Python *

Представь: пятница, вечер. Ты запускаешь CI для последнего пулл-реквеста, идёшь наливать кофе, возвращаешься… а билд упал. Один тест. Ты перезапускаешь проходит. «Флаки», — вздыхаешь ты и ставишь лейбл flaky. На следующей неделе история повторяется. Потом ещё раз.

Мы привыкли, что нестабильные тесты — это неизбежное зло. Их ловят повторными прогонами, а если повезёт вырезают. Но знаешь, что реально бесит? В 80% случаев корень проблемы можно найти, просто посмотрев на код теста.

Я написал инструмент, который это делает автоматически. Без логов CI, без истории прогонов — только AST и машинное обучение.

Назвал его FlakyDetector. Первая версия была исследовательским прототипом (про него у меня выходила статья на Хабре). А теперь — это полноценный продукт: CLI, веб-дашборд, CI-интеграция и даже React-фронтенд. И да, он open source.

Давай разберёмся, как это устроено.

Я три года пилю Telegram-бот для одного B2C-продукта. В пятницу вечером маркетолог попросил убрать запятую — я потратил двадцать минут на одну запятую, потому что текст был размазан по семи питон-файлам. И тут меня переклинило. Так появилась библиотека, где все диалоги бота живут в одном YAML — с клавиатурами, медиа, условиями и опциональной очередью под лимит Telegram. Выложил на PyPI, делюсь.

В прошлой статье я поделился своими наработками в области работы ИИ с CAD-программами (в моём и нашем случае, SolidWorks). В этот раз поделюсь практическими результатами на примере тестового ядра своей программы.

В статье поделюсь тестами программы, опишу интерфейс и поделюсь мыслями о дальнейшем развитии.

Каждый спринт мы экспортируем JSON из Kibana, листаем сотни записей и говорим себе, что потом превратим их в тест-кейсы, но потом никогда не наступает.

Логи содержат реальные API-вызовы. Настоящие endpoint’ы, реальные payload’ы, настоящие статус-коды из продакшна. Это ближайшее к спецификации описание того, как система ведёт себя на самом деле. И почти ничего из этого не становится автотестом. Потому что переводить вручную дольше, чем идёт спринт.

Я устал от «потом», написал secure-log2test, CLI-инструмент, который читает экспорт Kibana и генерирует готовый pytest-файл. Одна команда. Работающие тесты.

Главное ограничение, которое определило весь дизайн: никакие данные не покидают машину. Никаких вызовов LLM API. Никакого облака, всё локально.

Построение прогноза последовательности (графика) это тема отдельной книги, поэтому в статье я только слегка коснусь двух подходов:
- построение прогноза по одной точке, используя цикл;
- построение прогноза на весь период одним махом.

И постараюсь пояснить на примерах, почему один из них скорее всего будет пустой тратой времени.

Начинающим разработчикам строки обычно кажутся едва ли не самым простым, что есть в языке программирования. Возможно, причина в том, что знакомство с новым языком зачастую начинается с вывода на экран строки Hello, world!.

«Это же просто набор символов, заключённый в кавычки!» — обычно восклицает джуниор Python-разработчик.

Но в Python всё немного интереснее. И за простым синтаксисом скрывается большой набор возможностей, правил и нюансов. Более того, если посмотреть внимательнее, окажется, что в Python целый зоопарк строковых представлений и связанных с ними особенностей.

Привет, я Евгений Бартенев, автор и техлид курса «Python-разработчик» в Практикуме. В этой статье последовательно разберу, какие бывают строки в Python, чем они отличаются друг от друга, какие возможности дают и какие подводные камни могут встретиться в работе с ними. Поговорим и о базовом использовании, и о важных деталях, которые стоит помнить каждому разработчику.

В логистике проблема часто не в том, что нет данных.

Проблема в том, что данные разбросаны по разным местам.

Одни заявки лежат во внутренней системе, другие — в закрытых кабинетах грузоотправителей, третьи — на тендерных площадках, четвёртые приходят через Excel‑выгрузки, пятые доступны только через веб‑интерфейс. Где‑то есть нормальный HTTP‑обмен, где‑то данные спрятаны за фронтендом, где‑то приходится читать DOM‑таблицу, а где‑то сначала кажется, что всё просто, пока не выясняется, что цена приходит в копейках, маршрут состоит из трёх точек, а тип кузова записан как «тент 20т, верхняя загрузка».

Для менеджера всё это выглядит не как единый рынок грузов, а как набор вкладок в браузере.

Открыть один кабинет. Потом второй. Потом третий. Проверить направление. Сравнить цену. Посмотреть дату. Понять, где реф, где тент, где просто «20 тонн». Не забыть про аукцион, у которого скоро истекает время. Потом всё равно перенести результат в таблицу или открыть внутреннюю панель.

В какой‑то момент стало понятно: нам нужен не ещё один парсер, а единая витрина.

Так появился внутренний агрегатор заявок — условный «Авиасейлз для логистики».

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

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

После того как вердикт уже был вынесен, я прогнал то же самое дело через свой Telegram-бот на Claude Sonnet 4.6. Те же скриншоты, та же фактура, никаких подсказок.

Бот выдал тот же вердикт за двенадцать минут. Не на 100%, но суть совпала: кто прав, кто что должен сделать, какой срок, что при неисполнении.

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

Внутри статьи: архитектура с двумя ИИ (секретарь на Haiku отсеивает мусор, арбитр на Sonnet выносит решения), куски кода с промптами, дебаунс через asyncio чтобы бот не бомбардировал участников ответами, проверка криптотранзакций по 12 блокчейн-сетям параллельно, изолированные приватные группы через Telethon-userbot.

И главный вопрос в конце: пора ли увольнять живых арбитров?

Поговорим о том, как превращать последовательности пользовательских событий в векторы, зачем обучать BERT на «языке» клиентского поведения и почему embedding‑пространство может неожиданно начать отражать будущую ценность пользователей

Gunicorn кажется простым, пока не сталкиваешься с эксплуатацией: внезапные ошибки 502, зависшие воркеры и странное поведение при перезапусках. За этими симптомами стоят вполне конкретные причины — от медленных клиентов и отсутствия буферизации до особенностей реализации GThread и механики Graceful Shutdown.

В этой статье разберём реальные сценарии отказов, посмотрим, как менялась архитектура GThread в разных версиях Gunicorn, и соберём практичную конфигурацию с Nginx, Docker и Kubernetes, которая ведёт себя предсказуемо под нагрузкой.

ClearML — это целый космос, так что мы продолжаем разбирать его компоненты. В прошлой статье мы рассматривали ClearML Session и настраивали удаленную среду разработки с Jupyter Lab и VSCode. В этот раз поговорим о ClearML Agent и разберем, как с его помощью запустить обучение на удаленном сервере, в частности, Google Colab.

Итак, поехали!

Привет, Хабр! Меня зовут Никита Пастухов — автор FastStream, Principal Engineer и мейнтейнер AG2 (фреймворк для разработки агентов). Я уже 8 лет в разработке, последний год - по уши в агентах.

И я хочу доказать вам, что написать своего агента не сложнее, чем написать CRUD

Почему это вообще нужно доказывать? Потому что есть заметный разрыв между тем, что происходит с AI в мире, и тем, что происходит в среднестатистической российской компании. В мире — в каждой компании подписка на OpenAI, миллиард стартапов с AI-продуктами, агенты глубоко интегрированы в бэкофис. В России — «опасно, хостим свои модели», «непонятно» и чат-боты поддержки. В мире инженеры уже умеют разрабатывать агентов. В России — «что это вообще такое?»

Поэтому давайте разберём устройство агентов на примере OpenClaw — самого хайпового “личного AI-агента” прямо сейчас. Он живёт в вашем мессенджере, разбирает почту, ведёт соцсети, пишет код, деплоит сервисы. Его популярность — свидетельство того, насколько мало люди пока используют агентов в быту. Для тех, кто в теме, OpenClaw не привнёс ничего нового.

Это восьмая статья из моей серии про инженерные решения в ONEMIX. До этого было про клиентскую часть мессенджера: кэш сообщений, E2E, WebRTC звонки, Electron, outbox‑паттерн. Параллельно про AI‑агента Лиру и мнение про вайб‑кодинг.

Сегодня про серверную сторону. Backend ONEMIX — это один файл main.py на 19 603 строки, 379 эндпоинтов, FastAPI + SQLite, держит мессенджер с регистрацией через SMS, звонками через LiveKit, E2E через Double Ratchet, push‑нотификациями на iOS и Android. Этот файл я пишу больше года. За это время он эволюционировал из прототипа на 800 строк в production монолит.

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

Сразу важная оговорка. У меня не было требования держать 100к одновременных пользователей или 10к RPS. Это бэкенд под мобильное приложение с трафиком который для соло‑разработчика разумно поддерживать одному. Если у вас задачи другого масштаба, мой опыт может не подойти.

Для разработчиков умных камер, умных видеорегистраторов и нейросетевой видеоаналитики ПО видеонаблюдения нужна нейросеть, способная работать в реальных условиях наших улиц. А там никто с профессиональной камерой не ходит, правильный ракурс не настраивает, свет не выставляет, без сжатия не снимает и вообще все делает вопреки здравому смыслу учебников ВГИК.

Гамбит, конечно, подойдет для любых других задач, но здесь сделан упор на удобство сбора материала ИЗ систем видеонаблюдения и на разметку датасета с целью создания нейросетей ДЛЯ систем видеонаблюдения.

Гамбит не столько для отшлифованных фоток и рилсов из Интернета, а как раз наоборот – для не особо качественных видеозаписей из архивов видеонаблюдения. В Спецлабе называют такой контент «диким».

FastMCP позволяет быстро собрать MCP‑сервер, но скорость легко оборачивается ошибками: лишние токены, слабые схемы, сырые API‑примитивы, плохая обработка ошибок и риски безопасности.

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

Приветствую всех! Эта статья будет первой в серии статей про основы глубокого обучения. В этой части я расскажу про то, что такое модели, искусственный интеллект (ИИ), машинное (МО) и глубокое обучение (ГО), про виды этапа обучения моделей, что такое нейронные сети, градиентный спуск и обратное распространение. В конце затронем теорию свёрточных нейронных сетей.

В большинстве туториалов по 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). Ниже будет простыми словами объяснено, что это такое, далее мы разберём основные детали идемпотентности, часто понимаемые неверно и, наконец, проиллюстрируем её на полном примере. 

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

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