Как я собрал бесплатный сервис метаданных книг на Java и Spring Boot — с EAV/Pivot-схемой БД вместо ALTER TABLE на каждое новое поле, агрегацией нескольких открытых источников. Плюс обновлённый плагин для Obsidian.
У Telegram-бота может быть только один активный webhook. У меня при этом появились три независимых сценария: поддержка пользователей, управление небольшим магазином и внутренние административные команды. Склеивать их в один процесс не хотелось, заводить отдельного бота под каждый сервис — тоже.
Пока я выбирал архитектуру, переезд панели с одного домена на другой неожиданно провёл бесплатный chaos test: Telegram продолжил отправлять updates на старый адрес, получил 301 Moved Permanently и перестал доставлять сообщения. В очереди зависло шесть updates, а со стороны пользователей бот просто замолчал.
В статье разберу диагностику этого инцидента и устройство небольшого open-source router на FastAPI и Redis: с декларативными правилами, дедупликацией, надёжной очередью, retry и HMAC-подписью внутренних запросов.
Проверил 6 AI API-сервисов с бесплатным доступом: VyceAI, Experiential, Dahl, APInex, ModelRouter и TokenForge. Сравнил доступные модели, стартовые лимиты, RPM и поведение API на практике.
Перевод по СБП — это не одна стрелка между двумя сервисами, а лимиты, антифрод, идемпотентность, НСПК, Kafka и уведомления. Я попробовал собрать этот сценарий не на вайтборде, а в виде интерактивного потока — и сразу нашел несколько дыр в архитектуре.
Разработчик приложил к тикету свой токен целиком — чтобы ошибку авторизации можно было воспроизвести. Ошибку починили, тикет закрыли, токен так и остался в задаче, которую видит вся команда и подрядчики.
Токен выглядит как шифротекст: длинная строка из букв, цифр и дефисов, глазами не читается. Отсюда и распространённое допущение — раз не читается, значит, закрыто, и внутрь можно положить что угодно полезное.
На самом деле это base64. Читается одной командой, ключ для этого не нужен, и содержимое видно всем, через кого проходит токен: браузеру пользователя, расширениям в нём, промежуточным прокси, системам логирования.
410 вариантов писем, сотня микросервисов и до 15 файлов, которые приходилось править ради одной нотификации. Добавление письма превратилось в квест: создай компонент, подключи, опиши параметры, зарегистрируй — и молись, что ничего не забыл.
Мы устали и автоматизировали это. Теперь описываем контракт письма в OpenAPI, а CLI генерирует весь boilerplate — от NestJS-артефактов до React-компонента с типизированными пропсами. Часы работы сжались до минут.
Меня зовут Денис, я фронтенд-разработчик в ЮMoney. В этой статье расскажу, почему мы пришли к кодогенерации, как устроили процесс и что в нём изменилось для разработчиков, дизайнеров и тестировщиков. Материал будет полезен тем, кто работает с React, NestJS или TypeScript и хочет перестать писать однотипный код вручную. Особенно если поддержка UI-компонентов и API-слоя отнимает время, которое лучше потратить на реальную логику.
Пятьдесят дней назад планирование моих тренировок переехало из головы и переписки в телеграм-бота. Он читает восстановление из WHOOP и форму из TrainingPeaks, рассуждает через Claude и сам пишет структурированные тренировки обратно в календарь — оттуда они уезжают в Garmin Connect и на часы. За это время он записал в календарь 72 тренировки, а стоимость эксплуатации (дроплет, инференс, подписки) составила около 4 500 рублей в месяц против 30 000+ за живого тренера с теми же подписками на спортивные сервисы.
Официального доступа к TrainingPeaks у меня нет: в партнёрскую программу я написал и получил отказ без объяснения причин. В статье — как я всё равно научился писать в чужой календарь: обмен куки веб-сессии на bearer, GET-merge-PUT вместо несуществующего PATCH, поле, которое на чтении приходит объектом, а на запись требует JSON внутри JSON, и почему IF и TSS плановой тренировки приходится считать самому.
Вторая половина — про то, где это ломалось. Три отказа за пятьдесят дней, и ни один не был виной модели: устаревший в настройках пороговый темп, мой собственный баг с зонами не того вида спорта, один невалидный OAuth-scope, отбивавший запрос согласия целиком, и ответы, обрывавшиеся на полуслове из-за параметра, у которого «по умолчанию» значит разное у разных моделей. Плюс три дня, когда я был уверен, что агент зря меня бережёт, — а данные говорят, что прав был он.
Спортивного результата пока нет: до целевого марафона сто дней, но надеюсь на лучшее.
Всем привет. Я не являюсь разработчиком или DevOps специалистом. Для личных целей набросал скрипт для публикации в ВК, который сначала работал, но со временем стал падать с ошибками. Поэтому решил собрать свой сервис для сбора логов в БД, мониторинга ошибок и отправки ежедневного отчета о работе приложений на почту.
Эксперимент на примере классификации изображений CIFAR-10 с использованием фреймворка ICO: параллельная загрузка данных, аугментации, тренировка и валидация.
Почему без интеграции ИТ‑систем все усилия по цифровизации умножаются на ноль.
В статье разберём четыре подхода, которые компании выбирают, когда доходит до интеграций ИТ‑систем: классические «точка‑точка» (они же «спагетти‑код»), брокеры сообщений вроде Kafka и RabbitMQ, Open Source‑решения и готовые ESB‑платформы. Посмотрим на примерах, как каждый из них работает в бою, какие грабли ждут на каждом пути, и почему «бесплатно» на входе часто оборачивается очень дорогим сопровождением.
Поговорим про вечные костыли, про боль, с которой знаком каждый ИТ‑директор, и про то, как нормальная интеграционная платформа превращает команду из пожарной бригады в архитекторов, а не в вечных тушильщиков пожаров.
Разберём на примерах, как каждый подход работает в реальной жизни, какие у него плюсы и минусы, и почему «бесплатные» варианты часто обходятся дороже.
Работа с файлами в REST API Битрикс24 — та задача, где документация заканчивается ровно там, где начинаются проблемы. Официальные примеры показывают, как загрузить один файл в одно поле. А дальше выясняется, что у crm.item.update и crm.deal.update разные несовместимые форматы, что вложенный base64 через http_build_query уходит в никуда, а сервер при этом честно отвечает «result».
За год я делал файловую логику в шести проектах: перелив сделок между порталами, загрузка фотоописей с мобильного, парсинг PDF из карточек, сборка архивов, синхронизация аватаров. Везде подход получился разный.
Собрал всё в один разбор — шесть подходов с кодом и восемь граблей:
два формата файлового значения, которые нельзя смешивать, и почему при смешении затираются уже прикреплённые файлы;
тихий провал: HTTP 200, в ответе result, поле не обновилось;
useOriginalUfNames=Y, без которого UF_CRM_* молча игнорируются;
downloadUrl приходит с пустым auth= и без подстановки токена не скачивается, а при протухшем токене вместо файла отдаётся HTML-страница с кодом 200;
у одного изображения бывает несколько URL, и часть из них не работает — пришлось делать скоринг вариантов по эвристике.
В конце — таблица «что брать под какую задачу» и чеклист граблей. Двадцать блоков кода, всё из боевых проектов.
Каждый день мы натыкаемся на одни и те же грабли в связке фронта и бэка. Каждые такие грабли — это деньги и время. А если ещё и договариваться не умеем, процессов нет и решать никто не берётся, то дальше начинаются конфликты, атмосфера в команде проседает и проблемы копятся ещё быстрее.
Статья не про саму автогенерацию — с ней всё понятно, про неё и без меня написано достаточно. Мы внедрили генерацию типов из OpenAPI, и она вытащила наружу то, что с генерацией напрямую не связано: кто не хочет писать комментарии, почему у одной сущности два имени и почему у нас падал dev. По сути — про команду, эго и умение договариваться.
Сразу оговорюсь: это не единственно верный путь. Команды и компании разные, у всех свои нюансы, я рассказываю, как было у нас. Но если автогенерации у вас ещё нет и вы соберётесь её внедрять — будете хотя бы знать, что вас ждёт.
Telegram показал Rich Messages с интерактивными кнопками на примере шахмат. Я захотел проверить подход на более насыщенном сценарии и собрал покер‑бота.
Разбираю, как хранить состояние, обновлять одно сообщение, обрабатывать callback и защищаться от устаревших действий.
Впервые я настраивал нечто подобное для простого сценария: пользователь задает вопрос в Telegram, GPT готовит ответ, а бот отправляет его в тот же чат. Через час схема уже работала. Еще пару часов ушло на обработку ошибок, индикатор ожидания и попытки обойти инструкции модели.
Для этих целей я использовал конструктор, поэтому у меня получилась вот такая схема:
Puzzlebot (конструктор ботов) → webhook n8n → OpenAI → API puzzlebot → Telegram
Т.е puzzlebot отвечает за сценарий и общение с пользователем. n8n принимает данные, вызывает модель и возвращает результат. ИИ не получает прямого доступа к Telegram, puzzlebot или платежам: n8n передаёт ему только нужный текст, а действия выполняет по заранее заданному workflow
Возможно, с альтернативными конструкторами схема тоже работает или работает, но чуть иначе – я работаю с этими инструментами и рассказываю свой опыт. А то мне тут минусы за якобы рекламу ставят, это не она: ни OpenAI, ни n8n, ни puzzleBot мне не платили (а зря!))))
Мы устали искать Swagger по чатам и написали свой агрегатор.
— Где актуальный контракт сервиса рассрочек?
— В репозитории.
— В каком?
— Сейчас найду ссылку.
У нас этот диалог повторялся регулярно. Формально API-документация была. Фактически — реестр хранился в памяти нескольких сотрудников, а поиск работал через WB Wiki и корпоративный мессенджер Band.
Меня зовут Олег Леонов, я руковожу отделом системного анализа в финтехе RWB. Мы занимаемся рассрочками и кредитами, инвесткопилкой и WB Кошельком в мобильном приложении и на сайте.
Swagger Aggregator я начинал как пет-проект. Хотел собрать контракты в одном месте и искать по ним примерно так же, как по коду. Потом агрегатор прижился у команды. Расскажу, что в итоге получилось и на каких местах я потратил больше времени, чем рассчитывал.
Если бот копирует один и тот же пост в десять каналов, в Google Analytics все клики свалятся в одну кучу. URL у скрытой ссылки живёт не в тексте, а в MessageEntity, а copyMessages копирует его как есть. Ниже — как пересобрать пост под каждую площадку, не сломав жирный шрифт, эмодзи и health‑check.
Telegram умеет одно очень удобное действие: copyMessages. Берёте сообщение из чата A, кладёте в чат B — форматирование, медиа, альбом, скрытые ссылки, всё на месте. Для рассылок и зеркал это идеальный метод.
Для рекламы он ломает самое важное.
Рекламодатель покупает размещения в разных каналах и смотрит в свою аналитику: откуда пришёл клик. Если во всех десяти постах в text_link лежит один и тот же https://shop.example/sale, UTM бесполезен. Каналы неразличимы. Сделка неразличима. Дата размещения неразличима.
Во многих организациях мобильное приложение появляется значительно позже основной информационной системы. К этому моменту уже существует большая база данных, несколько внутренних интерфейсов, отчёты, фоновые задания и интеграции с другими сервисами. Всё это работает годами, поэтому полностью заменить систему ради нового приложения обычно невозможно.
В такой ситуации возникает понятная идея: подключить мобильный клиент напрямую к существующей базе или быстро добавить несколько методов в старую систему. Это действительно позволяет показать первые экраны, но дальше начинают появляться проблемы. Клиент зависит от структуры таблиц, разные разделы возвращают данные в разных форматах, права доступа проверяются непоследовательно, а любое изменение монолита может сломать уже опубликованное приложение.
В этой статье разберу более устойчивый вариант: отдельный API‑слой между мобильным приложением и существующей системой. Без полной переработки монолита и без попытки сразу перейти на микросервисы.
Корпоративные команды используют MCP-шлюзы, чтобы контролировать, как ИИ-агенты получают доступ к инструментам, сервисам и корпоративным данным. Agentgateway, проект с открытым исходным кодом, развиваемый под эгидой Agentic AI Foundation, маршрутизирует MCP-, Agent-to-Agent-, LLM- и API-трафик между клиентами и внутренними сервисами. Его открытый код, тесты и рекомендации по безопасности делают его полезным объектом для практического изучения безопасности корпоративных шлюзов.
Почему мы классифицируем движение руки, а не картинки со светофорами — и как встроить это в форму двумя строками
Картиночные капчи в 2026-м решаются моделями компьютерного зрения за миллисекунды, а каждый ваш клик по «выберите автобусы» бесплатно размечает чужой датасет. Плюс две свежие проблемы: Google в начале 2025 срезал бесплатный лимит reCAPTCHA с 1 000 000 до 10 000 проверок в месяц, а с апреля 2026 ужесточил модель ответственности за данные по GDPR. Из России reCAPTCHA к тому же нестабильна.
Общая проблема для сети — как доказать, что ты человек, не сдавая паспорт, лицо и номер телефона. Мы предлагаем: drop-in капчу, которую посетитель не кликает, а рисует. В описании — архитектура, ML-часть, приватность и код интеграции. Проект открытый. Буду рад аргументированным замечаниям.
Я измеряю видимость компаний в поиске и в ответах нейросетей. Свой сайт проверил последним: клиентские проекты всегда впереди своих. Результат отрезвляющий — все страниц есть в поиске, проблем с индексацией нет, а в вопросах про услугу без упоминания названия ноль появлений из тридцати двух возможных.
Внутри: как собрать промпт-карту и почему её нельзя писать до замера спроса, чем российский стек отличается от западного, отдельная директива в robots.txt, о которой мало кто знает, и во что обошёлся весь замер — 102 рубля.
