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

На неделе немного “поразвлекался” со 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 и под конец есть рассуждения о том, как понять, сколько времени инвестировать в проектирование.