Инженеры 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 Emscripten".

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

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

#webassembly #llvm #internals

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

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

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

#telegram #tools

https://t.me/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/

Мартин Турнойж написал небольшую статью про то, почему он до сих пор использует jQuery — "Why I'm still using jQuery in 2019".

В статье основной аргумент такой: зачем изобретать колесо, делая свои хелперы, которые не реализованы в браузере, когда уже есть готовая библиотека с удобным API. Ещё в защиту jQuery приводится факт, что минимальная сборка весит всего 17kb. Ещё приводится пример с Bootstrap, когда разработчики решили выпилить jQuery. Им пришлось заново реализовывать некоторые функции. Мартин пишет про то, что была проделана пустая работа в течение полутора лет. Я с ним не согласен, так как выпиливание библиотеки (насколько мне известно) шла в фоновом режиме, и от сокращения объёма загружаемого трафика выиграли все пользователи Bootstrap.

C некоторыми моментами из статьи я не согласен, но всё-таки она заставляет немного задуматься. С чем я согласен, это то, что методы для работы с DOM API иногда очень нелогичны. Но с этим уже ничего нельзя сделать... Вот так вот и живём.

#jquery #musings

https://arp242.net/jquery.html

Пару дней назад Матиас Байненс из команды v8 твитнул о том, что новые методы массивов flat и flatMap доступны во всех стабильных версиях браузеров и Node.js. Этот твит напомнил мне старую трагедию, которая развернулась из-за проблемы с flatten (предыдущее название `flat`).

Если говорить кратко, то добавление реализации flatten сломало как минимум один популярный сайт в Firefox Nightly. Причиной поломки была библиотека MooTools, которая содержала свою реализацию этого метода. Один из участников комитета TC39 завёл тикет про переименование flatten в smoosh. Это вызвало сильные волнения в js-сообществе — очень много разработчиков негодовало из-за нелогичного названия. Оказалось, что это была внутренняя шутка TC39, которую плохо донесли до сообщества. Как результат Матиас написал пост "#SmooshGate FAQ", в котором постарался объяснить, почему бы это название не прошло в стандарт, даже если бы это была не шутка. Спустя некоторое время, участники комитета TC39 переименовали flatten во flat.

Если интересуетесь историей развития web'а или хотите узнать немного больше о том, как принимаются решения в TC39, обязательно почитайте статью.

#history #tc39

https://developers.google.com/web/updates/2018/03/smooshgate

Эли Штайнбок написал статью "How We Write Full Stack JavaScript Apps" про то, каким принципам следует его команда и какие вспомогательные инструменты использует.

Он пишет про то, что его команда придерживается простоты: лучше скопировать код, чем делать плохую абстракцию. При написании кода на React советует пересмотреть подход с размещением контейнеров и компонентов в разных файлах/директориях. Их разделение зачастую не несёт решения каких-либо проблем. Он советует хранить связанные вещи рядом. Тот же самый подход его команда использует и для серверной части. Они не разносят модели, сервисы и резолверы по разным местам, а хранят их в одном логически выделенном месте. Ещё в статье есть небольшая подборка инструментов, которые они используют для генерации типов и кода.

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

#react #graphq #devexperience

https://medium.com/@eliezer/how-writing-simple-javascript-got-us-6200-github-stars-in-a-single-day-420b17b4cff4

Дайон Алмаэр опубликовал небольшой пост на тему противопоставления фреймворков и Web-компонентов — "The Truth about Web Components and Frameworks".

Дайон пишет про то, что причиной всех споров вокруг фреймворков и Web-компонентов является желание поделить всё на чёрно-белую абстракцию. То есть в данном случае найти наилучший инструмент для написания web-приложений. Но все желания спорящих разбиваются о суровую реальность "серого" мира: не все приложения можно легко разделить на "чёрные" и "белые". Например, использование Web-компонентов может очень сильно облегчить жизнь при переиспользовании кода в разных проектах, но если компоненты не переиспользуется, тогда использование Web-компонентов может быть избыточным. При этом могут существовать разные подходы к переиспользованию кода, и это нормально.  Если компания покупает другую компанию, возникает проблема интеграции разных приложений, которые могут написаны на разных фреймворках и т.п.

Недавно я где-то увидел шутку про Теорию Великого Объединения JavaScript-фреймворков. В общем, неизвестно, сколько ещё пройдёт времени, когда кто-то придумает инструмент, который решит все проблемы с web-приложениями.

#musings #webcomponents #jsframeworks

https://blog.almaer.com/the-truth-about-web-components-and-frameworks/