Сегодня Антон Виноградов из Яндекса опубликовал статью на хабре про историю объединения React и БЭМ. Честно говоря, я давно хотел прочитать подобную статью. В ней приводятся хорошие аргументы того, почему потребовалось скрещивать технологии между собой.
Если говорить кратко, React хорош для манипуляций с DOM, но при этом БЭМ позволяет очень точно управлять зависимостями, доставляя только нужный код клиенту. При этом БЭМ и React никогда не воевали между собой и не было цели их противопоставлять друг другу: "Компании не соревнуются в создании лучшего фреймворка на Земле. Если компания начнёт тратить меньше времени на инфраструктурные задачи при той же продуктивности, все от этого только выиграют".
Очень огорчил конец статьи, который по сути оказался пересказом доки архитектуры с гитхаба. Для своих этот раздел может, конечно, и ок, но для подавляющего большинства читателей статьи, я более чем уверен, он был непонятен. Очень надеюсь, что вторая часть статьи, которую обещают опубликовать через некоторое время, будет не менее интересна, а ситуация с заключением была просто недоразумением.
https://habr.com/ru/company/yandex/blog/438598/
#yandex #bem #react
Если говорить кратко, React хорош для манипуляций с DOM, но при этом БЭМ позволяет очень точно управлять зависимостями, доставляя только нужный код клиенту. При этом БЭМ и React никогда не воевали между собой и не было цели их противопоставлять друг другу: "Компании не соревнуются в создании лучшего фреймворка на Земле. Если компания начнёт тратить меньше времени на инфраструктурные задачи при той же продуктивности, все от этого только выиграют".
Очень огорчил конец статьи, который по сути оказался пересказом доки архитектуры с гитхаба. Для своих этот раздел может, конечно, и ок, но для подавляющего большинства читателей статьи, я более чем уверен, он был непонятен. Очень надеюсь, что вторая часть статьи, которую обещают опубликовать через некоторое время, будет не менее интересна, а ситуация с заключением была просто недоразумением.
https://habr.com/ru/company/yandex/blog/438598/
#yandex #bem #react
Хабр
React & БЭМ – официальная коллаборация. Часть историческая
Перед вами история интегрирования БЭМ-методологии в React-вселенную. Материал, который вы прочитаете, построен на опыте разработчиков Яндекса, развивающих самый масштабный и нагруженный сервис в...
В прошлый вторник Владимир Клепов из Яндекс.Почты написал хороший пост про то как они адаптируют письма к тёмной теме – "Как создать тёмную тему и не навредить. Опыт команды Яндекс.Почты".
В статье рассматриваются три подхода:
1. Переопределение стилей. Самый простой и понятный подход, но с большим недостатком – все красивости в письме пропадают.
2. CSS-фильтр с инвертированием цветов. Находчивое решение, но у него очень большие проблемы с производительностью.
3. Преобразование стилей. Этот метод и используется в почте. Он гораздо сложнее в реализации, но результат самый лучший. Его суть заключается в том, что в динамике проверяются все значения цветов в формате HSL. Если яркость (L) выше (для текста) или ниже (для фона) порога, то ничего не меняется, так как письмо и так уже в нужной цветовой палитре. Если это условие неверно, то проводится адаптация цвета (h, s, l) => (h, s, 1 - l).
Ещё в статье рассказывается об адаптации картинок к тёмной теме. Были грабли, поэтому их фича на первой итерации пока выехала без перекрашивания картинок. В будущем планируют применять дополнительную эвристику со спектральным анализом, которая должна избавить от возникших проблем.
#css #colors #hsl #yandex
https://habr.com/ru/company/yandex/blog/446780/
В статье рассматриваются три подхода:
1. Переопределение стилей. Самый простой и понятный подход, но с большим недостатком – все красивости в письме пропадают.
2. CSS-фильтр с инвертированием цветов. Находчивое решение, но у него очень большие проблемы с производительностью.
3. Преобразование стилей. Этот метод и используется в почте. Он гораздо сложнее в реализации, но результат самый лучший. Его суть заключается в том, что в динамике проверяются все значения цветов в формате HSL. Если яркость (L) выше (для текста) или ниже (для фона) порога, то ничего не меняется, так как письмо и так уже в нужной цветовой палитре. Если это условие неверно, то проводится адаптация цвета (h, s, l) => (h, s, 1 - l).
Ещё в статье рассказывается об адаптации картинок к тёмной теме. Были грабли, поэтому их фича на первой итерации пока выехала без перекрашивания картинок. В будущем планируют применять дополнительную эвристику со спектральным анализом, которая должна избавить от возникших проблем.
#css #colors #hsl #yandex
https://habr.com/ru/company/yandex/blog/446780/
Хабр
Как создать тёмную тему и не навредить. Опыт команды Яндекс.Почты
Меня зовут Владимир, я занимаюсь мобильным фронтендом в Яндекс.Почте. В нашем приложении уже была тёмная тема, но недожатая: мы умели перекрашивать интерфейс и...
Прочитал интересную статью Алексея Круглова "Continuous integration в Яндексе".
В статье рассказывается о том, как происходит работа над проектами в Яндексе. Есть единый монорепозиторий. В нём содержится очень много кода (25Гб), над которым работают более 2000 разработчиков. Использование монорепозитория позволяет снизить издержки на систему CI/CD, предотвращает вероятность появления библиотек с похожей функциональностью (так как всё на виду) и снижает порог для внесения исправлений в смежные проекты (используется общий стек для работы с кодом).
На каждый коммит запускается прогон тестов. Запускаются только те тесты, которые необходимы. Чтобы обнаружить нестабильно работающие тесты, они прогоняются два раза. Если какие-то тесты начинают "моргать", то владельцы этих тестов начинают получать уведомления с проблемой. Также используются diff-тесты, которые могут однозначно определить проблемный коммит, который вызвал поломку тестов.
В общем, советую почитать, если хотите узнать больше подробностей про причины переноса всего кода Яндекса в единый репозиторий и про особенности прогона тестов во внутренней CI-системе.
#ci #testing #yandex
https://habr.com/ru/company/yandex/blog/428972/
В статье рассказывается о том, как происходит работа над проектами в Яндексе. Есть единый монорепозиторий. В нём содержится очень много кода (25Гб), над которым работают более 2000 разработчиков. Использование монорепозитория позволяет снизить издержки на систему CI/CD, предотвращает вероятность появления библиотек с похожей функциональностью (так как всё на виду) и снижает порог для внесения исправлений в смежные проекты (используется общий стек для работы с кодом).
На каждый коммит запускается прогон тестов. Запускаются только те тесты, которые необходимы. Чтобы обнаружить нестабильно работающие тесты, они прогоняются два раза. Если какие-то тесты начинают "моргать", то владельцы этих тестов начинают получать уведомления с проблемой. Также используются diff-тесты, которые могут однозначно определить проблемный коммит, который вызвал поломку тестов.
В общем, советую почитать, если хотите узнать больше подробностей про причины переноса всего кода Яндекса в единый репозиторий и про особенности прогона тестов во внутренней CI-системе.
#ci #testing #yandex
https://habr.com/ru/company/yandex/blog/428972/
Хабр
Continuous integration в Яндексе
Поддержка огромной кодовой базы с одновременным обеспечением высокой производительности большого числа разработчиков — это серьезный вызов. В течение последних 5 лет в Яндексе идет разработка особой...
Хочу продолжить тему локальной работы с файлами из браузера. Мой коллега — Паша Смирнов — выступал на JS Party NSK и Я.Субботнике с докладом "Приключения в отдельном потоке". В докладе он рассказал про то, как сохранить отзывчивость приложения при работе с большими файлами в браузере.
Паша делал UI для поиска по картинке в мобильной версии Яндекс.Маркета. Перед загрузкой изображения на сервер, надо было сжать изображение в браузере. Для сжатия был использован Canvas. Но во время сжатия изображения были заметны лаги в интерфейсе, поэтому он решил вынести обработку в воркер (Worker API), чтобы не блокировать основной поток браузера. Так как в воркере DOM API, а следовательно и Canvas, не доступны, было использовано решение с OffscreenCanvas (это тот же самый Canvas, но для работы из воркеров). Но с OffscreenCanvas тоже есть проблема: на данный момент он поддерживается только в тех браузерах, которые построены на базе Chromium. Было принято решение использовать прогрессивное улучшение:
Идеального решения добиться не получилось, но тем не менее у всех пользователей, которые используют Chrome, изменение размера изображения не вызывает лагов в интерфейсе.
Доклад хороший, рекомендую посмотреть или почитать расшифровку доклада на хабре, если интересует тема работы с Worker API в браузере.
#js #filereader #worker #yandex
https://habr.com/ru/company/yandex/blog/453626/
Паша делал UI для поиска по картинке в мобильной версии Яндекс.Маркета. Перед загрузкой изображения на сервер, надо было сжать изображение в браузере. Для сжатия был использован Canvas. Но во время сжатия изображения были заметны лаги в интерфейсе, поэтому он решил вынести обработку в воркер (Worker API), чтобы не блокировать основной поток браузера. Так как в воркере DOM API, а следовательно и Canvas, не доступны, было использовано решение с OffscreenCanvas (это тот же самый Canvas, но для работы из воркеров). Но с OffscreenCanvas тоже есть проблема: на данный момент он поддерживается только в тех браузерах, которые построены на базе Chromium. Было принято решение использовать прогрессивное улучшение:
if (window.OffscreenCanvas) {
// используем решение с OffscreenCanvas и воркером
} else {
// старый вариант с Canvas
}Идеального решения добиться не получилось, но тем не менее у всех пользователей, которые используют Chrome, изменение размера изображения не вызывает лагов в интерфейсе.
Доклад хороший, рекомендую посмотреть или почитать расшифровку доклада на хабре, если интересует тема работы с Worker API в браузере.
#js #filereader #worker #yandex
https://habr.com/ru/company/yandex/blog/453626/
Мой коллега — Александр Воронянский — сегодня на хабре опубликовал статью про то, как наша команда Яндекс.Маркета доставляет фичи до пользователей — "От идеи до релиза. Детальный опыт фронтенда Маркета".
У нас работает более 40 фронтенд-разработчиков. В нашей ответственности находятся клиентская часть и Node.js BFF (Backend For Frontend). Мы работаем в контурах-командах, состоящих из разных специалистов: фронтендеры, бэкендеры, дизайнеры и продакт менеджеры. Любой человек из команды может предложить свою идею для улучшения сервиса, которая проходит оценку по системе GIST. Если идея хорошая, то команда начинает над ней работать. После того как написан код, пройдено ревью, тесты и другие проверки, фича попадает в релиз. Релизят у нас ребята из QA. Во время релиза проходит большое количество проверок: E2E-тесты, нагрузочные тесты, скриншот-тесты и т.п. Если всё ок, релиз попадает в престейбл (стейджинг). Там тоже проводятся проверки. После этого этапа свежий код релиза раскатывается по датацентрам.
В общем, в статье очень подробно рассказывается про наши рабочие процессы. Рекомендую почитать.
#ci #process #yandex
https://habr.com/ru/company/yandex/blog/459960/
У нас работает более 40 фронтенд-разработчиков. В нашей ответственности находятся клиентская часть и Node.js BFF (Backend For Frontend). Мы работаем в контурах-командах, состоящих из разных специалистов: фронтендеры, бэкендеры, дизайнеры и продакт менеджеры. Любой человек из команды может предложить свою идею для улучшения сервиса, которая проходит оценку по системе GIST. Если идея хорошая, то команда начинает над ней работать. После того как написан код, пройдено ревью, тесты и другие проверки, фича попадает в релиз. Релизят у нас ребята из QA. Во время релиза проходит большое количество проверок: E2E-тесты, нагрузочные тесты, скриншот-тесты и т.п. Если всё ок, релиз попадает в престейбл (стейджинг). Там тоже проводятся проверки. После этого этапа свежий код релиза раскатывается по датацентрам.
В общем, в статье очень подробно рассказывается про наши рабочие процессы. Рекомендую почитать.
#ci #process #yandex
https://habr.com/ru/company/yandex/blog/459960/
Хабр
От идеи до релиза. Детальный опыт фронтенда Маркета
Всегда хочется придумать что-то новое и нужное в своём сервисе. Особенно, если этот сервис любят пользователи. Но откуда брать идеи? Как выделить приоритетные? И как быстро довести идею до...
Валерий Щавель из Яндекс.Карт рассказал на хабре про опыт использования WebAssembly — "Как мы внедряли WebAssembly в Яндекс.Картах и почему оставили JavaScript".
В Яндекс.Картах объекты перед отрисовкой разбивают на треугольники прямо в браузере. Это ресурсоёмкая задача, которую решили попробовать вынести на уровень WebAssembly. Ребята сделали прототип, который использует wasm, и внедрили его в своё TypeScript-приложение. Скорость обработки тайлов выросла в несколько раз, но появилась просадка из-за накладных расходов на передачу данных из wasm в js. Также вырос размер бандла (в комментариях пишут, что это скорее всего из-за неиспользуемых фич emscripten). В итоге от WebAssembly на данный момент решили отказаться.
Статья интересная. Советую почитать, если интересуетесь темой WebAssembly.
#webassembly #experience #yandex
https://habr.com/ru/company/yandex/blog/475382/
В Яндекс.Картах объекты перед отрисовкой разбивают на треугольники прямо в браузере. Это ресурсоёмкая задача, которую решили попробовать вынести на уровень WebAssembly. Ребята сделали прототип, который использует wasm, и внедрили его в своё TypeScript-приложение. Скорость обработки тайлов выросла в несколько раз, но появилась просадка из-за накладных расходов на передачу данных из wasm в js. Также вырос размер бандла (в комментариях пишут, что это скорее всего из-за неиспользуемых фич emscripten). В итоге от WebAssembly на данный момент решили отказаться.
Статья интересная. Советую почитать, если интересуетесь темой WebAssembly.
#webassembly #experience #yandex
https://habr.com/ru/company/yandex/blog/475382/
Хабр
Как мы внедряли WebAssembly в Яндекс.Картах и почему оставили JavaScript
Меня зовут Валерий Шавель, я из команды разработки векторного движка Яндекс.Карт. Недавно мы внедряли в движок технологию WebAssembly. Ниже я расскажу, почему мы...
Сегодня на хабре появилась статья Александра Воронянского про опыт модернизации фронта Маркета — "Как переписать фронтенд нагруженного проекта и не потерять главного".
Очень интересно было почитать статью, так как я непосредственно участвовал в описанных событиях. Изначально Маркет работал на xml-based технологиях. Серверная часть фронтенда обслуживалась xscript — технологией Яндекса, практически вышедшей из употребления в компании. Представьте, что если бы вы писали node.js приложение, но с помощью xml со вставками на JavaScript. Примерно так выглядела работа с xscript. Сейчас серверный фронт работает на Node.js, на клиенте используется React.
Маркет — это большой проект, который нельзя было заморозить для перевода на новый стек. Перенос осуществлялся постранично. Чтобы не просадить производительность, был настроен сбор клиентских метрик, которые показывали деградации в миграции. В конце статьи есть несколько советов по миграции больших проектов.
В общем, интересная и полезная статья. Почитайте, если у вас планируется что-то подобное.
#yandex #experience #migration
https://habr.com/ru/company/yandex/blog/486146/
Очень интересно было почитать статью, так как я непосредственно участвовал в описанных событиях. Изначально Маркет работал на xml-based технологиях. Серверная часть фронтенда обслуживалась xscript — технологией Яндекса, практически вышедшей из употребления в компании. Представьте, что если бы вы писали node.js приложение, но с помощью xml со вставками на JavaScript. Примерно так выглядела работа с xscript. Сейчас серверный фронт работает на Node.js, на клиенте используется React.
Маркет — это большой проект, который нельзя было заморозить для перевода на новый стек. Перенос осуществлялся постранично. Чтобы не просадить производительность, был настроен сбор клиентских метрик, которые показывали деградации в миграции. В конце статьи есть несколько советов по миграции больших проектов.
В общем, интересная и полезная статья. Почитайте, если у вас планируется что-то подобное.
#yandex #experience #migration
https://habr.com/ru/company/yandex/blog/486146/
Хабр
Как переписать фронтенд нагруженного проекта и не потерять главного
Представим ситуацию. Ваш сервис или сайт был запущен несколько лет назад. Он постоянно развивается, приносит прибыль, его любят пользователи. Кодовая база с каждым годом растёт, инфраструктура...
Тут в интернете поднялся кипеш по поводу Яндекс.Маркета. Иван Вахрушев на хабре опубликовал статью "Тёмная сторона работы в Яндекс.Маркете", в ней он рассказал о своём опыте работы.
Хочу поделиться с вами своим опытом, не претендую на объективность, и это всего лишь личное мнение. Да, сразу стоит сказать, что мне никто ничего не платил за этот пост. Этот пост получился очень большим и не влез в лимиты телеграма. Полную версию статьи можно почитать по ссылке ниже.
Я работал разработчиком интерфейсов в Маркете с 2016 по 2019 год, пилил фронт, занимался BFF на ноде, принимал участие в разработке инфраструктурных штук. В общем было весело. В октябре 2019-го позвали поработать над стартапом — зачесались руки сделать что-то абсолютно новое с нуля. Не мог не воспользоваться таким шансом и в итоге ушёл. Ни на кого в Маркете не держу зла, и, в целом, у меня остались хорошие воспоминания, хотя было по-разному. Затрону самые важные на мой взгляд темы.
В статье Ваня пишет про переработки. Это очень больная тема. С одной стороны барикад работники хотят поддерживать work-life balance, не хотят выгореть и чувствовать себя хорошо, а с другой стороны есть бизнес, которому надо, чтобы фичи пеклись как блинчики. Лично я иногда перерабатывал, мог сидеть за фичей до поздней ночи. Зачем? Потому что был дурак, а не потому что меня заставлял бизнес. Тимлид напоминал идти домой, ну а я продолжал работать. Так продолжалось очень долго, пока не стал замечать за собой странные вещи — постоянная усталость, проблемы с вниманием, импульсивность и т.п. Подумал, что это ни к чему хорошему не приведёт и решил прекратить себя мучить. Последний год работалось очень хорошо, стал более продуктивен, хотя по факту тратил меньше времени, чем раньше. Никто не предъявлял претензий за то, что ухожу домой вовремя.
По поводу дохода. это очень мутная тема, так как есть много факторов, которые надо учитывать. В целом, компенсация была достойная для Новосибирска, хотя, наверное, мог бы зарабатывать больше. Рефликсируя на эту тему, сделал вывод, что надо было просто уметь себя продавать, когда устраивался. Но не жалуюсь — за моё время работы меня несколько раз повышали. Вывод — развивайте soft skills.
Качество кода. По Кенту Беку в коде фронта Маркета в целом ок. Нет дублирования, код тестируется, используется минимальное количество необходимых сущностей. С интентом правда была иногда проблема и приходилось чесать репу, разбираясь в кишках какой-нибудь инфраструктурной либы. В целом, код Маркета был предсказуем и довольно приятен в работе.
Всё ли было идеально? Нет. Всё ли было ужасно? Абсолютно нет. Как и у любой другой компании у Яндекс.Маркета есть и преимущества, и недостатки. Имхо, в этом нет ничего удивительного. Жаль, что не у всех людей не такой опыт как у меня. Но (по моим наблюдениям изнутри) Маркет и Яндекс в целом берут на заметку негативный опыт и стараются улучшить ситуацию.
P.S. 500-ый пост в канале (это не специально).
#musings #yandex
https://defront.ru/posts/2020/06-june/09-my-experience-at-yandex-market/
Хочу поделиться с вами своим опытом, не претендую на объективность, и это всего лишь личное мнение. Да, сразу стоит сказать, что мне никто ничего не платил за этот пост. Этот пост получился очень большим и не влез в лимиты телеграма. Полную версию статьи можно почитать по ссылке ниже.
Я работал разработчиком интерфейсов в Маркете с 2016 по 2019 год, пилил фронт, занимался BFF на ноде, принимал участие в разработке инфраструктурных штук. В общем было весело. В октябре 2019-го позвали поработать над стартапом — зачесались руки сделать что-то абсолютно новое с нуля. Не мог не воспользоваться таким шансом и в итоге ушёл. Ни на кого в Маркете не держу зла, и, в целом, у меня остались хорошие воспоминания, хотя было по-разному. Затрону самые важные на мой взгляд темы.
В статье Ваня пишет про переработки. Это очень больная тема. С одной стороны барикад работники хотят поддерживать work-life balance, не хотят выгореть и чувствовать себя хорошо, а с другой стороны есть бизнес, которому надо, чтобы фичи пеклись как блинчики. Лично я иногда перерабатывал, мог сидеть за фичей до поздней ночи. Зачем? Потому что был дурак, а не потому что меня заставлял бизнес. Тимлид напоминал идти домой, ну а я продолжал работать. Так продолжалось очень долго, пока не стал замечать за собой странные вещи — постоянная усталость, проблемы с вниманием, импульсивность и т.п. Подумал, что это ни к чему хорошему не приведёт и решил прекратить себя мучить. Последний год работалось очень хорошо, стал более продуктивен, хотя по факту тратил меньше времени, чем раньше. Никто не предъявлял претензий за то, что ухожу домой вовремя.
По поводу дохода. это очень мутная тема, так как есть много факторов, которые надо учитывать. В целом, компенсация была достойная для Новосибирска, хотя, наверное, мог бы зарабатывать больше. Рефликсируя на эту тему, сделал вывод, что надо было просто уметь себя продавать, когда устраивался. Но не жалуюсь — за моё время работы меня несколько раз повышали. Вывод — развивайте soft skills.
Качество кода. По Кенту Беку в коде фронта Маркета в целом ок. Нет дублирования, код тестируется, используется минимальное количество необходимых сущностей. С интентом правда была иногда проблема и приходилось чесать репу, разбираясь в кишках какой-нибудь инфраструктурной либы. В целом, код Маркета был предсказуем и довольно приятен в работе.
Всё ли было идеально? Нет. Всё ли было ужасно? Абсолютно нет. Как и у любой другой компании у Яндекс.Маркета есть и преимущества, и недостатки. Имхо, в этом нет ничего удивительного. Жаль, что не у всех людей не такой опыт как у меня. Но (по моим наблюдениям изнутри) Маркет и Яндекс в целом берут на заметку негативный опыт и стараются улучшить ситуацию.
P.S. 500-ый пост в канале (это не специально).
#musings #yandex
https://defront.ru/posts/2020/06-june/09-my-experience-at-yandex-market/
Неделю назад Владимир Гриненко представил Yandex UI — новую библиотеку React-компонентов, которая используется в проектах Яндекса.
Основными требованиями при создании библиотеки были: функциональность, доступность, скорость рендеринга, возможность переопределения компонентов и расширения поведения снаружи, поддержка TypeScript и темизации. Yandex UI под капотом использует bem-react. Поддержка БЭМ-подхода позволяет гибко управлять тем, какой именно код попадает в бандл приложения. Есть поддержка Dependency Injection, с помощью которой можно подменять функциональность компонентов, например, при проведении A/B-тестов или добавлении специфичной логики. Библиотека включает 24 компонента, в будущем планируется её расширение.
Мне лично очень понравилась поддержка DI, но хотелось бы видеть полноценное API на хуках для работы с модификаторами.
#react #yandex #talk
https://www.youtube.com/watch?v=trwdc0JCelA
https://github.com/bem/yandex-ui
Основными требованиями при создании библиотеки были: функциональность, доступность, скорость рендеринга, возможность переопределения компонентов и расширения поведения снаружи, поддержка TypeScript и темизации. Yandex UI под капотом использует bem-react. Поддержка БЭМ-подхода позволяет гибко управлять тем, какой именно код попадает в бандл приложения. Есть поддержка Dependency Injection, с помощью которой можно подменять функциональность компонентов, например, при проведении A/B-тестов или добавлении специфичной логики. Библиотека включает 24 компонента, в будущем планируется её расширение.
Мне лично очень понравилась поддержка DI, но хотелось бы видеть полноценное API на хуках для работы с модификаторами.
#react #yandex #talk
https://www.youtube.com/watch?v=trwdc0JCelA
https://github.com/bem/yandex-ui
YouTube
@yandex ui
Презентация @yandex/ui — open source библиотеки React-компонентов от Яндекса. Компоненты используются внутри и отвечают самым строгим требованиям: темизируемость (дизайн отдельно, управление визуалом через дизайн-токены), скорость рендеринга, доступность…