Верхняя полка📝

Любопытно и порой не очень весело наблюдать за развитием некоторых программных инструментов. Например, когда-то я искал, на чём делать свою домашнюю страничку, и остановил выбор на Academic — шаблоне для сайтогенератора Hugo.
Выбрал, в том числе за простоту.
И вот как она преобразилась со временем (даты примерные, но состав точный)👇

Для локальной работы с сайтом на HugoBlox (ex. Wowchemy, ex. Academic) нужно:
2018: Hugo
2019: Hugo Extended
2021: Hugo Extended + Go
2023: Hugo Extended + Go + NodeJS
2025: Hugo Extended + Go + NodeJS + Tailwind CSS

Что дальше? Python? Rust? BrainF*ck?
Это ведь всё те же статически отдаваемые странички... Казалось бы 🤨

Skiing in the winter wonderland ❄️

Как быстро растут детишки фреймворки 🌱

Кажется, ещё недавно я рассказывал со сцены на Joker в Петербурге о граблях обновления #SpringBoot c версии 1 на 2. Но оказывается прошло семь лет, и вот намедни был объявлен официальный релиз версии Spring Boot 4.0. Любопытно, что в этот же день на онлайн-конференции Подлодка был доклад про переход на эту версию; ребята здорово подгадали 👨‍🏫

В документе Spring Boot 4.0 Release Notes одной из первых идёт весьма обтекаемая формулировка:

... upgrading existing applications can be a little more involved that usual.

Как изящно они обошли фразу "вы офигеете разгребать поломки", не правда ли? 😉

Впрочем, наверняка опыт у всех будет разным. Судя по текущему Migration Guide, который в эти жаркие дни обновляется чуть ли не каждые несколько часов, основное веселье предстоит со стартерами ("кирпичиками" в Spring Boot), в том числе тестовыми, потому что одним из главных изменений в этой мажорной версии стала модуляризация фреймворка 🧱

Кроме того, похоже, не обойдётся и без развалов на этапе компиляции, так как многие классы разъехались по модульным пакетам, именуемым как org.springframework.boot.<module>. Конечно, умная InetlliJ IDEA, скорее всего, быстро подскажет, на что нужно поменять импорты, но если в проекте много явных обращений к классам Spring Boot, потыкаться всё равно придётся 👉

К счастью, такое масштабное обновление касается очень многих проектов, поэтому для него уже написана стопка рецептов на OpenRewrite, которая так и называется — Migrate to Spring Boot 4.0. По идее, она должна очень сильно упростить весь процесс, сведя его, по сути, к трём шагам:

1️⃣ Прописать в скрипте сборки рецепт (на примере build.gradle):

plugins {
    id("org.openrewrite.rewrite") version("latest.release")
}
rewrite {
    activeRecipe("org.openrewrite.java.spring.boot4.UpgradeSpringBoot_4_0")
    setExportDatatables(true)
}
dependencies {
    rewrite("org.openrewrite.recipe:rewrite-spring:6.19.0")
}

2️⃣ Запустить автомиграцию командой gradle rewriteRun.

3️⃣ Отревьюить получившиеся изменения и заставить их работать (чертыхаясь и понося уже не себя, а умный скрипт).

Какой способ обновления лучше — вручную или автоматически — каждый решает сам.
Но какой бы вы не выбрали, после завершения напишите, пожалуйста, в комментариях к посту или в ЛС, как у вас всё прошло — попробуем вместе собрать реальную картину обновлений 🖼

Пост-выходной впрыск новостей про #спорт

Вдохновленный своим относительно успешным прохождением Томского лыжного марафона (50 км коньковым ходом) в марте этого года, я решил не бросать это гиблое дело и выбрал новую цель — купил слот на аналогичный марафон, только уже в Кемерово, 14 марта. Старт называется KuzbasSki 🎯

Ту дистанцию в марте удалось "оформить" за 2:55:56 — во многом благодаря отличной погоде и сравнительно небольшому набору высоты (≈470 м). А вот на Кузбассе получить такой результат удастся едва ли, так как с погодой там часто бывают "сюрпризы", да и рельеф куда более забористый — набор ≈800 м 🏔

Но я всё продумал: специально взял слот заранее, чтобы не только успеть как следует подготовиться, но и передумать и слиться, а у вас было время забыть про этот пост и потом не срамотить меня за него🤪

🎞 Новые полезные видео по #Java Performance

1. Вебинар про JFR @ CLI
Опубликована запись недавно упоминавшегося здесь вебинара Алексея Рагозина по работе с JFR из командной строки. Помимо наглядности, видео интересно обилием всяких неочевидных фишечек, например, что целевой процесс для команды jcmd можно указать не только по старинке через его PID, но и простым именем главного Java-класса (в котором объявлен метод main). Для тех отважных, кто решится повторить эксперименты вебинара самостоятельно, Алексей оставил небольшую текстовую инструкцию — всего-то 57 шагов 🫠

2. Интервью про инструменты диагностики в Java
Недавно анонсированное мною интервью на онлайн-конференции Podlodka Java Crew состоялось — там я рассказывал об инструментах диагностики Java-приложений и их новшествах. Здорово и приятно, что моим интервьюером был Дмитрий Константинов, по докладам которого я сам ещё недавно постигал премудрости чтения и записи в Cassandra. В ходе разговора мы затронули самые разные темы, начиная от древних как мир дампов потоков и заканчивая новейшими JEP'ами и применениями AI. Плюс к тому поговорили об обновлениях не только встроенных инструментов JDK (таких как JFR и NMT), но и популярных сторонних: async-profiler, Eclipse MAT, VisualVM. И хотя это было именно интервью, а не доклад, в ходе ответов я старался многое демонстрировать, поэтому запись желательно не только слушать 👀

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

Увидимся на Подлодке 🌊

В следующую среду, 19 ноября с 10:00 до 11:00 МСК будем общаться онлайн с ребятами из конференции Podlodka #Java Crew:

Интервью «Эволюция инструментов диагностики в Java»
В формате интервью поговорим с Владимиром про различные способы диагностики проблем производительности в Java, такие как JFR, NMT, Heap и Thread дампы, профилирование. Обсудим новшества в этой области, а также то, какие проблемы и тренды есть сейчас.

Всем, кому интересна тема анализа производительности и поиска "узких мест" в коде нагруженных приложений — милости просим 🙌🏼

В продолжение темы про JFR ✈️

Вчера разбирался с забористым багом — барахлила асинхронная связь между двумя модулями приложения (на одной JVM): один обновлялся, а второй не всегда. Помимо нестабильности воспроизведения дело усложнялось тем, что проблема стреляла только на удалённом сервере заказчика. Короче, всё по классике😏

При помощи ряда экспериментов, интуиции и такой-то матери мне удалось выяснить, что один из асинхронно выполняемых методов прерывается из-за какого-то исключения. Но этого исключения не было в логах, потому что в методе не предусмотрели try/catch, а сам метод вызывался так:

executorService.submit(this::fireBatchedEvents)

, то есть отправлялся на исполнение в пул безо всякой обратной связи (что уже не хорошо, но это отдельная тема✍️)

И вот ситуация:
— исключение есть
— логов нет
— добавить логирование в код нельзя, потому что после перезапуска проблема опять перестанет повторяться.
"И как теперь что?" 🫤 (© Масяня)

К счастью, внутри JVM на выбросы исключений заведено отдельное событие для JDK Flight Recorder, оно называется jdk.JavaExceptionThrow. Если его включить и провести запись JFR во время проявления проблемы, то в ней (в записи) должны осесть данные обо всех исключениях, даже если само приложение их "глотает" 😋

Запуск записи в моём случае выглядел так:

./jattach <PID> jcmd JFR.start settings=none +jdk.JavaExceptionThrow#enabled=true +jdk.JavaExceptionThrow#stackTrace=true

, где:
• jattach — утилита для подключения к JVM, когда под рукой только JRE, а не JDK (в частности, нет jcmd);
• jcmd JFR.start settings=none — команда на старт записи с полностью выключенными событиями (чтобы не писать лишнего);
• +jdk.JavaExceptionThrow#enabled=true — флаг включения события JavaExceptionThrow. Символ "+" здесь нужен потому, что мы не меняем значение какой-то настройки из параметра settings (там же none), а добавляем его;
• +jdk.JavaExceptionThrow#stackTrace=true — флаг добавления стектрейсов к регистрируемым событиям; по умолчанию он снят, а без стектрейсов смотреть на исключения скучно.

После старта записи я выполнил в приложении проблемное действие, а потом остановил запись вот таким заклинанием:

./jattach <PID> jcmd JFR.stop name=1 filename=error.jfr

, где:
• jcmd JFR.stop name=1 — команда на останов конкретной записи (их может быть несколько). Имя записи можно либо задать явно при её запуске, либо посмотреть назначенное в ответе команды JFR.start 🚀

На выходе получился файл error.jfr, открыв который в Java Mission Control, удалось быстро отыскать пропавшее исключение и, главное, увидеть его стектрейс (хотя всего их там оказалось аж 320😳)

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

В блоге компании AxiomJDK на Хабре позавчера вышла статья Алексея Рагозина о работе с JDK Flight Recorder'ом из командной строки. Фишка статьи в том, что она не только рассказывает, как запускать/мониторить/останавливать записи JFR, но и как смотреть их результаты прямо на лету, т.е. без дампа в файлы с последующим открытием. Мне довелось немного поучаствовать в подготовке этой статьи; в основном, как рецензенту 🤓

Если кто не знает, Алексей — один из топовых российских экспертов по производительности JVM. Он пишет глубокие технические статьи, выступает с докладами, ведёт тренинги и сам разрабатывает инструменты для диагностики JVM. Кстати, его проект SJK (Swiss Java Knife) используется, например, в Apache Cassandra 💪🏼

Послезавтра, 13 ноября в 19:00 МСК Алексей проведёт открытый вебинар по работе с JFR из командной строки, но в отличие от статьи, там будет возможность в живую увидеть пример применения JFR к приложению на #Java 25, включая совсем свежие улучшения, вышедшие в этой версии в сентябре. Кто хочет быть на гребне прогресса, подключайтесь 📺

Когда я ещё студентом пришёл в работать в маленькую фирму по модернизации больших металлообрабатывающих станков, мне повезло работать под руководством опытного советского инженера-станкостроителя Бориса Леонидовича Хоменко. А он, в свою очередь, в силу возраста успел поработать с людьми закалки конца 40-ых, 50-ых и начала 60-ых годов 🕰

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

Стоит ли говорить, что они работали под огромным давлением со всех сторон? Нынешние дедлайны по спринтам и релизам кажутся детскими шалостями по сравнению с той нагрузкой и ответственностью, которую несли тогда они 🗿

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

Что такое "делать быстро"?
Это значит делать не торопясь, но без остановок.

А ведь и правда: зачастую слова "делай быстро" заставляют нас спешить. На первых порах это бывает оправданно, но уже скоро выясняется, что на длинной дистанции такой темп нам не по силам; что спешка порождает много ошибок; что сама работа уже, как минимум, не в радость, а то и вовсе уже противна. Всё это приводит к постепенному затуханию (выгоранию) и вынужденной остановке, часто на непредсказуемый срок 🕳

Слова "без остановок" не значат, что отдых вреден, разумеется. Они значат, что на больших объёмах работ беспорядочные перерывы зачастую вредят больше, чем не очень высокий темп выполнения. Подобно этому равномерно и неспешно бегущий марафонец достигает финиша раньше, чем равный ему по силам товарищ, рванувший со старта, но вынужденный много раз переходить на шаг, чтобы перевести дух 🏃‍♂️

Вероятно, за этими простыми словами стоит немало серьёзных историй тех суровых времён 🤔

Если вам тоже доводилось слышать от своих наставников/руководителей мудрые мысли, надолго запавшие в память, поделитесь, пожалуйста, в комментариях — пусть о них узнает больше людей 📢

В сегодняшнем выпуске дайжджеста Java Annotated Monthly (от JetBrains), помимо новости о выходе Spring Boot 4 и Spring Framework 7, содержалась заметка о запуске Developer Productivity AI (DPAI) Arena — открытой площадки для измерения показателей и сравнения эффективности ИИ-агентов для разработки ПО 👨‍💻

По сути, это публичная арена для сопоставления возможностей инструментов ИИ-кодинга. На ней собраны 15 форков от известных opensource-проектов, представляющих примеры различных архитектур enterprise-приложений, и для каждого проекта подобран набор задач с четко описанным требуемым результатом, по которому выводится балл за решение (от 0 до 100) ⚖️

Примечательно, что в эти 15 проектов попал и Spring PetClinic REST — та самая модификация известного демо-приложения Spring PetClinic, которую я использую в своих тренингах. На скриншоте приведена задача по добавлению в неё кэширования наиболее частых запросов, с которой относительно (не)успешно справился агент Codex от OpenAI 🧠

К слову, этот же агент сейчас числится лидером в "турнирной таблице" DPAI Arena, но надо понимать, что площадка ещё только запускается, поэтому некоторых сильных участников на ней ещё попросту нет. Да и сами лабораторные проекты сейчас на 90% подобраны из мира JVM, поэтому слово "multi-language" в описании проекта надо воспринимать с поправкой на новизну 🚼

Инициатором, автором и пока что единственным разработчиком DPAI Arena является компания JetBrains, однако с самого начала она заявляет намерение передать этот проект в Linux Foundation, чтобы он остался открытым, вендор-нейтральным и полностью прозрачным. При этом присоединиться к проекту уже сейчас могут не только технологические вендоры и создатели кодинг-агентов, но и конечные пользователи — разработчики ПО — за счёт предоставления чужих или своих бенчмарков и датасетов 🧪

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

https://dpaia.dev/

На днях прочёл студентам "Системного программирования" на МехМате НГУ третью лекцию по компьютерным сетям в рамках их спец.курса 🧑‍🎓

Лекция была посвящена безопасности сетей, поэтому в её начале я решил сделать обстоятельный обзор теоретических основ прикладной #криптографии. Однако это оказалось промашкой — уже на самой лекции выяснилось, что недавно у ребят прошёл целый курс криптографии, поэтому в этой теме они шарят не хуже, а возможно, и лучше меня. Но, по крайней мере, вторая часть лекции, где речь пошла уже о прикладных аспектах — инфраструктуре PKI, сертификатах X.509 и протоколе TLS — была для них в новинку и потому, надеюсь, полезной 🙏🏼

Зато, пока я готовился к первой части, нашёл статью в блоге CloudFront, где приведено самое человечное из когда-либо встречавшихся мне объяснений основ асимметричных схем RSA и EC (напомню/сообщу, что RSA держится на сложности факторизации больших чисел, а EC — на сложности дискретного логарифмирования). Конечно, большинство сугубо математических "интрижек" в статье всё же опущено, но вместо них приведены вполне понятные метафоры или пояснения. В общем, ответственно рекомендую к прочтению — приключение на 15-20 минут 📚😉

В начале октября я провёл новую серию тренингов по анализу производительности приложений на #JVM. Обратная связь собрана и обработана; можно повникать в результаты 🔎

Эта серия состояла из 5 занятий для двух групп, в которых суммарно было 17 участников. Первые три занятия были по тем же темам, что и раньше: работа с дампами потоков, с дампами памяти и с JFR, а последние два — по новой теме про профилирование, навеянной сделанным недавно докладом 🗣

И хотя общая средняя оценка по заполненным анкетам (8 из 17) получилась весьма неплохой — 9,8 из 10, проблемы и недоработки остаются налицо. В частности, немало затыков случилось "благодаря" корпоративной безопасности, причем даже там, где у прошлых групп в этой же компании всё было хорошо. Но и по моей части есть над чем поработать, особенно в новом тренинге по производительности, например, добавить пункт про установку JDK внутрь WSL для тех, кто хочет пощупать async-profiler на Windows, но не имеет IDEA Ultimate. Да и вообще выбор профайлера для практической части тренинга остаётся непростым открытым вопросом 🤔

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

В этот раз подготовка к этому интенсиву далась мне отнюдь нелегко; было много других важных активностей, конкурировавших за мои время и энергию. Но, судя по всему, на качестве материалов и их подаче это особо не сказалось. К тому же каждый новый заход позволяет чуть точнее спланировать тайминг, ещё раз вычитать слайды, подтюнить лабораторное приложение — словом, подшлифовать #тренинги и сделать их лучше 📈

Спасибо тем из вас, кто уже поучаствовал; ваши комментарии к этому посту будут очень ценными для меня и остальных! 🙏🏼

А тем, кто ещё только подумывает об участии, можно почитать описание тренингов (пока только 3 и 4) и задать уточняющие вопросы либо здесь, либо мне лично. Отличного вам дня! 🎈

Давненько не было новостей про #спорт , а ведь есть что рассказать 👇

В минувшее воскресенье состоялся мой заключительный старт летнего бегового сезона 2025 — Юрманка трейл. Это забег на 35 (по факту 37) километров с набором высота около 1100 м (примерно 380 этажей) по окрестностям реки Бердь и посёлка Маслянино в Новосибирской области. И без того едва заметные тропинки этой трассы во многих местах совсем исчезли под слоем недавно выпавшего снега, поэтому организаторам пришлось размечать трассу "по-дикому": сквозь заросли, косогоры и лес. Вместе с переходящим в грязь снегом это добавило гонке ещё несколько "изюминок" 🚧

Относительно хорошие результаты на минувших в сентябре полумарафоне Раевича (21,1 км) и Альбатрос-трейле (18 км) вселили в меня надежду на то, что в Юрманке я тоже смогу пробежать хорошо, хоть это и пока рекордно большая для меня дистанция в трейлах. Поэтому весь прошлый месяц я целенаправленно готовился:
— выбирал, заказывал и тестировал экипировку (без неё к таким стартам не допускают);
— проверял разные варианты одежды, чтобы при 0 градусов было комфортно бежать 3-4-5 часов;
— и, конечно, тренировался на пересечёнке: по вечерам с фонариком бегал на лыжных имитационных кругах, по утрам в выходные чавкал в ручьях вокруг Академгородка, а как-то раз изрядно помесил свежезаснеженные подъёмы горно-лыжного комплекса ⛷

В объективных цифрах это дало, в целом, неплохой результат: я финишировал за 4 часа 18 минут, став 14-ым из 98 бежавших эту дистанцию мужчин и 7-ым из 32 в категории М30-39 🏆

Однако с точки зрения раскладки сил и, как следствие, полученных впечатлений на финише, этот старт, увы, обернулся для меня фиаско — после 28-го километра, когда закончилась серия крутых подъёмов, я с неприятным удивлением осознал, что ноги тоже "кончились" (мышцы забились). На тот момент я замыкал группу бодрых бегунов, при должной борьбе в которой я мог бы попасть в призы в своей возрастной категории. Мой расчёт был на то, что дальше, когда трасса будет уже более пологой, я смогу этим заняться. Но увы, вместо этого я стал от них отставать, а вскоре и вовсе начал переходить на шаг при малейших подъёмах, постепенно уступив ещё несколько позиций догнавшим меня участникам. В таком полупешем режиме я и дотошнил оставшиеся 8 км до финиша 🏁

Будь я профессиональным спортсменом или помешанным на результатах, я бы всё равно посчитал такой исход успешным, ведь трудность и усталость в таком случае — необходимое зло, которым можно пренебречь. Но поскольку я — любитель (от слова "любить", на минуточку), для меня принципиально важно испытывать позитив, в том числе во время гонок и на их финише. Однако едва ли можно любить находиться в таком состоянии, в каком я был после финиша этой гонки. Уж лучше оказаться далёким от лидеров, но сохранить способность радоваться происходящему, а не сидеть потом полчаса под деревом с языком на плече 😛

Как бы там ни было, опыт получен, работа над ошибками проведена, выводы сделаны. Тем интереснее будет сравнивать результаты в следующий раз 😉

P.S. Часть фото авторские, часть из Telegram-чата гонки, часть от фотографов.