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

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

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

#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

Запрошуємо на Highload fwdays'26 — конференцію для тих, хто будує системи, які витримують будь-яке навантаження! ⚙️🔥

На вас чекає До 10 топових спікерів та професійний нетворкінг з інженерами, архітекторами та девопсами.

Говоритимемо про масштабування, Performance, Database в продакшн і не тільки.
Розбиратимемо кейси від Uklon, Silpo, MacPaw, Universe Group та інших техгігантів.

📍 Де: Київ (офлайн + онлайн)
📅 Коли: 6 червня
🔗 Деталі та реєстрація: https://bit.ly/4nxmojA
🎟 Знижка 10% за промокодом: CODICA_HIGHLOAD

🧠 13 законів розробки

Іноді найшвидший спосіб отримати правильну відповідь — це не поставити ідеальне питання, а показати недосконалий варіант рішення. У світі розробки це працює частіше, ніж здається — особливо в командній роботі та технічних дискусіях.

Попередні закони читайте тут:
👉 Закон Паркінсона
👉 Закон Хофштедтера
👉 Закон Брукса
👉 Закон Конвея (і зворотний закон Конвея)

Сьогодні — закон, який прекрасно пояснює, як насправді працює обмін знаннями 👇

✍️ Закон Каннінгема

“Найкращий спосіб отримати правильну відповідь в інтернеті — написати неправильну.”

👨‍💻 Що це означає для розробників
• простіше отримати фідбек, коли показуєш свій варіант рішення;
• прототип або rough-версія часто запускає дискусію швидше, ніж абстрактне питання;
• ревʼю коду працює ефективніше, коли є що критикувати.

📊 Що це означає для менеджерів
• швидкість обговорень зростає, коли є конкретний артефакт;
• draft-документи стимулюють команду включатися;
• early version краще, ніж ідея “в повітрі”.

💡 Простий приклад
Замість питання:
“Як краще реалізувати кеш?”
розробник кидає PR із базовою реалізацією.
Команда швидко знаходить edge-кейси, пропонує альтернативи — і рішення зʼявляється значно швидше.

Як працювати з цим законом:
✔️ показувати чернетки замість чекати ідеалу
✔️ писати proposal навіть якщо він не ідеальний
✔️ сприймати правки як частину процесу, а не як критику

💬 Не чекайте “ідеального” варіанту — іноді саме недосконала перша версія запускає найкориснішу дискусію в команді.

TikTok | Instagram | Telegram

💎 Знову улюблена добірка книг для Ruby devs!

#codica_advice

Безкоштовні PDF-книги, щоб прокачати ваш Ruby та Rails 📚

📍 Добірка Ruby-книжок 1
📍 Добірка Ruby-книжок 2
📍 Добірка Ruby-книжок 3
📍 Добірка Ruby-книжок 4

А сьогодні — вже 5-та добірка 🔥

👉 The Rails and Hotwire Codex: Build an app for web, iOS, and Android
Практичний гайд зі створення сучасних застосунків з використанням Rails та Hotwire для різних платформ.

👉 Layered Design for Ruby on Rails Applications
Про архітектуру та дизайн-патерни, які допоможуть створювати масштабовані та підтримувані Rails-додатки.

👉 Programming Crystal
Create High-Performance, Safe, Concurrent Apps
Для тих, хто хоче вийти за межі Ruby та спробувати Crystal — мову з подібним синтаксисом, але високою продуктивністю.

👉 Clean Ruby
A Guide to Crafting Better Code for Rubyists
Книга про чистий код у світі Ruby — як писати зрозуміло, красиво та професійно.

Ставте вподобайку, зберігайте і вдалого вам вечора! ✨

TikTok | Instagram | Telegram

Друзі, вітаємо з Днем вишиванки! 🤍

Наш генетичний код. Наша гордість. Наша розмова зі світом без слів. 🇺🇦
Сьогодні вулиці розквітають вишиванками, і від цього на душі стає спокійніше. Одягнути вишиванку сьогодні — це сказати: «Я пишаюся тим, хто я є».

З Днем вишиванки! Зі святом! 🌸🇺🇦
Обіймаємо кожного через усі відстані!

TikTok | Instagram | Telegram