Впечатления от посещения EuroPython 2014 в Берлине (часть вторая)

Вторая и заключительная статья-обзор прошедшей в Берлине конференции EuroPython 2014 (обзор первых двух дней конференции можно прочитать тут). В этой статье пойдет речь про написание мультиязыковой Sphinx-документации, gevent, тестирование серверной инфраструктуры после деплоя, преимущества SOA-архитектуры, коварство getattr(), особенности работы с памятью в Python и многое другое.

День третий (Sphinx, gevent, DevOps risk mitigation)

Третий день начался с написания мультиязыковой Sphinx-документации. Данный доклад был весьма полезен для меня лично, потому что в рамках проекта, которым я сейчас занимаюсь, возникала задача поддержки двух языковых версий API документации — английской и русской, при этом хотелось бы сделать этот процесс как можно более простым и прозрачным. На самом деле все довольно просто. Есть такая замечательная GNU утилита gettext, которая активно используется для интернационализации различных OpenSource проектов (думаю, что про gettext все и так знают без пояснений), и есть замечательный пакет sphinx-intl. Из sphinx-овой rst-овой документации при помощи нехитрых команд готовятся *.po файлы, которые потом переводятся в специальном gettext-редакторе, и на основе которых делается документация sphinx под какой-то конкретный выбранный язык. Так же в докладе был упомянут SAAS сервис Transifex, который облегчает труд переводчиков. Насколько я понял, общий принцип работы сервиса такой — при помощи нехитрых консольных утилиток, можно загружать и скачивать файлы переводов на этот сервис, который предоставляет для переводчиков удобный Web-интерфейс для перевода текстов. Консольные утилитки для этого сервиса, насколько я понял, работают по принципу git push/pull. Сервис не бесплатный. Думаю всем заинтересовавшимся (кто сталкивался с проблемой интернационализации) смотреть видео доклада необязательно, достаточно полистать слайды, чтобы все понять.

Из интересных докладов, которые были в этот день: доклад про gevent (я посчитал важным сходить на этот доклад, потому что на gevent-е чуть более чем полностью построен WebDAV-сервис проекта, которым я занимаюсь). На самом деле ничего принципиально нового не рассказали, начали с вводной по реализации асинхронности на Python и закончили собственно gevent-ом. Если кто не знает, что такое gevent — тому данный доклад возможно покажется интересным, ну а тем, кто уже знаком с данной технологией — врят ли. Из услышанных интересностей: 1. web-микрофреймворк, целиком сделанный на gevent-е, с поддержкой PostgreSQL, 2. AMQP-библиотечка, также целиком сделанная на gevent-е.

Ещё был весьма занятный доклад «DevOps Risk Mitigation: Test Driven Infrastructure», про тестировании инфраструктуры в рамках процесса deploy-я. На самом деле никакой магии нет — собирается RPM-ка, раскатывается куда-то на тестовые машины, и далее автоматизированно через rsh заходим на эти машины и тестируем все что только можно, начиная от HTTP proxy и заканчивая системой сбора логов. Докладчик, весьма колоритный old school-ный админ, как я понял, не признает всяких этих puppet-ов / chef-ов / salt-ов, но зато осознает идею того, что для поддержания качества продукта, тестами должен покрываться не только лишь один код. На мой взгляд, идея верная, и это и правда то, к чему надо стремиться. Возможно не такими способами, как говорится в докладе, но тем не менее. Всем DevOps-ам — must see.

День четвёртый (защита исходников, SOA от Disqus, архитектура абстрактного debugger-а, dh-virtualenv)

День начался с замечательнейшего по полезности доклада «Multiplatform binary packaging and distribution of your client apps». Думаю многие программисты, кто пишет коммерческие приложения, хотя бы раз в жизни задумывались над проблемой: «они могут скопировать и прочитать наш код!». То есть иными словами возникает задача — поставлять продукт в зашифрованном виде, ну или же в виде бинарников, из которых выцепить и модифицировать исходный код достаточно проблематично. К слову, Dropbox, у которого PC клиент написан на Python, решает данную проблему довольно геморройно — они кладут в инсталлятор свою собственную патченную версию интерпретатора Python, которая умеет читать зашифрованные *.pyc файлы. Решение, предлагаемое в докладе:

• 1. cythonize-им исходники — переводим их в *.c
• 2. компиляем полученное в native extensions
• 3. собираем exe-шник при помощи PyInstaller-ра
• 4. Упаковываем в setup.exe/dmg/rpm/deb файл

Для больших деталей рекомендую посмотреть видео доклада и слайды. Естественно каждый из 4х описанных мною этапов в докладе разобран более подробно — приводятся образцы кода, как и что делать. Ну и конечно же стоит оговориться, что данного рода обфускация не спасает о реверсинженеринга, когда человек может заимпортить обфусцированный пакет и просто банально пробежаться по именам методов/переменных. Кстати, ещё по данной к теме рекомендую к прочтению вот эту статью (она упоминается в докладе).

Следующим был весьма неплохой доклад от одного из разработчиков Disqus. В докладе говорилось про преимущества SOA-архитектуры на примере сервиса Disqus. Cервис Disqus чуть более чем полностью построен на Django, точнее он разделен на кучу-кучу мелких микросервисов (REST API, worker-ы, cron-ы и т.п.), каждый из которых построен на Django. К слову, докладчик доступно объяснил почему именно Django, а не что-то другое — большое комьюнити, куча готовых решений + намного проще найти специалистов. Если смотреть на технологический стек, то у Disqus из основных компонент используется uwsgi, django, celery, postgreSQL в качестве базы и redis для кэша. Чтобы шарить общий код между своими микросервисами, я так понял, они собирают отдельные python-овские пакетики. Из плюсов SOA подхода:

• 1. независимая масштабируемость
• 2. простота deploy-я
• 3. простота работы с кодом

из минусов:

• 1. если меняется какой-то один API (например external API service), то приходится не забывать догонять под измененный API другие сервисы
• 2. как упоминалось чуть выше — тяжелее шарить общий код между сервисами

Python Debugger Uncovered — вот это очень классный доклад от разработчика PyCharm. Советую всем backend-разработчикам посмотреть для общей эрудиции, как устроен некий абстрактный дебаггер в вакууме. Никакой высокой магии нет, все дебаггеры сделаны по одному принципу и подобию при помощи нативных средств самого языка Python. Кстати, для справки, дебаггеры PyCharm и PyDev объединяются.

Ещё в этот день был очень стоящий доклад про tool-у dh-virtualenv от Spotify. Spotify в качестве основой production ОС используют Debian, и цель создания данной утилиты заключалась в том, чтобы объединить deploy проекта в виде deb-ок с инкапсулированным virtualenv-ом. Общий смысла какой — с одной стороны Debian адски стабилен, а Debian-пакеты удобны тем, что позволяют прописать все не-python-ячи зависимости (типо libxml), с другой стороны virtualenv удобен тем, что позволяет изолировать внутри себя python-ньи зависимости, и все эти зависимости будут самыми свежими пакетами, т.к. взяты с PyPI. Тулза dh-virtualenv позволяет объединить одно с другим, и грубо говоря, автоматизированно собирать deb-ки из текущего развернутого virtualenv-а. Ставится она кстати через обычный apt-get. Внутри проекта, помимо setup.py и requirements.txt создается директория debian, в которой описываются характеристики и зависимости deb-пакета (rules, control и т.п.), а для создания пакета нагоняется консольная команда dpkg-buildpackage -us -uc. virtualenv на конечной qa/prod машине ставить не надо, т.к. он автоматически скачивается и упаковывается утилитой при создании пакета.

Lightning Talks этого дня лично мне запомнился одним очень интересным докладом про то, почему не стоит злоупотреблять getattr().
Пример кода:

1
2
3
4
5
6
7
8
9
10
11
12

import random
 
class A(object):
    def get_prop(self):
        return getattr(self, 'prop', None)
 
class B(A):
    @property
    def prop(self):
        return random.chioce(['test prop1', 'test prop2', 'test prop3'])
 
print(B().get_prop())

Данный код будет выводить всегда None, т.к. исключение (из-за неправильного имени метода, т.е. random.chioce) будет игнорироваться внутри getattr.

День пятый (особенности работы с памятью, DB API, делаем Go из Python)

Доклад “Everything You Always Wanted to Know About Memory in Python But Were Afraid to Ask” лично мне, как человеку, сильно далекому от C/C++, и привыкшему мыслить более приземленными материями, было очень интересно послушать. Какие-то вещи я уже знал, какие-то вещи лишний раз освежил в памяти. Не буду останавливаться на деталях, скажу так — особенно интересно было послушать про существующие тулы, которые имеют реальное практическое применение (objgraph, профилировщик памяти guppy и т.п.), и про то, что в Python можно заюзать раличные либы, реализующие низкоуровневый malloc(), и какой профит будет от этих замен. В общем, лично я рекомендую всем посмотреть этот доклад. Так же в этот же день проходил ещё один крутой доклад на схожую тему — «Fun with cPython memory allocator». К сожалению, я на него не ходил, но судя по отзывам моих коллег — доклад весьма стоящий. Многие наверное сталкивались с проблемой, когда создаешь в Python список из большого количества строк строк, потом удаляешь его, а память не уменьшается. Вот про эту проблему рассказывается в докладе — как это, из-за чего и как с этим бороться.

Далее был весьма неоднозначный доклад «Advanced Database Programming with Python». Тем, кто в своей практике мало работал с базами данных — рекомендую послушать. Узнаете такие вещи, как уровни изоляции транзакций, например, и чем они отличаются друг от друга, а так же про python-ячью специфику работы с базами данных (согласно PEP 249 autocommit=0 де факто и commit-ы надо не забывать писать вручную) и про какие-то базовые вещи по оптимизации запросов. Доклад неоднозначный, потому что автор делает акцент на множестве весьма редких оптимизаций типо, как например генерить ID вставляемой записи в Python-е, а не полагаться на auto_increment/sequences БД. Это-то конечно хорошо, вот только опыт показывает, что наслушавшись таких докладов, некоторые программисты начинают преждевременно оптимизировать все и вся, и это в 99% случаев приводит к весьма плачевным последствиям.

И последним было выступление от создателя web сервера gunicorn. Рассматривалось 100500 существующих вариантов реализации мультизадачности в python, и новый 100501-ый вариант — библиотечка offset, привносящая в python функционал кроутин языка Go. Во время выступления я немного покопался во внутренностях данной библиотеки — судя по всему в основе данной либы лежит боле низкоуровневая реализация кроутин основанная на библиотеке fibers. Сама же offset привносит в язык более высокоуровневые обертки. Т.е. грубо говоря, позволяет писать программы на python сродни тому, как они бы выглядели бы в Go. В своем докладе автор как раз приводит примеры схожести кода реализации некой абстрактной задачи, написанного на Go и написанного на Python, но с использованием offset. В общем, всем тем, кому недостаточно существующего функционала тредов, tornado/twisted, asyncio, gevent и модуля multiprocessing — данная библиотека может показаться весьма интересной. Слушать же сам доклад особого смысла не имеет — лучше сразу лезть в код на github и пробовать.

Заключительные Lightning Talks в этот день мне запомнились докладом про HSTS. Очень полезная штука надо сказать, о которой мало кто знает. Фактически это HTTP response заголовок, который указывает браузеру всегда принудительно использовать HTTPS-соединение для данного хостнейма. Т.е. в дальнейшем если пользователь вбивает в браузере http://some-url.com, то браузер сам автоматически подставит https. Полезно и из соображений безопасности и и из соображений сокращения числа редиректов с HTTP на HTTPS, возвращаемых с сервера.

Беседы в кулуарах

На конференции было огроменное количество стендов от компаний, так или иначе связанных с Python (Google, Amazon, DjangoCMS, JetBrains, Atlassian и пр). К ним ко всем можно было подходить и общаться на разного рода интересующие вопросы. Мы довольно много общались с ребятами из Google (правда это было не на самой конференции, а на after party от Google). Из интересного — Python у них используется преимущественно во внутренних продуктах, ну разве что кроме Youtube-а. Так же они нам по секрету сказали, что разработчики Google не очень-то любят BigTable, и уже сейчас в лабораториях Google готовится к выпуску новая революционная БД (кодовое название Spanner), позволяющая делать распределенные транзакции на кластере, и при этом обладающая всеми плюсами NoSQL. По слухам, вроде как даже Open Source (в чем, конечно, есть большие-большие сомнения).

Так же общались с представителями DjangoCMS (тут ничего интересного, банальная незатейливая CMS на Django, можно установить на свой сервер, а можно использовать SaaS решение) и c представителями Amazon. Касательно последних, задал им вопрос, затронутый на конференции highload 2012го года, по поводу того, что пропускная способность инстансов довольно разная и непропорциональна типу инстанса (см. презентацию — 25ый слайд), но получил в ответ «ну это специфика виртуализации такая, мы не можем сказать почему, обратитесь в поддержку». Кстати, думаю многим будет интересно, ребята из Amazon раздавали анкеты с вопросами на Python-тематику. Уже сейчас не вспомню, то ли они призы разыгрывали, то ли хантили таким образом. В общем, вопросики весьма специфичные, из разряда «эти самые вопросы, которые никогда не встречаются на практике, но их любят задавать на собеседованиях в больших конторах»:

1. Which is called first when creating an object:

a. __create__
b. __new__
c. __init__
d. __del__

2. What is printed by the last statement in:

1
2
3
4
5
6

def foo(x, l=[]):
    l+=2*x
    print l
 
foo('a')
foo('bc')

a. ['a','b','c']
b. ['a','bc']
c. ['a','a','b','c','b','c']
d. ['a','a','bc','bc']

3. What does the last statement print?

1
2
3
4
5
6
7
8

class A(str):
    pass
 
a=A('a')
d={'a':42}
d[a]=42
 
print type(d.keys()[0])

a. str
b. A
c. dict
d. int

4. Which of the following will these 2 statements return on Python vesrion 2?

1
2

5 * 10 is 50
100 * 100 is 10000

a. True, True
b. True, False
c. False, True
d. False, False

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

P.S Опубликовал этот пост на хабре.

Теги: amazon, cython, debugger, devops, dh-virtualenv, django, europython, gevent, go, google, hsts, pycon, python, soa, sphinx

Опубликовать: