Приглашаем на Java Jam — бесплатный митап ЮMoney для Java-разработчиков 🔥

Спикеры из ЮMoney и главный эксперт по технологиям Сбера расскажут о своём опыте и пообщаются с аудиторией.

Вот какие темы будут на митапе:

🟣 Как мы уменьшали нагрузку на базы данных в очередях задач. Расскажем, как реализовать надёжное асинхронное и отложенное исполнение задач.
🟣 Советы по производительному коду. Поговорим про время выполнения программ, работу со строками и коллекциями, вещественную и битовую арифметику, алгоритмические трюки и многое другое.
🟣 Уязвимости не пройдут. Обсудим, как повысить безопасность разработки с помощью SAST и SCA.

25 сентября, в четверг, в 18:30 (мск) — приходите на митап в Санкт-Петербурге или подключайтесь онлайн.

Зарегистрируйтесь, чтобы принять участие. Все подробности — на сайте митапа Java Jam™️

Как опытный Java-разработчик/бэкенд-инженер, ты должен разбираться в отказоустойчивости и паттерне Circuit Breaker. Вот сценарий ненадёжного платёжного шлюза 💳 , чтобы проверить знания кандидата:

Сценарий:

Твоё приложение интегрируется со сторонним платёжным API. При пиковых нагрузках этот API стабильно даёт сбой примерно в 2% запросов. Это приводит к неудачным оплатам и ухудшает пользовательский опыт.

Вопрос:

Как ты спроектируешь интеграцию так, чтобы она была устойчива к этим сбоям и при этом сохраняла хороший UX? Объясни, какие именно паттерны (например, Circuit Breaker или Retry с экспоненциальной задержкой) ты бы применил и почему. Как бы ты обработал возможные дубликаты транзакций, возникающие из-за повторных запросов?

→ Что я оцениваю:

Понимание паттернов устойчивости и отказоустойчивости. Кандидат должен уметь объяснить такие концепции, как повторные запросы, Circuit Breaker (например, с использованием Resilience4j), fallback-механизмы, а также критическую важность идемпотентности при проектировании интеграций с платёжными системами.

В примере показано как реализовать Resilience4j с fallback-методом в Spring Boot

👉 Java Portal

Да можно уже заранее на Java 29 😈

👉 Java Portal

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

Как это исправить?

Вот как:

Spring AOP (аспектно-ориентированное программирование) позволяет отделить сквозные задачи —> логирование, транзакции, безопасность от бизнес-логики.

Aspect = задача/область заботы
Advice = действие (@Before, @AfterReturning, @AfterThrowing, @After, @Around)
Pointcut = место применения

Spring AOP использует прокси-базированное runtime-вплетение (JDK-прокси или CGLIB), чтобы перехватывать вызовы методов на Spring-бинах и применять advice.

Ключевые моменты:

• Join points это только выполнения методов
• Вызовы через this.foo() обходят advice
• Финальные/приватные методы и классы часто не поддаются советам

Для полной функциональности, такой как перехват полей или конструкторов, используйте AspectJ weaving.
В Spring Boot добавьте spring-boot-starter-aop или включите через @EnableAspectJAutoProxy.

Результат → более чистый и поддерживаемый код, при этом повторяющиеся задачи остаются консистентными.

👉 Java Portal

Нашёл бесплатный кроссплатформенный обозреватель кода. Это опенсорс-инструмент, который работает автономно без интернета. Поддерживает C, C++, Java и Python. Может быть полезен для изучения чужого кода или анализа своих проектов.

GitHub: Sourcetrail

👉 Java Portal

Представь, что ты на собеседовании по Spring. Тебя спрашивают: Dependency Inversion vs Inversion of Control vs Dependency Injection. Это одно и то же? Как бы ты ответил?

Dependency Inversion Principle (DIP) это принцип из SOLID. Суть в том, что высокоуровневые модули не должны зависеть от низкоуровневых. Оба должны зависеть от абстракций. Это делает код гибким и удобным для тестирования.

Inversion of Control (IoC) это архитектурный стиль. Обычно твой код сам управляет созданием и связями объектов. При IoC этот контроль передаётся фреймворку или контейнеру. Он решает, когда и как связать объекты.

Dependency Injection (DI) это конкретный способ реализовать IoC. Фреймворк подсовывает нужные зависимости в класс, чаще всего через конструктор или сеттер.

Можно представить это как уровни:

- DIP задаёт правило проектирования
- IoC меняет то, кто управляет созданием объектов
- DI это инструмент, которым фреймворки делают этот перенос

Итог для собеседования: DIP = принцип, IoC = стиль, DI = техника.

👉 Java Portal

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

👉 Java Portal

Готовишься к собеседованиям на бэкенд?

Не пропусти эти 5 концептов системного дизайна для микросервисов

I. Saga: управляет распределёнными транзакциями без глобальной блокировки. Каждый сервис выполняет транзакцию в своей базе и публикует событие. Ошибки обрабатываются компенсирующими транзакциями. Реализуется через хореографию или оркестрацию.
II. TCC: резервирует ресурсы на этапе try, подтверждает через confirm, если все части успешны, или отменяет через cancel при ошибке. Часто используется для бронирований и платежей.
III. 2PC: координатор просит участников подготовиться; если все согласны, выполняется commit, иначе abort. Гарантирует атомарность, но синхронный, может блокировать участников и снижает доступность.
IV. Идемпотентность: проектируй операции так, чтобы повторные вызовы не изменяли результат. Используй idempotency key или дедупликацию.
V. Eventual Consistency: копии могут временно расходиться, но со временем сходятся через асинхронную репликацию или события. Подходит, когда важны масштабируемость и доступность.

👉 Java Portal

Полное обучение Apache Kafka — от нуля до продакшена. Включает подробное руководство, настройку кластера через Docker Compose, примеры на разных языках и скрипты для управления в продакшене.

https://github.com/StefanoFrusone/kafka-zero-to-production

👉 Java Portal

В новых версиях Spring RestTemplate заменяется на RestClient.

RestTemplate это старый синхронный HTTP-клиент в Spring с громоздким API и изменяемыми объектами, который постепенно устаревает.

RestClient — новый синхронный клиент (Spring 6.1+), с «плавным» и интуитивным API, вдохновлённый WebClient, неизменяемый и лаконичный. Он позволяет писать REST-вызовы проще и читаемее, обеспечивает лучшую обработку ошибок и поддержку тестирования, а также является современной заменой, которую проще поддерживать и расширять.

👉 Java Portal

На Хабре уже есть много материалов по Spring Security, от коротких заметок до детальных разборов. Этот конспект-мануал собран как пошаговое введение = от базовой аутентификации и фильтров до JWT и OAuth2.

Материал основан на официальной документации и дополнен разъяснениями «на простом языке». Использовался подход, который помогает структурировать знания и сделать стиль текста более читабельным, ближе к документации.

👉 Java Portal

Очень частый сценарий для собеседований по Java/бэкенду, который игнорировать нельзя.

Нужно ли защищать API?

Сценарий = ваш endpoint для логина может вызываться не более 10 раз в минуту для одного пользователя.

→ Простейший подход — Fixed Window Counter (счётчик фиксированного окна) = считаем запросы с 10:01 до 10:02, потом сбрасываем счётчик.

Проблема? Пользователь может сделать 10 запросов в 10:01:59 и ещё 10 в 10:02:01. Итого 20 запросов за 2 секунды 🤯

Для более надёжного решения используют Sliding Window для плавного ограничения или Token Bucket, чтобы корректно обрабатывать всплески.

→ Sliding Window
Избегает проблемы резких всплесков на границе окна. Вместо фиксированной минуты (например, 10:01) считает запросы за последние 60 секунд от момента запроса. Дает более плавное и точное ограничение скорости.

→ Token Bucket
Отлично подходит для корректной обработки всплесков. Представьте ведро, которое постепенно наполняется «токенами» (например, 1 токен в секунду, ведро для одного пользователя/IP/endpoint). Каждый API-запрос «съедает» один токен. Если токенов нет — запрос отклоняется. Так контролируется средняя скорость, но при этом пользователи могут накопить несколько токенов для небольшого всплеска.

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

👉 Java Portal

«99% аптайма достаточно».

Эту сказку слишком многие команды рассказывают сами себе.

А теперь математика:

• 99% аптайма —> примерно 7 часов простоя в месяц
• 99.9% —> около 40 минут
• 99.99% —> около 4 минут

Семь часов вроде не звучат страшно, но на масштабе это убивает доверие, срывает SLA и сжигает деньги.

И даунтайм не всегда выглядит как большой и громкий инцидент.

Он подкрадывается через такие вещи, как:

• платежка, которая теряет запросы без ретраев
• битый конфиг кэша, из-за которого трафик встаёт
• сервис, который тихо отваливается для части пользователей

Поэтому надёжность это не погоня за «100%». Это про системы, которые умеют гнуться, но не ломаться.
Ретраи. Circuit breakers. Фолбэки с сохранением работоспособности.
И правильные метрики — error budgets, а не красивые проценты для отчёта.

Потому что пользователю плевать на твой аптайм в дэшборде.
Ему важно, чтобы продукт работал, когда это реально нужно.

Так что когда кто-то снова скажет «99% это нормально», спроси его
Нормально для графика или нормально для клиента?

👉 Java Portal

Бронировал когда-нибудь онлайн перелёт, отель и машину, но отель сорвался? Вряд ли захочешь остаться с билетом и машиной, но без номера.

Паттерн SAGA работает как умный тревел-агент для микросервисов. Он управляет последовательностью операций —> сначала бронируем перелёт, потом отель.

Если один шаг падает, автоматически запускаются компенсирующие действия, которые откатывают предыдущие шаги —> например отмена перелёта.

Это гарантирует, что система не окажется в неконсистентном состоянии. Такой подход реально выручает, когда нужно работать с транзакциями в распределённых Java-сервисах.

Как это работает:

Успешный путь - bookFlight() → bookHotel() → rentCar() и можно ехать отдыхать.

При провале, если bookHotel() падает, в catch запускается cancelFlight() и первый шаг откатывается.
В итоге ты не остаёшься с перелётом в никуда, а система сохраняет консистентность.

👉 Java Portal

Шпаргалка по Java

👉 Java Portal

В Java-приложениях одна небольшая настройка может улучшить производительность в 50 раз.

@Transactional  
public List<Order> getRecentOrders() {  
    return orderRepository.findRecent();  
}  

Видите здесь что-нибудь странное?

Аннотация @Transactional на методе, который просто делает read/GET вызов.

Хуже всего то, что по умолчанию @Transactional работает в режиме read-write, то есть:

- лишние блокировки ресурсов;
- база вынуждена обрабатывать транзакцию даже для простого SELECT.

Что можно сделать:

@Transactional(readOnly = true)

Это позволит:

Пропустить ненужные flush-операции в Hibernate.
Оптимизировать работу транзакций для SELECT-запросов.
Уменьшить оверхед от прокси и избежать лишних блокировок.

Правила, которые стоит помнить:

Не вешайте @Transactional везде подряд только ради «красоты».
Используйте @Transactional(readOnly = true) для запросов.
Убирайте @Transactional, если методу вообще не нужна транзакция.
Регулярно профилируйте приложение — мелкие ошибки выливаются в огромные потери производительности.

👉 Java Portal

⌨️ Как вырасти до Мидла или Синьора в два раза быстрее?

👨‍💻Просто хорошо работать работу не достаточно. Ты делаешь то, что нужно компании, а не то, что повысит твой грейд

Лучший способ вырасти — это персональный план развития от Senior-инженера из БигТеха.

Вот как все работает:
1️⃣ Мок-интервью 1-на-1: Час реалистичного собеса с Senior-инженером из Иннотеха, Сбера или другого бигтеха
2️⃣ Честный фидбек: созвонимся и расскажем твои точки роста, оценим грейд и потенциальный уровень зарплаты
3️⃣Персональный план развития: не просто «учите алгосы», а роадмап с конкретными темами, который приведет тебя к желаемому грейду или офферу. Пример плана развития прикрепили к сообщению

Мы в ШОРТКАТ провели уже почти 1000 таких мок-интервью и получили оценку 4.9/5, поэтому знаем о чем говорим.

📈 Да, и все это за 900 рублей. Почему так дешево?
Мы хотим, чтобы у каждого была возможность проверить в деле наш сервис, а потом уже доверить нам свое развитие.

Переходи в нашего бота и забирай свой мок за 900 рублей → @shortcut_sh_bot

Реклама.
О рекламодателе.

14 алгоритмов сортировки в одной минуте

👉 Java Portal

Недавно на собеседовании кандидата спросили о четырёх основных функциональных интерфейсах Java 8. Когда его попросили объяснить каждый из них, он растерялся.

Вот эти 4 основных функциональных интерфейса:

I. Predicate<T>
Проверяет, удовлетворяет ли входное значение условию, возвращая true или false.
Как я запоминаю: как фейс-контроллер в клубе, который проверяет, есть ли ты в списке гостей, прежде чем пустить внутрь.

II. Function<T, R>
Принимает один аргумент и возвращает один результат, трансформируя данные.
Как я запоминаю: торговый автомат, который принимает монету (вход) и выдает газировку (выход).

III. Supplier<T>
Предоставляет результат без необходимости передавать аргументы, как фабричный метод.
Как я запоминаю: волшебная шляпа, из которой по запросу достается кролик, без предварительных условий.

IV. Consumer<T>
Принимает входное значение и выполняет над ним действие, но ничего не возвращает.
Как я запоминаю: мусорное ведро, которое принимает твой мусор (вход) и просто утилизирует его, без всякой «квитанции» на выходе.

На скрине пример, который использует все эти 4 интерфейса.

👉 Java Portal