В каждом утюге эта статья была, пусть будет и в моем.

Она немного поверностная, но хорошо дает обзор основных подсистем с точки зрения пользователя.

https://habr.com/ru/post/531872/

В новых версиях спринга появилась возможность создавать docker-образ через maven/gradle. Работает это через Cloud Native Buildpacks, все правильно раскладывается по слоям и выставляются оптимальные настройки JVM.

Звучит, конечно, прикольно, но если бы настройки JVM можно было посчитать автоматом — то почему они для всех приложений не определяются автоматом? Сомневаюсь, что утилита знает о характере вычислений и профиле нагрузки на приложение. Впрочем, может, это никому и не надо, сейчас проще накинуть пару лишних гигов оперативки, чем разбираться в нюансах.

Но настораживает и другой тренд: сейчас система сборки обрастает плагинами, которые позволяют не только собирать приложение, но еще и управлять его версиями, ветками git, сейчас вот и докер собирать. Что дальше — деплоить на прод через maven, потому что так удобнее? Только в кубер, конечно же. CI/CD не нужны, все пихаем в исходный код!

Как будто и не помнит никто уже про Nero Burning ROM. Супер-аппы в духе времени: почта продает продукты, такси доставляет еду, магазин выдает посылки, банк продает авиабилеты, в инстаграмме постят лонгриды, в IDE встаивают видеочаты и т.д.

Раньше было лень открывать IDE — открывал онлайн-IDE. Сейчас можно еще больше облениться и просто писать боту в телеге.

@rextester_bot brainfuck
+[--------->++<]>.---------.------.++++++++.-[++>---<]>+.---[----->++<]>.---.---..

Бот — простой фасад к http://rextester.com. Поддерживает все популярные языки. Интересно, какая у них там песочница? Она спокойно позволяет запускать ps aux и ls /. Выпускники ИБ — это ваш шанс почувствовать себя кулхацкерами, не выходя из телеги:)

Иногда IntelliJ жестко тупит и не скачивает исходники библиотек в проекте с maven, какие бы настройки ни стояли, и сколько бы ты не нажимал “Download Sources”. Помогут команды

mvn dependency:sources
mvn dependency:resolve -Dclassifier=javadoc

Первая скачает все доступные исходники ко всем зависимостям, а вторая — еще и javadoc к ним. В sbt это можно сделать командой sbt updateClassifiers (хотя я это не проверял). А вот в gradle такого вроде нет (с другой стороны, я и не припомню проблем с этим, может IntelliJ была со старыми иконками и работала нормально).

В продолжение темы конвертеров.

convert -density 300 order.pdf %02d.png

сконвертирует pdf в png. А обратно склеить их в pdf можно так:

convert {00..03}.png combined.pdf

Возможно придется включить разрешения, добавив

<policy domain="coder" rights="read | write" pattern="PDF" />

в /etc/ImageMagick-[версия]/policy.xml.

В конце прошлого года столкнулись на старой работе с багом Intellij Idea: после обновления она начала расставлять отступы немного по-другому в kotlin-коде. Сравнивали настройки — все идентично. Была версия, что в Intellij иногда почему-то игнорируется настройка continuation ident. Обновились до идентичных версий — все равно форматируют по разному, сволочи. Порылись в Youtrack’е JetBrains — нет такого бага. Так и забили…

На прошлой неделе коллега вляпался в эту же проблему. Но теперь есть хоть решение, позволяющее сохранить обратную совместимость: Kotlin obsolete IntelliJ IDEA codestyle. Новый стиль, конечно, поприятнее, но никто его в старом проекте менять не будет.

А вообще все чаще наблюдается тенденция, что обновления сферического ПО в вакууме все чаще содержат “новые нескучные иконки” и “поправили 2 старых бага, добавили 5 новых”, а не что-то действительно новое… Ну и/или я уже душный ворчливый дед:)

Немного капитана очевидности из личного опыта:

1. Алерты должны быть. Просто так на графики и дашборды никто смотреть не будет (возможно, кроме первых N дней, когда их только-только настроили).
2. Алерты должны быть такие, чтобы требовали реагирования. Если реакция на алерт по умолчанию будет “а, это как обычно, это норма”, то вскоре на них и смотреть не будут.
3. Алертов не должно быть много и в них не должно быть шума. Если за день приходит 500 алертов, то подробно с каждым возиться, разумеется, никто не будет. На старой работе делали для этого экспоненциальные интервалы уведомлений (алерт триггерится сначала раз в 5 минут, потом раз 10, потом раз в полчаса, потом раз в час, потом 2 раза в день и т.п. — точные интервалы не помню, но суть такая) и периодический агрегированный отчет (где собраны все полуважные алерты, не требующие мгновенного реагирования).
4. Вроде как следствие предыдущего пункта — делать разный уровень критичности алертов, но для этого надо иметь продвинутую систему оповещения. И, вероятно, на 3-4 уровень критичности смотреть уже никто не будет.
5. Если какой-то метрики, по которой генерируется алерт, нет вообще — скорее всего, на это тоже надо делать алерт. Если “нормальный” фон — 1000 ошибок в час (:sad_pepe:), а потом их внезапно 0 — маловероятно, что все ошибки исправили сразу: скорее всего, случилось что-то поинтереснее.
6. Продвинутые чуваки делают алерты на неработающую систему оповещения.
7. Алерты должны быть полными и актуальными. Банально, добавился новый эндпоинт — сразу же алерт к нему надо сделать. Если в алертах не будет актуальной и достоверной инфы, то зачем на них реагировать?
8. Как следствие, код с настройками алертов должен по быть по максимуму адекватным, а не помойкой из копипасты. Даже если это убогий TICK-скрипт для Kapacitor или поганые YAML-шаблоны Helm’а для Prometheus.
9. Алерт должен содержать информацию о том, почему этот алерт возник — какой был порог, какой значение сейчас, ссылку на дашборд и т.п. Иначе алерты будут звучать как “что-то пошло не так, сам думай, что и почему”.

В четверг посмотрел очередной видос с Numberphile и руки зачесались кое-что проверить. Суть видео вкратце: если взять f_1 = 2.920050977316134..., и вычислять n-ный элемент по формуле

f_n+1 = ⌊f_n⌋  * (f_n - ⌊f_n⌋  + 1)

то последовательность из целых частей ⌊f_1⌋, ⌊f_2⌋, ⌊f_3⌋ ... будет совпадать с последовательностью простых чисел.

Звучит очень круто, но конечно есть подвох с тем, что первый элемент (константу Буэнос-Айреса) можно вычислить, только зная простые числа. Но даже если так, то в коде-то это будет смотреться хорошо!

Вот только точность может внести коррективы, поэтому стоит проверить: а сколько простых чисел можно сгенерировать точно? 100? 1000?

Простенький скрипт дает ответ, что все грустно: с 15 десятичными знаками в константе получится всего лишь 12 чисел: 13-ое простое число — 43, а новый метод выдаст 42. Может, если использовать decimal с сумасшедшей точностью, и предвычислить константу по формуле из оригинальной статьи, то все будет лучше? Увы, но нет: с 1000 знаками точности можно сгенерировать правильно всего лишь 166 простых чисел.

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

Я слышал раньше о Pandoc, но не знал, что им пользоваться также просто, как и утилитой convert для изображений, которая выглядит порой как convert input.jpg output.png.

Pandoc мне пригодился, когда нужно было сконвертировать гугл-док с ответами для игры с кучей ссылок в Markdown для сайта. Для этого я скачал гугл-док как odt и потом выполнил

pandoc -f odt -t markdown Ребусы_ответы.odt -o result.md

Хоть форматирование получилось не идеальным, но после пары замен по регуляркам использовать его для верстки ответов под сайт стало гораздо удобнее по сравнению с копированием из гугл-дока.

Помимо старенького JMeter и де-факто стандарта для мира JVM Gatling, узнал на днях еще о существовании Siege. Если для первых двух надо что-то писать/настраивать, то для тестирования чего-то не очень сложного “по-быренькому” siege — отличный вариант, потому что он консольный и все параметры передаются аргументами. Пример команды:

siege -c10 -t60s --content-type "application/json" --header="Connection: Keep-Alive" -b 'https://example.com POST {"some": 0, "payload": "10"}'

Она будет бомбить 10 “пользователями” в течение 1 минуты указанный адрес с нужными заголовками.

А вообще всяких утилит для нагрузочного тестирования довольно много, сравнение можно посмотреть тут.