Python *

📐 Применение природных алгоритмов оптимизации в строительном проектировании

Современное проектирование несущих конструкций — это всегда поиск баланса между жёсткими требованиями безопасности и экономической эффективностью. Классические градиентные методы часто не справляются с многомерными пространствами ограничений, характерными для задач ПГС. Поэтому в САПР и ТИМ-решениях всё чаще применяются алгоритмы, подсказанные природой.

🧬 Генетические алгоритмы (GA) Основаны на естественном отборе и эволюционной генетике. В проектировании используются для оптимизации топологии и сечений элементов. Классические примеры — подбор оптимальных размеров подошвы и глубины заложения фундаментов, оптимизация сечений балок и рам. Алгоритм итеративно “скрещивает” варианты, отсеивая решения с недопустимыми осадками, недостаточной несущей способностью или перерасходом бетона.

Отдельное направление — задачи раскроя. Генетические алгоритмы успешно применяются для оптимизации 2D-укладки деталей сложной формы на листах металла, чтобы минимизировать отходы. В 3D-постановке это работает при компоновке арматурных каркасов, раскладке сборных элементов в опалубке или плотной упаковке конструкций для перевозки.

🐜 Алгоритмы роевого интеллекта (Swarm Intelligence) Моделируют поведение групп организмов: миграцию птиц, поиск пищи насекомыми. Наиболее известны метод роя частиц (PSO) и муравьиный алгоритм (ACO). Применяются для трассировки инженерных сетей, автоматического армирования плит, оптимизации геометрии сложных фундаментов. PSO эффективно распределяет усилия по расчётной сетке конечных элементов, снижая концентрацию напряжений за счёт корректировки параметров армирования локальными агентами.

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

🔥 Алгоритмы имитации физических процессов К ним относится метод имитации отжига (Simulated Annealing), который моделирует кристаллизацию металла при охлаждении. Используется для решения комбинаторных задач: календарное планирование, оптимизация логистики движения материалов, расстановка монтажных кранов, распределение бригад по захваткам при жёстких пространственных и временных ограничениях.

⚠ Ограничения и инженерная практика При всех возможностях природные алгоритмы не заменяют классические расчётные комплексы (МКЭ/FEM). Сегодня они выступают как эффективные препроцессоры: генерируют концептуальные схемы расстановки несущих элементов, варианты раскроя и календарные графики, которые затем проходят обязательную ручную верификацию инженером-конструктором и финальный проверочный расчёт в сертифицированном ПО на соответствие СП/СНиП.

Такой подход позволяет сократить рутину на ранних этапах, но оставляет ответственность за итоговое решение человеку.

Как бы я учила Python, если бы могла отмотать время назад...

# Не судите строго, впервые пиши пост, понимаю, что может быть не интересно (по причине опыта), но все же хочется внести свой вклад

Всем привет! Меня зовут Фаина я уже несколько лет пишу на Python (и не только) и зарабатываю этим на жизнь. Недавно я наткнулась на свои старые "конспекты" с первых попыток изучения языка. Это было... больно. Сотни скриншотов, обрывочные заметки и полное непонимание того, что происходит.

Если бы у меня была машина времени, я бы вернулась к той испуганной девушке, которая впервые открыла IDLE, и сказала бы ей несколько важных вещей.

1.Перестать коллекционировать курсы (и начать делать)

Моя самая главная ошибка — «синдром хомяка». Я скачала, наверное, 50 ГБ курсов: "Python с нуля", "Python для чайников", "Python за 24 часа". Я смотрела первые два урока, чувствовала себя умной, а потом бросала, потому что "этот курс не очень".

Итог: Один хороший курс + практика лучше, чем 50 идеальных курсов в папке "Разобрать".
Сейчас, если бы я начинала, я бы выбрала один интерактивный ресурс (или одну книгу, если, конечно, сможешь так учится) и шла по нему, пока не упрусь в стену. Не прыгала бы между ютуберами и методичками.

2.Сначала гуглить, потом — паниковать

В начале пути любая ошибка в коде вызывала у меня панику. Красный трейсбек выглядел как приговор. Я думала: "Ну всё, я бездарь, Python меня ненавидит".

Итог: Ошибка — это не "я плохая", это "код говорит мне, что именно не так".
Сейчас 80% моей работы — это чтение ошибок и гугление.

3.Зубрежка синтаксиса не работает. Работают проекты

Я думала, что если выучу все методы списков и словарей наизусть, то стану сеньором. Я исписывала тетради шпаргалками. Толку было ноль.

Итог: Ты запоминаешь только то, что используешь руками.
Вместо заучивания теории, я бы начала писать мини-программы с первого дня.

• День 3: Калькулятор чаевых.

• Неделя 2: Парсер курса валют с сайта (с помощью requests).

• Месяц 1: Простенький телеграм-бот, который присылает погоду.

Проекты не обязаны быть гениальными. Они должны быть действительно интересные, даже захватывающие.

Если ультра-кратко:

1. Лучше уж один источник знаний вместо "все сразу"

2. Лучше практика каждый день по 30 минут, чем раз в неделю и до потери пульса

3. Ошибки - это норм, не стрем

4. С другом или ментором будем веселее и эффективнее - с кем можно поделится опытом или обсудить код и тд.

Спасибо за внимание, ваша Фаина!)

Какие уникальные фичи есть в django-modern-rest?

Иногда, когда я добавляю какие-то фичи в мой https://github.com/wemake-services/django-modern-rest (можно ставить ⭐), то я думаю про себя: почему таких фичей больше нет нигде? 

Давайте сегодня посмотрим на них. А вы мне расскажите свое мнение в комментах.

Семантическая схема 

Допустим, вы навесили на какой-то свой endpoint auth: 

class UserController(Controller[MsgspecSerializer]):
      @modify(auth=[JWTAsyncAuth()])
      async def get(self) -> User: ...

В OpenAPI автоматически появятся все коды ошибок, которые могут случиться в auth (401).
Ничего не надо допом писать. И так происходит со всеми частями фреймворка: добавил throttling=[SyncThrottle(1, Rate.minute)]? Теперь у тебя в ответах автоматом 429. Если нужно, можно отключить любые семантические статусы. 

Не должно ли такое быть дефолтом везде?

Умные типы ошибок

Не уходя далеко: как кастомизировать формат ошибки, например, в FastAPI? Через боль. Как поменять в спеке формат? Руками.

В DMR мы просто добавили везде error_model как параметр. Можно заменять любые ошибки, все автоматом сконвертится и покажет правильную схему. Зачем? Хочешь Problem Details - используешь. Хочешь свой формат - реализуешь. Можно даже content negotiation на ошибки навесить.

Почему никто о таком не думает в других фреймворках?

Нормальный throttling

Фича, которая принесла мне больше всех боли. Я прочитал throttling реализации во всех фреймворках. В Litestar даже фиксы присылал. 

1. Почти нигде из коробки нет поддержки разных алгоритмов, бекендов, иногда даже cache-keys. Очень жаль, есть только обычный counter с бекендом в памяти
2. Нигде (пришлите в комменты контр-пример) нет разделения на throttling до auth и после. Почему такое вообще важно? Чтобы не заддосить auth. И чтобы иметь возможность выдавать per-user правила. Нужны и важны оба варианта
3. Кастомизация заголовков ответа? Ха!

Что? Почему?

Простое переиспользование кода

Когда я смотрю на АПИ разных DRF проектов или FastAPI, мне становится больно. FastAPI строит все на view функциях, которые нельзя нормально кастомизировать. А DRF строит все на импортах строк внутри настроек. А как на счет классов и наследования?

У нас подобное сделано как абстрактные generic классы. Например: получить JWT. Можно выбрать любой сериализатор, можно выбрать любые модели для запроса и ответа:

class RequestPayload(pydantic.BaseModel):
     username: str
     password: str

class ResponsePayload(pydantic.BaseModel):
     access: str
     refresh: str

class ObtainAccessAndRefreshSyncController(
    ObtainTokensSyncController[
        PydanticSerializer,
        RequestPayload,
        ResponsePayload,
    ],
): ...  # надо еще переопределить 2 метода

Все типизировано, документировано, очевидно. 
Как вы думаете, почему так больше никто не делает?

Внешние вьюхи

Интегрировать один фреймворк в другой - крайне сложно. Вот мы недавно даже стрим проводили, потому что не могли использовать dj-rest-auth из DRF. Так быть не должно.

Теперь в DMR можно использовать любые внешние Django View. Хоть DRF, хоть django-ninja, хоть ванильные вьюхи. И отображать любой внешний OpenAPI. Вот настолько просто:

raw_schema = read_openapi_yaml('openapi.yml')
router = Router(
    urls=[
        external_path(
            'number/', number, name='number',
            openapi=load_schema(raw_schema['paths']['/api/number'], PathItem),
        ),
    ],
)

Почему другие фреймворки не стараются вписать существующие решения?

Одной строкой

- Больше подобного у меня в тегеграм канале "Находки в опенсорсе": https://t.me/opensource_findings
- У нас есть еще куча других крутых фичей! Заглядывайте в наш чатик по DMR
- Релизнули django-stubs@6.1 с поддержкой django@6.1
- Сделали папку с крутыми каналами ребят из нашего Python сообщества. Смело можно закидывать коллегам как базовую папку "на кого подписаться в тг по питону". Внутри все мои друзья и коллеги, советую!

Задача о стабильной очереди задач

И это не тавтология... Проверьте свое знание синтаксиса, критическое мышление и умение вчитываться в ТЗ.

Условие

Идут обычные рабочие будни. Вы — ведущий DevOps-инженер в крупном маркетплейсе. В компании вовсю идет распродажа, и система распределенных вычислений на базе Celery работает на пределе возможностей, обрабатывая терабайты аналитики. В самом начале смены дежурный инженер замечает в системе ровно 100 активных задач. Согласно внутренней архитектуре, эти задачи зациклены: каждая задача после своего успешного завершения автоматически генерирует и ставит в очередь ровно одну новую задачу.

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

Задача

Объясните паникующему инженеру, почему его логика отказала. Как так получилось, что количество задач не растет? Напишите простую симуляцию этого процесса на Python, чтобы наглядно показать коллеге, как ведет себя такая очередь.

Убедитесь, что все решили правильно, — загляните в Академию Selectel.

Представлен открытый проект 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 тысячах часов речь;

• умеет слушать, говорить, прерывать ответы и вызывать инструменты в рамках одного диалога.

Представлен открытый проект repowise — оптимизатор кодовых баз, который экономит токены в кодинге и работает с Claude Code, Cursor, Copilot:

• не читает каждый файл, а сразу индексирует весь репозиторий;

• создаёт документацию для каждого файла;

• строит графы зависимости и анализирует историю Git с слабыми местами;

• неиспользуемый код и устаревшие зависимости чистит сам;

• результат: минимальная задокументированная экономия — 36%.

SmileLadder. Как трилогия про "память и мозг" привела к циклу про управление вниманием. Пост №1 - от синтетической к реальной ЭЭГ

В прошлой статье я попробовал описать внимание как динамическое распределение весов в графе. Тогда нейронная активность, оцениваемая по ЭЭГ, были синтетическими: граф состоял из модельных узлов, а сигнал генерировался осцилляторами в модели Хиндмарша-Роуза.

Публикация получилась сложная и я этим постом попытаюсь перейти к разбору исследования вопроса управления вниманием. Первое, что я попробую - это возьму реальную ЭЭГ: Для проверки я использовал открытый датасет STEW — Simultaneous Task EEG Workload. В нём 48 участников: для каждого записаны состояние покоя и работа с многозадачным тестом SIMKAP.

На реальной EEG индекс ASI (по которому я выдвигал гипотезу, что он может быть оценкой уровня внимания) различает покой и высокую когнитивную нагрузку. Но есть важные ограничения, о которых скажу ниже.

Берём реальную EEG - там 14 EEG-каналов, частота дискретизации 128 Гц. Всего 96 записей.

Каналы сгруппированы по областям: префронтальной, фронтальной, фронтоцентральной, височной, теменной и затылочной. Полная таблица соответствий лежит в репозитории.

Вот так использую свою модель

EEG делится на окна по 4 секунды с шагом 2 секунды. Для каждого окна рассчитываются четыре компонента:

1. спектральная вовлечённость - отношение активности beta к theta и alpha;

2. alpha gating - изменение задней alpha-активности;

3. фазовая организация - согласованность theta-ритма между передними и задними каналами;

4. пространственная селективность - насколько неравномерно распределена вовлечённость по каналам.

На этих 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.

Все числа сохранены в summary.json, а расчёт можно повторить по исходному коду:

python "Model GAT/stew_asi_gat_experiment.py" \
  --dataset dataset \
  --output "Model GAT/results" \
  --bootstrap 5000

Практический цикл управления вниманием я теперь вижу так:

задачи и контекст → оценка ожидаемого фокуса → EEG-маркер фактической нагрузки → обратная связь → корректировка списка задач

Текущий репозиторий закрывает только один фрагмент этого цикла: показывает, что реальная EEG содержит воспроизводимый сигнал изменения нагрузки. Следующий шаг - не «читать мысли», а научиться замечать момент, когда нагрузка перестаёт быть продуктивной мобилизацией и превращается в распад селективности.

Код, данные расчёта и графики: GitHub-репозиторий - его я форкнул от задачи идентификации и дописал свою часть.

unreal‑assets‑to‑glb

Это небольшой pip пакет, позволяющий вам конвертировать ресурсы unreal engine времени редактирования (не сборки игры) в модели формата glb.

особенности:

• интерфейс cli с поддержкой команды help

• поддерживает предварительный просмотр уровней (umap)

• фильтрация ассетов для экспорта только определенных моделей

• кэширование текстур для ускорения экспорта в будущем (если несколько раз выполняете экспорт)

• извлечение текстур базового цвета / альбедо, а также других текстур путем сохранения в формате png

• базовая поддержка сеток без анимации или костей без автоматического масштабирования с коэффициентом 100 к 1

В видео я показываю, как модель отображается в другом игровом движке после импорта конвертированных uasset-файлов

главное преимущество: вообще не требуется устанавливать UE

исходный код: https://github.com/Prikalel/unreal-assets-to-glb. пакет pip: https://pypi.org/project/unreal-assets-to-glb/

сгенерированные файлы могут быть легко импортированы в другие движки, такие как godot / unity и т.д.

в настоящее время поддерживаются 2 версии UE engine: 5.5 и 4.27.2

вы также можете заметить, что некоторые материалы в тестовой сцене частично затемнены - это связано с тем, что пакет не позволяет вам правильно экспортировать все настройки материалов / все настройки шейдеров (ограничения перечислены на странице github, это освещение, положение камеры и другие параметры, но базовое извлечение 3d-сетки работает идеально).

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

Лицензия GPL-3.0

MCP 2026-07-28: что действительно изменилось

Главное изменение — MCP стал stateless на уровне протокола. Убрали обязательные initialize, initialized и Mcp-Session-Id. Версия протокола и возможности клиента теперь передаются в каждом запросе, а сведения о сервере можно получить через server/discover. Любой запрос может обработать любой экземпляр сервера — без sticky sessions и общего хранилища сессий. Состояние приложения никто не запрещает: просто передавай явные идентификаторы вроде browser_id в аргументах инструментов.

Что ещё важно:

1. Долгие операции получили нормальный жизненный цикл. Tasks позволяют вернуть taskId, а затем проверять состояние через tasks/get, передавать дополнительные данные через tasks/update и отменять работу через tasks/cancel. Но Tasks не появились с нуля — раньше это была экспериментальная часть ядра, теперь её переработали и вынесли в официальное расширение.

2. Протокол стал удобнее для эксплуатации. Заголовки Mcp-Method и Mcp-Name позволяют маршрутизировать запросы, не разбирая JSON. Появились стандартные подсказки для кеширования — ttlMs и cacheScope, а также единые поля для передачи OpenTelemetry Trace Context.

3. Переработано общение сервера с клиентом. Вместо произвольных server-to-client запросов сервер теперь может вернуть input_required, после чего клиент повторяет исходный запрос с ответом пользователя. Подписки на изменения вынесены в subscriptions/listen.

4. Extensions стали полноценной частью экосистемы. Новые возможности теперь можно развивать отдельно от ядра. Первые заметные расширения — Tasks и MCP Apps. Последнее позволяет серверу отдавать интерактивный HTML-интерфейс, который клиент показывает в изолированном iframe.

5. Есть важные ломающие изменения. Все результаты теперь содержат resultType. Roots, Sampling, Logging и старый HTTP+SSE объявлены устаревшими. Схемы инструментов получили полноценную поддержку JSON Schema 2020-12. Если ты пишешь MCP-клиент или SDK, этот пункт может оказаться важнее MCP Apps.

6. Авторизацию подтянули ближе к реальному OAuth/OIDC. Добавили проверку iss, привязку учётных данных к конкретному issuer и уточнили регистрацию клиентов и работу с refresh-токенами.

В сухом остатке: remote MCP перестал требовать обязательную протокольную сессию и стал гораздо больше похож на нормальный stateless JSON-RPC поверх HTTP. Для продакшена это означает более простое горизонтальное масштабирование, маршрутизацию и кеширование. Остальные изменения полезны, но в основном касаются новых возможностей и миграции клиентов.

• спецификация MCP 2026-07-28

• ключевые изменения в деталях

tg

«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. Менеджеры пакетов и корпоративные прокси смогут пропускать пакеты с защищенным префиксом, только если издатель имеет на него право. Это точечная защита от одного семейства атак на имена; остальные сценарии неймсквоттинга мы разбирали в статье «Атаки на цепочку поставки ПО: виды угроз и как с ними бороться».

Подписывайтесь на CodeScoring в Telegram, VK, YouTube и Макс.

Сначала хотел написать комментарий к этой статье, но потом подумал, что пост лучше.

Наверно, просто каждый язык предназначен для решения своего круга задач. Когда-то фортран был языком для вычислений. Паскаль - для обучения. Си - для системных разработок. А вот Бейсик (я про компилируемые варианты) был универсален. :) Оттого, наверно, я его и выбрал в начале 90-х. Хотя с тех пор от него ничего не осталось, даже в плане синтаксиса, не говоря про огромные возможности...

А вот вопрос: какой язык может быть выбран в качестве "бытового"? Это не шутка. Лично я регулярно сталкиваюсь с необходимостью написать "одноразовую" программу, маленькую и не сложную. Для этого нужен простой язык и легкий транслятор.
Раньше я использовал VB3, но он на новых системах не работает. Потом "открыл для себя" SmallBasic и даже написал по нему некое пособие. Язык хороший, реально! Но есть один огромный минус, в силу чего он не годился для искомой роли: не работает с двоичными файлами.
Свой собственный язык ("Ellochka") я так и не удосужился до сих пор перевести под Виндовс (остался интерпретатор для ДОС).
Питон, увы, тоже не подходит: язык не очень прост, а главное - среда огромная, с флешки запускать несерьезно (а надо).

Так вот и вопрос: есть сейчас язык, подходящий для описанной задачи? Простой, легкий (в мегабайтах), без лишних наворотов, но "все что нужно есть"? Может, кто подскажет?

Ваш проект живёт дольше трёх месяцев? Код начинает сопротивляться изменениям: одна фича тянет правки в пяти файлах, тесты падают без внятного объяснения. Знакомо?

На бесплатном вебинаре «Антипаттерны в Python: как не превратить код в спагетти» разберём, где именно возникают эти точки напряжения, и что с ними делать.

📆 Когда: 30 июля, 16:00–17:00 (Мск)

👨‍🎓 Спикер: Читалов Дмитрий, специалист в области Python разработки

В программе:

✔️ Глобальные переменные

✔️ God Object

✔️ Spaghetti Code

✔️ Наследование ради наследования

✔️ Primitive Obsession

✔️ except: pass

✔️ Копипаста

✔️ Магические числа

✔️ Вложенные циклы O(n²)

✔️ Over-engineering

По каждому пункту — плохой код, разбор проблемы и готовый рефакторинг.

✍️ Регистрация

Задача о вирусе и 1 000 серверах

Представим, что в вычислительном кластере из 1 000 серверов одна машина заражена неизвестным вирусом. Он не нагружает процессор, не генерирует подозрительный сетевой трафик и не оставляет следов в системных журналах. Только раз в сутки вирус незаметно повреждает один файл резервной копии.

Для поиска зараженного узла начинающий сисадмин Олег написал анализатор логов. Скрипт проверяет любое количество серверов одновременно, объединяя их журналы в единый пул. Результат проверки может быть только двух видов:

• Status: 500 — если среди проверяемых серверов есть зараженный;

• Status: 200 — если зараженного сервера в группе нет.

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

Задача

Помогите Олегу определить — предложите решение, которое позволит определить один зараженный сервер из 1 000 возможных за 10 запусков анализатора. Напишите код на Python, который по результатам проверок сможет определить номер зараженного узла.

Посмотреть решение

Привет!

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

Поделитесь в комментариях)

Upd. Спасибо за комментарий, важная оговорка: проект работает локально на вашем компе, без утечек в инет)

Представлен открытый проект ODS (Osmantic Deployment System). Это проект, который превращает ПК в приватный ИИ‑сервер. Решение само определяет характеристики ПК, подберёт под них подходящую модель, скачает её и запустит локальный инференс:

• все локально и приватно: можно работать с документами, кодом и другими важными данными;

• через одну панель можно подключить голосовых помощников, агентов вроде Hermes, RAG, поиск, генерацию изображений и десятки других инструментов;

• без облачного сервиса. Без подписки.

Агент Ануфрий получил красивый вывод в терминал (отключаемый через конфиг).

Как всегда, ничего сложного, используются две библиотечки Rich + Prompt Toolkit. Вся эта красота хранится в отдельном модуле console, легко сможете разобраться, переделать, или подчерпнуть что-то для своих проектов. Кода там совсем немного.

Репозиторий: AgentAnufry

Есть идея в отдельной ветке Ануфрия запилить “кибербезопасника”, вырезав все лишнее и напихав скилов под инструменты Kali Linux. Мне кажется, тут LLM может проявить себя с хорошей стороны, если грамотно предоставить инструментарий.

Возможно что-то похожее уже кто-то реализовывал? Если да, поделитесь информацией об успехах.

P.S.: Ануфрий - это мой проект простого конструктора для создания собственных ассистентов на Python.

Выкатил релиз 1.3.1 моей простой товароучетной системы с поддержкой Честного Знака:

https://github.com/akdengi/sklad-cz

Что нового:

• Выбор товарной группы для работы в настройках (одиночный выбор из справочника). Реализованы 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 без всяких моков. Вызываешь функцию, проверяешь результат.

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

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

Кто тестирует ботов, как организуете?

С момента написания прошлой статьи про мою самописную товароучетную систему для работы с маркировкой «Честный Знак», я добавил новых фич и поправил существующие ошибки. Основные изменения следующие:

1. В Остатках в карточке товара появилась кнопка «Списать», позволяя сделать быстрое списание с нулевой ценой и выбором причины: утеря, собственные нужды, производственные цели, безвозмездная передача, отзыв с рынка. Данные нужно подавать также вручную, но для учета полезно.

2. Добавлен вид документа в продаже: поле «Вид док-та» в шапке заказа (Прочее, УПД, Товарная накладная, Акт приёма-передачи, Кассовый чек).

3. Появилась кнопка «Скачать КМ в CSV» в корзине Продаж для скачивания КМ в формате «для ввода/вывода из оборота» для вставке в ЭДО при передаче УПД.

4. Дропдаун «Статус» теперь показывает статус ЧЗ для проданных товаров.

5. Появилась возможность выделить и произвести массовую проверку статуса ЧЗ для выделенных товаров (чекбоксы + кнопка) на вкладках Остатки, Продано, Вывод из оборота.

6. Появилась колонка «Статус в ЧЗ» в таблицах Остатки и Вывод из оборота

7. Сделано автоподтверждение отчёта о выбытии при статусе ЧЗ равном «Выбыл» (RETIRED/WITHDRAWN/WRITTEN_OFF)

8. Сделано сохранение активной вкладки при перезагрузке страницы

9. Введена новая логика быстрой продажи: в шапку заказа: номер заказа, склад списания, дата продажи, добавление нескольких товаров по КМ/артикулу/EAN-13 с ценой за позицию в корзину с одинаковым номером заказа, КМ для Маркетплейсов отображается в корзине и копируется кликом, сделан Live-поиск при вводе кода с полной информацией о товаре.

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

Сразу напишу про API: авторизация по ЭЦП и получение общего статуса по КМ все еще ведется по 3 версии API Честного Знака, как и например работа с МОД, а что-то уже работает только по 4 версии API (например ввод-вывод из оборота).

Must-read для Python-разработчика: 5 статей от практика с сотнями интервью за плечами 

Делимся подборкой статей от Евгения Бартенева, эксперта курсов Практикума и разработчика с 20-летним опытом. А ещё он активно занимается созданием образовательного контента: является автором и техлидом курса «Python-разработчик», пишет статьи и проводит бесплатные мок-интервью для всех желающих в рамках проекта Boreesych.

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

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

Строки в Python: всё не так просто, как кажется. Начинающим разработчикам строки обычно кажутся едва ли не самым простым, что есть в языке программирования, но для Python это не совсем так. Евгений разбирает, какие бывают строки, чем они отличаются друг от друга, какие возможности дают и какие подводные камни могут встретиться в работе с ними. Здесь и о базовом использовании, и о важных деталях, которые стоит помнить каждому разработчику. 

От джуна к эксперту: как карта навыков и план развития помогают профессиональному росту Python-разработчика. Евгений размышляет, почему «стать мидлом, потом синьором» — плохая цель, которая не помогает расти. Затем рассказывает, что такое план профессионального развития, зачем он нужен и как его использовать на собеседованиях, в обучении и в реальной работе. А также делится примером карты навыков и шаблоном плана.

Книжная полка разработчика в эпоху интернета и искусственного интеллекта. Евгений объясняет, почему книги остаются незаменимым инструментом для изучения программирования даже в эпоху нейросетей, и делится личной подборкой — как для начинающих разработчиков, так и для тех, кто пишет код не первый день.

Если хотите освоить профессию Python-разработчика с нуля, сделать это можно на курсе «Python-разработчик» в Практикуме. Первые 30 уроков доступны бесплатно: вы попробуете себя в роли разработчика, познакомитесь с образовательной платформой и поймёте, подходит ли вам курс.

Сегодня произошла интересная штука: я встретил вживую новый вид сотрудника - "Оператор ЛЛМ", это как "Оператор ЭВМ", он "жмакает" кнопки, но не понимает зачем.

Суть: собесил сегодня чувака на инженерную позицию. Туда-сюда, вроде все складно, тимлиду вроде нравится. Потом дали мне слово, как софтверному инженеру, и я задал ровно два вопроса, после которых все стало понятно.

1 - чувак говорил, что у него есть хоум лаба, но не смог рассказать из чего она состоит (контейнеры/виртуалки/гипервизор).

2 - чувак показал свой пет-проект, но не смог рассказать как он работает под капотом.

Почему? - потому что он "кнопкодав", "оператор ЛЛМ" - называйте как хотите.

Это очень опасная тенденция, все больше людей называют себя "архитекторами" приложений, не понимая основ технологий которые их ЛЛМ пытается применять.

Фронтенд для души, бэкенд для людей!

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

Фронтенд весь такой разносторонний, креативный, местами легкий, местами настолько сложный что ломаешь голову. Напрашивается клеймо "для любителей".

Бэкенд наоборот поддерживает порядок и структурность. Меньше экспериментов и больше проверенных решений, самое то для "сделал работу - пошел спокойно домой".

Всем привет!

Сегодня поделюсь своим проектом, где использовал возможности открытых моделей LLM для создания автоматизированного конвейера по переводу англоязычных pdf-файлов в русскоязычные pdf. Как человек, интересующийся именно технологиями в области ИИ мне особенно было интересно максимальное приближенное к оригиналу сохранение содержимого переведенного материала, включая схемы, математические формулы, блоки кода (python) и bash-команд, рисунков (само собой), сохранение сносок, ссылок и пр. метаданных. Целью проекта было применение всевозможных доступных стеков и программ, использующих LLM в конкретной практической задаче. И как оказалось, на первый взгляд, простая задача перевода, с которой современная LLM, созданная и обученная на архитектуре трансформеров справляется на сегодняшний день блестяще, для pdf-формата оказалась не совсем простой (но и не скажу, что особо сложной).

О выборе программного стека технологий. Здесь во многом все определило глубина моих познаний и практических умений работать с LLM-моделями и тем оборудованием (потребительским, конечно), которое имеется дома. Поэтому, исходя из пары-тройки (пары) вычислительных узлов (ноутбуков) в домашней локалке мой выбор определил следующие программные и аппаратные компоненты.

Программные компоненты. Прежде всего это среда выполнения wsl. Просто работает в windows, удобна мне как новичку. В wsl установка обычной env стандартным python. И далее уже конкретные ПО для выполнения задачи перевода pdf на русский. Тут пришлось почитать в сети что есть свободное (исходя из цели использования только открытого ПО и LLM, чтобы оценить уровень их развития). Были опробованы такие программы как Docling, Marker-pdf и еще какую-то). В итоге, для извлечения из pdf в markdown формат я использовал Marker-pdf. У него имеется целый набор специализированных ocr-моделей для парсинга содержимого pdf. Marker в режиме конвейера осуществляет извлечение в указанную папку все содержимое исходного pdf в виде отдельных jpg-файлов, файла метаданных и итогового англоязычного .md файла. Для обратного процесса конвертации переведенного на русский язык ru.md я использовал WeasyPrint и Pandoc. Мой выбор - Pandoc. Сложнее, но поддержка xeLatex и куча настроек через опции командной строки и переменных окружения wsl. Pandoc - единственное ПО в моем конвейере, которое не использует LLM. И собственно, середина - перевод. Готовый скрипт на python. Перевод разбитых на части (chanks) в endpoint LLM - requests.post. Фишкой является url, который через специальный балансировщик, управляющий вычислительными узлами в локалке отправляется в requests.post. Получается параллельный перевод на нескольких узлах с  развернутыми OpenAI-совместимыми LLM. Количество узлов - сколько найдется в домашней ИИ лаборатории))). До и после отправки на перевод в LLM - чистка регулярками от различных костылей и защиты от перевода не нужных элементов (чистка колонтитулов, пагинация, сглаживание двойных переносов строк, изоляция спец. блоков от LLM блоков кода, мат. формул, кода внутри строк, приведение кода к pep8), подготовка переведенного _ru.md к сборке pdf-файла в Pandoc. В итоге - pipeline в 3 шага: Marker-pdf, Скрипт-переводчик на python, Pandoc.

Все вместе также можно запустить скриптом bash-сценария:

Использование: ./pipeline.sh <path_to_input_pdf> <output_path> [page_range]

Пример1: перевод всего Pdf-файла

./pipeline.sh /mnt/project/raw_data/embeddings.pdf /mnt/project/rendered/embeddings

Пример1: перевод первых 21 страниц Pdf-файла

./pipeline.sh /mnt/project/raw_data/embeddings.pdf /mnt/project/rendered/embeddings 0-20

Репозиторий на github DemonODG/pdf-translator: English-to-Russian PDF Translation Pipeline

Это мой первый пост на тему применения современных LLM моделей в различных практических задачах. Если это вызовет интерес в более подробном описании данного pipeline - напишу статью поподробнее.

Всем добра!

Как управлять окружениями — venv / pip vs pipenv vs poetry?

Привет, Хабр! Продолжаем нашу рубрику с быстрыми ответами на некоторые часто встречающиеся вопросы. Сегодня разберем такую проблему: проекты постоянно ломаются из-за конфликтов зависимостей. Что выбрать для новых проектов и как сделать так, чтобы код работал одинаково, в том числе в CI?

Обычно начало всех проблем — смешение глобальных и локальных пакетов или отсутствие фиксированных версий библиотек. Главный совет: у каждого проекта должно быть собственное окружение с явно указанными зависимостями и сохраненным lock‑файлом в репозитории.

Если говорить о базе, то это связка venv и pip. Плюс она встроена в сам Python. Вы вручную создаете окружение, устанавливаете нужные пакеты и фиксируете их в requirements.txt. 

Но подход со временем может стать неудобным — особенно когда в проекте десятки зависимостей и несколько разработчиков. Поэтому, на смену ручным методам пришел Poetry. 

Сейчас это, пожалуй, наиболее сбалансированное решение: он создает и управляет окружениями, отслеживает версии, собирает wheel‑пакеты и умеет публиковать их в PyPI. Lock‑файл (poetry.lock) обеспечивает воспроизводимость сборок, а сам формат pyproject.toml — это стандарт. В итоге вы получаете чистое окружение, детерминированные зависимости и понятное поведение CI.

Вот пример рабочего цикла:

python -m venv .venv
source .venv/bin/activate
pip install -U pip
pip install poetry
poetry install
poetry run pytest

В CI чаще используют схему с экспортом зависимостей:

poetry export -f requirements.txt --without-hashes -o reqs.txt
pip install -r reqs.txt
pytest

Отдельно стоит упомянуть uv — относительно новый инструмент, созданный командой Astral (авторы Ruff). Он написан на Rust и совместим с Python. По сути, это те же функции pip, venv и частично poetry, но быстрее. От Poetry он отличается отсутствием публикации пакетов, но при этом умеет сам устанавливать и менять версии Python через .python-version. 

UV работает с pyproject.toml и имеет собственный uv.lock. Может использоваться вместе с Poetry, но лучше создавать единый uv.lock для строгой воспроизводимости. Для CI это удобно, вы пишите:

pip install uv

Далее есть два варианта:

• uv venv — создает виртуальное окружение. Это аналог python3.13 -m venv .venv, но работает быстрее и с автоустановкой версии Python.

• uv init — помимо .venv, добавляет шаблон проекта с pyproject.toml для зависимостей, Git-репозиторий и базовые файлы. Идеально для нового проекта.

И окружение в CI полностью совпадает с локальным, а билд воспроизводится без сюрпризов. Но чаще всего комбинируют два решения: Poetry для разработки и uv — для быстрых сборок и деплоймента.

Если хотите освоить инструменты Python, то в Академии Selectel у нас есть отдельная подборка статей. Там мы рассказываем, как настраивать инструменты, работать с базами данных, создавать программы с интерфейсом и использовать Python для парсинга.

Как настроить TLS в клиенте Python при HTTPS-запросах?

Бывает так, что после обновления OpenSSL часть HTTPS-вызовов к внешним сервисам падает с ошибкой ssl.SSLError. Сейчас разберемся, как настроить Python, чтобы handshake проходил успешно и соединение оставалось безопасным.

После апдейтов OpenSSL часто отключают старые протоколы и слабые шифры — старые серверы не проходят handshake. Решение на клиенте — явно создать ssl.SSLContext, задать минимальную версию TLS и, при необходимости, набор шифров, а затем передать этот контекст в HTTP-клиент (например, httpx).

import ssl
import httpx

ctx = ssl.create_default_context(purpose=ssl.Purpose.SERVER_AUTH)
ctx.minimum_version = ssl.TLSVersion.TLSv1_2
ctx.set_ciphers('ECDHE+AESGCM:!ECDSA:!aNULL:!eNULL')

with httpx.Client(verify=ctx, timeout=10.0) as client:
    r = client.get('https://api.example.com')
    r.raise_for_status()
    print(r.status_code)

В коде мы указываем TLSv1_2 как минимальный порог. Это удобно: если сервер уже поддерживает TLS 1.3, все само заработает на самой новой версии. Но если какой-то внешний сервис еще не успел обновиться, соединение не разорвется, и все продолжит работать на стабильном 1.2. Так мы получаем универсальный код, который не сломается при работе со старыми API.

Для отладки TLS handshake применяйте openssl s_client -connect host:443 -tls1_2 чтобы увидеть, какие шифры поддерживает сервер. Временное ослабление minimum_version даст совместимость, но хуже для безопасности — лучше апгрейдить серверную часть. Сертификаты и ключи храните вне кода (секреты/volumes), не логируйте их, и при работе в контейнерах используйте безопасные механизмы передачи секретов.

Если хотите освоить инструменты Python, то в Академии Selectel у нас есть отдельная подборка статей. Там мы рассказываем, как настраивать инструменты, работать с базами данных, создавать программы с интерфейсом и использовать Python для парсинга.

Понял asyncio только когда бот начал зависать под нагрузкой

Писал на Python и честно говоря asyncio воспринимал как магию. Работает и ладно.

Пока однажды бот не завис.

Пользователей было немного, штук двадцать одновременно, но один запустил команду которая делала тяжёлый запрос к внешнему API. Пока запрос выполнялся, бот молчал. Остальные подвисли в ожидании.

Начал разбираться. Оказалось я вызывал синхронную функцию прямо внутри async хендлера. requests.get внутри async def. Это блокирует весь event loop. Все корутины ждут пока эта одна функция не завершится.

Решение простое: либо заменить requests на aiohttp, либо обернуть синхронный вызов через asyncio.to_thread. Второй вариант проще когда менять библиотеку лень:

python

result = await asyncio.to_thread(requests.get, url)

После замены бот перестал зависать. Все одновременные запросы к внешнему API обрабатываются параллельно без проблем, но теперь когда вижу синхронный вызов внутри async функции ощущение что что-то не так.

Кто сталкивался с похожим, как отлаживали?

Что делать, если Python-сервер падает из-за утечки памяти?

Привет, Хабр! Это наша экспериментальная рубрика, в которой мы даем новичкам быстрые ответы на четкие вопросы. Писать статью будет излишним, а некоторую пользу до аудитории донести, возможно, получится.

Итак, допустим, агент спустя время начинает расти по памяти и в итоге все падает. Где копать и как временно ограничить ущерб, пока ищете утечку?

Первое, что нужно сделать — измерить и локализовать. tracemalloc показывает, какие строки выделяют больше всего памяти, gc — количество объектов. 

Часто проблема в неограниченных кэшах, списках или в C-расширениях. Сначала стоит включить tracemalloc, дать процессу поработать и снять снапшот:

import tracemalloc
tracemalloc.start()
# после нагрузки
snapshot = tracemalloc.take_snapshot()
top = snapshot.statistics('lineno')[:10]
for stat in top:
    print(stat)

Параллельно делайте gc.collect() и логируйте число объектов len(gc.get_objects()), чтобы увидеть рост. На время расследования применяйте эксплуатационные меры: для WSGI-сервисов используйте Gunicorn с --max-requests и --max-requests-jitter, чтобы процессы периодически перезапускались и не накапливали мусор. А в контейнерах ставьте cgroup-пределы (--memory) и настраивайте restart-политику, чтобы платформа автоматически перезапускала упавшие поды.

Пример запуска Gunicorn:

gunicorn myapp:app --workers 4 --max-requests 1000 --max-requests-jitter 50

Если утечка в C-расширении или сторонней библиотеке, то временно автоматический перезапуск и мониторинг позволяют сохранить сервис работоспособным, пока вы находите корень проблемы и исправляете код.

Если хотите освоить инструменты Python, то в Академии Selectel у нас есть отдельная подборка статей. Там мы рассказываем, как настраивать инструменты, работать с базами данных, создавать программы с интерфейсом и использовать Python для парсинга.

Разработчик Тарун Гупта представил открытый проект autopilot-jobhunt. Это — ИИ-инструмент, который автоматически ищет вакансии в интернете, сравнивает их с профилем пользователя и присылает наиболее подходящие варианты в Telegram.

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

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

Сервис задуман как бесплатный. Для поиска вакансий он использует веб-агента TinyFish, а для анализа — бесплатные модели через OpenRouter. По умолчанию система переключается между Llama, Nvidia Nemotron, Google Gemma 4 и Alibaba Qwen3, если у одной из моделей заканчивается лимит. Вместо OpenRouter можно подключить Claude Code и API Anthropic, но в этом случае понадобится подходящая подписка или оплаченные токены.

Разработчик отдельно описал меры защиты данных. Файл с настройками и ссылкой на локальное резюме исключён из Git, поэтому его нельзя случайно опубликовать вместе с кодом проекта. Однако содержимое резюме все равно передаётся моделям, подключённым через OpenRouter. Тем, кто не хочет отправлять данные через этот сервис, автор предлагает использовать Claude Code.

По умолчанию autopilot‑jobhuntt настроен на поиск вакансий для разработчиков, но список профессий, компаний и требований можно изменить — нужно отредактировать файл конфигурации проекта.

Два часа потерял из-за того, что не написал один хендлер

Делал платежи в Telegram-боте. Нативные, через sendInvoice и ЮKassa.

Всё настроил: токен от BotFather получил, инвойс отправляется, кнопка оплаты появляется. Пользователь нажимает - и платёж падает с ошибкой. Молча. Без подробностей.

Payment failed

И всё. Telegram не говорит что именно не так.

Полез гуглить. Первая мысль - provider_token неверный. Проверил три раза, скопировал заново. Нет, токен правильный.

Потом решил что проблема в суммах - они передаются в копейках, не в рублях. 500 рублей = 50000. Перепроверил, у меня было правильно.

Потом подумал на webhook - может HTTPS не настроен как надо. Потратил минут сорок на проверку сертификата, перенастройку ngrok. Всё работает, но платежи всё равно падают.

Уже хотел идти спать, случайно наткнулся на строчку в документации:

Your bot must reply to this query in 10 seconds

Это про pre_checkout_query. Когда пользователь нажимает «Оплатить» - Telegram сначала отправляет боту запрос на подтверждение. Бот должен ответить в течение 10 секунд. Если не ответил - платёж автоматически отклоняется.

У меня хендлера для этого не было вообще. Бот просто молчал.

Добавил три строки:

python

@dp.pre_checkout_query()
async def pre_checkout(query: types.PreCheckoutQuery):
    await query.answer(ok=True)

Платёж прошёл с первого раза.

Два часа отладки из-за трёх строк кода которые я не написал.

Если кто-то тоже делает платежи в Telegram-боте и получает молчаливый отказ - проверьте pre_checkout_query первым делом, до всего остального.

В дополнение к посту по albu-mcp

В доке Albumentations появился отдельный раздел про мой AlbumentationsX MCP - https://albumentations.ai/docs/integrations/mcp/

Теперь есть официальный integration guide, где показано, как ты можешь подключить MCP-сервер к AI-assistant’у и использовать его для нормального HITL workflow вокруг CV-аугментаций: подобрать pipeline, провалидировать его, отрендерить локальные previews, сравнить baseline и candidate, дать feedback вроде too_noisy:high и экспортировать финальный pipeline.

Приятно видеть, что проект стал частью экосистемной документации Albumentations. 🙂

AlbumentationsX MCP это конечно же не замена Python API, а assistant-facing review layer для тех случаев, когда ты хочешь быстрее и безопаснее работать с augmentation pipelines.

Представлен открытый проект Ghostprovider — терминальный инструмент для быстрого запуска GitHub‑проектов у себя на localhost.

Принцип работы проекта: предоставляется ссылка на репозиторий, а инструмент сам анализирует проект: ищет Dockerfile, docker‑compose, package.json, requirements.txt, Go/Rust/Python/Node‑признаки, определяет тип приложения и пытается развернуть его в Docker. После запуска показывает локальный URL, контейнеры, логи и дает управлять сервисами прямо из TUI: старт, стоп, рестарт, удаление. По сути это автоматизированная оболочка над git clone, docker build, docker run и docker compose up, только с автоанализом проекта и удобным интерфейсом в терминале.

Важно: инструмент реально запускает код из чужих репозиториев, поэтому случайные проекты лучше гонять в VM/песочнице и внимательно смотреть Dockerfile/docker‑compose перед запуском. Сам Ghostprovider выглядит прозрачным, но риск всегда в том, что именно вы через него запускаете.

Как я перестал бояться опенсорсить свои поделки

для тех, кто пишет код в VS Code, не помнит наизусть флаги git filter-repo и считает, что IDE — нормально. Если ты из лагеря «настоящие программисты сидят в vim и пишут всё в Makefile» — просто пролистай

git-private2public как .gitignore, но чтобы сделать зеркало приватного репо одной git push.

Что это

CLI-тулза. Держит два репо в синхроне: приватный (ваш рабочий бардак) и публичный (чистая версия). При пуше автоматически вычищает секреты и обновляет публичный mirror.

Конфиг — папка .gitpublic/, как .gitignore. По одной маске на строку, без YAML.

.gitpublic/
  config      — source / target / push
  ignore      — что НЕ публиковать
  replace     — что заменить (==> без кавычек)
  scan        — что не должно попасть, иначе падаем
  allow       — но конкретно эти можно пропускать в пуш,  

Файла нет → настройки нет. Просто.

Автопуш через git hook

pip install git-private2public
cd ~/my-private-repo
git-private2public init

init создаёт пять пустых файлов с закомментированными примерами. Дальше правите то, что нужно:

Easy — только ignore:

.env
secrets/
*.key
credentials.json

Medium — добавляете replace:

10.0.0.5          ==> 203.0.113.5
real-token-here   ==> ***

Hard — добавляете scan (защита от факапов):

# scan
regex:github_pat_[A-Za-z0-9_]{30,}
regex:192\.168\.

Если в коде найдётся паттерн из scan — publish падает, ничего не пушится.

git-private2public scan      # dry-run
git-private2public publish   # реальный пуш

Автопуш через git hook

Это та фича, ради которой я и начал. Никакого CI, никаких GitHub Actions.

git-private2public hook enable

Ставит pre-push хук. Теперь обычный git push — отправляет в приватный репо и автоматически чистит-пушит в публичный mirror.

git-private2public hook status    # проверить
git-private2public hook disable   # выключить

Работает офлайн, на любом хостинге.

Почему не git filter-repo или BFG

Я ими пользовался. Они мощнее, но мне нужны были четыре вещи в одной тулзе:

Не нашёл — написал.

Установка (ещё раз, коротко)

pip install git-private2public

Если pip не вариант — single-file: скачал git_private2public.py, chmod +x, готово (нужны git-filter-repo и pyyaml).

Ссылки

• Репо: https://github.com/megamen32/git-private2public

• MIT, форкайте, шлите PR

• README на русском: README.ru.md

TL;DR

pip install git-private2public → init → редактируешь .gitpublic/ignore → publish. Если хочешь автопуш — hook enable.git push. Всё.

Представлен открытый сервис Aliens Eye, который ищет всевозможную информацию в соцсетях, на сайтах и других ресурсах, предоставляя полный отчёт:

• 840 различных OSINT-инструментов для анализа сайтов, соцсетей, других ресурсов, хостингов, доменов и даже физических устройства;

• все сервисы работают по одному клику. При этом интерфейс интуитивно понятен;

• отчёты предоставляет в JSON, CSV, HTML и Markdown форматах;

• без ограничений, без дополнительных установок.

Представлен открытый проект ИИ‑студии для видеомонтажа OpenMontage — комбайн из ИИ‑агентов для полноценного выпуска видеороликов. Проект помогает превратить доступ к Claude Code, Cursor, Copilot, Windsurf или Codex в киностудию:

• агенты берут на себя всё — от исследований и сценария до генерации видео, монтажа и озвучивания;

• 12 пайплайнов под любой тип контента — трейлеры, анимации, реклама, туториалы и так далее;

• 500 скиллов — генерация видео, аудио, музыки и картинок;

• умеет работает с лучшими генераторами — Kling, Runway, FLUX, ElevenLabs и Suno.

5 граблей, на которых умирают торговые боты

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

Стратегия - никогда не была сложной частью. Сложной частью была инфраструктура.

«Это работало в бэктесте» ничего не значит, если в live крутится другой код

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

Ошибка, которая открывает позицию дважды

Бот, обновляющий позицию в момент, когда процесс умирает - OOM, деплой, скачок питания, просыпается с испорченным состоянием: наполовину открытая позиция, неправильный cost basis, выход, который так и не зарегистрировался. Восстановление руками - это место, где утекают деньги.

Ордер, который биржа молча отвергла

Тихий убийца live-торговли: биржа отвергает, отваливается по таймауту или наливает частично - и внутреннее состояние вашего бота больше не совпадает с реальностью. Фикс из учебника - рукописный try/catch с откатом вокруг каждого ордера - это ровно тот код, который ломается на том краевом случае, который вы не предусмотрели.

Десять стратегий, один счёт, экспозиция 100%

Проверки риска по каждой стратегии в отдельности упускают очевидную портфельную истину: десять стратегий, каждая «рискует 10%», - это один счёт, рискующий всем. Открыть сразу 10 позиций не хватит капитала

Получение внешних данных через Crontab

Cron с парсингом внешних данных работает в другом процессе по системным часам - бесполезно в бэктесте, который проигрывает месяц за секунды. Так же как неполные свечи в live, на момент backtest база данных содержит больше записей, так как момент в прошлом уже завершен

Я сделал AlbumentationsX MCP — MCP-сервер для работы с аугментациями в computer vision.

Идея простая: когда ты собираешь augmentation pipeline, не хочется бесконечно вручную перебирать transforms, гадать с параметрами и проверять глазами десятки вариантов. Хотелось, чтобы MCP-host мог помочь: найти подходящие transforms, собрать консервативный baseline, провалидировать pipeline, отрендерить локальные previews, сравнить результаты, собрать feedback вроде too_noisy:high и экспортировать принятый вариант.

Проект работает поверх AlbumentationsX и не пытается делать магию вместо тебя. Он помогает быстрее пройти цикл: recommend → validate → preview → compare → adjust → export.

Особенно полезно, если ты делаешь classification, detection, segmentation, OCR или просто хочешь быстрее проверять качество аугментаций на локальных примерах.

Запуск:

uvx --from albumentationsx-mcp albumentationsx-mcp

Репозиторий: albu-mcp