В канале конференции HighLoad++, на которой я выступал месяц назад, начали публиковать топ-15 докладов по отзывам слушателей. Всего в программе конференции было более 100 докладов 📚

И если в 2022-ом на той же конференции мой доклад "Экскурсия в бэкенд Интернета вещей" внезапно оказался в рейтинге 2-ым, то нынче, вопреки ожиданиям, доклад про подсистему отладки в low-code-платформе не только не вошёл в топ-15, но и вообще не попал в рейтинг, потому что собрал слишком мало оценок. При этом сами средние оценки доклада получились не особо низкими: 4,56 за контент и 5,00 за подачу 🎰

Из этого напрашивается вывод, что сам доклад вышел неплохим, но люди до него дошли. Причины можно условно поделить на две группы — зависящие от докладчика и не зависящие:

1️⃣ К первым я бы отнёс время доклада: первый слот во второй день (10:00). Для кого-то это в принципе рановато, а кто-то мог "не выжить" после афтепати предыдущего дня. С этим мало что можно поделать, разве в следующий раз всё же просить программный комитет не ставить доклад в это время (как будто в этот раз я не просил, ха-ха).

2️⃣ Ко вторым относятся выбранные мною название доклада и его секция. Секцию я выбрал т.н. "Узкотематическую", хотя подходили и другие; видимо, это было промахом. А вот название я взял предложенное моим куратором из ПК и не особо подвергал его критике, хотя, видимо, стоило. Например, можно было вспомнить про тест на годность названия, предложенный Володей Ситниковым в кулуарах конференции JPoint (в апреле в Москве). Этот тест сводится примерно к такому вопросу:

Подумай, что будет гуглить разработчик, столкнувшийся с такой же проблемой/вопросом, как ты описываешь в докладе, и выпадет ли ему твой доклад при текущем его названии?

Видимо, в следующий раз надо будет пройти этот тест заранее, а заодно, быть может, и проверить понятность/привлекательность названия на потенциальной аудитории, например, с вами.
Вы же не против, правда? 😉

Наверняка эта задачка входит в число хрестоматийных и встречается на собеседованиях по #Java, но поскольку я по ним не хожу, пришлось убить часок на разбирательство с ней. Поделюсь с вами; вдруг кто-то тоже встретит.

🎓 Дано
Ванильный пул потоков на голом JDK (аналоги из класса Executors не подходят):

var threadPool = new ThreadPoolExecutor(
  corePoolSize,  // 3
  maxPoolSize,  // 30
  keepAliveTime,  // 60
  TimeUnit.SECONDS,
  new LinkedBlockingQueue<>(maxQueueLength), // 100
  Executors.defaultThreadFactory(),
  new DiscardPolicy());  // could also be a logging implementation

И некий метод, который сначала просто напихивает задачки в этот пул:

List<Future> futures = new ArrayList<>();
futures.add(threadPool.submit(task));

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

for (Future future : futures) {
  try {
    future.get();
  }
  catch (Exception e) {
    log.error("Failed to get task result from future", e);
  }
}

🔍 Найти
Какого _🙊_ в некоторых случаях метод намертво зависает на вызове future.get()?
При этом в дампе потоков нет никаких следов задач, которые бы зависли/зациклились/заблокированы.

🔑 Решение
Вариант 1. Добавить таймаут в метод future.get(). Да, это решит проблему, но не даст понять, почему она появилась.

Вариант 2. Извернуться как-нибудь так, чтобы прийти к вызову вида CompletableFuture.allOf(c1, c2, c3).join(). Наверняка так можно (не проверял), но выглядит избыточно сложно, должно же работать и так.

Вариант 3. Обернуть вызов future.get() вот в такое условие:

    if (future.isDone()) {
      future.get();
    }

Казалось бы, смысла в нём нет, ведь если задача не завершена (isDone() == false), то мы просто дождёмся её завершения при вызове get(). Но нет. Когда мы имеем дело с ThreadPoolExecutor, то при вызове submit() он в качестве имплементации Future возвращает экземпляр FutureTask, у которого метод isDone() выглядит так:

    public boolean isDone() {
        return state != NEW;
    }

, то есть "сделанной" считается любая не новая задача (в том числе когда она ещё в работе).

А метод FutureTask.get() устроен так:

    public V get() throws InterruptedException, ExecutionException {
        int s = state;
        if (s <= COMPLETING)
            s = awaitDone(false, 0L);
        return report(s);
    }

, то есть ожидание наступит для любого состояния, предшествующего завершению, в том числе для вышеупомянутого NEW (на самом деле только для NEW и COMPLETING).

Но если бы задача, на которой завис наш поток, была в состоянии COMPLETING, мы наверняка увидели бы соответствующий ей поток в дампе, а раз его нет, значит, она в NEW.
А как она могла оказаться NEW, если все задачи вроде как были переданы пулу на исполнение? Видимо, он её не взял. А почему не взял? Правильно — из-за переполнения очереди, ведь она ограничена (new LinkedBlockingQueue<>(maxQueueLength)). А почему тогда это не привело к ошибкам и прерыванию всего процесса? Верно, из-за с виду безобидной new DiscardPolicy(), которая просто дропает не влезшие задачки (и логирует их, как было в нашем случае).

✅ Вся цепочка кратко:
— не влезающие в очередь задачи молча отбрасываются политикой пула, оставляя им статус NEW;
— видя этот статус, метод future.get() впадает в бесконечное ожидание;
— исключить ожидание можно добавлением проверки на NEW в виде вызова future.isDone().
⚠️ Если очередь будет большой, а задачи — долгоиграющими, можно нарваться на случай, когда задача уже в очереди и имеет шанс быть выполненной, но цикл с вызовом get() её не подождёт. В этом случае решение должно быть другим.

Мораль: пишите однопоточные приложения🤪

Давно обещал рассказать вам об очередной программной поделке, идеей которой загорелся ещё в конце прошлого года — Telegram-бот для поиска своих фоток в больших открытых альбомах 👨‍💻

Мотивация проста:
— я часто участвую в массовых мероприятиях, где работают фотографы (в основном, конференции и соревнования, но не только)
— мне хочется сохранять удачные снимки с собой на память
— мне лень/некогда/неохота отсматривать сотни (а то и тысячи) чужих или просто левых снимков 📷

И я задумался:

А есть ли сервис, которому я мог бы просто переправить ссылку на фотоальбом с мероприятия, и он бы сам за меня его отсмотрел (по образцу моей фотки), а мне бы скинул только те фотки, на которых я есть?
И раз в 99% случаев такие ссылки публикуют в Telegram-каналах мероприятий, то в идеале бы как-то делать это, не покидая мессенджер.

Беглый гуглинг не дал подходящих результатов (тыкните меня, пожалуйста, носом, если проглядел), а поскольку дело было в канун Нового Года, я решил: "За время праздников запилю своё! Тут делов-то!" 😎

Стоит ли говорить, что к 9 января было готово меньше половины? Причем, половины разработки. Это я ещё не знал, какое "веселье" ждёт меня при деплое этого счастья в облако. Как бы там ни было, к 1 марта MVP был готов, и я даже успешно презентовал его на Открытом микрофоне преакселератора А:Старт в Новосибирском Академпарке (слайды того питча прилагаю). С тех пор оставалось несколько мелких, но неприятных изъянов, из-за которых мне не особо хотелось делиться сервисом с кем-либо, а чинить их было некогда. И вот только сейчас, будучи в отпуске в Горном Алтае, я добрался пофиксить их с подачи друга, решившего воспользоваться моей разработкой и получившего отлуп 🤦🏻

Сервис и сейчас далёк от совершенства, но базовый сценарий поддерживает:
1. Загрузить своё фото в качестве образца в Telegram-бот: @FramePhotoBot
2. Скинуть боту сообщение со ссылкой на фотоальбом, который нужно отсмотреть (поддерживаются альбомы VK, Mail.Ru, Google Drive, Яндекс.Диск, Wfolio)
3. Подождать*, пока готовые фотки придут в чат 📸

* Поскольку VPS с GPU в России нынче стоит как крыло самолёта, для своего бесплатного сервиса я использую мощности только CPU, поэтому нейросеть, просматривающая фотографии, работает весьма не быстро — обработка огромных альбомов может занимать до десятков минут ⏳

Для справки: основная логика сервиса написана на Kotlin, а вообще под его капотом крутятся запчасти на Java, JS, Go, Python и C++ (я их не писал, только интегрировал) ⚙️

Что предлагаю сделать:
— протестировать сервис (например, поискав себя в большущем альбоме с конференции JPoint 2025: https://vk.com/album-796_308596387) и оставить обратную связь
— поставить реакцию 🤓, если хочется узнать подробнее о внутреннем устройстве сервиса и/или его развертывании
— предложить более удачную картинку для бота🙂

Если вы не первый год в IT, то наверняка замечали, что программные продукты, помимо прочего, отличаются поддерживаемостью: какие-то поддаются правкам и дополнениям легко и естественно, а какие-то — так, будто их писали с единственной целью: "Сбить с толку вероятного противника" 🫡

Но что конкретно делает проекты/продукты поддерживаемыми? Вопрос не тривиальный. Приглашаю найти ответ вместе:


🧪 Исследование для backend-разработчиков
Наши коллеги проводят исследование, посвящённое поддерживаемости кода backend-ов: какие из известных подходов к разработке действительно упрощают жизнь разработчиков.

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

📋 Это займет около 20 минут.
Ваши ответы помогут всему сообществу разработчиков лучше понять, что действительно влияет на поддерживаемость кода — вне зависимости от языка и фреймворка.

📊 Результаты исследования будут опубликованы осенью 2025 года на сайте: https://maintable-backends.tilda.ws/

👉 Принять участие: https://forms.yandex.ru/cloud/685ccc62eb614635657832a4

Заметка для тех, кто, собираясь в отпуск, в первую очередь кладёт в сумку беговые кроссовки 👟

Горный Алтай, на мой взгляд – далеко не самое удачное место для комфортных пробежек: там то бежишь по узкой обочине нагруженной дороги, то корячишься вверх или вниз по ухабистым горным тропинкам. Но поскольку просторы там огромные (а виды и воздух упоительные), найти нормальные места для пробежек всё же можно. Поделюсь своим опытом 👇

Свой первый обзор беговых маршрутов Чемала (с фотками, треками и комментариями) я делал в 2019-ом году. С тех пор они почти не утратили актуальности (разве что траффик стал выше), а я открыл для себя ещё несколько. В дополнение к обзору привожу топ-3 из них в порядке возрастания клёвости.


🥉3 место: Чуйский тракт в районе с. Черга

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


🥈2 место: Катуньское заречье (близ с. Аюла)

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


🥇1 место: Айский тракт

Необъяснимо, но факт: гладкая, ровная, длинная асфальтовая трасса с невысоким траффиком и хорошим приподнятым тротуаром, который ещё и скрывается в тени деревьев (на части пути). Располагается между озером Ая и комплексом баз Бирюзовая Катунь. Не удивительно, что именно там проходит беговой этап ежегодной триатлонной гонки AltaiTriRace. Отлично подходит для скоростной асфальтовой тренировки. Пример трека присутствует.


Кто знает другие годные маршруты в тех краях – welcome в комментарии 👐

#спорт

Лайфхак для performance-инженеров 👷‍♂️

Коротко: Парсить большие heap-дампы для анализа в Eclipse MAT лучше в recovery mode: получается быстрее и стабильнее

Подробно:

Давеча потребовалось распарсить 30 ГБ-ый дамп памяти JVM-приложения для анализа в Eclipse Memory Analyzer Tool (MAT). Для этого в MAT есть отдельный консольный парсер, который тоже, разумеется, работает на #Java 🤭

И поскольку у меня на рабочей машине (Ubuntu 24.04) всего 32 ГБ ОЗУ, встал вопрос, сколько выставить -Xmx (максимальный размер кучи) парсеру, чтобы он (а) не притеснял другие приложения и (б) сам не скукожился от OutOfMemory: Java Heap Space?

Первая попытка выставить 28 ГБ провалилась: парсер был жестко прибит несокрушимым OutOfMemory Killer’ом за попытку аллоцировать слишком много памяти, причем нативной. Для тех, кто не в курсе, почему так происходит, у меня был доклад “Скажите «Ой»: JVM и OOM Killer” – там описан этот механизм ядра Linux и способы избегать столкновения с ним 🔫

Второй была попытка сторговаться на 26 ГБ, и она удалась, правда, ждать пришлось минут 15-20. Оно и понятно, ведь при таком потреблении парсер солидную (если не бОльшую) часть времени провёл не за делом, а в обнимку с GC, пытаясь на лету подчищать за собой объекты. Как бы там ни было, задача была решена, и это клёво ✅

Но уже через пару дней от того же заказчика пришёл новый дамп, на сей раз на 55 ГБ, и стало ясно, что так просто я уже не отскочу 🫠

Не особо веря в успех, я всё же решил попробовать отдать парсеру вообще всю память машины. Но для этого надо как-то заставить ОС не мешаться. А как это сделать? Правильно – Recovery Mode: максимально голый режим командной строки, используемый обычно для восстановления после жестких аварий ОС (в Windows есть его аналог под названием Safe Mode, хотя там графическая оболочка всё равно запускается) ⛑

Выставив в этом режиме -Xmx30G (с отступом на аллокации в нативной части), я был приятно удивлен тем, что парсинг успешно завершился. Больше того, он завершился гораздо быстрее, минуты за три. Видимо, возможность беспрепятственно бросить все 16 ядер CPU на борьбу с мусором позволили JVM максимально эффективно распорядиться памятью и не аффектить производительность прикладного кода ⛲️

Разумеется, здесь есть щепотка везения, ведь пиковое потребление памяти парсером во многом зависит от характера графа объектов в обрабатываемом дампе, а значит, в следующий раз такой трюк может и не пройти 🤹

Тем не менее, Recovery Mode — достаточно простой и эффективный способ превратить ваш ноутбук в настоящую Java-машину, поэтому предлагаю взять на заметку ✍️

Тот случай, когда в написанном слове точно есть одна из двух опечаток (буквы не хватает или буква лишняя), но будучи написанным DevOps-инженером, оно в любом случае не теряет смысла:

... чтобы ноды не залебывались от нагрузки ...

SSH-туннели для #Java Dev&Ops 🔭

Ни один из последних моих проектов не обходился без подключения по SSH, чтобы что-то посмотреть/настроить/отладить/пофиксить и т.д. Но часто для этого нужно подключиться к определённому TCP-порту удалённого сервера, а он недоступен: то открыт лишь на localhost, то где-то маршрута не хватает, то безопасники запрещают. Во всех этих случаях на выручку приходили SSH-туннели. Расскажу о них чуть подробнее, вдруг кто-то не знал или недооценивал 🧐

Что это?
Фича SSH клиента и сервера, позволяющая "пробросить" порт с удалённого сервера на свою локальную машину (где запущен SSH клиент). То есть сделать так, чтобы обращение на этот порт у localhost'а волшебным образом приводило к обращению на этот же (или другой) порт у сервера, но при этом весь траффик оставался закрытым внутри SSH-соединения.
По смыслу это похоже на port-forwarding у kubectl и docker, но может применяться в бОльшем числе случаев ⚒️

Зачем?
Чтобы мультиплексировать множество соединений с удалённым сервером по одному SSH-каналу без открытия портов на внешних сетевых интерфейсах сервера. Проще говоря, чтобы завернуть весь траффик внутрь SSH независимо от протокола. Например:
• чтобы удалённо отлаживать JVM-приложение, не выпячивая порт отладчика наружу;
• чтобы мониторить приложение по JMX, не заморачиваясь с настройкой SSL для этого;
• чтобы дергать Spring-приложение за actuator, не затеваясь с получением сертификатов для HTTPS 📌

Как включить?
В общем случае включение сводится примерно к такой команде в консоли:

ssh -L <local-port>:<remote-address>:<remote-port> -N -f <ssh-host>

, где:
• -L — команда на включение локального туннеля;
• local-port — порт, на котором вы хотите видеть удалённый сервис на своей машине (как правило, равен remote-port);
• remote-port — порт удаленного сервера, который нужно сделать доступным у себя (как правило, равен local-port);
• remote-address — IP или имя сетевого интерфейса, на котором открыт удалённый пробрасываемый порт; чаще всего это localhost, но могут быть и другие;
• -N — признак отсутствия команды, которую нужно выполнить на удалённом сервере (обычно она не нужна);
• -f — признак запуска туннеля в фоновом режиме; если не добавить, управление не вернётся в консоль, и туннель будет висеть в ней;
• <ssh-host> — либо имя хоста для подключения (может быть с именем пользователя, например, [email protected]), либо название настроек подключения из файла ~/.ssh/config, например:

Host my-sandbox-vps
  Hostname 55.555.555.0
  User root
  IdentityFile ~/.ssh/id_dsa
  IdentitiesOnly yes

С такими настройками включение SSH-туннеля для удалённой отладки может выглядеть так:

ssh -L 5005:localhost:5005 -N -f my-sandbox-vps

Причём и эта команда, и файл настроек останутся точно такими же даже под Windows, если у вас установлен OpenSSH 🪟

Как выключить?
Поскольку каждый туннель — это отдельный процесс, для его выключения достаточно этот процесс остановить. На Linux/MacOS это может выглядеть примерно так:

$ ss -tulpn | grep 5005
tcp   LISTEN 0   128   127.0.0.1:5005  0.0.0.0:*  users:(("ssh",pid=307017,fd=5))
$ kill 307017

А если туннель запущен без флага -f, то в его консоли достаточно нажать Ctrl+C✖️

Какие недостатки?
• быстродействие: как правило, скорость передачи заметно падает, поэтому смотреть видосики в UHD по такой схеме будет не комфортно;
• искажение цепочки вызовов: все запросы в целевой сервис будут приходить с localhost, где запущен SSH-сервер; это может создавать проблемы;
• непрозрачность: если целевой хост перестанет быть доступен, туннель просто молча упадёт, не подавая явных признаков и не пытаясь переподключиться (это всё преодолимо, но потребует усилий) 🧟

P.S. Картинка взята из этой статьи Ивана Величко, где он также объясняет и другие варианты построения туннелей на SSH. Почитайте, и пусть вам это никогда не пригодится 🫠

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

На этом фоне в обиход вошёл новый речевой оборот:

Сегодня в третьей половине дня...

Новость для тех, кто всерьёз задумывался начать своё дело в IT 💼

C 26 сентября по 30 октября в Новосибирском Технопарке пройдёт 31-ый сезон А:Старт — одной из топовых в России и уж точно крутейшей за Уралом акселерационной программы для начинающих предпринимателей и технологических стартапов. Туда можно прийти с IT-проектом на любой стадии от голой идеи до рабочего решения, а уйти с упакованным продуктом, готовым к выводу на рынок или даже имеющим выручку 💰

Для этого на протяжении пяти недель (как правило, по три дня: четверг-суббота) нужно посещать профильные лекции, прорабатывать конкретные вопросы с экспертами и менторами и, конечно, выполнять много домашней работы по контролем трекера: проводить проблемные интервью, анализировать рынок, считать unit-экономику, стряпать лендинги и (наверняка) допиливать свой продукт. Легко будет едва ли, а вот полезно — по-любому 💯

Фишка программы в привлечении множества экспертов из индустрии: владельцев бизнесов, опытных технопредпринимателей, инвесторов — словом, тех, кто собственными руками и головой уже добился значимых успехов и понимает реальные проблемы начинающих. Об них можно как следует "обстучать" все свои идеи, вопросы и сомнения, что очень сильно помогает трезво взглянуть на свою задумку и выбрать ей правильный путь развития 🌄

Участие в программе платное: 12К лично и 24К за команду. Но есть лайфхак. Незадолго до начала акселератора, 13 сентября в том же Академпарке будет проходить Easy Pitch — открытая презентация идей и проектов для всех желающих. Если к ней нормально подготовиться и уверенно выступить, то присутствующие там эксперты могут подарить бесплатную проходку на акселератор. Схема рабочая, проверял сам в 2023-ем и в этом году 👌🏼

Кому интересно, можно полистать сайт программы, а также задать вопросы организаторам (они хорошо реагируют) или мне — как выпускник весеннего А:Старт 2023, ни разу не пожалевший о содеянном, я с удовольствием поделюсь своим опытом участия 👐