З Днем Конституції України!
Дуже хочу побажати, щоб ми усі краще дотримувалися її положень, а наша країна гідно пройшла перевірку історією. Як цього досягти я не знаю, а тому краще розповім те, що знаю.

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

- Зміни через RFC (Request for Comments): якщо у вас є ідея щодо поліпшення коду/процесу, ви можете створити документ RFC, в якому детально описати вашу пропозицію. Цей документ потім обговорюється всіма зацікавленими сторонами, і після внесення змін і затвердження, ваша пропозиція впроваджується у проект. У веб-розробці RFC використовуються для стандартизації нових веб-технологій та протоколів, таких як HTTP, TLS, etc. приклад rfc-editor.org

- Щоб у вашого продукту/коду була якісна документація, можна застосовувати підхід Documentation First. Ідея зрозуміла будь-кому, хто використовував API First, UX First тощо. Спочатку ми пишемо документацію і збираємо на її основі зворотний зв’язок у користувачів. Приклад у Google

– Handbook, який описує всі сфери у компанії та всі процеси, інструменти, політики та стандарти. Такий підхід допомагає забезпечити єдині стандарти роботи і полегшує адаптацію нових співробітників. Крутий приклад у resend.

🇺🇦💙💛

За 10 хвилин починаємо:
- приєднатися, щоб поставити запитання на платформі GDG
- Подивитись онлайн на ютуб

Чому я не використовую znv?

Нещодавно мій менті запитав, чому я попросив його відмовитися від використання znv (zod + env) і замінити його на використання dotenv-safe та безпосередньо zod. Тож, моя відповідь на це така:

1️⃣ Ваш додаток під час запуску має перевіряти наявність environment-змінних. Детальніше у 12 factor app. Якщо якась із змінних не вказана, не можна використовувати значення за замовчуванням. Замість цього необхідно викинути помилку, щоб аварійно завершити роботу. Це допоможе уникнути людських помилок, коли при релізі на продакшн забули додати нову env змінну, а default value призведе до некоректної роботи нової функції.

2️⃣ Як single source of truth про потрібні вашому додатку змінні слід використовувати .env.example. Цей файл слугує документацією та його ми зберігаємо у корні репозиторію. На рівні коду dotenv-safe (який є обгорткою над dotenv) зчитає ваш .env.example та порівняє з process.env.

3️⃣ Потім у вашему config-service можна трансформувати interface ProcessEnv extends Dict<string>, тобто process.env['VAR_NAME'] має тільки string | undefined значення. та валідувати значення за допомогою zod, чи як вам подобається.

Тому використання znv має наступні проблеми:
👎 погіршує DevEx, бо замість .env.example потрібно дивитися у код
👎 znv дозволяє використовувати значення за замовчуванням

Давно не проводив #like_and_share. Мета гри - поділитися своїм досвідом та дізнатися про досвід інших учасників. Правила:

1. Публікація в каналі визначає тему. Сьогодні це автори контенту на тему каналу @node_recipes (Node.js, JS/TS, Cloud Native)
2. У коментарях кожен може залишити посилання на автора, якого він читає, і коротко описати, чому його контент є корисним.
3. Учасники голосують, використовуючи лайки. Не ставте негативні лайки, бо вони також зараховуються як позитивні.
4. Завтра ми підведемо підсумки на YouTube-стрімі. Переможець отримає 12-місячну персональну підписку на будь-яке IDE від JetBrains.

Сьогодні о 19 по Києву Node.js Weekly 2024-W13: From Node.js Developer to Cloud Engineer. Під час трансляції підведу підсумки like_and_share, тому запрошую долучатися!

Сподіваюся у вас є світло і ви підключаєтеся, бо я починаю ефір.
До зустрічі!

Як працює 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 autocorrect
git config --global help.autocorrect immediate
git sttaus # Runs `git status` immediately

# Prompt for confirmation before autocorrect
git config --global help.autocorrect prompt
git sttaus # Asks for confirmation before running `git status`

# Disable autocorrect
git config --global help.autocorrect never
git sttaus # Does not autocorrect

# Enable autocorrect with a 1 second delay
git config --global help.autocorrect 10
git sttaus # Runs `git status` instead, after a 1 second delay

Подібна функція є у zsh: CORRECT/CORRECT_ALL з prompt-виправленнями. Автоматичні виправлення на рівні системи, а не окремих команд, дуже ризиковані, тому такого не існує.

На завершення нагадаю, що у git tips є багато порад.

Де вчити 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⚠️

TypeScript support has landed🛬🛬🛬🛬🛬

На каналі давно не було рецептів, а ще довше технічних байок. Поділюсь з вами історією About estimates.

Від бізнесу надійшов запит на інтеграцію з одним популярним сервісом. Аналіз документації показав, що потрібна функція існує, тому інтеграція буде простою – налаштувати webhook на нашій стороні та надіслати запит до сервісу на включення сповіщень через цей webhook. Досвід роботи з цим сервісом є. Завдання зрозуміле. Беремо в наступний спринт. Як досвідчений менеджер, я розбив це завдання на два тікети: включення сповіщень у цьому сервісі та написання webhook-а.

Вгадайте, скільки часу цей популярний сервіс підключав сповіщення на своїй стороні?
Це зайняло 5 місяців, більше 20 звернень до служби підтримки/форуму. Місяць на переконання, що проблема на їх стороні. Вони таки визнали, що є баг на рівні інфраструктури, і виправлять його у наступному великому релізі через 2 місяці!!! Потім ще місяць на повторне переконання, що проблема не зникла. А потім ще місяць на виправлення бага вже на рівні коду.

Спробуйте вгадати, що це за сервіс?
Це Zoom. Бізнес попросив зберігати файли з чату. Кому цікаві конкретні деталі, ось посилання: https://devforum.zoom.us/t/is-webhook-meeting-chat-message-file-sent-work/113881

Які висновки можна зробити з цієї історії?
Не вірте документації, а перевіряйте її. Для цього і робиться Proof of Concept. А ще розбивайте завдання на частини, особливо коли йдеться про інтеграцію.

Як сортувати рядки?

Більшість із вас знають, що для сортування рядків у JavaScript існує localeCompare. Дозволяє легко відсортувати рядки. Приклад:
names.sort((a, b) => a.localeCompare(b));

Приклад з урахуванням локалі
names.sort((a, b) => a.localeCompare(b, 'uk'));

Приклад для сортування рядків, що містять числа, у більш зрозумілий для людини спосіб:
["a2", "a10", "a1"].sort((a, b) => a.localeCompare(b, undefined, { numeric: true }))
// Result: [ 'a1', 'a2', 'a10' ]

Взагалі, у третього аргументу Intl.CollatorOptions, крім numeric, є ще 6 можливих ключів, і знати їх напам’ять, звісно, ніхто не буде. Але давайте ще раз їх повторимо:
👉 caseFirst: Контролює позицію великих і малих літер у порядку сортування. Значення:
• "upper": Сортує великі літери перед малими (наприклад, “А” перед “а”).
• "lower": Сортує малі літери перед великими (наприклад, “а” перед “А”).
• "false" (значення за замовчуванням): Використовується порядок за замовчуванням для локалі.
👉 ignorePunctuation. Тип: boolean.  Корисно, коли потрібно порівнювати рядки, де пунктуація не повинна впливати на результат. Значення:
• true: Ігнорує пунктуацію під час порівняння.
• false (значення за замовчуванням): Враховує пунктуацію.
👉 sensitivity. Контролює, наскільки детальним є порівняння з точки зору регістру, акцентів і базових символів. Значення:
• "base": Враховує лише базові літери (“а” і “А” вважаються рівними).
• "accent": Враховує акценти, але ігнорує регістр (“é” і “e” різні, але “e” і “E” вважаються рівними).
• "case": Враховує регістр, але ігнорує акценти (“а” і “А” різні, але “а” і “ä” вважаються рівними).
• "variant": Враховує як регістр, так і акцентні відмінності (“а”, “А”, “ä” і “Ä” всі різні).
👉 usage. Визначає, чи оптимізовано порівняння для пошуку або сортування. Використовується з new Intl.Collator, а не localeCompare.
👉 localeMatcher. Визначає, як вибирається локаль, якщо ви вказали декілька локалей.
👉 collation. Зазвичай використовується для специфічних мов або застосунків, які потребують певної колації, але в більшості випадків це не є необхідним.

На завершення нагадаю, що сортування на рівні коду — це завдання для FE/BFF. У чистому BE сортування виконується на рівні бази даних. Для сортування за локаллю у нас є COLLATE. Приклад:
SELECT * FROM table_name ORDER BY column_name COLLATE "en_US";
Але якщо вам потрібні аналоги CollatorOptions, то SQL такого на жаль не має.

Давно не було #like_and_share. Мета гри - поділитися своїм досвідом та дізнатися про досвід інших учасників. Правила:

1. Публікація в каналі визначає тему. Сьогодні це developer tools. Приклади: Visual Studio Code, Postman.
2. У коментарях кожен може залишити посилання на інструмент, коротко його описати, та чому інструмент є корисним.
3. Учасники голосують, використовуючи лайки. Не ставте негативні лайки, бо вони також зараховуються як позитивні.
4. Наступного тижня ми підведемо підсумки на YouTube-стрімі. Переможець отримає 12-місячну персональну підписку на будь-яку IDE від JetBrains.

Як дізнатися, що пакет оновився?

В опитуванні Паша запитав: “А де варіант ‘одержимо перевіряю, чи є оновлення пакетів щодня’?”

Відповім: Це це не шлях розробника. Ти бачиш суслика вомбата? А він є! У першому варіанті.
Колись була CLI утиліта wombat. Зараз цей функціонал увійшов до складу npm hook. За допомогою цієї команди ми можемо налагоджувати webhook о нових релізах. Наприклад, у одному internal тренінгу ми робили slack нотіфікацію з допомогою AWS lambda та цього npm hook.

Там команда express.js випустила нову версію. П'яту! Не чіпай це на новий рік.
Огляд робити рано тому, що:
- npm i express ставитиме четверту, бо тег latest не переставили
- зміну з п'ятої в майстер не додали
- немає документації з міграції 4-5
- не оновлено @types/express

Завтра о 18-му по Києву проведу стрім, у якому зробимо розбір інструментів.
Якщо ви не поділилися досвідом і не проголосували за коментарі інших учасників ком'юніті, то настав час це зробити

До зустрічі в ефірі!

On air https://www.youtube.com/live/KujLK9gJ6Vo