Зараз глибоко копаю в Harness Engineering і маю дуже багато інфи, якою час від часу буду ділитись 😁

Ловіть один з крутих ресурсів для початківців (і не тільки).

Всередині: instructions, tools, state, feedback, verification, agent loops, graph engineering + розбори того, як побудовані harness в Claude Code, Codex, DeepSeek та Pi.

Є практичні проєкти, шаблони і навіть українська локалізація 🇺🇦👹

📎 - https://github.com/walkinglabs/learn-harness-engineering

Дуже багато відповіли, що Promise виконає обчислення в окремому потоці 🚬

Треба робити відео про Promise і в цілому про асинхронність в Node.js 📹🤌

Ще одне практичне застосування Jev - jevgrep 🤯☕️

Це інструмент для пошуку потрібного коду в репозиторії за допомогою Jev.

Ідея доволі проста

Замість того, щоб змушувати Claude/Codex витрачати токени на пошук потрібних файлів, ця брудна робота лягає на дешевий Jev.

Це якраз те, що я казав в відео про Jev. Не обовʼязково використовувати LLM для кожного кроку і частину простих рішень можна віддати маленькій спеціалізованій моделі.

🔗 - https://github.com/dzhng/jevgrep

Цікаве оновлення в Nest.js 🔥

Вони випиляли Axios з HTTP клієнта і тепер використовують native fetch.

З плюсів, які вони вказують:

- Немає залежностей
- Retry доступний по замовчуванню
- Timeouts, cancellation, interceptors
- Краща обробка помилок
- Випиляли Observable 🥹

В цілому - це круте оновлення, як через відсутність залежностей так і меншу імовірність зловити критичну вразливість, як це недавно було з Axios

📎 - https://docs.nestjs.com/application/http-client

Terragrunt — коли Terraform стає замало ☕️☕️☕️

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

Яку проблему він вирішує?

Уявіть, що у вас є декілька середовищ: dev, staging та prod. У кожному з них розгорнуті певні ресурси.

Якщо у вас моноліт, все доволі просто. Ви створюєте окремий Git репозиторій cloud-infra, у якому описуєте всю інфраструктуру за допомогою Terraform, а для розділення середовищ використовуєте Workspaces.

Але уявімо, що ваша система поступово переходить до мікросервісної архітектури. Кількість ресурсів зростає, а централізована Terraform конфігурація стає "жирною".

Тому інфраструктуру часто розділяють на незалежні Terraform конфігурації.

Наприклад, спільну інфраструктуру залишаємо в cloud-infra. А оскільки кожен мікросервіс має власний репозиторій, у ньому також можна розмістити Terraform конфігурацію для ресурсів, які належать конкретному сервісу: PostgreSQL, Redis, S3 тощо.

Таким чином, кожен мікросервіс може мати власний Terraform State, незалежний від state інших сервісів та спільної інфраструктури.

І в багатьох випадках такого підходу цілком достатньо.

Але зі зростанням складності інфраструктури можуть виникнути нові проблеми.

Наприклад, вам потрібно розгорнути ресурси в певному порядку, але вони описані в різних Terraform конфігураціях і мають окремі State.

Або один мікросервіс залежить від інфраструктури іншого, тому перед його розгортанням потрібно переконатися, що всі необхідні ресурси вже створені.

Частіше всього, тут починається побудова кастомних велосипедів, які максимально костильно забезпечують оркестрацію ресурсів 😁

І якраз тут можна використати Terragrunt

Фактично, це інструмент, який працює поверх Terraform та дозволяє оркеструвати незалежні проєкти з окремими state.

Не буду детально розписувати всі його можливості, адже, як на мене, набагато важливіше зрозуміти проблему, яку він вирішує 🤌

Дуже коротко про основні фічі:

- Повторне використання спільних конфігурацій без копіювання між середовищами та різними Terraform проєктами

- Управління залежностями між незалежними проєктами та порядком їх розгортання

- централізоване керування і оркестрація

- зручна організація конфігурацій для різних середовищ (коли workspaces не стає мало).

В своєму досвіді, я тільки раз працював з ним - це був великий enterprise продукт з величезною інфрою. Він там ідеально вписувався, так як дійсно спрощував життя і перекладав операційні проблеми на рівень DevOps, а розгортання потрібної інфри на інженерів

🔗 - https://terragrunt.gruntwork.io/

І саме головне питання, треба відео по ньому? 📹

Без коду, а більше огляд його можливостей на архітектурном рівні з життєвими прикладами.

Нове відео на каналі 🔥

Цього разу розібрав Obsidian і спробував відповісти на головне питання — чи може він реально стати мозком проєкту, особливо якщо підключити до нього AI-агентів.

У відео коротко про Vault, Links, Backlinks, Graph, Search, а також про головну проблему — що буде, коли документація почне деградувати й забруднювати контекст.

https://www.youtube.com/watch?v=1ibaFK8YHW4

Хочу поділитися цікавим українським проєктом — Дрони на районі 🇺🇦

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

Окрім практичної цінності, для вас як інженерів буде цікаво подивитись технічну реалізацію такого проєкту. Тут немає технологій заради технологій, а натомість все зроблено максимально просто з використанням Python, htmx, SQLite, Docker Compose і домашнього сервера.

І в цілому, автор ділиться не лише стеком, а й реальними інженерними рішеннями. Наприклад, чому звичайного uptime-моніторингу недостатньо, як контролювати актуальність даних і де AI справді приносить користь 🤌

Добрий ранок ☕️

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

Щоб узяти участь у розіграші, напишіть у коментарях network, ваш нік, наприклад network, @o_kazm.

Важливо
Книгу можемо відправити лише в межах України.

Розіграємо її 15.10.2026.

Не соромтеся ділитися розіграшем зі своїми друзями 😁