«Большинство списков бесплатных прокси на 95% состоят из нерабочих адресов, а значительная часть оставшихся — это либо „ловушки“ (honeypots), либо прокси, внедряющие скрипты в загружаемые вами страницы. Инструмент proxy‑scraper собирает публичные прокси (HTTP, SOCKS4 и SOCKS5) из более чем 700 источников и сохраняет только те, что успешно проходят все проверки. При каждом запуске программа анализирует эффективность источников, а полученный результат может преобразовать в единый ротируемый прокси‑адрес. В цифрах: за одни сутки было проверено 3,6 миллиона бесплатных прокси — работоспособными оказались 1,1%, причём более половины из тех, что ответили на первый запрос, не прошли проверку повторным запросом», — пояснил создатель проекта.

TL;DR: Ведомости КМД удобно обрабатывать в Python и pandas: привести выгрузку к плоской таблице, проверить данные, посчитать суммы и распределения, собрать отчёт или дашборд. Главное — не пропускать проверки.

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

КМД — это деталировочные чертежи металлоконструкций. Ведомости в их составе — таблицы с элементами, деталями, марками, количеством и весом. Именно такие таблицы удобно обрабатывать в Python.

Почему выгрузка не готова к анализу

• многоуровневые заголовки и объединённые ячейки;

• несколько листов с разной структурой;

• разные названия одних и тех же полей;

• числа и текст в одном столбце;

• пустые значения, дубликаты, служебные итоги;

• разные единицы измерения.

Даже суммарный вес по типам элементов начинается с выяснения, что в таблице и как читать поля. Процесс лучше делить: Excel/CSV → подготовка → проверка → расчёты → отчёт.

Подготовка в pandas

pandas читает Excel/CSV, преобразует столбцы, фильтрует, группирует и считает. Если таблица уже плоская:

import pandas as pd
df = pd.read_excel("ведомость.xlsx")
df["Вес"] = pd.to_numeric(df["Вес"], errors="coerce")
summary = (df.dropna(subset=["Тип элемента", "Вес"])
             .groupby("Тип элемента", as_index=False)["Вес"]
             .sum()
             .sort_values("Вес", ascending=False))
print(summary)

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

Проверки важнее расчёта

Число получить легко. Важнее понять, можно ли ему доверять. Проверяйте:

• обязательные поля;

• числовые столбцы;

• попадание заголовков и итогов в расчёт;

• неожиданные дубликаты;

• сходимость с контрольными суммами;

• единицы измерения.

В pandas это делается коротко:

print(df[["Тип элемента", "Вес"]].isna().sum())
print(df.duplicated(subset=["Марка", "Тип элемента"]).sum())

Набор проверок зависит от методики предприятия. Универсального правила нет, но проверки можно сделать явными и повторяемыми.

Что анализировать

• суммарный вес и количество позиций;

• распределение веса по типам элементов;

• сравнение сборок и комплектов;

• повторяющиеся детали;

• необычно тяжёлые/лёгкие позиции;

• таблицы и графики для отчёта.

Для визуализации — Plotly, для интерактивного дашборда — Streamlit. Но график лишь помогает заметить необычное значение, а не объясняет его причину.

Повторяемый сценарий

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

Что разрабатываем

Готовим курс «Мастер ведомостей» о Python и pandas для ведомостей КМД: неидеальные Excel/CSV, проверка данных, показатели, анализ сборок, визуализация, простые дашборды. Программа уточняется; будут практика, Jupyter Notebook, код и шаблоны.

Оставить заявку на уведомление о старте можно на странице курса.

Вопросы к сообществу

1. Какие операции с ведомостями вы чаще всего делаете вручную?

2. Какие проверки хотели бы сделать повторяемыми?

3. В каком виде удобнее получать результат: таблица, Excel-отчёт, графики, дашборд?

Расскажите в комментариях — это поможет выбрать сценарии для курса.

Когда пишешь код на Python, рано или поздно наступает момент, что один проект начнет ломать другой. Установили новую библиотеку, и вдруг скрипт, который вчера работал, падает с ошибкой. Знакомо? Причина обычно одна — конфликт зависимостей. Все пакеты свалены в один системный Python, версии пересекаются, и что-то обязательно отваливается.

Решение — виртуальное окружение. Это отдельная песочница для проекта: свои библиотеки, свой Python, никакого пересечения с соседями.

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

• Виртуальное окружение vs виртуальная машина. Первое — это просто отдельная папка с пакетами, второе — целая ОС. Хотя некоторые новички часто путают, и потом удивляются, почему venv весит пару мегабайт.

• venv, virtualenv, pipenv, poetry, conda. Это пять инструментов, которые решают похожие задачи, но по-разному. Для большинства проектов хватает встроенного venv — он уже есть в Python с версии 3.3, и ничего ставить не надо.

• Активация. А это самая частая точка спотыкания. Команды различаются для Windows, Linux и macOS, а PowerShell вообще блокирует скрипты по умолчанию. source .venv/bin/activate против .venv\Scripts\activate — и это только начало.

• requirements.txt. Важно помнить, что папку окружения нельзя копировать между машинами, так как она привязана к ОС и архитектуре. Вместо этого фиксируем список пакетов и разворачиваем его одной командой pip install -r requirements.txt.

• Git и .gitignore. Виртуальное окружение в репозиторий не кладут — только код и список зависимостей.

Чтобы пройти весь путь по шагам — от создания первой папки до деплоя на сервере через systemd и Gunicorn — читайте подробный гайд на сайте Рег.облака.

Если вы пишете код на Python, рано или поздно встает вопрос: в чем его писать? Вариантов масса: от блокнота до тяжелых IDE вроде PyCharm. Visual Studio Code — отличный компромисс — он легкий, но при этом умеет почти всё, что нужно для комфортной работы. Но сложность в том, что из коробки он бесполезен, пока не настроишь интерпретатор, расширения и окружение. И вот тут начинается самое интересное.

Вот с чего стоит начать и что стоит разобрать, если вы только садитесь за настройку:

• Интерпретатор. VS Code хранит и редактирует файлы, но код выполняет отдельная программа. Пока вы явно не укажете, какой Python использовать, редактор будет гадать и часто ошибаться.

• Виртуальное окружение. Без него все библиотеки ставятся в общую систему, и рано или поздно два проекта потребуют разные версии одной и той же библиотеки. Что-то одно сломается.

• Расширения. Pylance отвечает за автодополнение, Python Debugger — за отладку по шагам, Ruff — за линтинг и форматирование. Но если поставить всё сразу, инструменты начнут конфликтовать между собой.

• Отладка вместо print(). Точки остановки и панель переменных позволяют увидеть, что реально происходит в коде, вместо того чтобы гадать, где закралась ошибка.

Каждый из этих пунктов — отдельная история с нюансами под Windows, macOS и Linux. Где-то команда называется python, где-то python3. Где-то нужно вручную добавить PATH, где-то переустановить Python из официального пакета.

Если хотите пройти весь путь по шагам: от установки редактора до запуска первого скрипта с отладкой, читайте полное руководство на сайте Рег.облака.

Нюанс №1
У части пользователей незаметно включается Adaptive, а по умолчанию рядом маячит Fusion. В итоге ты думаешь, что работаешь на бесплатном SWE-2, а квота уезжает на роутер или lead-модель.В Fusion SWE-2 может быть только допом, а Fable/Astra/Sol платной основой. Дневная квота много у кого горит
Нюанс №2
Бесплатно не значит безлимитно по скорости. По ощущениям, после 5–6 параллельных сессий TPS режется примерно со 100 до 70, в пик может падать до 30. Плюс периодически прилетают 429, и API притормаживает
Чтобы не платить за соседей:

devin --model swe-2-high
/model swe-2-high
/session-stats

В конфиге закрепить (например) %APPDATA%\devin\config.json,

{
  "agent": {
    "model": "swe-2-high"
  }
}

Ну а /fusion, /model adaptive и /handoff не трогать. В статистике должна быть одна модель SWE-2, без Lead/Sidekick, и quota не должна уменьшаться.

P.S. Низкий порог входа по почте и слабая привязка к устройству сделали промо очень удобным для мультиаккаунтинга. Те 1 аккаунт за 20$ на почту + vps + cliproxyapi =>десятки индусов абузят через сабагентов. А еще конечно это по сути бесплатная мощная модель для любых ваших ИИ продуктов

P.P.S. 100% включат недельные квоты для free tier, но попробуй успеть пока не разобрали

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

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

Есть смысл в маркетинге для разрабов? Что думаете?

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

В основной отчет по проверке web-ресурса входит:

• email-адреса;

• телефоны по российским и американским форматам;

• телефоны из HTML-полей tel, phone, telephone, mobile и аналогов;

• адреса из специализированных полей и строк с явными адресными признаками;

• источники только тех страниц, где найдены контакты;

• внешние домены;

• внешние API endpoint-ы;

• внешние JavaScript-файлы;

• агрегированные счётчики обхода;

• DNS, IP и reverse DNS;

• RDAP и WHOIS;

• TLS-сертификат;

• цепочка перенаправлений;

• найденные поддомены;

• локальная история DNS/TLS;

• ограниченное сканирование TCP-портов исходного домена и определение технологий;

• технологии, используемые на сайте

Репозиторий проекта: https://github.com/Bednyakov/PhishIntel

«Никаких теней. Никакой неряшливости, свойственной Mermaid. Семантические паттерны описывают поведение отдельно от компоновки, поэтому такие элементы, как очередь, трассировка политик или граница доверия, могут использовать ближайший существующий тип без необходимости создавать новые. Статичный HTML используется по умолчанию; для последовательных пояснений доступна опциональная анимация. Инструмент также позволяет перерисовывать схемы из форматов draw.io, Mermaid или Excalidraw, задавая нужный формат, размер и уровень детализации. Никакой Figma. Никаких стандартных блоков со скруглёнными углами. Никаких 30-минутных сеансов подбора цветов», — пояснил автор решения.

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

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

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

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

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

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

Двумя неделями раньше — ошибка того же рода

Журнал, который проверяет только автор, ничего не доказывает. Поэтому верификатор написан на другом языке: пишет Python, проверяет TypeScript.

На тесте, где JS-верификатор читает журнал, созданный Python, выяснилось, что json.dumps сериализует 0.0 как "0.0", а JSON.stringify то же число — как "0". Строки разные, хеши разные, одна и та же честная запись хешируется по-разному.

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

def _jcs_numbers(value: Any) -> Any:
    """Приводит числа к форме, одинаковой в Python и JavaScript."""
    if isinstance(value, bool):
        return value
    if isinstance(value, float) and value.is_integer():
        return int(value)

Проверка на bool не паранойя: в Python True — экземпляр int, без этой ветки булево уехало бы в числовую нормализацию.

Писал бы верификатор я сам, на том же Python, — ошибка дожила бы до первого спора с клиентом.

Функция, которой намеренно нет

Проект отдаёт наружу MCP-сервер, JSON-API и ноду n8n. Все три умеют выполнять шаги, спрашивать разрешение и читать журнал. Ни один не умеет подтверждать.

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

Что вынес

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

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

Альфа, 115 тестов, ноль зависимостей, AGPL-3.0: github.com/oleg-vdv/kepil. Верификатор отдельно и под MIT: agent-trace.

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

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

• использовать только аудиоданные

• использовать только CPU

• уверенно меньше 20% ложных не\срабатываний для обеих классификаций - exclude_disliked and include_liked

Над решением успели поработать opus 4.8 (основная архитектура решения), fable 5 (ревью архитектуры; да-да, надо было наоборот, но архитектура была собрана до выхода fable) glm-5.2 (прикладные планы реализации задач) и 5.3 (прикладные планы+доведение пайплайна до рабочего состояния)

По архитектуре железный друг: 

• предложил тот же подход, что я использовал, но выкинул polars, вместо которого решил использовать duckdb. Когда он понял, что его не получится нормально развернуть на nfs, мы сошлись на хранении фич файлами parquet, а duckdb-базу билдить локально при запуске обучения - уж очень удобно ее использовать

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

• для процессинга агент сам предложил взять ту же essentia, но вместо навеса моделей на нее - предложил взять panns

• примитивы обучения взял те же: mean k-NN distance+GMM log-likelihood+IsotonicRegression. Предложил обучать по одной single-class модели на include_liked и exclude_disliked, но делать это за один проход. На метрику какой из моделей смотреть - решаем на уровне подписки

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

• модель подкинула критерий, который позволяет выделить фичи наиболее различные в датасетах. Не просто PCA, а выбрать те фичи, за счет которых мы различаем liked/disliked. 4k фич сжались до 64х - это значительно повысило точность ML-моделей за счет размерности

• но даже после этого exclude_disliked продолжала сильно страдать false positive'ами - эксклюдила что нужно и что не нужно. И тут агент предложил балансировать вывод этой модели выводом include_liked классификатора. Т.е. если exclude_liked считает, что трек надо выкинуть, то прежде чем вернуть это решение мы смотрим на include_liked скор этого трека. Если он высокий - трек остается. С таким подходом качество модели стало выше, мой исходный подход показывал когда-либо

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

Единственной сохранившейся проблемой остается довольно высокое потребление памяти при процессинге - каждый воркер, извлекающий фичи из аудио, потребляет 1.5-2ГБ. Но размен памяти на процессинг на CPU - вполне приемлем при локальном использовании

RAG (Retrieval-Augmented Generation) — подход, при котором генеративные модели ищут ответы не только в своей внутренней «памяти», но и в ваших данных через векторный поиск и используют их для ответа. Так вы получаете более точные результаты без дообучения модели.

На бесплатном вебинаре «Создание RAG-системы на базе Qdrant» покажем процесс создания RAG-системы с использованием векторной базы данных Qdrant.

📆 Когда: 10 сентября в 18:00 (Мск)
👨‍🎓 ️Спикер: Елисеев Илья, эксперт в области Python и машинном обучении, анализе данных и бизнес-процессов

Вы узнаете:
👾 Что такое RAG и как расширить «память» генеративных моделей без их дообучения.
👾 Типы векторных данных. Полнотекстовый и семантический поиск.
👾 Чанкинг данных: как разбивать текст на части для эффективного поиска.
👾 Основы работы с Qdrant: установка, настройка и использование.
👾 Создание RAG-системы: пошаговое руководство по интеграции генеративной модели с Qdrant.
👾 Практика: пример создания RAG на базе редких литературных текстов и LLM.

✍️Записаться

Сотрудники компании (разработчики, поддержка, юристы) активно используют ChatGPT, Claude и Cursor. В промпты летят ФИО клиентов, ИИН/ИНН, карты, API-ключи и бизнес-логика. С точки зрения RegTech (152-ФЗ, Закон РК № 94-V, GDPR) — это прямая утечка данных.

Обычный DLP просто заблокирует доступ, снижая продуктивность[cite: 1]. Мы сделали AI-Gateway — open-source шлюз с обратимой токенизацией (Reversible Tokenization), который маскирует ПДн до отправки в LLM, восстанавливает их в ответе и ведет защищенный лог.

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

1. Исходный промпт от пользователя/приложения:

«Клиент Ержан Нурсултанулы, ИИН 900715300005, оспаривает транзакцию по карте 4400 1234 5678 9101…»

2. Уходит во внешнюю LLM (ChatGPT/Claude/Gemini):

«Клиент [PERSON_1], ИИН [NATIONAL_ID_1], оспаривает транзакцию по карте [PAN_1]…»

3. Возвращается в приложение / браузер:

«…для Ержан Нурсултанулы (ИИН 900715300005) по карте 4400 1234 5678 9101 возврат…»

Модель помогает решить задачу, пользователь получает полный ответ, а вендор не получает ни одной персональной записи[cite: 1].

Ключевая архитектура

1. Обратимая токенизация, а не удаление. Замена сущностей на [PERSON_1] сохраняет связность текста для LLM[cite: 1]. Соответствия хранятся только в OAM (Mapping Store) в зашифрованном виде (PRF-CTR + HMAC) и автоматически удаляются после ответа[cite: 1].

2. Проверка по контрольным суммам. ИИН/БИН проверяются двухпроходным весовым алгоритмом, карты — по алгоритму Луна (Luhn), IBAN — ISO 13616[cite: 1]. Секреты (AWS, OpenAI, JWT, PEM) детектируются по формату и энтропии Шеннона[cite: 1].

3. Zero-Dependency Core (Python 3.11+ stdlib). Поверхность атаки на Supply Chain инструмента, видящего все промпты — ровно ноль[cite: 1]. Устанавливается в Air-Gapped контур без pip install[cite: 1].

4. Принцип Fail-Closed. Любая ошибка распарсинга или сбой детекции блокирует запрос[cite: 1].

5. Tamper-Evident Audit Log. Append-only JSONL с цепочкой хешей SHA-256[cite: 1]. Любое редактирование записи нарушает целостность лога[cite: 1].

Три канала перехвата

• Egress Proxy: Меняем base_url в OpenAI SDK (http://aigate.internal:8080/v1)[cite: 1]. Код приложений менять не требуется[cite: 1].

• Browser Extension (Manifest V3): Перехватывает ввод в ChatGPT/Claude/Gemini прямо в браузере до отправки на сервер[cite: 1].

• Endpoint Agent: Отслеживает буфер обмена (clipboard) для вставки в IDE (Cursor, Claude Desktop)[cite: 1].

Маршрутизация в локальные LLM

Можно настроить правило: промпты без ПДн идут в ChatGPT/Claude, а промпты с найденными чувствительными данными автоматически перенаправляются на локальный Ollama / vLLM (Llama 3.1)[cite: 1].

Быстрый запуск

git clone [https://github.com/oleg-vdv/AI-Gateway.git](https://github.com/oleg-vdv/AI-Gateway.git)
cd AI-Gateway
cp .env.example .env
docker compose up -d

1. Завязка. Три дедлайна: США — PQC для новых госзакупок нацбезопасности с 2027 (EO 14412 / CNSA 2.0, там прямо назван CBOM), Великобритания — полная криптографическая инвентаризация и план миграции к 2028 (NCSC), ЕС — переход с конца 2026. Первый вопрос аудитора одинаковый: «где именно у вас используется RSA?» Ответа нет почти ни у кого.

2. Что такое CBOM и почему это не то же самое, что SBOM.

3. «Harvest now, decrypt later» — почему это не про далёкое будущее: трафик записывают сегодня, расшифруют потом. Если у секрета срок жизни больше нескольких лет — проблема уже наступила.

4. Как работает сканер. Одна команда, три артефакта: CycloneDX 1.6 CBOM, отчёт с планом миграции на ML-KEM/ML-DSA, SARIF для GitHub code scanning. Плюс scan-tls — одно рукопожатие и вердикт по живому эндпоинту.

5. Байка про баг (Хабр это любит): первый же регрессионный тест поймал, как сканер находит «криптографию» в собственных регулярках. Лечилось маскировкой литералов RSA_generate_ke[y], и теперь есть вечный тест, что репозиторий подсвечивает только свои фикстуры.

6. Честный бенчмарк против PQCA CBOMkit. Не «мы лучше», а «мы разные»: CBOMkit глубже на Java/Python (знает размеры ключей, симметрику), мы шире (10+ языков, конфиги, сертификаты) и быстрее (0,05–0,12 с против минуты). Прямая ссылка на docs/BENCHMARK.md — воспроизводимо кнопкой в CI.

7. Ограничения честно: v0 на паттернах, динамические вызовы пропустит, отсутствие находок ≠ отсутствие проблем. AST-движок в планах.

8. Финал: вопрос к читателям — у кого уже спрашивали CBOM и в каком виде.

Может я не прав, но 8 лет пердения в офисный стул — сомнительный фильтр для выбора разработчика.

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

В общем, писать софт для кибербеза с другими дедами мне пока рано. Слишком молодой специалист.

«Я копался в папке ~/.cache/ с помощью OmniDiskSweeper и заметил кое‑что интересное. В папке codex‑primary‑runtime настольного приложения OpenAI Codex (позже переименованного в ChatGPT) находится 1,7 ГБ файлов, включая полную установку Python, полную установку Node.js, а также нативные бинарные файлы для Poppler, git и офисного пакета LibreOffice с открытым исходным кодом (который отделился от OpenOffice.org в 2010 году)», — пояснил исследователь Саймон Уиллисон.

Она довольно внушительная, LLM не поскупилась на требования к кандидату, но если кратко:

• нужен один разработчик

• весь бэкенд нужно построить с нуля, так как сейчас он держится на решениях из го*на и гугл таблиц

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

• агентный слой из роя агентов в проде тоже очень надо

• фронтенд на next.js тоже очень надо

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

• Cloude Code, Cloude Code, Cloude Code

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

Так выглядит рынок нанимателя 2026.

Сделал Laconian - agent skill, построенный вокруг принципа the shortest complete answer. Не самый короткий ответ вообще, а самый короткий из тех, которые остаются корректными и практически полезными.

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

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

Вся пользовательская часть проекта — один файл SKILL.md. В нём нет скриптов, зависимостей, сетевых вызовов, дополнительных разрешений или привязки к инструментам конкретной платформы.

В репозитории также развивается открытый benchmark: Laconian сравнивается с baseline, обычной инструкцией Answer concisely. и Caveman. Инфраструктура уже работает, но публичных результатов пока нет — поэтому пока не заявляю о выигрыше в длине, качестве или стоимости раньше данных.

Ссылки

• Сайт

• GitHub

• tg

24 августа вышел Telegram Bot API 10.3. В нём появилась полезная функция для AI-ботов: пользователь может остановить генерацию ответа штатной кнопкой Telegram.

В методы sendMessageDraft и sendRichMessageDraft, которые позволяют показывать черновик ответа в личном чате, добавили два параметра:

• can_stop=True — показывает кнопку остановки;

• keep_on_stop=True — временно оставляет уже сгенерированную часть ответа в чате.

Когда пользователь нажимает кнопку, бот получает обновление stopped_message_generation. В нём есть chat, message_thread_id и draft_id, поэтому событие можно связать с конкретной генерацией.

Если вы явно задаёте allowed_updates, новый тип обновления нужно добавить туда. Иначе нажатие кнопки просто не попадёт в обработчик.

Но Telegram останавливает только показ черновика. Запрос к LLM на стороне бота продолжит выполняться, пока разработчик сам его не отменит.

Например, можно хранить задачи по ключу из идентификаторов чата, темы и черновика:

key = (chat_id, message_thread_id, draft_id)

active_generations[key] = asyncio.create_task(
    generate_answer()
)

При получении stopped_message_generation находим задачу и отменяем её:

event = update.stopped_message_generation
key = (event.chat.id, event.message_thread_id, event.draft_id)

task = active_generations.pop(key, None)

if task is not None:
    task.cancel()

    try:
        await task
    except asyncio.CancelledError:
        pass

Это упрощённый пример: конкретный обработчик зависит от используемого фреймворка.

Одного task.cancel() тоже не всегда достаточно. Отмена в asyncio кооперативная: задача остановится только тогда, когда управление вернётся в event loop. Если внутри работает синхронный код или отдельный поток, он может продолжить работу.

Нужно также закрыть потоковое HTTP-соединение с провайдером модели. А если провайдер поддерживает отдельный API отмены, вызвать и его. Иначе модель может продолжить генерацию — вместе с расходом токенов — даже после закрытия соединения.

По сути, здесь есть три независимых действия:

• Telegram прекращает показывать черновик;

• бэкенд отменяет локальную задачу и закрывает соединение;

• провайдер модели останавливает генерацию, если умеет это делать.

Ещё один нюанс касается keep_on_stop=True. Остановленный черновик не превращается в обычное сообщение. Он исчезнет после следующего сообщения в чате или примерно через 30 секунд.

Если частичный ответ нужно сохранить, его придётся отдельно отправить через sendMessage или sendRichMessage.

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

Telegram добавил удобный интерфейс, но жизненный цикл генерации всё равно остаётся на стороне разработчика.

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

В Telegram Desktop 7.1.0 появился новый тип подключения — WEB proxy. Его уже успели описать как способ, с помощью которого Telegram может выглядеть для сети как обычный HTTPS-сайт.

Если сильно упростить официальное описание архитектуры, работает это так:

1. Клиент сохраняет обычный MTProxy framing и шифрование.

2. Соединения проходят через скрытый WebView внутри приложения.

3. WebView передаёт несколько логических потоков через один или несколько HTTPS- либо WebSocket-соединений с тем же доменом.

4. Серверный relay разделяет потоки и передаёт каждый локально запущенной официальной реализации MTProxy.

При этом relay видит только непрозрачный поток данных: он не расшифровывает содержимое и не выбирает Telegram-сервер назначения.

Указанный домен продолжает работать как обычный HTTPS-сайт. Если запрос не содержит корректного capability, вычисленного из домена и секрета WEB-прокси, посетитель получает публичную страницу. Bridge открывается только клиенту с правильными параметрами подключения.

Сейчас готовая реализация работает в Telegram Desktop. Для Android существует экспериментальный клиент, а поддержка iOS пока описана только в планах проекта.

Что это меняет для разработчика бота

Сам WEB-прокси обслуживает соединение Telegram-клиента с инфраструктурой мессенджера. Он не становится общим туннелем для всех компонентов продукта.

По-прежнему существуют отдельные сетевые контуры:

• Telegram Desktop пользователя → WEB-прокси → Telegram;

• сервер бота → api.telegram.org;

• Telegram → webhook endpoint бота;

• Mini App → домен, на котором размещено веб-приложение.

Если сервер бота потеряет доступ к api.telegram.org, результат будет зависеть от способа получения обновлений.

При long polling бот перестанет и получать обновления, и вызывать методы Bot API.

При webhook входящие обновления ещё могут приходить, если endpoint доступен извне. Однако обычные исходящие обращения к Bot API работать не будут. Есть редкое исключение: Telegram разрешает передать один метод Bot API прямо в HTTP-ответе на webhook. Но узнать результат выполнения такого метода бот уже не сможет.

WEB-прокси также не восстановит недоступный webhook и не поможет загрузить Mini App, если проблема возникла с доменом самого веб-приложения.

Это не недостаток новой технологии. Просто WEB-прокси решает задачу доступности клиента, а не отказоустойчивости сторонней инфраструктуры.

Что по-прежнему остаётся на стороне разработчика

Для long polling нужно отдельно контролировать доступность Bot API и задержку получения обновлений.

Для webhook полезно отслеживать через getWebhookInfo как минимум:

• pending_update_count;

• last_error_date;

• last_error_message.

Обработку обновлений лучше делать идемпотентной: если webhook отвечает кодом вне диапазона 2xx, Telegram повторяет доставку. А слепой повтор исходящих методов вроде sendMessage, наоборот, способен создать дубли.

Получается, фраза «Telegram у пользователя открылся» ещё не означает, что бот, webhook и Mini App тоже работают.

Подскажите, держите ли для Bot API резервный egress или HTTPS-прокси? И состояние webhook вы контролируете через getWebhookInfo или ограничиваетесь метриками самого приложения?

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

• анализирует любые файлы: изображения, видео, схемы, таблицы, документы, формулы и даже аудио.

• выдвигает гипотезы как настоящая команда учёных.

• проверяет информацию до последней запятой, чтобы не было ни одной выдумки или неточности;

• строит графики, таблицы и схемы;

• собирает результат в PDF и отдаёт в удобном формате;

• знает русский язык и ориентируется в культурном контексте;

• может подключаться к различным ИИ‑агентам;

• работает на Windows, macOS и Linux.

Проект помогает быстро собрать технический профиль домена и оценить потенциальный фишинговый риск в формате структурированного JSON-отчёта.

Что проверяет PhishIntel:

• DNS-записи, IP и reverse DNS;
• RDAP/WHOIS и регистрационные данные;
• HTTP, TLS-сертификаты и цепочки редиректов;
• содержимое веб-страниц, формы и внешние action;
• упоминания брендов и фишинговых ключевых слов;
• используемые веб-технологии;
• sitemap и обнаружение распространённых поддоменов;
• локальную историю изменений DNS и TLS;
• контекстный explainable scoring — с пояснением, почему домен получил тот или иной уровень риска.

Инструмент работает автономно, не требует обязательного доступа ко всем сетевым сервисам и продолжает формировать отчёт даже при недоступности DNS, HTTP или TLS-проверок.

Запуск:

python3 scan.py example.com

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

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

"Изучи технический отчет домена и дай оценку потенциальному фишинговому риску, составь краткий человекочитаемый отчет"

Инструмент писал для личных нужд, но может он будет полезен детективам, безопасникам и OSINT-специалистам.

🔗 Репозиторий: https://github.com/Bednyakov/PhishIntel

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

Недавно я познакомился с безумно хорошим инструментом для улучшения качества вашего питоновского кода - wemake-python-styleguide

Изначально проект позиционировался как простой плагин для flake8, но с куда большим количеством правил, он стал настолько большой что его нужно воспринимать как полноценный линтер. Кстати, он полностью совместим со ВСЕМИ правилами от ruff. И что важно, его развивает core-разработчик CPython — Никита Соболев.

Я считаю, что каждую ошибку, который он подсвечивает, это не чья-то прихоть, а реальный опыт поддержки самого языка. При этом линтер не перегибает палку: нарушения объясняются. Например, если ваш агент написал if x > 42 линтер выдаст ошибку WPS432 («magic number used»). Достаточно вызвать wps explain WPS432 (или отправить MCP-запрос), и вы получите развёрнутое пояснение, почему магические числа это плохо, и как их заменить на константу, кстати именно в новой версии появилась эта функциональность, теперь объяснения приходят прямо в контекст агента, плюс появились скиллы. Вообщем сделано так, чтобы улучшать код и не раздражать разработчика :)

Авторы проверили эффект на семи семействах открытых моделей размером от 3,8 до 36 млрд параметров. В эксперименте входные токены после rollback были идентичными, а различался только KV-кэш: в одном случае использовался старый кэш с отменённой веткой, в другом он заново строился только из подтверждённой истории. Старый KV-кэш изменил защищённое действие агента в 25 из 63 тестов, хотя данные атакующего отсутствовали в текущем запросе во всех 63 случаях. После перестроения кэша эффект исчез во всех тестах - 0 из 63.
Авторы также воспроизвели проблему через стандартный механизм повторного использования кэша в Hugging Face Transformers и через LangGraph time-travel. В тестах с LangGraph логический rollback был выполнен корректно, но сохранённое состояние KV оставалось старым; эффект проявился в 25 из 45 проверок. То есть журнал агента может выглядеть полностью корректным, хотя фактическое состояние, на которое смотрит модель, ему уже не соответствует.

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

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

В последнюю неделю августа пройдут два бесплатных вебинара:

🟣 «ИИ-видео без съёмочной группы: от промпта до контент-завода»

25 августа, 17:00–18:00 (Мск).

Поговорим про системный подход к генерации видео. Вместо случайных результатов — управляемый промпт в формате JSON с параметрами сцены, персонажа, ракурса, освещения и звука. Демонстрация на живом примере: от задачи на русском до готового ролика. Сравнение генераторов Kling, Veo 3, Seedance и Wan. Построение контент-конвейера: сценарий → промпт → генерация → монтаж → публикация.

Опыт работы с нейросетями не обязателен.

✍️ Записаться

---

🟢 «Стабилизация Python-автотестов: причины и инструменты»

28 августа, 17:00–18:00 (Мск).

Обсудим причины нестабильности автотестов — в тестах, инфраструктуре или продукте. Разбираем flaky-тесты и гейзен-баги, применяем плагины pytest-retry и pytest-flakefinder, осваиваем стратегию экспоненциальных ожиданий с библиотекой tenacity.

Рекомендуется опыт разработки тестов на Python.

✍️ Записаться

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

Ошибка 1. Проскальзывание применялось только в live-контуре, но не в историческом бэктесте (комиссии были в обоих). Честный пересчёт: Sharpe системы ~2.7 → ~1.8, доходность за пять лет +75% → +47%. Треть доходности уходила в неучтённые издержки.

Два поворота. Бенчмарк (SMA-кросс) торгует чаще нейросети и пострадал сильнее (Sharpe 0.98 → 0.59) — отрыв системы от него после исправления даже вырос. А LightGBM-бейзлайн, который с одними комиссиями показывал «скромные, но плюсовые» +5%, с полными издержками ушёл в −19%: его кромка была тоньше издержек. «Модель немного зарабатывает после комиссий» — это не результат, а вопрос, какие издержки вы забыли.

Ошибка 2. Я публиковал стресс-тест: замороженная модель на чужой эпохе (2015–2020) теряет −28%, вывод — «в чужом режиме опасна». Аудит нашёл дыру в самом тесте: часть признаков физически существует только с 2020–2021, и загрузчик молча подставлял вместо них нули (виноват except: pass, «удобно» глотавший отсутствующую таблицу). Тест мерил не модель в чужой эпохе, а модель, ослепшую на две трети входов.

Перемер зрячей версией (только признаки, существующие в обеих эпохах): +22% вместо −28%, все шесть лет от −1% до +8.5%. Катастрофы не было — минус рисовали нули в данных, а не смена режима.

И каскадное следствие: раньше казалось, что от «катастрофы» спасает еженедельное переобучение (walk-forward на той эпохе давал +17%). Теперь видно: зрячая замороженная модель даёт +22% — переобучение ничего не спасало, спасать было нечего.

Чек-лист, если хотите проверить свой бэктест на те же грабли:

1. Все ли слои издержек применяются во всех симуляторах, или только в одном?

2. Бенчмарк несёт те же издержки? Частота сделок разная — эффект несимметричен.

3. Существуют ли все признаки модели на всём периоде стресс-теста?

4. Есть ли в загрузчиках данных молчаливые except, превращающие отсутствующую таблицу в нули?

5. Стресс-тест показал катастрофу — сначала проверьте тест, потом модель.

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

Не является индивидуальной инвестиционной рекомендацией.

📐 Применение природных алгоритмов оптимизации в строительном проектировании

Современное проектирование несущих конструкций — это всегда поиск баланса между жёсткими требованиями безопасности и экономической эффективностью. Классические градиентные методы часто не справляются с многомерными пространствами ограничений, характерными для задач ПГС. Поэтому в САПР и ТИМ-решениях всё чаще применяются алгоритмы, подсказанные природой.

🧬 Генетические алгоритмы (GA) Основаны на естественном отборе и эволюционной генетике. В проектировании используются для оптимизации топологии и сечений элементов. Классические примеры — подбор оптимальных размеров подошвы и глубины заложения фундаментов, оптимизация сечений балок и рам. Алгоритм итеративно “скрещивает” варианты, отсеивая решения с недопустимыми осадками, недостаточной несущей способностью или перерасходом бетона.

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

🐜 Алгоритмы роевого интеллекта (Swarm Intelligence) Моделируют поведение групп организмов: миграцию птиц, поиск пищи насекомыми. Наиболее известны метод роя частиц (PSO) и муравьиный алгоритм (ACO). Применяются для трассировки инженерных сетей, автоматического армирования плит, оптимизации геометрии сложных фундаментов. PSO эффективно распределяет усилия по расчётной сетке конечных элементов, снижая концентрацию напряжений за счёт корректировки параметров армирования локальными агентами.

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

🔥 Алгоритмы имитации физических процессов К ним относится метод имитации отжига (Simulated Annealing), который моделирует кристаллизацию металла при охлаждении. Используется для решения комбинаторных задач: календарное планирование, оптимизация логистики движения материалов, расстановка монтажных кранов, распределение бригад по захваткам при жёстких пространственных и временных ограничениях.

⚠ Ограничения и инженерная практика При всех возможностях природные алгоритмы не заменяют классические расчётные комплексы (МКЭ/FEM). Сегодня они выступают как эффективные препроцессоры: генерируют концептуальные схемы расстановки несущих элементов, варианты раскроя и календарные графики, которые затем проходят обязательную ручную верификацию инженером-конструктором и финальный проверочный расчёт в сертифицированном ПО на соответствие СП/СНиП.

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

# Не судите строго, впервые пиши пост, понимаю, что может быть не интересно (по причине опыта), но все же хочется внести свой вклад

Всем привет! Меня зовут Фаина я уже несколько лет пишу на Python (и не только) и зарабатываю этим на жизнь. Недавно я наткнулась на свои старые "конспекты" с первых попыток изучения языка. Это было... больно. Сотни скриншотов, обрывочные заметки и полное непонимание того, что происходит.

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

1.Перестать коллекционировать курсы (и начать делать)

Моя самая главная ошибка — «синдром хомяка». Я скачала, наверное, 50 ГБ курсов: "Python с нуля", "Python для чайников", "Python за 24 часа". Я смотрела первые два урока, чувствовала себя умной, а потом бросала, потому что "этот курс не очень".

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

2.Сначала гуглить, потом — паниковать

В начале пути любая ошибка в коде вызывала у меня панику. Красный трейсбек выглядел как приговор. Я думала: "Ну всё, я бездарь, Python меня ненавидит".

Итог: Ошибка — это не "я плохая", это "код говорит мне, что именно не так".
Сейчас 80% моей работы — это чтение ошибок и гугление.

3.Зубрежка синтаксиса не работает. Работают проекты

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

Итог: Ты запоминаешь только то, что используешь руками.
Вместо заучивания теории, я бы начала писать мини-программы с первого дня.

• День 3: Калькулятор чаевых.

• Неделя 2: Парсер курса валют с сайта (с помощью requests).

• Месяц 1: Простенький телеграм-бот, который присылает погоду.

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

Если ультра-кратко:

1. Лучше уж один источник знаний вместо "все сразу"

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

3. Ошибки - это норм, не стрем

4. С другом или ментором будем веселее и эффективнее - с кем можно поделится опытом или обсудить код и тд.

Спасибо за внимание, ваша Фаина!)

Иногда, когда я добавляю какие-то фичи в мой https://github.com/wemake-services/django-modern-rest (можно ставить ⭐), то я думаю про себя: почему таких фичей больше нет нигде? 

Давайте сегодня посмотрим на них. А вы мне расскажите свое мнение в комментах.

Семантическая схема 

Допустим, вы навесили на какой-то свой endpoint auth: 

class UserController(Controller[MsgspecSerializer]):
      @modify(auth=[JWTAsyncAuth()])
      async def get(self) -> User: ...

В OpenAPI автоматически появятся все коды ошибок, которые могут случиться в auth (401).
Ничего не надо допом писать. И так происходит со всеми частями фреймворка: добавил throttling=[SyncThrottle(1, Rate.minute)]? Теперь у тебя в ответах автоматом 429. Если нужно, можно отключить любые семантические статусы. 

Не должно ли такое быть дефолтом везде?

Умные типы ошибок

Не уходя далеко: как кастомизировать формат ошибки, например, в FastAPI? Через боль. Как поменять в спеке формат? Руками.

В DMR мы просто добавили везде error_model как параметр. Можно заменять любые ошибки, все автоматом сконвертится и покажет правильную схему. Зачем? Хочешь Problem Details - используешь. Хочешь свой формат - реализуешь. Можно даже content negotiation на ошибки навесить.

Почему никто о таком не думает в других фреймворках?

Нормальный throttling

Фича, которая принесла мне больше всех боли. Я прочитал throttling реализации во всех фреймворках. В Litestar даже фиксы присылал. 

1. Почти нигде из коробки нет поддержки разных алгоритмов, бекендов, иногда даже cache-keys. Очень жаль, есть только обычный counter с бекендом в памяти
2. Нигде (пришлите в комменты контр-пример) нет разделения на throttling до auth и после. Почему такое вообще важно? Чтобы не заддосить auth. И чтобы иметь возможность выдавать per-user правила. Нужны и важны оба варианта
3. Кастомизация заголовков ответа? Ха!

Что? Почему?

Простое переиспользование кода

Когда я смотрю на АПИ разных DRF проектов или FastAPI, мне становится больно. FastAPI строит все на view функциях, которые нельзя нормально кастомизировать. А DRF строит все на импортах строк внутри настроек. А как на счет классов и наследования?

У нас подобное сделано как абстрактные generic классы. Например: получить JWT. Можно выбрать любой сериализатор, можно выбрать любые модели для запроса и ответа:

class RequestPayload(pydantic.BaseModel):
     username: str
     password: str

class ResponsePayload(pydantic.BaseModel):
     access: str
     refresh: str

class ObtainAccessAndRefreshSyncController(
    ObtainTokensSyncController[
        PydanticSerializer,
        RequestPayload,
        ResponsePayload,
    ],
): ...  # надо еще переопределить 2 метода

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

Внешние вьюхи

Интегрировать один фреймворк в другой - крайне сложно. Вот мы недавно даже стрим проводили, потому что не могли использовать dj-rest-auth из DRF. Так быть не должно.

Теперь в DMR можно использовать любые внешние Django View. Хоть DRF, хоть django-ninja, хоть ванильные вьюхи. И отображать любой внешний OpenAPI. Вот настолько просто:

raw_schema = read_openapi_yaml('openapi.yml')
router = Router(
    urls=[
        external_path(
            'number/', number, name='number',
            openapi=load_schema(raw_schema['paths']['/api/number'], PathItem),
        ),
    ],
)

Почему другие фреймворки не стараются вписать существующие решения?

Одной строкой

- Больше подобного у меня в тегеграм канале "Находки в опенсорсе": https://t.me/opensource_findings
- У нас есть еще куча других крутых фичей! Заглядывайте в наш чатик по DMR
- Релизнули django-stubs@6.1 с поддержкой django@6.1
- Сделали папку с крутыми каналами ребят из нашего Python сообщества. Смело можно закидывать коллегам как базовую папку "на кого подписаться в тг по питону". Внутри все мои друзья и коллеги, советую!

И это не тавтология... Проверьте свое знание синтаксиса, критическое мышление и умение вчитываться в ТЗ.

Условие

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

Через пару часов инженер бьет тревогу в рабочий чат: «Ребята, у нас проблема! График застыл! Похоже, планировщик завис или сеть легла, процессы не плодятся!». Вы открываете логи, смотрите на графики мониторинга и… Система работает абсолютно штатно, никакого бага нет.

Задача

Объясните паникующему инженеру, почему его логика отказала. Как так получилось, что количество задач не растет? Напишите простую симуляцию этого процесса на Python, чтобы наглядно показать коллеге, как ведет себя такая очередь.

Убедитесь, что все решили правильно, — загляните в Академию Selectel.

SELECT * FROM source_table WHERE timestamp > max_timestamp

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