Всем привет! Хотел бы поговорить о мониторинге наших web, да и не только web, приложений, в первую очередь, о проблемах, с которыми мы сталкиваемся. В этой статье я буду использовать язык python и популярные сервисы, чтобы содержимое было максимально понятно большинству.
У GitPython есть защита от опасных опций git. Я передал ей --upload-pack=/srv/lab/helper.sh, она отказала. Передал то же самое записью короче, -u/srv/lab/helper.sh, и она пропустила: скрипт выполнился. Это CVE-2026-67324, уязвима 3.1.50, исправлено в 3.1.51. Ниже стенд, живой вывод обеих попыток и разбор, почему шестистрочная проверка промахнулась.
Недавно встретились с коллегой за кружкой кофе, без всякой рабочей повестки. Он занимается Data Science, я — backend‑разработкой. Разговор как‑то незаметно, как это обычно бывает, свернул в сторону обсуждения рабочих нюансов, а самый обычный вопрос про очередной график в дашборде — закончился идеей проекта, который в итоге вырос в open‑source фреймворк.
В какой‑то момент он сказал фразу, которая неожиданно зацепила:
Когда говорят про оптимизацию под ИИ, обычно представляют работу с текстом на сайте. Но у меня раз за разом всплывает более базовая проблема: модель вообще не понимает, что за компания стоит за названием. Путает её с иностранной компанией с похожим названием, приписывает чужие продукты, называет не тот город. Это провал не контента, а цифрового следа компании (entity footprint), и его можно измерить.
В прошлой статье я рассказывал про WhyTrend — open-source инструмент, который не просто находит аномалии во временных рядах, а пытается объяснить, почему они произошли: собирает внешний контекст (новости, Hacker News, Wikipedia) и формирует объяснение со ссылками на источники. Если коротко: идея выросла из наблюдения, что находить аномалии мы научились отлично, а вот объяснять их до сих пор приходится вручную — гуглить, листать Reddit и Slack, собирать гипотезу самому.
Эта статья — про внутреннюю кухню: почему WhyTrend в итоге оказался фреймворком, а не очередной библиотекой, и какие архитектурные решения к этому привели.
Почти любая распределенная платформа рано или поздно сталкивается с необходимостью синхронизировать данные между своими системами. И чем выше требования к надежности и скорости доставки изменений, тем меньше остается простых решений. Бизнес-пользователям при работе с интерфейсом одной из платформ нужно знать о сущностях, заведённых во второй. Первая хранит их в реляционной СУБД (неважно, какой именно), а вторая - в документоориентированной 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 раз дороже?
Нет. И вот почему.
