Python *

Я делаю сервис по подписке и плачу налог как самозанятый. Пока платежей было три в день, чеки в «Мой налог» можно было выбивать руками. Когда они пошли круглосуточно, понадобилась автоматика — и выяснилось, что сложное в этой задаче не API налоговой, а один вопрос: что делать, когда запрос ушёл, а ответ не вернулся. Повторить — риск выдать человеку второй чек на ту же сумму. Не повторить — риск не выдать вовсе.

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

В одном из наших проектов бот записывает видеовстречи из Яндекс Телемоста, сохраняет их в WebM и передаёт на backend. После обработки запись становится доступна пользователю и воспроизводится через Video.js.

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

Сначала мы исправили MIME-тип. Затем изменили настройки плеера. Потом ограничили ответы бека чанками по 50 МБ. Ничего из этого не помогло.

Настоящая причина находилась не на фронте и не на беке, а в самом WebM.

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

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

Погнали смотреть, что у нас в питоне происходило!

При web3-разработке часто приходится заниматься вопросами консистентности считываемых из блокчейна данных и оптимизацией таких запросов так как у RPC‑провайдеров достаточно жёсткая тарификация за каждую единицу газа/RPC‑запрос. Обычно достаточно использования Multicall (умный контракт, который объединяет вызовы view‑ и pure‑ функций других умных контрактов в одном RPC‑методе eth_call), однако такое решение имеет свои лимиты. Так Multicall должен умещаться в предельный gaslimit, допускаемый RPC‑провайдером (зачастую он не очень велик и самое большое, что есть на рынке — это всего 500 миллионов единиц газа у одного из публичных RPC‑провайдеров). Другой проблемой чистого multicall является проблема консистентности: дробление запроса по нескольким вызовам multicall, чтобы уложиться в лимиты, может привести к тому, что часть запросов получат данные из текущего блока, а часть из следующего, что по очевидным причинам не подходит, например, для получения состояния всех пулов какого‑нибудь DEX типа Uniswap или Algebra при трейдинге. Крайне элегантное и эффективное решение данной проблемы для python‑разработчиков было выполнено командой YearnFinance (а именно BobTheBuilder) и опубликовано в виде pip‑пакета dank_mids. Именно его мы разберём в этой статье.

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

Когда я говорю, что «У меня сейчас десять задач в голове», это не означает, что все десять задач одинаково и одновременно находятся в фокусе внимания«.»

Часть задач обдумываю. Часть поддерживаю в фоновом режиме. Одна задача может постоянно возвращаться из‑за риска или приближающегося срока. Другая привлекает внимание из‑за эмоциональной значимости. Третья связана сразу с несколькими проектами и поэтому активируется каждый раз, когда человек сталкивается со смежной информацией.

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

Эти представления не хранятся в одной области мозга. Их удержание и обработка обеспечиваются взаимодействием нескольких функциональных систем. И у этих систем есть ограничения 7±2 (которое потом окажется 4±1) элемента, которые может удерживать наш мозг. Мне стало интересно с этим глубже разобраться, поэтому я засел за научные статьи и попробовал на Python немного помоделировать графы.

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

Есть устройство, работает с чипами ss02-1, умеет в них писать и читать. Для этого в себе содержит алгоритмы генерации паролей на авторизацию и запись, мы хотим получить эти данные сами. Что имеем - прошивку устройства, серийный номер чипа, на основание которого генерируются пароли. Попробуем восстановить алгоритм, используя инструменты дизассемблирования и эмуляции.

Я сижу на демо с потенциальным заказчиком. Показываю агента в действии: пользователь спрашивает «как настроить интеграцию с ITSM-системой», агент делает четыре итерации — семантический поиск, один OpenChunk, текстовый поиск по точному термину, синтез ответа со ссылками. Заказчик кивает, и тут слово берёт его технический директор: «А не проще было бы один RAG-запрос? Один вызов LLM — это же дешевле, чем двадцать».

Формально — да. Один вызов ассистента это 1 × LLM. Агент — до 20 × LLM. Значит, агент в 20 раз дороже?

Нет. И вот почему.

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

Естественно, с появлением мощных облачных ИИ не оставлялись попытки найти в них “качественных собеседников” по предложенной теме. Но, как показала практика, они справились с этой задачей далеко не блестяще! То галлюцинировали факты из общих знаний, то упираясь в границы своих датасетов.

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

На сегодняшний день проделана часть работы. Создан репозиторий в статусе исследовательского лога, куда выкладываются сырые скрипты обработки, предсобранный индекс ChromaDB и пайплайн на базе Qwen2.5 + LM Studio.

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

Архитектура индекса: как грамотнее организовать хранение в Chroma?

Сохранение контекста диалога: как правильно реализовать память о предыдущих вопросах пользователя без раздувания токен-бюджета?

Ранжирование выдачи: может ли reranker (например, cross-encoder) улучшить точность на философских текстах? И с какого объёма стоит начинать эту оптимизацию?

🏆 Ищем Грааль на рынке криптовалют

Искал Грааль в крипте через TradingView Ideas: прошлые результаты авторов не предсказывают будущее, зато работает простой признак — лидеры мнений пишут, когда по монете ещё тихо

Статья представляет собой практическое руководство для ИИ агента как воспроизвести технологию

Я фрилансер, и я ненавижу мониторить биржи. FL, Kwork, Freelance, куча Telegram‑каналов — каждое утро одна и та же рутина. Открываешь вкладку, обновляешь, листаешь, понимаешь что всё мимо, переходишь на следующую. Короче, бесконечная петля.

Подсчитал как‑то — два‑три часа в день уходит не на работу. На обновление страниц.

Решил автоматизировать. Написал агрегатор, который собирает заказы с четырёх площадок в единую ленту с фильтрами, присылает уведомления в Telegram и пересылает ответы заказчиков из бирж прямо в чат. Под капотом Python 3.13, FastAPI, Vue 3, PostgreSQL. Всё крутится в одном asyncio event loop.

Что получится, если собрать PostgreSQL, Airflow, JupyterLab, MinIO, Superset, шесть MCP-сервисов и локальную модель Ollama в одном Docker Compose-стенде?

Показываю полный путь синтетических промышленных данных: от витрин и проверок качества до Parquet-артефактов, MCP-инструментов и LLM-пояснений. Внутри — архитектура, воспроизводимый запуск, результаты проверок и открытый репозиторий.

Как организовать контрактное тестирование, если у вас 150+ микросервисов, 10 команд и QA есть далеко не везде? В Nexign перепробовали готовые инструменты, дважды откатили собственные решения — и в итоге за четыре дня собрали прототип, который за полтора года превратился в рабочий инструмент без единой строки тестового кода. Ведущий инженер Максим Дубинин рассказывает, что не так с Dredd и Pact и почему иногда проще сделать своё.

Всё началось с того, что на «Хабре» мне попалась статья о модели TAPe — Theory of Active Perception, или «теории активного восприятия». В статье были громкие заявления и интересные описания, но попробовать модель на практике не удалось.

Я собрал ключевые тезисы о TAPe и обратился к ChatGPT с запросом:

В 2026 году активно выходят новые фронтир LLM-ки, агентные системы и принципиально новые подходы в самых разных областях. Медицинский AI периодически перенимает наработки, однако область применения ИИ в медицине сейчас остается ограниченной.

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

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

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

Два года назад у меня практически не было опыта программирования. Когда‑то в школе мы немного изучали Pascal, но после этого я не написал ни одного скрипта. Я впервые открыл PyCharm, по ходу работы узнал, что такое API, SSH, виртуальная машина, системная служба и облачные задачи. При этом за несколько месяцев я создал систему, которая собирает новости из турецких источников, переводит и сокращает их, помогает администратору отбирать материалы, готовит полноценные публикации и размещает их в Telegram по расписанию.

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

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

Сейчас в тренде - внедрение ИИ вообще в любой проект, в любой чайник или пылесос. Я давно ковыряюсь в проектировании и Revit, и меня стабильно бесило одно и то же: куча рутины, одинаковых действий, которые можно было бы спокойно автоматизировать. Глядя на то, какие чудеса сейчас творят языковые и диффузионные LLM, генерируя целые детализированные миры, очень хочется сделать тоже самое в строительной сфере.

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

Я решил собрать свой вариант и назвал его AiRevit. Это не чатик с LLM поверх Revit. Тут вообще не предполагается использования такой архитектуры, которая бы основывалась на угадывании токена (нам не нужно ничего угадывать, нужно соблюдать строгие строительные правила). Это детерминированный pipeline, где текст сначала превращается в структурированный program_graph, потом в layout_solution, а уже потом в реальные элементы Revit через Dynamo и Python-скрипты. В репозитории это разложено на Node 3, Node 4 и Node 5, чтобы не было каши и чтобы каждый кусок отвечал за свою часть работы. (https://github.com/Rearks/AiRevit)

Все мы знаем, что языки делятся на динамические и статические: Python или JS позволяют молниеносно прототипировать, но расплачиваться нестабильностью в продакшене приходится потом, тогда как C++, Java или C# требуют прописывать типы сразу, оплачивая монументальную надежность замедлением разработки.

В 2006 году Джереми Сиек предложил разрешить этот конфликт концепцией постепенной типизации в работе «Gradual Typing for Functional Languages»: язык остается динамическим по умолчанию, однако разработчик может аннотировать типами отдельные модули или функции, не покрывая ими всю кодовую базу, а типизированный и нетипизированный код взаимодействуют через специальный динамический тип Dyn. Звучит как сказка — быстрое прототипирование с постепенным наращиванием стабильности. Однако при детальной проработке вскрылись фундаментальные нюансы: в серии последующих работ Сиек, Таха, Вадлер и другие показали, что стыковка типизированного и нетипизированного кода требует операции приведения типа (cast), а дизайн этого каста упирается в противоречие между тремя желаемыми свойствами — надёжностью системы типов (soundness), собственно постепенностью (gradual typing) и отсутствием рантайм-обёрток на границах (no wrappers).

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

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