Получение записей из Tokyo Tyrant и асинхронно-синхронный код
Posted by: kuroikaze85 on: 08/02/2010
Пытаясь использовать Tokyo Tyrant для хранения записей блога, я столкнулся с неприятным багом. При получении записей и показе их на странице всё было нормально, но при попытке стресс-тестирования с помощью Apache Benchmark Нода просто вываливалась с ошибкой Error: Unhandled emitError. Сперва оказалось что я просто забыл добавить errBack к фукции поиска в Tokyo Tyrant (оказывается, это наказуемо не хуже чем Unhandled Exception), но потом в этой функции-обработчике я стал получать ошибки Tyrant Error: 1. Гуглинг ничего не дал, и я наконец задумался над тем как выполняется мой код в Node 
Прочтите эту запись до конца »
Шаблонизаторы в Node: Mu
Posted by: kuroikaze85 on: 05/02/2010
Итак, в написании блога настал момент когда просто выводить HTML стало недостаточно, и я стал искать шаблонизатор для сайта. Выбор пал на Mu – порт Mustache из Ruby, насколько я понял. И хоть с Ruby работать мне не приходилось, синтаксис и набор фич понравился. Чёткое отделение логики от представления (в шаблоне вообще нет кода), вложенные шаблоны, компиляция в функции. В общем, решил изучить.
Асинхронное программирование в Node.js: Ожидание нескольких событий сразу
Posted by: kuroikaze85 on: 04/02/2010
Постановка задачи
Представим себе такую ситуацию. Нам надо сделать поиск в базе Tokyo Tyrant (или любой другой) и получить найденные значения в виде JavaScript-объектов. Проблема состоит в том, что получение объекта из Tokyo Tyrant происходит с коллбеком. Т.е., у нас на руках после поиска оказывается несколько коллбеков – по числу ожидаемых объектов:
Слияние ветвей в Git без fast-forward
Posted by: kuroikaze85 on: 04/02/2010
При слиянии ветвей Git по умолчанию делает т.н. «fast-forward»: коммиты ветви выглядят так будто были сделаны в транк. Для мелких правок это может быть несущественно, но если ветвь представляет собой какую-либо feature, удобно видеть на каком коммите она начинается. Для этого надо мержить ветви с флагом --no-ff:
git merge <имя_ветви> --no-ff
Plurk переходит на Node.js для comet-соединений
Posted by: kuroikaze85 on: 01/02/2010
В субботу стало известно что Plurk (один из крупнейших сервисов микроблоггинга в Азии) перевёл свою систему comet-соединений на Node.js. Программисты проекта поделились спецификациями системы и некоторыми данными измерений производительности.
Итак, система поддерживает одновременно более 200 тысяч соединений, большинство из них в неактивном состоянии. Для этого используется один сервер с 32 Гб памяти и четырёхядерным процессором. На сервере крутятся восемь экземпляров Node.
В качестве базы данных используется собственная разработка LightCloud, основанная на Tokyo Tyrant.
Предыдущая система была написана на Java+JBoss Netty, расход памяти на одно соединение был примерно в 10 раз больше чем с Node и сервер периодически страдал потерей соединений.
Авторы не исключают что код их comet-сервера в будущем может быть выпущен под OpenSource-лицензией. Прямо сейчас задать вопрос авторам можно на сайте Ycombinator или в Google-группе Node.js.
Табличные базы в Tokyo Tyrant
Posted by: kuroikaze85 on: 29/01/2010
Табличный режим пока выглядит довольно непривычно. Функции put передаются попеременно ключи и значения (но первым передаётся id записи). Вот так может выглядеть добавление записей в простенький блог и доставание их оттуда:
Tokyo Tyrant — Exception: connection is not open
Posted by: kuroikaze85 on: 29/01/2010
При попытке написать блог на связке Node + nginx + Tokyo Tyrant наткнулся на интересную вещь. Нам нужно открыть соединение с Tyrant, чтобы сохранять и получать оттуда записи. Первый же вариант — открыть соединение вместе с инициализацией Nerve и использовать его по мере необходимости. В теории это должно работать (пока клиент один):
Хранилища данных в Node.js: Tokyo Cabinet/Tokyo Tyrant
Posted by: kuroikaze85 on: 26/01/2010
Этим постом я начинаю серию о key-value stores, доступных из Node.js. Вообще то первым должен был быть пост о Redis, но т.к. сам Redis недавно обновился до 1.2 а соответствующий модуль для node — ещё не успел, мы начнём с Tokyo Tyrant.
Блокировка стран в Sourceforge
Posted by: kuroikaze85 on: 25/01/2010
Сегодня Sourceforge официально заявил что вынужден ограничить использование сайта из некоторых стран, согласно законодательству США. Дело в том что США ведёт списки стран, в которые невозможен экспорт определённых технологий и услуг. С понедельника SF начинает автоматически блокировать пользователей из этих стран. В списке блокированных: Куба, Иран, Северная Корея, Судан и Сирия.
Напомню, с 2008 года Sourceforge предоставлял этим странам ограниченный доступ (можно было скачивать файлы, но не принимать участие в разработке). С 25 января сайт из этих стран стал недоступен совсем.
Ситуация, конечно, не очень хорошая. С одной стороны, такое разделение Интернета явно не пойдет ему на пользу. Sourceforge — достаточно значимый ресурс, его блокировка в некоторых странах — это удар по всему opensource-сообществу. С другой стороны, это может стимулировать другие подобные сервисы задуматься о способах преодоления таких юридических преград. Мне в частности интересно отношение к этому Github.
Со стороны SF, впрочем, принятое решение выглядит правильным. В конечном итоге, обслуживать большинство пользоваталей — лучше, чем вообще никого. За нарушение этих норм в США предусмотрены вполне реальные штрафы и тюремные заключения. Впрочем, SF выражает надежду что политика в отношении этих стран может смягчиться.
P.S.Как оказалось, Google Code тоже запрещает доступ странам из этого списка. В TOS Гитхаба подобный пункт не найден.
Автоматическое управление багами в Github с помощью microcline
Posted by: kuroikaze85 on: 22/01/2010
Для Node.js уже существует несколько модулей юнит-тестирования. И, так как большинство относящихся к Node вещей хостятся на Github, я решил быстренько реализовать Github API в виде модуля. В первую очередь это может понадобиться для того чтобы открывать/закрывать баги на Гитхабе прямо из юнит-тестов.
Прочтите эту запись до конца »
