Mingus: за что я его ненавижу

   mkvirtualenv myblog —-no-site-packages
   workon myblog
   cdvirtualenv
   git clone git://github.com/montylounge/django-mingus.git
   cd django-mingus/mingus
   pip install -r stable-requirements.txt
   cp local_settings.py.template local_settings.py
   ./manage.py syncdb
   ./manage.py loaddata test_data.json
   ./manage.py runserver

   from django.conf import settings
   post_list_count = getattr(settings, "post_list_count", 20)

   BLOG_PAGE_SIZE = 20

Есть и более продвинутые:

   DEBUG_TOOLBAR_PANELS = (
       'debug_toolbar.panels.version.VersionDebugPanel',
       'debug_toolbar.panels.timer.TimerDebugPanel',
       'debug_toolbar.panels.settings_vars.SettingsVarsDebugPanel',
       'debug_toolbar.panels.headers.HeaderDebugPanel',
       'debug_toolbar.panels.request_vars.RequestVarsDebugPanel',
       'debug_toolbar.panels.template.TemplateDebugPanel',
       'debug_toolbar.panels.sql.SQLDebugPanel',
       'debug_toolbar.panels.signals.SignalDebugPanel',
       'debug_toolbar.panels.logger.LoggingPanel',
   )

Какое решение здесь возможно? Помимо простого размещения ключ/значение, в каждом приложении может также быть обработчик. В Django, конечно, есть обработчики по умолчанию, такие как IntegerSettingHandler, StringSettingHandler, и т. д. Но в приложении типа django-debug-toolbar будет обработчик DebugToolBarHandler. Это позволит приложению Настройки иметь стандартный API, через который любое приложение сможет связываться с ним через API Настроек, но каждое отдельное приложение предоставляет логику своего собственного обработчика для выполнения у себя своих правил. Или я просто псих?

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

Сейчас, если я собираюсь добавить в Mingus новое приложение, я стараюсь помнить о потребностях нетехнического конечного потребителя. Захотят ли они иметь возможность изменять эти настройки через панель управления? И если да, и если повторно применяемое приложение определяет запрашиваемое значение settings.py, мне нужно принять непростое решение. Надо ли здесь создать fork приложения, и добавить в модель настройки, которые можно обновлять через панель управления администратора [3], или же надо отказаться от этой идеи, в том числе и от сохранения других значений в settings.py проекта?

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

Можно получить это с помощью этих настроек. Или других настроек.

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

В Mingus я создаю два файла настроек:

1. settings.py
2. local_settings.py

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

Я неоднократно сталкивался с такой концепцией, работая с другими проектами, и в итоге остановился на этом простом паттерне.

Но это еще не окончательный ответ. В сообщении "Усовершенствование локальных настроек"_ в своём блоге Дэниэль Линдси (Daniel Lindsey) предлагает одно конкретное решение. Но если вы заглянете в комментарии к этому сообщению, вы увидите несколько альтернативных решений. Всё это подчёркивает необходимость введения общего стандарта. На самом деле, популярный подкаст DjangoDose в Handling Development, Staging, and Production Environments предложил своё решение с использованием концепции FLAVOR. Но опять же, если взглянуть на наиболее удачные из примеров в комментариях, то мы увидим целый букет альтернативных решений, применяемых другими разработчиками.

Один из разработчиков Mingus предложил мне взглянуть на довольно любопытную документацию команды Transifix Using a list of conf files , посвящённую тому, как они довольно успешно справились с управлением файлами настроек. Уже сам тот факт, что в принципе существует статья в википедии, посвящённая различным способам управления файлами настроек, подчёркивает необходимость введения стандартов в этом направлении.

Недавно я нашёл один проект, Django-Config (разработчики - Ноуэлл Стрит, Шон Райдер, сейчас поддержку осуществляет Тэррек Хоссейн.) Оба они, Стрит и Райдер, работают в PBS, и недавно подробно разбирали сложности, с которыми сталкиваются разработчики различных проектов и повторно применяемых приложений в инфраструктуре в своей презентации на конференции DjangoCon2009 Pluggable, Reusable Django Apps: A Use Case and Proposed Solution.

Django-Config определяет самого себя как "... простой способ поддерживать несколько конфигураций для Django. Он основан на концепции, включающей в себя создание общего конфигурационного файла, при этом конфигурационный файл для каждого пользователя (или для каждого сервера) сочетает в себе базовую и пользовательскую конфигурацию и загружает её." Самому мне ещё только предстоит запустить такой проект, но, учитывая сложность поддерживаемой в PBS инфраструктуры, я верю, что где-то там в недрах уже есть скрытые самородки, проверенные и доведённые до совершенства.

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

Статичные данные? Неужели!

Любой, кто когда-либо создавал в Django повторно применяемые приложения, задавал себе вопрос: где разместить статичные данные? Какое название задать для директории? Назвать директорию static или назвать её media? Где именно расположить её в файловой системе?

Прекрасным примером является повторно применяемое приложение Симона Уиллисона django-cropper, которое я недавно интегрировал в Mingus. Уиллсон недавно оставил commit message: «Наконец получилось сделать так, чтобы пакет включал в себя шаблон... И тем не менее я понятия не имею, что мне делать с зависимостями от статичных данных.» Это хороший вопрос. Что делать разработчику с зависимости от статичных файлов? Включаются ли файлы в проект? Или же надо инструктировать пользователя, что эти данные загружаются с XYZ? И если файлы включены в проект, то где они располагаются в самом приложении?

Я считаю, что ответом здесь служит Django-StaticFiles.

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

Загрузите это

Раз уж мы заговорили об управлением данными, поговорим и о загружаемых посредством панели управления Django файлах. Я считаю, что здесь тоже должно быть какое-то традиционное общепринятое решение - директория /uploads/ внутри MEDIA_ROOT. Слишком часто, начиная работу с приложением, я вижу такое:

   photo = models.ImageField(upload_to="/images/")

Это вообще не работает. Общепринятым по умолчанию должно стать решение MEDIA_ROOT +" /uploads/APP_NAME/ " и любые директории, определяемые параметром "upload_to", присоединяются директории по умолчанию, как, например, в моём приложении Photobooth:

   photo = models.ImageField(upload_to="images")

По умолчанию результат загрузится в директорию MEDIA_ROOT + /uploads/photobooth/images/.

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

Никто не уважает i18n

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

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

   from django.utils.translation import ugettext_lazy as _
   ...

   class Post(models.Model)
       description = models.TextField(_('description),
       help_text=_('The description of your post'))

       class Meta:
           verbose_name = _('post')
           verbose_name_plural = _('posts')
   ...

И всё, что надо теперь сделать в шаблонах для вывода текста, это следующее. Например, для landing.html:

   {% load i18n %}
   
{% trans "Blog roll" %}

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

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

• Django-Rosetta
• Django-DataTrans

Взгляните также на эту прекрасную статью, в которой приведён обзор ряда повторно применяемых приложений, облегчающих интеграцию в i18n - Dynamic Translation Apps for Django. Дело в том, что это очень, очень плохо, не переводить ваше приложение на другие языки. Нет, серьезно, если вы не интернационализируете ваше приложение, вы создаёте головную боль другим разработчикам, и, что ещё более важно, вы ещё и ограничиваете потенциальное дальнейшее распространение вашего проекта. Так что ведите себя хорошо, и обучите этого плохого мальчика другим языкам.

Всё дело в миграции

Во всех повторно применяемых приложениях, которые мы публикуем, мы должны начать использовать South! Или нам нужно чтобы разработчки Django удовлетворили мой pony request. В своём сообщении South and Reusable Apps я упоминал об этом, но сейчас я хочу ещё раз поднять вопрос актуальности общего выбора инструмента миграции.

В статье Reusable Apps in Django Panel на DjangoDose мы говорили о том, что в настоящий момент лучшим инструментом для миграций себя показывает South . Поскольку управление миграцией в принципе довольно редко практикуется в большинстве приложений, то и нет простого способа для миграции пакета приложений. И опять, винить в этом нужно именно меня. Но теперь с этим покончено. Мы двигаемся вперёд, и теперь все ставки делаем на South.

South действительно может упростить это всё для нас, разработчиков. Именно это предложение я сделал в вышеупомянутой публикации в блоге. Андрей Гудвин, автор South, отметил, что решение для мигрирующих повторно применяемых приложений, которые сами по себе не используют South, уже в работе. Это решение ожидается к выходу в ближайшей версии South. То есть, ещё не вся надежда потеряна. Эта функция позволит разработчикам создавать миграции South для повторно применяемых приложений, даже если в самих этих приложениях South не используется вообще. Потрясающе!

В данный момент Mingus предоставляет только один тип миграции (raw SQL), но даже и его не было до недавних пор, когда Mingus стали использовать в качестве движка для создания блогов. Зная это, было бы небрежностью с моей стороны не предоставить возможность использовать миграции для пользователей, которые с нетерпением ждут выхода нового релиза Mingus. Пока что у них для этих задач есть только raw SQL, но это совсем не то, что нужно. А нужно тут применять стандартные инструменты миграции, которые мы все и применяем.

Ключи кэша правят миром

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

Так почему не завести здесь какого-нибудь помощника, упрощающего эти задачи? Именно это я и сделал, добавив create_cache_key в django-sugar. Метод на самом деле совмещает в себе код одного сообщения блога и повторно применяемое приложение:

• Improving Django Cache
• Django-Caching

Вот, посмотрите на API:

   from blog.models import Post
   slug_val = 'some-slug'
   mykey = create_cache_key(Post, 'slug', slug_val)
   obj = cache.get(mykey)

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

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

Заключение

Django - вот причина, почему я так люблю придираться к Mingus. Я люблю Django и Python. И на самом деле это моё негодование - всего лишь маленькое пятнышко на потрясающе приятном путешествии в компани с Django.

В будущем будет выпущена финальная версия Mingus 1.0, в которой будут исправлены ошибки, добавлено ещё больше документации, и ещё больше тестов. Мало что ещё можно добавить к тому, что по сути является концепцией проекта, так что я думаю, что текущий набор функций будет окончательным.

Я благодарю тех, кто разрабатывает проект с открытым кодом любого направления, и я снимаю перед вами шляпу. Как и вы, я с нетерпением жду тех потрясающих вещей, которые ожидаются с выходом Django 1.2. Будучи пользователем такого грандиозного открытого проекта, я считаю, мне повезло, что ежедневно приходится работать с Django. И кстати я только что понял, что я и был «тем парнем» для большинства из рассмотренных в этой статье методов, и ненавижу себя за это.

Кевин Фриковски - основатель Monty Lounge Industries, LLC, где он также ведёт блог про Django, про веб-разработку, дизайн и про юзабилити. Он состоит в команде DjangoDose, и является одним из основателей Django-NYC. Свои репозитории ПО с открытым кодом он поддерживает на GitHub. Его твиттер - @montylounge. У него двое детей и очаровательная жена. Что касается работы, он глубоко уверен, что ему просто повезло, что приходится работать с Python и Django.