#code_only 🦄

При складанні плану розвитку інженера я завжди додаю проходження сертифікації. Наприклад, у план розвитку Junior➡️Middle Node.js Developer я додаю AWS Certified Developer. Інженер покращує резюме, бізнес посилює внутрішню експертизу та можливості партнерства з вендорами за рахунок наявності сертифікованих інженерів.

itskills4u.com.ua надає для українців можливість отримати безкоштовну підготовку та ваучери на сертифікації AWS. Рекомендую скористатися цією можливістю та посилити свої знання та резюме.

Судячи з лайків, вам сподобалася минула історія. Вечір п'ятниці, отже час нової!

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

Справа була у той час, коли я ще працював українському аутсорсі. Щоб бути точним, це була модель Team Extension, тобто з нашого боку інженери, які доповнюють існуючу інженерну команду замовника.

На третьому-четвертому тижні моєї роботи над проектом, мене зацікавило, над чим працює інженер з команди замовника. Він протягом усього цього часу на кожному щоденному мітингу розповідав про статуси однієї й тієї ж функціональності. Його код регулярно мерджився, але функціональність не віддавалася на тестування. Код виглядав дуже погано, код-рев'ю з нашого боку не проводилося, оскільки це потребувало знання сервісів, що розробляються тією командою.

Під час knowledge sharing архітектор замовника розповів, що інженер реалізує функціонал, який вже був створений як CLI утиліта. Цю утиліту написали і підтримують інженери компанії для інтеграції сервісів. Тобто інженер розбирався в коді утиліти та переписував його на JavaScript. Причому, планів відмовлятися від утиліти не було. Архітектор розумів, що такий підхід руйнує single source of truth, але не знав, що з цим робити. Я запропонував зробити рефакторинг, який включатиме CLI як частину додатку. Тоді код у Node.js просто буде викликати CLI утиліту як дочірній процес та спостерігати за виведенням.

Завдання-рефакторинг було додано у наступний спринт. Я провів сесію парного програмування з інженером і показав йому приклад з документації Node.js щодо child_process. Виявилося, що у утиліти навіть є прапорець --json, тому не потрібно було розбирати формат її відповіді. Ось так понад 1000 рядків коду перетворилися на 50, що не потребували тестування і були готові до змін.

Проекти на Node.js рідко використовують Oracle як базу даних. Проте розробникам Node.js варто знати, що Oracle Cloud Infrastructure входить до Топ-10 хмарних провайдерів. Подібно до AWS/GCP/Azure, OCI має сертифікації. Наразі триває програма "Безкоштовна сертифікація для OCI". Вона надає можливість отримати безкоштовну підготовку та скласти дві сертифікації (зазвичай 250 $ x 2). Детальніша інформація доступна тут.

Які типи запуску може мати Serverless?
#architecture #aws

Нагадаю базові речі, будь-який serverless будується на основі на Docker. Якщо це функції, лямбди, тобто Serverless Function, то Cloud вендор надає вам Docker Image куди платформа додасть ще один layer із вашим кодом. Якщо це Serverless Container, то запускатиметься той Docker Image, який ви дали. В обох випадках запускається саме докер-контейнер.

Приклади Serverless functions:
👉 AWS Lambda
👉 Azure Functions
👉 Cloud Functions

Приклади Serverless container:
👉 AWS Fargate
👉 Azure Container Instances
👉 Google Cloud Run

Тип запуску визначається саме станом контейнера:
❄️ Холодний старт (Cold Start) - це процес запуску у серверлес-середовищі, коли контейнер не існує та Docker Image відсутній. При такому запуску відбувається ініціалізація середовища та завантаження Docker Image, що призводить до затримок у відповіді на запити.
☀️Теплий старт (Warm Start) - це стан, коли серверлес-середовище має наявний Docker Image, але потрібно створити новий Docker Container. Під час запуску контейнера додаток може підключатися до бази даних та інших необхідних ресурсів.
🔥Гарячий старт (Hot Start) - це стан, коли Docker Container залишається активним у серверлес-середовищі після обробки попередніх запитів. Це найшвидший стан, оскільки контейнер вже повністю завантажений і готовий до негайного виконання наступних запитів.

Саме тому я використовую не прогрівання Serverless Functions, а Servless Container, який може бути викликаний не одним, а кількома тригерами, тому частіше перебуває у гарячому чи теплому стані.

⚠️ Рецепт написаний, як пояснення чому суттєвого прискорення shared Lambda layers у разі холодного старту ваших AWS лямд не дає.

AWS відкрив прийом заявок на наступну когорту Community Builders.

Я сам є учасником цієї програми. Ось, що надає участь в цій програмі:
👉 доступ до Slack разом з іншими AWS Community Builders, AWS Hero та співробітниками AWS;
👉 доступ до закритих вебінарів та альфа-версій продуктів;
👉 500 доларів AWS кредитів, з можливістю запитати ще від керівника мого напрямку;
👉 ваучер на одну сертифікацію щорічно;
👉 річна підписка на Cloud Academy;
👉 swag kit (мерч)

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

Зверніть увагу, що не має значення мати 10+ років досвіду. Контент від Junior спеціаліста для Junior спеціалістів також потрібен. Тому, якщо ви створюєте контент, а тим більше на українській мові, подайте заявку. Крайній термін - 13 липня.

Сьогодні буде рекурсивна байка, тобто байка про байки.

Знову йтимемо про той самий проект, де був Team Extension. До нас приїхали інженери зі Сполучених Штатів. Ввечері ми замовили ресторан для спільної вечері. Стіл швидко розійшовся на дві половини. Як сказав би психолог, для підтримки групової комунікації необхідна спільна тема, близька кожному за цінностями. Я запропонував поділитися особистими історіями про одне й те саме. І це спрацювало! Уявіть, кожен інженер за столом розповідає байку "а як ти заробив свою першу зарплату і на що її витратив?". Це виглядало як гра, де важливий процес, а не бажання порівнятися досвідом. Комунікація встановилась і під байки про "Яким був твій перший комп'ютер і як він з'явився у тебе?" ми вирушили на bar crawling у районі Бессарабки.

Гра мені сподобалася. Я навіть пропонував у неї зіграти на кількох афтерпаті на конференціях. Якщо будете в неї грати бажаю вам приємної компанії та веселих байок.

Що таке Variable Shadowing?

У багатьох мовах програмування є можливість затінення змінних (Variable Shadowing). Затінення змінних полягає в оголошенні змінної в більш внутрішній області видимості з таким самим ім'ям, яке існує в зовнішній області видимості. Приклад у JavaScript:
function myFunc() {
const my_var = 'test';
if (true) {
const my_var = 'new test';
console.log(my_var); // new test
}
console.log(my_var); // test
}

Використання цієї можливості погіршує зрозумілість коду і може легко призвести до складно виявимих помилок. Тому я вважаю це поганою практикою. У своїх проектах я використовую eslint правило no-shadow для JS-коду та @typescript-eslint/no-shadow для TS. Вони не входять до recommended, тому їх необхідно самостійно визначати у конфізі.

На завершення історичний екскурс:
- синтаксис CoffeeScript забороняв Variable Shadowing
- tslint recommended мав no-shadowed-variable за умовчанням

Як зрозуміти, чи є технічний лід на проекті?
#list
Протягом останніх 3 років я провів architecture review понад 20 Node.js проектів. Завдання цього огляду — оцінити стан проекту, тобто майбутній беклог, кодову базу та команду. Третина з них залучала українські команди. Співвідношення між in-house та outsource було 50% на 50%. Зазвичай, на проекті була відсутня посада архітектора/технічного ліда. Найпопулярнішим запитом від бізнесу: "Кого з поточної команди слід призначити технічним лідером? або його потрібно найняти ззовні?". При сильній внутрішній експертизі не залучають консультантів. На внутрішню експертизу погано вплинули COVID-19, війна та рецесія.

Ось підбірка питань з коментарями, які команди почули від мене:
1. Давайте відкриємо package.json. У залежностях є пакет "...". Яку функцію він виконує? На одному індійському проекті мені пояснювали, чому вони використовують пакет process, але не могли пояснити, чому після npm uninstall process, додаток продовжує працювати.
2. Який середній час збирання в CI/CD-пайплайні? Як і чому він змінювався протягом останнього кварталу?
Сумно, що на всіх проектах в CD не було GitHub Action concurrency або його аналогів.
3. Як організовано версіювання на проекті? Яка версія зараз працює на якому середовищі?
Один канадський проект порадував наявністю одного середовища з canary releases та feature flags. Лідером був QA, який виконував також обов'язки DevOps.
4. Давайте я через Postman або фронтенд надішлю запит. Покажіть мені, як знайти відповідні логі? На жодному продуктовому проекті я не зміг отримати демонстрацію, хоча продуктовим компаніям важливі troubleshooting skills у інженерів.
5. Я бачу, що ви використовуєте TypeScript (так само було у 90%). Але ви не використовуєте генерацію коду на клієнті або з вашої DSL. Чому? Найпростіша рекомендація але, вона вимагає змін у всьому процесі розробки. У одному аутсорс-проекті до списку питань для співбесіди додали AST (абстрактне синтаксичне дерево), але не задачі на найближчий місяць.
6. Яка у вас стратегія тестування? На всіх проектах була стратегія тестування, але всі скаржилися, що немає часу на тести, на погашення технічного боргу. Доповнюючі стратегії для rollback, promote и hotfix були лише на трьох аутсорс-проектах.
7. Як ви організовуєте код у вашому проекті? Розподіл був таким: проекти з Nest (40%), моноліт (20%) та мікросервіси (40%). Найгірше було з проектами на мікросервісах – їх запроваджували надто рано. Винятком був лише один проект, де використовувався Python для AI/ML та Node.js для API.
8. Покажіть мені метрики вашого Node.js? А інфраструктури? Чи є алерти? 80% проектів переадресовують ці питання до DevOps-ів.
9. Які плани на наступний спринт? Чи є технічний беклог? Як він наповнюється? До рев'ю бізнес вірить, що у нього FullStack розробники, а після відповіді на це запитання починає здогадуватися, що є поділ на FE/BE.
10. Що мені варто вас запитати, щоб відобразити важливе для вас у моєму звіті? всі попередні питання по суті є прелюдією, щоб техлід почав довіряти та виявив себе. На цей момент вже очевидно, чи є технічний лід на проекті, і якщо він є, то він говорить про проблеми, які необхідно продати бізнесу.

Я собі обіцяв цього року запустити курси по ноді.
Тому прошу 3 хвилини вашого часу, щоб краще зрозуміти, як це правильно зробити.
👉 https://forms.gle/fvpuhr2Yw4kJiyaC9

Звичайне питання від новачка у Nest.js в одному з телеграм чатів:
Всім привіт не підкажете як в relations отримати тілки частину полів від entity. 
Наприклад є UserEntity але мені не потрібно виводити поле password

Відповідь на запитання у Find Options є select. це вкладений об'єкт, у якому можна вказати select для зв'язків.

але тут ще можна додати:
1) архітектура коду
1.1) Додаток не має ResponseDTO layer. Зміна DB entities не повинна ламати REST
1.2) використання autoincrement id не рекомендується у реальних проектах. Краще використовувати nanoid і тому подібне.
2) Робота з помилками.
2.1) reThrow повинен мати cause
2.2) краще використовувати не базову помилку, а свої або вбудовані
3) Безпека
3.1) Зберігати паролі не можна. Натомість зберігають його хеш.
3.2) Виглядає як чергова спроба написати свій сервіс авторизації замість того, щоб використовувати Firebase Auth, Auth0, etc

питання в тому, а чи потрібно новачкові такий зворотний зв'язок.

Розпочну з актуальних новин. Як ви знаєте, учора Zuckerberg та компанія випустили прямого конкурента Twitter під назвою Threads. По суті, це pivot Instagram-у. Для тих, хто далекий від стартапів, поясню цей термін. Pivot - це зміна основної концепції/цільового ринку/продукту. При релізі таких продуктів часто є баги. Наприклад, у функції Threads, яка дозволяє поділитися посиланням на профіль, створюється неправильне посилання. Уявіть кількість маркетологів, які публікують: "Підписуйтесь на нас в Threads", а посилання не працює?

Можна було б згадати байку про принцип "If you wait until your product is bug-free before releasing it, you're already late.", але сьогоднішня байка про pivot.

Байка може містити спрощення технічних деталей, а також свідоме спотворення автором фактів, згаданих у байці. Це робиться як для дотримання норм NDA, так і для надання байці більшої літературної цінності. Тому вважайте всі збіги у байці випадковістю, а сюжет і персонажі - вигадкою автора.

Я робив рев'ю кодової бази та інфраструктури додатку, що пережив pivot двічі. Клон чат-рулетки перетворили на Dating додаток, а потім він став маркетплейсом з функцією відео-дзвінків. Якщо вважати, що pivot перетворює greenfield проект на легаси, то це був легаси у квадраті. Технічний борг досяг такого рівня, що було дешевше переписати все спочатку, ніж підтримувати. Це ще називають технічна смерть.

Після рев'ю засновник прийняв рішення продати проект. Тільки покупців на продукт цілком чомусь не знайшлося. Тому він продав базу даних користувачів. Одну з трьох, що мав.

Система моніторингу надсилає мені повідомлення щодо коду відповіді 500 з мого сервера. Зазвичай це означає наявність помилки на моєму сервері, яку потрібно виправити.
Однак, для мене та інших українців, сьогодні число 500 має інший зміст. 500 днів триває війна.💙💛

Огляд Node.js 20: URL.canParse
#node20

З новою версією Node.js 20 ми отримуємо зручний статичний URL.canParse. Цей метод допомагає визначити, чи є валідним URL. Його синтаксис:
URL.canParse(url)
URL.canParse(url, base)

Раніше до цього треба було використовувати try catch та new URL. Приклад:
try {
new URL('https//invalid-url.com')
} catch (error) {
console.error(error)
}

Підтримка цього методу в браузерах поки слабка, але core-js має polyfill. Детальніше у MDM. Ще фронтедерам нагадаю, що HTML5 має вбудований тип введення URL - <input type="url">, який можна використовувати для перевірки даних від користувача.

Що змінилося у розробці через AI?
Поділюсь своїм спостереженнями, що відбувається з розробкою через використанням Copilot/ChatGPT/LLMs.

1. В кодовій базі або системі відстеження завдань почали зберігати не тільки діаграми, але й промпти.
2. Стала важливішою підтримка консистентності кодової бази. Раніше це покращувало лише читання коду, а тепер ще його генерацію за допомогою Copilot/Tabnine/etc/
3. Стало простіше пояснювати інженерам протокол Server-Sent Events та його застосування. Для цього досить показати, як працює ChatGPT.
4. Бізнес сам почав просити додати кодогенерацію OpenAPI 3. Процес розробки не повинен бути блокером для створення плагінів ChatGPT.
5. Для розробників iPhone перетворився з камери на корисний самостійним пристрій. Чашка кави та ChatGPT з голосовим вводом допомагають розбити фічу на завдання.
6. Прискорилася інфляція досвіду (тобто він швидше знецінюється).Доводиться навчатися більше, хоча куди ще більше?
7. Генерація коду фронтенд компонентів з дизайну в Figma приєдналася до хайпу AI. Додався ще один аргумент у дискусію "Вкладатись у свою дизайн систему або використовувати готову?"
8. Спитаю у ChatGPT звучать так само часто, як погуглю. Цікаво як швидко з'явитися для цього дієслово?
9. Значно зросла цінність навичок code review та вміння розібратися у чужому коді.
10. З'являються посади промпт-інженерів.

На завершення повторю те, що я вже говорив: AI не забирає у вас роботу. Це зробить інженер, який вміє його використати.

На минулому тижні було випущено дві мажорні оновлення пакетів, які використовуються всіма: Prettier 3.0 та typescript-eslint 6.0. На початку цього тижня ком'юніті оновило залежні пакети (наприклад, eslint-plugin-prettier). Тому можна оновлюватись!

Офіційні анонси
👉 Prettier 3.0
👉 typescript-eslint 6.0

У typescript-eslint відбулися зміни в назвах конфігурацій та їх вмісті. Як на мене стало зрозуміліше та зручніше.

Основні нововведення Prettier:
👉 підтримка .prettierrc.js та його еквівалентів. Тепер можна легко використовувати extends, що раніше було неможливо.
👉 тепер prettier за замовчуванням ігнорує файли, які ігноруються .gitignore.
👉 виправлення в парсерах для CSS/GraphQL, щоб відповідати синтаксису.

Нагадаю, що eslint та prettier мають автофікс, який гарантовано робить безпечні оновлення у вашому коді. Бажаю приємного оновлення вашого проекту!

У березні 2019 року я мав можливість виступити на конференції JavaScript fwdays'19. Під час цієї події, разом з Тимуром Шемседіновим, ми мали честь відповідати на запитання учасників.

Під час одного з питань, до нас звернувся інженер з запитанням про обробку скасування запиту в середовищі Node.js. Хоча я не можу точно пригадати, яку саме відповідь подав Тимур, можливо, він згадав про AbortController, який на той час ще не був широко відомий і ще обговорювався в рамках TC39. Однак, я пам'ятаю свою власну відповідь, яка була короткою і некоректною – "кулі з фронту вже вилетіли, тобто їх не скасувати".

Зараз вже минуло 4 роки з того часу. В даний момент я займаюся консультуванням одного мобільного проекту. За останні півроку ми значно знизили кількість помилок як на стороні клієнта, так і на стороні сервера. Проте, у зв'язку з цим зросла частка помилок, які залишаються невідомими або непередбачуваними, з 0.01% до 2%. Цього тижня мені довелося зіткнутися з дивним явищем. Виявилося, що фреймворк Nest.js не генерує помилку, коли сокет вже закритий. Це стосується також інших фреймворків, таких як Express.js, Fastify або навіть простий Node.js, бо саме Node.js не генерує винятків, коли клієнт відключається до отримання відповіді від сервера.

З одного боку не можна писати відповідь у закритий сокет без помилок, але... Бажаєте перевірити? Натисніть cancel у Postman:

const { scheduler } = require('node:timers/promises');
const express = require('express')
const app = express()
app.get('/', async function (req, res) {
await scheduler.wait(60_000)
 res.send('hello world')
})
app.listen(3000)

Щобі ви розуміли рівень мого когнетивного дисонансу, у мене відчуття, що все що я знав до цього про розробку немає сенсу. Тому що Go/Python/PHP/etc поводяться так само. Але їх я ще перевіряю, бо Node.js я вже перевірив тричі.

Друзі, зустрічайте запис воркшопу «Infrastructure for Firebase project» від Нікіти Галкіна, який пройшов в рамках онлайн-конференції DevOps fwdays’23, 21 березня 2023 року 🤩

🎥 Опис воркшопу: Під час воркшопу ми налаштуємо реальний веб-проєкт, використовуючи Firebase фічі: хостинг, автентифікація, firestore. Нікіта пояснить, навіщо та коли використовувати ці функції, та продемонструє специфічні для Firebase практики DevOps. Набір інструментів включає firebase cli, firebase емулятори, terraform і Google Cloud Console.

Мова воркшопу – англійська

Приємного перегляду та не забудьте підписатись на наш YouTube-канал, щоб бути в курсі подій 🤗

Відео за посиланням ➡️ https://youtu.be/b0uVKeKxeX8

У мене багато подій, які не залишають часу на рецепти для каналу. Однією з цих подій слід поділитися публічно. Я прийняв запрошення від @fwdays приєднатися до програмного комітету конференції Node.js fwdays'23, яка відбудеться онлайн у грудні.

Розповім декілька слів про програмний комітет у FWdays. Його основне завдання – формування збалансованої та якісною програми. Участь у ПК відбувається на волонтерських засадах. ПК складається з 4-5 експертів, які зустрічаються онлайн раз на тиждень, щоб обговорити подані доповіді. Запрошенням експертів у ПК займається Міла, з якою знайомий кожен, хто подавав доповідь на FWdays.

Уточнивши у Міли ці деталі, я заглянув на сайт FWdays. На жовтень запланована конференція React+TS. Я вписався до ПК і цієї конференції, адже там є TypeScript.

На завершення скажу, що ця новина означає для каналу. Я повертаю рубрику #worth_seeing з відео, які я рекомендую переглянути.