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
Mostrar más📈 Análisis del canal de Telegram Java Books
El canal Java Books (@java_library) es un actor destacado. Actualmente la comunidad reúne a 14 133 suscriptores, ocupando la posición 9 050 en la categoría Tecnologías y Aplicaciones y el puesto 46 062 en la región Rusia.
📊 Métricas de audiencia y dinámica
Desde su creación el невідомо, el proyecto ha mostrado un crecimiento acelerado, reuniendo a 14 133 suscriptores.
Según los últimos datos del 26 octubre, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de -88, y en las últimas 24 horas de -5, conservando un alto alcance.
- Estado de verificación: No verificado
- Tasa de interacción (ER): El promedio de interacción de la audiencia es 8.38%. Durante las primeras 24 horas tras publicar, el contenido suele obtener 3.46% de reacciones respecto al total de suscriptores.
- Alcance de las publicaciones: Cada publicación recibe en promedio 1 184 visualizaciones. En el primer día suele acumular 489 visualizaciones.
- Reacciones e interacción: La audiencia responde de forma activa: el promedio de reacciones por publicación es 2.
- Intereses temáticos: El contenido se centra en temas clave como docker, собеседование, sql, boot, string.
📝 Descripción y política de contenido
El autor describe el recurso como un espacio para expresar opiniones subjetivas:
“Java Библиотека
По всем вопросам- @notxxx1
@ai_machinelearning_big_data - machine learning
@pythonl - Python
@itchannels_telegram - 🔥 best it channels
@ArtificialIntelligencedl - AI
@pythonlbooks-📚
@programming_books_it -it 📚
№ 503272888...”
Gracias a la alta frecuencia de actualizaciones (últimos datos recibidos el 27 octubre, 2026), el canal mantiene la vigencia y un amplio alcance. La analítica demuestra que la audiencia interactúa activamente con el contenido, lo que lo convierte en un punto de referencia dentro de la categoría Tecnologías y Aplicaciones.
grep только для простого поиска по файлам — вы теряете половину его возможностей.
Разбор *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
Files.walk().
Пример: найти все `.java`-файлы в проекте
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();
}
Почему это хороший подход:
- Рекурсивный обход «из коробки»
- Работает через Stream API
- Легко фильтровать, маппить и агрегировать
- Автоматически закрывает ресурсы (try-with-resources)
Полезно для:
- анализа исходников
- линтеров и кодогенерации
- поиска файлов по расширению
- утилит и dev-скриптов
#Java #IO