Может я не прав, но 8 лет пердения в офисный стул — сомнительный фильтр для выбора разработчика.
Безусловно, за это время можно приобрести огромный багаж опыта, но гарантий никаких. Будто бы все же лучше смотреть на реальные навыки.
В общем, писать софт для кибербеза с другими дедами мне пока рано. Слишком молодой специалист.
Приложение ChatGPT/Codex включает в себя полную копию LibreOffice.
«Я копался в папке ~/.cache/ с помощью OmniDiskSweeper и заметил кое‑что интересное. В папке codex‑primary‑runtime настольного приложения OpenAI Codex (позже переименованного в ChatGPT) находится 1,7 ГБ файлов, включая полную установку Python, полную установку Node.js, а также нативные бинарные файлы для Poppler, git и офисного пакета LibreOffice с открытым исходным кодом (который отделился от OpenOffice.org в 2010 году)», — пояснил исследователь Саймон Уиллисон.
Заманчивая вакансия на Python‑раба от владельца‑вайбкодера
Она довольно внушительная, LLM не поскупилась на требования к кандидату, но если кратко:
нужен один разработчик
весь бэкенд нужно построить с нуля, так как сейчас он держится на решениях из го*на и гугл таблиц
весь свой опыт в разработке специалист должен описать в х*евоей горе.md файлов, чтобы владелец мог управлять проектом с помощью Cloude Code без разработчика
агентный слой из роя агентов в проде тоже очень надо
фронтенд на next.js тоже очень надо
работать напрямую с владельцем, но он не технарь, поэтому важен опыт создания технической х*ни для «нетехнических» людей
Cloude Code, Cloude Code, Cloude Code
Еще нужно обязательно пройти анкетирование, так как резюме без анкет, которые никто кроме LLM не увидит, не рассматривают.
Так выглядит рынок нанимателя 2026.
Laconian: короткий ответ без потери смысла
Сделал Laconian - agent skill, построенный вокруг принципа the shortest complete answer. Не самый короткий ответ вообще, а самый короткий из тех, которые остаются корректными и практически полезными.
Логика простая: сначала определить полный ответ, затем удалить только то, без чего не пострадают точность, безопасность, существенные факты, ограничения и требования пользователя.
Skill убирает приветствия, пересказ запроса, незапрошенное описание процесса, повторы и декоративные выводы. При этом сохраняет важные оговорки, неопределённость, нужную детализацию, код, команды, числа, URL и другие данные, точная форма которых имеет значение.
Вся пользовательская часть проекта — один файл SKILL.md. В нём нет скриптов, зависимостей, сетевых вызовов, дополнительных разрешений или привязки к инструментам конкретной платформы.
В репозитории также развивается открытый benchmark: Laconian сравнивается с baseline, обычной инструкцией Answer concisely. и Caveman. Инфраструктура уже работает, но публичных результатов пока нет — поэтому пока не заявляю о выигрыше в длине, качестве или стоимости раньше данных.
Ссылки
В Bot API 10.3 появилась остановка генерации. Но LLM-запрос придётся отменять самому
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 добавил удобный интерфейс, но жизненный цикл генерации всё равно остаётся на стороне разработчика.
Вопрос: что вы бы делали после остановки: сохраняли частичный ответ, удаляли его или показывали кнопку «Продолжить», которая запускает новый запрос с уже полученным текстом?
Представлен открытый сетевой проект Tailcat — как netcat, но поверх плоскости данных Tailscale. Также доступна экспериментальная веб‑демонстрация в браузере (tailcat, скомпилированный в WebAssembly), которая может отправлять и получать файлы или текст, взаимодействуя с CLI. Трафик браузера передаётся только через DERP, без прямых соединений до появления поддержки WebRTC
WEB-прокси Telegram помогает клиенту, но не инфраструктуре бота
В Telegram Desktop 7.1.0 появился новый тип подключения — WEB proxy. Его уже успели описать как способ, с помощью которого Telegram может выглядеть для сети как обычный HTTPS-сайт.
Если сильно упростить официальное описание архитектуры, работает это так:
Клиент сохраняет обычный MTProxy framing и шифрование.
Соединения проходят через скрытый WebView внутри приложения.
WebView передаёт несколько логических потоков через один или несколько HTTPS- либо WebSocket-соединений с тем же доменом.
Серверный 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, который помогает удалять невидимые водяные знаки из текста и изображений от ИИ-систем. «Если исследователь использует ИИ, чтобы изменить одну строку в конце десятистраничной работы, вся публикация потенциально может получить отметку. Это может превратиться в кошмар для доверия», — пояснил автор решения.
Watermarks Remover работает за счёт небольшого изменения текста при сохранении исходного смысла. Инструмент проверяет материал на наличие ИИ-маркировки, создаёт вариации формулировок и повторяет процесс, пока статистический паттерн не перестанет определяться. Для изображений используется похожий подход, только вместо слов меняются пиксели.
Представлен открытый проект ИИ‑учёного OmniScientist, который сам пишет статьи, составляет библиографию, таблицы и рисует схемы для любых исследователей:
анализирует любые файлы: изображения, видео, схемы, таблицы, документы, формулы и даже аудио.
выдвигает гипотезы как настоящая команда учёных.
проверяет информацию до последней запятой, чтобы не было ни одной выдумки или неточности;
строит графики, таблицы и схемы;
собирает результат в PDF и отдаёт в удобном формате;
знает русский язык и ориентируется в культурном контексте;
может подключаться к различным ИИ‑агентам;
работает на Windows, macOS и Linux.
🔎 PhishIntel — автономный OSINT-инструмент для анализа доменов
Проект помогает быстро собрать технический профиль домена и оценить потенциальный фишинговый риск в формате структурированного 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-запрос), и вы получите развёрнутое пояснение, почему магические числа это плохо, и как их заменить на константу, кстати именно в новой версии появилась эта функциональность, теперь объяснения приходят прямо в контекст агента, плюс появились скиллы. Вообщем сделано так, чтобы улучшать код и не раздражать разработчика :)
Агент откатил действие, но модель его не забыла: KV-кэш может пережить rollback.
Исследователи показали неприятный рассинхрон между логикой агентной среды и состоянием самой языковой модели. Агент может отменить ветку выполнения, удалить её из истории диалога и продолжить работу так, будто этой ветки никогда не существовало. Но если среда повторно использует кэш ключей и значений (KV-кэш) той же сессии, модель всё ещё может учитывать информацию из уже удалённой ветки. Авторы называют необходимое свойство rollback consistency - согласованностью отката.
Авторы проверили эффект на семи семействах открытых моделей размером от 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.
✍️ Записаться
Я завысил собственный Sharpe. Исправляю публично
Перед стартом торговли реальными деньгами прогнал плановый аудит кода своей 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% — переобучение ничего не спасало, спасать было нечего.
Чек-лист, если хотите проверить свой бэктест на те же грабли:
Все ли слои издержек применяются во всех симуляторах, или только в одном?
Бенчмарк несёт те же издержки? Частота сделок разная — эффект несимметричен.
Существуют ли все признаки модели на всём периоде стресс-теста?
Есть ли в загрузчиках данных молчаливые except, превращающие отсутствующую таблицу в нули?
Стресс-тест показал катастрофу — сначала проверьте тест, потом модель.
Подробный разбор — в UPD к статье про сидовый шум. Цифры в старых текстах не правил — только явный UPD: тихая правка убила бы весь смысл протокола честности.
Не является индивидуальной инвестиционной рекомендацией.
📐 Применение природных алгоритмов оптимизации в строительном проектировании
Современное проектирование несущих конструкций — это всегда поиск баланса между жёсткими требованиями безопасности и экономической эффективностью. Классические градиентные методы часто не справляются с многомерными пространствами ограничений, характерными для задач ПГС. Поэтому в САПР и ТИМ-решениях всё чаще применяются алгоритмы, подсказанные природой.
🧬 Генетические алгоритмы (GA) Основаны на естественном отборе и эволюционной генетике. В проектировании используются для оптимизации топологии и сечений элементов. Классические примеры — подбор оптимальных размеров подошвы и глубины заложения фундаментов, оптимизация сечений балок и рам. Алгоритм итеративно “скрещивает” варианты, отсеивая решения с недопустимыми осадками, недостаточной несущей способностью или перерасходом бетона.
Отдельное направление — задачи раскроя. Генетические алгоритмы успешно применяются для оптимизации 2D-укладки деталей сложной формы на листах металла, чтобы минимизировать отходы. В 3D-постановке это работает при компоновке арматурных каркасов, раскладке сборных элементов в опалубке или плотной упаковке конструкций для перевозки.
🐜 Алгоритмы роевого интеллекта (Swarm Intelligence) Моделируют поведение групп организмов: миграцию птиц, поиск пищи насекомыми. Наиболее известны метод роя частиц (PSO) и муравьиный алгоритм (ACO). Применяются для трассировки инженерных сетей, автоматического армирования плит, оптимизации геометрии сложных фундаментов. PSO эффективно распределяет усилия по расчётной сетке конечных элементов, снижая концентрацию напряжений за счёт корректировки параметров армирования локальными агентами.
Муравьиный алгоритм особенно полезен в логистике стройплощадки: поиск кратчайших маршрутов движения техники, оптимальная последовательность подачи материалов на монтажный горизонт, обход временных препятствий.
🔥 Алгоритмы имитации физических процессов К ним относится метод имитации отжига (Simulated Annealing), который моделирует кристаллизацию металла при охлаждении. Используется для решения комбинаторных задач: календарное планирование, оптимизация логистики движения материалов, расстановка монтажных кранов, распределение бригад по захваткам при жёстких пространственных и временных ограничениях.
⚠ Ограничения и инженерная практика При всех возможностях природные алгоритмы не заменяют классические расчётные комплексы (МКЭ/FEM). Сегодня они выступают как эффективные препроцессоры: генерируют концептуальные схемы расстановки несущих элементов, варианты раскроя и календарные графики, которые затем проходят обязательную ручную верификацию инженером-конструктором и финальный проверочный расчёт в сертифицированном ПО на соответствие СП/СНиП.
Такой подход позволяет сократить рутину на ранних этапах, но оставляет ответственность за итоговое решение человеку.
Как бы я учила Python, если бы могла отмотать время назад...
# Не судите строго, впервые пиши пост, понимаю, что может быть не интересно (по причине опыта), но все же хочется внести свой вклад
Всем привет! Меня зовут Фаина я уже несколько лет пишу на Python (и не только) и зарабатываю этим на жизнь. Недавно я наткнулась на свои старые "конспекты" с первых попыток изучения языка. Это было... больно. Сотни скриншотов, обрывочные заметки и полное непонимание того, что происходит.
Если бы у меня была машина времени, я бы вернулась к той испуганной девушке, которая впервые открыла IDLE, и сказала бы ей несколько важных вещей.
1.Перестать коллекционировать курсы (и начать делать)
Моя самая главная ошибка — «синдром хомяка». Я скачала, наверное, 50 ГБ курсов: "Python с нуля", "Python для чайников", "Python за 24 часа". Я смотрела первые два урока, чувствовала себя умной, а потом бросала, потому что "этот курс не очень".
Итог: Один хороший курс + практика лучше, чем 50 идеальных курсов в папке "Разобрать".
Сейчас, если бы я начинала, я бы выбрала один интерактивный ресурс (или одну книгу, если, конечно, сможешь так учится) и шла по нему, пока не упрусь в стену. Не прыгала бы между ютуберами и методичками.
2.Сначала гуглить, потом — паниковать
В начале пути любая ошибка в коде вызывала у меня панику. Красный трейсбек выглядел как приговор. Я думала: "Ну всё, я бездарь, Python меня ненавидит".
Итог: Ошибка — это не "я плохая", это "код говорит мне, что именно не так".
Сейчас 80% моей работы — это чтение ошибок и гугление.
3.Зубрежка синтаксиса не работает. Работают проекты
Я думала, что если выучу все методы списков и словарей наизусть, то стану сеньором. Я исписывала тетради шпаргалками. Толку было ноль.
Итог: Ты запоминаешь только то, что используешь руками.
Вместо заучивания теории, я бы начала писать мини-программы с первого дня.
День 3: Калькулятор чаевых.
Неделя 2: Парсер курса валют с сайта (с помощью requests).
Месяц 1: Простенький телеграм-бот, который присылает погоду.
Проекты не обязаны быть гениальными. Они должны быть действительно интересные, даже захватывающие.
Если ультра-кратко:
Лучше уж один источник знаний вместо "все сразу"
Лучше практика каждый день по 30 минут, чем раз в неделю и до потери пульса
Ошибки - это норм, не стрем
С другом или ментором будем веселее и эффективнее - с кем можно поделится опытом или обсудить код и тд.
Спасибо за внимание, ваша Фаина!)
Какие уникальные фичи есть в django-modern-rest?
Иногда, когда я добавляю какие-то фичи в мой 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.
Представлен открытый проект Memora, который сохраняет работу Codex и Claude Code между сессиями. Внутри решения находится локальная база SQLite или синхронизация через S3, R2 и Cloudflare D1. Есть также семантический поиск, TODO, документы и связи между воспоминаниями. ИИ-агент запрашивает тему и получает готовый комплект данных: важный контекст, незакрытые задачи, связанные факты и ссылки на источники. Причём всю память можно открыть как интерактивный граф и изучать через встроенный RAG-чат.
Попросил ИИ чат нарисовать ИИ агента
