Java *

Hibernate 7.4 исправляет старую проблему с пагинацией и fetch join.

Раньше запрос на первые 10 Order вместе с OrderItem не мог безопасно ограничиться на уровне SQL. Из-за join один заказ превращался в несколько строк, и limit мог обрезать коллекцию. Поэтому Hibernate загружал все подходящие строки, а страницу выбирал уже в памяти. На больших данных это било по памяти и могло закончиться OutOfMemoryException.

Теперь Hibernate сначала выбирает нужные id родительских сущностей во вложенном запросе, а затем загружает для них полные дочерние коллекции. Пагинация остается в БД, данные не режутся.

Еще в 7.4 появились history и audit tables. @Temporal хранит версии строк и позволяет читать сущность на конкретный момент времени. @Audited пишет изменения ADD/MOD/DEL в audit-таблицу без Envers.

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

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

Digital Q.AppServer как раз закрывает эту задачу: платформа дает единый интерфейс для работы с серверами приложений Digital Q.TomEE и Digital Q.WildFly и собирает в одном месте основные операции сопровождения. В центре внимания здесь – уже не сам по себе выбор между серверами, а то, что ими можно управлять как частью одного эксплуатационного процесса, а не как набором разрозненных систем.

Один вопрос на собесе — три ответа.

«Что такое индекс?» спрашивают и джуна, и сеньора. Вопрос один — меняется глубина. По ней и считывают грейд.

Разобрал 8 таких вопросов. По каждому:
🟢 Junior — что это
🟡 Middle — как работает и где ломается
🔴 Senior — что будет в проде и чем платим

И где на самом деле проходит граница мидл/сеньор (спойлер: не там, где думаешь).

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

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

Привет, Хабр. Я Полина, продакт и главный редактор медиа-платформы «Своё Вино» от Россельхозбанка. Помните, не так давно мы говорили с вами о том, что общего у вина и ИТ? На платформе «Своё вино» мы с редакцией обычно говорим о терруарах, стилях и винтажах, но в этот раз попробуем применить ту же оптику к языкам программирования. Попробуем угадать язык по пяти строкам кода и заодно понять, по каким «ароматам» и «танинам» наш мозг так быстро их различает.

Бывает надо заглянуть внутрь JVM.
Увидеть CPU, ядра, потоки, а чаще heapMemory - но у тебя ничего для этого нет.
Ни Prometheus, ни других систем мониторинга. Ещё не настроено окружение.

Иногда может помочь и Endpoint с MXBean-ами.

Реверс-инжиниринг MAX: Архитектура телеметрии и фоновой эксфильтрации в «защищённом» мессенджере

что скрывает «гос-мессенджер» MAX? Мы провели глубокий статический анализ APK и вскрыли промышленный конвейер сбора данных. Внутри: полное отсутствие E2EE, ежедневный аудит разрешений (камера/микрофон/GPS), скрытое сканирование всех установленных приложений и фоновая выгрузка файлов на сторонние серверы с последующей зачисткой следов на устройстве. Разбираем пакеты, классы и методы, которые превращают мессенджер в систему направленного наблюдения.

Про безопасные миграции написано уже тысячу раз. Мы все наизусть знаем и про expand/contract, и про обратную совместимость, и про то, что схему нельзя ломать под трафиком. А потом всё равно наступаем на эти грабли.

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

Дальше расскажу, как так вышло

Разберемся, как на самом деле устроена интеграция Flyway в Spring Boot 4: что изменилось с появлением отдельного starter’а, как Boot прокидывает настройки и почему в связке с PostgreSQL одна неочевидная опция может намертво зависнуть миграцию

90% code coverage выглядит как повод выдохнуть — до первого бага, который спокойно проходит сквозь все тесты и добирается до прода. В статье разберём, почему покрытие строк создаёт ложное чувство надёжности, чем branch coverage полезнее и как мутационное тестирование показывает реальные дыры в тестовом наборе.

Это первая из двух статей про построение AI-агента внутри Джеймикс-приложения. Джеймикс (или Jmix, ex. CUBA) - высокоуровневый фреймворк для разработки корпоративных приложений на Java, автор не будет слишком сильно в него погружаться, в наше время любой запрос к AI даст Вам всю нужную информацию. В этой части мы соберем минимальный, но рабочий пример: пользователь задает вопрос на естественном языке, агент решает, какие операции вызвать на бэкенде, дергает их и возвращает осмысленный ответ. В качестве предметной области возьмем склад - сценарий, узнаваемый для большинства бизнес-приложений и достаточно широкий, чтобы во второй части обсудить уже не только чтение, но и запись данных, безопасность, fetch plans и метаданные.

Зачем это вообще нужно? Данные корпоративного приложения живут за списками и формами с фильтрами. Это отлично работает, когда пользователь знает, по каким полям фильтровать - и плохо для размытых, многокритериальных вопросов вроде "где у нас заканчивается кофе тёмной обжарки по северным складам?". Когда иначе пришлось бы открыть несколько экранов и руками свести результаты, AI-агент даёт возможность просто спросить - и собирает ответ из бэкенд-операций, которые у вас уже есть.

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

Привет, Хабр! В прошлых статьях я описала, как через нововведенный параметр TSI теоретически можно определить грейд разработчика.

Привет, Друзья!

Хотел написать короткий пост по мотивам одного казалось бы простого ПР-а, который мы недавно получили в рамках Axelix: Open Core продукта для решения основных известных болей при разработке Spring Boot приложений (кстати, give us a star!).

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

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

Давайте с места в карьер. Посмотрите на этот код:

Посмотрим на Kilua — новый Kotlin-фреймворк для web-frontend. Честно о том: где радует, где мешает, и почему один вопрос всё равно остается открытым

Всем привет, меня зовут Михаил, я работаю главным экспертом в ОТП Банке.

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

В какой-то момент я сказал себе: «Стоп. Хватит. Пора уходить в компанию, где всё организовано правильно». Мне казалось, что там не будет хаоса, бессмысленных авралов и вечной гонки за дедлайнами.

Ну что могу сказать - я попал.

Только вот ожидания и реальность оказались совершенно разными.

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

Она умерла в воскресенье вечером, и никто не услышал ни звука. Детективная история о том, как поставить прослушку на собственное приложение: Prometheus, Grafana, Micrometer, алерты, SLO. Все улики в комплекте, демо-проект прилагается. Совпадения с вашим продакшеном не случайны.

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

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

Для этого в Veai 5.12 появился General Agent. Он принимает задачу в том виде, в каком разработчик обычно ее формулирует: неидеально, с сомнениями и неполным пониманием пути. Агент сам подбирает нужные действия и отдает результат, который уже можно проверить.

Попробовать Veai 5.12 · Что входит в релиз

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

Привет. Меня зовут Николай Пискунов, я руководитель направления Big Data и эксперт курса Cloud DevSecOps по безопасной разработке от Академии вАЙТИ Beeline Cloud. Продолжаю цикл статей о клиенте для облачного сервиса Ollama. В первой части я рассказал, как родился этот клиент, с какими трудностями пришлось столкнуться при организации стриминга, и даже оставил пасхалку.

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

Именно это третье состояние и создаёт самый неприятный класс проблем. И именно о нём — эта статья.

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