devmark_ru

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Прошла уже пара месяцев с тех самых пор, как YouTube в России работает с ограничениями. Каждый из нас сам выбирает, каким видеохостингом пользоваться и как именно. Я же со своей стороны рассудил, что моя аудитория тоже должна иметь выбор.

Понятно, что есть разные способы, как продолжать смотреть мой канал на YouTube. Однако не всегда это зависит только от нас. Например, если вы хотите посмотреть про Java, Kotlin и Spring на работе (а статистика показывает, что основные просмотры идут именно по будням), то вы можете столкнуться с ограничениями.

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

Если вам удобнее смотреть канал на RuTube, прошу поддержать подпиской, комментами и лайками - канал только что создан и подписчиков на нём практически нет. Заранее благодарю!

Продолжаем эксперименты над короткими видео.

Сегодня я опубликовал два новых Shorts про наиболее популярные реализации интерфейсов Set и Map.

Я знаю, что эта тема про коллекции в Java часто вызывает много вопросов у новичков и пользуется неизменной популярностью.

Осваиваю Shorts на своём YouTube-канале!

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

В качестве примера я сделал несколько роликов про онлайн-утилиты на моём сайте.

Встречайте: раз, два, три и четыре.

Продолжаем цикл видео про работу с GraphQL в проекте, написанном на Kotlin и Spring Boot.

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

📺 Видео про обработку ошибок
📗 Статья на сайте

Продолжаем неделю GraphQL!

Сегодня на подходе второе 📺 видео, на этот раз по мотивам 📗 статьи об изменении данных с помощью мутаций.

Мутации - это по сути обычные методы со входными и выходными параметрами, которые изменяют состояние системы.

Дорогие друзья!

На днях количество подписчиков на моём youtube-канале преодолело очередную круглую цифру. Теперь вас более 4000!

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

Спасибо!

Астрологи объявили неделю GraphQL! 🥳

Ранее я дописал и актуализировал несколько статей по работе с GraphQL в Spring Boot. 🧑‍💻 Теперь пришла пора опубликовать обновлённые видео на эту тему.

Итак, встречайте:
📺 первое видео, в котором рассмотрим основные отличия GraphQL от REST, создадим пример проекта на Spring Boot и Kotlin.

Также разберём проблему N + 1 и узнаем, как можно добавлять кастомные типы данных в дополнение к стандартным.

На своём YouTube-канале обновил 📺 видео про алгоритм поиска чисел Фибоначчи, чтобы оно более соответствовало содержимому 📗 статьи.

Сама последовательность довольно проста. Она состоит из целых положительных чисел, где каждый следующий элемент равен сумме двух предыдущих. Например, 2 = 1 + 1, 3 = 2 + 1, 5 = 3 + 2.

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

Не забывайте ✅ подписываться и ставить ❤️ лайки)

Приятного просмотра!

Сегодня я расскажу про интерфейсы Comparable и Comparator в Java:
📗 новая статья на сайте
📺 новое видео на YouTube

Интерфейс Comparable задаёт правила сортировки по умолчанию. Объекты, реализующие этот интерфейс, уже могут сравниваться с помощью стандартных методов сортировки, поиска минимума и максимума. Такие коллекции как TreeMap и TreeSet требуют реализацию интерфейса Comparable, т.к. автоматически сортируют элементы.

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

Но гораздо удобнее конструировать компараторы «на лету», используя статический метод comparing() интерфейса Comparator. В этом случае вы можете комбинировать несколько полей для сравнения и даже менять порядок сортировки на обратный.

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

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

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

Написал третью статью про GraphQL на Kotlin и Spring. На этот раз научимся обрабатывать исключения и менять стандартный формат ответа при ошибке.

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

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

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

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

Например, если выбрать "рубли и копейки" и ввести число 1234.50, то на выходе получим текст одна тысяча двести тридцать четыре рубля 50 копеек. В настройках можно выбрать также евро, доллары, метры и даже гектары! И ещё можно настроить регистр букв.

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

В продолжение темы про онлайн-утилиты, я расширил существующую утилиту для вычисления SHA-хешей (Secure Hash Algorithm).

Если раньше там был единственный представитель этого семейства - SHA-256, то теперь появилось 8 новых! Добавлена поддержка хешей SHA-384, SHA-512, SHA-512/224 и SHA-512/256 из версии 2. Также добавлены хеши версии 3: SHA3-224, SHA3-256, SHA3-384, SHA3-512.

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

Уже довольно давно на моём сайте есть онлайн-утилита, которая позволяет форматировать любые данные в формате XML. Например, если все элементы исходного xml записаны подряд в одну строку, то после форматирования каждый из них будет начинаться с новой строки, а вложенность будет отражена с помощью отступов.

Теперь я добавил аналогичную утилиту для форматирования JSON. Поскольку в современных системах формат JSON используется даже чаще, чем XML, полагаю, что новый инструмент тоже может быть вам полезен.

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

Сегодня, 17 апреля в 15:00 стартует онлайн-часть конференции для Java-разработчиков JPoint 2024! Также 24 и 25 апреля будет проходить офлайн-часть в Москве (Конгресс-центр «ЦМТ», Краснопресненская наб. 12). Доклады будут идти параллельно в 3 трека.

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