Java

⚠️ Spring Boot ошибка, которую делают почти все Большинство просто добавляет: spring-boot-starter-web и не думает дальше. Но вот в чём проблема 👇 Этот стартер тянет за собой: - встроенный сервер (Tomcat) - лишние зависимости - ненужный overhead 👉 даже если тебе нужен только MVC 💡 Правильный подход: Если тебе нужен только Spring MVC — используй: spring-boot-starter-webmvc Что это даёт: • 📦 меньше зависимостей • ⚡ быстрее запуск • 🧹 чище архитектура • 💸 меньше ресурсов 🔥 Когда это критично - микросервисы - serverless - high-load системы - оптимизация старта 🧠 Инсайт Чем меньше лишнего ты тащишь в проект → тем проще его поддерживать 👉 Не ставь "на всякий случай" Ставь только то, что реально нужно #springboot #java ⚡️ Полезные ресурсы по Java 🚀 Max @javatg

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

🚀 Spring Boot: не делай эту ошибку с filters / interceptors Многие используют фильтры и интерцепторы неправильно 👇 👉 Они должны быть только для cross-cutting задач (то, что применяется ко ВСЕМ запросам) Примеры нормального использования: 🟢 Filters: - CORS - Encoding 🟢 Interceptors: - аутентификация / авторизация - метрики / логирование - locale - общие headers ❌ Главная ошибка: кладут туда бизнес-логику Например: - запрос в БД - проверка подписки - сложная логика Почему это плохо: - выполняется на КАЖДЫЙ запрос - создаёт лишнюю нагрузку - ломает архитектуру - усложняет тестирование 📉 Итог: interceptor превращается в «мусорный слой» 💡 Как правильно: - бизнес-логика → в сервисах - контроллеры → orchestration ⚡️ Полезные ресурсы по Java 🚀 Max @javatg

⚡️ Java совет: перестань терять производительность из-за boxing Когда используешь Stream<Integer>, JVM создаёт объект Integer для каждого значения. Это лишние аллокации, нагрузка на GC и замедление кода. Если работаешь с примитивами — используй primitive streams. ❌ Boxing (медленнее) Stream<Integer> boxed = Stream.of(1, 2, 3, 4, 5); int sumBoxed = boxed.reduce(0, Integer::sum); ✅ Без boxing (быстрее и эффективнее)

    
        
int sumPrimitive = IntStream.of(1, 2, 3, 4, 5).sum();
{}
    

Другие primitive streams:

    
        
IntStream

LongStream

DoubleStream
{}
    

Когда это критично: • большие коллекции • high-load сервисы • data processing • performance-sensitive код Правило простое: Если работаешь с числами - используй primitive streams, а не обёртки. ⚡️ Полезные ресурсы по Java 🚀 Max @javatg

⚠️ Маленькая настройка в Spring Boot, которая может спасти от скрытых багов. Лучше не менять значение по умолчанию:

    
        
spring.main.allow-bean-definition-overriding=false
{}
    

Что это делает? Если в приложении два бина с одинаковым именем, Spring не запустится. И это на самом деле хорошо. Почему: ✔ помогает сразу увидеть конфликт конфигурации ✔ не даёт одному бину тихо перезаписать другой ✔ предотвращает скрытые баги в DI Если же включить:

    
        
spring.main.allow-bean-definition-overriding=true
{}
    

• тогда второй бин молча перезапишет первый. В результате приложение запустится, но будет использовать не тот бин, который вы ожидали. И такие баги потом очень сложно найти. Иногда лучше получить ошибку при старте, чем искать проблему в продакшене. #SpringBoot #Java #Backend ⚡️ Полезные ресурсы по Java 🚀 Max @javatg

⚡️ Перестаём писать методы с 7+ параметрами Если сигнатура выглядит как: createUser(firstName, lastName, email, phone, address, city, country) Это уже сигнал, что модель данных развалилась. Проблема не только в читаемости. Такие методы сложнее поддерживать, расширять и тестировать. Любое изменение ломает сигнатуру и тянет за собой каскад правок. Нормальный вариант - собрать связанные данные в объект: UserInfo userInfo Получаем: - чище API - проще добавлять поля - меньше ошибок при передаче параметров - код начинает отражать доменную модель, а не список строк Это базовый приём, но именно на нём чаще всего экономят, а потом платят сложностью.

👣 На Stepik обновили курс «Rust: полный курс разработчика. С нуля до профи» Представьте: через три месяца вы открываете чужой Rust-код и читаете его как книгу. Arc<Mutex<T>> не вызывает панику. impl Future не пугает. Вы точно знаете, почему компилятор ругается и как это починить за 10 секунд. Это не фантазия. Это результат 50 уроков, в которых каждая концепция объясняется через код и закрепляется практикой. Ownership, traits, generics, async, unsafe - всё, что казалось магией, станет рабочим инструментом. А бонусом - портфолио проектов: от CLI-утилит до REST API и WebAssembly. Вы и так знаете, что Rust - ваш следующий язык. Этот курс просто сделает это реальностью. Сегодня - 55% процентов от цены, торопись: https://stepik.org/a/269250/

☕ Java совет: рекурсивный обход файловой системы В Java есть удобный способ рекурсивно обойти все файлы в директории - метод Files.walk(). Он возвращает Stream<Path>, что позволяет легко фильтровать и обрабатывать файлы через Stream API. Пример - найти все .java файлы в папке src:

    
        
import java.io.IOException;
import java.nio.file.*;
import java.util.stream.Stream;

public class Main {
    public static void main(String[] args) {
        Path startPath = Paths.get("src");

        try (Stream<Path> paths = Files.walk(startPath)) {
            paths
                .filter(Files::isRegularFile)
                .filter(path -> path.toString().endsWith(".java"))
                .forEach(System.out::println);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}{}
    

Что происходит: • Files.walk(startPath) - рекурсивно проходит по всем папкам • filter(Files::isRegularFile) - оставляет только файлы • endsWith(".java") - фильтр по расширению • forEach - обработка найденных файлов Это намного чище, чем писать собственную рекурсивную функцию обхода директорий. #Java #JavaDev #Programming ⚡️ Полезные ресурсы по Java 🚀 Max @javatg

Последний рывок перед майскими — AI-митап #каквсбере в Нижнем Новгороде!⚡️ 23 апреля в кампусе Школы 21 вместе с топовыми спикерами Сбера обсудим сразу три действительно горячие темы: ✔️ Какие алгоритмы генерации и шифрования сейчас в тренде? ✔️ Как «разогнать» искусственный интеллект? ✔️ Каким образом лучше подружить команду с ИИ? Готовы узнать всё о трансформации мира современной разработки? Тогда займите своё место на митапе — подробная программа и регистрация по ссылке!

⚠️ Spring Boot: не включайте publish-request-params в production В Spring Boot есть настройка: spring.mvc.publish-request-params=true Она включает логирование параметров HTTP-запросов. Это удобно в dev-среде, потому что можно видеть: • request headers • query parameters • form data Обычно это используют вместе с фильтром:

    
        
@Bean
public CommonsRequestLoggingFilter logFilter() {
    CommonsRequestLoggingFilter filter = new CommonsRequestLoggingFilter();
    filter.setIncludeQueryString(true);
    filter.setIncludeHeaders(true);
    filter.setIncludePayload(true);
    filter.setMaxPayloadLength(1000);
    filter.setAfterMessagePrefix("COMPLETE REQUEST: ");
    return filter;
}{}
    

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

    
        
POST /login
{
  "username": "john",
  "password": "mypassword"
}{}
    

Если включено логирование payload, такие данные могут попасть в: • application logs • log-агрегаторы • мониторинг системы А это уже серьёзная уязвимость безопасности. Поэтому правило простое: - включайте publish-request-params только в dev - никогда не логируйте request body в production - маскируйте чувствительные поля (`password`, token, `authorization`) Маленькая настройка - но может привести к утечке данных. #SpringBoot #Java #Backend #Security