Python Django

Идеальный старт для проекта Django: конфигурация окружения. Сохрани себе идеальный шаблон virtual environment и основных настроек для каждого нового проекта Django. Это упростит процесс настройки окружения и позволит избежать распространенных ошибок.

    
        
# Создание виртуального окружения
python3 -m venv venv

# Активация виртуального окружения
source venv/bin/activate

# Установка основных зависимостей
pip install django djangorestframework psycopg2

# Создание файла requirements.txt
pip freeze > requirements.txt

# Инициализация нового проекта Django
django-admin startproject myproject
# Переход в директорию проекта
cd myproject

# Запуск сервера для проверки
python manage.py runserver{}
    

Вышли первые выпуски IT-покера от K2 Cloud Турнир, где айтишники собирают идеальные билды из карт, интуиции и навыков. Вместо привычной колоды — технологии, сервисы и архитектурные решения. Идем смотреть

🚀 AgentCPM-Explore - первый open-source агент на 4B, который реально тащит GAIA и сложные реальные задачи OpenBMB выкатили AgentCPM-Explore - модель всего на 4B параметров, но по агентным метрикам она выглядит как зверь. ✅ SOTA среди 4B агент-моделей По агентным бенчмаркам модель: - обгоняет всех на своём масштабе - превосходит часть 8B моделей - и даже конкурирует с некоторыми 30B+ и closed-source LLM 🧠 Deep Research как у “исследователя” Модель умеет: - длинные цепочки рассуждений (long-horizon reasoning) - 100+ ходов автономного диалога - проверять себя через несколько источников (cross-validation) - делать самокоррекцию как человек - динамически менять стратегию и использовать инструменты То есть это уже не “чатбот”, а мини-исследователь, который реально может вести задачу до конца. 🔓 Открыт не только модельный вес - открыт весь стек И это самое жирное: OpenBMB выкладывают не “голую модель”, а весь pipeline агентности: - AgentRL - асинхронный RL-фреймворк для обучения агентов - AgentDock - безопасная песочница инструментов (tool sandbox) - AgentToLeaP - платформа оценки tool-learning (в один клик) - полный датапайплайн и воспроизводимые training workflows Это полноценная open-source платформа для создания агентов, где можно реально учиться, экспериментировать и собирать своих автономных “ресёрчеров”. Кто уже тестил GAIA на своих агентах ? 🤗 Hugging Face: https://huggingface.co/openbmb/AgentCPM-Explore 🔗 GitHub: https://github.com/OpenBMB/AgentCPM

🖥 На Stepik вышел курс, который учит работать с Docker на реальных проектах. Владение Docker - навык, который отличает новичка от профи, Сегодня почти всё разворачивается в контейнерах. Если ты не умеешь работать с Docker, ты медленнее, зависим от чужих настроек и постоянно ловишь баги «у меня локально работает». • как упаковывать проекты в контейнеры • как поднимать целые системы за минуты • как избегать типичных ошибок в продакшене • как делать стабильные и повторяемые окружения •в нем разобраны все возможные ошибки Только практика и реальные кейсы от авторов Docker Академии- с нуля до уверенного уровня. 🎁 Скидка 40 процентов действует 48 часов 👉 Записывайся и сделай Docker своим настоящим рабочим инструментом.

🖥 FastAPI для клиента: как должны выглядеть API-клиенты в Python Python-сообщество отлично научилось делать API-серверы. FastAPI / DRF дают идеальный опыт разработчика: - типы - валидация - понятные эндпоинты - документация по OpenAPI - минимум рутины Но есть проблема. Серверы стали удобными и “правильными”, а вот клиентская сторона до сих пор часто выглядит как кустарщина. Что часто встречается в проектах на базе python: - везде раскиданы httpx.get/post - URL собираются руками - параметры и headers копируются по коду - ответы парсятся вручную - ошибки обрабатываются как попало - нет нормальных типов и автодополнения И именно тут часто появляется 80% проблем. API может быть идеально спроектирован, но пользоваться им неудобно. Да, можно сгенерировать кода клиента. Но чаще всего генератор выдаёт огромный неудобный код: - странные имена методов - перегруженные классы - нечитаемый boilerplate - всё равно приходится писать обёртки руками В итоге клиенты либо не генерируют вообще, либо генерируют и потом ненавидят. API-клиенты должны быть сделаны как фреймворк. Как FastAPI, только наоборот. То есть ты описываешь клиент красиво и декларативно: - функция описывает intent (что мы делаем) - типы описывают контракт - библиотека берёт на себя HTTP-рутину Вместо кода “на коленке” httpx.get("https://api.site.com/users/123") Должно быть get_user(123) И дальше библиотека сама: - соберёт URL - подставит параметры - сериализует запрос - выполнит HTTP - распарсит ответ - кинет нормальную ошибку - даст типы и автодополнение в IDE Именно эту идею автор статье и продвигает (проект Clientele) Сделать API-клиенты удобными, чистыми и типобезопасными так же, как мы привыкли делать серверы Проблема не в HTTP. Проблема в том, что API-клиенты в Python до сих пор не стали “первоклассным кодом”. А должны стать. Подробности: paulwrites.software/articles/python-api-clients

⚡️ Базовая аутентификация в Django: как сделать правильно В статье рассматривается, как настроить базовую (Basic) аутентификацию в Django для API и защищённых ресурсов. Что такое Basic Authentication Это самый простой способ аутентификации по HTTP: клиент отправляет логин и пароль в заголовке Authorization: Basic …, закодированные в base64. Подходит для API, но требует HTTPS, так как пароль передаётся в каждом запросе. Django по умолчанию не предоставляет Basic Auth для view-функций. Он есть только в Django REST Framework. Если нужен собственный API или простая защита эндпоинтов без DRF — придётся реализовать самому. Подход из статьи Автор показывает, как создать middleware или декоратор, который: - проверяет заголовок Authorization - декодирует базу64 - валидирует логин/пароль - возвращает 401 Unauthorized, если аутентификация не прошла Пример (упрощённо): 1) Извлекаем заголовок 2) Проверяем, что он начинается с Basic 3) Декодируем base64 4) Сравниваем с нужными учётками Для Django-view это можно обернуть в декоратор и использовать так:

    
        
@basic_auth_required
def my_view(request):
    …
{}
    

Плюсы – очень лёгкий способ защитить API – работает без дополнительных библиотек – гибко настраивается Минусы – нет сессий, токенов, CSRF и других продвинутых схем – подходит только под HTTPS – пароль передаётся в каждом запросе Кому полезно Если нужен простой API или внутренняя служба, где полноценный OAuth/JWT: https://adamj.eu/tech/2025/12/08/django-basic-authentication/

🖥 Django 6.0 вышел - крупное обновление фреймворка Вышел Django 6.0, и это одно из самых насыщенных обновлений за последнее время. Релиз добавляет функциональность, которую разработчики долго закрывали сторонними библиотеками или кастомными решениями. Что нового и действительно важно: Поддержка template partials из коробки Теперь Django умеет частичные шаблоны на уровне фреймворка. Это упрощает структуру HTML, повышает переиспользуемость и делает шаблоны чище и понятнее без лишних include-хаков. Нативный фреймворк для фоновых задач В Django появился встроенный механизм для background tasks. Для многих проектов это означает, что Celery или RQ больше не обязательны для базовых задач — отложенные и асинхронные операции можно реализовать стандартными средствами. Встроенная система Content Security Policy (CSP) Django 6.0 получил полноценную поддержку CSP. Это серьёзный шаг в сторону безопасности по умолчанию и защита от XSS и других атак без внешних middleware. Современный email API с нормальной Unicode-поддержкой Работа с email стала более предсказуемой и дружелюбной к Unicode, что особенно важно для международных проектов и сложных шаблонов писем. Жизненный цикл версий Django 5.2 больше не имеет mainstream-поддержки. Разработчикам рекомендуется переходить на 6.0, чтобы получать новые возможности, обновления безопасности и улучшения платформы. Django продолжает двигаться в сторону «batteries included», но делает это аккуратно и прагматично. Django 6.0 снижает зависимость от внешних библиотек, усиливает безопасность и делает повседневную разработку заметно удобнее. Это релиз, который стоит внимательно изучить и запланировать апгрейд. https://www.djangoproject.com/weblog/2025/dec/03/django-60-released/

📌 Первые впечатления от системы фоновых задач в Django В свежем разборе объясняется, как Django наконец получает встроенный инструмент для фоновой обработки заданий без необходимости тянуть сторонние библиотеки вроде Celery. 🔹 Что это такое Django Background Tasks - новый официально поддерживаемый механизм для: - отложенного выполнения задач (delayed jobs), - периодических задач (cron-style), - асинхронной фоновой обработки в рамках приложения. 🔹 Почему это важно Раньше разработчикам приходилось выбирать сторонние решения (Celery, RQ, Dramatiq) с дополнительной инфраструктурой (Redis/RabbitMQ и т.п.). Теперь у Django будет собственный, простой и интегрированный способ: - выполнять задачи после ответа пользователю, - обрабатывать тяжёлые операции вне запроса, - запускать периодические задачи без внешних кронов. 🔹 Как это работает - Вы определяете задачу как обычную Python-функцию. - Django регистрирует её в очереди внутреннего раннера. - Фоновый воркер выполняет такие задачи по расписанию или сразу - без внешнего брокера. 🔹 Плюсы по сравнению с альтернативами ✔ встроенная интеграция с ORM и Django-экосистемой ✔ нет необходимости настраивать отдельный брокер ✔ ожидаемая простота и знакомый синтаксис для Django-разработчиков 🔹 О чём ещё в статье - примеры кода с определением фоновых задач; - как запускать и мониторить воркеры; - ограничения и когда всё же стоит использовать более мощные системы. 📌 В сумме: Django делает шаг к тому, чтобы базовая фонвая обработка стала простой и доступной из коробки - это ускоряет разработку и снижает операционную сложность для большинства проектов. https://roam.be/notes/2025/a-first-look-at-djangos-new-background-tasks/