devmark_ru

Сегодня на Хабре я опубликовал статью Как сделать Telegram-бота умнее: пошаговый гайд на Spring AI и Kotlin.

Это пошаговый туториал о том, как сделать интеграцию с любой популярной нейросетью с помощью Spring AI и развернуть его в облаке. В качестве примера рассматривается telegram-бот с ChatGPT, но можно использовать и DeepSeek. Сам проект написан на Kotlin и доступен в github.

В процессе написания статьи мне оказывали профессиональные консультации по devops ребята из dockhost.ru.

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

devmark_ru pinned «Дорогие друзья! Этот канал является частью проекта devmark.ru, где я делюсь своим опытом и публикую статьи о разработке на Java, Kotlin и Spring. Большинство статей доступно также и в видеоформате на YouTube и RuTube. Материалы рассчитаны в основном на начинающих…»

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

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

Оператор эксперимента будет выбран на конкурсной основе до 31 марта 2025 года. А практическая часть стартует 31 мая, когда все желающие получат доступ к данной платформе.

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

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

С другой стороны, до сих пор непонятно, что будет представлять из себя эта платформа. А то нагенерят нейросетью за 5 минут задания в стиле "что будет выведено в консоли после выполнения этой простыни кода?". И даже особо выверять эти задания не будут.

А что вы думаете о подобных инициативах? Следует ли государству пытаться как-то стандартизовывать требования и навыки в области разработки ПО?

Spring Rest Repository: минимум кода для полноценного restful сервиса на Kotlin

В этом видео рассмотрим как Spring Data Rest позволяет избежать написания контроллеров и сервисной логики.

Мы получим все основные операции CRUD (create, read, update и delete), написав при этом значительно меньше кода. Нам нужно только создать интерфейс и разметить сущность. Всё остальное (и запросы к БД, и rest api) Spring сгенерит за нас. Это очень удобный подход для создания прототипов.

Поскольку писать будем на Kotlin, нам придётся учитывать специфику взаимодействия с Java-кодом, на который изначально был рассчитан Spring Data Rest.

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

Видео доступно на YouTube и RuTube.

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

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

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

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

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

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

До 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 - напишите в комментах, буду очень вам благодарен)

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

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++).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 является как преимуществом, так и недостатком. Разработчикам, начинающим работать с этим языком, важно развивать зрелость и умение отличать хорошие паттерны от плохих, чтобы писать качественный и поддерживаемый код.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

🟠 CrudRepository на Kotlin (github)

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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