Development

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

В 1993-м году ученый Данбар вывел число, которе описывает количество социальных связей, которое в среднем способен поддерживать человек. Точнее там несколько чисел для разных уровней взаимодействия. Сами числа такие: 5, 15, 35, 150. Да и на самом деле там были не числа, а диапазоны, а сами числа - это скорее "среднее по палате". 5 - для близкого круга общения (условно семья) 150 - это число для большого сообщества. Например, рабочий офис, сообщество на форуме\дискорде. В статье также приводится цифра 3.8 - это среднее ограничение на количество человек, участвующих в общении (1 говорит, 2.8 слушают). Теория про числа Данбара подтверждается разными независимыми исследованиями (хотя числа там другие, но весьма близкие) Да и в целом, по моему опыту, это похоже на правду. Собрав 4 человек вместе в баре - скорее всего у них легко получится коммуницировать. Но собрав 6 человек, вероятно люди сами поделятся на 3+3 или 4+2 группы. Знаменитая рекомендация по размеру команды "на команду должно хватать 2 пиццы" тоже неявно указывает на некоторое волшебное число, способное описать ограничение на рабочую группу. В общем, число Данбара - весьма интересная вещь, которую можно применить при организации коммунити. Советую прочесть эту статью и, если понравится, почитать ту же википедию. На английской википедии, например, есть раздел с критикой теории

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

Storybook в прошлых блог-постах рассказывали про то, что они добавили в свои истории возможность взаимодействовать с компонентами, используя testing-library в своействе истории play Теперь же они пошли еще дальше и: - добавили возможность писать асерты в блоке play - теперь можно запускать play-блоки как авто-тесты. Для этого под капотом используется playwright и jest. - добавили панель взаимодействия, где можно наблюдать, как блок play буквально по-шагово взаимодействует с историей Выглядит очень круто и как раз этого не хватало storybook для полного закрытия потребности в юнит-тестировании компонентов. Не уверен, что текущая реализация будет идеальной. Но направление верное.

Очень хороший список бест-практисов для автоматического тестирования на JS. Рекомендую.

Статья про достаточно интересный концепт - перенос JS кода в Rust и использование его через WASM. Сама идея - вынести код с логикой в WASM - не нова. Это, например, позволяет описать бизнес-логику 1 раз на основном языке проекта (пусть будет условный Rust) и поставлять его в браузер без изменений. Также это позволяет вынести "сложные" вычисления из JS. В рамках данной статьи автор описывает как они переводили логику Reducer в Rust. Это было необходимо, потому что основная логика написана на Rust, но reducer был на TS. Из-за этого происходило много коммуникаций TS = WASM, из-за чего перформанс приложения утыкался в этот канал общения двух окружений. Поэтому ребята подумали и решили вынести еще и редусер в Rust, чтобы убрать лишние коммуникации. Кроме того, что ребята решили свои проблемы с перформанс, использование Rust для реализации редусера позволило: - Не беспокоится о нарушении иммутабельности - Rust все проверит сам - Можно использовать вкусные фишки Rust - pattern-matching, if-else expressions, док-блоки с исполняемыми авто-тестами Также ребята из Fiberplane написали свой генераторов биндингов к wasm - fp-bindgen.

`@swan-io/boxed` - библиотека с небольшим количеством монад для использования в JS. Также эта либа совместима с `ts-pattern`, о которой я писал чуть ранее. Библиотека предоставляет небольшое API: Option, Result, AsyncData, Future, Lazy и небольшие утилки. Но если вы хотите себе монадки, но не хотите тащить огромные либы, то boxed может быть интересен Также в документации есть мемчик, что меня сильно удивило. Ссылку кидать не буду - оставлю на самостоятельное исследование :)

Важная новость. В NodeJS решили сделать свой собственный, встроенный test runner. Так исторически сложилось, что NodeJS поставлял библиотеку для асертов, но не поставлял ничего для тестирования. Т.е. все, что связано с авто-тестами было вынесено для реализации сообществом. И сообщество за все это время успешно опробовало различные способы тестировать код, а какие-то стали чем-то вроде профессионального стандарта (имею в виду jest и mocha) Теперь сообщество NodeJS решило, что пора внести в NodeJS возможность запускать тесты из коробки. При этом у проекта нет цели с нуля создать самый лучший фреймворк тестированиял. Вместо этого NodeJS сосредоточится на базовом функционале, который нужен всем фреймворкам тестирования и который используется большинством популярных решений. В NodeJS войдет: - Функция `test` для определения тестов и сьютов - Поддержка асинхронных тестов - Возможность запустить тесты проекта и указать какие конкретно - Гарантия изоляции тестов - Возможность запускать тесты в несколько потоков Пощупать test runner уже можно в nightly билдах NodeJS. Лично я надеюсь что это войдет уже в следующий LTS.

Вышла в свет альтернатива Storybook'у - [Ladle](https://www.ladle.dev/blog) Что можно сказать про Ladle: - По бенчмаркам самого Ladle, Ladle быстрее Storybook. Внутри Ladle использует vite. Хотя Storybook тоже уже умеет в сборку через Vite - Ladle нацелен на то, чтобы можно было мигрировать со Storybook на Ladle без особых усилий. Ladle поддерживает тот же формат историй, что и Storybook. Также Ladle поддерживает встроенные аддоны Storybook. Выглядит заманчиво, но уже есть [статьи в интернете](https://dev.to/mbarzeev/trying-out-ladle-a-storybook-alternative-f68) от первопроходцев - не все так гладко. Запускается действительно быстро, но есть проблемы. Например, Ladle в некоторых кейсах не замечает изменений в файлах.

Состоялся публичный релиз фреймворка Redwood версии 1.0.0. Redwood - это фреймворк для веб-разработки, который позволяет быстро создавать продукты. Их целевая аудитория, судя по их сайту - стартапы. Redwood включает в себя React, Jest, Storybook, GrahpQL и, как я понял, интеграции с разными сервисами авторизации и деплоя.

Вышла 4 версия библиотеки ts-pattern. Библиотека реализует pattern matching в TS коде. Выглядит интересно Пример кода ``` import { match, P } from 'ts-pattern'; type Data = | { type: 'text'; content: string } | { type: 'img'; src: string }; type Result = | { type: 'ok'; data: Data } | { type: 'error'; error: Error }; const result: Result = ...; return match(result) .with({ type: 'error' }, () = `pOups! An error occured/p`) .with({ type: 'ok', data: { type: 'text' } }, (res) = `p${res.data.content}/p`) .with({ type: 'ok', data: { type: 'img', src: P.select() } }, (src) = `img src=${src} /`) .exhaustive(); ```

В блоге Мартина Фаулера появилась статья с описанием паттерна Transitional Architecture, который используется для плавной замены легаси системы на новое решение. Суть Transitional Architecture - сделать решение, которое позволит заменять легаси систему малыми частями. Когда вся легаси система будет заменена, временное решение следует убрать. В данном случае создание временного решения выглядит как лишняя работа, которую мы делаем, чтобы потом выкинуть. Но временное решение позволяет нам: - Заменять легаси систему не за один раз (слона надо есть по частям) - Возможность улучшить что-то вокруг легаси системы - Плавно проверять новое решение, которое приходит на замену старого. Например, мы можем обрабатывать новой частью системы только часть операций В статье приводится хороший пример применения паттерна

Хорошая статья про приоритезацию и скорость работы. Практически везде, где я работал, менеджмент в какой-то момент решал, что было бы хорошо прошерстить ВЕСЬ БЭКЛОГ из нескольких сотен задач: актуализировать задачи, поставить приоритеты, оценку. Еще круче: использовать скоринг по типа RICE, WSJF. На это уходит несколько недель, чтобы потом получить "актуальный приоритезированный бэклог". Правда через какое-то время (где-то в рамках года) оказывается, что бэклог опять стал неактуальным. Я еще ни в одной книжке по процессам не видел, чтобы где-то кто-то делал актуализацию всего бэклога. В скраме - текущая и следющая итерация. В канбан-методе - нужны топ N задач, где N - сколько мы сможем взять на следующей каденции планирования. Про PMBoK не читал, но уверен что и там нет активности поддержки бэклога из сотен итемов. Верная стратегия состоит в том, что чтобы сделать больше, нужно делать меньше. Точнее, чтобы сделать больше за длительный период времени, нужно делать меньше в текущий момент времени. Вот вся статья "How To Do Less" она вот про это. В статье рассказывается, почему WIP-лимит 1 - это благо, и как говорить "Нет" при обсуждении любых новых задач. В статье даже есть шаблоны ответов с плейсхолдерами наприхмер `This isn’t MAIN_PRIORITY, so we aren’t going to do it until at least ESTIMATED_DONE_DATE.`

Вышел React 18. Кажется об этом не сказал только ленивый, поэтому я просто приведу краткий список фич: - React теперь умеет в concurrent render. Подробнее лучше почитать в статье - Suspense можно начинать использовать в фреймворках. - React теперь умеет автоматически батчить изменения. Например, при вызове подряд двух setState, теперь будет всего 1 ререндер (следствие concurrent render). - Добавлена фича Transitions. Она позволяет выделить обновления UI, которые не требуют срочного ререндера. - Обновлены render-методы для ReactDOM - Новое интересное поведение Strict Mode. Strict Mode в режиме разработки тепреь будет эмулировать анмаунт и маунт компонента, чтобы проверить, есть ли в компоненте нежелательные сайд-эффекты. Также в Канале SuperOleg dev notes есть разбор нового реакта в плане перформанса (тлдр: React 18 - быстрее по пользовательским метрикам и выдает больше RPS) Подробнее: https://t.me/super_oleg_dev/49

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

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

Вышла 5 версия zx и кажется пришло время упомянуть zx в канале. zx - это инструмент от google, который призван заменить bash-скрипты. bash-скрипты - весьма мощный инструмент, но на bash'е неудобно писать код. Можно писать JS-скрипты, но нативное API nodejs слишком низкоуровневое и требует множества приседаний для самых простых сценариев. Я помню релиз первой версии и тогда я не очень понимал, зачем конкретно мне его использовать. Я посмотрел ченджлоги релизов zx и впечатлен развитием инструмента. Надеюсь в будущем его развитие будет идти в том же ключе - упрощение написания bash-подобных скриптов. Кажется в ближайшее время стоит его попробовать в какой-нибудь рабочейз адаче.

Статья про постановку процесса онбординга в компании. Если вкратце - рассказывается как сделать гайд, который ведет сотрудника во время онбординга и позволяет ему понимать, что ему еще нужно узнать, у кого и как это узнать, и нужна ли ему помощь

Статья про текущее положение Agile. В начале 2000-х agile был прорывной идеей, содержащей 4 основных принципа. Применение этих принципов для организации разработки позволяло делать лучшее ПО на рынке. Однако, спустя время, термин agile стал размываться и использоваться не к месту. Появились странные сертификации, agile трансформации и под словом agile начали продавать проектное управление. На текущий момент применение agile ведет к небольшому увеличению эффективности т.к. текущая разработка по-умолчанию намного ближе к agile чем 20 лет назад. На текущий момент для сообщества важно отбросить неверное использование agile и искать новые сферы его применения.

Хорошая вводная статья про monitoring и observability. Кратко рассказывается про: - зачем нужно следить за состоянием системы - что такое мониторинг и как его можно реализовывать - что такое observability и из чего он состоит - приводятся полезные практики для мониторинга и observability Рекомендую к прочтению, если вам интересна тема мониторинга приложений

Сайт с инструментами и подходами к разработке дизайн-систем. Кажется, от тех же ребят, которые делали сайт про инструменты и подходы к моно-репозиториям. Выглядит интересно

Статья про то, как автор улучшал типы популярной библиотеки для создания CLI на node.js - commander.js Commander.js использует паттерн builder, что позволяет затипизировать использование опций CLI после их обьявления. Для этого используются продвинутые (на мой взгляд) техники typescript: - вывод типов через infer - шаблонные литералы в типах TS для извлечения имени опции из строки вида --option - комбинация тернарных операторов для вывода типов Рекомендую к прочтению, если вам интересно как с помощью TS можно затипизировать сложные кейсы. Также в блоге в сайдбаре есть интересные кнопки "TLDR" и "Celebrate". Прикольно сделаны :)

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

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

Хороший доклад про то, что микросервисы - не панацея и нужны не всем. Правильное, но достаточно непопулярное мнение. Снизу оставляю описание доклада как есть: Микросервисы сегодня — это хайп, о котором говорят из каждого утюга. Складывается мнение, что старый добрый монолит — это плохо, а микросервисы — таблетка от всех болезней. Но так ли это на самом деле? В своем докладе я расскажу о том, когда стоит предпочесть монолит микросервисам. А также о том, что монолиты бывают разные, это не обязательно большой комок грязи. Модульный монолит позволяет сделать такую же качественную изоляцию частей системы друг от друга, как это предлагают микросервисы, при этом сохранив простоту отладки, деплоя и работу в рамках одной транзакции. Да, писать хорошие монолиты тоже нужно уметь :) Еще расскажу когда обычному монолиту пора становиться модульным и как перейти от обычного монолита к модульному. И, конечно, как выделять модули в отдельные сервисы.

Тред в твиттере про то, как увеличить продуктивность команды. тлдр: уменьшить количество рабочих встреч. В треде описаны достаточно рациональные идеи про встречи и фокусное время: - Вместо созвонов для стендап митингов - достаточно сообщений в чате - Всего 2 командных митинга в неделю - планирование в начале недели и демо в конце - Если митинг все таки нужен - лучше провести его в начале рабочего дня или в конце, чтобы середина дня была занята полезной работой - "Нет!" лишним людям на митинге. - Не нужно принимать каждую встречу в календаре, на которую вас позвали - Бронируйте свое рабочее время в календаре, чтобы вас не могли отвлечь пока вы работаете

Trilium - open-source инструмент для ведения персональной базы знаний. Сделан на JS, выглядит неплохо

Amazon'у необходимо быть очень быстрыми т.к. задержка в 100мс может стоить 1% от продаж. А при масштабах Amazon это огромные деньги. Поэтому в amazon все построено на серверном рендеринге, но при этом SSR React'а оказался недостаточно быстр для них. Достаточно интересный тред в твитере, где затрагивается то, как и зачем Amazon старается быть быстрым.

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

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