Google ужесточает модерацию финансовой вертикали

Google ужесточает модерацию финансовых офферов в ЕС и ЕЭЗ, введя двухэтапную верификацию через G2 Risk Solutions и Google Ads. Проверка затронет 24 страны, включая Австрию, Польшу, Нидерланды и другие члены союза. На прохождение модерации отводится 30 дней — за это время некоторые связки успеют отработать до вступления требований в силу. Для арбитражников это означает необходимость подготовиться к усложнению процесса запуска финансовых кампаний …

➡️ Читайте на сайте: https://aff.top/blog/google-uzhestochaet-moderaciiu-finansovoi-vertikali

🧠 Ещё больше инсайтов → в канале AFF.top

Scrapy ломается не на парсинге, а на грязной логике очередей и дублей

В Scrapy чаще всего ошибаются не в selectors, а в архитектуре паука:
— ставят тяжёлый код в parse и тормозят весь crawl;
— не разделяют extraction и normalization;
— игнорируют повторные запросы и получают мусор в очереди;
— путают пагинацию с обходом связей и случайно уходят в бесконечный обход.

Держите простое правило: parse должен быстро извлечь данные, собрать Request и уйти дальше. Всё, что связано с очисткой строк, преобразованием дат, расчётом полей и записью в хранилище, лучше выносить в pipeline или отдельный слой сервиса. Так паук проще тестировать и легче масштабировать.

Ещё один частый провал — отсутствие контроля за дублями и статусами. Если сайт отдаёт одинаковые карточки под разными URL, нужен свой fingerprint-ключ или нормализация ссылки. Если часть страниц отвечает 403/429, не лечите это бесконечными ретраями: лучше ограничить глубину, настроить паузы и понять, какие запросы реально нужны.

Если Scrapy начинает «есть всё подряд», остановитесь и проверьте три вещи: схему обхода, фильтрацию URL и границу ответственности между пауком и обработкой данных. Тогда проект перестаёт быть набором костылей и становится обычным конвейером.

Real Python выкатил 20-вопросный квиз по data structures — без выхода за базу

Вопросы проходят по strings, lists, tuples, dictionaries, sets, sorting и bytes.
Квиз собран вокруг core concepts из learning path по Python Data Structures, где сейчас 24 ресурса.

Для веб-разработки это полезно не как «тест на эрудицию», а как быстрый чек по тем местам, где чаще всего ломаются скрипты: сериализация, сортировка, мутации коллекций, работа с байтами.
Если в команде есть Django/FastAPI-сервисы, такой квиз удобно дать джуну перед ревью или прогнать самому перед рефакторингом утилит.

20 вопросов — нормальный формат, чтобы за 10 минут понять, где знания уже автоматические, а где ещё нужен гугл.

Один scatter-плот в Python закрывает и отчёт, и отладку — если докрутить s, c и alpha

Matplotlib делает scatter-плоты через plt.scatter(): два array-like набора для x и y, и точек уже можно насыпать на график.
Перед этим сам Matplotlib нужно установить.

Важный практический момент для веба и скриптов: у scatter() есть точечная настройка размера, цвета, формы и прозрачности через s, c, marker и alpha.
Для простых графиков plt.plot() с marker-аргументами может работать быстрее, но когда нужно размечать группы, аномалии или статус записей по цвету — без scatter() уже неудобно.

Если у вас Django/FastAPI-проект с генерацией графиков по данным из БД или ETL, это базовый инструмент, который быстро превращает сырые массивы в читаемую визуализацию.

Fable 5 скоро вернётся в публичный доступ

В исходном коде Claude Code обнаружены упоминания о возвращении модели Fable 5 в публичный доступ с изменённой моделью распространения — её больше не потребуется покупать отдельно, вместо этого будет применяться недельный лимит как для других моделей. Если информация подтвердится, пользователи платных тарифов смогут использовать Fable 5 в рамках своих подписок. Причины снятия ограничений по национальной безопасности остаются неясными. Хотя это п…

➡️ Читайте на сайте: https://aff.top/blog/fable-5-skoro-vernetsia-v-publichnyi-dostup

🧠 Ещё больше инсайтов → в канале AFF.top

7 ошибок в автоматизации на Python, из-за которых скрипт ломается в проде

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

— Нет идемпотентности: повторный запуск создает дубли, а не пропускает уже обработанное.
— Нет явных таймаутов и ретраев: зависший HTTP-запрос висит бесконечно, а ошибка сети валит весь поток.
— Смешаны ввод, обработка и вывод: код нельзя тестировать по частям и трудно переиспользовать.
— Логика завязана на пути, переменные окружения и ручной запуск из терминала.

Отдельно проверяйте конкуренцию: если два воркера читают одну очередь или один и тот же файл, нужен лок или атомарная запись. И не полагайтесь на «если упало — перезапущу руками»: после перезапуска скрипт должен понимать, что уже сделал, а что еще нет.

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

Pydantic ломается не в моделях, а в границах данных: 5 правил, которые спасают API

Если 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 — не компромисс, а осознанный выбор.

Chat GPT-5.6 будут выдавать лишь избранным

США ограничивают публичный доступ к новым ИИ-моделям: теперь его выдают только проверенным пользователям после обязательной 30-дневной процедуры верификации. Сэм Альтман называет это самым быстрым путём к публичному релизу. Эффективность меры вызывает сомнения — китайские разработчики традиционно копируют модели в течение суток после выхода.

➡️ Читайте на сайте: https://aff.top/blog/chat-gpt-5-6-budut-vydavat-lish-izbrannym

🧠 Ещё больше инсайтов → в канале AFF.top

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

Pydantic ломает меньше, если сразу договориться о правилах на входе

Если модель используется в API, скриптах и фоновых задачах, держите один подход к данным:
— вход валидируйте на границе;
— внутри системы работайте уже с типизированным объектом;
— ошибки отдавайте до того, как логика успеет разъехаться.

Самая частая ошибка — смешивать проверку, преобразование и бизнес-логику в одном месте. В итоге строка внезапно становится числом, пустой список проходит как валидный payload, а дефолты прячут баги. Лучше явно описать обязательные поля, ограничения и преобразования в модели, чем потом искать «магическое» поведение в обработчике.

Полезная привычка: отдельные модели для входа, ответа и внутреннего представления. Тогда payload от клиента, DTO для сервиса и объект для хранения не начинают жить одной жизнью. Ещё один плюс — проще тестировать: вы проверяете схему, а не весь endpoint целиком.

И не злоупотребляйте «умными» валидаторами там, где достаточно простых типов и ограничений. Чем меньше скрытой логики в модели, тем легче читать код, переиспользовать его в FastAPI и не ловить сюрпризы в парсерах и скриптах.

Scrapy ломается не на парсинге, а на плохой архитектуре проекта

Если у вас пауки начинают дублировать запросы, падать на редких страницах и засорять пайплайны, проблема обычно не в XPath. В Scrapy лучше сразу разнести роли: spider только собирает URL и поля, item pipeline чистит и валидирует, middleware отвечает за сеть и антибот-логику.

Три вещи, которые экономят часы:
— не хранить бизнес-логику в parse(), иначе паук быстро превращается в свалку;
— делать idempotent-обработку items, чтобы повторный прогон не плодил дубликаты;
— выносить настройки селекторов, заголовков и retry-политик в отдельные модули, а не копировать по спайдерам.

Если нужно ускорение, смотрите не только на concurrency, но и на лимиты внешнего сайта: иногда узкое место — DNS, иногда блокировки, иногда тяжелый pipeline. Еще полезно логировать причины пропуска item, а не только ошибки, тогда видно, где теряются данные.

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

7 ошибок в Python-скриптах, из-за которых ломается даже простой автоматизатор

Ошибка 1 — смешивать логику, ввод-вывод и парсинг в одном файле. Когда скрипт растёт, его уже нельзя нормально тестировать и переиспользовать.

Ошибка 2 — ловить except: без конкретики. Так прячутся реальные баги: сетевые сбои, битые данные, неверный формат ответа. Лучше ловить только ожидаемые исключения и логировать контекст.

Ошибка 3 — игнорировать таймауты и ретраи. Любой запрос к API, БД или внешнему сервису должен либо быстро падать, либо повторяться по правилам. Иначе зависание выглядит как «всё работает», пока очередь не встанет.

Ошибка 4 — тащить в прод сырые print() и магические константы. Для отладки годится, для эксплуатации нужен logging, конфиг и явные параметры. Тогда скрипт можно запускать и вручную, и по cron, и из Django-задачи.

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

Автоматизация ломается не в коде, а в допущениях вокруг него

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

Перед тем как запускать автоматизацию в боевой поток, проверьте:
— что будет при пустом ответе API;
— как обрабатываются повторы и повторный запуск;
— где хранятся токены, лимиты и таймауты;
— есть ли понятный лог ошибки, а не просто traceback в консоль.

Отдельно смотрите на идемпотентность. Если скрипт отправляет письмо, пишет в CRM или создаёт запись в БД, повторный запуск не должен плодить дубли. Иначе автоматизация быстро превращается в ручную уборку.

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

Хорошая автоматизация не та, что «работает у автора», а та, что предсказуемо отрабатывает на грязных данных, повторных запусках и частичных сбоях.

Python-код ломается не из-за языка, а из-за мелких привычек в проекте

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

— Не мешайте бизнес-логику, I/O и форматирование в одной функции. Как только там появляется третья ответственность, тестировать уже неудобно.
— Явно отделяйте границы: входные данные валидируйте сразу, наружу отдавайте понятные структуры, а не сырые dict без схемы.
— Не ловите Exception “на всякий случай”. Лучше поймать конкретную ошибку и понять, где именно сломался сценарий.
— Если есть повторяющийся кусок, вынесите его раньше, чем он расползётся по трем модулям. Рефакторинг позже почти всегда дороже.

Отдельно смотрите на имена: плохое имя в Python живёт дольше, чем плохая функция. Когда переменная называется data, result или temp, через две недели её смысл уже приходится вспоминать.

Если нужен код, который переживёт чужую правку, держите три вещи: короткие функции, явные типы/схемы, понятные имена. Это скучно, зато именно так Python остаётся удобным, а не превращается в архив сюрпризов.

Алиса AI будет конкурировать с Google AI Studio

Яндекс разворачивает экосистему AI-агентов на базе Алисы с доступом сначала для компаний, затем для всех. Агенты уже работают в Яндекс Такси и Лавке, скоро появятся в браузере и студии разработки. Платформа интегрирует стандартные функции — заказ такси, покупки, анализ данных. Алиса AI показывает неплохие результаты: менее известна, чем конкуренты, поэтому предлагает щедрые лимиты на видеогенерацию и работу с контентом. Яндекс планирует внедрить…

➡️ Читайте на сайте: https://aff.top/blog/alisa-ai-budet-konkurirovat-s-google-ai-studio

🧠 Ещё больше инсайтов → в канале AFF.top

В Zennoposter добавили ИИ-помощник

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/. Когда файл отвечает за одну роль, проект легче масштабировать, а отладка занимает минуты, а не вечер.