Soulful Socio-Technical Architecture

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

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

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

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

При национализации "люди сверху" решили, что надо поменять процесс добычи угля и разделили процесс на 3 этапа и разделили команды на 3 области.

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

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

Далее статья описывает интересные факты о вовлеченности, командах и социально-технических системах. И при этом есть ссылки на другие практики и книги (DDD, Team Topologies).

Если вам интересен managment и agile - статью можно прочитать. Если вы - кодер, то скорее всего статья покажется вам философскими рассуждениями и полной воды.

PS: В статье есть интересные илюстрации. Например, самооранизующиеся команды на фоне космоса.

https://infoq.com/articles/soulful-socio-technical-architecture

#agile

GitHub - trekhleb/javascript-algorithms: 📝 Algorithms and data structures implemented in JavaScript with explanations and links to further readings

Репозитории, который содержит описание и реализацию на JS более 100 алгоритмов. Описания, кроме текста, содержат красивые диаграммы и анимации, упрощающие понимание материала

https://github.com/trekhleb/javascript-algorithms

#link #javascript #algorithms

6 Concrete Tips That Will Make Your React Pull Requests Easier To Review

6 Советов по улучшение Code Review:
- Опишите изменения, которые приносит этот ПР и зачем он их делает
- Если у вас изменения визуала - приложите скриншоты
- Расскажите о требованиях к задаче
- Не пишите сложный код
- Расскажите, как ревьюить ваш код

Статья достаточно короткая и почему-то привязана к React, хотя сами советы применимы к Code Review любой задачи.

https://chakshunyu.com/blog/6-concrete-tips-that-will-make-your-react-pull-requests-easier-to-review

#code-review

GitHub - javascript-obfuscator/javascript-obfuscator: A powerful obfuscator for JavaScript and Node.js

Обфускатор JS кода, кототорый легко интегрировать в процесс сборки.

https://github.com/javascript-obfuscator/javascript-obfuscator

#link #javascript #library

GitHub - webpro/reveal-md: reveal.js on steroids! Get beautiful reveal.js presentations from any Markdown file

Reveal.js - движок для презентаций на html+js. Reveal-md позволяет описывать слайды в markdown и затем переводить их в reveal.js. Если вы хотите делать презентации, но вы не хотите делать их в каком-то GUI, а просто хотели бы описать все текстом и чтобы оно потом само - рекомендую обратить внимание на reveal-md

https://github.com/webpro/reveal-md

#link #javascript #presentations

The Micro-Frontend Chaos (and how to solve it)

Статья про микрофронтенды и борьбу за обратносовместимые изменения.

Микрофронтенды позволяют нам независимо разрабатывать и деплоить разные части приложения. Но если 1 из частей приложения ломает контракт - то может произойти каскад ошибок - часть А ломает контракт, от этого падает часть Б, которая зависит от А, а дальше падает В, зависящая от Б.

Автор перебирает разные решения но в итоге приходит к anit-corruption layer. Суть идеи, как я понял, явно выделять фасад модулей для удобного применения и следить за тем, чтобы он был обратносовместим. В npm пакетах эту роль обычно выполняет index.js - вы можете сделать сколько угодно сложную структуру в npm пакете, но index.js должен быть удобным и обратносовместимым.

Также в статье много примеров использования module federation

https://itnext.io/the-micro-frontend-chaos-and-how-to-solve-it-960b0a90c58

#javascript #microfrontends

Can we useRef, but without the .current? Let's try!

Захватывающая статья про нестандартное использование useRef в react.

Статья начинается с того, что каждый раз писать ref.current - это не нормально, это лишний шум. Поэтому автор приводит несколько примеров, как использовать useRef, но не писать .current

А дальше автор уходит в исследование возможностей useRef для нестандартного использования. Например, для создания компонентов со своим независимым скоупом.

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

https://thoughtspile.github.io/2021/10/25/useref-no-current

#react

Why I always wrap Context.Provider and useContext

React Context API - удобное, низкоуровное API. Разработчику необходимо делать телодвижения для простых вещей типа исключения лишних ререндеров

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

https://thoughtspile.github.io/2021/10/27/better-react-context

#react #react-context

Elm at Rakuten

Компания Rakuten поделилась своими ощущениями от 2х лет использования Elm в продакшне.

Если коротко, то ребята довольны Elm.
- Функционыйльный ЯП
- Гарантия отсутствия ошибок в рантайме
- Компилятор хорошо оптимизирует код и быстро компилирует. В статье приводится цифра 2.5 секунды для компиляции 60к строк кода.
- Великолепный вывод ошибок при компиляции. Компилятор описывает, почему это плохо и как это исправить. Как минимум советую посмотреть статью только хотя бы ради этого пункта
- Elm, кроме синтаксиса, предлагает архитектуру
- Имеет встроенный линтер

При этом Rakuten обозначает явный минусы выбора Elm:
- Сложности с наймом
- Перейти на ФП не так-то просто
- Приходится переизобретать то, что в JS экосистеме уже давно есть
- Иногда необходим интероп с JS
- Малое количество доступных ресурсов по Elm

В целом, вдохновляющая статья про Elm.

https://engineering.rakuten.today/post/elm-at-rakuten

#elm

Завтра начнется HolyJS - платная онлайн конфа от jug.ru про фронтенд. Но последний день можно будет посмотреть бесплатно, если зарегистрироваться.

- 7 докладов: например, про множественное наследование на JS от Виктора Вершанского, Test Driven Development от Дмитрия Коваленко и «бабушкофон» (sic!) от Никиты Мостового;
- Большой воркшоп по GlimmerX из двух частей;
- Дискуссии после каждого доклада, где можно пообщаться со спикером;
- Отдельные тематические дискуссии при участии крутых экспертов;
- Обсуждения в главной студии;
- Возможность поучаствовать в играх, квизах, конкурсах и других активностях от партнеров конференции — там можно не только круто провести время, но и получить ценные призы;
- Виртуальная выставка конференции;
- Чаты, где сидят сотни ваших коллег со всего мира.


Для участия в бесплатном дне нужно только зарегистрироваться. Там нужно выбрать тип билета «COMMUNITY DAY»

GitHub - lukeed/uvu: uvu is an extremely fast and lightweight test runner for Node.js and the browser

Ситник и artalar (автор ReatomJS) в твиттере рассказали о положительном опыте использования тест-раннера uvu.

Поигрался локально - действительно быстро работает

Из плюсов:
- быстрый
- простое API
- нет глобальных переменных (describe, it, test). Все нужно импортировать явно. Как следствие, тесты можно запускать просто как node test.ts и это будет работать

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

https://github.com/lukeed/uvu

#link #javascript #testing #github #library

Разбираемся в сортах реактивности

Текстовая расшифровка доклада Дмитрия Карловского (более известный как автор $mol) про реактивность в общем и реализацию реактивности в JS-библиотеках в частности.

Как всегда от Дмитрия, много полезной теории, всесторонний анализ вопроса и, конечно же, $mol на первом месте

https://habr.com/ru/company/timeweb/blog/586450

#link #habr #nin-jin #$mol #reactive

Stop catching errors in TypeScript; Use the Either type to make your code predictable

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

Система проверки типов в TS как будто бы просто игнорирует существование throw и catch, не давая при их использовании сильно больших гарантий на уровне типов.

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

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

https://antman-does-software.com/stop-catching-errors-in-typescript-use-the-either-type-to-make-your-code-predictable

#typescript #error-handling #either

Record, replay and measure user flows

В preview версии Google Chrome появилась возможность записывать действия на сайте в сценарий, который затем можно редактировать, повторять и экспортировать как puppeteer скрипт.

В devtools появилась новая вкладка Recorder, в которой можно начать запись и сделать нужные действия на сайте. После остановки записи, сценарий можно запускать, в том числе настраивая тротлинг сети и процессора.

Сценарии также можно редактировать: добавлять новые шаги или изменять существующие.

И как вишенка на торте - сценарии можно экспортировать как puppeteer скрипт.

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

https://developer.chrome.com/docs/devtools/recorder/

#link #google-chrome #puppeteer

TBM 40/52: Why Limiting WIP, Starting Together, Being Less Busy, and Working Together is SO HARD

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

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

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

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

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

В статье также есть полезные видео про WIP-лимиты и другие полезные мысли. Рекомендую прочитать, если вас интересуют процессы и все с ними связанное.

https://cutlefish.substack.com/p/tbm-4052-why-limiting-wip-starting

#agile #kanban #wip

Interactive stories (beta)

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


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

Простой пример использования новой возможности:

export const OpenDialog = () = DeleteCustomerDialog /;
OpenDialog.play = async ({ canvasElement }) = {
  const canvas = within(canvasElement);
  await fireEvent.click(
    canvas.getByRole('button', { name: 'Delete Customer' })
  );
};

Также в примерах кода используется msw для мокирования сети

https://storybook.js.org/blog/interactive-stories-beta

#storybook #auto-tests #testing-library

Why separate test automation teams don't work

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

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

На практике это приводит к тому что:
- Разработчики не задумываются о тестируемости кода = тестировать становится сложнее
- Разработчики делают изменения, которые ломают авто-тесты, но разработчики не поддерживают авто-тесты. Принятие решения "это тест плохой или мы сломали что-то в продукте" требует большого количества времени
- Фидбек от тестов очень долгий. Если у нас есть команда разработки и команда автоматизации тестирования, то, как правило, автотесты пишутся намного позже кода. В итоге эти автотесты дают фидбек о том, что что-то не работает слишком поздно. Возможно даже после релиза.

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

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

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

Автор также делает 1 исключение, в котором выделенная команда автоматического тестирования имеет смысл - это end-2-end тесты. end-2-end тесты могут быть не привязаны к конкретной команде т.к. проверяют все разом (грубо говоря, от верстки до БД), а также могут требовать отдельных компетенций.

https://techbeacon.com/app-dev-testing/why-separate-test-automation-teams-dont-work

#auto-tests #testing

useEffect sometimes fires before paint

Обычно предполагают что useEffect запустится после отрисовки. Но всегда ли это так?

На самом деле это не всегда так. Например в случае, если был вызван useEffect, а потом был вызван useLayoutEffect, обновляющий стейт компонента. В этом случае react вызовет useEffect раньше отрисовки.

Очень интересная статья про работу useEffect в разных условиях

https://thoughtspile.github.io/2021/11/15/unintentional-layout-effect

#react #react-hooks

How to get started with property-based testing in JavaScript using fast-check

Статья про использование подхода property-based-testing с помощью fast-check

Разработчики в основном описывают авто-тесты вида вход = функция = выход. Это авто-тесты на основе примеров (example-based).

Но можно писать другие авто-тесты - property-based. В таких авто-тестах мы должны выделить свойство (property) тестируемой системы. Свойство - это то, что всегда истинно, если все корректно работают. Можно сказать, что это какое-то правило, описывающее тестируемую систему.

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

Самый просто пример, который можно описать в рамках канала:

const sum = (a, b) = a + b

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

const propertyToTest = fc.property(fc.nat(), fc.nat(), (a,b) = {
   const result = sum(a,b)
   expect(result  a).toEqual(true)
   expect(result  b).toEqual(true)
}
fc.assert(propertyToTest, {numRuns: 10000});

И fast-check запустит для нас 10000 тестов с разными числами.

Property-based testing достаточно мощная техника, но которую сложно применить.

Относительное этой статьи видно, что автор срезает углы, описывая преимущество property-based testing и недостатки examples-based testing.

Например, в недостатках example-based тестирования указывается то, что мы можем тратить циклы ЦПУ на тесты, которые нам не нужны. Хотя property-based testing предполагает запуск тысяч тестов т.к. ЦПУ дешевое и мы можем себе позволить проверять кейс тысячи раз.

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

В остальном статья, как обычно у James Sinclair - классная. Если вас интересует тема автоматического тестирования и property-based тестирование - рекомендую к прочтению, но закройте глаза на сравнения с example-based тестированием.

https://jrsinclair.com/articles/2021/how-to-get-started-with-property-based-testing-in-javascript-with-fast-check

#sinclair #auto-tests #testing #property-based-testing #javascript

The strong and weak forces of architecture

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

Если коротко:

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

Обратная ситуация, когда каждая команда вольна выбирать все, что угодно - тоже нежелательна. Как же тогда найти золотую середину?

в MYOB все делится на вертикали, вертикали делятся на домены, в доменах существуют команды.

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

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

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

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

https://martinfowler.com/articles/strong-weak-arch.html

#link #martin-fowler #teamlead #architecture

Powerful Terminal And Command-Line (CLI) Tools For Modern Web Development

Набор тулов для работы в терминале. Показано много разного и интересного.

https://smashingmagazine.com/2021/11/powerful-terminal-commandline-tools-modern-web-development

#terminal #cli #console