А ви колись ловили себе на думці, що “я ж додав validation — значить, дублікати неможливі”? 😄

А потім у проді раптом з’являються сюрпризи, які ламають це відчуття безпеки.

Давайте розберемося, чому так відбувається 👇

#codica_advice

DB constraints: чому Rails validation — це не гарантія

📍 Rails без магії: 7 помилок, які роблять навіть мідли
📍 Background jobs: чому “просто Sidekiq” — не завжди просто
📍 Transactions у Rails: чому “і так працює” — небезпечна ілюзія

Майже кожен писав так:

validates :email, uniqueness: true

І здається — все, проблема вирішена.

Але в продакшені раптом з’являються два користувачі з однаковим email.

Чому?

Бо validation — це перевірка на рівні додатку,
а не гарантія на рівні бази.

Ми всі через це проходили 🙂

У чому реальна проблема
Rails validation працює так:
1. Перевіряє — чи існує запис
2. Якщо не існує — створює

Але якщо два запити прийшли одночасно → race condition.

І ти отримуєш дубль.

Що реально захищає
1️⃣ Unique index

add_index :users, :email, unique: true

Ось це вже гарантія.

База не дозволить вставити дубль навіть при конкурентному доступі.

2️⃣ NOT NULL

change_column_null :users, :email, false

Validation можна обійти через

update_column, insert_all

або консоль.
Constraint — ні.

3️⃣ Foreign keys

add_foreign_key :orders, :users

Без foreign key можна легко отримати “висячі” записи.

4️⃣ Check constraints (просунутий рівень)
Наприклад, статус лише з дозволеного списку:

add_check_constraint :orders, "status IN ('new', 'paid', 'cancelled')"

Тепер БД сама не дозволить некоректні дані.

Маленьке правило
Validation — це зручність.
Constraint — це гарантія.

Якщо дані критичні — вони мають бути захищені на рівні БД.

Типова помилка
Розробник каже:
“У нас же є validation.”

Але продакшен — це завжди про конкурентність, баги і непередбачувані сценарії.

І база — остання лінія оборони.

У кого був кейс, коли validation “пройшла”, а база зламалась? І що тоді довелося чистити вручну? 😄

TikTok | Instagram | Telegram

Є плани на літо? У нас є кілька ✈️

Ось 3 професійні стажування за кордоном від AIESEC для молоді 18–30 років 👇

💼 Хочеш у бізнесі та продажі — їдь до Португалії
Працюватимеш у Sabedoria Veloz — консалтингова компанія з нерухомості в Порто. Твої задачі: робота з CRM, комунікація з партнерами, підтримка sales-процесів та маркетингових інструментів.
📅 1 червня – 23 липня 2026 🕐 Пн–Пт, 08 :00 –17 :00
💸 Стажування без оплати
✔️ Проживання + харчування 1 раз/день + комп'ютер
💳 Членський внесок: 5 000 грн
🔗 Подати заявку

📱 Любиш соцмережі та відео — Греція чекає
Supreme Yachting — провідна яхтова агенція Греції — шукає SMM-спеца в Піреях. Будеш знімати відео, працювати з трендами та хештегами, розвивати облікові записи компанії зі свого досвіду в соцмережах.
📅 1 червня – 13 липня або 13 липня – 24 серпня 2026 🕐 Пн–Пт, 11 :00 –18 :00
💸 Стажування без оплати
✔️ Проживання покривається
💳 Членський внесок: 5 000 грн
🔗 Подати заявку

💻 Знаєш C++, Linux або Rust — їдь до Німеччини
Intra2net AG — компанія з 2001 року, що розробляє рішення безпеки для 5 000+ бізнесів. Будеш працювати над Linux-дистрибутивом та проектами з відкритим кодом, писати код на C++ і Rust, створювати автоматизовані тести.
📅 1 червня – 23 серпня 2026 🕐 Пн–Пт, 09 :00 –18 :00
💰 Зарплата: 1 600 EUR / місяць
✔️ Комп'ютер надається
💳 Членський внесок: 5 000 грн
🔗 Подати заявку

Уявіть двох людей з однаковою зарплатою. Вони п‘ють одну й ту саму каву, ходять в один спортзал і навіть жартують однаково. Але є нюанс: один із них через п‘ять років купує квартиру за готівку, а інший — нервово рахує дні до «смс-ки» про зарплату.

У чому секрет? У тому, що вони читають (або не читають) перед сном!

Перший колись присвятив вікенд «Психології грошей» Хаузела. Тепер він знає: нова приставка, коли на рахунку порожньо — це не «балування себе», а добровільне рабство на користь корпорацій. Він спокійно купує акції, коли ринок падає, бо в нього є стратегія від Бена Грема. Поки навколо паніка, він просто п‘є чай.

Другий вирішив, що книжки — це для теоретиків. Він довірився «пацанам з чату», влетів у сумнівну крипту на піку і тепер щоночі оновлює графік у надії повернути хоча б своє. Його стратегія — це надія. А надія — поганий фундамент для капіталу.

Різниця між ними — рівно 10 годин читання.

#codica_weekend

Щоб ви не витрачали час на сумнівну літературу «як стати мільйонером за ніч», ми зібрали для вас 5 фундаментальних книг.

🔹The Intelligent Investor — твій тверезий погляд на ринок.
🔹The Psychology of Money — щоб зрозуміти, чому ти витрачаєш там, де треба збирати.
🔹 A Random Walk Down Wall Street — математичне доведення, що стабільність б’є азарт.
🔹 One Up On Wall Street — як бачити гроші там, де інші бачать просто товари.
🔹 Common Stocks and Uncommon Profits — як відрізнити крутий бізнес від «пустушки».

Можна продовжувати грати в фінансову лотерею, а можна один раз вивчити правила.

А яку з цих книг ви б порадили собі 5 років тому, якби могли надіслати повідомлення у минуле? 😉

TikTok | Instagram | Telegram

Раночку, друзі! ☀️
Ну що, чий пароль сьогодні вже розгадали? 😄

Якщо життєво — став лайк ❤️
і поїхали підкорювати робочі файли, дедлайни та таски!

Продуктивного дня всім!

#codica_humor

TikTok | Instagram | Telegram

🎯 Як відповідати на запитання на співбесіді?

#codica_interviews

❌ Плутатись і говорити без структури — не ок
✅ Відповідати чітко, по кроках і по суті — ок

📌 How should you use filters in controllers?
📍 Очікувана відповідь:

У Ruby on Rails фільтри контролера

before_action
after_action
around_action

використовуються для виконання логіки до, після або навколо виконання action.

Їх основна мета — винести повторювану логіку з екшенів і уникнути дублювання коду.

Типові кейси використання:
1. Аутентифікація

before_action :authenticate_user!

Гарантує доступ лише авторизованим користувачам.

2. Завантаження ресурсу

before_action :set_post, only: [:show, :edit, :update, :destroy]

Уникає дублювання:

Post.find(params[:id])

у кожному action.

3. Авторизація

before_action :authorize_user

Перевірка прав доступу до ресурсу (часто через Pundit/CanCanCan).

⚠️ Важливо:
• Фільтри повинні містити тільки просту, повторювану логіку
• ❌ Не варто розміщувати бізнес-логіку у фільтрах
• Контролер має залишатися thin controller

👉 Основна логіка — у сервісах або моделях.

📌 What do we need to test in controllers?
📍 Очікувана відповідь:

Контролерні тести перевіряють HTTP-поведінку, а не бізнес-логіку.

Що саме тестуємо:
1. HTTP статус

expect(response).to have_http_status(:ok)
expect(response).to have_http_status(:redirect)
expect(response).to have_http_status(:not_found)

2. Рендеринг або редирект

expect(response).to render_template(:show)
expect(response).to redirect_to(posts_path)

3. Strong params
Перевірка, що приймаються лише дозволені параметри
(зазвичай опосередковано через поведінку).

4. Зміни в БД

expect {
  post :create, params: { post: valid_attributes }
}.to change(Post, :count).by(1)

5. Авторизація
Перевірка доступу:
• неавторизований → редирект / 401
• авторизований → success

6. JSON (для API)

expect(json_response["title"]).to eq("Test")

⚠️ Важливо (це часто валить кандидатів):
• ❌ Не тестуємо бізнес-логіку в контролері
• ❌ Не дублюємо модельні тести
• ✅ Контролер = вхід → вихід

request → response

🎯 Професійний підхід
Контролерні тести перевіряють:
👉 маршрутизацію
👉 статуси
👉 доступ
👉 формат відповіді

Бізнес-логіка тестується окремо:
• в моделях
• в сервісах

Ну і нехай оффери знаходять вас швидше, ніж ви встигаєте натиснути “Deploy” 🚀

TikTok | Instagram | Telegram