Позитив в преддверии НГ

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 и авторизации для отправки письма значительно превышает время отправки письма через локальный почтовик.

Боевой сервер под 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.

Боевой сервер под 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?

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

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

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

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

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

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

Звериный оскал капитализма, или прощай, Xmarks!

Как ни печально сознавать, что в современном мире все стоит денег, сознавать это приходится. Вот и очередной пример.

Все, кто обновил Xmarks до текущей версии, наверняка видели это печальное сообщение: "Sadly, Xmarks will be shutting down our free browser synchronization service on January 10, 2011." ("К сожалению, Xmarks остановит наш бесплатный сервис синхронизации браузеров 10 января 2011 года."). Причина объясняется в их блог-посте и тошнотворно проста - нет денег на продолжение.

Вот что написано у них под заголовком "The end" (перевод авторский, то есть мой):

Весной 2010, когда  деньги начали кончаться, а обстоятелства все ухудшались, мы начали искать потенциального покупателя нашей компании. Три месяца мы были удивительно близки к тому, чтобы совершить сделку, но покупатель попросту струсил. Тогда мы решили переориентировать Xmarks на бизнес-потребителя, но и эти планы беспощадно разрушились: с учетом встроенных функций синхронизации в Мозилле и Гуглхроме, трудно было представить пользователей, готовых платить за то, что они и так имеют даром. Четыре года мы предоставляли сервис синхронизации, не взимая за это плату, в надежде на то, что бизнес-модель для бесплатного сервиса как-нибудь появится. Поскольку все вложения не оправдались, мы больше не в состоянии нести расходы, в первую очередь - платить зарплату и оплачивать хостинг. Не имея соответствующих ресурсов, мы вынуждены остановить сервис. В наши планы входит поддержка работоспособности ближайшие 90  дней, а потом вытащим затычку и сольемся.

( ... благодарственные слова и немного статистики... )

Выражаясь словами Дугласа Адамса: "Вот и все. И спасибо за рыбу."

Там есть еще разделы "Начало" и "Середина", тоже небезынтересное чтиво. Англочитающие - велкам на первоисточник.

Для тех, кто не разделяет моего сожаления относительно конца Xmarks, поясню. Это, по моему глубокому убеждению, могут быть только люди, которые вообще не в курсе, что это за продукт. Вот фичи этого продукта:

• - Прозрачная (т.е. буз участия пользователя) синхронизация закладок. Все, что нужно - установить соответствующий плагин для поддерживаемого браузера (IE, Chrome, Mozilla Firefox, Safari) и зарегистрироваться на сервисе. Ну или ввести логин/пароль, если уже зарегистрировались. Теперь закладки будут синхронизироваться, причем кроссбраузерно, при добавлении новых закладок и при закрытии окна браузера.
• - Для Мозиллы и Хрома предусмотрена синхронизация открытых вкладок (sic!) и сохраненных паролей.

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

Я буду пользоваться этим супер (over 9000 super) сервисом столько, сколько он просуществует. Искренне верю в благополучный исход.

И последнее. Апдейт к записи гласит: 

Мы открыли страничку на сервисе Pledgebank. Вы можете там зарегистрироваться,  если  готовы платить хотя бы 10 баксов в год за Xmarks. Кредитка не нужна, просто пообещайте, что в принципе хотите и сможете заплатить. 

Я пообещал. А вы?

Подвал (footer) сайта

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

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

Существует веб-дизайнерский миф о том, что посетители не прокручивают страницы. Это миф существует с с середины 1990-х, когда посетители действительно не желали прокручивать веб-страницы. Сейчас же мы живем в эпоху, когда скроллинг становится неотъемлемой частью веб-серфинга. Представьте ситуацию: посетитель прокручивает сайт до самого низа, и что дальше? Вариант А. Посетитель начинает скучать и покидает ваш сайт – не лучший расклад, не так ли?  Вариант Б – посетитель видит в “подвале” интересную ссылку или примечательную картинку, и решает еще поизучать ваш сайт. Футер, по сути – ваш последний шанс побудить серфера остаться на вашем сайте.

Как сделать футер привлекательным для посетителя?

• - сделайте навигационный блок, который улучшит юзабилити сайта;
• - добавьте контактную информацию или даже форму обратной связи, чтобы сделать подвал более информативным;
• - не забудьте добавить инструменты для добавления в социальные сети – это отличная возможность получить фидбек и создать у посетителя ощущение вовлеченности;
• - заполните подвал интересным и уникальным контентом, и да – не забывайте его обновлять;
• - вы можете разместить там креативную рекламу, чтобы развлечь посетителя;
• - продублируйте в футере основные идеи вашего сайта;
• - используйте подвал как альтернативу боковой панели;
• - подвал большого размера с яркими границами привлечет внимание посетителя в десятки раз эффективнее, чем маленький текст, отодвинутый в самый конец веб-страницы;
• - используйте контрастное оформление, чтобы отделить подвал от других элементов;
• - оригинальные иллюстрации в футере могут стать серьезным аргументом в пользу вашего сайта;
• - сделайте кнопку “наверх”.

Перевод мой, очень вольный. Подробнее читайте в оригинальной статье. Там же приведены примеры, иллюстрирующие мысли, приведенные в статье. Мне понравился вот этот пример:

Резюмируя: надо попробовать. Гугл Аналитикс поможет оценить эффективность.

Про вариации на тему Твиттера

Как всякое заметное явление, появление Твиттера вызвало бурление сами знаете чего, но не только. Среди того, что не "оно", можно выделить Жуйк, он же Juick.com.

Жуйк, скажу я вам, это Твиттер, лишенный недостатков Твиттера. А именно отсутствует ограничение на длину поста, что дает возможность как минимум публиковать нормальные ссылки, не сокращенные всякими дурацкими сервисами вроде Бит.лы. Это первое.
Второе - это нормальная система комментариев. В Twitter вы отвечаете конкретному человеку, в Жуйке - на конкретный пост. Чем это лучше, и так понятно.
Третье - возможность постить через протокол Jabber прямо из вашего любимого клиента. Мой любимый Jabber-клиент запущен от 18 до 24 часов в сутки, так что мне это удобно. Кроме того, через тот же Жаббер-клиент можно и читать друзей и комментарии, эта информация просто приходит как сообщение через инстант-месседжер.
В общем, отличный ресурс. Ах да, еще одно преимущество - отсутствие спама. Ну почти. Сказывается заметно более низкая популярность в массах по сравнению с Твиттером.

Всех приглашаю. Вход через мою ленту.

Ну и специально для тех, кому особенно дорог Рунет. Наткнулся тут на просторах на rutvit.ru - почти полный аналог Твиттера. Те же 140 символов (кстати, а почему не 150?), те же фолловеры и т.п. В качестве бонуса имеется система оценки твитов.
У меня имеется акаунт на рутвите. Пока настроен на импорт данных с Твиттера, на случай, если кому-то удобно фолловить меня там.
Если вы знаете еще какие-то клоны Твиттера, пишите в комментариях, буду благодарен.

Про твиттер

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

Однако ситуация строго обратная. Не пользоваться Твиттером для сетевого жителя такое же некомильфо, как для жителя реального мира не использовать нижнего белья. И хотя Твиттер-ленту среднестатического сетевика читает едва ли больше посетителей, чем количество людей, имеющих доступ к обозрению нижнего белья порядочного гражданина, упоминания об этом сервисе обязательно присутствуют на всякой уважающей себя конференции, касающейся IT.
Вообще основное предназначение микроблогов (а именно этим термином обозначаются Twitter-ленты) - написать о том, что происходит с вами здесь и сейчас. Сесть и написать 140 символов гораздо проще, чем написать небольшой постинг символов на 1000 в нормальный блог. А значит, занятому человеку это удобнее.

Я мог бы сказать, что хотя 140 символов в 6,5 раз меньше 1000, а значит в 6,5 раз удобнее, именно этот факт делает общение через твиттер в 6,5 раз менее информативным и в 6.5 раз менее полезным. А отсутствие системы комментариев сводит полезность  общения через Твиттер на нет.
Остается именно тот функционал, на который микроблоги и рассчитаны - "я там-то и там-то, делаю то-то и то-то, и думаю сейчас о том-то и о том-то", и это всё. Но я этого не скажу.

У меня, конечно, тоже есть микроблог. Пишу я там по большей части всякую ерунду - как, я уверен, поступает 99% пользователей Твиттера. В эти же 99% входят и различные медийные лица - например, большой во всех отношениях человек Стивен Фрай (Stephen Fry). В своем микроблоге Стивен занимается тем же, чем и все мы - самопиаром, анонсом статей на своем официальном сайте и прочими делами той же тематики и того же разряда.
А вот то, чем занимается остальной процент, принято называть "спамом". В контексте современных методов продвижения бренда в целом это уже совсем не ругательное слово. Как говорится, без паблисити нет просперити, и Твиттер - один из инструментов достижения того самого паблисити.
Стоит упомянуть еще и о том, что с точки зрения продвижения (теперь уже не бренда в целом, а сайта компании в частности) размещение прямых ссылок на Твиттере имет смысл, поскольку они не закрыты ни "nofollow", ни "noindex", а значит, участвуют в формировании ссылочной массы. Правда, это большей частью относиться к Google и в меньшей степени к Яндексу, но все равно может быть полезно для продвиженца.
Резюмируя, скажу, что Twitter - уверенно вписавшаяся в современную реальность инструмент интерактивного пиара. Как средство общения, пожалуй, он слабоват, но этого от него никто и не требует. Пользоваться или нет - конечно, пользоваться. Возможно, когда у вас появятся стопиццот фолловеров и наступит тот самый черный день, кто-нибудь из тех, кому вы сообщите об этом в вашем собственном микроблоге, протянет вам руку помощи.

P.S. Естественно, хорошая идея порождает более одной реализации. На просторах Рунета давно уже существует Жуйк, лишенный массы недостатков Твиттера и имеющий массу достоинств. Но о нем в другой раз, тем более, что широкого распространения он не получил (а жаль!) и служит пристанищем разнообразных гиков.
А у вас есть микроблог на Twitter? Оставляйте ссылки в комментариях, зафолловимся!