StringConcat - разработка без боли и сожалений

Может показаться, что выход — просто брать опенсорс вместо всех этих вендоров. Но и здесь хватает юридических и организационных рисков. Одно дело — суперпопулярный PostgreSQL, другое — какой-нибудь нишевый фреймворк, который завтра может тихо умереть, а специалистов по ним больше не существует. Да и сами опенсорс-проекты умеют переобуваться.

Относительно свежий пример — MinIO. На главной странице теперь честно пишут:

This project is currently under maintenance and is not accepting new changes. 
For enterprise support and actively maintained versions, please see MinIO AIStor.

А ещё раньше они фактически убрали консоль администрирования (если я правильно понял), объяснив:

Honestly, it is hard to duplicate this work for the community branch…

Без обид — жестокие улицы Сан-Франциско каждый день требуют дозы Enterprise-лицензии. Но с опенсорсом хотя бы остаётся код: можно форкнуть, допилить, поддерживать сами или в сообществе.

С коммерческим продуктом всё жестче: если компания закрылась — код ушёл вместе с ней в закат над Golden Gate.

Обезопасить себя от всех рисков — задача нетривиальная и не всегда лежит в технической плоскости. Но если есть возможность — подстелите себе солому из исходников

Как я предлагал вернуть Монолит и сэкономить миллионы.

Лично мне вариант с Redis понравился больше всего. Быстро, дерзко, молодежно. Но была одна проблема: Redis работает идеально ровно до тех пор, пока данные влезают в оперативку. Как только память заканчивается — карета превращается в тыкву. А постоянное переливание данных в Postgres через стримы выглядело как надежный, но все-таки костыль.

И тут меня осенило. Я пришел к нашему Principal Engineer с Гениальным Планом™.

— Слушай, — говорю я с максимально серьезным лицом. — Я тут порылся в закромах Google Cloud. У них есть машина с 5 ТБ оперативной памяти. — И? — Стоит всего $10k в месяц. Я прикинул: туда влезут все наши данные года за три. Вообще всё. И никаких костылей с переливкой.

Диалог вышел коротким: PE:

— А через 3 года, я полагаю, ты уволишься? Я: — Зачем же? Через 3 года у Гугла появится инстанс на 7 ТБ. Просто переедем на него за ночь.

------
Самое смешное в этой машине — это процессор. Там 200+ ядер. А наш любимый Redis, как мы помним, однопоточный. Ему нужно 1.5 ядра:

1 ядро — крутить транзакции.

0.5 ядра — на IO и «на чай» операционной системе.

Остальные 198.5 ядер будут простаивать. Хотя, почему простаивать? Можно запустить майнинг Биткоина. Глядишь, и стоимость аренды отобьем, и в финтех-отчетах покажем «альтернативные источники дохода».
------

В теории, на одну такую машину влезет весь наш немаленький банк. Целиком. Если перестать играть в микросервисы, Kubernetes и распределенные системы, а просто собрать честный, старый добрый Монолит.

Ну ладно, для отказоустойчивости возьмем две такие машины. Master и Slave. Всё равно экономия на инфраструктуре выйдет раз в 10. Никаких сетевых задержек, никаких проблем с согласованностью, деплой простым копированием бинарника.

Звучит как полный бред сумасшедшего. Или всё-таки нет?

#Юмор

Финал: Битва баз данных. Кто стал сердцем банка?
[В прошлых сериях]: нас отшил дерзкий стартап, мы обиделись и пошли пилить своё решение. Задача была простая, как кирпич: найти хранилище, которое выдержит наши амбиции. 🎯 Цель: — 100 TPS (транзакций в секунду) на один аккаунт (с блокировками). — 1000 TPS на рандомные аккаунты.

Мы прогнали всех кандидатов через мясорубку нагрузочного тестирования. И вот результаты, от которых мы то плакали, то смеялись.


1. Postgres (Старый конь борозды не портит)
Взяли его чисто как baseline, чтобы было с чем сравнивать. Вся логика строго на хранимках (Stored Procedures), один поход из приложения в базу.

Результат:
Один аккаунт: 1 300 TPS (В 13 раз больше требуемого! Мы слегка присели).
Много аккаунтов: 9 000 TPS.

Внезапно «скучный» SQL показал, что списывать его со счетов рановато.


2. Redis + Postgres (Форсаж)
Схема: Редис считает математику в памяти, а потом стримами (Streams) скидывает данные в Постгрес на вечное хранение.

Результат:
Один аккаунт: 23 000 TPS.
Много аккаунтов: 23 000 TPS.

Ему вообще плевать. Редис однопоточный, ему все равно хоть один аккаунт, хоть много. Скорость света.


3. TigerBeetle (Тот самый стартап)

Результат:
Один аккаунт: 27 000 TPS.
Много аккаунтов: 77 000 TPS.

Обещанного миллиона мы не увидели, но цифры всё равно мощные. Правда, прямо посреди теста мы словили эксепшн:

Whoops, there is a bug in SDK…

Мелочь, а неприятно. Представили, как ловим этот «Whoops» в продакшене в «Черную пятницу», и перекрестились.


4. Google Spanner (Боль и унижение)
Напомню, Гугл продавал нам это как «Решение Всех Проблем Человечества».

Результат:
Один аккаунт: 78 TPS. (Нет, я не забыл букву «K». Просто 78).
Много аккаунтов: 870 TPS. (Тоже просто 870).

Мы протерли глаза. Перезагрузили серверы. Цифры не изменились. Звоним в Гугл: «Ребята, что за фигня? Где обещанная магия?»

Нам вежливо посочувствовали и выдали гениальные советы:
- «А вы поставьте перед Спаннером Redis». (Спасибо, Кэп! А Спаннер тогда зачем?).
- Скинули статью на Medium: «Какие костыли прикрутить, чтобы базы данных хоть как-то работало с hot accounts».
- Рассказали вдохновляющую историю, как один банк реализовал на Спаннере... фичу кэшбека. (Кэшбека, Карл! Не леджера).

Когда мы наконец прорвались через продажников к суровым технарям, те вздохнули и признались: «Ну да, сотню TPS выжмете, больше — вряд ли. Архитектура такая».

Занавес.

------

Итоговое решение
Мы выбрали Postgres.

Почему:
- Запас прочности: Он выдал 1300 TPS на один аккаунт при требовании в 100. Этого нам хватит на годы.
- Надежность: Это скучная, предсказуемая технология. Никаких «Whoops» в SDK.
- Архитектура: Мы спроектировали систему так, чтобы оставить перед Постгресом «Redis-shaped hole» (дырку в форме Редиса).
- Если (или когда) мы вырастем до космических масштабов, мы просто вставим туда Redis, как деталь пазла. А пока — зачем платить сложностью за то, что старый добрый SQL делает бесплатно?

А теперь предлагаю погуглить "Spanners British slang". В общем, хорошую штуку Спаннером не назовут

DIY для банка: выбираем базу данных, когда стартап нас отшил

В предыдущей серии я рассказывал, как TigerBeetle — стартап нашей мечты — отправил нас во френдзону. Пришлось засучить рукава и делать «сердце» банка самим.

Но на чем писать? Чтобы не было мучительно больно за бесцельно прожитые спринты, мы сформулировали требования.

Задача:

- 1000 TPS (транзакций в секунду) на рандомных аккаунтах.
- 100 TPS на одного «жирного» клиента.

С первым пунктом всё понятно: если руки растут из плеч, любая современная БД это вывезет. А вот второй пункт — это боль. Нужно заблокировать аккаунт, посчитать баланс, записать проводку и разблокировать. Арифметика беспощадна: 1 секунда / 100 транзакций = 10 мс на всё про всё. Тут уже на Python не попишешь, тут думать надо.

В кастинг на роль «сердца» попали четыре кандидата:

1. Postgres (Классика)
Старый добрый слон. Чтобы уложиться в 10 мс, всю логику придется зашивать в хранимки (Stored Procedures). Гонять данные туда-сюда между приложением и БД — непозволительная роскошь. Сомнения: Наша текущая система на MySQL выдает жалкие 7 TPS. Вендор клянется мамой, что это предел физики. Мы, конечно, умнее, но сможем ли мы быть умнее на порядок? Вопрос открытый.

2. Redis + Postgres (Безумный Макс)
Идея для смелых: ставим Redis перед Постгресом. — «Но это же просто кэш!» — кричат пуристы. — «Подержите мое пиво», — отвечаем мы.

Почему это круто:

- Single-threaded: Редис однопоточный. Никаких гонок (race conditions). Атомарность из коробки.

- Lua scripts: Логику можно исполнять прямо внутри памяти. Быстро, дерзко.

- Надежность: У Редиса есть стримы. Можно реализовать Transaction Outbox паттерн без танцев с бубном, Kafka и Debezium. Данные льются в Postgres в фоне.

- Персистенс: Да, вся база должна лезть в RAM. Но Редис умеет сбрасывать данные на диск и реплицировать на слейвы. Если настроить прямыми руками — надежно, как швейцарские часы.

3. TigerBeetle (Бывшая)
Те самые ребята, которые нас отшили. Заявляют 1 000 000 TPS. Даже на один аккаунт. Звучит как сказка, но проверить надо. Вдруг врут? А если не врут — будем кусать локти (или снова проситься к ним).

4. Google Spanner (Швейцарский нож)
Самый загадочный зверь. Спрашиваешь у Гугла, что такое Spanner, и тебе отвечают: «ЭТО ВСЁ».
Хочешь SQL? Spanner.

Хочешь Key-Value? Spanner.

Графы? Spanner.

AI? Разумеется, Spanner! Там скоро можно будет писать запросы в духе: «AI, проверь, хватит ли у юзера 123 денег на пиво, и если да — переведи».
На презентации меня сдержало только хорошее воспитание, чтобы не спросить: «А блокчейн вы туда еще не впихнули?». Похоже, это единственное, чего там нет.

Проблема: Это распределенная БД. Она сама решает, где хранить данные. Скорее всего, она раскидает счета по разным нодам, и каждый перевод превратится в multi-node transaction. А это медленно. Но Гугл так настойчиво поил нас кофе и водил по виски-барам, что мы решили дать Спаннеру шанс. Из вежливости.

------

Результаты эпичной битвы и реальные цифры нагрузочного тестирования — в следующем посте.

А пока вангуем в комментариях. В каком порядке тулзы пришли к финишу (от лучшей производительности к худшей). И какую технологию выбрали бы лично вы?

Кто будет ближе всех — тот настоящий HighLoad архитектор.

Мы в Satori тоже регулярно сталкиваемся с вендорами ПО. Раньше я как-то не особо обращал на это внимание… но теперь я просто в восхищении от того, как изящно устроен этот рынок. Узнал потрясающие вещи:

- Оказывается, API можно смело поставлять без документации — вы же умные, сами разберетесь.
- При этом часть API будет отвечать Not Implemented
- Можно брать деньги за доработки, а потом бодро сообщать: «Ну… не получилось».
- На вопрос «почему столько багов и есть ли у вас тесты?» присылать набор юнит-тестов, сгенерированный вчера ИИ, причём таких, что они не проверяют вообще ничего.
- Спокойно тестировать прямо на проде клиента — идеально же, всё под рукой.
- Игнорировать вопросы даже в платной техпододдержке — бережём энергию.
- На срочные запросы отвечать: «Единственный человек, который в теме, у нас сейчас в отпуске».
- Требовать оплату за работы, которых в природе не существовало.
- На просьбу о функциональности говорить: «Этого нет в нашем беклоге и никогда не появится».
- Продавать «коробочное решение», которое по факту — франкенштейн из копролита, костыля и поделия джуна после курсов.
- Обвинять заказчика, в том что он нормально задачу не ставит и не проверяет
- И главное, абсолютный шедевр: подсадить клиента на «бесплатное решение», а потом элегантно выкручивать ему руки за доработки.

Вот это я понимаю, бизнес-модель!

Тот неловкий момент, когда ты банк с 15 млн клиентов, а тебя френдзонит стартап.

Операция на открытом сердце: как мы искали движок для банка
Дано: Jago Bank. Представьте себе Тинькофф на третьем году жизни, только в Индонезии, в жаре и с дикими амбициями.

Приходит к нам бизнес и с порога заявляет: — Ребята, мы тут планируем скромный рост. Было 15 миллионов пользователей, станет 30. Ну вы там подготовьтесь по-быстрому.

Мы, как порядочные инженеры, пошли к нашему текущему провайдеру Core-системы: — Сдюжите? — Пфф, легко! — отвечают. — Мы вам просто второй инстанс рядом поставим. А вы уж там сами как-нибудь трафик между ними маршрутизируйте. И отчеты склеивайте руками. И вообще, крутитесь как хотите.

В переводе с вендорского на человеческий это означало: «Fuck you».

Мы намёк поняли. Осознали, что придется писать свою Core-систему (потому что кто, если не мы?). Самая мякотка там — это Ledger. Место, где живут все бухгалтерские проводки. Нам нужно переваривать около 1000 операций в секунду и не подавиться.

Но прежде чем садиться кодить велосипед, решили глянуть на рынок. Вдруг можно что-то укра... кхм, купить?

Натыкаемся на TigerBeetle. Это молодой стартап, который запилил не базу данных, а какой-то звездолёт на стероидах. Ребята дистиллировали саму суть финансовых проводок и выдали решение с космической надежностью и скоростью. Читаешь документацию и плачешь от счастья — видно, что люди знают домен лучше, чем свои пять пальцев.

Мы загорелись. Пишем им письмо, полное надежды и уважения:
«Привет! Мы банк, у нас 15 млн юзеров, растем до 30. Ваше решение — пушка. Мы почти готовы его ставить. Давайте знакомиться и работать!»
Ответ от стартапа приходит такой, будто мы у них мелочь у метро попросили:
«"Почти готовы" не считается. Вот когда решите на 100% — тогда и пишите. До связи».
Мы слегка офигели, но виду не подали. Пишем еще раз: «Ребят, ну скажите хоть сколько стоит? Бюджет-то планировать надо». Ответ:
«Сначала поклянитесь на крови, что берете нас, а потом мы вам ценник выкатим».
А теперь следите за руками. В это же самое время Google, у которого денег больше, чем у Бога, водит вокруг нас хороводы. Кормит бесплатными обедами, поит спешелти-кофе и присылает десант из Solution Architect’ов, которые в красках расписывают, как их Spanner идеально нам подходит.

Google прямым текстом говорит: «Пацаны, мы сделаем всё, лишь бы ваш financial ledger крутился на наших технологиях. Хотите массаж стоп? Только скажите».

Выводы делайте сами: То ли у Гугла так много денег, потому что они нанимают толковых продажников. То ли они нанимают толковых инженеров, поэтому у них много денег, и они могут позволить себе унижаться перед клиентом. А может, TigerBeetle просто знают, что их код настолько хорош, что это мы должны водить вокруг них хороводы.

З.Ы. «На самом деле, поведение стартапа — это отличный стресс-тест, который они провалили. Если они так ведут себя на этапе продажи, когда все обычно улыбаются и машут, то представьте, что будет, когда у нас в 3 часа ночи ляжет прод? Google, может, и не "звездолет", но у них хотя бы есть телефон, по которому можно наорать на живого человека».

Недавно на подлодке рассказывал о том, как выстраивать обработку ошибок, чтобы потом не было мучительно больно. И вот намедни снова наткнулся на эту же проблему. Пытался оставить заявку на сайте провайдера, но рукожопые разрабы не удосужились нормально проработать ошибки. В итоге потратил пару часов своей жизни — и столько же времени техподдержки (и наверняка не только моего). Ну подумаешь, с кем не бывает. Мы же тут высокопроизводительный код пишем и играем во фреймворки, а не пользователю делаем удобно.

Мы тут периодически прокачиваем наши курсы — и настало время небольшой калибровки. Для этого нам нужны примерно 5-10 добровольцев, которые готовы поучаствовать в коротком созвоне (30-40 минут).

Что будет на созвоне:
Мы позадаём несколько простых вопросов о наших продуктах - что актуально прямо сейчас, где болит и т.д. Это помогает нам держать курс в тонусе и развивать его туда, где он действительно полезен.

Что получите вы:
После вопросов — ваша очередь. Можете рассказать о своей текущей задаче, проблеме или боли: технической, рабочей, карьерной — любой. Мы внимательно послушаем и дадим рекомендации: что сделать, куда копать, как можно ускориться или вырулить из тупика.

Условия:
1. Вы не проходили наш тренинг «Разработка без боли и сожалений»
2. Вы занимаетесь коммерческой разработкой бекенда 3+ лет

Созвон короткий, формат дружелюбный, польза — взаимная. Если хотите присоединиться — перейдите по ссылке и оставьте контакты с описанием проблемы, мы всё организуем.

Видео vs текст

Как настоящий дед при разборе душных тем, я обычно выбираю текст — книги, статьи, любые буквы. Удобство быстро прыгать между абзацами, видеть всю картину целиком и благородный шелест страниц для меня всегда были плюсом.

Но в последнее время ловлю себя на мысли, что иногда видосы всё же выигрывают. Формат текста ограничен: схемы, которые автору кажутся очевидными, читателю часто выглядят как «угадай что я имел в виду». В видео же можно рассмотреть детали, которые в тексте либо опускают («да это же капитанщина»), либо запихивают в такой формат, что толком ничего не разобрать.

Типичная разработка

Смотрел код — и заметил прекрасное. Зацените, как там проверяется время:

event.createdAt.truncatedTo(ChronoUnit.SECONDS) shouldBe OffsetDateTime.now().truncatedTo(ChronoUnit.SECONDS)

То есть просто отрезают миллисекунды в надежде, что тест «успеет» в ту же секунду. А если через миллисекунду тикнет новая? Ну да, можно же начать резать минуты… или часы…
Так и рождаются моргающие тесты, которые то проходят, то падают — чистое веселье.

Что с этим делать?

Нормальный путь — зафиксировать время через Clock.fixed() или Clock.offset() и передавать этот Clock внутрь всего, что генерирует OffsetDateTime.now(clock).
Красоты мало, зато:
• время контролируется снаружи;
• тесты становятся предсказуемыми;
• и никто больше не бегает от внезапно наступившей секунды.

Если же душа просит простых и понятных решений, в JUnit можно тупо повторять тест несколько раз. Прокатило один раз — и ладно, галочка зелёная.

Ещё вариант: не сравнивать даты напрямую, а мерить Duration.between(…) и проверять, что разница в пределах пары миллисекунд. А когда CI сервер начнет тормозить и тесты снова станут моргать — добавите еще пару секунд, делов то.

Ну и последний способ — попробовать замокать статический метод now(), если сможете конечно.

P.S.: Если понадобятся дополнительные лайфхаки по созданию говнокода — зовите, всегда рад помочь.

🔧 Немного закулисья нашей разработки

Редко удаётся рассказать — и тем более показать — детали рабочих процессов. Обычно всё покрыто коммерческой тайной. Но сегодня хочу приоткрыть занавес и поделиться тем, над чем мы работаем.

Интеграции — это огромный пласт работы между системами, несмотря на кажущуюся простоту. Постоянное перекладывание данных, развешивание JSON’ов и выпиливание XML’ей лобзиком. Мы пробовали автоматизировать это стандартными агентами, курсорами и другими универсальными инструментами. Фиксировали правила, добавляли ограничения — но идеального результата не получили.

И честно говоря, я не разделяю всеобщих восторгов по поводу ИИ-тулзов общего назначения: да, в части случаев они экономят время, но количество допилок напильником там порой слишком велико (в последнее время я прям таки заставляю себя ими пользоваться, чтобы понять ограничения). Иногда проще вручную запилить, нежели объяснять электронному болвану что от него требуется. А ещё есть важная проблема — многие из этих агентов отправляют данные непонятно куда, а далеко не каждая компания может позволить себе делиться внутренней информацией с внешними сервисами.

Поэтому мы делаем ставку на другое: узкоспециализированную систему, заточенную под конкретный фреймворк и конкретные задачи интеграции. Вот, даже лендос склепали.

Наш подход — максимально декомпозировать каждый шаг, а то что можно сделать обычными алгоритмами — сделать ими и не выпендриваться. Так можно выжать максимум даже из относительно слабых моделей, которые легко развернуть на своей инфраструктуре. Но чтобы заставить модель уверенно решать даже узкую задачу, приходится серьёзно повозиться: продумывать промпты, писать на них тесты и т.д.

В идеале мы хотим прийти к циклу обратной связи, где модель сама исправляет свои ошибки, а участие человека сводится к минимуму (хотя полностью это невозможно ввиду природы LLM).

Система у нас состоит из двух ключевых модулей:
1. Генератор кода
2. Фреймворк с четкой структурой, в который этот код встраивается
На вход подается описание желаемого выхлопа, а так же документация целевых систем. На выходе — код, который реализует желаемую интеграцию, встроенную в фреймворк.

Сейчас я работаю над промптами, тестирую разные подходы и собираю первые результаты. И — что приятно — кое-что уже начинает работать (по крайней мере мне так кажется).

В следующих постах расскажу подробнее, что получилось, какие грабли встретились, и как вы сможете применить эти идеи у себя.

Продолжение следует 👇

Когда-то давно мне приспичило разобраться как работает Linux. Нашёл Linux From Scratch — проект, где ты буквально собираешь систему с нуля. Но это упоротый вариант.

В итоге я остановился на Arch Linux — почти как Gentoo, только без бесконечной пересборки мира.
Поднимал сети вручную, вкорячивал модули ядра, правил grub.cfg, шаманил с udev и драйверами.
Естественно, сейчас я уже всё это забыл и зову админа чтобы подключить сетевой кабель. Но тогда, когда я занимался прошивками и разрабатывал под Linux, это дало мне дикий буст к пониманию того, как система устроена изнутри. И вот это как раз пет-проект класса «Минимализм» — когда ты воссоздаёшь базовый слой, чтобы прочувствовать механику. Но есть опасность — после таких экспериментов у вас может прорасти свитер

Я юзал с целью "освоить незнакомый язык на реальном проекте", мне понравилось. Из прикольного - все проекты делаются по baby steps (например, Redis начинается с задания "сделайте TCP-сервер, который отвечает PONG на PING на нужном порте), это сильно помогает постепенно въехать в новую технологию. Из не очень прикольного, но по-своему полезного - в заданиях обычно пишут, что делает, но практически не дают пояснений, как; если непонятно, приходится лезть в документацию, в другие решения, которые там же можно посмотреть, или спрашивать у ChatGPT). Бесплатно дают доступ к одному проекту, который меняется каждый месяц, плюс, когда они добавляют новый проект, у него есть период бета-тестирования, когда он тоже бесплатен.

Недавно наткнулся на codecrafters.io — прикольный сервис, где можно с нуля реализовать всякие штуки вроде Redis, Git, SQLite и прочее непотребство.

По нашей классификации это пет-проекты класса «Минимализм» — когда ты не строишь продукт, а воссоздаёшь готовую технологию, чтобы понять, как она устроена внутри.

Каждое задание там — это разбор под капотом: сетевые протоколы, файловые форматы, системы хранения, парсеры и всё то, что обычно «просто работает».

Есть бесплатный тариф, так что можно попробовать без вложений.
Мы сами пока не юзали, но выглядит интересно

StringConcat - разработка без боли и сожалений pinned a photo

Что тут происходит?

Поскольку количество подписчиков существенно увеличилось, то необходимо прояснить.
Мы — Женя и Серёжа. Инженеры и идейные задроты. В разработке на двоих — уже почти 30 лет.
Начинали, когда никакой айтишечки толком и не было, а разраб получал максимум двадцаху, и то если работу найдет. С тех пор мы прошли весь путь — от зелёных разработчиков до руководителей и архитекторов. Жрали г… (ну вы поняли), падали, вставали и снова шли в прод.

👨‍💻 Серёжа (слева) — Staff Software Engineer в Jago Bank. Руководит разработкой Core Banking. Более 13 лет в индустрии, включая ThoughtWorks, где код — это не просто текст, а философия. Руководил распределёнными командами инженеров, запускал банковские приложения в Сингапуре, переводил монолиты в микросервисы и спасал проекты когда остальные уже опустили руки. Развивал инженерные практики до уровня Elite по DORA-метрикам.

🤖 Женя (справа) — технический директор в Satori. Занимается проектированием банковского софта, а так же руководит разработкой AI-агентов в области интеграции систем. Делал карточный процессинг в Яндекс.Кассе и Банке 131, выводил в прод систему мониторинга инсайдерской торговли в Behavox (UK), писал алгоритмы диагностики заболеваний в AbeHealth, делал телеком и автопроекты, включая электромобили «АТОМ».
Спикер ArchDays, КРАБР и Podlodka, научный редактор перевода книги Learning Domain-Driven Design.

Мы столько раз наступали на грабли, что уже различаем их по звуку удара об лоб.
Со временем мы заметили одну вещь: почти все ошибки повторяются из раза в раз.
Сначала это был наш пет-проект, способ собрать свой опыт и не сойти с ума.
Но оказалось, что всё это нужно не только нам.

Так появился наш курс «Разработка без боли и сожалений»,
где мы рассказываем, как:
- Собирать требования и исследовать предметку,
- Моделировать домен и писать тесты,
- Строить взаимодействие с внешним миром,
- Как всё это красиво натягивать на DDD и Чистую Архитектуру.
и многое другое
Здесь мы делимся практиками, которые помогают строить технологии и команды без выгорания и хаоса.

А этот канал — для тех, кто неравнодушен к своему делу. Если вы здесь, значит, вам важно делать хорошо, понимать, как и зачем всё устроено,и не мириться с «ну и так сойдёт», а мы вам стараемся по возможности помогать.
Спасибо, что вы с нами ❤️

Лайтовый видос про набор паттернов, который мы используем для самообразования и получения максимального выхлопа. Несмотря на кажущуюся простоту и очевидность, бустануться можно очень неплохо. Приятного просмотра!

YouTube | ВК