Дайджест за 2024-06-10 - 2024-06-14

Speeding up the JavaScript ecosystem - Server Side JSX
Новая статья про ускорение JS-экосистемы. На этот раз ускоряется не какая-то конкретная библиотека, а рендер JSX на сервере. Ускорение делается за счет прекомпиляции статичного и почти-статичного JSX в html-строку. За счет этого достигается ускорение в 7-20 раз и уменьшение работы сборщика мусора в 2 раза.

Node.js Performance Hooks: Mastering the Mental Model
Статья, объясняющая, как работают performance-хуки в nodejs. Если коротко, в nodejs есть API для обработки всех замеров через performance. Собственно это API и называется хуками.

Статья объясняет про особенности работы этих хуков (например, про наличие буферов у каждого обсервера).

Node.js Test Runner: A Beginner's Guide
Неплохая статья, рассказывающая про то, как работать с nodejs тест-ранером. Статья по шагам раскрывает возможности этого тест-ранера, включая не только самые обычные API (как сравнивать, как скипать тест), но также раскрываются возможности для мокирования модулей и таймеров.

⭐️The Gap: An exploration of the pain points that CSS gap solves.
Хорошая статья с хорошей визуализацией про то, почему в css появилось свойство gap и почему оно лучше всех предыдущих решений.

Половина статьи посвящена тому, как делались отступы между элементами до gapи какие проблемы у них были. Например, были сложности с учетом RTL-лэйаутов.

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

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

Why, after 6 years, I’m over GraphQL

Отличная статья про проблемы GraphQL. Особенно интересна она тем, что автор буквально залетел в GraphQL 6 лет назад, когда еще был hype train, но теперь он не может советовать использовать GraphQL в большинстве проектов.

В целом минусы GraphQL касаются безопасности, производительности и удобства. То что легко сделать в обычном REST API, становится сложно делать в GraphQL

Автор начинает с безопасности. А конкретно с авторизации. Если у вас есть данные, которые не может доставать любой пользователей (ну например, поле с имейлом пользователя может доставать только сам этот пользователь), то вам необходимо разбираться с фреймворками авторизации для GraphQL

Так как GraphQL это язык запросов, то пользователь можно создавать разные странные запросы. Например, можно в 128 байт уместить запрос, ответ на который возвращает мегабайты данных и который может полоржить сервер. С этим приходится бороться ограничивая максимальную вложенность полей в запросе и отдельно рассчитывая "сложность" доставания каждого поля. В то же время в REST достаточно поставить разные стратегии rate limiter для разных енд-поинтов

Другой интересный кейс, что можно послать заведомо неверный запрос

query {
  __typename @a @b @c @d @e ... # imagine 1k+ more of these
}

И чтобы собрать ответ с ошибкой сервер потратит в 2000 раз больше памяти, чем занимает сам запрос

Также автор дважды подмечает N+1 проблему, которую можно решать через паттерн Dataloader. Проблема с GraphQL не только в том, что N+1 актуальна для загрузки данных, но она актуальна и для авторизации.

В целом, конечно, ничего нового в этой статье нет - GraphQL очень удобен для запроса данных, но не очень удобен для безопасного и производительного резолва этих данных. Кроме того, для большинства решений и дебага, backend-разработчику проще работать с REST, чем с GraphQL.

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

https://bessey.dev/blog/2024/05/24/why-im-over-graphql/

#development #graphql #recommended

Test-Driving HTML Templates

В последнее время был очень популярен подход с чистым SPA при котором нам не нужен сервер и весь рендеринг происходит на стороне браузера. Однако сейчас все чаще становится популярным рендеринг на сервере. В блоге Мартина Фаулера опубликована статья, рассказывающая, как применять TDD при рендере HTML-шаблонов на "серверных" языках.

В целом статья разделяется на 3 этапа
1. Проверка корректности HTML. Первоначально было бы неплох отбрасывать невалидную вёрстку. Для этого на целевом языке берется библиотека, умеющая проверять валидность HTML
2. Проверка бизнес-логики. В HTML-шаблонах содержится логика и её нужно проверять. Цель таких тестов - отбросить все лишнее и проверять только то, что важно. В примере из статьи проверяется, что выставлены корректные статусы и задач в ToDoList
3. Тестирование поведения. Для того чтобы протестировать реальное поведение UI, нужно уметь проверять, что приложение делает на условный клик и как оно обрабатывает ответ сервера (например, при отправке формы). Для этого нам нужен браузер, поэтому автор предлагает использовать Playwright для тестирования. В этих тестах предлагается мокировать вообще все сетевые запросы, что немного странно, но возможно применимо в каких-то примерах.

Чем интересна данная статья: она показывает как применять TDD к разработке UI. В чистом виде вам эта статья может не понадобится (т.к. в целом проще разрабатывать через storybook и скриншот-тесты), но идея использовать TDD может быть полезна


https://martinfowler.com/articles/tdd-html-templates.html

#development #martinFowler #TDD #html

Data Fetching Patterns in Single-Page Applications

Статья в блоге Мартина Фаулера про паттерны загрузки данных в SPA-приложениях. Загрузка данных в SPA-приложениях - не самая простая задача, т.к. необходимо учитывать все нюансы асинхронно природы этого действа - например, необходимо обрабатывать ошибки и долгую загрузку. В статье по-шагам реализуются основные паттерны для загрузки данных. Если вы уже "собаку съели" на загрузке данных, то вы вряд ли увидите в этой статье что-то новое. Однако, сама статья весьма неплоха для начинающих разработчиков.

Сначала автор описывать, как работать с состоянием загрузки. У нас есть 3 основных состояния: данные грузятся, данные не удалось загрузить, данные загружены. Первый паттерн - Asynchronous State Handler - необходимо написать генерализированный код, инкапсулирующий в себя управление загрузкой и отдающий в UI только знания о текущем состоянии. Самое ценное в этом паттерне - это разделение кода UI от кода загрузки данных. В рамках статьи автор реализует паттерн, создавая генерализированный хук для загрузки данных по урлу.

Если у нас в рамках компонента есть под-компонент, которому также необходимы данные, то мы можем поймать проблему водопада запросов. Например, есть компонент профиля, внутри него есть компонент друзей. Сначала мы показываем скелетон для загрузки профиля, загружаем данные профиля, узнаем что надо грузить друзей - снова ждем. Здесь нам на помощь приходит Parallel Data Fetching - нужно уметь грузить данные параллельно, чтобы не заставлять ждать пользователя дольше необходимого

Для того чтобы не нагружать UI-код обработкой долгой загрузки или ошибки загрузки, выделяется паттерн Fallback Markup - когда мы выделяем обработку этих состояний в отдельные под-компоненты, а их использование описывается декларативно. В React, например, это легко делать с помощью Suspense.

Если же мы заранее знаем, какие данные пользователю понадобятся, то мы можем загружать их заранее и тем самым реализовывать паттерн Prefetching. Например, используя <link rel="preload">. Но это подходит только для данных, о загрузке которых мы уверены еще на уровне первоначального рендера страницы. Но иногда мы получаем эту уверенность по другому тригеру. Например, наше приложение предоставляет большой список и при клике на какую-то кнопку нужно загрузить и отобразить дополнительную информацию о конкретном элементе списка. Вместо того, чтобы загружать данные только по клику, мы можем их предзагружать если пользователь водит мышкой по компоненту больше скольки-то милисекунд. Это может привести к излишней загрузке в некоторых кейсах, но если мы, например, знаем на основе нашей аналитики, что 90% пользователей, которые держат мышку на элементе дольше 300мс кликают на кнопку загрузки - то можно облегчить жизнь 90% пользователей.

Последний рассмотренный паттерн - Code Splitting. Не весь код приложения нужен пользователю прямо сейчас. Вместо этого можно загружать верстку или логику только тогда, когда она реально понадобилась.

https://martinfowler.com/articles/data-fetch-spa.html#ChoosingTheRightPattern

#development #martinFowler #SPA #javascript

https://habr.com/ru/companies/ispring/articles/822975/

Статья о проведении автоматического рефакторинга с помощью JS CodeShift. Есть проект на Google Closure Library и команда решила перевести код на ECMAScript 6. Поскольку проект большой (900 000 строк кода), было решено сделать это автоматизированно.

Почему решили отказаться от Google Closure Library:
• Длинные пространства имён
• С Google-модулями плохо работают подсказки IDE
• Появление скрытых зависимостей
• Актуальность технологий

Делать рефакторинг в таком большом проекте руками сложно: долго, нудно и, скорее всего, такой рефакторинг приведет к ошибкам в проде. Поэтому логично его автоматизировать.

Сделать такой рефакторинг с помощью регулярных выражений невозможно, но его легко сделать с помощью работы с AST (Abstract Syntax Tree). Для этого был выбран JS CodeShift.

Описать изменение таких файлов с помощью регулярных выражений в общем случае невозможно. Для проверки гипотезы были отрефачены 3 небольших (500 файлов) проекта. Весь рефакторинг занял 1 час, включая ручные правки сложных моментов.

Автор даёт два совета:
• Начинать с небольших и простых модулей или проектов.
• Не следует пытаться автоматизировать всё. Автоматический рефакторинг хорошо покрывает часто встречающиеся паттерны. Остальное легче поправить вручную. Т.е. утрируя, можно следовать правилу 80/20 - 80% кейсов рефакторинга можно покрыть автоматикой, остальные 20% лучше сделать руками, чтобы рефакторинг не превратился в первые 80% работы и вторые 80% работы


Мощь AST в действии, или как переписать код 10 летней давности на ES6-модули и ничего не сломать

#development #javascript #ast #refactoring #jscodeshift

Дайджест за 2024-06-17 - 2024-06-20

⭐️Why, after 6 years, I’m over GraphQL
Отличная статья про проблемы GraphQL. Особенно интересна она тем, что автор буквально залетел в GraphQL 6 лет назад, когда еще был hype train, но теперь он не может советовать использовать GraphQL в большинстве проектов.

В целом минусы GraphQL касаются безопасности, производительности и удобства. То что легко сделать в обычном REST API, становится сложно делать в GraphQL

Test-Driving HTML Templates
В последнее время был очень популярен подход с чистым SPA при котором нам не нужен сервер и весь рендеринг происходит на стороне браузера. Однако сейчас все чаще становится популярным рендеринг на сервере. В блоге Мартина Фаулера опубликована статья, рассказывающая, как применять TDD при рендере HTML-шаблонов на "серверных" языках.

Data Fetching Patterns in Single-Page Applications
Статья в блоге Мартина Фаулера про паттерны загрузки данных в SPA-приложениях. Загрузка данных в SPA-приложениях - не самая простая задача, т.к. необходимо учитывать все нюансы асинхронно природы этого действа - например, необходимо обрабатывать ошибки и долгую загрузку. В статье по-шагам реализуются основные паттерны для загрузки данных. Если вы уже "собаку съели" на загрузке данных, то вы вряд ли увидите в этой статье что-то новое. Однако, сама статья весьма неплоха для начинающих разработчиков.

Сначала автор описывать, как работать с состоянием загрузки. У нас есть 3 основных состояния: данные грузятся, данные не удалось загрузить, данные загружены. Первый паттерн - Asynchronous State Handler - необходимо написать генерализированный код, инкапсулирующий в себя управление загрузкой и отдающий в UI только знания о текущем состоянии. Самое ценное в этом паттерне - это разделение кода UI от кода загрузки данных. В рамках статьи автор реализует паттерн, создавая генерализированный хук для загрузки данных по урлу.

Мощь AST в действии, или как переписать код 10 летней давности на ES6-модули и ничего не сломать
Статья о проведении автоматического рефакторинга с помощью JS CodeShift. Есть проект на Google Closure Library и команда решила перевести код на ECMAScript 6. Поскольку проект большой (900 000 строк кода), было решено сделать это автоматизированно.


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

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

Conditionals on Custom Properties

Оказывается, в CSS скоро может появиться возмождность делать условные стили через if. Данная статья разбирает предлагаемый синтаксис и рассуждает о нюансах применения этого синтаксиса для вложенных условий

Изначально я сильно удивился, что в css добавляют что-то подобное. Но, оказывается какое-то подобие условий уже можно было реализовать через calc и custom-properties calc(var(--test) * var(--if-true) + (1 - var(--test)) * var(--if-false)). Теперь же рабочая группа развития CSS обсуждает введение условий в язык.

Данная статья концентрируется на одном аспекте нового синтаксиса, а именно описывает нюансы применения вложенных условий.

https://geoffgraham.me/conditionals-on-custom-properties/

#development #css #customProperties

Blazing Fast Websites with Speculation Rules

Огромная статья про новую фичу в вебе - speculation rules. В статье подробно описывается, что это за фича, какие у нее сценарии использования, какие есть плюсы и минусы.

Если коротко, speculationRules позволяет подсказать браузеру, какие другие страницы нужно предзагрузить, чтобы пользователь получил контент следующей страницы как можно быстрее

<script type="speculationrules">
  {
    "prerender": [
      {
        "urls": ["/shop", "/contact"]
      }
    ]
  }
</script>

Есть 2 вида спекуляций: prerendering и prefetching (т.е. пререндер и предзагрузка).

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

Prefetching загружает ключевые ресурсы страницы, но не делает пререндер. Т.е когда пользователь кликает на ссылку на страницу, которая предзагружена, в браузере уже все загружено и нужно её только отрисовать.

Какие преимущества у этой фичи:
- Во первых, это нативная фича, для которой даже не нужен JS-код
- Во вторых, в вебе уже есть похожие фичи (link rel=preload например), но ни одна из них не может загружить контент страницы и все связанные с ним ресурсы, а также сделать пререндер страницы.
- Конфигурирование спекуляций очень гибкое, про это я опишу ниже


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

Например, по матчингу урла ресурса

<script type="speculationrules">
  {
    "prerender": [
      {
        "where": {
          "and": [
            { "href_matches": "/*" },
            { "not": { "href_matches": "/logout" } }
          ]
        }
      }
    ]
  }
</script>

<!-- ✅ Prerendered -->
<a href="/shop">Shop</a>

<!-- ✅ Prerendered -->
<a href="/about">About</a>

<!-- ❌ Not prerendered -->
<a href="/logout">Logout</a>

Также можно указать, чтобы пререндер происходил, только если пользоватьель делает hover над элементом (и держит его более 200мс)

<script type="speculationrules">
  {
    "prerender": [
      {
        "where": {
          "href_matches": "/*"
        },
        "eagerness": "moderate"
      }
    ]
  }
</script>

А еще можно управлять пререндером на основе css-селекторов

<script type="speculationrules">
  {
    "prerender": [
      {
        "where": {
          "and": [
            { "href_matches": "/*" },
            {
              "not": {
                "selector_matches": ".no-prerender"
              }
            }
          ]
        }
      }
    ]
  }
</script>

Также спекуляции отображаются в девтулах: появляется отдельная вкладка в application, где можно посмотреть предзагруженные страницы и правила. Также предзагрузка страниц отображается в Network и Performance.

Можно из JS понять, предзагружена страница или нет.

const isPagePrerendered =
  document.prerendering ||
  window.performance?.getEntriesByType?.("navigation").at(0)?.activationStart >
    0;

https://www.debugbear.com/blog/speculation-rules

#development #performance #speculationRules #recommended

How React 19 (Almost) Made the Internet Slower

React 19 замедляет интернет!!!!! Достаточно громкий заголовок у статьи, но она посвящена конкретному кейсу - изменена логика обработки асинхронных компонентов в Suspense.

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

Пример кода

function App() {
  return (
    <>
      <Suspense fallback={"Click Me Load More..."}>
        <ComponentThatFetchesData val={1} />
        <ComponentThatFetchesData val={2} />
        <ComponentThatFetchesData val={3} />
      </Suspense>
    </>
  );
}

const ComponentThatFetchesData = ({ val }) => {
  const result = fetchSomethingSuspense(val);

  return <div>{result}</div>;
};

В React18 все три компонента начнут загружать данные в один момент времени. В React19 сначала первый компонент загрузит свои данные, затем второй, затем третий.

Видимо, команда React решила немножко оптимизировать рендер и React перестал рендерить сиблингов в Suspense, в случае отлавливания промиса. Однако, это изменение очень сильно воздействует на перформанс React-приложений.

Команда React пообещала пофиксить эту проблему, поэтому в целом ничего страшного не произошло - сообщество нашло проблему, обсудило, разработчики обещали пофиксить. Историю со счастливым концом.


https://blog.codeminer42.com/how-react-19-almost-made-the-internet-slower/

#development #javascript #react #react19 #suspense #performance

React Internals Explorer - easily see how React works

React Internals Explorer - новый тул, который визуализирует работу рендера React. В нем одновременно есть окно с кодом, который можно редактировать, превью верстки, и интерактивная диаграмма, показывающая, как React рендерит этот код

В инструменте есть пресеты для изучения разных механик React, а также возможность запускать код в React18 и React19. В том числе там можно посмотреть разницу в рендере Suspense с несколькими асинхронными компонентами, про которую я писал в прошлом посте.

https://jser.pro/ddir/rie

#development #javascript #react #tool #recommended

Дайджест за 2024-06-25 - 2024-06-28

Conditionals on Custom Properties
Оказывается, в CSS скоро может появиться возможность делать условные стили через if. Данная статья разбирает предлагаемый синтаксис и рассуждает о нюансах применения этого синтаксиса для вложенных условий

Изначально я сильно удивился, что в css добавляют что-то подобное. Но, оказывается какое-то подобие условий уже можно было реализовать через calc и custom-properties calc(var(--test) var(--if-true) + (1 - var(--test)) var(--if-false)). Теперь же рабочая группа развития CSS обсуждает введение условий в язык.

⭐️Blazing Fast Websites with Speculation Rules
Огромная статья про новую фичу в вебе - speculation rules. В статье подробно описывается, что это за фича, какие у нее сценарии использования, какие есть плюсы и минусы.

Если коротко, speculationRules позволяет подсказать браузеру, какие другие страницы нужно предзагрузить, чтобы пользователь получил контент следующей страницы как можно быстрее

How React 19 (Almost) Made the Internet Slower
React 19 замедляет интернет!!!!! Достаточно громкий заголовок у статьи, но она посвящена конкретному кейсу - изменена логика обработки асинхронных компонентов в Suspense.

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

⭐️React Internals Explorer - easily see how React works
React Internals Explorer - новый тул, который визуализирует работу рендера React. В нем одновременно есть окно с кодом, который можно редактировать, превью верстки, и интерактивная диаграмма, показывающая, как React рендерит этот код

В инструменте есть пресеты для изучения разных механик React, а также возможность запускать код в React18 и React19. В том числе там можно посмотреть разницу в рендере Suspense с несколькими асинхронными компонентами, про которую я писал в прошлом посте.

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

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

Why Google Sheets ported its calculation worker from JavaScript to WasmGC

Движок гугл таблиц переехал на WasmGC.

Изначально движок был написан на Java в 2006 году. В 2013 году движок переехал в браузер и заработал на JavaScript (через компиляцию Java в JavaScript, как я понял). Это, очевидно, позволило убрать нагрузку с серверов на клиентские устройства. Движок запускается в веб-воркере и общается с главным тредом через MessageChannel.

Однако переезд на JS создал риск расхождения расчетов. Чтобы его нивелировать, команда создала кучу кейсов вида "вход => выход" и проверяла, что обе реализации движка работают одинаково. Во время проверки корректности работы также замерялся перформанс и выяснилось, что код на JS работал в 3 раза медленнее кода на Java.

Поэтому было принято решение скопилировать код в WasmGC - расширение Wasm для языков со сборщиком мусора (которым и является Java). Ребятам из гугла пришлось писать свой компилятор из Java в WasmGC. Первоначальная реализация оказалась в 2 раза медленнее реализации на JS. Но для первого прототипа - это хороший результат.

Дальше команда занялась оптимизацией созданного решения:
- Завезли оптимизации, которые есть в других тулчейнах. Например, оптимизация вызова виртуальных методов, которая реализована в V8 и JVM, но ничего похожего нет в WasmGC. Реализовав 2 самые распространенные оптимизации (спекулятивный инлайн кода и девиртуализация) вычисления ускорились на 40%
- Были кейсы, когда лучше было взять нативную реализацию. Например, вместо использования библиотеки re2j для регулярок, которая компилировалась в WasmGC, лучше взять нативный RegExp, предоставляемый браузером
- Часть кода была написана для JS. Например, в JS специфичные нюансы работы с массивами и объектами - они хорошо реализованы в JS движках, но as is плохи в других движках. Поэтому потребовалось переписать идиоматичный JS-код на что-то более подходящее для WasmGC.

Итоговая версия реализации на WasmGC оказалась в 2 раза быстрее реализации на JS.




https://web.dev/case-studies/google-sheets-wasmgc

#development #javascript #wasm #google #googleSheets

From Markdown to Video

Вы когда нибудь задавались вопросом, как превратить markdown в видео? Вот и я нет, а оказывается это можно сделать.

В статье очень коротко рассказывается как с помощью Code Hike (так до конца и не понял что это, но кажется это штука, которая позволяет превращать контент в markdown во что-то красивое) и remotion превратить markdown в видео.

Алгоритм примерно следующий:
- Вы пишете маркдаун контент
- Импортируете её в CodeHike, где контент будет преобразован в React компоненты и можно использовать всю мощь React
- Т.к. есть React, то для красивых анимаций можно использовать remotion

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

https://v1.codehike.org/blog/remotion

#development #javascript #react #remotion #codeHike #video #animations #markdown

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

Why Google Sheets ported its calculation worker from JavaScript to WasmGC
Движок гугл таблиц переехал на WasmGC.

Изначально движок был написан на Java в 2006 году. В 2013 году движок переехал в браузер и заработал на JavaScript (через компиляцию Java в JavaScript, как я понял). Это, очевидно, позволило убрать нагрузку с серверов на клиентские устройства. Движок запускается в веб-воркере и общается с главным тредом через MessageChannel.

From Markdown to Video
Вы когда нибудь задавались вопросом, как превратить markdown в видео? Вот и я нет, а оказывается это можно сделать.

В статье очень коротко рассказывается как с помощью Code Hike (так до конца и не понял что это, но кажется это штука, которая позволяет превращать контент в markdown во что-то красивое) и remotion превратить markdown в видео.

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

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

The 4 keys to creating team accountability

Небольшая менеджерская статья про то, как передавать ответственность в команды (возможно неправильно перевожу, в оригинале "team accountability"). Статья содержит 4 ключевые практики для менеджера, которая помогут сделать команды accountability.

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

Явные ожидания > быстрые указания

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

Любознательность > Страх (в оригинале Curiosity > Fear)

Фразы "Мы все рассчитываем на вас" и "Каждая ваша ошибка может стоит дорого для компании" заставляет участников команды лишь нервничать и бояться ошибиться. Исследования показывают, что чем менее безопасно чувствуют себя люди, тем менее они производительны.

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

Контекст > дедлайн

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

Самодостаточность > Зависимость

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

https://newsletter.canopy.is/p/the-4-keys-to-creating-team-accountability

#managment

Component, colocation, composition: A note on the state of React

Еще 1 разбор драмы в React вокруг изменения алгоритма рендера сиблингов в Suspense. Если коротко, то в бетке 19го React, команда React сделала так, что если в Suspense несколько компонентов кидают промисы, то они будут исполнены последовательно, а не параллельно. После фидбека от комьюнити все вернули назад.

В данном посте поднимается вопрос, как далеко мы отошли от бога команда React готова отойти от сообщества и экосистемы.

С одной стороны, компоненты должны быть самодостаточными - скрывать за собой UI, ui-логику, бизнес-логику, сетевые запросы, стейт. С другой стороны - React противится такому подходу: стейт и сайд-эффекты должны быть где-то в другом месте, но не в React. Тем не менее сообщество сделало много крутых решений, которые с помощью API React позволяют сделать что-то похожее на самодостаточные компоненты. Но чем более компоненты самодостаточные, тем менее они композируемы.

Теперь же команда React форсит использование React Server Components и, вполне вероятно, готова пойти против всего сообщества в пользу новых "правильных" паттернов.

https://bobaekang.com/blog/component-colocation-composition/

#development #javascript #react

New JavaScript Set methods

На MDN появилась статья про новые методы Set. Ссылка про новые методы уже была в канале, но текущая ведет на MDN и там хорошая визуализация работы этих методов.

Если коротко, то удобные методы у Set давно были у Safari и относительно недавно заехали в chrome и firefox. Скоро можно будет начинать использовать в продакшне без полифилов.

Что это за методы:
intersection - позволяет найти пересечение множеств (set'ов)

const setA = new Set([1,2,3])
const setB = new Set([2,4])
setA.intersection(setB) // Set(1) {2}

union - позволяет объединить два множества

const setA = new Set([1,2,3])
const setB = new Set([2,4])
setA.union(setB) // Set(4) {1, 2, 3, 4}

difference - позволяет достать множество, которое получится если из множества А убрать все элементы множества Б

const setA = new Set([1,2,3])
const setB = new Set([2,4])
setA.difference(setB) // Set(2) {1, 3}
setB.difference(setA) // Set(1) {4}

symmetricDifference - позволяет достать множество, которое содержит элементы которые входят только в одно из множеств

const setA = new Set([1,2,3])
const setB = new Set([2,4])
setA.symmetricDifference(setB) // Set(3) {1, 3, 4}

isSubsetOf - возвращает true, если множество А является под-множеством Б

const setA = new Set([1,2,3])
const setB = new Set([2])
setA.isSubsetOf(setB) // false
setB.isSubsetOf(setA) // true

isSupersetOf - возвращает true, если множество А является над-множеством Б

const setA = new Set([1,2,3])
const setB = new Set([2])
setA.isSupersetOf(setB) // true
setB.isSupersetOf(setA) // false

isDisjointFrom - возвращает true, если у множеств нет пересечений

const setA = new Set([1,2,3])
const setB = new Set([2])
const setC = new Set([4])
setA.isDisjointFrom(setB) // false
setA.isDisjointFrom(setC) // true

https://developer.mozilla.org/en-US/blog/javascript-set-methods/

#development #javascript #set

Why do we underestimate how long it will take to complete a task?

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

Ошибка планирования - когнитивное искажение, предложенное Канеманом и Тверски, которое говорит, что когда люди пытаются предсказать будущее, они часто опираются на интуицию и эти предсказания очень не точны

Почему мы ошибаемся в планировании, например, задач? Есть несколько разных когнитивных искажений, которые в сумме дают Ошибку Планирования

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

Например, есть исследование, в котором студентов спросили, сколько своих сокурсников они смогут обогнать по итоговым результатам обучения. Средний студент верил, что сможет обойти 84% своих сокурсников. Что, конечно же, не бьется с реальностью - не может каждый второй быть в топ 16% по оценкам.

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

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

Другое когнитивное искажение, влияющее на ошибку планирования - это эффект якоря или эффект привязки (Anchoring effect). Это особенность восприятия, которая заставляет нас ориентироваться на первую высказанную мысль. Самый простой пример из мира разработки, это когда приходит менеджер и говорит "эй ребята, сможете взять в работу эту маленькую задачку". Задачка, конечно же, может быть не маленькой, но т.к. мы о ней впервые услышали как о маленькой, то наш мозг будет цепляться за эту мысль. Это и есть эффект якоря. С ошибкой планирования он связан следующим образом: на ранних этапах работы над задачей или проектом у нас есть какой-то контекст - бюджет, дедлайны, цели. И даже если в середине задачи мы начнем получать сигналы о том, что первоначальный контекст не совсем верен, мы будем мысленно цепляться за начальную установку.

Получается, что Anchoring Effect заставляет нас следовать плану, который был создан под эффектом Optimism Bias

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

Как избежать или уменьшить эффект от ошибки планирования.

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

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

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

Оказалось, что у второй группы результаты были стат. значимо лучше

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


https://thedecisionlab.com/biases/planning-fallacy

#managment #planning #planningFallacy #estimation #recommended

Дайджест за 2024-07-08 - 2024-07-12

The 4 keys to creating team accountability
Небольшая менеджерская статья про то, как передавать ответственность в команды (возможно неправильно перевожу, в оригинале "team accountability"). Статья содержит 4 ключевые практики для менеджера, которая помогут сделать команды accountability.

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

Component, colocation, composition: A note on the state of React
Еще 1 разбор драмы в React вокруг изменения алгоритма рендера сиблингов в Suspense. Если коротко, то в бетке 19го React, команда React сделала так, что если в Suspense несколько компонентов делают кидают промисы, то они будут исполнены последовательно, а не параллельно. После фидбека от комьюнити все вернули назад.

В данном посте поднимается вопрос, как далеко мы отошли от бога команда React готова отойти от сообщества и экосистемы.

New JavaScript Set methods
На MDN появилась статья про новые методы Set. Ссылка про новые методы уже была в канале, но текущая ведет на MDN и там хорошая визуализация работы этих методов.

Если коротко, то удобные методы у Set давно были у Safari и относительно недавно заехали в chrome и firefox. Скоро можно будет начинать использовать в продакшне без полифилов.

⭐️Why do we underestimate how long it will take to complete a task?
Отличная статья про Ошибку Планирования (Planning Fallacy). В статье разбирается что это, какие когнитивные искажения приводят к этой ошибке и как избежать или уменьшить эффект этой ошибки.

Ошибка планирования - когнитивное искажение, предложенное Канеманом и Тверски, которое говорит, что когда люди пытаются предсказать будущее, они часто опираются на интуицию и эти предсказания очень не точны

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

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

Кратко про основные техники кеширования в браузере

Вводная и простая статья про кеширование. Статья рассказывает о нескольких заголовках - Cache-Control , E-tag, If-Modified-Since и, внезапно, про Local Storage.

Все объяснения сопровождены примерами реализации на Node.js



https://habr.com/ru/companies/otus/articles/825060/

#development #caching