Java Portal | Программирование
12K subscribers
1.43K photos
110 videos
43 files
1.45K links
Присоединяйтесь к нашему каналу и погрузитесь в мир для Java-разработчика

Связь: @devmangx

РКН: https://clck.ru/3H4WUg
Download Telegram
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
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
10😁2
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
Please open Telegram to view this post
VIEW IN TELEGRAM
7
Появился проект Build Mini-Kafka — практическое руководство, в котором предлагается с нуля реализовать упрощённую версию Apache Kafka и разобраться в её внутреннем устройстве.

В процессе разработки предстоит реализовать:

- журнал сообщений с моделью append-only и разбиением на партиции;
- выбор лидера на основе алгоритма Raft;
- отслеживание ISR (набора синхронизированных реплик) и продвижение high watermark;
- идемпотентных и транзакционных продюсеров;
- группы потребителей с автоматической перебалансировкой.

Проект ориентирован на изучение принципов работы распределённых брокеров сообщений и архитектуры Kafka через практическую реализацию, а не через теорию.

Ссылка: https://builddistributedsystem.com/projects/mini-kafka

👉 Java Portal
Please open Telegram to view this post
VIEW IN TELEGRAM
5🔥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;
}


#SpringBoot #JavaDev

👉 Java Portal
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
📌 Шпаргалка по API-заголовкам

Заголовки API несут метаданные, обеспечивающие безопасную и эффективную коммуникацию.

- Authorization — отправка токенов доступа безопасно
- Content-Type — определение формата тела запроса
- Accept — указание ожидаемого формата ответа
- User-Agent — идентификация клиентского приложения
- Cache-Control — управление кешированием
- Origin — поддержка валидации CORS
- Cookie — отправка информации о сессии
- Accept-Language — установка языковых предпочтений

Понимание заголовков API помогает создавать более быстрые, безопасные и надёжные приложения.

👉 Java Portal
Please open Telegram to view this post
VIEW IN TELEGRAM
1
Java совет : начиная с Java 14 можно использовать record для коротких неизменяемых объектов-носителей данных.

короче обычных POJO
автоматически есть equals(), hashCode(), toString()
объекты неизменяемые по умолчанию

👉 Java Portal
Please open Telegram to view this post
VIEW IN TELEGRAM
Как на самом деле работает Git
Большинство использует Git, не понимая, что происходит внутри.

Суть такая:
git init
создаёт папку, за которой Git начинает следить
git add
говоришь Git: «эти изменения пойдут в сохранение»
git commit
фиксирует снимок состояния проекта в этот момент
git push
отправляет эти снимки в облако (обычно GitHub)
git pull
забирает снимки, которые отправили другие
git branch
создаёт отдельную линию разработки, где можно работать изолированно
git merge
объединяет эту ветку обратно в основную

👉 Java Portal
Please open Telegram to view this post
VIEW IN TELEGRAM
👍61
Примитивные 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
Please open Telegram to view this post
VIEW IN TELEGRAM
5
Эволюция коммуникации между сервисами

Архитектура ПО кардинально изменилась за последние 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
Please open Telegram to view this post
VIEW IN TELEGRAM
Почему используется 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
Please open Telegram to view this post
VIEW IN TELEGRAM