4 октября 2010 г.

Django + GMail

Есть два пути для отправки email-сообщений из Django – через установленный на сервере Sendmail или Pistfix или с любого адреса через SMTP.

В случае, когда сервер не очень мощный и постоянное наличие в пямяти лишнего демона нежелательно, можно воспользоваться связкой с Gmail. Для этого нужно внести следующие изменения в файл settings.py вашего проекта:

    EMAIL_USE_TLS = True
EMAIL_HOST = 'smtp.gmail.com'
EMAIL_HOST_USER = 'youremail@gmail.com'
EMAIL_HOST_PASSWORD = 'yourpassword'
EMAIL_PORT = 587


Собственно, это все. Теперь при вызове функции EmailMessage ваши письма будут от отправляться через интерфейс Gmail.



Можно проверить это дело через консоль, запустив ее командой:




python manage.py shell




и введя команды:



>>> from django.core.mail import EmailMessage
>>> email = EmailMessage('Hello', 'World', to=['youremail@somewhere.com'])
>>> email.send()


Какие преимущества мы получим, используя такой подход? Вот такие:




  • - наши письма не попадут в спам (потому что мы используем реальные данные);


  • - мы не нагружаем  сервер запуском дополнительных программ.



Недостаток тоже есть. Время соединения с Gmail и авторизации для отправки письма значительно превышает время отправки письма через локальный почтовик.

3 октября 2010 г.

Боевой сервер под Django 2

Продолжение. Начало см. в статье Боевой сервер под Django.

В прошлый раз я занимался исключительно теоретическими изысканиями, но теперь настало время для практики. Приступим.

Я ставил себе систему Debian 5.0, потому что неплохо в ней разбираюсь и мне нравится ее несколько параноидальная политика – в репозитории присутствуют только суперпроверенные пакеты. Все примеры будут приведены именно для нее, но с некоторыми изменениями подойдут и для других Linux систем.

Еще одно предупреждение. Я работаю под рутом для администрирования сервера. Если вы поступаете не так, то добавляйте “sudo” перед вводом команд.

Итак, какое программное обеспечение нам понадобится на сервере?

Python.

Во-первых, естественно, сам интерпретатор Python. Как правило, по умолчанию он уже установлен, однако нужно проверить версию. Я использую для разработки Python 2.6, потому что он, как правило, присутствует в репозиториях всех современных систем, что позволяет ставить его из пакетов, а не собирать вручную.

Проверим версию Python:

root@myserver: ~# python
Python 2.6.6 (r266:84292, Sep 15 2010, 16:00:36)
[GCC 4.4.5 20100909 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>


В моем случае все нормально, можно набрать



>>> exit()


для выхода в командную строку.



Если нужно обновление (например, установлен Python ветки 2.5), вводим команду




root@myserver: ~# aptitude install python




Если обновления есть, будет предложено эти обновления автоматически скачать и установить.



Django Framework.



Предположим, интерпретатор Python установлен. Для запуска Django-проекта нам, естественно, понадобится и сам фреймворк. Производим следующие действия (текущая версия Джанго на сейчас – 1.2.3):




root@myserver: ~# wget http://www.djangoproject.com/download/1.2.3/tarball/



root@myserver: ~# tar xzvf Django-1.2.3.tar.gz



root@myserver: ~# cd Django-1.2.3



root@myserver: ~# python setup.py install




На моей установке Debian фреймворк установился в /usr/local/lib/python2.6/dist-packages/django. В вашей системе он может оказаться по другому пути, принципиального значения это не имеет. Чтобы найти, куда установился фреймворк, воспользуйтесь поиском:




find / -name django




Обязательно найдется.



Проверить правильность установки можно следующим образом:



root@myserver: ~# python   Python 2.6.6 (r266:84292, Sep 15 2010, 16:00:36) 
[GCC 4.4.5 20100909 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import django
>>> 


В моем случае все прошло отлично. Если же вы видите ошибку следующего вида:



>>> import django 
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named django
>>>


Значит, установка прошла неверно, модуль Django не найден. Попробуйте переустановить.



Итак, фреймворк установлен. Мы можем протестировать его работоспособность следующим образом:




root@myserver: ~# mkdir /home/djangotest



root@myserver: ~# cd /home/djangotest



root@myserver: ~# django-admin.py startproject mysite




Это все стандартные процедуры для старта нового проекта. Созданная структура впоследствии понадобится нам для тестирования работоспособности нашей среды.



Можно выполнить нашу любимую команду:




root@myserver:/home/djangotest/mysite# python manage.py runserver

Validating models...


0 errors found



Django version 1.2.3, using settings 'mysite.settings'

Development server is running at http://127.0.0.1:8000/


Quit the server with CONTROL-C.




Останавливаем сервер (CONTROL-C) и приступаем к установке остального ПО.



Снова немного теории.



Для запуска веб-приложения обычно требуются следующие компоненты:




  • - веб-сервер для отдачи продукта пользователю;


  • - сервер СУБД для обслуживания данных;


  • - почтовый сервер для отсылки сообщений пользователям приложения.


  • Этими программами дело, конечно, не ограничиваете, но в первом приближении этого будет достаточно.



Некий потребительский стандарт предполагает набор Apache (веб-сервер) + MySQL (СУБД) +Sendmail/Postfix (почтовый сервер). Все это невероятно удобное и надежное, при этом страшно тяжёлое – наш скромный сервачок это все крутить не сможет.



Мы пойдем другим путем. В качестве веб-сервера мы будем использовать Lighttpd, наше Django-приложение будет работать как FastCGI, базу данных мы будем крутить на SQLite, а без почтового сервера и вовсе обойдемся – будем использовать Gmail через SMTP.



В следующей части установим и настроим Lighhtpd + FastCGI.


2 октября 2010 г.

Боевой сервер под Django

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

c:\> python manage.py runserver

Но вот приходит время для того, чтобы запустить ваш проект в Интернет.  Существует ряд виртуальных хостингов, которые предоставляют возможность запуска Python-приложений. Самые известные из них – Джино и Комтет.

Однако это не путь настоящего гика. Во-первых, каждый виртуальный хостинг имеет свои ограничения (например, предустановленная версия Django может отличаться от той, которую вы хотите использовать).

Путь настоящего веб-самурая – это, конечно, свой выделенный сервер. На крайний случай, можем обойтись и виртуальным сервером (VPS/VDS).

Единственным отчетливо видимым недостатком такого пути является, безусловно, цена. VPS, не говоря уже о выделенном сервере (дедике от англ. dedicated). Однако свободы, предоставляемые своим сервером, настолько широки, что стоят той разницы в цене, которая неизбежно возникнет.

Небольшая оговорка – если вы страшно далеки от администрирования Linux-систем и не желаете ничего про это знать, то все дальше написанное можно не читать. Воспользуйтесь каким-нибудь готовым решением.

Итак, каковы минимальные характеристики сервера для старта веб-приложения на Django? Зависит от двух вещей: настройки сервера и нагрузки на приложение (количество посещений ресурса).

Приведу более конкретный пример. Была разработана CRM, отслеживающая оборот неких объектов, являющихся основной продукцией компании. Поскольку никакого сервера у компании нет, как нет желания иметь персонал для его поддержки, решили вынести приложение на VDS.

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

Я остановился на unmanaged VDS от VDSPlanet. Начал с самого дешевого тарифа, решив, что если будет необходимость, можно будет его повысить.

В следующий раз остановимся подробнее на наборе ПО, которое нам потребуется для запуска приложения.

Куда вставлять код Google Analytics?

Рекомендации разные. Кто-то утверждает, что вставлять код нужно перед закрывающим тегом </body>, чтобы не тормозить загрузку страницы. Кто-то. наоборот, рекомендует делать это перед закрывающим тегом </head>.

Ответ на этот вопрос дает нам документация от Гугла.

Современный код Google Analytics (GA) – асинхронный. На практике это означает, что код не будет тормозить загрузку страницы, а значит, можно помещать его выше, чем перед закрывающим тегом </body>.

- Отлично, – скажет пытливый читатель. - А что нам это даст? Зачем выше?

Если вы хотите просто смотреть, кто, когда и в каком количестве посещал ваш сайт/блог, то принципиального значения место размещения кода GA не имеет. Но как только вам нужно что-то большее, – например, трекинг событий или пользовательские переменные, – тут-то и пригодится наличие кода GA между тегами <head></head>.

Для того, чтобы отслеживать, например, клик по кнопке, вам нужно будет использовать следующий синтаксис:

<a href="#" onClick="_gaq.push(['_trackEvent', 'Videos', 
'Play', 'Baby\'s First Birthday']);"
>
Play</a>


Пример взят из документации.



Как видим, для трекинга события использована функция _gaq.push, которая как раз и является частью объекта _gaq, объявленного в коде GA. В случае, если бы объект был объявлен ниже, чем код отслеживания нашей ссылки, то отслеживание попросту не сработало бы.



Все вышеописанное не относится к “традиционному” коду GA. Если у вас именно тот, традиционный код, рекомендую перейти на новый, асинхронный. Есть подробные примеры миграции на новый код.



А как вы используете код Google Analytics?


1 октября 2010 г.

И снова ТемплейтМонстер

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

Кроме периодически выдаваемых на гора темплейтов, встречаются и другие полезные продукты жизнедеятельности этого гиганта. На днях была выложена бесплатная коллекция их 65 (!) бесплатных наборов иконок для разных соцсетей. Иконки для Блоггера, иконки для ЖЖ, иконки для RSS, иконки для Твиттера - да куча всяких разных иконок для сайта или блога. 

Чудотворная коллекция иконок находится в свободном доступе и ждет своего счастливого скачивателя.

Мне понравились сеты Free social vintage icons, Beer Cap Social Icons и еще пара. Думаю, куда бы их прикрутить.

А вам какие нравятся?