В амбициозные планы этого года, помимо лыжного марафона (в марте в Томске), входил марафон плавательный – ещё осенью прошлого года я вместе с друзьями по спортивному клубу купил слот на 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
Если вы не первый год в IT, то наверняка замечали, что программные продукты, помимо прочего, отличаются поддерживаемостью: какие-то поддаются правкам и дополнениям легко и естественно, а какие-то — так, будто их писали с единственной целью: "Сбить с толку вероятного противника" 🫡
Но что конкретно делает проекты/продукты поддерживаемыми? Вопрос не тривиальный. Приглашаю найти ответ вместе:
🧪 Исследование для backend-разработчиков
Наши коллеги проводят исследование, посвящённое поддерживаемости кода backend-ов: какие из известных подходов к разработке действительно упрощают жизнь разработчиков.
Если вы работали хотя бы три месяца над зрелым проектом, находившимся в разработке не менее полугода до вашего прихода — поучаствуйте, пожалуйста, в опросе.
📋 Это займет около 20 минут.
Ваши ответы помогут всему сообществу разработчиков лучше понять, что действительно влияет на поддерживаемость кода — вне зависимости от языка и фреймворка.
📊 Результаты исследования будут опубликованы осенью 2025 года на сайте: https://maintable-backends.tilda.ws/
👉 Принять участие: https://forms.yandex.ru/cloud/685ccc62eb614635657832a4
Но что конкретно делает проекты/продукты поддерживаемыми? Вопрос не тривиальный. Приглашаю найти ответ вместе:
🧪 Исследование для backend-разработчиков
Наши коллеги проводят исследование, посвящённое поддерживаемости кода backend-ов: какие из известных подходов к разработке действительно упрощают жизнь разработчиков.
Если вы работали хотя бы три месяца над зрелым проектом, находившимся в разработке не менее полугода до вашего прихода — поучаствуйте, пожалуйста, в опросе.
📋 Это займет около 20 минут.
Ваши ответы помогут всему сообществу разработчиков лучше понять, что действительно влияет на поддерживаемость кода — вне зависимости от языка и фреймворка.
📊 Результаты исследования будут опубликованы осенью 2025 года на сайте: https://maintable-backends.tilda.ws/
👉 Принять участие: https://forms.yandex.ru/cloud/685ccc62eb614635657832a4
maintable-backends.tilda.ws
Исследование: характеристики поддерживаемых кодовых баз backend-приложений
Заметка для тех, кто, собираясь в отпуск, в первую очередь кладёт в сумку беговые кроссовки 👟
Горный Алтай, на мой взгляд – далеко не самое удачное место для комфортных пробежек: там то бежишь по узкой обочине нагруженной дороги, то корячишься вверх или вниз по ухабистым горным тропинкам. Но поскольку просторы там огромные (а виды и воздух упоительные), найти нормальные места для пробежек всё же можно. Поделюсь своим опытом 👇
Свой первый обзор беговых маршрутов Чемала (с фотками, треками и комментариями) я делал в 2019-ом году. С тех пор они почти не утратили актуальности (разве что траффик стал выше), а я открыл для себя ещё несколько. В дополнение к обзору привожу топ-3 из них в порядке возрастания клёвости.
🥉3 место: Чуйский тракт в районе с. Черга
Сама по себе трасса невероятно живописна, но бежать только вдоль нее может быть не комфортно: мало тени, много машин. К счастью, в районе базы отдыха Барсуган есть несколько ответвлений, по которым можно сбежать в поля поодаль от тракта (в других местах они тоже наверняка есть). Только бежать туда лучше в сухую погоду, иначе кроссовки будут мокрыми от травы и/или тяжелыми от налипшей грязи. Подходит для одиночного трейла. Пример трека здесь.
🥈2 место: Катуньское заречье (близ с. Аюла)
Это относительно плоский участок между Чемальской солнечной электростанцией, аквапарком Рублёвка и собственно рекой Катунь. Там много хоженых тропинок и прокатанных дорог, а со многих точек открываются шикарные виды. Подходит для небольшого кросса, без жести. Пример трека тут.
🥇1 место: Айский тракт
Необъяснимо, но факт: гладкая, ровная, длинная асфальтовая трасса с невысоким траффиком и хорошим приподнятым тротуаром, который ещё и скрывается в тени деревьев (на части пути). Располагается между озером Ая и комплексом баз Бирюзовая Катунь. Не удивительно, что именно там проходит беговой этап ежегодной триатлонной гонки AltaiTriRace. Отлично подходит для скоростной асфальтовой тренировки. Пример трека присутствует.
Кто знает другие годные маршруты в тех краях – welcome в комментарии 👐
#спорт
Горный Алтай, на мой взгляд – далеко не самое удачное место для комфортных пробежек: там то бежишь по узкой обочине нагруженной дороги, то корячишься вверх или вниз по ухабистым горным тропинкам. Но поскольку просторы там огромные (а виды и воздух упоительные), найти нормальные места для пробежек всё же можно. Поделюсь своим опытом 👇
Свой первый обзор беговых маршрутов Чемала (с фотками, треками и комментариями) я делал в 2019-ом году. С тех пор они почти не утратили актуальности (разве что траффик стал выше), а я открыл для себя ещё несколько. В дополнение к обзору привожу топ-3 из них в порядке возрастания клёвости.
🥉3 место: Чуйский тракт в районе с. Черга
Сама по себе трасса невероятно живописна, но бежать только вдоль нее может быть не комфортно: мало тени, много машин. К счастью, в районе базы отдыха Барсуган есть несколько ответвлений, по которым можно сбежать в поля поодаль от тракта (в других местах они тоже наверняка есть). Только бежать туда лучше в сухую погоду, иначе кроссовки будут мокрыми от травы и/или тяжелыми от налипшей грязи. Подходит для одиночного трейла. Пример трека здесь.
🥈2 место: Катуньское заречье (близ с. Аюла)
Это относительно плоский участок между Чемальской солнечной электростанцией, аквапарком Рублёвка и собственно рекой Катунь. Там много хоженых тропинок и прокатанных дорог, а со многих точек открываются шикарные виды. Подходит для небольшого кросса, без жести. Пример трека тут.
🥇1 место: Айский тракт
Необъяснимо, но факт: гладкая, ровная, длинная асфальтовая трасса с невысоким траффиком и хорошим приподнятым тротуаром, который ещё и скрывается в тени деревьев (на части пути). Располагается между озером Ая и комплексом баз Бирюзовая Катунь. Не удивительно, что именно там проходит беговой этап ежегодной триатлонной гонки AltaiTriRace. Отлично подходит для скоростной асфальтовой тренировки. Пример трека присутствует.
Кто знает другие годные маршруты в тех краях – welcome в комментарии 👐
#спорт
toparvion.github.io
Беговые маршруты Чемала (Алтай)
Идеи, советы и места для кроссов и шоссейных пробежек
👍6❤2✍1
Лайфхак для performance-инженеров 👷♂️
Коротко:Парсить большие heap-дампы для анализа в Eclipse MAT лучше в recovery mode: получается быстрее и стабильнее
Подробно:
Давеча потребовалось распарсить 30 ГБ-ый дамп памяти JVM-приложения для анализа в Eclipse Memory Analyzer Tool (MAT). Для этого в MAT есть отдельный консольный парсер, который тоже, разумеется, работает на #Java 🤭
И поскольку у меня на рабочей машине (Ubuntu 24.04) всего 32 ГБ ОЗУ, встал вопрос, сколько выставить
Первая попытка выставить 28 ГБ провалилась: парсер был жестко прибит несокрушимым OutOfMemory Killer’ом за попытку аллоцировать слишком много памяти, причем нативной. Для тех, кто не в курсе, почему так происходит, у меня был доклад “Скажите «Ой»: JVM и OOM Killer” – там описан этот механизм ядра Linux и способы избегать столкновения с ним 🔫
Второй была попытка сторговаться на 26 ГБ, и она удалась, правда, ждать пришлось минут 15-20. Оно и понятно, ведь при таком потреблении парсер солидную (если не бОльшую) часть времени провёл не за делом, а в обнимку с GC, пытаясь на лету подчищать за собой объекты. Как бы там ни было, задача была решена, и это клёво ✅
Но уже через пару дней от того же заказчика пришёл новый дамп, на сей раз на 55 ГБ, и стало ясно, что так просто я уже не отскочу 🫠
Не особо веря в успех, я всё же решил попробовать отдать парсеру вообще всю память машины. Но для этого надо как-то заставить ОС не мешаться. А как это сделать? Правильно – Recovery Mode: максимально голый режим командной строки, используемый обычно для восстановления после жестких аварий ОС (в Windows есть его аналог под названием Safe Mode, хотя там графическая оболочка всё равно запускается) ⛑
Выставив в этом режиме -Xmx30G (с отступом на аллокации в нативной части), я был приятно удивлен тем, что парсинг успешно завершился. Больше того, он завершился гораздо быстрее, минуты за три. Видимо, возможность беспрепятственно бросить все 16 ядер CPU на борьбу с мусором позволили JVM максимально эффективно распорядиться памятью и не аффектить производительность прикладного кода ⛲️
Разумеется, здесь есть щепотка везения, ведь пиковое потребление памяти парсером во многом зависит от характера графа объектов в обрабатываемом дампе, а значит, в следующий раз такой трюк может и не пройти 🤹
Тем не менее, Recovery Mode — достаточно простой и эффективный способ превратить ваш ноутбук в настоящую Java-машину, поэтому предлагаю взять на заметку ✍️
Коротко:
Подробно:
Давеча потребовалось распарсить 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-машину, поэтому предлагаю взять на заметку ✍️
🔥15👍3❤2👏1
Тот случай, когда в написанном слове точно есть одна из двух опечаток (буквы не хватает или буква лишняя), но будучи написанным DevOps-инженером, оно в любом случае не теряет смысла:
... чтобы ноды не залебывались от нагрузки ...
😁19
Минувшие выходные целиком прошли под хэштегом #спорт — вместе с товарищами по спортивному клубу я был в Красноярске на двухдневном фестивале открытой воды Шумиха 2025 🌊
В оба дня нас забрасывали катерами на дикие речные берега, откуда мы возвращались вплавь в стартовый городок. В субботу у меня был заплыв на 3,8 км по заливу Енисея с прикольным названием Шумиха, а в воскресенье — 5 км уже по самому Енисею-батюшке. Оба старта, в целом, прошли хорошо; я показал результаты, соответствующие своему текущему уровню подготовки. Правда, во второй день плылось заметно сложнее — несмотря на твёрдое намерение не упарываться в первый день, сил было потрачено немало, а они, как известно, не бесконечные 🙃
Высокие берега, сплошь поросшие вековыми хвойными деревьями; чистая прохладная вода, местами придававшая изюминки своим волнением; несокрушимая мощь и масштабное величие Красноярской ГЭС, расположенной всего в 1,5 км от места старта — всё это вкупе с хорошей организацией и отличной компанией сделали прошедшие два дня очень яркими и богатыми на позитивные впечатления, хоть и напряженными физически🫠
Не знаю, удастся ли ещё поплавать в открытой воде в этом сезоне; всё же наше сибирское лето весьма скоротечно. Но даже если нет, эти выходные вполне можно считать достойным завершением сезона🌅
P.S. Для любопытствующих: итоговый протокол соревнований лежит здесь.
В оба дня нас забрасывали катерами на дикие речные берега, откуда мы возвращались вплавь в стартовый городок. В субботу у меня был заплыв на 3,8 км по заливу Енисея с прикольным названием Шумиха, а в воскресенье — 5 км уже по самому Енисею-батюшке. Оба старта, в целом, прошли хорошо; я показал результаты, соответствующие своему текущему уровню подготовки. Правда, во второй день плылось заметно сложнее — несмотря на твёрдое намерение не упарываться в первый день, сил было потрачено немало, а они, как известно, не бесконечные 🙃
Высокие берега, сплошь поросшие вековыми хвойными деревьями; чистая прохладная вода, местами придававшая изюминки своим волнением; несокрушимая мощь и масштабное величие Красноярской ГЭС, расположенной всего в 1,5 км от места старта — всё это вкупе с хорошей организацией и отличной компанией сделали прошедшие два дня очень яркими и богатыми на позитивные впечатления, хоть и напряженными физически🫠
Не знаю, удастся ли ещё поплавать в открытой воде в этом сезоне; всё же наше сибирское лето весьма скоротечно. Но даже если нет, эти выходные вполне можно считать достойным завершением сезона🌅
P.S. Для любопытствующих: итоговый протокол соревнований лежит здесь.
🔥15👏2