mefody.dev

Полезный npm-пакет, который помогает обновлять npm-пакеты.

Мне периодически нужно обновлять зависимости в проектах: где-то из-за соображений безопасности, где-то для новых фичей, где-то просто хочется. Конечно, можно запустить npm update, но если версии зависимостей прибиты гвоздями в package.json, то эффект слабый. Можно использовать npm outdated и руками проходится по всем пакетам. Или написать bash-скрипт, который распарсит это дело и установит latest-версии.

Но я же не первый, кто про это задумался. Есть очень удобный npm-check-updates, у которого куча опций, сильно упрощающих процесс. Почитайте Readme, документация у проекта хорошая.

Как его использую я:
1. Ставлю пакет как глобальную зависимость npm install -g npm-check-updates.
2. ncu --interactive --format group — вывожу список доступных обновлений с группировкой по семверу. Накатываю патчи, тестирую.
3. git commit — сохраняю слепок проекта, чтобы была возможность откатиться.
4. ncu --interactive --format group — накатываю миноры, тестирую. Иногда уже на этом этапе выясняется, что какие-то пакеты решили переехать на ES-модули без мажорного обновления. Если получается мелкими правками в коде починиться, то профит. Если нет, то откатываюсь на рабочую версию и пробую накатывать только те пакеты, которые ничего не ломают. На это уходит чуть больше времени.
5. git commit — сохраняю слепок проекта, чтобы была возможность откатиться.
6. ncu --doctor -u — пробую обновить всё оставшееся, но пакет по-умному запускает npm test и обновляет только то, что не роняет тесты в проекте. Так как иногда в проектах есть скриншотные тесты, для которых нужно не только установить проект, но ещё и собрать и запустить, то на этом этапе можно переключиться на чтение отложенных статей, приготовление кофе, созвоны с коллегами. К сожалению, на этом этапе скрипт чаще всего ничего не обновляет, но по логам прогона тестов и сборки можно хотя бы понять, что именно ломается.
7. Тестирую, git commit, git push.

Если вы точно знаете, что какие-то библиотеки не нужно обновлять, рядом можно положить файлик .ncurc.json, куда прописать в reject список прибитых гвоздями зависимостей. Например, версии фреймворка, TS, специфичных сборщиков.

npm-check-updates тянет с собой много зависимостей, кого-то это может смутить. Поэтому не стесняйтесь искать удобные вам альтернативы. Главное, оптимизируйте свою работу. Пускай страдают машины.

Генеративный Open Graph

Наткнулся на интересную статью про то, как генерировать картинки для Open Graph так, чтобы это выглядело почти как искусство: https://matthewstrom.com/writing/generative-art-og-images/.

Небольшой ликбез для тех, кто с этим не сталкивался. Когда вы вставляете какой-нибудь урл в социальных сеточках, то там часто появляется карточка с заголовком, каким-то текстом и картинкой. Делается это всё при помощи простых мета-тегов вроде <meta property="og:image" content="https://mefody.dev/og_image.jpg" />. Роботы социальных сетей ходят по урлам, достают данные из этих мета-тегов и кешируют где-то у себя, чтобы быстро показывать рядом с постом эти карточки.

У меня был про это доклад на двух конференциях, можете посмотреть слайды: https://mefody.github.io/talks/lazy-og/

В какой-то момент маркетологи поняли, что такие картинки неплохо привлекают внимание в общей массе постов, поэтому подключение OG стало почти обязательной частью проектов, где есть частое обновление контента, вроде новостных лент или блогов. У меня в блоге тоже есть OG. В Wordpress есть много плагинов для добавления картинки к посту, чтобы она потом в таких вот карточках показывалась.

Постепенно мы доросли до того, что как будто бы не надо к каждому посту придумывать свою картинку, а можно попросить дизайнера придумать шаблон, который мы будем сами заполнять программно по данным из статьи. У GitHub есть отдельный пост про то, как они прикручивали реалтайм карточку для проектов, авторов, репозиториев: https://github.blog/2021-06-22-framework-building-open-graph-images/.

Основная проблема генерации на лету — скорость. Роботы не будут ждать вечно, пока картинка грузится. Если картинка отдаётся долго, то робот просто уйдёт. Ещё и закэширует у себя пометку, что у вас на странице картинки нет. Может быть попробует достать картинку из тела статьи, но это не точно. Поэтому чаще всего для таких решений используется генерация картинки-превью при сборке страницы (у многих генераторов статических сайтов есть для этого плагины) либо генерация картинки где-нибудь в облаке при публикации (дёргаем ручку один раз, она долго генерируется, а потом отдаётся роботу из файловой системы сохранённая).

Когда-то написал свой велосипед для такого: https://github.com/MeFoDy/talks/tree/master/lazy-og/demo. Буду рад, если кому-то пригодится для своей более качественной реализации. Прелесть решения в том, что это, как и у многих, банальный скриншот страницы с вставленными поверх стилями для OG-карточки. То есть достаточно запустить какой-нибудь Puppeteer, открыть страницу, вставить специальные стили, сделать скриншот, сохранить его в файловую систему — профит! И оно даже работает довольно шустро, если правильно разогреть Puppeteer.

Автор статьи, Matthew Ström, пошёл дальше и для каждой странички рисует canvas с довольно интересной математикой. Его решение довольно гибкое, можно под себя перекрасить без труда. Обязательно почитайте.

Отойдём ненадолго от совсем уж технических тем.

На прошедших выходных был на конференции Yamal.Dev Conf. Это двухдневная конференция на абсолютно разные темы из сферы ИТ: бэкенд, фронтенд, ML, образование, лайфстайл и другие. Проходит она в Салехарде, что делает её уникальной — не так много событий такого уровня проходит за полярным кругом.

Почему решил отметить именно эту конференцию?
Мне повезло быть спикером на первой конференции в прошлом году. Тогда это была попытка начать какой-то движ вокруг ИТ в регионе, где в принципе любой движ — уже событие. Был один день, минимум докладчиков, никакого дайвёрсити, -40 градусов за окном (а возле статуи мамонта все -52), полупустой зал, в котором многие пришли просто посмотреть, хоть и не работали в ИТ активно.

Именно тогда я понял, как важно развивать именно локальные сообщества. Москва, Петербург, Минск на тот момент уже были перенасыщены ивентами. Хочешь вписаться в движуху — вот тебе список из 20+ чатиков, где уже что-то происходит. Мотивируйся и развивайся, сколько тебе влезет. Но есть и другой мир, где одна конференция в год — большое событие.

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

И получилось хорошо. Классные специалисты из разных городов приехали и поделились своим опытом. Были воркшопы не под запись, где можно сходу получить практические навыки. Мой хороший друг впервые в жизни попробовал себя в роли докладчика на мастер-классе с большой аудиторией по собиранию умного дома из подручных средств и получил замечательные отзывы. Зрители подходили и искренне благодарили за заряд вдохновения и знаний. В спикерском чатике уже строят планы на следующий год. И это здорово!

В регионах не так много возможностей что-то в своей жизни радикально менять. Многие айтишники из больших городов живут в «пузыре», где у нас есть выбор и возможности, даже «фи» можно выразить, если смузи на афтепати был недостаточно густой, а бананы на кофе-паузах могли бы быть и позеленее. В маленьких городах нужен какой-то триггер, который покажет, что можно по-другому: попробовать войти в ИТ, посмотреть на опыт больших компаний, которых там банально зачастую нет, послушать истории «селебрити» и вдохновиться их примером. При этом местные активные айтишники искренне хотят что-то менять, развивать сферу, уходить от стагнации. Поэтому мне важно помогать таким начинаниям там, где я могу быть полезным со своим опытом больших конференций. Чтобы кто-то решил в своей жизни что-то поменять, делать добрые дела и не бояться смотреть на жизнь за пределами своего маленького города. Открывать глаза и уши и учиться слышать весь мир, а не только то, что приносят.

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

Поддерживайте локальные сообщества. Они искренние, открытые, со своим вайбом и по-настоящему что-то меняют в сознании.

Всем добра и мира!

Вышло обновление SVGOMG.

SVGOMG под капотом обновился до SVGO 3.0, и на самом деле обновление SVGO в этой новости даже интереснее.

Во-первых, если вы у себя используете SVGO для оптимизации SVG-файлов где-нибудь в пайплайне, версия 3.0 требует Node.js 14+. Ещё одна причина обновить ноду, если ещё не успели. Во-вторых, обновились конфиги для SVGO: active больше не нужен, extendDefaultPlugins тоже убрали. В-третьих, плагин sortAttrs теперь включён по умолчанию, поэтому после обновления может раздуться коммит с обновлёнными svg-шками. Не пугайтесь, это ради лучшей gzip-компрессии.

Обязательно почитайте release note, там много полезных инструкций, как обновиться правильно.

Почему обратил внимание на обновление именно SVGOMG? Там появился ползунок для плагина convertTransform, который позволяет контролировать точность чисел. Поигрался с несколько SVG — банальное уменьшение точности чисел на некоторых картинках вообще не заметно глазом. И даже скриншотные тесты не всегда ловят эти незначительные диффы. При этом экономия в байтах местами колоссальная, потому что в изначальных картинках очень много длинных дробных чисел. Этот же плагин можно аккуратно настроить и у себя в пайплайне.

Если вы ещё не используете ничего для минификации SVG — зря. Попробуйте подключить SVGO, мне он много трафика экономит на всяких иконках из Figma. Пока что не видел ни одного графического редактора, который сразу хорошо минифицированный файл выдаёт, всегда нужно поверх напильничком проходиться.

Есть древний доклад Виталия Харисова «10k», там много идей для оптимизации размера страниц можно почерпнуть. И хотя я знаю, что Виталий некоторые SVG жмёт прям руками, при этом получается чуть-чуть лучше, чем у автоматики, но в докладе он советует всё-таки SVGO.

Chromium собирается выкатить выравнивание таймеров (в том числе DOM-таймеров) на 125 Гц.

Сейчас движок старается запустить таймер тогда, когда дедлайн запуска задачи по таймеру пришёл. Причём для разных задач есть разные механизмы расписаний вызовов задач, для синхронизации которых используется механизм сообщений (messaging). И в некоторых местах из-за этого возникают баги синхронизации, а в других видно пустое потребление ресурсов, когда движок выполнения задач просто вхолостую гоняется на проверку «Ну что, а теперь пора?».

Для WebRTC уже попробовали включить принудительную синхронизацию на 120 Гц (то есть задачи выполняются 120 раз в секунду), и в некоторых случаях это привело к 12% экономии энергопотребления. Теперь хотят включить такой же механизм для многих других задач. Подробнее можно посмотреть здесь.

Как это скажется на разработчиках?
С одной стороны, приложения просто из коробки начнут меньше разряжать батареи устройств. С другой — если у вас были какие-то вычисления или анимации, для которых критически важно выполняться как можно раньше, то стоит присмотреться к другим API, которые работают не на таймерах. Chrome уже предлагал такие решения после релиза Chrome 88. После включения механизма выравнивания таймеров ваши графики замеров пользовательских метрик, например, могут начать показывать другую картинку с дельтой ±8ms.

Но, кажется, для большинства приложений ничего не изменится. Пользователей с мониторами, которые работают чаще 125 Гц, не так уж много, а для рендеринга сайтов в браузере мы всё ещё опираемся на 60 FPS.

Наткнулся на интересную статью про псевдокласс :has(), или, как его ещё называют, родительский селектор: https://utilitybend.com/blog/practical-uses-of-the-has-relational-pseudo-class

Автор делится полезными примерами того, как это нововведение в CSS может изменить мышление при вёрстке страниц. Можно додумать свои примеры:
1. form:has(:invalid) — способ как-то стилизовать форму, в которой есть ошибки заполнения инпутов. Так, например, можно показывать блок с сообщениями об ошибках.
2. .grid:has(img) — способ понять, нужно ли перестроить сетку под наличие в ней картинок. Полезно для всяких плиточных интерфейсов.
3. .article:not(:has(h1)) — можно вообще прикрутить CSS-«линтер», который будет подсвечивать несоблюдение каких-то договорённостей в команде, вроде «в статье должен быть заголовок первого уровня».

.article:not(:has(h1)) {
    background-color: red;
}

Дать QA набор таких сниппетов — и тестирование той же доступности вёрстки станет быстрее.

Кстати, с :not автор немного запутался. В его примере селектор выглядит .articles:has(:not(figure)), что по сути значит «выбери элемент с классом articles, внутри которого есть что-то, кроме figure». То есть селектор .articles:has(:not(figure)) article по сути не имеет смысла, проще написать .articles article — эффект тот же, только специфичность селектора ниже.

Но за что люблю современный веб, так за то, что можно в твиттере написать автору, а он пообещает посмотреть пример внимательнее и исправить. Так и сделал, ждём апдейта статьи.

Когда-то давно у меня была задача заставить браузер в некоторых местах показывать эмодзи сердечка, а в некоторых — UTF-символ.

Казалось бы, есть спека, по которой нужно добавлять управляющие последовательности: U+FE0E для выключения эмодзи, U+FE0F — для включения. Даже статью про это в бложег написал. Но этот способ всё равно не везде работает, операционные системы часто ведут себя своенравно.

Томас Штайнер сегодня показал, что в черновиках спецификаций, оказывается, есть свойство как раз для таких задач: font-variant-emoji. Очень жду его реализации в браузерах. Пусть машины разбираются, как что рендерить по моим командам, а не я читаю спеку UTF для костылей всего над одним символом.

https://drafts.csswg.org/css-fonts/#font-variant-emoji-prop

Готовлю доклад «Chrome DevTools — спрятанные полезности», в процессе нахожу всякое интересное, связанное с недокументированными возможностями панелей девтулзов в Chrome.

Оказывается, во вкладке Network фильтр можно использовать для удобного дебага расширений.
Синтаксис фильтра простой: key:value, где key — параметр запроса вроде схемы, урла, метода, а value — значение, которое можно в том числе задавать регуляркой. И если вы хотите инвертировать фильтр, то можно либо чекбокс рядом с фильтром поставить, либо добавить - перед key:value.

В документации к фильтрам есть информация только про схемы http и https, но, внезапно, запросы из браузерных расширений можно обрабатывать вот так:
- -scheme:chrome-extension — прячет запросы из браузерных расширений;
- scheme:chrome-extension — показывает запросы только из браузерных расширений.

Channel created