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

Самая большая слабость JWT — его гибкость. PASETO устраняет её. Спецификация JWT позволяет токену самому указывать, какой алгоритм использовать. Это единственное дизайнерское решение стоит за большинством проблем с JWT в продакшене. Вот что PASETO делает иначе. 1. Атака живёт в заголовке JWT содержит поле alg, которое указывает свой же алгоритм подписи. Вы можете установить его в "none", и некоторые библиотеки пропустят проверку. Или взять публичный RSA-ключ, использовать его как HMAC-секрет, подписать через HS256 — и сервер, доверяющий заголовку, примет поддельный токен. Это атака RS256→HS256 confusion, и она до сих пор ломает реальные системы. 2. PASETO привязывает криптографию к версии Токен PASETO имеет формат version.purpose.payload. Версия фиксирует набор шифров — нечего согласовывать. v4.public — всегда Ed25519. v4.local — всегда XChaCha20 с BLAKE2b. Нет заголовка alg — нет атаки alg:none и confusion-атак. 3. Вы выбираете назначение, а не алгоритм Локальный токен (local) зашифрован симметричным ключом. Публичный токен (public) подписан так, что любой с публичным ключом может его проверить. Стандартный JWT только подписан — payload читается как обычный base64, и секреты утекают, когда люди забывают об этом. 4. Для сессий не нужно ни то, ни другое JWT безопасны только как короткоживущие токены — минуты, а не недели, на которые тянется сессия. Google делает именно так: JWT используется только для передачи логина между хостами, а сессия в браузере остаётся кукой. PASETO — лучший выбор для короткоживущего подписанного токена: SSO-переходы, межсервисные вызовы, одноразовое использование. Для сессий проще кука, подкреплённая Postgres или Redis, а отзыв одной сессии — это удаление одной строки. Большинство логинов хватаются за токен там, где подошла бы сессия. https://gist.github.com/samsch/0d1f3d3b4745d778f78b230cf6061452 👉 Java Portal

Почему используется 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

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;
}

#SpringBoot #JavaDev 👉 Java Portal

Появился проект 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

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

Горутины и виртуальные треды. Слева 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));

Такой подход: • делает сигнатуры методов компактнее • упрощает расширение модели данных • снижает вероятность ошибок при вызове • делает код более понятным и самодокументируемым Если несколько параметров всегда используются вместе — вероятно, им нужен собственный класс или record. #Java #Refactoring #CleanCode 👉 Java Portal