Вот и отгремела конференция Saint HighLoad++ 2025 в Петербурге. Это были два дня насыщенного общения, интересных докладов и приятного осознания, что в России есть люди, умеющие организовывать масштабные продолжительные мероприятия (почти 2,5 тысячи человек) с точностью до запасных ручек (это не шутка) 💪🏼
Мой доклад, в целом, прошёл нормально, хотя я ожидал, что придёт больше людей. То ли начало в 10:00 после афтепати оказалось многим не под силу, то ли "Узкотематическая секция" показалась не релевантной, то ли название и описание доклада не вызвали отклика в душах и разумах. Как бы там ни было, я благодарен всем, кто всё же пришёл и послушал — я реально горел этой темой, с удовольствием готовился и с нетерпением ждал возможности поделиться ею с вами. Надеюсь, это чувствовалось 🙏🏼
Обратная связь, как и видео запись, будет позже. А пока могу поделиться слайдами: https://toparvion.pro/event/2025/highload/ Приятного прокликивания🙂
Мой доклад, в целом, прошёл нормально, хотя я ожидал, что придёт больше людей. То ли начало в 10:00 после афтепати оказалось многим не под силу, то ли "Узкотематическая секция" показалась не релевантной, то ли название и описание доклада не вызвали отклика в душах и разумах. Как бы там ни было, я благодарен всем, кто всё же пришёл и послушал — я реально горел этой темой, с удовольствием готовился и с нетерпением ждал возможности поделиться ею с вами. Надеюсь, это чувствовалось 🙏🏼
Обратная связь, как и видео запись, будет позже. А пока могу поделиться слайдами: https://toparvion.pro/event/2025/highload/ Приятного прокликивания🙂
🔥6
Баги, которые исчезают сами — самые страшные.
Ведь если они сами исчезают, значит, они могут в любой момент сами и появиться... 🤔🙈
Ведь если они сами исчезают, значит, они могут в любой момент сами и появиться... 🤔🙈
😁7💯3
В амбициозные планы этого года, помимо лыжного марафона (в марте в Томске), входил марафон плавательный – ещё осенью прошлого года я вместе с друзьями по спортивному клубу купил слот на 10 км вплавь по одному из чистейших водоёмов России – озеру Тургояк в Челябинской области. Этот заплыв должен был стать для меня компенсацией, в целом, успешного, но очень тяжелого заплыва на ту же дистанцию на Кузбассе в 2021 году; хотелось бахнуть ту же дистанцию быстрее и, по возможности, легче ⚖️
Однако чем ближе становился этот старт, тем больше я сомневался в своей готовности и желании в нём участвовать: плавательных объёмов не хватало, прогноз погоды предвещал холодную воду, а приступ увлечения swimrun’ом не давал забыть, что вообще-то бег я люблю ни чуть не меньше, чем плавание. А тут ещё выяснилось, что организаторы предстоящего заплыва экспериментируют с форматами и добавляют не только плавание… Дело кончилось тем, что незадолго до старта я разменял свой 10-километровый плавательный слот на два: 5 км вплавь в тот же день (в эстафете) и акватлон накануне: 5 км бегом, 2 км вплавь, 5 км бегом. По нагрузке это примерно как два полумарафона подряд ⏩
В акватлоне я начал весьма бодро, быстро вырвался вперёд и завершил первый беговой этап лидером, хотя бежал по силам, не рвал. А вот последовавшее плавание стало неприятной сменой: первый же участок пролегал на встречу волнам и он тут же вскрыл моё слабое место – пока я с ними боролся, меня обошли сразу несколько атлетов, догнать которых было крайне сложно. На втором беговом этапе, несмотря на появившуюся усталость, я сохранил почти тот же, довольно высокий по меркам остальных темп, однако отыграть накопленное отставание времени не хватило, и я финишировал через 1:36, став только 4-ым из 18 участников 🏆
Следующее утро (в день заплыва на 5 км) было безветренным, вода гладкой, а небо чистым – близкие к идеальным условия. Таковыми они и остались для первого этапа эстафеты. Однако для нас, плывших после, уральская погода приготовила сюрприз – уже к концу первого километра на воде появилась рябь, уверенно переходящая в волнение. Этот процесс уверенно развивался с каждой сотней метров, а вместе с ним постепенно деградировал и темп. И хотя волны были не встречными, а попутно-диагональными, они всё равно здорово усложняли ориентирование и дыхание, а под конец ещё и стали причиной непрерывной борьбы с собственным буем, постоянно забрасываемым вперёд. В этом режиме я достиг финиша лишь через 1:56, а наша команда стала 12-ой из 16 заявившихся 🏅
Несмотря на эти сложности, я остался очень рад и доволен участием и поездкой в целом. Отдельно благодарю друзей, которые болели и помогали до, во время и после обоих стартов – мне было нереально приятно слышать, видеть и чувствовать их поддержку! В этот раз наш новосибирский десант на Тургояк насчитывал вместе с детьми 23 человека, и такая общность – предмет отдельной большой гордости. Видно, #спорт и правда объединяет! 🤗
Однако чем ближе становился этот старт, тем больше я сомневался в своей готовности и желании в нём участвовать: плавательных объёмов не хватало, прогноз погоды предвещал холодную воду, а приступ увлечения swimrun’ом не давал забыть, что вообще-то бег я люблю ни чуть не меньше, чем плавание. А тут ещё выяснилось, что организаторы предстоящего заплыва экспериментируют с форматами и добавляют не только плавание… Дело кончилось тем, что незадолго до старта я разменял свой 10-километровый плавательный слот на два: 5 км вплавь в тот же день (в эстафете) и акватлон накануне: 5 км бегом, 2 км вплавь, 5 км бегом. По нагрузке это примерно как два полумарафона подряд ⏩
В акватлоне я начал весьма бодро, быстро вырвался вперёд и завершил первый беговой этап лидером, хотя бежал по силам, не рвал. А вот последовавшее плавание стало неприятной сменой: первый же участок пролегал на встречу волнам и он тут же вскрыл моё слабое место – пока я с ними боролся, меня обошли сразу несколько атлетов, догнать которых было крайне сложно. На втором беговом этапе, несмотря на появившуюся усталость, я сохранил почти тот же, довольно высокий по меркам остальных темп, однако отыграть накопленное отставание времени не хватило, и я финишировал через 1:36, став только 4-ым из 18 участников 🏆
Следующее утро (в день заплыва на 5 км) было безветренным, вода гладкой, а небо чистым – близкие к идеальным условия. Таковыми они и остались для первого этапа эстафеты. Однако для нас, плывших после, уральская погода приготовила сюрприз – уже к концу первого километра на воде появилась рябь, уверенно переходящая в волнение. Этот процесс уверенно развивался с каждой сотней метров, а вместе с ним постепенно деградировал и темп. И хотя волны были не встречными, а попутно-диагональными, они всё равно здорово усложняли ориентирование и дыхание, а под конец ещё и стали причиной непрерывной борьбы с собственным буем, постоянно забрасываемым вперёд. В этом режиме я достиг финиша лишь через 1:56, а наша команда стала 12-ой из 16 заявившихся 🏅
Несмотря на эти сложности, я остался очень рад и доволен участием и поездкой в целом. Отдельно благодарю друзей, которые болели и помогали до, во время и после обоих стартов – мне было нереально приятно слышать, видеть и чувствовать их поддержку! В этот раз наш новосибирский десант на Тургояк насчитывал вместе с детьми 23 человека, и такая общность – предмет отдельной большой гордости. Видно, #спорт и правда объединяет! 🤗
🔥8
Немного пятницы в эфире "Верхней полки" 📺
В одном из соседних чатов проскользнула ссылка на т.н. Хороший Учебный Язык (программирования) от земляка-новосибирца Алексея Кутепова:
https://github.com/tsoding/good_training_language
В духе гремящего импортозамещения язык предлагает писать примерно так:
Глядя на это, сразу вспоминается язык 1С:
А если взглянуть на аббревиатуру названия, то вспоминается другой язык — некогда шумевший YoptaScript, код на котором тоже пишется по-русски, но, кхм-кхм, со своей спецификой (18+):
```
result сука a иличо b нах
result сука a ичо b нах
вилкойвглаз (x пизже 0 иличо y хуёвей 10) жЫ
шухер( 'Ыгыыг' ) нах
a внатуре пиздишь нах
есть
```
Если знаете другие языки программирования, основанные на русском (или хотя бы кириллице), поделитесь, пожалуйста — будет любопытно добавить их в эту копилку 🗳
В одном из соседних чатов проскользнула ссылка на т.н. Хороший Учебный Язык (программирования) от земляка-новосибирца Алексея Кутепова:
https://github.com/tsoding/good_training_language
В духе гремящего импортозамещения язык предлагает писать примерно так:
вкл прелюдия;
конст ВЫСОТА := 10;
пер скрытое_поле: массив(ВЫСОТА, массив(ШИРИНА, лог));
про отобразить_поле() нч
для строка := 1..ВЫСОТА нч
для столбец := 1..ШИРИНА нч
если поле(строка - 1)(столбец - 1)
то печать(«%»);
иначе то печать(«_»);
кц
печать(«\н»);
кц
кц
Глядя на это, сразу вспоминается язык 1С:
&НаКлиенте
Функция РассчитатьПроцентНаценки(ЦенаЗакупки, ЦенаПродажи)
ПроцентНаценки = 0;
Если ЦенаЗакупки <> 0 Тогда
ПроцентНаценки = (ЦенаПродажи - ЦенаЗакупки) * 100 / ЦенаЗакупки;
КонецЕсли;
Возврат ПроцентНаценки;
КонецФункции
А если взглянуть на аббревиатуру названия, то вспоминается другой язык — некогда шумевший YoptaScript, код на котором тоже пишется по-русски, но, кхм-кхм, со своей спецификой (18+):
result сука a иличо b нах
result сука a ичо b нах
вилкойвглаз (x пизже 0 иличо y хуёвей 10) жЫ
шухер( 'Ыгыыг' ) нах
a внатуре пиздишь нах
есть
```
Если знаете другие языки программирования, основанные на русском (или хотя бы кириллице), поделитесь, пожалуйста — будет любопытно добавить их в эту копилку 🗳
GitHub
GitHub - tsoding/good_training_language: Хороший Учебный Язык
Хороший Учебный Язык. Contribute to tsoding/good_training_language development by creating an account on GitHub.
😁5
Оказывается, многолетний холивар между поклонниками текстовых редакторов Vim и Emacs настолько известен и благодатен для шуточек, что даже Google не устоял и добавил себе пасхалочку на эту тему 🐣
Об этом, кстати, есть заметка в Википедии в статье с недвусмысленным названием Editor war 🪖
Об этом, кстати, есть заметка в Википедии в статье с недвусмысленным названием Editor war 🪖
😁6
Весьма забористый баг довелось встретить и пофиксить намедни. В одной таблице в Cassandra хранились некие события, вычитываемые по их дате. И почему-то в некоторых нечастых случаях запрос из нашего приложения не возвращал ничего, хотя события за запрашиваемые даты совершенно точно хранились в БД (проверено вручную). Мистика, не иначе 👻
Как выяснилось, временные метки событий хранились не в чистом виде, а как
А поскольку ID события у нас имеют тип
На второй день расследования, выдёргивая последний клок волос из головы, я набрёл в исходниках Cassandra на реализацию CQL-функций
Другими словами, целочисленный идентификатор, который вставляется в UUID, трактуется Cassandra'ой как знаковый, а значит, его старший разряд относится не к самому числу, а к его знаку. И поэтому, когда мы через
Решением стал отказ от ручного формирования TimeUuid на основе
Вывод:всё тлен при работе с TimeUuid помнить про его составную природу и по максимуму отряжать манипуляции с ним на сторону либо Cassandra, либо её драйвера ✍️
#бывает
Как выяснилось, временные метки событий хранились не в чистом виде, а как
TimeUuid — длинный целочисленный идентификатор, включающий в себя как timestamp события, так и его ID (это делается, чтобы исключить коллизии между событиями, произошедшими в один момент времени, а также чтобы сохранить для ключа все свойства обычного целочисленного ID). Как следствие, одному timestamp-у может соответствовать множество значений TimeUuid, и, чтобы это учесть, при реализации поиска событий мой предшественник-разработчик прибег к небольшой хитрости: стал задавать нижнюю границу поиска (минимальную дату) в виде TimeUuid с неким минимальным ID события, а верхнюю границу (максимальную дату) — с максимально возможным ID 🗜А поскольку ID события у нас имеют тип
Long, то и значения этих границ выбраны соответственно: 0 и Long.MAX_VALUE. То есть задумка в том, что каким бы ни был фактический ID искомого события, он по-любому будет в диапазоне от 0 до Long.MAX_VALUE. Казалось бы, что может пойти не так? 🧐На второй день расследования, выдёргивая последний клок волос из головы, я набрёл в исходниках Cassandra на реализацию CQL-функций
maxTimeuuid и minTimeuuid, в комментариях к которым написано:* The min and max possible lsb for a UUID.
* Note that his is not 0 and all 1's because Cassandra TimeUUIDType
* compares the lsb parts as a signed byte array comparison. So the min
* value is 8 times -128 and the max is 8 times +127.
Другими словами, целочисленный идентификатор, который вставляется в UUID, трактуется Cassandra'ой как знаковый, а значит, его старший разряд относится не к самому числу, а к его знаку. И поэтому, когда мы через
Long.MAX_VALUE вкорячиваем туда что-то вроде 0xFF-FFFF-FFFFFF, то получаем не максимально возможный идентификатор события, а какое-то (отнюдь не максимальное) отрицательное число. Соответственно, ID хранимых в БД событий начинают не особо предсказуемым образом делиться на те, что проходят проверку на сравнение с этим числом, и те, что нет. В нашем случае не проходили лишь пара десятков из почти 4000, поэтому отловить проблему было не просто 🕵️♂️Решением стал отказ от ручного формирования TimeUuid на основе
0 и Long.MAX_VALUE в пользу тех самых функций из языка CQL, и условие поиска стало выглядеть примерно так:WHERE key = '...'
AND timestamp_uuid >= mintimeuuid('2025-06-01T00:00:00.000')
AND timestamp_uuid <= maxtimeuuid('2025-06-01T00:00:00.000')
Вывод:
#бывает
GitHub
cassandra/src/java/org/apache/cassandra/utils/TimeUUID.java at 8014eec7aad72415b3d53cb5cc6cacf76acf95c1 · apache/cassandra
Apache Cassandra®. Contribute to apache/cassandra development by creating an account on GitHub.
🔥7👍3
В канале конференции HighLoad++, на которой я выступал месяц назад, начали публиковать топ-15 докладов по отзывам слушателей. Всего в программе конференции было более 100 докладов 📚
И если в 2022-ом на той же конференции мой доклад "Экскурсия в бэкенд Интернета вещей" внезапно оказался в рейтинге 2-ым, то нынче, вопреки ожиданиям, доклад про подсистему отладки в low-code-платформе не только не вошёл в топ-15, но и вообще не попал в рейтинг, потому что собрал слишком мало оценок. При этом сами средние оценки доклада получились не особо низкими: 4,56 за контент и 5,00 за подачу 🎰
Из этого напрашивается вывод, что сам доклад вышел неплохим, но люди до него дошли. Причины можно условно поделить на две группы — зависящие от докладчика и не зависящие:
1️⃣ К первым я бы отнёс время доклада: первый слот во второй день (10:00). Для кого-то это в принципе рановато, а кто-то мог "не выжить" после афтепати предыдущего дня. С этим мало что можно поделать, разве в следующий раз всё же просить программный комитет не ставить доклад в это время (как будто в этот раз я не просил, ха-ха).
2️⃣ Ко вторым относятся выбранные мною название доклада и его секция. Секцию я выбрал т.н. "Узкотематическую", хотя подходили и другие; видимо, это было промахом. А вот название я взял предложенное моим куратором из ПК и не особо подвергал его критике, хотя, видимо, стоило. Например, можно было вспомнить про тест на годность названия, предложенный Володей Ситниковым в кулуарах конференции JPoint (в апреле в Москве). Этот тест сводится примерно к такому вопросу:
Видимо, в следующий раз надо будет пройти этот тест заранее, а заодно, быть может, и проверить понятность/привлекательность названия на потенциальной аудитории, например, с вами.
Вы же не против, правда? 😉
И если в 2022-ом на той же конференции мой доклад "Экскурсия в бэкенд Интернета вещей" внезапно оказался в рейтинге 2-ым, то нынче, вопреки ожиданиям, доклад про подсистему отладки в low-code-платформе не только не вошёл в топ-15, но и вообще не попал в рейтинг, потому что собрал слишком мало оценок. При этом сами средние оценки доклада получились не особо низкими: 4,56 за контент и 5,00 за подачу 🎰
Из этого напрашивается вывод, что сам доклад вышел неплохим, но люди до него дошли. Причины можно условно поделить на две группы — зависящие от докладчика и не зависящие:
1️⃣ К первым я бы отнёс время доклада: первый слот во второй день (10:00). Для кого-то это в принципе рановато, а кто-то мог "не выжить" после афтепати предыдущего дня. С этим мало что можно поделать, разве в следующий раз всё же просить программный комитет не ставить доклад в это время (как будто в этот раз я не просил, ха-ха).
2️⃣ Ко вторым относятся выбранные мною название доклада и его секция. Секцию я выбрал т.н. "Узкотематическую", хотя подходили и другие; видимо, это было промахом. А вот название я взял предложенное моим куратором из ПК и не особо подвергал его критике, хотя, видимо, стоило. Например, можно было вспомнить про тест на годность названия, предложенный Володей Ситниковым в кулуарах конференции JPoint (в апреле в Москве). Этот тест сводится примерно к такому вопросу:
Подумай, что будет гуглить разработчик, столкнувшийся с такой же проблемой/вопросом, как ты описываешь в докладе, и выпадет ли ему твой доклад при текущем его названии?
Видимо, в следующий раз надо будет пройти этот тест заранее, а заодно, быть может, и проверить понятность/привлекательность названия на потенциальной аудитории, например, с вами.
Вы же не против, правда? 😉
Telegram
HighLoad++
⭐️ Топ-15 докладов Saint HighLoad++ 2025
В июне в Санкт-Петербурге собрались более 3000 участников со всей страны и 120 ведущих экспертов отрасли, которые представили свои доклады по 13 тематическим трекам.
Целых два дня мы обсуждали архитектуры крупных…
В июне в Санкт-Петербурге собрались более 3000 участников со всей страны и 120 ведущих экспертов отрасли, которые представили свои доклады по 13 тематическим трекам.
Целых два дня мы обсуждали архитектуры крупных…
👍2🙏1
Наверняка эта задачка входит в число хрестоматийных и встречается на собеседованиях по #Java, но поскольку я по ним не хожу, пришлось убить часок на разбирательство с ней. Поделюсь с вами; вдруг кто-то тоже встретит.
🎓 Дано
Ванильный пул потоков на голом JDK (аналоги из класса
И некий метод, который сначала просто напихивает задачки в этот пул:
, потом идёт по своим делам, а когда заканчивает с ними, проверяет готовность задачек и, если надо, дожидается завершения каждой, чтобы продолжить работу дальше:
🔍 Найти
Какого _🙊_ в некоторых случаях метод намертво зависает на вызове
При этом в дампе потоков нет никаких следов задач, которые бы зависли/зациклились/заблокированы.
🔑 Решение
Вариант 1. Добавить таймаут в метод
Вариант 2. Извернуться как-нибудь так, чтобы прийти к вызову вида
Вариант 3. Обернуть вызов
Казалось бы, смысла в нём нет, ведь если задача не завершена (
, то есть "сделанной" считается любая не новая задача (в том числе когда она ещё в работе).
А метод
, то есть ожидание наступит для любого состояния, предшествующего завершению, в том числе для вышеупомянутого
Но если бы задача, на которой завис наш поток, была в состоянии
А как она могла оказаться
✅ Вся цепочка кратко:
— не влезающие в очередь задачи молча отбрасываются политикой пула, оставляя им статус
— видя этот статус, метод
— исключить ожидание можно добавлением проверки на
⚠️ Если очередь будет большой, а задачи — долгоиграющими, можно нарваться на случай, когда задача уже в очереди и имеет шанс быть выполненной, но цикл с вызовом
Мораль: пишите однопоточные приложения🤪
🎓 Дано
Ванильный пул потоков на голом 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() её не подождёт. В этом случае решение должно быть другим.Мораль: пишите однопоточные приложения🤪
😁12🫡4❤2👍2
Forwarded from Spring АйО
⚡️ Он помогает Java-разработчикам по всей стране! Интервью с Владимиром Плизга
На JPoint 2025 мы пообщались с Владимиром Плизга — инженером Tibbo Systems, спикером, тренером и автором Telegram-канала «Верхняя полка».
Владимир — настоящий энтузиаст: разрабатывает инструменты для упрощения жизни бэкенд-разработчиков, делится опытом на конференциях и митапах, пишет статьи и ведёт тренинги по производительности Java-приложений.
😉 СМОТРЕТЬ НА YOUTUBE
😄 СМОТРЕТЬ В VK ВИДЕО
🥰 СМОТРЕТЬ НА RUTUBE
Это только начало — впереди ещё больше бесед с интересными людьми из мира Java и Spring.
На JPoint 2025 мы пообщались с Владимиром Плизга — инженером Tibbo Systems, спикером, тренером и автором Telegram-канала «Верхняя полка».
Владимир — настоящий энтузиаст: разрабатывает инструменты для упрощения жизни бэкенд-разработчиков, делится опытом на конференциях и митапах, пишет статьи и ведёт тренинги по производительности Java-приложений.
Это только начало — впереди ещё больше бесед с интересными людьми из мира Java и Spring.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1🔥1
Давно обещал рассказать вам об очередной программной поделке, идеей которой загорелся ещё в конце прошлого года — 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) и оставить обратную связь
— поставить реакцию 🤓, если хочется узнать подробнее о внутреннем устройстве сервиса и/или его развертывании
— предложить более удачную картинку для бота🙂
Мотивация проста:
— я часто участвую в массовых мероприятиях, где работают фотографы (в основном, конференции и соревнования, но не только)
— мне хочется сохранять удачные снимки с собой на память
— мне лень/некогда/неохота отсматривать сотни (а то и тысячи) чужих или просто левых снимков 📷
И я задумался:
А есть ли сервис, которому я мог бы просто переправить ссылку на фотоальбом с мероприятия, и он бы сам за меня его отсмотрел (по образцу моей фотки), а мне бы скинул только те фотки, на которых я есть?
И раз в 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) и оставить обратную связь
— поставить реакцию 🤓, если хочется узнать подробнее о внутреннем устройстве сервиса и/или его развертывании
— предложить более удачную картинку для бота🙂
🔥8🤓7👍5