Должен был это написать

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

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

Как сказали когда-то давным-давно мне мои друзья протестанты, которым я много и бескорыстно помогал — «Человек ты, Андрей, хороший, но всё равно попадёшь в ад». Важно не то, что ты действительно делаешь хорошего, важно вписываешься ли ты в рамки, выполнил ли ты базовую программу, после которой начинается твоя безупречность. Что ж, бог вам судья :)

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

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

А руки ещё помнят.

Кстати, JSX вырос из PHP-либы XHP, которая позволяла с помощью XML описывать HTML. В свою очередь XHP была построена на идеях JS-стандарта E4X, SpiderMonkey-реализацию которого мы и использовали в нашем XSLT-процессоре. Вот такая цикличность.

Постримим с ребятами из GeekBoards про клавиатуры. Попробую в очередной раз объяснить ,что не так с Keychron и что с этим можно сделать.

10.11 в 20:00 по GMT+3

https://holyjs.ru/talks/d1ba8d146dac4d30a49e5f252e6a8d19/

Вся эта шумиха с переездом с Твиттера на распределённый гипертекстовый векторный Mastodon напомнила мне про прекрасные времена Фидонета. Фидонет конечно был rulez 4ever, и никакая современная соцсеть не может сравниться с ним по вайбу (для меня). Если вы не застали (подозреваю, что старый тут только я), то вот вам краткий ликбез.

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

Вся сеть строилась на чистом энтузиазме. Ноды соглашались на вечно занятый ночью телефон (иногда поинты скидывались и ставили ноде вторую КРУГЛОСУТОЧНУЮ линию). Люди, имеющие доступ к дешёвому или бесплатному межгороду (или любой другой сети) поднимали хабы, и все вместе хабы образовывали бэкбон (хребет) сети, условие её выживания.

Фактически сеть могла работать даже на дискетах, привязанных к почтовым голубям — она была оффлайновой (да-да, FTN). Выглядело это так:

- Вечером вы включаете программу-мэйлер (например, T-Mail) которая начинает долбиться на номер ноды
- Дозвонившись на ноду мэйлер выкачивает пакет почты и закидывает его в эхо-процессор
- Эхо-процессор распаковывает почту и раскладывает по папочкам: личные сообщения и эхи. Эхо-конференции это продвестники форумов.
- Вы открываете редактор (например GoldED), читаете почту и отвечаете на что-то
- Эхо-процессор пакует почту, мэйлер пытается её отправить, вы отправляетесь спать, чтобы утром почитать, что же за великий срач случился в очередной эхе из-за вашего глупого сообщения, и не словили ли вы плюс из плюсомёта от модератора (три плюсика и бан)

Всю эту красоту убила банальная штука — в стране ввели повременную плату за станционарный телефон. Да, Фидо можно было запустить и поверх TCP/IP, но никому уже это было не нужно. Кончилась эпоха.

Такое дело, next.js наконец-то обогнал Create React App в качестве инструмента по умолчанию для React-разработчика. Да, конечно, есть Vite, есть Remix, у всех свои причины для выбора, но речь не об этом.

Речь о том, что давно пора закопать CRA. Это был хороший инструмент для старта обучения, но он никогда не был расчитан на долгую жизнь в продакшене. Может быть next и не лучшее решение, но это достойное решение.

Сегодня презентую доклад — результат двухнедельного копания в облачных провайдерах. Все варианты деплоя 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-сокет и не мешало соседнему.