Development

Сложно поспорить с тем, что хорошая документация ускоряет работы разными способами (упрощает получение знаний, ускоряет процессы за счет их описания, ускоряет разработку за счет описания контекстов, бест-практисов и все такое). Но при этом в большинстве команд документации уделяется очень малое время. Ситуация примерно как с рефакторингом. Все понимают, что это важно, но все сфокусированы на бизнес-задачах. В данной статье дается несколько советов по тому, как поставить процесс документирования в команде. 2 стратегии для изменения процессов: - Документируйте то, что приносит много боли. Люди часто что-то спрашивают в чатиках ? Есть какой-то процесс, занимающий много времени и который лежит целиком в головах людей? Опишите это! - Вся новая документация должна быть безупречной. Смиритесь с тем, что документация к старым системам будет плохой. Возможно вы с этим уже жили годами, так что даже не заметите разницы. Эти стратегии следует комбинировать друг с другом, принимая решения о том, что и как документировать. Также рекомендуется выделить людей, которые бы следили за тем, что эти стратегии соблюдаются и которые бы говорили всем, где и как следует описать документацию.

Scrum, наверное, самый популярный процессный фреймворк, используемый в разработке. Сама идея Scrum, в целом, может работать в определенных контекстах. Но Scrum применяют вообще везде, но не потому что это надо, а потому что это модно. "Все используют Scrum и мы тоже будем" (с). В данной статье подчеркиваются проблемы Scrum, когда он используется не к месту: - 2х-недельные спринты являются стандартом и при этом не подходят большинству команд. В итоге за 2 недели не удается добится какого-то значимого результата, большие пользовательские истории режутся на микро-истории, которые сами по себе не важны. В итоге фокус сдвигается на завершении микро-историй, а не на решение проблемы пользователя. - Часто в спринтах попадает "основная" задача и сколько то задач с поддержки (технический долг, баги). Это ведет уничтожению фокуса команды (на мой взгляд, вся идея Scrum строится как раз вокруг фокуса всей команды на одной заддачи, и за счет этого как раз и достигается хорошая производительность). - Ритуалы, требующие синхронизации всей команды, не помогают, а мешают. Автор также в конце статьи приводит свою альтернативу. Предлагается иметь большую итерацию разработки (2 месяца), короткую итерацию между большими итерациями разработки (1 месяц), в рамках которой проводится анализ, фикс багов, тех долга и тп. Этот процесс решает вышеописанные проблемы: - есть 2 вида итераций, в рамках которых фокус разных. В длинной итерации фокус на решении какой-то бизнес проблемы. В короткой итерации фокус на стабильности системы. - Итерации длинные. Не призываю слепо следовать советам из интернета по поводу процессов, лучше все таки подумать, какой процесс будет оптимален в вашей команде. Но можно использовать поинты из статьи для улучшения своих процессов.

Короткая статья, рассказывающая про новый хук useEvent и проблемы, которые он решает.

Google собирает информацию по производительности страниц с миллионов открытий страниц в браузере Google Chrome. Эта информация есть в свободном доступе, а значит ее можно использовать для разного рода анализа. В этой статье эти данные используются для анализа корреляции между производительностью сайта и фреймворком, который он использует. Очень занятная статья. тлдр: - сайты без использования фреймворков в среднем быстрее - в анализе большинства метрик производительности все фреймворки выдают +- одинаковую цифру. Однако в некоторых замерах некоторые фреймворки могут сильно отличаться. Например, в части метрик Angular сильно отстает от вообще всех фреймворков Какие выводы можно сделать: - Не особо важно какой у вас фреймворк. Важно то, насколько вы нацелены сделать быстрый сайт и насколько хорошо вы умеете это сделать. - Сайты без фреймворков открываются быстрее. - Есть очень интересные способы использовать доступные в интернете данные о сайтах и пользовательских сессиях

Неплохая статья про то, почему fastify должен восприниматься как стандарт для создания вбе-серверов на nodejs вместо express Собственно вся статья сравнивает fastify с express. Когда-то мне не хватало именно такой статьи чтобы ссылаться на нее при рекомендации взять fastify вместо express или koa. В статье упоминается что fastify лучше чем express потому что: - Более адекватное API для расширения функционала - Перформанс - Некоторые вещи есть пря внутри fastify Того, чего нет в статье, но что я оценил в свое время в fastify - typescript first - встроенное апи для тестирования сервера. Вместо того чтобы приседать с поднятием сервера через какой-нибудь supertest, в fastify из коробки есть возможность эмулировать обработку запроса, и эмулированный запрос пройдет все стадии обработки также, как и настоящий

Расширение для vs-code и также сайт, который позволяет перевести непонятные TS ошибки на человеческий язык. Как это работает. Например, вы ловите ошибку ``` Conversion of type 'string' to type 'string[]' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first. ``` ts-error-translator переведет это в ``` You can't use 'as' to convert string into a string[] - they don't share enough in common. ``` Конкретно эта ошибка в целом понятна и можно было бы не переводить, но инструмент полезный т.к. наверно уже сталкивались с TS ошибками, которые занимают пол-экрана и с которыми совсем непонятно что делать. Сложно поверить, но в 2017м году, когда была конкурентная борьба между flowtype и typescript, typescript очень сильно выигрывал у flowtype по понятности ошибок. Flowtype выводил ошибки а) совершенно непонятные б) не в том месте. Например, вы неправильно используете тип, а flowtype выводит ошибку не там, где тип используется, а там где он обьявляется. ts-error-translator Ввыглядит функционалом, который должен быть нативно внедрен в сам TS или vscode

Вышла версия 1.0 веб-фреймворка вокруг React с SSR. Я бы не писал в канале об очередном фреймворке вокруг react, если бы не одно "но". Этот фреймворк построен вокруг deno. Возможно я пропустил другие такие фреймворки, но решил на всякий случай схоронить ссылку на этот. Deno экосистема становится все шире и шире. Также предлагаю вам пройти на главную страницу проекта и восхитится оформлением сайта. Гифки и текст так наложены друг на друга что получается "так плохо, что даже хорошо".

Zag - библиотека с реализацией популярных паттернов для компонентов. На самом деле, это очень плохое описание, но я не могу подобрать слова чтобы сделать лучше. Zag предоставляет готовую логику для разных компонентов типа выпадашек, умных инпутов, модалок. Т.е. zag предоставляет логику, а стилизацию и компоновку можно сделать на своей стороне. Это само по себе звучит очень станно, но настоящая изюмнка Zag в использовании конечных автоматов (Finite State Machine). Т.е. библиотека предоставляет не просто функции или хуки для реализации паттернов, а предоставляет полноценный конечный автомат, использование которого очень похоже на x-state. По-моему мнению, конечные автоматы очень сильно подходят для описания UI и UI-логики (а на ближайшем codefest я об этом даже немножко расскажу). Прикольно что zag реализует эту идею. Хотя я слабо представляю как использовать zag в своих проектах.

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

Storybook в своем блоге опубликовал статью про скорость сборки storybook разными бандлерами: vite и webpack. Для замеров производительности был взят реальный проект - IBM Carbon Design System. Былипроверены множество метрик: - время до первой отрисовки истории в браузере при холодном старте dev режима - то же самое, но с использованием кешей предыдущего запуска - время prodction сборки - размер собираемых ассетов - время отрабатывания HMR и всего тестировалось 5 конфигураций сборки: - webpack 4 - webpack 5 - webpack 5 с оптимизациями lazy compilation и code splitting - vite - vite c code splitting Там достаточно много цифр, но как итог я бы выделил, что vite с оптимизациями и webpack5 с оптимизациями намного быстрее всех остальных вариантов и примерно одинаковы между собой. На самом деле есть разница в разных кейсах (где-то выигрывает webpack5, а где-то vite), но, по большому счету, разница не так велика.

Дэн Абрамов добавил RFC на новый хук useEvent. Если совсем утрировать, то это как useCallback, но без приседаний с мемоизацией. Т.е. обычно, чтобы правильно использовать useCallback, мы должны передать все, что используется внутри useCallback как зависимости, а значит на каждое изменение зависимости - будем изменяться и ссылка на функцию, что может привести к лишним ререндерам. У этой проблемы были разные воркераунды, но теперь команда react решает эту проблему на уровне инструменте с помощью нового хука. По ссылке можно прочесть обсуждение и сам RFC.

После того как публичные и приватные свойства класса вошли в стандарт, команда V8 начала работу над оптимизацией их реализации в движке. До оптимизации, реализацией полей классов была намного медленее реализации заполнения полей обьекта. В новом v8 заполнение полей объекта остается более быстрым вариантом, но разница уже минимальна. В статье приводятся графики и обьяснение оптимизации и внутренней имплементации полей класса.

Netlify анонсировали поддержку нового вида serverless - edge functions. Как я понял, netlify гарантируют, что эти функции, как cdn, будут расположены как можно ближе к пользователям. Но новость в канале не потому что Netlify придумала новый термин для лямбд, а потому что рантайм для этих функций - Deno! Deno, по-немногу, превращается из "интересный концепт" в то, что можно использовать в большом продакшне.

Большая статья о том, как Dropbox выстраивали отказоустойчивую инфраструктуру. В 2020м году Dropbox упал на 47 минут. Для такого большого бизнеса это очень долго и очень дорого. С тех пор компания активно занималась тем, чтобы не допустить подобного снова. Статья рассказывает о предпринятых шагах и о внутренней кухне. Мне это сложно пересказать, лучше самим почитать, если вам интересно. Как итог, 18 ноября 2021 инженеры Dropbox решили сделать финальный тест своих изменений в инфраструктуре. Они взяли и отключили сеть на 30 минут в датацентре в Сан-Хосе. Т.е. они добились того, что полное отключение дата-центра от общей сети на 30 минут никак не повлияло на бизнес-показатели.

Небольшая история от RudderStack о том, как они ускорили запуск nodejs приложения в разы. Если коротко, то ребята используют nodejs как бекенд, но при деплое он запускается около 5 минут, что очень плохо. Просто представьте, что вы деплоете код, а узнаете о том, что он неправильно работает только через 2 минуты. А потом еще катите фикс и, не смотря на вашу скорость делания самого фикса, ждете еще 2 минуты пока новая версия приложения попробует запуститься. Вообще, это звучит довольно странно т.к. nodejs имеет один из самых низких показателей времени старта приложения на AWS (согласно доклада чувака из Amazon на frontendconf) У ребят оказась проблема в том, что для запуска приложения они использовали ts-node. ts-node - это либа, которая запускает node.js и "учит" его транспайлить typescript код, позволяет запускать nodejs на typescript без предварительной компиляции. Это очень удобно, но очень медленно. Если у вас много кода, то приложение перед запуском будет вынуждено его весь скомпилировать. У меня есть пара пет-проектов и я раньше тоже не парился с компиляцией ts кода и просто деплоил docker-образ, в котором запускался ts-node. Для моих пет проектов не страшно иметь небольшую задержку при запуске. Но оказалось, что это также сьедает кучу памяти, а мой VPS имеет ее не так уж много. В общем, не используйте ts-node в продакшне - это замедляет запуск приложения и увеливает потребление памяти. Инженеры из RudderStack тоже это поняли, даже сделали профилирование. Они попробовали предварительно скомпилировать код с помощью tsc и результат им не понравился. Конкретно, там есть проблема с тем, как tsc компилирует импорты. Тут я бы сказал, что надо просто взять babel\swc и немного подконфигурировать этот сетап и стало бы просто замечательно. Но ребята взяли webpack. Возможно у них была сложная ситуация с кастомными правилами транспиляции кода. В этом случае действитеьно легче взять webpack. Как итог, заменив ts-node на webpack ребята значительно ускорили свое приложение. Что в этой истории интересного: - Не надо использовать ts-node в продакшне - Посмотрите, как они запрофилировали запуск приложения - Посмотрите, как они искали решение и на основе чего их отбрасывали Эта история - хороший пример поиска и решения проблем.

Оказывается есть библиотека Remotion, которая позволяет делать видео-ролики с помощью React. И недавно вышел релиз 3.0, в котором поддерживается работа рендера в AWS. Сам инструмент базируется на идее, что можно взять React, HTML и CSS и использовать его возможности для создания видео, вместо того чтобы изучать различные видео-редакторы (и возможно покупать их лицензии). Выглядит, на самом деле, бомбически. С одной стороны это безумие (зачем использовать React для рендера видео?), а с другой - весьма логичный шаг. С помощью remotion можно использовать все блага ращработки в целом и веб-стека в частности для создания видео. Например, вы можете реализовать DRY, хранить историю в git'е, использовать готовые наработки т.к. теперь ваше видео - не слои в видео-редакторе, а самый настоящий код. Всем рекомендую посмотреть. Я лично слабо представляю для себя сценарии использования, но выглядит как нечто полезное в узких сценариях. Ну и очень интересна сама идея - использовать веб-разработку для создания видео.

Lerna - один из первых тулов для разработки монорепо в JS-экосистеме. Lerna давно не получала обновлений, но теперь в README добавили инфу о том, что проект не находится в стадии активной разработки и следует переехать с lerna на альтернативы press F to pay respect

Meta выпустили фреймворк для создания текстовых редакторов. Звучит немножко странно, но выглядит очень хорошо. Ребята сделали супер-быстрый редактор текста и примочки к нему, которые позволяют реализовывать кастомный WYSIWYG редактор, редактор для совместного редактирования текста, поля ввода с ссылками, хэштегами, кастомными emoji. В общем, если вам нужно сделать крутое и умное поле ввода - посмотрите на lexical.

Вышел Jest 28 и в нем даже есть несколько интересных фичей. Первая - возможность писать тесты на ваши .d.ts файлы. Для этого под капотом ихспользуется либа tsd. Эти тесты работают следующим образом: - вы в тестовом файле импортируете тип из .d.ts - пишете использования этого типа - tsd проверяет, что нет typescript ошибок у этого кода Также из знаменательных фичей - работа над перформансом Добавлен jest-light-runner, который работает намного быстрее. Пишут, что есть нюансы использования, но должно хорошо работать для простых модулей. А также появилась возможность разбивать тест-сьют для запуска в параллель на разных машинах. Это позволяет значительно ускорить время прогонов юнит-тестов, если у вас есть эти несколько машин. Самое простое применение выглядит так: - у вас тесты бегут 10 минут в одной джобе в CI - вы делаете 4 параллельных джобы и в каждой запускаете jest с флагом --shard и значениями 1/4, 2/4, 3/4, 4/4 - каждая джоба берет себе разные четверти тестов. - теперь ваши тесты бегут около 2 с половиной минут Это, кстати, отличный пример KISS-решений. Вместо того, чтобы изголяться с системой master-workers, где master делит сьюты и говорит воркерам, какие тесты запускать, а потом получает от них результат, склеивает и принимает решение о том, прошел прогон или нет, ребята просто сделали детерминированный алгоритм выбора тест-кейсов по строке вида "N/M" и закрыли 99% кейсов, для которых нужно разбить прогон на несколько машин.

Если вы когда-нибудь писали тесты на jest с применением jsdom, то, вероятно, вы знаете, что это и очень крутой способ для написания тестов т.к. мы можем проверить что компоненты работают т.к. мы от них хотим, но с другой стороны это отличный, модный, навороченный дробовик для выстрела себе в ногу. Не редка ситуация, когда, казалось бы, на написание простого тест вида "выбери значение в селекте из нашего ui-kit" нужно потратить 2-4 часа. А потом при изменениях в функционале тест падает и не разобрать, почему он упал. Да и дебажить неудобно. Часть этих проблем может снять jest-preview. Библиотека отрисовывает в браузере ту верстку, которую вы пытаетесь протестировать в jest-тесте. Выглядит круто. Из коробки поддержка react + react-testing-library, но обещают что должны работать любые фреймворки.

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

Node 18 официально зарелизилась: - новый V8 - test-раннер вшит в nodejs - в NodeJS теперь есть fetch

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

madge - еще одна либа для анализа зависимостей в JS проекте и также умеет строить графы и их анализировать. Тоже весьма интересная штука для анализа зависимостей в проекте

dependency-cruiser - библиотека для анализа зависимсотей в JS коде. Умеет анализировать код, строить граф зависимостей и выводить его в разных форматах (например, json и svg график) Также можно в конфиге настраивать правила для проверки. Например, можно запретить циклические зависимости и некоторые виды импортов в приложении. Например, когда мы следуем feature-based архитектуре и хотим гарантировать, что фичи могут использовать друг друга только через публичный интерфейс, обьявленый в index файлах. Лично я недавно использовал это библиотеку для анализа зависимостей в одном нашем рабочем легаси пакете с целью найти модули, которые можно удалить или влить в приложения. Оказалось достаточно удобно, хотя и не без нюансов.

IndexedDB - это база данных, созданная для управления с помощью JS и встроенная прямо в браузер. Если у вас есть задача хранить большое количество данных, шарить их между вкладками и сохранять их персистентно (т.е. данные не теряются при закрытии браузера) - то стоит посмотреть в сторону IndexedDB, вместо того, чтобы придумывать схемы вида redux = LocalStorage и героически решать проблемы от подобных связок. Лично я никогда не смотрел в сторону IndexedDB т.к. в рабочих приложениях обычно хватало самых простых решений, а сам IndexedDB - слишком низкоуровневый. Но вот в комментариях на хабре наткнулся на ссылку на Dexie - библиотека для удобного использования IndexedDB. Она дает легкое в использовании API для работы с IndexedDB, а также имеет биндинги к популярным фреймворкам (react, vue, angular, svelte). Есть даже подобие реактивности - dexie позволяет следить за данными в базе.

Хорошая статья от James Sinclair про функциональную композицию. Каждый из нас использует композицию. Каждый раз, делая функцию, которая вызывает другие функции - это композиция. Но ее можно делать лучше: проще одновременно и для того, кто будет читать код, и для того, кто пишет. Для этого нам нужны дополнительные функции для композиции, которые, как правило, есть уже готовые в любой библиотеке для ФП: compose, pipe, flow. В статье очень круто показывается как реализовать такие функции и в чем их разница. Такое применение композиции, кроме простых преимуществ вида: "код стало проще читать" переводит код из "описываем алгоритм через работу с переменными" в "описываем алгоритм через связь функций", что делает код более устойчивым к ошибкам и рефакторингам. Также, применение композиции функций - еще 1 способ обдумывания реализации.

Интересная статья про изменение продуктивности, которое произошло с начала всеобщего тренда на удаленку. Недавно Microsoft опубликовали исследование, в котором говорится, что "белые воротнички" имеют 2 пика продуктивности - до обеда и после обеда. Но также с начала пандемии появился еще 1 мини-пик поздно вечером. Если раньше, условно, люди могли работать с 9 до 17, то теперь наблюдается тред на работу с 9 до 22 (последний пик как раз в 22 часа). Также, в условиях удаленной работы количество митингов, с начала пандемии, увеличилось в 3 с половиной раза. Из-за этого приходится откладывать "настоящую" работу на по-позже, так и возникает третий пик. Почему так происходит? Одна из проблем - из-за удаленки теперь нет четкого разграничения дом-работа. Если при работе в офисе рабочая активность была привязана к офису, то теперь это не так. В статье не дается ответов, что с этим делать, кроме как начать делить коммуникации на синхронные (требуют митинга) и асинхронные (можно решить чатом, почтой и тд).

Вслед за введением в NodeJS встроенного тест-раннера, хотят внести также и код для распарсивания аргументов командной строки

Warp - очень быстрый терминал для MacOS, написанный на Rust. Из интересных фич: - вставка сниппетов - редактирование поля ввода в терминале как кода. Т.е. доступны, например, мультикурсоры - поиск сниппетов по запросу с помощью "AI" Немножко поигрался - работать в терминале действительно приятно и смузёво.