Python *

Один и тот же JavaScript-код в браузере, Node.js, Deno и Bun должен показывать примерно одинаковую скорость – по крайней мере, так кажется до первых замеров. Я взял четыре прикладные задачи, добавил к сравнению Python и измерил не только время выполнения, но и потребление памяти, причём отдельно посмотрел, как результат меняется вместе с границами замера. Оказалось, что у каждой среды своё представление о быстродействии, а лидер зависит не только от алгоритма, но и от того, входят ли в задачу чтение файлов, парсинг или обработка изображений. Все примеры и исходные данные можно запустить локально и сравнить результаты со своей машиной.

Привет, Хабр! (И тебе, случайный читатель, который открыл эту статью в перерыве между двадцатой правкой того, что ты ещё месяц назад гордо назвал финальной версией).

Сегодня давайте без кода и без нытья пофилософствуем на тему:

Когда же продукт готов? И будет ли готов когда-нибудь...?

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

1. Зачем это нужно

Моя боль как автора (а я не только программист и к. т. н, но еще и писатель в жанре фантастики) – это отсутствие на сайте автор.тудей полноценного анализа статистики. Вся статистика ограничивается просмотрами, временем и средним временем прочтений по дням и главам, в виде шахматки:

Эксперимент на примере классификации изображений CIFAR-10 с использованием фреймворка ICO: параллельная загрузка данных, аугментации, тренировка и валидация.

LLM-бум породил не только новые возможности, но и новое поколение атак. За два года мы увидели реальные атаки на агенты: один вредоносный email и Copilot сливает платёжные данные клиентов, одно фальшивое GitHub issue и CI/CD пайплайн скомпрометирован, один тщательно настроенный промпт и AI-агент выполняет удалённый код на вашей машине. Это уже далеко не теория, а зафиксированные исследователями в 2025 - 2026 годах атаки на Microsoft Copilot, OpenAI Atlas, Claude Code и Apple Intelligence.

Атаки становятся изощрённее: злоумышленники маскируют вредоносные инструкции под XML-политики, шифруют в base64, вставляют невидимые символы и даже прячут джейлбрейк в стихи. Встроенные фильтры LLM пропускают до 76% таких атак.

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

В этой статье разберем основные виды атак и посмотрим на примере, как выстроить базовую защиту с моделью безопасности OGL-Mini.

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

Я сделал Location King — игру на спутниковых снимках. Показывается участок съёмки сверху, без подписей, границ и координат. Надо понять, где это, и поставить точку на карте мира. Чем ближе к цели, тем больше очков, максимум пять тысяч за раунд.

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

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

Я померил: страница кабинета грузилась 2,1 секунды. При этом сервер отдавал HTML за 30 миллисекунд. Первый час я искал не там — потому что померил не ту страницу.

Всё решил один замер. Я дёрнул один и тот же CSS-файл десять раз с кукой сессии и десять раз без неё: 55 мс против 14 мс. За файл с диска. Оказалось, аутентификация делала SELECT, UPDATE и COMMIT в SQLite на каждую картинку и каждый скрипт — сорок раз за страницу, чтобы сорок раз переписать один и тот же таймстамп.

Вторым тормозом был Tailwind, который компилировал стили в браузере у каждого посетителя. Стало 0,9 секунды.

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

Код открыт

Рекомендательная лента почти любого музыкального сервиса оптимизируется под одну метрику — удержание. Мне захотелось не рассуждать об этом абстрактно, а измерить: так появился OpenEar — open-source privacy-first дашборд, который считает прозрачные метрики музыкального разнообразия по истории ListenBrainz.

У меня в проекте было четырнадцать копий одного IP‑адреса. По одной в каждом скрипте, который ходит на боевой сервер: деплой, перезапуск сервиса, правка DNS, диагностика почты. Классический копипаст, который живёт до первого переезда.

Переезд случился. Адрес поменялся. Четырнадцать скриптов стали указывать в никуда.

Дальше начинается то, ради чего я это пишу.

ИИ-агент может не только писать код, но и сам забирать задачи из YouGile, выполнять их и обновлять статусы. Рассказываю, как я связал Codex и Claude Code с таск-трекером, почему обычный retry после timeout однажды создал дубли и зачем между LLM и API нужен отдельный детерминированный слой.

За две недели ко мне зарегистрировалось 176 ботов. Я полез разбираться, как они прошли мимо трёх уровней защиты, — и вылез с двенадцатью дырами, к ботам отношения не имевшими: хранимый XSS через JSON-LD, чужие задачи по одному идентификатору, сессия, которую нельзя погасить сменой пароля.

И одна, из-за которой до сих пор стыдно: все мои лимиты по IP обходились одной строкой в HTTP-заголовке. Проверил на собственном проде — сорок запросов, ноль отказов.

Внутри: разбор атаки и аудит с кодом, ИИ-помощник на ключе пользователя (и асинхронный генератор, молча съедавший ответы), 334 статьи как инженерная задача.

Компьютер начал тупить в середине дня. VS Code переставал отвечать, новые вкладки редактора не открывались по минуте, а лимит подписки на ИИ-ассистента сгорал к обеду вместо конца недели. Виноватым оказался не ассистент, а плагин, который ведёт для него память между сессиями.

Мы списали uv со счетов. А потом он ускорил наш CI на 80%

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

Мы так и сделали. Взяли один микросервис: Python 3.14, 37 прямых зависимостей, 153 пакета в lock-файле, приватные пакеты и внутренний Nexus. Ожидание было простым: если uv действительно быстрее Poetry, миграция окупится сама.

Локально получилось наоборот. Резолвинг — да, быстрее. Установка по готовому lock-файлу — нет, иногда даже медленнее. Эксперимент закрыли и остались на Poetry.

Через несколько недель пришлось вернуться. Не из любопытства, а из-за алерта Trivy и сюрпризов Poetry 2 с корпоративными индексами. И вот тогда uv показал себя совсем в другом месте — в CI.

В статье разберем:

- почему локальный бенчмарк uv vs Poetry нас обманул;
- как Poetry 2 сломал привычную разработку без VPN;
- зачем мы писали парсер poetry.lock → requirements.txt и почему это оказалось костылём;
- как точечная замена Poetry на uv sync в пайплайне сократила время с 5:10 до 2:50;
- почему в итоге uv стал единым стандартом и локально, и в CI.

Коротко: если инструмент не выиграл с первого прогона — это ещё не значит, что он бесполезен. Часто вы просто мерили не то узкое место.

Токен, прочитанный из кеша, стоит не «немного дешевле». Он дешевле в 10–31 раз: DeepSeek — $0.44 против $0.014 за миллион, OpenAI — $4.00 против $0.40.

Кеш провайдера — префиксное дерево по токенам. Он работает ровно до первого расхождения с прошлым запросом. Дальше — всё по полной цене.

Поэтому одна строка вида Current time: {datetime.now()} в начале системного промпта отключает кеш целиком: время меняется на четвёртом слове, и остальные две тысячи токенов политик и базы знаний каждый раз оплачиваются заново. Хотя не менялись ни разу.

Я замерил это на живых вызовах DeepSeek. Один и тот же агент, одни и те же четыре вопроса, одна и та же минута — разница только в том, куда положить время. Ноль попаданий в кеш против 1152 токенов из 1180.

Потом направил профайлер на 97 877 собственных вызовов Claude Code — 32,5 млрд входных токенов, 98% из кеша.

Внутри: как найти такой баг у себя, почему совпадение текста на 96% ещё не значит, что кеш работает, и какие поломки не видно глазами вообще — схемы инструментов из словаря с плавающим порядком ключей, база знаний из set(), «префикс совпал, а кеша нет».

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

Инструмент открыт: github.com/Isk4R1oT/prefixcash

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

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

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

В первой части был инструмент, который снимает схему Firebird и раскладывает её деревом файлов: один объект — один файл. Он отлично отвечает на вопрос «как эта процедура выглядит сейчас» и совершенно беспомощен в вопросе «кто её поменял в среду вечером». Дамп — это фотография, а нам нужен ещё и вахтенный журнал.

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

Обычный MCP-инструмент возвращает агенту текст или структурированные данные. Агент анализирует результат и пишет тебе что-то вроде:

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

Как и писал ранее — сайты — это моё хобби. Иногда я прибегал к помощи сторонних веб‑дизайнеров, что‑то делал сам. Такое поверхностное занятие сайтами с годами привело к тому, что сайты устарели на десятилетие в плане дизайна и UX. В этом году в бизнесе артистов для корпоративов наступило затишье и появилось много свободного времени. Было принято решение обновить сайты! И именно во время этого обновления появилась проблема, из которой в итоге вырос HeadInspect.

Когда я только пришел на должность помощника DBA, я заметил, что все production базы фиксируют изменения странным образом, а именно каждый день в 00:00 вызывался скрипт, который выгружает схему БД Firebird, в виде файла script.sql, созданный встроенной утилитой isql. Далее делил весь файл на объекты (файлы), по группам (директориям) принадлежности, объясняю: есть кусок скрипта создания таблицы, он помещается в директорию 01_TABLES в виде отдельного файла названного в честь названия объекта который он содержит, и так далее. Чем же это плохо? А суть в том что разработчиков много, правки анонимны, история тяжело воспроизводимая. В такой каше сразу не разберешься.