Перед сделкой с альткоином мне обычно нужно быстро ответить на два вопроса: есть ли у цены выраженное направление и происходит ли в монете что-то заметное прямо сейчас. Смотреть для этого десяток страниц на разных биржах неудобно, поэтому я собрал небольшой сканер.
Пользователь отправляет тикер и получает три результата: направление активность и итоговый статус.
Поднял Recall@5 поиска по памяти на 17%, померил качество самих ответов и получил прирост, неотличимый от шума: тест Макнемара, p = 0.79. Месяц работы впустую. Потом посмотрел в промпт, поправил там одну формулировку и получил плюс 16 процентных пунктов за вечер. Модель отказывалась отвечать, когда ответ лежал прямо перед ней.
Внутри: как собрать свой набор проверочных вопросов и не обмануться, почему параметры BM25 из статей проиграли подобранным перебором, и какие шесть приёмов не сработали вообще.
Несколько месяцев назад я начал делать небольшой сервис для контейнерной логистики.
Изначальная идея была довольно простой: заменить бесконечную публикацию одних и тех же грузов и свободных машин в рабочих чатах нормальным поиском.
Так появился ГрузоБот это сервис для грузоотправителей, экспедиторов и перевозчиков, работающий через мессенджер MAX.
Сейчас проект уже находится в бета, но продакшене, поэтому хочу рассказать не столько о самом сервисе, сколько о том, что оказалось под капотом и с какими задачами пришлось столкнуться при разработке.
Для параллельной работы больше не обязательно каждый раз поднимать команду сабагентов. Уже открытые сессии принимают задания, отдают результаты и передают друг другу нужный контекст.
Но если честно проще в вашем стиле попросить кодекс/клод объяснить как оно все работает, чем читать эту статью, она для неленивых.
У Telegram-бота может быть только один активный webhook. У меня при этом появились три независимых сценария: поддержка пользователей, управление небольшим магазином и внутренние административные команды. Склеивать их в один процесс не хотелось, заводить отдельного бота под каждый сервис — тоже.
Пока я выбирал архитектуру, переезд панели с одного домена на другой неожиданно провёл бесплатный chaos test: Telegram продолжил отправлять updates на старый адрес, получил 301 Moved Permanently и перестал доставлять сообщения. В очереди зависло шесть updates, а со стороны пользователей бот просто замолчал.
В статье разберу диагностику этого инцидента и устройство небольшого open-source router на FastAPI и Redis: с декларативными правилами, дедупликацией, надёжной очередью, retry и HMAC-подписью внутренних запросов.
Или пример того, что будет, если роль пакетного менеджера доверить AI.
[ Перед прочтением ознакомьтесь с политикой безопасности в вашей компании ]
Коллеги жаловались на дубли в базе пользователей: людей меньше, чем учётных записей, а откуда берётся расхождение - непонятно. Объяснилось оно одной строкой в коде, которая сравнивает адреса посимвольно.
В базе четыре учётные записи: Ivan.Petrov@gmail.com, ivanpetrov@gmail.com, ivan.petrov+shop@gmail.com, IVAN.PETROV@gmail.com. С точки зрения кода это четыре разных строки. С точки зрения почты - один и тот же ящик, все письма придут в одно место.
Дальше начинается интересное: акции «только для новых пользователей», лимиты на бесплатный период, «одна заявка на человека» - всё это обходится без единой уловки, просто точкой в адресе.
Представь простую задачу: ты просишь агента пересказать содержимое сайта.
Не установить пакет.
Не запустить скачанный скрипт.
Не открыть подозрительное вложение.
Просто прочитать страницу и сделать краткое резюме. Через несколько шагов на твоей машине выполняется код атакующего, устанавливается соединение с управляющим сервером и для наглядности открывается калькулятор.
И самое интересное: агент не нарушал прямой запрет. Наоборот, в ключевой момент он поступил "безопасно" — отказался запускать неизвестный бинарный файл и написал собственный декодер на Python. Именно это решение и стало частью атаки.
Такую цепочку продемонстрировал исследователь безопасности Иоганн Ребергер на Claude Code с моделью Opus 5 в Auto Mode. В его небольших сериях тестов атака срабатывала в трёх или четырёх запусках из пяти. Это не означает, что "Claude взламывается с вероятностью 80%", но хорошо показывает более важную проблему: безопасный на вид отдельный шаг ничего не гарантирует, если вся цепочка строится в среде, которую контролирует атакующий.
Я бы сделал начало более естественным и менее похожим на презентацию продукта. Например:
В прошлой статье я разбирал, как с помощью Python и Telethon автоматизировать сбор публикаций из Telegram‑каналов. Тогда мы фактически решали задачу первого уровня: получили сообщения, забрали текст и сохранили результат.
На практике довольно быстро выясняется, что у Telegram‑публикации есть гораздо больше интересных данных, чем просто текст.
У сообщения есть источник, время публикации, просмотры, реакции, комментарии, медиафайлы и другие связанные данные. Если собирать информацию сразу из нескольких каналов, всё это уже хочется не просто выгрузить в таблицу, а нормально связать между собой.
Например, один и тот же пользователь может встречаться сразу в нескольких чатах, а один пост может иметь десятки комментариев и несколько типов реакций. При обычном экспорте такие связи быстро теряются.
Поэтому после первой версии парсера я решил пойти немного дальше и посмотреть, что получится, если относиться к Telegram не как к источнику отдельных сообщений, а как к набору связанных данных.
В этой статье покажу, как я организовал такой сбор, какие данные можно получить из публикаций и что с ними можно делать после парсинга.
Сервис зависает, контейнер не отвечает, а в логах — только «обработанные» ошибки. Часто причина таких инцидентов скрывается в слишком широком except Exception, который мешает приложению корректно завершаться. Разберем, как правильно обрабатывать исключения в production‑воркерах и избежать подобных проблем.
Привет! В предыдущей статье https://habr.com/ru/articles/1042328/ я рассказал о математической оценке коэффициента шума (КШ) методом отношения сигнал-шум. Сегодня перейдем от теории к практике - к автоматизации радиоизмерений. Покажу, как построить гибкую систему управления измерительными приборами на Python, которая не боится разношёрстного парка оборудования в лаборатории.
Вечером 02.09 у нас не вышел плановый пост в TenChat. В логе задачи планировщика — ничего осмысленного, просто ненулевой код возврата и алерт «слот не закрыт». Разбор растянулся на весь вечер, потому что там оказались не одна поломка, а три, и каждая маскировала следующую.
Тикет пришёл от разработчика, который писал импорт учёток из старой системы. Формулировка была такая: «кажется, у нас ломается верификация, но ломается она в плюс — подходят пароли, которых не было».
Ломалось не у него. Так работает bcrypt, и работает уже двадцать семь лет.
Команда — шесть разработчиков, полтора десятка параллельных проектов. Задачи жили в Excel, чатах и головах. В какой-то момент стало понятно, что «а кто это делает?» задаётся чаще, чем «как это сделать», — пора заводить трекер.
Дальше случилось то, что случалось у многих: мы честно прошлись по рынку, везде что-то мешало, и в понедельник я открыл пустой репозиторий. Во вторник команда уже вела задачи в своём трекере.
А самое интересное произошло между этими точками: канбан-доска — то, ради чего всё затевалось, — прожила в интерфейсе два с половиной часа. По истории коммитов видно точно.
Расскажу по порядку: почему не подошло готовое, что выкинули, что оставили и почему «свой трекер за два дня» — это не подвиг, а холодный расчёт про длину петли обратной связи.
Почему не готовое
Сразу дисклеймер: всё перечисленное ниже — нормальные инструменты. Не подошли они нам из-за наших ограничений, а не потому что плохие.
Jira и Linear отпали первыми: данные о внутренних проектах не должны жить во внешнем облаке, а с обслуживанием российских аккаунтов у обоих вендоров всё сложно. Kaiten, YouGile, Weeek — приличные российские альтернативы, но это опять облако с чужим хранением, а по деньгам на команду — подписка за то, чем мы будем пользоваться на пять процентов.
Self-hosted Plane был ближе всего, но тащить и обслуживать чужой комбайн ради шести человек не хотелось.
GitHub Issues мы используем и любим, но тут споткнулись о главное: трекер нужен не только разработчикам. Руководителю нужны карточки, сроки и картинка загрузки — а не list view с лейблами. Фраза, убившая этот вариант, звучала так: «Issues не умеют пользоваться менеджеры». Это не претензия к менеджерам — это факт о интерфейсе.
Огромное количество разработчиков мечтают создать свой проект, который будет приносить им доход поверх зарплаты на основной работе.
Начинается все с большого энтузиазма, грёз о том, какой классный и полезный будет его продукт. Потом формирование основного функционала, планирование разработки, рисование архитектуры и инфраструктуры, создание репозитория и, конечно же, разработка. У кого-то это длится несколько недель, у кого-то годами. И вот когда заветный проект готов, назначается так называемая дата релиза. Проект уже запущен локально или в стейдж окружении, создатель его протестировал, все работает хорошо, возможно даже дал попользоваться нескольким знакомым, которые нехотя прокликали и сказали, какое же классное и полезное приложение.
В дату релиза проект деплоится в прод. Но почему-то там все также один пользователь — сам создатель.
Ты вроде и понимаешь почему, логично ведь, что без рекламы и маркетинга пользователей не будет, но пока пишешь код - делаешь, что умеешь, а маркетинг это что-то неизвестное и непонятно. На самом деле маркетингом нужно было заниматься с первого дня, даже раньше, чем пришла идея.Но пока вернемся к нашему наивному разработчику.
Он сидит, смотрит на свой проект и прям чувствует, как энтузиазм сходит на нет. Приходит понимание, что нужно как-то привлекать пользователей, но как? На самом деле на этом этапе уже многие так и остаются, и проект просто попадает на так называемое «кладбище пет-проектов».
Но если же нет, то этому разработчику приходится становиться в абсолютно диаметрально противоположное амплуа, к которому он не привык. Ибо с приходом нейросетей разработка стала менее ценной, проектов больше, конкуренция за пользователя выше, соответственно маркетинг сложнее.
За последнее время я написал три статьи про систему, которая превращает длинные видео в вертикальные клипы: общий обзор «аниме-завода», разбор виртуальной камеры с face tracking и рассказ о том, почему связка «транскрипт + LLM» почти всегда даёт мусор.
Комментарий, который повторялся под всеми тремя, был один и тот же: «покажи код».
Показываю.
→ github.com/ialakey/shorts-factory
Это витринная ветка большого приватного проекта: MVP, в котором оставлен полный путь «взял длинное видео → получил готовый вертикальный клип», а всё остальное вырезано. Ниже — что именно внутри, как код соотносится с тремя предыдущими статьями и что пришлось выкинуть.
Полезная внутренняя функция редко остаётся функцией без зависимостей. Сегодня ей понадобился python-dateutil, завтра — конкретная версия NumPy. Когда тот же код нужен во втором проекте, приходится либо менять его lockfile, либо собирать отдельный контейнер, либо превращать десять строк в сервис.
splime предлагает ещё один вариант: опубликовать доверенную Python‑функцию вместе с точными версиями пакетов и вызывать её по имени. Локальный демон сам собирает окружение и хранит его отдельно от проекта, который будет вызывать функцию. Общая модель была в первой статье, а упаковка функции — в предыдущей части. Этот текст можно читать отдельно.
Сначала запустим функцию, чья зависимость вообще не установлена у вызывающего кода. Затем посмотрим, откуда берётся venv, почему он кэшируется и когда одной ноде стоит назначить native, venv-subprocess или Docker. Материал рассчитан на macOS и Linux с Python 3.13+; в splime 0.4.9 сборка локальных окружений требует POSIX.
Идея агрегатора новостей по кибербезопасности зародилась еще давно. Хотелось получать самое важное и без инфошума. LLM тогда ещё не были повседневным инструментом, и первую версию реализовал на модели суммаризации rut5_base_sum_gazeta, а важность считал textrank. Работало так себе. Потом появились сервисы, которые сами подбирают новости под настроенную ленту. Но оптимального решения так и не увидел – это либо про всё сразу, либо что-то про одну узкую тему.
Задача изначально выглядела простой. Моделей полно, готовых наработок должно было быть много. Но на практике уже первые недели ушли на тюнинг, и лучше при этом не становилось: поднял порог – канал молчит сутки, опустил – в ленту попали вебинары, квадранты и пресс-релизы продуктов. Из этого опыта родилось гибридное решение. Важность теперь считает формула из семи признаков, все логируется, а модель пишет тексты и отсекает нерелевантное.
31 августа в 14:32 по Москве у нас вышла последняя штатная публикация. Дальше cron честно стартовал по расписанию, генератор успевал выбрать тему и написать текст, но в ленте ничего не появлялось. Так повторилось четыре раза: три запуска 1 сентября и утренний запуск 2 сентября.
Вселенная постоянно меня удивляет тем, что здесь на Земле нет ничего постоянного — облака в небе в следующую секунду уже другой формы, а птенцы, едва вылупившись, уже через несколько недель становятся взрослыми птицами и навсегда покидают гнездо. Все меняется настолько стремительно, что кажется, и в космосе так же. Но нет, всякий раз, когда я получаю спектр звезды и вижу ее линии водорода неизменно на одних и тех же позициях, я удивляюсь: неужели свет не встречает на своем пути ничего, что может его изменить, там действительно так пусто?
Например, от Бетельгейзе свет идет около 600 лет, но в любой день сними ее спектр — линии на своих местах. А если взять объект за миллиарды световых лет от Земли, что покажут фотоны? Ученые говорят, на таком расстоянии длина волны света сильно растянута из‑за расширения пространства и линии смещены в красную зону спектра.
Мне захотелось проверить это самой. Что из этого вышло, я расскажу ниже, и забегая вперед, скажу, что спектр меня удивил. А начну с любопытной предыстории.
