Прикольная штука, которая за счет магии мета-программирования добавляет GUI для скрипта на основе его argparse структуры (увы, просто для sys.argv не работает). Область применения конечно весьма узка (потому что вряд ли ваша бабуля будет запускать питон-скрипты), но вдруг кому пригодится. Тянет wxpython, который ставится полгода.

Prometheus — де-факто стандарт для всяких куберов и микросервисов. До него я работал с TICK-стеком, в частности с InfluxDB.

Я особо не вдавался в различия этих двух систем — ну метрики и метрики, че там может быть такого? Но недавний опыт с запихиванием данных в Prometheus в нестандартном сценарии и их последующим запросом показал, что можно конечно плакаться и колоться, но кактус жрать дальше как-то не очень. В итоге обсудили с коллегой, что если мы в основном пушим данные, то InfluxDB лучше подходит для наших сценариев.

Фундаментальное отличие Prometheus от InfluxDB — это разные модели работы с данными: push vs pull. При этом у Prometheus есть Push Gateway (который работает хреново), а InfluxDB — telegraf (агент, который опрашивает и пушит), и он работал без особых проблем. Киллер-фича Prometheus — это то, что он хорошо клеиться с микросервисами, для InfluxDB нужно чуть больше церемоний. Но складывается впечатление, что InfluxDB универсальнее и покрывает большинство сценариев.

Хороший разбор на эту тему можно посмотреть тут.

Занятный доклад от Одерски про усилия команды разработчиков языка, чтобы Scala стала проще.

Хотя я и до этого смотрел несколько докладов Одерски, в этом меня немного удивила практичность подходов: у меня было стереотипное представление об ученом в слоновой башне с жесткими принципами функциональной чистоты. Например, он рассказывает, как энтузиаст заменил императивную реализацию расстояния Левенштейна в компиляторе на чисто функциональную с иммутабельными структурами. Оказалось, что реализация неверная, да еще и хуже читается, поэтому оставили старую. Другой пример: большинство присутствующих в зале скалистов признало, что тупой матчер на Option лучше, чем .fold или .map(...).getOrElse(...).

В конце доклада есть еще блок о Caprese и эффектах. На примере функций высшего порядка Одерски объясняет, чем capabilities лучше проверяемых исключений.

Классная обучающая и интерактивная статья про шейдеры. Я очень далек от графики (и игор, которые ее требуют Т_Т), но прочитал с удовольствием.

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

Вот вы накалякали PR, пришла стадия рефакторинга — стоит пройтись по всем мелким замечаниям и поправить их. Но по умолчанию в какой-нибудь Intellij будут показываться все TODO, а не только ваши. Конечно, ваша кодовая база хорошая, и их будет не очень много, да? Падме.жпг В итоге надо как-то отфильтровать только то, что относится к вашей ветке.

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

Попробуем сделать это через консоль. Читать документацию git — сомнительная затея: как и пользовательский интерфейс git, она тоже любит “тщательно выбирать друзей”. Нам нужны все изменения в ветке:

git diff --merge-base master

Эта команда выдаст патч на все закоммиченное и добавленное в git. Но есть еще и недобавленные файлы:

git ls-files --others --exclude-standard

Объединяем это все через cat и grep’аем. Ну и чтобы не запоминать колбасу, добавляем функцию в ``~/.bash_aliases` (или где вы там храните своё):

function branch_todo(){
  cat <(git ls-files --others --exclude-standard -z | xargs -0 cat) \
      <(git diff --merge-base master) \
  | grep -i -E 'TODO|FIXME|FIMXE'
}

Многие, я думаю, слышали, как в 2016 Alpha Go победил Ли Седоля в го, после чего тот заявил о своем уходе из го.

В феврале этого года вышло исследование, в котором экспериментировали с аналогичным, более продвинутым движком и нашли в нем дырку: стратегию, которой может научиться человек и обыгрывать компьютер в 97% случаев. Стратегию эту мог бы заметить любой достаточный опытный игрок. По сути, это adversarial атака на движок.

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

В общем, глубокие нейронки крутые, но не супер-надежные. Нужно больше GAN’ов строить для них.

В некоторых кругах бытует мнение, что аналитики нафиг не нужны. Вот норм доклад-наброс на тему.

Если вкратце, “зависит от задачи команды”. Докладчик обсуждает явный антипаттерн, когда аналитик выполняет некоторые функции архитектора, менеджера, продуктового менеджера, техписателя, тестировщика, программиста и т.д. — по сути, универсальная затычка. (Вьетнамские вертолеты — был в одной компании отдел из аналитиков, которые на low-code жахали целые продукты). В пользу аналитиков приводится довольно вялый аргумент, что когда нужны, тогда нужны (соответственно, когда не нужны, то не нужны). Если отбросить тавтологии, то по мнению докладчика получается, что реальная необходимость в системных аналитиках возникает только при наличии сложной предметной области и для формулирования четких требований. Уже на секции вопросов докладчику вполне закономерно указали, что требования вообще продакт должен формировать, а за толкованием предметной области — это к бизнес-аналитику. Т.е. в нормальной команде системные аналитики не нужны (и я с этим согласен).

Этот доклад мне немного напомнил мой старый пост про деление на задачки: если разрабу нужен отдельный человек, который ему будет разжевывать, что и как надо делать, то зачем он вообще нужен? Код писать? Это и ChatGPT умеет…

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

Забавный сайтик, в котором в примерах показывается, чем плох YAML. И неплохо дополняющая его статья.

Вообще YAML — неплохой пример “хотели как лучше” и отсутствия системного мышления. Конечно, прикольно иметь кучу неявных конвертаций, но очень грустно, когда произойдет что-то неожиданное вроде false вместо Норвегии. Если это еще скомбинировать с каким-нибудь шаблонизатором и затруднить проверку, то будет еще больнее — наверно, поэтому это де-факто стандарт для “девопсов” с их куберами и хельмами, да?

Для java и Kotlin павлики были, пришел через для C++.

Занятный видос, в котором реализовали public_cast, чтобы получить доступ к приватному методу. Помимо этого, там в конце есть еще и кратенькое объяснение, зачем нужны вообще эти *_cast’ы и чем плохо сишное преобразование типов (MyType)someVar.