#ссылка дня

Я не удивлюсь, если в комментариях напишут: "Ну ты чо вообще, все это знают", но тем не менее.

У Google помимо прекрасных блогов разработчиков (того же Chrome) и весьма неплохой документации на их проекты имеется и простая обучающая платформа — Code Labs.

https://codelabs.developers.google.com/

Повторю, это не тайна, но я не знал, что материалов настолько много. От дизайна и веба до Flutter и ИИ. Ну и всеми любимый Python, куда ж без него.

Прошел несколько примеров по Flutter. Да, это в основном "пиши вот так", но на то оно и простая платформа. На некий путь вполне может навести, руку набить. Ну и бесплатно при этом.

Моя рекомендация, в общем.

#google #dev #education #бородач

#фишка дня

Наверное, было бы удобно отображать статус разработки компонентов в Storybook, согласитесь?

Но вот авторы Storybook так не считают. Потому никакой возможности поместить статус отдельного взятого компонента в сайдбар нет.

Хотя, не было.

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

Как-то так:
const meta: Meta<typeof Btn> = {
title: 'Components/Button',
component: Btn,
tags: ['NEW'], // Example of assigning status as tags
argTypes: {...},
};

Репозиторий: https://github.com/varya/storybook-8-sidebar-statuses
Пример: https://varya.me/storybook-8-sidebar-statuses/

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

#storybook

#инструмент дня

Если меня спросят, на чем я стал бы делать ранний прототип, я бы ответил Drupal. Ну или Ruby on Rails. Ну просто потому что я их знаю. На Drupal вообще мышкой можно все накликать и получить рабочий API.

Но, конечно, это уже сравнительно оторвано от реальности :) Простой CRUD aka Create-Read-Update-Delete можно собрать тысячей разных способов.

Так что стоит принести ещё один: Remult.

https://remult.dev/

Remult использует всю мощь декораторов TypeScript для описания своих т. н. сущностей, которые потом станут моделями.

import { Entity, Fields } from "remult"

@Entity("tasks", {
allowApiCrud: true
})
export class Task {
@Fields.cuid()
id = ""

@Fields.string()
title = ""

@Fields.boolean()
completed = false

@Fields.createdAt()
createdAt?: Date
}

После чего остается только зарегистрировать созданную сущность в сервере на, например, express и получить готовый CRUD API.

Останется дело за фронтендом, который автоматом тут не генерируется, зато вам доступно множество хелперов для управления своими сущностями.

Прекрасная документация, отличные пошаговые инструкции к разным фреймворкам. Ребята однозначно старались.

Горячая рекомендация, в целом.

#typescript #crud

#такое дня

Что, все уже услышали об уязвимости в xz? По ней можно фильм снять.

Для тех, кто любит поточнее: https://habr.com/ru/amp/publications/804039/

Для всех остальных суть в том, что кто-то пять лет внедрялся в доверие к разработчикам средства сжатия lz (а конкретно, библиотеки liblzma) и в какой-то момент внедрил бэкдор. И никто и внимания не обратил: ну уважаемый человек же.

А заметил это вообще чувак из Майкрософт: Андрес Фройнд. Ему показалось, что тесты как-то медленно проходят 🫠

Ладно, к сути. Информация об уязвимости распространяется быстро. Бэкдор включён в версии 5.6.0 (февраль) и 5.6.1 (март). Линукс-дистрибутивы многие вряд ли этому подвержены, а вот brew в macOS вполне кому-то мог это доставить.

Так вот, не надо кидаться проверять версию через запуск xz --version! Вы буквально запустите приложение. Это касается любых новостей об уязвимостях.

Впрочем, если вредонос уже скачан — то он уже в системе, ибо библиотека-то используется ну почти везде, особенно при установлении SSH-туннелей.

Не надо это делать на своих корпоративных машинах :)

Потому:
1. Проверяйте версию через пакетные менеджеры
apt-cache policy xz-utils
brew info xz
и так далее
2. Когда откатили — перезагрузитесь, обязательно.

Как-то так.

P. S. PR с уязвимостью был одобрен старым добрым LGTM.

#фишка дня

Рукописи не горят! А веб-сайты?

У нас уже был пример сгорающего попапа от Ксении Кондрашовой. Но ей, определённо, было этого мало :)

Итак, встречайте, великолепный пример сочетания шейдеров и анимаций GSAP, а конкретно — GSAP ScrollTrigger: https://codepen.io/ksenia-k/full/GRLqZVR

Впечатляющая работа.

#webgl #animation #shader #scroll

#релиз дня

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

Итак, встречайте: Bun 1.1. Теперь со вкусом Windows!

Для тех, кто пропустил последний год: Bun — это среда выполнения JavaScript, аналогичная Node.js и решающая в целом те же задачи, но построенная вокруг JavaScript-движка JSC aka JavaScript Core.

Напомню, что JSC используется в браузере Safari и в React Native. А это значит, что туда свои силы вкладывают Apple и Facebook. Node.js построен вокруг движка V8, используемого в Google Chrome.

Но дело, конечно, не только в движке. Bun весьма быстрее Node.js и включает в себя не только среду выполнения и оболочку командной строки, но и сборщик, и тесты и пакетный менеджер (npm все же не часть node если что).

Ну просто для сравнения, bun install в 18 раз быстрее pnpm и yarn, и в 30 раз быстрее npm.

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

Но в версии 1.1 нам пообещали, что множество проблем совместимости с Node.js уже устранено.

И, конечно, главное нововведение: полноценная поддержка Windows! Парни реально последние полгода на это положили.

В общем, смотрим видео о выпуске, там много всего: https://youtu.be/yXTFOeGly9o?si=F4tr_R8X8ec0_BXx

Ну и по факту это значит, что теперь смело можно рассчитывать, что написав скрипт для Bun в Linux, он прекрасно запустится в macOS и Windows и работать будет одинаково.

В общем, когда переходим, котаны? А кто уже?

#bun #node #jsc

#библиотека дня

Сегодня не самая обычная библиотека, решающая, впрочем, достаточно сложную задачу.

Компания Evil Martians и Андрей Ситник конкретно известны своим скурпулёзным подходом к интерфейсам и их оптимизации. Если кто-то ещё не в курсе существования их блога, настоятельно рекомендую: https://evilmartians.com/chronicles

Ну конкретно по теме канала — тег Frontend, конечно же.

Так вот, одной из их достаточно новых специализаций является разработка интерфейсов профессиональных утилит, в том числе для десктопа. Например, UI для HTTPie.

А без чего нельзя представить себе профессиональное приложение? Правильно, без хоткеев. Да и вообще нынче доступность без хоткеев — не доступность вовсе.

И вот Андрей Ситник на днях выкатил обновление своей библиотеки KeyUX: https://github.com/ai/keyux

Пример её работы на видео. А что умеет?

1. Добавлять горячие клавиши по aria-keyshortcuts
2. Возвращает на место :active у кнопок при использовании клавиатуры
3. Превращает списки в навигационные элементы
4. Правильно отрабатывает стрелки, табуляцию и Esc.
5. Показывает подсказки если нужно.

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

#javascript #a11y #hotkeys

#статья дня

Белиберда на экране — вовсе не белиберда. Именно таким образом Slack тестирует свою систему интернационализации. Переводов.

i18n, если ещё короче.

Если говорить строго, правильная локализация — это жопа.

1. Какие-то языки по своей природе длиннее, какие-то короче. Какие-то вообще иероглифы.
2. Нужно не только перевести слова, но и учесть формат дат.
3. Убедиться, что какой-то кастомный символ не крашит приложение (да, такое бывает).
4. И всё это надо как-то поддерживать и обновлять.

Так что статья из блога инженеров Slack — самое то: https://slack.engineering/localizing-slack/

TL;DR они используют синтаксис ICU MessageFormat для хранения кроссплатформенных переводов, а белиберда на экране нужна для тестирования, чтобы быстро находить непереведённые строки. Они будут выглядеть нормально.

#slack #i18n

#фишка дня

Эмулируем различные особенности зрения легко и просто!

Если залезть в Chrome DevTools, нажать на меню "три точки", выбрать Rendering и найти раздел Emulate vision deficiencies, можно легко понять, как видят ваш сайт, например, люди с искажённым цветовосприятием. Дальтоники.

Список эмулируемых особенностей:
1. Нечёткое зрение (тут и близорукость, и дальнозоркость подойдёт)
2. Протанопия (нет красного)
3. Дейтеранопия (нет зелёного)
4. Тританопия (нет синего)
5. Ахроматопсия (нет цвета)

Начиная с Chrome 112 есть возможность имитировать пониженную контрастность (для имитации катаракты, например): https://developer.chrome.com/blog/new-in-devtools-112/#reduced-contrast

#a11y #chrome #devtools #бородач

#фишка дня

Надоело угадывать высоту строки, чтобы текст стал высотой ровно в прописную букву? Say no more!

 line-height: 1cap;

И вы великолепны.

P. S. ещё более вы великолепны, если Safari версии больше 17.2 включительно.

#css

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

Дамы и господа, неправильно свёрстанный макет это x2 к срокам, потому что переделывать сложнее, чем делать изначально правильно.

Ну и поскольку я не все обещания данные в посте исполнил, отметьте, что бы хотели узнать по теме, особенно новоприбывшие.

#заметка дня

#css #html #pp #pixelperfect

Один из самых проблемных вопросов верстальщиков — не обязательно начинающих — это так называемый “пиксель пёрфект” (pixel perfect). Проще говоря, свёрстанный макет должен полностью соответствовать дизайну вплоть до последнего пикселя.

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

Но всё немного интереснее.

Давайте сразу определимся: правильно свёрстанный макет точен до пикселя по умолчанию. Точка.

Правильная вёрстка экономит время и силы. Даже если вы, как и я, верстаете итеративно, то есть набрасываете крупные блоки и потом начинаете приводить в нужный вид, пишите нужные значения сразу, не откладывая на потом.

У блока стоят поля и отступы по 16 пикселей? Нет ни одной причины ставить 10, чтобы “было легче считать” (и такое бывает), а потом проходить по всему макету заново. Ставьте сразу 16, а чтобы помочь себе — пользуйтесь расширениями для браузера, например https://www.welldonecode.com/perfectpixel/

Конечно, так можно дойти до крайности. Я много раз видел как люди бездумно копируют размеры из Sketch, Avocode или Figma наивно полагая, что уж кому как не им знать о размерах и положении. Это самая большая ошибка, и я уж молчу о том, что редакторы зачастую ставят абсолютное позиционирование всему подряд.

Будьте заранее готовы к тому, что макет – живой. Выделенный блок делится на секции? Используйте проценты во флексах или fr в гридах, делите его относительными единицами. Дизайнер поставил 63 px? Это явно дрогнула рука, не используйте нечётные значения никогда, округляйте до ближайших x4 (в данном случае — 64). Во всех размерах должна просматриваться логика, не могут три кнопки в ряду иметь один размер, а четвёртая – другой.

Почему кратно четырём? Потому что округление в пределах четырёх пикселей вполне укладывается в общепринятое понятие точной вёрстки, но на крайний случай у вас останется ещё как минимум два уровня деления. А при использовании нечётных значений transform или устройства с полуторной плотностью экрана дадут вам размытую картинку (к счастью, последние версии браузеров эту проблему часто решают за нас).

В скором времени я попробую затронуть тему вёрстки изначально неудобных макетов: что делать если вам выдали макет в 1920 пикселей, а большинство ноутбуков до сих пор имеют 1366 и как вести диалог с дизайнером и заказчиком в такой ситуации.

#заметка дня

Сразу с панча: не используйте input[type=“number”].

Он тащит за собой целый ворох проблем:

1. странно выглядит (ниже о том, почему);
2. плохо стилизуется;
3. не подчиняется стандартным атрибутам вроде maxlength (sick!);
4. имеет ARIA-роль spinbutton (ниже поясню, что это);
5. позволяет ввести e (10e9) и валидация даже не заикнётся;
6. в старых Safari и Chrome округляет введённые числа (например, номер кредитки) до мантиссы и экспоненты (по-моему, это уже конец);
7. во время ввода можно случайно нажать стрелку вверх или вниз (или даже тронуть колесо мышки на некоторых ос) и введённое число изменится.

Как видите, минусов немало. А откуда они вообще взялись?

А всё просто: input[type=“number”] создавался для имитации т. н. tally counter, ручного счётчика. Ну вы наверняка видели фильмы, где людей или скот считали надетым на палец устройством. Отсюда и ARIA-роль spinner (счётчик оборотов), и стрелки ввода.

Вот только числа с плавающей запятой или ввод мантиссы и экспоненты — это уже самодеятельность браузеров. Что приводит к идиотичным ситуациям вроде округления чисел.

Так что же делать?

А делать следующее:

<input type="text" inputmode="numeric" pattern="[0-9]*">

В 2024 году с такой конструкцией проблем у вас не возникнет. И с точки зрения доступности всё верно. И на мобильных клавиатура нужная встанет.

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

За подробностями можно обратиться к блогу разработчиков официального сайта правительства Великобритании: https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/

Крайне неожиданно было вообще узнать, что ребята из техотдела правительства Великобритании вообще свой блог ведут на официальных началах.

Я помню подобное было у многих государственных сайтов,. но почти все блоги исчезли со временем...

Подытожим: input[type=“number”] делался не для того, как его применяют.

Подумайте об этом.

#css #html #number #aria #semantics #a11y #бородач

Как я могу помочь CSS развиваться

Периодически в подкасте «Веб-стандарты» мы обсуждаем всякие новые CSS-фичи. CSS-блогеры активно делятся демками с этими фичами, выпускают про них обучающие материалы, готовят доклады. Но я, например, не часто задумываюсь, откуда у людей, которые занимаются тем, чтобы новые фичи в принципе появлялись, берётся мотивация этим заниматься.

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

А что с придумыванием этих фичей? Есть комитет w3c, рабочие группы в нём: там некоторые занимаются фичами на зарплате, а кто-то — на энтузиазме. И вот среди энтузиастов есть люди и компании, которые очень сильно влияют на стандарты как качественно, так и количественно.

Мириам Сюзанн — как раз такой человек. @scope, @layer, CSS Anchor Positioning, popover — все эти довольно революционные для CSS спецификации так или иначе дошли до браузеров благодаря OddBird — компании Мириам. Они ещё делают SCSS.

Никого ни к чему не призываю, но так как я сам спецификации писать не умею, а в браузере их реализовывать и подавно, то помогаю как могу. Буду донатить OddBird, которым сейчас нужны деньги на дальнейшую работу. Когда-то веб-разработчики всем миром собрали на атрибут inert. Я хочу таким образом двигать CSS вперёд.

Хотите так же помогать развитию CSS — https://opencollective.com/oddbird-open-source.

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

Ну а если ваш путь — тот самый open source, который вы хотите делать своими руками, то вот вам видео выходного дня: Андрей Ситник ещё в 2019 году поделился опытом, как продвигать open source.

https://youtu.be/-CLm8bwwL_M

#ссылка дня

Внимание, важный вопрос!

Что вам больше нравится: Volvo или Porsche?

Прежде чем отвечать, подумайте! Ведь речь идёт не об автомобилях, а о...

...дизайн-системах.

Вот это поворот

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

Давайте на них посмотрим.

Volvo: https://vcc-ui.vercel.app/docs

И их Storybook: https://developer.volvocars.com/design-system/web/?path=/docs/getting-started-1-introduction--docs

Porsche: https://designsystem.porsche.com/v3/

Ребята из Volvo даже блог свой ведут. Например, они ушли от CSS-in-JS назад к CSS ещё до того, как это стало модным: https://vcc-ui.vercel.app/blog/2022-11-23-future-css

Кто найдёт дизайн-систему BMW? :)

Кто использовал эти две?

#css #design #ui #storybook

#фишка дня

Когда-то давно я слышал о таком свойстве, как text-align-last.

Что оно делает? Ну, думаю, всё понятно из иллюстрации :)

Работает с последней строкой индивидуально, позволяя сделать более приятные глазу переходы текста, соответствующие остальной стилистике. Вот хорошая статья на тему: https://www.stefanjudis.com/today-i-learned/how-to-align-the-text-of-the-last-paragraph-line/

С интерактивным примером, как вы любите.

Почему я акцентировал на нём внимание?

Да просто я знал о нём ещё тогда, когда оно толком нигде не поддерживалось. Вот в IE работало, буквально, а в Chrome нет. И как-то все на него забили в итоге.

В этом есть небольшая беда так нами любимых «the future CSS tip». Наиграешься, разочаруешься, и забудешь :(

Но есть же наш уютный канальчик, мы тут всё вспомним :)

#css #thefuturepast

#ссылка дня

Все знают, что в JavaScript возможны утечки памяти, вот только никто их не видел.

Погоди, в смысле, никто? Вот же, целый репозиторий: https://github.com/ufocoder/javascript.memory-leaks

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

Не позволяйте памяти утечь, котаны! И дополняйте примеры :)

#javascript #memory

Переходите на тёмную сторону тему на Хабре вместе с Yandex Cloud!

Мы знаем о любви разработчиков к тёмной теме. И знаем, что многим её не хватало на Хабре. Встречайте технический квест от Хабра и Yandex Cloud, пройдя который вы сможете подключить долгожданную тёмную тему и выиграть мерч.

Пройти квест и подключить темную тему можно здесь

#ссылка дня

Я сначала подумал, что это шутка: https://github.com/tc39/proposal-math-sum

Оказалось, совсем и не шутка.

Ваши мнения, котаны?

inb4 https://0.30000000000000004.com/

#фишка дня

Продолбался весь день с подготовкой релиза. С cherry-pick-ами нужных коммитов. Шутки про черрипики точёны оставьте себе.

В чём же проблема?

А в том, что наша команда работает по trunk-модели. Всё сливается в мастер, мастер автоматически релизится как Latest-версия продукта и отправляется в тестирование.

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

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

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

Для этого реализуются различные feature-флаги и прочие условные условности для разделения потоков пользователей продукта по фичам.

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

Плохо когда вы забыли о гигиене и смешали коммиты от двух фичей — свободной к релизу и нестабильной. Или когда не засквошили PR-коммит (мой случай).

Тогда выборка черри-пиков может быть не самым приятным занятием. А грязные черри-пики штука очень неприятная.

Так вот, про что же фишка дня? А вот про то, что в процессе я выяснил: совсем не обязательно делать checkout коммита по его хэшу, можно по сообщению! Буквально:

git checkout ':/add multiselect to ui kit'

Причём, сообщение не надо вспоминать полностью!

В итоге, git выберет ближайший к вам такой коммит. Уютно!

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

#git #til #commit #бородач