klen.github.io

Измерение производительности популярных python web-фреймворков

2015-06-15T00:00:00+03:00

Содержание:

Участники тестирования
Методика тестирования
Результаты
Выводы

На праздниках решил протестировать популярные python фреймворки для web на производительность. В отличии от других тестов не стал сосредотачиваться на деплойменте, тестируя разнообразные связки uwsgi/gunicorn/chaussette/waitress/nginx и тд. Но на тестировании именно самих платформ. В частности меня интересовала «плата за асинхронность» — насколько набирающие популярность асинхронные фреймворки превосходят/уступают синхронным WSGI-решениям.

Участники тестирования

Note

Описания взяты с оригиналов

Aiohttp 0.16.3 -- Асинхронный фреймворк базирующийся на Asyncio;
Bottle 0.12.8 -- Быстрый, простой и легковесный WSGI микрофреймвок;
Django 1.8.2 -- Веб-фреймворк для перфекционистов с горящими сроками;
Falcon 0.3.0 -- Высоко-производительный фреймворк для построения облачных API;
Flask 0.10.1 -- Микрофреймворк базирующийся на Werkzeug, Jinja2 и хороших намерениях;
Muffin 0.0.88 -- Асинхронный фреймворк базирующийся на Asyncio и Aiohttp;
Pyramid 1.5.7 -- Небольшой, быстрый и понятный веб-фреймворк;
Tornado 4.2 -- Асинхронная сетевая библиотека и веб-фреймворк;

Методика тестирования

Тесты прогонялись на Amazon EC2 t2.medium сервере. Для создания нагрузки использовалась утилита WRK запущенная на том же сервере с параметрами:

wrk -d30s -t12 -c400 [URL]

Все приложения (кроме Tornado) запускались при помощи Gunicorn (2 процесса на каждое). Для синхронных WSGI библиотек использовался Meinheld worker.

Приложение на Tornado запускало 2 процесса, используя средства самого фреймворка.

Все тесты производились с использованием Python 3.4.

Каждое приложение тестировалось по трем основным сценариям:

JSON-тест -- закодировать небольшой объект в JSON и вернуть клиенту.
Remote-тест -- требуется загрузить ответ от другого сервера и вернуть его клиенту.
Complete-тест -- Используя ORM загрузить коллекцию объектов из базы, добавить к ней еще один и отрендерить список в шаблоне.

Первый сценарий это своеобразный «Hello World!» лишь несколько усложненный процессом кодирования в JSON, что практически не влияет на результаты. Показывает именно быстродействие в плане обработке HTTP-запросов.

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

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

В качестве базы данных использовался Postgresql с дефолтными настройками.

Исходники приложений можно найти на Github.

Результаты

Name	50% (ms)	75% (ms)	Avg (ms)	Req/s
Aiohttp	91.67	103.1	108.01	4093.41
Bottle	24.77	26.23	25.06	15761.45
Django	103.2	112.19	103.36	3696.90
Falcon	19.24	19.81	19.19	20677.13
Flask	64.32	71.59	65.68	6023.40
Muffin	108.07	115.09	171.56	3575.36
Pyramid	41.75	43.49	41.63	9402.69
Tornado	138.24	149.84	136.87	2829.72

В первом простом тесте с хорошим отрывом победили синхронные фреймворки. Не считая Django, но в оправдание последнего, можно сказать, что по-умолчанию этот фреймворк делает множество работы (middlewares by default). Асинхронные фреймворки делят места аутсайдеров и неожиданно для меня на последнем месте оказался Tornado. Очень хорошие результаты у Falcon и Bottle.

Name	50% (ms)	75% (ms)	Avg (ms)	Req/s	Timeouts
Aiohttp	358.08	369.08	338.94	1120.27
Bottle	3363.74	9911.84	6403.92	19.09	335
Django	3317.64	12954.23	6918.64	18.96	300
Falcon	3196.23	12976.84	6696.17	19.28	328
Flask	3306.88	11690.8	6824.88	19.16	363
Muffin	372.95	428.75	376.98	1019.76
Pyramid	3295.1	10518.92	6673.78	19.35	338
Tornado	1994.39	2069.25	1928.31	194.37

Для понимания результатов следующего теста необходимо пояснить, что приложения обращались к nginx настроенному на ответ с задержкой 100ms. Из-за этого результаты синхронных фреймворков очень близки, практически вся их работа после определенного момента сводилась к ожиданию. Опять неожиданные результаты от Tornado, я предполагал, что он будет близок к Aiohttp и Muffin. Но тем неменее Tornado в 10 раз эффективнее в этом кейсе чем ближайший синхронный фреймворк.

Name	50% (ms)	75% (ms)	Avg (ms)	Req/s	Non 2xx	Timeouts
Aiohttp	151.78	156.9	254.75	1004.82	68%	236
Bottle	613.5	630.17	1062.86	451.34		178
Django	1610.46	1976.44	2632.36	88.57		42
Falcon	766.75	805.35	1457.99	350.26		81
Flask	1032.63	1649.89	1465.25	222.78		496
Muffin	420.14	485.4	1552.7	819.62
Pyramid	562.44	601.49	812.43	248.42		235
Tornado	937.37	988.86	910.06	418.36

И последний тест. Результаты Aiohttp можно игнорировать тк к сожалению более двух третей запросов вернули 502 ошибки. На первом месте неожиданно, но приятно, оказался мой фреймворк Muffin достаточно быстро обрабатывающий этот тест. Django значительно проигрывает, лишь подтверждая медлительность стандартного движка шаблонов и ORM.

Выводы

Я предлагаю читателю сделать их самостоятельно. Данное тестирование производилось мой чтобы понять выгоду использования синхронных/асинхронных библиотек и показатели производительности популярных решений.

В дальнейшем планирую проводить данные измерения регулярно.

Graphite-beacon — простая система оповещений для Graphite

2014-10-30T00:00:00+03:00

Для мониторинга своих проектов я использую связку из Graphite + Grafana. Данные с серверов собирает Collectd, метрики приложений принимает Statsd.

Недавно в очередной раз поднимая эту инфраструктуру, я понял, что мне не хватает сигналов на основе данных метрик из Graphite. Например оповещения при падении свободной памяти ниже критического значения и тп.

Разумеется я не первый у кого возникла такая необходимость и существует ряд OpenSource приложений для данной задачи. Вот некоторые их них: Seyren, Cabot, graphite-pager, graphite-alerts. Вооружившись системой конфигурирования серверов я уже начал писать роли для развертывания одного из перечисленных решений, но через некоторое время осознал, что хочу сделать еще одно.

Итак, что же мне не понравилось?

Seyren — Java приложение (требует установленного MongoDB) при настройке возникли проблемы (я уже не помню какого рода) и я вернулся к другим вариантам.

Поддерживает множество типов оповещений: SMTP, Hubit, IRC, HipChat и прочее.

graphite-pager — Python-приложение (требует установленного Redis). При установке лично у меня возникли конфликты в python-зависимостях, в целом решаемые. Главная для меня проблема: нет поддержки SMTP.

graphite-alerts — Форк graphite-pager, как я понимаю добавлен веб-интерфейс для настройки. Также требует Redis, плюс судя по зависимостям БД для SQLAlchemy. Понятно, что можно использовать SQLLite, но тем не менее. Установка описана очень поверхностно и желания разбираться не вызывает. Плюс наследует от прародителя главный для меня недостаток: нет поддержки SMTP.

Cabot — Подозреваю самое мощное решение из перечисленных. Для установки предлагается использовать поставляемый с исходниками fabfile, требования и зависимости нигде не описаны. Судя по исходникам запускает Django + Gunicorn для веб-интерфейса и Celery для переодических задач. Хочет Postgres и Redis для базы данных и брокера соответственно.

Не понравился прежде всего мутной процедурой установки (в принципе все ясно), но могли бы и прямо написать. Но это не главное, прежде всего я не хочу запускать столько процессов чтобы иметь оповещения об изменении метрик из Graphite.

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

Поэтому на свет появился Graphite-beacon.

Это простое python-приложение не требуещее для работы базы данных или очереди задач. Работает на основе Tornado и написано в асинхронном стиле. На текущий момент для оповещений поддерживается SMTP и HipChat. При необходимости несложно добавить новые.

Конфигурируется «маяк» при помощи JSON файлов и имеет интуитивно понятный формат:

// Да здесь даже можно использовать комментарии
{
"graphite_url": "http://g.server.org",
"smtp": {
    "from": "beacon@server.org",
    "to": ["me@gmail.com"]
},
"alerts": [
    {   "name": "MEM",
        "format": "bytes",
        "query": "aliasByNode(sumSeriesWithWildcards(collectd.*.memory.{memory-free,memory-cached}, 3), 1)",
        "rules": ["critical: < 200MB", "warning: < 400MB"] },
    {   "name": "CPU",
        "format": "percent",
        "interval": "30m",
        "query": "aliasByNode(sumSeriesWithWildcards(collectd.*.cpu-*.cpu-user, 2), 1)",
        "rules": ["critical: >= 80%", "warning: >= 70%"] }
]}

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

Подробнее смотрите в описании Graphite-beacon.

Для Debian систем существует репозиторий с готовыми пакетами: http://dl.bintray.com/klen/deb

Возможно для вас этот простой инструмент будет также полезен как и для меня. Если у вас возникли вопросы, не стесняйтесь их задавать в комментариях.

Задачи на будущее:

Анализ аномальных пиков на метриках;
Прикручивание поддержки Hubot;
Веб-интерфейс, но зачем?

Mixer -- удобная генерация данных для тестирования

2013-06-17T00:00:00+04:00

Содержание:

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

Mixer — это удобная библиотека для генерации данных для тестов. Из коробки обладает поддержкой Django ORM, SQLAlchemy ORM, Mongoengine ODM и простым синтаксисом для интеграции любых бэкэндов. Работает в версиях python 2-х и 3-х версий.

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

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

Mixer предлагает второй способ. Вы получаете данные непосредственно в тестах, в любом необходимом количестве и не зависите от изменений в их структуре.

Пример работы

Несколько примеров для Django как для наиболее распространненного сейчас python-фреймворка.

Создадим стандартного пользователя используя django.contrib.auth.models.User.

from mixer.backend.django import mixer
from django.contrib.auth.models import User

user = mixer.blend(User)

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

По-умолчанию Mixer старается генерировать данные не только учитывая тип полей, но и анализируя их названия. Например при проверке примеров библиотека сгенерировала пользователя с логином mixcookie1957, адресом электронной почты: limb_candy@wordpress.br и именем: Robinson Wolverhampton. Но такое поведение разумеется можно отключить и получать абсолютно случайные данные.

Если вам нужно сгенерировать несколько объектов, имеется короткий синтаксис. Создадим еще 5 пользователей.

users = mixer.cycle(5).blend(User)

Зачастую возникает неоходимость предопределить некоторые значения генерируемого объекта. Синтаксис Mixer прост и интуитивно понятен. Создадим пользователя с логином testuser и группой admin.

from django.contrib.auth.models import User, Group

group = mixer.blend(Group, name='admin')
user = mixer.blend(User, username='testuser', groups=[group])

Но Mixer позволяет сделать это еще быстрее. Вышеприведенный код генерации можно заменить одной строчкой:

user = mixer.blend(User, username='testuser', groups__name='admin')

Синтаксис знаком пользователям Django, "__" позволяет указывать в фильтрации запросов, поля зависимых объектов. Так и в Mixer разделитель "__" позволяет предзадавать поля зависимых объектов не заботясь об их генерации. Использование может быть очень гибким.

messages = mixer.cycle(10).blend(
    Message,
    author__name='Duck Nukem',
    author__age='100',
    author__clan__title='crazy beaches',
)

По-умолчанию Mixer пропускает поля имеющие значение по умолчанию или позволяющие None значение. Вы всегда можете предзадать их вручную как в вышеприведенном примере или позволить Mixer сделать это за вас используя волшебный атрибут mixer.random.

class Product(models.Model):
    title = models.CharField(max_length=100)
    price = models.DecimalField(default=0)
    type = models.IntegerField(
        choices=((1, 'food'), (2, 'drinks')),
        null=True
    )

# Здесь price=0 и type=None
mixer.blend(Product)

# А здесь price это какой то decimal, а type равен `food` или `drinks`
mixer.blend(Product, price=mixer.random, type=mixer.random)

В качестве предзаданных данных Mixer поддерживает также функции и генераторы.

# Пример с функцией

def get_super():
    return "super"

mixer.blend(Superman, what=get_super)


# Пример с генератором

gen = (v for v in [10, 20, 30, 40, 50])
products = mixer.cycle(5).blend(Product, price=gen)

# Еще один
authors = mixer.cycle(10).blend(Author)
books = mixer.cycle(5).blend(Book, author=(a for a in authors))

Синтаксис для работы Flask, SQLAlchemy, Mongoengine схож и в данной статье рассматриваться не будет. Импортируете необходимый бэкэнд, указываете модель и получаете данные.

Продвинутое использование

Указание моделей через путь

Вам необязательно импортировать модели для генерации тестовых данных. Mixer способен сделать это за вас. Для Django достаточно указать строку вида: <имя_приложения>.<имя_модели>. Для других бэкэндов придется указать python путь для импорта. Пример из начала статьи можно изменить так:

user = mixer.blend('auth.user')

Другие волшебные атрибуты:

mixer.fake

Поведение mixer.fake похоже на mixer.random, но в отличии от последнего, генерирующего случайные данные, данный атрибут генерирует данные «фейковые данные» анализируя имя поля. Например для строкового поля login это будет строка имитирующая логин пользователя, а не просто случайный набор символов.

test = mixer.blend('app.message', content=mixer.fake)

Note

И mixer.random и mixer.fake позволяют принудительно указать тип генерируемого значения: mixer.random(int), mixer.fake(models.CharField)

mixer.select

mixer.select похож на mixer.fake и mixer.random, но работает с уже существующими данными. В приведенном ниже примере пользователю присваивается одна из существующих в базе данных групп.

user = mixer.blend('auth.user', groups=mixer.select)

mixer.select может принимать параметры фильтрации, например для Django:

user = mixer.blend('auth.user', groups=mixer.select(active=True))

mixer.mix

mixer.mix это волшебный атрибут указывающий на будущее сгенерированное значение. Например создадим пользователя с одинаковыми username и last_name.

user = mixer.blend('auth.user', username=mixer.mix.first_name)

Как мы помним mixer.mix указывает на объект который будет сгенерирован. Поэтому mixer.mix.first_name будет указывать на поле этого объекта и цель достигнута.

Использование mixer.mix может быть и более интересным.

ship = mixer.blend(
    Ship,
    captain__country = mixer.mix.region.country,
    title=mixer.mix.captain.nick
)

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

def get_username(user):
    return user.first_name.lower() + user.last_name.lower()

user = mixer.blend(
    username = mixer.mix(get_username)
)

mixer.sequence

Mixer, как уже указывалось, умеет принимать в качестве значений полей генераторы. mixer.sequence это помощник для создания генераторов из функций. Он принимает функцию от одного аргумента и на ее основе создает генератор.

Например несколько пользователей с логинами вида: 'test0', 'test1' и тд.

mixer.cycle(10).blend('auth.user', username=mixer.sequence(
    lambda c: 'test' + c
))

В функцию будет приходить счетчик итераций. Вышеприведенная операция встречается довольно часто, поэтому mixer.sequence поддерживает короткий синтаксис. При передачи строки он трансформирует ее в функцию: lambda c: value.format(c).

Результат кода аналогичен предыдущему.

mixer.cycle(10).blend('auth.user', username=mixer.sequence('test{0}'))

Преимущества по сравнению с другими библиотеками

Mixer поддерживает python второй и третьей версии.

Библиотека обладает интеграцией с Django ORM, SQLAlchemy ORM, Mongoengine ODM и легко расширяется для других бэкэндов. Независимо от проекта вы получаете единый интерфейс для генерации данных.

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

Mixer интуитивно понятен, гибок в настройке и прост.

Надеюсь с данным модулем генерация данных станет для вас легче и приятнее.

Ускорение python тестов. Конкурентный запуск.

2013-06-11T00:00:00+04:00

Содержание:

Nose
Unittest
- Django

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

Nose

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

"You can parallelize a test run across a configurable number of worker processes. While this can speed up CPU-bound test runs, it is mainly useful for IO-bound tests that spend most of their time waiting for data to arrive from someplace else and can benefit from parallelization."

—nose

Обычный запуск тестов выглядит так:

$ nosetests

Для использования конкуренции:

$ nosetests --processes=4

Unittest

Все хорошо, но как ускорить тесты если вы не используете nose? Задавшись этим вопросом я обнаружил модуль concurrencytest от Corey Goldberg. Он позволяет переопределить unittest.TestSuite для использования конкурентного запуска тестов.

Базовый пример использования:

from concurrencytest import ConcurrentTestSuite, fork_for_tests

# Здесь мы определяем unittest.TestSuite и unittest.TestRunner
suite = ...

# И обеспечиваем конкурентный запуск
concurrent_suite = ConcurrentTestSuite(suite, fork_for_tests())
runner.run(concurrent_suite)

Вот и все. Теперь тесты будут выполняться асинхронно.

Note

По умолчанию concurrencytest запускает форки по количеству ядер процессора вашей системы. Вы можете явно указать количество процессов при создании ConcurrentTestSuite задав аргумент для функции для fork_for_tests (fork_for_tests(8)).

Django

Приведу пример интеграции concurrencytest в Django проект. Нужно создать собственный TestRunner который переопределит создаваемую TestSuite. Пусть код проекта лежит в модуле main, создадим файл main/test_runner.py:

from concurrencytest import ConcurrentTestSuite, fork_for_tests
from django.test.simple import DjangoTestSuiteRunner


class DjangoConcurencyTestSuiteRunner(DjangoTestSuiteRunner):

    def build_suite(self, test_labels, extra_tests=None, **kwargs):
        suite = super(DjangoConcurencyTestSuiteRunner, self).build_suite(
            test_labels, extra_tests=extra_tests, **kwargs
        )

        concurrency_suite = ConcurrentTestSuite(suite, fork_for_tests())
        return concurrency_suite

Теперь осталось переопределить опцию TEST_RUNNER в настройках Django, указав путь импорта к нашему раннеру:

TEST_RUNNER = 'main.test_runner.DjangoConcurencyTestSuiteRunner'

Не забудьте добавить в ваше окружение зависимость от concurrencytest и обновить его.

Все, теперь запуск Django тестов будет автоматически использовать все присуствующие в системе ядра процессора. В моих проектах прирост скорости выполнения тестов составил от 35% до 60% процентов, на 4-х ядерном macbook pro.

Note

Кстати если вы используете tox для прогона тестов используя разные окружения, то для использования конкурентного запуска вам достаточно просто установить модуль detox и запускать tox-тесты с его помощью.

OSX - Программы которые я использую

2013-04-04T00:00:00+04:00

Содержание:

Джентльменский набор
XtraFinder
Xee
VLC
Transmission
AppTrap
Deegres
iTerm2
Face2Face
Заключение

Вот и настала моя очередь перейти на Mac. Уже некоторое время я использую Macbook Pro Retina и могу сказать, что доволен выбором на все 100%. Это именно его крышку вы можете наблюдать на картинке сверху.

Долгое время меня удерживали от перехода на технику Apple трудности установки и настройки серверного окружения для разработки. Я использовал debian системы и поднимал на своем рабочем ноутбуке такую же среду, что и на сервере. Kонечно, если постараться, многое можно настроить используя OSX. Но далеко не все так же просто. Потом я стал плотно работать с виртуализацией и гостевая система стала не такой критичной. Возможно я напишу об этом в следующих статьях, но в этой мне захотелось описать используемое мной программное обеспечение.

И так мой «must have» лист. Все программы и плагины представленные ниже, бесплатны на момент написания этого текста.

Джентльменский набор

Программное обеспечение которое в описании не нуждается: Skype, Chrome, Dropbox.

Ну и для OSX включу сюда же Adium и Homebrew (для разработчиков).

XtraFinder

После использования nautilus мне не хватало нескольких вещей в стандартном файловом менеджере OSX — Finder. В основном это касалось панельного режима.

Проблему решил бесплатный плагин Xtrafinder. Вкладки, панели, удобные кнопки, быстрое переключение отображения скрытых файлов и многое другое. Платные аналоги стоят до $50 и уступают в функциональности.

Xee

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

VLC

Удобный кроссплатформенный медиа-плеер. Практически комбайн, хотя я использую его исключительно для просмотра видео. Стандартный Quicktime не соперник для VLC.

Transmission

Торрент-качалка. Возможно и не лучший выбор, но опять же присутствует на всех платформах, что избавляет от модальности при переключении на другие OS.

Интерфейс Transmission не перегружен и оставляет приятное впечатление.

AppTrap

В 2013 году при удалении программ на OSX стандартными инструментами, в системе остаются неиспользуемые служебные файлы, обнаружить и очистить которые — задача нетривиальная. Apptrap — бесплатное решение для надежного удаления программ.

Deegres

Бесплатный виджет для меню-бара отображающий текущую погоду. В том или ином виде использую подобные решения на всех платформах. Deegres можно найти в AppStore.

iTerm2

Использую iTerm2 вместо стандартного терминала OSX. Вкладки, темы, полезные хоткеи, удобная работа с клипбордом, панельный режим.

Считаю его удобнее чем TotalTerminal.

Face2Face

Mail — стандартное приложение электронной почты в OSX. Для него существует немалое количество плагинов.

Face2Face ищет изображения отправителей писем используя такие сервисы как Gravatar, Facebook и прочие.

Заключение

Надеюсь вы нашли для себя что-нибудь полезное в этом списке.

PS: Разумеется здесь упомянуты не все используемые мной программы. Например я предпочитаю Picasa стандартному iPhoto. Из платных программ выделил бы: 1Password, CleanMyMac, Bookreader.

В заключении хочу спросить пользователей OSX: часто ли и в каких целях вы используете Dashboard? Все мои знакомые в лучшем случае держат там погоду и калькулятор, и практически не открывают его. После пары недель использования я осознал его бесполезность и полностью удалил из системы:

defaults write com.apple.dashboard mcx-disabled -boolean true
killall Dock
defaults write com.apple.dashboard mcx-disabled -boolean false

Pylama — аудит python-кода

2012-09-02T00:00:00+04:00

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

Во-втором случае код моих проектов автоматически прогоняется через ряд утилит: pyflakes, pep8, mccabe, pylint. Какое то время я использовал Flake8 сочетающую в себе все эти линтеры. Но потом его возможностей мне стало не хватать. Схожий функционал уже был мной разработан для python-mode, поэтому я вынес его в отдельный модуль. Так появился Pylama.

Pylama это утилита для проверки python-кода схожая с Flake8, но обладающая рядом улучшений.

Установка

$ pip install pylama

Использование

Рекурсивная проверка текущей диектории:

$ pylama

Игнорировать определенные типы (группы типов) ошибок:

$ pylama -i W,E501

Изменение набора линтеров:

$ pylama -l "pep8,mccabe"

Опции

$ pylama --help

usage: pylama [-h] [--ignore IGNORE] [--verbose] [--select SELECT]
            [--linters LINTERS] [--complexity COMPLEXITY] [--skip SKIP]
            [path]

Code audit tool for python.

positional arguments:
path                  Path on file or directory.

optional arguments:
-h, --help            show this help message and exit
--ignore IGNORE, -i IGNORE
                        Ignore errors and warnings.
--verbose, -v         Verbose mode.
--select SELECT, -s SELECT
                        Select errors and warnings.
--linters LINTERS, -l LINTERS
                        Select errors and warnings.
--complexity COMPLEXITY, -c COMPLEXITY
                        Set mccabe complexity.
--skip SKIP           Skip files (Ex. messages.py)

Переключение настроек pylama из файла

В любом python-файле вы можете установить опции проверки для pylama. Они будут установлены только для данного файла.

.. Где-то в коде
# Игнорировать все Warnings кроме W301
# lint_ignore=W:lint_select=W301

Для выключения проверки текущего файла:

# lint=0

Разработка pylama ведется на Github: http://github.com/klen/pylama

Pyradio — простой консольный радиоплеер

2012-09-01T00:00:00+04:00

Очень простой клиент для прослушивания онлайн-радиостанций. Ничего лишнего.

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

Я исправил ошибки, доработал консольный клиент и собрал пакет для PYPI. Теперь можно просто ввести:

sudo pip install pyradio
pyradio -p 15

Note

На самом деле вам еще понадобиться установленный mplayer.

И слушать музыку.

Неделя с Flask

2012-08-31T00:00:00+04:00

Содержание:

Flask-Foundation
Flask-Mixer
Flask-Collect
Заключение

Стал использовать Flask для небольших проектов. Django неимоверно разрослась, да и просто замылила глаз. В процессе работы родилось несколько полезных приложений.

Flask-Foundation

Я уже писал про open-source проекты на Flask с хорошим исходным кодом. Но как показывает практика, для быстрого старта их недостаточно.

Я собрал свою сборку: http://github.com/klen/Flask-Foundation базового проекта на Flask, содержащую следующие вещи:

Flask-Admin — администрирование;
Flask-Script — автоматизация;
Flask-Cache — кеширование;
Flask-Debugtoolbar — отладка;
Flask-Babel — локализация;
Flask-WTF — поддержка WTForms;
Flask-Bootstrap — стилизация;
Flask-Mail — почта;
Flask-SQLAlchemy — ORM, базы данных;
Flask-Testing — тестирование;
Alembic — миграции бд;

Проект содержит богатый функционал и может послужить хорошим примером для быстрого старта.

Flask-Mixer

Фабрика генерации объектов из SQLAlchemy моделей. Создавалась мной в целях тестирования, но может использоваться и в других случаях (пакетная генерация данных).

Адрес на Github: http://github.com/klen/Flask-Mixer

Примеры работы:

# Простая генерация модели
user1 = mixer.blend(User)
assert user1.id and user1.username and user1.created_at
assert user1.score == 50
assert user.profile.user == user

# Модель может быть задана строкой
role1 = mixer.blend('app.models.Role')
assert role1.user
assert role1.user_id == role1.user.id

# Генерация объекта с предопределенными значениями
user2 = mixer.blend(User, username='test')
assert user2.username == 'test'

# Это могут быть значения для референс-объектов
role1 = mixer.blend(Role, user__username='test2')
assert role2.user.username == 'test2'

# Значение может быть функцией
user = mixer.blend(User, username=lambda:'callable_value')
assert user.username == 'callable_value'

# Принудительная установка случайного значения для поля с default value
user = mixer.blend(User, score=mixer.random)
assert user.score != 50

# Установка случайного значения из базы данных
profiles = Profile.query.all()
user = mixer.blend(User, profile=mixer.random)
assert user.profile in profiles

Flask-Collect

Нехватку такого приложения я почувствовал при первом же деплое Flask-проекта. Как известно раздавать статичные файлы (css, js и тп) питоном в нашем бизнесе не комильфо. Обычно проксирующий WSGI веб-сервер отдает их из определенной папки напрямую. Для сборки таких файлов из приложений проекта в Django существует встроенное приложение.

Во Flask ничего подобного не нашлось. Есть инструкции в документации где рекомендовано отдавать статичные файлы веб-сервером, но нет ни слова о том как их собирать. Не найдя ничего на Pypi я написал свое.

Использование:

В коде:

app = Flask(__name__)
collect = Collect(app)
collect.collect(verbose=True)

или из консоли при использовании Flask-Script:

$ ./manage.py collect

Адрес на Github: http://github.com/klen/Flask-Collect

Заключение

В целом Flask мне нравится. Код чище, его меньше, работает быстрее. SQLAlchemy на голову уделывает на текущий момент Django ORM.

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

Полезности для GIT

2012-07-19T00:00:00+04:00

Алиас для более компактного git status:

$ git config --global alias.st 'status -sb'
$ git st

Алиас для редактирования последнего коммита:

$ git config --global alias.amend 'commit --amend -C HEAD'
$ git amend

Алиас для отмены последнего коммита:

$ git config --global alias.undo 'reset --soft HEAD^'
$ git undo

Предпочитаемый мной вывод diff:

$ git config --global alias.diff 'diff --word-diff'
$ git undo

«Визуальная» история веток в консоли:

$ git config --global alias.hist "log --pretty=format:'%Cred%h%Creset %ad | %Cgreen%s%d%Creset [%an]' --graph --date=short"

Удобная работа с Git-Flow:

$ git config --global alias.hotfix 'flow hotfix'
$ git config --global alias.feature 'flow feature'
$ git config --global alias.release 'flow release'

Автоматическая коррекция опечаток во вводимых командах:

$ git config --global help.autocorrect 1
$ git comit
$ git bronch

Автоматическая запись разрешенных мердж конфликтов, для будущего использования:

$ git config --global rerere.enabled 1

Получение веток с не влитыми данными:

$ git branch --no-merged

Список коммитов в ветке branchA отсуствующих в ветке branchB:

$ git log branchA ^branchB

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

# In your .bashrc or .profile:

    GIT_PS1_SHOWDIRTYSTATE=1
    GIT_PS1_SHOWSTASHSTATE=1

    $ (develop *$):

PyServe. Веб-сервер одной командой

2012-06-14T00:00:00+04:00

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

При установленном python это делается буквально в одну строку.

Для python версий 2.*:

$ python -m SimpleHTTPServer

Для python версий 3.*:

$ python -m http.server

Я часто пользовался этой функциональностью, например при отладке standalone HTML приложений работающих с удаленными API. В какой то момент мне захотелось большего:

Одинаковый синтаксис для python 2 и 3 версий;
Возможность отключения "автоиндекса" для директорий (игнорирование index.html);
Возможность указания IP-адреса сервера (шаринг в сети);
Возможность скрытия системных файлов;
Более приятный внешний вид при выводе каталога директории;
Возможность указания пути к директории (не только текущей);

Так появился пакет PyServe.

$ pip install pyserve

Пакет не содержит зависимостей, поддерживает всю вышеперечисленную функциональность и прост в установке. Теперь независимо от версии python вы можете запустить сервер одной командой:

$ serve

Создание python-пакетов (aka setup scripts)

2012-06-13T00:00:00+04:00

Содержание:

Создаем структуру проекта
Редактируем мета-информацию (setup.py)
Виртуальное окружение
Создание команд
Работа с версиями
Управление зависимостями
Управление файлами проекта (MANIFEST.in)
Создание и запуск тестов
Публикация пакета на pypi.python.org

Одна из действительно полезных вещей в python — это система скриптов установки. Любой, серьезно увлекающийся python-программированием разработчик рано или поздно сталкивается с ней. Но из-за гибкости инструментария скриптов установки, их документация весьма раздута. На текущий момент имеется набор утилит (setuptools, distutils, distribute) выполняющих одинаковые задачи.

В данной статье я на конкретных примерах покажу как создать и настроить простой python-пакет.

Наш проект будет иметь следующую функциональность:

Метод возвращающий строку: "Hello World!";
Команда helloworld печатающая эту строку в стандартный вывод.

Note

Исходные коды для данной статьи можно увидеть по адресу: https://github.com/klen/klen.github.com/tree/master/_code/helloworld-project

Создаем структуру проекта

Для начала создадим директорию для пакета. Ее минимальный набор файлов состоит из: файла дистрибьюции (setup.py) описывающего метаданные и python кода проекта (в нашем случае модуля helloworld).

Также, xорошим тоном считается создание в корне директории файла с описанием проекта: README.txt.

Получаем следующую структуру:

helloworld-project
├── helloworld
│   ├── __init__.py
│   └── core.py
├── setup.py
└── README.txt

Наша корневая директория helloworld-project будет содержать мета-данные пакета и вспомогательные файлы (тесты, лицензию, документацию и т.д.), а поддиректория helloworld непосредственно сам модуль helloworld.

Теперь отредактируем файл: helloworld/core.py и добавим логику нашего приложения (получение и вывод строки "Hello World!"):

def get_message():
    return "Hello World!"


def print_message():
    print get_message()

Редактируем мета-информацию (setup.py)

Заполним файл описания README.rst:

Description
===========

An example Hello World project.

Теперь отредактируем файл setup.py:

from setuptools import setup, find_packages
from os.path import join, dirname

setup(
    name='helloworld',
    version='1.0',
    packages=find_packages(),
    long_description=open(join(dirname(__file__), 'README.txt')).read(),
)

Note

Убедитесь, что в вашей системе доступны setuptools, в противном случае установите python-пакет distribute

Этих операций достаточно, чтобы собрать пакет дистрибьюции. Выполните команду сборки:

$ python setup.py sdist

В случае успеха вы получите файл: dist/helloworld-1.0.tar.gz. Это полноценный, архивированный python-пакет и вы можете распространять его среди прочих разработчиков.

Виртуальное окружение

Virtualenv — пакет применяемый для создания изолированного python-окружения. Используем его для тестирования нашего проекта.

Создадим окружение env:

$ virtualenv env

Команда создаст директорию env внутри нашего проекта и установит туда python, pip и distribute. Произведем в него установку нашего проекта.

$ ./env/bin/python setup.py install
running install
running bdist_egg
running egg_info
[...]
Processing dependencies for helloworld==1.0
Finished processing dependencies for helloworld==1.0

И протестируем его работоспособность:

$ ./env/bin/python
>>> import helloworld.core as hw
>>> hw.get_message()
'Hello World!'
>>> hw.print_message()
Hello World!

Все работает. Осталось добавить поддержку команды helloworld в консоли.

Создание команд

Для создания команды helloworld изменим файл setup.py:

setup(
    ...
    entry_points={
        'console_scripts':
            ['helloworld = helloworld.core:print_message']
        }
    )

В параметре entry_points мы задаем словарь с "точками вызова" нашего приложения. Ключ console_scripts задает список создаваемых исполняемых скриптов (в Windows это будут exe-файлы). В данном случае мы указали создание исполняемого скрипта helloworld при вызове которого будет запускаться метод print_message из модуля helloworld.core.

Переустановим модуль в наше окружение и проверим работу созданного скрипта (для этого прийдется активировать наше окружение):

$ ./env/bin/python setup.py install
$ source ./env/bin/activate
(env)
$ helloworld
Hello World!
(env)

Похоже все работает.

Работа с версиями

Номер версии важная часть любого проекта. От него зависит обновление пакетов и разрешение зависимостей. В примере выше мы указали номер версии 1.0 в файле setup.py. Более правильное решение перенести его в файл helloworld/__init__.py чтобы сделать доступным в python-коде. По существующим соглашения для хранения номера версии в модуле, используется переменная __version__.

helloworld/__init__.py`:

__version__ = '1.0'

Изменим файл setup.py, чтобы нам не приходилось редактировать номер версии в двух местах:

...
import helloworld

setup(
    name='helloworld',
    version=helloworld.__version__,
    ...

Существует множество систем наименования версий в python обычно рекомендуется использовать PEP386. Можно представить, что обозначение версии состоит из номера мажорного, минорного релизов (номера багфикса при необходимости), разделенных точками. В последней части версии разрешается использовать буквы латинского алфавита. Примеры из официальной документации:

0.4       0.4.0  (these two are equivalent)
0.4.1
0.5a1
0.5b3
0.5
0.9.6
1.0
1.0.4a3
1.0.4b1
1.0.4

Управление зависимостями

Добавим функциональности нашему проекту. Создадим команду serve которая будет запускать вебсервер отдающий страницу со строкой "Hello world!" генерируемой нашим модулем. Для этого воспользуемся пакетом Flask.

Добавляем файл helloworld/web.py:

from flask import Flask, render_template

from helloworld.core import get_message


app = Flask(__name__)


@app.route("/")
def hello():
    return render_template('index.html',
        message=get_message())


def run_server():
    app.run()

И файл helloworld/templates/index.html:

<!DOCTYPE HTML>
<body>{{message}}</body>

И опишем команду serve в файле setup.py:

...
entry_points={
   'console_scripts': [
       'helloworld = helloworld.core:print_message',
       'serve = helloworld.web:run_server',
       ]
   },
...

Теперь в нашем проекте появилась зависимость от пакета Flask. Без его установки наше приложение не будет правильно работать. За описание зависимостей в файле setup.py отвечает параметр install_requires:

...
install_requires=[
    'Flask==0.8'
]

Проверим установку зависимостей обновив наш пакет и работу команды serve:

$ ./env/bin/python setup.py develop
...
Processing dependencies for helloworld==0.1
Searching for Flask==0.8
...
$ serve
   * Running on http://127.0.0.1:5000/

Открыв браузер по адресу http://127.0.0.1:5000 вы должны увидеть нашу страницу.

Управление файлами проекта (MANIFEST.in)

На текущий момент при сборке нашего пакета distutils включает в него только python-файлы. Необходимо включить в него файл helloworld/templates/index.html без которого проект работать не будет.

Чтобы сделать это мы должны сообщить distutils какие еще файлы надо включать в наш проект. Один из способов — это создание файла MANIFEST.in:

recursive-include helloworld/templates *.html

Данная команда указывает distutils на включение в проект всех html файлов в директории helloworld/templates.

Также придется обновить setup.py:

...
setup(
    ...
    include_package_data=True,
    ...
    )

Теперь шаблоны будут включены в наш проект.

Создание и запуск тестов

Хорошей практикой считается создание тестов для вашего проекта. Добавим простейшую реализацию, файл tests.py:

from unittest import TestCase
from helloworld.core import get_message

class HelloworldTestCase(TestCase):
    def test_helloworld(self):
        self.assertEqual(get_message(), 'Hello World!')

И обновим setup.py:

...
setup(
    ...
    test_suite='tests',
    ...
    )

Теперь мы можем произвести предварительное тестирование нашего проекта:

$ python setup.py test
running test
running egg_info
writing requirements to helloworld.egg-info/requires.txt
writing helloworld.egg-info/PKG-INFO
writing top-level names to helloworld.egg-info/top_level.txt
writing dependency_links to helloworld.egg-info/dependency_links.txt
writing entry points to helloworld.egg-info/entry_points.txt
reading manifest file 'helloworld.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'helloworld.egg-info/SOURCES.txt'
running build_ext
test_helloworld (tests.HelloworldTestCase) ... ok

----------------------------------------------------------------------
Ran 1 test in 0.000s

OK

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

Публикация пакета на pypi.python.org

Прежде чем вы сможете опубликовать свой проект вам необходимо зарегистрироваться на PyPi. Запишите ваши реквизиты в файле ~/.pypirc:

[distutils]
index-servers =
    pypi

[pypi]
username:<username>
password:<password>

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

$ python setup.py register sdist upload

Note

Вы не сможете опубликовать пакет helloworld, тк данное имя проекта уже занято.

Серверная реализация Android C2DM Push уведомлений (python)

2012-04-03T00:00:00+04:00

Содержание:

Введение
Подготовка к работе
Получение токена для сервера
Отправка Push уведомлений
Интеграция с Django

Статьи по теме

Настало время рассказать, как реализовать серверную поддержку Push уведомлений для Android. Эта возможность появилась в мобильной системе начиная с версии 2.2 (API8). Ниже я рассмотрю реализацию на Python, но для программиста владеющего другими языками, не должно составить труда справиться самостоятельно.

Note

Исходные коды для данной статьи можно увидеть по адресу: https://github.com/klen/klen.github.com/tree/master/_code/android-push

Введение

Эта простая схема описывает работу с C2DM сервисом. Ваше Android приложение (APP) регистрируется в C2DM сервисе (например при запуске) и отправляет полученный регистрационный код серверу (APP SERVER).

Теперь сервер (APP SERVER) используя полученный регистрационный код и специальный токен может сформировать специальный HTTP-запрос сервису C2DM, который в свою очередь отправит Push сообщение устройству на котором запущена ваша программа.

Note

По-умолчанию в C2DM установлена квота на отсылку не более 200000 уведомлений в день. http://code.google.com/android/c2dm/quotas.html

Подготовка к работе

Для начала необходимо зарегистрировать ваше приложение в C2DM по адресу: http://code.google.com/android/c2dm/signup.html

Вам потребуется указать ваш действующий Google-аккаунт и доменное имя вашего приложения. Вы должны получить на почту письмо с подтверждением. После регистрации вашему приложению будет добавлена возможность получать Push-уведомления с учетом действующих в C2DM квот.

Note

Настройка поддержки Push уведомлений на стороне приложения в данной статье не рассматривается. Вы можете изучить например эту статью: C2DM Написание Android клиента

Получение токена для сервера

Получение авторизационного токена для сервера подробно рассматривается в документации: ClientLogin for Installed Applications. Резюмируя данный документ: для получения токена, нам надо сформировать POST запрос со следующими параметрами:

accountType	HOSTED_OR_GOOGLE
Email	our@email.here (email аккаунта регистрировавшего C2DM)
Passwd	our_password_here (пароль)
service	ac2dm
source	our.app идентификатор для логирования (например доменное имя)

Пример запроса:

POST /accounts/ClientLogin HTTP/1.0
Content-type: application/x-www-form-urlencoded

accountType=HOSTED_OR_GOOGLE&Email;=jondoe@gmail.com&Passwd;=north23AZ&service;=cl&source=Gulp-CalGulp-1.05

Сделать это можно например используя Curl (Замените ACCOUNT, PASSWORD, SOURCE на ваши реквизиты):

curl -X POST https://www.google.com/accounts/ClientLogin -d Email=ACCOUNT -d Passwd=PASSWORD -d source=SOURCE -d accountType=HOSTED_OR_GOOGLE -d service=ac2dm

В третьей строке Auth=... и будет ваш искомый токен. Сохраните его в надежном месте.

Отправка Push уведомлений

Отправка уведомлений описана в разделе: How the Application Server Sends Messages. Поддерживаются следующие параметры:

registration_id	Ключ регистрации, полученный приложением от C2DM и переданный серверу приложений
collapse_key	Название группы сообщений.
Authorization: GoogleLogin auth=	Токен авторизации (передается в заголовке)
data.<key>	Набор дополнительных данных в формате key-value
delay_while_idle	Флаг отложенной доставки. Сообщение может быть доставлено позже.

Этих данных достаточно, чтобы написать простой код (для работы с HTTP я использую замечательную библиотеку Requests):

import requests

from .settings import C2DM_URL, C2DM_TOKEN


class AndroidNotifyError(Exception):
    pass


def send_notify(registration_id, collapse_key="default", delay_while_idle=True, **payloads):
    headers = dict(Authorization='GoogleLogin auth=%s' % C2DM_TOKEN)
    data = {'registration_id': registration_id,
            'collapse_key': collapse_key,
            'delay_while_idle': True}

    for(k, v) in payloads.iteritems():
        data["data.%s" % k] = v

    response = requests.post(C2DM_URL, headers=headers, data=data, verify=False)

    if response.ok and 'Error' in response.content:
        _, error_type = response.content.split('=', 1)
        raise AndroidNotifyError(error_type)

    elif response.status_code == 401:
        raise AndroidNotifyError('ClientLogin invalid.')

    elif response.status_code == 503:
        raise AndroidNotifyError('Service temporarily unavailable.')

    return response  #**

Теперь отправлять нотификации можно так:

send_notify('device-registration-id-here', message='test', sound='test')

Интеграция с Django

При интеграции с Django проектом стоит подумать об асинхронности запросов в C2DM.

Асинхронность достигается использованием Celery.

from celery.decorators import task
from android import send_notify

@task(ignore_result=True, max_retries=2, default_retry_delay=10, priority=1)
def _async_android_push(token, payloads, **kwargs):
    return send_notify(token, **payloads)


def send_async_android_notify(token, **payloads):
    return _async_android_push.apply_async(args=(token, payloads))  # Fix rst**

Мысли на будущее: отключение недействительных устройств, массовые рассылки и проверка доставки.

Filler. Пример простой игры на Canvas.

2012-04-01T00:00:00+04:00

Note

Canvas HTML API для отрисовки графики. Поддерживается всеми современными браузерами (в IE начиная с 9й версии)

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

В процессе разработки использовал отличные библиотеки AtomJS и LibCanvas от TheShock. Инструменты понравились и всячески рекомендуются к применению. Выражаю огромную благодарность автору за работу.

Результат вы можете опробовать ниже. Цель игры захватить большинство клеток, меняя свой цвет. Игра начнется по клику на поле. Управлять можно также контролами снизу. Для начала новой игры, перезагрузите страницу.

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

Исходники доступны на гитхабе: https://github.com/klen/filler

Ссылки:

Серверная реализация IOS Push уведомлений (python)

2012-03-20T00:00:00+04:00

Содержание:

Введение
Получение и конвертация сертификата
Реализация IOS Push в python-приложениях
Интеграция с Django

Я уже писал статью про реализацию Push уведомлений с использованием сервиса Urbanairship. У этого способа есть ряд преимуществ и недостатков. Преимущества я описал в вышеприведенной статье, недостаки сервиса в его лимитах на количество бесплатных сообщений и периодических отключениях на техническое обслуживание.

Сегодня мы рассмотрим реализацию IOS Push уведомлений своими руками для Python программ.

Note

Исходные коды для данной статьи можно увидеть по адресу: https://github.com/klen/klen.github.com/tree/master/_code/ios-push

Введение

IOS Push уведомления бывают двух видов: локальные и удаленные. Локальные инициируются приложением на стороне клиента и в данной статье не рассматриваются. Удаленные уведомления отсылаются со стороны сервера на клиентское приложение при помощи службы APNS (Apple Push Notification Service). Процесс выглядит следующим образом:

Приложение регистрируется в APNS и получает Device Token;
Приложение сообщает Device Token нашему серверу;
Теперь сервер может установить SSL соединение с APNS и отправить Push уведомление;

Получение и конвертация сертификата

Push сертификаты для приложений можно получить на iOS Provisioning Portal.

Выберите свое приложение и зайдите в раздел настроек: Configure.

Скачайте production и development сертификаты (*.cer). Возможно вам потребуется предварительно включить Push нотификации для своего приложения и создать их.

Дальнейшие действия лучше провести на компьютере с OSX. Импортируйте полученные сертификаты и экспортируйте их в формате p12. Вероятно вам потребуется ключ разработчика с которым были созданы CSR запросы.

Полученный файл в формате p12 необходимо переконвертировать в pem. Для этой задачи я написал простенький shell скрипт.

https://github.com/klen/klen.github.com/blob/master/_code/ios-push/convert12.sh

Сконвертируем с его помощью полученный от Apple Dev сертификат в нужный нам формат:

# Получим и подготовим скрипт конвертации
wget https://raw.github.com/klen/klen.github.com/master/_code/ios-push/convert12.sh && chmod +x convert12.sh

# Сконвертируем полученные от Apple сертификаты
./convert12 convert pushprod.p12
./convert12 convert pushdev.p12

В процессе у вас будет запрошен пароль на сертификаты, если они создавались без пароля, просто нажмите Enter. Результатом этой операции будут pem файлы с теми же названиями.

Этим же скриптом их можно протестировать, что в дальнейшем избавит от множества проблем при отладке:

# В результате должно быть установлено соединение с Apple
./convert12 test pushprod.pem prod
./convert12 test pushdev.pem dev

Если соединение сразу сбрасывается или выводятся SSL ошибки, вы что-то сделали неправильно.

Реализация IOS Push в python-приложениях

В своих проектах я использую PyAPNs библиотеку. Простой файл обвязка вокруг нее реализует все основные задачи: push.py

import os.path as op
from apns import APNs, Payload


KEYS_FILE = op.abspath(op.join(op.dirname(__file__), 'fakekey.pem'))

assert op.exists(KEYS_FILE)


def get_server(use_sandbox=False, keys_file=KEYS_FILE):
    " Create and return production or develop server. "
    return APNs(use_sandbox=use_sandbox, cert_file=keys_file, key_file=keys_file)


def send_notify(token, server=None, **payloads):
    " Send simple device notify. "
    server = server or get_server()
    return server.gateway_server.send_notification(token, Payload(**payloads))


def get_feedbacks(server):
    " Get inactive tokens. "
    return list(server.feedback_server.items())  # Fix rst**

Пример использования:

from push import send_notify, get_server

token_hex = 'b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b87'
result = send_notify(token_hex, alert="Hello world!", sound="default")

Вполне возможно, что токен от приложения будет приходить к вам в формате Base64, тогда перед сохранением необходимо проделать следующие преобразования.

import binascii
from base64 import urlsafe_b64decode

def fix_token(token):
    token = token.strip()
    token = token.encode('utf-8') if isinstance(token, unicode) else token
    token = urlsafe_b64decode(token + '=' * (4 - len(token) % 4))
    token = binascii.hexlify(token)

Интеграция с Django

При интеграции с Django проектом необходимо подумать о переключении между developer и production и об асинхронности запросов в APNS.

Асинхронность достигается использованием Celery.

from celery.decorators import task
from ios import send_notify

@task(ignore_result=True, max_retries=2, default_retry_delay=10, priority=1)
def _async_ios_push(token, payloads, **kwargs):
    return send_notify(token, **payloads)


def send_async_ios_notify(message, token=None):
    " Send IOS push notification. "
    if not token:
        return False

    if isinstance(message, basestring):
        message = dict(alert=message)

    data = dict(item for item in message.iteritems() if not item[0] in ['alert', 'sound'])

    return _async_ios_push.apply_async(args=(token, dict(
        sound=message.get('sound', 'default'),
        alert=message.get('alert'),
        custom=dict(data=data),
    )))  # Fix rst**

Стоит подумать и об отключении неактивных устройств: tasks.py:

from abstract_app.models import Client
from celery.decorators import periodic_task

from .ios import get_feedbacks
from .settings import IOS_CLEAN_INTERVAL


@periodic_task(ignore_result=True, run_every=IOS_CLEAN_INTERVAL)
def parse_async_feedbacks():
    feedbacks = get_feedbacks()
    if feedbacks:
        tokens, _ = zip(*feedbacks)
        Client.objects.filter(token__in=tokens).update(active=False)
    return True  # Fix rst*

Полностью пример модуля для Django вы можете увидеть по ссылке: https://github.com/klen/klen.github.com/tree/master/_code/ios-push/django/push

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

Настройка HTTPS для чайников

2012-03-12T00:00:00+04:00

Содержание:

Введение
Запрос на получение сертификата (CSR)
Получение подписанных SSL ключей на 90-дневной период
Настройка Nginx для работы с SSL

HTTPS (Hypertext Transfer Protocol Secure) — расширение протокола HTTP поддерживающее шифрование. Данные, передаваемые по протоколу HTTPS «упаковываются» в криптографический протокол SSL или TLS, тем самым обеспечивается защита этих данных. В отличие от HTTP для HTTPS по умолчанию используется TCP-порт 443.

В данной статье я расскажу о том, как бесплатно (90 дней) получить сертифицированные SSL ключи для своего сервера и настроить HTTPS соединения. На данный момент в русскоязычных источниках эта информация представлена разрозненно, поэтому данную статью можно использовать как руководство по получению подписанных ключей и быстрой настройке HTTPS.

Введение

Чтобы подготовить сервер для обработки https-соединений, администратор должен получить и установить в систему сертификат для этого веб-сервера. Сертификат можно создать самостоятельно с помощью Unix утилиты ssl-ca из пакета OpenSSL, но подписанный данным методом сертификат не является безопасным и большинство браузеров выдают предупреждения об этом. Часть агентов также блокирует сайты с такими сертификатами, например IPhone приложения.

Сертификаты подписанные компаниями-сертификаторами избавлены от данной проблемы, но требуют оплаты для использования. Основные компании-сертификаторы: VerySign, SSLCOM, DigiCert и другие. Так сложилось, что я предпочитаю использовать SSLCOM в основном из-за их 90-дневного бесплатного периода использования для новых ключей, получение которого и будет описано в данной статье. За три месяца можно основательно протестировать проект, понять приоритеты, сделать полноценный запуск и в дальнейшем уже решить будете ли вы продлевать действие сертификата за деньги.

Запрос на получение сертификата (CSR)

CSR — запрос на получение сертификата, требуется для подписи ключей компанией-сертификатором. Я создаю его в консоли Unix-систем, например в терминале на стороне сервера. Если у вас нет такой возможности, вы можете создать CSR онлайн: https://www.reg.ru/sslcertificate/generate_key_and_csr

Из консоли:

# Создадим директорию для работы
mkdir -p ~/csr && cd ~/csr

# Создадим приватный ключ и запрос на сертификат
openssl req -new -newkey rsa:2048 -nodes -keyout <your_domain_name>.key -out <your_domain_name>.csr

Note

Все поля CSR должны заполняться на английском. Код страны — двух буквенный Alpha2 (RU для России).

your_domain_name — имя домена для которого создается сертификат

Common name — адрес домена (без www). Wildcart записи вида *.domen.com не поддерживаются на бесплатном тарифе.

Пример заполнения:

Скопируйте полученный ключ <your_domain_name>.key и файл запроса <your_domain_name>.csr в надежное место.

Получение подписанных SSL ключей на 90-дневной период

Подписывать ключи будем у http://ssl.com. Для начала работы войдите на сервис или зарегистрируйтесь.

После входа попадаем на страницу задач и выбираем buy certificate для продолжения.

На открывшейся странице выбираем Free SSL.

Нажимаем кнопку GET и попадаем на первый шаг процесса подписания нашего сертификата. В открывшейся странице выберите чекбокс I want to submit my CSR now для добавления полученного нами на предыдущем шаге CSR.

В данной статье мы будем настраивать Nginx поэтому из выпадающего списка я выбрал соответствующую опцию.

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

Пятый шаг — подтверждение домена. Возможно два варианта, размещение файла на сервере или подтверждение по электронной почте. Адреса требуемые для подтверждения через email не всегда доступны, поэтому я обычно выкладываю на сервер полученный файл.

Пример конфигурации для Nginx (файл D3AD7299FFC0954B0FD047063ABB7EFD.txt лежит в папке /home/user):

location = /D3AD7299FFC0954B0FD047063ABB7EFD.txt {
    alias /home/user/D3AD7299FFC0954B0FD047063ABB7EFD.txt;
}

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

Если проверку вы прошли успешно, остается только ждать подтверждения от компании-сертификатора, что может занять от нескольких часов до суток.

После добавления ключей компанией сертификатором вам будет выслано уведомительное письмо. Откройте страницу заказа сертификата и загрузите его к себе на компьютер. Для Nginx вы получите файл ca_bundle.txt

Полученный файл переименуйте в формат <your_domain_name>.bundle.crt и вместе с ключом который мы создали на первом шаге (<your_domain_name>.key) положите на сервер.

Настройка Nginx для работы с SSL

Для включения SSL в Nginx добавьте в конфигурацию сервера следующие настройки:

server {
    ...
    listen 443;
    ssl                     on;
    ssl_protocols   SSLv3 TLSv1;
    ssl_certificate /<path_to_file>/<your_domain_name>.bundle.crt;
    ssl_certificate_key     /<path_to_file>/<your_domain_name>.key;
    ...
}

Для автоматического направления всех HTTP запросов на HTTPS, обычно достаточно следующей конфигурации:

# HTTPS settings
server {
    listen 443;
    ssl                     on;
    ssl_protocols   SSLv3 TLSv1;
    ssl_certificate /<path_to_file>/<your_domain_name>.bundle.crt;
    ssl_certificate_key     /<path_to_file>/<your_domain_name>.key;
    ...
}

# HTTP settings
server {
    listen 80
    rewrite ^(.*) https://$server_name$1 permanent;
}

И не забудьте обновить сертификаты через три месяца! :)

Flask. Примеры opensource проектов

2012-02-18T00:00:00+04:00

Flask — легковесный веб-фреймворк для python. Создатель стремится сделать его простым, легким в освоении для новичков и легко расширяемым.

Ядро микрофреймворка содержит следующие возможности:

Сервер для разработки и дебаггер;
Поддержка unit тестов;
RESTfull request routing;
Jinja2 шаблоны;
Сессии;
100% совместимость с WSGI;
Поддержка Unicode;
Хорошая документация;
Совместимость с Google App Engine;
Лёгкая расширяемость.

Лучшие способ освоить новую библиотеку — прочитать документацию и изучить хорошие примеры. Несколько открытых проектов на Flask я и собрал ниже.

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

Ссылки и заметки

2012-02-18T00:00:00+04:00

Новый дизайн сайта и новая рубрика «Заметки». Формат полноценной статьи не всегда удобен когда хочется поделиться мыслями или найденной в интернете информацией. Для этих целей и предназначен данный раздел.

Несколько полезных сниппетов для джанго

2011-12-02T00:00:00+04:00

Содержание:

Автоматическая генерация имени файла в полях типа FileField, ImageField
- Пример работы
- Параметры сниппета
Работа с кешем
- Примеры работы
Атомарные обновления

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

Автоматическая генерация имени файла в полях типа FileField, ImageField

В Django поля типа FileField и ImageField позволяют определять функцию для генерации имени сохраняемого файла. Она указывается в аргументе upload_to при создании поля.

Когда мне надоело придумывать уникальные имена файлов, при сохранении их в Django-проектах я написал нижеприведенный сниппет.

Генерируемые пути файлов содержат только латинские и цифровые символы;
Файлы с одинаковыми названиями, загружаемые в разные инстансы не перезаписываются;
Файлы удобно хранятся отсортированные по приложениям и моделям;
Путь файла однозначно говорит нам о том, что за инстанс его использует;
Система не позволяет тысячам файлов скапливаться в одной папке;

from hashlib import md5
from os import path as op
from time import time


def upload_to(instance, filename, prefix=None, unique=False):
    """ Auto generate name for File and Image fields.
    """
    ext = op.splitext(filename)[1]
    name = str(instance.pk or '') + filename + (str(time()) if unique else '')

    # We think that we use utf8 based OS file system
    filename = md5(name.encode('utf8')).hexdigest() + ext
    basedir = op.join(instance._meta.app_label, instance._meta.module_name)
    if prefix:
        basedir = op.join(basedir, prefix)
    return op.join(basedir, filename[:2], filename[2:4], filename)

Пример работы

Например у нас есть модель Archive в приложении storage, storage/models.py:

from django.db import models

class Archive(model.Model):
    title = models.CharField(max_length=100)
    file = models.FileField(upload_to=upload_to)

В результате сохраненные файлы будут иметь пути вида: {MEDIA_URL}/storage/archive/21/40/2140e8fe8678bc08ff6e9b10c9639068.zip

Здесь присутствует имя приложения, имя модели, созданное новое имя файла и его расширение. При этом путь дробится на папки согласно четырем первым символам в имени файла 21/40/2140e8.... Это позволяет значительно отсрочить ситуацию с сотнями тысяч объектов в папке и тормоза файловой системы.

Параметры сниппета

Функция upload_to может принимать до 4-х параметров. Аргументы instance и filename передаются Django.

Аргумент prefix принимает строковые значения и позволяет дополнительно настраивать пути файлов. Например при определении префикса prefix="cart" вышеприведенный код будет сохранять файлы с путями вида: {MEDIA_URL}/storage/archive/cart/21/40/2140e8fe8678bc08ff6e9b10c9639068.zip. Префикс был добавлен после имени модели.

Аргумент unique принимает булевы значения и позволяет гарантированно получить уникальное имя файла. По-умолчанию для instance с одинаковым ключом, для одинаковых имен файла, будет создан идентичный путь. Это сделано намеренно, чтобы при обновлении файлов пути в конкретной модели не изменялись. Параметр unique меняет это поведение и при каждом изменении файла, путь будет другим.

Но как использовать все эти параметры если Django передает в указанную функцию только первые два? Здесь нам поможет Каррирование. Мы используем функцию curry из django.utils.functional, которая имитирует это поведение в python.

Например в нижеприведенном коде:

from django.db import models
from django.utils.functional import curry

class Archive(model.Model):
    title = models.CharField(max_length=100)
    cover = models.ImageField(upload_to=curry(upload_to, prefix='cover'))
    file = models.FileField(upload_to=curry(upload_to, prefix='file'))
    other = models.FileField(upload_to=curry(upload_to, unique=True))

Файлы из поля cover будут сохраняться с путями вида: {MEDIA_URL}/storage/archive/cover/21/40/2140e8fe8678bc08ff6e9b10c9639068.jpg

Файлы из поля file будут сохраняться с путями вида: {MEDIA_URL}/storage/archive/file/21/40/2140e8fe8678bc08ff6e9b10c9639068.zip

Файлы из поля other всегда будут иметь уникальные пути, вида: {MEDIA_URL}/storage/archive/11/11/1111e8fe8678bc08ff6e9b10c9639068.mp3

Работа с кешем

В работе с кешированием проекта нужна четкая стратегия и обозначенные соглашения. Например наименования ключей кэша. SomeModel.object.filter(active=True) с каким ключом хранить результат выполнения этого запроса? Как параллельный разработчик узнает этот ключ? Когда производить инвалидацию? Для Django существуют приложения помогающие решать эту проблему, но зачастую они слишком перегружены и сложны в использовании.

Для простых проектов я написал несколько полезных функций:

import hashlib
import re

from django.core.cache import cache
from django.db.models import Model, get_model
from django.db.models.base import ModelBase
from django.db.models.query import QuerySet
from django.utils.encoding import smart_str

def cached_instance(model, **filters):
    """ Auto cached model instance.
    """
    if isinstance(model, basestring):
        assert '.' in model, ("'model_class' must be either a model"
                                " or a model name in the format"
                                " app_label.model_name")
        app_label, model_name = model.split(".")
        model = get_model(app_label, model_name)

    cache_key = generate_cache_key(model, **filters)
    return get_cached(cache_key, model.objects.select_related().get, kwargs=filters)


def cached_query(qs, timeout=None):
    """ Auto cached queryset and generate results.
    """
    cache_key = generate_cache_key(qs)
    return get_cached(cache_key, list, args=(qs,), timeout=None)


def clean_cache(*args, **kwargs):
    """ Generate cache key and clean cached value.
    """
    cache_key = generate_cache_key(*args, **kwargs)
    cache.delete(cache_key)


def generate_cache_key(cached, **kwargs):
    """ Auto generate cache key for model or queryset
    """
    if isinstance(cached, QuerySet):
        key = str(cached.query)

    elif isinstance(cached, (Model, ModelBase)):
        key = '%s.%s:%s' % (cached._meta.app_label,
                cached._meta.module_name,
                ','.join('%s=%s' % item for item in kwargs.iteritems()))

    else:
        raise AttributeError("Objects must be queryset or model.")

    if not key:
        raise Exception('Cache key cannot be empty.')

    key = clean_cache_key(key)
    return key


def clean_cache_key(key):
    """ Replace spaces with '-' and hash if length is greater than 250.
    """
    cache_key = re.sub(r'\s+', '-', key)
    cache_key = smart_str(cache_key)

    if len(cache_key) > 200:
        cache_key = cache_key[:150] + '-' + hashlib.md5(cache_key).hexdigest()

    return cache_key


def get_cached(cache_key, func, timeout=None, args=None, kwargs=None):
    args = args or list()
    kwargs = kwargs or dict()
    result = cache.get(cache_key)

    if result is None:

        if timeout is None:
            timeout = cache.default_timeout

        result = func(*args, **kwargs)
        cache.set(cache_key, result, timeout=timeout)

    return result

    #**

Примеры работы

# Генерация ключей для Queryset (разные ключи для разных запросов)
print generate_cache_key(TaxiStation.objects.all())
print generate_cache_key(TaxiStation.objects.all())
print generate_cache_key(TaxiStation.objects.filter(active=True))
print generate_cache_key(TaxiStation.objects.filter(city=1, title="intaxi"))
print generate_cache_key(TaxiStation.objects.filter(active=True))

# Output: 'SELECT-"main_taxistation"."id",-"main_taxistation"."active",-"main_taxistation"."title",-"main_taxistation"."city_id",-"main_taxistation"."agent_id",--873aa3b2fbd81cdaa9fce75e60706579'
# Output: 'SELECT-"main_taxistation"."id",-"main_taxistation"."active",-"main_taxistation"."title",-"main_taxistation"."city_id",-"main_taxistation"."agent_id",--873aa3b2fbd81cdaa9fce75e60706579'
# Output: 'SELECT-"main_taxistation"."id",-"main_taxistation"."active",-"main_taxistation"."title",-"main_taxistation"."city_id",-"main_taxistation"."agent_id",--043271300c8db6cc9152ef3119e6195c'
# Output: 'SELECT-"main_taxistation"."id",-"main_taxistation"."active",-"main_taxistation"."title",-"main_taxistation"."city_id",-"main_taxistation"."agent_id",--98960ebe77c30e08fe6b4a4fd2b1ab57'
# Output: 'SELECT-"main_taxistation"."id",-"main_taxistation"."active",-"main_taxistation"."title",-"main_taxistation"."city_id",-"main_taxistation"."agent_id",--043271300c8db6cc9152ef3119e6195c'

# Генерация ключей для Model
print generate_cache_key(TaxiStation, pk=100, active=True)
print generate_cache_key(TaxiStation, pk=50)

# Output: main.taxistation:pk=50

# Кеширование Queryset (получение данных из кеша или из БД с сохранением в кеш)
all = cached_query(SomeModel.objects.all())
some_results =  cached_query(SomeModel.objects.filter(param=True))

# Принудительная очистка кеша Queryset
clean_cache(SomeModel.objects.all())
clean_cache(SomeModel.objects.filter(param=True))

# Кеширование instance
order = cached_instance(Order, pk=20, title="Some title")

# можно и по имени
order = cached_instance('app.order', pk=20, title="Some title")

# Очистка кеша
clean_cache(Order, pk=20, title="Some title")

Атомарные обновления

Часто возникают ситуации когда нам необходимо обновить одно или несколько полей объекта. В Django по-умолчанию это можно сделать при помощи следующего кода:

# Допустим у нас есть объект order (instance of model)
order.custom_field = custom_value
order.full_clean()
order.save()

При этом ORM Django создает и выполняет запрос содержащий обновление всех полей объекта, что может быть довольно медленной операцией.

Значительно быстрее сработает следующая конструкция:

order.custom_field = custom_value
order.full_clean()
Order.objects.filter(pk=order.pk).update(custom_field = custom_value)

Но она несколько неудобна. Следующая функция решает эту проблему.

import operator

from django.db import models
from django.db.models.expressions import F, ExpressionNode


EXPRESSION_NODE_CALLBACKS = {
    ExpressionNode.ADD: operator.add,
    ExpressionNode.SUB: operator.sub,
    ExpressionNode.MUL: operator.mul,
    ExpressionNode.DIV: operator.div,
    ExpressionNode.MOD: operator.mod,
    ExpressionNode.AND: operator.and_,
    ExpressionNode.OR: operator.or_,
    }

class CannotResolve(Exception):
    pass

def _resolve(instance, node):
    if isinstance(node, F):
        return getattr(instance, node.name)
    elif isinstance(node, ExpressionNode):
        return _resolve(instance, node)
    return node

def resolve_expression_node(instance, node):
    op = EXPRESSION_NODE_CALLBACKS.get(node.connector, None)
    if not op:
        raise CannotResolve
    runner = _resolve(instance, node.children[0])
    for n in node.children[1:]:
        runner = op(runner, _resolve(instance, n))
    return runner

def update(instance, full_clean=False, **kwargs):
    "Atomically update instance, setting field/value pairs from kwargs"

    # apply the updated args to the instance to mimic the change
    # note that these might slightly differ from the true database values
    # as the DB could have been updated by another thread. callers should
    # retrieve a new copy of the object if up-to-date values are required
    for k, v in kwargs.iteritems():
        if isinstance(v, ExpressionNode):
            v = resolve_expression_node(instance, v)
        setattr(instance, k, v)

    # clean instance before update
    if full_clean:
        instance.full_clean()

    # fields that use auto_now=True should be updated corrected, too!
    for field in instance._meta.fields:
        if hasattr(field, 'auto_now') and field.auto_now and field.name not in kwargs:
            kwargs[field.name] = field.pre_save(instance, False)

    rows_affected = instance.__class__._default_manager.filter(pk=instance.pk).update(**kwargs)
    return rows_affected

#**

Теперь мы можем делать так:

# Обновили объект и сохранили его в базу, через
update(order, custom_field=custom_value)

print order.custom_field
# Output: custom_value

Или даже так:

update(order, custom_field=custom_value, other_field=other_value, more_field=more_value)

Обходясь при этом без тяжелых запросов к базе.

SELECT (1) AS "a" FROM "main_order" WHERE "main_order"."id" = 22387  LIMIT 1; args=(22387,)
UPDATE "main_order" SET "created_at" = E'2011-12-02 19:39:00.969044', "city_id" = 1, "when" = E'2011-12-02 19:50:00', "price" = E'100.00', "expected_price" = E'350.00', "car_class" = 10, "conditioner" = false, "smoke" = false, "no_smoke" = false, "child_seat" = false, "long_length" = false, "meet_sign" = false, "from_address_id" = 17130, "to_address_id" = 17131, "route_id" = NULL, "from_node_id" = 501, "to_node_id" = 501, "from_address_entrance_no" = E'', "from_comment" = E'', "to_comment" = E'', "flight_number" = E'', "meet_sign_text" = E'', "auto_id" = NULL, "fare_id" = 42, "taxistation_id" = 1, "passenger_id" = 71111111111, "device_id" = E'200774696189910', "device_agent" = E'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.2 ', "device_name" = E'Web', "device_token" = E'', "device_sms" = true, "current_status" = E'WaitForCarAssigment', "updated" = E'2011-12-02 19:40:09.405462', "credit" = false WHERE "main_order"."id" = 22387 ; args=(u'2011-12-02 19:39:00.969044', 1, u'2011-12-02 19:50:00', u'100.00', u'350.00', 10, False, False, False, False, False, False, 17130, 17131, 501, 501, u'', u'', u'', u'', u'', 42, 1, 71111111111L, u'200774696189910', u'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.2 ', u'Web', u'', True, 'WaitForCarAssigment', u'2011-12-02 19:40:09.405462', False, 22387)

UPDATE "main_order" SET "price" = E'100.00' WHERE "main_order"."id" = 22387 ; args=(u'100.00', 22387)

Надеюсь эти несколько простых функций, будут также полезны вам, как и мне.

Настройка сервера. Создаем и разворачиваем django-проект

2011-11-26T00:00:00+04:00

Содержание:

Makesite
Установка и настройка Makesite
Создание проекта
Подготовка Django-проекта к деплою
Создание ключей для клонирования репозитория
Установка зависимостей
Установка и удаление проекта
Обновление проекта

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

Note

Все инструкции в этой статье приводятся для системы Ubuntu Oneiric, пользователь ubuntu.

Makesite

Настройка, развертывание и обновление сайтов — операции, требующие автоматизации. Есть множество утилит для этого, например Capistrano (ruby) или Fabric (python). В свое время эта задача встала и передо мной. Были определены следующие требования:

В основе системы должны находится shell скрипты;
Развертывание проекта должно производится одной командой;
Элементарное обновление или удаление проектов;
Каждый экземпляр проекта привязан к ветке репозитория;
Настройки всех проектов могут быть заданы как глобально, так и в момент развертывания;
Легкость настройки и создания шаблонов;
Автономность уже развернутого проекта;

Беглый осмотр существующих решений привел к необходимости в очередной раз писать свой велосипед. В итоге на свет появился Makesite. Описание всех принципов его работы выходит за рамки данной статьи.

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

Установка и настройка Makesite

Note

Данные действия выполняются на сервере

Для начала работы на нашем сервере потребуется установить и настроить Makesite. Рекомендуется проводить установку при помощи setuptools:

# Устанавливаем setup-tools
sudo apt-get install python-setuptools python-pip

# Устанавливаем makesite
sudo easy_install makesite

# Или при помощи Pip
sudo pip install makesite

Теперь нам необходимо решить в какой директории будут развернуты наши проекты и указать ее для Makesite. Обычно я использую /var/www. Чтобы не вводить этот путь при каждой операции, определим системную переменную $MAKESITE_HOME. Удобно сразу это сделать при помощи следующей команды:

# Создаем директорию для хранения наших будущих сайтов
$ sudo mkdir /var/www

# Выводим и проверяем настройки bash
$ makesite shell -p /var/www

# Записываем их в ваш ~/.bashrc
$ makesite shell -p /var/www >> ~/.bashrc

# Загружаем настройки для текущего сеанса
$ source ~/.bashrc

Создаем корневой файл конфигурации в указанной нами директории /var/www/makesite.ini.

Note

В примерах используется адрес созданного в предыдущих статьях AWS сервера: awsdemo.us.to.

[Main]

# Указываем источник получения кода проектов по умолчанию
# В данном случае будет использоваться созданный нами репозиторий
# Префикс 'git+' указывает Makesite на способ получения
# В настройках можно применять переменные, в данном случае будет
# производиться поиск репозитория по имени разворачиваемого проекта
src = git+git@awsdemo.us.to:%(project)s.git

# Доменное имя для создаваемых конфигураций сайтов
# Можно было сделать например так:
# domain = %(branch)s.%(project)s.us.to
# Но так как полученный нами бесплатный DNS не поддерживает Wildcard записи,
# поступим проще:
domain = %(project)s.us.to

# Режим деплоя (это всего лишь переменная которую можно использовать в шаблонах)
mode = dev

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

Создание проекта

Note

Данные действия выполняются локально

Перейдем к репозиторию awsdemo на нашей локальной машине, который мы создали в прошлой статье и превратим его в Django-проект.

# Переходим в директорию нашего проекта
$ cd ~/Projects/awsdemo

# Создаем новый django-проект
$ django-admin.py startproject aws

# Переносим файлы из созданного проекта в наш репозиторий
$ mv aws/* . && rm -r aws

# Сохраняем изменения в git
$ git add .
$ git commit -m 'Start new django-project'

Теперь его надо подготовить к деплою.

Note

Файлы с исходным кодом Django-проекта можно найти по адресу: https://github.com/klen/klen.github.com/tree/master/_code/awsdemo

Подготовка Django-проекта к деплою

Note

Данные действия выполняются локально

Рекомендуется, но совсем необязательно, создавать в корневой директории проекта файл конфигурации Makesite с основными параметрами деплоя.

Создадим файл makesite.ini:

[Main]
# Шаблоны Makesite которые будут применятся для нашего сайта
# всегда есть возможность создать собственные шаблоны
# в том числе и в хранимые с исходниками проекта
template=virtualenv,django,uwsgi

Для шаблона virtualenv (он создает и обновляет при необходимости виртуальное окружение проекта) необходимо создать файл с зависимостями.

requirements.txt:

# Django
Django==1.3

Для шаблона uwsgi (он запускает наш проект с помощью uwsgi и nginx) необходимо создать файл определяющий наше wsgi-приложение.

wsgi.py:

#!/usr/bin/env python
from os import environ
from django.core.handlers.wsgi import WSGIHandler

environ['DJANGO_SETTINGS_MODULE'] = environ.get(
    'DJANGO_SETTINGS_MODULE', 'settings')

application = WSGIHandler()

Следующее, что необходимо сделать это поправить settings.py изменив его следующим образом (включаем базу данных, интерфейс администрирования, определяем путь к STATIC_ROOT и правим urlconf):

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': 'aws.db',
...

from os import path as op
DEPLOY_DIR = op.dirname(op.dirname(__file__))
STATIC_ROOT = op.join(DEPLOY_DIR, 'static')

...

ROOT_URLCONF = 'urls'

...

# Uncomment the next line to enable the admin:
'django.contrib.admin',

...

И последнее создадим фикстуру для создания первого пользователя initial_data.json (login: admin, pasword: admin):

[{
        "model": "auth.user",
        "pk": 1,
        "fields": {
            "username": "admin",
            "first_name": "Darth",
            "last_name": "Vader",
            "is_active": true,
            "is_superuser": true,
            "is_staff": true,
            "last_login": "2000-01-01 00:00:00",
            "groups": [],
            "user_permissions": [],
            "password": "sha1$bb19a$51b2bac8dd83c30e6cf6694bf3049241a14124ea",
            "email": "admin@admin.admin",
            "date_joined": "2000-01-01 00:00:00"
        }}]

Наш проект готов к деплою.

Создание ключей для клонирования репозитория

Note

Данные действия выполняются на сервере

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

Я предпочитаю второй вариант:

# Переходим в нашу домашнюю .ssh директорию
$ cd ~/.ssh

# Создаем отдельный ключ для makesite (укажите makesite в имени файла)
# без паролей
$ ssh-keygen
  Generating public/private rsa key pair.
  Enter file in which to save the key (/home/ubuntu/.ssh/id_rsa): makesite
  Enter passphrase (empty for no passphrase):
  Enter same passphrase again:
  Your identification has been saved in makesite.
  Your public key has been saved in makesite.pub.

# Копируем ключ в id_rsa
$ cp makesite id_rsa
$ cp makesite.pub id_rsa.pub

Полученный ключ надо подключить к нашему репозиторию, путем редактирования gitolite_admin (подробности в предыдущей статье). Вкратце ваш порядок действий:

Скопировать ключ ~/.ssh/makesite.pub в gitolite-admin/keydir/makesite.pub (например при помощи scp)
Обновить параметры доступа к awsdemo в файле gitolite-admin/conf/gitolite.conf (добавить строчку RW+ makesite)
Сделать коммит с изменениями и пуш на сервер.

Теперь можно проверить работу с репозиторием на стороне сервера:

git clone git@awsdemo.us.to:awsdemo.git /tmp/aws

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

Установка зависимостей

Note

Данные действия выполняются на сервере

Дадим команду Makesite на деплой нашего проекта:

makesite install awsdemo

Помните мы указали строку "src = git+git@awsdemo.us.to:%(project)s.git" в /var/www/makesite.ini, она говорит Makesite где получать исходники проекта. То есть вышеприведенная команда по факту транслируется следующим образом:

makesite install awsdemo --src git+git@awsdemo.us.to:awsdemo.git

Note

Makesite поддерживает установку из пути файловой системы, или git, mercurial (hg+), subversion (svn+) систем контроля версий

Вывод команды будет приблизительно таким:

Clone src: git+git@awsdemo.us.to:awsdemo.git
--------------------------------------------
Cmd: /usr/bin/git clone git@awsdemo.us.to:awsdemo.git /tmp/tmpkWznFx/source
remote: Counting objects: 12, done.
remote: Compressing objects: 100% (9/9), done.
remote: Total 12 (delta 1), reused 0 (delta 0)
Receiving objects: 100% (12/12), done.
Resolving deltas: 100% (1/1), done.

Deploy templates: base,src-git,virtualenv,supervisor,nginx,uwsgi
----------------------------------------------------------------
Prepare template: base
Prepare template: src-git
Prepare template: virtualenv
Prepare template: supervisor
Prepare template: nginx
Prepare template: uwsgi

Check requirements
------------------
Cmd: sudo chmod +x /tmp/tmpkWznFx/service/*.sh
Cmd: /bin/bash /tmp/tmpkWznFx/service/base_check.sh
Cmd: /bin/bash /tmp/tmpkWznFx/service/virtualenv_check.sh
Error: Command 'virtualenv' not found!
Install python-virtualenv package

Command '/bin/bash /tmp/tmpkWznFx/service/virtualenv_check.sh' returned non-zero exit status 127
See log: /tmp/tmp8IAJYB

Он говорит нам о том, что на стадии проверки зависимостей Makesite прервал установку. Команда virtualenv не была найдена в системе.

Мы можем поставить python-virtualenv и повторить попытку, но споткнемся на nginx, uwsgi или других зависимостях. Поэтому поставим все сразу одной командой.

sudo apt-get install python-virtualenv nginx uwsgi uwsgi-plugin-python nginx supervisor
sudo /etc/init.d/nginx start

Установка и удаление проекта

Note

Данные действия выполняются на сервере

Теперь повторим деплой нашего проекта:

$ makesite install awsdemo

Эта команда создаст следующую структуру директорий:

/var/www/master/
            awsdemo/
                |
                |-deploy/      # Файлы конфигурации
                |-logs/        # Логи nginx, supervisor, uwsgi
                |-media/       # Папка для загружаемых файлов
                |-service/     # Скрипты для обслуживания проекта
                |-source/      # Исходный код проекта
                |-static/      # Статика проекта
                |-.virtualenv/ # Виртуальное окружение проекта
                |-makesite.ini # Параметры проекта
                |-.makesite    # Список шаблонов проекта

Сайт уже запущен и работает. Makesite скачал исходники, развернул виртуальное окружение, создал файлы конфигурации nginx, supervisor, uwsgi и подключил их, выполнил синхронизацию базы данных, скопировал файлы статики, а также создал shell скрипты для обновления, удаления и перезапуска проекта.

Для пробы удалим развернутый проект:

Note

В bash, для большинства команд Makesite, работает автодополнение.

# Указываем короткое имя проекта (ветка.проект)
$ makesite uninstall master.awsdemo

# Или можно указать полный путь
$ makesite uninstall /var/www/awsdemo/master

Проект удален из системы, nginx и supervisor перезагружены. Теперь можно развернуть его снова вышеприведенной командой.

Обновление проекта

Note

Данные действия выполняются локально

Изменим что-нибудь в нашем проекте, например добавим views.py:

from django.http import HttpResponse


def home(request):
    return HttpResponse("Hello from makesite!")

Подключим его в urls.py:

...

# Examples:
url(r'^$', 'views.home', name='home'),

...

Сохраним и отправим изменения на сервер. Теперь на сервере достаточно ввести команду makesite update master.awsdemo, чтобы наш сайт обновился. При этом новые зависимости, миграции, статические файлы Makesite обработает самостоятельно.

В рамках данной статьи я планировал показать как создать свой хук на обновление репозитория в gitolite, чтобы git push в удаленный репозиторий вызывал автоматическое обновление соответствующих сайтов (по факту makesite update), но статья и так получилась достаточно длинной, поэтому эта задача предлагается к выполнению в качестве домашнего задания.

Note

Подробная статья про работу с Makesite находится в моих ближайших планах

Настройка сервера. Gitolite — хостинг git-репозиториев

2011-11-18T00:00:00+04:00

Содержание:

Начало работы
Установка Gitolite
Управление Gitolite

В предыдущей статье я рассказал как создать свой бесплатный (в течении года) сервер на облаке от Amazon Web Services. Пришла пора настроить на нем среду для удобной разработки.

Ниже будет описано создание собственного Git репозитория с помощью Gitolite.

Note

Все инструкции в этой статье приводятся для системы Ubuntu Oneiric, пользователь ubuntu.

Начало работы

Первые мои команды на новом сервере:

# Обновление системы (да мне нравятся свежие пакеты)
sudo apt-get update
sudo apt-get upgrade

# Утилиты для сборки
$ sudo apt-get install build-essential

# Конфигурирование локалей
$ sudo locale-gen ru_RU.UTF-8
$ sudo locale-gen en_US.UTF-8
$ sudo dpkg-reconfigure locales

Установка Gitolite

Git распределенная система контроля версий и не нуждается в хостинг-сервере. Но в таком случае для доступа к репозиторию необходим доступ к файловой системе, в которой он расположен. В противном случае для синхронизации (команды разработчиков или кода на сервере) необходим Git хостинг с сетевым доступом.

Самые распространенные решения: Gitolite и Gitosis. Я предпочитаю Gitolite из-за удобства настройки и установки.

Для начала установим Git и Gitolite из пакетов:

# Установка git и gitolite
$ sudo apt-get install git gitolite

Теперь нужно создать владельца репозиториев. Обычно используется пользователь с логином: git. Создадим его и выполним под ним настройку Gitolite:

# Создание пользователя git
$ sudo useradd -m git

# Копируем свой публичный ssh rsa ключ из домашней директории
# для настройки управления репозиторием
$ sudo cp ~/.ssh/id_rsa.pub /home/git/admin.pub

# Заходим под пользователем git и заканчиваем настройку
$ sudo su git
$ cd
$ gl-setup admin.pub

В этот момент откроется Vim с настройками репозитория по-умолчанию. Сохраняя спокойствие, нажмите :x для сохранения и выхода из редактора. Нажмите Ctrl+D для окончания сеанса пользователя git. Поздравляю первый этап настройки закончен, можете закрыть соединение с сервером, дальнейшая настройка будет произведена на вашей локальной машине.

Управление Gitolite

Управление Gitolite осуществляется с помощью специального репозитория gitolite-admin который уже создан у вас на сервере. Добавление репозиториев и пользователей, изменения конфигурации производятся через стандартные Git операции (commit, push).

Скачаем этот репозиторий на ваш локальный компьютер:

Note

Здесь, и далее, я работаю с адресом моей созданной на Amazon VPS: awsdemo.us.to. Для вас он будет отличаться. Как создать и прикрепить свой домен было рассказано в прошлой статье.

# -- Ваша локальная машина --
# git clone git@<your_vps_domain>:gitolite-admin.git
git clone git@awsdemo.us.to:gitolite-admin.git

Если вы ничего не напутали с ключами и настройками, то gitolite-admin будет скопирован на ваш компьютер.

Note

gitolite-admin включает в себя две папки. Папка keys включает в себя файлы с публичными частями rsa ключей пользователей репозитория. Папка conf содержит файлы конфигурации gitolite.

Посмотрим на файл conf/gitolite.conf:

repo    gitolite-admin
        RW+     =   admin

repo    testing
        RW+     =   @all

Он говорит нам о том, что на нашем хостинге доступно два репозитория: gitolite-admin и testing, при чем к первому из них доступ на чтение и запись имеет только пользователь с ключом сохраненным в файле keys/admin.pub, а ко второму все пользователи.

Добавим еще одну запись для нашего будущего Django-проекта, я назову его awsdemo:

repo    gitolite-admin
        RW+     =   admin

repo    testing
        RW+     =   @all

repo    awsdemo
        RW+     =   admin

Сохраним изменения и отправим их на сервер:

$ git commit -am 'Add django repo'
$ git push origin master

Теперь можно создавать сам проект и привязывать его к удаленному хостингу:

# Создание директории для будущего проекта
$ mkdir -p ~/Projects/awsdemo
$ cd ~/Projects/awsdemo

# Создание репозитория
$ git init

# Привязываем его к нашему хостингу
$ git remote add origin git@awsdemo.us.to:awsdemo.git

# Первый коммит
$ touch README
$ git add .
$ git commit -am "Initial commit"

# Отправляем изменения на сервер
$ git push origin master

  Counting objects: 3, done.
  Writing objects: 100% (3/3), 210 bytes, done.
  Total 3 (delta 0), reused 0 (delta 0)
  To git@ec2-174-129-57-41.compute-1.amazonaws.com:django.git
    * [new branch]      master -> master

Все, новый репозиторий создан и доступен для клонирования из Gitolite

Продолжение: Настройка сервера. Создаем и разворачиваем django-проект

Год облачного хостинга от Amazon — бесплатно

2011-11-11T00:00:00+04:00

Содержание:

Бесплатный период использования сервиса от AWS
Регистрация на Amazon Web Services
Создание и запуск VPS
Привязка IP и настройка DNS
Подключение к серверу

Note

Amazon Web Services инфраструктура Web Services платформы в облаке, представленная компанией Amazon в начале 2006 года. В данной инфраструктуре представлено много сервисов для предоставления различных услуг, таких как: Amazon EC2 аренда виртуальных сервисов, Amazon SimpleDB облачная база данных, Amazon S3 файловый хостинг и множество других.

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

Облачный хостинг имеет ряд преимуществ перед прочими решениями:

Гибкая ценовая политика, вы платите только за то, что используете;
Легкое масштабирование проектов;
Отказоустойчивость.

В случае AWS к преимуществам добавляется:

Огромное количество доступных образов систем;
Удобные интерфейсы управления (включая консольные и GUI утилиты);
Автоматический load-ballancer;
И еще множество полезнейших опций, перечислять которые я сейчас просто не возьмусь.

В данной статье мы создадим и запустим бесплатную VPS на Amazon с выделенным IP-адресом и прикрепленным доменом. В следующих статьях я покажу как настроить на ней Git хостинг для ваших репозиториев и поднять Django проект с автообновлением кода. Все вместе не должно занять у вас более нескольких часов.

Итак поехали.

Бесплатный период использования сервиса от AWS

Для новых зарегистрированных пользователей Amazon предоставляет программу бесплатного использования AWS Free Usage Tier сроком на год. Вкратце она включает в себя:

750 часов работы VPS t1.micro в месяц (читаем 1 VPS в месяц бесплатно);
10 ГБ гарантированного места бесплатно;

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

Регистрация на Amazon Web Services

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

Кредитная карточка Visa или MasterCard (нужна только для проверки);
Работающие email и мобильный номер для подтверждения.

Ссылка для регистрации: https://aws-portal.amazon.com/gp/aws/developer/registration/index.html

Я лишь коротко опишу этот процесс:

На первых шагах вы создадите аккаунт на AWS, введя свои электронную почту, пароль и адрес;
После создания и подтверждения аккаунта пройдите по ссылке: https://aws-portal.amazon.com/gp/aws/developer/subscription/index.html?productCode=AmazonEC2 и подпишитесь на услуги EC2;
В процессе подписки вас попросят ввести данные кредитной карты (с нее будет произведено пробное списание, с возвратом) и пройти верификацию вашего мобильного телефона (вам позвонит робот и попросит ввести код подтверждения в режиме тонального набора)

Note

Вы можете спокойно подписываться на все услуги AWS. Это облачный хостинг и деньги с вас снимут только по факту реального использования услуг.

Если все прошло успешно вы можете пройти в консоль управления вашими сервисами от Amazon: https://console.aws.amazon.com/ec2/

Создание и запуск VPS

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

Note

У вас ведь есть своя пара rsa ssh ключей? Если да, то рекомендую выбрать Key Pairs и нажав кнопку Import Key Pair загрузить публичную часть вашего ключа на AWS.

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

Я буду устанавливать Ubuntu и воспользуюсь для этого замечательным сайтом: http://alestic.com/. Образы доступные на нем уже оптимизированы под AWS.

Выбираем из табов регион для создания вашей системы. Выбираем образ с загрузкой по EBS (это гарантирует вам сохранность данных если сервер по каким либо причинам будет остановлен) и нажимаем на кнопку рядом с 32 или 64-битной версией для перехода в консоль AWS.

Откроется окно с выбранной системой, нажимайте кнопку <Continue> (обратите внимание, что для бесплатного периода Instance type вашей системы должен быть t1.micro, он выбран по умолчанию).

Когда вы дойдете до этапа создания ключей (Create Key Pair) вы сможете выбрать ключ из уже загруженных ранее или создать новый. Во втором случае сохраните полученный ключ на свой компьютер.

Следующий этап Configure Firewall управление политиками безопасности. Политика безопасности (Security Group) регламентирует какие порты и типы соединений открыты наружу на вашем сервере.

Создайте новую группу и откройте порты TCP 22, 80 для доступа по SSH и WWW.

Заканчивайте настройку и запускайте ваш сервер: Launch.

Запуск займет некоторое время в течении которого статус сервера изменится на running.

Привязка IP и настройка DNS

При выделении сервера в нижней части страницы показывается область информации, в том числе и DNS адрес.

Адрес по-умолчанию не слишком удобен для работы, например ec2-184-72-89-43.compute-1.amazonaws.com, поэтому далее мы привяжем более удобную DNS запись.

Для начала нужно привязать к нашей VPS постоянный IP адрес. Откройте в вашей консоли пункт меню Elastic IPs и нажмите кнопку Allocate New Address для выделения вашим серверам нового постоянного IP-адреса.

После создания адреса, его необходимо привязать к нашему серверу. Нажимаем Associate Address в появившемся окне, в выпадающем списке, выбираем нашу VPS и подтверждаем привязку. Все, теперь наш сервер доступен по данному IP и мы можем привязать к нему DNS.

Если у вас уже есть свой домен, то вы можете сразу прописать A-запись для связывания его с полученным выше IP-адресом. Если нет, то я предлагаю получить бесплатный, с помощью сервиса FreeDNS. Вообще, это обычный DNS-провайдер продающий регистрацию доменов и услуги по их сопровождению, но у его клиентов есть уникальная возможность расшаривать поддомены третьего уровня для бесплатного использования всеми желающими. Нет никаких гарантий, что клиент не остановит обслуживание корневого домена второго уровня, но например mooo.com существует с 2001 года. Вкратце, данный сервис позволит вам получить бесплатный домен третьего уровня с бесплатным хостингом DNS. Например: для данной статьи я создам awsdemo.us.to.

Итак, регистрируйтесь на FreeDNS, заходите в консоль управления на вкладку Subdomains и нажимайте добавить.

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

Подключение к серверу

После запуска мы можем подключиться с помощью SSH к нашему серверу awsdemo.us.to. Учтите, что пользователь по умолчанию на образах с http://alestic.com/ — ubuntu.

Если вы предварительно загрузили свои ключи:

ssh ubuntu@awsdemo.us.to

Или с использованием полученного ключа от Amazon:

# (Для ключа с именем test.pem)
# Устанавливаем необхожимые права
chmod 400 test.pem

# Подключаемся с полученным ключом
ssh -i test.pem ubuntu@awsdemo.us.to

В случае успеха вы должны попасть в терминал вашего запущенного сервера, поздравляю!

Note

Обязательно загляните в замечательную справку AWS: http://aws.amazon.com/documentation/ec2/

Продолжение: Настройка сервера. Gitolite — хостинг git-репозиториев

VIM плагин для комфортной работы с python

2011-10-10T00:00:00+04:00

Содержание:

Python-mode screencast

В своей работе я использую редактор VIM. Я довольно долго шел к этому выбору, перепробовав множество решений. Мне сразу не понравились большие IDE, вроде Eclipse (и основанных на нем систем) или IDEA. Во-первых это JAVA и медлительность, хотя в последнее время ситуация улучшается. Во-вторых сложность самостоятельного расширения функциональности. Меня почти устраивали Textmate (osx) и его аналог E-texteditor (windows) с которыми я проработал продолжительное время, но так случилось, что судьба свела меня с VIM :)

Не буду разводить холивар и расписывать все его достоинства, опишу лишь основные преимущества сыгравшие для меня важнейшую роль.

Легкая расширяемость. Расширения кроме несложного встроенного vimlang, можно писать практически на чем угодно: python, ruby, tcl, shell.
Независимость от настроенной рабочей системы. Дайте мне терминал и я в пару команд получу на нем работающий VIM с моими настройками и плагинами. Именно поэтому VIM-еры работают на удаленных терминалах также комфортно как и на локальной машине.
Мощность. При казалось бы простоте и аскетизме VIM очень гибко настраивается. Я еще не встречал функциональности в IDE которой бы не мог при желании получить в VIM.
VIM-modes. Да именно инопланетный режим работы VIM стал для меня наибольшим плюсом. У меня нет мышки, ни дома, ни на работе. Пальцы всегда на буквенном блоке клавиатуры. Это сложно объяснить, но когда к этому привыкаешь становится трудно работать по другому.

Ну, а самый большой минус VIM конечно же — кривая вхождения. С этим редактором надо съесть пуд соли, но если вы подружитесь он оправдает все ожидания.

Python-mode screencast

Для работы с python я написал отдельный плагин. Его главное достоинство в том, что он не требует установки в систему используемых python библиотек (Pylint, Pyflakes и Rope). Вот его основные возможности:

Вывод python-документации в отдельном окне;
Запуск текущего кода и вывод результата в отдельное окно;
Проверка кода библиотекой Pylint или Pyflakes (автоматически или вручную);
Умное автодополнение, переход к определениям объектов, рефакторинг и множество других фич библиотеки Rope.
Автоматическая поддержка Virtualenv.
И еще несколько полезных мелочей для python.

Чтобы продемонстрировать работу плагина я снял небольшой скринкаст (извиняюсь за качество, это мой первый опыт). Итак Python-mode:

Скачать плагин можно с Github: https://github.com/klen/python-mode

Также там можно посмотреть мою конфигурацию этого замечательного редактора: https://github.com/klen/.vim

Если вы заинтересовались VIM и хотите узнать о нем побольше, советую посмотреть к примеру эти скринкасты:

http://www.derekwyatt.org/vim/vim-tutorial-videos/vim-novice-tutorial-videos/

Urbanairship, push-уведомления для мобильных приложений

2011-07-16T00:00:00+04:00

Содержание:

Регистрация и создание приложения
Отправка push-уведомлений
Заключение

Note

Статью про самостоятельную реализацию IOS Push смотрите здесь. Самостоятельная серверная реализация Android Push рассматривается тут

Разрабатывая мобильные приложения рано или поздно сталкиваешься с необходимостью оперативного оповещения клиентов о происходящих на сервере изменениях. Клиентское приложение иногда связывается с сервером и получает данные которые его ожидают. Но что делать если приложение не соединено с сервером или выключено, а оповестить о событиях необходимо?

Для этого практически для всех популярных мобильных платформ (ios, android, blackberry) компаниями-разработчиками реализована функциональность Push-уведомлений.

Push-уведомления — сообщения которые сервер отправляет клиенту для информирования его о новых данных. Например это может быть новое сообщение от знакомого, изменение статуса заказа, появление определенного товара и так далее.

Note

Для веб-приложений вариант реализации push-уведомлений описывается в статье: Создание сервера оповещений с использованием Tornado и Socket.IO

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

Данный сервис позволяет пользоваться едиными API для отправки уведомлений на apple, android, blackberry устройства. Позволяет вести статистику и пользоваться отладочной консолью. Без сложностей переключаться между боевым и разработческим режимами отправки. И самое главное демократичной ценовой политикой https://urbanairship.com/pricing/. Бесплатное ограничение в миллион уведомлений в месяц покроет большинство небольших проектов, а если ваше приложение перерастет этот порог то $0.001 за уведомление (2.8 копейки) при превышении не должно составить трудностей и это значительно дешевле SMS-сообщений.

В данной статье рассматривается работа c Urbanairship на примере iPhone push-уведомлений.

Регистрация и создание приложения

Регистрируемся на http://urbanairship.com, при регистрации вас попросят указать адрес для платежей и действующие данные кредитной карты.
Перед созданием приложения на Urbanairship нам необходимо получить push SSL сертификат. Идем на iOS Provisioning Portal и получаем Development и Production Push SSL Certificate в формате *.cer. Получив их на любое Apple Mac устройство конвертируйте в Personal Information Exchange (.p12) формат.
Теперь мы готовы зарегистрировать наше приложение на Urbanairship. Идем по адресу https://go.urbanairship.com/apps/ и создаем два новых приложения ( example-production, example-development ) выбирая соответственно Production или Development режимы и загружая соответствующие сертификаты. Для каждого из режимов записываем Application Key и Application Master Secret они нам понадобятся для работы с API.

Note

Рекомендуется создавать по отдельному приложению для production и development режимов.

Отправка push-уведомлений

Реализуем с помощью python механизм push-уведомлений для нашего приложения. Прежде всего рассмотрим каким образом это все реализовано на примере IOS устройств.

Для работы службы уведомлений требуется IOS 3.0 или выше, подключение к Интернету и поддержка в вашей мобильной программе. Чтобы получать уведомления от программы, ее необходимо открыть как минимум один раз. Когда IOS устройство находится в активном режиме (экран включен) прием уведомлений осуществляется в любое время, в противном случае через каждые 15 минут.

Для отправки уведомления на устройство сервер должен знать Device token который приложение получает при регистрации в Apple Push Notification Service. В уведомлениях можно использовать звуки, значки, текстовые сообщения.

Note

Urbanairship push documentation

Резюмируя:

Приложение должно зарегистрироваться в Apple и получить Device Token;

Приложение должно сообщить Device Token серверу (например

http-заголовком);

Для отправки уведомления сервер делает http запрос к API Urbanairship, с JSON данными.

Реализация на python (django) может выглядеть следующим образом:

from urllib import urlencode
from urllib2 import urlopen, Request, URLError

from django.utils import simplejson
from django.conf import settings
from celery.decorators import task

@task(ignore_result=True, max_retries=3, default_retry_delay=10)
def send_ios(message, sound=None, device_token=None):
    """ Send IOS push notification
        with urbanairship service.
        Celery async task.
    """
    if isinstance(message, basestring):
        message = dict(alert = message)

    if device_token:
        try:
            return urlopen(Request(
                settings.URBANSHIP_PUSH_URL,
                simplejson.dumps(dict(
                    device_tokens = [ device_token ],
                    aps = dict(sound=sound, alert=message.get('alert'),
                                data=message.get('data'))
                )),
                headers = {
                    'Authorization': 'Basic %s' % base64.b64encode(
                        "%s:%s" % (settings.URBANSHIP_APP_KEY,
                                    settings.URBANSHIP_MASTER_SECRET)),
                    'Content-type': 'application/json',
                },
            ), timeout=10)

        except URLError, e:
            _send_ios.get_logger().error("urbanairship server is unresponsible, cannot send ios notification")
            _send_ios.retry(exc=e)

Note

В данном примере я использовал Celery для выполнения асинхронного оповещения. Если на вашем проекте очереди задач не используются уберите декоратор task и обвязку кода отправки в try ... except.

В настройках проекта мы должны указать ключи: 'URBANSHIP_PUSH_URL, URBANSHIP_APP_KEY, URBANSHIP_MASTER_SECRET' полученные нами ранее. В своей разработке я стартую продакшен и дев сервера с разными настройками, соответственно с разными ключами для Urbanairship.

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

Использование:

# simple message
send_ios('Hello', device_token='FAKEDEVICETOKEN')

# message with sound
send_ios('Beep', sound='default', device_token='FAKEDEVICETOKEN')

# message with data
send_ios({
    alert = 'Some data',
    data = {
        order: 999,
        status: 'updated',
    }
}, sound='default', device_token='FAKEDEVICETOKEN')

Если отправка не происходит откройте приложение в Urbanairship в режиме просмотра и посмотрите сообщения в консоли (для отладки должен быть активирован чекбокс debug в настройках (production, development) приложения).

Заключение

Мы рассмотрели push-уведомления для IOS устройств, но фактически уже имеем поддержку android или blackberry. Необходимо только изменять JSON данные в запросе к API Urbanairship.

Мой опыт взаимодействия с Urbanairship на протяжении последних трех месяцев исключительно позитивный.

Urbanairship push documentation

Apple Push Notification Service Programming Guide

Android Cloud to Device Messaging Framework

Запуск django и других python проектов при помощи uwsgi+nginx

2011-07-15T00:00:00+04:00

Содержание:

Установка зависимостей
Конфигурирование и запуск
Запуск
Настройка django-проекта
Управление

Note

Редакция от 11/11/2011

Note

Статья описывает развертывание python-проектов на linux сервере с использованием nginx, supervisor, uwsgi. В интернете уже есть множество материалов на эту тему, ниже находится небольшая систематизация моего опыта.

Практически в каждом веб-проекте используется легковесный веб-сервер (nginx, lighthttpd и тд), как минимум для генерации статики. При этом довольно часто для динамической части проекта применяют apache + модули. В один момент мне надоело ставить nginx и apache одновременно и теперь я использую связку nginx + uwsgi из-за простоты развертывания, удобства обслуживания и быстродействия.

UWSGI — быстрый, легко настраиваемый сервер для WSGI приложений, написанный на C.

Далее я покажу как настроить и запустить python WSGI приложение (в том числе и с использованием Django).

Note

Сравнение производительности WSGI серверов: http://nichol.as/benchmark-of-python-web-servers

Установка зависимостей

Для начала необходимо установить nginx, uwsgi. Последние версии nginx уже содержат поддержку WSGI, поэтому вручную собирать ничего не надо.

~~Я предпочитаю устанавливать uwsgi с помощью pip.~~

Note

Рассмотрено для debian-based дистрибутивов. Права суперпользователя.

# nginx и uwsgi устанавливаем прямо из репозиториев
# для последних версий uwsgi неоюходимо дополнительно
# установить пакет: uwsgi-plugin-python
apt-get install nginx uwsgi uwsgi-plugin-python

Для управления uwsgi и множеством других процессов, я использую supervisor:

apt-get install supervisor

Note

Если вы получите ошибку ImportError поставьте python-модуль elementtree и повторите установку supervisor.

Конфигурирование и запуск

Note

Файлы с исходным кодом для данной статьи можно найти по адресу: https://github.com/klen/klen.github.com/tree/master/_code/uwsgi

Предположим у нас есть python-проект расположенный состоящий из очень простого WSGI приложения (wsgi.py):

def application(environ, start_response):
    status = '200 OK'
    output = 'Pong!'

    response_headers = [('Content-type', 'text/plain'),
                        ('Content-Length', str(len(output)))]
    start_response(status, response_headers)
    return [output]

Note

Здесь и далее предполагается, что корневой путь для проекта /home/klen/Projects/klen.github.com/_code/uwsgi

Создадим конфигурационный файл с настройками uwsgi для запуска нашего приложения: uwsgi.xml

Note

В данном примере рассмотрен XML формат, но можно использовать INI или параметры строки запуска

<!-- UWSGI XML Configuration File -->
<uwsgi>

    <!-- Сокет для передачи данных -->
    <socket>/home/klen/Projects/klen.github.com/_code/uwsgi/uwsgi.sock</socket>

    <!-- Путь к виртуальному окружению -->
    <!-- <home>/home/klen/Projects/klen.github.com/_code/uwsgi/.virtualenv</home> -->

    <!-- Нам понадобится включенный python плагин -->
    <plugins>python</plugins>

    <!-- Дополнительный python-путь -->
    <pythonpath>/home/klen/Projects/klen.github.com/_code/uwsgi</pythonpath>

    <!-- Модуль python с определением wsgi приложения -->
    <module>wsgi</module>

    <!-- Количество процессов -->
    <processes>10</processes>

    <!-- Максимальное количество соединений для каждого процесса -->
    <max-requests>5000</max-requests>

    <!-- Максимальный размер запроса -->
    <buffer-size>32768</buffer-size>

    <!-- Убивать каждое соединение требующее больше 30 сек для обработки -->
    <harakiri>30</harakiri>

    <reload-mercy>8</reload-mercy>
    <master />
    <no-orphans />

</uwsgi>

Создадим конфигурационный файл с настройками для supervisor: supervisor.conf

[program:example]
command=/usr/bin/uwsgi -x /home/klen/Projects/klen.github.com/_code/uwsgi/uwsgi.xml
user=www-data
stdout_logfile=/home/klen/Projects/klen.github.com/_code/uwsgi/logs/uwsgi.log
stderr_logfile=/home/klen/Projects/klen.github.com/_code/uwsgi/logs/uwsgi_err.log
directory=/home/klen/Projects/klen.github.com/_code/uwsgi
autostart=true
autorestart=true
redirect_stderr=true
stopsignal=QUIT

Note

Обычно я держу конфигурацию supervisor в проекте и создаю на нее симлинки в /etc/supervisor/conf.d

Настроим server в nginx:

upstream example.proxy {
    ip_hash;
    server unix:///home/klen/Projects/klen.github.com/_code/uwsgi/uwsgi.sock;
}

server {

    listen      4444;

    # В продакшен добавьте сюда свой домен
    # server_name example.com;

    access_log  /home/klen/Projects/klen.github.com/_code/uwsgi/logs/nginx_access.log;
    error_log   /home/klen/Projects/klen.github.com/_code/uwsgi/logs/nginx_error.log;

    # Статика у нас будет хранится в папк static в корне проекта
    location ^~ /static/ {
        root /var/www/example;
        expires max;
    }

    location = /favicon.ico {
        rewrite (.*) /static/favicon.ico;
    }

    location = /robots.txt {
        rewrite (.*) /static/robots.txt;
    }

    location / {
        uwsgi_pass  example.proxy;
        include     uwsgi_params;
    }
}

Запуск

Создадим ссылку на файлы конфигурации проекта для nginx и supervisor:

# создадим папку для логов
mkdir logs

# nginx
ln -s /home/klen/Projects/klen.github.com/_code/uwsgi/nginx.conf /etc/nginx/sites-enabled/uwsgi-example.conf

# supervisor
ln -s /home/klen/Projects/klen.github.com/_code/uwsgi/supervisor.conf /etc/supervisor/conf.d/uwsgi-example.conf

Дадим права на запись всем пользователям:

Note

По хорошему надо просто изменить владельца проекта на www-data.

chmod a+w -R /home/klen/Projects/klen.github.com/_code/uwsgi

Перезапустим nginx и supervisor:

/etc/init.d/nginx restart
/etc/init.d/supervisor stop
/etc/init.d/supervisor start

Если все прошло успешно, то перейдя по адресу: http://localhost:4444/ вы должны увидеть наше работающее приложение.

Настройка django-проекта

Для Django проекта вам необходимо просто изменить wsgi.py:

#!/usr/bin/env python
import os

from django.core.handlers.wsgi import WSGIHandler


os.environ['DJANGO_SETTINGS_MODULE'] = os.environ.get(
    'DJANGO_SETTINGS_MODULE', 'settings')

application = WSGIHandler()

Note

Предпологается, что проект находится в той же директории, в противном случае добавьте необходимые пути в sys.path

Управление

# Старт проекта
supervisorctl start example

# Перезапуск проекта
supervisorctl restart example

# Останов проекта
supervisorctl stop example

# Статус проекта
supervisorctl status example

Note

Также вы можете использовать параметр uwsgi touch-reload

Данный способ успешно применяется мной в боевой и девелоперской среде. Например так работают сайты http://intaxi.ru и http://venturebrothers.ru.

Django-markdown — поддержка Markdown в Django

2011-07-09T00:00:00+04:00

Содержание:

Установка
Подключение к проекту
Использование и настройка

Note

Markdown (маркдаун) — облегчённый язык разметки. Первоначально создан Джоном Грубером (англ. John Gruber) и Аароном Шварцем, целью которых являлось создание максимально удобочитаемого и удобного в публикации облегчённого языка разметки. Многие идеи языка были позаимствованы из существующих соглашений по разметке текста в электронных письмах. Реализации языка Markdown преобразуют текст в формате Markdown в валидный, правильно построенный XHTML и заменяет левые угловые скобки («<») и амперсанды («&») на соответствующие коды сущностей.

Иногда возникает необходимость использовать язык разметки для редактирования текстов. HTML редактировать руками при набивании текстов никто не хочет да это и не нужно, а вот какой нибудь wiki-синтаксис или Markdown интуитивно понятны программистам. Конечно секретаршу трудно обучить не GUI-евой разметке (хотя возможно), но если проект предполагает нечастые обновления силами квалифицированного персонала, Markdown становится очень удобен.

Для своих задач я написал Django-markdown — Django приложение позволяющее быстро и несложно подключить Markdown синтаксис на проект.

Список возможностей:

Поддержка Markdown синтаксиса в шаблонах;
Поддержка в стандартных Django-flatpages;
Поддержка в стандартном Django-admin;
Поддержка в формах и виджетах (wysiwyg).

Чаще всего я использую это приложение, когда на проекте есть Django-flatpages для удобства редактирования.

Note

Django-markdown предназначен для версии Django 1.3 и выше.

Установка

Приложение можно установить из PyPi

easy_install django-markdown

# Или с помощью pip

pip install django-markdown

Подключение к проекту

Необходимо добавить django_markdown в INSTALLED_APPS, settings.py:

INSTALLED_APPS += 'django_markdown',

И создать url в базовом url_config, urls.py:

url('^markdown/', include( 'django_markdown.urls')),

Note

Подключать URL необходимо если вы хотите использовать функционал предпросмотра в виджетах.

Использование и настройка

Использование в формах:

from django_markdown.widgets import MarkdownWidget

class MyMarkdownForm(forms.Form):
    content = forms.CharField( widget=MarkdownWidget() )

Note

Просто подключаем виджет к нужному полю.

В стандартном Django-admin:

from django_markdown.admin import MarkdownModelAdmin

adimin.site.register(MyModel, MarkdownModelAdmin)

Note

Все поля типа TextField будут выведены с использованием Markdown виджета

Django-flatpages:

# В вашем базовом url_config
from django_markdown import flatpages

... URLS ..

# Setup django admin and flatpages
admin.autodiscover()
flatpages.register()
urlpatterns += [ url(r'^admin/', include(admin.site.urls)), ]

Note

Мы импортируем flatpages из django_markdown вместо стандартного пути.

Настройка скинов wysiwyg (markitup по-умолчанию) settings.py:

MARKDOWN_EDITOR_SKIN = 'simple'

Note

Подробнее про настройку скинов и JS API читайте на сайте Markitup

Надеюсь это приложение и синтаксис будут вам полезны.

Настройка dnsmasq для локальной разработки (linux)

2011-07-08T00:00:00+04:00

Содержание:

Установка и использование Dnsmasq

В какой-то момент в процессе локальной разработки мне надоело постоянно редактировать /etc/hosts для тестирования очередного развернутого проекта. Появилось желание настроить "wild local dns" — например чтобы все днс вида *.dev.me вели на localhost. К сожалению /etc/hosts не поддерживает записи вида *.bla.bla.bla. Поиск в интернете давал только ссылки на BIND9, настраивать который достаточно сложно. Но когда я уже был морально готов воевать с BIND9, мне на глаза попался более простой DNS сервер — Dnsmasq. С его использованием задача сильно упрощается, буквально до нескольких команд.

Установка и использование Dnsmasq

debian-based (вам понадобятся root права):

# Устанавливаем dnsmasq
apt-get install dnsmasq

# Редактируем кнфигурацию dnsmasq
vim /etc/dnsmasq.conf
#   # Добавляем строку со своим "вируальным доменом для localhost"
#   address=/dev.me/127.0.0.1

# Перезапускаем сервис
/etc/init.d/dnsmasq restart

# Все, наши локальные поддомены готовы.
ping dev.me
ping something.dev.me
ping another.domain.dev.me

Все работает!

Создание сервера оповещений с использованием Tornado и Socket.IO

2011-07-06T00:00:00+04:00

Содержание:

Установка и настройка Tornadio
Создание приложения Tornado
Клиентская часть
Обработка подключений
Идентификация подключений
Использование

Структура современных веб-приложений зачастую включает в себя некие HTTP API с которыми работают подключенные к серверу клиенты. Обычно для них важно оперативно обновлять информацию о произошедших на сервере событиях.

Note

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

В данный момент на большинстве сайтов это реализуется постоянными AJAX запросами к серверу с клиентской стороны. У этого способа существуют недостатки:

Создается лишняя нагрузка на сервер;
Информация может приходить с задержкой;
Увеличивается трафик на клиенте.

В данной статье рассматривается способ с использованием WebSocket и Comet технологий. Мы создадим простейший сервер оповещений с использованием SocketIO и Tornadio. С клиентской стороны будет создаваться постоянное подключение к нашему серверу и в нужный момент мы будем посылать оповещения о событиях.

Note

SocketIO — javascript библиотека предоставляющая единый интерфейс для связи с Comet сервером с использованием множества протоколов (WebSocket, Flashsocket, XHR multipart и тд.).

SocketIO уже поставляется с модулем для nodejs. С его помощью можно реализовать необходимую функциональность на сервере используя JavaScript. В данной статье рассматривается решение с использованием Python.

Note

Tornadio — python библиотека надстройка над Tornado для поддержки интерфейса SocketIO.

Note

Для дальнейшего чтения предполагается, что вы знакомы с Python, VirtualEnv и JavaScript.

Установка и настройка Tornadio

Для начала создадим и активируем виртуальное окружение (VirtualEnv) для нашего сервера:

# Создаем директорию для сервера
mkdir -p ~/Projects/tornado_pushserver
cd ~/Projects/tornado_pushserver

# Создаем виртульное окружение
virtualenv .ve

# Активируем виртуальное окружение
source .ve/bin/activate

Устанавливаем в созданное окружение Tornado и Tornadio:

easy_install tornadio

Создание приложения Tornado

Напишем обработчик HTTP подключений к нашему серверу. Создадим и отредактируем файл handler.py:

import tornado.web


class BroadcastHandler(tornado.web.RequestHandler):

    def get(self):
        self.write('Hello from tornadio!')

Все, что он делает, это отдает строку 'Hello from tornadio!' при GET запросах.

Создадим основной файл приложения app.py

import tornado.web
from tornadio import server

from handler import BroadcastHandler


urls = [ (r"/", BroadcastHandler) ]

application = tornado.web.Application( urls )

if __name__ == "__main__":
    server.SocketServer(application)

Здесь мы создали Tornado application использующее наш обработчик соединений.

Note

Код для текущего состояния нашего сервера, вы можете посмотреть по адресу: https://github.com/klen/example_tornadio_project/tree/0.1.0

Запустите сервер с помощью команды python app.py и откройте в браузере http://localhost:8001 вы должны увидеть ответ сервера. Если все в порядке остановите его из консоли нажав Ctrl+C.

Клиентская часть

Создайте страницу для клиентов console.html:

<!DOCTYPE html>
<html>
    <script src="http://cdn.socket.io/stable/socket.io.js"></script>
    <script>
        window.onload = function(){
            var log = document.getElementById('log');

            var socket = new io.Socket(window.location.hostname, {
                port: 8001,
                rememberTransport: false
            });

            socket.connect();

            socket.addEvent('message', function(data) {
                log.innerHTML += '<p>' + data + '</p>';
            });
        };
    </script>
    <h2>Console client</h1>
    <div id='log'></div>
</html>

Разберем, что в ней происходит. Подключается SocketIO скрипт реализации протоколов. Создается объект socket с параметрами подключения к нашему серверу. Происходит подключение socket.connect. И все полученные от сервера сообщения выводятся в тело страницы.

Теперь подключим этот шаблон на стороне сервера, изменив handler.py:

class BroadcastHandler(tornado.web.RequestHandler):
    def get(self):
        self.render('console.html')

Note

Код для текущего состояния нашего сервера, вы можете посмотреть по адресу: https://github.com/klen/example_tornadio_project/tree/0.2.0

Снова запустите сервер и подключитесь к нему в браузере: http://localhost:8001 Через какое то время в вы увидите ошибки в консоли. Они вызваны тем, что протоколы SocketIO у нас сейчас никто не обрабатывает. Выключите сервер и давайте создадим обработку подключений.

Обработка подключений

Создайте файл connection.py:

import logging
from tornadio import SocketConnection


class ClientConnection(SocketConnection):
    clients = set()
    def on_open(self, *args, **kwargs):
        logging.warning('client connected')
        self.clients.add(self)

    def on_close(self):
        logging.warning('client disconnected')
        self.clients.remove(self)

    # **

Здесь мы создали класс для наших подключений. При подключении он сохраняет ссылку на себя в ClientConnection.client. При разрыве соединения удаляет.

Подключим его в наше приложение app.py:

import tornado.web
from tornadio import server, get_router

from connection import ClientConnection
from handler import BroadcastHandler


urls = [ (r"/", BroadcastHandler), get_router(ClientConnection).route() ]

application = tornado.web.Application( urls )

if __name__ == "__main__":
    server.SocketServer(application)

Сейчас мы создали ресурс SocketIO для клиентских подключений.

И доработаем на handler.py для отправки сообщений подключенным клиентам:

import tornado.web
from connection import ClientConnection


class BroadcastHandler(tornado.web.RequestHandler):

    def get(self):
        self.render('console.html')

    def post(self):
        message = self.get_argument('message')
        for client in ClientConnection.clients:
            client.send(message)
        self.write('message send.')

Мы добавили обработчик POST запросов, отправляющий сообщения нашим подключениям.

Note

Код для текущего состояния нашего сервера, вы можете посмотреть по адресу: https://github.com/klen/example_tornadio_project/tree/0.3.0

Запустите сервер и откройте несколько страниц по адресу http://localhost:8001 В консоли сервера вы должны увидеть сообщения о подключении. Давайте попробуем отправить сообщения подключенным клиентам с помощью POST запросов к нашему серверу.

curl localhost:8001 -d message=Ping
curl localhost:8001 -d message=Another_ping

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

Идентификация подключений

Есть несколько вариантов идентифицировать клиент. Например можно запрашивать пользовательскую сессию если она существует. Сейчас мы просто будем сообщать случайно генерированный ID серверу после подключения. Доработаем немного console.html:

<!DOCTYPE html>
<html>
    <script src="http://cdn.socket.io/stable/socket.io.js"></script>
    <script>
        window.onload = function(){

            var log = document.getElementById('log');

            var socket = new io.Socket(window.location.hostname, {
                port: 8001,
                rememberTransport: false
            });

            // register client
            socket.addEvent('connect', function(e){
                log.innerHTML += '<p>Connected.</p>';
                socket.send({
                    id: Math.floor(Math.random(1000) * 1000)
                });
            });

            socket.connect();

            socket.addEvent('message', function(data) {
                log.innerHTML += '<p>' + data + '</p>';
            });
        };
    </script>
    <h2>Console client</h1>
    <div id='log'></div>
</html>

Мы добавили реакцию на событие connect и отправляем на сервер информацию о нашем текущем ID.

Добавим обработку идентификатора в наш класс подключений connection.py:

from tornadio import SocketConnection
import logging


class ClientConnection(SocketConnection):

    clients = set()

    def __init__(self, *args, **kwargs):
        self.id = None
        super(ClientConnection, self).__init__(*args, **kwargs)

    def on_open(self, *args, **kwargs):
        logging.warning('client connected')
        self.clients.add(self)

    def on_message(self, message):
        logging.warning(message)
        if not self.id:
            self.id = message.get('id', None)
        self.send('Hello client %s' % self.id)

    def on_close(self):
        logging.warning('client disconnected')
        self.clients.remove(self)

    # **

Теперь при получении сообщения, мы регистрируем идентификатор клиента.

И добавим функциональности в handler.py:

import tornado.web
from connection import ClientConnection


class BroadcastHandler(tornado.web.RequestHandler):

    def get(self):
        self.render('console.html')

    def post(self):
        message = self.get_argument('message')
        key = self.get_argument('id', None)
        for client in ClientConnection.clients:
            if key and not key == client.id:
                continue
            client.send(message)
        self.write('message send.')

Сейчас мы проверяем запрос на наличие параметра id и в этом случае отправляем сообщение только конкретному подключенному клиенту.

Note

Код для текущего состояния нашего сервера, вы можете посмотреть по адресу: https://github.com/klen/example_tornadio_project/tree/0.4.0

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

Console client

Connected.

Hello client 63

Отправим несколько сообщений:

curl localhost:8001 -d message=Hello_all
curl localhost:8001 -d message=Hello_63&id=63

Note

Во-втором сообщении подставьте ID для одного из своих подключений

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

Использование

Итак сервер мы написали, каким образом его можно использовать? Например запустить на другом порту вашего основного домена и подключаться к нему с клиентских страниц. При этом если на основном сервере происходит какое то событие, делается POST запрос (в идеале асинхронный) к серверу оповещений который в свою очередь посылает сообщение клиенту. В качестве сообщения можно отправлять JSON с необходимой информацией.

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

Это несложно реализовать и вы можете доработать сервер самостоятельно.

В заключении я рекомендую вам почитать документацию SocketIO, Tornadio и возможно Tornado.

Простейшая реализация протокола JSONP

2011-07-05T00:00:00+04:00

Содержание:

Пример в действии:

Когда в веб-проекте необходимы кроссдоменные JSONP запросы, а подключать javascript фреймворки не хочется, можно воспользоваться этой простейшей реализацией:

// simplest JSONP request implementation
function jsonp (url, callback) {
    var name = "jsonp" +  +new Date,
        script = document.createElement("script"),
        head = document.getElementsByTagName("head")[0];
    window[name] = callback;
    script.src = url.replace(/=\?/, "=" + name);
    head.insertBefore(script, head.firstChild);
}

Пример использования (получение информации о пользователе с использованием API twitter.com):

var link = "http://api.twitter.com/1/statuses/user_timeline.json?screen_name=horneds&count=2&callback=?"

jsonp(link, function (data) { alert(data) });

Пример в действии:

Изменяйте значение поля ниже, на логин пользователя в твиттере, чтобы загрузить изображение его профиля.

Django-gitrevision, автоматическое обновление статики на клиенте

2011-07-04T00:00:00+04:00

Содержание:

Установка
Настройка и использование
Заключение

В современных веб-проектах, статические файлы (css, js ...) обычно жестко кешируются с целью экономики трафика и для предупреждения лишней нагрузки на сервер. В тоже время важно чтобы при обновлении статики, особенно JavaScript файлов, старые клиенты получили обновленную версию.

В моем проекте используется Git и Django. И вполне логично допустить, что актуальная версия статики зависит от номера последнего коммита в Git.

Поэтому когда такая проблема возникла, я взял и написал очень простое django-приложение для отслеживания текущего Git коммита в проекте.

Note

На текущий момент данное приложение неактуально тк я сделал http://github.com/klen/dealer Последний пакет поддерживает несколько систем контроля версий включая git и mercurial. И несколько python веб-фреймворков, а не только Django.

Установка

Приложение можно установить из PyPi

easy_install django-gitrevision

# Или с помощью pip

pip install django-gitrevision

Настройка и использование

Необходимо добавить gitrevision в INSTALLED_APPS, settings.py:

INSTALLED_APPS += 'gitrevision',

Если вы предполагаете использовать gitrevision шаблонах (для обновления статики, этого достаточно) добавьте в settings.py:

TEMPLATE_CONTEXT_PROCESSORS += 'gitrevision.context_processors.gitrevision',

И используйте переменную GIT_REVISION в шаблонах:

<link href="/test.css?{{ GIT_REVISION }}" rel="stylesheet" type="text/css" media="screen" />
<script src="/test.js?{{ GIT_REVISION }}"></script>

Если идентификатор коммита нужен во views, хотя мне трудно представить такую ситуацию, то подключите gitrevision в MIDDLEWARE_CLASSES.

MIDDLEWARE_CLASSES += 'gitrevision.middleware.GitRevision',

Использование в views:

def superview( request ):
    gitrevision = request.git_revision
    ...

В этом случае нет необходимости подключать CONTEXT_PROCESSOR так как в шаблонах идентификатор будет доступен через request.git_revision.

Note

Возможно вам понадобится добавить переменную с путем к вашему репозиторию в settings:

GIT_PATH = <path_to_your_git_repository>

Заключение

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

Теперь в текущих проектах у меня не возникает головной боли по поводу устаревшей версии статики на клиентах.

Создаем свой персональный сайт на Github.

2011-07-03T00:00:00+04:00

Содержание:

Введение
Использование генераторов статических сайтов
Установка и настройка Pelican
Автоматизация

Mало кто знает, что Github кроме превосходного хостинга ваших Git проектов может также хостить ваш персональный сайт. Например на нем расположен этот блог. В своей первой статье я расскажу как максимально удобно настроить эту функциональность.

Введение

Для начала вам нужно быть зарегистрированным пользователем Github и уметь работать с системой контроля версий Git. Предположим вы готовы.

Первое, что вам потребуется — это создать на Github репозиторий с именем вида: username.github.com, где username ваш логин на сервисе. Например для этого блога создан репозиторий http://github.com/klen/klen.github.com
Вторым шагом мы создадим локальный репозиторий и привяжем его к удаленному:

Note

В дальнейшем я буду приводить примеры для своего сайта: klen.github.com

mkdir ~/Projects/klen.github.com
cd ~/Projects/klen.github.com
git init
echo 'Hello world!' > index.html
git add .
git commit -m 'Initial commit'
git remote add origin git@github.com:klen/klen.github.com.git
git push -u origin master

Отлично, ваш статический сайт уже готов! В течении 10 минут он появится по адресу:: username.github.com. В дальнейшем он будет обновляться при коммитах в удаленный репозиторий.

Использование генераторов статических сайтов

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

Существует масса проектов генерации статических сайтов и блогов. При работе с ними фактически вы пишете страницы и статьи в удобном для вас формате, а затем генератор обновляет структуру сайта. По-умолчанию Github уже поддерживает написанный на ruby генератор Jekyll. То есть вам необязательно использовать только HTML синтаксис, из коробки вы можете писать в ваш сайт на Markdown. Подробнее читайте в документации Github Pages и Jekyll.

Я предпочитаю генерировать страницы локально и проверять результат без выгрузки содержания на Github. Мне привычнее работать с Python поэтому в качестве генератора сайта мной используется Pelican. Ниже я покажу как поставить его и настроить для работы.

Если вы предпочитаете ruby дальше можете не читать.

Установка и настройка Pelican

Предполагается, что вы знакомы с Python и VirtualEnv.

Так как мы будем использовать Pelican нам необходимо выключить встроенный в Github генератор Jekyll. Это делается добавлением в корень репозитория файла .nojekyll.

touch .nojekyll
git add .
git commit -m 'Disable Jekyll'

Теперь создадим и активируем виртуальное окружение для модулей нашего сайта:

virtualenv .ve_blog
source .ve_blog/bin/activate

Установим в созданный нами VirtualEnv генератор Pelican и необходимый для него движок шаблонов Jinja2:

easy_install pelican
easy_install jinja2

Мы будем держать исходники сайта в поддиректории source, а созданные статические страницы в корне репозитория, чтобы Github их видел. Создадим файл source/hello.rst с нашей первой статьей:

Hello world!
############

:slug: hello

Hello from Pelican!

Note

Я использую синтаксис RST, но вы можете использовать Markdown для своего сайта. Просто сохраняйте файлы с расширением *.md Pelican поддерживает и другие форматы, но надо ставить соответствующие модули.

И соберем статику:

pelican source -o .

Note

Опция -o . заставляет Pelican производить сборку статики в корне проекта.

Если все прошло успешно в корне проекта вы увидите несколько HTML файлов. Откройте index.html в браузере и посмотрите на ваш сайт.

Теперь наши изменения можно сохранить в Git и отправить на Github.

git add .
git commit -m 'Add virtualenv and setup pelican.'
git push origin master

Автоматизация

Настроим наш сайт и немного автоматизируем рутинные операции.

Создадим файл настроек нашего сайта source/settings.py:

AUTHOR = 'Kirill Klenov'
SITENAME = 'klen.github.com'
SITEURL = 'http://klen.github.com'

Note

Подробнее про настройки Pelican, можно прочитать в его документации.

Для упрощения сборки создадим sh-файл .compile

#!/bin/sh

PRJ_DIR=/home/klen/Projects/klen.github.com

VE_DIR=$PRJ_DIR/.ve_blog

# Modify path
OLD_PATH=$PATH
PATH="$VE_DIR/bin:$PRJ_DIR:$PATH"
export PATH

# Compile static files
pelican $PRJ_DIR/source -o $PRJ_DIR -s $PRJ_DIR/source/settings.py -v

# Return PATH
PATH=$OLD_PATH
export PATH

И дадим ему права на исполнение:

chmod +x .compile

Теперь в директории проекта можно вызывать ./.compile и собирать статику даже без активации виртуального окружения.

Следующим шагом создадим Git хук для автоматической генерации сайта при коммитах. Создадим и отредактируем файл .git/hooks/pre-commit:

#!/bin/sh

PRJ_DIR=/home/klen/Projects/klen.github.com

$PRJ_DIR/.compile

Note

Не забудьте сделать его исполнемым.

При каждом коммите изменений в репозиторий, проект будет пере-собран автоматически.

На этом нашу предварительную работу по созданию github-сайта можно считать оконченной. В дальнейшем стоит поподробнее прочитать документацию Pelican, модифицировать стандартную или создать собственную тему оформления и подключить какой нибудь сервис комментариев.

Note

Как нетрудно догадаться исходники этого блога расположены по адресу: http://github.com/klen/klen.github.com

Sorry dude. Page not found

2011-01-01T00:00:00+03:00