Django

Предисловие

Для написания данной статьи был изучен очень большой пласт материала, разбросанного по всему Интернету, по форумам, чатам, сайтам-блогам, stackoverflow. Я собрал все воедино, так как это пригодится и мне и очень надеюсь, что другие разработчики на Django, также, останутся довольны данным материалом. Если есть что добавить (улучшить) или поправить, пожалуйста, пишите в комментариях или в Диалоги ( личные сообщения ) Хабр.

Тестирование handler 404

Если мы попытаемся тестировать ошибку 404 при заданном debug = True, то будет получать стандартный для Django отчет об ошибке с указанием о причине, но используя следующий метод вы сможете проверить работоспособность отработки 404 ошибки без лишних забот. На работающем сайте настоятельно рекомендую использовать nginx.

1. Открываем для редактирования файл settings.py, находящийся в каталоге проекта и устанавливаем значение debug = False

2. В том же каталоге открываем для редактирования файл urls.py и добавляем следующие строки:

from django.urls import re_pathfrom django.views.static import serve #добавляем в заголовкеre_path(r'^media/(?P<path>.*)$', serve, {'document_root': settings.MEDIA_ROOT}),re_path(r'^static/(?P<path>.*)$', serve, {'document_root': settings.STATIC_URL}),

При переключении debug в значение false, мы по умолчанию теряем статику и медиа, но используя данный метод, django продолжить обрабатывать эти данные вместо nginx, к примеру, а также, позволяет проверить отработку 404 или других ошибок в Django при работе на localhost, например при python manage.py runserver .

Формсеты и динамическое добавление форм

Для подготовки этого материала ушло достаточно много времени, сотни незакрытых вкладок в поисках полезной информации, а так множество вопросов в чатах разработчиков на Python/Djangoи даже появился на светсайт для создания резюмес динамическим добавлением полей формы, где представлен и используетсяданный функционал.
(Демо учетная запись:
Логин: habrhabr
Пароль: pp#6JZ2\a7y=

Стояла у меня такая задача: отображать форму, а по нажатию на кнопку добавлять дополнительные экземпляры данной формы.

Для этих целей создал несколько моделей вида, где Worker - это FK для Experience:

class Worker(models.Model):    public_cv = models.BooleanField(default=False, verbose_name='Can everyone see your resume ?')    cv_name = models.CharField(max_length=250, verbose_name='CV name', blank=True)    author = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE, verbose_name='Author', default=0)# +много других полей    def __str__(self):        return self.name    def publish(self):        self.published_date = timezone.now()        self.save()class Experience(models.Model):    worker = models.ForeignKey(Worker, on_delete=models.CASCADE)    title = models.CharField(max_length=200, verbose_name='Position name')# +много других полей    def __str__(self):        return self.title    def publish(self):        self.published_date = timezone.now()        self.save()# +много других моделей

Следующим шагом, который приближал меня к цели - реализовать желаемое сначала в административной панели django-admin, для этого я использовал StackedInline:

class ExperienceInstance(admin.StackedInline):    model = Experience    extra = 1@admin.register(Worker)class PublishWorkers(admin.ModelAdmin):    inlines = [        ExperienceInstance,]

И получим желаемый вид пока что в Django-admin, создается пустая форма Experience связанная с Worker и кнопка "Добавить форму Experience":

Теперь нужно добавить во views.py код, который позволит выводить форму Experience отдельно и по нажатии кнопки создавать дополнительный экземпляр формы Experience, будем использовать Formset:

from django.forms import inlineformset_factoryfrom django.http import HttpResponseRedirectfrom .forms import ExperienceFormdef expformview(request, worker_uid):    worker = Worker.objects.get(uid=worker_uid)    ExperienceFormset = inlineformset_factory(        Worker, Experience, form=ExperienceForm, extra=1, max_num=15, can_delete=True    )    if request.method == 'POST':        formset = ExperienceFormset(request.POST, instance=worker)        if formset.is_valid():            formset.save()            return HttpResponseRedirect(request.META.get('HTTP_REFERER'))    formset = ExperienceFormset(instance=worker)    return render(request, 'site/expform.html',                  {                      'formset': formset,                      'worker': worker,                  }                  )

Также, создадим Форму в forms.py ExperienceForm:

class ExperienceForm(forms.ModelForm):    started = forms.DateField(        required=False,        label='Start date',        widget=forms.TextInput(attrs={'placeholder': 'YYYY-MM-DD'})    )    ended = forms.DateField(        required=False,        label='End date',        widget=forms.TextInput(attrs={'placeholder': 'YYYY-MM-DD'})    )    class Meta:        model = Experience        fields = ('title',                  'selfedu',                  )

Далее шаблон HTML. Я использую Crispy для лучшего отображения полей форм. {{formset.media}} нужен для вывода WYSIWYG-редактора ckeditor. При нажатии на кнопку с type="submit" данные текущей формы сохраняются в базы и снизу добавляется еще один, но пустой экземпляр формы:

{% extends 'site/base.html' %}{% load crispy_forms_tags %}{% block content %}{% if worker.author == request.user%}<html lang="en">   <head>      <meta charset="UTF-8">      <meta name="viewport" content="width=device-width, initial-scale=1.0">      <meta http-equiv="X-UA-Compatible" content="ie=edge">      <title>Experience | {{worker}}</title>   </head>   <body>      <center>         <div class="col-lg-5" style="margin:1em;">            <nav aria-label="breadcrumb">               <ol class="breadcrumb">                   <li class="breadcrumb-item">Basic information</li>                   <li class="breadcrumb-item active" aria-current="page"><b>Experience</b></li>                   <li class="breadcrumb-item">Education</li>                   <li class="breadcrumb-item">Certification</li>                   <li class="breadcrumb-item">Awards</li>                   <li class="breadcrumb-item">Projects</li>               </ol>            </nav>         </div>      </center>   <h2 align="center" style="margin:1em;">{{worker}}'s Experience form</h2>      <form method="post">         {% csrf_token %}         <div class="row" style="margin:2em 0 2em 0;">            <div class="col-lg-5 mx-auto">               {{formset.media}}               {{formset|crispy}}            </div>             <div class="col-lg-12">                 <center><button type="submit" class="btn btn-outline-warning">Save & Add</button>                 <a href="edu"><button type="button" class="btn btn-outline-success">Next > Education</button></a></center>             </div>         </div>      </form>   </body></html>{%else%}      <div class="row">         <div class="col-lg-12" style="margin-top:6em;">            <center>               <h2>You have not access to this section</h2>            </center>         </div>      </div>      {%endif%}{% endblock %}

Так выглядит это на работающем сайте:

Экспорт данных в PDF с поддержкой кириллицы (русских букв)

Для экспорта данных, в данном случае страницы HTML в PDF мы будем использоватьXHTML2PDF; для его установки необходимо в venv запустить:

pip install xhtml2pdf

Далее добавляем следующий код в views.py:

from xhtml2pdf import pisadef render_pdf_view(request, worker_uid):    template_path = 'site/pdf.html'    worker = Worker.objects.get(uid=worker_uid)    exp = Experience.objects.filter(worker=worker)    context = {        'worker': worker,        'exp': exp,    }    response = HttpResponse(content_type='application/pdf')    response['Content-Disposition'] = 'filename="%s_%s.pdf"' % (worker.name, worker.created_date.strftime('%Y-%m-%d')) # правлю название выходного файла PDF вида: Имя_Год-М-Д    # Найти шаблон и вывести его    template = get_template(template_path)    html = template.render(context)    # Создаем PDF    pisa_status = pisa.CreatePDF(html, dest=response, )    # Вывод ошибок    if pisa_status.err:        return HttpResponse('We had some errors <pre>' + html + '</pre>')    return response

Шаблон HTML заполняем как обычный шаблон, но нужно учитывать, что парсер PDF видит только локальные стили, поэтому их нужно объявить между тегами <style></style> в данном шаблоне.

Чтобы русские символы корректно отображались в экспортируемом PDF необходимо загрузить шрифт с поддержкой кириллических (русских) букв и положить его в static/fonts/ , при этом указать до файла-шрифта полный путь с учетом системных каталогов, например в моем случае путь выглядит так:/var/www/cvmaker/static/fonts/arial.ttf , а между тегами <style/> добавляем следующее:

@font-face {         font-family: 'sans-serif';         src: url("/var/www/cvmaker/static/fonts/arial.ttf");         }         body{         font-family: "sans-serif";         }

Таким образом в экспортируемом PDF-файле мы видим вместо черных квадратиков на месте русских букв нормальные кириллические символы:

Проблемы в работе магазина

Я работаю в обычном велосипедном магазине в центре Варшавы. Торгуем как стационарно, так и в интернете. Среднее количество купленных велосипедов за день ~2 на весь год. При этом пик продаж приходится на лето и тогда в день можем иметь по ~17 интернет-заказов и столько же в магазине, а зимой не продавать вообще ничего.

В 2020г. в связи с пандемией COVID, спрос на велосипеды вырос до невероятных показателей, а мы, как порядочная контора, начали расширение.

Это привело к тому, что в конце прошлого сезона, заказы только несуществующих велосипедов участились в среднем до 4-х раз в неделю на протяжении 4-х самых продуктивных месяцев. А это ~16 несоответствий на сайте в месяц (не считая фейлы в магазине).

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

В конце концов, чтобы как-нибудь унять этот хаос мне было поручено создать EXСEL, куда впишутся все велосипеды со складов, чтобы примерно знать их расположение. Конечно же, я наплевал на таблицу. Хотя бы потому что при нынешней текучке продуктов она потеряет смысл недели через 2 и станет полностью неактуальной спустя 2-3 больших поставки.

Управление продуктами удаленно

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

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

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

Компоненты

Всю систему получилось разделить на три основных части:

1. Небольшая Python библиотека для взаимодействия с API PrestaShop;

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

3. Расширение Chrome для автоматического снятия проданного велосипеда во время выставления гарантийной карты. Да, на работе все время использовался только Chrome.

Все запросы проходят через некий middle-сервер, который и связывается с сайтом для взаимодействия. Теперь обо всем вкратце и по порядку.

Главный модуль для работы с API PrestaShop

Способов взаимодействия с API PrestaShop на Python не так много, наверное, потому что PS занимает только 5% рынка (а версия 1.6 и того меньше). Нашлась всего одна полноценная библиотека prestapyt, что само по себе большая редкость для Питона. Возможно, она сэкономила бы мне пару ночей, но попробовать свое решение хотелось не меньше чем быстрее это запустить.

Так как выбора особо и не было, а заняться было нечем, я приступил к анализу API, документациям и изучению работы PS. Спустя пару дней создался скрипт, который имел в себе самые базовые функции типа поиска продуктов и изменение их количества, да и работал умеренно быстро.

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

Код на Git

Алгоритм поиска продукта по комбинациям

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

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

Исходя из этого получился следующий алгоритм:

1. Получаем ссылку на комбинацию используя фильтр по reference коду;

2. Из нужной комбинации ссылку на карточку продукта;

3. Дальше, из карточки продукта, ссылку на stock_availables. Получится некий массив ссылок;

4. Проходим циклом по всех ссылках в associations и ищем ту же комбинацию.

5. Получаем ссылку на стоки, проверяем наличие и, если оно > 0 удаляем единицу товара. Если нет выкидываем предупреждение, что товар закончился.

6. В завершение отправляем отредактированный XML на тот же адрес stock_availables, из которого это все и было получено.

Похоже на такую себе рекурсию от комбинации аж до общего количества.

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

Взаимодействие с API

Доступ к главной странице начинается со ссылки вида https://domain.com/api. Здесь можно посмотреть, какие разделы доступны авторизованному юзеру. А проверяется это попытками найти id раздела например, тег products в теле ответа. Совпадение обозначает, что раздел доступен конкретному ключу.

Общение через API происходит на языке XML, а схемы запросов выглядят примерно так:

<prestashop><api shopName="myshop"><addresses xlink:href="http://personeltest.ru/aways/domain.com/api/addresses" get="true" put="false" post="false" delete="false" head="false"></addresses></api></prestashop>

Следующий сегмент ссылки - это название раздела. Пример получения продуктов https://domain.com/api/products:

<prestashop>  <products>    <product id="22" xlink:href="http://personeltest.ru/aways/domain.com/api/products/22"/>    <product id="24" xlink:href="http://personeltest.ru/aways/domain.com/api/products/24"/>    <product id="265" xlink:href="http://personeltest.ru/aways/domain.com/api/products/265"/>    <product id="294" xlink:href="http://personeltest.ru/aways/domain.com/api/products/294"/>  <products /><prestashop />

Отобразятся ссылки на карточки продуктов.

Для формирования и непосредственной отправки запросов скрипт использует requests. Удобная штука, хоть и работает относительно медленно Requests потому что я работал с ней раньше, она хорошо документирована и с ней просто приятно иметь дело.

Авторизация

API PS использует Basic авторизацию только по ключу (без пароля). Поэтому запрос получается до невозможности прост. Логин средствами requests:

request_url = https://domain.com/apiget_combination_xml = requests.get(request_url, auth=(self.api_secret_key, ''))

Получаем ответ 200, и тело ответа, содержащее всю страницу в XML. Теперь можно распарсить ее на отдельные теги и поискать нужные значения в них.

Парсинг XML ответа

Здесь ситуация выглядела лучше нашлась библиотека xml.etree. Отлично документированный инструмент, который через пару минут после импорта уже выдает все, что нужно (а много и нужно), а работать с целым телом ответа можно так же, как и с обычным словарем Python.

Достанем ссылку на подкатегорию из полученного ответа:

# Импортируем все необходимое в 2 строчкиfrom xml.etree import ElementTree as ETfrom xml.etree.ElementTree import ElementTree# Экземпляр xml.etreedef xml_data_extractor(data, tag):# data  XML данные# tag = products тег для поиска в деревеtry:xml_content = ET.fromstring(data.content) # Экземпляр класса ElementTree. Принимает строку в качестве аргумента. В моем случае тело ответа.general_tag = xml_content[0] # Получаем родительский тег  он всегда первыйtag = general_tag.find(tag) # Ищем заданный тегtag_inner_link = tag.get('{http://www.w3.org/1999/xlink}href') # Ищем ссылку в теге# Так же можно искать подстроку href в каждом ключе и получать значение после совпадения # Возвращаем внутреннюю ссылку в виде словаряproduct_meta = {'product_link': tag_inner_link}  return product_metaexcept:return None

Результат: https://domain.com/api/products. Все просто, но работает.

Большинство функций возвращают None в блоке except и словарь в блоке Try. Не знаю, хорошо ли это, но знаю, что это можно улучшить, чтобы не было такого разброса типов.

Фильтры поиска PS

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

Ссылка для запроса с фильтром для комбинаций выглядит так:

https://domain.com/api/combinations/?filter[reference]=reference, где reference код искомого продукта.

Сам код - это штрих-код, наклеенный на коробке и выглядит примерно так: KRHE1Z26X14M200034.

Дальше идут некоторые специфические функции и приватные методы, которые более подробно описаны в документации. Да! У этого куска кода есть документация на Git:

Структура библиотеки

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

def __init__(self, api_secret_key, request_url=None, **kwargs):try:self.api_secret_key = str(api_secret_key) #!API key is necessary!self.api_secret_key_64 = base64.b64encode((self.api_secret_key + ':').encode())    except:raise TypeError('The secret_key must be a string!')  # Main path to working directoryself.base_dir = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))self.request_url = request_urlself.kwargs = kwargs.items()#product meta to returnself.name = Noneself.total_quantity = Noneself.w_from = Noneself.w_to = Noneself.date = str(datetime.datetime.now().strftime("%d-%m-%Y, %H:%M"))

Далее идут приватные методы: _xml_data_extractor(), _wd() и даже кастомный _logging(), который пишет все совершенные операции вне зависимости от результата. Можно задать свое имя лог-файла.

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

Обработка запросов и middle-сервер

Для взаимодействия приложения и расширения со скриптом из любой точки мира магазина нужен был сервер c поддержкой Python. Сначала это выглядело как проблема, но я кое-что попробовать. Поднять WSGI-сервер на хостинге, конечно же!

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

Однако, нашлось еще более скостылизированное решение. У меня есть блог, запущенный на Django, а если посмотреть под другим углом отличный middle-сервер, способный обрабатывать множество запросов и уже настроен и готов к работе.

Создав еще одно приложение, подключил библиотеку, настроил какой-никакой контроль доступа к странице и вот он тестовый запуск.

Отлично! Запрос по ссылке https://palachintosh.com/xxx/xxx/? (без параметров) обработался и выдал результат об ошибке, так как нет ни токена, ни номера рамы. Просто пустой запрос.

Пробуем запрос с параметрами /?code=1122334455&token=IUFJ44KPQE342M3M109DNWI (код тестового продукта):

Вернулся словарь success значит, запрос обработался, количество продуктов уменьшилось и на складе, и в доступных для продажи, все записалось в лог-файл и вообще работает. Уже можно слать запросы с реальными номерами рам.

Контроль доступа

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

Логика проста токен совпадает продолжаем операцию. Токен не совпадает прерываем транзакцию еще на начальном этапе как-то так:

token = Nonewith open(token.txt) as file_t:token = file_t[0]if token == str(request.GET.get(token))://Вызываем обработчикreturn JsonResponse({Error: Invalid token})

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

Расширение Chrome и первые две кнопки

Расширение содержит набор функций для определения нужной страницы, отправки запроса, стилизации некоторых окон и т.д.

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

Самым сложным этапом оказалась работа с политикой CORS. На сервере пришлось добавить отдельную функцию, которая добавляет заголовки Access-Control-Allow-Origin. Без него, в случае кроссдоменных запросов срабатывает защита и сразу сбрасывает соединение еще на этапе запроса OPTIONS.

Проблема решилась определением во views.py функции def options(self, request). Она просто проверяет заголовки и отдает допустимые заголовки для совершения полноценного GET запроса.

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

Алгоритм расширения

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

Если вписать существующий номер рамы, то все поля заполнятся данными из реестра на стороне производителя. В поле Kod roweru появится тот самый код, который характеризует все одинаковые велосипеды.

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

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

var interval;functionmain_interval(){clearInterval(interval);  interval=setInterval(function(){href=window.location.hrefif(href.indexOf('https://24.kross.pl/warranty/new')>=0||href.indexOf('id_product=')>=0){if(href.indexOf('id_product=')>=0){prestaCheck();clearInterval(interval);}if(href.indexOf('https://24.kross.pl/warranty/new')>=0){location.reload();get_buttons();}}if(href.indexOf('https://24.kross.pl/bike-overview/new')>=0){clearInterval(interval);check_all();}},1000);}

Конечный код получения данных формы выглядит так:

// onclick or enter events function getFormData() {    var getForm = document.forms[0];    if (getForm != null) {        if (getForm.hasChildNodes("sku") && getForm.sku != null){            var code = String(getForm.sku.value);        }        if (getForm.hasChildNodes("bike_model") && getForm.bike_model != null) {            edit_msg = document.querySelector(".message-container > span > h1");            edit_msg.innerText = "Rower " + String(getForm.bike_model.value) + " zostanie usunity ze stanw!";        }        if (code != null && getForm.serial_number != null) {            sendRequest(code);        }    }}

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

vargetBodyBlock=document.querySelector('body');varalert_div=document.createElement('div');alert_div.innerHTML='<divclass="alert-message"><divclass="message-container">\<span><h1></h1></span>\<divclass="inner-buttons">\<buttonid="btnYes"class="ant-btnant-btn-danger">Potwierdzam!</button>\<buttonid="btnReserve"class="ant-btnant-btn-danger">Zdjrezerwacj</button>\<buttonid="btnNo"class="ant-btnant-btn-success">Nieteraz</button>\</div></div></div>';loader=document.createElement('div');getBodyBlock.appendChild(alert_div);

Ссылка на репозиторий: https://github.com/palachintosh/shop_extension

Самая страшная часть Android-приложение

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

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

Работа приложения (ничего интересного)

Приложение имеет 3 страницы. Сначала выбираются названия складов и количество переносимого товара, а дальше:

• Либо код сканится, если он не поврежден.

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

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

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

Кнопки в приложении

Main Activity содержит всего 3 метода onCreate, scanCode, enterCode и описывают кнопки, которые запускают другие активити:

protected void onCreate(Bundle savedInstanceState) {    super.onCreate(savedInstanceState);    setContentView(R.layout.activity_main);    Spinner fromSpinner = (Spinner) findViewById(R.id.fromSpinner);    Spinner toSpinner = (Spinner) findViewById(R.id.toSpinner);    ArrayAdapter<String> adapter = new ArrayAdapter<String> (            this, android.R.layout.simple_spinner_item, warehouses);    adapter.setDropDownViewResource(android.R.layout.simple_spinner_dropdown_item);    fromSpinner.setAdapter(adapter);    toSpinner.setAdapter(adapter);}public void scanCode(View view) {    Intent intent = new Intent(MainActivity.this, Scan.class);    Spinner get_w_from = (Spinner) findViewById(R.id.fromSpinner);    Spinner get_w_to = (Spinner) findViewById(R.id.toSpinner);    EditText editText = (EditText) findViewById(R.id.prodctQuantity);    String quantity_tt = editText.getText().toString();    RequestData requestData = new RequestData(            get_w_from.getSelectedItem().toString(),            get_w_to.getSelectedItem().toString(),            quantity_tt);    intent.putExtra(RequestData.class.getSimpleName(), requestData);    startActivity(intent);}

Закладка Enter Code отвечает за ручной ввод реферального кода. Скажем, если наклейка повреждена. Здесь все просто вписываем и отправляем.

Scan Code переключается на Activity co сканнером, а обрабатываются изображения библиотекой Barcode Scanner от Google.

Send Code отправляющая код на сервер. Обработчик получает данные из текстового поля сканнера или инпута из активити ручного заполнения, валидирует его и передает данные обработчику отправки запроса. А Retrofit делает все остальное. Приложение, пока что, самая недопиленная часть сказывается плохое знание Java и отсутствие опыта разработки под Android в целом, но я пытаюсь исправиться.

Код приложения на github: https://github.com/palachintosh/product_control.git

Как это выглядело раньше

Раньше процесс управления продуктами выглядел так:

• Когда приезжала большая доставка продукты добавлялись на сайт вручную с накладной;

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

• Нужно было как-то мониторить склады, с которых коробки приезжают и стараться это обновлять по мере возможности.

Как это выглядит сейчас:

• Когда приезжает доставка сканируются либо штрих-коды на накладной, либо каждая коробка;

• Во время продажи подтверждается действие удаления единицы продукта;

• Когда коробки мигрируют со склада на склад в приложении выбираются склады и отправляется отсканированный код.

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

Выводы

Если посчитать все обязательные кнопки, то получается, что их реально 5:

1. Отправка запроса с сайта производителя чтобы снять продукт.

2. Отмена отправки запроса (если велосипед был продан через интернет, тогда этим управляет PrestaShop).

3. Кнопка "Enter code" в приложении.

4. Кнопка "Scan code".

5. Отправка запроса в приложении "Send Code".

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

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

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

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

Людям, посмотревшим репозитории или вообще прочитавшим это буду благодарен за конструктивные комментарии и критику.

Prologue

- Глянь, статью на Хабр подготовил.
- Эм... а почему заголовок на английском?
- "Предметно-ориентированное проектирование, Гексагональная архитектура портов и адаптеров, Внедрение зависимостей и Пайто..."

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

Intro

Как же летит время! Два года назад я расстался с миром Django и очутился в мире Kotlin, Java и Spring Boot. Я испытал самый настоящий культурный шок. Голова гудела от объёма новых знаний. Хотелось бежать обратно в тёплую, ламповую, знакомую до байтов экосистему Питона. Особенно тяжело на первых порах давалась концепция инверсии управления (Inversion of Control, IoC) при связывании компонентов. После прямолинейного подхода Django, автоматическое внедрение зависимостей (Dependency Injection, DI) казалось чёрной магией. Но именно эта особенность фреймворка Spring Boot позволила проектировать приложения следуя заветам Чистой Архитектуры. Самым же большим вызовом стал отказ от философии "пилим фичи из трекера" в пользу Предметно-ориентированного проектирования (Domain-Driven Design, DDD).

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

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

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

Dependency Injection

Вы знаете что такое Внедрение зависимостей ака Dependency Injection (DI). Точно знаете, хотя можете и не вспомнить формального определения. Давайте на небольшом примере рассмотрим, в чём плюсы и минусы этого подхода (если вам угодно - шаблона).

Допустим нам понадобилась функция, отправляющая сообщения с пометкой "ТРЕВОГА!" в шину сообщений. После недолгих размышлений напишем:

from my_cool_messaging_library import get_message_bus()def send_alert(message: str):    message_bus = get_message_bus()    message_bus.send(topic='alert', message=message)

В чём главная проблема функции send_alert()? Она зависит от объекта message_bus, но для вызывающего эта зависимость совершенно не очевидна! А если вы хотите отправить сообщение по другой шине? А как насчёт уровня магии, необходимой для тестирования этой функции? Что, что? mock.patch(...) говорите? Коллеги, атака в лоб провалилась, давайте зайдём с флангов.

from my_cool_messaging_library import MessageBusdef send_alert(message_bus: MessageBus, message: str):    message_bus.send(topic='alert', message=message)

Казалось, небольшое изменение, добавили аргумент в функцию. Но одним лишь этим изменением мы убиваем нескольких зайцев: Вызывающему очевидно, что функция send_alert() зависит от объекта message_bus типа MessageBus (да здравствуют аннотации!). А тестирование, из обезьяньих патчей с бубном, превращается в написание краткого и ясного кода. Не верите?

def test_send_alert_sends_message_to_alert_topic()    message_bus_mock = MessageBusMock()    send_alert(message_bus_mock, "A week of astrology at Habrahabr!")    assert message_bus_mock.sent_to_topic == 'alert'    assert message_bus_mock.sent_message == "A week of astrology at Habrahabr!"class MessageBusMock(MessageBus):    def send(self, topic, message):        self.sent_to_topic = topic        self.sent_message = message

Тут искушённый читатель задастся вопросом: неужели придётся передавать экземпляр message_bus в функцию send_alert() при каждом вызове? Но ведь это неудобно! В чём смысл каждый раз писать

send_alert(get_message_bus(), "Stackoverflow is down")

Попытаемся решить эту проблему посредством ООП:

class AlertDispatcher:    _message_bus: MessageBus    def __init__(self, message_bus: MessageBus):        self._message_bus = message_bus    def send(message: str):        self._message_bus.send(topic='alert', message=message)alert_dispatcher = AlertDispatcher(get_message_bus())alert_dispatcher.send("Oh no, yet another dependency!")

Теперь уже класс AlertDispatcher зависит от объекта типа MessageBus. Мы внедряем эту зависимость в момент создания объекта AlertDispatcher посредством передачи зависимости в конструктор. Мы связали (we have wired, не путать с coupling!) объект и его зависимость.

Но теперь акцент смещается с message_bus на alert_dispatcher! Этот компонент может понадобиться в различных местах приложения. Мало ли откуда нужно оправить сигнал тревоги! Значит, необходим некий глобальный контекст из которого можно будет этот объект достать. И прежде чем перейти к построению такого контекста, давайте немного порассуждаем о природе компонентов и их связывании.

Componential architecture

Говоря о внедрении зависимостей мы не сильно заостряли внимание на типах. Но вы наверняка догадались, что MessageBus - это всего лишь абстракция, интерфейс, или как бы сказал PEP-544 - протокол. Где-то в нашем приложении объявленo:

class MessageBus(typing.Protocol):    def send(topic: str, message: str):        pass

В проекте также есть простейшая реализация MessageBus-a, записывающая сообщения в список:

class MemoryMessageBus(MessageBus):    sent_messages = []    def send(topic: str, messagge: str):        self.sent_messages.append((str, message))

Таким же образом можно абстрагировать бизнес-логику, разделив абстрактный сценарий пользования (use case) и его имплементацию:

class DispatchAlertUseCase(typing.Protocol):    def dispatch_alert(message: str):        pass

class AlertDispatcherService(DispatchAlertUseCase):    _message_bus: MessageBus    def __init__(self, message_bus: MessageBus):        self._message_bus = message_bus    def dispatch_alert(message: str):        self._message_bus.send(topic='alert', message=message)

Давайте для наглядности добавим HTTP-контроллер, который принимает сообщения по HTTP-каналу и вызывает DispatchAlertUseCase:

class ChatOpsController:    ...    def __init__(self, dispatch_alert_use_case: DispatchAlertUseCase):        self._dispatch_alert_use_case = dispatch_alert_use_case    @post('/alert)    def alert(self, message: Message):        self._dispatch_alert_use_case.dispatch_alert(message)        return HTTP_ACCEPTED

Наконец, всё это необходимо связать воедино:

from my_favourite_http_framework import http_serverdef main():    message_bus = MemoryMessageBus()    alert_dispatcher_service = AlertDispatcherService(message_bus)    chat_opts_controller = ChatOpsController(alert_dispatcher_service)    http_server.start()

Первой же реакцией здорового программиста будет: "ну нафига громоздить столько кода?". Ваша правда, всё вышенаписанное умещается в одну коротенькую функцию:

@post('/alert)def alert(message: Message):    bus = MemoryMessageBus()    bus.send(topic='alert', message=message)    return HTTP_ACCEPTED

Коротко? Ещё как! Поддерживаемо? Вообще никак. Почему? Из-за сильнейшей связанности (coupling) компонентов в коде. Уместив всё в одну функцию таким образом, мы намертво привязали логику отправки оповещений к конкретной реализации шины сообщений. Но это ещё полбеды. Самое ужасное то, что бизнес-составляющая полностью растворилась в технических деталях. Не поймите меня неправильно, подобный код вполне имеет право на существование. Но простит ли растущее приложение такой сжатый подход?

Вернёмся к нашей компонентной архитектуре. В чём её преимущества?

• Компоненты изолированы и независимы друг от друга напрямую. Вместо этого они связаны посредством абстракций.

• Каждый компонент работает в чётких рамках и решает лишь одну задачу.

• Это значит, что компоненты могут быть протестированы как в полной изоляции, так и в любой произвольной комбинации включающей тестовых двойников (test double). Думаю не стоит объяснять, насколько проще тестировать изолированные части программы. Подход к TDD меняется с невнятного "нуууу, у нас есть тесты" на бодрое "тесты утром, вечером код".

• С учётом того, что зависимости описываются абстракциями, можно безболезненно заменить один компонент другим. В нашем примере - вместо MemoryMessageBus можно бухнуть DbMessageBus, да хоть в файл на диске писать - тому кто вызывает message_bus.send(...) нет до этого никакого дела.

"Да это же SOLID!" - скажите вы. И будете абсолютно правы. Не удивлюсь, если у вас возникло чувство дежавю, ведь благородный дон @zueve год назад детально описал связь SOLID и Чистой архитектуры в статье "Clean Architecture глазами Python-разработчика". И наша компонентная архитектура находится лишь в шаге от чистой "гексагональной" архитектуры. Кстати, причём тут гексагон?

Architecture is about intent

Одно из замечательных высказываний дядюшки Боба на тему архитектуры приложений - Architecture is about intent (Намерения - в архитектуре).

Что вы видите на этом скриншоте?

Не удивлюсь, если многие ответили "Типичное приложение на Django". Отлично! А что же делает это приложение? Вы вероятно телепат 80го уровня, если смогли ответить на этот вопрос правильно. Лично я не именю ни малейшего понятия - это скриншот первого попавшегося Django-приложения с Гитхаба.

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

Надеюсь вам было несложно отгадать эту маленькую загадку и вы вынесли из неё главное: архитектура должна встречать нас с порога, буквально с момента окончания git clone.... Как здорово, когда код приложения организован таким образом, что предназначение того или иного файла или директории лежит на поверхности!

В "Гексагональной архитектуре", гексагон в частности призван упростить восприятие архитектуры. Мудрено? Пардон, сейчас всё будет продемонстрировано наглядно.

Hexagonal architecture of Ports and Adapters

"У нас Гексагональная архитектура портов и адаптеров" - с этой фразы начинается рассказ об архитектуре приложения новым членам команды. Далее мы показываем нечто Ктулхуподобное:

Изобретатель термина "Гексагональная архитектура" Алистар Кокбёрн (Alistair Cockburn) объясняя выбор названия акцентировал внимание на его графическом представлении:

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

Итак, на изображении мы видим:

Домен (предметная область) - это сердце приложения. Классы, методы, функции, константы и другие объекты домена повторяют язык предметной области. Например, правило Хабра

"Пользователь может голосовать за публикации, комментарии и карму других пользователей если его карма 5"

будет отображено именно здесь. И как вы наверняка поняли, в домене нет места HTTP, SQL, RabbitMQ, AWS и т.д. и т.п.

Зато всему этому празднику технологий есть место в адаптерах подсоединяемых к портам. Команды и запросы поступают в приложение через ведущие (driver) или API порты. Команды и запросы которые отдаёт приложение поступают в ведомые порты (driven port). Их также называют портами интерфейса поставщика услуг (Service Provider Interface, SPI).

Между портами и доменом сидят дирижёры - сервисы приложения (Application services). Они являются связующим звеном между сценариями пользования, доменом и ведомыми портами необходимыми для выполнения сценария. Также стоит упомянуть, что именно сервис приложения определяет, будет ли сценарий выполняться в рамках общей транзакции, или нет.

Всё это - и порты, и адаптеры и сервисы приложения и даже домен - слои архитектуры, состоящие из индивидуальных компонентов. Главной заповедью взаимодействия между слоями является "Зависимости всегда направлены от внешних слоёв к центру приложения". Например, адаптер может ссылаться на домен или другой адаптер, а домен ссылаться на адаптер - не может.

И... ВСЁ. Это - вся суть Гексагональной архитектуры портов и адаптеров. Она замечательно подходит для задач с обширной предметной областью. Для голого CRUDа а-ля HTTP интерфейс для базы данных, такая архитектура избыточна - Active Record вам в руки.

Давайте же засучим рукава и разберём на примере, как спроектировать Django-приложение по канонам гексагональной архитектуры.

Interlude

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

Во второй части вас ждёт реализация гексагональной архитектуры на знакомом нам всем примере. В первой части мы старались абстрагироваться от конкретных решений, будь то фреймворки или библиотеки. Последующий пример построен на основе Django и DRF с целью продемонстрировать, как можно вплести гексагональную архитектуру в фреймворк с устоявшимися традициями и архитектурными решениями. В приведённых примерах вырезаны некоторые необязательные участки и имеются допущения. Это сделано для того, чтобы мы могли сфокусироваться на важном и не отвлекались на второстепенные детали. Полностью исходный код примера доступен в репозитории https://github.com/basicWolf/hexagonal-architecture-django.

Upvote a post at Hubruhubr

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

Рейтинг публикации меняется путём голосования пользователей.

1. Пользователь может проголосовать "ЗА" или "ПРОТИВ" публикации.

2. Пользователь может голосовать если его карма 5.

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

С чего же начать работу? Конечно же с построения модели предметной области!

Domain model

Давайте ещё раз внимательно прочтём требования и подумаем, как описать "пользователя голосующего за публикацию"? Например (source):

# src/myapp/application/domain/model/voting_user.pyclass VotingUser:    id: UUID    voting_for_article_id: UUID    voted: bool    karma: int    def cast_vote(self, vote: Vote) -> CastArticleVoteResult:        ...

На первый взгляд - сомнительного вида творение. Но обратившись к деталям сценария мы убедимся, что этот набор данных - необходим и достаточен для голосования. Vote и CastArticleVoteResult - это также модели домена (source):

# src/myapp/application/domain/model/vote.py# Обозначает голос "За" или "Против"class Vote(Enum):    UP = 'up'    DOWN = 'down'

В свою очередь CastArticleVoteResult - это тип объединяющий оговорённые исходы сценария: ГолосПользователя, НедостаточноКармы, ПользовательУжеПроголосовалЗаПубликацию (source):

# src/myapp/application/domain/model/cast_article_vote_result.py...CastArticleVoteResult = Union[ArticleVote, InsufficientKarma, VoteAlreadyCast]

Как вы думаете, каких данных достаточно для описания результата успешно выполненного сценария?

# src/myapp/application/domain/model/article_vote.py@dataclassclass ArticleVote:    user_id: UUID    article_id: UUID    vote: Vote    id: UUID = field(default_factory=uuid4)

Но самое интересное будет происходить в теле метода cast_article_vote(). И начнём мы конечно же с тестов. Первый же тест нацелен на проверку успешно выполненного сценария (source):

def test_cast_vote_returns_article_vote(user_id: UUID, article_id: UUID):    voting_user = VotingUser(        user_id=user_id,        voting_for_article_id=article_id,        karma=10    )    result = voting_user.cast_vote(Vote.UP)    assert isinstance(result, ArticleVote)    assert result.vote == Vote.UP    assert result.article_id == article_id    assert result.user_id == user_id

Запускаем тест и... ожидаемый фейл. В лучших традициях ТДД мы начнём игру в пинг-понг с тестами и кодом, с каждым тестом дописывая сценарий до полной готовности (source):

MINIMUM_KARMA_REQUIRED_FOR_VOTING = 5...def cast_vote(self, vote: Vote) -> CastArticleVoteResult1:    if self.voted:        return VoteAlreadyCast(            user_id=self.id,            article_id=self.voting_for_article_id        )    if self.karma < MINIMUM_KARMA_REQUIRED_FOR_VOTING:        return InsufficientKarma(user_id=self.id)    self.voted = True    return ArticleVote(        user_id=self.id,        article_id=self.voting_for_article_id,        vote=vote    )

На этом мы закончим моделирование предметной области и приступим к написанию API приложения.

Driver port: Cast article vote use case

Как было сказано ранее, в гексагональной архитектуре, приложение управляется через API-порты.

Чтобы как-то дотянуться до доменной модели, в наше приложение нужно добавить ведущий порт CastArticleVotingtUseCase, который принимает ID пользователя, ID публикации, значение голоса: за или против и возвращает результат выполненного сценария (source):

# src/myapp/application/ports/api/cast_article_vote/cast_aticle_vote_use_case.pyclass CastArticleVoteUseCase(Protocol):    def cast_article_vote(self, command: CastArticleVoteCommand) -> CastArticleVoteResult:        raise NotImplementedError()

Все входные параметры сценария обёрнуты в единую структуру-команду CastArticleVoteCommand (source), а все возможные результаты объединены - это уже знакомая модель домена CastArticleVoteResult (source):

# src/myapp/application/ports/api/cast_article_vote/cast_article_vote_command.py@dataclassclass CastArticleVoteCommand:    user_id: UUID    article_id: UUID    vote: Vote

Работа с гексагональной архитектурой чем-то напоминает прищурившегося Леонардо ди Каприо с фразой "We need to go deeper". Набросав каркас сценария пользования, можно примкнуть к нему с двух сторон. Можно имплементировать сервис, который свяжет доменную модель и ведомые порты для выполнения сценария. Или заняться API адаптерами, которые вызывают этот сценарий. Давайте зайдём со стороны API и напишем HTTP адаптер с помощью Django Rest Framework.

HTTP API Adapter

Наш HTTP адаптер, или на языке Django и DRF - View, до безобразия прост. За исключением преобразований запроса и ответа, он умещается в несколько строк (source):

# src/myapp/application/adapter/api/http/article_vote_view.pyclass ArticleVoteView(APIView):    ...    def __init__(self, cast_article_vote_use_case: CastArticleVoteUseCase):        self.cast_article_vote_use_case = cast_article_vote_use_case        super().__init__()    def post(self, request: Request) -> Response:        cast_article_vote_command = self._read_command(request)        result = self.cast_article_vote_use_case.cast_article_vote(            cast_article_vote_command        )        return self._build_response(result)    ...

И как вы поняли, смысл всего этого сводится к

1. Принять HTTP запрос, десериализировать и валидировать входные данные.

2. Запустить сценарий пользования.

3. Сериализовать и возвратить результат выполненного сценария.

Этот адаптер конечно же строился по кирпичику с применением практик TDD и использованием инструментов Django и DRF для тестирования view-шек. Ведь для теста достаточно построить запрос (request), скормить его адаптеру и проверить ответ (response). При этом мы полностью контролируем основную зависимость cast_article_vote_use_case: CastArticleVoteUseCase и можем внедрить на её место тестового двойника.

Например, давайте напишем тест для сценария, в котором пользователь пытается проголосовать повторно. Ожидаемо, что статус в ответе будет 409 CONFLICT (source):

# tests/test_myapp/application/adapter/api/http/test_article_vote_view.pydef test_post_article_vote_with_same_user_and_article_id_twice_returns_conflict(    arf: APIRequestFactory,    user_id: UUID,    article_id: UUID):    # В роли объекта реализующего сценарий выступает    # специализированный двойник, возвращающий при вызове    # .cast_article_vote() контролируемый результат.    # Можно и MagicMock, но нужно ли?    cast_article_use_case_mock = CastArticleVoteUseCaseMock(        returned_result=VoteAlreadyCast(            user_id=user_id,            article_id=article_id        )    )    article_vote_view = ArticleVoteView.as_view(        cast_article_vote_use_case=cast_article_use_case_mock    )    response: Response = article_vote_view(        arf.post(            f'/article_vote',            {                'user_id': user_id,                'article_id': article_id,                'vote': Vote.UP.value            },            format='json'        )    )    assert response.status_code == HTTPStatus.CONFLICT    assert response.data == {        'status': 409,        'detail': f"User \"{user_id}\" has already cast a vote for article \"{article_id}\"",        'title': "Cannot cast a vote"    }

Адаптер получает на вход валидные данные, собирает из них команду и вызывает сценарий. Oднако, вместо продакшн-кода, этот вызов получает двойник, который тут же возвращает VoteAlreadyCast. Адаптеру же нужно правильно обработать этот результат и сформировать HTTP Response. Остаётся протестировать, соответствует ли сформированный ответ и его статус ожидаемым значениям.

Ещё раз попрошу заметить, насколько облегчённее становится тестирование, когда не нужно загружать всё приложение целиком. Адепты Django вспомнят о легковесном тестировании вьюшек посредством RequestFactory. Но гексагональная архитектура позволяет шагнуть дальше. Мы избавились от обезьяньих патчей и mock-обёрток конкретных классов. Мы легко управляем поведением зависимостей нашего View, ведь взаимодействие с ними происходит через абстрактный интерфейс. Всё это легко модифицировать и отлаживать.

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

Application services

Как дирижёр управляет оркестром исполняющим произведение, так и сервис приложения управляет доменом и ведомыми портами при выполнении сценария.

PostRatingService

С места в карьер погрузимся в имплементацию нашего сценария. В первом приближении сервис реализующий сценарий выглядит так (source):

# src/myapp/application/service/post_rating_service.pyclass PostRatingService(    CastArticleVoteUseCase  # имплементируем протокол явным образом):    def cast_article_vote(self, command: CastArticleVoteCommand) -> CastArticleVoteResult:        ...

Отлично, но откуда возьмётся голосующий пользователь? Тут и появляется первая SPI-зависимость GetVotingUserPort задача которой найти голосующего пользователя по его ID. Но как мы помним, доменная модель не занимается записью голоса в какое-либо долговременное хранилище вроде БД. Для этого понадобится ещё одна SPI-зависимость SaveArticleVotePort:

# src/myapp/application/service/post_rating_service.pyclass PostRatingService(    CastArticleVoteUseCase):    _get_voting_user_port: GetVotingUserPort    _save_article_vote_port: SaveArticleVotePort    # def __init__(...) # внедрение зависимостей oпустим, чтобы не раздувать листинг    def cast_article_vote(self, command: CastArticleVoteCommand) -> CastArticleVoteResult:        voting_user = self._get_voting_user_port.get_voting_user(            user_id=command.user_id,            article_id=command.article_id        )        cast_vote_result = voting_user.cast_vote(command.vote)        if isinstance(cast_vote_result, ArticleVote):            self._save_article_vote_port.save_article_vote(cast_vote_result)        return cast_vote_result

Вы наверняка представили как выглядят интерфейсы этих SPI-зависимостей. Приведём один из интерфейсов здесь (source):

# src/myapp/application/ports/spi/save_article_vote_port.pyclass SaveArticleVotePort(Protocol):    def save_article_vote(self, article_vote: ArticleVote) -> ArticleVote:        raise NotImplementedError()

За кадром мы конечно же сначала напишем тесты, а уже потом код :) При написании юнит-тестов роль SPI-адаптеров в тестах сервиса, как и в предыдущих примерах, играют дублёры. Но чтобы удержать сей опус в рамках статьи, позвольте оставить тесты в виде ссылки на исходник (source) и двинуться дальше.

SPI Ports and Adapters

Продолжим рассматривать SPI-порты и адаптеры на примере SaveArticleVotePort. К этому моменту можно было и забыть, что мы всё ещё находимся в рамках Django. Ведь до сих пор не было написано того, с чего обычно начинается любое Django-приложение - модель данных! Начнём с адаптера, который можно подключить в вышеуказанный порт (source):

# src/myapp/application/adapter/spi/persistence/repository/article_vote_repository.pyfrom myapp.application.adapter.spi.persistence.entity.article_vote_entity import (    ArticleVoteEntity)from myapp.application.domain.model.article_vote import ArticleVotefrom myapp.application.ports.spi.save_article_vote_port import SaveArticleVotePortclass ArticleVoteRepository(    SaveArticleVotePort,):    def save_article_vote(self, article_vote: ArticleVote) -> ArticleVote:        article_vote_entity = ArticleVoteEntity.from_domain_model(article_vote)        article_vote_entity.save()        return article_vote_entity.to_domain_model()

Вспомним, что паттерн "Репозиторий" подразумевает скрытие деталей и тонкостей работы с источником данных. "Но позвольте! - скажете Вы, - a где здесь Django?". Чтобы избежать путаницы со словом "Model", модель данных носит гордое название ArticleVoteEntity. Entity также подразумевает, что у неё имеется уникальный идентификатор (source):

# src/myapp/application/adapter/spi/persistence/entity/article_vote_entity.pyclass ArticleVoteEntity(models.Model):    ... # здесь объявлены константы VOTE_UP, VOTE_DOWN и VOTE_CHOICES    id = models.UUIDField(primary_key=True, default=uuid4, editable=False)    user_id = models.UUIDField()    article_id = models.UUIDField()    vote = models.IntegerField(choices=VOTES_CHOICES)    ...    def from_domain_model(cls, article_vote: ArticleVote) -> ArticleVoteEntity:        ...    def to_domain_model(self) -> ArticleVote:        ...

Таким образом, всё что происходит в save_article_vote() - это создание Django-модели из доменной модели, сохранение её в БД, обратная конвертация и возврат доменной модели. Это поведение легко протестировать. Например, юнит тест удачного исхода выглядит так (source):

# tests/test_myapp/application/adapter/spi/persistence/repository/test_article_vote_repository.py@pytest.mark.django_dbdef test_save_article_vote_persists_to_database(    article_vote_id: UUID,    user_id: UUID,    article_id: UUID):    article_vote_repository = ArticleVoteRepository()    article_vote_repository.save_article_vote(        ArticleVote(            id=article_vote_id,            user_id=user_id,            article_id=article_id,            vote=Vote.UP        )    )    assert ArticleVoteEntity.objects.filter(        id=article_vote_id,        user_id=user_id,        article_id=article_id,        vote=ArticleVoteEntity.VOTE_UP    ).exists()

Одним из требований Django является декларация моделей в models.py. Это решается простым импортированием:

# src/myapp/models.pyfrom myapp.application.adapter.spi.persistence.entity.article_vote_entity import ArticleVoteEntityfrom myapp.application.adapter.spi.persistence.entity.voting_user_entity import VotingUserEntity

Exceptions

Приложение почти готово!. Но вам не кажется, что мы кое-что упустили? Подсказка: Что произойдёт при голосовании, если ID пользователя или публикации будет указан неверно? Где-то в недрах Django вылетит исключение VotingUserEntity.DoesNotExist, что на поверхности выльется в неприятный HTTP 500 - Internal Server Error, хотя правильнее было бы вернуть HTTP 400 - Bad Request с телом, содержащим причину ошибки.

Ответ на вопрос, "В какой момент должно быть обработано это исключение?", вовсе не очевиден. С архитектурной точки зрения, ни API, ни домен не волнуют проблемы SPI-адаптеров. Максимум, что может сделать API с таким исключением - обработать его в общем порядке, а-ля except Exception:. С другой стороны SPI-порт может предоставить исключение-обёртку, в которую SPI-адаптер завернёт внутреннюю ошибку. А API может её поймать.

О, я слышу вас, дорогие адепты функционального программирования! "Какие исключения? В топку! Даёшь Either!". В ваших словах много правды и эта тема заслуживает отдельной статьи. В одном я же, я полностью соглашусь с вами - в домене не должно быть исключений!.

Например, в данной ситуации уместным будет исключение VotingUserNotFound (source) в которое оборачивается VotingUserEntity.DoesNotExist (source):

# src/myapp/application/adapter/spi/persistence/exceptions/voting_user_not_found.pyclass VotingUserNotFound(Exception):    def __init__(self, user_id: UUID):        super().__init__(user_id, f"User '{user_id}' not found")# ---# myapp/application/adapter/spi/persistence/repository/voting_user_repository.pyclass VotingUserRepository(GetVotingUserPort):    ...    def get_voting_user(self, user_id: UUID, article_id: UUID) -> VotingUser:        try:            # Код немного упрощён, в оригинале здесь происходит            # аннотация флагом "голосовал ли пользователь за статью".            # см. исходник            entity = VotingUserEntity.objects.get(id=user_id)        except VotingUserEntity.DoesNotExist as e:            raise VotingUserNotFound(user_id) from e        return self._to_domain_model(entity)

А вот теперь действительно, приложение почти готово! Осталось соединить все компоненты и точки входа.

Dependencies and application entry point

Традиционно точки входа и маршрутизация HTTP-запросов в Django-приложениях декларируется в urls.py. Всё что нам нужно сделать - это добавить запись в urlpatterns (source):

urlpatterns = [    path('article_vote', ArticleVoteView(...).as_view())]

Но погодите! Ведь ArticleVoteView требует зависимость имплементирующую CastArticleVoteUseCase. Это конечно же PostRatingService... которому в свою очередь требуются GetVotingUserPort и SaveArticleVotePort. Всю эту цепочку зависимостей удобно хранить и управлять из одного места - контейнера зависимостей (source):

# src/myapp/dependencies_container.py...def build_production_dependencies_container() -> Dict[str, Any]:    save_article_vote_adapter = ArticleVoteRepository()    get_vote_casting_user_adapter = VotingUserRepository()    cast_article_vote_use_case = PostRatingService(        get_vote_casting_user_adapter,        save_article_vote_adapter    )    article_vote_django_view = ArticleVoteView.as_view(        cast_article_vote_use_case=cast_article_vote_use_case    )    return {        'article_vote_django_view': article_vote_django_view    }

Этот контейнер инициализируется на старте приложения в AppConfig.ready() (source):

# myapp/apps.pyclass MyAppConfig(AppConfig):    name = 'myapp'    container: Dict[str, Any]    def ready(self) -> None:        from myapp.dependencies_container import build_production_dependencies_container        self.container = build_production_dependencies_container()

И наконец urls.py:

app_config = django_apps.get_containing_app_config('myapp')article_vote_django_view = app_config.container['article_vote_django_view']urlpatterns = [    path('article_vote', article_vote_django_view)]

Inversion of Control Containers

Для реализации одного небольшого сценария нам понадобилось создать и связать четыре компонента. С каждым новым сценарием, число компонентов будет расти и количество связей будет увеличиваться в арифметической прогрессии. Как управлять этим зоопарком, когда приложение начнёт разрастаться до неприличных размеров? Тут на помощь приходят Контейнеры Инверсии Управления.

IoC-container - это фреймворк управляющий объектами и их зависимостями во время исполнения программы.

Spring был первым универсальным IoC-контейнером / фреймворком с которым я столкнулся на практике (для зануд: Micronaut - да!). Чего уж таить, я не сразу проникся заложенными в него идеями. По-настоящему оценить всю мощь автоматического связывания (autowiring) и сопутствующего функционала я смог лишь выстраивая приложение следуя практикам гексагональной архитектуры.

Представьте, насколько удобнее будет использование условного декоратора @Component, который при загрузке программы внесёт класс в реестр зависимостей и выстроит дерево зависимостей автоматически?

T.e. если зарегистрировать компоненты:

@Componentclass ArticleVoteRepository(    SaveArticleVotePort,):    ...@Componentclass VotingUserRepository(GetVotingUserPort):    ...

То IoC-container сможет инициализировать и внедрить их через конструктор в другой компонент:

```@Componentclass PostRatingService(    CastArticleVoteUseCase):    def __init__(        self,        get_voting_user_port: GetVotingUserPort,        save_article_vote_port: SaveArticleVotePort    ):        ...

К сожалению мне не приходилось иметь дела с подобным инструментарием в экосистеме Питона. Буду благодарен, если вы поделитесь опытом в комментариях!

Directory structure

Помните скриншот "типичного Django-приложения"? Сравните его с тем что получилось у нас:

Чувствуете разницу? Нам больше не нужно лезть в файлы в надежде разобраться, что же там лежит и для чего они предназначены. Более того, теперь даже структура тестов и кода приложения идентичны! Архитектура приложения видна невооружённым глазом и существует "на бумаге", а не только в голове у разработчиков приложения.

Interlude

Давайте дружно выдохнем! Даю честное слово, больше ни одной строчки кода! Новый сценарий пользования готов к испытаниям. И пока коллеги вносят последние штрихи (миграция БД, отписки в трекере задач и т.п.) предлагаю поразмышлять вслух о том, почему гексагональная архитектура и предметно-ориентированное проектирование отлично подходят друг-другу.

Domain-Driven Design

Эрик Эванс (Eric Evans) популяризировал термин "Domain-Driven Design" в "большой синей книге" написанной в 2003м году. И всё заверте... Предметно-ориентированное проектирование - это методология разработки сложных систем, в которой во главу угла ставится понимание разработчиками предметной области путем общение с представителями (экспертами) предметной области и её моделирование в коде.

Мартин Фаулер (Martin Folwer) в своей статье рассуждая о заслугах Эванса подчёркивает, что в этой книге Эванс закрепил терминологию DDD, которой мы пользуемся и по сей день.

В частности, Эванс ввёл понятие об Универсальном Языке (Ubiquitous Language) - языке который разработчики с одной стороны и эксперты предметной области с другой, вырабатывают в процессе общения в течении всей жизни продукта. Невероятно сложно создать систему (а ведь смысл DDD - помочь нам проектировать именно сложные системы!) не понимая, для чего она предназначена и как ею пользуются.

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

- Майкл Крайтон, "Парк Юрского периода"

Более того, универсальный язык, со всеми оговорёнными терминами, сущностями, действиями, связями и т.д. используется при написании программы - в названиях модулей, функций, методов, классов, констант и даже переменных!

Другой важный термин - Ограниченный Контекст (Bounded Context) - автономные части предметной области с устоявшимися правилами, терминами и определениями. Простой пример: в онлайн магазине, модель "товар" несёт в себе совершенно разный смысл для отделов маркетинга, бухгалтерии, склада и логистики. Для связи моделей товара в этих контекстах достаточно наличие одинакового идентификатора (например UUID).

Понятие об Агрегатах (Aggregate) - наборе объектов предметной области, с которыми можно обращаться как единым целым, классификации объектов-значений и объектов-сущностей.

О DDD можно рассуждать и рассуждать. Эту тему не то что в одну статью, её и в толстенную книгу-то нелегко уместить. Приведу лишь несколько цитат, которые помогут перекинуть мостик между DDD и гексагональной архитектурой:

Предметная область - это сфера знаний или деятельности.

Модель - это система абстракций, представляющих определённый аспект предметной области.

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

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

Эти цитаты взяты из выступления Эрика Эванса на конференции DDD Europe 2019 года. Приглашаю вас насладиться этим выступлением, прежде чем вы введёте "DDD" в поиск Хабра и начнёте увлекательное падение в бездонную кроличью нору. По пути вас ждёт много открытий и куча набитых шишек. Помню один восхитительный момент: внезапно в голове сложилась мозаика и пришло озарение, что фундаментальные идеи DDD и Agile Manifesto имеют общие корни.

Hexagonal Architecture

Так причём же здесь Гексагональная архитектура? Я очень надеюсь, что внимательный читатель уже ответил на этот вопрос.

На заре Гексагональной архитектуры в 2005м году, Алистар Кокбёрн писал:

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

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

Становится просто связать модель предметной области в коде и "на бумаге" используя универсальный язык общения с экспертами. Универсальный язык обогащается с обеих сторон. При написании кода находятся и изменяются объекты, связи между ними и всё это перетекает обратно в модель предметной области.

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

Тесты. Тэст-Дривэн Дэвэлопмэнт. В самом соке, когда тест пишется, к пока не существующему функционалу и мы даём возможность нашей IDE (или по-старинке) создать класс/метод/функцию/концепцию которая пока существует лишь в тесте. Интеграционные тесты, для которых необязательно загружать всю программу и инфраструктуру, а лишь адаптеры и необходимые для теста сервисы.

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

Microservices

Подумайте, каким образом в наши дни разбивают приложение на части, работа которых происходит в ограниченных контекстах? Ответ очевиден - Микросервисы! Все вышеописанные плюсы гексагональной архитектуры применимы и в этом случае. Но помимо вышеописанных плюсов, появляется возможность модифицировать микросервисы буквально методом "вырезать-вставить". Можно откреплять целые куски логики и кода из одних и вставлять в другие, отпочковывать микросервисы из монолита, или собирать всё обратно в монолит. И даже не важно, на каких языках написаны эти микросервисы. Ведь домен изолирован от технической составляющей! Поэтому переписывание на другой язык программирования становится куда более тривиальной задачей.

На десерт - короткое видео на тему от Дейва Фарли: The problem with microservices.

Outro

Спасибо вам уважаемый читатель. Спасибо, что не бросили меня в середине статьи и прошли со мной до конца. Надеюсь тема беседы вас заинтриговала и вы дерзнёте внедрить принципы гексагональной архитектуры и DDD в ваши проекты. Успехов и до новых встреч!

P.S.

Хотите проверить, насколько вы прониклись вышеизложенным? Тогда подумайте и ответьте, является ли поле VotingUser.voted оптимальным решением с точки зрения моделирования предметной области? А если нет, что бы вы предложили взамен?

Всем привет!

Скажу сразу, эта статья не про очередное переписывание монолита на микросервисы, а о применении микросервисных практик в рамках существующего проекта с использованием интересных, как мне кажется, подходов. Наверное, уже нет смысла объяснять, почему многие проекты активно используют микросервисную архитектуру. Сегодня в IT возможности таких инструментов как Docker, Kubernetes, Service Mesh и прочих сильно меняют наше представление об архитектуре современного приложения, вынуждая пересматривать подходы и переписывать целые проекты на микросервисы. Но так ли это необходимо для всех частей проекта?

В нашем проекте есть несколько систем, которые писались в те времена, когда преимущества микросервисного подхода были не столь очевидны, а инструментов, позволяющих использовать такой подход, было очень мало, и переписывать системы полностью просто нецелесообразно. Для адаптации к новой архитектуре мы решили в части задач использовать асинхронный подход, а также перейти к хранению части данных на общих сервисах. Само приложение при этом осталось на Django (API для SPA). При переходе на k8s деплой приложения был разбит на несколько команд: HTTP-часть (API), Celery-воркеры и RabbitMQ-консьюмеры. Причем было именно три развёртывания, то есть все воркеры, как и консьюмеры, крутились в одном контейнере. Быстрое и простое решение. Но этого оказалось недостаточно, так как это решение не обеспечивало нужный уровень надежности.

Начнем с RabbitMQ-консьюмеров. Основная проблема была в том, что внутри контейнера стартовал воркер, который запускал много потоков на каждый консьюмер, и пока их было пару штук, всё было хорошо, но сейчас их уже десятки. Решение нашли простое: каждый консьюмер вывели в отдельную команду manage.py и деплоим отдельно. Таким образом, у нас несколько десятков k8s-развёртываний на одном образе, с разными параметрами запуска. Ресурсы мы тоже выставляем для каждого консьюмера отдельно, и реальное потребление у консьюмеров достаточно невысокое. В результате для одного репозитория у нас десятки реальных отдельных сервисов в k8s, которые можно масштабировать, и при этом разработчикам намного удобнее работать только с одним репозиторием. То же самое и для развёртываний Сelery.

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

Вроде бы рабочее решение? Да, но ДомКлик большой сложный механизм с сотнями сервисов, и иногда выход одного стороннего (вне конкретной системы) сервиса, который используется в одном единственном API-методе, может привести к пробке на сервере uwsgi. К чему это приводит, надеюсь, объяснять не нужно, всё встает или тормозит. В такие моменты должен приходить Кэп и говорить что-то вроде: Нужно было делать отдельные микросервисы и тогда упал бы только тот, что связан с отказавшим внешним сервисом. Но у нас-то монолит.

В Kubernetes есть такой сервис, как Ingress Controller, его основная задача распределять нагрузку между репликами. Но он, по сути, nginx, а значит Ingress Controller можно использовать для того, чтобы роутить запросы на разные сервисы.

Примерно вот так выглядит схема:

Проанализировав наш API, мы разбили его на несколько групп:

• Внешний API (методы для других сервисов).

• Внутренний API (методы для фронтенда).

• Некритичные API-методы, которые зависимы от внешних сервисов, но не влияют на работу системы (статистика, счетчики и т. п.)

Таким образом можно легко создавать новые сервисы. Управлять ресурсами для каждого из них, масштабировать те методы, которые несут большую нагрузку, и получать другие преимущества. Если один из методов перестанет отвечать из-за каких-то внешних причин, то его можно изолировать в отдельное развёртывание и снизить нагрузку на другие части системы.

В конечном итоге наша система, имея один репозиторий и Django под капотом, раздроблена благодаря Kubernetes на 42 сервиса, 5 из которых делят HTTP-трафик, а остальные 37 консьюмеры и Celery-задачи. И в таком виде она может быть актуальна еще пару лет, несмотря на использование относительно старого стека технологий.

Хабр, отличного всем времени суток! Скоро в OTUS стартует курс Python Web-Developer: мы приглашаем на бесплатный Demo-урок Паттерны Page Controller и Front Controller: реализация в Django и публикуем перевод статьи Nicolle Cysneiros Full Stack Developer (Labcodes).

Согласно всегда правдивой информации на Википедии, в мире насчитывается около 360 миллионов носителей английского языка. Мы, как разработчики, настолько привыкли писать код и документацию на английском языке, что не осознаем, что это число это всего. 4,67% населения всего мира. Единый язык общения между разработчиками это, конечно, хорошо, но это не значит, что пользователь должен чувствовать дискомфорт при использовании вашего продукта.

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

Локализация или интернационализация

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

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

Как гласит документация Django: локализацию делают переводчики, а интернационализацию разработчики.

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

• Формат даты и валюты;

• Конвертация валюты;

• Преобразование единиц измерения;

• Символы юникода и двунаправленны текст (см. ниже);

• Часовые пояса, календарь и особые праздники.

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

Как это делается в Python?

GNU gettext

Есть несколько инструментов, которые могут помочь локализовать ваше приложения на Python. Начнем с пакета GNU gettext, который является частью Translation Project. В этом пакете есть:

• библиотека, которая в рантайме поддерживает извлечение переведенных сообщений;

• набор соглашений о том, как нужно писать код для поддержки каталогов сообщений;

• библиотека, поддерживающая синтаксический анализ и создание файлов, содержащих переведенные сообщения.

Следующий фрагмент кода это просто Hello World в файле app.py, где используется модуль gettext в Python для создания объекта перевода (gettext.translation) в домене приложения с указанием директории локали и языка, на который мы хотим перевести строки. Затем мы присваиваем функцию gettext символу нижнего подчеркивания (обычная практика для уменьшения накладных расходов на ввод gettext для каждой переводимой строки), и, наконец, ставим флаг строке Hello World!, чтобы она была переведена.

import gettextgettext.bindtextdomain("app", "/locale")gettext.textdomain("app")t = gettext.translation("app", localedir="locale", languages=['en_US'])t.install()_ = t.gettextgreeting = _("Hello, world!")print(greeting)

После пометки переводимых строк в коде, мы можем собрать их с помощью инструмента командной строки GNU xgettext. Этот инструмент сгенерирует PO-файл, который будет содержать все отмеченные нами строки.

xgettext -d app app.py

PO-файл (или файл Portable Object) содержит список записей, а структура записи выглядит следующим образом:

#  translator-comments#. extracted-comments#: reference#, flag#| msgid previous-untranslated-stringmsgid untranslated-stringmsgstr translated-string

Мы можем добавить для строки комментарий для переводчиков, ссылки и флаги. После этого мы обращаемся к ID записи (msgid), который представляет из себя непереведенную строку, помеченную в коде и строку записи (msgstr) переведенную версию этой строки.

Когда мы запускаем xgettext в командной строке, передавая app.py в качестве входного файла, получается такой PO-файл:

"Project-Id-Version: PACKAGE VERSION\n""Report-Msgid-Bugs-To: \n""POT-Creation-Date: 2019-05-03 13:23-0300\n""PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n""Last-Translator: FULL NAME <EMAIL@ADDRESS>\n""Language-Team: LANGUAGE <LL@li.org>\n""Language: \n""MIME-Version: 1.0\n""Content-Type: text/plain; charset=UTF-8\n""Content-Transfer-Encoding: 8bit\n"#: app.py:7msgid "Hello, world!"msgstr ""

В начале файла у нас есть метаданные о файле, проекте и процессе перевода. Потом стоит непереведенная строка Hello World! в качестве ID записи и пустая строка для строки записи. Если для записи не указан перевод, то при переводе будет использоваться ID записи.

После генерации PO-файла можно начинать переводить термины на разные языки. Важно отметить, что библиотека GNU gettext будет искать переведенные PO-файлы в пути к папке определенного вида (<localedir>/<languagecode>/LCMESSAGES/<domain>.po), то есть для каждого языка, который вы хотите поддерживать, должен быть один PO-файл.

|-- app.py|-- locale   |-- en_US   |   |-- LC_MESSAGES   |       |-- app.po   |-- pt_BR       |-- LC_MESSAGES       |   |-- app.po

Вот пример PO-файла с переводом на португальский:

"Project-Id-Version: PACKAGE VERSION\n""Report-Msgid-Bugs-To: \n""POT-Creation-Date: 2019-05-03 13:23-0300\n""PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n""Last-Translator: FULL NAME <EMAIL@ADDRESS>\n""Language-Team: LANGUAGE <LL@li.org>\n""Language: \n""MIME-Version: 1.0\n""Content-Type: text/plain; charset=UTF-8\n""Content-Transfer-Encoding: 8bit\n"#: app.py:7msgid "Hello, world!"msgstr "Ol, mundo!"

Чтобы использовать переведенные строки в коде, нужно скомпилировать PO-файл в MO-файл с помощью команды msgfmt.

msgfmt -o app.mo app.po

Когда MO-файл готов, можно изменить язык программы на португальский, подав его на вход функции перевода. Если мы запустим следующий код, отмеченная строка будет переведена как Ol, mundo!:

import gettextgettext.bindtextdomain("app", "/locale")gettext.textdomain("app")t = gettext.translation("app", localedir="locale", languages=['pt_BR'])t.install()_ = t.gettextgreeting = _("Hello, world!")print(greeting)

Модуль locale

У этого модуля есть доступ к базе данных локалей (locale) POSIX, и он особенно полезен для обработки форматов дат, чисел и валют. В примере ниже показано как использовать библиотеку locale:

import datetimeimport localelocale.setlocale(locale.LC_ALL, locale='en_US')local_conv = locale.localeconv()now = datetime.datetime.now()some_price = 1234567.89formatted_price = locale.format('%1.2f', some_price, grouping=True)currency_symbol = local_conv['currency_symbol']print(now.strftime('%x'))print(f'{currency_symbol}{formatted_price}')

В данном примере мы импортируем модуль, меняем все настройки локалей на US English и извлекаем соглашения локали. С помощью метода locale.format мы можем отформатировать число и не беспокоиться о разделителях в разрядах десятков и тысяч. С помощью директивы %x для форматирования даты день, месяц и год будут стоять в правильном порядке для текущей локали. Из соглашений локали мы получим и корректный символ для обозначения валюты.

Ниже вы видите выходные данные того кода на Python. Мы видим, что дата соответствует формату Month/Day/Year, десятичный разделитель это точка, а разделитель разряда тысяч запятая, а также есть знак доллара для валюты США.

$ python format_example.py05/03/2019$1,234,567.89

Теперь с тем же кодом, но изменив локаль на Portuguese Brazil, мы получим другой вывод, основанный на бразильских соглашениях форматирования: дата будет отображаться в формате Month/Day/Year, запятая будет разделителем для десятков, а точка для тысяч, символ R$ будет говорить о том, что сумма указана в бразильских реалах.

import datetimeimport localelocale.setlocale(locale.LC_ALL, locale='pt_BR')local_conv = locale.localeconv()now = datetime.datetime.now()some_price = 1234567.89formatted_price = locale.format('%1.2f', some_price, grouping=True)currency_symbol = local_conv['currency_symbol']print(now.strftime('%x'))print(f'{currency_symbol}{formatted_price}')

Легче ли дела обстоят в Django?

Переводы и форматирование

Интернационализация включается по умолчанию при создании проекта на Django. Модуль перевода инкапсулирует библиотеку GNU и предоставляет функционал gettext с настройками перевода на основе языка, полученного из заголовка Accept-Language, который браузер передает в объекте запроса. Итак, весь тот код на Python, который мы видели раньше, оказывается инкапсулирован в модуль перевода из django utils, так что мы можем перепрыгнуть далеко вперед и просто использовать функцию gettext:

from django.http import HttpResponsefrom django.utils.translation import gettext as _def my_view(request):    greetings = _('Hello, World!')    return HttpResponse(greetings)

Для переводов, мы можем помечать переводимые строки в коде Python и в шаблоне (после загрузки тегов интернационализации). Тег trans template переводит одну строку, тогда как тег blocktrans может пометить как переводимый целый блок строк, включая переменный контент.

<p>{% trans "Hello, World!" %}</p><p>{% blocktrans %}This string will have {{ value }} inside.{% endblocktrans %}</p>

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

Аналогично интерфейсу командной строки GNU, django admin предоставляет команды эквивалентные тем, которые часто используются в процессе разработки. Чтобы собрать все строки, помеченные как переводимые в коде, вам просто нужно выполнить команды django admin makemessages для каждой локали, которую вы хотите поддерживать в своей системе. Как только вы создадите папку locale в рабочей области проекта, эта команда автоматически создаст правильную структуру папок для PO-файла для каждого языка.

Чтобы скомпилировать все PO-файлы, вам просто нужно выполнить django admin compilemessages. Если вам нужно скопировать PO-файл для конкретной локали, вы можете передать его в качестве аргумента django-admin compilemessages --locale=pt_BR. Чтобы получить более полное представление о том, как работают переводы в Django, вы можете ознакомиться с документацией.

Django также использует заголовок Accept-Language для определения локали пользователя и правильного форматирования дат, времени и чисел. В примере ниже мы видим простую форму с DateField и DecimalField. Чтобы указать, что мы хотим получить эти входные данные в формате, согласующимся с локалью пользователя, нам просто нужно передать параметр localize со значением True в экземпляр поля формы.

from django import formsclass DatePriceForm(forms.Form):    date = forms.DateField(localize=True)    price = forms.DecimalField(max_digits=10, decimal_places=2, localize=True)

Как меняется процесс разработки?

После интернационализации приложения процесс развертывания должен быть адаптирован к процессу перевода. В нашем проекте мы отправляем любые новые термины в перевод сразу после развертывания в промежуточной среде. Развертывание на продакшн будет утверждено сразу после перевода всех терминов и компиляции PO-файлов.

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

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

Интересно развиваться в данном направлении? Узнайте больше о курсе Python Web-Developer и записывайтесь на бесплатные Demo-уроки в OTUS!

Перевод статьи подготовлен специально для студентов курса Python Web-Developer.

Вы запускаете тесты командой manage.py test, но знаете ли вы, что происходит под капотом при этом? Как работает исполнитель тестов (test runner) и как он расставляет точки, E и F на экране?

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

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

Однако, прежде чем писать код, давайте проведем реконструкцию процесса тестирования.

Выходные данные тестов

Давайте разберемся в результатах выполнения тестов. За основу возьмем проект с пустым тестом:

from django.test import TestCaseclass ExampleTests(TestCase):    def test_one(self):        pass

При выполнении тестов мы получаем знакомые выходные данные:

$ python manage.py testCreating test database for alias 'default'...System check identified no issues (0 silenced)..----------------------------------------------------------------------Ran 1 test in 0.001sOKDestroying test database for alias 'default'...

Чтобы понять, что происходит, попросим программу рассказать об этом подробнее, добавив флаг -v 3:

$ python manage.py test -v 3Creating test database for alias 'default' ('file:memorydb_default?mode=memory&cache=shared')...Operations to perform:  Synchronize unmigrated apps: core  Apply all migrations: (none)Synchronizing apps without migrations:  Creating tables...    Running deferred SQL...Running migrations:  No migrations to apply.System check identified no issues (0 silenced).test_one (example.core.tests.test_example.ExampleTests) ... ok----------------------------------------------------------------------Ran 1 test in 0.004sOKDestroying test database for alias 'default' ('file:memorydb_default?mode=memory&cache=shared')...

Отлично, этого достаточно! Теперь давайте разбираться.

На первой строке мы видим сообщение Creating test database - так Django отчитывается о создании тестовой базы данных. Если в вашем проекте несколько баз данных, вы увидите по одной строке для каждой.

В этом проекте я использую SQLite, поэтому Django автоматически ставит mode=memory в поле адреса базы данных. Так операции с базой данных станут быстрее примерно раз в 10. Другие базы данных, такие как PostgreSQL, не имеют подобных режимов, но для них есть другие методы запуска in-memory.

Вторая строка Operations to perform и несколько последующих строк это выходные данные команды migrate в тестовых базах данных. То есть вывод тут получается идентичным с тем, который мы получаем при выполнении manage.py migrate на пустой базе данных. Сейчас я использую небольшой проект без миграций, но если бы они были, то на каждую миграцию в выводе приходилась бы одна строка.

Дальше идет строка с надписью System check identified no issues. Он взялась из Django, который запускает ряд проверок перед полетом, чтобы убедиться в правильной конфигурации вашего проекта. Вы можете запустить проверку отдельно с помощью команды manage.py check, и также она выполнится автоматически с запуском большинства команд управления. Однако в случае с тестами, она будет отложена до тех пор, пока тестовые базы данных не будут готовы, так как некоторые этапы проверки используют соединения баз данных.

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

Следующие строки про наши тесты. По умолчанию test runner выводит по одному символу на тест, но с повышением verbosity в Django для каждого теста будет выводиться отдельная строка. Здесь у нас есть всего один тест testone, и когда он закончил выполнение, test runner добавил к строке ok.

Чтобы обозначить конец прогона, ставится разделитель ---. Если бы у нас были какие-то ошибки или сбои, они бы вывелись перед этими черточками. После этого идет краткое описание выполненных тестов и OK, показывающее, что тесты прошли успешно.

Последняя строка сообщает нам, что тестовая база данных была удалена.

В итоге у нас получается следующая последовательность шагов:

1. Создание тестовых баз данных.

2. Миграция баз данных.

3. Запуск проверок системы.

4. Запуск тестов.

5. Отчет о количестве тестов и успешном/неуспешном завершении.

6. Удаление тестовых баз данных.

Давайте разберемся, какие компоненты внутри Django отвечают за эти шаги.

Django и unittest

Как вам, должно быть, уже известно, фреймворк для тестирования в Django расширяет фреймворк unittest из стандартной библиотеки Python. Каждый компонент, отвечающий за шаги, описанные выше, либо встроен в unittest, либо является одним из расширений Django. Мы можем отразить это на диаграмме:

Мы можем найти компоненты каждой стороны взглянув на код.

Команда управления тестами test

Первое, на что нужно посмотреть, это команда управления тестами, которую Django находит и выполняет при запуске manage.py test. Находится она в django.core.management.commands.test.

Что касается команд управления, то они довольно короткие меньше 100 строк. Метод handle() отвечает за обработку в TestRunner. Если упрощать до трех основных строк:

def handle(self, *test_labels, **options):    TestRunner = get_runner(settings, options['testrunner'])    ...    test_runner = TestRunner(**options)    ...    failures = test_runner.run_tests(test_labels)    ...

Полный код.

Так что же представляет из себя класс TestRunner? Это компонент Django, который координирует процесс тестирования. Он настраиваемый, но класс по умолчанию, и единственный в самом Django это django.test.runner.DiscoverRunner. Давайте рассмотрим его следующим.

Класс DiscoverRunner

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

Начинается он как-то так:

class DiscoverRunner:    """A Django test runner that uses unittest2 test discovery."""    test_suite = unittest.TestSuite    parallel_test_suite = ParallelTestSuite    test_runner = unittest.TextTestRunner    test_loader = unittest.defaultTestLoader

(Документация, исходный код)

Эти атрибуты класса указывают на другие классы, которые выполняют различные шаги в процессе тестирования. Как видите, большинство из них компоненты unittest.

Обратите внимание на то, что один из них называется test_runner, таким образом у нас получается два различных понятия, который называются test runner это DiscoverRunner из Django и TextTestRunner из unittest. DiscoverRunner делает гораздо больше, чем TextTestRunner, и у него другой интерфейс. Возможно, в Django можно было бы обозвать DiscoverRunner по-другому, например, TestCoordinator, но сейчас об этом уже поздно думать.

Основной поток в DiscoverRunner находится в методе runtests(). Если убрать кучу деталей, run_tests() будет выглядеть примерно так:

def run_tests(self, test_labels, extra_tests=None, **kwargs):    self.setup_test_environment()    suite = self.build_suite(test_labels, extra_tests)    databases = self.get_databases(suite)    old_config = self.setup_databases(aliases=databases)    self.run_checks(databases)    result = self.run_suite(suite)    self.teardown_databases(old_config)    self.teardown_test_environment()    return self.suite_result(suite, result)

Шагов здесь совсем немного. Многие из методов соответствуют шагам из списка, который мы приводили выше:

• setup_databases() создает тестовые базы данных. Но этот метод создает только те базы данных, которые необходимы для выбранных тестов, отфильтрованных с помощью get_databases(), поэтому если вы запускаете только SimpleTestCases без баз данных, то Django ничего создавать не будет. Внутри этого метода создаются базы данных и выполняется команда migrate.

• run_checks() запускает проверки.

• run_suite() запускает набор тестов, включая все выходные данные.

• Функция teardown_databases() удаляет тестовые базы данных.

И еще парочка методов, о которых можно рассказать:

• setup_test_environment() и teardown_test_environment() устанавливают или убирают некоторые настройки, такие как локальный сервер электронной почты.

• suite_result() возвращает количество ошибок в ответ команде управления тестированием.

Все эти методы полезно рассмотреть, чтобы разобраться с настройками процесса тестирования. Но они все являются частью Django. Другие методы передаются компонентам в unittest - build_suite() и run_suite().

Давайте поговорим и о них.

buildsuite()

buildsuite() ищет тесты для запуска и перемещает их в объект suite. Это длинный метод, но если его упростить, выглядеть он будет примерно так:

def build_suite(self, test_labels=None, extra_tests=None, **kwargs):    suite = self.test_suite()    test_labels = test_labels or ['.']    for label in test_labels:        tests = self.test_loader.loadTestsFromName(label)        suite.addTests(tests)    if self.parallel > 1:        suite = self.parallel_test_suite(suite, self.parallel, self.failfast)    return suite

В этом методе используются три из четырех классов, к которым, как мы видели, обращается DiscoverRunner:

• test_suite - компонент unittest, который служит контейнером для запуска тестов.

• parallel_test_suite - оболочка для набора тестов, которая используется с функцией параллельного тестирования в Django.

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

runsuite()

Еще один метод DiscoverRunner, о котором надо поговорить это run_suite(). Его мы упрощать не будем, и просто посмотрим, как он выглядит:

def run_suite(self, suite, **kwargs):    kwargs = self.get_test_runner_kwargs()    runner = self.test_runner(**kwargs)    return runner.run(suite)

Его единственная задача создавать test runner и говорить ему запустить собранный набор тестов. Это последний из компонентов unittest, на который ссылается атрибут класса. Он использует unittest.TextTestRunner - test runner по умолчанию для вывода результатов в виде текста, в отличие, например, от XML-файла для передачи результатов в вашу CI-систему.

Закончим мы наше небольшое расследование, заглянув в класс TextTestRunner.

Класс TextTestRunner

Этот компонент unittest берет тест-кейс или набор и выполняет его. Начинается он вот так:

class TextTestRunner(object):    """A test runner class that displays results in textual form.    It prints out the names of tests as they are run, errors as they    occur, and a summary of the results at the end of the test run.    """    resultclass = TextTestResult    def __init__(self, ..., resultclass=None, ...):

(Исходный код)

По аналогии с DiscoverRunner, он использует атрибут класса для ссылки на другой класс. Класс TextTestResult по умолчанию отвечает за текстовый вывод. В отличие от ссылок класса DiscoverRunner, мы можем переопределить resultclass, передав альтернативу TextTestRunner._init_().

Теперь мы наконец-то можем кастомизировать процесс тестирования. Но сначала вернемся к нашему маленькому исследованию.

Карта

Теперь мы можем расширить карту и показать на ней классы, которые мы нашли:

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

Как кастомизировать

Django предлагает два способа кастомизации процесса выполнения тестов:

• Переопределить команду тестирования с помощью кастомного подкласса.

• Переопределить класс DiscoverRunner, указав в настройках TESTRUNNER кастомный подкласс.

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

Супербыстрый Test Runner

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

# example/test.pyfrom django.test.runner import DiscoverRunnerclass SuperFastTestRunner(DiscoverRunner):    def run_tests(self, *args, **kwargs):        print("All tests passed! A+")        failures = 0        return failures

Затем воспользуемся им в файле с настройками следующим образом:

TEST_RUNNER = "example.test.SuperFastTestRunner"

А затем выполним manage.py test, и получим результат за рекордно короткое время!

$ python manage.py testAll tests passed! A+

Отлично, очень полезно!

А теперь давайте сделаем еще практичнее, и перейдем к выводу результатов теста в виде эмодзи!

Вывод в виде эмодзи

Мы уже выяснили, что компонент TextTestResult из unittest отвечает за вывод. Мы можем заменить его в DiscoverRunner, передав значение resultclass в TextTestRunner.

В Django уже есть опции для замены resultclass, например, опция --debug-sql option, которая выводит выполненные запросы для неудачных тестов.

DiscoverRunner.run_suite() создает TextTestRunner с аргументами из метода DiscoverRunner.get_test_runner_kwargs():

<img alt="Изображение выглядит как текст

def get_test_runner_kwargs(self):    return {        'failfast': self.failfast,        'resultclass': self.get_resultclass(),        'verbosity': self.verbosity,        'buffer': self.buffer,    }

Он же в свою очередь вызывает get_resultclass(), который возвращает другой класс, если был использован один из двух параметров тестовой команды (--debug-sql или --pdb):

def get_resultclass(self):    if self.debug_sql:        return DebugSQLTextTestResult    elif self.pdb:        return PDBDebugResult

Если ни один из параметров не задан, метод неявно возвращает None, говоря TextTestResult использовать по умолчанию resultclass. Мы можем увидеть этот None в нашем собственном подклассе и заменить его подклассом TextTestResult:

class EmojiTestRunner(DiscoverRunner):    def get_resultclass(self):        klass = super().get_resultclass()        if klass is None:            return EmojiTestResult        return klass

Наш класс EmojiTestResult расширяет TextTestResult и заменяет вывод точек по умолчанию на эмодзи. В конечном итоге получается довольно длинно, поскольку на каждый тип результата приходится отдельный метод:

class EmojiTestResult(unittest.TextTestResult):    def __init__(self, *args, **kwargs):        super().__init__(*args, **kwargs)        # If the "dots" style was going to be used, show emoji instead        self.emojis = self.dots        self.dots = False    def addSuccess(self, test):        super().addSuccess(test)        if self.emojis:            self.stream.write('')            self.stream.flush()    def addError(self, test, err):        super().addError(test, err)        if self.emojis:            self.stream.write('?')            self.stream.flush()    def addFailure(self, test, err):        super().addFailure(test, err)        if self.emojis:            self.stream.write('')            self.stream.flush()    def addSkip(self, test, reason):        super().addSkip(test, reason)        if self.emojis:            self.stream.write("")            self.stream.flush()    def addExpectedFailure(self, test, err):        super().addExpectedFailure(test, err)        if self.emojis:            self.stream.write("")            self.stream.flush()    def addUnexpectedSuccess(self, test):        super().addUnexpectedSuccess(test)        if self.emojis:            self.stream.write("")            self.stream.flush()    def printErrors(self):        if self.emojis:            self.stream.writeln()        super().printErrors()

После указания TEST_RUNNER в EmojiTestRunner, мы можем запустить тесты и увидеть эмодзи:

$ python manage.py testCreating test database for alias 'default'...System check identified no issues (0 silenced).?...----------------------------------------------------------------------Ran 8 tests in 0.003sFAILED (failures=1, errors=1, skipped=1, expected failures=1, unexpected successes=1)Destroying test database for alias 'default'...

Урааа!

Вместо заключения

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

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

Я знаком лишь с двумя библиотеками, предоставляющими кастомные подклассы DiscoverRunner:

• unittest-xml-reporting обеспечивает вывод в формате XML для вашей CI-системы.

• django-slow-tests обеспечивает измерение времени выполнения тесты для поиска самых медленных тестов.

Сам я не пробовал, но их объединение может не сработать, поскольку обе они переопределяют процесс вывода.

С другой стороны, у pytest есть процветающая экосистема с более чем 700 плагинами. Так происходит из-за того, что в его архитектуре используется композиция с хуками, которые работают по аналогии с сигналами в Django. Плагины регистрируются только для тех хуков, которые им нужны, а pytest вызывает каждую зарегистрированную хук-функцию в соответствующей точке процесса тестирования. Многие из встроенных функций pytest даже реализованы в виде плагинов.

Если вам интересна более детальная настройка процесса тестирования, обратитесь к pytest.

Конец

Спасибо, что отправились со мной в это путешествие. Я надеюсь, что вы узнали что-то новое о том, как Django запускает ваши тесты, и научились кастомизировать их.

Читать ещё:

• Почему интернационализация и локализация имеют значение

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

Немного теории

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

Django это фреймворк, использующий шаблон проектирования Model-View-Controller (MVC).

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

Обычно в таких схемах MVC описывают подобным образом:

• Model доступ к хранилищу данных

• View это интерфейс, с которым взаимодействует пользователь

• Controller некий связывающий объект между model и view.

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

Стоит обратить внимание на две вещи.

Первое, часто под M в MVC подразумевают модель данных, и говорят, что это некий класс, который отвечает за предоставление доступа к базе данных. Что неверно, и не соответствует классическому MVC и его потомкам MV*. В классическом MVC под M подразумевается domain model объектная модель домена, объединяющая данные и поведение. Если говорить точнее, то M в MVC это интерфейс к доменной модели, так как domain model это некий слой объектов, описывающий различные стороны определенной области бизнеса. Где одни объекты призваны имитировать элементы данных, которыми оперируют в этой области, а другие должны формализовать те или иные бизнес-правила.

Второе, в Django нет выделенного слоя controller, и когда вам говорят, что в Django слой views это контроллер, не верьте этим людям. Обратитесь к официальной документации, а точнее к FAQ, тогда можно увидеть, что этот слой вписывается в принципы слоя View в MVC, особенно, если рассматривать DRF, а как такового слоя Controller в Django нет. Как говорится в FAQ, если вам очень хочется аббревиатур, то можно использовать в контексте Django аббревиатуру MTV (Model, Template, and View). Если очень хочется рассматривать Web MVC и сравнивать Django с другими фреймворками, то для простоты можно считать view контроллером.

Несмотря на то, что Django не соответствует MVC аббревиатуре, в ней реализуется главный смысл MVC отделение бизнес-логики от логики представления данных.Но на практике это не всегда так по нескольким причинам, которые мы рассмотрим ниже.

Перейдем к практике

Выделим в Django приложениях несколько слоев, которые есть в каждом туториале и почти в каждом проекте:

• front-end/templates

• serializers/forms

• views

• models

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

Первый кейс создание заказа. При создании заказа нам нужно:

• проверить валидность заказа и доступность товаров

• создать заказ

• зарезервировать товар на складе

• передать заявку менеджеру

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

Второй кейс просмотр списка моих заказов. Здесь все просто, мы должны показать пользователю список его заказов:

• получить список заказов пользователя

Слой serializers/forms

У слоя serializers три основные функции (все выводы для serializers справедливы и для forms):

• валидировать данные

• преобразовывать данные запроса в типы данных Python

• преобразовывать сложные Python объекты в простые типы данных Python (например, Django модели в dict)

Дополнительно сериалайзеры имеют два метода, create и update, которые вызываются в методе save() и почти всегда используются во view.

Пример использования из документации:

class CommentSerializer(serializers.Serializer):email = serializers.EmailField()  content = serializers.CharField(max_length=200)  created = serializers.DateTimeField()  def create(self, validated_data):  return Comment.objects.create(**validated_data)  def update(self, instance, validated_data):    instance.email = validated_data.get('email', instance.email)    instance.content = validated_data.get('content', instance.content)    instance.created = validated_data.get('created', instance.created)    instance.save()    return instance

Где-то в нашей view:

# .save() will create a new instance.serializer = CommentSerializer(data=data)# .save() will update the existing `comment` instance.serializer = CommentSerializer(comment, data=data)comment = serializer.save()

В данном подходе за сохранение и обновление сущностей отвечает сериалайзер, точнее он оперирует методами модели.

Можно использовать ModelSerializer и ModelViewSet, что позволяет писать CRUD методы в пару-тройку строк.

# serializers.pyclass OrderSerializer(serializers.ModelSerializer):class Meta:  model = Order    fields = __all__# views.pyclass OrderViewsSet(viewsets.ModelViewSet):queryset = Order.objects.all()  serializer_class = OrderSerializer

Если углубиться в реализацию ModelViewSet и ModelSerializer, то можно заметить, что за сохранение и обновление сущностей также отвечает сериалайзер.

В таком случае, кажется, что переопределение create отличное место для того, чтобы описать там все бизнес-процессы и правила создания заказа.

# serializers.pyclass OrderSerializer(serializers.ModelSerializer):class Meta:model = Orderfields = []def create(self, validated_data):# Проверяем, что все товары есть и заказ валиден...# Создаем запись о заказе в БДinstance = super(OrderSerializer, self).create(validated_data)    # Бронируем товары на складе    ...    # Передаем заявку менеджеру    ...    # Оповещаем пользователя    ...    return instance  # views.pyclass OrderViewsSet(viewsets.ModelViewSet):queryset = Order.objects.all()  serializer_class = OrderSerializer

Если с методом создания мы что-то придумали, то логику получения заказов пользователя придется помещать в view.

Получается такая схема:

Плюсы данного подхода:

Легко делать CRUD

Django и DRF предоставляют очень удобные инструменты с помощью которых можно легко создавать CRUD.

Минусы данного подхода:

Нарушение идей MVC

Мы смешиваем бизнес-логику с задачей сериализации (получения/отображения) данных в одном слое. Ни о каком выделенном слое бизнес-логики у нас нет и речи.

Сериалайзеры стоит относить к слою View в MVC в контексте Django. Когда мы располагаем в сериалайзерах свою бизнес логику, мы нарушаем главный принцип MVC отделение логики представления данных от бизнес-логики.

Нельзя переиспользовать

Не получится переиспользовать логику одного сериалайзера в другом сериалайзере, или в каком-то другом компоненте.

Сложно тестировать

Сложно протестировать бизнес-логику независимо от логики сериализации и валидации данных.

Сложно поддерживать

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

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

Высокая зависимость от фреймворка

Высокая зависимость от DRF Serializers или Django Forms. Если мы захотим поменять способ сериализации и отказаться от serializers, то придется переносить или переписывать нашу логику. Также будет сложно переехать с Django Forms на DRF Serializers или наоборот.

Правильные обязанности слоя

Сериализация/десериализация данных

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

Валидация данных

Без написания кастомных валидаторов. Если вам требуется написать кастомный валидатор, то, скорее всего, это бизнес-правило, и данную проверку лучше вынести в слой с бизнес-логикой (где бы он ни был).

Заключение

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

Стоит отказаться от ModelSerializer с его магическими методами create и update и заменить их на обычные сериалайзеры (можно использовать ModelSerializer как read only для удобства). Если вы пишете какое-то простое приложение, где кроме CRUD ничего не нужно, то можно не отказываться от удобства DRF и использовать сериалайзеры как предлагается в документации.

Слой Views

Слой View в контексте Django отвечает за представление и обработку пользовательских данных, в нем мы описываем, какие данные нам нужны и как мы хотим их представить. Если вспомнить то, о чем мы говорили в начале, то можно сразу сделать вывод, что во views не нужно писать бизнес-логику, иначе мы смешиваем логику представления данных с бизнес-логикой. Даже если считать, что views в Django это контроллеры, то размещать в них бизнес-логику тоже не стоит, иначе у вас получатся ТТУКи (Толстые, тупые, уродливые контроллеры; Fat Stupid Ugly Controllers).

Но часто можно увидеть что-то подобное:

# views.pyclass OrderViewsSet(viewsets.ModelViewSet):queryset = Order.objects.all()  serializer_class = OrderSerializer                                  def perform_create(self, serializer):  # Проверяем, что все товары есть и заказ валиден    ...    # Создаем запись о заказе в БД    super(OrderViewsSet, self).perform_create(serializer)    # Бронируем товары на складе    ...    # Передаем заявку менеджеру    ...    # Оповещаем пользователя    ...

По дефолту, в ModelViewSet для сохранения и обновления данных используется сериалайзер, что не входит в его обязанности. Это можно исправить, полностью переопределить метод perform_create (не вызывать super, но тогда встает вопрос об объективности наследования от ModelViewSet). Можно написать кастомные методы в ModelViewSetили написать кастомные APIView:

# views.pyclass OrderCreateApi(views.APIView):class InputSerializer(serializers.ModelSerializer):  number = serializers.IntegerField()    ...                     def post(self, request):  serializer = self.InputSerializer(data=request.data)    serializer.is_valid(raise_exception=True)    # Проверяем, что все товары есть и заказ валиден    ...    # Создаем запись о заказе в БД                                             order = Order.objects.create(**serializer.validated_data)    # Бронируем товары на складе    ...    # Передаем заявку менеджеру    ...    # Оповещаем пользователя    ...                       return Response(status=status.HTTP_201_CREATED)

В отличии от слоя serializers, мы теперь легко можем поместить нашу логику получения заказов в слой views.

# views.pyclass OrderViewsSet(viewsets.ModelViewSet):queryset = Order.objects.all()  serializer_class = OrderSerializer                            def get_queryset(self):  queryset = super(OrderViewsSet, self).get_queryset()    queryset = queryset.filter(user=self.request.user)    return queryset

Тем самым, ограничив не только получение списка, но и другие методы CRUD, что, иногда, очень удобно и быстро. Также, можно переопределить каждый метод по отдельности.

Получается такая схема:

Стоит помнить, что мы отказались от использования saveу serializers. В таком случае слой serializers остается чистым и выполняет только правильные обязанности.

Плюсы данного подхода

Легко делать CRUD

Django и DRF предоставляют очень удобные инструменты, с помощью которых можно легко создавать CRUD и views не исключение.

Минусы данного подхода

Нарушение идей MVC

Мы смешиваем в одном слое логику представления данных и бизнес-логику приложения.

Нельзя переиспользовать

Не получится переиспользовать логику одной view в другой view, или в каком-то другом компоненте. Так же будут проблемы, если мы захотим вызывать нашу бизнес-логику из других интерфейсов, например, из Celery задач.

Высокая зависимость от фреймворка

Высокая зависимость от DRF View или Django View. Если мы захотим поменять способ обработки запроса и отказаться от views, то придется переносить или переписывать нашу логику. Будет сложно переехать с Django View на DRF View или наоборот.

Сложно тестировать

Достаточно сложно протестировать код во views независимо от serializers и остальной инфраструктуры Django + придется использовать http client для тестирования.

Сложно поддерживать

Со временем views разрастаются, часть логики переносится в Celery задачи, часть в модели, код во views дублируется, так как их нельзя переиспользовать все это приводит к тому, что проект сложно поддерживать.

Правильные обязанности слоя

Обработка запроса

Во view мы принимаем и обрабатываем запрос клиента, подготавливаем данные для передачи в бизнес-логику.

Делегирование сериализации данных сериалайзерам

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

Вызов методов бизнес-логики

После подготовки и сериализации данных вызывается интерфейс бизнес-логики.

Логика представления данных

Мы должны обработать ответ от методов бизнес-логики и предоставить нужные данные клиенту.

Заключение

Вывод примерно такой же как и с serializers в views не стоит размещать бизнес-логику.

Стоит отказаться от ModelViewSet и миксинов, так как они используют сериалайзеры для сохранения данных, вместо этого использовать обычные APIView или GenericAPIView.

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

Слой models

Если опираться на более продвинутые туториалы или вспомнить слой Model в MVC, то кажется, что models отличное место для размещения бизнес-логики.

Это может выглядеть примерно так:

# models.pyclass Order(models.Model):number = serializers.IntegerField()  created = models.DateTimeField(auto_now_add=True)  status = models.CharField(max_length=16)                                               def update_status(self, status: str) -> None:  self.status = status    self.save(update_fields=('status',))  ...    @classmethod  def create(cls, data...):  instance = cls(...)    # Проверяем, что все товары есть и заказ валиден    ...    # Создаем запись о заказе в БД    instance = instance.save()    # Бронируем товары на складе    ...    # Передаем заявку менеджеру (например на почту или создаем какую то запись в БД)    ...    # Оповещаем пользователя    ...# views.pyclass OrderCreateApi(views.APIView):class InputSerializer(serializers.ModelSerializer):  number = serializers.IntegerField()    ...      def post(self, request):  serializer = self.InputSerializer(data=request.data)    serializer.is_valid(raise_exception=True)        Order.create(**serializer.validated_data)                    return Response(status=status.HTTP_201_CREATED)

В view мы сериализуем данные с помощью serializer и вызываем метод создания заказа у класса модели.В данном случае мы реализовали classmethod, что бы не было необходимости создавать экземпляр модели. Иначе нам придется понимать какие данные относятся к полям модели, а какие мы должны передать в метод создания, а это уже некие бизнес- правила.

Стоит заметить, что не нужно писать бизнес-логику в методе save(), так как это базовый метод модели и он может неоднократно использоваться в различных частях кода.

Для методов получения данных в таком случае стоит использовать Managers.

# views.pyclass OrderListApi(views.APIView):class OutputSerializer(serializers.ModelSerializer):  class Meta:    model = Order      fields = __all__                             def get(self, request):  orders = Order.objects.filter(user=request.user)    # если у вас сложные условия фильтрации    # например, Order.objects.filter(user=request.user, is_deleted=False, is_archived=False...)    # то стоит написать кастомные методы в Manager        data = self.OutputSerializer(orders, many=True).data        return Response(data)

Получается такая схема:

В данном случае слои serializers и views становятся чистыми и правила бизнес-логики концентрируются в одном слое.

Плюсы данного подхода

Следование идеям MVC

Мы отделили логику представления данных от логики предметной области. View только подготавливает данные и вызывает методы модели, все бизнес правила и процессы описаны в методах модели. Данный подход соответствует главной идее MVC.

Легко тестировать

Вся бизнес-логика собрана в одном слое, который не зависит от других слоев, например, от views или serializers. Каждый метод модели можно протестировать по отдельности как обычный python код. Остается только замокать метод save и базовые методы managers или использовать базу данных, если требуется.

Можно переиспользовать

Методы модели можно вызывать из любого компонента, DRF Views, Django Views, Celery задачи и т.д.

Минусы данного подхода

Зависимость от фреймворка

У нас все еще есть зависимость от фреймворка, но это не так критично. Так как отказ от Django models и ORM или их замена очень редкий кейс.

Сложно поддерживать большие проекты

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

Усложнение CRUD проектов

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

Заключение

Мы не нарушили главных идей MVC и наш код соответствует им. Такой подход можно использовать в малых проектах, когда бизнес-логики не много и она умещается в классах моделей.

Слой Services

Мы перебрали все дефолтные слои в Django приложении, теперь можем вспомнить о том, что под слоем Model в MVC подразумевается не один объект, а набор объектов.

Выделим отдельный сервисный слой services внутри слоя Model, который будет отвечать за бизнес-правила предметной области и приложения. В models оставить только простые property, в которых нет сложных бизнес-правил, и методы для работы с собственными данными модели, например обновление полей. Тогда наши кейсы можно реализовать так:

# models.pyclass Order(models.Model):number = serializers.IntegerField()  created = models.DateTimeField(auto_now_add=True)  status = models.CharField(max_length=16)                                               def update_status(self, status: str) -> None:  self.status = status    self.save(update_fields=('status',))...# services.py# вместо пречесления всех аргументов можно реализовать DTOdef order_create(name: str, number: int ...) -> bool:# Проверяем, что все товары есть и заказ валиден  ...  # Создаем запись о заказе в БД  order = Order.objects.create(...)  # Бронируем товары на складе  ...  # Передаем заявку менеджеру (например на почту или создаем какую то запись в БД)  ...  # Оповещаем пользователя  ...# views.pyclass OrderCreateApi(views.APIView):class InputSerializer(serializers.ModelSerializer):  number = serializers.IntegerField()    ...                             def post(self, request):  serializer = self.InputSerializer(data=request.data)    serializer.is_valid(raise_exception=True)      services.order_create(**serializer.validated_data)                 return Response(status=status.HTTP_201_CREATED)

Стоит придерживаться следующему подходу:

• views подготовка данных запроса, вызов бизнес логики, подготовка ответа

• serializers сериализация данных, простая валидация

• services простые функции с бизнес правилами или классы (Service Objects)

• managers содержит в себе правила работы с данными (доступ к данным)

• models единственный окончательный источник правды о анных

Получение заказов пользователя:

# services.pydef order_get_by_user(user: User) -> Iterable[Order]:return Order.objects.filter(user=user)# views.pyclass OrderListApi(views.APIView):class OutputSerializer(serializers.ModelSerializer):  class Meta:    model = Order      fields = ('id', 'number', ...)                            def get(self, request):  orders = services.order_get_by_user(user=request.user)                                             data = self.OutputSerializer(orders, many=True).data                                return Response(data)

Получается такая схема:

Плюсы данного подхода

Следование идеям MVC

Как и в предыдущем подходе, мы полностью отделили бизнес-логику от логики представления.

Легко тестировать

Сервисы представляют собой простые Python функции, которые легко тестировать.

Можно переиспользовать

Мы можем вызывать наши сервисы из любого компонента + можем повторно использовать какие-то сервисы в других проектах.

Легко поддерживать и расширять

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

Гибкость

Существует множество подходов написания и расширения сервисного слоя.

Минусы данного подхода

Зависимость от фреймворка

Доменный слой не отделен от слоя приложения и инфраструктуры. Мы все еще используем Django модели в качестве сущностей. У нас могут возникнуть проблемы, когда мы захотим отказаться от Django ORM, но это очень редкий кейс и для многих проектов неактуален.

Усложнение CRUD проектов

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

Заключение

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

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

Что касается Django, советую обратить внимание на стайл гайд от HackSoftware у них схожие взгляды, но они разделяют сервисный слой на два компонента (services и selectors) и не используют кастомные методы в managers. Подход написания serializers и включения их во views я взял у них. Также стоит посмотреть на идеи ребят из dry-python.

Общий итог

Получается, что поддерживаемость и чистота Django проектов страдает от удобства и плюшек фреймворка. Django и DRF очень классные инструменты, но не все их возможности стоит использовать. Можно сделать вывод, что, чем больше ваш проект и чем сложнее в нем бизнес-правила и сущности, тем более абстрактным и независимым от фреймворка должен быть ваш код. И выделение сервисного слоя это далеко не предел и не идеал архитектуры приложения.

Пару недель назад Django 3.2 выпустил свой первый альфа-релиз, а финальный релиз выйдет в апреле. Он содержит микс новых возможностей, о которых вы можете прочитать в примечаниях к релизу. Эта статья посвящена изменениям в тестировании, некоторые из которых можно получить на более ранних версиях Django с пакетами backport.

1. Изоляция setUpTestData()

В примечании к релизу говорится:

Объекты, назначенные для классификации атрибутов в TestCase.setUpTestData() теперь выделяются для каждого тестового метода.

setUpTestData() очень полезный прием для быстрого выполнения тестов, и это изменение делает его использование намного проще.

Прием TestCase.setUp() нередко используется из юнит-теста для создания экземпляров моделей, которые используются в каждом тесте:

from django.test import TestCasefrom example.core.models import Bookclass ExampleTests(TestCase):    def setUp(self):        self.book = Book.objects.create(title="Meditations")

Тест-раннер вызывает setUp() перед каждым тестом. Это дает простую изоляцию тестов, так как берутся свежие данные для каждого теста. Недостатком такого подхода является то, что setUp() запускается много раз, что при большом объеме данных или тестов может происходить довольно медленно.

setUpTestData() позволяет создавать данные на уровне класса один раз на TestCase. Его использование очень похоже на setUp(), только это метод класса:

from django.test import TestCasefrom example.core.models import Bookclass ExampleTests(TestCase):    @classmethod    def setUpTestData(cls):        cls.book = Book.objects.create(title="Meditations")

В промежутках между тестами Django продолжает откатывать (rollback) любые изменения в базе данных, поэтому они остаются там изолированными. К сожалению, до этого изменения в Django 3.2 rollback не происходили в памяти, поэтому любые изменения в экземплярах моделей сохранялись. Это означает, что тесты не были полностью изолированы.

Возьмем, к примеру, эти тесты:

from django.test import TestCasefrom example.core.models import Bookclass SetUpTestDataTests(TestCase):    @classmethod    def setUpTestData(cls):        cls.book = Book.objects.create(title="Meditations")    def test_that_changes_title(self):        self.book.title = "Antifragile"    def test_that_reads_title_from_db(self):        db_title = Book.objects.get().title        assert db_title == "Meditations"    def test_that_reads_in_memory_title(self):        assert self.book.title == "Meditations"

Если мы запустим их на Django 3.1, то финальный тест провалится:

$ ./manage.py test example.core.tests.test_setuptestdataCreating test database for alias 'default'...System check identified no issues (0 silenced)..F.======================================================================FAIL: test_that_reads_in_memory_title (example.core.tests.test_setuptestdata.SetUpTestDataTests)----------------------------------------------------------------------Traceback (most recent call last):  File "/.../example/core/tests/test_setuptestdata.py", line 19, in test_that_reads_in_memory_title    assert self.book.title == "Meditations"AssertionError----------------------------------------------------------------------Ran 3 tests in 0.002sFAILED (failures=1)Destroying test database for alias 'default'...

Это связано с тем, что in-memory изменение из test_that_changes_title() сохраняется между тестами. Это происходит в Django 3.2 за счет копирования объектов доступа в каждом тесте, поэтому в каждом тесте используется отдельная изолированная копия экземпляра модели in-memory. Теперь тесты проходят:

$ ./manage.py test example.core.tests.test_setuptestdataCreating test database for alias 'default'...System check identified no issues (0 silenced)....----------------------------------------------------------------------Ran 3 tests in 0.002sOKDestroying test database for alias 'default'...

Спасибо Simon Charette за изначальное создание этой функциональности в проекте django-testdata, и до его объединения в систему Django. На старых версиях Django вы можете использовать django тест-данные для той же изоляции, добавив декоратор@wrap_testdata в ваши методы setUpTestData(). Он очень удобен, и я добавлял его в каждый проект, над которым работал.

(В более старых версиях Django также документируется обходной путь, включающий повторный запрос базы данных в каждом тесте, но это медленнее).

2. Использование faulthandler по умолчанию

В примечании к релизу говорится:

DiscoverRunner сейчас использует faulthandler по умолчанию.

Это небольшое улучшение, которое может помочь вам дебаггить сбои низкого уровня. Модуль Python faulthandler предоставляет способ сброса экстренной трассировки в ответ на проблемы, которые приводят к сбою в работе интерпретатора Python.Тогда тестовый runner Django использует faulthandler. Подобное решение было скопировано из pytest, который делает то же самое.

Проблемы, которые ловит faulthandler, обычно возникают в библиотеках на языке C, например, в драйверах баз данных. Например, OS сигнал SIGSEGV указывает на ошибку сегментации, что означает попытку чтения памяти, не принадлежащей текущему процессу. Мы можем эмулировать это на Python, напрямую посылая сигнал самим себе:

import osimport signalfrom django.test import SimpleTestCaseclass FaulthandlerTests(SimpleTestCase):    def test_segv(self):        # Directly trigger the segmentation fault        # signal, which normally occurs due to        # unsafe memory access in C        os.kill(os.getpid(), signal.SIGSEGV)

Если мы делаем тест в Django 3.1, мы видим это:

$ ./manage.py test example.core.tests.test_faulthandlerSystem check identified no issues (0 silenced).[1]    31127 segmentation fault  ./manage.py test

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

Вместо этого мы видим трассировку на Django 3.2:

$ ./manage.py test example.core.tests.test_faulthandlerSystem check identified no issues (0 silenced).Fatal Python error: Segmentation faultCurrent thread 0x000000010ed1bdc0 (most recent call first):  File "/.../example/core/tests/test_faulthandler.py", line 12 in test_segv  File "/.../python3.9/unittest/case.py", line 550 in _callTestMethod  ...  File "/.../django/test/runner.py", line 668 in run_suite  ...  File "/..././manage.py", line 17 in main  File "/..././manage.py", line 21 in <module>[1]    31509 segmentation fault  ./manage.py test

( Сокращенно )

Faulthandler не может генерировать точно такую же трассировку, как стандартное исключение в Python, но он дает нам много информации для дибаггинга сбоя.

3. Timing (тайминг)

В примечании к релизу говорится:

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

Команда manage.py test включает опцию --timing, которая активирует несколько строк вывода в конце пробного тест-запуска для подведения итогов по настройке базы данных и времени:

$ ./manage.py test --timingCreating test database for alias 'default'...System check identified no issues (0 silenced)....----------------------------------------------------------------------Ran 3 tests in 0.002sOKDestroying test database for alias 'default'...Total database setup took 0.019s  Creating 'default' took 0.019sTotal database teardown took 0.000sTotal run took 0.028s

Благодарим Ахмада А. Хуссейна за участие в этом мероприятии в рамках Google Summer of Code 2020.

Если вы используете pytest, опция --durations N работает схоже.

Из-за системы фикстуры pytest время настройки базы данных будет отображаться как время настройки (setup time) только для одного теста, что сделает этот тест более медленным, чем он есть на самом деле.

4. Обратный вызов (callbacks) тестаtransaction.on_commit()

В примечании к релизу говорится:

Новый метод TestCase.captureOnCommitCallbacks() собирает функции обратного вызова (callbacks functions), переданные в transaction.on_commit(). Это позволяет вам тестировать эти callbacks, не используя при этом более медленный TransactionTestCase.

Это вклад, который я ранее сделал и о котором ранее рассказывал.

Итак, представьте, что вы используете опцию ATOMIC_REQUESTSот Django, чтобы перевести каждый вид в транзакцию (а я думаю, что так и должно быть!). Затем вам нужно использовать функцию transaction.on_commit() для выполнения любых действий, которые зависят от того, насколько длительно данные хранятся в базе данных. Например, в этом простом представлении для формы контактов:

from django.db import transactionfrom django.views.decorators.http import require_http_methodsfrom example.core.models import ContactAttempt@require_http_methods(("POST",))def contact(request):    message = request.POST.get('message', '')    attempt = ContactAttempt.objects.create(message=message)    @transaction.on_commit    def send_email():        send_contact_form_email(attempt)    return redirect('/contact/success/')

Мы не посылаем сообщения по электронной почте, если только транзакция не сохраняет изменения, так как в противном случае в базе данных не будет ContactAttempt.

Это правильный способ написания подобного вида, но ранее было сложно протестировать callback (обратный вызов), переданный функции on_commit(). Django не будет запускать callback без сохранения транзакции, а его TestCase избегает сохранения, и вместо этого откатывает (rollback) транзакцию, так что это повторяется при каждом тесте.

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

(Я ранее говорил об увеличении скорости в три раза благодаря конвертации тестов из TransactionTestCase в TestCase.)

Решением в Django 3.2 является новая функция captureOnCommitCallbacks(), которую мы используем в качестве контекстного менеджера. Она захватывает любые callbacks и позволяет вам добавлять утверждения или проверять их эффект. Мы можем использовать это, чтобы проверить наше мнение таким образом:

from django.core import mailfrom django.test import TestCasefrom example.core.models import ContactAttemptclass ContactTests(TestCase):    def test_post(self):        with self.captureOnCommitCallbacks(execute=True) as callbacks:            response = self.client.post(                "/contact/",                {"message": "I like your site"},            )        assert response.status_code == 302        assert response["location"] == "/contact/success/"        assert ContactAttempt.objects.get().message == "I like your site"        assert len(callbacks) == 1        assert len(mail.outbox) == 1        assert mail.outbox[0].subject == "Contact Form"        assert mail.outbox[0].body == "I like your site"

Итак, мы используем captureOnCommitCallbacks() по запросу тестового клиента на просмотр, передавая execute флаг, чтобы указать, что фальшивое сохранение (коммит) должно запускать все callbacks. Затем мы проверяем HTTP-ответ и состояние базы данных, прежде чем проверить электронную почту, отправленную обратным вызовом (callback). Наш тест затем покрывает все на просмотре, оставаясь быстрым и классным!

Чтобы использовать captureOnCommitCallbacks() в ранних версиях Django, установите django-capture-on-commit-callbacks.

5. Улучшенный assertQuerysetEqual()

В примечании к релизу говорится:

TransactionTestCase.assertQuerysetEqual() в данный момент поддерживает прямое сравнение с другой выборкой элементов запроса в Django

Если вы используете assertQuerysetEqual() в ваших тестах, это изменение точно улучшит вашу жизнь!

В дополнение к Django 3.2, assertQuerysetEqual() требует от вас сравнения с QuerySet после трансформации. Далее происходит переход по умолчанию к repr(). Таким образом, тесты, использующие его, обычно проходят список предварительно вычисленных repr() strings для вышеупомянутого сравнения:

from django.test import TestCasefrom example.core.models import Bookclass AssertQuerySetEqualTests(TestCase):    def test_comparison(self):        Book.objects.create(title="Meditations")        Book.objects.create(title="Antifragile")        self.assertQuerysetEqual(            Book.objects.order_by("title"),            ["<Book: Antifragile>", "<Book: Meditations>"],        )

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

Из Django 3.2 можно передать QuerySet или список объектов для сравнения, что позволяет упростить тест:

from django.test import TestCasefrom example.core.models import Bookclass AssertQuerySetEqualTests(TestCase):    def test_comparison(self):        book1 = Book.objects.create(title="Meditations")        book2 = Book.objects.create(title="Antifragile")        self.assertQuerysetEqual(            Book.objects.order_by("title"),            [book2, book1],        )

Спасибо Питеру Инглсби и Хасану Рамезани за то, что они внесли эти изменения. Они помогли улучшить тестовый набор Django.

Финал

Наслаждайтесь этими изменениями, когда Django 3.2 выйдет или сделайте это раньше через пакет backport.

Перевод статьи подготовлен в преддверии старта курса Web-разработчик на Python.

Также приглашаем всех желающих посмотреть открытый вебинар на тему Использование сторонних библиотек в django. На занятии мы рассмотрим общие принципы установки и использования сторонних библиотек вместе с django; а также научимся пользоваться несколькими популярными библиотеками: django-debug-toolbar, django-cms, django-cleanup и т.д.

Предисловие

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

Подготовка

У нас есть обычный VPS c ОС Ubuntu, и мы уже написали в PyCharm или в блокноте свой сайт на Django и его осталось всего лишь опубликовать, привязать домен, установить сертификат и в путь.

Первым делом необходимо обновить список репозиториев и установить сразу же пакет nginx:

apt get updateapt get-install nginx

Я решил хранить файлы сайта в каталоге: /var/www/. В данном случае перемещаемся в каталогcd /var/www/и создаем новый каталогmkdir geekheroи получаем такой путь: /var/www/geekhero/

Переходим в новый каталог geekhero:cd geekheroи создаем виртуальное окружение:python3 -m venv geekhero_env

Активируем виртуальное окружение:source geekhero_env/bin/activateи устанавливаем в него Django: pip install Django и сразу же ставим pip install gunicorn

Создаем проект:django-admin startproject ghproj

Далее нужно произвести все первичные миграции; для этого прописываем:python manage.py makemigrations , затемpython manage.py migrate .

После этого создаем административную учетную запись: python manage.py createsuperuser и следуем инструкции.

Далее уже создаем applications, но так как вы читаете данную статью, то вы уже умеете все это делать.

Заходим в Settings.py и прописываем, если отсутствует:
import os в заголовке, остальное в самом низу текстового файла:

STATIC_URL = '/static/'STATIC_ROOT = os.path.join(BASE_DIR, 'static/')

НастройкаGunicorn

Идем в каталог /etc/systemd/system/ и создаем два файла: gunicorn.service и gunicon.socket:

Содержимое файла gunicorn.service:

[Unit]Description=gunicorn daemonRequires=gunicorn.socketAfter=network.target[Service]User=rootWorkingDirectory=/var/www/geekhero #путь до каталога с файлом manage.pyExecStart=/var/www/geekhero/geekhero_env/bin/gunicorn --workers 5 --bind unix:/run/gunicorn.sock ghproj.wsgi:application#путь до файла gunicorn в виртуальном окружении[Install]WantedBy=multi-user.target

Содержимое файла gunicorn.socket:

[Unit]Description=gunicorn socket[Socket]ListenStream=/run/gunicorn.sock[Install]WantedBy=sockets.target

Для проверки файла gunicorn.service на наличие ошибок:

systemd-analyze verify gunicorn.service

Настройка NGINX

Далее идем в каталог: /etc/nginx/sites-available/ и создаем файл geekhero (название вашего сайта) без расширения:

server {    listen 80;    server_name example.com;        location = /favicon.ico { access_log off; log_not_found off; }    location /static/ {        root /var/www/geekhero;           #путь до static каталога    }        location /media/ {        root /var/www/geekhero;           #путь до media каталога    }        location / {        include proxy_params;        proxy_pass http://unix:/run/gunicorn.sock;    }}

Для того, чтобы создать символическую ссылку на файл в каталоге/etc/nginx/site-enabled/необходимо ввести следующую команду:

sudo ln -s /etc/nginx/sites-available/geekhero /etc/nginx/sites-enabled/

При любых изменениях оригинального файла, ярлык из sites-enabled нужно удалять и пересоздавать заново командой выше или выполнять команду:sudo systemctl restart nginx

Финальный этап

Для проверки конфигурации nginx нужно ввести команду:

sudo nginx -t

sudo nginx -tДалее запускаем службу gunicorn и создаем socket:

sudo systemctl enable gunicornsudo systemctl start gunicorn

Для отключения выполняем команды:

sudo systemctl disable gunicorn
sudo systemctl stop gunicorn

Также, эти обе команды пригодятся, если вы будете вносить какие-либо изменения в HTML или python файлы, чтобы обновить свой сайт, но помните, что, если вносите изменения в модели, то обязательно нужно сделать python manage.pymakemigrations <app> и migrate <app> из каталога с проектом.

Для первичного запуска / полной остановки сервиса Gunicorn:
service gunicorn start / service gunicorn stop

Чтобы посмотреть статус запущенного сервиса нужно ввести:

sudo systemctl status gunicornилиsudo journalctl -u gunicorn.socket(с последней командой правильный вывод такой: мар 05 16:40:19 byfe systemd[1]: Listening on gunicorn socket. )

Для проверки создания сокета, необходимо ввести команду:

file /run/gunicorn.sock

Такой вывод считается правильным:/run/gunicorn.sock: socket

Если внес какие-либо изменения в файл gunicorn.service или .socket, необходимо выполнить команду:

systemctl daemon-reload

Если все нормально сработало, то можем запустить nginx:

sudo service nginx start

Получаем сертификат SSL для домена

Установим certbot от Let's Encrypt:sudo apt-get install certbot python-certbot-nginx

Произведем первичную настройку certbot:sudo certbot certonly --nginx

И наконец-то автоматически поправим конфигурацию nginx:sudo certbot install --nginx

Осталось только перезапустить сервис nginx:sudo systemctl restart nginx

Итог

В рамках этой статьи мы разобрали как вывести наш сайт в production, установив Django, Gunicorn, nginx и даже certbot от Let's Encrypt.

Привет, хабровчане. Для будущих студентов курса "Web-разработчик на Python" подготовили перевод материала.

Если мы хотим передать данные из Django в JavaScript, мы обычно говорим об API, сериализаторах, вызовах JSON и AJAX. Обычно дело усложняется наличием React или Angular на фронте.

Но иногда вам нужно сделать что-то быстро и грязное построить диаграмму и не задумываться над инфраструктурой одностраничного приложения.

Обычный подход

Допустим, у нас есть приложение на Django со следующей моделью:

from django.db import modelsclass SomeDataModel(models.Model):    date = models.DateField(db_index=True)    value = models.IntegerField()

И простой TemplateView:

<img alt="Изображение выглядит как текст

from django.views.generic import TemplateViewclass SomeTemplateView(TemplateView):    template_name = 'some_template.html'

Теперь мы можем построить простую линейную диаграмму с помощью Chart.js, и мы не хотим использовать AJAX, создавать новые API и т.д.

Если мы хотим визуализировать простую линейную диаграмму в нашем some_template.html, код будет выглядеть следующим образом (взято из этих примеров):

<canvas id="chart"></canvas><script src="http://personeltest.ru/aways/cdn.jsdelivr.net/npm/chart.js@2.9.4/dist/Chart.min.js"></script><script>window.onload = function () {  var data = [48, -63, 81, 11, 70];  var labels = ['January', 'February', 'March', 'April', 'May'];  var config = {    type: 'line',    data: {      labels: labels,      datasets: [        {          label: 'A random dataset',          backgroundColor: 'black',          borderColor: 'lightblue',          data: data,          fill: false        }      ]    },    options: {      responsive: true    }  };  var ctx = document.getElementById('chart').getContext('2d');  window.myLine = new Chart(ctx, config);};</script>

И получится следующее:

Теперь, если мы захотим построить диаграмму данных, поступающих из SomeDataModel, мы подойдем к этой задаче следующим образом:

from django.views.generic import TemplateViewfrom some_project.some_app.models import SomeDataModelclass SomeTemplateView(TemplateView):    template_name = 'some_template.html'    def get_context_data(self, **kwargs):        context = super().get_context_data(**kwargs)        context['data'] = [            {                'id': obj.id,                'value': obj.value,                'date': obj.date.isoformat()            }            for obj in SomeDataModel.objects.all()        ]        return context

А затем мы визуализируем массив JavaScript с помощью шаблона Django:

<canvas id="chart"></canvas><script src="http://personeltest.ru/aways/cdn.jsdelivr.net/npm/chart.js@2.9.4/dist/Chart.min.js"></script><script>window.onload = function () {  // We render via Django template  var data = [    {% for item in data %}      {{ item.value }},    {% endfor %}  ]  // We render via Django template  var labels = [    {% for item in data %}      "{{ item.date }}",    {% endfor %}  ]  console.log(data);  console.log(labels);  var config = {    type: 'line',    data: {      labels: labels,      datasets: [        {          label: 'A random dataset',          backgroundColor: 'black',          borderColor: 'lightblue',          data: data,          fill: false        }      ]    },    options: {      responsive: true    }  };  var ctx = document.getElementById('chart').getContext('2d');  window.myLine = new Chart(ctx, config);};</script>

Именно так это и работает, но, как по мне, слишком грязно. У нас больше нет JavaScript, но есть JavaScript с шаблоном Django. Мы теряем возможность выделить JavaScript в отдельный файл .js. Также мы не можем красиво работать с этим JavaScript.

Но можем сделать лучше и быстрее.

Добавим остроты

Стратегия следующая:

1. В нашем случае мы будем сериализовать данные через json.dumps и хранить их в контексте.

2. Отрендерим скрытый элемент <div> с уникальным id и атрибутом data-json, а именно с сериализованными данными JSON.

3. Запросите этот <div> из JavaScript, прочитайте атрибут data-json и используйте JSON.parse, чтобы получить необходимые данные.

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

Почти как упрощенный AJAX.

Ниже пример того, как я использую эту стратегию:

import jsonfrom django.views.generic import TemplateViewclass SomeTemplateView(TemplateView):    template_name = 'some_template.html'    def get_context_data(self, **kwargs):        context = super().get_context_data(**kwargs)        context['data'] = json.dumps(            [                {                    'id': obj.id,                    'value': obj.value,                    'date': obj.date.isoformat()                }                for obj in SomeDataModel.objects.all()            ]        )        return context

Теперь извлечем наш код на JavaScript в статичный файл chart.js.

В результате получим some_template.html:

{% load static %}<div style="display: none" id="jsonData" data-json="{{ data }}"></div><canvas id="chart"></canvas><script src="http://personeltest.ru/aways/cdn.jsdelivr.net/npm/chart.js@2.9.4/dist/Chart.min.js"></script><script src="{% static 'chart.js' %}"></script>

Как видите в скрытом div происходит магия. Мы скрываем div, чтобы удалить его из любой верстки. Здесь вы можете дать ему соответствующий id или использовать любой подходящий HTML-элемент.

Атрибут data-json (который необязателен и не является чем-то предопределенным) содержит нужный нам JSON.

Теперь, наконец, мы реализуем следующую простую функцию для получения и анализа необходимых нам данных:

function loadJson(selector) {  return JSON.parse(document.querySelector(selector).getAttribute('data-json'));}

И вот наш chart.js готов:

function loadJson(selector) {  return JSON.parse(document.querySelector(selector).getAttribute('data-json'));}window.onload = function () {  var jsonData = loadJson('#jsonData');  var data = jsonData.map((item) => item.value);  var labels = jsonData.map((item) => item.date);  console.log(data);  console.log(labels);  var config = {    type: 'line',    data: {      labels: labels,      datasets: [        {          label: 'A random dataset',          backgroundColor: 'black',          borderColor: 'lightblue',          data: data,          fill: false        }      ]    },    options: {      responsive: true    }  };  var ctx = document.getElementById('chart').getContext('2d');  window.myLine = new Chart(ctx, config);};

Быстрый и грязный способ для тех, кто просто хочет что-то отправить. А вот и конечный результат:

Дисклеймер

Я не рекомендую вам пользоваться этим подходом для чего-то большего, чем грязное доказательство концепции. Как только ваш код на JavaScript начнет расти, станет сложно его контролировать. Рекомендуется пройти путь SPA с одним из популярных фреймворков (в нашем случае React).

Узнать подробнее о курсе "Web-разработчик на Python".

Посетить Demo day к курсу.

Введение

После того, как мы закончили разработку веб-приложения, оно должно быть размещено на хосте, чтобы общественность могла получить доступ к нему из любого места. Мы посмотрим, как развернуть и разместить приложение на экземпляре AWS EC2, используя Nginx в качестве веб-сервера и Gunicorn в качестве WSGI.

AWS EC2

Amazon Elastic Compute Cloud (Amazon EC2) - это веб-сервис, обеспечивающий масштабируемость вычислительных мощностей в облаке. Мы устанавливаем и размещаем наши веб-приложения на экземпляре EC2 после выбора AMI (OS) по нашему усмотрению. Подробнее об этом мы поговорим в следующих разделах.

NGINX

Nginx - это веб-сервер с открытым исходным кодом. Мы будем использовать Nginx для сервера наших веб-страниц по мере необходимости.

GUNICORN

Gunicorn - это серверная реализация интерфейса шлюза Web Server Gateway Interface (WSGI), который обычно используется для запуска веб-приложений Python.

WSGI - используется для переадресации запроса с веб-сервера на Python бэкэнд.

Мы не будем использовать сервер, который поставляется с django по умолчанию в производстве.

Развертывание приложения

Мы запустим EC2 экземпляр на AWS, для этого войдите в консоль aws.

• Выберите EC2 из всех сервисов

• Выберите запуск New instance и выберите Ubuntu из списка.

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

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

Подключение к Экземпляру

Мы можем подключиться к экземпляру, используя опцию 'connect' в консоли (или с помощью putty или любого другого подобного инструмента ). После подключения запустите следующие команды

sudo apt-get update

Установите python , pip и django

sudo apt install pythonsudo apt install python3-pippip3 install django

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

cd  /home/ubuntu/  mkdir Projectcd Projectmkdir ProjectNamecd ProjectName

Теперь мы поместим наш код по следующему пути.
/home/ubuntu/Project/ProjectName

GitHub

Убедитесь, что ваш код находится в репозитории, чтобы мы могли легко втянуть его в наш экземпляр ec2.

• Перейдите в только что созданную папку (/home/ubuntu/Project/ProjectName/)

• git clone <repository-url>

Это клонирует репозиторий в папку, и в следующий раз мы сможем просто вытащить изменения с помощью git pull.

Settings.py Файл.

Мы должны внести некоторые изменения в settings.py в нашем проекте.

• Вставьте свои секретные ключи и пароли в переменные окружения

• Установить Debug = False

• Добавте Ваш домейн в ALLOWED_HOSTS

BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))STATIC_ROOT = os.path.join(BASE_DIR, static)

Выполните следующие действия, чтобы миграция модели произошла и все статические файлы были собраны в общую папку (путь указан в STATIC_ROOT).

manage.py makemigrationsmanage.py migratemanage.py collectstatic

Установка Nginx

Для установки Nginx выполните команду

 sudo apt install nginx

Есть конфигурационный файл с именем по умолчанию в /etc/nginx/sites-enabled/, который имеет базовую настройку для NGINX, мы отредактируем этот файл.

sudo vi default

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

мы добавим proxy_pass http://0.0.0.0:9000 и укажем путь к нашей статической папке, добавив путь внутри каталога /static/, как указано выше. Убедитесь, что вы собрали все статические файлы в общую папку, запустив команду

manage.py collectstatic

Теперь запустите сервер nginx

sudo service nginx start             #to start nginxsudo service nginx stop              #to stop nginxsudo service nginx restart           #to restart nginx

Установка Gunicorn

pip install gunicorn

Убедитесь, что Вы находитесь в папке проекта, например: /home/ubuntu/Project, и запустите следующую команду, чтобы запустить gunicorn

gunicorn ProjectName.wsgi:application- -bind 0.0.0.0:9000

Теперь, когда мы установили и настроили nginx и gunicorn, к нашему приложению можно получить доступ через DNS экземпляра ec2.

При работе над django-проектом, есть ряд must-have сторонних библиотек, если не хочется бесконечно изобретать велосипед. Средстав отладки sql запросов(debug-toolbar, silk, --print-sql из django-extensions), что-нибудь для хранения древовидных структур, переодических/отложенных задач(кстати, cron-like интерфейс есть у uswgi. EAV всё ещё бывает нужен, хотя часто его можно заменить jsonfield. И одна из таких крайне полезных вещей, но почему-то реже обсуждаемая в сети - FSM. Не так часто почему-то сталкиваюсь с ними в чужом коде.

Практически у каждой записи в БД есть некоторое состояние. Например, для комментария это может быть - опубликован/удален/удален модератором. Для заказа в магазине - оформлен/оплачен/доставлен/возврат и т.п. Причем переход из одного состояния в другое часто бывает размазан по коду и в нем присутствует бизнес-логика, которую надо обильно покрывать тестами(всё равно придется, но можно избежать тестирования элементарных вещей, например, что заказ может перейти в состояние "возврат денег" только после того, как он побывал в состоянии "оплачен".

Вполне логично было бы описывать такие переходы более декларативно и в одном месте. Вместе с необходимой логикой и проверкой доступа.

Вот пример кода из тестов библиотеки django-fsm

class BlogPost(models.Model):    """    Test workflow    """    state = FSMField(default='new', protected=True)    def can_restore(self, user):        return user.is_superuser or user.is_staff    @transition(field=state, source='new', target='published',                on_error='failed', permission='testapp.can_publish_post')    def publish(self):        pass    @transition(field=state, source='published')    def notify_all(self):        pass    @transition(field=state, source='published', target='hidden', on_error='failed',)    def hide(self):        pass    @transition(        field=state,        source='new',        target='removed',        on_error='failed',        permission=lambda self, u: u.has_perm('testapp.can_remove_post'))    def remove(self):        raise Exception('No rights to delete %s' % self)    @transition(field=state, source='new', target='restored',                on_error='failed', permission=can_restore)    def restore(self):        pass    @transition(field=state, source=['published', 'hidden'], target='stolen')    def steal(self):        pass    @transition(field=state, source='*', target='moderated')    def moderate(self):        pass    class Meta:        permissions = [            ('can_publish_post', 'Can publish post'),            ('can_remove_post', 'Can remove post'),        ]

Помимо прочего это прекрасно подходит для rest api. Мы может создавать эндпоинты для переходов между состояниями автоматически. Например, запрос /orders/id/cancel выглядит вполне логичным action`ом для viewset. И у нас уже есть необходимая информация для проверки доступа! А также для кнопочек в админке, и возможность рисовать красивые чарты с workflow :) Есть даже визуальных редакторы workflow т.е. не-программисты могут описывать бизнесс-процессы

Чем более декларативный и обобщенный код мы пишем, тем он надежней. Меньше объем кода, меньше его дублирование, меньше ошибок. Тестирование частично перекладывается на автора библоитеки, и можно сосредоточиться на бизнес-логике уникальной для проекта.