Everything you wanted to know
about the Django framework

Анти-шаблон local_settings.py

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

# Внимание! Это анти-паттерн
try:
    from .local_settings import *
except ImportError:
    pass

Что означает использование файла local_settings.py для хранения локальных настроек проекта, в то время как сам файл занесен в игнор-список системы контроля версий (например в .hgignore или .gitignore). В таком случае локальный проект в стадии разработки использует исполняемый код вне системы контроля версий.

Если вам такой подход кажется неправильным, то вы на верном пути.

Лучше будет включить локальные настройки, секретный ключ и другие настройки в переменные окружения. Если же переменные окружения вам не подходят, то можно использовать в качестве хранилищ своих настроек файлы в форматах JSON, XML, YAML или те форматы представления данных, которые вам нравятся.

Что может случится, если использовать анти-паттерн local_settings в своем проекте, спросите вы?

Анти-паттерн local_settings

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

Но это перкрасно у меня работает!

То, что работает локально и успешно проходит тесты, может генерировать мелкие ошибки, которые не будут обнаружены, пока не станет слишком поздно. Вот пример того, что может случиться (с чем автор столкнулся в работе):

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

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

  • тесты не учитывали крайние случаи в новой библиотеке.

  • стал использоваться в локальной разработке, а также на рабочем сервере.

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

  • никто не может понять, почему рабочий проект ведет себя по-другому.

Первое, что было проверено — этот печальный кусок (именно кусок, а не часть) кода в настройках модуля:

# Внимание! Это анти-паттерн
try:
    from .local_settings import *
except ImportError:
    pass

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

И что действительно плохо, так это то, что серьезные ошибки не удается отладить вначале, потому что перенесенный код не соответствует коду из local_settings.py.

Но я не ошибаюсь!

Люди часто говорят: «Я не так глуп, как другие и не совершу такую ошибку».

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

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

Учитывая все это, почему бы не сделать умную вещь и не включить весь исполняемый код в управление версиями? А уникальные, секретные данные и ключи можно перенести в переменные окружения или файлы конфигурации. Готово!

Как обрабатывать конкретные переменные

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

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

# Хороший код!
from django.core.exceptions import ImproperlyConfigured

def get_env_var(var_name):
    try:
        return os.environ[var_name]
    except KeyError:
        error_msg = f"Set the {var_name} environment variable"
        raise ImproperlyConfigured(error_msg)

SECRET_KEY = get_env_var("SECRET_KEY")

Перевод статьи https://www.pydanny.com/using-executable-code-outside-version-control.html

Поделитесь с другими:

Представления-классы
(Class-Based Views)

Детальное описание и структура классов Django.

Добавление пользовательской аутентификации в Django

Нам необходимо добавить пользовательский бэкенд аутентификации в наш проект Django. Механизм аутентификации по умолчанию в Django требует, чтобы пользователь предоставил имя пользователя и пароль. Рассмотрим сценарий, в котором вы создаете банковское приложение. У каждого клиента есть customer_id. Возможно, вы захотите поддержать аутентификацию клиента с помощью имени пользователя и customer_id.

Выпущены релизы безопасности Django: 3.0.3, 2.2.10 и 1.11.28

В соответствии с политикой безопасности, команда Django выпускает Django 3.0.3, Django 2.2.10 и Django 1.11.28. Эти выпуски решают проблему безопасности, подробно описанную ниже. Мы призываем всех пользователей Django обновиться как можно скорее.

Релиз исправления Django: 3.0.2

Сегодня выпущен релиз исправления ошибок Django 3.0.2. Пакет релиза и контрольные суммы доступны на странице загрузок, а также из индекса пакетов Python. Идентификатор ключа PGP, использованный в этом выпуске: Mariusz Felisiak: 2EF56372BA48CD1B.

Как переключиться на пользовательскую модель User в существующем проекте

Документация по Django рекомендует всегда начинать ваш проект с пользовательской модели User (даже если она идентична Django с самого начала), чтобы упростить настройку позже, если вам нужно. Но что делать, если вы не видели этого при запуске проекта, или если вы унаследовали проект без пользовательской модели User, и вам нужно добавить ее?

Выпущены релизы безопасности Django: 3.0.1, 2.2.9 и 1.11.27

В соответствии с политикой безопасности, команда Django выпускает Django 3.0.1, Django 2.2.9 и Django 1.11.27. Эти выпуски решают проблему безопасности, подробно описанную ниже. Мы призываем всех пользователей Django обновиться как можно скорее.

Django: WebSocket`ы и Channels

WebSockets — это технология, которая позволяет открывать сеанс интерактивной связи между браузером пользователя и сервером. С помощью этой технологии пользователь может отправлять сообщения на сервер и получать управляемые событиями ответы, не требуя длительного опроса, то есть без необходимости постоянно проверять сервер на предмет ответа. Подумайте, когда вы отвечаете на электронное письмо в Gmail, и в нижней части экрана вы видите всплывающее предупреждение «1 непрочитанное сообщение от [...]» от человека, на которого вы только что отвечали. Такая обратная связь в режиме реального времени обусловлена такими технологиями, как WebSockets!

Выпуск Django 3.0

Команда Django рада объявить о выпуске Django 3.0: движение к тому, чтобы сделать Django полностью асинхронным, предоставляя поддержку для работы в качестве приложения ASGI, теперь официально поддерживает MariaDB 10.1 и выше, а также много других новых функций и возможностей.

Выпущены релизы безопасности Django: 2.2.8 и 2.1.15

В соответствии с политикой безопасности, команда Django выпускает Django 2.2.8 и Django 2.1.15. Этот выпуск решает проблему безопасности, подробно описанную ниже. Мы призываем всех пользователей Django обновиться как можно скорее.

Путь от request до response в Джанго

Веб-приложение или веб-сайт вращаются вокруг цикла запрос-ответ, и приложения Django не являются исключением. Но это не просто двухэтапный процесс. Наши приложения Django должны пройти различные стадии, чтобы вернуть конечному пользователю результат. Чтобы лучше понять структуру Django, мы должны понимать, как инициируются запросы и как конечный результат передается конечному пользователю. В статье объясняются различные этапы запросов и используемое там программное обеспечение или код.

Выпущен релиз-кандидат Django 3.0

Кандидат 1 релиза Django 3.0 - это последняя возможность для вас испытать множество новых функций перед выпуском Django 3.0.