SELECT * FROM source_table WHERE timestamp > max_timestamp

При следующем запуске алгоритм снова заберет новые данные. И так далее, бесконечный цикл. Колонка по которой определяются новые данные бывает не только типом timestamp, но и просто датой и числовым значением.
В виде наглядно показан процесс.

• Nemotron говорит с вами без пауз и умеет в эмоции;

• разрешает вам перебивать себя с задержкой всего 480 мс;

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

• поддерживает сложные сценарии использования;

• обучен на 550 тысячах часов речь;

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

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

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

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

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

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

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

Публикация получилась сложная и я этим постом попытаюсь перейти к разбору исследования вопроса управления вниманием. Первое, что я попробую - это возьму реальную ЭЭГ: Для проверки я использовал открытый датасет 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-репозиторий - его я форкнул от задачи идентификации и дописал свою часть.

Это небольшой 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 стал 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

Используя функцию numgen из библиотеки nftables, мы можем изменять количество переходов каждый раз при генерации пакета ICMPv6. Функция numgen возвращает либо случайные числа, либо монотонный счетчик. С помощью счётчика мы можем легко настроить каждый переход так, чтобы он возвращал разный IPv6-адрес при генерации ответного пакета.

Для этого потребовалось ещё две вещи. Во-первых, необходимо отключить ограничение скорости ядра (по умолчанию 1/с) для исходящего трафика ICMPv6 с помощью команды sysctl net.ipv6.icmp.ratelimit=0, иначе всё закончится очень быстро. Вторая проблема заключается в том, что mtr обычно показывает несколько адресов для каждого узла, поскольку это указывает на использование нескольких разных путей для пакета, и это обычно полезная информация.

После всего этого я использовал ffmpeg для передискретизации видео до 8 кадров в секунду (что соответствует интервалу в 125 мс между кадрами) и экспорта уменьшенных (до 30x11 пикселей) отдельных кадров в файлы PNG. Затем я написал скрипт на Python для чтения файлов изображений и преобразования их в набор правил nftables для генерации соответствующих ответов ICMPv6. В результате получается чуть более мегабайта правил nftables, но это определённо того стоит.

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 серверов одна машина заражена неизвестным вирусом. Он не нагружает процессор, не генерирует подозрительный сетевой трафик и не оставляет следов в системных журналах. Только раз в сутки вирус незаметно повреждает один файл резервной копии.

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

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

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

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

Задача

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

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

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

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

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

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

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

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

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

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

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

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

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

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 (например ввод-вывод из оборота).

Делимся подборкой статей от Евгения Бартенева, эксперта курсов Практикума и разработчика с 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 - напишу статью поподробнее.

Всем добра!

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

Бывает так, что после обновления 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 для парсинга.

Писал на 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 функции ощущение что что-то не так.

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

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

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

Первое, что нужно сделать — измерить и локализовать. 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 для парсинга.

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

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

Сервис задуман как бесплатный. Для поиска вакансий он использует веб-агента 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 первым делом, до всего остального.

В доке 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.

Принцип работы проекта: предоставляется ссылка на репозиторий, а инструмент сам анализирует проект: ищет 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. Всё.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Идея простая: когда ты собираешь 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

Заперли физика, химика и экономиста,на необитаемом острове с банкой консервов.  Физик предлагает разбить её камнем, химик — нагреть на костре. Экономист говорит: «Предположим, у нас есть открывашка».

• Path-aware exits
  
  Плохо: PnL считается по close, ни одна сделка не закрыта по SL
  Хорошо: OHLC-реплей внутри свечи, intra-candle SL/TP
  

• Look-ahead bias
  
  Плохо: Ручной параметр времени, индикатор на всём массиве
  Хорошо: Ambient-контекст, данные только до текущего тика
  

• Комиссии + слиппедж + leverage
  
  Плохо: PnL по миду, без комиссий, +0.3% это минусовая статегия ниже комиссии
  Хорошо: На момент холда считается стоимость обслуживания leverage, fees
  

• Размер выборки
  
  Плохо: <30 сделок, Sharpe Ratio в космосе, tail-driven
  Хорошо: N/A вместо фейка при недостатке данных, гейты ≥10 сигналов / ≥14 дней
  

• Crash-recovery
  
  Плохо: Нет атомарной записи, рестарт с нуля
  Хорошо: Atomic writes, graceful shutdown
  

• Адаптер биржи
  
  Плохо: Не отправлял реальный ордер
  Хорошо: Если покупателя/продавца не нашлось, не закрываем позицию и в бд

В подкасте Радио-Т 1018 был интересный момент, что у ИИ сейчас гораздо меньше опенсорсных репозиториев и датасетов на Swift, чем условно на Python или Go. И поэтому, как Claude Code, так и Codex хреново пишут нативные iOS приложения. А ведь API языка обновляется, имеющиеся данные в нейронках устаревают с каждым WWDC.

Я как бэкендер с этой темой не сталкиваюсь. Стало интересно, как в Apple вайбкодят разрабы и влияет ли это как-то на темпы разработки по сравнению с конкурентами. Apple Intelligence пока пытались запустить для обычных потребителей, или когда анонсировали переход на Gemini-бэкенд, это повлияло как-то на пайплайн разработчиков? Есть ли у их моделей какой-то секретный проприетарный датасет, чтобы повысить качество работы с их экосистемой?

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

Тут у меня котелок начал накидывать вопросы.

Apple ладно, а какое будущее у новых языков программирования? Будут ли авторы новых языков задаваться вопросом «как мой язык будут поддерживать нейросети?» Их популяризация будет целиком и полностью за счет опен-сорс коммьюнити теперь, пока остальные языки будут писать агенты? Сообщества сами генерят синтетические данные для языков программирования, чтобы локальные модели лучше умели в определенный скилл? Или может для языков будут сразу разрабатываться скиллы или MCP? Какую роль в адаптации к агентсткой разработке будут играть компилируемые языки со строгой типизацией по сравнению с нестрогими, скриптовыми языками? А поддержка нового языка агентами на сносном уровне, - это повод для флекса в презентации у компании?

В интересное время живем.

• Вытягивает структурированный и понятный JSON из PDF, изображений и других файлов.

• Обрабатывает десятки страниц за секунды. Нейронке можно скармливать даже огромные файлы.

• Сохраняет все поля оригинала.

Это полноценный бесплатный практический курс от базы до production-подхода.

Внутри разбираются:

- как работает HTTP, HTML и DOM

- requests, BeautifulSoup, lxml

- CSS-селекторы и XPath

- работа с API, JSON и авторизацией

- динамические сайты через Playwright и Selenium

- асинхронный парсинг на aiohttp и asyncio

- Scrapy как промышленный фреймворк

- обход антибот-защит

- хранение, валидация и экспорт данных

- ретраи, логирование и обработка ошибок

- тестирование парсеров

- архитектура production-парсера

- типовые ошибки и антипаттерны

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

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

https://github.com/justxor/Pythonparsing-/tree/main

#junior #python #парсинг