How to model application flows in React with finite state machines and XState

Пошаговый пример проектирования небольшой страницы с помощью XState

https://engineering.kablamo.com.au/posts/2021/finite-state-machines-and-xstate

#link #frontend #web-development #xstate #react #javascipt

Frontend development. How to use finite state machines in React?

Еще одна статья про проектирование маленьгого react приложения вместе с xstate

https://tsh.io/blog/finite-state-machines-in-react

#xstate #react #javascipt #web-development #frontend

17 причин не использовать чаты в работе, перевод статьи основателя Basecamp — Офис на

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

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

https://vc.ru/office/275508-17-prichin-ne-ispolzovat-chaty-v-rabote-perevod-stati-osnovatelya-basecamp

#communication

Patterns of Legacy Displacement

Паттеры для замены легаси на что-то новое.

Сам процесс замены можно разбить на следующие состоявляющие:
- Понять, чего хотим достичь
- Разбить проблему на мелкие части
- Успешно заделиверить эти части
- Изменить организацию так, чтобы новое решение не превратилось в новое легаси

В статье рассказывается об анти-паттернах переписывания легаси:
- переписывание всего разом
- переписывание потому что "новая технология"
- переписывание без понимания, чего хотим достичь
- переделывавние технической части или бизнесовой изолированно друг от друга

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

Обязательно к прочтению всем, кто хочет менять легаси

https://martinfowler.com/articles/patterns-legacy-displacement

#martin-fowler #refactoring #legacy

Ускоряем код на JS и других языках: подборка приёмов от разработчика поиска Яндекса

Команда поиска Яндекс внимательно следит за производительностью своего поиска. Поиск яндекса - пример бизнеса, в котором производительность критична.

У команды поиска уже были хорошие доклады про то, как они следят за перформансом своего приложения.

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

https://habr.com/ru/company/yandex/blog/570914

#web-development #frontend #yandex #habr #performance

GitHub - vultix/ts-results: A typescript implementation of Rust's Result object.

Имплементация обьекта Result из Rust на typescript. Result очень похож на монаду Maybe (если я правильно помню эту монаду) - может содержать или результат или ошибку, но перед тем как работать с результатом нужно проверить, содержится ли в Result ошибка или результат.

Выглядит интересно.

https://github.com/vultix/ts-results

#link #typescript #library #github #web-development #frontend

WebDriver BiDi - The future of cross-browser automation

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

Затем на свет вышел Chrome Devtools Protocol (CDP) и puppeteer. Он, обьективно говоря, удобнее всем. Кроме одного факта - работает только с chromium based браузерами. Текущие самые популярные платформы для написания браузерных тестов - cypress и puppeteer, работают на CDP.

Чуть позже Microsoft анонсировала playwright. Инструмент имеет апи как у puppeteer, но умеет автоматизировать safari и firefox (если не ошибаюсь).

А теперь комитет W3C стандартизирует WebDriver-BiDi - который должен взять плюсы CDP, но убрать из них специфику хрома и стать единым новым протоколом для общения с браузерами.

https://developer.chrome.com/blog/webdriver-bidi

#testing #web-development

TypeScript: Unexpected intersections

У вас есть 2 обьекта одного типа Type.

type Type = {
a: string,
b: number
}

Функция принимает параметр key типа keyof Type и перебрасывает из одного обьекта значение key в другой обьект.

function fn(key: keyof Type) {
obj1key = obj2key
}

В этом случае Typescript будет думать, будто-бы мы ЛЮБОЙ ключ obj2 кидаем в ЛЮБОЙ ДРУГОЙ ключ obj1. Т.е. rак будто пытаемся записать string | number либо в поле с типом string, либо в поле с типом number. Typescript кинет ошибку т.к. ему нужно доказать что мы правильно перезаписываем поля.

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

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

https://fettblog.eu/typescript-unexpected-intersections

#typescript #frontend #web-development

Heuristics for Effective Software Development: A continuously evolving list

Эвристики эффективной разработки.

Очередной манифест с лозунгами. Но в целом все верно.

https://holub.com/heuristics-for-effective-software-development-a-continuously-evolving-list

#development

The Problem with Prioritization Frameworks

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

- ICE/RICE scoring (reach, impact, confidence, effort)
- Value vs complexity 2X2 matrix
- Stakeholder scoring

Все они примерно одинаковы, нужно дать оценку идеям по трем пунктам:
- Сколько это принесет денег
- Как сложно это сделать

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

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

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

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

Есть и другие методы приоритезации:
- Kano model
- Opportunity scoring
- Buy-a-feature method

Они работают лучше, но по-другому и имеют свои проблемы

https://jefago.com/product-management/why-prioritization-frameworks-dont-work

#link #managment #agile #prioritization

GitHub’s Journey From Monolith to Microservices

Github вырос в 2 раза за полтора года. GitHub стал достаточно большим, чтобы ощущать неудобство от монолита:
- можно случайно все сломать
- большой кусок кода
- все разработчики завязаны на 1 стек

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

В статье вы не увидите ничего нового, если вы уже мастер микросервисов. П

https://infoq.com/articles/github-monolith-microservices

#github #microservices #web-development

How open source beat agile

GitHub запустился в 2008 году и очень быстро стал популярным. В том числе популяризировалась и модель Pull Request + Code Review.

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

Эта два совершенно разных подхода, которые подходят разным контекстам. Подход GitHub'а подходит open-source проектам, потому что:
- В проекты в GitHub'е нельзя просто так комитить в мастер
- Нет четкого заказчика

Подход Continious Delivery больше подходит agile проектам, где все разработчики могут комитить сразу в мастер и есть четкий заказчик.

Эти два подхода конфликтуют.

Почему же в коммерческой разработке все используют подход, который больше подходит для open source проектов? А именно, почему практически все разрабатывают с помощью Pull Request и Code Review?

Автор статьи связывает это с тем, что процесс разработки как в Open Source более прозрачен. Разработчики во время Code Review видят практики, которые применяют другие разработчики. В то время как при применении Continous Delivery сложно увидеть практики, применяемые другими разработчиками.

От себя добавлю, что инструментов, позволяющих проводить Code Review на Pull Request'ах - достаточно много. В то же время инструментов, позволяющих делать удобный Continious Code Review на мастере - нет совсем

https://surfingcomplexity.blog/2017/01/21/how-open-source-beat-agile

#agile #development #code-review

Prefer Declarative State Updaters

Статья про антипаттерн, когда чаилд-компонент работает с передаваемым ему апи, зная его реализацию

В частности, когда в чаилд компонент передаётся setState от родителя

Из минусов статьи - аргументация. Это плохо потому что это плохо и вообще не надо так.

https://kyleshevlin.com/prefer-declarative-state-updaters?ck\_subscriber\_id=887769274

#link #react #frontend #javascript #web-development

How To Write Readable React Content States

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

В статье рассматриваются два способа реализации этих состояний в react компоненте.

По сути это:
- условия в разметке
- отдельные компоненты

Оба способа имеют свои плюсы и минусы и подходят в разных контекстах

https://www.chakshunyu.com/blog/how-to-write-readable-react-content-states/

#link #react #javascript #web-development #frontend

testjavascript/nodejs-integration-tests-best-practices

40 бест практисов для интеграционного тестирования сервисов на nodejs. Многие советы никак не привязаны к технологическому стеку

https://github.com/testjavascript/nodejs-integration-tests-best-practices

#link #node #testing #frontend #backend #web-development

Team meeting audit: 3 tests for an effective Meeting OS (and 4 steps to fix it!) · 5. Action plan for our Meeting OS

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

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

В статье описан готовый фреймворк по анализу митингов в команде и как сделать их эффективнее

https://coda.io/@shishir/team-meeting-audit/5-action-plan-for-our-meeting-os-65

#link #meetings

A Journey in Test Engineering Leadership: Applying Session-Based Test Management

Статья про Session-Based Test Management.

Метод был описан еще в нулевых. Если коротко, то метод предлагает ставить процесс тестирования примерно так:
- Лид группы определяет стратегию и план тестирования
- Тестировщики тестируют
- В конце тестирования создается отчет, в котором, в том числе, указываются сколько времени ушло на само тестирование, сколько на поиск багов и сколько на административную рутину
- После этого мы можем анализировать, как бы улучшить процесс тестирования

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

https://infoq.com/articles/session-based-test-management

#testing #development

Better coordination, or better software?

Предположим у вас много разных сервисов, которые связаны друг с другом. И есть разные команды эти сервисы развивающие.

В такой системе нужно много синхронизаций - задачи могут влиять на несколько сервисов разом. И за этим нужно следить.

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

В таком случае количество каналов коммуникаций снизится и всем будет легче. А система станет гибче.

https://jessitron.com/2021/08/02/better-coordination-or-better-software

#architecture #development #agile

Consistency, Coupling, and Complexity at the Edge

Какую организацию API выбрать для проекта: RestAPI или GraphQL?

Rest API удобен для использования в сервисах и проектирования сервисов. Но не удобен для GUI т.к. REST предполагает разделение сущностей на отдельные ендпоинты, а в GUI мы хотим видеть все и сразу.

GraphQL удобен для GUI за счет того, что можно просто описать, что нужно показать, а там оно уже само разберется. Но это неудобно для сервисов.

Но почему нам стоит выбирать между REST и GraphQL? Почему не взять лучшее из обоих.

Если REST подходит для проектирования сервисов и использования в сервисах то давайте его там и использовать.

Если GraphQL удобен для GUI то давайте его использовать для конечных приложений (web, ios, android, etc).

Мы можем последовать Separation of Concerns принципу и использовать те инструменты, которые лучше подходят контексту.

Мы можем проектировать внутренние сервисы на REST, но делать отдельные bff для приложений, которые внутри уже используют то, что удобно им. Например, GraphQL.

https://infoq.com/articles/consistency-coupling-complexity

#architecture #graphql #rest #bff

Improving Testability: Removing Anti-Patterns through Joint Conversations

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

Как улучшить тестируемость системы? Н простых шагов:
- Определить анти-паттерны, которые мешают тестировать код
- Осознать, что тестирумость приложения важна, в том числе разработчикам
- Осознать, что если автотесты пишут тестировщики и они подключаются после разработки - вносить изменения будет сложно
- Проводить ретроспективы - почему что-то было сложно протестировать и как это исправить, а что было легко протестировать и как это закрепить
- Думать о тестировании на шаге проектирования системы. Обсуждать архитектуру решения вместе с тестировщиком.

https://infoq.com/articles/improving-testability

#testing

Gateway Pattern

Статья в блоге Мартина Фаулера про Gateway Pattern. Gateway инкапсулирует в себе знание об общении с внешним сервисом. Это гарантирует, что нюансы внешнего сервиса не растекутся по всей кодовой базе, а изменения в API внешнего сервиса можно обрабатывать только в Gateway. Кроме этого, Gateway полезен для мока в тестах.

https://martinfowler.com/articles/gateway-pattern.html

#martin-fowler #pattern