Bottleneck #03: Product v Engineering

Статья в блоге Мартина Фаулера про противостояние продуктовой и инженерной команды. Это противостоняие является дисфункцей и негативно сказывается на развитии продукта.

Данный блог пост является частью серии постов про проблемы при масштабировании стартапа.

Основные проблемы, когда разработка продукта разделена на продуктовую команду и инженерную команду:
- Инженеры не обладают продуктовым контекстом
- Перекидывание задачи через забор в зону отвественности другой команду
- Игнорирование технического долга
- Команды общаются, но не занимаются совместной работой

Из основных решений:
- Выделить правильные stream-aligned команды. Эти команды должны быть кросс-функциональны и сфокусированы не вокруг своей области работы, а вокруг метрик продукта
- Совмещать продуктовые и инженерные нужны продукта

Статья на самом деле достаточно большая и я очень сильно утрировал её смысл. Если вам интересна эта тема - рекомендую к прочтению

https://martinfowler.com/articles/bottlenecks-of-scaleups/03-product-v-engineering.html

#managment #martinFowler #crossFunctionalTeams #TeamTopology

Wix Multithreaded Node.js to Cut Kubernetes Pod Costs

Команда Wix применила worker threads в своём nodejs приложении и уменьшила потребление ресурсов этим приложении в своем kubernetes кластере на 70%.

Статья достаточно короткая. В рамках неё разбирается что же такое worker threads (механизм в nodejs для вынесения сложных вычислений в треды из основного потока) и какие есть готовые решения для использования этой технологии.

Перевод приложения на треды нетривиален (треды требуют чтобы между процессом и тредом летали "чистые" данные, что может потребовать значительного рефакторинга кода), но для Wix он определенно стоил того.

В конце статьи раскрываются изменения различных показателей сервиса. Например, теперь требуется на 70% меньше подов, улучшились метрики по скорости ответа, в 10 раз уменьшился рейт ошибок.

Эти цифры и есть самое важное в статье. Если у вас есть сложные вычисления на nodeJS, то вы можете также расчитывтаь на значительноее улучшение перформанса при переводе вычислений в треды.

https://thenewstack.io/wix-multithreaded-node-js-to-cut-kubernetes-pod-costs/

#development #javascript #wix #performance #multiThreading

Overcoming Popular Issues With React Projects — Dinosaurs With Jetpacks

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

Основная проблема React - это сообщество.

В статье на этот счет есть забавная цитата:

Second there is this immutable transducer reselect memoized concurrent proxy suspense state promotion society. Performance zealots obsessing over trillion renders per second. Which they don’t deliver, by the way.

Какие советы дает атвор:
- Не пишите на React (да и вообще на другом фреймоврке) если вам это не нужно. Простой JS код проще поддеррживать, тестировать и воспринимать. В целом совет звучит очень радикально, но, мне кажется, тут смылс в том, чтобы не завязываться на фреймворк там, где это не нужно.
- Избегать встроенных инструментов для управления стейтом
- Не складывать логику в кастомный хуки. Это сложно читать, сложно дебажить и сложно тестировать.
- Избегайте хайповых игрушек типа Suspense. Используйте скучные, проверенные инструменты.
И опять хорошая шутка от автора:
You know the joke about the Suspense? You know why is it called Suspense? It takes 4 years to release it.
- Избегайте культа иммутабельности. Полностью согласен с этим пунктом - иммутабельный код хорош только в языках, которые спроектированы под имутабельность. В нашем контексте код только усложняется, зачастую не принося большой пользы.
- Игнорируйте тех, кто разрабатывает фреймворки. Их советы хороши лишь в теоретических рассуждениях, но этим люди не умеют поддерживать большие реальные приложения и их советы зачастую вредны.
- Храните логику на бекенде. Используйте BFF. Это хорошо работает и это легко тестировтаь и дебажить.

Повторюсь, что статья очень субъективна. Но я в целом с ней согласен. В своих проектах я стараюсь форсить политику использования React только для рендера. Любую логику (запросы, логика приложения, подготовки данных) стараюсь выносить из компонентов в другие сущности.

https://dinosaurs-with-jetpacks.com/posts/react-problems

#development #javascript #react #bestPractices

Team management complexity and synchronisation costs

Хорошая статья от Виталия Шароватова про то, что парное программирование позволяет делать продукт одновременно быстро и качественно.

В статье разбираются 2 типичных проблемы команд разработки:
- Индивидуальная работа ведет к тому, что второе мнение появляется слишком поздно (во время код-ревью, тестирования или уже на проде)
- Оптимальный размер команды 6-7 человек, т.к. дальше уже слишком большой штраф синхронизации

Обе эти проблемы решает парное программирование.

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

Вторая проблема решается тем, что для менеджера нет разницы - синхронизировать 6 человек со своими задачами или 6 пар со своими задачами. Это значительно упрощает коммуникацию.

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

Так что, если вы где-то услышите, что парное программирование - это дорого, вы можете ссылаться на исследование, которое указывает что это дороже всего на 15, но зато снимает многие другие риски

https://qase.io/blog/quality-and-management-complexity/

#development #pairProgramming

Дайджест за 17 - 28 октября

textlint · The pluggable linting tool for text and markdown
Интересный инструмент для линтинга текстовых файлов и markdown, который поддерживает кастомные плагины.

Закрытие RFC по useEvent
В react сообществе столько разговоров было о новом useEvent и оптимизациях рендера, а теперь команда react решила, что текущий rfc недостаточно хорош. Вместо этого команда разделит текущий RFC на несколько и учтет пожелания сообщества

Bottleneck #03: Product v Engineering
Статья в блоге Мартина Фаулера про противостояние продуктовой и инженерной команды. Это противостоняие является дисфункцей и негативно сказывается на развитии продукта. В статье описываются проблемы этой ситуации и её возможные решения.

Wix Multithreaded Node.js to Cut Kubernetes Pod Costs
Команда Wix применила worker threads в своём nodejs приложении и уменьшила потребление ресурсов этим приложении в своем kubernetes кластере на 70%.

Overcoming Popular Issues With React Projects — Dinosaurs With Jetpacks
Статья про типовые проблемы в проектах на React. Статья весьма субъективная, но вполне злободневная и со многим хочется согласиться.

Team management complexity and synchronisation costs
Хорошая статья от Виталия Шароватова про то, что парное программирование позволяет делать продукт одновременно быстро и качественно. В статье разбирается, как парное программирование может решить 2 типичных проблемы разработки: долгая петля обратной связи и увеличение размера команды без появления проблем сложной коммуникации

——————————————

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

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

Чтобы компенсировать это, порекомендую пару каналов, которые сам читаю:
- artalog - мейнтейнер реатома пишет всякое интересное про реактивность, react, перформанс, typescript. Достаточно хардкорно
- melikhov.dev - Андрей Мелихов, один из постоянных участников подкаста веб-стандарта, когда-то вёл свой подкаст, делал (возможно и сейчас делает, просто я не в курсе) хорошие уроки на youtube, а также ведет свой канал, где рассказывает всякое интересное про DI, архитектуру, nodejs
- Канал с очень скромным названием SuperOleg dev notes - канал одного из разработчиков фронтенд кор-команды в tinkoff. Контент бывает не так часто, но когда случается - объемный, многогранный и качественный.
- Мир глазами другого человека - канал Романа Ивлиева (один из организаторов teamlead conf) про менеджмент.
- Yet Another SA - канал про архитектуру
- Docops - канал про ведение документации от лида команды документации tarantool

Вы, в свою очередь, в коментах, можете накидать в комментарии ещё интересных каналов для чтения 🙂

Introducing Turbopack: Rust-based successor to Webpack – Vercel

Я немного запаздываю относительно других каналов, но вот анонсировали новый бандлер от команды vercel - turbopack.

Последние года идет тренд на переписывание инфраструктурных инструментов с JS на более низкоуровневые и производительные (хотя бенчмарки показывают разное) языки. Вот пришло время переписать бандлер на Rust.

Обещают, что новый бандлер быстрее чем Vite в 10 раз и быстрее чем Webpack в 700 раз (в коментах накидали, что уже провели независимое исследование, и цифры не такие безумные. В общем, как обычно, авторы инструментариев не стремятся делать объективные перформанс бенчмарки). Как я понял, Turbopack разрабытавался под next.js и начиная с 13 версии next.js проекты будут собираться на нём.

Примечательно в этой истории также то, что "хоронит" webpack один из основных контрибьюторов webpack - Tobias Koppers. Я не помню с какого времени он разрабатывает webpack, но точно знаю, что вся глобальная деятельность в webpack c версии 2 по версию 5 - дело, в первую очередь, его рук.

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

https://vercel.com/blog/turbopack

#development #webpack #turbopack #bundler

Conway's Law

Коротка заметка в блоге Мартина Фаулера про закон Конвея.

Закон Конвея гласит:
Организации проектируют системы, которые копируют структуру коммуникаций в этой организации

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

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

Самая суть закона - то, как устроеная коммуникация между людьми, также она будет устроена в системе.

С точки зрения архитектуры и менеджмента важно учитывать этот закон при построении системы или организации команд.

Использовать закон можно при проектировании системы. Это когда мы, вместо того, чтобы ждать пока дизайн системы станет таким же как структура организации, сначала дизайним систему, а потом собираем команды вокруг компонентов системы.

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

https://martinfowler.com/bliki/ConwaysLaw.html

#managment #architecture #conwayLaw #martinFowler

What if the team hates my functional code?

Статья в блоге James Sinclair про неприятие командой введения функционального стила программирования.

На мой взгляд, достаточно частая проблема, когда люди изучают функциональное программирование на ютубе, в статьях, книжках. Заряжаются на чистый код, композицию, частичное применение, монады. Приходят на проект и начинают писать код "как там". А потом, при открытии МР-а получают критику от коллег что всё непонятно, сложно, как это дебажить и вот это вот всё.

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

В статье приводятся следующие вопросы, на которые необходимо ответить при залетании с ноги (не только с функциональной ноги):
- Как мы будем обучать команду новым подходам?
- Если что-то случится на продакшне, сможем ли мы быстро пофиксить? Сможем ли мы быстро поставить дебаг-логи?
- Как это масштабируется в нашем окружении?
- Как мы будем поддерживать единообразие в структуре и стилистике кода? Ведь мы хотим, чтобы любой человек мог начать править любой код
- Что случится, если ты (человек, влетающий с новыми порядками) уйдешь из проекта? Сможет ли команда это поддерживать?

Поэтому внедрять новые подходы надо итеративно, чтобы все плавно обучались и эксперименты были небольшими (в случае неудачи их легче откатить).

Дальше в статье идет гайд по рефакторингу от нечитаемого ФП-кода к читаемому ФП-коду

Код, который, скорее всего, будет непонятен тем, кто не погружался в ФП

const renderNotifications = flow(
  map(addReadableDate),
  map(addIcon),
  map(formatNotification),
  map(listify),
  wrapWithUl
);

Код после рефакторинга, который остается чистым и композируемым, но при этом понятен всем

const renderNotifications = (notifications) = {
  const withDates = notifications.map(addReadableDate);
  const withIcons = withDates.map(addIcon);
  const formattedItems = withIcons.map(formatNotification);
  const listItems = formatedItems.map(listify);
  return wrapWithUl(listItems);
};

От себя добавлю что в фронтенд-сообществе ФП натурально "одурманивает" разработчиков и они начинают писать чистый ФП-код в перемешку с обычным кодом, что сильно усложняет чтение кода. Каюсь, сам таким был. Теперь же я предпочитаю сразу быть как Груг - бить дубиной за безосновательное радикальное применение ФП там, где ему не место. Впрочем, как и за другие ярые эксперименты, которые сильно усложняют код, но применяются потому что это "круто".

https://jrsinclair.com/articles/2022/what-if-the-team-hates-my-functional-code/

#development #functionalProgramming

Code coverage with Storybook test runner

Сначала storybook добавили для историй поле play, в которое можно складывать необходимые взаимодействия с компонентом

Потом они добавили возможность писать там асерты и использовать истории как тесты

Теперь же выходит статья про то, как собирать test coverage с этих тестов.

В общем-то по ссылке доступна очень короткая инструкция про сбор test coverage у storybook тестов.

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

О том что storybook - инструмент тестирования в первую очередь, я говорил на своих докладах последние пару лет. Но теперь storybook сам делает удобное API для тестирования и костылить что-то самому нужно намного реже.

https://storybook.js.org/blog/code-coverage-with-the-storybook-test-runner

#development #storybook #testing

Дайджест за 31 октября - 3 ноября

Introducing Turbopack: Rust-based successor to Webpack – Vercel
Vercel опубликовал Turbopack - замену webpack, который, по их заверениям быстрее других бандлеров. В коммантариях к посту накидали независимого исследования от Evan You, где он показывает, что бенчмарк - синтетический и цифры не такие драматические

Conway's Law
Коротка заметка в блоге Мартина Фаулера про закон Конвея. Закон Конвея гласит "Организации проектируют системы, которые копируют структуру коммуникаций в этой организации". Этот закон можно инвертировать и сначала спроектировать систему, а потом команды вокруг него.
К посту также имеются полезные комментарии.


What if the team hates my functional code?
Статья в блоге James Sinclair про неприятие командой введения функционального стила программирования. Вкратце, она показывает, что не нужно заходить "с ноги" в код и с ходу писать В ультимативном ФП-стиле. Можно соблюдать основные праадигмы ФП и при этом не ломать устои команды.

Code coverage with Storybook test runner
Статья в блоге Storybook про возможность писать проверки компонента прямо в историях, а затем интегрировать это в Jest.


——————————————

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

Comparing TCP and QUIC

Неплохой обзор QUIC в сравнении с TCP. Рассматриваются основные проблемы TCP и как QUIC их обходит. Также в статье рассматривается, из чего состоит QUIC соединение и как формируются пакеты.

Предыстория QUIC для тех, кто пропустил все новости о нем. (Очень упрощенно, но не буду против если вы попинаете меня в комментариях, где я черезчур все упростил и пересказал неправильно)

Есть 2 низкоуровневых протокола передачи данных: TCP и UDP.

TCP реализует в себе гарантию доставки, т.е. посылая данные другому участнику сети, вы гарантировано получете от него ответ "получил". Это упрощает передачу данных (т.к. есть гарантия что другой участник взаимодействия получил или не получил данные), но в то же время замедляет весь процесс.

UDP - это протокол без гарантии доставки данных. При его использовании участники обмена данных сами должны решить проблему потери пакетов. Но зато сама коммуникация очень быстрая (не нужно дожидаться ответа второго участника)

Отсюда и популярные шутки вида "Я бы мог вам рассказать анекдот про UDP, но боюсь он до вас не дойдёт"

HTTP и HTTP2 построены поверх TCP. Игры же, как правило, делаются поверх UDP.

И вот относительно недавно (год-два назад) инженеры из Google пришли с идеей нового протокола для передачи данных на замену HTTP2 - QUIC. QUIC - это HTTP3.

Все, что можно было выжать из TCP уже выжали. Поэтому QUIC построен вокруг UDP протокола, что позволяет ему быть супер быстрым, секурным и вот это вот всё.

https://www.potaroo.net/ispcol/2022-11/quicvtcp.html

#development #quic #http3

What is a developer experience team?

Статья про эволюцию и организацию работы команды Developer Experience.

Что такое DX Team? Это паттерн команды, которая занимается улучшением опыта разработчика. Она улучшает внутренние инструменты, адаптирует процессы, строит системы удобного мониторинга и прочие интересные штуки, которые позволяют обычны м разработчикам делать свою работу лучше. Т.е. это команда разработчиков внутри компании, которая делает жизнь других разработчиков внутри компании лучше.

Как появляются DX команды?

1. Сначала какая-то существующая команда находит у себя проблемы и решает её своими силами.
2. В какой-то момент появляется крупная проблема и её нельзя решить в фоновом режиме. Появляется отдельная внутренняя рабочая группа по устранению проблемы. После решения проблемы, если он актуальная для других команд, решение масштабируется на другие команды
3. Организация понимает ценность работы над DX и выделяет отдельную централизованную команду. Эта команда работает в двух направлениях: стратегическое развитие (решают проблемы всей органиации) и обработка запросов от разработчиков. Эта работа идет достаточно хаотично
4. Команда организует свой родмап и приоритезирует работу. Здесь может появится отдельный PM или PO. Также у команды появляются четкие критерии по определению приоритетов разработки.

В статье также подробно описывается как приоритезировать задачи, но я тут останавливаться не буду.

Также описано как проводить эксперименты для новых инструментов или процессов. Как известно, слона едят по частям, поэтому при внедрении больших изменений нужно их внедрять итерационно. Это же касается и DX команд. Как внедрять новые процессы и инструменты:
1. Найти early adopters. Это, как правило, команды у которых либо сильно болит текущая проблема, либо очень гибкие и открытие к новому люди
2. Сделать функционал для них и отдать им в пользование
3. Собрать фидбек
4. Если эксперимент удачный (адоптером помогло) - раскатить на всю организацию. Иначе либо отказаться от идеи, либо внести исправления и снова отдать их в early adopters команды.

Рекомендую статью к прочтению всем, кто интересуется платформенными командами

https://leaddev.com/productivity-eng-velocity/what-developer-experience-team

#link #development #DX #platformTeam

👌🏼 jest over vitest

Интересная заметка, где автор описывает свой опыт замены jest на vitest.

vitest позволяет небольшими изменениями перевести весь проект с jest на vitest. Поэтому попробовать vitest достаточно просто.

В данной заметке интересны конкретные цифры. У автора jest оказался быстрее чем vitest (14 секунд против 16 секунд). И поэтому автор принял решение остаться на jest.

Однако автор отмечает что vitest намного быстрее в watch режиме.

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

https://bradgarropy.com/blog/jest-over-vitest

#development #javascript #jest #vitest

Announcing Rome v10

Вышел первый стабильный релиз инструментария Rome после начала переписывания на Rust.

Напомню, что Rome - это инструментарий для веб-проектов, который решает проблему зоопарка инструментов в экосистеме, когда каждый инструмент реализует одно и то же много раз (например, babel, eslint, prettier, typescript не могут переиспользовать результаты обработки кода друг-друга). За счет этого планируется создать быструю единую экосистему инструментов с очень хорошим DX.

В релизе поставляется линтер и форматтер.

Линтер вдохновлялся eslint'ом и содержит 60 стабильных правил.

Форматтер вдохновлялся prettier и, вроде как, можно без проблем заменить prettier на rome forammter

Также авторы выделяют принципы, которым они следуют при разработке инструментария.

Во первых, инструмент должен быть устойчив к ошибкам. Как пример приводится то, как eslint и rome linter обрабатывают ошибку синтаксиса. Если eslint встречает ошибку синтаксиса - то он не может обработать файл т.к. не может распарсить его в AST. Rome Linter же обрабатывает все, что может обработать (что смог распарсить в корректный AST). В статье есть прям гифка, покказывающая разницу для разработчика.

Во вторых, высокая планка для диагностики ошибок. При обнаружении ошибки нужно сообщить разработчику: почему это ошибка, что будет если её не исправить, как её исправить. Среди текущих инструментов в этом весьма неплохо продвинулся typescript. А вот правила eslint, как правило, ничего не объясняют, а просто запрещают. В статье приводится пример, когда линтер сообщает, что есть код, который недостижим и линтер объясняет, почему он решил, что код недостижим. Выглядит круто!

Выглядит неплохо, но в проекты вносить пока рано. Пока не выглядит, что у Rome есть серьезные преимущества против prettier и eslint. Ну работает быстрее. Но eslint и prettier и так достаточно быстрые чтобы успевать отрабатывать прямо в IDE на каждый введенный символ.

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

https://rome.tools/blog/2022/11/08/rome-10/

#development #javascript #rome

Gatsby 5: The Fastest Gatsby Yet | Gatsby

Состоялся релиз Gatsby 5.0.0!

Во первых, добавили Slice API, который позволяет выносить переиспользуемые компоненты или решения в отдельный слайсы, что ускоряет инкрементальные билды и деплои в Gatsby Cloud.

Во вторых, добавили частичную гидрацию. Т.е. будут гидрироваться только те компоненты, которые нужны для работы текущего функционала в браузере. Это значительно ускоряет перформанс метрики. Т.к. эта фича построена вокруг React Server Components, то он, как и RSC - пока будет в бете.

Также вышла вторая верся IDE GraphiQL. Это IDE в которой удобно разрабатывать Gatsby сайты и есть встроенная интеграция с GraphQL тулзами.

https://www.gatsbyjs.com/blog/gatsby-5/

#development #javascript #gatsby

The hidden cost of complexity

Статья про сложность (complexity) и простоту (simplicity).

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

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

Почему нужно выбирать простые решения? Из-за природы складывания сложностей. Если взять 2 сложные вещи и связать их, то в сумме получится намного более сложная система.

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

Хотя, иногда, для того, чтобы начать упрощать систему, необходимо сначала добавить сложность.

Основные поинты:
- Между сложным и простым, следует выбирать простое.
- Сложность растет экспоненциально
- Чтобы уменьшить сложность в системе, скорее всего потребуется сначала её добавить (миграционный период)

https://medium.com/@dolevp/the-hidden-cost-of-complexity-d9d8eb91594c

#managment #complexity

Дайджест за 7 ноября - 17 ноября

Comparing TCP and QUIC
Неплохой обзор QUIC в сравнении с TCP. Рассматриваются основные проблемы TCP и как QUIC их обходит. Также в статье рассматривается, из чего состоит QUIC соединение и как формируются пакеты.
В комментариях накидали еще полезных ссылок про QUIC


What is a developer experience team?
Статья про эволюцию и организацию работы команды Developer Experience.

Что такое DX Team? Это паттерн команды, которая занимается улучшением опыта разработчика. Она улучшает внутренние инструменты, адаптирует процессы, строит системы удобного мониторинга и прочие интересные штуки, которые позволяют обычны м разработчикам делать свою работу лучше. Т.е. это команда разработчиков внутри компании, которая делает жизнь других разработчиков внутри компании лучше.

Рекомендую статью к прочтению всем, кто интересуется платформенными командами

👌🏼 jest over vitest
Интересная заметка, где автор описывает свой опыт замены jest на vitest. Благодаря совместимости vitest с jest, переехать с jest на vitest достаточно легко. Автор проделывает не очень много шагов для переезда, но в его случае оказывается, что vitest отрабатывает медленее jest (но быстрее в watch режиме). Поэтому переезд в итоге не состоялся

Announcing Rome v10
Вышел первый стабильный релиз инструментария Rome после начала переписывания на Rust. В релизе поставляется линтер и форматтер. Они оба быстрее чем Eslint и Prettier.
Также в блоге продемонстрированы 2 подхода команды Rome:
- Инструменты устойчивы к ошибкам (в статье есть прекрасная гифка, которая показывает разницу подходов на примере Eslint и Rome Linter)
- Ошибки должны быть самодиагностируемыми. Т.е. при возникновении ошибки от инструмента, разработчику должно быть понятно, что это за ошибка, почему это плохо, что к ней привело и как её исправить. Это также показано в статье на примере одного из правил линтера


Gatsby 5: The Fastest Gatsby Yet | Gatsby

Состоялся релиз Gatsby 5.0.0. Новые фичи для перформанса и обновление своей IDE. Хотя в коменте к посту написали что Gatsby пора хоронить 🙂

The hidden cost of complexity
Статья про сложность (complexity) и простоту (simplicity).
Основные поинты:
- Между сложным и простым, следует выбирать простое.
- Сложность растет экспоненциально
- Чтобы уменьшить сложность в системе, скорее всего потребуется сначала её добавить (миграционный период)


——————————————

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

Deno 1.28: Featuring 1.3 Million New Modules

Вышел Deno 1.28

Как и обещала команда Deno - в этом релизе стабилизировали совместимость с npm экосистемой. Это значит, что теперь все пакеты из npm можно свободно использовать в Deno. При этом получая все плюшки Deno, связанные с безопасностью.

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

Также из нового и интересного:
- lock-файл создается автоматически если есть конфиг deno
- Стабилизировали несколько старых API и добавили новое единое экспериментальное API для запуска команд (напримре, для запуска какой-то консольной утилиты из deno-рантайма)

https://deno.com/blog/v1.28

#development #deno

Release v4.0.0: Complete rewrite · fullstack-build/tslog

Вышел 4.0.0 релиз либы для логирования tslog в котором либу полностью переписали:
- без зависимостей
- работает в node.js и браузере
- ESM
- Большие возможности кастомизации

Честно говоря, даже не слышал об этом логере до этого. Но интересно, что мейнтейнеры решили полностью все переписать.

Судя по доке, логгер действительно достаточно фичастый и гибкий.

https://github.com/fullstack-build/tslog/releases/tag/v4.0.0

#link #development #javascript #logger #release #library

google/wireit: Wireit upgrades your npm scripts to make them smarter and more efficient.

Новый опенсорс от гугла в JS экосистему. Встречайте, wireit!

У библиотеки достаточно ёмкое описание: wireit улучшает npm scripts делая их умнее и эффективнее.

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

Собственно npm никогда и не хотел быть хорошим task-manager'ом, оставляя это на откуп сообществу.

Wireit как раз инструмент, который позволяет удобно делать непростые скрипты для проекта.

Wireit умеет:
- указывать какой скрипт от какого зависит, что позволяет wireit запускать их максимально эффективно
- запускать скрипты при изменении файлов
- определяет, когда скрипт не нужно запускать
- с точки зрения пользователя, интерфейс не меняется - все команды также запускаются через npm run

Вместо тысячи слов просто положу пример, как тул подключается в проект через package.json файл

{
  "scripts": {
    "build": "wireit",
    "bundle": "wireit"
  },
  "wireit": {
    "build": {
      "command": "tsc"
    },
    "bundle": {
      "command": "rollup -c",
      "dependencies": ["build"]
    }
  }
}

https://github.com/google/wireit

#link #development #javascript #npm #google #library

Why would anyone need JavaScript generator functions?

Очень хорошая статья от James Sinclair про генератор-функции в JS. Автор коротко объясняет, как генератор-функции оказываются незаменимы при обработке огромных массивов данных (позволяют реализовать ленивую обработку), почему async/await не закрывает все потребности работы с асинхронными функциями и как можно сделать бесконечную последовательность.

Генераторы не очень нужны в обычном коде приложения, но могут оказаться незаменимыми в "инструментальном" коде.

Рекомендую к прочтению

https://jrsinclair.com/articles/2022/why-would-anyone-need-javascript-generator-functions/

#development #javascript #sinclair #generators #recommended