Коли робочий тиждень позаду, у Mr. Cody прокидається внутрішній кутюр’є ✨

Наш маскот приміряв традиційні костюми різних країн. Ну який же він у нас гарнюня 🫶 (Окрім одного персонажа з унітазами, але то окрема клінічна історія 🫠)

Який образ Містера Cody залетів вам у саме серце?

Став реакції:
❤️ — за розкішний український аутфіт!
🔥 — за стильні європейські костюми!
🗿 — за «стиль болота» в окремому бліндажі!

TikTok | Instagram | Telegram

Друзі, всім ясного та допитливого вихідного 🔬

#codica_weekend

Зібрали для вас підбірку про науку. Ідеально, щоб залипнути з користю 🧠

➡️ 25 за 25: найбільші наукові відкриття ХХІ сторіччя і що далі до 2050?
Геном, CRISPR, AlphaFold, чорні діри і термоядерка — концентрат науки, після якого трохи інакше дивишся на світ і майбутнє.
⏱ Тривалість — 34 хв

➡️ Людина, яка відкрила антиматерію [VERITASIUM]
Історія відкриття, яке звучить як sci-fi, але стало реальною наукою — дуже захоплює і пояснює складне простими словами.
⏱ Тривалість — 34 хв

➡️ Чому часові пояси такі дивні?
Після цього відео ви нарешті зрозумієте, чому світ живе в такому хаосі часу і чому все могло бути значно простіше 😄
⏱ Тривалість — 27 хв

Нехай ці вихідні будуть з новими відкриттями, гарним настроєм і хоча б однією відповіддю на питання “як це працює?” ☕

TikTok | Instagram | Telegram

Раночку, друзі!!

Ну так і є, а що? 😄
Гарного усім дня!

#codica_humor

TikTok | Instagram | Telegram

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

#codica_interviews

❌ Обмежуватися визначенням з документації.
✅ Пояснювати архітектурні нюанси.

📌 Explain what is a session mechanism. How does it work in Rails?
📍 Очікувана відповідь:

HTTP є stateless-протоколом, тому сесія — це спосіб зберегти стан між запитами.

За замовчуванням у Rails використовується ActionDispatch::Session::CookieStore.

Весь стан сесії серіалізується у JSON (починаючи з Rails 7), шифрується алгоритмом AES-256-GCM (через ActiveSupport::MessageEncryptor) і зберігається прямо у браузері користувача.

🔒 Завдяки шифруванню клієнт не може прочитати вміст, а завдяки криптографічному підпису — не може його підробити.

💡 Профі додасть про обмеження та альтернативи:

У CookieStore є ліміт 4KB і відсутній швидкий механізм відкликання сесії з боку сервера (якщо куку вкрали, вона валідна, поки не спливе expires). Тому для критичних систем краще конфігурувати :cache_store (на базі Redis або Solid Cache) — тоді в cookie зберігається лише випадковий session_id, а самі дані лежать на сервері.

🛡 Захист від Session Fixation при автентифікації

def create
  user = User.find_by(email: params[:email])

  if user&.authenticate(params[:password])
    # Повністю оновлюємо сесію перед записом нових даних
    reset_session
    session[:user_id] = user.id
    redirect_to root_path
  else
    render :new
  end
end

📌 Describe CSRF, XSS, session hijacking, and session fixation.
📍 Очікувана відповідь:

🔹 CSRF (Cross-Site Request Forgery) — атака, що змушує браузер авторизованого користувача виконати небажаний запит (POST/PUT/DELETE) на ваш додаток.

🛡 Захист: Rails (у non-API додатках) порівнює токен у параметрах/заголовках із токеном у сесії за допомогою protect_from_forgery. Також допомагає прапорець SameSite=Lax або Strict для cookies.

🔹 XSS (Cross-Site Scripting) — впровадження шкідливого JS-коду в сторінку.

🛡 Захист: Rails автоматично ескейпить вивід у шаблонах (через клас ActiveSupport::SafeBuffer). Метод html_safe та хелпер raw слід використовувати обережно. Глобально додаток захищає налаштування Content Security Policy (CSP) заголовків.

🔹 Session Hijacking — викрадення чужого session cookie (через MITM або XSS).

🛡 Захист: Робота виключно через HTTPS (config.force_ssl = true), а також обов'язкові прапорці HttpOnly (забороняє JS читати куку) та Secure для сесійних файлів cookie.

🔹 Session Fixation — ситуація, коли зловмисник нав'язує жертві свій session_id до моменту логіну, а після авторизації користувача отримує доступ до його сесії.

🛡 Захист: Обов’язковий виклик reset_session одразу після успішного входу (популярні геми на кшталт Devise чи Rodauth роблять це автоматично під капотом).

✅ Коротко:
На співбесіді важливо показати концепцію Defense in Depth (багаторівневий захист): ми не просто сподіваємося на магію фреймворку, а чітко розуміємо конфігурацію кук, HTTP-заголовки безпеки ( HSTS , CSP) та логіку роботи middleware (ActionDispatch).

TikTok | Instagram | Telegram

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

Друзі, ви знали що інколи інструменти починають жити власним життям?

Просте рішення поступово обростає новими функціями, стає складнішим і в якийсь момент вже важко зрозуміти, для чого воно створювалось спочатку. Знайомо? 🙂

Сьогодні — закон, який дуже точно описує еволюцію багатьох продуктів 👇

Закони, які вже розглянули:
👉 Закон Паркінсона
👉 Закон Хофштедтера
👉 Закон Брукса
👉 Закон Конвея (і зворотний закон Конвея)
👉 Закон Каннінгема
👉 Закон Стерджена

🧩 Закон Завінскі (Zawinski’s Law)

“Кожна програма намагається розширитися, поки не зможе читати email.”
(А ті, що не змогли — замінюються іншими, які змогли)

👨‍💻 Що це означає для розробників
• навіть прості інструменти з часом перетворюються на “комбайни”;
• зʼявляється зайва складність і важчий support;
• фокус продукту розмивається через нескінченні фічі.

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

💡 Простий приклад
👉 Slack починався як месенджер — тепер це платформа з інтеграціями, AI-функціями, workflow і mini-apps.
👉 Notion — із нотаток виріс у повноцінну операційну систему для команд.

Як працювати з цим законом:
✔️ регулярно перевіряти core value продукту
✔️ не додавати функції лише тому, що “можемо”
✔️ залишати простір для простих, вузькоспеціалізованих рішень

Інколи найсильніше продукт виглядає не через кількість фіч, а через чіткий фокус і зрозуміле призначення.

TikTok | Instagram | Telegram

💎 Ruby-інструменти, які варто знати кожному розробнику. Частина 2

Попередня частина:
👉 Ruby-інструменти. Частина 1

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

#codica_advice

Ось 4 інструменти, які допоможуть тримати код під контролем 👇

📌 RuboCop

Більшість Ruby-розробників використовують RuboCop як автоформатер. Але його потенціал значно більший.

Рекомендуємо звернути увагу на додаткові набори правил:
• rubocop-performance — знаходить неефективний Ruby-код
• rubocop-rspec — покращує якість тестів
• rubocop-rails — перевіряє Rails-специфічні антипатерни

Часто один новий cop може виявити десятки проблем по всьому проєкту.

📌 Reek

Шукає code smells.
На відміну від RuboCop, аналізує не стиль, а дизайн коду.

Наприклад:
• Long Method
• Feature Envy
• Utility Function
• Too Many Parameters

Саме Reek часто показує місця, які давно просяться на рефакторинг.

📌 Flog

Вимірює складність методів.
Якщо метод отримує високий Flog score — це сигнал, що його важко читати, тестувати та підтримувати.

Корисно запускати перед великим рефакторингом, щоб зрозуміти, де найбільший біль у проєкті.

📌 Flay

Шукає дублювання коду.
І не просто копіпасту рядок у рядок.

Flay знаходить схожі фрагменти логіки навіть після перейменування змінних або незначних змін у коді.

Іноді після запуску виявляється, що один і той самий алгоритм реалізований у 5 різних сервісах.

📚 Хороший код — це не той, який написали красиво сьогодні.
Хороший код — це той, який команда зможе підтримувати через рік.

А ви використовуєте щось окрім RuboCop для контролю якості коду?

TikTok | Instagram | Telegram