Development

Записки мейнтейнера внутреннего ui-kit команды DigitalOcean. Автор описывает практики и прицнипы, которые считает основопологающими для создания хорошего ui-kit'а. Большая часть советов - правильные и хорошие. Часть советов, на мой взгляд, не то что неправильные, просто очень субьективны и в некоторых контекстах могут причинить вред. Философия ui-kit: - Должно быть легко перенести дизайн в код - Компонент должен быть черным ящиком для родителя, использующего его - Решение в ui-kit'е должны быть одновременным очевидными, простыми и правильно в большинстве случаев - Делать плохие вещи должно быть как минимум некомфортно, как максимум - невозможно. Советы: - У kit'а должен быть мейнтейнер или группа мейнтейнеров. Без мейнтейнерства измененися будут вноситься абы как, что через какое-то время сделает использование системы невозможной - Интерфейс компонента должен лаконично представлять варианты использования компонента. Т.е. условно по одним пропсам можно понять, как компонент можно использовать - Компонент не должен позиционировать себя сам - Компоненту следует занимать все доступное горизонтальное пространство. Ограничения по размеру накладывает клиентский код. - Не следует предоставлять API для изменения стилей. Однако, иногда следует все таки добавить для разработчиков для очень редких кейсов максимально неудобное API. И им должно быть очевидно что то, что они делают - неправильно и надо идти заводить задачу на команду ui-kit'а. - Не следует стараться быть максимально похожими на базовые элементы - Избегайте spread оператора в JSX - Композиция компонентов должна быть бесплатной. - Перед удалением чего-то из библиотеки, лучше пару мажорных версий обьявлять это как deprecated - Код-моды позволяют ускорить массовые изменения по коду. - Анализируйте то, как используются ваши компоненты. Лучше делайте это автоматически. - Пишите скриншот-тесты Я прошелся только по заголовкам. Вообще там в каждом пункте достаточно много мыслей про то, почему так стоит делать, с примерами кода. Если вы разарабываете ui-kit - must read.

Сначала Airbnb имели много css-стилей в scss файлах. Но затем они захотели перейти на css-in-js решения для повышения Developer Experience. Существующие решения им не понравились и они написали свою абстракцию над css-in-js решениями react-with-styles. И в целом все было ок, но на текущих обьемах кода текущее css-in-js решение слишком "тяжелое" - от 10% до 20% времени старта приложения тратится на css-in-js решение. Поэтому было принято решение, что нужно поменять текущее решение. Когда-то давно оно подходило, но сейчас контекст поменялся. Был выбор между тремя путями: - Извлечение CSS во время сборки - Написать свой фреймворк - Применить существующий фреймворк Первое решение банально дорогое. Нужно потратить много усилий, но непонятно зачем их тратить. Написать свой фреймворк - к счастью, у Airbnb нет NIH-синдрома. Поэтому они посчитали здраво, что существующие решения уже давно существуют, развиваются, учитывают фидбек комьюниты и успешно обрабатывают разного рода эдж-кейсы. Свой "золотой" инструмент мы не сделаем. Поэтому лучше взять что-то готовое в сообществе и начать это использовать, возможно немного адаптировав под себя. Получается нужно выбрать один из существующих фреймворков. Как кандидаты были выбраны: - Emotion - Treat - Linaria Ребята сделали какие-то перформанс замеры и выяснили, что все решения лучше чем текущее, но Treat и Linaria "лучше" чем Emotion, а Treat немного "лучше" чем Linaria, но Airbnb все равно выбрали Linaria как новый css-in-js инструмент. Linaria позволяет писать css-in-js и при этом умеет извлекать стили из JS во время компиляции, но при этом умеет инжектить критический CSS при SSR, а также умеет во время сборки отбросить дубликаты css-свойств. Когда вы применяете 2 класса в коде, Linaria сама определяет какой итоговый набор css-свойств надо применить и извлекает в сss-класс только нужные. Из преимуществ Airbnb также выделяет улучшение DX за счет того, что в Linaria для описания css используются шаблонные строковые литералы, в которых css-свойства пишутся также, как они пишутся в css (например `flex-direction` а не `flexDirection`) Также airbnb использует atomic-css, но в Linaria нет поддержки для atomic стилей, но при этом Linaria из коробки умеет отбрасывать лишние свойства - что очень удобно. Airbnb законтрибьютили в Linaria решение для atomic-css. Миграция на Linaria была достаточно спокойной: - Во первых, команды сами были мотивированы писать код на Linaria т.к. он был удобнее - Во вторых, инженеры в Airbnb написали кодмоды для автоматической миграции (об этом в статье написано не очень подробно) По перформансу: в результате перевода 10% компонентов, перформанс сайта улучшился на доли процентов - разные метрики стали лучше от 0.25% до 1.6%. Если перевести 90% кода, то должно быть лучше. Итог: - Airbnb мигрирует на Linaria, что одновременно улучшает и перформанс и DX. - Для миграции используется автоматика в виде код-модов - Airbnb при этом законтрибьютили код в Linaria, улучшив его для всех Очень интересная во всех аспектах статья - есть и про миграцию большо количества кода и про выбор инструмента и про оценку эффекта от смены инструменты.

DR - decision record. Это документ, который описывает какое-то принятое командой решение. Описывается контекст, в котором принимается решение, его плюсы, минусы, альтернативы и еще разная полезная информация. Самые известные DR - ADR - architecture decision record. Это когда разработчики описывают какое-то решение по архитектуре. Это помогает в будущем понять, почему архитектура построена именно вот так. Это решает частую проблему, когда человеку непонятно, почему здесь сделано именно так, ведь "с этим же совершенно неудобно работать!". Однако правильно описанный ADR может показать, что в тот момент, когда такое решение применялось - это было лучшим решением из альтернатив. Также бывают другие виды DR. Например, Виталий Шароватов, например, популяризует термин PDR - process decision record. По ссылке находится репозиторий, в котором достаточно подбробно обьясняется, зачем вам нужны DR, как их делать, а также есть куча ссылок на различные материалы по этой теме

Статья в блоге Мартина Фаулера от автора книги про организацию продуктового бэклога (Product Backlog Building technique). Статья посвященна как раз этой технике. Многие команды сталкиваются с необходимостью организации продуктового беклога задач, но при этом не имеют понятия, как делать это правильно. В рамках статьи коротко рассказана техника PBB Для начала, нам нужно определить, кто те пользователи, для которых мы что-то делаем. Эти пользователи должны быть максимально похожи на настоящих пользователей. Затем необходимо определить, что пользователь хочет сделать. Затем необходимо определить, как фича продукта помогает пользователю решить его потребность. Рядом с фичей описываются челенджи и профиты для пользователя. Затем фича уже описывается в терминах Product Backlog Item (PBI) - что конкретно необходимо сделать в продукте, чтобы закрыть потребность пользователя. Из этого мы можем собрать User Story вида: Я, как пользователь, хочу выполнить активность (PBI), чтобы получить профит. Таким образом мы можем собрать все необходимые user story и создать из них беклог. При этом, у этих user story есть четкая иерархия. Пользователь хочет фичу, которая состоит из N user story. Дальше необходимо прописать критеркии приемки для user story (как мы проверим, что она работает) и разбить ее на мелкие технические задачи. Для задач уже не нужно следовать какому-то определенному шаблону. User Story должна быть описана по INVEST. Т.е. история должна быть независимой, обсуждаемой, ценной, оцениваемой, небольшой и тестируемой (перевод терминов из головы, скорее всего где-то слова подобраны некорректно). Но не все истории as is подходят под INVEST. Например, у нас могут быть технологические блокеры (нарушает независимость) или какая-то большая неопределенность (нарушает оцениваемость). В этом случае можно завести специальные виды задач: Enabler. Они призваны разрешить такого рода сложности и привести user story к INVEST. К PBI можно применить практики Definition of Ready (DoR) и Definition of Done (DoD). DoR - описывает критерии для задачи, которым она должна удовлетворять для того, чтобы ее взяли в работу. Например, мы, как команда, можем договорится не брать в разработку задачи для которых не описаны критерии приемки. DoD - описывает критерии завершенности задачи. Например, мы, как команда, можем договорится не считать задачу завершенной, если то что мы сделали не было задокументировано. Полезная статья со ссылками на разные практики для работы с бэклогом. Кажется, что и сама книжка должна быть хороша.

Неплохая статья про планирование целей. В рамках статьи описывается, как подходить к планирование как бизнеса, так и личных целей. В основе описываемого метода стоят несколько практик. Использование диаграммы Виенна для определения целей, которые: - Мы умеем делать - За которые нам заплатят - То что мы хотим делать Это позволяет найти оптимальные цели. Далее для каждой цели расписывается план по ней на следующие: - день - неделю - месяц - квартал - несколько лет Это позволяет одновременно описать и стратегию и тактику в достижении целей. При этом все эти планы необходимо постоянно пересматривать. Это одна из основных идей статьи. Нельзя планировать монументально. Для достижения антихрупкости нужно всегда адаптировать планы под изменяющуюся реальность. В статье также есть отсылки на разные практики (80\20 например). В общем, достаточно инетерсно, если вам нравится то, что рассказывает, например, Максим Дорофеев.

Вышел fastify 4. Из важных изменений: * Ускорение холодного старта * Улучшение перформанса. * Обновление Pino * Задепрекейтили кучу разных способов вызвать listen, оставили основные 3 * Изменили композицию обработчиков ошибок * Пофиксили разные случаи, когда было странное поведение

Webpagetest - это инструмент для анализа скорости работы сайтов. Он очень крутой, но, по моим ощущениям, малоизвестен. Обычно все знают про lighthouse или sitespeed, но мало кто знает про webpagetest У меня был положительный опыт использования webpagetest. Он позволяет замерить как простые сценарии вида "Зашел по ссылке и открыл сайт" так и сложные вида "зашел по ссылке, открыл сайт, ввел что-то поиск, нажал найти, выбрал первый результат". При этом дается полный отчет начиная от базовых метрик типа TTFB, TTI, LT, так и метрики по каждому запросу, который делает браузер, и waterfall диаграмму по запросам и событиям и даже видео. Также в нем можно сравнивать разные запуски между собой. На одной из прошлых работ мы с помощью webpagetest следили, чтобы наши базовые сценарии проходили быстрее, чем на сайтах конкурентов. В общем, очень крутая штука. Но у нее был 1 недостаток. Webpagetest дает очень много инфы, но совсем непонятно, что же с ней делать. Теперь же webpagetest запустили Opportunities & Experiments. Webpagetest сам находит проблемы с загрузкой сайта и предлагает провести эксперимент, который может их решить. Например, у вас грузятся блокирующие сторонние скрипты. Webpagetest может в этом случае предложить вам проверить, как изменится скорость загрузки, если бы скрипты грузились асинхронно. Раньше для такого же эксперимента нужно было: * Уменять подменять контент страницы без изменения кода приложения. Не всегда можно быстро изменить код, задеплоить куда-нибудь, чтобы проверить как эксперимент влияет на загрузку. Поэтому нужно было придумать, как правильно подменить контент * Додуматься до самой оптимизации. В данном примере она достаточно тривиальна и может быть очевидна. Но не все оптимизации настолько очевидны. Теперь же webpagetest может значительно ускорить ускорение сайта т.к. с таким инструментарием очень легко найти проблему и проверить гипотезу, что решение проблемы действительно приведет к значительному ускорению.

Svelvet - библиотека компонентов на Svelte для создания интерактивных флоу диаграм. Красиво выглядит и svelte под капотом. Даже захотелось сделать что-нибудь на основе этого.

Статья из 2008го года про виды возражений. Мне понравилось, что она начинается с хорошего обьяснения, почему большинство комментариев в статьях или на форумах про несогласие с автором. Когда ты согласен с автором, то тебе, по сути, нечего написать. Разве что дополнить информацию автора чем-нибудь, что он не рассмотрел сам. Однако если ты несогласен с автором, то у тебя огромный простор тем для написания комментария. Можно написать, где автор не прав или ошибся, можно написать про нюансы и альтернативные точки зрения, которые авторы не рассмотрел. Можно написать что-то про самого автора. Преобладающее количество несогласия среди комментариев - это нормально. Но проблема в том, что такая коммуникация может перейти в более агрессивные формы. Автор делить такие комментарии на 7 уровней. Чем выше уровень, тем более полезный комментарий для дискусии и тем меньше негатива он вызывает у людей Уровни: - "Ты чёрт". Комментарии не относящиеся к самому тексту, только к автору - Ad Hominem. Это аргумент, который также относится не к самому тексту, а к автору (его авторитету или положению относительно темы текста). Например, "этот чувак всегда говорит булшит, зачем его слушать?" или "это мейнтейнер библиотеки LIB, естественно он будет рассказывать про то, какая она хорошая". Ad hominem не является аргументом против сути т.к. если тебе есть что сказать по сути темы - скажи по сути темы и тебе не нужно будет ссылаться на ad hominem. - Возражение на подачу. Это аргумент уже не против автора, но еще не против его материала. - Противоположность. Это когда комментатор указывает, что факт А на самом деле ложь и все ровно наоборот. Но при этом комментатор не приводит существенных аргументов в пользу своей точки зрения - Контраргумент. Если все предыдущие уровни можно игнорировать т.к. они не содержат в себе каких либо аргументов или доказательств. Здесь же уже должны быть какие-то аргументы и может произойти продуктивная дискуссия. Однако часто люди думают, что спорят о чем-то одном, в то время как обсуждают что-то совсем разное. - Опровержение. Это когда комментатор берет какую-то конкретную мысль автора и опровергает ее, приведя аргументы. - Опровержение сути (en. сentral point). Проблема с предыдущим пунктом в том, что можно опровергать какие-то мелкие несостыковки, но не сказать ничего по сути основной мысли. Эти уровни описывают то, насколько большой шанс, что аргумент был "по делу". У первых трех уровней шансов нет, но чем ближе к последнему, тем больше шанс что несогласие имеет под собой логичное обоснование. Для авторов эти пункты могут помочь правильно реагировать на комментарии. Можно, например, мотивировать комментаторов повысить уровень комментария т.к. возможно комментатор использовал условный ad hominem неосознанно и у него на самом деле есть хорошие аргументы. Для комментаторов эти пункты могут помочь правильно оформить свою мысль. Не факт, что использование только последних уровней сделает обсуждение более результативным, но, по-крайней мере, люди будут менее обиженными или злыми. Что в целом идет на пользу обсуждению. If moving up the disagreement hierarchy makes people less mean, that will make most of them happier. Most people don't really enjoy being mean; they do it because they can't help it.

baymard провели масштабное исследование оптимальной длины строчки текста и выяснили, что оптимальная длина - от 50 до 75 символов Если длина строчки короче или длиньше, то у читателя появляются сложности с чтением текста и восприятием информации. Как следствие, часть пользователей вместо покупки услуги могут просто уйти сайта т.к. не смогли понять ценность сервиса. В целом, конечно, и так было очевидно что если строчки слишком широкие или слишком узкие, то читать текст практически невозможно. Поэтому на многих сайтах, включая habr, на широкоформатных мониторах куча свободного пространства. Но здесь интересны следующие моменты: - Исследование достаточно большое и проводилось на реальных коммерческих сайтах - Есть ссылки на разные рекомендации по оптимальной для читаемости длине текста - Есть кореляция между UX в виде читаемости текста и покупкой сервиса или товара Ну и теперь в войне за конфиг prettier'а у лагеря "коротких строк" есть еще 1 аргумент, теперь подтвержденный исследованием :)

Достаточно обширный туториал про монорепо. Рассказывается про: - что такое монорепо и в чем отличие от монолита (в конце еще сравнивается с микрофронтендами о0) - какие плюсы от использования монорепо - типовая файловая структура монорепозиториев - какие инструменты используются для работы монорепозиториев (что-то для воркспейсов (yarn, npm, pnpm) и что-то для запуска скриптов (lerna, nx, turbo)) - как настроить публикацию ченджлога и пакетов В целом хорошая статья для тех, кто про монорепо слышал только краем уха и не в курсе что это и как это делается. Если вы уже знакомы с тем, что это, для чего это и как это реализуется - вряд ли вы увидите там что-то новое.

Статья про hurl - инструмент на rust для тестирования http серверов. Hurl позволяет писать тесты вида: - сделай запрос - проверь его заголовки - сделай дополнительный запрос - проверь его Автор приводит в плюс скорость его работы, хотя я пока не сталкивался с ситуацией, чтобы тестирование через http-запросы было медленным. Также автор говорит, что его студентам было легче писать тесты, используя hurl. В целом выглядит интересно и стоит запомнить, что есть вот такой инструмент для тестирования, который подходит для интеграционного тестирования и контрактного тестирования. Пример теста на hurl ``` # 1. Get the GitHub user info for @Orange-OpenSource GET https://api.github.com/users/Orange-OpenSource # 2. We expect to get back an HTTP/2 200 response. Also, assert # various things about the Headers and JSON body. Finally # capture the value of the `blog` property from the body into # a variable, so we can use that in the next step. HTTP/2 200 [Asserts] header "access-control-allow-origin" == "*" jsonpath "$.login" == "Orange-OpenSource" jsonpath "$.public_repos" = 286 jsonpath "$.folowers" isInteger jsonpath "$.node_id" matches /^[A-Za-z0-9=]+$/ [Captures] blog_url: jsonpath "$.blog" # 3. Get the blog URL we received earlier, GET it, and make # sure it's an HTML page GET {{blog_url}} HTTP/2 200 [Asserts] header "Content-Type" startsWith "text/html" ```

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

Lerna - она теперь как феникс. Сначала обьявили о том, что проект больше не разрабатывается, затем команда NX взяла на себя мейнтейнерство над проектом, а теперь выходит релиз 5.1-beta в котором Lerna под капотом позволяет использовать NX и тем самым добивается ускорение работы скриптов в 10 раз по сравнению с "без NX", а также в 5 раз быстрее чем Turborepo (еще 1 инструмент для монорепо). Бенчмарки, возможно, немножко синтетические (например, они могут быть специально проверять только кейсы, в которых NX справляется лучше чем turborepo), но для существующих пользователей Lerna это точно хорошее дело.

У Cloudflare имеется достаточно обширная документация по всем их продуктам, которую они держат в open-source. Изначально для публикации документации был выбран Gatsby и он хорошо справлялся в начале пути. Gatsby - это, если утрировать, генератор статичных сайтов. Но в какое-то время у Cloudflare стало 1600 страниц документации и Gatsby уже не позволял быстро разарабывать документацию: Первое ограничение - это архитектура самой документации. Документация Cloudfare состояла из 48 проектов, каждый из которых был отдельным инстансом gatsby-документации. Это, например, делало сложным локальную сборку всего сайта Второе ограничение - время сборки. На таких обьемах gatsby собирал проект около часа. Это неприемлемая скорость сборки, особенно для документации. Поэтому Cloudflare перешли на Hugo. Hugo, если утрировать, это как Gatsby, но написан Go. И он очень быстрый. Одной из проблем при миграции стало то, что много документации было написано на MDX, а не чистом Markdown. Для решения это проблемы был написан скрипт для миграции, который парсил MDX в AST и который затем правил AST на чистый Markdown. В статье есть пример одного из таких скриптов, который находит h1 и a элементы. Как итог, переход был полностью автоматическим и был сделан единомоментно. После переезда на Hugo: - Стало возможным собрать документацию локально т.к. она собирается быстро и это теперь единый проект - В собранной документации стало на 90% меньше Javascript - Перформанс метрики стали намного лучше Это все доступно в опенсорсе и можно посмотреть как было, как стало, и что поменялось. ПР на переезд на Hugo удаляет 950 тысяч строчек кода и добавляет взамен 118 тысяч. Выглядит очень внушительно.

Статья из того что блога, что и предыдущая статья, но теперь про Feature-Driven дизайн. На мой взгляд, статья очень плохо структурирована (ну либо я не понял структуры). Мысль автора растекается по разным темам, переходя с архитектуры на FP, а затем переходит в TDD и обратно в архитектуру. Если очень сухо пересказать, то тезисы следующие: - Feature-Driven архитектура - это когда мы оттакливаемся от бизнесовых фич в определении структуры кода. Это хорошо сочетается с вертикальными слайсами фич - Бизнес-фичи уже несут в себе сложность и мы не можем на них повлиять. Но мы можем повлиять на сложность, которую несут с собой языки и инструменты добавляют. Сложность рождается от состояний и последовательностей (сначала сделай это, потом это, и если звезды сошлись - вот это). Решение для этого безобразия - функциональное программирование. От себя добавлю к этому тезису то, что часто, когда разработчики начинают писать ФП-код, то у них получается императивный ФП. Т.е. как бы и проблему "плохих императивных подходов" не решили, и систему усложнили. - TDD позволяет побороть сложность состояний и последовательностей. При этом автор вносит интересный паттерн, про который я до этого не слышал - двух уровневый TDD. Сначала мы пишем приемочный тест (например на cypress), а затем делаем обычный TDD (юнит-тест = фича = рефакторинг), затем, когда приемочный тест проходит = деплоим. В статье также есть куча ссылок на полезные ресурсы по теме дизайна систем.

Архитектура фронтенда - сложная тема. Во первых, большинство практик по разработке хорошо подходят для backend разработки, но плохо подходят для frontend разработки Во вторых, почти на каждый аспект системы в фронтенде необходимо принимать решение. Свобода выбора такая, что одну и ту же задачу можно решить тысячью способов, перебирая разные подходы и библиотеки. В данной статье автор высказывает свою позицию относительно архитектуры фронтенд приложений. И это позиция очень хороша. Чтиво достаточно долгое - у меня заняло около 40 минут. Но чтиво очень хорошее. В целом автор рассказывает про самые базовые принципы хорошей архитектуры. Они верны для любой разработки, в том числе и для фронтенда. Цель хорошей архитектуры - предоставить способ построить поддерживаемое, тестируемое, гибкое приложение 2 основных принципа: Command Query Separation и Separation of Concerns CQS говорит о том, что нужно разделять получение данных (query) и изменение данных (commands) Separation of Concerns говорит о том, что нам нужно явно разделять ответственность слоев архитектуры. Также в статье подробно рассмотрено как применить эти принципы на практике, при этом нет жесткой привязки к инструментам (кроме React'а) - можно это реализовать и на GraphQL и на redux и на хуках. Кроме этого, автор рассказывает про основные архитектурные паттерны, считающиеся классическими (чистая архитектура, MVC и тд) В целом, статья реально хорошая и рекомендую ее к прочтению всем, кто заинтересован в архитектуре фронтенд-приложений. Кроме того у автора в целом достаточно хороший блог. Лично я подписался.

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

EStimator.dev - приложение от команды гугла, оценивающая, насколько быстрее может быть сайт, если бы он использовал современный JS. Когда ES6, ES7 только появились, они принесли с собой разнообразнчй очень удобный синтаксис и разработчики сразу стали его активно использовать. Однако браузеры не спешили поддерживать веьс этот синтаксис и код приходилось транспайлить в ES5. Некоторый синтаксис транспайлился в очень большие куски кода. Например, обычный async/await транспайлится в огромные, по своим размерам, генераторы (которые не JS-генераторы). Какое-то время в интернете часто можно было найти статьи вида "мы транспайлим в ES5, а пользователей, которые не поддерживают ES6 фичи всего 2%, если мы от них откажемся то мы можем перестать так агрессивно транспайлить = ускорим сборку, код будет понятнее, код будет намного меньше (десятки процентов). Вот EStimator.dev позволяет оценить, насколько меньше кода будут загружать пользователи, если сайт начнет транспайлить код только для свежих версий браузеров. Как я понимаю, схема работы такая: - estimator загружает страницу и скачивает весь ее JS - каким-то образом определяется, что из этого кода можно было не транспайлить - выясняется на сколько килобайт кода можно было меньше отправлять пользователю Я не смог получить из знакомых мне сайтов больше 6% разницы между текущим кодом и тем, который мог бы быть. Также интересно, что инструмент предлагает пожертвовать 5% аудитории Switching to modern JS would reduce that to Xmb, while still supporting 95% of browsers Тем не менее, инструмент весьма интересный. Можно получить прогноз по своему сайту за минуту. Возможно, это кому то поможет принять решение о том, что пора перестать транспайлить в ES5.

Статья про достижение консенсуса методом 5-пальцев (5-Finger consensus). Если мы используем голосование большинством, будь то просто большинство или не меньше 75%, то голосование за решение проходит быстро, но в результате может быть принято нелучшее решение. В противопоставление голосованием большинству существует принятие решения по консенсусу - решение принимается, если все с ним согласны. Этот метод ведет к очень долгим обсуждениям и также не гарантирует принятие лучших решений т.к. условная оппозиция может отказываться принимать предложение, пока не будут удовлетворены ее требования. В статье предлагается метод 5 пальцев. В чем он заключается. Есть 5 оценок: - 1 палец - категорически несогласен - 2 пальца - не согласен - 3 пальца - следую решению группы - 4 пальца - согласен - 5 пальцев - категорически согласен Голосование проводится с помощью поднятой руки с нужным количеством раскрытых пальцев. На первом этапе голосования, если все проголосовали 3-5, то решение принято. Если есть оценка 1 или 2, то участники, проголосовавшие 1 или 2 обьясняют свою точку зрения, почему они несогласны. Если группа принимает возражения и меняет предложение, снова проводится первый этап голосования по новому предложение. Иначе проводится второй этап. На этом этапе, если все проголосовали 2-5, то решение принято, иначе люди с оценкой 1 обьясняют свою точку зрения. Если группа принимает возражения и меняет предложение, снова переходим к первому этапу. Иначе проводится третий этап, в котором решение принимается большинством. Такой метод одновременно позволяет быстро придти к консенсусу и позволяет несогласным повлиять на голосование. Их аргументы 100% будут услышаны, и если другие участники сочтут их важными - они будут приняты или повлияют на голоса других участников. Метод выглядит очень разумным. Заметье, снова предлагается не играть в демократию, в которой все довольны. Решение принимает большинство и оно может игнорировать возражения, если сочтет их несерьезными. При этом метод позволяет гарантировано высказаться 2 раза позиции, которая против решения. Т.е. если аргументы этой позиции весомые, а все участники обсужжения - адекватные люди, то аргументы будут услышаны и учтены.

В докладах на конференциях и в статьях часто можно услышать рекомендацию по типу "у вас должна быть самоорганизация, каждый должен участвовать во всем, все должны быть услышаны". Вы, наверное, участвовали в дискуссиях, где обсуждалось что-нибудь важное и достаточно большим количеством людей. Например, обсуждение нового coding style или выбор инструментария для чего-нибудь (например, для создания форм) составом в 10+ человек. Как правило, в таких обсуждениях нельзя придти к единогласному решению. Поэтому применение принципа "принимаем предложение если все проголосовали ЗА" - не работает. ИМХО, но даже в группе из 6 человек бывает тяжело придти к единому решению. Поэтому лично я не верю в "а давайте все вместе решим\подумаем" и "если кто-то против, то не делаем". Собственно статья про ссылке как раз про это. Приходить к консенсусу, в котором все были бы довольны - сложно. И ведет к ловушке консенсуса (в статье есть ссылка на определение), когда из-за того, что нам нужно принять консенсус, принимаются только безопасные решения и система стагнирует. Также решение принимается очень долго, если мы стараемся достичь консенсуса т.к. для этого необходимы длительные обсуждения. Вместо этого статья предлагает использовать consent вместо consensus. Извините, не могу корректно перевести термины на русский язык. Суть заключается в том, что мы считаем решение принятым, если нет никаких обьективных возражений. Также в статье предлагается не учитывать мнений людей, которые не обладают нужными знаниями, либо на которых не влияет решение, которое группа пытается принять решение. Также в статье есть интересные ссылки на связанные материалы.

В статье рассматриваются антипаттерны для скриптов, написанных с puppeteer. В некоторых пунктах достаточно подробно описаны причины, по которым описанное действие является антипаттерном. Хотя где-то треть пунктов очень странная. По-крайней мере я не представляю чтобы люди случайно научились такому паттерну. Например, использование отдельного html-парсера при использовании puppeteer кажется мне весьма странной идеей, когда мы уже запустили браузер и он сам отлично парсит html. Список антипаттернов: - Использование waitForTimeout - Предположение, что puppeteer API работает как браузерное API (разобрано на примере click) - Не использование domcontentloaded, когда это подходит - Не блокирование загрузки изображений и ресурсов - Избегание page.evaluate, когда он подходит - Использование селекторов из dev-tools as is - Игнорирование возвращаемого значения waitForSelector - Использование отдельного html-парсера - Использование puppeteer там, где есть более подходящие средства Пункты, порой, немного странные, но да ладно. Для меня интересными пунктами оказались блокировка изображений и про возвращаемое значение waitForSelector По waitForSelector я банально не знал, что он возвращает элемент, который мы ожидаем. Видимо тут сыграла привычка из более старых инструментов для тестирования в браузере, где ожидание элемента и его получение - 2 разных метода Про блокировку изображений и ресурсов я никогда не задумывался, но это действительно может значительно ускорить скрипты, если изображение и ресурсы некритичны

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

Статья про то, что схлапывать дерево коммитов 1 коммит - это антипаттерн. Практика squash коммитов обычно используется для: - Сделать 1 коммит в фиче-ветке перед ребейзом на мастер\отправкой на код-ревью - Сделать 1 коммит из фиче-ветки при вливании кода в мастер Бывают и другие применение, но эти, кажется, основные. Я сам лично не вижу большой пользы от *правильной* истории в гите (атомарные коммиты, описание тела коммита на каждый коммит, гайд по правльному именованию). Мне лично важно чтобы были: - Ссылка на задачу, с которой связан коммит - Не слишком большой обьем изменений - Боле-мене понятное имя коммит-месседжа Мнение в статье: - Squash - антипаттерн и его никогда не следует использовать - Те, кто использует squash чтобы история была чище после мержа в мастер могут пользоваться встроенным в git функционалом Особенно забавно то, что буквально во 2-м абзаце статьи встречается People have strong opinions about this. The thing is that my opinion is the correct one. В целом статья - холиварная, поэтому там 66 комментариев, где есть лагерь чистой истории и лагерь честной истории. Мне в статье понравилось то, что там описаны нюансы работы гита, а именно: - Гит трекает контент, но умеет быстро делать диф между контентом - Squash от не-squash мерджа отличается тем, что при squash-мердже есть один родительский коммит из мастера, а при не-squash также сохраняется ссылка на родителя из ветки. В статье это показано через консоль гита. - В гите есть возможность показывать дерево коммитов учитывая только первого родителя, что позволяет вывести дерево коммитов, где были мержи без squash, так, как будто squash был использован.

"Вам не нужен UI-фреймворк" - статья, развенчивающая миф о том, что стоит только взять UI-фреймворк и сразу все станет хорошо. А если не стало - ну значит надо было найти *правильный* UI-фреймворк. Автор проходится по основным причинам, почему фреймворки вообще используют и описывает свое видение того, как правильно делать. Когда люди хотят использовать UI-фреймворк, они хотят получить: - Интерфейс, который выглядит *профессионально* - Быструю разработку т.к. не нужно заниматься разработкой базовых компонентов с нуля - Готовые компоненты для сложных кейсов - модалки, дропдауны и тд. Но есть нюансы Чтобы получить *профессиональный* интерфейс, нужно чтобы его придумывал профессионал. И тут уже не так важно, будет это UI-фреймворк или нет. Хотя использование UI-фреймворка может даже помешать. Использование UI-фреймворка действительно ускоряет разработку, но только в начале. Затем разработчики начинают тратить много времени чтобы натянуть сову на глобус, т.е. возникает ситуация, когда API UI-фреймворка не ложится на то, как надо сделать. И в итоге приходится заниматься профессиональным костылированием. С модалками и дропдаунами поинт здравый т.к. действительно сложно учесть и доступность и ограничения платформ и разницу в работе браузеров при реализации таких компонентов. В целом автор советует следующее: - Если вам нужно быстро собрать что-то простое, то действительно проще взять готовый UI-фреймворк. Например, вы делаете интерфейс для внутреннего использования (какая-нибудь админка) - Вы делаете короткие проекты, где на создание своего UI-фреймворка нет времени. - Изучите то, как создавать дизайн. Для создания *профессионального* интерфейса недостаточно иметь блоки, из которых он собирается. Нужно иметь представление как такой дизайн создавать. - Пользуйтесь фреймворками, которые предоставляют паттерны, но не UI-целиком. Например Chakra-UI и Tailwind.

Stripe описали опыт единоразового перевода 3.7 миллиона строк Flowtype кода на Typescript. В компании давно использовали Flowtype для описания типов. Когда-то Flowtype был многообещающей библиотекой чекинга типов. Теперь же она уже практически не используется. Как следствие, тулинг вокруг Flowtype стал неудобен и начал замедлять разработку. Понятно, что пора было переходить на Typescript, но как перенести 3.7кк строк с Flow на Typescript? Кор-команда Stripe изучила опыт Airtable и Zapier и в итоге использовала наработки Airtable, которые в свое время опубликовали codemod для перевода кода с Flowtype на Typescript. Им пришлось дорабатывать этот тулинг под свои кейсы т.к. кое где генерировался некорректный код, а где-то генерировался код, который Typescript считался небезопасным с точки зрения типов. В итоге проект переехал на typescript с 37000 ошибок TS, которые были заигнорированы. В оригинальном Flowtype коде было 5к ошибок. Codemod решил не все проблемы. Например, также были найдены захардкоженные ссылки на js и также пришлось поправить jest snapshot'ы т.к. они ссылаются на имя файла с тестами. В остальном, все прошло гладко и команда Stripe получила буст продуктивности из-за использования Typescript'а благодаря отлично поддержке в IDE. Stipe, кстати, опубликовали свой тулинг. Ссылка есть в статье Что следует вынести из этой истории: - Рефакторинг большого проекта должен быть автоматизирован. Невозможно это сделать в ручном режиме. - Если вы еще на Flowtype, то уже давно было пора переезжать на Typescript

Когда мы говорим о производительности загрузки сайта, то, как правило, все упирается в загрузку и работу JS. Свой код мы еще худо-бедно можем как-то оптимизировать, но мы не можем повлиять на сторонний код, который иногда необходимо грузить синхронно и который останавливает парсер браузера из-за того, что скрипт идет в DOM. Яркий пример таких скриптов - скрипты аналитики. Интеграция аналитики позволяет нам получать информацию о том, как пользователи пользуются сайтом, но с другой стороны они могут сильно ухудшить перформанс загрузки сайта. Для решения это проблемы была написана библиотека partytown. Она позволяет выносить такие скрипты в web-воркеры, из-за чего они перестают занимать главный тред JS в браузере. Но тут возникает проблема, что из web-воркеров недоступен DOM, который может быть нужен скрипту в веб-воркере. Библиотека решает эту проблему очень элегантным образом - все запросы в DOM из воркера оборачиваются в синхронный xhr, который обрабатывается как DOM запрос в главном треде и результат потом возращается как ответ xhr в веб-воркер (надеюсь я правильно понял схему). partytown реализует уже известную концепцию выноса тяжелого кода в веб-воркеры для ускорения работы сайта. Выглядит интересно. Вроде легко интегрировать и при этом можно сразу нанести пользу. Рекомендую попробовать как гипотезу на пару вечеров на своем проекте, если у вас есть проблемы с 3rd-party скриптами.

Вышел 1.0.0 релиз тулинга, позволяющего: - запускать JS из Python - запускать Python из node.js Причем делается не просто как exec из nodejs API, а имено импорт сущностей одного языка в другой язык. Выглядит интересно, хотя очевидно, что это очень нишевая история и у нее куча ограничени

Статья, рассказывающая про опыт использования cypress для написание е2е-тестов, а конкретно про проблемы, с которыми столкнулась команда и как она их решала и, заодно, делала продукт лучше в плане доступности

Вышел playwright 1.22 в котором добавили супер крутую фичу - возможность тестировать компоненты в playwright. Если вы следите за cypress, то у них давно был описан концепт вида "просто импортируй в код файл компонента, отрендери его и пользуйся cypress для тестирования компонента". Сейчас, если я правильно помню, этот концепт находится в бете. И вот playwright реализует ту же самую идею у себя. Но, в отличии от cypress - playwright более низкоуровневый и быстрый (мое имхо) инструмент. Возможность, пока что, добавлена как экспериментальная. Мое мнение, что тестирование вида - импортируем компонент, рендерим его в браузере, взаимодействуем с ним - это очень крутая схема, если удасться добиться стабильности и большой скорости работы таких тестов.