За підсумками тема вебінару GitHub ecosystem review for Google Cloud projects.

📅: 15 червня, 17:00-19:00

Программа:
– Огляд екосистеми GitHub
– Хмарні служби Google, які використовуються з GitHub
– GitHub Actions for CI/CD to Google Cloud
– GitHub Certifications: яку сертифікацію вибрали, навчальні матеріали, як отримати безкоштовний ваучер, як скласти іспит

Вебінар проходитиме на платформі GDG, тому для участі необхідно зареєструватись. Запис вебінару буде здійснено шляхом трансляції на youtube.

До зустрічі!

За 5 хвилин починаємо GitHub ecosystem review for Google Cloud projects.
Подивитись на YouTube https://www.youtube.com/live/A8MTTZqJ5zc
Підключитися, щоб поставити запитання https://gdg.community.dev/events/details/google-gdg-cloud-kyiv-presents-github-ecosystem-review-for-google-cloud-projects/

Через 20 хвилин проведу TypeScript new features and ecosystem review

Початок о 19 по Києву. До зустрічі в ефірі!

Закінчую матеріали з GitHub сертифікації статтею на Dou.
Розписав усі етапи. Зверніть увагу на лайфхаки.

​​Навіщо використовувати eslint правило no-process-env?

Відповідно до 12-факторного маніфесту, для конфігурації застосунку використовуються змінні середовища (env variables). Для звернення до них у Node.js використовується process.env.

Для правильного використання process.env існує правило no-process-env. Це правило зробить ваш код більш послідовним, використовуючи один файл для налаштування вашого застосунку. Тобто, ви використовуєте це правило по всьому проекту, а в файлі config.ts вимикаєте його для всього файлу.

А ще цей підхід покращує продуктивність застосунку завдяки зверненню до кешованого значення замість прямого читання з process.env. Ось приклад коду, за допомогою якого ви можете переконатися в різниці.

UPDATE: Додав cacheObject до коду

#code_only

Коли ніхто не показав FE розробнику фуллстеку, що можна фільтрувати на рівні бази даних.

Аксель Раушмайер оновив свою книгу Exploring JavaScript. Тепер вона включає ECMAScript 2024. Рекомендую!

​​В JS функціональний код повільніший, ніж імперативний.

На картинці приклад коду. Результат його роботи:
❯ node example.js
functional: 7.782ms
for of: 3.851ms
for: 2.853ms

Коли вам знадобиться цей факт? При працевлаштуванні у Big Tech або Enterprise компанію. Цей рецепт саме для таких людей. Адже одним із етапів відбору в такі компанії часто є алгоритми, як правило з автоматизованою перевіркою. Один в один, як на олімпіадах зі спортивного програмування.

Під час алгоритмічного інтерв’ю використання функціонального стилю може знизити ваші шанси на роботу. Поясню чому:
– функціональний код використовує N циклів на N операцій, замість 1 циклу на N операцій. У прикладі операцій 2 – перевірка парності та підсумовування.
– функціональний код використовує додаткову пам’ять на кожному map/reduce/etc.

А ось при розробці цей факт впливає мало. Оскільки Node.js у комерційній розробці рідко використовується для обчислень (Node.js замінюють більш підходящими технологіями), а ці мікрооптимізації шкодують читабельності/підтримуваності коду.

Наступний вебінар Google Cloud service review: Cloud Run

📅: 29 червня, 17:00-19:00

Программа:
– Що таке Cloud Run
– Cloud Run VS Cloud Function VS Firebase Function
– Cloud Run Service VS Cloud Run Job
– Integrations
– New Cloud Run features

Доповідачі:
– Віктор Турський, Senior Software Engineer, Google, веде @jabascript
– Нікіта Галкін, GDE, Cloud Architect, Independent Contractor, веде @node_recipes

Вебінар проходитиме на платформі GDG, тому для участі необхідно зареєструватись. Запис вебінару буде здійснено шляхом трансляції на youtube.

До зустрічі!

Monolith requires consistency
✅ Codestyle Consistency – Prettier/Eslint/EditorConfig
✅ Data Consistency – Database Migrations
✅ Process Consistency – Checklists

PS Жарт 7-річної давності: “Галкін любить ставити галочки”

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

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

- Зміни через 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🛬🛬🛬🛬🛬