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

Очерёдность с syncdb

Одно из выбранных решений django-evolution — невмешательство в дела команды syncdb. То есть, django-evolution никогда не пытается выполнять SQL код для создания таблиц.

Первое неудобство в этом для нас — более сложный процесс составления миграционного SQL’а. Дело в том, что наши админы не шибко любят запускать изменения в базах всякими неконтролируемыми тулзами, а просят присылать им SQL-скрипты. Django-evolution умеет генерить SQL своих эволюций, а SQL для создания таблиц приходится вырезать руками из базы отдельно.

Но гораздо хуже другое. Представьте, что в процессе миграции базы с достаточно старой версии есть и новые модели, и эволюции, применяемые к этим моделям. Поскольку создавать таблицы надо отдельной командой, надо помнить, что этот SQL должен обязательно идти до эволюций. Несколько муторно. Теперь представьте, что среди эволюций есть переименование одной таблицы (соответствующее переименованию модели). С точки зрения syncdb таблицы для нового имени модели нет, и она её создаст. От этого эволюция переименования накроется, потому что таблица уже существует.

Приехали — есть эволюции, которые надо запускать до syncdb, а есть те, которые после. Соответственно, процесс превращается в совсем ручной cherry-picking.

Были ещё какие-то частные случаи, когда важен порядок применения syncdb и evolve, и в итоге, чтобы избавиться от этих проблем, мы стали вносить создания таблиц в эволюции вручную.

Написание симуляций

Кто не знает, в django-evolution есть интересная фича: она умеет не применять эволюции непосредственно к базе, а прогнать их сначала вхолостую (”simulate” в терминах приложения). Делается это не реально в БД, а спомощью выполнения специально написанных функций, которые меняют сигнатуру проекта — представление текущего вида моделей в памяти. Это примерно такой словарик:

{
    'myapp': {
        'MyModel1': {'fields': [ ... ], 'meta': [ ... ]},
        'MyModel2': {'fields': [ ... ], 'meta': [ ... ]},
    }
}

Идея состоит в том, что django-evolution берёт сохранённую сигнатуру из БД, которая соответствует предыдущему её состоянию, и протаскивает её через симуляционные функции всех неприменённых эволюций. Они меняют сигнатуру в памяти, и если в конце она соответствует тому, какая у вас модель в Питоне сейчас описана, django-evolution рапортует, что наличествующих эволюций достаточно для того, чтобы проапгрейдить базу.

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

Хуже того, многие симуляции нужны только для того, чтобы evolve перестал жаловаться на несовпадение при симуляции, потому что в этом случае он отказывается что-либо делать вообще. Ни применить эволюции, ни SQL для них вывести. Нет у него ключика --force…

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

В итоге по факту оказывается, что ещё не было ни одного релиза у нас, когда бы мы не тратили немало времени на то, чтобы дописывать код только для того, чтобы evolve хотя бы просто запускался поверх довольно старой версии БД. То есть по очереди во время разработки всё вроде применилось, а вот скопом — нет.

Hint’ованные и сохранённые эволюции

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

Теперь представьте себе вполне обычный workflow:

• разработчик делает изменения в модели
• через evolve --hint -x отражает его в БД
• тестирует, отлаживает

Теперь, чтобы это скоммитить, надо обязательно записать проведённые эволюции в виде файла, чтобы автоматически апгрейдить другие БД. А откуда вы теперь эти эволюции возьмёте? Всё ведь уже применено.

Казалось бы, можно ввести в процесс разработки правило, что никогда нельзя применять hint’ованные эволюции, а делать их только в виде файлов. Но во-первых, слишком много таких “гигиенических” правил сильно нагружают голову, а во-вторых это просто не работает. Потому что не родился ещё тот разработчик, который бы с первого раза писал правильный код, в том числе и при изменении схемы БД. Всегда нужно что-то переделать по результатам отладки.

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

Наличие двух видов эволюций мне сейчас кажется, пожалуй, главным архитектурным изъяном django-evolution. Хотя может быть, мы просто не поняли, как этим пользоваться…

Ключик “всё хорошо”

Обратная ситуация тоже частенько случается: у вас есть некая база, в которой что-то переделано вручную, что-то откуда-то сдамплено/скопировано. Однако программист уверен, что она соответствует тому, что есть в моделях. А команда evolve — нет. Потому что в базе не записано, что были применены сохранённые эволюции, она пытается их симулировать и находит ошибки от повторного применения.

К сожалению, у команды evolve нет никакого ключика, чтобы сказать базе: “всё применено руками, просто запиши новое состояние и считай, что все эволюции применены”. Да, считается, что при использовании django-evolution нельзя лезть в БД руками. Но я поверю в практичность такого подхода, когда оно само будет работать идеального. А пока реальность такова, что в базу приходится лазить руками.

Не фиксируются отдельные эволюции

Даже для многих админов БД является откровением, что PostgreSQL умеет делать DDL в транзакциях. Ни одна другая СУБД из набора Джанги этого не умеет, даже Oracle. И надо ж случиться такому совпадению, что ядрёныекорные разработчики Джанги предпочитают именно Postgres. Рассел (автор django-evolution), кажется, тоже его предпочитает. Никак иначе я не могу объяснить то, что применяемые эволюции фиксируются как выполненные только по успешному завершению всей последовательности эволюций.

Представьте себе теперь типичную ситуацию выезда в продакшн на MySQL-сервере какой-нибудь напряжённой итерации разработки. Применямых эволюций там — десяток. И на разработческой базе они прекрасно применялись. А вот на живы данных — упали. Где-то в середине. С Postgres’ом бы не было проблем, транзакция бы не скоммитилась. Но у нас вот часть изменений применилась, а часть нет. Какая именно часть применилась, django-evolution в БД не записал. И теперь, если начать миграцию заново, оно будет пытаться применять уже применённые вещи, и напарываться на всякие “already exists” для создаваемых полей и “not exists” для удаляемых.

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

Эволюции лежат в приложениях

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

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

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

Что вместо?

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

Видимо, это будут dmigrations. Миграции там хранятся в отдельной директории, применяются только из сохранённых файлов, и там есть ручной контроль — команда mark_as_applied. Очень похоже, что их авторы исходили из очень практических use-case’ов и наступали на похожие с нашими грабли.

South решили не пробовать. Саша утверждает, что он “ещё хуже”, чем django-evolution :-). А остальным разработчикам, включая меня, кажется, должно быть всё равно, потому что не работали ни с South, ни с dmigrations.

Посмотрим, что получится.

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

Сигналы синхронны

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

Но сигналы тут совсем ни причем. Не знаю, откуда берется идея, что они выполняются в каком-то другом времени. Возможно из-за того, что механизм их работы где-то там в глубине скрыт, и просто хочется верить, что сделано так как раз для асинхронности (а для чего ещё?). А может виной всему опыт использования POSIX’овых сигналов, которые присылаются ОС в некие произвольные моменты времени и с точки зрения программы действительно происходят асинхронно с её процессом исполнения.

На самом же деле механизм вызова сигнала по сути своей прост, как доска. Точнее, как цикл “for”. Представьте, что у вас где-то в системе есть глобальный словарик такого рода:

signals = {
    signal1: [func1, func2],
    signal2: [func3],
}

И вызов например signal1.send(*args) — это:

for func in signals[signal1]:
    func(*args)

Вот и всё. И пока весь цикл не пройдёт и все обработчики не отработают, вызов “send” будет честно их ждать.

Слабая связанность компонентов

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

Представим для примера некий гипотетический Форум, в котором есть авторизация по OpenID. Когда в форум приходит новый пользователь, код авторизации заводит новую запись форумного Профиля для этого пользователя. Делает он это самым простым и очевидным способом: импортирует модель Profile и создает её новый объект.

Теперь представим, что нам хочется оторвать авторизацию по OpenID в отдельное приложение — некий гипотетический Правильный OpenID-консумер. Просто перенести весь авторизационный код в отдельную директорию недостаточно из-за сильной связности: Авторизация всё ещё импортирует к себе модель Форума Profile, а значит её нельзя будет использовать как отдельное приложение без Форума.

Это как раз и решается сигналами. Вместо того, чтобы звать Форум напрямую, Авторизация в момент осознания, что с ней случился новый пользователь, отсылает в Бесконечный Эфир сигнал. Это специальный сигнал, описанный специально для такой оказии где-то в коде Авторизации и основательно документирован. Со своей стороны Форум импортирует определение сигнала из Авторизации и начинает его слушать, повесив на него в качестве реакции свою функцию, создающую новому пользователю профиль.

Таким образом мы получаем связь с однонаправленной зависимостью:

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

• Авторизация слабо связана с (не зависит от) Форума, потому что предоставляет свой сигнал для любого потребителя и благодаря тому, что те навешивают обработчики сигналам по собственной инициативе, она не зависит от их наличия, количества или сущности.

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

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

Одна из когда-то давно слезно просимых фич — загрузка объектов с неполным списком полей (aka “defer/only“). Раньше это делалось через .values(), но результатом запроса был тупой набор значений. Новая фича возвращает полноценные объекты с недозаполненными полями. Поля заполняются отдельными запросами при первом обращении.

Теперь, по меткому выражению Малколма все кинутся этим пользоваться, потому что оно кажется очень крутым. Грустная ирония состоит в том, что если вы думаете, что вам нужны defer/only, это с высокой вероятностью либо преждевременная оптимизация, либо указание на неудачную модель базы. То есть, либо вы Реально Большие BLOB’ы храните в базе, вместо файлов, либо у вас в модели куча полей, которые можно и нужно разнести по разным моделям, провязанным один-к-одному. Впрочем, ладно, разберемся :-)

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

• можно выдать юзеру свое сообщение типа “удалено столько-то объектов”
• можно вместо возвращения управления в админку передать объекты в свою вьюху, если над ними нужны какие-то многоходовые издевательства
• действие можно повесить как на одну модель, так и глобально для всех

А, да… Включенный сейчас по умолчанию “удалить все объекты” обещали сделать отключаемым. Не всем это надо :-)

Также совршенно нежданно-негаданно Малколм нашел время добить и скоммитить мой декоратор condition, который я когда-то писал для Cicero. Малколм его обобщил до работы не только с GET’ом, но и с остальными методами (PUT, POST, DELETE), которые могут обрабатывать ETag’и. Теперь Джанго реагирует на нужные заголовки с правильными HTTP-кодами. Ура! Писать REST-сервисы на Джанго теперь еще приятнее!

Ну и на закуску немножко приятных багфиксов:

• 7295: в шаблонных тегах теперь можно использовать кавычки любого типа

• 5756 и 6296: в параметрах шаблонных тегов теперь можно использовать фильтры (всеми любимый {% ifequal list|length 5 %} теперь должен работать)

• 2698: наконец обработаны все краевые случаи с обращением к родительским объектам при использовании фильтрующих менеджеров по умолчанию (читай: теперь это можно делать без опасения наступить на туманные грабли)

• 8164: в ModelForms теперь можно удобно задавать порядок и полей модели и дополнительных полей формы

• 10194: появилась умная функция django.shortcuts.redirect(), которая принимает всякие значения и делать The Right Thing™. Например вместо:

  from django.core.urlresolvers import reverse
  from django.http import HttpResponseRedirect
  ...
  return HttpResponseRedirect(reverse(viewname, args=[param]))
  

  теперь достаточно:

  from django.shortcuts import redirect
  ...
  return redirect(viewname, param)
  

А у вас есть любимые фички в этом релизе?

Я всегда пропагандировал простой способ: прокидывать в шаблоны переменную MEDIA_URL, используя стандартный контекст-процессор media. А в шаблоне просто составлять слова рядом:

<link rel="stylesheet" href="{{ MEDIA_URL }}css/style.css">

Это типа работает, но у такого способа есть пара минусов:

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

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

• В простейшем случае он просто присоединяет имя файла к MEDIA_URL:

  {% media "images/edit.png" %}
  

  Однако если параметр начинатся со слеша или с протокола (”http://”), то он уже не будет присоединяться к MEDIA_URL.

• Можно добавить флажок, чтобы ссылка всегда была абсолютной:

  <!-- /media/edit.png становится http://example.com/media/edit.png -->
  {% media "images/edit.png" "absolute" %}
  

• Можно добавить к файлу timestamp по времени обновления, что очень полезно для css- и js-файлов, чтобы при изменении их на сервере, браузер автоматически получали новую версию без необходимости заставлять юзеров вручную рефрешить страницу. Больше того, для css- и js-файлов это включено автоматически. Поведение это явно можно включать и выключать флажками “timestamp” и “no-timestamp”

  {% media "css/style.css" %}                <!-- ...style.css?123456789 -->
  {% media "css/style.css" "no-timestamp" %} <!-- ...style.css -->
  {% media "images/edit.png" "timestamp" %}  <!-- ...edit.png?123456789 -->
  

Флажки “timestamp”, “no-timestamp” и “absolute” можно использовать одноврменно (через запятую).

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

def _absolute_url(url):
    if url.startswith('http://') or url.startswith('https://'):
        return url
    domain = Site.objects.get_current().domain
    return 'http://%s%s' % (domain, url)

@register.simple_tag
def media(filename, flags=''):
    flags = set(f.strip() for f in flags.split(','))
    url = urlparse.urljoin(settings.MEDIA_URL, filename)
    if 'absolute' in flags:
        url = _absolute_url(url)
    if (filename.endswith('.css') or filename.endswith('.js')) and 'no-timestamp' not in flags or \
       'timestamp' in flags:
        fullname = os.path.join(settings.MEDIA_ROOT, filename)
        if os.path.exists(fullname):
            url += '?%d' % os.path.getmtime(fullname)
    return url

Вот! Подробности позже. И, наверное, даже не у меня…

Особо приглянувшиеся мне вещи:

• Store.objects.annotate(Count('books__authors'))

  Store — это магазин, у него many-to-many на Book, у которого есть many-to-many на Author. Тут делается join по всем нужным таблицам и group by на них.

• Book.objects.annotate(num_authors=Count('authors')).filter(num_authors__gt=1)

  Я очень рад, что having не стали делать отдельным понятием. Это просто фильтр. А уж having там или where — пусть оно само разбирается.

А также вместе с этим в транк приехали и выражения со ссылкой на поля (по крайней мере, должны были, я не проверял :-) ).

И вот на днях, в процессе переписывания TaCo на Джанго (да, я таки занялся) я обнаружил в джанговских формах фичу, про которую как-то нигде “официально” не рассказывали.

Задачка

Пусть у нас есть Маша и Саша, которые работают в багтракинге над одним проектом. Маша открывает баг про падение программы, и, словив озарение, начинает его тут же фиксить, потому что работы там на 10 минут. Через часок она понимает, что починить все так просто не получилось и решает отложить работу. Перед тем, как пойти налить кофейку, она переключается обратно в окно браузера с багом и переводить его в статус “In progress”.

Беда в том, что в это же время Саша, который взял на себя обязанности пастуха багтракинга, тоже нашел этот баг и, справедливо подумав, что падение программы — проблема серьезная, адекватно поменял поле severity на “Major”.

Так вот, если сабмит формы тикета обрабатывать стандартным образом, то Машин перевод тикета в “In Progress” помимо этого вернет ему severity в “Normal”, потому что именно в таком виде она открыла эту форму час назад.

Решение

TaCo решал эту проблему. Вместо того, чтобы сохранять в тикет данные из формы целиком, он определял, какие именно поля в этой форме пользователь поменял, и применял только эти изменения. То есть, в нашем случае от Маши пришло бы только указание “поменять статус”, и severity остался бы нетронутым.

Реализовано это самым очевидным способом: в форме вместе с видимыми юзеру полями рисуются их скрытые дубликаты с именами типа “OldSeverity”, “OldOwner” и т.д. При сабмите из формы вынимаются поля и их старые значения, по которым выясняется, что поменялось.

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

Django

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

Включается это для отдельных полей указанием атрибута show_hidden_initial:

class TaskForm(forms.Form):
    severity = forms.ChoiceField(..., show_hidden_initial=True)
    owner = forms.ChoiceField(..., show_hidden_initial=True)
    # ...

После валидации у формы будет доступен form.changed_data — список с названиями измененных полей, который уже можно использовать по своему усмотрению. Например:

if form.is_valid():
    for fieldname in form.changed_data:
        setattr(obj, fieldname, form.cleaned_data[fieldname])
    obj.save()

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

P.S. Я заодно подпилил TagsField, чтобы он поддерживал этот параметр. Правда не опубликовал еще.

Сайт SoftwareManiacs.Org работает на VPS-сервере (у компании TekTonic) и представляет собой сборную солянку из технологий:

• блог — вполне себе стандартный WordPress с парой плагинов и собственной темой, которую я меняю раз в год в начале мая
• форум, каталог программ, статистика и about — мои собственные программы, написанные на Django
• еще wiki (DokuWiki) и багтракинг (самописный), которые используются исключительно для личных целей

Меня периодически спрашивали, как это все интегрировано. Очень просто — на уровне конфига веб-сервера (lighttpd), который раздает задачки трем бэкендам:

• FastCGI-сервер со всем Джанго-кодом
• PHP через FastCGI для всего PHP-кода (wiki и блог)
• FastCGI-сервер для багтракинга

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

Открытие исходников

Идея выложить свои приложения у меня созрела давно, и причина этому очень простая: вдруг кому что полезно будет. Тем не менее, не все они, что называется, “коммерческого” качества. К таким я с чистой совестью могу отнести только Cicero и Vooid, которые можно брать и устанавливать. Два других — Soft и SaneStat — это скорее код, в который можно просто полюбопытствовать.

Все исходники выложены просто в виде ссылок на Bazaar-бранчи, без всяких красивых интерфейсов и без всякой сопроводительной инфраструктуры типа публичного багтракинга и wiki. Сделано так намеренно. Дело в том, что равносильно желанию поделиться, у меня существует осознание, что я не смогу находить время, чтобы поддерживать все эти вещи как нормальные открытые проекты. Иначе бы просто выложил все на Google Code, где уже все это есть. А пока, я буду рад всяким советам, сообщениям о багах и патчам, но надеюсь, что их количество не сведет меня с ума :-)

Soft

Выкладывание программок собственного сочинения было первым назначением моего сайта. В те времена (2000 год где-то) у него еще не было собственного домена (хотя адрес http://www.mtu-net.ru/maniac/ до сих пор правильно редиректит!), и весь сайт, как наверное у многих, представлял собой набор статичных HTML-файлов. Довольно быстро это стало очень неудобно поддерживать по очевидным причинам. Но я мучился до 2005 года :-). И только тогда, когда я “заболел” Джангой, я сподобился сделать софтинку, которая бы позволяла выкладывать программы и обновления к ним автоматизированным способом.

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

В итоге “soft” — это достаточно узконаправленная программа, в которой, тем не менее, есть кое-что интересное для внешнего наблюдателя.

• Реализовано достаточно элегантное решение мультиязычного контента. В итоге, сейчас у меня есть программы на двух языках (highlight.js, TagsField, mysql_replicated), у которых переведено все вплоть до новостей. Все это достаточно удобно рулится из админки.

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

Следующее, что мне очень хочется туда привернуть — это выкладывания новых версий программ. Сейчас мне приходится руками ходить на сервер, чекаутить последние версии из репозиториев, упаковывать архивы и раскладывать все в нужные места. Хочется это все делать в рамках джанговской админки, просто создавая новый объект “Релиз”, который будет делать все сам через шеллный скрипт, привязанный к каждой конкретной программе.

SaneStat

Эта штука началась с простого питоньего скрипта, который парсил апачевский лог в поисках рефереров, которые на меня ссылаются. Этот же скрипт простыми print’ами выводил и HTML, когда вызывался по CGI. Это, опять-таки, было медленно и неудобно, поэтому было переведено под Джанго. Как и у любого парсера логов, у него есть две части — собственно парсер, который оформлен в виде команды для manage.py, вызывающейся из крона, и набора вьюшек, которые передают в шаблоны результаты этого парсинга.

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

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

Все остальное

Все остальное в джанго-части сайта реализовано стандартными джанговскими приложениями: admin, flatpages, redirects. Я слышал мнение, что джановский контриб бесполезен для чего-то реального, но могу это авторитетно опровергнуть. Его вполне можно использовать, надо только знать ограничения и не хотеть слишком многого.

Админка используется у меня по прямому назначению: редактирование программ, добавление рефереров в базу статистики, редактирование about’а и т.д. Практически не кастомизирована. Самый сложный экран — это пожалуй редактирование программы с кучей inline’утых линков и переводов:

На flatpages реализуется все, что либо статично по сути, либо еще не стало повторяться настолько часто, чтобы хотелось написать под это код. Яркий пример первого случая — about. Просто flatpage с кастомным шаблоном. Пример второго случая — описание создания языков для highlight.js. Пока такой документ единственный в своем роде. Если вдруг другие программы начнут обзаводиться похожими вещами, допишу для этого немножко когда в приложение soft. Так и живем :-).

Расположение проекта

На сервере все это у меня лежит, как и положено по best practices джанго-проектов. Проект — отдельная папка с настройками, конфигами, шаблонами и локализацией. Приложения — в совершенно другой отвлеченной папке. Что как раз и позволяет выложить приложения в мир, потому что они не привязаны жестко к сайту. В итоге INSTALLED_APPS в настройках выглядит довольно длинно:

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.admin',
    'django.contrib.admindocs',
    'django.contrib.flatpages',
    'django.contrib.redirects',
    'common',
    'soft',
    'hljs_download',
    'vooid',
    'sanestat',
    'cicero',
    'cicero_punbb_import',
)

И все это нужно :-).

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

Речь идет о тикете 7210 — “Added expression support for QuerySet.update”. Это про то, что сейчас джанговский ORM не умеет создавать SQL для условий в запросах, в которых есть а) выражения:

update page set views_count = views_count + 1 where id = 123;

б) поля в качестве значений:

select * from employee where current_salary > start_salary;

Теперь это можно будет делать.

Загвоздка

Но самое интересное — это синтаксис, которым такие штуки записываются. В нем, собственно, и была главная загвоздка, почему этой фичи не было в ORM еще давно. Действительно, если написать все как есть, то получится:

# вместо увеличения на единицу текущего значения Питон увеличит локальну переменную 
# views_count, которой еще и нет наверняка
Page.objects.filter(pk=123).update(views_count=views_count + 1)

# вместо поля start_salary будет использована строка "start_salary", которая свалится
# на приведении к числу
Employee.objects.filter(current_salary__gt='start_salary')

F-объект

Проблему решили введением специального объекта, который означает “поле в этом запросе”. И назвали его, что важно, кратко — F. В итоге оба примера начинают выглядеть вот так:

Page.objects.filter(pk=123).update(views_count=F('views_count') + 1)
Employee.objects.filter(current_salary__gt=F('start_salary'))

Кода придет время формировать SQL, объект запроса будет знать, что F-объект содержит в себе название поля. С вытекающим отсюда правильным экранированием и т.д.

Минуточку…

Раз F — объект для отложенного хранения имени поля, то как работает конструкция F('views_count') + 1? Оказывается, F переопределяет для себя все имеющие смысл математические операции методами __add__, __sub__, __mul__ и прочими, которые Питон использует при рассчете выражений. Результатом каждой из них является такой же объект F, который хранит у себя свои операнды. Соответственно, эти вызовы можно комбинировать (хотя практического юзкейса я еще не придумал):

op = F('field') + 1   →  op = F('field').__add__(1)
op2 = op * 3          →  op2 = op.__mul__(3)

А вот на закуску стоит сказать, что эти вещи работают и при переставленных операндах. То есть:

1 + F('field')

… не свалится, хотя у объекта int и не определено, как к нему __add__ джанговский F-объект. Вот эта магия достигается за счет обратных методов операций: __radd__, __rmul__ и т.д. Они вызываются у правого объекта в операции, если вызов прямого метода на левом объекте выдал ошибку NotImplemented. Соответственно:

1 + F('field')        →  F('field').__radd__(1)

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

Итак, первая версия схемы файлового инструментария Джанго:

К схеме прилагаются отмазка и пояснения. Отмазка простая: сейчас полчетвертого ночи, поэтому я реально мог там что-то напутать. Буду благодарен за исправления!

Пояснения следуют…

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

Storage

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

File

Базовый класс, представляющий все джанговские файлы. По сути — легкая обертка над стандартным питоньим fileом с добавлением пары удобных методов (итератор chunks(), свойства .path, .url). Именно этот объект возвращает метод open() из хранилища.

FileUploadHandler

Обработчик потока байтов, идущих по HTTP при upload’е файлов. Джанго умеет разбирать поток по ходу дела на файлы и передавать их на обработку таким вот хендлерам. По умолчанию в Джанго реализован хендлер, который умеет принимать маленькие файлы в память, а большие — сваливать на диск. Но этот интерфейс тоже предназначен для расширения юзерами. Возможная функциональность: потоковая распаковка архивов, проксирование файлов на удаленную машину без сохранения локально, проверка на вирусы, а также подсчет принятых байтов для реализации ajax’овых progress bar’ов.

Дефолтный FileUploadHandler в зависимости от размера файла рождает одного из двух наследников UploadedFile (см. далее): InMemoryUploadedFile или TemporaryUploadedFile (во временной директории на диске).

UploadedFile

Наследник File. По сути — реимплементация его, умеющая безопасно обрезать заданное пользователем имя и помнящая кодировку загрузки. Вряд ли когда-то кому-то понадобится от него наследоваться или что-то с ним делать напрямую.

FileField

Поле модели, которое представляет собой файл, сохраненный в модели. На самом деле, как и все остальные поля моделей, он виден в объектах моделей не сам по себе, а заменяет себя в классе на атрибут с данным (так, например, CharField заменяет себя в классе модели на простой строковый атрибут). Атрибут этот — дескриптор FileDescriptor, который при запросе его у модели через obj.file_field лезет в хранилище и достает оттуда файл в виде класса FieldFile.

FieldFile (у вас не рябит еще в глазах от “F”, “i”, “e” и “l”?)

Наследник File, знающий, что он представлен в модели как имя файла. По этому имени он умеет доставать и сохранять контент из/в хранилище, на которое хранит у себя ссылку. Именно от этого класса предполагается наследоваться для создания своих интересных файловых полей. Самый очевидный пример такого интересного поля — всевозможные варианты ThumbnailImageField (привет, Саша!). Кстати, если будете делать что-то в таком духе, пожалуйста, сохраняйте данные не напрямую в файловую систему, а пользуйтесь интерфейсом хранилища, чтобы тамбнейлы сохранялись туда же, где и сами картинки.

Вот, как-то так. HTH!

Если вы какое-то время работаете с Django и используете inclusion-теги, то наверняка сталкивались с неудобством, что кроме переменных контекста, возвращаемого из тега, в шаблон не попадает ничего. В частности, там нет всяких полезных {{ user }}, {{ MEDIA_URL }} и прочих “глобальных” вещей из родительских контекстов.

Я одно время был даже пропонентом такого подхода, потому что он “чище”: в контекст не сливается куча глобальных переменных, которые теоретически засоряют namespace внутреннего независимого шаблона. Но практика показывает, что все наоборот. Случаев, когда вам нужны глобальные данные в контексте, полно, а вот чтобы они мешались, я как-то не припоминаю совсем. Да и кроме того, поскольку шаблонный язык очень ограничен, прострелить себе ногу с помощью глобальных данных там довольно сложно. Средств мало :-).

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

Проще всего сделать, конечно так:

@register.inclusion_tag('template.html', takes_context=True)
def my_tag(context):
    return {
         'user': context['user'],
         'MEDIA_URL': context['MEDIA_URL'],
    }

Но это скучно и нуждается все время в поддержке по дописыванию нужных переменных. Чтобы это автоматизировать, можно было бы воспользоваться методом типа items(), выдающему все содержимое, но такого метода у контекста нет. Потому что контекст — это на самом деле не dict, а стек из dictов. Поэтому нужно было бы бежать по всем стеку циклом, и у каждого dictа брать items(). Но это уже слишком многословно.

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

Жаль только, что декоратор inclusion_tag написан так, что сделать этого не позволяет. Поэтому я пишу тег руками:

class MyTagNode(template.Node):
    def render(self, context):
        context.update({
            # собственные переменные
        })
        result = template.loader.get_template('template.html').render(context)
        context.pop()
        return result

@register.tag
def my_tag(parser, token):
    return MyTagNode()

Метод context.update берет переданный dict и “пушит” его наверх стека. Соответственно context.pop его потом оттуда удаляет. Вуаля!

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

Первой идет штука под странным названием “Vooid”.

Vooid (Very Own OpenID server) — это OpenID-сервер для персонального сайта, написанного на Джанго. Обслуживает единственного пользователя — администратора, позволяя ему использовать любой URL своего сайта для авторизации по OpenID.

Штука получилась очень простой в установке — пара сеттингов да подключение в urlconf. По желанию — включение шаблонного тега с <link>ами в базовый шаблон. Также можно выбрать любой URL своего сайта в качестве OpenID и настроить SREG.

Так что, для тех, кто не хочет светить OpenID-провайдеру свою историю входов, по-моему, довольно удобная штука.

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

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

Разговаривая с людьми о Джанго, я обнаружил, что многие ждут релиз 1.0 как некое одиозное событие, которое… что? Оно, очевидно, что-то такое знаменует и означает. Но вот что именно в релизе 1.0 такого отличительного, что его все ждут.

Стабильность

Слышу, что ждут стабильности. Но это слово означает две разные вещи. По поводу одной — стабильности работы — в джанговском FAQ’е есть запись о том, что Джанго и так стабилен, и был стабильным еще до того, как даже исходники открылись. На нем работают реальные сайты и не падают. И это все правда.

Поэтому речь, конечно, не об этой стабильности. Речь о стабильности API, который в версии 1.0 перестанет изменяться.

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

Развитие

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

Позвольте снова спросить, чем в этом смысле отличается релиз 1.0 от произвольно зафиксированной ревизии? Что, Джанго после 1.0 перестанет развиваться? Да нет, корные разработчики уже заявляли, что довольно быстро после 1.0 появятся 1.1, 1.2. Думаю и 2.0 будет довольно быстро… Может быть эти самые 1.1 и 1.2 будут сохранять обратную совместимость с 1.0? Да, наверняка. Но штука в том, что поддержка обратной совместимости — священная корова в разработке Джанго, и она ломается крайне редко и крайне неохотно. И только по делу. Номера версий тут не причина, а следствие. Фактически, версией 2.0 Джанго скорее всего станет первая же, в которой придется избавиться от какого-нибудь старого API, проявившего себя не слишком удачно.

Сторонние компоненты

Третий аспект “особенности” версии 1.0 — предполагается, что ее API будут использовать в качестве ориентира разработчики сторонних компонентов. И это снова правда. Но я, убейте меня, не верю, что разработчики сторонних компонентов не будут использовать и новые API. А значит их уже нельзя будет использовать с 1.0 напрямую. Да еще и эти компоненты не будут обязаны соблюдать полную обратную совместимость с 1.0, тут уж все зависит от специфики кода и желания разработчика. Если разработчик вменяемый, то он, опять таки, тоже старается сохранять обратную совместимость независимо от того, в какой версии фреймворка его стукнуло желание написать что-нибудь полезное.

Транк

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

Думаю, мы продолжим делать это и после 1.0.

И вот это в Джанго, на мой взгляд, самое главное. Имея такой транк, который живет и практически не ломается, лично мне никаких релизов не надо :-)

И тем не менее…

Тем не менее, версия 1.0 — это хорошо. Я могу сходу придумать две причины, почему это так:

• Это большой символ, и очень хороший стимул: я давно не помню такого шквала активности в разработке Джанго, который начался с тех пор, как был объявлен план на 1.0. Были наконец-то доделаны и влиты в транк важнейшие рефакторинги, ждавшие своей очереди: новая админка, обработка аплоудов, подключаемые файловые хранилища и т.д. Фреймворк стал гораздо лучше за последние пару месяцев.

• Это знаковое событие с маркетинговой точки зрения. Вокруг Джанго есть много людей, которые не интересуются процессом подробно, и которые привыкли к тому, что версия 1.0 — это “готово, можно пользоваться”. Теперь они, наконец-то, заткнутся о том, что Джанго “все еще бета” :-).

Поздравляем нас всех!

Куда все идут

Я приглашаю:

07.09.2008 15:00, Б2, Большая Садовая, д. 8 (м. Маяковская выход в сторону Театра Сатиры), метро Маяковская

Празднование релиза Django 1.0

Есть идея отпраздновать вместе с остальным миром долгожданный релиз Django 1.0!

Приглашаются все, кому это интересно. Познакомимся (кто не знаком), пообщаемся, расскажем друг о друге, сделаем фотки и пожелаем доброго пути любимому фреймворку. Программировать не будем :-)

В качестве места сбора предлагается клуб “PodМосковье”. Говорят, вполне демократичное место, и народу много можно вместить. Если у кого-то есть другие предложения — пишите.

И отдельная просьба — обязательно отмечайтесь по кнопке “Присоединиться”, все, кто собирается пойти, чтобы знать, на сколько человек просить уважаемый клуб место зарезервировать.

P.S. Мероприятие совершенно не связано с Яндексом, это просто встреча по интересам.

Geek’s note: этот пост, созданный средствами нашего мегасайта “Куда Все Идут” содержит микроформат hEvent, и если у вас браузер умеет его распознавать, его можно добавить в ваш любимый веб-календарь.

Месяц прошел в неспешном рефакторинге (наконец перевел формы на ModelForm, которых не сущетсвовало, когда начинал их писать), добавлении мелких удобств (автоподсветка URL’ов, чтение SRE из OpenID) и правке мелких багов (например, пропускались топики из одних пробелов). В общем, ничего существенного не изменилось.

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

Регистрация и спам

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

А регистрации начинаются уже потом. Вот типичный случай.

На прошлом движке (PunBB) спам приходил сотнями в день. На Cicero спама нет. Совсем. Причем, не только в самом форуме, но и в карантинной очереди. Я четко помню там ровно четыре поста за месяц: одно тестовое, а три других — false positives, про которые Акисмет поосторожничал и посчитал спамом, хотя они таковым не являлись. Их я, конечно, пропихнул в форум, научив собачку, что на них лаять больше не надо.

По большей части отсутствие спама я связываю с нестандартной формой постинга. Саша Кошелев, правда, предрек мне, что “со временем научатся”, но я думаю, что это маловероятно: кому нужно специально затачивать роботов под форум, существующий пока в единственном экземпляре, на котором общаются гики?

Фичи Cicero

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

А еще я, кажется, стал узнавать “в лицо” некоторых мутантов :-).

Из собиравшихся 30 человек пришли, если не ошибаюсь, 18. Учитывая всякие тенические накладки, начали спринт мы где-то через час после назначенного времени. WiFi был, электричество тоже :-).

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

Еще одна штука, которая явилась для меня откровением, что 5 часов на такое событие мало; у нас в офисе в тот день полы менялись, поэтому около шести вечера нас выгнали. Мало, потому что первые часса три ушли у всех на то, чтобы “войти в поток” и начать эффетктивно работать. Под конец, я заметил, работа пошла веселей. Да еще и на IRC-канале появился один из джанговский triager’ов и прямо в онлайне несколько наших тикетов подвинул в “Ready for checkin”, а также дал несколько советов.

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

• Виктор бессстрашно взялся за древний ticket 13, и добился там неплохого прогресса (Викто, патчик доделаешь?) Тикет этот во время спринта успел обрасти собственным издевательским фольклором: “не знаешь что делать — а вон, возьми тринадцатый” :-)

• Трое джангистов — Тарас Халтурин, Николай Лещев и Олег Плессер сваяли целый БД-бэкенд для Оракла с поддержкой пула коннектов. Базовое “тупое” приложение с ним ускорилось в три раза.

Ну а в завершение мероприятия мы накормили программистов пиццей. Кажется, все были довольны :-). Я считаю, будем собираться еще!

Да, вот забыл: кто уже написал в прошлом посте, что придет, пришлите пожалуйста еще разок свои имя и фамилию мне на isagalaev@yandex-team.ru. Надо надо заявку в охрану сделать.

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