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

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

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

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

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

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

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

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



#managment #note

Learn Yjs

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

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

https://learn.yjs.dev/

#development #javascript #Yjs

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

Explore Agent Recipes

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

https://www.agentrecipes.com

#development #typescript #ai #llm

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


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

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

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

Running Inference In Web Extensions

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

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

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

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

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



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

#development #javascript #firefox #TransformerJs #ai

Avoiding anys with Linting and TypeScript

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

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

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

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

Разработчик может сам их объявить

function foo(param: any) {}

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

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

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

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


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

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

Announcing Rspack 1.2

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

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

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

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

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

#development #javascript #bundlers #rspack #release

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

Bun 1.2

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

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

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

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

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

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

Ниже примеры использования нового API:
Чтение и запись файла

import { s3 } from "bun";

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

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

import { file } from "bun";

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

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

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

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

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

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

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


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

#development #javascript #bun #releaseNotes

Type Predicate Generator

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

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

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

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

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

Давайте разберем на примере
Для достаточно простого типа

export type User = {
  id: number;
  login: string;
};

Я бы написал руками что-нибудь такое:

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

Генератор же дает такой вывод:

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

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

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

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

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

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

#development #typescript #library #github #generator

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

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

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

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

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

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

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

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

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

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

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

#development #martinFowler #codemod #hypermod #refactoring

Hypermod

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

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

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

https://www.hypermod.io

#development #javascript #typescript #codemod #refactoring

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

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

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

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

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

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

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

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

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

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

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

Docxtemplater

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

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

https://docxtemplater.com

#development #javascript #docx #library

The modern way to write JavaScript servers

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

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

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

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

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

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

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

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

#development #javascript #node