jsonrepair

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




https://github.com/josdejong/jsonrepair

#development #JSON #library

Поговорим про клавиатурки

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

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

Когда-то я использовал обычные клавиатуры и все было хорошо. Я умел печатать в слепую (спасибо за это тысячам наигранных часов в World of Warcraft). Но мне стало неудобно использовать обычную клавиатуру, когда я стал писать много веб кода.

Я пишу код быстро. Ял знаю основные хоткеи, которые позволяют мне навигироваться по файлам и сущностям без использования мышки. Когда я парно программирую с людьми, которые так не умеют - я стараюсь их переучить, т.к. использование мышки настолько замедляет работу, что мне становится больно наблюдать за этим. Скролить Tree View мышкой для поиска файла (вместо jump to file или, на худой конец find in directory) или искать метод в файле через скрол (вместо jump to symbol) - это примерно как купить феррари и ездить со скоростью 20км\ч - в целом легально, но это какая-то мука.

Мои знакомые говорят, что прямая работа с кодом - не более 20% времени работы программиста, а печать кода - и того меньше. Поэтому нет смысла оптимизировать эту часть работы. Но это не матчится с моим опытом. Там, где я быстро проверяю десятки маленьких гипотез (например "можно ли решить задачу хуком в роутере?"), получая новые знания, люди с мышкой проверяют за то же время всего парочку.

Но даже знание хоткеев не спасает - иногда нужно использовать клавиши, которые требуют полной перестановки кистей на клавиатуре: <>, стрелочки, pgup и тд. 

Какое-то время я, для упрощения работы с этими клавишами, использовал разные костыли на уровне ОС (благо в линуксе с этим все очень просто). Но в какой-то момент мне показалось, что это какие-то костыли и нужно "нормальное" решение. В этот момент я задумался о приобритении программируемой клавиатуры, которая разделена на 2 части. Как правило такие клавиатуры уже содержат в себе раскладку, которая не требует движения кистей вообще.

Я пробовал разные варианты клавиатур, но последние несколько лет работаю с lilly 58pro. С этой клавиатуры и пишу пост. Навык печати на обычных клавиатурах еще не потерял, но переход с классической клавиатуры на сплит занимает где-то часик-два (обычно проблемы с клавишами на краю клавиатуры - win, cmd, f12, т.к. они могут по разному располагаться на клавиатурах). Я использую низкопрофильные свичи kailh choc, линейные и тактильные. Тактильные для обычных клавиш, а линейные для модификаторов и того, что надо зажимать.

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

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



#note #keyboards

How to test React Server Component

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

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


https://www.nico.fyi/blog/how-to-test-react-server-component

#development #javascript #react #reactServerComponents #testing

Expert Generalists

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

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

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

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

В чем сила таких специалистов:

Как правило, такие люди быстро обучаются - они изучат новый инструментарий, если он решает текущую задачу. Как следствие, они создадут более лучшее решение за счет подходящих инструментариев.

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

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

Ключевые качества экспертов-генералистов:
- Любознательность
- Умение сотрудничать
- Фокус на клиенте (бизнесовая направленность)
- Ставка на фундаментальные знания
- Широта знаний
- Способность понимать позицию смежных доменов (например, понимать проблемы SRE или DevOps)

Многие эксперты-генералисты вырастают в технических лидеров

Встает закономерны вопрос: "где брать таких специалистов?". Текущий найм устроен так, что мы скорее наймем ультра-эксперта в технологии, чем наймем человека, который любознателен и умеет погружаться в новые домены. В статье предлагается подход из двух решений:
- Перестать смотреть только на узкие хард-скилы. Вместо этого следует проверять человека на обучаемость, любознательность, создание условий для совместной работы
- Проводить внутренние тренинги и воркшопы, цель которых - погрузить специалистов в смежные области. В Thoughtworks есть 3 воркшопа, в которых специалисты делают решения из смежных областей. В рамках воркшопа они реализуют простые прототипы kafka, kubernetes, delta lake (штука для работы с данными). Создав прототип, люди начинают понимать базовые принципы, на которых основаны эти системы и начинают видеть рабочие ситуации с другой стороны

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

Для каждой ключевой компетенции в команде нужен 1-2 специалиста.

---

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



https://martinfowler.com/articles/expert-generalist.html

#managment #tshape #martinFowler

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 примеров использования этого функционала.

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

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