Kotlin уже не просто язык для Android. В 2026 году на нём пишут бэкенд, кроссплатформенные приложения и даже заменяют Java. Почему команды уходят с Java на Kotlin, как новичку начать и при чём тут Kotlin Multiplatform? Разбираемся и пишем «Hello, World!» с Gradle. Бонус: пример кода и ссылка на репозиторий.
Головоломка Ханойские башни (или Ханойская башня, или Towers of Hanoi) – классический пример задачи, в которой лучшее и самое наглядное решение основывается на рекурсии. Кроме того, эта задача иногда встречается на собеседованиях. Тем удивительнее, что последняя статья (хотя и весьма обстоятельная), посвященная этой задаче на Хабре датируется 2013-м годом и решение приводится на Delphi. Давайте исправим эту печальную ситуацию!
Мы привыкли обсуждать микросервисную архитектуру с точки зрения границ сервисов, ответственности команд, масштабируемости и отказоустойчивости. Мы спорим о том, как правильно нарезать домен, где провести границы и какие сервисы должны взаимодействовать напрямую.
Но есть более фундаментальный вопрос - кто в системе определяет правила игры?
В реальных финтех-системах бизнес-логика часто начинает зависеть от того, как именно разложены микросервисы. Допустимость действий формируется не в одном месте, а распределяется по цепочке:
- часть проверок живeт во фронтенде
- часть - в API,
- часть - в промежуточных сервисах
- часть — во временных проверках, добавленных после инцидентов
Добавили новый сервис в цепочку - и изменилось поведение.
Вынесли проверку в отдельный процессинг - и появились состояние гонки.
Перестроили оркестрацию - и неожиданно стала недоступной операция, которая раньше работала.
В этот момент происходит архитектурный перекос - не бизнес-процесс определяет систему, а структура сервисов начинает определять поведение процесса.
Для финтеха это особенно критично. Допустимость действия - это не просто проверка прав. Это функция состояния процесса, версии правил, контекста операции и регуляторных ограничений. Если эта допустимость зависит от связности сервисов или порядка их вызова, система становится хрупкой и уязвимой, и тогда, начинается разговор о подходе, в котором бизнес-логика централизуется, версионируется и становится инвариантной к физической архитектуре.
Мы отвлекаем существенные ресурсы в поисках решения для проблем.
Как выбрать коллекцию в Java, чтобы код летал? Разбираем алгоритмическую сложность (Big O) самых популярных структур: ArrayList, LinkedList, HashSet, HashMap. В конце — схемы выбора и лучшие практики от команд. Сохраняйте, чтобы не забыть!
Вечером в пятницу коллега, назовем его Мститель, спросил, не сталкивался ли я с проблемой, что route возвращает 400... но «если сменить название на сильно другое», то всё ок. Я сперва не обратил внимание на слово «сильно». Может быть, где-то дублируется регистрация этого рута? Или мститель перепутал GET и POST. Или какой-то баг в общем на создание хэндлеров?
Почти 800 тестов, 10 минут на прогон, каждый пуш — ожидание на CI. Знакомо? Рассказываю, как довёл время до 101 секунды: снижение таймаутов, параллелизм ScalaTest, shared Testcontainers и защита от регрессий. Scala, SBT, PostgreSQL, GraalVM — конкретные шаги и подводные камни.
Когда я только начинал свой путь в автоматизации, мне отчаянно не хватало толкового и структурированного материала по паттернам проектирования именно для автотестов. Хороших статей про паттерны в целом — вагон, а вот с привязкой к тестированию — днём с огнём не сыщешь.
Паттерны — это та вещь, которая моментально выдает уровень культуры кода и понимание инженерных практик. Неудивительно, что на собеседованиях на позицию Automation QA любят покопаться в этой теме.
В этой статье я решил закрыть этот пробел. Вы найдете не только продуманную классификацию основных паттернов автоматизации, но и самый подробный, на мой взгляд, разбор каждого из них с примерами. А в конце поговорим про антипаттерны.
Добро пожаловать в обсуждение! Буду рад конструктивной критике и дополнениям.
Сегодня мы живём в мире распределённых систем: Apache Kafka, Apache Spark, Apache Cassandra — это уже не экзотика, а повседневная инфраструктура продакшена.
Сервисы пишут события, стримы обрабатываются в реальном времени, данные реплицируются по датацентрам. И почти в каждом таком сценарии возникает фундаментальный вопрос:
Как понять, что произошло раньше, а что позже, если глобального времени не существует?
Здесь в игру вступают логические часы Лампорта — простая, но концептуально мощная идея, лежащая в основе причинно-следственного порядка в распределённых системах.
Подробнее - в новом переводе от команды Spring АйО.
Монолит тормозит, бизнес требует новых отчётов, а каждая правка ломает всё вокруг? Знакомо! В этой статье рассматриваются примеры внедрения CQRS и Event Sourcing. разбираются практики разделения команд и запросов, построение асинхронной архитектуры на Kafka. Под катом — код, Mermaid-схемы и best practices, которые реально работают.
В статье «Пример описания многослойной архитектуры, основанной на использовании наборов подслоёв и иерархии моделей данных» рассмотрен подход к построению многослойной архитектуры приложения с использованием трёх слоёв и девяти подслоёв.
Использование такого набора взаимодействующих между собой слоёв и подслоёв даёт возможность максимально детально описать структуру функционала приложения. Продолжая далее этот подход можно детализировать каким именно функционалом наполняются подслои приложения и для наполнения подслоёв использовать архитектурные блоки. Под архитектурным блоком далее будет пониматься типовой функционал определённого подслоя приложения.
Анализируя типовой функционал приложения можно выделить 9 основных архитектурных блоков.
В позапрошлом году вышла статья https://habr.com/ru/articles/814529/ про синхронизацию позиции персонажа между клиентом и сервером в Lineage 2. После прочтения появилось желание перенести эту логику в свои сырцы от когда-то разрабатываемого сервера и, возможно, запустить его где-то для себя и старых друзей поразвлекаться. Понятное дело, что современного ПК с кучей рам, хорошим процом и nvme дисками при желании было бы за глаза даже для запуска тысяч игроков, но заниматься организацией доступа из дикого интернета на свой ПК желания не было, да и обеспечивать постоянный доступ - дело такое себе. В наличии была самая дешманная впска у хостера F с доменом, но с сильно ограниченными ресурсами: одно ядро и 512Мб рам. Мягко скажем, памяти маловато.
Наспех восстановил сырцы, актуализировал сборку под современные версии java и либ, запустил - потребление хипа примерно 400Мб на старте. Без геодаты. А с геодатой - 1200Мб.
И тут появился спортивный интерес влезть в 512Мб, да еще и с геодатой.
Результатом стал оптимизированный драйвер геодаты, зашаренный на гитхабе https://github.com/mosinnik/l2-geo, репорт о потенциальном баге в JDK и эта статья.
В статье показано, как сократить boilerplate код при создании Minecraft модов с помощью фреймворка под названием Temporal API...
Параллельные стримы в Java 8 выглядят как бесплатное ускорение: добавил .parallel() — и все ядра побежали работать. Но по факту всё сложнее, так как распараллеливание имеет накладные расходы, зависит от того, насколько хорошо делится источник данных, сколько стоит объединение результатов, и даже от локальности данных в памяти.
В новом переводе от команды Spring АйО на примерах и бенчмарках разберем, почему простая свёртка на маленьких диапазонах может стать медленнее, почему ArrayList часто выигрывает у LinkedList в параллели, как reduce может неожиданно сломаться из-за неверного identity, и что вообще происходит внутри common ForkJoinPool.
Когда начинается разговор про Java, почти всегда он внезапно уходит в сторону Spring. И это не случайность.
Проблемы с релизами, поддержкой, миграциями, безопасностью — это не «проблемы Spring». Это следствие того, как изменилась сама Java-экосистема.
Чтобы понять, что происходит со Spring, нужно сначала разобраться, что произошло с Java.
Почему ваша Java-система буксует там, где должна летать? Мы привыкли доверять магии JVM, но в мире Java 21 и Native Image правила игры изменились. От микро-оптимизаций байт-кода до радикальной смены парадигмы с Scoped Values – разбираем 11 “золотых правил”, которые заставят JIT петь, а ваш бинарник – стартовать за миллисекунды. Никакой “воды”, только хардкор, регистры процессора и “голоса” компиляторов внутри вашего кода.
Работая с кодом, я не раз ловил азарт: а как этот метод можно ускорить ещё? Какую гайку подкрутить, чтобы JVM не просто работала, а буквально летела? Что изменить в архитектуре, чтобы Native Image стал ещё компактнее, а холодный старт – ещё быстрее?
Испытав этот азарт оптимизации не раз, я хочу поделиться им с вами. Я собрал квинтэссенцию своего опыта в конкретный чек-лист.
Это не просто советы по стилю кода. Это “10+1 Золотых правил оптимизации Java 21+”.
Это те рычаги, которые заставляют JIT-компилятор петь, а GraalVM – генерировать бинарники с хирургической точностью.
Приготовьтесь! Мы начинаем оптимизировать!
Когда я впервые увидел, как мой сервис на Spring Boot с Postgres, MongoDB и Kafka «съел» всего 45 МБ оперативной памяти, я почувствовал азарт. Азарт инженера, который нашёл способ обмануть систему. Я был заряжен Axiom NIK: его эффективностью, его агрессивной компиляцией и тем, как он превращает «жирный» корпоративный стек в изящный бинарник.
Многие годы нам вдалбивали: «Java — это прожорливо!». Нам говорили: «Выдели 2 ГБ под микросервис, иначе JIT не прогреется».
Забудьте об этом! Я провёл R&D, который ставит точку в спорах о прожорливости Java!
Это не просто тесты. Это вскрытие!
JWT — это архитектурное решение, которое меняет то, как сервисы доверяют друг другу. В статье разбираем, почему крупные проекты перешли с серверных сессий на JWT, как устроена его криптография под капотом, и в каких случаях JWT может подвести.
Состоялся релиз OpenIDE 2025.3 на базе IntelliJ IDEA Platform 2025.3. В релизе — поддержка Java 25, автодополнение действий IDE через двойную точку (Command Completion), Spring MCP для LLM-агентов, обновления для Go и фронтенд-стека, улучшения HTTP-клиента Connekt и доработки Docker-плагина.
В свежем релизе Veai 5.5 (плагин к IntelliJ IDEA со своим AI агентом для написания кода, тестирования и отладки) работа с агентом становится более управляемой, безопасной и расширяемой. SKILLs — это полноценная поддержка открытого стандарта навыков: их можно хранить в проекте, переиспользовать между задачами и инструментами, и агент будет подключать их автоматически.
Добавлены новые режимы агента Plan и Review. Auto Review — для быстрых проверок сгенерированных изменений, Edit Scope — для ограничения области редактирования, а также возможность создавать свои режимы агентов под конкретные роли и сценарии. Для персональных пользователей добавлена поддержка Claude 4.6 Opus.
JDBC — технология, которую каждый Java-разработчик учил на курсах, но мало кто применяет правильно. В этой статье расскажу о лучших практиках работы с базами данных из Java-приложений, которые обеспечивают максимальную производительность в продакшене.
