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

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

Зберігайте, бо деякі самі заберемо собі в нотатки 👇

🔹 /godmode — попросити Claude видати максимально сильну й рішучу версію відповіді.

🔹 /devil — змусити модель розібрати протилежну позицію й знайти слабкі місця у вашому рішенні.

🔹 /10x — прокачати ваш драфт: зробити hook гострішим, логіку чистішою, а результат сильнішим.

🔹 /compare — порівняти два рішення за конкретними критеріями: cost, speed, risk, complexity, upside.

🔹 /scout — пошукати ризики, edge cases, конкурентів, blind spots і потенційні точки провалу.

🔹 /critique — знайти слабку логіку, незрозумілі місця та непідтверджені твердження й одразу запропонувати фікси.

🔹 /ooda — розкласти складну задачу через Observe → Orient → Decide → Act.

🔹 /brief — стиснути відповідь до найкориснішої суті. Наприклад: 5 bullets, максимум 100 слів.

🔹 /explainlikeim5 — спочатку пояснити максимально просто, а потім поступово додавати технічну глибину.

🔹 /teacher — перетворити Claude на ментора, який спочатку ставить питання й змушує вас подумати, а вже потім дає відповідь.

🔹 /artifacts — попросити зібрати prototype або інтерфейс прямо в чаті.

Для розробників особливо цікаві /critique, /compare, /scout, /teacher та /10x.

Сама команда — лише старт. Додавайте до неї контекст, критерії, обмеження, приклади й очікуваний формат результату.

Коротше, зберігайте собі цей маленький набір «заклинань» для Claude 🧙‍♂️
І тисніть реакцію на цей пост, якщо корисно))

TikTok | Instagram | Telegram

Коли React-проєкт стає складнішим: 4 інструменти, які варто знати

Продовжуємо нашу рубрику для JavaScript та React-розробників!

Минулі частини:
🔹 Частина 1 — репозиторії для прокачування скілів
🔹 Частина 2 — девтулзи, які забирають рутину
🔹 Частина 3 — маловідомі бібліотеки для реальних задач

Цього разу підготували добірку інструментів для задач, де звичних React/TypeScript-підходів уже може бути недостатньо: складні UI-флоу, велика кількість станів, типізована бізнес-логіка та accessibility.

📌 XState — коли UI-логіка перетворюється на складний набір станів і переходів

isLoading, isError, isSuccess, isRetrying...

Зі зростанням кількості сценаріїв керувати такою логікою стає дедалі складніше. Особливо у формах, checkout-флоу, авторизації чи багатокрокових процесах.

XState дозволяє описувати поведінку застосунку через state machines та statecharts: які стани існують, які переходи між ними можливі та що має відбуватися під час переходу.

Це зручно для складних сценаріїв, які потрібно підтримувати й тестувати протягом тривалого часу.

🔗 Дивитися XState

📌 ts-pattern — pattern matching для TypeScript

У великих TypeScript-проєктах часто доводиться працювати з union types:

type Result =
  | { status: "loading" }
  | { status: "success"; data: User[] }
  | { status: "error"; message: string };

ts-pattern дозволяє описувати такі сценарії через pattern matching, а за допомогою .exhaustive() — перевіряти на рівні TypeScript, чи всі можливі варіанти були оброблені.

Додав новий тип у union — TypeScript допоможе знайти місця, які потрібно оновити.

Особливо корисно для reducer’ів, API-відповідей, state machines та складної бізнес-логіки.

🔗 Дивитися ts-pattern

📌 React Aria — accessibility для власного UI

Власний Modal, Select, Combobox чи DatePicker швидко виходить за межі звичайної верстки.

Потрібно продумати keyboard navigation, focus management, screen readers, ARIA-атрибути та різні сценарії взаємодії.

React Aria від Adobe надає unstyled components і низькорівневі hooks, які беруть на себе значну частину accessibility та interaction logic, залишаючи команді контроль над стилями й структурою UI.

Цікавий варіант для команд, які будують власну дизайн-систему.

🔗 Дивитися React Aria

📌 Effect — для складної TypeScript application logic

Effect варто розглядати, коли застосунок має багато асинхронних операцій, залежностей, помилок і складної бізнес-логіки.

Бібліотека працює з typed errors, dependency injection, structured concurrency, retries, resource management і schema validation.

Підхід досить незвичний, тому Effect цікаво хоча б розібрати на рівні архітектури — особливо якщо працюєте з великими TypeScript-системами.

🔗 Дивитися Effect

💬 Який із цих інструментів ви вже зустрічали у production?

А якщо у вашому стеку є бібліотека, яку варто додати в наступну частину, — кидайте назву в коментарі. 👇

TikTok | Instagram | Telegram