Python для этого подходит идеально: на нем пишут и быстрые прототипы с MVP, и промышленные серверные и высоконагруженные системы. Значит, распознавание можно встроить прямо в то приложение, где данные уже обрабатываются, без отдельного сервиса между ними.

Smart ID Engine распознает удостоверяющие личность документы и отдает структурированные данные и изображения отдельных полей: фото владельца, подпись, штамп. Полный код доступен на GitHub.

Пошаговое встраивание в Python-приложение

1. Подключение библиотеки

Для подключения библиотеки в проект необходимо скопировать в ваш проект файлы обертки (папка bindings), саму библиотеку (папка bin) и конфиг распознавания (папка data-zip с файлом bundle_…se). Обертку и библиотеку нужно подключить в проект:

и импортировать библиотеку:

2. Создание движка распознавания

Движок распознавания создается из конфига распознавания (data-zip/bundle_…se). В параметрах необходимо указать путь к нему и параметр ленивой инициализации (True/False). При значении False все внутренние объекты будут инициализированы сразу не дожидаясь, когда они понадобятся для какой-то конкретной сессии.

3. Настройка распознавания

Настройка распознавания (settings) включает в себя выбор режима распознавания (mode), маски документа (document type masks), а также при желании указание дополнительных опций. Для распознавания документа по одному изображению используется режим singleshot (если документ распознается по нескольким картинкам — default). Для внутреннего паспорта РФ требуется специфицировать маску документа, указав rus.passport.national в доступных к распознаванию документах.

4. Распознавание документа

Сессия распознавания паспорта РФ подразумевает распознавание одного документа (по одному или нескольким кадрам). Для распознавания другого документа создайте новую сессию, настройки можно оставить те же. Создание сессии осуществляется путем указания ранее созданных настроек (settings) и персонализированной подписи (personalized_signature).

Загрузка изображения паспорта РФ по пути (path_to_image):

Распознавание паспорта:

Получение результата:

5. Извлечение информации из результата распознавания

Тип документа

Вывод:

Описание документа

Вывод:

Текстовые поля

Включают все текстовые строки, которые были извлечены с документа

Вывод:

Полный вывод содержит более 30 полей, включая информацию об органе выдачи и MRZ-строку.

Поля изображений

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

Вывод:

Заключение

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

При этом распознавание паспорта на Python – не единственный вариант интеграции Smart ID Engine. Та же библиотека может работать и как часть мобильного или десктоп-приложения, а также прямо в браузерах или мессенджерах. Выбор конкретного варианта зависит от того, какие документы нужно распознавать и откуда поступает изображение – подробнее об этом можно прочитать на сайте Smart Engines.

Реклама. Рекламодатель: ООО «Смарт Энджинс Сервис» ИНН 7728328449, erid: 2W5zFJof1MB

Для тех, кто гоняет Polars в пайплайнах, это значит два дела на сегодня. Во-первых, после обновления часть запросов может вернуть строки в другом порядке: потоковый движок не гарантирует порядок для join, group_by и unpivot, если явно не попросить. Во-вторых, код, который годами «работал» на неявных приведениях типов и молчаливом заполнении пропусков, начнёт падать с ошибкой. Разработчики называют это осознанной политикой: ошибка сразу лучше неверного результата через двадцать минут работы пайплайна.

• RC ставится командой pip install polars==2.0rc1; финальный 2.0 выйдет в ближайшие недели, точной даты нет.
• LazyFrame.collect() по умолчанию идёт через streaming-движок; по ожиданиям авторов, в совокупности он «легко в 5 раз быстрее» старого in-memory и заметно экономит память; независимых замеров RC нет.
• Порядок строк после join, group_by и unpivot больше не гарантирован; для join и group_by порядок возвращает параметр maintain_order, для unpivot нужен явный sort; старый движок включается через pl.Config.set_engine_affinity("in-memory") или collect(engine="in-memory").
• is_in с разными типами, горизонтальный concat с разной высотой, касты строк в даты и целых в Enum теперь бросают исключение вместо тихого приведения.
• Большинство удалённых методов и параметров отвечают типизированными ошибками AttributeRemovedError и ArgumentRemovedError с подсказкой, чем заменить.

Почему потоковый движок потребовал мажорной версии

Polars давно развивает два движка. Классический in-memory собирает результат каждой операции целиком в памяти. Потоковый разбивает данные на куски и прогоняет их через план запроса конвейером, поэтому промежуточные результаты не раздуваются. До 2.0 потоковый движок нужно было включать явно; теперь режим engine="auto" выбирает именно его.

Цена такого дефолта в порядке строк: потоковый движок для ряда операций его не гарантирует. Старый движок порядок сохранял, и на это молча полагалось много кода: например, брали первую строку после группировки и считали её «самой ранней». В 2.0 такие места нужно найти и явно попросить порядок (у join и group_by есть параметр maintain_order, после unpivot остаётся явный sort):

Заявление о скорости стоит читать как оценку вендора: «в сумме мы ожидаем, что потоковый движок будет легко в 5 раз быстрее», со ссылкой на собственные бенчмарки Polars. Независимых замеров на RC пока нет, и выигрыш зависит от запроса: на маленьких таблицах, которые целиком помещаются в кеш, разница будет меньше, чем на группировках по десяткам гигабайт.

Где код перестанет молчать об ошибках

Вторая тема релиза сформулирована в посте так: ошибки должны подниматься заранее, а не через 20 минут работы пайплайна, и неявное поведение при несовпадении данных должно включаться явно, а не быть дефолтом. Авторы отдельно отмечают, что строгость стала ценнее с приходом ИИ-агентов: агент может вызвать collect_schema(), проверить типы без чтения данных и быстро получить обратную связь. Примеры из поста и руководства по миграции:

• is_in с разными типами. Раньше Int64 и Float64 приводились к общему супертипу, даже если это теряло точность. В примере из поста идентификатор 9007199254740993 при касте в float64 округлялся до 9007199254740992 (граница, до которой float64 представляет все целые точно), и проверка по списку «помеченных» аккаунтов давала ложное совпадение. В 2.0 это InvalidOperationError: кастовать нужно самому и осознанно.
• Горизонтальный concat. Таблицы высотой 5 и 4 раньше склеивались, а недостающая ячейка молча становилась null; типичный сценарий из поста: тихо упавшая задача за один из дней. Теперь ShapeError, а старое поведение включается через how="horizontal_extend".
• Касты заменены специализированными методами. Целые в Enum или Categorical и обратно: вместо cast() нужны .cat.to() и .cat.physical(). Строка в дату: вместо cast(pl.Date) методы .str.to_date() и .str.to_datetime(), которым можно явно задать формат. Кастовать плоскую колонку в List через cast(pl.List(...)) тоже нельзя, для этого есть pl.list().
• Булевы операторы между Boolean и целыми числами теперь ошибка; std() и var() для Duration удалены, сначала переводите в микросекунды через .dt.total_microseconds().
• Каст между Struct с разным числом полей при strict=True (дефолт) падает, а не обрезает лишние поля; руководство помечает это отдельным предупреждением, потому что раньше данные терялись молча.

Отдельный набор изменений касается чтения CSV. При сканировании набора файлов схема теперь выводится по первым 10 файлам, а не по всем (параметр infer_schema_files). Автоматические имена колонок для файлов без заголовка начинаются с column_0, а не column_1; это же касается read_excel и read_ods. Пользовательская схема в scan_csv сопоставляется с файлом по именам колонок, а не по позиции: раньше первая запись схемы молча получала данные первой колонки файла, даже если имена не совпадали. Для лишних и недостающих колонок появились параметры extra_columns и missing_columns, по умолчанию оба бросают ошибку.

Что будет со старым кодом

Для большинства удалений библиотека получила два типизированных исключения (документация предупреждает, что часть удалённого по-прежнему даёт обычные AttributeError и TypeError): polars.exceptions.AttributeRemovedError для удалённых методов и атрибутов и polars.exceptions.ArgumentRemovedError для удалённых параметров. Оба сообщения указывают на замену:

По словам Винка, большая часть удалённого давно помечена как deprecated, и у тех, кто обновлялся регулярно, пайплайны пострадать не должны. Команда просит сообщать, если из библиотеки убрали что-то, на что реально полагались. Смена движка не затрагивает eager-API DataFrame: выигрыша в скорости там не будет, потому что дефолт меняется только у LazyFrame. Остальные несовместимости на eager распространяются полностью: строгий concat, новые правила read_csv, убранные касты и удалённые методы.

Как проверить свой проект до финального релиза

1. Поставьте RC в отдельное окружение: pip install polars==2.0rc1. В прод его тащить рано, это кандидат в релиз.
2. Прогоните тесты и посмотрите на исключения AttributeRemovedError, ArgumentRemovedError, InvalidOperationError и ShapeError: каждое сообщение содержит подсказку с заменой.
3. Найдите места, где код полагается на порядок строк после join, group_by или unpivot: сортировки «по умолчанию», head(1) после группировки, сравнение с эталоном по позициям. Добавьте maintain_order (join, group_by) или явный sort (unpivot).
4. Если результат обязан совпадать со старым до байта, зафиксируйте старый движок на время миграции: pl.Config.set_engine_affinity("in-memory").
5. Проверьте чтение CSV без заголовка (сдвиг нумерации колонок на единицу) и scan_csv с явной схемой (сопоставление по именам).

В планах ветки 2.x, о которых команда, по её словам, «недостаточно говорила публично»: полноценная out-of-core обработка для потокового движка, новая архитектура IO-плагинов, собственный читатель S3, расширенное покрытие SQL, планировщик на основе оценки стоимости с переупорядочиванием join и отказ от mmap, после которого конвейер станет асинхронным от начала до конца. Сроков по этим пунктам нет. Замечания по RC команда принимает в issues на GitHub.

Источники: Pre-release of Polars 2.0 (блог Polars, Ritchie Vink), Руководство по переходу на Polars 2.0, Бенчмарки Polars

Изображение на обложке: Логотип: Polars

Практический вопрос для тех, кто обновляется: что сломается. Удалены torch.cholesky, torch.qr и параметр профилировщика use_cuda; acc_policy="balanced" в LinearCrossEntropyOptions теперь вызывает ValueError, нужно "compact"; у скалярного clamp изменился градиент на границе. А torch.compile на Python 3.15 в этом релизе не работает и завершается явным RuntimeError.

• NVGEMM добавляет в Inductor ядра CUTLASS, сгенерированные CuTeDSL, с fusion эпилогов, scaled и NVFP4 GEMM.
• Distributed: новый backend nccl2 с неблокирующими коммуникаторами и eager splitting; c10d умеет перенастраивать process group на месте; Flight Recorder работает с любым backend.
• torch.switch обобщает torch.cond на несколько веток, torch.while_loop захватывается CUDA Graphs, @dynamic_spec единообразно описывает динамические формы для torch.compile, torch.export и make_fx.
• Apple Silicon получил нативные SVD, eigh, QR и Cholesky; появились ROCm 7.14 wheels, захват графов на Intel XPU и цель sm_107 для NVIDIA Rubin.
• Wheels для Python 3.15 и 3.15t собраны для Linux x86-64 и aarch64, Windows x86-64 и macOS Apple Silicon, но лежат на download.pytorch.org, а не на PyPI; torch.compile на 3.15 не поддерживается.

Что даёт NVGEMM и кому он нужен

NVGEMM, по описанию релиза, подключает к компилятору Inductor ядра матричного умножения CUTLASS, которые генерируются через CuTeDSL. Поддерживаются слияние эпилогов (операций после умножения), scaled GEMM и формат NVFP4, а также grouped-reduction epilogues. Это продолжение линии PyTorch 2.13, где CuTeDSL-путь только закладывался. Выигрыш получат те, кто гоняет обучение и инференс на современных NVIDIA GPU через torch.compile; на CPU, ROCm и Apple Silicon эта часть релиза ничего не меняет. Цифр ускорения относительно 2.13 в блоге релиза нет, поэтому эффект стоит мерить на своей модели.

Отказоустойчивость распределённого обучения

Backend nccl2 появился рядом с прежним NCCL и приносит неблокирующие коммуникаторы и eager splitting. Важнее для практики изменения в c10d: process group можно перестроить на месте, без полного перезапуска задания, когда один из узлов выпал. Добавлены односторонние окна RMA, а Flight Recorder, инструмент посмертной диагностики зависших коллективных операций, теперь работает не только с NCCL. Для кластеров на десятки GPU это означает меньше потерянных часов при сбое одного узла; для одной машины изменения не заметны.

Python 3.15: wheels есть, torch.compile нет

Python 3.15 ещё не вышел: 1 сентября появился второй релиз-кандидат, финал назначен на 1 октября. PyTorch 2.14 уже публикует сборки под 3.15 и его free-threaded вариант 3.15t для Linux, Windows и macOS на Apple Silicon, включая применимые CPU-, CUDA-, ROCm- и XPU-варианты. Две оговорки из заметок к релизу: эти wheels не лежат на PyPI, их нужно ставить с индекса download.pytorch.org, и torch.compile под 3.15 не поддерживается; попытка скомпилировать модель завершится RuntimeError, работает только eager-режим.

Что это значит на практике: проверить совместимость своего кода с 3.15 до октября можно уже сейчас, но замеры производительности с компиляцией придётся отложить до следующего релиза PyTorch. Про сам релиз-кандидат и заморозку ABI мы писали отдельно.

Несовместимые изменения

• LinearCrossEntropyOptions(acc_policy="balanced") удалён: теперь ValueError, заменять на "compact".
• Удалены устаревшие torch.cholesky и torch.qr (используйте torch.linalg.cholesky и torch.linalg.qr) и параметр профилировщика use_cuda.
• Градиент скалярного clamp на границе изменён с 1 на 0; для тензорных границ градиент делится как 0,5 и 0,5. Модели, чувствительные к поведению на границе клиппинга, могут обучаться иначе.
• Поддержка комплексных тензоров в torch.compile помечена как экспериментальная.

Как обновляться

1. Свериться с матрицей сборок на странице релиза: версии CUDA, ROCm 7.14, XPU и Python для вашей платформы.
2. Прогнать по коду поиск acc_policy="balanced", torch.cholesky, torch.qr и use_cuda.
3. Если используете кастомные process group с параметром backend, проверить их на nccl2 отдельно.
4. Для Python 3.15 ставить только с индекса download.pytorch.org и не рассчитывать на torch.compile.

Библиотека torchvision 0.29 в релизе объявлена ABI-совместимой с будущими torch 2.15 и 2.16, то есть её не придётся пересобирать под следующие два выпуска. Ограничений на загрузку wheels по регионам в источниках нет. Что ещё вышло в ML-инструментах за последние недели, смотрите в обзоре открытых моделей августа.

Источники: PyTorch 2.14 Release Blog, Release notes v2.14.0 на GitHub, Python 3.15.0rc2

Изображение на обложке: PyTorch Foundation, логотип PyTorch

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

Оговорка стоит в самом README: это референсная реализация, она не поддерживается и не принимает внешний вклад. В примерах нет аутентификации, MCP-серверы по умолчанию слушают loopback.

• Два агента, три способа запуска (Messages API, Claude Agent SDK, Managed Agents (beta)), четыре вертикали и восемь веб-приложений в одном репозитории под Apache 2.0.
• Не оформляет заказ, не списывает деньги и не меняет живые листинги: checkout только рисует корзину, каждая запись мерчанта ждёт одобрения человека.
• Проверки provenance, лимиты, ограждение стороннего текста и валидация памяти работают внутри вызова инструмента и держатся на всех трёх путях запуска.
• Своя интеграция сводится к реализации StorefrontBackend или MerchantBackend; отсутствующие системы выключаются переключателями enable_*.
• Модели по умолчанию: claude-sonnet-5 у покупательского агента, claude-opus-5 у мерчантского, claude-haiku-4-5-20251001 для памяти; рантаймы работают через Vertex AI, Bedrock, Microsoft Foundry и шлюзы.
• Требования: Python 3.11 и новее, Node 22. Демо поднимается шестью командами из README.

Один агент описан один раз и работает на трёх рантаймах

Главная архитектурная идея репозитория, как её формулирует README: каждый агент определён один раз (промпт, скиллы, контракты инструментов, гейты) и запускается на Messages API, на Claude Agent SDK и на Managed Agents. Четыре вертикали работают поверх одних библиотек и различаются бэкендом и доменными расширениями интерфейса.

Покупательский агент ищет и сравнивает товары, собирает планы покупок, наполняет корзину, отвечает на вопросы о заказах и правилах магазина и запоминает, что покупатель о себе рассказал. Его пять сценариев лежат как skills в каталоге shopping-agent/skills. Мерчантский агент объясняет показатели, правит листинги, реагирует на алерты по остаткам и заказам, назначает цены и промо, готовит кампании. Его пять сценариев лежат в merchant-agent/skills. Любая запись мерчанта становится staged change, которую применяет уже интерфейс одобрения на стороне хоста.

Nothing places an order, charges a card, or changes a live listing: checkout renders the cart for the host to complete, and every merchant write is staged until a person approves it.

Код разложен на семь pip-пакетов. Общее для обеих ролей вынесено в commerce-common: конфиг, ограждение стороннего текста, память, скиллы, grounding, презентационные компоненты, исполнитель инструментов и события. У каждой роли три пакета: core с типами, интерфейсом бэкенда, промптом, контрактами инструментов и гейтами; runtime с циклом ходов на Messages API; sdk с тем же агентом на Agent SDK и консолью. CI проверяет, что имена семи пакетов остаются незарегистрированными в публичном индексе, а pin-файлы ставят их из каталогов репозитория.

Эталонный путь запуска, вокруг которого построены примеры, это Messages API. Хост создаёт объект агента с бэкендом, каталогом скиллов и конфигом и стримит события хода; извлечение памяти вызывается отдельно после хода, и только на этом пути. Код из README:

На Agent SDK тот же промпт, скиллы и инструменты, но цикл ведёт SDK: хост заранее подгружает данные для grounding, после хода ничего не выполняется. На Managed Agents агент размещён у Anthropic и ходит за данными в ваш MCP-сервер; деплой делает скрипт scripts/deploy_managed_agent.sh, без флага --live это сухой прогон. Различия трёх путей по docs/safety.md:

• Messages API. Все правила grounding включаются принудительно через tool_choice; работают извлечение памяти после хода, сжатие истории и бюджеты аналитического делегата мерчанта.
• Agent SDK. Grounding только для правил с формой предварительной загрузки; цикл ограничен max_turns; аналитика мерчанта идёт субагентом без SQL-инструмента и бюджетов; память хост извлекает сам.
• Managed Agents. Grounding отсутствует, циклом владеет платформа, память пишется только через save_memory, одобрением staged change служит промпт always_ask на apply_change.

Проверки стоят внутри вызова инструмента, поэтому переживают смену рантайма

Документ docs/safety.md делит правила на три группы: что код проверяет сам, что по-прежнему просят у модели промптом и что обязан добавить деплой. Ключевой приём: правило внутри вызова инструмента держится на всех трёх путях, потому что все три прогоняют вызовы через один исполнитель в модуле commerce_common/execution.py. Правило на уровне хода живёт в конкретном рантайме, и таблица указывает, где оно не работает.

A rule enforced inside a tool call holds on all three paths, because the Messages API runtime, the SDK toolset, and the MCP server execute tools through the same executor.

Что именно проверяется в коде, по таблице документа:

• Ограждение (fencing). Сторонний текст очищается, оборачивается в ограждение с фиксированной меткой и обрезается до max_fenced_chars. Очистка убирает невидимые и управляющие символы, поддельные маркеры ходов, теги транскрипта и вызовов инструментов и копии самого маркера ограждения.
• Лимиты цикла. Запрошенное моделью число результатов поиска обрезается до max_search_results; после max_tool_iterations раундов рантайм Messages API принудительно делает ход без инструментов.
• Provenance корзины. В корзину попадают только идентификаторы товаров, которые в этой сессии вернул инструмент каталога или заказов. Попытка добавить товар с опциями (размер, цвет) задерживается, и модели показывают варианты. Действует лимит на позицию и на число строк.
• Нет оплаты. У StorefrontBackend нет метода, который размещает заказ или списывает деньги. URL размещённого checkout приходит из checkout_handoff после вызова модели и не проходит через неё.
• Provenance staged-записей мерчанта. Изменение принимает только идентификаторы листингов и кампаний, возвращённые инструментом в этой сессии; правка контента требует чтения get_listing. apply_change принимает только идентификаторы изменений, которые вернули staging или get_pending_changes.
• Guardrails мерчанта. Проверяются при постановке изменения и повторно при применении: число позиций, размах изменения цены, глубина промо, размер пополнения, бюджет кампании, защищённые поля.
• Одобрение хостом. При require_host_approval (включено по умолчанию) apply_change проходит только для идентификаторов, которые хост пометил одобренными. Карточка предпросмотра ничего не одобряет, «да, применяй» в чате тоже.
• Память. Ключ факта до 64 символов, значение до 200, одна из трёх категорий; значения, похожие на идентификаторы, отбрасываются. Извлечение читает только текст последнего обмена, никогда результаты инструментов.
• Поверхность инструментов и идентичность. Список инструментов вычисляется из конфига деплоя, исполнитель отказывает любому другому имени. Идентичность держит сервер: ни один аргумент инструмента не называет пользователя или мерчанта.

Вторая группа правил остаётся в промпте: трактовать ограждённый текст как материал для отчёта, называть условия и цифры только из результата инструмента, подтверждать запись только после успешного вызова, называть товары по идентификатору. Документ оговаривает: промптовые правила держатся ровно настолько, насколько модель следует инструкциям, а таблица держится на любой модели. Деплой, который меняет модель или выключает require_host_approval, должен сначала перегнать свои evals по этому разделу.

When the model breaks one of these, the error is confined to its text. Every write, figure, and disclosure behind that text still passed the checks in the table above, so the failure is a misstatement to correct and no action needs reversing.

Третья группа целиком на стороне деплоя: аутентификация и авторизация на каждом маршруте и на MCP-серверах (примеры принимают любого вызывающего), учётные данные для вызова ваших сервисов, лимиты запросов, бизнес-правила (фрод, право на покупку, цены, остатки), оплата после checkout, обращение с памятью как с персональными данными, гигиена логов и сама поверхность одобрения. Значения guardrails в двух файлах config.py названы демонстрационными.

Своя интеграция сводится к двум интерфейсам и переключателям enable_*

Точка входа для собственных систем описана в docs/backends.md. Деплой реализует StorefrontBackend поверх каталога, корзины, заказов и политик или MerchantBackend поверх аналитики, каталога, остатков, цен и кампаний. Контрактом служат докстринги методов в backend.py и types.py каждой роли. Каждый метод вызывает ваш сервис на стороне сервера с учётными данными, которые хост хранит для сессии; модель видит только результат.

Each one calls your service server-side with the credential your host holds for the session; the model reads only the result.

Документ раскладывает интеграцию на шесть шагов. Первый: решить, кто вызывающий. Хост аутентифицирует человека и стартует сессию с принципалом; токен покупателя живёт в контексте сессии, сервисная учётка передаётся в конструктор бэкенда. Гость тоже принципал: чтение, которому нужен аккаунт, бросает исключение, которое подкласс исполнителя превращает в просьбу войти. Второй: порядок многошаговых сценариев (удержать места, затем подтвердить) хранится и проверяется в бэкенде, а нарушение маппится через domain_error в понятный модели результат. Третий: как завершается checkout. Вариантов три: ссылка на маршрут в вашем приложении, размещённый checkout платформы, для которого checkout_handoff возвращает URL, или маркетплейс с записью на каждого продавца.

Четвёртый шаг: товары с опциями. Запись бывает простой, семейством (с полем options) или вариантом (с option_values и variant_of); идентификатор варианта идёт всюду, где ждут идентификатор товара. Детали товара возвращают все варианты семейства в одном ограждении, обрезанном до max_fenced_chars (12 000 символов по умолчанию). Компактная строка варианта занимает 70–120 символов, так что в семейство помещается около шестидесяти вариантов; кроссовки в восьми цветах и четырнадцати размерах документация советует подавать как восемь семейств по четырнадцать, потому что за пределами лимита результат режется без ошибки. Пятый: записи мерчанта по семействам, где изменение цены и пополнение именуют вариант. Шестой: для цифр, которых у платформы нет, возвращать None с пометкой, а не подставной ноль.

Для пилота README предлагает начинать с малого. Покупательский пилот реализует поиск и карточку товара, а остальное заглушает: метод-заглушка возвращает результат «недоступно» и не меняет ни байта промпта. Мерчантский пилот реализует восемь методов чтения, записи отказывают. Система, которой у бизнеса нет совсем, выключается переключателем enable_*: это убирает её инструменты, строки промпта и правило grounding на всех трёх путях, а сценарии, которым она нужна, паркуются в каталоге skills/_staged/. Свой сценарий добавляется каталогом с файлом SKILL.md, доменный интерфейс расширением PresentationExtension (вертикали поставляют семь), а brand_name, assistant_name и brand_voice в конфиге задают личность ассистента.

Модели заданы строкой в конфиге, а переключение платформы сосредоточено в одном месте и зависит от рантайма

По docs/deployment.md код по умолчанию ходит в API Anthropic, но у каждого пути есть одно место, где деплой переключает платформу. Рантаймы Messages API принимают любой асинхронный клиент из пакета anthropic аргументом client=: AsyncAnthropicVertex для GCP Vertex AI, AsyncAnthropicBedrockMantle или AsyncAnthropicBedrock для AWS, AsyncAnthropicFoundry для Microsoft Foundry, AsyncAnthropic с base_url и auth_token для собственного шлюза. Пакеты требуют anthropic 0.91 и новее. Рантаймы Agent SDK HTTP-клиента не создают: платформу выбирает CLI Claude Code по переменным окружения, которые добавляются в options.env. Managed Agents работает на инфраструктуре Anthropic, поэтому у него нет варианта для Vertex, Bedrock и Foundry.

Модель задаётся строкой в конфиге: поля model и memory_model у каждой роли, у мерчанта ещё analysis_model. Значения по умолчанию, по таблице документа: claude-sonnet-5 для покупательского агента, claude-opus-5 для мерчантского, claude-haiku-4-5-20251001 для извлечения памяти. Грамматика идентификаторов у платформ разная: Vertex пишет датированные снимки через @, Bedrock через Mantle берёт идентификаторы с префиксом anthropic., а через Invoke API идентификаторы inference-профилей. Все три поля идут через один клиент, поэтому все три модели должны существовать на целевой платформе. Живого разговора с облаком в CI нет; документ просит прогнать его на своей платформе до того, как на неё полагаться.

Доступность API Anthropic и облачных платформ для конкретной страны или способа оплаты в документации репозитория не обсуждается. Для собственного шлюза документ называет требование: отдавать /v1/messages со стримингом SSE для Messages API, а для Managed Agents ещё проксировать /v1/skills, /v1/agents, /v1/environments, /v1/sessions и поток событий сессии с заголовками anthropic-beta.

Демо поднимается шестью командами, а плагин Claude Code собирает агента под ваш стек

Порядок запуска из README (нужны Python 3.11 и новее и Node 22, ключ ANTHROPIC_API_KEY в файле .env):

Флаг --merchant поднимает портал мерчанта вместо витрины, --all оба. В README каждой вертикали есть раздел Try с репликами, которые прогоняет scripts/smoke_chat.py. Розничная ACME показывает поиск, сравнение, корзину, checkout и память; ACME Travel добавляет инвентарь с датами; ACME Mobile матрицу тарифов и серверные раскрытия комиссий; ACME Tickets таймированные удержания мест, листы ожидания и карту зала.

Второй способ начать: плагин commerce-builder для Claude Code. Он читает клонированный репозиторий как эталон и собирает агента на этих пакетах против ваших систем либо проверяет уже написанного. Установка и первая команда из README:

Команда /scaffold-commerce-agent спрашивает о стеке, проговаривает план и строит проект. Дальше /add-commerce-flow добавляет сценарий, /author-commerce-evals пишет evals, /review-commerce-agent начинает с уже существующего агента. Собственных MCP-коннекторов в поставке нет: оба агента ходят в системы через интерфейсы бэкенда. Где официальный коннектор является источником истины (Snowflake, BigQuery, Stripe, Square, Slack и другие в списке README), он и становится целью интеграции. MCP-сервер торговой платформы вызывается из метода бэкенда на сервере, и гейты provenance остаются перед каждой записью.

Проверка после правок: ruff check и ruff format --check, pytest, python scripts/check.py; python scripts/verify_all.py добавляет сухие прогоны деплоя и сборку веб-приложений; python scripts/smoke_chat.py --vertical travel проводит один живой разговор и требует ключ. Чтобы убедиться, что кэширование промпта работает, README советует читать cache_read_input_tokens из события turn_complete: ноль на втором ходу означает, что префикс промпта изменился.

Что делать команде, которая пишет ассистента для магазина

1. Поднять розничное демо по шести командам выше (Python 3.11 и новее, Node 22, ключ API) и пройти реплики из раздела Try в examples/retail/ на витрине (порт 3000) и в портале мерчанта (флаг --merchant, порт 3100).
2. Сверить таблицу «Enforced in code» и список «What a deployment owns» из docs/safety.md с собственной платформой: аутентификация, учётные данные, лимиты запросов, бизнес-правила, оплата, персональные данные в памяти, логи.
3. Для пилота реализовать в StorefrontBackend только поиск и карточку товара, для MerchantBackend восемь методов чтения. Отсутствующие системы выключить через enable_*, зависимые сценарии убрать в skills/_staged/.
4. Разложить каталог по трём формам записи из docs/backends.md и проверить самое большое семейство против лимита max_fenced_chars в 12 000 символов.
5. Выбрать завершение checkout: свой маршрут, размещённый URL платформы через checkout_handoff или ссылка на продавца для маркетплейса; оплата остаётся в хосте.
6. Для Vertex AI, Bedrock, Foundry или шлюза передать клиент аргументом client= (anthropic 0.91 и новее) или переменные CLI в options.env и заменить все три идентификатора моделей.
7. Перед выкладкой прогнать ruff, pytest, scripts/check.py и scripts/verify_all.py, затем один живой разговор scripts/smoke_chat.py на своей платформе; при смене модели перегнать evals по разделу «Still asked of the model».

Репозиторий создан 1 сентября, анонс в аккаунте Claude Developers вышел 2 сентября в 19:33 UTC. На 3 сентября, 01:53 мск, по данным GitHub API у проекта 277 звёзд и 46 форков. Поддержки и приёма внешних изменений Anthropic не обещает: «This is a reference implementation; it is not maintained and does not accept contributions», говорится в README. На практике это значит, что исправления и адаптацию под свои системы команде придётся вести в собственном форке, а промпты и гейты под новые модели проверять своими evals. Цен, лимитов и сроков дальнейшего развития Anthropic в репозитории не называет.

Источники: Claude Developers в X: анонс открытия Claude Commerce Agents (2 сентября 2026), GitHub: anthropics/commerce-agents, README репозитория commerce-agents, docs/safety.md: правила, проверяемые кодом, и обязанности деплоя, docs/backends.md: подключение своих систем, docs/deployment.md: Vertex AI, Bedrock, Microsoft Foundry и шлюзы, Плагин commerce-builder для Claude Code, Скиллы покупательского агента, Скиллы мерчантского агента

Изображение на обложке: Anthropic, кадр из анонса Claude Commerce Agents

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

• Каталог ~/.cache/codex-runtimes/codex-primary-runtime занимает 1,7 ГБ на macOS.
• Node.js 446,4 МБ, Python 440,6 МБ, LibreOffice headless 429,7 МБ, Poppler 187,9 МБ, Git 148,1 МБ; вместе нативные бинарники весят 771 МБ.
• В plugins/documents лежат skills, которые объясняют агенту, где искать бинарники и как ими пользоваться.
• Наблюдение сделано на одной машине с macOS; официальных данных о составе runtime на Windows и Linux нет.

Что именно лежит в каталоге

Уиллисон наткнулся на каталог случайно, разбирая ~/.cache/ утилитой OmniDiskSweeper. Внутри codex-runtimes/codex-primary-runtime три части: dependencies на 1,7 ГБ, plugins на 6,3 МБ и файл runtime.json на 4,1 КБ. В зависимостях четыре подкаталога: native на 771,0 МБ, node на 446,4 МБ, python на 440,6 МБ и bin на 28,7 КБ. В native лежат libreoffice-headless (429,7 МБ), poppler (187,9 МБ), git (148,1 МБ), libheif (4,7 МБ) и jxrlib (679,9 КБ).

Набор говорящий. Poppler читает и рендерит PDF, LibreOffice в headless-режиме конвертирует документы Word, Excel и PowerPoint в другие форматы без графического интерфейса, libheif открывает фотографии с iPhone в формате HEIC, jxrlib нужна для JPEG XR. Git и полноценные интерпретаторы Python и Node.js дают агенту возможность выполнять код и работать с репозиториями на машине пользователя.

Зачем агенту офисный пакет

Самое интересное в находке лежит в папке plugins/openai-primary-runtime/plugins/documents. По словам Уиллисона, в ней лежат skills, то есть текстовые инструкции, которые объясняют модели, как найти эти бинарники и как ими пользоваться. Это тот же подход, что в Claude Code и других агентных инструментах: вместо встроенного парсера каждого формата агент получает описание команды и вызывает готовую утилиту.

На практике это означает, что когда вы просите десктопный ChatGPT «сделать из этого документа PDF» или «вытащить таблицу из презентации», конвертация может выполняться локально, вызовом LibreOffice или Poppler из этого кэша. Это один из возможных путей: из наблюдения нельзя сказать, какие операции остаются локальными, а какие всё равно отправляют содержимое файла модели или обрабатываются иначе; документации OpenAI о составе runtime и о том, когда он скачивается, в открытом доступе нет.

Что стоит учесть

Наблюдение сделано на одной машине с macOS. Приложение для Windows может комплектоваться иначе, и переносить цифры на другие платформы не стоит. Не ясно и то, как обновляется runtime: отдельным скачиванием при первом обращении к документам или вместе с приложением.

Тем, кто следит за дисковым пространством, достаточно заглянуть в тот же путь. Удалять каталог вручную мы бы не советовали: что произойдёт с функциями работы с документами без него, автор не проверял, а официального способа отключить или очистить runtime OpenAI не описывает.

Разработчикам агентов здесь два практических наблюдения. Первое: в поставке для работы с форматами лежат полтора гигабайта проверенных открытых инструментов, включая LibreOffice, форк OpenOffice.org 2010 года. Второе: инструкции к этим инструментам лежат в виде читаемых файлов рядом с бинарниками, и их можно изучить как пример того, как крупный вендор пишет skills для своей модели.

Источники: Simon Willison: Codex bundles LibreOffice, OpenAI Help: Moving to the new ChatGPT desktop app

Изображение на обложке: Tproger

Для обычного пользователя PyCharm без плагина Cadence новость ничего не меняет. Для тех, кто подключал сервис, JetBrains даёт жёсткую рекомендацию: все учётные данные, к которым Cadence имел доступ, считать скомпрометированными и заменить, включая ключи облаков, токены GitHub и GitLab, SSH-ключи и ключи подписи. Региональной разбивки пострадавших компания не даёт; если сервис у вас был подключён, рекомендации те же.

• Период доступа атакующих: 8–24 августа 2026 года; JetBrains заметила эксплуатацию 23 августа и отключила сервер 24-го.
• Вектор: CVE-2026-63077 в TeamCity, который оркестрировал облачные задачи Cadence; патч на сервер не поставили.
• Утекли имена пользователей, реальные имена, email, время последнего входа и IP; полный бэкап сервера Cadence за 2024 год; AWS IAM-пользователи и их учётные данные; файлы в S3-бакетах JetBrains.
• Мог быть доступен исходный код, синхронизированный из PyCharm; затронуты ли бакеты клиентов, компания не установила.
• Токены плагина Cadence в PyCharm аннулированы; JetBrains просит заменить все секреты, доступные сервису, и проверить репозитории, облака, реестры пакетов и системы деплоя.

Что такое Cadence и при чём тут TeamCity

Cadence — облачный сервис JetBrains, который через необязательный плагин PyCharm позволяет отправлять тяжёлые вычисления, например обучение моделей, на удалённые машины. Чтобы запускать эти задачи, сервис использовал TeamCity, собственный CI-сервер JetBrains, как оркестратор облачных нагрузок. Именно в этой инсталляции TeamCity была уязвимость CVE-2026-63077, позволяющая удалённо выполнять команды без входа. Компания признаёт, что для этого сервера действовало то же правило, что и для остальных: патчить сразу после выхода исправления. Правило не сработало.

The server should have been patched, but it was not.

Хронология

• 8 августа: атакующие воспользовались уязвимостью TeamCity и получили доступ к серверу api.cadence.jetbrains.com.
• 8–24 августа: период активности; в это время были доступны данные пользователей, бэкап, учётные данные AWS и файлы в S3.
• 23 августа: JetBrains обнаружила эксплуатацию.
• 24 августа: сервер отключён, токены плагина Cadence в PyCharm аннулированы.
• 31 августа: первое обновление отчёта с перечнем затронутых данных.
• 1 сентября, 12:05 CEST: второе обновление; расследование ещё включает несколько проверок.

Что именно утекло

Компания перечисляет четыре категории. Первая — персональные данные пользователей Cadence: логины, реальные имена, адреса почты, время последнего входа и IP-адрес, с которого он был. Вторая, самая неприятная, — полная резервная копия сервера Cadence за 2024 год: JetBrains подтвердила, что атакующие получили доступ к её содержимому, а в нём могло быть всё, что сервис хранил на тот момент. Третья — AWS IAM-пользователи с учётными данными, то есть доступ к части облачной инфраструктуры JetBrains. Четвёртая — файлы в S3-бакетах компании; проверить, были ли затронуты бакеты клиентов, JetBrains на момент публикации не смогла.

We have confirmed that the threat actors accessed data contained in the Cadence server backup from 2024.

Отдельно компания допускает, что атакующим мог быть доступен исходный код, который пользователи синхронизировали из PyCharm в Cadence для запуска задач. Доказательств извлечения секретов из текущего окружения сервиса, по словам JetBrains, не найдено. Между «не найдено доказательств» и «не было» большая разница, и компания сама рекомендует исходить из худшего: список секретов, которые нужно считать скомпрометированными, включает облачные учётные данные, токены GitHub, GitLab и Bitbucket, учётные данные реестров пакетов и контейнеров, SSH-ключи и ключи подписи.

Что сделать, если вы пользовались Cadence

• Проверьте в PyCharm, стоял ли плагин Cadence; его токены JetBrains уже аннулировала, но это закрывает только вход в сервис.
• Замените всё, что было доступно из задач Cadence: ключи AWS, Google Cloud и Azure и любых других облаков, токены GitHub, GitLab и Bitbucket, учётные данные реестров пакетов и контейнеров, SSH-ключи, ключи подписи.
• Пересмотрите репозитории, которые синхронизировались в сервис, на предмет секретов в коде и истории коммитов: они могли уйти вместе с исходниками.
• Проверьте журналы облачных аккаунтов за 8–24 августа на действия от имени сервисных пользователей, которыми пользовался Cadence; JetBrains отдельно называет AWS и S3, IAM, реестры пакетов и системы деплоя.
• Если в 2024 году вы пользовались Cadence, а потом ушли, ваши данные могли находиться в бэкапе за 2024 год; состав пользователей в нём компания не раскрыла.
• Ждите финальный отчёт: расследование не закончено, и список затронутых данных может расшириться.

Урок для всех остальных

История примечательна не масштабом, а причиной. Компания, которая сама делает TeamCity, не поставила патч на свой TeamCity, и этого хватило. Для любой команды это напоминание: инвентаризация внутренних сервисов с публичным адресом и автоматическое отслеживание CVE для них — единственная защита от сюжета «должны были пропатчить, но не пропатчили». Второй урок про бэкапы: резервная копия двухлетней давности оказалась столь же ценной для атакующих, как и живая система, потому что секреты в ней никто не ротировал.

Источник: Cadence security incident, August 2026 (JetBrains)

Изображение на обложке: JetBrains

Обе дыры не новые: advisory по Langflow опубликован в GitHub Advisory Database ещё 23 января, но исправленная версия в нём не указана, а ZDI в бюллетене ZDI-26-034 называет единственной мерой ограничение доступа к сервису. Для Rails исправления есть. Если у вас в проде или на тестовом сервере стоит Langflow либо Rails-приложение принимает файлы от пользователей, проверять нужно сегодня.

• CVE-2026-0768, Langflow: CVSS 9.8, CWE-94, инъекция кода через параметр code в эндпоинте /api/v1/validate/code, аутентификация не нужна, код выполняется от root; исправленная версия в advisory не указана.
• CVE-2026-66066, Rails Active Storage: CVSS 9.5, чтение произвольных файлов при обработке изображений через libvips; уязвимы activestorage до 7.2.3.2, 8.0.x до 8.0.5.1 и 8.1.x до 8.1.3.1.
• VulnCheck насчитала 360 срабатываний на ловушках в нескольких странах; в запросах ищут ключи OpenAI и AWS, файл secret_key Langflow, папку .ssh и историю shell.
• Rails закрывается обновлением activestorage вместе с libvips не ниже 8.13; для Langflow единственная подтверждённая мера — ограничить доступ к сервису доверенными пользователями и сетями.
• При признаках эксплуатации считайте доступные секреты скомпрометированными и меняйте их.

Langflow: код в параметре code и никакого патча

Langflow — популярный инструмент, где ИИ-пайплайны собираются мышкой из блоков, а под капотом это Python-приложение. У него есть служебный эндпоинт /api/v1/validate/code, который проверяет пользовательский код компонента. Проверка входа там оказалась недостаточной: код из параметра выполняется, а эндпоинт не требует аутентификации. Langflow часто разворачивают в Docker от root, поэтому атакующий получает полный контроль над контейнером и всем, что в нём лежит: ключами моделей, токенами, доступами к базам.

Authentication is not required to exploit this vulnerability.

Это уже второй раз, когда тот же эндпоинт подводит: в 2025 году в нём же нашли CVE-2025-3248. По данным VulnCheck, в запросах атакующие целятся в переменные окружения LANGFLOW_SUPERUSER, OPENAI_API*, AWS_ACCESS*, AWS_SECRET*, файл /root/.cache/langflow/secret_key, каталог .ssh и .bash_history. Цель — не сам Langflow, а всё, к чему у него есть ключи. По данным VulnCheck, основной источник трафика на ловушки Langflow находился в России, а попадания фиксировались на canary-системе в Великобритании; атаки на Rails приходили на ловушки в Сингапуре, Израиле и Великобритании.

Rails: картинка, которая читает файлы

В Rails уязвим Active Storage, стандартный механизм загрузки файлов. Когда приложение обрабатывает изображение, оно передаёт файл в библиотеку libvips. Специально собранный файл заставляет libvips прочитать произвольный путь на сервере и вернуть содержимое в результирующем изображении. Так утекают secret_key_base, master key Rails, пароли БД и облачные учётные данные, а с ними в ряде конфигураций возможно и выполнение кода. Исследователи назвали уязвимость KindaRails2Shell.

Условия эксплуатации по advisory: libvips как бэкенд обработки и возможность для недоверенного пользователя загрузить файл. Если у вас ImageMagick или файлы грузят только администраторы, риск ниже, но обновиться всё равно стоит. Исправленные версии gem activestorage: 7.2.3.2, 8.0.5.1 и 8.1.3.1; advisory требует также libvips не ниже 8.13 и рекомендует заменить секреты.

Что сделать сегодня

• Langflow: ограничьте доступ ко всему сервису доверенными пользователями и сетями (VPN, reverse proxy с аутентификацией); это единственная мера, которую называет ZDI, потому что исправленной версии в advisory нет. Следите за релизами проекта.
• Проверьте логи на запросы к /api/v1/validate/code с чужих адресов; нашли — считайте все ключи в окружении скомпрометированными и ротируйте их.
• Rails: bundle update activestorage rails до 7.2.3.2, 8.0.5.1 или 8.1.3.1 и выше, обновите libvips до 8.13 или новее; проверьте Gemfile.lock.
• Пока не обновились: на libvips 8.13 и новее включите блокировку недоверенных операций (переменная VIPS_BLOCK_UNTRUSTED или Vips.block_untrusted(true)), для более старых версий обхода advisory не даёт, остаётся отключить обработку файлов от пользователей.
• После инцидента меняйте secret_key_base и master key: с их утечкой атакующий подделывает сессии и расшифровывает credentials.

Контекст

Обе уязвимости известны с зимы, но волна эксплуатации началась, когда появился рабочий эксплойт и его добавили в автоматические сканеры. VulnCheck отдельно отмечает, что запросы приходили на ловушки в разных странах, то есть кампания не целевая, а ковровая: сканеры ищут любой доступный снаружи экземпляр. Langflow особенно распространён во внутренних ИИ-экспериментах, которые поднимают «на минутку» с публичным IP и забывают, и именно такие установки первыми находят сканеры.

Источники: Attackers exploit critical Langflow and Rails flaws (The Hacker News), GHSA-x5pr-rvjj-j6qm: Langflow code injection, GHSA-xr9x-r78c-5hrm: Active Storage arbitrary file read, ZDI-26-034

Изображение на обложке: Langflow, Ruby on Rails

Между rc1 и rc2 вошло около 144 исправлений от 76 участников: ошибки, сборка, документация. До финала принимаются только проверенные исправления багов, новых функций не будет. Релиз-менеджер Хьюго ван Кеменаде называет rc2 финальным кандидатом и просит мейнтейнеров тестировать пакеты именно сейчас; ставить rc2 в прод команда не рекомендует.

• 3.15.0rc2 — последний запланированный кандидат; ABI заморожен, финальный релиз назначен на 1 октября 2026 года.
• JIT: в среднем на 8–9% быстрее обычного интерпретатора на x86-64 Linux и на 12–13% быстрее tail-calling interpreter на macOS с Apple Silicon; разброс по тестам от замедления на 15% до ускорения больше чем вдвое; цифры предварительные.
• Официальные сборки для Windows x64 используют tail-calling interpreter, сборки для macOS по умолчанию поддерживают free-threading.
• Новое в языке: ленивые импорты через ключевое слово lazy (PEP 810), встроенные типы frozendict (PEP 814) и sentinel (PEP 661).
• Мейнтейнерам: собирайте wheels под 3.15 и гоняйте тесты на rc2; после 1 октября исправление попадёт только в 3.15.1.

Что означает «ABI заморожен»

ABI — набор правил, по которым скомпилированный код (numpy, pydantic-core, любой пакет с C или Rust внутри) обращается к интерпретатору: размеры структур, порядок полей, сигнатуры функций. Пока ABI меняется, wheel, собранный под бету, может упасть на финальной версии. Теперь команда CPython обещает: «There will be no ABI changes from this point forward in the 3.15 series» (перевод редакции: «С этого момента в серии 3.15 изменений ABI не будет»). Значит, wheel, собранный сегодня под rc2, останется валидным для 3.15.0 и всех 3.15.x.

На практике это точка, после которой авторы популярных библиотек выкладывают на PyPI сборки для новой версии. Если ваш проект зависит от пакета, который до сих пор не собран под 3.15, самое время открыть issue или прислать PR: у мейнтейнеров есть месяц.

Сколько на самом деле даёт JIT

Документация «What's New» приводит две цифры, и их важно не смешивать. На x86-64 Linux JIT даёт 8–9% ускорения в среднем геометрическом относительно обычного интерпретатора. На macOS с процессорами Apple JIT сравнивают с более быстрым tail-calling interpreter, и там выигрыш 12–13%. Разброс по отдельным тестам огромный: от замедления примерно на 15% до ускорения больше чем вдвое. Документация подчёркивает, что цифры предварительные и до финала могут измениться. Так что «Python стал на 10% быстрее» — неверное обобщение: на вашем коде может быть и минус.

Tail-calling interpreter — другой способ реализовать цикл исполнения байткода, где каждая инструкция вызывает следующую хвостовым вызовом вместо большого switch. В 3.15 именно он идёт в официальных 64-битных сборках для Windows. Официальные сборки для macOS по умолчанию получают поддержку free-threading, то есть режим без GIL остаётся экспериментальным, но доступным без пересборки.

Три новинки языка, которые вы заметите

Ленивые импорты (PEP 810): ключевое слово lazy перед import откладывает загрузку модуля до первого обращения. Это ответ на старую проблему медленного старта CLI-утилит, которые тянут тяжёлые зависимости «на всякий случай».

frozendict (PEP 814) — неизменяемый словарь, встроенный в язык: если все его ключи и значения хешируемы, его можно использовать как ключ другого словаря, и его безопасно отдавать наружу как константу. sentinel (PEP 661) закрывает старый обходной приём с _MISSING = object() для «значение не передано»: у таких маркеров появляется нормальный repr и корректное поведение при pickle.

Что сделать до 1 октября

• Поставьте rc2 рядом с рабочей версией: официальные установщики и исходники на python.org; в uv или pyenv сначала проверьте, что версия появилась в их списках (uv python list), и прогоните тесты проекта.
• Если у вас пакет с расширениями: соберите wheels под 3.15 и выложите на PyPI; ABI больше не изменится.
• Замерьте свой код с JIT и без: флаги сборки и переменные окружения описаны в документации; средним цифрам не верьте.
• Проверьте зависимости на совместимость с ленивыми импортами: код, который полагается на побочные эффекты при импорте, с lazy сломается.
• Нашли регрессию — сообщайте в трекер CPython сейчас: после релиза исправление уйдёт только в 3.15.1.
• Если пользуетесь корпоративным зеркалом PyPI, убедитесь, что оно синхронизирует wheels с тегом cp315: первые сборки под 3.15 появятся в ближайшие недели.

Контекст

Разработка 3.15 началась 7 мая 2025 года, первая бета вышла 7 мая 2026-го, rc1 — 4 августа. После финального релиза ветка получит около двух лет исправлений ошибок и затем ещё примерно три года обновлений безопасности, по обычному графику CPython.

Источники: Python 3.15.0rc2 (python.org), What's New in Python 3.15

Изображение на обложке: Python Software Foundation

В этой статье соберём работающего RAG-бота, который отвечает на вопросы о любой веб-странице, примерно на 60 строках Python. Никаких парсеров HTML, headless-браузеров и сложных фреймворков — только requests, локальная Ollama и чистый Markdown.

Что такое RAG

RAG (retrieval-augmented generation) — это подход, при котором языковая модель не отвечает по своей памяти, а сначала ищет релевантные фрагменты во внешнем тексте, а потом генерирует ответ на их основе. Это резко снижает галлюцинации и позволяет работать с данными, которых не было в обучающей выборке.

• RAG-бот на Python укладывается в ~60 строк и работает без облачных LLM.
• Самое неприятное в RAG-пайплайне — очистка HTML; готовый Markdown API убирает эту работу.
• Текст разбивается на чанки (~1200 символов), каждый превращается в эмбеддинг и сравнивается с эмбеддингом вопроса.
• Локальные модели nomic-embed-text и llama3 через Ollama не требуют иностранных карт и VPN.
• Качество ответа зависит от качества исходного текста: сырой HTML зашумляет поиск, чистый Markdown улучшает ретривл.

Что мы соберём

Архитектура бота простая и универсальная:

1. Отправляем URL в сервис извлечения текста и получаем чистый Markdown.
2. Разбиваем Markdown на фрагменты (чанки) по границам абзацев.
3. Превращаем каждый чанк в вектор — эмбеддинг.
4. То же самое делаем с вопросом пользователя.
5. Находим чанки, ближайшие к вопросу, по косинусной близости.
6. Отдаём найденные фрагменты + вопрос языковой модели с инструкцией отвечать только по контексту.

Такая схема легко масштабируется: можно заменить локальную Ollama на OpenAI, Anthropic или российские модели, а векторы перенести в Qdrant или Chroma.

Что понадобится

• Python 3.9+
• Библиотека requests
• Локально запущенная Ollama с моделями nomic-embed-text и llama3
• Доступ к API извлечения текста (в примере — Web to Markdown/JSON API; бесплатный тариф даёт 50 запросов в сутки)

Код бота

Сохраните скрипт как rag_bot.py и подставьте свой ключ, если сервис извлечения текста требует авторизации:

На что обратить внимание:
Если вы используете RapidAPI-версию сервиса, запрос к API_URL обычно требует заголовка X-RapidAPI-Key. Без ключа бесплатный endpoint может вернуть 401.

Разбор по частям

fetch_markdown — единственный внешний вызов. Сервис сам забирает страницу, убирает навигацию, баннеры и футер и возвращает Markdown: заголовки, абзацы, списки. Это освобождает от зависимостей вроде BeautifulSoup или headless Chrome.

chunk_markdown режет текст на фрагменты примерно по 1200 символов, не разрывая абзацы. Мелкие чанки дают более точный ретривл, но увеличивают число эмбеддингов; для начала 1200 символов — хороший баланс.

embed и cosine превращают текст в векторы и считают их близость. Модель nomic-embed-text из Ollama бесплатна, быстрая и неплохо понимает русский и английский.

answer эмбеддит вопрос, выбирает три самых похожих чанка и строит промпт с жёстким ограничением: отвечать только по контексту. Это главная страховка от галлюцинаций.

Запуск

Установите зависимости и скачайте модели в Ollama:

Если всё в порядке, в консоли появится примерно такой результат:

Почему важен чистый Markdown

Если скормить эмбеддинг-модели сырой HTML, в векторах окажутся теги <div>, меню навигации и копирайты из футера. В результате поиск похожести выдаст «Copyright © 2026» вместо полезного ответа. Чистый Markdown — заголовки, абзацы, списки — улучшает качество ретривла почти бесплатно.

Если не хочется зависеть от внешнего API, можно заменить fetch_markdown на один из альтернативных вариантов:

• trafilatura — библиотека на Python для извлечения главного текста.
• r.jina.ai/http://URL — бесплатный сервис без ключа.
• Firecrawl — API с поддержкой сканирования сайтов целиком.
• ScrapingBee — прокси + рендеринг для сложных страниц.

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

Куда развивать

• Направьте бота на документацию, чейнджлог или блог конкурента и задавайте вопросы по ним.
• Замените Ollama на OpenAI, Anthropic, Gemini или российские модели — функция answer меняется в двух строках.
• Сохраняйте эмбеддинги в векторную БД: Chroma, Qdrant или FAISS, чтобы индексировать сразу много страниц.
• Используйте формат json вместо Markdown, если нужна структура: параграфы, заголовки, ссылки — отдельно.

Выводы

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

RAG работает ровно так хорошо, каков текст, который вы ему скармливаете. Уберите самую утомительную часть — очистку HTML, — и останется интересное: поиск и генерация.

Исходник идеи — статья «Chat With Any Website: Build a RAG Bot in ~60 Lines of Python». Попробуйте собрать бота на своей странице и посмотрите, где он справляется, а где начинает фантазировать.

Автор оригинального руководства указывает заголовок «за $5/месяц», но на практике минимально жизнеспособная конфигурация обходится в $6–12/месяц. За $5 дроплет даёт всего 1 ГБ ОЗУ — для семимиллиардной модели этого катастрофически мало. Ниже — реальные цифры и честная смета.

Что такое Llama 2 и зачем её self-hostить

Llama 2 — семейство открытых больших языковых моделей от Meta. Версия 7B содержит 7 миллиардов параметров, понимает английский и ряд других языков, умеет писать код, отвечать на вопросы и дополнять текст. Лицензия разрешает коммерческое использование при соблюдении простых правил, а веса можно скачать с Hugging Face.

Self-hosting в данном случае означает, что вы сами устанавливаете модель на арендованный сервер, контролируете окружение, не делитесь данными пользователей с третьими лицами и не зависите от чужих rate limit. Главная экономика: при интенсивном использовании собственный инференс обходится в десятки раз дешевле облачных API.

• Llama 2 7B можно запустить на DigitalOcean Droplet с 2 vCPU и 4 ГБ ОЗУ при 4-битном квантовании.
• Реальная стоимость — $12/месяц за Droplet плюс около $0,50 за трафик, а не $5.
• Docker + FastAPI дают воспроизводимое окружение и HTTP API из коробки.
• Для загрузки весов с Hugging Face нужен токен и принятая лицензия на Llama 2.
• Для публичного доступа обязательны HTTPS, базовая аутентификация и rate limiting.

Что понадобится для развёртывания

Аппаратная часть

• DigitalOcean Droplet на Ubuntu 22.04 LTS.
• Минимум: 1 vCPU / 2 ГБ ОЗУ ($6/месяц) — только для экспериментов.
• Рекомендуемый: 2 vCPU / 4 ГБ ОЗУ ($12/месяц) — стабильная работа с квантованием.
• 80 ГБ SSD: ~13 ГБ уйдёт на Docker-образ, модель и кэш.

Программная часть

• SSH-ключ и базовое умение работать в терминале.
• Docker и Docker Compose для управления контейнером.
• Аккаунт на Hugging Face с принятой лицензией Llama 2 и API-токеном.
• Nginx или аналогичный reverse proxy для вывода API в интернет.

Российская специфика: сайт DigitalOcean периодически попадает под блокировки Роскомнадзора. Для регистрации и управления Droplet может понадобиться VPN. Альтернативы — Hetzner, Selectel, Yandex Cloud или другие европейские и российские провайдеры; логика развёртывания от этого почти не меняется.

Шаг 1. Создаём Droplet и подключаемся по SSH

В панели DigitalOcean нажимаем Create → Droplet. Выбираем ближайший к целевой аудитории регион — для России это обычно Франкфурт или Амстердам. В качестве образа указываем Ubuntu 22.04 x64, тип — Basic Shared CPU, конфигурацию — 2 vCPU / 4 ГБ RAM. Авторизацию настраиваем через SSH-ключ, парольный вход отключаем.

Сгенерировать ключ и подключиться можно так:

Шаг 2. Устанавливаем Docker и зависимости

После подключения обновляем пакеты и ставим Docker официальным скриптом. Добавляем root в группу docker, чтобы не писать sudo перед каждой командой.

Шаг 3. Собираем Docker-образ с FastAPI

Приложение состоит из трёх файлов: Dockerfile, requirements.txt и app.py. Ключевой трюк — CPU-версия PyTorch и библиотека bitsandbytes, которая позволяет загрузить 7-миллиардную модель в 4 ГБ видеопамяти/ОЗУ.

Dockerfile

requirements.txt

Шаг 4. Пишем FastAPI-приложение

Приложение загружает модель при старте, кэширует её в /app/models и предоставляет три endpoint: /health, /info и /generate. Квантование в 4 бита снижает точность незначительно, но уменьшает потребление памяти в 3–4 раза.

Создаём файл с токеном Hugging Face. Никогда не коммитьте его в репозиторий: в продакшене используйте переменные окружения или секрет-менеджер.

Шаг 5. Собираем и запускаем контейнер

Первый запуск занимает 10–15 минут: скачиваются зависимости PyTorch и веса модели. Чтобы не качать веса при каждом перезапуске, подключаем Docker volume.

Для удобного управления добавляем docker-compose.yml:

Шаг 6. Проверяем API

Когда в логах появится Uvicorn running on http://0.0.0.0:8000, тестируем endpoint'ы:

Ответ должен содержать сгенерированный текст, количество токенов и время инференса. На CPU одна генерация из 100 токенов занимает 4–10 секунд — это нормально для бюджетного дроплета.

Шаг 7. Безопасно выводим API в интернет

Открывать порт 8000 напрямую в интернет небезопасно. Ставим Nginx как reverse proxy, настраиваем HTTPS через Let's Encrypt и базовую аутентификацию. Для rate limiting используем limit_req в Nginx или облачный firewall DigitalOcean.

Минимальная конфигурация Nginx выглядит так:

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

Выводы

Self-hosted Llama 2 — рабочий способ снизить затраты на генеративный ИИ в pet-проектах и прототипах. При правильном квантовании семимиллиардная модель помещается в бюджетный дроплет, а Docker + FastAPI превращают развёртывание в рутинную процедуру. Главное — не экономить на RAM и не забывать про безопасность публичного API.

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

Если соберётесь повторить гайд, начните с $12 Droplet и протестируйте нагрузку вручную. А если DigitalOcean недоступен — переносите тот же Docker Compose на Hetzner, Selectel или Yandex Cloud без изменения кода.

Источник: How to Deploy Llama 2 on DigitalOcean for $5/Month: Complete Self-Hosting Guide — RamosAI, Dev.to.

Без маркетинга и успешного успеха. Только боль, костыли и суровый прод! Мой пет-проект - бот «Щёлк-ГДЗ». Это ИИ-помощник, который решает школьные задачки по фоткам, видео, гс, тг-кружкам и PDF. Под капотом Python 3.12.3, aiogram 3, aiosqlite, апи OpenRouter (модель Gemini 3.0 Flash) и Робокасса. Крутится всё это на дешёвом VPS в Нидерландах. Держит 2500+ пользователей и не падает.

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

Нейронка вместо джуна и Уроборос багов

Сразу признаюсь... С нуля я это не писал :) Синтаксис мне генерили LLM-ки. Начинал с Gemini 2.5 Pro, затем перешел на 3.0 Pro, а сейчас использую 3.1 Pro.

Многие думают, что нейронка сама напишет проект "под ключ", но это миф. Я никогда не доверял ИИ проектирование архитектуры и использовал его как продвинутый StackOverflow (скармливал конкретную задачу (например, написать SQL-миграцию) и получал кусок кода).

ИИ — это не архитектор, а джун на спидах.

Как только логика усложнялась - гемини ловил «Уроборос багов». Кидаешь баг А - он его фиксит, но появляется ошибка Б. Скармливаешь и её - фиксит, но возвращается баг А. Цикл замкнулся. Лечилось только созданием новых чатов, в которые я кидал код и писал запросы типа "Найди критические ошибки, логические дыры и баги".

Про продуктовую логику нейронка вообще не слышала. В первой версии рефералки был баг, где любой(если его аккаунта ещё нет в БД) мог написать в конце ссылки что любые 9 цифр (?start=1234567890) и получить бонусы.

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

Немного про архитектуру.

Чтобы код не превратился в нечитаемую лапшу на 5000 строк, я жестко разбил всё на модули. Архитектура бота выглядит так:

main.py - это точка входа с настройкой логгеров, коннетами aiohttp и запуском APScheduler

database.py - вся работа с БД

neiro.py - логика общения с апи OpenRouter (стриминг, сжатие фоток через Pillow, JSON-контекст)

states.py - классы состояний aiogram.fsm.state (например, PaymentProcess, GdzMode)

utils.py - легковесные утилиты. Например лок пользователей (защита от спама запросами):

Хэндлеры вынесены в отдельную папку handlers/:

handlers/common_handlers.py - главное меню с обработкой /start (рефералки, utm-метки).

handlers/gdz_handlers.py - сам процесс ИИ-решения (вход в GdzMode, прием фото, видео, кружочков).

handlers/pay_handlers.py - это логика платежей (Robokassa) и "Умная корзина".

handlers/tasks_handlers.py - квесты (выдача премиума за подписку на каналы спонсоров).

Сборку интерфейсов вынес в all_def.py. Не люблю, когда в хэндлерах генерится полотно текста с кнопками. Там же лежат функции склонения слов (1 запрос, 2 запроса, 5 запросов). А в settings.py лежат списки с рандомными ответами бота, чтоб казался живым.

Так же в settings.py я сделал кэширование картинок, тоесть при первом запуске бот грузит фото меню как BufferedInputFile, сохраняет file_id от Телеграма и дальше шлет картинки моментально по ID. Сервак говорит спасибо за сэкономленный трафик)

В handlers/common_handlers.py находится первичная маршрутизация. Вот так обрабатываются рефералки, переходы с сайта, с рекламы и другое при старте:

Диета по токенам

Хранить бесконечную историю диалогов дорого и бессмысленно. В бесплатной версии храню 10 последних сообщений (5 пар вопрос-ответ), а в преме — 30.

Но фотки весят большое кол-во токенов. Если премиум-юзер закинет 30 фоток, OpenRouter выставит мне огромный счет. В итоге я прикрутил ограничение: Из 30 сообщений ИИ видит только 10 последних картинок.

Старые фотки тупо вырезаю из JSON. Подменяю на системный промпт:

С довольно неплохой моделью (gemini 3.0 flash) это работает как часы (она честно признается, что забыла картинку, а не выдумывает что-то из воздуха).

Стриминг, FloodWait и защита баланса

Чтобы бот не выглядел тормозом, я сделал стриминг ответа от ИИ в neiro.py. Я обновляю сообщение в Телеграме чанками по мере получения их от ОпенРоутера.

Но если делать message.edit_text слишком часто, ловишь FloodWait. В итоге я выставил интервал в 0.7 секунд и обернул всё в жесткий try/except:

Стрим при этом не прерывается. Поспали и погнали дальше :) Если на этапе обработки файла или стриминга падает критическая ошибка - честно возвращаю юзеру запрос на баланс.

В handlers/gdz_handlers.py это выглядит так:

SQLite тащит

Почему не Postgre? Потому что для микро-SaaS с 2,5к пользователей SQLite хватает за глаза. Но в асинхронной среде она любит кидать ошибку database is locked.

Чтобы этого избежать, я включил WAL-режим при инициализации пула, разделил коннекты на db_writer и db_reader, а сложные операции доверил самому SQL.

Например, 00:00 запускается крон-таска, которая собирает огромную аналитику, начисляет всем активным юзерам +1 ежедневный запрос и сбрасывает просроченные подписки. И это всё это работает атомарно внутри database.py:

Умная корзина на APScheduler

Когда дело дошло до монетизации, всплыли две проблемы:

Первая: юзер оплатил, но забыл нажать кнопку «✅ Я оплатил» в боте. Бот ждет, юзер ждет, товар не выдается, поддержка кипит.

Вторая: юзер сформировал счёт и передумал ("брошенная корзина").

Вместе с LLM я с нуля изучил apscheduler и убил двух зайцев фоновыми задачами. Теперь в handlers/pay_handlers.py при генерации ссылки на оплату я создаю две отложенные таски:

Как это работает?

Через 5 минут срабатывает async def auto_check_payment(), которая тихо стучится в робокассу. Если статус success - бот сам начисляет запросы на баланс и радует клиента. Если статус pending - таска умирает, и в дело вступает 30-минутная таска.

Но она не шлёт спам вслепую, а лезит в БД и проверяет 3 бизнес-правила:

1. await db.has_successful_payment_recently - Не купил ли он другой товар за последние 3 часа?

2. await db.get_latest_invoice_id - А это точно самый последний сгенерированный им счет?

3. await db.can_send_agitation - Не присылали ли мы ему агитацию недавно?

Если проверки пройдены, то юзер получает сообщение: "⏳ Домашка сама себя не решит! Ты начал оформлять покупку, но оплата так и не прошла...". Это поднимает конверсию оплат.

Финал

Почему я не использую Redis для стейтов? Ответ банален: мой дешевый VPS имеет всего 1 гб оперативки. Пул aiohttp, In-Memory стейты и асинхронные таски и так жрут 70% RAM. Редис тупо не влезет.

Как говорится, работает — не трогай.

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

Готов ответить на вопросы по архитектуре и послушать советы в комментариях \(^^)/

P.s. вот ссылка на первую статью о моём проекте:

P.s. Если кто-то хочет потестить вживую(не реклама), то юз бота в тг @gdzshchelk_bot

Арендовать мощные VPS под ресурсоемкие задачи в текущих реалиях выходит неоправданно дорого. При этом дома у меня уже был выделенный неттоп (мини-ПК) с 16 ГБ оперативной памяти на базе энергоэффективного процессора Intel N95.

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

История настройки сетевой архитектуры

Использование Tuna

В самом начале проекта я еще не думал о VPN как о способе пробития NAT и основе, на которой будет строиться вся система. Первое, к чему я пришел — сервис Tuna. Если кратко, это аналог Cloudflare Tunnel за условные 300 рублей. У него очень приятный веб-интерфейс и невероятно простая настройка. Однако для полноценной независимой архитектуры он не подошел по двум причинам:

• Сервера Tuna находятся вне контроля пользователя.
• На удаленном сервере нельзя развернуть свои сопутствующие сервисы.

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

Вот пример конфига для tuna (все максимально просто, создаем контейнеры для ssh туннеля, чтобы был доступ ssh, а также основной http туннель с привязкой к nginx или любому другому прокси если такой есть):

В поисках гибкости: тесты Pangolin и переход к FRP

После Tuna я решил двигаться в сторону собственного контроля и попробовал Pangolin. Однако решение быстро отвалилось: для дешёвого сервера оно оказалось слишком «тяжёлым» и избыточным. Главные минусы — ощутимый оверхед по ресурсам и лишний слой принудительной веб-аутентификации перед самими сервисами. Это ломало нормальное взаимодействие с родными мобильными клиентами (вроде Element для Matrix или Bitwarden для паролей), где повторная авторизация в браузере просто не нужна.

На смену пришел FRP (Fast Reverse Proxy). Он выполнял ту же функцию проброса, но хостил я его уже на собственном арендованном VPS в режиме Layer 4 (TCP). Это дало абсолютную гибкость: внешний VPS не заглядывал внутрь пакетов и ничего не расшифровывал, а просто пересылал сырой поток домой. Кроме того, это отлично оптимизировало расходы: вместо 300 рублей за Tuna и ещё 300 рублей за отдельный VPN, я стал платить всего 500 рублей за один стойкий VPS, который мог настраивать как хочу. (к тому же можно было обойтись даже дешевле, так как VPS с 4 гб оперативки загружен всего лишь на 40%, процессор всего на 20%-40%)

FRP состоит из 2 конфигурационных файлов (один на удаленном сервере frp server, другой на локальном frp client), все также довольно просто, однако его можно использовать на разных слоях. У меня он брал трафик за стандартный TCP и передавал его на локальный сервер.

Также доп. фишка в том что основная конфигурация происходит именно в frpc, который, в свою очередь, передает часть настроек на frp на удаленном сервере.

frpc.toml:

frps.toml:

Полноценный переезд на WireGuard (AmneziaWG) и 8 часов отладки

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

• Безопасность: FRP всё же открывал внутренние ресурсы в публичный интернет, оставляя их доступными для сканеров портов.
• Удобство маршрутизации: Все участники сети стали равноправными узлами в одной виртуальной локальной подсети. Больше не нужно было настраивать постоянные односторонние пробросы.
• Дополнительный бонус: Поскольку удаленный VPS был куплен в Нидерландах, через этот же VPN я автоматически получил безопасный доступ ко всем зарубежным ресурсам.

Для реализации схемы на удаленном VPS был развернут контейнер wg-easy с поддержкой AmneziaWG, а на домашнем мини-ПК — клиентский контейнер Amnezia (сборка из Dockerfile с использованием amnezia-tools и модулем ядра хоста).

И именно здесь я поймал самый изнурительный баг проекта. После развертывания трафик упорно шёл только в одну сторону. Часов 8 ушло на диагностику iptables, маршрутов и чтение зарубежных форумов (что бесполезно, учитывая специфику наших блокировок). Оказалось, провайдер просто дропал обратный трафик стандартного WireGuard, так как пакеты шли без маскировки. Причина крылась в docker-compose.yml: у меня было прописано image: ghcr.io/wg-easy/wg-easy:latest. Как выяснилось, тег latest на Docker Hub намертво прилип к старой 14-й версии, а поддержка параметров AmneziaWG появилась только в ветке 15.x. Изменение тега на конкретную версию (15.3) решило проблему за секунду.

Благодаря переходу конфигурация получилась максимально простой, основные отличия от стандартной документации выделил в коде: (в основном то, на что пришлось долго рыть информацию)

Настройка Nginx

Чтобы сервисы были доступны исключительно внутри подсети VPN, я задействовал Nginx. Доступ к приложениям был жестко ограничен на уровне конфигурации — веб-сервер принимает запросы только из диапазона IP-адресов 10.8.0.0/24. Любые попытки постучаться на сервер из внешнего интернета без активного VPN-туннеля автоматически сбрасываются Nginx.

Логика распределения завязана на proxy-протоколе: Nginx на удаленном VPS выступает основным входным узлом, принимает зашифрованный трафик, заворачивает его в заголовки с реальным IP-адресом клиента и через туннель перекидывает на локальный Nginx домашнего сервера. Локальный веб-сервер уже сам расшифровывает SSL и распределяет трафик по конечным Docker-контейнерам, сохраняя реальные IP в логах безопасности.

Вставлю один кусок кода из nginx на удаленной машине для примера, так все остальное примерно похоже (конфиги использовались в виде .template):

SSL-сертификаты

Для получения валидных SSL-сертификатов я настроил работу через автоматический Certbot по challenge-валидации DNS-01 c API Webnames. Сам домен привязан к внутреннему IP-адресу 10.8.0.1. Проверка через DNS позволила выпустить единый wildcard-сертификат на весь домен и его поддомены без необходимости держать открытым 80-й порт веб-сервера наружу.

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

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

Вот настройка certbot:

История софта

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

Первый стек и оптимизация

Первыми на домашнем сервере прижились медиа-сервисы: Navidrome для стриминга музыки и Audiobookshelf для аудиокниг и подкастов. Они легковесные, имеют отличные мобильные клиенты с синхронизацией прогресса и полностью закрывают мои потребности. Позже к ним добавился Nextcloud как единое независимое облако для файлов, контактов и семейных документов.

Затем встал вопрос безопасного хранения паролей. Сначала я смотрел в сторону оригинального Bitwarden, но в итоге я выбрал Vaultwarden — альтернативный сервер на Rust, полностью совместимый с API Bitwarden. Он потребляет считанные мегабайты оперативной памяти и работает идеально. Дополнительно для удобства управления всей этой распределенной Docker-инфраструктурой в локальный стек был добавлен Portainer. (+ Portainer Agent на удаленный сервер)

Из интересных моментов, где мне пришлось немного больше возиться, чем с остальными сервисами это nextcloud настройка:

Ошибки проектирования: почему я удалил Matrix (Synapse)

Не все решения прошли проверку временем. На этапе использования Tuna и FRP я развернул сервер Matrix (Synapse) для защищенного обмена сообщениями. Мне казалось это крутой идеей, но когда я окончательно перешел на AmneziaWG, целесообразность мессенджера внутри закрытого туннеля сошла на нет.

Synapse требовал слишком много ресурсов, впустую расходовал оперативку домашнего ПК и усложнял конфиг Nginx. При этом реальной пользы для семьи он не приносил. Для критических алертов инфраструктуры и повседневного общения проще и эффективнее оказалось использовать Telegram. (плюс алертинг настроен именно через него) В итоге я полностью выпилил Synapse из стека, освободив ресурсы.

Вместо него я добавил в связку к wg-easy локальный AdGuard Home. Теперь он работает прямо внутри VPN-сети: очищает весь трафик от рекламы и трекеров на лету, кэширует DNS-запросы и не дает истории веб-серфинга улетать внешним провайдерам.

Основной проблемой с которой я столкнулся при использовании AdGuard Home, так это то что я так и не понял как заставить использовать AmneziaVPN клиент AdGuard как основной DNS, при этом AmneziaWG работает прекрасно. Как я понимаю дело в том что AmneziaWG работает намного проще на уровне ip и у него нету никаких доп фильтров, настроек и подобного, поэтому он просто берет данные из конфига.

От костылей на Bash к декларативному Ansible

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

Так я пришел к декларативному подходу и Ansible. Теперь вся конфигурация описывается в виде плейбуков и ролей, отражающих конечное желаемое состояние серверов. Конфиденциальные данные перенесены в файл secrets.yml, а хрупкие конструкции автоматизированы через шаблоны Jinja2. Проект стал идемпотентным: если шаги уже выполнены, Ansible их просто пропускает.

В итоге получилось несколько yaml файлов для стандартной настройки системы (bootstrap_os.yml) и для настройки каждого из хостов (setup_local.yml и setup_remote.yml). В итоге теперь все что нужно чтобы полностью с нуля развернуть проект - скачать Ansible, несколько других зависимостей на свой рабочий пк и запустить один manage_deploy.sh, в котором можно будет выбрать сценарий как будет вести себя Ansible и спокойно дождаться разворачивания сервисов.

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

Вот пример основного плейбука deploy.yml:

Тестирование мультидистрибутивности с помощью Vagrant

Проект изначально затачивался под работу на трех дистрибутивах: Ubuntu, Debian и Arch Linux. Тестировать Ansible-плейбуки прямо на рабочей локальной машине (в моем случае — EndeavourOS) слишком рискованно, а создавать виртуальные машины руками — долго и неудобно.

Решением стал Vagrant, позволяющий за пару минут развернуть чистые ОС в VirtualBox из готовых образов. Но в процессе настройки мультивендорного стенда в режиме сетевого моста (public_network) всплыли две критические проблемы:

1. Конфликт DNS: По умолчанию Vagrant создает NAT-интерфейс для управления нодой. При включении второго (публичного) интерфейса для локальной сети ломался дефолтный DNS-резолвер. Проблему пришлось решать принудительной очисткой и перезаписью файла /etc/resolv.conf через inline-скрипт автоматизации Vagrant.
2. Проблема с GRUB на Debian: В используемом базовом образе generic/debian12 конфигурация GRUB сохраняла жесткую привязку к конкретному имени диска из окружения сборщика. При повторном развертывании плейбуков на тестовом стенде это приводило к сбоям загрузчика. Чтобы автоматизировать очистку, пришлось внедрить скрипт, который на лету определяет имя системного диска через lsblk и автоматически передает правильные параметры в загрузчик через утилиту debconf-set-selections.

Вот код Vagrantfile: (в node.vm.provision происходит основное решение ошибок)

Надежная система бэкапов на базе BorgmaticДля создания резервных копий я внедрил Borgmatic (удобную надстройку над дедуплицирующим инструментом Borg Backup). Весь процесс автоматизирован с помощью связки системных юнитов borgmatic.service и borgmatic.timer. В бэкап уходят две ключевые директории: apps-data (конфигурации приложений и баз данных) и PersonalData (медиатека: музыка, книги, подкасты, файлы Nextcloud).

Развертывание системы бэкапов полностью берет на себя Ansible. Мне достаточно указать UUID внешнего жесткого диска — скрипт сам проверит его наличие в системе, примонтирует в нужную директорию, создаст зашифрованный репозиторий и настроит политику ротации (хранение 7 ежедневных, 4 еженедельных и 6 ежемесячных копий). Также в Prometheus выведен мониторинг самого репозитория .borg для отслеживания его размера и статуса успешности архивации.

Главная проблема при бэкапе работающих Docker-контейнеров — риск скопировать базу данных в «битом» или неконсистентном состоянии, если в момент создания архива в нее шла активная запись. Чтобы решить эту проблему, я задействовал механизм хуков в конфигурации Borgmatic.

Перед началом резервного копирования автоматически срабатывает команда остановки контейнеров проекта (docker-compose down), а после успешного завершения (или в случае возникновения непредвиденной ошибки) контейнеры автоматически поднимаются обратно в фоновом режиме. Для удобного просмотра архивов и быстрого восстановления файлов я развернул веб-интерфейс Borg UI.

Конфигурация borgmatic: (использую как Jinja2 шаблон, чтобы Ansible в плейбуках сам подставил переменные)

Наблюдаемость (Observability) уровня Enterprise

В последних релизах (v1.2.0 и v1.3.0) фокус проекта сместился на мониторинг и работу с логами.

Эволюция алертинга и переход на Gatus

Изначально для мониторинга доступности я смотрел на Uptime Kuma, но отказался из-за отсутствия удобной декларативной настройки через конфиги. Затем я развернул связку Blackbox Exporter и Alertmanager с уведомлениями в Matrix. Но тут крылась логическая несостыковка: весь алертинг был завязан на локальном ПК, и в случае его аппаратного отказа я бы просто лишился уведомлений.

Тогда я решил вернуть Uptime Kuma, но развернуть его на удаленном VPS в качестве внешнего «сторожа» и автоматизировать его настройку через Python-скрипт с библиотекой uptime-kuma-api. Но и тут ждали «грабли» — библиотека не обновлялась три года и намертво ломалась на свежих версиях Kuma.

В итоге идеальным решением стал Gatus. Он изначально проектировался под управление через YAML-конфиги и поддерживает отправку алертов, если сервер не отвечает. Из-за специфики фронтенда Gatus (он не умеет работать из подкаталога типа /gatus), мне пришлось перенести его и wg-easy на полноценные субдомены gatus. и wireguard.

Для Gatus получился простой конфиг:

Для мониторинга аппаратных ресурсов удаленного и локального серверов была развернута связка node-exporter + cAdvisor. Все уведомления теперь приходят мгновенно в Telegram-бота. Чтобы избежать лавины одинаковых сообщений (например, при перезагрузке хоста), в Alertmanager настроена жесткая группировка и дедупликация событий. Также добавлен экспортер для AdGuard Home, выводящий статистику заблокированных запросов в Grafana.

Централизованные логи: Loki + Grafana Alloy

В релизе v1.3.0 в стек была добавлена централизованная система сбора логов Loki. Вместо устаревшего Promtail в качестве агента сбора я применил Grafana Alloy.

Он эффективно собирает логи со всех запущенных Docker-контейнеров, парсит их и передает в Loki. Теперь вся история событий, ошибок веб-сервера Nginx или падений внутренних приложений доступна в едином интерфейсе Grafana с возможностью удобной фильтрации через LogQL, что значительно упрощает отладку.

Конфиг Loki:

Конфиг Grafana Alloy: (локальный конфиг)

Интерфейс: переход на Homepage

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

В итоге я заменил самописную страницу на полноценный комьюнити-проект Homepage. Это дало некоторую гибкость: вся панель настраивается через простые YAML-файлы и поддерживает встроенные виджеты интеграции. Пока что она простенькая, но возможно в будущем сделаю что-то более продвинутое.

Заключение

Постарался подробно рассказать о структуре проекта и как я к этому пришел, очень много я не добавил, если пост зайдет, то я обязательно более подробно пройдусь по некоторым моментам: как я настраивал Matrix и на каком моменте я решил его убрать, как собирал локальный amnezia контейнер-клиент, что нового я добавил в релизе 1.4.0 и другое.

Также я перешел с manage_deploy.sh на отдельный GUI клиент, который будет полностью автоматизировать процесс подготовки к deploy. (написан на Go Wails). Про это тоже возможно сделаю статью.

Вся кодовая база проекта, подробная документация, инструкции по развертыванию открыты и доступны для сообщества:

🔗 GitHub-репозиторий: https://github.com/canntstand/ServeHub-2

Это моя первая статья на этом сайте и в то же время первый личный проект, которому я отдал так много времени (3 месяца). Буду рад вашему фидбеку в комментариях!

OpenCode запускается в терминале как текстовый интерфейс (TUI) и ведёт себя как собеседник, которого вы явно направляете. Попросите проанализировать функцию, объяснить баг, добавить типизацию или переписать модуль — и агент сделает это с учётом всего проекта, а не только вставленного фрагмента. Поддерживается более 75 провайдеров, включая Anthropic, OpenAI и Google Gemini.

В отличие от облачных IDE с ИИ, OpenCode не заставляет загружать код на чужие серверы: он общается с моделью из вашей локальной среды, а файлы остаются на вашей машине. Для командной работы есть файл AGENTS.md — аналог инструкции для агента, который загружается в начале каждой сессии.

• OpenCode — бесплатный open-source ИИ-агент для терминала с поддержкой 75+ моделей.
• Устанавливается одной командой curl, через Homebrew или npm; для старта достаточно ключа Gemini.
• Plan-режим предлагает план правок без изменения файлов, Build-режим сразу применяет их.
• AGENTS.md задаёт правила проекта: стиль кода, архитектуру и команды запуска.
• Встроенные LSP-серверы (Pyright для Python) и веб-интерфейс отличают OpenCode от конкурентов.

Установка и первый запуск

Самый быстрый способ — официальный скрипт. Он определяет платформу, скачивает бинарник и прописывает путь в PATH. Альтернативы — Homebrew для macOS/Linux и npm-пакет, если Node.js уже стоит.

Другие способы установки

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

Если команда не найдена, перезагрузите конфигурацию shell:

Для Windows лучший опыт — WSL. Храните проекты внутри файловой системы WSL, а не на диске C:, иначе производительность упадёт.

Подключаем модель

Запустите opencode без аргументов — откроется TUI. Чтобы добавить провайдера, введите слэш-команду /connect и выберите Google. Ключ можно получить бесплатно в Google AI Studio: вход через Google-аккаунт, пара кликов — и ключ готов.

После подключения выберите модель. Для повседневных задач подходит Gemini 3 Flash Preview — быстрая и дешевая (в данном случае бесплатная) модель. Переключить модель позже можно через /models.

Где хранятся ключи:
Токены сохраняются в ~/.local/share/opencode/auth.json. Скрипт запросит ключ повторно, только если вы захотите сменить провайдера.

Проверьте работу простым вопросом:

AGENTS.md — память проекта

Главная фишка OpenCode — понимание контекста. Каждый раз при запуске агент читает файл AGENTS.md из корня проекта. Там можно описать архитектуру, стиль кода, команды тестирования и форматирования, а также специфические требования к проекту.

Создать заготовку помогает команда /init. Она проанализирует структуру проекта — файлы, импорты, директории — и сгенерирует черновик. После этого файл стоит дополнить своими правилами.

Важно: после ручного изменения AGENTS.md перезапустите сессию или попросите агента перечитать файл. Также полезно периодически вызывать /init, чтобы документ актуализировался под текущее состояние кода.

Plan и Build: два режима работы

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

• Plan — агент предлагает план изменений, но не трогает файлы. Это аналог предварительного просмотра diff.
• Build — агент сразу вносит правки в проект. Используйте, когда уверены в задаче.

Ещё есть варианты модели: default, low и high. Режим default автоматически регулирует глубину рассуждений под сложность задачи, что экономит токены на простых вопросах и не даёт ошибиться на сложных. Переключать вручную можно через Ctrl + T.

Контекст одним символом

Чтобы добавить файл в контекст, используйте символ @. Начните печатать имя файла — откроется fuzzy-поиск. А если сообщение начинается с восклицательного знака !, OpenCode выполнит shell-команду и включит её вывод в беседу.

Рефакторим Python-проект

Разберём реальный сценарий: у нас есть скрипт обработки CSV, который «работает, но стыдно показать». Попросим OpenCode привести его в порядок.

Сначала переключитесь в Plan-режим и задайте запрос с контекстом файла:

OpenCode, опираясь на AGENTS.md, найдёт типичные проблемы: отсутствие if __name__ == "__main__":, нет type hints, магические числа, неинформативные сообщения об ошибках. В конце он предложит план — например, выделить main(), добавить аннотации, заменить SystemExit на ValueError и ввести константы.

Если план устраивает, переключитесь в Build и подтвердите — агент применит изменения. После этого останется запустить тесты:

Если что-то пошло не так, команда /undo откатывает последнее изменение. Можно вызывать её несколько раз, чтобы вернуться к нужному состоянию.

Что отличает OpenCode от конкурентов

Переключение моделей на лету

Claude Code и Cursor привязаны к своим моделям. В OpenCode можно подключить сразу несколько провайдеров и переключаться между ними через /models без перезапуска. Это удобно, когда одна модель лучше справляется с архитектурой, а другая — с мелкими правками.

Встроенные LSP-диагностики

OpenCode использует Language Server Protocol и поставляется с более чем 30 встроенными языковыми серверами. Для Python по умолчанию работает Pyright, который подсвечивает ошибки типов, неопределённые имена и проблемы с импортами. Эти диагностики передаются модели, поэтому агент видит то же, что и ваш редактор.

Веб-интерфейс

Если терминал кажется тесным для длинных ответов, запустите opencode web в отдельной вкладке. Поднимется локальный сервер на 127.0.0.1, откроется браузер, и вы получите ту же беседу в графическом виде. Терминал и веб-интерфейс работают одновременно и делят одно состояние сессии.

Практические советы

• Начинайте каждую сессию с проверки AGENTS.md — это экономит токены и повышает качество ответов.
• Сложные правки сначала прогоняйте в Plan-режиме: так проще поймать неверные предположения агента.
• Для российских разработчиков бесплатный Gemini — самый доступный вариант: не требует иностранной карты и работает из РФ с ограничениями.
• Не забывайте про /compact: длинные сессии занимают контекст, и свёртка истории ускоряет работу.
• Коммитьте AGENTS.md в Git: так вся команда получает единые инструкции для ИИ-помощника.

Выводы

OpenCode — удобный вариант для разработчиков, которые хотят ИИ-помощника в терминале без привязки к платным подпискам. Особенно он выигрывает там, где важен контекст проекта: благодаря AGENTS.md и режимам Plan/Build агент не превращается в слепого исполнителя, а работает как внимательный напарник.

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

Если вы ещё не пробовали терминальных ИИ-агентов, OpenCode — хорошая точка входа. Установка занимает минуту, первый ключ Gemini бесплатный, а дальше можно решать: оставить его как основной инструмент или использовать в связке с привычным редактором.

Источники:

• How to Use OpenCode for AI-Assisted Python Coding — Real Python
• Официальный сайт OpenCode

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

itertools — модуль стандартной библиотеки Python, который предоставляет ленивые итераторы для композиции цепочек обработки данных.

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

Функции разделены на три группы: бесконечные итераторы (count, cycle, repeat), конечные итераторы (chain, islice, groupby и др.) и комбинаторные (product, permutations, combinations).

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

Подводные камни: groupby требует предварительной сортировки по тому же ключу; итераторы одноразовые; tee() может неэкономно расходовать память.

Зачем вообще ленивые итераторы?

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

Ленивый итератор не строит коллекцию целиком. Он помнит текущее состояние и умеет «добыть» следующий элемент. Поэтому itertools работает с любыми итерируемыми источниками — файлами, генераторами, сетевыми потоками — и не требует, чтобы весь объём данных поместился в оперативную память.

Память vs скорость:
Ленивость экономит память, но не всегда ускоряет код. Если данные всё равно нужны целиком — например, для сортировки — список может оказаться быстрее. Используйте итераторы там, где важна потоковая обработка.

Три семейства инструментов

Документация Python делит функции модуля на три группы. Такое разделение помогает быстро выбрать инструмент: нужна бесконечная последовательность, преобразование конечной или перебор комбинаций.

Бесконечные итераторы: count, cycle, repeat

count — это range без конца. Ему можно задать начальное значение и шаг, и он будет выдавать числа до тех пор, пока его не остановят снаружи. cycle бесконечно повторяет переданную последовательность, а repeat — бесконечно или заданное число раз возвращает один объект.

Классический трюк — сочетание map и count: map(f, count()) работает как математическое табулирование tabulate(f), знакомое из SML и Haskell.

Конечные итераторы: chain, islice, groupby и другие

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

batched появился в Python 3.12 и сразу стал незаменимым инструментом: партии запросов к API, пакеты строк для вставки в базу, страницы данных. Последняя партия может быть короче — это поведение по умолчанию.

groupby часто путают с SQL-аналогом, но это не тот же инструмент. Python-версия группирует только подряд идущие одинаковые ключи, поэтому перед ней обычно нужна сортировка по тому же ключу. Если забыть про это, результат покажется случайным.

Комбинаторные итераторы: product, permutations, combinations

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

product с аргументом repeat удобен для перебора многомерных конфигураций: product([0, 1], repeat=3) даст все двоичные triples, как в таблице истинности.

Подводные камни, за которые хватаются новички

Несмотря на простоту отдельных функций, у модуля есть несколько особенностей, которые легко превратить в баг.

• groupby работает только с подряд идущими одинаковыми ключами. Перед вызовом сортируйте данные по тому же ключу, иначе группы разобьются.
• Итераторы одноразовые. После list(iterator) исходный итератор опустошён, и второй проход по нему даст пустой результат.
• tee копирует данные во внутренний буфер, пока все производные итераторы не прочитают их. Если один итератор сильно отстаёт, память может расти не хуже списка.
• zip_longest с бесконечным итератором никогда не остановится. Ограничивайте такие комбинации islice или takewhile.
• product полностью потребляет входные итераторы, чтобы построить пулы значений. С бесконечными последовательностями его использовать нельзя.

Рецепты: от простого к составному

Документация Python включает раздел рецептов — готовые комбинации функций, которые решают частые задачи. Некоторые из них настолько удобны, что со временем превращаются в полноценные функции модуля: так появились accumulate, compress и pairwise.

Для sliding_window сейчас часто используют рецепт из документации или аналог из more-itertools, где функция уже реализована и хорошо протестирована.

Выводы

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

Together, they form an iterator algebra making it possible to construct specialized tools succinctly and efficiently in pure Python.

Источник: itertools — Functions creating iterators for efficient looping. Если в вашем коде до сих пор царят вложенные циклы и огромные списки — попробуйте заменить их на поток. Скорее всего, получится короче, быстрее и понятнее.

В этой статье разберём, как внутри устроены метаклассы, зачем нужен встроенный type с тремя аргументами и когда стоит писать свой метакласс, а когда — обойтись наследованием или декоратором.

Класс — тоже объект

В Python 3 любой класс является экземпляром метакласса. По умолчанию этим метаклассом выступает type. Поэтому запись class Foo: pass интерпретатор превращает примерно в такой вызов:

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

type сам является экземпляром себя — это одна из тех особенностей Python, которые сначала удивляют, а потом помогают понять, что классы и объекты в языке живут по одним правилам.

Метакласс — это класс, экземплярами которого являются другие классы.

В Python 3 по умолчанию метаклассом любого класса является type.

Вызов type(name, bases, dict) создаёт класс динамически.

Собственный метакласс наследуется от type и переопределяет __new__ или __init__.

Чаще всего задачу решают наследованием или декоратором класса — метакласс нужен редко.

type — не только функция проверки типа

Всем знаком вызов type(x), который возвращает тип объекта. Но если передать type три аргумента, он превращается в фабрику классов:

• первый аргумент — имя класса (становится __name__);
• второй — кортеж базовых классов (становится __bases__);
• третий — словарь пространства имён (становится __dict__).

Этот механизм лежит в основе любого определения класса. Когда Python видит ключевое слово class, он сначала собирает тело класса в словарь, а затем вызывает метакласс, чтобы создать сам класс.

Пример — класс с методом, собранный вручную:

Такой код редко пишут в production, но он наглядно показывает, что класс — это всего лишь объект, созданный вызовом фабрики. А значит, эту фабрику можно заменить на свою.

Как написать свой метакласс

Чтобы изменить процесс создания класса, наследуемся от type и переопределяем __new__. Этот метод отвечает за создание самого класса, поэтому в нём можно добавить общие атрибуты, проверить имя или зарегистрировать класс в каталоге.

Здесь AutoAttrMeta автоматически добавляет атрибут version каждому классу, который её использует. То же самое можно сделать через наследование, но метакласс действует на этапе создания класса, а не при вызове методов.

Помимо __new__, часто переопределяют __init__ метакласса: он получает уже созданный класс и может его донастроить. А __call__ контролирует создание экземпляров класса — именно он вызывает __new__ и __init__ объекта.

А точно нужен метакласс?

Тим Петерс, автор «Дзена Python», как-то сказал, что метаклассы — это магия, которую 99% разработчиков никогда не понадобится. Если вы сомневаетесь, нужны ли они вам, — скорее всего, не нужны.

Метаклассы — это более глубокая магия, чем та, о которой 99% пользователей должны беспокоиться. Если вы сомневаетесь, нужны ли они вам, значит, не нужны.

Для сравнения — три способа дать классам общий атрибут:

Наследование

Декоратор класса

Метакласс

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

Когда метакласс действительно уместен:
— автоматическая регистрация подклассов в плагиновой системе;
— валидация объявлений полей (например, ORM проверяют типы атрибутов);
— принудительный единый API для большого семейства классов;
— реализация паттернов вроде Singleton на уровне класса.

Практический пример: автоматическая регистрация плагинов

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

Такой подход удобен, потому что автор плагина просто объявляет класс, а реестр обновляется сам. В реальных фреймворках — например, в старых версиях Django — похожая идея используется для построения моделей данных.

Выводы

Метаклассы — не ежедневный инструмент, но понимание их работы делает код Python прозрачнее. Вы начинаете видеть, что class — это тоже объект, а type — всего лишь фабрика, которую при желании можно заменить.

Главное правило: если задачу решает наследование или декоратор класса, не тащите метакласс. А если без контроля за созданием класса никуда — смело берите type и наследуйтесь от него.

Источник и дополнительное чтение: Python Metaclasses на Real Python.

С практической точки зрения проект на**й не нужен. Есть GitHub, GitLab и куча нормальных инструментов. Но как эксперимент — почему бы и нет? Чисто посмотреть, можно ли заставить Telegram работать как VCS.

Почему не JSON

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

Подергал JSON туда-сюда пару дней и понял: не варик.

1. Конкурентный доступ. Два юзера одновременно коммитят — один перезаписывает файл другого.
2. Целостность данных. Если бот упал в середине записи — JSON остаётся в невалидном состоянии.
3. Версионность. Хранить историю изменений в JSON — это просто перенести проблему из кода в структуру файла.

Вывод: JSON — для конфигов, а не для данных, которые меняются каждую секунду.

Выбор SQLite и схема БД

Выбрал SQLite, потому что:

• Не надо поднимать отдельный сервер
• Целостность данных на уровне движка (транзакции, foreign keys, rollback)
• Всё в одном файле — скопировал и унёс

Сущности:

• users — telegram_id, username, current_project_id
• projects — owner_id, name, thread_id (каждый проект живёт в своём треде канала)
• files — filename, current_version, флаг modified (файл изменился и готов к коммиту)
• file_versions — мясо. Каждая версия файла с полным содержимым. Привязана к file_id и опционально к commit_id
• commits — сообщение, время, ссылка на проект
• commit_files — связка коммитов с версиями файлов (many-to-many, чтобы поддержать ветки)

Почему так: я хотел иметь возможность откатиться к любой версии любого файла. Да, база распухнет, но текстовые файлы — это не гигабайты видео. Плюс наличие file_versions и commit_files позволяет делать diff между версиями и смотреть историю изменений.

В коде вместо голых кортежей из SQL — датаклассы:

Маркдауновый ад

Казалось бы: взял код, обернул в тройные апострофы, кинул в Telegram. Telegram сам подсветит синтаксис, если указать язык. Красота. В теории.

На практике Telegram использует свой диалект Markdown, где куча служебных символов: _ * [ ] ( ) ~ > # + - = | { } . !

Попытка 1: заэкранировать всё подряд. Результат: код превращается в кашу. Вместо def __init__- получается def |_|_init|_|_ — уже не запустишь, и в канале выглядит как говно.

Попытка 2: не экранировать вообще. Telegram шлёт на**й с ошибкой «can't parse entities».

Попытка 3: экранировать только то, что реально ломает разметку. Выяснилось, что порядок важен. Сначала экранируем точки и подчеркивания, потом обратную косую черту. Но и это не панацея — последовательности типа \*

после экранирования превращаются в \\*, и Telegram снова недоволен.

Попытка 4: разбивать на части. Для больших файлов делаю превью (первые 50 строк), экранирую их, отправляю как код, а полную версию — файлом. И тут начался ад: Telegram находил ошибки в тех частях кода, которых в превью вообще не было. Оказывается, он всё равно парсил полный код, даже если отправлялась только его часть.

Попытка 5 (финал): забил на Markdown и перешёл на HTML. Telegram умеет его принимать. Да, он не такой красивый, но зато предсказуемый:

Никаких точек, подчеркиваний, обратных слешей. Просто экранируем три символа — и код летит как надо.

Security by design

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

Добавил в /commit. Потом решил с другого аккаунта потестировать команды на чужих файлах. И тут бот на каждую команду стал выдавать «файл не найден» или «проект не найден». И я понял: безопасность уже работает. С самого начала. Из коробки. Без единой строчки кода.

Как так вышло? В таблице projects с самого начала было поле owner_id. При создании проекта я писал туда telegram_id владельца. Все запросы к БД фильтруются по этому полю:

Показать проекты — только свои. Найти файл — только в своих проектах. Выбрать проект — только из своих. Никаких лишних проверок. Просто SQL-запросы, которые с самого начала учитывали владельца.

Команды: от семи до двух десятков

Изначально казалось, что команд будет немного. Но...

Жизнь рассудила иначе.

• База: /start, /init, /use, /list, /ls, /commit, /log, /status
• Удаление: /rm, /rmproject + подтверждение
• Игнор: /ignore, /ignored, /unignore
• Ветки: /branch, /branches, /checkout
• Диффы и просмотр: /diff, /cat

Итого — уже под два десятка. И это не предел.

Простота > абстракции

В моём коде нет абстрактных базовых классов. Совсем. Потому что они нужны только когда у тебя есть минимум две разные реализации одного и того же. В GitGram всё проще: один способ работать с БД, один способ шифровать, один способ парсить .gitignore.

Если завтра появится вторая реализация — тогда и буду делать интерфейс. А пока это просто оверхед.

В GitGram:

• Хочешь понять, как работает add_file — идёшь в database.py и читаешь 10 строк кода.
• Хочешь увидеть обработчик /commit — открываешь bot.py и смотришь.

Никаких AbstractMinerShieldEventProcessor, BaseGitGramManager, InterfaceProviderFactory.

Код должен быть тупым. Чем тупее — тем проще его читать и отлаживать.

Что дальше

В планах:

• Докрутить коллаборацию (несколько человек над одним проектом)
• Приватные репозитории
• Кодспейс прямо в боте (да да знаю я сошёл с ума и бла бла бла..)

Итог

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

На практике GitGram ни к чему. Но сама задумка — Git в Telegram — это же так прикольно. Просто посмотреть, можно ли такое вообще запилить.

Если хочешь поучаствовать

• GitGram
• Чат для хардкорных: @sandbox_hardcore — вся сырая разработка, факапы и обсуждения (без цензуры)

Подписывайся на мой TГ-канал — там я публикую все свои эксперименты, код и приглашаю к обсуждению. Только факты, мат и никакой политоты.

На первый взгляд кнопка «наверх» — задача на пять минут. Добавил position: fixed, обработчик window.scrollTo() — готово.

Но стоит этой кнопке появиться в живом проекте, как выясняется, что она пересекается с cookie-баннером, мешает чату поддержки, выглядит иначе в мобильной версии, не дружит со строгим CSP или пропадает из Django Admin.

В итоге маленькая UI-деталь начинает обрастать условиями. Я решил собрать их в отдельный Django-пакет — django-scroll-to-top

Когда трёх строк JavaScript достаточно

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

Это нормальное решение. Не всегда стоит тянуть пакет ради одной кнопки.

Но в реальном Django-проекте быстро появляются дополнительные вопросы:

• когда именно показывать кнопку: после 300 пикселей, одного экрана или только при прокрутке вверх;
• что делать на коротких страницах;
• как не перекрыть cookie-баннер, чат, toast-уведомления или нижнюю мобильную навигацию;
• как дать пользователю закрыть кнопку;
• как не сломать клавиатурную навигацию и режим reduced motion;
• как сделать отдельное оформление для сайта и Django Admin;
• как не заставлять проект добавлять unsafe-inline в Content Security Policy;
• как позволить редактору или администратору изменить цвет, положение и иконку без нового деплоя.

Именно в этот момент «три строки JavaScript» превращаются в отдельный компонент.

Что я хотел получить

Цель была не в том, чтобы сделать ещё одну стрелку в правом нижнем углу. Хотелось собрать переиспользуемый компонент со следующими свойствами:

1. Подключение сайта одной template-тегом.
2. Отдельная поддержка обычных страниц и стандартного Django Admin.
3. Настройка внешнего вида через админку, а не через постоянную правку CSS.
4. Без jQuery, CDN, фронтенд-фреймворка и обязательной сборки.
5. Безопасная работа при строгой CSP.
6. Прогрессивное улучшение: без JavaScript остаётся обычная ссылка в начало страницы.
7. Возможность жить рядом с другими фиксированными элементами интерфейса.

Пакет в итоге хранит обычные настройки установки в settings.py, а визуальное поведение — в базе данных. Это позволяет менять кнопку через Django Admin, публиковать новую версию настроек и при необходимости откатываться на предыдущую. В проекте есть отдельные профили для публичного сайта и Django Admin, а ревизии могут быть черновыми, опубликованными или архивными.

Быстрое подключение

Базовый сценарий начинается с установки:

В settings.py добавляем приложение. Если нужна поддержка стандартной админки, пакет должен идти раньше django.contrib.admin:

Включаем области, где должна работать кнопка:

Для публичной части добавляем URLConf пакета:

А в общий шаблон сайта — один тег:

На стандартном Django Admin ничего дополнительно вставлять не нужно: пакет использует обычный механизм разрешения шаблонов Django. Если же в проекте переопределён admin/base_site.html тег можно добавить вручную в блок footer

Настройка без превращения админки в редактор CSS

Мне не хотелось хранить в базе шаблоны, произвольный CSS или JavaScript. Это неудобно для сопровождения и создаёт лишнюю поверхность для ошибок.

Поэтому визуальная часть собрана из контролируемых вариантов:

• круг, квадрат, скруглённый квадрат или pill;
• заливка solid, outline, soft, ghost, glass или gradient;
• положение в любом углу экрана;
• отдельные размеры для desktop и mobile;
• светлая и тёмная тема;
• встроенные иконки, иконки от разработчика или загружаемые SVG;
• настройки тени, границы, opacity и focus ring.

Что происходит, когда рядом есть cookie-баннер или чат

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

• cookie-баннер;
• компактная кнопка после закрытия баннера;
• чат поддержки;
• кнопка обратного звонка;
• мобильная навигация;
• toast-уведомления.

Пакет умеет рассматривать такие элементы как препятствия. Для этого можно пометить элемент атрибутом:

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

Для сложных виджетов есть отдельный адаптер: он может отслеживать появление и исчезновение элементов, например компактного launcher после закрытия cookie-баннера. При этом ни cookie-пакет, ни чат не становятся зависимостями django-scroll-to-top

Доступность — не отдельная галочка в конце

У кнопки есть понятное имя для screen reader, поддержка клавиатуры, видимый focus-visible, минимальный размер области нажатия и режим prefers-reduced-motion.

Если пользователь отключил анимации на уровне системы, плавная прокрутка не будет навязываться. Если JavaScript не загрузился, кнопка остаётся обычной ссылкой на начало документа.

Полный независимый аудит WCAG 2.2 AA и тестирование масштабирования 200% и 400% пока находятся в roadmap, поэтому называть компонент полностью сертифицированным по WCAG было бы неправильно. Но структурные требования — клавиатурная доступность, фокус, reduced motion, forced-colors и безопасная работа без JavaScript — уже заложены в компонент и покрываются тестами.

CSP и загружаемые SVG

В корпоративных проектах часто нельзя просто добавить inline-скрипт и включить unsafe-inline ради одной кнопки.

По умолчанию компонент использует same-origin CSS и JavaScript. Для него подходит политика такого вида:

Настраиваемые цвета и размеры отдаются не через inline-стили, а через версионированный stylesheet endpoint. Это позволяет сохранить простой контракт с одним template-тегом и не ослаблять CSP.

Отдельно пришлось подумать о загружаемых SVG. Админ не рендерит исходный файл как есть: SVG проходит санитарную обработку. Скрипты, обработчики событий, внешние ресурсы, встроенные документы и небезопасные namespace отклоняются. Для загружаемых иконок также хранится информация об авторе, источнике и лицензии.

Ревизии, публикация и откат

Одна из самых полезных вещей в пакете — не сама кнопка, а жизненный цикл её настроек.

Можно создать черновик, посмотреть результат в live preview, опубликовать изменения или вернуться к предыдущей версии. Это особенно удобно, когда кнопку настраивает не разработчик, а контент-менеджер или дизайнер.

У ревизий есть три состояния:

• draft — редактируемый черновик;
• published — текущая активная конфигурация;
• archived — сохранённая версия для отката.

Где пакет уместен, а где нет

django-scroll-to-top имеет смысл, когда кнопка нужна в нескольких проектах, должна работать в Django Admin, настраиваться без деплоя или жить в окружении со строгими требованиями к CSP и интерфейсу.

Для лендинга на одну страницу проще и правильнее написать несколько строк самостоятельно. Это будет быстрее, понятнее и дешевле в сопровождении.

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

Сейчас пакет выпущен как beta-версия 0.2.0, требует Python 3.10+ и поддерживает Django 4.2 LTS, 5.x и 6.0. Лицензия — MIT.

Исходный код, документация и примеры использования доступны в GitHub-репозитории проекта.

Пакет опубликован в PyPI под именем django-scroll-to-top.

Обратная связь, баг-репорты и предложения по интеграции с кастомными Django Admin-темами приветствуются в Issues.

Что делает time.sleep()

Функция time.sleep(seconds) приостанавливает выполнение текущего потока на указанное время. Аргумент — число секунд, включая дробные значения. Например, 0.001 — это одна миллисекунда, а 1.5 — полторы секунды.

Важный нюанс: time.sleep() гарантирует лишь минимальную задержку. Реальная пауза почти всегда чуть дольше из-за планировщика операционной системы и текущей нагрузки. Для большинства задач это не критично, но для высокоточного тайминга лучше искать другие инструменты.

Типичные сценарии использования

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

• Распределение запросов к API с ограничением rate limit.
• Повторные попытки выполнения ненадёжных операций.
• Пауза между итерациями мониторинга или парсинга.

Мониторинг сайта с интервалом в 60 секунд

Простой аптайм-бот опрашивает страницу и засыпает на минуту. Без задержки скрипт уйдёт в бесконечный цикл и может получить бан по IP.

Совет:
Для реального мониторинга добавьте логирование или уведомления, иначе ошибки останутся только в консоли.

Декоратор для повторных попыток

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

Обратите внимание на raise внутри блока except: если его убрать, исключение не пойдёт наружу, и декоратор не поймёт, что нужна повторная попытка.

Паузы в потоках: Event.wait()

В потоках можно использовать time.sleep(), но он непрерываен: поток не сможет быстро завершиться, пока спит. Для корректной остановки лучше применять threading.Event().wait(). Этот метод прерывается, как только событие установлено через event.set().

Такой подход позволяет аккуратно завершить все потоки по Ctrl+C: event.set() мгновенно будит все ожидающие wait().

Неблокирующие паузы в asyncio

Асинхронный код в Python появился в версии 3.4 модуля asyncio и получил синтаксис async/await в 3.5. Внутри корутин нельзя использовать обычный time.sleep(): он заморозит весь event loop. Для паузы в асинхронном коде есть asyncio.sleep().

Ключевое отличие: asyncio.sleep() приостанавливает только текущую корутину, уступая управление event loop. Остальные задачи продолжают выполняться. Это особенно важно при соблюдении rate limit при параллельных запросах.

Как не заморозить GUI

В GUI-фреймворках весь интерфейс работает в главном потоке с собственным циклом событий. Если вызвать time.sleep() в обработчике кнопки, окно повиснет: не будет отрисовки, не сработают клики, а в Windows может появиться предупреждение о неответствии.

Метод .after() в Tkinter планирует callback через заданное число миллисекунд и сразу возвращает управление циклу событий. Аналог в wxPython — wx.CallLater(). Паттерн универсален: не блокируйте поток, планируйте отложенный вызов.

• time.sleep() — универсальный способ поставить синхронную паузу, но он блокирует поток целиком.
• Для повторных попыток удобен декоратор с задержкой, который ловит исключения и делает retry.
• В потоках предпочитайте Event.wait(): его можно прервать через event.set().
• В асинхронном коде используйте asyncio.sleep(), иначе заморозите весь event loop.
• В GUI применяйте фреймворковые методы вроде Tkinter.after(), чтобы интерфейс оставался отзывчивым.

Выводы

Пауза в коде — это не просто «подождать секунду». В синхронном скрипте достаточно time.sleep(), в потоке важно уметь выходить по сигналу, в асинхронном коде нельзя блокировать event loop, а в GUI нужно работать в рамках фреймворкового цикла событий. Правильный инструмент зависит от контекста, и выбор влияет на отзывчивость и стабильность приложения.

Не блокируйте поток без причины. Если можно уступить управление — уступите.

Источник и дополнительные материалы: Real Python — Python sleep(): How to Add Time Delays to Your Code.

• Apache Airflow — мощный оркестратор для сложных Python-конвейеров, но требует инфраструктуры и DevOps-культуры.
• n8n — визуальный конструктор с открытым исходным кодом: удобен для средних нагрузок, можно бесплатно хостить на своём сервере.
• Make (бывший Integromat) — облачный визуальный автоматизатор для бизнес-команд, дешевле Zapier, но тарифицирует каждый шаг сценария.
• Для российских команд критичны: возможность self-hosting, стоимость инфраструктуры и риски доступности зарубежного SaaS.
• Нет универсального победителя — выбор зависит от размера команды, сложности логики и требований к контролю над данными.

API-оркестрация — это не просто «позвонить в API», а построить надёжный конвейер: вызвать один сервис, передать результат в другой, обработать ошибку, повторить при сбое и записать лог. Иногда это пара запросов в час, а иногда — десятки тысяч операций в день. Отсюда и разница в подходах: где-то важна гибкость кода, где-то — скорость запуска, а где-то — цена за операцию.

Apache Airflow: тяжёлый артиллерист

Airflow появился в Airbnb и за десять лет стал стандартом для data-пайплайнов. Его используют Netflix, Spotify и Uber — там, где нужно управлять сотнями зависимых задач с контролем SLA и аудитом. Главная идея: вы описываете workflow как Python-код в виде направленного ациклического графа (DAG), а scheduler отвечает за порядок, ретраи и мониторинг.

Зачем выбирать Airflow

• Сложная логика: ветвления, условия, ретраи, расписания через cron.
• Полный контроль над кодом: любые библиотеки Python, кастомные операторы, unit-тесты.
• Зрелая экосистема: SLA-мониторинг, audit trail, интеграция с Kubernetes и Spark.
• Open Source: можно развернуть на своей инфраструктуре, в том числе на российских облаках.

Честный взгляд на минусы

• Высокий порог входа: нужно разворачивать БД, Redis, воркеры и веб-интерфейс.
• Минимальный кластер на VPS обходится примерно в €50/месяц без учёта времени администратора.
• При 50+ задачах DAG превращается в большой Python-файл, который сложно поддерживать без дисциплины.
• Коммуникация между задачами через XCom требует внимания: забыли очистить — получили memory leak.

Пример простого DAG, который забирает пользователя, его посты и считает количество:

Airflow хорош, когда у вас уже есть data-команда, Kubernetes и понимание, зачем нужны DAG. Для стартапа из трёх человек это, скорее, оверинжиниринг.

n8n: визуальный middle ground

n8n занимает промежуточную нишу между кодом и no-code. Это node-based редактор: вы перетаскиваете блоки, соединяете их стрелками, а логика — в JavaScript-функциях и условиях. Главное преимущество: n8n open-source, его можно поднять на собственном сервере, и за это не придётся платить пошагово.

Зачем выбирать n8n

• Быстрый старт: визуальный конструктор позволяет собрать пайплайн за час, а не день.
• Self-hosting: контейнер на VPS за $5–10/мес может обрабатывать тысячи запусков в день.
• Гибридный подход: 90 % задач решается мышкой, сложную трансформацию можно написать на JS.
• Прозрачная цена облака: плата за выполнение workflow, а не за каждый модуль.

Ограничения

• При сотнях задач в одном workflow визуальная схема становится громоздкой.
• Нативные узлы покрывают не всё: экзотический API придётся звать через HTTP Request.
• Self-hosted версия требует обновлений и бэкапов — это всё ещё инфраструктура, хоть и простая.
• Для России: облако n8n — европейский сервис, но self-hosted можно развернуть на Selectel, Yandex Cloud или любом другом провайдере.

Пример JSON-экспорта workflow, который забирает пользователей, преобразует данные и пишет в PostgreSQL:

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

Make: бизнес-автоматизация по шагам

Make (ранее Integromat) — это облачный визуальный автоматизатор для бизнес-команд. Его сценарии собираются из модулей: триггер → действие → фильтр → маршрутизатор. По сравнению с Zapier у Make глубже логика, а цена ниже, но он остаётся полностью SaaS-решением.

Зачем выбирать Make

• Быстрая интеграция с популярными сервисами: Google Sheets, Slack, Telegram, CRM, email-рассылки.
• Визуальные маршрутизаторы (routers), итераторы и агрегаторы позволяют строить ветвления без кода.
• Низкий порог входа для маркетологов, менеджеров продукта и операционистов.
• План Core стоит от $9/мес за 10 000 операций — дешевле многих конкурентов.

Подводные камни

• Тарификация по операциям: каждый модуль в сценарии считается отдельно. Десять шагов × тысяча запусков = 10 000 операций.
• Нельзя self-host: данные обрабатываются на серверах Make, что может быть проблемой для чувствительных данных.
• Для России: сервис работает как зарубежный SaaS, есть риски доступности и оплаты.
• Сложные сценарии сложнее отлаживать: приходится кликать по модулям в истории выполнений.

Типичный сценарий в Make выглядит так: вебхук из формы → проверка дубликата в Google Sheets → запись в CRM → отправка уведомления в Telegram. Всё это строится мышкой, но стоит добавить кастомную логику — и придётся использовать HTTP-модуль или встроенные функции.

Сравнение в цифрах

Сводная таблица по ключевым параметрам. Вместо абстрактных «плюсов» смотрите на конкретные ограничения:

• Airflow — код Python, self-hosted, сложность высокая, стоимость от €50/мес + администрирование, лучше для data-платформ.
• n8n — визуальный + JS, self-hosted или cloud, средняя сложность, self-hosted от $5–10/мес, лучше для средних нагрузок и гибридных команд.
• Make — визуальный no-code, только cloud, низкая сложность входа, от $9/мес за 10K операций, лучше для бизнес-автоматизации.
• Модель оплаты: Airflow — инфраструктура; n8n — инфраструктура или executions в облаке; Make — операции (каждый модуль отдельно).
• Контроль данных: максимальный у Airflow и self-hosted n8n; минимальный у Make как SaaS.

Российская специфика:
Для команд в РФ критичен self-hosted путь: Airflow и n8n можно развернуть на отечественных VPS или в Yandex Cloud/Selectel. Make, Zapier и другие зарубежные SaaS не дают гарантий доступности и оплаты. Если данные не могут покидать страну — выбор очевиден.

Как выбрать инструмент

FAQ

Выводы

Нет единого лучшего инструмента для API-оркестрации — есть подходящий под ваши ограничения. Airflow остаётся выбором зрелых data-команд, которым нужна масштабируемость и контроль. n8n закрывает большинство задач среднего уровня и даёт свободу self-hosting. Make — удобный SaaS для бизнес-автоматизации, но с привязкой к облаку и пошаговой тарификацией.

Хороший оркестратор не тот, у кого больше иконок в интерфейсе, а тот, чьи ошибки вы сможете отладить в два часа ночи.

Источник: материал основан на публикации «Airflow vs n8n vs Make for API orchestration» автора Raizan в DEV Community — dev.to/chasebot/airflow-vs-n8n-vs-make-for-api-orchestration-1lb8. Раздел про Make и сравнительный анализ дополнены редакционным контекстом.

В этой статье разберёмся, когда fine-tuning решает проблему, а когда проще обойтись промптами или RAG. Сравним LoRA, QLoRA и полное дообучение, посмотрим на цифры и напишем рабочий пайплайн на Python.

Что такое fine-tuning и зачем он нужен

Fine-tuning — это донастройка уже предобученной модели под конкретную задачу. Вместо того чтобы учить трансформер с нуля на сотнях гигабайт текстов, мы берём готовую LLM и показываем ей тысячи или десятки тысяч примеров, которые важны именно нам: стиль ответов, формат JSON, медицинскую терминологию или правила поведения в чат-боте.

Важный нюанс: дообучение меняет поведение модели, а не добавляет свежих фактов. Если вам нужно, чтобы бот знал актуальные цены, документацию API или внутреннюю базу знаний — правильный путь это RAG и хороший системный промпт, а не бесконечная перетренировка весов.

Когда fine-tuning — правильный выбор

Базовые модели 2026 года — GPT-5, Claude 4.5, Llama 3.3, Qwen 3, DeepSeek-V4 — научились следовать инструкциям, вызывать инструменты и выдавать структурированный вывод. Поэтому последовательность действий у большинства команд такая: сначала промптинг, потом RAG, и только потом fine-tuning.

Есть четыре ситуации, где дообучение действительно оправдано:

• Надёжность структурированного вывода. Если модель постоянно ломает JSON-схему или забывает поля, fine-tuning закрепляет правильный формат.
• Доменная лексика. Медицинские, юридические или научные термины, которые базовая модель «не осмеливается» использовать, можно вшить через SFT.
• Тон и политика отказов. Когда системные инструкции конфликтуют с базовой alignment-моделью, целевое дообучение перестраивает поведение точнее, чем промпты.
• Дистилляция и сжатие. Можно перенести способности большой модели на маленькую, чтобы удешевить инференс в продакшене.

Главное правило: не пытайтесь впрыснуть в модель факты через дообучение. Исследования показывают, что RAG превосходит fine-tuning по фактической точности, а знания, зашитые в веса, быстро устаревают и приводят к галлюцинациям.

• LoRA и QLoRA в 2026 году покрывают большинство задач; полное дообучение нужно редко.
• QLoRA позволяет дообучать 70B-модель на одном GPU с 48 ГБ VRAM, уменьшая потребление памяти примерно в 4 раза.
• Fine-tuning меняет поведение, а не факты: знания добавляйте через RAG, стиль и формат — через SFT/DPO.
• Оптимальная стартовая точка: LoRA rank 16, все линейные слои, learning rate 2e-4, 1–3 эпохи.
• Unsloth ускоряет QLoRA в 2–5 раз и снижает потребление VRAM примерно на 70% по сравнению с ванильным TRL.

LoRA: низкоранговая адаптация

Low-Rank Adaptation (LoRA), предложенная в 2021 году, изменила правила игры. Вместо обновления всех весов модели LoRA добавляет к каждому линейному слою две маленькие обучаемые матрицы A и B. Обучается лишь 0,1–1% параметров, а остальная часть модели заморожена.

Формула обновления выглядит так:

Ŵ = W + (α / rank) × A × B

Здесь W — замороженные предобученные веса, A и B — адаптерные матрицы, rank задаёт размер скрытого представления, а alpha масштабирует вклад адаптации. Например, LoRA rank 16 на Llama 3.3 70B обучает около 420 миллионов параметров — менее 1% от общего числа — при качестве, близком к полному дообучению.

QLoRA: дообучение на потребительском железе

QLoRA добавляет к LoRA 4-битную квантизацию замороженных весов в формате NF4 (Normal Float 4). Сами адаптеры остаются в FP16/BF16, поэтому точные градиенты не теряются. Эта комбинация, предложенная Dettmers и соавторами в 2023 году, позволяет разместить 70-миллиардную модель на одной RTX 4090 или A6000.

Качество при этом остаётся очень близким к обычному LoRA: разница на большинстве бенчмарков укладывается в доли процента. Для разработчиков в России и СНГ это особенно ценно: не нужен кластер A100, достаточно одной мощной локальной карты или аренды GPU у облачного провайдера.

Сравнение методов: цифры

По данным команд Unsloth, Hugging Face и мета-анализу FinLoRA, разрыв между параметро-эффективными методами и полным дообучением в 2026 году стал минимальным. Вот типичные цифры для Llama 3.3 70B:

• MMLU: QLoRA отстаёт от LoRA менее чем на 0,3%, а оба метода в пределах 1% от полного fine-tuning.
• HumanEval (код): полное дообучение лидирует на 2–3%, но LoRA догоняет, если таргетировать все семь линейных слоёв: q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj.
• GSM8K (математика): при rank ≥ 32 различий между методами практически нет.
• MT-Bench / AlpacaEval: QLoRA и LoRA в пределах 0,5% от полного дообучения.

Практический вывод: для подавляющего большинства задач полное дообучение не стоит 50–100-кратного роста вычислительных затрат. QLoRA на одном GPU даёт продакшен-качество.

SFT, DPO и RFT: три подхода к обучению

Выбрать метод адаптации — только половина дела. Нужно ещё понять, как учить модель. В 2026 году доминируют три парадигмы.

Supervised Fine-Tuning (SFT)

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

Direct Preference Optimization (DPO)

DPO стала рабочей лошадкой 2026 года. Вместо отдельной reward-модели, как в RLHF, она оптимизирует предпочтения напрямую: у нас есть пары «хороший ответ / плохой ответ», и модель учится выбирать лучший. Это дешевле, стабильнее и проще в настройке. DPO выбирайте для тона, alignment и управления отказами.

Reinforcement Fine-Tuning (RFT)

Reinforcement Fine-Tuning от OpenAI доступен для o-серии и других reasoning-моделей. Модель обучается не по эталонным ответам, а по пользовательской функции-оценщику. Это мощно для задач с верифицируемой наградой: генерация кода, математика, структурированная экстракция. Главный барьер — нужно сначала написать хороший grader.

Пошаговый гайд: дообучаем Llama 3.3 с QLoRA

Ниже — минимальный рабочий пример на Python с использованием Unsloth и Hugging Face TRL. Мы дообучим адаптеры для Llama 3.3 8B Instruct на собственном датасете инструкций.

Шаг 1. Установка зависимостей

Шаг 2. Загружаем базовую модель в 4 бита

Шаг 3. Настраиваем LoRA-адаптеры

Шаг 4. Готовим датасет

Шаг 5. Запускаем обучение

Шаг 6. Сохраняем и при необходимости сливаем адаптер

Гиперпараметры: что влияет на результат

Качество дообучения сильно зависит от нескольких ручек. Вот практические рекомендации на 2026 год.

LoRA rank

Начинайте с rank 16 для большинства задач. Rank 8 хватает для простого обучения формату, rank 32–64 дают небольшой прирост на сложной доменной адаптации, но повышают риск переобучения. Очень высокие rank редко окупаются.

Learning rate

Для стандартного SFT с LoRA/QLoRA стартовая точка — 2e-4. Для DPO, GRPO и других reinforcement-методов снижайте до 5e-6. Полное дообучение требует ещё меньших скоростей: 1e-5–5e-6.

Target modules

Всегда таргетируйте все семь линейных слоёв: четыре слоя внимания и три слоя MLP. Исключение модулей даёт минимальную экономию памяти и заметно портит качество.

Эпохи и batch size

Оптимум — 1–3 эпохи. Больше трёх эпох на инструкционных датасетах обычно ведёт к переобучению. Целевой эффективный batch size — 16–32 (batch size × gradient accumulation).

Стек инструментов в 2026 году

Экосистема дообучения выросла и во многом стандартизировалась.

• Hugging Face PEFT + TRL. Де-факто стандарт: SFTTrainer, DPOTrainer, ORPOTrainer. Работает с любой моделью из Hub.
• Unsloth. 2–5× быстрее и на ~70% меньше VRAM для QLoRA. Must-have для одно-GPU сетапов.
• Axolotl. YAML-конфиги для мульти-GPU пайплайнов на кластерах A100/H100.
• Torchtune. Нативная библиотека от PyTorch с компонентным подходом. Легче TRL, но требует больше ручной работы.
• LM Studio / Ollama. Для быстрой локальной проверки дообученной модели.

Типичные ошибки и как их избежать

1. Дообучение без evals. Если вы не можете измерить, стала ли новая контрольная точка лучше предыдущей, у вас не проблема дообучения — у вас проблема оценки. Пишите метрики до тренировки.
2. Катастрофическое забывание. Узкий датасет может «выбить» общие способности модели. Добавляйте 10–20% общих инструкционных данных, используйте низкий learning rate и rank ≤ 32.
3. Переобучение на шум. Если loss стремится к нулю, а eval падает — модель запоминает артефакты. Проверьте датасет на дубликаты и противоречия, добавьте LoRA dropout 0.1.
4. Устаревание знаний. Факты, зашитые в веса, стареют вместе с датасетом. Для изменяющихся данных используйте RAG, а fine-tuning оставьте для стабильного поведения.

Выводы

Fine-tuning LLM в 2026 году стал доступным инструментом: QLoRA + Unsloth превращают дообучение 70-миллиардной модели из инфраструктурного проекта в задачу на один вечер. Но техническая возможность не отменяет стратегии: большинство команд всё ещё получают больше пользы от хорошего промпта и RAG.

Золотое правило остаётся неизменным: дообучение меняет поведение, а не факты. Начинайте с QLoRA, rank 16, всех линейных слоёв, learning rate 2e-4 и 1–3 эпох. Пишите evals до тренировки, смешивайте доменные данные с общими инструкциями и не пытайтесь заменить RAG бесконечным дообучением.

Fine-tuning — это не способ научить модель фактам, а способ научить её манере. Тот, кто понимает разницу, экономит десятки тысяч долларов на вычислениях.

Источник: LLM Fine-Tuning 2026: Complete LoRA, QLoRA & Full Fine-Tuning Guide — TechMag на Dev.to.

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

Так появляется классическая ловушка legacy: систему надо модернизировать, но остановить развитие нельзя. Переписать всё с нуля страшно, поддерживать как есть — всё дороже. В результате продукт обрастает временными решениями, скорость разработки падает, а стоимость каждого следующего изменения растет.

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

Почему Big Bang-переписывание чаще всего заканчивается плохо

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

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

Проблема не в самой идее переписывания, а в условиях, при которых оно проваливается. Большой риск возникает, когда совпадают четыре фактора: переписывание занимает много месяцев, в это время бизнес продолжает развивать старую систему, новая версия покрывает сразу большую часть функциональности, а откат связан с миграцией данных. Если все четыре пункта присутствуют, Big Bang почти гарантированно превратится в долгий и дорогой проект.

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

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

Big Bang всё-таки бывает оправдан — но в узких условиях. Если кодовая база молодая (год-два), пользователей мало, у системы нет критичного состояния в БД и продукт можно временно заморозить или вести в обоих контурах параллельно, полное переписывание может оказаться дешевле постепенной миграции. Это редкая ситуация, и она быстро исчезает по мере роста продукта. В зрелых системах безопаснее работает другой подход — постепенная архитектурная эволюция.

Пример: как команда переписала сервис документов и потеряла полгода

Команда сопровождала сервис — старый модуль на aiohttp с Pydantic v1, через который проходила вся обработка путевых листов и актов осмотра транспорта. Сервис существовал шесть лет, был покрыт тестами фрагментарно, а его API использовали мобильное приложение водителей, диспетчерская веб-панель и пакетный импорт.

Команда решила переписать сервис целиком: перейти на FastAPI, обновить Pydantic до v2, заодно почистить контракты и заменить внутреннее хранилище документов с MongoDB на PostgreSQL. План был рассчитан на четыре месяца.

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

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

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

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

В-четвёртых, переключение было сделано «в лоб»: маршрут в API Gateway просто перенаправили на новый сервис. Фича-флага не было, теневого запуска не было, плана отката не было. Когда выяснилось, что новый сервис строже валидирует исторические форматы документов и отклоняет часть старых записей, быстро вернуться на старую реализацию не получилось — её к тому моменту уже отключили на стенде, а в БД успели уйти записи в новом формате.

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

Strangler Fig Pattern: как заменить систему по частям

Один из самых практичных подходов к модернизации legacy-кода — Strangler Fig Pattern. В софтверном виде паттерн был сформулирован Мартином Фаулером в 2004 году под названием StranglerFigApplication. Идея проста: не переписывать систему целиком, а постепенно выносить отдельные части в новую реализацию.

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

Представим старый монолит интернет-магазина. Внутри него есть каталог, корзина, заказы, платежи, скидки, личный кабинет и уведомления. Переписать всё сразу — рискованно. Но можно начать с относительно изолированного участка, например с уведомлений.

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

Strangler Fig хорошо работает там, где между старым и новым кодом есть сетевая граница: HTTP, message bus, RPC. Если такой границы нет — например, нужно постепенно заменить функцию или класс внутри одного процесса — используется родственный паттерн Branch by Abstraction: над старой реализацией создается абстракция, рядом пишется новая реализация, переключение происходит через конфигурацию или фича-флаг, после стабилизации старая ветка удаляется. Снаружи это выглядит как Strangler Fig, но без сетевого прокси.

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

Главное правило: сначала повторить поведение, потом улучшать

Одна из частых ошибок при модернизации legacy-кода — попытка одновременно переписать систему и улучшить бизнес-логику. Команда смотрит на старый модуль и думает: «Раз уж мы его трогаем, давайте сразу сделаем нормальную архитектуру, изменим контракты, уберем странные кейсы и перепишем поведение».

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

Например, в системе расчета налогов может быть правило: для контрактов, заключенных до 2018 года, НДС округляется в меньшую сторону до целого рубля, а для всех остальных — по математическим правилам. Новый разработчик может решить, что это ошибка, и «исправить» округление. Но потом выяснится, что часть крупных клиентов держит это поведение в своих сверках, а смена правила приведет к расхождениям в актах и претензиям.

Прежде чем менять поведение, его нужно зафиксировать. Для этого пишут характеристические тесты (characterization tests, иногда называемые golden master или approval tests). Идея простая: на реальных данных или их обезличенных копиях прогоняется старая реализация, её ответы сохраняются как эталон, и любые будущие изменения, отклоняющиеся от эталона, отлавливаются автоматически. Тесты пишутся не для красоты, а для того, чтобы зафиксировать существующее поведение — даже странное — перед тем, как его трогать. Подробно эта техника описана у Майкла Физерса в книге Working Effectively with Legacy Code; на практике её удобно реализовать через библиотеки семейства approval-tests (approvaltests-python, approvaltests-java и аналоги).

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

Feature toggles: как включать новую логику без риска

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

В обычной разработке релиз часто выглядит бинарно: код либо выкатили, либо нет. При миграции legacy это неудобно. Гораздо безопаснее иметь возможность включить новую реализацию для 1% пользователей, затем для 10%, потом для половины аудитории и только после этого для всех.

Например, команда переносит расчет стоимости доставки из монолита в новый сервис. С помощью фича-флага это выглядит так:

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

На первом этапе флаг включают только для внутренней команды. Потом для тестового сегмента пользователей. Затем для небольшой доли реального трафика. Если метрики стабильны, долю увеличивают. Если появляются ошибки, флаг выключают, и пользователи снова идут в старую реализацию.

Важно различать два разных типа флагов. Флаг постепенной выкатки (rollout flag) меняется редко и контролирует, какой процент пользователей видит новую логику. Kill switch — отдельный флаг, единственная задача которого — мгновенно выключить новую реализацию при инциденте. Kill switch должен опрашиваться на каждом запросе, его кэширование должно жить секунды, а не минуты, и он принципиально не должен зависеть от той системы, которую он выключает. Иначе в момент аварии может оказаться, что выключатель сам недоступен.

В качестве инфраструктуры для флагов команды обычно берут одну из платформ: LaunchDarkly, Unleash, Flagsmith, GrowthBook, либо собирают собственную поверх Redis или конфигурационного сервиса. Для миграции важны три свойства: быстрое распространение изменений (секунды, а не минуты), поддержка таргетинга по пользователю/сегменту и аудит — кто и когда менял флаг.

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

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

Shadow testing: как проверить новую систему на реальном трафике

Feature toggles помогают безопасно переключать пользователей. Но перед этим хорошо бы понять, совпадает ли новая логика со старой. Для этого используют shadow testing.

Shadow testing — это запуск новой реализации параллельно старой, но без влияния на пользователя. Пользовательский запрос по-прежнему обрабатывает старая система, а новая получает копию запроса и считает результат «в тени». Пользователю этот результат не показывается. Команда только сравнивает ответы.

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

Два момента, на которые стоит обратить внимание в этом коде. Теневой вызов запускается через asyncio.create_task — корутина сразу планируется в event loop и начнёт выполняться, как только функция вернёт управление. И весь блок завернут в try/except: исключение в новой логике не должно ронять основной запрос. Без этих двух свойств shadow testing рискует ухудшить продакшен вместо того, чтобы безопасно его проверить.

Небольшая оговорка для продакшена: event loop держит на task только слабую ссылку, и без сохранённой ссылки задача может быть собрана сборщиком мусора прямо во время выполнения. В реальном коде Task имеет смысл класть в set фоновых задач и удалять оттуда через add_done_callback. В примере выше эта обвязка опущена для читаемости.

Для критичной доменной логики — платежей, биллинга, расчета тарифов — допустимый уровень расхождения должен быть около нуля: цель в shadow-режиме не «как можно меньше различий», а «понимаем каждое расхождение». Для менее чувствительных доменов (рекомендации, ранжирование результатов поиска) можно жить с расхождением в долях процента, но и там расхождения нужно классифицировать, а не игнорировать. Возможно, это баги новой реализации. А возможно, старая система содержит устаревшую логику, которую нужно отдельно обсудить с бизнесом.

Shadow testing особенно полезен для критичных доменных частей: платежей, биллинга, расчета тарифов, персональных предложений, транзакций. Там нельзя просто «попробовать на пользователях» и посмотреть, что будет.

При этом важно отличать теневую проверку чтения от теневой проверки записи. Чтение проверить относительно дёшево: запрос идёт в обе системы, ответы сравниваются, никаких внешних эффектов нет. С записью всё сложнее. Если новая реализация в shadow-режиме действительно создаст заказ, спишет деньги или отправит письмо, у пользователя возникнут двойные эффекты. Поэтому для writes либо вводят идемпотентные ключи и shadow-режим без реальных побочных действий (внешние вызовы заменены no-op-стабами, БД — отдельной shadow-копией), либо вообще отказываются от теневой проверки записи в пользу постепенной выкатки за фича-флагом.

Сравнение ответов в реальной системе тоже не сводится к одной функции compare. Нужно отдельно решать, как игнорировать «нормальный» шум (метки времени, идентификаторы, порядок коллекций), как сэмплировать трафик, чтобы не утопить хранилище расхождений, и как организовать триаж — кто и в каком ритме разбирает накопившиеся диффы. Готовые решения этого класса — GitHub Scientist (Ruby и его порты в другие языки), Twitter Diffy, либо собственный лёгкий регистратор поверх Kafka и таблицы расхождений.

С чего начинать модернизацию

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

Удобный способ выбрать первый кусок — оценить кандидатов по двум осям: насколько модуль критичен для бизнеса (low / high) и насколько сильно он связан с остальной системой (low / high). Начинать стоит с квадранта low-criticality + low-coupling: ошибки в нем не уронят бизнес-показатели, а малое количество зависимостей позволит провести миграцию полностью, не утянув за собой смежные модули. Высоко-критичные и сильно связанные части (платежи, ядро авторизации) трогают в последнюю очередь — на этот момент команда уже наберёт опыт безопасной миграции.

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

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

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

Миграция данных: самая сложная часть

Большая часть статьи говорит о маршрутизации запросов и переключении трафика. Но в реальных проектах основная сложность лежит ниже — в данных. Старая и новая реализации почти всегда работают с общим состоянием: одной БД, одним хранилищем документов, одним набором очередей. Переехать туда «одним коммитом» нельзя.

Базовый рабочий приём — Expand-Contract (он же Parallel Change). Изменение схемы делается в три такта. На этапе expand в БД добавляются новые поля, таблицы или индексы, при этом старое поведение полностью сохраняется. Затем — migrate: обе реализации начинают писать и в старое, и в новое место (dual writes), а отдельный фоновый процесс делает backfill — заполняет новые поля историческими данными. После этого читатели по одному переключаются на новую схему. Только когда никто из читателей не использует старую структуру, наступает contract — удаление лишних колонок и таблиц.

Несколько практических деталей, которые часто упускают:

· Dual writes — это не бесплатная операция. Две записи означают две точки отказа. Если одна из них упала, нужно решать, что делать: продолжать ли работу, ставить ли событие в очередь на повтор, помечать ли запись как несогласованную. Простое «сначала пишем туда, потом сюда» в продакшене на нагрузке приводит к расхождениям.

· Backfill часто длиннее, чем кажется. На большой таблице миграция в одном UPDATE блокирует продакшен. Поэтому backfill делают батчами по N тысяч строк с паузами, отслеживают прогресс и предусматривают возможность остановить и продолжить.

· Онлайн-изменения схемы на крупных таблицах делаются не штатным ALTER TABLE, а специализированными инструментами: gh-ost или pt-online-schema-change для MySQL, встроенные онлайн-механизмы PostgreSQL для индексов и колонок, Liquibase/Flyway — для управления версионированием изменений в репозитории.

· Shadow testing данные не покрывает. Можно сравнить, что новая реализация возвращает то же, что и старая, но если за этим стоит другая схема в БД, проверка корректности самой миграции данных — это отдельная работа: сверки, контрольные суммы, выборочный аудит исторических записей.

Без этих шагов любая красивая фасадная архитектура наталкивается на разъезжающиеся данные — и тогда даже идеальный Strangler Fig снаружи не спасает.

Прокси-слой как точка контроля

Чтобы постепенно заменять legacy-код, нужно управлять маршрутизацией запросов. Для этого часто создают прокси-слой, API Gateway или фасад, через который проходит обращение к старой и новой логике. В терминах Domain-Driven Design такой слой часто называют Anti-Corruption Layer: он защищает новую реализацию от старых контрактов и наоборот, позволяя двум моделям сосуществовать без взаимного «загрязнения».

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

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

В качестве технической основы команды обычно берут один из трех вариантов: классический API gateway (Kong, AWS API Gateway), service mesh (Envoy, Istio) или более простой reverse proxy (NGINX, HAProxy). Service mesh особенно удобен, когда трафик уже идёт внутри Kubernetes-кластера: маршрутизацию можно менять конфигурацией, без правок кода клиентов и сервисов.

Например, мобильное приложение обращается к endpoint /orders/history. Раньше этот endpoint напрямую обслуживал монолит. После введения API Gateway приложение продолжает ходить по тому же контракту, но внутри gateway может решать, куда направить запрос: в legacy-модуль или новый сервис истории заказов.

Управление маршрутизацией обычно делается не «всё или ничего», а на основании атрибутов запроса: значения заголовка (X-Migration-Cohort: new), куки, хэша от user-id (стабильное разбиение пользователей на сегменты) или географического региона. Это позволяет выкатывать новую реализацию сначала на одну страну, на сотрудников самой компании или на тестовый сегмент — и только потом расширять охват.

Для клиента ничего не меняется. Для команды появляется управляемость.

Наблюдаемость: без метрик миграция превращается в гадание

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

Минимальный набор — это логи, метрики и распределенная трассировка (distributed tracing). Нужно понимать, сколько запросов идет в старую и новую реализацию, сколько ошибок возникает, как меняется latency, где появляются таймауты, какие статусы возвращаются, какие бизнес-метрики проседают.

Технические метрики стоит формулировать не как «средний ответ» и «процент ошибок», а в терминах SLI и SLO: целевые показатели вида «99.9% запросов на /orders/history отвечают быстрее 300 ms за 30 дней» с явным error budget. Latency измеряется по перцентилям (p50, p95, p99) — среднее значение почти всегда обманчиво, а хвосты распределения говорят о реальном опыте пользователя. На время миграции имеет смысл выставить отдельные SLO для нового и старого пути и сравнивать их.

В качестве инструментов де-факто стандартом стал OpenTelemetry для трассировок, метрик и логов — единый протокол, который пишет в практически любое хранилище. Дальше — Prometheus и Grafana для метрик, Jaeger или Tempo для traces, Sentry или аналог для ошибок. Для миграции важна возможность фильтровать метрики по «варианту» — отдельно по старому и новому пути — иначе все цифры смешаются и реальную динамику будет не видно.

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

Пример: новая система формально отвечает быстрее старой и не дает ошибок. Но после включения на 10% пользователей падает конверсия в оплату. Причина может быть не в серверной ошибке, а в изменении порядка полей, другом тексте сообщения или потере какого-то edge-case. Без бизнес-метрик команда может решить, что миграция успешна, хотя для продукта она уже создает проблему.

Практическая последовательность миграции

Рабочая последовательность обычно выглядит так.

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

Затем поверх legacy-логики создается стабильный контракт. Это может быть API, фасад, gateway или отдельный слой внутри приложения. Главная задача — сделать так, чтобы клиенты зависели не от внутренней реализации, а от понятного интерфейса. На этом этапе полезно вспомнить про contract testing (Pact, Spring Cloud Contract): автотесты со стороны потребителей фиксируют, что именно они ожидают от API, и предупреждают о ломающих изменениях до того, как они доедут до продакшена.

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

Следующий этап — shadow testing. Новая система получает копии реальных запросов, считает результат, но пользователю по-прежнему возвращается ответ legacy. Команда сравнивает результаты и устраняет расхождения.

Когда новая реализация достаточно стабильна, начинается постепенное переключение через feature toggles. Сначала внутренние пользователи, потом 1% реального трафика, затем 5–10%, затем 50% и только после этого 100%.

На каждом этапе команда смотрит на метрики. Если всё стабильно, движение продолжается. Если появляются проблемы, флаг выключается, трафик возвращается в legacy, а команда разбирает причины.

Последний этап — удаление старого кода. Это не формальность, а обязательная часть миграции. И «удалить старый код» — это не один коммит, а явный Definition of Done: вырезана старая ветка кода, удалён фича-флаг, обновлена документация и схемы архитектуры, переименованы или удалены устаревшие дашборды и алерты, обновлены runbook’и для on-call и проведено короткое внутреннее обучение. Если этого не сделать, через полгода никто уже не вспомнит, какой путь актуален, и легаси-ветвление останется в коде навсегда.

Откат миграций: дешёвый только пока не пошли записи

Откатить миграцию, в которой ещё не было записи в БД, легко: достаточно переключить фича-флаг, и трафик снова идёт через старую реализацию. Откатить миграцию, в которой новая система уже неделю писала данные в новые таблицы, — отдельный, гораздо более тяжёлый разговор.

Поэтому ещё на этапе проектирования каждое изменение должно сопровождаться явным планом отката. Удобно различать три типа шагов.

Полностью обратимые шаги. Чтение через новый сервис, расчёт «в тени», новые метрики. Откат — выключить флаг. Это самый комфортный режим, и в нём стоит держать миграцию как можно дольше.

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

Forward-only. После некоторой точки откат становится невозможен — например, после того, как старая схема удалена или внешние интеграции перенастроены на новый сервис. Такие шаги допустимы, но к ним нужно приходить отдельно, осознанно, с особенно строгими SLO в предыдущем этапе. До forward-only-перехода имеет смысл подержать систему в режиме параллельной работы дольше, чем по графику.

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

Пример: как тот же сервис мигрировали со второй попытки

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

На первом шаге они зафиксировали поведение существующего сервиса. На самые часто используемые сценарии (создание путевого листа, подпись акта осмотра, выгрузка пакета документов за период) написали характеристические тесты на реальных продакшен-данных, обезличенных и сохранённых как фикстуры. Любое будущее изменение поведения теперь падало в CI как явное расхождение.

Параллельно команда провела инвентаризацию побочных эффектов. Из исходного кода и логов выяснилось, что сервис не только хранит документы, но и: публикует событие в Kafka при смене статуса, инкрементирует счётчик в Redis для рейтинга водителей, отправляет webhook во внешнюю систему партнёра, пишет в таблицу аудита. Каждый из этих эффектов попал в отдельный пункт чек-листа «что должно остаться» в новой реализации.

Затем команда выбрала первый кусок для выноса — не весь сервис, а только чтение документов (GET /documents/{id} и GET /documents/by-driver/{driver_id}). Это была наименее рискованная часть: ошибки в чтении неприятны, но не ломают финансовые потоки.

Новый сервис написали на FastAPI рядом со старым. На уровне API Gateway появилось правило маршрутизации: запросы на чтение шли в старый сервис, но в фоне дублировались в новый. Ответ пользователю всегда возвращал legacy, а ответ нового сервиса сравнивался с эталоном и записывался в отдельную таблицу для разбора. Использовали обёртку поверх asyncio.create_task — на ответ пользователя теневой вызов не влиял.

За три недели shadow-режима команда нашла четыре расхождения. Два оказались багами новой реализации (округление времени, неправильная сортировка вложений). Два — давно забытыми особенностями старого сервиса (одно поле возвращалось в UTC, другое — в локальной зоне; так было исторически, бизнес не возражал, но в новой реализации захотели единый формат). Все четыре зафиксировали явно: баги — починили, особенности — согласовали с продуктовой командой как осознанное изменение.

Когда расхождений не осталось, включили фича-флаг на сотрудников самой компании. Через неделю — на 1% реальных водителей. Дальше шаг по 5%, 25%, 50%, 100% с паузой в несколько дней между этапами. На каждом шаге следили не только за HTTP-ошибками и latency, но и за продуктовыми метриками: количество подписанных актов, время от открытия документа до подписи, доля повторных запросов. Один раз пришлось откатиться с 25% на 5% — в одном из регионов выросло время отклика из-за неэффективного запроса. Исправили, выкатили снова.

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

Типичные ошибки при работе с legacy

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

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

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

Четвертая ошибка — не договариваться с бизнесом. Модернизация не должна быть невидимой «инженерной активностью в стол». Её нужно встраивать в roadmap, объяснять эффект и договариваться о приоритетах. Если бизнес не понимает, зачем команда тратит время на миграцию, работа будет постоянно проигрывать новым фичам.

Пятая ошибка — не удалять старый код. Временное сосуществование старой и новой логики нормально. Вечное сосуществование — нет. Если legacy не удаляется, технический долг не уменьшается, а просто меняет форму.

Шестая ошибка — не удалять фича-флаги после миграции. Флаг, который сыграл свою роль и больше никогда не выключается, превращается в постоянное ветвление в коде. Через год команда не помнит, можно ли удалить такую ветку или там сидит важный edge-case. Через два — кода с такими «мёртвыми» флагами становится больше, чем основной логики. Поэтому каждый флаг должен заводиться с условием удаления («после полной выкатки и двух недель стабильной работы») и иметь ответственного, кто этим удалением займётся.

Отдельно стоит упомянуть организационную сторону. Закон Конвея работает и в обратную сторону: если новый и старый код владеются разными командами с разными приоритетами, миграция будет тормозиться независимо от выбранного паттерна. На время миграции имеет смысл явно проговорить, кто отвечает за переход, и не разделять старую и новую реализации между несовместимыми roadmap’ами.

Компромиссы, к которым нужно быть готовыми

Постепенная модернизация безопаснее Big Bang-переписывания, но она не бесплатна. Некоторое время система будет сложнее, чем раньше. В ней появятся старый и новый код, прокси-слой, фича-флаги, дублирование логики, дополнительные метрики.

Shadow testing увеличит нагрузку на инфраструктуру, потому что часть запросов будет обрабатываться дважды. Команде придется поддерживать дисциплину: документировать контракты, отслеживать флаги, удалять старую реализацию после миграции, поддерживать contract-тесты в актуальном состоянии.

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

Когда Strangler Fig особенно оправдан

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

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

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

Когда модернизацию лучше не делать

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

Продукт, который уходит из эксплуатации. Если через год сервис будет выключен или заменён на покупное решение, тратить квартал на его рефакторинг бессмысленно. Достаточно стабилизировать то, что есть.

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

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

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

Что получает команда

Главный результат постепенной модернизации — управляемость. Команда начинает лучше понимать систему, контролировать изменения и снижать риск инцидентов.

Появляются понятные контракты, наблюдаемость, практика безопасных релизов, культура удаления старого кода. Разработчики перестают бояться legacy, потому что у них появляется метод, а не только желание «когда-нибудь всё переписать».

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

Модернизация — это процесс, а не проект

Legacy нельзя «починить за квартал». Если система развивалась годами, она не станет простой после одного рефакторинга. Но её можно системно улучшать.

Strangler Fig Pattern, Branch by Abstraction, feature toggles, shadow testing и аккуратная миграция данных дают рабочую модель: выбрать ограниченный участок, описать контракт, реализовать новую версию, проверить её на реальном трафике, постепенно переключить пользователей и удалить старый код.

Это не самый быстрый путь. Зато он управляемый. А в зрелых продуктах управляемость важнее скорости.

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

Через четыре месяца четырёхагентный пайплайн на LangChain крутился одиннадцать дней и стоил 47 000 долларов. Никто не заметил, пока не пришёл счёт. Тот же паттерн: цикл работал корректно, но у него не было условия выхода.

Проблема не в моделях, а в отсутствии условия остановки. В этой статье разберём, как собрать минимальный, но production-ready каркас агентного цикла: спецификацию до запуска, предохранитель по токенам и ходам, неизменяемый аудит и поверхность для человеческого согласования. Полный код и 80 тестов с 100% покрытием доступны в репозитории автора оригинала.

Агентные циклы сжигают бюджет не из-за плохих моделей, а из-за нечёткого условия остановки.

Спецификация должна отвечать на три вопроса: что делает, что не делает и что значит «готово» — в одном предложении.

Circuit breaker режет цикл по жёстким потолкам: число ходов и суммарные токены. Проверка — до вызова модели, а не после.

Ledger в SQLite фиксирует каждый ход: хеш входа, дельту токенов, время, результат. Это аудит, а не лог для отладки.

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

Что такое агентный цикл и почему он уходит в бесконечность

Агентный цикл — это конструкция вида while True, внутри которой языковая модель получает задачу, вызывает инструменты, анализирует результат и решает, продолжать или закончить. Такие циклы лежат в основе оркестраторов вроде LangGraph, CrewAI и AutoGen, а также внутри coding-агентов. Если только начинаете разбираться с LLM, полезно сначала понять, как устроены большие языковые модели, а для практики — заглянуть в основы Python.

Цикл уходит в бесконечность не потому, что модель «глупая», а потому, что никто не определил, что значит «готово». Модель видит неоднозначность и пытается быть полезной: перефразирует вызов инструмента, запускает верифицирующего агента, тот находит «проблему», срабатывает корректирующий агент — и так далее. На дашбордах всё выглядит активно: растёт число вызовов инструментов, completion rate держится высоким, а бюджет течёт в пустоту.

Почему дорожает каждая итерация:
Агент не начинает с чистого листа. Он каждый раз перечитывает всё предыдущее окно контекста — все неудачные попытки, все промежуточные выводы. Итерация 1 стоит 100 токенов, итерация 10 — уже тысячи. Вы платите за каждый провал снова и снова.

Почему компании сначала платят за чатбота, а потом за агентный рабочий процесс

Gartner фиксирует разрыв в потреблении токенов между пилотными чатботами и production-агентными рабочими процессами в 5–30 раз. А отчёт FinOps Foundation за 2026 год говорит, что 73% компаний превысили изначальный бюджет на ИИ. Цифры взяты из оригинального туториала; полные отчёты Gartner и FinOps Foundation доступны по платным подпискам. Причина разрыва — в неправильном масштабировании: команда планировала стоимость чатбота (~0,04 USD за взаимодействие), а в прод ушёл мультиагентный оркестр (~1,20 USD за взаимодействие, до 70x на сложных задачах).

A loop that runs without an exit condition isn't autonomous. It's a billing event waiting to happen.

Пять примитивов, которые ловят большинство отказов

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

1. Spec writer — заставляет ответить на три вопроса до первого вызова модели.
2. Circuit breaker — режет цикл, если превышены потолки по ходам или токенам.
3. Ledger — ведёт append-only журнал каждого хода в SQLite.
4. Agent loop — связывает три компонента в единый цикл.
5. Review surface — собирает пятиэлементный фрейм и требует человеческой аттестации перед выдачей результата.

Фаза 1. Определить «готово» до первой строчки кода

Самая дорогая ошибка в разработке агентов — не выбор модели, а начало кодинга до того, как команда может одним предложением описать условие завершения. «Агент проверит сайт» — не подходит. «Агент обходит целевой URL, извлекает все теги <title> и <meta name="description">, помечает отсутствующие или слишком длинные и останавливается» — подходит.

Spec writer интерактивно запрашивает три поля, сохраняет их значения в SQLite и возвращает неизменяемый SpecResult(frozen=True). Полученный session_id связывает спецификацию, строки журнала и итоговый результат в одну трассируемую сессию.

Почему frozen=True:
Спецификация — это обязательство, а не черновик. frozen=True запрещает переприсваивать поля объекта SpecResult, поэтому код цикла не может «подвинуть» условие завершения посреди запуска.

Фаза 2. Принудить «готово» на лету

Circuit breaker задаёт два жёстких потолка: turn_limit — максимальное число обращений к модели, и token_limit — суммарное число токенов за всю сессию. Каждый потолок — «строго больше»: если лимит 5 ходов, пятый ещё разрешён, шестой выбросит исключение.

Ключевое правило: breaker.check() вызывается до запроса к модели, а не после. Постфактум проверка бессмысленна: токены уже сожжены. Исключение, а не код возврата, — чтобы нельзя было промолчать.

Как подобрать лимиты для продакшена

Демонстрационные значения 5 ходов / 15 000 токенов слишком жёсткие для реальных задач. Для продакшена автор предлагает настроить лимиты под свой бюджет; в туториале приведён пример breaker = CircuitBreaker(turn_limit=10, token_limit=50000). Если одна сессия должна стоить не дороже 1 USD, а средний ход — 0,10 USD, получается порядка 10 ходов. Конкретный token_limit выбирается исходя из прайсинга модели и среднего размера контекста: чем длиннее история диалога, тем раньше сработает потолок.

• Стартуйте с жёсткими лимитами и разрешайте рост только по метрикам, не по интуиции.
• Отдельно лимитируйте retry-политику: каждый повторный запрос увеличивает и turn_count, и объём контекста.
• Не смешивайте лимит токенов с лимитом выходных токенов модели; circuit breaker считает сумму input + output.

Фаза 3. Записывать всё, что нельзя подделать

Circuit breaker защищает бюджет. Ledger защищает понимание того, что произошло. Это не лог для отладки, а журнал аудита: каждая строка — один ход, append-only, без обновлений и удалений.

Три решения стоит взять на заметку. Во-первых, вместо исходного текста сохраняется SHA-256 хеш входа: так не утекают персональные данные, а одинаковые входы разных запусков можно сравнивать. Во-вторых, pass_fail хранится как INTEGER (1/0), потому что у SQLite нет булева типа. В-третьих, временная метка — datetime.now(timezone.utc).isoformat(), так как datetime.utcnow() объявлен устаревшим в Python 3.12.

Фаза 4. Цикл, который уважает границы

Agent loop — единственный компонент, который обращается к языковой модели. Всё остальное работает локально: проверка потолков, запись в журнал, оценка условия выхода.

Анатомия одного хода простая и строгая: сначала breaker.check(), потом вызов модели, потом ledger.write(), потом проверка stop_reason. Если модель вернула end_turn — возвращаем результат. Если нет — добавляем сообщение continue и идём на следующий круг.

Этот вариант цикла — минимальный текстовый. Если агент использует инструменты, в Anthropic API stop_reason может быть tool_use: тогда нужно выполнить инструмент, вернуть его результат в messages и только потом решать, продолжать или завершать.

Системный промпт обязательно включает все три поля спецификации, а не только done_looks_like. Модели нужна негативная область — то, что агент делать не должен (what_it_does_not), — не меньше, чем позитивная: иначе она начнёт «добавлять ценность» за рамками задачи.

Фаза 5. Поверхность согласования: цикл бежит к человеку

Circuit breaker и ledger решают технические проблемы, но не отвечают на вопрос: «Соответствует ли результат тому, что обещали?» Именно здесь ошибки проходят в прод: вывод выглядит аккуратным, дашборд зелёный, ревьюер ставит галочку.

Review surface собирает пятиэлементный фрейм из SQLite и требует явной аттестации:

1. Исходное обещание — три поля спецификации.
2. Критерий приёмки — поле done_looks_like как явный бенчмарк.
3. Diff — вход первого хода, выход последнего, число ходов, токены, сработал ли breaker.
4. Доказательства — все строки ledger за сессию.
5. Неразрешённые допущения — строки с breach_reason и failed-ходами.

После согласования ревьюер вызывает attest(). Функция собирает пятиэлементный фрейм в каноническом порядке и считает от него SHA-256 — получается frame_hash. Это аудиторская квитанция: она доказывает, что ревьюер видел именно этот фрейм, а не краткое резюме.

Практический пример: SEO-аудит по расписанию

Автор приводит пример SEO-аудита. SEO-аудит имеет естественный ритм: обход, выявление проблем, исправление, ожидание переиндексации. Запускать агента 24/7 бессмысленно — он будет сжигать токены в паузах между событиями. Честная архитектура — cron-задача, которая запускает цикл по расписанию.

Пример упрощён:
В production-варианте стоит проверять URL (допустимые схемы и хосты) и оборачивать requests.get в try/except requests.RequestException, чтобы агент не падал при недоступности сайта.

Cron-строка выглядит так:

Агент выполняет работу, записывает ходы в ledger, и если circuit breaker сработал — результат уходит на человеческую проверку, а не в прод.

Провайдер-независимость через адаптер

Цикл работает с любым клиентом, удовлетворяющим протоколу LLMClient. По умолчанию используется Anthropic, но через адаптер можно подключить OpenAI, Gemini, Ollama, локальные модели или собственный сервер. В репозитории автора показан иллюстративный пример адаптера для OpenAI. Главное — привести ответ к форме, которую ожидает AgentLoop: usage.input_tokens, usage.output_tokens, content[0].text, stop_reason.

Выводы: дисциплина дороже модели

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

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

Define what done looks like before you start. That's the job, and always has been.

Полный код и 80 тестов с 100% покрытием доступны в репозитории автора оригинала: github.com/dannwaneri/production-safe-agent-loop.

Источник: How to Build a Production-Safe Agent Loop — From Exit Conditions to Audit Trails, freeCodeCamp.

LiteLLM — популярный open-source ИИ-шлюз, который выступает единой точкой доступа к свыше ста провайдерам моделей (OpenAI, Anthropic, Google Gemini, AWS Bedrock, Azure и другим). Через него проходят API-ключи, промпты и ответы, поэтому компрометация шлюза равнозначна компрометации всей ИИ-инфраструктуры.

Три CVE объединяются в цепочку: CVE-2026-47101 (обход авторизации), CVE-2026-47102 (повышение привилегий) и CVE-2026-40217 (выполнение кода).

Оценка полной цепочки — CVSS 9,9. Отдельная CVE-2026-47102 получила 8,7 по CVSS 4.0 и 8,8 по CVSS 3.1.

Исправление вошло в релиз LiteLLM v1.83.14-stable, опубликованный 2 мая 2026 года — это первый релиз с полным набором патчей.

Компрометация открывает доступ к мастер-ключу LiteLLM, salt-ключу для расшифровки сохранённых учётных данных, URL базы данных и всем провайдер-ключам, а также позволяет подменять ответы модели.

Это не первый серьёзный инцидент с LiteLLM в 2026 году: в марте злоумышленники скомпрометировали PyPI-релизы проекта, а в апреле критическая SQL-инъекция эксплуатировалась менее чем через сутки после раскрытия. Новая цепочка пока не зафиксирована в реальных атаках, но её потенциальная опасность сопоставима с полным захватом сервера.

Как работает цепочка

Атака строится на том, что разные уровни проверок доверяют данным, которые присылает пользователь. Роль internal_user — это учётная запись с низкими правами по умолчанию, которую часто выдают обычным сотрудникам.

• CVE-2026-47101 — обход авторизации. Обычный internal_user при создании виртуального ключа может указать поле allowed_routes без проверки. Значение ["/*"] даёт доступ ко всем маршрутам, включая административные.
• CVE-2026-47102 — повышение привилегий. Эндпоинт /user/update позволяет пользователю редактировать собственную запись и записать user_role: "proxy_admin". После этого атакующий становится полным администратором.
• CVE-2026-40217 — выполнение кода. Механизм Custom Code Guardrail (он запускает Python-скрипты для проверки запросов) компилирует код администратора через exec() без фильтрации. Если в глобальном пространстве имён (globals) не убран __builtins__, Python автоматически подкладывает встроенные функции — нужно лишь вызвать os.system для обратного шелла.

Чем это опасно

Шлюз сидит между агентом и моделью, поэтому взломанный прокси читает и может изменять всё, что через него проходит. Атакующий получает мастер-ключ LiteLLM, salt-ключ для расшифровки сохранённых учётных данных, URL СУБД и все провайдер-ключи. Кроме утечки данных, он может подменять ответы модели: в демонстрации Obsidian встроенный обратный вызов LiteLLM (callback) подменил ответ Claude Code на поддельный вызов инструмента. Пользователь напечатал одно слово hello, а агент выполнил код, открывший реверс-шелл на машине разработчика.

Что делать

• Обновиться до LiteLLM v1.83.14-stable или новее — это первый релиз с полным набором патчей.
• Перепроверить всех пользователей с ролью proxy_admin: в LiteLLM эта роль может запускать произвольный код через Custom Code Guardrail и MCP, то есть фактически даёт root-доступ на хост.
• Проверить обратные вызовы (callbacks) в litellm_settings.callbacks в config.yaml: они не видны в интерфейсе, но исполняются на каждом запросе.
• Провести аудит Custom Code Guardrail и убедиться в целостности развёрнутого кода, а не только конфигурации.
• При подозрении на компрометацию сменить провайдер-ключи, учётные данные БД и MCP-токены.

Контекст: ранее Tproger уже разбирал supply chain-атаку на LiteLLM, в ходе которой вредоносные версии пакета попали на PyPI.

Если в вашей сети есть LiteLLM — обновление и аудит прав стоит провести до конца недели. Подробнее — в первоисточнике.

Чтобы начать, установите Matplotlib через pip. После этого достаточно импортировать pyplot под стандартным псевдонимом plt, подготовить два массива данных и вызвать plt.scatter(). В обычном скрипте график нужно явно показать через plt.show(), а в Jupyter Notebook или интерактивной консоли это необязательно.

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

plt.scatter() против plt.plot()

Тот же базовый график можно построить функцией plt.plot(), передав маркер "o". Однако замеры через timeit обычно показывают, что plt.plot() работает в несколько раз быстрее. Зачем тогда нужен scatter()? Дело в гибкости: только plt.scatter() позволяет задавать индивидуальный размер, цвет и прозрачность для каждой точки.

Правило простое: для сырых точек без изысков выбирайте plt.plot(), а если нужно раскодировать дополнительные переменные визуально, используйте plt.scatter().

Кастомизация маркеров

Размер точек: параметр s

Допустим, владелец кофейни хочет добавить на график информацию о марже каждого напитка. Параметр s отвечает за площадь маркера. Чтобы разница была заметна, удобно передать массив значений и отмасштабировать его, например, умножив на 10.

Цвет: параметр c

Цвет помогает выделить категории. Можно задать его вручную через RGB-кортежи: зелёный для низкого содержания сахара, жёлтый для среднего и красный для высокого. Параметр c принимает список цветов той же длины, что и данные.

Форма: параметр marker

Когда на одном полотне оказываются два разных набора, важно различать их на глаз. По умолчанию точки рисуются кругами "o", но для второго набора можно выбрать другой символ, например, ромб "d".

Прозрачность: параметр alpha

Если точки накладываются друг на друга, часть данных становится невидимой. Параметр alpha задаёт прозрачность от 0 до 1. Значение 0.5 делает маркеры полупрозрачными, и совпадающие наблюдения перестают прятаться.

Непрерывный цвет и стили

Вместо фиксированных RGB-цветов можно передать в c числовой массив и выбрать цветовую карту через cmap. Это превращает маркеры в градиент, а plt.colorbar() добавит шкалу значений. Кроме того, оформление можно поменять глобально: plt.style.use("seaborn-v0_8") применит стилистику, близкую к Seaborn.

Список доступных стилей возвращает команда plt.style.available. Экспериментируйте с ними, чтобы быстро привести график к единому виду без ручной настройки каждой детали.

Продвинутая техника: маскирование данных

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

Шпаргалка по параметрам

• x, y — координаты точек (обязательные аргументы).
• s — размер маркера: одно число или массив значений для каждой точки.
• c — цвет в формате RGB, название или массив чисел для цветовой карты.
• marker — форма точки: 'o' (круг), 'd' (ромб), 'x' (крест) и другие.
• cmap — название цветовой карты, применяется вместе с числовым c.
• alpha — прозрачность от 0 (полностью прозрачный) до 1 (непрозрачный).

Выводы

Функция plt.scatter() превращает плоскую диаграмму рассеяния в многослойный инструмент анализа. На одном полотне можно одновременно показать цену, объём продаж, прибыльность, категорию товара и его характеристики через размер, цвет и форму маркеров. Для простых задач по-прежнему удобен plt.plot(), но стоит ли задача исследовать сложные взаимосвязи, scatter() становится незаменим.

Исправления корутин и C-расширений

Обновление устраняет избыточное предупреждение о неиспользуемых корутинах: интерпретатор теперь корректно отслеживает жизненный цикл асинхронных объектов и не выдаёт ложных предупреждений при штатной работе с asyncio. Кроме того, разработчики починили множественное наследование в C-расширениях — ранее комбинация нескольких базовых типов из cpyext могла приводить к некорректному порядку разрешения методов (MRO) и падениям при инициализации объектов. Эти исправления повышают стабильность при работе с асинхронным кодом и нативными библиотеками.

Изменения в байт-коде

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

Версии и совместимость

Сборка PyPy3.11 поддерживает стандартную библиотеку CPython 3.11.15, а PyPy2.7 ориентирована на Python 2.7.18+ с бэкпортами исправлений безопасности. Разработчики подтвердили совместимость API с предыдущими выпусками линейки 7.3 и рекомендуют установить патч.

Ссылки

Подробности обновления — в официальном анонсе PyPy 7.3.23.

20 мая 2026 года GitHub официально признал взлом: злоумышленники скомпрометировали устройство сотрудника через вредоносную версию расширения для Visual Studio Code. Ответственность взяла группировка TeamPCP, предлагающая похищенный код на форумах за $50 000.

• GitHub подтвердил несанкционированный доступ к ~3 800 внутренних репозиториев 20 мая 2026 года
• Вектор атаки — отравлённая версия расширения VS Code (предположительно Nx Console v18.95.0), доступная в маркетплейсе ~11 минут
• Ответственность взяла группировка TeamPCP (UNC6780), данные выставлены на продажу за $50 000
• Данные клиентов GitHub не пострадали — взлом затронул только внутренние репозитории
• GitHub ротировал критические ключи, изолировал устройство и удалил вредоносное расширение

Как работала атака

Схема взлома — многоступенчатая. Хакеры загрузили отравлённую версию популярного расширения в маркетплейс VS Code, которым управляет материнская компания GitHub — Microsoft. Когда сотрудник установил заражённую версию, вредонос получил доступ к устройству.

Дальше началась классическая цепочка бокового перемещения: компрометация устройства → извлечение секретов из репозитория, к которому был доступ у пользователя → доступ к внутренней инфраструктуре GitHub. Каждый шаг становился плацдармом для следующего.

Наиболее вероятным кандидатом исследователи называют троянизированную версию Nx Console (nrwl.angular-console) v18.95.0, опубликованную 19 мая 2026 года и провисевшую в маркетплейсе около 11 минут до удаления.

Проблема маркетплейса VS Code в этом контексте очевидна: разработчик, устанавливающий расширение от внешне легитимного издателя, фактически не имеет способа обнаружить инъекцию вредоноса без активного сканирования секретов или поведенческого мониторинга на уровне эндпоинта.

Что похитили и что продают

По заявлению TeamPCP на форуме Breached, группа получила доступ к «исходному коду GitHub и внутренним организациям». В объявлении о продаже указано: «Здесь около ~4 000 репозиториев приватного кода, я с удовольствием отправлю образцы заинтересованным покупателям».

GitHub подтвердил, что заявленный злоумышленниками масштаб «~3 800 репозиториев в целом согласуется» с данными внутреннего расследования — редкий случай, когда жертва сама верифицирует объём утечки. Это существенно повышает достоверность инцидента.

Что примечательно: TeamPCP не вымогает выкуп. Группа ищет единственного покупателя, после чего обещает уничтожить данные на своей стороне. Однако если покупатель не найдётся — группа угрожает опубликовать данные бесплатно. Дедлайна нет, но угроза утечки есть.

Масштаб последствий

GitHub — крупнейшая в мире платформа разработки: более 4 миллионов организаций (в том числе 90% компаний из Fortune 100), 180 миллионов разработчиков, 420 миллионов репозиториев. Внутренний исходный код платформы содержит архитектурные решения, реализации систем безопасности и дизайн внутренних API — то, к чему никто за пределами GitHub не должен был иметь доступа.

Данные клиентских репозиториев, корпоративных аккаунтов и организаций не пострадали. GitHub подтвердил отсутствие свидетельств утечки за пределы внутренних репозиториев компании.

Кто такие TeamPCP / UNC6780

TeamPCP, отслеживаемая Google Threat Intelligence Group как UNC6780, — финансово мотивированная группировка, специализирующаяся на атаках на цепочки поставок в экосистеме разработки. В 2026 году она успела скомпрометировать несколько крупных инструментов:

• Trivy — популярный сканер уязвимостей (CVE-2026-33634): затронуто более 1 000 организаций, включая Cisco
• KICS (от Checkmarx) и LiteLLM — целевой сбор учётных данных из CI/CD-пайплайнов
• durabletask — официальный Python-клиент Microsoft для Durable Task: три вредоносные версии (1.4.1–1.4.3)
• TanStack, MistralAI, Telnyx SDK — серия атак на open-source зависимости через отравленные pull request

Инструмент группы — само-реплицирующийся вредонос Mini Shai-Hulud, автоматизирующий атаки на цепочки поставок через кражу CI/CD-учётных данных. Он распространяется через компрометированные PyPI-пакеты и вредоносные pull request в популярные GitHub-репозитории.

Как GitHub ответил на взлом

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

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

Выводы

Платформа GitHub используется более чем 4 миллионами организаций, включая 90% компаний Fortune 100. Взлом внутреннего исходного кода GitHub несёт последствия, выходящие далеко за рамки самого инцидента: в руках злоумышленника оказываются архитектурные решения и реализации систем безопасности платформы.

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

Если вы или ваша команда используете VS Code на корпоративных устройствах: проверьте список установленных расширений, убедитесь, что secret scanning активен, и следите за официальными обновлениями от GitHub. Источник: Secure Blink, Help Net Security, HackRead.

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

Расскажу, как мне пришла идея этого проекта. Изначально всё началось с того, что я заметил, как на многих сайтах (например, на том же SourceForge) крутые программы с открытым исходным кодом начали просто без причины удаляться. Мне захотелось создать собственный «мир программ», где можно найти абсолютно всё и ничего не будет удалено. Исключение — вредоносный софт: если в приложении обнаружатся вирусы, скрытые трояны или рекламные бандлы, я сразу отправляю его в бан. Во всех остальных случаях программа будет жить. Не знаю, зайдет вам или нет. Но надеюсь на лучшее :)

Это одна из крупнейших координированных атак на реестры пакетов в 2026 году, и первая, которая в одной кампании задела сразу и npm, и PyPI. StepSecurity и Socket трекают её как «mini-shai-hulud». Разбираемся, что произошло, кто пострадал и что делать.

• 404 вредоносные версии в 170+ npm-пакетах и 2 PyPI-пакетах, опубликованы в течение пятичасового окна 11 мая.
• Под удар попали: @tanstack (42 пакета роутера для React, Vue, Solid), @mistralai (3 SDK), @uipath (65 пакетов автоматизации), @opensearch-project/opensearch (1,3 млн загрузок в неделю), Guardrails AI.
• Два механизма триггера в npm: preinstall-хук (@mistralai) и optionalDependency с prepare-скриптом (@tanstack). На PyPI — инжекция в __init__.py, срабатывает при импорте, а не при установке.
• Payload крадёт GitHub-токены, npm-токены, AWS IAM-credentials и HashiCorp Vault-credentials. Эксфильтрация — через onion-routed мессенджер Session, поэтому C2-домен заблокировать нельзя.
• Самораспространение: payload использует украденный GitHub-токен, чтобы закоммитить .claude/settings.json и .vscode/tasks.json в feature-ветки чужих репозиториев через GraphQL-мутацию createCommitOnBranch.
• Безопасные версии: mistralai ≤ 2.4.5, guardrails-ai ≤ 0.10.0. По npm — пиньте версии и регенерируйте lockfile.

Что произошло

В ночь с 11 на 12 мая 2026 года автоматическая система детекта SafeDep засекла массовый burst странных публикаций на npm. Атакующий действовал не точечно, как в случае с axios в марте 2026, а целыми scope-ами: внутри одного scope падали сразу все пакеты. К утру стали известны границы кампании — 170 npm-пакетов, 404 вредоносные версии, плюс 2 PyPI-пакета.

Кого затронуло

• TanStack (42 пакета, 84 версии): целый экосистем роутера — @tanstack/react-router, @tanstack/vue-router, @tanstack/solid-router, их devtools, SSR-плагины и build-инструменты. У @tanstack/react-router — 3 миллиона загрузок в неделю.
• Mistral AI (3 пакета, 9 версий): core SDK @mistralai/mistralai и его обёртки под Azure и GCP. По три вредоносные версии на каждый.
• UiPath (65 пакетов, 65 версий): весь scope @uipath — SDK агентов, оркестратор, инструменты RPA, пакеты для интеграции.
• OpenSearch (@opensearch-project/opensearch): официальный JavaScript-клиент, 4 затронутые версии — 3.5.3, 3.6.2, 3.7.0, 3.8.0. 1,3 миллиона загрузок в неделю.
• Guardrails AI (guardrails-ai==0.10.1 на PyPI): фреймворк validation guardrails для Python.
• Mistral AI на PyPI (mistralai==2.4.6): официальный SDK; легитимного релиза 2.4.6 не существовало, последняя версия — 2.4.5 от 7 мая.

Как работает атака

На npm — два механизма триггера

Для Mistral AI атакующий заменил блок scripts в package.json на preinstall-хук. Этот хук скачивает Bun runtime и запускает payload setup.mjs, который, в свою очередь, запускает основной обфусцированный бинарь router_init.js.

Для TanStack атакующий пошёл хитрее. В легитимный package.json добавлен optionalDependency, указывающий на вредоносный коммит в реальном репозитории tanstack/router на GitHub (коммит #79ac49eedf774dd4b0cfa308722bc463cfe5885c). В этом коммите лежит prepare-скрипт, который снова тянет Bun и запускает тот же payload.

Преимущество атакующего: коммит в публичном репозитории, который ссылается из optionalDependency, не вызывает алертов автоматических сканеров — внешне это легитимная зависимость.

На PyPI — инжекция в __init__.py

PyPI устроен иначе: sandboxed install через pip download и pip wheel не выполняет код пакета. Поэтому атакующий не стал прятать payload в install-хуке. Вместо этого в __init__.py добавили 15 строк, срабатывающих при первом import:

Никакой обфускации: URL, путь и команда выполнения — открытым текстом. Проверка sys.platform запускает dropper только на Linux. macOS- и Windows-сборки несут трояны, но dropper там не сработает. Cloudflare помечает домен git-tanstack.com как phishing-сайт.

Что крадёт payload

Внутри обфусцированного router_init.js — модульный credential stealer с дедикейтными провайдерами под разные источники секретов:

• GitHub PAT, OAuth и App-installation токены: паттерны ghp_*, gho_*, ghs_*.
• GitHub Actions OIDC JWT — формата ghs_NNN_xxx.yyy.zzz.
• npm publish tokens (npm_*).
• AWS IAM credentials через зондирование metadata-эндпоинта 169.254.169.254/latest/meta-data/iam/security-credentials/.
• HashiCorp Vault — пробу на localhost:8200.

Сканер регулярок прогоняется по содержимому переменных окружения, файлам конфигурации и истории shell. Цель — максимизировать lateral movement из CI/CD-окружений и dev-машин в публичное облако.

Самораспространение через Claude Code и VS Code

Самая интересная и пугающая часть payload — self-replication механизм. Имея украденный GitHub-токен, payload использует GraphQL-мутацию createCommitOnBranch, чтобы закоммитить вредоносные файлы в репозитории жертвы:

• .claude/settings.json и .claude/setup.mjs — конфиг для Claude Code, запускающий payload при открытии проекта.
• .vscode/tasks.json и .vscode/setup.mjs — то же самое для VS Code.
• .claude/router_runtime.js — полная копия 2,2-мегабайтного payload, чтобы следующая стадия не зависела от внешнего хоста.

Цели коммитов выбираются хитро: payload запрашивает до 50 веток через GraphQL и отфильтровывает main, master, develop и release (типичный набор). Коммиты идут в feature- и topic-ветки, где меньше шансов нарваться на ревью. В коммит-сообщении добавляется случайный Co-authored-by, чтобы выглядеть «коллективно».

Итог цепочки: любой разработчик, который git pull заражённую ветку и откроет проект в VS Code или Claude Code, запустит payload без явного действия. Затем его токены крадутся — и цикл повторяется.

Эксфильтрация через Session — почему домен не закрыть

Атакующий не использовал классический C2-домен. Вместо этого payload содержит полную реализацию клиента Session — onion-routed мессенджера на сети Oxen. Payload связывается с pre-pinned seed-нодами (seed1.getsession.org, seed2.getsession.org, seed3.getsession.org), получает список snode-ов и отправляет украденные креды через peer-to-peer-сеть.

Для больших данных payload использует filev2.getsession.org/file/ — централизованный файловый сервер Session. Это единственная фиксированная точка инфраструктуры; всё остальное — динамическое peer-to-peer-разрешение через swarm. Защитники не могут отозвать swarm так, как отзывают домен.

Шифрование на ed25519 и x25519, перебор snode-адресов в рантайме — блокировка C2 на уровне DNS или firewall здесь не работает.

Что делать прямо сейчас

Для npm-проектов

Проверьте lockfile на наличие вредоносных версий по затронутым scope-ам:

Если что-то найдено — запиньте пакеты на известные безопасные версии и перегенерируйте lockfile. После этого ротейтьте все секреты, к которым имела доступ ваша dev-машина или CI: GitHub PAT, npm-токены, AWS-ключи, Vault-токены.

Для Python-проектов

Проверьте установленные версии:

Если у вас mistralai==2.4.6 или guardrails-ai==0.10.1 — окружение скомпрометировано. Безопасные версии: mistralai ≤ 2.4.5 и guardrails-ai ≤ 0.10.0.

Дополнительная гигиена

• Проверьте feature- и topic-ветки своих репозиториев на свежие коммиты с подложенными файлами в .claude/ и .vscode/ — особенно если у вас под рукой Claude Code или VS Code с активным GitHub-токеном.
• Запретите автоматический запуск preinstall- и postinstall-скриптов через флаг --ignore-scripts.
• Просканируйте репозитории на наличие .claude/router_runtime.js — это копия payload, размер около 2,2 МБ.

Indicators of Compromise (IoC)

FAQ

Выводы

Эта атака подсветила два архитектурных риска, которые мы коллективно проигнорировали. Первый — preinstall/postinstall-скрипты в npm по дефолту запускаются от лица пользователя; одно зависимое дерево из 100 пакетов даёт атакующему 100 шансов запуститься на dev-машине. Второй — IDE-конфиги в репозиториях. Удобство «открыл проект и сразу работает» оборачивается атакующим прямо тем же удобством: пушнул .claude/setup.mjs в feature-ветку — и payload запускается у каждого, кто склонирует ветку.

Защита здесь — это --ignore-scripts в npm, изолированные среды для install (контейнеры, devcontainers), review-обязательность для всех веток, отслеживание незапланированных .claude/- и .vscode/-файлов в pull-requests.

Полный технический разбор с дизассемблированным payload, swarm-логикой и appendix-ом со всеми пакетами — в посте SafeDep.

Flatten — операция приведения вложенной структуры к одномерной. Самый распространённый кейс: матрица представлена как список списков, а вам нужен плоский список всех значений, чтобы передать в алгоритм или ML-модель. В отличие от других языков, в Python нет встроенного .flatten() у списков — поэтому стандартное «как это сделать?» имеет несколько ответов разной степени читаемости и эффективности.

Пусть у нас есть матрица 4×4:

Цель — получить:

• Быстрее всего работает обычный цикл с in-place мутацией: += или .extend(). Время — около 5–7 мс.
• itertools.chain() — около 16 мс, но в 3 раза экономнее по памяти; подходит, когда финальный список не нужен полностью.
• List comprehension — около 24 мс. Читаемо и без побочных эффектов, но создаёт промежуточные объекты.
• functools.reduce() + lambda и sum() — от 2,6 секунд. Это в 400–500 раз медленнее за счёт постоянного создания новых промежуточных списков.
• Для произвольной вложенности — рекурсия или итеративный обход со стеком.
• В data-science для NumPy-массивов используйте np.ndarray.flatten() — он быстрее любого варианта на чистых списках.

Способ 1. Цикл for + .extend()

Самый прямолинейный и читаемый вариант: проходим по каждой подсписку и добавляем её элементы к итоговому списку через .extend().

.extend() принимает любой iterable и поэлементно добавляет его в конец списка. Альтернативно можно использовать augmented-concatenation +=:

Обе функции делают одно и то же. Real Python отмечает: flatten_extend читается чуть лучше, потому что метод named — намекает на смысл операции. По скорости варианты идут в первой тройке.

Способ 2. List comprehension

Pythonic-альтернатива однострочнику. Двойной for внутри comprehension перебирает сначала строки, потом элементы строк:

Подход компактнее цикла и не плодит промежуточных переменных. Скорость — заметно медленнее .extend() из-за двух вложенных циклов на уровне comprehension, но всё ещё в диапазоне десятков миллисекунд.

Способ 3. itertools.chain() — экономно по памяти

chain() возвращает итератор, а не список. Это значит, что вы можете обходить элементы потокового, не материализуя весь массив в памяти — полезно, когда матрица большая и хранить полный flat-список нерационально.

На большой матрице chain.from_iterable примерно в три раза медленнее цикла .extend(): накладные расходы на материализацию через list(). Но если итоговый список как таковой не нужен — можно отдать сам итератор потребителю и сэкономить и время, и память.

Способ 4. functools.reduce() и sum() — почему так медленно

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

iconcat мутирует аккумулятор и держится в топ-3 по скорости. А вот вариант с lambda и оператором + на каждом шаге копирует обе стороны — отсюда и взрывной рост времени на больших данных.

С sum() ситуация ровно такая же:

sum() работает на любых сложениях, но для списков это О(n²) по аллокациям. На матрице 1000×1000 он в ~500 раз медленнее цикла с .extend().

Способ 5. Произвольная вложенность — рекурсия и стек

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

Рекурсия удобна, пока глубина не упирается в sys.getrecursionlimit() (по умолчанию 1000). Для очень глубоких структур стоит переписать через итеративный обход со стеком:

Способ 6. NumPy для data-science

Если вы работаете с матрицами в data-science, у numpy.ndarray есть готовый метод .flatten(). Он быстрее любого варианта на чистых Python-списках, потому что под капотом работает с непрерывным блоком памяти.

Замер производительности

Real Python прогнали все варианты на матрице 1000×1000 через timeit. Результаты, отсортированные по времени:

Между первыми тремя и последними четырьмя — пропасть в 400–500 раз. Причина: топовые функции мутируют существующий список, а reduce(+), reduce(operator.add), reduce(lambda x, y: x + y) и sum() на каждой итерации создают копии.

FAQ

Выводы

Если вам нужен один-в-один поведенческий рецепт: for row in matrix: flat.extend(row). Этот код понятен любому, кто знает Python, и упирается в производительность только когда матрица переваливает за миллионы элементов. Если объёмы такие, что нужна потоковая обработка — переключитесь на itertools.chain. Если данные numerical — используйте NumPy.

Главное, чего стоит избегать — sum(matrix, []) и reduce с + или lambda. Они смотрятся изящно в туториалах, но превращают O(n) в O(n²) и ставят вас в первую же боттлнек-историю на проде.

Оригинальный туториал с пошаговыми объяснениями и сравнением — на Real Python, автор — Leodanis Pozo Ramos.

Однако недавно проект получил второе дыхание. Разработчик Александр Тишов (Amro) — создатель CMS Seditio и основатель веб-студии «Авего» — выпустил Denwer SE (Second Edition). Это не просто обновление, а полный реинжиниринг с сохранением классической философии: портативность, скорость работы и привычная структура каталогов.

В этой статье разберём, что изменилось под капотом, почему панель управления переехала с Perl на Python, как работает автоматический HTTPS с собственным корневым сертификатом и зачем нужен зоопарк версий PHP от 5.6 до 8.5.

Краткий экскурс: от Denwer 3 до Denwer SE

Оригинальный Denwer (сокращение от Джентельменский Набор Веб-разработчика) появился в начале 2000-х. Он представлял собой связку Apache + PHP + MySQL, упакованную в самораспаковывающийся архив. Главные фишки:

• Виртуальный диск (по умолчанию Z:), который монтировался через subst.
• Автоматическое создание виртуальных хостов по именам папок в home.
• Консольные exe-файлы (Run, Stop, Restart) без графического окна.

Проблемы оригинала:

• Управление на Perl — медленно, тяжело поддерживать в Windows.
• Только 32-битные компоненты.
• Невозможно быстро переключать версии PHP или БД.
• Отсутствие нормального HTTPS (только самоподписанные сертификаты с ошибками в браузере).
• Поддержка прекратилась в 2016 году.

Denwer SE решает все эти проблемы, оставаясь при этом таким же портативным — достаточно скопировать папку на флешку или в облачный каталог.

Архитектура: Python вместо Perl

Denwer SE — панель управления написана на Python и скомпилирована в один EXE-файл (через PyInstaller).

Внутри служебной папки denwer\ лежат:

• DLL-версия Python — интерпретатор, который использует основной исполняемый файл.
• Скомпилированные модули .pyd — в том числе GUI на базе Tcl/Tk для оконного интерфейса и системного трея.
• Минимальный набор библиотек для управления службами, правки hosts и генерации сертификатов.

Это даёт несколько преимуществ:

• Портативность — панель ищет соседние папки home и usr, поэтому каталог со стеком можно переносить куда угодно без переустановки.
• Скорость — Python-скрипты запускаются быстрее, чем Perl, особенно на холодном старте.
• Читаемость кода — разработчику проще поддерживать и расширять функционал.

Полный переход на x64

Оригинальный Denwer навсегда остался 32-битным, что в современных реалиях просто неприемлемо. Denwer SE собирается исключительно под x64:

• Apache (версия 2.4.x) — 64-битный.
• Все модули PHP (от 5.6 до 8.5) — Thread Safe x64.
• MySQL / MariaDB — 64-битные сборки.

Системные требования — Windows 7/8/10/11 (x64). Для работы компонентов потребуются Microsoft Visual C++ Redistributable (VC11, VC12, VC14, VC15). Разработчик положил установщики этих пакетов в папку vcredist\ — при необходимости можно доустановить вручную.

Структура каталогов: преемственность и гибкость

Denwer SE сохранил классическую структуру, чтобы старые пользователи не ломали голову:

Главный конфиг — usr\configuration.txt. В нём задаются пути без жёсткой привязки к букве диска, например:

При старте панель монтирует виртуальный диск (по умолчанию Z:) и динамически подставляет путь через переменную subst_drive.

Управление версиями PHP и БД без танцев с бубном

В Denwer SE встроен менеджер версий. Вы просто выбираете из выпадающего списка нужную версию PHP (например, 8.3 или 5.6) — панель сама правит конфигурацию Apache.

Как это работает под капотом:

В папке usr/local/apache/php лежат подкаталоги php5.6, php7.4, php8.3 и т.д..

В каждом из них есть файл php-denwer.conf— шаблон для подключения модуля к Apache. При выборе версии этот файл копируется в conf/extra/httpd-denwer.conf, который затем включается в основной httpd.conf.

Если вы хотите добавить свою сборку PHP (например, PHP 8.4-rc), достаточно:

• Распаковать x64 Thread Safe версию в отдельный каталог внутри php\.
• Создать php-denwer.conf по образцу.
• Убедиться, что все DLL от VC++ установлены.

Аналогично для баз данных: переключение между MySQL 5.7 и MariaDB 11.8 происходит через тот же интерфейс. В каталоге СУБД может лежать файл db-denwer.conf, который при старте копируется в my.ini.

HTTPS, который не бесит: локальный Root CA

Самое болезненное место при локальной разработке это самоподписанные сертификаты. Браузеры постоянно ругаются, приходится кликать «Принять риск». Для командной разработки это вообще катастрофа: каждый участник должен сгенерировать свой сертификат и добавить в исключения.

Denwer SE решает проблему элегантно — он создаёт собственный корневой центр сертификации (CA) и подписывает им сертификаты для всех ваших локальных доменов.

Как это работает:

1. При первом запуске (если найден OpenSSL) панель генерирует ключи denwer-ca.key и сертификат denwer-ca.crt в папку usr/local/apache/conf/cert/denwer-ca/.
2. Для каждого виртуального хоста (папки в home/) автоматически создаётся сертификат в conf/cert/<domain>/.
3. Все сертификаты хостов подписаны локальным CA.

Чтобы браузер доверял им, нужно один раз установить denwer-ca.crt в хранилище «Доверенные корневые центры сертификации» Windows. Для этого в панели есть специальная кнопка (требует прав администратора).

После этого любые HTTPS-запросы к локальным хостам работают без единого предупреждения.

Удобства для разработчика (DX)

В версии 1.2.4 добавили несколько фич, которые экономят время каждый день:

• Лог с таймштампами — каждая строка в окне панели имеет префикс [чч:мм:сс]. Теперь видно, сколько секунд сервер поднимается и где возможны задержки.
• Прямой доступ к php.ini и my.cnf — рядом со списками версий появились кнопки, открывающие конфигурацию именно активной версии.
• Автоматическое ведение hosts — панель в реальном времени сканирует home/, находит новые домены и прописывает их в C:\Windows\System32\drivers\etc\hosts. Журнал добавляемых записей сохраняется в usr\AddedHosts.txt. При остановке стека лишние строки удаляются.
• Для смены версии PHP или базы данных панель требует полной остановки всех служб. Вы нажимаете «Стоп», меняете версию в списке, затем «Старт» — и стек поднимается уже с новыми настройками. Автоматический перезапуск без вашего участия работает только для Apache: когда вы добавляете новый домен в папку home/, панель сама переписывает vhosts.conf и перезапускает веб-сервер, не трогая БД.

Почему не Open Server или Docker?

Этот вопрос закономерно возникает у всех, кто видит очередной локальный веб-сервер. Ведь есть уже давно Open Server Panel, Laragon, XAMPP, а для продвинутых — Docker. Зачем ещё один?

Open Server — мощный и удобный комбайн с десятками версий PHP и настройками «на века». Но он разворачивается в системе не портативно: создаёт папки в ProgramData, пишет в реестр, а запуск может занимать 5–10 секунд. Denwer SE, напротив, полностью переносим: скопировал папку на флешку или в облачный каталог — и всё работает. Запуск стека — буквально 1–2 секунды, что критично, когда вы десятки раз за день перезапускаете сервер для тестов.

Docker — индустриальный стандарт для изоляции и воспроизводимости окружений. Но для локальной разработки простого сайта он часто избыточен. Вам нужно разобраться в образах, контейнерах, пробросе портов, volume’ах и docker-compose.yml. А в Denwer SE вы просто создали папку в home/ — и готово. Никакой работы с командной строкой, никакого потребления гигабайт ОЗУ на фоновую службу Docker Desktop.

Laragon — быстрый, портативный, поддерживает не только PHP, но и Node.js, Python, Go. Но он ориентирован на современные фреймворки, особенно Laravel. Denwer SE же сделан для тех, кто вырос на классическом Денвере: виртуальный диск Z:, папка home/имя_домена/www, минимум настроек. Не нужно переучиваться — просто распаковал и работаешь как 10 лет назад, но с новыми версиями PHP и HTTPS.

Как начать пользоваться Denwer SE

1. Скачать архив с официального сайта автора.
2. Распаковать в любое место, например C:\web\DenwerSE\.
3. Запустить DenwerSE.exe — если нет прав администратора, попросит их для монтирования диска и правки hosts.
4. Нажать «Запустить» — появится виртуальный диск Z:, а в системном трее иконка.
5. Создать папку сайта — например, home\myproject.local и положить туда index.php.
6. Открыть в браузере http://myproject.local/ (или https://myproject.local/). HTTPS будет работать сразу после установки корневого сертификата (кнопка в панели).

По умолчанию пароль к MySQL/MariaDB — пустая строка (пользователь root). При желании его можно сменить через phpMyAdmin.

Заключение

Denwer SE — это не просто ностальгический проект. Это действительно современный инструмент, который доказывает, что концепция «локального сервера в одну папку» всё ещё актуальна. Отказ от Perl в пользу Python, менеджер версий PHP/БД, нормальный HTTPS, портативность и мгновенный запуск — всё это делает его отличным выбором для быстрого прототипирования, тестирования легаси-кода или обучения веб-разработке.

Если вы устали ждать, пока Open Server применит настройки, или не хотите разбираться в Docker Compose — попробуйте Denwer SE. Вероятно, он напомнит вам старые добрые времена, но уже без боли устаревших технологий.

• Автор проекта: Александр Тишов (Amro), разработчик CMS Seditio.
• Лицензия: Freeware.
• Совместимость: Windows 7/8/10/11 x64.

Исходники панели управления не открыты (распространяется скомпилированный EXE), но архитектура и конфиги полностью прозрачны. В планах — добавить поддержку Nginx в качестве альтернативы. Следите за обновлениями.

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

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

ИТ-аутстаффинг и штат: в чем разница

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

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

Отличия двух моделей — в таблице:

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

А как вообще контролировать человека, которого не нанимал? Да ровно так же — через задачи, метрики, совместные инструменты. Трудовой договор тут ни при чём. Меняется только то, кто его подписывает и кто несёт кадровые обязательства.

Преимущества аутстаффинга разработчиков

Классический рекрутинг никуда не уходит, но иногда аутстаффинг гораздо эффективнее. Итак, каковы же преимущества этой формы найма?

Аутстаффинг в ИТ: быстрое масштабирование без кадровой нагрузки

Найти сильного специалиста в команду в среднем занимает два-три месяца — и это при активном поиске. Часто бывает так, что людей в команде не хватает, потому что проект стремительно растет. Запуск нескольких параллельных процессов поиска кадров рискует затянуться. И тогда бизнес обращается к провайдеру, чтобы добрать нужное количество специалистов. Провайдер предлагает кандидатов, имеющих релевантный опыт в конкретном технологическом стеке, уже через одну-две недели, иногда – быстрее. Разница ощутима, особенно когда дата запуска проекта уже стоит в календаре.

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

Экономит бюджет и снижает операционные затраты

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

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

Дает доступ к широкому пулу технических компетенций

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

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

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

Специалисты с разнообразными опытом

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

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

Снижение административной нагрузки

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

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

Когда аутстаффинг выгоднее штатного найма

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

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

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

• широкой базой найдёт быстрее и, скорее всего, дешевле, чем собственный подбор.
• Тест гипотезы без обязательств. Компания запускает новое направление, но не уверена в его горизонте. Аутстаффинг позволяет собрать команду, быстро оценить гипотезу и выйти без кадровых последствий, если направление не пошло.

У модели есть и ограничения, которые важно учитывать. Главный риск — зависимость от провайдера: если партнёрство прерывается досрочно, специалист уходит вместе с накопленным знанием о проекте. Для критически важных функций это серьёзно. Поэтому разумный подход — смешанный: ключевые роли закрывать штатом, а аутстаффинг подключать для расширения команды под конкретные задачи с понятным сроком.

Штатный найм: когда он по-прежнему эффективен

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

• Погружение в продукт. Человек, который работает с одним продуктом год или два, знает его глубже, чем тот, кого привлекли на полгода. Этот контекст нельзя передать через документацию или онбординг — он накапливается постепенно, через участие во всех стадиях и решениях.
• Лояльность. Штатный сотрудник думает о своей карьере внутри компании, заинтересован в её развитии. Это сложно воспроизвести в модели временного сотрудничества — здесь у специалиста другие приоритеты.
• Корпоративная память. Внутренние специалисты накапливают базу знаний, обучают новых коллег, передают экспертизу. При аутстаффинге существует риск, что с окончанием контракта вместе со специалистом уйдут и знания о проекте — если не выстроить процесс передачи.
• Стабильность команды. Долгие проекты требуют предсказуемого состава: меньше перестановок, меньше потерь контекста. Штатный найм даёт более высокую вероятность сохранить команду на горизонте нескольких лет.

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

Не вместо, а вместе: гибкие форматы и штатный найм техкадров

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

Компании, прошедшие через опыт масштабирования технической команды, как правило, не задаются вопросом «аутстаффинг или штат» — они комбинируют. Устойчивое ядро в штате, расширение под конкретные задачи — через провайдера.

Подробнее о том, как организована работа с внешними техническими кадрами, — в профильных материалах компаний, например, в разделе ИТ-аутсорсинг на сайте Selecty, где описаны конкретные форматы взаимодействия заказчика с провайдером.

Гибкие форматы работы с техническими кадрами сегодня — уже не просто тренд, а устойчивая норма рынка. Компании, которые умеют подбирать инструмент под задачу, получают ощутимое операционное преимущество. ИТ-аутстаффинг при правильном применении — один из таких инструментов.

Реклама. ООО Селекти, ИНН 7736313541, erid: 2W5zFJYUtvD

Разбираем главные события апреля 2026 — что меняется для тех, кто пишет на Python, мейнтейнит библиотеки или поддерживает прод-инфраструктуру.

PEP 772 принят. Python получил избранный Packaging Council из пяти человек с двухлетними сроками — теперь у решений про pip, setuptools и PyPI есть формальный орган, не зависящий от PyPA.

Инкрементальный GC откатывают. В 3.14.5 и 3.15 вернётся старый поколенческий сборщик. Память на проде росла до 5×, а паузы 26 мс vs 1,3 мс этого не оправдывали.

OpenAI приобрёл Astral. Создатели uv, Ruff и type-checker ty теперь под OpenAI. Лицензии открытые — форк остаётся страховочным механизмом.

PEP 803 принят. Появится abi3t — стабильный ABI для free-threaded билдов, цель Python 3.15. Решает «wheel-explosion» для Cryptography, SciPy, Pydantic.

Python 3.15.0 beta 1. Первая бета и feature-freeze назначены на 5 мая. После этой даты в 3.15 уже не попадут новые PEP-ы.

PEP 772: у Python появился Packaging Council

16 апреля Python Software Foundation и Steering Council одобрили PEP 772 — учреждение Packaging Council из пяти человек, выбираемых голосующими членами PSF. Полномочия совета сравнимы со Steering Council, но узкоспециализированы: стандарты упаковки, инструменты вроде pip и setuptools, эксплуатация PyPI.

До этого момента Python Packaging Authority (PyPA) координировала упаковочные решения неформально, через делегирование от Steering Council по PEP 609. На практике это значило, что любое крупное изменение в pip или PyPI требовало согласования через несколько групп без чёткого мандата. Совет получает прямые полномочия и работает на двухлетних сроках с шахматным переизбранием — две и три позиции ротируются в разных циклах, чтобы сохранять преемственность.

Главное последствие — упаковочные вопросы перестают зависать в комитете. По формулировке PEP, решения принимаются консенсусом, как и в Steering Council, но при необходимости совет может действовать голосованием. На повестке у нового органа уже стоят темы вроде упаковки в эпоху LLM-зависимостей и стандартизации lockfile-формата.

Реверт инкрементального GC в Python 3.14.5

В тот же день, 16 апреля, релиз-менеджер Hugo van Kemenade предложил откатить инкрементальный сборщик мусора, дебютировавший в Python 3.14, и core-команда согласилась. Реверт войдёт в 3.14.5 и 3.15 до feature-freeze.

Тестирование на продакшене у Neil Schemenauer показало интересную картину. Максимальные паузы инкрементального коллектора действительно упали с 26 мс до 1,3 мс — то самое, ради чего его и вводили. Но пиковое потребление памяти выросло до 5× baseline, а суммарное время выполнения задач увеличилось из-за дополнительной бухгалтерии. Для веб-приложений, дата-пайплайнов и батч-задач длинные паузы — не главная проблема. Память — главная.

Необычная часть истории — что ревёрт идёт в патч-релизе 3.14.5. На цикле релиза 3.14 предположение было, что инкрементальный GC обоснован. Откат показывает, что «прошёл бенчмарк-сьют» и «работает в проде» — это не одно и то же. Если ваши деплои на 3.14 жгут заметно больше памяти, чем на 3.13, теперь понятно почему. Core-команда не закрывает инкрементальный подход насовсем — вернуться к нему могут в 3.16, но через полноценный PEP-процесс, который оригинальная реализация пропустила.

OpenAI приобрёл Astral — uv, Ruff и ty переходят к ChatGPT-вендору

В конце марта OpenAI объявил о покупке Astral — компании-разработчика uv, Ruff и type-checker ty. Новость прокатилась по сообществу в апреле, когда разработчики начали считать масштаб сделки. uv в начале года перешагнул отметку в 126 миллионов скачиваний в месяц, Ruff давно стал линтером по умолчанию для существенной доли современных Python-проектов. Перенос обоих инструментов под OpenAI — ощутимый сдвиг в том, кто контролирует критическую инфраструктуру Python.

Реакция Simon Willison — «осторожно-оптимистичная»: команде Astral можно доверять прямо сейчас, но «product+talent acquisition может со временем превратиться в чисто talent-only». Структурная страховка — открытые лицензии: форк остаётся жизнеспособным запасным вариантом, если будущие владельцы решат развернуть стратегию.

Первый полный месяц после поглощения прошёл «скучно в хорошем смысле»: uv выпустил патчи 0.11.3–0.11.7, Ruff — 0.15.9–0.15.11, ни один проект курса не сменил. Если кто-то опасался резкого крена в сторону интеграции только с Codex — этого не произошло. На tproger мы писали ранее о том, как Astral в начале апреля запустила направление безопасности — теперь это инициатива внутри OpenAI.

PEP 803: стабильный ABI для free-threaded Python

PEP 803 приняли 30 марта, цель — Python 3.15. Документ определяет abi3t — отдельный вариант стабильного ABI для free-threaded билдов. Это закрывает «wheel-explosion problem», на которую Cryptography, SciPy и Pydantic жалуются уже больше года.

Сейчас, чтобы расширение работало на free-threaded Python, мейнтейнерам приходится собирать отдельный wheel для каждой минорной версии каждого Python-релиза. Контракт обычного abi3 (собрал один раз — работает на любой 3.x) для free-threaded не работает: у этих билдов разные инварианты по потокобезопасности.

Цена стабильности — PyObject становится непрозрачным под abi3t. Расширения, которые сейчас лезут в поля PyObject напрямую, должны мигрировать на новые accessor-API из PEP 697 и PEP 793. Это реальный рефакторинг, но взамен — один wheel на много версий Python. Картинку дополняет FastAPI 0.136.0 от 16 апреля: теперь у фреймворка есть официальная поддержка Python 3.14t. Инфраструктурный слой для GIL-free Python зреет быстро.

Что ещё стоило бы заметить

• Python 3.15.0 beta 1 — 5 мая. Альфа 8 от 7 апреля стала последней. Бета означает feature-freeze: новые PEP-ы в 3.15 после 5 мая уже не попадут.
• JIT в 3.15 быстрее. На x86-64 Linux замеры показывают +6–7%, на AArch64 macOS — +12–13% по сравнению с tail-calling-интерпретатором из 3.14.
• PEP 829 (черновик). Barry Warsaw предложил .start-файлы как замену .pth для startup-хуков пакетов. Старый формат позволяет произвольное исполнение кода при импорте — известный supply-chain-вектор.
• Polars 1.40.0 (18 апреля). Streaming-движок дотянули до групповых AsOf-join, статистики (cov, corr, skew, kurtosis, entropy) и strptime; добавили lock-free memory manager со spill-to-disk.
• Starlette 1.0 (22 марта). ASGI-фундамент FastAPI наконец стабилен: API теперь не сломается без мажорного релиза.
• Gemma 4 day-one в Python. 2 апреля Google открыл веса (2B/4B/31B + 26B MoE). Transformers 5.5.0, vLLM 0.19, Ollama 0.21 — всё с поддержкой в день релиза.
• Jazzband сворачивается. Площадка коллективного мейнтейнинга 84 проектов закрывается до конца 2026 года. Причины — «slopocalypse» (поток AI-сгенерированных PR-ов) и выгорание единственного админа.

Выводы

Апрель 2026 ощутимо сдвинул сразу два слоя Python-экосистемы. Управленческий — у языка появился второй формальный орган, конкретно отвечающий за упаковку, что давно просили десятки участников. Техническая прод-сторона — команда призналась, что инкрементальный GC из 3.14 не проходит проверку реальностью, и откатила его. На фоне этого поглощение Astral смотрится как индустриальный сигнал: ключевая Python-инфраструктура мигрирует в орбиту крупных AI-вендоров, и сообществу остаётся следить, не превратится ли «product+talent» в «talent-only».

Если поддерживаете C-расширение — следите за abi3t и API-миграцией под PEP 697/793. Если деплоите на 3.14 — планируйте обновление до 3.14.5, как только она выйдет. И если вы в принципе следите за Python — стоит разово посмотреть на состав будущего Packaging Council: пять человек впервые получают мандат принимать решения за всех нас.

Источник: Python News — Real Python.

Astral — компания, стоящая за Ruff (линтер для Python, заменяющий flake8, isort и десятки других инструментов) и uv (менеджер пакетов Python, в 10–100 раз быстрее pip). Оба инструмента написаны на Rust и стали стандартом де-факто для многих Python-команд.

• Astral (создатели Ruff и uv) запускает направление безопасности для Python-экосистемы
• Фокус — аудит зависимостей, обнаружение уязвимых и вредоносных пакетов в supply chain
• Инструменты будут open source и интегрированы с существующей экосистемой Astral
• Python — одна из главных мишеней supply chain атак наряду с npm

Зачем это нужно

Python-экосистема — одна из главных мишеней supply chain атак. Только за последний год в PyPI фиксировали сотни вредоносных пакетов: от криптомайнеров до стилеров. Злоумышленники регулярно публикуют пакеты с опечатками в названиях (typosquatting) или внедряют вредоносный код в легитимные пакеты.

Существующие инструменты (pip-audit, safety, Snyk) работают, но не интегрированы с современным Python-тулингом. Astral хочет встроить безопасность прямо в рабочий процесс — на уровне uv и Ruff, где разработчик и так проводит время.

Что планируется

• Аудит зависимостей — проверка lock-файлов на известные уязвимости (CVE)
• Обнаружение вредоносных пакетов — статический анализ кода пакетов на подозрительное поведение
• Интеграция с uv — проверка безопасности при установке и обновлении зависимостей
• Open source — все инструменты будут открытыми, как Ruff и uv

Почему это важно

Astral уже доказали, что могут переизобрести Python-тулинг: Ruff заменил десяток линтеров, uv заменил pip, pip-tools, virtualenv и pyenv. Если они применят тот же подход к безопасности — аудит зависимостей станет таким же быстрым и удобным, как линтинг с Ruff.

Для Python-разработчиков в России это особенно актуально: многие используют локальные зеркала PyPI или корпоративные реестры, где контроль целостности пакетов — отдельная головная боль.

Следить за развитием: блог Astral, GitHub.

Файл .gitignore — один из первых, который появляется в любом репозитории. Но многие добавляют его по привычке, не разбираясь в синтаксисе и не думая о глобальных настройках. В итоге в историю коммитов попадают .pyc-файлы, папки node_modules и секреты из .env.

В этом гайде разберём синтаксис .gitignore с примерами каждого паттерна, дадим готовые шаблоны для Python, Node.js, Java и Go, а также покажем, как исправить ситуацию, если файл уже попал в индекс. Статья рассчитана на тех, кто уже знаком с основами Git — если нужно освежить базу, начните с введения в Git.

— .gitignore поддерживает паттерны *, **, !, / и комментарии через #

— Готовые шаблоны для Python, Node.js, Java и Go закрывают 90% типичных случаев

— Глобальный ~/.gitignore_global избавляет от повторения в каждом проекте правил для IDE и ОС

— Если файл уже в индексе, git rm --cached убирает его без удаления с диска

— .gitkeep — хак для отслеживания пустых директорий

Эта статья — часть нашего полного путеводителя по Git. Там — весь маршрут: от первого коммита до продвинутых workflow.

Синтаксис .gitignore: разбираем каждый паттерн

Git читает .gitignore построчно. Пустые строки игнорируются, строки с # в начале — комментарии. Остальное — паттерны.

* — любое количество символов в имени файла (кроме /):

** — любое количество директорий (рекурсивно):

! — отмена предыдущего правила (исключение из исключений):

Важно: паттерн ! не работает, если родительская директория уже заигнорирована. Например, если в .gitignore есть строка build/, то правило !build/keep-me.txt не поможет — файл всё равно будет игнорироваться. Чтобы исключение сработало, нужно сначала разрешить саму директорию: !build/, а затем уже — конкретный файл.

/ в начале — привязка к корню репозитория:

/ в конце — игнорировать только директорию, не файл с таким же именем:

# — комментарий. Используйте для группировки правил:

Шаблон .gitignore для Python

Python генерирует .pyc-файлы и папки __pycache__ при каждом запуске. Виртуальные окружения (venv, .venv) и файлы с переменными окружения (.env) тоже не должны попадать в репозиторий.

Шаблон .gitignore для Node.js

Главная причина тяжёлых репозиториев на Node.js — папка node_modules, которую забыли добавить в .gitignore. Её размер легко достигает сотен мегабайт.

Шаблон .gitignore для Java

Java-проекты собираются Maven или Gradle — у каждого свои папки артефактов. Скомпилированные .class-файлы и .jar-архивы пересобираются при каждом билде и в репозитории не нужны.

Шаблон .gitignore для Go

Go компилирует проект в бинарник — его хранить в репозитории не нужно. Папка vendor/ содержит копии зависимостей: её включать или нет — зависит от политики команды. Если используете Go modules без vendor-режима, добавьте папку в .gitignore.

Глобальный .gitignore: один раз для всех проектов

Некоторые файлы мусорят в любом проекте — .DS_Store на macOS, Thumbs.db на Windows, файлы IDE вроде .idea/ или .vscode/. Дублировать эти правила в каждом репозитории неудобно. Для этого есть глобальный .gitignore.

Настройка через core.excludesFile:

Пример содержимого ~/.gitignore_global:

После настройки Git применяет глобальные правила автоматически во всех репозиториях на вашем компьютере — без изменения .gitignore проекта.

Ещё один способ локально игнорировать файлы — .git/info/exclude. Этот файл работает как .gitignore, но не коммитится в репозиторий и виден только вам. Удобно для временных файлов, специфичных для вашего окружения, которые не стоит выносить в глобальный ~/.gitignore_global.

Файл уже в индексе: как перестать его отслеживать

Добавить правило в .gitignore недостаточно, если файл уже был закоммичен. Git продолжит его отслеживать. Нужно убрать файл из индекса, сохранив его на диске:

После этого добавьте правило в .gitignore и закоммитьте оба изменения — удаление из индекса и обновлённый .gitignore. Сам файл останется у вас на диске, но перестанет появляться в git status.

Если нужно очистить весь индекс и применить правила заново (например, после добавления нескольких паттернов):

Внимание: эта команда пересоздаёт индекс целиком. Не запускайте её при незакоммиченных изменениях.

.gitkeep: как отслеживать пустые директории

Git не отслеживает директории — только файлы. Если папка пустая, git add её просто проигнорирует. Это проблема, когда структура директорий важна для проекта: например, logs/, uploads/, tmp/.

Решение — добавить в пустую папку файл-заглушку .gitkeep:

Файл .gitkeep — неофициальное соглашение. Никакой специальной поддержки в Git нет, это просто пустой файл с понятным именем. Некоторые команды используют .githold или .keep — принципиальной разницы нет.

Инструменты: генераторы готовых шаблонов

Не обязательно писать .gitignore с нуля — есть готовые инструменты:

• gitignore.io (toptal.com/developers/gitignore) — генератор по языку, IDE и ОС. Введите «Python», «JetBrains», «macOS» — получите готовый файл.
• GitHub gitignore templates — официальная коллекция шаблонов от GitHub. Шаблоны для 150+ языков и фреймворков. Используется как основа при создании репозитория через интерфейс GitHub.
• gh repo create — при создании репозитория через GitHub CLI можно сразу выбрать шаблон .gitignore флагом --gitignore.

Для проверки, почему конкретный файл игнорируется (или не игнорируется), используйте встроенную команду:

Итог

Правильный .gitignore — это не формальность, а часть культуры работы с репозиторием. Он защищает от утечки секретов, не даёт захламить историю коммитов и экономит время при клонировании. Начните с шаблона под ваш стек (используйте gitignore.io или GitHub-коллекцию), добавьте глобальный файл для настроек IDE, и у вас не будет проблем с лишними файлами в git status.

Если хотите разобраться с Git глубже — изучите полный путеводитель по Git на Tproger: там собраны все ключевые темы от основ до продвинутых техник.

Мне стало интересно: а можно ли на бесплатных мощностях, буквально "на коленке", собрать русскоязычного ИИ-рентгенолога? Спойлер: можно. В этой статье расскажу, как я скрестил Vision Transformer от Google с ruGPT-3 от Сбера, как боролся с датасетами на Kaggle и что из этого вышло. В конце — ссылки на GitHub и рабочее демо.

Архитектура: как пришить глаза к мозгу

Чтобы нейросеть могла посмотреть на снимок и написать текст, нужна архитектура Vision-Language Model. Обучать такого монстра с нуля у меня не было ни ресурсов, ни желания. Поэтому я пошел по пути Hugging Face VisionEncoderDecoderModel.

Идея проста как кирпич:

1. Энкодер (Глаза): Берем предобученный google/vit-base-patch16-224-in21k. Он отлично дробит картинку на патчи и извлекает визуальные фичи (понимает, где ребра, а где легкие).
2. Декодер (Язык): Берем ai-forever/rugpt3small_based_on_gpt2. У нее нет глаз, она умеет только генерировать текст.

Чтобы их сшить, пришлось немного "взломать" конфиг ruGPT-3, принудительно сказав ей: «Теперь ты декодер, и у тебя есть слои кросс-внимания» (is_decoder=True, add_cross_attention=True). Hugging Face заботливо создал новые пустые веса между двумя моделями. Именно эти связи мне и предстояло обучить.

Data Engineering: боль, страдания и Kaggle

Найти 7-10 тысяч рентгеновских снимков с подробными заключениями на русском языке в открытом доступе — задача нереальная.

Поэтому я взял открытый американский датасет Indiana University Chest X-Ray (IU X-Ray). Там есть картинки и тексты от американских врачей.

Прямо на Kaggle я поднял пайплайн машинного перевода на базе Helsinki-NLP/opus-mt-en-ru. Закинул тексты в GPU батчами по 32 штуки и за 10 минут перевел более 7000 медицинских заключений на вполне сносный русский медицинский язык.

Но тут платформа подкинула сюрприз: Kaggle прячет часть файлов в виртуальной файловой системе (снимков 7000, а стандартный скрипт видел только 4). Пришлось писать суровый маппинг с глубоким сканированием (os.walk), отрезать расширения и жестко связывать ID в CSV с реальными путями на диске.

Обучение: выжимаем все соки из бесплатных T4

Обучение проходило на Kaggle (2x NVIDIA T4). Чтобы модель не умерла от нехватки памяти (OOM), а сессия не отвалилась по тайм-ауту, пришлось шаманить:

• Включил Mixed Precision (fp16) — ускорило обучение в 2 раза.
• Настроил Gradient Accumulation — размер батча на видеокарту был всего 4, но виртуально мы накапливали до 16.
• Столкнулся с тем, что Seq2SeqTrainer крашится при попытке сохранить промежуточный чекпоинт мультимодального "франкенштейна". Решение? Выключить промежуточные сохранения (save_strategy="epoch") и молиться, чтобы Kaggle не завис. (Кстати, спасает JS-скрипт в консоли браузера, делающий клик раз в 60 секунд).

На 15 эпох ушло около 2.5 часов.

Что получилось в итоге? (Потрогать руками)

Получилась нейросеть, которая реально понимает, что изображено на рентгене, и сыпет терминами вроде «кальцифицированная гранулема» или «легочная васкулярность». Да, иногда она "галлюцинирует" (датасет в 7к снимков — это капля в море для ML), но базовые вещи вроде чистых легких или пневмоторакса сечет неплохо.

Я завернул модель в Gradio и выложил на Hugging Face Spaces. Можно зайти с телефона или ПК, загрузить любой снимок рентгена из гугла и посмотреть, что она выдаст.

👉 Потыкать лайв-демо тут: Hugging Face Space

👉 Весь код, пайплайны и веса тут: GitHub Репозиторий

Буду рад, если кому-то этот код сэкономит время при создании своих мультимодальных сеток. Залетайте в репу, ставьте звездочки, форкайте. Если есть идеи, как улучшить датасет (может, прогнать переводы через LLM для чистки медицинского сленга) — пишите в комменты!

(Дисклеймер: модель обучена в исследовательских целях за вечер. Не суйте ей свои снимки вместо похода к реальному врачу)

В октябре 2025 года вышел Python 3.14 с экспериментальным JIT-компилятором и поддержкой шаблонных T-строк — язык продолжает ускоряться, не жертвуя простотой. Экосистема тоже не стоит на месте: FastAPI стал стандартом для высокопроизводительных API, а инструменты вроде Ruff и uv радикально ускорили рабочий процесс разработчика. Python Package Index (PyPI) насчитывает более 600 000 пакетов — для любой задачи, скорее всего, уже существует готовое решение.

Этот путеводитель — не энциклопедия и не учебник. Это навигационный хаб: мы кратко разберём каждую важную область Python и дадим ссылки на подробные материалы Tproger, где каждая тема раскрыта в деталях. Неважно, только начинаете вы знакомство с языком или уже пишете на нём продакшен-код — здесь вы найдёте структурированную карту для дальнейшего роста. Мы охватим основы синтаксиса, продвинутые концепции, три главных веб-фреймворка, Data Science, последние нововведения в Python 3.14 и карьерные перспективы.

— Python — язык №1 по TIOBE 2026, более 600 000 пакетов в PyPI

— Основы языка: динамическая типизация, duck typing, встроенные коллекции (list, tuple, dict, set и другие)

— Три главных веб-фреймворка: Django (full-stack), Flask (микро), FastAPI (async API)

— Python 3.14: экспериментальный JIT-компилятор и шаблонные T-строки

— Медианная зарплата middle Python-разработчика: 250 000—350 000 руб./мес.

— Функции: замыкания, LEGB, *args/**kwargs, лямбды

— ООП: классы, наследование, @property, магические методы

— GIL, threading, asyncio и multiprocessing — когда что использовать

— Тестирование с pytest, работа с файлами через pathlib

Основы языка: с чего начинается Python

Python — язык с динамической типизацией и строгим контролем отступов. Если в C++ или Java фигурные скобки определяют блоки кода, то в Python эту роль играют пробелы. Поначалу это непривычно, но на практике делает код единообразным и читаемым — у вас просто нет возможности написать нечитаемую «лапшу». Философия Python описана в «Дзен Python» (PEP 20): «Красивое лучше уродливого», «Явное лучше неявного», «Простое лучше сложного». Эти принципы пронизывают весь язык и его стандартную библиотеку.

Базовые типы данных в Python — это числа (int, float, complex), строки (str), булевы значения (bool), а также коллекции: списки (list), кортежи (tuple), множества (set) и словари (dict). Каждый тип имеет свои особенности. Например, целые числа в Python не ограничены размером: можно спокойно работать с числами в тысячи разрядов без переполнения — попробуйте сделать это в C или Java. Строки неизменяемы, а словари с Python 3.7 гарантированно сохраняют порядок вставки. Множества предоставляют проверку принадлежности элемента за O(1), а операции объединения, пересечения и разности выполняются за линейное время, что делает их незаменимыми для задач на поиск уникальных элементов.

Одна из ключевых концепций — duck typing: «если объект ходит как утка и крякает как утка, то это утка». Python не проверяет тип объекта заранее — он проверяет, поддерживает ли объект нужную операцию. Это даёт гибкость, но требует дисциплины. Современный Python активно использует аннотации типов (type hints), которые помогают IDE и линтерам находить ошибки ещё до запуска кода. Начиная с Python 3.10 появился оператор match/case (паттерн-матчинг), а в 3.12 — улучшенные дженерики и type aliases, которые делают типизацию ещё удобнее.

Переменные в Python — это не ячейки памяти, а метки (имена), привязанные к объектам. Понимание этого механизма — ключ к предсказуемой работе с мутабельными типами вроде списков и словарей. Когда вы пишете a = b для списка, вы не копируете данные — обе переменные указывают на один и тот же объект в памяти. Отсюда классические ловушки с изменяемыми аргументами по умолчанию и «неожиданным» изменением данных. Для создания независимой копии нужно использовать срез [:], метод copy() или модуль copy для глубокого копирования.

Управляющие конструкции в Python минималистичны и выразительны. Условия записываются через if/elif/else, циклы — через for и while. Конструкция for в Python ближе к foreach из других языков: она итерирует по элементам коллекции, а не по индексам. Функция range() генерирует последовательности чисел для случаев, когда нужен числовой цикл. Важно освоить и обработку исключений (try/except/finally) — Python использует исключения не только для ошибок, но и как механизм управления потоком, например StopIteration для завершения итерации.

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

Функции в Python

Функции — основной инструмент структурирования кода в Python. Ключевое слово def создаёт функцию, return возвращает результат. Python поддерживает позиционные и именованные аргументы, значения по умолчанию, а также распаковку через *args (кортеж позиционных) и **kwargs (словарь именованных). Это позволяет создавать гибкие интерфейсы: от простых утилит до сложных API-обёрток.

Анонимные функции lambda удобны для коротких выражений — например, в качестве ключа сортировки: sorted(users, key=lambda u: u.age). Однако злоупотреблять ими не стоит: если лямбда не помещается в одну строку, лучше написать обычную функцию с понятным именем.

Python использует правило LEGB для поиска переменных: Local → Enclosing → Global → Built-in. Это объясняет, почему переменная внутри функции «затеняет» глобальную, и почему для изменения глобальной переменной нужно объявление global. Замыкания (closures) — функции, захватывающие переменные из объемлющей области видимости — лежат в основе декораторов, фабричных функций и callback-паттернов.

Функции в Python — объекты первого класса: их можно передавать как аргументы, возвращать из других функций и сохранять в структурах данных. Это фундамент для функционального стиля программирования, который активно используется вместе с map(), filter() и functools.

ООП в Python

Python — мультипарадигменный язык, но ООП в нём реализовано глубоко и последовательно. Классы создаются ключевым словом class, конструктор определяется методом __init__, а первый параметр каждого метода — self, ссылка на текущий экземпляр. В отличие от Java или C#, где this подразумевается неявно, Python требует явного указания — это осознанный выбор в пользу читаемости.

Python поддерживает множественное наследование через механизм MRO (Method Resolution Order) — алгоритм C3-линеаризации определяет порядок обхода родительских классов. Полиморфизм реализуется через duck typing: нет необходимости в интерфейсах — достаточно, чтобы объект имел нужные методы. Для формальных контрактов есть модуль abc с абстрактными базовыми классами и декоратором @abstractmethod.

Инкапсуляция в Python — скорее соглашение, чем принуждение. Префикс _ обозначает «приватный» атрибут, __ — активирует механизм name mangling, но ни то ни другое не запрещает доступ. Для контролируемого доступа к атрибутам используют декоратор @property, который превращает метод в вычисляемое свойство с геттером, сеттером и делетером.

Магические методы (dunder-методы) — мощный механизм, позволяющий объектам вести себя как встроенные типы. __str__ и __repr__ управляют строковым представлением, __eq__ и __hash__ — сравнением, __len__ и __getitem__ — доступом к элементам. Подробный разбор синтаксиса и концепций Python — в нашем подробном описании языка для начинающих.

Модули и пакеты Python

Модульная система Python проста: любой .py-файл — это модуль, а директория с __init__.py — пакет. Импорт осуществляется через import и from ... import. Python ищет модули по путям из sys.path, куда автоматически входят текущая директория, стандартная библиотека и директория site-packages с установленными пакетами.

Для управления зависимостями экосистема предлагает несколько инструментов. Классический pip + venv решает базовые задачи: создание изолированного окружения и установка пакетов из PyPI. Poetry добавляет управление зависимостями через pyproject.toml, lock-файлы и публикацию пакетов. Новый uv — написанный на Rust менеджер пакетов — работает в 10—100 раз быстрее pip и активно набирает популярность.

Стандартная библиотека Python (batteries included) — одна из самых богатых: от работы с сетью (http, socket) до сериализации (json, pickle), регулярных выражений (re) и параллелизма (threading, multiprocessing). Полный список из более чем 200 модулей доступен в нашей подборке полезных Python-библиотек.

Практика: задачи для начинающих

Главная ошибка при изучении программирования — читать теорию неделями, не написав ни строчки кода. Python хорош тем, что позволяет начать практиковаться с первого дня: интерактивный интерпретатор (REPL), быстрая обратная связь и понятные сообщения об ошибках снижают барьер входа до минимума. Откройте терминал, напишите python3 — и вы уже можете экспериментировать.

Начинайте с простых задач: обработка строк, работа со списками, базовые циклы и условия. Затем переходите к задачам на функции, рекурсию и работу с файлами. Важно не просто решать задачу, а разбирать чужие решения — так вы быстрее освоите идиоматический Python. Один грамотно решённый пример научит вас большему, чем десять страниц документации. Обращайте внимание на то, как опытные разработчики используют встроенные функции (enumerate, zip, map), срезы списков и словарные включения — это и есть «питонический» стиль.

Хорошая практика — вести собственный файл с решениями и заметками. Возвращаясь к задачам через неделю, вы увидите, как вырос ваш уровень. Платформы вроде LeetCode, Codewars и HackerRank предлагают задачи с автоматической проверкой, но начинать лучше с задач, адаптированных под русскоязычную аудиторию. Ещё один совет: не гонитесь за количеством. Пять задач, решённых вдумчиво с разбором альтернативных подходов, ценнее пятидесяти, решённых механически копированием паттернов.

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

Продвинутые концепции Python

Когда основы освоены, приходит время познакомиться с инструментами, которые отличают код новичка от кода опытного разработчика. В Python таких инструментов много, но есть пять ключевых концепций, без которых сложно писать по-настоящему качественный код: декораторы, генераторы, comprehensions, контекст-менеджеры и механизм *args/**kwargs. Именно владение этими инструментами отличает junior-разработчика от middle — и именно их чаще всего спрашивают на собеседованиях.

Декораторы

Декоратор — это функция, которая принимает другую функцию и возвращает её модифицированную версию. Звучит абстрактно, но на практике декораторы встречаются повсеместно: @property, @staticmethod, @login_required в Django, @app.route() во Flask. Они позволяют добавлять поведение без изменения исходного кода функции — логирование, кэширование, проверку прав доступа, валидацию аргументов, замер времени выполнения.

Под капотом декоратор — это обычный паттерн: функция, принимающая функцию и возвращающая функцию. Но синтаксический сахар с символом @ делает код лаконичным и выразительным. Декораторы можно параметризовать, складывать стопкой (применять несколько к одной функции) и даже применять к целым классам. Стандартная библиотека Python включает полезные декораторы: @functools.lru_cache для кэширования результатов, @functools.wraps для сохранения метаданных обёрнутой функции.

Декораторы — одна из тех тем, которые кажутся сложными ровно до момента, пока не разберёшься. Подробный разбор с примерами — в статье «Декораторы в Python: понять и полюбить».

Генераторы и comprehensions

Генераторы — это функции с ключевым словом yield, которые возвращают данные лениво, по одному элементу за раз. Вместо того чтобы создавать в памяти список из миллиона элементов, генератор выдаёт их по запросу. Это критически важно при обработке больших файлов, потоков данных и результатов SQL-запросов. Генератор занимает фиксированный объём памяти независимо от количества элементов — хоть миллион, хоть миллиард.

Comprehensions (списковые, словарные и множественные включения) — это питонический способ создания коллекций в одну строку. Вместо цикла из трёх строк вы пишете выразительную конструкцию: [x ** 2 for x in range(10) if x % 2 == 0]. Они быстрее эквивалентных циклов (Python оптимизирует их на уровне байткода) и читаются проще — если не злоупотреблять вложенностью. Словарные включения {k: v for k, v in pairs} и множественные {x for x in items} работают по тому же принципу.

Контекст-менеджеры и *args/**kwargs

Конструкция with в Python — это контекст-менеджер, который гарантирует корректное освобождение ресурсов: закрытие файлов, соединений с базой, снятие блокировок. Вместо try/finally вы пишете with open('file.txt') as f: — и ресурс освобождается автоматически, даже если произошла ошибка. Можно создавать собственные контекст-менеджеры через методы __enter__/__exit__ или декоратор @contextmanager из модуля contextlib — это проще, чем кажется.

*args и **kwargs позволяют создавать функции с переменным числом аргументов. Это основа для написания гибких API, декораторов и обёрток. Понимание того, как Python распаковывает аргументы, открывает путь к элегантным решениям: передача параметров из словаря в функцию одной строкой, объединение конфигураций, создание универсальных обёрток. В комбинации с аннотациями типов (ParamSpec, Concatenate) этот механизм стал ещё мощнее в последних версиях Python.

Отдельного внимания заслуживает работа с памятью. Python скрывает от разработчика ручное управление памятью, но понимание того, сколько весят разные типы данных и как работает сборщик мусора, помогает писать эффективный код. Например, пустой список в Python занимает 56 байт, а каждый элемент добавляет 8 байт на указатель плюс размер самого объекта. Для числовых задач это означает, что NumPy-массив может быть в 10 раз компактнее обычного списка. Детальный разбор — в статье о распределении памяти в Python.

Dataclasses и NamedTuple

Модуль dataclasses (Python 3.7+) решает классическую проблему: написание классов, которые в основном хранят данные. Декоратор @dataclass автоматически генерирует __init__, __repr__, __eq__ и другие методы. С параметром frozen=True класс становится неизменяемым — удобно для конфигураций и DTO.

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

Многопоточность, асинхронность и GIL

GIL (Global Interpreter Lock) — глобальная блокировка интерпретатора CPython, которая гарантирует, что в каждый момент времени только один поток выполняет байткод Python. Это упрощает реализацию интерпретатора и работу с памятью, но ограничивает параллелизм CPU-задач. Важно: GIL не мешает I/O-параллелизму — потоки освобождают блокировку при ожидании сети, диска или sleep.

Модуль threading подходит для I/O-bound задач: параллельные HTTP-запросы, чтение файлов, работа с базами данных. Для CPU-bound вычислений (обработка изображений, математические расчёты) используйте multiprocessing — он создаёт отдельные процессы, каждый со своим GIL. Пул concurrent.futures.ProcessPoolExecutor упрощает распределение задач по ядрам.

Модуль asyncio — стандарт для асинхронного программирования в Python. Конструкции async def и await позволяют писать неблокирующий код, который выглядит почти как синхронный. Один поток обрабатывает тысячи соединений — именно поэтому FastAPI и другие ASGI-фреймворки работают быстрее классических WSGI-аналогов.

Когда что использовать? threading — для I/O-операций с умеренной нагрузкой. asyncio — для высоконагруженных I/O-сценариев (веб-серверы, парсеры). multiprocessing — для CPU-bound задач. На практике они часто комбинируются: например, asyncio для сетевого ввода-вывода и ProcessPool для тяжёлых вычислений внутри одного приложения.

Важная новость: PEP 703 предлагает сделать GIL опциональным (free-threaded Python). Экспериментальная сборка без GIL уже доступна в Python 3.13+ через специальную сборку python3.14t (free-threaded build). В Python 3.14 этот режим стал официально поддерживаемым (PEP 779). Если эксперимент окажется успешным, в будущих версиях Python сможет полноценно использовать все ядра процессора без обходных путей через multiprocessing.

Тестирование в Python

Тестирование — не роскошь, а базовая гигиена разработки. В Python стандартом де-факто является pytest — фреймворк, который сочетает простоту написания тестов с мощной системой расширений. Обычные функции с assert — это уже тесты. Не нужны классы, наследование от TestCase и специальные методы.

Фикстуры (@pytest.fixture) управляют подготовкой и очисткой тестового окружения: подключение к базе данных, создание тестового клиента, временные файлы. Параметризация (@pytest.mark.parametrize) позволяет прогнать один тест с десятками наборов входных данных без дублирования кода.

Для изоляции внешних зависимостей используйте unittest.mock — встроенный модуль, который позволяет подменять HTTP-запросы, обращения к базе данных и вызовы внешних сервисов. В связке с pytest это покрывает 95% потребностей в тестировании. TDD (Test-Driven Development) — подход, при котором тест пишется раньше кода. Его необязательно практиковать всегда, но для сложной бизнес-логики он существенно снижает количество регрессий.

Работа с файлами и данными

Python предоставляет удобные инструменты для работы с файлами любых форматов. Конструкция with open(...) гарантирует корректное закрытие файла даже при ошибке. Модуль pathlib (Python 3.4+) — современная замена os.path: объектно-ориентированные пути, кроссплатформенная совместимость и цепочки вызовов.

Для структурированных данных стандартная библиотека предлагает модули json, csv и configparser. Для YAML понадобится сторонний пакет PyYAML. Работа с Excel-файлами — через openpyxl или pandas. Для больших объёмов данных используйте потоковое чтение: csv.reader или json.JSONDecoder().raw_decode() вместо загрузки всего файла в память.

Для работы с распределением памяти и внутренним устройством типов данных Python — рекомендуем нашу статью о распределении памяти в Python: сколько и в каких случаях занимают типы данных.

Веб-разработка на Python

Python — один из ключевых языков для серверной веб-разработки. Три фреймворка покрывают практически все сценарии: Django — для полнофункциональных приложений, Flask — для микросервисов и лёгких проектов, FastAPI — для высокопроизводительных API. Каждый из них занимает свою нишу, и выбор зависит от масштаба проекта, требований к производительности и опыта команды. Разберём сильные и слабые стороны каждого, чтобы вы могли сделать осознанный выбор.

Django: всё включено

Django — это «батарейки в комплекте». ORM, админ-панель, система аутентификации, шаблонизатор, миграции базы данных, защита от CSRF и XSS, формы с валидацией, кэширование, интернационализация — всё работает из коробки и не требует сторонних зависимостей. Это делает Django идеальным выбором для крупных проектов: интернет-магазинов, SaaS-платформ, CRM-систем, внутренних корпоративных порталов. Instagram, Mozilla, Disqus, Pinterest — все они используют Django в продакшене.

Главное преимущество Django — зрелость. Фреймворку больше 20 лет, он имеет огромное сообщество, тысячи готовых пакетов (django-rest-framework, django-allauth, celery) и предсказуемый цикл релизов. Django ORM позволяет работать с базой данных через Python-объекты, не написав ни строчки SQL, а система миграций автоматически отслеживает изменения в моделях. Обратная сторона — Django навязывает свою архитектуру. Если вам нужен только REST API без шаблонов и админки, значительная часть фреймворка будет «мёртвым грузом».

Flask: минималистичный и гибкий

Flask — противоположность Django. Микрофреймворк даёт маршрутизацию, обработку запросов и систему расширений — остальное вы выбираете сами. Нужна ORM? Подключите SQLAlchemy. Нужна авторизация? Flask-Login. Хотите WebSocket? Flask-SocketIO. Такой подход идеален для микросервисов, прототипов и проектов, где полный контроль над стеком важнее скорости старта. Flask часто выбирают для внутренних сервисов, API-шлюзов и проектов, которые начинаются маленькими, но могут вырасти.

Flask отлично сочетается с фронтенд-фреймворками. Например, в статье «Пишем одностраничное приложение с Flask и Vue.js» мы показываем, как построить SPA с Flask-бэкендом — от настройки проекта до деплоя. Это типичный современный стек: Python на сервере, JavaScript-фреймворк на клиенте.

FastAPI: скорость и типизация

FastAPI — самый молодой из тройки, но уже ставший стандартом для создания API. Он построен на Starlette (ASGI) и Pydantic, поддерживает async/await из коробки и автоматически генерирует документацию OpenAPI (Swagger UI и ReDoc) прямо из аннотаций типов в коде. FastAPI — один из самых быстрых Python-фреймворков благодаря Starlette и uvicorn. Валидация данных через Pydantic-модели ловит ошибки ещё до обработки запроса, а type hints превращаются в живую документацию API. Dependency injection встроен в ядро фреймворка, что упрощает тестирование и переиспользование кода.

Но скорость — не всё. FastAPI требует понимания асинхронного программирования, а экосистема пока уступает Django и Flask по количеству готовых решений. Для простого CRUD-приложения с админкой Django справится быстрее; для прототипа с нестандартной архитектурой Flask даст больше свободы. О подводных камнях и ситуациях, когда FastAPI — не лучший выбор, мы подробно рассказываем в статье «Почему не стоит выбирать FastAPI» — честный разбор, который поможет принять взвешенное решение.

Какой фреймворк выбрать

• Полноценное веб-приложение с админкой и авторизацией — Django
• Микросервис или прототип с полным контролем над стеком — Flask
• Высокопроизводительный REST/GraphQL API с автодокументацией — FastAPI
• Не уверены — начните с Django: у него самый пологий путь от нуля до продакшена

На практике многие команды используют несколько фреймворков одновременно: Django для основного приложения, FastAPI для высоконагруженных микросервисов, Flask для внутренних инструментов. Python позволяет комбинировать. Общий навык для всех трёх фреймворков — понимание HTTP-протокола, REST-архитектуры, работы с базами данных и основ безопасности (CORS, CSRF, XSS, SQL-инъекции). Освоив эти концепции на одном фреймворке, вы легко перейдёте на другой.

Python для Data Science

Если веб-разработка — давняя территория Python, то Data Science — его новая сверхдержава. По данным JetBrains Developer Ecosystem Survey, Python — самый изучаемый язык программирования и основной инструмент дата-аналитиков и дата-инженеров. R, Julia, Scala — у каждого есть свои преимущества, но ни один не предлагает такую же широту экосистемы. Причина — уникальный набор библиотек, который покрывает весь pipeline работы с данными: от загрузки и очистки до визуализации и развёртывания моделей в продакшен.

NumPy — фундамент всего стека. Библиотека предоставляет многомерные массивы и математические операции, работающие на порядки быстрее чистого Python — за счёт реализации на C. Умножение матрицы 1000x1000 в NumPy выполняется за миллисекунды, в то время как наивная реализация на чистом Python займёт минуты. Pandas строится поверх NumPy и предлагает удобные таблицы (DataFrame), позволяя загружать, фильтровать, группировать и агрегировать данные в несколько строк кода. Данные из CSV, Excel, SQL, JSON — Pandas читает практически всё.

Для машинного обучения стандартом остаётся scikit-learn — библиотека с десятками алгоритмов классификации, регрессии и кластеризации. Её главная сила — единый интерфейс: fit(), predict(), score() работают одинаково для любого алгоритма, будь то случайный лес, SVM или градиентный бустинг. Это позволяет быстро сравнивать модели, менять алгоритмы одной строкой и строить пайплайны предобработки данных.

Для глубокого обучения Python предлагает PyTorch и TensorFlow — два гиганта, на которых построены GPT, Stable Diffusion и другие модели, изменившие индустрию. PyTorch доминирует в исследованиях благодаря динамическим вычислительным графам, а TensorFlow остаётся популярным в продакшене благодаря TensorFlow Serving и TFLite. Визуализация данных — matplotlib для статичных графиков, seaborn для статистических визуализаций и plotly для интерактивных дашбордов. Jupyter Notebook объединяет всё это в единую среду, где код, графики и текст живут рядом.

Разобраться в ключевых библиотеках поможет наш топ-10 Python-библиотек для Data Science. А если хотите расширить инструментарий за пределы стандартного набора — загляните в подборку 10 полезных библиотек, о которых вы могли не слышать: там есть настоящие жемчужины для отладки, профилирования и работы с данными.

Для управления окружениями в Data Science часто используют conda (Anaconda/Miniconda) — он умеет устанавливать не только Python-пакеты, но и системные зависимости вроде CUDA для GPU-вычислений.

Практические инструменты Python

Помимо веб-разработки и Data Science, Python — незаменимый инструмент для повседневных задач: интеграция с внешними сервисами, извлечение данных из веб-страниц и обработка текста.

Работа с API

Библиотека requests — стандарт для синхронных HTTP-запросов: лаконичный API, автоматическая сериализация JSON и управление сессиями. Для асинхронных задач и HTTP/2 используйте httpx — он совместим с requests по интерфейсу, но поддерживает async/await.

Веб-скрапинг

Для извлечения данных из HTML-страниц Python предлагает несколько уровней инструментов. BeautifulSoup — простой парсер для статических страниц: выборка по CSS-селекторам и тегам. Scrapy — полноценный фреймворк для масштабного скрапинга с очередями, ротацией прокси и экспортом данных. Selenium и Playwright — для страниц, где контент рендерится JavaScript'ом.

Регулярные выражения

Модуль re — мощный инструмент для поиска и трансформации текста по шаблонам. Основные функции: re.findall() для извлечения всех совпадений, re.sub() для замены и re.compile() для предкомпиляции часто используемых паттернов.

Совет: для сложных паттернов используйте сырые строки (r"...") — они избавляют от двойного экранирования обратных слэшей. А для задач, выходящих за рамки регулярных выражений (парсинг HTML, XML), всегда предпочитайте специализированные парсеры.

Что нового в Python 3.14

Python 3.14 (что нового) (да, «пи»-релиз — разработчики не упустили возможность пошутить), выпущенный в октябре 2025 года, стал одним из самых значительных релизов за последние годы. Главные нововведения направлены на производительность — область, где Python традиционно уступал компилируемым языкам. Но 3.14 меняет правила игры.

Экспериментальный JIT-компилятор (PEP 744) — пожалуй, главная новость. Он компилирует часто выполняемые участки кода (так называемые «горячие пути») в машинные инструкции прямо во время работы программы. На реальных приложениях это даёт эффект варьируется: от замедления на 10% до ускорения на 20% в зависимости от нагрузки — на некоторых задачах JIT пока замедляет код без каких-либо изменений в коде. JIT пока отключён по умолчанию (в официальных сборках для macOS и Windows JIT уже включён в бинарники — активируется переменной окружения PYTHON_JIT=1), но уже работает стабильно на большинстве платформ. Это первый шаг к тому, чтобы Python перестал считаться «медленным языком».

Внутренняя архитектура интерпретатора переработана: новый tail-call диспетчер опкодов (на уровне C, не Python-функций) даёт прирост 3—5% на стандартном benchmark suite. Важно: это не оптимизация хвостовой рекурсии в Python-коде — RecursionError при превышении глубины стека по-прежнему возможен.

T-строки (PEP 750) — новый синтаксис шаблонных строк с префиксом t"...". В отличие от f-строк, T-строки не выполняют подстановку сразу, а возвращают объект Template, который можно обработать — экранировать специальные символы, валидировать параметры, преобразовать значения. Это отличное решение для безопасной генерации HTML и SQL без риска инъекций.

Среди других улучшений — ускоренные операции со словарями (до 40% быстрее в некоторых сценариях), оптимизированная работа сборщика мусора и улучшенные сообщения об ошибках, которые теперь подсказывают возможные причины проблемы. Обновлён синтаксис обработки исключений (PEP 758): теперь можно писать except ValueError, TypeError: без скобок (без as — с as по-прежнему нужны скобки: except (ValueError, TypeError) as e:). Также завершён переход на отложенное вычисление аннотаций типов (PEP 649/749) — аннотации больше не вычисляются при импорте модуля, что ускоряет запуск. Python продолжает развиваться, сохраняя обратную совместимость и фокус на удобстве разработчика.

Куда двигаться дальше

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

1. Backend-разработчик — Django, Flask или FastAPI, базы данных (PostgreSQL, Redis), REST API, очереди задач (Celery), контейнеризация (Docker, Kubernetes)
2. Data Scientist / ML-инженер — pandas, scikit-learn, PyTorch, работа с данными, статистика, построение и деплой моделей
3. DevOps / SRE — автоматизация инфраструктуры (Ansible, Terraform), скрипты мониторинга, CI/CD пайплайны, облачные провайдеры (AWS, GCP)
4. ИИ-инженер — LLM, промпт-инжиниринг, RAG-системы, fine-tuning, LangChain, работа с API нейросетей (OpenAI, Anthropic, Mistral)
5. Автоматизатор / QA-инженер — Selenium, Playwright, pytest, автоматизация тестирования, нагрузочное тестирование (Locust)

Независимо от выбранного направления, есть навыки, которые пригодятся везде: Git для контроля версий, SQL для работы с базами данных, Docker для контейнеризации, Linux для понимания серверной среды. Python-разработчик в 2026 году — это не просто человек, который знает синтаксис языка, а специалист, владеющий инструментарием вокруг него. Также стоит освоить виртуальные окружения (venv, poetry, uv), линтеры (ruff, mypy) и основы CI/CD — это ожидается от любого профессионального разработчика. Для управления версиями Python-проектов пригодится наш путеводитель по Git.

Рынок труда подтверждает спрос: по данным hh.ru, количество вакансий с Python стабильно растёт на 15—20% в год, а медианная зарплата Python-разработчика уровня middle составляет 250 000—350 000 рублей в месяц. Специалисты на стыке Python и Data Science / ML зарабатывают ещё больше. Язык востребован не только в IT-компаниях: банки, телеком, ритейл, промышленность — Python нужен везде, где есть данные и автоматизация.

Отдельно стоит упомянуть растущий спрос на ИИ-инженеров. С развитием больших языковых моделей Python стал основным языком для интеграции ИИ в продукты: построение RAG-систем, создание агентов, fine-tuning моделей — всё это делается на Python. Библиотеки LangChain, LlamaIndex, Hugging Face Transformers формируют новую экосистему, которая растёт быстрее любого другого направления в IT.

Если вы в начале пути — начните со структурированной дорожной карты изучения Python. Она поможет не потеряться в обилии материалов и выстроить последовательный план обучения от основ до профессионального уровня. А затем возвращайтесь к этому путеводителю — здесь вы всегда найдёте ссылки на углублённые материалы по каждой теме. Мы регулярно обновляем наши гайды, чтобы они оставались актуальными — так что добавляйте страницу в закладки.

PrismML — стартап из Калтеха, поддержанный Khosla Ventures, Cerberus и Google — представил семейство 1-bit Bonsai: первые коммерчески жизнеспособные языковые модели, где каждый параметр закодирован одним битом. Модели доступны под лицензией Apache 2.0.

• 1-bit Bonsai 8B — LLM на 8,2 млрд параметров с 1-битными весами, занимает 1,15 ГБ (в 14 раз меньше обычной 8B-модели)
• На бенчмарках конкурирует с Llama 3 8B и Qwen3 8B, при этом работает в 8 раз быстрее и потребляет в 4-5 раз меньше энергии
• Запускается на iPhone 17 Pro Max (44 ток/с), M4 Pro (131 ток/с), RTX 4090 (368 ток/с)
• Также выпущены Bonsai 4B (~0,5 ГБ) и Bonsai 1.7B (0,24 ГБ)
• Лицензия Apache 2.0, модели доступны на Hugging Face

Последние годы развитие ИИ шло по пути увеличения моделей: больше параметров, больше GPU, больше энергии. Это дало мощные модели, но привязало их к дата-центрам. PrismML предлагает альтернативу — не наращивать размер, а концентрировать интеллект: максимум полезной работы на гигабайт модели.

Что значит «1-битная модель»

В стандартных LLM каждый вес (параметр) хранится в 16-битном числе с плавающей точкой (FP16). В 1-bit Bonsai 8B все веса — эмбеддинги, слои внимания, MLP-слои и LM head — закодированы одним битом. Нет «escape hatches» с повышенной точностью — это настоящая 1-битная модель от начала до конца.

Результат: модель с 8,2 млрд параметров занимает 1,15 ГБ вместо ~16 ГБ. Это уменьшение в 14 раз — не за счёт обрезки слоёв или дистилляции, а за счёт принципиально иного способа кодирования весов.

Производительность: бенчмарки и скорость

PrismML измерял Bonsai 8B на стандартном наборе бенчмарков: IFEval, GSM8K, HumanEval+, BFCL, MuSR, MMLU-Redux.

• По средним оценкам бенчмарков — конкурирует с Llama 3 8B, Qwen3 8B и другими лидерами класса 8B
• Intelligence density (плотность интеллекта, по собственной метрике PrismML): 1,06/ГБ у Bonsai против 0,10/ГБ у Qwen3 8B — разница в 10,6 раз
• Скорость: 131 ток/с на M4 Pro, 368 ток/с на RTX 4090, 44 ток/с на iPhone 17 Pro Max
• Энергоэффективность: 0,074 мВт·ч/токен на M4 Pro — в 4-5 раз лучше FP16-аналогов

На длинных агентных задачах преимущество ещё заметнее: в демо PrismML Bonsai 8B обработал 50 тикетов за то же время, что обычная 8B-модель — 6.

Три модели семейства

PrismML выпустил три модели разного размера:

• 1-bit Bonsai 8B — 8,2 млрд параметров, 1,15 ГБ. Флагман: рассуждения, вызов функций, генерация кода
• 1-bit Bonsai 4B — ~0,5 ГБ, 132 ток/с на M4 Pro. Баланс скорости и точности
• 1-bit Bonsai 1.7B — 0,24 ГБ, 130 ток/с на iPhone 17 Pro Max. Ультралёгкая модель для мобильных устройств

Все три модели сдвигают Парето-фронт «интеллект vs размер» влево — то есть дают больше возможностей при меньшем объёме.

Зачем это нужно: от дата-центров к устройствам

1-битные модели открывают класс задач, для которых облачные LLM не подходят:

• Приватность — данные не покидают устройство
• Латентность — нет задержки на сетевой запрос
• Автономность — работает офлайн, без интернета
• Стоимость — не нужен облачный GPU
• Роботика и встраиваемые системы — запуск на edge-устройствах с ограниченной памятью

Будущее ИИ определит не тот, кто построит самый большой дата-центр, а тот, кто сможет доставить максимум интеллекта на единицу энергии и стоимости.

Перспектива: специализированное железо

Текущие результаты получены на стандартном потребительском железе, оптимизированном для FP16-арифметики. PrismML отмечает, что выигрыш пока идёт в основном за счёт уменьшения footprint — полноценная оптимизация 1-битного инференса на уровне железа ещё впереди.

В 1-битных моделях умножения в линейных слоях можно заменить сложениями. Специализированные чипы для 1-битного инференса могут дать ещё один порядок ускорения.

Энергия стала главным узким местом для масштабирования ИИ-датацентров. PrismML фундаментально меняет уравнение «мощность/вычисления».

Как попробовать

Модели доступны на Hugging Face под лицензией Apache 2.0. Поддерживаются:

• Apple (Mac, iPhone, iPad) — через MLX
• NVIDIA GPU — через llama.cpp CUDA
• Whitepaper с техническими деталями обучения и оценки доступен на сайте PrismML

Выводы

Мы годами разрабатывали математическую теорию, необходимую для сжатия нейронной сети без потери способности к рассуждению. 1-бит — не конечная точка, а отправная.

1-bit Bonsai — первая серьёзная заявка на то, что 1-битные модели могут быть не компромиссом, а полноценным продуктом. Если результаты бенчмарков подтвердятся независимыми исследователями, это изменит экономику запуска LLM: модель класса 8B, которая помещается в гигабайт и работает на смартфоне, — это другой рынок.

Скачать модели: Hugging Face | Подробности: блог PrismML

Разработчик Nahuel Nucera решил эту проблему: MiniStack — полностью бесплатная замена LocalStack с открытым исходным кодом, которая эмулирует 33 AWS-сервиса на одном порте. И, в отличие от LocalStack, запускает настоящие базы данных и контейнеры вместо мок-заглушек.

MiniStack — бесплатная open-source замена LocalStack (MIT-лицензия)

33 AWS-сервиса на одном порте — S3, SQS, DynamoDB, Lambda, IAM, RDS, ElastiCache, ECS и другие

Реальная инфраструктура: RDS поднимает настоящий Postgres, ElastiCache — настоящий Redis, ECS — Docker-контейнеры

Запуск за 2 секунды, 30 МБ RAM в простое (vs 30 секунд и 500 МБ у LocalStack)

Drop-in совместимость с boto3, AWS CLI, Terraform, CDK, Pulumi

Почему LocalStack стал платным

LocalStack сменил лицензию с Apache 2.0 на Business Source License (BSL) и перенёс ключевые сервисы — S3, SQS, Lambda, IAM, Cognito, EC2 — в платный тир. Бесплатная версия LocalStack Community фактически перестала покрывать базовые сценарии локальной разработки.

Для коммерческих команд LocalStack Pro стоит от $35/мес на разработчика. Для опенсорс-проектов и индивидуальных разработчиков это создало вакуум — и MiniStack его заполнил.

Что умеет MiniStack

MiniStack — это один Python ASGI-сервер, который эмулирует AWS API на порте 4566. Ваши существующие boto3-клиенты, Terraform-провайдеры, CDK-стеки и AWS CLI работают без изменений — достаточно указать endpoint.

33 поддерживаемых сервиса

• Хранилище: S3 (с версионированием, Object Lock, CORS, lifecycle), EBS, EFS
• Очереди и события: SQS (FIFO + DLQ), SNS (fanout в SQS и Lambda), EventBridge, Kinesis, Firehose
• Базы данных: DynamoDB (TTL, транзакции), RDS (реальный Postgres/MySQL), ElastiCache (реальный Redis), Athena (реальный SQL через DuckDB)
• Вычисления: Lambda (реальное исполнение Python, warm pool), ECS (реальные Docker-контейнеры), Step Functions, EMR
• Сеть и безопасность: EC2 (instances, VPC, subnets, security groups), ALB/ELBv2, Route53, Cognito, IAM, STS
• Конфигурация: SSM Parameter Store, Secrets Manager, CloudFormation, Glue Catalog

Реальная инфраструктура, а не заглушки

Главное отличие MiniStack — он поднимает настоящие сервисы там, где это важнее всего:

• RDS — вызов CreateDBInstance с engine=postgres запускает реальный PostgreSQL-контейнер и возвращает настоящий host:port
• ElastiCache — реальный Redis-контейнер, а не in-memory имитация
• ECS — реальные Docker-контейнеры
• Athena — реальный SQL через DuckDB (при наличии)

Это принципиально отличается от подхода LocalStack, который во многих случаях использует стабы — ответы «всё ОК» без реального выполнения.

Сравнение с LocalStack

Ключевые метрики рядом:

• Запуск: MiniStack ~2 сек vs LocalStack ~15–30 сек
• RAM в простое: MiniStack ~30 МБ vs LocalStack ~500 МБ
• Docker-образ: MiniStack 150 МБ vs LocalStack ~1 ГБ
• Лицензия: MiniStack MIT vs LocalStack BSL (ограниченная) / Proprietary ($35+/мес)
• RDS, ElastiCache, ECS: MiniStack — реальные контейнеры бесплатно vs LocalStack — только в Pro

При этом MiniStack совместим с тем же API: endpoint-url, boto3, Terraform, CDK — всё работает без изменения кода.

Как начать

Три способа установки:

Проверка работы:

Для Python-проектов:

Выводы

MiniStack не претендует на полное покрытие всех AWS-сервисов — это задача LocalStack Pro. Но для типичной локальной разработки (S3 + SQS + DynamoDB + Lambda + IAM + RDS) он закрывает 90% потребностей при нулевой стоимости, мгновенном запуске и MIT-лицензии.

Проект активно развивается (947 звёзд на GitHub, версия 1.0.7) и уже привлёк внимание на Hacker News (227+ баллов). Если вы искали замену LocalStack после перехода на платную модель — попробуйте.

Ссылки: GitHub | Сайт | PyPI | Docker Hub

Вы знаете, что a + b * c + d вычисляется как a + (b * c) + d. Но как объяснить это машине? Как закодировать правила приоритета операторов так точно, чтобы парсер сам правильно строил дерево разбора?

Pratt parsing — элегантный алгоритм, придуманный Воном Праттом в 1973 году. Он лежит в основе парсеров многих современных языков, но его описания часто сводятся к магическим таблицам приоритетов без объяснения, почему это работает. Эта статья строит интуицию с нуля.

— AST — основная структура данных: оператор над операндами, вычисление снизу вверх.

— Приоритет операторов определяет наклон дерева: выше приоритет — глубже в дерево.

— При падении приоритета алгоритм поднимается по «хребту» дерева — это и есть суть Pratt parsing.

— Левая и правая ассоциативность задаются через LBP и RBP (left/right binding power).

— Полный парсер с поддержкой всех операторов — около 10 строк на Python.

Абстрактное синтаксическое дерево

Наиболее распространённое решение для разбора выражений — абстрактное синтаксическое дерево (AST, Abstract Syntax Tree). В AST каждый оператор стоит над своими операндами. Вычисление идёт снизу вверх: сначала обрабатываются дочерние узлы, затем операция над ними.

Для выражения a + b * c + d правильное AST выглядит так:

Узел * находится глубже, чем +, — это и отражает более высокий приоритет умножения. При вычислении сначала перемножаются b * c, результат складывается с a, затем прибавляется d.

Как приоритет влияет на форму дерева

Здесь кроется главная интуиция Pratt parsing. Приоритет операторов напрямую определяет, в какую сторону «наклоняется» дерево:

• Убывающий приоритет (например, * + ==) — дерево наклонено влево: операторы с большим приоритетом оказываются глубже.
• Возрастающий приоритет (например, == + *) — дерево наклонено вправо.
• Равный приоритет — по соглашению левая ассоциативность, дерево наклоняется влево.

Рассмотрим промежуточное состояние разбора. Пусть мы уже построили дерево I для выражения (a > b + c * d) — это правонаклонное дерево: > наверху, * в самом низу.

Теперь встречаем следующий оператор. Куда вставить новый узел? Зависит от приоритета:

• [I] * e — приоритет * не меньше приоритета * в дереве, вставляем в самый глубокий узел.
• [I] + e — приоритет + ниже *, но выше >, поднимаемся по хребту выше узла *.
• [I] == e — приоритет == ниже всего дерева, всё дерево I становится левым потомком.

Ключевое наблюдение: когда встречается оператор с меньшим приоритетом, мы поднимаемся по правому хребту дерева, собирая узлы с более высоким приоритетом. Это и есть Pratt parsing — алгоритм, который реализует именно этот подъём по хребту.

От интуиции к коду

Начнём с простого случая — правонаклонного дерева. Каждый оператор правоассоциативен, приоритет не учитывается:

Здесь leaf() читает следующий терминал (число или переменную), peek() смотрит на текущий токен без продвижения, advance() читает и сдвигает позицию.

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

Это уже работает для правоассоциативных операторов. Но у нас if — разобрали один оператор и вышли. Для левоассоциативных нужен цикл:

Полный Pratt parser

Замена if на while — это и есть процедура подъёма по хребту дерева. Цикл продолжается, пока следующий оператор имеет достаточно высокий приоритет, чтобы «захватить» левую часть. Как только приоритет падает — выходим, и текущее поддерево передаётся вверх по стеку вызовов.

Правая ассоциативность через binding power

До сих пор у нас одно число приоритета на оператор. Но для управления ассоциативностью нужно различать, насколько «сильно» оператор притягивает операнды слева и справа. Вводятся два понятия:

• LBP (left binding power) — сила притяжения левого операнда.
• RBP (right binding power) — сила притяжения правого операнда.

Правила ассоциативности через binding power:

• Левоассоциативные операторы (+, *): LBP == RBP. Правый рекурсивный вызов получает тот же приоритет — следующий оператор с таким же приоритетом не захватывается, строится левое дерево.
• Правоассоциативные операторы (**, =): RBP = LBP − 1. Правый рекурсивный вызов получает чуть меньший приоритет — следующий оператор с таким же приоритетом захватывается, строится правое дерево.

Это финальная версия Pratt parser. Всего 8 строк кода — и корректный разбор всех операторов с любым приоритетом и ассоциативностью.

Итог

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

Ключевые детали реализации:

• while вместо if — реализует подъём по хребту для левоассоциативных операторов.
• Передача приоритета в рекурсию — ограничивает, какие операторы «захватываются» на следующем уровне.
• LBP / RBP — контролируют ассоциативность через разницу в единицу.

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

Проблема оказалась не в сети, не в базе и не в нагрузке. Проблема была в одном булевом флаге, который изменил момент открытия пула соединений — и превратил fork() из безопасной операции в мину замедленного действия.

Ключевые выводы:
— fork() копирует память процесса (copy-on-write), но разделяет файловые дескрипторы с ядром
— TCP-сокеты после fork() указывают на один и тот же объект ядра — два процесса пишут в один поток
— threading.Lock ломается: futex-ключ привязан к физическому адресу памяти, который меняется при copy-on-write
— Фоновые потоки пула просто не существуют в дочернем процессе — fork() копирует только вызывающий поток
— Правило: никогда не держите открытые соединения перед fork()

Инцидент — что случилось

За несколько дней до инцидента в конфигурации изменился один флаг. Нужно было, чтобы обработчики сигналов Django регистрировались внутри воркеров Celery. Существующая настройка пропускала регистрацию, если флаг не был установлен в true.

Флаг установили. Сигналы заработали. Фича уехала в прод.

QA был быстрым. Изменение выглядело изолированным: переключить флаг, убедиться, что сигналы регистрируются в Celery, готово. Никто не искал побочных эффектов, спрятанных в AppConfig.ready().

А потом тихо начало выполняться кое-что ещё. Несколько методов AppConfig.ready(), которые теперь стали активны, делали ORM-запросы при старте: создавали расписания периодических задач, проверяли записи crontab. Рутинные вещи. Ничего опасного на вид.

Но эти запросы открыли пул соединений с базой данных. В мастер-процессе. До fork().

Модель конкурентности Celery по умолчанию — prefork. Не потоки, не async-воркеры. Celery использует fork() — системный вызов POSIX — для создания пула рабочих процессов. Эту деталь легко забыть, когда смотришь на код приложения. Но она становится критически важной, когда открываешь соединения с базой при старте.

В этом и была проблема.

Что копирует fork()

Большинство разработчиков знают поверхностный ответ: fork() создаёт дочерний процесс, который является копией родительского. Но слово «копия» скрывает важное различие, которое ядро проводит между двумя типами ресурсов.

Память — copy-on-write

Когда fork() выполняется, ядро не дублирует RAM немедленно. Вместо этого оно помечает таблицы страниц обоих процессов как read-only, указывая на одни и те же физические страницы. Фактическое копирование происходит только когда один из процессов пишет в страницу: ядро перехватывает page fault, выделяет новую физическую страницу, копирует содержимое и обновляет таблицу страниц. До этого момента оба процесса разделяют физическую память, не зная об этом.

Это эффективно. И именно поэтому Python-объекты, включая внутреннее состояние пула соединений, выглядят целыми в дочернем процессе. Дочерний процесс получает свою копию pool._pool, pool._lock, pool._sched. Байты на месте. Структура на месте.

Но некоторые из этих байтов указывают на ресурсы ядра. А ресурсы ядра не копируются.

Файловые дескрипторы — общие

TCP-сокет — это не Python-объект. Это объект ядра: struct file со счётчиком ссылок, за которым стоит struct sock с буферами отправки и получения, состоянием TCP, sequence numbers. Когда fork() выполняется, ядро вызывает dup_fd() для таблицы файловых дескрипторов родителя: каждый открытый fd дублируется в дочерний процесс, а счётчик ссылок на struct file увеличивается.

Оба процесса теперь держат fd=12. Оба указывают на один и тот же объект сокета в ядре. Один TCP-поток, два читателя и два писателя — без координации между ними.

Проводной протокол PostgreSQL — stateful. Он ожидает последовательные пары запрос-ответ в одном потоке. Два процесса, чередующие байты в одном соединении, не создают два независимых разговора. Они создают мусор.

Блокировки — сломанный futex

threading.Lock построен на pthread_mutex_t, который внутри опирается на futex — механизм ядра Linux, использующий физический адрес памяти целого числа как ключ для очереди ожидания. После fork() copy-on-write может переместить страницу дочернего процесса на новый физический адрес при записи. Futex-ключ дочернего процесса расходится с родительским. futex_wake из одного процесса не будит никого в другом.

POSIX явно говорит об этом: поведение мьютекса после fork() не определено, если он не был создан с атрибутом process-shared. Python-овский Lock этот атрибут не использует.

Фоновые потоки — просто не существуют

fork() дублирует только вызывающий поток. Внутренний планировщик пула — отвечающий за поддержание минимального числа соединений, проверки здоровья, уведомление ожидающих — копируется как Python-объект, но не имеет соответствующего потока ОС. Его TID не существует. Любой путь кода, который зависит от его ожидания или сигнализации, заблокируется навсегда.

Дочерние процессы унаследовали пул, который выглядел целым, но был мёртв. Они вызывали pool.getconn(), пытались захватить сломанный лок, ждали 20 секунд notify, который никогда не придёт, и получали таймаут.

Почему пул соединений ломается после fork()

Пул соединений psycopg (ConnectionPool) хранит три вида ресурсов. Каждый ломается по-своему после fork().

TCP-сокеты разделяются на уровне ядра. Любая попытка использовать их из двух процессов одновременно разрушает поток протокола. На практике дочерние процессы до этого даже не доходили.

threading.Lock опирается на futex, привязанный к физическому адресу. После copy-on-write ключ дрейфует. futex_wake будит очередь по старому адресу — никого в дочернем процессе там нет.

Фоновые потоки не существуют в дочернем процессе. Планировщик пула — Python-объект без ОС-потока. Код, зависящий от его notify, блокируется навечно.

Вот почему раньше всё работало:

До изменения флага AppConfig.ready() пропускал регистрацию периодических задач. ORM не вызывался при старте. Нет запросов — нет пула. Нет пула — нечего наследовать. Каждый дочерний процесс начинал с чистого состояния и лениво создавал собственный пул при первом обращении к базе: собственные сокеты, собственный лок, собственный фоновый поток.

Решение — чистый fork без наследства

Два хука сигналов Celery.

worker_before_create_process срабатывает в родительском процессе после ready(), перед каждым fork(). Он закрывает все соединения с базой по всем алиасам и уничтожает пулы соединений. К моменту выполнения fork() нет открытых TCP-сокетов, нет локов, нет фоновых потоков для наследования.

worker_process_init срабатывает в каждом дочернем процессе после fork() как второй уровень защиты — defense-in-depth, на случай если что-то было пропущено.

После обоих хуков каждый дочерний процесс пуст. Первый ORM-запрос создаёт свежий пул, который целиком принадлежит этому процессу.

Принцип простой: никогда не держите открытые соединения перед fork() — или явно закройте и уничтожьте их до форка. Это правило применимо к любому пулу соединений на основе TCP: psycopg, SQLAlchemy, redis-py. Технология не важна. Важно поведение ядра.

Диаграммы — до и после

До изменения флага: чистый fork, каждый воркер создаёт свой пул

После изменения флага: пул открыт в мастере, fork() распространяет повреждение

После исправления: пул уничтожен перед fork(), каждый воркер стартует чисто

Выводы

Настоящий урок — не в конкретном фиксе. Он в понимании того, почему пул сломался. Что fork() на самом деле копирует. Что он разделяет. Почему лок, который выглядит целым, может заблокировать дочерний процесс. Почему поток, существующий как Python-объект, может полностью отсутствовать в ОС.

Правила, которые стоит запомнить:

• Никогда не открывайте пул соединений до fork() — или явно уничтожьте его перед форком
• fork() копирует память (лениво), но разделяет файловые дескрипторы на уровне ядра
• threading.Lock после fork() — undefined behavior: futex привязан к физическому адресу, который дрейфует при copy-on-write
• Фоновые потоки не дублируются — fork() копирует только вызывающий поток
• Это правило касается любого пула TCP-соединений: psycopg, SQLAlchemy, redis-py — поведение ядра одинаково

Невидимая часть — это взаимодействие между последовательностью запуска Django и моделью процессов Celery. Две системы, каждая из которых хорошо понятна по отдельности, делают неожиданное на стыке.

Адаптированный перевод статьи What fork() Actually Copies Даниэля Бастоса (Daniel Bastos).

Независимый разработчик Tom Turney опубликовал метод sparse V dequantization — оптимизацию для инференса LLM с квантизированным KV-кешем. Вместо того чтобы ускорять деквантизацию каждого значения, он предложил пропускать деквантизацию целиком для позиций, где вес внимания пренебрежимо мал. На Apple M5 Max с моделью Qwen 3.5 35B (MoE) метод дал прирост +22,8% к скорости декодирования на контексте 32K токенов. Перплексия осталась неизменной, а точность поиска needle-in-a-haystack выросла с 7/9 до 9/9.

Ключевые выводы

— Узкое место квантизированного KV-кеша — не то, как вы деквантизуете, а то, сколько значений вы деквантизуете.
— При длинном контексте (32K+) более 90% весов внимания пренебрежимо малы — их деквантизацию можно пропустить.
— Метод работает с любой схемой квантизации KV-кеша: TurboQuant, q8_0, q4_0, NVFP4.
— Реализация — 3 строки в ядре flash attention. Не нужно ни переобучение, ни калибровочные данные.
— NIAH-тест улучшился: 9/9 вместо 7/9. Пропуск деквантизации убирает квантизационный шум от позиций, которые ничего не вносят в результат.

Проблема — узкое место деквантизации

Чтобы понять суть открытия, нужно разобраться в контексте. Современные LLM при генерации текста хранят промежуточные вычисления в так называемом KV-кеше (key-value cache). Это массив ключей (K) и значений (V), которые модель использует в механизме внимания — чтобы при генерации каждого нового токена не пересчитывать всю историю диалога.

Проблема: KV-кеш растёт линейно с длиной контекста и при 32K токенов занимает гигабайты памяти. Решение — квантизация: сжатие значений из 16-битного формата в 3-4 бита. TurboQuant от Google (ICLR 2026) сжимает KV-кеш в 4,6 раза с потерей перплексии всего ~1%. Но при декодировании каждый сжатый блок нужно деквантизовать — преобразовать обратно в числа с плавающей точкой. И на длинных контекстах это становится узким местом.

На Apple M5 Max деквантизация TurboQuant занимает 14-34% времени декодирования. На контексте 32K токенов скорость декодирования падает с 78,3 tok/s (потолок без деквантизации) до 47,0 tok/s — штраф в 40%.

14 попыток, которые провалились

Прежде чем найти решение, Turney перебрал 14 альтернативных реализаций деквантизации на Apple Silicon: регистровые массивы, битовую арифметику, SIMD-шаффлы, FMA без ветвлений, слитые блочные операции. Ни одна не обогнала базовую таблицу подстановки (LUT) в константной памяти GPU.

Вывод оказался фундаментальным: на Apple Silicon 4 дивергентных чтения из константной памяти быстрее любой арифметики, которая даёт тот же результат. Это аппаратный пол — ниже него не опуститься. Единственный оставшийся рычаг — уменьшить количество позиций, которые нужно деквантизовать.

Решение — не ускорять, а пропускать

Ключевое наблюдение: в flash attention ядре веса внимания (softmax) вычисляются из ключей (K) до того, как начинается работа со значениями (V). То есть на момент деквантизации V мы уже знаем, какие позиции контекста получили значимый вес внимания, а какие — нет.

Что такое разреженность внимания? Когда модель генерирует следующий токен, механизм внимания (softmax) распределяет вероятность по всем предыдущим позициям контекста. При коротком контексте внимание распределено относительно равномерно. Но чем длиннее контекст, тем более концентрированным оно становится: модель «смотрит» на несколько десятков ключевых позиций, а 90%+ получают веса ниже 10-6 — они практически ничего не вносят в итоговый результат.

Sparse V dequantization использует этот факт: если вес внимания для позиции ниже порога (10-6), её деквантизация и аккумуляция пропускаются целиком.

Вся реализация — три строки в Metal-ядре:

Это экономит чтения из константной памяти (обращения к LUT), ALU-операции (извлечение индексов, применение знака, умножение на норму) и чтения из глобальной памяти устройства.

Принципиальное отличие от 14 провалившихся подходов: они пытались сделать каждую из N операций быстрее (ограничено аппаратным полом). Sparse V убирает (1-p) x N операций целиком — и выигрыш растёт с длиной контекста, потому что разреженность внимания растёт.

Результаты

Скорость декодирования (M5 Max, Qwen 3.5 35B MoE)

Эффект sparse V масштабируется с длиной контекста — чем длиннее контекст, тем больше позиций пропускается:

• Короткий контекст: +1,4% (внимание плотное, мало что пропускать)
• 4K: +4,0%
• 8K: +7,2%
• 16K: +12,9%
• 32K: +22,8% (с 47,0 до 57,7 tok/s)

При 32K токенов отношение к несжатому q8_0 улучшилось с 0,76x до 0,93x — почти паритет.

Качество: перплексия и retrieval

Перплексия при включении sparse V остаётся численно идентичной варианту без него. На корпусе wikitext-103 (50 чанков, контекст 32K, CI +/-0.021) дельта составила ровно 0,0000. Это подтверждено на всех протестированных длинах контекста: 8K, 16K, 32K.

Ещё более неожиданный результат — в тесте needle-in-a-haystack (NIAH). Этот тест проверяет, может ли модель найти конкретный факт, спрятанный в длинном контексте:

• Без sparse V: 7/9 (q8_0 тоже 7/9)
• С sparse V: 9/9 (100%)

Гипотеза автора: позиции с пренебрежимо малым весом внимания вносят практически нулевой полезный сигнал, но при деквантизации добавляют квантизационный шум. Sparse V убирает этот шум — и соотношение сигнал/шум улучшается.

Почему это работает для любой квантизации

Sparse V работает не на уровне конкретного формата квантизации, а на уровне механизма внимания. Метод использует веса softmax как сигнал для пропуска вычислений — а softmax одинаков вне зависимости от того, как именно сжаты K и V.

Автор валидировал метод на трёх форматах KV-кеша с разной стоимостью деквантизации:

• turbo3 (3,5 бита, TurboQuant) — +22,8% на 32K, перплексия без изменений
• q8_0 (8 бит) — +5% к декодированию, перплексия идентична
• q4_0 (4 бита) — перплексия идентична, скорость в пределах шума

Закономерность: чем дороже деквантизация, тем больше выигрыш. turbo3 использует Walsh-Hadamard-преобразование и полярную декомпозицию — тяжёлые операции, поэтому выигрыш максимален. q4_0 использует простое масштабирование — пропуск дешёвой операции даёт мало. Но в обоих случаях метод не ухудшает ни перплексию, ни retrieval.

Это означает, что sparse V можно включить по умолчанию для любого формата квантизации KV-кеша в llama.cpp — как безусловную оптимизацию, которая ничего не стоит на коротком контексте и даёт ощутимый выигрыш на длинном.

FAQ

Не сломает ли пропуск позиций качество генерации?

Нет. Порог 10-6 выбран консервативно. При контексте 32K с 32 головами внимания вклад пропущенной позиции в итоговый вектор — менее одной миллионной от максимума. Перплексия во всех экспериментах осталась численно идентичной — дельта 0,0000 на 50 чанках wikitext-103.

Почему нельзя пропускать и K-деквантизацию?

Потому что K нужен для вычисления весов внимания. Чтобы узнать, какие позиции имеют пренебрежимо малый вес, нужно сначала деквантизовать все ключи и посчитать softmax. Автор отмечает это как направление будущей работы: двухпроходный механизм, где первый проход вычисляет приблизительные веса для фильтрации K-позиций.

Работает ли это на NVIDIA GPU?

Эксперименты проводились на Apple Silicon (M5 Max, M2 Pro). Реализация — Metal-ядро для llama.cpp. На CUDA профиль узкого места другой (NVIDIA использует тензорные ядра и HBM вместо unified memory), но сам принцип — пропуск работы для позиций с малым весом внимания — универсален. Портирование на CUDA и ROCm автор указывает как следующий шаг.

Выводы

Sparse V dequantization — элегантное решение, которое меняет вопрос с «как деквантизовать быстрее?» на «нужно ли деквантизовать вообще?». Метод использует информацию, которая уже есть в ядре flash attention — веса softmax — как бесплатный сигнал для пропуска вычислений.

Главная ценность подхода — не конкретный прирост в 22,8%, а более широкая идея attention-aware computation: использование собственных паттернов разреженности модели для оптимизации ядер инференса. Чем длиннее контекст, тем сильнее разреженность — и тем больше выигрыш. Именно при тех длинах контекста, где узкое место деквантизации наиболее болезненно.

Код и бенчмарки: TheTom/turboquant_plus (бенчмарки и диагностика), TheTom/llama-cpp-turboquant (реализация, ветка experimental_decode_speed_tests).

Обсуждение на r/LocalLLaMA.

Источник: Sparse V Dequantization — документация turboquant_plus.

Он опубликовал 113 уроков, которые вынес из этого опыта. Мы отобрали самые ценные, сгруппировали по темам и адаптировали для русскоязычной аудитории. Каждый урок — практический: его можно взять и применить в своём проекте уже сегодня.

Ключевые выводы

— Кэширование — последняя мера. Сначала исправьте модель данных, индексы и N+1-запросы.
— E2E-тесты на happy path дают в 10 раз больше отдачи, чем юнит-тесты на отдельные методы.
— Доведите Sentry до inbox zero — это единственный самый мощный шаг для качества продукта.
— Не обвиняйте конкретного разработчика за баг в проде: это всегда каскад из 3+ ошибок системы.
— Деплой за 2 минуты вместо 28 — достижимо, и это меняет культуру принятия решений.

Про архитектуру и масштабирование

Используйте сервисные объекты вместо раздувания моделей

В фреймворках, где модели строятся вокруг существительных (Product, User, Auction), логика неизбежно скапливается в этих классах. Со временем каждый из них превращается в монстра на тысячи строк. Решение — выносить процессы в отдельные сервисные объекты: PlaceAuctionBidService, ProductBillingService. Суть — перестать мыслить существительными и начать мыслить глаголами.

Одна и та же вещь, реализованная дважды — провал технического лидерства

Если в кодовой базе есть два разных клиента к одному платёжному провайдеру, три файла с функциями для работы с датами или дублирующиеся UI-компоненты — это симптом отсутствия ответственного за архитектуру. Создавайте очевидные, легко находимые места для общего кода (common/datetime.py, common/geo.py) и отмечайте переиспользуемый код на ревью.

Полиморфные связи в БД — почти всегда ошибка

ORM-код для полиморфных отношений становится крайне запутанным, и вы теряете защиту через foreign key constraints. Проще добавить nullable FK для каждой связанной модели и написать абстракции на уровне запросов.

Дефолтные фильтры и сортировки в ORM — всегда ошибка

Скрытые дефолты вроде order_by('-id') или filter(is_deleted=False) становятся миной замедленного действия, когда в команде 20+ человек. Новый разработчик не знает про неявное поведение — и получает баг. А скрытый ORDER BY портит аналитические запросы, потому что ORM добавляет ключ сортировки в SELECT.

Вся инфраструктура — в коде

Когда Джек пришёл в MorphMarket, все 27 крон-задач были настроены вручную на продакшн-сервере. Большинство отсутствовали на staging. Перенос в код (а затем конфигурация AWS/Heroku/CloudFlare/Sentry через Terraform) сделал все окружения похожими друг на друга — и, что важно, сделал инфраструктуру доступной для чтения AI-агентам.

Про тестирование

E2E > интеграционные > юнит-тесты

Пользователям важно, чтобы система работала целиком. Один E2E-тест на happy path каждой ключевой фичи (регистрация, покупка, создание листинга) даёт на порядок больше уверенности, чем десятки юнит-тестов. Детали дорабатывайте интеграционными и юнит-тестами — они быстрее и проще в поддержке.

Автоматические тесты для шаблонных фич

В MorphMarket написали систему, которая автоматически тестирует около 300 админ-страниц: парсит имя страницы, находит фабрику, создаёт запись в БД и проверяет, что страница открывается. Тот же подход можно применить к любому CRUD-эндпоинту без выделенного теста.

Изолируйте тесты полностью

Хрупкость тестов убивает мотивацию команды. Основные ловушки:

• Всё, что связано со временем — замораживайте или мокайте
• Фиксируйте seed для всех источников случайности — в каждой библиотеке
• Запретите реальные HTTP-запросы в не-E2E тестах (используйте VCR-подобные библиотеки)
• Отдельный Redis для тестов с автоочисткой перед каждым тестом
• Тестовая среда не должна читать ни одной переменной из вашего .env

Мокайте только внешние объекты

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

CI должен проверять не только ошибки, но и раздражающие мелочи

В MorphMarket CI также ловит новые warning-и в тестах, рассинхронизацию SDK с бэкендом и забытые миграции в Django. Чем раньше замечена мелочь, тем дешевле её исправить.

Про отладку и мониторинг

Sentry до inbox zero — самый мощный шаг к качеству

Когда Джек пришёл в компанию, Sentry показывал 1 000 ошибок в час. После агрессивной фильтрации (игнор старых браузеров, расширений, пометка JavaScript-ошибок уникальным идентификатором) и починки реальных багов — меньше 1 ошибки в час. Результат: каждая новая ошибка стала событием, на которое команда реагирует немедленно.

Dead Man Switch — мониторьте то, что должно происходить

Исключения шумят и легко ловятся. А вот отсутствие события — нет. Если крон-система перестала работать или бэкапы БД не снимаются — вы узнаете об этом только через heartbeat-мониторы. Настройте их.

Username в каждой строке лога

По умолчанию в логах — только IP-адрес. Но IP ротируется, создаёт лишнее перенаправление при дебаге и не показывает картину при использовании нескольких устройств. Поместите текущий запрос в thread-local и добавьте username в каждую запись.

Трипвайр-алерты на 20 самых важных эндпоинтов

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

Громко падайте при ошибках

Не глушите исключения except: pass. Паттерн от Джека: крашиться локально, мягко отказывать в проде — но всегда отправлять ошибку в Sentry/логи. Чем раньше заметили — тем меньше ущерб.

Про работу в команде

Не обвиняйте одного человека за баг в проде

Любой инцидент — это каскад минимум трёх провалов: автор не заметил, ревьюер пропустил, QA не покрыло, тесты не проверили, архитектура допустила класс ошибки. Обвинение одного человека мешает команде видеть системные причины.

Все разработчики должны быть немного фулстек

В MorphMarket убрали строгое деление на фронтенд/бэкенд/ops. Переобучение заняло год, но окупилось: фронтендер добавляет поле в БД сам, а не ждёт бэкендера — это сокращает время доставки фич.

Пятницы технического долга

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

Запретите длинные PR

В MorphMarket был период, когда PR висели по 3 месяца и накапливали тысячи изменений. Их невозможно ревьюить, они конфликтуют с master и создают огромный деплой-риск. Новое правило: мерж в master каждые 1–2 дня, максимум — раз в неделю. Побочный эффект: старшие разработчики дают фидбэк раньше, и драматические переписывания случаются реже.

Поощряйте общение в удалённых командах

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

Про производительность

N+1-запросы — враг номер один в ORM

Проблема проявляется на крупных эндпоинтах, которые постепенно расширяют разные авторы: новые фильтры и параметры создают спорадические N+1, которые возникают только при определённом сочетании фильтров и объёме данных. Настройте APM (например, New Relic) для автоматического обнаружения N+1 и обучите команду ловить их на ревью.

Кэширование — последняя мера

Код кэширования чудовищно сложен в поддержке. Сначала исправьте модель данных, допишите индексы, уберите N+1, оптимизируйте алгоритмы. И только после этого — кэш. Джек рассказывает о случаях, когда наивный кэш работал на малых объёмах, но убивал Redis (он однопоточный!) при росте данных на два порядка.

Таймауты на всех уровнях — иммунная система сервиса

Веб-запрос должен завершиться за 25 секунд — иначе убивается. Да, для длинных задач придётся использовать фоновые задачи, но без таймаутов одна тормозящая внешняя API может съесть все потоки сервера и уронить всё.

Выгружайте работу в фоновые задачи

Отправка email, push-уведомления, обработка вебхуков от платёжных систем — всё это должно уходить в очередь. Веб-процесс обязан оставаться быстрым.

ORDER BY id вместо ORDER BY created

Если поле created неизменяемо и совпадает по порядку с id — сортируйте по id. Индекс на id уже есть бесплатно в каждой таблице.

Удаляйте ненужные данные

В MorphMarket некоторые таблицы копили 10 лет данных — логи IP-адресов, записи push-уведомлений, сообщения девятилетней давности. Скрипт очистки делает эти таблицы компактнее и быстрее.

Про безопасность и надёжность

Начните с модели угроз: что может получить атакующий?

Для MorphMarket основные вектора: захват аккаунтов (фикс — обязательный 2FA), спам-фишинг (капча на регистрации + фильтры сообщений), DDoS (Cloudflare + rate limit на nginx + кэш ключевых эндпоинтов). Универсального подхода нет — каждый сервис должен понимать свою специфику.

CHECK-ограничения в БД — лучше предотвратить, чем чинить

Раньше в MorphMarket крон-задача раз в сутки проверяла целостность данных и слала алерты. Всё заменили на CHECK constraints на уровне БД — некоторые проверяют до 16 операций над разными колонками. Невалидные данные просто не могут быть записаны.

Вебхуки — рассадник race conditions

Действие в коде может вызвать вебхук, который прилетит быстрее, чем данные запишутся в БД. Получатель вебхука прочитает устаревшее состояние и может затереть свежие данные. Решение: откладывайте действия, вызывающие вебхуки, до on_commit в БД.

Логируйте намерение перед побочным эффектом — особенно для платежей

Перед списанием с карты или возвратом пишите в лог: "bill user XYZ $100 for Y". Простой Write-Ahead Log спасал MorphMarket в нескольких инцидентах.

Про деплой

Деплой должен быть быстрым — действительно быстрым

MorphMarket сократил деплой с 28 минут до 2. Как: разделили фронтенд и бэкенд, распараллелили, перешли на Rust-based компиляцию JS, вынесли сборку на мощные машины (MacBook M-series вместо commodity Heroku), убрали из слага всё ненужное, почистили старые ассеты из S3.

Smoke-тест после каждого деплоя в прод

Автоматическая проверка ключевых страниц через Playwright после каждого деплоя. Если последние 150 деплоев были скучными — соблазн перестать проверять вручную огромен. Автоматический smoke-тест не устаёт и не теряет бдительность.

Не деплойте ничего рискованного в пятницу

Баг может проявиться вечером или в субботу, когда никого нет. Мелкие хотфиксы и изменения в админке — можно. Всё остальное — до четверга.

Плейбук для инцидентов при деплое

Короткие инструкции: как убить залипшие соединения к БД, точечно почистить кэш (без flush, который разлогинит всех), форсировать обновление ассетов. Обученная команда сокращает даунтайм в разы.

Про карьерный рост — от тимлида до CTO

Научитесь говорить о производительности сотрудников

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

Документ ожиданий от сотрудника

Если написать "мы ценим, когда вы решаете проблемы в #bug-discussion до того, как они дойдут до CTO", люди действительно начнут так делать. Мотивированный сотрудник хочет ясности. Он не может прочитать ваши мысли.

Одно крупное изменение за раз

Внедряете E2E-тесты? Доведите до стабильности, прежде чем браться за линтеры. Если система сделана плохо — команда не будет ей доверять и не будет использовать. Плюс есть предел того, сколько изменений люди могут усвоить одновременно.

CLI-инструменты + AI = максимальный рычаг

AI отлично работает с текстом. CLI-инструменты тоже. Дайте AI доступ к продакшн-логам, отчётам об ошибках, read-only реплике БД, CI-результатам и REPL — и получите огромный множитель продуктивности. Джек называет это "наблюдаемость через CLI — ваш главный усилитель для AI".

FAQ

Почему монолит, а не микросервисы?

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

С чего начать, если в проекте уже бардак?

С Sentry до inbox zero и таймаутов на веб-запросы. Первое даёт видимость реальных проблем, второе предотвращает каскадные отказы. Дальше — по статье: N+1, изоляция тестов, сервисные объекты.

Насколько эти уроки применимы за пределами Django?

Джек 17 лет работал с Rails, Laravel, Express и другими фреймворками — и подчёркивает, что большинство уроков переносимы. N+1, дефолтные сортировки, race conditions в вебхуках, инфраструктура как код — всё это не привязано к конкретному стеку.

Правда ли, что E2E-тесты лучше юнит-тестов?

Не лучше, а дают больше отдачи на первом этапе. Один E2E-тест на happy path покрывает весь стек. Юнит-тесты нужны для деталей и граничных случаев, но начинать покрытие лучше сверху вниз.

Выводы

113 уроков Джека Кинселлы — это не теория из книг, а выжимка из 7 лет ежедневной работы над монолитом, который обслуживает реальных пользователей. Главные принципы:

• Предотвращайте, а не чините — CHECK constraints, таймауты, линтеры
• Делайте невидимое видимым — логи, мониторинг, Sentry до inbox zero
• Инвестируйте в скорость обратной связи — быстрый деплой, быстрый CI, короткие PR
• Доверяйте людям и системе, а не контролю — fullstack-навыки, плейбуки, документ ожиданий

Оригинальная статья: Scaling a Monolith to 1M LOC: 113 Pragmatic Lessons from Tech Lead to CTO (Semicolon & Sons, Jack Kinsella).

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

Именно это произошло на неделе 24–28 марта 2026 года. Три популярных пакета на PyPI — LiteLLM, telnyx и Trivy — оказались скомпрометированы одной и той же группировкой. Разбираемся, как это работает, чем грозит и как защититься.

Supply chain атака (атака на цепочку поставок) — это тип кибератаки, при котором злоумышленник внедряет вредоносный код не напрямую в вашу систему, а через доверенную зависимость: библиотеку, инструмент или сервис, который вы уже используете. Вместо того чтобы взламывать ваш сервер, атакующий компрометирует то, что вы сами устанавливаете. Это особенно опасно, потому что такие пакеты проходят через все ваши проверки — они же «легитимные».

Ключевые выводы

— За одну неделю скомпрометированы три крупных пакета: litellm (версии 1.82.7 и 1.82.8), telnyx (версии 4.87.1 и 4.87.2) и Trivy (сканер уязвимостей от Aqua Security).
— Все атаки связаны с группировкой TeamPCP: совпадают RSA-ключ шифрования, схема эксфильтрации и имя архива tpcp.tar.gz.
— Вредоносный код крал SSH-ключи, токены облачных провайдеров (AWS, GCP, Azure), секреты Kubernetes, файлы криптокошельков и переменные окружения.
— LiteLLM — самый агрессивный вариант: латеральное перемещение по кластерам K8s и установка персистентного бэкдора через systemd.
— telnyx использовал стеганографию: вредоносный бинарник был спрятан внутри WAV-файла.
— Вектор первоначальной атаки — компрометация Trivy, через который были украдены PyPI-токены из CI/CD пайплайнов.

Хронология атак

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

1. Март 2026, начало месяца — Trivy. Группировка TeamPCP скомпрометировала apt-репозиторий сканера уязвимостей Trivy от Aqua Security. Отравленный бинарник Trivy, установленный в CI/CD пайплайнах, начал красть секреты раннеров — в том числе токены для публикации на PyPI.
2. 24 марта 2026, 10:52 UTC — LiteLLM. На PyPI появляется версия litellm 1.82.8 с вредоносным .pth-файлом. Пакет крадёт учётные данные, перемещается по кластерам Kubernetes и устанавливает бэкдор. Чуть ранее вышла версия 1.82.7 с менее агрессивным вариантом — без .pth-файла, но с таким же пейлоадом в коде прокси-сервера.
3. 27 марта 2026 — telnyx. Публикуются версии telnyx 4.87.1 и 4.87.2. Вредоносный код внедрён в _client.py. Используется новая техника доставки — стеганография в WAV-файлах. Версия 4.87.1 содержит баг (опечатка в регистре Setup() вместо setup()), версия 4.87.2 исправляет его.

Ни одна из вредоносных версий не имела соответствующего тега или релиза в GitHub-репозитории. Пакеты были загружены напрямую на PyPI с помощью украденных токенов, минуя стандартный CI/CD-процесс.

LiteLLM — подробный разбор

LiteLLM — популярная Python-библиотека от BerriAI, которая предоставляет единый интерфейс к более чем 100 провайдерам LLM: OpenAI, Anthropic, Google, Azure и другим. Она широко используется в AI-стартапах, MCP-плагинах и продакшн-системах. Именно поэтому компрометация этого пакета особенно опасна — он часто оказывается в окружениях с доступом к критическим секретам.

Как работал вредоносный код

Атака использовала малоизвестную особенность Python — файлы .pth (path configuration files). Модуль site обрабатывает их при каждом запуске интерпретатора: строки, начинающиеся с import, передаются в exec(). Это значит, что вредоносный код выполнялся при любом запуске Python в окружении, где был установлен litellm — не только при импорте библиотеки.

Файл litellm_init.pth (34 628 байт) содержал одну строку:

Эта строка запускала фоновый процесс через Popen, который декодировал и выполнял трёхуровневый вредоносный пейлоад.

Три стадии атаки

Стадия 1 — оркестратор (25 844 байта). Содержал захардкоженный RSA-4096 публичный ключ и ещё один base64-закодированный блоб с логикой сбора данных. Управлял шифрованием и отправкой украденных данных.

Стадия 2 — коллектор (17 281 байт). Собирал:

• SSH-ключи всех типов (RSA, Ed25519, ECDSA, DSA) со всех пользователей системы
• Переменные окружения и .env-файлы
• Учётные данные AWS, GCP, Azure — включая активную эксплуатацию через AWS SigV4 для дампа Secrets Manager и SSM Parameter Store
• Конфигурации Kubernetes и секреты из всех namespace
• Файлы криптокошельков: Bitcoin, Ethereum, Solana, Litecoin, Dogecoin, Zcash и другие
• Историю shell, .gitconfig, пароли баз данных

Стадия 3 — персистентность (1 125 байт). Устанавливал бэкдор, замаскированный под «System Telemetry Service»:

Домен checkmarx.zone имитировал известную компанию Checkmarx, работающую в сфере безопасности приложений.

Латеральное перемещение по Kubernetes

Самая агрессивная часть атаки — распространение по кластерам Kubernetes. Если на скомпрометированной машине был доступен токен сервисного аккаунта K8s, вредонос создавал привилегированный pod на каждом узле кластера:

Поды именовались node-setup-* в пространстве имён kube-system, чтобы выглядеть легитимно. Каждый под монтировал корневую файловую систему хоста, получал доступ к PID и сети хоста и через chroot устанавливал персистентный бэкдор непосредственно на узел.

Шифрование и эксфильтрация

Украденные данные шифровались по гибридной схеме: случайный 32-байтный ключ AES-256-CBC для данных, затем сам ключ шифровался RSA-4096 (OAEP). Архив отправлялся POST-запросом на домен models.litellm.cloud — он был зарегистрирован 23 марта 2026 года, за день до публикации вредоносных пакетов, и не является частью легитимной инфраструктуры LiteLLM.

Побочный эффект — из-за того, что .pth-файл срабатывал при каждом запуске интерпретатора, дочерний процесс снова запускал тот же .pth, создавая экспоненциальную fork-бомбу. Именно так компрометацию и обнаружили: один из инженеров FutureSearch заметил, что машина упала после установки litellm как транзитивной зависимости MCP-плагина в Cursor.

telnyx — стеганография в WAV-файлах

telnyx — официальный Python SDK для телекоммуникационной платформы Telnyx, используемый для программной телефонии, SMS и работы с сетью. Пакет загружается более миллиона раз в месяц (~30 000 в день), что делает его компрометацию особенно масштабной.

Вектор атаки

Как и в случае с LiteLLM, GitHub-репозиторий telnyx не был скомпрометирован. Все недавние коммиты принадлежат stainless-app[bot] — боту платформы Stainless, которая генерирует SDK. Ни версия 4.87.1, ни 4.87.2 не имеют соответствующих тегов или релизов в GitHub.

Ключевое доказательство — отпечаток инструмента загрузки. Легитимный CI-пайплайн использует rye publish, а метаданные PyPI для вредоносных версий показывают twine/6.2.0 CPython/3.14.3. Злоумышленник загрузил пакеты вручную, используя украденный API-токен.

Репозиторий не использовал PyPI Trusted Publishers (OIDC), которые привязывают загрузку к конкретному репозиторию и workflow. Без этой защиты украденный токен позволяет загрузить любую версию с любой машины.

Стеганография в WAV-файлах

Главное нововведение этой атаки — доставка пейлоада через аудиофайлы. При импорте модуля telnyx вредоносный код скачивал WAV-файл с C2-сервера и извлекал из аудиоданных скрытый исполняемый файл:

Этот подход позволяет обойти сетевые инструменты инспекции трафика: WAV-файл выглядит как обычный аудиоконтент, а сам пейлоад закодирован в base64 и XOR-шифрован внутри аудиоданных.

Два вектора атаки

Вредоносный код содержал два независимых пути — для Windows и для Linux/macOS.

Windows — функция setup() скачивала WAV-файл hangup.wav, извлекала из него бинарник и сохраняла как msbuild.exe в папку автозагрузки Windows (директория Startup в %APPDATA%). Имя файла имитировало легитимный Microsoft Build Engine. Для предотвращения повторных загрузок использовался скрытый lock-файл с 12-часовым таймаутом.

Linux/macOS — функция FetchAudio() скачивала ringtone.wav, декодировала из base64-переменной _p скрипт сбора учётных данных и запускала его в фоновом процессе. Скрипт собирал те же категории данных, что и в атаке на LiteLLM, шифровал их AES-256-CBC + RSA-4096 и отправлял через HTTP POST.

Любопытная деталь: версия 4.87.1 содержала баг — вызов Setup() с заглавной буквой при определении def setup() со строчной. NameError прерывал выполнение модуля, и ни один из векторов атаки не работал. Версия 4.87.2 исправляла опечатку.

Trivy — когда сканер безопасности сам становится угрозой

Trivy — популярный open source сканер уязвимостей от Aqua Security, который проверяет контейнеры, файловые системы и Git-репозитории. Он широко используется в CI/CD пайплайнах для автоматического поиска уязвимостей перед деплоем.

Именно Trivy стал точкой входа для всей цепочки атак. TeamPCP скомпрометировала apt-репозиторий Trivy и подменила бинарник. Когда CI-раннеры устанавливали Trivy без фиксации версии, они получали отравленную сборку:

Отравленный Trivy с полными привилегиями CI-раннера собирал секреты окружения, включая PYPI_PUBLISH_PASSWORD. Эти украденные токены затем использовались для публикации вредоносных версий LiteLLM и telnyx напрямую на PyPI.

Мейнтейнер LiteLLM подтвердил связь с Trivy на Hacker News. Ирония ситуации в том, что инструмент, призванный защищать от уязвимостей, сам стал вектором атаки.

Кто за этим стоит — группа TeamPCP

Все три атаки атрибутированы одной группировке — TeamPCP. Атрибуция основана на трёх совпадающих индикаторах:

1. Идентичный RSA-4096 публичный ключ. Ключ шифрования в пейлоаде telnyx побайтово совпадает с ключом из litellm 1.82.8. Расшифровать данные может только владелец соответствующего приватного ключа.
2. Имя архива tpcp.tar.gz и HTTP-заголовок X-Filename: tpcp.tar.gz. Используются в обеих атаках при эксфильтрации. «TPCP» — сокращение от TeamPCP.
3. Идентичная схема шифрования. Одинаковая последовательность команд openssl: генерация случайного ключа, шифрование AES-256-CBC, шифрование ключа через RSA OAEP — одни и те же вызовы в обоих пейлоадах.

При этом атакующие активно развивают инструментарий: LiteLLM использовал скомпрометированный домен (models.litellm.cloud) для C2, telnyx — голый IP-адрес (83.142.209.203). Стеганография в WAV-файлах — новая техника, не встречавшаяся в атаке на LiteLLM.

Как защититься

Если вы используете любой из скомпрометированных пакетов — действуйте немедленно. Вот практический чеклист:

1. Проверьте версии зависимостей. Запустите pip show litellm и pip show telnyx во всех ваших окружениях, включая CI/CD раннеры и Docker-образы.
2. Удалите скомпрометированные версии и очистите кеш. Удалите пакеты и выполните pip cache purge или rm -rf ~/.cache/uv, чтобы закэшированные wheel-файлы не установились повторно.
3. Проверьте признаки персистентности. Ищите ~/.config/sysmon/sysmon.py и ~/.config/systemd/user/sysmon.service. В Kubernetes — поды node-setup-* в kube-system. На Windows — файл msbuild.exe в папке Startup.
4. Ротируйте все секреты. SSH-ключи, токены облачных провайдеров, ключи API из .env, пароли БД, токены PyPI — всё, что присутствовало в скомпрометированном окружении.
5. Фиксируйте версии зависимостей. Используйте lock-файлы: pip freeze, uv lock, poetry.lock.
6. Включите PyPI Trusted Publishers. Привяжите публикацию пакетов к конкретному GitHub-репозиторию и workflow через OIDC. Украденные токены станут бесполезными.
7. Проверяйте хеши пакетов. Используйте флаг --require-hashes при установке через pip или аналогичные механизмы в uv и poetry.
8. Настройте мониторинг зависимостей. Инструменты вроде SafeDep vet, pip-audit или Socket помогут обнаружить вредоносные пакеты до попадания в продакшн.

Пример фиксации хешей с pip:

Пример фиксации с uv:

FAQ

Как понять, что мой проект затронут?

Проверьте установленные версии: pip show litellm и pip show telnyx. Если у вас litellm 1.82.7 или 1.82.8, либо telnyx 4.87.1 или 4.87.2 — вы затронуты. Также проверьте кеш пакетного менеджера: для uv поищите файл litellm_init.pth в ~/.cache/uv. Наличие этого файла — признак компрометации.

Достаточно ли просто обновить пакет?

Нет. Если вредоносная версия была установлена, одного обновления недостаточно. Вредонос мог уже установить персистентный бэкдор (~/.config/sysmon/sysmon.py), украсть секреты или создать привилегированные поды в Kubernetes. Необходимо провести полный аудит: проверить систему на признаки персистентности, ротировать все секреты и очистить кеш пакетного менеджера.

Работает ли вредоносный код в Docker-контейнерах?

Да. .pth-файл из litellm срабатывает при любом запуске Python в контейнере, где установлен пакет. Более того — если в контейнере доступен Kubernetes service account token (что является стандартной конфигурацией), вредонос может выйти за пределы контейнера и скомпрометировать весь кластер.

Как TeamPCP получила токены PyPI?

Через скомпрометированный Trivy. CI/CD пайплайны LiteLLM и, вероятно, telnyx устанавливали Trivy из apt-репозитория без фиксации версии. Когда TeamPCP подменила бинарник в репозитории, отравленный Trivy с привилегиями CI-раннера извлёк секреты окружения — в том числе токены для публикации на PyPI. Репозиторий telnyx не использовал Trivy, поэтому точный вектор получения его токена пока не установлен, но паттерн атаки идентичен.

Можно ли было обнаружить атаку до установки?

Да, при наличии правильных инструментов. Отсутствие соответствующего GitHub-тега для опубликованной версии, изменение инструмента загрузки (twine вместо rye publish), появление .pth-файла в wheel — всё это детектируемые аномалии. Инструменты типа SafeDep vet умеют проверять пакеты на подобные сигналы. Также помогает проверка хешей через --require-hashes.

Выводы

Волна атак TeamPCP демонстрирует новый уровень supply chain атак: это не тайпсквоттинг и не подмена малоизвестных пакетов. Атакующие компрометируют инфраструктуру публикации настоящих, широко используемых библиотек — и делают это через цепочку доверия. Trivy ломает CI/CD, CI/CD отдаёт PyPI-токены, PyPI-токены используются для публикации троянизированных пакетов.

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

Три ключевых урока из этой истории:

1. Фиксируйте версии всего — не только библиотек, но и инструментов в CI/CD. apt-get install trivy без версии — это приглашение для атакующего.
2. Используйте Trusted Publishers — PyPI OIDC привязывает публикацию к конкретному репозиторию. Украденный токен без workflow бесполезен.
3. Мониторьте аномалии — отсутствие GitHub-тега для PyPI-версии, смена upload tool, появление .pth-файлов — всё это сигналы компрометации.

Источники: SafeDep — анализ litellm, SafeDep — анализ telnyx, FutureSearch — обнаружение litellm, GitHub Advisory litellm #24512.

Distance-Engagement Oscillation (DEO) — это метод промптинга, основанный на теории перцептивного рефрейминга (Perceptual Reframing Theory, PRT). Рефрейминг — это способность посмотреть на проблему под другим углом, сменив «рамку» восприятия. DEO заставляет языковую модель чередовать два когнитивных режима: аналитическую дистанцию (анализ проблемы со стороны) и эмоциональное вовлечение (проживание проблемы изнутри). Автор метода — Гёкхан Гёкмен из Технического университета Бурсы.

Результаты эксперимента на трёх open-source LLM показали: DEO-промптинг повышает качество креативного мышления модели на 40–55% по сравнению с обычными промптами. Эффект подтверждён тремя независимыми оценщиками с размером эффекта Cohen's d от 1.29 до 1.63 («очень большой»).

Главное:
— DEO-промптинг улучшает креативное мышление LLM на 40–55% (Cohen's d = 1.29–1.63)
— Предсказанный порядок DEO > Distance > Engagement ≥ Vanilla подтвердился во всех 9 комбинациях модель×оценщик (p < .001)
— Метод работает без дообучения — только через структуру промпта
— Тестировалось на Llama 3.3 70B, Qwen3 32B и Llama 4 Scout
— Код и данные открыты на GitHub под лицензией CC BY 4.0

Как работает DEO-промптинг

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

DEO использует четыре шага, чередуя аналитическую дистанцию и эмоциональное вовлечение:

1. ANALYSE (дистанция) — модель анализирует проблему со стороны, выявляя скрытые допущения и рамки мышления
2. FEEL (вовлечение) — модель «проживает» проблему, подключая эмпатию и эмоциональный контекст
3. REFRAME (дистанция) — модель формулирует альтернативные интерпретации на основе обоих режимов
4. ENVISION (вовлечение) — модель представляет конкретную реализацию нового решения

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

Дизайн эксперимента

Исследование включало два анализа с общим объёмом в 13 500 вызовов генерации:

Анализ 1: промпты с рефреймингом vs обычные промпты

• 50 оригинальных задач из 8 категорий когнитивных ловушек: якорение, ложная бинарность, функциональная фиксированность, фрейминговая ловушка, нарративный замок, нулевая сумма, эффект Эйнштеллунга, многоходовые задачи
• 3 open-source LLM: Llama 3.3 70B, Qwen3 32B, Llama 4 Scout 17B-16E
• 5 запусков на каждое условие (temperature 0.7) с усреднением
• 3 независимых оценщика: самооценка модели + Claude Sonnet 4 + GPT-4.1 (все слепые к условию)
• 5 критериев оценки: разнообразие фреймов, выявление допущений, новизна решения, ревизия предпосылок, корректность

Анализ 2: четыре условия DEO

Для 20 задач с чистыми путями дистанции сравнивались четыре условия:

• Vanilla — обычный промпт без дополнительной структуры
• Distance-only — только аналитическая дистанция
• Engagement-only — только эмоциональное вовлечение
• DEO — полная осцилляция между дистанцией и вовлечением

Результаты

Предсказанный теорией порядок DEO > Distance > Engagement ≥ Vanilla подтвердился во всех 9 комбинациях модель × оценщик (все Friedman p < .001).

Анализ 1: рефрейминг значимо лучше обычных промптов

Средние баллы по 5-балльной шкале рефрейминга:

• Llama 3.3 70B — vanilla: 2.84, рефрейминг: 3.99 (Δ = +1.15, d = 1.29)
• Qwen3 32B — vanilla: 2.86, рефрейминг: 4.00 (Δ = +1.14, d = 1.56)
• Llama 4 Scout — vanilla: 2.82, рефрейминг: 3.98 (Δ = +1.16, d = 1.42)

Все 9 пар модель × оценщик показали статистическую значимость на уровне p < .001. При этом корректность ответов не снизилась — напротив, также значимо выросла.

Анализ 2: осцилляция эффективнее любого режима по отдельности

Средние баллы по четырём условиям (оценщик OpenAI, Llama 3.3 70B):

• Vanilla: 2.37
• Engagement-only: 2.92
• Distance-only: 3.61
• DEO: 4.06

Дистанция значительно превосходит вовлечение во всех 9 случаях — это подтверждает гипотезу PRT о том, что увидеть фрейм мышления сложнее, чем прочувствовать проблему. DEO добавляет значимое улучшение поверх дистанции в 4 из 9 случаев (d = 0.40–1.06).

Какие задачи выигрывают больше всего

Максимальный эффект DEO наблюдается на задачах с нарративным замком (narrative lock-in) — когда модель застревает в одной истории или интерпретации. Здесь прирост достигает Δ = +2.14, d = 3.23. На втором месте — задачи с фрейминговой ловушкой и эффектом Эйнштеллунга (фиксация на привычном методе решения).

Девять путей рефрейминга PRT

Теория PRT выделяет девять когнитивных путей, которые используются как промпт-стратегии:

1. Name the Frame — назвать скрытую рамку мышления (Δ до +1.60)
2. Decompose to Generic — разложить задачу на абстрактные компоненты
3. Distant Analogy — применить аналогию из другой области (Δ до +1.64)
4. Incubate & Reset — сделать паузу и вернуться к задаче заново
5. Invert — перевернуть задачу наоборот (Δ до +1.38)
6. Premise Reflection — поставить под сомнение исходные предпосылки (Δ до +1.56)
7. Surprise as Signal — использовать удивление как сигнал для рефрейминга (Δ до +1.87)
8. Confidence Calibration — калибровать уверенность в ответе
9. Step Outside — посмотреть на задачу глазами другого человека (Δ до +1.34)

Самые эффективные пути: Name the Frame, Distant Analogy и Surprise as Signal. Все три связаны с дистанцией — способностью модели "увидеть" рамку, в которой она мыслит.

Как попробовать DEO самому

Репозиторий включает slash-команду /reframe для Claude Code. Она применяет четырёхшаговую осцилляцию DEO к любой задаче:

Claude пройдёт четыре этапа — ANALYSE, FEEL, REFRAME, ENVISION — и выдаст рефреймированный ответ с альтернативными интерпретациями проблемы.

Для воспроизведения полного эксперимента:

Полный эксперимент (3 модели, 4 условия, 5 запусков, 3 оценщика) обходится примерно в $15–20.

FAQ

Что такое DEO-промптинг?

DEO (Distance-Engagement Oscillation) — это метод промптинга, в котором языковая модель чередует аналитический режим (дистанция) и эмоциональный режим (вовлечение). Такое чередование помогает модели выйти за рамки привычного мышления и находить более креативные решения. Метод основан на теории перцептивного рефрейминга (PRT) из когнитивной психологии.

На каких моделях работает DEO?

В исследовании метод тестировался на трёх open-source моделях: Llama 3.3 70B, Qwen3 32B и Llama 4 Scout 17B-16E. Эффект был стабильно значимым на всех трёх. Поскольку DEO работает на уровне промпта (zero-shot, без дообучения), он применим к любой LLM, способной следовать структурированным инструкциям.

Чем DEO отличается от Chain-of-Thought?

Chain-of-Thought заставляет модель рассуждать пошагово в одном когнитивном режиме. DEO добавляет переключение между режимами — от анализа к эмпатии и обратно. Это помогает модели не просто "думать дольше", а "думать иначе", выявляя скрытые предпосылки и рамки мышления, которые блокируют креативные решения.

Снижается ли корректность ответов при использовании DEO?

Нет. В эксперименте корректность ответов значимо выросла во всех 9 комбинациях модель × оценщик (p < .001). DEO не жертвует точностью ради креативности — оба показателя улучшаются одновременно.

Можно ли использовать DEO в продакшене?

Код и данные открыты под лицензией CC BY 4.0. Метод не требует дообучения или специальной инфраструктуры — достаточно модифицировать системный промпт. Четырёхшаговая структура ANALYSE–FEEL–REFRAME–ENVISION легко интегрируется в любой пайплайн.

Выводы

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

Исследование Гёкмена — первый эмпирический тест механизма DEO и одна из немногих работ, применяющих когнитивную психологию рефрейминга к промпт-инжинирингу. Результаты показывают, что структура промпта важнее, чем размер модели: правильно организованное чередование дистанции и вовлечения даёт стабильный и воспроизводимый прирост креативного мышления LLM.

Полный код эксперимента, 307 JSON-файлов с ответами моделей и статистический анализ доступны в репозитории на GitHub. Препринт статьи опубликован на Zenodo (DOI: 10.5281/zenodo.19252225).

Попробуйте DEO-промптинг на своих задачах — возможно, ваша LLM способна на большее, чем вы думаете.

Telnyx — платформа для программируемой телефонии, SMS и сетевых сервисов. Её Python SDK (telnyx на PyPI) скачивают более 1 миллиона раз в месяц (~30 000 загрузок в день). 27 марта 2026 года исследователи из SafeDep обнаружили, что версии 4.87.1 и 4.87.2 содержат вредоносный код, которого нет в исходном репозитории на GitHub. Инциденту присвоен CVE-2026-33634 (CVSS 9.4). Обе заражённые версии уже карантинированы PyPI.

Главное: Версии telnyx 4.87.1 и 4.87.2 на PyPI содержат вредоносный код — 74 строки, внедрённые в файл _client.py. Пакет скачивают более 1 млн раз в месяц. Вредонос использует стеганографию в WAV-файлах для доставки полезной нагрузки. На Windows устанавливается бэкдор, на Linux/macOS — крадутся учётные данные. Безопасная версия — 4.87.0. Атака связана с группировкой TeamPCP — это уже третье звено в цепочке после компрометации Trivy, Checkmarx и litellm.

Supply chain attack (атака на цепочку поставок) — тип атаки, при которой злоумышленник компрометирует не конечную цель, а один из компонентов, от которого она зависит: библиотеку, SDK или инструмент сборки. Разберём, как именно сработала атака и что делать, если вы используете telnyx.

Как произошла компрометация

Последняя чистая версия пакета — 4.87.0 — была опубликована 26 марта через штатный CI/CD-пайплайн (GitHub Actions + Rye). У неё есть соответствующий тег v4.87.0 в репозитории.

Версии 4.87.1 и 4.87.2 не имеют ни тегов, ни релизов на GitHub. Workflow публикации не запускался после v4.87.0. Метаданные PyPI показывают, что заражённые версии были загружены через twine/6.2.0, тогда как легитимный пайплайн использует rye publish.

Вывод: атакующий получил украденный PyPI API-токен и загрузил троянизированные версии напрямую, минуя CI/CD. У проекта не был настроен PyPI Trusted Publisher (OIDC), который привязывает загрузку к конкретному репозиторию и воркфлоу, делая украденные токены бесполезными.

Как работает вредоносный код

В файл telnyx/_client.py было внедрено ровно 74 строки кода в трёх местах: импорты в начале файла, base64-закодированная переменная с полезной нагрузкой и функции атаки после легитимных классов. Код выполняется автоматически при import telnyx — никакого взаимодействия с пользователем не требуется.

WAV-стеганография

Ключевая особенность атаки — использование стеганографии. Вредонос скачивает с C2-сервера файлы, замаскированные под WAV-аудио (ringtone.wav для Linux/macOS, hangup.wav для Windows). Исполняемый код спрятан в аудиофреймах и извлекается через XOR-деобфускацию. Импорт модуля wave в SDK для телефонии — единственный «красный флаг», который мог выдать атаку при code review.

Windows: бэкдор через автозагрузку

Функция setup() проверяет os.name == 'nt', затем скачивает бинарник из WAV-файла и сохраняет его как msbuild.exe в папку автозагрузки Windows. Имя файла имитирует легитимный инструмент Microsoft Build Engine. Бэкдор запускается при каждом входе в систему с кулдауном повторной установки 12 часов.

Linux/macOS: кража учётных данных

Функция FetchAudio() запускает второй этап из base64-закодированной переменной (4 436 символов). Скрипт собирает учётные данные, API-ключи, SSH-ключи и секреты, шифрует их связкой AES-256-CBC + RSA-4096 с хардкодированным публичным ключом и отправляет на C2-сервер через HTTP POST.

Баг атакующего

Любопытная деталь: в версии 4.87.1 атака на Windows не работала. Атакующий вызвал Setup() с заглавной буквы, тогда как функция определена как setup() со строчной. Это вызывало NameError, прерывавший выполнение модуля до запуска FetchAudio(). Версия 4.87.2 — по сути патч-релиз атакующего, исправляющий эту опечатку.

Связь с TeamPCP: цепочка атак

RSA-4096 публичный ключ, зашитый в вредоносный код, побайтово совпадает с ключом из компрометации пакета litellm. Это позволяет с высокой уверенностью атрибутировать атаку группировке TeamPCP. Группировка использует инфраструктуру CanisterWorm, размещённую на блокчейне Internet Computer Protocol (ICP) — без единой точки отказа.

Компрометация telnyx — третье крупное звено в каскадной атаке TeamPCP:

• 27 февраля — атака на репозиторий Trivy (сканер уязвимостей от Aqua Security) через вредоносный PR
• 19–20 марта — заражённый Trivy v0.69.4 опубликован, CanisterWorm распространился на 46+ npm-пакетов
• 23 марта — скомпрометированы Checkmarx GitHub Actions
• 24 марта — заражены версии litellm 1.82.7 и 1.82.8 на PyPI (~97 млн загрузок/мес)
• 27 марта — заражены версии telnyx 4.87.1 и 4.87.2 на PyPI

Что делать

1. Проверьте версию telnyx в ваших проектах
2. Если установлена 4.87.1 или 4.87.2 — немедленно откатитесь на 4.87.0
3. Проверьте наличие файла msbuild.exe в папке автозагрузки Windows
4. Проверьте сетевые соединения с IP 83.142.209.203
5. Если обнаружены IoC — считайте все учётные данные, API-ключи и SSH-ключи скомпрометированными
6. Проверьте CI/CD на использование других скомпрометированных пакетов TeamPCP: Trivy, Checkmarx Actions, litellm
7. Включите Trusted Publishers для всех ваших PyPI-пакетов

Индикаторы компрометации (IoC)

CVE-2026-33634 (CVSS 9.4) — GitHub issue #235

FAQ

Какие версии telnyx заражены?

Вредоносный код содержится в версиях 4.87.1 и 4.87.2. Обе уже карантинированы PyPI. Последняя безопасная версия — 4.87.0. При этом в 4.87.1 из-за опечатки атакующего ни один из векторов атаки фактически не срабатывал.

Как атакующие получили доступ к PyPI?

Через украденный PyPI API-токен. GitHub-репозиторий telnyx не был скомпрометирован — атакующие загрузили пакеты напрямую на PyPI через twine, минуя CI/CD. У проекта не был настроен Trusted Publisher (OIDC), который предотвратил бы такую атаку.

Кто стоит за атакой?

Атака атрибутирована группировке TeamPCP. Это та же группа, которая ранее скомпрометировала сканер уязвимостей Trivy, GitHub Actions Checkmarx и PyPI-пакет litellm. RSA-ключ в вредоносном коде побайтово совпадает с ключом из предыдущих атак. Инфраструктура CanisterWorm размещена на блокчейне ICP, что делает её устойчивой к блокировке.

Что делать, если я уже установил заражённую версию?

Немедленно откатитесь на версию 4.87.0. Проверьте систему на наличие IoC. Если обнаружены признаки компрометации — считайте все учётные данные, API-ключи и SSH-ключи на этой машине скомпрометированными и выполните их ротацию. Также проверьте CI/CD на использование Trivy, Checkmarx Actions и litellm.

Выводы

Атака на telnyx — не изолированный инцидент. Это часть каскадной кампании TeamPCP, которая за месяц скомпрометировала Trivy, Checkmarx, litellm и теперь telnyx. Единственная надёжная защита — PyPI Trusted Publishers (OIDC), привязывающий загрузку к конкретному GitHub-репозиторию.

Этот инцидент в очередной раз показывает: доверять пакетам из PyPI «на слово» нельзя, даже если это официальный SDK крупной платформы. Настройте Trusted Publishers, пиньте версии зависимостей, проверяйте хеши при установке. Проверьте свои проекты прямо сейчас.

Источники: SafeDep, Aikido, The Hacker News, JFrog Security Research

LiteLLM — это open-source прокси для работы с API различных LLM-провайдеров: OpenAI, Anthropic, Azure, Bedrock и ещё сотней других. Библиотека позволяет переключаться между моделями через единый интерфейс с автоматическими фоллбэками, ретраями и трекингом расходов. При 97 миллионах загрузок в месяц (около 3,4 млн в день) это один из самых популярных инструментов в AI-инфраструктуре.

В скомпрометированных версиях 1.82.7 и 1.82.8, опубликованных на PyPI, обнаружили встроенный стилер учётных данных. Он крал SSH-ключи, токены облачных сервисов, API-ключи и пароли, а затем расползался по Kubernetes-кластерам.

Ключевое: Версии LiteLLM 1.82.7 и 1.82.8 на PyPI содержали стилер, крадущий SSH-ключи, облачные токены и API-ключи. Версия 1.82.8 запускала вредоносный код при каждом старте Python — даже без импорта библиотеки. Если вы устанавливали LiteLLM 24 марта 2026 года — проверьте свои системы. Последняя чистая версия — 1.82.6.

Но эта атака — не изолированный инцидент. Это финал пятидневной supply chain атаки (атаки через цепочку поставок — внедрение вредоносного кода в легитимный пакет через компрометацию его инфраструктуры). За ней стоит группировка TeamPCP — ранее неизвестная группа, которая за последнюю неделю марта целенаправленно атаковала инструменты безопасности и разработки. Кампания началась с компрометации сканера уязвимостей Trivy и через цепочку украденных CI/CD-креденшалов дотянулась до LiteLLM.

Разбираем всю цепочку атаки от начала до конца — подробнее, чем где-либо ещё.

Хронология: пять дней, три вендора, пять экосистем

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

19 марта: Trivy — точка входа

Всё началось с Trivy — open-source сканера уязвимостей от Aqua Security, которым пользуются тысячи компаний для проверки контейнеров и кода.

Атакующие использовали скомпрометированные учётные данные мейнтейнера, чтобы:

• Опубликовать вредоносный релиз Trivy v0.69.4, который прошёл через стандартную release-машинерию и попал в GHCR, ECR Public, Docker Hub, deb/rpm-пакеты
• Подменить 76 из 77 тегов aquasecurity/trivy-action на вредоносные коммиты
• Заменить все 7 тегов aquasecurity/setup-trivy

Вредоносный код в GitHub Actions сканировал память процесса Runner.Worker, собирал креденшалы, шифровал данные AES+RSA и отправлял на подставной домен scan.aquasecurtiy[.]org — обратите внимание на опечатку в слове «security». Если прямая эксфильтрация не удавалась, малварь создавала публичный репозиторий tpcp-docs через GitHub-токен жертвы и сливала данные туда.

20–22 марта: npm-червь и дефейс

Уже на следующий день украденные токены пошли в дело. Атакующие запустили самораспространяющегося npm-червя: 28 пакетов в @EmilGroup, 16 в @opengov, плюс отдельные пакеты в других скоупах. Червь крал npm-токены из скомпрометированных окружений, проверял, к каким пакетам они дают доступ, поднимал patch-версию, подставлял оригинальный README для маскировки и переиздавал пакет с вредоносной начинкой.

К 22 марта та же инфраструктура начала обслуживать Kubernetes-скрипт с разделением жертв по геолокации. На иранских системах деплоился DaemonSet с контейнером kamikaze, который удалял файловую систему хоста и перезагружал ноду. На остальных — устанавливал персистентный бэкдор.

В тот же день атакующие дефейснули 44 репозитория внутренней GitHub-организации Aqua Security (aquasec-com), переименовав их с префиксом tpcp-docs- и описанием «TeamPCP Owns Aqua Security».

23 марта: Checkmarx

Кампания добралась до Checkmarx — ещё одного крупного вендора в сфере безопасности приложений. Были скомпрометированы:

• Checkmarx/kics-github-action — сканер инфраструктурного кода
• Checkmarx/ast-github-action — GitHub Action для платформы Checkmarx
• Расширения VS Code в реестре Open VSX: ast-results v2.53.0 (около 36 000 загрузок) и cx-dev-assist v1.7.0 (около 500 загрузок)

Паттерн тот же: стилер креденшалов, привязанный к домену checkmarx[.]zone, с фоллбэком на публичный репозиторий docs-tpcp для эксфильтрации.

24 марта: LiteLLM

В 10:52 UTC на PyPI появилась версия LiteLLM 1.82.8. Соответствующий тег или релиз на GitHub отсутствовал — пакет был загружен напрямую, в обход стандартного процесса. По данным ReversingLabs, был скомпрометирован GitHub-аккаунт сооснователя и CEO LiteLLM Криша Дхолакии — предположительно, через CI/CD-пайплайн, где Trivy использовался без пиннинга версии.

Через три часа команда безопасности PyPI поставила проект на карантин. Скомпрометированные версии были удалены. Последняя чистая версия — 1.82.6. Но при 3,4 миллионах загрузок в день даже три часа — это огромное окно.

Мейнтейнеры LiteLLM опубликовали security-апдейт, подтвердив компрометацию и рекомендовав всем пользователям обновиться до версии 1.82.6 или выше (после снятия карантина). Issue #24512 на GitHub, описывающий уязвимость, был закрыт — предположительно, самим атакующим через скомпрометированный аккаунт.

Как работает вредоносный код

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

Версия 1.82.7: инъекция в proxy_server.py

В версии 1.82.7 вредоносный код был внедрён в файл litellm/proxy/proxy_server.py. Малварь запускалась только при реальном использовании LiteLLM Proxy в приложении. Если пакет был установлен, но прокси-сервер не запускался, код мог не сработать.

Версия 1.82.8: .pth-файл — запуск без импорта

Версия 1.82.8 принципиально опаснее. В wheel-пакет был добавлен файл litellm_init.pth размером 34 628 байт, содержащий дважды закодированный в base64 вредоносный код.

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

Это означает: достаточно было выполнить pip install litellm==1.82.8, и каждый последующий запуск Python на этой машине активировал стилер. Не нужно писать import litellm — даже python -c "print('hello')" запускал вредоносный код.

Три стадии: сбор, шифрование, эксфильтрация

Стадия 1 — сбор. Скрипт прочёсывает машину и собирает:

• SSH-ключи и конфигурации (~/.ssh/)
• .env-файлы с секретами
• Креденшалы AWS (Access Key, Secret Key), GCP (ADC), Azure
• Конфигурации Kubernetes (~/.kube/config)
• Docker-конфиги (~/.docker/config.json)
• Пароли баз данных
• Историю шелла (bash_history, zsh_history)
• Файлы криптокошельков
• Все переменные окружения
• Данные с облачных metadata-эндпоинтов (IMDS)

Стадия 2 — шифрование. Собранные данные упаковываются в tar-архив и шифруются гибридной схемой: случайный сессионный ключ AES-256-CBC для данных, зашифрованный захардкоженным 4096-битным RSA-публичным ключом.

Стадия 3 — эксфильтрация. Зашифрованный архив отправляется POST-запросом на models.litellm[.]cloud (домен не имеет отношения к настоящему litellm.ai) с заголовком X-Filename: tpcp.tar.gz.

Горизонтальное распространение в Kubernetes

Если на машине обнаружен токен сервисного аккаунта Kubernetes, малварь переходит в режим горизонтального распространения (lateral movement):

1. Читает все секреты кластера во всех неймспейсах
2. Создаёт привилегированный pod на каждой ноде в kube-system на основе образа alpine:latest
3. Каждый pod монтирует корневую файловую систему хоста
4. Устанавливает персистентный бэкдор в /root/.config/sysmon/sysmon.py
5. Регистрирует systemd user service для автозапуска

Таким образом, компрометация одного pip-пакета превращается в полную компрометацию всего Kubernetes-кластера.

Персистентность и бэкдор

На локальной машине малварь создаёт:

• ~/.config/sysmon/sysmon.py — скрипт-бэкдор
• ~/.config/systemd/user/sysmon.service — systemd unit для автозапуска

После установки бэкдор периодически обращается к https://checkmarx[.]zone/raw, скачивает файл в /tmp/pglog и выполняет его содержимое. Это даёт атакующим возможность удалённо выполнять произвольный код на скомпрометированных машинах в любой момент.

Как обнаружили: баг в малвари устроил fork-бомбу

Ирония истории в том, что атаку обнаружили благодаря ошибке самих хакеров.

Команда FutureSearch столкнулась с проблемой случайно: MCP-плагин в IDE Cursor подтянул LiteLLM как транзитивную зависимость. Вредоносный .pth-файл запускал дочерний Python-процесс через subprocess.Popen. Но поскольку .pth-файлы срабатывают при каждом запуске интерпретатора, дочерний процесс тоже запускал малварь, та порождала ещё один процесс — и так далее.

Результат — экспоненциальная fork-бомба, которая мгновенно съедала всю оперативную память и вешала систему. Без этого бага стилер мог бы работать незамеченным значительно дольше.

Мы были взломаны… тысячи людей, вероятно, прямо сейчас под атакой

Что делать, если вы затронуты

Если в ваших проектах, CI/CD-пайплайнах или на рабочих машинах устанавливался LiteLLM 24 марта или позже — проверьте версию:

Если обнаружена версия 1.82.7 или 1.82.8:

1. Удалите пакет и очистите кэши: pip cache purge, rm -rf ~/.cache/uv
2. Проверьте наличие бэкдора: файлы ~/.config/sysmon/sysmon.py и ~/.config/systemd/user/sysmon.service
3. В Kubernetes: аудит kube-system на наличие подов node-setup-*, проверка секретов на несанкционированный доступ
4. Ротация всех креденшалов: SSH-ключи, облачные токены (AWS, GCP, Azure), API-ключи, пароли БД, .env-файлы
5. Сетевые логи: проверьте обращения к models.litellm[.]cloud, checkmarx[.]zone, scan.aquasecurtiy[.]org
6. Восстановление: не ограничивайтесь удалением пакета — пересобирайте системы из известных чистых образов с закреплёнными (pinned) зависимостями

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

Индикаторы компрометации (IoC)

Вредоносные домены:

• models.litellm[.]cloud — C2 для LiteLLM
• checkmarx[.]zone — C2, используемый для персистентности и Checkmarx-атаки
• scan.aquasecurtiy[.]org — C2 для Trivy-атаки

Файлы на диске:

• litellm_init.pth в site-packages/
• ~/.config/sysmon/sysmon.py
• ~/.config/systemd/user/sysmon.service
• /tmp/pglog
• /tmp/.pg_state

Kubernetes-артефакты:

• Поды с именами node-setup-* в kube-system
• Контейнеры с именами kamikaze или provisioner

Инциденту присвоен идентификатор CVE-2026-33634. Полный список IoC в формате CSV доступен в репозитории Datadog Security Labs.

Частые вопросы

Что такое LiteLLM и зачем его используют?

LiteLLM — это open-source Python-библиотека и прокси-сервер, который предоставляет единый интерфейс для работы с более чем 100 LLM-провайдерами (OpenAI, Anthropic, Azure, AWS Bedrock и другие). Библиотека позволяет переключаться между моделями без изменения кода, автоматически обрабатывает фоллбэки и ретраи, отслеживает расходы. По данным PyPI, пакет загружается около 3,4 миллионов раз в день.

Какие версии LiteLLM скомпрометированы?

Скомпрометированы версии 1.82.7 и 1.82.8, опубликованные на PyPI 24 марта 2026 года. Обе версии удалены. Последняя безопасная версия — 1.82.6. Версия 1.82.8 опаснее: она запускает вредоносный код при каждом старте Python через механизм .pth-файлов, тогда как 1.82.7 активируется только при использовании прокси-сервера.

Как проверить, затронут ли я?

Выполните pip show litellm для проверки версии и find ~/.cache/uv -name "litellm_init.pth" для поиска вредоносного файла в кэше. Также проверьте наличие бэкдора: файлы ~/.config/sysmon/sysmon.py и ~/.config/systemd/user/sysmon.service. В Kubernetes ищите поды node-setup-* в namespace kube-system.

Кто стоит за атакой?

Атака приписывается группировке TeamPCP, которая за последнюю неделю марта 2026 года провела серию supply chain атак на инструменты разработки и безопасности: сканер уязвимостей Trivy (Aqua Security), GitHub Actions и расширения VS Code от Checkmarx, npm-пакеты, и в финале — LiteLLM. Инциденту присвоен идентификатор CVE-2026-33634.

Что такое .pth-файл и почему он опасен?

Файлы с расширением .pth, размещённые в директории site-packages, автоматически обрабатываются модулем site Python при каждом запуске интерпретатора. Исполняемые строки в таких файлах выполняются без явного импорта библиотеки. В случае LiteLLM 1.82.8 файл litellm_init.pth содержал дважды закодированный в base64 вредоносный скрипт, который запускался при каждом вызове python в скомпрометированном окружении.

Выводы

Ирония инцидента — в том, что LiteLLM по определению хранит API-ключи ко всем LLM-провайдерам организации. Атакующие выбрали пакет, который гарантированно имеет доступ к самым ценным секретам.

Одна зависимость. Одна цепная реакция. Пять экосистем supply chain скомпрометированы менее чем за месяц

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

Устанавливать пакеты из публичного реестра без проверки хешей и без lock-файлов — значит фактически отдать root-доступ любому, кто сможет скомпрометировать аккаунт мейнтейнера. Как ёмко выразилась Ноэлль Мурата, старший инженер по безопасности в Xcape: «Это цифровой эквивалент того, чтобы съесть бутерброд, найденный в метро, и удивиться пищевому отравлению».

Подробный технический анализ от Datadog Security Labs доступен здесь. Оригинальный отчёт FutureSearch — здесь. Официальный security-апдейт LiteLLM — здесь.

Проверьте свои зависимости сегодня. Команды для аудита — в разделе выше.

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

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

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

Быстрее — не значит умнее

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

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

При этом ожидаемого скачка продуктивности тоже не случилось. В среднем ИИ не дал статистически значимого ускорения по времени.

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

Как именно ИИ «ломает» обучение

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

Более «здоровыми» оказались сценарии, где ИИ используют как справочник или собеседника: задают концептуальные вопросы, просят объяснить уже сгенерированный код, проверяют гипотезы.

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

Именно эта творческая составляющая и делает Майнкрафт лучшим для обучения программированию детей. Мир игры представляет собой бесконечную «цифровую песочницу» с четкими правилами физики и логики. Здесь можно не только построить замок, но и запрограммировать лифт для него, систему освещения или автоматическую дверь, которая откроется, только если игрок положит в сундук нужный предмет.

Что делает программирование в Майнкрафт простым и доступным детям:

• Мотивация и контекст. Ребенок видит немедленный и наглядный результат своего кода. Не абстрактная задача «вывести числа на экран», а конкретная цель: «заставить стреляющую пушку автоматически строиться и стрелять» или «создать поезд, который сам едет по заданному маршруту». Программирование в Майнкрафт становится не самоцелью, а ключом к новым игровым возможностям.
• Визуальная обратная связь. Ошибка в коде часто приводит к забавным последствиям в игре (например, поезд уезжает не туда или механизм строит себя неправильно). Это превращает отладку из рутины в увлекательное расследование.
• Естественный переход от роли игрока к роли создателя. Ребенок перестает быть пассивным потребителем контента. Он становится архитектором, инженером, творцом собственных миров и правил.

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

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

Также приглашаем на онлайн-курсы для детей по программированию в Майнкрафт:

• Minecraft Junior. Создание игр для детей 7-10 лет.
• Игровая вселенная Minecraft. Программирование Python.
• Инженер миров Minecraft для детей от 10 до 13 лет.

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

Как выбрать платформу для программирования в Майнкрафт

Прежде чем мы перейдем к обзору конкретных сервисов, разберемся, по каким параметрам их стоит оценивать. Основные критерии, на которые стоит обратить внимание:

1. Безопасность и закрытость среды.

Это абсолютный приоритет. Образовательная платформа должна быть защищенным пространством.

• Это значит, что ребенок взаимодействует только с заранее одобренным контентом, без возможности случайного выхода в открытые сетевые миры Minecraft с неконтролируемым общением. Все действия происходят либо в локальном мире на компьютере, либо в специально созданном классе с доступом по коду.
• Это важно, так как позволяет полностью сосредоточиться на обучении, исключив риски, связанные с онлайн-игрой. А вы как родитель можете быть спокойны, зная, что ребенок в цифровой безопасности.
• На что обратить внимание: Есть ли у платформы режим «офлайн» или защищенные «образовательные серверы»? Требует ли она регистрации и какие данные запрашивает? Есть ли модерация или родительский контроль?

2. Удобный интерфейс, подходящий по возрасту.

Интерфейс — это мост между идеей ребенка и ее реализацией. Он должен быть интуитивно понятным:

• Для младших школьников (6-10 лет) идеальным стартом является визуальное программирование блоками. Команды выглядят как цветные пазлы, которые нужно сложить в определенном порядке. Это позволяет усвоить логику алгоритмов, не отвлекаясь на синтаксис языка. Для подростков (11+) важен плавный или прямой переход к текстовому коду (Python, JavaScript), который выглядит как у профессиональных разработчиков.
• Это важно, так как слишком сложный интерфейс отпугнет, а слишком простой — быстро наскучит. Правильный инструмент, соответствующий уровню и амбициям ребенка, давая ему почувствовать прогресс.
• На что смотреть: Предлагает ли платформа разные режимы (блоки/текст)? Насколько логично организовано меню? Есть ли подсказки и обучающие миссии «внутри» игры?

3. Связь программ в Майнкрафт с реальными языками программирования.

Конечная цель — получить навык, применимый в реальном мире.

• Платформа должна учить принципам и синтаксису языков, которые используются в веб-разработке, анализе данных, создании игр (например, Python или JavaScript). Даже работа с блоками должна в итоге показывать, как этот же алгоритм выглядит в текстовом виде.
• Это важно, так как обеспечивает преемственность в обучении. Навыки, полученные при программировании в Майнкрафт, ребенок сможет использовать для создания сайта, чат-бота или мобильного приложения.
• На что смотреть: На каком языке пишется код? Можно ли переключиться с блоков на текст и увидеть эквивалент своего алгоритма? Есть ли справочник по командам (документация)?

4. Стоимость и простота начала.

Этот критерий касается не только бюджета, но и организационных усилий.

• Нужно ли покупать специальную версию игры? Есть ли подписка на саму платформу? Можно ли начать с бесплатного полноценного курса, чтобы оценить интерес ребенка? Сколько стоит переход на следующий уровень?
• Понимание ответов на эти вопросы позволяет планировать. Бесплатный старт — это возможность «попробовать без обязательств». Разумная плата за углубленный курс — это инвестиция в качественный контент и поддержку.
• На что смотреть: Что входит в бесплатную версию? За что именно взимается плата (лицензия на игру, доступ к урокам, техподдержка)? Нужно ли устанавливать дополнительное программное обеспечение?

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

Программирование в Minecraft Education Edition

Minecraft Education Edition (M:EE) — это не модификация игры и не сторонний сервис. Это специальная версия игры, созданная компанией Microsoft именно для учебных целей.

Как устроен Minecraft Education Edition

Платформа представляет собой автономное приложение, которое можно установить на компьютер или планшет. Его ключевой компонент — Code Builder. Это специальный режим, который открывается нажатием одной клавиши (C) прямо в игровом мире. Он запускает панель программирования, не прерывая процесс игры в Майнкрафт.

Главный герой Code Builder — Исполнитель (The Agent), мобильный робот, которого ученик программирует. Вы не управляете им вручную, а пишете код, который заставляет Исполнителя двигаться, разрушать или ставить блоки, собирать предметы. Он идеально иллюстрирует основу программирования: мы даем четкие инструкции виртуальному объекту.

С чего начать программирование в Minecraft Education Edition

Доступ:

Платформа платная. Лицензию обычно приобретает учебное заведение (школа, кружок) для своих учеников. Для домашнего использования также можно купить индивидуальную подписку через официальный сайт Microsoft. Есть и бесплатная пробная версия.

Первые шаги:

После запуска ученик попадает в Библиотеку миров. Здесь — десятки готовых, методически продуманных уроков не только по программированию в Майнкрафт, но и по математике, истории, биологии. Для обучения коду нужно выбрать мир из раздела «Информатика» или «Основы программирования».

Интерфейс программирования:

Внутри мира нажимаем C и видим выбор: MakeCode (визуальные блоки) или Python. Можно начать с блоков, а в любой момент переключиться на вкладку «Python» и увидеть, как тот же самый код выглядит на текстовом языке.

Пример реального задания

Уровень «Островной старт» (для новичков)

Задача:

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

Что делает ребенок в MakeCode (блоки):

1. Из меню перетаскивает блок при запуске (аналог главной функции).
2. Внутрь добавляет блок агент.двигаться вперед и выбирает количество шагов.
3. Добавляет блок агент.поставить и выбирает тип блока (например, дубовые доски).
4. Запускает код и наблюдает, как Исполнитель в точности выполняет последовательность.

Переход к Python:

Ребенок переключает вкладку и видит сгенерированный код:

from mcpi.minecraft import Minecraft

mc = Minecraft.create()

agent.move("forward", 5)

agent.place("oak_planks")

Он понимает, что блоки — это оболочка для настоящих команд. Теперь он может экспериментировать, меняя числа и названия блоков прямо в текстовом редакторе.

Ключевые плюсы программирования в Minecraft Education Edition

• Педагогический подход. Каждый урок имеет четкие учебные цели, встроенные подсказки и постепенное увеличение сложности.
• Полная безопасность. Миры локальны или защищены. Нет открытых сетевых серверов. Есть инструменты для учителя: возможность давать ресурсы, телепортироваться к ученику, управлять настройками мира.
• Прямой путь к Python. Это главное преимущество. Ребенок с самого начала работает с синтаксисом одного из самых востребованных языков в мире, видя прямую связь между визуальными блоками и строками кода.
• Учебный план. Платформа предлагает готовые проекты на 10-12 занятий, что удобно для учителей и родителей, ведущих систематическое обучение.

В каком возрасте можно изучать программирование в Minecraft Education Edition?

• Начальная школа (6-10 лет). Старт в визуальном редакторе MakeCode внутри M:EE. Выполнение сюжетных заданий по строительству, фермерству.
• Средние школьники 11-13 лет. Параллельная работа: выполнение задачи на блоках, затем анализ и редактирование кода на Python. Создание более сложных механизмов: автоматических дверей с редстоуном, сортировщиков предметов.
• Подростки (14+). Программирование на чистом Python для решения комплексных задач: генерация ландшафтов по алгоритму, создание мини-игр с условиями и циклами.

Minecraft Education Edition — это стандарт для обучения программированию детей в школе или на курсах. Это не самая дешевая платформа, но она предлагает максимально целостный путь от игрового конструирования к написанию кода на Python.

Программирование в Майнкрафт с Microsoft MakeCode

Microsoft MakeCode для Minecraft — это бесплатный веб-редактор, который превращает обычную, самую распространенную версию игры (Minecraft: Bedrock Edition) в инструмент для изучения программирования. Его главная философия — минимальный порог входа и максимальная свобода творчества.

Как устроен Microsoft MakeCode

MakeCode — это облачная платформа, работающая прямо в браузере. Она не требует установки дополнительного программного обеспечения, кроме самой игры. Принцип работы основан на создании поведенческих пакетов (behavior packs) — специальных дополнений, которые изменяют логику мира.

Редактор предлагает два равноценных интерфейса, между которыми можно мгновенно переключаться:

• Блочный редактор для визуального программирования в Майнкрафт с цветными блоками-командами.
• Текстовый редактор JavaScript — код пишется в нем на упрощенном JavaScript с автодополнением и подсветкой синтаксиса.

Код, написанный в MakeCode, вы экспортируете в один файл, который затем копируете в папку с сохранениями Minecraft. После этого в игре активируется новый мир с вашими правилами и возможностями.

Программирование в Майнкрафт с MakeCode: как начать?

Доступ полностью бесплатный. Достаточно зайти на сайт makecode.com и выбрать раздел «Minecraft». Нужна только лицензия на базовую версию Minecraft (Bedrock Edition) на ПК, Xbox или планшете.

Первые шаги:

На сайте есть встроенные туториалы по программированию в Майнкрафт. Они пошагово объясняют, как создать первый проект — например, «Волшебную палочку», которая при использовании строит мост, или «Чат-бота», который отвечает в игровом чате.

Процесс:

Работа идет в браузере. После написания алгоритма можно нажать кнопку «Запустить» и увидеть симуляцию работы кода прямо в окне. Когда проект готов, его скачивают и активируют в игре.

Пример реального задания

Проект «Умная кирка».

Задача:

Создать кирку, которая при разрушении блока руды автоматически дропает (выбрасывает) вдвое больше ресурсов.

Что делает ребенок (в блочном редакторе):

1. Использует событие при разрушении блока — это триггер, который запускает код при определенном действии.
2. Добавляет условие if для проверки типа разрушенного блока (например, железная руда).
3. Внутри условия размещает команду выбросить предмет с указанием предмета (железный слиток) и количества (умножая стандартное количество на 2).

Переход к JavaScript:

Переключившись на вкладку JavaScript, ребенок увидит структурированный код:

blocks.onBlockBroken(function (block) {

if (block == IRON_ORE) {

mobs.dropItem(block.position, IRON_INGOT, 2)

}

})

Так он изучает базовые конструкции языка: функции, условия, работу с событиями — но в контексте знакомой игры.

Ключевые плюсы платформы

• Нулевая стоимость и доступность. Сам редактор бесплатен и работает онлайн — можно попробовать программирование в Майнкрафт без дополнительных инвестиций, используя уже купленную игру.
• Прямая интеграция с Minecraft, уже установленным на домашнем ПК. Ребенок видит результат своего труда там, где он привык играть, что усиливает его мотивацию.
• Мощный событийно-ориентированный подход. MakeCode учит современной парадигме программирования — реагированию на события (игрок наступил на плиту, ударил по блоку, нажал кнопку). А это — фундамент для создания интерактивных приложений.
• Плавный переход к JavaScript. Язык, на котором пишет ребенок в текстовом режиме, — это актуальный JavaScript, один из главных языков веб-разработки. Навыки, полученные здесь, применимы для создания сайтов и веб-приложений.

Оптимальный возраст

• Начальная школа (6-10 лет). Младшим школьникам, которые хотят научиться программированию в Майнкрафт с MakeCode, стоит начинать с блочного редактора и повторять готовые туториалы. Цель — понять цепочку «событие — условие — действие».
• Средняя школа (11-14 лет). Создание собственных модификаций: оружие со спецэффектами, автоматические фермы, простые мини-игры. Активное переключение между визуальными блоками и JavaScript для анализа кода.
• Подростки (14+). Программирование сложных систем на чистом JavaScript: многопользовательские игры в одном мире, алгоритмы procedural generation (создание ландшафтов), подключение внешних датчиков (через MakeCode для микроконтроллеров).

Microsoft MakeCode для Minecraft подходит детям, которые изучают программирование дома, самостоятельно, или в кружках. Это прямой путь к пониманию того, как создаются моды и интерактивные приложения.

Code.org — курс по программированию для детей «Час кода: Приключение в Minecraft»

Если первые две платформы требуют наличия самой игры, то подход Code.org принципиально иной. Это не инструмент для модификации Minecraft, а отдельный интерактивный курс, который лишь использует эту вселенную и ее героев для обучения основам алгоритмики. Главная цель такого подхода — снять барьеры для первого знакомства с программированием и сделать его увлекательным.

Как устроен курс по программированию «Час кода в Minecraft»

Code.org — крупнейшая некоммерческая образовательная платформа, ее акция «Час кода» известна во всем мире. Курс «Приключение в Minecraft» — это серия головоломок, которые нужно решить прямо в браузере.

Ребенок не устанавливает игру и не работает в игровом движке. Вместо этого он видит упрощенный изометрический мир (вид сверху под углом), похожий на Minecraft, и управляет действиями персонажа (Стив, Алекс или другими), составляя программу из визуальных блоков. Каждый урок — это короткая задача: пройти к овце, собрать ресурсы, построить дом, избежать опасностей.

Как попасть на курс программирования для детей «Час кода в Minecraft»

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

Первые шаги:

Зайдите на страницу курса code.org/minecraft — ребенок сразу может приступить к курсу программирования. Он разбит на несколько тематических разделов (например, «Первое путешествие», «Создай свой мир», «Герой»). Начните с самого первого задания, где за две минуты объясняется базовый принцип: перетащить блок двигаться вперед в рабочую зону и нажать «Запустить».

Процесс:

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

Пример реального задания

Уровень «Сбор урожая» (из раздела «Первое путешествие»).

Задача:

Дойти до тыквы, срубить ее и вернуться на старт.

Что делает ребенок:

1. Анализирует карту: сколько шагов до тыквы? Нужно ли поворачивать?
2. Из палитры перетаскивает блоки двигаться вперед (2 раза) в область «Когда запущено».
3. Добавляет блок разрушить вперед (чтобы срубить тыкву).
4. Добавляет еще два блока двигаться вперед, чтобы вернуться.
5. Нажимает «Выполнить» и наблюдает за анимацией.

Такие задачи по программированию в Майнкрафт учат ребенка последовательности команд, предварительному планированию маршрута, понятию «алгоритм» как четкому плану действий. На следующих уровнях появляются циклы повторить, чтобы не тащить много одинаковых блоков, и условия если, чтобы реагировать на препятствия.

Ключевые плюсы программирования в Майнкрафт на курсе «Час кода»

• Максимальная доступность и безопасность. Не нужно ничего устанавливать, платить за подписку, нет рисков онлайн-игр. Ребенок находится в полностью контролируемой учебной среде, которая отлично подходит для первого знакомства с программированием дома.
• Рассчитан для новичков. Курс построен по принципу «от простого к сложному» с очень плавным нарастанием. Каждая новая концепция (цикл, условие) вводится в максимально наглядной и простой форме и связана с решением конкретной игровой проблемы.
• Фокус на фундаментальных концепциях, а не синтаксисе. Здесь учат не языку Python или JavaScript, а вычислительному мышлению: разбивать задачу на шаги, видеть закономерности, использовать абстракции (циклы) и логические условия. Это основа для любого программирования в будущем, а не только в Майнкрафт.
• Мотивирующая среда. Узнаваемые персонажи и предметы Minecraft создают высокий уровень вовлеченности. Ребенок чувствует, что решает «настоящие» игровые задачи.

Возраст и оптимальный путь обучения

• Младшие школьники (6-10 лет) — основная целевая аудитория этого курса программирования в Майнкрафт. Он подходит для детей, которые еще не готовы работать в сложной среде, но уже хотят попробовать запрограммировать любимых героев. Все уроки достаточно просты и их можно пройти самостоятельно.
• Школьники от 11 лет. Для них «Час кода» может служить первой ступенькой перед переходом на MakeCode или Education Edition. За 4-6 часов прохождения курса ребенок усваивает базовую логику, что сделает переход к текстовым языкам программирования менее пугающим.
• Для всех возрастов. Курс отлично подходит для совместного занятия родителей с детьми, где взрослый может выступать в роли наставника, обсуждая логику решений.

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

Реклама. Рекламодатель ООО «Пиксель.Стади», ИНН 5074078988, erid: 2W5zFJ5erR6

Почему связка «Minecraft + Python» работает так эффективно

Объяснять абстрактные концепции программирования бывает сложно. Но когда эти концепции встроены в знакомый и любимый игровой мир, обучение становится естественным. Поэтому программирование на Python в Minecraft — это продуманный симбиоз, где сильные стороны одной технологии дополняют другую. Рассказываем, почему это работает.

Визуальный результат и немедленная обратная связь в знакомой вселенной

В традиционном обучении код часто выполняется в «пустоте» консоли. Ребенок написал программу — она вывела текст или число. Это похоже на «взрослое» программирование, но не всегда впечатляет.

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

Эта прямая, визуальная связь между действием (написание кода) и результатом (изменение мира) закрепляет понимание. Ребенок не заучивает синтаксис, а использует его как инструмент для воплощения своих идей в Minecraft — и в итоге изучает программирование на Python, играя.

Понятные и достижимые задачи с плавным переходом от простого к сложному

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

• На начальном уровне: сделать так, чтобы при ударе по земле деревянным мечом появлялся цветок. Это учит работе с событиями (on_block_hit) и простым командам.
• На среднем уровне: запрограммировать автоматическую ферму, которая будет сажать и собирать пшеницу, когда нажимаешь на рычаг. Здесь подключаются циклы (for или while) и более сложная логика.
• На продвинутом уровне: создать портал, который телепортирует игрока в случайно сгенерированную крепость. Это уже проект, объединяющий работу с координатами, случайными числами (random module) и алгоритмами генерации.

Каждая игровая задача при программировании на Python в Minecraft — это мини-проект с четким, осязаемым результатом. Ребенок видит прогресс: сегодня он заставил зажечься лампу, а через месяц его код управляет целым умным домом в игре.

Создание собственных модов и мотивация

Для ребенка, который привык существовать по правилам игры, возможность эти правила изменить — настоящая суперсила. Именно это и позволяют сделать моды для Майнкрафт, написанные на Пайтон.

Мод — это уже не простой скрипт, это полноценное дополнение, которое меняет геймплей. И Python, с его мощными библиотеками, отлично подходит для этого.

Что можно создать:

• новый инструмент (например, кисть, которая закрашивает область выбранным блоком);
• новое существо (ручного дракона, который помогает в строительстве);
• новую механику (систему квестов с диалогами и наградами).

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

Приглашаем на наш онлайн-курс по Python и Minecraft для детей. Первый урок курса можно пройти бесплатно. На нем ребенок с помощью преподавателя создаст свой первый уникальный проект, познакомится с форматом обучения и сможет задать любые вопросы. Программирование на Python в Minecraft — это возможность для ребенка увидеть, как теория становится практикой в увлекательной игровой форме. Записаться на бесплатный пробный урок можно здесь.

Инструменты и платформы для программирования в Minecraft на Python

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

Minecraft + Python для детей без опыта в программировании: изучение основ через визуальные среды (MakeCode)

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

Ссылка на платформу: Microsoft MakeCode для Minecraft

Как работает MakeCode:

Это бесплатный онлайн-редактор, работающий в браузере. Ребенок составляет программу из блоков, а затем скачивает файл-модификацию для версии Minecraft: Bedrock Edition (это версия для Windows 10/11, Xbox, мобильных устройств). В игре активируется новый мир с вашими правилами.

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

Задачи в MakeCode понятны и визуальны: «Запрограммируй кнопку, чтобы при нажатии появлялся фонтан», «Сделай волшебную палочку, которая сажает деревья». Ребенок осваивает ключевые концепции: последовательность команд, циклы repeat и условия if, даже не подозревая, что изучает серьезные темы.

Как создание модов связано с Python? В MakeCode есть возможность переключаться между блоками и кодом. Хотя ребенок не использует Python напрямую, он изучает принципы программирования. Написав алгоритм блоками, можно переключиться на другую вкладку и увидеть, как этот же алгоритм выглядит в виде текстового кода. Это первый и очень важный шаг к пониманию, что за визуальным интерфейсом стоит реальный язык программирования.

Minecraft Education Edition для перехода на текстовый Python

Когда визуальное программирование усвоено, наступает время для первого настоящего текстового языка. Лучшая платформа для изучения Python на этом уровне — Minecraft: Education Edition.

Ссылка на платформу: Minecraft: Education Edition

Это специальная версия игры с встроенной средой программирования Code Builder. Внутри игрового мира нужно нажать всего одну клавишу (C), и откроется редактор, подключенный непосредственно к игре.

Главный объект для обучения — Агент, робот-помощник. Ребенок программирует именно его. Например, команды agent.move("forward") или agent.place("down") заставляют его двигаться и строить.

В Minecraft: Education Edition ребенок пишет код на настоящем Python. Он изучает:

• Импорт библиотек: from mcpi.minecraft import Minecraft
• Переменные: height = 10
• Циклы: for i in range(height):
• Функции: def build_wall():

На этом уровне ребенок может создавать что-то масштабное и полезное:

• Автоматическое строительство: скрипт, который по команде строит башню, пирамиду или дом заданного размера, используя вложенные циклы.
• Игры внутри Minecraft: например, игра «Угадай число», где программа загадывает число, а игрок вводит догадки через чат игры, получая подсказки «больше» или «меньше». Это учит работе с вводом-выводом и случайными числами (random.randint).

Python и Minecraft для разработчиков модов и ботов

Это уровень для подростков, которые освоили основы Python и хотят создавать по-настоящему сложные проекты, максимально приближенные к работе реального разработчика.

Для этого уровня используется стандартный Minecraft: Java Edition и специальные Python-библиотеки, такие как mcpi (Minecraft Pi API) или более мощные, как SpockBot или mineflayer (через Node.js, но управляемый Python). Здесь уже понадобится настройка локального сервера игры.

Что можно сделать на этом уровне:

Бот на Python для Minecraft — ребенок пишет не просто скрипт, а автономную программу, которая может «самостоятельно» существовать в игровом мире:

• Бот для сражений: анализирует окружение, находит мобов, атакует их, уворачивается. Это требует работы с обработкой событий в реальном времени.
• Бот-строитель по чертежу: программа может читать схему постройки из файла (например, изображения или простого текстового массива) и воспроизводить ее в мире блок за блоком.

Работа с файлами и внешними API, когда проекты выходят за рамки самой игры:

• Работа с файлами: сохранение и загрузка построек из файлов .json или .txt.
• Внешние API: подключение к внешним сервисам. Классический пример — бот, который меняет погоду в игре в зависимости от реальной погоды буквально у вас за окном. Для этого ваш скрипт будет делать запрос к публичному метеосервису, получать данные и преобразовывать их в игровую команду /weather.

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

Независимо от возраста, начинать стоит с MakeCode (даже если ребенок уже подросток). Визуальное программирование даст быстрое чувство успеха и укрепит понимание логики. Затем можно перейти ко второму уровню, чтобы глубже разобраться, как Python интегрирован в Minecraft. Третий уровень — это отличная цель для личного проекта или итоговой работы на серьезном курсе программирования.

С чего начать

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

Настраиваем окружение

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

Как начать программировать на Python в Minecraft: Education Edition

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

Что нужно и как настроить:

Нужны установленный Minecraft: Education Edition (доступен для учебных заведений и домашнего использования) и стандартный редактор кода, например, Mu Editor или Thonny (они простые и бесплатные). Настраивать ничего не нужно. Внутри игры встроен Code Builder, который сам обеспечивает связь между скриптом и игровым миром. Ребенок просто пишет код в редакторе и запускает его в игре нажатием одной клавиши.

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

Python в Minecraft для продвинутых — локальный сервер

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

Что нужно:

1. Официальная версия Minecraft: Java Edition.
2. Установленные Java и Python на компьютере.
3. Локальный игровой сервер Spigot или Paper (это специальные версии сервера, которые поддерживают плагины).
4. Плагин, который позволяет запускать Python-скрипты на сервере, например, RaspberryJuice.

Нужно запустить на своем компьютере небольшой сервер Minecraft. Плагин выступает переводчиком между командами на Python и языком сервера. Игрок подключается к этому серверу из клиента игры и может управлять им через Python-скрипты.

Поскольку это локальная сеть (ваш компьютер подключается сам к себе), рисков из внешнего интернета нет. Все происходит внутри вашего ПК.

Что можно создать? 10 проектов на Python для Minecraft

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

1. Автоматическая ферма

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

Какие навыки развивает: циклы (for для прохода по рядам), работа с блоками (определение типа блока — getBlock, его замена — setBlock), использование задержек (time.sleep) для симуляции роста.

Вот как это выглядит в коде (фрагмент):

# Упрощенная логика одного ряда

for x in range(start_x, end_x):

mc.setBlock(x, y, z, block.WHEAT_SEEDS) # Посадить семя

mc.setBlock(x, y+1, z, block.BONE_BLOCK) # Использовать "костную муку"

time.sleep(0.1)

mc.setBlock(x, y, z, block.WHEAT) # Заменить на зрелую пшеницу

2. Чат-бот для игры, дающий подсказки

Этот бот отвечает на сообщения игрока в игровом чате. Например, на команду /help выводит список подсказок, на /coords — текущие координаты игрока. Можно создать бота-гида для собственной карты с квестами.

Какие навыки развивает: обработка строк (разбор введенной команды player_message.split()), условные операторы (if player_message == "/help":), вывод информации (postToChat).

3. Генератор лабиринтов

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

Какие навыки развивает: работа с двумерными массивами (списками списков) для хранения карты, освоение простых алгоритмов (например, алгоритм поиска в глубину), использование случайных чисел (random.randint) для выбора путей.

4. Волшебная палочка, строящая замки

При нажатии правой кнопкой мыши с определенным предметом в руке (палкой) программа строит под игроком или перед ним небольшую прегенерованную структуру — например, башню с лестницей внутри.

Какие навыки развивает: обработка событий (определение, когда игрок использует предмет), работа с относительными координатами (отсчет от позиции игрока), создание и использование функций для строительства типовых элементов (build_wall(), build_roof()).

Как это выглядит в коде (фрагмент):

# Функция построения башни

def build_tower(pos_x, pos_y, pos_z, height):

for i in range(height):

mc.setBlocks(pos_x-2, pos_y+i, pos_z-2,

pos_x+2, pos_y+i, pos_z+2,

block.STONE_BRICK)

# ... код для создания внутреннего пространства и лестницы

5. Бот на Python для помощи в строительстве в Minecraft

Бот, который следует за игроком и по команде /build house строит рядом стандартный дом из заранее заданных материалов.

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

Ребенок научится автоматизировать рутинные действия и сделает первый шаг к созданию умных NPC (неигровых персонажей).

6. Метеостанция, связанная с реальным миром

Программа получает данные о реальной погоде в вашем населенном пункте через открытое API и меняет игровую погоду в зависимости от них: если в реальности идет дождь — в игре тоже начинает лить.

Какие навыки развивает: работа с внешними сетевыми запросами (библиотека requests), парсинг данных в формате JSON, интеграция разных систем — реального мира и виртуального.

7. Головоломка «Угадай пароль из факелов»

Игрок попадает в комнату с рычагами и факелами. Нужно установить факелы в определенной комбинации (последовательности), имитирующей двоичный код, чтобы открыть дверь.

Какие навыки развивает: логические операции, работа с двоичными данными, обработка состояний множества блоков (проверка, getBlock для каждого факела), создание интерактивных игровых механик.

8. Автоматический сортировщик предметов

Система из воронок и сундуков в Minecraft, управляемая на Python. Когда игрок бросает предмет в принимающий сундук, программа определяет его тип и отправляет по трубам (или телепортирует) в соответствующий тематический сундук: еда — в один, руды — в другой, оружие — в третий.

Какие навыки развивает: работа с инвентарем сущностей, сложные условия (if-elif-elif), организация логики обработки предметов.

9. Мини-игра «Выживание на платформе»

Это генератор арены в Minecraft, написанный на Python. Под игроком исчезают блоки, оставляя только движущиеся платформы. Нужно перепрыгивать с одной на другую, чтобы не упасть в лаву. С каждым уровнем скорость увеличивается.

Какие навыки развивает: создание игровых циклов, управление временем (time.time() для отслеживания скорости), динамическое изменение мира (удаление и установка блоков в реальном времени).

10. Симулятор гравитации (песок/гравий)

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

Какие навыки развивает: понимание физических симуляций в упрощенном виде, работа с циклами в обратном порядке (от нижнего блока к верхнему), визуализация алгоритмов.

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

Реклама. Рекламодатель ООО «Пиксель.Стади», ИНН 5074078988, erid: 2W5zFJSQLsz

Почему Python — идеальный «первый язык» для юного программиста

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

Главное достоинство Python — ясность. Его синтаксис (правила написания команд) создан так, чтобы код был читаемым. Сравните, как выглядит одна и та же команда — вывод текста на экран — на разных языках.

• В Python это: print("Привет, мир!")
• В Java это выглядит сложнее: System.out.println("Привет, мир!");
• А в C++ иначе: std::cout << "Привет, мир!" << std::endl;

Для новичка, особенно ребенка, команда print (на английском — «напечатать») интуитивно понятна. В Python много таких ключевых слов, взятых из обычной речи: if (если), else (иначе), while (пока). Это снижает барьер входа. Ребенок учится не просто запоминать странные символы, а формулировать логические мысли на языке, который понимает и он сам, и компьютер.

Еще одно преимущество Python — возможность получить мгновенную обратная связь и сразу увидеть действие, производимое кодом. Python поддерживает интерактивный режим в таких средах, как Thonny или онлайн-песочницы (например, Trinket).

Выглядит это так: ребенок вводит строчку 3 + 5 * 2 и сразу после нажатия Enter получает ответ 13. Потом он пишет первую команду с ошибкой, например primt("Привет"), и программа сообщает: NameError: name 'primt' is not defined, объясняя, что не знает такой команды. Это превращает обучение в диалог с компьютером и живой эксперимент, где каждая идея проверяется за секунду. Такой формат поддерживает любопытство и не дает заскучать.

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

• Веб-разработка: создание сайтов и веб-приложений с помощью фреймворков Django и Flask.
• Анализ данных и наука: Python — популярнейший инструмент для исследований. Библиотеки Pandas и NumPy помогают обрабатывать огромные объемы информации.
• Искусственный интеллект и машинное обучение: библиотеки TensorFlow и Scikit-learn делают Python лидером и в этой стремительно развивающейся области.
• Автоматизация и скрипты: написание программ для автоматизации рутинных задач на компьютере.
• Создание игр: разработка 2D-игр с помощью модуля PyGame или использование Python для создания модов в Minecraft.

Это реальные перспективы, которые открываются перед ребенком уже после первых простых уроков Python.

Урок «калькулятор на Python», который мы сегодня предлагаем, — отличный способ «пощупать» язык, получить быстрый результат и вдохновиться на большее. Он точно докажет, что программирование — это творческий и увлекательный процесс.

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

Приглашаем вашего юного программиста на онлайн-курсы Python в Школе программирования для детей «Пиксель». На них дети не просто повторяют готовые скрипты, а учатся понимать саму логику программирования. Под руководством наших педагогов-практиков ребенок освоит язык комплексно: от основ синтаксиса до работы с готовыми библиотеками и создания собственных модулей.

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

Лучший способ понять, подходит ли такой формат вашему юному разработчику, — попробовать. Первый урок курса по Python для детей можно пройти бесплатно. Это полноценное занятие, где ребенок под руководством преподавателя сразу погрузится в процесс создания и сможет оценить, насколько ему интересно двигаться дальше в мире кода. Записаться на пробный урок можно здесь.

Подготовка к старту: 10 минут на настройку

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

Вариант 1, с установкой приложения на ПК: Thonny

Thonny — это среда, созданная специально для обучения. Она отлично подходит для первых шагов, а ее встроенный «отладчик» (инструмент для поиска ошибок) поможет понять, что пошло не так, если программа не работает.

Как установить (это займет 5 минут):

1. Откройте браузер и перейдите на официальный сайт: thonny.org.
2. Найдите на главной странице кнопку «Download» («Скачать») и выберите вашу операционную систему (Windows, macOS или Linux) и нажмите на нее.
3. Сайт автоматически предложит версии, подходящие для вашей операционной системы. Просто скачайте установочный файл.
4. Запустите скачанный файл и следуйте подсказкам мастера установки (всегда нажимайте «Далее» или «Установить»). Никаких сложных настроек не требуется.

Как выглядит интерфейс:

Вариант 2, онлайн-песочница в браузере: Trinket.io

Если вы не хотите ничего скачивать и устанавливать, начните прямо в интернете. Trinket.io — это идеальная онлайн-площадка для экспериментов. Все, что нужно в этом случае, — браузер и доступ в Сеть.

Как начать работу:

1. Перейдите по адресу: trinket.io.
2. Создайте бесплатный аккаунт (это полезно, чтобы сохранять свои проекты), но для первого раза можно начать и без регистрации.
3. Нажмите на кнопку «New Trinket» выберите язык программирования (Python).
4. Откроется окно редактора кода.

Как выглядит интерфейс:

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

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

Независимо от того, выбрали вы Thonny или Trinket, сделайте следующее:

1. В главном окне редактора кода (в Thonny — большое верхнее окно, в Trinket — левая панель) напишите строки:
2. python
3. print("Привет, мир!")
4. Запустите программу. В Thonny нажмите зеленую кнопку с изображением «пуска» (▶) на панели инструментов или клавишу F5 на клавиатуре. В Trinket нажмите большую белую кнопку «Run» («Запустить») вверху.

В окне результата (в Thonny — это нижняя «оболочка», в Trinket — правая панель) вы увидите надпись:

text

Привет, мир!

Давайте подробно разберем, что произошло, чтобы понять, как компьютер нас «услышал»:

• print — это функция, то есть команда для Python. Ее единственная задача — выводить то, что указано в скобках, на экран. Само слово переводится как «напечатать».
• ("Привет, мир!") — это аргумент, то, что мы «даем в руки» команде print. Круглые скобки — обязательный признак функции.
• "Привет, мир!" — это строка, простой текст. В Python весь текст всегда заключается в кавычки (двойные " или одинарные '), чтобы компьютер понял: это не команда, а просто слова для человека.

Поздравляем! Вы только что написали, скомпилировали и запустили свою первую программу. Если надпись появилась — ваш «рабочий стол» программиста настроен правильно. Если что-то пошло не так (например, появилось красное сообщение об ошибке), проверьте, точно ли вы повторили строчку: нет ли опечатки в слове print, все ли кавычки и скобки на месте.

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

Урок по созданию калькулятора на Python

А теперь добро пожаловать на первый настоящий урок по Python для начинающих! Мы создадим не просто калькулятор, а интерактивную программу, которая будет общаться с пользователем, задавать вопросы и давать умные ответы. Это первый шаг к пониманию, как компьютер обрабатывает информацию и принимает решения.

Наша цель — создать программу, которая спрашивает у пользователя два числа и тип операции (сложение, вычитание, умножение или деление), а затем корректно вычисляет и выводит результат.

Шаг 1: Запоминаем данные и знакомимся с переменными

Представьте, что переменная — это коробка с названием, в которую можно положить какое-то значение: число, текст или что-то еще. Когда программе нужно вспомнить это значение, она просто смотрит в коробку с нужным именем.

Чтобы создать такую «коробку» и положить в нее значение, мы используем знак равенства =:

число_1 = 10

число_2 = 5

В этом примере мы создали две переменные: число_1 со значением 10 и число_2 со значением 5. Теперь, написав print(число_1), программа выведет 10.

Шаг 2: Спрашиваем у пользователя нужные числа с помощью функции input()

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

число_1 = input("Введите первое число: ")

число_2 = input("Введите второе число: ")

Теперь при запуске программы в консоли появится вопрос «Введите первое число:», и пользователь сможет ввести любое число.

Шаг 3: Преобразуем текст в число с функцией int()

Важный момент: для компьютера то, что ввел человек через input() — это просто текст (строка), даже если ввели цифры. С текстом нельзя выполнять арифметические операции. Попробуйте в оболочке Python выполнить "5" + "3". Результатом будет не 8, а "53" (конкатенация, то есть сложение строк).

Чтобы исправить это, мы используем функцию int(), которая преобразует текстовую строку, содержащую целое число, в настоящий числовой формат:

число_1 = int(input("Введите первое число: "))

число_2 = int(input("Введите второе число: "))

Обратите внимание: int() «оборачивает» input(). Это значит, что порядок действий будет таким: 1) выполнится input() и вернет текст, 2) функция int() попытается превратить этот текст в число. Если ввести буквы, программа выдаст ошибку — так компьютер говорит нам, что не может из этого сделать число.

Шаг 4: Учим компьютер принимать решения — if/elif/else

Теперь нам нужно спросить пользователя, что он хочет сделать с числами. Логика программы должна быть такой: ЕСЛИ пользователь выбрал знак "+", ТО сложить числа. ИНАЧЕ, ЕСЛИ он выбрал "-", вычесть, и так далее.

В Python для этого используются условные операторы: if (если), elif (иначе если) и else (иначе). После каждого из этих слов нужно поставить условие и двоеточие. Все команды, которые должны выполниться при истинности условия, записываются с отступом (обычно 4 пробела):

операция = input("Выберите операцию (+, -, *, /): ")

if операция == "+":

результат = число_1 + число_2

elif операция == "-":

результат = число_1 - число_2

elif операция == "*":

результат = число_1 * число_2

elif операция == "/":

результат = число_1 / число_2

else:

print("Ошибка: такой операции нет")

результат = None # Специальное значение "ничего"

Обратите внимание на двойной знак равенства ==. В программировании один знак = — это присвоение (положить в коробочку), а два знака == — это сравнение (проверить, равны ли значения).

Шаг 5: Красиво выводим ответ с f-строками

Осталось красиво показать результат. Самый удобный способ в Python — f-строки. Перед кавычками в строке нужно поставить букву f, а переменные, которые нужно подставить, поместить в фигурные скобки {}. Python автоматически заменит {число_1} на значение переменной:

print(f"Результат: {число_1} {операция} {число_2} = {результат}")

Эта строчка выведет, например: Результат: 10 + 5 = 15.

Готовый код калькулятора на Python с комментариями

1. Запрашиваем у пользователя два числа и сразу преобразуем их из текста в целые числа:

число_1 = int(input("Введите первое число: "))

число_2 = int(input("Введите второе число: "))

2. Спрашиваем, какую математическую операцию нужно выполнить:

операция = input("Выберите операцию (+, -, *, /): ")

3. Проверяем выбор пользователя и выполняем соответствующее действие:

if операция == "+":

результат = число_1 + число_2 # Складываем

elif операция == "-":

результат = число_1 - число_2 # Вычитаем

elif операция == "*":

результат = число_1 * число_2 # Умножаем

elif операция == "/":

результат = число_1 / число_2 # Делим

else:

# Этот блок выполнится, если пользователь ввел что-то отличное от +, -, *, /

print("Ошибка: такой операции нет")

результат = None # Указываем, что результата нет

4. Если результат был вычислен (то есть не равен None), выводим его на экран:

if результат is not None:

# Используем f-строку для красивого форматирования ответа

print(f"Результат: {число_1} {операция} {число_2} = {результат}")

Как можно улучшить калькулятор на Python: дополнение к уроку для новичков

1. Защита от деления на ноль. Добавьте проверку в блок с делением (/). Прежде чем делить, спросите: if число_2 == 0: и, если это так, выведите сообщение «На ноль делить нельзя!», а не выполняйте деление.
2. Бесконечный цикл. Оберните весь код (кроме первой строчки с приветствием) в цикл while True:. Это позволит производить много вычислений подряд, не перезапуская программу. Не забудьте добавить условие для выхода (например, если пользователь введет слово «стоп» вместо числа).

Куда двигаться, когда урок по Python для начинающих пройден

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

• Переменные. Вы научились хранить данные (числа, текст) в «коробках» с именами.
• Ввод и вывод. Теперь ваша программа может общаться с миром: получать данные от пользователя через input() и показывать результаты с помощью print().
• Условные операторы (if/elif/else). Вы заставили компьютер принимать решения, выбирать разные действия в зависимости от выбора пользователя.
• Работа со строками и числами. Вы поняли разницу между текстом "5" и числом 5 и научились преобразовывать одно в другое.
• Основы логики. Вы увидели, как программа выполняет команды шаг за шагом, сравнивает значения и следует по разным «веткам» кода.

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

Самый лучший способ учиться — сразу применять новое знание. Попробуйте усовершенствовать калькулятор на Python, это станет отличной практикой:

1. Защита от ошибок. Сделайте программу более надежной. Что будет, если вместо числа ввести буквы? А если при делении ввести ноль? Используйте try...except и дополнительные проверки, чтобы калькулятор давал полезные подсказки, а не просто завершался с ошибкой.
2. Новые операции. Добавьте возведение в степень, вычисление квадратного корня или остатка от деления. Это потребует изучить новые операторы или функции из библиотеки math.
3. История вычислений. Научите программу запоминать последние 3-5 операций и выводить их по отдельной команде (например, при вводе слова «история»). Для этого вам понадобится познакомиться со списками (list) — одной из самых полезных структур данных в Python.
4. Графический интерфейс (GUI). Самый эффектный шаг — превратить консольную программу в окно с кнопками и полями ввода. Начните с простой библиотеки tkinter, которая уже есть в Python. Создание даже самого простого окошка с кнопками даст базовое понимание того, как устроены привычные всем программы.

Не бойтесь экспериментировать и искать идеи. Если что-то не получается — это нормально. Каждая ошибка приближает к решению.

Где искать вдохновение: посмотрите проекты других начинающих на платформах вроде Code.org или CheckiO. Попробуйте повторить или улучшить их.

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

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

Реклама. Рекламодатель ООО «Пиксель.Стади», ИНН 5074078988, erid: 2W5zFJnMUoz