Что год уходящий с собой уносит...

Планировал в уходящем году разобраться с Джанго, и, думаю, что это мне удалось более или менее. Благо вещь намного проще чем, например, Ur. Правда, основная проблема, что проектов пока на нём почти и нет совсем. Есть, конечно avastep, но вещь довольно простая, пусть даже и посещаемость есть какая-никакая. Но Джанге там негде особо и проявить-то себя, хотя, видимо, будет допиливаться, в смысле расширения.
Хочется в следущем году попробовать FeinCMS взять на вооружение ибо modx уж больно грустная вещь для чего-нибудь чуть в сторону отходящего от стандартного функционала

Толи лыжи не едут...

urls.py и именованные ссылки это вроде бы хорошо, но вот никак немогу понять: разве нельзя в этих самых ссылках GET параметры как-то "прикрутить"?
Писать в шаблоне {% url my_link %}?param={{ template_param }} и "вручную" разбирать потом на стороне view-хи как-то кажется несколько заморочным.
А параметры в урлах временные, поэтому логичней иметь их явными параметрами, ну и AdSense не срабатывает там где нужно (наверное каждый раз пересобирает статистику для таргетинга?).

Яблоки vs. Апельсины

Довольно интересное сравнение Drupal и Django.

Красиво :)

Обновил django-debug-toolbar до версии 0.8 - вот это я понимаю красивый интерфейс :)

DjandoCon 2009

Для тех, кто ещё не в курсе, пару недель прошла конференция DjangoCon 2009. Видео вроде ещё не выкладывали, слайды уже есть.
Кстати, TWiD возродился недавно в виде Django Dose. Пока контента не сильно много, но ждём, что появится позже.
P.S. В связи со сменой работы перспективы вменяемой работы на Django заметно поуменьшились, к сожалению.

Go shopping!!!

Поковырялся тут с пхпшным oscommerce, много плевался. Проект находится в "подвешенном" состоянии и, вместе с тем, много народу делает разные "доделки", местами противоречащие друг другу. В общем до модульности Django Apps далековато.
Ну, думаю, а гляну-ка Satchmo, вебшоп на Django. Но первые впечатления не очень обрадовали:

1. Документация на сайте опирается на версию из HEAD репозитария, так что возникает вопрос со стабильностью.
   
2. Установка тянет за собой кучу зависимостей, причём в рекомендациях easy_install и прямое создание ссылок в site-packages, а также выгрузка некоторых вещей также по HEAD из репозитариев (пусть и от участников проекта, насколько я понял)
3. Урлы подключаются путём добавления магической строчки "from satchmo_store.urls import urlpatterns", т.е. ни о какой конфигурируемости речи не идёт.
4. Многоязычность делается через какие-то "терни к звёздам", в файлах лежит папочка "ru" с переводом, но среди языков по "магическому" адресу /settings нет русского языка, а вот переключение на русский язык, несмотря на это работает. В переводах продуктов же список всех языков, доступных джанге.

В общем как-то всё грустно...

А кончил за упокой...

Для первого нашего Django-проекта я решил использовать South, чтобы меньше заморачиваться с модификациями БД (например, выполнять их автоматически при деплойменте). Всё здорово, но вот в версии 0.5 была подлая "засада" - South не совсем корректно понимал вариант, когда default для полей задавался через callable. Приходилось ручками править определение поля, создавать миграцию, а потом исправлять поле на первоначальный вариант. Однако вышла версия 0.6 и там это было исправлено. "Здорово" подумал я, но не тут-то было :)
Проблема возникла в обновлении версии пакета, который был поставлен в virtualenv через pip. В документации к pip данный вопрос вообще никак не освещается. Путём гугления обнаружилась опция --upgrade, только вот указывать для файла с зависимостями оказалось неверным вариантом, потому как через зависимости тянулся почему-то злосчастный PIL, некорректно устанавливающийся.
Пришлось делать апгрейд пакета отдельно ручками как

pip -E . install --upgrade South

Но в site-packages остаются "концы" от старой версии 0.5, поэтому их пришлось ручками стереть.
Python, конечно, неплохой язык, но вот всё чаще вспоминаются слова dmz про package hell, и это далеко не радует.

Действительно хорошая книга

Начал читать ProDjango и такое ощущение, что из первых 2 глав её я узнал про python больше чем из всей Dive Into Python. Однозначно оценка 5 книжке!

Толь лыжи не едут...

Понадобилось тут разобраться с интернационализацией в Django, в принципе, вроде всё понятно, но в одном месте вышел "затык". Создаю с помощи комманды файл django.po, компилирую в бинарный формат, запускаю сервер, а там ни намёка на перевод. Наверное не меньше получаса медитировал над документацией и гуглом. Оказалось, что создал я папку conf/locale, где ищется локализация самой джанги, а для других проектов нужна просто locale. Надо просто внимательней читать то, что пишут инструменты (в сообщении conf/locale была просто первой). Хотя такая неоднородность несколько контрастирует c остальными аспектами довольно последовательного Django.

Хочу другой линукс!

Повоевав с mod_wsgi, вроде приблизился к нормальной разработке, но не тут-то было: не захотел Django имена файлов с русскими буквами воспринимать. Оказалось, что Apache запускался с LANG=C, как это исправить даже в джанговских доках написано, но вот CentOS и тут отличился: настраивается не в /etc/apache2/envvars, а в /etc/sysconfig/httpd и даже называется не LANG, а HTTPD_LANG. Ну и после последних новостей есть уже огромный повод задуматься. Но это потом, ведь завтра отпуск начинается :)

R.I.P. mod_python

Проблемы в CentOS разрешились тривиальным удалением mod_python (с его помощью публиковался trac). Одновременно включить его и mod_wsgi не удалось, да и не нужно в принципе, trac ведь может и через wsgi работать.
В общем не надо 2 разными способами решать одну и ту же задачу одновременно - скорей всего только заморочки лишние нарисуются.

Deployment не задался.

После войн сервером под CentOS пришёл к тому, что mod_wsgi поставить не удаётся, поэтому пока ограничусь mod_python. После отпуска надо будет задуматься о каком-то альтернативном хостинге.

О сколько нам пакетов чудных...

Пытаюсь сейчас разобрать деплоймент Django-приложений. Остановился на fabric, virtualenv и pip. Всё вроде бы интересно, но вот возникли некоторые неувязки - PIL не устанавливается через

#pip install PIL

можно, конечно использовать

#pip install http://effbot.org/downloads/Imaging-1.1.6.tar.gz

но как-то "не спортивно", поэтому захотелось использовать site-packages куда будут установлены некоторые "дефолтные" пакеты (в т.ч. PIL). Только вот окружения, созданные через virtualenv, не хотели видеть глобальные пакеты. Пришлось посерьёзней разобраться с разбором импортов в python.
Причина оказалась в том, что товарищи из Ubuntu "пошаманили" с python 2.6 и site-packages зовутся dist-packages, буквально-таки:

  if use_default_sitedirname:
      return pylib.replace('/dist-packages', '/site-packages')
  else:
      return pylib

поэтому ставить надо было не через sudo pip install/easy_install virtualenv, а с помощью sudo apt-get install python-virtualenv.
Теперь я понимаю, о чём Джеймс Беннет писал в своём посте про проблемы с пакетами.
Продолжу разбираться дальше и, наверное, напишу пост о варианте развёртывания, который у меня получится.

Дебажим джангу

Вроде начал толком писать приложение на Django и, естественно, понадобилось как-то отлаживать приложения. Довольно приятно был удивлён наличием удобных вещей по сравнению с PHP (или может я просто так плохо умею с ним обращаться?):

1. bdp/ipdb позволяет ставить брейкпойнты в коде и делать пошаговую отладку, конечно, не Eclipse/Visual Studio, но вполне годно к использованию;
2. django-debug-toolbar, о ней я уже писал, с тех пор там появилась ещё рубрика "сигналы";
3. django-extensions в связке с werkzeug, про использование extensions для рисования диаграмм моделей я уже упоминал, но вот расширение страницы ошибки до того, что там становится доступна коммандная строка, меня сильно впечатлило.

Сухими словам или картинками объяснять получится не очень демоснтративно, поэтому рекомендую посмотреть неплохие касты от Eric Holscher тут и тут.
Оттуда же я узнал, что даже стандартная страница об ошибке Django информативнее, чем мне казалось (к примеру можно посмотреть участки кода и отправить стэктрейс на dpaste.com).
И ещё складывается такое впечатление, что на Django как-то больше думаешь о строении приложения с архитектурной точки зрения, т.е. как отдельные части взаимосвязаны и, возможно ли какое-нибудь переиспользование кода, а не с точки зрения "вот тут параметр А, надо отобразить табличку в Н строк". Хотя задачка не очень показательная, т.к. не из типовых для джанго, по-моему.

Чтож ещё почитать?

Дочитал Dive Into Python, как-то не очень меня впечатлила книга. Наверное, язык прост до того, что "разжёвывание" приёмов кажется черезмерным, да ещё и используемый там способ подачи материала в виде кода со сносками как-то мне совсем не по душе...
Следующей "питонистой" книгой, думаю должна стать Practical Django Projects, о которой я писал в предыдущем посте.
Или, может быть, есть что-нибудь другое стоящее внимания?

Хороших книг должно быть много!

Джеймс Беннет выпустил второе издание своей книги "Practical Django Projects" (книга была дополнена и приведена к версии Django 1.1). Думаю, если не уйду из веба и таки начну толком переход наших проектов на Django, то надо будет купить электрическую версию.

Делаем правильный суп

По совету bw решил попробовать html5lib для решения заморочки с Beautifulsoup и получилось избавиться от некрасивого воркараунда (правда, ворнинг словился):

>>> import urllib
>>> html = urllib.urlopen('http://django-newbie.blogspot.com/').read()
>>> import html5lib
>>> from html5lib import treebuilders
>>> parser = html5lib.HTMLParser(tree=treebuilders.getTreeBuilder("beautifulsoup"))
>>> soup = parser.parse(html)
/usr/local/lib/python2.6/dist-packages/html5lib-0.11.1-py2.6.egg/html5lib/inputs
tream.py:367: DeprecationWarning: object.__init__() takes no parameters
>>> soup.findAll('link', {'type':'application/rss+xml'})[0]['href']
u'http://django-newbie.blogspot.com/feeds/posts/default?alt=rss'

Ну зачем так?

Самое загадочное в Python, на мой взгляд - ';'.join(words)
Неужто есть рациональное объяснение этому?

Суп с приключениями

Понадобилось тут вырезать адрес RSS-ленты со страничек. Ну, думаю, возьму BeautifulSoup и делов-то. Для ЖЖ всё прошло без проблем:

>>> import urllib
>>> html = urllib.urlopen('http://kurilka.livejournal.com/').read()
>>> from BeautifulSoup import BeautifulSoup
>>> soup = BeautifulSoup(html)
>>> soup.findAll('link', {'type':'application/rss+xml'})[0]['href']
u'http://kurilka.livejournal.com/data/rss'

Ну, думаю, гораздо более демонстративно будет, если я вытяну RSS прямо для этого же блога, куда пишу сейчас этот пост. Но не тут-то было...
Упало оно с криком HTMLParser.HTMLParseError: bad end tag: u"</scr'+'ipt>". Причём, оказывается, что это программеры Google попирают спецификации W3C и не экранируют "</" в тексте скрипта. Поэтому пришлось пока сделать временную "затычку":

>>> import urllib
>>> html = urllib.urlopen('http://django-newbie.blogspot.com/').read()
>>> html = html.replace("</src'", '')
>>> from BeautifulSoup import BeautifulSoup
>>> soup = BeautifulSoup(html)
>>> soup.findAll('link', {'type':'application/rss+xml'})[0]['href']
u'http://django-newbie.blogspot.com/feeds/posts/default?alt=rss'

Вот так и воюем: то с нестрогими спецификациями, то с нестрогим их соблюдением...
P.S. И ещё больше добила борьба с blogger.com, жестоко коверкающим тэги

Продолжая тему открытости

Simon Willison выложил в публичный доступ репозиторий с исходным кодом djangopeople.net, думаю полезно в качестве хорошего примера по Django

Касты из Ченнаи

В рамках пассивного обучения Django посмотрел тут касты одного индуса под названи Learn Django: Create a Wiki in 20 minutes. В целом довольно познавательные ролики, только вот как-то оно неаккуратно. В первых 2 частях код правится в VIM, а в третьей - в WingIDE. И оформление кода несколько стремновато. Ещё это усугубляет, что сделано оно на версии 0.96, а в версия 1.0 привнесла среди прочего пару актуальных изменений:

• Текст выводимый в шаблонах "автоискейпится" и можно безопасно выводить любые переменные в результирующий html, т.е. не надо каждый раз добавлять фильтр escape для переменных, а наоборот лишь в случае необходимости добавлять фильтр safe (или тэг autoescape);
• В urlconf'ах появились имена паттернов, и тэг url может принимать эти самые имена, но судя по документации тэг этот был и ранее, так что "прибивание гвоздями" адресов нельзя оправдать (показательно, как он сам потом ручками во всех шаблонах меняет адреса на новый формат).

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

Рисуем диаграмки наших моделей

Наткнулся тут на ещё одну полезную вещь - Django Command Extensions, подборку разных полезных вспомогательных штуковин - запуск скрипта в контексте Django, управление job'ами, экспорт адресов электронной почты и др.
Но самой прикольной мне показалась комманда graph_models - которая строит граф зависимостей между моделями в приложении (по сути ER-диаграмму) при помощи GraphViz.
К примеру вот диаграммка для приложения из кастов Эрика Флоренцано, о которых я писал :




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

Страшный секрет

Дело в том, что в Django есть магия, которую нельзя удалить! Собственно я вот об этом:



И вообще это необычайный фреймворк (для тех кто не в курсе), а Cal Henderson вообще его ненавидит и рассказывает об этом серьёзным и зловещим голосом.

А теперь, когда вы это узнали, вас придётся убрать.

Патчим Django

Для задачи, которую на досуге пописываю, понадобилось мне изобразить wizard, причём на последней странице нужна капча против ботов.
Для капчи я решил использовать supercaptcha. В принципе это не единственное решение, скажем, я писал уже о Django Simple Captcha, но суперкапча мне как-то больше приглянулась.
Что касается wizard'а, то в django.contrib есть класс FormWizard, предназначенный как раз для этого.
И вроде всё хорошо, но обнаружился ньюанс - на самом последнем шаге FormWizard валидирует заново все данные, которые ввёл пользователь. Для обычных полей проблем никаких не возникает (разве что чуть больше времени тратится), а с капчей такой фокус не пройдёт, т.к. валидация у неё "одноразовая". Править капчу, на мой взгляд, в данном случае неправильно, поэтому пришлось внести изменения в FormWizard, о которых я написал ticket 10810 в Trac Django. По сути дела там реализован "хак", т.к. просто последняя форма не ревалидируется заново. Как решить задачу чтобы "и волки сыты, и овцы целы" я так пока и не придумал. Но текущее решение вполне работоспособное, поэтому пока остановлюсь на неём.

Нам скрывать нечего!

Django - фреймворк с открытым кодом. И мало того, что открыт код самого фреймворка, если есть желание, то вполне можно посмотреть исходный код основного сайта Django - djangoproject.com, для этого надо лишь зайти в репозиторий Subversion. Я для себя, к примеру, обнаружил там ссылку на библиотечку Universal Feed Parser, как раз для проекта, который хочется реализовать.

На деревню дедушке

Если продолжать тему ресурсов, посвящённых Django, то обязательно стоит упомянуть списки Google группы:

• на английском это http://groups.google.com/group/django-users;
• а на русском - http://groups.google.com/group/django-russian.

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

Простая магия переиспользования

Наткнулся на очень интересное видео с Джеймсом Беннетом, одним из значимых разработчиков в Django и автором книги Practical Django Projects, несколько устаревшей (по версии фреймворка), но, судя по всему, стоящей (поэтому она стоит у меня в списке к прочтению). В этом видео он рассказывает об очень важной составляющей идеологии фреймворка - идеи reusable apps, т.е. переиспользуемых приложений. В соответствии с ней, сайт представляет собой не оргомную монолитную кучу кода, а совокупность отдельных приложений, небольших, отвечающих за отдельную функциональность, но делающих это хорошо. За счёт этого приложение становится более прозрачным, код - более переиспользуемым, и повышается его поддерживаемость и расширяемость. На примерах показывается каким образом можно строить эти самые reusable apps.
Этому же посвящена 1-я часть слайдов с презентации Real World Django, прошедшей на PyCon 2009 (очень жалко, что не опубликовано видео оттуда).

Простота - сильное преимущество.

Вначале я уже писал, что хотел попробовать веб-разработку на Haskell, и этот пункт всё ещё остаётся в моём TODO-списке.
Однако, читая заметки по воду создания сайта на Happstack (а это, на мой взгляд, один из интересных веб-фреймворков на Haskell) натыкаешься на разные моноиды, монадные трансформеры и т.п. вещи. В итоге у меня получается, что больше думаешь над тем как это всё выражено в типах, чем над самим содержанием приложения. Тогда как на Django прочитав учебник уже можно ваять, немного подглядывая по поводу конкретных тонкостей.
Хотя, возможно, тут сказывается мой небольшой опыт разработки на Haskell и, вероятно, если бы я попрограммировал полгодика, то уже бы все эти монады и иже с ними не оттягивали на себя внимание.
Только вот python до Django я практически не знал, а по Haskell прочитал далеко не один tutorial.
Так что фактор кривой обучения играет довольно сильно в пользу Django.

Инструмент для ловли жуков

Обнаружил тут довольно интересное расширение - Django Debug Toolbar, которое добавляет на сайт вспомогательную панельку с информацией, полезной для отладки приложения. Если точнее там можно увидеть:

• полную версию дистрибутива джанго;
• время выполнения с разбивкой и числом переключений контекста;
• настройки проекта (т.е. по сути ваш settings.py);
• заголовки HTTP;
• параметры запроса, т.е. куки, содержание словаря сессии, параметры GET и POST;
• запросы SQL с их временем выполнения и планами;
• шаблоны, которые использовались для форматирования ответа;
• логи приложения (правда я ещё даже не пробовал их использовать)

Прикольная вещь на мой взгляд.
И всё это есть простое расширение на python, устанавливаемое буквально за 5 минут. Т.е. имеем ещё один аргумент в пользу расширяемости и удобства фреймворка.

Язык определяет мышление

Наверное, многие знают, что, согласно гипотезе Сепира - Уорфа, язык человека определяет его мышление и способ познания реальности. Поэтому, во-первых, программисту не стоит замыкаться на одном языке, и, во-вторых, стоит выбирать такой язык, который как можно лучше позволяет реализовывать проще и удобне решения задач, которые стоят перед разработчиком. К области веб-приложений это тоже вполне применимо.
Так вот "основой" для Django служит очень неплохой язык python: довольно простой и в то же время одновременно выразительно мощный и элегантный. Одной из наиболее ценных черт его, на мой взгляд, является целостность, т.е. все составляющие следуют общим принципам (наверное, тут снова стоит упомянуть The Zen of Python), одним из которых является There's Only One Way To Do It (Есть только один способ сделать это). Следование этому принципу уменьшает число вариантов, которые стоит рассматривать при решение задачи, поэтому разработчик тратит меньше времени и усилий, что не может не радовать. Хотя есть мнение, что ограничение свободы не есть положительная вещь, т.к. рамки сковывают "твоческий порыв". В качестве противоположной идеи сразу вспоминается перловский TIMTOWTDI. Однако, по-моему простота и скорость работы играют чаще всего определяющую роль, а если надо будет решать какие-то более "креативные" задачи, то никто не запрещает использовать другой инструмент.
В python я ещё пока совсем новичёк, поэтому для "подтягивания" своих навыков штудирую книгу Dive Into Python (текст доступен онлайн, есть и русская версия, хотя я предпочитаю читать оригинал) - довольно неплохо написано, правда стиль со сносками к исходникам мне немного не нравится.

Ресурсы о Django

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

• Родной сайт проекта, самый логичный и самый исчерпывающий источник, там есть вики, документация, исходные коды, ссылки на другие источники и др.;
  
• Djangobook - книга, очень хорошее введение, о ней я уже писал;
• This Week In Django (сокращённо TWiD), авторы которого говорят, что это ресурс обо всём по поводу Django, там же они выкладывают еженедельные подкасты, правда последний почему-то датирован 28-м февраля.

Думаю, что есть ещё интересные ресурсы, буду выкладывать новые ссылки по мере того, как буду их находить. Так что - stay tuned!

Простейший способ поставить Django под Windows

Всё делается элементарно:

1. заходим на www.instantdjango.com;
2. скачиваем файлик;
3. распаковываем его;
4. начинаем ваять наш супер-пупе-мегасайт на Django

P.S. Сам, правда, пользуюсь линуксом, но, т.к. большая часть народа сидит под ОС из Редмонда, думаю, эта ссылка будет не бесполезна.

Про Django Book и версии

Для получения обзорных сведений по Django на мой взгляд очень хорошо подходит Django Book от Adrian Holovaty и Jacob Kaplan-Moss, который доступен онлайн.
Правда есть 2 версии книги: первая для версии 0.96 фреймворка и вторая (до конца не завершённая) для 1.0. Я почти дочитал вторую, актуальную версию, но заметил пару проблемок.
Во-первых почему-то уже которую неделю недоступна глава 9.
Во-вторых возник у меня вопрос: как добавлять "кастомные" поля к пользователям (а инфраструктура авторизации и аутентификации уже встроена в Django)? Обнаружил в официальных доках, что делается, как обычно, очень просто, только информация об этом присутствует в версии 1.0 Django Book, а в соответствующей главе 2.0 почему-то нет упоминания об этом.
Однако в целом очень хорошая книжка - читается легко и в итоге получаешь довольно целостную картину устройства фреймворка и того, как писать приложения для него.

Простота - залог успеха

Всё-таки очень подкупает в Django его компонентность и слабосвязанность различных частей. К примеру в том примерчике, что сейчас пытаюсь сделать, понадобилась мне капча. Стандартной нет с фреймворком, но на сайте нашёл ссылку на Django Simple Captcha (кстати, на Google Code довольно много проектов для Django), решил попробовать:

• сделал этому проекту svn co ;
• добавил ссылку к python path;
• добавил CaptchaField в мою модель;
• добавил соответствующий url;
• и всё заработало :)

В общей сложности на решение задачи ушло минут 10-20. С решением её на PHP для варианта, когда нет механизма "из коробки", даже сравнивать не охота :)
В общем - переиспользование рулит не по-детски ибо это сила!

Метод избавления от рутинных задач в Django

Вебразработка очень часто навевает скуку на людей, которые ей занимаются. Ведь, несмотря на всю увлекательность и прелесть интернета, очень много вещей повторяется из раза в раз. Для пользователя это скорей плюс, т.к. не надо каждый раз выяснять, какие ссылки нажимать и т.д. Но вот для программиста это становится очень утомительно, когда приходится писать не первый десяток одинаковых формочек, списков объектов и т.п., которые очень похожи и отличаются лишь небольшими ньюансами. Получается, что разработчик теряет мотивацию, начинает допускать ошибки, ни просто его время расходуется на практически совершенно тупые по своей сути действия. Но прагматичные программисты понимают, что с этим надо бороться и провозглашают одним из основых принципов - DRY, т.е. Don't Repeat Yourself (кстати в вышеуказанной книге этому посвящена глава 2.1 The Evils of Duplication). И авторы Django с этим вполне солидарны.
Скажем, меня всегда утомляло дублирование разных аспектов обработки форм:

• для начала надо иметь html, который будет их отображать;
  
• потом надо обработать информацию, полученную как результат POST-запроса, в частности сделать валидацию;
  
• проверенные данные надо "запихать" в БД;
• если валидация данных не была успешна, то надо отобразить снова ту же форму, сохранив данные, которые были введены пользователем.

Кроме этого можно ещё упомянуть обобщённые виды (generic views), переиспользуемые приложения (как в составе самого фреймворка, так и большое количество сторонних), блоки и тэги для шаблонов и, наверное, это ещё не всё.
Ну и, я уверен, тут не обошлось без влияния The Zen Of Python :)
В целом, если Вы хотите автоматизировать нудные типовые задачи вебразработки и больше времени посвятить сути вашег крутого сайта, то Django может оказать Вам в этом неплохую помощь.

Русские ресурсы о Django

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

Отличные касты

Не зря говорят "лучше 1 раз увидеть чем 100 раз услышать". Поэтому на меня произвели довольно сильное впечатления скринкасты от Эрика Флоренцано, в которых на живом примере показано создание приложения на Django. Лучше, конечно, не просто смотреть касты, но и опробовать всё это своими руками, включив заодно и моторную память.
Жалко, правда, что серия не совсем закончена: в 13-м эпизоде Эрик упоминает, что в 14-м он расскажет об использовании Fabric для развёртывания приложений на Django, но эпизода пока так и нет.

PHP → Django

По поводу миграции с PHP есть довольно интересный пост. Хочу тоже как автор того поста спустя некоторое время сказать I cannot imagine going back to PHP :)

Лиха беда начало

Итак, PHP за последние месяцы успел очень изрядно утомить своими "прелестями". Посмотрев несколько по сторонам, решил взяться за Django - первые впечатления очень даже положительные.
Сначала, правда, хотелось попробовать решения на Erlang или Haskell, но userbase у них заметно меньше, соответственно подводных камней потенциально заметно больше, а хочется именно рабочее опробированное решение, чтоб не приходилось "на каждый чих" писать свою реализацию по сути дела стандартных вещей.
Интересные ссылки, мысли и прочее, что будет появляться по мере вникания во фремворк, буду публиковать здесь. Хотябы просто для истории, а, может быть, это поможет кому-то ещё.