Дайджест за 2025-08-11 - 2025-08-15

How we made JSON.stringify more than twice as fast
Статья в блоге V8 про ускорение работы JSON.stringify в 2 раза в определенных кейсах. JSON.stringify наверное одна из самых часто-используемых функций, а поэтому её производительность очень важна. Удивительно, что спустя столько лет все еще находится возможность оптимизировать эту функцию

Что сделали: если вы вызываете JSON.stringify и передаете туда простой объект или массив, не используете 2 и 3 аргументы функции, не используете .toJSON и еще несколько ограничений, то V8 вместо обычного рекурсивного алгоритма будет использовать итеративный, который переведет объект в json в 2 раза быстрее.

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

Эта заметка про модуль "Развитие и оценка ключевых людей".

No, AI is not Making Engineers 10x as Productive
Эссе про то, что AI-инструменты, вопреки заявлениям, не ускоряют работу в 10 раз. Автор, как и многие из нас, постоянно сталкивается в медиа пространстве и кулуарных разговорах с высказываемой кем-то мыслью, что ИИ ускоряет работу разработчика в 10 раз, а в будущем профессия разработчика вообще может исчезнуть.

Одних это восхищает, других напрягает. Автора, вот, напрягает. Он столкнулся с ситуацией, когда все вокруг говорят о 10-кратном увеличении производительности с ИИ, а он к этому не прикоснулся.

Express Slow Down
Базовое решение для защиты от повышенной нагрузки - встроить rate limiter - решение, которое будет отбивать HTTP-ошибкой на все запросы, которые идут сверх лимита.

express-slow-down - библиотека, которая предоставляет express middleware, который вместо отбивания HTTP-ошибкой как бы приостанавливает обработку запроса, давая ту же гарантию (приложение не будет обрабатывать больше Х запросов в единицу времени), но не отбивая ошибкой, а подвешивая обработку запроса.

Почему стоит использовать Tagged Unions при разработке на TypeScript
Хорошая статья про паттерн Tagged Union (который может называться по-разному, я до этого встречал его под названием discriminated union). В чем суть - если у вас в какую-то ветку кода попадает объект с типом A | B, то вам придется каким-то образом уточнять тип, чтобы быть уверенным в корректной работе кода (или убедить в этом typescript)

Очень удобно, когда такое поле уже есть. Например API отдает объекты A | B | C, но мы можем определить каждый объект по полю type. Но если такого поля нет - его можно заложить самим. В этом и есть суть паттерна.

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

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

Introducing the first alpha of Turso: The next evolution of SQLite
Не только JS-тулинг переписывают на Rust. Очередь дошла и до sqlite. Turso - новая СУБД на RUST, которая совместима с sqlite, но также имеет дополнительные фичи.



zshy - The no-bundler build tool for TypeScript libraries
Zshy - билд тул для typescript библиотек. Это инструментарий, который был создал для Zod, но теперь его адаптировали для широкого использования и выложили в опенсорс.



jsonrepair
jsonrepair - библиотека для починки сломанного json. Библиотека умеет чинить типичные проблемы - копирование JS-объектов в JSON, пропущенные запятые или незакрытые скобки, учитываются особенности вставки JSON из разных источников.


Поговорим про клавиатурки
Я пишу этот пост с раздельной эргономичной ортолинейной низкопрофильной механической сплит клавиатуры. Если вы нормальный человек, у вас должен появиться вопрос "а что это значит?". Если вы тоже в этой теме, то возможно вам интересно, как я дошел до такой жизни.


How to test React Server Component
Удивительно, столько движа вокруг серверных компонентов React. Но при этом нет никаких официальных туториалов как тестировать эти компоненты (по крайней мере я не видел таких туториалов и в статье говорят что их нет)

Panda CSS - Build modern websites using build time and type-safe CSS-in-JS

Библиотека для CSS-in-JS, которая обещает хороший DX с типами, а весь css генерируется при сборке, т.е. рантайма нет. Есть интеграция со всеми популярными фреймворками и инструментами, в том числе React Server Components

https://panda-css.com/

#development #javascript #cssInJs #library

Профессиональная обработка ошибок в TypeScript

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

Часто никто не задумывается о том, как вообще работать с ошибками. Дай бог если где-то в коде вообще будет написан catch и что-то обработано. "Unknown Error", "что-то пошло не так", "oops", "попробуйте еще раз" прочно вошли в нашу жизнь и никто уже не удивляется, когда видит в UI нечто непонятное.

В статье рассказывается, что хорошо бы поделить ошибки на "ожидаемые" - это те, про которые нам известно и примерно понятно, как их следует обрабатывать, и "неожиданные" - это те, про которые мы не в курсе, или в курсе их существования, но не ожидаем таких ошибок (пример кейса "знаем, но не ожидаем" - не ожидаем, что будет ошибка резолва DNS из нашей nodejs до нашего же API на java)

Ошибки, по-хорошему, нужно обрабатывать. Но механизм throw => try-catch не очень удобен для этого - флоу обработки ошибок не очевиден. Вместо этого автор предлагает использовать Result-монаду из библиотеки true-myth (лично я своих проектах использую библиотеку ts-results).

Если мы начинаем использовать Result-монаду как результат функции, то сама монада заставляет нас явно обрабатывать ошибки. Как следствие:
- Есть явный, очевидный флоу обработки ошибок от любой функции
- TS может требовать корректной обработки ошибок (если не лениться типизировать то, что лежит в result-монаде)

Как это выглядит

Без result-монады

async function createUser(newUser: NewUser): User {
  return { ... };
}

try {
  const user = await registerUser();
  return { status: 200, user };
} catch (e) {
  if (e instanceof UserNameTaken) {
    return { status: 400, message: 'User name taken' };
  }
  throw e;
}

с Result-монадой

type UserResult =
  | { result: 'success', user: User }
  | { result: 'error', error: Error };

async function createUser(newUser: NewUser): UserResult {
  return { ... };
}

// Вызывающий код:
const userResult = createUser(newUser);

if (userResult.result === 'error') {
  if (userResult.error.code === 'User name taken') {
   return { status: 400, message: 'User name taken' };
  }

  // иначе возвращаем ошибку выше по флоу
  return userResult;
  
}

return { status: 200, user };

В примере кода могут быть не очевидно, зачем вообще использовать result - кода стало больше, а не меньше. Но:
- Теперь TS требует явно проверять результат и ошибки. Забыть написать обработку ошибок невозможно (ну или нужно явно подавить ошибки TS)
- Все ошибки можно типизировать. Ну или хотя бы ожидаемые ошибки.
- Result-монады хорошо композируются. Если result-монада - стандарт для возврата результата функции, то передача результата между слоями (как в примере выше с неизвестной ошибкой) либо требует 0 усилий, либо требует небольшой переупаковки ошибки

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

https://habr.com/ru/companies/piter/articles/935278/

#development #javascript #typescript #errorHandling

Удалить полпроекта: как мы переписывали MobX‑сторы на React Query в большом Next.js‑проекте

Статья про оптимизацию ощущаемого перформанса сайта с помощью перехода с mobx на React Query. Если предыдущее предложение показалось вам странным, то вы правы, заменять mobx на react-query очень странно т.к. это смена с реактивного стейт менеджера на либку для менеджмента запросов

Тем не менее, статья и опыт достаточно интересные. В приложении есть SSR и CSR. Вся логика по загрузке данных вшита в mobx-сторы. Эта логика может отличаться для разных компонентов (глобальные и локальные сторы) и для разных флоу (серверный и клиентский). В какой-то момент разработчики поняли что а) получилось сложно б) сайт перезагружает данные там, где не должен. Поэтому решили мигрировать на react-query

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

Сначала попробовали сменить mobx на react-qeury на главной странице. Собрали часть граблей, значительно ускорили открытие страницы, новый код стал занимать в 2 раза меньше строчек, чем старый. Затем составили план миграции - задокументировали, как делать адаптеры, как переписывать разные куски кода (серверный, клиентский, локальный, глобальный), сделали базовые абстракции для упрощения переписывания. Затем, договорились, что весь новый код надо писать на react-query, а старый переписывать в рамках техдолга.

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

https://habr.com/ru/companies/kts/articles/935086/

#development #javascript #mobx #reactQuery #migration

Team OKRs in Action

Статья в блоге Мартина Фаулера про OKRs - Object Key Results - фреймворк целеполагания для компаний. В статье рассказывается про основные проблемы применения и лучшие практики OKRs.

Самая частая проблема OKRs - это когда команды не вовлечены в постановку OKR в соответствии с целями компании.

Как должно быть:
- Есть Vision - то, к чему компания идет на горизонте нескольких лет
- Есть Стратегия компании - это, куда компания идет в перспективе года
- Есть OKRs команд - это цели и ключевые измеримые результаты команд
- Есть задачи команд

В идеале, стратегия должна быть связана с Vision, OKRs команд должны быть связаны со стратегией, а задачи команд с OKRs команд.

На практике же есть 2 популярных анти-паттерна:
1. Команды составляют OKR без учеты стратегии. Соответственно, работа команды не бьет в стратегию компании. А если команд много - их усилия могут быть направлены в совершенно разные вектора
2. Командам спускают OKRs сверху. Команды не вовлечены и поэтому не предлагают эффективные способы реализации стратегии. OKR становится формальностью.

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

Автор предлагает следующий воркфлоу для OKRs:
- В начале годового цикла создается глобальная стратегия
- Каждый квартал команда планирует свои OKRs
- Каждую неделю команда трекает прогресс по OKRs и планирует следующие задачи
- В конце квартала команда проводит ретроспективу



https://martinfowler.com/articles/team-okr.html

#managment #OKR #martinFowler

5 Useful CSS functions using the new @function rule

В 139 хром завезли синтаксис для объявления функций в css. Статья показывает 5 примеров использования этого функционала.

Изменение знака числа

/* Returns the negative of a value */
@function --negate(--value) {
  result: calc(-1 * var(--value));
}

html {
  --gap: 1em;
  padding: --negate(var(--gap));
}

opacity

/* Return a semi-transparent value */
@function --opacity(--color, --opacity) {
  result: rgb(from var(--color) r g b / var(--opacity));
}

/* usage */
div {
  background-color: --opacity(red, 80%);
}

/* with custom properties (assuming theme variables) */
.card {
  border-color: --opacity(var(--color-secondary), var(--mostly-opaque));
}

:root {
  --brandBlue: skyblue;
  --brandBlue-a20: --opacity(var(--brandBlue), 20%)
  /* nice :) */
}

Масштабируемый размер шрифта

Тут лучше глянуть демку в статье. Выглядит весьма недурно.

@function --fluid-type(--font-min, --font-max, --type: 'header') {
  --scalar: if(style(--type: 'header'): 4vw; 
               style(--type: 'copy'): 0.5vw);
  result: clamp(var(--font-min), var(--scalar) + var(--font-min), var(--font-max));
}

h1 {
  --header-min: 24px;
  --header-max: 36px;
  font-size: --fluid-type(var(--header-min), var(--header-max));
}

p {
  --copy-min: 16px;
  --copy-max: 24px;
  font-size: --fluid-type(var(--copy-min), var(--copy-max), 'copy');
}

Скругление углов по условию
Также лучше посмотреть демку

/* Conditionally apply a radius until you are (default: 4px, or specify second argument) from the edge of your screen */
@function --conditional-radius(--radius, --edge-dist: 4px) {
  result: clamp(0px, ((100vw - var(--edge-dist)) - 100%) * 1e5, var(--radius));
}

/* usage */
.box {
  /*  1rem border radius, default (4px) distance  */
  border-radius: --conditional-radius(1rem);
}

.box-2 {
  /*  1rem border radius, right at the edge (0px distance)  */
  border-radius: --conditional-radius(1rem, 0px);
}

Сайдбар на больших экранах
Функция делает так, что на больших экранах часть контента уносится в сайдбар, а на малых - контент идет в колонку

/* Take up 1fr of space for the sidebar on screens smaller than 640px, and take up the --sidebar-width for larger screens */
@function --layout-sidebar(--sidebar-width: 20ch) {
  result: 1fr;
  
  @media (width > 640px) {
    result: var(--sidebar-width) auto;
  }
}

.layout {
  display: grid;
  /* uses fallback value of a 20ch sidebar-width */
  grid-template-columns: --layout-sidebar();
}

Бонус: функция выбора значения на основе темы
Функция принимает на вход 2 параметра - первый для светлой темы, а второй для темной. И возвращает тот, который подходит под текущую тему юзера

Сама функция

/* Function returns the first value if the user's color scheme is light and the second if it is dark */
@function --light-dark(--light, --dark) {
  result: if(
    style(--scheme: dark): var(--dark);
    else: var(--light)
  );
}

Захват темы юзера

:root {
  --root-scheme: light;
  --scheme: light;

  @media (prefers-color-scheme: dark) {
    --root-scheme: dark;
    --scheme: dark;
  }
} 

Захват темы c элемента (если на элементе не указана тема - возьмется та, что захвачена на руте)

@scope ([data-scheme]) {
  :scope {
    --scheme-from-attr: attr(data-scheme type());
      --scheme: if(
        style(--scheme-from-attr: system): var(--root-scheme);
        else: var(--scheme-from-attr)
      );
    color-scheme: var(--scheme); /* To make the native light-dark() work */
  }
}

И, наконец, использование

[data-scheme] {
  color: light-dark(#333, #e4e4e4);
  background-color: light-dark(aliceblue, #333);

  border: 4px --light-dark(dashed, dotted) currentcolor;
  font-weight: --light-dark(500, 300);
  font-size: --light-dark(16px, 18px);
}

Пару постов назад в комментариях жаловались на то, что монады сложно читать. Как вам кодинг в css? :)

https://una.im/5-css-functions/

#development #css

Дайджест за 2025-08-18 - 2025-08-22

Panda CSS - Build modern websites using build time and type-safe CSS-in-JS
Библиотека для CSS-in-JS, которая обещает хороший DX с типами, а весь css генерируется при сборке, т.е. рантайма нет. Есть интеграция со всеми популярными фреймворками и инструментами, в том числе React Server Components

Профессиональная обработка ошибок в TypeScript
Небольшой перевод небольшой статьи про обработку ошибок в JS. Статья достаточно простая (даже, имхо, черезчур - тему можно было бы раскрыть и интересней), но в ней рассказывается о важном концепте - обработка ошибок.

Удалить полпроекта: как мы переписывали MobX‑сторы на React Query в большом Next.js‑проекте
Статья про оптимизацию ощущаемого перформанса сайта с помощью перехода с mobx на React Query. Если предыдущее предложение показалось вам странным, то вы правы, заменять mobx на react-query очень странно т.к. это смена с реактивного стейт менеджера на либку для менеджмента запросов


Team OKRs in Action
Статья в блоге Мартина Фаулера про OKRs - Object Key Results - фреймворк целеполагания для компаний. В статье рассказывается про основные проблемы применения и лучшие практики OKRs.

5 Useful CSS functions using the new @function rule
В 139 хром завезли синтаксис для объявления функций в css. Статья показывает 5 примеров использования этого функционала.

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

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

GitHub’s internal playbook for building an AI-powered workforce

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

В статье описывается модель, по которой Github масштабирует применение AI.

Основные столпы, которые необходимы для масштабирования внедрения AI:
1. AI-адвокаты — внутренняя сеть добровольцев‑чемпионов для распространения практик (как через вебинары, так и через совместную работу).
2. Понятные политики и безопасность — правила, чтобы сотрудники уверенно и безопасно использовали AI.
3. Возможность обучаться применению AI и возможность применять его в работе
4. Метрики на основе данных — система метрик по адопшену, вовлечённости и бизнес‑эффекту.
5. Ответственный, управляющий масштабированием
6. Поддержка руководства — стратегическое видение, ресурсы и тд
7. Использование подходящих инструментов — набор проверенных инструментов, подходящих под роли и задачи.
8. Внутренние сообщества (Communities of Practice) — форумы и сообщества для обмена знаниями и опытом.


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

В статье делается большой уклон на вовлечение людей в интеграцию с AI. Не "мы придумали для вас инструменты и практики, используйте", а "индустрия меняется, будьте теми, кто участвует в ее изменении". Люди сами найдут оптимальные способы использования AI в своей работе, если их правильно вовлечь.

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

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

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

Рекомендую внимательно прочитать, если вам интересна тема масштабирования использования ИИ.

https://resources.github.com/enterprise/ai-powered-workforce-playbook/

#development #ai #github

Part 1: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity

Недавно во многих каналах и форумах разошлись результаты исследования влияния использования на производительность разработчиков. Результаты следующие: ожидали ускорение на 20%, а по факту замедлились на 19%. Давайте погрузимся в исследование и поймем его ограничения и выводы

Чем это исследование примечательно (ну кроме неожиданного результата) - оно проводится на реальных эадачах и замеряется время выполнения задач. Другие исследования обычно замеряют скорость написания строчек кода или открытия пул реквестов, или измеряют производительность на синтетических задачах (напишите свой веб сервер который отдает hello world)

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

Всего в исследовании приняли участие 16 разработчиков, и они завершили 246 задач. По итогам исследования исследователи выделили 21 фактор, которые могут объяснять влияние или влиять на производительность разработчиков.

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

Категории активностей
- Активный кодинг: 24 минуты в задачах без AI, 20 минут в задачах с AI
- Чтение и поиск: 15 минут без AI, 14 минут с AI
- Тестирование и дебаг: 8 минут без AI, 10 минут с AI
- Git и окружение: 7 минут без AI, 6 минут с AI
- Ожидание (Idle, overhead): 3 минуты без AI, 7 минут с AI
- Ревью вывода AI: 7 минут с AI
- Промптинг: 5 минут с AI
- Ожидание AI: 4 минуты с AI

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

С чем связано увеличение времени в ожидании и ревью? В исследовании выделяют несколько причин.

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

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

В третьих, часть разработчиков неопытны в использовании AI (мое субъективное мнение). Когда AI выдавал им неидеальный ответ, они, вместо того, чтоб его подредактировать, удаляли весь ответ и меняли промпт

Как итог, разработчики зарепортили следующее:
- В 100% отчетах разработчики исправляли код после AI
- В 56% отчетах - это были большие изменения
- В 75% отчетах разработчики читали каждую строчку, которую сгенерировали ИИ

В следующем посте разберем факторы, влияющие на скорость разработки, которые выделили исследователи.

В комментарии скину интересные графики.

https://arxiv.org/abs/2507.09089

#development #ai #performance #research #openSource

Part 2: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity

Как я говорил в предыдущем посте, исследователи выделили 21 фактор, который виляет или может влиять на производительность разработчиков. Давайте их разберем.

Я не буду рассматривать факторы as is как в исследовании, я их переструктурирую в более широкие факторы

Фактор №1: применение AI в сложном контексте снижает скорость разработки

Основные тейки из исследования следующие:
- Репозитории, в которых работал AI - гигантские.
- Кроме этого, некоторые знания в них - неявные, и существуют только в головах разработчиках.
- Так как это опен-сорс, в репозиториях очень строгие стайл-гайды и правила написания кода и оформления пул реквестов.

Как следствие - разработчики тратили много времени на ревью и исправление кода. Часто AI не мог предложить адекватного (или идеального) решения


Фактор №2: применение AI не помогает тем, кто уже эксперт в текущем контексте
В исследовании принимали участие разработчики, которые годами работают в их репозиториях (5+ лет). Чем лучше разработчики понимали область задачи, тем сильнее было замедление скорости разработки.

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

Фактор №3: применение AI замедляет, пока у вас нет навыков работы с AI
Опытные в AI разработчики не были мотивированы участвовать в исследовании. Исследователи провели обучение по работе cursor (что может говорить о низком уровне навыка работы с AI)

Исследователи искали кореляцию между опытом работы с AI и ускорением (предполагали что AI сначала замедляет, а затем ускоряет), но не нашли такой кореляции. Хотя в их же графике есть всего 1 разработчик, который провел в курсоре более 50 часов и выполнил после этого 24 задачи и получил ускорение (график в комментариях)

Фактор №4: применение AI увеличивает скоуп задач
Это немного ставит под сомнение тезис "применение AI замедляет разработку" т.к. разработчики выполняют основную задачу и что-то еще рядом с ней.

Ситуация, на самом деле, обычная, с которой сталкивался, наверное, каждый, кто пробовал использовать агентский режим. Вы хотите просто сделать фичу, а агент:
- Провел рефакторинг
- Поправил gitlab-ci.yml
- Дописал JSDoc там, где его не хватало
Иногда эти правки полезные, иногда - нет. Но факт - если они полезные, то у вас дилема - или расширить скоуп задачи и принести еще пользы, влив еще немного времени на задачу, или потратить время на удаление лишних правок.

Фактор №5: Применение AI в другом инструментарии замедляет разработку
Тут надо сказать, что я говорю ровно противоположное тому, что написано в исследовании. В исследовании говориться, что такой фактор есть, но они считают, что он, скорее всего, не повлиял, т.к. cursor сопоставимая IDE с IDE участников, а также у 3 разработчиков cursor был одной из основных IDE до исследования.

Из 16 разработчиков, учатсвующих в исследовании, 12 согласились открыть свои данные по репозиториям, в которых они работают:
- 7 python
- 2 haskell
- 2 js
- 1 rust

Я могу предположить, что у большинства разработчиков (python + haskell) основная IDE - не vscode и, соответственно, переход на cursor для них далеко не бесплатный.

Теперь представьте, что вы 50% задач делаете в вашей любимой IDE, в которой вы работаете годами, а другие 50% задач делаете в IDE, в которой другие инструментарий и возможности (скорее всего меньший по сравнению с профильными IDE), другие хоткеи, другое поведение. Логично ожидать, что ваша производительность просядет при работе в новой IDE.

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

https://arxiv.org/abs/2507.09089

#development #ai #performance #research #openSource

Part 3: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity

Завершающий пост про исследование.

Давайте коротко вспомним, что было в предыдущих постах:
- Сильные разработчики в сложных опен-сорс проектах для 50% задач начали использовать AI
- Скорость выполнения задач с использованием AI оказалась на 19% ниже
- Достаточно большое количество времени разработчики либо промптили, либо ждали ответа AI, либо ревьюили AI-код
- При этом сам кодинг с AI идет быстрее
- Текущий AI-инструментарий не может реализовать сложных решений (по крайней мере при заходе в эту степь с двух ног без подготовки и сложных паттернов)
- Текущий AI-инструментарий - медленный
- Использование AI расширяет скоуп задачи
- Чем более экспертен разработчик в какой-то области, тем сильнее замедление в разработки при использовании AI в этой области
- В областях, где разработчики были новичками AI очень сильно им помог
- Разработчики, принимающие участие в исследовании, были не очень опытны в AI, а часть разработчиков не могли воспользоваться AI-тулингом в их "родной" IDE

Не смотря на то, что AI-замедляет, код от AI часто приходилось удалять или изменять, в отчетах, которые заполнялись после завершения задачи, разработчики указывали, что AI их ускорил. То есть, не смотря на то, что по факту задача делалась дольше, разработчики ощутили ускорение своей работы.

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

Когда исследование завершилось и разработчики выполнили все свои задачи, им не стали отключать cursor. После того, как уже не требовалось использовать AI для 50% задач, 69% разработчиков продолжили использовать cursor. Невероятный retention!

Подведем общий итог. Вместо "Исследование говорит о том, что AI замедляет разработку на 19%" я бы сформулировали итог так:
- Если вы супер-опытный разработчик
- Вы разрабатываете в очень сложном репозитории со строгими гайдлайнами (опен-сорс)
- Вы постоянно переключаетесь в другую IDE для использования AI
- И вы не опытны в AI-кодинге
- То при применении AI вы замедлитесь на 19%

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

https://arxiv.org/abs/2507.09089

#development #ai #performance #research #openSource

Дайджест за 2025-08-25 - 2025-08-29

GitHub’s internal playbook for building an AI-powered workforce
Статья от Github про сложности внедрения AI в работу. Основная проблема - не купить инструменты, а внедрить их использование в рабочий процесс.

В статье описывается модель, по которой Github масштабирует применение AI.

Part 1: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
Недавно во многих каналах и форумах разошлись результаты исследования влияния использования на производительность разработчиков. Результаты следующие: ожидали ускорение на 20%, а по факту замедлились на 19%. Давайте погрузимся в исследование и поймем его ограничения и выводы

Чем это исследование примечательно (ну кроме неожиданного результата) - оно проводится на реальных эадачах и замеряется время выполнения задач. Другие исследования обычно замеряют скорость написания строчек кода или открытия пул реквестов, или измеряют производительность на синтетических задачах (напишите свой веб сервер который отдает hello world)

Part 2: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
Как я говорил в предыдущем посте, исследователи выделили 21 фактор, который виляет или может влиять на производительность разработчиков. Давайте их разберем.

Я не буду рассматривать факторы as is как в исследовании, я их переструктурирую в более широкие факторы

Part 3: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
Завершающий пост про исследование.

Давайте коротко вспомним, что было в предыдущих постах:

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

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

Mediabunny - Complete media toolkit

Mediabunny - тулкит для работы с медиа прямо в браузере. Склеивание, перекодирование, комбинирование и тд и тп. В общем, ffmpeg но только в браузере и в виде библиотеки для JS.

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


https://mediabunny.dev/

#development #javascript #media #library

Why do browsers throttle JavaScript timers?


Хорошая статья, рассказывающая про особенности работы setTimeout. Вы знали, что setTimeout(0) вызовется не сразу, а через 4мс? А все потому что, когда-то разработчики слишком активно использовали setTimeout(0) где надо и где не надо, а разработчики браузеров решили защитить пользователей и сделали минимальный лимит в 4мс.

Описал достаточно утрировано, но тем не менее - можете рассчитывать на 4мс вместо 0мс задержки в современных браузерах.

Зачем браузеры делают такое? Они оптимизируют использование батарейки и сети на устройствах пользователей. Иногда браузеры делают это более агрессивно. Например, safari задерживает выполнение колбека на 26 секунд, а для неактивных вкладок хром задерживает выполнение колбека на одну секунду

Что же делать, если вы хотите выполнить колбек после выполнения всех микротасок? Автор задался тем же вопросом т.к. делает JS-имплементацию indexeddb и ему нужно комитить транзакции.

Автор провел простые бенчмарки и сделал следующие выводы:
- scheduler.postTask имеет минимальную задержку (0.00-0.01 мс), но не реализован в safari
- window.postMessage имеет задержку чуть больше (0.01-0.03мс), но поддерживается в safari
- MessageChannel.postMessage имеет задержку еще чуть больше (0.02-0.05мс), но в safari значительно больше (0.52мс)

Когда нибудь и текущие API могут замедлить (когда разработчики станут ими слишком активно злоупотреблять), но пока так.


https://nolanlawson.com/2025/08/31/why-do-browsers-throttle-javascript-timers/

#development #javascript #timers #setTimeout

Fresh 2.0 Graduates to Beta, Adds Vite Support

Fresh - веб-фреймворк в deno - зарелизился в бетке 2.0.

Главные изменения:
- Интеграция с Vite
- HMR в islands-компонентах
- Ускорение инициализации приложения в браузере в 10 раз
- Вернули компонент Head. Убирали, потому что была кривая реализация, ухудшающая перформанс. Теперь хорошая реализация

https://deno.com/blog/fresh-and-vite

#development #javascript #deno #vite

You no longer need JavaScript

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

Какие приколы рассмотрены в статье:
- Вложенные css-селекторы (пример & > .buttons)
- Колор пикер на чистом css
- transitioning + @starting-style
- nesting + :has для выбора темы сайта
- radio-group и radio tabs
- Акордеон
- Валидация инпутов с использованием regexp-шаблона и :has
- Использование lvh, svh, dvh вместо vh
- Получение высоты экранной клавиатуры (актуально для мобильных девайсах) в css (пока только для хрома)

Горячо рекомедую статью и демки к просмотру.

https://lyra.horse/blog/2025/08/you-dont-need-js/

#development #javascript #css

Deriving Client State from Server State

Частый паттерн - использовать useEffect для синхронизации состояния двух стейтов. В рамках статьи обсуждается синхронизация стейта react-query и zustand. Вместо использования useEffect предлагается высчитывать состояние, вместо его синка

Пример проблемы:

const useSelectedUser = () => {
  const { data: users } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  })
  const { selectedUserId, setSelectedUserId } = useUserStore()

  // If the selected user gets deleted from the server,
  // Zustand won't automatically clear selectedUserId
  // You have to manually handle this:
  useEffect(() => {
    if (!users?.some((u) => u.id === selectedUserId)) {
      setSelectedUserId(null) // Manual sync required
    }
  }, [users, selectedUserId])

  return [selectedUserId, selectedUserId]
}

Пример предлагаемого решения

const useSelectedUser = () => {
  const { data: users } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  })
  const { selectedUserId, setSelectedUserId } = useUserStore()

  const selectedId = users?.some((u) => u.id === selectedUserId)
    ? selectedUserId
    : null

  return [selectedId, setSelectedUserId]
}

Соглашусь с автором. Если вы можете не использовать 2 стейта, которые надо синхронизировать - не надо их использовать т.к. синхронизация стейтов это а) кривое решение б) хрупкое решение. У меня до сих пор есть въетнамские флешбеки от синхронизации rxjs-like стейта (какой-то самописный стор на обсерваблах) с redux-like стором.

https://tkdodo.eu/blog/deriving-client-state-from-server-state

#development #javascript #react #reactQuery #zustand

Дайджест за 2025-09-08 - 2025-09-12

Mediabunny - Complete media toolkit
Mediabunny - тулкит для работы с медиа прямо в браузере. Склеивание, перекодирование, комбинирование и тд и тп. В общем, ffmpeg но только в браузере и в виде библиотеки для JS.

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

Why do browsers throttle JavaScript timers?

Хорошая статья, рассказывающая про особенности работы setTimeout. Вы знали, что setTimeout(0) вызовется не сразу, а через 4мс? А все потому что, когда-то разработчики слишком активно использовали setTimeout(0) где надо и где не надо, а разработчики браузеров решили защитить пользователей и сделали минимальный лимит в 4мс.


Fresh 2.0 Graduates to Beta, Adds Vite Support
Fresh - веб-фреймворк в deno - зарелизился в бетке 2.0.


You no longer need JavaScript
Очередная статья про то, что слишком много Javascript грузится на сайтах, а ведь можно делать интерфейсы без Javascript. Отличие этой статьи от многих таких же - очень крутые примеры и демки того, что позволяют сделать современные веб-стандарты без использования JS.


Deriving Client State from Server State
Частый паттерн - использовать useEffect для синхронизации состояния двух стейтов. В рамках статьи обсуждается синхронизация стейта react-query и zustand. Вместо использования useEffect предлагается высчитывать состояние, вместо его синка


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

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

Introducing Next-Generation Flamegraph Visualization for Node.js

Название статьи говорит само за себя - представлен инструментарий для профилирования nodejs приложений. Фишки, в общем-то, две: а) крутая визуализация б) профилирование замедляет fastify всего на 5%

Рекомендую открыть статью и посмотреть демки и скриншотики. Решение очень хорошее и удобное:
- Можно использовать без конфига
- Задизайнено для удобной интеграции в приложения и тулы автоматизации
- Можно стартовать и стопать профилирование с помощью SIGUSR2 сигналов (отдельный лайк)
- Програмное АПИ
- Кросс-платформенное cli
- Стандартный формат вывода результата профилирования

В статье приводится несколько примеров использования (типичный сценарий: запустить сервер, сделать запросы, остановить профилирование) и различные бенчмарки

https://blog.platformatic.dev/introducing-next-gen-flamegraphs-for-nodejs

#development #javascript #nodejs #performance #flamegraph #profiling

MCP-UI - Interactive UI Components for MCP

Если вы более менее активно используете AI, то вы наверняка знаете, что такое MCP. Это протокол для интеграции инструментария в ИИ-агенты. MCP-UI предлагает решение для mcp с интерактивным UI. Т.е. у вас в чате не просто "был вызван тул такой-то", а показывается полноценный UI, который наглядно показывает результат, позволяет с ним повзаимодействовать и доуточнить (что приведет еще к одному вызову тула)

Демка выглядит интересно. Возможно когда нибудь увидим что-то такое в ИИ-чатах и агентах

https://mcpui.dev/

#development #javascript #mcp #ai