Python *

Почти любая распределенная платформа рано или поздно сталкивается с необходимостью синхронизировать данные между своими системами. И чем выше требования к надежности и скорости доставки изменений, тем меньше остается простых решений. Бизнес-пользователям при работе с интерфейсом одной из платформ нужно знать о сущностях, заведённых во второй. Первая хранит их в реляционной СУБД (неважно, какой именно), а вторая - в документоориентированной MongoDB. До кучи, обе платформы разнесены по сети. Можно, конечно, предложить открыть оба интерфейса бок о бок и сверять данные глазами. Но это справедливо негативно скажется на финансовом обеспечении команды разработки, да и как-то не по-человечески так относиться к своим коллегам. Поэтому приходится зарабатывать доверие в коллективе честным трудом.

Встаёт вопрос: как в условиях распределённой структуры наладить транспортировку данных для взаимодействия независимых систем? Прикручивать ко всем продуктам кастомные интеграции дорого и непродуктивно. 

В данной статье хочется представить вам, как мы реализовали интеграцию двух независимых платформ со своими базами данных при помощи инструментов MongoDB для мониторинга данных и брокера сообщений. Описать путь от самого простого решения на примитивных выгрузках метаданных одной пачкой до реализации на событиях Change Stream посредством брокера сообщений.

ИИ помогает инженеру. Но готов ли инженер безопасно его использовать?

Чтобы найти ошибку в конфиге Cisco, многие просто копируют его целиком в ChatGPT. На решение проблемы уходит две минуты. Но вместе с конфигом искусственный интеллект получает информацию о внутренней инфраструктуре компании.

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

Самое главное уравнение‑это уравнение поля Эйнштейна в общей теории относительности (Источник [1]):

Стандартная ситуация: разрабатывается сигнально-кодовая конструкция, хочется проверить её на устойчивость к шуму. Моделируем - и BER-кривая оказывается на 3 дБ левее теоретической (Рис.1). Знакомо? Тут два варианта: либо ваша система действительно хороша и стоит задуматься о патенте, либо стоит проверить правильность добавления шума к сигналу.

Привет, Хабр!

Время от времени я возвращаюсь к своему PET-проекту приватного и независимого от сторонних сервисов голосового ассистента под кодовым названием «Альфа», который разработан для голосового взаимодействия с умным домом на базе Home Assistant. Простыми словами — это приватная умная колонка для управления умным домом. В этот раз я решил заняться вопросом «нормального» взаимодействия «Альфы» и Home Assistant. А что из этого вышло — читайте далее.

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

Поэтому я решил собрать собственный контролируемый пайплайн. Базой для эксперимента была выбрана Stable Diffusion 1.5. Да, это далеко не самая новая архитектура: она хуже современных моделей понимает комплексные описания, чаще ломает анатомию и ограничена базовым разрешением 512×512. Но у неё остаются неоспоримые козыри: низкие требования к железу, гигантская экосистема (ControlNet, чекпоинты) и возможность быстро обучать и тестировать гипотезы на домашнем ПК.

Суть эксперимента — обучить стилевую LoRA на обезличенной подборке стикеров из ВК. Модель должна была выучить не лицо конкретного персонажа и не манеру конкретного художника, а общие паттерны жанра: белый фон, упрощённые формы, характерный векторный контур и мультяшную выразительность эмоций.

Бывают ошибки, которые не видит ни ревью, ни тесты: код отрабатывает правильно, прогон зелёный, а запросов к базе он делает в сто раз больше прежнего. Я убрал из фонового планировщика классический N+1 — самым что ни на есть учебным способом — и чуть не выкатил в прод версию, где нагрузка росла как квадрат числа пользователей. Разбираемся с замерами в руках: при чём тут expire_on_commit, почему предзагрузка пачкой сама по себе ни в чём не виновата и как одна строка превращает цикл в N².

Я делаю сервис по подписке и плачу налог как самозанятый. Пока платежей было три в день, чеки в «Мой налог» можно было выбивать руками. Когда они пошли круглосуточно, понадобилась автоматика — и выяснилось, что сложное в этой задаче не 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 и почему иногда проще сделать своё.