HowProgrammingWorks - JavaScript and Node.js Programming

Завтра Часть 2 вводного курса по применению структур данных, покажу и сами примеры внедрения и Skills для AI, чтобы писать код эффективнее

1. Встроенные структуры JavaScript: Object, Array, Map, Set, WeakMap, WeakSet, TypedArray

2. Кастомные структуры: Queue, Deque, Stack, List, UnrolledList, Circular Buffer, Heap, Trie, Graph, LRU, Pool, CRDT

3. Высокопроизводительные структуры metautil: Struct, ConsList, Trie, List, UnrolledList, Queue, Deque, Stack, Pool, Semaphore

В субботу, 8 августа, в 17:00 смотрим, как подключать скилы и библиотеки и использовать их в реальном коде:
https://gm.nexttick.it/go/data-structures-code-review

AI ошибается. Люди тоже ошибаются.

Проблема в том, что AI производит код полный недочетов и скрытых ошибок быстрее, чем чинит и в большем объеме, чем человек способен прочитать.

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

Нужно уменьшать стоимость проверки результата и стоимость владения.

Промпт не является контрактом. Это пожелание на естественном языке, допускающее десятки интерпретаций. Можно написать модели "не ломай совместимость", "учти все крайние случаи" и "пиши надежно", но эти фразы невозможно автоматически проверить. Контракт должен быть формальным и желательно исполняемым.

Типы фиксируют форму данных, сигнатуры и архитектурные границы. Это дешевый, широкий, но неглубокий контроль. Типы не подтверждают бизнес-логику, порядок операций, права доступа, транзакционность, идемпотентность, отсутствие гонок и корректность побочных эффектов. А в TypeScript типы вообще не являются точным описанием того, что будет реально исполняться в виртуальной машине. Типы стирается до runtime и виртуальная машина сама выводит свои типы, которые отличаются от того, что вы себе написали в TS.

Типы описывают представление компилятора о программе, а виртуальная машина работает с реальными значениями у которых есть вычислимая "форма" и с кодом, кторый оптимизируется во время исполнения под эту форму. Данные всегда приходят из сети, БД, JSON, JavaScript-модуля, пользовательского ввода и не соответствуют тому, что было в TS. Типы в рантайме более строгие, чем в TS, например, он учитывает порядок полей в объекте, знает, как резолвится асинхронная функция, через ивентлуп или очередь микротасков, отличает значения внутри Number: HeapNumber, Smi, Int8, Uint8, Int16, Uint16, Int32, Uint32, Int64, Uint64, Float16, Float32, Float64, Word8, Word16, Word32, Word64...

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

Тесты фиксируют поведение гораздо точнее. Мутационное тестирование намеренно портит реализацию чтобы проверить общую стабильность на сломанном пути. Контрактные тесты подтверждают совместимость модулей и сервисов Интеграционные тесты проверяют взаимодействие с базой, сетью и инфраструктурой. E2E фиксируют наблюдаемое пользователем поведение. Нужно зафиксировать даже неизвестное legacy-поведение, а как это сделать типами?

Полная типизация внутренней реализации постепенно теряет смысл, AI способен читать реализацию целиком и отслеживать реальные рантайм-типы гораздо более точно. Во многих проектах достаточно JavaScript для реализации каждого модуля + d.ts для контрактов. Typings становятся суммаризацией кода и документации. Они описывают обещание модуля внешнему миру, не заставляя потребителя изучать реализацию. Внутри можно свободно менять алгоритмы, структуры данных и декомпозицию, пока сохраняются внешние типы, тесты и инварианты.

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

Заходим к Илье, учимся тестировать с AI: https://ai.javascript.ninja/gld-ai-r

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

Под стримом по структурам данных задали вопрос, какие AI модели я использую и какой харнес.

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

Я стараюсь по неделе переключаться между моделями, чтобы знать их состояние и чувствовать особенности, но для моих задач сейчас лучше всего подходит Sonnet 4.6 (даже не 5), Codex 5.3, Grok 4.5, они не очень умные, но мне не нужно, чтобы они были умные, за то они не придумывают хитрых и запутанных решений и работают очень быстро. Вот в тех же структурах данных я их все пробовал использовать и пришел к выводу, что они примерно все на одном уровне, если применять их для текхической рутины. Они делают именно то, что просишь, особенно если сбрасывать контекст часто, хотя и деградация у них ниже, чем у флагманов.

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

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

В субботу 8 августа мастер-класс в 17:00, покажу тем, кто зарегистрируется https://gm.nexttick.it/go/data-structures-code-review

Стало сложно писать лучше чем Fable, я неделю оптимизировал под V8 три несчастные структуры данных, чтобы обогнать его: Unrolled List, Doubly List, Circular Buffer.

Но не бойтесь, я завтра буду рассказывать не про то, как они устроены (картинка с 6 структурами), а как их использовать (картинка с 12 интерфейсами).

Завтра в 19:00 — прямой эфир о практическом применении структур данных
Поговорим в формате применения, решения конкретных прикладных проблем в реальном коде:
• почему "массив на все случаи жизни" превращается в техдолг
• какие структуры упрощают бизнес-логику, backend и frontend
• как внедрить структуры данных отталкиваясь от проблемы и болей
• как выбирать решения с учетом V8, памяти, GC и стоимости работы с AI
Покажу код, но не код самих структур, а код того, как они используются.
Будет ли запись стрима - я пока не решил, но для тех, кто посмотрит его в прямом эфире будет секретная часть, которую я точно потом отрежу.

Оставляйте вопросы заранее прямо под видео — разберем их на эфире:
https://youtube.com/live/qNAjrZ07un0

Как вы думаете, кому выгодно, чтобы вы не читали код и чтобы он все время переписывался и никогда не стабилизировался? One-shot? Все с нуля и каждый раз - вот что нужно. Все свои софты личные, одноразовые тулы, agentic loop, self-review, Best-of-N, infinite repair, full-replay...

Курс Ильи Климова «Тестирование в эпоху агентов»

AI уже умеет писать много кода, но без тестов, контрактов и автоматической проверки качества он завалит вас кодом и вы его даже не вычитаете, не говоря уже о том, что на глаз многие вещи просто не ловятся, особенно в таких объемах кода. Курс учит, как построить управляемую инфраструктуру, чтоб тестирование помогало дресировать AI. Особенно полезно тем, кто уже использует AI в реальных JavaScript/TypeScript-проектах.

Промокод на 15% ti15 до 1 августа

Заходим, не стесняемся: https://ai.javascript.ninja/gld-ai-r

Почему в JavaScript мире нет культуры использования структур данных?
Их неправильно учат, точнее, правильно, но этого мало, такие знания полезны только на задачках с литкода и на собесах, а вот на практике люди сразу забывают про структуры данных и реальный код только: [], {}, Set, Map

Я поискал, как их обычно преподают
- как устроены внутри и как работают
- как оптимизировать: CPU, memory
- как оценить вычислительную сложность
- как оптимизировать под V8, GC

Но нет даже попыток показать:
- как применить на реальной задаче
- как они делают код понятнее
- как они помогают экономить на AI

1 августа покажу примеры на реальном коде для бизнес-логики, системного программирования, бекенда, фронтенда: https://youtube.com/live/qNAjrZ07un0

В NextTick мы регулярно проводим голосовые разборы для участников с платной подпиской. Один из последних стримов мы решили ненадолго открыть в Telegram-канале IT-Гильдии.

AI уже умеет ускорять разработку. Проблема в том, что бизнесу не нужен код быстрее. Ему нужны решенные задачи.

Это часовой разговор о том, что агентская эпоха уже меняет в работе разработчика: почему количество сгенерированного кода ничего не говорит о результате, где сохраняется ценность инженера и почему архитектура, code review и способность спорить с неверными решениями становятся важнее скорости написания кода. А еще — что изменения в GitLab, увольнения в Cloudflare и рост AI-рынка означают не для абстрактного «рынка труда», а для конкретного разработчика прямо сейчас.

Запись будет в канале до 2 августа. https://t.me/itguild_next_tick

Новый набор в гильдию Next Tick

За что тебе платят, когда код пишет модель? Ответ, с которым мы работаем в Гильдии: за работу с ограничениями, decision framework, архитектуру, review, широкое мышление, глубокую экспертизу, умение коммуницировать с людьми и агентам.

Вы знаете, что у меня есть курс по архитектуре, в нем 22 лекции по 2 часа и вот все материалы по архитектуре, которые я записал для NextTick почти не пересекаются с моим курсом, потому, что в NextTick другая цель и другой материал, который обычно не передают в статьях, книгах и докладах, это личный опыт, о нем рассказывают друзьям в неформальном общении, но оказалось, что это самое ценное, что позволяет быстро нарастить компетенции.

Некоторые темы по архитектуре, которые мы уже рассмотрели:
- AI и архитектура: кто кем управляет, зачем уменьшать сложность
- Почему "большие задачи" почти всегда ложь — и как дробить работу
- Вертикальные слайсы vs горизонтальные слои в архитектуре
- Acceptance criteria как проверяемый контракт
- Planning for AI: explicit outcome, границы, definition of done
- Не весь техдолг равен, как продать рефакторинг на языке ROI
- Rewrite vs refactoring, AI-assisted migration: где AI ускоряет, а где производит новый долг
- Мифология в программной инженерии
- Architecture review: что реально должно блокировать merge
- Реактивные вычисления, модель акторов, конечные автоматы
- Мультипарадигменное программирование и построение DSL-языков
- Функциональные и нефункциональные требования
- ADR (документирование архитектурных решений)
- Управление характеристиками кода для построения нужной архитектуры

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

Что будет в ближайшее время:

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

Архитектура - это пересечение экономики и эстетики: предсказуемость из непредсказуемых частей, обратимые решения vs one-way doors, R&D вместо "надо все знать".

Заходите на сайт, там обзор и описание формата - https://nexttick.it/?utm_source=timur_tg_howprogworks

🧑‍💻 AI: зачем нужны структуры данных для JavaScript — практические примеры для бэкенда и фронтенда

Структуры данных в JavaScript обычно объясняют через их внутреннее устройство, API и оценку сложности Big O. А мы пойдем от реальных инженерных проблем: написание бизнес-логики, кода на JavaScript и TypeScript для backend и frontend, типовые проблемы в разработке: коррапт глобальных данных, гонку состояния, очереди, кеширование, история изменений, управление памятью и ресурсами.

Мы разберем, почему каждая структура решает определенную проблему, и уже как следствие, то что она что-то запрещает и чем за это приходится платить, но и какие плюсы мы получаем. От обычных Array, Object, Map и Set до Linked List, Persistent List, Heap, Circular buffer, Bloom filter, Stack, Queue, Append-only, Immutable lists and Records. Отдельно классифицируем структуры для доменного, продуктового, платформенного и системного кода.

https://www.youtube.com/live/qNAjrZ07un0

А тут альтернативный вариант входа без пароля:

- Хранение ключей в OPFS (в браузере)
- Для генерации Web Crypto (ECDSA P-256)
- Без использования Web Authn, Passkey

https://github.com/HowProgrammingWorks/ChallengeSignIn

Passkey (вход без пароля)

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

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

Минимальный пример на чистом Node.js и WebAuthn API: регистрация, вход, сессия.
https://github.com/HowProgrammingWorks/Passkey

Что я понял по итогам работы над структурами данных для стандартной библиотеки Metarhia

Это же классическая тема, но ее мало кто хорошо осваивает в наше время, тем более в мире JS/Web разработки и во времена, когда все пишет AI. И даже если учили и знают, как делать хотябы простейший список, то нет привычки его использовати и знания остаются аккадемической теорией, невосстребованными вообще, а в коде массивы и объекты, ну максимум Set/Map. Почему же так случается?

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

Я за последний месяц собрал свои наработки за последние 15 лет и сделал и продакшен-версии кода и учебные примеры, записал много лекций и стримов по структурам данных. Буду делать примеры и скилы, а пока вот продакшен-реди реализация самых нужных структур тут https://github.com/metarhia/metautil

Object.freeze / seal / preventExtensions: сколько это стоит в V8

Бенчмарк на create / read / write для обычного объекта {} и трех режимов защиты: freeze, preventExtensions, seal.

- create: защита дороже обычного объекта ~в x4: {} 5.7 ns, а для freeze/seal ~25 ns
- read: разницы почти нет, все ~1.4–1.6 ns
- write: preventExtensions и seal пишут в существующие поля так же быстро, как {}, а freeze в кидает исключение ~2245 ns (долго)

Вывод: читать frozen можно спокойно, дорого создавать (это обычно редко), а писать в freeze через try/catch не нужно, но в коде freeze может быть, если есть тесты, подтверждающие, что не пишем в поля

https://github.com/HowProgrammingWorks/Object

Трехконтурная разработка: вместо того, чтобы генерировать с помощью AI миллионы строк кода в одном репозитории можно разделить это на 2 или три цикла.

Первый контур: технологический стек

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

Второй контур: параметризованные модули

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

Третий контур: продукт

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

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

Эти и другие вопросы обсуждаем каждый четверг на созвоне сообщества https://www.patreon.com/c/tshemsedinov