11.03.202519:13
Через 5 хвилин проведу стрім, щодо новини дня TypeScript -> Go:
- https://devblogs.microsoft.com/typescript/typescript-native-port/
Ця новина чудово підходить для розповіді про те, що таке LSP і чому це важливо для нас як розробників.
Навколо цієї теми вже починають з'являтися міфи, які викликані неточності, що виникають під час пересказу.
- https://www.totaltypescript.com/typescript-announces-go-rewrite
Отож давайте розберемо цю новину і додамо технічної глибини та розуміння цієї теми.
Приєднуйтесь до стріму або перегляньте його в записі
https://youtube.com/live/13dWqnuuNlk?feature=share
- https://devblogs.microsoft.com/typescript/typescript-native-port/
Ця новина чудово підходить для розповіді про те, що таке LSP і чому це важливо для нас як розробників.
Навколо цієї теми вже починають з'являтися міфи, які викликані неточності, що виникають під час пересказу.
- https://www.totaltypescript.com/typescript-announces-go-rewrite
Отож давайте розберемо цю новину і додамо технічної глибини та розуміння цієї теми.
Приєднуйтесь до стріму або перегляньте його в записі
https://youtube.com/live/13dWqnuuNlk?feature=share
18.02.202515:03
Сьогодні ділюся спостереженням, яке часто зустрічається в проектах, де я проводжу 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. У певних ситуаціях це правильний інструмент для вирішення чергового інженерного завдання.
Багато команд використовують лише одну базу даних, зазвичай 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. У певних ситуаціях це правильний інструмент для вирішення чергового інженерного завдання.


07.02.202514:02
Сьогодні хочу поділитися, як за один вечір, безкоштовно можна посилити своє резюме для #AWS. Кроки:
1. Створіть профіль на AWS Skill Builder, якщо у вас його ще немає. Використовуйте ту пошту, на яку ви збираєте бейджі.
2. Пройдіть курс AWS Well-Architected Foundations.
3. За бажанням, завантажте сертифікат про завершення і обміняйте його на AWS ваучер на 20$ у коментарях до цього посту.
4. Додайте в розділ сертифікацій свого резюме рядок AWS Well-Architected Proficient.
5. Через кілька тижнів від AWS має надійти бейдж на Credly. Я його ще не отримав.
По суті, це повний аналог Skill Badge від Google Cloud, який також вимагає 2-3 години на отримання. Але цього не знають рекрутери, тому ми отримуємо легальний спосіб додати в своє резюме потрібні ключові слова.
Для тих, хто дочитав до кінця, поясню звідки ці 20$: я учасник програми AWS Community Builders, і мені там видали 30 ваучерів для мого ком’юніті.
1. Створіть профіль на AWS Skill Builder, якщо у вас його ще немає. Використовуйте ту пошту, на яку ви збираєте бейджі.
2. Пройдіть курс AWS Well-Architected Foundations.
3. За бажанням, завантажте сертифікат про завершення і обміняйте його на AWS ваучер на 20$ у коментарях до цього посту.
4. Додайте в розділ сертифікацій свого резюме рядок AWS Well-Architected Proficient.
5. Через кілька тижнів від AWS має надійти бейдж на Credly. Я його ще не отримав.
По суті, це повний аналог Skill Badge від Google Cloud, який також вимагає 2-3 години на отримання. Але цього не знають рекрутери, тому ми отримуємо легальний спосіб додати в своє резюме потрібні ключові слова.
Для тих, хто дочитав до кінця, поясню звідки ці 20$: я учасник програми AWS Community Builders, і мені там видали 30 ваучерів для мого ком’юніті.
31.01.202516:41
У березні я проводитиму внутрішній курс AI-Enabled Developer Experience для однієї компанії. Перед запуском мені потрібно зробити тестовий прогін контенту і перевірити, наскільки матеріали корисні та практичні.
Якщо цікаво взяти участь у пілотній групі, заповни форму: https://forms.gle/FQiudHwi28DwbeB5A
Участь безкоштовна. Відбір учасників буде на основі відповідей у формі (потрібна різноманітність)
Формат – самостійне проходження матеріалів + зворотний зв’язок.
Головна мета – перевірити, як AI може реально покращити Developer Experience у повсякденній роботі.
Update Feb 4. Закрив форму. Дякую всім, хто виявив інтерес. В кінці тижня ви отримаєте емейл.
Якщо цікаво взяти участь у пілотній групі, заповни форму: https://forms.gle/FQiudHwi28DwbeB5A
Участь безкоштовна. Відбір учасників буде на основі відповідей у формі (потрібна різноманітність)
Формат – самостійне проходження матеріалів + зворотний зв’язок.
Головна мета – перевірити, як AI може реально покращити Developer Experience у повсякденній роботі.
Update Feb 4. Закрив форму. Дякую всім, хто виявив інтерес. В кінці тижня ви отримаєте емейл.
Reposted from:
Той самий Бабіч

21.01.202514:43
Подкасти повертаються! Уже цього четверга відбудеться запис випуску на тему "Хто такі, курвамать, ті синьйори, як їх відрізнити від нормальних людей і чи варто ломиться в синьйори усім поголовно".
А допоможе мені розібратися в цій темі неперевершений Нікіта Галкін, найбільший експерт з NodeJS, якого я знаю, справжній системний архітектор (не то шо я), Google Developer Expert і просто неймовірної душі людина.
Обовʼязково поговоримо про те, кому нафіг впали грейди в компаніях, які навички треба, аби вважатись гідним високого звання старшого розробника, як з личинки джуна перетворитися на прекрасного синйьора і чи дійсно потрібно усім прагнути до цієї карʼєрної сходинки.
ВАЖЛИВО
1. Запис буде. Але згодом. Змонтований.
2. Під час етеру будемо збирати донати на ЗСУ та розіграємо подарунки
3. Виключно під час етеру ви матимете нагоду поставити своє запитання гостю
4. Ще раз: запис буде викладено згодом, відредагований.
5. Приходьте на етер, буде цікаво ;)
23 січня, канал "Сергій Бабіч та Дивовижний світ веброзробки", 19:00
.
А допоможе мені розібратися в цій темі неперевершений Нікіта Галкін, найбільший експерт з NodeJS, якого я знаю, справжній системний архітектор (не то шо я), Google Developer Expert і просто неймовірної душі людина.
Обовʼязково поговоримо про те, кому нафіг впали грейди в компаніях, які навички треба, аби вважатись гідним високого звання старшого розробника, як з личинки джуна перетворитися на прекрасного синйьора і чи дійсно потрібно усім прагнути до цієї карʼєрної сходинки.
ВАЖЛИВО
1. Запис буде. Але згодом. Змонтований.
2. Під час етеру будемо збирати донати на ЗСУ та розіграємо подарунки
3. Виключно під час етеру ви матимете нагоду поставити своє запитання гостю
4. Ще раз: запис буде викладено згодом, відредагований.
5. Приходьте на етер, буде цікаво ;)
23 січня, канал "Сергій Бабіч та Дивовижний світ веброзробки", 19:00
.


24.10.202413:28
10.03.202515:22
Що повинен знати 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 Technology
2. На ринку найбільше затребувані Node.js розробники, які знають TypeScript, NestJS, React та CloudNative (AWS/K8s/etc).
3. Використовувати ринок, як джерело правди, що варто вивчати, можна тільки до middle рівня. На senior/senior+ потрібно самостійно складати план подальшого розвитку.
У вересні минулого року я висловлював свою думку Що має знати 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 Technology
2. На ринку найбільше затребувані Node.js розробники, які знають TypeScript, NestJS, React та CloudNative (AWS/K8s/etc).
3. Використовувати ринок, як джерело правди, що варто вивчати, можна тільки до middle рівня. На senior/senior+ потрібно самостійно складати план подальшого розвитку.
13.02.202512:28
Сьогодні один із моїх менті запитав мою думку про (вказано, як в оригіналі)
Поділюсь своєю точкою зору публічно.
Позиція Intern/Trainee буде актуальною завжди, адже нові люди приходитимуть у професію. Інша справа, що вимоги будуть змінюватися. Вони вже зараз змінюються, і в них з'являється вміння ефективно використовувати ChatGPT.
Я був у кількох кампусах США з доповідями, як Google Developer Expert. Тому в моїй мережі LinkedIn є нинішні студенти США. Тож LinkedIn мені регулярно показує їхні лайки. Тому в мене складається враження, що кількість інтернатур у топовій компанії залишається такою ж.
Update: Мені в DM дали посилання на першоджерело.
The "entry-level engineer" doesn't exist anymore.
Поділюсь своєю точкою зору публічно.
Позиція Intern/Trainee буде актуальною завжди, адже нові люди приходитимуть у професію. Інша справа, що вимоги будуть змінюватися. Вони вже зараз змінюються, і в них з'являється вміння ефективно використовувати ChatGPT.
Я був у кількох кампусах США з доповідями, як Google Developer Expert. Тому в моїй мережі LinkedIn є нинішні студенти США. Тож LinkedIn мені регулярно показує їхні лайки. Тому в мене складається враження, що кількість інтернатур у топовій компанії залишається такою ж.
Update: Мені в DM дали посилання на першоджерело.


06.02.202506:24
Як цікава задачка з prompt-оптимізації нагадала перечитати документацію.
Під час експериментів із TypeSpec та LLM для генерації API-специфікацій я натрапив на кумедну, але доволі показову особливість. AI постійно пропонував додавати ендпоінти для видалення цілих колекцій!
Чому так сталось? У промті була “use the best Microsoft practices”, щоб правильно використовувався TypeSpec. Модель із ентузіазмом підхопила RESTful API design із Azure Architecture Center та вирішила, що глобальне видалення даних є чудовою ідеєю. Бо так э у прикладі. То, що так не робиться на реальних проектах, модель не враховувала. Хоча, можливо, я чогось не знаю, і це нормальний дизайн?
📌 Lesson learned: Know the best practices you ask others to follow.
Під час експериментів із TypeSpec та LLM для генерації API-специфікацій я натрапив на кумедну, але доволі показову особливість. AI постійно пропонував додавати ендпоінти для видалення цілих колекцій!
Треба видалити користувача?
Без проблем — просто викликаємо DELETE /user, і всі користувачі зникають.
Чому так сталось? У промті була “use the best Microsoft practices”, щоб правильно використовувався TypeSpec. Модель із ентузіазмом підхопила RESTful API design із Azure Architecture Center та вирішила, що глобальне видалення даних є чудовою ідеєю. Бо так э у прикладі. То, що так не робиться на реальних проектах, модель не враховувала. Хоча, можливо, я чогось не знаю, і це нормальний дизайн?
📌 Lesson learned: Know the best practices you ask others to follow.
27.01.202516:17
Вчора мені виповнилося 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. Неможливо робити все одночасно швидко, якісно та правильно. Найчастіше це недосяжно; важливо вміти перемикатися між цими режимами.
Див. 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". До речі, цей канал почався саме так.
03.12.202415:59
Інформації про зарплату це важливо. В українському IT ми дивимося DOU. В них як раз зараз триває зарплатне опитування.
Для світових зарплат я використовую glassdoor.com та www.levels.fyi. Наприклад, OpenAI найняв FullStack на $1.24M/year
Цікаво, який топ буде в аналітике DOU? Тому заповніть анкету
Для світових зарплат я використовую glassdoor.com та www.levels.fyi. Наприклад, OpenAI найняв FullStack на $1.24M/year
Цікаво, який топ буде в аналітике DOU? Тому заповніть анкету
22.10.202414:46
Олексій у коментарях до посту про види боргу пропонує не використовувати цей термін:
Така точка зору популярна у Scrum майстрів, які пропоную все що є в белог розглядати як можливості. Я ж як людина з економічною освітою пропоную вам використовувати терміни борг та інфляція в контексті технічних процесів. Вони зрозуміліші бізнесу.
Наприклад, з 5-го жовтня 2024 року 8-а версія eslint досягла end of life і більше не підтримується. Використання 8-ї або старшої є прикладом тех боргу, викликаного технічною інфляцією.
На завершення поділюсь планами на наступний стрим. Він буде як налаштувати eslint для Node.js проектів.
Я би взагалі казав би не борг, а можливість покращення, бо коли ми кажемо про можливість, то вже зрозуміло, що є ресурси (у наявності чи потенційні, байдуже). А слово борг якось тхне
Така точка зору популярна у Scrum майстрів, які пропоную все що є в белог розглядати як можливості. Я ж як людина з економічною освітою пропоную вам використовувати терміни борг та інфляція в контексті технічних процесів. Вони зрозуміліші бізнесу.
Наприклад, з 5-го жовтня 2024 року 8-а версія eslint досягла end of life і більше не підтримується. Використання 8-ї або старшої є прикладом тех боргу, викликаного технічною інфляцією.
На завершення поділюсь планами на наступний стрим. Він буде як налаштувати eslint для Node.js проектів.
07.03.202512:02
🤩🙌 Зустрічайте останнє відео з конференції React+ fwdays'24!
👨💻 Доповідь: "Effortless API Integration: SDK Generation as Best Practise" від Nikita Galkin
🎙️ Опис: «Many developers create a separate layer for working with APIs, but Nikita believes that this approach is inefficient — it is better to generate code from your API contract. The talk will cover the following topics: how does SDK differ from API, and why is SDK preferable for development? How can you automatically generate an SDK for Swagger and GraphQL? What should you do if you don’t have an API contract? And finally, why is it important for backend developers to understand React? The talk will help optimize development processes and simplify team interactions, making working with APIs more predictable and convenient».
🗣️ Мова – англійська
Дивіться відео на нашому новому каналі Fwdays Global та не забудьте підписатись! ➡️ https://youtu.be/bjp5Poutb7w?si=nCGJUcF2260EI07f
👨💻 Доповідь: "Effortless API Integration: SDK Generation as Best Practise" від Nikita Galkin
🎙️ Опис: «Many developers create a separate layer for working with APIs, but Nikita believes that this approach is inefficient — it is better to generate code from your API contract. The talk will cover the following topics: how does SDK differ from API, and why is SDK preferable for development? How can you automatically generate an SDK for Swagger and GraphQL? What should you do if you don’t have an API contract? And finally, why is it important for backend developers to understand React? The talk will help optimize development processes and simplify team interactions, making working with APIs more predictable and convenient».
🗣️ Мова – англійська
Дивіться відео на нашому новому каналі Fwdays Global та не забудьте підписатись! ➡️ https://youtu.be/bjp5Poutb7w?si=nCGJUcF2260EI07f


11.02.202513:16
Нещодавно команда Firebase випустила перший стабільний реліз Genkit. Це фреймворк для створення AI-застосунків, який можна використовувати не тільки на платформі Firebase, а й де завгодно та з будь-якими LLM. Genkit забезпечує зручний Developer Experience і має дружню спільноту. Рекомендую розглянути його для вивчення та додати до свого технологічного стеку.


05.02.202516:01
This change doesn’t require any changes for TypeORM, Nest.js GraphQL enums, etc.
23.01.202516:54
Скоро починаємо https://www.youtube.com/watch?v=L-65TzJT24k
29.10.202417:58
WebStorm тепер безкоштовний для некомерційного використання!
JetBrains оголосила: тепер WebStorm доступний безкоштовно для навчання, open-source, хобі та створення контенту. Комерційні проєкти залишаються під платною ліцензією.
Це означає, що ви отримуєте повний функціонал IDE без обмежень! Єдина різниця — замість повної версії Code With Me, у безкоштовній ліцензії доступна лише його Community-версія.
Як отримати ліцензію?
1. Встановіть WebStorm і відкрийте.
2. Виберіть “Non-commercial use”.
3. Увійдіть у свій JetBrains-акаунт.
4. Погодьтеся з умовами.
💡Важливо: анонімну статистику збирають обов’язково, вимкнути її неможливо.
JetBrains оголосила: тепер WebStorm доступний безкоштовно для навчання, open-source, хобі та створення контенту. Комерційні проєкти залишаються під платною ліцензією.
Це означає, що ви отримуєте повний функціонал IDE без обмежень! Єдина різниця — замість повної версії Code With Me, у безкоштовній ліцензії доступна лише його Community-версія.
Як отримати ліцензію?
1. Встановіть WebStorm і відкрийте.
2. Виберіть “Non-commercial use”.
3. Увійдіть у свій JetBrains-акаунт.
4. Погодьтеся з умовами.
💡Важливо: анонімну статистику збирають обов’язково, вимкнути її неможливо.
21.10.202417:45
У соціальних мережах заведено ділитися лише успіхами, а невдачі називати досвідом. Це створює викривлене уявлення про реальність.
Один з підписників питає:
Відповім на це публічно та поділюся своєю невдачею. У мене саме так відбувається з навчанням 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”
Один з підписників питає:
можна в тебе спитати, чи в тебе бувало відчуття, що ти ніби вчишся і кінця краю тому не видно, і є сумнів в тому що ти навчаючись не гаїш час і рухаєшся далі?
Відповім на це публічно та поділюся своєю невдачею. У мене саме так відбувається з навчанням 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”
21.02.202515:02
У середу готовув контент по курсу AI-Enabled Developer Experience та спіймав комплекс самозванця. Усвідомив, що багато функцій WebStorm та Visual Studio я не тільки не використовую, а й навіть не знаю про них.
Тому сьогодні хочу поділитися з вами фічею для WebStorm, що називається Endpoints та чудова працує з NestJS. Згідно з документацією вона повинна працювати з Express, можливо, з Fastify, але, здається, зараз вона зламана. Демонстрація фічі на відео.
Можливо зробити ще простіше, ніж на відео shift+shift /url feed
Catch that DevEx vibe!
Учора вперше використав її під час парного програмування з колегою. Відкрив мікросервіс, над яким він працює. Знайшов у Endpoint потрібний роут, поставив Breakpoint, та почав дебаг. Зворотний зв'язок від колеги, він автор цього мікросервісу, так швидко це не зміг би зробити.
Тому сьогодні хочу поділитися з вами фічею для WebStorm, що називається Endpoints та чудова працує з NestJS. Згідно з документацією вона повинна працювати з Express, можливо, з Fastify, але, здається, зараз вона зламана. Демонстрація фічі на відео.
Можливо зробити ще простіше, ніж на відео shift+shift /url feed
Catch that DevEx vibe!
Учора вперше використав її під час парного програмування з колегою. Відкрив мікросервіс, над яким він працює. Знайшов у Endpoint потрібний роут, поставив Breakpoint, та почав дебаг. Зворотний зв'язок від колеги, він автор цього мікросервісу, так швидко це не зміг би зробити.
10.02.202515:12
Розіслав електронні листи учасникам AI-Enabled Developer Experience. Перевірте свою пошту.
04.02.202512:47
Один із моїх менті (світчер) поставив цікаве питання:
Питання справді чудове, тож поділюся своєю відповіддю публічно.
Я почав працювати напряму з США у 2016 році. Спочатку було незвично: у свої 30 років я був наймолодшим на дзвінках. Тоді на DOU жартували, що після 30 програмістів «спускають по Дніпру». А тут середній вік команди був близько 40.
Мене теж хвилювало питання: що я робитиму в 40, 50, 60 років?
Зараз мені 40, і я вже давно не переймаюся віком. Мабуть, допоміг приклад Джона, з яким ми працювали у 2021 році. У 70 років йому набридло бути менеджером, але й на пенсію він не захотів. Тож він вивчив React і зайнявся фронтендом. Його життєвий досвід поєднувався з технічною “незашореністю”, тому працювати з ним було справжнім задоволенням.
Окремо хочу зупинитися на технічній незашореності. На співбесідах я завжди кажу щось на зразок:
Цю фразу з not married я якраз запозичив у Джона. А же досвід роботи з ним став для мене чудовим щепленням від ейджизму.
скажи чи є програмісти після 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 я якраз запозичив у Джона. А же досвід роботи з ним став для мене чудовим щепленням від ейджизму.
21.01.202514:55
Вчора Matt Pocock, автор TotalTypeScript, опублікував свій безкоштовний курс з Vercel's AI SDK.
Пройти його займе один вечір. Він не замінить, а доповнить читання документації.
Рекомендую для перегляду.
Пройти його займе один вечір. Він не замінить, а доповнить читання документації.
Рекомендую для перегляду.
25.10.202413:50
Сьогодні поширю мої загальні питання для технічних співбесід:
1. Ось package.json з нашого проєкту. Які в тебе виникають запитання щодо його вмісту? Прокоментуй залежності: з чим тобі подобається працювати, що б ти замінив і чому? З чим ще не стикався?
2. Покажи свій package.json з поточного проєкту (якщо це не порушує NDA) або pet-проєкту. Я оберу кілька пакетів і поставлю питання про них.
3. Уяви, що тепер ти інтерв'юєр. Як би ти перевіряв знання з теми? Які б 3 питання ти поставив (просте, середнє, складне)? Можна вибрати одне з них та попросити кандидата відповісти.
4. Розкажи мені про недоліки в роботі з TypeScript, Nest.js, TypeORM, GitHub Actions, монорепозиторіями тощо. Це допомагає побачити глибину розуміння та досвід використання.
5. Уяви, що в продакшені виникла проблема, і застосунок почав працювати повільно. Як би ти діагностував і визначив причину? Це чудова можливість перевірити знання інфраструктури, моніторингу, логування та відповідних інструментів.
6. Як ти організовуєш обробку помилок у застосунку?
7. Що з останніх новинок у JavaScript-екосистемі ти вже випробував? Які твої враження?
8. Як ти працюєш з обмеженням API Rate Limiting? Перевіряє знання управління навантаженням, повторних спроб (retry) та масштабування застосунку.
9. Розгляньмо кейс: я — продакт-оунер і хочу, щоб ти реалізував фічу X. Які питання по вимогах ти б поставив і як би ти декомпозував їх у завдання для розробки?
10. Які в тебе є питання за підсумками сьогоднішнього інтерв'ю?
Використання такого формату запитань допомагає проводити співбесіду як розмову між двома колегами, а не як іспит.
1. Ось package.json з нашого проєкту. Які в тебе виникають запитання щодо його вмісту? Прокоментуй залежності: з чим тобі подобається працювати, що б ти замінив і чому? З чим ще не стикався?
2. Покажи свій package.json з поточного проєкту (якщо це не порушує NDA) або pet-проєкту. Я оберу кілька пакетів і поставлю питання про них.
3. Уяви, що тепер ти інтерв'юєр. Як би ти перевіряв знання з теми
4. Розкажи мені про недоліки в роботі з TypeScript, Nest.js, TypeORM, GitHub Actions, монорепозиторіями тощо. Це допомагає побачити глибину розуміння та досвід використання.
5. Уяви, що в продакшені виникла проблема, і застосунок почав працювати повільно. Як би ти діагностував і визначив причину? Це чудова можливість перевірити знання інфраструктури, моніторингу, логування та відповідних інструментів.
6. Як ти організовуєш обробку помилок у застосунку?
7. Що з останніх новинок у JavaScript-екосистемі ти вже випробував? Які твої враження?
8. Як ти працюєш з обмеженням API Rate Limiting? Перевіряє знання управління навантаженням, повторних спроб (retry) та масштабування застосунку.
9. Розгляньмо кейс: я — продакт-оунер і хочу, щоб ти реалізував фічу X. Які питання по вимогах ти б поставив і як би ти декомпозував їх у завдання для розробки?
10. Які в тебе є питання за підсумками сьогоднішнього інтерв'ю?
Використання такого формату запитань допомагає проводити співбесіду як розмову між двома колегами, а не як іспит.
16.10.202417:07
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.
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.
Shown 1 - 24 of 605
Log in to unlock more functionality.