Выражения switch в Java 14+ являются исчерпывающими (exhaustive): компилятор проверяет, что обработаны все возможные значения.

✅ Если пропустить константу enum, компиляция завершится ошибкой
✅ Исправить это можно, обработав все значения enum или добавив ветку default
✅ Более безопасный рефакторинг и меньше скрытых ошибок
#Java #JavaDev

👉 Java Portal

Правда или ложь?

1. HTTPS шифрует путь URL и query-параметры ❓
- Правда
При HTTPS шифруется весь HTTP-запрос, включая путь (/api/users) и query-параметры (?id=123). Исключение — доменное имя обычно видно через DNS и TLS-метаданные (если не используется ECH).

2. Транзакция в БД автоматически блокирует всю таблицу ❓
- Ложь
В большинстве современных СУБД используются строчные (row-level) или более гранулярные блокировки. Блокировка всей таблицы происходит лишь в некоторых сценариях.

3. Данные Redis теряются при перезапуске сервера ❓
- Ложь
Redis может сохранять данные через RDB-снимки и AOF-журналирование. Без настроенной персистентности данные действительно будут потеряны.

4. async/await в Node.js выполняет код параллельно ❓
- Ложь
async/await упрощает работу с асинхронным кодом, но само по себе не создаёт параллелизм. Оно лишь ожидает завершения Promise. Для реального параллельного выполнения нужно запускать несколько операций одновременно (например, через Promise.all()).

5. Ответ 304 Not Modified не содержит тела ❓
- Правда
Статус 304 Not Modified сообщает клиенту использовать закэшированную версию ресурса, поэтому тело ответа отсутствует.

6. Внешние ключи (Foreign Keys) улучшают производительность запросов ❓
- Ложь
Основная задача внешних ключей — обеспечение ссылочной целостности. Они не ускоряют запросы сами по себе. Более того, проверки FK могут добавлять накладные расходы при записи данных.

7. Docker-контейнеры используют общее ядро ОС хоста ❓
-Правда
Контейнеры изолированы через namespaces и cgroups, но используют одно и то же ядро хостовой системы.

8. JWT-токены по умолчанию зашифрованы ❓
- Ложь
Обычный JWT (JWS) подписан, но не зашифрован. Любой может декодировать его содержимое через Base64URL. Для шифрования используется JWE, но это отдельный механизм.

👉 Java Portal

Java: VarHandle можно использовать как более лёгкую альтернативу volatile. Это строго типизированная ссылка на переменную.

Когда две нити работают с одной и той же переменной, процессор может переупорядочивать операции и кэшировать записи. В результате одна нить обновляет значение, а другая продолжает видеть его старую версию.

#JavaDev

✅ volatile решает эту проблему, обеспечивая полную синхронизацию каждой операции чтения и записи. Это безопасно, но довольно затратно: такой уровень гарантий часто оказывается избыточным и медленнее, чем требуется на практике.

VarHandle предоставляет более гибкий и лёгкий механизм благодаря набору специализированных методов.
✅ setRelease — это операция «публикации» значения. Поток-записыватель говорит: «Я закончил. Всё, что я записал до этого момента, теперь безопасно для чтения другими потоками».
Это похоже на нажатие кнопки «Сохранить и опубликовать» для поста.

✅ getAcquire — это операция «подписки» на опубликованные данные.
Она означает: «Дай мне опубликованное значение, и вместе с ним я корректно увижу всё, что было записано до его публикации».
✅ setRelease и getAcquire работают в паре: если поток-читатель увидел флаг, записанный через setRelease, то он гарантированно увидит и все данные, которые были записаны до установки этого флага.
Это обеспечивает необходимую видимость данных между потоками без полной стоимости синхронизации, которую обычно накладывает volatile.

✅ setOpaque — самый дешёвый вариант. Подходит для сценариев с одним потоком-записывателем, когда нужно лишь сохранить порядок собственных операций записи без дополнительных гарантий синхронизации между потоками.
Главное: volatile предоставляет все эти гарантии сразу, но за более высокую цену. VarHandle позволяет выбрать только те гарантии видимости и упорядочивания памяти, которые действительно нужны в конкретном случае.
Демо на GitHub: https://github.com/mcasari/codingstrain/tree/main/x-posts-examples/java-varhandle-fences-demo

👉 Java Portal

Большинство разработчиков ни разу не открывали папку .git.
А именно там находится всё, что делает Git Gitом.

Git не является системой отслеживания изменений во времени. Git представляет собой content-addressable storage, построенное на основе направленного ациклического графа (DAG).

Все операции происходят внутри .git/objects/.
Git хеширует данные файлов и сохраняет их в виде четырёх типов объектов:

Blob → хранит только содержимое файла. Без имени файла, без пути. Два одинаковых файла в разных каталогах будут ссылаться на один и тот же blob.

Tree → хранит соответствие между именами файлов, правами доступа, путями и хешами blob-объектов или дочерних tree-объектов.

Commit → содержит ссылку на корневой tree-объект, а также информацию об авторе, временную метку и ссылку на родительский коммит.

Annotated Tag → содержит ссылку на коммит и собственные метаданные: имя автора тега, дату создания и сообщение тега.
Эти объекты образуют DAG:

Directed — дочерние объекты указывают на родительские.
Acyclic — ни один коммит не может ссылаться обратно на самого себя через цепочку связей.

Когда вы создаёте ветку, Git записывает один текстовый файл размером около 41 байта в:

.git/refs/heads/<имя-ветки>

Этот файл содержит:

40-символьный SHA-1 хеш
символ перевода строки в конце

Именно этот файл и представляет собой всю ветку.

Git не хранит файлы. Git хранит содержимое, связи между объектами и историю изменений.
Поймите устройство объектов Git. Освойте граф. Тогда станет понятно, как Git работает на самом деле.
#Git

👉 Java Portal

Hibernate & JPA Cheatsheet

👉 Java Portal

Java: избегайте магических чисел.

В Java магическим числом (Magic Number) называют жёстко заданное числовое значение, используемое в коде без какого-либо пояснения того, что именно оно обозначает.

Магические числа снижают читаемость кода и усложняют его сопровождение.

#JavaDev #CleanCode

👉 Java Portal

Почему Twelve-Factor App важен

Он описывает проверенные временем архитектурные паттерны и практики, которые можно применять к SaaS-приложениям. Эти подходы помогают создавать софт, который будет устойчивым и легко переносимым при деплое в онлайн-среду.

Двенадцать факторов:

I. Codebase
Одна кодовая база под управлением системы контроля версий, много окружений для деплоя

II. Dependencies
Явное объявление и изоляция зависимостей

III. Config
Хранение конфигурации в окружении

IV. Backing services
Внешние сервисы воспринимаются как подключаемые ресурсы

V. Build, release, run
Жёсткое разделение стадий сборки, релиза и запуска

VI. Processes
Приложение запускается как один или несколько Stateless-процессов

VII. Port binding
Экспорт сервисов через привязку к порту

VIII. Concurrency
Масштабирование через модель процессов

IX. Disposability
Максимальная надёжность за счёт быстрого старта и корректного завершения

X. Dev/prod parity
Минимизировать различия между dev, staging и production

XI. Logs
Логи рассматриваются как поток событий

XII. Admin processes
Админские задачи выполняются как одноразовые процессы

В книге Beyond the 12 Factor App Кевин Хоффман дополняет эти принципы новыми пунктами, включая телеметрию и безопасность:

- Один код, одно приложение
- API first
- Управление зависимостями
- Design, build, release, run
- Конфигурация, креды и код
- Логи
- Disposability
- Внешние сервисы
- Эквивалентность окружений
- Административные процессы
- Port binding
- Stateless-процессы
- Конкурентность
- Телеметрия
- Аутентификация и авторизация

👉 Java Portal

💡 Java: Удаляйте неиспользуемые импорты и переменные для повышения читаемости кода.

Лишние импорты и неиспользуемые переменные создают визуальный шум, усложняют навигацию по коду и затрудняют поддержку. Большинство IDE умеют автоматически находить и удалять такой код.

#Java #CleanCode

👉 Java Portal

Наткнулся на GitHub-репозиторий для изучения System Design - - - https://github.com/systemdesign42/system-design-academy

Внутри собраны материалы как для подготовки к собеседованиям, так и для понимания того, как устроены реальные системы.

Что есть:

• Основы System Design
• Базовые концепции AI Engineering
• Вопросы по System Design для собеседований
• Разборы архитектур реальных сервисов
• Упрощённые инженерные кейсы с визуализациями и схемами

Понравилось, что материал собран в одном месте и не требует прыгать между десятками статей, видео и блогов.

Хороший вариант для тех, кто хочет закрыть пробелы в архитектуре систем или подготовиться к design-интервью.

👉 Java Portal