Верхняя полка📝
Open in Telegram
Путевые заметки программного инженера и легкоатлета-любителя. Автор: Владимир @Toparvion Плизга Домашняя страница: https://toparvion.pro/
Show moreRussia495 879The category is not specified
359
Subscribers
No data24 hours
+27 days
-330 days
Posts Archive
В этот четверг в 17:00 МСК буду выступать на онлайн митапе от сообщества CommIT с докладом о профилировании ⚒️
За время, прошедшее с выпуска первой версии этого доклада, профайлеры заметно развились: вышли значительные доработки и в async-profiler (v4.2+), и в JFR (JDK 25), поэтому кое-что обновилось и в материалах доклада 📚
Увидимся! 📺
+6
Гонка героев (2026) 🎖
Под этим попсовым названием кроется забег по полосе препятствий, специально построенной на военном полигоне для всех, кто хочет испытать себя в условиях, отличных от мягкого комфортного кресла под кондиционером в чистом офисе 💺
Мероприятие проходит несколько раз в год во многих городах России, а в Новосибирске проводится уже 10-ый год подряд, но остаётся довольно популярным, собирая больше 1000 участников в разнообразных форматах: личном, командном, по возрастам, в чемпионате и т.п. Местная полоса имеет длину порядка 8 км и содержит около 32 препятствий, многие из которых сопряжены с погружением в грязную воду или проползанием по жидкому грунту. Это и придаёт мероприятию особый вайб атмосферу 🧟♂️
В первые два года (2016-2017) проведения я участвовал в гонке 4 раза: трижды в составе взводов с коллегами и один раз индивидуально в чемпионате, который завершился для меня дисквалификацией из-за провала на одном из препятствий. За прошедшие после этого годы моё отношение к гонке сменило все грани:
— сначала не хотелось и думать о повторном участии, ибо пресытился;
— потом стало как-то безразлично;
— а в последние год-два поймал себя на том, что уже не против вписаться в это безобразие ещё разок 🤠
А тут как раз товарищи предложили собрать взвод от нашего спортивного клуба. Основным вызовом для меня стало не столько прошедшее время (всё же 8 лет), сколько полная смена физической активности: за это время я окончательно перестал заниматься уличной гимнастикой (воркаутом) и полностью перешёл в циклические виды спорта: бег, плавание, лыжи. Месяц специальных тренировок на стадионе (силовые упражнения вперемешку с бегом) показал, что физическая форма действительно изменилась, причём с т.з. предстоящей полосы препятствий не в лучшую сторону. Но надежда была 🙏🏼
Однако на гонке она почти не оправдалась — многочисленные рукоходы, на которые пришлась четверть всех препятствий, довольно быстро вскрыли недостаток хватки и силы, из-за чего приходилось прибегать к помощи товарищей или проходить препятствия с нарушением правил. Дело осложнялось содранными накануне тремя мозолями и неверно выбранными перчатками, хотя плохому танцору, как известно... Зато все канатные препятствие дались на удивление хорошо, включая подъём из водяного рва по канату на 3 м до колокольчика и, конечно же, изюминку трассы — финальное препятствие "Эверест", на которым многие команды теряли массу времени в безуспешных попытках взобраться по канату на высокую стену с уже обессилевшими руками
Вероятно, быстрое прохождение этого рубежа, а также довольно бодрый темп на беговых участках позволил нашему взводу обойти порядка 5-7 других команд. А общее время прохождения полосы — 1:25:43 — обеспечило нам 7-ое место среди 118 взводов формата "teams". Признаться, это результат превзошёл наши собственные ожидания: по самым оптимистичным вскидкам мы рассчитывали попасть лишь в топ-20 🙂
Едва ли этот опыт вдохновит нас погрузиться в бег с препятствиями с головой и вписаться в "Сибирский предел", "Битву титанов" и прочие схожие мероприятия. Но как вариант разнообразить тренировочный процесс он очень даже неплох 👍
#спорт
С интересным вопросом пришли недавно коллеги-фронтендеры: хотим, мол, в перспективе перейти на WebTransport API — модно-молодёжную альтернативу WebSocket-ам, с изолированными стримами, out-of-order сообщениями и прочими ништяками. Основная особенность — работа поверх протокола HTTP/3 (который, в свою очередь, построен на QUIC). Отсюда вопрос: а поддерживает ли такое наш бэкенд на #Java? 🤔
Немного поизучав тему, я выяснил, что:
• В самой Java протокол HTTP/3 поддерживается только в качестве клиента и только начиная с версии 26, вышедшей в марте этого года (JEP-517).
• Для поддержки на стороне сервера нужны сторонние библиотеки, в нашем случае это Apache Tomcat, так как API для фронта крутится на нём.
◦ При этом от Java как от платформы требуется реализация DTLS, но она, к счастью, сделана ещё в Java 9.
• А вот Tomcat поддержки HTTP/3 не имеет и не сильно торопится её вводить, потому что:
◦ HTTP/3 построен поверх протокола UDP и сильно оптимизирован для работы в мобильных сетях и прочих нестабильных условиях;
◦ Но Tomcat редко взаимодействует с ними напрямую, т.к. чаще всего стоит за балансировщиком, реверс-прокси, side-car'ом или чем-то ещё внутри корпоративного контура, где соединения уже стабильны, быстры и предсказуемы;
◦ Поэтому разработчики Tomcat считают старый добрый HTTP/1.1 (поверх TCP) всё ещё более подходящим:
Tomcat is not normally directly internet facing. It is typically sat behind some form of load-balancer and/or TLS termination and/or reverse proxy. In those scenarios poor network conditions aren't an issue so using QUIC is costs CPU power which is something folks - particularly those with large installations - try to minimise. It makes more sense to use HTTP/1.1 in those scenarios. Hence there isn't much requirement for an HTTP/3 implementation in Tomcat at the moment.◦ В этой связи, авторы Tomcat предлагают страждущим поддержки HTTP/3 ставить перед Tomcat'ом NGINX и снимать HTTP/3 на нём (либо на Caddy, Envoy и др.) • Но если стоит задача эффективно и быстро упаковывать данные для передачи и приёма именно по WebTransport API, то в этом сценарии бэкендовый сервер всё равно рискует остаться узким местом 🍾 Тогда остаются такие варианты: • Ждать поддержки HTTP/3 в Tomcat (рано или поздно она, скорее всего, будет); • Менять Tomcat на другой сервлет-контейнер, например, Jetty, который уже поддержал HTTP/3; • Переходить с сервлетного стека на реактивный, в котором Reactor Netty тоже поддерживает HTTP/3 ☢️ Есть ли другие альтернативы — не знаю, но не исключаю, что появятся, ведь и сам WebTransport API ещё только в baseline и потому поддерживается не повсеместно. Поживём-увидим 👀
Repost from SnowOne-канал
Всем привет!
В такую жару приятно вспомнить о нашей ламповой зимней конференции SnowOne ❄️
Публикуем видео всех 19-ти докладов! В этот раз на двух платформах, можно смотреть, где удобно)
Youtube: https://www.youtube.com/playlist?list=PLecWId-JT7S4gCNI3cqLT5sBYku49vutQ
VK Videos: https://vkvideo.ru/playlist/-166874186_1
Спасибо, что были с нами в феврале! А если нет, присоединяйтесь сейчас за просмотром записей) Увидимся следующей зимой на SnowOne 2027 ☃️
В эти жаркие (по меркам Сибири) летние деньки во многих вузах проходят не менее жаркие защиты дипломов у выпускников 📚
Не обошла эта активность и меня — уже лет восемь я состою в экзаменационной комиссии на защите у бакалавров специальности "Программная инженерия" в НГТУ (НЭТИ), на кафедре Вычислительно техники, выпускником которой сам и являюсь 🎓
В этот раз защит было довольно много, и почему-то среди них было немало проектов, реализующих сервисы для трекинга всего и вся: питания, привычек, книг, тренировок, записей на СТО и т.п. Прямо отчетливый тренд. Интересно, сами студенты реально пользуются такими сервисами? 🤭
Ещё было любопытно видеть, как некоторые выступления ребят на защитах становятся всё больше похожи на питч-сессии стартапов: студенты не столько показывают проделанную работу и констатируют пресловутую "научную новизну и практическую ценность", сколько будто бы пытаются продать комиссии свою разработку. Но если у меня это вызывает лишь улыбку и желание задать заковыристый вопрос по технической части (чтобы напомнить, где находится автор), то у других членов комиссии, особенно очень взрослых преподавателей, такой подход вызывает явное недоумение 🥴
Немного удручило отсутствие у некоторых ребят понимания предметной области, в которой они разрабатывают своё программное решение. Кто-то пилит приложение для моделирования химических реакций, но при этом плохо представляет себе таблицу Менделеева. Кто-то строит электронный каталог книг, но не учитывает их годы издания. А кто-то сделал сетевую игру в реальном времени, но не знает основных отличий TCP от UDP. Мне осталось неясным, то ли это проявление типичного студенческого подхода "Ну оно же работает!" или же отголоски избыточного применения ИИ в учебе?.. 🧐
Как бы там ни было, я рад,что снова поучаствовал в защитах, ведь эти ребята — наши с вами завтрашние коллеги, и для налаживания продуктивного контакта с ними очень полезно понимать, что они пинали делали все эти годы в универе 🤓
Первый старт этого лета 🏃♂️
Сегодня состоялся ежегодный "Пробег памяти В. Рыцарева" — кросс по лесам и горкам близ Новосибирского Академгородка. Он был уже 50-ым по счёту в своей истории и 4-ым для меня. Своему первому участию в нём я посвящал отдельный очерк 📜
По сложившейся традиции я вписался в максимальную его дистанцию — 22,5 км (3 круга по 7,5). Но вопреки предыдущим разам уже на втором круге на главном подъёме почувствовал, что пульс неадекватно высок, и перешёл на шаг, хотя раньше никогда так не делал. Бывало, что к третьему кругу сползал на нечто близкое к трусце, но не на шаг 🐌
Надеялся, что дальше отпустит, и я вернусь в комфортный темп. Но чуда не случилось — бежалось по-прежнему тяжеловато. Несколько раз спросив самого себя о готовности к третьему кругу, я приходил к одному и тому же выводу: да, я смогу его преодолеть, но это будет отнюдь не удовольствие, а мучение. А мне как любителю важно делать то, что нравится и не вредит, тем более, что этот старт не был целевым, т.е. никаких ставок на него сделано не было. К тому же и по личному, и по чужому опыту я хорошо знаю, что такие "подвиги" потом требуют долгого и порой малоприятного восстановления
Ровно поэтому я принял решение финишировать досрочно и сошёл на 15-ом километре. Неприятно, но правильно. Упрись я рогом и дотяни до финиша, ничего хорошего бы из этого не вышло 💯
Надеюсь, это лишь разовое отклонение, а не начало большого спада. Поживём-увидим; буду держать в курсе 📻
#спорт
+8
Мало кто знает, но нелепый ник Toparvión образован от слова "Топáр" — названия небольшого посёлка в центральном Казахстане. А откуда взялось это название — доподлинно неизвестно, но есть, как минимум, две версии: либо от фамилии некогда бывавшего там революционного деятеля Топаровского, либо (что кажется более правдоподобным) — от казахского слова "тулпар", что в переводе на русский значит "конь", ведь в тех степях много веков подряд находились бесчисленные пастбища 🐴
Как бы там ни было, те места обладают одним замечательным свойством — невероятным простором для взора. Достаточно отойти от застройки минут на 20 почти в любую сторону, чтобы очутиться в точке, откуда даже без подъёма в гору (а их там и нет, только сопки) будет открываться настолько просторный вид, что взгляд ни упрётся ни во что, кроме горизонта — ни в дома, ни в деревья, ни в заборы, ни в рельеф 👀
Как всё же приятно и ценно хотя бы иногда возвращаться к своей точке отсчёта, подпитываться воспоминаниями от знакомых с детства людей, мест и предметов, сбрасывать накопленный негатив и заряжаться добрым, светлым настроем на новые дела и свершения. Первый отпуск этого года почти окончен; возвращаемся к работе ✊
Hard work & hard run 🛠👟
Текущая рабочая неделя выдаётся весьма непростой. Во-первых, она длится уже 12-ый день, и почти каждый из них оказывается полон задач вплоть до "третьей половины дня" включительно. Во-вторых, из-за этого приходится пропускать некоторые тренировки, а это не очень хорошо сказывается на самочувствии, не столько физическом, сколько эмоциональном — уже не раз замечал, что если объём тренировок проседает, а другие нагрузки растут, то, видимо, где-то что-то в организме недовырабатывается, и даже привычные вещи и события постепенно начинают восприниматься не так позитивно, как раньше 🤷🏼♂️
А тут ещё незаметно подкралась очередная дата проведения ЗаБег.РФ — масштабного любительского бегового старта, проводимого одновременно в десятках городов России, а с некоторых пор ещё и в других странах. В последние годы я пропускал этот старт, так как: (1) уже пробегал на нём 21 км несколько раз, и (2) из-за синхронного старта во всех городах, начало забега в Новосибирске приходится на 13:00 — зачастую самый пик жары 🥵
Нынче ЗаБег должен был пройти в юбилейный 10-ый раз, плюс застрявший в Новосибирске холодный циклон обещал, что жары не будет. Да ещё и некогда запланированная поездка в эти выходные отменилась. Словом, всё шло к тому, чтобы вписаться в этот старт, что я и сделал ✍️
Ожидаемо, бежалось нелегко: сказывались и пропущенные тренировки, и непрекращавшийся ни на минуту дождь (хорошо хоть не проливной), и периодические волны ветра, которые сильно мешают будучи встречными, но почему-то остаются незаметными, когда дуют в спину 💨
Найдя себе оправдание в том, что это забег не на рекорд, а так, для поддержания формы, я выбрал сравнительно невысокий, близкий к комфортному темп и бежал с ним почти всю дистанцию. Тем не менее, результат меня приятно удивил, так как оказался на минуту быстрее предыдущего Весеннего полумарафона в апреле ⏱️
И вот теперь моя коллекция медалек этой серии пополнилась ещё одной, шестой по счёту. Да, это далеко не все 10, но среди них есть самая первая, за 2017 год, поэтому мне всё же приятно ощущать себя частью этой большой, правильной и позитивно заряженной истории 🌅
Ну а пока этот заряд ещё греет, сжимаем зубы/булки/кулаки/пр. и погнали трудиться дальше 👷♂️
"Чем горячей была работа,
Тем краше день ваш выходной"
© М. Бернес
#спорт
Дорогой ИИ, спасибо за то, что помогаешь мне писать код, беря на себя часть работы, например, генерацию всякого рутинного кода.
Но если ты и дальше будешь генерить getter'ы и setter'ы такими, то я уж лучше как-нибудь по старинке...
public static boolean isWriting(boolean isWriting) {
return isWriting;
}В сегодняшнем выпуске рубрики #инструменты хочу поделиться сайтом EndOfLife.date — агрегатором сведений о сроках поддержки версий всевозможного ПО: от стандартов и языков программирования до браузеров и офисных программ 🗄
По нему можно быстро выяснить, когда превратится в тыкву ваша версия сервера, СУБД или ОС. А заодно узнать, когда вообще выходили мажорные версии, и какие у них даты истечения поддержки. И всё это без продирания через разношёрстную документацию каждого вендора 📚
На сегодня в каталоге числится 455 программных продуктов. Доступ к их сведениям можно получить не только руками через браузер, но и через REST API, а для особо занятых есть возможность экспортировать данные каждого продукта в iCalendar 📆
Последнее может быть особенно полезно, чтобы в день, когда ваш основной фреймворк окончательно перестанет поддерживаться, разослать всем мудрое: "А ведь я предупреждал!" 👴🏼🧙🏻
In-memory графы на Java — от теории к практике ⚒️
Готовые инструменты, да ещё open-source, — это, конечно, здорово. Но реальность обычно такова, что ни один из них не подходит на 100%. Так было и у меня на недавнем проекте. Поэтому пришлось собирать Франкенштейна:
1️⃣ Основная часть — на Guava Graphs
2️⃣ Отдельные упоротые специфичные кейсы — на JGraphT
3️⃣ Часто востребованные алгоритмы — (полу)самописные
Поясню такой выбор.
1️⃣ Guava Graphs оказалась хороша по трём причинам:
— максимально человеческий API: интуитивно понятный, почти без неожиданностей, хорошо документирован;
— гибкость построения графов: можно указать что надо, а что нет, и не "переплачивать" за ненужные фичи;
— стандартный набор прелестей: большое сообщество, много примеров, регулярные обновления.
2️⃣ Без JGraphT не удалось обойтись из-за того, что:
— нужно уметь экспортировать граф в другие форматы (GraphVizDot, GEXF) для отладки и верификации (см. приложенный скринкаст);
— нужно исполнять нетривиальные алгоритмы, которых нет в Guava, например, выявлять путь образования циклов.
В принципе, JGraphT покрывает и функционал Guava, поэтому можно было обойтись только им. Но помимо всяких полусубъективных факторов (типа удобства API и полноты документации) я не стал так делать потому, что JGraphT расценивает ребра графа как полноценные его сущности и потому создаёт в памяти объект под каждое ребро. А в Guava есть возможность этого не делать и выражать ребра атрибутами вершин 🔖
В нашем случае рёбра отражают однотипные отношения между ячейками таблиц, поэтому не нуждаются ни в лейблах, ни в других свойствах, а значит, не обязаны быть объектами, и это здорово экономит память. Судите сами — сейчас на одном из серверов заказчика расклад по графу такой:
• 516К вершин (ячеек)
• 1,1М рёбер (связей между ячейками)
• 500 Мб занимает граф в памяти 🪙
Согласитесь, это уже не мало. А если бы мы взяли JGraphT, и на каждое ребро создавали бы по объекту в куче, цифры были бы куда более жуткими... 🙈
3️⃣ Собственные алгоритмы потребовались в тех местах, где Guava ничего не предлагает, а конвертировать граф в формат JGraphT неоправданно дорого. Пример такого места — топологическая сортировка, которая нужна при каждом вычислении зависимых ячеек или при полном пересчёте всей таблицы 🔗
Изначально я взял для этого готовый алгоритм с GitHub. Он работал чётко, но выдаваемый им результат можно было исполнять только в один поток, а в наших масштабах этого оказалось недостаточно: таблица на 16,5К ячеек с формулами обсчитывалась 51 секунду. Тогда пришлось менять его на самописный алгоритм, пригодный для исполнения на множестве ядер 🪵
Конечно, слово самописный тут требует кавычек, ибо в 2026 году вряд ли имеет смысл писать такие вещи с нуля. Вместо этого основа реализации создавалась в обнимку с ИИ, а потом дорабатывалась напильником под (порой суровые) реалии целевого проекта 🪚
Заодно с этой доработкой открылись глаза пути оптимизации, позволяющие избегать многих вычислений, исход которых известен заранее. Благодаря этому, обсчёт той же массивной таблицы сократился с 51 сек. до 2 сек. 📉
—
Не скажу, что строение этого Франкенштейна меня полностью устраивает и не подлежит пересмотру. Вопросики к нему есть. В частности, одна строчка в
build.gradle.kts, добавившая зависимость от JGraphT, увеличила размер финального артефакта приложения на 5+ Мб. Стоило ли оно того — вопрос ещё открытый... 🤔
P.S. Приложенный видосик — скринкаст из программы Gephi, о которой я рассказывал в Полке около года назад. На нём запечатлён "игрушечный" граф на 11К ячеек, полученный экспортом (через JGraphT) из нашего приложения не под нагрузкой. Он вам что-нибудь напоминает? 😉
P.P.S. Если вам интересно подробнее почитать про реализацию топологической сортировки, поставьте под этим постом "🤓".Repost from Spring АйО
🍃 Владимир Плизга & Spring АйО
Продовые heap-дампы, конечно, штука полезная, пока вместе с ними не утекают логины, пароли и прочие сюрпризы для ИБ.
В нашем блоге вышла статья от Владимира Плизга — друга Spring АйО и автора, который умеет разбирать сложные JVM-темы без лишнего шума и магии.
Статья о том, как анализировать heap-дампы с прода и при этом не тащить за собой лишние риски:
🔘где в дампе могут всплыть sensitive-данные;
🔘как это проверять на практике;
🔘чем дезинфицировать дампы перед передачей;
🔘и когда брать Eclipse MAT, heap-dump-tool или hprof-redact.
Материал особенно полезен тем, кто работает с JVM, production-инцидентами, OutOfMemory и performance-разбором не только в теории.
🎂 У Владимира Плизга и Алексея Рагозина есть курсы по оптимизации производительности приложений на JVM. Инфа тут.
📎 Читать на Хабре: https://habr.com/ru/companies/spring_aio/articles/1031462/
Обещанный следующий пост выйдет чуть позже, а пока — минутка техники безопасности ⛑
На тренинге по анализу дампов памяти я упоминаю про обфускацию конфиденциальных данных, которые могли попасть в дамп, если он снят с боевого приложения. В подробностях я этот момент не освещаю, хотя он весьма важен и может предотвратить серьёзные проблемы 🚫
Тем, для кого эта тема актуальна, теперь можно погрузиться в неё глубже — на Хабре вышла моя новая статья в блоге у ребят из Spring АйО 👇🏼
Что есть в Java для работы с графами? 🕸
В предыдущем посте упоминался некий движок вычислений на основе графа ячеек (для электронных таблиц). По следам его создания хочу поделиться с вами списком отсмотренных мною opensource-библиотек на #Java для построения и обработки графов в памяти одной машины (т.е. графовые СУБД вне обзора) — вдруг кому пригодится 👀
JGraphT — серьёзный инструмент для серьёзных задач. Содержит реализации множества алгоритмов над графами и кучу интеграций с различными форматами. Хорошо подходит, если требуется глубокая аналитика, а экономия вычислительных мощностей не в приоритете 🚚
Apache Commons Graphs — формально вроде как вариант, но надпись "Last Published: 17 June 2011" на главной странице говорит сама за себя 💀
JUNG (не путать с JUG) — тоже весьма пожилой проект, который едва ли стоит рассматривать всерьёз, однако жизнь там всё-таки теплется за счёт того, что на этом проекте обкатываются всякие экспериментальные алгоритмы и фичи, которые, если приживаются, могут переехать в... 👇🏼
Guava Graphs — компонент одной из самых популярных Java-библиотек в дикой природе. Имеет немало общего с JUNG за счёт одного и того же разработчика. Предоставляет базовый API для работы с графами и минимальный набор готовых алгоритмов; например, умеет детектировать циклы в направленных графах, но не умеет строить их пути. Содержит немало фишек для оптимизации потребляемых ресурсов, например, учёт связей ячейки с самой собой 🪺
FastGraph — не Java, а Kotlin, но какая разница? А разница в скорости обхода — по словам автора, эта библиотечка при обходе в глубину уделывает Guava в 68 раз и JGraphT в 44 раза. Проект очень молодой (меньше года) и пока без большой аудитории, но, как видите, весьма амбициозный 🚀
(самоделка) — в целом, тоже вариант, если чётко понимать, в чём плюсы и минусы такого решения. За основу можно взять готовые наброски из Интернета или, конечно же, попросить ИИ 🤖
Есть и другие, более экзотичные решения, которые я не рассматривал. Если у вас был опыт работы с ними, расскажите, пожалуйста, в комментариях — будет интересно об этом узнать 🙌
Что из этого списка (и в каком виде) пригодилось мне в том проекте расскажу в следующем посте 📻
+3
Помимо начала Java конференции JPoint (кто уже там — шлите фотки!), сегодняшний день примечателен долгожданным релизом платформы AggreGate, над которой я нынче тружусь 👷♂️
В нём было исправлено несусветное количество багов (а сколько ещё добавлено🤭), а также реализовано несколько мощных фич, каждая из которых могла быть стать поводом для отдельного мажорного релиза 💪🏼 (но мы не ищем легких путей)
Из того, к чему довелось приложить руку мне:
— новый компонент Электронные таблицы (а-ля Excel/Google Sheets): там я отвечал за всякие хитрые кастомные функции, а также реализацию параллельного движка вычислений на основе графа ячеек 🪧
— переработанный Редактор выражений: в нём я реализовал всю бэкенд часть от построения многослойных деревьев вычислений в памяти до отдачи точечных результатов клиенту в ленивом режиме (чтобы не потопить) 🌳
Подробнее об этих и других фичах можно почитать в пресс-релизе: https://aggregate.digital/ru/news/release-64.html 🗞
Зная объём и сложность сделанных доработок, мне думается, что выпуск такого релиза — это только первые 90% работы над ним. Дальше, с помощью обратной связи пользователей, его предстоит как следует причесать и стабилизировать 🛠
Наверняка это будет не просто, но, как говорится, дорогу осилит идущий 🙂
Вопрос к знатокам #Java ❔
Что обозначает буква
D, используемая в качестве префикса кастомных JVM-опций?
(типа -Dcom.myapp.someFlag=true)
Я нередко прошу наших инженеров (пользователей разрабатываемой платформы) добавить в файл vmoptions ту или иную кастомную опцию, поддерживаемую бизнес-логикой. Они добавляют и тут же приходят жаловаться, что приложение теперь вообще не стартует, потому что unrecognized VM option... 😵💫
Приходится объяснять, порой извиняясь, что все такие опции нужно предварять не только дефисом, но и префиксом D, так как они кастомные. Они добавляют, всё начинает работать, но потом в догонку всё же спрашивают, а что означает эта дурацкая неочевидная буква? 🧐
Тут я включаю режим JVM-эксперта и такой:
Эээ... Ммм.. Нуу... Это от слова... "Dopolnitelno" 🤓
На просторах нижнего интернета появились якобы материалы наших курсов с Алексеем Рагозиным, которые можно приобрести по весьма скромной цене, в том числе вскладчину 🧱
Пожалуйста, не ведитесь на эту дичь 🦆
Дело в том, что многие материалы давно прошедших тренингов можно получить и бесплатно; достаточно попросить их у нас напрямую. А материалы новейших занятий (например, по мониторингу и метрикам JVM) всё ещё находятся у нас в проработке, поэтому не были и не могли быть слиты ни в каком адекватном виде 💎
Будьте бдительны и помните про сыр 🪤
P.S. Но если там что-то годное, скиньте мне тоже позырить 🤭👀
Одна из главных ценностей больших конференций (для меня) — возможность узнать, что вообще происходит в индустрии. Вот только сделать это через посещение отдельных докладов сложновато, если вообще возможно 🧠
Хорошо, что на JPoint для этого есть State of Java — отдельное выступление, полностью посвященное состоянию IT-ландшафта в релевантной нам части — в Java. Там можно как увидеть общий расклад, так и почерпнуть несколько интересных (порой забавных) инсайтов по узким темам 😉
Но чтобы представленные там результаты были адекватными, нужно охватить как можно больше респондентов, то есть, в том числе, нас с вами 👀
Для этого призываю вас пройти этот опрос от JUG.Ru, если вы причастны к разработке на Java: https://survey.jugru.org/soj2026 📋
Он не маленький (у меня ушло минут 20), но ради общего дела стоит это время потратить ✊
И даже если вы не собираетесь на ближайшую JPoint, всё равно имеет смысл заполнить, так как после конференции подробные результаты опроса будут разосланы всем его участникам 📩
Repost from Spring АйО
🍃 Когда тормозит Java? Владимир Плизга. Алексей Рагозин. Павел Кислов | Spring АйО Подкаст №59
😉 СМОТРЕТЬ НА YOUTUBE
😄 СМОТРЕТЬ В VK ВИДЕО
🥰 СМОТРЕТЬ НА RUTUBE
🗯 Чуть позже...
🤩 СЛУШАТЬ НА SPOTIFY
🤩 СЛУШАТЬ НА APPLE PODCASTS
💬 Аудио версию подкаста можно найти в комментариях
Available now! Telegram Research 2025 — the year's key insights 
