Мое видение первой версии

Mailr будет иметь быстрый и удобный веб интерфейс, которым будет удобно пользоваться на небольшом экране ноутбука, на большом мониторе и на iPad Mini, все эти девайсы у меня есть и хочется иметь единый настраиваемый интерфейс для них.

Mailr будет иметь gmail-совместимый режим через IMAP, чтоб можно было вернуться в любое время на gmail. Так как пока версия под мобильные телефоны не планируется, то этот режим будет тоже полезен, можно будет параллельно коннектиться к gmail привычным мобильным клиентом, если нужно. Кроме прочего с gmail за спиной проще начинать разработку и сконцентрироваться на удобном интерфейсе.

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

Также будут дополнительные функции.

Объединение цепочек писем. Google хорошо находит соответствие писем и цепочек, но иногда его алгоритмы не работают:

Возможность вручную объединить цепочки – это выход в таких ситуациях.

Markdown для написания писем. Мне нравится Markdown и reStructuredText и мне бы хотелось писать письма используя эти текстовые языки разметки, после конвертации они выдают отличный для чтения HTML. Текущий редактор писем в gmail для меня очень неудобный.

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

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

Вся почта в одном табе. Я использую Chrome и мне нравится, что он открывает “Настройки”, “Скачанные файлы”, “Расширения” в новых вкладках, а не окнах (раньше использовал Firefox – он многое открывает в новых окнах). У меня весь серфинг интернета живет в одном окне браузера, а вся почта, в идеале, хочется, чтоб жила в одной вкладке (включая все аккаунты)

Простой backup. Это важно для Open Source продукта, чтоб была возможность взять все данные (аккаунты, фильтры, цепочки) и перенести с одной инсталяции на свою локальную или на сервер своего проверенного друга-гика.

Следующие версии

Когда можно будет использовать Mailr c gmail в качестве IMAP сервера, то дальше мне хочется уйти все таки от gmail и использовать свой email адрес. И, скорее всего, следующим шагом будет интеграция с Mailgun. Поднять свой правильный почтовый сервер с антиспам-фильтром – дело не самое легкое, с Mailgun будет проще, тем более они не хранят письма у себя.

Дальше много мыслей для продолжения: поддержка других IMAP серверов, множественные аккаунты в одном табе, PGP шифрование, списки рассылок для друзей…

Напоследок

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

Стек технологий:

• Python 3, werkzeug, jinja2, sqlalchemy, lxml;
• PostgreSQL с его крутыми типами данных и не только;
• lessjs, jquery на фронтенде.

Да, только jquery – из-за архитектурного решения. Мне больше нравится писать Python код, а JavaScript хочется очень минимизировать, поэтому вместо модного REST и рендеринга на стороне клиента мне захотелось генерировать семантичный HTML на стороне сервера. Это полезно, например, для iPad Mini, в нем процессор слабее и памяти меньше, чем обычно на ноутбуках и десктопах. В будущем эта ситуация может измениться.

В этом проекте еще нужно многое придумать, многое реализовать, многое оптимизировать. В последнее время я занимался им очень интенсивно, но мой отпуск заканчивается и нужно возвращаться к работе, то есть времени на проект будет намного меньше. Очень хочется его довести до стадии, чтоб заменить наконец gmail :).

Open Source – это круто и мне всегда хотелось отдать дань этому сообществу. Если задуманное мной в этом email клиенте удастся реализовать и получится хороший продукт, то это будет отличный вклад.

P.S.

Статья была на хабре, но им не понравилась ссылка на демо %).

Примеры с цепочками писем, которые зацепили:

• Thunderbird и Thunderbird Conversations;
• Geary – gmail-подобный десктопный клиент;
• fastmail.fm – платная почта, которая какое-то время была под Opera Software.

И, конечно, смотрел на mailpile.is, но они пошли странным путем.

Транзакции для изоляции базы

В моем мозгу изоляция окружения для конкретного теста - это обязательное условие для существования хороших тестов. Для изоляции базы самый верный способ - это транзакции, они быстрые. В начале теста мы открываем транзакцию, а после прохождения теста делаем ее откат (rollback), ну и условие напрашивается само - не должно быть прерывания открытой транзакции. У нас вышло так, что в процессе бронирования было ручное управление транзакциями (это и есть прерывание), а тестов вокруг бронирования у нас было очень много (больше всего хотелось покрыть тестами именно этот процесс), поэтому мне пришлось придумывать свой механизм изоляции базы на основе ее копирования из шаблона. Хотя этот механизм был быстрее стандартного в django для этого случая, но он был медленнее и сложнее транзакций. Поэтому когда делался запуск тестов в несколько процессов, пришлось приложить больше усилий, чтоб все наши тесты хорошо работали.

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

Запуск в несколько процессов

Хорошие тесты - это те, которые запускаешь и через какое-то реальное время получаешь фитбек прошли или не прошли, для этого вообще-то тесты и вводятся. Если тесты запускаются долго, это плохо скажется на процессе тестирования в команде. Для меня реальное время - до 10 минут, меньше конечно лучше, но больше - это сигнал, что тесты нужно срочно ускорять. В какой-то момент количество тестов выросло до ~800, время 15 минут, всевозможные локальные оптимизации кода в тестах произведены, а время еще нужно было сокращать, т.к. тестов становилось все больше. Очень хороший скачек в ускорении тестов - это запуск в несколько процессов, хотя этот метод добавляет определенную сложность тестовой среде. Кроме изоляции базы на уровне процессов, также необходима изоляция всевозможных кешей, redis. У нас вышло все еще сложнее. Реализация тестовой среды как-то была совсем не готова к нескольким процессам и нужна была значительная переработка, которая в итоге состоялась. Мы перенесли всю логику изоляции всего на уровень TestCase, это нам дало возможность не только запустить тесты в несколько потоков, но также и опробовать разные пускальщики: nose2, pytest, но мы так и остались на nose первом. С каждым из пускальщиков были какие-то проблемы. pytest был очень медленным на наших тестах при распараллеливании. nose2 у нас какое-то время поработал на CI, но он зависал при исключениях в многопроцессорном режиме. У nose1 хоть и были проблемы с неработающими плагинами в multiprocess, но xmlunit отчет как-то прикрутили для CI, а без других обходились, главное что тесты работали значительно быстрее. На одном хакатоне мы опробовали запускать наши тесты на крутом серваке (с 24 ядрами, кажется), так у нас ~800 тестов проходили за пару минут в 20 процессов. Но самый большой прирост заметен обычно при 2-4 процессах. На моем ноутбуке в 4 процесса тесты проходили меньше 6 минут, но у меня реальных было 2 ядра и два виртуальных :)

Хорошо бы, чтобы тестовая среда была готова к запуску в несколько процессов, благо если учесть, что используются транзакции в тестах, то решается это довольно легко, проект-шаблон доступен на github.

Mocks

Опять же в моем мозгу сидит, что все внешние вызовы должны быть “замоканы” для того чтоб тесты были предсказуемые и быстрые. Даже самый быстрый и надежный сторонний сервис может дать сбой или ответить каким-то не совсем ожидаемым способом, и тогда тесты упадут. Но тесты не должны падать из-за внешних условий, поэтому мы подменяем действительность моками и прописываем те ответы, которые мы ожидаем в тестах. Есть еще ряд случаев, в которых без моков не обойтись, это могут быть разные моменты со временем, проверка на прошлое или будущее, проверка выпадения исключений и т.п. В общем в проекте с тестами скорее всего будут моки, у нас их было много.

Хоть мы имеем дело с динамическим языком python и модуль mock очень помогает нам, но моки - это в своем роде магия, и у модуля mock есть свои нюансы и ограничения, про которые не все разработчики знают. Время от времени моки становились проблемой, особенно когда их сайд-эффекты сложно было определить и особенно у тех разработчиков, которые мало общались с моками. К ним нужно привыкнуть, с опытом их использовать и чинить становится проще.

Зависимость тестов от фикстур

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

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

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

Следите за своими тестами

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

Следите за своими тестами и пусть они вам помогают писать хороший код.

Maximus

Декорация окон. Когда окно не развернуто на весь рабочий стол, то в декорациях есть смысл: потянуть за заголовок, растянуть окно. А вот когда окно максимизировано, то частично смысл в декорациях теряется, да еще и место занимают. Действия типа: скрыть окно (Alt+F9), закрыть окно (Alt+F4), максимизировать (Alt+F10) хорошо выполняются через быстрые клавиши. Поэтому убираем декорацию окон, когда они максимизированы. Для этого есть пакет maximus в debian:

$ aptitude install maximus

По умолчанию maximus разворачивает все окна на весь экран. Есть вариант прописывать exclude_class, но я поступил по-другому - отключил максимизацию:

$ gconftool -s /apps/maximus/no_maximize --type bool true
$ gconftool -R /apps/maximus
 undecorate = true
 binding = disabled
 exclude_class = [Totem,Gnome-system-monitor]
 no_maximize = true

Т.е. максимизировать окна буду вручную через Alt+F10.

В общем уже неплохо, но ряд приложений после запуска нужно сразу максимизировать, т.к. они не хотят запоминать своих размеров и положения… Лишние телодвижения: запустить, нажать Alt+F10, а хочется просто запустить.

Devilspie

И тут на помощь приходит devilspie. Он может работать не только с классами окон (exclude_class из maximus - это список классов окон), но и может проверить имя приложения, класс и имя окна и еще ряд атрибутов. Причем может проверить атрибут не только на соответствие, а и на содержание (contains) и соответствие регулярному выражению. Действия над окнами тоже разные: maximize, unmaximize, focus и undecorate даже :).

Инструмент нашли, дальше используем.

$ aptitude install devilspie

Создаем файл ~/.devilspie/common.ds. И помещаем туда что-то типа:

 1 (begin
 2     ;(debug)
 3     (if
 4         (or
 5             (contains(application_name) "Vim")
 6             (contains(application_name) "Terminal")
 7             (contains(window_name) "New Tab - Google Chrome")
 8             (contains(window_name) "FatRat")
 9             (contains(window_name) "Document Viewer")
10             (contains(window_name) "Clementine")
11             (is(window_name) "DreamPie")
12         )
13         (maximize)
14     )
15 )

И добавляем devilspie в автозагрузку.

Обычно работаю с конфигом ~/.devilspie/common.ds следующим образом. Добавляю строку с дебагом (например: убрать “;” в начале строки №2 в приведенном выше листинге), убиваю процесс devilspie и запускаю его в терминале. В терминал начинают писаться атрибуты окон. Пример сессии:

$ killall devilspie
$ devilspie

 Window Title: 'naspeh@free: '; Application Name: 'Terminal'; Class: 'Gnome-terminal'; Geometry: 1280x774+0+3
 Window Title: 'pusto.org: Edit for fun - Iceweasel'; Application Name: 'Iceweasel'; Class: 'Iceweasel'; Geometry: 1280x774+0+3
 Window Title: 'x-nautilus-desktop'; Application Name: 'File Manager'; Class: 'Nautilus'; Geometry: 1280x800+0+0
 Window Title: 'Bottom Expanded Edge Panel'; Application Name: 'Bottom Expanded Edge Panel'; Class: 'Gnome-panel'; Geometry: 1280x24+0+776
 Window Title: 'Top Expanded Edge Panel'; Application Name: 'Top Expanded Edge Panel'; Class: 'Gnome-panel'; Geometry: 1280x25+0+0

Потом открываю нужное мне окно, смотрю атрибуты, правлю конфиг, перезапускаю devilspie и так пока не будет все хорошо :).

Раз уж используем devilspie, можно с его помощью еще что-то замутить.

Например, Skype очень жутко ведет себя в linux. Один из боков: хочется чтоб окна чатов открывались в одном месте и одинакового размера. Если заниматься этим вручную, то тут нужно подгонять каждое новое окно чата мышкой, изрядно потыкав. И тут на помощь приходит действие geometry из devilspie.

Пример debug:

Window Title: 'Skype? 2.2 (Beta) for Linux'; Application Name: 'Skype? 2.2 (Beta) for Linux'; Class: 'Skype'; Geometry: 266x487+0+25
Window Title: 'Anastasie - Skype? Chat'; Application Name: 'Skype'; Class: 'Skype'; Geometry: 824x619+456+95

(if

    (and
        (contains(window_name) "Skype")
        (matches(window_role) "ConversationsWindow")
    )
    (geometry "800x675+365-0")
)

Для получения window_role использовал xprop, который содержится в x11-utils.

Итого

Есть действия, которые каждодневно повторяются, и если на них потратить немного времени и автоматизировать, то в конечном счете сэкономится пара ненужных телодвижений в день :). Как говорится: настрой свой linux под себя.

Напоследок скриншот экрана:

Makefile

Когда я работал в 42cc, в практике у нас было добавление Makefile в проект, куда записывались часто используемые команды, в итоге работа с проектом сводилась к:

make clean
make runserver
make test
make deploy

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

clean:
    -rm *~*
    -find . -name '*.pyc' -exec rm {} \;

runserver:
    PYTHONPATH=$(PYTHONPATH) python django-project/manage.py runserver

test:
    PYTHONPATH=$(PYTHONPATH) nosetests --with-django --django-settings=$(test_settings) $(module)

Есть с Makefile пара неприятных моментов:

• отступы в целях должны быть именно табами, а не 4 пробела. А с учетом специфики python и его рекомендаций были случаи, когда редактор был настроен на замену табов, и чтоб вставить таб, нужно было его копировать %);
• в задачу можно передавать параметры только через правку файла или задание переменных окружения, это основной минус.

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

Fabric

Потом я услышал про чудо библиотеку для деплоймента fabric и стал ее использовать. Но плодить fabfile.py, Makefile совсем не хотелось. Решил, что если использовать fabric для деплоймента, то почему бы не использовать ее и для частых локальных команд:

from fabric.api import local, run, cd


def run():
    '''Start development server'''
    local('PYTHONPATH=. paster serve --reload development.ini', capture=False)


def pep8(target='.'):
    '''Run pep8'''
    local('pep8 --ignore=E202 %s' % target, capture=False)


@hosts('root@pusto.org')
def deploy(restart=False):
    '''Deploy to remote server'''
    local('hg push', capture=False)
    with cd('/var/www/horosh/'):
        run('hg pull&&hg up')
        if restart:
            run('/etc/init.d/horosh force-reload')

Работа с консолью опять сводится к коротким командам:

fab clean pep8
fab run
fab deploy:True

В fabric мы уже можем передавать параметры при вызове задачи и это клево.

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

• специфика передачи параметров в задачи через двоеточие, не unix стиль;
• в зависимостях две либы: paramiko, pycrypto;
• пару раз пытался заюзать функции из fabric просто в коде, как обычную библиотеку (может так делать не надо было :), но все сводилось к тому, что нужно юзать fab команду или отказаться совсем;
• для меня было удивительным, что fabric (или paramiko) не подхватывает ~/.ssh/config (хотя ключи и known_hosts подхватывает). Т.е. в хостах нужно явно прописывать пользователя, когда пользователь на сервере не совпадает, чтоб задача отработала без паролей по ключам. Хотя этого пользователя можно прописать в настройках или задать через параметры.

В принципе это не критичные моменты, библиотека делает свое дело. Для разработки на винде, возможно, это лучшее решение, т.к. тут свой ssh клиент paramiko, но я - не на винде :).

“Чистый” python

Со временем понял, что из fabric мне больше всего нужны функции local и run, а мои методы деплоя простые и не нужна особенность fabric для работы с множеством серверов.

Итак, чтоб сделать local c перехватом вывода и без, нужно всего-то:

from subprocess import call, Popen, PIPE, STDOUT

# With capture
cmd = Popen('ls -la', shell=True, stdout=PIPE, stderr=STDOUT)
print(cmd.communicate()[0])

# Without capture
call('ls -la', shell=True)

Теперь можно вспомнить про argparse и его сабкоманды и уже можно создавать свои manage.py на чистой стандартной библиотеке.

А что будем делать с деплоем?

Все просто :) - использовать стандартный клиент ssh.

from subprocess import call

commands = '&&'.join(['ls -la', 'uptime'])
call('ssh pusto.org "%s"' % commands, shell=True)

Т.е. мы можем делать развертывание проекта при помощи стандартной библиотеки python и клиента ssh, который у меня точно есть под рукой.

Итого

Минимизация команд - это классный подход. Хочется обратить внимание на возможности стандартной библиотеки python и лишний раз задуматься, а стоит ли добавлять в зависимости проекта “жирную” библиотеку (аля fabric)…

P.S. Еще пара ссылок на инструменты касающиеся темы: doit, paver.

Подход 1. Класс-контейнер с тестами в виде методов, аля unittest

from unittest import TestCase

answer = 42


class TestAnswer(TestCase):
    def setUp(self):
        print('setup')

    def test(self):
        self.assertEquals(answer, 42)

    def tearDown(self):
        print('teardown')

Исторически сложилось, что unittest использует верблюжью нотацию для setUp, tearDown, assert* (assertTrue, assertEquals…) методов. Но в python есть PEP 8, в котором принято использовать подчеркивание в названиях функций (методов), и в nose.tools можно найти аналогичные функции, но с подчеркиванием (assert_true, assert_equals) для любителей PEP 8.

Подход 2. Модуль с тестами в виде функций

from nose.tools import assert_equal, with_setup

answer = 42


def setup_func():
    print('setup')


def teardown_func():
    print('teardown')


@with_setup(setup_func, teardown_func)
def test_answer():
    assert_equal(answer, 42)

В последнее время второй подход компоновки тестов мне все больше нравится. Почему?

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

  test_auth.py:TestAuth.test_login
  test_auth.py.test_login
  

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

  class TestAuth(TestCase):
      def test_login()
          ...
      def test_logout()
          ...
  

  но когда для test_login нужен setUp метод, а для test_logout нет, то тут приходится класс-контейнеры компоновать в зависимости от используемых SetUp, TearDown методов. В общем присутствует неоднозначность и это не очень хорошо :)

• в классе-контейнере забирается один отступ, а отступы ценны, когда соблюдаешь ограничение в 80 символов;

• в первом подходе класс наследуется от unittest.TestCase, при вызове каждого assert* метода логично обращаться к self и тут опять у нас крадут символы:

  self.assertEqual
  assert_equal...4
  

Для написания тестов можно использовать doctest

 1 answer = 42
 2 
 3 
 4 def test_answer():
 5     '''
 6     >>> answer
 7     42
 8     '''
 9     assert False

Выглядит кратко, хотя конечно такой формат тестов не всегда подходит…

Классная вещь assert

answer = 43


def test_answer():
    assert answer == 42

После запуска, вывод:

$ nosetest
======================================================================
FAIL: test.test_answer
----------------------------------------------------------------------
Traceback (most recent call last):
...
    assert answer == 42
AssertionError

Очень заманчиво: не нужен дополнительный импорт, лаконично. Но вот при выводе не известно какое значение содержит переменная answer. Правда тут может порадовать nose и даже двумя вариантами:

$ nosetests --pdb-failures
...
-> assert answer == 42
(Pdb) answer
43

приходится вводить answer - лишние телодвижения :).

Следующий вариант еще красивее:

$ nosetest -d
======================================================================
FAIL: test.test_answer
----------------------------------------------------------------------
Traceback (most recent call last):
...
    assert answer == 42
AssertionError:
>>  assert 43 == 42

так что, в принципе, тесты можно писать через assert без потери информативности вывода, нужно только использовать правильные “пускальщики”.

Более краткие сигнатуры

from nose.tools import eq_

answer = 43


def test_answer():
    eq_(answer, 42)

После запуска, вывод:

FAIL: test.test_answer
----------------------------------------------------------------------
Traceback (most recent call last):
...
    eq_(answer, 42)
AssertionError: 43 != 42

Заменили assert_equal на более короткий вариант eq_, вывод ошибки будет полностью аналогичен. Т.е. при выводе увидим, что answer на самом деле 43 и пойдем сразу искать ошибку в коде. Один нюанс, что тесты не заканчиваются проверкой на eq_ и ok_, которые есть в nose.tools, набор методов нужен более обширный…

Интересное по теме

• pytest - это аналог nose, со своими “плюшками”, он умеет запускать большинство тестов написанных для nose.

• attest - интересный подход (python way) от известной команды Pocoo. Пример из документации:

  from attest import Tests
  math = Tests()
  
  @math.test
  def arithmetics():
      """Ensure that the laws of physics are in check."""
      assert 1 + 1 == 2
  
  if __name__ == '__main__':
      math.run()
  

• Oktest для лаконичности - идея прикольная. Пример из документации:

  from oktest import ok
  
  ok (x) > 0                 # same as assert_(x > 0)
  ok (s) == 'foo'            # same as assertEqual(s, 'foo')
  ok (s) != 'foo'            # same as assertNotEqual(s, 'foo')
  

Итого

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