Spring АйО

⚡️ Можно ли запретить AI-агенту ломать архитектуру Spring-приложения? Одних инструкций в AGENTS.md и Skills недостаточно. Агенту нужны инструменты, которые проверят результат и помогут найти ошибку.

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

Но видео не про ArchUnit. Оно про то, как тесты, линтеры и анализаторы создают для AI-агента обратную связь и помогают ему работать качественнее. 😉 СМОТРЕТЬ НА YOUTUBE 😄 СМОТРЕТЬ В VK ВИДЕО 🥰 СМОТРЕТЬ НА RUTUBE

⚡️ Можно ли запретить AI-агенту ломать архитектуру Spring-приложения? Одних инструкций в AGENTS.md и Skills недостаточно. Агенту нужны инструменты, которые проверят результат и помогут найти ошибку.

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

Но видео не про ArchUnit. Оно про то, как тесты, линтеры и анализаторы создают для AI-агента обратную связь и помогают ему работать качественнее. 😉 СМОТРЕТЬ НА YOUTUBE 😄 СМОТРЕТЬ В VK ВИДЕО 🥰 СМОТРЕТЬ НА RUTUBE

👀 Как понять, на чём тормозит запуск Spring Boot Нередка ситуация, когда приложение стало запускаться заметно дольше, а в логах все ок. Может быть такое, что время уходит на создание бинов, загрузку данных или подключение к внешним сервисам. Чтобы найти узкое место, Spring предоставляет интерфейс ApplicationStartup. Есть три стула основные реализации: – DefaultApplicationStartup. Используется по умолчанию и фактически ничего не записывает. – BufferingApplicationStartup. Хранит события запуска в памяти. Удобен для локальной диагностики, тестов и просмотра через Actuator. – FlightRecorderApplicationStartup. Передаёт данные в Java Flight Recorder для более глубокого профилирования. Для быстрого анализа можно подключить буферизацию:

SpringApplication app = new SpringApplication(Application.class);

app.setApplicationStartup(
    new BufferingApplicationStartup(2048)
);

app.run(args);

И открыть эндпоинт в настройках:

management.endpoints.web.exposure.include=startup

После запуска временная шкала будет доступна по адресу:

GET /actuator/startup

В ответе можно увидеть продолжительность отдельных этапов, их иерархию и имена создаваемых бинов:

{
  "duration": "PT0.000754S",
  "startupStep": {
    "name": "spring.beans.instantiate",
    "tags": [
      {
        "key": "beanName",
        "value": "specialService"
      }
    ]
  }
}

У эндпоинта есть важная особенность: – GET возвращает текущий снимок временной шкалы; – POST возвращает снимок и очищает буфер. Можно добавлять и собственные этапы. Например, отдельно измерять подключение к базе данных:

StartupStep step =
    applicationStartup.start("app.database.connect");

try {
    step.tag("database", "main");
    connectToDatabase();
} finally {
    step.end();
}

Такие этапы появятся рядом со стандартными событиями Spring. Это особенно полезно, когда во время инициализации выполняются миграции, прогреваются кэши, загружаются модели или создаются подключения к внешним системам. Для продолжительного и более детального профилирования лучше использовать FlightRecorderApplicationStartup вместе с JFR и Java Mission Control. Короче: – нужен быстрый снапшот запуска - юзаем BufferingApplicationStartup; – нужен глубокий анализ JVM - юзаем FlightRecorderApplicationStartup; – нужна диагностика бизнес-инициализации, тогда добавляем собственные StartupStep. Как-то так 🤓 🔗 Фул статья: https://habr.com/ru/companies/spring_aio/articles/1066976/

🤖 AI-агент просил разрешить правку файла проекта. А сам добавил SSH-ключ злоумышленника Ситуация. Вы клонируете репозиторий, просите AI-агента настроить проект и видите обычное подтверждение:

Разрешить изменение `project_settings.json`?

Нажимаете «Разрешить». Только агент записывает данные не в настройки проекта, а в ~/.ssh/authorized_keys. Если SSH доступен извне, добавленный ключ может открыть злоумышленнику вход на компьютер без пароля. Исследователи Wiz назвали эту атаку GhostApproval и воспроизвели её сразу в шести AI-инструментах: – Amazon Q Developer – Claude Code – Augment – Cursor – Google Antigravity – Windsurf Схема-то простая и рабочая) Вредоносный репозиторий содержит чисто символическую ссылку, файловую «переадресацию». Файл выглядит как project_settings.json, но на самом деле ведёт к ~/.ssh/authorized_keys или ~/.zshrc. README просит агента изменить типа «настройку проекта». Агент выполняет инструкцию, следует по ссылке и пишет уже за пределами репозитория. Ну красота же. Самое неприятное то, что в в тестах Windsurf и Amazon Q успевали изменить файл ещё до подтверждения пользователя. Augment выполнял чтение и запись вообще без запроса. А в Claude Code агент распознал реальный файл, но человеку всё равно показал безобидное имя project_settings.json. AWS, Cursor и Google выпустили исправления. В актуальных версиях Claude Code есть предупреждение о таких ссылках. На момент публикации исследования Wiz не получила подтверждения исправлений от Augment и Windsurf. Мораль сей басни здесь интереснее самой уязвимости: кнопка «Разрешить» не защищает разработчика, если интерфейс показывает ему не то действие, которое действительно выполнит агент. Поэтому незнакомые репозитории лучше открывать в контейнере или виртуальной машине, а перед запуском агента проверить файловые ссылки командой: find . -type l -ls 💡 Источники: – исследование Wiz, – бюллетень AWS, – официальное исправление Cursor. Они нас погубят... 🙃

🤖 ИИ выдумал уязвимости SQLite. Они попали в официальные базы Шесть новых уязвимостей SQLite оказались выдуманными. Но до того, как это выяснилось, они успели получить номера CVE, попасть в Национальную базу уязвимостей США и системы автоматического анализа безопасности. Одной из них даже присвоили оценку 9,8 из 10 по шкале критичности CVSS. Почти максимальная опасность. Это когда возможна утечка данных, отказ в обслуживании и удалённое выполнение кода. Представьте реакцию команды 😅 Сканер находит критическую уязвимость в зависимости, сборка краснеет, релиз останавливается, разработчики начинают искать способ обновиться или закрыть дыру. А дыры... Не существует) История началась с того, что неизвестный автор опубликовал на GitHub более 50 описаний уязвимостей. Вот тот самый репо. Исследователи JFrog решили проверить шесть CVE, якобы обнаруженных в SQLite. Они собрали заявленные версии базы в изолированных контейнерах, запустили примеры эксплуатации под AddressSanitizer и изучили исходный код. Результат получился впечатляющим: – упомянутых функций не существовало в заявленных версиях SQLite; – номера строк указывали за пределы файлов; – описанные исправления никогда не вносились; – часть PoC содержала невалидный SQL; – ни один из примеров не вызвал обещанную ошибку. После более широкого аудита выяснилось, что из 55 опубликованных описаний 54 были полностью выдуманы. Ещё одно основывалось на реальном баге, но содержало непроверенные CVE-данные. JFrog предполагает, что описания были сгенерированы при помощи LLM. С этим уже согласились и разработчики SQLite и на официальной странице проекта шесть CVE помечены как несуществующие баги и вероятные галлюцинации ИИ. Сами записи начали удалять из баз. И вот здесь начинается самое интересное. Во многих компаниях новые CVE автоматически попадают в сканеры, CI, отчёты и задачи для разработчиков.

А – автоматизиция. Например, в TELUS Dependabot постоянно проверяются зависимости и при обнаружении уязвимости создаёт предупреждение и рекомендует исправляющий PR. В Synergy проверки Dependabot автоматически запускаются при создании каждого PR. А JFrog Xray можно настроить так, чтобы по данным об уязвимости система создала задачу в Jira, запретила скачивание библиотеки или остановила сборку.

Поэтому ошибочная CVE, прошедшая проверку используемой платформы, способна превратиться не просто в строчку в базе, а в настоящий PR, задачу для разработчика или заблокированный релиз. Получается почти идеальный цикл: 1. ИИ придумывает уязвимость. 2. Автоматическая система принимает её за настоящую. 3. Другой ИИ-агент пытается найти несуществующую функцию и написать для неё патч. 4. Команда тратит вполне настоящее рабочее время. Походу, одного номера CVE и высокой оценки теперь недостаточно. Для свежих уязвимостей придётся проверять подтверждение от разработчиков проекта, ссылку на исправляющий коммит, затронутые версии и воспроизводимость PoC. Добро пожаловать в эпоху, когда security-сканеру тоже нужен фактчекинг 🙂 📎 Расследование JFrog: https://research.jfrog.com/post/sqlite-critical-cves-or-llm-slops/ 📎 Позиция SQLite: https://sqlite.org/cves.html

🛠 Axelix вышел в GA

Почему этот бин вообще создался? Откуда приехало значение property? Кто съел все соединения из пула? И где мы опять поймали N+1?

В такие моменты мы идём в логи, подключаем дебаггер и начинаем разбираться во внутренностях Spring. Ну или просто перезапускаем приложение, вдруг больше не повторится. Axelix появился как раз для таких расследований. Он подключается к работающим Spring Boot-приложениям и показывает, что происходит с бинами, конфигурацией, транзакциями, кэшами и scheduled-задачами. А ещё ищет известные проблемы и сомнительные настройки — те самые костыли, которые Spring-разработчики собирают в проде уже много лет. И вот теперь Axelix вышел в GA — состоялся релиз версии 1.0.0. До него были milestone-версии, которые успели попробовать несколько десятков команд. Исходный код проекта открыт под лицензией LGPL-3.0. Версию 1.0.0 уже можно использовать в продакшне, хотя разработчики советуют не спешить и для начала обкатать её на dev-окружении. Что, в общем-то, звучит разумно. Если хочется узнать, зачем появился Axelix и какой путь проект прошёл до первого стабильного релиза, об этом подробно рассказал Михаил Поливаха — технический лидер Axelix и эксперт Spring АйО. 📎 Мотивация создания продукта: https://habr.com/ru/companies/spring_aio/articles/1065202/ 📱 Канал Axelix: http://t.me/axelix_official 👩‍💻 Исходный код на GitHub: https://github.com/axelixlabs/axelix

🔨 Как Kafka сломала JVM Казалось бы, что может пойти не так при обычном вызове KafkaTemplate.send()? Метод возвращает Future, ошибки обрабатываются в коллбэке, всё выглядит ок. Но после сетевого сбоя приложение начинает бесконечно выбрасывать IllegalMonitorStateException, помогает только перезапуск. В статье от нашего участника Spring АйО Академии, Евгения Рудикова, развернулся настоящий технический детектив: корутины, скрытая блокировка в Kafka Producer, вложенные synchronized, JIT-компиляция, CodeCache и баг OpenJDK. Разбираемся, как и в JVM могут быть баги, которые проявляются в определённых условиях, и почему библиотечный код стоит заранее считать потенциально блокирующим. 📎 Полный текст: https://habr.com/ru/companies/spring_aio/articles/1064528/

👩‍💻 Новиночка от JetBrains JetBrains выпустила в ранний доступ JetBrains Context. Он помогает ИИ-агентам быстрее разбираться в больших проектах. Обычно перед выполнением задачи агент долго изучает код (ищет нужные файлы, читает классы и проверяет связи между модулями). Новая тула заранее создаёт индекс кодовой базы и помогает сразу находить подходящие участки кода. Работает с Claude Code, Codex CLI и Junie CLI. Поддерживается поиск сразу по нескольким репозиториям, даже если они не скачаны локально. По тестам JetBrains инструмент обещает сократить: ☑️количество шагов агента до 68%; ☑️время выполнения задачи до 59%; ☑️расходы до 48%. Доступно подписчикам JetBrains AI без дополнительной оплаты и не расходует AI-квоту. Что на рынке уже есть: ☑️ Augment Context Engine самый близкий аналог. Работает с разными агентами через MCP и также поддерживает несколько репозиториев. ☑️ Sourcegraph более мощное решение для крупных компаний с сотнями репозиториев. Умеет искать код, зависимости, изменения и историю коммитов. Есть self-hosted-версия. ☑️ GitHub Copilot тоже индексирует репозитории, но в основном работает внутри GitHub и Copilot. Получается: ☑️ JetBrains Context — простой старт для пользователей JetBrains AI; ☑️ Augment — универсальный вариант для разных агентов; ☑️ Sourcegraph — решение для крупных корпоративных проектов; ☑️ GitHub — встроенный инструмент для команд на Copilot. Наверное, одного мощного ИИ-агента уже недостаточно. Ему ещё нужен отдельный инструмент, который быстро объяснит, как устроен проект. Для больших Spring-проектов с множеством модулей и внутренних API в целом это может дать эффект. Но надо тестить. 🧐 Годно?

🍃 Новый HTTP-метод, IPv6 бесперспективен, QUERY удалят | Spring АйО Подкаст №69 😉 СМОТРЕТЬ НА YOUTUBE 😄 Чуть позже... 🥰 СМОТРЕТЬ НА RUTUBE 🗯 СЛУШАТЬ НА ЯНДЕКС.МУЗЫКЕ 🤩 СЛУШАТЬ НА SPOTIFY 🤩 СЛУШАТЬ НА APPLE PODCASTS 💬 Аудио версию подкаста можно найти в комментариях

⚙️ В HTTP появился метод QUERY. Пора прощаться с POST /search? У бэкенд-разработчиков много лет был довольно неловкий выбор. Пока фильтров мало, используем GET:

GET /orders?page=2&status=PAID&sort=createdAt,desc

Потом поиск усложняется. Появляются диапазоны дат, группы условий, вложенные фильтры. Query string постепенно превращается в плохо читаемый DSL. Заодно приходится учитывать ограничения на длину URI и то, что адрес запроса может попасть в логи. Обычно в этот момент появляется такой эндпойнт:

POST /orders/search
Content-Type: application/json

{
  "status": ["PAID", "SHIPPED"],
  "createdAt": {
    "from": "2026-06-01",
    "to": "2026-06-30"
  },
  "customer": {
    "country": "NL"
  }
}

Решение рабочее. POST вообще не ограничен созданием ресурсов. Сервер может обрабатывать его тело по собственной семантике. Проблема в другом: на уровне HTTP POST считается потенциально небезопасным и не идмептентным. Прокси, клиенты и другая инфраструктура не знают, что наш /search только читает данные. Такой запрос нельзя автоматически повторять или полноценно кэшировать без дополнительных договоренностей. Передать тело в GET технически возможно. Но RFC 9110 говорит, что у содержимого GET-запроса нет общепринятой семантики. Некоторые серверы и промежуточные узлы могут отклонить такой запрос. Среди причин упоминаются даже атаки класса request smuggling. В июне 2026 года IETF опубликовала RFC 10008 с новым методом QUERY:

QUERY /orders HTTP/1.1
Content-Type: application/json
Accept: application/json

{
  "status": ["PAID", "SHIPPED"],
  "total": {
    "min": 100,
    "max": 1000
  }
}

QUERY предназначен для запросов, описание которых передается в теле. Формат может быть любым, если он обозначен через Content-Type: JSON, SQL, JSONPath или собственный язык фильтрации. Спецификация закрепляет за QUERY три свойства: - safe - клиент не запрашивает изменение состояния целевого ресурса - idempotent - запрос можно безопасно повторить - cacheable - ответ разрешено кэшировать Для кэша есть отдельное правило: ключ должен учитывать тело запроса и связанные с ним метаданные. Поэтому существующие CDN и reverse proxy не начнут кэшировать QUERY сами по себе. Им потребуется поддержка нового метода. QUERY также умеет работать с conditional requests. А сервер может сообщить о допустимых форматах через новый заголовок Accept-Query. 👩‍💻 Что со Spring? В актуальном Spring Framework полноценной поддержки QUERY пока нет. Проблема находится именно на уровне фреймворка: в RequestMethod отсутствует такое значение, поэтому обычный @RequestMapping нельзя привязать к QUERY. Обойти ограничение можно через functional endpoints, собственный HandlerMapping или ручную проверку метода. Для нового стандарта это слишком много самодельной инфраструктуры. Сейчас открыт PR с поддержкой RFC 10008. Команда Spring рассчитывает подготовить ее к Spring Framework 7.1, который ожидается в ноябре 2026 года. Точная версия пока не гарантирована. Так что переписывать все POST /search сегодня рано. Ждем нормальной поддержки в Spring, клиентах и прокси. Потом уже можно будет с чистой совестью бежать менять поисковые POST-запросы на QUERY. RFC 10008: https://www.rfc-editor.org/info/rfc10008/ Spring Framework PR: https://github.com/spring-projects/spring-framework/pull/34993

🔑 Натуральные ключи в БД. Последний раз объясняю! Каждый разработчик хотя бы раз задумывался: "Зачем создавать отдельный ID, если в таблице уже есть уникальное поле? Email, номер паспорта, GAV-координаты — всё это отлично идентифицирует запись, понятно выглядит и даже несёт полезную информацию". Кажется, что натуральный ключ - вполне логичное решение. Но только до тех пор, пока бизнес не просит изменить правила. Вчера поле было уникальным, сегодня - уже нет. А вместе с ним начинает разваливаться всё, что на него завязано. В новой статье разбираем небольшой кейс, где натуральный ключ казался очевидным выбором ровно до одной фразы от бизнеса. Если вы когда-нибудь хотели сделать email или другое бизнес-поле Primary Key, рекомендуем прочитать статью до того, как это решение попадёт в прод. 📎 Подробнее в статье: https://habr.com/ru/companies/spring_aio/articles/1062754/

⚡️ Встроенный DB-клиент в OpenIDE Рады рассказать про новую и очень значительную часть OpenIDE, про которую нас неоднократно спрашивали.

В OpenIDE появился встроенный DB-клиент для работы с базами данных прямо внутри IDE.

Больше не нужно держать рядом DataGrip, DBeaver или pgAdmin — подключились один раз, и дальше работаете с базой там же, где пишете код. В первой версии доступны: – SQL-комплишн по схеме базы: подсказывает таблицы и колонки, ловит опечатки и синтаксические ошибки – Редактирование данных прямо в таблице: сортировка, фильтры, правка ячеек – Экспорт результата в CSV, JSON, SQL и XML – ER-диаграмма схемы базы: таблицы и связи между ними наглядно – EXPLAIN и анализ плана запроса Уже есть поддержка 5 наиболее популярных СУБД: PostgreSQL, MySQL, ClickHouse, SQLite и Oracle. Базовые возможности DB-клиента доступны в OpenIDE абсолютно бесплатно, полноценная поддержка всех 5 СУБД — в OpenIDE Pro.

Друзья, мы в эфире! Ссылки на митап с Aston 😄VK 📱YouTube

🍃 Программистам верить нельзя, JavaScript ломает API, List vs Set в Hibernate | Spring АйО Подкаст №68 😉 СМОТРЕТЬ НА YOUTUBE 😄 Чуть позже... 🥰 СМОТРЕТЬ НА RUTUBE 🗯 СЛУШАТЬ НА ЯНДЕКС.МУЗЫКЕ 🤩 СЛУШАТЬ НА SPOTIFY 🤩 СЛУШАТЬ НА APPLE PODCASTS 💬 Аудио версию подкаста можно найти в комментариях

🍃 Уже завтра! Митап Spring АйО & Aston ⛔️Завтра, 22 июля встречаемся на онлайн-митапе для Java-разработчиков, который проводим вместе с нашими друзьями из Aston В программе три практических доклада:

☑️ «Что не так с вашим Spring AOP? Отвечает Axelix» Михаил Поливаха, технический руководитель проекта Axelix Разберемся, как связаны Spring AOP, проксирование и AspectJ и в каких случаях возможностей Spring уже недостаточно. ☑️ «Превратности DLT: как топик ошибок становится кладбищем бизнес-событий» Евгений Сулейманов, технический директор ProzyTech Обсудим, почему Dead Letter Topic без мониторинга и оповещений может привести к потере важных бизнес-событий. ☑️ «Эволюция ИИ-агентов. Как простой запрос превращается в полноценную архитектуру» Максим Александров, старший разработчик программного обеспечения Aston

📅 22 июля, 18:00 по Москве 📍 Онлайн 🎯 Для специалистов любого уровня 🔗 Регистрация по ссылке

👩‍💻 Что нового в IntelliJ IDEA 2026.2 Несмотря на то, что IntelliJ IDEA уже несколько лет официально недоступна в России, она по-прежнему остаётся одной из самых популярных IDE среди разработчиков. На днях вышла свежая версия 2026.2. В релиз вошли новые инструменты для работы с ИИ-агентами, изменения в отладчике и автоматизация ряда повседневных операций. Также появилась поддержка Java 27, Kotlin 2.4, TypeScript 7, будущего Gradle 10 и обновления для Spring, Terraform и Docker Compose. В статье пройдемся по основным изменениям. 🔗 Полный текст: https://habr.com/ru/companies/spring_aio/articles/1061042/

👩‍💻 Spring Cloud Contract уходит из Spring После почти десяти лет в экосистеме Spring Cloud один из главных инструментов контрактного тестирования переезжает в новый дом. Spring Cloud Contract выходит из портфеля Spring Cloud и продолжит развиваться в организации Stubborn под новым названием - Stubborn Contract. И это не форк, не переписывание с нуля и не попытка начать все заново. Проект остается в руках своего создателя Марцина Гжегорцкого, который развивает его еще со времен Accurest в 2014 году. Что важно для пользователей: - сегодня ничего не сломается. Текущими версиями можно пользоваться дальше; - будущие обновления, исправления и поддержка будут выходить уже в Stubborn Contract; - впереди миграция на новые Maven-координаты; - пакеты переедут с org.springframework.cloud на sh.stubborn; - DSL, Contract Verifier, Stub Runner, HTTP и messaging останутся на месте; - проект сохранит открытый исходный код и лицензию Apache 2.0. Причина переезда довольно резонна: внутри большого портфеля Spring Cloud проект не получал столько внимания, сколько заслуживал. Теперь у него появятся собственная дорожная карта, брокер контрактов и корпоративное финансирование, чтобы развитие больше не зависело от свободных выходных мейнтейнера. Комментарий Михаила Поливаха:

Внутри Broadcom сейчас активно происходит пересмотр портфеля Spring в целом. Например, проект Spring Cloud Data Flow полностью ушёл из Open Source, активно сворачивают поддержку Reactor-а. Марцин же, один из авторов Spring Cloud, покинул команду уже как год, наверное. Посмотрим, что будет с проектом далее. Тем не менее, без активной поддержки сообщества будет непросто.

Spring Cloud Contract заканчивается. Stubborn Contract только начинается

🍃 Spring АйО & Aston ⛔️22 июля встречаемся на онлайн-митапе для Java-разработчиков, который проводим вместе с нашими друзьями из Aston Поговорим о механизмах, которые «вроде бы работают», но требуют точного понимания: Spring AOP, AspectJ, Kafka DLT и архитектуре ИИ-агентов. В программе три практических доклада: ☑️ «Что не так с вашим Spring AOP? Отвечает Axelix» Михаил Поливаха, технический руководитель проекта Axelix

Разберемся, как связаны Spring AOP, проксирование и AspectJ и в каких случаях возможностей Spring уже недостаточно.

☑️ «Превратности DLT: как топик ошибок становится кладбищем бизнес-событий» Евгений Сулейманов, технический директор ProzyTech

Обсудим, почему Dead Letter Topic без мониторинга и оповещений может привести к потере важных бизнес-событий.

☑️ «Эволюция ИИ-агентов. Как простой запрос превращается в полноценную архитектуру» Максим Александров, старший разработчик программного обеспечения Aston

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

📅 22 июля, 18:00 по Москве 📍 Онлайн 🎯 Для специалистов любого уровня 🔗 Регистрация по ссылке До встречи на митапе!

❓ Что вам нужно знать про семантику List и Set в Hibernate Казалось бы, ну коллекция и коллекция. Положил List или Set в entity, и живи спокойно. А потом на проде внезапно появляется пачка странных DELETE/INSERT, транзакция тяжелеет, и кто-то обязательно говорит: «Ну это же Hibernate, он такой». Звучит удобно. Только вот удобство это обычно маскирует другое: вы сами сказали ORM одно, а ожидали совсем другое. Использование List и Set для Hibernate это особый сигнал. И от того, какой сигнал вы подали, зависит и SQL, и то, поедет ли у вас Lazy Loading в самый неподходящий момент. Иногда разница выглядит мелкой, но она крайне важна. Если вы хотите не очередной свод правил «делайте так, потому что так принято», а понять, почему ответ именно такой, заходите. Разберёмся без магии и без списания вины на Hibernate. P.S: Данную статью мы написали по мотивам вопросов, возникших у участников Spring АйО Академии. Спасибо всем тем, кто учавствовал в первом потоке! 📎 Полный текст: https://habr.com/ru/companies/spring_aio/articles/1059922/

🍃 Агенты портят архитектуру, IDE не нужна, Spotify не стал лучше | Spring АйО Подкаст №67 😉 СМОТРЕТЬ НА YOUTUBE 😄 Чуть позже... 🥰 СМОТРЕТЬ НА RUTUBE 🗯 Чуть позже... 🤩 СЛУШАТЬ НА SPOTIFY 🤩 СЛУШАТЬ НА APPLE PODCASTS 💬 Аудио версию подкаста можно найти в комментариях