Как же строить системы определения доступа не вокруг конкретных действий, а экономической модели платформы? Как легко переусложнить то, что переусложнять априори не стоит? Где заканчивается гибкость и начинается ад поддержки?

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

Несколько лет я мечтал поработать на Kotlin. Мне это удалось - был большой проект РЖД, я вкатился, писал код, радовался. Kotlin мне правда понравился.

Но давление менеджеров, нереальные сроки и просто выгорание вынудило меня выходить на рынок, и я пошёл искать работу… и тут меня ждал сюрприз. Вакансий, где нужен чисто Kotlin, в России - единицы. А те, что есть, чаще ищут Java/Kotlin с упором на первую.

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

Поехали!

Три года назад я писал свой первый коммерческий парсер на ANTLR4 — для бизнес-формул аналитической системы. Несколько лет спустя я бы сделал его иначе в трёх центральных местах. Разбираю каждое: левая рекурсия для приоритета операторов, Listener vs Visitor, и почему getText() для повторного парсинга — антипаттерн.

Я расскажу, как реализовать локального LLM "Agent".

«Что вы получите:
— LLM, который индексирует ваш код и отвечает по контексту
— Генерацию и автоматическую вставку кода / тестов
— Полную работу без интернета и утечек данных
Показываю на примере IntelliJ IDEA, Ollama и Continue.»

Всем привет! Недавно столкнулся с проблемой, что в настоящее время большая часть обучающих материалов по Retrieval‑Augmented Generation (RAG) сосредоточена на Python‑экосистеме (LangChain, LlamaIndex и тому подобное), а пошаговые руководства, которые показывают, как быстро собрать рабочее RAG‑приложение на чистом Java‑стеке, встречаются крайне редко. Эта статья представляет собой простое практическое руководство, где мы разберём весь процесс от настройки окружения до полного примера кода, чтобы даже начинающий Java‑разработчик мог развернуть RAG.

У тех, кто впервые столкнулся с Java-разработкой в последние пять лет, могло сложиться впечатление, что Spring всегда был доминирующим фреймворком, а сам язык предназначен для разработки backend в web-приложениях. Однако пока web-приложения были проще, специализация frontend-разработчика не была такой очевидной, интерфейс обновляли на сервере, а Java поддерживала ряд фреймворков, управляющих динамической HTML-версткой.

Эти фреймворки до сих пор живут в легаси, которое проще поддерживать, чем переписать. Они могут требовать обновлений, когда у регуляторов возникают новые требования или меняется корпоративный стиль оформления интерфейса. А если фреймворк живёт, то к нему желательно иметь подходящий инструмент. Поэтому сегодня мы расскажем сразу про четыре инструмента в GigaIDE PRO, поддерживающие уже не столь трендовые, но достаточно распространённые в среде «кровавого энтерпрайза» фреймворки.

 Начнём наш обзор с рассказа про поддержку самых «древних».

Я Java-разработчик: пишу на Java 5 лет. Последний месяц собираю портфолио через Spec-Driven Development — связку Spec Kit и Claude Code. Первый проект — Telegram-бот для задач. С шести вечера до двух ночи одного вторника я прошёл полный SDD-цикл от конституции до MVP с шестью командами. Восемь часов. Один вечер. Рабочий продукт. Но главное — что-то сдвинулось в моём инженерном процессе.

В статье рассмотрим кто сегодня выигрывает битву за бэкенд: сравнение синтаксиса, разбор производительности, а главное — честный прогноз на 2-3 года. Если выбираете стек для нового проекта или думаете, учить ли Kotlin вдогонку к Java, — эта статья для вас!

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

Рассмотрим модель данных application model, которая потребуется в дальнейшем изложении и которая используется в паттерне CQRS.

Реализация архитектурного паттерна CQRS, используемого в приложении для функционала application logic, представляет собой набор классов наследников базовых классов QueryHandler / CommandHandler и набор классов данных, которые являются наследниками базовых классов Query / Command. Классы наследники Query / Command представляют собой модель данных application logic. Такую модель данных логично назвать application model.

Используя application model и другие известные модели данных слоёв приложения можно построить полную схему моделей данных многослойной архитектуры приложения.

Apache JMeter — не просто инструмент. В этой статье разберем, как получать от него реальную пользу. Вы узнаете, почему 80% отчётов о нагрузке бесполезны, как настроить распределённый тест и анализировать не среднее значение, а процентили. Полный гайд от первого HTTPS-скрипта до информативного HTML-отчёта и Best Practices.

Продолжаем серию «Kotlin для новичков». Сегодня разбираем фундамент, без которого не обходится ни одно приложение: строки и коллекции. Как правильно резать подстроки, форматировать JSON, чем List отличается от MutableList и зачем enum в Kotlin круче, чем в Java. Заглядывайте, будет полезно!

Представьте: сервис А звонит сервису Б, а тот зависает. Сервис А ждёт, занимает потоки, не освобождает ресурсы. Потом к нему приходит другой сервис — и тоже встаёт в очередь. Так один сбой разрастается по всей системе, как снежный ком. Этот эффект называется каскадным отказом.

Паттерн Circuit Breaker (предохранитель) решает эту проблему. В статье разбираем его на примере ассистента HR с зонтиком, показываем, как настроить Resilience4j, и делимся, какие ошибки стоит (а какие не стоит) учитывать в статистике.

 Описание

Паттерн Circuit Breaker (предохранитель) занимает важное место среди паттернов архитектуры приложений, особенно в микросервисных системах.

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

Проблема распространяется и умножается на всю систему. У сервиса А занимается всё больше потоков, которые ничего не делают, а просто ждут. Если будут заняты все потоки, сервис А станет полностью неработоспособен. Так проблема разрастается по цепочке — этот эффект называется каскадным отказом (cascading failure).

Чтобы решить проблему, сервис А должен иметь защитный механизм, который определяет, что сервис Б сейчас в аварийном состоянии, и временно не обращаться к нему. Этот механизм и называется Circuit Breaker (предохранитель).
 

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

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

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

«Talk is cheap. Show me the code.»

Недавно мне в руки попала книга «Искусство неизменяемой архитектуры: теория и практика управления данными в распределенных системах». В ней описаны довольно радикальные, но логичные подходы к проектированию: полный отказ от UPDATE и DELETE в пользу INSERT, идентификация сущностей через хеш-суммы и построение распределенных систем без боли.

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

В этой статье разберем, как выглядит REST-сервис на Kotlin + Spring Boot, живущий по законам неизменяемости, и к каким результатам это привело.

Это текстовая версия доклада с Java Rock Star Meetup, с которым выступал Александр Ланцов — ведущий разработчик Мир Plat.Form. Если вы больше любите смотреть видео, то смотрите запись доклада на YouTube или VK Видео.

Всем привет! Меня зовут Евгений Оселедец, я ведущий разработчик в компании Axenix. В этой статье расскажу, как мы упаковали React и Java в единое автономное desktop-приложение с помощью Electron для Windows, Linux и macOS — без Docker, без предустановленной Java у пользователя и без необходимости интернет-соединения. Расскажу, с какими техническими вызовами мы столкнулись и какие решения сработали на практике.

Привет, Хабр! Я Юрий Дергач, я возглавляю ЦК DevOps и релизного управления в РСХБ. Мы с командой развиваем инфраструктуру и автоматизируем разработку продуктов компании. При внедрении наших проектов группы «Экосистема Свое», основанных на стеке Java Spring, в Kubernetes, возникли вопросы, связанные с различными методами балансировки нагрузки между микросервисами.

В этой статье мы обсудим два основных подхода к балансировке нагрузки между Backend-компонентами приложений на стеке Java Spring Cloud в Kubernetes. Мы также рассмотрим преимущества и недостатки каждого метода.

Вы слышали о Kafka, MQTT, S3, Iceberg, Trino, PostgreSQL, Redis и Flink? А насколько хорошо вы знаете эти технологии? По каждой из них написаны огромные книги («Kafka: The Definitive Guide», около 800 страниц), и каждый день выходят новые публикации про тонкости.

Эта статья про другое.

Вместо внутренностей движков и законов распределённых систем посмотрим на эти технологии как на кубики LEGO: какую роль каждая из них играет в архитектуре и как они стыкуются друг с другом. Это будет практический туториал: начнём с минимальной конфигурации и постепенно соберём сложную систему. Статью можно просто читать как обзор архитектуры, а можно запускать каждую конфигурацию и изучать её в деталях. Для этого достаточно Git, Git LFS и Docker Compose. Всё запускается в контейнерах. Даже примеры на Java собираются через Docker multi-stage build.

Привет Хабр! Меня зовут Артур Валиев, и я разработчик небольшого мобильного приложения с названием «Echo Layer».

Меня давно не отпускала одна мысль: почти все разговоры о приватной переписке в какой‑то момент упираются не в шифрование, не в криптографию, не в архитектуру, а в банальную человеческую инерцию. Можно сколько угодно строить красивую систему, можно делать open source, end‑to‑end encryption, писать про zero knowledge и отсутствие серверных логов, но потом ты возвращаешься в реальную жизнь и видишь, что люди всё равно сидят там, где им удобно. В Telegram, в WhatsApp, в VK, сейчас уже и MAX, в корпоративных чатах, в почте, в комментариях, где угодно. И если для приватности нужно сначала всех пересадить в новое приложение, то задача почти обречена.

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

Так Echo Layer и появился. Не как «новый безопасный чат», а как попытка превратить сам ввод текста в место, где может жить приватность.

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

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

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

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

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

Разберем всё по шагам, с замерами производительности. Поехали!

Playwright или Selenium на Java — что выбрать для автотестов в 2026 году? Разбираю историю инструментов, различия в локаторах, ожиданиях, стабильности, стоимости поддержки и объясняю, в каких сценариях каждый из них лучше.

Привет, Хабр! Меня зовут Даша Александрова, я Java‑разработчик. Хочу поделиться опытом миграции данных из Oracle в PostgreSQL без простоя сервисов.

Причина миграции — импортозамещение.

Теперь немного про сам проект. В его основе — микросервисная архитектура на Java 11/17 и Spring Boot 2/3. В качестве основной базы данных использовалась Oracle с несколькими схемами. В коде сочетаются нативные SQL‑запросы и Hibernate, вся бизнес‑логика живет на уровне приложения — без процедур, триггеров и другой логики в базе. Идентификаторы генерируются через sequence. Проект активно развивается, регулярно выпускаются релизы. Система ориентирована на клиентские приложения — мобильное и веб, при этом нагрузка остается умеренной и не относится к highload‑сценариям.

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

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

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

Рефакторинг должен быть скучный и надежный. Надо держаться от искушения обновить библиотеку, починить баг, улучшить стиль. Под катом разбор почему именно такой путь сможет вытянуть тяжелый legacy рефакторинг, а шаг вправо и влево ведет к откату релиза.

Всем привет! Меня зовут Александр, и сегодня я расскажу о результатах перевода учебного проекта со Spring WebFlux и Netty на Spring MVC и Tomcat с виртуальными потоками и проверки обоих вариантов под нагрузкой в 2000rps. В качестве подопытного будет выступать система микросервисов, разработанная в рамках курса CloudJava.

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

Почему инженеры хотят делать новое, а неделя уходит на сопровождение, алерты и переключение контекстов? Поводом для этой статьи стали два материала, которые неожиданно сошлись в одной точке: доклад Романа Елизарова про опыт разработчика и отчет Chainguard Engineering Reality Report 2026. Мы сопоставили взгляд сильного практика и международные данные, чтобы понять, куда на самом деле утекает внимание инженерных команд и почему DX сегодня — это уже не про удобство, а про экономику внимания.

GitHub, GitLab или Bitbucket — куда податься начинающему разработчику в 2026? Казалось бы, какая разница — Git везде одинаковый. Но когда дело доходит до первого пет-проекта, портфолио или стартапа на троих, выбор платформы решает всё: от скорости сборки до шансов быть замеченным рекрутером.

В этой статье — сравнение лимитов, цен и скрытых фич. Разберём реальные сценарии, таблицу с актуальными данными на апрель 2026.

Что делать, если синхронные REST-вызовы превращают ваши микросервисы в карточный домик? Пора вспомнить проверенные временем паттерны обмена сообщениями. В этой статье разбираем архитектуру Pipes and Filters, Content-Based Router и Idempotent Receiver — те самые кирпичики, на которых держатся надёжные системы. Схемы, best practices для проектирования устойчивых интеграций для Enterprise-разработки.

Вот уже 18 лет статический анализатор кода PVS-Studio находится на рынке. За это время он обзавёлся поддержкой языков C, C++, C# и Java. Разумеется, останавливаться на этих языках мы не планируем, и в этой статье расскажем про разработку нового JavaScript/TypeScript анализатора, который выйдет уже совсем скоро.

Проблема фундаментальная: system prompt — это инструкция, которую LLM старается выполнить, но не обязан. Модель может её переинтерпретировать, «забыть» при длинном контексте или просто обойти через специальные конструкции. Guardrails — это другой уровень: они работают на уровне кода, до и после вызова LLM, и модель физически не может их обойти.

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

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

А также:
▫️ Почему фраза «создайте мне систему» — это красный флаг.
▫️ Как постепенное уточнение спасает от «аналитического паралича» и переписывания кода.
▫️ User Story vs Use Case: в чём настоящая разница и что выбрать.
▫️ Схемы итеративного процесса и ролей в Agile-проекте.

Девятый выпуск еженедельных IT-новостей от OpenIDE.

Милла Йовович выложила свой проект в open-source, Claude Code нашел баг в Linux, которому 23 года, Anthropic показали Claude Mythos и сразу закрыли доступ.

А Skill Caveman внезапно оказался самым простым и самым эффективным инструментом недели.

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

Однако, если ты опытный специалист и постоянно используешь стримы в своей работе, возможно даже для тебя будет изюминка, ради которой тебе стоит прочитать статью. Я подпишу блок для тебя как ИЗЮМИНКА 

Захотелось рассмотреть важную тему Stream API, но чтобы сделать статью интереснее, я решил сравнить его с инструментами реактивного программирования — Flux и Mono из Project Reactor.

Начнём с того, что такое Stream и в чём его схожесть с Flux.

Если серьезно, то сегодня мы поговорим про БАЗЫ данных. Как-то один мой друг разработчик сказал, что программирование можно понимать как

Продолжая тему инструментов, интегрированных в среду разработки, сегодня мы рассмотрим клиент для работы с базами данных, доступный пользователям GigaIDE. Для пользователей Community-версии доступен open source-плагин DB Navigator, который хорошо описан, например, здесь. Пользователям PRO-версии доступна пара расширений:

SQL — синтаксическая поддержка и форматирование SQL-кода;

Database — клиент баз данных с широким набором возможностей.

Я работаю программистом 15 лет. За это время чего я только не делал и у меня скопилась статистика. Если на первом месте я работал 5 лет на втором 3 года, то на последующих год полтора и я выгорал и менял работу. Я не мог понять почему так происходило. Только в одной фирме мне действительно нравилось работать. Хотя когда я там работал мне тоже хотелось в определенный моменты уйти, но все же сейчас я вспоминаю коллег и проекты с теплотой.

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

Данная статья является переводом анонса Гевина Кингa о релизе первого milestone JPA 4 спецификации и общего вектора развития JPA.

Полноценная 4-ая версия JPA спецификации должна выйти чуть-чуть позже в этом году. Тем не менее, то, что сейчас в Milestone это основа, которая, возможно, с небольшими доработками, но уже пойдёт в релиз в этом году.

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

P.S: У нас в рамках Spring АйО Академии как раз есть программа посвящённая Hibernate. В ней мы тоже затронем новую версию спецификации, в частности и работу со StatelessSession и EntityAgent на практике. Я думаю, что из всего апдейта, именно стандартизация работы без Persistence Context будет самым важным для прикладных разработчиков. Остальное тоже важно, но не так как работа с EntityAgent.

Приятного чтения!