12073
Присоединяйтесь к нашему каналу и погрузитесь в мир для Java-разработчика Связь: @devmangx РКН: https://clck.ru/3H4WUg
11 принципов разработки ПО, которые стоило понять гораздо раньше.
1. SOLID — более качественное объектно-ориентированное проектирование
2. DRY — не повторяйся
3. KISS — не усложняй
4. YAGNI — не реализуй то, что пока не нужно
5. SRP — одна ответственность
6. Open/Closed — расширяй, не ломая существующее
7. Dependency Inversion — уменьшай связанность
8. Composition — собирай систему из гибких компонентов
9. Separation of Concerns — разделяй ответственность между частями системы
10. Fail Fast — обнаруживай проблемы как можно раньше
11. Measure First — оптимизируй только то, что действительно имеет значение
👉 Java Portal
Переименование поля в API изнутри кажется безобидным. Снаружи оно может положить каждый дашборд, который рассчитывал на старое имя.
Любое изменение API попадает в одну из двух категорий, и от этого зависит всё.
Если изменение ломающее, нужно поднимать версию: удаление или переименование полей, добавление обязательных параметров или фундаментальное изменение поведения эндпоинта.
Безопасные изменения можно выпускать без новой версии: добавлять необязательные поля, новые эндпоинты или просто ускорять работу.
Большая часть боли появляется из-за двух противоположных ошибок. Не версионировать вообще — и каждый релиз превращается для пользователей в лотерею. Версионировать всё подряд — и в итоге вы поддерживаете пять версий, а разработчики уже не понимают, какую использовать.
Несколько простых правил помогают держать баланс:
— Показывайте версию явно, например /v1/ в URL, как это делают Stripe и GitHub.
— Используйте семантическое версионирование, чтобы смена мажорной версии сразу означала необходимость изменений в клиентском коде.
— Если версия выводится из эксплуатации, говорите об этом прямо в ответе через заголовок Sunset и давайте 6–12 месяцев на миграцию.
Версия API — это обещание о том, что не изменится.
Нарушать его нужно редко и громко. Никогда — молча.
Какую ошибку вы встречали чаще?
👉 Java Portal
Сопоставление с образцом для instanceof: переменную можно объявить прямо в проверке.
Старый подход: сначала instanceof, затем отдельное приведение типа.
Новый подход: if (obj instanceof Dog d) — переменная d сразу готова к использованию.
При этом d существует только там, где условие проверки истинно.
#Java #PatternMatching
👉 Java Portal
Ещё один отличный плейлист по структурам данных и алгоритмам от pmavrin.
https://youtube.com/playlist?list=PLrS21S1jm43igE57Ye_edwds_iL7ZOAG4&si=4mS5lXn3uxI-V2LM
👉 Java Portal
Типы классов в Java:
1. Concrete Class — обычный класс с полной реализацией методов.
2. Abstract Class — нельзя создать напрямую через new; может содержать абстрактные методы.
3. Final Class — нельзя наследовать.
4. Static Nested Class — статический вложенный класс внутри другого класса.
5. Inner Class — нестатический класс внутри другого класса.
6. Local Class — класс, объявленный внутри метода или другого блока.
7. Anonymous Class — класс без имени, обычно используется для одноразовой реализации.
8. Singleton Class — класс, спроектированный так, чтобы существовал только один его экземпляр.
9. POJO — простой Java-класс без специальных требований к наследованию или фреймворкам.
10. Record Class — компактная форма класса для хранения данных; появилась как предварительная возможность в Java 14.
11. Enum Class — класс, представляющий фиксированный набор констант.
👉 Java Portal
Spring Boot 4: теперь лучше использовать RestTestClient вместо TestRestTemplate.
У него более удобный API в стиле RestClient, он работает как с MockMvc, так и с реальным портом приложения.
При необходимости добавьте @AutoConfigureRestTestClient.
#SpringBoot4 #RestTestClient
👉 Java Portal
Используйте Collectors.summarizingInt(), чтобы за один проход получить количество элементов, сумму, минимум, максимум и среднее значение.
Так не придётся несколько раз прогонять один и тот же поток данных.
Метод возвращает объект IntSummaryStatistics.
Для long и double есть аналогичные методы: summarizingLong() и summarizingDouble().
#Java #Streams
👉 Java Portal
Spring Boot 4: проверка null-safety через JSpecify.
Более понятные контракты @Nullable / @NonNull.
Лучший статический анализ в IDE.
#SpringBoot4 #JSpecify
👉 Java Portal
Тюнинг производительности Spring Boot.
https://vladmihalcea.com/spring-boot-performance-tuning/
👉 Java Portal
Уже очевидно, что ВАЙБКОДИНГ — главный навык ближайших лет
Посмотрите сами. ИИ уже забирает на себя работу целых команд: пишет код, закрывает задачи джунов и позволяет стартапам запускать продукты в 2–3 раза меньшим составом. То, на что раньше нужны были несколько разработчиков, сегодня всё чаще делает один человек с ИИ-агентами.
И это только начало. Те, кто освоит вайбкодинг сейчас, смогут быстрее запускать проекты, автоматизировать огромный объём работы, увереннее конкурировать на рынке и зарабатывать больше тех, кто продолжает делать всё вручную.
Начать с нуля поможет канал Вайб-кодинг. Там ребята круглосуточно мониторят более 320 российских и зарубежных источников и публикуют только главное: релизы, инструменты, гайды, курсы и практические кейсы.
Подписывайтесь, нас уже 50 тысяч: @vibecoding_tg
В Spring Boot 4 больше нет поддержки Undertow — теперь рекомендуется использовать Tomcat или Jetty.
Что изменилось:
* Undertow несовместим с Servlet 6.1.
* Вместо starter-undertow используйте Tomcat (по умолчанию) или Jetty.
* Не разворачивайте приложения на Spring Boot 4 в старых сервлет-контейнерах.
👉 Java Portal
MIT 6.824 (распределённые системы) — один из лучших бесплатных инженерных курсов в интернете.
Вместо чистой теории весь курс построен вокруг чтения и разбора фундаментальных работ из реальных систем:
GFS (Google File System) — архитектура с одним главным узлом, распределение чанков и работа с eventual consistency при больших нагрузках на добавление данных.
Raft — выбор лидера, репликация журнала и инварианты безопасности. Алгоритм разбирается намного доступнее, чем Paxos.
ZooKeeper — координация без блокировок, системы с преобладанием чтения, линейно согласованные записи и eventual consistency для чтений через watches.
Spanner — глобально распределённые транзакции, двухфазный commit поверх Paxos и использование TrueTime (атомные часы + GPS) для обеспечения внешней согласованности.
Также в курсе разбираются MapReduce, Spark, Frangipani, Memcached от Facebook и другие системы.
Если хотите выйти за пределы поверхностного system design и понять, как внутри устроены реальные распределённые хранилища и системы консенсуса, этот курс — настоящий клад.
Плейлист: https://youtube.com/playlist?list=PLrw6a1wE39_tb2fErI4-WkMbsvGQk9_UB
👉 Java Portal
Хотите разобраться в алгоритмах поиска и сортировки на Java?
Этот подробный курс научит эффективно искать данные и сортировать массивы с помощью самых важных алгоритмов информатики.
Он подойдёт как тем, кто только начинает изучать Java, так и тем, кто готовится к экзаменам. Вы поймёте, как работают эти алгоритмы и как пошагово отслеживать их выполнение.
https://social.ora.cl/6011BEIoOf
👉 Java Portal
💡 В Spring Boot 4 изменилось имя настройки, отвечающей за включение трассировки.
✅ management.tracing.enabled → management.tracing.export.enabled
✅ @ConditionalOnEnabledTracing → @ConditionalOnEnabledTracingExport
#SpringBoot4 #Observability
👉 Java Portal
Используйте ReentrantReadWriteLock, когда операций чтения много, а записи происходят редко.
✅ Несколько потоков могут одновременно удерживать блокировку чтения
✅ Для записи требуется эксклюзивная блокировка
✅ При преобладании чтения пропускная способность выше, чем с одной эксклюзивной блокировкой
#Java #Concurrency
👉 Java Portal
Валидатор загрузки связей в JPA
В статье показано, как программно проверять, каким образом JPA и Hibernate загружают связанные сущности — через JOIN или отдельными дополнительными запросами.
Проблема особенно заметна с FetchType.EAGER. Например, @ManyToOne и @OneToOne используют его по умолчанию, из-за чего Hibernate может незаметно генерировать дополнительные запросы и приводить к классической проблеме N+1.
Автор строит собственный валидатор поверх механизмов Hibernate Statistics и Event Listeners. Он позволяет прямо в тестах определить
→ какие связанные сущности были загружены
→ какие пришли через дополнительные SQL-запросы
→ какие были получены через JOIN
Например, можно проверить, что запрос неожиданно загрузил две PostComment отдельными запросами и ещё один Post через JOIN. После замены запроса на JOIN FETCH валидатор подтверждает, что дополнительные SQL-запросы исчезли.
По сути, это способ ловить проблемы со стратегией загрузки и N+1 ещё на уровне тестов, до того как они попадут в продакшен.
https://vladmihalcea.com/jpa-association-fetching-validator/
👉 Java Portal
Интеграционное тестирование базы данных с помощью Testcontainers
https://vladmihalcea.com/testcontainers-database-integration-testing/
👉 Java Portal
Предсказание ветвлений всплывает снова и снова, потому что его влияние на производительность действительно огромное. Эту тему стоит понимать глубже.
У BitLemonSw как раз вышло новое видео о том, как работает предсказание ветвлений в современных процессорах.
Суть простая. В коде постоянно встречаются ветвления: циклы, if, switch/case, вызовы функций и возвраты.
Проблема в том, что процессоры работают конвейерно и не могут каждый раз ждать, пока станет известно, по какой ветке пойдёт выполнение. Иначе это сильно тормозило бы процессор.
Поэтому процессор заранее угадывает результат ветвления и продолжает загружать инструкции по предполагаемому пути. Если прогноз оказался верным — всё быстро. Если нет — часть работы приходится выбросить и начать заново.
https://youtu.be/UbDIoNY9E0w
👉 Java Portal
90% PostgreSQL в 2026 году сводится к этим 10 вещам. Всё остальное — в основном споры об расширениях.
1. MVCC + VACUUM
Обновления создают мёртвые строки. Если autovacuum настроен плохо, таблицы и индексы раздуваются, а задержки постепенно растут неделями.
2. Индексы под реальные сценарии запросов
Порядок колонок в составных индексах важен. Нужно понимать частичные и покрывающие индексы, а также почему ORM иногда незаметно приводит к полному сканированию таблицы.
3. Блокировки и DDLALTER TABLE может заблокировать запись. Важно понимать режимы блокировок, очереди и безопасные приёмы вроде CREATE INDEX CONCURRENTLY и обновления данных небольшими партиями.
4. Уровни изоляции и аномалииRead Committed, Repeatable Read, Serializable. Пропавшие или дублирующиеся строки часто нужно разбирать через конкурентные транзакции, а не искать проблему только в коде.
5. Управление соединениями
Слишком много соединений убивает CPU и память. Нужны PgBouncer, адекватные размеры пулов и контроль долгих транзакций в состоянии idle in transaction.
6. WAL, checkpoints и репликация
Объём WAL напрямую влияет на ввод-вывод. Плохие настройки checkpoints вызывают скачки задержек, а отставание реплик ломает чтение с реплик и делает переключение при сбое рискованным.
7. Основы планировщика запросовEXPLAIN (ANALYZE, BUFFERS) — ваш отладчик. Нужно понимать оценки количества строк, типы JOIN и когда требуется ANALYZE или расширенная статистика.
8. Наблюдаемость, привязанная к реальным сбоям
Следите за p95 задержкой, ожиданием блокировок, временными файлами, попаданиями в кэш, отставанием autovacuum и реплик. Добавьте журнал медленных запросов с нормальными порогами.
9. Резервные копии и проверка восстановления
Базовые бэкапы плюс архивирование WAL — минимум. Главная ошибка — никогда не проверять восстановление и уже во время аварии выяснить, что не хватает ролей, расширений или восстановление занимает слишком долго.
10. Безопасность и права
Минимально необходимые права, отдельные владельцы объектов, никакого superuser у приложения, регулярная смена учётных данных, ограничение сетевого доступа и закрытая на запись схема public в production.
👉 Java Portal
Как настроить JPA и Hibernate в Spring Petclinic с помощью Hypersistence Optimizer:
https://vladmihalcea.com/spring-petclinic-hypersistence-optimizer/
👉 Java Portal
Чувак декомпилировал Java-игру, чтобы посмотреть, как она устроена внутри.
На выходе получил полностью обфусцированный код: вместо нормальных имён — $$1, $$2 и прочий мусор. Для человека разбирать такое вручную — боль.
Но для LLM это почти идеальная задача. Она довольно быстро восстанавливает смысл кода, понимает связи между классами и объясняет, что именно происходит.
Такие задачи идеал для ИИ.
👉 Java Portal
Если достаточно долго работать с базами данных, рано или поздно столкнёшься с проблемами подключений или параллелизма.
В такой ситуации не стоит просто повышать лимиты в конфигурации. Лучше разобраться в архитектуре, чтобы понимать, почему это происходит и как исправить проблему оптимальным способом.
Эта статья от гениального человека — отличный разбор управления подключениями в Postgres и возможных решений.
Легко свести всё к особенностям Postgres с отдельным процессом на каждое соединение, но похожие проблемы могут возникать и в других базах данных, включая MySQL.
Часто ответ кроется в пуле подключений, но и он добавляет свою сложность, которую тоже важно понимать.
Статье уже 8 лет, но для Postgres она остаётся актуальной и в 2026 году.
Ссылка ниже.
https://brandur.org/postgres-connections
👉 Java Portal
JetBrains переносит возможности IntelliJ IDEA в другие редакторы.
Новое расширение Java & Kotlin by IntelliJ IDEA уже доступно в предварительной версии для VS Code и всех его форков, включая Cursor и Antigravity.
Возможности IntelliJ IDEA — теперь в любом редакторе, где вы работаете. 🙂↔️
👉 Java Portal
SELECT FOR UPDATE в PostgreSQL на самом деле выполняет запись.
На heap-странице Postgres у каждого tuple есть заголовок с метаданными этой записи.
Когда транзакция выполняет SELECT FOR UPDATE, у найденных строк обновляется заголовок: они помечаются как заблокированные, а в xmax записывается идентификатор транзакции, которая установила блокировку.
В частности, в заголовке infomask выставляются два бита:HEAP_XMAX_EXCL_LOCK и HEAP_XMAX_LOCK_ONLY.
Из-за этого страница становится dirty, а изменение также попадает в WAL. Позже WAL может быть отправлен на standby-реплику.
Сама dirty-страница затем может быть сброшена на диск фоновым процессом.
После коммита блокировка снимается.
Забавно, что операция чтения в итоге может вызвать целую цепочку операций записи на диск.
раться с новой возможностью.
👉 Java Portal
Лучшие инженеры не изучают распределённые системы по поверхностным пересказам. Они сразу обращаются к фундаментальным научным статьям. Чтение таких работ помогает понять, почему системы спроектированы именно так, а не просто научиться ими пользоваться.
Вот пять классических статей всех времён, которые должен прочитать каждый разработчик.
1. The Google File System (2003)
Почему стоит прочитать: статья изменила подход всей индустрии, предложив считать отказ компонентов нормой, а не исключением. В ней описано, как построить масштабную отказоустойчивую распределённую систему хранения данных на базе недорогого массового оборудования, оптимизировав её под интенсивную последовательную дозапись вместо произвольной записи.
Ссылка: https://static.googleusercontent.com/media/research.google.com/en//archive/gfs-sosp2003.pdf
2. Dynamo: Amazon’s Highly Available Key-Value Store (2007)
Почему стоит прочитать: исчерпывающий разбор того, как пожертвовать согласованностью ради высокой доступности — AP в теореме CAP. В статье изложены ключевые паттерны, лежащие в основе масштабируемых NoSQL-хранилищ: консистентное хеширование, векторные часы, gossip-протоколы и настраиваемый кворум для операций чтения и записи.
Ссылка: https://allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf
3. In Search of an Understandable Consensus Algorithm (Raft) (2014)
Почему стоит прочитать: Paxos печально известен тем, насколько сложно его понять и корректно реализовать, тогда как Raft делает концепцию реплицируемых конечных автоматов более доступной. Алгоритм разбивает задачу консенсуса на отдельные подзадачи, которые легко анализировать: выбор лидера, репликацию журнала и обеспечение безопасности.
Ссылка: https://raft.github.io/raft.pdf
4. Spanner: Google’s Globally-Distributed Database (2012)
Почему стоит прочитать: статья показывает, как добиться строгой сериализуемости и внешней согласованности между дата-центрами по всему миру. Секрет — API Google TrueTime, ограничивающий неопределённость времени с помощью синхронизированных GPS-приёмников и атомных часов.
Ссылка: https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf
5. Time, Clocks, and the Ordering of Events in a Distributed System
Почему стоит прочитать: на физическое время нельзя полагаться при работе с независимыми узлами. Лэмпорт вводит логические часы и фундаментальное отношение «произошло до» (happened-before), лежащее в основе упорядочивания событий в современных распределённых сетях.
Ссылка: https://amturing.acm.org/p558-lamport.pdf
👉 Java Portal
Используйте Files.isSameFile(a, b), чтобы проверить, указывают ли два пути на один и тот же файл.
✅ Path.equals сравнивает только текстовое представление пути.
✅ isSameFile проверяет реальный файл и учитывает симлинки.
#Java #Files
👉 Java Portal
Spring Boot 4: чтобы перенести ключи конфигурации, временно используйте properties-migrator как помощник.
✅ При запуске и в логах он показывает, какие ключи устарели.
✅ Обновите ключи, затем удалите зависимость.
#SpringBoot4 #Migration
👉 Java Portal
Если вы присваиваете переменной значение, полученное из её текущего значения с применением арифметической операции, можно использовать оператор составного присваивания.
Подробнее об операторе составного присваивания: https://social.ora.cl/6018BDGLH0
👉 Java Portal
Большинство проблем с производительностью упираются в то, как вы работаете с памятью.
И эта статья до сих пор остаётся одним из лучших материалов по теме:
• Как на самом деле работает оперативная память
• Кеши процессора и почему от них так сильно зависит производительность
• Практические методы оптимизации
• Инструменты для измерения того, что реально происходит в системе
Автор — Ульрих Дреппер из Red Hat.
Материалу почти 20 лет, но он до сих пор актуален.
Доступно бесплатно:
https://people.freebsd.org/~lstewart/articles/cpumemory.pdf
👉 Java Portal
Клиентское кэширование в HTTP работает так
Сервер может отдавать два типа ресурсов — статические и динамические. Статические данные не меняются между запросами, поэтому их можно кэшировать на стороне клиента с помощью специальных HTTP-заголовков.
Когда клиент впервые делает GET-запрос к ресурсу, локальный кэш проверяет его наличие. Если ресурса нет, запрос уходит на сервер. Сервер в ответе указывает, что данные можно закэшировать -> заголовок Cache-Control задаёт время жизни ресурса, а ETag определяет его конкретную версию. Кэш сохраняет ответ и возвращает его клиенту.
При повторном запросе, если ресурс ещё актуален, кэш сразу отдаёт его клиенту, минуя сервер. Однако сервер может обновить ресурс до истечения срока жизни в кеше, поэтому данные в кеше и на сервере не всегда строго согласованы. Обычно это приемлемо, а чтобы гарантировать обновление, сервер просто меняет версию ресурса.
Если ресурс в кеше устарел, кэш отправляет новый запрос на сервер с условным заголовком, например If-None-Match, где указывает сохранённую версию. Если сервер имеет новую версию, он возвращает её. Если изменений не было, он отвечает кодом 304 Not Modified, и клиент продолжает использовать локальные данные.
👉 Java Portal