Java Portal | Программирование
Open in Telegram
Присоединяйтесь к нашему каналу и погрузитесь в мир для Java-разработчика Связь: @devmangx РКН: https://clck.ru/3H4WUg
Show more
Network:📈 Analytical overview of Telegram channel Java Portal | Программирование
Channel Java Portal | Программирование (@java_iibrary) in the Russian language segment is an active participant. Currently, the community unites 11 920 subscribers, ranking 10 472 in the Technologies & Applications category and 53 940 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 11 920 subscribers.
According to the latest data from 26 October, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by 288 over the last 30 days and by 14 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 10.39%. Within the first 24 hours after publication, content typically collects 6.42% reactions from the total number of subscribers.
- Post reach: On average, each post receives 1 239 views. Within the first day, a publication typically gains 766 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 3.
- Thematic interests: Content is focused on key topics such as boot, string, void, архитектура, resttemplate.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“Присоединяйтесь к нашему каналу и погрузитесь в мир для Java-разработчика
Связь: @devmangx
РКН: https://clck.ru/3H4WUg”
Thanks to the high frequency of updates (latest data received on 27 October, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
11 920
Subscribers
+1424 hours
+617 days
+28830 days
Posts Archive
Почему используется Event-Driven Architecture?
Представьте систему с двумя микросервисами:
1) payments
2) emails
Когда платеж подтверждён, payments вызывает emails, чтобы отправить чек.
Но приложение растёт. Теперь нужно ещё сгенерировать счёт, обновить метрики и отправить уведомление.
Чтобы это сделать, payments начинает вызывать каждый из них.
Каждая новая функциональность добавляет ещё один вызов. Со временем такой поток становится всё сложнее поддерживать.
Event-Driven Architecture предлагает другой способ коммуникации.
Когда платеж подтверждён:
1) payments публикует событие "payment confirmed".
2) emails отправляет чек.
3) billing генерирует счёт.
4) metrics обновляет дашборды.
Если завтра вы добавите ещё один микросервис, ему просто нужно реагировать на это событие. Payments не меняется.
Вот почему это так хорошо сочетается с микросервисами: каждый сохраняет единственную ответственность и может развиваться без прямой зависимости от остальных.
Очевидно, не всё только преимущества. Система также становится сложнее. Возникают такие проблемы, как повторные попытки, дублирующиеся события, порядок обработки и наблюдаемость.
На практике обычно используется брокер (например, Kafka или RabbitMQ), который получает событие и распределяет его по подписанным микросервисам.
👉 Java Portal
Эволюция коммуникации между сервисами
Архитектура ПО кардинально изменилась за последние 30 лет.
Не потому, что старые подходы были неправильными..
а потому что приложения постоянно росли.
Вот как развивалась коммуникация сервисов:
🔹 1990-е → Point-to-Point (прямая связь)
Просто. Быстро. Но жёсткая связанность.
🔹 2000-е → Запрос/Ответ (RPC)
Удалённые вызовы упростили построение распределённых систем.
🔹 2010-е → Очереди сообщений (Message Queues)
Асинхронная коммуникация повысила надёжность и масштабируемость.
🔹 Середина 2010-х → Издатель/Подписчик (Pub/Sub)
Сервисам больше не нужно было знать друг о друге напрямую.
🔹 Конец 2010-х → Потоковая обработка событий (Event Streaming)
Непрерывная обработка данных в реальном времени с помощью платформ вроде Kafka.
🔹 2020-е → API Gateway + Service Mesh
Управление трафиком, безопасность, наблюдаемость и отказоустойчивость стали первоклассными гражданами.
🔹 Сегодня → AI-нативная коммуникация
Агенты не просто вызывают API — они обнаруживают инструменты, рассуждают о задачах и координируют рабочие процессы.
Главный урок?
Каждая эволюция уменьшала связанность и увеличивала масштабируемость.
Мы движемся от:
➡️ Вызова сервисов
➡️ Публикации событий
➡️ Координации интеллектуальных систем
Какой паттерн коммуникации вы используете чаще всего сегодня?
- REST
- gRPC
- Kafka
- RabbitMQ
- Event Bus
- Service Mesh
👉 Java Portal
Примитивные vs Ссылочные типы в Java
Это одна из самых недопонятых тем в Java.
Многие разработчики знают, что такое примитивные и ссылочные типы, но не то, как они хранятся в памяти.
Понимание этой разницы делает такие темы, как String, Arrays, Objects и Garbage Collection, гораздо более лёгкими для усвоения.
🔹 Примитивные типы
Примитивные переменные хранят фактическое значение.
Примеры:
- byte
- short
- int
- long
- float
- double
- char
- boolean
int age = 25;
double price = 99.99;
char grade = 'A';
boolean isJavaFun = true;
Представьте, что вы пишете число прямо на листе бумаги.
age → 25
🔹 Ссылочные типы
Ссылочные переменные не хранят сам объект.
Они хранят адрес памяти (ссылку) объекта.
Примеры:
- String
- Массивы
- Классы
- Интерфейсы
- Перечисления (Enums)
- Записи (Records)
String name = "Vishwanath";
int[] numbers = {1, 2, 3, 4};
Student student = new Student();
Представьте, что вы храните адрес дома, а не сам дом.
name ───► "Vishwanath"
Простой способ запомнить
- Примитив = хранит значение
- Ссылка = хранит адрес объекта
Совет для собеседования
Что произойдёт здесь?
String a = "Java";
String b = a;
b = "Spring";
Станет ли a тоже "Spring"?
Нет.
b обновляется, чтобы ссылаться на другой объект String, в то время как a всё ещё указывает на исходную строку "Java".
Понимание ссылок объясняет, почему поведение объектов отличается от примитивных значений.
Освоение этой концепции значительно облегчит понимание:
- Stack vs Heap памяти
- Объектов и Классов
- Параметров методов
- Коллекций
- Сборки мусора (Garbage Collection)
👉 Java Portal
Как на самом деле работает Git
Большинство использует Git, не понимая, что происходит внутри.
Суть такая:
git init
создаёт папку, за которой Git начинает следить
git add
говоришь Git: «эти изменения пойдут в сохранение»
git commit
фиксирует снимок состояния проекта в этот момент
git push
отправляет эти снимки в облако (обычно GitHub)
git pull
забирает снимки, которые отправили другие
git branch
создаёт отдельную линию разработки, где можно работать изолированно
git merge
объединяет эту ветку обратно в основную
👉 Java Portal
Java совет : начиная с Java 14 можно использовать
record для коротких неизменяемых объектов-носителей данных.
✅ короче обычных POJO
✅ автоматически есть equals(), hashCode(), toString()
✅ объекты неизменяемые по умолчанию
👉 Java Portal
📌 Шпаргалка по API-заголовкам
Заголовки API несут метаданные, обеспечивающие безопасную и эффективную коммуникацию.
- Authorization — отправка токенов доступа безопасно
- Content-Type — определение формата тела запроса
- Accept — указание ожидаемого формата ответа
- User-Agent — идентификация клиентского приложения
- Cache-Control — управление кешированием
- Origin — поддержка валидации CORS
- Cookie — отправка информации о сессии
- Accept-Language — установка языковых предпочтений
Понимание заголовков API помогает создавать более быстрые, безопасные и надёжные приложения.
👉 Java Portal
+1
Spring Cloud: централизуйте конфигурацию с помощью Spring Cloud Config вместо того, чтобы копировать
application.properties в каждый сервис.
Используйте Spring Cloud Config для централизованного управления конфигурацией, а не копируйте application.properties повсюду.
// — 1) Config Server: одно место, которое обслуживает конфигурацию всех сервисов —
@SpringBootApplication
@EnableConfigServer
public class ConfigServerApp {
public static void main(String[] args) {
new SpringApplicationBuilder(ConfigServerApp.class).run(args);
}
}
// — 2) application.yml сервера (раздаёт файлы из classpath) —
// spring.profiles.active: native # локальные файлы, Git не нужен
// spring.cloud.config.server.native.search-locations: classpath:/config
// server.port: 8888
// — 3) /config/client-service.yml (конфигурация для "client-service") —
// myproperty: value
// — 4) Клиент: загружает конфигурацию с сервера при запуске —
// spring.application.name: client-service
// spring.config.import: optional:configserver:http://localhost:8888
@Component
public class GreetingClient {
@Value("${myproperty}") // значение получено с Config Server
private String myProperty;
}
Появился проект Build Mini-Kafka — практическое руководство, в котором предлагается с нуля реализовать упрощённую версию Apache Kafka и разобраться в её внутреннем устройстве.
В процессе разработки предстоит реализовать:
- журнал сообщений с моделью append-only и разбиением на партиции;
- выбор лидера на основе алгоритма Raft;
- отслеживание ISR (набора синхронизированных реплик) и продвижение high watermark;
- идемпотентных и транзакционных продюсеров;
- группы потребителей с автоматической перебалансировкой.
Проект ориентирован на изучение принципов работы распределённых брокеров сообщений и архитектуры Kafka через практическую реализацию, а не через теорию.
Ссылка: https://builddistributedsystem.com/projects/mini-kafka
👉 Java Portal
Java: Глубокие цепочки вроде
user → address → city — классическая ловушка для NullPointerException. Вложенные проверки if (x != null) быстро разрастаются, и легко пропустить один из уровней.
✅Optional:
findByEmail(email)
.map(User::getAddress)
.map(Address::getCity)
.orElse("unknown");Optional в API нет, достаточно одной проверки:
if (user == null || user.getAddress() == null)null-проверок, из-за которых сложно понять, какое именно значение может отсутствовать.
#Java #NullSafety
👉 Java Portal
+1
Redis может быть самым большим предательством в истории open source.
В 2009 итальянский разработчик по имени Salvatore Sanfilippo работал над стартапом, а MySQL был слишком медленным. Тогда он в свободное время сделал собственную in-memory базу данных и выложил её в open source бесплатно.
Он назвал её Redis.
Twitter использовал его. GitHub использовал его. Snapchat использовал его. Stack Overflow использовал его. Каждая крупная технологическая компания в мире запускала Redis где-то в своём стеке.
К 2020 году Salvatore выгорел после 11 лет поддержки проекта в одиночку. Он передал проект Redis Labs и ушёл.
В марте 2024 Redis Labs изменили лицензию.
За ночь Redis перестал быть open source. Облачные провайдеры больше не могли предлагать его как managed service без оплаты Redis Labs. Сообщество, которое выросло вокруг кода Salvatore, проснулось и оказалось заблокированным.
Они не спорили. Они не писали посты. Они форкнули проект.
Через восемь дней Linux Foundation объявил Valkey. Поддержка от AWS, Google, Oracle, Ericsson и Snap. Более 50 компаний присоединились за несколько недель.
В течение года Fedora, Ubuntu, Debian и Arch полностью отказались от Redis и сделали Valkey стандартом. AWS перенёс миллионы узлов на Valkey. Valkey достиг 1.19 миллиона запросов в секунду. На 230% быстрее версии Redis, которую прекратили развивать.
Потом Redis вернул Salvatore, чтобы попытаться вернуть сообщество.
Он вернулся. Он выступил на Hacker News, защищая изменение лицензии. Он пытался восстановить доверие.
Сообщество уже двинулось дальше без него.
Redis построил 15 лет доверия в open source. Проверил его один раз. Потерял за 8 дней.
В open source сообщество — это не просто пользователи. Сообщество — это ров.
👉 Java Portal
Kafka в event-driven архитектурах: 5 ключевых паттернов
Большинство разработчиков знают Kafka как систему обмена сообщениями, но мало кто действительно понимает, как использовать всю её мощь в event-driven архитектурах.
Kafka — это не просто продюсирование и потребление сообщений. Это основа масштабируемых, отказоустойчивых и реально-временных систем, используемых крупнейшими компаниями мира.
Вот 5 ключевых паттернов Kafka, которые должен знать каждый инженер:
1. Централизованное управление логами — стримьте логи из нескольких приложений в Kafka для долгосрочного хранения и анализа.
2. Распределение данных в реальном времени — публикуйте данные для множества потребителей эффективно через pub/sub архитектуру Kafka.
3. Бесшовная репликация логов — обеспечивайте консистентность в распределённых системах через репликацию и воспроизведение изменений логов.
4. Многоступенчатая обработка событий — обрабатывайте потоки событий в несколько этапов для обнаружения паттернов и аналитики в реальном времени.
5. Продвинутая автоматизация workflow через события — автоматизируйте процессы, обнаруживая и анализируя паттерны событий в реальном времени.
Освоение этих паттернов поможет проектировать масштабируемые event-driven архитектуры для реальных приложений.
Сохраните этот пост для будущего. Поделитесь с теми, кто готовится к system design интервью или работает с event-driven системами.
👉 Java Portal
20 законов разработки, которые должен знать каждый инженер
1. Закон Галла: Работающая сложная система вырастает из работающей простой.
2. KISS: Делай проще. Всё остальное — оверхеад.
3. Закон Конвея: Компании проектируют системы, которые повторяют структуру их коммуникаций.
4. Закон Хайрума: У достаточно большого API уже неважно, что ты обещал в контракте. Кто-нибудь уже зависит от каждого observable-поведения твоей системы.
5. CAP-теорема: Выбери два: консистентность, доступность, устойчивость к разделению.
6. Закон Завински: Любая программа разрастается до тех пор, пока не научится читать почту.
7. Закон Брукса: Добавление людей в опаздывающий проект делает его ещё более поздним.
8. Эффект Рингельмана: Производительность каждого участника группы падает с ростом группы.
9. Закон Прайса: Половину работы делают квадратный корень от всех людей.
10. Эффект Даннинга — Крюгера: Новички переоценивают свои способности, эксперты — недооценивают.
11. Закон Хофштадтера: Всё занимает больше времени, чем ты планируешь, даже с учётом этого закона.
12. Закон Паркинсона: Работа расширяется, чтобы заполнить всё отведённое на неё время.
13. Закон Гудхарта: Когда метрика становится целью, она перестаёт быть хорошей метрикой.
14. Закон Гилба: Измерять неточно лучше, чем не измерять вообще.
15. Принцип Кнута: Забудь о микрооптимизациях в 97% случаев. Преждевременная оптимизация — корень всех зол.
16. Закон Амдала: Ускорение одной части системы ограничено долей времени, которое эта часть реально используется.
17. Закон Мёрфи: Если что-то может пойти не так, оно пойдёт не так.
18. Закон Постела: Будь консервативен в том, что отправляешь, и либерален в том, что принимаешь.
19. Закон Стерджена: 90% всего на свете — фигня.
20. Закон Каннингема: Лучший способ получить правильный ответ в интернете — не задать вопрос, а написать неправильный ответ.
👉 Java Portal
Исторический момент. Новый HTTP-метод в стандарте.
QUERY. Альтернатива GET и POST.
Как GET — не меняет состояние ресурса. Как POST — можно использовать тело запроса. Шлёшь JSON, кешируешь ответ.
Только что повышен до Proposed Standard.
👉 Java Portal
Java: Начиная с Java 8, отдавайте предпочтение
java.time вместо Date и Calendar.
API из java.time неизменяемые (immutable), потокобезопасные (thread-safe) и намного понятнее в использовании.
Преимущества:
LocalDate.of(2026, 5, 31) — май действительно означает май.
Нет изменяемых объектов, которые легко случайно испортить.
Форматтеры из DateTimeFormatter потокобезопасны.
Удобная работа с часовыми поясами через ZonedDateTime.
Более читаемый и предсказуемый код.
Вместо:
Date Calendar SimpleDateFormatИспользуйте:
LocalDate LocalDateTime ZonedDateTime Instant DateTimeFormatterКод становится проще, а количество ошибок с датами и временем заметно уменьшается. 👉 Java Portal
Твой Java-проект в Claude Code не должен каждый раз стартовать с пустого промпта.
claude-code-java — это готовая рабочая область для Java-разработчиков. Внутри навыки, шаблоны, MCP-конфиг и скрипты для настройки. Всё, что нужно для типичной Java-работы.
Он делает Claude Code одинаково полезным в любом проекте. Подсовывает структурированные markdown-скиллы для код-ревью, тестов, коммитов, архитектурных решений и работы с Maven.
Что внутри:
- 18 навыков для Java: код-ревью, архитектура, Spring Boot, JPA, Maven, безопасность, логирование
- Быстрый старт через setup-project.sh — создаёт .claude/, привязывает навыки, генерирует CLAUDE.md
- Можно брать по одному навыку, выборочно или сразу всё
- В комплекте шаблоны CLAUDE.md, MCP-конфиг, настройки
- README подсказывает, как подключить те же навыки к автоматическому PR-ревью
Открытый исходный код под MIT.
👉 Java Portal
+1
Горутины и виртуальные треды. Слева Go с горутинами, справа Java с виртуальными потоками. Оба создают миллион задач.
Забавно наблюдать, как одни и те же люди твердят, что язык справа медленный и многословный, а язык слева бесконечно лучше. А на деле оба справляются с одним и тем же объёмом. Просто каждый по-своему.
👉 Java Portal
Что нового в PostgreSQL 19?
PostgreSQL 19 продолжает одну важную тенденцию. Postgres превращается во что-то гораздо большее, чем просто реляционная база.
Самые интересные новинки:
Графовые запросы через SQL/PGQ
PostgreSQL 19 научился выполнять SQL Property Graph Queries. Теперь можно запрашивать связи прямо на SQL, без отдельной графовой базы. Пригодится для соцсетей, рекомендаций, поиска мошенничества и графов зависимостей.
GROUP BY ALL
Вместо того чтобы перечислять все колонки в GROUP BY, пишешь GROUP BY ALL. Postgres сам группирует по неагрегатным колонкам. Меньше шаблонного кода, меньше ошибок.
WAIT FOR LSN
Фича для приложений, которые используют реплики чтения. Позволяет подождать, пока реплика догонит основную базу, прежде чем читать данные. Полезно для консистентности «прочитал то, что написал».
Лучшая поддержка JSON
Postgres и дальше улучшает работу с полуструктурированными данными, не теряя при этом SQL, индексы, соединения и транзакции.
PostgreSQL 19 пока в бете. Детали могут поменяться к релизу. Но направление понятно. Postgres потихоньку становится одной платформой под всё: реляционные данные, документы, графы, аналитика и векторы для AI.
👉 Java Portal
AI-инструменты можно любить и ненавидеть, но работать без них в IT уже практически невозможно 🤩
Коллеги из AvitoTech 11 июля зовут в их офис на Лесной на AI Hardcore Day. Приглашают тех, кто каждый день сталкивается с AI в работе и даже пишет своих AI-агентов. Обещают доклады и нетворкинг-сессию на террасе после — и всё это без записи.
💫 Среди тем:
— Spec-Driven Development: теория, инструменты, практика.
— Разработка и тестирование MCP для внутренних агентных систем аналитики.
— Выпрямляем руки агентов: как сделать MCP удобными и действительно полезными.
— Атаки на GenAI-агентов: OWASP на практике.
➡ Регистрация тут!
Java Tip: Не перегружайте методы параметрами
Если метод принимает слишком много аргументов, возрастает риск передать значения в неправильном порядке, а код становится сложнее читать и поддерживать.
❌ Плохо:
createUser(firstName, lastName, street, city, zip, country);createUser(firstName, lastName,
new Address(street, city, zip, country));
Docker-ошибка, которую я вижу почти в каждом junior Dockerfile:
COPY . .
RUN npm installCOPY package*.json ./
RUN npm install
COPY . .COPY . . ломает кэш, и всё после него (включая npm install) пересобирается с нуля при каждой сборке
если поменять порядок, слой с установкой зависимостей остаётся в кэше даже при изменении кода, потому что он зависит только от package.json
одна перестановка строк. экономит 40+ секунд на каждой пересборке. кэшируй зависимости, а не код.
👉 Java Portal