Pull to refresh

Comments 19

Хвост первоисточника намеренно оборван при переводе: даже если бы я приводил гиперссылки и SHA-суммы установочных файлов, всё равно в целях безопасности вам следовало бы доверять одному только первоисточнику, а не то вдруг бы я подменил их.
Сразу скажу, что повышенное быстродействие радикально проявляется не во всех частных случаях.

Например, мой недавний скрипт для чтения заголовков фидонетовской эхопочты из базы JAM с анализом массива Subfields отрабатывает на Node 0.6.19 за ≈шесть секунд. В новой версии (на Node 0.8.0) выигрыш по времени составляет, во всяком случае, меньше одной секунды. (Точнее не могу сказать, потому что мне не хочется гонять его десятки раз и усреднять результаты.)
UFO landed and left these words here
Увидел «блогозаписи» и сразу понял кто автор =)
PS Спасибо за приведенные измерения.
Очень радует появление worker.send(message, [sendHandle]) и доменов
На счёт первого пункта (второго аргумента у .send) могу сказать, что меня это не только радует, но и экономит мне кучу времени в рабочем проекте. Ура!
Напишите о впечатлениях как-нибудь? :)
Если выгорит, почему бы и нет? :) Просто в связке клиент-сервер-fork, где fork должен общаться с клиентом, реализация этого путём обмена сообщениями send между сервером и fork'ом адски выносила мозг.
Хотя, а что тут писать? Только если о своём горьком опыте проектирования. Рад, что теперь этот функционал send'а в стабильной версии.
У меня просто сервер крутится на node.js, и в некоторых, особых случаях, приходится «считать факториал».
Cluster использовать — не вариант, т.к. «факториалу» нужно только соединение с особой базой данных, для которой насписан самодельный драйвер, с другой стороны, основной сервер в require имеет адскую кучу зависимостей.
Приходилось fork'ать другую программку с «программой-факториалом» и общаться с основным сервером через send, чтобы он что-то отправлял клиенту. Причем сценариев отправки — море.
Теперь, надеюсь, станет гораздо проще.
Да мне в целом интересно, кто как использует и чего с помощью Node.js уже добились :)
А адекватной иерархии Error-классов и их наследования так и не появилось?
Ну вот это:
var MyError = function (code, msg) {
    Error.call(this);
    Error.captureStackTrace(this, this.constructor);
    this.code = code;
    this.name = 'My Error';
    this.message = msg;
};
MyError.prototype = Error;
MyError.prototype.constructor = MyError;

— извращение. CoffeeScript несколько улучшает дело, но не сильно.
Хочется что-нибудь вроде:
var MyError = Error.extend('My Error', function (code, message) {
    Error.call(this, code, message);
});

Это касательно наследования.

А с иерархией вообще беда, насколько я заметил (могу ошибаться, буду рад, если меня поправят), ошибки в разных модулях абсолютно не разнесены по типам (т.е. например ошибки в fs все — Error, отличаются только code и errno). Во-первых эти доп. поля нигде не описаны (я не нашел), во-вторых не получается писать такой код:
if (err instanceof NotExistsError) {
    // handler 1
} else if (err instanceof MemoryError) {
    // handler 2
} else {
    // handler 3
}
Хочется что-нибудь вроде:
var MyError = Error.extend('My Error', function (code, message) {
    Error.call(this, code, message);
});

Ну тут уж Node.js не причём — это библиотека общего назначения для JavaScript, а фреймворк с конкретными целями. Если вы хотите избежать нескольких лишних строчек для описания наследования — возьмите Mootools.Core, например.
Или напишите хелпер, который был бы ещё короче: var MyError = Error.extend('My Error');

По поводу того, как представляются ошибки — имхо вы предлагаете слишком навороченную концепцию. Можно было бы для каждого кода ошбики сделать свой класс конечно, но чем тогда ваш код с условиями на instanceof будет отличаться от кода с условиями на err.code? Большинство кодов ошибок кроме общих вроде «error not supported» отновятся к I/O операиям и соответствуют кодам ошибок стандартной библиотеки. Всё просто и доступно, имхо.
Node.js — это не просто библиотека, а (де-факто) на данный момент стандартный способ написания серверов на JS. Соответственно почти все, что в нем происходит, становится трендом (и, если повезет, общепринятой практикой).

Как вы будете следить за уникальностью этих кодов между разными сторонними библиотеками?
Большинство ошибок — это ошибки не уровня I/O операций, а бизнес логики. И они у каждой библиотеки и приложения уникальны.
Что-то у меня система квестов в разрабатываемой игре стала показывать заметно худшие результаты.
Вчера 2 варианта бенчмарка работали за 9.1 и 4.9 секунд. Сегодня, после апдейта из launchpad.net/~chris-lea/+archive/node.js/, они стали работать 10.7 и 6.1 сек соотв-но.
Only those users with full accounts are able to leave comments. Log in, please.