Node Modules Inspector
Node Modules Inspector - инструмент, позволяющий провести анализ пакета - от чего зависит, какие уязвимости, сколько весит и все такое. Главные отличительные особенности этого проекта: очень приятный UI и запуск прямо в браузере в Web Container (песочница, в которой можно запускать что-то близкое к nodejs)
Выглядит нереально круто: выбираешь пакет, запускается WebContainer, внутри него запускается pnpm и устанавливает пакет и выводит всю стату для анализа
https://node-modules.dev/
#development #javascript #pnpm #performance #webcontainer
Node Modules Inspector - инструмент, позволяющий провести анализ пакета - от чего зависит, какие уязвимости, сколько весит и все такое. Главные отличительные особенности этого проекта: очень приятный UI и запуск прямо в браузере в Web Container (песочница, в которой можно запускать что-то близкое к nodejs)
Выглядит нереально круто: выбираешь пакет, запускается WebContainer, внутри него запускается pnpm и устанавливает пакет и выводит всю стату для анализа
https://node-modules.dev/
#development #javascript #pnpm #performance #webcontainer
node-modules.dev
Node Modules Inspector
Visualize your node_modules, inspect dependencies, and more.
Omlet - Uncover React component usage across your dev teams
Еще один инструмент для анализа кода, но на этот раз для дизайн-систем и UI-китов. Омлет собирает аналитику по использованию компонентов в коде: какие компоненты как используются, как быстро отказываются от deprecated компонентов, какие компоненты не из дизайн-системы разработчики часто используют (кандидаты на вынос в дизайн-систему)
Выглядит как инструмент с очень узким юзкейсом - для выделенных команд UI-кита в больших компаниях.
https://omlet.dev/
#development #uikit #react
Еще один инструмент для анализа кода, но на этот раз для дизайн-систем и UI-китов. Омлет собирает аналитику по использованию компонентов в коде: какие компоненты как используются, как быстро отказываются от deprecated компонентов, какие компоненты не из дизайн-системы разработчики часто используют (кандидаты на вынос в дизайн-систему)
Выглядит как инструмент с очень узким юзкейсом - для выделенных команд UI-кита в больших компаниях.
https://omlet.dev/
#development #uikit #react
Omlet
Component analytics and insights for React.
Reproducibility vs. Provenance: Trusting the JavaScript Supply Chain
reproduce - инструмент, который проверяет, что пакет, скачиваемый из npm, действительно собран из исходников на github. Т.е. инструмент проверяет пакеты на reproducibility.
Зачем это надо? Это необходимо для гарантии того, что никто никак не патчит код пере публикацией. Это может быть как проблема безопасности (хакеры встроились в пайплайн публикации и воруют крипто-кошельки), так и проблема доверия (авторы пакета обещают что никак не используют ваши данные, а сами отправляют телеметрию).
Provenance - это когда кто-то заявляет, что пакет и правда собран из исходников (например Github). reproducibility - это когда каждый может убедиться в том, что пакет собран из тех же исходников, что есть на github.
Теперь для проверки reproducibility есть reproduce.
https://blog.vlt.sh/blog/reproducibility
#development #npm #security
reproduce - инструмент, который проверяет, что пакет, скачиваемый из npm, действительно собран из исходников на github. Т.е. инструмент проверяет пакеты на reproducibility.
Зачем это надо? Это необходимо для гарантии того, что никто никак не патчит код пере публикацией. Это может быть как проблема безопасности (хакеры встроились в пайплайн публикации и воруют крипто-кошельки), так и проблема доверия (авторы пакета обещают что никак не используют ваши данные, а сами отправляют телеметрию).
Provenance - это когда кто-то заявляет, что пакет и правда собран из исходников (например Github). reproducibility - это когда каждый может убедиться в том, что пакет собран из тех же исходников, что есть на github.
Теперь для проверки reproducibility есть reproduce.
https://blog.vlt.sh/blog/reproducibility
#development #npm #security
vlt /vōlt/ - blog
Reproducibility vs. Provenance: Trusting the JavaScript Supply Chain
We launched a new tool to detect package integrity issues in the JavaScript ecosystem. Learn how `reproduce` is changing the game.
Playwright: игра в скриншотные тесты
Отличная статья от Okko про реализацию скриншот-тестов в связке playwright + storybook. Она одновременно верхнеуровневая (т.е. автор не погружается прям в самые детали) и одновременно содержит весь самый сок, необходимый для настройки скриншот-тестов в проекте.
Okko требуется поддерживать интерфейсы для веба и смарт-тв, на которых могут быть разные ОС, поэтому вопрос поддержки UI стоит достаточно остро. Поэтому они и вложились в скриншот-тесты.
В статье рассказывается про:
- Как отключить анимации в дополнение к API playwright
- Как получить список всех историй и пройти по ним в цикле для запуска всех скриншот-тестов
- Как работать с загрузкой изображений, шрифтов и других ресурсов
- Как и зачем запускаться в docker
- Как работать с эталонами
- Как настраивать Playwright
В общем, мастхев ссылка если вы занимаетесь скриншот-тестированием или хотите поставить этот процесс
https://habr.com/ru/companies/okko/articles/890438/
#development #javascript #storybook #testing #screenshotTesting #habr #okko
Отличная статья от Okko про реализацию скриншот-тестов в связке playwright + storybook. Она одновременно верхнеуровневая (т.е. автор не погружается прям в самые детали) и одновременно содержит весь самый сок, необходимый для настройки скриншот-тестов в проекте.
Okko требуется поддерживать интерфейсы для веба и смарт-тв, на которых могут быть разные ОС, поэтому вопрос поддержки UI стоит достаточно остро. Поэтому они и вложились в скриншот-тесты.
В статье рассказывается про:
- Как отключить анимации в дополнение к API playwright
- Как получить список всех историй и пройти по ним в цикле для запуска всех скриншот-тестов
- Как работать с загрузкой изображений, шрифтов и других ресурсов
- Как и зачем запускаться в docker
- Как работать с эталонами
- Как настраивать Playwright
В общем, мастхев ссылка если вы занимаетесь скриншот-тестированием или хотите поставить этот процесс
https://habr.com/ru/companies/okko/articles/890438/
#development #javascript #storybook #testing #screenshotTesting #habr #okko
Хабр
Playwright: игра в скриншотные тесты
Работа с Playwright всегда доставляет мне удовольствие. « Наиграв » уже десятки, если не сотни часов в библиотеке, решая проблемы, копаясь в исходниках или на просторах сети, я практически всегда...
Серия бесплатных воркшопов про менеджмент от Стратоплан
Всем привет, с 14 по 18 апреля c 17:00 по 19:00 по МСК будут проходить бесплатные 2х-часовые занятия от Стратоплан по менеджменту. Среди спикеров есть как минимум 2 чувака, которых я рекомендую читать и слушать всем - Виталий Шароватов (слежу за ним уже лет 7) и Дмитрий Болдырев, который недавно выпускал крутую серию постов про образование команд из рабочих групп
Будет 5 занятий, на которых рассмотрят:
– первые шаги: ожидания и задачи после назначения
– найм и как это делать правильно
– как создать команду
– как ставить и контролировать задачи
– лидерство
Если вы - тимлид или хотите расти в этом направлении - рекомендую записаться. Это бесплатновое, плюс спикеры реально хороши.
Бесплатная регистрация здесь
#managment #stratoplan #note
Всем привет, с 14 по 18 апреля c 17:00 по 19:00 по МСК будут проходить бесплатные 2х-часовые занятия от Стратоплан по менеджменту. Среди спикеров есть как минимум 2 чувака, которых я рекомендую читать и слушать всем - Виталий Шароватов (слежу за ним уже лет 7) и Дмитрий Болдырев, который недавно выпускал крутую серию постов про образование команд из рабочих групп
Будет 5 занятий, на которых рассмотрят:
– первые шаги: ожидания и задачи после назначения
– найм и как это делать правильно
– как создать команду
– как ставить и контролировать задачи
– лидерство
Если вы - тимлид или хотите расти в этом направлении - рекомендую записаться. Это бесплатновое, плюс спикеры реально хороши.
Бесплатная регистрация здесь
#managment #stratoplan #note
Школа менеджмента STRATOPLAN
Основы управления
Бесплатный курс от Школы менеджмента «Стратоплан»
Дайджест за 2025-04-07 - 2025-04-11
Node Modules Inspector
Node Modules Inspector - инструмент, позволяющий провести анализ пакета - от чего зависит, какие уязвимости, сколько весит и все такое. Главные отличительные особенности этого проекта: очень приятный UI и запуск прямо в браузере в Web Container (песочница, в которой можно запускать что-то близкое к nodejs)
Выглядит нереально круто: выбираешь пакет, запускается WebContainer, внутри него запускается pnpm и устанавливает пакет и выводит всю стату для анализа
Omlet - Uncover React component usage across your dev teams
Еще один инструмент для анализа кода, но на этот раз для дизайн-систем и UI-китов. Омлет собирает аналитику по использованию компонентов в коде: какие компоненты как используются, как быстро отказываются от deprecated компонентов, какие компоненты не из дизайн-системы разработчики часто используют (кандидаты на вынос в дизайн-систему)
Выглядит как инструмент с очень узким юзкейсом - для выделенных команд UI-кита в больших компаниях.
Reproducibility vs. Provenance: Trusting the JavaScript Supply Chain
reproduce - инструмент, который проверяет, что пакет, скачиваемый из npm, действительно собран из исходников на github. Т.е. инструмент проверяет пакеты на reproducibility.
Зачем это надо? Это необходимо для гарантии того, что никто никак не патчит код пере публикацией. Это может быть как проблема безопасности (хакеры встроились в пайплайн публикации и воруют крипто-кошельки), так и проблема доверия (авторы пакета обещают что никак не используют ваши данные, а сами отправляют телеметрию).
Playwright: игра в скриншотные тесты
Отличная статья от Okko про реализацию скриншот-тестов в связке playwright + storybook. Она одновременно верхнеуровневая (т.е. автор не погружается прям в самые детали) и одновременно содержит весь самый сок, необходимый для настройки скриншот-тестов в проекте.
Okko требуется поддерживать интерфейсы для веба и смарт-тв, на которых могут быть разные ОС, поэтому вопрос поддержки UI стоит достаточно остро. Поэтому они и вложились в скриншот-тесты.
Серия бесплатных воркшопов про менеджмент от Стратоплан
Всем привет, с 14 по 18 апреля c 17:00 по 19:00 по МСК будут проходить бесплатные 2х-часовые занятия от Стратоплан по менеджменту. Среди спикеров есть как минимум 2 чувака, которых я рекомендую читать и слушать всем - Виталий Шароватов (слежу за ним уже лет 7) и Дмитрий Болдырев, который недавно выпускал крутую серию постов про образование команд из рабочих групп
——————————————
Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегам или друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂
Node Modules Inspector
Node Modules Inspector - инструмент, позволяющий провести анализ пакета - от чего зависит, какие уязвимости, сколько весит и все такое. Главные отличительные особенности этого проекта: очень приятный UI и запуск прямо в браузере в Web Container (песочница, в которой можно запускать что-то близкое к nodejs)
Выглядит нереально круто: выбираешь пакет, запускается WebContainer, внутри него запускается pnpm и устанавливает пакет и выводит всю стату для анализа
Omlet - Uncover React component usage across your dev teams
Еще один инструмент для анализа кода, но на этот раз для дизайн-систем и UI-китов. Омлет собирает аналитику по использованию компонентов в коде: какие компоненты как используются, как быстро отказываются от deprecated компонентов, какие компоненты не из дизайн-системы разработчики часто используют (кандидаты на вынос в дизайн-систему)
Выглядит как инструмент с очень узким юзкейсом - для выделенных команд UI-кита в больших компаниях.
Reproducibility vs. Provenance: Trusting the JavaScript Supply Chain
reproduce - инструмент, который проверяет, что пакет, скачиваемый из npm, действительно собран из исходников на github. Т.е. инструмент проверяет пакеты на reproducibility.
Зачем это надо? Это необходимо для гарантии того, что никто никак не патчит код пере публикацией. Это может быть как проблема безопасности (хакеры встроились в пайплайн публикации и воруют крипто-кошельки), так и проблема доверия (авторы пакета обещают что никак не используют ваши данные, а сами отправляют телеметрию).
Playwright: игра в скриншотные тесты
Отличная статья от Okko про реализацию скриншот-тестов в связке playwright + storybook. Она одновременно верхнеуровневая (т.е. автор не погружается прям в самые детали) и одновременно содержит весь самый сок, необходимый для настройки скриншот-тестов в проекте.
Okko требуется поддерживать интерфейсы для веба и смарт-тв, на которых могут быть разные ОС, поэтому вопрос поддержки UI стоит достаточно остро. Поэтому они и вложились в скриншот-тесты.
Серия бесплатных воркшопов про менеджмент от Стратоплан
Всем привет, с 14 по 18 апреля c 17:00 по 19:00 по МСК будут проходить бесплатные 2х-часовые занятия от Стратоплан по менеджменту. Среди спикеров есть как минимум 2 чувака, которых я рекомендую читать и слушать всем - Виталий Шароватов (слежу за ним уже лет 7) и Дмитрий Болдырев, который недавно выпускал крутую серию постов про образование команд из рабочих групп
——————————————
Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегам или друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂
How to get deep traces in your Node.js backend with OTel and Deno
Deno в одном из недавних релизов добавили нативную поддержку Open Telemetry - инструментария, которая добавляет возможности для observability вашей системы. Буквально можно смотреть на что конкретно было затрачено время, пока сервер отвечал пользователю.
Данная статья в целом не погружается в глубоко работу Open Telemetry, но подсвечивают, что OT в nodejs сделан через костыли, а для подключения надо написать 2 экрана кода (в свое время сам ужаснулся этой SDK), а в Deno достаточно указать ключ запуска deno
https://deno.com/blog/otel-tracing-in-node-and-deno
#development #javascript #opentelemetry #deno
Deno в одном из недавних релизов добавили нативную поддержку Open Telemetry - инструментария, которая добавляет возможности для observability вашей системы. Буквально можно смотреть на что конкретно было затрачено время, пока сервер отвечал пользователю.
Данная статья в целом не погружается в глубоко работу Open Telemetry, но подсвечивают, что OT в nodejs сделан через костыли, а для подключения надо написать 2 экрана кода (в свое время сам ужаснулся этой SDK), а в Deno достаточно указать ключ запуска deno
https://deno.com/blog/otel-tracing-in-node-and-deno
#development #javascript #opentelemetry #deno
Deno
How to get deep traces in your Node.js backend with OTel and Deno | Deno
Adding meaningful tracing to a Node backend requires additional instrumentation and configuration. Here’s another approach that requires zero additional code.
Конспект книги Team Topologies, часть №1 - team-first mindset
Основные концепции:
Team-first mindset
Команда - самый эффективный способ организации людей для решения проблем. Поэтому важно перестроить сознание на team-first и уметь работать с командами:
- Когда команда - неделимый юнит для реализации любой работы
- Похвала и порицание всегда идут на команду, а не на отдельных людей
- Цели команды важнее собственных
Модель Такмана говорит о том, как рабочая группа превращается в команду:
- Формирование - создается рабочая группа и начинает работать сообща
- Шторминг - возникают конфликты между людьми. На этом этапе часть людей может покинуть группу или группа может распасться полностью.
- Нормализация - выработка единых подходов
- Перформинг - команда выходит на плато высокой продуктивности
Числа Данбара
Антрополог Данбар проанализировал различные сообщества людей и заметил, что есть 4 "круга" социальных связей:
- Очень близкие отношения с 5-7 людьми
- Приятели, хорошие друзья - 15 человек
- Семья, коллеги - 50 человек
- Стая - 150-200 человек
Это не какая-то математическая модель - это результат наблюдений.
Как это перекладывается на IT и организации:
- Идеальный размер команды - 5-7 человек. Но в крайнем случае - до 15, но тогда высок риск что люди внутри сами поделятся на 2 группы
- 50 человек - уровень подразделения
- 200 человек - уровень отдела
В книге приводится кейс компании, которая обходит фазу шторминга в модели Такмана:
- Рекомендованы команды по 7 человек
- Но команды могут расти вместе с ростом задач или продукта, это нормально
- Когда команда достигает 15 человек - её делят на 2 команды
Т.к. команда из 15 человек - уже сработавшаяся, то когда их поделят на 2 команды, они могут пропустить фазу шторминга.
Когнитивная нагрузка на команду должна быть ограничена
Виды когнитивной нагрузки:
- Внутренняя - относится напрямую к реализации задачи напрямую
- Внешняя - относится к окружению, в котором задачу нужно сделать
- Общая - относится к аспектам задачи, которым можно уделить внимание для получения новых данных
Надо минимизировать первые 2 типа нагрузки (через обучение и автоматизацию) и сфокусироваться на 3 типе когнитивной нагрузки, решение которой позволяет делать более крутые фичи
Когнитивная нагрузка применима и к системам. Главное правило: не давать на команду больше когнитивной нагрузки, чем она может переварить. Иначе команда начинает работать как группа индивидуалистов т.к. утопают в сложности своих задач и у них нет времени на командную работу
Главная концепция - Закон Конвея
> Дизайн IT-систем повторяет дизайн коммуникации организации
Популярный пример: если вы решите сделать компилятор языка программирования и его будут делать 4 команды - он будет 4-х ступенчатым.
Коммуникация команд всегда побеждает архитектуру. Именно поэтому нельзя создавать архитектуру системы, не думая о дизайне команд и их коммуникаций. Есть 2 пути - либо отталкиваться от команд и создавать архитектуру на основе командного деления. Либо применять обратный маневр Конвея - сначала придумать архитектуру, а потом под эту архитектуру собрать команды.
Очень важная мысль: архитектура и топология команд очень связаны друг с другом. Задача архитектора - дизайнить и то и другое одновременно.
Как следствие - все бест-практисы архитектуры валидны и для организации работы команд:
- Низкое зацепление и большая связность - команды должны слабо зависеть друг от друга и должны больше коммуницировать внутри себя
- Команды не должны быть большими
- Команды должны иметь четкие интерфейсы, описывающие, как с ними взаимодействовать
Я прошелся совсем по верхам, но это минимум, который необходимо знать для организации команд. На основе этих идей создана концепция Team Topologies об основных типах команд и их взаимодействии, которую я раскрою в следующих постах.
#note #TeamTopology #book #конспект #managment
Основные концепции:
Team-first mindset
Команда - самый эффективный способ организации людей для решения проблем. Поэтому важно перестроить сознание на team-first и уметь работать с командами:
- Когда команда - неделимый юнит для реализации любой работы
- Похвала и порицание всегда идут на команду, а не на отдельных людей
- Цели команды важнее собственных
Модель Такмана говорит о том, как рабочая группа превращается в команду:
- Формирование - создается рабочая группа и начинает работать сообща
- Шторминг - возникают конфликты между людьми. На этом этапе часть людей может покинуть группу или группа может распасться полностью.
- Нормализация - выработка единых подходов
- Перформинг - команда выходит на плато высокой продуктивности
Числа Данбара
Антрополог Данбар проанализировал различные сообщества людей и заметил, что есть 4 "круга" социальных связей:
- Очень близкие отношения с 5-7 людьми
- Приятели, хорошие друзья - 15 человек
- Семья, коллеги - 50 человек
- Стая - 150-200 человек
Это не какая-то математическая модель - это результат наблюдений.
Как это перекладывается на IT и организации:
- Идеальный размер команды - 5-7 человек. Но в крайнем случае - до 15, но тогда высок риск что люди внутри сами поделятся на 2 группы
- 50 человек - уровень подразделения
- 200 человек - уровень отдела
В книге приводится кейс компании, которая обходит фазу шторминга в модели Такмана:
- Рекомендованы команды по 7 человек
- Но команды могут расти вместе с ростом задач или продукта, это нормально
- Когда команда достигает 15 человек - её делят на 2 команды
Т.к. команда из 15 человек - уже сработавшаяся, то когда их поделят на 2 команды, они могут пропустить фазу шторминга.
Когнитивная нагрузка на команду должна быть ограничена
Виды когнитивной нагрузки:
- Внутренняя - относится напрямую к реализации задачи напрямую
- Внешняя - относится к окружению, в котором задачу нужно сделать
- Общая - относится к аспектам задачи, которым можно уделить внимание для получения новых данных
Надо минимизировать первые 2 типа нагрузки (через обучение и автоматизацию) и сфокусироваться на 3 типе когнитивной нагрузки, решение которой позволяет делать более крутые фичи
Когнитивная нагрузка применима и к системам. Главное правило: не давать на команду больше когнитивной нагрузки, чем она может переварить. Иначе команда начинает работать как группа индивидуалистов т.к. утопают в сложности своих задач и у них нет времени на командную работу
Главная концепция - Закон Конвея
> Дизайн IT-систем повторяет дизайн коммуникации организации
Популярный пример: если вы решите сделать компилятор языка программирования и его будут делать 4 команды - он будет 4-х ступенчатым.
Коммуникация команд всегда побеждает архитектуру. Именно поэтому нельзя создавать архитектуру системы, не думая о дизайне команд и их коммуникаций. Есть 2 пути - либо отталкиваться от команд и создавать архитектуру на основе командного деления. Либо применять обратный маневр Конвея - сначала придумать архитектуру, а потом под эту архитектуру собрать команды.
Очень важная мысль: архитектура и топология команд очень связаны друг с другом. Задача архитектора - дизайнить и то и другое одновременно.
Как следствие - все бест-практисы архитектуры валидны и для организации работы команд:
- Низкое зацепление и большая связность - команды должны слабо зависеть друг от друга и должны больше коммуницировать внутри себя
- Команды не должны быть большими
- Команды должны иметь четкие интерфейсы, описывающие, как с ними взаимодействовать
Я прошелся совсем по верхам, но это минимум, который необходимо знать для организации команд. На основе этих идей создана концепция Team Topologies об основных типах команд и их взаимодействии, которую я раскрою в следующих постах.
#note #TeamTopology #book #конспект #managment
Конспект книги Team Topologies, часть №2 - типы команд и взаимодействия
Во всех компаниях разная культура, разные процессы и разные команды. Но фундаментально все команды и взаимодействия между ними можно свести к 4 базовым видам команд и 3 базовым видам взаимодействия
4 базовых вида команд:
- Продуктовые команды (Stream aligned teams, уточню что перевод не совсем корректный, но он наиболее понятный)
- Команды сложной подсистемы (complex-subsystem team)
- Платформенные команды (platform team)
- Поддерживающие команды (enabling team)
Продуктовые команды:
- Основной вид команды в организации (90+% команд)
- Сфокусированы на доставке ценности
- Имеют все необходимые компетенции для решения задач своего потока
- Экспериментируют и учаться
- Все остальные типы команд нужны для того, чтобы продуктовые команды быстрее доставляли ценность
Команды сложной подсистемы:
- Отвечает за развитие и поддержку сложной под-системы. Сложной настолько, что всем членам команды необходимо быть экспертами в области этой системы (наприммер, команда создающая видео-кодек)
- Команда инкапсулирует в себе когнитивную сложность какой-то предметной области. Позволяя продуктовым командам быстрее разрабатывать фичи.
Платформенные команды:
- Цель команды - обеспечить продуктовым командам возможность доставлять фичи с высокой степенью автономности
- Платформенная команда взаимодействует с продуктовыми командами для понимания того, что им нужно и совместного прототипирования
- Платформенная команда развивает платформу как продукт
- Крупные платформы также внутри могут делиться на команду и иметь внутри все 4 типа команд
Поддерживающие команды:
- Состоит из специалистов в определенной технической или продуктовой области
- Команда ищет новые возможности и развивает инструментарий для других команд
- Не являются центром уникальной экспертизы, а помогают другим командам получить компетенции и возможности
То есть, если совсем коротко:
- Есть команды, которые делают продуктовые фичи
- Если есть что-то реально сложное, под эту сложность выделяют отдельные команды, которые делают это "сложное" - легким и удобным для других команд
- Т.к. продуктовые команды постоянно заняты продуктовыми фичами, то им помогают платформенные команды и поддерживающие команды
- Платформенные команды предоставляют платформы, которые легки и удобны в использовании и помогают продуктовым командам доставлять фичи
- Поддерживающие команды создают инструментарий для продуктовых команд и развивают их компетенции
Как команды могут друг с другом взаимодействием:
- Совместая работа
- X-as-a-Service
- Фасилитация
Совместная работа
- Описание говорящее - 2 команды совместно что-то делают
- Не рекомендуется часто заниматься совместной работой т.к. это затратное мероприятие. К этому нужно подходить осознанно
- 1 команда должна совместной работать только с 1 другой командой в 1 момент времени
- Взаимодействие эффективно для поиска новых решений и инноваций
X-as-a-Service:
- Потребление или предоставление чего-либо с минимальным взаимодействием
- Этот тип взаимодействия можно использовать со множеством команд одновременно
- Эффективно на поздних этапах развития чего-либо, когда важна стабильность поставки, а не поиск новых решений
Фасилитация:
- Помощь или получение помощи от другой команды для устранения препятствий
- Режим взаимодействия рекомендуется использовать с небольшим количеством команд одновременно
Проще это объяснять на примерах:
- Поддерживающая команда в режиме фасилитации помогает продуктовой команде научитья использовать инструментарий для UI-автотестов
- Платформенная команда предоставляет инструментарий для деплоя в прод как X-as-a-Service
- ML-команда (Команда сложной под-системы) в режиме совместной работы с продуктовой командой ищут оптимальные способы использования ML для автоматизации проверки контента пользователей (отзывов например)
Конечно, все несколько сложнее, но в рамках обзора приходится ужиматься по контенту
#note #TeamTopology #book #конспект #managment
Во всех компаниях разная культура, разные процессы и разные команды. Но фундаментально все команды и взаимодействия между ними можно свести к 4 базовым видам команд и 3 базовым видам взаимодействия
4 базовых вида команд:
- Продуктовые команды (Stream aligned teams, уточню что перевод не совсем корректный, но он наиболее понятный)
- Команды сложной подсистемы (complex-subsystem team)
- Платформенные команды (platform team)
- Поддерживающие команды (enabling team)
Продуктовые команды:
- Основной вид команды в организации (90+% команд)
- Сфокусированы на доставке ценности
- Имеют все необходимые компетенции для решения задач своего потока
- Экспериментируют и учаться
- Все остальные типы команд нужны для того, чтобы продуктовые команды быстрее доставляли ценность
Команды сложной подсистемы:
- Отвечает за развитие и поддержку сложной под-системы. Сложной настолько, что всем членам команды необходимо быть экспертами в области этой системы (наприммер, команда создающая видео-кодек)
- Команда инкапсулирует в себе когнитивную сложность какой-то предметной области. Позволяя продуктовым командам быстрее разрабатывать фичи.
Платформенные команды:
- Цель команды - обеспечить продуктовым командам возможность доставлять фичи с высокой степенью автономности
- Платформенная команда взаимодействует с продуктовыми командами для понимания того, что им нужно и совместного прототипирования
- Платформенная команда развивает платформу как продукт
- Крупные платформы также внутри могут делиться на команду и иметь внутри все 4 типа команд
Поддерживающие команды:
- Состоит из специалистов в определенной технической или продуктовой области
- Команда ищет новые возможности и развивает инструментарий для других команд
- Не являются центром уникальной экспертизы, а помогают другим командам получить компетенции и возможности
То есть, если совсем коротко:
- Есть команды, которые делают продуктовые фичи
- Если есть что-то реально сложное, под эту сложность выделяют отдельные команды, которые делают это "сложное" - легким и удобным для других команд
- Т.к. продуктовые команды постоянно заняты продуктовыми фичами, то им помогают платформенные команды и поддерживающие команды
- Платформенные команды предоставляют платформы, которые легки и удобны в использовании и помогают продуктовым командам доставлять фичи
- Поддерживающие команды создают инструментарий для продуктовых команд и развивают их компетенции
Как команды могут друг с другом взаимодействием:
- Совместая работа
- X-as-a-Service
- Фасилитация
Совместная работа
- Описание говорящее - 2 команды совместно что-то делают
- Не рекомендуется часто заниматься совместной работой т.к. это затратное мероприятие. К этому нужно подходить осознанно
- 1 команда должна совместной работать только с 1 другой командой в 1 момент времени
- Взаимодействие эффективно для поиска новых решений и инноваций
X-as-a-Service:
- Потребление или предоставление чего-либо с минимальным взаимодействием
- Этот тип взаимодействия можно использовать со множеством команд одновременно
- Эффективно на поздних этапах развития чего-либо, когда важна стабильность поставки, а не поиск новых решений
Фасилитация:
- Помощь или получение помощи от другой команды для устранения препятствий
- Режим взаимодействия рекомендуется использовать с небольшим количеством команд одновременно
Проще это объяснять на примерах:
- Поддерживающая команда в режиме фасилитации помогает продуктовой команде научитья использовать инструментарий для UI-автотестов
- Платформенная команда предоставляет инструментарий для деплоя в прод как X-as-a-Service
- ML-команда (Команда сложной под-системы) в режиме совместной работы с продуктовой командой ищут оптимальные способы использования ML для автоматизации проверки контента пользователей (отзывов например)
Конечно, все несколько сложнее, но в рамках обзора приходится ужиматься по контенту
#note #TeamTopology #book #конспект #managment
Конспект книги Team Topologies, часть №3 - итоги
В этом посте не будет какой-то прям новой инфы из книги. Тут я резюмирую про что книга и для кого
В рамках предыдущих постов я срезал очень много углов т.к. уместить 200-300 страниц в 8000 символов и не потерять смысл - сложно.
Книга оказалась намного лучше, чем я ожидал. Обычно такие книги на определенный % состоят из всякой воды и лозунгов. Но эта книга более системная. Авторы взяли свой опыт и опыт всей индустрии в рамках организации команд и сложили его в удобную форму книги.
В книге очень много ссылок на другие книги, исследования, кейсы крупных компаний. Это натурально кладезь полезных ссылок на всякое.
Авторы не говорят, что их рецепт - единственный верный. Они прямо говорят, что подход, описанный в Team Topologies - базовый, фундаментальный. Но в определенных контекстах и в крупных организациях топология команд может отличаться т.к. там в узких кейсах будут эффективны более специфичные бест-практисы
Тем не менее, очень хорошо подана база:
- Команды должны быть маленькими
- И их ответственность должна быть маленькой (помещаться в команду)
- Разработка - это не сервера и бинари, это социо-техническая система, т.е. важна как техника так и люди и взаимодействия между ними
- Архитектура - это команды+системы
- Многие бест-практисы архитектуры актуальны и для организации команд
- Закон Конвея - организация побеждает архитектуру
- Команды должны быть самостоятельными
- Как следствие - все "вспомогательные" команды должны работать так, чтобы повышать самостоятельность других команд, а не снижать их. Пример: хорошо, когда команда, разратывающая инструментарий для автоматизации, предоставляет удобную библиотеку, гайдлайны по интеграции, коучит продуктовые команды для повышения экспертизы в автоматизации. Плохо, когда эта же команда сама заходит в команды и пишет там тесты
- Нужны четкие границы ответственности команд
- Команды разные нужны, команды разные важны
- То же самое и про взаимодействия - нужны разные в разный момент времени
Очень много в книге уделено разработке внутренних платформ и как внутренние платформы могут превратится в большие продукты, где внутри также есть разные типы команд
Для меня книга открыла глаза на некоторые аспекты взаимодействия команд, стало реально проще понимать, почему текущие наши попытки взаимодействия с какими-то командами работали плохо, а какие-то работали хорошо
Для кого эта книга:
- Архитекторы
- Менеджмент над тимлидами
- Тимлиды, которые уже больше про управление командой, чем про альфа-волчистость в команде (условно, если вы альфа-веб разработчик в команде веб-разработчиков и, поэтому, тимлид - то возможно книга будет не для вас)
Книгу строго рекомендую к прочтению, если она матчится с вашей текущей ролью.
#note #TeamTopology #book #конспект #managment
В этом посте не будет какой-то прям новой инфы из книги. Тут я резюмирую про что книга и для кого
В рамках предыдущих постов я срезал очень много углов т.к. уместить 200-300 страниц в 8000 символов и не потерять смысл - сложно.
Книга оказалась намного лучше, чем я ожидал. Обычно такие книги на определенный % состоят из всякой воды и лозунгов. Но эта книга более системная. Авторы взяли свой опыт и опыт всей индустрии в рамках организации команд и сложили его в удобную форму книги.
В книге очень много ссылок на другие книги, исследования, кейсы крупных компаний. Это натурально кладезь полезных ссылок на всякое.
Авторы не говорят, что их рецепт - единственный верный. Они прямо говорят, что подход, описанный в Team Topologies - базовый, фундаментальный. Но в определенных контекстах и в крупных организациях топология команд может отличаться т.к. там в узких кейсах будут эффективны более специфичные бест-практисы
Тем не менее, очень хорошо подана база:
- Команды должны быть маленькими
- И их ответственность должна быть маленькой (помещаться в команду)
- Разработка - это не сервера и бинари, это социо-техническая система, т.е. важна как техника так и люди и взаимодействия между ними
- Архитектура - это команды+системы
- Многие бест-практисы архитектуры актуальны и для организации команд
- Закон Конвея - организация побеждает архитектуру
- Команды должны быть самостоятельными
- Как следствие - все "вспомогательные" команды должны работать так, чтобы повышать самостоятельность других команд, а не снижать их. Пример: хорошо, когда команда, разратывающая инструментарий для автоматизации, предоставляет удобную библиотеку, гайдлайны по интеграции, коучит продуктовые команды для повышения экспертизы в автоматизации. Плохо, когда эта же команда сама заходит в команды и пишет там тесты
- Нужны четкие границы ответственности команд
- Команды разные нужны, команды разные важны
- То же самое и про взаимодействия - нужны разные в разный момент времени
Очень много в книге уделено разработке внутренних платформ и как внутренние платформы могут превратится в большие продукты, где внутри также есть разные типы команд
Для меня книга открыла глаза на некоторые аспекты взаимодействия команд, стало реально проще понимать, почему текущие наши попытки взаимодействия с какими-то командами работали плохо, а какие-то работали хорошо
Для кого эта книга:
- Архитекторы
- Менеджмент над тимлидами
- Тимлиды, которые уже больше про управление командой, чем про альфа-волчистость в команде (условно, если вы альфа-веб разработчик в команде веб-разработчиков и, поэтому, тимлид - то возможно книга будет не для вас)
Книгу строго рекомендую к прочтению, если она матчится с вашей текущей ролью.
#note #TeamTopology #book #конспект #managment
Обучение в стратоплане: обзор на модуль про принятие решений
Очередной обзор на обучение в стратоплане. В этом модуль обсуждали, как принимать решения. Модуль более сфокусированный, чем предыдущий. В предыдущем поверхностно прошли по куче концепций. В этом же модуле обсуждали 2 крупные концепции: алгоритм принятия решений и алгоритм решения конфликтов
Алгоритм принятия решений
Алгоритм состоит из 5 шагов:
1. Является ли это решение своевременным и актуальным для вас?
2. Имеется ли вся информация для принятия решения?
3. Есть ли подробный план реализации?
4. Заинтересованы ли в этом решении компания, руководитель, ЛПР?
5. Чувствую ли я себя хорошо при принятии решения?
Алгоритм одновременно и простой и сложный. Простой - потому что, когда смотришь на него, думаешь "не ну это и так очевидно". Сложный - потому что спотыкаешься, когда пробуешь применить.
Например, возьмем 2 шаг - "Имеется ли вся информация для принятия решения?". Как это понять?
Чтобы решить этот шаг необходимо собрать всю информацию. Как это сделать? Здесь может помочь метод "4 ячейки". Суть метод в том, что мы делим квадрат на 4 части
1. Что я знаю
2. Что я не знаю, но я понимаю, что я этого не знаю
3. Что я знаю, но я не понимаю, что это относится к теме
4. Что я не знаю, но не понимаю, что я этого не знаю
Эти 4 пункта позволяют найти поинты, которые необходимо дополнительно исследовать и поинты, которые необходимо проресерчить. Четвертый пункт - самый интересный. С одной стороны кажется, что он не имеет смысла. Ведь как я могу написать то, чего не представляю. Но на практике, описывая этот квадрат, мозг может найти что-то на подкорке сознания и перенести это в пункт 2 - не знаю, но теперь понял что это надо узнать.
После того как вся информация собрана, её надо проанализировать, ведь не вся информация одинаково полезна. Надо понять:
- К чему обращается информация - это логика, эмоции, правила
- Про интерпретировать. Какая основная мысль?
- Проанализировать. Действительно ли информация верна?
Последний шаг также интересен - "Чувствую ли я себя хорошо при принятии решения?". Суть в том, что перед принятием решения вы должны чувствовать себя хорошо и само решение должно вам нравится.
По поводу "чувствовать себя хорошо". Есть целое исследование на основе отчетов израильской судебной системы, которое говорит, что судьи выносят "хорошие" решения утром, перед обедом выносят "плохие решения", после обеда цикл повторяется до ужина (или перекуса), под конец рабочего дня выносятся в основном "плохие" решения. Ваше эмоциональное состояние сильно влияет на принимаемые вами решения.
Когда вы приняли решение, вы должны понимать, что принимаете его исходя из чьих то целей:
- Компании
- Команды
- Членов команды
- Конечного продукта
Если вы приходите и говорите "я так решил", то это плохой путь.
Теперь интересное про конфликты
Формула конфликта: Конфликт (открытое противостояние) = Конфликтная ситуация (набор условий, из которых конфликт может появиться) + Конфликтоген (слова и действия, запускающие конфликт)
Формула конструктива:
- Конструктив = Конфликтная ситуация - Конфликтоген
- Конструктив = Конфликт - Конфликтная ситуация - (Конфликтоген)
Т.е. вам либо надо находить конфликтоген и убирать его, либо убирать конфликтную ситуацию.
Что интересно, в любом конфликте (если в нем не участвуют социопаты) у обоих конфликтующих сторон есть позитивное намерение. Обе стороны считают, что делают что-то хорошее, а их оппонент - что-то плохое. Позитивное намерение зачастую неочевидно для оппонента. Чтобы решить конфликт - необходимо обозначить позитивные намерения обеих сторон, тогда появляется шанс перейти в конструктив и поиск вин-вин ситуации.
Как решать конфликты:
- Наладить контакт - обозначить проблему, предложить спокойно обсудить
- Выяснить как конфликтующие стороны видят ситуацию, их позитивные намерения и желаемые изменения в поведении оппонента
- Договор - обсудить на какие уступки могут пойти стороны конфликта и заключить договор (устный, MN-ка)
#note #stratoplan #managment
Очередной обзор на обучение в стратоплане. В этом модуль обсуждали, как принимать решения. Модуль более сфокусированный, чем предыдущий. В предыдущем поверхностно прошли по куче концепций. В этом же модуле обсуждали 2 крупные концепции: алгоритм принятия решений и алгоритм решения конфликтов
Алгоритм принятия решений
Алгоритм состоит из 5 шагов:
1. Является ли это решение своевременным и актуальным для вас?
2. Имеется ли вся информация для принятия решения?
3. Есть ли подробный план реализации?
4. Заинтересованы ли в этом решении компания, руководитель, ЛПР?
5. Чувствую ли я себя хорошо при принятии решения?
Алгоритм одновременно и простой и сложный. Простой - потому что, когда смотришь на него, думаешь "не ну это и так очевидно". Сложный - потому что спотыкаешься, когда пробуешь применить.
Например, возьмем 2 шаг - "Имеется ли вся информация для принятия решения?". Как это понять?
Чтобы решить этот шаг необходимо собрать всю информацию. Как это сделать? Здесь может помочь метод "4 ячейки". Суть метод в том, что мы делим квадрат на 4 части
1. Что я знаю
2. Что я не знаю, но я понимаю, что я этого не знаю
3. Что я знаю, но я не понимаю, что это относится к теме
4. Что я не знаю, но не понимаю, что я этого не знаю
Эти 4 пункта позволяют найти поинты, которые необходимо дополнительно исследовать и поинты, которые необходимо проресерчить. Четвертый пункт - самый интересный. С одной стороны кажется, что он не имеет смысла. Ведь как я могу написать то, чего не представляю. Но на практике, описывая этот квадрат, мозг может найти что-то на подкорке сознания и перенести это в пункт 2 - не знаю, но теперь понял что это надо узнать.
После того как вся информация собрана, её надо проанализировать, ведь не вся информация одинаково полезна. Надо понять:
- К чему обращается информация - это логика, эмоции, правила
- Про интерпретировать. Какая основная мысль?
- Проанализировать. Действительно ли информация верна?
Последний шаг также интересен - "Чувствую ли я себя хорошо при принятии решения?". Суть в том, что перед принятием решения вы должны чувствовать себя хорошо и само решение должно вам нравится.
По поводу "чувствовать себя хорошо". Есть целое исследование на основе отчетов израильской судебной системы, которое говорит, что судьи выносят "хорошие" решения утром, перед обедом выносят "плохие решения", после обеда цикл повторяется до ужина (или перекуса), под конец рабочего дня выносятся в основном "плохие" решения. Ваше эмоциональное состояние сильно влияет на принимаемые вами решения.
Когда вы приняли решение, вы должны понимать, что принимаете его исходя из чьих то целей:
- Компании
- Команды
- Членов команды
- Конечного продукта
Если вы приходите и говорите "я так решил", то это плохой путь.
Теперь интересное про конфликты
Формула конфликта: Конфликт (открытое противостояние) = Конфликтная ситуация (набор условий, из которых конфликт может появиться) + Конфликтоген (слова и действия, запускающие конфликт)
Формула конструктива:
- Конструктив = Конфликтная ситуация - Конфликтоген
- Конструктив = Конфликт - Конфликтная ситуация - (Конфликтоген)
Т.е. вам либо надо находить конфликтоген и убирать его, либо убирать конфликтную ситуацию.
Что интересно, в любом конфликте (если в нем не участвуют социопаты) у обоих конфликтующих сторон есть позитивное намерение. Обе стороны считают, что делают что-то хорошее, а их оппонент - что-то плохое. Позитивное намерение зачастую неочевидно для оппонента. Чтобы решить конфликт - необходимо обозначить позитивные намерения обеих сторон, тогда появляется шанс перейти в конструктив и поиск вин-вин ситуации.
Как решать конфликты:
- Наладить контакт - обозначить проблему, предложить спокойно обсудить
- Выяснить как конфликтующие стороны видят ситуацию, их позитивные намерения и желаемые изменения в поведении оппонента
- Договор - обсудить на какие уступки могут пойти стороны конфликта и заключить договор (устный, MN-ка)
#note #stratoplan #managment
PNAS
Extraneous factors in judicial decisions
Are judicial rulings based solely on laws and facts? Legal formalism holds that judges apply legal reasons to the facts of a case in a rational, me...
Дайджест за 2025-04-14 - 2025-04-18
How to get deep traces in your Node.js backend with OTel and Deno
Deno в одном из недавних релизов добавили нативную поддержку Open Telemetry - инструментария, которая добавляет возможности для observability вашей системы. Буквально можно смотреть на что конкретно было затрачено время, пока сервер отвечал пользователю.
Данная статья в целом не погружается в глубоко работу Open Telemetry, но подсвечивают, что OT в nodejs сделан через костыли, а для подключения надо написать 2 экрана кода (в свое время сам ужаснулся этой SDK), а в Deno достаточно указать ключ запуска deno
Конспект книги Team Topologies, часть №1 - team-first mindset
Основные концепции:
Team-first mindset
Команда - самый эффективный способ организации людей для решения проблем. Поэтому важно перестроить сознание на team-first и уметь работать с командами:
Конспект книги Team Topologies, часть №2 - типы команд и взаимодействия
Во всех компаниях разная культура, разные процессы и разные команды. Но фундаментально все команды и взаимодействия между ними можно свести к 4 базовым видам команд и 3 базовым видам взаимодействия
Конспект книги Team Topologies, часть №3 - итоги
В этом посте не будет какой-то прям новой инфы из книги. Тут я резюмирую про что книга и для кого
В рамках предыдущих постов я срезал очень много углов т.к. уместить 200-300 страниц в 8000 символов и не потерять смысл - сложно.
Обучение в стратоплане: обзор на модуль про принятие решений
Очередной обзор на обучение в стратоплане. В этом модуль обсуждали, как принимать решения. Модуль более сфокусированный, чем предыдущий. В предыдущем поверхностно прошли по куче концепций. В этом же модуле обсуждали 2 крупные концепции: алгоритм принятия решений и алгоритм решения конфликтов
——————————————
Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегам или друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂
How to get deep traces in your Node.js backend with OTel and Deno
Deno в одном из недавних релизов добавили нативную поддержку Open Telemetry - инструментария, которая добавляет возможности для observability вашей системы. Буквально можно смотреть на что конкретно было затрачено время, пока сервер отвечал пользователю.
Данная статья в целом не погружается в глубоко работу Open Telemetry, но подсвечивают, что OT в nodejs сделан через костыли, а для подключения надо написать 2 экрана кода (в свое время сам ужаснулся этой SDK), а в Deno достаточно указать ключ запуска deno
Конспект книги Team Topologies, часть №1 - team-first mindset
Основные концепции:
Team-first mindset
Команда - самый эффективный способ организации людей для решения проблем. Поэтому важно перестроить сознание на team-first и уметь работать с командами:
Конспект книги Team Topologies, часть №2 - типы команд и взаимодействия
Во всех компаниях разная культура, разные процессы и разные команды. Но фундаментально все команды и взаимодействия между ними можно свести к 4 базовым видам команд и 3 базовым видам взаимодействия
Конспект книги Team Topologies, часть №3 - итоги
В этом посте не будет какой-то прям новой инфы из книги. Тут я резюмирую про что книга и для кого
В рамках предыдущих постов я срезал очень много углов т.к. уместить 200-300 страниц в 8000 символов и не потерять смысл - сложно.
Обучение в стратоплане: обзор на модуль про принятие решений
Очередной обзор на обучение в стратоплане. В этом модуль обсуждали, как принимать решения. Модуль более сфокусированный, чем предыдущий. В предыдущем поверхностно прошли по куче концепций. В этом же модуле обсуждали 2 крупные концепции: алгоритм принятия решений и алгоритм решения конфликтов
——————————————
Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегам или друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂
Introducing Zod 4 beta
Спустя несколько лет с выхода Zod v3 выпустили бетку Zod v4. Zod - библиотека для валидации объектов на мэтч с переданной схемой.
В 4-м релизе увеличили скорость работы валидации и работы TS по валидации типов, уменьшили размер бандла, добавили новые удобные API. Если вы используете Zod - рекомендую запланировать обновление.
Что интересного уже есть в бетке
Ускорение
- В 2.6 раз быстрее парсинг строк
- в 3 раза быстрее парсинг массивов
- в 8 раз быстрее парсинг объектов
- в 20 раз ускорение инициализации typescript на типах Zod
- в 2 раза уменьшили бандл сайз
- Если вам этого мало - сделали
Улучшили работу со схемами:
Сделали отдельную систему для описания метаданных к схемам
Сделали вывод JSON-схемы
Сделали новое API для корректного получения типа объекта. В посте упоминают кейс, когда у одной схемы поле - опциональное (можно не указать), а другой - обязательное, но значение может быть
Разница небольшая, но она есть. В Zod3 нельзя получить корректный тип для этих объектов.
В Zod4 добавили новый метод, который это умеет, но опциональность ключа там указывается в имени ключа (что, конечно, странно. В друг у нас действительно поле со знаком в конце, что тогда делать?)
Кроме того,
Обработка ошибок
Во первых, добавили возможность указать локаль для вывода ошибок
Во вторых, улучшили форматирование ошибок
В общем, интересный большой апдейт для важной библиотеки.
https://v4.zod.dev/v4
#development #javascript #library #zod #release
Спустя несколько лет с выхода Zod v3 выпустили бетку Zod v4. Zod - библиотека для валидации объектов на мэтч с переданной схемой.
В 4-м релизе увеличили скорость работы валидации и работы TS по валидации типов, уменьшили размер бандла, добавили новые удобные API. Если вы используете Zod - рекомендую запланировать обновление.
Что интересного уже есть в бетке
Ускорение
- В 2.6 раз быстрее парсинг строк
- в 3 раза быстрее парсинг массивов
- в 8 раз быстрее парсинг объектов
- в 20 раз ускорение инициализации typescript на типах Zod
- в 2 раза уменьшили бандл сайз
- Если вам этого мало - сделали
@zod/mini, который содержит основной функционал и весит в 6.6 раз меньшеУлучшили работу со схемами:
Сделали отдельную систему для описания метаданных к схемам
import * as z from "zod";
const myRegistry = z.registry<{ title: string; description: string }>();
const emailSchema = z.string().email();
myRegistry.add(emailSchema, { title: "Email address", description: "..." });
myRegistry.get(emailSchema);
// => { title: "Email address", ... }
Сделали вывод JSON-схемы
import * as z from "zod";
const mySchema = z.object({name: z.string(), points: z.number()});
z.toJSONSchema(mySchema);
// => {
// type: "object",
// properties: {
// name: {type: "string"},
// points: {type: "number"},
// },
// required: ["name", "points"],
// }
Сделали новое API для корректного получения типа объекта. В посте упоминают кейс, когда у одной схемы поле - опциональное (можно не указать), а другой - обязательное, но значение может быть
undefined. Т.е. грубо говоряtype Obj1 = {
prop?: string;
}
type Obj2 = {
prop: string | undefined;
}
Разница небольшая, но она есть. В Zod3 нельзя получить корректный тип для этих объектов.
z.object({ name: z.string().optional() });
// { name?: string | undefined }
z.object({ name: z.union([z.string(), z.undefined()]) });
// { name?: string | undefined }
В Zod4 добавили новый метод, который это умеет, но опциональность ключа там указывается в имени ключа (что, конечно, странно. В друг у нас действительно поле со знаком в конце, что тогда делать?)
const ValueOptional = z.interface({ name: z.string().optional()});
// { name: string | undefined }
const KeyOptional = z.interface({ "name?": z.string() });
// { name?: string }
Кроме того,
z.interface позволяет описывать цикличные типы проще, чем это было в Zod3import * as z from "zod"; // zod@4
const Category = z.interface({
name: z.string(),
get subcategories() {
return z.array(Category)
}
});
Обработка ошибок
Во первых, добавили возможность указать локаль для вывода ошибок
import * as z from "zod";
// configure English locale (default)
z.config(z.locales.en());
Во вторых, улучшили форматирование ошибок
✖ Unrecognized key: "extraField"
✖ Invalid input: expected string, received number
→ at username
✖ Invalid input: expected number, received string
→ at favoriteNumbers[1]
В общем, интересный большой апдейт для важной библиотеки.
https://v4.zod.dev/v4
#development #javascript #library #zod #release
Zod
Introducing Zod 4 | Zod
The new Cookie Store API
Внезапно узнал, что уже 4 года как существует новое API для работы с куками, которое давно доступно в Chrome, недавно стало доступно в Safari и все еще недоступно в Firefox - Cookie Store API
Новое API намного удобнее. Хотя любое API, по сравнению со старым, будет удобнее.
Первое, что бросается в глаза - это человеческий интерфейс для установки. Если вам нужно просто установить значение -
Второе, что бросается в глаза - это то, что все взаимодействие стало асинхронным
Тут я не совсем понял смысла от асинхронщины, но методы будут бросать ошибки - что тоже хорошо.
Еще 1 фича не бросается в глаза, но она очень крутая - можно наконец-то подписаться на изменения кук и увидеть измененные и удаленные куки
Пример использования из статьи: синхронизируем состояние стора с состоянием куки
В общем, выглядит многообещающе. Ждем открытия без флага в Firefox и можно юзать. Но если хочется уже использовать, то должны быть рабочие полифилы.
https://fotis.xyz/posts/the-new-cookie-store-api/
#development #javascript #cookie
Внезапно узнал, что уже 4 года как существует новое API для работы с куками, которое давно доступно в Chrome, недавно стало доступно в Safari и все еще недоступно в Firefox - Cookie Store API
Новое API намного удобнее. Хотя любое API, по сравнению со старым, будет удобнее.
Первое, что бросается в глаза - это человеческий интерфейс для установки. Если вам нужно просто установить значение -
cookieStore.set("cookie1", "cookie1-value");. Если вам нужна полная настройка:cookieStore.set({
name: 'theme',
value: 'dark',
path: '/',
partitioned: false,
sameSite: 'strict',
});
Второе, что бросается в глаза - это то, что все взаимодействие стало асинхронным
try {
await cookieStore.set("cookie1", "cookie1-value");
} catch (error) {
console.log(`Error setting cookie1: ${error}`);
}
Тут я не совсем понял смысла от асинхронщины, но методы будут бросать ошибки - что тоже хорошо.
Еще 1 фича не бросается в глаза, но она очень крутая - можно наконец-то подписаться на изменения кук и увидеть измененные и удаленные куки
cookieStore.addEventListener('change', (event) => {
console.log(event);
});
Пример использования из статьи: синхронизируем состояние стора с состоянием куки
cookieStore.addEventListener('change', (event) => {
const deleted = ev.deleted.find((c) => c.name === THEME_COOKIE_NAME);
if (deleted) {
setStoredTheme(undefined);
return;
}
const changed = ev.changed.find((c) => c.name === THEME_COOKIE_NAME);
if (changed) {
setStoredTheme(changed.value);
return;
}
})
В общем, выглядит многообещающе. Ждем открытия без флага в Firefox и можно юзать. Но если хочется уже использовать, то должны быть рабочие полифилы.
https://fotis.xyz/posts/the-new-cookie-store-api/
#development #javascript #cookie
Fotis Papadogeorgopoulos
The new Cookie Store API
Introducing the relatively new Cookie Store API, and what it means for web applications.
Дайджест за 2025-04-21 - 2025-04-25
Introducing Zod 4 beta
Спустя несколько лет с выхода Zod v3 выпустили бетку Zod v4. Zod - библиотека для валидации объектов на мэтч с переданной схемой.
В 4-м релизе увеличили скорость работы валидации и работы TS по валидации типов, уменьшили размер бандла, добавили новые удобные API. Если вы используете Zod - рекомендую запланировать обновление.
The new Cookie Store API
Внезапно узнал, что уже 4 года как существует новое API для работы с куками, которое давно доступно в Chrome, недавно стало доступно в Safari и все еще недоступно в Firefox - Cookie Store API
Новое API намного удобнее. Хотя любое API, по сравнению со старым, будет удобнее.
——————————————
Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегам или друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂
Introducing Zod 4 beta
Спустя несколько лет с выхода Zod v3 выпустили бетку Zod v4. Zod - библиотека для валидации объектов на мэтч с переданной схемой.
В 4-м релизе увеличили скорость работы валидации и работы TS по валидации типов, уменьшили размер бандла, добавили новые удобные API. Если вы используете Zod - рекомендую запланировать обновление.
The new Cookie Store API
Внезапно узнал, что уже 4 года как существует новое API для работы с куками, которое давно доступно в Chrome, недавно стало доступно в Safari и все еще недоступно в Firefox - Cookie Store API
Новое API намного удобнее. Хотя любое API, по сравнению со старым, будет удобнее.
——————————————
Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегам или друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂
Impossible Components
Статья от Дэна Абрамова про новые возможности, которые открываются при использовании Server Components. А именно - возможность писать единый код, часть которого исполняется на сервере, а часть на клиенте. Бесшовная интеграция значительно повышает DX и выразительность решений.
Дэн доходчиво показывает основные возможности и объясняет концепции серверных компонентов, раскрывая эти идеи последовательно и с хорошими примерами кода.
В целом, всю статью можно свести к следующей мысли: никогда еще не было так просто писать фронтенд с серверной логикой, не теряя при этом в DX и возможностях композиции решений.
Строго рекомендую к прочтению
https://overreacted.io/impossible-components/
#development #javascript #react #reactServerComponents #danAbramov
Статья от Дэна Абрамова про новые возможности, которые открываются при использовании Server Components. А именно - возможность писать единый код, часть которого исполняется на сервере, а часть на клиенте. Бесшовная интеграция значительно повышает DX и выразительность решений.
Дэн доходчиво показывает основные возможности и объясняет концепции серверных компонентов, раскрывая эти идеи последовательно и с хорошими примерами кода.
В целом, всю статью можно свести к следующей мысли: никогда еще не было так просто писать фронтенд с серверной логикой, не теряя при этом в DX и возможностях композиции решений.
Строго рекомендую к прочтению
https://overreacted.io/impossible-components/
#development #javascript #react #reactServerComponents #danAbramov
overreacted.io
Impossible Components — overreacted
Composing across the stack.
Spectacle
Библиотека для создания презентаций на React. Выглядит неплохо, надо будет попробовать как нибудь. Большой плюс - наличие готовых лейаутов для слайдов (список, колонки, картинка справа, картинка сверху и другие базовые лэйауты).
https://nearform.com/open-source/spectacle/
#development #javascript #react #library #presentations
Библиотека для создания презентаций на React. Выглядит неплохо, надо будет попробовать как нибудь. Большой плюс - наличие готовых лейаутов для слайдов (список, колонки, картинка справа, картинка сверху и другие базовые лэйауты).
https://nearform.com/open-source/spectacle/
#development #javascript #react #library #presentations
spectacle Documentation
Spectacle - React library for sleek presentations, using JSX syntax
A React.js based library for creating sleek presentations using JSX syntax that gives you the ability to live demo your code.
Advanced React in the Wild: Часть №1
Большой пост про исследование перформанса больших веб приложений. В статье рассмотрены варианты улучшения перформанса для разных приложений - кому-то важно SEO, кому-то скорость переключения роутов. Все кейсы - кейсы реальных компаний с замерами.
Обзор всех кейсов не влезет в 1 пост в телеге, поэтому будет целых 2 поста
Итак, первый кейс - компания Vio.com. Компания имела плохой скор Interaction to Next Paint (INP). Т.е. было большое время между взаимодействимем с элементов на странице и перерисовкой интерфейса. Рекомендация от гугла - 200ms. Цифра Vio - 380ms. Google в марте 2024 официально заявила, что INP является одним из фактором для ранжирования в поисковой выдаче
Что сделали в Vio
Провели анализ перформанса с помощью Chrome DevTools и Lighthouse, обнаружили проблемы, разметили код кастомными User Timing метками и поработали с React профайлером и обнаружили ключевые ботлнеки в перформансе приложения. В частности, обнражили reflow, из-за которого браузер ререндерил слишком много элементов
Более агрессивно разделили код на асинхронные чанки с помощью
Также они обнаружили, что слишком частая обработка некоторых событий блокировала главный тред. Добавили дебаунсы.
Также обнаружили лишние ререндеры в React'е. Ререндерелись те части приложения, которые не должны были ререндерится. Добавили
Обновили React до React18, что позволило перейти на concurrent rendering - это улучшило INP в 2 раза: на десктопе 450ms=>240ms, на мобилке: 1100ms => 500ms (хотя в начале исследования писалось что INP - 380ms. Откуда взялось такое разночтение (450 и 1100 vs 380) - я не понял).
Еще из интересных хаков - прерывание некритичной логики долгих обработчиков для освобождения main thread. При этом пример приведен немного странный - отправка аналитики. Отправка аналитики, по идее, и не должна блокировать основной поток, но да ладно. Одно из классических решений - перенести логику в воркер или сервис-воркер. Что сделали в Vio: откладывают выполнение части кода на другой тик с помощью промиса
Решение максимально простое, но это позволило улучшить INP на 19% (улучшили на 120ms, и тут опять расхождения с заявляемыми в начале значениями)
Как улучшили ререндеры React'а:
- Разделили сложные кастомные хуки на маленькие
- Заменили React Router API на window.location везде где смогли
- Улучшили мемоизацию Redux селекторов
Это позволило ускорить INP еще на 45% (снова не могу не пожаловаться, но непонятно от чего считалось ускорение т.к. по тексту суммарное ускорение уже больше 100%, поэтому это явно не от начальных цифр, а от одной из предыдущих итераций)
Каких результатов достигли:
- INP улучшился с 380ms до 175ms
- Загружаемый JS уменьшили на 60%
- Уменьшили количество ненужных ререндеров
- Интерфейс стал отзывчивее
Что здесь важного:
- Не какая-то абстрактная теория, а практические советы
- Даны, с одной стороны, простые советы, а с другой стороны - действенные
- Перформанс улучшается не просто так, а для достижения целей бизнеса - необходимо предоставлять хороший сервис и встать выше в поисковой выдаче гугла
- Хорошая инженерная работа - провели анализ перформанса, нашли ботленки и проблемы, сделали улучшения, замерили метрики "до" и "после". Это перекликается с книгой, обзор на которую я кидал в канал - "Современная программная инженерия" - вместо того, чтобы сразу делать улучшения, необходимо собрать метрики и провести анализ, чтобы принять правильное решение о необходимых улучшениях и оценить результат
Продолжение будет завтра
https://largeapps.dev/case-studies/advanced/
#development #javascript #performance #research
Большой пост про исследование перформанса больших веб приложений. В статье рассмотрены варианты улучшения перформанса для разных приложений - кому-то важно SEO, кому-то скорость переключения роутов. Все кейсы - кейсы реальных компаний с замерами.
Обзор всех кейсов не влезет в 1 пост в телеге, поэтому будет целых 2 поста
Итак, первый кейс - компания Vio.com. Компания имела плохой скор Interaction to Next Paint (INP). Т.е. было большое время между взаимодействимем с элементов на странице и перерисовкой интерфейса. Рекомендация от гугла - 200ms. Цифра Vio - 380ms. Google в марте 2024 официально заявила, что INP является одним из фактором для ранжирования в поисковой выдаче
Что сделали в Vio
Провели анализ перформанса с помощью Chrome DevTools и Lighthouse, обнаружили проблемы, разметили код кастомными User Timing метками и поработали с React профайлером и обнаружили ключевые ботлнеки в перформансе приложения. В частности, обнражили reflow, из-за которого браузер ререндерил слишком много элементов
Более агрессивно разделили код на асинхронные чанки с помощью
React.lazy и Suspense. Таким образом, они уменьшили код, необходимый для первоначальной работы страницы.Также они обнаружили, что слишком частая обработка некоторых событий блокировала главный тред. Добавили дебаунсы.
Также обнаружили лишние ререндеры в React'е. Ререндерелись те части приложения, которые не должны были ререндерится. Добавили
React.memo и useMemo в критичные места.Обновили React до React18, что позволило перейти на concurrent rendering - это улучшило INP в 2 раза: на десктопе 450ms=>240ms, на мобилке: 1100ms => 500ms (хотя в начале исследования писалось что INP - 380ms. Откуда взялось такое разночтение (450 и 1100 vs 380) - я не понял).
Еще из интересных хаков - прерывание некритичной логики долгих обработчиков для освобождения main thread. При этом пример приведен немного странный - отправка аналитики. Отправка аналитики, по идее, и не должна блокировать основной поток, но да ладно. Одно из классических решений - перенести логику в воркер или сервис-воркер. Что сделали в Vio: откладывают выполнение части кода на другой тик с помощью промиса
async function yieldToMain() {
return new Promise((resolve) => {
setTimeout (resolve, 0);
});
}
// Usage in tracking middleware
case trackEvent.type: {
await yieldToMain();
trackAnalyticsEvent();
await yieldToMain();
logEvent();
}
Решение максимально простое, но это позволило улучшить INP на 19% (улучшили на 120ms, и тут опять расхождения с заявляемыми в начале значениями)
Как улучшили ререндеры React'а:
- Разделили сложные кастомные хуки на маленькие
- Заменили React Router API на window.location везде где смогли
- Улучшили мемоизацию Redux селекторов
Это позволило ускорить INP еще на 45% (снова не могу не пожаловаться, но непонятно от чего считалось ускорение т.к. по тексту суммарное ускорение уже больше 100%, поэтому это явно не от начальных цифр, а от одной из предыдущих итераций)
Каких результатов достигли:
- INP улучшился с 380ms до 175ms
- Загружаемый JS уменьшили на 60%
- Уменьшили количество ненужных ререндеров
- Интерфейс стал отзывчивее
Что здесь важного:
- Не какая-то абстрактная теория, а практические советы
- Даны, с одной стороны, простые советы, а с другой стороны - действенные
- Перформанс улучшается не просто так, а для достижения целей бизнеса - необходимо предоставлять хороший сервис и встать выше в поисковой выдаче гугла
- Хорошая инженерная работа - провели анализ перформанса, нашли ботленки и проблемы, сделали улучшения, замерили метрики "до" и "после". Это перекликается с книгой, обзор на которую я кидал в канал - "Современная программная инженерия" - вместо того, чтобы сразу делать улучшения, необходимо собрать метрики и провести анализ, чтобы принять правильное решение о необходимых улучшениях и оценить результат
Продолжение будет завтра
https://largeapps.dev/case-studies/advanced/
#development #javascript #performance #research
Advanced React in the Wild: Часть №2
Продолжаем читать большое исследование перформанса веб-проектов. Следующая компания - DoorDash. Приложение рендерится только на клиенте и оно очень большое - долго грузится, огромный JS-бандл, плохие SEO-метрики. При загрузке сайта пользователи долго наблюдают белый экран.
Что они сделали:
Во первых, начали переходить на Next.js для серверного рендеринга. Переход не моментальынй, а по-страничный.
Ключевые поинты при миграции:
- Использование ленивой гидрации. Чтобы оптимизировать скорость отдачи первого байта, некритичные компоненты подгружались лениво во время SSR. Это позволило ускорить отдачу первого контента + уменьшило нагрузку на CPU
- Сделали единый контекст для SSR и CSR. Оттуда следует доставать куки, урл и все другое, что зависит от окружения. Также в контексте присутствует флаг
Результаты:
- +12-15% ускорения загрузки страницы
- LCP улучшился на 65%
- Все это без глобальных переписываний - делали инкрементально и по шагам
Следующая компания - Preply
Проблема - плохой INP. Они посчитали, что улучшение INP может сохранить $200k в год. При этом приложение написано на старом Next.js, где нет серверных компонентов.
Что сделали:
- Провели анализ код с помощью девтулов и react-профайлера. Главная задача - разгрузить главный поток, поэтому оптимизировали ререндеры, рекомпозировали большие функции, оптимизировали циклы
- Завернули некритичные части интерфейса в
- Оптимизировали тяжелые обработчики событий, которые делали сложные обновления стейта. Добавили к ним
- Применили агрессивный код-сплиттинг
- Подключили CDN для асетов и части API, которое можно кешировать (если я правильно понял). Это позволило уменьшить сетевую задержку с 1.5s => 0.5s
Результаты:
- Улучшили INP 250ms=>175ms, перейдя в "зеленую" зону, с точки зрения оценки метрикой гуглом.
Следующая компания - GeekyAnts
Сайт компании имел Lighthouse скор около 50. Для консалтинговой компании это такое себе.
Что сделали:
- Обновили Next.js, перешли на серверные компоненты. Все неинтерактивное перенесли на сервер, что ускорило отдачу конента и уменьшило размер JS в браузере.
- Перенесли загрузку данных с браузера на сервер, что также значительно все ускорило
- Подключили оптимизации Next.js - код-сплиттинг, Image компонент, стриминг при SSR
Результат:
- Lighthouse скор улучшился до 90+
- Улучшился SEO
Последний кейс: Inggest
Проблема: белый экран при открытии сайта
Что сделали:
- Статичный пререндер + стриминг - позволили добиться хорошего UX. Там где можно пререндерить - они пререндерили. Там где нужны динамические данные - подключили стриминг
- Тюнили кэширование в Next.js. Добились мгновенного отображения некоторых страниц
- Улучшили DX за счет Next.js
Результаты:
- Вместо белого экрана при смене роута - шапка и футер стали отображаться моментально, а контент подгружался прогрессивно
- Улучшили UX и DX одновременно
https://largeapps.dev/case-studies/advanced/
#development #javascript #performance #research
Продолжаем читать большое исследование перформанса веб-проектов. Следующая компания - DoorDash. Приложение рендерится только на клиенте и оно очень большое - долго грузится, огромный JS-бандл, плохие SEO-метрики. При загрузке сайта пользователи долго наблюдают белый экран.
Что они сделали:
Во первых, начали переходить на Next.js для серверного рендеринга. Переход не моментальынй, а по-страничный.
Ключевые поинты при миграции:
- Использование ленивой гидрации. Чтобы оптимизировать скорость отдачи первого байта, некритичные компоненты подгружались лениво во время SSR. Это позволило ускорить отдачу первого контента + уменьшило нагрузку на CPU
- Сделали единый контекст для SSR и CSR. Оттуда следует доставать куки, урл и все другое, что зависит от окружения. Также в контексте присутствует флаг
isSSR, что позволяет инкрементально подготавливать необходимые фичи на SSR.Результаты:
- +12-15% ускорения загрузки страницы
- LCP улучшился на 65%
- Все это без глобальных переписываний - делали инкрементально и по шагам
Следующая компания - Preply
Проблема - плохой INP. Они посчитали, что улучшение INP может сохранить $200k в год. При этом приложение написано на старом Next.js, где нет серверных компонентов.
Что сделали:
- Провели анализ код с помощью девтулов и react-профайлера. Главная задача - разгрузить главный поток, поэтому оптимизировали ререндеры, рекомпозировали большие функции, оптимизировали циклы
- Завернули некритичные части интерфейса в
Suspense, сделав гидрацию неблокирующей (фича React18)- Оптимизировали тяжелые обработчики событий, которые делали сложные обновления стейта. Добавили к ним
startTransition (React18 API для конкурентного режима), что пометило обработку как low-priority и React не забивал основной поток для обработки события. Также подключили дебаунс и тротлинг для частых событий- Применили агрессивный код-сплиттинг
- Подключили CDN для асетов и части API, которое можно кешировать (если я правильно понял). Это позволило уменьшить сетевую задержку с 1.5s => 0.5s
Результаты:
- Улучшили INP 250ms=>175ms, перейдя в "зеленую" зону, с точки зрения оценки метрикой гуглом.
Следующая компания - GeekyAnts
Сайт компании имел Lighthouse скор около 50. Для консалтинговой компании это такое себе.
Что сделали:
- Обновили Next.js, перешли на серверные компоненты. Все неинтерактивное перенесли на сервер, что ускорило отдачу конента и уменьшило размер JS в браузере.
- Перенесли загрузку данных с браузера на сервер, что также значительно все ускорило
- Подключили оптимизации Next.js - код-сплиттинг, Image компонент, стриминг при SSR
Результат:
- Lighthouse скор улучшился до 90+
- Улучшился SEO
Последний кейс: Inggest
Проблема: белый экран при открытии сайта
Что сделали:
- Статичный пререндер + стриминг - позволили добиться хорошего UX. Там где можно пререндерить - они пререндерили. Там где нужны динамические данные - подключили стриминг
- Тюнили кэширование в Next.js. Добились мгновенного отображения некоторых страниц
- Улучшили DX за счет Next.js
Результаты:
- Вместо белого экрана при смене роута - шапка и футер стали отображаться моментально, а контент подгружался прогрессивно
- Улучшили UX и DX одновременно
https://largeapps.dev/case-studies/advanced/
#development #javascript #performance #research
Advanced React in the Wild: Часть №3
Заключительная часть. Какие итоги можно вынести из этих кейсов?
Оптимизация перформанса - крайне важна
- Оптимизируя Core Web Vitals вы улучшаете как опыт пользователя, так и свои позиции в поисковой выдаче гугла. Вместе это ведет к экономии денег на привлечение и удержание клиентов
- Уменьшение JS-бандов значительно ускоряет работу страницы
- Нужно уметь разгружать основной поток. Либо руками (как делали в первом кейсе), либо используя фишки React18 и других фреймворков, либо используя доступное браузерное API для подобных оптимизаций
Необходимо найти баланс между SSR и CSR
- Нет единственно верного решения по выбору между SSR и CSR. Разные компании выбрали разные решения для оптимизации своих приложений.
- SSR нужен для ускорения первоначальной загрузки сайта и SEO
- CSR нужен для интерактивности и логики на UI. Например, используя CSR с правильными стратегиями кэширования и подзагрузки чанков, пользователи будут ощущать более высокую работу сайта при переходе в навигации сайта
- Прогрессивная гидрация и островная архитектура берут лучшее из SSR и CSR, давай оптимальный опыт всем
- SSR легко сделать неправильно, что приведет к плохим метриками
- Совет от авторов: используйте SSR чтобы сайт хорошо работал (быстро отдавать контент, лучший SEO), затем сделайте его быстрым, подтюнивая и включая CSR там, где это улучшит UX.
Применяйте кэширование правильно
- Кэширование на edge и CDN ускоряют загрузку ресурсов пользователями и улучшают их опыт
- Оптимизация кэширования в Next.js (и других фреймворках) может значительно улучшить UX
- С кэшированием нужно быть осторожным. Ошибка в кэшировании может дорого стоить
Улучшайте работу со стейт-менеджерами
- Не перемудрите с глобальным состоянием. Глобальное состояние - это всегда сложно. Используйте то, что проще (в том числе встроенные в фреймворк средства).
- Используйте те инструменты, которые умеют в модульность и которые хорошо выполняют свою часть работы. Например, React Query + Zustand намного проще, чем Redux.
- Чем проще - тем лучше. Сложные решения - сложно поддерживать. Сделать правильно, но на redux может быть намного дольше и сложнее, чем заиспользовать Context + useState
Улучшайте опыт разработчика (DX)
- Используйте бест-практисы вашего фреймворка. Например, гайды от Next.js, если вы используете Next.js
- Используйте те инструменты, которые позволяют делать быстрые и мелкие итерации. Если у вас хот-релоад занимает 30 секунд, то ни о какой быстрой разработке не может быть и речи
- Улучшайте CI CD и релизный процесс. Чем лучше у вас настроеная непрерывная интеграция и выкладка, тем проще вам идти небольшими итерациями и тем больше уверенности в этих итерациях
- Используйте React-примитивы по назначению. Suspense и Error Boundaries значительно улучшают как DX, так и UX
- Вкладывайтесь в обучение и образование. Читайте, смотрите, экспериментируйте.
Доступность из коробки
- Используйте семантичный HTML и ARIA атрибуты
- Вложитесь в корректную работу навигации с клавиатуры и управление фокусом
- Постоянно проверяйте сайт на доступность
Улучшайте UX
- Быстрее загрузка, раньше возможность взаимодействовать => счастливые юзеры => успешный бизнес.
- Бесшовная навигация и переходы позволяют юзеру работать без остановки
- Работайте с фидбеком от юзеров и используйте метрики перформанса, собранный с юзеров, а не собранные самостоятельно
Советы от авторов
- Замеряйте и оптимизируйте то, что вам нужно оптимизировать (разным сайтам важны разные аспекты перформанса)
- Адоптируйте новые фичи Next.js и React18 (или ваших инструментариев). Это улучшит и перформанс и DX
- Кэшируйте агрессивно, но осторожно
- Сделайте менеджмент состояния простым
- Инвестируйте в DX и архитектуру
- Делайте хорошо для юзера сразу
https://largeapps.dev/case-studies/advanced/
#development #javascript #performance #research
Заключительная часть. Какие итоги можно вынести из этих кейсов?
Оптимизация перформанса - крайне важна
- Оптимизируя Core Web Vitals вы улучшаете как опыт пользователя, так и свои позиции в поисковой выдаче гугла. Вместе это ведет к экономии денег на привлечение и удержание клиентов
- Уменьшение JS-бандов значительно ускоряет работу страницы
- Нужно уметь разгружать основной поток. Либо руками (как делали в первом кейсе), либо используя фишки React18 и других фреймворков, либо используя доступное браузерное API для подобных оптимизаций
Необходимо найти баланс между SSR и CSR
- Нет единственно верного решения по выбору между SSR и CSR. Разные компании выбрали разные решения для оптимизации своих приложений.
- SSR нужен для ускорения первоначальной загрузки сайта и SEO
- CSR нужен для интерактивности и логики на UI. Например, используя CSR с правильными стратегиями кэширования и подзагрузки чанков, пользователи будут ощущать более высокую работу сайта при переходе в навигации сайта
- Прогрессивная гидрация и островная архитектура берут лучшее из SSR и CSR, давай оптимальный опыт всем
- SSR легко сделать неправильно, что приведет к плохим метриками
- Совет от авторов: используйте SSR чтобы сайт хорошо работал (быстро отдавать контент, лучший SEO), затем сделайте его быстрым, подтюнивая и включая CSR там, где это улучшит UX.
Применяйте кэширование правильно
- Кэширование на edge и CDN ускоряют загрузку ресурсов пользователями и улучшают их опыт
- Оптимизация кэширования в Next.js (и других фреймворках) может значительно улучшить UX
- С кэшированием нужно быть осторожным. Ошибка в кэшировании может дорого стоить
Улучшайте работу со стейт-менеджерами
- Не перемудрите с глобальным состоянием. Глобальное состояние - это всегда сложно. Используйте то, что проще (в том числе встроенные в фреймворк средства).
- Используйте те инструменты, которые умеют в модульность и которые хорошо выполняют свою часть работы. Например, React Query + Zustand намного проще, чем Redux.
- Чем проще - тем лучше. Сложные решения - сложно поддерживать. Сделать правильно, но на redux может быть намного дольше и сложнее, чем заиспользовать Context + useState
Улучшайте опыт разработчика (DX)
- Используйте бест-практисы вашего фреймворка. Например, гайды от Next.js, если вы используете Next.js
- Используйте те инструменты, которые позволяют делать быстрые и мелкие итерации. Если у вас хот-релоад занимает 30 секунд, то ни о какой быстрой разработке не может быть и речи
- Улучшайте CI CD и релизный процесс. Чем лучше у вас настроеная непрерывная интеграция и выкладка, тем проще вам идти небольшими итерациями и тем больше уверенности в этих итерациях
- Используйте React-примитивы по назначению. Suspense и Error Boundaries значительно улучшают как DX, так и UX
- Вкладывайтесь в обучение и образование. Читайте, смотрите, экспериментируйте.
Доступность из коробки
- Используйте семантичный HTML и ARIA атрибуты
- Вложитесь в корректную работу навигации с клавиатуры и управление фокусом
- Постоянно проверяйте сайт на доступность
Улучшайте UX
- Быстрее загрузка, раньше возможность взаимодействовать => счастливые юзеры => успешный бизнес.
- Бесшовная навигация и переходы позволяют юзеру работать без остановки
- Работайте с фидбеком от юзеров и используйте метрики перформанса, собранный с юзеров, а не собранные самостоятельно
Советы от авторов
- Замеряйте и оптимизируйте то, что вам нужно оптимизировать (разным сайтам важны разные аспекты перформанса)
- Адоптируйте новые фичи Next.js и React18 (или ваших инструментариев). Это улучшит и перформанс и DX
- Кэшируйте агрессивно, но осторожно
- Сделайте менеджмент состояния простым
- Инвестируйте в DX и архитектуру
- Делайте хорошо для юзера сразу
https://largeapps.dev/case-studies/advanced/
#development #javascript #performance #research