Посмотрел доклад Джефа Ши из Netflix про то, как развивалась их часть React-приложения, отвечающая за регистрацию нового пользователя — "Redux For Transactional Apps".

Из доклада мне запомнилось то, как они боролись с разобщённостью флоу процесса регистрации на разных платформах: Web, Mobile, TV. На каждой платформе транзакции описывались в самом приложении (в докладе под транзакцией подразумевается пошаговое изменение состояния приложения). Логика транзакций в итоге была перемещена в API, что позволило решить проблему.

Ещё в докладе Джеф рассказал про то, какой профит они получили при использовании Redux. Благодаря тому, что view отделено от стейта, они могут использовать одну и ту же логику изменения состояния на разных платформах, просто подменяя компоненты, отвечающие за представление.

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

#react #statemanagement #talk

https://youtu.be/V8oTJ8OZ5S0?t=1134

Попалась на глаза очень прикольная статья Сид Балы про объяснение принципа работы кодека H.264 — "H.264 is Magic". Перевод статьи на русский язык есть на хабре.

H.264 используется при передачи видеопотока, в формате Blu-ray, в телефонах и т.п. При кодировании фрейма производится сжатие с потерями с использованием частотного пространства. Потом производится цветовая субдискертизация, которая обрабатывает закодированные цвета таким образом, чтобы изображение использовало меньшее количество цветов.

После обработки фреймов наступает этап кодирования компенсации движения, когда выделяется базовый фрейм I-frame и последующие фреймы, которые кодируют смещение блоков 16x16 пикселей базового фрейма. Это позволяет эффективно сжимать движущиеся изображения на статичном фоне. После кодирования компенсации движения применяется энтропийное кодирование.

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

#algorithm #video

https://sidbala.com/h-264-is-magic/

Пару месяцев в закладках лежала статья Дага Силларса про объяснение того, почему инлайн изображений в CSS с помощью Base64 является анти-паттерном — "Performance Anti-Patterns: Base64 Encoding".

Добавление закодированных в base64 изображений блокирует critical rendering path. Если изображение очень большое, то это повлияет на размер CSS. После загрузки большой CSS-файл должен будет распариться. Комбинация этих двух факторов увеличивает задержку перед отображением документа. Также может возникнуть такая ситуация когда один и тот же файл может быть заинлайнен несколько раз. Даг нашёл пример, в котором одно и тоже фоновое изображение было заинлайнено 115 раз. Ещё в статье был пример большого CSS, в который было заинлайнено 6 разных шрифтов.

Совет в статье простой — использовать инлайн изображений с умом. Также не стоит инлайнить шрифты. И по возможности надо переходить на HTTP/2.

P.S. Завтра буду рассказывать обновлённый доклад про кодмоды на FrontendConf в Москве. Если среди вас кто-нибудь там будет, подходите сказать привет, буду рад вашему фидбеку.

#performance #base64 #css

https://calendar.perfplanet.com/2018/performance-anti-patterns-base64-encoding/

Прочитал серию из двух хороших статей "Disguise-Driven Testing: Jest Mocks in Depth" Джо Моргана про использование моков в Jest.

Jest — это фреймворк для тестирования, разработанный Facebook, который развивался в самом начале как форк Jasmine. В первой части рассказывается про основы использования моков, зачем они нужны и как их использовать. Очень подробно разбирается пример их использования для подмены результатов вызова Rest API сервиса. Первая часть написана очень доступно, поэтому особенно рекомендую почитать её новичкам и тем, у кого небольшой опыт работы с инструментами для тестирования.

Во второй части статьи рассматриваются, на мой взгляд, более интересные примеры. Пример мока генератора уникального id, с возможностью его тонкой настройки. И пример мока библиотеки, которая работает с DOM API. В последнем примере тестируется React-компонент, использующий хуки. Для того чтобы useEffects заработал корректно, использовался небольшой трюк с задержкой с помощью async/await. Вторую часть статьи рекомендую тем, у кого уже есть опыт использования Jest. Скорее всего из неё вы узнаете что-нибудь новое.

#jest #mocks #testing

https://ponyfoo.com/articles/disguise-driven-testing-jest-mocks-in-depth
https://ponyfoo.com/articles/disguise-driven-testing-jest-mocks-in-depth-part-2

Вчера увидел ссылку на статью Марка Миллера (участник TC39) "The Tragedy of the Common Lisp: Why Large Languages Explode".

Несмотря на название статьи речь в ней идёт про JavaScript. Марк работает над стандартизацией языка с 2007 года. Он очень заботится о том, чтобы язык оставался минимальным и элегантным. В статье он объясняет, почему избирательно подходит к выбору того, что будет добавлено в ECMAScript. По его мнению, минимализм языка является тем качеством, который ценят большинство разработчиков. Осознание того, что мы полностью понимаем принципы работы инструмента, ведёт к чувству удовлетворения.

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

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

#js #tc39 #musings

https://medium.com/@erights/the-tragedy-of-the-common-lisp-why-large-languages-explode-4e83096239b9

Инженеры eBay неделю назад написали пост про то, как они используют WebAssembly у себя в проекте — "WebAssembly at eBay: A Real-World Use Case". На хабре есть перевод.

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

Сначала для чтения штрих-кодов они использовали JavaScript библиотеку BarcodeReader. Но она работала хорошо только в 20 процентах случаев. Потом они воспользовались скомпилированной в WebAssembly C++ библиотекой, которую они используют в нативных приложениях. И опять возникла проблема — библиотека даёт отличный результат только на сфокусированном изображении. Так как есть ограничения Web-платформы связанные с камерой, они не смогли добиться хорошего результата. Потом они попробовали другую Open Source C++ библиотеку, там тоже было не очень всё ок, но она работала в тех случаях, когда не работала предыдущая библиотека. Поэтому у них появилась идея распознавать штрих-код, используя сразу три разных подхода одновременно: с помощью двух скомпилированных в WebAssembly библиотек и с помощью JavaScript-библиотеки.

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

#webassembly #usecase

https://www.ebayinc.com/stories/blogs/tech/webassembly-at-ebay-a-real-world-use-case/

Давайте вернёмся к теме отладки приложений. Нашёл в дебрях интернета статью 2014-го года "The Debugging Toolbox".

В статье Бэн МакКормик пишет про свою стратегию решения проблем в коде. В этом ему помогает выстроенный с годами процесс, который можно поделить на несколько шагов:

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

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

#debug #programming

https://benmccormick.org/2014/08/19/the-debugging-toolbox

Ссылку на вчерашнюю статью я нашёл у Марка Эриксона в статье "Blogged Answers: Debugging Tips".

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

В статье Марк ещё рассказывает про три случая из его реальной работы, которые потребовали долгого дебага. В первой истории проблема заключалась в неправильном регистре файла, во второй и третьей — в проблемном коде, который забивал главный поток Twisted, из-за чего зависала вся система.

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

#debug #programming

https://blog.isquaredsoftware.com/2019/01/blogged-answers-debugging-tips/

Аксель Раушмайер у себя в блоге два дня назад опубликовал статью про то, как работают декларации в JavaScript — "Unpacking hoisting".

Аксель предлагает выделять следующие аспекты любых объявлений: область видимости (где к объявленной сущности можно обращаться) и активация (это черта динамична, она определяет, в какой момент исполнения кода можно обратиться к сущности).

Традиционные функции и var'ы всплывают и работа с ними не вызывает особых проблем. Особенности есть при работе с const, let и class. Если обратиться к сущности в объявлении функции, то всё будет ок, но если попытаться выполнить эту функцию, когда сущность ещё не объявлена, то возникнет исключение ReferenceError. Промежуток времени между входом в область видимости сущности и исполнением инструкции с её объявлением называется Temporal Dead Zone (TDZ). Если в это время обратиться к объявляемым переменной/классу/функции, то возникнет исключение. Именно поэтому первый вызов функции из примера ниже выкинет исключение, а второй выполнится без ошибок:

function a() {
  return b;
}

a(); // throws ReferenceError
const b = 1;
a(); // 1

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

#js #es2015

http://2ality.com/2019/05/unpacking-hoisting.html

Вей Гао опубликовала статью про то, как она добавила поддержку тёмной темы у себя в блоге — "Night Mode with Mix Blend Mode: Difference".

При подготовке своего доклада "This World Mixed and Blended" к Вей пришла идея сделать тёмную тему с помощью CSS-свойства mix-blend-mode: difference. Difference — режим смешивания, который доступен почти во всех современных браузерах кроме IE11. Этот режим можно выразить формулой: difference(A, B ) = |A - B|. То есть абсолютное значение разницы двух цветов.

Для реализации тёмной темы Вей сделала дополнительный div, который перекрывает контент. У этого элемента установлены background: white и mix-blend-mode: difference;. Благодаря этому светлый фон становится тёмным, а тёмный текст — светлым. Для исключения изображений из режима смешивания используется свойство isolation: isolate.

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

#css #colors

https://dev.wgao19.cc/2019-05-04__sun-moon-blending-mode/

Прочитал интересную статью Алексея Круглова "Continuous integration в Яндексе".

В статье рассказывается о том, как происходит работа над проектами в Яндексе. Есть единый монорепозиторий. В нём содержится очень много кода (25Гб), над которым работают более 2000 разработчиков. Использование монорепозитория позволяет снизить издержки на систему CI/CD, предотвращает вероятность появления библиотек с похожей функциональностью (так как всё на виду) и снижает порог для внесения исправлений в смежные проекты (используется общий стек для работы с кодом).

На каждый коммит запускается прогон тестов. Запускаются только те тесты, которые необходимы. Чтобы обнаружить нестабильно работающие тесты, они прогоняются два раза. Если какие-то тесты начинают "моргать", то владельцы этих тестов начинают получать уведомления с проблемой. Также используются diff-тесты, которые могут однозначно определить проблемный коммит, который вызвал поломку тестов.

В общем, советую почитать, если хотите узнать больше подробностей про причины переноса всего кода Яндекса в единый репозиторий и про особенности прогона тестов во внутренней CI-системе.

#ci #testing #yandex

https://habr.com/ru/company/yandex/blog/428972/

Эдди Османи опубликовал в марте статью про работу с большими списками в React — "Rendering large lists with react-window".

Рендеринг десятков и сотен тысяч элементов в списке приводит к лагам в интерфейсе. Для решения этой проблемы используются виртуализированные списки, в которых рендерится не весь контент сразу, а только та его часть, которая видна в данный момент плюс некоторое смещение выше и ниже. Самая известная библиотека для создания таких списков react-virtualized Брайана Воуна (Brian Vaughn). Но существует более компактный аналог от того же автора — react-window. Про него и рассказывает в статье Эдди.

React-window — очень компактная и быстрая библиотека. В статье есть примеры того, как сделать с помощью неё виртуальный список и таблицу на гридах. У react-window есть несколько ограничений в отличие от react-virtualized, но для большинства случаев она подходит хорошо.

#performance #react #library

https://addyosmani.com/blog/react-window/

Пару месяцев назад в канале был обзор статьи "Код ревью" Дмитрия Мананникова. Тогда я написал, что к ней добавить особо нечего. Но недавно нашёл пост бывшего инженера Facebook — "On Code Reviews", который отлично дополняет предыдущую статью.

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

Если вы работаете в команде с ревью кода (и даже если нет), очень рекомендую прочитать статью.

#musings #codereview #programming

https://medium.com/@schrockn/on-code-reviews-b1c7c94d868c

Дас Сурма недавно написал ещё один пост про работу с WebAssembly — "Compiling C to WebAssembly without Emnoscripten".

В этой статье он показывает как работать с WebAssembly без Emnoscripten. Есть пример того, как скомпилировать простой C-код в wasm с помощью llvm. Немного разбирается архитектура llvm (бэкенд/фронтенд-компиляторы). Показывается, как работать с динамической памятью, на примере суммирования массива целых чисел. Для выделения памяти в Emnoscripten используется malloc, но так как в статье рассказывается про более низкий уровень, там используется простой самописный bump-аллокатор памяти.

Статья довольно техническая и очень подробная. Если интересуетесь темой WebAssembly, рекомендую почитать.

#webassembly #llvm #internals

https://dassur.ma/things/c-to-webassembly/

Хочу порекомендовать хороший небольшой телеграм-канал Олега Ковалёва, в котором он собирает cheat-sheets для самых разных технологий. У него можно найти подборки по алгоритмам, машинному обчению, базам данных, go, rust, инструментам разработки, гиту и т.п. Активно собирает подборки от подписчиков. В общем, рекомендую.

P.S. Это не реклама, Олег даже не в курсе, что я решил немного попиарить его канал.

#telegram #tools

https://news.1rj.ru/str/techchsh

Макс Бок написал статью "The CSS Mindset" про свой опыт изучения CSS.

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

Также Макс в статье делится и другими инсайтами, которые помогли ему с изучением CSS. Статья хорошая. Советую почитать.

#css #musings

https://mxb.dev/blog/the-css-mindset/

Посмотрел выпуск видео-подкаста HTTP 203, в котором Джек Арчибальд и Сурма Дас рассказывают про особенности цикла for в JavaScript "JavaScript for-loops are… complicated".

Обычные циклы for (с var в инициализаторе) работают следующим образом: инициализируется счётчик, проверяется условие выхода, выполняется тело цикла, производится инкремент счётчика, проверяется условие, выполняется тело цикла и т.д. Если в инициализаторе используется let, то логика работы цикла немного меняется. Это объясняется тем, что переменная счётчика должна копироваться в создаваемую лексическую область тела цикла. Такое поведение закреплено в стандарте языка. C let, код ниже выведет цифры 0, 1, в отличие от цикла с var, который бы вывел цифры 2, 2.

for (let i = 0; i < 2; i++) {
  setTimeout(() => console.log(i));
}

В итоге инкремент счётчика в случае с let происходит перед выполнением тела цикла, но не для первой (!) итерации. Эту особенность можно использовать для каких-нибудь странных вещей, но Джек и Сурма не рекомендуют так делать. Они подытожили подкаст советом использовать итераторы и инструкцию for...of вместо обычного цикла for, когда это имеет смысл. И я тоже считаю, что это хороший подход.

#js #quirks

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

Недавно в Firefox Nightly появилась поддержка subgrid. Рейчел Эндрю в статье "CSS Grid Level 2 – subgrid is coming to Firefox" рассказала про причину его появления.

Subgrid — это небольшое расширение гридов, которое добавляет новое ключевое слово subgrid в свойства grid-template-columns и grid-template-rows. Subgrid может быть полезен там, где необходимо наследование свойств полос родительского грида. В статье есть два примера его использования: в наборе элементов, у которых должны быть одинакового размера заголовок, контент и подвал, и в раскладке с неизвестным числом элементов с растягивающимся первым элементом на всю высоту контейнера.

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

#css #grids

https://hacks.mozilla.org/2019/06/css-grid-level-2-subgrid-is-coming-to-firefox/

Гарри Робертс на csswizardy написал статью про оптимизацию загрузки статических ресурсов "Self-Host Your Static Assets".

Он пишет про то, что использование ресурсов сторонних сайтов (например, популярных CDN) оказывает негативное влияние на скорость загрузки сайта в целом. Например, в документации Bootstrap есть ссылки, которые предлагается вставить на страницу, для того чтобы начать использовать CSS-фреймворк. Они содержат обращение к трём разным доменам code.jquery.com, cdnjs.cloudflare.com и stackpath.bootstrapcdn.com. На соединении с высокими задержками, загрузка этих ресурсов на 1.765 секунды медленнее загрузки тех же самых ресурсов с домена, на котором находится основная страница сайта. По поводу аргумента того, что может использоваться кросс-доменное кеширование, Генри приводит контр-аргумент с Safari, в котором кеширование между доменами не работает.

Статья хорошая. В ней есть ещё много информации. Очень рекомендую почитать и задуматься о переносе ресурсов с внешних доменов на свой.

#performance #web #cache

https://csswizardry.com/2019/05/self-host-your-static-assets/

Автор CSS-фреймворка Codyhouse Себастьяно Гирейро опубликовал пост о том, почему они используют CSS-переменные вместо переменных SASS — "Why we prefer CSS Custom Properties to SASS variables".

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

Несмотря на то что в статье рассказывается про использование CSS-переменных в коде фреймворка Codyhouse, эти подходы могут быть использованы и при работе с обычным CSS.

#css #customproperties

https://codyhouse.co/blog/post/css-custom-properties-vs-sass-variables

Брэд Ву написал на CSS Tricks статью про блокирование прокрутки основного контента при открытии модального окна — "Prevent Page Scrolling When a Modal is Open".

Прокрутка контента при открытом модальном окне ведёт к плохому пользовательскому опыту, так как после закрытия окна пользователь может оказаться в другом месте страницы. Бред рассматривает несколько вариантов решения этой проблемы. Пример с overflow-y: hidden очень простой, но не работает с мобильной версией iOS. Для блокирования скролла в iOS в статье описывается другой подход с использованием position: fixed и смещением, которое задаётся с помощью JavaScript.

В комментариях к статье пишут, что overflow: hidden для блокирования прокрутки документа работает в iOS 13. Мне стало интересно — нашёл тикет в трекере WebKit. Действительно, баг починили месяц назад. Остаётся подождать, когда большинство пользователей перейдёт на новую версию iOS, и о хаке с fixed можно будет забыть.

#ios #scrolling #ux

https://css-tricks.com/prevent-page-scrolling-when-a-modal-is-open/