The Front End Developer/Engineer Handbook 2024 by Cody Lindley for Frontend Masters

Рекомендую ознайомитися з цим матеріалом, особливо якщо ви готуєтеся до співбесіди на позицію FullStack або Frontend. Контент написаний тезово з акцентом на підвищення ерудованості. Якщо ви хочете заглибитись, то наведені посилання.

Node.js is 15! 🎉🎉🎉

Як отримати GitHub сертифікації безкоштовно?

На початку цього року GitHub/Microsoft анонсували GitHub сертифікації. Існує 4 сертифікації, але Node.js розробникам будуть корисні:
• GitHub Foundations Certification для початківців розробників
• GitHub Actions Certification для техлідів, які відповідають за DevOps процеси або DevOps інженерів

Ціна 99$ за іспит, але я хочу поділитися з вами, як отримати ваучер безкоштовно. Отже, алгоритм:
1. Реєструємось на подію в рамках Learn Live Learn Live: Get Certified with GitHub | Microsoft Learn. Повний список Home | Microsoft Reactor.
2. Дивимось на YouTube у режимі лайф.
3. За півгодини до кінця стріму робимо реєстрацію на іспит і доходимо до оплати, щоб залишилось ввести промокод.
4. За 15 хвилин до кінця у відео буде ваучер. Приклад Introduction to GitHub and its Certifications. Вводимо його у форму швидше за інших учасників.
5. Якщо не встигли, то виконуємо те ж саме на іншому вебінарі. Можна взяти програму іспанською Learn Live: Get Certified with GitHub | Microsoft Learn.

Щойно закінчився перший вебінар. Код ваучера був YSP9QNJ5.

Цього літа буде Навчальний Табір по Rust, деталі:
- безкоштовно
- онлайн формат
- починається 24 червня 2024 року і триватиме 4 місяці.
- українська або англійська, за вибором
- перевірена програма
- досвідчені ментори
- навчання в малих групах

Відмінні риси IT-ринку в Україні - це його конкурентність та прозорість. Велику заслугу в цьому мають відкриті дані про зарплати, які допомагають усунути інформаційну асиметрію. Детальніше про цей феномен можна прочитати за запитом ринок лимонів.

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

Саме зараз відбувається чергове анкетування. Якщо ви ще не заповнили анкету, настійно рекомендую вам це зробити.

👉 Заповнювати тут

40 хвилин тому розпочався 2-й вебінар в рамках Get Certified with GitHub. Наприкінці покажуть ваучер для безкоштовного проходження GitHub сертифікації. Зазвичай вона коштує 99$.

У вас буде 10-20 секунд, щоб його активувати, тому ось перевірений метод:
1. Обираємо сертифікацію. Я рекомендую GitHub Actions для досвідчених розробників, GitHub Foundation для початківців.
2. Реєструємося тут https://examregistration.github.com/ Вас перенаправить на https://test-takers.psiexams.com/
3. Робимо бронювання на https://test-takers.psiexams.com/. На етапі Payment зупиняємося.
4. Чекаємо код ваучера у відео https://www.youtube.com/watch?v=bQEY7_au-Ko
5. Вводимо код швидше за конкурентів.
Lifehacks:
1. Таймслот можна обрати будь-який вільний через пару тижнів. Потім зробити reschedule на зручний вам час, коли будете готові.
2. Щоб виграти кілька секунд, можна використовувати розпізнавач тексту з екрану. У мене такий вбудований в CleanShot.

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