Обіцяний відео-розбір на каналі вже завтра.

Учора вийшло оновлення на NotebookLM, яке дозволяє робити аудіо-огляди багатьма мовами, в тому числі й українською.

Не знаю, чи це частина цього оновлення, або вони це виправили раніше, але тепер, щоб отримати доступ до цього інструмента з України, не потрібно вмикати VPN.

Я прикріпив згенерований подкаст на основі відео Бабича. Це звучить чудово!

А всього два місяці тому я тестував створення аудіо українською мовою та на ринку не було нічого якостного. За два місяці ми маємо українську у OpenAI та Google.

👀 https://youtu.be/rZSydNEcrR4

Учорашнє відео містить одну з ключових думок про те, що нам потрібно вміти створювати код з різною швидкістю/якістю.
Це вміння змінювати швидкість під завдання важливе в усіх сферах життя… Тут я зупинюся, бо починаю цитувати: "Thinking, Fast and Slow” by Daniel Kahneman.

За останній рік завдяки AI-інструментам я навчився краще управляти швидкістю вивчення нових інструментів/бібліотек.

Ось що дозволяє рухатися так, як я звик та як воно було до AI:
1️⃣ Learning by doing
2️⃣ Reading standart documentation
3️⃣ Video about the tool from courses/conferences

Ось що дозволяє рухатися deep&slow:
1️⃣ Several Deep research in your LLM: Best practices, alternatives, known <tool> problems and best practises to resolve them
2️⃣ The tool source code review. AI helps with navigation, explanation, etc
3️⃣ Best practise creation about this tool. Part of my consulting, so i review this with other experts.

Ось що дозволяє рухатися швидко:
1️⃣ Prompt for your LLM: There is documentation … Split it in 5 bitesize lessons with quize at the end. Start with the first lesson and based on quize explaine me what i missed.
2️⃣ GitDiagram. Example https://gitdiagram.com/nestjs/nest
3️⃣ DeepWiki. Example https://deepwiki.com/nestjs/nest

а які інструменти ви використовуєте для навчання? Які курси відвідуєте?

Хочу нагадати вам про дві речі:
1️⃣ Маніфест 12 факторів говорить: Store config in the environment
2️⃣ process.env — це не звичайний JavaScript об’єкт, а обгортка над C++ кодом, яка забезпечує доступ до змінних середовища на системному рівні.

Тому кешуйте доступ до process.env через проміжну змінну, а не звертайтесь до нього при кожному запиті до вашого API.

У цьому допоможуть:
- NestJS: Cache environment variables
- ESLint-правило n/no-process-env

Цікава переписка про learning by doing в сучасних умовах.

Ось ще один цікавий скріншот. Колега з США тестує моделі цим промптом (підкресленим червоним), щоб перевірити, наскільки модель ерудована. На скріншоті використовується terminal з llm.datasette.io

Через два дні стартує віртуальна конференція від O’Reilly – Coding with Al: The End of Software Development as We Know It. Контент - як це часто буває зараз – предзаписаний і буде транслюватися у стрімі.

Ось три причини, чому я буду дивитися:
1️⃣ Гаряча тема і гучні імена. Спікери – ті, хто формує тренди. Той самий Едді Асмані не потребує представлення.

2️⃣ Формат – лайтнінг-доповіді. Не затяжні 45 хвилин, а короткі, концентровані виступи. Це набагато складніше, ніж здається – за кілька хвилин донести суть без права на помилку.

3️⃣ Класна підбірка рекомендованої літератури. Все заточено під O’Reilly-каталог, а 10-денного безкоштовного тріалу вистачить, щоб осилити одну-дві топові книги. Та й, будемо чесні, вас не треба вчити, як обійти обмеження 😏

🎥 Якщо пост набере 100 вогників – зроблю відеоогляд найцікавішого з конференції.

Я дивлюсь – приєднуйтесь

Сьогодні у нас на каналі новий формат #Smells_Like_Failure.

Правило гри: я викладаю контент, який на перший погляд здається правильним, але в ньому є концептуальна помилка. Коментар з першим правильним описом помилки отримує підписку на JetBrains IDE.

Сьогодні контент — це LinkedIn пост, який я знайшов у себе в стрічці.
—
У нас є переможець!
Рекомендація другові мала бути такою:
Слухай, я бачу за часом відповідей від сервера, що у вас не налаштований кеш для AI запитів. Ви можете витратити багато грошей, якщо будуть надсилатися одні й ті ж запити. Додавання кешу дозволить вам бути більш економними.

📢 ADK Хакатон від Google Cloud

Відкрито реєстрацію на Agent Development Kit Hackathon. Учасники будуть створювати мультиагентні системи для вирішення задач у сферах автоматизації процесів, взаємодії з клієнтами, генерації контенту та ін.

💼 Призовий фонд: $50,000
📅 Подання заявок: з 12 травня по 23 червня 2025 року

🛠 Спробувати ADK можна вже зараз.
ℹ️ Повна інформація про хакатон з’явиться наступного тижня.

Інформацію про хакатон оголосили на Monthly GDE Call.
Я поставив запитання: чи можна буде використовувати Genkit, чи лише ADK?
На жаль, лише ADK. Шкода, адже Genkit має підтримку TypeScript та нім в мене є продакшн-досвід
А ADK вийшов лише місяць тому і поки що доступний тільки для Python.

Я пам’ятаю, що обіцяв зробити огляд Coding with Al конференції – обов’язково виконаю це, щойно отримаю доступ до всіх записів. Декілька виступів я ще не встиг переглянути, тому, як і ви, чекаю відкриття матеріалів.

👀Перше враження
Назва конференції Coding with AI: The End of Software Development as We Know It не зовсім відповідає змісту. 100% доповідей стосувалися власне коду. Натомість теми, без яких ми не уявляємо повного циклу розробки — постановка завдань, збір вимог, найм команди, комунікації, перевірка гіпотез, user experience, аналітика даних — фактично не розкривалися. Тому логічніше було б назвати її The End of Coding as We Know It.

⭐️Speaker, який став відкриттям
Справжнім відкриттям для мене став виступ Гарпера Ріда «My LLM Codegen Workflow at the Moment». Поки немає відео, раджу зазирнути до його блогу – там уже є частина матеріалів із презентації: Harper Reed’s Blog.

⚙️Практичний міні-флоу, який я вже впроваджую:
1. Conversational LLM ставить лише по одному yes/no запитанню за раз.
2. Після серії питань LLM генерує специфікацію у файлі spec.md.
Це допомагає швидко 🚀 уточнювати вимоги й одразу фіксувати їх у структурованому форматі.
—
UPDATE: Прислали запис. Check your email

Ну що, панове backend-розробники, до списку інструментів Node.js/AI/CloudNative я з чистою совістю можу додати TypeSpec.
Минулого тижня Microsoft випустила TypeSpec 1.0 GA

Чому це важливо?
Розширений список 12+3 факторів включає API First Factor.
Саме TypeSpec є тим інструментом, за допомогою якого зручно та швидко дизайнити ваш API.

Тому раджу прочитати анонс і спробувати TypeSpec. Cпочатку на вашому pet проєкті, а потім, хто знає, можете інтегрувати в процеси розробки на комерційному.

Більшість моїх записів присвячені моєму особистому досвіду, заснованому на роботі в стартапах. Проте я цікавлюся трендами, пов'язаними з enterprise, де Angular популярніший за React, а Java більше використовується, ніж Node.js.
Тому сьогодні я хочу поділитися з вами посиланням, яке буде корисним для тих, хто працює саме на enterprise проєктах.

Open Micro Frontend Platform – OpenMFP

Чим цікавий проєкт?
- запущений лише 2 місяці тому
- фінансується Європейським Союзом
- створений за підтримки компанії SAP

А ще це частина Apeiro-Reference-Architecture, де можна прочитати слоган

Unify your services from hardware to software with Kubernetes' declarative power, across any cloud and edge!

Чи став би я зараз використовувати цей проєкт? Ні. Але подивитися на задачі, які виникають у ході цього проєкту, та їхні рішення – це точно хороший спосіб стати кращим інженером. А ще, поки є такі проєкти, жоден AI нас точно не замінить.

Сьогодні прийшов імейл, що мою участь у програмі AWS Community Builders продовжено на наступний рік.

Заради цікавості я зайшов подивитися в директорію, скільки у нас білдерів з України. Їх шість. У 2024 та 2025 роках не додалося жодного нового учасника. Це сумно, адже участь у програмі для людини, що створює контент щодо Cloud-ів, одна з найпростіших.
UPDATE: Виявляється, що я не правий. В коментарях знайшовся учасник програми 2025 року. Мабуть, ще не оновили директорію.

Тому пропоную вам написати за цей рік декілька одиниць контенту з AWS/Cloud в зручному для вас форматі. Щоб коли відкриється наступна хвиля заявок у січні 2026 ви мали що подати.

Сподіваюся, ви скористаєтеся участю в цій програмі, бо воно того варте.

Як ефективно зменшити трафік у WebSocket-додатках?

Уявіть собі, що у вашому застосунку кілька разів на секунду мають надходити повідомлення

{ “timestamp”: 1747008028, “price”: 997.538642664439 }

Як тут краще організувати серіалізацію payload-у?

1️⃣ Чому розмір payload має значення?
- Менший пакет → коротший TTFB і менше затримок.
- Економія трафіку = нижчі витрати на інфраструктуру та швидший фронтенд.

2️⃣Порівняння розмірів повідомлень
- JSON-об’єкт {timestamp, price} – 49 byte
- JSON-об’єкт {t, p} – 37 byte
- JSON-кортеж [t,p] – 29 byte
- Protobuf – 15 byte

3️⃣ permessage-deflate (RFC 7692)
- WS мають вбудоване стиснення яке активується у фазі HTTP Upgrade: браузер пропонує, сервер вирішує.
- Алгоритм — DEFLATE (zlib); стиснення «повідомлення-за-повідомленням».
Приклад

new WebSocketServer({
port: 8080,
perMessageDeflate: {
threshold: 1024, // не стискати < 1 KB
clientNoContextTakeover: true, // менше пам’яті
serverNoContextTakeover: true
}
});

4️⃣ Коли вигідно стискати, а коли ні
- Великі JSON (>1 KB) - економія 70-90%, але навантаження на CPU
- Часті дрібні котирування (< 200 😎 - економія ~0%, бо заголовок DEFLATE «з’їдає» вигоду
- Protobuf – простіше вимкнути

👉 Висновки
- Оптимізація payloads нагадує оптимізацію зберігання в MongoDB.
- Перехід з JSON-object → JSON-array → Protobuf вже зменшує пакет у ≈3 р.
- Якщо потрібна читаємість разом з помірним зменшенням трафіку - {t,p} непоганий компроміс.
- Для максимальної продуктивності в стрімах котирувань усе ще лідирує бінарний формат (Protobuf)

Два місяці тому на Soft Skills fwdays’25 Сергій Немчинський зробив доповідь, у якій підкреслив важливість Estimations для бізнесу. Потім ця тема активно обговорювалася в кулуарах і в LinkedIn.

Візія Сергія:

оцінювання ефективніше проводити не в story points, а в “півднях” (half-days). Таски при цьому мають бути нарізані від півдня до максимум двох днів. Якщо більше - дробити. Якщо менше - об’єднувати.

Як навчитись оцінювати? У людини один мозок — і для роботи, і для побуту. Тож оцінку часу можна (і варто) тренувати завжди. Йдеш у магазин — прикинь, скільки це займе, і порівняй реальний результат із прогнозом. Це вже практика.

Моє бачення питання Estimations:
1️⃣ Самі творці Scrum відмовились від оцінок у їхньому класичному вигляді.

Estimating tasks will slow you down. Don’t do it… No estimation at all will improve team performance over hour estimation.

Jeff Sutherland, співзасновник Scrum і автор Agile Manifesto
2️⃣Відсутність процесу оцінювання ≠ відсутність обговорення задач і усунення невизначеностей.
3️⃣Бізнесу потрібні не оцінки, а предиктабельність (predictability).
Вона досягається тоді, коли задачі дрібні, зрозумілі, і їх регулярно доставляють у продакшн.
Детальніше у книжці NoEstimates.
4️⃣Інженер може дати адекватну оцінку тільки при фіксованому бізнес-скоупі та стабільному технічному стеку. Але заморожувати скоуп і стек - це гальмувати бізнес. І майже ніхто на це не піде.
5️⃣Бізнесу справді потрібні оцінки лише тоді, коли є кілька варіантів реалізації фічі, і вибір залежить від ресурсів. Але практика показує, що краще зробити A/B тест і подивитись на реакцію користувачів, а не гадати.

Ще раз – дрібні задачі, швидкий фідбек від команди та бізнесу ось наш реальний delivery framework.
📌 До речі, практика нарізки бізнес-фіч на дрібні delivery-орієнтовані задачі існує ще з 2016 року
А з появою AI вона почала допомагати не лише бізнесу, але й інженерам, які можуть у AI tools.

👉 Резюме
Згоден із Сергієм у тому, що задачі мають бути правильно нарізані.
А от витрачати час на оцінювання — особливо в динамічному середовищі — мені здається зайвим.

🧠 VS Code стає відкритим AI-редактором

Цього тижня буде спекотно від новин для розробників: одразу дві топові конференції – Microsoft Build і Google I/O – проходять паралельно. Перша новина від Microsoft – команда VS Code оголосила:

GitHub Copilot Chat стане open source під ліцензією MIT, а ключові AI-фічі поступово інтегрують у ядро редактора.

Моя особиста думка – це продовження курсу на відкритість. Нагадаю ще 3 місяці тому Microsoft анонсувала Language Server Protocol (LSP) для GitHub Copilot, щоб спростити інтеграції в інших IDE та дати розробникам більше прозорості. У довгостроковій перспективі ці обидва кроки надають домінуючу позицію.

Чому це важливо:
- AI вже не плагін – це ядро девелопменту.
- VS Code офіційно трансформується в AI-платформу з відкритим кодом, і Microsoft запрошує спільноту долучатися
- iteration plan та FAQ.


Що далі:
– Open source Copilot Chat
– Інтеграція AI-компонентів у core VS Code
– Відкриття інфраструктури для prompt-тестування

І на завершення, вірусне зображення OpenAl acquires Windsurf

Як AI змінює інтернет?

Десятиліттями інтернет працював за простою моделлю: користувач → пошуковик → сайт. Люди отримували відповіді, сайти – трафік, а творці контенту мали стимул створювати більше. Саме так і працював вільний веб.

Але генеративний AI (ChatGPT, Gemini, Claude) змінює гру: відповіді з’являються без переходів на сайти. Контент поглинається, але нічого не повертається авторам – ні переглядів, ні грошей.

Парадокс:
✍️ Ручне створення якісного контенту – дороге і повільне
🤖 Генеровання AI-контент – швидке і дешеве, але часто поверхневе.
🧠 І при цьому, AI вчиться та генерує відповіді на основі саме ручного контенту, який створили люди – навіть якщо моделі були дистильовані чи донавчані на проміжних репрезентаціях, їхня база все одно – ручна людська робота.

Без нових джерел знань AI почне "висихати". Ми вже бачимо перші ознаки цього – контент повторюється, втрачається глибина, а сенс розчиняється.

🎯 Що робити?
Розробники краще розуміють технічні ризики, ніж бізнес. І саме ми маємо запропонувати рішення, як захистити контент у нову епоху AI:
1️⃣ Додавай структуровані дані
Використовуй schema.org, OpenGraph, JSON-LD – це робить автора видимим для пошуковиків і AI.
2️⃣ Контролюй доступ до індексації
Налаштовуй robots.txt, meta noindex, data-nosnippet – це пряме заява, що ми не хочемо, щоб нас парсили.
3️⃣ Вшивай авторство у контент
Водяні знаки, унікальні посилання, сигнатури – усе це зберігає атрибуцію навіть у відповідях AI.
4️⃣ Захищай API/site
Додавай rate limiting, ключі доступу й умови використання. Підготовка до монетизації – вже зараз.

👉 Пояснити бізнес, що бізнес-модель тільки на основі контенту, більше не працює.
Саме це я і намагався донести бізнесу на дзвінку, який закінчився 25 хвилин тому.