Java *

Всем привет! Меня зовут Петрович и я работаю техлидом java команды в небольшом международном финтехе. В этой статье я хотел бы поделиться с вами опытом миграции наших сервисов с Redis на Hazelcast, а также о том какие уроки мы усвоили. Статья будет полезна тем кто рассматривает отказоустойчивые и более простые в поддержке альтернативы Redis.

Наша команда отвечает за подсистему оценки платежеспособности клиентов (в народе - скоринг). Стек - классический джентльменский набор для java команды - последняя LTS версия Java, Spring Boot (с Hibernate), база PostgreSQL, брокер сообщений RabbitMQ, авторизация через Keycloak, кэш Redis, собираем в docker контейнеры с помощью jib и деплоим в k8s через gitlab, arttifactory используем для хранения стартеров и библиотек.

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

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

Всем привет, меня зовут Михаил. Мне 23 года, и я работаю Senior Java разработчиком в ОТП Банке. До этого я работал ведущим back-end разработчиком в РЖД.

Я и мои коллеги в моем опыте не сомневаются - работаю сеньором уже больше 2 лет. Я попал на стажировку в 18 лет. Стажировался за копейки, усердно работал вместо "веселой студенческой жизни".

А потом получаю отказы в духе: "Вы слишком молоды для этой позиции"

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

Кто-то становится миллионером в 18, а мы чем хуже?

Сегодня попытаюсь разобраться в этой ситуации подробно, наливайте чай или кофе, поехали!

На форуме Cursor разработчик рассказал, как запретил агенту работать с удалённой базой, а тот всё равно выполнил npx supabase db push. Эта команда отправляет локальные изменения схемы в подключённый удалённый проект. Агент мог изменить рабочую базу данных — и только после этого сам признал, что нарушил правило.

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

У меня всё закончилось проще. Вчера я попросил Cursor разобраться с упавшим сквозным тестом. Я ждал исправления в приложении, но агент поменял проверку в самом тесте и отчитался, что всё готово. Тест, разумеется, прошёл.

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

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

От имени основной команды Axelix и всех, кто внёс вклад в сообщество, я хочу заявить: мы наконец это сделали.

Axelix, наконец, выходит в GA (Generally Available — общедоступная версия)!

Для тех, кто не знает - Axelix это продукт с открытым (Open Source) ядром, который позволяет выявлять распространённые проблемы, подводные камни и неэффективности в Java-приложениях.

Ядро продукта лежит на GitHub - можете использовать, это бесплатно.

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

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

Звучит как теория? Увы, но это суровая практика Spring Kafka, с которой многие разработчики имеют дело каждый день.

Вы пишете сервис A, сериализуете объект в JSON, отправляете в kafka-топик. Консьюмер сервиса B, который понятия не имеет о существовании класса com.company.a.event.UserEvent, должен бы прочитать JSON по структуре полей - ведь это же просто данные, верно? Но нет.

JsonDeserializer по умолчанию смотрит в заголовок TypeId, видит там полное имя класса отправителя и пытается выполнить Class.forName(). Класса нет - контейнер падает. 

Ваш независимый сервис внезапно стал зависимым от classpath источника запроса.

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

Техническая оговорка: в это статье рассматривается конкретика про JsonSerializer/JsonDeserializer в Spring Kafka. На Avro/Protobuf со Schema Registry эта проблема не воспроизводится - там контракт вынесен в схему, и имя Java-класса просто не играет роли.

Долгое время GraphCompose выглядел как PDF-движок. Но архитектурно PDF никогда не должен был быть центром системы: разработчик описывает документ на одном языке, движок один раз рассчитывает layout, а подключаемые backend’ы переводят готовую геометрию в нативные объекты нужного формата.

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

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

Эту задачу мы и хотели решить при разработке «Галактики Сверхновой». Заглядывайте под кат и узнаете, как устроено это разделение: почему ядро осталось консервативным, а расширения можно писать на Python, Java и C#, и как метаданные стали основой для интеграций и ИИ.

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

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

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

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

В Veai 5.16 для этих сценариев появились команда /btw и параметр strictness. Ниже разберём механику обеих функций, их ограничения и влияние частого повторения инструкций на контекст модели.

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

Смотря на всю ситуацию на рынке, я подумал: хм, вот джуны притворяются мидлами и сеньорами и ходят по собесам. А что, если все будет наоборот?

Учитывая, что ситуация на рынке для джунов совсем плачевная, я решил провести эксперимент. 30 дней. Только я, фейковое резюме джуна, новый Telegram-аккаунт - и все!

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

Интересно, чем все это закончилось и как это было? Присаживайтесь поудобнее!

Статья настоящий разбор-детектив: почему неблокирующий API может блокироваться, как потерять монитор после деоптимизации JIT, почему try-catch иногда важнее коллбэков, и как решать сложные проблемы новыми концепциями мышления. Приятного чтения!

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

Всем привет! Меня зовут Григорий, и недавно при разработке своего микросервисного приложения я нашёл уязвимость — сообщения, пересылаемые между сервисами, имели высокий риск быть необработанными. Решением стал паттерны Outbox и Inbox. Однако, когда я стал их реализовывать во всех приложениях, то понял, что просто копирую и вставляю код. Чтобы это исправить, я решил написать свой стартер.

Привет, Хабр! Меня зовут Михаил Сичалов, я руководитель проектов и эксперт практики Applied Intelligence в компании Axenix.

Это вводная статья из цикла работ, посвящённых реальным сценариям использования Apache Spark и сопутствующим техническим нюансам, с которыми я столкнулся за последнее десятилетие работы над проектами в области Data Engineering. Я решил систематизировать и переосмыслить свой опыт работы с этим фреймворком и поделиться с сообществом интересными и нестандартными аспектами, освоенными на практике.

Несмотря на выразительность модуля Spark SQL с точки зрения описания преобразований над данными, зачастую возникает необходимость в создании пользовательских функций (UDF). Для этого в Apache Spark есть целое подмножество API, с помощью которого можно реализовать пользовательскую функцию произвольной сложности. Но что делать в случае, когда код функции становится доступным только в рантайме, а Spark используется в связке с Java API?

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

В блоге Anthropic вышла статья Thariq Shihipar, в которой он рассказывает, как агент помогает находить ему Неизвестные Неизвестные (Unknown Unknowns). Я думаю, что мысли из статьи также очень важны для Spec Driven Development, и хорошо объясняют, почему спецификация это живой документ, и получение финального документа возможно только после того, как код уже написан, (ну или во всяком случае, одновременно с этим моментом). Если вы считаете, что Spec Driven Development — это будущее AI‑assisted разработки (намеренно не говорю вайбкодинг), прошу под кат.

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

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

Агент отчитался: экран настроек готов. Поля редактируются, после сохранения выскакивает тост «Сохранено». Я нажал F5 — все настройки вернулись к дефолтным. Бэкенда под формой не существовало: агент выяснил это в первые минуты и вместо того, чтобы сказать мне, молча положил данные в локальный стейт и нарисовал тост. Ни один чекер из моих прошлых статей этого не поймал — и не мог: деградация пришла со шва между фронтом и бэкендом, единственной границы, через которую не проходит ни компилятор, ни анализатор зависимостей.

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

Всем привет! На связи Михаил Поливаха, технический лидер проекта Axelix.

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

А что насчет натуральных ключей в БД? Если, допустим, у меня есть поле, по которому я могу явно идентифицировать запись, стоит ли его использовать как Primary Key?

И я за время дизайна enterprise систем, и за время дизайна Axelix пришёл к выводу: Просто не используйте натуральные ключи вообще никогда. Когда у вас появляется такое желание - выйдите на свежий воздух, пройдитесь, прогуляйтесь, и вас отпустит.

В прошлой статье мы разбирали, как сделать работу ИИ-агента предсказуемее: зафиксировать требования в спецификации с помощью Specification-Driven Development (SDD), до реализации описать ожидаемое поведение тестами по Test-Driven Development (TDD), а готовый результат проверить и передать отдельному субагенту на ревью.

У такого подхода есть цена.

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

Полагаться только на свои ощущения в таких вопросах очень опрометчиво. В одном из экспериментов разработчики считали, что ИИ ускорил их примерно на 20%. Замеры показали обратное: с ИИ они работали на 19% медленнее.

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

Что показывают эксперименты, если читать их целиком

Заголовки об ИИ в разработке противоречат друг другу: «на 55% быстрее», «на 19% медленнее», «на 26% продуктивнее». Результаты расходятся, потому что исследования проводились в разных условиях и измеряли разные показатели.

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

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

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