Мій друг хоче увійти до IT, що йому порадити?

Для успішної роботи в IT обов'язковою умовою є систематична самоосвіта. Тому не варто радити:
– йти на курси
– шукати ментора
– вступати в ком'юніті "Вчимо <технологія> разом"
– боротися за місце в інтернатурі
– підписуватись на ваш улюблений ютуб канал

Ці поради не працюють, якщо людина не має навички самоосвіти. А що тоді працює? Допомога у підборі матеріалів для самоосвіти. Ось де я зазвичай підбираю матеріали для початківців:
- https://www.freecodecamp.org/learn/
- https://exercism.org/tracks
- https://www.coursera.org/courses (пам'ятаємо про фінансову допомогу)

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

90+% людей не закінчать свого першого курсу. Це нормально, усі люди різні. IT і регулярне самоосвіта не підходять усім. Але тим, хто закінчить, можна радити курси, менторів або навіть рефералити в інтернатуру вашої компанії.

Як оновлювати залежність?
#npm

<offtop>Я переписував текст про оновлення вомбатових кубиків чотири рази, щоб це був рецепт для каналу, а не доповідь на конференцію.</offtop>

Особисто для мене найскладніша відповідальність тех.ліду – це стежити за актуальністю тех.стека. Занадто швидко прогресує екосистема JavaScript + DevOps + CloudNative. Однак у рамках тематики канали ми сьогодні говоритимемо лише про оновлення npm пакетів.

Почнемо з базових речей:
1️⃣ <offtop>Якщо у канал з'явиться інстаграм, то першою картинкою це буде блок-схема про вибір типу залежності для вашого пакета. </offtop> dependencies це то, що потрібно під час run-time або побудови проекту. Все інше, що необхідно під час тестування або локальної розробки це devDependencies (тести, літнги, тощо).
2️⃣ Автори пакетів з 0.X версією мають право ламати зворотну сумісність із кожним мінорним релізом. Конкретний приклад до жовтня 2022 року, коли вийшла 1.0 версія, автори axios мали повне моральне право ламати зворотну сумісність.
3️⃣ Треба використовуємо package-lock.json, щоб зберегти все дерево залежностей. Цей файл є частиною git-репозиторію, як composer.lock у php або .terraform.lock.hcl у DevOps.
4️⃣ Ви використовуєте актуальну версію вашого менеджера пакетів. Я волію слідувати мейнстріму, тому у нас npm@9 з третьою версією lockfileVersion. Якщо у вас не третя, то виправляється за допомогою npm i --lockfile-version 3 --package-lock-only. Якщо у вас не npm, то у вас чи вашого тех.ліда має бути чітка відповідь чому саме так.
5️⃣ необхідно видаляти залежності, що не використовуються.

Перейдемо як саме оновлювати залежності:
1️⃣ Правильно, тобто ви змінюєте залежності за допомогою команди npm install <packageName> або npm update <packageName>, а не за допомогою зміни package.json чи npm update. Поясню, змінювати файли через редактор, замість використання менеджера пакетів – це розсинхронізувати package.json та package-lock.json. npm update без імені пакета оновлює все, тобто це некеровано, отже неправильно.
2️⃣ Свідомо, тобто ви знаєте що саме змінилося у ваших залежностях. Для цього необхідно читати реліз ноутс. Мені в цьому допомагає njt. Приклад, njt axios r
3️⃣ Регулярно, тобто перевіряти наявність нових версій за допомогою npm outdated. На моїх проектах оновлення залежностей це один із аджайл ритуалів після релізу.

На завершення, нагадаю, що ваш додаток це не лише код, написаний вашою командою, а й конкретні версії бібліотек, які використовуються вашим кодом. Тому ставтеся до їхнього вибору (і оновленню) з відповідальністю!

Запрошуємо Вас 7-го червня на вебінар “Найкращі практики DevOps у Google Cloud”. Запрошений експерт – Нікіта Галкін, Cloud Architect. Мета доповіді розповісти на прикладі Google Cloud про інженерні підходи, що дозволяють нести відповідальність за інфраструктуру. Вебінар є частиною програми “Розвивайте кар’єру з Google Cloud: DevOps & Architect”, тому для участі потрібна реєстрація. До зустрічі в ефірі!

Що там із YouTube-каналом?
У моєму want-to-do списку є багато справ, наприклад, вести ще один блог про гаджети та лайфхаки, більше ділитися досвідом роботи з AWS або вести YouTube канал. Про те як справи з YouTube каналом я вам сьогодні і розповім.

У травні мій трекер по напрямку YouTube перевалив за 150 годин. Таку кількість часу у 2023 році я провів, намагаючись навчитися створювати відео, яке би мені не було соромно демонструвати. Я щиро захоплююся Турським, Бабичем, Климовим, Немчинським, Малєєвим та багатьма іншими українськими IT YouTube-амі, але у мене поки що не виходить так, як у них.

За останні два дні я спробував зробити огляд Node.js новин, але результатом знову незадоволений. До 150 годин потрібно додати ще 10 годин на це 10-ти хвилинне відео, яке я так і не доробив. Можливо YouTube це не моє. Для порівняння на підготовку та здачу сертифікації Professional Cloud Security Engineer у травні я витратив 25.

Ось те, що мало бути у відео:
➡️ Нода знову перемагає, але чому синтетичні тести не є показником? https://pkolaczk.github.io/memory-consumption-of-async/
➡️ З'явився домен верхнього рівня .zip. Які ризики це несе? https://domains.google/tld/zip/
➡️ Обговоримо основи: Хто відповідає за налаштування CORS – Frontend, Backend або DevOps у 2023 році? https://docs.nestjs.com/security/cors
➡️ Чому MVP ≠ PoC або ще один AI хайп? https://twitter.com/advany/status/1664451798793584642
➡️ Що таке IDP (Internal Developer Platform) і чому ваш СТО повинен його впровадити? https://www.youtube.com/watch?v=Rg98GoEHBd4

Продовжую вчитися, щоб вкладатись у норматив не більше години на створення хвилини відео.

Цей пост інформаційної підтримки @nearprotocolua. Вони проводять офлайн евент у Києві. Рекомендую для розширення кругозору та нетворкінгу.

Джерело

How Rust Developers Are Building Blockchain Apps — мітап, що сфокусован на технічних аспектах що таке блокчейн, навіщо там Rust, що з ним можна робити, підійде як для людей які розглядають Rust як додаткову мову так і для людей які хочуть розібратися що таке блокчейн з техничної точки зору 👍

📍 Де: Михайла Грушевського 3, Київ, Україна
📅 Коли: 15 червня 2023 
⏰ 19:00 - 22:00
🤑 Вартість: Вхід безкоштовний, але за попередньою реєстрацією
🧐 Дізнайтесь більше від Near Ukraine Guild, Human Guild та Brushfam про: 
1️⃣ Що таке блокчейн , для чого його можна використовувати
2️⃣ Особливості Polkadot та Near, для чого вони потрібні
3️⃣ Які є юз кейси блокчену та подивимося демо
4️⃣ Навіщо треба геймінг на блокчейні, і як Human Guild допомогає розробляти блокчейн ігри
5️⃣ І найголовніше — офлайн спілкування під безкоштовне пиво 🍻 ✨

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

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

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

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

Вечір п'ятниці, тому давайте спробуємо формат технічних байок.

Ви чули, анекдот:
– Я з приводу вакансії спеціаліста з інформаційної безпеки.
– Надішліть ваше резюме.
– Воно вже на головній сторінці вашого сайту.
У мене був такий досвід.

Все починалося стандартно. Рекрутер звернулася до мене на LinkedIn із вакансією Node.js Lead. Співбесіда з HR пройшла добре: проект мене зацікавив, а мій досвід був релевантним для вакансії. Тому ми попрощалися з тим, що наступним кроком рекрутер надішле запрошення на технічну співбесіду.

Звичайно, рекрутер не розповіла про технічний стек. Тому я вирішив подивитись його сам. Протягом 2 хвилин я дізнався, що це MERN стек. Про це свідчили:
- заголовок X-Powered-By: express
- ObjectId MongoDB в URL
- source maps (вони були увімкненими в продакшні)

Швидкий перегляд source maps показав, що одне SPA відповідає як за клієнтську, так і за адміністративну частину. Експеримент з API, який змінює профайл, показав, що на бекенді відсутня валідація. Я зробив себе адміном. Тепер я міг викласти моє резюме на головну сторінку сайту, але я вирішив записати 2-хвилинне відео з аналізом уразливостей. Я попросив рекрутера передати це відео інтерв’юеру. На все це я витратив близько години.

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

Які сервіси треба вміти інтегрувати?
#list

У стартапах одним з ключових факторів прийняття рішень є швидкість виходу на ринок (time-to-market). Тому широко використовуються інтеграції зі сторонніми API замість створення власних сервісів. У цьому випадку, Node.js виконує роль оркестратора, тобто викликає SDK/API та/або створює webhook. З мого особистого досвіду створення PoC за допомогою інтеграції займає 1 день, а розробка production-ready функціоналу зазвичай займає 1-2 тижні. Створення ж in-house рішення відбувається у кілька разів довше і має слабший функціонал.

Ось список завдань і приклади сервісів:
1) Відправка push-сповіщень: Amazon SNS, Firebase Cloud Messaging
2) Аутентифікація та управління користувачами: Auth0, Okta, Firebase Authentication, Amazon Cognito.
3) Підтримка користувачів: Intercom.
4) Прийом платежів: Stripe, Braintree.
5) Відправка електронних листів: Amazon SES, SendGrid, Mailgun.
6) Створення чатів: getstream.
7) Управління підписками: App Store Server API, Google Play API, Stripe.
8) Відправка SMS: Twilio.
9) Створення чат-ботів: Telegram, WhatsApp, Discord.
10) Аналітика: Google Analytics, Mixpanel.

NestJS 10

Минулого тижня вийшла нова мажорна версія NestJS 10.

Breaking changes:
👉 Припинення підтримки Node.js v12 та v14.
👉 перехід до TypeScript 4.8+ з новим Abstract Syntax Tree (AST). Це необхідно для CLI-плагінів.
👉 Переміщення модуля кешу до окремого пакету @nestjs/cache-manager.

New features:
🚀 Підтримка SWC (Speedy Web Compiler) для прискорення процесу розробки.
🚀 Можливість перевизначення модулів у тестах для спрощення створення моків.
🚀 Підтримка підписок з використанням шаблонів у Redis.

Моя особиста думка:
💡 Для BE розробки основна затримка - це створення нових підключень до зовнішніх ресурсів (наприклад до БД). Тому SWC виглядає для мене переоціненим. Та й із перевіркою типів він працює не так вже й швидко.
💡Спрощення роботи з тестами - це головна перевага переходу на нову версію.
💡 Оновлення версій Node.js/TypeScript це круто, ще б додали графік підтримки версій.

Links:
🔗 Інструкції щодо міграції з Nest v9.
🔗 Офіційний пост

🔥хто: Віктор Турський
🚀що: розповідає про те, як змінився процес розробки за 15 років
⏰​Коли: 29.06, 6 pm CET
​​📺Де: YouTube, реєстрація https://bit.ly/3P97fpE
📍Організатор: Sigma Software

На цьому можна зупинитися, бо Вітя дійсно вміє розповідати цікаво й по суті. Але я хочу ще пропіарити його проект my-talks.net. Тому якщо ви не бачили жодної доповіді Турського швидко відкрили https://my-talks.net/viktor-turskyi. Там є із чого вибрати. Для читачів каналу особливо зайдуть "6 ways to hack your JavaScript application" та "Docker deep dive for JavaScript developers". Впевнений, що і "Life Behind Clouds" буде також на високому рівні.

#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. Що мені варто вас запитати, щоб відобразити важливе для вас у моєму звіті? всі попередні питання по суті є прелюдією, щоб техлід почав довіряти та виявив себе. На цей момент вже очевидно, чи є технічний лід на проекті, і якщо він є, то він говорить про проблеми, які необхідно продати бізнесу.