оця варта уваги

Згадав про одну цікаву книжку, яка скрасить вашу поїздку в поїзді чи літаку📕

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

Також, непогано підійде для підготовки до system design interview і в цілому підніме рівень проходження інервʼю.

З найцікавішого, можна виділити:
- Fitness Functions
- Evolutionary Architecture Pitfalls and Antipatterns
- Architectural Coupling

З мінусів, це поверхневість книги, що в принципі не дивно, бо вона доволі тонка

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

Отже, ACID - це набір властивостей, які описують транзакцію.

1️⃣ Atomicity
Транзакція або виконується повністю (COMMIT), або не виконується взагалі (ROLLBACK).

2️⃣ Consistency
Після транзакції база має залишатися у валідному стані. Важливо розуміти, що валідний стан описується на рівні DB за допомогою інструментів, які перевіряють дані під час транзакцій: constraints, foreign keys, unique indexes, checks...

У реальному житті це завжди компроміс. Критичні правила краще залишати на рівні бази, а менш важливі валідації можна тримати на рівні application layer.

3️⃣ Isolation
Основна ідея, що транзакції не повинні заважати одна одній. Це теж компроміс, так як чим вищий рівень ізоляції тим менше аномалій при паралельних транзакціях, але менша паралельність.

Те що треба розуміти:
- Read Uncommitted
- Read Committed
- Repeatable Read
- Serializable

4️⃣ Durability
Якщо транзакція закомічена, база даних має гарантувати, що ці зміни були записані на диск.

Також, це часто запитують на інтервʼю тому про ACID я писав на сайті

Перемога? 👹

Microsoft скасовує ліцензії для Claude Code

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

Але всі ми знаємо, що vendor lock-in - це доволі жорстка штука. І якщо умовний Claude вже підсадив на свою голку, то оптимізувати витрати - задачка із зірочкою.

Згадав про хороший інструмент для симуляції проблем з мережею. По факту - це проксі, де ви можете додавати різні аномалії по типу timeouts, latency, обмеження body, обрив мережі і тд.

Toxyproxy - https://chaostoolkit.org/drivers/toxiproxy/

І назва в нього прикольна😁

Одна з реально корисних речей, яку приніс із собою AI, - це можливість писати бекенд у TDD стилі.

Наприклад, з бізнесової точки зору задача зрозуміла, і ви знаєте, як її імплементувати. Якщо це умовний API endpoint, то ви розумієте, які дані будете віддавати на фронтенд.

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

Я вже давно використовую цей підхід, і він реально працює. Особливо корисно для складних flow, де, щоб протестувати все через умовний Swagger чи Postman, потрібно створити купу seeds.

Як на мене, для такого підходу, ідеальне поєднання - це e2e-тест + Testcontainers.

Оскільки я використовую свій акаунт у Cursor, то змушений трохи економити: якщо задача не суперскладна, використовую Opus 4.7 для планування, а Codex/Sonnet - для імплементації.

Цікаво чи завезли реальних покращень🤞🚬

На додачу до допису про 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.

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