Навіщо потрібен пакет sentences-per-line?Сьогодні хочу порекомендувати вам пакет, але спочатку поясню, навіщо він потрібен. Почнемо з документації.Стандартним форматом документації в розробці є Markdown. Причому ми все частіше пишемо її не лише для інженерів, а й для LLM. Приклади – .cursor/rules, copilot-instructions.md. Важливо підтримувати документацію в актуальному стані. Її оновлення завжди було частиною Definition of Done, але зараз це стало простіше – багато завдань можна делегувати AI-агентам. Нам залишається лише зробити ревʼю.Під час ревʼю виникає проблема: великі абзаци складно перевіряти. Звичайні Markdown-лінтери не вирішують цю задачу. І тут на допомогу приходить пакет sentences-per-line: - Кожне речення – на окремому рядку. Якщо потрібно, можна скористатися auto-fix. - Зміни стають читабельними: diff показує, що саме змінилося на рівні речення. - При цьому Markdown автоматично обʼєднує рядки в один абзац, тож візуально нічого не змінюється.Пакету вже понад 7 років. Дивно, чому цей пакет досі не додали як частину markdownlint. Переглянути приклади конфігурації пакета можна у автора Josh Goldberg, наприклад, тут.Якщо ви хочете, щоб ваша документація була зручною для ревʼю та адаптованою до сучасного дев-процесу, sentences-per-line – обовʼязковий інструмент.
1 квітня Amazon анонсував MCP Servers, і це була не жартівлива новина. По суті, це зручна заміна AWS CLI, яка значно прискорює процес розробки. Проєкт поки що перебуває у глибокій альфа-версії, але я вже протестував його разом із Claude Desktop та Cursor і хочу поділитися власними враженнями.При використанні Cursor ефективність виявилась нижчою через те, що змішувалися код, архітектура та інфраструктура. Була ідея налаштувати кастомний режим, але я вирішив цього не робити і переключився на Claude Desktop. Там мені вдалося зосередитись виключно на одному рівні й успішно вирішити кілька робочих завдань, не покидаючи інтерфейсу Claude. Вони були пов’язані з Visual Prompt Engineering, але це зовсім інша історія.Короткий огляд AWS MCP серверів:🔸Core MCP Server – відповідає за підключення та конфігурацію інших MCP серверів, а також забезпечує логування. Ідея окремого сервера для керування всією екосистемою мені сподобалася.🔸AWS CDK MCP Server – генерує інфраструктуру як код (IaC), дотримуючись рекомендацій AWS Well-Architected. Особисто не тестував, бо використовую Terraform, лише переглянув source code. CDK підтримує багато ресурсів, включно з Lambda Powertools. Планую повернутись до нього під час запуску наступного проєкту на serverless AWS, щоб додатково протестувати AWS Lambda Powertools (TypeScript).🔸Nova Canvas MCP Server – дозволяє створювати зображення. Саме цей сервер я використовував найактивніше, щоб протестувати кілька гіпотез на моделі від AWS Nova Canvas.🔸Cost Analysis MCP Server – створений для аналізу та оптимізації витрат на AWS. Конкретних завдань із ним ще не вирішував, перше враження не дуже. Проте сама ідея дуже корисна, і як тільки вийде стабільна версія, планую активно застосовувати його під час архітектурних рев'ю.🔸Bedrock Knowledge Base Retrieval – сервер для роботи з Amazon Bedrock Knowledge Bases. Поки не маю проєктів із Bedrock KB, тому навіть не переглядав source code.Корисні посилання:🔗 Офіційний анонс на AWS Blog🔗 AWS MCP Servers на GitHub🔗 Для встановлення більшості Python-based MCP серверів потрібен uv (сучасний Python package manager)Резюме:MCP Servers — перспективні інструменти, які вже зараз варто вивчати та пробувати застосовувати у своїх проєктах, а цей AWS проєкт хороший вибір для цього.
Що повинен знати Node.js розробник у 2025-Q1?У вересні минулого року я висловлював свою думку Що має знати Senior Node.js Developer. Зараз я спробував зробити аналіз на основі зрізу усіх українських вакансій. Для цього я звернувся до знайомих з DOU. Мене познайомили з Оксаною Лобко. Саме вона той надзвичайно продуктивний інженер, що створював Джинні у 2017-2021. Зараз вона працює над своїм проєктом JobNote.ai та part-time допомагає у DOU.Оксана надала агреговані дані про вакансіям з українського ринку. JobNote парсить вакансії на сайтах Dou, Джинні та recruitika. Ось так виглядає зріз даних для Node.js: https://jobnote.ai/skills/Node.js/Прокоментую, що там таке:– Cеред даних є як чисті Node.js розробники, так і FullStack.– Title визначається за потрібними роками досвіду. Junior (0,1), middle (2,3,4), senior (>=5).– Популярність технології визначається кількістю вакансій, де вона вказується як вимога.– У рамках цього аналізу дані salary/application per job я відкинувДля зручності аналізу я перейшов від абсолютних показників до відносних. Отже, що нам показують дані?Що стабільно потрібно? TypeScript, NestJS, React та бази даних стабільно затребувані незалежно від рівня:- TypeScript – є у 70% вакансій незалежно від рівня.- NestJS – у 40% вакансій. Express.js/Fastify/etc майже не зустрічаються.- PostgreSQL – у 50% вакансій.- MongoDB – у 30% вакансій.- MySQL – 20%, SQL – 20%, NoSQL – 15%.- Redis – 25% (але для Junior трапляється рідше).- React – у 40% вакансій, Next.js/HTML/CSS – у 10%.Що менше вимагають з розвитком? Очевидно, що певні знання стають само собою зрозумілими:- JavaScript – важливий для 70% Junior, але для Middle/Senior це знижується до 40%.- API – 50% для Junior, 40% для Middle та 30% для Senior.- Git – 30% для Junior, 20% для Middle і Senior.Що стає актуальніше з розвитком? Явно зростає попит на Cloud Native- AWS – Junior (35%), Middle (40%), Senior (50%).- CI/CD – Junior (10%), Middle (20%), Senior (27%).- Docker – Junior (23%), Middle (28%), Senior (33%).- Kubernetes – Junior (10%), Middle (12%), Senior (24%).Топ-3 хмарних провайдерів:- AWS – Junior (35%), Middle (40%), Senior (50%)- Google Cloud – Junior (5%), Middle (8%), Senior (15%).- Azure – Junior (?), Middle (7%), Senior (12%).Окремо виділю зростання попиту на GraphQL- GraphQL – Junior (6%), Middle (15%), Senior (18%)Чого ми не бачимо у вакансіях?LLM/AI/Agents/etc. Я очікував побачити це у вакансіях у 2025-Q1Воно ще занадто нове, щоб бізнес розумів, як це інтегрувати в існуючі технічні та бізнесові процеси. ВисновкиМожливо, я упереджений, тому дані лише підтвердили мої припущення:1. У 2025 Node.js — Boring Technology2. На ринку найбільше затребувані Node.js розробники, які знають TypeScript, NestJS, React та CloudNative (AWS/K8s/etc).3. Використовувати ринок, як джерело правди, що варто вивчати, можна тільки до middle рівня. На senior/senior+ потрібно самостійно складати план подальшого розвитку.
Сьогодні ділюся спостереженням, яке часто зустрічається в проектах, де я проводжу Architecture Board Review.Багато команд використовують лише одну базу даних, зазвичай PostgreSQL. Хоча це зручно і забезпечує консистентність, ми все одно використовуємо інші сховища даних (наприклад, S3) та інтегруємося з 3rd parties, як-от Stripe чи Firebase Auth. Через це питання узгодженості між DB та 3rd parties все одно доводиться вирішувати.Не бійтеся додавати ще одну базу даних до проєкту - це може спростити розробку та архітектуру застосунку. Ось кілька прикладів:1) SQLite для даних, що рідко змінюються. У додатку його монтують як Docker Volume з доступом лише для читання, а зміни здійснюються через адмінку, яка використовує той же volume з правами на запис.2) Окрема база для аналітики. Наприклад, додатковий PostgreSQL або спеціалізована база для аналітичних даних, щоб основна база не була перевантажувана і це не впливало на користувацький досвід.3) Realtime база. Firestore або Supabase можуть бути використані для реалізації повідомлень у реальному часі. Підключення серверних подій або веб-сокетів часто вимагає великих змін в архітектурі, тому окрема база для realtime notifications може бути зручною альтернативою.4) Redis для кешування. Використання Redis або його аналогів допомагає зменшити навантаження на бази даних, пришвидшити доступ до часто використовуваних даних та забезпечити кращу масштабованість проєкту.На завершення нагадаю про PostgreSQL Extensions. У певних ситуаціях це правильний інструмент для вирішення чергового інженерного завдання.
Вчора мені виповнилося 40. Ось що я хотів би знати як професіонал, коли мені було 30:1. Неможливо робити все одночасно швидко, якісно та правильно. Найчастіше це недосяжно; важливо вміти перемикатися між цими режимами.Див. Make It Work, Make It Right, Make It Fast.2. Оцінка результативності одного інженера (у тому числі вашої власної) не має сенсу. Важлива загальна ефективність команди.Див. Групова динаміка.3. Акції, опціони та криптотокени як частина винагороди мають сенс лише у компаніях, що вже вийшли на біржу. В іншому випадку шансів більше виграти в казино. Див. статистику стартапів, де співробітники змогли зробити exit.4. Ми обираємо не один інструмент або фреймворк, а цілу екосистему та спільноту. Наприклад, екосистему Node.js або продукти Apple.5. Одного разу вас звільнять, або ви самі підете. Див. 45 татуювань менеджера.6. Найкращі пропозиції роботи приходять через нетворкінг. Тому не будь мудаком та не працюйте із мудакамі. Див. The Schmuck in My Office.7. Перш ніж вирішувати проблему, переконайтеся, що вона справді існує для того, хто приймає рішення. Див. базові техніки продажів.8. Люди не змінюються, але процеси можна й потрібно змінювати. Саме тому я почав робити DevOps.9. Час важливіший за гроші, тому витрачай час і гроші на те, що заощаджуватиме час. Дивись, Time to the Market.10. Дуже корисно писати нотатки "today i learned". До речі, цей канал почався саме так.
Сьогодні поширю мої загальні питання для технічних співбесід:1. Ось package.json з нашого проєкту. Які в тебе виникають запитання щодо його вмісту? Прокоментуй залежності: з чим тобі подобається працювати, що б ти замінив і чому? З чим ще не стикався?2. Покажи свій package.json з поточного проєкту (якщо це не порушує NDA) або pet-проєкту. Я оберу кілька пакетів і поставлю питання про них.3. Уяви, що тепер ти інтерв'юєр. Як би ти перевіряв знання з теми <topic>? Які б 3 питання ти поставив (просте, середнє, складне)? Можна вибрати одне з них та попросити кандидата відповісти.4. Розкажи мені про недоліки в роботі з TypeScript, Nest.js, TypeORM, GitHub Actions, монорепозиторіями тощо. Це допомагає побачити глибину розуміння та досвід використання.5. Уяви, що в продакшені виникла проблема, і застосунок почав працювати повільно. Як би ти діагностував і визначив причину? Це чудова можливість перевірити знання інфраструктури, моніторингу, логування та відповідних інструментів.6. Як ти організовуєш обробку помилок у застосунку?7. Що з останніх новинок у JavaScript-екосистемі ти вже випробував? Які твої враження?8. Як ти працюєш з обмеженням API Rate Limiting? Перевіряє знання управління навантаженням, повторних спроб (retry) та масштабування застосунку.9. Розгляньмо кейс: я — продакт-оунер і хочу, щоб ти реалізував фічу X. Які питання по вимогах ти б поставив і як би ти декомпозував їх у завдання для розробки?10. Які в тебе є питання за підсумками сьогоднішнього інтерв'ю?Використання такого формату запитань допомагає проводити співбесіду як розмову між двома колегами, а не як іспит.
Нагадаю вам, що тех борг має різні види. Виділяють:1. Архітектурний борг — виникає через недостатнє опрацювання або зміни архітектури системи.2. Кодовий борг — з’являється через погане або неефективне написання коду.3. Тестовий борг — нестача тестів або неякісне покриття коду тестами.4. Інфраструктурний борг — застаріла або неефективна інфраструктура проєкту.5. Документаційний борг — нестача або відсутність документації по проєкту.6. Процесний борг — неефективні процеси розробки або їх відсутність.7. Борг безпеки — відсутність заходів безпеки або ігнорування вразливостей.8. UI/UX-борг — погане опрацювання інтерфейсу користувача та взаємодії.9. Борг залежностей — використання застарілих бібліотек та фреймворків.10. Бізнес-борг — спрощення або пропуск функціоналу заради прискореного релізу.11. Командний борг — виникає через затримку в наймі потрібних фахівців або найм некваліфікованих співробітників для заповнення вакансій.Борги не варто затягувати, інакше настане технічна смерть проекту, коли дешевше переписати з 0, ніж підтримувати/розвивати поточний.Як приклад, чому борги треба віддавати, поділюся своєю історією про здоров’я. Я не робив чек-ап з моменту виїзду з України, а це майже 3 роки. Метрики контролю здоров’я: логування ваги та Heart rate variability (HRV), який мені вимірює Whoop. Метрики не тішили, останній рік вага при зрості 192 см – 110 кг (референсне значення 85-93 кг), HRV 48 мс (референс 45-95). І це при більш-менш регулярних заняттях спортом. Місяць тому HRV впав до 25 мс. А до вечора другого дня піднялася температура, і тієї ж ночі мене прооперували – видалили запалений апендицит. Пройшов місяць, я не робив якихось суттєвих змін у дієті чи фізичних навантаженнях, але HRV виріс до 65 мс і продовжує зростати, а вага знизилася до 102 кг. Висновки робіть самі.
Де вчити NestJS?Сьогодні в особисті повідомлення знову прилетів запит на те, де вчити Nest.js: “Нікіта, привіт! можеш порадити хороший курс по нест на юдемі чи курсері? чи книгу”Почну з посилань, які я рекомендую:🔗 NestJS documentation 🔗 Official NestJS Courses 🔗 API with NestJS by wanago.io 🔗 Open Source Projects using NestJSОсобистий досвід. За останні 4 роки я провів більше 10 разів внутрішні курси по Nest.js. Кожного разу я компонував курс під потреби проекту. Немає сенсу давати GraphQL або NestJS мікросервіси команді, яка їх використовувати не буде. Вчити PHP розробників та frontend розробників необхідно по-різному. Спільне у курсів було те, що я показував реальну практику застосування фреймворку в контексті, близькому до потреб проекту. Якщо ж робити курс у відриві від контексту проекту, то вийде переказ Official NestJS Courses та wanago.io.На Coursera представлені курси у стилі університетського матеріалу, тобто фокус на теорію. А фреймворки вчаться через практику – learning by doing. З цієї ж причини хороших книг по Nest.js немає. По фреймворках пишуть документацію, тому раз на півроку перечитуємо документацію та реліз notes по Nest.js. Також я рекомендую робити і з Node.js або будь-яким іншим інструментом.Для мене Udemy це блошиний ринок, тобто вам може пощастити і ви знайдете за 5 доларів щось варте. Але як правило час на пошук та реставрацію (перевірку актуальності інформації в курсі) не виправдовує походи на блошиний ринок. Цей час краще вкласти в написання коду або вивчення як роблять колеги, тому я і раджу переглядати код NestJS проектів.І на завершення: ⚠️learning by doing⚠️
Як працює git autocorrect?Сьогодні порада для новачків. Якщо у вас багато опечаток у git і ви не використовуєте git alias, рекомендую звернути увагу на help.autocorrect. Якщо є тільки одна схожа команда, git виконує її автоматично. Якщо ж є кілька варіантів, він перераховує їх і зупиняється.Приклади:$ git com -m "Some awesome work"git: 'com' is not a git command. See 'git --help'.The most similar commands are commit column# Immediate autocorrectgit config --global help.autocorrect immediategit sttaus # Runs `git status` immediately# Prompt for confirmation before autocorrectgit config --global help.autocorrect promptgit sttaus # Asks for confirmation before running `git status`# Disable autocorrectgit config --global help.autocorrect nevergit sttaus # Does not autocorrect# Enable autocorrect with a 1 second delaygit config --global help.autocorrect 10git sttaus # Runs `git status` instead, after a 1 second delayПодібна функція є у zsh: CORRECT/CORRECT_ALL з prompt-виправленнями. Автоматичні виправлення на рівні системи, а не окремих команд, дуже ризиковані, тому такого не існує.На завершення нагадаю, що у git tips є багато порад.
TGLIST.COM.UA
