Pydantic ломают не типы, а границы входных данных

Если модель валится в рантайме, проблема обычно не в самой схеме, а в том, что в неё тащат всё подряд: raw JSON, формы, query params и внутренние dict без разделения слоёв. Для веба полезно держать три уровня: входной payload, нормализованную доменную модель и объект для ответа.

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

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

Ещё одна полезная привычка: не использовать одну и ту же модель для create, update и response. Это почти всегда приводит к лишним optional-полям, странным default и утечке внутренних атрибутов в API.

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

asyncio ломается не в await, а в границах между I/O, CPU и cancellation

Если в проекте «всё асинхронно», это ещё не значит, что оно масштабируется. В реальности чаще всего путают три вещи: параллельность, конкурентность и неблокирующий I/O. asyncio хорошо работает там, где задачи ждут сеть, диск или таймеры. Как только в корутину попадает тяжёлая CPU-работа, event loop начинает задыхаться.

Есть 4 типовые ошибки:
— забыли вынести CPU-bound кусок в thread/process pool;
— сделали много await подряд там, где нужен gather();
— не закрыли клиент/сессию/соединение и получили утечки;
— игнорируют cancellation, а потом ловят «зависшие» фоновые задачи.

Отдельно проверьте точки входа. Если внутри корутины вызывается обычный блокирующий код — sleep, requests, синхронный ORM, файловые операции без ограничений — весь выигрыш от asyncio исчезает. Для внешних API, очередей и парсинга это особенно заметно: один блокирующий вызов может остановить десятки задач.

Хорошее правило: корутина должна либо ждать I/O, либо быстро делегировать тяжёлую работу наружу. Если это не так — перепишите участок, а не «добавляйте больше async».

Flask ломается не на маршрутах, а на том, как вы смешиваете слои

У Flask есть полезная ловушка: проект легко стартует как один файл, а потом тихо превращается в комок view-функций, SQL и логики авторизации. Если через месяц в код страшно заходить, проблема обычно не в фреймворке, а в отсутствии границ.

Рабочая схема для живого проекта:
— routes держат только HTTP-слой: принять запрос, провалидировать, вернуть ответ;
— service содержит бизнес-логику и не знает про request;
— repository общается с БД или внешним API;
— extensions и config инициализируются отдельно, а не прячутся внутри view.

Еще одна типовая ошибка — хранить состояние в глобальных переменных и надеяться, что «в проде не заметят». Flask сам по себе не спасает от гонок, если вы пишете в модульные переменные, кэшируете «на глаз» или создаете клиент БД в каждом обработчике.

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

Scrapy ломается не на парсинге, а на мелочах вокруг него: 6 проверок

Scrapy часто считают “просто фреймворком для пауков”, но в проде он падает на одинаковых вещах. За неделю в репах обычно всплывают одни и те же ошибки: не тот selector, дубли, кривой пайплайн, таймауты и слишком жирные ответы от сайта.

— Сначала проверь, что ты выбираешь именно стабильный узел, а не случайный div внутри карточки.
— Дальше смотри на дедупликацию: canonical, query-параметры, пагинация и одинаковые ссылки с разным мусором в URL.
— Если данные “исчезают”, ищи проблему в item pipeline, а не в spider: там часто тихо режутся пустые поля и неожиданные типы.
— Для тяжёлых страниц включай ограничение concurrency и нормальный retry/backoff, иначе ты сам создаёшь себе бан.

Есть наблюдение которое стоит проверить: если Spider работает только на одной странице, почти всегда дело в предположении, что HTML одинаковый. В Scrapy это лечится не магией, а явной проверкой структуры ответа и отдельной логикой на каждый шаблон страницы.

Ещё одна типовая ловушка — смешивать сбор и очистку. Spider должен добывать сырые поля, а нормализация, приведение типов и фильтры — жить отдельно. Тогда проще тестировать, проще дебажить и проще менять источник без переписывания всего проекта.

Если Scrapy “вроде работает”, но результат плавает, начни с трёх вещей: структура ответа, дедуп, pipeline. Это экономит больше времени, чем любой красивый рефакторинг.

1. Выкатить ни какую он-лайн конфу я естесвенно не выкатил, потерпите

2. После прошлого видео (тык) мой канал теперь имеет юзер @PO_YICA_BRAL

3. Держите вечернее видео, я нажрусь и спать

Чото надо ещё сказать? Ну, можно лишь добавить Настя #MelBet верни деньги, не играй с огнём, со мной лучше не ссориться. Спасибо.

P.S. Бабка-то, похоже, не своей..... см. видео!

С уважением, Иванов Е.Ю!