Python *

Как автоматизировать перехват лидов из Telegram, если конкуренты прячут свои чаты и запрещают копирование ссылок? Клиент пришел с задачей: парсить комментарии из 50 крупных каналов в реальном времени. Проблема в том, что для прослушивания нужен ID скрытой группы, который менеджеры вытаскивали руками, тратя на это полдня. В этой статье показываю, как мы обошли визуальные ограничения интерфейса, вытащили нужные ID напрямую через API Telegram и сократили рутину с десятков часов до пары секунд. Внутри — готовый скрипт-сканер на Python.

FastAPI окончательно закрепился в стеке Python-разработчиков, а значит, на собеседованиях вас точно будут гонять по корутинам, Pydantic и Dependency Injection. Я собрал 10 реальных вопросов (включая коварные подвохи от сеньоров!), которые сейчас задают джунам и мидлам. Никакой сухой теории из доков — только практика. Го под кат — проверим, насколько вы готовы к следующему интервью!

Не всегда стоит патчить ответ от внешнего HTTP-сервиса через mocker.patch. В таких тестах приложение возвращает ожидаемый ответ, но важная часть логики остаётся непроверенной: какой URL собрал клиент, каким методом ушёл запрос, какое тело было отправлено и как обработался ответ внешнего сервиса. В статье показываю другой подход: мокать не метод клиента, а сам внешний HTTP-сервис. Для клиентов на requests используем requests-mock, для клиентов на httpx — pytest-httpx. Так тесты остаются быстрыми и без реальной сети, но при этом проходят через настоящий код клиента и позволяют проверять состояние фейкового внешнего сервиса, тем самым улучшая качество тестов.

Когда я начал пользоваться Claude Code, у меня было ощущение, что я дал умному человеку доступ только к одной папке на компьютере. Он видит код, помогает с задачами — но не знает, что происходит снаружи. Нет доступа к чатам, к базе данных, к GitHub issues. Всё это приходилось копировать руками и вставлять в контекст.

Потом я узнал про MCP.

Если вы работаете с базами данных и используете ORM, вы, вероятно, сталкивались с той же проблемой, что и я. ORM отлично подходят для отображения таблиц на объекты. Но они начинают мешать, когда запрос становится сложным: агрегации, тщательно продуманные JOIN’ы, формы отчетов, которые не соответствуют одной модели на таблицу. Вы боретесь с ORM, переходите на сырой SQL, а затем вручную пишете связующий код (маппинг).

Не каждый SELECT возвращает то, что подходит под одну ORM-модель. SQL - это лучший язык для доступа к данным. Лучшие ORM, которые я использовал, такие как Drizzle, побеждают, потому что они остаются близки к SQL. Я хотел пойти дальше: хранить SQL в системе контроля версий и генерировать из него типизированный Python.

Именно поэтому я создал nORM (no ORM - не ORM) и выпустил версию v0.1.0 на этой неделе (мой первый опенсорс проект).

Вчера pypi.org несколько часов был недоступен из российских сетей. Для кого-то это «подождём», а для CI/CD, прода и просто рабочего дня — это вставший pip install и красные сборки.

Причина системная: pypi.org и хранилище пакетов files.pythonhosted.org живут на CDN Fastly, у которого нет точек присутствия в России и доступ к которому уже не раз ограничивался. Вчерашняя недоступность — не первая и почти наверняка не последняя.

Хорошая новость: чтобы застраховаться, не нужно зеркалировать весь PyPI (это терабайты и постоянная синхронизация). Достаточно поднять лёгкий реверс-прокси на nginx. В этом гайде соберём такой с нуля — с кешированием и прозрачным переключением для pip.

Не хотите хостить сами? Есть уже готовое зеркало — pypi.depkit.ru. Оно работает на российских IP, имеет большой объём кеша под пакеты и отдаёт их очень быстро. Можно просто подставить его в index-url (как — в конце статьи) и пропустить всю настройку. Дальше — для тех, кому интересно поднять своё.

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

Но довольно быстро стало понятно, что с временными и ресурсными ограничениями лучше не пытаться написать маленький PagerDuty. Поэтому я сузил задачу до более реалистичного ядра: локального RAG-сервиса, который ищет по документации, ранбукам и коду, а затем передаёт найденный контекст в LLM.

Так появился llmortem — FastAPI-сервис, который можно подключить к OpenWebUI как OpenAI-compatible backend.

В статье расскажу, как устроена архитектура, почему я начал с BM25, зачем индексировать docstring’и и какие ограничения у такого подхода.

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

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

В этой статье мы углубимся в стохастический анализ и рассмотрим методы определения стационарности временных рядов в реальном времени. Разберем математический аппарат расширенного теста Дики-Фуллера (ADF), причины его интеграции в ядро нашей торговой системы и особенности реализации на Python при работе с большими массивами данных.

Когда пишешь библиотеку, рано или поздно упираешься в движок. Не в красивый внешний интерфейс и не в обёртки, а в ту часть внутри, которая гоняет процесс по состояниям: что-то сгенерировал, проверил, решил, что делать дальше, повторил. Пара флагов, цикл while, большой if посередине, и через месяц вы уже сами не помните, какие переходы там вообще возможны и почему одна из веток недостижима.

Недавно я собирал ровно такой движок и наткнулся на библиотеку, которая делает эту работу заметно аккуратнее. Называется pydantic-graph. Про неё почти не пишут, хотя на ней стоит весь pydantic-ai, агентский фреймворк от авторов Pydantic. Дальше я расскажу про неё на конкретном примере, харнессе надёжности для слабых языковых моделей.

Сразу оговорюсь про термин, потому что он сейчас на слуху. Харнесс это не только MCP, скиллы и память. Это ещё и робастность, в том числе у совсем небольших моделей. Вот эту вторую часть я и беру за пример. Но статья не столько про модели, сколько про сам подход. Основная мысль простая: это удобный способ собрать движок для чего угодно, где есть состояния и переходы, и при этом не утонуть в собственном цикле.

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

В статье разберём, как Pipeline в sklearn помогает собрать обработку данных и модель в единый воспроизводимый конвейер, снизить риск data leakage и упростить работу со сложными ML‑сценариями.

Полгода назад я написал статью про FlakyDetector — инструмент, который ищет нестабильные тесты по одному лишь исходному коду, Потом была статья FlakyDetector 2.0 . AST + CatBoost, 37 признаков, вроде бы всё круто.

Но один комментарий меня добил.

Пользователь Ariless рассказал реальный кейс: в их проекте тест падал с SLOT_OVERLAP — не потому, что в коде теста было что-то плохое, а потому что фикстура была общая на несколько тестов (shared scope). Предыдущий тест не успел почистить слот — следующий упал.

Тема экономии токенов сейчас дико популярна, и мы с ребятами в Гильдии AI-инженеров знатно её пообсуждали. Напомню краткую суть: там связка Serena (LSP) + Semble (векторные эмбеддинги) + Ripgrep (поиск координат) показала себя абсолютным топом для точечной навигации.

Но в комментариях и личке мне тут же начали советовать: «Нахлобучь сверху еще rtk для сжатия вывода терминала и context-mode для полнотекстового индекса репозитория! Тема прокси-экономии сейчас на пике хайпа, сэкономишь еще больше!». Я подумал за**ись.

И решил провести душный чек. Взял популярный open-source проект supermemory (~180 файлов, JS/TS) и замерил: действительно ли добавление rtk + context-mode дает реальный профит поверх моего текущего сетапа, или это просто карго-культ и оверхед, который утянет бюджет в минус?

Привет, Хабр!

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

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

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

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

Компании уже оплачивают сотрудникам Claude Code, Cursor или Codex, но не всегда видят рост производительности.

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

Разбираю, зачем команде общая память, и при чём тут GBrain, OpenBrain и обычные Markdown-файлы.

Любой аналитик знает, что самым надёжным способом проверки гипотез являются рандомизированные контролируемые эксперименты (RCT), или, как их называют в народе — A/B-тесты. На практике часто возникают ситуации, когда провести A/B-тест невозможно — в основном это происходит по этическим или техническим причинам. Однако бывают кейсы, когда рандомизация невозможна потому, что treatment-ом является определённое действие пользователя. Например, treatment-ом может быть оформление платной подписки или отмена бронирования на сервисе. Давайте назовём такой вид воздействия добровольным.

В русскоязычном пространстве, и в частности на Хабре, достаточно много статей, посвящённых таким методам Causal Inference, как DiD, PSM и Causal Impact. Тем не менее, к моему удивлению, практически нет статей, посвящённых методам на основе ортогонализации и regression adjustment, хотя, на мой взгляд, именно эти методы являются самыми удобными для оценки эффекта от добровольного treatment-а. Пришло время исправить это недоразумение и разобрать метод Double/Debiased Machine Learning (DML) и Partial Linear Regression для задач Causal Inference!

Мне стало любопытно: смогу ли я распарсить карту HotA и написать такой парсер, который сможет быстро отвечать на вопросы вроде: «Где можно выучить заклинание “Городской портал”?», «Где найти артефакт, например, Чёрный шар?», «Есть ли в тюрьме герой Джелу?» и всё в таком духе.

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

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

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

Большинство Telegram-ботов выглядят одинаково. /start — стена текста — кнопки. Пользователь тыкает, получает ответ, закрывает. Никакого ощущения что за ботом стоит что-то живое. Конверсия падает, люди не возвращаются, и ты не понимаешь почему — ведь функционал вроде работает.

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

В этой статье я собрал 7 конкретных фич с кодом на aiogram 3.x которые это исправляют. Некоторые внедряются за пять минут, некоторые требуют больше времени — но каждая влияет либо на удержание, либо на монетизацию, либо на рост аудитории. Без воды, сразу к делу.

Спроси ChatGPT или Claude про топовых экспертов в твоей нише и с большой вероятностью себя в ответе не найдёшь. Так было и у меня: руковожу AI-направлением в Т-Банке, выступаю, пишу, а модель об этом не знала, потому что меня не было в данных, по которым она отвечает. За вечер я это починил и собрал пошаговый гайд: как сделать сайт читаемым для агентов, попасть в Wikidata и Google Knowledge Graph. Без IT-бэкграунда, по шагам, с готовым репозиторием для форка.

Как обычно в начале месяца мы рассказываем вам о том, что изменилось в GigaIDE за прошедший месяц — май. Соответствующий обзор за апрель доступен здесь. Ниже — краткий обзор обновлений Pro-функциональности GigaIDE, который можно найти на нашем маркетплейсе.

Как мы избавили общепит от часа ручной работы каждое утро: разобрали реальный кейс синхронизации стоп-листа из СБИС Presto в каталог на Tilda через CommerceML. Поток на Python/FastAPI, дебаунс через SHA-256, eventual consistency без очередей и грабли, на которые наступили в проде.