Это интервью было проведено Олегом Подсечиным с Райаном Далом (Ryan Dahl) 8 июля 2010 г., вскоре после чтений Райана в Кельне. Олег — энтузиаст JavaScript, который управляет Ionsquare Ltd, специализирующейся в области ИТ-консалтинга.

О.П.: Первый вопрос на самом деле вводный. Как вы пришли к Node.JS? Был ли у вас раньше опыт работы с JavaScript? Когда вы начали работать с использованием JavaScript? А также с событийно-управляемым программным обеспечением?

РД: Я работал по контракту, и делал различные маленькие проекты на C, как правило, серверное событийно-управляемое программное обеспечение, и я понял, что пишу один и тот же код снова и снова. С — великолепный язык для работы, но я хотел что-то, позволяющее писать скрипты в том же стиле, в котором я обычно программирую серверное ПО.

Nodeload, первому проекту команды GitHub, выполненному с использованием node.js, недавно исполнился 1 год. Nodeload, — это тот сервис, который упаковывает содержимое Git-репозитория в ZIP-архивы и тарболы. С тех пор нагрузка на сервис росла в течение года, и мы столкнулись с различными проблемами. Почитайте о происхождении Nodeload, если вы не помните, почему это работает так, как работает сейчас.

По существу, у нас стало слишком много запросов, проходящих через один сервер nodeload. Эти запросы запускали процессы git archive, которые запускали SSH-процессы для общения с файловыми серверами. Эти запросы постоянно записывали гигабайты данных, а также передавали их через nginx. Одной простой идеей было заказать больше серверов, но это создало бы дубликат кэша заархивированных репозиториев. Я хотел избежать этого, если возможно. Итак, я решил начать все сначала и переписать Nodeload с нуля.

Для меня это было неожиданностью, когда увидел на блоге Node.JS «Windows Executable node.exe».
Попробовал сие чудо на win7, стартовало без всякого шаманства.
В тестирование не углублялся.

Интро

Dotcloud — это это облачная платформа для развертывания приложений. Стек на DotCloud включает в себя более 10 различных сервисов среди которых есть и Node.JS.

Мои первые впечатления от DotCloud были весьма положительные. Можно практически забыть о том как развертывать приложение и полностью сосредоточится на коде. Работа по развертыванию сводится к установке DotCloud CLI и настройке файла окружения dotcloud.yml. Установка клиента под Linux/MacOS тривиальна:

sudo easy_install pip && sudo pip install dotcloud

Что такое TameJS ?

TameJS — это расширение Javascript, которое делает событийное/асинхронное программирование более простым и элегантным. Его очень просто использовать с nodejs или другими v8-проектами.

NodeBeginner.ru — перевод на русский язык учебника по Node.js для начинающих «The Node Beginner Book» автора Manuel Kiessling.

Учебник предназначен для разработчиков с опытом работы с каким-либо объектно-ориентированным языком, немного знакомых с JavaScript и полных новичков в Node.js. Оригинал ещё находится в процессе написания, законченно около 90%. Перевод будет соответственно обновляться.

Я рад рассказать о том, что Microsoft в сотрудничестве с Joyent предоставит ресурсы для портирования Node на Windows. Как вы уже могли слышать ранее в этом году, мы начали работу над нативным портом на Windows — с целью использовать высокопроизводительный IOCP API.

Эта работа требует в значительной степени модифицировать базовую структуру и мы очень рады тому, что теперь получаем официальное руководство и инженерные ресурсы от Microsoft. От Rackspace так же выделено время Bert Belder для выполнения этой работы.

Результатом будет официальный бинарный релиз node.exe опубликованный на nodejs.org, который будет работать на Windows Azure и других версиях Windows начиная с Windows Server 2003.

От переводчика: Я только начинаю присматриваться к Node.js, и, обнаружив это руководство, сильно пожалел, что оно не попалось мне на глаза раньше. Надеюсь, что этот перевод поможет многим разобраться, что же такое Node, и с чем его едят.

У вас уже чешутся руки попробовать Node.js и пора начинать обрабатывать начальство? Не торопитесь! Для некоторых компаний, которые я консультировал на предмет того, подходит ли им Node.js, правильный ответ был — «Нет!»

Это руководство — набор основанных на моём личном опыте советов для тех, кто хочет узнать, имеет ли смысл применять Node у себя в компании, и, если да, то как убедить в этом начальство.

Три месяца назад мы решили отказаться от использования Django на нашем сайте и переписать все с нуля на серверном JavaScript под Node.js (уж если бывает в жизни стартапа время, когда можно серьёзно менять инфраструктуру, так это в самом начале пути — когда есть наибольшая свобода маневра).

Что заставило нас принять такое решение? Одна простая мысль — стек LAMP мёртв. За два десятилетия, прошедшие со времени его рождения, произошли фундаментальные изменения в протоколах, контенте, серверах и клиентах, на которых построен Веб. Можно выделить три эры развития паутины:

donnerjack13589 анонсировал новый модуль для Node.JS, — node-spdy, который добавляет поддержку протокола SPDY, который был предложен компанией Google и внедрен в Chromium/Google Chrome и на сайтах компании Google (подробнее...).

Напомню, что основной целью при создании протокола SPDY было снижение задержек при доставке контента.

Пример использования модуля node-spdy:

var options = {
  key: fs.readFileSync(__dirname + '/../keys/spdy-key.pem'),
  cert: fs.readFileSync(__dirname + '/../keys/spdy-cert.pem'),
  ca: fs.readFileSync(__dirname + '/../keys/spdy-csr.pem'),
  NPNProtocols: ['spdy/2']
};

spdy.createServer(options, function(req, res) {
  res.writeHead(200);
  res.end('hello world!');
});

Приветствуется помощь сообщества в разработке.

Наверное, каждый, кто начинает изучать nodejs, испытывает трудности с переходом на событийно-ориентированное программирование. Все просто, пока мы можем выполнять действия последовательно: начинать следующее, дождавшись завершающего события от предыдущего. Но что делать, если таких действий много и они продолжительны во времени? А если мы не можем продолжать, пока не дождемся завершения каждого из них?

Надавно была опубликована библиотека node-fibers, вносящая в nodejs и v8 поддержку замечательного fiber/coroutine — тоесть, возможность использовать yield.
Параллельно, на nodejs groups прошел целый ряд обсуждений на тему всевозможных вариантов упрощения асинхронного синтаксиса.

Вдохновившись возможностями, которые дают «волокна», я написал библиотеку node-sync, которая делает разработку в асинхронном окружении nodejs значительно удобнее, а код — нагляднее.

Синопсис

// Обычная асинхронная функция, вызывает callback с результатом через 1 сек
function someAsyncFunction(a, b, callback) {
    setTimeout(function(){
        callback(null, a + b);
    }, 1000)
}
// Вызываем эту функцию синхронно, используя Function.prototype.sync(),
// работающий по тому же принципу, что и call()
// на этом моменте текуший поток "зависнет" на секунду, пока функция не вернет значение
var result = someAsyncFunction.sync(null, 2, 3);
console.log(result); // "5" через 1 секунду

В статье пойдет речь о Must Have тулзе для удаленной отладки Node.js приложений либо кода на WebKit браузерах node-inspector.

Для отладки кода в браузере, впринципе удаленная отладка и не нужна, не считая мобильных устройств, где она фактически не возможна потому что крайне не удобна. Совсем другое дело с серверным JavaScript. Node.js имеет несколько отладчиков, восновном продвигают ndb Node Debugger — консольная утилита для дебага Node.js приложений. Подходит только для фанатов консоли либо для мазохистов. Работать не удобно, отлаживать долго, по сравнению с отладкой кода в том же FireBug.

Что же умеет node-inspector:
1. Удаленная отладка
2. Отладка в графическом интерфейсе WebKit-debugger (На клиент ничего не нужно ставить — у вас все уже есть)
3. Редактирование runtime-кода!
4. Использует WebSockets, и никакого polling'а!
5. Удаленное профилирование блоков кода c использованием v8-profiler

Сделано под вдохновением этого топика.
Обычный JavaScript, к которому все привыкли, не даёт средств работы ни с файловой системой, ни с двоичными данными, поэтому все описанное ниже будет про node.js.

Страничка Wiki, детально описывающая изменения в API между ветками 0.2.x и 0.4.x.

Важные изменения по сравнению с веткой 0.2.x:

В комментариях к моему предыдущему топику об асинхронном программировании, коллбеках и использовании process.NextTick() в Node.js было задано немало вопросов о том, за счёт чего получается или может быть получена большая производительность при использовании неблокирующего кода. Постараюсь это наглядно показать :) Статья призвана в основном прояснить некоторые моменты работы Node.js (и libeio в его составе), которые на словах бывает трудно описать.

Пример обработки запросов сервером с блокирующим чтением:


В первую очередь прокомментирую полезность использования неблокирующего ввода/вывода. Как правило, использовать блокирующие операции в Node.js стоит лишь на этапе инициализации приложения, и то не всегда. Правильная обработка ошибок в любом случае потребует использования try/catch, так что код при использовании неблокирующих операций не будет сложнее, чем при использовании блокирующих операций.
Нужно лишь помнить, что случае, когда запросов неблокирующих операций может оказаться больше, чем потоков libeio. В этом случае новые запросы будут становиться в очередь и блокировать выполнение, однако для программиста это будет происходить прозрачно.

Несмотря на то, что большинство из изучающих Node.js в какой-то мере знают JavaScript и имеют опыт использования его в контексте браузеров, при обсуждении практических моментов многие встречаются с трудностями в понимании работы стандартной библиотеки и механизмов обеспечения асинхронного выполнения кода, содержащего множество вложенных коллбеков. Также часто возникает недопонимание, Я постараюсь вкратце описать порядок работы event loop в Node.js и рассказать, на какие моменты стоит обратить внимание при написании качественного асинхронного кода. Думаю, что статья будет полезна и тем, кто занимается написанием производительных фреймворков для браузеров.

В течении последних месяцев стало ясно, что возрастающая популярность Node требует большей и лучше организованной команды разработчиков. Действительно, чтобы Node стал более популярен, и возможно стал следующим PHP, требуются инвестиции в команду разработчиков на полной занятости. Нужна компания, поддерживающая их и позволяющая наладить отношения с большими компаниями, которые могут использовать Node в своих проектах и внести свой вклад в проект.



Основной бизнес Joyent (облачные вычисления) вполне отвечает духу свободного и открытого Node. По этим причинам я заключил соглашение с Joyent об официальной поддержке Node.js. Единственное изменение, которое коснётся разработчиков — CLA будет подписываться не со мной, а с Joyent. Node будет продолжать регулярно выходить под лицензией MIT. В рамках соглашения — в дополнение к поддержке моих разработок — мы наняли Isaac Schlueter и планируем расширить команду ещё на одного человека в ближайшее время. Скоро мы начнём сдавать в аренду наши минималистичные инстансы no.de (хостинга с поддержкой Node) и разрабатывать на заказ различные модули и дополнения для Node.

Под катом описание изменений в выпущенных вчера версиях Node.js v0.2.5 и v0.3.1.

Прошедшие выходные могут похвастаться двумя релизами Node.js: очередной минорной версией в ветке v0.2.x и официальным релизом ветки v0.3.x.
И пусть разрабатываемая ветка всё ещё отмечена как «нестабильная», в ней ожидаются существенные улучшения производительности, переносимости и добавление новых возможностей, о которых стоит знать уже сейчас. Тем более, что эта версия уже вполне работоспособная.
Также в конце топика бонус в виде ссылок на репозитории пакетов Node.js v0.2.x и NPM (Node.js package manager).

Привет, ребята! С этого момента я хочу начать цикл статтей с подробностями по созданию сообственного MVC фреймворка для node.js, название которому будет — Spirit.

Первая статья будет состять из четырех частей:
1. Идея и миссия фреймворка
2. Настройка сервера
3. Создание каркаса фреймворка
4. Создание продвинутого и удобного роутера

Предупреждаю сразу, что статья — огромна, с кучей текста и большими блоками кода.