Хороший доклад про то, как работает инкрементальный компилятор 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.

Красный флаг в описании процесса — упоминание конкретного человека вместо роли. Часто это “так исторически сложилось” и чтобы сделать какую-то нетривиальную вещь, нужно обратиться к абстрактному Даздрапермию с вопросом. Довольно часто это может быть еще и “случайный” человек — “вот за облачные сервера у нас отвечает Иннокентий, наш техдир, все никак не можем девопса нанять, а сисадмин не умеет” или “про браузерные тесты спроси у Иоанны, она так веб-дизайнер, но разбирается”.

В моменте это может показаться удобно — сразу есть контакт нужного человека с максимальной экспертностью в вопросе. Но в долгосрочной перспективе Даздрапермий может уйти в отпуск, заболеть, уволиться нахрен или сбиться автобусом. Для редких операций между исчезновением Даздрапермия и возникновением проблемы может пройти пару месяцев. И тогда будет веселый аттракцион по поиску хоть кого-то, кто его может заменить без всяких подсказок про то, кто потенциально может выполнить нужную операцию. Зачастую выясняется, что кроме Даздрапермия никто и не разбирается в узком вопросе.

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

Если же указывать роль/команду вместо человека, то сразу возникают вопросы, а кто/какая команда вообще должна быть ответственной, какие еще есть смежные активности и т.п. Теоретически это может привести к улучшению процесса в целом: например, передать наконец компетенции в более подходящие руки или обменяться знаниями внутри ответственной группы. Конечно, никто не застрахован от того, что роль упразднят/расформируют команду и т.п., но это меньший риск, чем исчезновение человека.

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

git log --all --full-history --no-merges -- your/broken/file.path

Тут идет поиск по всему логу изменений за исключением мержей (вы ведь не делаете ничего странного с файлами во время мержа?). Можно поиграться с флагом --diff-filter=D, но надо железно знать, что файл удален. В моем случае это было не так.

Наткнулся на довольно неплохую утилиту, которой просто проверить папку с ворохом .md и/или HTML файлов на наличие битых ссылок. Для маленького количества файлов проще проверить глазами, да и вряд ли там будет много кросс-ссылок, для большой документации скорее всего будет использоваться что-то вроде MkDocs со встроенными средствами и/или плагинами. А вот для среднего количества — самое то.

Онлайн запросы скорее всего вряд ли будут иметь смысл (а если репозиторий публичный, то это еще и дырка потенциальная). Одна из киллерфич — проверка якорей (/blabla#header). Поэтому проверка выглядит примерно так:

lychee --offline --include-fragments '**/*.md'

Если есть сгенерированный контент, то лучше запускать на отрендеренном сайте.

Есть и GitHub Action, пример на моем репозитории тут — при подключении нашлось аж 3 ошибки.

UPD: a после исправления командной строки, чтобы поддерживались относительные ссылки, нашлась еще пара косяков.