7 ошибок в автоматизации на Python, из-за которых скрипт ломается в проде
Автоматизация часто умирает не в логике, а на краях: файл не там, API отвечает пусто, задача запускается дважды. Если скрипт делает бизнес-операцию, он должен переживать сбои, а не только успешный сценарий.
— Нет идемпотентности: повторный запуск создает дубли, а не пропускает уже обработанное.
— Нет явных таймаутов и ретраев: зависший HTTP-запрос висит бесконечно, а ошибка сети валит весь поток.
— Смешаны ввод, обработка и вывод: код нельзя тестировать по частям и трудно переиспользовать.
— Логика завязана на пути, переменные окружения и ручной запуск из терминала.
Отдельно проверяйте конкуренцию: если два воркера читают одну очередь или один и тот же файл, нужен лок или атомарная запись. И не полагайтесь на «если упало — перезапущу руками»: после перезапуска скрипт должен понимать, что уже сделал, а что еще нет.
Хорошее правило простое: каждый шаг должен быть безопасен к повтору, а каждый внешний вызов — иметь таймаут, лог и понятную ошибку.
Автоматизация часто умирает не в логике, а на краях: файл не там, API отвечает пусто, задача запускается дважды. Если скрипт делает бизнес-операцию, он должен переживать сбои, а не только успешный сценарий.
— Нет идемпотентности: повторный запуск создает дубли, а не пропускает уже обработанное.
— Нет явных таймаутов и ретраев: зависший HTTP-запрос висит бесконечно, а ошибка сети валит весь поток.
— Смешаны ввод, обработка и вывод: код нельзя тестировать по частям и трудно переиспользовать.
— Логика завязана на пути, переменные окружения и ручной запуск из терминала.
Отдельно проверяйте конкуренцию: если два воркера читают одну очередь или один и тот же файл, нужен лок или атомарная запись. И не полагайтесь на «если упало — перезапущу руками»: после перезапуска скрипт должен понимать, что уже сделал, а что еще нет.
Хорошее правило простое: каждый шаг должен быть безопасен к повтору, а каждый внешний вызов — иметь таймаут, лог и понятную ошибку.
Pydantic ломается не в моделях, а в границах данных: 5 правил, которые спасают API
Если Pydantic у вас «иногда валится без причины», проблема обычно не в валидации, а в том, что входной контракт размыт. Модель должна быть не копией JSON, а фильтром: принимать лишнее только осознанно, а поля с бизнес-смыслом делать явными.
• Делайте отдельные схемы для input и output. Одна модель на всё почти всегда приводит к лишним optional-полям и странным дефолтам.
• Не прячьте бизнес-логику в валидаторах. Валидатор проверяет форму и типы, а не решает, можно ли создавать объект.
• Явно задавайте alias, если внешний API живёт на snake_case, а внутренний код — на другом соглашении.
• Для вложенных объектов лучше провалиться сразу, чем тащить None глубоко в сервисный слой.
Ещё одна частая ошибка — надеяться, что Pydantic «сам всё приведёт к нужному виду». Он приведёт, но иногда слишком щедро: строка станет числом, пустой список — валидным значением, а лишнее поле тихо пройдёт дальше. Для критичных границ лучше включать строгую валидацию и не полагаться на магию преобразований.
Если модель начинает разрастаться, это сигнал разнести её на DTO, response-схемы и внутренние типы. Так код проще тестировать, а ошибка становится локальной: не в десяти сервисах, а в одном месте входа.
Если Pydantic у вас «иногда валится без причины», проблема обычно не в валидации, а в том, что входной контракт размыт. Модель должна быть не копией JSON, а фильтром: принимать лишнее только осознанно, а поля с бизнес-смыслом делать явными.
• Делайте отдельные схемы для input и output. Одна модель на всё почти всегда приводит к лишним optional-полям и странным дефолтам.
• Не прячьте бизнес-логику в валидаторах. Валидатор проверяет форму и типы, а не решает, можно ли создавать объект.
• Явно задавайте alias, если внешний API живёт на snake_case, а внутренний код — на другом соглашении.
• Для вложенных объектов лучше провалиться сразу, чем тащить None глубоко в сервисный слой.
Ещё одна частая ошибка — надеяться, что Pydantic «сам всё приведёт к нужному виду». Он приведёт, но иногда слишком щедро: строка станет числом, пустой список — валидным значением, а лишнее поле тихо пройдёт дальше. Для критичных границ лучше включать строгую валидацию и не полагаться на магию преобразований.
Если модель начинает разрастаться, это сигнал разнести её на DTO, response-схемы и внутренние типы. Так код проще тестировать, а ошибка становится локальной: не в десяти сервисах, а в одном месте входа.
Starlette — это не «мини-FastAPI», а каркас, который удобно ломать и собирать под себя
Если нужен тонкий HTTP-слой для микросервиса, вебхуков или внутреннего API, Starlette часто выигрывает за счёт простоты: маршруты, middleware, фоновые задачи, WebSocket — без лишней магии. Он хорош там, где важнее контролировать поведение, чем тащить большой фреймворк ради пары эндпоинтов.
Что обычно делают неправильно:
• Пишут sync-хендлеры и потом удивляются блокировкам в проде
• Вешают тяжёлую логику прямо в endpoint вместо сервиса или очереди
• Игнорируют lifespan-события и теряют инициализацию клиентов, пулов, кешей
• Смешивают ручную работу с request/response и начинают плодить дублирование
Если проект растёт, Starlette удобно использовать как базу для тонкой архитектуры: отдельно слой транспорта, отдельно бизнес-логика, отдельно интеграции. Это особенно заметно в async-проектах, где один плохо написанный handler может тормозить весь ворклоад.
Ещё плюс: Starlette легко тестировать и легче читать в ревью, когда в коде нет лишнего «магического» слоя. Но это работает только если сразу договориться о границах: где валидируются данные, где ловятся ошибки, где живут зависимости.
Хорошее правило простое: если вам нужен контроль над HTTP и минимум абстракций, Starlette — не компромисс, а осознанный выбор.
Если нужен тонкий HTTP-слой для микросервиса, вебхуков или внутреннего API, Starlette часто выигрывает за счёт простоты: маршруты, middleware, фоновые задачи, WebSocket — без лишней магии. Он хорош там, где важнее контролировать поведение, чем тащить большой фреймворк ради пары эндпоинтов.
Что обычно делают неправильно:
• Пишут sync-хендлеры и потом удивляются блокировкам в проде
• Вешают тяжёлую логику прямо в endpoint вместо сервиса или очереди
• Игнорируют lifespan-события и теряют инициализацию клиентов, пулов, кешей
• Смешивают ручную работу с request/response и начинают плодить дублирование
Если проект растёт, Starlette удобно использовать как базу для тонкой архитектуры: отдельно слой транспорта, отдельно бизнес-логика, отдельно интеграции. Это особенно заметно в async-проектах, где один плохо написанный handler может тормозить весь ворклоад.
Ещё плюс: Starlette легко тестировать и легче читать в ревью, когда в коде нет лишнего «магического» слоя. Но это работает только если сразу договориться о границах: где валидируются данные, где ловятся ошибки, где живут зависимости.
Хорошее правило простое: если вам нужен контроль над HTTP и минимум абстракций, Starlette — не компромисс, а осознанный выбор.
This media is not supported in your browser
VIEW IN TELEGRAM
Chat GPT-5.6 будут выдавать лишь избранным
США ограничивают публичный доступ к новым ИИ-моделям: теперь его выдают только проверенным пользователям после обязательной 30-дневной процедуры верификации. Сэм Альтман называет это самым быстрым путём к публичному релизу. Эффективность меры вызывает сомнения — китайские разработчики традиционно копируют модели в течение суток после выхода.
➡️ Читайте на сайте: https://aff.top/blog/chat-gpt-5-6-budut-vydavat-lish-izbrannym
🧠 Ещё больше инсайтов → в канале AFF.top
США ограничивают публичный доступ к новым ИИ-моделям: теперь его выдают только проверенным пользователям после обязательной 30-дневной процедуры верификации. Сэм Альтман называет это самым быстрым путём к публичному релизу. Эффективность меры вызывает сомнения — китайские разработчики традиционно копируют модели в течение суток после выхода.
➡️ Читайте на сайте: https://aff.top/blog/chat-gpt-5-6-budut-vydavat-lish-izbrannym
🧠 Ещё больше инсайтов → в канале AFF.top
This media is not supported in your browser
VIEW IN TELEGRAM
Vk удалили из App store: что дальше?
Удаление VK из App Store заблокировало доступ для владельцев iPhone в России, но проблема решаема. Арбитражники теряют один канал, но не аудиторию — 20–30 млн пользователей iOS остались на месте. Вместо VK стоит переориентироваться на альтернативные источники: Telegram Ads с таргетингом на iOS, push-сети типа AdProfex, MTS Ads и Beeline Ads. VK может последовать примеру Max и запустить PWA-приложение для восстановления уведомлений. Главный вывод…
➡️ Читайте на сайте: https://aff.top/blog/vk-udalili-iz-app-store-chto-dalshe
🧠 Ещё больше инсайтов → в канале AFF.top
Удаление VK из App Store заблокировало доступ для владельцев iPhone в России, но проблема решаема. Арбитражники теряют один канал, но не аудиторию — 20–30 млн пользователей iOS остались на месте. Вместо VK стоит переориентироваться на альтернативные источники: Telegram Ads с таргетингом на iOS, push-сети типа AdProfex, MTS Ads и Beeline Ads. VK может последовать примеру Max и запустить PWA-приложение для восстановления уведомлений. Главный вывод…
➡️ Читайте на сайте: https://aff.top/blog/vk-udalili-iz-app-store-chto-dalshe
🧠 Ещё больше инсайтов → в канале AFF.top
Pydantic ломает меньше, если сразу договориться о правилах на входе
Если модель используется в API, скриптах и фоновых задачах, держите один подход к данным:
— вход валидируйте на границе;
— внутри системы работайте уже с типизированным объектом;
— ошибки отдавайте до того, как логика успеет разъехаться.
Самая частая ошибка — смешивать проверку, преобразование и бизнес-логику в одном месте. В итоге строка внезапно становится числом, пустой список проходит как валидный payload, а дефолты прячут баги. Лучше явно описать обязательные поля, ограничения и преобразования в модели, чем потом искать «магическое» поведение в обработчике.
Полезная привычка: отдельные модели для входа, ответа и внутреннего представления. Тогда payload от клиента, DTO для сервиса и объект для хранения не начинают жить одной жизнью. Ещё один плюс — проще тестировать: вы проверяете схему, а не весь endpoint целиком.
И не злоупотребляйте «умными» валидаторами там, где достаточно простых типов и ограничений. Чем меньше скрытой логики в модели, тем легче читать код, переиспользовать его в FastAPI и не ловить сюрпризы в парсерах и скриптах.
Если модель используется в API, скриптах и фоновых задачах, держите один подход к данным:
— вход валидируйте на границе;
— внутри системы работайте уже с типизированным объектом;
— ошибки отдавайте до того, как логика успеет разъехаться.
Самая частая ошибка — смешивать проверку, преобразование и бизнес-логику в одном месте. В итоге строка внезапно становится числом, пустой список проходит как валидный payload, а дефолты прячут баги. Лучше явно описать обязательные поля, ограничения и преобразования в модели, чем потом искать «магическое» поведение в обработчике.
Полезная привычка: отдельные модели для входа, ответа и внутреннего представления. Тогда payload от клиента, DTO для сервиса и объект для хранения не начинают жить одной жизнью. Ещё один плюс — проще тестировать: вы проверяете схему, а не весь endpoint целиком.
И не злоупотребляйте «умными» валидаторами там, где достаточно простых типов и ограничений. Чем меньше скрытой логики в модели, тем легче читать код, переиспользовать его в FastAPI и не ловить сюрпризы в парсерах и скриптах.
Scrapy ломается не на парсинге, а на плохой архитектуре проекта
Если у вас пауки начинают дублировать запросы, падать на редких страницах и засорять пайплайны, проблема обычно не в XPath. В Scrapy лучше сразу разнести роли: spider только собирает URL и поля, item pipeline чистит и валидирует, middleware отвечает за сеть и антибот-логику.
Три вещи, которые экономят часы:
— не хранить бизнес-логику в parse(), иначе паук быстро превращается в свалку;
— делать idempotent-обработку items, чтобы повторный прогон не плодил дубликаты;
— выносить настройки селекторов, заголовков и retry-политик в отдельные модули, а не копировать по спайдерам.
Если нужно ускорение, смотрите не только на concurrency, но и на лимиты внешнего сайта: иногда узкое место — DNS, иногда блокировки, иногда тяжелый pipeline. Еще полезно логировать причины пропуска item, а не только ошибки, тогда видно, где теряются данные.
Хороший Scrapy-проект — это когда паук можно остановить, запустить заново и получить тот же набор данных без ручной чистки.
Если у вас пауки начинают дублировать запросы, падать на редких страницах и засорять пайплайны, проблема обычно не в XPath. В Scrapy лучше сразу разнести роли: spider только собирает URL и поля, item pipeline чистит и валидирует, middleware отвечает за сеть и антибот-логику.
Три вещи, которые экономят часы:
— не хранить бизнес-логику в parse(), иначе паук быстро превращается в свалку;
— делать idempotent-обработку items, чтобы повторный прогон не плодил дубликаты;
— выносить настройки селекторов, заголовков и retry-политик в отдельные модули, а не копировать по спайдерам.
Если нужно ускорение, смотрите не только на concurrency, но и на лимиты внешнего сайта: иногда узкое место — DNS, иногда блокировки, иногда тяжелый pipeline. Еще полезно логировать причины пропуска item, а не только ошибки, тогда видно, где теряются данные.
Хороший Scrapy-проект — это когда паук можно остановить, запустить заново и получить тот же набор данных без ручной чистки.
7 ошибок в Python-скриптах, из-за которых ломается даже простой автоматизатор
Ошибка 1 — смешивать логику, ввод-вывод и парсинг в одном файле. Когда скрипт растёт, его уже нельзя нормально тестировать и переиспользовать.
Ошибка 2 — ловить
Ошибка 3 — игнорировать таймауты и ретраи. Любой запрос к API, БД или внешнему сервису должен либо быстро падать, либо повторяться по правилам. Иначе зависание выглядит как «всё работает», пока очередь не встанет.
Ошибка 4 — тащить в прод сырые
Держите код маленькими блоками: отдельная функция для данных, отдельная для действий, отдельная для ошибок. Такой Python проще чинить, проще покрывать тестами и легче передавать другому разработчику.
Ошибка 1 — смешивать логику, ввод-вывод и парсинг в одном файле. Когда скрипт растёт, его уже нельзя нормально тестировать и переиспользовать.
Ошибка 2 — ловить
except: без конкретики. Так прячутся реальные баги: сетевые сбои, битые данные, неверный формат ответа. Лучше ловить только ожидаемые исключения и логировать контекст.Ошибка 3 — игнорировать таймауты и ретраи. Любой запрос к API, БД или внешнему сервису должен либо быстро падать, либо повторяться по правилам. Иначе зависание выглядит как «всё работает», пока очередь не встанет.
Ошибка 4 — тащить в прод сырые
print() и магические константы. Для отладки годится, для эксплуатации нужен logging, конфиг и явные параметры. Тогда скрипт можно запускать и вручную, и по cron, и из Django-задачи.Держите код маленькими блоками: отдельная функция для данных, отдельная для действий, отдельная для ошибок. Такой Python проще чинить, проще покрывать тестами и легче передавать другому разработчику.
Forwarded from Потрачено! Клуб спящих бизнесменов!
Коллеги, тут типа серьёзный пост про кое что новое....
Последние месяцы я всё глубже ухожу в AI, автоматизацию и вайб-кодинг. И каждый день нахожу вещи, которые реально можно применять в арбитраже уже сегодня.
Новые MCP, AI-агенты, GitHub-репозитории, скрипты, сервисы, автоматизация, генерация контента, Telegram, инфраструктура… Короче всё, что помогает работать быстрее и зарабатывать больше.
Но публиковать это здесь не хочется.
Этот канал всё-таки про арбитраж, рынок, движуху и мои проекты.
Поэтому сделал отдельный канал AFF//AI.
Туда будут улетать:
• лучшие AI-инструменты для арбитражников;
• GitHub-репозитории и готовые решения;
• промпты, MCP, AI-агенты и автоматизация;
• разборы новых GPT, Claude и других моделей;
• всё, что реально экономит время и даёт преимущество в работе.
Если кажется, что AI скоро изменит арбитраж сильнее, чем очередной антидетект или новый спай-сервис, скорее всего так и будет.
Поэтому AFF//AI станет местом, куда я буду складывать всё самое полезное, что нахожу каждый день.
Последние месяцы я всё глубже ухожу в AI, автоматизацию и вайб-кодинг. И каждый день нахожу вещи, которые реально можно применять в арбитраже уже сегодня.
Новые MCP, AI-агенты, GitHub-репозитории, скрипты, сервисы, автоматизация, генерация контента, Telegram, инфраструктура… Короче всё, что помогает работать быстрее и зарабатывать больше.
Но публиковать это здесь не хочется.
Этот канал всё-таки про арбитраж, рынок, движуху и мои проекты.
Поэтому сделал отдельный канал AFF//AI.
Туда будут улетать:
• лучшие AI-инструменты для арбитражников;
• GitHub-репозитории и готовые решения;
• промпты, MCP, AI-агенты и автоматизация;
• разборы новых GPT, Claude и других моделей;
• всё, что реально экономит время и даёт преимущество в работе.
Если кажется, что AI скоро изменит арбитраж сильнее, чем очередной антидетект или новый спай-сервис, скорее всего так и будет.
Поэтому AFF//AI станет местом, куда я буду складывать всё самое полезное, что нахожу каждый день.
Автоматизация ломается не в коде, а в допущениях вокруг него
Чаще всего скрипт пишут так, будто входные данные всегда одинаковые. Потом он внезапно падает на пустом поле, дубликате, лишнем пробеле или неожиданном формате даты.
Перед тем как запускать автоматизацию в боевой поток, проверьте:
— что будет при пустом ответе API;
— как обрабатываются повторы и повторный запуск;
— где хранятся токены, лимиты и таймауты;
— есть ли понятный лог ошибки, а не просто traceback в консоль.
Отдельно смотрите на идемпотентность. Если скрипт отправляет письмо, пишет в CRM или создаёт запись в БД, повторный запуск не должен плодить дубли. Иначе автоматизация быстро превращается в ручную уборку.
Ещё одна типовая ошибка — смешивать бизнес-логику и инфраструктуру. Когда парсинг, ретраи, отправка уведомлений и запись в файл живут в одном файле, сопровождать это почти невозможно.
Хорошая автоматизация не та, что «работает у автора», а та, что предсказуемо отрабатывает на грязных данных, повторных запусках и частичных сбоях.
Чаще всего скрипт пишут так, будто входные данные всегда одинаковые. Потом он внезапно падает на пустом поле, дубликате, лишнем пробеле или неожиданном формате даты.
Перед тем как запускать автоматизацию в боевой поток, проверьте:
— что будет при пустом ответе API;
— как обрабатываются повторы и повторный запуск;
— где хранятся токены, лимиты и таймауты;
— есть ли понятный лог ошибки, а не просто traceback в консоль.
Отдельно смотрите на идемпотентность. Если скрипт отправляет письмо, пишет в CRM или создаёт запись в БД, повторный запуск не должен плодить дубли. Иначе автоматизация быстро превращается в ручную уборку.
Ещё одна типовая ошибка — смешивать бизнес-логику и инфраструктуру. Когда парсинг, ретраи, отправка уведомлений и запись в файл живут в одном файле, сопровождать это почти невозможно.
Хорошая автоматизация не та, что «работает у автора», а та, что предсказуемо отрабатывает на грязных данных, повторных запусках и частичных сбоях.
Forwarded from Потрачено! Клуб спящих бизнесменов!
This media is not supported in your browser
VIEW IN TELEGRAM
🚀 aff.top — вся индустрия арбитража в одном месте
🧠 Блог про арбитраж и ИИ — как нейросети меняют залив и антифрод
🚨 База спамеров — ежедневно собираем спамеров и ведём рейтинг
🛠 70+ инструментов — от клоаки до антифрод-чека
🎬 1000+ видео — весь YouTube про трафик в одной ленте
👤 2400+ персон — байеры и фаундеры с контактами напрямую
Без регистрации, без платных «премиумов».
👇 Подписывайся на канал
🧠 Блог про арбитраж и ИИ — как нейросети меняют залив и антифрод
🚨 База спамеров — ежедневно собираем спамеров и ведём рейтинг
🛠 70+ инструментов — от клоаки до антифрод-чека
🎬 1000+ видео — весь YouTube про трафик в одной ленте
👤 2400+ персон — байеры и фаундеры с контактами напрямую
Без регистрации, без платных «премиумов».
👇 Подписывайся на канал
Python-код ломается не из-за языка, а из-за мелких привычек в проекте
Есть наблюдение которое стоит проверить: в Python чаще всего страдает не алгоритм, а дисциплина вокруг него. Один и тот же код через месяц выглядит как набор случайных решений, если не держать базовые правила.
— Не мешайте бизнес-логику, I/O и форматирование в одной функции. Как только там появляется третья ответственность, тестировать уже неудобно.
— Явно отделяйте границы: входные данные валидируйте сразу, наружу отдавайте понятные структуры, а не сырые dict без схемы.
— Не ловите Exception “на всякий случай”. Лучше поймать конкретную ошибку и понять, где именно сломался сценарий.
— Если есть повторяющийся кусок, вынесите его раньше, чем он расползётся по трем модулям. Рефакторинг позже почти всегда дороже.
Отдельно смотрите на имена: плохое имя в Python живёт дольше, чем плохая функция. Когда переменная называется data, result или temp, через две недели её смысл уже приходится вспоминать.
Если нужен код, который переживёт чужую правку, держите три вещи: короткие функции, явные типы/схемы, понятные имена. Это скучно, зато именно так Python остаётся удобным, а не превращается в архив сюрпризов.
Есть наблюдение которое стоит проверить: в Python чаще всего страдает не алгоритм, а дисциплина вокруг него. Один и тот же код через месяц выглядит как набор случайных решений, если не держать базовые правила.
— Не мешайте бизнес-логику, I/O и форматирование в одной функции. Как только там появляется третья ответственность, тестировать уже неудобно.
— Явно отделяйте границы: входные данные валидируйте сразу, наружу отдавайте понятные структуры, а не сырые dict без схемы.
— Не ловите Exception “на всякий случай”. Лучше поймать конкретную ошибку и понять, где именно сломался сценарий.
— Если есть повторяющийся кусок, вынесите его раньше, чем он расползётся по трем модулям. Рефакторинг позже почти всегда дороже.
Отдельно смотрите на имена: плохое имя в Python живёт дольше, чем плохая функция. Когда переменная называется data, result или temp, через две недели её смысл уже приходится вспоминать.
Если нужен код, который переживёт чужую правку, держите три вещи: короткие функции, явные типы/схемы, понятные имена. Это скучно, зато именно так Python остаётся удобным, а не превращается в архив сюрпризов.
This media is not supported in your browser
VIEW IN TELEGRAM
Алиса AI будет конкурировать с Google AI Studio
Яндекс разворачивает экосистему AI-агентов на базе Алисы с доступом сначала для компаний, затем для всех. Агенты уже работают в Яндекс Такси и Лавке, скоро появятся в браузере и студии разработки. Платформа интегрирует стандартные функции — заказ такси, покупки, анализ данных. Алиса AI показывает неплохие результаты: менее известна, чем конкуренты, поэтому предлагает щедрые лимиты на видеогенерацию и работу с контентом. Яндекс планирует внедрить…
➡️ Читайте на сайте: https://aff.top/blog/alisa-ai-budet-konkurirovat-s-google-ai-studio
🧠 Ещё больше инсайтов → в канале AFF.top
Яндекс разворачивает экосистему AI-агентов на базе Алисы с доступом сначала для компаний, затем для всех. Агенты уже работают в Яндекс Такси и Лавке, скоро появятся в браузере и студии разработки. Платформа интегрирует стандартные функции — заказ такси, покупки, анализ данных. Алиса AI показывает неплохие результаты: менее известна, чем конкуренты, поэтому предлагает щедрые лимиты на видеогенерацию и работу с контентом. Яндекс планирует внедрить…
➡️ Читайте на сайте: https://aff.top/blog/alisa-ai-budet-konkurirovat-s-google-ai-studio
🧠 Ещё больше инсайтов → в канале AFF.top
This media is not supported in your browser
VIEW IN TELEGRAM
В Zennoposter добавили ИИ-помощник
Zennolab добавил в Zennoposter встроенный ИИ-кубик с доступом к четырём моделям (Gemini, DeepSeek, Claude, ChatGPT) — 50 бесплатных запросов в сутки. Есть режимы Assistant (чтение) и Agent (автоматическое создание скриптов), плюс новый GET-запрос по API. Нейросети хорошо справляются с регистрацией, постингом, фармингом аккаунтов и простым кодированием, но требуют проверки при парсинге динамических сайтов и диагностике ошибок. В связке с Zennoobr…
➡️ Читайте на сайте: https://aff.top/blog/v-zennoposter-dobavili-ii-pomoschnik
🧠 Ещё больше инсайтов → в канале AFF.top
Zennolab добавил в Zennoposter встроенный ИИ-кубик с доступом к четырём моделям (Gemini, DeepSeek, Claude, ChatGPT) — 50 бесплатных запросов в сутки. Есть режимы Assistant (чтение) и Agent (автоматическое создание скриптов), плюс новый GET-запрос по API. Нейросети хорошо справляются с регистрацией, постингом, фармингом аккаунтов и простым кодированием, но требуют проверки при парсинге динамических сайтов и диагностике ошибок. В связке с Zennoobr…
➡️ Читайте на сайте: https://aff.top/blog/v-zennoposter-dobavili-ii-pomoschnik
🧠 Ещё больше инсайтов → в канале AFF.top
Flask ломается не на роутинге, а на границах приложения: вот где искать баги
В Flask проект обычно выглядит простым, пока в нём не появляется конфиг, база, фоновые задачи и пару blueprint'ов. Дальше ошибки начинаются не в вьюхах, а в том, как собирается приложение.
— Не держите инициализацию БД и клиентов API в модуле импорта: при тестах и запуске воркеров это даёт скрытые сайд-эффекты.
— Не смешивайте бизнес-логику и обработчики: view должен принять запрос, вызвать сервис и вернуть ответ.
— Для конфигурации используйте один объект settings, а не россыпь переменных окружения по файлам.
— Если есть несколько контекстов, явно фиксируйте, где нужен app context, а где request context.
Отдельная боль — шаблоны глобального состояния. Кэш, синглтоны, соединения и хранилища лучше создавать через factory-функцию, иначе тесты начинают зависеть друг от друга, а баги проявляются только под нагрузкой. Для небольших сервисов это особенно коварно: код кажется «лёгким», но поддержка быстро дорожает.
Ещё один маркер зрелого Flask-кода — предсказуемая структура: app/, services/, repositories/, routes/, tests/. Когда файл отвечает за одну роль, проект легче масштабировать, а отладка занимает минуты, а не вечер.
В Flask проект обычно выглядит простым, пока в нём не появляется конфиг, база, фоновые задачи и пару blueprint'ов. Дальше ошибки начинаются не в вьюхах, а в том, как собирается приложение.
— Не держите инициализацию БД и клиентов API в модуле импорта: при тестах и запуске воркеров это даёт скрытые сайд-эффекты.
— Не смешивайте бизнес-логику и обработчики: view должен принять запрос, вызвать сервис и вернуть ответ.
— Для конфигурации используйте один объект settings, а не россыпь переменных окружения по файлам.
— Если есть несколько контекстов, явно фиксируйте, где нужен app context, а где request context.
Отдельная боль — шаблоны глобального состояния. Кэш, синглтоны, соединения и хранилища лучше создавать через factory-функцию, иначе тесты начинают зависеть друг от друга, а баги проявляются только под нагрузкой. Для небольших сервисов это особенно коварно: код кажется «лёгким», но поддержка быстро дорожает.
Ещё один маркер зрелого Flask-кода — предсказуемая структура: app/, services/, repositories/, routes/, tests/. Когда файл отвечает за одну роль, проект легче масштабировать, а отладка занимает минуты, а не вечер.
This media is not supported in your browser
VIEW IN TELEGRAM
Новую Google reCapcha прошли статичной картинкой
Google выпустил обновленную reCAPTCHA, требующую движений рук для прохождения, но система оказалась уязвима к обходу. Достаточно транслировать статичное изображение с нужным жестом через виртуальную камеру с помощью простого Python-скрипта, чтобы нейросеть пропустила пользователя. Это создает серьёзный риск для сайтов: защита от ботов, позиционировавшаяся как прорыв, на деле не работает. Баг остается актуальным и позволяет спамерам легко автомат…
➡️ Читайте на сайте: https://aff.top/blog/novuiu-google-recapcha-proshli-statichnoi-kartinkoi
🧠 Ещё больше инсайтов → в канале AFF.top
Google выпустил обновленную reCAPTCHA, требующую движений рук для прохождения, но система оказалась уязвима к обходу. Достаточно транслировать статичное изображение с нужным жестом через виртуальную камеру с помощью простого Python-скрипта, чтобы нейросеть пропустила пользователя. Это создает серьёзный риск для сайтов: защита от ботов, позиционировавшаяся как прорыв, на деле не работает. Баг остается актуальным и позволяет спамерам легко автомат…
➡️ Читайте на сайте: https://aff.top/blog/novuiu-google-recapcha-proshli-statichnoi-kartinkoi
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
DeepSeek представит последнюю версию v4
DeepSeek выпустит v4 в середине июля с новой моделью ценообразования API: токены подорожают в 2 раза в часы пиковой нагрузки (09:00–12:00 и 14:00–18:00 по пекинскому времени). Компания планирует уведомлять пользователей по почте за 24 часа до изменения тарифов. Проблема с ошибками «server busy» останется, но обойдётся дороже — это может существенно повлиять на экономику проектов, которые активно используют API DeepSeek для автоматизации и масшта…
➡️ Читайте на сайте: https://aff.top/blog/deepseek-predstavit-posledniuiu-versiiu-v4
🧠 Ещё больше инсайтов → в канале AFF.top
DeepSeek выпустит v4 в середине июля с новой моделью ценообразования API: токены подорожают в 2 раза в часы пиковой нагрузки (09:00–12:00 и 14:00–18:00 по пекинскому времени). Компания планирует уведомлять пользователей по почте за 24 часа до изменения тарифов. Проблема с ошибками «server busy» останется, но обойдётся дороже — это может существенно повлиять на экономику проектов, которые активно используют API DeepSeek для автоматизации и масшта…
➡️ Читайте на сайте: https://aff.top/blog/deepseek-predstavit-posledniuiu-versiiu-v4
🧠 Ещё больше инсайтов → в канале AFF.top
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Anthropic выпустили Sonnet 5
30 июня вышла Claude Sonnet 5 — новая версия позиционируется как самая агентная в линейке и приближается к флагманской Opus 4.8. Модель лучше справляется со сложными многоуровневыми задачами, устойчива к вредоносным запросам и не генерирует эксплойты. Sonnet 5 доступна на Free-тарифе, но тестирование показало скромные улучшения: хотя работает лучше Sonnet 4.6, её обгоняют конкуренты, включая китайские модели, которые дешевле через API при лучшей…
➡️ Читайте на сайте: https://aff.top/blog/anthropic-vypustili-sonnet-5
🧠 Ещё больше инсайтов → в канале AFF.top
30 июня вышла Claude Sonnet 5 — новая версия позиционируется как самая агентная в линейке и приближается к флагманской Opus 4.8. Модель лучше справляется со сложными многоуровневыми задачами, устойчива к вредоносным запросам и не генерирует эксплойты. Sonnet 5 доступна на Free-тарифе, но тестирование показало скромные улучшения: хотя работает лучше Sonnet 4.6, её обгоняют конкуренты, включая китайские модели, которые дешевле через API при лучшей…
➡️ Читайте на сайте: https://aff.top/blog/anthropic-vypustili-sonnet-5
🧠 Ещё больше инсайтов → в канале AFF.top
Автоматизация ломается не на коде, а на исключениях и повторном запуске
Чаще всего скрипт пишут как «счастливый путь»: данные пришли, API ответил, файл сохранился. В реальной автоматизации важнее другое — что будет при таймауте, пустом ответе, дубле, частичном падении и повторном запуске после сбоя.
Держите базовый чек-лист:
— idempotency: повторный запуск не должен дублировать записи;
— retries: только для временных ошибок, с ограничением и паузой;
— checkpoints: сохраняйте прогресс, а не только финальный результат;
— logging: пишите не «упало», а что именно, на каком объекте и почему.
Если есть очередь, cron или планировщик — отдельно проверьте, что задача не запускается параллельно сама с собой. Иначе один и тот же файл, заказ или строка таблицы обработается дважды, а потом это будет выглядеть как «странная бизнес-ошибка», хотя проблема была в конкуренции.
Еще одна типовая ошибка — смешивать загрузку, обработку и запись в один монолитный скрипт. Когда всё в одном блоке, любой сбой заставляет гонять процесс заново. Разносите этапы: вход, валидация, трансформация, выход. Тогда каждый шаг проще тестировать и безопаснее перезапускать.
Если автоматизация должна жить долго, проектируйте ее как цепочку повторяемых шагов, а не как одноразовый запуск.
Чаще всего скрипт пишут как «счастливый путь»: данные пришли, API ответил, файл сохранился. В реальной автоматизации важнее другое — что будет при таймауте, пустом ответе, дубле, частичном падении и повторном запуске после сбоя.
Держите базовый чек-лист:
— idempotency: повторный запуск не должен дублировать записи;
— retries: только для временных ошибок, с ограничением и паузой;
— checkpoints: сохраняйте прогресс, а не только финальный результат;
— logging: пишите не «упало», а что именно, на каком объекте и почему.
Если есть очередь, cron или планировщик — отдельно проверьте, что задача не запускается параллельно сама с собой. Иначе один и тот же файл, заказ или строка таблицы обработается дважды, а потом это будет выглядеть как «странная бизнес-ошибка», хотя проблема была в конкуренции.
Еще одна типовая ошибка — смешивать загрузку, обработку и запись в один монолитный скрипт. Когда всё в одном блоке, любой сбой заставляет гонять процесс заново. Разносите этапы: вход, валидация, трансформация, выход. Тогда каждый шаг проще тестировать и безопаснее перезапускать.
Если автоматизация должна жить долго, проектируйте ее как цепочку повторяемых шагов, а не как одноразовый запуск.
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Clickstar прекращает работу
Clickstar закрывается. Легендарная пуш-сеть прекращает закуп трафика с 1 августа, полная остановка — 20 августа.
Сетка работала почти 8 лет и была одним из лучших источников качественного трафика на Россию и СНГ. Сейчас пуш-трафик стал слишком ботовым из-за гугловских банов на скрипты сбора.
Что это означает для арбитражников — разбираемся в ста…
➡️ Читайте на сайте: https://aff.top/blog/clickstar-prekraschaet-rabotu
🧠 Ещё больше инсайтов → в канале AFF.top
Clickstar закрывается. Легендарная пуш-сеть прекращает закуп трафика с 1 августа, полная остановка — 20 августа.
Сетка работала почти 8 лет и была одним из лучших источников качественного трафика на Россию и СНГ. Сейчас пуш-трафик стал слишком ботовым из-за гугловских банов на скрипты сбора.
Что это означает для арбитражников — разбираемся в ста…
➡️ Читайте на сайте: https://aff.top/blog/clickstar-prekraschaet-rabotu
🧠 Ещё больше инсайтов → в канале AFF.top