✔️ Java-тест: индексация списка в Map

Напишите метод для production-кода 👇

📦 Задание

Реализуйте метод, который строит индекс «email → пользователь»:

public Map<String, User> indexByEmail(List<User> users) {
    // Ваша реализация
}

📋 Требования

— На вход может прийти null или пустой список → вернуть пустую Map.
— В списке встречаются пользователи с одинаковым email → при дубле оставить последнего (и обоснуйте политику).
— email может быть null → такие записи пропускать.
— Порядок итерации сохранять.

Ставьте → 🔥, если нравится формат. Если нет → 🤔

💬 Решения под спойлер. Сравним, какое будет лучше.

🐸 Библиотека собеса по Java

#practise

🔥 Хот-тейк на вечер

Твой Service-слой — это карго-культ, а «доменная модель» — мешок сеттеров- Контроллер → Сервис → Репозиторий, @Entity с голыми полями, вся логика в *ServiceImpl. Знакомо? Поздравляю: ты пишешь процедурный код и уже лет 15 называешь это ООП.

Мартин Фаулер записал anemic domain model в антипаттерны ещё в 2003-м. Поведение должно жить внутри сущности (Rich Model), а не в стопке сервисов, которые дёргают её сеттеры снаружи.

Но стоит затащить бизнес-логику в JPA-сущность и ты женишь домен на Hibernate, ловишь LazyInitializationException где не ждал и молишься на detached-состояния.

Так за кем правда?

Анемичная модель = здоровый прагматизм и чистое разделение слоёв. Или мы просто разучились в ООП и прикрываемся «так исторически сложилось».

Пишите, за кого топите 👇

🐸Библиотека джависта

#DevLife

🔧 Магия kubectl

Под рестартится каждые 5 минут, а kubectl logs показывает только текущий инстанс? Добавьте --previous, и вы увидите логи предыдущего упавшего контейнера — именно там обычно лежит причина крэша.

🔹 Зачем это нужно

— При CrashLoopBackOff текущий контейнер пустой, он только стартовал и ещё ничего не записал.
— Логи предыдущего контейнера хранятся до следующего рестарта, окно для отладки есть.
— Без этого флага вы буквально смотрите не туда.

🔹 Как использовать

— Логи предыдущего контейнера: kubectl logs pod-name --previous
— Конкретный контейнер в мультиконтейнерном поде: kubectl logs pod-name -c sidecar --previous
— Последние 50 строк: kubectl logs pod-name --previous --tail=50
— Следить за логами в реальном времени: kubectl logs -f pod-name
— Логи всех подов деплоймента сразу: kubectl logs deploy/my-app --all-containers

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#Enterprise

⚙️ В чем разница между балансировщиками нагрузки, обратными прокси и API-шлюзами?

1️⃣ Балансировщик нагрузки

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

Он получает запрос, перенаправляет его на сервер, принимает ответ и отправляет его обратно клиенту.

Это увеличивает пропускную способность, снижает задержки и оптимизирует использование ресурсов.

2️⃣ Обратные прокси

Работают как посредники между клиентами и серверами, обрабатывая запросы и передавая данные, скрывая серверы и повышая их безопасность.

Они обеспечивают контроль за сетевым трафиком, снижая риски атак и угроз.

Дополнительно, они могут кэшировать контент для уменьшения нагрузки на сервер, сжимать данные для ускорения передачи и управлять SSL/TLS-шифрованием, разгружая веб-серверы.

3️⃣ API-шлюзы

Работают как единая точка входа для всех API-запросов, направляя их к нужным микросервисам и собирая результаты.

Они упрощают взаимодействие клиентов с разными сервисами, добавляют защиту, применяют правила, переводят между веб-протоколами и агрегируют данные.

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

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#CoreJava

🔐 Spring Security: хватит бояться, пора настраивать

Все мы рано или поздно упираемся в Spring Security и обычно это выглядит как «добавил стартер, всё сломалось, ничего не понятно».

В новой статье на Хабре практика с самого нуля:

▪️ поднимаем проект на Spring Boot + PostgreSQL в Docker Compose
▪️ смотрим, что Security делает «из коробки»: дефолтный логин, редиректы, сгенерированный пароль
▪️ пишем свою сущность User с ролями и разбираем каждый метод UserDetails. Зачем нужны isAccountNonLocked, isEnabled и прочие «непонятные» методы
▪️ реализуем UserDetailsService — ту самую точку входа, без которой фреймворк вообще не знает о ваших пользователях

Уровень — простой, время — ~9 минут. Идеально, если только начинаете разбираться в безопасности Spring-приложений или хотите наконец понять, что происходит под капотом.

🔗 Подробнее

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#Enterprise

😮 Топ-вакансий для джавистов за неделю

Middle Backend Developer (Kotlin/Java) — удалёнка — ДжазТим

Middle Java Software Engineer — офис (Алматы) — Kaspi kz

Senior Java разработчик — удалёнка/гибрид/офис (Москва) —Азиатско-Тихоокеанский банк

➡️ Еще больше топовых вакансий — в нашем канале Java jobs

ℹ️ @Transactional НЕ откатывается на checked-исключениях

Метод бросил исключение, ты ждёшь rollback, а в БД лежат наполовину применённые изменения. Скорее всего, исключение было checked:

@Transactional
public void process() throws BusinessException {
    repo.save(a);
    if (bad) throw new BusinessException("...");  // checked
    repo.save(b);
}

По умолчанию Spring откатывает транзакцию только на RuntimeException и Error. На любом checked-исключении (наследники Exception, кроме RuntimeException) транзакция коммитится. Это не баг, а наследие декларативных транзакций из EJB.

Два пути:

// 1) явно расширить условие отката
@Transactional(rollbackFor = Exception.class)

// 2) или сделать доменные исключения unchecked
public class BusinessException extends RuntimeException { ... }

Проверь свои сервисные методы, которые бросают checked-исключения внутри @Transactional — там часто прячется молчаливый частичный коммит.

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#Enterprise

✔️ Concurrency-тест: пул потоков копит задачи до OOM

Нагрузка выросла, latency пополз вверх, потом OutOfMemoryError 👇

📦 Задание — code review

Сервис обрабатывает входящие события асинхронно.

@Configuration
public class ExecutorConfig {

    @Bean
    public ExecutorService eventExecutor() {
        return Executors.newFixedThreadPool(10);
    }
}

@Service
@RequiredArgsConstructor
public class EventService {

    private final ExecutorService eventExecutor;

    public void handle(Event event) {
        eventExecutor.submit(() -> process(event));
    }
}

▪️ Объясни

— Какая очередь стоит за Executors.newFixedThreadPool и почему она опасна под нагрузкой.
— Почему задачи бесконтрольно «копятся» и система падает в OutOfMemoryError, а не начинает отбрасывать нагрузку.
— Как собрать ThreadPoolExecutor руками: ограниченная очередь, RejectedExecutionHandler, backpressure. Чем плох и newCachedThreadPool в этом сценарии.

Ставьте → 🔥, если нравится формат. Если нет → 🌚

💬 Решения под спойлер. Сравним, какое будет лучше.

🐸 Библиотека собеса по Java

#practise

🐳 Магия Docker CLI

Собрали образ и он весит 2 ГБ, а вы не понимаете, откуда столько? docker history покажет размер каждого слоя — сразу видно, какая инструкция в Dockerfile раздула образ.

🔹 Зачем это нужно

— Каждая инструкция в Dockerfile создаёт слой, и docker history показывает размер каждого.
— Сразу видно, если COPY затянул 800 МБ зависимостей.
— Помогает оптимизировать порядок слоёв для лучшего кэширования.

🔹 Как использовать

— Посмотреть слои: docker history my-image
— Без обрезки команд: docker history --no-trunc my-image
— Только размеры в human-readable: docker history --format "{{.Size}}\t{{.CreatedBy}}" my-image
— Сравнить два образа: запустите history для обоих и сравните слои.

💡 Если видите большой слой от COPY . . — значит, в контекст сборки попали модули, .git или логи. Проверьте dockerignore, это обычно экономит сотни мегабайт.

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#Enterprise

🔍 List vs Set в @OneToMany: почему «просто замени на Set» — плохой совет

List без @OrderColumn в Hibernate — это bag, неупорядоченное мультимножество. Попытка вытащить две bag-коллекции одним JOIN FETCH роняет приложение ещё на старте:

org.hibernate.loader.MultipleBagFetchException:
cannot simultaneously fetch multiple bags

В интернете 280+ апвоутов у ответа «замени List на Set». Исключение он действительно убирает, но лечит симптом, а не причину.

Суть проблемы в том, что JOIN FETCH двух коллекций порождает декартово произведение строк (N×M). С Set Hibernate просто дедуплицирует это в памяти → SQL-результат всё равно раздут, и на больших коллекциях это деградация, а не решение.

Правильно — грузить максимум одну коллекцию за запрос. Persistence Context гарантирует, что в рамках сессии сущность загружается в единственном экземпляре, поэтому две коллекции можно безопасно дотянуть двумя отдельными запросами / @EntityGraph, или через @BatchSize / subselect-fetch.

Бонус про bag: при изменении bag-коллекции (особенно с join-таблицей без собственного PK) Hibernate нередко делает DELETE всех строк коллекции и INSERT заново вместо точечного INSERT. Ещё один аргумент не использовать bag для изменяемых связей.

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#Enterprise