Node.JS *

Документация — одна из самых важных составляющих любого проекта, особенно если этот проект с открытым кодом, который будут читать другие люди. Чтобы сделать мир opensource чуточку лучше, я попытался собрать свои знания в области организации модулей nodejs проектов и сделать такой инструмент как Makedoc!. Ремарка для адептов ruby: это почти то же, что и rdoc.info для руби.

Этот инструмент анализирует код проекта, выделяет потенциально документируемые куски кода (не важно, с документацией или без), и генерирует статический набор страничек, описывающих проект.

В кратце шаблон использования такой: идем на jsdoc.info/[githubusername]/[projectname] и видим готовую документацию по проекту. Либо идем на jsdoc.info/[githubusername] и получаем список проектов для которых можно сгенерировать документацию.

За деталями реализации прошу под кат.

Вы бывали на вечеринках, где друзья с работы и друзья из колледжа не разговаривают?

Я запостил видео на Tumblr, которое бы никогда не запостил на Facebook:


Это гитарист, отжигающий под «Bangarang» Skrillex'а.

25 марта на Гитхабе в репозиториях компании LearnBoost, широко известной в сообществе Node.js благодаря проектам Socket.io, mongoose, cluster, появился небольшой модуль console-trace. Это маленькое, но полезное дополнение функции console.log(), которое раньше было доступно только в консолях браузеров — вывод имени файла и номера строки, из которой вызвана console.log().

Наверняка у многих, кто пробовал использовать 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, а сегодня ещё и поздравляет ;)