Когда я прошелся по коду mercurial_keyring (он написан на python), оказалось что проблема лежит в функции get_http_password, точнее в том, что модуль keyring не может сохранить/получить пароль, если в ключе присутствует знак :. Скрипт mercurial_keyring.py генерирует ключ из логина и url-а, соответственно если URL начинается с http: или https:, плагин просто не находит сохраненного пароля.

Я это у себя исправил просто правкой mercurial_keyring.py. Было:

    def _format_http_key(self, url, username):
        return "%s@@%s" % (username, url)

Стало:

    def _format_http_key(self, url, username):
        return "%s@@%s" % (username, url.replace(':', '#'))

Nude.js подключается к странице как любой другой скрипт:

<!--[if IE]>
<script type="text/javascript" src="excanvas_r3/excanvas.compiled.js"></script>  
<![endif]-->
<script src="nude.js/compressed/nude.min.js"></script>

Для работы nude.js требуется canvas, поэтому для IE требуется “эмулятор” iecanvas.js. После подключения можно анализировать DOM node изображения:

 nude.load(node);
  nude.scan(function(result){ 
    console.log(result ? "Nudity found in " + node.id + "!" : "Not nude");
  });

Однако после подключения изображения к странице Tumblr и отладки сообщений об ошибках, обнаружился интересный факт. А именно: если на canvas помещён элемент с домена, не совпадающего с доменом скрипта, canvas считаются “загрязнёнными” и информацию об изображении с них получить уже нельзя. Единственный способ это обойти — убедиться что сервер отдаёт с запрашиваемым изображением заголовок CORS (cross-origin resource sharing), а именно Access-Control-Allow-Origin. Пока этот заголовок использует в основном Flickr. В других случаях, когда домены скрипта и изображения не совпадают, загрузить и обработать его уже нельзя.

После этого я отложил эту идею до нормального внедрения CORS.

Пару месяцев назад я записался на онлайн-курс Artificial Intellingence от Stanford University. И пока курс не начался (он начался только в понедельник 10 октября) пришла ко мне мысль сделать какую нибудь “песочницу” для тестирования разных алгоритмов, которые будут встречаться в курсе. Захотелось сделать такую песочницу из Minecraft.

Вначале я думал о том чтобы просто модифицировать клиент или написать к нему плагин. Но т.к. при модификации пришлось бы работать с декомпилированным (плохо читаемым) Java-кодом, а система плагинов пока оставляет желать лучшего, я переключил своё внимание на сервер. Тут дела были несколько лучше. Для Minecraft есть несколько серверов с открытым исходным кодом на разных языках — C, Java, Python, .NET и т.д. Покопавшись в них, а также покопавшись в nodecraft — заброшенной попытке написать minecraft-сервер на JavaScript, я решил все таки попробовать написать сервер самостоятельно, благо опыт работы с двоичными протоколами после разработки limestone у меня есть, да и во внутренности Minecraft я уже немного забирался (правда с Питоном). Протокол Minecraft описан (пусть даже немного неточно) в Minecraft Coalition wiki.

За первые пару дней я разобрался с последовательностью авторизации клиента и перешёл непосредственно к логину. Для логина сервер должен выслать клиенту местность вокруг места появления и всякие стартовые параметры типа времени сервера, содержимого инвентаря, точки респауна в случае если игрок погибнет и т.д. В IRC на канале #mcdevs меня сразу предупредили что отправка чанков клиенту это довольно сложная часть разработки и многие авторы серверов срезаются именно здесь. В результате двухдневных попыток подбора библиотеки сжатия и экспериментов с порядком пакетов отправить местность всё таки получилось. На следующий день после этого я прикрутил отправку keepalive-пакетов (без этого время пребывания на сервере ограничивалось одной минутой) и добавил респаун мобов и их движение. Теперь осталось только добавить определение столкновений, чтобы делать лабиринты, и можно приступать к заданиям второй главы курса — алгоритмам поиска пути.

Когда доделаю сервер будет видимо отдельный большой пост о протоколе Minecraft, написании сервера и насколько он на самом деле подходит для тестирования AI-алгоритмов. Пока мои наработки можно найти на Github. Сервер я назвал blackstone (на #mcdevs предлагали node-minecraft, но по моему это скорее название для какой нибудь библиотеки утилит).

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

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

Установка

Для работы Kue требуется Redis версии не меньше чем 2 (с поддержкой команды WATCH). Я использовал 2.2.11, последнюю стабильную версию. Об установке и настройке Redis можно подробнее прочитать в другой статье.

Сам Kue ставится из npm:

npm install kue

Ничего настраивать после установки не нужно — Kue сам подключится к Redis по стандартному порту. Если Redis у Вас настроен на нестандартный порт, нужные параметры можно передать при подключении модуля в коде.

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

Попробуем сразу создать задачу:

var kue = require('kue'),
    jobs = kue.createQueue();

jobs.create('email', {
    title: 'welcome email for tj'
  , to: 'tj@learnboost.com'
  , template: 'welcome-email'
}).save();

Здесь "email" это тип задачи, объект содержит метаданные, которые будут доступны при выполнении. Свойство title особое: оно будет использоваться в веб-интерфейсе как имя задачи. Если требуется указать приоритет задачи, перед save() в цепочку идёт .priority() с указанием приоритета.

Приоритет может быть задан либо числом (чем меньше, тем раньше задача попадёт в очередь), либо строкой. Строки служат указателями наиболее типичных приоритетов:

• low: 10
• normal: 0
• medium: -5
• high: -10
• critical: -15

Получить задачу для выполнения можно с помощью jobs.process:

jobs.process('email', function(job, done) {
  console.log('Processing "' + job.data.title + '"');
  done();
});

При выполнении в обработчик передаётся объект задачи job (метаданные доступны в свойстве data) и callback done — если он будет вызван без передачи ошибки, задача будет отмечена как успешно выполненная.

Маленькие задачи, которые нет смысла выполнять поодиночке, можно обрабатывать по несколько штук параллельно. Для этого после типа задачи надо передать количество задач для одновременного выполнения. Например, чтобы отправить сразу 20 писем, можно использовать такой код:

jobs.process('email', 20, function(job, done) {
  console.log('Processing "' + job.data.title + '"');
  done();
});

Если надо следить за выполнением отдельных задач, можно использовать индикаторы выполнения и индивидуальные логи. Чтобы отметить степень выполнения долгой задачи, используйте job.progress:

job.progress(done, total);

Здесь total это общее количество шагов выполнения (или элементов для обработки), done — количество уже выполненных шагов. Если при выполнении что то пойдет не так, можно записать сообщение в лог задачи:

job.log('Error rendering slide %d: %s, slide.id, render.err);

Веб-интерфейс

У Kue есть веб-интерфейс, представляющий собой приложение на основе Express. Чтобы его запустить надо вызвать kue.app.listen и передать ему порт:

kue.app.listen(3003);

В веб-интерфейсе можно следить за выполнением задач.

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

Kue показывает индикаторы степени выполнения той или иной задачи, задаваемые job.progress.

Ссылки по теме

• Официальный сайт Kue
• Репозиторий Kue на Github

Точнее, таких писем было два.

При более внимательном рассмотрении оказалось что во втором письме ссылки ведут не на основной сайт Хабра, а на другой домен (хотя в самом письме написано что отправлено оно от mailer@habrahabr.ru). Немного пошарившись по второму сайту, сделал вывод что это какая то dev или staging площадка для ремонта багов. Никакого нового функционала там нет, зато например с утра не открывались топики если я был залогинен (я смог зайти, да), в обед это уже починили, зато потом снова сломали. И в собственный либо чей нибудь другой хабрацентр зайти невозможно. Кстати, самой новой фичи Хабра (возможности подписаться на комментарии к топику/отписаться от них) я там тоже не увидел.

Судя по топикам и комментариям, база в проекте актуальна на 4 июня 2011, время последнего комментария 18:29. Соответственно, срок голосования за всё уже истёк, так что проверить систему патронов не получилось. Из исследовательских побуждений сделал комментарий к одному из топиков. Комментарий появился на dev-сайте, но не на основном.

Очевидно что база используется настоящая (иначе я не смог бы зайти со своим паролем, да и почта бы не пришла), и крон работает исправно. Ради эксперимента попробовал зайти под неправильным паролем/другим пользователем — не получается. Судя по всему, оба сайта по крону проверили мою дату регистрации, убедились что я зарегистрирован более 3-х лет назад и сижу без значка, и оба выслали мне по письму (автоматически сформированному со ссылками).

Что подводит меня к интересной мысли что и на нашем проекте может быть такая же засада. Мы тоже используем частичную живую базу, крон тоже работает и данные пользователям периодически рассылаются. Правда у нас все dev/stage сервера закрыты HTTP Auth, так что просто так туда не зайти. Но проверить на всякий случай надо.

Ради ещё одного эксперимента (да и просто из интереса) запостил этот топик на Dev-Хабр. Хотя при публикации топика мне выдало 500 ошибку, он тем не менее появился в “новых”. В пост вставил картинку для отслеживания посещаемости — нашёл фотографию по запросу dev server, залил на habrastorage и сократил URL через bit.ly. В bit.ly есть простенькая статистика по переходам (в нашем случае — по просмотрам картинки). В результате топик пока не получил ни просмотров, ни оценок.

В конце концов отписал Чипу и Дейлу по этому поводу. Пришёл ответ, но dev-сайт так и не закрыли (поэтому домен из записи я убрал).

То, есть, чтобы вместо вот этого:

var call = http.request(options, function(res) {
	var data = '';
	res.on('data', function(chunk) {
		data += chunk;
	});
	
	res.on('end', function(chunk) {
		data += chunk;
		// Сделать что нибудь с полным ответом сервера
	});
});
call.end();

…можно было писать как нибудь так:

var call = http.request(options, function(res) {
	s(res).collect().on('data', function(data)
		// Сделать что нибудь с полным ответом сервера
	});
});
call.end();

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

var test = new events.EventEmitter();

// Преобразуем текст входящих событий в JSON, оставляем только поле test
// и отфильтровываем все значения которые не начинаются на "a"
sop.sop(test).json().only('test').filter(/a.+/).log();

test.emit('data', JSON.stringify({"test": "a1"}));
test.emit('data', JSON.stringify({"test": "b1"}));
test.emit('data', JSON.stringify({"test": "a2"}));
test.emit('data', JSON.stringify({"test": "b2"}));

test.emit('end');

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

P.S.: нашёл похожий проект — async.js от Fabian Jakobs

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

Для большинства систем runit ставится из стандартного менеджера пакетов (apt-get install runit для Debian). Если в Вашем менеджере нужного пакета нет, можно скачать исходники для сборки с официальной страницы.

Каждому сервису в runit соответствует директория в /etc/sv. В этой директории создаём файл запуска run:

mkdir /etc/sv/testservice
vim /etc/sv/testservice/run

В файле run пишем строку для запуска нашего скрипта, с перенаправлениями ввода-вывода, без демонизации (&), но с exec:

exec node /etc/mysite/server.js 1>>/var/log/mysite/output 2>>/var/log/mysite/error

Ставим этому файлу разрешение на выполнение:

chmod +x run

Теперь чтобы запустить сервис надо передать runit команду и имя директории внутри /etc/sv:

sv start testservice

Чтобы остановить сервис, вторым параметром передаётся stop, чтобы перезапустить — restart.

Чтобы проверить runit я использовал немного модифицированный “Hello World” с официального сайта:

http.createServer(function (req, res) {
  res.writeHead(200, {'Content-Type': 'text/plain'});
  res.end('Hello World\n');
  console.log('Log message #' + i);
  console.error('Err message #' + i);
  i++;
}).listen(8124, "192.168.175.128");
console.log('Server running at http://127.0.0.1:8124/')

console.log выводит строку в стандартный поток вывода (stdout), console.error выводит строку в stderr. Строки, переданные в console.log будут выводиться в /var/log/mysite/output, то что передано в console.error будет записано в /var/log/mysite/error.

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

Чтобы прикрутить runit к monit’у, можно создать симлинк в директории /etc/init.d/ на /usr/bin/sv. При таком вызове runit будет запускать/останавливать сервис, соответствующий имени симлинка:

ln -s /usr/bin/sv /etc/init.d/testservice

Теперь при вызове /etc/init.d/testservice start Ваш скрипт будет запущен. Так проще будет перейти с Init на runit если Вы всё таки задумаете это сделать

Ссылки по теме

• Официальный сайт Runit
• Руководство по установке и использованию runit (Хабрахабр)
• Использование node.js с Init + Monit

Получение данных

Я решил найти API нашей системы багтрекинга Mantis чтобы взять оттуда список багов и построить граф зависимостей. Я помню что когда то читал об этом API. Оказалось что Mantis предоставляет SOAP API для получения всей необходимой информации о багах (MantisConnect). Так как из Node работать с SOAP оказалось не очень удобно, я переключился на PHP. Я использовал класс NuSOAP чтобы не изобретать велосипед лишний раз. Обращение к Мантису с помощью NuSOAP делается примерно так:

require_once('nusoap-0.9.5/lib/nusoap.php');
$WSDL_POINT = "https://mantis.example.com/api/soap/mantisconnect.php";
$username = 'username';
$password = 'password';

$proxyhost = isset($_POST['proxyhost']) ? $_POST['proxyhost'] : '';
$proxyport = isset($_POST['proxyport']) ? $_POST['proxyport'] : '';
$proxyusername = isset($_POST['proxyusername']) ? $_POST['proxyusername'] : '';
$proxypassword = isset($_POST['proxypassword']) ? $_POST['proxypassword'] : '';
$useCURL = isset($_POST['usecurl']) ? $_POST['usecurl'] : '0';

$client = new nusoap_client($WSDL_POINT, false,
					$proxyhost, $proxyport, $proxyusername, $proxypassword);

Теперь можно вызывать методы. Я решил просто создать в Мантисе фильтр на нужные баги и получать его результаты:

$params = array(
    'username' => $username,
    'password'         => $password,
    'project_id'         => 42, // Проект, который нас интересует (можно посмотреть в веб-интерейсе Mantis)
    'filter_id'          => 987, // ID фильтра, можно посмотреть на странице управления фильтрами
    'page_number'         => 1,
    'per_page'       => 400 // получить 400 записей
);
$result = $client->call('mc_filter_get_issues', $params,  'https://mantis.example.com:443/api/soap/mantisconnect.php', 'http://soap.amazon.com');

В $result окажется результат обращения к API — массив багов с соответствующими полями. Теперь надо перевести его в формат, подходящий для построения графика.

Graphviz и DOT-файлы

По примеру cg2dot я решил выводить данные в виде DOT-файла. Описание формата можно найти в Wikipedia — он довольно простой. Я просто прошёл по массиву багов и вывел все описания в виде 12345 [label="24430: example issue description"]; и связи parent-child в виде 12345 -> 12346. К сожалению, я не нашёл способа одновременно рисовать направленные и ненаправленные ребра, потому для related to я использовал стрелки в обоих направлениях. Все строки записываются внутри конструкции digraph issues { / }. Я ещё добавил строку rankdir=LR чтобы узлы отрисовывались сверху вниз. По умолчанию dot отрисовывает их в строку, и с длинными описаниями багов получается довольно неудобная картина.

В результате у меня получился граф зависимостей багов. Я ещё немного дописал код чтобы баги разного приоритета выводились разными цветами (12345 [color="green"];). Получившийся код я запускаю прямо из командной строки:

C:\xampp\htdocs\issues>php index.php | "c:\Program Files\Graphviz2.24\bin\dot.exe" -Tpng -o21-mar-11_19-41.png

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

UPD: испытал код на мантисе для Dwarf Fortress, получился огромный граф.

Ссылки по теме

• API MantisConnect
• Краткое описание формата DOT
• Полное описание на сайте GraphViz
• Получившийся код

Проблема решилась с помощью xdebugtoolkit и Graphviz. Graphviz и Python (необходимый для работы тулкита) у меня уже стояли. Оставалось скачать сам xdebugtoolkit. В него входит утилита cg2dot, преобразующая cachegrind-файл в граф вызовов (с указанием какой вызов сколько времени занял). Потом по получившимся данным утилита dot из graphviz просто строит график в формате PNG, на котором неплохо видно где же застревает PHP. Сам вызов выглядит примерно так:

cg2dot.py "D:\cachegrind\stage\cachegrind.out.16084" | "C:\Program Files\Graphviz2.24\bin\dot.exe" -Tpng -ograph.png

Я ввел эту команду и ушёл на час гулять. В результате получился файл graph.png по которому уже было понятно где и что работает медленно.