Вот и закончился февраль, за который в GigaIDE появилось ещё больше полезного. Ниже — краткий обзор обновлений PRO-функциональности GigaIDE, которую можно найти в нашем маркетплейсе. Обзор инкремента за январь доступен по ссылке.
Уже вышла Java 25 — самая свежая версия, которую все хотят попробовать. Но ставить ли её новичку? Или взять проверенную Java 21 LTS? В этом гайде — пошаговая установка Java на Windows с картинками, разбор различий между версиями, настройка JAVA_HOME и PATH ориентирован для начинающих разработчиков, изучающих Java
Почему одни системы всегда показывают актуальные данные, а другие — иногда отдают устаревшее, но зато хорошо масштабируются и показывают хорошие показатели по производительности?
В новом переводе от команды Spring АйО разберем, что такое модель согласованности как контракт между процессом и системой, какие бывают сильные и слабые гарантии и как они связаны с производительностью и доступностью.
Замечали некий companion object в интерфейсах Hilt-модулей? Что он делает, как он работает под капотом, почему так популярен в Hilt-модулях, и почему нельзя обойтись обычными классами? Сегодня я развею эту магию!
Если вы думаете, что навигационная система в современном автомобиле — это просто красивое приложение, которое рисует синюю линию на карте и говорит «через 200 метров поверните направо», вы застряли в 2010 году.
В Android Automotive OS (AAOS) навигация часто становится одним из самых жирных и критически важных системных компонентов. Это «пространственный мозг» машины. Десятки других модулей постоянно дергают её за рукав с вопросами: «Где мы?», «Какое ограничение скорости?», «Сколько полос на дороге?», «В какой полосе мы сейчас едем?».
В этой статье я поделюсь опытом из своей практики разработки навигационной системы для крупного немецкого автопроизводителя. Мы разберем, как построить надежное межпроцессное взаимодействие (IPC) внутри автомобиля на примере передачи ADAS-атрибутов для японского модуля ETC 2.0.
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 – генерировать бинарники с хирургической точностью.
Приготовьтесь! Мы начинаем оптимизировать!
