Java Portal | Программирование

Генерация тестовых данных Чтобы написать хороший тест, нужны хорошие тестовые данные, приближенные к production. Плохо подготовленные данные = плохо написанный тест. Поэтому практически все тесты должны состоять из трех основных частей: - given (подготовка данных и стабов для mock/spy) - when (вызов тестируемого API) - then (проверка результата) Сложно написать хороший тест, полагаясь на данные, которые уже существуют в базе в момент запуска теста (за исключением справочных данных или тех, что были накатаны на production с помощью миграционных фреймворков вроде liquibase и flyway). Обычно на эти данные полагаются другие тесты, а потому часто меняются, что ломает наши тесты или делает их даже flaky. Поэтому каждый тест должен в идеале готовить данные только для себя, на которых он планирует проверить API:

@Test
void findAll() {
    // given
    // Все компактно, содержит только необходимую информацию для программиста
    User user1 = userDao.save(getUser("test1@gmail.com"));
    User user2 = userDao.save(getUser("test2@gmail.com"));
    User user3 = userDao.save(getUser("test3@gmail.com"));

    // when
    List<User> actualResult = userDao.findAll();

    // then
    // Легко получить доступ к id объектов, т.к. накатывание данных было в самом тесте
    assertThat(actualResult).hasSize(3);
    List<Integer> userIds = actualResult.stream()
            .map(User::getId)
            .toList();
    assertThat(userIds).contains(user1.getId(), user2.getId(), user3.getId());
}

А чтобы не испортить состояние базы во время проверки, то: - открываем транзакцию ПЕРЕД выполнением теста (@BeforeEach) - накатываем данные, вызываем API и проверяем результат (@Test) - откатываем транзакцию в конце (@AfterEach) 👉 Java Portal

Учись Git прямо в браузере Теперь можно тренироваться с командами Git, не устанавливая ничего на свой компьютер. Прямо в браузере запускаешь команды и сразу видишь, что делает каждая из них, идеально для обучения и практики. Попробовать можно здесь 👉 Java Portal

В Spring Boot ProductController нужно обработать два разных случая: 1. Вернуть простой 404 Not Found, если продукт не найден. 2. Вернуть 201 Created с динамическим заголовком Location при успешном создании. Какие механизмы Spring вы бы использовали для реализации каждого из этих требований и почему? Два основных способа управлять HTTP-ответом, отправляемым клиенту: → @ResponseStatus: простой статический вариант - Можно навесить на исключение или метод контроллера. - Всегда возвращает один и тот же HTTP-статус. - Подход "fire-and-forget": быстро и лаконично в случаях, когда ответ всегда одинаковый. - Лучше всего подходит для простой обработки ошибок. Например, ResourceNotFoundException, аннотированный @ResponseStatus(HttpStatus.NOT_FOUND), всегда будет возвращать 404. - Нельзя добавить кастомные заголовки или динамическое тело ответа. → ResponseEntity: кастомный инструмент - Даёт полный программный контроль над формированием HTTP-ответа во время выполнения. - Можно выставить статус, добавить заголовки и собрать тело ответа так, как требуется по логике. - Лучше всего подходит для сложных ответов. Например, когда нужно добавить заголовок Location после создания ресурса (201 Created) или вернуть детализированный JSON-объект с информацией об ошибке. - Это основной инструмент, когда ответ должен зависеть от ситуации. Комбинация подходов: Используя @RestControllerAdvice для глобальной обработки исключений, можно применять @ResponseStatus для типовых ошибок, а ResponseEntity — для более специфичных и динамичных ответов. Такой подход даёт одновременно и эффективность, и гибкость. 👉 Java Portal

Проект JDBG от roger1337 позволяет подключаться к JVM во время выполнения и исследовать внутреннее состояние Java-программы. Инструмент использует JNI + JVMTI + DLL-инъекцию, поддерживает просмотр классов, байткода, стека вызовов, локальных переменных и экземпляров объектов. Создан для исследовательских и образовательных целей, под лицензией Apache 2.0. https://github.com/roger1337/JDBG 👉 Java Portal

Джуны — всё, ИИ победил. По статистике BCG, за последний год компании выбросили на улицу 75% молодняка. При этом миддлам и сеньорам зарплаты подняли в 4 (!) раза. Чтобы подняться до уровня элит в аномально короткие сроки — подпишитесь на легендарные каналы для айтишников: Новости и инсайды Фронтенд разработка ИИ и биг дата Node js Вёрстка Питон и нейросети QA-тестировщики Там раскрыли инфу из курсов общей стоимостью 5.000.000р в эксклюзивных пошаговых инструкциях. Пока остальные пойдут на дно якорем, вы войдете в 10% тех, кто сломал систему.

CQRS — один из самых популярных вопросов на собеседованиях Java/backend-разработчиков, связанных с взаимодействием микросервисов. При этом обычно не задают вопрос в формате «Дайте определение CQRS», а формулируют его через реальный сценарий. Сценарий:

Сервис заказов на e-commerce платформе в данный момент обрабатывает все операции (массовое создание и обновление заказов, поиск заказов клиентов, формирование сложных отчётов по продажам) через одну общую реляционную базу данных. Во время пиковых нагрузок тяжёлые отчётные запросы вызывают серьёзные замедления транзакционных операций, что ухудшает пользовательский опыт. Кроме того, сама модель данных заказов становится чрезмерно сложной, пытаясь одновременно удовлетворить разные потребности.

Вопросы: Определите проблему: Какую ключевую архитектурную проблему этот пример демонстрирует в части работы с данными и почему единая модель данных не справляется? Предложите решение: Как вы бы переработали этот сервис, чтобы устранить проблемы с производительностью и избыточной сложностью? Назовите архитектурный паттерн и его основной принцип. Ответ: CQRS решает эту задачу за счёт разделения моделей и баз данных для записи и чтения. Запись (заказы): команды обновляют выделенную нормализованную базу для записи (оптимизированную под транзакции). Чтение (отчёты): события записи асинхронно обновляют отдельную денормализованную базу для чтения (оптимизированную под быстрые запросы и отчётность). CQRS чаще всего реализуется с использованием брокера сообщений. 👉 Java Portal

Java Streams Cheat Sheet Пример кода со всеми базовыми приёмами работы со Stream API:

преобразование коллекций flatMap, mapMulti, peek сортировка, min/max, distinct проверки (allMatch, anyMatch) объединение (reduce, joining) группировка и разбиение (groupingBy, partitioningBy)

👉 Java Portal

Бэкенд на пределе возможностей: миллионы пользователей, высокие нагрузки, отказоустойчивость. В канале Backend VK Hub эксперты рассказывают, как устроены системы под капотом, делятся экспертизой и обсуждают инженерные решения. Подписывайтесь, чтобы узнать, как строятся сервисы, которые должны работать всегда и у всех.

Многие начинают с Java и используют static повсюду. Кажется, что это «упрощает код», например при вызове методов, но на самом деле static — это довольно точное понятие, которое стоит хорошо понимать. В Java static означает, что что-то принадлежит классу, а не экземпляру. То есть: - Статическое поле существует в памяти только один раз и шарится между всеми объектами этого класса. - Статический метод можно вызвать без создания экземпляра. - Жизненный цикл статических сущностей начинается при загрузке класса в память и заканчивается только при завершении JVM. Для чего используется? 🤔 - Для объявления констант (public static final), которые никогда не меняются. - Для утилитарных методов (например, Collections.sort()), которые не зависят от внутреннего состояния объекта. Где начинаются проблемы? - Когда используешь static для переменных, которые на самом деле должны быть частью состояния объекта. - Когда превращаешь его в «глобальную зависимость», и код становится тяжело тестировать, плюс возникает сильная связность. static — это не шорткат. Это способ сказать:

«это уникально и шарится по всему приложению».

👉 Java Portal

Как тестировать Spring Boot приложения в Java? Статья объясняет, как использовать @SpringBootTest, разницу между юнит- и интеграционными тестами, а также даёт советы по ускорению тестов. Полезно для разработчиков любого уровня, работающих со Spring Boot и микросервисами. 👉 Java Portal

🔥Прими участие в Хакатоне от ИТ-холдинга Т1 в Новосибирске и поборись за призовой фонд 800 000 рублей! Когда: 23–26 октября Формат: онлайн + финал на площадке Участвуй, если ты: 🔹обучаешься на технической или ИТ-специальности; 🔹развиваешься в направлении разработки, аналитики, CV, ML или DevOps; 🔹сможешь быть в Новосибирске 26 октября. Выбери свой кейс:

✴️Цифровой дресс-код: фон, который выделяет вас. Создай локальный ML-модуль сегментации видео и генератор персонализированных фонов. ✴️CodeMetrics: метрики, которые помогают расти. Разработай систему автооценки эффективности команд через анализ Git-метрик.

Почему стоит участвовать: 🔘Кейс в портфолио и полезная обратная связь от менторов Т1; 🔘Шанс проявить себя, чтобы начать карьеру в одной из крупнейших ИТ-компаний; 🔘Реальный опыт командной работы; 🔘Мерч и атмосфера сильного комьюнити — в Т1 более 5 000 джунов из 580+ вузов России и Беларуси. Регистрация открыта! ➡️ Успей до 21 октября по ссылке. erid: 2Vtzqwmd32u

Подготовка к собеседованию по Java Microservices Без понимания ключевых концепций микросервисов сложно успешно пройти собеседование на backend-разработчика. Даже если вы не реализовывали их на практике, базовое знание даст серьёзное преимущество. Сохрани себе этот список как краткий гид или план подготовки.

Монолит vs Микросервисы → масштабирование отдельных функций независимо Проектирование микросервиса → изоляция управления профилем пользователя Паттерн API Gateway → единая точка входа для клиентов Взаимодействие сервисов (REST vs Messaging) → асинхронная очередь обработки заказов Паттерн Circuit Breaker → предотвращение каскадных сбоев сервисов Spring Cloud Load Balancer → распределение трафика между инстансами Spring Cloud Config → управление внешними конфигурационными параметрами Service discovery (Eureka/Consul) → автоматический поиск сервисов друг другом Feign Client vs WebClient → блокирующие и неблокирующие вызовы Event-driven архитектура и Kafka → обработка потоков данных в реальном времени Отдельная база для сервиса vs общая база → разделение уровня хранения данных Паттерн Saga → согласованность распределённых транзакций Аутентификация на основе JWT и OAuth2 → безопасные stateless API Безопасность в API Gateway → централизованная аутентификация и авторизация запросов Observability (логи, трассировка, метрики) → отладка проблем в продакшене Prometheus и Grafana → мониторинг состояния системы и дашборды Стратегии деплоя в Kubernetes → авто-масштабирование и самовосстановление приложений Blue-Green и Canary-деплой → нулевой даунтайм и минимальные риски при релизах Когда использовать WebFlux → высоконагруженные и низколатентные API CQRS и Event Sourcing → разделение моделей чтения и записи при сложных сценариях

👉 Java Portal

Топ-53 задач на Java для подготовки к собеседованиям В статье собраны самые популярные задания по Java, полезные курсы по DevOps, Linux и паттернам проектирования, а также список вопросов для подготовки к техническим интервью. 👉 Java Portal

Как вы решаете вопрос с покрытием? Почти в каждом проекте висит задача: поднять покрытие до 70%. И почти в каждой команде никто не хочет этим заниматься. Explyt – AI-плагин для Java и Kotlin разработчиков, который снимает эту боль. Он генерирует юнит-тесты прямо в IDE: по коду, по runtime-трассам, по спекам. И делает это так, как будто реально вник в проект. 📌 Что умеет: - создаёт осмысленные тесты для Java и Kotlin-кода - поддерживает JUnit 4/5, TestNG, кастомные фреймворки - превращает execution trace в автотесты - предлагает фиксы, если сгенерированный тест падает - есть режим агента, где AI сам меняет код, запускает тесты и ищет ошибки 📦 Плагин доступен: - через JetBrains Marketplace - или напрямую с сайта разработчика 🎁 30 дней бесплатного доступа – просто пользуйтесь. 👉 Попробовать на своём проекте

👉 Java Portal

Вопрос из Java-собеседования (сценарный): Ты используешь @Autowired для field injection в Spring-проекте. Это просто и работает.

@Component
public class UserService {
    
    @Autowired
    private UserRepository userRepository;
}

Тимлид просит тебя отрефакторить это, так как field injection часто считается плохой практикой. Подумай о минусах field injection: → Visibility: скрывает обязательные зависимости класса. → Testability: усложняет unit-тестирование, часто требует рефлексии. → Runtime Issues: может привести к NullPointerException, если зависимость отсутствует. → Design: поощряет классы с чрезмерной ответственностью (нарушение SRP). Какой рекомендуемый вариант? → Constructor Injection. Зависимости явно передаются при создании объекта, делая их обязательными.

@Component
public class UserService {
    private final UserRepository userRepo; // final!
    
    public UserService(UserRepository userRepo) {
        this.userRepo = userRepo;
    }
}

Почему Constructor Injection лучше? → Explicit: явно показывает, что нужно классу для работы. → Guaranteed: приложение не поднимется, если зависимости нет. → Immutable: final-поля безопаснее и дружелюбнее к многопоточности. → Testable: легко замокать и прокинуть зависимости в тестах. Это приводит к более надежному и поддерживаемому коду. 👉 Java Portal

Держите репозиторий на GitHub где собрана отличная подборка бесплатных материалов по программированию. Здесь собраны сотни книг по самым разным направлениям: от веб-разработки и геймдева до AI, блокчейна, создания приложений и даже prompt engineering. 😎 👉 Java Portal

🔍Тестовое собеседование с Java-разработчиком из МТС уже завтра 1 октября (уже завтра!) в 19:00 по мск приходи онлайн на открытое собеседование, чтобы посмотреть на настоящее интервью на Middle Java-разработчика. Как это будет: 📂 Илья Аров, старший разработчик в МТС, будет задавать реальные вопросы и задачи разработчику-добровольцу 📂 Илья будет комментировать каждый ответ респондента, чтобы дать понять чего от вас ожидает собеседующий на интервью 📂 В конце можно будет задать любой вопрос Илье Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для Java-разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы. Переходи в нашего бота, чтобы получить ссылку на эфир → @shortcut_sh_bot Реклама. О рекламодателе.

Вопрос для собеседования Java/Backend:

Как современные приложения оставляют вас залогиненным без хранения сессии на сервере? 🫖

Современные приложения могут держать пользователя залогиненным без серверного хранения сессий благодаря JWT Это компактный и безопасный токен, который сервер подписывает и отдает клиенту. Клиент хранит его и отправляет вместе с запросами, а сервер проверяет подпись и доверяет данным внутри токена без обращения к базе. JWT состоит из трёх частей — заголовка с алгоритмом и типом, полезной нагрузки с пользовательскими данными (claims) и подписи, которая гарантирует подлинность. Такой подход делает авторизацию stateless: вся необходимая информация хранится в самом токене. Чтобы обеспечить безопасность, важно всегда использовать HTTPS, задавать короткий срок жизни токена и предусматривать механизм отзыва украденных токенов. 👉 Java Portal

Google увеличил функционал Agent Development Kit для Java, внедрив поддержку LangChain4j. Теперь Java-инженеры способны подключать модели OpenAI, Anthropic, Mistral и прочие, разрабатывая многоагентные решения с более гибким контролем и усовершенствованной логикой. Подробности: тык 👉 Java Portal