Your Cache Headers Could Probably be More Aggressive

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

Автор разбирает 2 простых сценария: кеширование до изменения и вечное кеширование.

Если у вас есть ресурс, который иногда меняется, то имеет смысл выставить следующее значение заголовка Cache-Control: public, max-age=0, must-revalidate. В этом случае браузер при повторном указании ресурса будет спрашивать у веб-сервера, изменился ли указанный ресурс или нет. И если не изменился - сервер ответит 304 кодом, что означает, что браузер может взять контент из кеша. В этом случае выигрывают все - пользователь не скачивает лишний трафик, не ожидает загрузки. Сервер же не тратит свои ресурсы на раздачу файла

Если у вас есть ресурс, который никогда не меняется (например, JS-статика с хешом в имени), то в заголовок можно передать public, max-age=31560000, immutable.

public означает что ресурсы может быть закеширован как на устройстве так и на посредниках
max-age=31560000 указывает, что ресурс кешируется на 1 год
immutable означает, что браузер не должен перезапрашивать ресурс, если он уже есть в кеше.

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

https://www.macarthur.me/posts/more-aggressive-cache-headers

#development #caching #performance

💥 Introducing Skott, the new Madge!

Skott - библиотека для анализа графа зависимостей. Альтернатива Madge. Авторы обещают что она работает очень быстро.

Можете попробовать на своем проекте запустив skott --displayMode=webapp --trackThirdPartyDependencies --ignorePattern="test/**/*". Возможно, потребуется поправить команду чуть под себя

Я попробовал на текущем проекте. Анализ действительно более менее быстрый, но воспользоваться результатом в веб-UI я не смог т.к. там ничего непонятно и на графе из 1300 узлов он подлагивает (первый рендер занимает где-то полминуты). Так что я знаю что у нас 43 циклических зависимостей, но Skott, как почтальон Печкин, мне их не покажет.

https://dev.to/antoinecoulon/introducing-skott-the-new-madge-1bfl

#development #javascript #library #graph #dependencyAnalyze

JavaScript триггеры и функции появились в Redis 7.2

В Redis 7.2 появится возможность писать внутренние триггеры и функции на JS. Раньше поддерживался только Lua. Redis - это СУБД для быстрой работы с данными key-value. Оказывается там есть возможность не просто складывать и читать данные, но еще и делать кастомную логику на языке программирования

Функции и триггеры покрывают разные кейсы. Функции - это про быструю обработку данных на стороне СУБД. Например, я хочу получить ФИО всех клиентов, но вместо полных имен - инициалы. Можно выгрузить всех клиентов в приложение и там сделать обработку, а можно сделать функцию, которая сразу вернет готовые данные. Триггеры же позволяют подписаться на события в БД и реагировать на них. Например, дополнять всем данным определенного типа колонку lastUpdated

Еще из интересного, что redis предусмотрели, что разработчики захотят делиться друг с другом скриптами, поэтому добавили возможность конфигурировать этот код

Redis используют движок v8 для запуска JS. Жаль, конечно, что не приводятся данные по перформансу этого всего (и сравнительный анализ с решением на lua например). Но, тем не менее, круто что появилась возможность писать такой функционал на JS

Примеры:

Подсчет количества слов во вставляемых данных

function wordsCounter(client, data){
text = client.call('hget', data.key, 'content');
words = text.split(' ').length;
client.call('hset', data.key, 'cnt', words.toString());
//This log is for demo purposes, be aware of spamming the log file in production
redis.log('Number of words: ' + words.toString());

Логирование изменения данных
function alertUserChanged(client, data) {
// detect the event and log an audit trail
if (data.event == 'hset'){
redis.log('User data changed: ' + data.key);
}
else if (data.event == 'del'){
redis.log('User deleted: ' + data.key);
}

var curr_time = client.call("time")[0];

// add the current timestamp to the Hash
client.call('hset', data.key, 'last', curr_time);
}

https://habr.com/ru/articles/761514/

#development #javascript #redis

Хороший ретрай, плохой ретрай, или История одного падения

Хорошая статья, объясняющая на простых примерах практики для взаимодействия с сервером, который отдает ошибки. Наверняка, вы сталкивались с ситуацией, когда сервер иногда отвечает ошибкой, но если повторить запрос - то ответит корректно. Решение на поверхности - просто влепить retry. Что может пойти не так?

Статья как раз и объясняет что может пойти не так. Если коротко, то retry может привести к тому, что нагрузка на сервер вырастет и он перестанет справляться с обработкой запросов. После этого количество ошибок возрастет, количество retry увеличится, что приведет к еще более печальным результатам. В статье рассказывается как правильно делать обращения к нестабильному серверу

Первая практика: retry. Если все клиенты будут использовать retry с одинаковым таймаутом между запросами, то если серверу станет плохо - ретраи его добьют. Чтобы этого не случилось, используют exponential backoff retry - это когда ретраи делаются не через фиксированные отрезки времени, а эти отрезки увеличиваются. Грубо говоря, если сервер не смог ожить за первые 2 быстрых ретрая, то вряд ли он оживет в ближайшее время, поэтому есть смысл увеличивать с каждой попыткой интервал между попытками.

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

Но в целом, при долгом отказе сервера, даже "умные" ретраи не спасают - они лишь откладывают пик нагрузки. Поэтому применяют и другие практики: Retry circuit breaker и Retry budget.

Практика Retry circuit breaker говорит о том, что ретраи допускается делать если количество ошибок от сервера не превышает порог. Если превышает - мы считаем что сервис немножко нездоров и долбить его ретраями - значит делать хуже

Практика Retry budget говорит о том, что ретраев не должно быть больше определенного порога от количества успешных запросов. Например, не больше 10% от запросов.

Но и это еще не все. Еще существует практика deadline propagation. Это когда клиент в запросе передает значение таймаута и сервер, получая запрос на обработку из очереди обработки, может принять решение - есть ли смысл его обрабатывать. Или прекратить обрабатывать запрос, ответ на который клиент уже не ждет.

В общем, крутая статья с хорошими примерами и графиками про основные паттерны борьбы с нагрузкой на нестабильный сервер

https://habr.com/ru/companies/yandex/articles/762678/

#development #performance #retry #circuitBreaker #recommended

Дайджест за 2023-09-25 - 2023-09-28


————

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

————

Your Cache Headers Could Probably be More Aggressive
Короткая статья про кеширующие хедеры. При настройке заголовков ответа на сервере или CDN можно указать правила кеширования. Если их правильно настроить, это сильно поможет и пользователю и приложению.

Автор разбирает 2 простых сценария: кеширование до изменения и вечное кеширование.

💥 Introducing Skott, the new Madge!
Skott - библиотека для анализа графа зависимостей. Альтернатива Madge. Авторы обещают что она работает очень быстро.

Можете попробовать на своем проекте запустив skott --displayMode=webapp --trackThirdPartyDependencies --ignorePattern="test/**/*». Возможно, потребуется поправить команду чуть под себя

JavaScript триггеры и функции появились в Redis 7.2
В Redis 7.2 появится возможность писать внутренние триггеры и функции на JS. Раньше поддерживался только Lua. Redis - это СУБД для быстрой работы с данными key-value. Оказывается там есть возможность не просто складывать и читать данные, но еще и делать кастомную логику на языке программирования

Функции и триггеры покрывают разные кейсы. Функции - это про быструю обработку данных на стороне СУБД. Например, я хочу получить ФИО всех клиентов, но вместо полных имен - инициалы. Можно выгрузить всех клиентов в приложение и там сделать обработку, а можно сделать функцию, которая сразу вернет готовые данные. Триггеры же позволяют подписаться на события в БД и реагировать на них. Например, дополнять всем данным определенного типа колонку lastUpdated

⭐Хороший ретрай, плохой ретрай, или История одного падения
Хорошая статья, объясняющая на простых примерах практики для взаимодействия с сервером, который отдает ошибки. Наверняка, вы сталкивались с ситуацией, когда сервер иногда отвечает ошибкой, но если повторить запрос - то ответит корректно. Решение на поверхности - просто влепить retry. Что может пойти не так?

Статья как раз и объясняет что может пойти не так. Если коротко, то retry может привести к тому, что нагрузка на сервер вырастет и он перестанет справляться с обработкой запросов. После этого количество ошибок возрастет, количество retry увеличится, что приведет к еще более печальным результатам. В статье рассказывается как правильно делать обращения к нестабильному серверу

——————————————

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

Подъехала новая статья: "Сетевая инфраструктура - от основ до Дата Центров".

За 10 лет работы инженером у меня накопилось много вопросов о сети, часть из которых я либо не знал, либо не понимал. Сеть эффективно скрывает от нас всю свою сложность, делая нашу жизнь проще. Но иногда эти пробелы в знаниях сказывались, например:
- Когда меня спросили на собеседовании про Level 3 и Level 4 балансеры.
- Когда я стал лидить проект, связанный с инфраструктурой (создание Cassandra as a Service)
- Так и при проектировании высоконагруженных систем, когда требуется глубокое понимание сети для оптимизации и правильного дизайна.

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

В статье вы узнаете:
- Что такое OSI Level?
- Как функционируют TCP/UDP/QUIC? Что такое пакет, фрагмент, датаграм?
- Как устроена сеть между клиентом и сервером. Что такое ISP, BGP, Anycast?
- Что представляют из себя Edge networks?
- И в заключение — как устроена сеть в дата-центре компании Meta.

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

На русском: https://amarchenko.dev/blog/2023-10-02-network/
На английском: https://amarchenko.dev/translate/2023-10-02-network/

Death by a thousand microservices

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

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

При этом многие крупные технологические компании достигли коммерческого успеха, будучи монолитами (Dropbox, Twitter, Netflix, Facebook, GitHub, Instagram, Shopify, StackOverflow, WhatsApp), а некоторые из них и по сей день имеют монолитное ядро. А некоторые компании уходят от микросервисов к более крупным сервисам (Uber)

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

Также все это, хоть и в меньшей степени, справедливо и для микрофронтендов: микрофронтенды привносят в проект определенную сложность, поэтому решение об их использовании должно приниматься только если эта сложность окупается преимуществами от введение микрофронтендов

https://renegadeotter.com/2023/09/10/death-by-a-thousand-microservices.html

#development #microservices #recommended

The Uphill Battle of Memoization

Есть статьи Дэна Абрамова и Кент Си Доддса, объясняющие, как правильно композировать компоненты в React, чтобы не требовалось использование React.memo. Но в чем проблема React.memo?

Статья разбирает, почему использование React.memo приводит к усложнению кода. Если коротко, то React.memo использует для сравнения Object.is, что влечет за собой требование прокидывания стабильных ссылок на объекты и функции в пропсы. А это, в свою очередь, требует заворачивания в useMemo всех объектов, вместо простого их прокидывания, даже если они не изменяются.

Например, в коде <ExpensiveTree style={{ backgroundColor: 'blue' }} /> при каждом рендере style будет новый, поэтому, чтобы не вызывать ререндер, нужно либо вынести style в константы за компонент (что не всегда возможно), либо завернуть объект в useMemo

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

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

https://tkdodo.eu/blog/the-uphill-battle-of-memoization

#development #react #memoization #performance

Дайджест за 2023-10-05 - 2023-10-06

——————

На прошлой неделе посетил FrontendConf. Конференция, как всегда, огонь: поговорил с интересными людьми в кулуарах, послушал умных людей на докладах и рассказал про свой опыт построения архитектурного гайдлайна (спасибо вам, если вы приходили меня послушать ❤️).

На этой неделе возвращаюсь в привычный график чтения статей и публикации новостей в канале

——————

⭐Death by a thousand microservices
Хорошая статья про то, что микросервисы переоценены. Начиная с какого-то времени и по сей день, микросервисы считаются лучшим выбором для создания новых продуктов. Обязательно надо делить все на микросервисы, это позволяет изолировать контексты, легко масштабировать инстансы, разделить код по командам. Но, почему-то, все упускают сложность, которую привносят микросервисы.

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

The Uphill Battle of Memoization
Есть статьи Дэна Абрамова и Кент Си Доддса, объясняющие, как правильно композировать компоненты в React, чтобы не требовалось использование React.memo. Но в чем проблема React.memo?

Статья разбирает, почему использование React.memo приводит к усложнению кода. Если коротко, то React.memo использует для сравнения Object.is, что влечет за собой требование прокидывания стабильных ссылок на объекты и функции в пропсы. А это, в свою очередь, требует заворачивания в useMemo всех объектов, вместо простого их прокидывания, даже если они не изменяются.

——————————————

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

Sharing State with Islands Architecture

Islands Architecture набирает популярность и появляются статьи про разные нюансы работы с этой архитектурой. В данной статье рассматривается, как шарить данные между островами. В целом, ничего нового в рамках статьи нет (т.к. проблема существует еще с jquery-виджетов), но неплохо визуализировано и объяснено, какие паттерны шаринга данных есть и какой из них лучше

В целом в статье рассматриваются следующие паттерны, от худшего к лучшему:

- Единое состояние выше по дереву островов
- Использование шины событий (в рамках данной статьи через диспатч кастомных событий в document)
- Использование стейт-менеджера
- Развязывание связи острова и стейт менеджера (через комбинацию события+стейт менеджер)

https://frontendatscale.com/blog/islands-architecture-state/

#development #islands #architecture #stateManagment

Best Practices for Securing Node.js Applications in Production

Чеклист из 15 пунктов про обеспечение безопасности в nodejs приложении. В каждом пункте в статье раскрывается зачем и как это делать

1. Не запускать Node.js с Root привилегиями
2. Иметь актуальные версии NPM-пакетов
3. Избегать дефолтных имен куки
4. Установить HTTP-заголовки, отвечающие за безопасность
5. Реализовать Rate Limiting
6. Настроить строгие политики аутентификации
7. Не отправлять лишней информации
8. Мониторить бекенд
9. Использовать HTTPS-only политику
10. Валидировать пользовательский ввод
11. Использовать линтеры
12. Защищаться от SQL-инъекций
13. Ограничить размер запроса
14. Мониторить уязвимости через тулинг
15. Обеспечьте возможность репорта уязвимостей пользователями

https://semaphoreci.com/blog/securing-nodejs

#development #nodejs #security #checklist

Honey, I shrunk the npm package

Статья рассматривает 3 различных стандарта для сжатия файлов: gzip, brotli (решение от Google) и ZStandard (решение от Facebook). Рассматриваются эти стандарты с точки зрения распаковки npm-пакетов. В целом, неплохой обзор на разные инструменты для сжатия контента

В рамках сравнения получились следующие выводы: ZStandard эффективнее сжимает чем gzip и быстрее распаковывается. Brotli же сжимает еще эффективнее, но не так быстр в запаковке и распаковке контента.

Но при этом для сжатия npm пакетов используется gzip. Почему так, если другие форматы эффективнее? Все дело в обратной совместимости. Brotli поддерживается нативно с npm 10 (если я правильно понял статью), а значит, пока есть клиенты с более мелкими версиями npm - включать brotli как решение по умолчанию - нельзя. Так что к 2027 году можно будет переходить на brotli по-умолчанию. А поддержки ZStandard в npm пока еще нет, поэтому вряд ли стоит ожидать его применения

PS: отдельно порадовала отсылка в названии статьи к фильму "Дорогая, я уменьшил детей", который был у меня в детстве на кассете :)

https://jamiemagee.co.uk/blog/honey-i-shrunk-the-npm-package/

#development #performance #compression #brotli #zstd #gzip

Lit 3.0 Prerelease 2 and more!

Пререлиз Lit 3.0. Короткое напоминание: Lit - это инструмент для облегчения работы с веб-компонентами.

Релиз выглядит достаточно интересным: отказ от поддержки IE11, переход на новые декораторы из стандарта языка, обновления компилятора (неожиданно для меня, шаблоны Lit компилируются через Typescript) и, самое для меня неожиданное, интеграция с Preact Signals.

https://lit.dev/blog/2023-09-27-lit-3.0-prerelease-2

#development #lit #webcomponents

Test Assertion Styles in JavaScript

Короткая заметка про разные стили работы тестовых фреймворков в JS (в целом актуально и не только для JS)

Есть 2 типа тестовых тулзов: spec и tap. Spec - это когда мы тесты обозначаем специальной функцией и когда она выкидывает исключение - мы считаем что тест упал. Если же исключение не было выкинуто - тест прошел. Tap - это когда есть специальное API для проверок и проверки либо проходят либо нет.

Типичный пример в spec-подходе:

describe('account', () => {
it('has a balance of zero when first created', () => {
// if this throws, the test fails
expect(new Account().balance).to.equal(0)
})
it('has an empty list of initial addresses', () => {
expect(new Account().addresses).to.match([])
})
})

Типичный пример в tap-подходе:
t.test('account', async t => {
const a = new Account()
t.equal(a.balance, 0, 'balance of zero when first created')
t.match(a.addresses, [], 'empty list of addresses')
t.test('credits', async t => {
a.credit(100)
t.equal(a.balance, -100, 'negative balance after credit')
a.debit(200)
t.equal(a.balance, 100, 'positive balance after debit')
})
})

В первом сниппете кода границы тесты - это describe и it.

Во втором же сниппете используется объект t, который умеет делать проверки и композировать их через test. При этом "тестов" в привычном понимании там нет, только проверки. Минимальный tap тест выглядит так t.ok(cond, message)

То есть, разница подходов - разница в абстракции, вокруг которых они крутятся. Для spec - это тесты, для tap - проверки.

Автор также указывает на разницу, что в spec-подходе it и describe определяются тест-ранером (а значит нельзя запустить тесты на чисто nodejs) и обязательно нужно выделять describe => it, но, кажется что в реальности это не так (т.к. все таки есть тулы, где эти функции нужно импортировать явно, а тесты могут запускаться без отдельного тест-ранера)

https://blog.izs.me/2023/09/software-testing-assertion-styles/

#development #testing #tap

Дайджест за 2023-10-09 - 2023-10-13

Sharing State with Islands Architecture
Islands Architecture набирает популярность и появляются статьи про разные нюансы работы с этой архитектурой. В данной статье рассматривается, как шарить данные между островами. В целом, ничего нового в рамках статьи нет (т.к. проблема существует еще с jquery-виджетов), но неплохо визуализировано и объяснено, какие паттерны шаринга данных есть и какой из них лучше

Best Practices for Securing Node.js Applications in Production
Чеклист из 15 пунктов про обеспечение безопасности в nodejs приложении. В каждом пункте в статье раскрывается зачем и как это делать

Honey, I shrunk the npm package
Статья рассматривает 3 различных стандарта для сжатия файлов: gzip, brotli (решение от Google) и ZStandard (решение от Facebook). Рассматриваются эти стандарты с точки зрения распаковки npm-пакетов. В целом, неплохой обзор на разные инструменты для сжатия контента

В рамках сравнения получились следующие выводы: ZStandard эффективнее сжимает чем gzip и быстрее распаковывается. Brotli же сжимает еще эффективнее, но не так быстр в запаковке и распаковке контента.

Lit 3.0 Prerelease 2 and more!
Пререлиз Lit 3.0. Короткое напоминание: Lit - это инструмент для облегчения работы с веб-компонентами.

Релиз выглядит достаточно интересным: отказ от поддержки IE11, переход на новые декораторы из стандарта языка, обновления компилятора (неожиданно для меня, шаблоны Lit компилируются через Typescript) и, самое для меня неожиданное, интеграция с Preact Signals.

Test Assertion Styles in JavaScript
Короткая заметка про разные стили работы тестовых фреймворков в JS (в целом актуально и не только для JS)

Есть 2 типа тестовых тулзов: spec и tap. Spec - это когда мы тесты обозначаем специальной функцией и когда она выкидывает исключение - мы считаем что тест упал. Если же исключение не было выкинуто - тест прошел. Tap - это когда есть специальное API для проверок и проверки либо проходят либо нет.

——————————————

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

Did the React team forget the React Forget compiler?

Команда React работает над своим компилятором React Forget. Внезапно на reddit'е задались вопросом "не забыла (forget) ли команда React о React Forget?". И в комментарии пришел разработчик из команды React и рассказал немного подробностей про разработку компилятора.

Разработчик объясняет сложность создания своего компилятора на достаточно простом примере компилирования использования переменных в компоненте в код с useMemo.

https://www.reddit.com/r/reactjs/comments/16nnh4z/comment/k1jbr4t/

#development #react #reactForget

Building an onboarding plan for engineering managers

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

Статья рассказывает, как сделать план онбординга для менеджеров

1. Обозначьте срок онбординга. Всем участникам должно быть понятно, к какому сроку ожидается, что новый менеджер начнет быть эффективной частью команды
2. Назначьте менеджера-ментора, который будет помогать советом и отвечать на вопросы новичка
3. План онбординга состоит из двух форм обучения: теория и практика. В теоретической части следует рассказать различные знания о роли менеджера в компании. Практика же предполагает использование этой теории в текущей работе. Например, в рамках теории можно рассказать о процессе разработки, а в рамках практики новый менеджер должен вести этот процесс. При этом важно разделить знания на секции, например "работа с людьми", "обеспечение поставки" и "техническое лидерство", тогда можно будет поочередно вводить нового менеджера в каждую секцию через паттерн теория=>практика
4. Адаптируйте план под бекграунд нового менеджера. Если практики разработки в целом везде очень походи, то практики менеджмента в разных компаниях сильно отличаются. Поэтому для онбординга менеджера очень важно адаптировать план под его контекст.

https://leaddev.com/process/building-onboarding-plan-engineering-managers

#managment #onboarding

DefinitelyTyped is a monorepo!

DefinitelyTyped только что стал полноценным монорепозиторием на основое pnpm!

В DefinitelyTyped хранятся все пакеты в @types организации. Если пакет не поставляет типы сам, то всегда можно прислать пул-реквест в этот репозиторий и установить пакет отдельно (так делает, например, react с его @types/react).

Масштаб впечатляет — 8710 пакетов в одном репозитории!

Это миграции посвящены аж три поста:
1. What is DefinitelyTyped, and is it a monorepo? — как был устроен репозиторий и какие проблемы были до миграции.
2. Speeding up pnpm — название говорит само за себя. Естественно, при таком объёме всплывают не очень эффективные алгоритмы. Особенно круто, что показан процесс профилирования.
3. DefinitelyTyped is a monorepo! — как теперь всё устроено, какие проблемы сохранились (или появились) и что дальше.

Монументальная работа и огромный, в том числе и маркетинговый, успех для pnpm!

Diving into Engineering Metrics

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

В статье обсуждается зачем нужны такие метрики и какие подходы есть в индустрии для сбора этих метрик

Зачем нам нужно замерять команды разработки:

1. Метрики позволяют понимать производительность
2. Замеряя метрики, команды могут видеть свое развитие
3. Метрики могут быть использованы для принятия решений
4. Метрики позволяют убедиться, что разработчики следуют целям бизнеса
5. Устанавливать цели
6. Позволяют обсуждать прогресс проекта со стейкхолдерами
7. Улучшение метрик положительно влияет на мораль команды
8. Метрики позволяют увидеть, что ресурсы используют неээфективно
9. Метрики позволяют убедиться в достаточном качестве продукта

Но как правильно померить команду разработки? Это нетривиальная задача и подходы к решению этой задачи менялись с течением времени

Когда то давно, достаточно было замерять строчки кода (например, в книжке "мифический человекомесяц" часто встречаются кейсы, где проекты замеряются по строчкам кода).

Затем перешли на измерение velocity и cycle time. Velocity замеряет объем поставляемых в итерацию задач. Cycle time - время от "взяли задачу в проработку\работу" до "поставили ценность клиенту". Эти метрики уже намного ближе к бизнесу, чем строчки кода. Они проверяют, насколько команда гибкая (насколько быстро она проверяет гипотезы)

Позже, DevOps движение принесло DORA (DevOps Research and Assessment) - 4 ключевых метрики, по которым можно понять эффективность команды:

1. Lead Time: сколько времени проходит от появления идеи до получения её клиентами
2. Deployment Frequency: как часто команда поставляет изменения (деплоит в прод)
3. Change Failure Rate: как часто изменениям нужны правки или переделки
4. Mean Time To Recovery: как быстро мы можем исправить проблему, если она появилась

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

Следующий набор метрик - SPACE.

1. Satisfaction
2. Performance
3. Activity
4. Communication and collaboration
5. Efficiency and flow

Тут уже делается акцент на уровне счастья разработчика и на эффективности процессов. Но при этом, в статье (я не понял это прям в SPACE предлагается или в статье так интерпретировали этот набор метрик) предлагается замерять скорость и эффективность Code Review, что, на мой взгляд, не очень хорошо

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

В общем, оценивать эффективность разработки очень сложно и есть разные подходы, которые можно комбинировать.

https://hybridhacker.email/p/diving-into-engineering-metrics

#managment #engineeringMetrics #metrics #performance

Speeding up the JavaScript ecosystem - The barrel file debacle

Новая статья про ускорение JS экосистемы. На этот раз автор не разбирает какой-то конкретный кейс, а в целом рассказывает об одном паттерне, который замедляет исполнение кода.

Паттерн сегодняшней статьи - это index-файлы с ре-экспортами. В сообществе есть консенсус большинства, что у библиотек или модулей должен быть index.js, который содержит все публичное API, и дальше лезть никому не нужно. А если вы используете не все из этого API, то tree-shaking вырежет все лишнее.

В целом, это так и есть, но не всегда. Tree-shaking актуален только для кода, который был обработан бандлером. Если же код не обрабатывается бандлером, то рантайм вынужден все import'ы обработать, что увеличивает время выполнения кода.

Например, если код не бандлить и просто поставлять модулями в браузер, то браузеру придется обработать все дерево зависимостей index.js файла, даже если вам нужна одна простая утилка.

Также это проблема, с которой я сталкиваюсь при написании тестов в jest. Код импортирует 1 утилку, но она импортируется из index.js файла, поэтому jest тратит 5-10 секунд на резолв всех зависимостей, и 100мс на запуск самих тестов.

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

https://marvinh.dev/blog/speeding-up-javascript-ecosystem-part-7/

#development #javascript #performance