Development

PM2 WebUI. Opensource Alternative to PM2 Plus. Minimalistic App Manager and Logs Viewer - suryamodulus/pm2-webui

Заметки одного из разрабов typescript. Чувак изучает кодовую базу и экосистему typescript и оформляет эти знания в заметки. Хорошее чтиво, если интересно окунуться во внутренности typescript

Оказывается в Eslint есть апи для профилирования скорости работы правил.

Команда VS Code столкнулась с тем, что всплывали баги, когда в функцию в typescript прокидывали null, undefined и прочие грязные вещи. В проекте был отключен строгий режим. Ко времени обнаружения этой проблемы в проекте уже было много файлов и просто так включить опцию в tsconfig было нельзя - нужно было бы разом поправить слишком большое количество ошибок проверки типов Команда VS Code пошла по другому пути: - Они завели отдельный tsconfig, который наследовал проектный, но включал строгие проверки. Также в нем было указано, что он работает только для ограниченного списка файла. Эти файлы уже жили со строгими правилами. - По мере исправления ошибок в проекте, список файлов в этом конфиге разростался - Когда в этом конфиге оказались все файлы проекта, они переключили опцию строгой проверки в основном конфиге. В CI отрабатывали пара скриптов, которые добавляли измененные в коммите/пуше файлы в список файлов в новый конфиг, если эти файлы проходили проверку строгим конфигом.

Немного про опыт миграции на строгий конфиг. Суть аналогична опыту команды VSCode

Микрофронтенды - это про независимость разработки. Сложный фокус в том, что не смотря на независимость разработки, для всех (и пользователей и разработчиков) приложение должно быть единым-целым Основные паттерны разработки микрофронтендов: - live together: код находится в монорепо, собирается и деплоится разом - build together: код находится в разных местах, но собирается и деплоится разом - run together: код находится в разных местах, собирается и деплоится независимо. Сборка единого приложения происходитв браузере в Asurion (компания, в которой работает докладчик) использует первый подход. Покрайней мере я так понял. Как движок для микрофронтендов они используют single-spa.js.org. Фреймворк выделяет следющие "микрофронтенды", из которых собирается приложение: - root config - main приложения. Там описывается роутинг, конфиги, загрузка ресурсов, layout - applications - приложения. Должны соответствовать специальному интерфейсу, через который фреймворк будет их дергать. - parcels - по сути виджеты. Независимые и переиспользуемые компоненты - utility modules - микрофронтенды с утилитами и библиотеками Фреймворк несет с собой роутер, который понимает что и когда нужно грузить

Jest по дефолту использует 1 тред для cli и N-1 тредов для запуска тестов, где N - количество ядер на вашем процессоре. Эта конфигурация - неоптимальна. Можно передать --maxWorkers=50% и тесты будут проходить быстрее. В разных контекстах будет разное оптимальное число. В статье есть способ поиска оптимального числа.

An ESLint plugin for writing better regular expressions. - RunDevelopment/eslint-plugin-clean-regex

Express уже давно не разрабатывается и отстал от современных реалий (насколько помню, от async хендлеров запросов там может утекать память). Все больше проектов отказываются от express в пользу других фреймворков, таких как fastify. Fastify: - Быстрый - Удобный - из коробки поддержка TS и тестирование - Из коробки много во что умеет. Например в валидацию и парсинг из и сериализацию в JSON. Если проект столкнулся с необходимостью мигрировать с expressjs на другой фреймворк, то необходимо будет написать простые API-тесты, не завязанные на сам фреймворк: - Делаем запрос - Получаем ответ - Сверяем body и код ответа Написать такие тесты можно с помощью пакета supertest. Хотя можно и ручками все сделать Это общий флоу для переезда на любой другой фреймворк. Fastify для облегчения миграции предлагает специальный плагин, который позволяет использовать хендлеры от express внутри fastify приложения. Также, все популярные middleware для express реализованы и для fastify. Статья интересна и тем, кто реально думает о миграции текущей кодовой базы с express на fastify, так и тем, кто хочет просто ознакомиться с fastify. В статье показывается мапинг вида "вот как мы это делали на express, а вот как будем делать то же самое на fastify"

Очень много споров возникает вокруг React.Context. Нужны ли state managment тулы, если есть контекст? Можно ли сложить весь state приложения в контекст? В данной статье разбирается, почему React.Context не подходит для замены state managment тулов, но отлично выполняет роль DI механизма. Эту особенность React.Context используют все state managment тулы. В статье также подробно разбирается, что такое DI, зачем он нужен и как его реализовать в react.

Atomos - расширение для google chrome, визуализирующий работу recoil. Выглядит интересно

Отличная статья про код-ревью. Если коротко то: - Код ревью требует смены контекста. Зачастую не один раз - Код ревью создают очереди на доске - Из-за код ревью приходится решать конфлиты, если код на ревью лежит слишком долго - Код ревью - это social interaction minefield. Как итог: ревью это дорого и никто не хочет его лишний раз делать. Вместо того чтобы делать код-ревью, следует применять другие практики шаринга знаний (моп-программинг например). Для коммерческой разработки процесс разработки через пулреквесты с использованием код-ревью - вреден. Pull requests are an improvement on working alone. But not on working together.

A fast, efficient Node.js Worker Thread Pool implementation - piscinajs/piscina

Топик про управление сложностью. Основной посыл - сложность невозможно убрать из системы т.к. сложность - часть системы (часть бизнес-требований например). Но зато сложность можно изолировать. Кажется в этом и состоит одна из основных забот разработчика - как изолировать сложность, чтобы она не расплескалась по всей системе.

npm скрипты - мощный инструмент, но сложный. Основные проблемы проистекают из факта, что package.json - это json, в котором неудобно описывать сложные команды - Неудобно описывать последовательность команд - Неудобно прокидывать аргументы, настаривать env Но вместо npm скриптов мы можем использовать make-файлы. Там все это делать удобно т.к. нет ограничений JSON, но мы еще получаем дополнительные преимущества: - более гибкое и удобное написание команд (мультистрочность например) - make умеет трекать зависимости и перезапускать таски только для изменившихся файлов - make быстрее

Расшифровка доклада про миграцию с монолита на микросервисы. Слово "монолит" стало синонимом слова "легаси". Сообщество верит, что есть один правильный ответ на то, какую архитектуру выбрать. И этот ответ - микросервисная архитектура. Sam Newman - автор книги про микросервисы и независимый консультант, рассказывает, почему монолит - это не всегда плохо и бывают ситуации когда переход на микросервисы лишь усугубит проблемы. Например, если у вас модульный монолит, то при переезде на микросервисную архитектуру вы можете сделать хуже, не получив профитов. Если же микросервисы вам нужны, то в статье описываются паттерны выноса функционала из монолита в микросервисы и новые челленджи, появляющиеся в микросервисах, которых нет в монолите. Также в статье интересно написано про release train. Это когда мы релизимся строго в определенное расписание. Релизятся те фичи, которые успели к этому расписанию. Я знал про подход, но не думал о том, что его используют для того чтобы придти к CI. Паттерн использования release train: - Релизимся, например, раз в месяц - Понемногу увеличивает частоту релизов - Когда частота релизов стала "ежедневно" - можно переходить к CI. Использование release train на постоянной основе - неправильно и вредно. Статья отлично рассказывает про разделение монолита: зачем и как это делать, необходимые культурные изменения. В целом все советы ложатся на абстрактную разработку, когда нужно выносить сущности из общей каши. Рекомендую, 10 из 10

James Sinclair написал статью про тернарный оператор в JavaScript. Чем оператор хорош, чем он плох и как следует его использовать. Как и прочие его статьи - великолепно

Крутой канал, обьясняющий, как работает сеть с помощью коротких и понятных видео.

Одна из проблем задачи оптимизации перформанса сайта - это понять, какой эффект даст оптимизация на бизнес. Можно найти много источников, где предлагает просто оптимизировать, потому это хорошо. Есть пара синтетических тестов - когда делали обратное - замедляли сайт. Телекоммуникационная компания Vodafone провела честный АБ тест улучшения производительности сайта. Одной группе людей показывали обычный лендинг, а другой группе - оптимизированный. Улучшение LCP на 31% дало рост продаж на 8%.

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

При разработке API (имеются в виду ендпоинты для фронта или интеграции) есть 2 стула: - Сначала спроектировать API (лучше) - Сначала разработать сервисы и потом их завернуть в API. Это хуже т.к. получившееся API придется дорабатывать. Также в статье приводятся способы разделения "уровней" API, композируя которые можно получать простые для интеграции системы

Как дебажить Jest тесты, исключая использование console.log и IDE? - node.js умеет открывать порт для подключения дебаггера. Можно запустить jest через node с опцией inspect и подключится дев-тулами из хрома - но можно пойти еще дальше и запустить node не с опцией inspect, а с командой inspect. В этом случае мы сможем дебажить прямо в консоли. Достаточно интересный опыт.

Опенсорс сервис для управления feature toggles. Позволяет управлять тоглами, предоставляет официальные клиенты для go, node, java, ruby, python, C#. Есть еще неофициальные клиенты для других языков (даже для Dart) Есть Enterprise и SaaS версия.

Статья 2004го года от Мартина Фаулера про DI, IoC, Service Locator. Мартин Фаулер оказал значительное влияние на те термины и концепции, которые мы используем сейчас для описания процесса получения зависимостей. Must Read для тех кто хочет разобраться что такое DI, IoC и чем Service Locator отличается от DI.

Воркшоп в котором Андрей рассматривает: - Что такое DI - Какие виды DI бывают - Что такое Service Locator и чем это отличается от DI - Как реализовать IoC на основе inversify - Как реализован IoC в nest.js Все это на примере простого кода. Итог: Хороший вводный доклад в тему DI

Профилировать React компоненты можно двумя способами: - API react для профилирования - Расширение для браузера, которое использует это API В статье подробно рассказывается как пользоваться обоими способами.

Обзор инструментов для аудита css. Что может пойти не так с css: - Неиспользуемые правила - Слишком специфичные селекторы - Дублирование селекторов - Слишком много цветов - И прочее Инструменты позволяют наглядно посмотреть, что не так с вашим CSS и предлагают способы исправить ситуацию

Storybook очень сильно интегрирован с webpack и это доставляет неудобства: невозможно просто так обновить webpack внутри storybook, невозможно заменить инструмент для сборки. Для решения проблемы команда storybook решила выделить интерфейс Builder, чтобы абстрагироваться от конкретной реализации. Теперь реализация сборщика - это плагин для storybook. Сделано прям как в умных книжках про архитектуру. На текущий момент есть 2 реализации: webpack4 и webpack5, но в будущем могут появится Vite, Snowpack и другие. PS: В статье есть хорошая шутка про то, что storybook старается минимизировать количество мажорных обновлений. Ха!

React проходит лишь 71% тестов на соответствие custom-elements, которые являются частью стандарта по веб-компонентам. В статье разбирается, почему на самом деле в react можно использовать custom elements почти без проблем. В целом статья больше интересна с точки зрения того, как работают custom elements и какие решения принимали мейнтейнеры react

Доклад 2019го года про то, что нужно проектировать системы исходя из когнитивной нагрузки команд, разрабатывающих систему, а не из технологий и паттернов. Люди много спорят о том, что нужно начинать с монолита и потом переходить в микросервисы, или что наоборот нужно начинать с микросервисов. Многие начинают проектирование систем с технологий, баз данных, фреймворков. Вместо этого следует начать проектирование системы с распределения когнитивной нагрузки. > software that fits in your head. Есть 4 метрики, по которым мы можем определить эффективность разработки: - lead time - deployment frequency - mean time to restore (MTTR) - change fail percentage Если software is ‘too big for our heads’ то это ухудшает все 4 метрики. Поэтому важно разделять систему на сервисы так, чтобы команда была полностью ответствена за сервис и могла fit system in head. Есть 4 фундаментальных типа команд: - stream-aligned team - ответственный за бизнес-домен, все остальные типы команд призваны снизить нагрузку с этого типа команд - enabling team - как правило временные команды, помогающие там, где есть пробелы - complicated-subsystem team - сфокусированы на каком-то очень сложном компоненте - platform team Мы можем формировать разные команды, классифицируя их по этим 4м типам команд. При этом нам нужно также подумать о коммуникациях между командами. Есть 3 основных вида межкоммандной коммуникации: - X as a service - collaboration - facilitating Мы не можем заранее так спроектировать команды и их взаимодействие, с этим нам помогают тригеры: - система стала слишком большой - появились люди, у которых есть узкая специализация - коммуникаций и координации стало слишком много Мы должны выделять команды так, чтобы команды были with high cohesion internalyy (think autonomy, mastery & purpose) и были небольшие каналы коммуникаций между маленькими командами. В докладе также приводятся реальные примеры применения этих принципов реальными компаниями. Авторы доклада - также авторы книги Team Topologies Book