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

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

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

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

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

Роберт Мартин - чистый код (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

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

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

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

Electrobun

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

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

https://electrobun.dev

#development #javascript #electron #bun #desktop

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

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

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

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

Дайджест за 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 и выделил восходящие звезды (по сути выделили проекты, которые получили больше всего звезд на гитхабе за год). Звезды поделены по категориям: фреймворки, тулинг, Реакт, Бекенд, тестирование и так далее.

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

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

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

A checklist for your tsconfig.json

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

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

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

#development #javascript #typescript #tsconfig

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

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

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

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

Что это означает на практике? В компаниях часто на повышение идут люди, которые добились успеха на своей текущей должности. Однако при повышении могут понадобится другие компетенции, в которых человек уже не так хорош. В 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 (спасибо команде подлодки за этот билет). Подводим итоги розыгрыша во вторник утром.