The new Cookie Store API

Внезапно узнал, что уже 4 года как существует новое API для работы с куками, которое давно доступно в Chrome, недавно стало доступно в Safari и все еще недоступно в Firefox - Cookie Store API

Новое API намного удобнее. Хотя любое API, по сравнению со старым, будет удобнее.

Первое, что бросается в глаза - это человеческий интерфейс для установки. Если вам нужно просто установить значение - cookieStore.set("cookie1", "cookie1-value");. Если вам нужна полная настройка:

cookieStore.set({
name: 'theme',
value: 'dark',
path: '/',
partitioned: false,
sameSite: 'strict',
});


Второе, что бросается в глаза - это то, что все взаимодействие стало асинхронным
try {
await cookieStore.set("cookie1", "cookie1-value");
} catch (error) {
console.log(`Error setting cookie1: ${error}`);
}


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

Еще 1 фича не бросается в глаза, но она очень крутая - можно наконец-то подписаться на изменения кук и увидеть измененные и удаленные куки
cookieStore.addEventListener('change', (event) => {
console.log(event);
});


Пример использования из статьи: синхронизируем состояние стора с состоянием куки
cookieStore.addEventListener('change', (event) => {
const deleted = ev.deleted.find((c) => c.name === THEME_COOKIE_NAME);

if (deleted) {
setStoredTheme(undefined);
return;
}

const changed = ev.changed.find((c) => c.name === THEME_COOKIE_NAME);

if (changed) {
setStoredTheme(changed.value);
return;
}
})


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

https://fotis.xyz/posts/the-new-cookie-store-api/

#development #javascript #cookie

Introducing Zod 4 beta

Спустя несколько лет с выхода Zod v3 выпустили бетку Zod v4. Zod - библиотека для валидации объектов на мэтч с переданной схемой.

В 4-м релизе увеличили скорость работы валидации и работы TS по валидации типов, уменьшили размер бандла, добавили новые удобные API. Если вы используете Zod - рекомендую запланировать обновление.

Что интересного уже есть в бетке

Ускорение
- В 2.6 раз быстрее парсинг строк
- в 3 раза быстрее парсинг массивов
- в 8 раз быстрее парсинг объектов
- в 20 раз ускорение инициализации typescript на типах Zod
- в 2 раза уменьшили бандл сайз
- Если вам этого мало - сделали @zod/mini, который содержит основной функционал и весит в 6.6 раз меньше

Улучшили работу со схемами:

Сделали отдельную систему для описания метаданных к схемам

import * as z from "zod";

const myRegistry = z.registry<{ title: string; description: string }>();

const emailSchema = z.string().email();

myRegistry.add(emailSchema, { title: "Email address", description: "..." });
myRegistry.get(emailSchema);
// => { title: "Email address", ... }



Сделали вывод JSON-схемы

import * as z from "zod";

const mySchema = z.object({name: z.string(), points: z.number()});

z.toJSONSchema(mySchema);
// => {
// type: "object",
// properties: {
// name: {type: "string"},
// points: {type: "number"},
// },
// required: ["name", "points"],
// }



Сделали новое API для корректного получения типа объекта. В посте упоминают кейс, когда у одной схемы поле - опциональное (можно не указать), а другой - обязательное, но значение может быть undefined. Т.е. грубо говоря
type Obj1 = {
prop?: string;
}

type Obj2 = {
prop: string | undefined;
}


Разница небольшая, но она есть. В Zod3 нельзя получить корректный тип для этих объектов.

z.object({ name: z.string().optional() });
// { name?: string | undefined }

z.object({ name: z.union([z.string(), z.undefined()]) });
// { name?: string | undefined }


В Zod4 добавили новый метод, который это умеет, но опциональность ключа там указывается в имени ключа (что, конечно, странно. В друг у нас действительно поле со знаком в конце, что тогда делать?)
const ValueOptional = z.interface({ name: z.string().optional()});
// { name: string | undefined }

const KeyOptional = z.interface({ "name?": z.string() });
// { name?: string }


Кроме того, z.interface позволяет описывать цикличные типы проще, чем это было в Zod3

import * as z from "zod"; // zod@4

const Category = z.interface({
name: z.string(),
get subcategories() {
return z.array(Category)
}
});



Обработка ошибок
Во первых, добавили возможность указать локаль для вывода ошибок

import * as z from "zod";

// configure English locale (default)
z.config(z.locales.en());


Во вторых, улучшили форматирование ошибок
✖ Unrecognized key: "extraField"
✖ Invalid input: expected string, received number
→ at username
✖ Invalid input: expected number, received string
→ at favoriteNumbers[1]


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

https://v4.zod.dev/v4

#development #javascript #library #zod #release

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

How to get deep traces in your Node.js backend with OTel and Deno
Deno в одном из недавних релизов добавили нативную поддержку Open Telemetry - инструментария, которая добавляет возможности для observability вашей системы. Буквально можно смотреть на что конкретно было затрачено время, пока сервер отвечал пользователю.

Данная статья в целом не погружается в глубоко работу Open Telemetry, но подсвечивают, что OT в nodejs сделан через костыли, а для подключения надо написать 2 экрана кода (в свое время сам ужаснулся этой SDK), а в Deno достаточно указать ключ запуска deno

Конспект книги Team Topologies, часть №1 - team-first mindset
Основные концепции:
Team-first mindset
Команда - самый эффективный способ организации людей для решения проблем. Поэтому важно перестроить сознание на team-first и уметь работать с командами:

Конспект книги Team Topologies, часть №2 - типы команд и взаимодействия
Во всех компаниях разная культура, разные процессы и разные команды. Но фундаментально все команды и взаимодействия между ними можно свести к 4 базовым видам команд и 3 базовым видам взаимодействия



Конспект книги Team Topologies, часть №3 - итоги
В этом посте не будет какой-то прям новой инфы из книги. Тут я резюмирую про что книга и для кого

В рамках предыдущих постов я срезал очень много углов т.к. уместить 200-300 страниц в 8000 символов и не потерять смысл - сложно.

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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





#note #stratoplan #managment

Конспект книги Team Topologies, часть №3 - итоги

В этом посте не будет какой-то прям новой инфы из книги. Тут я резюмирую про что книга и для кого

В рамках предыдущих постов я срезал очень много углов т.к. уместить 200-300 страниц в 8000 символов и не потерять смысл - сложно.

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

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

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

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

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


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

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


Книгу строго рекомендую к прочтению, если она матчится с вашей текущей ролью.



#note #TeamTopology #book #конспект #managment

Конспект книги Team Topologies, часть №2 - типы команд и взаимодействия

Во всех компаниях разная культура, разные процессы и разные команды. Но фундаментально все команды и взаимодействия между ними можно свести к 4 базовым видам команд и 3 базовым видам взаимодействия

4 базовых вида команд:
- Продуктовые команды (Stream aligned teams, уточню что перевод не совсем корректный, но он наиболее понятный)
- Команды сложной подсистемы (complex-subsystem team)
- Платформенные команды (platform team)
- Поддерживающие команды (enabling team)

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

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

Платформенные команды:
- Цель команды - обеспечить продуктовым командам возможность доставлять фичи с высокой степенью автономности
- Платформенная команда взаимодействует с продуктовыми командами для понимания того, что им нужно и совместного прототипирования
- Платформенная команда развивает платформу как продукт
- Крупные платформы также внутри могут делиться на команду и иметь внутри все 4 типа команд

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


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

Как команды могут друг с другом взаимодействием:
- Совместая работа
- X-as-a-Service
- Фасилитация

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

X-as-a-Service:
- Потребление или предоставление чего-либо с минимальным взаимодействием
- Этот тип взаимодействия можно использовать со множеством команд одновременно
- Эффективно на поздних этапах развития чего-либо, когда важна стабильность поставки, а не поиск новых решений

Фасилитация:
- Помощь или получение помощи от другой команды для устранения препятствий
- Режим взаимодействия рекомендуется использовать с небольшим количеством команд одновременно

Проще это объяснять на примерах:
- Поддерживающая команда в режиме фасилитации помогает продуктовой команде научитья использовать инструментарий для UI-автотестов
- Платформенная команда предоставляет инструментарий для деплоя в прод как X-as-a-Service
- ML-команда (Команда сложной под-системы) в режиме совместной работы с продуктовой командой ищут оптимальные способы использования ML для автоматизации проверки контента пользователей (отзывов например)

Конечно, все несколько сложнее, но в рамках обзора приходится ужиматься по контенту



#note #TeamTopology #book #конспект #managment

Конспект книги Team Topologies, часть №1 - team-first mindset

Основные концепции:
Team-first mindset
Команда - самый эффективный способ организации людей для решения проблем. Поэтому важно перестроить сознание на team-first и уметь работать с командами:
- Когда команда - неделимый юнит для реализации любой работы
- Похвала и порицание всегда идут на команду, а не на отдельных людей
- Цели команды важнее собственных

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

Числа Данбара
Антрополог Данбар проанализировал различные сообщества людей и заметил, что есть 4 "круга" социальных связей:
- Очень близкие отношения с 5-7 людьми
- Приятели, хорошие друзья - 15 человек
- Семья, коллеги - 50 человек
- Стая - 150-200 человек

Это не какая-то математическая модель - это результат наблюдений.

Как это перекладывается на IT и организации:
- Идеальный размер команды - 5-7 человек. Но в крайнем случае - до 15, но тогда высок риск что люди внутри сами поделятся на 2 группы
- 50 человек - уровень подразделения
- 200 человек - уровень отдела

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

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

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

Надо минимизировать первые 2 типа нагрузки (через обучение и автоматизацию) и сфокусироваться на 3 типе когнитивной нагрузки, решение которой позволяет делать более крутые фичи

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

Главная концепция - Закон Конвея

> Дизайн IT-систем повторяет дизайн коммуникации организации

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

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

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

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

Я прошелся совсем по верхам, но это минимум, который необходимо знать для организации команд. На основе этих идей создана концепция Team Topologies об основных типах команд и их взаимодействии, которую я раскрою в следующих постах.



#note #TeamTopology #book #конспект #managment

How to get deep traces in your Node.js backend with OTel and Deno

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

Данная статья в целом не погружается в глубоко работу Open Telemetry, но подсвечивают, что OT в nodejs сделан через костыли, а для подключения надо написать 2 экрана кода (в свое время сам ужаснулся этой SDK), а в Deno достаточно указать ключ запуска deno



https://deno.com/blog/otel-tracing-in-node-and-deno

#development #javascript #opentelemetry #deno

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

Node Modules Inspector
Node Modules Inspector - инструмент, позволяющий провести анализ пакета - от чего зависит, какие уязвимости, сколько весит и все такое. Главные отличительные особенности этого проекта: очень приятный UI и запуск прямо в браузере в Web Container (песочница, в которой можно запускать что-то близкое к nodejs)

Выглядит нереально круто: выбираешь пакет, запускается WebContainer, внутри него запускается pnpm и устанавливает пакет и выводит всю стату для анализа

Omlet - Uncover React component usage across your dev teams
Еще один инструмент для анализа кода, но на этот раз для дизайн-систем и UI-китов. Омлет собирает аналитику по использованию компонентов в коде: какие компоненты как используются, как быстро отказываются от deprecated компонентов, какие компоненты не из дизайн-системы разработчики часто используют (кандидаты на вынос в дизайн-систему)

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

Reproducibility vs. Provenance: Trusting the JavaScript Supply Chain
reproduce - инструмент, который проверяет, что пакет, скачиваемый из npm, действительно собран из исходников на github. Т.е. инструмент проверяет пакеты на reproducibility.

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

Playwright: игра в скриншотные тесты
Отличная статья от Okko про реализацию скриншот-тестов в связке playwright + storybook. Она одновременно верхнеуровневая (т.е. автор не погружается прям в самые детали) и одновременно содержит весь самый сок, необходимый для настройки скриншот-тестов в проекте.

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

Серия бесплатных воркшопов про менеджмент от Стратоплан
Всем привет, с 14 по 18 апреля c 17:00 по 19:00 по МСК будут проходить бесплатные 2х-часовые занятия от Стратоплан по менеджменту. Среди спикеров есть как минимум 2 чувака, которых я рекомендую читать и слушать всем - Виталий Шароватов (слежу за ним уже лет 7) и Дмитрий Болдырев, который недавно выпускал крутую серию постов про образование команд из рабочих групп

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

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

Серия бесплатных воркшопов про менеджмент от Стратоплан

Всем привет, с 14 по 18 апреля c 17:00 по 19:00 по МСК будут проходить бесплатные 2х-часовые занятия от Стратоплан по менеджменту. Среди спикеров есть как минимум 2 чувака, которых я рекомендую читать и слушать всем - Виталий Шароватов (слежу за ним уже лет 7) и Дмитрий Болдырев, который недавно выпускал крутую серию постов про образование команд из рабочих групп

Будет 5 занятий, на которых рассмотрят:
– первые шаги: ожидания и задачи после назначения
– найм и как это делать правильно
– как создать команду
– как ставить и контролировать задачи
– лидерство

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

Бесплатная регистрация здесь

#managment #stratoplan #note

Playwright: игра в скриншотные тесты

Отличная статья от Okko про реализацию скриншот-тестов в связке playwright + storybook. Она одновременно верхнеуровневая (т.е. автор не погружается прям в самые детали) и одновременно содержит весь самый сок, необходимый для настройки скриншот-тестов в проекте.

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

В статье рассказывается про:
- Как отключить анимации в дополнение к API playwright
- Как получить список всех историй и пройти по ним в цикле для запуска всех скриншот-тестов
- Как работать с загрузкой изображений, шрифтов и других ресурсов
- Как и зачем запускаться в docker
- Как работать с эталонами
- Как настраивать Playwright

В общем, мастхев ссылка если вы занимаетесь скриншот-тестированием или хотите поставить этот процесс

https://habr.com/ru/companies/okko/articles/890438/

#development #javascript #storybook #testing #screenshotTesting #habr #okko

Reproducibility vs. Provenance: Trusting the JavaScript Supply Chain

reproduce - инструмент, который проверяет, что пакет, скачиваемый из npm, действительно собран из исходников на github. Т.е. инструмент проверяет пакеты на reproducibility.

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

Provenance - это когда кто-то заявляет, что пакет и правда собран из исходников (например Github). reproducibility - это когда каждый может убедиться в том, что пакет собран из тех же исходников, что есть на github.

Теперь для проверки reproducibility есть reproduce.

https://blog.vlt.sh/blog/reproducibility

#development #npm #security

Omlet - Uncover React component usage across your dev teams

Еще один инструмент для анализа кода, но на этот раз для дизайн-систем и UI-китов. Омлет собирает аналитику по использованию компонентов в коде: какие компоненты как используются, как быстро отказываются от deprecated компонентов, какие компоненты не из дизайн-системы разработчики часто используют (кандидаты на вынос в дизайн-систему)

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

https://omlet.dev/

#development #uikit #react

Node Modules Inspector

Node Modules Inspector - инструмент, позволяющий провести анализ пакета - от чего зависит, какие уязвимости, сколько весит и все такое. Главные отличительные особенности этого проекта: очень приятный UI и запуск прямо в браузере в Web Container (песочница, в которой можно запускать что-то близкое к nodejs)

Выглядит нереально круто: выбираешь пакет, запускается WebContainer, внутри него запускается pnpm и устанавливает пакет и выводит всю стату для анализа

https://node-modules.dev/

#development #javascript #pnpm #performance #webcontainer

Дайджест за 2025-03-31 - 2025-04-04

A 10x Faster TypeScript
Команда TypeScript решила переписать компилятор на go. Кажется уже обсудили везде где только можно, поэтому я ничего особо нового не добавлю. Если коротко: компилятор typescript не очень быстрый и команде приходится заниматься хитрыми оптимизациями чтобы ускорить его. Логичный шаг - переписать компилятор на другой язык. Сделали прототип на go и он оказался в 10 раз быстрее на крупных проектах (типа vscode)

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

My LLM codegen workflow atm
Крутая статья, где автор рассказывает, как он используем LLM для разработки небольших приложений и для правок в существующих приложениях

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

Lynx: Unlock Native for More
Lynx - набор инструментов для создания нативных приложений на основе идей веб-технологий. Это что-то близкое к React Native, но не React Native (я, честно сказать, не уверен что до конца вообще понял разницу между Lynx и RN)

Этот инструментарий, в частности, используется в TikTok.

Javascript Game Tutorials
Занятный сайт, на котором собраны гайды, как делать игры на JS (пока 2 гайда на 1 игру). Сами гайды выглядят просто топово - все объясняет по шагам с интерактивом. Есть текст, есть codepen, есть youtube

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

End of Life
У многих продуктов есть End of life - конец поддержки мейнтейнером. Когда у продукта закончилась поддержка - нет никаких гарантий, что там будут чинить баги или фиксить дыры безопасности. Именно поэтому важно всегда обновлять те части проекта, проблемы в которых могут нести риски

Сайт собирает end of life кучи продуктов - начиная от опереционных систем и заканчивая библиотеками (jquery, react).

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

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

End of Life

У многих продуктов есть End of life - конец поддержки мейнтейнером. Когда у продукта закончилась поддержка - нет никаких гарантий, что там будут чинить баги или фиксить дыры безопасности. Именно поэтому важно всегда обновлять те части проекта, проблемы в которых могут нести риски

Сайт собирает end of life кучи продуктов - начиная от опереционных систем и заканчивая библиотеками (jquery, react).

Рекомендую сохранить в закладки


https://endoflife.date/

#development #endOfLife

Javascript Game Tutorials

Занятный сайт, на котором собраны гайды, как делать игры на JS (пока 2 гайда на 1 игру). Сами гайды выглядят просто топово - все объясняет по шагам с интерактивом. Есть текст, есть codepen, есть youtube

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


https://javascriptgametutorials.com/

#development #javascript #game #tutorial

Lynx: Unlock Native for More

Lynx - набор инструментов для создания нативных приложений на основе идей веб-технологий. Это что-то близкое к React Native, но не React Native (я, честно сказать, не уверен что до конца вообще понял разницу между Lynx и RN)

Этот инструментарий, в частности, используется в TikTok.

Идея инструмента, в целом, обычная: берем лучшие части веба (например jsx, css), делаем ядро инструмента, которое обеспечит быстрый запуск и плавную работу (например, в Lynx, отдельный тред для UI, а вся логика в бекграунде), делаем свой тулинг сборки (в частности здесь тулинг поверх rspack), делаем кросс-платформенность (можно скомпилировать в web).

Выглядит интересно. Использование инструмента в TikTok дает некоторое доверие.

https://lynxjs.org/blog/lynx-unlock-native-for-more

#development #javascript #react #native #tiktok

My LLM codegen workflow atm

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

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

Если подробнее
Сначала необходимо побрейнштормить вместе с LLM идею
Ask me one question at a time so we can develop a thorough, step-by-step spec for this idea. Each question should build on my previous answers, and our end goal is to have a detailed specification I can hand off to a developer. Let’s do this iteratively and dig into every relevant detail. Remember, only one question at a time.

Here’s the idea:


Когда брейншторм окончен, необходимо сгруппировать это все в требования
Now that we’ve wrapped up the brainstorming process, can you compile our findings into a comprehensive, developer-ready specification? Include all relevant requirements, architecture choices, data handling details, error handling strategies, and a testing plan so a developer can immediately begin implementation.


Вывод сохраняется в файл spec.md

Затем составляется план разработки, из которого будет собран чеклист, которому могут следовать ИИ-агенты, а также который будет загружен в ИИ-агента, который пишет код (github copilot workspace, cursor etc)
Draft a detailed, step-by-step blueprint for building this project. Then, once you have a solid plan, break it down into small, iterative chunks that build on each other. Look at these chunks and then go another round to break it into small steps. review the results and make sure that the steps are small enough to be implemented safely, but big enough to move the project forward. Iterate until you feel that the steps are right sized for this project. From here you should have the foundation to provide a series of prompts for a code-generation LLM that will implement each step. Prioritize best practices, and incremental progress, ensuring no big jumps in complexity at any stage. Make sure that each prompt builds on the previous prompts, and ends with wiring things together. There should be no hanging or orphaned code that isn't integrated into a previous step. Make sure and separate each prompt section. Use markdown. Each prompt should be tagged as text using code tags. The goal is to output prompts, but context, etc is important as well.




Затем, собственно, запускается ИИ-агент. Автор рассматривает разные варианты запуска (где-то он сам переносит вывод ИИ в IDE, где-то агент сам пишет код и запускает тесты).

Выглядит круто. Рекомендую посмотреть самостоятельно т.к. часть вещей я опустил.

https://harper.blog/2025/02/16/my-llm-codegen-workflow-atm/

#development #ai #llm

A 10x Faster TypeScript

Команда TypeScript решила переписать компилятор на go. Кажется уже обсудили везде где только можно, поэтому я ничего особо нового не добавлю. Если коротко: компилятор typescript не очень быстрый и команде приходится заниматься хитрыми оптимизациями чтобы ускорить его. Логичный шаг - переписать компилятор на другой язык. Сделали прототип на go и он оказался в 10 раз быстрее на крупных проектах (типа vscode)

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

TypeScript 6 будет еще на TS. Typescript 7 уже будет полностью на Go.


https://devblogs.microsoft.com/typescript/typescript-native-port/

#development #typescript #golang #performance

Всем привет! Со следующей недели возобновляется постинг интересных ссылок. А пока еще немного #offtop :)

Давайте расскажу, как проходит отбор в спикеры на конференцию

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

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

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

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

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

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

Далее идет встреча с программным комитетом, где ПК расспросит про идею, ваш опыт и даст рекомендации (например, было бы интересно послушать не просто про скриншот-тестирование, но скриншот+ui-тестирование). Ребята из программного комитета реально помогают изменить основу доклада так, чтобы и слушателям было интереснее, и ваш доклад был лучше

Далее программный комитет либо принимает доклад, либо отклоняет

Если доклад принимается, то:
- Назначается стартовый синк, где обсуждается, какой флоу может быть у доклада и что стоит рассказать
- Назначаются регулярные прогоны, на которых программный комитет дает обратную связь по контенту: что надо раскрыть, что слишком сильно раскрыто и надо меньше, что следует поменять, что следует еще происследовать
- На первых прогонах не обязательно должны быть готовы слайды. Вполне можно позволить себе шарить экран с каким-нибудь гугл доком
- С каждым следующим прогоном доклад все больше должен быть готов на итоговый. Т.е. эволюция примерно такая: идея => тезисы + флоу => заглушка контента => слайды-заглушки => рабочие слайды (контент есть, но оформление на уровне джуна) => pre production ready слайды

Программный комитет состоит из крутых инженеров и опытных спикер-коучей, поэтому они дают крутую обратную связь по флоу. Бывало и так, что мне приходилось разворачивать флоу доклада несколько раз во время подготовки (т.к. например углублялся в дебри, которые интересны только мне, но не широкому кругу людей), поэтому черновые варианты долкада должны быть easy to edit & refactor

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

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

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

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

Конференция проходит в Новосибирске и очень ламповая по своей атмосфере. Приезжайте как слушатель или как спикер - развиртуализируемся!


#codefest #note

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

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

Я вчера потратил на это около 3-4 часов, но в конце был доволен просто как слон :) Получил и гибкое производство и научился еще связывать несколько ЖД путей (в аналогии с ESB - научился переопубликовывать сообщение из одного инстанса кафки в другой) - это понадобилось для доставки отдаленных ресурсов на основной производственный сектор.

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

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

#note #offtop #edenCrafters

Я в небольшом отпуске, поэтому с постами на этой неделе туго. Думал, что прочту все дайджесты и наберу ссылок, но между прогулками я полносью поглащен игрой Eden Crafters. Про нее и расскажу. Не сильно вяжется с тематикой канала, поэтому #offtop

Eden Crafters - это игра, в которой вас высаживают на безжизненной планете и которую нужно терраформирмировать, т.е. сделать пригодной к жизни. Делать это надо при помощи создания производственных цепочек: добыть руду, переплавить, получить детали А Б В, из деталей А Б сделать деталь Г, из деталей В и Г получить деталь Д. Необходимо также добывать электричество и воду. И из всего этого строить разные механизмы, которые:
- Меняют температуру
- Поглощают радиацию
- Озеленяют местность
- Меняют состав атмосферы
- Отчищают озера

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

Но я хотел рассказать не о самой игре (хотя могу рекомнедовать в нее поиграть), а о том как я вчера в игре  реализовывал enterprise service bus pattern.

ESB - если очень сильно утрировать, это когда у вас есть сервисы, но они общаются не напрямую, а через какую-то шину событий. Например, в реальности это реализуется с помощью RabbitMQ и Kafka - одни сервисы отсылают туда события, другие эти события считывают. В JS-мире близко по духу находится Event Bus pattern - это когда у нас есть виджеты\модули, но они общаются через шину событий (которую в браузере можно реализовать через DOM-API - через postMessage или createEvent).

Как я пришел к этому паттерну в игре. Я уже говорил, что в игре необходимо создавать цепочки производства. Например:
- Есть бур, который извлекает 240 золотой руды в минуту
- Есть кузница, которая может превращать 60 руды в 30 слитков в минуту
- Это значит, что оптимально будет разместить 4 кузницы
- Для этого надо поставить разветвители конвейеров. Бур => разветвитель 1 в 3 (из 1 конвеера получается 3) => Кузница, Кузница, разветвитель 1 в 3 (Кузница, Кузница) => 2 соединителя 3 в 1 => на выходе получаем единый конвеер с 120 золотых слитков в минуту
- Дальше по аналогии делаем медные слитки, из них медные пластины (тоже может понадобится не 1 сборщик и потребуются разветвители), из пластин катушку с медной нитью
- Из нити + слитков получаем что-то еще

И таких цепочек - МНОГО. И они открываются по мере развития в игре.

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

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

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

И тут у меня открылась железная дорога. ЖД в игре устроена так, что есть:
- Дорога
- Вокзалы - там можно погрузить что-то одно в какой-то конкретный грузовой вагон, а еще можно выгрузить какой-то конкретный грузовой вагон. На примере: на вокзале можно сгружать золотые слитки в вагон №4 и забирать груз из вагона №3 (куда мы можем загружать на другом вокзале медную нить)
- Собственно поезд, который везет вагоны
- Вагоны

Я сначала не понимал зачем это вообще нужно, когда есть конвейеры. Но потом я понял, что можно реализовать ESB:
- Строим круговую железную дорогу вокруг огромной производственной площадки
- Когда мы хотим что-то сделать доступным на нашей ЖД (шине), необходимо поставить вокзал, поставить рядом с ним производство нужного ресурса, добавить к поезду вагон и сгружать в него поставляемый ресурс
- Когда мы хотим что-то получить из ЖД, необходимо поставить вокзал и сгружать необходимое

Writable Streams in Node.js: A Practical Guide

В NodeJS есть классная абстракция - stream. Она позволяет удобно работать с потоками и делать приложения, которые лучше работают под высокой нагрузкой. В данной статье разбирается, как создать свой кастомный Writable Stream, т.е. поток в который вы можете писать и интегрировать его во все потоковые-АПИ

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

https://pavel-romanov.com/writable-streams-in-nodejs-a-practical-guide

#development #javascript #nodejs #stream

Дайджест за 2025-03-17 - 2025-03-21

upfetch - advanced fetch client builder
upfetch - библиотека для удобной работы с fetch. В целом API максимально похоже на fetch, но добавлены всякие фишечки для удобства работы: таймауты, хуки, валидация, удобная передача body и query и тому подобное

Проще всего сравнить код на fetch с кодом на upfetch

React Scan
React Scan - инструмент, который находит проблемы в производительности React-приложений. Я не пробовал, но обещают сумасшедший DX - просто добавляете скрипт или устанавливаете браузерное расширение или запускаете cli, а инструмент вам скажет, какие конкретно компоненты требуют исправления перформанса.

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

Speeding up the JavaScript ecosystem - Rust and JavaScript Plugins
Достаточно необычная статья в серии про ускорение JS-тулинга. Если помните, есть чувак, который заходит в разный опенсорс, находит там проблемы перформанса и ускоряет инструменты в сотни раз. Тем самым доказывания, что надо иметь прямые руки, а не переписывать все на Rust или Go

Текущая статья тоже о том, что не обязательно переписывать все на Rust.

Michigan TypeScript Founder Successfully Runs Doom Inside TypeScript's Type System
Не знаю зачем вам эта информация, но система типов в TS - Тьюринг полная. Если утрировать, это значит, что на ней можно написать любую программу. Ну вот чел и переписал DOOM на системе типов. Пара триллионов строк кода, эмуляция ОЗУ, процессора и другого железа, 100 гигов оперативки чтобы это запустить - и вот DOOM уже запустился у вас в vscode с 0.000001 FPS.

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

Think JavaScript Is Slow? Here's How JIT (Just In Time) Compilation Makes It 100x Faster Instantly
Статья, показывающая на простых примерах, как работает JIT-компиляция и как она ускоряет скорость работы JS. В данной статье разбирается, какой байткод генерируется в разных ситуациях и как один и тот же код может быть представлен разным байткодом.

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

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

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

Think JavaScript Is Slow? Here's How JIT (Just In Time) Compilation Makes It 100x Faster Instantly

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

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

https://www.royalbhati.com/posts/why-js-is-fast

#development #javascript #performance #v8

Michigan TypeScript Founder Successfully Runs Doom Inside TypeScript's Type System

Не знаю зачем вам эта информация, но система типов в TS - Тьюринг полная. Если утрировать, это значит, что на ней можно написать любую программу. Ну вот чел и переписал DOOM на системе типов. Пара триллионов строк кода, эмуляция ОЗУ, процессора и другого железа, 100 гигов оперативки чтобы это запустить - и вот DOOM уже запустился у вас в vscode с 0.000001 FPS.

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

https://socket.dev/blog/typescript-types-running-doom

#development #javascript #typescript

Speeding up the JavaScript ecosystem - Rust and JavaScript Plugins

Достаточно необычная статья в серии про ускорение JS-тулинга. Если помните, есть чувак, который заходит в разный опенсорс, находит там проблемы перформанса и ускоряет инструменты в сотни раз. Тем самым доказывания, что надо иметь прямые руки, а не переписывать все на Rust или Go

Текущая статья тоже о том, что не обязательно переписывать все на Rust.

В чем суть. Автор работает в Deno и в Deno есть свой линтер, который написан на Rust. Но никто не будет писать кастомные правила для фронтенд-проектов на Rust: фронтендеры не смогут, а растовикам это не интересно.

Если же реализовывать мостик между JS и Rust, то затраты на коммуникацию съедят все профиты от введения Rust. Например, если передавать AST-дерево файла checker.ts из исходников TS размеом в 610к AST-нод между Rust и JS в json-формате, то это займет почти 3 секунды. Достаточно много.

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

Хороший пример задачи, где знание алгоритмов весьма кстати.

https://marvinh.dev/blog/speeding-up-javascript-ecosystem-part-11/

#development #javascript #rust

React Scan

React Scan - инструмент, который находит проблемы в производительности React-приложений. Я не пробовал, но обещают сумасшедший DX - просто добавляете скрипт или устанавливаете браузерное расширение или запускаете cli, а инструмент вам скажет, какие конкретно компоненты требуют исправления перформанса.

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

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

Осталось докрутить интеграцию с LLM и исходным кодом, чтоб инструмент сразу предлагал как исправить проблему

https://github.com/aidenybai/react-scan

#development #javascript #react #library #github #performance

upfetch - advanced fetch client builder

upfetch - библиотека для удобной работы с fetch. В целом API максимально похоже на fetch, но добавлены всякие фишечки для удобства работы: таймауты, хуки, валидация, удобная передача body и query и тому подобное

Проще всего сравнить код на fetch с кодом на upfetch

Ниже примеры из ридми проекта

Отправка query-параметров
fetch:
fetch(
`https://api.example.com/todos?search=${search}&skip=${skip}&take=${take}`,
)


upfetch:
upfetch('/todos', {
params: { search, skip, take },
})



Отправка body
fetch:
fetch('https://api.example.com/todos', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ title: 'New Todo' }),
})


upfetch:
upfetch('/todos', {
method: 'POST',
body: { title: 'New Todo' },
})



Валидация по схеме
import { z } from 'zod'

const posts = await upfetch('/posts/1', {
schema: z.object({
id: z.number(),
title: z.string(),
}),
})



Хуки

const upfetch = up(fetch, () => ({
onRequest: (options) => {
// Called before the request is made, options might be mutated here
},
onSuccess: (data, options) => {
// Called when the request successfully completes
},
onError: (error, options) => {
// Called when the request fails
},
}))


Настройка таймаута для всех запросов
const upfetch = up(fetch, () => ({
timeout: 5000,
}))



Из интересного, возможность использовать другие fetch-compatible api

import { fetch, Agent } from 'undici'

const upfetch = up(fetch)

const data = await upfetch('https://a.b.c', {
dispatcher: new Agent({
keepAliveTimeout: 10,
keepAliveMaxTimeout: 10,
}),
})


https://github.com/L-Blondy/up-fetch

#development #javascript #library #github #fetch

Дайджест за 2025-03-10 - 2025-03-14

TypeScript: the satisfies operator
Большой пост про satisfies оператор в TypeScript. Объясняется что такое satisfies оператор и какие основные юзкейсы у него есть

satisfies проверяет, что значение соответствует какому-то типу, не меняя тип значения.

import-in-the-middle
import-in-the-middle - библиотека для патчинга экспортов ESM-библиотек. Достаточно интересная штука, которая должна использоваться с умом. Для работы библиотеки необходимо регистрировать её как загрузчик в node.js

node --loader=import-in-the-middle/hook.mjs my-app.mjs

Запускаем Pong в 240 вкладках браузера
Вы видели челлендж "сделай игру, помещающуюся в 13кб", вы видели реализацию DOOM на всем чем можно. Но видели ли вы реализацию игры ping pong на фавиконках вкладок? Вот, можете посмотреть по ссылке

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

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


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

Migrating 160,000 Lines of Production Banking JavaScript to TypeScript with Zero Downtime
Статья про миграцию 160к строк кода с JS на TypeScript. Статья достаточно поверхностная и моментами странная.

Есть компания, это стартап про деньги на какой-то там ранней стадии (в оригинале seed-stage startup). Код запускается в двух рамтаймах: лямбды в AWS и GraphQL API в ECS. Т.к. стартап в сфере финансов, то необходимо перейти на TS (чтобы избегать глупых ошибок, которые будут дорого стоит) и сделать это без даунтайма

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

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

Migrating 160,000 Lines of Production Banking JavaScript to TypeScript with Zero Downtime

Статья про миграцию 160к строк кода с JS на TypeScript. Статья достаточно поверхностная и моментами странная.

Есть компания, это стартап про деньги на какой-то там ранней стадии (в оригинале seed-stage startup). Код запускается в двух рамтаймах: лямбды в AWS и GraphQL API в ECS. Т.к. стартап в сфере финансов, то необходимо перейти на TS (чтобы избегать глупых ошибок, которые будут дорого стоит) и сделать это без даунтайма

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

Как проводили миграцию:
- Сделали отдельный бранч в гите, где все файлы переименовали из .js в .ts.
- Словили тысячу уникальных ошибок
- По-немногу вводили корректные типы

Все это продолжалось 6 недель, после чего приступили к 2-3 дневному тестингу на стейдж-окружении. Причем тестировали на реальных кейсах. Т.к. приложение связано с деньгами - то переводили $1 между счетами

Из интересного - сделали поддержку запуска и JS и TS кода в скриптах запуска. Удобно для раскатки и отката


https://benhowdle.im/migrating-js-to-ts-zero-downtime.html

#development #javascript #typescript #migration

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



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

Что мне понравилось:
Разобрали реально много моделей

---

Например, Модель Менеджмента по Адизесу. Модель предполагает что есть 4 основных стиля управления:
- P - Producer (производитель)
- A - Администратор
- E - Entepreneur (предприниматель)
- I - Интегратор

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

---

Модель DISC - выделяет 4 ключевых психотипа личности, на основе того, как люди реагируют на события. В целом, недалеко ушло от 4 типов людей у Пифагора.

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

---

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


---

Модель Такмана - каждая команда проходит через 4 стадии:
- Формирование - все только начали работать вместе
- Шторминг - первые трения и конфликты, эффективность снижается, возможен роспуск команды
- Нормализация - группа пережила шторминг и выходит на производительность
- Эффективная команда

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

---

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

Кроме моделей рассматривали, как провести анализ организации и на чем следует фокусироваться:
- Цели
- Стратегия
- Процессы
- Команды
- Сотрудники
- Ожидания
- Смежные команды
- И многое другое

Тоже было весьма полезно. О чем-то уже знал, о чем-то не задумывался. Информацию дали структурировано.

Единственный минус обучения - большой фокус на командную работу в группах. Благо обучение идет среди IT-менеджеров т.е. все в одном контексте + у всех есть минимальные софт-скиллы. Но я такой формат не особо люблю - спонтанная 20-минутная групповая активность не заменяет нормальное обучение.

Короткий итог:
- Было реально полезно. Но в целом пошли по верхам
- Большой упор на работах в группах и вопросах
- Интересное коммьюнити. Получил немного новых знаний и примеров, общаясь в чате группы.


---

Если вас зацепил пост, то скоро (с 17 по 28 марта) Стратоплан будет проводить Антимарафон «Вредные привычки, мешающие вашей карьере». Название странное, но это 10 лекций скорее про хорошие привычки. Судя по описанию поговорят про обратную связь, про лидерство, про планирование работ. Среди спикеров есть крутые чуваки, которые всегда несут пользу в своих публичных выступлениях. Я их читаю и могу рекомендовать вам: Дима Болдырев, Роман Ивлев

Рекомендую записаться - обучение всегда полезно, а если вдруг не понравится - выйдете, бесплатновое же :)





#note #stratoplan

Запускаем Pong в 240 вкладках браузера

Вы видели челлендж "сделай игру, помещающуюся в 13кб", вы видели реализацию DOOM на всем чем можно. Но видели ли вы реализацию игры ping pong на фавиконках вкладок? Вот, можете посмотреть по ссылке

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

Если совсем коротко описывать решение то оно следующее:
- Отрываются 8 окон по 30 вкладок с помощью AppleScript
- Есть мастер-вкладка, есть вкладки-воркеры
- Коммуникация между вкладками построена на BroadcastChannel
- Мастер вкладка запускает игру когда дождалась загрузки всех вкладок-воркеров
- Затем мастер-вкладка отправляет воркерам, как им следует обновить фавиконку
- Рассчет того, какой вкладке нобходимо обновить фавиконку идет на основе хардкода размеров окон, фавиконок и всех отступов в Google Chrome




https://habr.com/ru/articles/884564/

#development #javascript #pingPong

import-in-the-middle

import-in-the-middle - библиотека для патчинга экспортов ESM-библиотек. Достаточно интересная штука, которая должна использоваться с умом. Для работы библиотеки необходимо регистрировать её как загрузчик в node.js

node --loader=import-in-the-middle/hook.mjs my-app.mjs



Пример
import { Hook } from 'import-in-the-middle'
import { foo } from 'package-i-want-to-modify'

console.log(foo) // whatever that module exported

Hook(['package-i-want-to-modify'], (exported, name, baseDir) => {
// `exported` is effectively `import * as exported from ${url}`
exported.foo += 1
})

console.log(foo) // 1 more than whatever that module exported


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

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

https://github.com/nodejs/import-in-the-middle

#development #javascript #library #esmodules

TypeScript: the satisfies operator

Большой пост про satisfies оператор в TypeScript. Объясняется что такое satisfies оператор и какие основные юзкейсы у него есть

satisfies проверяет, что значение соответствует какому-то типу, не меняя тип значения.

Чтобы понять разницу между satisfies и as достаточно взглянуть на 1 пример, где as сделает тайпкаст, а satisfies укажет на ошибку

type Point = { x: number, y: number };
const point5 = { x: 2 } as const as Point; // OK
const point6 = { x: 2 } as const satisfies Point; // ERROR


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

Например, у вас есть конфиг для стилей
type TTextStyle = {
html: string,
latex: string,
};

const TextStyle = {
Bold: {
html: 'b',
latex: 'textbf',
},
}


Если вы используете начнете описывать тип переменной TextStyle, то вы можете столкнуться с тем, что случайно сделаете тип более широким

type TTextStyle = {
html: string,
latex: string,
};

const TextStyle: Record = {
Bold: {
html: 'b',
latex: 'textbf',
},
}
TextStyle.KEK // OK


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

Оператор satisfies тут как нельзя кстати
type TTextStyle = {
html: string,
latex: string,
};

const TextStyle = {
Bold: {
html: 'b',
latex: 'textbf',
},
} satisfies Record
TextStyle.KEK // ERROR


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

Однако, есть прикольные моменты, которые обозначу в посте. Хотя satisfies обычно не меняет тип проверяемой переменной, есть исключения.

Например, satisfies может уточнить тип
type Robin = {
name: 'Robin',
};

const robin1 = { name: 'Robin' };
// robin1.name имеет тип string
const robin2 = { name: 'Robin' } satisfies Robin;
// robin2.name имеет тип 'Robin'


https://2ality.com/2025/02/satisfies-operator.html

#development #typescript #satisfies

Встреча потенциальных докладчиков с программным комитетом FrontendConf 2025

13 марта в 19:00 пройдет встреча с потенциальными докладчиками, на которой мы обсудим:
- на какие темы мы хотим говорить на конференции в этом году,
- как проходят отбор заявок,
- как готовить доклад с Программным комитетом.

Приходите! Я уже восьмой год подряд провожу эту встречу (как же быстро растут чужие дети), расскажу, какой видим программу, и обсудим ваши идеи докладов.

Регистрация: https://conf.ontico.ru/event/join/open_fc2025-online.html

Подробнее про программу и форма подачи докладов: https://cfp.frontendconf.ru

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

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

Introducing RushDB: Zero-Config Instant Database for Modern Apps & AI Era
Ссылка от подписчика про разрабатываемый им продукт - RushDB. RushDB - это база данных, которая легко развернуть и начать использовать. Основная фишка - это то что БД забирает на себя организацию данных - нормализацию, лейблинг, организацию связей между сущностями. И это очень подходит для AI-решений - вы закидываете данные, БД сама все структурирует, а структуру и связи уже может использовать AI

Также все сделано для того, чтобы работа с БД была простой: есть SDK на typescript и pythin, можно селф-хостить, можно хостить в клауде, есть гарантии транзакций, возможность работать ничего не настраивая.

The TypeScript Agent Framework
Mastra - фреймворк на Typescript для создания ИИ-агентов. Выглядит достаточно хорошо - поддерживает много разного: кастомные тулы, воркфлоу (и контроль их исполнения), RAG, память.

Тут еще не было постов про ИИ-агентов, поэтому небольшая вводная. LLM сами по себе могут лишь предсказывать, какой текст должен следовать за предыдущим. Это достаточно прикольный инструмент, но чтобы что-то сделать нужно а) дать им какие-то данные; б) вести с ними диалог в каком-то фреймворке (дать данные, попросить проанализировать, дать дополнительные данные, снова что-то попросить). ИИ-агенты как раз позволяют закрыть полный флоу работы с LLM - добавляются инструменты (tools), которые позволяют достать какие-то данные, и добавляются воркфлоу или сценарии, которые ведут LLM.

Deno 2.2: OpenTelemetry, Lint Plugins, node:sqlite
Вышел Deno 2.2. Заехали прикольные фичи: поддержка из коробки sqlite и OpenTelemtry, улучшения линтера, поддержка QUIC (http3), улучшение совместимости с Nodejs API, а также различные работы по перформансу.

Я бы хотел отдельно выделить поддержку Open Telemetry в Deno. Open Telemetry - это крайне важна штука, для обеспечения observability ваших систем. Open Telemetry - это набор соглашений о том, как следует логировать операции в IT-системах. Обычно OT встраивается в фреймворки, либо вы сами подключаете ОТ и инструментируете свой код. Deno же сам инструментирует основные методы (console.log, fetch, Deno.serve), а все что надо инструментировать сверх - остается на вас.

Bundling Dependencies
Статья разбирает, стоит или не стоит бандлить зависимости в свои библиотеки.

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

ESLint now officially supports linting of CSS
Eslint продолжает развиваться. Теперь он умеет линтить CSS, используя парсер CSSTree. Сделали хорошее базовое решение: пока есть малое количество встроенных правил, но при этом есть удобное АПИ для создания кастомных правил + есть АПИ для расширения синтаксиса CSS (например, есть готовый пресет для расширения синтаксиса для tailwind)



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

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

ESLint now officially supports linting of CSS

Eslint продолжает развиваться. Теперь он умеет линтить CSS, используя парсер CSSTree. Сделали хорошее базовое решение: пока есть малое количество встроенных правил, но при этом есть удобное АПИ для создания кастомных правил + есть АПИ для расширения синтаксиса CSS (например, есть готовый пресет для расширения синтаксиса для tailwind)

import css from "@eslint/css";

export default [
{
files: ["**/*.css"],
plugins: {
css,
},
language: "css/css",
rules: {
"css/no-empty-blocks": "error",
},
},
];


https://eslint.org/blog/2025/02/eslint-css-support/

#development #javascript #eslint #css

Bundling Dependencies

Статья разбирает, стоит или не стоит бандлить зависимости в свои библиотеки.

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

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

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

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

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

https://e18e.dev/blog/bundling-dependencies.html

#development #javascript #bundle

Deno 2.2: OpenTelemetry, Lint Plugins, node:sqlite

Вышел Deno 2.2. Заехали прикольные фичи: поддержка из коробки sqlite и OpenTelemtry, улучшения линтера, поддержка QUIC (http3), улучшение совместимости с Nodejs API, а также различные работы по перформансу.

Я бы хотел отдельно выделить поддержку Open Telemetry в Deno. Open Telemetry - это крайне важна штука, для обеспечения observability ваших систем. Open Telemetry - это набор соглашений о том, как следует логировать операции в IT-системах. Обычно OT встраивается в фреймворки, либо вы сами подключаете ОТ и инструментируете свой код. Deno же сам инструментирует основные методы (console.log, fetch, Deno.serve), а все что надо инструментировать сверх - остается на вас.

Также в Deno встроен Open Telemetry Exporter - вам достаточно запустить Deno с режимом OT и указать ендпоинт экспорта OT вашего Deno-приложения и телеметрия польется в вашу целевую систему, где вы можете отслеживать все действия юзера.



https://deno.com/blog/v2.2

#development #javascript #deno #releaseNotes

The TypeScript Agent Framework

Mastra - фреймворк на Typescript для создания ИИ-агентов. Выглядит достаточно хорошо - поддерживает много разного: кастомные тулы, воркфлоу (и контроль их исполнения), RAG, память.

Тут еще не было постов про ИИ-агентов, поэтому небольшая вводная. LLM сами по себе могут лишь предсказывать, какой текст должен следовать за предыдущим. Это достаточно прикольный инструмент, но чтобы что-то сделать нужно а) дать им какие-то данные; б) вести с ними диалог в каком-то фреймворке (дать данные, попросить проанализировать, дать дополнительные данные, снова что-то попросить). ИИ-агенты как раз позволяют закрыть полный флоу работы с LLM - добавляются инструменты (tools), которые позволяют достать какие-то данные, и добавляются воркфлоу или сценарии, которые ведут LLM.

Например, вы хотите сделать код ревью своего МР-а. Как это делается с LLM - создается чат, дается контекст, кидается много файлов и на каждый просится фидбек. Как это делается с ИИ-агентом - вы строите агента, который умеет ходить в апи gitlab или github (и другие апи) для получения данных, в агенте настраиваете воркфлоу как делаются код-ревью. А дальше заходите в чат с ИИ-агентом и говорите "сделай код ревью моего последнего МР-а", а дальше ИИ-агент сам пройдется по всем инструментам и сценариям и сделает для вас код ревью

Возвращаемся к статье. Mastra - фреймворк для описания ИИ-агентов. Я прямо сейчас играюсь с LangChain.js для создания агента, но, видимо, попробую теперь и Mastra.

https://mastra.ai

#development #javascript #ai #aiAgents

Introducing RushDB: Zero-Config Instant Database for Modern Apps & AI Era

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

Также все сделано для того, чтобы работа с БД была простой: есть SDK на typescript и python, можно селф-хостить, можно хостить в клауде, есть гарантии транзакций, возможность работать ничего не настраивая.

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

https://rushdb.com/blog/rushdb-the-zero-config-database-for-modern-apps-and-ai-solutions

#development #javascript #database #ai

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

Style-observer: JS to observe CSS property changes, for reals
В вебе относительно давно есть разные Observer'ы, с некоторыми из которых, кажется, столкнулся каждый - Mutation Observer и Intersection Observer. Но чего нам не хватает - это Style Observer. Статья от Lea verou про то, как сообщество решало задачу "реагировать на изменения в стилях" и как Lea Verou и другие неравнодушные люди сделали Style Observer

Первые решения этой задачи появились еще в 2018 году и было реализованы на полинге - JS код периодически запрашивал стили и реагировал на их изменения. Затем были сделаны решения, которые работали на основе селекторов и transitionstart. Затем в какой-то момент появился transition-behavior: allow-discrete, который позволяет делать более общие решения. На его основе и построен style-observer

Move on to ESM-only
Пора перестать делать пакеты с поддержкой CJS и работать только в ESM. Автор статьи 3 года назад писал гайд, как делать пакет с поддержкой ESM & CJS, но теперь считает, что сообщество и тулинг за эти 3 года ушли далеко вперед и от поддержки CJS можно отказываться.

Изначально весь движ к ESM-only пакетам делался снизу-вверх - некоторые библиотеки (типа execa) переехали на ESM-only и, таким образом, заставляли двигаться всю экосистему. Это достаточно крутой мув, но, по мнению автора, он оказался менее эффективен, чем поддержка ESM у тулинга и фреймворков.

The Popover API is now Baseline Newly available
Popover - это база. Теперь официально. Popover - это стандартизированное API для реализации всплывающих окон в браузере. Вообще Popover реализовали в Firefox еще в апреле 2024 года, но реализация оказалась проблемной для iOS и iPadOS - нельзя было закрыть Popover без уважения кликнув по свободному месту. Поэтому пришлось ждать свежего релиза сафари, чтобы сказать, что Popover - это база

Что это значит для нас: можно считать что Popover прекрасно работает с января 2025. Когда значительная часть пользователей перейдёт на браузеры с версией выше, чем выпущенные в январе 2025 года, можно будет использовать Popover по полной.

How to refactor code with GitHub Copilot
Github развивают свой Copilot и выпускают хорошие статьи по работе с ним. В данном статье рассказывается, как Copilot может помочь в рефакторинге.

Статья делится на несколько частей: что такое рефакоринг => как его начать => как сделать мелкий рефакторинг => как набросать план рефакторинга

We Replaced Our React Frontend with Go and WebAssembly
Чуваки из Dagger переписали React на Go. Внимание, не повторять в домашних условиях. Команда Dagger столкнулась со сложностью - у них был интерфейс в вебе и интерфейс в терминале и необходимо было все UI-фичи дублировать в двух разных кодовых базах (собственно React и Go). Решение простое: переписать один из двух UI на typescript Go.

Выбор достаточно храбный, но обоснованный. Команда имеет широкую экспертизу в Go и слабую в web-e, поэтому принято решение попробовать переехать полностью на Go. Статья рассказывает о проблемах, с которыми столкнулась команда и что из этого вышло.

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

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

We Replaced Our React Frontend with Go and WebAssembly

Чуваки из Dagger переписали React на Go. Внимание, не повторять в домашних условиях. Команда Dagger столкнулась со сложностью - у них был интерфейс в вебе и интерфейс в терминале и необходимо было все UI-фичи дублировать в двух разных кодовых базах (собственно React и Go). Решение простое: переписать один из двух UI на ~~typescript~~ Go.

Выбор достаточно храбный, но обоснованный. Команда имеет широкую экспертизу в Go и слабую в web-e, поэтому принято решение попробовать переехать полностью на Go. Статья рассказывает о проблемах, с которыми столкнулась команда и что из этого вышло.

Ребята взяли Go-App - это тулинг для написания PWA-приложиков на go, с применением WASM.

Какие нюансы вскрылись при написании Go приложения для веба:
- Нужно было очень аккуратно оптимизировать потребление памяти. В проекте есть кейсы, когда требуется отрисовывать более 200 тысяч строчек логов, что может привести к развалу приложения.
- Go WASM оказался неповоротливым в обработке огромных объемов JSON, из-за чего пришлось менять архитектуру решения.
- WASM файл получился большим - 32 МБ. Даже после сжатия brotli он остается 4.6 МБ
- Думали, что будет сложно писать UI-компоненты, но оказалось что это не так
- Научились использовать npm библиотеки из Go-кода
- По сравнению с React, прямая работа с UI позволяет лучше оптимизировать код. Можно сделать много разных решений, замерить и выбрать лучшее.
- Дебаг средствами Go - удобен
- За бесплатно получили PWA приложение (в целом, могли и раньше воткнуть конечно)

Следует ли вам проделывать такое? Скорее всего нет. У Dagger специфичный юзкейс:
- Делают непростой UI. Далеко не каждому продукту нужно выводить сотни тысяч элементов на странице
- Команда из сильных go-разработчиков
- Требование синхронизации двух интерфейсов

Я же отмечу, что Go-разработчики не перестают меня удивлять путями, которые они выбирают. Кейс же очень интересный.

https://dagger.io/blog/replaced-react-with-go

#development #javascript #golang #wasm

How to refactor code with GitHub Copilot

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

Статья делится на несколько частей: что такое рефакоринг => как его начать => как сделать мелкий рефакторинг => как набросать план рефакторинга

Рефакторинг - изменение кода без изменения поведения. По сути, изменение структуры кода. Самые популярные примеры: упрощение условий, вынесение общей логики, декомпозиция функций

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

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

- How would you improve this?
- Improve the variable names in this function.
- #file:pageInit.js, #file:socketConnector.js Offer suggestions to simplify this code.

Но как стартовая точка - сойдет. Вместе с Copilot можно идти в более сложные рефакторинги, когда вы накидываете контекст, а Copilot предагает решения.

Все кто использовали Copilot и ChatGPT уже, скорее всего, пробовали подход "сделай красиво". Однако команда Copilot рекомендует идти дальше и составлять план рефакторинга вместе с Copilot. Эта фича есть в Copilot Workspace и она выглядит достаточно неплохо. В чем суть: вместо того, чтобы просить Copilot сделать код красивее, можно скормить ему контекст (что делаем, зачем, какие цели, какие файлы) и попросить составить план рефакторинга. Этот план можно затем полировать вместе с Copilot, а затем уже проводить рефакторинг по плану. В целом, похоже на обычный здоровый процесс рефакторинга - перед тем как делать что-то сложное, лучше обсудить с коллегой план.

Также в статье приводится реальный кейс рефакторинга вместе с Copilot из команды Github

https://github.blog/ai-and-ml/github-copilot/how-to-refactor-code-with-github-copilot/

#development #javascript #ai #copilot #refactor #github

The Popover API is now Baseline Newly available

Popover - это база. Теперь официально. Popover - это стандартизированное API для реализации всплывающих окон в браузере. Вообще Popover реализовали в Firefox еще в апреле 2024 года, но реализация оказалась проблемной для iOS и iPadOS - нельзя было закрыть Popover ~~без уважения~~ кликнув по свободному месту. Поэтому пришлось ждать свежего релиза сафари, чтобы сказать, что Popover - это база

Что это значит для нас: можно считать что Popover прекрасно работает с января 2025. Когда значительная часть пользователей перейдёт на браузеры с версией выше, чем выпущенные в январе 2025 года, можно будет использовать Popover по полной.

https://web.dev/blog/popover-baseline

#development #javascript #popover

Move on to ESM-only

Пора перестать делать пакеты с поддержкой CJS и работать только в ESM. Автор статьи 3 года назад писал гайд, как делать пакет с поддержкой ESM & CJS, но теперь считает, что сообщество и тулинг за эти 3 года ушли далеко вперед и от поддержки CJS можно отказываться.

Изначально весь движ к ESM-only пакетам делался снизу-вверх - некоторые библиотеки (типа execa) переехали на ESM-only и, таким образом, заставляли двигаться всю экосистему. Это достаточно крутой мув, но, по мнению автора, он оказался менее эффективен, чем поддержка ESM у тулинга и фреймворков.

Почему стоит переезжать на ESM-only и не стоит оставаться на CJS & ESM?
- Не смотря на то, что Nodejs позволяет импортировать CJS в ESM, экспорты CJS сделаны по-другому, из-за его возникает необходимость делать двойную работу. Автор не погружается глубоко в проблематику, но указывает, например, на необходимость генерировать 2 файла с типами
- Зависимости, которые поставляются как ESM и как CJS в код приложения, могут конфликтовать друг с другом. Также это большая проблема для пакетов-синглотонов
- Размер пакетов, которые поддерживают CJS & ESM, увеличиваются (т.к. им нужно держать 2 версии кода)

Где следует уже использовать ESM-only^
- Новые пакеты
- Пакеты, которые должны работать в браузере
- CLI
- Node.js пакеты, таргетирующиеся на новые версии ноды


https://antfu.me/posts/move-on-to-esm-only

#development #javascript #esmodules

Style-observer: JS to observe CSS property changes, for reals

В вебе относительно давно есть разные Observer'ы, с некоторыми из которых, кажется, столкнулся каждый - Mutation Observer и Intersection Observer. Но чего нам не хватает - это Style Observer. Статья от Lea verou про то, как сообщество решало задачу "реагировать на изменения в стилях" и как Lea Verou и другие неравнодушные люди сделали Style Observer

Первые решения этой задачи появились еще в 2018 году и было реализованы на полинге - JS код периодически запрашивал стили и реагировал на их изменения. Затем были сделаны решения, которые работали на основе селекторов и transitionstart. Затем в какой-то момент появился transition-behavior: allow-discrete, который позволяет делать более общие решения. На его основе и построен style-observer

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

https://lea.verou.me/blog/2025/style-observer/
https://observe.style

#development #css #leaVerou

Дайджест за 2025-02-17 - 2025-02-21

Обзор на книгу "Чистый дизайн. Практика эмпирического проектирования ПО" от Кента Бек
Кент Бек - автор XP и TDD, один из создателей Agile Manifesto, снова ворвался в публицистику и выпустил новую короткую книгу. Книга короткая и, по ощущениям, состоит из кучи собранных вместе блог-постов.

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

Introducing Fusion - write PHP inside Vue and React components
Мы достигли технологической сингулярности: теперь можно писать php внутри vue или react внутри php! Чел из сообщества Laravel (фреймворк для php) сделал инструмент, который позволяет в Laravel писать vue и react файлы, внутри которых будет использоваться php.

Это не просто рендер vue-шаблонов с использованием php, это и вызов php-методов из браузерного кода, и синхронизация стейта на вебе и на беке. ИМХО, неплохая тема, особенно веб-для разработчиков на проекте с laravel.

Tutorial: publishing ESM-based npm packages with TypeScript
Туториал по публикации ESM-пакетов с поддержкой TS, которые работают и в браузере и в ноде. Туториал разбирает все - от структуры файлов и конфигов, до настройки тулов. Есть, конечно, небольшой минус - гайд немного предвзят по некоторым моментам

Основной полезный контент - это настройка ESM-модулей, которая делается теперь проще, благодаря поддержке ESM различным тулингом, через объявление поля exports в package.json, вместо описания 4-х разных полей ранее.

Read-only accessibility in TypeScript
Пост, разбирающий все аспекты создания readonly свойств и объектов в TS: от свойств объекта, до readonly Set и Map.

Я знал про readonly (и даже иногда использовал), но я не знал что в TS есть Readonly вариации массива, tuple, Set и Map. В статье показывается как они работают и какие есть особенности их работы.

Beej's Guide to Git
Огромный гайд по git'у. Кажется в этом гайде покрыто вообще все, при этом все описано достаточно компактно и разобраны основные кейсы работы с git'ом, которые нужные разработчику.

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

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

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

Beej's Guide to Git

Огромный гайд по git'у. Кажется в этом гайде покрыто вообще все, при этом все описано достаточно компактно и разобраны основные кейсы работы с git'ом, которые нужные разработчику.

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

https://beej.us/guide/bggit/html/split/

#development #git #tutorial

Read-only accessibility in TypeScript

Пост, разбирающий все аспекты создания readonly свойств и объектов в TS: от свойств объекта, до readonly Set и Map.

Я знал про readonly (и даже иногда использовал), но я не знал что в TS есть Readonly вариации массива, tuple, Set и Map. В статье показывается как они работают и какие есть особенности их работы.

Для меня самым шоком оказалось, что объект Readonly объект можно кинуть аргументом в функцию, которая принимает не Readonly объект, а значит может его поменять. При этом для массива, Set и других Readonly типов все работает корректно - я не могу кинуть Readonly версию типа в функцию, которая ожидает не-readonly версию.

https://2ality.com/2025/02/typescript-readonly.html

#development #typescript #readonly

Tutorial: publishing ESM-based npm packages with TypeScript

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

Основной полезный контент - это настройка ESM-модулей, которая делается теперь проще, благодаря поддержке ESM различным тулингом, через объявление поля exports в package.json, вместо описания 4-х разных полей ранее.

Настройка экспорта зависит от ответов на несколько вопросов:
- Собираемся ли мы экспортировать все через под-директории (import someThing from "package-name/sub/index") или из рута (import someThing from "package-name")
- Собираемся ли мы указывать расширение для файлов для экспортов под-директорий?

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

Автор туториала не говорит о том, как лучше, но для себя он вывел следующие правила:
- Большинство его пакетов не имеют под-дпиректорий
- Если пакет - это коллекция модулей, то они экспортируются с расширением
- Если пакет - это вариация нескольких версий пакета (синхронное и асинхронное АПИ например), то они экспортируются без расширения


// Bare export
".": "./dist/src/main.js",

// Subpaths with extensions
"./util/errors.js": "./dist/src/util/errors.js", // single file
"./util/*": "./dist/src/util/*", // subtree

// Extensionless subpaths
"./util/errors": "./dist/src/util/errors.js", // single file
"./util/*": "./dist/src/util/*.js", // subtree


Также в статье настраивается:
- mocha
- tsc
- typedoc
- publint
- knip
- madge
- и куча других тулов

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

https://2ality.com/2025/02/typescript-esm-packages.html

#development #typescript #npm

Introducing Fusion - write PHP inside Vue and React components

Мы достигли технологической сингулярности: теперь можно писать php внутри vue или react внутри php! Создатель Laravel (фреймворк для php) сделал инструмент, который позволяет в Laravel писать vue и react файлы, внутри которых будет использоваться php.

Это не просто рендер vue-шаблонов с использованием php, это и вызов php-методов из браузерного кода, и синхронизация стейта на вебе и на беке. ИМХО, неплохая тема, особенно веб-для разработчиков на проекте с laravel.

Сниппет кода на странице с примером включает только отображение:


$user = prop(Auth::user()->email);





https://laravel-news.com/introducing-fusion

#development #javascript #php #vue

Обзор на книгу "Чистый дизайн. Практика эмпирического проектирования ПО" от Кента Бек

Кент Бек - автор XP и TDD, один из создателей Agile Manifesto, снова ворвался в публицистику и выпустил новую короткую книгу. Книга короткая и, по ощущениям, состоит из кучи собранных вместе блог-постов.

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

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

Вторая часть и третья части уже намного интереснее.

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

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

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

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

Простое (на мой взгляд) определение связности и зацепления из книги:
> Отдельный фрагмент кода понять легче, если он представляет единое целое и имеет единый смысл ... Это связность. Кроме того, понять происходящее в контексте отношений с другими частями кода проще, если эти отношения немногочисленны, относительно слабы или сильно ограничены. Это сцепление. Сцепление и связность ... означают ... то, как ваш мозг воспринимает сложные системы.

Книга очень короткая. Я прочел буквально за 3 вечера. Сам формат мне понравился - вместо того, чтобы читать талмуд на 400+ страниц про все подряд, есть супер короткая книга, которая покрывает небольшую тему, раскрывает её с разных сторон (хотя в этой книге некоторые идеи раскрыты не очень глубоко), и эту тему можно впитать в себя буквально за рабочую неделю.

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



#note #book

Дайджест за 2025-02-10 - 2025-02-14

Docxtemplater
Docxtemplater - библиотека на JS, которая позволяет генерировать docx, pptx, xlsx документы на основе шаблонов.

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

The modern way to write JavaScript servers
Достаточно интересная статья, которая показывает возможности для упрощения в кодовой базе и в DX при прямом использовании Request и Response вместо node:http

node:http - механизм для поднятия веб-сервера на ноде и он достаточно хорошо работает. Многие фреймворки очень сильно завязаны на node:http не только на уровне, где должна быть связь с сетью, но и внутри бизнес-логики. Вместо этого автор предлагает использовать стандартизированные в Web Request и Response

Standard Schema - A common interface for TypeScript validation libraries
Внезапно (для меня по крайней мере), но авторы популярных пакетов для валидаций собрались и стандартизировали схемы для валидации данных в TS. На сайте описывается состав спеки и библиотеки и фреймворки, которые уже её поддерживают.

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

Миграция на строгий TypeScript: наш путь и собственное решение
Статья от Selectel про миграцию на строгий TS. Проблема, рассматриваемая в статье, стара как строгий режим TS: проект писался изначально не на TS, решено было его перевозить на TS на нестрогий режим т.к. ни у кого нет столько времени, чтобы переписать весь проект на строгие типы

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

Обзор на книгу "Рискуя собственной шкурой" от Насима Талеба
Насим Талеб - человек, давший миру очень популярные книги "Черный лебедь" и "Антихрупкость". Я их не читал, но мне рекомендовали прочесть "Рискуя собственной шкруой", что я и проделал на новогодних каникулах.

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

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

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

Обзор на книгу "Рискуя собственной шкурой" от Насима Талеба

Насим Талеб - человек, давший миру очень популярные книги "Черный лебедь" и "Антихрупкость". Я их не читал, но мне рекомендовали прочесть "Рискуя собственной шкруой", что я и проделал на новогодних каникулах.

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

Есть несколько основных идей в книге
- Для взвешенных решений необходимо "ставить шкуру на кон", т.е. рисковать чем-то. Тот, кто не рискует, не может принимать хороших решений.
- Диктатура меньшинства. Если есть какое-то непримиримое меньшинство (3-4% от общества), которое равномерно распределено по обществу, которое хочет протолкнуть какое-то решение, а большинство готово подстроится - то решение меньшинства будет принято
- Эффект Линди: Чем дольше что-то существует, тем дольше оно будет существовать дальше.

Это общие идеи, которые можно применить к очень многим аспектам жизни общества.

Например, можно рассмотреть эти идеи с точки зрения нашей любимой айтишечки

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

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

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

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

Эффект Линди следует следующей логике: если что-то смогло прожить 100 дней, значит оно достаточно живучее, чтобы прожить еще 100 дней. Если что-то прожило 1000 дней, значит оно достаточно живучее, чтобы прожить еще 1000 дней. В общем, можно сказать с большой уверенностью, что React проживет еще 11 лет :)

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

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



#note #book

Миграция на строгий TypeScript: наш путь и собственное решение

Статья от Selectel про миграцию на строгий TS. Проблема, рассматриваемая в статье, стара как строгий режим TS: проект писался изначально не на TS, решено было его перевозить на TS на нестрогий режим т.к. ни у кого нет столько времени, чтобы переписать весь проект на строгие типы

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

Одно из рассматриваемых решений - подключить плагин для TS. В сообществе есть 2 таких решения и оба в selectel не понравились: нужны кастомные настройки tsconfig и встраивание в сборку

Поэтому команда Selectel решила написать ~~свой велосипед~~ свое решение этой проблемы. Так на свет появилась библиотека @selectel/ts-check. Она умеет запускаться из кли и, если я правильно понял, повторяет логику того, как работает проверка в IDE. Также ребята сразу сделали поддержку code quality report в gitlab, поэтому ошибки @selectel/ts-check отображаются сразу в МР.

В статье все описано чуть подробнее, в том числе раскрывается немного деталей работы с TS Language Server.

https://habr.com/ru/companies/selectel/articles/879980/

#development #javascript #typescript #strictMode #habr

Standard Schema - A common interface for TypeScript validation libraries

Внезапно (для меня по крайней мере), но авторы популярных пакетов для валидаций собрались и стандартизировали схемы для валидации данных в TS. На сайте описывается состав спеки и библиотеки и фреймворки, которые уже её поддерживают.

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

https://standardschema.dev

#development #javascript #typescript #schema

The modern way to write JavaScript servers

Достаточно интересная статья, которая показывает возможности для упрощения в кодовой базе и в DX при прямом использовании Request и Response вместо node:http

node:http - механизм для поднятия веб-сервера на ноде и он достаточно хорошо работает. Многие фреймворки очень сильно завязаны на node:http не только на уровне, где должна быть связь с сетью, но и внутри бизнес-логики. Вместо этого автор предлагает использовать стандартизированные в Web Request и Response

Вы очень часто работаете с Request и Response, ведь это те самые объекты, с которыми работает fetch. Поэтому вместо завязок на фреймворки или node:http, можно было бы завязываться на эти самые объекты и описывать свои обработчики запросов примерно так

type MyApp = (req: Request) => Promise;


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

Есть правда один нюанс: в самой nodejs пока так нельзя. Но можно рассчитывать на скорую поддержку.

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

https://marvinh.dev/blog/modern-way-to-write-javascript-servers/

#development #javascript #node

Docxtemplater

Docxtemplater - библиотека на JS, которая позволяет генерировать docx, pptx, xlsx документы на основе шаблонов.

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

https://docxtemplater.com

#development #javascript #docx #library

Дайджест за 2025-02-03 - 2025-02-06

Bun 1.2
Вышел огромный апдейт Bun 1.2. Release Notes просто огромные. Если совсем коротко, то продолжается работа по совместимости с Node.js, добавлены встроенные клиенты для s3 и Postgres, добавлен lock-файл. Также expressjs, запущенный в Bun, теперь в 3 раза быстрее, чем запущенный Node.js.

Релиз реально огромный, пройдусь лишь по самым интересным вещам. При прочтении следует помнить, что бенчмарки от Bun могут быть не совсем честными, поэтому, если вдруг решите попробовать переехать на Bun, делайте собственные бенчмарки.

Type Predicate Generator
Подписчик канала принес ссылку на свое творение - генератор предикатов для типов. В чем суть: в typescript есть возможность писать рантайм функции, которые уточняют тип. Но писать их руками не всегда прикольно.

Например, функция, уточняющая тип до boolean - function foo(v: unknown): v is boolean { return typeof v === 'boolean' }. Выглядит просто, однако, для составных объектов уже так не получится

Refactoring with Codemods to Automate API Changes: часть 3 - Codemods в других языках
Предыдущие части (обзор в канале 1 и 2) показывали примеры на JS. Однако такие инструменты есть и на других языках.

Эта часть статьи фокусируется на обзоре других инструментов.

Hypermod
Hypermod - инструментарий для кодмодов. Пока еще в бете. Я его упоминал в предыдущем посте и мне он показался интересным

Что представляет собой этот инструментарий:

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

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

Hypermod

Hypermod - инструментарий для кодмодов. Пока еще в бете. Я его упоминал в предыдущем посте и мне он показался интересным

Что представляет собой этот инструментарий:
- Удобный плейграунд для разработки и дебага кодмодов
- Предоставляется экспирименс разработки Codemod'а как разработки проекта: каждый CodeMod - отдельный проект, к которому можно писать доку, писать тесты, проверять его в плейграунде, делиться с коллегами или сообществом.
- AI для работы с кодмодами. Прикольно что ребята сделали кастомный GPT в openai чате с ChatGPT.

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

https://www.hypermod.io

#development #javascript #typescript #codemod #refactoring

Refactoring with Codemods to Automate API Changes: часть 3 - Codemods в других языках

Предыдущие части (обзор в канале 1 и 2) показывали примеры на JS. Однако такие инструменты есть и на других языках.

Эта часть статьи фокусируется на обзоре других инструментов.

Например JavaParser для Java работает на основе по паттерна Visitor и там доступны все те же техники, что и для jscodeshift

Также есть инструменты типа OpenRewrite, которые работают не просто с AST, а с LST - Lossless Semantic Trees. Это деревья, в которых отображается не только синтаксис, но и семантика. К сожалению, конкретных примеров использования LST в статье нет.

Hypermod - AI инструмент для генерации кодмода на основе текстового запроса.

Codemod.com - платформа сообщества и продукт. На платформе можно делиться своими кодмодами и брать чужие. Но также предлагается CLI и IDE, которые позволяют удобно работать с кодмодами и генерировать их с помощью AI.

https://martinfowler.com/articles/codemods-api-refactoring.html#CodemodsInOtherLanguages

#development #martinFowler #codemod #hypermod #refactoring

🎉 Результаты розыгрыша:

Победитель:
1. Маша 🌿 (@m_hodeneva)

Проверить результаты

Type Predicate Generator

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

Например, функция, уточняющая тип до boolean - function foo(v: unknown): v is boolean { return typeof v === 'boolean' }. Выглядит просто, однако, для составных объектов уже так не получится

// example.ts
export type User = {
id: number;
login: string;
email?: string;
address: {
street: string;
house: number;
};
};


Писать руками проверки на то, что какая-то переменная является типом User - бесчеловечно (озвучивать голосом Графа Лимонохвата из Adventure Times). Для этого есть разные решения, например: библиотеки для валидации или плагины для TSC.

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

Давайте разберем на примере
Для достаточно простого типа
export type User = {
id: number;
login: string;
};


Я бы написал руками что-нибудь такое:
export function isUser(arg: unknown): arg is User {
// Проверяю на объект
if (typeof arg !== 'object') {
return false;
}
// Не все объекты - объекты, выкидываем null
if (arg == null) {
return false;
}
// проверяем поля
if (typeof arg.id !== 'number') {
return false;
}
if (typeof arg.login !== 'string') {
return false;
}
return true;
}


Генератор же дает такой вывод:
import { type User } from "./example";
// used to safely get all the object attributes as `unknown`s
type SafeShallowShape = {
[_ in keyof Type]?: unknown;
};
export function isUser(root: unknown): root is User {
// check that `root` is an object
if (!(typeof root === "object" && root !== null)) {
return false;
}
(root) satisfies {};
// safely get all the attributes from `root` as `unknown`s
const { id, login }: SafeShallowShape = root;
// check that `root.id` is of primitive type `number`
if (!(typeof id === "number")) {
return false;
}
// check that `root.login` is of primitive type `string`
if (!(typeof login === "string")) {
return false;
}
/*
In TypeScript the `never` type is assignable to any other type,
effectively turning it into an unsafe `any` type at assignment.
The following checks ensure that none of the checked values got
narrowed down to `never`.
*/
// @ts-expect-error: should not be `never`
(isUser) satisfies never;
// @ts-expect-error: should not be `never`
(root) satisfies never;
// @ts-expect-error: should not be `never`
(id) satisfies never;
// @ts-expect-error: should not be `never`
(login) satisfies never;
/*
Verify that all the predicates above narrowed all the types
down to the root type that is being checked by the predicate.
This is the key check that makes the whole type predicate safe.
*/
({
id,
login
}) satisfies User;
return true;
}


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

Также можно сгенерировать unit-тесты, но тогда контент не влезет в ограничения телеги на длину сообщений :)

Можете поиграться сами в Playgroud'е

Решение интересное, имеет право на существование. Не забудьте поставить звезды автору на гитхабе.

https://github.com/peter-leonov/type-predicate-generator

#development #typescript #library #github #generator

Bun 1.2

Вышел огромный апдейт Bun 1.2. Release Notes просто огромные. Если совсем коротко, то продолжается работа по совместимости с Node.js, добавлены встроенные клиенты для s3 и Postgres, добавлен lock-файл. Также expressjs, запущенный в Bun, теперь в 3 раза быстрее, чем запущенный Node.js.

Релиз реально огромный, пройдусь лишь по самым интересным вещам. При прочтении следует помнить, что бенчмарки от Bun могут быть не совсем честными, поэтому, если вдруг решите попробовать переехать на Bun, делайте собственные бенчмарки.

Bun достиг 90% совместимости с Node.js. Здесь очень интересен способ, которым Bun проверяет свою совместимость - ребята просто берут тесты ноды и запускают их на Bun и смотрят, сколько тестов проходит. Так вот, 90% тестов Node.js проходит на Bun.

Какие новые модули node.js заехали в новый релиз Bun:
- node:http2 - модуль для работы с http2, который работает в 2 раза быстрее чем в ноде
- node:dgram - модуль для общения по UDP
- node:cluser - модуль, для организации работы нескольких инстансов Bun. Нужен, например, для утилизации нескольких ядер ЦПУ.
- node:zlib - был переписан на нативный код, стал быстрее в 2 раза чем в Bun 1.1
- добавили поддержку снятия снапшотов памяти из node:v8. Это самое интересное т.к. Bun работает не на v8, но они сделали модуль, который снимает снапшот памяти и переводит его в формат v8, чтобы они открывался в девтулах хрома.

Как итог всех переписываний и оптимизаций, expressjs в Bun теперь работает в 3 раза быстрее, чем в Node.js

Bun целится быть cloud-first рантаймом, поэтому добавляет соответствующие API. Например, в этом релизе встроили API для работы с s3. Выглядит круто - простое API, работает быстрее чем @aws-sdk/client-s3 в Node.js, при этом нативная поддержка s3 встроена даже в чтение файлов

Ниже примеры использования нового API:
Чтение и запись файла
import { s3 } from "bun";

const file = s3.file("folder/my-file.txt");
// Чтение
const content = await file.text();
// Запись
await file.write("hello s3!");


Самый топ, на мой взгляд, bun понимает s3:// протокол и использует s3 клиент для его обработки
import { file } from "bun";

async function createFile(url, content) {
const fileObject = file(url);
if (await fileObject.exists()) {
return;
}
await fileObject.write(content);
}
await createFile("s3://folder/my-file.txt", "hello s3!");


Также в Bun встроили Postgres-клиент (который быстрее самых популярных postgres-клиентов для Node.js на 50%), а скоро добавят еще и поддержку MySQL

Изменили также и работу с пакетами:
- отказались от бинарного лок-файла в пользу текстового из-за DX. Также ускорили установку пакетов на 30%.
- для package.json и лок-файла используется JSONC - это JSON + комментарии + висящие запятые
- Поддержка .npmrc
- Добавили команду bun patch для исправления зависимостей

Воркфлоу патчинга такой:
- Запустите bun patch
- Отредактируйте файлы в node_modules/package
- Запустите bun patch --commit
- Теперь bun будет применять ваши изменения при установке пакетов проекта

Улучшили инструментарий для тестирования:
- Добавили сбор тестового покрытия
- Добавили инлайн снапшоты
- Добавили test.only()
- Добавили новые матчеры в expect: toContainValue(), toContainKey(), toHaveReturned
- Добавили возможность указывать в expect кастомные сообщения об ошибках

Прокачали сборку:
- Добавили поддержку HTML-импортов
- Добавили возможность "скомпилировать" приложение в исполняемый файл
- Добавили возможность собрать приложение в commonJS
- Добавили инжект переменных окружения во время сборки
- Добавили возможно импортировать css в js
- Самый отвал башки - добавили возможность импортировать C код, компиляцию которого возьмет на себя Bun в рантайме через использование очень быстрого компилятора

Также поддержали много обновлений в JS и WebApi. Укажу ключевые:
- Поддержка import attributes
- Поддержка Promise.withResolvers
- Поддержка оператора using
- Поддержка Iterator helpers


https://bun.sh/blog/bun-v1.2

#development #javascript #bun #releaseNotes

Дайджест за 2025-01-27 - 2025-01-30

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

Напоминаю про розыгрыш билета на Podlodka React Crew

————————————-

Refactoring with Codemods to Automate API Changes: часть 2 - основные ошибки
Обновление в статье про кодмоды - основные проблемы кодмодов. Первая часть обозревается тут

Данная часть статьи продолжает предыдущий пример. В предыдущем примере был описан кодмод, который заменяет использование компонента Avatar на Avatar + Tooltip. Все хорошо в простых кейсах, но что если а) кто-то импортировал Avatar с ренеймом import { Avatar as NotAvatar } б) что если тултип уже импортирован. В этих случаях кодмод или не отработает, или отработает криво, что приведет к проблемам.

Running Inference In Web Extensions
Внезапно в новом релизе firefox будут встроены ML модели. Вы и сейчас можете установить transformerjs и использовать модели с hugging face, но firefox сделал для этого отдельный компонент, который загружает модельки (если я правильно понял), выполняет их в отдельном оптимизированном процессе, самостоятельно хранит их. При этом API компонента браузера близко (или идентично) к API transformerjs. API доступно только в расширениях

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

Avoiding anys with Linting and TypeScript
Any в TypeScript - необходимая концепция, потому что TS создан поверх JS, но которая может сильно испортить опыт разработчика и избыточное использование any может привести к дефектам в проде. Много копий сломано в споре о том, стоит ли вообще использовать any. Лично видел, как люди закапывали многие человеко-часы, лишь бы вычистить any из кода.

Данная статья описывает, как писать меньше any и больше осмысленного кода. Статья проходится по настройкам в tsconfig и eslint - как их следует подключать и как использовать.

Announcing Rspack 1.2
Вышел RSPack 1.2. RSPack это бандлер для веб-проектов, написанный на Rust.

Что интересного - завели persistent cache, который может ускорить сборку на 250%. Это мастхев для больших проектов


Анонс Podlodka React Crew + промокод + розыгрыш билета
Всем привет! Сегодня в канале не статья, сегодня будет реклама анонс онлайн-конфы для React-разработчиков + розыгрыш билета на конфу.

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

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

Розыгрыш билета на Podlodka React Crew (спасибо команде подлодки за этот билет). Подводим итоги розыгрыша во вторник утром.

Также организаторы выделили билет на розыгрыш в канале. Розыгрыш запущу после этого поста, когда разберусь с ботом для этой активности. Правила простые: если вы подписаны на канал и тыкнули "участвовать", вы получаете шанс получить билет. Во вторник подведем итоги.

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

Podlodka React Crew будет проходить в онлайн с 10 по 14 февраля 📅. У них достаточно неплохой набор тем (observability (за 2 темы по обсервабилити отдельный лайк), react19, AI, перформанс, серверные компоненты, профессиональный рост). Формат конфы удобный - каждый день 1 доклад утром, 1 доклад вечером (мое обучение в стратоплане, про которое я писал ранее, будет забирать у меня выходные раз в месяц 😢) - можно спокойно посещать конфу, не отвлекаясь от работы или бытовухи.

Мое ИМХО, но самые крутые доклады в текущей программе - обще-инженерные, а не чисто фронтендерские:
- "Observability Passport: что, где, когда в моем приложении" - поможет вам системно подойти к вашему Obersvability. Многие думают что Observability - это просто куда-то заливать логи или ошибки, но на самом деле, хотя заливка логов важна и она практически является ядром Observability, только лишь заливать логи - мало, надо заливать правильные логи и уметь с ними работать
- "OpenTelemetry для фронтенд-разработчика" - продолжение предыдущей темы. OpenTelemetry - очень мощный инструмент, сквозное внедрение которого значительно улучшает и упрощает разбор инцидентов и анализ логов
- "AI Integrated Developer Experience" - хайповая тема, но анонс хороший. Докладчик фокусируется на том, как держать баланс между "пусть за меня все делает AI" и "блин, какая-то фигня получается, лучше сам все сделаю". По моему опыту у многих людей есть проблема с AI-инструментами, что они впадают в крайность - либо полностью доверяют AI, либо отрицают эти инструменты. Сам я использую AI в работе и сайд-проектах на ежедневной основе (кроме, кстати, ведения этого канала - в постах нет ни одной нейро-строчки текста)
- "Метрики производительности веб-приложений" - перформанс - вечная тема. С одной стороны, уже много всего рассказано и написано, с другой стороны, мы до сих пор видим лагающие сайты в интернете.
- "Монорепы — история про сову и глобус" - доклад, если я правильно понял, про организацию репозиториев - когда следует идти в монорепо, когда полирепо, когда можно не парится и следовать KISS в этом вопросе
- "Мокаем просто с Mock Service Worker" - мокирование - техника, которая может быть очень полезной, если правильно её использовать. Доклад про инструмент MSW и про то, как он помогает не только в тестировании

Имхо, все темы выше - обще-инженерные. Некоторые с небольшим уклоном в веб (веб-перформанс и MSW например), но они все равно спокойно перекладываются на общие подходы.

Я знаю подлодку где-то с 2016-го года, когда это был только подкаст. Мой путь от двери дома до рабочего места занимал примерно 36 минут (не знаю зачем я засекал, но помню до сих пор) и я за неделю мог послушать пару интересных выпусков.

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

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

При этом цены на эти конференции, в отличии от билетов на конференции от онтико и jugru - очень демократичные - всего 5400р

Если же вы хотите оплатить сами, то для вас есть промокод на скидку в 500р - react_crew_2_74mrG8

Также организаторы выделили билет на розыгрыш в канале. Розыгрыш запущу после этого поста, когда разберусь с ботом для этой активности. Правила простые: если вы подписаны на канал и тыкнули "участвовать", вы получаете шанс получить билет. Во вторник подведем итоги.

Announcing Rspack 1.2

Вышел RSPack 1.2. RSPack это бандлер для веб-проектов, написанный на Rust.

Что интересного - завели persistent cache, который может ускорить сборку на 250%. Это мастхев для больших проектов

Также из улучшений перформанса:
- Ускорение код-сплиттинга
- Можно управлять тем, за изменением каких файлов следит RSPack. По дефолту раньше он следил за всеми файлами в node_modules, что, конечно, давало свой оверхед. Теперь это можно настраивать вручную
- Уменьшили потребление памяти при сборки проектов
- Увеличили минификацию кода SWC
- Распараллелили стадию сборки "сайд-эффекты", что улучшило перформанс стадии в 2-3 раза

Кроме улучшений перформанса:
- Поддержка Angular
- Поддержка Yarn PnP

https://rspack.dev/blog/announcing-1-2

#development #javascript #bundlers #rspack #release

Avoiding anys with Linting and TypeScript

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

Данная статья описывает, как писать меньше any и больше осмысленного кода. Статья проходится по настройкам в tsconfig и eslint - как их следует подключать и как использовать.

Казалось бы, для чего статья - включи запрет на any в tsconfig и все готово. Но это не так. Например, если вы включите в конфиге noImplicitAny, то вы избавитесь от неявных any, но явные при этом, останутся. Это хороший первый шаг, но его недостаточно

Откуда могут появиться any:

Разработчик может сам их объявить
function foo(param: any) {}


В этом случае noImplicitAny не поможет т.к. any тут задан явно (explicit). Это можно забанить через плагин к eslint'у - `@typescript-eslint/no-unsafe-function-type`

Но даже если мы подключим это правило, то и его будет недостаточно, т.к. any может появиться в результате вызова встроенных функций. Например, JSON.parse, или при использовании типа Function, или при использовании try catch аргумент в catch будет any

Как все это поправить:
- `@typescript-eslint/no-unsafe-argument` запрещает any в аргументах
- `@typescript-eslint/no-unsafe-assignment` запрещает any в переменных
- `@typescript-eslint/no-unsafe-call` запрещает any в вызовах
- `@typescript-eslint/no-unsafe-member-access` запрещает получать проперти у any
- `@typescript-eslint/no-unsafe-return` запрещает возвращать any из функции
- `@typescript-eslint/use-unknown-in-catch-callback-variable` - форсит использование unknown в try catch
- `ts-reset` - исправляет глобальные типы TS. Например, после установки, JSON.parse() начнет возвращать unknown.
- `@typescript-eslint/ban-comment` - запрещает оставлять управляющие тайп-чекером TS коменты без описания
- `@eslint-community/eslint-comments/disable-enable-pair`, `@eslint-community/eslint-comments/no-unlimited-disable`, `@eslint-community/eslint-comments/require-description` запрещают оставлять комментарии управляющие eslint-ом без описания

После всего этого можно пойти дальше и включить строгие правила в конфиге.


https://typescript-eslint.io/blog/avoiding-anys/

#development #javascript #typescript #any #eslint #tsconfig

Running Inference In Web Extensions

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

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

При этом API очень простое, например, можно суммаризировать текст вот такой функцией

async function summarize(text) {
await browser.trial.ml.createEngine({taskName: "summarization"});
const result = await browser.trial.ml.runEngine({args: [text]});
return result[0]["summary_text"];
}


При этом можно передать ссылку на кастомную готовую модель и firefox ее загрузит. Если вы пишите расширение для firefox - рекомендую посмотреть в сторону нового API. Можно поиграться с нативным API в firefox и найти какую-то крутую фичу для расширения, которую потом можно портировать на transofmerjs.



https://blog.mozilla.org/en/mozilla/ai/ai-tech/running-inference-in-web-extensions/

#development #javascript #firefox #TransformerJs #ai

Refactoring with Codemods to Automate API Changes: часть 2 - основные ошибки

Обновление в статье про кодмоды - основные проблемы кодмодов. Первая часть обозревается тут

Данная часть статьи продолжает предыдущий пример. В предыдущем примере был описан кодмод, который заменяет использование компонента Avatar на Avatar + Tooltip. Все хорошо в простых кейсах, но что если а) кто-то импортировал Avatar с ренеймом import { Avatar as NotAvatar } б) что если тултип уже импортирован. В этих случаях кодмод или не отработает, или отработает криво, что приведет к проблемам.

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

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

Другая полезная техника - декомпозиция кодмода (или наоборот, композиция кодмодов)

Вернемся к примеру с фиче-тоглом
import { featureToggle } from "./utils/featureToggle";

const convertOld = (input: string) => {
return input.toLowerCase();
};

const convertNew = (input: string) => {
return input.toUpperCase();
};

const result = featureToggle("feature-convert-new")
? convertNew("Hello, world")
: convertOld("Hello, world");

console.log(result);


Если мы хотим написать кодмод, который уберет использование фичетогла
const convertNew = (input: string) => {
return input.toUpperCase();
};

const result = convertNew("Hello, world");

console.log(result);


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

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

import { removeFeatureToggle } from "./remove-feature-toggle";
import { removeUnusedImport } from "./remove-unused-import";
import { removeUnusedFunction } from "./remove-unused-function";

import { createTransformer } from "./utils";

const removeFeatureConvertNew = removeFeatureToggle("feature-convert-new");

const transform = createTransformer([
removeFeatureConvertNew,
removeUnusedImport,
removeUnusedFunction,
]);

export default transform;


import { API, Collection, FileInfo, JSCodeshift, Options } from "jscodeshift";

type TransformFunction = { (j: JSCodeshift, root: Collection): void };

const createTransformer =
(transforms: TransformFunction[]) =>
(fileInfo: FileInfo, api: API, options: Options) => {
const j = api.jscodeshift;
const root = j(fileInfo.source);

transforms.forEach((transform) => transform(j, root));
return root.toSource(options.printOptions || { quote: "single" });
};

export { createTransformer };


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

https://martinfowler.com/articles/codemods-api-refactoring.html#FixingCommonPitfallsOfCodemods

#development #javascript #martinFowler #codemod

Дайджест за 2025-01-20 - 2025-01-24

A checklist for your tsconfig.json
Пост от Dr. Axel Rauschmayer, который объясняет основные опции в tsconfig и дает советы, какие опции следует указать в своем конфиге в разных случаях (в зависимости от типа приложения).

По сути, это переработка доки по tsconfig с комментариями. Тем не менее, все рассказано достаточно ёмко и понятно.

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

Learn Yjs
Learn Yjs - интерактивный курс про то, как использовать Yjs CRDT библиотеку для создания приложений с возможностью совместной работы (условно как в гугл доке, когда несколько юзеров могут редактировать один документ одновременно)

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

Five years of React Native at Shopify
5 лет назад Shopify сообщили о том, что они переезжают на React Native. Пока одни компании хоронят RN и переезжают с него, а другие форсят Flutter или чистый натив, shopify 5 лет живет с React Native (и контрибьютит в RN, за что им отдельный респект) и пока не думают уходить. В статье есть ссылки на другие статьи от shopify по теме.

Explore Agent Recipes
Статья от стартапа together.ai, который предоставляет SDK для работы с LLM, которая описывает основные паттерны работы с большими языковыми моделями и дает примеры на python и typescript.


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

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