Школы Академии Яндекса

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

Искренне верю, что такие способы компаний готовить специалистов выгоден обеим сторонам. Компании готовят по тем стандартам, которые им важны для их проектов. При этом в той же ШРИ программа и современная, и с глубоким погружением в практику. А для обучающихся, по сути, это бесплатная школа, выпуск из которой ни к чему не обязывает. В итоги компаниям, чтобы закрыть свою потребность в найме (не секрет же, что полного альтруизма не бывает), приходится делать очень качественные программы, чтобы на фоне других подобных программ выглядеть хорошо.

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

Кстати, Андрей @melikhov_dev Мелихов будет в ШРИ читать лекцию по Node.js. Сам схожу вольнослушателем, пожалуй.

https://academy.yandex.ru/schools/summer

Firefox Public Data Report

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

А статистика, на самом деле, интересная.

1. Хоть многие и предрекают Firefox смерть на рынке браузеров, они всё ещё удерживают 200 миллионов активных пользователей в месяц, что не такое уж и маленькое число. К сожалению, оно снижается каждый год, но не так, как рисовало моё воображение.

2. В среднем пользователи Firefox сидят в браузере 5.3 часа в день.

3. «Вечнозелёность» Firefox вполне себе хорошая: обычно за месяц 70% пользователей переходят на самый свежий релиз.

4. Почти у 40% пользователей есть какое-либо браузерное расширение, причём в России — у 60% пользователей. Из них самые популярные — блокировщики рекламы, скачивалки видео, расширения социальных сетей. Что как бы намекает, что тестировать сайты в инкогнито глупо — правильнее создавать профили для тестирования с расширениями, чтобы видеть реальную картину.

5. Разрешение экрана 1920x1080 с каждым годом всё увереннее забирает долю у разрешения 1366x768. Десктопные мониторы становятся всё больше либо поддерживают более чёткую картинку. Тестировать сайты только на 1024x768 уже странно.

6. Пока что у пользователей преобладает 2 ядра CPU, хотя всё больше могут позволить себе 4 ядра и больше. Выносить тяжёлые вычисления в воркеры однозначно пора.

7. Доля macOS как операционной системы пользователей настолько низкая по сравнению с Windows, что если вы проверяете свои сайты только в ОС от Apple, вы точно живёте в каком-то мире фантазий и понятия не имеете, как на самом деле видят ваш сайт пользователи. При этом на последней тимлидской конференции в спикерской были только макбуки, что забавно.

8. После 2021 года доля пользователей с Flash резко упала, на сегодня всего 1.771% никак не могут обновиться.

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

https://data.firefox.com/

Chrome extension that steals everything

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

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

На самом деле ревью расширения в Chrome Web Store должно блокировать таких зловредов. Но хороший лендинг с понятной инструкцией, как установить пользовательское расширение, может помочь сотворить зло.

Мораль:
1. Проверьте, что умеют расширения, которые установлены у вас прямо сейчас. Действительно им нужны все эти доступы?
2. Не зря браузеры ведут работу над тем, чтобы ограничивать доступы расширениям.

https://mattfrisbie.substack.com/p/spy-chrome-extension

PWA для новичков

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

Диванная аналитика: когда большие корпорации создают подобные курсы, у них явно есть планы о поддержке технологии. Это значит, что за PWA сейчас как минимум два гиганта: Google и Microsoft. Для меня это сигнал, что вкладываться в изучение прогрессивных веб-приложений точно стоит, эти знания смогут мне помочь.

https://learn.microsoft.com/en-us/shows/pwa-for-beginners/

Дебаг свойств-асесcоров в JS

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

В случае автора статьи на странице каждые 10 секунд происходил скролл вверх. И он логично предположил, что нужно проверить, кто трогает scrollTop у document.documentElement. И если сначала Вячеслав играется с сеттером свойства, попутно разбираясь, что не каждое свойство получится так дебажить, то потом вспоминает крайне удобную функцию debug, которая работает в DevTools. Сам постоянно про неё забываю.

https://blog.griddynamics.com/debugging-accessor-properties-in-javanoscript-everything-you-should-know/

Хороший доклад. Рекомендую. Смотрел его ещё в Салехарде, много думал.

А вот и доклад про психологическое здоровье с Московского Teamlead conf.

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

https://youtu.be/clZtSk2m05g

Скруглённые относительно друг друга углы

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

Рассматривайте такие вкладывания как поворот дороги, где дорога — полоска между краем внешнего блока и внутренним блоком. Для поворота правильно и естественно, что для внешней стороны и внутренней есть один общий центр окружности, отличается только радиус. И тогда решение для вёрстки приходит само собой.

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

https://set.studio/relative-rounded-corners/

Когда :focus-visible виден?

Ире Адеринокун простыми словами объясняет спецификацию псевдокласса :focus-visible. Браузер применяет стили для него, если:
1. Пользователь установил настройку «Всегда показывать фокус».
2. Сфокусированный элемент поддерживает работу с вводом с клавиатуры. То есть для инпутов с текстом применит стили, а для кнопок — не факт.
3. Пользователь переключается между фокусируемыми элементами при помощи устройства без указателя. Например, клавиатурой.
4. JS-скрипт переместил фокус с элемента, на котором стили применялись.

Просто и понятно. В статье есть демки, которые помогут понять на примерах.

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

/* Apply focus styles */
:focus-visible, :focus {
  outline: 1px solid red;
}

/* Remove the focus outline */
:focus:not(:focus-visible) {
  outline: none;
}

https://bitsofco.de/when-is-focus-visible-visible/

Клиент подсказывает или клиент врёт?

Люблю читать про разное интересное, с чем приходится сталкиваться браузерам, чтобы не сломать интернет. Ингве Петтерсен рассказывает о том, почему заголовок User-Agent — то ещё зло для всех.

Когда-то, когда про кроссбраузерность говорили только грустным шёпотом, а разработчики вполне могли себе позволить гордо выставить плашку «W3C Validated», некоторые начали опираться на заголовок User-Agent, чтобы в зависимости от него выдавать разную вёрстку. Или, будем честны, отдавать экран, на котором требовать установить тот браузер, в котором разработчики смогли сверстать почти без багов.

Уже тогда возникла проблема вайтлистов и блоклистов. Допустим, вы точно знаете, что ваш сайт хорошо показывается в Firefox и плохо в Chrome (фантазируем). Есть три пути:
1. Починить и в Chrome.
2. Разрешать пользоваться только в Firefox.
3. Запрещать пользоваться в Chrome.

И вот тут многие решили пойти по надёжному способу: разрешать смотреть страницу только там, где она точно работает. То есть все остальные браузеры в пролёте.

Допустим, команда сделала исследование браузеров на рынке, протестировала, закрепила где-то на уровне Apache этот самый вайтлист. И тут появлятся браузер Opera, который хочет честно подписать себя в User-Agent как Opera, но все сайты с вайтлистами просто в нём не работают. При этом инженеры Opera уверены, что у них самые современные реализации стандартов, сайты точно будут работать хорошо. Что они делают? Правильно, начинают подписываться как другие браузеры. И получаем что-то вроде Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36 OPR/97.0.4719.17.

Или вообще выходит браузер Arc, который под капотом Chromium. Разумеется, он тоже из коробки мимикрирует под Chrome. Просто чтобы работало.

В общем, идея изначально была хороша, но реалии разработки её извратили, поэтому опираться на User-Agent сейчас можно только если у вас есть все User-Agent всех браузеров мира — только так можно быть уверенным, что никого из пользователей не обидел зря, но и разработчиков не заставил реализовывать что-то, что они пока не умеют. (Надеюсь, сарказм распарсили.)

И собрались популярные браузеры, и придумали новую группу заголовков, и назвали их Client Hints. И стали передавать туда информацию только ту, что посчитали важным: мажорную версию движка, операционную систему, а вообще — то, что сервер спросит явно. Зачем гонять лишние байты, если у сервера в принципе нет обработки нюансов вроде разрядности процессора и типа устройства?

Вот только даже с таким решением случаются казусы. Написал разработчик регулярку v=\d{2}, а тут браузеры внезапно стали версии 100+ выпускать. И всё, теперь страница не показывается у тех, кто сидит на Intel Pentium 2 c Windows 98, и у большей части аудитории с самым последним Chrome на почти любой ОС. Казус.

Автор статьи как раз вспоминает про бесконечную версию Opera 9.9. Всё уже было в Симпсонах.

Мораль:
- User-Agent всё. Если вы на него опираетесь, то делаете пустую работу и рискуете сломать сайт нечаянно.
- Client Hints нужно уметь принимать. Придётся повозиться с сервером, чтобы запрашивать какие-то очень нужные вам детали о клиенте.
- Пишите регулярки внимательнее — версии браузера могут дойти до 1000 когда-нибудь (а что, ежедневные релизы от ChatGPT), а могут и вообще придумать альтернативу SemVer.
- Проверяйте фичи не по названию и версии браузера, а через прогрессивное улучшение на клиенте или те самые Client Hints. Всё равно браузеры врут, особенно новые, которых разработчики так и норовят оставить без рабочих сайтов, хоть они под капотом Chromium.

https://vivaldi.com/blog/technology/client-hints-or-client-lies/
https://github.com/WICG/ua-client-hints

И вдогонку. Если уж вам ну очень надо знать версию браузера, вот статья, как подготовиться к урезанным User Agent.

https://developer.chrome.com/en/blog/user-agent-reduction-android-model-and-version/

Разбираемся с Style Queries

Юна Кравец рассказывает о ещё одной интересной возможности, которая пришла к нам вместе с Container Queries.

В самой спецификации CSS Containment Module Level 3 очень много текста уделено тому, как работать с размерами контейнера, и буквально 3 абзаца — про то, как опираться на почти любые свойства контейнера.

Представьте, что у вас есть компонент карточки товара, который вы берёте из дизайн-системы. И эти карточки должны уметь рисоваться по-разному, с темами. Для начала можно расставить много классов по всему HTML, чтобы явно задавать тему этим карточки. Можно ещё поставить тему на какой-то родительский блок, но тогда начинается борьба со специфичностью вида .theme_dark .card, которую к тому же довольно просто сломать неправильным подключением файлов со стилями. А можно завязаться на кастомные переменные, которые в некоторых проектах уже используют как API. По аналогии с переменными окружения в серверных приложениях.

Допустим, вы договорились, что для темизации вместо навешивания классов в нужных местах вы задаёте всего один класс на родителе, тот же .theme_dark, но внутри простой код:

.theme_dark {
   --theme: dark;
}

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

@container style(--theme: dark) {
  .card_bright {
    background: linear-gradient(-30deg, yellow, orange);
  }
}

В таком случае вес селектора тот же, осталась только проблема с правильным порядком подключения стилей. Для этого, к слову, можно посмотреть в сторону CSS Cascade Layers.

Прелесть такого подхода, что выражения от стиля можно комбинировать точно так же, как медиавыражения, и при помощи бинарной логики сделать почти полноценный if внутри CSS (`else` пока не завезли, да он и не нужен, так как есть not и каскад). При этом на метрики Core Web Vitals новинка может повлиять положительно: раньше нужно было дождаться загрузки стилей, теперь тоже нужно дождаться загрузки стилей, но динамический HTML может стать приятно меньше, а стили при этом обычно кладут на CDN и настраивают для них кеширование.

Минусы подхода:
- Пока работает только в Chromium и только с кастомными свойствами. Но по спецификации должны будут в будущем поддерживаться и обычные свойства.
- Нужно переучиться использовать не классы, а кастомные переменные как API для связки CSS с HTML.
- Нужно явно задавать контейнеры, а это тоже требует перестроения мышления. А с большим количеством контейнеров на всём подряд можно и навредить производительности.

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

https://developer.chrome.com/blog/style-queries/

«Как лгать при помощи статистики»

Дарелл Хафф написал очень понятную и интересную книгу о том, как правильно реагировать на фразы «98% наших выпускников успешно устроились в жизни», «Это средство помогает 4 из 5 покупателей», «Исследование показывает, что на удалёнке эффективность сотрудников упала от 3% до 12%» и подобные им. Заметьте, я не пишу, что эти фразы — бред. В каждой нужно разобраться.

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

Если до этого вы очень много работали со статистикой и соц. исследованиями, то вряд ли найдёте для себя что-то новое. Остальным книгу крайне рекомендую.

https://alpinabook.ru/catalog/book-kak-lgat-pri-pomoshchi-statistiki/

Публичное собеседование junior-разработчика

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

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

https://www.youtube.com/watch?v=9nBbRK-Gfjg

CodeRun

Только что наша большая команда запустила бету нового сервиса для решения алгоритмических и не только задач. Если кто-то знаком с https://contest.yandex.ru/, то вы знаете, что у нас уже много лет есть платформа для проведения олимпиад и контестов. Но хотелось сделать что-то, что будет доступно не только олимпиадникам, а вообще всем. Например, полноценные задачи на вёрстку, а не только на написание кода на JavaScript.

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

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

Например, адаптивности пока нет, доступность некоторых элементов не доделана, нет OpenGraph.

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

https://coderun.yandex.ru/catalog

«Давайте созвонимся на пару минут»

Вчера читал доклад у Podlodka TeamLead Crew про то, нужны ли созвоны, как их проводить более эффективно и можно ли ставить все встречи впритык, чтобы потом после них пойти поработать.

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

https://www.youtube.com/watch?v=EEGM38yA9Wo

text-wrap: balance

Сначала Адам Аргайл написал статью, про то, как это работает. Потом Ахмад Шадид добавил полезных примеров.
В общем, прямо во время записи подкаста заслал в Shower пулл-реквест, чтобы в теме Ribbon тоже автоматом рисовались красивые заголовки.

text-wrap: balance — это способ попросить браузер рисовать текст внутри какого-то контейнера до 4 строчек сбалансированно. Например, если у вас на сайте есть длинные заголовки, в которых постоянно в последней строчке висячее слово остаётся, то браузер постарается сделать все строчки приблизительно одной длины, что по меркам типографики красиво и правильно.

Это свойство пока работает только в Chrome Canary за флагом, но как только оно начнёт работать в стабильном браузере, у вас просто станет красиво сразу. Поэтому есть смысл показать свойство дизайнерам уже сейчас, добавить его в правильных местах (см. статью Ахмада, очень хорошие примеры на мой субъективный взгляд) и уже выкатить в прод. Люблю CSS за то, что он не ломается, когда не знает какое-то свойство.

https://ishadeed.com/article/css-text-wrap-balance/
https://developer.chrome.com/blog/css-text-wrap-balance/

Новые возможности CSS, которые меняют взгляд на вёрстку

Вчера читал доклад на конференции DUMP про то, что наши страхи использовать новые фичи в CSS во многом обусловлены «детской травмой» веб-мастеров 2000-ых, что любое новое свойство скорее всего работает всего в одном браузере, а в остальных либо кое-как, либо никак. А на самом деле благодаря инициативе Interop многие фичи появляются чуть ли ни одновременно в вечнозелёных браузерах (вот бы ещё Safari подтянули релизный цикл хотя бы до обновления в пару месяцев).

Заодно поделился CSS-свойствами, которые нашёл крайне интересными за последние полгода.

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

Переопределение заголовков ответа для дебага

В Chrome 113 Dev Tools появилась, на мой взгляд, потрясающая фича, которая сильно ускорит параллельную разработку фронтенда и бэкенда в некоторых конкретных случаях.

Представьте, что у вас есть какая-то функциональность на сайте, которая зависит от HTTP-заголовков ответа сервера. Да даже представлять особо не надо, она точно есть: кэширование, куки, CORS, CSP, скачивание файлов, редиректы и разное другое. И вот в какой-то момент эту функциональность нужно доработать новыми заголовками, но на бэкенде доработка требует 2 дня разработки, тестирование и деплой, а на фронтенде — пары часов небольших правок с тестированием. Что можно сделать, чтобы не стопорить фронтенд в таком случае:

1. Сделать заглушку на бэкенде, которая топорно возвращает нужные заголовки по параметрам в URL. Плохой вариант, потому что отвлекается бэкендер, который мог бы уже фичу начать делать. И всё равно нужно ждать деплой.

2. Настроить фронтендеру что-то проксирующее, вроде Charles, научить подменять конкретные заголовки на уровне сети. Уже лучше, но джуну, который только-только освоил вёрстку и какой-нибудь фреймворк, объяснять, как сниффить трафик, кажется оверинжинирингом. К тому же не на всех корпоративных машинках можно ставить сторонние прокси.

3. Воспользоваться новой фичей Chrome Dev Tools! (как будто в телемагазине вещаю, простите)

В чём суть фичи:
- В открытых Dev Tools во вкладке Network > Headers > Response Headers теперь можно редактировать заголовки ответа сервера. Или добавить новые.
- Во вкладке Sources > Overrides можно найти домен, на котором экспериментируете с заголовками, и отредактировать там файл .headers, внутри которого можно задать переопределения не конкретному ответу, а вообще всем ответам.

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

https://developer.chrome.com/blog/new-in-devtools-113/#network

D&D Tokenizer

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

За выходные собрал приложение для рисования токенов персонажей в настольных играх. По названию можно понять, что фокус сделал на D&D. Мы с друзьями привыкли, что у всех NPC и у наших игровых альтер-эго есть красивые картинки, а рамка — часть этого впечатления. Делал для себя, но почему бы не поделиться со всеми.

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

Исходники: https://github.com/MeFoDy/dnd-tokenizer
Сам проект: https://dnd-tokenizer-41471e.netlify.app/

Одно PWA, чтобы править всеми

Вчера на HolyJS читал доклад про то самое приложение для генерации картинок-токенов, про которое писал выше. Цель доклада в том, чтобы убедить разработчиков, что PWA вполне себе могут заменить нативные приложения в каких-то случаях. Не во всех, это точно, но во многих. На самом деле не так уж и часто нативные приложения нуждаются в каких-то редких низкоуровневых API, при этом под капотом часто у них WebView, из которого уже можно сделать PWA меньшими усилиями.

Самую большую дискуссию вызвал вопрос безопасности PWA: «Можно ли написать что-то банковское и безопасное фронтенд-инструментами?» На мой взгляд, здесь между нативным и PWA разница очень маленькая:

— Да, нативное сложнее ломать, потому что нужна экспертиза. Но если она есть и вся логика по безопасности у вас зашита на клиенте — приложение дырявое. На фронтенде посмотреть логику гораздо проще, но имея под рукой хороший прокси (аналог вкладки Network в Dev Tools) можно расковырять почти любые запросы-ответы.

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

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

— Банковские приложения внезапно начали писать на PWA. А у банков аудиты безопасности обычно очень даже серьёзные.

Дискуссия интересная, на конференциях явно нужен доклад про безопасность в PWA, будет полезно.

Видео доклада пока нет, но слайдами уже могу поделиться: https://mefody.github.io/talks/pwa-2023/