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

Link Roundup #3

2012-05-14T16:06:00Z

Разработка

Что-то пошла мода на "легковесные" очереди задач. Недавно Vincent Driessen опубликовал свой RQ, а теперь вот и David Cramer пишет, что они в DISCUS пришли к чему-то подобному.
На Highscalability появилась ссылка на новую статью про Paxos. Говорят, там всё хорошо расписано, и обсуждаются детали реализации.
Про то, что масштабируемые сервисы нужно разделять переборками, чтобы повысить их плавучесть.
MailCatcher — простой SMTP сервер, для отладки отправки писем. Перехватывает все проходящие через него сообщения, и показывает из в веб-интерфейсе. Попробовал swiftypy.com — поисковый движок для сайтов. Морфологию русскую, увы, не поддерживает. Но выглядит круто. И пока бесплатен.
Небольшая заметка о том, как ребята из Pinterest продвигают формат oEmbed, и с его помощью по непонятному урлу картинки с flickr, получают реальный адрес страницы, с этим изображением.
Статья про то, как применять GitFlow и работать с GitHub. Правда ничего не говорится о том, как майнтейнер апстрима будет мерджить твою feature ветку, ведь если он сделает это через интерфейс гитхаба, то git-flow будет нарушен. Жаль, gitflow мне приглянулся.
Статья про то, почему команда GitHub не использует git-flow в своей работе.
Статья о том, как устроен Ginger — сервис общения для команд. Схема асинхронного IO такая: Django -> Redis PubSub -> Node.js -> Socket.io -> Браузер.
Обширное, хоть и старое (2008) года, сравнение JSON библиотек для Python.
Антипаттерны деплоя Python кода. Согласен со всеми пунктами.
Статья про то, как кластеризуют документы ребята из стартапа Prismatic. Присутствует пара практических советов, как бороться с нехваткой памяти и ресурсов CPU при больших объемах подобных вычислений. Суть проста — не хранить и не делать лишнего.
Пост про то, почему плохо заводить организации для проектов на GitHub.
Про динамическую подгрузку функций virtualenvwrapper и скринкастик про сам враппер. Посмотрел всё это и и понял, что мне это не нужно, потому что я крайне редко переключаюсь между окружениями в одной консоли, у меня для этого tmux есть.

Полезные сервисы

GitHire — сервис для найма активных гиттеров.
git.io — сокращала урлов для GitHub. Оказывается уже почти полгода существует, а я и не знал.

Link Roundup #2

2012-04-23T13:15:00Z

Python

Статья о том, как пушить стэктрейсы через PubSub Redis'a в IRC канал.
Мой клон Homebrew, но для Linux и на Python, пока очень очень alpha, но уже умеет устанавливать пакетики, и скоро научится удалять :))).
Один из коллег опубликовал на GitHub python скриптик, чтобы считать IO по файлам в Linux. Сначала статистика собирается через TAP, а потом этим скриптиком аггрегируется: stap filestat.stp bsc-srch-base-8 | python -u aggregate_filestat.py.
А вот Chaco — python библиотечка для рендеринга интерактивных графиков.
Кеннет Рейнц написал статью про "правильную" структуру репозитория для Python проекта. Всё очевидно и разжевано. Можно рекомендовать новичкам.
Доклад Python Metaprogramming for Mad Scientists and Evil Geniuses, с PyCon2012. Много интересного про манкипатчинг.
Так же, я потестил PyPy на маленьком Bottle+Gunicorn проектике, и получил прирост производительности всего на 30%. Не впечатлен. Настмотревшись их графиков, ожидал большего.
Кстати, вы знали, что в gunicorn можно передавать не только путь до application, но и фунцию, которая этот app генерит? Как-то так: gunicorn 'mysite:app_generator()'.

Разное

Огромная подборка статей про Responsive Design. Отложил в закладки, когда-нибудь пригодится, хоть я и не верстальщик и не дизайнер.
Интересная статья про то, как правильно писать асинхронный код на Javascript. Предлагаемая концепция немного напоминает Deferred в Twisted Python, и обертку inlineCallbacks.
Старая статья Guy Kawasaki о том, что презентация должна быть на 10 страницах, за 20 минут и крупным 30pt шрифтом.
Описание формата oEmbed, позволяющего посредством GET запросов получать информацию о ресурсах сайта по урлу. Например для встраивания их в другие сайты. Оказывается, этот oEmbed много кто поддерживает.
Твиттер принес ссылку на еще один GUI клиент к MongoDB — MonjaDB. Пока не смотрел. Судя по скриншотам, довольно развесистый, и на Java и под Eclipse.

Полезные сервисы

ChartBeat — онлайн аналитика посещений. По словам разработчиков, их сервис отличается от Google Analytics или Яндекс Метрики тем, что позволяет отслеживать то, чем занимаются пользователи вышего сервиса прямо сейчас, в "реальном" времени. Хотел попробовать, но они хотят даже для триала, получить данные моей кредитки. Отказался.
Hide-My-Ass — прокси, который не нужно настраивать.
19 апреля, Python хостинг http://ep.io объявил о скором закрытии. Не выдержали конкуренции. Вовремя я перевел один свой маленький сайтик с него, на хостинг яндекса.

Link Roundup #1

2012-04-16T12:54:00Z

Решил делать еженедельные подборки ссылок на разные темы. Это первый такой пост.

Думаю переползать с Munin на Collectd, но попутно наткнулся на проектик python-munin, упрощающий написание плагинов для Munin на python. Мне уже вряд ли пригодится. Кстати, для collectd тоже можно на питончике писать плагины, но запускаются они более разумно.
На прошлой неделе я написал things-periodical-tasks, но позже осознал его бесполезность. Во-первых, в things есть периодические задачи, хоть их и неудобно добавлять, если нужно указывать дни недели. Во-вторых, на постоянно выключаемом ноуте, cron пропускает задачи, запланированные на то время, которое он проспал.
Yaxy — прокси сервер для разработчика, позволяет на лету подменять урлы, заголовки, куки, и т.д..
MongoDB Architecture — заметка про особенности разработки под MongoDB. Наверное всё это можно найти в официальной документации, но там оно разбросано по разделам, а здесь на одной странице.
Амазон запустил Cloud Search и об этом не написал только ленивый. Вообще, довольно очевидная идея и странно, что ни один поисковый гигант до сих пор не выпустил такого продукта.
Статейка про Two Phase Commit в MongoDB и прочих noSQL — про то, как в отсутствии нормальных транзакций, организовать гарантированное изменение нескольких объектов в базе данных.
Статейка про S.M.A.R.T и то, что означают те или иные пункты отчета. Кстати, для OSX в Homebrew есть консольная утилитка smartmontools.
В догонку, я нашел страницу с описанием разных форков Homebrew. И целых три форка Homebrew под Linux:
Из них попробовал пока только последний, от ndevenish. Но там не всё так гладко. Тот же collectd — не собирается потому что не видит dev библиотек, установленных в Ubuntu. Пока отложил.

Periodical Tasks For Things

2012-04-11T15:19:00Z

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

Я уже использую Things от Cultured Code, для ведения списка дел. Однако там нет такой полезной фичи, как периодические таски. Работать оно должно так же, как периодические события в календаре — добавил один раз, указав интервал времени, и задача у тебя появляется сама собой. Вот этого то в Things и не хватает.

Но есть же Apple Script, который позволяет делать почти всё, что угодно!

И вот я сел, и примерно за час времени родил скрипт из 10 строк, добавляющий в Things таск прямо из командной строки терминала. Дальше уже дело техники — запускаешь crontab и добавляешь по строчке на каждой задание, которое должно возникать само собой.

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

Исходники скрипта доступны на GitHub. Форкайте, правьте.

Unittesting With Tdaemon And Tmux

2012-04-06T16:39:00Z

Некоторое время назад я нашел интересный watchdog для запуска юнит-тестов — tdaemon. Инетересн он был прежде всего тем, что работал без использования inotify, что позволяло мне запускать его в диреткториях, подмонтированных внутрь VirtualBox.

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

На днях я, решив попробовать новый севис для записи скринкастов, сделал ролик, в котором демонструрую работу с tdaemon, tmux и специальным плагином nose-notify-tmux, который умеет показывать прогресс юниттестов прямо в табике tmux.

Вот уже производная этого ролика, переснятая и с саундтреком:

Кто хочет нормального качества, тем в ascii плеер.

Исправление работы 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.