Светлячный Dev Лог

Исправление работы django-kombu с InnoDB

2011-12-26T03:42:00Z

Наверное многие из вас используют django-celery, или хотя бы слышали про этот инструмент для асинхронного выполнения задач. В самом простейшем случае, когда нет желания взводить дополнительные redis или AMQP сервера, очередь задач организуется через уже имеющуюся базу данных. В моем случае это был MySQL.

В случае, когда очередь организуется через базу, Celery использует специальный бэкенд django-kombu, который устроен довольно просто — при добавлении сообщения, оно сериализуется и кладется в табличку БД, при операции pop, запись из базы изымается. Такой вот AMQP для бедных.

Итак, я использовал MySQL и celery работал отлично до тех пор, пока не было принято решение сконвертировать все таблички в InnoDB дабы использовать транзакции. После такого изменения, celery перестал "подхватывать" новые задачи и выполнял их только после рестарта.

В интернетах предлагалось три решения этой проблемы:

откатить все таблички django-kombu обратно на движок MyISAM;
установить в конфиге MySQL ISOLATION LEVEL READ-COMMITTED;
раскомментировать некую строчку в сорцах django-kombu, после чего он станет переоткрывать коннекты к базе при каждой операции.

Объясню, почему все три никуда не годятся.

Вариант, предлагающий держать часть табличек в MyISAM, лишает нас транзакционности.
Установка иного ISOLATION LEVEL, глобально или в рамках сессии, может привести к некоторым "спецэффектам" при выполнении задач, рассчитанных на более строгую изоляцию.
Переустановка соединения с базой каждый раз — просто грязный хак, замедляющий работу очереди в несколько раз.

Пришлось лезть в кишки django-kombu и править все самому. Оказалось, что по время опроса очереди, библиотека держит коннект с базой открытым и все селекты выполняются в рамках одной длиииной трензакции. Это означает, что все сообщения, которые будут добавлены в очередь в процессе, kombu не увидит из за того, что в MySQL по умолчанию установлен ISOLATION LEVEL REPEATABLE READ.

В итоге, я обернул несколько методов в декоратор commit_on_success, и всё заработало как надо. При этом небольшой тест показал производительность в 3 раза больше чем у версии с "грязным" хаком.

Попутно поправил еще один баг, связанный с тем, что celery завершала свою работу в случае, когда MySQL становился недоступен.

Создал Pull Request, но пока его не смерджили, исправления в моей ветке на GitHub.

GitHub в Цифрах

2011-10-15T09:20:00Z

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

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

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

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

А еще, можно сделать пузомерку для гиков, с медальками, рейтингами и титулами. Это просто прикольно: сделал десяток коммитов в полночь получи титул "Midnight code warrior" :)

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

Прогресс

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

Поскольку у API гитхаба есть ограничение в 5000 запросов в час, то процесс выкачивания всего графа затянулся почти на два дня.

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

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

Наблюдай и следи

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

Отсюда видно, что почти 50% пользователей, следят более чем за 10 репозиториями и 7% (около 4 тысяч) — более чем за 100. Так же мне интересны те 20% (11 тысяч), что фоловят более 10 человек, они наверняка не успевают прочитывать весь свой News Feed. И уж наверняка оставшиеся 410 пользователей, что фоловят больше сотни по достоинству оценят аггрегатор новостной ленты. Сам я, как раз вхожу в последнюю категорию, так как фоловлю 331 разработчика.

Количество репозиториев

Среднее количество публичных репозиториев у гитхаб пользователя — 8, из них 3, это форки чужих проектов.

На этом графике видно, что 60% пользователей имеют меньше 10 публичных репозиториев, а у 15% их нет вообще. Зато почти у четверти пользователей гитхаба публичных репозиториев от 10-100, и они являются потенциальными пользователями моего сервиса.

При этом, процент активных репозиториев, таких в которые был хотя бы один push за последний месяц, всего 10%.

И еще…

Всего я выкачал информацию чуть больше чем по 500 тысячам репозиториев, и примерно 40% из них, это форки. Удивительно, я думал что форков должно быть гораздо гораздо больше.

Посчитал я и то, насколько больше "второй круг", по сравнению с первым. В среднем, пользователь гитхаба фоловит 9 человек, и следит за 33 репозиториями, это его "первый круг". Второй круг, это те, кого фоловят те, кого фоловят ты. Второй круг, уже составляет 230 пользователей и 800 репозиториев. И это в среднем. Для нерепрезентативных вроде меня цифры другие: 11548 и 42882 соответственно. Это почти 1/5 всего гитхаба!

Кроме этого, я посчитал соотношение обычных пользователей и организаций:

Немножко Топов, я знаю, они всем нравятся :)

Top 20 компаний

Компания	Кол-во
	37965
ThoughtWorks	75
Google	65
Mozilla	61
Red Hat	58
Freelance	56
Twitter	40
Japan	40
Yandex	39
Freelancer	36
Globo.com	35
Yahoo!	33
Intridea	31
Facebook	30
GitHub	29
Student	26
Emergya	26
Pivotal Labs	24
Microsoft	23
Engine Yard	23

Top 20 городов

Город	Кол-во
	23657
San Francisco	1441
London	962
New York	578
Paris	474
Chicago	458
Seattle	457
Tokyo	430
Berlin	423
Germany	417
Portland	346
Toronto	317
Boston	288
Austin	280
Sydney	272
Stockholm	261
Japan	244
Los Angeles	230
Brooklyn	226
Melbourne	221

Top 20 "последователей"

Логин	Фолловит
snytkine	3242
mtsoerin	1983
webiest	1903
superfeedr	1710
charlenopires	1236
stonegao	1205
Marak	1068
speedygonzalez	1059
tyru	1022
esneko	867
josegonzalez	640
c9s	556
kanzure	555
take-cheeze	517
elliottcable	495
Sannis	475
mattn	462
j2labs	453
dpree	446
rkh	444

Top 20 "кого фолловят"

Логин	Последователей
defunkt	4005
torvalds	3803
jeresig	3466
mojombo	3248
ryanb	2737
schacon	2429
paulirish	2316
dhh	2170
wycats	2044
ry	2032
rails	1946
facebook	1802
jquery	1767
technoweenie	1572
pjhyett	1563
visionmedia	1554
cyanogen	1410
douglascrockford	1380
tpope	1369
android	1317

Top 20 "по репозиториям"

Логин	Репозиториев
gitpan	21976
vim-scripts	3735
emacsmirror	3101
Epictetus	911
panega	612
jenkinsci	602
dev2dev	504
wave2future	411
CyanogenMod	342
MechanisM	329
rjbs	325
tokuhirom	297
rwldrn	297
aculich	287
rainly	282
albertobraschi	278
idega	272
rafl	266
apache	258
kristianmandrup	244

Top 20 "вотчеров"

Логин	Наблюдает за
gitpan	21976
vim-scripts	3736
emacsmirror	3588
stonegao	2789
abecciu	2474
igrigorik	2415
charlenopires	2339
stan	2318
matagus	2160
smtlaissezfaire	1955
rmetzler	1916
shanlalit	1897
willi	1896
Epictetus	1821
filipeamoreira	1812
arden	1783
andrew	1746
methodmissing	1665
rkh	1571
lgs	1511

Всё

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

P.S. — думаю, проектик найдет свою аудиторию в несколько тысяч человек. Осталось придумать, как его монетизировать, чтобы окупать аренду серверных мощностей.

For-Else in Python

2011-04-18T11:18:00Z

Пользовались ли вы когда-нибудь ключевым словом else, совместно с for? Нет? Мне тоже не приходилось. А оказывается, это чрезвычайно удобно в тех случаях, когда в теле цикла используется ключевое слово break.

Как работает else? Очень просто. Код этой секции выполняется в том случае, если основной цикл завершился естественным образом, без эксепшена или вызова break.

То есть, это ключевое слово будет полезно тогда, когда вам нужно выполнить какой-то код только в том случае, если в цикле были перебраны все элементы. Я на этом сделал аналог switch с поддержкой регекспов и значением по-умолчанию:

import re
REGEXES = (
    (r'some ([^ ]+)', lambda m, line: do_some(m, line)),
    (r'another ([^ ]+)', lambda m, line: do_another(m, line)),
)
REGEXES = tuple((re.compile(line), func) for line, func in REGEXES)

def switch(text_to_check, regexes, default):
    for line, func in regexes:
        match = line.match(text_to_check)
        if match is not None:
            func(match, line)
            break
    else:
        default(line)

switch('blah minor', REGEXES, do_default_action)

Git helper for GitHub Users

2011-04-14T12:26:00Z

Нашел тут скриптик, облегчающий работу с гитхабом из командной строки. Все что нужно, это иметь установленный ruby (в Mac OS X, он уже есть). Скрипт достаточно скачать куда-нибудь в PATH, и сделать на него алиас alias git=hub.

Для полноценной работы, нужно так же добавить в ~/.gitconfig секцию с вашим именем и токеном:

[github]
    user = svetlyak40wt
    token = а-тут-секретный-токен

После этого можно будет, к примеру, по-быстрому форкнуть мой проект ForkFeed, который, кстати, тоже полезен пользователям GitHub:

git clone svetlyak40wt/forkfeed
cd forkfeed
git fork

Наслаждайтесь!

Github Trends

2011-04-05T10:29:00Z

Знаете, какой мой основной паттерн использования GitHub? Помимо хранения в нем кода своих проектиков, конечно. Я подписан на множество людей, которые постоянно вотчат разные репозитории. И у меня есть RSS фид, в котором только информация о том, кто чем заинтересовался. Периодически я этот фид просматриваю, и если вижу, что у какого-то репозитория появилось много вотчеров, то присматриваюсь к проекту поближе.

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

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

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

Тем не менее, пока не буду писать свой велосипед, и попробую воспользоваться GitHub Trends.

Асинхронное тестирование с Twisted

2011-03-01T10:53:00Z

Недавно я писал в твиттере, что мне нравится писать юниттесты для программ, использующих Python фреймворк Twisted. В твиттере всего не уместишь, поэтому я решил оформить пояснение отдельным постом.

Дело в том, что я сейчас разрабатываю распределенный, отказоустойчивый сервис локов. Внутри он асинхронный, использует Twisted. Ноды общаются между собой по TCP, используя собственный текстовый протокол, а наружу предоставляют HTTP интерфейс в духе REST. Мне очень важно обеспечить стабильность и консистентность моего сервиса, потому что от него будет зависеть синхронизация других задач. Поэтому первое что я сделал, это написал тесты. Эти тесты даже и unit-тестами назвать нельзя, они скорее, функциональные.

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

Отладка сетевого взаимодействия сложная штука. Но тут (барабанная дробь), на сцену выходит Twisted!

by dirkjanranzijn

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

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

перед запуском теста, TestCase класс вызывает random.seed(some_value) и запоминает значение some_value;
если тест сломался, то помимо обычного сообщения об ошибке, TestCase выводит RANDOM SEED: some_value;
чтобы запустить тест, явно инициализировав генератор случайных чисел, я его декорирую:
```
@seed(some_value)
def test_my_broken_code(self):
  ...
```

Вот класс TestCase и декоратор seed, реализующие данную функциональность:

import random
import time

from twisted.trial import unittest

def seed(value):
    def decorator(func):
        func._random_seed = value
        return func
    return decorator

class TestCase(unittest.TestCase):
    def _run(self, method_name, result):
        method = getattr(self, method_name)
        seed = getattr(method, '_random_seed', int(time.time()))
        random.seed(seed)

        def seed_info_adder(failure):
            failure.value.args = (failure.value.args[0] + ' (random seed: %s)' % seed,) + failure.value.args[1:]
            return failure

        d = super(TestCase, self)._run(method_name, result)
        d.addErrback(seed_info_adder)
        return d

Что думаете по поводу такого метода отладки? 13558447.88548999.1298975203.fe8d17be47add1425588f6f16d9ae6e9 и 1120000000000244.1354.1298974870.96d80d1dda087b5185ebddd707442782

Еще одна HTTP либа

2011-02-16T11:11:00Z

Порой в твиттере прилетают интересные ссылки. Так, например, вчера Юрий Юревич заретвитил несколько обновлений с PyPi. Одно из них — новая библиотечка для работы с HTTP. По сути, это всего лишь обертка над стандартными urllib и urllib2, призванная сделать работу с ними проще и понятней. Однако, уже по дизайну этого велосипеда видно, что где его можно улучшить.

Например, для того, чтобы использовать аутентификацию с именем пользователя и паролем, там предлагается сначала создать некий Auth объект и потом использовать его во всех вызовах:

conv_auth = requests.AuthObject('requeststest', 'requeststest')
r = requests.get('https://convore.com/api/account/verify.json', auth=conv_auth)

Зачем? Если этот объект только и делает, что хранит имя пользователя и пароль, почему не использовать вместо него tuple (username, password)??? Если уж делаешь просто, почем не идешь до конца?

И еще пара замечаний по коду. Использовать с python2.5 его нельзя, потому что автор забыл про from __future__ import absolute_import, try except блоки тоже newstyle, в главном методе, посылающем запрос, чудовищный ifelse блок на два экрана. И еще, он пытается сам вызывать манкипатчинг, если присутствуют библиотеки eventlet или gevent. Что будет, если у меня они установлены в системе, но я не собираюсь их использовать?

Zen для каждого

2011-02-15T10:03:00Z

Есть такой PEP-0020, с которым рекомендуется ознакомиться всем начинающим питонистам как только они изучат PEP-0008. Это краткий свод правил, которых следует придерживаться, программируя на питоне (да и не только не нем, кстати). Правила составил Тим Петерс и они, кстати, доступны прямо из интерпретатора. Достаточно сделать import this.

Но сегодня я хочу дать ссылку на приложение к PEP-0020, написанное Хантером Бланксом. В нем он приводит краткие иллюстрации каждого пункта из "The Zen of Python". Получилось очень наглядно.

Эволюция проектов на GitHub

2011-02-09T12:11:00Z

Сегодня зарелизил небольшую но очень полезную тулзу для пользователей GitHub. Проект называется Forkfeed. Он предназначен для слежения за развитием форков ваших проектов на гитхабе.

by GraemePow@flickr

Часто бывает такое, что кто-то форкает ваш проект, начинает его развивать, а pull реквестов не присылает. А за всем ведь не уследишь. Поэтому я написал скрипт, который обходит все форки всех моих проектов, смотрит какие их коммиты новее моих, и создает Atom фид. Фид обновляется по крону, на моем VPS. Теперь я всегда буду в курсе новых форков каждого из моих проектов.

Кролик в Бутылке

2011-02-01T00:35:00Z

Полторы недели назад, в заметке "Командная строка для интернетов", я писал о довольно полезном сервисе умных закладок, которые каждый может дописать под свои нужды и запустить либо на локальной машине, либо на собственном сервере.

Поковыряв код этого проекта, я пришел к выводу, что он для такой простой идеи, реализация чересчур сложна. И конечно же, решил все переписать :-)

Теперь мой форк называется не Bunny, а Cony, что является синонимом слова кролик.

by animalvegetable@flickr

Если Bunny1 тянет за собой большой и толстый CherryPy, то Cony гораздо скромнее. Он основан на микро-фреймворке Bottle, а Bottle, это всего лишь один файл, который лежит прямо в репозитории проекта.

Расширяй

Благодаря отсутствию зависимостей, установка Cony предельно проста — клонируем репозиторий, и запускаем ./cony.py. Дописывание своих шоткатов тоже предельно просто — достаточно положить в текущей директории файлик local_commands.py. Готовые примеры некоторых команд лежат в директории examples. Можно в начале local_commands.py сделать from examples import * чтобы подключить их все, либо импортировать только нужные функции.

Клонируй и делись

Если ты написал интересный шоткат, и считаешь, что он будет полезен другим — не ленись, форкни проект на GitHub, и добавь команду отдельным файлом в examples, а затем пришли Pull Request.

И немного про бутылку

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

OpenSource Переводы

2011-01-27T14:55:00Z

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

Transifex, предоставляет интерфейс для работы над переводами. Процесс выглядит так:

Регистрируешься.
Добавляешь свой проект.
Указываешь какие у него есть PO файлы, загружая уже готовые переводы.

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

После того, как перевод готов, можно скачать готовые PO файлы.

Ради эксперимента, я добавил туда один свой небольшой проектик django-faces. Если знаете язык, отличный от английского и русского, попробуйте перевести. Строк для перевода совсем немного.

Кстати, всего я насчитал на Transifex около 600 проектов, и лишь в половине из них есть ресурсы для перевода. Это значит, что разработчики начинают играться с интерфейсом, но что-то им мешает довести дело до конца. Интерфейс действительно местами очень непонятный. К примеру, я так и не смог понять, как поискать интересный проект, который бы можно было перевести на русский.

Командная строка для Интернетов

2011-01-20T11:11:00Z

Пользуетесь ли вы поисковыми сокращениями, позволяющими после шотката ввести запрос прямо в адресной строке браузера? Если да, то вам наверняка будет интересно узнать, что можно не только подключать к вашему браузеру готовые поисковые движки, но и писать более изощренные обработчики запросов прямо на Python.

Вчера я отрыл на гитхабе интересный проект, разработанный когда-то в недрах Facebook. Проект носит странное название Bunny1.

by serenionion@flickr

Bunny1, это вебсервер, который принимает команду и некоторый запрос, а затем либо редиректит куда-то, либо показывает HTML страницу с результатом. Если подключить URL этого сервера в качестве поиска по умолчанию, то вы получаете командную строку прямо в браузере. И самое полезное тут то, что:

это будет работать во всех современных браузерах;
команды можно дописывать самому, на python.

К примеру, можно написать обработчик, который по запросу tw Доброе утро Москва! будет твитить в ваш аккаунт и редиректить на страничку этого твита.

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

Отладчик с блэкджеком

2011-01-18T14:13:00Z

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

Сегодня я хочу рассказать вам о довольно полезном инструменте, а именно — об отладчике. Если вы не любитель развесистых IDE, то наверняка пользовались стандартным отладчиком питона pdb. Он покрывает 90% необходимой мне функциональности, но все же, несколько неудобен. Например, в нем нет автокомплита и несколько напрягает необходимость периодически набирать команду для вывода листинга, чтобы посмотреть на контекст текущей строки.

Эти, а так же некоторые другие проблемы, призван решить проект pdbpp. Вот несколько фич, которые оказались мне наиболее полезны:

sticky mode — в этом режиме отладчик перерисовывает текущую функцию после каждого шага интерпретатора;
автокомплит по табу — больше не надо вызывать dir(obj) чтобы ознакомиться с интерфейсом объекта;
подсветка синтаксиса — pdbpp использует Pygments, чтобы сделать код еще прекраснее чем он есть (ведь твой код прекрасен, разве нет?).

Кроме этого, там есть такие штуки, как вызов редактора для исправления трассируемого файла, умный парсинг команд, команда longlist (ll) для вывода на экран текущей функции или метода.

Вот так выглядит типичная сессия pdbpp:

А для того, чтобы использовать этот чудесный инструмент, достаточно установить его в систему любым из доступных вам способов, после чего, как обычно, можно использовать import pdb; pdb.set_trace().

Update: записал короткую демку того, как это работает.

Социальные закладки на GitHub

2011-01-13T11:17:00Z

Сегодня я хочу рассказать вам о довольно интересном проекте, появившемся недавно на GitHub. Разрабатывается он некой девой Hilary Mason и называется gitmarks.

Суть проекта в следующем. Он позволяет сохранять URL в закладки и делиться ими с другими пользователями через GitHub. Для каждой закладки, скрипт выкачивает содержимое залинкованной страницы. Так же, можно задать теги и описание ссылки. Ну и конечно же, можно использовать git grep для поиска по своим закладкам. Добавлять ссылки можно как из командной строки, так и с помощью букмарклета, но для этого нужно запустить локальный вебсервер.

Автор фотографии Ei! Kumpel.

Однако, у этого проекта есть, и несколько недостатков.

Во-первых, код выглядит довольно безобразно из-за того, что Хилари не придерживается общепринятых в Python сообществе, соглашений.

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

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

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

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

Diff Git Cached в Vim

2011-01-09T14:04:00Z

Оказывается в Vim есть полезная штука для просмотре диффа при редактировании commit message git. Она появилась, начиная с версии 7.2. Называется эта команда :DiffGitCached.

Дифф можно вызывать вручную, а можно прописать в конфиг такую строчку:

autocmd FileType gitcommit DiffGitCached | wincmd p

И тогда дифф будет открываться автоматически после запуска git commit.

Этот хинт я почерпнул из книги Vim Recipes.

Лучший логгинг для Питона

2010-12-30T10:39:00Z

Помнится, я как-то уже жаловался на то, что код питонового логгинга писал какой-то ненатурал и индус, впридачу. Так вот, недавно я нашел библиотечку, приятно реализующую логирования и по тестам, превосходящую стандартный logging в скорости, примерно в 5 раз. Называется она Logbook.

Я потыкал в Logbook, поглядел код, позапускал тесты. Она мне нравится. В ней много вкусных плюшек. Вот те из них, которые кажутся мне наиболее интересными:

Возможность работы со стандартной библиотекой logging. Существующие библиотеки, которые выводят все через стандартный logging, переделывать не придется.
Можно без проблем добавлять в записи дополнительную информацию, например IP пользователя и ID запроса к веб приложению. И тогда все записи лога будут легко кластеризоваться по этим данным.
Специальные хендлеры, такие как FingersCrossedHandler и GroupHandler позволяют группировать записи лога и выводить их в файл (или отправлять по почте, пачками)

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

Допустим, вы пишите сложную Django view в которой много чего происходит, внутри вызываемых вьюхой функций вы логируете производимые действия с уровнем DEBUG или INFO. И когда всё идет как задумано, эти записи вам, в общем то, и не интересны. А вот если случается какая-то ошибка, то было бы неплохо не только stack-trace посмотреть, но и видеть, какие действия ему предшествовали. Тут то и приходит на помощь FingersCrossedHandler. Он складывает все записи лога в память, если встречается запись с уровнем ERROR, то вызывает другой обработчик (например отсылающий записи из буфера вам на почту или складывающий в файл). Если ошибки не произошло — буфер очищается, я специально проверил, утечек памяти нет. Вот пример использования:

from __future__ import with_statement
from logbook import FileHandler, FingersCrossedHandler, Logger

logger = Logger('root')

def issue_logging():
    def factory(record, handler):
        return FileHandler('app/issue-%s.log' % record.time)
    return FingersCrossedHandler(factory)

def some_func():
    logger.debug('This is a debug message.')
    logger.warning('Warning, warning.')

def error():
    1/0

def main():
    with issue_logging():
        try:
            some_func()
            error()
        except Exception:
            logger.exception('Something went wrong.')

if __name__ == '__main__':
    main()

В итоге его работы, произойдет ошибка деления на 0 и в директории будет создан один единственный файл:

[2010-12-29 22:18] DEBUG: root: This is a debug message.
[2010-12-29 22:18] WARNING: root: Warning, warning.
[2010-12-29 22:18] ERROR: root: Something went wrong.
Traceback (most recent call last):
  File "test.py", line 23, in main
    error()
  File "test.py", line 17, in error
    1/0
ZeroDivisionError: integer division or modulo by zero

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

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

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

Image Shortener Wanted!

2010-12-28T01:05:00Z

Меня посетила идея нового сервиса, от которого как минимум один человек, то есть я сам, мог бы извлечь пользу — "Сокращалка Картинок".

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

Так вот, было бы прекрасно, если б существовал некий прокси-сервер, который бы работал одновременно и как сокращалка урлов, и как ресайзер.

Например, есть картинка http://farm5.static.flickr.com/4005/4203341399_c1c99027e5_o.jpg, и я хочу вставить ее в блог, но так чтобы по ширине она была не больше 600 пикселей:

Я иду на сервис сокращалки и вбиваю там URL этой картинки (в идеале, хорошо бы чтоб можно было вбивать не только URL картинки, но например, URL странички фликра, где она размещена).
Сервис выдает мне короткий урл: http://blah.img/3bfg с которого, по умолчанию, просто редиректит на оригинал.
Я вставляю в свой пост картинку, и в src указываю URL с параметрами: http://blah.img/3bfg?width=600.
Когда по этому урлу картинка запрашивается впервые, сокращалка скачивает оригинал, ресайзит его кладет куда-нибудь в облако и редиректит на эту уменьшенную копию.
Я получаю профит от красивого бложика.

Ну как идея? Может я изобретаю велосипед, и она давно реализована?

Powered by Pelican

2010-12-25T23:06:00Z

После нескольких дней трудов, перевел бложик на генератор статических блогов Pelican. При чем, даже не один бложик, а сразу два: http://aartemenko.com и тот что я пытался вести в Google Buzz.

От http://aartemenko.com я решил отказаться с целью поэкономить память на VPS да и надоело столько доменов содержать. А Google Buzz оказался совсем непригоден для ведения коротких программистских заметок, поскольку непозволяет не то что код с подсветкой вставить, но даже простейших HTML тегов не поддерживает.

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

Теперь я могу редактировать посты в своем любимом текстовом редакторе Vim, и при необходимости, запускать по ним grep. Пока Pelican поддерживает снитаксисы Markdown и ReST, но думаю этого должно хватить всякому. Осталось дописать вспомогательный скрипт для Vim, который будет деплоить статьи на хостинг, и пингать FeedBurner.

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

Модульная сетка

2010-12-19T20:52:00Z

Настраиваю модульную сетку для своего бложика.

Решил отказаться от Buzz и переехать в статический stand-alone, генерируемый с помощью Pelican.

Сейчас делаю свою тему. CSS буду генерить с помощью Compass и Blueprint, а для вспоможения, настроил отображение модульной сетки с помощью вот этого джаваскрипта:

https://github.com/aishek/modulargrid

Pdb decorator

2010-12-16T14:43:00Z

Нарисовал тут pdb decorator. Он полезен, когда отлаживаешь функцию, обернутую большим кол-вом декораторов, например какую-нибудь Django вьюху.

from functools import wraps

def pdb_deco(func):
    @wraps(func)
    def wrapper(*args, **kwargs):
        import pdb;pdb.set_trace()
        return func(*args, **kwargs)
    return wrapper