Gregory Koshelev channel

На следующей неделе стартуем 11-й сезон Podlodka Techlead Crew.
В этот раз мы выбрали темой сезона "Техлид в эпоху AI", потому что хотим обсудить, как изменились работа техлида и процесс разработки, когда большую часть кода уже пишет AI.

У меня есть пара бесплатных билетов на конференцию для друзей. Кто хочет, пишите в комментариях 👇 вместе с интересным кейсом ИИ-трансформации или применения AI в разработке, а я подарю билет тому, чья история мне будет ближе. Я бы хотел расстаться с билетами до субботы 🙂

#анонс #podlodka #techlead #ai

Java 25

Год назад обещал рассказать про Java 25, а тут уже неделю как Java 27 зарелизилась. Зато можно сверить свои прогнозы с последними исследованияии.

Материалы:
— Дискуссия «Горячие JEP’ы 25: юбилейное» на JPoint 2025:
* YouTube
* VK Видео
* Презентация
— Доклад «Есть время объяснять, переходим на Java 25» на Podlodka Java Crew:
* YouTube
* Презентация

LTS-версии Java:
— Java 11 — 2018
— Java 17 — 2021
— Java 21 — 2023
— Java 25 — 2025

На новые LTS мигрируют независимо от того, насколько значимые изменения были в этой версии. По результатам исследований видно (см. презентацию выше), что старые версии продолжают использоваться на протяжении долгого времени («хвост» медленно усыхает), но «мейнстримная» версия сменяется приблизительно через 3 года с момента релиза.

За последние годы значимых изменений в самом языке было немного, а основной фокус был направлен на внутренние изменения (JVM) и развитие библиотеки классов (API, реализация). Таким образом, переход на новую версию обусловлен либо естественным обновлением на свежую версию, либо качественным отличием рантайма. Мой прогноз из 2025 года: переход на Java 25 будет идти более высокими темпами как раз благодаря второго пути. Во-первых, в экосистеме Java сложилась уникальная ситуация — среда исполнения поддерживает несколько алгоритмов сборки мусора, нацеленных на разные аспекты производительности (пропускная способность и латентность приложений). Во-вторых, в Java «доезжают» JEP-ы, задуманные 10-15 лет назад (или ещё раньше), но реализация которых была осложнена заботой о «священной корове» Java (сохранении обратной совместимости).

Возвращаясь к теме GC: на текущий момент у нас есть выбор из 4-х production ready сборщиков мусора:
— Parallel GC, максимизирующий throughput приложения за счёт минимального оверхеда.
— ZGC, минимизирующий паузы в приложении, хорошо подходит для огромных хитов.
— G1GC — отличный сборщик мусора по умолчанию (читай — для общего случая, когда heap < 32GB), нацеленный на некоторый баланс между throughput и latency, смещённый в сторону пропускной способности приложения. В самой свежей версии JDK 27, вышедшей буквально неделю назад, благодаря JEP 532, G1GC стал сборщиком мусора по умолчанию для всех вариантов развёртывания.
— Shenandoah — ещё один GC, нацеленный на баланс между пропускной способностью и паузами, но нацеленный на обеспечение коротких пауз в том числе на больших хипах.
Выбирайте подходящий алгоритм GC в зависимости от профиля нагрузки. При этом важно не только погонять на обычном уровне нагрузке, но и на экстремальном (когда из кластера реплик выпадает их часть, когда случается наплыв пользователей из-за 11.11 и т.п.).

Как я уже упомянул выше, в прошлом году при обсуждении Java 25 я прогнозировал более высокую скорость распространения. И вот, спустя полгода-год, при подготовке State of Java 2026 мы видим, что этот тренд подтвердился. Причин этому много, но самое главное: Java (JVM) ускоряется прямо «из коробки», когда простая смена версии рантайма позволяет получить прирост в скорости работы. В планах на JPoint 2026 сделать выступление про увеличение производительности JVM на реальных задачах за последние 15 лет.

Чек-лист для перехода на новую версию Java
— BOM (Bill of materials): заявлена совместимость у библиотек и фреймворков, зависимости обновить при необходимости
— Не используется закрытый и удалённый API, перейти на альтернативный API при необходимости
— Провалидировано изменение настроек и поведения по списку JEP-ов
— Проведено функциональное и performance тестирование, проведено сравнение результатов «до» и «после»
— Обновлены инструкции по эксплуатации (метрики, GC, ...)
— Новые фичи используем в следующую итерацию!

И переходим на Java 25+ в проде, дамы и господа! 🎉

#java #jvm #материалы #видеозаписи #доклад #jpoint #podlodka

Метрики, которые нам врут: от идеального Observability к провалу DORA?

В прошлом году на DevOops Григорий Кошелев учил нас наводить порядок в инфраструктурном хаосе — пояснил за Observability распределенных систем. Мы увидели как следить за тысячами сервисов, чтобы не сойти с ума во время ночных инцидентов.

Помните этот хардкор? Если пропустили - самое время пересмотреть:

📺 Смотреть на YouTube | 📺 VK Видео

Казалось бы, техническая видимость настроена, трейсы крутятся, логи мутятся. Что дальше? А дальше начинается:
А теперь давайте измерять эффективность DevOps-процессов! Внедряем DORA-метрики!.
(С) Эффективный менеджер

На бумаге Deployment Frequency, Lead Time for Changes и MTTR звучат как серебряная пуля и индустриальный стандарт. Но как в реальности мы узнаем в его новом докладе на DevOops 2026 — «DORA-метрики: история провала?».

В шестом DevOops Podcast мы приоткроем занавес доклада и обсудим как все ломается о суровую реальность процессных метрик.

В прямом эфире обсудим:
• Почему измерить работу кластера проще, чем измерить работу инженера?
• Как разработчики начинают «хакать» DORA (привет, пустые коммиты ради частоты деплоя)?
• В какой момент внедрение «стандартов DevOps» ломает инженерную культуру и превращается в карго-культ?

Главный спойлер к новому докладу: почему DORA провалилась и что использовать вместо нее, чтобы не врать самим себе?

Присоединяйтесь к нам 18 сентября в 18:00 (МСК):

📺 YouTube

Готовьте вопросы заранее и пишите их в комментариях к этому посту! Как у вас обстоят дела с DORA-метриками? Помогают или бесят? Самые острые боли разберем в эфире!

Спонтанный подкаст с ребятами из ПК DevOops про Observability и DORA-метрики сегодня в 18:00 МСК (трансляция будет на YouTube).

Из новостей по теме:
— на DevOops 2026 буду рассказывать про опыт внедрения DORA-метрик (расскажу, что получилось и что не получилось в итоге)
— а это вообще эксклюзив: с этого сезона присоединился к ПК DevOops, где буду помогать спикерам с подготовкой докладов про Observability и SRE.

#анонс #observability #devoops

В ПК JPoint готовим State of Java 2026.
Вот тут можно заполнить опрос, чтобы помочь в сборе статистики.

На JPoint 2026 покажем результаты исследования и выводы.

Подробности в посте в канале конференции.

#анонс #java #jpoint #techradar

Небольшая заметка про спортивное программирование.

Завершился финал Северной Евразии по спортивному программированию в рамках ICPC 2026:
— Всего участвовало 318 команд из России, Беларуси, Средней Азии и Закавказья.
— Первые три места заняли команды ВШЭ (Москва).
— Среди российских команд в ТОП-30 попали 4 команды не из Москвы и Санкт-Петербурга: ЧелГУ (Челябинск) — 7 место, НГУ (Новосибирск) — 8 место, УрФУ (Екатеринбург) — 19 и 28 места.
— На финал ICPC 2026 от североевразийского региона поедут 16 команд, среди которых 11 — команды российских вузов (от одного вуза может поехать только одна команда).

Таблица с результатами финала тут: https://nerc.itmo.ru/archive/2025/standings.html

#icpc

Позвали на ближайшую онлайн-конференцию Podlodka Java Crew рассказать про переход на LTS-версию Java 25.
Своему выступлению дал название "Есть время объяснять, переходим на Java 25". Планирую расскзаать, почему Java 25 — подходящий релиз для миграции* не только для Java-программистов, но и для тех, кто эксплуатируют различные инструменты, написанные на Java (это различные Кассандры, Кафки, Эластики).

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

*) спойлер: далеко не каждый такой инструмент готов сейчас к миграции. Это тоже обсудим.

#анонс #доклад #java #podlodka

За последние несколько дней было три атаки ботов на канал. Самая масштабная была позавчера (13 октября): 1к+ ботов подписались, поставили рандомных реакций (особенно любят какашки и слёзы). Вчера исчезли оставшиеся боты (выпилены из телеги?), а какашки реакции остались. На данный момент цель акции не ясна, но мы продолжаем следить за ситуацией. ✍️

На публикацию материалов это никак не повлияет. Из ближайшего планирую написать про:
— Observability распределённых систем (по мотивам доклада с DevOops, сильно переработанная версия с Podlodka Techlead Crew, материалы предыдущей версии тут).
— Заметка про LTS-версии Java (в первую очередь про мотивацию перехода на Java 25 не только для Java-программистов, но и для тех, кто эксплуатирует Кассандры, Кафки, Эластики и другие инструменты, написанные на Java).
— Подборка материалов про Apache Kafka.
— Заметка про Joker 2025 (интересные доклады, инсайты по мотивам предстоящей конференции).

#офтоп #анонс

Материалы по докладу «JMH: вводный курс по микробенчмаркам» с JPoint 2025:
— Запись доклада на Youtube: https://youtu.be/yjTnuRHtcYw
— Презентация доклада
— Ссылка на примеры микробенчмарков в репозитории JMH
— Репозиторий jmh-crash-course с дополнительными примерами микробенчмарков (из доклада)
— Оригинальная статья (PDF) Дональда Кнута, откуда пошла мода на «Premature optimization is the root of all evil»
— Статья «Java theory and practice: Anatomy of a flawed microbenchmark» от Brian Goetz (Ссылка ведёт на webarchive, потому что IBM сломали все старые статьи)
— Заметка с 8 правилами по написанию микробенчмарков от John Rose
— Статья «Avoiding Benchmarking Pitfalls on the JVM» от Julian Ponge
— Caliper — альтернативный инструмент для написания микробенчмарков на Java, а также пост Алексея Шипилёва, почему не надо его использовать 😅 (ссылка на пост есть прямо в README Caliper)
— Конечно же, блог Алексея Шипилёва — полезно для всех, кто интересуется темой перформанса и внутрянки JVM, в частности статья «Nanotrusting nanotime»
— Запись доклада Алексея Шипилёва «(The Art of) (Java) Benchmarking II»
— Запись доклада Алексея Шипилёва «Java Benchmarking: как два таймстампа прочитать!»
— Гигиенический минимум «6 аннотаций» для вашего микробенчмарка:

@Fork 
@Warmup
@BenchmarkMode
@State
@Measurement
@OutputTimeUnit 

— Для дальнейшего изучения:
* Статья про чёрную дыру в JMH от Алексея Шипилёва
* jcstress (Java Concurrency Stress) — инструмент для поиска concurrent-ошибок
* JLBH (Java Latency Benchmark Harness) — инструмент для измерения latency в Java-приложениях.

#доклад #видеозаписи #материалы #jmh #best_practice #jvm #java #performance #тестирование

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

Ну, а пока анонсы предстоящей недели:
— С 13 по 17 октября пройдёт онлайн-конференция Podlodka Techlead Crew №9, где я и другие коллеги по программному комитету готовим неделю "Архитектурных антипаттернов" (и паттернов тоже). У меня остался один бесплатный билет на конференцию, которым готов поделиться — пишите в комментарии (достанется первому).
— 17-18 октября будет Java-конференция Joker, где я не только в роли ПК, но и в роли эксперта на докладе, где есть Кафка (😅), и спикера на дискуссии про новинки Java ("Горячие JEP'ы 25: юбилейное").
— 19-20 октября будет конференция по тестированию Heisenbug, куда меня позвали экспертом на пару докладов.

#анонс #podlodka #joker #heisenbug #пк

На следующей неделе 29 мая на Podlodka Java Crew №6 рассказываю вводный курс по микробенчмаркам с использованием JMH.

Что будет в докладе:
— Разбор базовых правил написания микробенчмарков на Java/JVM
— Крэш-курс по JMH (quick start, основные фичи, best bractice)
— Разбор множества примеров микробенчарков.

#анонс #доклад #podlodka #java #jvm #performance #jmh #best_practice

Материалы по докладу «Observability распределённых систем» на Podlodka Techlead Crew №8:
— Презентация доклада на GitHub

— Книги
* Mastering Distributed Tracing
* Distributed Tracing in Practice
* серия «Site Reliability Engineering»

— Доклад «В чём (ещё) польза распределённых трассировок?» (DevOops 2022)
* запись на YouTube
* ссылка на сообщение с материалами

— Доклад про Sentry «Работа над ошибками» (DevOops 2020)
* запись на YouTube
* ссылка на сообщение с материалами

— Доклад «Vostok Hercules: 3 года доставляем телеметрию — полёт нормальный» (JPoint 2022)
* запись на YouTube
* ссылка на тред с материалами

— Доклад «SRE и перформанс, или Когда производительность имеет значение» (DevOops 2023)
* запись на YouTube
* ссылка на сообщение с материалами

— Доклады про SLO

— Moira — система алертинга по данным из Prometheus / VictoriaMetrics и Graphite
* репозиторий на GitHub
* документация

— Профилирование приложений на JVM
* запись доклада «Профилирование Java в стиле Linux» (Сергей Мельников, Joker 2024) на YouTube
* презентация доклада «Путеводитель по профилированию приложений на JVM» (Владимир Плизга, JPoint 2025)

— Аннотации (Annotations) — расширенный вид телеметрии (например, события жизненного цикла приложения)
* Аннотации в Grafana
* Аннотации в Elastic APM
* Аннотации в Kibana

— OpenTelemetry
* Статья про профили в OTel
* Схема с потоками телеметрии в OTel
* Репозиторий с примерами использования OTel в Java на GitHub
* Инструментация клиентов Apache Kafka при помощи Open Telemetry https://opentelemetry.io/blog/2022/instrument-kafka-clients/

— Методологии проектирования метрик
* 4 Golden Signals (из SRE Book)
* RED method
* USE method

— Экземпляры (Exemplars) — расширенный вид телеметрии, связываемый с метриками
* Описание модели
* Пример использования в Go (Google Cloud Platform)
* Exemplars в Grafana

— Сэмплирование трассировок
* Хвостовое сэмплирование (tail-based sampling) в OTel
* Документация и настройка
* Issue на GitHub про проблему сэмплирования связываемых трассировок (трассировки связываются через Span Link)

— Создание метрик из трассировок
* Статья про использование коннектора SpanMetrics
* Описание коннектора в репозитории на GitHub

— OpenTelemetry Collector — компонент для обработки и передачи телеметрии
* Архитектура
* Масштабирование

#материалы #видеозаписи #книги #moira #distributed_systems #телеметрия #open_telemetry #observability #podlodka #techlead #best_practice

На этой неделе идёт онлайн-конференция Podlodka Techlead Crew, посвящённая теме межсервисного взаимодействия. В четверг 10 апреля расскажу про Observability распределённых систем.

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

P.S. Есть ещё один бесплатный билет, чтобы залететь на конференцию. Пишите в комментарии — поделюсь.

#анонс #доклад #podlodka #observability #телеметрия #sre #open_telemetry #moira #graphite #grafana #prometheus #sentry #elastic #kibana #techlead

State of Java 2025 на JPoint от Кирилла Толкачева. 3 из 4 используют #kafka! 🤟

На ближайшем JPoint 3 апреля расскажу вводный курс по микробенчмаркам с использованием JMH.

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

#анонс #доклад #jpoint #performance #jmh #best_practice #jvm

Сижу на чьём-то докладе. Название ещё странное: "Кафка. PRO. ", а дальше в названии то ли "Время умирать", то ли "Время убирать" — шрифт и цвета какие-то убогие — не смог разобрать. Ещё подумал, как Володя Ситников такое пропустил? Но спикер бодро начинает, какие-то вопросы в зал задаёт, а я на них отвечаю. А потом мои же ответы дополняет — да всё складно так выходит, словно мы специально всё это готовили, хотя я его впервые в жизни вижу. Но потом докладчик начал какой-то лютый бред нести (уже не могу восстановить детали — какие-то фантастические сценарии для Кафки придумывал). В итоге я Алексею Андрею Кулешову говорю: "я это слушать больше не могу", и вышел из зала. Захожу в главный зал, а там почему-то выставка (!) унитазов (!), а на сцене Алексей Мерсон (я ещё удивился, почему он пришёл на JPoint, но решил, что его ведущим позвали, а я это пропустил вместе с каким-то синком ПК). В общем, я прохожу мимо всех этих унитазов к первому ряду и спрашиваю:
— Почему тут выставка унитазов?
Лёша со сцены отвечает:
— Какое поколение — такая и выставка.
А я ему тут же:
— Молодое поколение или старое?
После моего вопроса зал ржёт (а я ещё думаю, что шутка норм — надо запомнить).
Тут на сцену поднимаются Андрей Когунь, Алексей Фёдоров и ещё кто-то — типа собрались эксперты, чтобы ответить на вопросы из зала, а зал вопросы почему-то не задаёт. Ну, я руку тяну и обращаюсь к Андрею:
— Андрей, нормально ли вместо вызова Thread.yield делать прогрев?
Андрей берёт микрофон в две руки, смотрит на меня и молчит, и в зале тишина. Я уточняю:
— Ну, прогревочные итерации вызывать вместо метода yield.
Вижу, что и Лёша Мерсон на меня смотрит и не понимает, так я ему объясняю:
— В Java у Thread-а есть метод yield, который подсказывает планировщику, что можно тред снять с выполнения. А раз мы так и так готовы снять тред с выполнения, то почему бы не прогреть вместо этого нужный нам код.
И тут... я просыпаюсь... так и не узнав, что @akogun думает о прогреве вместо Thread.yield.

Завтра я и Андрей Когунь на Podlodka Java Crew выбираем для разработки приложений Spring фреймворк под конкретные задачи:
— Spring (не нуждается в представлении)
— Micronaut
— Quarkus
— Helidon.

По сути в Java-мире две экосистемы для разработки web-сервисов: Spring и Jakarta EE (ex Java EE). И MicroProfile — естественное развитие Jakarta (расширение дополнительными стандартами), нацеленное на разработку микросервисной архитектуры и cloud-native приложений. MicroProfile помимо совместимости с Jakarta EE включает (но не ограничивается) такие компоненты как телеметрия, конфигурирование, JWT, инструменты отказоустойчивости (типа механик повторов запросов, таймаутов, circuit breaker и т.д.) и другие.
Quarkus, Helidon и Micronaut в той или иной степени поддерживают стандарты MicroProfile. Например, Quarkus на 100% совместим с MP 4.1, а Helidon — с MP 5.0, MP 6.0 и MP 6.1.

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

Если говорить не про концептуальные особенности, а архитектурные, то можно обратить внимание на использование HTTP-серверов, основанных на Netty (Quarkus-Vertx, Micronaut и ранее Helidon). Про это имеет смысл написать отдельный пост в контексте моего доклада про Undertow, т.к. доклад уже доступен публично и можно поделиться материалами.

При этом Spring был и остаётся хорошим выбором "по умолчанию" благодаря своей популярности и тому, что внутрь экосистемы затащили практически всё. Любой другой выбор необходимо обосновывать — вот этим и займёмся за круглым столом.

#анонс #java #spring #microprofile #quarkus #helidon #micronaut #netty #vertx

Публичное собеседование техлида на Podlodka Techlead Crew и дополнительные материалы.

— Видео собеседования на YouTube: https://youtu.be/xcR56HPM51w.
— Репозиторий с примерами архитектур распределённых систем: System Design Primer (в частности, для интервью за основу была взята задача Web Crawler).
— 8 заблуждений о распределённых вычислениях:
1. Сеть надёжна;
2. Сетевая задержка равна нулю;
3. Пропускная способность не ограничена;
4. Сеть защищена;
5. Топология сети не меняется;
6. Есть один администратор;
7. Транспортные расходы равны нулю;
8. Сеть (и вычислительные узлы) однородна.
— Архитектурные шаблоны в распределённых системах:
* Большой источник материалов по микросервисной архитектуре — https://microservices.io/,
* Сборник Patterns of Distributed Systems (Unmeshi Joshi и Martin Fowler).
— По теме Non-Functional Requirements (NFR):
* статья «10 nonfunctional requirements to consider in your enterprise architecture» (RedHat) ,
* гайд по сбору нефунциональных требований (Microsoft).
— По теме SLA/SLO:
* видео доклада Даниила Марданова «Как внедрить SLO в продукт и получить от этого пользу» на DevOops 2023,
* видео моего доклада «SLA — друг или враг разработчика» на DevOops 2021.
— Полезные ссылки по использованию PostgreSQL:
* документация по High Availability, в частности сравнение подходов по репликации,
* сравнение способов балансировки запросов в PostgreSQL.
— Полезные ссылки про Redis:
* сравнение Redis Cluster и Sentinel,
* пример использования Redis в качестве очереди.
— Использование GeoDNS для минимизации сетевых задержек в крупной геораспределённой системе (особенно актуально в задаче Web Crawler, где необходимо совершать обход множества сайтов, имеющих непредсказуемое географическое распределение):
* документация на GeoIP и GeoLite 2,
* пример определения локации по IP на Java.
— Комментарий про латентность сети. Скорость света в вакууме в полтора раза выше скорости света в оптическом волокне (~300 000 км / с против ~200 000 км / с). В реальности RTT (Round-Trip Time) выходит значительно выше, т.к. нужно учитывать кривизну проложенных оптических магистралей, задержку передающего и маршрутизирующего оборудования:
* RTT Екатеринбург – Москва — 20-30 мс (теоретический минимум исходя из расстояния «по прямой» в 1 400 км в одну сторону — 14 мс),
* RTT Екатеринбург – Лондон (3900 км в одну сторону) составляет 70-75 мс,
* RTT Екатеринбург – Сан-Франциско (~ 11 000 км) — 180-200 мс.
— Bloom Filter — вероятностная структура данных, которая упрощает поиск данных в крупных системах (позволяет быстро отсекать походы на диск и/или в сеть туда, где этих данных точно нет, т.е. исключает false negative сценарии, но допускает false positive). Примеры использования: Apache Cassandra и PostgreSQL.

#видеозаписи #материалы #собеседование #архитектура #slo #highload #distributed_systems #techlead #podlodka

У нас тут прошла внутренняя Конференция инженеров-программистов

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

Спросили у создателей конференции Гриши Кошелева и Андрея Эйдинова, как и зачем они придумали КИП. И подкрепили отзывами контуровцев.

Фото прилагаются. Ну а то, что было на фейл-секции, остается на фейл-секции 🤐

23 октября провели внутреннюю конференцию инженеров-программистов, где я выступил в роли программного директора. По обратной связи в ТОПе оказалась фейл-секция из 6 выступлений ребят из Контура и Яндекса, заняв второе место в рейтинге, уступив только эпичной истории переезда всей компании из Slack в Mattermost. Впрочем, это не удивительно: хорошо учиться на ошибках, особенно, если это чужие ошибки. 😀
Во время подготовки было некоторое волнение, поскольку фейл-секцию проводили под конец конференции в формате стендапа, а ещё всё это было под пиво и пиццу. В общем, "шалость удалась".

А за организацию фейл-секции я взялся неспроста: на следующей неделе 13 ноября выступаю на DevOops с историей "Комбо-факапы, или Эффект бабочки-факапницы".

#анонс #пк #кип #devoops #факапы