Валя читает ишью

axobject-query: maximize back compat 3 дня назад Jordan Harband потряс всё JS комьюнити своим пул-реквестом в проект axobject-query с названием «maximize back compat». 210 дизлайков, ни одного лайка, бесконечное количество критики… Давайте сперва про Джордана — это очень известный человек в комьюнити, работал в твиттере, коинбейзе, эирбнб. Участник TC39, контрибьютил в еслинт, бабель, ноду, опубликовал 513 пакетов в npm. Теперь про сам axobject-query — я, честно говоря, не знаком с AXObject (и если ещё более честно, то и знакомиться особо не хочу), какая-то низкоуровневая штука для работы с доступностью в общем. Интересно кто этим пакетом пользуется — eslint-plugin-jsx-a11y (пакет Джордана), svelte, astro. Короче, короче, большие и уважаемые проекты. А теперь давайте про пул-реквест — под названием «maximize back compat» скрывается поддержка ноды v0.4. Знаете когда он вышла? 12 февраля 2011 (!!!) года! Я даже не успел её застать, кажется моя первая версия была 0.8 или 0.9 Поддержка достигается за счёт смены jest на tape, который написал Джордан. А так же замены dequal на deep-equal-json т.к. первый требует ноду старше v6. А кто является автором deep-equal-json сами догадаетесь. deep-equal-json как минимум ругают за то, что он тянет 17 зависимостей, в то время как dequal ни одной. Это критично для svelte, т.к. у них есть REPL и юзеры будут загружать эти пакеты в том числе и в браузере. В ответ на критику Джордан занимает очень оборонителньую позицию. Например, его спрашивают «а как ты стал мэйнтейнером этого пакета? Как мы видим, это твой пул-реквест в этот проект. Понятно, что ты уважаемый человек с большой историей контрибьюшенов, но ответь пожалуйста на этот простой вопрос» или «замотивирован ли ты внедрять свои пакеты т.к. можешь получать отчисления от tidelift». В ответ Джордан либо не отвечает либо делает это очень уклончиво. Интересно, что в описании пул-реквеста указано «It also expands the test matrix so that all supported engines are tested, now and moving forward.», но на деле в CI указано >= 0.8, а в engines 0.4… Кажется уж,если решил быть таким педантичным, то надо идти до конца… В общем, рекомендую почитать комментарии в пул-реквесте. Там правда очень уважаемые люди. А на самого Джордана свалилось много как конструктивной критики, так и булинга. Хоть я и осуждаю такое, но природа этого понятна. Уж очень экстравагантное решение получилось. P.S. once JS drama — always JS drama…

Мой тиммейт Дима (а заодно и автор effector) на днях тоже с веселой детективной историей столкнулся

Кыргызы против Intl.NumberFormat Когда лучшее враг хорошего. Недавно к нам в команду web platform в aviasales пришли из техподдержки со странным багом у пользователя: в Arc браузере сломано отображение символа валюты кыргызских сомов, вместо него выводится непонятный символ. Проще всего конечно было ответить, что браузер не поддерживается, но стоп, разве арк не на хромиуме, чем он такой особенный? Начал разбираться Действительно, в обычном хроме сомы показываются как KGS, а в арке как символ, и символ явно ошибочный. Для отображения валют мы используем стандартный Intl.NumberFormat и в арке он действительно выдаёт другой символ. Начало проясняться. Возможно, арк использует новую версию хромиума и поэтому показал проблемы раньше? И действительно, Chrome Canary получил точно такой же баг. Получается, совсем скоро, валюта сломается у всех, вообще у всех сайтов и пользователей страны, и отсчёт времени уже пошёл 🫠 Куда отправлять баг? У хромиума есть свой баг трекер, но работа с ним оставляет желать лучшего, выглядит он мягко говоря антично. Никогда не заполнял баги для браузера, но видимо этот час настал. В процессе подготовки репорта вспомнил, что вообще говоря, локализациями занимается не хромиум а отдельная библиотека ICU, то есть проблема ещё глубже, чем просто баг браузерного движка. А, казалось бы, невинная проблема Описываю свои приключения коллегам, один замечает, что это первый раз, когда мы нашли баг не в самом лучшем браузере safari а в хроме, теперь счёт багов 4:1 в пользу первого. А действительно, а как себя ведёт в таких условиях сафари? Открываю. Встречаю тот же баг 🫡 Очевидно, проблема на уровне операционной системы. Решил присмотреться к символу внимательнее, это просто мусорный вывод или он имеет какую-то семантику? Символ который выдаётся на macos выглядит так: ⃀, если вы читаете с macos то почти наверняка ничего не увидите (в первом комментарии скриншот как это рендерилось в реальности). В базах данных по юникоду описание: Unicode Character 'SOM SIGN'. Бинго. Это не баг, это настоящий символ валюты, но в стандартных шрифтах macos его нет, на windows всё отображается нормально В итоге получается ситуация: раньше вместо символа валюты выдавалась аббревиатура, библиотека ICU исправила эту проблему чем ухудшила вывод на девайсах apple Это многое говорит о нашем обществе Issue в багтрекере хрома или ICU открывать не стал. Очевидно они всё сделали правильно; парадоксальная ситуация в которой никто толком не виноват. Ну, точнее, можно конечно попинать apple чтобы добавляли символ, но это всё равно что орать на баобаб Оценив диспозицию, решил что надёжнее всего будет просто сделать .replace для проблемного символа на старый вариант. Мимоходом заметил, что в некоторых других условиях у нас на сайте кыргызская валюта отображается нормально. Оказалось, что вместо официального символа используется юникод-комбинация c + нижнее подчеркивание под символом: c̲. Как говорится c̲мекалочка ок. Но чтобы я не сильно радовался, оказалось, что в том самом стандартном шрифте apple этот символ тоже отображается криво, проще заменить обратно на KGS, как это было раньше и всех устраивало Когда я заходил на эту пятничную задачу последнее чего я ожидал это изучения багтрекера браузеров. А вот проблемы с apple наоборот вполне были в рамках! Разумеется это ценно, что у движка chromium есть конкурент который не живёт на пособиях гугла, но нельзя не признать, что девайсы apple и веб разработка это головная боль. Всегда. Пока писался этот пост, «улучшающий» апдейт хрома был раскатан на всех пользователей. Кыргызский интернет оказался уже сломан, сломан для всех

Стажировка в Авиасейлс У нас открывается набор на летнюю стажировку! 2 месяца по 500 баксов, 4-6 часов в день, ремоут, все дела Фронтенд, go, iOS, юристы, редакторы, дизайнеры, маркетинг — в общем есть всё! Аплайтесь через сайт, можете указать что вакансию в канале увидели https://aviasales.ru/about/vacancies

React Compiler доступен для пользователей https://react.dev/learn/react-compiler

Не смотря на то, что профилирование JavaScript является мощным инструментом, мне всегда не хватало возможностей инструментов. Так что последние годы я почти перестал пользоваться этим методом. Для меня это просто не работало: для небольших скриптов – слишком мало деталей, для долго работающих (например, сборка webpack или выполнение unit-тестов) – сплошная каша. Оказывалось, что инструментирование с помощью console.log() работает куда эффективнее, чем ковыряние в CPU профилях. В тоже время, мне казалось это неправильным. 2,5 года назад, очередной раз разбираясь в тормозящей webpack сборке, и делая аналитику что и как работает, представил как это могло бы выглядеть в инструментах. Пришла идея кластеризации функций по модулям, пакетам, категориям. Это казалось очевидным решением, странно, что никто еще не сделал. "Если никто не сделал, наверное это не будет работать" – думал я тогда. Но "не попробуешь не узнаешь", и решил попробовать реализовать – вдруг заработает. Сначала я начал разбираться с тем как устроен формат ".cpuprofile". Было ничего непонятно, и казалось очень сложным. Но на деле вышло, что ничего сложного в этом нет, сложно только разобраться. Сложность в том, что материалов про то как устроен формат и про логику его работы, и вообще профилирование с точки зрения аналитики, обнаружить не удалось. Обычно ограничиваются базовыми туториалами по профилированию. Информацию приходилось собирать по крупицам: по ишуям, по комментариям, по коду v8 и т.д. И еще много экспериментировать. Как бы то ни было, получилось собрать прототип кластеризации. И это на удивление хорошо заработало. Правда с кластеризацией появились новые проблемы: как считать разные агрегации, делать это быстро и под разными углами, и на больших масштабах. Информации по этому поводу было бы странно найти, так как никто кластеризацию толком и не делал. Но тем не менее основа была заложена, так появился проект под названием CPUpro – мое переосмысление того, какими должны быть инструменты анализа CPU профилей. Время от времени я понемногу допиливал CPUpro, продолжал экспериментировать. А некоторое время назад пришло озарение, на фоне размышлении о том, как сделать сравнение профилей "до" и "после" без сопоставления двух флеймчартов глазками. Сравнение профилей пока не реализовано, но многое для этого уже сделано (высокая производительность, низкое потребление памяти), и вообще стало получаться что-то приличное. Теперь я ковыряюсь в CPU профилях каждый день, и все больше коллег делают тоже самое. В общем, инструмент приобрел состояние, когда его не стыдно показать 🙂 Еще много что предстоит сделать, но он полезен уже сейчас, нам уже не раз помог в работе. Особенно если нужно проанализировать профайл на десятки или сотни мегабайт. Release notes (там больше деталей, бенчмарки и скриншоты) Твит анонса (спасибо за лайк, ретвит) CPUpro (GitHub)

cpupro — лучший cpu профайлер Не так давно я искал узкие места в витесте и вебпаке и внезапно наткнулся на cpupro. Когда я увидел, кто автор, то понял что инструмент плохим быть не может в принципе: Рома Дворнов — знак качества! Традиционно, это самый быстрый аналайзер из существующих, способный переваривать огромные (2гб) профайлы. Ну и по функциональности он впереди всех существуюших профайлеров — куча разных вьюшек, сортировки по пакетам/функциям и так далее. В общем, очень рекомендую! https://github.com/lahmatiy/cpupro/releases/tag/v0.5.0

Vitest: invalid JSON syntax found at position -1. Алло, это канал о витесте? Ну а если серьёзно, то пожалуй столкнулся с одним из самых интересных багов в своей жизни. Я уже рассказывал, что витест для нас компромиссный опыт и породил экстравагантные практикие в духе «гоняем 100 пайплайнов и проверяем, что не флакает». В общем, задумал я обновить его немного, открыл пул-реквест, погонял те самые 100 пайплайнов — всё зеленое! Мёрджим! Проходит 2 недели и 60% пайплайнов начинают падать… Разработчики ругаются, тимлид предлагает откатывать, я в замешательстве — работало же! Снова начинаю гонять пайплайны, находим 3 проблемных теста, которые никто не трогал уже полгода. Выключаем — всё снова стабильно и зелено. Начинаю разбираться… Ошибка выглядит так — Error: Failed to parse JSON file, invalid JSON syntax found at position -1. Спасибо, очень информативно! Собираю такой же докер образ как на CI, тыкаю проблемные тест — ничего. Т.к. проблема воспроизводится только на CI, то решаю запатчить vite через yarn patch, добавив название файла в лог. Сработало — проблемный файл мы генерируем на CI и путь до него известен. Проверяю содержимое файла до тестов — всё на месте. Проверяю после тестов — и снова всё на месте. Но в тестах почему-то всё так же ломается. И тут я замечаю, что у падающих шардов есть кое-что общее — падает именно первый тест. Смотрю как это работает внутри vite — обычный fs.readFile и JSON.parse. В голову закрадывается страшная идея — а что если это какя-то проблема с файловой системой и одновременным чтением одного файла из нескольких процессов. Ищу ишью в ноде, но ничего прям конкретного не вижу. Уже начинаю писать скрипт для стресс-теста одновременного чтения, чтобы проверить гипотезу и тут в голову приходит идея — а что если кто-то этот файл всё таки перезаписывает? Проверяю файл через fs.stat сразу после записи и после тестов — даты создания и редактирования отличаются! Смотрю немного в пайплайн и понимаю, что внутри одной из команд мы запускаем генерацию этого файла. Мда! А ларчик просто открывался, как говорится. Убираю лишнюю генерацию и всё сразу же зеленеет. Для меня было откровением, что при записи файл может принимать какое-то промежуточное состояние. Т.е. не before → after, а before → empty → latest. Рефлексируя о дебаге и что могло упростить поиск, пришёл к такому алгоритму: 1. Если ошибка указывает на неочевидное место, то её сразу же надо патчить, чтобы сузить радиус дебага (в очередной раз могу поругать бандлинг зависимостей в vite, кажется в новой версии зависимости ошибка уже содержит путь до файла). 2. В ошибках нужно искать общие признаки (в моём случае что падает только первый тест в каждом из шардов). 3. Проверять самые простые гипотезы в userland коде, а не искать какие-то баги в больших популярных библиотеках (vite и node в нашем случае) Остаётся вопрос: а почему ошибка не сразу всплыла, а через 2 недели? Ответ прост: у нас 4 шарда и не все тесты импортируют проблемный файл. С добавлением/удалением тестов порядок в шардах немного меняется и тесты, которые читают файл, становятся первыми в очереди и попадают в те самые первые 5 секунд, когда мы перезаписываем файл. Такой вот детектив. А как вы провели вечер пятницы?

Ну что, кот вылез из мешка (сорян, вы же хотели, чтобы я русский не забывал?), вышел подкаст Бирмана, в котором я рассказываю про Гит. Вообще идите послушайте, а я тут коротенько наброшу. Я шутил в твиттере, что «люди которые пользуются консольным Гитом, кажется, не слишком хорошо его понимают и это повод копнуть поглубже» что было переделыванием аналогичной фразы про гуевый Гит. Так вот, я считаю, что консольный Гит это конечно крутое кун-фу, но это сложность ради сложности (смотрите, я собрал корабль в бутылке, причем обе руки были завязаны за спиной), но какого-то особого «глубокого» понимания он не дает. Я офигенно знаю Гит (ну, я так думаю) и пользуюсь исключительно гуем, потому что — ну а нафига страдать? Беда всех консольных интерфейсов — что они работают в парадигме запрос-ответ, «ты сначала спроси, а мы потом покажем». Это плохая парадигма, хорошая — вот смотри все что есть, если нужно, уточняй. Вторая беда — они всегда показывают прошлое. То есть я ветку уже удалил, но если на экране есть вывод предыдущей git branch -a, то он не обновится. Вот ты и сидишь и спрашиваешь постоянно: где я? кто я? какой сейчас статус? Закоммитить не в ту ветку — одна из самых частых ошибок, потому что ветка нигде не написана. (мне сейчас скажут, что у них условный oh-my-zsh запрашивает и печатает ветку после каждого нажатия enter, на что я скажу: вы что, ебанутые? ^W^W^W вот мы и начали делать gui колхозными средствами) Ну и в целом многие вещи исходно требуют графического представления (diff-ы, лог), которое консольному интерфейсу приходится как-то колхозить. Для чего, для кого? Зачем вы страдаете, мистер Андерсон? Вторая часть моих претензий связана с ебанутостью конкретно git-ового cli. - Например, команды, которые и не существительные, и не глаголы (`git checkout`/`git branch`). - Команды, которые полностью меняют свой смысл в зависимости от ключа (`git branch`, git branch -l, git branch -d, `git checkout --merge`). - Команды, которые полностью меняют свой смысл от аргумента (`git checkout`). - Неконсистентный словарь (staging, index, cache — это все одно и то же). - Команды, которые очевидно создавались заплаткой поверх других команд. Попробуйте понять логически, что с чем сравнивает команда git diff --cached - Git status, который пишет «You are up to date», даже не сходив в интернет и ничего не проверив! Распределенная система контроля версий боится ходить в сеть! - Просто идиосинкразия удаления файла через git add - То, что стеш автоматически не стешится (правда, это во многих gui тоже так) - Отсутствует анду. А это, между прочим, столп вообще любого человеко-компьютерного взаимодействия. Короче, если ты все это запомнил, то молодец! У тебя большая память, высокий болевой порог и ты любишь хранить бессмыслицу на своем чердаке. Ты наверное и всех американских президентов можешь перечислить по порядку? В общем, you do you, конечно, но меня раздражает, что эта вот пытка считается чем-то вроде badge of honor, чем-то, чем люди прям гордятся. А на деле самый обычный стокгольмский синдром. Конечно, это не отменяет того, что какой-то конкретный GUI для гита тоже может быть плохим! Условный VS Code, в котором одна кнопка sync, которая делает и пуш и пулл и черт знает что еще, да, действительно, с такой каши не сваришь. Но бывают и хорошие ведь! Условный Sublime Merge снимает почти все головняки консоли и при этом не идет против правды и показывает вещи как есть. И это просто хорошо сделанная обертка, даже не переосмысление самой работы с DVCS. Короче, дискурс «нАдО сИдЕтЬ в КоНсОлЕ» вредит и развитию инструментов, и доступности профессии для новичков. Да и вам самим было бы легче, просто кто-то фильмов про хакеров насмотрелся с зелеными буквами. На терминале свет клином не сошелся, алло!

Никита очень чётко сформулировал все мои претензии к гиту А лучший гуй, который я пробовал — Fork