Java *

Продолжаем разбирать HikariCP: как выбирать размер пула, что учитывать в Kubernetes и при нескольких сервисах, почему большой maximumPoolSize не всегда помогает, какие настройки стоит пересмотреть перед продом и какие ошибки чаще всего приводят к проблемам с базой.

Привет. Меня зовут Николай Пискунов, я руководитель направления Big Data и эксперт курса Cloud DevSecOps по безопасной разработке от Академии вАЙТИ Beeline Cloud. Сегодня я хочу поделиться историей создания одного интересного проекта — клиента для облачного сервиса Ollama.

Хотите увидеть, как живое Spring Boot‑приложение проходит путь от репозитория до кластера Kubernetes? В статье пройдем путь от создания простого HealthController до автоматического деплоя через CI/CD. Разберём Dockerfile без магии, манифесты Deployment с пробами, настройку ресурсов и изящный Graceful Shutdown. В финале вы получите живую связку «код — контейнер — кластер», готовую к продакшену.

HikariCP давно стал де-факто стандартом JDBC connection pooling в JVM-проектах. Но подключить его мало: важно правильно выбрать размер пула, таймауты, maxLifetime, keepaliveTime, leak detection и метрики.

Разбираем, как настроить HikariCP для Java, Kotlin, Scala и Spring Boot, какие ошибки чаще всего встречаются в проде и почему maximumPoolSize нельзя просто копировать из соседнего сервиса.

Вы наверняка видели такой код - for (String s : data) { result += s; } сотни раз.

Что с ним не так?

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

И казалось бы, проблема конкатенации строк в Java давно решена. Джунам говорят: используй StringBuilder и будет тебе щастье. А статьи десятилетней давности сравнивают + и append() в бенчмарках и ставят точку.

В сегодняшней статье я копнул немного глубже и оказалось, что реальность сложнее.

Вред не исчез - он принял новые, менее очевидные формы.

Иногда перед разработчиком встает задача воссоздания некоторого окружения локально. В него часто входят различные компоненты инфраструктуры, такие как:

– PostgreSQL

– Kafka

– RabbitMQ

– Redis

И так далее. Менеджить целый зоопарк таких сервисов локально бывает не очень удобно. К счастью, у команды Spring Boot для вас есть небольшой помошник - Spring Boot Docker Compose.

Комментарий от Михаила Поливахи:

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

Почему Kubernetes стал стандартом оркестрации контейнеров? Разбираем архитектуру без скучной теории: Control Plane, поды, сервисы, деплойменты — на реальных примерах. Вы узнаете, как избежать типичных ошибок, увидите опыт миграции Tinder и получите лучшие практики, которые применяют ведущие команды. Статья для тех, кто хочет не просто знать команды kubectl, а понимать, как проектировать отказоустойчивые платформы

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

Для реализации выбран абстрактный бизнес-процесс запроса абстрактных ресурсов. Пример придуман максимально общим. Необходимо реализовать обработку бизнес-процесса с несколькими стадиями.

Всем привет! Хочу рассказать, как мы проектировали кэш поиска отелей и почему за полтора года прошли путь от Infinispan к managed Redis а затем к Postgres. По стеку java-21, spring-boot-3, 1 вендор отелей, расчетная нагрузка 1000 RPS и 10M запросов в сутки.

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

Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом.

В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза “end-to-end encryption”? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства?

Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger.

Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои.

Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать.

В статье расскажу, как работает E2EE изнутри: как устанавливается сессия через X3DH, как каждое сообщение получает отдельный ключ через Symmetric Ratchet, почему сервер хранит только зашифрованные конверты, и какие ошибки я допустил по дороге.

Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.

Моки — достаточно крутой инструмент, если использовать его правильно.

И все-таки лично для меня писать и поддерживать тесты на моках всегда было отдельным видом боли. Думаю, все знакомы с ситуацией: добавил в метод новый аргумент — и пошёл в 30 тест-кейсов проставлять заглушки. И это только от одного нового аргумента.

И я не буду здесь спорить о терминологии — в этой статье я буду называть все тестовые дублёры «моками». Примеры будут на Scala, но моки в других языках работают похожим образом, так что боль универсальная. Как и решение — об этом в статье.

TL;DR

Я сделал библиотеку для генерации PDF на Java, в которой:

Документ описывается семантически (модули, секции, параграфы, таблицы, слои), а не через moveTo/lineTo/showText.

Layout и рендер — это два разных прохода. Геометрия резолвится один раз, потом её рисуют. Поэтому документ можно тестировать до того, как написан хотя бы один байт PDF.

Под капотом — ECS-архитектура в стиле игровых движков: Entity / Component / System. Сущности документа лежат в EntityManager, компоненты прицепляются и снимаются, системы (LayoutSystem, PaginationSystem, RenderingSystem) работают над ними.

Тестирование трёхуровневое: unit → layout-снапшоты (как у Jest для React) → визуальная регрессия по PNG-диффу.

На простом инвойсе библиотека идёт 2.45 мс (iText 5 — 1.57 мс, JasperReports — 4.45 мс). На стресс-тесте: 50 потоков, 5000 документов, 0 ошибок, ~2000 doc/sec.

Это статья про задумку и инженерные решения, которые получились нетривиальными. Если вам интересно, как декларативный UI, ECS и снапшот-тесты влезают в одну библиотеку для PDF — заходите.

Сегодня я хочу вам рассказать интересную историю из своей жизни про аутстафф. Когда я только начинал карьеру, я попал на стажировку в одну аутстафф-компанию. Проходил я ее 3 месяца, и после успешного завершения спустя месяц попал на проект... мидлом с 4 годами опыта.

Эта статья - про ад и слезы. Про реальный опыт.

Сейчас есть люди, которые без опыта ставят себе 3-4 года и идут покорять горы, думая, что все это очень легко. Конечно, в мое время еще не было ChatGPT, AI-агентов и всего такого (говорю прям как дед), было сложнее. Но дело не в инструментах, а в желании и стремлении. А еще в умении не сломаться, когда на тебя орут, ты ничего не понимаешь, а заказчик думает, что ты мидл с 4 годами опыта.

Сейчас я расскажу, как я не сломался. Хотя был близко. Очень близко.

Поехали!

Python уже не просто язык для скриптов и Data Science — в 2026 году он стал «клеем», который связывает микросервисы, тесты и CI/CD в Java‑проектах. Как получилось, что даже консервативные Java‑разработчики всё чаще пишут интеграционные тесты на pytest, запускают контейнеры с Testcontainers и рулят пайплайнами в GitHub Actions с помощью Python‑скриптов?

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

В этой статье мы продолжаем обсуждать инструменты в GigaIDE. Напомню, что ранее мы уже рассказывали про наши инструменты для работы с Docker/Podman, файловым SFTP-источником в этой статье, а также с клиентом БД — в этой. Сегодня мы сосредоточимся на инструментах для Java-разработки. Первый плагин в обзоре — Profiler, задача которого состоит в том, чтобы автоматизировать профилирование и визуализацию отчётов, и WildFly, задача которого выполнять подготовку, развёртывание и запуск, и решать другие задачи в отношении серверов приложений WildFly или JBoss.

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

Старый код редко лежит бесплатно. Даже если его никто не вызывает, он попадает в поиск, ревью, CI, локальный запуск и голову каждому новому разработчику. Разбираю на примерах: DTO, endpoint’ы, которые «скорее всего не используются», deprecated events, конфиг-поля, Docker/CI-хвосты и продуктовые фичи «на будущее».

Вообще‑то, я бэкендер последние лет 20, но недавно остался без работы (и AI тут не причём), решил «замутить» свой «стартап», пока ищу новую работу Java‑программиста. А заодно подтянуть новые технологии, поглубже изучить немецкий и английский и немного развеяться…

Писать приложения под iOS было моим хобби последние лет 10, и пару моих приложений до сих пор постоянно висят в топе в Российском AppStore, но это были всё «игрушки», а захотелось сделать что‑то взаправду стоящее, и так возникла идея написать лучшее (ни больше ни меньше) приложение для изучения языков с помощью аудирования. Точнее, товарищ подсказал идею. А ещё точнее — идея давно была реализована под Андроид, но аналогов под iOS нет, а очень хотелось. И мне, и товарищу:). Да и смартфона с андроидом у меня нет и никогда не было, не судите строго, но не люблю я вирусы и глюки.

Идея следующая: берёте любое аудио на любом нужном вам языке, загружаете в приложение, и оно автоматически (можно так же вручную) разбивает аудиофайл на нужные вам сегменты для «шэдоуинга», аудирования, многократного прослушивания и тому подобного. Аналогов в сторе я не нашёл, точнее, что‑то отдалённо похожее там есть, но без своих настроек, без выбора своего контента для изучения, без красивой визуализации аудио, короче, без всего того, что нам бы хотелось иметь.

Итак, идея есть, какие технологии использовать? В старых моих приложениях был UIKit, Realm/CoreData, и, сториборды. Не судите строго, я как бэкэндер тогда не знал, что использование сторибордов среди «трушных» айосников считается плохим тоном и плохой приметой. Но теперь‑то я решил использовать современные технологии! И выбрал такой стэк: SwiftUI, SwiftData, Speech Framework. Что касается последнего, то он вроде бы доступен ещё с iOS 10, но я решил, что технологии развиваются, и распознавание текста из аудио должно было бы сделать со времени iOS 10 огромный рывок вперёд. Но теперь я не так сильно в этом уверен, и об этом эта моя маленькая статья…

Фича-тоглы: мир удобства без лишней настройки

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

В новой версии платформы Инкоманд появился No Code инструмент «Инкоманд Объекты», позволяющий создавать структуры данных и управлять ими без написания кода — Object Definition’ы, поля, связи, представления, права доступа настраиваются через UI. Но данные не всегда рождаются и живут в самой системе. На практике объекты часто находятся в смежных системах, и задача разработчика — не дублировать их, а организовать бесшовный доступ.

В этой статье я расскажу, как мы реализовали такое решение с помощью механизма Proxy Object Storage, и с какими проблемами пришлось столкнуться на пути интеграции Инкоманд с Microsoft Graph API.