Я просто хотел бы шокировать вас моими последними достижениями в области хакинга: я создал двунаправленный мост к библиотекам выполнения Objective-C из среды Node. Эта сумасшедшая штука позволяет делать замечательные вещи, например, писать родные приложения для MacOS X и iOS полностью на Node и JavaScript!

Я создал высокоуровневую библиотеку, которую назвал NodObjC, и она предлагает лёгкий для использования API, непосредственно формируемый из API библиотек Objective-C. Вот пример из README:

var $ = require('NodObjC');

// First you need to "import" the Framework
$.import('Foundation');

// Setup the recommended NSAutoreleasePool instance
var pool = $.NSAutoreleasePool('alloc')('init');

// NSStrings and JavaScript Strings are distinct objects, you must create an
// NSString from a JS String when an Objective-C class method requires one.
var string = $.NSString('stringWithUTF8String', 'Hello Objective-C World!');

// Print out the contents (calling [string description])
console.log('%s', string);
//   → Prints "Hello Objective-C World!"
pool('drain');

Последние несколько недель я использую все свободное время, которое могу найти, чтобы обдумать, какие технологии мы будем использовать, чтобы реализовать первую версию BankSimple. Многие люди, вероятно, предположат, что я сразу же предпочёл Scala, в связи с тем, что я был соавтором книги об этом языке, но я подхожу к решению инженерных задач совершенно иначе. Каждая проблема имеет соответствующий набор применяемых технологий, и задача разработчика, — обосновать необходимость их использования.

(Кстати, Scala, может быть, хорошо подходит для BankSimple, в немалой степени из-за большого количества стороннего кода на Java, с которым мы должны интегрироваться, но это уже совсем другая тема для блога, и даже, скорее всего, для совершенно другого блога).

Одной из самых обсуждаемых технологий среди Hacker News является Node, окружение для разработки и запуска событийно-управляемых приложений JavaScript на виртуальной машине V8. В рамках выбора технологий для реализации проекта я выполнил оценку Node. Вчера я выразил некоторый общий скепсис относительно Node, и автор этого окружения, Райан Дал, попросил, чтобы я изложил свои мысли более подробно. Так вот, приступаю.

В данной статье я попытаюсь показать, как можно создать простой чат, используя Node.js в связке с Socket.IO. Изначально я хотел построить чат на чистых Websockets, но столкнулся с практически полным отсутствием готовых реализаций сервера для них в Интернете. Так что решил не изобретать велосипед, а использовать готовую библиотеку.
В моем случае сервер работает под Ubuntu, поэтому все примеры будут для неё (и ссылки в примерах — на него же).

Установка компонентов

Первым делом нам потребуются собственно Node.js (инструкция по инсталляции и ссылки на скачивание здесь) и Socket.IO. Модули для Node.js проще всего устанавливать, используя менеджер npm —

curl http://npmjs.org/install.sh | sh
npm install socket.io

Серверная часть

Структура серверной части такова: сервер принимает сообщение, если это команда — выполняет определенные действия, если просто сообщение — рассылает всем остальным участникам.

Это интервью было проведено Олегом Подсечиным с Райаном Далом (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 и рассказать, на какие моменты стоит обратить внимание при написании качественного асинхронного кода. Думаю, что статья будет полезна и тем, кто занимается написанием производительных фреймворков для браузеров.