На Секвойе вышла статья про Райана Дала. Текст конечно чистая беллетристика про трудное детство и героические преодоления, но есть любопытные моменты.

Совершенно близкое и понятное мне желание уничтожить ранние работы от стыда за них:

«Этим поступком Дал присоединился к ряду художников и изобретателей, таких как Уилла Кэтер, которая в предисловии к переизданию своего первого романа просила читателей рассматривать книгу как исторический артефакт ранних попыток, а не как отражение ее нынешних художественных достоинств. <...> Дал, не имея возможности кремировать свое цифровое творение, фактически просил всех присутствующих в зале и полмиллиона человек, которые будут смотреть его выступление онлайн, отнести Node к списку его "ранних работ".»

Импульсивность и радикальность поступков в молодости:

«В то время Дал был немного бескомпромиссным. У него была тенденция иногда очень агрессивно удалять некоторые вещи из Node. Одной из таких вещей были Promises. Дал счел их дизайн неэлегантным. "На следующий день было удалено огромное количество кода, - вспоминает Белдер, - и всем пришлось переписывать свои Node.js-программы, потому что теперь все работало по-другому".»

Дал сожалел, что подписал контракт с Joyent и отдал им Node.js, так как тех, в итоге, Нода интересовала только как маркетинговый инструмент и вкладывать большие деньги в развитие, нанимать больше инженеров они были не готовы. Позже это стало причиной выбора Далом иной модели развития для Deno, сейчас он получает венчурное финансирование от Секвойи и развививает свой продукт так, как он видит это сам, являясь полноценным владельцем, а не наёмным работником.

Ну и напоследок, самое важное (и я вижу ближашее будущее так же):

«Самым большим новшеством Deno является движение в сторону граничных вычислений (edge computing), которые Дал рассматривает как следующий большой сдвиг в веб-разработке. "В частности, бессерверные граничные вычисления (serverless at edge), то есть запуск сервера везде и сразу во всех регионах мира", - говорит он, - "вот где я вижу Deno через пять лет". Версия edge computing, которую Deno называет облаком изолятов (речь про V8-изоляты), запускает маленькие кусочки JavaScript в датацентрах по всему миру»


Почитайте, чтиво лёгкое и приятное.

Сегодня полдня спорили JS синхронный или асинхроннный. Так вот, совершенно не важно, как вы его называете, важно другое — понимание, как работает рантайм, в котором ваш JS запущен. Да, сам язык ECMAScript не обладает встроенными асинхронными апишками (ок, мне тут говорят про Атомики. Поговорим когда они будут везде!). Всё, что вы делаете в нём происходит синхронно. Максимум можно отбросить что-то в очередь микротасок — таким образом мы поменяем порядок обработки, но не освободим Event Loop. Цепочка из коллбеков вручную созданных промисов так и останется крутиться в фазе микротасков. Следующая итерация внешнего event loop не наступит. Из коробки мы не можем сказать «Эй VM, вот тебе корутина, выполни её в соседнем треде и верни результат по готовности». Нет у нас ничего для этого. Мы можем очень сильно упороться и написать свой Event Loop с прерываниями внутри JS — вот это мы можем да.

Таймеры, setImmidiate, функции, возвращающие промисы — всё это прилетает к нам из окружения. Именно платформа, где мы запускаем наш JS предоставляет работу с другими тредами и даёт нам EventLoop. В спецификации самого ECMAScript нет никаких таймеров и фечей — всё это внешние апишки. Есть отдельные ребята, попавшие в спеку — например, динамические импорты. Но их тоже крутит внешний рантайм, не сам движок JS.

Как работает код на node.js?

Мы выполняем небольшой синхронный код на старте и заряжаем задачи во внешние API. Например, задачу слушать какой-то порт. К это задаче мы привязываем коллбек. Дальше где-то во внешнем мире другой код, написанный на другом языке (на плюсах, например), в другом треде слушает порты. Между внешним миром и нашим JS-кодом крутится эвент луп. Он проверяет, не сработал ли триггер и вызывает соответствующий коллбек в JS. Коллбек снова синхронно выполняется (и может поставить новые задачи в планировщик). Коллбек это реакция на то, что во внешнем мире что-то произошло. Что случится, если коллбек выполняется слишком долго? Например, мы запустили очень большой цикл? Event loop будет стоять и ждать выполнения этой синхронной операции. Ничего не будет происходить. Никакие внешние запросы не будут обработаны, никакие таймеры не сработают. В нашем Event Loop возникнет лаг.

Для Node.js приложения это значит, что в этот момент конкретно этот экземпляр приложения будет тормозить для всех клиентов. Т.е. если у вас есть один медленный эндпоинт, то обращение к нему остановит обработку для всех остальных эндпоинтов. Из-за одного пользователя будут страдать все остальные. Именно потому долгие синхронные операции в Node.js максимально нежелательны. Если вы пишете консольный скрипт или стартуете приложение — вы можете делать что-то синхронно. Если же делаете обработчик запроса пользователя, то добро пожаловать в асинхронность.

Да, нам нужно превращать синхронные операции в асинхронные. Встроенных средств в языке для этого нет, но есть во внешней среде: таймеры и setImmidiate, например. Мы можем буквально сказать — выполни этот код в следующем цикле. Или, иначе говоря, «вызови коллбек когда внешний таймер сработает через 0ms (т.е. в следующем цикле)». Маленькие кусочки нашего синхронного кода будут вызываться по чуть-чуть и мы дадим Event loop время размотать накопившиеся очереди и вызвать другие коллбеки.

А как померить лаг? Мы же должны следить за ним. Ну, конечно, мы можем взять встроееный метод perf_hooks.monitorEventLoopDelay . Но давайте подумаем, как это можно сделать на коленке? Очень просто! Берём текущий таймстамп в высоком разрешении, вызываем setTimeout(fn, 0) и в его коллбеке снимаем таймстамп и измеряем разницу. Время, через которое сработает коллбек таймера с ожидаемо нулевой задержкой и есть наш EventLoop-лаг.

Итого, мы действительно пишем асинхронный код каждый день. И эту замечательную асинхронность нам даёт рантайм, котором наш JS запущен. Этот рантайм содержит и интерпретатор языка и EventLoop и работу с I/O. Потому Нода это не просто V8, это V8 + libuv. А Deno это V8 + ядро на Rust + Tokio.

С 15 марта откроется очередной набор в ШРИ. Естественно, записался туда читать лекцию по node.js

В этот раз на три страны, приходите. ШРИ штука не идеальная, но интересная и полезная. И бесплатная.

Upd

Вся история со ШРИ кажется мне очень уникальной (поправьте, если это не так). На чистом энтузиазме, бесплатно, одни ребята тратят личное время на обучение других. Учат как умеют, но но учат реальными боевыми знаниями. Другие ребята менторят и проверяют домашние работы. Многие преподаватели и менторы — сами бывшие выпускники (что и доказывает эффективность системы).

И вот этот корабль на невероятностной тяге успешно летит уже много лет.

Попробовал перетащить небольшой проектик с CRA (не я поднимал его на CRA, сами понимаете) на vite. Результат, ну как сказать. Да, vite поднимается быстро, и dev-режим на esbuild хорош. Но продакшен rollup оказался неожиданно капризным, посыпались пачками транзитивные зависимости с кривыми esm (например). Что-то удалось перебить альясами (что совсем не радует, конечно), что-то не удалось поправить никак без правок в самих зависимостях.

С next таких проблем нет.

Попросил ChatGPT нарисовать Мона Лизу на чистом CSS. Результат явно лучше, чем я справился бы сам.

Drawing the Mona Lisa using CSS alone would be quite a challenge as it is a complex piece of art with many intricate details. However, it is possible to create a simplified version using basic shapes and positioning techniques in CSS.

За годы работы я сталкивался со множеством моделей разработки. Таблички в экселе и «сделать вчера», ватерфолы, эджайлы: скрамы, канбаны и все их уродливые сочетания. И вот я думаю, что это всё вообще не имеет значения для эффективной разработки. Важна только команда, понимание общих целей и мотивация каждого отдельного участника процесса.

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

Какие же ощущения у меня по таким процессам?

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

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

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

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

Не стройте процессы ради процессов, отталкивайтесь от реальных потребностей команды и бизнеса.

TIL На маке 80-й порт доступен без sudo 🤯

Неожиданно в последний момент вписался в Субботник, расскажу как у нас устроена Ферма, на которую мы накатываем приложения для E2E.

На волне шуток про устаревание UDP придумался ещё один стариковский вопрос — зачем кто-то в 2023 может использовать CP-1251? Что это, грёбаное легаси и бесполезная фигня?

А ответ в том, что русскоязычные символы в CP-1251 занимают 1 октет (8 бит). А в UTF-8 в два раза больше. То есть, если ваши данные это текст, и данных много, то переход на UTF-8 даст ого-го какие накладные расходы.

Вообще вспомнилось, как в первой половине нулевых я сидел через прокси, перегонявший UTF-8 сайты в KOI-8. Когда платишь за мегабайты, то отношение к обьёмам данных совсем иное.

И не отходя от кассы — почему правильнее говорить октет, а не байт (и так написано в спеках). Потому что байт это не 8 бит. Байт — это минимальная адресуемая область памяти, единица обработки информации. Так уж сложилось, что сейчас чаще всего байт содержит 8 бит. Но это не догма. Были и другие машинки, с другим размером байта.

Потому когда хотят точности в терминах, то используют слово «октет».

План пока такой — в субботу на Субботнике, 6 апреля в Казань читать студентам КФУ (мечта старая постоять за кафедрой), 21 апреля Dump.

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

Летом будет ШРИ, надо направить силы туда.

DHH с товарищами опять чудят. Но я их понимаю и поддерживаю — люблю простые и понятные решения. Как минимум, чем ближе к железу, тем меньше шанс столкнуться с нерешаемой задачей.

https://dev.37signals.com/bringing-our-apps-back-home/

Playwright запили классный ui для дебага тестов. Теперь есть общий центр управления где можно выбрать нужный тест, запустить, перезапусть, включить вотчер, посмотреть тайм-тревел, пройтись пик-локатором и перейдя в VSCode быстро поправить код теста. Очень круто.

Хочется попробовать сразу, как доедет во внутренний npm компании. Кстати, если у вас E2E тесты не на Playwright, то поделитесь в комментах почему так.
https://github.com/microsoft/playwright/releases/tag/v1.32.0

Студенты очень классные. Как и мы 20 лет назад, только умнее (возможностей-то больше). Многие уже работают и мыслят технически на уровне хорошего миддла, если брать по уровню индустрии в стране в целом. Да, нужно набирать софты и продуктовое мышление, но хардовые мозги на месте.

Компании за них, кстати, активно борются, такие сотрудники всем нужны.

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

И вся возня с премиями/опционами/долями — она же жутко отвлекает от работы. Мы на берегу уже договорились, что компания получит мои 40 часов в неделю, а я получу в конце месяца свой бутерброд с икрой, на который мы подписались. «Вы что, премии не хотите?» — это худшие мотивационные слова от проджекта, что я слышал в своей жизни.

Не хочу я премию. Я хочу, чтобы продукт был классным. Чтобы своё время, потраченное на продукт было не жалко. Чтобы была польза и был смысл.

Пришёл в эту индустрию бедным и останусь здесь, даже если снова будет беднота.

Ночной бред

Хотел вам показать интересный пример, что иногда

JSON.parse(JSON.stringify(obj))

работает быстрее, чем

{...obj}

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

test(JSON.parse(JSON.stringify(objToCopy)))

значительно быстрее, чем

test2({...objToCopy})

Почему? кажется, что ответ на поверхности: запускаем Ноду с --allow-natives-syntax и проверяем

const a = {a: 1};
const b = {...a};
%HaveSameMap(a, b); // false

const c = JSON.parse(JSON.stringify(a));
%HaveSameMap(a, c); // true

Дело раскрыто, функция стала мегаморфной, JIT вырубился, можно писать пост.

Но! Попробуем добавить вариант с

test3(structuredClone(objToCopy))

test with JSON.parse: 268 ms.
test with structuredClone: 308 ms.
test with spread: 2802 ms.

Проверяем:

const d = structuredClone(a);
%HaveSameMap(a, d); // false

Таааак

Что же получается. И spread и structuredClone ведут к мегаморфности. Но при этом structuredClone не приводит к деоптимизациям.
Дальше докидываю

Object.assign({}, objToCopy)

и не смотря на мегаморфность

test with Object.assign: 238 ms.

Психую. Запускаю с --trace_deopt и вижу, что спред постоянно вышибает

(kind: deopt-eager, reason: wrong map)

Но почему Object.assign и structuredClone не приводят к деоптимизации? Я не знаю 🤡 и могу только предположить, что срабатывает какая-то дополнительная эвристика, и несмотря на то, что мапы разные, в деоптимизацию JIT здесь не уходит. (потому что надо спать!) А спред под такую эвристику не попадает (или, точнее, попадает через раз, так как чем больше попыток вызова, тем чаще случается деоптимизация).

Так, не пишите тесты глубокой ночью ) Одна загадка с утра раскрылась, но стало ещё веселей. Действительно, для structuredClone и Object.assign я в цикле не выходил из мономорфности, потому что стрелял клонами, они имеют между собой одинаковую мапу

const objToCopy1 = { a: 1, b: 2 };
const objToCopy2 = { a: 1, b: 2 };
const N = 100;

for (let i = 0; i < N; i++) {
    testFunction1(JSON.parse(JSON.stringify(objToCopy1)));
    testFunction1(JSON.parse(JSON.stringify(objToCopy2)));

    testFunction2({...objToCopy1})
    testFunction2({...objToCopy2})

    testFunction3(structuredClone(objToCopy1))
    testFunction3(structuredClone(objToCopy2))
}

Но вот что интересно, при увеличении N testFunction2 падает в деоптимизацию, %HaveSameMap({...objToCopy1}, {...objToCopy2}) вываливается в false.

Можете сами попробовать

const objToCopy1 = { a: 1, b: 2 };
const objToCopy2 = { a: 1, b: 2 };
const N = 13;

 for (let i = 0; i < N; i++) {
    console.log(%HaveSameMap({...objToCopy1}, {...objToCopy2}))
 }

В данном случае у меня на 13-й итерации (зависит от версии v8) мапы уже не равны.

gist чтобы погонять spread https://gist.github.com/melikhov-dev/51f92e84b7aa9456a4cdba0550130df7

Оказывается, Артём про это давно писал, не нужно было мне ночью не спать https://news.1rj.ru/str/artalog/178
C --nolazy-feedback-allocation упало бы сразу в деоптимизацию и было бы не так загадочно.

Встречал две стратегии работы с автотестами:

- повторный прогон, чтобы флапающие тесты прошли (дожатие)

- повторный прогон, чтобы поймать флапающие тесты и покрасить билд в красный

Первый вариант обычно идёт от бизнесовой, а второй от платформенной команды.

Так как я переехал на разработку на удалённой машине (ради чего пришлось отказаться от WebStorm), то оставалась одна боль — как визуально гонять E2E когда что-то ломается. Понятно, что с headless проблем нет, но иногда нужен headfull, чтобы пошагово подебажить.
Ради этого приходится локально держать копию проекта и гонять E2E из неё, но это просто неудобно.

Вчера попробовал сделать X11 форвардинг на MacOS и это вполне рабочая схема. Не супер-быстро, но, в целом, поковырять что-то вполне можно. Ставим XQuartz, прописываем ForwardX11 yes в .ssh/config — готово, ssh -X и мы можем запускать Playwright на удалённой машине и рисовать окошко у себя на макбуке. VSCode так всё это понимает бесшовно, красота.

В недавнем выпуске подкаста мы Алексеем обсуждали интервью Дагласа Крокфорда и историю JSON. На самом деле, там конечно много интересных моментов, которые не удалось затронуть. Попробою пересказать текстом, телега всё стерпит.

Во-первых про название «JavaScript». Вопреки расхожему мнению, что слово «Java» было тут добавлено Netscape, чтобы хайпануть на популярном в тот момент языке, Крокфорд утверждает, что это название было утверждено самой Sun и сделано ради амбиций Sun. В тот момент Netscape и Sun объединились против главного зла тех лет — Microsoft. Каждая компания предлагала своё решение для создания софта, не привязанного к операционной системе. Если Sun топила за виртуальную машину, на которой запускался универсальный бинарник, то Netscape за браузер, как универсальную среду. Не важно на какой вы OS, главное, чтобы на ней был браузер. Объединившись компании развивают чудовище — Java-апплеты. Мощное, но медленное и неприятное для пользователя решение.

В то же время у Netscape был язык Mocha (позже переименованный в LiveScript). И Sun это не нравилось. Зачем два языка в браузере? Зачем глупый LiveScript, когда есть прекрасная Java? Но Netscape видели потенциал скриптовых языков, потенциал программирования на событиях. Рядом уже расцветал HyperCard от Apple, новички, не стеснённые концепцией навязанной сложности неблокируемого асинхронного программирования творили на нём удивительные на тот момент вещи. Более того, великий Myst был написан на HyperCard! (этого факта я не знал, хоть и облизывался на Myst всю вторую половину 90-х). Да, Myst был собран фактически на коленке на домашнем скриптовом языке и вышел изначально только на Mac OS.

И тогда неожиданно нашёлся компромисс. Кто-то в Netscape (возможно Марк Андрессен) предложил переименовать LiveScript в JavaScript и солгать миру, что это такое подмножество Java. И Sun неожиданно согласились.

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

Он страдает страдает, но в какой-то день до него доходит — это не Java 🤡. Это совершенно другой язык и, более того, в нём есть концепции, которых нет в других языках. Прежде всего, в нём есть функции как сущность первого класса и у функций есть лексическое замыкание (что было на тот момент только в Scheme). И функции могут быть анонимными, настоящие лямбды! Более того, язык ещё и мультипарадигменный.

Ну вот тут Крокфорд полюбил JavaScript, оседлал волну хайпа, стал везде выступать, консультировать и написал свою книгу и первый линтер для JS (JSLint).

В следующем посте расскажу про JSON.