Codica - корисне про IT

🧠 Це не баг — це історія

Квіз з історії програмування та технічної спадщини, яка досі впливає на наш код 🚀

Ви вже знаєте цей формат і, здається, трохи його любите 😉

Тож час знову перевірити себе: чому іноді найдивніші рішення виявляються найживучішими?

Гайда вгадувати!

TikTok | Instagram | Telegram

Ми тут знайшли справжній скарб для тих, хто давно хотів розібратися в Computer Science 👀

Безкоштовна добірка курсів від MIT, Stanford, Princeton та інших топових університетів — зібрана в карту навчання.

🔗 github.com/ForrestKnight/open-source-cs

Забирайте в закладки. Можливо, це саме той ресурс, який ви давно шукали ❤️

#codica_advice

TikTok | Instagram | Telegram

#codica_js

#codica_ruby

📌 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

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

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

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

#codica_advice

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

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

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

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

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

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

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

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

TikTok | Instagram | Telegram

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

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

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

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

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

💼 Чому одні проходять випробувальний термін легко, а інші стикаються з труднощами вже в перші місяці?

#НапуттяВід_HR Директорки Клименко Наталії

Наталя, HR Director, яка за роки роботи в IT супроводжувала сотні probation-періодів, ділиться інсайтами з практики.

У цьому матеріалі — реальні поради про адаптацію, комунікацію з командою та кроки, які допоможуть закріпитися на новій позиції.

Зберігайте та гортайте далі 👉

TikTok | Instagram | Telegram

📌 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