Python *

README редко ломается в один момент.

Обычно он просто постепенно перестаёт соответствовать проекту: переименовали команду, перенесли файл, удалили .env.example, сменили package manager — а инструкция осталась прежней.

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

Мне стало интересно: можно ли автоматически находить хотя бы часть таких расхождений, не выполняя команды из README и не отправляя исходный код в LLM?

Так появился RealityLint — open‑source CLI, который статически сверяет проверяемые утверждения из README с реальным состоянием репозитория.

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

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

Чтобы понять суть этого «узкого места», обратите внимание на то, как «школьный» алгоритм справляется с увеличением размера чисел. При умножении двух двузначных чисел выполняется четыре однозначных умножения. Если перейти к паре трёхзначных чисел, то потребуется девять однозначных умножений. Нагрузка растёт пропорционально квадрату количества разрядов (n², где n — количество разрядов в умножаемых числах). При анализе подобного алгоритма компьютерные учёные не измеряют скорость в секундах, поскольку она зависит от аппаратного обеспечения. Вместо этого они подсчитывают количество вычислительных шагов. Они также игнорируют второстепенные детали, такие как время, необходимое для переноса единицы при умножении. Когда числа становятся достаточно большими, эти низкоуровневые операции перестают иметь значение, поскольку их полностью затмевают более ресурсоёмкие операции. Информатики обозначают количество шагов с помощью так называемой нотации «большого O»: например, алгоритм, который учат в начальной школе, требует O(n²) шагов, что читается как «порядка n в квадрате». В общих чертах, если числа в два раза длиннее, для выполнения алгоритма требуется в четыре раза больше вычислительной работы. Если числа в тысячу раз длиннее, требуется в миллион (1 000 в квадрате) раз больше работы.

Имя пакета в реестре часто оказывается первым сигналом того, что компоненту можно доверять. Разработчик видит название вроде google-cloud-storage, opentelemetry-sdk или apache-airflow-providers-slack раньше, чем открывает исходный код, и ожидает, что знакомый префикс указывает на известный проект. В PyPI это ожидание пока ничем не подтверждено: реестр формально не связывает общее начало имени с его владельцем, поэтому любой свободный вариант может зарегистрировать посторонний пользователь.

В конце июня 2026 года в Python‑сообществе приняли PEP 752 (мы писали об этом здесь). Он предлагает закреплять за организацией не отдельные имена, а префикс и все будущие проекты, которые ему соответствуют. Если PyPI реализует этот механизм, то пакет с именем вроде «google‑cloud‑new‑service» сможет опубликовать только та организация, которой принадлежит право на этот префикс или которой разрешили пользоваться этим правом. На первый взгляд, решение очевидное. Однако общий префикс не всегда означает, что все пакеты принадлежат одному издателю. Иногда он обозначает семейство официальных библиотек, а иногда экосистему сторонних дополнений. 

Меня зовут Артем Максимов, я отвечаю за аналитику продуктов в CodeScoring. Вместе с дата‑инженером Артемом Ивановым в этой статье мы разбираемся, какую проблему решает PEP 752, где проходит его граница и что нам показывает база данных CodeScoring.

Меня зовут ZolAnd, я - независимый инженер-разработчик embedded-систем в основном для дома и сельской усадьбы. В какой-то момент мне захотелось собрать под одной крышей разношёрстный парк ZigBee-устройств от разных производителей, работать с ним локально, без обязательной привязки к облаку, и при этом иметь возможность не только интегрировать чужие устройства, но и проектировать свои. Так появился проект ZBFun. Эта статья — про то, с какими вызовами я столкнулся, какие решения уже существуют и почему они мне не подошли, и про архитектуру, к которой я в итоге пришёл.

С чего всё началось

Задача звучала просто: хочу python-библиотеку для ZigBee на ESP32-C6. Готовой не нашлось — есть отличный esp-zigbee-lib от Espressif на C, но ничего сопоставимого на Python или MicroPython для этой платформы не было. Значит, писать самому. И тут выяснилась вторая, более фундаментальная проблема. Чтобы написать библиотеку, нужно понимать, что такое ZigBee Cluster Library (ZCL) — стандарт, который описывает, из чего вообще состоит ZigBee-устройство: кластеры, атрибуты, команды, типы данных, зависимости между ними. Официальный документ Alliance — 1213 страниц PDF, написанный для инженеров, имплементирующих стек с нуля, без какой-либо машиночитаемой версии. Ни JSON, ни XML — только текст, рассчитанный на то, что человек прочитает и перепечатает нужное руками. Дальше — хуже. Когда я стал сверять этот текст с реальными SDK и реальными устройствами, обнаружились расхождения. Причём не косметические, а такие, из-за которых устройство просто не будет работать правильно.

Cлучилось то, что я обычно советую не делать: я не выбрал из существующих 14 форматов, а сделал 15-й.

Я автор aiochlite — асинхронного клиента ClickHouse на aiohttp. Раньше мой декодер RowBinary читал каждое числовое поле отдельно. Если брать 200 тысяч строк с десятью числовыми колонками, получалось два миллиона таких чтений, хотя все данные уже были в памяти.

Сначала я думал использовать Cython, C или Rust. Но потом решил попробовать оптимизировать сам процесс: объединить соседние поля с фиксированной длиной в один struct, а полностью фиксированные строки разбирать с помощью Struct.iter_unpack. На числовых данных это ускорило работу примерно в 8.3 раза.

Со смешанной схемой данных получилось интереснее: простая склейка почти не помогла. Главной проблемой осталась проверка типов внутри основного цикла. В итоге я начал генерировать и компилировать Python-функцию под конкретную схему ответа — это дало ускорение еще примерно в 1.7 раза.

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

В процессе прохождения курса от MIT про нейросети наткнулась на интересную тему, представленную одним из лекторов. Он задался вопросом: «А может ли нейросеть выучить функцию Вейерштрасса (непрерывная функция на вещественной прямой, не имеющая производной ни в одной точке)?». Я решила проверить это на практике. Мною было принято решение не останавливаться на фракталах, а поискать другие функции, обладающие интересными для математика свойствами: лестница Кантора, функция Римана (Томаэ) и др. В данной статье представлена только функция Вейерштрасса.

В последний вечер дататона у нас оставалось три попытки отправить решение. К этому моменту мы уже перебрали несколько моделей, собрали тяжёлый ансамбль и упёрлись в 0.6605. Новые энкодеры добавляли по одной-две тысячных, а fine-tuning показывал отличные цифры локально и проваливался на лидерборде.

Добавлять ещё одну модель смысла почти не было. Мы решили изменить сам поиск соседей: попробовать K-reciprocal re-ranking, а затем ещё раз применить AS-Norm. От этого варианта ждали примерно 0.67–0.69.

Получилось 0.7042 и 10-е место из 93. Почти весь день мы пытались выжать из моделей тысячные, а перерасчёт соседей добавил больше четырёх сотых без дополнительного обучения.

Современные AI-агенты действуют в реальном мире с помощью доступных им инструментов (tools). Ядро вокруг модели (LLM), которое позволяет всему этому работать (harness), серьезно влияет на качество и стоимость конечных ответов. При этом добавление в harness простого JavaScript может существенно прокачать AI-агента и заменить часть долгих и дорогих рассуждений простейшим кодом, который будет лучше, точнее и быстрее.

В этой статье разберу как такие интерпретаторы могут помогать. Начну с примера, который можно повторить у себя в LM Studio, а потом перейду к более общему устройству на LangChain, где простой JS-интерпретатор становится уже не таким простым, а забирает часть логики с LLM и помогает ей фокусироваться на том, что нужно, делегируя детерминированную логику скрипту.

Мы храним зашифрованные данные, и рядом с ними лежат ключи, которые к этим данным не подходят. Выглядит как расстройство для взломщика.

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

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

Рано или поздно в инфраструктуре появляется задача автоматического обновления TLS-сертификатов. В простом случае она решается установкой certbot: один домен, один сервер, cron-задание и дальше можно не вспоминать об этом годами.

Сложности начинаются, когда инфраструктура вырастает…

Задача звучит просто: выяснить, называют ли бренд ChatGPT, Claude, Perplexity, Gemini, Алиса AI и GigaChat, когда пользователь спрашивает совета или ответа у ИИ. На практике эта задача раскладывается на десятки технических решений, каждое из которых меняет результат в разы. Ниже устройство замера, формат хранения и три моих ошибки, которые обесценивают всю работу.

Если вы замеряете прогресс своего солвера на случайной подвыборке из train, вы замеряете его не на том наборе. Медианная задача train занимает 100 клеток на выходе, у медианной задачи eval их 225. Два и более тестовых входа требуют 6.9 процента задач train и 40.8 процента задач eval. Расхождение держится по всем шести структурным осям, которые я померил, и переживает поправку на множественные сравнения.

Дальше идёт распределительное сравнение обоих публичных наборов ARC-AGI-2, отпечатки файлов, на которых оно сделано, и подмножество из train, подобранное под eval по структуре. CSV со списком задач в конце.

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

Привет, я Николай Видов, тимлид команды чат-ботов в Т-Банке, восемь лет пишу на Python. 

Казалось бы, конфигурация — это просто .env и settings.py. Но стоит приложению вырасти — и начинается: секреты утекают в логи, port внезапно приходит строкой abc, настройки дублируются между окружениями. Я прошел путь от хардкода до типизированных схем и понял: конфигурация — это не мусорный код на скорую руку, а часть инфраструктуры, которую нужно проектировать так же тщательно, как бизнес-логику.

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

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

Я подключил к Hermes пользовательскую Telegram-сессию. После этого агент смог искать в моих чатах, читать нужные фрагменты истории, находить контакты, выгружать выбранные переписки в JSONL и, после моего подтверждения, писать от моего имени.

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

Так начался эксперимент с MTProto, Pyrogram, tgcli и SKILL.md для Hermes. Польза обнаружилась быстро. Ограничения пришлось придумывать почти так же быстро, ещё до первой реальной отправки.

Привет всем заглянувшим!

В этой статье я поделюсь опытом автоматизации API‑тестирования связкой Postman + Newman, но с небольшим «секретным ингредиентом». Мы не просто будем запускать коллекции в Jenkins напрямую, а используем универсальный Python‑скрипт, который превращает стандартный прогон в мощный инструмент мониторинга.

В чем «фишка» этого подхода?

Обычно Newman выдает довольно сухие отчеты. Мой скрипт выступает в роли умной прослойки: он обрабатывает результаты тестов на статус‑коды, собирает данные и упаковывает их в наглядный Allure‑отчет. Более того, здесь добавлена функция почтовых уведомлений, чтобы контролировать состояние системы, не заходя в Jenkins.

У меня есть RAG‑сервис: проверяет фактологические утверждения в бизнес‑отчётах против реальных источников — SEC EDGAR, World Bank, FRED, Wikipedia. Это капстоун LLM Zoomcamp (DataTalksClub). Курс закончился, оценку поставили (peer review, 42/42), а я решил дотянуть проект до состояния «не стыдно показать на собеседовании как рабочий код», а не просто «закрыл критерии оценки курса».

Garmin записывает почти всё: сон, HRV, стресс, Body Battery, пульс на тренировке, каждый подход в зале. ChatGPT ничего этого не видит. Чтобы спросить у него, как прошла неделя, нужно было сначала открыть Garmin Connect, переписать цифры руками и вставить их в чат.

Один вечер, один скрипт. Забрать сон и HRV за сегодня, сложить в файл. Никакой архитектуры, просто раздражение от того, что данные есть, а спросить их некому.

Сейчас это открытый пайплайн: локальный кэш, агентный Telegram-бот, локальная модель на Ollama, веб-мастер настройки, Windows-дистрибутив и заявка на акселератор Sber500. По пути пришлось несколько раз пересобрать саму задачу.

У меня было 48 часов видеозаписей учебного курса и простая мысль: пересматривать это я не буду никогда. Сырой транскрипт немногим лучше — болото на сотни страниц. Я собрал конвейер, который превратил записи в Obsidian-вики: 47 связанных статей, и каждое утверждение в любой из них — в двух кликах от места в записи, где это было сказано.