Java *

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

Каждый сервис будет иметь свою логику, свою ответственность. Сервисы одной системы могут быть написаны на разных языках программирования. Однако это не будет мешать им общаться. Так вот общение это буквально - обмен информацией. Обмен сообщениями определенного формата, который смогут понять все сервисы. Это похоже на общение между нами. Я говорю что-то собеседник слушает информацию, дальше обрабатывает ее неким образом своим мыслительным аппаратом и формирует ответное сообщение и проговаривает его вслух адресуя голос в направлении оппонента. Для отправки сообщения нам людям, нужно знать адресата или видеть его, для того, чтобы обратиться к нему.

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

Если ты разработчик, то тебя это коснется. Спустя какое то время, кто-то раньше, кто-то позже, но каждый приходит к тому, что пора реально взять и разобраться в многопоточке. Я как то писал статью для себя, когда готовился к собесам и понял, что мне самому очень вкатывает такой формат обучения, когда ты пишешь статью на тему, которую исследуешь изучаешь. Так информация осваивается в разы лучше. Поэтому я собираюсь пропустить через себя огромный объем информации по многопоточности. Буду работать как супер компьютер обрабатывать сразу все возможные ветки в направлении освоения многопоточности. 

Стандартные алгоритмы даунсемплинга хорошо работают с линейными графиками. На scatter они теряют до 60% визуально значимых данных. Показываем, как двумерное прореживание решает задачу, которую одномерные методы фундаментально не могут.

Java 26 вышла 18 марта. В релизе 10 JEP-ов: Structured Concurrency получила шестое превью и API наконец стабилизировался, final-поля начинают путь к настоящей иммутабельности, G1 и ZGC получили улучшения производительности, примитивы заработали в паттернах, а HTTP/3 вошёл в стандартный HttpClient финальной фичей.

Разбираем каждое из изменений и смотрим, как перевести реальный проект на Java 26.

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

Сначала мне казалось, что рассказывать о таких «подвигах» не слишком интересно. Все любят истории об успешном успехе. Потом я вспомнил: главное — не итог, а путь, опыт и знания, которые ты получаешь по дороге. Как только я начал смотреть на материал как на обучающий, делиться им стало намного проще.

Бывает так: с какой то технологией уже разобрался, а вот перейти к новой боязно. Учить новые движки непросто, да и текущий инструмент уже не справляется с задумкой… Сомнения часто мешают двигаться вперёд, но народная мудрость «глаза боятся, а руки делают» никогда не подводит.

В итоге я решился и попробовал FXGL для 3D‑рендеринга. Но не для того, чтобы сделать полноценную игру(хотя она и получилась), а чтобы соединить расчёты по системному моделированию с элементами геймификации. Уточню: я не призываю использовать FXGL во всех случаях. Для серьёзных 3D‑проектов есть отличные инструменты — Unigine, jMonkeyEngine, Godot, Unreal Engine. Я попытался собрать и упорядочить знания, которые получил в ходе своего небольшого эксперимента.

Последние годы FeignClient и RestTemplate были де-факто стандартом для вызова внешних API в Spring. Но теперь появился нативный Http Interface Client — и я решил проверить, можно ли им заменить Feign без потери удобства.

Скорее всего читатели знают, но контекста ради.
Flink имеет децентрализованный дизайн с распределенной архитектурой, где набор контейнеров ( Task Manager ) несут ответственность за свою локальную зону или не несут?
Эта зона в случае разбиения через keyBy размазывается исходя из хэша заданного ключа, посредством чего, Flink гарантирует попадание всех событий с этим ключом на тот же контейнер и также гарантирует сохранение того порядка событий, в котором они доехали до оператора, и, как следствие этот контейнер является мастером-владельцем ключа - отсюда понятие локальной зоны становится оправданным, ведь все хэш пространство размазывается на контейнеры равномерно. Однако, если не использовать keyBy и просто попробовать вызвать что угодно, то будет round-robin распределение и тогда снимается понятие локальной зоны ответственности.

Переводим нашу платформу с JSON на Apache Avro и Schema Registry. Заменяем сериализаторы и десериализаторы, генерируем классы из схем и разбираем разницу между GenericRecord и SpecificRecord.

Практика на реальном проекте.

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

В новом переводе от команды Spring АйО рассмотрим утечки памяти в Java.

Не секрет, что GC освобождает только недостижимые объекты. Утечка в Java начинается там, где объект уже не нужен, но на него все еще есть цепочка ссылок от живого потока.

Симптомы обычно одинаковые: куча растет, GC срабатывает чаще, паузы увеличиваются, финал - java.lang.OutOfMemoryError: Java heap space.

В целом вывод такой, что нужно смотреть график heap в VisualVM/JVisualVM/JConsole, снимать heap dump (jmap), в Eclipse MAT запускать Leak Suspects и проверять цепочки удерживающих ссылок.

Выбирать стиль интеграции приложений — всё равно что выбирать фундамент для дома. Ошибёшься — и переделывать придётся, когда стены уже стоят.

В этой статье я разбираю четыре основных стиля интеграции: передача файлов, общая база данных, удалённый вызов процедур (RPC) и асинхронный обмен сообщениями (Messaging). Без воды, на реальных примерах — включая историю провала TSB Bank, который стоил сотен миллионов фунтов.

Вы узнаете:

▪️ почему общая база данных — это антипаттерн для микросервисов;
▪️ как асинхронность спасает прод, когда падают соседние сервисы;
▪️ какие best practice используют команды, чтобы не получить распределённый монолит.

Если вы архитектор, тимлид или разработчик, который хочет строить надёжные системы — добро пожаловать под кат.

Когда мы проектировали пайплайн автоматического заполнения EMR по итогам видеоконсультаций, исходная гипотеза была простой: Jitsi Meet — open source, документация есть, значит, подключить бота и получить транскрипт — задача на пару дней. На практике именно этот слой занял непропорционально много времени относительно своей "очевидности".

В этой статье разберу, как устроена транскрипция в Jitsi Meet под капотом, почему это не "просто включить кнопку", с какими конфигурационными нюансами пришлось столкнуться и как в итоге был выстроен пайплайн от видеозвонка до структурированного текста.

Мы, разработчики на Java, используем параметризованные типы каждый день: List<String>, Map<Long, User>, Optional<Order> и так далее. Однако у параметризованных типов есть важная особенность: в Java они существуют в полном виде только на этапе компиляции.

Продолжаем серию «Kotlin для новичков»!

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

В этом туториале вы узнаете:

▪️ Как объявлять функции и чем это отличается от Java.
▪️ Что такое именованные аргументы и значения по умолчанию (и почему это круто).
▪️ Как работает стек вызовов и области видимости.
▪️ Главные best practices, которые используют в разработке.

Многие команды продолжают использовать приложения на платформе CUBA, которые хорошо работают и ежедневно решают реальные бизнес‑задачи. Но со временем неизбежным становится вопрос: стоит ли продолжать поддерживать приложение на старом стеке или лучше перенести его на Jmix?

В этой статье я хочу показать, как такая миграция выглядит на практике. Мы перенесли приложение‑пример Timesheets с CUBA Platform на Jmix и записали процесс шаг за шагом. Timesheets — это не маленькое демо с несколькими сущностями и CRUD‑экранами. Это приложение для учета рабочего времени с согласованиями, несколькими способами ввода времени, кастомным UI‑поведением, календарем, диаграммами и немалым объемом бизнес‑логики.

Одним вечером я решил проверить: что если взять решётку из 10 000 узлов, задать одно правило передачи энергии между соседями — и просто запустить? Никакой теоретической физики из учебника, никакой подготовки. Посмотреть что вырастет само.

Спойлер: за один день появились волновое уравнение, интерференция, фазовый переход, рождение и аннигиляция частиц, и стрела времени. Всё из одного уравнения.

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

Дебаг, запуск проекта и рефакторинг. Все мы хорошо знакомы с этими фичами IDE и пользуемся ими практически каждый день. Но передовые ИИ-агенты для кодинга почему-то абсолютно ничего не знали про эту “базу” до релиза Veai 5.8 🙂 (ИИ-агент к JetBrains IDEs для написания кода, тестирования и отладки с доступом к топовым LLM и всем внутренним инструментам IDE).

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

Как я собрал мультиканального voice-бота на Spring Boot, который объединяет Discord, Telegram и веб-панель в одной системе.

Разбираю архитектуру, работу с голосом (TTS, запись каналов), интеграцию JDA + LavaPlayer и реальные проблемы продакшена — от memory leaks до ограничений Telegram API.

Закончился еще один месяц, а значит нам пора поделиться с Вами новостями о развитии GigaIDE. Ниже краткий обзор обновлений PRO-функционала GigaIDE, которые можно найти на нашем маркетплейсе. Обзор инкремента за февраль доступен по данной ссылке.