Всем привет. На днях моя техническая статья с open source кодом про написание нейросети с нуля на Node.js вышла из песочницы Хабра благодаря НЛО, набрала 8K+ просмотров и получила крутой фидбек. Но за 2 дня до этого я решил провести эксперимент и выложить этот же материал на VC.ru. Итог — моментальный пожизненный бан без объяснения причин в первые 15 минут…
Я довольно долго был уверен, что понимаю, как работает call stack.
Ну а что там понимать? Положил кадр, снял кадр, LIFO.
Потом открыл спецификацию. Оказалось, за «стеком вызовов» стоит каркас из пяти сущностей, а половина привычных объяснений просто не совпадает с текстом стандарта.
Замыкание — не фича языка, а побочный эффект того, что окружение живёт отдельно от кадра. «Область видимости» — вообще не сущность: такого термина там нет. А слов event loop, microtask и task queue в ECMA-262 ровно ноль. Проверяется грепом за минуту.
Разбираю модель исполнения по первоисточнику: агент, контекст, окружения, джобы. Каждое утверждение сверено с текстом стандарта, номера параграфов проставлены — можно перепроверять за мной.
Мы создаем крошечную языковую модель с нуля на чистом Node.js без использования TensorFlow или PyTorch, реализуя нейроны, автоград, эмбеддинги, механизм самовнимания (self-attention), полносвязную сеть (FFN), обратное распространение ошибки и SFT, одновременно наблюдая за тем, как отдельные веса и целые матрицы изменяются в процессе обучения
В предыдущей статье я описал как я делал DTMF-MQTT шлюз для открывания ворот. Там я мЕльком упомянул, что делалось это как альтернатива телеграм и в общем свою функцию выполнило. В действительности путь был длинней, тернистей, но зато и завел куда дальше: текущее решение ничем не уступает тому что было в ТГ, а кое в чём и превосходит.
Задача формулировалась в одно предложение: робот должен сам звонить людям в WhatsApp, проигрывать голосовое приветствие, записывать ответ и присылать оператору расшифровку с вердиктом «да / нет / надо посмотреть руками».
Проблема в том, что официально это невозможно. У WhatsApp нет API для голосовых роботов: Business API умеет шаблонные сообщения, провайдеры на рынке умеют текстовые рассылки, голосовые звонки закрыты наглухо. Готового решения не существует ни за деньги, ни за большие деньги.
Зато существует официальное десктопное приложение, которое звонить умеет. И его можно водить за руку.
Это рассказ о том, что из этого вышло: с чего начиналось, какие подходы умерли по дороге, четыре слоя автоматизации — от CDP до виртуальных аудиокабелей — и один урок про производительность, который перечеркнул половину архитектуры уже на живых звонках.
Сразу оговорюсь: по отношению к правилам платформы это серая зона, и я не предлагаю это повторять. Мне здесь интересна чистая инженерия — как автоматизируется то, что автоматизировать не предполагалось. Ограничения и риски честно разберу в конце.
Кода будет много. Всё интересное в этом проекте живёт именно в деталях.
Я хотел получить локального AI-агента без отдельного API для каждой модели — и превратил браузерные сессии DeepSeek, Qwen и ChatGPT в единый транспорт. В статье разбираю архитектуру AI Free: WASM proof-of-work, подписанные запросы через авторизованную вкладку, работу через штатный UI, общий оркестратор, память, skills и восстановление после сбоев. А ещё рассказываю, почему первый успешный запрос оказался самой простой частью проекта, который я разрабатываю один.
Мой мемный сервис «Шакализатор» победил в премии Яндекс Практикума, но меня больше интересовал другой вопрос: как VPS с одним ядром и 1 ГБ RAM пережил 1,2 млн запросов за сутки?
Серверную часть в основном писал Codex, а я во время наплыва обновлял статистику и ждал падения. Теперь разбираю код, логи и серверные срезы: что именно спасло систему, где нам просто повезло и почему миллион запросов оказался не тем, чем кажется.
Представьте, что вам нужно обрабатывать десятки тысяч сообщений с помощью LLM: извлекать данные из текста, классифицировать объявления и получать строго структурированный JSON. При этом стоимость каждого запроса должна оставаться минимальной.
Я столкнулся именно с такой задачей и попробовал несколько подходов: от бесплатных моделей до платных API. В итоге удалось снизить стоимость одного запроса примерно до 0.006 рублей, сохранив качество обработки.
В статье расскажу, как я пришёл к этому решению и почему в итоге написал собственный API-слой поверх OpenCode Go.
В статье разберем, как собрать простой DI-контейнер на чистом JavaScript без TypeScript, декораторов и reflect-metadata. Заодно посмотрим, как применить его в небольшом DDD-примере с корзиной, репозиторием, скидками и разными lifetime зависимостей.
Пример реализации простого кэширующего прокси для пакетов npm, composer и pip на базе node.js для Windows и Linux.
Хочу сравнить фреймворк Point0 и библиотеку tRPC. Делаю это, потому что квери и мутации в Point0 очень похожи по DX на tRPC, но более удобны ввиду того, что всё же Point0 это фреймворк и он может обладать возможностями, которыми библиотека не может:
Объявлять квери вместе с серверным кодом прямо в клиентских файлах, или наоборот
Автоматически гидрировать и дегидрировать квери клиент при включении SSR
В мутациях отправлять файлы автоматически превращая данные в FormData и обратно
Иметь стабильные индивидуальные урлы для квери и мутаций
Не заставлять зависать редактор кода при увеличении количества эндпоинтов
Возвращать в ответах с сервера на клиент целые серверные компоненты или интерактивные острова
Управлять внешним видом состояний загрузки на страницах и в компонентах
Кроме того, что описано в этой статье, Point0 может много чего ещё, но об этом в других статьях. Сейчас фокусируемся на сравнении с tRPC. Предполагается, что вы с tRPC более менее знакомы, но ниже я всё равно буду показывать примеры реализации на tRPC, чтобы сравнения были видимыми.
Когда я начал развивать Discord-сообщество, обычной команды /ban хватило совсем ненадолго. Роли настраивались в одном месте, приветствия — в другом, логи — в третьем, а за уведомления о стримах отвечал отдельный бот.
Я много работаю с кодинг‑агентами в Claude Code. В какой‑то момент поймал себя на том, что не представляю, на что уходят токены. Счёт в конце месяца есть, а из чего он складывается, непонятно.
Написал небольшую утилиту: она читает то, что Claude Code и так пишет на диск, и раскладывает расходы по статьям. То, что она показала, мне не понравилось.
Есть одно предложение, которое за последние месяцы перепечатали, кажется, все. Вот оно, в переводе с блога TypeScript:
📣 Заявка. «Проверка типов проекта VS Code (около 1,5 млн строк) ускорилась с 77.8 с до 7.5 с». Итог, который команда вынесла в заголовок, — «примерно в 10 раз быстрее».
Это не обзор релиза. Это попытка воспроизвести один график — не на кодовой базе Microsoft, а на монорепо, которое я собрал специально под замер, двумя компиляторами на одной машине, с показом каждой цифры и с репозиторием, где любую из них можно получить командой pnpm bench.
Сразу спойлер: да, TS7 быстрее, и заметно. Но „в десять раз“ живёт в одном конкретном месте, испаряется в другом, а кое-что важное в 7.0 пока не вошло — и это „кое-что“ важнее скорости.
Главная мысль:
«10×» — это про чекер на большом проекте, а не про весь ваш день. TS7 радикально ускоряет проверку типов и режет память, и замеры это подтверждают. Но в 7.0 отсутствует стабильный программный API — а с ним из сборки выпадают кастомные трансформеры, tsserver-плагины и типизированный линтинг. Поэтому вопрос миграции — не «стало ли быстрее», а «завязана ли ваша сборка на этот API».
Я не пытался сделать «приватный мессенджер» и вообще не думал про слежку и прослушку.
В один день мне просто надоело, что созвониться с человеком — это настоящая проблема: блокировки, включи-выключи VPN, а любой новый аналог встречает регистрацией с десятком полей — а теперь местами ещё и просьбой показать паспорт.
За ночь я собрал прототип голосового чата по принципу «ничего лишнего» — и уже потом с удивлением понял, что этот же принцип случайно сделал разговор в нём таким, что подслушать его со стороны физически негде.
Ниже — как так получилось, где у этой «невозможности» честные границы, и почему всё держится на одном-единственном решении.
Привет, сообщество! Уже долгое время я отмечал на для себя на карте бесплатные парковочные места в центре города; Этот список быстро начал "ходить по рукам" среди друзей и знакомых. Мне пришла в голову идея, а что если развить "списочек для друзей" в какой-то более общественно полезный проект? И с какими техническими челленджами придется столкнуться при попытке навайбкодить мало-мальски production-ready приложение?
Управление контекстной рекламой — это много механической работы. Открыть статистику, выгрузить срез, свести два периода в таблице, заметить просевшую кампанию, пойти в другой отчёт, поднять минус‑слова, вернуться, поправить ставку. Каждый шаг по отдельности занимает приличное количество времени, с учетом того, что в больших РК этот процесс еще и подвисает (буквально подвисает, на больших отчетах статистика может грузиться минуты). Все вместе половина рабочего дня уходит на то, чтобы просто понять, что происходит в аккаунте. И таких аккаунтов у специалистов/фрилансеров обычно больше одного, у меня сейчас, например — 7.
Естественно, что регулярно собирать статистику по большому количеству срезов руками просто не получится. Директ тоже не сильно помогает, рекомендации там сейчас достаточно общие и верхнеуровневые.
Пробовал автоматизировать это, выгружая эксель со статой и загружая его напрямую в клод, но по факту это не сильно ускорило работу — все равно нужно самому пройти по аккаунтам и выгрузить достаточно много срезов. А когда они выгружены, там уже и самостоятельно это можно сделать достаточно быстро. Короче говоря, не особо это и автоматизация.
Последние полгода я достаточно активно работал с различными ИИ и решил, что созрел на то что бы сделать свой сервис, который снимет эти проблемы. Логика, как я её видел, должна была быть простой — даёшь ИИ доступ к АПИ Директа, а дальше он сам делает всю магию, и я просто запросами в чате получаю все необходимые данные и управляю кампаниями.
Что может быть проще?)
Хочу анонсировать свой фреймворк Point0. Это первый Bun FullStack фреймворк сопоставимый по функционалу с Next.js и TanStack Start. Однако, имеет кардинально другой DX, ради которого и был создан.
Мне всегда не нравились существующие фреймворки, особенно Next.js и Remix (React Router). Но я думал, что, видимо, по-другому фреймворки просто не получаются, поэтому и не делают. А громоздкость, чужие строгие соглашения, неповоротливость архитектуры, это просто необходимое зло, с которым я должен смириться.
В какой-то момент во мне накопилось критическое ощущение, что всё же должно быть совершенно по-другому. И я подумал, а напишу-ка я псевдокод на воображаемом фреймворке, который бы меня устраивал, вообще не взирая на возможность реализации. Просто буду писать проект, будто бы идеальный фреймворк существует.
И получилось так здорово, что я просто забыл обо всём на свете и 10 месяцев пилил реализацию этого фреймворка, а 3 месяца назад даже уволился с работы, чтобы уже скорее его добить. И вот добил, и хочу поделиться с вами.
Обсуждение архитектуры или бага часто начинается в ChatGPT, а реализация продолжается локально в Codex CLI. Рассказываю, как я сделал небольшую CLI-утилиту, которая переносит расшаренный ChatGPT-диалог в локальную сессию Codex, и почему для этого оказалось недостаточно просто записать JSONL-файл.
npm install — такая привычная многим из читателей команда, но за последние пару месяцев она обернулась сущим кошмаром для инженеров по безопасности. И ладно бы всё сводилось к проверке 5 пакетов из package.json, но у каждой зависимости по 10 своих зависимостей, а у тех ещё по 10. В итоге мы тянем 2000, а не 5 пакетов, и тут, кажется, уже руками не проверишь. И именно на этой боли всех безопасников, поддерживающих JS-проекты, сыграла команда TeamPCP. В этой статье я хочу подробно, от А до Я, разобраться, в чём опасность, почему так произошло и как от этого защититься.
