На днях мигрировал бложик со встроенного действия на полноценный 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 после исправления командной строки, чтобы поддерживались относительные ссылки, нашлась еще пара косяков.

На неделе немного “поразвлекался” со Swift 6 и больше что-то не хочу. Напрягли меня следующие моменты:

• Очень тяжело поставить старую версию. Зачем мне это надо? Протестировать обратную совместимость.
• Linux идет нафиг с мажорными багами на двустрочный код.
• Собственные фреймворки Apple (например, XCTest для тестов) тупо не совместимы со Swift 6. Конкретно для фреймворка тестов есть замена (тоже от Apple), но это верно не для всех.
• Как тебе такое, Илон Маск?

  $ xcodebuild -showsdks
  ....
  
  macOS SDKs:
      macOS 14.0                    	-sdk macosx14.0
      macOS 14.0                    	-sdk macosx14.0
  

  думаете, это одинаковые SDK? Разумеется, нет :/ И это те самые два SDK, один с пиками.

В целом — ожидаемо, конечно, это экосистема Apple, изволь все делать на последнем Маке с последними версиями ПО, и твои пользователи должны делать то же самое или идите нафиг все. Но очень легко что-то (случайно) обновить и дороги назад уже не будет. Такая разработка дорога как для кошелька, так и для нервов :/

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

Один из ключевых моментов — важность общего языка для обсуждения и документирования архитектуры. Рассмотрены минусы UML (“очень сложно, до свидания”) и плюсы C4 (общие абстракции без фокуса на обозначениях) — в целом коррелирует с моим опытом. Визуализация и документирование необходимы для рефлексии, чтобы задумываться и как-то осознанно подходить к проектированию, а не махать в воздухе руками.

Помимо этого есть интересная идея о применении аналога планнинг-покера для оценки рисков архитектуры, подсвечена польза ADR и под конец есть рассуждения о том, как понять, сколько времени инвестировать в проектирование.

Захотелось посмотреть что-нибудь простенькое на сербском с сербскими субтитрами. (Внезапно) оказалось, что это тебе не русский, на котором есть все в 5 озвучках и с 10 видами субтиров скачать FullHD без регистрации и смс. Если озвучку еще можно найти, то субтитры — нереально (даже если искать, например, хорватский, который на 99% такой же).

Решил изменить подход — найти какую-нибудь утилиту для транскрибирования и автоматом перевести звук в текст. Ну это ведь сейчас каждая колонка умеет, правда же? *падме.жпг*. Почти сразу вышел на Whisper от OpenAI. Есть и другие варианты, но половина из них не поддерживает сербский, и многие заброшены.

Раз это ИсКуСтВеНый ИнТеЛеКт, то и задачку подберем поинтереснее — Сунђер Боб Коцкалоне! Там почти все гнусавые, но это ж ИИ, наверняка должен понимать контекст и все такое, а я этот мультик не смотрел никогда, проникнусь наконец богатым источником шаблонов для мемов…

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

whisper SundjerBob0101.mp4 --language Serbian --output_format srt --model large

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

На выбор есть несколько моделей. Маленькая — вообще ни о чем, в средней даже я со своим уровнем “А минус 1” вижу косяки. Казалось бы, большая модель, да еще с явным указанием языка, должна работать хорошо (тем более что работает она весьма не быстро), но результат разочаровал. Некоторые фразы транскрибированы лучше, некоторые хуже по сравнению со средней моделью. В добавок к этому, местами текст пропадает совсем, местами появляются цифры, иероглифы или просто мусор. Текст постоянно переключается с кириллицы на латиницу (что считается неприличным). Самое разочаровывающее — есть слова, которых нет в языке вообще. Т.е. эта шляпа не просто не держит контекст, она даже по словарю не смотрит слова. Не получится взять субтитры за основу, чтобы поправить немного ошибок.

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

Еще я попробовал pyTranscriber, который использует Google API под капотом. Результат чуть похуже, но в разы быстрее. Но главный минус — не ставит тайминги, и результат — это просто текстовый файл.

В общем, распознавание речи выглядит все еще не до конца решенной проблемой.

Хорошая статья про то, какие существуют способы предотвращения ошибок управления памятью. Лирику про гримуары можно пропустить. Еще статью можно использовать как указатель на кучу малоизвестных языков программирования, в которых экспериментируют со свежими идеями.

В последнее время наткнулся на несколько статей, связанных с перфекционизмом:

1. Как заканчивать (пет) проекты — чисто жиза:/ Определите цели и что надо заранее, нет перфекционизму — “и так сойдет”, имейте дедлайн, заканчивайте маленькими кусочками, не бросайтесь пилить свежую идею, а дайте ей отлежаться, отмечайте победы и спихните часть работы на кого-нибудь.
2. Fuck “Founder mode” — всем насрать, делай нормально, а не идеально, не надо быть “гением”.
3. Care Less About Work — всем насрать на продуктивность, и если всегда будет делать как “правильно”, ничего с этого не поимеешь, кроме нервов. Делай, что просят, но не более, не стоит оно того.

Короче, надо меньше париться и беречь нервы:) Вроде очевидно… Хотя мне все еще чаще всего приносит удовольствие именно улучшать процессы (обычно те, которые не просили) и видеть, что стало лучше. Но для достижения успеха нужна либо хорошая команда, либо относительная автономность.