с Рождеством! послушала на одном дыхании очень интересный подкаст от Евгения Сулейманова и Михаила Поливахи

про что он:
⚙️ зачем разработчику контрибьютить в open source
⚙️ зачем разработчику быть спикером
⚙️ как это влияет на рост, видимость, уверенность и качество мышления
⚙️ как выбирать технологии и выстраивать обучение, если не хочется бегать за каждым трендом
⚙️ AI на рынке

посмотреть можно на youtube

📚обзор на ч. 2 «Предметно-ориентированное проектирование» от Эрика Эванса (Структурные элементы)

ч.1

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

на этом фоне smart ui выглядит как антипаттерн. вся логика живет в экранах, каждый контроллер сам ходит в базу, валидирует, считает правила, дергает интеграции. код отражает кнопки и формы, а не бизнес. язык предметной области не формируется, изменения становятся дорогими, усложнение ломает систему. при этом smart ui честно хорош для простых задач, админок, коротких проектов и быстрого старта. он просто несовместим с целью ddd - строить модель как носитель знания.

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

сущность определяется не набором атрибутов, а непрерывностью существования и идентичностью во времени. она может менять форму, состояние, представление, но оставаться собой. у нее всегда есть идентификатор и четкое определение равенства. объект-значение наоборот существует как описание. важны не «кто», а «какое». адрес, деньги, период, координаты. value object желательно делать неизменяемым, чтобы безопасно передавать и переиспользовать. если изменяемость нужна ради производительности, ее надо изолировать и не делить между владельцами.

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

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

агрегат задает границы согласованности. это группа связанных объектов, которая изменяется как единое целое. у агрегата есть корень, и только он доступен извне. внешние ссылки могут указывать только на root. внутренние сущности живут только внутри агрегата. агрегат определяет транзакционные границы, изоляцию и правила доступа.

создание сложных объектов и агрегатов выносится в фабрики. фабрика скрывает детали сборки, гарантирует инварианты и возвращает корректный объект сразу в рабочем состоянии. фабрика - архитектурный элемент, а не бизнес-сущность. иногда она живет в корне агрегата, иногда в отдельном объекте, иногда внутри логического владельца. простой объект можно создавать через конструктор, но порог для фабрики в ddd довольно низкий.

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

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

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

💻как мы переехали с Oracle на PostgreSQL без даунтайма [часть 1: контекст и работа с кодовой базой]

весной 2025 я начала работать над задачей перевода проекта с Oracle на PostgreSQL.

с чем имеем дело:
1. микросервисная архитектура
2. java, spring boot. в коде и нативные sql-запросы, и hibernate
3. активные бизнес-релизы, команда постоянно выкатывает новые фичи
4. человеко-ресурсы ограничены: я, позже 1-2 разработчика (в зависимости от фазы), 1 devops и 1-2 qa
5. ключевое - никакого даунтайма. пользователь не должен заметить, что под капотом вообще что-то меняется

при таких вводных перевод проекта с одной базы на другую - это не «миграция», а отдельный длительный процесс, который живет параллельно с развитием продукта.

если обобщать, процесс состоит из нескольких крупных этапов:
1. анализ и очистка данных
детальный разбор накопившегося легаси, неиспользуемых таблиц, исторических костылей
2. миграция данных
3. переработка liquibase
4. переработка прикладного кода микросервисов
учет нативных запросов, особенностей ORM, тех самых «так исторически сложилось» и т.д.
5. организационные и процессные вопросы
подготовка инфраструктуры, коммуникация с командами, синхронизация бизнес- и тех-релизов, стратегия веток, взаимодействие с сопровождением и dba, заранее продуманные сценарии проблем и способы их решения. техническая часть - это лишь половина задачи. вторая половина - люди, процессы, ограничения и договоренности.

к чему стремилась: в PostgreSQL есть все исторические данные, поды пишут в нее новые напрямую — и это все без даунтайма.

в этой части я расскажу о работе на уровне кода.

при продумывании перехода важно сразу учитывать различия между базами.
например, в Oracle пустая строка фактически равна null, в Postgresql такого поведения нет. или, например, boolean в виде 0/1 или Y/N становится честным true/false.
мы очень много правили кастомные запросы и clob. было много разных ситуаций.

liquibase правили по принципу: пока не запустится - чиним.
во многих местах хватало массовых правок через ide (например, number(1,0) -> boolean). важно не забывать и про dbms-фильтры в liquibase (например, dbms=oracle), которые легко пропустить.

для запуска скриптов использовали контексты:
• ddl - context="!PREP and !PROD"
• dml - context="!IFT and !PREP and !PROD"

ddl в первом случае накатывался отдельным процессом (через ДБА), а dml фактически не требовался - но к этому я еще вернусь позже.

еще один исторический нюанс - использование sequence в некоторых сервисах. при миграции данных пришлось отдельно продумывать механизм динамического сдвига значений, чтобы избежать коллизий после переключения. мы реализовали это на старте pod-а: проходились по всем sequence микросервиса, сравнивали значения в oracle и postgresql и при необходимости сдвигали их в postgres.

логика сдвига зависела от скорости роста таблицы и объема данных. в ряде сервисов хватало общего коэффициента с запасом (например, x2-x3).
важно, что этот механизм можно было безопасно запускать многократно - при рестарте микросервиса. дополнительно была сделана административная ручка для runtime-сдвига sequence. решение легко тиражировалось между микросервисами - менялась только формула расчета нового значения.

итог: благодаря этим работам кодовая база микросервиса научилась дружить со слоном.

а о стратегии миграции исторических данных поговорю в следующей части.
💎 - жду, очень интересно!
(насыпьте пж алмазов, нужно понимать отклик такого контента)

💻как мы переехали с Oracle на PostgreSQL без даунтайма [часть 2: миграция данных]

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

возможные подходы к миграции данных

а) spring batch
классический инструмент для etl-процессов (extract, transform, load).
миграция реализуется на уровне кода: несколько datasource, reader, processor, writer, job, step.

плюсы - гибкость и полный контроль над логикой.
минусы - сложность настройки и поддержки. по сути, это отдельное приложение со своей конфигурацией и жизненным циклом.

б) dblink
прямое подключение к oracle и перенос данных запросами.
рабочий, но достаточно низкоуровневый вариант.

в) ora2pg
утилита для миграции схемы и данных из oracle в postgresql.
хорошо подходит для одноразового переноса, но плохо ложится на сценарии с активной записью и требованиями zero-downtime.

г) fdw и утилиты поверх него (например, ora_migrator)
идея fdw - создание в postgresql «прокси»-таблиц с прямым доступом к oracle.
можно читать данные из oracle как из обычных таблиц postgresql.
утилиты поверх fdw упрощают жизнь: автоматизируют перенос данных, конвертацию типов и рутинные операции. под капотом все равно fdw, но с меньшим количеством ручной работы.

д) cdc (change data capture)
например, oracle goldengate или debezium.
идея - онлайн-репликация данных без остановки системы: изменения (insert / update / delete) сразу летят в postgresql.

плюс - идеально подходит под zero-downtime.
минус - дополнительная инфраструктура и необходимость разбираться в инструменте.

в итоге для нашего проекта остановилась на cdc.

ожидания от cdc-решения были следующие:
1. opensource или free
2. поддержка oracle → postgresql
3. начальная загрузка данных + онлайн-репликация изменений
4. возможность накатываться на уже существующие таблицы
5. поддержка преобразований данных (например, типов)

рассмотренные cdc-решения

oracle golden gate (free)
бесплатная версия умеет реплицировать только oracle → oracle, что сразу делает ее непригодной для нашего сценария.
полную версию я пыталась раскатить отдельно, но опыт оказался довольно болезненным: нормально не завелась ни на linux, ни на macos, ни на windows (пробовали разные версии). плюс очень ограниченное количество материалов вне официальной документации - в основном приходится ориентироваться на коды ошибок и мануалы.

airbyte
есть opensource-версия с активным github и платные расширения.
oracle connector от разработчиков платный, а community-версия сильно ограничена:
• нельзя управлять типами данных на конвейере
• не умеет писать в уже существующие таблицы postgresql
• не поддерживает полноценную онлайн-репликацию

по факту это скорее инструмент для разовой или периодической загрузки (cron / ручной запуск), чем полноценный cdc.

debezium
полноценный opensource с большим коммьюнити и живой экосистемой.
есть ui, но на начало 2025 он выглядел довольно сырым и практической ценности почти не нес - удобнее использовать связку kafka connect ui + kafka ui + http.

по результатам экспериментов debezium лучше всего подошел под требования проекта.
основной минус - высокий порог входа и необходимость работы с kafka-инструментарием, что добавляет сложности в поддержке.

в следующей части - продолжение
💎 - поддержка!

💻как мы переехали с Oracle на PostgreSQL без даунтайма [часть 3: процессы]

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

про организацию релизов

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

по веткам использовали следующий подход:
параллельно release-x создавалась ветка postgres-release-x с полностью идентичным кодом плюс доработки под postgresql.
эта ветка не мержилась в master до выхода в прод.

тестовый стенд велся в двух namespace:
• основной - на master
• отдельный - на postgres-ветке

это позволяло не блокировать разработку и тестирование и не тормозить бизнес-релизы из-за миграционных нюансов. cherrypick-и в релизные ветки выполнялись синхронно.

в итоге процесс на тестовом стенде выглядел так:
1. для целевого микросервиса заводилась ветка postgres-release-<version>, в которую вливались все изменения. релизные правки подтягивались через cherrypick
2. микросервис можно было деплоить сразу - ddl накатывался нативно через liquibase
3. во всех postgresql-микросервисах отключались джобы и очереди, чтобы второй namespace не перехватывал события и не писал данные неконсистентно. управление выполнялось через feature flags
4. в окружении задавались оба datasource: oracle и postgres, выполнялась синхронизация sequence
6. временно отключались fk и другие тяжелые структуры через feature flags для проведения миграции данных
7. база подготавливалась к работе с debezium
8. выполнялась миграция данных и последующее тестирование

на препроде и проде цикл был следующим:
1. подготавливалась инфраструктура
2. заранее накатывались проверенные ddl через ДБА в postgreSQL базу
3. запускался debezium для перелива снепшота и онлайн-изменений
4. микросервис деплоился на postgres-ветке: клиенты начинали работать с новой базой, а debezium в моменте догонял оставшиеся изменения из oracle, включались fk и другие тяжелые структуры

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

в следующей статье разберу debezium как инструмент и расскажу о его устройстве и тонкой настройке.
💎 - поддержка!

как думаете: расширять статью и идти на хабр? насколько интересно читать такие личные истории? чем-то полезно, даже если не ложится в рабочее?

💎- без слов да

📚обзор на ч. 3 «Предметно-ориентированное проектирование» от Эрика Эванса (Углубляющий рефакторинг)

ч.1
ч.2

рефакторинг начинает влиять на надежность и «долголетие» системы только тогда, когда опирается не на чистоту кода, а на понимание предметной области. либо узнали что-то новое о бизнесе — код меняется, либо делаем модель точнее.

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

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

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

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

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

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

логика разделяется по эффектам: чистые функции без побочных эффектов, простые команды для изменений состояния, сложные вычисления — объекты-значения.

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

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

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

💎 - спасибо!

📚обзор на ч. 4 «Предметно-ориентированное проектирование» от Эрика Эванса (Стратегическое проектирование)

ч. 1
ч. 2
ч. 3

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

единая доменная модель для большой системы почти всегда недостижима или слишком дорогая. поэтому систему делят на части — bounded contexts.

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

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

extreme programming хорошо поддерживает целостность модели внутри одного контекста, но между контекстами нужны архитектурные решения. варианты: shared kernel, customer/supplier, conformist, anticorruption layer.

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

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

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

дистилляция и углубляющий рефакторинг делают модель очевидной и гибкой. изменения кода отражают изменения в понимании предметной области: узнали что-то о бизнесе — код меняется, уточнили модель — код уточняется.

стратегическое проектирование начинается с оценки ситуации: карта контекстов, единый язык, смысловое ядро, технологии, навыки и интерес команды.

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

💎- спасибо за обзор книги!

Что за CDC и Debezium такие?💻

В предыдущих постах я рассказывала о миграции данных и упомянула Debezium как целевое решение, поэтому хотелось бы рассказать о нём чуть подробнее.
Репозиторий проекта: https://github.com/debezium/debezium

Change Data Capture (CDC, захват изменений данных) — это технология, которая позволяет отслеживать и фиксировать изменения в базе данных в реальном времени, а затем передавать эти данные в другие системы. Возможно, в кабанчике про это читали, если не работали напрямую.

Debezium - это CDC-платформа, которая использует все блага Apache Kafka и Kafka Connect для обеспечения надежности, отказоустойчивости и масштабируемости.

Коннектор Kafka Connect отслеживает базу данных, считывает все изменения и публикует их в Kafka-топики. Также Debezium можно запускать через embedded-движок прямо внутри приложения, получая те же события изменений данных без использования Kafka. Ещё один вариант — поставить целый Debezium Server (готовое к использованию приложение). Подробнее об архитектуре

Debezium полезен в ряде следующих сценариев: инвалидация кеша, интеграция, миграция данных, CQRS.

Как же это работает на практике? На примере миграции Oracle -> PostgreSQL.
Oracle фиксирует все изменения в redo log. При первом запуске коннектора Debezium делает initial snapshot — полное считывание состояния таблиц. После snapshot-а коннектор продолжает стримить изменения из redo log, превращая INSERT / UPDATE / DELETE в упорядоченные CDC-события, которые отправляются в Kafka. Далее sink-коннектор или consumer применяет эти изменения к PostgreSQL, воспроизводя операции в том же порядке. В результате Postgres постепенно синхронизируется с Oracle. Важно: Oracle должен быть настроен на архивное логирование

Что доступно сейчас?
Source-коннекторы поддерживают: MongoDB, MariaDB, MySQL, PostgreSQL, Oracle, SQL Server, Db2, Cassandra, Spanner и Vitess + Informix (инкубационный режим).
Sink-коннекторы — JDBC и MongoDB Sink.

Для раската миграции мне понадобились образы Kafka (Kafka, Zookeeper, Kafka UI, Kafka Connect UI) и Debezium Connect. UI мной был проигнорирован умышленно, так как летом 2025 он был сырым и нерабочим. На февраль 2026 репозиторий UI уже архивирован, так как появилась новая платформа с UI: разработка идёт активно, но проект пока на ранней стадии.

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

😭как правильно жаловаться на баг? давайте разбираться.

когда задаёшь вопрос на том же Stackoverflow или issue на GitHub с подозрением на баг, важно дать такой код, чтобы другие могли быстро понять и воспроизвести проблему. в англоязычном сообществе это называют MRE / MCVE / MWE / reprex = минимальный, воспроизводимый пример.

код должен быть минимальным, полным и воспроизводимым.

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

что такое полный? чтобы другой разработчик смог повторить баг быстро прямо из примера. red flag - это вставлять скриншоты кода. всегда стоит использовать отдельные текстовые блоки для каждого фрагмента.

что такое воспроизводимый? код действительно должен выдавать ту же проблему. стоит описать точно: какая ошибка, на какой строке, что должно было работать. также стоит обязательно предварительно проверить на чистом окружении.

если соблюдать эти три основные правила, люди гораздо быстрее помогут разобраться или создать PR.

также советую к прочтению эту статью.

💎 - полезно, дарреровна

⚡️ активно слежу за проектами в экосистеме Java. пару лет назад коллеги рассказывали мне про JPA Buddy, и инструмент сразу заинтересовал. очень быстро он стал хитом: на сегодня у него 5 миллионов скачиваний, его заметили в JetBrains, и он вошёл в продуктовую линейку компании.

после этого ребята из Haulmont начали работать над Amplicode, чтобы расширить возможности интеграций с разными средами и дать всем Spring-разработчикам доступ к современным инструментам. также вместе с компаниями Axiom JDK и Группой Астра они создали и продолжают развивать открытый бесплатный российский форк IntelliJ IDEA Community — OpenIDE.

Amplicode — это плагин для IntelliJ IDEA (Community и Ultimate), GigaIDE и OpenIDE, который ускоряет и упрощает разработку сервисов и web-приложений на Spring. А версия для VS Code позволяет быстро создавать административный интерфейс на React Admin.

подробно о возможностях плагина можно узнать на сайте (правда, советую поставить себе и попробовать - делов на пару минут)
свой отзыв я оставила здесь

💻миграция на Spring Boot 3 (Java 17): особенности процесса

да, понимаю: звучит как тема из 2022 года.
но по опросам здесь около 20% всё ещё работают на старых версиях. так что, возможно, кому-то будет полезно увидеть верхнеуровневую картину миграции (или кого в целом обошла такая участь на проекте)

наш проект был на Java 11 + Spring Boot < 2.7.
Spring Boot 3 требует минимум Java 17, поэтому логичный первый шаг - это обновление Java.

⛏этап 1. переезд на Spring Boot 2.7 + Java 17
это своего рода мост.
что происходит на этом этапе:
• обновление Java 11 → 17
• обновление Spring Boot → 2.7
• обновление зависимостей
• небольшие правки в application.properties / yaml
• начинают светиться deprecated-конфигурации

основная боль - это зависимости. в целом, работа достаточно быстрая и техническая.

⛏этап 2: переезд на Spring Boot 3
а вот тут начинается самое интересное.

• главное изменение - переход с Java EE на Jakarta EE. Все пакеты javax.* стали jakarta.*, и это затрагивает JPA, Validation, Servlet API, кастомные фильтры и интеграции.
• Hibernate 6 теперь используется в Spring Boot 3. меняется поведение ORM: может измениться генерируемый SQL, стратегии именования, поведение join’ов, pagination. иногда внезапно проседает производительность запросов, которые раньше работали стабильно, приходится разбираться, что поменялось под капотом.
• Spring Cloud Sleuth больше не поддерживается, вместо него используется Micrometer Tracing. также меняются конфигурации Spring Security, Feign, Actuator, Prometheus и другие коровые компоненты. есть изменения в springdoc-openapi, логировании (Logback) и поведении MVC. например, сопоставление URL с завершающим слэшем теперь отключено по умолчанию: /api/test и /api/test/ считаются разными маршрутами, что может повлиять на api-gateway.
• Actuator стал более строгим по умолчанию. подход к отображению чувствительных конфигурационных значений изменён в сторону большей безопасности, что тоже может потребовать корректировки настроек.
• тесты после перехода часто начинают падать из-за Jakarta, обновлённых конфигураций и изменений во фреймворке. где-то нужно переписать конфигурацию, обновить моки, поменять импорты.

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

в целом, процесс похож на игру «убей крота»: пока сборка наконец не станет зелёной и не пройдут минимальные проверки - ты продолжаешь свое путешествие в мире неожиданностей…

ах! юбилей! 💻🤭
спасибо, что читаете, друзья

🏀собери команду из покемонов…
или из ии-агентов.

в Claude Code представили новую экспериментальную функцию — Agent Teams. она позволяет запускать не одного ai-ассистента, а сразу несколько агентов, которые работают вместе над одной задачей. по сути, это полноценная команда разработчиков-ии: есть тимлид, есть исполнители с разными ролями, есть распределение ответственности.

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

в документации приводят несколько сценариев:

🎮parallel code review — несколько агентов проверяют один pr с разных сторон: безопасность, производительность, тесты.
🎮debugging with competing hypotheses — агенты параллельно проверяют разные гипотезы бага и сопоставляют выводы.
🎮реализация фичи — один отвечает за backend, другой за frontend, третий за тесты и документацию.

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

и вот интересный кейс: команда из 16 агентов за две недели и примерно 20 000 долларов без вмешательства людей создала 100 000-строчный компилятор C на базе Rust, способный компилировать ядро Linux.

бу, испугался?