Некоторым из вас, возможно, будет интересно узнать, что более 900 уникальных участников было задествовано в разработке Django, начиная с 1 января 2007 года. Данные основаны на логах SVN.
Должен заметить, что сообщество очень сильное, особенно в сравнеии с другими, широко известными проектами:

• Django: 906
• Pylons: 80
• PyPy: 240
• Linux Kernel: 4043
• PostgreSQL: 150
• Apache HTTP server: 118
• SQLAlchemy: 36
• Python: 428

Необходимо учесть, что все анонимные и гостевые коммиты считались за одного участника, если конечно проект позволял таковые.

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

Любая динамическая страница любого сайта содержит элементы типа «блок» и «основной контент».

Если коротко, то я предлагаю использовать «теги» для вывода блоков и логику view для вывода контента. Это позволит, например, закэшировать блок на уровне шаблонов не написав ни строчки python кода.

Ко всему прочему мы получаем максимально разбитую на составляющие систему.

Стоит учитывать так же, что в основном контенте тоже можно найти блоки и тоже вынести их в отдельные теги, за тем лишь уточнением, что в случае привязанности блока к данным из основного контента, эти данные необходимо прокинуть в тег. Можно воспользоваться context, но это не столь очевидно, как передавать параметры в тег напрямую.

В любом случае, это дело каждого, решать как делать правильно :)

P.S> Интересно было бы узнать как вы организуете проекты Django и с чем это связано

Сегодня, 29 июля, James Bennett опубликовал новость о том, что очередной milestone в чудесном фреймворке Django достигнут, вышла версия 1.1.
Из наиболее интересных изменений можно отметить

• ORM aggregation
• Query expressions
• URL namespaces

и много других разностей, которые можно найти в списке изменений.

• Список изменений
• Сам архив

James Bennett выпустил обновленную книгу по практическому применению Django. Версия фреймворка — 1.1, что радует. Цена книжки на Amazon.com составляет $29.69 за бумажную версию. Примеры кода выложены на bitbucket.org.

Когда мы делали Рисоваську, то сайту отвели не очень много внимания. «Простой, быстрый, „продающий“ нашего скачиваемого клиента» — такие требования получил dmalinovsky. В итоге сайт был написан на PHP с использованием авторского мини-фреймворка. Когда же Денис переключился на другие задачи, то стало понятно, что сайт никто не хочет расширять — не прикольно. На Эрланге писать — прикольно, на C++ — тоже прикольно (но после Эрланга конечно же все ворчали), на PHP — «не-не-не, я лучше на Эрланге попишу».

Меня это всё не устраивало, поэтому как только у меня выдалось время, я начал портирование сайта на технологии, поработать с которыми захочет каждый из нашей команды. Кандидатами были — Ruby on Rails и Django. Оба фреймворка — прекрасны! И самое главное — подходят по уровню инноваций, фана, красивого кода. Django я выбрал из-за языка — Python мне как-то сразу запал в душу.

Django. Разработка веб-приложений на Python

С помощью простой и надежной платформы Django, основанной на языке Python, можно создавать мощные веб-решения, написав всего несколько строк кода. Ее использование позволяет обеспечить высокую скорость и гибкость разработки, а также решать широкий спектр прикладных задач. Авторы, опытные разработчики, описывают все приемы, инструменты и концепции, которые необходимо знать, чтобы оптимально использовать Django 1.0, включая все основные особенности новой версии.
Это полное руководство начинается с введения в Python, затем подробно обсуждаются основные компоненты Django (модели, представления и шаблоны) и порядок организации взаимодействия между ними. Описываются методы разработки конкретных приложений: блог, фотогалерея, система управления содержимым, инструмент публикации фрагментов кода с подсветкой синтаксиса. После этого рассматриваются более сложные темы: расширение системы шаблонов, синдицирование, настройка приложения администрирования и тестирование веб-приложений. Авторы раскрывают разработчику секреты Django, давая подробные разъяснения и предоставляя большое количество примеров программного кода, сопровождая их построчным описанием и иллюстрациями.

На этой неделе в очередной раз столкнулся с проблемой «нестандартных» шрифтов, и если ранее можно было иногда обойтись самой обычной нарезкой в графическом редакторе или использовать какие-то клиентские приёмы подмены, то в этот раз задача стоит наиболее глобально. Динамических заголовков в надвигающемся проекте реально много.

Своими мыслями, поиском и конечным решением я и хотел бы поделиться с вами.

Преамбула

Из нескольких способов развертывания Django я сразу отмёл mod_python, потому что мне не хотелось поднимать тяжеловесный Apache. Решил развернуть на легком веб-сервере. На данный момент основных легковесных альтернатив Апачу две — lighttpd и nginx. Первоначально я выбрал первый, но столкнулся с проблемами, связанными с URL. Я подумал, что, может, nginx будет работать получше, и развернул приложение на нём. В этом деле мне очень сильно помог один скринкаст, уже не помню точно чьего авторства.
Всё было отлично, но когда я захотел использовать админку Django(удобная вещь, кстати), меня постигло разочарование — форма логина показывалась, но при попытке войти меня выбрасывало на admin. После получаса гугления, я нашёл топик на небезызвестном форуме Ивана Салагаева, в котором описывалось решение проблемы. После того, как я последовал описанным советам, все заработало на-ура. Представляю вашему вниманию необходимую конфигурацию сервера и Django.

В development version подобная функциональность вынесена в «интерфейс» и задокументирована, но сайт, для которого нужно было расширить функциональность интерфейса администратора постоен на Django 1.0, в котором этой возможности ещё нет…

а точнее использовать уже имеющиеся в Django (те что по-уполчанию есть в интерфейсе администрирования)…

Django Dash — соревнование для разработчиков на Джанге. Вам дается только 48 часов на разработку вебприложения! Отличный повод попробовать себя в скоростной разработке.

Правила

• Заготовки запрещены
• 48 часов
• Максимум 3 человека в комманде
• Можно использовать чужой код (не более 50 % от общего)
• Система управления версиями (Subversion) хостится у организаторов

Долго откладывал разобраться, так и релоадил апач целиком :)

@never_cache
def restart(request):
    ''' Перезапуск демона '''
    if request.META['mod_wsgi.process_group'] != '':
        import signal, os
        os.kill(os.getpid(), signal.SIGINT)
        ret = 'restarted'
    else:
        ret = 'not find porcess_group'
        
    return HttpResponse(ret, mimetype='text/plain')

UP: touch yourfile.wsgi

В предыдущей части мы начали бороться за память на 256 мегабайтном слайсе «на скорую руку». Результат был, но не столь эффектный как тот которого я добился на этот раз.

Я всегда догадывался, что причина всех моих неприятностей — apache. И чем больше я пытался его настраивать, тем больше в этом убеждался. Вывод? Попробовать заменить. Одно но — переход должен быть как можно более плавным, поскольку речь, ясно дело, о продакшене.

Поскольку у меня был опыт общения с nginx, а если быть точным — опыт с проксированием, то был выбран именно этот веб-сервер. К тому же у него хорошие параметры производительности.

Какое-то время назад потребовалось перенести проекты с выделенного сервера на VPS. Для этих целей был выбран slicehost. В общем и целом контора нравится и готов её рекомендовать всем.

Случилась лишь одна проблема: начали приходить уведомления о слишком сильном использовании диска (чтение/запись). Долгое время проблема не находила решения из-за отсутствия времени, но это вылилось в непонятные отказы, сопровождавшиеся статистикой в >200% CPU usage. После долгих извращений, была найдена проблема, а затем и её решение.

Новичкам в Django будет полезно узнать об очень полезном инструменте отладки — debug-toolbar. Он настолько крут, что его называют Firebug for Django. На больших проектах без него (или другого отладчика) не обойтись.

Готовые решения по редактированию контактов в ldap я не нашел. И Решил написать свой веб-интерфейс ldap адресной книги, получилось простое django приложение, как раз такое, чтоб секретарь не запутался))

Однажды появилась необходимость выбрать шаблонизатор для использования с Django. На одном встроенном решении останавливаться я не хотел, а провел небольшое исследование производительности и удобства использования разных продуктов.

На данный момент я выбрал Cheetah. Вот почему:

Я совсем недавно начал работать с Django и меня практически сразу же взбесила ущербная команда syncdb, которая ничего толком не синхронизирует, умеет лишь создавать таблицы для новых моделей.

А добавление или удаление полей в уже существующие модели превращается в настоящий pain in ass — приходится «подсматривать» за тем, как ORM создала бы таблицы заново (manage.py sqlall) и вручную делать ALTER TABLE для изменившихся столбцов таблиц.

То есть, ORM в Django так или иначе предполагает активный трах с SQL shell, потому что в процессе прототипирования эти поля в моделях изменяются просто пачками.

Началось всё с того что надо было часто создавать однотипные формы и сохранять введённые данные в базу. По суте форма всегда одна и та же — «Заявка на регистрацию» — но в зависимости от мероприятия поля в ней разные.

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

Сия заметка, плод трудов хабра-человека sevenov, ему и почёт, дабы в будущем ему хватило кармы оставить свой след на хабре самому ;)

~~~~

Сегодня возник вопрос о том, как сделать вот так:



После получасового гугления наткнулся на несколько тикетов на code.djangoproject.com (ссылок сейчас не подкину, в истории искать лень). В общем, суть их в том, что нужно переписать чуть ли не половину Django. Немного подумав, я реализовал по своему. Возможно это кто-то уже делал, но на решение я не наткнулся.