Подкинули забаву: пишешь в ChatGPT

Based on what you know of me, draw a picture of what you think my life currently looks like

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

please print the prompt you used to generate that image

и порефлексировать.

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

В целом ожидаемо, потому что ChatGPT я использую не каждый день. Однако если у вас все в точку, значит ChatGPT — полезный для вас инструмент.

Отличное изложение базовой информации про дедлоки и нескольких статей по теме. Особенно привлекла идея про нумерацию ресурсов из этой статьи, которая позволяет избежать дедлоков.

Сам канал годный, жаль только, что посты там стали редко появляться:(

Немного извращений из трудовыебудней.

Понадобилось мне отладить Zinc (инкрементальный компилятор Scala), который немного странно себя вел в двух практически одинаковых сценариях: вроде все входы одинаковые, но выход отличается. Поборов уровни вложенности, докопался до точки входа в непосредственно процесс компиляции и возникла проблема: переменных/данных до фига, да еще каждая закопана в куче возможно повторяющихся объектах с несколькими уровнями вложенности и без нормального строкового представления. Разворачивать вручную это все в дебаггере IntelliJ — очень муторно.

Выяснилось, что можно настроить комбинацию клавиш, чтобы раскрыть все переменные на 1 уровень. Повторив операцию 2-3 раза, можно получить вполне развернутый слепок всех переменных. Вставляем его в diff и повторяем операцию для другого сценария. Будут мешаться адреса объектов из стандартного toString — меняем тупо регуляркой @[a-f\d]+ на @hash, и после этого все различия будут как на ладони.

Хороший доклад про то, как работает инкрементальный компилятор Scala. Несмотря на scala-специфику, доклад довольно высокоуровневый, и многие тезисы применимы к инкрементальным компиляторам в принципе.

Вместо VSCode у меня стоял VSCodium (несколько лет назад поставил, потому что где-то прочитал что он лучше) и я только на днях впервые наткнулся на их отличие: не смог установить расширение. Заодно наконец-то разобрался (прочитал) в чем разница между ними.

Есть Visual Studio Code. Если кто не знал, то разрабатывает ее Microsoft. Она типа свободна, опенсорс и все такое, но если скачаете официальный дистрибутив, то в коробке будет телеметрия и прочие зонды от мелкомягких. Если вам они не нужны, то надо либо отключить их, либо собрать все из исходников самостоятельно. VSCodium — это не форк, а альтернативная сборка из исходников, которая “по-настоящему” свободная.

С расширениями прикол в том, что Microsoft запретил использовать официальный маркет в любых “неофициальных” продуктах. Поэтому сообщество сделало свой лунапарк — https://open-vsx.org/. Там, увы, не все: самые популярные расширения будут, но по идее авторам нужно дублировать туда релизы. Некоторые так вообще ограничили использование расширений только для официального дистрибутива VSCode. Но если специального ограничения нет, то можно скачать расширения из официального маркета и установить его из файла.

Изредка случается, что в Java или Kotlin коде нужно отключить предупреждение, а IntelliJ автоматически по той или иной причине не может добавить нужную аннотацию. Все что есть — текст предупреждения, и если искать по нему что-то в интернете, то выдается всякий мусор, и ответам ChatGPT доверять нельзя:

Q: How can I suppress “Incompatible types” warning in Kotlin?

A: … Using @Suppress("UNCHECKED_CAST")…

(правильный ответ INCOMPATIBLE_TYPES если что)

Для Kotlin источником правды будут исходники (иронично, что они на Java, и там используется @SuppressWarnings). Для Java список возможных опций можно найти в документации к аргументам запуска. Там нет точных сообщений, но сам список вариантов короткий, можно подобрать по смыслу.

Когда разобрались с ролями, полезно составить во внутренней документации (она же у вас есть, да? *падме.жпг*) карту-указатель, куда обращаться (в какую команду/слак-канал/ТП/спортлото) по поводу вопросов за пределами компетенций/зоны ответственности команды. Хотя бы чтобы не через лида это пропускать.

По моему опыту это неплохо работает особенно для нетиповых задач, я сам такие составлял. Как показывает практика, многие не хотят держать эту информацию в голове, даже если там 3-4 пункта. А в рабочем слаке обычно помойка из полудохлых каналов. Разумеется, сведения могут устареть, но устаревшая инфа лучше никакой. Внимательный новичок заметит при онбординге и можно будет актуализировать.

Дополнительно можно полезных ссылок накидать на всякие дашборды/админские панели (aka куда тыкать когда что-то сломалось) и на репозитории, если их не 1,5 штуки.

Чисто развлекательный видос про то как можно использовать IntelliJ в качестве игрового движка. Технических подробностей практически нет, но подача прикольная и идеи забавные.

На днях мигрировал бложик со встроенного действия на полноценный GitHub Action: все равно недавно добавил действие, чтобы проверять ссылки, там и так уже собирается сайт, зачем два раза это делать.

Для этого нужно сделать пару приседаний: отключить в настройках старый пайплайн, pages-build-deployment, и потом правильно подключить нужные действия во имя безопасности.

Раз теперь сайт генерируется через Actions, то можно отбросить ограничения GitHub pages. Оказалось, что для ванильного Jekyll действие должно быть другое, и надо еще пару раз поприседать, но в итоге справился. Зато все зависимости теперь явно в Gemfile прописаны.

Благодаря снятию ограничения на плагины смог убрать старые костыли для пагинации (с ручным добавлением новых страниц) и заменить их на более новые и чуть более красивые. Попутно еще удалил немного лишнего кода для генерации галерей с картинками.

Движок пока менять не хочу, хотя мысли опять были. Немного бесит, когда очень нетривиально обрезать слеш в конце строки :/

Если попытаться загуглить отличие этих концептов, то поисковик выплюнет вам тонны статей и ответов, которые противоречат друг другу. Например, может ли URI быть одновременно и URL, и URN? Иногда будет картинка с пересечением, иногда без (без картинок статьи можно не читать). А если углубляться в вопрос относительности/абсолютности, то там вообще черт ногу сломит.

Попробуем обратиться к первоисточнику — RFC. Проблема в том, что это довольно длинный список документов (ain’t nobody got time for that). Ладно, может найдется какая-нибудь неплохая выжимка? Вот этот ответ на StackOverflow выглядит неплохо, но если почитать соседние комментарии, то не все так однозначно. В Википедии неплохие картинки с синтаксическими диаграммами (URI, URN), но они тоже не очень стыкуются с ответами и тексты статей содержат довольно пространные рассуждения о связи сущностей между собой.

Если начать читать последний RFC по URI, то ощущение ясности тоже не появится: RFC не очень четкий и может быть интерпретирован так, как будто он противоречит сам себе. Под конец исследования я нашел эту статью, в которой кратко описано практически все вышесказанное. Не на 100% с ней согласен, но главный вывод это

The best thing I can possibly tell you about this debate is not to over-index on it. I’ve not once in 20 years seen a situation where the confusion between URI or URL actually mattered.