Посты с тегом django (68)

Произвести впечатление любой ценой

Вы когда-нибудь задумывались каким таким магическим образом джанговская админка сияет своим синим стилем в только что созданном проекте? Ведь одна из самых больших проблем у новичков в Джанге - это наладить отдачу статики в проекте, но её даже не надо настраивать чтобы правильно заработала админка!

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

Есть устоявшееся мнение, что у Джанги реальные проблемы с PR'ом и продвижением в массы. Что мол не кричат разработчики и члены сообщества, что вот она какая крутая и что всем надо ею пользоваться. Так у нас свой путь - не надо бить во все колокола, а лишь в нужных местах сгладить углы и сделать вхождение новых людей плавным и беззаботным. Благими намерениями - дорога в ад!

Проза в том, что медиа админки в runserver хендлится специальной WSGI мидлвариной. Причем даже в основном хендлере есть проверка на наличие в урле префикса медии админки и подавлении нотификации о запросе в консоле - чтобы не пугало неподготовленное сознание!:-)

Всё это чревато, т.к. кто-то всё таки в ...

Пространства имен

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

Всё это родилось из идеи иметь несколько админок в одном проекте. И после рефакторинга админки под новые формы это стало возможным. Так же нужно было решить как разделять их урлы и главное как их реверсить по имени. Понятно, что в общем случае имена паттернов урлов разных админок будут пересекаться и однозначно преобразовать имя в урл невозможно. Тогда придумали каждому объекту SiteAdmin давать имя и это имя становилось частью названия паттерна урлов соответствующей админки. Ещё особенностью являлось то, что админка это объект и её урлы скрыты в атрибуте urls, что немного ломало классический способ инклюда урлов Джанги.

Что же сделали? Добавили разделение имен урлов. Причем разделенние на 2 уровня - уровень приложения и уровень инстанса приложения. Так что за приложения и что за инстансы?

Допустим у вас есть приложение foo, в котором присутствует какое-то количество урлов. Раньше хорошей практикой считалось урлы называть с префиксом имени приложения, например foo_index (или ещё каким-то уникальным идентификатором, что делала раньше админка (именем)). Теперь же. использую пространства имен, можно ограничится только index и указать ...

Что такое pip?

Pip это альтернатива easy_install, а как говорят сами разработчики - замена.

Как известно easy_install только часть глыбы под названием setuptools. Много копий сломано по поводу нужно ли такие двухголовое чудовище, которое позволяет продвинутым образом собирать питонячьи пакеты и их устанавливать. Или достаточно стандартного distutils. Вот тут pip выступает как противоположность, говоря - я сборкой пакетов не занимаюсь, а только их ставлю.

Pip может поставить любой пакет собранный при помощи distutils. Причем только source-пакет - никаких бинарных яиц ему и прочих setuptools'овых прибамбасов.

Эта концептуальная простота во многом помогла pip постепенно выйти на уровень широко используемого инструмента в питон-сообществе. Благо и пользоваться им максимально просто:

# pip install wna

где wna - это некий пакет (для примера я возьму код своего блога).

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

Помимо уже собранных source-пакетов pip может брать исходники пакетов из систем контроля версий. Поддерживаются subversion, mercurial, git, bazaar. Делая checkout и устанавливая через python setup.py с ключом devel, дает возможность иметь в папке /src/packet_name/ исходный код и при необходимости редактировать его.

# pip install -e hg+http://bitbucket.org/daevaorn/turbion/#egg=turbion

Где egg=turbion говорит pip чтобы он сделал checkout ...

Виджет на морде

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

Django-Yandex

Обновленная Яндекс.Афиша работает на Джанге. Вот уже третий месяц как. Запустили мы её прямо в канун пятницы тринадцатого в марте!

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

Глобальная цель была - обновить движок Яндекс.Афиши, переписав его на Django.

Что да как

Распил кода КВИ

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

Мы резонно решили, что, переписывая Афишу на Джанге, нужно опираться уже на имеющийся code base КВИ.

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

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

Djapian: версия 2.2.1 - хотфиксы

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

Для проверки я решил найти или на худой конец намайнить какой-то большой массив данных и его проиндексировать. Подумав, решил что что-то типа википедии будет в самый раз. Быстро нашел xml дамп русской википедии и попробовал его залить в базу, а потом проиндекcировать. Для оперативности ограничился числом в 150К статей.

При тестировании действительно выяснилось, что с включенными транзакциями индекс обновляется очень медленно - примерно 0.5 док/сек. Причем виноваты не сами транзакции, а то что при каждом комите происходил flush базы. Отключив flush, производительность индексирования выросла в разы - до 15-20 док/сек, что уже очень не плохой показатель.

В итоге в хотфикс релизе я добавил возможность управлять транзакциями (по умолчанию они выключены) и сбросом кеша в базу через опции команды index - --transaction и --flush:

  • --transaction - включает использование транзакций
  • --flush - включает сброс файлового кеша при обновлении каждого документа

Ещё изменил политику работы с большим числом объектов в очереди индексирования. Теперь они обрабатываются постранично и не сжирают кучу виртуальной памяти из-за нерадивых client-side курсоров БД. Это тоже могло приводить к активному свопингу и ухудшению производительности.

Djapian стал ещё производительнее и лучше:-)