Сейчас, когда А* уже официально банкрот и прошла через делистинг на Nasdaq, хочется немного порефлексировать про свой опыт в этом интересной компании. Я же туда заходил, когда она была ого-го, единорог, гремела на рынке! Но через 4 месяца ушёл, не выдержал, возненавидел.

Первое и самое главное, испытательный срок — это двусторонний процесс. Не только компания смотрит на тебя, но и ты смотришь на компанию. И компания может его не пройти. Это нормально.

Второе — разок в большой громкий стартап точно стоит зайти. Узнаешь, что такое IPO, SPAC, размытие доли, обратный сплит и другие чудесные вещи, которые помогут разобраться в мире акций. Посмотришь, как выглядит хайп-дривен изнутри и какие существуют опасные звоночки.

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

Левая рука выбрала Пайтон, а правая решила на Скале. Левая нога деплоится через Тимсити в Кубер, а правая предпочитает Дженкинс и EC2. Везде одни синьоры, но критерий синьорства определяется тимлидом. В это время обе руки крутят один и тот же вентиль, разными способами и в разные стороны. Потому что не договорились.

Всё это очень весело, пока инвестиции не проели.

* все совпадения с реальными компаниями случайны.

Как же давно я тебя искал

https://github.com/npm/cli/issues/4263

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

Блуждающий ECONNRESET

Достаточно частый кейс в node.js-разработке, когда мы видим в логах блуждающую ошибку ECONNRESET при запросах в другой бэкенд. Начинаем искать, идём на вторую машинку, а там тишина, ошибок в логах нет. Как обычно отвечают — у нас всё хорошо, проблемы на вашей стороне.

Одна из причин это включенный keepalive. Идея keepalive в том, что мы можем переиспользовать коннекшены, не создавать новый коннекшн на каждый запрос. Клиент стучится на сервер, открывает коннекшн, удерживает его и при следующем заходе обращается к уже созданному коннекшену. А что произойдёт, если клиент удерживает коннекшн дольше, чем сервер? Т.е. сервер имеет например keepalive_timeout 4, а клиент создал http.Agent с timeout: 5? Мы и получим тот самый ECONNRESET.

И даже при равных значениях можно достаточно легко войти в состояние гонки:

import http from 'node:http';

const server = http.createServer((req, res) => { res.end('some stuff') });

server.keepAliveTimeout = 5000; //default

server.listen(1337, '127.0.0.1', startSendingRequests);

function startSendingRequests() {
    const keepAliveAgent = new http.Agent({keepAlive: true, timeout: 5000});

    setInterval(() => {
        http.get('http://127.0.0.1:1337', {agent: keepAliveAgent}, (res) => {
            res.on('data', (chunk) => {
                console.log(`BODY: ${chunk}`);
            });
        }).on('error', (e) => {
            console.error(`problem with request: ${e.message}`);
        });
    }, 5000)
}

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

Во-вторых, документация node.js предлагает такой паттерн ретрая:

    .on('error', (err) => {
      // Check if retry is needed
      if (req.reusedSocket && err.code === 'ECONNRESET') {
        retriableRequest();
      }
    });

UPD

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

WASM и Докер

Есть одна штука в андроид смартфонах, которая мне бесспорно нравится — это бесконечная лента интересных ссылок по свайпу влево с главного экрана. Буквально вчера подкинули статейку. Оказывается, в оригинальном Docker Engine (который на containerd), можно красиво запускать упакованные в контейнер wasm-приложения. Из уже поддерживаемых рантаймов: WasmEdge, Spin, Slight и Wasmtime.
Штука эта есть в Docker Engine в бета-режиме достаточно давно. Но я-то на OrbStack ушёл. И там пока из поддержки только такой ишью https://github.com/orbstack/orbstack/issues/585

Так ли оно нужно, я пока честно говоря не понял. Но прикольно смотреть куда идёт WASM.

Готовил на Субботник классный доклад про песочницы на Node.js (vm, vm2, v8 isolates, wasm QuickJS и т.д.) и их проблемы. Но, к сожалению, накладка, не попадаю физически. Зато будут другие классные доклады, а свой расскажу как-нибудь попозже.

Скоро запускается открытый лекторий летних школ. Заглядывайте 10-го, кто хочет послушать как я буду 2 часа нудеть про Node.js. Другие лекции тоже интересные!

Очередной забавный кейс с npm

Есть у нас приложение, которое поднимает стенды с приложеньками, «ферма» называется. Вот просто, качает нужную ветку из git, делает условно npm ci && npm run build && npm run start и поднимает инстанс, на который мы натравливаем E2E. Да-да, мы знаем про докер, но пока не успели.

И вот буквально позавчера ловим странный баг. В одной из веток не устанавливается несколько зависимостей. Просто нет их node_modules. Локально не повторяется. Захожу на ферму, дёргаю npm ci из консоли — всё ок. Зависимости не ставятся:

1) только когда npm ci вызывается из самой фермы через child_process.exec,
2) только на конкретной ветке.

Ооок. Я магию не люблю, потому сажусь разбираться. Посмотрим что там в env. Ого, а там npm_config_legacy_peer_deps: 'true' . П-нятненько почему зависимости не ставятся, они же peerDeps.

Две загадки:

1) Откуда legacy-peer-deps залетает в env,
2) Почему он влияет не всегда.

Что ж, ответ на первую. В папке самой фермы в .npmrc лежит legacy-peer-deps=true. Когда мы её запускаем через npm run start npm читает .npmrc и прокидывает в env всю свою лабуду в npm_config_*. А child_process.exec запускает дочерние процессы с process.env родителя.

Ответ на вторую загадку. npm ci --legacy-peer-deps не разрушал приложение, потому что ставил все зависимости как и было написано в package-lock.json. Но в конкретной ветке случилась коллизия, зависимость поставили и в devDependencies и в просто dependencies. Вот после этого npm ci перестал доверять package-lock.json и пересчитал всё дерево, уже тихо применяя к нему правило --legacy-peer-deps.

Люблю я эту работу.

Бэкстейдж, кстати. В этот раз сильно меньше недоволен результатом, получилось упихнуть в полтора часа больше полезного и гораздо меньше воды. Уже не медь, но до золота ещё пара итераций нужна.

Никита молодец, будь как Никита и его команда!

CodeRun. Большой запуск

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

Сегодня мы выходим из беты! Случилось то, к чему я шёл несколько лет. Очень волнительно 🙂

Теперь у нас есть свой маскот Кодерун, новый брендинг, мультифайловые задачи, подборки, переработанная навигация, профиль участника. И будет ещё больше, бэклог ломится от интересных идей!

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

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

А всей большой команде CodeRun хочу выразить огромную благодарность за то, что помогли реализовать мою старую мечту — сделать классный тренажёр с интересными задачами для тех, кто хочет развиваться и прокачиваться. Люблю вас! 💛

https://coderun.yandex.ru/

Николас Закас (автор ESlint) поделился своими размышлениями про безопасное использование Bun и Deno. Хорошие поинты:

1 Не используйте API, специфичные для Deno или Bun. Это затруднит смену рантайма если что-то пойдёт не так с этими двумя. Придерживайтесь Node.js API, которые уже поддерживаются в Deno и Bun.

2 Используйте префикс 'node:' для внутренних модулей Node.js. И Deno, и Bun поддерживают большую часть внутренних модулей Node.js, но они могут идентифицировать эти модули только при наличии префикса 'node:'. Node.js прекрасно работает при использовании префикса 'node:', поэтому вы можете обеспечить совместимость во всех трех средах выполнения.

3 В Deno используйте пакеты из npm и JSR, а не спецификаторы HTTP-модулей. Одним из первых нововведений в Deno была возможность указывать модули с помощью URL-адресов. Deno по-прежнему остается единственным рантаймом, поддерживающим такой способ загрузки модулей, поэтому лучше всего использовать npm и JSR пакеты, которые можно использовать во всех трех рантаймах.

4 Используйте package.json для указания зависимостей. Deno рекомендует вам использовать deno.json или jsr.json для указания ваших зависимостей, но он также может использовать package.json.

5 Также всегда запускайте на CI проверки совместимости с Node.js. Node.js это отличный запасной вариант, если вы используете Deno или Bun, поскольку не привязан к какой-либо одной компании. Чтобы оставить возможность быстрой смены рантаймов полезно всегда запускать тесты в CI в Node.js даже если вы переходите на Deno или Bun.

Благодаря отличной совместимости Deno и Bun с Node.js API, сейчас проще, чем когда-либо писать единый код для всех трёх сред выполнения. Трюк заключается в том, чтобы нацелиться на Node.js, а затем использовать функции совместимости Deno и Bun. Таким образом, если в любое время произойдет смена рантайма, ваше приложение сможет работать без особых проблем.

For idiots like me. The rate function over a cpu seconds counter reads "How many seconds did the cpu work every second?". 1 second every second on 1 core will be 100%. 3 cores at 50% will be 1.5 seconds every second, etc... The bracket is the averaging window, longer periods will flatten the graph. Tune according to how erratic your cpu usage is.

link

Захотелось книжку «Девос для идиотов».

А вообще где нам нужен rate? Конечно же когда мы отгружаем process.cpuUsage() в какой-нибудь прометей. Нам нужно смотреть не в сами значения, а в прирост между ними. Потому и формула

rate(container_cpu_user_seconds_total[30s])

Typenoscript теперь и в Node.js?

В свежем выпуске мы затронули нашумевший PR. Что случилось то? А случилось такое, что в Node.js подвезли в экспериментальном режиме загрузчик для ts файлов. Работает он очень просто (правда просто). В ноду вшивается SWC в виде скомпиленного для WASM бинаря. TS файлы прогоняются через SWC и из них отстреливаются типы. Всё. Enum и namespace не работают (о счастье). Никакие транспиляции трансформации не производятся. Просто отстреливаются типы.

Есть ли проблемы? Конечно есть. Например, нужно писать расширение файлов в импортах. Потому что импорт так работает бай дизайн.

Почему это круто и важно? Потому что транспиляция раздражает. Потому что хочется всё иметь из коробки и без настроект. Накидать ts-файлик и запустить.

В общем, неожиданно и очень приятно.

UPD
Почитайте роадмап обязательно (спасибо @kravetsone, что напомнил)

Простой лайфхак как сделать звук на созвоне значительно лучше (причём с обеих сторон), если у вас под рукой только bt-наушники.

Выберите источником звука микрофон ноута и не насилуйте пропускную способность bt-канала.

А вот и продолжение истории поддержки TypeScript в Node.js подоспело. Был добавлен флаг --experimental-transform-types, который добавляет возможность запускать файлы с TypeScript-only (требующем трансформации) синтаксисом (Enum, namespace, module с поддержкой source-map). Однако Node.js всё ещё не читает ваш tsconfig.json.

Из интересного: чтобы импортировать (import, require) файл, вам необходимо будет указать расширение .ts, которое включается в TS-конфиге опцией allowImportingTsExtensions. А ещё появилась целая команда для поддержки TypeScript в Node.js.

Кроме того, импорты типов должны быть помечены как type импорты, как при включенном verbatimModuleSyntax в TS-конфиге, иначе вы получите ошибку в рантайме.

import type { Type1, Type2 } from './module.ts';
import { fn, type FnParams } from './fn.ts';

Также предлагается добавить в feature флаги информацию о возможности импортировать файлы с типами или TypeScript-only синтаксисом.

process.features.typenoscript
//               ^? "strip" | "transform"

Всего 4 дня назад в eslint появилась поддержка `.ts` конфигов благодаря jiti, поэтому нововведения в Node.js по импорту .ts файлов облегчат жизнь всему нашему сообществу.

Очень советую к прочтению этот README и ROADMAP, а ещё спасибо @melikhov_dev за упоминание!

Pull Request

Полтора часа с Кириллом хоронили ноду на бэкенде.

https://youtu.be/98qu3CqRNb8

https://youtu.be/DH9vEW5_PiY

Осень — это время когда проекты оживают. Запуски, презентации, становится снова интересно в индустрии.

Я побежал, у меня сентябрь горит.

HTTP 301/302 vs 307/308

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

И вот тут появляется вроде бы мелочь (совсем нет) — 307/308 сохраняют оригинальный метод запроса и его body(payload). Ну а 301/302 уходят на новый адрес через GET, теряя всё тело и разрушая все ваши апишки.