4 января вышел релиз кандидат fullstack-фрейморка для разработки веб-приложения Django. Обзоры, наверено, не писали/читали только ленивые. Но пишут, в основном, про мажорные фичи, из-за которых и выпускают релиз. Я перевел свой небольшой прототипчик одного приложения на Django 1.5 RC и поюзал некоторые минорные нововведения, о которых пишут мало, но которые почти делают каждый релиз тем, из-за чего часто хочется использовать именно его. Из того, что мне понравилось - это:

  • изменения в template engine: теперь True, False, None воспринимаются так же, как и в python;
  • дополнительные батарейки для работы с временными зонами - мелочь, а очень приятно;
  • исправленна ошибка OutOfMemory при использовании команды dumpdata - особенно полезно на небольших хостингах;
  • mod_wsgi auth handler - для тех, кто все еще использует Apache и Basic авторизацию;
  • в debug конфигурации приложения логи дополнительно выводятся в консоль;
  • user_login_failed событие - понятно что это такое, +1 к секьюрити: легче блокировать ботов от перебора паролей и плюс к защите от DDoS;
  • loaddata имеет опцию для игнорирования колонок, которых больше нет в модели - просто в восторге от этой фичи, имхо, она для меня теперь станет неаменимой при разработке, кода модель активно меняется, а django south использовать еще рано (в момент разработки, а не при выходе в production).
Из всего вышесказанного, кроме mod_wsgi auth handler попробовал все и хоче сказать: дявол кроется в деталях, они делают любой продукт именно таким, чтоб им (не) хотелось пользоваться.

Ну и не могу сказать про одно мажорное изменения - эксперементальная поддержка Python 3.2+! Осталось подождать и/или портировать нужные зависимости для проектов и можно начинать использовать. На свой страх и риск, конечно, т.к. production код должен быть как можно стабильнее, а не в статусе "эксперементальная фича". Хотя, time to market никто не отменял...

Подробности на оффициальном сайте Django:


Все сказанное ниже является личным мнением автора и не является объективной точкой зрения и/или истиной последней инстанции.

Я всегда считал и продолжаю это делать, что Django - не очень-то и модульный фреймворк. Он расширяемый, но не модульный, IMHO. В моем понимании модульный фреймворк, это фреймворк, который состоит из ядра (core), и каких-то модулей, которые можно к нему подключать при желании/необходимости. Но и без них будет доступна минимальная функциональность. В случае же Django - выкинуть из него некоторые модули (e.g. models, template engine) достаточно сложно. Что-бы сделать что-то подобное, необходимо самостоятельно удалять ненужные куски кода, что тянет за собой проверку работоспособности оставшихся частей и прочие неприятности в виде сложной поддержки полученного кода и обновление фреймворка.

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

Т.к. этот вопрос интересует меня давно, я его задавал одному из Django Core Developers, Andrew Goodwin’уб на прошедшем в октябре UA Pycon. Далее в вольном пересказе пишу его слова так, как я их понял:

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

И есть еще одна проблема: community хочет не только модульность самого Django, но и возможность использование его компонентов, например models, вне Django. В данной это невозможно, но мы хотим когда-нибудь это сделать”

Несколько ссылок по теме из википедии:



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

  • подключения специальной версии CSS;
  • подключения нужных JavaScript’ов;
  • создание мобильных шаблонов (templates) с версткой (html).

Сразу оговорюсь, что вопрос мобильной верстки сейчас затрагивать не буду.

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

{% if request.mobile %}
    Mobile
{% else %}
    Not mobile
{% endif %}

 

Или же наша view поменяет вид на такой:

def index(request):
    if not request.mobile:
        return render_to_response('index.html’)
    else:
        return render_to_response('mobile_index.html’)

Теперь дело за малым - сделать так, чтоб в объекте нашего запроса (request’а) появилось свойство mobile. Один из самых простых и достаточно эффективных способов - посмотреть какой USER_AGENT у браузера, который делает запрос. Для этих целей уже есть небольшой, но удобный компонент minidecector, который анализирует USER_AGENT из запроса и выставляет нужное значение свойства request.mobile.

minidetector можно подключать двумя способами:

  • добавление декоратора detect_mobile к нужной view;
  • добавление уже готового Middleware; в этом случае будут обрабатываться все запросы к нашему приложению.

Небольшой пример использования minidetector лежит на GitHub’e: https://github.com/e0ne/BlogSamples/tree/master/MobileTest

 

Другие ссылки по теме:

Напомню, что протестировать это на встроеном в Django веб-сервере не получится, т.к. он работает только локально и вы не зайдете на него со своего мобильного устройста. Настройка Django+Apache+mod_wsgi описана тут: https://code.djangoproject.com/wiki/django_apache_and_mod_wsgi


Django и jQuery Template

Published 9/21/2011 by e0ne in Python | Web Development
Tags: ,

 

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

Вначале просто  data binding работал отлично и никаких проблем не предиделось. Но стоило только появиться необходимости использовать тег {{if}} из jQuery Template, встретились первые неожиданности.

Неожиданность номер раз:

Не совсем, конечно, неожиданность, а, скорее, первая меленькая проблемка. Конструкция “{{“ - совпадает с синтаксисом шаблонов в Django, от чего мы получаем ошибку что у нас неправильный темплейт. Пришлось открыть доки django и найти там что такое template tag и как им пользоваться.

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

{% templatetag openvariable %} if highlight {% templatetag closevariable %}
  <div style="background-color: ${color}">
{% templatetag openvariable %} else {% templatetag closevariable %}
  <div>
{% templatetag openvariable %} /if {% templatetag closevariable %}
  ${name}
</div>

Читабельность всего этого упала в разы, но стало работать. Не совсем правильно, но работать...

Неожиданность номер два:

Вместо ожидаемого результата на странице я получал нечто похожее на:

{{ if highlight }}
  <div style="background-color: red">
{{ else }}

Первая мысль - в разметке страницы заэкранированы символы “{{“ и “}}”. Но, как часто это бывает - первая идея оказалась неправильной. Снова открыл доки Django и jQuery Template. Далеко не сразу заметил что в примерах jQuery Template нет пробела между “{{“ и “if”... Неожиданно, но удаление примеров помогло и все сразу заработало. 

Вывод один - читать документацию (любую!) по диагонали нельзя!

Пример, уже традиционно, лежит на GitHub: https://github.com/e0ne/BlogSamples/tree/master/DjangoAndJqueryTemplate

 


Выбор веб-фреймворка не в .NET стеке для нового проекта достаточно нетривиальная задача. Их много - больших, маленьких, хороших и не очень, горячих и зелёных. Так как при работе с Python больше сталкивался с Django, то для себя, т.е. очень IMHO, сделал несколько правил.

Использовать Django нужно когда: 

  • нужно получить опыт с Django;
  • нужно сделать быстро сайт с админской частью (блог, CMS и т.д.);
  • есть хорошее готовое приложение/модуль для Django и его нужно сомсем немного доточить напильником;
  • нет необходимости заморачиватья с DAL (data access layer) и стандартного ORM вполне достаточно;
  • какие-то из модулей Django уж ооочень хорошо подходят для текущей задачи;
  • нужно сделать что-то очень быстро и нет опыта с другими фреймворками.
Итого получилось 6 пунктов. Если не выполняются хотя бы 3, то нужно задуматься о целесобразности использования Django. IMHO.

Как сказал один из авторов Django в своей книге: "Django - это всего-лишь приложение на Python".

 


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

Работа с потоками всегда была не самым лёгким занятием для программистов. А если брать особенность работы с потоками в Python ветки 2.x и 3.x (не считая версий 3.2 и 2.7), то кроме потоков нам на голову падали ещё проблемы в GIL (Global Interpreter Lock). Но прогресс не стоит на месте и многопоточность используется уже практически везде. Проблема с cuncerrency встречается всё чаще и решать её приходится так же часто. 

При необходимости реализации такой задачи мне под руку попалась библиотеке eventlet (http://eventlet.net/), которая уже использовалась у нас на проекте и мне очень понравилась. Основная задача этой библиотеки - дать возможность реализации высокомашстабируемых не блокирующих I/O задач (highly scalable nonblocking I/O).

Описывать подробно все достоинства и недостатки данной библиотеки не буду, т.к. таких пока было обнаружено не слишком уж много. Больше всего, что мне не понравилось - это, на мой взгляд, не очень хорошая документация (http://eventlet.net/doc/), но открытые исходники с подробными комментариями и кучей примеров эту проблему решили.

В рамках моей задачи, мне понадобилось сделать какое-то подобие COMET-сервера с помощью long polling - один из способов сделать push-уведомления (http://en.wikipedia.org/wiki/Push_technology) для веб-приложений. Основная особенность - клиент делает один за другим (ajax)запросы на сервер, а сервер, в свою очередь отвечает клиенту только тогда, когда у него появились необходимые данные.

Простой пример такого приложения на Django доступен на гитхабе: https://github.com/e0ne/BlogSamples/tree/master/djangolp


Проблема с использованием разных версий софта практически настолько же стара как мир разработки этого самого софта. Смотря со стороны разработчика, то самый простой случай - это когда нужно пофиксить какие-либо баги в предыдущей версии. Проблема заключается в том, что для dev environment уже используется более новая версия python, django и/или другого, необходимого для проекта, ПО. В более “тяжелом” случае все становится еще интересней: в production одно, на stage -  другое, на машине разработчика - третье, а тут еще нужно писать под google app engine, для которого требуются специфические (старые) версия python/django. 

Первой моей идеей было поднять разные виртуалки для тестирования, но немного погуглив наткнулся на такую замечательную вещь, как virtualenv. Как написано на оффициальном сайте - “virtualenv is a tool to create isolated Python environments”, что в переводе звучит, примерно, так: “virtualenv - приложение для созданий изолированных рабочих сред для python”. Таким образом вы можете создать несколько окружений с разными версиями python и/или других библиотек. 

Установка virtualenv ничем не отличается от установки любой библиотеки, написанной на python. В моем случае установка выглядила так:

sudo easy_install virtualenv

После установки virtualenv процесс создание виртуального окружения состоит всего лишь из одной команды:

virtualenv -p /usr/bin/python2.5 ./gae/

Здесь с помощью параметра -p я указал версию python, которую необходимо использовать для виртуального окружения. Последним параметром идет путь к  директории, в которой необходимо все создать. Так же рекомендуется добавлять параметр --no-site-packages, для того, чтобы из виртуального окружения не было доступа к пакетам из “реальной” среды (из встроенной справки: Don't give access to the global site-packages dir to the virtual environment). У себя этот параметр я не использовал по следующей причине: на рабочем PC mbp я использую такую схему библиотек:

  • последняя версия python и необходимых библиотек устанавливается обычным образм, без virtualevn;
  • если для каких-то причин необходимы другие версии интерпретатора или библиотек - создаю virtualenv;
  • в virtualenv доустанавливаю только те библиотеки, версии которых должны отличаться от реальной среды моей ОС (в моем случае - необходимо использовать более старую версию).

Теперь, после создания virtualenv появилась такая структура папок:

bin include lib

В Windows-like OS структура папок может немного отличаться.

$ python --version

Python 2.6.5

$  ./bin/python --version

Python 2.5.4

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

UnacceptableVersionError: django 1.0 was requested, but 1.2.1.final.0 is already in use.

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

Для переключения в виртуальное окружение проще всего использовать скрипт activate, который лежит в каталоге bin нашего  vitrualevn:

e0ne-macbook:gae e0ne$ source bin/activate

(gae)e0ne-macbook:gae e0ne$ python --version

Python 2.5.4

Для выхода из виртуального окружения существует команда deactivate:

(gae)e0ne-macbook:gae e0ne$ deactivate 

e0ne-macbook:gae e0ne$ 

Перейдем непосредственно к установке djngo в созданное виртуальное окружение. Установка любого python-пакета в virtualenv ничем не отличается от обычного процесса установки и выполняется всем знакомой командой:

(gae)e0ne-macbook:Django-1.0.4 e0ne$ python setup.py install

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

Я описал лишь базовые возможности пакета virtualenv, но и этого вполне достаточно для того, чтобы увидеть всю его мощь, спрятанную я простым и понятным интерфейсом. Как всегда, все подробности на оффициальной странице: http://pypi.python.org/pypi/virtualenv