cleaning house in nx monorepo, how i removed 120 unused deps safely

Короткая заметка про то, как автор удалил 120 пакетов-зависимостей (около 25% от всего объема зависимостей в проекте) из монорепо используя knip. Knip - тул, который ищет неиспользуемые зависимости и код.

Сам процесс выпила зависимостей простой:
1. Запустить knip
2. Проверить, что то, что он пометил ненужным - это реально ненужная штука
3. Удалить ненужное
4. Проверить, что все работает
5. Goto 1

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

https://johnjames.blog/posts/cleaning-house-in-nx-monorepo-how-i-removed-120-unused-deps-safely

#development #javascript #nx #knip

How to detect Safari and iOS versions with ease in 2025

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

Если вам нужно отключить какой-то функционал для "старых" версий сафари, то предлагается такой фреймворк:
- Сначала проверьте, доступен ли gestureEvent. Если доступен - это webkit
- Затем найдите релиз ноутсы интересующей вас версии сафари
- в релиз ноутсах найдите фичу, на доступность которой можно написать проверку. Например, если вас интересуют версии сафари от 17 и выше, можно проверить поддержку contain-intrinsic-size
- проверьте, что все правильно работает

Как это выглядит в коде

Определяем что это вебкит

//  Desktop Safari, all mobile WebKit browsers on iOS and webview iOS
function isWebkit() { return "GestureEvent" in window; }

//  all mobile webkit browsers and webview iOS
function isMobileWebKit() { return "ongesturechange" in window; }

//  Desktop Safari
​​function isDesktopWebKit() {
  return (
    typeof window !== 'undefined' &&
    'safari' in window &&
    'pushNotification' in window.safari
  );
}

Определяем что это хотя бы 17 ios

// Use `CSS.supports` in Javascript or `@supports` in CSS to check if the feature is available.
// true on iOS 17.0+ (Safari 17.0+)
const isAtLeastiOS17 = CSS.supports("contain-intrinsic-size", "100px");

И теперь получаем возможность таргетироваться на версию сафари

if(isMobileWebKit()){
  if (isAtLeastiOS17) {
    // Safe to use iOS 17+ features
  } else {
    // Fallback for older iOS versions
  }
}

Иногда проверки могут быть сложнее т.к. проверить наличие поля в window или доступность css-свойства через support - недостаточно. В этом случае предлагается проверять поведение кода или элементов в реальном DOM.

https://evilmartians.com/chronicles/how-to-detect-safari-and-ios-versions-with-ease

#development #javascript #safari #browserDetection

modern-tar

modern tar - библиотека для работы с tar архивами. Работает в nodejs и браузерах. Поддерживает стриминг, создание и распаковку tar-архивов.

https://github.com/ayuhito/modern-tar

#development #javascript #library #github

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

React 19.2
Новый релиз React 19.2 принес достаточно интересные новшества: несколько фич для ускорения рендера или навигации, улучшения в девтулах, новые хуки.

cleaning house in nx monorepo, how i removed 120 unused deps safely
Короткая заметка про то, как автор удалил 120 пакетов-зависимостей (около 25% от всего объема зависимостей в проекте) из монорепо используя knip. Knip - тул, который ищет неиспользуемые зависимости и код.


How to detect Safari and iOS versions with ease in 2025
Статья в блоге злых марсиан о том, как правильно детектить версию ios и safari в коде. Если коротко подвести итог: проверять доступность фич, которые выходили в разных версиях ios и safari, хотя это может быть сложно и немного хрупко.

modern-tar
modern tar - библиотека для работы с tar архивами. Работает в nodejs и браузерах. Поддерживает стриминг, создание и распаковку tar-архивов.

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

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

Speculation Rules at Shopify

Shopify завершил тестирование использования Speculation Rules на своей платформе. Speculation Rules позволяют при загрузке страницы указать браузеру, какие еще файлы или страницы следует предзагрузить и с каким приоритетом. Например, если пользователь открыл корзину, логично предзагрузить ему страницу оплаты, чтобы при переходе на оплату все открылось моментально.

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

https://performance.shopify.com/blogs/blog/speculation-rules-at-shopify

#development #javascript #performance #preload

ffetch

ffetch - ещё одна библиотека для замены нативного fetch в коде. Эта библиотека предоставляет поддержку typescript, таймауты, ретраи с динамическим таймаутом между ретраями, хуки, менеджмент ошибок, мониторинг, circuit breaker и другие фичи. Выглядит недурно - все самое базовое и необходимое для сетевых запросов уже в комплекте.

Пример базового использования

import createClient from '@fetchkit/ffetch'

// Create a client with timeout and retries
const api = createClient({
  timeout: 5000,
  retries: 3,
  retryDelay: ({ attempt }) => 2 ** attempt * 100 + Math.random() * 100,
})

// Make requests
const response = await api('https://api.example.com/users')
const data = await response.json()

https://github.com/fetch-kit/ffetch

#development #javascript #github #fetch

Array.prototype.pushAll

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

Например

arr2.forEach(item => arr.push(item))

// или
arr.push(...arr2)

// или
for(const item of arr2) { arr.push(item)}

Но, как оказывается, есть нюанс.

В случае использования spread оператора arr.push(...arr2) все работает, но, т.к. каждый элемент массива arr2 надо теперь сделать отдельным аргументом, то это влечет за собой необходимость поработать js-движку. И, оказывается, есть обращения в github nodejs, когда чуваки спредят массивы из миллионов элементов и у них падает приложение из-за stack overflow

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

Это, наверняка, обходится с помощью первоначального указания новой длинны массива (arr.length += arr2.length), но это будут помнить малое количество разработчиков.

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


https://github.com/tc39/proposal-bulk-add-array-elements

#development #javascript #tc39

Дайджест за 2025-10-13 - 2025-10-15

Speculation Rules at Shopify
Shopify завершил тестирование использования Speculation Rules на своей платформе. Speculation Rules позволяют при загрузке страницы указать браузеру, какие еще файлы или страницы следует предзагрузить и с каким приоритетом. Например, если пользователь открыл корзину, логично предзагрузить ему страницу оплаты, чтобы при переходе на оплату все открылось моментально.


ffetch
ffetch - ещё одна библиотека для замены нативного fetch в коде. Эта библиотека предоставляет поддержку typescript, таймауты, ретраи с динамическим таймаутом между ретраями, хуки, менеджмент ошибок, мониторинг, circuit breaker и другие фичи. Выглядит недурно - все самое базовое и необходимое для сетевых запросов уже в комплекте.


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


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

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

Bun 1.3

Вышел Bun 1.3. Основные фишки: улучшили поддержку фулстэк-разработки, встроили MySQL и Redis клиенты, улучшили работу с Cookie и роутингом, сделали улучшения для монорепо

Теперь обо всем по порядку

Если вы разрабатывается чисто фронтенд, то теперь достаточно запустить bun './**/*.html' и bun сделает транспиляцию и сборку всех исходников и сразу подтянет HMR. В релиз ноутсах также показывается насколько быстро работает HMR - текст на сайте обновляется мгновенное вместе с редактированием tsx исходника. Выглядит мощно.

Также в bun встроили простой роутинг и стриминг логов с браузера в терминал

import homepage from "./index.html";
import dashboard from "./dashboard.html";
import { serve } from "bun";

serve({
  development: {
    // Enable Hot Module Reloading
    hmr: true,

    // Echo console logs from the browser to the terminal
    console: true,
  },

  routes: {
    "/": homepage,
    "/dashboard": dashboard,
  },
});

Также фулстек приложения можно собирать в исполняемые файлы на разные ОС.

Появились новые хелперы для работы с SQL и новые встроенные DB-клиенты: mysql и redis. Встроенный redis-клиент в разы быстрее внешних библиотек (node-redis и ioredis). По замерам создателей Bun, конечно же. В любом случае - встроенная поддержка популярных СУБД это большой плюс.

Также много работ сделано в менеджере пакетов. В частности - внедрены isolated installs для монореп. Эта настройка делает так, что пакет не сможет достучатся до зависимости, которая не объявлена в его package.json. Эта настройка включена по дефолту. Если нужно вернуть старое поведение необходимо в конфиг bun добавить linker = "hoisted"

Также из интересного: добавили Security Scanner API. Теперь можно устанавливать внешние решения для аудита безопасности пакетов.

Еще сделали большой блок изменений во встроенный в Bun тест-реймворк. Во первых, сделали официальное расширение для VSCode, которое интегрирует bun test в VS Code Test Explorer UI, т.е. тесты можно запускать из UI vscode и там же смотреть результаты. Во вторых - дали явную возможность помечать тесты, как готовые для запуска в параллельном режиме или как требующие последовательного запуска. Это крайне полезно. По умолчанию в параллель запускаются не более 20 тестов, но это значение можно изменить. Важное отличие новой фичи от того, что уже есть в vitest или jest - можно запускать в параллель тесты, написанные в одном файле. Это, конечно, не новая фича (условный ava умеет такое с самого начала, если я правильно помню), но все равно звучит полезно.

Для любителей ATDD или TDD, добавили возможность пометить тест как "ожидается, что упадет". Это полезно, когда вы заранее составляете список тестов, а только потом имплементируете функционал, но при этом в отчете о запуске тестов вы хотите разделить "тест упал" и "функционал еще не реализован".

test.failing("known bug: division by zero", () => {
  expect(divide(10, 0)).toBe(Infinity);
  // This test currently fails but is expected to fail
  // Remove .failing when the bug is fixed
});

test.failing("TDD: feature not yet implemented", () => {
  expect(newFeature()).toBe("working");
  // Remove .failing once you implement newFeature()
});

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

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

#development #javascript #bun #releaseNotes

React Compiler v1.0

Вышел React Compiler v1.0. Его можно поставить и, по заверениям разработчиков, забыть о ручном менеджменте useMemo, useCallback, React.memo в 99% кейсах - теперь эту работу должен забрать на себя React Compiler. В остальных 1% кейсов можно заняться ручной оптимизацией для достижения лучших результатов.

React Compiler уже используется в приложениях. Например в Meta Quest Store - магазин приложений для VR гарнитуры Oculus Quest. Использование React Compiler ускорило работу навигации на 12%, а некоторые взаимодействия ускорились в 2.5 раза.

Штош, ждем посты на хабре и доклады на конфах про то, как люди включили React Compiler и их сайт ускорился или им пришлось потратить неделю на поиск бага.

https://react.dev/blog/2025/10/07/react-compiler-1

#development #javascript #react #reactCompiler

Oxlint JS Plugins Preview

Oxlint представили API для плагинов на JS. При этом есть 2 версии API - частично совместимое с Eslint, что позволяет подключить eslint-правила в oxlint без доп приседаний, и oxlint API, которое позволяет делать более производительные правила.

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

При этом API плагинов для oxlint не сильно отличается от eslint. С миграцией кода с eslint на oxlint вполне справится любая LLM. С точки зрения разрабов oxlint было бы правильно выложить prompt или rules для переписывания правил на основе LLM или AI-агентов.

https://oxc.rs/blog/2025-10-09-oxlint-js-plugins.html

#development #javascript #oxlint #eslint

Node.js 22 Features You Should Be Using

Nodejs 22 стал LTS, а значит пора обновляться и смотреть, чего же там нового принесли в Nodejs.

Основные изменения:
- WebSocket клиент теперь стабильная фича, можно смело переходить на него
- fetch теперь также стабильная фича, можно смело переходить на встроенный fetch
- улучшили модель разрешений. Можно лочить использование файловой системы или env-переменных

node --experimental-permission \
     --allow-fs-read=/app/data \
     --allow-env=NODE_ENV index.js

- Стабилизировали использование require из ES-модулей. Это должно упростить жизнь на время перехода экосистемы к ES-модулям
- Встроенный тест-раннер теперь поддерживает кастомные репортеры, сбор тестового покрытия и мокирование таймеров
- Поддержка AbortController в нативных API


https://nodesource.com/blog/nodejs-22-features

#development #javascript #nodejs #releaseNotes

Отзыв на обучение в Стратоплане

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

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

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

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

На обучении нам показали 3 способа описания бизнес-процессов (хотя все способы подходят для любых процессов): BPMN, IDEF0, EPC (ох уж эти любители аббревиатур).

Интересно в них то, что они концентрируются на разных аспектах процессов.
Например, IDEF0, будет близка тем, кто размышляет о процессах как о производстве чего-либо и, наверное, будет удобна многим программистам.

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

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

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

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

На примере онбординга джуна.

Если вам надо объяснить, кто за что отвечает в процессе разработки - лучше использовать что-то типа BPMN - выделить свимлейны под заказчика, разработчика, тестировщика, тимлида и объяснять процесс через их действия и ответственность.

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

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

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



#note #stratoplan

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


——

На этой неделе я в отпуске, поэтому постов не обещаю. Буду знакомиться с Нижним Новгородом.

——-


Bun 1.3
Вышел Bun 1.3. Основные фишки: улучшили поддержку фулстэк-разработки, встроили MySQL и Redis клиенты, улучшили работу с Cookie и роутингом, сделали улучшения для монорепо

Теперь обо всем по порядку

React Compiler v1.0
Вышел React Compiler v1.0. Его можно поставить и, по заверениям разработчиков, забыть о ручном менеджменте useMemo, useCallback, React.memo в 99% кейсах - теперь эту работу должен забрать на себя React Compiler. В остальных 1% кейсов можно заняться ручной оптимизацией для достижения лучших результатов.



Oxlint JS Plugins Preview
Oxlint представили API для плагинов на JS. При этом есть 2 версии API - частично совместимое с Eslint, что позволяет подключить eslint-правила в oxlint без доп приседаний, и oxlint API, которое позволяет делать более производительные правила.


Node.js 22 Features You Should Be Using
Nodejs 22 стал LTS, а значит пора обновляться и смотреть, чего же там нового принесли в Nodejs.


Отзыв на обучение в Стратоплане
Снова отзыв на обучение в стратоплане. Коротко о моем статусе обучения: курс уже закончился, а последнюю половину я смотрю в записи и отстал на 4 модуля (по сути 4 месяца). Из плюсов - вместо 15 часов обучения на модуль (3 дня по 5 часов), запись просматривается где-то за 2 часа. Из минусов: вам придется пережить еще 3 отзыва на обучение т.к. в целом материал норм и я его буду досматривать :) . Последний просмотренный модуль, на основе которого я пишу этот пост, был про бизнес-процессы.

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

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

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

Как AI помогает мне в разработке браузерного расширения

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

Немного контекста про пет-проект - это браузерное расширение для jira, которое делает работу в jira чуточку удобнее. Оно было создано другими людьми, а я там изредка добавляю новые фичи. Занимаюсь я этим проектом крайне мало времени и AI очень сильно упрощает разработку расширения в контексте ограниченного времени.

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

Кто пробовал вручную переводить код с JS на TS, тот знает, насколько это тяжело. То есть, ну с одной стороны - сиди да понемногу описывай поля, которые нашел. С другой, на практике не получается это делать прям продуктивно - работа идет мучительно медленно. Здесь мне на помощь пришел github copilot, который можно запустить прям в веб-морде гитхаба и дать ему задачу, а он сделает изменения и опубликует ветку. Copilot переписал весь код на ts, а я потом его ревьюил. Результат вышел более менее хорошим: были ошибки, часть из которых я заметил во время ревью, а часть пошла в прод и была исправлена после. Я не уверен, что я сам справился бы лучше. Однако уверен, что если бы это был крафтовый ручной рефакторинг - он занял бы кратно больше времени.

Вывод, который я сделал из этого кейса: AI хорошо справляется с техническими рефакторингами. В частности, хорошо переписывает код на ts.

Второй интересный кейс связан с разработкой новой фичи в расширении. Я делал фичу, которая должна отрабатывать на jira-задачах, которые подходят под условия пользователя. В jira как раз существует язык для написания запросов на поиск задач - JQL. Он не супер гибкий, но а) он простой для изучения б) его знают все, кто работает с jira. Например Team = MyTeamName and labels not in (A,B,C).

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

Писать самому такое решение - задача решаемая, но сложная. Я решил попробовать дать эту задачу cursor'у. И знаете - вышло очень хорошо! Cursor сделал трех-ступенчатое решение:
- Написал tokenizer, который разбирает поисковую строку на токены
- Написал парсер, который проходит по токенам и возвращает условие в структурированном формате или ошибку, если поисковая строка невалидна
- Написал функцию, которая проверяет, подходит ли задача под JQL-фильтр

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

Флоу доработки JQL парсера был построен на test-first подходе:
- Сначала cursor сделал первую реализацию
- Затем я попросил написать его юнит-тесты на эту реализацию
- Если нужны правки - дописываю тест и прошу поправить код, чтобы тесты проходили

Экспириенс просто амейзинг. Получилось достаточно быстро доработать функционал до нужного мне уровня.

Бонусом, после написания кода, я попросил AI все задокументировать + сделать виджет для тестирования JQL-парсера, который визуально показывает, как работает условие и почему оно срабатывает или не срабатывает для определенной задачи (скрин приложу в коменты)

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

Ссылки с пруфами:
- JS => TS
- вот код jql-парсера




#note #ai #jiraHelper

Исходники веб-версии app store

Чуваки из эпла, которые разрабатывают веб версию апстора, случайно сделали сорсмапы кода открытыми на проде. И теперь исходный код апстора стал общественным достоянием - энтузиасты скачали его и залили на гитхаб. Репозиторий уже прикрыли, но вы легок можете найти другие репозитории поиском по гитхабу по строке apps.apple.com. Скорее всего уже можно посмотреть и не на гитхабе.

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

Я посмотрел краем глаза, что увидел:
- Используется svelte и scss
- Не смотря на использование svelte, встречается импеативная работа с DOM (создание элементов, навешивание классов)
- Иногда встречаются достаточно объемные комментарии к работе кода - респект людям, описывающие нюансы работы решения в комментариях
- У каждой уважающей себя команды непременно должен быть написан свой логгер. Чтобы было уж совсем по-взрослому - нужен базовый логгер и его наследник - ConsoleLogger. У эпла все серьезно - логгеры с наследованием
- Используется нативный dialog для модалок + полифилл. Также респект за использование нативного dialog

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

https://github.com/rxliuli/apps.apple.com

#development #javascript #svelte #appStore #apple

Дайджест за 2025-11-05 - 2025-11-06

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

Исходники веб-версии app store
Чуваки из эпла, которые разрабатывают веб версию апстора, случайно сделали сорсмапы кода открытыми на проде. И теперь исходный код апстора стал общественным достоянием - энтузиасты скачали его и залили на гитхаб. Репозиторий уже прикрыли, но вы легок можете найти другие репозитории поиском по гитхабу по строке apps.apple.com. Скорее всего уже можно посмотреть и не на гитхабе.


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

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

Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl

Пост в блоге Мартина Фаулера где автор пытается разобраться в новомодном в AI-тусовке термине Spec-Driven-Development, рассматривая его имплементацию разными инструментами

Spec Driven Development, это когда спека пишется перед кодом и является источником правды, а AI по спеке реализует код.

Можно выделить 3 основных варианта имплементации spec driven development:
- spec first - сначала пишется спека, затем по ней пишется код. После реализации кода спека не нужна
- spec anchored - пишется спека, затем по ней спишется код. Затем спека используется в будущих доработках фичи
- spec as source - спека - это главный файл, источник истины. Человек взаимодействует только со спекой, оставляя задачу реализации AI

Тут надо бы понять, а что вообще такое спека. Как обычно в IT далеко не все термины хорошо определены. Спека - один из этих терминов. Автор дает следующее определение: "Структурированный артефакт, или набор артефактов, описывающих поведение и функциональность на естественном языке".

Автор статьи попробовала 3 инструмента для SDD подхода: Kiro, Spec-kit (от гитхаба), Tessl (пока в бете).

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

№1: Инструменты в основном spec-fisrt, т.е. спека пишется под задачу, а после реализации кода она уже и не нужна

№2: Сам подход (и в частности инструменты) плохо работает для небольших задач.
Там, где достаточно сделать быстрый фикс с AI-агентом прямо в коде, SDD-инструменты генерируют тонны избыточной документации. Например, для решения небольшой проблемы будут описаны все критерии приемки и несколько юзер сторей.
Инструменты должны адаптировать свой флоу под сложность задач

№3: Приходиться ревьюить много markdown-документов.
А т.к. LLM переплюнет по словоблудию любого человека, то документы получаютяс большие. Ревьюить их - сложно. Ревьюить код намного проще.

№4: Появляется ложное чувство контроля из-за обилия документации, чеклистов, планов и правил. А по-факту ИИ просто игнорирует часть инструкций.

№5: SDD можно рассматривать как развитие идей MDD (Model Driven Development).
При применении MDD вы описываете модель доменной области на каком-то DSL, а затем имлементируете эту модель в коде. Подход, ожидаемо, не взлетел - никому не охота писать модели, которые проще сразу описывать в коде. Но применение LLM убирает рутину из процесса, оставляя саму суть - человек описывает систему на естественном языке, а LLM до-описывает все скучное.

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

https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html

#development #martinFowler #specificationDrivenDevelopment #ai

Применяем что-то типа Specification Driven Development на практике

В предыдущем посте написал про Spec Driven Development и упомянул, что вдохновился подходоми решил его попробовать.

Напомню: у меня есть пет-проект, который помогает мне (и не только мне) в работе и на развитие которого я выделяю очень мало времени (буквально считанные часы в месяц) - chrome extension подсвечивающий разное в jira. Фичи я в нем делаю строго с ИИ т.к. писать крафтовый код - долго. Обычно закидываю задачу в агента и иду заниматься своими делами

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

И вот решил попробовать SDD. Я не погружался в то, как это делать правильно, не брал никаких шаблонов. Делал, как чувствую.

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

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

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

По итогу применять практику мне прям понравилось.

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

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

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

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

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

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

Какие уроки извлек:
- Сначала думай (пиши спеку), потом делай - все еще рабочая стратегия
- SDD - выглядит жизнеспособно, по крайней мере если вы делаете пет-проект chrome extension
- ИИ хорошо пишет доку по спеке+коду


Ссылка на спеку, по которой сдеплан код



#development #specificationDrivenDevelopment #ai #note #javascipt #jiraHelper

ESLint Plugin for Baseline JavaScript

Eslint Plugin для проверки использования слишком нового синтаксиса и фичей веба. Вы выбираете baseline threshold, а плагин контролирует, чтобы вы его придерживались

https://baselinejs.vercel.app/

#development #javascript #eslint #baseline

Codefest 16: Call for Papers

Codefest открыл сбор заявок на доклады на 2026 год. Сбор заявок продлится до 1 марта. Если хотите выступить - отправляйте заявки. Конференция ламповая, хожу на нее в качестве и спикера и слушателя уже лет 10, почти без перерывов.

Конференция - крупнейшая в Сибири, куда приезжают куча спикеров и участников со всей России. Хотя, будем честны, по моим ощущениям основа состава конференции - ребята из Сибири.

Хорошие доклады, куча стендов компании, кайфовые афтепати - это все Codefest

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

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



https://16.codefest.ru/themes#program

#note #codefest #callForPaper