Ось така розмова вийшла з колегою-архітектором.привіт Нікітаможливо можеш трохи допомогти?Треба інструмент котрий міг би полегшити документацію. Confluence не має. На данний момент вся документація створюється в окремому git проекті. Шо не є зручно. Є купа репозиторієв в котрих є свої нюанси (як приклад як додавати переклади, сетапити перший запуск ...). Readme не дуже зруно юзати.Можливо знаєшь якість інструменти? можливо якийсь npm пактет котрий міг би давати змогу вести зручну документацію для кожного репозиторія?у клієнта Azure інфраструктура
привіт1. як я тебе зрозумів- є система (або група застосунків), код якої зберігається як polyrepo- є технічна документація, що зберігається в окремому репозиторії2. як я зрозумів проблему — неактуальність документації. Вона частково спричинена тим, що зміни в репозиторіях app1/appN із кодом не завжди супроводжуються змінами в репозиторії з документацією docs3. що я припускаю за контекстом- використовується GitHub Actions- проблему не вдається вирішити використовуючи тількі інженерну дисципліну4. що б я зробив- продовжив би використовувати один репозиторій для документації як джерело правди- додав би в кожен репозиторій папку docs- створив би reusable GitHub Action, який копіює зміни з appN/docs у docs/appNу результаті розробники відповідають за документацію на рівні репозиторію, а архітектори — на рівні docs5. опційно- для людей із репозиторію docs зробити автопублікацію сайту з документацією (є багато готових рішень для перетворення markdown → HTML)- вибрати й задокументувати технічний стек у репозиторії docs, додати скрипти для перевірки відповідності у всіх репозиторіях (наприклад, версія TypeScript/Eslint/etc)- реалізувати підхід для генерації специфікацій із коду (Swagger чи його аналоги) і збірку зі всіх репозиторіїв- для AI coding agents — створити власний MCP сервер. Спочатку з документацією, пізніше з метриками з інфраструктури й даними з застосунківА взагалі ведення узгодженої документації — це більше про допомогу людям домовитися й дотримуватись домовленостей, ніж про інженерію.
Сьогодні поговоримо про Terraform і на кого підписатися, щоб бути в курсі його екосистеми.⠀🤔Почну з головного питання – навіщо тобі, дорогий читачу, Terraform?Щоб бути інженером, а не просто розробником.Розробники вміють тільки писати код (на одній мові / фреймворку), тому їх легко замінює AI.А от інженер створює продукти, відповідає за їхню роботу аж до продакшену і розуміє DevOps практики.Terraform – це стандарт де-факто серед IaC (Infrastructure as a Code), тому знати його – мастхев.⠀🎓Власне, як його вчити? Перевірено на особистому досвіді.📗Теоретична база:1. Готуємося до сертифікації Terraform Associate- learning path by HashiCorp- відео by FreeCodeCamp2. Опціонально здаємо іспит за $70 (робочих знижок чи ваучерів я не знайшов)3. Читаємо Terraform Best Practices⠀🛠 Практика:1. Паралельно з теорією пишемо інфру для свого комерційного або pet-проєкту в тому хмарному провайдері, що тобі зручний.2. Поступово додаємо інструменти з Terraform-екосистеми:- tfenv- tflint- tfupdate- checkov- pre-commit-terraform⠀📬 Як бути в курсі?Книга і pre-commit-terraform написані моїм улюбленим AWS Hero – Антоном Бабенко.Він регулярно стрімить на своєму YouTube-каналі та веде Terraform Weekly.Я читаю його дайджести, а ще реліз-ноути Terraform та провайдерів, які використовую.⠀Наприкінці посилання на останнє відео Антона з AWS Community Day Armenia.
Хочу поділитися з вами незручною правдою. Бізнесу не потрібні:- фреймворки- системи логування- CI/CD- тестування- i так далі.Ці процеси та інструменти потрібні нам, інженерам, щоб якісно виконувати свою роботу.Коли ти приходиш до ресторан та замовляєш їжу, то шеф-кухарь не розповідає тобі, як він користується ножами чи м’ясо для котлет майже закінчується. Так і бізнесу потрібен готовий працюючий додаток. А деталі ваших інструментів можуть цікавити хіба що CTO. Тому не розповідайте стейкхолдерам технічні деталі, а лише питайте, який результат їм потрібен та коли.Ще раз, це ваше завдання - знати документацію, знаходити час для оновлення технічного стеку або погашення технічного боргу. Знаходити баланс між технічними завданнями і впровадженням бізнес-фіч – це ознака Senior-а.PS Пост написаний за підсумками обговорення з менті питання “Як отримувати від бізнесу апруву на технічні завдання?”. Контекст: менті - єдиний розробник у проєкті. Моя позиція, як ви вже здогадалися з допису, не обговорювати це питання з бізнесом, а просто виділяти 2 години кожен робочий день на технічні завдання.
Поділюсь своїм баченням поточних реалій ринку.Зараз основна складність з наймом інженерів – не через дефіцит кандидатів, а навпаки: на ринку надлишок претендентів, і більшість з них не відповідають очікуванням.Основні проблеми:- Велике навантаження на рекрутинг – потрібно переглянути сотні резюме, щоб знайти хоча б одного сильного кандидата.- Якісні фахівці рідко шукають роботу – у нестабільних умовах вони не хочуть ризикувати стабільними проєктами.- Оптимізація під вакансії – багато хто «прокачує» резюме під вимоги (читай: прикрашає факти).- AI-чітінг – використання штучного інтелекту для виконання тестових і навіть під час технічних співбесід без розуміння відповідей.⚠️ Ця ситуація характерна як для українського, так і для міжнародного ринку.Що з цим доводиться робити? У межах консалтингу я додаю тестове завдання до технічної співбесіди. Рекрутер попереджає, що буде розгорнутий фідбек за результатами. Нижче – статистика за 2025 рік за двома вакансіями: Senior FullStack і Senior Node.js Developer.- Взяли тестове завдання – 17 кандидатів (із них задали уточнювальні питання – 3)- Прислали виконане завдання – 11- Завдання виконано на рівні Senior – 4- Завдання виконано на рівні Middle – 2- Зроблено оферів за підсумками співбесід – 1Основні проблеми в тестових:👎Додаток не запускається або не збирається.Приклад: конфлікти версій бібліотек.👎Обрано невдалий архітектурний підхід або технологічний стек.Приклад: реалізація real-time (WS/SSE) у NestJS без використання RxJS.👎Відсутні важливі фічі.Приклад: у FullStack-завданні була явна задача на sharing у соцмережах, але її не реалізували бо use client👎Ігнорування базових best practices.Приклад: захардкожені змінні замість використання env vars, потенційні security-уразливості.Основні проблеми під час обговорення тестового на технічній співбесіді:🤦♂️Кандидат не може пояснити прийняті рішення або власний код.🤦♂️Кандидат не здатен внести правки у свій код.Приклад: “Давайте виправимо цей незначний баг” – і починається паніка.На кінець хочу вам нагадати, що знайти хороших людей завжди складно, незалежно від того, чи шукаєте ви роботу, чи нового колегу для вашого проєкту.
Останні два тижні в AI — новий виток. Вийшла купа моделей і тулзів для девелоперів. Потестити все ще не встиг, але знову чую: «AI забирає роботу джунів». І це жах, бо тоді хто стане сеньорами?🟡 Непопулярна думка:- Досвідчений джун - це не сеньор.- Досвідчений сеньор - це не архітектор.- Досвідчений архітектор/техлід - це не СТО.Це не грейди одного шляху, це різні набори компетенцій.Їх неможливо опанувати, просто «доростаючи» - їх треба перемкнути свідомо, змінюючи підхід, зони відповідальності та перспективу.🧠 Ключова думка:Сеньори з’являються не з джунів, а з недосвідчених сеньорів.СТО з’являються не з архітекторів, а з недосвідчених СТО.Кілька свіжих прикладів1️⃣ Node.js девелопер, який 5 місяців шукає роботу сеньора. Я звів його з рекрутером, він провалив навіть базову комунікацію.Його аргумент: «Ну, для HR комунікація - це головне, а для мене - допоміжне». Але це і є проблема: сеньор - це передусім про ефективну командну взаємодію.2️⃣ Колега, що скаржиться, як його “недооцінили” на system design інтерв’ю. Йому пощастило, йому дістався завдання зробити систему, яку він уже робив для мільйонів користувачів. Але… забув зібрати вимоги, не продав ідею, не доніс цінність. Архітектор – це не про те, що ти вже колись робив. Це про те, як ти комунікуєш свою експертизу тут і зараз. Інтерв’ю – це теж робоча ситуація.AI не забирає роботу. Він просто більше не дає ховатися за «ще рано», «я не впевнений», «мені не дали шанс».У сильних – це інструмент, а у інфантильних – конкуренція.
Я пам’ятаю, що обіцяв зробити огляд 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
Учорашнє відео містить одну з ключових думок про те, що нам потрібно вміти створювати код з різною швидкістю/якістю.Це вміння змінювати швидкість під завдання важливе в усіх сферах життя… Тут я зупинюся, бо починаю цитувати: "Thinking, Fast and Slow” by Daniel Kahneman.За останній рік завдяки AI-інструментам я навчився краще управляти швидкістю вивчення нових інструментів/бібліотек.Ось що дозволяє рухатися так, як я звик та як воно було до AI:1️⃣ Learning by doing2️⃣ Reading standart documentation3️⃣ 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 them2️⃣ The tool source code review. AI helps with navigation, explanation, etc3️⃣ 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/nest3️⃣ DeepWiki. Example https://deepwiki.com/nestjs/nestа які інструменти ви використовуєте для навчання? Які курси відвідуєте?
🚀 Вийшов реліз Node.js v22.15.0#nodejs_apiУ цьому мінорному оновленні є два важливі моменти, на які варто звернути увагу.1️⃣ Оновлення бази часових поясів: tzdata 2024b → 2025aДеталі змін у реліз-нотах tzdata 2025a.Якщо ваш застосунок має бізнес-логіку, що залежить від таймзон, це оновлення може стати breaking change. Щоб уникнути подібних ризиків у майбутньому, краще використовувати system-ICU, щоб оновлювати таймзони незалежно від оновлень Node.js.2️⃣ Зʼявився новий метод process.execve() — системний виклик, який повністю замінює поточний процес на новий, зберігаючи той самий PID. Приклад:console.log('Before execve pid:', process.pid);try { process.execve('/bin/sh', ['sh', '-c', 'echo After execve pid: $$']);} catch (err) { console.error('execve failed:', err);}Що це означає для Node.js розробників?🐳 Мінімалістичний init-процес на JS у Docker-контейнерах: наприклад, можна спочатку отримати секрети з AWS Secrets Manager, а потім запускати основну програму, як треба по 12 Factor.🔁 Hot-reload без втрати PID: перезапуск застосунку без його зупинки — актуально для IoT-пристроїв або embedded-систем.⚠️ Новий вектор атак: тепер можливе підміщення логіки без зміни PID, що вимагає додаткової уваги до безпеки.
Дві хронічні помилки, через які ваші улюблені фічі зникають із інструментів1️⃣Не навчаєте колег користуватися улюбленими фічамиДистанційна робота знизила популярність парного програмування. Хоча, парадоксально, з’явились чудові інструменти для цього — від Code With Me до Tuple.Парне програмування — це можливість підгледіти круті патерни використання інструментів у колеги або, навпаки, показати йому фічу, яку обожнюєш сам.🔁 Використовуйте цей формат частіше. Це інвестиція не лише у команду, а й у виживання ваших улюблених можливостей.2️⃣Вимикаєте збір телеметріїБагато сіньйорів вимикають збір телеметрії — і в IDE, і в інших інструментах. Але мова не про “злив даних для чергової LLM”, а про анонімну статистику використання фіч: що, коли і як часто використовується.Вимикання збіру телеметрії не має сенсу:✅ телеметрія не навантажує мережу або CPU;✅ вона дозволяє інженерам, які розвивають інструменти, ухвалювати проактивні рішення на основі даних;❌ без неї фічі зникають “бо ніхто не користується”. Хоча користуються — просто без сліду.Цей пост — реакція на обговорення фічі modal commit, яку винесли в окремий плагін, і розмову з інженером JetBrains на Google Cloud Next’25. У них багато техборгу, і фічі, які виглядають “непопулярними” за телеметрією, вони змушені виносити або прибирати.
Я вирішив підтримати Діму Малєєва та Влада Кампова та створив свій профіль на mentor.shЯ оформив як послуги для менті те, чим вже давно займаюся як Fractional CTO для компаній.1️⃣ Mock Hiring Process – Готуємося до реальних інтерв’юУ 2025 році як в Україні, так і у світі, кандидатів більше, ніж вакансій. Тестове завдання стало стандартним етапом ще до першої розмови. Для компаній я:– складаю тестове завдання,– перевіряю його,– а вже потім проводжу технічне інтерв’ю.Для менті це оформлено як імітація реального процесу найму:– Ви отримуєте тестове завдання відповідно до вашого рівня та спеціалізації;– Проходите годинне технічне інтерв’ю;– Отримуєте детальну зворотну відповідь.Послуга на mentor.sh називається Hourly Session і коштує $200, підходить для ролей:– Cloud Engineer (Node.js + Cloud Native),– Node.js Developer (NestJS),– Fullstack Developer (NestJS + Next.js),– Frontend Developer (Next.js).Технології обрані відповідно до актуального попиту на ринку.2️⃣ Learning by doing – Менторство через практикуТе, що я називаю технічним наглядом у компаніях, я оформив у формат для менті: “Get hands-on experience by building real-world skills with a new fullstack web project every two weeks.”Як це працює:– Аналізуємо вимоги до продукту або фічі,– Обираємо технологічний стек (з PoC),– Проектуємо архітектуру,– Реалізуємо рішення,– В кінці кожного циклу ви отримуєте фідбек + еталонне рішення.Для цього є два дзвінки на місяць зі мною - обговорюємо результати, робимо новий крок.Створенно для Fullstack-інженерів, або тих, хто рухається у цей бік. Вартість — $250/місяць.
TGLIST.COM.UA
