📚 Рубі‑книги + PDF! Безкоштовно!

#codica_advice

👉 Друзі, ми підготували ще одну добірку крутих книг по Ruby та Rails!
👉 Тепер читати їх можна безкоштовно, зручно і в будь-який час.

📌 Добірка Ruby-книжок 1
📌 Добірка Ruby-книжок 2

📌 The Rails 8 Way
– детальний гайд по Rails 8 з практичними прикладами та сучасними підходами до розробки.

📌 High Performance PostgreSQL for Rails: Reliable, Scalable, Maintainable Database Applications
– навчись створювати швидкі, масштабовані та надійні бази даних для Rails-проектів.

📌 Rails on Containers
– дізнайся, як ефективно запускати Rails-додатки у контейнерах та облаках.

📌 From PHP to Ruby on Rails
– чудовий гід для тих, хто хоче перейти з PHP на Ruby on Rails без зайвого стресу.

📌 Ruby Data Structures and Algorithms
– поглиблене вивчення структур даних та алгоритмів у Ruby для оптимізації коду та ефективності програм.

Зберігай цей пост, щоб не загубити посилання 📌

TikTok | Instagram | Telegram

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

Друзі, погодьтесь, іноді здається, що розробка це лише про код. Але якщо подивитись чесно, більшість складнощів виникає не в рядках коду, а в часі, очікуваннях і плануванні.

Тому запускаємо невелику серію – про закони, які програмісти й менеджери проживають щодня, навіть якщо не завжди називають їх вголос.

Сьогодні – один із найвідоміших 👇 І ви точно про нього чули

Закон Паркінсона

“Робота заповнює весь час, відведений на її виконання.”

Що це означає для розробки?
Якщо на задачу дали 5 днів – є великий шанс, що вона займе всі 5, навіть якщо технічно могла бути готова за 2.

👨‍💻 Для розробників
• починається зайвий рефакторинг “бо є час”;
• з’являється overengineering;
• дедлайн здається далеким і старт відкладається.

📊 Для менеджерів
• оцінки розтягуються;
• складно зрозуміти реальну швидкість команди;
• roadmap стає менш прогнозованим.

💡 Живий приклад
Задача: “додати простий фільтр”.
Оцінка – 3 дні.
Факт:
день 1 – дослідження,
день 2 – переписати сервіс “бо можна краще”,
день 3 – власне фільтр 🙂

Як з цим працювати:
✔️ дробити задачі на менші
✔️ ставити проміжні чекпоінти
✔️ домовлятись про definition of done, а не “ще трохи покращу”

Цікаво, чи ловили ви себе на Законі Паркінсона в реальних проєктах? 👀
Далі буде ще цікавіше – у серії попереду 12 законів розробки

TikTok | Instagram | Telegram

Rails magic: чому “воно саме працює” – найдорогоцінніша пастка 😈

👉 Rails люблять за швидкість і комфорт. І так, частина магії – це реально сила: conventions, генератори, ActiveRecord, автозавантаження – усе це економить час.

👉 Але є момент, який майже кожен проходив: спочатку Rails “все робить сам”, а потім одного дня ти ловиш баг/гальма/дивну поведінку і розумієш, що не знаєш що саме він робить під капотом.

І це норм. Ми всі так робили 🙂

Де “магія” найчастіше б’є по проєкту:
1. N+1 та eager loading
Запитів у базу стає 200 замість 2 і це не “повільний сервер”, а типова історія з асоціаціями.

2. Callbacks з побічними ефектами

after_save

“трошки відправляє лист”, “трошки створює записи”, “трошки штовхає джобу” і з часом ти вже не можеш пояснити, чому щось запускається двічі.

3. Validations без гарантії в БД

validates :email, uniqueness: true

виглядає як гарантія, але без

unique index

це лише “майже завжди”.

4. Time zones / serialization / params
Rails може дуже зручно кастити дані… і так само зручно створити “невидимі” баги на межі типів/часу/форматів.

Як тримати Rails під контролем?
• Дивись у SQL:

ActiveRecord

крутий, але істина – у запитах.
Звичка: інколи відкривати логи або використовувати

EXPLAIN

• Менше магії там, де болить: критичні флоу роби максимально явними (особливо фінанси, доступи, інтеграції).

• Тестуй поведінку, а не “віру”: тести мають ловити не лише “працює”, а й “не робить зайвого”.

• Пам’ятай піраміду тестів: більше unit/інтеграційних, менше UI-E2E і менше ілюзії, що “все під контролем”.

Міні-правило, яке рятує нерви:
Якщо ти не можеш за 10 секунд пояснити чому код спрацьовує – значить там уже з’явилась “магія”, яку пора зробити явною.

TikTok | Instagram | Telegram