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

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

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

https://youtu.be/mRvzgBGLVyM

Туган як

В альма-матер бы пробраться, скучаю.

Люблю эту гифку за наглядность проблемы наследования. Не расширяйте сущности, особенно из внешних библиотек, если они явно не объявлены абстрактными. К сожалению, у нас в TS/JS нет финальных классов. Возможно совет стоит сократить до «Постарайтесь не использовать классы». В общем-то большинство классов, что я встречаю в JS/TS коде не инкапсулируют никаких данных. Даже более того, зачастую все методы этих классов можно объявить статическими и ничего не сломается.

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

Так зачем страдать, если можно просто оперировать функциями?

Отличный набор базовых советов по эксплуатации node.js в режиме SSR

Привет!

Давно хотел поделиться накопленным за последний год опытом оптимизаций и масштабирования SSR приложений.

Думал уложиться в несколько telegram постов, но меня немножечко прорвало, и получилась почти полноценная статья.

В статье расскажу про основные проблемы SSR (спойлер - React и Node.js) и рассмотрю ряд возможных оптимизаций:

- Static Site Generation
- Rendering at the Edge
- Микросервисы
- Оптимизациия кода
- Кэширование компонентов
- Кэширование запросов
- Rate Limiting
- Fallback кэш страниц
- Client-side rendering fallback
- Кластеризация и воркеры

Ссылка на статью в моем Notion - https://superoleg39.notion.site/SSR-04ad1ab46de346edb244a1112bd357a3

Очень жду ваш фидбек в комментарии)

Этим субботним вечером хочу напомнить вам простое правило, которое часто забывают.

Вот оно: пропсы не влияют на ре-рендер компонент в Реакте. Ре-рендер срабатывает при изменении стейта, это его триггер. А вот дальше, независимо от того, изменились ли пропсы или нет, обёрнуты ли объекты в useMemo или не обёрнуты — все потомки этого объекта будут перерисованы. Да, если потомки обёрнуты в React.memo то пропсы важны, вот здесь уже нужно ловить ссылки и заворачивать их в useMemo и useCallback. Но там ещё и из контекста может прилететь.

А помните, был такой Tink? Вот и я забыл.

История в том, что когда Yarn (который на самом деле Berry, а не оригинальный Yarn) выкатил Plug'n'Play, то NPM тут же презентовал Tink. Похожее решение, но в случае Tink это был не просто файл-маппер, не просто немного иной режим работы npm, фактически они хотели глубоко патчить резолвинг модулей в node.js. Но в целом решали ту же проблему — как вынести зависимости за пределы проекта и избежать их дублирования на диске. Да, pnpm решает ту же задачу, но иначе, на симлинках, что делает его более хрупким решением.

К сожалению, tink умер не родившись, после ухода zkat из команды npm. Но поругаться с yarn за первенство идеи, как я помню, они всё же успели 🙂

https://news.1rj.ru/str/artalog/624

Фан-факт про JS, который вы, возможно не знали. В спеке JS нет Integer, но есть абстрактная операция ToIntegerOrInfinity которая используется для приведения Number к целому числу. И работает она так, что просто отрезает всё, что находится за запятой — It converts argument to an integer representing its Number value with fractional part truncated, or to +∞ or -∞ when that Number value is infinite

Убедитесь сами, вот вам спецификация.

Вот ещё забавное — parseInt не рекомендуется использовать с Number, потому что он берёт строкое представление числа и режет его до точки или до e.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/parseInt#using_parseint_on_non-strings

Бэкстейдж. Доклад, который вы может быть когда-нибудь увидите.

Никита успел раньше меня расписать

https://news.1rj.ru/str/mefody_dev/25