Java Books
Java Библиотека По всем вопросам- @notxxx1 @ai_machinelearning_big_data - machine learning @pythonl - Python @itchannels_telegram - 🔥 best it channels @ArtificialIntelligencedl - AI @pythonlbooks-📚 @programming_books_it -it 📚 № 5032728887
Ko'proq ko'rsatish📈 Telegram kanali Java Books analitikasi
Java Books (@java_library) kanali faol ishtirokchi. Hozirda hamjamiyat 14 211 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 8 815-o'rinni va Rossiya mintaqasida 46 019-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 14 211 obunachiga ega bo‘ldi.
25 Avgust, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni -60 ga, so‘nggi 24 soatda esa -11 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 8.91% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 3.73% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 1 267 marta ko‘riladi; birinchi sutkada odatda 530 ta ko‘rish yig‘iladi.
- Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 4 ta reaksiya keladi.
- Tematik yo‘nalishlar: Kontent docker, собеседование, sql, boot, string kabi asosiy mavzularga jamlangan.
📝 Tavsif va kontent siyosati
Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“Java Библиотека
По всем вопросам- @notxxx1
@ai_machinelearning_big_data - machine learning
@pythonl - Python
@itchannels_telegram - 🔥 best it channels
@ArtificialIntelligencedl - AI
@pythonlbooks-📚
@programming_books_it -it 📚
№ 503272888...”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 26 Avgust, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Texnologiyalar & Aralashmalar toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.
@SpringBootApplication.
Пример:
@SpringBootApplication(
exclude = {
DataSourceAutoConfiguration.class,
HibernateJpaAutoConfiguration.class
}
)
public class MyApplication {
public static void main(String[] args) {
SpringApplication.run(MyApplication.class, args);
}
}
Когда это полезно:
• вы используете свою конфигурацию базы
• приложение не работает с БД, но зависимости есть
• тестовые или lightweight-сервисы
• миграция старого проекта
Spring Boot умный.
Но иногда ему нужно сказать: “не делай это за меня”.
#SpringBoot #Java #BackendThreadLocal.withInitial(...).
Что это даёт:
- У каждого потока своя независимая копия переменной
- Не нужны синхронизация и блокировки
- Значение создаётся лениво — только при первом обращении
Пример:
ThreadLocal<Integer> counter =
ThreadLocal.withInitial(() -> 0);
counter.get(); // 0
counter.set(70);
counter.get(); // 70grep только для простого поиска по файлам — вы теряете половину его возможностей.
Разбор *grep by example* — это набор реальных сценариев, которые показывают, как использовать инструмент для повседневных задач разработчика и DevOps.
Что можно делать с grep
- Поиск по нескольким файлам и каталогам
- Фильтрация логов и больших текстов
- Поиск по шаблонам и регулярным выражениям
- Игнорирование регистра
- Подсветка совпадений
- Показ строк до и после совпадения
Полезные примеры
Поиск слова во всех файлах:
antonz.org/grep-by-example/
<!-- Dependency -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-mail</artifactId>
</dependency>
⚡️<!-- application.properties -->
spring.mail.host=smtp.gmail.com
spring.mail.port=587
spring.mail.username=your_email@gmail.com
spring.mail.password=your_app_password
spring.mail.properties.mail.smtp.auth=true
spring.mail.properties.mail.smtp.starttls.enable=true
// Service
@Autowired
private JavaMailSender mailSender;
public void sendEmail(String to, String subject, String text) {
SimpleMailMessage message = new SimpleMailMessage();
message.setTo(to);
message.setSubject(subject);
message.setText(text);
message.setFrom("your_email@gmail.com");
mailSender.send(message);
}@Email — проверяет формат почты
- @NotBlank — поле обязательно
- @Size(min, max) — ограничения длины
- @Pattern — проверка по regex
Spring автоматически:
- валидирует входящий JSON
- при ошибке возвращает 400 Bad Request
- формирует понятный список ошибок в ответе
То есть API сразу становится “самозащищающимся” от кривых данных.
Важно: логику валидации мы держим рядом с данными, а не размазываем по контроллерам.
Если нужно — формат ответа с ошибками можно полностью переопределить через глобальный exception handler.
Итог: меньше бойлерплейта, чище контроллеры и предсказуемое поведение API.
@javatg-XX:+UseCompactObjectHeaders
По отзывам в реальных системах:
15–30% снижения heap - обычная история.
Просто протестируй на своих сервисах - и забирай бесплатную экономию.RestTemplate, не разбрасывай таймауты по коду.
✅ Правильнее сделать конфигурацию через RestTemplateBuilder:
- один общий RestTemplate с дефолтными timeout
- плюс отдельные клиенты под “медленные” сервисы (через `@Qualifier`)
Так у тебя:
- единая точка настройки
- меньше багов в проде из-за “вечных” запросов
- проще дебажить и менять параметры
💡 Особенно полезно в микросервисах, где внешние сервисы могут подвисать.
#SpringBoot #JavaDevnull поля в JSON
Если ваш API отдаёт JSON и там постоянно летят поля вида:
"phone": null,
"email": null
это:
- засоряет ответы
- увеличивает трафик
- мешает фронту (лишние проверки)
Решение - сказать Jackson: не сериализовать null-поля.
Достаточно добавить аннотацию на DTO:
✅ @JsonInclude(JsonInclude.Include.NON_NULL)
После этого все поля со значением null автоматически исчезнут из JSON-ответа.
Плюс: это особенно удобно для PATCH/частичных ответов.== сравнивает ссылки (объекты), а не текст
- иногда “работает” из-за String Pool, а иногда ломается в проде
- из-за этого появляются баги уровня: “на деве ок, в проде не ок”
Правило:
- ✅ для сравнения текста всегда equals()
- ✅ если строка может быть null - используй "CONST".equals(str)
- ✅ если нужно без учета регистра - equalsIgnoreCase()
Подписывайся, больше фишек каждый день !
❌ ПЛОХО: упадёт, если s == null
if (s.equals("OK")) {
handle();
}
// ✅ ЛУЧШЕ: safe equals (null-safe)
if ("OK".equals(s)) {
handle();
}
// ✅ Универсально: сравнение объектов + null-safe
if (Objects.equals(s, "OK")) {
handle();
}TextUtils, который делает только одну вещь:
- форматирование текста
- обработка строк
- простые операции над конкретной областью
❌ Плохо (God class)
Типичный DoThings, где впихнули всё подряд:
- работа с файлами
- логирование
- бизнес-операции
- управление задачами
- и ещё 20 методов “на всякий случай”
Почему это плохо:
- сложно тестировать
- сложно поддерживать
- сложно менять (ломается всё)
- растёт связанность и хаос
Правило:
Helper-класс должен иметь одну ответственность.
Если класс делает слишком много несвязанных вещей - разбивай на отдельные компоненты.
# Gradle проект с авто-структурой
mkdir my_java_app && cd my_java_app
gradle init --type java-application --dsl groovy --test-framework junit-jupiter
# быстрый запуск + тесты
./gradlew test
./gradlew runpeek() — не для логики.
Его задача — подсмотреть, что проходит по конвейеру, и помочь отладке.
Пример — посмотреть, как меняются данные по шагам:
list.stream()
.filter(x -> x > 10)
.peek(x -> System.out.println("Filter: " + x))
.map(x -> x * 2)
.peek(x -> System.out.println("Map: " + x))
.toList();
Вот, как это работает:
- filter() — отбрасывает лишнее
- peek() — просто печатает, ничего не меняя
- map() — преобразует значения
Почему важно не класть туда «настоящую» логику:
- peek() могут удалить или отключить
- порядок выполнения потоков может меняться
- код становится хрупким и непредсказуемым
Коротко:
- нужен вывод - используй peek().
- нужна логика - используй map(), filter() и другие операторы.orElseGet() вместо orElse(), когда значение считать дорого
Многие пишут так:
User user = cache.find(id).orElse(createDefaultUser());
Проблема: createDefaultUser() выполнится всегда,
даже если пользователь нашёлся в кэше.
Правильнее так:
User user = cache.find(id).orElseGet(() -> createDefaultUser());
💡 В чём фишка
orElse() сначала вызывает аргумент, потом проверяет Optional
orElseGet() вызывает лямбду только если значение пустое
📌 Когда это особенно важно
- создание объектов «по умолчанию» дорогое
- требуется загрузка из БД/сети
- есть тяжёлая сериализация или вычисления
@AutoConfigureRestTestClient
Это автоматически настраивает клиент и позволяет:
- отправлять запросы прямо из тестов
- проверять статус и тело ответа
- работать с объектами, а не “сырым” JSON
Пример
Копировать код
@SpringBootTest
@AutoConfigureRestTestClient
public class PersonControllerTests {
private static final String API_PATH = "/persons";
@Test
void add(@Autowired RestTestClient restTestClient) {
restTestClient.post().uri(API_PATH)
.body(Instancio.create(Person.class))
.exchange()
.expectStatus().is2xxSuccessful()
.expectBody(Person.class)
.value(person -> assertNotNull(person.getId()));
}
}
👉 Для TestRestTemplate есть похожая аннотация:
@AutoConfigureTestRestTemplateТесты становятся чище, короче и ближе к реальному поведению API ✨ @javatg
