Андрей Казаков

Представьте танец - каждый участник знает свои шаги и реагирует на движения партнёров без указаний хореографа. Но стоит одному из танцоров сбиться или споткнуться, и весь зал погружается в несвязный хаос!

Если ваши интеграционные тесты тонут в хаосе тестовых данных, а ручные SQL-скрипты вызывают головную боль, то Database Rider — ваш супергерой. В прошлом посте мы разобрали основы, а сегодня нырнем в практику: от многоформатных датасетов и хитрых проверок БД до ускорения тестов и организации данных без бардака.

Если вы работаете в разработке ПО, особенно в продуктовых командах, то, скорее всего, слышали о HADI-циклах. HADI часто воспринимают как инструмент менеджеров и аналитиков: A/B-тесты, конверсии, метрики.

ACID транзакции мощный инструмент, которые позволяет поддерживать целостность данных в реляционных СУБД. Это очень простой в использовании механизм - если что-то пошло не так, то мы откатываем транзакцию, а данные остаются согласованными.

👩‍💼 Менеджеры любят видеть процесс целиком: от старта до результата. Но в хореографии это сложно - сервисы общаются напрямую, и картина теряется. 🎯 Оркестрация делает процесс прозрачным: бизнес и архитекторы видят одну и ту же модель, которую можно и читать, и исполнять.

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

Представьте, что ваша система — это оркестр, где каждый музыкант знает свою партию, но никто не машет палочкой. Вместо хаоса — гармония бизнес-процессов. В этом посте разберем, как Domain-Driven Design (DDD) и хореография в распределенных системах создают именно такую синергию: от моделирования событий до масштабируемой архитектуры.

Всем привет! Сегодня хочу поднять вопрос энергоэффективности наших приложений. В эпоху экспоненциального роста вычислительных мощностей все больше внимания уделяется вопросам энергопотребления и снижения воздействия на окружающую среду. В этом контексте энергоэффективность и энергосбережение превращаются в ключевой и стратегический приоритет для IT…

Все знают CAP-теорему: при сетевых сбоях приходится выбирать между доступностью и консистентностью. Но вот проблема: в реальности сбои случаются не так часто. Большую часть времени система работает нормально. И здесь CAP молчит. Что происходит, когда сеть не падает? Какие компромиссы мы делаем тогда? Ответ даёт теорема PACELC

В управлении продуктами и проектами самая важная часть - выбрать то, над чем работать в первую очередь. В прошлый раз мы разобрались в простом способе приоритизации MoSCoW, который позволяет быстро раскидать задачи по приоритету. Но что, если менеджер продукта все задачи помечает как Must have, все важны и все нужно как можно быстрее? Здесь поможет…

Представьте ситуацию: пользователь покупает «Тур под ключ», но на этапе оплаты его карта отклонена. Авиабилет и отель уже забронированы. Ваша система должна отменить все эти изменения, не оставив недовольных клиентов. Классические транзакции тут не работают. Выход — компенсационные транзакции. Давайте разберем, как это работает и когда это нужно и…

Всем привет! Вы когда-нибудь работали с системой, которую боялись трогать? Где каждое изменение вызывало лавину багов, а обновление базы данных превращалось в операцию с многодневным даунтаймом? Я тоже. И чаще всего виной всему — не плохие разработчики, а слабая архитектура.