Доброго ранку, друзі! ☕️

Гайда обирати, яка ти кава сьогодні))

#codica_humor

TikTok | Instagram | Telegram

Без вашої допомоги ми не зможемо закрити таски в Jira! Допоможіть розплутувати цей клубок.

Ваше завдання:
Визначте для кожного з п'яти співробітників (Андрій, Марія, Сергій, Наталія, Богдан) їхню роль, дію та точний порядок виконання (від 1 до 5).

🕵️‍♂️ Відомо, що:
Андрій працює у Backend-команді.
Марія працює у QA-команді.
Сергій працює у DevOps-команді.
Богдан працює у PM-команді.
Отже, Наталія працює у Frontend-команді.
Андрій був першим, хто виконав свою дію.
Сергій запустив Deploy.
Марія не запускала Deploy.
QA-фахівець останнім перевірив Production.
PM замерджив зміни у main.
Frontend робив Code Review.
Pull Request був створений раніше, ніж Code Review.
Code Review відбувся безпосередньо перед Merge.
Наталія не була останньою, хто виконував дію.

🤔 Ну що, увімкнете режим Шерлока? Хто зможе першим відновити весь ланцюжок подій без помилок?

Пишіть у коментарях свій варіант (наприклад: «Андрій був 1-м і створив PR» або викладайте одразу весь ланцюжок від 1 до 5)! Подивимося, у кого найкраща логіка 👇

TikTok | Instagram | Telegram

🤯 «Знову впав Redis, і всі фонові таски зупинилися?» або «Скільки можна платити за Sidekiq Pro лише заради базових фіч?»

Якщо ви досі піднімаєте окремий Redis-сервер для обробки фонових задач (Active Job) у Rails-проєктах — у нас для вас хороші новини.

У Rails 8 офіційним дефолтним бекендом для фонових задач став Solid Queue. Тепер фонові черги можуть працювати через вашу основну базу даних (PostgreSQL, MySQL або SQLite) без окремого Sidekiq та Redis.

❓ «Але ж БД повільніша за Redis! База просто впаде від постійних блокувань!» — скаже будь-який Senior-розробник.

Не все так просто! Solid Queue використовує ефективні механізми SQL, зокрема FOR UPDATE SKIP LOCKED, щоб воркери могли забирати задачі з черги без очікування на вже заблоковані рядки.

Як це працює і чому це круто:

1️⃣ Жодних блокувань усієї таблиці

Коли воркер бере задачу з бази, він може заблокувати конкретний рядок. Інші воркери пропускають заблоковані рядки (SKIP LOCKED) і переходять до наступних задач, не чекаючи на звільнення зайнятих.

2️⃣ Менше витрат на інфраструктуру

Вам більше не обов’язково конфігурувати, моніторити та оплачувати окремий Redis-кластер для staging і production. Менше компонентів — простіше розгортання та підтримка.

3️⃣ Транзакційна цілісність (Transactional Jobs)

Можна налаштувати постановку задач у чергу в межах тієї самої транзакції, що й запис бізнес-даних. Якщо транзакція відкотиться (rollback), задача не буде зафіксована в черзі.

Це допомагає уникнути класичної проблеми з Sidekiq/Redis, коли фоновий воркер намагається обробити задачу раніше, ніж транзакція з основними даними буде закомічена.

4️⃣ Підтримка складних сценаріїв із коробки

Solid Queue підтримує:

• Delayed jobs — відкладені задачі.
• Concurrency controls — обмеження паралельного виконання.
• Pausing queues — призупинення черг.
• Recurring jobs — періодичні задачі за розкладом.

🛠 Як спробувати у своєму Rails-проєкті

Gemfile:

gem "solid_queue"

Конфігурація в config/environments/production.rb:

config.active_job.queue_adapter = :solid_queue

Далі встановлюємо конфігурацію та міграції Solid Queue:

bin/rails solid_queue:install

Запускаємо воркери:

bin/jobs

🔥 Підсумок для співбесіди

Solid Queue — це не просто альтернатива Sidekiq. Це крок до простішої архітектури Rails-застосунків, меншої кількості зовнішніх залежностей і нижчої вартості підтримки інфраструктури.

Водночас Sidekiq залишається чудовим вибором для проєктів із високим навантаженням, а продуктивність Solid Queue залежить від конкретної БД, навантаження та конфігурації.

А ви вже перейшли на Solid Queue у Rails 8 чи поки залишаєтесь на перевіреній зв’язці Sidekiq + Redis?

👇 Пишіть у коментарях!

TikTok | Instagram | Telegram

Йо, друзі, з вами наша постійна рубрика #IT_словник

Ми зібрали рідкісні, дивні та абсолютно геніальні слова з усього світу, які ви навряд чи чули, але які на 100% описують будні в розробці. Розширюємо вокабуляр, качаємо софт-скіли, піднімаємо настрій і вчимося витончено тролити колег та ПМ-ів.

Читайте попередні пости рубрики:
📌 "Гігіл" — читати тут
📌 "Торшлюспанік" — читати тут
📌 "Цундзуку" — читати тут
📌 "Айвош" — читати тут
📌 "Калсарікянні" — читати тут

Гортайте нижче, тегайте в коментарях тих, кому це життєво, і погнали! 🔥

«Фершлімбесерн» (Verschlimmbessern) — німецьке слово, яке означає «намагатися покращити щось, але в процесі зробити тільки гірше».

Як це в IT: Класика рефакторингу без тестів. Ти бачиш код, який працює, але написаний криво. Думаєш: «Зараз швиденько зроблю красиво». Прибираєш один костиль — падає база даних, відвалюється авторизація, а проєкт починає горіти.

Сюди ж відносяться ситуації, коли PM заходить на 5 хвилин у таску, щоб «трохи уточнити вимоги», і дедлайн зсувається на місяць.

Як це використовувати в житті: Якщо рука тягнеться переписати старий робочий модуль без чіткого ТЗ, б'ємо себе по руках і пишемо в коментарях до коду: // Не чіпати, тут можливий фершлімбесерн.

Або кажемо менеджеру на пропозицію «покращити дизайн форми за годину до релізу»: «Ні, це приведе до повного фершлімбесерну».

TikTok | Instagram | Telegram