Обучение в стратоплане: обзор на модуль про принятие решений

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

Алгоритм принятия решений

Алгоритм состоит из 5 шагов:
1. Является ли это решение своевременным и актуальным для вас?
2. Имеется ли вся информация для принятия решения?
3. Есть ли подробный план реализации?
4. Заинтересованы ли в этом решении компания, руководитель, ЛПР?
5. Чувствую ли я себя хорошо при принятии решения?

Алгоритм одновременно и простой и сложный. Простой - потому что, когда смотришь на него, думаешь "не ну это и так очевидно". Сложный - потому что спотыкаешься, когда пробуешь применить.

Например, возьмем 2 шаг - "Имеется ли вся информация для принятия решения?". Как это понять?
Чтобы решить этот шаг необходимо собрать всю информацию. Как это сделать? Здесь может помочь метод "4 ячейки". Суть метод в том, что мы делим квадрат на 4 части
1. Что я знаю
2. Что я не знаю, но я понимаю, что я этого не знаю
3. Что я знаю, но я не понимаю, что это относится к теме
4. Что я не знаю, но не понимаю, что я этого не знаю

Эти 4 пункта позволяют найти поинты, которые необходимо дополнительно исследовать и поинты, которые необходимо проресерчить. Четвертый пункт - самый интересный. С одной стороны кажется, что он не имеет смысла. Ведь как я могу написать то, чего не представляю. Но на практике, описывая этот квадрат, мозг может найти что-то на подкорке сознания и перенести это в пункт 2 - не знаю, но теперь понял что это надо узнать.

После того как вся информация собрана, её надо проанализировать, ведь не вся информация одинаково полезна. Надо понять:
- К чему обращается информация - это логика, эмоции, правила
- Про интерпретировать. Какая основная мысль?
- Проанализировать. Действительно ли информация верна?

Последний шаг также интересен - "Чувствую ли я себя хорошо при принятии решения?". Суть в том, что перед принятием решения вы должны чувствовать себя хорошо и само решение должно вам нравится.

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

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

Если вы приходите и говорите "я так решил", то это плохой путь.

Теперь интересное про конфликты

Формула конфликта: Конфликт (открытое противостояние) = Конфликтная ситуация (набор условий, из которых конфликт может появиться) + Конфликтоген (слова и действия, запускающие конфликт)

Формула конструктива:
- Конструктив = Конфликтная ситуация - Конфликтоген
- Конструктив = Конфликт - Конфликтная ситуация - (Конфликтоген)

Т.е. вам либо надо находить конфликтоген и убирать его, либо убирать конфликтную ситуацию.

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

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





#note #stratoplan #managment

Дайджест за 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 крупные концепции: алгоритм принятия решений и алгоритм решения конфликтов



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

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

Introducing Zod 4 beta

Спустя несколько лет с выхода 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 позволяет описывать цикличные типы проще, чем это было в Zod3

import * 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

The new Cookie Store API

Внезапно узнал, что уже 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

Дайджест за 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, по сравнению со старым, будет удобнее.

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

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

Impossible Components

Статья от Дэна Абрамова про новые возможности, которые открываются при использовании Server Components. А именно - возможность писать единый код, часть которого исполняется на сервере, а часть на клиенте. Бесшовная интеграция значительно повышает DX и выразительность решений.

Дэн доходчиво показывает основные возможности и объясняет концепции серверных компонентов, раскрывая эти идеи последовательно и с хорошими примерами кода.

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

Строго рекомендую к прочтению

https://overreacted.io/impossible-components/

#development #javascript #react #reactServerComponents #danAbramov

Spectacle

Библиотека для создания презентаций на React. Выглядит неплохо, надо будет попробовать как нибудь. Большой плюс - наличие готовых лейаутов для слайдов (список, колонки, картинка справа, картинка сверху и другие базовые лэйауты).

https://nearform.com/open-source/spectacle/

#development #javascript #react #library #presentations

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.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. Оттуда следует доставать куки, урл и все другое, что зависит от окружения. Также в контексте присутствует флаг 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

Дайджест за 2025-04-28 - 2025-05-02

Impossible Components
Статья от Дэна Абрамова про новые возможности, которые открываются при использовании Server Components. А именно - возможность писать единый код, часть которого исполняется на сервере, а часть на клиенте. Бесшовная интеграция значительно повышает DX и выразительность решений.

Дэн доходчиво показывает основные возможности и объясняет концепции серверных компонентов, раскрывая эти идеи последовательно и с хорошими примерами кода.

Spectacle
Библиотека для создания презентаций на React. Выглядит неплохо, надо будет попробовать как нибудь. Большой плюс - наличие готовых лейаутов для слайдов (список, колонки, картинка справа, картинка сверху и другие базовые лэйауты).


Advanced React in the Wild: Часть №1
Большой пост про исследование перформанса больших веб приложений. В статье рассмотрены варианты улучшения перформанса для разных приложений - кому-то важно SEO, кому-то скорость переключения роутов. Все кейсы - кейсы реальных компаний с замерами.

Обзор всех кейсов не влезет в 1 пост в телеге, поэтому будет целых 2 поста

Advanced React in the Wild: Часть №2
Продолжаем читать большое исследование перформанса веб-проектов. Следующая компания - DoorDash. Приложение рендерится только на клиенте и оно очень большое - долго грузится, огромный JS-бандл, плохие SEO-метрики. При загрузке сайта пользователи долго наблюдают белый экран.


Advanced React in the Wild: Часть №3
Заключительная часть. Какие итоги можно вынести из этих кейсов?


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

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

proposal Composites

TC39 - комитет стандартизации ES - дропнул пропозал Tuple & Records в пользу Composites

Composites - это сущность, которая
- Оборачивает объект и дает доступ к его свойствам
- Неизменяема (нельзя добавлять, удалять, менять свойства)
- 2 композита, имеющие одинаковые свойства и значения - идентичны

Проще, конечно, показать примером

const pos1 = Composite({ x: 1, y: 4 });
const pos2 = Composite({ x: 1, y: 4 });
Composite.equal(pos1, pos2); // true

const positions = new Set(); // the standard ES Set
positions.add(pos1);
positions.has(pos2); // true

const c = Composite({ x: 1, y: 2 });
Object.keys(c); // ["x", "y"]
c.x; // 1
c.y; // 2

В общем, чем-то близко к Records&Tuples, поэтому и заменили, хотя синтаксис стал многословнее. С ходу так и не придумаю, где бы я такое хотел использовать.

https://github.com/tc39/proposal-composites

#development #javascript #tc39 #proposal

Scale Your Project with Layered React Structure

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

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

Что же предлагает автор в своем гайде:

Компоненты деляться на умные и глупые. Глупые - содержат только верстку и другие глупые компоненты. Умные - содержат бизнес-логику и не содержат никакой верстки. Это позволяет отделить бизнес-логику от верстки, а также закинуть все глупые компоненты в сторибук. Умные компоненты тестируются с помощью vitest и testing-library

Функции делятся на утилки и сервисы. Принцип делениz меня, прямо скажем, удивил. Если функция возвращает промис - это сервис. Если функция синхронная - это утилка.

Если есть какая-то сущность в коде - ей нужна отдельная папка. Автор, в дополнении к уже указанным мной сущностями, выделил еще хуки, асеты, типы. Но суть тут в принципе - если вы выделяете какую-то сущность, для нее нужна папка. Например, вы делаете проект где много валидаций - выделите функции-валидации в отдельную папку Validators.

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

https://playfulprogramming.com/posts/layered-react-structure

#development #javascript #react #fileStructure

Custom CSS Functions in the Browser

В хром 136+ за экспериментальным фиче-флагом доступна новая крутая фича - определение собственных функций в CSS. Это тот кейс, когда лучше 1 раз увидеть код, чем 10 раз про него прочесть

Функция возвращает dark, если юзер предпочитает темную тему, и light, если это не так

@function --media-scheme() {
  result: light;
  @media (prefers-color-scheme: dark) { result: dark; }
}

:root {
  --color-scheme: --media-scheme();
}

Добавляет прозрачность цвету

@function --transparent(--color, --alpha: 0.8) {
  result: oklch(from var(--color) l c h / var(--alpha);
}

dialog {
  background: --transparent(black); /* black at default 0.8 opacity */
}

Во первых: выглядит круто! И одновременно немного пугающе - нам хватает дебагинга JS, а css воспринимается как код, который просто работает и в него редко надо залезать и там сложно накосячить - в будущем это может быть не так.
Во вторых: возможно снова увидим вакансии на css-программиста и css-архитектора (это, конечно же, шутка. Но, как известно, в каждой шутке есть доля правды)

https://www.oddbird.net/2025/04/11/custom-functions/

#development #javascript #react #fileStructure

Дайджест за 2025-05-05 - 2025-05-07

proposal Composites
TC39 - комитет стандартизации ES - дропнул пропозал Tuple & Records в пользу Composites


Scale Your Project with Layered React Structure
Еще одна рекомендация по организации файлов и сущностей в React-проектах. В целом, конечно, ничего нового - есть сущности, у каждой сущности своя папка. Сущность-интегратор (в данном случае View) может содержать свою под-структуру с папками-сущностями более низкого порядка. Все то что мы и так делали без FSD и других рекомендаций.

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

Custom CSS Functions in the Browser
В хром 136+ за экспериментальным фиче-флагом доступна новая крутая фича - определение собственных функций в CSS. Это тот кейс, когда лучше 1 раз увидеть код, чем 10 раз про него прочесть



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

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

Giving V8 a Heads-Up: Faster JavaScript Startup with Explicit Compile Hints

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

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

Ключевой вопрос в том, как выбрать те самые функции, которые необходимо компилировать сразу. Команда провела исследование, что при корректном выборе функции для компиляции на старте, то 17 из 20 популярных веб сайтов ускорятся на 630мс - звучит достойно.

Поэтому команда V8 разрабатывает возможность управлять этим поведением. На данный момент сделали возможность указать весь скрипт как критичный к компиляции. Делается это с помощью комментария

//# allFunctionsCalledOnLoad
function testfunc2() {  
   console.log('testfunc2 called!');
}

testfunc2();

Ожидаем развития этого функционала и разбора реальных кейсов в статьях и докладах.

https://v8.dev/blog/explicit-compile-hints

#development #javascript #v8 #performance

Обзор на обучение в стратоплане

Продолжаем обзоры на обучение менеджменту в стратоплане. Модуль получился слишком расфокусированным, без единой линии повествования: было про типы команд и структур, было про целеполагание (OKR & KPI), про модели команд и роль лидера, про конфликты и поиск win-win решения.

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

В данном посте расскажу про то, как разные концепции по-разному смотрят принципы объединения людей в команды. Рассматриваемые концепции: PMBoK, Spotify Model и Team Topologies

Начнем с PMBoK. PMBoK - это "библия" проектного менеджмента. Огромный труд про то, как вести проекты. Периодически он обновляется и выпускается новая редакция.

Основные типы орг структур по PMBoK

Проектно-ориентированная структура:
- Команды собираются вокруг проектов
- Менеджер проекта имеет полную власть в рамках своего проекта
- По завершении проекта команды распускаются или переходят в другой проект

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

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

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

Как мы видим, PMBoK выделяет типы орг структур на основе роли проджект менеджера и управления ресурсами для достижения проектов.

Основная проблема при выборе орг структуры: у нас есть центры компетенций (отвечают за скилы) и центры по проектам (делают бизнес вэлью)

Что говорит об организации команд Spotify Model
В Spotify Model выделяются следующие типы структур:
- Squad (отряд) - небольшие (6-12 человек) команды, которые доставляют какую-то ценность.
- Tribe (племя) - объединение отрядов в нечто большее, объединенное общей целью
- Chapter (собор или церковь) - сбор людей в рамках профессии или компетенции для обмена опытом
- Guild (гильдия) - объединение людей по интересам. Например, гильдия перформанса

Spotify Model в первую очередь фокусируется на автономности команд и обмене знаний. Но, как и у матричной структуры в PMBoK, можно выделить 2 независимых направления: squad&tribe - проектные, а chapter&guild - функциональные

Team Topologies
Здесь буду краток т.к. недавно уже был обзор на книгу ( ищется по тегам #teamTopology #конспект). Team Topologies близок по духу к Spotify Model и акцентируется на командах по доставке ценности, но выделяет и другие типы команд, перенося некоторые функциональные вещи в полноценные команды (команда по развитию автоматизированного тестирования), но также оставляя простор для сообществ по компетенциям.

Итог
Нужно уметь балансировать между двумя крайностями в структуре управления и коммуникаций: вокруг бизнес ценности и вокруг компетенций. Нежелательно впадать только в 1 крайность, нужно уметь держать баланс

---

17 мая в 11:00 по МСК будет проходить бесплатный воркшоп "Сложные переговоры" от Стратоплана. Кажется, там ещё дадут скидку на полноценное обучение. В начале поста я жаловался на расфокусированное обучение, но практические занятия по переговорам и решению конфликтов от Стратоплана строго рекомендую - материал дают хорошо + дают инструкцию, как применять на практике.



#note #stratoplan #managment

Обзор на доклады Codefest 15

Скоро (31 мая - 1 июня) пройдет Codefest - разнонаправленная IT-конференция в Новосибирске. Если приедете на конференцию - можем там увидиться - буду присутствовать там оба дня. Обещаю интересные доклады и уютную атмосферу.

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

Канал про веб, поэтому в первую очередь глянем доклады по вебу.

Про­грес­сив­ный HTML
Очень много в веб-разработке уделяется внимание перформансу. Но очень часто оптимизируется код, но не используются имеющиеся инструменты для прогрессивной доставки контента, которые почти за бесплатно могут значительно улучшить перформанс метрики. В докладе как раз разберут такие инструменты.


AI-ассистенты: как начать использовать сегодня, а не с понедельника (и не бросить после релиза)
AI это хайп. Но если раньше доклады были в стиле "залетайте в этот хайп-трейн, тут класно", то теперь появляются доклады в стиле "как использовать правильно и не попасть в ловушку". Этот доклад про правильное использование и ловушки.

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


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


Как реализовать обработку видео в браузере с применением AI
Простые модельки можно загрузить в браузер и использовать их в приложениях. Более того, есть вероятность что браузеры встроят эти модельки (firefox уже сделал это в экспериментальном режиме). В докладе команда Контур.Толк рассказывает, как они используют модельку для обработки видео-потока прямо в браузере.

Используем различные архитектуры внутри FSD
Из названия и тезисов непонятно, про что будет доклад, но будет что-то про архитектуру (в каком-то её понимании) и FSD. Есть шансы что будет хорошо, есть шансы что будет что-то странное. В любом случае, интересно посмотреть.

Конкурентоспособность: начало
Много внимания уделяем перформансу, но, как правило, не можем сформулировать, какие показатели скажут, что все хорошо, а какие - что все плохо. Один из интересных подходов - сравнивать свой продукт с конкурентами. Если он быстрее - значит перформанс хороший. Если нет - значит плохой. Доклад про то, как Лавка сделала такой мониторинг

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

Есть еще несколько докладов по вебу, но хочется еще показать 2 доклада с QA-трека
Почему разработчики не доверяют AI свои тесты?
Как нейросети обещали ускорить тестирование, а сделали только хуже
Оба доклада про анти-паттерны и бест-практисы при написании автотестов. Т.к. автотесты - это, имхо, неотъемлемая часть работы разработчика, а AI - новый базовый инструмент, то оба доклада могут забустить вашу продуктивность.

https://15.codefest.ru/program

#note #codefest

What Does "use client" Do?

Пост в блоге Дэна Абрамова про серверные компоненты. Точнее пост про концепцию use client и use server, но по факту это про концепцию серверных компонентов.

В посте Дэн рассказывает, какая идея вложена в use client и use server. Когда мы делаем приложение, которое имеет и бэк и фронт, то для взаимодействия между фронтом и беком необходимо использовать особые способы коммуникации, вместо простого вызова функции. Чтобы вызвать бэк с фронта - надо делать сетевой запрос, а чтобы бэку что-то сообщить для фронта - надо как-то передавать данные для рендера.

Намного круче было бы использовать функции напрямую. Именно это и позволяют делать директивы use client и use server. Они как бы обозначают для сборщика, что экспорты этого файла надо адаптировать для вызова в "другом" мире.

Статья интересная, с хорошими примерами кода и хорошими объяснениями.


https://overreacted.io/what-does-use-client-do/

#development #javascript #react #reactServerComponents #danAbramov

You can serialize a promise in React

Еще одна статья, связанная с серверными компонентами. Но на этот раз идеи из нее можно использовать и вне React. Легко передать данные между беком и фронтом, если они легко конвертируются в JSON. Но как передать Promise? Ведь он не сериализуется

const promise = new Promise((resolve) => {
  setTimeout(() => resolve("Hello!"), 1_000);
});

const json = JSON.stringify(promise); // => '{}'

Чтобы сериализовать Promise нужно придумать какой-то свой протокол передачи его состояния и значения.

Один из способов - использовать Stream. При создании промиса отправляем в поток сообщение promise:create, при резолве промиса отправляем в поток текстовое сообщение, содержащее результат промиса

function serializePromise(promise) {
  const stream = new ReadableStream({
    async start(controller) {
      controller.enqueue("promise:create");

      const value = await promise;
      controller.enqueue(`promise:resolve:${value}`);
      controller.close();
    },
  });

  return stream;
}

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

function deserializePromise(stream) {
  const reader = stream.getReader();

  let promise;
  let resolver;
  let unlock;

  let didUnlock = false;
  const lockUntilReady = new Promise((resolve) => {
    unlock = (arg) => {
      resolve({ promise: arg });
      didUnlock = true;
    };
  });

  async function readStream() {
    const { done, value } = await reader.read();

    if (done) {
      if (!didUnlock) {
        unlock();
      }
      return;
    }

    if (value === "promise:create") {
      promise = new Promise((resolve) => {
        resolver = resolve;
      });
      unlock(promise);
    } else if (value.startsWith("promise:resolve:")) {
      const result = value.split(":")[2];
      resolver(result);
    }

    readStream();
  }

  readStream();

  return lockUntilReady;
}

Примерно так и работает сериализация промисов в серверных компонентах React. Сервер отсылает особые события и умеет сериализовывать много чего в строки, а клиент считывает поток и десериализует это в Promise и резолвит его десериализованным ответом.

Хорошая статья с интерактивными примерами. Рекомендую посмотреть т.к. сама задача передачи стейта промиса достаточно интересная.


https://twofoldframework.com/blog/you-can-serialize-a-promise-in-react

#development #javascript #react #reactServerComponents #Promise