Пару месяцев назад я записался на онлайн-курс 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 по которому уже было понятно где и что работает медленно.

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

Проксирование запросов

Сделать обычный прокси в Node.js проще простого:

var http = require('http');

http.createServer(function(request, response) {

  var proxy = http.createClient(80, request.headers['host'])
  var proxy_request = proxy.request(request.method, request.url, request.headers);
  proxy_request.on('response', function (proxy_response) {
    proxy_response.pipe(response);
    response.writeHead(proxy_response.statusCode, proxy_response.headers);
  });

  request.pipe(proxy_request);
}).listen(8080);

Здесь я применяю метод pipe, позволяющий соединять два потока. Сначала мы соединяем запрос от пользователя с запросом к удалённому сайту, потом соединяем ответ от сайта с ответом нашему пользователю. Весь прокси-сервер укладывается в несколько строк. Здесь не учтены многие вещи, котоорые должен уметь прокси-сервер — например, перенаправление HTTPS-запросов — но для моих целей хватит и такого.

Задержка для определённых сайтов

Теперь надо сделать задержку для определённых сайтов. Сначала просто прочитаем список сайтов и преобразуем его в объект, чтобы было проще проверять присутствие домена в списке:

var oc = function(a) {
  var o = {};
  for(var i=0;i<a.length;i++) {
    o[a[i]]='';
  }
  return o;
}

var delayed_sites_raw = fs.readFileSync('timekillers', 'ascii');

var delayed_sites = oc(delayed_sites_raw.split("\n"));

Функция oc (object converter) преобразует элементы массива в ключи объекта, чтобы можно было делать if ('domain' in delayed_sites) {.

Сами потоки можно задержать несколькими способами. Вообще у потока можно вызвать stream.pause (это остановит генерацию событий, но данные будут накапливатся в буфере) и потом продолжить обработку вызовом stream.resume. Я решил приостанавливать ответ от удалённого сервера — чтобы когда я вызову stream.resume ответ уже был получен и сохранён в буфере.

В результате получился вот такой код:

var oc = function(a) {
  var o = {};
  for(var i=0;i<a.length;i++) {
    o[a[i]]='';
  }
  return o;
}

var http = require('http'),
    url = require('url'),
    fs = require('fs');

var delayed_sites_raw = fs.readFileSync('timekillers', 'ascii');

var delayed_sites = oc(delayed_sites_raw.split("\n"));

console.log('Delayed sites:' + delayed_sites);

http.createServer(function(request, response) {
  var delay = 0;

  if (host in delayed_sites) {
    delay = 30000;
  }

  var proxy = http.createClient(80, request.headers['host'])
  var proxy_request = proxy.request(request.method, request.url, request.headers);
  proxy_request.on('response', function (proxy_response) {
    proxy_response.pause();
    setTimeout(function() {
        proxy_response.resume();
    }, delay);
    proxy_response.pipe(response);
    response.writeHead(proxy_response.statusCode, proxy_response.headers);
  });

  request.pipe(proxy_request);
}).listen(8080);

Для тестов я использовал Firefox. Список доменов читается из файла timekillers, в котором они просто записаны по одному домену на строку:

www.reddit.com
twitter.com
news.ycombinator.com
habrahabr.ru
www.tumblr.com

Если через такой прокси открыть например Яндекс, он откроется сразу же. Но если попытаться зайти на Reddit, ответ от прокси придёт только через 30 секунд (это хорошо видно в консоли FireBug).

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

• Комикс «Let Go» в xkcd
• Документация по потокам в Node.js
• Руководство по написанию прокси в Node.js без соединения потоков (на английском)

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

curl -X POST -d "email=example@example.com" http://nodester.com/coupon

Через некоторое время (2 дня в моём случае) на указанный адрес придёт код купона и инструкции по регистрации аккаунта. Чтобы собственно зарегистрировать аккаунт есть два способа: простой и сложный. Простой: зайти на главную страницу и нажать Register, в открывшемся окне ввести желаемые логин, пароль, полученный код купона и свой публичный ключ. Сложный способ — создать аккаунт через вызов API:

curl -X POST -d "user=myusername&password=mynewpassword&email=example@example.com&coupon=mycouponcode&rsakey=ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApRIZrAgJHwPKfJssLwsLpva3SNUNKPkjo4PfviKgTpzNdKVVy3g6ShCw2S381SLxtChg7c0uht04aRiVjyL61Aaigvd6RVWzVeUQjxNT/lguFHDzvHGf4lEh579aQLyUfKLzsbfqss2gIy56Al0Skk3buK871C3PlWZjUL6XkFaYjcfAJBjLVKi8LcNV25ivvKQeMeh2DA6/J36BS0CmB5wsaZbJqp4tDk/pA3ymvOZ/oaJPsMhKHUPxM9FHfkwoGzIUTBNcatsWIPsLL16bE/Jy7Aii3RSKp7tfjcSa5F6ngmXUwrlr%2BGV5hD2LWRc/YlxxKZWUrRU%2B8UdiEoJB6Q== root@debian" http://nodester.com/user

Имейте в виду, при вставке публичного ключа в вызов curl необходимо заменить все вхождения + на %2B. К регистрации через сайт это не относится, туда ключ вставляется как есть. Проще всего произвести замену с помощью sed:

cat ~/.ssh/id_rsa.pub | sed s/'+'/'%2B'/g > test-pub.rsa

Потом просто вставляете в вызов curl полученную строку из файла. После этих действий у Вас будет рабочий аккаунт.

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

Управлять аккаунтом на Nodester можно либо вызывая методы API с помощью curl, либо установив из npm утилиту для работы с хостингом из командной строки:

npm install nodester-cli

Методы API можно посмотреть на этой странице, а я воспользуюсь приложением. После установки надо добавить в приложение свои логин и пароль:

nodester user setup myusername mynewpassword

Теперь можно создавать приложение. В папке с файлом приложения делаем:

nodester app create myappname server.js

Здесь myappname — имя приложения, по которому потом можно будет к нему обращаться, server.js — файл, который требуется запускать для старта приложения (необязательный параметр). Удобно что файл можно указать сразу. После того как приложение создано, отправлять изменения на сервера можно так же как и с другими хостингами: командой git push. Правда, удалённый источник придётся добавить в репозиторий самостоятельно:

git remote add nodester url_from_api

URL, который здесь надо использовать, будет выдан при создании приложения.

Другие возможности

• Nodester тоже умеет работать с npm, но немного не так как Duostack. Необходимые Вашему приложению пакеты указываются командой nodester appnpm (либо соответствующим вызовом API).
• Из хранилищ пока предлагается только облачный вариант CouchDB: CouchOne.
• Можно получать доступ к логам приложения
• Можно повесить сайт на Nodester на собственный домен
• На хостинге работает Socket.IO
• Nodester можно развернуть на собственном сервере

На последнем пункте я хочу остановиться поподробнее. В отличии от предыдущих хостингов Nodester предоставляет весь исходный код для создания собственного сервера с Node, апдейтами по git push, мониторингом, прокси для http-запросов собственной разработки и т.д. Скачать всё это можно на Github, инструкции по установке на Amazon/Rackspace (на английском) можно найти в этом файле.

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

• Сайт Nodester
• Руководство по API
• Исходный код для размещения на своём сервере