Python *

В большинстве туториалов по Telegram-ботам всё начинается с одного куска кода: получили токен у @BotFather, поставили python-telegram-bot или aiogram, написали хендлер, deploy. Это Bot API. И в 90% задач этого хватает.

А потом приходит задача которую Bot API не закрывает в принципе: программно создать супергруппу под конкретный проект и добавить туда нужных людей по @username, и сделать это десятки раз в день. Bot API такое не умеет даже теоретически - метода «создать группу» там нет, метода «добавить юзера в группу» тоже. Лезете в полную документацию Telegram API искать обход, упираетесь в раздел  channels.createChannel  /  channels.inviteToChannel под MTProto, и начинается совсем другая история - не Bot API, а user-бот через telethon.

В этой статье разбираю как мы сделали production MTProto user-бот на FastAPI + Telethon. Под капотом: Cloudflare WARP для обхода DPI (без него с российского VPS просто не подключиться), Singleton-клиент с keepalive, in-memory cache resolve-юзеров, и 5 ограничений Telegram которые знают только те кто лез туда ногами. Реальный production-сервис у клиента в нише строительства/монтажа, обслуживает связку Planfix → Telegram-группы под каждый проект.

Сервис написан на Python 3.11. Стек: Telethon 1.43.2, FastAPI 0.136.1, Uvicorn 0.46.0, Pydantic 2.13.4. На VPS под systemd, наружу через Cloudflare Tunnel. Вызывается из n8n через HTTP-ноду.

Бывают дни, когда на работе делать нечего. А бывают дни, когда ты — программист и звукорежиссёр одновременно, и в голову приходит странная мысль: «А что, если взять аудио, превратить его в картинку-спектрограмму, сжать эту картинку как фотографию (JPEG, WebP, AVIF), а потом попробовать восстановить звук обратно? Как оно будет звучать?»

Спойлер: иногда — удивительно хорошо. Иногда — как из унитаза. Но всегда — интересно.

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

Идемпотентность в System Design: полный пример

Идемпотентность часто упоминается при проектировании систем (system design). Ниже будет простыми словами объяснено, что это такое, далее мы разберём основные детали идемпотентности, часто понимаемые неверно и, наконец, проиллюстрируем её на полном примере. 

Что такое идемпотентность?

Операция является идемпотентной, если при однократном или многократном выполнении она всякий раз даёт один и тот же результат.

В финале хакатона Dev-to-Dev: Agentic Engineering Challenge на втором месте оказался самый качественно написанный проект соревнования. 65 тестов, типы, защита от path traversal, Docker с non-root user, архитектура, в которой видно инженера, а не участника хакатона. И именно поэтому он не победил.

Победителем стал не самый чистый код и не самая смелая архитектура. Это решение точнее всех попало в то, что мы пытались измерить — agentic engineering. Термин, которому едва пара лет, и в который каждая команда пока вкладывает что-то своё.

Ниже разбираем 10 финалистов хакатона: что они построили, где заработали баллы и где их потеряли, какие архитектурные ставки сработали — и почему «писать хороший код» и «строить агентные системы» в 2026 году превратились в разные навыки.

Микрофреймворк для параллельного обучения AI-агентов в средах Gymnasium с графическим интерфейсом на wxPython. Решает классическую проблему «зависшего GUI» при длительном обучении нейросетей: вычисления вынесены в отдельные процессы-сервисы, а интерфейс остаётся полностью отзывчивым. Поддерживает плагинную систему для добавления новых сред, визуализацию прогресса (графики Matplotlib), генетический алгоритм обучения (нейроэволюцию через DEAP) и сборку в один .exe через PyInstaller с автоматическим CI/CD.

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

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

Казалось бы, ничего страшного. Но ведь можно по-другому, верно?

Этот опыт применим не только для игровых серверов, но и для любых проектов, в которых используются сокетные соединения и разрыва соединения влияет на UX

В условиях современного банковского надзора внезапный дефолт крупного банка — событие экстраординарное, особенно в США. Финансовые регуляторы выстроили глубоко эшелонированную систему защиты: Центральные банки непрерывно мониторят нормативы, проводят стресс-тесты и, как правило, действуют на упреждение.

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

В статье воссоздадим дефолт SVB в банковском ALM симуляторе: наберем тот самый портфель ценных бумаг, смоделируем изменение рыночной конъюнктуры и поведение вкладчиков.

Покажем, как невидимые банковские риски превращаются в реальную дыру в капитале, и убивают крупнейшие банки.

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

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

Лира берёт на себя часть этой работы. Это не корпоративный чат‑бот, не ChatGPT с настройками компании. Конкретный продукт с конкретными функциями:

Как соединить LLM-агента на AG2 с Dishka в одном DI-контейнере. На рабочем примере: FastAPI + SSE-стрим по AG-UI + Postgres, тулзы с типизированным внедрением сценариев, отдельная транзакция на каждый tool call. Плюс грабли при сборке.

Инженерия качества: Как перестать надеяться на удачу и начать измерять своих ИИ-агентов [Часть 1]

LLM глючит в продакшене? 🤖 Хватит надеяться на «vibe-check»! Узнай, как внедрить инженерный подход к качеству ИИ-агентов. В статье, будет рассмотрена концепция Golden Set, его автоматической генерации для RAG системы, на примере библиотеки RAGAS

Приветствую всех читателей Хабр.

Думаю, многим знаком этот сценарий: появляется задача — и первая мысль: «скормлю все LLM, она разберётся». Поначалу получается красиво, всё работает и есть первые результаты. Потом начинаешь проверять детали и замечаешь, что модель местами добавляет текст от себя. Потом смотришь на затрачиваемое время и понимаешь, что при текущей скорости обработка всего объёма документов закончится через год.

Именно в такой ситуации я оказался, когда захотел обработать базу ГОСТов.

Эта статья — про то, как я прошёл путь от «кидаем всё в LLM» до детерминированного пайплайна на классических NLP-инструментах. И про то, как в этом помогли те же самые языковые модели — но уже в роли консультантов, а не рабочей лошадки.

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

Поехали!

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

Так появился Sumify: бот, который сам достает главное из медиа и превращает его в выжимку, конспект и ответы на вопросы.

Если что такое параллелизм более-менее все разработчики понимают, то объяснение асинхронности через аналогии с кассирами/поварами вредно, так как вводит в очень большое заблуждение.
В данной статье я разберу эту проблему на примерах Python и Go и попробую дать свою правильную аналогию.

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

В этой статье поделюсь своим опытом и намеченными планами.

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

Часть моделей числится бесплатными, но отвечает нестабильно. Часть внезапно исчезает из выдачи провайдера. Часть формально жива, но по качеству ответа годится только для демо. Иногда пользователь выбрал одну модель, а провайдер вернул ошибку. Иногда ответ пришел, но уже от другой модели. Иногда список моделей на фронте устарел, а backend уже живет в другой реальности.

То есть проблема тут не в том, как красиво показать список LLM. Проблема в том, как построить агрегатор, который умеет выбирать живые free-модели, переживать сбои провайдера и не врать интерфейсу о том, какая модель реально ответила.

В одном из своих проектов эта задача решалась не через бесконечный каталог моделей, а через более жесткий инженерный контур. Backend получает сырой список моделей от провайдера, очищает его, отбирает только подходящие free-варианты, оставляет по одной модели на бренд, отдает этот набор на фронт, а во время реального запроса умеет сделать fallback на модель другого бренда. При этом в ответе возвращается не только текст, но и actual_model, чтобы интерфейс знал, кто реально сгенерировал результат.

Немного погрузимся во внутреннее устройство Apache Airflow и разберёмся, что на самом деле происходит за красивым синтаксисом TaskFlow API. Посмотрим, как работают декораторы @task и @dag, каким образом обычные Python‑функции превращаются в задачи Airflow и за счёт какой «магии» строится граф зависимостей. А заодно напишем собственный мини‑пример, чтобы лучше понять архитектурные идеи, на которых построен современный Airflow.

На каждом ревью найдётся кто‑то, кто спросит: «Зачем четыре файла, если это один пайплайн?»

А затем, давайте объясню!

Вот есть Postman-коллекция из 40 запросов. Разложена по папкам, и с тестовыми скриптами, которые проверяют статус-коды. Вы потратили на неё время, она хороша.

И ещё у вас есть CI-пайплайн, который про Postman никогда не слышал и слышать не собирается.

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

Получается, коллекция документирует API. CI тестирует API. Они описывают одну и ту же систему и при этом никогда не встречались.

Я написал postman2pytest, чтобы их познакомить.