И это не тавтология... Проверьте свое знание синтаксиса, критическое мышление и умение вчитываться в ТЗ.
Условие
Идут обычные рабочие будни. Вы — ведущий DevOps-инженер в крупном маркетплейсе. В компании вовсю идет распродажа, и система распределенных вычислений на базе Celery работает на пределе возможностей, обрабатывая терабайты аналитики. В самом начале смены дежурный инженер замечает в системе ровно 100 активных задач. Согласно внутренней архитектуре, эти задачи зациклены: каждая задача после своего успешного завершения автоматически генерирует и ставит в очередь ровно одну новую задачу.
Через пару часов инженер бьет тревогу в рабочий чат: «Ребята, у нас проблема! График застыл! Похоже, планировщик завис или сеть легла, процессы не плодятся!». Вы открываете логи, смотрите на графики мониторинга и… Система работает абсолютно штатно, никакого бага нет.
Задача
Объясните паникующему инженеру, почему его логика отказала. Как так получилось, что количество задач не растет? Напишите простую симуляцию этого процесса на Python, чтобы наглядно показать коллеге, как ведет себя такая очередь.
Представлен открытый проект Memora, который сохраняет работу Codex и Claude Code между сессиями. Внутри решения находится локальная база SQLite или синхронизация через S3, R2 и Cloudflare D1. Есть также семантический поиск, TODO, документы и связи между воспоминаниями. ИИ-агент запрашивает тему и получает готовый комплект данных: важный контекст, незакрытые задачи, связанные факты и ссылки на источники. Причём всю память можно открыть как интерактивный граф и изучать через встроенный RAG-чат.
Заметка о том как работает алгоритм инкрементальной загрузки, она же дельта, в ETL процессах. Полезно будет для тех кто только погружается. Для загрузки данных в хранилище данных мы выполняем два отдельных процесса: первоначальную загрузку исторических данных и инкрементальную загрузку. Первый процесс делается разово, а второй выполняется периодически. Инкрементальная загрузка выбирает только новые, еще не загруженные данные из источника в цель. Например, пользователи постоянно генерируют новые данные, бизнес работает. Система запускалась час назад и забрала новые на тот момент данные. При следующем запуске алгоритм определяет максимальную дату в цели: max_timestamp = SELECT MAX(timestamp) FROM target_table
и выбирает все записи из источника которые новее max_timestamp
SELECT * FROM source_table WHERE timestamp > max_timestamp
При следующем запуске алгоритм снова заберет новые данные. И так далее, бесконечный цикл. Колонка по которой определяются новые данные бывает не только типом timestamp, но и просто датой и числовым значением. В виде наглядно показан процесс.
Nvidia представила открытый проект Nemotron VoiceChat. Это голосовой ИИ‑агент, способный открывать любые инструменты по команде пользователя в реальном времени:
Nemotron говорит с вами без пауз и умеет в эмоции;
разрешает вам перебивать себя с задержкой всего 480 мс;
умеет вызывать инструменты посреди диалога — поиск в сети, календарь и так далее;
поддерживает сложные сценарии использования;
обучен на 550 тысячах часов речь;
умеет слушать, говорить, прерывать ответы и вызывать инструменты в рамках одного диалога.
SmileLadder. Как трилогия про "память и мозг" привела к циклу про управление вниманием. Пост №1 - от синтетической к реальной ЭЭГ
В прошлой статье я попробовал описать внимание как динамическое распределение весов в графе. Тогда нейронная активность, оцениваемая по ЭЭГ, были синтетическими: граф состоял из модельных узлов, а сигнал генерировался осцилляторами в модели Хиндмарша-Роуза.
Публикация получилась сложная и я этим постом попытаюсь перейти к разбору исследования вопроса управления вниманием. Первое, что я попробую - это возьму реальную ЭЭГ: Для проверки я использовал открытый датасет STEW — Simultaneous Task EEG Workload. В нём 48 участников: для каждого записаны состояние покоя и работа с многозадачным тестом SIMKAP.
На реальной EEG индекс ASI (по которому я выдвигал гипотезу, что он может быть оценкой уровня внимания) различает покой и высокую когнитивную нагрузку. Но есть важные ограничения, о которых скажу ниже.
Берём реальную EEG - там 14 EEG-каналов, частота дискретизации 128 Гц. Всего 96 записей.
Каналы сгруппированы по областям: префронтальной, фронтальной, фронтоцентральной, височной, теменной и затылочной. Полная таблица соответствий лежит в репозитории.
Вот так использую свою модель
EEG делится на окна по 4 секунды с шагом 2 секунды. Для каждого окна рассчитываются четыре компонента:
спектральная вовлечённость - отношение активности beta к theta и alpha;
alpha gating - изменение задней alpha-активности;
фазовая организация - согласованность theta-ритма между передними и задними каналами;
пространственная селективность - насколько неравномерно распределена вовлечённость по каналам.
На этих 14 каналах обучается графовый attention-readout. В коде он называется узелTHAL - это скрытый вычислительный узел-оркестратор.
Практический результат: у 48 участников из этого датасета медиана ASI-EEG составила:
0,5129 в покое;
0,5311 при высокой нагрузке.
Медианный парный сдвиг равен +0,0218, 95% bootstrap-интервал — [0,0049; 0,0533]. Парный критерий Уилкоксона дал p = 0,00182. Это означает, что нулевая гипотеза об отсутствии различий отвергается, так как p-value меньше стандартного уровня значимости 0,05.
На этих данных ASI-EEG действительно реагирует на изменение когнитивного состояния. Это уже не результат виртуальной EEG, а эффект, полученный на записях реальных тестов.
Есть и второй пруф: графовый классификатор проверялся с разделением участников между фолдами. На уровне целой записи он различил покой и нагрузку с точностью 88,5%, а ROC AUC составил 0,969.
Практический цикл управления вниманием я теперь вижу так:
задачи и контекст → оценка ожидаемого фокуса → EEG-маркер фактической нагрузки → обратная связь → корректировка списка задач
Текущий репозиторий закрывает только один фрагмент этого цикла: показывает, что реальная EEG содержит воспроизводимый сигнал изменения нагрузки. Следующий шаг - не «читать мысли», а научиться замечать момент, когда нагрузка перестаёт быть продуктивной мобилизацией и превращается в распад селективности.
Код, данные расчёта и графики: GitHub-репозиторий - его я форкнул от задачи идентификации и дописал свою часть.
сгенерированные файлы могут быть легко импортированы в другие движки, такие как godot / unity и т.д.
в настоящее время поддерживаются 2 версии UE engine: 5.5 и 4.27.2
вы также можете заметить, что некоторые материалы в тестовой сцене частично затемнены - это связано с тем, что пакет не позволяет вам правильно экспортировать все настройки материалов / все настройки шейдеров (ограничения перечислены на странице github, это освещение, положение камеры и другие параметры, но базовое извлечение 3d-сетки работает идеально).
но вы, очевидно, можете редактировать материалы после экспорта вручную в движке, в который вы их импортировали, изменяя размеры текстур / нормалей / добавляя пользовательские общие элементы и т.д.
Главное изменение — MCP стал stateless на уровне протокола. Убрали обязательные initialize, initialized и Mcp-Session-Id. Версия протокола и возможности клиента теперь передаются в каждом запросе, а сведения о сервере можно получить через server/discover. Любой запрос может обработать любой экземпляр сервера — без sticky sessions и общего хранилища сессий. Состояние приложения никто не запрещает: просто передавай явные идентификаторы вроде browser_id в аргументах инструментов.
Что ещё важно:
Долгие операции получили нормальный жизненный цикл. Tasks позволяют вернуть taskId, а затем проверять состояние через tasks/get, передавать дополнительные данные через tasks/update и отменять работу через tasks/cancel. Но Tasks не появились с нуля — раньше это была экспериментальная часть ядра, теперь её переработали и вынесли в официальное расширение.
Протокол стал удобнее для эксплуатации. Заголовки Mcp-Method и Mcp-Name позволяют маршрутизировать запросы, не разбирая JSON. Появились стандартные подсказки для кеширования — ttlMs и cacheScope, а также единые поля для передачи OpenTelemetry Trace Context.
Переработано общение сервера с клиентом. Вместо произвольных server-to-client запросов сервер теперь может вернуть input_required, после чего клиент повторяет исходный запрос с ответом пользователя. Подписки на изменения вынесены в subscriptions/listen.
Extensions стали полноценной частью экосистемы. Новые возможности теперь можно развивать отдельно от ядра. Первые заметные расширения — Tasks и MCP Apps. Последнее позволяет серверу отдавать интерактивный HTML-интерфейс, который клиент показывает в изолированном iframe.
Есть важные ломающие изменения. Все результаты теперь содержат resultType. Roots, Sampling, Logging и старый HTTP+SSE объявлены устаревшими. Схемы инструментов получили полноценную поддержку JSON Schema 2020-12. Если ты пишешь MCP-клиент или SDK, этот пункт может оказаться важнее MCP Apps.
Авторизацию подтянули ближе к реальному OAuth/OIDC. Добавили проверку iss, привязку учётных данных к конкретному issuer и уточнили регистрацию клиентов и работу с refresh-токенами.
В сухом остатке: remote MCP перестал требовать обязательную протокольную сессию и стал гораздо больше похож на нормальный stateless JSON-RPC поверх HTTP. Для продакшена это означает более простое горизонтальное масштабирование, маршрутизацию и кеширование. Остальные изменения полезны, но в основном касаются новых возможностей и миграции клиентов.
«Bad Apple!! Но это же traceroute! В продолжение моего поста о том, как заставить инструменты traceroute отображать произвольное содержимое, и вдохновлённый выходом на днях ещё одной кавер‑версии Bad Apple, я просто не мог не сделать это», — пояснил Йонас Шефер.
Используя функцию numgen из библиотеки nftables, мы можем изменять количество переходов каждый раз при генерации пакета ICMPv6. Функция numgen возвращает либо случайные числа, либо монотонный счетчик. С помощью счётчика мы можем легко настроить каждый переход так, чтобы он возвращал разный IPv6-адрес при генерации ответного пакета.
Для этого потребовалось ещё две вещи. Во-первых, необходимо отключить ограничение скорости ядра (по умолчанию 1/с) для исходящего трафика ICMPv6 с помощью команды sysctl net.ipv6.icmp.ratelimit=0, иначе всё закончится очень быстро. Вторая проблема заключается в том, что mtr обычно показывает несколько адресов для каждого узла, поскольку это указывает на использование нескольких разных путей для пакета, и это обычно полезная информация.
После всего этого я использовал ffmpeg для передискретизации видео до 8 кадров в секунду (что соответствует интервалу в 125 мс между кадрами) и экспорта уменьшенных (до 30x11 пикселей) отдельных кадров в файлы PNG. Затем я написал скрипт на Python для чтения файлов изображений и преобразования их в набор правил nftables для генерации соответствующих ответов ICMPv6. В результате получается чуть более мегабайта правил nftables, но это определённо того стоит.
PyPI готовится закреплять префиксы имен пакетов за организациями
29 июня 2026 года был принят PEP 752. Он описывает механизм, с помощью которого пакетные репозитории смогут закреплять префиксы имен за определенными организациями. Например, новые пакеты с префиксом google-cloud- смогут публиковать только организации, получившие соответствующее право.
Сейчас пространство имен PyPI остается плоским. Если название свободно, пользователь может зарегистрировать пакет, который выглядит частью известного проекта, например, google-cloud-something, opentelemetry-something или apache-airflow-providers-something. Знакомый префикс повышает доверие к названию, хотя реального отношения к организации у пакета может не быть.
PEP 752 предлагает закреплять за владельцем как сам префикс, так и новые названия, которые включают префикс и дефис после него. Попытка опубликовать такой пакет без разрешения будет завершаться ошибкой. При этом уже существующие проекты можно не блокировать. Репозиторий вправе разрешить их владельцам выпускать новые версии и после появления защищенного префикса.
Синтаксис имен не изменится, поэтому дорабатывать pip, uv и другие менеджеры пакетов ради обычной установки не потребуется. Вместе с тем в API репозитория появятся сведения о связи проекта с защищенным префиксом. В дальнейшем менеджеры пакетов и прокси смогут учитывать их в собственных политиках.
Принятый PEP пока описывает стандарт, а не уже работающую функцию PyPI. Правила подачи и рассмотрения заявок вынесены в PEP 755, который остается черновиком. Срок запуска механизма также пока не объявлен.
PEP 752 переносит часть проверки на самый ранний этап, когда в репозитории только появляется новое имя. Для семейств пакетов вроде google-cloud-* или apache-airflow-providers-* это позволяет остановить постороннего издателя до того, как правдоподобно названная подделка станет доступна пользователям.
У такой защиты есть довольно четкие ограничения. Право на префикс подтверждает, что издатель может использовать такое имя в конкретном репозитории, но ничего не говорит о безопасности содержимого. Если учетную запись доверенного издателя скомпрометируют или он сам выпустит вредоносную версию, резервирование не поможет. На другой репозиторий выданное право тоже не распространяется.
Когда механизм заработает, новые метаданные можно будет использовать не только на страницах PyPI. Менеджеры пакетов и корпоративные прокси смогут пропускать пакеты с защищенным префиксом, только если издатель имеет на него право. Это точечная защита от одного семейства атак на имена; остальные сценарии неймсквоттинга мы разбирали в статье «Атаки на цепочку поставки ПО: виды угроз и как с ними бороться».
Сначала хотел написать комментарий к этой статье, но потом подумал, что пост лучше.
Наверно, просто каждый язык предназначен для решения своего круга задач. Когда-то фортран был языком для вычислений. Паскаль - для обучения. Си - для системных разработок. А вот Бейсик (я про компилируемые варианты) был универсален. :) Оттого, наверно, я его и выбрал в начале 90-х. Хотя с тех пор от него ничего не осталось, даже в плане синтаксиса, не говоря про огромные возможности...
А вот вопрос: какой язык может быть выбран в качестве "бытового"? Это не шутка. Лично я регулярно сталкиваюсь с необходимостью написать "одноразовую" программу, маленькую и не сложную. Для этого нужен простой язык и легкий транслятор. Раньше я использовал VB3, но он на новых системах не работает. Потом "открыл для себя" SmallBasic и даже написал по нему некое пособие. Язык хороший, реально! Но есть один огромный минус, в силу чего он не годился для искомой роли: не работает с двоичными файлами. Свой собственный язык ("Ellochka") я так и не удосужился до сих пор перевести под Виндовс (остался интерпретатор для ДОС). Питон, увы, тоже не подходит: язык не очень прост, а главное - среда огромная, с флешки запускать несерьезно (а надо).
Так вот и вопрос: есть сейчас язык, подходящий для описанной задачи? Простой, легкий (в мегабайтах), без лишних наворотов, но "все что нужно есть"? Может, кто подскажет?
Ваш проект живёт дольше трёх месяцев? Код начинает сопротивляться изменениям: одна фича тянет правки в пяти файлах, тесты падают без внятного объяснения. Знакомо?
Представим, что в вычислительном кластере из 1 000 серверов одна машина заражена неизвестным вирусом. Он не нагружает процессор, не генерирует подозрительный сетевой трафик и не оставляет следов в системных журналах. Только раз в сутки вирус незаметно повреждает один файл резервной копии.
Для поиска зараженного узла начинающий сисадмин Олег написал анализатор логов. Скрипт проверяет любое количество серверов одновременно, объединяя их журналы в единый пул. Результат проверки может быть только двух видов:
Status: 500 — если среди проверяемых серверов есть зараженный;
Status: 200 — если зараженного сервера в группе нет.
При этом анализатор нагружает сеть и системы хранения данных, поэтому его разрешено запускать не более 10 раз в сутки. Все проверки должны быть спланированы заранее и отправлены в расписание на весь день. Изменять состав очередной проверки после получения результатов предыдущей нельзя.
Задача
Помогите Олегу определить — предложите решение, которое позволит определить один зараженный сервер из 1 000 возможных за 10 запусков анализатора. Напишите код на Python, который по результатам проверок сможет определить номер зараженного узла.
Появилась идея: локальная база знаний, строящаяся по коду проекта на вашем компе и способная человеческим языком отвечать на вопросы по проекту, помогающая джунам быстро вкатиться в суть, а синьорам бегло проверить что они сломают очередным обновлением. Интересно ли было вам таким пользоваться? Помогло ли бы оно?
Поделитесь в комментариях)
Upd. Спасибо за комментарий, важная оговорка: проект работает локально на вашем компе, без утечек в инет)
Представлен открытый проект ODS (Osmantic Deployment System). Это проект, который превращает ПК в приватный ИИ‑сервер. Решение само определяет характеристики ПК, подберёт под них подходящую модель, скачает её и запустит локальный инференс:
все локально и приватно: можно работать с документами, кодом и другими важными данными;
через одну панель можно подключить голосовых помощников, агентов вроде Hermes, RAG, поиск, генерацию изображений и десятки других инструментов;
Агент Ануфрий получил красивый вывод в терминал (отключаемый через конфиг).
Как всегда, ничего сложного, используются две библиотечки Rich + Prompt Toolkit. Вся эта красота хранится в отдельном модуле console, легко сможете разобраться, переделать, или подчерпнуть что-то для своих проектов. Кода там совсем немного.
Есть идея в отдельной ветке Ануфрия запилить “кибербезопасника”, вырезав все лишнее и напихав скилов под инструменты Kali Linux. Мне кажется, тут LLM может проявить себя с хорошей стороны, если грамотно предоставить инструментарий.
Возможно что-то похожее уже кто-то реализовывал? Если да, поделитесь информацией об успехах.
P.S.: Ануфрий - это мой проект простого конструктора для создания собственных ассистентов на Python.
Выбор товарной группы для работы в настройках (одиночный выбор из справочника). Реализованы 22 доступные группы (исключены алкоголь, табак, мех, ветпрепараты и др.)
Запрос и отображение баланса денежных средств в ЧЗ на дашборде. Кнопка «Обновить баланс» для ручного обновления.
Загрузка данных МОД из API Честный Знак по кнопке. Автоматическое заполнение адреса и FIAS ID. Предупреждение при отсутствии МОД со ссылкой на ЛК ЧЗ.
Сканирование: проверка GTIN КМ для SKU, авто-определение правильного SKU, онлайн-проверка статуса ЧЗ сразу после добавления
При импорте теперь выдает детальный отчёт об ошибках с модальным окном и экспортом в CSV (дубликаты, структура, GTIN, статус ЧЗ).
Продажа: блокировка поиска по GTIN/Артикулу/EAN для товаров с маркировкой (только поиск по КМ).
Склады: улучшенное отображение — таблица SKU с колонками Остаток/Продано.
Далее планирую заняться работой с отчетами: вывод из оборота, аннулирование отчета о выводе и ввод назад в оборот
А там глядишь и до заказа КМ доберусь и вводе в оборот :)
Начал писать тесты для бота. Оказалось не так страшно как думал
Долго откладывал тесты для своих ботов. Казалось что это боль: нужно мокать API, имитировать апдейты, непонятно с чего начать.
Начал с малого. Вынес всю бизнес-логику в отдельные функции которые не знают ничего про Telegram. Просто принимают данные, возвращают результат.
python
# Не так
async def handle_payment(message: types.Message):
amount = int(message.text)
if amount > 10000:
await message.answer("Сумма слишком большая")
# А так
def validate_amount(amount: int) -> tuple[bool, str]:
if amount > 10000:
return False, "Сумма слишком большая"
return True, ""
async def handle_payment(message: types.Message):
is_valid, error = validate_amount(int(message.text))
if not is_valid:
await message.answer(error)
Теперь validate_amount тестируется обычным pytest без всяких моков. Вызываешь функцию, проверяешь результат.
Звучит очевидно. Но я долго писал всю логику прямо в хендлерах и потом удивлялся почему тестировать неудобно. Оказывается проблема была не в тестах, а в архитектуре.
Покрытие пока небольшое, но уже несколько раз тесты поймали регрессию которую я бы заметил только в продакшене.
С момента написания прошлой статьи про мою самописную товароучетную систему для работы с маркировкой «Честный Знак», я добавил новых фич и поправил существующие ошибки. Основные изменения следующие:
В Остатках в карточке товара появилась кнопка «Списать», позволяя сделать быстрое списание с нулевой ценой и выбором причины: утеря, собственные нужды, производственные цели, безвозмездная передача, отзыв с рынка. Данные нужно подавать также вручную, но для учета полезно.
Добавлен вид документа в продаже: поле «Вид док-та» в шапке заказа (Прочее, УПД, Товарная накладная, Акт приёма-передачи, Кассовый чек).
Появилась кнопка «Скачать КМ в CSV» в корзине Продаж для скачивания КМ в формате «для ввода/вывода из оборота» для вставке в ЭДО при передаче УПД.
Дропдаун «Статус» теперь показывает статус ЧЗ для проданных товаров.
Появилась возможность выделить и произвести массовую проверку статуса ЧЗ для выделенных товаров (чекбоксы + кнопка) на вкладках Остатки, Продано, Вывод из оборота.
Появилась колонка «Статус в ЧЗ» в таблицах Остатки и Вывод из оборота
Сделано автоподтверждение отчёта о выбытии при статусе ЧЗ равном «Выбыл» (RETIRED/WITHDRAWN/WRITTEN_OFF)
Сделано сохранение активной вкладки при перезагрузке страницы
Введена новая логика быстрой продажи: в шапку заказа: номер заказа, склад списания, дата продажи, добавление нескольких товаров по КМ/артикулу/EAN-13 с ценой за позицию в корзину с одинаковым номером заказа, КМ для Маркетплейсов отображается в корзине и копируется кликом, сделан Live-поиск при вводе кода с полной информацией о товаре.
ПО я писал для своей товарной группы «Игры и игрушки», но оно должно подходить и для других товарных групп потребительских товаров.
Сразу напишу про API: авторизация по ЭЦП и получение общего статуса по КМ все еще ведется по 3 версии API Честного Знака, как и например работа с МОД, а что-то уже работает только по 4 версии API (например ввод-вывод из оборота).
