Node.JS *

Наверняка у многих, кто пробовал использовать Node.JS в своих проектах, возникал вопрос о деплое npm пакетов на сервера. В нашей инфраструктуре широко используются машины с Ubuntu, куда мы деплоим сервисы через debian пакеты. Хочу рассказать об инструменте, который мы написали для упрощения создания debian пакетов и которым успешно пользуемся уже больше года.

В этой публикации я поставил перед собой несколько целей:

• Сравнить разные стили программирования работы с БД Firebird в NodeJS;
• Найти наиболее производительный вариант;
• Получить в результате руководство к действию тем, кто начинает использовать Firebird в NodeJS.

Дальше много кода…

Springbase объявляет о бесплатном хранении реляционных баз данных в объёме до 100 мегабайтов с траффиком до гигабайта в месяц.

Доступ к базам данных возможен посредством административного веб-интерфейса, а также из джаваскриптов, написанных для движка Node.js при помощи специального модуля node-springbase. Обращение к БД происходит посредством SQL-запросов:

Являясь постоянным пользователем форума nodejs.ru, часто наблюдаю картину когда люди начиная изучать nodejs сравнивают ее с php, а иногда пытаются работать с ней так как с php. Я бы хотел объяснить “на пальцах” разницу между php и nodejs применительно к работе сайта. Статья предназначена для новичков. Я намеренно буду говорить очень упрощенно, не вдаваясь в глубокие подробности, что бы как можно проще показать различия в технологиях.

При реализации модели для манипуляции с данными в MongoDB, я пришел к выводу, что нужно как то избежать проблем с вложенностью асинхронных вызовов. Я не знал о существовании Step для Node.js и решил создать свой велосипед. Чем и хотел бы с Вами поделиться, уважаемые Хабро пользователи.

В данной статье пойдет речь о реализации паттерна Repository во взаимодействии с Mongoose ODM для использования в Node.js проектах.
Средства ODM Mongoose — предоставляют очень удобую обертку реализации запросов к MongoDB посредством схожего с LINQ стиля. Ниже представлена реализация репозитория на примере модуля UserRepo для модели User.

Начал осваивать Mac OS X. Поистине замечательная операционная система. Очень нравится интерфейс и продуманность функционала. Многие вещи хотелось бы увидеть в Windows. Но речь не об этом. Так вот решил я все таки посмотреть получится ли у меня запустить Cloud9 ide локально на Mac OS X Lion 10.7.3. Ранее я запустил эту IDE на Ubuntu 11.10. После многочисленных неудачных попыток, запустить понравившуюся мне IDE под Mac OS X, я было уже решил бросить эту затею, хотя на официальном сайте было указано что в качестве поддерживаемых ОС есть и Mac OS, но запустить упорно не получалось.

Когда на одном сервере находиться несколько одновременно работающих node.js сайтов, для них необходим общий механизм запуска. Наиболее простой вариант, а также наиболее производительный, это запуск одного приложения, которое подключает все нужные сайты. Механизм подключения должен быть без ограничений для создаваемых сайтов, и максимально простым. Он должен быть стабилен, при критической ошибке на одном из сайтов, другие все равно должны продолжать свою работу.
Все подключаемые веб-приложения должны быть легко переносимы на отдельный хостинг. Необходима поддержка как отдельных доменных имен, так и поддоменов для определенного доменного имени.

Допустим, есть две директории, в которых находятся веб-приложения:

— /var/www/domains/, с каталогами site.ru, othersite2.ru и тд.
— /var/www/subdomains/, с каталогами site3, othersite4 и тд.

Чтобы сайты были доступны по соответсвующим адресам (site.ru, othersite2.ru, site3.example.com, othersite4.example.com), потребуется запустить данную команду:

$ vhoster -n example.com -s /var/www/subdomains/ -d /var/www/domains/ --port 80 --host 0.0.0.0
vhost: site.ru
vhost: othersite2.ru
vhost: site3.example.com
vhost: othersite4.example.com

Для тех, кому нужен vhoster и интересна его реализация, прошу под кат.

Не так давно, а именно 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, на основе которого невозбранно работает, например, вот какой код, предлагаемый в качестве примера: