Node.js Recipes

Як працює 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 є багато порад.

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

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

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

Чому я не використовую 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 дозволяє використовувати значення за замовчуванням

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

З Днем Конституції України! Дуже хочу побажати, щоб ми усі краще дотримувалися її положень, а наша країна гідно пройшла перевірку історією. Як цього досягти я не знаю, а тому краще розповім те, що знаю. Ось кілька ідей для вашого процесу розробки на тему дня: - Зміни через RFC (Request for Comments): якщо у вас є ідея щодо поліпшення коду/процесу, ви можете створити документ RFC, в якому детально описати вашу пропозицію. Цей документ потім обговорюється всіма зацікавленими сторонами, і після внесення змін і затвердження, ваша пропозиція впроваджується у проект. У веб-розробці RFC використовуються для стандартизації нових веб-технологій та протоколів, таких як HTTP, TLS, etc. приклад rfc-editor.org - Щоб у вашого продукту/коду була якісна документація, можна застосовувати підхід Documentation First. Ідея зрозуміла будь-кому, хто використовував API First, UX First тощо. Спочатку ми пишемо документацію і збираємо на її основі зворотний зв’язок у користувачів. Приклад у Google – Handbook, який описує всі сфери у компанії та всі процеси, інструменти, політики та стандарти. Такий підхід допомагає забезпечити єдині стандарти роботи і полегшує адаптацію нових співробітників. Крутий приклад у resend. 🇺🇦💙💛

Monolith requires consistency ✅ Codestyle Consistency – Prettier/Eslint/EditorConfig ✅ Data Consistency – Database Migrations ✅ Process Consistency – Checklists PS Жарт 7-річної давності: “Галкін любить ставити галочки”

Наступний вебінар 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. До зустрічі!

​​В 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 замінюють більш підходящими технологіями), а ці мікрооптимізації шкодують читабельності/підтримуваності коду.