🔥 Один из лучших обучающих курсов на StepiK по SQL

SQL можно знать годами и всё равно теряться, когда запрос внезапно начинает тормозить в проде.

Этот курс про уровень, где ты не просто пишешь SELECT, а понимаешь, что происходит внутри MySQL, почему запрос работает медленно и как ускорить его без новых проблем. Здесь разбираются EXPLAIN, индексы, CTE, оконные функции, транзакции, аналитические паттерны, legacy SQL и работа с AI-ассистентами.

Каждый урок - с практикой и реальными SQL-задачами на MySQL 8 с автопроверкой.

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

Для подписчиков скидка - 49% в течение 2 суток: https://stepik.org/a/298827/

🔥 Package Doctor - необычный security-сканер для Python-зависимостей

Он отвечает не только на вопрос «есть ли у пакета CVE?», а на более практичный:

если завтра в этой зависимости найдут уязвимость, вы реально под угрозой и есть ли вообще кому её исправлять?

Package Doctor оценивает сразу две вещи:

- находится ли библиотека на trust boundary: auth, загрузка файлов, десериализация, crypto, URL parsing, model loading и т.д.
- есть ли у проекта реальная способность быстро выпустить фикс

Плюс инструмент:

- проверяет pinned-версии по advisory-базам
- учитывает CISA KEV и EPSS
- AST-парсит ваш код и показывает, где зависимость реально импортируется
- отличает abandoned package от просто редко обновляемого
- умеет работать как hook для Claude Code и блокировать подозрительную зависимость до pip install

Интересный подход: не засыпать разработчика сотнями CVE, а приоритизировать именно те зависимости, где одновременно есть экспозиция + слабая поддержка.

Автор отдельно рекомендует использовать его вместе с pip-audit, а не вместо него.

https://github.com/binuka200/package-doctor

🔥 Qwen представила Qwen3.8-Omni-Flash - свою первую мультимодальную модель, изначально заточенную под агентные задачи.

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

По данным Qwen, на WildClawBench-MM и UniClawBench модель прибавила в среднем 19,5 пункта в агентных задачах и приблизилась к Gemini 3.8 Flash по работе с аудио и видео.

Контекст - 1 млн токенов. На OmniVideoBench активный поиск по длинному видео позволил сократить расход токенов на 51,8% по сравнению со статическим анализом.

Стоимость обработки видео при этом снизилась примерно на 89% относительно Qwen3.5-Omni-Plus.

Вместе с моделью Qwen открывает Qwen-MM-Plugins для мультимодальных инструментов. Qwen-Live Harness также будет опубликован отдельно.

https://qwen.ai/blog?id=qwen3.8-omni-flash

🐍 В CPython одно чтение `__dict__` может навсегда замедлить доступ к атрибутам конкретного объекта.

Начиная с Python 3.11 обычный obj.x часто вообще не делает lookup по словарю. После прогрева интерпретатор специализирует LOAD_ATTR, а значение читается почти напрямую из inline storage объекта.

Но достаточно выполнить:

`obj.__dict__`

или:

`vars(obj)`

а в некоторых случаях даже:

`copy.copy(obj)`

— и __dict__ материализуется. После этого объект теряет быстрый специализированный путь на оставшееся время жизни.

На CPython 3.14.6 в тесте на M3:

обычный объект → 33.0 ms
после чтения __dict__ → 50.6 ms

В free-threaded сборке разрыв ещё больше:

34.0 ms → 59.4 ms.

Интересная деталь: __slots__ сам по себе почти не ускоряет обычный attribute access. Его преимущество здесь в другом — у объекта нет __dict__, значит его невозможно случайно материализовать и сбить оптимизацию.

Очень неочевидная причина, почему vars() или copy.copy() внутри hot path могут неожиданно ударить по производительности.

https://deadlovelll.github.io/2026-09-05-reading-dict-deoptimizes-attribute-access/

🐍 Ruff доволен, mypy молчит, тесты зелёные. А в коде четыре одинаковых функции

Автор статьи столкнулся с этим в проекте, который писал ИИ-агент. Вместо поиска готовых функций агент добавлял новые копии. Когда понадобилось изменить нормализацию данных, он уже не мог разобраться, какую из четырёх править.

Обычные проверки не покрывают всю структуру проекта:

* Ruff находит нарушения правил и умеет проверять сложность при соответствующей настройке.
* mypy проверяет типы.
* pytest проверяет сценарии, для которых написаны тесты.

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

Автор предлагает добавить структурный анализ. Его инструмент pyscn ищет дубли, сложные функции, мёртвый код и нарушения правил зависимостей:

uvx pyscn analyze .

Что полезно забрать в свой проект:

* Блокировать в CI новые проблемы, а не сразу весь накопленный техдолг.
* Следить за изменением сложности, а не только за общей оценкой.
* Закрепить допустимые зависимости между модулями проверяемыми правилами.
* Дать агенту запускать анализатор до отправки кода на ревью.

Высокая сложность сама по себе ещё не повод переписывать функцию. Иногда длинная последовательность понятных проверок лучше искусственного дробления.

Статья — https://codescan.dev/blog/ruff-mypy-pytest-and-then-what