Сегодня, 9 октября, состоится первый день конференции Java-разработчиков Joker 2024 в онлайн формате. Затем будут ещё два дня: 15 и 16 октября, в том числе и оффлайн в Питере.

На Joker ежегодно можно услышать самые разные доклады, полезные Java-разработчику: об использовании Spring Boot, работе JVM «под капотом», JVM-языках вроде Kotlin, backend-архитектуре и многом другом.

Если вы не успели или не смогли купить билет, то на первый день конференции можно зарегистрироваться совершенно бесплатно в рамках Community Day.

P.S. Я сам поеду в Питер и буду на конфе оба дня, поэтому если вдруг кто-то из подписчиков моего канала окажется на Joker - всегда рад пообщаться! Можете отмечаться здесь в комментах.

Я поработал немного над юзабилити онлайн-утилит на своём сайте и ко многим из них добавил кнопки копирования и очистки текстовых полей ввода. Вроде банальная вещь, но позволяет вместо трёх нажатий клавиши (выбрать поле, выделить весь текст в этом поле, затем Ctrl+C или Del) сделать всё в один клик. Также многие утилиты в текстовых полях по умолчанию содержат наглядный пример, призванный продемонстрировать работу данной утилиты.

Утилиты на сайте пригодятся прежде всего разработчикам. Например, base64, unix timestamp, форматирование json и xml.

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

А теперь немного занимательной статистики. В тройку наиболее популярных утилит входят генератор UUID (уникальные идентификаторы), url-encoder (если хотите передать текст как параметр в url) и number2text (сумма прописью - пригодится при оформлении договоров).

На тему инсайтов, которые посетили меня во время joker 2024, хочу привести доклад-дискуссию, который называется «Kubernetes, Grafana, Kibana и прочий смрадъ. Раньше было лучше».

Ребята говорят, что сейчас разработчики практически не задумываются над тем, насколько привычный им стек подходит под решение конкретных задач. Например, все мы, не задумываясь, делаем telegram-бот на spring boot, начинаем любой новый проект сразу с кучи микросервисов, заворачиваем все это в докер и кубер, обкладываем метриками и дашбордами, даже если пользователей у этого проекта 1,5 человека в сутки. Это приводит к раздуванию бюджета, сроков, серверных ресурсов и получается замкнутый круг.

Это всемирный заговор разработчиков, чтобы им было проще выбивать повышение зарплат? Или это карго-культ, когда вчерашний джун, не задумываясь, из проекта в проект повторяет один и тот же архитектурный паттерн? Или может просто раздутое эго разработчиков, что «вот мой внутренний проект тоже может быть хайлоадом, как у гигантов индустрии»?)

Другой инсайт, который возник у меня на Joker 2024 во время обмена опытом с коллегами. Уже довольно давно при создании репозиториев (если это не JPA), и сервисов в Spring, я всегда выделяю интерфейс. Даже если у него всего одна реализация.

Почему?
1. Потому что я так привык
2. В любой книге про паттерны вы встретите фразу о том, что "программировать надо на уровне интерфейсов, а не реализаций"
3. Если сервис занимает несколько экранов, бывает удобно посмотреть весь его публичный API на одном экране, просто зайдя в интерфейс.

Но есть и минусы:
1. Файлов становится в 2 раза больше без изменения функциональности.
2. Неудобная навигация в IDE (2 клика для перехода к реализации вместо одного).
3. Когда у нас нет интерфейса, Spring'у чуть проще находить бины.

Ну и я задумался, всегда ли эти плюсы перевешивают эти минусы? Например, навигацию приходится делать гораздо чаще, чем смотреть API целиком. Может, пришла пора пересмотреть практику обязательного выделения интерфейса?

А как принято делать у вас в команде?

С момента своего появления в Java 8 Stream API сделал работу с коллекциями гораздо удобнее. Помимо большого количества утилитарных методов, он разделил все операции над коллекциями на промежуточные и терминальные. Тем самым стримы привнесли также концепцию "ленивых" (отложенных) вычислений. Действительно, зачем обрабатывать миллион элементов исходной коллекции, если заранее известно, что на выходе всегда берутся только два?

Kotlin под капотом использует те же самые java-коллекции, а вот вместо стримов предлагает очень похожую концепцию Sequence.

Поэтому вы наверняка задавались вопросом: надо ли вообще использовать обычные коллекции, если стримы/сиквенсы в теории должны быть более производительными? Этим же вопросом задались авторы доклада Непоследовательные последовательности на Joker 2024. И вот к каким выводам они пришли.

Обычные коллекции на самом деле всегда выигрывают у стримов и сиквенсов, если количество преобразований (например, map) над каждым элементом коллекции меньше 20. Это происходит за счёт инлайнинга компилятором и оптимизаций во время выполнения. Но если у вас в каждом элементе слишком много объектов или если кол-во преобразований больше 20, то инлайнинг перестаёт работать и ленивые вычисления начинают давать заметный профит.

Если же сравнивать между собой стримы и сиквенсы, то последние устроены чуть проще, а потому слегка проигрывают стримам. Происходит это за счёт того, что стримы учитывают некоторые признаки (например, признак сортировки) от предыдущей операции. А потому выполняют чуть меньше преобразований.

А как работаете с коллекциями вы?

Недавно прочитал на Хабре статью под названием Ты — ненастоящий айтишник / Дедовщина в IT.

В ней обсуждается, что люди, давно работающие в IT, предвзято относятся к новичкам в профессии, особенно без профильного айтишного образования. Автор утверждает, что в IT появилась каста гейткиперов - самопровозглашённых экспертов, разделяющих людей на достойных и неугодных. В качестве доказательства своих взглядов они приводят тезисы о том, что IT - чуть ли не единственная сфера, где можно быстро начать получать комфортный доход без связей и нарушения закона. Поэтому в последние годы в эту сферу пытаются попасть все подряд.

Гейткиперы утверждают, что IT - это искусство, которым нужно заниматься с детства. Однако IT "давно демистифицировано" - это просто работа, не требующая глубоких технических знаний и чаще всего это просто "перекладывание" json'ов. Если раньше, лет 20 назад, во главу угла ставили фундаментальный бэкграунд, то сейчас работодатель в числе прочего смотрит, насколько хорошо разработчик умеет говорить на языке бизнеса и выгодно продавать свою экспертизу. Гейткиперы же этого делать не умеют и не хотят, а потому довольно естественно боятся конкуренции со стороны более молодых и амбициозных, но не имеющих такого бэкграунда.

Если хотите знать моё мнение, как человека, работающего в IT лет 15, думаю, что гейткиперы действительно существуют и их реакция на новичков вполне ожидаема. Способ найма и получения опыта сильно изменился за последнее десятилетие.

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

А как вы относитесь к гейткиперам? Сталкивались ли с ними на старте карьеры? Поделитесь в комментах своим опытом.

Меня периодически спрашивают в комментах на 📺 YouTube, почему не запускается тот или иной пример из github на последних версиях java.

Время не стоит на месте, поэтому пришла пора актуализировать некоторые старые статьи на моём сайте. Также я обновил примеры проектов, связанные с этими статьями.

Вот список последних обновлений.
Проекты адаптированы под 🌱 Spring Boot 3 и ☕️ Java 21:

➡️ Аудит изменений в Spring Data JPA (github)

➡️ Валидация бинов в Spring (новый проект на github)

➡️ Springdoc для документации REST API (github)


Также добавил 📗 новые разделы в существующие статьи:

➡️ Настройка Ubuntu под хостинг JVM приложения - раздел про переадресацию с www и http на https в nginx.

➡️ Алгоритм поиска чисел Фибоначчи - уже не первый раз дополняю её. На этот раз один из пользователей в комментариях предложил более эффективную реализацию рекурсивного алгоритма.

🧑‍💻 Всегда рад обратной связи! Поэтому пишите в комментах, если чего-то не хватает или что-то не работает.

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

Новые функции:

🟢 Теперь видео с 📺 YouTube можно смотреть прямо на странице статьи, не покидая её. Соответственно, кнопку-ссылку сверху справа я убрал.

🟢 В конце каждой 📗 статьи появился раздел "См. также" с наиболее похожими статьями. Сделано это для того, чтобы легче находить другие материалы из той же серии.


Обновления статей (переход на ☕️ Java 21 и 🌱 Spring Boot 3):

🟠 Кеширование в Spring Boot (github)

🟠 CrudRepository на Kotlin (github)

Продолжение следует...

Добавил на сайт новую утилиту для генерации Cron-выражений. Это выражение представляет собой расписание для запуска периодических задач.

Cron-выражение чаще всего состоит из нескольких цифр, разделённых пробелами, согласно схеме выше. Используется как в Unix системах, так и в различных фреймворках, таких как Spring (аннотация @Scheduled).

Формат их по большей части совпадает, однако в Unix используется 5 элементов (с точностью до минуты), а в Spring - 6 (с точностью до секунды).

Поскольку запомнить все правила формирования cron-выражений с первого раза нелегко, удобнее это сделать с помощью онлайн утилиты. Помимо генерации самого выражения, утилита также покажет даты ближайших срабатываний этого выражения относительно текущего времени.

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

Представляю вашему вниманию ещё одну новую утилиту! Она позволяет просматривать содержимое JWT-токена в человеко-читаемом виде.

JSON Web Token (JWT) - это открытый стандарт для создания токенов доступа, основанный на формате JSON. Используется для аутентификации в клиент-серверных приложениях.

Токен состоит из трёх частей:
1. заголовок с технической информацией о самом токене
2. основные данные (payload)
3. цифровая подпись

Чаще всего нас интересует именно вторая часть. В ней можно найти информацию о том, кто его выпустил, когда и до какой даты токен является валидным.

Поскольку в "сыром" виде токен представляет собой просто строку из букв и цифр, в целях отладки бывает полезно посмотреть, какая информация в нём содержится. Поэтому утилита может быть полезна разработчикам и QA-инженерам.

Что важнее: выразительность синтаксиса или простота поддержки?

Kotlin и Java — два популярных JVM-языка программирования, которые используются для разработки приложений. Оба языка имеют свои преимущества и недостатки, в том числе в плане выразительности.

С одной стороны, выразительность Kotlin — это его плюс. В Kotlin есть больше вариативности в написании кода, что позволяет разработчикам выбирать наиболее подходящий стиль и паттерны для решения задачи. Это может сделать код более читаемым и понятным, а также ускорить разработку.

С другой стороны, выразительность Kotlin — это и его минус. Большая вариативность может привести к тому, что разработчики будут использовать разные стили написания кода и нужно будет принимать общие соглашения на уровне команды и затем контролировать их выполнение.

Например, в Kotlin существует короткая форма записи для сигнатуры метода, когда возвращаемый тип автоматически выводится на основе возвращаемого значения.

// эти три формы записи эквивалентны
fun getMagicValue() = 42

fun getMagicValue(): Int = 42

fun getMagicValue(): Int {
    return 42
}

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

Или другой пример. В Kotlin наряду с try-catch есть конструкция runCatching, которая также позволяет обрабатывать исключения. То есть два разных стиля обработки исключения делают одно и то же.

runCatching {
   doSomething()
}.onFailure { e: Exception ->
   logger.error { e }
}

// то же самое
try {
   doSomething()
} catch (e: Exception) {
   logger.error { e }
}

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

Таким образом, выразительность Kotlin является как преимуществом, так и недостатком. Разработчикам, начинающим работать с этим языком, важно развивать зрелость и умение отличать хорошие паттерны от плохих, чтобы писать качественный и поддерживаемый код.

А как вы считаете, в крупных проектах важнее гибкость и выразительность или единообразие и простота поддержки кода?

Дорогие подписчики! Всех с Наступающим!

Желаю, чтобы в Новом году вам удавалось достигать поставленных целей, чтобы задачи были интересными и чтобы все праздники удавалось встречать в кругу друзей, родных и близких.

P.S. В 2025-ом году хочу поэкспериментировать с тематикой и стартовать один сайд-проект. Следите за анонсами!

Итак, ⛄️🎄🍾 Новый Год уже наступил и мчится на всех порах... и что это значит? Это значит, что пришла пора анонсировать новый проект!

Поэтому представляю вашему вниманию канал Пульс Технологий @pulse_of_tech, на котором регулярно публикуются самые обсуждаемые новости и статьи из мира науки и IT!

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

Обновил 📺 видео про Springdoc, чтобы оно соответствовало статье. Видео доступно и на YouTube, и на RuTube - кому что удобнее.

Springdoc позволяет автоматически генерировать документацию по вашему REST API на основании исходного кода и специальных аннотаций. Таким образом, ваша документация будет всегда актуальной и её не нужно как-то дополнительно актуализировать каждый раз при изменении исходников.

Записал видеоролик для статьи Валидация бинов в Spring. Видео доступно на YouTube и RuTube.

Spring позволяет проверять входящие запросы в декларативном стиле при помощи специальных аннотаций из пакета jakarta.validation. Валидация активируется с помощью аннотации Valid.

Ещё бывает полезно изменить стандартный формат сообщения об ошибке, чтобы там отображались более информативные сообщения. И в видео я расскажу как это можно сделать.

Пример проекта также доступен на github.

На собеседованиях и на leetcode можно встретить такую алгоритмическую задачу.

Дан неупорядоченный массив целых чисел. Нужно найти все пары чисел, сумма которых равна указанной. Числа в массиве могут быть как положительными, так и отрицательными. В качестве результата нужно вернуть порядковые индексы найденных элементов.

В новом видео (YouTube и RuTube) мы рассмотрим несколько вариантов реализации этого алгоритма, начиная с самого простого, и будем постепенно его оптимизировать. Текстовый вариант в виде статьи доступен на моём сайте.

Сегодня давайте разберёмся, как вычислять контрольные суммы файлов на ☕️ Java с помощью стандартной библиотеки. 📺 Видео доступно на YouTube и RuTube.

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

Существует несколько алгоритмов вычисления контрольной суммы, рассмотрим самые популярные: md5, sha-256, sha-512 и crc-32.

С наступлением эпохи микросервисной архитектуры и облачных технологий монолит воспринимается как плохая практика и вообще что-то устаревшее.

К плюсам микросервисов можно отнести лёгкость освоения кодовой базы новичками и готовность к горизонтальному масштабированию by design. Однако за это мы платим дублированием кода и данных в разных микросервисах, большим количеством однотипных правок при обновлении библиотек и сервисных паролей, а также сложными релизами.

В монолите же огромная кодовая база, которую трудно держать в голове, и велика вероятность упереться в потолок по техническим лимитам на сервере. Однако монолиты быстрее разрабатывать, проще релизить и обновлять в нём библиотеки.

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

А какую архитектуру выбрали бы вы при старте нового проекта?

Задавались ли вы вопросом, что именно влияет на популярность языков программирования? Почему одни ЯП популярны десятилетиями, а про другие уже никто не вспоминает? Хочу привести несколько примеров.

C++, привнесший в классический Си ООП модель программирования, появился в 1983. По современным меркам имеет высокий порог входа, тяжёлое наследие в синтаксисе и, как следствие, долгую разработку и сложный дебаг. Однако используется до сих пор для написания высоконагруженных проектов или низкоуровневых утилит и драйверов.

Java в 1995, учтя все минусы C++, привнесла в ООП автоматическую сборку мусора и относительно "стройную" стандартную библиотеку. Сейчас является стандартном де-факто для серверных приложений. Хотя изначально разрабатывалась для управления стиральными машинами и микроволновками.

С#, учтя все "детские болезни" Java, представил очень похожий язык, но под инфраструктуру Microsoft. По сути, до сих пор его ниша так и ограничивается продуктами Microsoft.

Kotlin, детище JetBrains, как будто выбрав золотую середину между ООП Java и функциональным программированием Scala, представил ещё более "стройную" стандартную библиотеку и поддержку от такого гиганта как Google, который сделал его основным языком разработки под Android. И с каждым годом всё больше набирает популярности на server-side.

Python, наиболее популярный сейчас язык программирования, имеющий низкий порог входа. Используется в самых разных сферах: от написания небольших скриптов и до машинного обучения. Его особенностью является необходимость форматировать блоки кода отступами, в отличие от фигурных скобок, как в большинстве других языков. К плюсам можно отнести читабельность кода и интуитивно-понятный синтаксис.

Хочется ещё отдельно вспомнить про HTML, который не совсем язык программирования, а язык разметки. Появившись вместе с интернетом, он разрабатывался для домохозяек. Сейчас домохозяйки сайты не верстают, однако HTML живее всех живых, являясь чем-то вроде ассемблера для Интернета. И скорее всего будет существовать до тех пор, пока существует сам Интернет.

PHP, изначально заточенный под создание сайтов и по сути генерирующий HTML-страницы динамически, в начале нулевых был стандартом де-факто при создании сайтов. В настоящее время его немного потеснили другие языки, но сдавать свои позиции не намерен. Кроме того, PHP уже довольно давно по дизайну старается быть похожим на Java.

Ещё давайте вспомним SQL - язык для баз данных, который, в отличие от обычных ЯП, позволяет указать ЧТО я хочу получить в результате, а не КАК это сделать. Каждая СУБД его расширяет под свою специфику, но стандартные запросы поддерживаются в любом из них. Разработан в 70-е и тоже живее всех живых.

Исходя из всего вышесказанного, напрашивается вывод, что на популярность и время жизни языка влияют либо особенность среды исполнения (HTML, SQL), либо заточенность под конкретного вендора (C#), либо богатый набор библиотек и низкий порог входа (Python), либо высокая производительность (C++).

А какой язык программирования предпочитаете вы и почему?

Знаете, что доводит меня до "белого каления"?

Небольшая предыстория.

До 2022 года я хостил все свои pet-проекты, в том числе и devmark.ru, на сервисе heroku.com. Меня он полностью устраивал, т.к. позволял в один клик развернуть Spring-приложение в облачном сервисе, а также при необходимости подключить ему postgres, домен и https. То есть вы получаете готовый сервис без навыков devops буквально за 5 минут. Потом мне пришлось перейти на отечественные виртуалки и я даже сэкономил на этом. Но я готов платить больше, если сервис заметно облегчает мне жизнь и позволяет сосредоточиться на написании кода.

И вот недавно я узнал, что timeweb.cloud предоставляет такой же функционал. У них заявлено немало фичей: облачные БД, kuber, s3 и тот же apps - сборка и деплой из репозитория. Я сначала обрадовался и готов был уже начать переносить все свои проекты туда, однако при первой же попытке деплоя gradle-проекта удача меня покинула(

В процессе двухдневной переписки с поддержкой меня сначала отправили читать их мануал по деплою maven (видимо они считают что раз java, то только maven), затем посоветовали увеличить память c 1 до 2 ГБ и, наконец, завели "внутреннюю задачу" со словами "решение может занять длительное время" 😡. Как будто я - первый человек, которые решил у них задеплоить Spring с gradle 😏 А ведь эта фича у них доступна уже как минимум год!

Другой забавный момент состоит в том, что самая "свежая" JDK, которая у них поддерживается - Java 19 (год выпуска - тот же 2022). Когда же я спросил, не планируется ли поддержка Java 21 как последней актуальной long-term support версии - мне предложили вынести эту фичу на голосование в раздел "Есть идея", и если она будет востребована - то возьмут в работу. То есть переход на актуальную (а порой и более оптимизированную) версию преподносится как фича). Браво! Кстати, на голосование эту фичу уже вынесли до меня ещё полгода назад.

Вот пожалуй и всё что нужно знать про отечественный хостинг) Это меня и доводит до "белого каления". Когда задаёшь конкретные вопросы и выдвигаешь гипотезы, а тебя просто игнорят и отписываются. Хотя gradle - это такой же базовый функционал как maven, который должен поддерживаться по умолчанию.

Но я без претензий к техподдержке timeweb. Их просто этому не научили) Они нащупали реально востребованную нишу и я считаю, что будущее именно за такими сервисами. Осталось только довести до ума технологическую составляющую.

Развитие технологий, как часть ещё более давнего процесса разделения труда, имеет вектор на уменьшение необходимого вам оборудования и знаний при увеличении вашей производительности и удобства. Сервисная модель отлично себя зарекомендовала, к тому же её легко монетизировать. Об этом красноречиво говорят различные конструкторы сайтов, облачные хранилища файлов (Google Drive, Яндекс Диск), потоковое видео (YouTube, Netflix), запуск любых игр без локальной установки (GeForce Now), виртуализация, контейнеры и, наконец, деплой напрямую из репозитория.

Год или полтора назад на одной из конференций я разговаривал на эту тему с представителем всем известной компании на букву Я. Тогда мне сказали, что, несмотря на развитие Cloud-направления, деплой из репозитория не рассматривается даже в отдалённой перспективе.

Между тем среди моих подписчиков периодически возникает вопрос, как развернуть Spring-приложение на сервере. Я же не могу им сказать: "изучите ещё администрирование linux, postgres, docker, kuber - и вот тогда сможете увидеть свой Hello World из любой точки мира"?

P.S. Если знаете другие отечественные аналоги heroku - напишите в комментах, буду очень вам благодарен)

✅ Обновил видео про работу с событиями в Spring.

В нём рассмотрим gradle-проект, написанный на Kotlin. В основе проекта лежит Spring Boot. Фреймворк "из коробки" предоставляет простой механизм работы с событиями, который позволяет уменьшить связность компонентов системы.

Событие, которое возникает в одной точке приложения, может быть перехвачено и обработано в любой другой части приложения благодаря механизму publisher и eventListener. А при помощи пары аннотаций мы можем сделать эту обработку асинхронной.

➡️ Видео доступно на YouTube и RuTube. Текстовый вариант доступен в виде статьи.