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

Путаешь Dockerfile и Docker Compose? Тогда вот короткое пояснение. Они дополняют друг друга, но выполняют разные задачи в контейнерной инфраструктуре. Dockerfile используется для создания и сборки Docker-образов. Docker Compose используется для запуска контейнеров как части многоконтейнерной среды или с заданными параметрами выполнения. Примечание. Начиная с версии 1.28.6, Docker Compose по умолчанию ищет compose.yaml или compose.yml, но сохраняет обратную совместимость с docker-compose.yaml/yml. Если в проекте есть оба варианта, приоритет у compose.yaml. Прикрепил простую визуализацию, чтобы было легче разобраться. 👉 Java Portal

Java хотела добавить лямбды, но при этом не поломать JVM и не переписывать двадцатилетние API. Решение? Сделать вид, что в Java есть функции первого класса, используя то, что уже было: интерфейсы с единственным абстрактным методом. Так появились функциональные интерфейсы.

@FunctionalInterface
interface Operation {
    int apply(int x, int y);
}

Operation add = (a, b) -> a + b;

System.out.println(add.apply(3, 4)); // 7

Кажется, что ты передаешь функцию... но нет. Компилятор создаёт экземпляр Operation. В Java нет "свободных" функций, как в JavaScript или Kotlin. Сейчас это используется даже со старыми классами языка. Например, Runnable существует ещё с Java 1.0 и содержит всего один метод run. Когда в Java 8 завезли лямбды, стало можно писать так:

new Thread(() -> System.out.println("Hello from a thread")).start();

И старый конструктор Thread(Runnable r) продолжил работать без изменения ни одной строки оригинального API. Именно это позволило не сломать экосистему и сохранить стабильность, за которую Java так ценят. 👉 Java Portal

В Java такое видел почти каждый: var user = new User("Jordy", "Colombia", 28, true, "admin"); Код компилируется, но никто не помнит, что означает каждый параметр (если только IDE не подсказывает). Порядок важен, значения путаются, а любое изменение превращается в клоунаду. Классический конструктор начинает убивать читаемость. От этого и спасает Builder:

var user = User.builder()
    .name("Jordy")
    .country("Colombia")
    .age(28)
    .active(true)
    .role("admin")
    .build();

Теперь код читается как нормальное предложение. Не нужно запоминать порядок, угадывать значения и зависеть от IDE. Назначение каждого поля видно сразу. Причем сам JDK в новых API давно использует этот подход, пример с HttpRequest:

HttpRequest request = HttpRequest.newBuilder()
    .uri(URI.create("url"))
    .GET()
    .build();

Смысл в том, что когда у объекта много параметров, простой конструктор перестает быть понятным и превращается в препятствие. Builder это не просто "красивый паттерн". Это инструмент, который делает код понятным, а создание объектов безопасным и предсказуемым. Создание объекта не должно выглядеть как угадывание параметров. 👉 Java Portal

Удаляйте ChatGPT. Вы не умеете им пользоваться. Большинство пользователей спамит в ИИ всякую чушь — просят рассказать анекдот, изливают душу и используют как Гугл. Российский тимлид OpenAI Вадим Петрич рассказывает в «Доктор GPT» как извлекать из нейронок максимум пользы. Это очень интересно: • ТОП №1 нейросеть, генерирующая видео без цензуры вообще • Готовые промты на все случаи жизни • Инсайды и разработки от китов индустрии Подпишитесь, с Доктором GPT нейронки станут инструментом роста, а не безделушкой: https://t.me/+K65EHRh_x_c2OTli

Хочешь избежать проблем, когда Cloudflare падает? Или когда La Liga блокирует твои страницы? Разработчик сделал open-source CLI, чтобы можно было легко отключать этот сервис в проектах за пару секунд.

$ npx disable-cloudflare@latest

👉 Java Portal

Почему Redis однопоточный (и почему из-за этого он быстрый) У тебя сервер на 32 ядра, а Redis грузит только одно. На вид неэффективно. Но при этом Redis остается одной из самых быстрых in-memory баз. Почему так? Основной bottleneck обычно не CPU Для типичных операций Redis вроде GET, SET, INCR CPU почти не тратится. В реальных условиях упираешься в другое: - пропускная способность сети (ответы клиентам) - пропускная способность памяти (RAM <--> CPU cache) - системные вызовы, TCP, epoll и другая возня ядра В таких условиях добавление потоков не дает прироста, потому что ограничение в другом. Почему мультипоточность сделала бы Redis медленнее? Если бы несколько потоков трогали одну область данных, понадобились бы:

Локи Чтобы безопасно читать или писать ключи. Ожидание блокировок добавляет задержки. Context Switching Переключение между 32 потоками сжигает ресурсы и ломает кэш-локальность. Cache Coherence Когда один поток обновляет данные, которые кэшировал другой, аппаратная часть должна инвалидировать кэши по ядрам.

Это создает "cache thrashing" и ест производительность. Во многих сценариях эти накладные расходы больше, чем сама работа Redis-команды. Секрет - однопоточный event loop Redis работает на неблокирующем event loop (epoll/kqueue). Он умеет держать тысячи соединений и обрабатывать только те сокеты, у которых есть данные. Плюсы: - без блокировок - предсказуемые задержки - строгий порядок операций - минимальный overhead Работая в памяти, один поток способен обработать сотни тысяч или даже миллионы команд в секунду. Но небольшая поправка = Redis не полностью однопоточный Redis однопоточен только в части, которая работает с данными. Остальное вынесено в фоновые потоки. ✔️Главный поток Выполняет команды и трогает dataset. ✔️BIO-потоки Для долгих задач: lazy delete (UNLINK) синхронизация AOF фоновые задачи модулей ✔️I/O threads (с версии Redis 6+) Для чтения запросов и отправки ответов по сети. При этом сами данные не трогаются, значит = без локов. Так Redis получает выгоду от распараллеливания, не ломая простоту и предсказуемость. Redis специально остается однопоточным в части доступа к данным, чтобы избежать локов, гонок и непредсказуемости. При этом дополнительные потоки используются там, где они реально помогают. В результате Redis часто обходится быстрее сложных многопоточных систем. 👉 Java Portal

Исәнмесез! Встречайте новый VK JT Meetup: ML + Java! 4 декабря VK приглашает ML-инженеров и Java-разработчиков Казани на офлайн-встречу. В программе: — Практические доклады от экспертов VK: управление облаком One-cloud, запуск генеративного поиска в мессенджере и выкатка RAG в прод — Два потока на выбор: нетворкинг с настольными играми или решение реальных кейсов от VK с призами Общайтесь с экспертами, находите лучшие решения и оставайтесь на афтепати: фуршет, нетворкинг, настолки и свободное общение. Только офлайн, в Big Twin Arena. 🎟 Участие бесплатное, регистрация на сайте.

Одна простая привычка, которая сильно упрощает поддержку Dockerfile, это сортировка многострочных списков пакетов по алфавиту. На первый взгляд мелочь, но влияние на читаемость и будущую поддержку заметное. Когда ставишь пакеты в многострочном apt-get install или apk add блоке, легко случайно добавить дубликат или пропустить что-то, что затерялось в середине списка. Алфавитная сортировка полностью снимает этот вопрос. Список можно быстро просканировать, сразу увидеть дубли и держать всё в едином стиле на разных окружениях. Плюс уменьшаются шумные диффы в код-ревью. Когда пакеты отсортированы, добавление или удаление одного пункта выглядит как аккуратное и предсказуемое изменение. Без сортировки маленькое обновление часто превращается в огромный diff, и ревью становится сложнее, чем должно быть. Этот подход особенно полезен, когда команда растёт. Несколько человек, трогающих один Dockerfile, не начинают перетасовывать строки под свой вкус или форматировать по-разному. Структура остаётся стабильной, и поддержка со временем становится проще. Небольшое улучшение, но на сотнях билдов оно экономит заметно нервов и времени. 👉 Java Portal

Только что выкатили демо, показывающее, почему Spring Data AOT реально важен для производительности. Перенос парсинга запросов из рантайма в стадию компиляции дает: - запуск приложения быстрее на 50–70% - ошибки в запросах ловятся до деплоя - SQL генерируется заранее на этапе сборки - всё готово для GraalVM Native Репозиторий: https://github.com/danvega/spring-data-aot 👉 Java Portal

12 рекомендаций по дизайну API для бэкенд-разработчиков (Их часто спрашивают на собеседованиях) 1. Понятные имена ресурсов

❌`GET /get-all-orders`  
✅`GET /orders`

2. Корректное использование HTTP-методов - POST /users — создать пользователя - GET /users/123 — получить пользователя - PUT /users/123 — заменить полностью - DELETE /users/123 — удалить 3. Идемпотентность Клиент отправляет:

POST /payments
Idempotency-Key: abc-123

Если запрос повторится, сервер должен вернуть тот же результат, не создавая операцию заново. 4. Версионирование API Рекомендуемый вариант — в URL:

GET /v1/products/42
GET /v2/products/42

5. Правильные статус-коды Если пользователь не найден:

❌ `200 OK { "error": "user not found" }`  
✅ `404 Not Found`

6. Пагинация Пример:

GET /articles?page=2&limit=50

Ответ должен содержать элементы 51–100. 7. Фильтрация и сортировка Пример:

GET /orders?status=shipped&sort=-created_at

8. Безопасность Использование JWT в заголовках:

Authorization: Bearer <token>

9. Rate limiting Например: 100 запросов в минуту. После превышения — вернуть:

429 Too Many Requests

10. Кэширование Запрос:

GET /blog/posts/123

Ответ содержит:

ETag: "abc"

Повторный запрос:

If-None-Match: "abc"

Если не изменилось — 304 Not Modified. 11. Документация Используй: - Swagger UI - OpenAPI Разработчики должны видеть схемы, параметры и иметь возможность тестировать запросы. 12. Быть прагматичным Иногда лучше так:

POST /auth/login

чем строго REST-подход:

POST /sessions

Хороший API читается как логичная, предсказуемая система и экономит время всем, кто с ним работает. 👉 Java Portal

25 золотых правил системного дизайна

1. Система с упором на чтение > Используй кэш (Redis/Memcached) для частых запросов вроде профилей пользователей 2. Низкая задержка > Используй кэш и CDN (Cloudflare), чтобы раздавать статику ближе к пользователю 3. Система с упором на запись > Используй Message Queue (Kafka) для буферизации большого объема записей (логи, аналитика) 4. ACID-требования > Используй SQL (PostgreSQL) для строгих транзакций вроде банковских операций 5. Неструктурированные данные > Используй NoSQL (MongoDB) для гибких схем, например каталогов товаров 6. Сложные медиа-ресурсы > Используй Blob Storage (AWS S3) для видео, изображений и больших файлов 7. Сложные предварительные расчёты > Используй Message Queue + Cache для асинхронной генерации контента (например ленты новостей) 8. Поиск при больших объемах данных > Используй Elasticsearch для полнотекстового поиска и автокомплита 9. Масштабирование SQL > Используй шардирование, чтобы разделить большие таблицы на несколько инстансов 10. Высокая доступность > Используй Load Balancer (NGINX) чтобы распределять трафик и избегать перегрузки 11. Глобальная доставка данных > Используй CDN для стабильного стриминга и раздачи контента по всему миру 12. Графовые данные > Используй Graph DB (Neo4j) для соцсетей, рекомендаций и связей между сущностями 13. Масштабирование компонентов > Используй горизонтальное масштабирование, а не просто апгрейд железа 14. Быстрые запросы к базе > Используй индексы на ключевых колонках вроде email или user_id 15. Пакетные задачи > Используй Batch Processing для отчётов, расчётов или периодических задач 16. Защита от злоупотреблений > Используй Rate Limiter, чтобы предотвращать DDoS и спам запросов к API 17. Доступ к микросервисам > Используй API Gateway для авторизации, маршрутизации и SSL-терминации 18. Единая точка отказа > Добавляй Redundancy (Active-Passive), чтобы сервис продолжал работать при сбоях 19. Отказоустойчивость данных > Используй репликацию (Master-Slave), чтобы данные не терялись при падении узлов 20. Реальное время > Используй WebSockets для чатов, лайв-обновлений, лайв-результатов 21. Обнаружение сбоев > Используй Heartbeat-пинг, чтобы проверять статус сервисов каждые несколько секунд 22. Целостность данных > Используй Checksums (MD5/SHA) чтобы проверить, что загруженные файлы не повреждены 23. Децентрализованное состояние > Используй Gossip Protocol, чтобы ноды обменивались статусами без центрального сервера 24. Эффективное кеширование > Используй Consistent Hashing, чтобы добавлять или убирать кэш-ноды без полного пересчёта ключей 25. Работа с геоданными > Используй Quadtree или Geohash для быстрых запросов вроде поиска ближайших водителей

👉 Java Portal

🔍 Завтра тестовое собеседование с Java-разработчиком 19 ноября(уже завтра!) в 19:00 по мск приходи онлайн на открытое собеседование, чтобы посмотреть на настоящее интервью на Middle Java-разработчика. Как это будет: 📂 Сергей Чамкин, старший разработчик из Uzum, ex-WildBerries, будет задавать реальные вопросы и задачи разработчику-добровольцу 📂 Cергей будет комментировать каждый ответ респондента, чтобы дать понять чего от вас ожидает собеседующий на интервью 📂 В конце можно будет задать любой вопрос Сергею Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для Java-разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы. Переходи в нашего бота, чтобы получить ссылку на эфир → @shortcut_sh_bot Реклама. О рекламодателе.

Spring Boot: на этапе разработки можно включить spring.main.lazy-initialization=true, чтобы ускорить запуск приложения. По умолчанию Spring Boot инициализирует все бины при старте. В среде разработки это приводит к: Более долгому старту приложения, особенно в крупных проектах Приходится ждать загрузки бинов, которые прямо сейчас даже не нужны Чтобы избежать этого, в application.properties укажите:

spring.main.lazy-initialization=true

Важно сохранить поведение по умолчанию в проде, потому что: Ошибки на старте выявляются раньше Все компоненты готовы принимать запросы сразу 👉 Java Portal

API VERSIONING позволяет разработчикам поддерживать несколько версий эндпоинтов веб-сервиса (например, /users или /products), не ломая интеграции у клиентов при внесении изменений. В новом Spring Boot 4 появилась встроенная поддержка версионирования API, и настраивается она очень просто. → Добавь строки в конфиг (application.properties) под твой сценарий. Можно использовать оба варианта одновременно — заголовки и query-параметры. 1 способ: версионирование через заголовок (Клиент передает версию в header, например: api-version: 1 — название заголовка можно выбрать любое)

spring.mvc.apiversion.use.header = api-version

2 способ: версионирование через query-параметр (Клиент передает версию в запросе, например: ?version=1)

spring.mvc.apiversion.use.query-parameter = version

→ Установка версии по умолчанию (Используется версия 1.0, если клиент ничего не указал)

spring.mvc.apiversion.default = 1.0

Примечание: если версия указана и в заголовке, и в query-параметре, то приоритет у более высокой версии. Например, header = 2, query = 1 → в итоге будет 2. Готово. a) Без множества контроллеров b) Без /v1/, /v2/ в URL c) Код чище и проще поддерживать 👉 Java Portal

Совет по Java: можно использовать Collectors.joining(", ") чтобы собрать Stream в строку с разделителем запятая (или любым другим, если нужно). Обычный способ:

List<String> items = List.of("a", "b", "c");
StringBuilder sb = new StringBuilder();
for (int i = 0; i < items.size(); i++) {
    sb.append(items.get(i));
    if (i < items.size() - 1) {
        sb.append(", ");
    }
}
System.out.println(sb.toString());

Через joining:

List<String> items = List.of("a", "b", "c");
String result = items.stream().collect(Collectors.joining(", "));
System.out.println(result.toString());

👉 Java Portal

Многие ненавидят Java не потому что язык плохой, а потому что первое знакомство с ним вышло травматичным. В универе его чаще всего преподавали на примерах из прошлого века, а преподаватели были больше заняты тем, чтобы сто раз написать public static void main, чем объяснить, почему всё устроено именно так. А ещё эта многословность, ошибки компиляции, необходимость сходу понимать классы, объекты, наследование… неудивительно, что после такой встречи у людей остаётся отвращение. Плюс порог входа у Java выше, чем у более дружелюбных языков вроде Python или JavaScript. И хотя это уже давно не тот тормозной тяжёлый язык из 2000-х, многие до сих пор думают о нем именно так, не замечая, что сегодня он работает почти во всех крупных системах. И тут самое забавное: пока в интернете его поливают грязью, компании всё так же активно ищут Java-разработчиков и платят им очень хорошие деньги. Потому что в реальном мире остаётся то, что работает и масштабируется. 👉 Java Portal

⚡️ На Stepik вышел курс по Linux Ребята сделали крутейший курс по Linux, где понятным языком, шаг за шагом, на реальных примерах и с наглядными схемами обучают работе с этой ОС Внутри 20+ модулей: от установки Linux и работы с файлами до сетей, прав, дисков, процессов, автоматизации на Bash и многого другого. Всё сразу закрепляется на практике (200+ заданий с автопроверкой). После прохождения вы получите сертификат, который можно добавить в резюме. Есть бесплатные демо-уроки для ознакомления. В ближайшие 48ч курс доступен со скидкой 25% по промокоду «LINUXTG25»: открыть курс на Stepik

IntelliJ IDEA начнет использовать JSpecify как основную null-safe библиотеку начиная с версии 2025.3. "Переход на JSpecify это хороший пример того, как совместная работа в экосистеме Java приводит не просто к очередному стандарту, а к тому, который реально приносит пользу разработчикам." 👉 Java Portal

Каким будет результат? 👉 Java Portal

Мы охотились за лишними 300 мс задержки в микросервисе. Думали, что это сборщик мусора в Java. Два дня крутили настройки JVM. Ноль эффекта. А настоящая проблема оказалась в git clone внутри init-контейнера. Сервис случайно настроили так, что он на каждом старте клонировал репозиторий ради одного конфиг-файла. Клонирование было медленным, но задержка терялась на фоне общего старта приложения. Сервис не тормозил - он просто постоянно перезапускался. Всегда проверяйте сайдкары и init-контейнеры раньше, чем лезете в логику приложения. 👉 Java Portal