Сегодня презентую доклад — результат двухнедельного копания в облачных провайдерах. Все варианты деплоя node.js-приложения, цены, девопс во все поля. Как обычно выяснил по дороге, что я знаю, что ничего не знаю. Зоопарк тут просто бесконечный вскрывается, хватит на хороший пэйпер или даже маленькую книжку.

Главный вопрос — бесплатной трансляции не будет, два раза ездить на конференции с одним докладом я не люблю, а значит нужно думать, что делать с этим добром дальше. Сесть за статью? Записать видос? Что-то, да надо будет сделать.

TIL FinOps

Financial Operations или Cloud Financial Operations. Ребята постарались вписать нормальную расшифровку, чтобы люди вроде меня не докапывались. Короче говоря, облака оказались такими гибкими в тарификации, что появились отдельные ребята, которые могут сесть с калькулятором и внятно ответить на вопрос — сколько денег мы заплатим вот за это облачное счастье и где можно срезать косты.

Поспорили вчера с Сашей Шушуновым — нужно ли проращивать типы насквозь от базы данных до фронта? Саша говорит, что нужно. Кент Доддс говорит, что нужно. А я за маппинг в DTO. И дядя Боб за DTO (кто бы сомневался). Да, удобно, когда имена полей гарантированно совпадают, но как же часто я вижу, как по системе гуляет модель со всеми её optional полями и реляциями. И на месте использования люди давят опциональность через ! чтобы TS не ругался (а что, я точно знаю, что здесь поле не пустое). Так если поле не пустое, то пусть структура DTO это и описывает. Если подтянули данные через реляцию — пусть DTO это описывает.

За пределами Data Access Layer я не хочу знать о структуре базы данных. Я хочу работать с чистыми данными, я не хочу видеть здесь модель, обвешанную методами. Представление данных на клиенте вообще может не совпадать с представлением в БД (как минимум, мы любим в UI работать с денормальзованными данными). А уж идея средствами ORM менять структуру БД под схемы вводит меня в ступор. Да, DX будет шикарный, но данные — это самое ценное, что у нас есть. И я хочу пересекать границу между данными и представлением максимально аккуратно.

Старый я. И вредный.

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

Вокруг только и разоговоров о tRPC как о «лёгкой» замене GraphQL. Ещё чуть чуть и наконец-то снова начнём писать RPC-вызовы руками, примотав к ним кодогенерацию sdk из OpenAPI в нужный нам язык. И кажется мне, что это и есть устойчивое решение на годы (в общем-то, и раньше с RPC было прекрасно жить, если ты контролируешь фронт и бэк/bff).

Спасибо @artalog за ссылочку

TIL Фишфудинг

Если про догфудинг большая часть моих читателей в курсе (Eating your own dog food, пользуйтесь продуктами, которые вы разрабатываете), то про фишфудинг, думаю, слышали не многие. Сам узнал сегодня, как вы понимаете.

Фишфудинг — термин из глубин Гугла. Fishfooding is using an app or feature really early in its development before it's even really finished. Т.е. стараемся пользоваться своим продуктом как можно раньше, чтобы выявить проблемы до того, как на них наткнутся не то что пользователи, а даже сотрудники компании за пределами вашего отдела.

Интересно, что в Гугле понимают это так: фишфудинг — использовать прототип в команде, догфудинг — использовать прототип во всей компании. Это идёт несколько вразрез с классическим догфудингом, там всё же речь не только про прототипы, а про продукты в целом.

https://www.inc.com/bill-murphy-jr/google-spent-21-years-learning-how-to-release-new-products-heres-1-thing-it-always-does-first.html

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

Пока не встретил хорошего решения этой задачи. Если встречали, то скиньте в комменты.

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

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

Если бы я делал доклад про лигатуры, то поставил бы это фото на заглавную картинку.

Довольная странная история с url.parse() в node.js. Его задепрекейтили в угоду переезду на WHATWG URL API. Но URL API не умеет парсить относительные пути.
В итоге, все либо продолжают сидеть на депрекейченном апи, либо городят самопальные велосипеды, повторяя то, что и так уже давно есть и работает.

https://github.com/whatwg/url/issues/531

Доклад с YaTalks можно глянуть по таймкоду

А вот и нарезанная версия доехала https://youtu.be/77h-_SytDhM

Немного хорошего и тёплого в эти непередаваемо холодные дни. Завтра проводим новогодний субботник по дизайну и разработке интерфейсов. Онлайн, и кто успел — встретимся оффлайн.

https://events.yandex.ru/events/ya-subbotnik-2022-12-10

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

Маргинальные варианты с синхронизацией файликов по SSH оставим в прошлом, современный способ это поднять сервер IDE удалённо, зацепиться на него клиентом и кодить в своё удовольствие в тишине. И вот тут VSCode резко захватывает рынок, нет ничего сложного в том, чтобы сделать сервер и клиент на веб-технологиях.

JetBrains в ответ выкатили Gateway, но как же глючно он пока работает. К сожалению, именно в такой архитектуре разрыв в удобстве разработчика чудовищный и, кажется, у меня грядёт очередная энная попытка окончательно переехать на VSCode.

UPD

Это не пост про вечный спор, что лучше. Для меня очевидно, что Idea. Это пост про то, что Idea оказалась не готова к современной парадигме Remote-разработки.

Недавно встретил живой node.js-кластер в проде и прослезился. Вычурная древняя технология — мастер процесс слушает порт/юникс-сокет, создаёт коннекшены и раскидывает рауд-робином через IPC по воркерам (а воркеры — это он сам себя нафоркал при старте). Да, можно кинуть в воркер сетевой сокет, но работает это криво и считай, что не было в проде. В итоге, имеем перегруженный сетевыми задачами мастер и лишнюю сериализацию/десериализацию межпроцессного общения. И конечно полное отключение при обновлениях (мастер-процесс тоже придётся погасить).

Ну а что делать, однопоточные процессы, а масштабировать хотелось. Сейчас-то понятно, один процесс в контейнер, штампуем контейнеров сколько надо и с балансировщика распределяем трафик.

А вот ещё одна забавная технология, уходящая в прошлое (по моим приборам) — Unix socket. Раньше когда нужно было посадить множество разработчиков (например) на один сервер, чтобы каждый спокойно гонял свой экземпляр приложения в своей папочке и не мешал друг другу занятым портом — использовали Unix-сокеты, такой способ межпроцессного общения. Создавался файлик сокета (который нужен был просто как адрес, в него ничего не писалось), node.js подписывалась на этот сокет (а не на порт), nginx прямо туда гнал трафик. И можно было таким образом поднимать сколько угодно приложений без контейнерной изоляции, каждое слушало свой unix-сокет и не мешало соседнему.

Когда зашёл на проект, одним из удивлений было то, что здесь использовался fontawesome. К счастью, вставлялись иконки не через шрифты (надеюсь, все уже отказались от этого?), а обычным noscript-инлайном, но всё равно, установка этого монстра в зависимости была неприятной процедурой.
Ну и вот, такой подарок под новый год — наконец-то у нас своя библиотека иконок.

А вообще планируем очень много опенсорса в следующем году.

Год трагедий, больших и маленьких, год потерь. Разорваны связи, потеряна дружба. Кто-то ушёл навсегда (зависит от отношения к реальности, конечно, для меня пока там пустота), с кем-то может быть снова сможем наладить связь спустя годы. Настроение где-то на уровне нигде, хочется только работать и работать, 24/7 365.

Год ценности физического общения. Хватит удалёнки с меня, хватит онлайн-конференций. Без реального общения мы ничто, мы двигаемся в никуда. Мы не можем поддержать друг-друга по зуму. Проверено — не работает. Разбежавшись в разные стороны мы никогда не сделаем ничего по-настоящему крутого. Так, будем ковыряться в песочнице и закрывать бэклог по багам.

Без плана, без цели вхожу в 2023. Но восстановлены забытые и налажены новые дружеские связи. Есть возможности, о которых раньше и мечтать не мог. Есть понимание того, что я могу делать, и в чём моя максимальная польза для других.

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

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

Вы все крутые, вы все молодцы. Всем добра и мира. Прорвёмся.

Самая добрая фотография у меня на телефоне. Всех обнимаю!

И помним, что v8 в браузере и v8 на сервере работают в совершенно равзных условиях.

Привет!

Столкнулись с интересным кейсом, для меня это просто утечка памяти года - JSON.parse(undefined)

Этот простой код в Node.js до 18 версии вызывает небольшую утечку памяти, примерно 128 байт на вызов, которые не очищаются с помощью Garbage Collector.

Проблема описана в этом issue, и как будто бы исправлена в актуальных мажорках ноды, но фактически утечка присутствует в 14.x и 16.x версиях, по результатам наших проверок.

Почему утечка года:
- она маленькая и медленная, нужны хорошие нагрузки что бы была заметна
- совершенно неожиданная при профилировании (просто посмотрите на этот "undefined" на скриншоте, я просто игнорировал его когда встречал)
- очень легко воспроизвести, у нас оказалось несколько мест где парсим те cookies, которые часто undefined

Очень рад работать с такими крутыми коллегами, один из которых смог это раскопать)

Основной причиной, почему начали смотреть утечки памяти, оказался другой код, связанный с LRU кэшами, но в любом случае это хороший повод обновить Node.js