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

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

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

Всем привет! Сегодня в канале не статья, сегодня будет реклама анонс онлайн-конфы для 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

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

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

Дайджест за 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-разработчиков + розыгрыш билета на конфу.

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

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

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 <package>
- Отредактируйте файлы в node_modules/package
- Запустите bun patch --commit <package>
- Теперь 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

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<Type extends {}> = {
    [_ 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<User> = 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

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

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

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

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

Hypermod

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

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

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

https://www.hypermod.io

#development #javascript #typescript #codemod #refactoring

Дайджест за 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 - инструментарий для кодмодов. Пока еще в бете. Я его упоминал в предыдущем посте и мне он показался интересным

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

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

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

Docxtemplater

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

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

https://docxtemplater.com

#development #javascript #docx #library

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<Response>;

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

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

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

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

#development #javascript #node

Standard Schema - A common interface for TypeScript validation libraries

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

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

https://standardschema.dev

#development #javascript #typescript #schema

Миграция на строгий 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

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

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

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

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

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

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

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

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

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

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

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

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

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



#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 такого простого решения нет

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



#note #book

Introducing Fusion - write PHP inside Vue and React components

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

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

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

<!-- app.vue -->
<php>
    $user = prop(Auth::user()->email);
</php>
 
<template>
    <div>{{ user }}</div>
</template>

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

#development #javascript #php #vue