Меня зовут Арсений, мне 15 лет. У меня 99 пользователей, более 100 SQL‑миграций и приложение на Android и Windows. И, что не менее важно, — команда единомышленников и поддержка тех, кто верил в проект с самого начала.
Если вам интересно попробовать — заходите на агора.com.
Это история про открытый креативный промпт к LLM, оставленный без присмотра. Через месяц он превратил пятничную рубрику нашего блога в гимнастику парафразов одного и того же тезиса. Поймал я это не на первой пятнице и даже не на второй: каждая отдельная статья сама по себе выглядела нормально. На четвёртой стало очевидно.
Расскажу, какие четыре вещи я попробовал, прежде чем признать, что промпт-инжинирингом эту штуку не лечат. По дороге всплыло, что часть проблемы сидела не в промпте, а в нашей собственной конфигурации Gemini, на которую я не сразу обратил внимание (точнее - вообще не видел). И как в итоге мы перевели генератор тем с открытого «придумай вопрос» на заранее детерминированную ротацию из курируемого пула. Без файнтюна, без RAG, без переезда на другую модель.
У меня был проект, где один Next.js сайт обслуживал несколько доменов, и возникла задача — эффективно кешировать страницы, чтобы не пересоздавать их каждый раз. Сначала я попробовал внедрить кеширование через Redis: я написал хендлер, подключил его, но вскоре обнаружил, что Redis потребляет колоссальный объём оперативной памяти — порядка 100 ГБ, и это при том, что ещё не все запросы были закешированы. Тогда я решил поискать другой подход и обратил внимание на PVC — общее хранилище, которое могли бы использовать все поды. Я начал изучать варианты работы с PVC и довольно быстро пришёл к идее общего кеш‑хранилища для всех подов. Я попробовал просто писать данные в PVC, но столкнулся с проблемой: каждый раз, когда под поднимался, он перезаписывал кеш. До тех пор, пока не подняты все поды, данные постоянно перезаписывались, а мне нужно было, чтобы первый под записал данные, а последующие только читали их. Я начал искать, как сделать кастомный кеш‑хендлер, но готовых решений не нашёл.
Однажды разработчики NEXT.JS решили сделать сервис для хостинга и получился Vercel. Они смогли предложить рынку облачную архитектуру, определяемую фреймворком, что дало великолепный пользовательский опыт.
Но в ряде случаев нужны аналоги Vercel. Особенно в России, где сайты на Vercel недоступны для многих пользователей с мобильного интернета из-за региональных ограничений. Да и не у всех есть возможность оплачивать платные тарифы долларовой картой.
Чтобы лучше представить альтернативы Vercel и их сильные и слабые стороны, я рассмотрю архитектуру самого сервиса и его конкурентов.
В какой-то момент я заметил, что сам учет финансов в Obsidian меня полностью устраивает, а вот сбор исходных данных для него каждый раз отнимает лишнее время.
Схема была простой и довольно утомительной: открыть несколько банков, посмотреть остатки по счетам и картам, потом перенести эти цифры в свои заметки. По отдельности это мелочь, но в регулярной рутине такие действия быстро начинают раздражать.
Я решил автоматизировать именно этот участок. Мне был нужен локальный и понятный способ собирать данные из интернет-банков, а уже потом использовать их в своей системе заметок.
В этой части речь пойдет именно про сбор данных: как я сделал небольшой bridge-слой между банками и Obsidian. Во второй части можно будет уже перейти к тому, как эти данные встраиваются в vault.
Последние полгода я работаю над VibeMuvik — кино-соцсетью с рецензиями, дебатами и синхронным просмотром фильмов. Одна из тех штук, которые «ну вроде несложно», пока не начинаешь копать.
Эта статья — про неожиданные находки. Не про «как я выбрал стек» (скучно) и не про «туториал по WebRTC» (и без меня есть). Это пять ситуаций, в которых я споткнулся, обнаружил что-то интересное, и подумал «об этом стоит рассказать — другим пригодится».
Поехали.
Telegraph API обещает принимать content до 64 КБ, но на практике CONTENT_TOO_BIG прилетает уже на 17-20 КБ. Разбираю, как измерял реальный лимит, при чём тут UTF-8 vs UTF-16 для кириллицы, и каким обходным путём чинил молчаливую деградацию RU-канала.
Прошлой зимой я писал тут про «Мастерок» — строительный калькулятор на Flutter для RuStore. Приложение поехало в прод, набрало 4.9 звезды, и в какой-то момент пришло осознание: аудитория смартфонных приложений — это аудитория смартфонных приложений. А человек, который в обед нагуглил «сколько мешков ротбанда на 20 квадратов», в магазин приложений не полезет. Он хочет страницу в браузере. Желательно без куки-баннера на полэкрана, без интерфейса из 2012-го и без того, чтобы перед ответом на вопрос ему предлагали посмотреть пять реклам.
Так появился getmasterok.ru — веб-половина той же экосистемы. Сайт на Next.js 15, шестьдесят один калькулятор, ИИ-прораб, SEO, блог, всё как положено. И с одним неочевидным вызовом, который стал главным сюжетом этой статьи.
А вызов я нашёл не сам. Его нашёл пользователь.
Когда заканчиваешь работу над веб-приложением, будь то полноценный сайт или Telegram MiniApp, всегда есть желание сразу и без хлопот всё это захостить, показать друзьям, знакомым и сразу пустить в прод.
И встает вопрос: как вообще выложить это все в интернет, желательно по нормальной ссылке, с HTTPS и без тонны настроек VPS и nginx?
В этой статье я покажу способ, как публиковать сайты на PaaS-сервисах, просто привязав к ним Git-репозиторий и делая в него коммиты (или вообще просто перетягивая файлы в интерфейсе).
Типовая задача на российском рынке: есть публичный сайт (лендинг, маркетплейс, каталог), на нём формы — заявка, регистрация, заявка партнёра. Эти лиды должны попадать в 1С Битрикс, где с ними работает отдел продаж.
Подход "в лоб" выглядит так: в обработчике формы сделать await fetch('https://bitrix.../crm.lead.add', ...) и вернуть пользователю ответ после того, как Битрикс подтвердил создание лида.
Это плохо работает. Битрикс REST API нестабилен по latency — 200 мс в норме, 8 секунд при нагрузке на стороне CRM. Пользователь сайта в это время смотрит на крутилку. Если Битрикс упал или таймаутит — сайт отдаёт ошибку, хотя пользователь форму заполнил корректно.
В этой статье — паттерн, который я использовал на маркетплейсе недвижимости на Next.js 16 + PostgreSQL 16 + 1С Битрикс. Без Redis, без BullMQ, без отдельного воркера. Просто Next.js API route + after() + минимальный HTTP-клиент с retry и таймаутом.
Цифры проекта для контекста: 25 объектов недвижимости в каталоге (отдельная сущность ready_homes оставлена за скобками статьи), 57 API-роутов, PostgreSQL 16.13 на VPS, деплой через systemd + nginx, интеграция с Битрикс — исключительно outbound (сайт → CRM).
Если предыдущая часть была посвящена аспектам, связанным с публикацией сообщений, то в этой части основное внимание уделено обработке сообщений, проектированию консьюмеров и проблеме ребаланса в консьюмер группе.
Несколько лет назад в одном из моих проектов на чистом JavaScript возникла задача: валидировать большие вложенные объекты со сложной структурой. Объекты содержали различные подобъекты, к каждому из которых применялись свои правила валидации в зависимости от типа.
Задача усложнялась двумя дополнительными требованиями:
Если ты тоже смотришь на Dart как на backend-альтернативу для Node.js, лучше пройти этот путь на чужих ошибках. Полные результаты benchmark'а — Go, Node.js, Dart, Bun, Deno, .NET — с методологией, конфигурацией и сырыми цифрами лежат на GitHub. Под катом — сама история. Не технический отчёт, а инженерская драма: как 2 недели ушли на перенос архитектуры, почему всё выглядело идеально на бумаге, и как гипотеза с "экономией памяти" разбилась о реалии raw benchmark. И ещё — почему AI-агент сделал всё правильно, и именно это оказалось проблемой.
Ранее мы писали похожие статьи о CSS, но JavaScript заслуживает не меньшего внимания! Тем более что JavaScript лучше справляется с версионированием. Мы рассмотрим новые возможности самого языка, а также основные среды выполнения, фреймворки, библиотеки и инструменты.
Привет, Хабр! Меня зовут Василий Беляев. Я руководитель группы разработки по направлению фронтенда в ИТ-компании «Криптонит». В этой статье я расскажу про организацию работы с версиями и компонентами, оптимизацию рабочего процесса внутри команды, а также опишу несколько лайфхаков, которые мы применили.
Привет, Хабр! Меня зовут SlywerX, я студент 3 курса кафедры Программной инженерии МТУ (Алматы) и fullstack-разработчик. Несколько месяцев назад я задался вопросом: а как вообще работают языки программирования изнутри? Лучший способ разобраться — написать свой. Так появился SWX (Shadow Web eXploit) — скриптовый язык на базе Node.js с собственным синтаксисом, криптографией и даже HTML-рендерингом.
Сейчас SWX на версии 7.0.0. В этой статье расскажу как всё устроено, что было сложно и зачем это вообще нужно было делать.
В предыдущей статье мы подробно рассмотрели замыкания в JavaScript, а сейчас изучим как из-за них возникают утечки памяти и как этого избежать.
Замыкание существует пока, есть хоть одна ссылка на функцию создавшую его. Если быть неосторожным, это может привести к утечкам памяти: когда объект уже не используется в программе, но сборщик мусора не может его удалить. Такие ссылки могут быть неочевидными...
В субботу Anthropic заблокировал мой рабочий сетап, построенный на oAuth Claude Code и Telegram. Вместо того чтобы ждать, я за вечер написал self-hosted замену с блэкджеком и постоянной памятью. Рассказываю, как устроен TeleClaude — опенсорсный инструмент, который позволяет управлять проектами через топики в Telegram, используя вашу локальную подписку Claude с лимитами из oAuth. Никаких облаков, API и дополнительных трат. Разбираю архитектуру, систему памяти и показываю, как запустить у себя.
WP умер, перевёл все сайты на OpenClaw
Раньше часто использовал WordPress с кучей плагинов для создания сайтов и лендингов. Сейчас поставил DarwinClaw на чистую машину Ubuntu и сказал ему сделать всю инфраструктуру для сайтов. Он поставил nginx + node.js.
Потом попросил перенести сайты, указав ссылки на них. Он создал все сайты.
Попросил добавить git и репозиторий для хранения этих сайтов. То есть всегда можно быстро откатить изменения.
Теперь полностью управляю этим зоопарком лендингов через TG команды типа:
Убери с сайта X вот это
Добавь на сайт Y вот то
Поменяй стиль сайта Z на …
Откати последние изменения на сайте XM
Замени икноку на сайте XS на более современную
Собери статистику по заполнению форм с сайтов X, Y, Z в формате
Раньше это либо делали люди за деньги, либо WP с его тяжёлой инфраструктурой, теперь всё делает бот на OpenClaw.
Замыкание это важный механизм JavaScript, понимание которого обязательно фронтендера. Он позволяет изящно реализовать принцип наименьшего раскрытия, благодаря инкапсулированию функций, сохраняя их состояние во внутренней области видимости, для последующего использования.
