На додачу до допису про TDD хочу поділитися досвідом, який я колись отримав на одному проєкті. Це був досвід ще до AI, та й загалом у темні часи, які були увіковічені в треш-історіях ebanoe.it.

На одному з проєктів ми пробували запровадити BDD разом із популярною на той час бібліотекою Cucumber.js.

Ідея була дуже цікава, і загалом цей підхід багато чого спрощує та робить зв’язок із бізнесом тіснішим. Але ми вперлися в проблеми, і ця ідея заглохла. Переважно через те, що робота була через гал tру і нас розглядали суто як дешеву раб силу (суровий укр ринок). Та і в той час було важко отримати апрув навіть на звичайні тести, а тут - якесь незрозуміле BDD і Огірок.js.

З огляду на розвиток AI цей підхід може отримати друге дихання, адже писати тести стало набагато простіше й швидше, інженери набагато більше залучені в бізнес і BDD можна розглядати, як один з способів синхронізувати продукт і розробку навколо очікуваної поведінки системи, щоб тримати всіх "on the same page".

Хто не в курсі за BDD, дуже раджу ознайомитись🚬

Чому знання React, Angular і Vue не робить вас кращим розробником?

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

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

В backend усе працює так само, але ситуація тут ще гірша через наявність великої кількості однакових інструментів.

Суть допису така - зосереджуйтесь на реально важливих речах, від яких можна отримати вихлоп в вигляді 💸


П.С. Побачив в LinkedIn пост про порівняння React i Angular, на секундочку в 2026 році 😁

Цікава новина для всіх хто цікавиться інвестиціями, будемо купувати на хаях?😄

До IPO звісно ще далеко, але перші кроки вже почались

📎 - https://www.anthropic.com/news/confidential-draft-s1-sec

Знову поламали AWS🚬

Цікаво чи є кореляція з недавніми лейофами😁😁😁

Сьогодні натрапив на твіт одного забутого Node.js фреймворка - Moleculer.

Загалом він дуже добре лягає на концепцію nanoservices. Але, на відміну від того ж Express.js, тут не потрібно писати власні велосипеди для transport, fault tolerance, discovery, tracing тощо.

З дуже приємного - наявність із коробки Circuit Breaker, Retry, Bulkhead та інших fault tolerance механізмів.

Ідея дуже хороша, але за відчуттями, Nest.js викинув його за борт і повністю захопив цю нішу. Тому працювати з ним, мабуть не варто, але почитати його концепції буде доволі цікаво.

📎 - https://moleculer.services/

SOLID здорової людини

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

Тому ловіть життєву версію SOLID:

S - Single Responsibility

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

Принцип каже, що має бути тільки одна причина для зміни цього сервісу і це зміни в Auth Flow.

O - Open/Closed

Якщо тобі треба внести якісь зміни в сервіс чи компонент на 2000 рядків коду, і ввечері ти хочеш відпочивати, а не відкочувати свої зміни з проду, краще не чіпай те гівно, а додай свої зміни поверх цього атракціону.

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

L - Liskov Substitution

Якщо ти по пʼяні вирішив перевизначити стандартний метод у репозиторії якоїсь ORM, наприклад UserRepository.find(), то семантично цей метод усе ще має щось шукати. Не треба в ньому щось видаляти чи створювати нові записи.

Принцип каже, що дочірній клас має безпечно замінювати батьківський.

I - Interface Segregation

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

Принцип каже, що краще мати кілька малих інтерфейсів, ніж один великий: так їх простіше перевикористовувати.

D - Dependency Inversion

В ідеалі твоя архітектура має залежати від абстракцій, а не від реалізацій. У реальному житті базовий мінімум - це взяти нормальний Node.js фреймворк, де з коробки є Dependency Injection, наприклад NestJS.

Без цього доведеться ініціалізувати залежності всередині бізнес-логіки. А це розірве вам жопу, коли проєкт розростеться і треба буде вносити зміни або покривати код тестами.

Принцип каже, що високорівневі модулі не мають залежати від конкретних реалізацій. Тобто вашому API контролеру має бути все одно, який саме сервіс підставлять усередину. Головне, щоб він відповідав потрібній абстракції: інтерфейсу, класу або токену провайдера.

Ще зовсім недавно тут був допис про 300 людей у каналі, а сьогодні нас уже 500 🎉🎉🎉

Це дуже мотивує писати далі й ділитися ще більше інженерним контентом.

Дякую всім за те, що читаєте ❤️

Найпотужніший курс за всі часи 😱

Якщо ви новачок і шукаєте курси програмування, то з імовірністю 100% натрапите на всяке ІТ сміття, де вчорашні джуни будуть вам розказувати про JS і React. Про джунів які викладають - не жарт.

Цей курс реально покращить ваше розуміння програмування і розробки загалом. Це звісно не умовне GoIT, а всього лише безіменна бурса - Harvard 😁. Але курс дуже крутий і, як на мене, обовʼязковий для початківців.

І так - це актуально в епоху АІ. Я б сказав, навіть актуальніше, ніж до неї.

Курс повністю безкоштовний, і якщо на англійській дивитись важко, то в інтернеті є укр/рос версії.

📎 - https://pll.harvard.edu/course/cs50-introduction-computer-science

Згадав одну цікаву задачу, яку колись зустрічав на live coding інтервʼю в одній EU компанії. Думаю багатьом буде цікаво її розвʼязати, щоб попрактикуватись.

Потрібно написати простий клон сервісу по типу onetimesecret.com.

User flow:

1. Користувач A відправляє на сервер повідомлення, наприклад: Hello, world!
2. Бекенд шифрує це повідомлення, зберігає його і повертає унікальний URL, за яким secret можна відкрити лише один раз. Наприклад: https://api.com/cmq0zrsky00003b6sxwxj8igk

3. Користувач B відкриває цей URL.
4. Бекенд знаходить secret, розшифровує його, повертає текст Hello, world! і одразу видаляє запис.

Фактично потрібно реалізувати два ендпоінти:

- створити secret;
- прочитати secret один раз.

З інструментів можна використовувати будь-що, але для такої задачі достатньо Node.js + Express.js.

Що потрібно знати для першої роботи?

Декілька разів бачив питання від людей, які хочуть потрапити в ІТ-болото. Я буду розглядати позицію full-stack розробника, оскільки наразі вона найбільш актуальна.

Frontend не розглядаю, бо пройти туди набагато важче, тай не треба воно вам (ІМНО) 😑

Нижче наведу список знань, які вам потрібно буде освоїти, щоб пройти інтерв’ю на Junior позицію в галєру мрії. Відразу зазначу, що ІТ-курси вам не допоможуть і дадуть максимум 10–15% від усього, що потрібно для роботи. Чому так - опишу в окремому дописі.

HTML/CSS
Треба знати на рівні простої верстки. Зараз на інтерв’ю про них майже не питають.

JS
Будуть питати про основні теми: closures, promises тощо. З того, що бачу зараз, це буквально 3–5 питань з JS Core, навіть на Junior-рівні.

TS
Потрібне розуміння деяких “advanced” тем, наприклад, type narrowing і generics. Це дозволить вам добре виступити на інтерв’ю.

React
Будуть довбати, якщо інтерв’юер - це галерний frontend-гой, який уже 5 років не міняв проєкт. Тому, окрім загального розуміння, варто розібрати основні теми, які часто звучать на інтерв’ю: hooks, controlled/uncontrolled components тощо.

Node.js
Навіть на Junior-позицію від вас будуть очікувати розуміння асинхронної моделі, Event Loop, а інколи - process/thread, cluster, streams.

Databases
Якщо пощастить з інтерв’юером, то з базами даних буде пов’язано приблизно 40% інтерв’ю. Тому важливо розібрати основні теми: індекси, зв’язки, ACID тощо. Також варто підтягнути SQL до рівня розуміння JOIN і агрегацій.

Security
Навіть якщо позиція Junior, вас точно запитають про JWT, XSS і можливо, ще кілька топіків. Тому потрібно копнути й у цей бік.

Те, що я описав вище, потрібно для проходження інтерв’ю. Для навчання найбільш оптимальним варіантом були й залишаються pet projects паралельно з YouTube/Udemy.

Для них беріть щось потрібне в роботі, наприклад Nest.js/TypeORM/PostgreSQL для backend і React або Next.js для frontend. Наступайте на граблі, паралельно розбираючись в них.

Підігнали мені тут цікаву візуалізацію Event Loop

Буде корисно, якщо є пробіли в ньому і не розумієте порядок виконання синхронного і асинхронного коду. І на інтервʼю теж знадобиться, щоб пояснити черговість console.log

📎 - https://devops-daily.com/games/javascript-promises-async-await-simulator

В багатьох досі існує думка, що для realtime не бажано використовувати православні бази даних(SQL), а треба обовʼязково брати NoSQL.

Хочу порекомендувати extension для PostgreSQL, який дозволяє ефективно працювати з time-series даними, наприклад telemetry, IoT, GPS… - TimescaleDB.

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

Заодно гляньте, що таке Hypertable. Це відповість на питання, чому таке можливо в PostgreSQL.

🔗 https://www.tigerdata.com/timescaledb

Вже хтось пробував новий Claude Fable?

Походу токенів він жере побільше, ніж всі Opus разом взяті, але має бути хороший інструмент, бо Fable погане не назвуть (хто грав цю легенду, той зрозуміє)😁

DRY чи WET?

Як ми всі знаємо, реальність сучасної розробки дуже відрізняється від книжок. І часто мамкині любителі патернів та best practices на практиці створюють більше проблем, ніж вирішують.

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

DRY (Don’t Repeat Yourself) каже, що потрібно уникати дублювання коду, бо інакше зміни доведеться робити в багатьох місцях. Звучить благородно. Але на практиці це часто призводить до того, що сервіс, який можна було просто продублювати з невеликими змінами, перетворюється на switch/case атракціон, в якому ніхто не може розібратися.

Якщо проєкт на ранній стадії, іноді краще керуватися WET (Write Everything Twice). Це протилежність DRY і загалом вважається антипатерном, але добре підходить для ситуацій, коли ми не можемо собі дозволити best practices.

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

Чому курси не працюють❓

Часто бачу в інтернеті обговорення ІТ-курсів і хочу коротко та без хейту розповісти, чому вони працюють далеко не так, як очікує більшість.

Я буду розглядати full-stack курси, бо frontend майже не ведуть до роботи в ІТ, а backend курсів з Node.js немає.

У сучасних реаліях типовий ІТ курс - це орієнтовно 10 - 15% від усього, що вам потрібно для першої роботи, тому великих надій на нього покладати не варто.

Отже, ось чому курси не сильно допоможуть “зайти” в ІТ:

1️⃣ Поверхневість

Більшість курсу - це core технології: HTML, CSS, JS, трохи TS і зовсім трохи Node.js. Звичайно, усе, що складніше за JS, буде розглянуто максимально поверхнево, щоб не ускладнювати процес і не відлякати вас від ІТ у період, коли ще можна повернути кошти.

У дорожчих курсах є SQL, але це теж максимально поверхневий огляд на рівні SELECT/JOIN.

2️⃣ Застарілі технології

За відчуттями, курси не оновлюють десь із 2018 року, коли був популярний SASS/LESS і люди молилися на MERN стек (MongoDB, Express.js, React.js, Node.js).

3️⃣ Акцент на простоті

Якщо ви подивитеся програму курсів, то здебільшого це 70% frontend і трохи backend. І, звичайно, усе крутиться навколо React. Це знову ж таки зроблено для того, щоб не відлякати людину.

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

От спробуйте продати людині ідею, що їй доведеться задрочити реляційні бази, замість того щоб писати тудуліст на React.

4️⃣ Джуни-ментори

У більшості курсів менторять у кращому випадку працюючі junior/middle розробники, а в гіршому - випускники цих же курсів. Звичайно, ніхто вам не допоможе зрозуміти складніші теми, ніж замикання в JS.

❗️Якщо ви початківець❗️

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

Цікава новина від Skynet Anthropic

Як на мене - це чіткий сигнал того, що стратегія по АІ міняється. Вже ніхто не говорить про заміну інженерів, натомість ставку будуть робити на AI Adoption (старий добрий vendor lock-in 😁)

В принципі, все як я казав раніше. Якщо ви backend розробник, то важливо розуміти як працювати з АІ, вміти інтегровувати його в продукти і розуміти його болячки.

📎 - https://www.anthropic.com/news/claude-corps

Всі пишуть і говорять про ACID, але дуже мало людей знають про BASE. Треба розуміти, що ACID - це локальні концепції, які працюють в рамках однієї бази даних, а BASE описує узгодженість даних між сервісами в розподіленій системі.

BA - Basically Available

Система намагається залишатися доступною навіть тоді, коли частина сервісів або інфраструктури має проблеми. Є багато способів забезпечити BA, наприклад Retry with Backoff, Circuit Breaker, Fallback, DLQ і так далі.

S - Soft State

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

Так як здебільшого комунікація між сервісами є асинхронною, наприклад через Message Brokers, запит користувача може мати багато етапів. І кожен з цих етапів буде мати свій проміжний State.

Якщо хочете дослідити це глибше, то розберіть Saga Pattern. Як на мене - це найбільш наглядний приклад S.

E - Eventual Consistency

Узгодження даних відбувається, але не обовʼязково миттєво. Наприклад, користувач оплатив замовлення. Payment Service вже знає, що оплата успішна, але Order Service ще не оновив статус замовлення, бо чекає подію з черги.

Кляті пєндоси забрали доступ до Fable 5 i Mythos 5 😱😱😱

Anthropic каже, що можлива причина - це jailbreak (спроба змусити модель обійти її правила безпеки). Але як на мене уряд США просто поступово бере під контроль ще одну стратегічну технологію

📎 - https://www.anthropic.com/news/fable-mythos-access

Концепції TypeScript: Mixins vs Decorators

Думаю було б корисно почати створювати дописи і про TypeScript/JavaScript. Це звичайно не кодинг, а більш концептуальні теми, розуміння яких стало важливішим з приходом АІ.

Decorators
Фактично - це функція, яку можна прикріпити до класу, методу, параметра або поля за допомогою синтаксису @. Його задача додати або змінити поведінку конкретної сутності.

Наприклад, розберемо типовий метод контролера в Nest.js:

@Post()
@UseGuards(AuthGuard)
async createTrip() {}

Post() - додає поведінку, яка вказує, що метод має обробляти HTTP POST запити.

UseGuards(AuthGuard) - додає поведінку, яка перевірить чи користувач авторизований, перед викликом цього метода.

Mixins
Вони теж дозволяють додавати поведінку, але працюють інакше, ніж decorators. Їхня основна задача - розширити клас через композицію (бо множинного наслідування немає).

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

Наприклад, в нас є бізнес логіка кешування (методи і поля), які спільні для всіх хто буде їх використовувати. Тоді логічно використати mixin, щоб розширити функціонал і паралельно не мати жорсткої завʼязки, як у випадку з наслідуванням.

class CachedTripsService extends WithCache(TripsService) {}

// В нас немає завʼязки з класом і при необхідності можна розширити його ще більше
Sentry(With)class CachedTripsService extends WithCache(TripsService) {}

Коли і що використовувати?

Тут все дуже просто, якщо потрібно розширити/змінити поведінку пробуєте використати decorators, в більшості випадків їх буде достатньо.

Якщо бачите, що вам потрібно створювати нові методи/поля, які будуть використовуватись в рамках класу, тоді створюєте mixin.

Авторизація vs автентифікація

Дуже коротко про ці важливі поняття, бо багато хто не знає, що воно таке. Самі назви запамʼятовувати не обовʼязково, але важливо розуміти, які етапи контролю доступу до системи в нас є.

Автентифікація

Простими словами, система запитує: Хто ти?

Наприклад, ти вводиш свій email і пароль. Якщо вони правильні, система ідентифікує тебе як конкретного користувача і видає JWT токен.

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

Авторизація

Простими словами, система визначає: Що тобі дозволено робити?

Після того, як система зрозуміла хто ти, тобто перевірила чи JWT токен валідний, вона має визначити чи тобі дозволена операція.

Є багато способів це зробити, але ось декілька в якості прикладу:

RBAC (role-based access control) - доступ визначається через ролі, наприклад: admin, moderator, user.

PBAC (permission-based access control) - доступ визначається через конкретні permissions, тобто дозволи на окремі дії. Наприклад: user:create, user:delete, post:update, billing:read.

Кому цікаво, LangChain викотили ще один безкоштовний курс по LangSmith. Це звичайно не курси з інстаграма від гуру вайбкодингу, але теж дуже навіть непогано.

Вже якось згадував LangChain Academy і те що в них доволі багато курсів по Core технологіям (LangChain/LangGraph/LangSmith).

Звісно більшість на Python, але для тих хто поки не душить змія є версії і на JavaScript.

📎 - https://academy.langchain.com/courses/langsmith-deployment