Django *

Как известно, в 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. Собственно о чем далее и пойдет речь.

Веб-cервис (англ. web service) — идентифицируемая веб-адресом программная система со стандартизированными интерфейсами. Веб-службы могут взаимодействовать друг с другом и со сторонними приложениями посредством сообщений, основанных на определённых протоколах (XML, JSON и т. д.). Веб-служба является единицей модульности при использовании сервис-ориентированной архитектуры приложения.

Одним из подходов создания веб сервиса является rest.
Rest (сокр. англ. Representational State Transfer, «передача состояния представления») — стиль построения архитектуры распределенного приложения. Данные в REST должны передаваться в виде небольшого количества стандартных форматов (например HTML, XML, JSON). Сетевой протокол (как и HTTP) должен поддерживать кэширование, не должен зависеть от сетевого слоя, не должен сохранять информацию о состоянии между парами «запрос-ответ». Утверждается, что такой подход обеспечивает масштабируемость системы и позволяет ей эволюционировать с новыми требованиями.

Многие учебные пособия по разработке на Django раскрывают как быстро получить работающий отладочный сервер (python manage.py runserver), а вопрос развертывания в боевом режиме часто остается нераскрытым или освещаются далеко не самые простые и эффективные методы.
Ниже я расскажу о об одном из способов развернуть сайт на Django в боевом режиме, начиная от выбора хостинга, заканчивая развертыванием веб-сервера. Таким образом статья может быть полезна тем, кто освоил разработку на базе Django, но не имеет опыта развертывания серверов. Мой способ один из многих, но он достаточно прост, эффективен в работе и легок в поддержке. Используем VPS-хостинг, Ubuntu 10.04, nginx, gunicorn.

Version: 0.2

Возникла у меня потребность атомарного обновления в реальном времени страницы у некоторого количества пользователей в зависимости от действий других пользователей (не гербалайф чат). Понятное дело, можно всё выкинуть в помойку и, по-молодецки, запилить с нуля на tornado/twisted.web, но явно не самый продуктивный путь (да и я не мо́лодец ни разу) когда всё что надо — уже работает на Django и нужно всего-то чуть-чуть… Естественным образом, по сути своей, сюда просится WebSocket. И всё бы ничего но Django WSGI приложение, а этот стандарт не предполагает таких выкрутасов даже близко (пока). Гугления интернетов навели, в очередной раз, на труд известного python-гуру kmike (это без сарказма, т.к. его работы выручали меня лично уже не однократно, за что нижайший ему поклон!).

Итак если вы хотите скрестить ваш Django проект с websocket посредством js библиотеки socket.io или sockjs — вилькоммен!

Думаю что большинство python программистов уже в какой-то степени знакомы с возможностями Celery. В 1-ой части я расскажу, как можно использовать RabbitMQ без celery, а во второй части — краткий обзор новых возможностей celery 3.0.
Об установке связки Django-Celery-RabbitMQ можно почитать тут.
Про использование RabbitMQ хорошо написано тут, и тут, ну и на сайте RabbitMQ.

Добрый день. Постараюсь рассказать о сложных формах в Django. Все началось, когда в моем дипломе понадобилось сделать форму, которая состояла бы из других форм. Ведь если у вас есть две формы, которые вы используете, и тут понадобилась другая, которая является просто контейнером тех двух, вы же не будете создавать новую, копируя в неё все поля из старых, это очень тупо. Поэтому надо как-то их объединить. В свое время было FormWizard в Django, но он был крайне не удобным так что в новой версии её переделали на WizardView. Django конечно MVC, но я в статье все как можно детально постараюсь продемонстрировать, а потом уже можно все сжать используя ModelForm и циклы в шаблонах.
Поглядим на наши модели, ничего особенного, но чтобы было понятней, продемонстрируем.

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

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

Итак, задача. Пользователи очень любят оставлять на сайтах свои телефоны и другую приватную информацию. Причем, делать это они хотят, не задумываясь о том, как правильно её ввести: 8(908)1271669 или, скажем, 908 127 16 69. Посетители сайта очень любят видеть правильные телефоны, желательно единообразно оформленные: (+7 495) 722-16-25, +7 968 127-31-32. Получается, нужно валидировать и хранить номера в нормализованном виде, то есть без оформления. В поле, про которое я буду рассказывать, можно ввести больше одного номера телефона. Формат хранения определим как последовательности из 11 цифр, разделенные пробелом.

Pudb — полноэкранный консольный дебагер с графическим интерфейсом. Большим плюсом является то, что в нем есть подсветка синтаксиса, дополнительные панели вывода информации, горячии клавиши и интерграция с IPython.

pdb, в сравнении с Pubd, показался жутно не удобным и ограниченым. Поиск ошибок стал занимать на много меньше времени и приносить больше удовольствия. При первом взгляде на него вспоминался Assembler и Turbo Pascal в студенческие годы в техникуме.

Если кто заинтересовался примеры установки и использования под катом.

Хорошо, когда при разработке проекта под django, разработчики проекта изначально озаботились его интернационализацией.

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

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

Итак, еще один способ запуска Django. Но зачем? Ведь уже каких только способов запуска нет. Казалось бы на любой вкус. Обоснование и описание — под катом.

Через шесть лет после появления тикета с предложением возможности использования своей модели вместо штатной django.contrib.auth.models.User и тысяч постов с идеями использования дополнительной модели профилей случилось чудо: https://github.com/django/django/commit/70a0de37d132e5f1514fb939875f69649f103124

Даже находясь частично на проходящем сейчас в Вашингтоне DjangoCon'е (а может и благодаря этому) мы смогли таки выпустить сегодня большое обновление самой мощной среды разработки для Python & Django — PyCharm 2.6.

С прошлого релиза в апреле мы сделали следующее: