Simple monorepos via npm workspaces and TypeScript project references

Статья от Dr. Axel Rauschmayer про монорепы с использованием npm, который умеет в workspaces, и примером правильной настройки tsconfig в рамках монорепы

https://2ality.com/2021/07/simple-monorepos.html

#link #npm #typescript #monorepo #frontend #web-development

Abracadabra, refactor this! - Visual Studio Marketplace

Расширение для vscode для автоматического рефакторинга JS и TS кода. Некоторые рефакторинги выглядят весьма впечатляюще

https://marketplace.visualstudio.com/items?itemName=nicoespeon.abracadabra#abracadabra

#link #typescript #vscode #frontend #web-development

Incremental note-taking

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

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

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

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

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

https://thesephist.com/posts/inc

#link #knowledge-managment

Social loafing - Wikipedia

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

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

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

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

Одна из причин возникновения эффекта: чем больше группа, тем менее виден эффект от усилий конкретного человека.

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

Эффект также перекликается с другими психологическими теориями, например с Social identity theory

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

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

https://en.wikipedia.org/wiki/Social_loafing

#link #peopleware #psychology

Эволюция рабочего места: от ноутбука на кухне до работы стоя

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

https://habr.com/ru/company/dododev/blog/570078

#health

Beat the bystander effect with minimal social pressure

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

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

Статья предлагает бороться с эффектом свидетеля следующим образом:
- Предлагайте сделать целевое действие конкретным людям. При этом ответ "нет" не должен игнорироваться
- При поиске добровольца ограничивайте время поиска. Например, "ищу добровольца для Х следующие 3 дня, потом выберу кого нибудь"
- Предлагайте другого человека, если это пойдет на пользу процессу
- Даже "эй, Боб, помоги мне найти того кто сделает Х" лучше чем "Ищу добровольца чтобы сделать Х"

http://acritch.com/bystander-tactics

#link #psychology

beachball

Тул для удобной автоматической публикации npm пакетов от Microsoft.

- Синхронизирует гит и нпм
- Генерирует ченджлоги
- Сам поднимает версии по семверу
- Работает как с моно-репо и так и single-репо
- 0-config

https://microsoft.github.io/beachball

#link #monorepo #microsoft #npm #web-development #frontend #library

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