Node.JS *

Не так давно, а именно 2011-10-05 вышла новая версия фреймворка connect 2.0. На хабре был замечен пробел, а тут выдалось пару свободных часов. Буду писать сразу про версию 2.0.1 вышедшую 29 февраля. Во второй версии сделали много очень нужных и долгожданных изменений.

В прошлой статье я начал рассказывать о своём опыте разработки экспериментального WEB-проекта «Что делать?» на Node.JS. Первая часть была обзорной, в ней я постарался раскрыть плюсы и минусы технологии, а также предупредить о проблемах, с которыми, возможно, придётся столкнуться в ходе разработки. В этой статье я подробнее остановлюсь на технических деталях.

Несколько слов о «хабраэффекте»

Прошла неделя с момента пиара на хабре моего проекта «Что делать?». Я напомню, что этот проект начинался, как эксперимент по разработке среднестатистического WEB-проекта целиком на JavaScript (Node.JS). Сейчас я хочу поделиться с сообществом результатами этого эксперимента, полученным полезным опытом, а также подробной картой с отмеченными на ней граблями.

Эпизод 1: начало пути

В процессе работы над проектом с использованием Node.js в качестве серверсайда, возникла задача запуска JS скрипта в качестве сервиса, со всем плюшками типа start, stop, restart. По этой теме в принципе уже достаточно информации, но она в основном сводится к использованию Monit + Init под линуксом, либо кратких советов типа «use nodemon, Luke».

В моём случае в качестве продакшн-сервера была машина на FreeBSD. В качестве утилиты запускающей JS файл как процесс мне приглянулся forever. Эта штука, в отличии от nodemon, умеет следить за запущенными под ней процессами и поднимать их при падении без ожидания изменения в исходниках скрипта, что очень удобно именно на продакшене. К тому же forever умеет показывать текущий список запущеных процессов, с отображением их аптайма, ну и позволяет останавливать/перезапускать процессы по имени или индексу.

Недолго думая, был написан rc.d скрипт:

Компания-создатель облачной IDE Cloud 9 на конференции NodeSummit, посвященной Node.js, планирует представить ряд новых улучшений в своем продукте, попутно представив сообществу англоязычный сборник документации по Node.js, который доступен по адресу nodemanual.org.

Весь сборник разделен на две части — Basic и Tutorials; при этом как таковых «HowTo» для новичков нет, поэтому можно сказать, что целевой аудиторией сайта являются все же профессионалы в Node.js. Авторами большинства статей называются разработчики Mozilla и Joyent, а примеры, представленные в документации, можно запустить в Cloud9, имея в ней аккаунт. GitHub сборника можно найти здесь.

Также Дениэлс намерен представить и блог nodebits.org, направленный на "… поддержание духа Node.js и инновационности". Сейчас блог не отличается большим числом статей (первая датируется только 30 декабря), но его обещают пополнять, называя среди авторов ведущих разработчиков Node.js-сообщества Тима Касвелла, Берта Белдера и Бена Нурдхаиса (Tim Caswell, Bert Belder, Ben Noordhuis).

[NodeManual]

Обнаружив трёхдневной давности правку в вики Node, я жмякнул по приведённой там гиперссылке и попал на сайт-каталог «The Node Toolbox», довольно полезный. Как я понял тотчас же, целью этого сайта является распределение по категориям (или по тегам) всех тех пакетов с джаваскриптами для Node, которые содержатся в каталоге пакетного менеджера npm. Таким образом, сайт этот может быть ценною отправною точкою для поиска пакетов для Node по их предназначению. (В мире открытого кода это средство, как и другие до него, позволяет человеку внимательному не переизобрести ненароком чей-нибудь велосипед.)

Наверху сайта «The Node Toolbox» видна «горячая десятка» наиболее свежих пакетов и десятка наиболее используемых пакетов (по числу зависимостей других пакетов от них) — в общем-то это средство менее полезно и инновационно, чем список категорий, потому что эти рейтинги и без того видны на search.npmjs.org (притом там в рейтингах видать по пятнадцать пакетов, а у «The Node Toolbox» всего лишь по десять).

Более или менее пристальное вглядывание в эти рейтинги на протяжении нескольких последних месяцев привело меня ко впечатлению (быть может, и ошибочному: архивов-то рейтингов я не веду, а полагаюсь на память) о постепенном росте популярности пакета async, сейчас вошедшего ужé в десятку наиболее используемых. Он полезен тем, что содержит два десятка функций, серьёзно упрощающих объединение вызовов асинхронных функций, составление из них более крупных фрагментов алгоритмов. Не могу не отметить, что наблюдаемая популярность вполне заслужена пакетом async. Есть основания думать о части функций пакета async (притом о заметно большой части их) как о своего рода асинхронном аналоге соответствующих функций underscore, используемых при пакетной обработке коллекций (то есть массивов и объектов) — а ведь тот же рейтинг называет пакет underscore наиболее используемым в других пакетах для Node. Логично, что популярен и асинхронный аналог его.

Со вчерашнего дня, господа, можно написать вот такой скрипт:

// функция преобразования строки JavaScript (UTF-8) в UTF-16
function TEXT(text){
   return new Buffer(text, 'ucs2').toString('binary');
}

var FFI = require('node-ffi');

// подключаемся к user32.dll
var user32 = new FFI.Library('user32', {
   'MessageBoxW': [
      'int32', [ 'int32', 'string', 'string', 'int32' ]
   ]
});

// диалоговое окно
var OK_or_Cancel = user32.MessageBoxW(
   0, TEXT('Привет, Хабрахабр!'), TEXT('Заголовок окна'), 1
);

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

Это стало возможным потому, что модуль node-ffi (обёртку вокруг той необыкновенно полезной библиотеки libffi, которая используется для вызова библиотек на языке Си не менее чем в восьми других языках) вчера портировали на Windows.

Autodafé — node.js фреймворк, начало читайте в этой статье: habrahabr.ru/blogs/nodejs/135089

Основная часть статьи будет посвящена перенаправлению запросов в autodafe, формированию URL и т. п. Но для начала мне бы хотелось осветить общие принципы работы приложения с подключенными клиентами, для того чтобы было понятнее какую часть рабочего процесса мы будем обсуждать.

Откуда берется пыль

Начнем со схемы, отображающей подключение клиентов к приложению:



На схеме можно увидеть несколько пользователей, которые пользуются различными устройствами и различными браузерами, которые в свою очередь подключаются к приложению по различным протоколам. (В данный момент к autodafe можно подключиться только по http и websockets)

В приложении каждому подключению соответствует один Client. Client создается для каждого http запроса и подключения по websockets. Клиенты с одинаковым идентификатором сессии принадлежат одному экземпляру Session. Обычно одна сессия в приложение соответствует одному браузеру.

Ну и для логического завершения на схеме приведен компонент “users”, который позволяет привязать различные сессии, прошедшие специальную авторизацию к одному объекту UserIdentity. Таким образом в приложении каждый объект UserIdentity соотносится к одному реальному пользователю.

Совсем недавно npm стал радовать нас и под win, а сегодня ещё и поздравляет ;)

Autodafe — node.js фреймворк для разработки веб приложений

Содержание статьи может описывать неактуальный код. У фреймворка уже давно свой сайт autodafe.ws

Самые вкусные плюшки из коробки:

• архитектура: MVC + подключаемые модули
• Mysql ORM (ActiveRecord с поддержкой отношений, асинхронное подобие того, что предлагает Yii framework для PHP )
• HTTP сервер
• WebSockets ( обертка для socket.io )
• удобное перенаправление запросов и человеко понятные УРЛ
• управление пользователями
  • аутентификация и авторизация, сессии
  • система управления правами ролей пользователей
• почта
• логирование в консоль, фс и на почту
• шаблонизатор

Ложка дегтя:

• очень малая часть задокументирована
• задокументированная часть плохо задокументирована
• плохо задокументированная часть задокументирована только на русском языке
• тестами покрыт не весь фреймворк

В последнее время Microsoft довольно активно поддерживает проект Node.JS. Уже проделана большая работа по портированию Node на асинхронный API ввода/вывода Windows (IOCP) и вот недавно анонсирована поддержка Node.JS в облачном хостинге Microsoft Windows Azure. Доступ к облачным сервисам Azure доступен через SDK опубликованном на GitHub, который также можно установить с помощью npm:

npm install azure

В целом это выглядит как хорошие новости для сообщества Node.JS. Несмотря на большой интерес, в отношении проекта сохраняется некий скепсис как о «несерьезной» технологии не готовой для использования в «настоящих» проектах. Вслед за такими разработчиками многие заказчики также не спешат использовать платформу Node для своих проектов. Так что поддержка со стороны Microsoft может помочь не только с размещением проекта в облаке, но и возможно развеять некоторые страхи для тех кто рассматривает Node.JS как технологию для своего нового проекта.

Библиотека jQuery — это общепризнанное средство манипуляции сразу несколькими форматами данных (XML, HTML, объекты DOM, обыкновенные объекты), да притом работающее посредством удобного (цепного) вызова методов с удобными (краткими) названиями. Поэтому ничуть не удивляют попытки приспособить jQuery не только к одному клиентскому, но также ещё и к серверному джаваскрипту — в частности, к Node.js.

Признаюсь честно, что когда разработчики jQuery превозмогли проблему №7102, то её название («Register jQuery as a CommonJS async module») на какое-то время даже заставило меня обмануться: я сперва подумал было, что и в Node.js (так как модули Node.js и СommonJS имеют немало общего) отныне jQuery станет работать невозбранно. Ан нет, не тут-то было. Пристальное вглядывание в коммит и в запрос на слияние позволяет осознать, что jQuery, в сущности, обрёл возможность регистрироваться только как AMD-модуль и даже проверяет свойства define.amd и define.amd.jQuery перед саморегистрацией.

Собственно говоря, архитектура jQuery «затóчена» под употребление в условиях браузерной DOM: код jQuery полагается на существование объекта window, который служит аргументом главного замыкания, окаймляющего весь код jQuery. Прежде же таких неявных предположений было ещё больше, и только с устранением проблемы №6690 библиотека jQuery перестала полагаться на существование глобальных объектов navigator и location, начав вместо того получать их как свойства объекта window. (Понятно, что такое предположение никак не подходило для Node.js, где глобальные объекты служат свойствами объекта global, а вовсе не window; а равно не подходило и ко многим прочим реализациям CommonJS.)

Потому для запуска jQuery в Node.js применяются готовые реализации браузерной DOM — такие, как пакет jsdom, на основе которого невозбранно работает, например, вот какой код, предлагаемый в качестве примера:

Оказывается, ещё в начале 2011 года японский исследователь по имени Тосио Мори, действующий под псевдонимом forest1040, выяснил, что возможно запустить Node.js на устройстве с Android, если обладать правами рута. Итоги его наблюдений изложены на нижеследующих тринадцати слайдах:


Для тех, кто не вполне понимает по-японски, переводчик Jed Schmidt создал англоязычную версию инструкций, выложенную во блоге у forest1040. Говоря вкратце, предлагаемая последовательность действий вот какова:

• Получить права рута на устройстве под Android
   
• Использовать qemu и собрать Linux для ARM
   
• Внутри ARM Linux собрать Node.js
   
• Скопировать собранный Node.js на устройство под Android

Великий китайский файервол попросту заблокировал доступ к домену nodejs.org из страны. Связано это ни с чем иным, как с вышедшей новой версией node.js под номером 0.6.4. Это может показаться странным, но файервол действительно блокирует все сайты содержащие цифры 64 и 89. Связано это с печальными событиями имевшими место в 1989м году. Тогда на площади Тяньаньмэнь были расстреляны студенты. Правительство пытается любыми, даже такими безумными, способами ограничить доступ современного населения к истории тех событий.

     О чем это

Являясь автором модуля подключения к Firebird для NodeJS, я долго откладывал публикацию о нем, считая, что модуль еще достаточно сырой. Кроме того, развитие модуля несколько застопорилось, поскольку весь необходимый мне функционал в нем уже присутствует (однако он еще далек от универсальности).
Время от времени только возникает необходимость исправить выявленную ошибку или подправить что-то для обеспечения совместимости с последней стабильной версией NodeJS. Надо сказать, что модуль не является популярным ввиду направленности NodeJS сообщества на NoSQL решения. А Firebird сообщество, видимо, смотрит на NodeJS с осторожностью, да и не такое уж оно и большое. К тому же довольно часто Firebird используется в связке с Delphi на платформе Windows, так что заинтересовать кого-либо из работающих под Windows специфичным Linux решением тоже тяжело. Однако, недавнее значительное продвижение проекта NodeJS в сторону поддержки Windows дало надежду на привлечение внимания таких людей к проекту. Эта публикация будет посвящена тому, как можно работать с Firebird из NodeJS. Будут даны инструкции по установке для Linux и Windows, примеры типовых сценариев работы. Топик, однако, рассчитан на тех, кто хоть немного знаком с Firebird (необходима рабочая копия сервера БД для экспериментов). Для тех, кто не знаком с Firebird, в конце публикации будут даны ссылки на ресурсы для изучения.

Заинтересовавшимся — добро пожаловать под кат.

Фреймворк NodeJS вышел на первое место в списке самых популярных проектов Github по количеству подписчиков (watchers).

1. node — 11 349 подписчиков
2. rails — 11 234
3. bootstrap — 10 924
4. jquery — 10 479
5. html5-boilerplate — 8 940
6. homebrew (пакетный менеджер для OS X) — 6 641
7. diaspora — 5 898
8. three20 (библиотека Objective-C для разработки од iPhone) — 5 380
9. devise (система аутентификации для Rails) — 5 249
10. Spoon-Knife (пустой репозиторий для обучения новых пользователей github, как делать форки и проч.) — 4 863

Вообще, рейтинг довольно субъективен. Например, на третьем месте Bootstrap, набор стилей и элементов UI от разработчиков Twitter, который появился на свет всего несколько месяцев назад. В первые недели после выхода он даже побывал в лидерах этого списка.

Как цифры с Github соотносятся с реальностью, можно судить по количеству фолловеров к тегам на StackOverflow: у NodeJS их 2200, у jQuery — 19 500, C# — 22 200, у PHP — 18 000, и даже у фреймворка ASP.NET 8300 фолловеров.

В официальном блоге Node.JS вчера (25 ноября) объявлено о выходе новой версии Node, под номером 0.6.3. Изменения не очень значительны: исправлен десяток ошибок да недочётов.

Я счёл это небезынтересным подарком ко дню рождения (по приятному совпадению, 25 ноября мне исполнилось 33 года). Однако в тот же день, задавшись вопросом «Как принять вывод Windows-команды, вызванной из node.js?», я начал в Windows XP серию экспериментов, конечным итогом которой стало обнаружение сразу двух ошибок Node при работе с кодировками под Windows.

Во-первых, при вызове команды методом require('child_process').exec(…) Node ожидает от неё вывода в кодировке UTF-8, тогда как в русифицированной системе Windows команды (например, dir) выводят текст в кодировке CP866.

Во-вторых, если дочерний консольный процесс изменит кодировку консоли, то будет воздействовать и на кодировку консоли родительского процесса Node (в частности, на вывод методом console.log) — получается, что консоль у них одна и та же, или что-то в этом же дýхе.

А теперь немного подробностей.

npm — это пакетный менеджер node.js. С его помощью можно управлять модулями и зависимостями.
Небольшая шпаргалка всех моих любимых команд npm:

• Установка npm
• Обновление npm
• Поиск пакетов в npm
• Просмотр информации о пакете
• Локальная установка пакетов
• Установка пакета в наше приложение
• Понимание разницы между глобальной и локальной установкой
• Глобальная установка пакетов
• Удаление локально установленного пакета
• Удаление глобально установленного пакета
• Установка определённой версии пакета
• Установка модуля с Github
• Связи любых пакетов локально
• Связи локальных пакетов для нескольких приложений
• Отмена связи между пакетами приложения
• Отмена связи пакета в системе
• Создание нового пакета
• Добавление нового пользователя
• Публикация пакета в репозиторий npm
• Удаление пакета из репозитория npm
• Управление правами доступа к пакетам в репозитории npm

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

• как установить рабочее окружение Node.js на своем компьютере;
• как писать код;
• как отлаживаться;
• как развернуть то, что получилось на удаленном сервере.

А тесты производительности в конце статьи возможно дадут ответ на вопрос зачем собственно вам может понадобится изучать Node.js.

Приветствую %habrname%!

Во вчерашней статье для меня в общем-то было ожидаемо, что большинству не будет интереса к nodejs, многие посмотрят только демо. Но к сожалению я не учёл, что и оценивать в статье будут именно игру! Хоть мне было и обидно потратив столько времени на написание статьи (а что самое главное игра писалась именно для статьи, а не наоборот), я сегодня решил написать продолжение.

Ну что же! Проведём работу над ошибками и сделаем работающую игру со всем о чём просили, но при этом не будем отклонятся от темы блога и рассмотрим все технические моменты с которыми столкнулись при тесте игры.