Java *

В первой статье я писал про SDD на примере одного вечера. После чего прошёл 17 спринтов SDD на FullStack‑приложении: B2C‑трекер привычек и целей, два репозитория, 251 тест на бэке и 77 на фронте, релиз в продакшен. Здесь — что не дало мне потерять контроль на этом масштабе.

Тема разграничения доступности действий в рамках конкретного тенанта выходит далеко за рамки ERP домена и требует особо пристальной реализации. Это особенно применимо для коммерческих систем (коей и является Kroncl - название системы), в которых классический RBAC требует определённых доработок, включающих адаптацию к упрощённой features-based access control (в народе - FBAC, является своего рода реализацией ABAC). Кроме того, технологические компании крайне редко (уникальные случаи всё же есть) посвящают публичные статьи внутреннему устройству своих систем тарификации, что крайне печально, ведь это буквально могли быть рассказы о том, как архитектурные решения напрямую влияют на маркетинг и как следствие доходность компании.

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

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

Несколько лет я мечтал поработать на 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, и делимся, какие ошибки стоит (а какие не стоит) учитывать в статистике.
 

Один экран в приложении, а на бэкенде несколько 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.

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

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

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