Dev News от Максима Соснова

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

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

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

Есть несколько основных идей в книге
- Для взвешенных решений необходимо "ставить шкуру на кон", т.е. рисковать чем-то. Тот, кто не рискует, не может принимать хороших решений.
- Диктатура меньшинства. Если есть какое-то непримиримое меньшинство (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<Response>;

Плюсы от такого описания:
- Это кросс-платформенная запись для всех 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<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

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

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


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

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

Explore Agent Recipes

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

https://www.agentrecipes.com

#development #typescript #ai #llm

Five years of React Native at Shopify

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

Какие плюсы выделяет команда Shopify от переезда на React Native:
- Стали быстрее делать фичи т.к. фичи теперь делаются 1 раз и сразу доставляются на обе платформы
- Инженеры могут переходить между разработкой в вебе и разработкой в нативе, что дает гибкость компании
- Паритет по фичам между iOS и Android из коробки
- Приложения очень быстрые (<500мс на загрузку экрана)
- Продолжают использовать нативные решения там, где это оправдано

Что еще выделяют в RN

Приложения на React Native - быстрые
Каждый раз при переходе с нативных решений на RN встает вопрос о перформансе. Нативные решения - быстрые т.к. они нативные. Пользователи ожидают быстрого отклика от мобильных приложений. Заметят ли требовательные к перформансу пользователи изменения в отклике при переезде на RN? Итог 5 лет: приложения на RN можно сделать такими же быстрыми, как и нативные приложения, если делать все правильно. Здесь в посте даются 3 ссылки на материалы, как shopify ускорял приложение на RN

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

Typescript позволяет разработчикам свободно переходить с React Web на React Native и обратно
Это позволяет бизнесу быть более гибким: сегодня у вас много фичей на веб, в следующем квартале на натив. Т.к. одни и те же люди могут делать и то и то, то нет проблемы с распределением людей по этим задачам. Другой большой плюс: что код для нативной мобилки и веба имеет одну технологическую базу, а значит можно иметь общие инструменты, бест-практисы и договоренности.

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

В Shopify нативных разработчиков обучал RN-у и Javascript'у, чтобы они могли войти в RN и применять свою глубокую экспертизу. Обучение при этом проходило системно: были выделено рабочее время на обучение, менторы со стороны RN, React и Javascript.

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

Дебаг стал хуже
Дебаг в RN неудобный (особенно по сравнению с нативной разработкой). Но Meta уже улучшает эту часть RN и shopify помогает им в этом.

Апдейты RN не бесшовные
Обновление приложения на новую версию RN всегда занимает много времени.

Большая зависимость от сторонних библиотек
Как следствие - необходимо уделять внимание обновлению этих библиотек и угрозам безопасности в них.

https://shopify.engineering/five-years-of-react-native-at-shopify

#development #javascript #reactNative #shopify

Learn Yjs

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

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

https://learn.yjs.dev/

#development #javascript #Yjs

Иду на обучение в стратоплан

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

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

Принцип Питера: В иерархической системе каждый индивидуум имеет тенденцию подниматься до уровня своей некомпетентности

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

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

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

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



#managment #note

A checklist for your tsconfig.json

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

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

https://2ality.com/2025/01/tsconfig-json.html

#development #javascript #typescript #tsconfig

Дайджест за 2025-01-13 - 2025-01-17

Electrobun
Electrobun - фреймворк для создания десктопных приложений на Typescript, который под капотом использует bun. В целом, из названия понятно, что это аналог Electron, но с использованием bun

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

Refactoring with Codemods to Automate API Changes: часть 1
В блоге Мартина Фаулера появилась статья про кодмоды. Она еще не закончена (позднее будут апдейты), но уже достаточно интересна. Кодмод (codemod => code modification) - это инструмент для автоматического изменения кода.

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

You don't need Next.js
История команды ComfyDeploy о том, как они переехали с Next.js на чистый React. Статья убер короткая, но кейс интересный.

Что дал переезд на чистый React:

Node’s new built-in support for TypeScript
Node.js, начиная с версии 23.6.0, поддерживает TS без прокидывания каких-либо флагов. Dr. Axel Rauschmayer в своем блоге рассказывает, как использовать TS в Node.js без компиляции, какие есть ограничения, и что будет с этой фичей в будущем.

Все основные ограничения связаны с тем, что Node.js не компилирует TS, а просто лишь вырезает типы из кода. Т.е. не получится использовать фичи TS - енамы, неймспейсы. Также нет поддержки TSX (что логично, т.к. нет поддержки JSX)

2024 JavaScript Rising Stars
Кто-то подвел итоги 2024 года в Javascript и выделил восходящие звезды (по сути выделили проекты, которые получили больше всего звезд на гитхабе за год). Звезды поделены по категориям: фреймворки, тулинг, Реакт, Бекенд, тестирование и так далее.

Есть достаточно интересные вещи. Например, в общем списке проектов:

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

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

2024 JavaScript Rising Stars

Кто-то подвел итоги 2024 года в Javascript и выделил восходящие звезды (по сути выделили проекты, которые получили больше всего звезд на гитхабе за год). Звезды поделены по категориям: фреймворки, тулинг, Реакт, Бекенд, тестирование и так далее.

Есть достаточно интересные вещи. Например, в общем списке проектов:
- Excalidraw - достаточно популярная рисовалка
- Affine - аналог Notion
- Bruno - аналог postman (использую сам)
- n8n - low-code платформа (использую для публикации статьей в канал)
- Flowise - low-code платформа для LLM

В целом во многих категориях топ без каких-либо изумлений. Например, в стейт менеджерах:
- Zustand (недавно кстати начал юзать в одном пет-проекте, о нем позже еще напишу)
- Jotai
- XState
- Pinia
- Nano Stores

Однако, все равно рекомендую вам самостоятельно посмотреть весь список, возможно вы найдете что-то для себя. Лично я изучу пару инструментов (в основном связанных с LLM)



https://risingstars.js.org/2024/en

#development #javascript #yearResults

Node’s new built-in support for TypeScript

Node.js, начиная с версии 23.6.0, поддерживает TS без прокидывания каких-либо флагов. Dr. Axel Rauschmayer в своем блоге рассказывает, как использовать TS в Node.js без компиляции, какие есть ограничения, и что будет с этой фичей в будущем.

Все основные ограничения связаны с тем, что Node.js не компилирует TS, а просто лишь вырезает типы из кода. Т.е. не получится использовать фичи TS - енамы, неймспейсы. Также нет поддержки TSX (что логично, т.к. нет поддержки JSX)

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

Например:

function describeColor(color: Color): string {
  return `Color named “${color.colorName}”`;
}
type Color = { colorName: string };
describeColor({ colorName: 'green' });

Скомпилируется в

function describeColor(color       )         {
  return `Color named “${color.colorName}”`;
}

describeColor({ colorName: 'green' });

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

https://2ality.com/2025/01/nodejs-strip-type.html

#development #javascript #node #typescript

You don't need Next.js

История команды ComfyDeploy о том, как они переехали с Next.js на чистый React. Статья убер короткая, но кейс интересный.

Что дал переезд на чистый React:
- Ускорение сборки с 3 минут до 18 секунды
- Хот релоад до 200мс
- Все в команде стали счастливее

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

Next.js это мощный фулстек фреймворк, но он также несет с собой сложности, с которыми нужно бороться при росте приложения. В общем, автор дошел до точки, когда исправление небольшой опечатки требовало ожидания 7 минут сборки и решил отказаться от Next.js и перейти просто на React, т.к. большинство фичей Next ему были не нужны.

В статье есть гифки, где сравнивается открытие страницы при старте дев-сервера на next.js 15 с режимом turbo и чистым React. Победил React - 1.67 секунды против 10 секунд. Сравнение не совсем честное т.к. пока автор переводил проект на React, он удалял еще всякое ненужное по пути (старые фичи, неиспользуемые библиотеки).

Что автор потерял от отказа от Next.js:
1. Пришлось разделить кодовые базы бекенда и фронтенда (не сказал бы конечно, что это минус)
2. Потеряли фичи кэширования из Next.js, пришлось делать кэширование руками
3. Потеряли статическую генерацию, теперь приходится больше думать о сплитовании чанков. Но зато теперь нет проблем с кликами по элементам, которые уже отрендерены, но еще не работают
4. Потеряли "магию" серверных компонентов.


https://www.comfydeploy.com/blog/you-dont-need-nextjs

#development #javascript #nextjs #react

Refactoring with Codemods to Automate API Changes: часть 1

В блоге Мартина Фаулера появилась статья про кодмоды. Она еще не закончена (позднее будут апдейты), но уже достаточно интересна. Кодмод (codemod => code modification) - это инструмент для автоматического изменения кода.

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

Как всегда в блоге Мартина Фаулера, все раскладывается по полочкам. Сначала описывается проблема, которая привела к созданию таких инструментов: иногда нужно сделать повторяющиеся изменения в коде проекта и не всегда это можно сделать простым find-and-replace или с помощью sed. Тут на помощь приходят кодмоды - они позволяют описывать изменения не в формате строка => строка, а в формате AST => AST, что намного гибче и позволяет учесть много разных кейсов.

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

В статье разбирается 2 примера:

Удаление уже неактуальных фиче-тоглов

Если вы разрабатываете через фиче-тоглы, то вы знаете о проблеме работы с тоглами:

Когда фича не готова, мы ее закрываем фиче-тоглом

const data = featureToggle('feature-new-product-list') ? { name: 'Product' } : undefined;

Когда фича готова и протестирована, надо удалить фиче-тогл

const data = { name: 'Product' };

Эту работу можно сделать с помощью кодмода на jscodeshift

module.exports = function (fileInfo, api, options) {
  const j = api.jscodeshift;
  const root = j(fileInfo.source);

  // Find ConditionalExpression where the test is featureToggle('feature-new-product-list')
  root
    .find(j.ConditionalExpression, {
      test: {
        callee: { name: "featureToggle" },
        arguments: [{ value: "feature-new-product-list" }],
      },
    })
    .forEach((path) => {
      // Replace the ConditionalExpression with the 'consequent'
      j(path).replaceWith(path.node.consequent);
    });

  return root.toSource();
};

Рефакторинг компонента Avatar

Кейс такой: компонент аватара имеет тултип. Если передать текст тултипа в пропсе, то можно навести мышку на аватар и увидеть подпись к аватару.
Но реальность показала, что нужно уметь полноценно управлять тултипом, поэтому эту ответственность лучше вынести из компонента аватара.

В контексте статьи описывается, как сделать кодмод, который если видит использование компонента Avatar с нужной пропсой, обернет его в Tooltip

+ import { Tooltip } from "@design-system/tooltip";
import { Avatar } from "@design-system/avatar";

const UserProfile = () => {
  return (
-    <Avatar  image="/juntao.qiu.avatar.png" name="Juntao Qiu/>
+    <Tooltip content="Juntao Qiu">
+      <Avatar image="/juntao.qiu.avatar.png" />
+    </Tooltip>
  );
};

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

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

#development #javascript #refactoring #codemod

Electrobun

Electrobun - фреймворк для создания десктопных приложений на Typescript, который под капотом использует bun. В целом, из названия понятно, что это аналог Electron, но с использованием bun

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

https://electrobun.dev

#development #javascript #electron #bun #desktop

Всех с наступающим новым годом 🎄

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

Встретимся в новом году

Чем заняться на новогодних каникулах

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

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

------------------------

Про то, как писать хороший код

Роберт Мартин - чистый код (Clean Code)

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

Мартин Фаулер - 2 издание книги про рефакторинг
Искать так:
- Refactoring: Improving the Design of Existing Code (2nd Edition)
- Рефакторинг кода на JavaScript. Улучшение проекта существующего кода

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

Роберт Мартин - чистая архитектура (Clean Architecture)

Постоянно видите споры в интернетах про то, что на самом деле означает S в SOLID, но не можете влететь в него с двух ног и вас это расстраивает? Тогда эта книга для вас! В книге рассказываются как практики для написания кода (разделение ответственности и тд), так и практики по проектированию систем.

Философия разработки ПО
Как искать:
- Philosophy of software design, John K. Ousterhout

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

Принципы Юнит-Тестирования, Хориков Владимир

Примеры в книге написаны на C#, но общие принципы написания авто-тестов везде одинаковые. Книга очень хорошо описывает лучшие практики и антипаттерны автоматического тестирования, учит по шагам, как научиться писать хорошие тесты.

------------------

Про код закончил, перейду теперь к процессам и командам

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

Проект "Феникс". Как DevOps устраняет хаос и ускоряет развитие компании | Ким Джин, Бер Кевин
Буквально адаптация предыдущей книги к реальности в IT. Читать после Цели.

Deadline. Роман об управлении проектами | ДеМарко Том
Самый странный (с художественной точки зрения) бизнес-роман из всех в этой подборке. Если коротко, книга рассказывает о контр-интуитивных вещах про процессы разработки, менеджмент, команду и производительность. Читается порой сложно - я перечитывал этот роман 3 раза и каждый раз открывал его с новой стороны.

Пять пороков команды | Ленсиони Патрик

Бизнес-роман про 5 основных проблем, которые не дают команде стать командой. Кое где весьма спорно, но тем не менее, все чаще замечаю на практике, что идеи в книге верные.

--------

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



#note #books

Дайджест за 2024-12-23 - 2024-12-27

Remove Image Background
Addy Osmani сделал тул для удаления заднего фона с фотографий, который работает прямо в браузере. Сам тул не то чтобы сильно интересный или предоставляет какие-то уникальные функции, но интересен тем, как он сделан.

Сайт использует готовые модельки (на выбор даются 2 из выпадашки), которые скачиваются прямо в браузер (весят в пределах пары десяток мегабайт) и прямо в браузере запускаются через Transformer.js - библиотеку, которая позволяет запускать в JS различные модельки с huggingface.

FSD 2.1 или как «pages first» подход может ухудшить структуру ваших Frontend приложений
Вышло обновление Feature Sliced Design 2.1, в котором добавили сущность страниц и папку pages. Теперь вместо супер плоского списка в руте проекта код можно делить по страницам.

Статья по ссылке является частным мнением про нововведение (оценка фичи - негативная). В комментариях есть немного интересных комментариев

Как мы мигрируем с JQuery на React
Неплохая статья про миграцию легаси кодовой базы с ASP + jquery на React. Люди, в целом, деляться на 2 типа: одни знают базовый способ как итеративно переписывать кодовую базу, а другие не знают и хотят все переписать. Для первых статья не принесет ничего принципиально нового, но можно посмотреть на интересные решения. Для вторых статья будет полезна как реальный пример итеративной миграции, где надо скрещивать новые и старые технологии.

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

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

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

Как мы мигрируем с JQuery на React

Неплохая статья про миграцию легаси кодовой базы с ASP + jquery на React. Люди, в целом, делятся на 2 типа: одни знают базовый способ как итеративно переписывать кодовую базу, а другие не знают и хотят все переписать. Для первых статья не принесет ничего принципиально нового, но можно посмотреть на интересные решения. Для вторых статья будет полезна как реальный пример итеративной миграции, где надо скрещивать новые и старые технологии.

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

Вернемся к статье: перескажу её коротко. Есть приложение на ASP+jquery. Оно большое, оно работает и развивается. Переписывать его единомоментно - это большие риски и придется вместо выпуска фич переписывать код (возможно с багами).

Код при этом организован в неймспейсы. Т.е. условно jquery компоненты существуют и достаются так

const combobox = new App.Components.Combobox({
  container: document.querySelector('#someDiv'),
  props: {}
});

Внутри эти компоненты описывались в react-like стиле

namespace App.Components {
 export interface ComboBoxProps {
  container: JQuery;
  items: ComboBoxItem[];
  renderOption: (item: ComboBoxItem) => JQuery;
 }
 
 export class ComboBox {
  constructor(private props: ComboBoxProps) {
   // создаём разметку и рендерим её в container
   this.container.append(this.render());
  }
 
  private render(): JQuery {
   const viewItems = this.props.items.map(this.props.renderOption);
   // ... создаём разметку
   return view;
  }
 
  setItems() { /* ... */ }
  enable() { /* ... */ }
  disable() { /* ... */ }
 }
}

Если мы хотим использовать современный тулинг вместо jquery и внедрять этот тулинг итеративно, то базовый хороший вариант - внедрить этот тулинг в эти неймспейсы. Что автор и делает: создается адаптер, который "склеивает" новый и старый подходы.

Создается адаптер, который скрывает, что он рендерит React-компонент

export async function renderAppHeader(props: AppHeaderProps, container: HTMLElement) {
    const { AppHeader } = await import('./components/AppHeader');
 
    return renderComponent({
        container,
        component: <AppHeader {...props} />,
        autoUnmount: true
    });
}

Который в коде используется примерно также, как использовался Combobox

myLib.renderAppHeader(document.getElementById('header-container'), {
 title: 'Cool App',
 // остальные пропсы ...
})

React-код при этом находится в отдельном репозитории и компилируется как UMD библиотека (чтобы быть глобально доступной). При этом встает проблема сборки html и вставки туда скриптов библиотеки. Страницы собирает .NET и самый простой способ менять ссылки на новые при каждом релизе компонентов - это пересобирать .NET проект. Способ ужасный, поэтому в .NET был написан код, который умеет работать с manifest.json webpack-а и понимает какие файлы необходимо отдавать.

Также интересен выбранный стейт-менеджер. Изначально стейт был в React Context'е и хуках, но потом было необходимо заиспользовать полноценный стейт-менеджер. Выбор пал на zustand, как более менее удобный и который можно использовать в старом коде, а не только в новом.

В общем, статья неплохая - не слишком глубокая и не слишком поверхностная.  

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

#development #javascript #habr #jquery #react #migration #ASPnet

FSD 2.1 или как «pages first» подход может ухудшить структуру ваших Frontend приложений

Вышло обновление Feature Sliced Design 2.1, в котором добавили сущность страниц и папку pages. Теперь вместо супер плоского списка в руте проекта код можно делить по страницам.

Статья по ссылке является частным мнением про нововведение (оценка фичи - негативная). В комментариях есть немного интересных комментариев

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

Один из главных минусов FSD, для меня, было игнорирование базового принципа декомпозиции. Например, у меня есть страница, на странице есть форма, у формы есть сложные поля. Эта иерархичная структура (страница => форма => поля) отлично ложится на тестовую модель, на описание архитектуры, на работу дизайнеров и она полностью отрицается FSD т.к. нельзя делать вложенные контексты. Ну, вот и pages появились. Осталось дождаться когда разрешат внутри делать вложенные контексты - тогда можно будет вернуться к рассмотрению FSD.

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

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

#development #javascript #fsd #featureSlicedDesign

Remove Image Background

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

Сайт использует готовые модельки (на выбор даются 2 из выпадашки), которые скачиваются прямо в браузер (весят в пределах пары десяток мегабайт) и прямо в браузере запускаются через Transformer.js - библиотеку, которая позволяет запускать в JS различные модельки с huggingface.

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

https://bg.addy.ie

#development #javascript #TransformerJs #ai

Дайджест за 2024-12-17 - 2024-12-20

proposal-import-sync
Пришел апдейт по пропозалам в EcmaScript. Внезапно для себя увидел там динамический синхронный импорт :О . Пока еще в stage 1, т.е. все еще может сильно поменяться.

Кейсы использования из пропозала

React 19 is now stable!
React 19 можно использовать в проде. С момента публикации бетки доки про 19 реакт в доке появилось 2 изменения: улучшения в Suspense и новое статичное API в React Dom

Улучшения Suspense заключаются в том, что теперь, если необходимо отрендерить фолбек, то фолбек будет рендерится сразу, а не дожидаться рендера соседей по дом-дереву. Это улучшает user experience (и, как я помню, на это многие жаловались в github-ишуях react'а).

State of Node.js Performance 2024
Новый бенчмарк по производительности новой версии Node.js по сравнению с предыдущими. В целом все как обычно: часть операций ускорилась, часть немного замедлилась. В основном, конечно, все стало быстрее

Если вы пишете высоконагруженные приложения на node.js, то вам точно стоит посмотреть. Можете, например, выяснить, что именно ваш код замедлится на 50% (например, если вы декодируете latin1) и надо подождать, пока команда node.js исправит это. Или наоборот, значительно ускорится и лучше быстрее обновляться.

React Anti-Pattern: Stop Passing Setters Down the Components Tree
Короткая и немного скомканная статья про один из анти-паттернов в React - протекание абстракции из-за прокидывания в пропсы компонента функции, которая умеет много больше, чем занимается компонент.

Ну я слишком широко взял, автор сетует на прокидывание set-функции из useState в компоненты.

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

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

React Anti-Pattern: Stop Passing Setters Down the Components Tree

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

Ну я слишком широко взял, автор сетует на прокидывание set-функции из useState в компоненты.

function Form() { 
    const [formData, setFormData] = useState({ name: '' }); 
    return (
        <div>
            {/* прокидываем в инпут колбек, который сетит ВСЮ форму*/}
            <Input name={formData.name} setFormData={setFormData} />
        </div> 
    ); 
};


function Input({ name, setFormData }) { 

    const handleInputChange = (event) => { 
     // обновляем только одно поле
        setFormData((prevData) => ({ ...prevData, name: event.target.value })); 
    }; 
    
    return <input type="text" value={name} onChange={handleInputChange} />;
};

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

Как должно быть в упрощенном примере:

function Form() { 
    const [formData, setFormData] = useState({ name: '' }); 
    const setName = (name) => setFormData({...formData, name})
    return (
        <div>
            <Input name={formData.name} onChangeName={setName} />
        </div> 
    ); 
};


function Input({ name, onChangeName }) { 

    const handleInputChange = (event) => {
     onChangeName(event.target.value) 
    }; 
    
    return <input type="text" value={name} onChange={handleInputChange} />;
};

Можно пойти еще дальше - вынести все в хук или контекст, но суть не в этом. Суть текущего поста не в том, как делать "правильно", а как не делать "неправильно" - не кидайте в компоненты "лишние" данные и функции.

https://matanbobi.dev/posts/stop-passing-setter-functions-to-components

#development #javascript #react #antiPatterns

State of Node.js Performance 2024

Новый бенчмарк по производительности новой версии Node.js по сравнению с предыдущими. В целом все как обычно: часть операций ускорилась, часть немного замедлилась. В основном, конечно, все стало быстрее

Если вы пишете высоконагруженные приложения на node.js, то вам точно стоит посмотреть. Можете, например, выяснить, что именно ваш код замедлится на 50% (например, если вы декодируете latin1) и надо подождать, пока команда node.js исправит это. Или наоборот, значительно ускорится и лучше быстрее обновляться.



https://nodesource.com/blog/State-of-Nodejs-Performance-2024

#development #javascript #nodejs #performance #benchmark

React 19 is now stable!

React 19 можно использовать в проде. С момента публикации бетки доки про 19 реакт в доке появилось 2 изменения: улучшения в Suspense и новое статичное API в React Dom

Улучшения Suspense заключаются в том, что теперь, если необходимо отрендерить фолбек, то фолбек будет рендерится сразу, а не дожидаться рендера соседей по дом-дереву. Это улучшает user experience (и, как я помню, на это многие жаловались в github-ишуях react'а).

Новое статичное API для React DOM представляет собой методы для статической генерации сайтов prerender и prerenderToNodeStream. Это версия рендера, которая дожидается загрузки данных и только потом отдает разметку. Обычный же рендер серверных компонентов может сначала отдать разметку с фолбеками, а только потом дослать апдейт разметки когда данные загрузятся.

Кто уже обновился?

https://react.dev/blog/2024/12/05/react-19

#development #javascript #react #react19

proposal-import-sync

Пришел апдейт по пропозалам в EcmaScript. Внезапно для себя увидел там динамический синхронный импорт :О . Пока еще в stage 1, т.е. все еще может сильно поменяться.

Кейсы использования из пропозала

Синхронная загрузка кода, который уже должен быть загружен

import 'app';

// this will always work if 'app' has been loaded previously
const app = import.sync('app');

Если модуль еще не загружен (или код не выполняется в top-level await), то такой вызов синхронного импорта кинет исключение.

Условная загрузка

let fs;
try {
  fs = import.sync('node:fs');
} catch {}

if (fs) {
  // Use node:fs, only if it is available
}

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

https://github.com/tc39/proposal-import-sync

#development #javascript #proposal

Дайджест за 2024-12-02 - 2024-12-05

Conditional Props in React Using Type Discrimination
Хорошая вводная статья про Type Discrimination в Union в typescript. Это паттерн, который позволяет выделять разные типы объектов по какому-либо полю

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

Overflow Clip
Хорошая статья про то, как работает overflow в css. Наверное, каждый фронтендер использовал это свойство для обрезки контента или чего-то подобного. С одной стороны - все просто, с другой, вряд ли кто-то глубоко погружался в то, какие возможности вообще есть у этого функционала.

В данной статье представлены крутые интерактивые примеры использования overflow: clip, которые позволяют сделать то, что сложно (или невозможно) сделать с помощью overflow: hidden.

typescript advent и adventofcode
Снова декабрь. Снова адвенты. Выделяю 2 адвента, о которых знаю: адвент по typescript и advent of code.

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

Technology Radar | October 2024
Вышел новый выпуск радара технологий от thoughtworks. Напомню, что это такое: периодически компания thoughtworks выпускает радар, который показывает, какие технологии и инструменты они используют, какие тестируют, от каких отказываются. К каждой практике есть подробное описание про практику и причины попадания в определенную зону радара

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

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

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

Technology Radar | October 2024

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

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

Что нового и интересного я увидел там для себя

Очень много про AI и LLM:
- Using GenAI to understand legacy codebases
- Small language models
- Synthetic data for testing and training models
- LLM as a judge
- Function calling with LLMs
- Dynamic few-shot prompting
- On-device LLM inference
- Structured output from LLMs
- FastChat
- Software engineering agents (например Copilot Workspace)

Все эти штуки либо в зоне бест-практисов, либо в зоне перспективных
Однако одна штука уехала в зону "надо выбрасывать", а именно "Replacing pair programming with AI". Чтож, теперь есть и вердикт от thoughtworks, что copilot не может заменить человека для парного программирования

Про практики:
- Domain storytelling - практика для фасилитации старта построения домена для DDD
- Observability 2.0 - переход к единому подходу к обсервабилити, вместо использования кучи разных
- Continuous deployment и 1% canary перешли в бест-практисы

Из того, что более менее связано с вебом:
- Component testing - сразу попало в бест-практисы. Под компонентными тестами имеются в виду тесты компонентов в jsdom. Использование реального браузера слишком медленное и нестабильное.
- GraphQL for data products - GraphQL в радаре с 2019 года, но вот оказалось что GraphQL весьма неплох для получения данных из больших хранилищ данных. Более того, graphQL удобен для нейронок т.к. есть схемы и понятное апи для доставания данных
- Spinkube - опен-сорс серверлесс рантайм для WASM в k8s
- PGLite - wasm реализация PostgreSQL
- Rspack - добавлен как перспективный сборщик фронтенд проектов
- tsoa - это проект, который предлагает использовать TS как единую точку правды о контрактах API и генерировать swagger на основе ts. Плюсы использования TS: это ЯП, в котором удобно работать со структурами и типами, и в который легко войти. Также можно использовать все практики для кода (бранчевание, версионирование, линтинг и тд)



Инструменты:
- Zed - редактор на Rust от создателей Atom. Поддерживает много языков программирования, AI и совместную работу. Но пока рано говорить что Zed может заменить vscode.
- Warp - терминал для macos и linux. Я уже писал о нем в канале - это очень удобный терминал. Использую его уже давно и пока нравится. Основная фича, на мой взгляд, это просто крутой DX - это терминал в котором удобно работать. Но еще есть AI, сниппеты и еще куча всякого вокруг, но я это не использовал
- Raycast - ланчер для macOS, который умете запускать программы, искать файлы, запускать автоматизированныеп задачи
- Mockoon- опен-сорсный тул для мокирования. Умеет работать с OpenAPI
- GitButler - простой и удобный git client
- Difftastic - тула для показа diff, которая учитывает контекст. Например, когда вы смотрите обычный дифф (например в том же гите) кода как дифф текста, то вы наверняка сталкивались с тем, что дифф неправильно понял, например, рефакторинг. Или просто показывает много шума (вы добавили точку с запятой - это супер безопасное изменение, но показывается ровно также как обычное изменение). Diffstatic учитывает контекст и убирает весь шум. Я пока не пробовал, но звучит круто (если еще и рефакторинги в TS будет понимать - будет ваще пушка) и мой коллега уже юзает и пока хвалит (пользуясь случаем - привет Серёга 👋)


https://www.thoughtworks.com/radar

#development #thoughtworks #techradar

typescript advent и adventofcode

Снова декабрь. Снова адвенты. Выделяю 2 адвента, о которых знаю: адвент по typescript и advent of code.

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

Advent of code - это адвент с алгоритмическими задачками. Я не любитель подобного, но знаю, что многим нравится

Если вы знаете еще какие-то адвенты - кидайте в тред.

https://www.adventofts.com
https://adventofcode.com/2024

#development #advent #typescript

Overflow Clip

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

В данной статье представлены крутые интерактивые примеры использования overflow: clip, которые позволяют сделать то, что сложно (или невозможно) сделать с помощью overflow: hidden.

https://ishadeed.com/article/overflow-clip/

#development #css #overflow

Conditional Props in React Using Type Discrimination

Хорошая вводная статья про Type Discrimination в Union в typescript. Это паттерн, который позволяет выделять разные типы объектов по какому-либо полю

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

Вот самый утрированный пример:

type User = {
    type: 'user' | 'admin';
    commonField: any;
    adminField?: any;
    userField?: any;
}

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

const user: User = {
   type: 'user',
   commonField: 1,
   adminField: 2,
   userField: 3
}

По бизнес-логике не может юзер содержать админские поля, но по типам тайпскрипта - может. Как это решить? Автор сначала рассматривает Generic, но я это даже приводить не буду, т.к. для решения этой проблемы в TS есть механика discriminate types.

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

В данном случае нам следует явно выделить тип юзера и тип админа и скрестить их в тип абстрактного юзера через объединение. При этом в типы юзера и админа мы будем различать по полю type

type Admin = {
 type: 'admin';
    commonField: any;
    adminField: any;
}
type User = {
 type: 'user';
    commonField: any;
    userField: any
}
type AbstractUser = User | Admin

Теперь typescript будет корректно уточнять тип по проверке user.type

function procerssUser(user: AbstractUser) {
 if (user.type === 'admin') {
  console.log(user.adminField)
 }
 if (user.type === 'user') {
  console.log(user.userField)
 }
}

В статье все это описано более подробно и с примерами из React (хотя React тут скорее просто как пример использования)

https://elanmed.dev/blog/conditional-props-using-type-discrimination

#development #javascript #typescript #discrimination #react

Дайджест за 2024-11-25 - 2024-11-29

Uncontrolled or controlled: A matter of perspective
Статья, разбирающая смысл термином Controlled Component и Uncontrolled Component. В целом, ничего нового, но разбор короткий и понятный

Давайте разберем на небольшом примере

Adopting the compiler in Sanity Studio
Sanity Studio - приложение для создания и редактирования контента (не до конца понял каокго) с режимом совместной работы и постоянной синхронизацией. Приложение реализовано на React и команда решила попробовать подключить react compiler в свой проект.

Если совсем коротко: Sanity Studio подключили react compiler и он обнаружил проблемы в коде и ускорил рендер приложения.

Storybook 8.4
Вышел Storybook 8.4. Основные фичи: улучшения компонентных тестов, уменьшение размера бандла, поддержка svelte 5, поддержка React Native, поддержка тэгов в историях

Теперь давайте разберем по-подробнее

Will we care about frameworks in the future?
Заметка об использовании AI в разработке и о том как это может повлиять на индустрию. Здесь только мысли, без примеров кода или каких-то серьезных аргументов. Но мысли, подобные описанным в статье, в последнее время посещают и меня.

Нужны ли нам фреймворки, если большинство кода будут писать нейронки, а они спокойно пишут код и без фреймворков ? Фреймворки решают разные проблемы, но многие из них связаны в первую очередь с когнитивными ограничениями человека. У нейронок нет таких ограничений (есть правда другие, но не об этом разговор). Нейронке норм копипастить код, или напрямую работать с DOM, вместо инициализации кучи обвязки из фреймворков. Нейронка не боится писать бойлерплейт. Мы - люди, так не делаем - мы стараемся не дублировать логику и использовать высокоуровневые абстракции, чтобы снизить когнитивную нагрузку.

LLMs as a tool for thought
Еще одна статья о нейронках. На этот раз еще менее техническая, чем предыдущая.

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

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

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

LLMs as a tool for thought

Еще одна статья о нейронках. На этот раз еще менее техническая, чем предыдущая.

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

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

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

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

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

https://wattenberger.com/thoughts/llms-as-a-tool-for-thought

#development #llm #thoughts

Will we care about frameworks in the future?

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

Нужны ли нам фреймворки, если большинство кода будут писать нейронки, а они спокойно пишут код и без фреймворков ? Фреймворки решают разные проблемы, но многие из них связаны в первую очередь с когнитивными ограничениями человека. У нейронок нет таких ограничений (есть правда другие, но не об этом разговор). Нейронке норм копипастить код, или напрямую работать с DOM, вместо инициализации кучи обвязки из фреймворков. Нейронка не боится писать бойлерплейт. Мы - люди, так не делаем - мы стараемся не дублировать логику и использовать высокоуровневые абстракции, чтобы снизить когнитивную нагрузку.

Я думаю, что в ближайшие несколько лет индустрия разработки претерпит значительные изменения. Мое имхо: работа "кодера" уже не будет так цениться, будут цениться способности проектировать системы, а 80% кода будут писать нейронки. Я бы сказал, что под риском сейчас все те, кто считают что в задаче должно быть все четко описано: что делать, как делать, какие таблицы в БД нужны, какие контракты надо реализовать, должны быть все макеты, а разработчик лишь пишет код, т.е. работает как преобразователь ТЗ в код. Такое скоро будет заменено нейронками.

https://paul.kinlan.me/will-we-care-about-frameworks-in-the-future/

#development #llm #thoughts

Storybook 8.4

Вышел Storybook 8.4. Основные фичи: улучшения компонентных тестов, уменьшение размера бандла, поддержка svelte 5, поддержка React Native, поддержка тэгов в историях

Теперь давайте разберем по-подробнее

Самый крутой апдейт релиза, на мой взгляд, называется Component Test in 1 click. Storybook много усилий вкладывает в использование инструмента в целях тестирования. В данном релизе добавили удобные кнопки в UI-сторибука для запуска разных видов тестов прямо из интерфейса (ui-тесты (chromatic), компонентные тесты, тесты доступности). Лучше, конечно, посмотреть гифку в блоге, чтоб посмотреть на то, как работает эта фича. Выглядит хорошо.

Следующий большой поинт - оптимизация бандла. Теперь storybook весит на 50% меньше, по сравнению с 8.0. Эта работа делалась итеративно и каждый следующий релиз становился все меньше. В посте также есть картинка, которая показывает изменение графа модулей по релизам - выглядит внушительно.

За счет чего удалось достичь таких результатов:
- Удалили fs-extra, handlebars, file-system-cache
- Заменили lodash ⇒ es-toolkit, express ⇒ polka,  chalk ⇒ picocolors, qs ⇒ picoquery
- Оптимизации: включение продакшн-мода для react, опциональный prettier
- Бандлинг: Vite builder , React renderer , Addon-docs 

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

Перейдем далее: React Native поддерживался в storybook 7, но поддержку для storybook 8 добавили только сейчас. Собираются и далее поддерживать совместимость с React Native

Другая полезная фича: тегирование историй. Если у вас большой сторибук, то бывает сложно там навигироваться. Да, там есть поиск по названию истории, но бывает так, что мы хотим выделить все истории, которые связаны с чем-то определенным, а сделать это невозможно. Теперь в Storybook появилась возможность указывать теги у истории и фильтровать истории по ним. Также можно визуализировать теги в виде беджей. Как юзкейсы, которые предлагает сам Storybook в посте: выделение новых компонентов (бейдж New! рядом с историей в навигации) и ведение версий (бейдж v1.0.0 рядом с историей в навигации)

https://storybook.js.org/blog/storybook-8-4/

#development #javascript #storybook #release #componentTests #svelte5

Adopting the compiler in Sanity Studio

Sanity Studio - приложение для создания и редактирования контента (не до конца понял каокго) с режимом совместной работы и постоянной синхронизацией. Приложение реализовано на React и команда решила попробовать подключить react compiler в свой проект.

Если совсем коротко: Sanity Studio подключили react compiler и он обнаружил проблемы в коде и ускорил рендер приложения.

Я сразу признаюсь, что не до конца вкурил про что там челы пишут (т.к. до сих пор не до конца понимаю что такое react compiler). Но основные поинты такие:
- eslint-plugin-react-compiler хорошо работает как детектор багов. Он находит места, которые работают неправильно
- babel-plugin-react-compiler вскрывает проблемы react-кода приложения

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

Также ребята инженерно подошли к включению компайлера в код и замерили, насколько ускорился рендер приложения. Для тестов перформанса они используют свои юзкейсы - скорость редактирования контента. Разные кейсы ускорились по разному, но в целом ускорение составило от 5% до 33%, что весьма внушительно.

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

В общем, звучит круто. Какие советы дает автор:
- Подключайте eslint-plugin-react-compiler и фиксите баги
- Подключайте babel-plugin-react-compiler на тестовых стендах чтоб убедиться, что приложение стало работать лучше и нет багов
- Используйте react-compiler-runtime чтобы ускорить приложение
- Инкрементально рефакторите код, который компилятор пропускает


https://github.com/reactwg/react-compiler/discussions/33

#development #javascript #react #reactCompiler #react18

Uncontrolled or controlled: A matter of perspective

Статья, разбирающая смысл термином Controlled Component и Uncontrolled Component. В целом, ничего нового, но разбор короткий и понятный

Давайте разберем на небольшом примере

Пример uncontrolled компонента

function Page() {
  return <input name="search" />;
}

Пример controlled компонента

function Page() {
  const [search, setSearch] = useState('');

  return (
   <> 
    <input
      value={search}
      onChange={(e) => setSearch(e.target.value)}
      name="search"
    />
    
    <button onClick={() => setSearch('')}>Clear</button>
   </>
  );
}

В первом примере input, с точки зрения Page, является uncontrolled компонентом т.к. Page не контролирует состояние и работу input'а - input работает сам. Во втором примере и значение и обработка работы input'а контролируется компонентом Page

Это достаточно тривиальный пример

Давайте возьмем Counter вместо нативного инпута

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <>
      <button onClick={() => setCount(count - 1)}>-</button>
      <div>{count}</div>
      <button onClick={() => setCount(count + 1)}>+</button>
    </>
  );
}

Это controlled или uncontrolled компонент? Чтобы понять это, надо посмотреть на компонент с точки зрения того, кто его использует

function App() {
  return <Counter />;
}

С точки зрения App такой Counter - uncontrolled, т.к. он работает сам по себе и на его работу нельзя повлиять

Но Counter можно реализовать и как controlled компонент. В этом случае с точки зрения App код должен получиться примерно такой

function App() {
  const [count, setCount] = useState(0);

  return (
    <>
      <Counter value={count} onChange={setCount} />

      <p>App state: {count}</p>

      <button onClick={() => setCount(0)}>Reset</button>
    </>
  );
}

А можно пойти еще дальше и сделать так, чтобы Counter мог работать и как controlled компонент и как uncontrolled компонент. Если ему прокинули пропсы - значит будет работать как controlled, иначе - uncontrolled.

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

https://buildui.com/posts/uncontrolled-vs-controlled-a-matter-of-perspective

#development #javascript #react #controlledComponents

Дайджест за 2024-11-18 - 2024-11-22

setImmediate() vs setTimeout() in JavaScript
Хороший разбор того, как в NodeJS работает event-loop на примере разбора порядка вызовов setTimeout и setImmediate.

В коментариях к посту указали, что статья не совсем точная. Поэтому если решите почитать статью - почитайте и комментарии

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

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

Legacy Modernization meets GenAI
Статья в блоге Мартина Фаулера про то, как они в ThoughtWorks используются нейронки для модернизации всякого легаси.

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

Destroy on Friday: The Big Day 🧨 A Chaos Engineering Experiment – Part 2
Вы когда-нибудь задумывались, что будет, если отключить часть ваших серверов? Скорее всего - нет. А есть целая область знаний, которая посвящена этому - chaos engineering. Chaos engineering - это методика повышения отказоустойчивости систем через искусственное создание крупных сбоев.

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

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

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

Destroy on Friday: The Big Day 🧨 A Chaos Engineering Experiment – Part 2

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

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

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

https://www.honeycomb.io/blog/destroy-on-friday-chaos-engineering-pt2

#development #chaosEngineering

Legacy Modernization meets GenAI

Статья в блоге Мартина Фаулера про то, как они в ThoughtWorks используются нейронки для модернизации всякого легаси.

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

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

В ThoughtWorks придумали сделать систему, которая ускорит этот процесс - CodeConcise. Берется код, преобразуется в AST, анализируются связи между разными файлами на уровне кода (например, модуль А зависит от модуля Б, но только при использовании метода Х). По этой инфе уже работает CodeConcise, внутри которого нейронка

Использование CodeConcise ускоряет разбор легаси модуля с 6 недель до двух.

Что еще пробовали делать с кодом через нейронку:
- Удалять мертвый код - оказалось не очень эффективно, относительно тулов, которые уже есть в индустрии
- Переписывать код с 1го стека на другой - также оказалось не эффективно. Код оказывался низкого качества.

https://martinfowler.com/articles/legacy-modernization-gen-ai.html

#development #martinFowler #chatgpt #ai #refactoring

Организация базы знаний в obsidian

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

Что я имею в виду под знаниями:
- Шпаргалки по использованию инструментов
- Полезные ссылки
- Конспекты и интересные идеи
- MN-ки
- Заметки по проекту или разным областям

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

Самый необычный инструмент для хранения знаний, который я видел, это Trello. Чел (привет Костя) заводил карточку на trello-доске под каждую тему и в ее контенте и комментариях скидывал всякое интересное.

Самые популярные, из тех что я вижу у своих коллег, это notion и встроенные в ОС заметки.

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

В какой-то момент я перешел на работу с markdown-файлами. Почему так:
- Полный контроль над контентом. Это просто файлы - храню где хочу, легко бекапить, легко синхронизировать, можно открыть на любом тостере
- Markdown легко конвертировать в другие форматы. Например, посты в канал я пишу в markdown и телега их принимает. Заметки по работе я тоже пишу в markdown и в confluence есть конвертер из markdown в confluence формат
Конечно же есть и минусы:
- markdown формат весьма ограничен. Приходится, как минимум, отказаться от работы с таблицами
- Тяжело найти инструмент, который оставит полный контроль над файлами и позволит легко шарить эти файлы и работать с ними в режиме совместной работы

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

Obsidian - это приложение, которое создано вокруг идеи Zettelkasten. Сам метод Zettelkasten я не использую т.к. имхо, проблемы, которую решал Zettelkasten уже нет. Obsidian из коробки позволяет работать с папкой с markdown файлами как с базой знаний: можно линковать файлы друг с другом, организовывать вокруг тэгов, быстро рефакторить их (например, вынести часть заметки в другую и тут же оставить ссылку в текущем документе на новую заметку). Также obsidian очень мощный благодаря плагинам от сообщества: их много, они часто немного сыроваты, но в целом хорошо расширяют возможности Obsidian.

Используемые мной плагины:
- Outliner - позволяет удобно работать со списками
- Dataview - позволяет строить запросы по заметкам
- Excalidraw - позволяет рисовать диаграммы прямо в obsidian, используя excalidraw
- Whisper - позволяет наговаривать аудио, которое потом распознается в текст с помощью whisper
- Templater - позволяет создавать заметки по шаблону
- Tasks - добавляет работу с задачами - можно делать запросы в Dataview, ставить дедлайны, связывать задачи
- Meta Bind - позволяет создать удобные кнопки с кастомной логикой
- Advanced Slides - позволяет делать слайды на основе reveal.js. Использую для простых презентаций

С этими плагинами (и еще парочкой мелких) я веду 3 базы знаний:
- По каналу. Вот прям щас пишу в ней пост
- По работе. Там все задачи, заметки, MN-ки, ведение больших проектов, 1:1, слайды
- Личный. Там все общие заметки как по разработке, так и просто житейские. Также там конспекты по книжкам.

База знаний для канала синхронизируется через гит
База знаний по работе только на рабочем ноуте
Личная база знаний синхронизируется по гугл диску

А как вы организуете свою базу знаний?



#note #obsidian #knowledgeManagement

setImmediate() vs setTimeout() in JavaScript

Хороший разбор того, как в NodeJS работает event-loop на примере разбора порядка вызовов setTimeout и setImmediate.

Посмотрите на этот код

setImmediate(() => {
  console.log("setImmediate 1");
});

setTimeout(() => {
  console.log("setTimeout 1");
}, 0);

setTimeout(() => {
  console.log("setTimeout 2");
}, 0);

setImmediate(() => {
  console.log("setImmediate 2");
});

Предположите, в каком порядке пойдет вывод в консоль?

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

setTimeout 1
setImmediate 1
setImmediate 2
setTimeout 2

Почему так происходит? Потому что event loop в NodeJS работает следующим образом:
- Таймеры
- Колбеки IO
- Хендлинг IO
- Check

Когда мы вызываем setTimeout(cb, 0) мы складываем задачу в ивент луп. Задачи берутся по одной и колбек таймаута разберется в фазе таймеров. Затем выполняются IO-фазы, а затем фаза Check. setImmediate как раз выполняется в фазе Check, причем с гарантией, что все задачи этой фазы разберутся сразу после IO.

Поэтому получается так, что
- Из ивентлупа забирается первый таймер
- Исполняется
- Проходит IO
- Выполняется Check, в рамках которого выполняются все setImmediate
- Goto start

При этом, если мы поставим таймер и immediate в рамках колбека IO, то можно получить другой результат

const fs = require('fs');

fs.readFile('example.txt', () => {
  setTimeout(() => {
    console.log("setTimeout after I/O");
  }, 0);

  setImmediate(() => {
    console.log("setImmediate after I/O");
  });
});

setImmediate after I/O
setTimeout after I/O

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

https://www.trevorlasn.com/blog/setimmediate-vs-settimeout-in-javascript

#development #javascript #setImmediate #setTimeout

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

Crafting a 13KB Game: The Story of Space Huggers
Периодически проходит интересный челлендж - необходимо создать игру на JS, которая поместится в 13кб. Всегда интересно почитать, как люди делают полноценные игры и умещают их в такой крохотный размер.

Данная статья - как раз одна из таких. Автор одной из игр делится тем, как создать такую игру. Здесь не так много технических деталей, связанных с JS, но зато очень много про сам гейм-дизайн и про принятие решений.

Announcing Official Puppeteer Support for Firefox
Наконец-то появилась официальная поддержка firefox в puppeteer. Теперь можно использовать puppeteer для работы с firefox.

Из интересных технических деталей в статье: было два основных варианта для реализации интеграции с puppeteer:

Common Causes of Memory Leaks in JavaScript
Хорошая статья про утечки памяти.

How we shrunk our Javascript monorepo git size by 94%
У статьи очень кликбейтное название. Я сначала подумал, что чуваки комитили node_modules и теперь решили его удалить или что-то в этом роде. Но все оказалось куда интереснее.

Есть команда в Microsoft, которая разрабатываем в большом монорепо на JS. Называется это 1JS, в нем около 20 миллионов строк кода, 2500 пакетов, а клонирование требует 178 гигабайт дискового пространства и некоторые коллеги из Европы (странное уточнение от автора, ну да ладно) не могли его склонировать.

Самые тяжелые NPM пакеты
Одновременно интересная и практически бесполезная таблица с самыми тяжелыми npm пакетами и тем, сколько мирового интернет траффика они потребляют.

Рассчет трафика достаточно простой: берем вес tar.gz пакета, берем количество загрузок в неделю, перемножаем, получаем трафик в неделю

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

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

Самые тяжелые NPM пакеты

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

Рассчет трафика достаточно простой: берем вес tar.gz пакета, берем количество загрузок в неделю, перемножаем, получаем трафик в неделю

Самый большой трафик создают swc, typescript, next, esbuild, aws-sdk, pnpm, prettier, date-fns

Jquery на 178 месте по трафика. React-dom - 28, сам React - 275.

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



https://docs.google.com/spreadsheets/d/1oYJxQgMA7lQ6-wNaBKNNDz6vr3Yaa1EDsI_Hakr4ROg/edit?gid=1891857584#gid=1891857584

#development #javascript #npm

How we shrunk our Javascript monorepo git size by 94%

У статьи очень кликбейтное название. Я сначала подумал, что чуваки комитили node_modules и теперь решили его удалить или что-то в этом роде. Но все оказалось куда интереснее.

Есть команда в Microsoft, которая разрабатываем в большом монорепо на JS. Называется это 1JS, в нем около 20 миллионов строк кода, 2500 пакетов, а клонирование требует 178 гигабайт дискового пространства и некоторые коллеги из Европы (странное уточнение от автора, ну да ладно) не могли его склонировать.

История про клонирование 178 гигабайт звучит очень странно т.к. я точно помню, что microsoft делала свою файловую систему для работы с огромными гит-репозиториями, которая решает проблему клонирования "лишних" файлов. Ну, видимо в репозитории 1JS это не так.

В репозитории есть 2 основных ветки - mainи versioned. В первой ведется разработка, во второй ведутся релизы. По сути ветка versioned хранит в себе изменения CHANGELOG.md и CHANGELOG.json. На удивление, обнаружилось, что именно эти файлы приводят к тому, что в дереве гита приходится хранить дополнительные 125 гигабайт данных.

Почему так? По умолчанию, алгоритм запаковки изменений и снапшотов в git для идентификации файла использует только последние 16 символов названия файла. Поэтому, если изменить repo/packages/foo/CHANGELOG.json, то git будет собирать diff и к repo/packages/bar/CHANGELOG.json (пересчитал символы, у меня получилось что 15 совпадают, а 16 отличается. Либо я не так считаю, либо что-то не так понял). Т.к. это монорепо с 2500 пакетов, то ченджлогов много и git считает дифф каждый к каждому (опять же, если я правильно понял).

Это можно поправить, увеличив окно для сравнения. Для этого ребята добавили возможность регулировать это окно в git for windows. После перепаковки репозитория, размер уменьшился с 178ГБ до 5ГБ.

Очень интересная история с неожиданной развязкой. Никогда бы не подумал что ведение ченджлога может привести к 94% затрат на размер репозитория.

https://www.jonathancreamer.com/how-we-shrunk-our-git-repo-size-by-94-percent/

#development #javascript #performance #monorepo #git #microsoft

Common Causes of Memory Leaks in JavaScript

Хорошая статья про утечки памяти.

Статья начинается с разбора типов памяти в V8.

Есть:
- RSS (Resident Set Size) - все используемая память
- Heap Total - Память выделенная под JS-объекты
- Heap Used - Память, используемая JS-объектами
- External - Память под С++ объекты, прилинкованные к JS объектам
- Array Buffers - Память выделенная под ArrayBuffer. Используется для хранения бинарных данных

Получить текущее использования можно так

console.log('Initial Memory Usage:', process.memoryUsage());

Initial Memory Usage: {
  rss: 38502400,
  heapTotal: 4702208,
  heapUsed: 2559000,
  external: 1089863,
  arrayBuffers: 10515
}

Основные причины утечки памяти:
- Плохая работа с данными. Например, когда данные уже не нужны, а мы все еще их храним (в глобальной переменной или в замыкании)
- Плохая работа с event listeners. Если их не удалять, после того как они стали не нужны, они будут также держать объекты и защищать их от сборки
- Замыкания
- Некорректной использование bind. Например, мы забиндили метод к this, но в методе this не используется. В этом случае из-за bind GC не сможет собрать то, на что забинжена функция (this).
- Циклические зависимости (пример в статье интересный - this.reference = this;

Третья часть статьи описывает, как же профилировать использование памяти в ноде.

Сначала надо запустить процесс с записью лога node --prof server.js
Затем необходимо прочитать лог node --prof-process isolate-0x140008000-42065-v8.log > processed-profile.txt

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

https://www.trevorlasn.com/blog/common-causes-of-memory-leaks-in-javascript

#development #javascript #performance #memoryLeak

Announcing Official Puppeteer Support for Firefox

Наконец-то появилась официальная поддержка firefox в puppeteer. Теперь можно использовать puppeteer для работы с firefox.

Из интересных технических деталей в статье: было два основных варианта для реализации интеграции с puppeteer:
- Использовать WebDriver BiDi протокол. Это штука, которая была стандартизирована еще w3c и поверх нее, как я помню, работает selenium
- Использовать CDP (chrome dev-tools protocol), по которому puppeteer работает с хромом, т.е. по сути надо имплементировать CDP в firefox; Или сделать интеграцию puppeteer с RDP - это аналог CDP но для firefox

Сначала попробовали сделать экспериментальную и ограниченную поддержку CDP в firefox. Но решили что лучше идти в сторону Webdriver BiDi, как более стандартизированная и кросс-браузерная штука.

https://hacks.mozilla.org/2024/08/puppeteer-support-for-firefox/

#development #javascript #puppeteer #firefox

Crafting a 13KB Game: The Story of Space Huggers

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

Данная статья - как раз одна из таких. Автор одной из игр делится тем, как создать такую игру. Здесь не так много технических деталей, связанных с JS, но зато очень много про сам гейм-дизайн и про принятие решений.

Хорошее чтиво на вечер

https://frankforce.com/space-huggers-how-i-made-a-game-in-13-kilobytes/

#development #javascript #game

Дайджест за 2024-11-05 - 2024-11-08

Максим Соснов. Двое за ноутом, не считая copilot’а, или Как внедрить парное программирование
Мое выступление на codefest про парное программирование и его применение в нашей команде.

Please Stop Using Barrel Files
Статья про вред от использования barrel-файлов.

Optimizing SPA load times with async chunks preloading
Небольшая статья про оптимизацию загрузки асинхронных чанков в SPA-приложении.

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

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

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

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

React Switchboard

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

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

https://github.com/coryhouse/react-switchboard

#development #javascript #react #library

Optimizing SPA load times with async chunks preloading

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

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

Если сильно утрировать, то в коде проекта есть что-то типа:

const routes = {
    '/': import('pages/main'),
    '/search': import('pages/search')
}

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

Примерно та же проблема есть и при навигации. Пользователь делает действие, которое должно перекинуть его на страницу search и снова ждет загрузки скрипта.

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

5 простых шагов для реализации идеи:
- Добавляем имена чанкам import(/* webpackChunkName: "main" */ "./pages/main")
- Пишем плагин (в случае автора - плагин для RSPack)
- Плагин получает стату сборки и из нее достает ссылку до именованного чанка
- В проекте заводится способ нахождения имени чанка по текущему урл
- Плагин инжектит скрипт в head, который на основе window.loocation.href находит нужное имя чанка и инжектит ссылку до чанка в link rel=preload.

Таким образом достигается ускорение загрузки страниц.

Как альтернатива, достойная отдельная статьи, упоминается предзагрузка на стороне сервис-воркера.

https://mmazzarolo.com/blog/2024-08-13-async-chunk-preloading-on-load/

#development #javascript #performance

Please Stop Using Barrel Files

Статья про вред от использования barrel-файлов

Немного контекста, что такое barrel file. Это когда у нас есть папка dir с файлами someFile1.ts и someFile2.ts.
Мы могли бы импортировать их так

import { someFunction } from 'dir/someFile'
import { someFunction2 } from 'dir/someFile2'

Но есть паттерн barrel (в переводе бочка) файлов, когда мы в папке dir создаем index.ts, который ре-экспортит все внутренние сущности

dir/index.ts

export { someFunction } from './someFile'
export { someFunction2 } from './someFile2'

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

import { someFunction, someFunction2 } from 'dir'

Какие минусы выделяет автор у таких файлов:

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

Второй минус уже более близок к реальности - barrel-file ведут к замедлению перформанса инструментов сборки. Когда в тулинге сборки появилась оптимизация по выбросу неиспользуемых экспортов, в сознании разработчиков это отпечаталось как "если я не использую экспорт, его стоимость для сборки - нулевая". Однако, это не так. Если вы используете jest для юнит-тестов, то вы напрямую можете столкнуться с этой проблемой, т.к. jest не занимается три-шейкингов и если вы импортируете 1 маленькую функцию из barrel-файла - вы, на самом деле, импортируете весь модуль.

Автор приводит в пример свой проект, где замена импортов на прямые ускорила сборку на 70% (также могу подтвердить такое по своему опыту борьбы с jest).

Также автор приводит в пример опыт Next.js, которые для борьбы с этой проблемой сделали фичу optimizePackageImports, которая заменяет импорты из barrel-файлов на прямые импорты во время сборки

Не смотря на минусы, такие файлы могут быть полезны, если используются по назначению: для организации публичного API библиотеки

https://tkdodo.eu/blog/please-stop-using-barrel-files

#development #javascript #barrelFile

Давно не делился папками с телеграм каналами 🙃

Тут завели новую тг-папку, называется "Архитектура", но это обманчивое название - там много каналов от фронтенд-разработчиков (в том числе этот канал) 😁

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

https://t.me/addlist/Pk3F9xr4il5lZTc6

Максим Соснов. Двое за ноутом, не считая copilot’а, или Как внедрить парное программирование

Мое выступление на codefest про парное программирование и его применение в нашей команде.

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

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

https://www.youtube.com/watch?v=T14D2GVHGgw&list=PL8761XQAJnrb2Z-Q50OocgfyAyAMlDDEs&index=14
https://vk.com/video/@codefest/playlists?z=video-65336816_456239569%2Fclub65336816%2Fpl_-65336816_29

#development #pairProgramming #extremeProgramming #codefest #speech

Дайджест за 2024-10-28 - 2024-10-31

pretty-print
pretty-print - библиотека для удобного вывода в консоль любых JS-значений. Когда делаешь обычный console.log по большим объектам, то там легко наступить на кейс, когда в каком-нибудь поле выведется Object object. Эта "проблема" решается с помощью JSON.stringify, но либа предлагает еще кучу всякого и удобного

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

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

Логично сделать что-то типа expect(notification).not.toBeInTheDocument(). Но что, если нотификашка появляется не сразу?

ECMAScript proposal updates 2024-10
Пришел октябрьский апдейт по пропозалам в EcmaScript.

В 4 стейдж перешли Promise.try, Import Attributes, RegExp Modifiers, Sync Iterator helpers, JSON Modules

Announcing Deno 2
Вышел Deno 2.0. Сделали аж целое часовое видео про то, какой Deno крутой. Сам видос начинается с немного кринжовой рекламы про то, как тяжело разработчикам без Deno и как хорошо с Deno.


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

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

Announcing Deno 2

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

Что нового в Deno 2 (согласно статье):
- Обратная совместимость с nodejs и npm (можно запустить свое node.js приложение в deno без дополнительных усилий)
- Поддержка package.json и node_modules
- Свой менеджер пакетов - deno install, deno add, deno remove
- Стандартная библиотека (вместо десятка пакетов из npm)
- Поддержка приватных реджистри
- Поддержка воркспейсов и монорепо
- LTS-релизы
- JSR - свой модный реджистри пакетов

Также улучшили много существующих фичей:
- deno fmt теперь умеет в HTML, CSS, YAML
- deno lint теперь умеет в специфику Node
- deno test теперь поддерживает тесты, написанные с помощью node:test
- deno task запускает скрипты из scripts
- deno doc - улучшили вывод
- deno compile - поддерживает подпись и иконки для Windows
- deno serve теперь умеет запускать сервер на нескольких ядрах
- deno init позволяет инициализировать библиотеки и сервера
- deno jupyter теперь поддерживает изображения, графы и HTML
- deno bench теперь более точно замеряет
- deno coverage теперь умеет отдавать вывод в HTML

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

#development #javascript #deno #release

ECMAScript proposal updates 2024-10

Пришел октябрьский апдейт по пропозалам в EcmaScript.

В 4 стейдж перешли Promise.try, Import Attributes, RegExp Modifiers, Sync Iterator helpers, JSON Modules

Promise.try
Позволяет завернуть колбек в промис
До Promise.try

await new Promise((resolve) => resolve(fn()))

С Promise.try

await Promise.try(fn)

Import Attributes
Позволяет указать мета-информацию для импортов

import json from "./foo.json" with { type: "json" };
import("foo.json", { with: { type: "json" } });

RegExp Modifiers
Модификаторы RegExp (например i, m и другие) теперь можно использовать и в под-выражениях
Пример из доки (внимание на группы, внутри которых используется i)

const re1 = /^[a-z](?-i:[a-z])$/i;
re1.test("ab"); // true
re1.test("Ab"); // true
re1.test("aB"); // false

const re2 = /^(?i:[a-z])[a-z]$/;
re2.test("ab"); // true
re2.test("Ab"); // true
re2.test("aB"); // false

Sync Iterator helper
Добавляет удобные методы (map, filter, take, flatMap, reduce, toArray, forEach , some , every, find, from) для работы с итераторами
Пример

function* naturals() {
  let i = 0;
  while (true) {
    yield i;
    i += 1;
  }
}

const result = naturals()
  .take(5)
  .reduce((sum, value) => {
    return sum + value;
  }, 3);

result // 13

В stage-3 перешел Atomics.pause. Этот метод позволяет указать, что треду следует встать на короткую паузу. Это позволяет более оптимально использовать CPU

В stage-2.7 перешли: Error.isError и Iterator Sequencing

Error.isError решает ту же проблему что и Array.isArray, а именно создание инстансов Ошибки в разных контекстах (например, iframe имеет полностью свой контекст и там свой класс Error, поэтому проверка ошибки на instanceof Error в родительском контексте выведет false т.к. в родительском контексте есть свой класс Error)

Iterator Sequencing добавляет API для объединения итераторов.
Например, у вас есть 2 итератора и вы между ними еще хотите добавить значений. Сейчас самый удобный способ сделать это

let lows = Iterator.from([0, 1, 2, 3]);
let highs = Iterator.from([6, 7, 8, 9]);
let digits = function* () {
  yield* lows;
  yield 4;
  yield 5;
  yield* highs;
}();

Array.from(digits); // [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

А будет

let lows = Iterator.from([0, 1, 2, 3]);
let highs = Iterator.from([6, 7, 8, 9]);
let digits = Iterator.concat(lows, [4, 5], highs);

В stage-2 пришли Extractors, structs, iterator chunking

Extractors - это расширение деструктуризации, которое позволяет сразу обработать деструктурированное значение.
Проще всего показать на примере
Сейчас приходится делать так:

const { field: rawField } = data 
const field = process(rawField)

Пропозал позволяет сделать так

const processData({ field }) = data

Ну и пример того как сделать простую деструктуризацию в этом пропозале

class C {
  #data;
  constructor(data) {
    this.#data = data;
  }
  [Symbol.customMatcher](subject) {
    return #data in subject && [this.#data];
  }
}

const subject = new C({ x: 1, y: 2 });

const C({ x, y }) = subject;
x; // 1
y; // 2

structs добавляет структуры в язык. Это более строгая версия классов. Эта штука нужна для повышения производительности (в том числе для кейсов с воркерами)

struct Box {
  constructor(x) { this.x = x; }
  x;
}

let box = new Box(0);
box.x = 42;  // x is declared
assertThrows(() => { box.y = 8.8; });        // structs are sealed
assertThrows(() => { box.__proto__ = {}; }); // structs are sealed

iterator chunking - мега простой пропозал, позволяет нарезать итератор на куски

const digits = () => [0, 1, 2, 3, 4, 5, 6, 7, 8, 9].values();
let chunksOf2 = Array.from(digits().chunks(2));
// [ [0, 1], [2, 3], [4, 5], [6, 7], [8, 9] ]

https://ecmascript-daily.github.io/ecmascript/2024/10/12/ecmascript-proposal-update

#development #javascript #ecmascript #proposal

Inverse Assertions

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

Логично сделать что-то типа expect(notification).not.toBeInTheDocument(). Но что, если нотификашка появляется не сразу?

Можно поставить какой-нибудь sleep. Лично я во всех проектах делаю утилку const wait = (msec) => new Promise(resolve => setTimeout(resolve, msec)), который, по сути, и есть sleep и вызывается как await wait(1000). Проблема с таким подходом, что мы либо подбираем эмпирически нужное значение ожидания, либо завязываемся на детали реализации (т.е. должны знать через сколько примерно появляется нотификашка)

Как же делать правильно. В testing-library есть waitFor - функция резолвнет промис, как только её колбек пройдет

Например

await waitFor(() => {  
  expect(notification).toBeVisible()  
})

Сам waitFor в данном случае очень полезен - мы просто пишем что ожидаем какого-то условия и это позволяет нам отвязаться от деталей реализации, а также гарантирует что мы не будем ждать лишнее время (как в случае со sleep)

Но тут нам мешает, что waitFor ожидает успешного колбека. Т.е. если мы напишем

await waitFor(() => {
    expect(notification).not.toBeInTheDocument()
})

То waitFor завершится сразу же, хотя нотификашка может появиться позже.

Решение здесь - инвертировать проверку

const notificationVisiblePromise = waitFor(() => {
    expect(notification).toBeVisible()
})
 
// Assert that the notification promise has, eventually, rejected.
await expect(notificationVisiblePromise).rejects.toThrow()

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

https://www.epicweb.dev/inverse-assertions

#development #javascript #testingLibrary #testing #assertions

pretty-print

pretty-print - библиотека для удобного вывода в консоль любых JS-значений. Когда делаешь обычный console.log по большим объектам, то там легко наступить на кейс, когда в каком-нибудь поле выведется [Object object]. Эта "проблема" решается с помощью JSON.stringify, но либа предлагает еще кучу всякого и удобного

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

https://www.npmjs.com/package/@parischap/pretty-print

#development #javascript #library #console

Дайджест за 2024-10-21 - 2024-10-25

Unleash JavaScript's Potential with Functional Programming
Еще одна статья про функциональное программирование в JS. Данная статья представляет собой гайд, который погружает вас в функциональное программирование шаг за шагом.

Объяснение начинается с определений - что такое примитив, что такое композируемая сущность, что такое функция и из чего она состоит и тд и тп. Заканчивается все применением каррирования.

⭐️SVG Coding Examples: Useful Recipes For Writing Vectors By Hand
Огромный гайд по рисованию SVG в JS на Smashing Magazine.

Начинается все с основ: что за поле используется в SVG, как управлять его размером, что с единицами измерения. Затем гайд переходит в варианты создания простых svg примитивов (линии, квадраты, окружности, овалы) в JS, затем переходит к более сложным техникам (полигоны, паттерны).

How Bun supports V8 APIs without using V8 (part 1)
Команда разработки Bun рассказывают, как они поддерживают API V8 (движок гугл хрома) без использования V8. Bun стремиться быть совместимым с nodejs API, чтобы любой nodejs код можно было запускать в bun. Если nodejs для каких-то операций использует С++ библиотеки, то bun тоже их использует (или их аналоги). Сложнее обстоят дела с теми кейсами, когда реализация nodejs сделана через вызов V8. В Bun используется не V8 а JavaScriptCore (движок, используемый в safari). Поэтому прост так взять и использовать тоже самое не получается - надо либо найти аналог в JSC и убедиться что он работает также, либо написать свою имплементацию

Собственно про это и статья. В статье рассказывается про подводные камни такого подхода. 2 практических идентичных куска кода на С++ будут вести к разным результатам при использовании V8 и JSC. Статья подробно рассказывает про часть этих подводных камней с примерами С++ кода.

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

https://github.com/Yonom/assistant-ui

Ultimate Express
Ultimate Express - http сервер с полной совместимостью с express, но реализованный на µWebSockets (это веб-сервер написанный на С++). Основная фича (помимо скорости работы) - что это drop-in замена обычному экспрессу. Если вы используется 4 экспресс, все что нужно, это поставить новый пакет npm install ultimate-express и затем по всему коду заменить express на ultimate-express.

Есть несколько ограничений и отличий от обычного express, но они минимальны.

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

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

Ultimate Express

Ultimate Express - http сервер с полной совместимостью с express, но реализованный на µWebSockets (это веб-сервер написанный на С++). Основная фича (помимо скорости работы) - что это drop-in замена обычному экспрессу. Если вы используется 4 экспресс, все что нужно, это поставить новый пакет npm install ultimate-express и затем по всему коду заменить express на ultimate-express.

Есть несколько ограничений и отличий от обычного express, но они минимальны.

На странице в гитхабе представлены 2 бенчмарка перформанса - в одном сравнивается обычный express и ultimate-express. В нем ускорение составляет от 4 до 12 раз. Другой бенчмарк от bun. В этом бенче ultimate-express занимает 3 место среди замеров на node.js (в общем списке он где-то 12)

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

https://github.com/dimdenGD/ultimate-express

#development #javascript #express #httpServer

assistant-ui

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

https://github.com/Yonom/assistant-ui

#development #javascript #react #ai

How Bun supports V8 APIs without using V8 (part 1)

Команда разработки Bun рассказывают, как они поддерживают API V8 (движок гугл хрома) без использования V8. Bun стремиться быть совместимым с nodejs API, чтобы любой nodejs код можно было запускать в bun. Если nodejs для каких-то операций использует С++ библиотеки, то bun тоже их использует (или их аналоги). Сложнее обстоят дела с теми кейсами, когда реализация nodejs сделана через вызов V8. В Bun используется не V8 а JavaScriptCore (движок, используемый в safari). Поэтому прост так взять и использовать тоже самое не получается - надо либо найти аналог в JSC и убедиться что он работает также, либо написать свою имплементацию

Собственно про это и статья. В статье рассказывается про подводные камни такого подхода. 2 практических идентичных куска кода на С++ будут вести к разным результатам при использовании V8 и JSC. Статья подробно рассказывает про часть этих подводных камней с примерами С++ кода.

https://bun.sh/blog/how-bun-supports-v8-apis-without-using-v8-part-1

#development #javascript #bun

SVG Coding Examples: Useful Recipes For Writing Vectors By Hand

Огромный гайд по рисованию SVG в JS на Smashing Magazine.

Начинается все с основ: что за поле используется в SVG, как управлять его размером, что с единицами измерения. Затем гайд переходит в варианты создания простых svg примитивов (линии, квадраты, окружности, овалы) в JS, затем переходит к более сложным техникам (полигоны, паттерны).

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

https://www.smashingmagazine.com/2024/09/svg-coding-examples-recipes-writing-vectors-by-hand/

#development #svg #recommended

Unleash JavaScript's Potential with Functional Programming

Еще одна статья про функциональное программирование в JS. Данная статья представляет собой гайд, который погружает вас в функциональное программирование шаг за шагом.

Объяснение начинается с определений - что такое примитив, что такое композируемая сущность, что такое функция и из чего она состоит и тд и тп. Заканчивается все применением каррирования.

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


https://janhesters.com/blog/unleash-javascripts-potential-with-functional-programming

#development #javascript #functionalProgramming

Дайджест за 2024-10-14 - 2024-10-18

Bundling - Past, Present, and Future
Давненько в канале не было видео-контента. В основном, потому что я сам не люблю видео контент, больше читаю. Но вот есть неплохой видел на английском от создателя Parcel про историю бандлинга в вебе.

Неплохо рассказывается история бандлинга и модульности в JS-экосистеме от AMD модулей и до современных тулов и проблем

Nodejs dev - fastify book
Есть среди подписчиков чел, который делает свои сайты-документашки по популярным инструментам. Они уже попадали в канал. В этот раз появился сайт-документашка по fastify.

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

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

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

⭐️Canon TDD
Статья от Кента Бека (автора TDD) про TDD. Основная проблема TDD в том, что его неправильно понимают и применяют. Кент Бек в очередной раз рассказывает, как правильно применять каноничный TDD.

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

Улучшение производительности рендеринга с помощью CSS content-visibility
Перевод небольшой статьи от автора emoji-picker-element (компонент для выбора эмодзи) про увеличение производительности рендера этого компонента. Каждый эмодзи состоит из двух элементов - button и img. Достаточно простая верстка. Однако, пользователи компонента пожаловались на медленную работу компонента. Оказалось, что у них более 19 тысяч эмодзи в селекте, из-за чего браузер "подвисает" на пару секунд

Для картинок уже использовался loading=lazy, поэтому такой долгий рендер не был связан с загрузкой почти 20 тысяч картинок. Можно было бы добавить виртуализированный список, но это усложняет решение и делает компонент хуже с точки зрения доступности (хотя, конечно, сложно назвать список из 20к элементов доступным в принципе)

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

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

Улучшение производительности рендеринга с помощью CSS content-visibility

Перевод небольшой статьи от автора emoji-picker-element (компонент для выбора эмодзи) про увеличение производительности рендера этого компонента. Каждый эмодзи состоит из двух элементов - button и img. Достаточно простая верстка. Однако, пользователи компонента пожаловались на медленную работу компонента. Оказалось, что у них более 19 тысяч эмодзи в селекте, из-за чего браузер "подвисает" на пару секунд

Для картинок уже использовался loading=lazy, поэтому такой долгий рендер не был связан с загрузкой почти 20 тысяч картинок. Можно было бы добавить виртуализированный список, но это усложняет решение и делает компонент хуже с точки зрения доступности (хотя, конечно, сложно назвать список из 20к элементов доступным в принципе)

Первым делом автор использовал css content-visibility. Это новый фукционал CSS, который позволяет "скрыть" элементы с точки зрения вёрстки и рисования. При этом контент все еще будет доступен в дереве доступности и по нему можно делать поиск по страницу (ctrl+F). Единственное что нужно - уметь предрасчитать размер скрываемых элементов.

После применения content-visibility, прирост в производительности составил 15% - заметно, но не то что ожидалось. Дальнейшее погружение в перформанс показало, что не смотря на loading="lazy", картинки все еще как-то обрабатываются браузером. Следующее решение: заменить img на background-image, но только если элемент с эмодзи появился на экране. Для этого используется IntersectionObserver. Данная техника позволила ускорится на 40%

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

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

#development #css #performance

Canon TDD

Статья от Кента Бека (автора TDD) про TDD. Основная проблема TDD в том, что его неправильно понимают и применяют. Кент Бек в очередной раз рассказывает, как правильно применять каноничный TDD.

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

В этой статье Кент Бек снова рассказывает о каноничном TDD, которое он описывал в своих книжках

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

Шаги по реализации TDD:

1) Список тестов. Первый шаг - описать список всех ожидаемых вариаций нового поведения. При этом не следует думать о том, как это будет работать технически (ОК думать о том, что состояние заказа изменится, но не ОК думать о том, в какие поля БД будут записаны данные).
2) Выберите тест из списка тестов и напишите его. Один тест. Полноценный тест с фазами подготовки, запуска и проверки. Типичные ошибки: писать тесты без проверок; писать сразу кучу тестов.
3) Сделайте так, чтобы тест прошел. Типичные ошибки: удалять проверки; копировать вычисленные значения в проверки; делать рефакторинг в этой фазе (умная мысль на запомнить - "Make it run, then make it right"). Если во время реализации вы понимаете, что нужен еще 1 тест - запишите его в список тестов из списка 1. После того как тест прошел, вычеркните его из списка тестов (он реализован)
4) Опциональный рефакторинг. Типичные ошибки: слишком глубокий рефакторинг, который не требуется сейчас; Слишком раннее создание абстракций
5) Если список те стов еще не пуст, перейдите к пункту 2.

В статье также есть крутая визуализация этого алгоритма.

https://tidyfirst.substack.com/p/canon-tdd

#development #TDD #kentBeck #recommended

Деконструкция монолита: Максимально производительный подход к проектированию программ

Перевод статьи о том, как shopify переходил от монолита к модульному монолиту. Shopify был огромным монолитом на Ruby on Rails, в который на протяжении более десяти лет вносили изменения свыше тысячи разработчиков. В какой-то момент команда осознала, что текущее решение необходимо декомпозировать

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

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

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

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

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

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

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

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

#development #monolith #microservices #modularMonolith

Nodejs dev - fastify book

Есть среди подписчиков чел, который делает свои сайты-документашки по популярным инструментам. Они уже попадали в канал. В этот раз появился сайт-документашка по fastify.

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

https://nodejsdev.ru/frameworks/fastify.3.book/

#development #javascript #nodejs #fastify

Bundling - Past, Present, and Future

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

Неплохо рассказывается история бандлинга и модульности в JS-экосистеме от AMD модулей и до современных тулов и проблем

https://www.youtube.com/watch?v=JUS6EPMbk0U

#development #javascript #bundlers #youtube #video

Дайджест за 2024-10-07 - 2024-10-11

ts-blank-space
Bloomberg заопенсорсили свой компилятор TS в JS. Это, конечно, сложно назвать компилятором - он очень быстро удаляет весь синтаксис TS и оставляет только нативный синтаксис JS.

Сам инструмент максимально простой: парсит AST, находит токены, связанные с TS и заменяет их на пробелы (поэтому blank-space в названии).

stricli
Еще 1 инструммент от Blooomberg. На этот раз - инструмент для создания cli. Основные фичи: поддержка typescript, отсутствие депенденсей, умеет и в ESM и в commonjs, умеет в автокомплит из шела, умеет в код сплиттинг и инъекцию зависимостей

What in Zod's name?
Есть библиотека для валидации по схеме - Zod. Она достаточно популярна, но ошибки валидации от нее сложно воспринимать. Для упрощения разбора ошибок появился zod.fyi - вы вставляете в него текст ошибки, а он выдает вам человекопонятное описание, что же случилось. В целом, наверное, можно закидывать ошибку и в chatGPT.


ESLint now officially supports linting of JSON and Markdown
Eslint продолжает развиваться. На этот раз представили поддержку линтинга json и markdown.

С одной стороны, линтить JSON и markdown не очень то интересно. С другой стороны есть 2 плюса: 1) можно использовать 1 инструмент для линтинга не только кода, но и json и доки на markdown; 2) сделали полноценную поддержку других языков

Announcing VoidZero - Next Generation Toolchain for JavaScript
Evan You (создатель vue, vite и кучи других инструментов) основал компанию, задача которой - создать тулчейн нового поколения для JS. Компания называется VoidZero. В целом, примерно те же цели что и у Rome, но доверия к Evan You намного больше - человек ультра продуктивен и делает действительно крутые инструменты.


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

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

Announcing VoidZero - Next Generation Toolchain for JavaScript

Evan You (создатель vue, vite и кучи других инструментов) основал компанию, задача которой - создать тулчейн нового поколения для JS. Компания называется VoidZero. В целом, примерно те же цели что и у Rome, но доверия к Evan You намного больше - человек ультра продуктивен и делает действительно крутые инструменты.

Что уже было разработано командой Evan You
- Vite, который стал уже основным сборщиком для многих мета-фреймворков
- Самый быстрый JavaScript парсер oxc-parser, в 3 раза быстрее чем SWC
- Самый быстрый Node.js резолвер зависимостей oxc-resolver, в 28x раз быстрее чем enhanced-resolve
- Самый быстрый TS/JSX трансформер oxc-transform, в 4 раза быстрее чем SWC. Не видел его, кстати, в бенчмарке от Блумберга, где они сравнивали свой ts-blank-page
- Самый быстрый линтер oxlint, в 50–100 раз быстрее чем ESLint
- Самый фичастый (в оригинале the most feature-complete) тест-раннер для веб приложений - vitest
- Самый быстрый бандлер Rolldown. Быстрее чем esbuild и другие бандлеры, написанные на Rust

Я верю в то, что у Evan You все получится. Во первых, он уже доказал, что умеет делать крутые тулы. Во вторых, в отличии от Rome, у него уже есть куча инструментов, часть из которых уже популярны - он делает свой тулчейн не на пустом месте

https://voidzero.dev/posts/announcing-voidzero-inc

#development #javascript #EvanYou

ESLint now officially supports linting of JSON and Markdown

Eslint продолжает развиваться. На этот раз представили поддержку линтинга json и markdown.

С одной стороны, линтить JSON и markdown не очень то интересно. С другой стороны есть 2 плюса: 1) можно использовать 1 инструмент для линтинга не только кода, но и json и доки на markdown; 2) сделали полноценную поддержку других языков

Получается, теперь можно писать плагины на eslint для линтинга других языков. Это позволит сообществу сделать плагины для линтинга css, html, всяких svelte и прочих форматов прямо внутри eslint. Что звучит круто

Подключение новых плагинов выглядит вот так

import json from "@eslint/json";

export default [
    {
        plugins: {
            json,
        },
    },

    // lint JSON files
    {
        files: ["**/*.json"],
        language: "json/json",
        rules: {
            "json/no-duplicate-keys": "error",
        },
    },
];

https://eslint.org/blog/2024/10/eslint-json-markdown-support/

#development #javascript #eslint #markdown #JSON

What in Zod's name?

Есть библиотека для валидации по схеме - Zod. Она достаточно популярна, но ошибки валидации от нее сложно воспринимать. Для упрощения разбора ошибок появился zod.fyi - вы вставляете в него текст ошибки, а он выдает вам человекопонятное описание, что же случилось. В целом, наверное, можно закидывать ошибку и в chatGPT.

https://zod.fyi/

#development #javascript #zod #validation

stricli

Еще 1 инструммент от Blooomberg. На этот раз - инструмент для создания cli. Основные фичи: поддержка typescript, отсутствие депенденсей, умеет и в ESM и в commonjs, умеет в автокомплит из шела, умеет в код сплиттинг и инъекцию зависимостей

https://bloomberg.github.io/stricli/

#development #javascript #typescript #bloomberg #cli

ts-blank-space

Bloomberg заопенсорсили свой компилятор TS в JS. Это, конечно, сложно назвать компилятором - он очень быстро удаляет весь синтаксис TS и оставляет только нативный синтаксис JS.

Сам инструмент максимально простой: парсит AST, находит токены, связанные с TS и заменяет их на пробелы (поэтому blank-space в названии).

Зачем это вообще нужно.

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

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

Оригинальный код

class Cat<T> {
  public whiskers: number;
  public tail: T;

  constructor(count: number, tail: T) {
    this.whiskers = count;
    this.tail = tail;
  }
}

throw Error();

Код, скомпилированный TS в esnext

class Cat {
    whiskers;
    tail;
    constructor(count, tail) {
        this.whiskers = count;
        this.tail = tail;
    }
}
throw Error();

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

ts-blank-space компилирует код в такой вариант

class Cat    {
         whiskers        ;
         tail   ;

  constructor(count        , tail   ) {
    this.whiskers = count;
    this.tail = tail;
  }
}

throw Error();

Как видите, вся специфика TS была заменена на пробелы, все значимые токены остались на своих местах. Это позволяет упростить дебаг: stacktrace ошибок всегда указывает на ту же строчку и колонку, на которой стоит конструкция в оригинальном коде; также упрощается сбор сорс-мапов. Если код меняется, то сорсмапы, грубо говорят, содержат мапинг вида "вот была строчка 10 колонка 11, теперь она строчка 7, колона 8". С использованием ts-blank-space сорсмапы описываются 1 строчкой //# sourceURL=cat.ts

Простота инструмента позволяет ему быть быстрым: по бенчмаркам блумберга, если не учитывать работу с AST для сорс-мапов, то ts-blank-space уступает лишь esbuild и @swc/core. Если же учитывать мапинг сорс-мапов, то ts-blank-space является самым быстрым тулом

Простота инструмента также и ограничивает его. Поддерживается на весь синтаксис TS:
- не поддерживаются неймспейсы (declare namespace поддерживается)
- не поддерживается специфика commonJS
- енамы (declare enum поддерживается)
- Свойства класса, объявляемые в конструкторе constructor(public prop) {}

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

https://bloomberg.github.io/ts-blank-space/

#development #javascript #typescript #bloomberg #compiler

Сегодня и завтра я на Frontendconf 2024. Завтра буду рассказывать свой доклад "релизим без стресса" про то, как применять лучшие инженерные практики и быть уверенными, что релиз пойдёт гладко.

Если вы на frontendconf 2024, приходите слушать.
Если вы не на конференции - новости пойдут в канал либо с пятницы, либо со следующей недели.

А ещё скоро появится публичная ссылка моего выступления с codefest про парное программирование, также скину в канал.

Дайджест за 2024-09-16 - 2024-09-20


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

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

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

How I Created a 3.78MB Docker Image for a JavaScript Service
Чем бы ты не занимался, всегда найдется азиат, который сделает это круче.

Так произошло и с докер-образами для JS-сервисов. Чела не устраивало, что все текущие образы весят 50+ МБ, вне зависимости от рантайма, и тогда он сделал свой докер-образ, который весит 3.7МБ.

Exploring Goja: A Golang JavaScript Runtime
Вот было у вас такое, что вы пишете на golang, и вам не хватает простого человеческого javascript? Теперь ваша боль решена - Goja - js рантайм для Golang

Если без шуток, челу необходимо было запускать JS в рамках Golang приложения. Конкретного кейса автора я не понял, но в целом могу выдумать несколько интересных: запуск JS-кода в контролируемом рантайме (для спортивного программирования например), описание сложных правил в UI на JS, а исполнение правил - на сервере на golang.

⭐️How to Use React Compiler – A Complete Guide
Огромная статья, рассказывающая про то, как работает React Compiler. Статья рассказывает, из чего состоит React Compiler как внутри себя, так и через какие инструменты он подключается в проект.

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

Multithreading in Node.js: Using Atomics for Safe Shared Memory Operations
Статья про многопоточность в nodejs и про atomics API.

Основная проблема мульти-поточности, это race-conditions.

Mutation-testing our JavaScript SDKs
Статья от Sentry, про применение мутационного тестирования в Sentry. Если коротко, мутационное тестирование - это когда инструмент меняет немного ваш код (создает мутанта) и ожидает, что тесты отловят это изменение. Мутанты при этом создаются тысячами, поэтому этот процесс весьма ресурсо-затратен. Однако и результаты всегда однозначны - если мутант выжил, значит вы что-то не протестировали. По сути мутационное тестирование оценивает качество ваших тестов, а не вашего кода. Есть и минусы - не всегда мы хотим писать столько тестов, сколько нужно для набора 100% скора (например, как часто вы в своих тестах проверяете, что вам реально в catch прилетел instanceof Error, а не какой-то кастомный клас?)

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

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

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

Mutation-testing our JavaScript SDKs

Статья от Sentry, про применение мутационного тестирования в Sentry. Если коротко, мутационное тестирование - это когда инструмент меняет немного ваш код (создает мутанта) и ожидает, что тесты отловят это изменение. Мутанты при этом создаются тысячами, поэтому этот процесс весьма ресурсо-затратен. Однако и результаты всегда однозначны - если мутант выжил, значит вы что-то не протестировали. По сути мутационное тестирование оценивает качество ваших тестов, а не вашего кода. Есть и минусы - не всегда мы хотим писать столько тестов, сколько нужно для набора 100% скора (например, как часто вы в своих тестах проверяете, что вам реально в catch прилетел instanceof Error, а не какой-то кастомный клас?)

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

Ожидаем продолжения, где ребята поделятся результатами трекинга скора мутационного тестирования.

https://sentry.engineering/blog/js-mutation-testing-our-sdks

#development #javascript #testing #mutationTesting #sentry

Multithreading in Node.js: Using Atomics for Safe Shared Memory Operations

Статья про многопоточность в nodejs и про atomics API.

Основная проблема мульти-поточности, это race-conditions.

Для визуализации проблемы можно взять следующий пример. У нас есть приложение, которое запускает 2 воркера и передает им одни и те же данные

Код приложения и воркера

import { Worker, isMainThread, workerData, threadId } from 'node:worker_threads';

// код приложика
if (isMainThread) { 
  const buffer = new SharedArrayBuffer(1);
  new Worker(import.meta.filename, { workerData: buffer });
  new Worker(import.meta.filename, { workerData: buffer });
} else {
// код воркера
  const typedArray = new Int8Array(workerData);
  typedArray[0] = threadId;
  console.dir({ threadId, value: typedArray[0] });
}

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

Однако практика показывает, что это не так

# 1 type of results
{ threadId: 1, value: 2 }
{ threadId: 2: value: 2 }

# 2 type of results
{ threadId: 1, value: 1 }
{ threadId: 2: value: 1 }

# 3 type of results
{ threadId: 1, value: 1 }
{ threadId: 2: value: 2 }

ОС может передать процессорное время в другой тред после того, как тред записал данные в массив, но до того, как тред вывел свои данные в консоль

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

В JS для эксклюзивного и безопасного доступа к шареной памяти используется atomics. В данном кейсе автор разбирает использование store и load для блокирующего доступа к памяти, что не до конца решается кейс, но уже делает лучше.

const typedArray = new Int8Array(workerData);
Atomics.store(typedArray, 0, threadId);
const value = Atomics.load(typedArray, 0);
console.dir({ threadId, value });

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

https://pavel-romanov.com/multithreading-in-nodejs-using-atomics-for-safe-shared-memory-operations

#development #javascript #nodejs #multiThreading #atomics

How to Use React Compiler – A Complete Guide

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

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

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

https://www.freecodecamp.org/news/react-compiler-complete-guide-react-19/

#development #javascript #react #reactCompiler #recommended

Exploring Goja: A Golang JavaScript Runtime

Вот было у вас такое, что вы пишете на golang, и вам не хватает простого человеческого javascript? Теперь ваша боль решена - Goja - js рантайм для Golang

Если без шуток, челу необходимо было запускать JS в рамках Golang приложения. Конкретного кейса автора я не понял, но в целом могу выдумать несколько интересных: запуск JS-кода в контролируемом рантайме (для спортивного программирования например), описание сложных правил в UI на JS, а исполнение правил - на сервере на golang.

Автор смотрел в сторону разных вариантов запуска JS в рамках Golang, но остановился на Goja. Основное преимущество Goja - это бесшовная связка структур в Golang со структурами JS.

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

На последок, закину сниппет кода, который использует Goja

package main

import (
 "fmt"

 "github.com/dop251/goja"
)

func main() {
 vm := goja.New()

 // Passing an array of integers from 1 to 100
 values := []int{}
 for i := 1; i <= 100; i++ {
  values = append(values, i)
 }

 // Define the JavaScript code to filter even values
 script := `
  values.filter((x) => {
   return x % 2 === 0;
  })
  `

 // Set the array in the JavaScript runtime
 vm.Set("values", values)

 // Run the script
 result, err := vm.RunString(script)
 if err != nil {
  panic(err)
 }

 // Convert the result back to a Go slice of empty interfaces
 filteredValues := result.Export().([]interface{})

 fmt.Println(filteredValues)
 // Outputs: [2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 60 62 64 66 68 70 72 74 76 78 80 82 84 86 88 90 92 94 96 98 100]

 first := filteredValues[0].(int64)
 fmt.Println(first)
}

https://jtarchie.com/posts/2024-08-30-exploring-goja-a-golang-javascript-runtime

#development #javascript #runtime

How I Created a 3.78MB Docker Image for a JavaScript Service

Чем бы ты не занимался, всегда найдется азиат, который сделает это круче.

Так произошло и с докер-образами для JS-сервисов. Чела не устраивало, что все текущие образы весят 50+ МБ, вне зависимости от рантайма, и тогда он сделал свой докер-образ, который весит 3.7МБ.

Чтобы сделать такой худой образ, автор использует LLRT как рантайм. Это рантайм, который развивает AWS, если я правильно помню. Создан поверх движка QuickJS.

Т.к. llrt весит так мало не просто так (а потому что многое там упрощено и многого там просто нет), то пришлось немножко адаптировать свое приложение. Например, переписать часть, связанную с http сервером.

Итоги:
- Докер образ стал весить меньше
- Приложение быстрее стартует
- Приложение медленее работает
- Автор в целом рекомендует оставаться на nodejs для большинства кейсов.

https://shenzilong.cn/record/How%20I%20Created%20a%203.78MB%20Docker%20Image%20for%20a%20JavaScript%20Service

#development #javascript #docker

Дайджест за 2024-09-09 - 2024-09-13

⭐️Особенности Effector, которые почему-то никто не обсуждает: опыт ВКонтакте спустя год использования
На Codefest команда ВК рассказывала, как они решили перейти на effector и почему пришлось откатываться. Мне лично доклад сильно понравился, потому что он, по своему смыслу, двух-уровневый: на первом уровне - критика effector, на втором уровне - как выбирать инструменты (отдельно кекнул прям на докладе, что решили выбирать стейт менеджер на основе голосования)

Записи докладов с Codefest еще не обнародовали, но команда VK выпустила статью на ту же тему. Статья уже стала источником небольшой драмы в сообществе (например, можно почитать кучу постов у sergeysova и немножко у artalog).

An SSR Performance Showdown
Немного странный бенчмарк производительности серверного рендеринга разных библиотек. Задача простая: отрисовать спираль из 2398 дивов. В сравнении участвовали fastify-html (простая либка для рендера html из fastify), react, preact, vue, solidjs, svelte.

В явных лидерах (>1000 RPS): fastify-html и vue, далее с небольшим отставанием (>900 RPS) идут svelte и solidjs, завершают рейтинг preact (717 RPS) и react (572 RPS).

В комментах отписаличь, почему бенчмарк - фигня

Announcing Vue 3.5
Анонсирован Vue 3.5. Давно не следил за vue, хотя продолжительно время писал на нём. И вот решил посмотреть что там нового в vue 3.5.

Я, конечно, давно уже не слежу за тем, насколько Vue быстрее или медленнее других библиотек и фреймворков. Но в моей памяти - он считается достаточно быстрым (поправьте в коментах, если это уже давно не так). Тем не менее, в 3.5 уменьшили в 2 раза потребление памяти системой реактивности, а трекинг огромных вложенных массивов ускорился в 10 раз в определенных кейсах

В комментах разные уточнения к посту и перформансу

OpenAI is shockingly good at unminifying code
Небольшая статья, показывающая интересный юзкейс для нейронок. Чувак увидел прикольную ASCII-анимацию на сайте, и захотел узнать как она работает. Как это часто бывает на сайтах - из исходников есть только минифицированный код на React в сорсах страницы.

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

Inside ECMAScript: JavaScript Standard Gets an Extra Stage
Комитет стандартизации Ecmascript добавил еще 1 Stage для предложений по улучшению языка. Между 2 и 3 этапом добавился stage 2.7.

Почему он понадобился: часто большие предложения, попадавшие на Stage 3, разворачивались обратно на Stage 2 т.к. оказывалось, что у предложения есть существенные недостатки, которые не были выявлены ранее. Это означает, что вся работа, сделанная в stage 3, была сделана зря. Чтобы минимизировать подобные кейсы, решили добавить шаг 2.7, в котором уже договорились о том, как все должно работать, но теперь пишут тест-кейсы и валидируют, что это предложение действительно рабочее (если я правильно понял).

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

Также короткий пост о том как я посетил конфу в Томске

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

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

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

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