Даёшь Django в народные массы!

Затычки к django-multilingual-ng

2011-04-03T14:56:00.000+04:00

Из всех "многоязычных" решений на Django самым внятным мне показался django-multilingual-ng, от авторов django CMS. Сама django CMS по смыслу не очень подошла для текущего проекта, поэтому было принято решение сделать своё решение, позаимствовав часть идей из django CMS.
То, что django-multilingual-ng написано под django CMS, к сожалению, дало неприятный косяк в том, что оно "из коробки" не другит с FeinCMS. Причём в тикете автор говорит - используйте лучше django CMS, что довольно странно, если мне нужен всего-лишь UI для редактирования mptt-деревьев.
Понадобилось тут ещё добавить некоторое удобство - чтоб в админке словарики (многоязычные) были по алфавиту отсортированы (в соответствии с текущим языком, конечно).
Поле ordering для ModelAdmin, естественно, не подходит, ибо переводы лежат в отдельной таблице и поля разные для разных языков получаются.
Поковырявшись в джанге получился вот примерно такой велосипедик:

class NameMultilingualAdmin(MultilingualModelAdmin):
    list_display = ('name',)

    @gll
    def get_changelist(self, request):
        field = 'name_%s' % GLL.language_code
        from django.contrib.admin.views.main import ChangeList
        
        class NameOrderedChangelist(ChangeList):
            def get_ordering(self):
                return (field, 'asc')

        return NameOrderedChangelist

Палка о 2 концах

2011-03-04T00:47:00.000+03:00

К дифирамбам легкому созданию форков в прошлом посте надо добавить солидную ложку дёгтя: когда форков становится слишком много и забивают на upstream, то изменения могут разойтись, усложняя или делая вообще маловозможным обмен кодом между форками. Оказалось, просто, что юникод в оригинальном django-filebrowser уже поддерживается в последней версии (причём в выполненном тикете файл с русским именем), а форк без поддержки grappelli сделан заметно ранее и изменения из upstream в него не вливались. В общем, свобода - это хорошо, но лучше чтоб она давалась человеку, который понимает как и зачем ей пользоваться.

Unicode rulezz

2011-02-27T01:09:00.000+03:00

Вроде всё-таки начал делать более-менее реальный проект на Django, поэтому появляются поводы писать сюда.
Потребовалась работа с файлами (плюс интеграция с tinyMCE), к сожалению, django-filebrowser тянет в зависимостях grappelli, который совсем вроде как не сдался (думаю admin_tools вполне хватит). Нашёлся форк с "отпиленными" grappelli и uploadify, но загвоздк оказалась в том что он хочет "буквы" в именах файлов, а русские буквы, конечно же, буквами не являются на его взгляд. Чтож, 5 минут и готов по-моему вполне рабочий форк.
Open source и github в частности, по-моему, довольно сильно меняют процесс разработки, причём в лучшую сторону. Обмен кодом/идеями - очень хорошая вещь.

Об истории джанго

2010-08-25T00:11:00.000+04:00

Для тех, кто не в курсе - откуда появился Django.

Патчим PIL под Windows

2010-06-18T13:33:00.000+04:00

Сам я вот уже полтора года сижу на Linux, поэтому проблемы с виндовыми библиотеками как-то меня не особо касались.
Но, не так давно, взялся руководить одним студенческим проектом на Django, предложил на выбор: или ставить линукс (хотяб в виртуалку) или иметь сношения с зависимостями виндовых библиотек. С линуксом не так чтоб здорово, поэтому все выбрали 2-й вариант.
И вроде бы особых проблем не было, если не считать чуть более хитрую настройку всего зоопарка.
Но вот на днях "отвалилась" у них капча со словами: "The _imagingft C module is not installed", сами они разобраться не смогли, пришлось мне делать вскрытие.
Оказалось, что товарищи сборщики прописали левую зависимость в библиотеку. Пересобирать как-то совсем было лениво, поэтому просто взял Resource Hacker и вырезал следующий кусок

  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b">
    </dependentAssembly>
  </dependency>

к чёртовой матери из _imagingft.pyd.

P.S. Обнаружил http://draft.blogger.com/, который более внятно работает с HTML (странно, что по дефолту стоит совсем кривой редактор)

Django In Depth от Джеймса Беннета

2010-06-04T18:28:00.001+04:00

По-моему, отличнейшая презентация (и почему я на неё только вчера наткнулся?) :

Django In Depth

View more presentations from ubernostrum.

По следам...

2010-04-17T22:22:00.004+04:00

Вспомнил, что начинал читать Pro Django, и решил продолжить это дело. И почти сразу нашёл пояснение к предыдущей проблеме с переменными в блоках DTL: контекст, передаваемый в шаблоны организован в виде стэка.
Оказалось, что и в официальных джанговских доках это тоже описано.
P.S. В комментах и в своём блоге alerion дал решение в прошлый раз (но до его блога я не добрался, а приведённый вариант был не до конца понятен).

Продолжая тему нескольких портов

2010-04-13T23:19:00.002+04:00

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

О портах в nginx

2010-04-13T00:14:00.002+04:00

Потребовалось развернуть 2 разных инстанса сервера на джанго на одном и том же хосте, но на разных портах.
Django крутится в mod_wsgi за nginx.
На первый взгляд всё выглядело нормально, но сюрприз образовался, когда попытался я зайти в админку: после логина следовал редирект на сайт с дефолтным 80-м портом (хотя в админку я залезал по другому порту).
Вскрытие (спустя более часа разбирательств) показало, что во всём виноват проксирующий nginx, в котором была прописана директива "proxy_set_header Host $host:$server_port;". Всё легко разрешилось добавлением порта - "proxy_set_header Host $server_port;".

Pip, о сколько в этом слове...

2010-04-11T22:08:00.002+04:00

Что-то вот совсем понять не могу в чём проблема и как её диагностировать:
Через fabric создаётся новый virtualenv и в него устанавливаются все зависимости с помощью "pip install -r requirements.txt". Всё вроде бы хорошо, но иногда pip зависает на продолжительное время и весь процесс занимает десятки минут вместо стандартного времени менее минуты.

И ты, брут?

2010-04-08T19:27:00.000+04:00

Я был несколько удивлён узнав, что студия, сами знаете кого, тоже использует джанго.

А мужики-то не знают!

2010-04-03T22:39:00.002+04:00

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

Администрируемые настроечки и github

2010-03-31T00:08:00.002+04:00

Понадобились тут для приложения настраиваемые настройки в админке (буквально потребовалось сделать редактируемыми адреса для отрпавки определённых формочек). Не желая изобретать свой велосипед, полез в гугл. Там обнаружил с ходу старенький django-dbsettings, который мне показался каким-то не кузявым: проект заброшен (хотя есть форки на github) да и с ходу не нашёл там группировки настроек (адреса и сабжи отличаются для разных форм). Следующим оказался совсем свежий django-appsettings. Вроде бы простое приложение, но я что-то 2 вечера разбирался в (ещё не очень знакомых мне) фокусах с метапрограммированием на python, которые там используются. Всему виной, по-моему, несколько противоречивое README к проекту. Ключевым вопросом стало то, что для подключения настроек для приложения необходимо, чтобы эти настройки были использованы в моделях приложения, т.е. в них должны присутствовать строки:


from appsettings import app
settings = app.settings.your_app

которые и вызывают соответствующий autodiscover().
С учётом этого всё стало довольно прозрачно и ясно и группировки вроде на месте, только вот в интерфейсе администрирования их не было у Джареда. Пришлось "форкнуть" проект и реализовать то, что необходимо.
Поставил в итоге ещё один плюсик гиту и понравился github. Правда в последнем обнаружилось пару багов: с коммитом, начинающимся с # он по ходу дела не дружит (в итоге пришлось делать merge из коммандной строки), да ещё на 1-м из флэшевых графов мой Firefox просто "схлопнулся". А в целом очень удобно - возьму себе на вооружение.
P.S. Ещё для настроек есть какое-то решение от авторов Satchmo, но смотреть его как-то было уже лень, когда было получено практически рабочее решение.

Работать надо меньше...

2010-03-23T01:20:00.003+03:00

Минут пятнадцать сидел и "тупил" по поводу того, почему Джанго не хочет переводить строчку, когда локализация к ней написана и скомпилирована. Оказалось, что надо было просто лишь перегрузить девсервер.
Кстати, по поводу локализации: в грядущей версии 1.2 появится новый флажок с говорящим за себя названием - USE_L10N.

Разделяй и не властвуй?

2010-03-20T00:32:00.003+03:00

Эксперименты показывают (в исходники самой Джанго пока не залезал толком), что Django Template Language имеет один не совсем неочевидный ньюанс: переменные, которые устанавливаются с помощью templatetag'ов в блоках, не "шарятся" между разными блоками. В итоге получается, что их надо устанавливать переменные заново в каждом из блоков, т.е. получаем как минимум лишний вызов, и возможно ещё и совершенно лишний запрос к базе.
Можно, конечно, результаты запроса кэшировать, если есть необходимось, но всё равно дублирование остаётся. С другой стороны, безусловно, установка переменных из шаблона не есть правильный подход, всё должно быть установлено по возможности на уровне view или в middleware. Но вот данные нужны на уровне именно самого шаблона, view находятся, в ныеншнем случае, в django CMS, а шаблоны могут туда передаваться разные, данные же эти нужны лишь в одном из них.
Получается или я что-то реально недопонимаю или всё выглядит немного некрасиво.

Советская власть и русификация всей страны

2010-03-11T22:10:00.002+03:00

Обнаружил тут вдруг, что, несмотря на довольно хорошую поддержку интернационализации в Джанго, с локализацией не всё так тривиально, как хотелось бы. По сути надо было решить очень простую задачу - выводить локализованные имена месяцев в архиве новостей (хотя кто знает, что там дальше понадобится ещё). Есть, конечно, datetime.strftime, только вот он пляшет от текущей локали, которая задаётся на весь процесс и не управляется Джанго. В итоге поставил BabelDjango и использовал format_date(date, 'LLLL') оттуда.

О django CMS

2010-02-19T18:27:00.004+03:00

Планировали тут для одного проекта поднять Drupal, потому как основная задача там - CMS. После чтения доков и исходников пришли к выводу, что даже руками на Джанго будет собрать сервер быстрее, плюс необходимые механизмы интеграции требуют достаточной гибкости. Готовые фичи "из коробки" - это, конечно, интересно, но хочется иметь возможность манёвра. Ну и примеры кода под друпал, в котором на прямую запросы к таблицам самого друпала делаются, как минимум, смутили. Хотя, безусловно, нехилое сообщество пользвателей и большое число инсталляций может является некоторым плюсом. Но по-моему гораздо удобнее пользоваться инструментом, для которого понимаешь, как он работает, и представляешь варианты того, что надо сделать для реализации нового функционала. Поэтому родилось по-моему логичное решение: в топку PHP.
Писать совсем с нуля CMS было бы несколько грустно, а для джанго они уже есть. Правда, не так чтоб их было огромное количество, да и по поводу распространённости/фичам ситуация не так чтоб совсем идеальная, но варианты имеются.
По следам статьи "Picking a Django powered CMS" в первую очередь взгляд упал на FeinCMS. Вещь в целом вроде неплохая, но всёже по принципу оно больше похоже на то, что называют (пхпшники в основном) CMF, т.е. компоненты надо ещё подгонять нужным образом, чтобы получить саму CMS. Плюс ещё вылез какое-то исключение при создании перевода страницы, причина которого сходу была неясна.
Это заставило всплыть в памяти мысли о django CMS. Поставил, настроил, "натянул" дизайн, посоздавал странички и контент для них и оно мне реально понравилось. Возможно пока я ещё не обнаружил проблемных мест, но на данный момент считаю django CMS довольно хорошим проектом, довольно гибким и удобным. Немного, правда, смущает число тикетов по системе, но реальных шоу-стопперов я не обнаружил.
Надеюсь, что за не очень большое время проект удастся довести до ума и заменить старую неуклюжую пхп-версию на джанговскую, которую можно будет легко и непринуждённо расширять и модифицировать, ну и, надеюсь, что django CMS в этом поможет.
P.S. Рекомендую ещё по этому поводу статью "Друпал или Джанго".

Очередная находка ньюба

2010-02-19T01:29:00.002+03:00

Оказывается, что приложение Джанго не может совпадать по имени с именем проекта, причём проявилость это у меня довольно хитрым способом. Дело в том, что понадобилось мне забацать свой templatetag, создал приложение (с совпадающим именем), а Джанга ругается. Чуть потыркался, остановил девелоперский сервер, пытаюсь запустить runserver_plus из django-command-extensions, а оно мне отвечает: "Не, чувак, нет у тебя этих расширенных комманд, погляди в комманду хелп, убедись". Нормальный же runserver запускается и работает, только вот templatetag, конечно же не находит.
В целом, ещё один урок на тему, что с именами в Питоне надо быть чуть аккуратным.
P.S. И абсолютный импорт тут ничем не поможет.

И что они нашли в django-pagination?

2010-02-15T00:51:00.004+03:00

Куча джангописателей (наприме, включая авторов Pinax) используют django-pagination, но по-моему товарищ Эрик выдаёт несколько кривой результат для большого числа страниц. Например страницы могут вылядеть следующим образом:
<<previous 1 2 ... 5 6 7 8 ... 20 21 next>>
Сразу обращает на себя асимметрия результата, плюс ещё в начале и в конце много страниц отображается.
По-моему гораздо симпатичней (и даже чуточку логичней) вариант
< Prev 1 ... 5 6 7 8 9 ... 21 Next >
вот отсюда.
P.S. А blogger ужасно хреново работает с угловыми скобками, сил нет.

Все аналогии ложны.

2010-02-13T00:59:00.002+03:00

Размышляя над разницей между подходами и приёмами прниятыми на PHP и в python (в основном я рассматриваю Django, т.к. с другими фреймворками я не очень хорошо знаком), всё чаще в голову приходит аналогия с противопоставлением Windows и Linux. В PHP в основном всё уже готово "из коробки" и та же поддержка апачем особых плясок с конфигами не требует, тогда как с тем же Django приходится разобраться с процессом развёртывания, да и вариантов там сразу целая пачка (если не больше). Ну и самый большой аргумент, на мой взгляд, это модульность и гибкость, которая позволяет на линуксе, джанге достичь больших результатов, но в итоге требует больших усилий головного мозга (как говорят "если в линуксе можно настраивать программу, то вам, скорее всего, её придётся настраивать"). А модульность эта не может строиться без достаточной стройности идеологии и структуры системы (не могу не привести ссылку на свой прошлый пост про reusable apps).

Зависимости, зависимости...

2010-02-05T00:35:00.002+03:00

У товарища тут вышла проблема с разворачиванием приложеньица на джанге. Вроде всё сделано нормально, но выдаёт, хоть ты тресни, ошибку импорта, аля "не могу импортировать 'test.settings'", но файл-то лежит рядом и из питона нормально импортируется. Битый час придумывал, откуда могут ноги у этой проблемы расти. Оказалось всё тривиально - в поставке питона идёт модуль test, поэтому возник конфликт пакетов.
Так что называйте папки (и пакеты) внятно!

Спасибо русским программистам!

2010-01-18T00:00:00.002+03:00

Предыдущая война с mod_wsgi закончилась в итоге тем, что Apache был "спрятан" за проксирующий nginx, что решило проблему с "залипающими" запросами. Заодно и статике теперь должна оптимальней отдаваться.
Думал было использовать ещё Nginx upload module, написал даже нужный код (т.к. данные в итоге приходят немного иначе). Однако, по запарке забыл код обновить, а в результате обнаружилось, что оно и без этого замечательно работает. Поэтому оставил пока тот вариант "на всякий пожарный". Хотя толком не помешало бы тесты сделать, чтоб понять, даст ли оно какую-либо разницу.
В любом случае nginx рулит, спасибо Игорю Сысоеву.

WSGI...

2010-01-06T13:41:00.002+03:00

Вот толи я неважный линуксовый админ, толи в связке CentOS+mod_wsgi что-то "нетак":
время от времени Apache "затыкается" и из внешних признаков обнаружились лишь записи с "Premature end of script headers:" для сайта на Django. Причём вчера такое поведение получилось повторить сделав touch одному из wsgi-скриптов, ошибки же повалились для другого сайта, откуда могут тут взяться "наведённые" проблемы совершенно непонятно.
Возможно, надо обновить mod_wsgi с 2.5 до 2.8, или вообще собрать по-нормальному другой сервер (и плюнуть на CentOS), но пока чуть поживём с непонятками.

2010-01-05T20:11:00.001+03:00

Django-chunks вроде бы совсем мелочь-мелочью, но для вставки всякой ерунды а-ля баннеры очень даже удобно.

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

2009-12-28T00:44:00.002+03:00

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

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

2009-12-14T10:08:00.002+03:00

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

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

2009-11-16T09:54:00.002+03:00

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

Красиво :)

2009-10-10T20:04:00.001+04:00

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

DjandoCon 2009

2009-09-26T00:00:00.003+04:00

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

Go shopping!!!

2009-09-08T22:44:00.002+04:00

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

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

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

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

2009-08-27T22:55:00.002+04:00

Для первого нашего 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, и это далеко не радует.

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

2009-08-26T00:49:00.002+04:00

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

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

2009-08-22T00:17:00.002+04:00

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

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

2009-07-31T16:00:00.002+04:00

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

R.I.P. mod_python

2009-07-28T23:21:00.003+04:00

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

Deployment не задался.

2009-07-24T20:56:00.004+04:00

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

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

2009-07-18T23:57:00.002+04:00

Пытаюсь сейчас разобрать деплоймент 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.
Теперь я понимаю, о чём Джеймс Беннет писал в своём посте про проблемы с пакетами.
Продолжу разбираться дальше и, наверное, напишу пост о варианте развёртывания, который у меня получится.

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

2009-07-15T23:31:00.003+04:00

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

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

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

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

2009-07-01T23:24:00.002+04:00

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

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

2009-06-24T22:48:00.002+04:00

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

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

2009-06-14T22:33:00.008+04:00

По совету 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'

Ну зачем так?

2009-05-15T11:49:00.001+04:00

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

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

2009-05-13T20:55:00.004+04:00

Понадобилось тут вырезать адрес 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, жестоко коверкающим тэги

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

2009-05-04T23:13:00.002+04:00

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

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

2009-05-03T11:15:00.002+04:00

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

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

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

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

2009-05-02T20:20:00.004+04:00

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

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

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

2009-04-26T12:30:00.005+04:00

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

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

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

Патчим Django

2009-04-22T22:52:00.003+04:00

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

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

2009-04-16T22:17:00.002+04:00

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

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

2009-04-09T21:57:00.002+04:00

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

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

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

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

2009-04-07T23:21:00.001+04:00

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

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

2009-04-05T10:40:00.003+04:00

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

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

2009-04-03T23:20:00.002+04:00

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

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

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

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

2009-04-01T22:28:00.004+04:00

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

Ресурсы о Django

2009-03-30T23:19:00.002+04:00

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

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

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

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

2009-03-29T10:27:00.003+04:00

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

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

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

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

2009-03-28T09:22:00.002+03:00

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

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

2009-03-27T00:32:00.002+03:00

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

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

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

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

2009-03-25T22:25:00.002+03:00

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

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

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

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

2009-03-24T18:40:00.002+03:00

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

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

2009-03-23T23:16:00.001+03:00

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

PHP → Django

2009-03-23T17:23:00.000+03:00

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

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

2009-03-23T17:08:00.000+03:00

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