Java *

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

Java Telegram API обманывает разработчиков дубликатами запросов при отключении интернета?

Мы команда разработки телеграмм ботов, которая смогла придумать решение для работы с дубликатами в Statefull командах Telegram API используя REST. Прошли путь от наивного решения до работающего продукта.

Статья о том как Я начал разработку собственной Idea и чуть не бросил 2 раза эту затею. Как я выбрал неподходящий готовый пакет редактора кода, и начал разработку своего снова.

Привет, Хабр!

Меня зовут Михаил Поливаха. Я думаю, что в Хабе Spring АйО меня уже относительно знают. В рамках Spring АйО мы довольно часто занимаемся подбором технического материала и его ревью. Сам же я довольно регулярно выступаю на конференциях, контрибьючу в Open Source и т.д.

Также, часто наши материалы крутятся вокруг Java разработки и конечно же Spring-а. И данной пост, хоть и будет с одной стороны сильно связан с Java и Spring Framework, но, тем не менее, не похож на остальные.

На днях произошло довольно знаковое событие. Мы с небольшой командой примерно год писали инструмент, который призван существенно упростить весь процесс отладки, тестирования и мониторинга Spring Boot приложений в production. И вот этот проект наконец-то получил первый Milestone Релиз.

Проект называется Axelix.

Представьте: ваш сервис Y генерирует 10 000 событий в секунду, а сервис X может проглотить только 500. И при этом нельзя потерять ни одного события, а порядок обработки обязан быть строгим. Очередь? Конечно. Но какую? И что делать, когда она переполнится?

В статье — разбираем реальную архитектурную задачу с разбором типовых ошибок, двух подходов к порядку (strict FIFO и per‑key ordering), нюансами DLQ, backpressure, идемпотентностью и скрытыми проблемами типа head‑of‑line blocking.

Откуда берётся «среднее приложение с GitHub»? Если попросить агента создать JPA‑сущность или настроить Spring Security, то он выдаст вполне рабочий код. Вопрос только в одном: для какого проекта?

Модели натренированы на миллионах репозиториев: студенческие работы, всех задолбавшая Petclinic, туториалы с YouTube, у меня кстати, есть куча своих:D.

Но без чёткого контекста агент выдаёт типичное «среднее приложение с GitHub»: всё синтаксически верно, но далеко не всегда вписывается в существующий РЕАЛЬНЫЙ проект. С Lombok или без него? Используя @IdClass или @EmbeddedId? Предпочитаешь Record'ы или классические классы? Как у тебя маппятся DTO? Агент этого не знает и чаще всего либо пытается угадать, либо начинает грепать всё что можно и нельзя.

Prompt engineering помогает, но ненадолго. Прикреплять каждый раз примеры сущностей и архитектурные правила — прошлый век. Интеграция в IDE с @ и выбором файлов уже лучше, но всё равно надо постоянно об этом помнить и как РОБОТ писать ему одно и тоже.

Всем привет! Меня зовут Петя Портнов, я работаю в Ozon ведущим разработчиком в команде среднего поиска — слоя, который ранжирует поисковую выдачу.

Представьте, что вы вводите запрос в поисковую строку маркетплейса. За этим простым действием скрывается сложный поисковый пайплайн: миллионы товаров фильтруются, ранжируются и сортируются по релевантности. Но как именно система решает, что показать первым? В основе этого решения лежат вычисления, среди которых — сотни разнообразных формул, учитывающих цену, рейтинг, популярность, персонализацию и другие факторы. По мере развития системы таких формул становится всё больше, а сами они усложняются. В какой-то момент вычисления превращаются в узкое место: начинают потреблять значительную долю CPU, создают множество промежуточных объектов — и так для каждого поискового запроса. Возникает вопрос: как снизить стоимость таких вычислений в JVM?

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

Микросервисы обещают масштабирование и независимость команд, но чаще ломают систему медленнее монолита. Почему?

В статье разбираем семь архитектурных ошибок, которые можно встретить в реальных системах: выбор по моде, shared database, игнорирование network latency, операционная сложность на потом, слишком мелкая декомпозиция, отсутствие стратегии consistency, недооценка сроков миграции.

Оказывается, документация Claude Code рассказывает не всё. Стоило только лишь заглянуть в исходники. И вот что можно настроить, но чего нет в доке:

— hooks, которые переписывают команды на лету;
— автоодобрение safe-команд без лишних подтверждений;
— постоянная память агентов между сессиями;
— auto-mode, который понимает описание окружения на обычном английском;
— самообучающиеся циклы памяти и «снов»;
— скрытые поля skills, agents и permissions, которых нет в документации.

И все это работает уже сейчас, а исходники Claude Code лежат у вас в node_modules. Мы собрали все в статью. Там больше конкретики, JSON-конфигов, shell-хуков и примеров, которые можно утащить себе почти без правок.

Профилирование Java‑приложений в production часто упирается не в отсутствие инструментов, а в их ограничения: CPU горит в одном месте, latency копится в другом, аллокации давят на GC, а lock contention вообще не виден в обычном CPU‑профиле.

В статье разбираем, как использовать async‑profiler для диагностики реальных Java‑сервисов: снимать CPU, allocation, wall‑clock и lock‑профили, читать flame graph и понимать, где именно приложение тратит ресурсы.

Как-то раз на одном из программистских форумов я наткнулся на интересную задачку. Интересна она была тем, что требовалось рекурсивное решение на Java. Мне захотелось разобраться…

Cursor, Copilot и другие AI‑инструменты обещают быстро закрыть рутину с unit‑тестами: сгенерировать кейсы, расставить моки, добавить ассерты и поднять покрытие. Но зелёные тесты ещё не означают, что код защищён от регрессий.

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

Каждый, кто программирует с агентами (Claude Code, Codex и т.д.), знает: перед тем как приступить к задаче, агент исследует проект. Это кажется логичным, естественным и закономерным, ведь люди делают так же. Обычно говорят: «агент наполняет контекст».

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

- задача определена в общем виде (кто знает, что имел в виду автор)
- пути исследования не детерминированы (в общем виде не используется специфика фреймворка)
- используются базовые инструменты (read, grep, cat, find)

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

В Anthropic быстро осознали эту проблему и вынесли всю описанную работу в Explore sub-agent. В результате основной agent ставит задачу промптом, Explore выбирает путь исследования, а результат формирует в виде отчета. Проблему чистоты основного контекста они, конечно, решили. Но что с качеством такого анализа?

Наблюдая за работой Explore и видя, как агент, используя «примитивные» инструменты, в агонии пытаясь отыскать недостающее или, наоборот, пропускает важные сведения о проекте, невольно ловишь себя на мысли: «Как так вышло, что последние 10 лет развития индустрии инструментов прошли мимо agent?» А может, это человечество свернуло не туда?

Привет, Хабр! Меня зовут Александр, я Java-разработчик в GlowByte. Работаю в практике управления рисками и комплаенс (Risk & Compliance). Хочу поделиться своим опытом и в целом рассказать о том, чем мы здесь занимаемся. А занимаемся мы автоматизацией систем управления рисками – от AML (противодействие легализации доходов) и операционных рисков до коллекшна (взыскание просроченной задолженности) и систем принятия решений.

Моё направление – как раз последнее: системы принятия решений (СПР). Если коротко, мы автоматизируем стратегии, где нужно в реальном времени перерабатывать кучу входных параметров, учитывать множество факторов и выдавать сложные, комплексные решения. Типичные примеры: оценка риска, предстраховые проверки, системы мониторинга, расчет резервов, расчет комиссионных вознаграждений страховым агентам и многое другое.

Чем это интересно? На выходе – не просто «да/нет», а полноценное управляемое бизнес-правило, которое можно быстро менять без переписывания кода.

В этой статье хочу поделиться опытом разработки backend API на Spring Boot-проекте, где нам пришлось много работать с OpenAPI-спецификацией, динамическими запросами и тестированием бизнес-логики.

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

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

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

Системный аналитик пишет User Story, рисует BPMN, описывает API — а через месяц архитектор перекраивает всё, потому что «это не ложится на DDD». Знакомо?

В этой статье я показываю пошаговый маршрут, как аналитику самому спроектировать доменную модель и перенести её в Java‑код. Разбираю на реальном кейсе: Event Storming, выделение ограниченных контекстов, построение агрегатов с инвариантами и асинхронное взаимодействие через интеграционные события.

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

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

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

Почему классический разбор SAST-находок — это боль

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

Открыть указанный в отчете файл

Обнаружить там какую-нибудь generic-функцию, которая принимает строку и склеивает SQL-запрос

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

Разобраться, была ли где-то по дороге валидация или экранирование

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

Меня зовут Игорь Симаков, работаю engineering manager’ом и руковожу командами разработки

На одном из наших сервисов, который работает с XLSX-файлами, прилетел production-алерт на высокое потребление памяти. Стандартный P3, обычно решается рестартом. Пошёл смотреть поды и нашёл проблему, к памяти отношения не имеющую, но представляющую больший риск, чем сам алерт. Об этом и расскажу ниже: чем «утечка диска» отличается от «утечки памяти», как мы наткнулись на грабли в Apache POI и как закрыли их на уровне архитектуры

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

- Конкатенация строк в циклах

- String.format() в горячем коде

- Автобоксинг 

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

Если вы пишете на Java и у вас всё вроде работает, но под нагрузкой сервисы начинают задыхаться, в новом переводе от команды Spring АйО рассмотрим конкретные паттерны, на которые стоит посмотреть.