среда, 25 августа 2010 г.
пятница, 18 июня 2010 г.
Патчим PIL под Windows
Сам я вот уже полтора года сижу на Linux, поэтому проблемы с виндовыми библиотеками как-то меня не особо касались.
Но, не так давно, взялся руководить одним студенческим проектом на Django, предложил на выбор: или ставить линукс (хотяб в виртуалку) или иметь сношения с зависимостями виндовых библиотек. С линуксом не так чтоб здорово, поэтому все выбрали 2-й вариант.
И вроде бы особых проблем не было, если не считать чуть более хитрую настройку всего зоопарка.
Но вот на днях "отвалилась" у них капча со словами: "The _imagingft C module is not installed", сами они разобраться не смогли, пришлось мне делать вскрытие.
Оказалось, что товарищи сборщики прописали левую зависимость в библиотеку. Пересобирать как-то совсем было лениво, поэтому просто взял Resource Hacker и вырезал следующий кусок
P.S. Обнаружил http://draft.blogger.com/, который более внятно работает с HTML (странно, что по дефолту стоит совсем кривой редактор)
Но, не так давно, взялся руководить одним студенческим проектом на 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 (странно, что по дефолту стоит совсем кривой редактор)
пятница, 4 июня 2010 г.
Django In Depth от Джеймса Беннета
По-моему, отличнейшая презентация (и почему я на неё только вчера наткнулся?) :
Django In Depth
View more presentations from ubernostrum.
суббота, 17 апреля 2010 г.
По следам...
Вспомнил, что начинал читать Pro Django, и решил продолжить это дело. И почти сразу нашёл пояснение к предыдущей проблеме с переменными в блоках DTL: контекст, передаваемый в шаблоны организован в виде стэка.
Оказалось, что и в официальных джанговских доках это тоже описано.
P.S. В комментах и в своём блоге alerion дал решение в прошлый раз (но до его блога я не добрался, а приведённый вариант был не до конца понятен).
Оказалось, что и в официальных джанговских доках это тоже описано.
P.S. В комментах и в своём блоге alerion дал решение в прошлый раз (но до его блога я не добрался, а приведённый вариант был не до конца понятен).
вторник, 13 апреля 2010 г.
Продолжая тему нескольких портов
Разбираем дальше вчерашнюю тему нескольких сайтов на одном хосте.
Скорее всего вам не помешает, чтобы можно было заходить одновременно в несколько админок на разных сайтах (т.е. разных портах). По умолчанию это не сработает, т.к. куки сессии будет совпадать для обеих сайтов. По-моему логично разрешить проблему при помощи разных SESSION_COOKIE_NAME в файлах настроек.
Скорее всего вам не помешает, чтобы можно было заходить одновременно в несколько админок на разных сайтах (т.е. разных портах). По умолчанию это не сработает, т.к. куки сессии будет совпадать для обеих сайтов. По-моему логично разрешить проблему при помощи разных SESSION_COOKIE_NAME в файлах настроек.
О портах в nginx
Потребовалось развернуть 2 разных инстанса сервера на джанго на одном и том же хосте, но на разных портах.
Django крутится в mod_wsgi за nginx.
На первый взгляд всё выглядело нормально, но сюрприз образовался, когда попытался я зайти в админку: после логина следовал редирект на сайт с дефолтным 80-м портом (хотя в админку я залезал по другому порту).
Вскрытие (спустя более часа разбирательств) показало, что во всём виноват проксирующий nginx, в котором была прописана директива "proxy_set_header Host $host:$server_port;". Всё легко разрешилось добавлением порта - "proxy_set_header Host $server_port;".
Django крутится в mod_wsgi за nginx.
На первый взгляд всё выглядело нормально, но сюрприз образовался, когда попытался я зайти в админку: после логина следовал редирект на сайт с дефолтным 80-м портом (хотя в админку я залезал по другому порту).
Вскрытие (спустя более часа разбирательств) показало, что во всём виноват проксирующий nginx, в котором была прописана директива "proxy_set_header Host $host:$server_port;". Всё легко разрешилось добавлением порта - "proxy_set_header Host $server_port;".
воскресенье, 11 апреля 2010 г.
Pip, о сколько в этом слове...
Что-то вот совсем понять не могу в чём проблема и как её диагностировать:
Через fabric создаётся новый virtualenv и в него устанавливаются все зависимости с помощью "pip install -r requirements.txt". Всё вроде бы хорошо, но иногда pip зависает на продолжительное время и весь процесс занимает десятки минут вместо стандартного времени менее минуты.
Через fabric создаётся новый virtualenv и в него устанавливаются все зависимости с помощью "pip install -r requirements.txt". Всё вроде бы хорошо, но иногда pip зависает на продолжительное время и весь процесс занимает десятки минут вместо стандартного времени менее минуты.
четверг, 8 апреля 2010 г.
суббота, 3 апреля 2010 г.
А мужики-то не знают!
Обнаружил , что у pip есть опция кэшировать загружаемые пакеты. Для этого надо присвоить переменной окружения $PIP_DOWNLOAD_CACHE папку, где будет располагаться этот кэш.
Забавно, но на оф. сайте pip эта опция фигуриует только в новостях.
На самом деле захотелось сделать развёртывание совсем с 0, с созданием virtualenv и не заморачиваясь на исправление зависимостей, но каждый раз скачивать десяток мегабайт по-моему всёж некоторое расточительство, особенно когда состав пакетов менятся довольно редко. Пусть даже и в наше время мегабитных подключений.
Забавно, но на оф. сайте pip эта опция фигуриует только в новостях.
На самом деле захотелось сделать развёртывание совсем с 0, с созданием virtualenv и не заморачиваясь на исправление зависимостей, но каждый раз скачивать десяток мегабайт по-моему всёж некоторое расточительство, особенно когда состав пакетов менятся довольно редко. Пусть даже и в наше время мегабитных подключений.
среда, 31 марта 2010 г.
Администрируемые настроечки и github
Понадобились тут для приложения настраиваемые настройки в админке (буквально потребовалось сделать редактируемыми адреса для отрпавки определённых формочек). Не желая изобретать свой велосипед, полез в гугл. Там обнаружил с ходу старенький django-dbsettings, который мне показался каким-то не кузявым: проект заброшен (хотя есть форки на github) да и с ходу не нашёл там группировки настроек (адреса и сабжи отличаются для разных форм). Следующим оказался совсем свежий django-appsettings. Вроде бы простое приложение, но я что-то 2 вечера разбирался в (ещё не очень знакомых мне) фокусах с метапрограммированием на python, которые там используются. Всему виной, по-моему, несколько противоречивое README к проекту. Ключевым вопросом стало то, что для подключения настроек для приложения необходимо, чтобы эти настройки были использованы в моделях приложения, т.е. в них должны присутствовать строки:
которые и вызывают соответствующий autodiscover().
С учётом этого всё стало довольно прозрачно и ясно и группировки вроде на месте, только вот в интерфейсе администрирования их не было у Джареда. Пришлось "форкнуть" проект и реализовать то, что необходимо.
Поставил в итоге ещё один плюсик гиту и понравился github. Правда в последнем обнаружилось пару багов: с коммитом, начинающимся с # он по ходу дела не дружит (в итоге пришлось делать merge из коммандной строки), да ещё на 1-м из флэшевых графов мой Firefox просто "схлопнулся". А в целом очень удобно - возьму себе на вооружение.
P.S. Ещё для настроек есть какое-то решение от авторов Satchmo, но смотреть его как-то было уже лень, когда было получено практически рабочее решение.
from appsettings import app
settings = app.settings.your_app
которые и вызывают соответствующий autodiscover().
С учётом этого всё стало довольно прозрачно и ясно и группировки вроде на месте, только вот в интерфейсе администрирования их не было у Джареда. Пришлось "форкнуть" проект и реализовать то, что необходимо.
Поставил в итоге ещё один плюсик гиту и понравился github. Правда в последнем обнаружилось пару багов: с коммитом, начинающимся с # он по ходу дела не дружит (в итоге пришлось делать merge из коммандной строки), да ещё на 1-м из флэшевых графов мой Firefox просто "схлопнулся". А в целом очень удобно - возьму себе на вооружение.
P.S. Ещё для настроек есть какое-то решение от авторов Satchmo, но смотреть его как-то было уже лень, когда было получено практически рабочее решение.
вторник, 23 марта 2010 г.
Работать надо меньше...
Минут пятнадцать сидел и "тупил" по поводу того, почему Джанго не хочет переводить строчку, когда локализация к ней написана и скомпилирована. Оказалось, что надо было просто лишь перегрузить девсервер.
Кстати, по поводу локализации: в грядущей версии 1.2 появится новый флажок с говорящим за себя названием - USE_L10N.
Кстати, по поводу локализации: в грядущей версии 1.2 появится новый флажок с говорящим за себя названием - USE_L10N.
суббота, 20 марта 2010 г.
Разделяй и не властвуй?
Эксперименты показывают (в исходники самой Джанго пока не залезал толком), что Django Template Language имеет один не совсем неочевидный ньюанс: переменные, которые устанавливаются с помощью templatetag'ов в блоках, не "шарятся" между разными блоками. В итоге получается, что их надо устанавливать переменные заново в каждом из блоков, т.е. получаем как минимум лишний вызов, и возможно ещё и совершенно лишний запрос к базе.
Можно, конечно, результаты запроса кэшировать, если есть необходимось, но всё равно дублирование остаётся. С другой стороны, безусловно, установка переменных из шаблона не есть правильный подход, всё должно быть установлено по возможности на уровне view или в middleware. Но вот данные нужны на уровне именно самого шаблона, view находятся, в ныеншнем случае, в django CMS, а шаблоны могут туда передаваться разные, данные же эти нужны лишь в одном из них.
Получается или я что-то реально недопонимаю или всё выглядит немного некрасиво.
Можно, конечно, результаты запроса кэшировать, если есть необходимось, но всё равно дублирование остаётся. С другой стороны, безусловно, установка переменных из шаблона не есть правильный подход, всё должно быть установлено по возможности на уровне view или в middleware. Но вот данные нужны на уровне именно самого шаблона, view находятся, в ныеншнем случае, в django CMS, а шаблоны могут туда передаваться разные, данные же эти нужны лишь в одном из них.
Получается или я что-то реально недопонимаю или всё выглядит немного некрасиво.
четверг, 11 марта 2010 г.
Советская власть и русификация всей страны
Обнаружил тут вдруг, что, несмотря на довольно хорошую поддержку интернационализации в Джанго, с локализацией не всё так тривиально, как хотелось бы. По сути надо было решить очень простую задачу - выводить локализованные имена месяцев в архиве новостей (хотя кто знает, что там дальше понадобится ещё). Есть, конечно, datetime.strftime, только вот он пляшет от текущей локали, которая задаётся на весь процесс и не управляется Джанго. В итоге поставил BabelDjango и использовал format_date(date, 'LLLL') оттуда.
пятница, 19 февраля 2010 г.
О django CMS
Планировали тут для одного проекта поднять Drupal, потому как основная задача там - CMS. После чтения доков и исходников пришли к выводу, что даже руками на Джанго будет собрать сервер быстрее, плюс необходимые механизмы интеграции требуют достаточной гибкости. Готовые фичи "из коробки" - это, конечно, интересно, но хочется иметь возможность манёвра. Ну и примеры кода под друпал, в котором на прямую запросы к таблицам самого друпала делаются, как минимум, смутили. Хотя, безусловно, нехилое сообщество пользвателей и большое число инсталляций может является некоторым плюсом. Но по-моему гораздо удобнее пользоваться инструментом, для которого понимаешь, как он работает, и представляешь варианты того, что надо сделать для реализации нового функционала. Поэтому родилось по-моему логичное решение: в топку PHP.
Писать совсем с нуля CMS было бы несколько грустно, а для джанго они уже есть. Правда, не так чтоб их было огромное количество, да и по поводу распространённости/фичам ситуация не так чтоб совсем идеальная, но варианты имеются.
По следам статьи "Picking a Django powered CMS" в первую очередь взгляд упал на FeinCMS. Вещь в целом вроде неплохая, но всёже по принципу оно больше похоже на то, что называют (пхпшники в основном) CMF, т.е. компоненты надо ещё подгонять нужным образом, чтобы получить саму CMS. Плюс ещё вылез какое-то исключение при создании перевода страницы, причина которого сходу была неясна.
Это заставило всплыть в памяти мысли о django CMS. Поставил, настроил, "натянул" дизайн, посоздавал странички и контент для них и оно мне реально понравилось. Возможно пока я ещё не обнаружил проблемных мест, но на данный момент считаю django CMS довольно хорошим проектом, довольно гибким и удобным. Немного, правда, смущает число тикетов по системе, но реальных шоу-стопперов я не обнаружил.
Надеюсь, что за не очень большое время проект удастся довести до ума и заменить старую неуклюжую пхп-версию на джанговскую, которую можно будет легко и непринуждённо расширять и модифицировать, ну и, надеюсь, что django CMS в этом поможет.
P.S. Рекомендую ещё по этому поводу статью "Друпал или Джанго".
Писать совсем с нуля CMS было бы несколько грустно, а для джанго они уже есть. Правда, не так чтоб их было огромное количество, да и по поводу распространённости/фичам ситуация не так чтоб совсем идеальная, но варианты имеются.
По следам статьи "Picking a Django powered CMS" в первую очередь взгляд упал на FeinCMS. Вещь в целом вроде неплохая, но всёже по принципу оно больше похоже на то, что называют (пхпшники в основном) CMF, т.е. компоненты надо ещё подгонять нужным образом, чтобы получить саму CMS. Плюс ещё вылез какое-то исключение при создании перевода страницы, причина которого сходу была неясна.
Это заставило всплыть в памяти мысли о django CMS. Поставил, настроил, "натянул" дизайн, посоздавал странички и контент для них и оно мне реально понравилось. Возможно пока я ещё не обнаружил проблемных мест, но на данный момент считаю django CMS довольно хорошим проектом, довольно гибким и удобным. Немного, правда, смущает число тикетов по системе, но реальных шоу-стопперов я не обнаружил.
Надеюсь, что за не очень большое время проект удастся довести до ума и заменить старую неуклюжую пхп-версию на джанговскую, которую можно будет легко и непринуждённо расширять и модифицировать, ну и, надеюсь, что django CMS в этом поможет.
P.S. Рекомендую ещё по этому поводу статью "Друпал или Джанго".
Очередная находка ньюба
Оказывается, что приложение Джанго не может совпадать по имени с именем проекта, причём проявилость это у меня довольно хитрым способом. Дело в том, что понадобилось мне забацать свой templatetag, создал приложение (с совпадающим именем), а Джанга ругается. Чуть потыркался, остановил девелоперский сервер, пытаюсь запустить runserver_plus из django-command-extensions, а оно мне отвечает: "Не, чувак, нет у тебя этих расширенных комманд, погляди в комманду хелп, убедись". Нормальный же runserver запускается и работает, только вот templatetag, конечно же не находит.
В целом, ещё один урок на тему, что с именами в Питоне надо быть чуть аккуратным.
P.S. И абсолютный импорт тут ничем не поможет.
В целом, ещё один урок на тему, что с именами в Питоне надо быть чуть аккуратным.
P.S. И абсолютный импорт тут ничем не поможет.
понедельник, 15 февраля 2010 г.
И что они нашли в django-pagination?
Куча джангописателей (наприме, включая авторов 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 ужасно хреново работает с угловыми скобками, сил нет.
<<previous 1 2 ... 5 6 7 8 ... 20 21 next>>
Сразу обращает на себя асимметрия результата, плюс ещё в начале и в конце много страниц отображается.
По-моему гораздо симпатичней (и даже чуточку логичней) вариант
< Prev 1 ... 5 6 7 8 9 ... 21 Next >
вот отсюда.
P.S. А blogger ужасно хреново работает с угловыми скобками, сил нет.
суббота, 13 февраля 2010 г.
Все аналогии ложны.
Размышляя над разницей между подходами и приёмами прниятыми на PHP и в python (в основном я рассматриваю Django, т.к. с другими фреймворками я не очень хорошо знаком), всё чаще в голову приходит аналогия с противопоставлением Windows и Linux. В PHP в основном всё уже готово "из коробки" и та же поддержка апачем особых плясок с конфигами не требует, тогда как с тем же Django приходится разобраться с процессом развёртывания, да и вариантов там сразу целая пачка (если не больше). Ну и самый большой аргумент, на мой взгляд, это модульность и гибкость, которая позволяет на линуксе, джанге достичь больших результатов, но в итоге требует больших усилий головного мозга (как говорят "если в линуксе можно настраивать программу, то вам, скорее всего, её придётся настраивать"). А модульность эта не может строиться без достаточной стройности идеологии и структуры системы (не могу не привести ссылку на свой прошлый пост про reusable apps).
пятница, 5 февраля 2010 г.
Зависимости, зависимости...
У товарища тут вышла проблема с разворачиванием приложеньица на джанге. Вроде всё сделано нормально, но выдаёт, хоть ты тресни, ошибку импорта, аля "не могу импортировать 'test.settings'", но файл-то лежит рядом и из питона нормально импортируется. Битый час придумывал, откуда могут ноги у этой проблемы расти. Оказалось всё тривиально - в поставке питона идёт модуль test, поэтому возник конфликт пакетов.
Так что называйте папки (и пакеты) внятно!
Так что называйте папки (и пакеты) внятно!
понедельник, 18 января 2010 г.
Спасибо русским программистам!
Предыдущая война с mod_wsgi закончилась в итоге тем, что Apache был "спрятан" за проксирующий nginx, что решило проблему с "залипающими" запросами. Заодно и статике теперь должна оптимальней отдаваться.
Думал было использовать ещё Nginx upload module, написал даже нужный код (т.к. данные в итоге приходят немного иначе). Однако, по запарке забыл код обновить, а в результате обнаружилось, что оно и без этого замечательно работает. Поэтому оставил пока тот вариант "на всякий пожарный". Хотя толком не помешало бы тесты сделать, чтоб понять, даст ли оно какую-либо разницу.
В любом случае nginx рулит, спасибо Игорю Сысоеву.
Думал было использовать ещё Nginx upload module, написал даже нужный код (т.к. данные в итоге приходят немного иначе). Однако, по запарке забыл код обновить, а в результате обнаружилось, что оно и без этого замечательно работает. Поэтому оставил пока тот вариант "на всякий пожарный". Хотя толком не помешало бы тесты сделать, чтоб понять, даст ли оно какую-либо разницу.
В любом случае nginx рулит, спасибо Игорю Сысоеву.
среда, 6 января 2010 г.
WSGI...
Вот толи я неважный линуксовый админ, толи в связке CentOS+mod_wsgi что-то "нетак":
время от времени Apache "затыкается" и из внешних признаков обнаружились лишь записи с "Premature end of script headers:" для сайта на Django. Причём вчера такое поведение получилось повторить сделав touch одному из wsgi-скриптов, ошибки же повалились для другого сайта, откуда могут тут взяться "наведённые" проблемы совершенно непонятно.
Возможно, надо обновить mod_wsgi с 2.5 до 2.8, или вообще собрать по-нормальному другой сервер (и плюнуть на CentOS), но пока чуть поживём с непонятками.
время от времени Apache "затыкается" и из внешних признаков обнаружились лишь записи с "Premature end of script headers:" для сайта на Django. Причём вчера такое поведение получилось повторить сделав touch одному из wsgi-скриптов, ошибки же повалились для другого сайта, откуда могут тут взяться "наведённые" проблемы совершенно непонятно.
Возможно, надо обновить mod_wsgi с 2.5 до 2.8, или вообще собрать по-нормальному другой сервер (и плюнуть на CentOS), но пока чуть поживём с непонятками.
вторник, 5 января 2010 г.
Django-chunks вроде бы совсем мелочь-мелочью, но для вставки всякой ерунды а-ля баннеры очень даже удобно.
Подписаться на:
Сообщения (Atom)
