Python *

Почему, несмотря на накопленный опыт и современный инструментарий, число флаки‑тестов растёт год от года? Исследование BitRise 2025 года показало, что доля команд, которым приходится сталкиваться с флаки-тестами, выросла с 10% в 2022-м до 26% в 2025-м.

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

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

- Больше этапов в пайплайнах

- Более сложные рабочие процессы

- Больше сторонних зависимостей

Сложность среды, сторонние зависимости - всё это бьёт в первую очередь по E2E-тестам. Проблема в том, что компенсировать эти источники сложности может быть очень дорого. И именно об этом я хочу поговорить сегодня: насколько дорого обеспечить стабильность E2E-тестов?

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

Результат оказался не магическим, но полезным: -n auto дал ещё ×3.4 локально и около ×2.7 в CI. В статье показываю, почему xdist не заменяет дешёвый setup, а только домножает его; как разводить БД и Redis по воркерам; где упираются соединения Postgres; и почему память Docker VM и тюнинг Postgres не сдвинули потолок.

Сквозная аналитика для B2C: связать клик в рекламе с оплатой и посчитать ROMI. Ядро MVP (реклама + веб + биллинг в Google Sheets, дашборд в BI) собирается за две недели с Claude Code. А честные цифры - атрибуция, когорты, грабли API - занимают месяцы и требуют головы, не LLM.

Предыстория

1 день назад я опубликовал первую статью про WebScan из Песочницы Хабра. Честно — не ожидал ничего особенного. Думал придут 50 человек, может кто-то поставит звезду на GitHub.

Вышло иначе.

За первые сутки статью прочитали 548 человек. Потом пошли 10К охват, закреплённый пост на канале с 29К подписчиков, Google AI который начал рассказывать про WebScan всем кто спрашивал про bug bounty инструменты на Python. И 12 звёзд на GitHub от людей которых я не знаю.

Это была лучшая мотивация чтобы не останавливаться.

Честно о трудностях

Я подал заявку на Cyber Verification Program от Anthropic чтобы использовать Claude без блокировок для кибербезопасности. Отказали за час. Причина — случайно нажал No на вопросе про MFA. Одна кнопка, один отказ.

Coverage был 84% — я думал 87%, оказалось это была progress bar pytest а не реальная цифра.

Nuclei на Go оказался медленнее WebScan на Python. Я сам не верил пока не провёл бенчмарк.

Имя webscan на PyPI уже занято. Пришлось переименовать в webscan-security.

Всё это решалось — просто не всё шло по плану.

Что изменилось за неделю

v1.0 → v2.0 это не просто версия. Это другой инструмент.

Плагины: 7 → 19

Добавились: XSS, Blind SQLi, Path Traversal, Open Redirect, SSRF, GraphQL интроспекция, SSL/TLS анализ, Tech Fingerprint, Subdomain Enumeration через DNS и crt.sh, CVE lookup через NVD API (350,000+ уязвимостей в реальном времени), Secrets detection (AWS, OpenAI, Anthropic, GitHub ключи в исходниках).

Crawler

WebScan теперь сам обходит цель — парсит ссылки, формы, JavaScript эндпоинты. Раньше сканировал только то что ему давали. Теперь сам находит что сканировать.

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

Это была бы скучная заметка в духе «МАС не нужен, расходимся». Но нашлось исключение. Чем труднее задача для модели, тем больше у команды появляется шанс на выигрыш. Так что вопросов у меня два. Влияет ли вообще топология системы на результат? И если влияет, можно ли автоматически выбирать подходящий паттерн под конкретную задачу? Ответ на второй вопрос пока отрицательный, и самое любопытное здесь именно почему.

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

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

Я решил сделать иначе. Программа, о которой пойдёт речь — это десктопное приложение для Windows, которое запускается двойным кликом, подключается к открытому API Binance и выдаёт взвешенный Score по шести категориям индикаторов, бэктест на последних 100 барах, уровни поддержки/сопротивления по фракталам и ATR-метрики риска. В статье расскажу, как всё это устроено изнутри — с формулами и кодом.

Когда у приложения появляется несколько хостов PostgreSQL, начинается головная боль: нужно динамически находить мастера после failover, выбирать реплику с нужным отставанием и гарантировать что пользователь не увидит устаревшие данные после своей же записи. DNS кешируется минутами, libpq не знает про lag, HAProxy не слышал про LSN. Разбираем как устроены существующие решения и как закрыть все три задачи через лёгкий HTTP сервис — pg-status.

Дисклеймер о конфликте интересов.

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

И сразу к делу — с вопроса, на который у большинства есть «очевидный», но неверный ответ.

Как превратить крик души в работающую утилиту и попасть в официальную ArchWiki? Мне 17 лет, и мне просто надоело тянуть HDMI-кабель от ноутбука к телевизору через всю комнату. В этой статье я расскажу, как написал свой стример экрана FluxCast на Python, с какими багами Smart TV пришлось столкнуться и как устроен «слепой» дебаг проприетарного железа по логам пользователей со всего мира.

WebScan — асинхронный CLI-сканер безопасности на чистом Python. За неделю вырос до 15 плагинов: XSS, SQL инъекции, CORS, Path Traversal, SSRF, утечки API ключей и многое другое. Safe Mode, proxy, SOCKS5, пять форматов отчётов включая SARIF.

В статье разбираю архитектуру и сравниваю с Nikto.

Взяли автоэнкодер из свежей работы CALM (Continuous Autoregressive Language Models), который учится упаковывать чанк из K=4 токенов в один непрерывный вектор и разворачивать обратно, и обучили его не на 15 миллиардах токенов Pile на 8 GPU, как в оригинале, а на 18 тысячах коротких строк с требованиями из IT-вакансий - на обычной машине без видеокарты. По дороге выгребли три классических грабли (flash-attn без CUDA, deepspeed, который не импортируется под NumPy 2.x, и тихий OOM на 33 ГБ логитов). Ниже - подробный разбор архитектуры, конфигов и честные результаты round-trip-реконструкции.

На третий день в проде мой support-агент на LangGraph и GPT-4o слил email одного клиента в переписку с другим. Причина банальна: модель вставила сырой контекст из базы прямо в ответ, и ничто в пайплайне это не проверяло. Фреймворки для агентов дают оркестрацию, вызов инструментов и память — но не безопасность. В этой статье разбираю стек из четырёх guardrails (валидация входа, валидация выхода, circuit breaker по расходам и проверка вызова инструментов), который умещается в ~200 строк Python и добавляет менее 40 мс latency. С рабочим кодом, схемой пайплайна и честным разбором того, что эти guardrails ловят, а что — нет.

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

Я провел простой эксперимент и превратил цифры MNIST в последовательности переходов между 256 гвоздями и обучил небольшой Transformer продолжать путь нити. В результате модель выдаёт не PNG, а JSON-траекторию, которую можно отрисовать в любом разрешении - или потенциально передать физической string-art установке.

Код выложил на GitHub

Миллион асинхронных задач на Rust спокойно живёт в нескольких сотнях мегабайт. Сто тысяч корутин на Python нередко упираются в память раньше. Дело не в том, что “Rust быстрый, а Python медленный” - дело в том, ГДЕ физически лежит состояние приостановленной задачи.

Разбираю, во что превращается ваш async fn после компиляции: стейт-машина на стеке против объекта в куче. Сравниваю модели Rust (Tokio), Python (asyncio), C# и JavaScript - кто аллоцирует на каждый await, а кто нет, и почему это видно на счётчике RAM при 100k задач.

Внутри: что генерирует компилятор, куда уезжает состояние между await, stackful против stackless, и что с этим делать сегодня.

Всем привет!

Telegram меня наконец-то услышал! Ну ладно, не только меня, а может, и не слышал вовсе, но недавний апдейт клиента и вчерашнее обновление Telegram Bot API 10.1 попали прямо в меня.

Дуров и команда ввели Rich Messages — полноценную альтернативу обычным сообщениям, в которых можно конструировать сложную структуру контента с помощью Rich Markdown или HTML-разметки. Кроме того, теперь появилась возможность явно использовать бота в роли полноценного модератора (гварда) на стыке с Mini Apps. Но обо всём по порядку.

Если вам интересны подобные материалы и разработка в целом, подписывайтесь на Telegram-канал «Код на салфетке».

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

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

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

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

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

Разбираемся, как работает shrinking, почему ручные shrinker'ы плохо масштабируются и за счёт чего Hypothesis умеет минимизировать ошибки практически автоматически.

Здравствуйте, дорогие читатели! Сегодня - ещё одна статья из рубрики джангологии.

Раньше я уже писал о своих идеях (1 и 2) о том, как сделать django асинхронным. Они основывались, вслед за sqlalchemy, на использовании гринлетов. Несмотря на то, что proof-of-concept был успешно получен, а трудностей - встречено меньше, чем ожидалось, я всё-таки отказался от этого подхода: во-первых, он уже применяется в sqlalchemy. Во-вторых, это ведёт к усложнению, и растёт так называемая test matrix - потому что поддерживается как синхронный случай, так и асинхронный. А simple, как мы знаем, is better than complex.

Так вот, я решил возобновить эти свои попытки, изменив подход на более радикальный. А именно, необратимо переписать django на async-only, сломав совместимость полностью. Для этого потребуется заменить в половине функций def на async def и добавив await при их вызове. Я уверен, что такой подход лучше.

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

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

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