-
юридическая консультация
Форум: Курилка (Offtop)
Останнє повідомлення від: RobertGow
23-07-2026, 18:31
» Відповіді: 0
» Перегляди: 76 -
Як Cloudflare вбиває SEO ...
Форум: SEO просування сайтів
Останнє повідомлення від: Olena_Top
18-07-2026, 13:17
» Відповіді: 5
» Перегляди: 112 -
Монітор програміста у 202...
Форум: Залізо (Hardware)
Останнє повідомлення від: Stas_Frontend
18-07-2026, 13:06
» Відповіді: 5
» Перегляди: 103 -
Як почати просувати молод...
Форум: Інформаційні ресурси
Останнє повідомлення від: Yulia_JS
18-07-2026, 11:00
» Відповіді: 3
» Перегляди: 86 -
Яке сьогодні свято? Приві...
Форум: Інформаційні ресурси
Останнє повідомлення від: rullan
16-07-2026, 22:04
» Відповіді: 2
» Перегляди: 72 -
MySQL vs SQLite: Порівнян...
Форум: Веб проекти та Веб додатки
Останнє повідомлення від: Stas_Frontend
15-07-2026, 09:46
» Відповіді: 5
» Перегляди: 122 -
Скільки коштує в місяць б...
Форум: Сервіси Штучного інтелекту
Останнє повідомлення від: Olena_Top
13-07-2026, 12:17
» Відповіді: 5
» Перегляди: 123 -
Український продукт: корп...
Форум: Українські розробки
Останнє повідомлення від: rullan
09-07-2026, 08:33
» Відповіді: 5
» Перегляди: 175 -
Figma у 2026 році: Чи є щ...
Форум: Обговорюємо HTML + CSS
Останнє повідомлення від: rullan
09-07-2026, 08:19
» Відповіді: 5
» Перегляди: 111 -
Сайт з Вебархіву: AstroFo...
Форум: Інші сайти
Останнє повідомлення від: Stas_Frontend
24-06-2026, 20:53
» Відповіді: 5
» Перегляди: 108
- Повідомлення на форумі:436
- Гіди форуму:141
- Учасники:49
- Останній учасник:Andraxqv
Привіт всім! Сьогодні хочу підняти дуже холіварну, але неймовірно важливу тему архітектури баз даних — використання зовнішніх ключів (Foreign Keys, або просто "зв'язки таблиць").
В університетах та на курсах нас вчать, що реляційна база даних завжди повинна бути в третій нормальній формі (3NF), а всі пов'язані таблиці мають бути жорстко з'єднані між собою через `FOREIGN KEY`. Це робиться для того, щоб гарантувати так звану цілісність даних (Referential Integrity). Але на практиці, особливо в великих HighLoad-проектах або мікросервісних архітектурах, архітектори часто свідомо відмовляються від використання фізичних зовнішніх ключів на рівні бази даних.
Чому так відбувається? Давайте розбиратися більш детально, коли зв'язки — це беззаперечна користь, а коли — абсолютне зло і антипатерн.
Коли зв'язки таблиць — це беззаперечна користь (і навіть мастхев)
1. Гарантія цілісності даних (Data Integrity). Головне завдання зовнішнього ключа — не дати вам вставити в базу "сироту". Наприклад, ви не зможете створити замовлення (Order) для клієнта (User), якого не існує в таблиці користувачів. Аналогічно, ви не зможете випадково видалити категорію товарів, якщо в ній ще залишилися товари (залежно від налаштувань ON DELETE RESTRICT / CASCADE). Це гарантує, що ваша база ніколи не перетвориться на смітник з битими посиланнями, які потім викликають Fatal Errors у додатку.
2. Автоматичне каскадне видалення (ON DELETE CASCADE). Дуже зручна фішка для невеликих і середніх проектів. Видаляєте користувача — і база даних сама, на рівні ядра, видаляє всі його пости, коментарі, лайки та активні сесії. Вам не треба писати складну логіку в бекенді, обходити цикли та переживати, що десь забули почистити пов'язані дані. Це швидко і надійно.
3. Документація схеми та ORM. Коли новий розробник (або навіть ви самі через півроку) дивиться на базу з зовнішніми ключами через ER-діаграму, він відразу розуміє архітектуру проекту. Крім того, сучасні ORM-фреймворки (як Doctrine в PHP, Eloquent в Laravel чи Hibernate в Java) можуть автоматично генерувати моделі та їх зв'язки на основі цих ключів в БД. Це значно прискорює розробку.
4. Запобігання помилкам розробників на рівні ядра. Якщо у вас є баг в коді, який намагається записати неіснуючий `product_id` в таблицю кошика, база даних просто відхилить такий запит з помилкою `Constraint Violation`. Без FK цей "фантомний" запис потрапив би в базу, і потім ви б довго шукали причину, чому в кошику лежить товар без назви і ціни.
Коли зв'язки таблиць перетворюються на ЗЛО (і чому від них відмовляються)
Але якщо все так круто, то чому такі технологічні гіганти як GitHub, Shopify, або просто великі проекти на мікросервісах взагалі відмовилися від використання Foreign Keys?
1. Продуктивність та блокування (Performance & Locking). Це головна причина. Кожного разу, коли ви вставляєте або оновлюєте запис із зовнішнім ключем, база даних повинна зробити невидимий `SELECT` в пов'язану таблицю, щоб перевірити, чи дійсно існує там такий ID. При масових вставках (Bulk Insert) або дуже високому навантаженні (HighLoad) це створює величезний оверхед на I/O диска. Більше того, FK можуть викликати каскадні блокування рядків (Row Locks), що часто призводить до мертвих блокувань (Deadlocks) при паралельних транзакціях з різних потоків.
2. Складнощі з шардінгом (Sharding) та масштабуванням. Коли ваша база переростає один сервер, ви починаєте ділити її на частини (шарди). Наприклад, користувачі з США лежать на одному сервері (Шард А), а з Європи — на іншому (Шард Б). А що робити із замовленнями? Зовнішні ключі працюють тільки в межах однієї бази даних на одному сервері. Неможливо створити фізичний FK між таблицями, які лежать на різних фізичних машинах. Тому в мікросервісах або шардованих базах цілісність даних підтримується виключно на рівні додатку (код), а не на рівні БД.
3. Міграції та зміни схеми бази (Schema Migrations). У великій базі (сотні гігабайт або терабайти даних) змінити тип колонки, яка бере участь у FK, або додати/видалити новий зв'язок — це справжній біль. Процес `ALTER TABLE` з перевіркою констрейнтів може заблокувати таблицю на години, зупинивши роботу всього проекту. Набагато простіше просто зберігати ID як звичайний `INT` або `UUID` і підтримувати логіку перевірок в коді бекенду.
4. Проблема 'каскадного пекла'. Правило `ON DELETE CASCADE` звучить круто, поки хтось випадково (через баг в адмінці або необачний запит) не видалить базовий запис (наприклад, 'Компанію'). Тоді база мовчки, за лічені секунди, знесе сотні тисяч записів з 20 інших таблиць (співробітників, їхні фінансові транзакції, історію листування тощо). У серйозних системах використовують виключно 'м'яке видалення' (Soft Delete), просто ставлячи прапорець `is_deleted = 1` або `deleted_at = NOW()`. У цьому випадку запис фізично лишається в базі, тому FK іноді просто заважають.
Висновок
Для 90% типових проектів (CMS, блоги, корпоративні сайти, інтернет-магазини середнього розміру, CRM системи для малого бізнесу) зовнішні ключі — це ваші найкращі друзі. Вони захистять вас від купи помилок та сміття в базі. Економіка проекту виграє від надійності більше, ніж від гіпотетичної економії мілісекунд.
Але якщо ви будуєте HighLoad архітектуру, розбиваєте величезний проект на мікросервіси, плануєте шардінг бази, або стикаєтесь з проблемами продуктивності при записі десятків тисяч рядків на секунду — вам, скоріш за все, доведеться відмовитись від фізичних зв'язків у БД і повністю перенести відповідальність за цілісність даних на ваш бекенд.
Який ваш особистий досвід? Ви завжди ставите FK на автоматі, чи свідомо ігноруєте їх? Чи були у вашій практиці випадки, коли зв'язки вас реально рятували від катастрофи, або навпаки — повністю клали базу під навантаженням? Діліться історіями!
Привіт, спільното! Нещодавно відбувся реліз **Antigravity 2** від команди Google DeepMind, і я вирішив розібрати, що нового з'явилося в цьому надпотужному ШІ-асистенті для програмістів. Якщо ви пам'ятаєте першу версію, вона вже була крутою, але друга — це справжній прорив у сфері Agentic Coding.
1. Автономні субагенти (Subagents)
Найбільша фішка другої версії — це можливість Antigravity 2 самостійно створювати та керувати субагентами. Уявіть, що ви ставите задачу: "Розробити новий модуль для CMS". Antigravity 2 не просто пише код лінійно, він створює субагента-дослідника (researcher), який вивчає кодову базу, поки головний агент проектує архітектуру. Це дозволяє паралельно вирішувати складні задачі.
2. Планування (Planning Mode)
Тепер асистент став значно обережнішим із великими проектами. З'явився режим "Planning Mode", який змушує ШІ спершу провести глибокий аналіз (без написання коду), скласти детальний план імплементації (Implementation Plan), погодити його з розробником, і лише після Approval починати писати код. Це економить купу часу на переробках, коли ШІ "галюцинував" архітектуру на 10 файлів, яка не підходила до вашого проекту.
3. Нові інструменти взаємодії з файлами та терміналом
З'явилися круті інструменти, як multi_replace_file_content, що дозволяють вносити зміни у декілька незв'язаних блоків коду в одному файлі за один виклик. Це робить рефакторинг набагато швидшим. Крім того, ШІ тепер вміє запускати фонові задачі в терміналі і отримувати сповіщення, коли вони завершаться (замість того, щоб тупо чекати).
4. Інтеграція з браузером (Browser Subagent)
Antigravity 2 отримав можливість запускати браузерні сесії для пошуку інформації, перевірки роботи веб-додатків, читання документації, що недоступна просто через curl. Він сам клікає, скролить і аналізує сторінки, що неймовірно корисно при дебагінгу фронтенду чи парсингу.
5. Розширений контекст та пам'ять
Завдяки переходу на нове ядро (Gemini 3.1 Pro), контекстне вікно стало ще більшим, а головне — ШІ краще утримує увагу на деталях з початку розмови. Також з'явилися артефакти (Artifacts) — спеціальні markdown-документи (task.md, walkthrough.md), які ШІ веде як журнал проекту, фіксуючи, що зроблено, а що ще залишилося.
В цілому, Antigravity 2 — це вже не просто "розумний автокомпліт", а повноцінний мідл-розробник у вашій команді, якому можна делегувати не просто написання функції, а цілі фічі з архітектурним плануванням та тестуванням.
Хто вже встиг потестити? Які ваші враження від нових субагентів та швидкості роботи?
Пропоную в цій темі ділитися своїми пет-проектами, інформаційними сайтами та просто корисними ресурсами, які ми створили. Почну першим!
Запустив нещодавно SaunaWiki — https://sauna-retro.pp.ua/.
Це така собі енциклопедія про сауни та лазні. Збирав інформацію про історію, вплив на здоров'я і навіть поради з будівництва. Якщо хтось планує будувати власну лазню або просто любить погрітися — заходьте, там багато цікавого.
А чим можете похвалитися ви? Додавайте посилання та короткий опис!
Привіт, колеги! 2026 рік приніс чимало крутих оновлень у світ фронтенду. Якщо ви ще верстаєте по-старому, час оновити свій інструментарій. Ось суб'єктивний топ найважливіших фішок, які стали стандартом цього року:
1. CSS Anchor Positioning (Якірне позиціонування)
Нарешті ми забули про муки з JS для створення тултіпів, випадаючих меню та попапів. Тепер можна прив'язати один елемент до іншого прямо в CSS:
.tooltip {
position: absolute;
position-anchor: --my-button;
bottom: anchor(top);
}2. View Transitions API (Multi-page підтримка)
Тепер плавні переходи між сторінками працюють не тільки в SPA, а й у звичайних багатосторінкових сайтах. Достатньо одного мета-тегу та CSS правила view-transition-name, щоб елементи красиво перетікали з однієї сторінки на іншу при навігації.
3. Повний контроль над <selectlist>
Старий добрий <select> нарешті отримав повноцінну заміну — <selectlist>. Тепер ми можемо стилізувати кожну частину випадаючого списку (кнопку, контейнер з опціями) без використання кастомних JS-бібліотек, які важать як крило літака.
4. CSS Style Queries (Контейнерні запити по стилях)
Ми вже звикли до запитів по розміру контейнера, але тепер можна змінювати стилі залежно від значень кастомних властивостей (CSS variables) батьківського елемента. Це дозволяє створювати неймовірно гнучкі дизайн-системи.
5. HTML Search Element
Тег <search> став обов'язковим для доступності. Він семантично позначає частину сторінки, призначену для пошуку або фільтрації, замінюючи старий підхід з role="search".
6. Masonry Layout у CSS Grid
Те, на що ми чекали роками! Більше не потрібен JS для створення сітки в стилі Pinterest. У 2026 році властивість grid-template-rows: masonry вже стабільно працює в більшості сучасних браузерів.
Що з цього ви вже впровадили у свої проекти? Чи є щось, що я пропустив?
Masonry — це просто розрив! Я нарешті видалив скрипт на 15кб, який тільки цим і займався. Єдине, що засмучує — Safari як завжди наздоганяє останньою, хоча в 19-й версії вже ніби все ок.
Привіт всім! Нещодавно натрапила на цікавий ресурс для тих, хто займається просуванням бізнесу в Україні — Бізнес каталог України (BizCatalog), доступний за адресою catalog.biz.ua.
Хочу поділитися основними фішками, які я для себе виділила:
Що це таке?
Це сучасний каталог компаній та послуг, де можна розмістити профіль свого бізнесу (навіть якщо ви ФОП). Сайт має досить високий авторитет домену (DR 27+), що дуже круто для SEO.
Основні категорії:
Каталог дуже структурований — понад 200 категорій у 11 основних напрямках. Найбільш активні:
- Медицина та здоров'я: аптеки, клініки.
- Дозвілля: ресторани, туризм.
- Бізнес-послуги: право, консалтинг, бухгалтерія.
- Навчання: курси, школи.
Можливості для власників бізнесу:
1. Безкоштовне розміщення: Можна додати компанію назавжди без оплати (з ручною модерацією).
2. Прямі контакти: Можна вказати телефон, email та посилання на сайт/соцмережі.
3. SEO-профіт: Навіть на безкоштовному тарифі ви отримуєте згадку, а на платних — активні do-follow посилання.
4. Просування через статті: Є тарифи, які включають написання аналітичних статей про ваш бізнес.
Тарифи:
Там є кілька рівнів — від Безкоштовного до Аналітики (за 1200 грн), де обіцяють максимальну видимість і навіть беклінки з інших ресурсів.
Як на мене, це непоганий спосіб отримати додатковий трафік і покращити впізнаваність бренду в мережі. Хтось уже користувався цим сервісом? Як результати?
Вступ: Чому Go (Golang) — це чудовий вибір для веб-розробки?
Go, або Golang, розроблений компанією Google, за останні роки став однією з найпопулярніших мов для створення високонавантажених бекенд-систем. Його головні переваги — це неймовірна швидкість виконання (близька до C++), простота синтаксису та вбудована підтримка конкурентності (goroutines). У цьому гайді ми пройдемо шлях від написання першого сервера до його деплою на реальний сервер.
1. Налаштування оточення
Перш за все, вам потрібно встановити Go з офіційного сайту go.dev. Після інсталяції перевірте версію в терміналі:
go versionСтворіть робочу директорію для проекту та ініціалізуйте модуль:
mkdir my-go-site
cd my-go-site
go mod init github.com/username/my-go-site2. Створення базового HTTP-сервера
Go має потужну стандартну бібліотеку net/http, яка дозволяє створити сервер без сторонніх фреймворків. Створіть файл main.go:
package main
import (
"fmt"
"net/http"
)
func homeHandler(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "<h1>Вітаємо на моєму сайті на Go!</h1>")
}
func main() {
http.HandleFunc("/", homeHandler)
fmt.Println("Сервер запущено на http://localhost:8080")
http.ListenAndServe(":8080", nil)
}Запустіть код командою
go run main.go3. Робота з шаблонами (HTML Templates)
Для створення реальних сайтів ми використовуємо пакет html/template. Це дозволяє безпечно (із захистом від XSS) вставляти дані в HTML-код.
Приклад створення шаблону templates/index.html:
<!DOCTYPE html>
<html>
<head>
<title>{{.Title}}</title>
</head>
<body>
<h1>{{.Header}}</h1>
<p>Сьогодні: {{.Date}}</p>
</body>
</html>Код у Go для рендерингу:
func handler(w http.ResponseWriter, r *http.Request) {
tmpl := template.Must(template.ParseFiles("templates/index.html"))
data := struct {
Title string
Header string
Date string
}{
Title: "Мій Go Сайт",
Header: "Ласкаво просимо!",
Date: time.Now().Format("02.01.2006"),
}
tmpl.Execute(w, data)
}4. Вибір фреймворку: Standard Lib чи Fiber/Echo?
Хоча стандартна бібліотека крута, для великих проектів часто використовують:
- Fiber: Дуже швидкий (подібний до Express.js у Node.js).
- Echo: Мінімалістичний та високопродуктивний.
- Gin: Один із найпопулярніших завдяки своїй стабільності та екосистемі.
Якщо ви тільки починаєте — спробуйте Gin, він має чудову документацію.
5. Робота з базою даних
Для Go найкраще підходить PostgreSQL. Ми можемо використовувати драйвер pgx або ORM на кшталт GORM.
Приклад підключення (GORM):
db, err := gorm.Open(postgres.Open(dsn), &gorm.Config{})
if err != nil {
panic("failed to connect database")
}Go дозволяє писати типобезпечні запити, що значно зменшує кількість помилок у рантаймі.
6. Структура проекту
Типова структура професійного Go-проекту виглядає так:
- /cmd: Точки входу (main.go).
- /internal: Бізнес-логіка, прихована від зовнішнього світу.
- /pkg: Бібліотеки, які можна перевикористовувати.
- /api: Визначення API-інтерфейсів.
7. Компіляція та Деплой
Одна з найбільших переваг Go — це компіляція в один бінарний файл. Вам не потрібно встановлювати Go на сервері!
Зберіть проект:
GOOS=linux GOARCH=amd64 go build -o mysite ./cmd/main.goТепер просто скопіюйте файл mysite на свій VPS (наприклад, через scp) і запустіть його.
Використання Docker:
Створіть Dockerfile:
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY . .
RUN go build -o main .
FROM alpine:latest
COPY --from=builder /app/main /main
ENTRYPOINT ["/main"]Це створить максимально легкий образ (близько 15-20 МБ), який легко розгортати в Kubernetes або через Docker Compose.
Поради для продакшену:
1. Використовуйте Nginx як Reverse Proxy для кешування та SSL.
2. Налаштуйте Systemd юніт, щоб сайт автоматично перезапускався після збоїв.
3. Обов'язково додайте логування (наприклад, пакет uber-go/zap).
Висновок
Go — це мова для тих, хто втомився від складності Java або повільності Python/PHP. Вона дає розробнику повний контроль, неймовірну швидкість та впевненість у тому, що код буде працювати стабільно під будьяким навантаженням.
Чи пробували ви вже писати бекенд на Go? Які були ваші найбільші труднощі? Обговоримо у коментарях!
Хорошоп (Horoshop) — це українська SaaS-платформа для створення інтернет-магазинів, яка за останні роки стала справжнім лідером на нашому ринку. Багато хто називає її «українським Shopify», і в цьому є доля правди. Але чи дійсно вона підходить для будь-якого бізнесу? Давайте розберемося.
1. Що таке Хорошоп?
Це хмарне рішення (SaaS), що означає, що вам не потрібно купувати хостинг, встановлювати двигун чи займатися технічною підтримкою сервера. Ви просто реєструєтеся, обираєте дизайн, завантажуєте товари — і ваш магазин готовий до роботи. Це ідеально для малого та середнього бізнесу, який хоче швидко запуститися без залучення дорогих розробників.
2. Головні переваги
- SEO-оптимізація з коробки. Це одна з найсильніших сторін платформи. Усі технічні налаштування для SEO (редиректи, мікророзмітка Schema.org, оптимізація швидкості завантаження) вже впроваджені. Сайти на Хорошоп зазвичай мають високі показники Google PageSpeed.
- Інтеграція з українськими сервісами. Платформа має готові модулі для Нової Пошти, Укрпошти, Checkbox (ПРРО), а також платіжних систем LiqPay, WayForPay та Monobank. Жодна іноземна CMS не дасть такої глибини локалізації без додаткових плагінів.
- Робота з маркетплейсами. Вивантаження товарів на Rozetka, Prom.ua, Google Shopping, Facebook та Instagram робиться в кілька кліків.
- Швидкість запуску. Магазин можна налаштувати за кілька днів, якщо у вас вже готові фото та описи товарів.
3. Технічні нюанси та обмеження
Оскільки це SaaS, ви не маєте доступу до вихідного коду (PHP/JS). Ви не можете самостійно дописати якусь унікальну функцію або змінити структуру бази даних. Ви обмежені тими можливостями, які надає платформа. Хоча Хорошоп постійно оновлюється, іноді доводиться чекати на реалізацію специфічних хотілок.
4. Цінова політика
Хорошоп працює за передплатою. Є кілька тарифних планів, залежно від кількості товарів та необхідного функціоналу. Важливо розуміти, що за стартовий запуск (налаштування) зазвичай береться одноразовий платіж, але часто бувають акції, де запуск безкоштовний.
5. Порівняння з конкурентами
Якщо порівнювати з WordPress + WooCommerce, то Хорошоп виграє за рахунок стабільності та відсутності необхідності «колупатися в коді». З іншого боку, WordPress дає повну свободу, але вимагає постійного нагляду за безпекою та оновленнями.
Порівняно з Shopify, Хорошоп значно дешевший (особливо враховуючи комісії Shopify за транзакції) та набагато краще адаптований під українські реалії податкової звітності та логістики.
Висновок
Хорошоп — це потужний інструмент для тих, хто цінує свій час і хоче зосередитися на продажах, а не на програмуванні. Якщо вам потрібен стандартний інтернет-магазин з гарним SEO та всіма українськими інтеграціями — це варіант №1. Але якщо ви плануєте будувати складний портал з унікальною механікою лояльності чи нестандартним кабінетом користувача — можливо, варто дивитися в бік кастомної розробки.
А що ви думаєте про Хорошоп? Хто вже мав досвід переїзду на цю платформу з інших CMS? Давайте обговоримо!
Додатково про мобільну версію та дизайн
Варто згадати про адаптивність. Хорошоп пропонує велику кількість готових шаблонів, які вже протестовані на конверсію. Мобільна версія працює дуже швидко, що критично важливо у 2024 році, коли понад 70% трафіку йде зі смартфонів. Ви можете змінювати кольори, шрифти та структуру блоків на головній сторінці, але радикально перекроїти дизайн без допомоги дизайнерів Хорошопу буде складно. Це плата за стабільність і підтримку.
Також цікавий момент — це B2B функціонал. Нещодавно платформа додала можливість створювати окремі ціни для різних груп покупців, що робить її придатною не тільки для роздрібної торгівлі, а й для гуртових постачальників. Це великий крок вперед, який раніше був доступний тільки в дорогих Enterprise-рішеннях.
Чекаю на ваші коментарі! Чи відчуваєте ви обмеження SaaS-моделі, чи навпаки — радієте, що не треба шукати фрілансерів для кожного «фікса»?
Давайте чесно: OpenAI почали здавати позиції. Клод пише кращий код, Gemini ковтає гігабайти даних, а китайці з DeepSeek та Qwen взагалі демпінгують ринок потужними Open-Source моделями.
Що ви зараз використовуєте в роботі? Чи вірите ви, що китайський ШІ обійде США вже цього року? Чи все це просто хайп на бенчмарках?
Колеги, вже півроку працюю з App Router у Next.js і досі маю змішані почуття щодо React Server Components (RSC). З одного боку — менший бандл на клієнті, з іншого — складність у розумінні 'де клієнт, а де сервер' зросла в рази. Чи не здається вам, що ми надто все ускладнюємо заради 100 балів у Lighthouse?
Хто як налаштовує згоду на куки для бурж-проектів? Останнім часом Google дуже суворо вимагає Consent Mode v2. Чи використовуєте ви готові рішення типу Cookiebot, чи пишете свої легкі скрипти, щоб не валити швидкість сайту?