AI, Minecraft и Node.js
Пару месяцев назад я записался на онлайн-курс 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, но по моему это скорее название для какой нибудь библиотеки утилит).
Яндекс.Метрика
Последнее время с интересом слежу за развитием истории с проиндексированными смс, заказами (а теперь ещё и билетами). На Хабре (да и в Интернете вообще, по моему) все горой стоят за Яндекс — дескать, кто не закрыл нужные страницы с помощью robots.txt, тот сам себе злобный Буратино. Я не совсем согласен с такой точкой зрения. Как пользователь Яндекс.Метрики лично я пропустил момент когда она начала по тихому сдавать страницы в очередь краулера (и, соответственно, в индекс). Я использую кое где Метрику для статистики, и для меня такое открытие было неприятной неожиданностью. Причём я сейчас проверил в новостях метрики — о таком нововведении там ни слова. Хотя мне скрывать какие то страницы смысла не имеет, подобное изменение всё равно вызывает вопросы. Имхо, раз уж метрика привязывается к почтовому аккаунту, могли бы и разослать предупреждение.
Впрочем, это не означает что владельцы сайтов тут совсем ни при чём. При защите пользовательских данных подход security through obscurity ни к чему хорошему привести не может. Особенно если данные действительно личные (номера телефонов, адреса + состав заказа, данные о поездке), лучше защищать их явно, чем просто надеяться на то что никто и никогда этих страниц не увидит. И неожиданно изменившиеся правила игры не обернулись бы такими конфузами.
В общем, этот случай — хороший повод задуматься о безопасности пользовательских данных в своих проектах, не полагаясь на поведение поисковиков «по умолчанию». Обновить robots.txt, поставить авторизацию на страницах, которые содержат личные данные.
Kue — очереди с приоритетами на основе Redis
Если в Вашем проекте необходимо выполнять какие то задачи в фоновом режиме, будь то отправка почты или перекодирование видео, Вам следует присмотреться к Kue — инструменту для управления очередями задач с поддержкой приоритетов, метаданных и удобным веб-интерфейсом.
Случайная находка — dev-сервер Хабрахабра
Сегодня совершенно случайно обнаружил один из development-серверов Хабрахабра. Так получилось что как раз сегодня прошло 3 года с моей регистрации на ресурсе. Узнал я об этом, зайдя с утра в почту и увидев письмо от Хабрахабра с темой «Вам доступен значок ‘Старожил’«.
Точнее, таких писем было два.
Операции с однородными потоками данных
Недавно задумал написать вспомогательный модуль для node.js, чтобы облегчить работу с потоками для чтения. Например, быстро собрать по кускам ответ от сервера и представить в виде одной строки или JSON.
Я достаточно долгое время использовал связку Init+Monit для запуска скриптов node, но со временем стал натыкаться на минусы такой связки. Одна из самых серьёзных проблем — отсутствие возможности вывести лог в разные файлы в ранних версиях start-stop-daemon. Версия, поставляемая с Debian Lenny не поддерживает такой функционал, а сборка новой версии тянет за собой уйму непонятного барахла. В итоге, попробовав разные варианты, я остановился на runit как замене Init-скриптам.
Mantis + GraphViz
После предыдущего эксперимента мне понравилось работать с GraphViz, к тому же я давно хотел понять как именно использовать его для отрисовки графов, поэтому я решил сделать небольшой скриптик с использованием dot.
Большие файлы cachegrind
Сегодня пришлось столкнуться с необходимостью сделать профилирование для скрипта который исполнялся слишком долго. Для таких целей у меня стоит связка из XDebug + WinCacheGrind. XDebug отработал как положено, но файл cachegrind.out получился размером ~200 метров. WinCachegrind по каким то причинам каждый раз зависал, пытаясь его переварить (подозреваю что из за большого размера). В результате пришлось пойти другим путём.
Проблема решилась с помощью 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
Неделю назад в замечательном комиксе xkcd была упомянута интересная тема: прокси, задерживающий запросы к определённым сайтам на 30 секунд, как средство борьбы с прокрастинацией. Естественно, мне захотелось реализовать такую штуку но время для этого нашлось только сейчас.
Хостинг Node.js на Nodester
Ну что ж, серия обзоров хостингов похоже приближается к концу 
Сегодня я посмотрю на последний найденный мной сервис: Nodester (бывший NodeFu). Как обычно, чтобы получить к нему доступ надо записаться на бета-тестирование через вызов API:
curl -X POST -d "email=example@example.com" http://nodester.com/coupon
Читать далее…
