Если вы вдруг в Питере, то приходите во вторник (23 июля) в Юнион на дринкап SPB Frontend!

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

В общем, буду завтра там сам, приходите и вы! :*

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

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

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

Дальше мы полезли изучать код на предмет подозрительных вещей:

1. Логи
2. Изменения в конфигурации
3. Ишьюсы в Laravel (основной фреймворк)
4. Миграции

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

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

Открываем миграцию, а там тот самый пресловутый транкейт, который хоть и выглядел подозрительно, но не касался других таблиц. Смотрю в логи и вижу что транкейт выполняется так: TRUNCATE marketing_discounts CASCADE. И тут я как понял. Не знаю как так получилось, но я даже не был в курсе, что у трункейта есть такая опция. CASCADE приводит к тому, что дропаются все связанные таблицы (рекурсивно) независимо от того, есть ли там данные или нет. Сказать что я был в шоке, ничего не сказать. Тут же нашелся issues в ларавеле, где выяснилось несколько интересных деталей. Мы не единственные кто грохнул базу таким образом. Собственно сам issue появился с целью того, чтобы защитить всех остальных, на что разработчики сказали сорян, обратная совместимость. Самое смешное, что подобное поведение реализовано только для драйвера постгреса, у остальных такого нет.

```

When you truncate tables using the laravel illuminate db builder it truncates the table as expected. However, postgresql is different because it changes the DEFAULT behavior of truncate from RESTRICT to CASCADE. This means that you can loose all your data in other "related" tables (something that doesn't happen with the other sql drivers)

```

И ниже смешные комментарии в духе:

```

3 years passed, Laravel users still truncates their entire databases...

We were also a victim of this behavior this morning, fortunately we were on a test database. Very dangerous!

```

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

В итоге мы все поправили и восстановили данные, но открыли в себе новый страх. Давно в моей жизни не было таких приключений)

ишью: https://github.com/laravel/framework/issues/35157

GitHub

Truncating tables in mysql, sqlite, sqlserver abstractions do not cascade, postgres does. This is unexpected and a leaky abstraction…

Laravel Version: 5.8 (or higher) PHP Version: 7.4 Database Driver & Version: postgresql 12 Description: When you truncate tables using the laravel illuminate db builder it truncates the table a...

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…

Кыргызы против 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 и веб разработка это головная боль. Всегда.

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

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

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

Если вперые слышите об этом, то взгляните на пост про React Forget (предыдущее название)

Исходный код вот тут

Temporal

Ну и история! 13 мая 2017 появляется первый коммит Temporal Proposal - нового апи для управления датами, вдохновленный moment и luxon.

Ключевые отличия от Date: продуманная работа с часовыми поясами, иммутабельное апи, работа с интервалами (Duration). Схема ключевых сущностей.

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

Я сам использовал этот полифил в течении года, пока пилил проект на ноде, остался очень доволен! С багами не сталкивался, только сделал ПР с улучшением типов (приятно делать даже небольшой вклад в такие крупные проекты)

Уже в 21 году я считал сам пропосал и полифил к нему самым продуманным и проработанным тулом для работы с датами. И сейчас так считаю, но смущает 200 kB (50 kB gzip), что бы тянуть на фронт. Хотя стоит учитывать, что когда оно появится в браузере вы сможете просто вырезать полифил не меняя сам код, чего не скажешь про остальные либы для дат из NPM.

Но почему это все еще не стандарт?

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

По закону на Гаваях время должно быть одно, но все местные живут по другому, кто прав? Это не придуманная ситуация, а реальная проблема с которой столкнулся разработчик у нас в чате. Предложенное расширение стандарта позволяет указать не только часовой пояс, но и конкретный “календарь”, который может иметь свою специфику.

23 октября 2023 предложение апрувнули!

Работа над темпорал продолжается, серьезных блокеров, кажется, больше нет. Текущий статус трекатеся тут: https://github.com/tc39/proposal-temporal/issues/2628

Мне сложно сказать, когда предложение станет стандартом и мы увидем его в браузерах, но вот в V8 реализация Temporal занимает уже больше 2.6% бинарника и вы уже можете использовать его в Deno.

Напоследок, очень порекомендую великолепный доклад Пару календарей назад я был совсем другим Алексея Охрименко, для понимания всей проблематики. А вот доклад конкретно про Temporal: How to Outsmart Time Building Futuristic JavaScript Apps Using Temporal

Мне, кстати, кажется это многое говорит о том какой гит "юзер-френдли"...

git rerere

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

Например, если вы работаете в какой-то «гигаветке» (долго делаете большую недробимую фичу), постоянно подливая из других веток изменения и разрешая одни и те же мерж-конфликты, то с включённой в конфиге опцией rerere (reuse recorded resolution) вы можете разрешить конфликт всего один раз, а затем git, если увидит, что в файле с таким-то именем уже была ситуация, что у нас такая-то строчка, а снаружи пришла такая-то строчка, то разработчик решал конфликт вот так. И, собственно, не будет спрашивать ещё раз, а решит, как вы решили в первый раз.

git config \-\-global rerere.enabled true

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

https://git-scm.com/book/en/v2/Git-Tools-Rerere

Vitest: шардирование
Т.к. в коментариях были вопросы что это ваще такое, то покажу и расскажу.
В целом шардирование популярная практика. Идея в том, чтобы разделить один процесс на несколько и таким образом достичь параллельности

Вот так мы запускали витест до:

```

VITEST_MIN_THREADS=12 VITEST_MAX_THREADS=12 yarn vitest --reporter=html --reporter=html --outputFile.html=./vitest-reports/01/index.html

```

А вот так запускаем теперь (команды запускаются параллельно):

```

VITEST_MIN_THREADS=3 VITEST_MAX_THREADS=3 yarn vitest run --shard=1/4 --reporter=html --outputFile.html=./vitest-reports/01/index.html

VITEST_MIN_THREADS=3 VITEST_MAX_THREADS=3 yarn vitest run --shard=2/4 --reporter=html --outputFile.html=./vitest-reports/02/index.html

VITEST_MIN_THREADS=3 VITEST_MAX_THREADS=3 yarn vitest run --shard=3/4 --reporter=html --outputFile.html=./vitest-reports/03/index.html

VITEST_MIN_THREADS=3 VITEST_MAX_THREADS=3 yarn vitest run --shard=4/4 --reporter=html --outputFile.html=./vitest-reports/04/index.html

```

Обратите внимание, что каждый отчёт живёт в отдельной директории и пока что нет способа их склеить.

https://vitest.dev/guide/cli.html#shard