npq allows you to audit npm packages before you install them

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

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

https://github.com/lirantal/npq

#development #javascript #security #audit

ts-regexp - a minimal, statically typed alternative to JavaScript's RegExp

ts-regexp - либа для типизированных RegExp.

Проще показать код, чем расписывать, что умеет либка


Это обычный RegExp (читать голосом из рекламы "это обычный порошок") - выводятся весьма абстрактные типы

const groups1 = new RegExp('^(?<year>\\d{4})-(?<month>\\d{2})-(?<day>\\d{2})$', 'g').exec('2000-10-24')!.groups;
//      ⤴ '{ [key: string]: string; } | undefined' 🤮

А это ts-regexp - выводятся захваченные группы

const groups2 = typedRegExp('^(?<year>\\d{4})-(?<month>\\d{2})-(?<day>\\d{2})$', 'g').exec('2000-10-24')!.groups;
//      ⤴ '{ year: string, month: string, day: string }' 🥰

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

https://github.com/codpro2005/ts-regexp

#development #javascript #typescript #regexp #library

What Improves Developer Productivity at Google? Code Quality

В 2022 году Google опубликовали внутреннее исследование по продуктивности разработчиков. Если коротко, то основной вывод: лучший способ повысить продуктивность - улучшить качество кода.

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

В Google периодически разработчикам рассылают опрос в стиле "насколько вы удовлетворены" - работой, инструментами, коллегами и тд. Отвечать на них нужно в спектре нет - скорее нет - не знаю - скорее да - да. Каждый разработчик проходит такой опрос раз в 9 месяцев. Также в Google собирают различные данные по работе разработчиков - время на code review, время на влитие изменений, количество написанных строчек кода и тд

В исследовании ищут связь между ответом на вопросом "насколько вы были продуктивны последние 3 месяца" и ответами на другие вопросы (субъективные метрики) и метриками (объективные цифры). Искали корреляцию между ответом на "вы продуктивны?" и 39 метриками. Важное отличие исследования - для выявления связи был выбран метод панельного анализа - это когда вывод делается на основе слежения за одним и тем же человеком какое-то время. Панельный анализ выявил причинно-следственную связь "качество кода" => "продуктивность"

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

Что больше всего влияет на ощущаемую продуктивность (расположено в порядке убывания влияния):
- Удовлетворенность качеством кода 📈(выше - лучше)
- Смена приоритетов 📉 (негативное влияние)
- Тех долг проекта 📉
- Использование новейших тулов и инфры 📈
- Удовлетворенность тулингом и инфрой 📈
- Медленное Code Review 📉
- Сложное изучение инструментария 📉
- Тех долг зависимостей 📉
- Скорость сборки приложения 📈
- Организационные изменения 📉

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

По результатам исследования Google решили заняться повышением качества кода:
- Провели несколько внутренних конференций по качеству кода
- Создали модель Technical Debt Maturity Model и фреймворк для управления техническим долгом
- Команды поставили цели в OKR по управлению техническим долгом
- Раздают награды за большой вклад в улучшение качества кода

Какие минусы у исследования:
- Это Google. Многие идеи актуальны только в контексте Google и не подходят другим контекстам
- Мало объективных метрик, но много субъективных. Многие метрики, имхо, странные (физическое расстояние до менеджера). В то же время, нет многих других метрик (ну например, количество, приемочных багов)
- Особенно странно, что целевая метрика - "ощущаемая человеком продуктивность" - тоже субъективная
- Замерялся индивидуальный перформанс, а не командный
- Выводы на основе 2х замеров каждого разработчика. 2х замеров, имхо, мало.

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

В документе есть много интересного - не поленитесь почитать сами.

https://storage.googleapis.com/gweb-research2023-media/pubtools/6862.pdf

#development #research #google #codequality #technicalDebt #productivity

Дайджест за 2025-07-28 - 2025-08-01

Expert Generalists
Статья в блоге Мартина Фаулера про T-shaped специалистов. Точнее, все текущие термины (T-shape, П-shape, и другие) плохо подходят, поэтому в статье вводится термин Expert-Generalist, который означает, что человек одновременно является и экспертом (в противовес generalist) и использует свою экспертизу во многих областях (в противовес эксперту в одной области).

В данном случае имеется в виду, что человек является экспертом в фундаментальных понятиях, которые позволяют ему быть успешным в областях, которые построены на этих понятиях. Классический пример из IT, это когда человек имеет опыт написания ПО на 3-4 языка программирования и ему после этого уже не так важно, на каком именно другом языке писать код, пока этот язык следует общим парадигмам (основан на том же фундаменте). Условно, человек, который писал на JS, PHP, JAVA, C++ с легкостью может войти в Go, Rust, Kotlin. Но, вероятно, столкнется с некоторыми проблемами при входе в Haskell. Но, скорее всего, сможет это сделать в короткие сроки.

npq allows you to audit npm packages before you install them
npq - исполняемый пакет в npm, который проверяет безопасность пакетов перед их установкой и выводит найденные уязвимости, после чего юзер может принять решение, устанавливать ему пакет или нет.

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

ts-regexp - a minimal, statically typed alternative to JavaScript's RegExp
ts-regexp - либа для типизированных RegExp.


What Improves Developer Productivity at Google? Code Quality
В 2022 году Google опубликовали внутреннее исследование по продуктивности разработчиков. Если коротко, то основной вывод: лучший способ повысить продуктивность - улучшить качество кода.

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

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

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

How we made JSON.stringify more than twice as fast

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

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

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

https://v8.dev/blog/json-stringify

#development #javascript #v8 #JSON #performance

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

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

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

Какие модели есть в области развития людей

4 Уровня обучения (the four levels of teaching)
Модель от 1969 года за авторством Martin Broadwell говорит, что путь изучения чего-либо проходит через 4 этапа:
- Неосознанная некомпетентность
- Осознанная некомпетентность
- Осознанная компетентность
- Неосознанная компетентность

В чем особенность каждого этапа
Неосознанная некомпетентность - на этом этапе человек не знает, что он чего-то не знает. Бывает так, что человек знает про что-то, но на самом деле не представляет что там внутри. Типичное в IT "Почему дизайнеры/фронтендеры так долго красят кнопку?". Для перехода на следующий момент должен произойти какой-то момент, в котором человек осознает, что все сложнее, чем ему кажется (AHA! monent)

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

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

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

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


---



Это, конечно, круто, но как понять кого развивать?
Есть несколько моделей

Модель TOP - Таланты, Возможности, Желания

По каждому человеку надо узнать
- Что человек умеет делать
- Что человек может делать
- Что человек хочет делать

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

В идеале вам надо находит те области, в которых собран сразу весь T, O, P. Если где-то собрано только 2 из 3, то надо подумать, можно ли подтянуть 3 фактор. Самый простой пример - человек хочет научиться настраивать CI/CD, но думает что на проекте нет возможности. Однако, если хорошо подумать (или поговорить с руководителем), окажется, что задачи на настройку CI/CD на самом деле есть.

Модель оценки потенциала 9 box grid
Также простая и эффективная модель.
Есть 2 оси:
- Перформанс человека
- Потенциал человека

Каждая ось делится на 3 отрезка:
- Хороший\высокий
- Средний
- Плохой\низкий

Получается 9 ячеек от "плохой перформанс, низкий потенциал" до "хороший перформанс\высокий потенциал"

Ну собственно по матрице, примерно понятно что надо делать

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

---

Были еще пару моделей, но они не влезут в пост.

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




#note #stratoplan

No, AI is not Making Engineers 10x as Productive

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

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

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

Но использование ИИ не дает суперпроизводительности в следующих сценариях:
- Использование инструментария, на котором LLM не обучался
- Реализация правок в сложной или большой кодовой базе
- Написание "хорошего" кода. Автор говорит, что код, генерируемый ИИ, не годиться для поддержки
- Работа, не связанная с кодом напрямую

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

Настоящая работа намного шире, чем просто кодинг.

Также автор подсвечивает интересную мысль: те 10х инженеры, которых он видел, были 10х инженерами не за счет быстрого кодинга, а за счет создания простых в поддержке и развитии решений и также за счет того, что НЕ делали лишней работы. Разработка с ИИ же, наоборот, подталкивает делать сложные в поддержке и развитии решения, а также не останавливают от делания лишней работы, а наоборот, подталкивают к этому (например, когда вместо простого решения в 1 файл ИИ предлагает я хотел просто сделать все по какому-нибудь архитектурному паттерну)

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

https://colton.dev/blog/curing-your-ai-10x-engineer-imposter-syndrome/

#development #ai

Express Slow Down

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

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

Звучит интересно, хотя и не для всех случаев. Где-то замедлять обработку - приемлемо, а где-то - прямое ухудшение UX. Бездумно использовать не стоит, но можно задуматься о применении такого паттерна.

https://github.com/express-rate-limit/express-slow-down

#development #javascript #nodejs #express #github #library #middleware

Почему стоит использовать Tagged Unions при разработке на TypeScript

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

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

Например, представьте, что мы из API получаем список интересных мест на карте. Часть мест - это точки, часть - области. И API отдает и те и другие с полем coordinates, которое хранит кортеж из широты и долготы для точки, и массив кортежей для области

type Response = {
   name: string;
   coordinates: [number, number] | [number, number][]
}

Во всем коде, который работает с такой структурой, придется писать логику проверки структуры объекта.

Вместо этого, мы можем сделать это 1 раз и сохранить в поле, а само поле использовать для определения типа

// не пинайте за код, это просто пример
type PointResponse = Response & { type: "point" }
type PolygonResponse = Response & { type: "polygon" }

function tagResponse(item: Response) {
    const type = Array.isArray(item.coordinates[0]) ? "polygon" : "point"
    return {
        type,
        ...item
    }
}

function handleResponse(item: Response) {
    const taggedItem = tagResponse(item)
    switch (taggedItem.type) {
        case "point":
            // point logic
            break;
  case "polygon":
         // polygon logic
         break;
    }
}

Код получился субъективно лучше, чем если бы мы воткнули проверкки на поля. Особенно, если бы пример был сложней т.к. текущий - очень утрированный.

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

В статье приводятся и другие примеры и примеры, когда паттерн используется в рамках других паттернов (например, Result-монада)

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

https://habr.com/ru/companies/megafon/articles/933752/

#development #javascript #typescript

Дайджест за 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