Я здав AWS Certified AI Practitioner у серпні.
Для підготовки було достатньо матеріалу зі skillbuilder.aws

Node.js 23 is released!

Features:
- ESM Enabled by Default.
- Dropped Support for Windows 32-bit Systems: давно час було це зробити.
- --run command stable: конкуренція із npm/yarn за запуск скриптів?
- Test Runner Enhancements: корисно для авторів бібліотек, для тестування продакшен коду продовжуємо використовувати Jest.

Нагадаю, що версії з непарними номерами (наприклад, сьогоднішній Node.js 23) ідеально підходять для раннього тестування нових можливостей у вашому середовищі. Такі випуски не переводяться в LTS. А ось Node.js 22 стане LTS протягом тижня, що розпочнеться 29 жовтня. Тому заплануйте оновленя з 20 до 22.

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

Один з підписників питає:

можна в тебе спитати, чи в тебе бувало відчуття, що ти ніби вчишся і кінця краю тому не видно, і є сумнів в тому що ти навчаючись не гаїш час і рухаєшся далі?

Відповім на це публічно та поділюся своєю невдачею. У мене саме так відбувається з навчанням Machine Learning. Щоб залишатися цікавим роботодавцям, треба вміти працювати з AI/ML. В чому саме проявляється це відчуття безкінечності для меня? За цей рік я вже двічі провалив сертифікацію Google Cloud Professional Machine Learning Engineer. Можна сказати щось типове: знання, здобуті під час підготовки, допомагають у роботі. Це не допомогає, бо провал все одно б’є по самооцінці та підсилює синдром самозванця.

Що я роблю в випадку невдачі? Те саме, що і в разі успіху. Спочатку відпочинок. Потім впорядковую нотатки та підводжу підсумки. Після цього — нова навчальна мета. Адже стару потрібно замінити, незалежно від того, чи була вона досягнута, чи провалена.

Keep learning, because in software development “it takes all the running you can do, to keep in the same place”

Олексій у коментарях до посту про види боргу пропонує не використовувати цей термін:

Я би взагалі казав би не борг, а можливість покращення, бо коли ми кажемо про можливість, то вже зрозуміло, що є ресурси (у наявності чи потенційні, байдуже). А слово борг якось тхне

Така точка зору популярна у Scrum майстрів, які пропоную все що є в белог розглядати як можливості. Я ж як людина з економічною освітою пропоную вам використовувати терміни борг та інфляція в контексті технічних процесів. Вони зрозуміліші бізнесу.

Наприклад, з 5-го жовтня 2024 року 8-а версія eslint досягла end of life і більше не підтримується. Використання 8-ї або старшої є прикладом тех боргу, викликаного технічною інфляцією.

На завершення поділюсь планами на наступний стрим. Він буде як налаштувати eslint для Node.js проектів.

Сьогодні поширю мої загальні питання для технічних співбесід:

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. Які в тебе є питання за підсумками сьогоднішнього інтерв'ю?

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

WebStorm тепер безкоштовний для некомерційного використання!

JetBrains оголосила: тепер WebStorm доступний безкоштовно для навчання, open-source, хобі та створення контенту. Комерційні проєкти залишаються під платною ліцензією.
Це означає, що ви отримуєте повний функціонал IDE без обмежень! Єдина різниця — замість повної версії Code With Me, у безкоштовній ліцензії доступна лише його Community-версія.

Як отримати ліцензію?
1. Встановіть WebStorm і відкрийте.
2. Виберіть “Non-commercial use”.
3. Увійдіть у свій JetBrains-акаунт.
4. Погодьтеся з умовами.

💡Важливо: анонімну статистику збирають обов’язково, вимкнути її неможливо.

🚀 Node.js 22.11.0 тепер у LTS!

Node.js 22.x офіційно перейшов у Long Term Support (LTS)! Тепер ця версія перебуває у статусі “Active LTS” і буде підтримуватися до жовтня 2025 року. Після цього періоду вона перейде в режим “Maintenance” та залишиться актуальною до квітня 2027. Жодних змін порівняно з версією Node.js 22.10.0, окрім оновленяя метаданіх.

Docker hub вже має актуальні images, тому можна переходити.

Nest.js має застарілий tsconfig
Рецепт є прикладом відповіді на 4 питання https://xn--r1a.website/node_recipes/774
Команда nest new project-name генерує некоректний файл tsconfig, налаштований для застарілої версії Node.js (16-ї). Проблему посилює використання в екосистемі Nest.js пакета ts-node, який застосовується, наприклад, у проєктах типу typeorm або nest-commander. Пакет ts-node вже понад рік не оновлювався і досі не підтримує TypeScript 5.0 — Supporting Multiple Configuration Files in extends. Це обмежує можливість застосовувати рекомендовані налаштування з tsconfig/bases за допомогою:
{
"extends": ["@tsconfig/strictest/tsconfig", "@tsconfig/node22/tsconfig"]
}

Приклад ts-config, що відповідає сьогоднішнім best practise:
{
"extends": "@tsconfig/strictest/tsconfig",
"compilerOptions": {
// @todo extend from @tsconfig/node22/tsconfig after ts-node support extends array
// start of @tsconfig/node22/tsconfig
"lib": ["es2023"],
"module": "node16",
"target": "es2022",
"moduleResolution": "node16",
// end of @tsconfig/node22/tsconfig

"allowJs": false,
"checkJs": false,

"emitDecoratorMetadata": true,
"experimentalDecorators": true,

"forceConsistentCasingInFileNames": true,

"noEmit": true,
"baseUrl": "./",
"paths": {
"~/*": ["./src/*"]
}
},
"include": ["src/**/*", "tests/**/*"],
"ts-node": {
"require": ["tsconfig-paths/register"]
}
}

UPDATE:

а чому не module: "nodenext" і target: "esnext"?

Бо https://github.com/tsconfig/bases/blob/main/bases/node22.json#L8 яке йде з https://github.com/microsoft/TypeScript/wiki/Node-Target-Mapping

Checklist: Error handling
Для повної відповіді на питання №5 краще підходить формат доповіді або навіть воркшопу. У текстовому форматі я зупинився на чеклісті. Кожен елемент списку представлений у форматі того, що має бути в проєкті, і питання, яке варто висвітлити під час інтерв’ю або задокументувати у вашому проєкті.

Рівень коду:
- Використовуються користувацькі класи помилок для різних типів виключень. Як і для чого їх використовують?
- Налаштований глобальний обробник(и) unhandled exceptions на вхідні запити. Приклади: Nest.js exception filters, Express error handler. Які задачі вирішує цей обробник?
- Налаштовані process.on('unhandledRejection') і process.on('uncaughtException'). Що вони роблять?
- Налаштований ESLint з правилами, що полегшують роботу з помилками. Які саме це правила?

Рівень застосунку:
- Є розділення Operational і Programmer Errors. Чим вони відрізняються?
- Налаштований retry для звернень до сервісів. Як саме він реалізований?
- Зміни в базі даних використовують транзакції. Як вони налаштовані?
- Реалізована стратегія “graceful shutdown” при критичних помилках або вимкненні. Що це таке і навіщо необхідно?
- Виконується валідація всіх вхідних даних. Як це реалізовано? Чому це необхідно?
- Визначена відповідальність за текст помилок для кінцевого користувача. Яка вона? Чи є інтернаціоналізація тексту помилок?

Рівень логування:
- Помилки в логах серіалізуються із збереженням stack-trace. Як це робиться? Що таке stack-trace?
- Помилки в логах серіалізуються із збереженням cause. Як це робиться? Що таке cause?
- Немає partial stacktrace. Чим це може бути викликано і як цього уникнути?
- Логи містять traceID для відстеження запитів. Як реалізовано його створення і логування?
- Інтегровані системи моніторингу та оповіщення про помилки. Які саме?

Інформації про зарплату це важливо. В українському IT ми дивимося DOU. В них як раз зараз триває зарплатне опитування.
Для світових зарплат я використовую glassdoor.com та www.levels.fyi. Наприклад, OpenAI найняв FullStack на $1.24M/year
Цікаво, який топ буде в аналітике DOU? Тому заповніть анкету

Подкасти повертаються! Уже цього четверга відбудеться запис випуску на тему "Хто такі, курвамать, ті синьйори, як їх відрізнити від нормальних людей і чи варто ломиться в синьйори усім поголовно".

А допоможе мені розібратися в цій темі неперевершений Нікіта Галкін, найбільший експерт з NodeJS, якого я знаю, справжній системний архітектор (не то шо я), Google Developer Expert і просто неймовірної душі людина.

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

ВАЖЛИВО
1. Запис буде. Але згодом. Змонтований.
2. Під час етеру будемо збирати донати на ЗСУ та розіграємо подарунки
3. Виключно під час етеру ви матимете нагоду поставити своє запитання гостю
4. Ще раз: запис буде викладено згодом, відредагований.
5. Приходьте на етер, буде цікаво ;)

23 січня, канал "Сергій Бабіч та Дивовижний світ веброзробки", 19:00

.

Вчора Matt Pocock, автор TotalTypeScript, опублікував свій безкоштовний курс з Vercel's AI SDK.
Пройти його займе один вечір. Він не замінить, а доповнить читання документації.

Рекомендую для перегляду.

Скоро починаємо https://www.youtube.com/watch?v=L-65TzJT24k

Вчора мені виповнилося 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". До речі, цей канал почався саме так.

У березні я проводитиму внутрішній курс AI-Enabled Developer Experience для однієї компанії. Перед запуском мені потрібно зробити тестовий прогін контенту і перевірити, наскільки матеріали корисні та практичні.
Якщо цікаво взяти участь у пілотній групі, заповни форму: https://forms.gle/FQiudHwi28DwbeB5A
Участь безкоштовна. Відбір учасників буде на основі відповідей у формі (потрібна різноманітність)
Формат – самостійне проходження матеріалів + зворотний зв’язок.
Головна мета – перевірити, як AI може реально покращити Developer Experience у повсякденній роботі.

Update Feb 4. Закрив форму. Дякую всім, хто виявив інтерес. В кінці тижня ви отримаєте емейл.

Один із моїх менті (світчер) поставив цікаве питання:

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

Питання справді чудове, тож поділюся своєю відповіддю публічно.

Я почав працювати напряму з США у 2016 році. Спочатку було незвично: у свої 30 років я був наймолодшим на дзвінках. Тоді на DOU жартували, що після 30 програмістів «спускають по Дніпру». А тут середній вік команди був близько 40.

Мене теж хвилювало питання: що я робитиму в 40, 50, 60 років?

Зараз мені 40, і я вже давно не переймаюся віком. Мабуть, допоміг приклад Джона, з яким ми працювали у 2021 році. У 70 років йому набридло бути менеджером, але й на пенсію він не захотів. Тож він вивчив React і зайнявся фронтендом. Його життєвий досвід поєднувався з технічною “незашореністю”, тому працювати з ним було справжнім задоволенням.

Окремо хочу зупинитися на технічній незашореності. На співбесідах я завжди кажу щось на зразок:

I’m an expert in TypeScript, Node.js, AWS, but I’m not married to this tech stack and open to new approaches and tools.

Цю фразу з not married я якраз запозичив у Джона. А же досвід роботи з ним став для мене чудовим щепленням від ейджизму.

This change doesn’t require any changes for TypeORM, Nest.js GraphQL enums, etc.

Як цікава задачка з prompt-оптимізації нагадала перечитати документацію.

Під час експериментів із TypeSpec та LLM для генерації API-специфікацій я натрапив на кумедну, але доволі показову особливість. AI постійно пропонував додавати ендпоінти для видалення цілих колекцій!
<sarcasm>
Треба видалити користувача?
Без проблем — просто викликаємо DELETE /user, і всі користувачі зникають.
</sarcasm>

Чому так сталось? У промті була “use the best Microsoft practices”, щоб правильно використовувався TypeSpec. Модель із ентузіазмом підхопила RESTful API design із Azure Architecture Center та вирішила, що глобальне видалення даних є чудовою ідеєю. Бо так э у прикладі. То, що так не робиться на реальних проектах, модель не враховувала. Хоча, можливо, я чогось не знаю, і це нормальний дизайн?

📌 Lesson learned: Know the best practices you ask others to follow.