На пути к 1.0 релизу Django претерпевал немало радикальных изменений. Одно из них рефакторинг системы сигналов.

Если вы первый раз читаете и не в курсе «что это такое и с чем его едят», то скажу в двух словах. Это система реагирования на события приложения. Любой JavaScript или прикладной UI программист хорошо знаком с системой событий (event) — клик мышкой, нажатие горячей клавиши и т.п. Для программистов серверной части веба все выглядит немного по другому. Есть HTTP-запрос и есть его обработчик, анализируется как правило URL на предмет «кому отправлять запрос». Но на самом деле это та же система сигналов-событий, только узкопрофилированная под обработку HTTP-запросов.

Оказывается серверная часть веб-приложения тоже может, и я уверен, просто должна генерировать намного больший спектр сигналов, чем просто обработку URL и данных запроса. С чем успешно и справляется Django. Теперь немного прозы. Какие же события может ловить Django «из-коробки».

• pre_init — перед запуском метода-конструктора __init__() модели;
• post_init — после выполнения метода __init__() модели;
• pre_save — перед сохранением экземпляра модели в базу;
• post_save — после успешного сохранения экземпляра модели в базу;
• pre_delete, post_delete — перед и после удаления экземпляра модели из базы;
• post_syncdb — генерируется админкой Django после установки нового приложения (INSTALLED_APPS);
• request_started, request_finished, got_request_exception — генерируются при обработке HTTP-запросов;
• template_rendered — генерируется только в режиме тестирования приложения.

Итак сигналы *_init, _*save, *_delete и post_syncdb генерируются системой моделей Django и их можно импортировать из django.db.models.signals. Сигналы обработки HTTP-запросов из django.core.signals. И тестовый template_rendered из django.test.signals.

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

Код модели:

class MimeType(models.Model):
    """
    Mime Types table
    """
    name = models.CharField(max_length=200)
    slug = models.SlugField()

    def __unicode__(self):
        return self.name

class Item(models.Model):
    """
    Main file
    """
    name = models.CharField(max_length=200)
    slug = models.SlugField()
    file = models.FileField(upload_to='files', blank=True)
    mime = models.ForeignKey(MimeType, blank=True, null=True)
    upload_date = models.DateTimeField(auto_now_add=True)

    def __unicode__(self):
        return self.name

    def set_mime(self, mime):
        obj, created = MimeType.objects.get_or_create(name=mime, slug=slugify(mime))
        self.mime = obj

Посмотрите на метод set_mime модели Item. Он создает новый объект MimeType или использует если он уже создан. При этом не сохраняя модель Item. Теперь я пишу функцию-callback, которая будет вызываться по событию сохранения модели Item.

import mimetypes
import os.path

# init mime types dict
mimetypes.init()

def add_mime_type(instance, **kwargs):
    """
    Adding mime-type to uploaded file (for future use).
    Would be called on post-save.
    """
    if not hasattr(instance, 'mime') or not hasattr(instance, 'file'):
        raise Exception("Object %s does not have 'mime' attribute! Can't set mime-type!" % instance)
    if instance.file:
        extension = os.path.splitext(instance.file.path)[1].lower()
        instance.set_mime(mimetypes.types_map[extension])

Итак, функция-callback add_mime_type принимает параметр instance, который является экземпляром модели, сгенерировавшим сигнал (в нашем случае модели Item). Вторым параметром принимает словарь (dictionary). Кстати, это и есть один из моментов обратной несовместимости. После рефакторинга каждая функция-callback должна принимать параметр **kwargs.

Теперь третий самый простой шаг — связывание модели с сигналом. В самом конце файла моделей добавилась строчка:

models.signals.pre_save.connect(add_mime_type, sender=Item)

Теперь перед каждым сохранением объектов Item, будет выполняться проверка и установка Mime-типа.

Кстати, я советую если у вас больше одного сигнала, выносите их в отдельный файл signals.py или можно по-старинке писать в файле моделей (что ИМХО иногда мешает чтению кода).

Почитать про сигналы можно еще в официальной доке: Django Signals и Django Built-in signal reference. Почитать про рефаторинг можно на странице Backwards Incompatible Changes и в соответствующем коммите 8223.

Александр Кошелев тоже немного раньше написал по теме, статья «А вы поймали новые сигналы?» с хорошим примером создания абстрактного сигнала.

«На сегодня все. Вопросы в студию» :-)

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

Так что ждите в скором будущем новых статей по Django тематике. Думаю осветить подробно:

• эффективное создание форм;
• кастомизация django admin интерфейса;
• трюки с FileField и аплоадом в общем;
• сигналы в django.

Вышла новая переписанная версия Spawning — WSGI сервера. Главное достоинство это non-blocking IO, т.е. большие возможности по масштабируемости (scaling).

Spawning is a wsgi server which supports multiple processes, multiple threads, non-blocking HTTP io, and automatic graceful upgrading of code.

Это очередной способ запуска django и других python-приложений для веб. Пример команды для запуска django процесса:

spawn --factory=spawning.django_factory.config_factory settings --port 9090 -s 4 -t 100

Пример для запуска приложений через paste (например Pylons используют paste для деплоя):

spawn --factory=spawning.paste_factory.config_factory development.ini

Если захотелось поставить и попробовать:

sudo easy_install Spawning

Почитайте еще обзор Эрика на английском.

Update: как ни странно товарищ Александр aka piranha практически одновременно со мной написал статью как раз про деплой через WSGI. Так что моя заметка «пролетает как фанера над Парижем», ибо мягко говоря Spawing не самый быстрый вариант :-) Читайте — Amazon byteflow: WSGI серверы кратко и юзайте fapws2.

Скажу сразу: «я офигел». То, что сейчас предлагает Google для сторонних разработчиков — просто бомба. И не думайте, что App Engine это что-то новое. Да это неплохое дополнение к существуещей инфраструктуре, но самое главное внутри.

Итак, про что же я. GData — универсальный API Google для чтения, записи и поиска в его сервисах. Это очень сбалансированная смесь CRUD и Atom/RSS. Самое главное в GData — это фиды. Результаты поиска, сложные запросы, создание/обновление документов и т.п. возвращаются в формате, подобному Atom фиду. Ребята из Google практически дополнили спецификацию Atom возможностью делать запросы (выборки) и реализовали незаконченную спецификацию Atom Publishing Protocol. Другими словами гугловские сервисы видны через интерфейс GData, как фиды, которые можно читать, апдейтить, искать по каким-то параметрам и удалять. Эта модель работы с данными отлично вливается в сферу веб, что и показала практика Web2.0 (покажите популярный сайт без фида).

Какие сервисы на сегодня доступны через GData API:

• Google Docs;
• Gmail contacts;
• Notebook;
• Blogger;
• Picasa;
• Calendar;
• Base;

Полный список на сайте Google API.

Чтобы не остаться голословным хочу привести пример кода для работы с Google Docs.

import gdata.docs.service

# авторизация
gd_client = gdata.docs.service.DocsService()
gd_client.email = 'username@gmail.com' #change this
gd_client.password = '' #change this
gd_client.source = 'exampleCo-exampleApp-1'
gd_client.ProgrammaticLogin()

# запрашиваем список (фид) всех документов с сервиса
feed = gd_client.GetDocumentListFeed()
# выбираем первый документ для работы
d = feed.entry[0]
# работаем с документом
print d.title.text # выводим название документа
print d.content.src # ссылка на документ в html виде (как он хранится в google)

Для создания или изменения документа необходимо использовать python-модуль atom. Пример кода:

import atom
# устанавливаем название нового документа
document.title = atom.Title(text='my best friends')

Что еще можно добавить. Вышеприведенный код предоставлен разработчиками Google для Python. Т.е. это уже клиентская часть API. Есть также версия для Java, .NET и PHP. Так что если есть желание интегрироваться с Google, то, пожалуй, все необходимое для этого есть.

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

На закусь ссылка на описание протокола GData.

Свежая новость про новый сервис от Гугла. Я не удивлен — Гугл предлагает хостинг приложений. Вполне логичное развитие. Я в принципе давно этого ждал. Что хорошего и что плохого? Много писать не буду.

Хорошее — мощнейшая инфраструктура для хостинга и конечно поддержка приложений на Python ;-)

Плохое — такими темпами скоро «Интернет» == «Google». Я имею довольно приличный опыт в телекоме и хорошо понимаю, что бояться нужно совсем не того что Google индексирует все на свете и типа приватности скоро кирдык. А бояться нужно того, что Гугл сосредоточит большое кол-во интернет-траффика на себе и в результате сможет диктовать свои условия провайдерам. И скорее всего мы получим большое кол-во шаровых вещей в обмен на бесконечный поток контекстной рекламы... Так обычно Гугл и делает. Но не будем о грустном, время покажет.

Подробнее смотрите на страницах Гугла:

• Google App Engine - Google Code
• Google App Engine Blog: Introducing Google App Engine + our new blog
• Running Django on Google App Engine - Google App Engine - Google Code

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

Итак, читайте пост Николая про субъективные причины выбора языка Python для веб-разработки — Блог компании SmartWeb: Почему Python (Муки выбора). Коменты пестрят конечно, но обратите внимание, что ребята целой командой писали до этого на Java, а не на php.

Советую послушать подкаст Димы Честных — Python против PHP. С юмором и по теме.

И немного наблюдений от себя. Последнии пару недель я получил достаточно много разного фидбека по теме корявости php. Так что получилась некоторая закономерность в общении. Итак, немного фактов.

• Примерно 50% утверждавших, что php «рулит», не знают никакого другого языка программирования.
• Около 20% счастливы от самого факта перехода с enterprise (Java, .NET) технологии на динамический язык (php) и пока не осознали, что его им мало.
• Около 25-30% процентов считают отсутствие поддержки python или ruby хостинг-провайдерами причиной для торможения личного развития, как программиста.
• Больше половины писавших на каком-то другом языке программирования перед php, долго на php не задерживаются.

И в довесок хочу дать ссылку на хорошую новую документацию, точнее даже набор примеров работы на python с мелкими задачами — Python-by-example. Оглавление разбито по python-модулям. Ну и конечно, если кто-то решил ознакомиться с python или собирается начать писать что-то на нем, и при этом не знает с чего начать, могу посоветовать книгу В глубь языка Python. Я в свое время начал с придуманной мной самим задачи и официальной документации :-)

Сегодня важное событие у меня. Я наконец-то смог выродить подкаст о веб-разработке, который планировал оч давно записать. Даже не только планировал, но и пробывал. Итак, это моя третья попытка — более-менее удачная. Не могу сказать что я на 100% доволен результатом, но как говориться «первый блин можно и простить» :-)

Для меня намного важнее узнать ваше мнение, уважаемые читатели! На сколько вам был бы полезен вообще подкаст о веб-разработке. И о каких темах вы бы хотели услышать выпуски в будующем. Любые ваши комментарии (желательно конструктивные) будут мотивировать меня для дальнейшей записи. А так как я не диктор и не работал никогда на радио, дается мне сие записывание нелегко... Так что хотелось бы знать интересно ли будет что-то подобное для вас. Жду фидбека, а пока качайте 10 минутное mp3 весом в 14Мб :-)

Отдельный фид для подкаста скоро будет.

Update: сделал еще копию подкаста с битрейтом 128 на 10Мб

Готова вторая подборка интересных ссылок с моими комментариями.

• Google GData Authentication decorator — пример кода для работы с документами google на python (удобный декоратор).
• Control Suite : High Quality Controls & Widgets for Prototype — интересный набор контролов и виджетов для javascript библиотеки Prototype.
• FastInit: a faster window.onload — готвый javascript код (кроссбраузерный) для убыстренной инициализации и вызова js-скриптов. Очень удобно использовать вместо window.onload.
• Cross-Fade Anything — еще одна javascript библиотека для создания слайд-шоу эффекта в Prototype.
• Ext JS - JavaScript Library — очередной javascript тулкит для создания rich ui. Особенность в том, что он позволяет строить оконные интерфейсы aka browser OS.
• LightWindow — реинкарнация популярного Lightbox JS. Позволяет делать js popup с любым контентом, в отличии от lightbox, который позволяет делать popup только картинки.

PS: если вы использовали что-то из указанного в ссылках — поделитесь, пожалуйста. Думаю многим будет интересно узнать чужое мнение.

Наткнулся на интересную заметку. Как автоматизировать загрузку всех моделей из INSTALLED_APPS при запуске django python shell (manage.py shell).

from django.db.models.loading import get_models
for m in get_models():
    exec "from %s import %s" % (m.__module__, m.__name__)

Оказывается очень удобно! :-)

Оригинал — Peter Sheats’ Blog » Blog Archive » Autoloading Your Django Models

Решил сменить свою del.icio.us ленту в сайдбаре на более-менее регулярный постинг интересных ссылок.

А вот место в сайдбаре собираюсь заполнить блогроллом. Так что если хотите попасть в список — напишите мне на имейл или в комментарии свой сайт/блог. Добавляю на условии, что вы ставите на меня обратный линк.

Итак интересное, что я «нарыл» на просторах интернета за последние пару недель.

• StaticGenerator for Django — ссылка дня! очень полезный проект для django-разработчиков, может генерировать статический html вариант сайта из моделей, пользуясь методом get_absolute_url. Самое главное, что через сигналы он может автоматом обновлять html-страницы при изменении/добавлении объектов (т.е. буквально данных в базе).
• Evaluation of web based WYSIWYG-editors, test result 2007 — обзор онлайновых WYSIWYG редакторов (javascript и один на java), с него набрел на один интересный редактор (следующая ссылка).
• WYMeditor - web-based XHTML editor — простой интересный онлайн редактор, без возможности upload/insert images, но зато более семантичный и наглядный для тех, кто знает HTML.
• WYMstyle и css-boilerplate — css frameworks, хороши для веб проектов, когда у вас еще нет дизайна веб-сайта/веб-приложения, но вам нужно более-менее симпатично показать контент и функционал. Облегчают работу тем, кто не любит долгой возни с версткой.
• swfobject 2 — новая переработанная версия (на данный момент rc1) javascript библиотеки для включения в страницу flash/flex роликов или приложений. Кто еще не пробывал — советую, намного удобнее, чем писать кроссбраузерные теги и делать ручные проверки нужной версии flash. Еще можно почитать блог разработчиков — SWFFix Dev Blog.
• transdb — неплохая библиотека для локализации конента в django. Добавляет специальные многоязыковые текстовые поля в модель, что облегчает работу с базой и хорошо интегрируется с существующей системой i18n в django.
• PyAMF — Реализация на Python поддержки протокола обмена данными AMF (от Adobe) для клиент-серверного взаимодействия. Используется во flash и других проектах Adobe. Данные по этому протоколу передаются в бинарном виде, что более-продуктивно с точки зрения потребления траффика, автоматизирована сериализация/десериализация данных как на стороне сервера, так и клиента.

В связи с тем, что в сфере веба и python у меня много знакомых, завел страницу у себя на блоге – Работа для Python программистов. Буду помогать и тем кто ищет себе разработчиков и самим разработчикам. Надеюсь, что через личное знакомство трудоустройство будет приятным для обеих сторон.

Сегодня в feed-ридер попало уведомление из django community про интересную python-библиотеку CleverCSS с примером кода для использования в Django, оригинальный пост автора.

Библиотека позволяет писать CSS на Python с последующей конвертацией "на лету" или генерации статических файлов. Т.к. стили описываются на Python, то следовательно можно использовать всю его мощь для автоматизации дизайна. Представьте, что можно сгенерировать персональные стили для каждого элемента в базе (например для каждой фотки по ее id). Или, например, предоставить пользователям возможность настраивать внешний вид сайта (цвета, шрифт), что особо полезно при создании тем веб-сайтов.

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

После недавнего общения с Иваном, систематизировал в голове свои идеи насчет семантической верстки и связанных с ней нюансов.

Главный вопрос: а зачем нужна семантика в верстке? Может это просто очередной понт, который не имеет реально важного значения?

Хорошо, перейду сразу к делу без всякой теории.

Итак случай первый, когда семантика мне оказалась необходима. Я думаю все, кто разрабатывали средние и мелкие веб-сайты, имели дело с текстовыми материалами заказчика (сделанные обычно в M$ Word). Или возможно Вам просто приходилось переделывать чьи-то текстовые документы (например при подготовке к диплому или редактировании статьи). Я уверен, что любой человек, читающий эту заметку, испытывал трудности при редактировании чужого текста. Типичные примеры это сбивка и прыгание абзацев, заголовков и особенно списков. Так вот любой среднестатистический пользователь ПК, скорее всего, при создании списков сам проставляет номера элементов, забивает пробелами отступы в абзацах, вместо того чтобы воспользоваться соответствующими пунктами меню. В принципе это вполне нормально для круга задач среднестатистического пользователя ПК. Но если пойти чуть дальше в использовании текстового материала, например экспорта в другой формат, то глюки в форматировании текста не заставят себя долго ждать. И даже хорошо поддерживаемый вордом RTF покажет пользователю все прелести несемантической верстки. А если Вам нужно конвертировать на другой носитель информации (например с экрана на бумагу, я не беру в пример стандартное распечатывание страниц в M$ Word), то тут скорее всего пользователя ждет еще больше сюпризов (наиболее часто замечаемый – это переносы строк). А при импорте неправильно сверстанных (читай несемантично сверстанных) документов в среду веб, необходимо перелопачивать весь текст и исправлять (обычно в ручную) неправильные элементы верстки. Далее, если даже осмотреться в самой среде веб, уже можно заметить все больше разноплановых устройств, с помощью которых можно читать веб-страницы. Особенности семантической верстки очень актуальны для мобильных устройств, т.к. они имеют нестандартные размеры экрана и сами браузеры имеют разный уровень качества по парсингу (x)HTML. Поэтому, чтобы оставить на совесть разработчиков мобильного устройства неправильное отображение сверстанных Вами страниц, нужно делать все по стандартам (в которые потом можно будет тыкнуть пальцем ;-)). Возвращаясь к началу моего первого пункта, замечу, что почти всех своих клиентов по разработке веб-сайтов я сначала консультировал, как правильно готовить контент к импорту и публикации на сайт.

Случай второй, когда семантика очень полезна. Семантика в верстке всегда несет смысловую нагрузку. На любом этапе работы с контентом можно понять что хотел сказать контент-менеджер или просто автор текста. Если текст не единичный, а имеет какую-то периодичность, то четкое типовое форматирование намного снижает рутинную работу кодера или верстальщика. Также это очень помогает при создании стилей и оформления документов дизайнерами. Род работ зависит от типа документа (журнал, газета или веб-публикация), но идея семантически верного текста везде одинакова. Для меня это всегда было важно при написании стилей (CSS) для веб-страниц. Т.е. чем больше типовых элементов текста, тем более легко сверстать их внешний вид корректно и тем понятнее, что хотел сказать автор текста на всех промежутках работы над ним. И не забывайте про друга верстальщика – copy n paste ;-), тут семантика будет на Вашей стороне.

Случай третий, самый важный. Автоматизация обработки текста. Часто один и тот же текстовый контент приходится держать в нескольки форматах. Типичный пример – страница веб-сайта доступная как pdf-документ и имеющая версию для печати. Все три варианта текста будут иметь разный внешний вид. Если просто веб-страницу и версию для печати можно просто настроить с помощью стилей (CSS), то с pdf такой вариант не пройдет. Тут нужна конвертация. Как раз на этом этапе будет видно качество верстки текста. Но это не совсем полный пример автоматизации. Некоторое время назад (достаточно давно) я писал на PHP CMS движок для веб-сайта. Одним из требований была синхронизация сайта по нескольким зеркалам. Синхронизация БД не была возможна по некоторым техническим причинам, поэтому был выбран вариант хранения всей информации в XML-файлах. Но немного поразмыслив я решил использовать XHTML формат для контента, в итоге в чистом XMLе хранилась только карта сайта, из которой генерировались URL. Почему же я выбрал XHTML? Дело в том, что XHTML может рендерить сам браузер (мне его остается только стилизовать, например с помощью CSS), поэтому отпадает нобходимость в конвертации текста в HTML формат. С другой стороны XHTML дает возможность работать с текстом средствами XML-утилит. В итоге получилась очень удобая смесь. При сохранении контента он строго семантически форматировался в нужные элементы с соответствующими аттрибутами, что давало возможность мне использовать их для стилизации на стороне клиента (через CSS) и обработки (фильтрации, выборки и поиска) на стороне сервера. Давайте рассмотрим пример.

Отличная погода сегодня в городе
2007/09/22
Весь город сегодня вышел на улицы, чтобы ощутить последнее осеннее тепло...
Подробнее ...


some other text

В данном примере я могу использовать названия элементов и аттрибутов в CSS файле для стилизации текста и в тоже время на стороне сервера, например с помощью xpath я могу выбрать все заголовки новостей. Вот пример xpath-выражения: /body[@id='root-node']/div[@class='news-node']/h1[@class='news-head']. Самое главное что такой четко структуированный документ всегда будет легко экспортировать в любой другой формат. В данном случае, спустя год я переделывал сайт на django и буквально за несколько часов написал скрипт, который перевел весь контент (без единой потери) в базу джанги.

На Python такой запрос будет выгялдеть так:

import libxml2
xml = """ .... """ # тут кусок xml приведенный выше
doc = libxml2.parseDoc(xml)
head_node = doc.xpathEval("/body[@id='root-node']/div[@class='news-node']/h1[@class='news-head']")[0]
print head_node.content

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

Недавно второй раз на практике столкнулся с серьезной задачей по работе с XML на Python. И второй раз был расстроен. К сожалению не все просто в Python настолько, насколько хотелось бы.

Говоря в общем, встроенная в последний Python (2.5) ElementTree не совсем хороший выбор, как по мне, для полноценной работы с XML. С помощью ElementTree удобно создавать XML-документы, но никак не парсить. Я был удивлен, что такая простая задача как принять XML-документ из переменной—окажется такой замороченной… ElementTree заточен для парсинга файлов (т.е. ему нужно передавать при открытии или путь или уже открытый файл). В моем случае я уже имел переменную из HTTP-запроса, обработанного Django. Несколько часов я плясал с бубном, сначала чтобы заставить принять XML-документ из переменной, потом уже с самим парсингом и получением аттрибутов тегов. В общем убил много времени впустую, что очень неприятно. В довесок ко всему общеизвестный факт что ElementTree имеет очень ограниченную документацию, поэтому время было потрачено дополнительно на гугление и ковыряние в его сырцах.

Хочу отметить что создание XML-документа с помощью ElementTree оказалось достаточно простым и удобным. А начинали мы именно с создания, поэтому и парсинг позже пытались делать тем же ElementTree.

В итоге, после всей возни, я решил для парсинга использовать отдельную библиотеку—Beautilful Soup. И работа сразу пошла очень быстро. Главное достоинство Beautilful Soup—это практически полная сериализация XML-документа в объекты Python. Что очень хорошо отражается на читаемости кода и очень удобно при отладке. Насчет создания документов с помощью Beautilful Soup, ничего сказать не могу, т.к. небыло времени для себя потестировать.

Из прошлого своего опыта также добавлю, что есть еще одна библиотека для работы с XML на Python—lxml. Она базируется на Cи библиотеках libxml и libxslt. Которые в свою очередь используются в большом количестве unix-приложений и других скриптовых языках. Прошлая моя задача была свзязана с выборкой данных из XML-документов с помощью Xpath. Так вот lxml и в частности libxml имеет хорошую и удобную реализацию Xpath. Так что рекомендую.

PS: Все написанное выше—сугубо личное мнение, на которое в принципе имею право :)

Ниже примеры кода.

# пример парсинга XML через Soup
from BeautifulSoup import BeautifulStoneSoup as Soup

def some_view(request):
    message = Soup(request.raw_post_data)
    some_obj = Obj(content = message.body.string, phone = message.sin.string)
    # message.body - body это xml тег

# пример создания XML-документа
import elementtree.ElementTree as ET

# создаем документ
root = ET.Element("message") # рутовый элемент 
root.set("rid", "7idfndsi9s") # устанавливаем ему аттрибут
sn = ET.SubElement(root, "sn")
sn.text = "1039303" 
body = ET.SubElement(root, "body")
body.set("content-type","text/plain")
body.text = "somte text content" 
message = ET.tostring(root)

 1039303
 somte text content

Последнее время стал увлекаться подкастами. К сожалению русскоязычных качественных очень мало. А на тему веб-разработок вообще нет (поправьте если ошибаюсь).

Хочу привести свою подборку англоязычных подкастов, которые слушаю.

1. Начну с наиболее интересного для меня—Hivelogic Radio. В этом подкасте автор концентрируется на веб-разработке, как на дизайне так и на программировании. Очень интересные интервью с интересными людьми. В разработке есть акцент на Ruby on Rails. Со стороны аудио, подкаст сделан очень качественно. Приятно слушать.
2. Следующий подкаст я слушаю не так давно, но у него довольно большой авторитет—FOO Casts: Podcasts from O’Reilly & Friends В нем освящается много технических вопросов, необязательно связанных с вебом, но все равно полезных для любого гика и разработчика. Качества звука тоже на высоте.
3. Inside Silicon Valley—Подкаст, состоящий в основном из интервью с монстрами и просто успешными людьми из Силиконовой Долины. Качество хорошее, слушать интересно.
4. Python411 Podcast—для фанов Python. Качество звука не впечатляет, но темы и интервью довольно интересные. Так что подкаст пожалуй действительно для фанатов Python. Освящаются вопросы не только веб-разработки, но и других специализаций в программировании.
5. WebDevRadio—Действительно настоящий подкаст именно для веб-разработчика. Обсуждение новых технологий в вебе, интервью, относительно часты обновления. Советую.
6. The Mac Attack—Подкаст про Mac, MacOSX и все что с ним связано. Как известно многие современные веб-разработчики и дизайнеры выбирают платформу Apple в качестве рабочей станции. Так что думаю будет просто интересно, а некоторым и полезно.

В связи с появлением в trunk-ветке django такой прикольной библиотеки, как newforms, пришлось на нескольких проектах переползать на trunk. При этом все остальные должны стандартно работать на версии 0.95

В системе стоит как раз 0.95 (в site-packages). Проекты работают все на связке mod_python + apache. При настройке mod_python для django-проекта используется директива PythonPath. С её помощью к путям поиска python-модулей добавляется директория с проектом. Поэтому достаточно положить дистрибутив django в ту же директорию где лежит проект.

А вот для отладки приложения приходится немного пошаманить. Я так и не разобрался в чем причина, но когда запускаешь python shell (python manage.py shell) в любом случае в списке директорий с модулями site-packages оказываются первее чем то, что добавляешь в PythonPath переменную окружения. В итоге получается что используется версия django, котрая стоит в site-packages (т.е. 0.95).

Решается всё довольно просто, но дошел я до этого не сразу, т.к. боролся чтоб всё было кошерно :-) (через python manage.py shell). Сначала грешил на ipython, но без него была та же петрушка. Наковырявшись вдоволь я сделал потом всё по быстрому и просто.

1. PYTHONPATH=’path_to_Django_project‘
2. DJANGO_SETTINGS_MODULE=my_project.settings

После этого в любой директории набераете python или ipython и делаете импорты из моделей и работаете с ними.

Прошла еще одна конференция в Киеве по языку программирования Python—Exception #2. И я там был, как говориться, мед пиво пил :)

К сожалению послушать смог только один доклад, Евгения—“Взаимодействие Python с другими языками”.

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

Могу сказать отдельно что мне больше всего был интересен момент про оптимизацию python-программ. Были наглядные примеры и с кодом и с результатом на вполне реальной задаче. Теперь некоторые моменты лучше уложились (по полочкам :-) в голове.

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

Есть проблема в Django с удалением файла в FileField и ImageField из админки. Проблема давняя, а до сих пор не решенная, недавно вернулись к её обсуждению. Вот патч лежит уже три месяца как. Вчера вроде по нему появилась активность. Посмотрим…

Вот старый тикет #22 (его закрыли) и новый #2534 с более “умным” патчем.

А от себя скажу, что в модели файл получается удобнее хранить в отдельной таблице, в большинстве случаев. Т.к. при удалении ссылающегося на него объекта, сам файл можно оставить и потом использовать опять (если файл большой, то каждый раз его заливать неудобно при удалении/добавлении зависящего объекта); да плюс обычно хранится не тупо неизвестный binary файл, а что-то более интересное, нуждаещееся в описании и какой-то мета-информации, следовательно удобно было бы потом делать расширенное описание файла добавлением новых полей в таблицу по мере необходимости.

И если брать частный случай с Django, то тогда файл можно легко удалить как отдельный эелемент модели.

Конференция по Python в Киеве Exception #1 прошла успешно!

Спасибо организаторам и всем активным участникам! Лично мне было очень интересно!

Презентация к моему докладу в виде pdf

Фото можно посмотреть в моем альбоме. Пока офциальная версия фоток не выложена.

• Pylons
• Clever Harold
• web.py
• Turbo Gears
• Django

Русский сайт по agile development agiledev.ru.

ORM про который много говорилось SQLAlchemy

Мои персональные контакты: dobrych [at] gmail.com отзываюсь как на email так и на чат (google talk). ICQ: 2211123

Меня еще можно почитать на tophost.com.ua/blog

Update: про конференцию еще написал Алексей в своем блоге. Обсуждение на deveopers.org.ua

Два треда на PythAgora-ua – Материалы с Exception #01 и Exception #01 прошёл.

Вот нашлось еще одно решение как раскрасить код.

Pygments поддерживает большое кол-во языков:

• Boo
• BrainFuck
• C, C++
• C#
• Delphi
• Java
• JavaScript
• Lua
• PHP
• Perl
• Python (incl. console sessions)
• Ruby (incl. irb sessions)
• Visual Basic.NET
• CSS
• Diff files
• HTML
• INI-style config files
• IRC logs (irssi style)
• Makefiles
• SQL
• TeX
• XML
• Django/Jinja templates
• Smarty templates
• ERB (ruby templating)

Работает только на Python. Поэтому использовать его нужно или через командную строку или встраивать в двжиок сайта (если он на Python).

Вот еще одна причина побыстрее переводить свой блог на Python :-)

В конце октября (24-ого) будет конференция в Киеве по программированию на Python.

Основная тема – Python для web. Буду докладчиком. Приходите послушать :-)

После конференции обещаю выложить весь материал.

Читать про конференцию Exception #1