Django *

Преимущества облачного хостинга в наше время объяснять не приходиться, а Red Hat предлагает нам ещё и опробовать все вкусности бесплатно (естественно с некоторыми ограничениями).
Вы не платите за хостинг и получаете?

• 1 Gb дискового пространства
• возможность создать 3 приложения
• поддержку php 5.3, Ruby 1.9, Node.js 0.6, Perl 5.10, python 2.6 (3.3), Zend Server 5.6 и это ещё не полный список.

Ну а если необходимого языка не нашлось можно создать Do-It-Yourself приложение и настроить его как душе угодно.

Мы же рассмотрим развёртывание Django приложения.

Привет, хабр!
Я очень большой фанат фреймворка Django и все свои проекты пишу исключительно на нем. Сегодня я расскажу о том, как расширить стандартную библиотеку полей формы собственным оригинальным решением. Задача статьи не в том чтобы предложить готовое решение, а в том, чтобы осветить технологию создания кастомных полей.
Небольшое отступление. Однажды я корпел над созданием базы знаний для компании, в которой в то время работал. База представляла собой набор статей, помеченных тегами. К элементу ввода тегов предъявлялись следующие требования:

• Множественный ввод
• Автодополнение вводимого тега
• Теги могут содержать пробелы (состоять из нескольких слов)
• Возможность создать новый тег, а не выбрать из списка

После недолгих поисков, я нашел jQuery-плагин Tag-It!, который полностью удовлетворял требованиям к виджету. Осталось только прикрутить это поле к Django.

Доброго времени суток, уважаемые хабровчане! Недавно я заинтересовался Python и, в частности, веб-фреймворком Django. После ознакомления с основными возможностями захотелось найти бесплатный хостинг с поддержкой Django. Каюсь, в тот момент напрочь забыл про GAE, но, почитав вчера про оный, понял, что выбор получился ничуть не хуже. Итак, встречайте, AppFog! (осторожно, под катом картинки!)

Написано, т.к. возник очередной холивар в комментариях на тему SQL vs ORM в High-Load Project (HL)

Преамбула

В заметке Вы сможете найти, местами, банальные вещи. Большая часть из них доступна в документации, но человек современный часто любит хватать все поверхностно. Да и у многих просто не было возможности опробовать себя в HL проектах.
Читая статью, помните:

• Никогда нельзя реализовать HL-проект на основе только одной манипуляции с ORM
• Никогда не складывайте сложные вещи на плечи БД. Она нужна Вам чтобы хранить инфу, а не считать факториалы!
• Если вы не можете реализовать интересующую Вас идею простыми средствами ORM — не используйте ORM для прямого решения задачи. И тем более не лезте в более низкий уровень, костыли сломаете. Найдите более элегантное решение.
• Извините за издевательски-юмористический тон статьи. По другому скучно :)
• Вся информация взята по мотивам Django версии 1.3.4
• Будьте проще!

И-и-и да, в статье будут показаны ошибки понимания ORM, с которыми я столкнулся за три с лишним года работы с Django.

Очень многие выбирают Django за его простоту. Код на Django прост и лаконичен, мы меньше думаем о костылях и больше о бизнес-логике.

Gevent тоже выбирают из-за того, что он простой, очень шустрый и не несёт за собой callback hell.

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

Заметил, что на Хабре никто не писал про отличный JavaScript шаблонизатор Swig.

JavaScript в поледнее время становится все более популярным и находит новые неожиданные сферы применения. Вот и меня не обошел этот тренд, так что при just-for-fun разработке одного проекта я не удержался и решил попробовать использовать JS одновременно на сервере (Node.JS), веб-клиенте (Backbone.js — все серьезно :) ) и в мобильном приложении (PhoneGap). Следующим шагом для меня стал выбор шаблонизатора, причем поддержка как node, так и браузера была обязательным критерием. До этого я имел дело в основном в Django Template Language, так что выбор пал на Swig.

Особенности Swig:

• Django Template подобный синтаксис
• Крайне высокая скорость работы (бенчмарки)
• Поддержка node.js и основных браузеров
• Совместимость с Express
• Открытый исходный код

В официальном блоге Django появилась информация о том, что планируется расширить функционал встроенной ORM миграциями — важным функционалом, который присутствует во многих современных ОРМ-ах, что называется «из коробки», например в рельсовом ActiveRecord или пхпшной Doctrine. Исторически сложилось, что этот функционал отсутствует в Django ORM.

На проходящем в Санта Кларе(США) PyCon 2013 была представлена бета версия нового сайта Python.org — preview.python.org.
Новая адаптивная версия сайта выглядит приятней и современней, навигация по сайту стала более удобной и понятной.

Последний раз дизайн сайта был обновлен в 2006 году. Хотя если смотреть глубже, структура сайта не менялась с конца 90-х.

Новый сайт сделан на платформе Django 1.5 (Python 3.3)

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

Vim — уникальный по своей гибкости редактор, который при должной настройке может едва ли не идеально удовлетворять все пожелания работающего с ним. Правда эта настройка может продолжаться месяцы, а то и годы, что является и достоинством, и недостатком vim’а. Существует множество статей и туториалов по использованию Vim для разработки на Python и Django, надеюсь мне удастся рассказать что-то новое. В своей статье я постараюсь по минимуму упоминать плагины общего назначения, вроде NERDTree или surround.vim и опишу несколько более специализированных расширений и настроек, которые существенно упростили процесс работы на Python.

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

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

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

Предисловие

Сразу хочу попросить прощения за столь перегруженную статью, но для меня сейчас всё это актуально и связано. Думаю что некоторым это может пригодиться для будущей разработки. Хочу обратить внимание, что в этой статье я не стану рассказывать вам как устанавливать те или иные тривиальные вещи, установка которых, к тому же, зависит от той или иной платформы. Также в статье я не описываю телодвижения по настройке прав доступа к файлам сервера, опять же, это зависит от реализации. В статье описан процесс настройки на PDC сервер с именем tci.lan, все имена сохранены, в вашем случае их следует заменить на соответствующие вам. Данная статья содержит код, для улучшения читаемости он спрятан в спойлерах.

Делая отладку производительности небольшого проекта, но с достаточно большой базой, столкнулся с неприятным спецэффектом.
Django при выборках с условиями по внешним ключам, связанным с проверкой на NULL, генерирует запросы, содержащие JOIN по каждому такому ключу.

Как известно, в Django предусмотрен очень лёгкий и простой механизм уведомления разработчиков о возникающих проблемах. Когда проект развёрнут на локальном компьютере и в настройках DEBUG имеет значение True, то отчёты об ошибках просто выводятся в виде HTTP-ответа, в виде удобной страницы с возможностью копирования traceback'а.

Если же это production-сервер, и DEBUG имеет значение False, то отчёты по умолчанию отправляются по электронной почте всем, кто указан в настройке ADMINS (кстати, если вы используете SMTP-сервер, то письма могут не приходить, так как SMTP-сервер не принимает адрес root@localhost — в этом случае просто укажите любой другой адрес, который будет принимать ваш SMTP-сервер, с помощью настройки SERVER_EMAIL).

Разумеется, ничего не мешает также написать свой logging handler (обработчик журналирования) и сохранять отчёты об ошибках в любом нужном виде — создавать задачу в баг-трекере, например.

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

Предыстория

Понадобилось мне добавить на сайт функцию поиска. Первой мыслью было — воспользоваться возможностями SQL-сервера, — но искать надо сразу по нескольким таблицам, слова и фразы, да ещё и со стеммингом. Понял, что изобретать свой велосипед будет накладно.

Решил поискать, а что же всё-таки есть из готовых решений? Оказалось, прямо скажем, не густо: django-haystack и django-sphinx. Ранее достоинства и недостатки обоих уже перечисляли, поэтому не буду повторяться.

Потратив какое-то время на чтение блогов и форумов, решил всё-таки попробовать django-sphinx, т. к. в django-haystack, насколько мне известно, с поддержкой Sphinx до сих пор не очень.

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

Вчера на официальном сайте Django появилось сообщение о доступности Django 1.5 Release Candidate.

Пара слов о нововведениях:

• Конфигурируемая модель User. Теперь можно использовать стандартную авторизацию, дополняя модель своими полями.
• Поддержка Python 3. Прекращение поддержки Python 2.5. Минимальная версия теперь — 2.6.5
• Задание конкретных полей при сохранении модели — параметр update_fields в Model.save()
• Кэширование связанных моделей
• Явное указание потокового ответа (класс StreamingHttpResponse)
• Тег {% verbatim %}, рендеринг внутри которого не происходит (удобно для javascript-шаблонов)

Скачать Django 1.5 RC

Доступные инструменты значительно упрощают разработку приложений для Windows Azure. При изложении материала предполагается, что пользователь не имеет опыта работы с Windows Azure. Выполнение всех шагов данного руководства позволит запустить приложение на основе Django в облаке.

Из этого руководства вы узнаете:

• Как создать базовое приложение Django.
• Как запускать и отлаживать приложения Django локально с помощью тестового сервера Django.
• Как запускать приложения Django локально в эмуляторе среды.
• Как публиковать и повторно публиковать приложение на платформе Windows Azure.

Следуя приведенным инструкциям, вы создадите простое веб-приложение Hello World. Приложение будет размещено в экземпляре веб-роли, которая размещается в выделенной виртуальной машине на платформе Windows Azure.

Когда разработчики требуют множество python и django различных версий на одном хосте на помощь приходит
virtualenv…

Но после этого доустанавливать дополнительные модули для каждого python приходится руками через pip

И тут возникают нюансы. Например с библиотекой PIL

Она прекрасно устанавливается, но при попытке работы с ней выдает вот такие великолепные сообщения об ошибках

decoder jpeg not available

Проблема в том, что при сборке PIL не может библиотеки для работы с jpeg, zlib, tiff, freetype, потому что в нашем случае они лежат в /usr/lib64, а в PIL написано искать только в /usr/local/lib

Недавно я запустил сайт backgrounddating.com и написал об этом здесь, на Хабрахабре. Разумеется, я уже тогда рассказал о некоторых технических деталях реализации этого проекта, но об одной из возможностей сайта я бы хотел написать отдельно, тем более, что документации (как на русском, так и на английском) на эту тему в Интернете пока что довольно мало. Итак, речь пойдёт о чате в реальном времени между двумя пользователями. Задача состоит в том, чтобы любой пользователь мог отправлять другим пользователям сообщения, и, если у получателя сообщения открыт чат с этим пользователям, то он сразу же видел входящие сообщения (а в ином случае он мог прочитать сообщения позже: то есть при открытии чата загружается история последних сообщений).

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

Сразу уточню, что это не единственный способ реализовать подобное. Вы можете использовать другой асинхронный веб-сервер (например node.js), можете использовать другую очередь сообщений (или вообще её не использовать, если вам подходят особенности такого варианта: с пользователями одного канала обязательно общается один и тот же worker веб-сервера). Я даже не утверждаю, что этот вариант самый лучший (но в данном случае он подошёл лучше всех). В конце концов, мы здесь вообще не будем рассматривать костыли (long polling, Flash) для старых браузеров (а это почти все версии IE, например), не поддерживающих веб-сокеты, и даже не будем рассматривать возможность подключаться из тех браузеров, которые уже поддерживают протокол WebSocket, но не стандартизированную версию (RFC 6455), а одну из устаревших. О том, как можно включить поддержку устаревшей версии «draft 76» (она же «hixie-76»), смотрите в документации Tornado.

— документо-ориентированная система управления базами данных (СУБД) с открытым исходным кодом, не требующая описания схемы таблиц. Написана на языке C++ и распространяется в рамках лицензии Creative Commons.

В последнее время становится довольно популярной и восстребованой. И вот возникла идея использовать ее в связке с фреймворком Django. Собственно о чем далее и пойдет речь.