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

💎 Ruby devs, тримаємо курс на прокачку скілів — знову свіжа добірка корисних книжок! #codica_advice Зібрали ще кілька PDF-книг, які допоможуть краще зрозуміти Ruby, Rails і не тільки 📚⚡️ Минулі добірки вже зберегли? 📍 Добірка Ruby-книжок 1 📍 Добірка Ruby-книжок 2 📍 Добірка Ruby-книжок 3 📍 Добірка Ruby-книжок 4 📍 Добірка Ruby-книжок 5 👉 Working with Ruby Threads Threads, concurrency, synchronization та реальні кейси для Ruby-розробки. 👉 RubyFu: Ruby Programming for Hackers У книзі — automation, security, hacking-підходи та цікаві способи використання Ruby поза звичними Rails-проєктами. 👉 Docker for Rails Developers Тут про те, як комфортно використовувати його саме в Rails-розробці. 👉 Ruby Programming for Beginners Просте пояснення базових концепцій, багато прикладів і мінімум «сухої теорії». 👉 Ruby DSL Handbook Книга показує, як будувати красиві, читабельні та гнучкі API у ruby-way стилі. Зберігайте собі і діліться з колегами! TikTok | Instagram | Telegram

#codica_js

#codica_ruby

🚀 Друзі, знайшли цікавий open-source інструмент для тих, хто працює з Claude Code. Claude mem — тулза, яка допомагає краще тримати контекст і не “випадати” посеред довгих задач. 💡 По суті: • менше обривів у роботі • стабільніший workflow • краще запам’ятовування контексту • зручніше для великих проєктів Його вже називають “підсилювачем” для power-користувачів 😄 💬 Друзі, цікаво: ви б таке собі поставили у свій стек чи поки вистачає базового Claude Code? TikTok | Instagram | Telegram

🔹 Scrimba — Learn JavaScript Дуже крутий варіант для новачків. Тут можна одразу писати код прямо всередині уроку, а не просто дивитись відео. ✅ інтерактивне навчання ✅ сучасний JavaScript ✅ маленькі проєкти під час навчання ✅ є безкоштовна версія 💰 Pro: ~$24/міс або ~$294/рік Його зараз дуже часто радять на Reddit і в ком’юніті frontend-розробників. 🔹 javascript.info Мабуть найкращий безкоштовний підручник по JavaScript. Тут реально пояснюють JS нормально: • async/await • DOM • fetch • closures • prototypes • modules Коли пройдете базу — цей сайт стане вашим постійним reference 😄 💰 Повністю безкоштовно Його дуже часто рекомендують навіть досвідчені devs. 🔹 Frontend Masters Це вже більше для тих, хто хоче піти глибше у frontend. Тут дуже сильні курси по: • JavaScript • React • TypeScript • System Design 💰 ~$39/міс або ~$390/рік Його часто називають однією з найсильніших платформ для frontend developers. 🔹 JavaScript30 — Wes Bos 30 маленьких проєктів на чистому JavaScript. Дуже хороший ресурс після бази, щоб: ✅ набити руку ✅ перестати боятись JS ✅ навчитися працювати з DOM і browser API 💰 Безкоштовно Його теж часто радять саме для практики. Ми б радили таку схему: 1️⃣ Scrimba → база 2️⃣ JavaScript30 → практика 3️⃣ javascript.info → поглиблення знань 4️⃣ Frontend Masters → вже для серйозного росту І головне — не проходити 20 курсів одночасно 🙌 Краще один курс + свої маленькі проєкти. Саме практика і GitHub зараз вирішують набагато більше, ніж сертифікати 🚀 TikTok | Instagram | Telegram

Друзі, якщо хочете почати вчитись JavaScript і web development — ось декілька курсів та ресурсів, які ми можемо порадити 💻

Сьогодні — закон, який допомагає тверезо дивитися на тренди 👇 📉 Закон Стерджена “90% усього — це сміття.” (У контексті розробки — більшість інструментів, рішень і ідей не переживають перевірку практикою.) 👨‍💻 Що це означає для розробників • нова бібліотека ≠ краще рішення; • більшість “хайпових” інструментів зникає через рік; • варто перевіряти стабільність, підтримку і реальні кейси використання. 📊 Що це означає для менеджерів • не кожен тренд потрібно одразу тягнути в roadmap; • експерименти важливі, але їх треба ізолювати; • технологічні рішення повинні проходити фільтр практичності. 💡 Живий приклад Зʼявляється новий JS-фреймворк, який “швидший за всіх”. Команда витрачає час на міграцію — а через рік про нього вже ніхто не говорить. У підсумку — більше техборгу, ніж вигоди. Як працювати з цим законом: ✔️ дивитися на ecosystem і community, а не тільки на hype ✔️ запускати spike перед впровадженням ✔️ ставити питання: “Це вирішує нашу проблему чи просто цікаво?” 💬 Стабільність і передбачуваність часто цінніші за найгучніший тренд — особливо у довгоживучих продуктах. TikTok | Instagram | Telegram

🧠 13 законів розробки У світі розробки щодня зʼявляються нові фреймворки, бібліотеки, AI-інструменти та “революційні” підходи. Але досвідчені інженери знають: не все, що голосно звучить, справді приносить користь у реальних проєктах. Закони, які вже розглянули: 👉 Закон Паркінсона 👉 Закон Хофштедтера 👉 Закон Брукса 👉 Закон Конвея (і зворотний закон Конвея) 👉 Закон Каннінгема

Автоматизація в QA давно стала важливою частиною розвитку спеціаліста та якості продукту 🚀 #codica_articles У новій статті наш QA Lead Олексій ділиться своїм досвідом і пояснює, чому автотести — це значно більше, ніж просто написання скриптів. Це про системне мислення, стабільність продукту та вміння бачити якість у довгостроковій перспективі. У картках — практичні думки, досвід з реальних проєктів і речі, які варто знати кожному QA, хто хоче рости в автоматизації 💡 Читайте, зберігайте та діліться своїм досвідом у коментарях! TikTok | Instagram | Telegram

📌 How should you use content_for and yield? 📍 Очікувана відповідь: У Ruby on Rails yield і content_for використовуються для передачі та динамічної підстановки контенту з view-шаблонів у layout. 1️⃣ yield Це маркер-placeholder у layout, куди Rails вставляє скомпільований HTML-код конкретного view.

<!-- app/views/layouts/application.html.erb -->
<body>
  <%= yield %> <!-- Сюди вставиться контент, наприклад, з posts/index.html.erb -->
</body>

2️⃣ content_for Дозволяє передати іменований блок контенту (named block) з view у певне місце в layout.

<!-- app/views/posts/show.html.erb -->
<% content_for :title do %>
  Posts Page
<% end %>

У layout ми викликаємо цей блок за іменем:

<title><%= yield(:title) %></title>

Типові кейси використання: 🔹 Динамічні мета-теги та заголовки:

<% content_for :title, "Dashboard" %>

🔹 Підключення специфічних для сторінки скриптів чи стилів (хоча в епоху Webpacker/Propshaft це робиться рідше). 🔹 Кастомні зони: сайдбари, хлібні крихти (breadcrumbs). ⚠️ Важливі технічні pitfalls: • Накопичення контенту: content_for за замовчуванням конкатенує (додає) блоки, якщо викликати його кілька разів з однаковим ключем. Якщо вам потрібно суворо перезаписати значення (наприклад, перевизначити title в partial), використовуйте метод provide замість content_for. • Продуктивність: Не зловживайте content_for всередині циклів чи великої кількості partials — це створює зайве навантаження на рендеринг у пам‘яті. 👉 yield = місце вставки 👉 content_for = спосіб передати контент у це місце (з можливістю append) 📌 How should you use nested layouts? 📍 Очікувана відповідь: Nested layouts у Rails використовуються для створення ієрархії шаблонів (шаблони в шаблонах). Вони потрібні, коли група сторінок має унікальну структуру (наприклад, адмінка), але повинна залишатися всередині глобального базового шаблону сайту (з тими ж скриптами, мета-тегами тощо). Як це реалізувати правильно (Best Practice): 🏗️ Головний (батьківський) layout:

<!-- app/views/layouts/application.html.erb -->
<html>
<head><title>My App</title></head>
<body>
  <header>Main Header</header>
  <%= yield %>
  <footer>Main Footer</footer>
</body>
</html>

🏗️ Вкладений (дочірній) layout для адмінки. Тут ми огортаємо код у render template::

<!-- app/views/layouts/admin.html.erb -->
<%= render template: "layouts/application" do %>
  <div class="admin-panel-wrapper">
    <aside>Admin Sidebar</aside>
    <main>
      <%= yield %> <!-- Сюди вставиться конкретний view адмінки -->
    </main>
  </div>
<% end %>

У контролері ми просто вказуємо дочірній layout:

class Admin::BaseController < ApplicationController
  layout "admin"
end

Результат: Rails спочатку відрендерить view всередині admin.html.erb, а потім отриманий результат передасть як блок у application.html.erb. Типові кейси використання: 🔹 Окремі кабінети (Admin / Dashboard / Налаштування профілю) зі своїми сайдбарами. 🔹 Мультілендінги в межах одного застосунку зі спільними assets, але різною структурою секцій. ⚠️ Важливо: • Уникайте глибокої вкладеності (більше 2 рівнів). Код стає «спагеті», і логіку рендерингу важко дебажити. • Якщо дочірній шаблон відрізняється лише парою блоків, краще використати content_for або render partial, аніж плодити новий вкладений layout. 👉 Nested layouts — це побудова ієрархії інтерфейсу через:

render template: "parent_layout" do
  ...
end

🎯 Професійний підхід: yield і content_for — для керування атомарним контентом у межах одного layout. Nested layouts — для побудови архітектурної ієрархії інтерфейсу без дублювання базового HTML. 🚀 Ну і нехай ваші layout’и будуть такими ж чистими, як CI після green build 🚀 TikTok | Instagram | Telegram

❓ Як відповідати на запитання на співбесіді? #codica_interviews ❌ Суха теорія, яку можна загуглити за 5 секунд — не ок ✅ Пояснити на пальцях, дати код і підсвітити граблі — ок

Сьогодні — День скорботи і вшанування пам’яті жертв війни в Україні. День тиші, болю та пам’яті про всіх, чиї життя забрала війна. Ми пам’ятаємо кожного. Цінуємо силу тих, хто бореться. І дякуємо тим, завдяки кому маємо можливість жити, працювати та мріяти. Світла пам’ять загиблим. Слава Україні! Героям слава! 🇺🇦 TikTok | Instagram | Telegram

Англійська за мемами😜 👉 Говоримо красиво 📍 soulmate – споріднена душа 📍 have the heart – мати сміливість (або “мати серце”, залежно від контексту: на щось наважитися або бути достатньо добрим/співчутливим) #codica_english TikTok | Instagram | Telegram

Друзі, всім ясного та натхненного вихідного ✨ Зібрали для вас підбірку про дизайн. Саме те, щоб провести вихідні з користю 🎨 #codica_weekend ➡️ Уроки Adobe Illustrator Аж 35 уроків українською мовою — повний буст від нуля до впевненого рівня. ⏱ Тривалість — серія уроків ➡️ Як я навчився друкувати ДУЖЕ швидко (400+ с/хв) Покажуть, як вийти на космічну швидкість набору тексту. ⏱ Тривалість — 6 хв ➡️ Уроки PowerPoint Як робити не нудні, а сильні презентації: структура, візуал і подача, яка тримає увагу. ⏱ Тривалість — 45 хв (серія уроків) ➡️ Безкоштовний курс з Webflow Навчишся створювати адаптивні сайти без коду і зрозумієш, як дизайн перетворюється в готовий продукт. ⏱ Тривалість — серія уроків ➡️ Figma українською — курс Ідеально, щоб зайти в UI/UX або систематизувати знання по Figma. ⏱ Тривалість — серія уроків Нехай ці вихідні будуть з хорошим вайбом, новими ідеями та смачною кавою і обов’язково — трохи відпочинку поруч з тими, хто заряджає ❤️ TikTok | Instagram | Telegram

Fat model / Fat controller: коли клас росте швидше за проєкт Якщо у вас є модель на 1200+ рядків або контролер, який “трошки робить усе” — цей пост для вас 🙂 У Rails легко почати красиво. Але з часом у модель додається: • бізнес-логіка • інтеграції • callback-и • валідації • формування JSON • умовні переходи станів І раптом один клас починає вирішувати пів проєкту. Ми всі через це проходили 🙂 👉 У чому проблема 🔹 Код важко читати 🔹 Логіка розмазана 🔹 Тести стають складними 🔹 Будь-яка зміна ламає щось несподівано 🔹 Новому розробнику потрібно пів дня, щоб зрозуміти “що тут відбувається” Модель перетворюється на “божественний об’єкт”. 👉 Чому це трапляється саме в Rails Rails заохочує логіку в моделях. І на початку це правильно. Але: ActiveRecord ≠ місце для всієї бізнес-логіки. Модель відповідає за дані. А не за весь життєвий цикл домену. Як зрозуміти, що вже “fat” • файл важко прогорнути • методи не пов’язані між собою • з’явились 5+ callback-ів • модель знає про зовнішні API • ви боїтесь її чіпати 👉 Що робити замість цього 1️⃣ Service objects Виносимо бізнес-логіку:

ruby 
class CreateOrder
  def call(params)
    ...
  end
end

2️⃣ Query objects Складні запити — не в модель. 3️⃣ Form objects Особливо для складних форм і multi-step flows. 4️⃣ PORO (Plain Old Ruby Object) Не все повинно бути ActiveRecord. 👉 Маленьке правило Якщо метод не працює з полями моделі напряму — можливо, він не повинен бути в ній. Який найбільший файл моделі ви бачили? І скільки там було рядків? 😄 TikTok | Instagram | Telegram

Друзі, розбираємо Rails 👇 І продовжуємо нашу серію з 7 постів для RoR, де дивимось на типові проблеми продакшену 🙂 Попередні пости серії: 📍 Rails без магії: 7 помилок, які роблять навіть мідли 📍 Background jobs: чому “просто Sidekiq” — не завжди просто 📍 Transactions у Rails: чому “і так працює” — небезпечна ілюзія 📍 DB constraints: чому Rails validation — це не гарантія #codica_advice