Здравствуйте, BulatZiganshin, Вы писали:

BZ>ты не поверишь, но node.js я тоже изучаю всего несколько дней, а js/cs не знаю вообще — вчера написал первую программу на js, сегодня — первую на cs, поминутно заглядывая в справочник и пытаясь перебором найти нужный синтаксис

Предлагаешь тоже несколько дней потратить, чтобы понять, о чем было твое сообщение?
А по существу вопроса — спасибо, что расписал. Стало понятно, что за зверь, перспектива использования и тп.

Здравствуйте, Marty, Вы писали:

M>По ссылкам сходил, но ничего не понял. Понял только то, что node.js — http-сервер на JavaScripte движка V8 от гугл. Что за звери остальные, не понял. Вообще, имхо, человеку далекому от js так сразу все не осознать.

О проекте node.js

Учите английский, блядь! Это серверный однопоточный джаваскрипт-движок на событиях (libev), состоящий из гугловского якобы высокопроизводительного JIT-компилятора V8 и библиотеки асинхронного ввода-вывода к нему. В библиотеке присутствует HTTP-сервер, что позволяет получить что-то в духе эрланговского MochiWeb и питоновского TornadoWeb, но позволяющее писать клиентский (браузерный/AJAX) и серверный ('cкрипты') код на одном языке. Ну и конечно геморрой в стиле mod_perl + POE вам обеспечен. Тем не менее, говорят, это прогрессивно и круто. (Шутка)

Для особо одарённых, уточняю. Вышеперечисленное включает: вонючую, но встроенную вариацию memcached; невозможность без плясок с бубном, не снившихся питоновцам, задействовать более одного ядра; новые уязвимости из-за паразитной передачи данных в параллельно исполняющийся запрос; падучесть всей VM вместе с вашими фронт-эндом и бэк-эндом в стиле легендарной DOS при зацикливании или непойманном исключении в любом из обработчиков событий; возможность неправильно реализовать HTTP; феерический пул потоков для исполнения в нём unlink(); развесистые монады при вводе-выводе, не снившиеся хаскеллистам; ну и, конечно же, необходимость писать юнит-тесты на каждый чих, потому что только джедаи в состоянии безошибочно разыменовать хеш массивов хешей хешей массивов, а а компилятор попытки присвоить ёжику зайчика не ловит.

Но и это ещё не всё! Для затягивания сроков и удорожания разработки система включает: иллюзию эрланговской изоляции посредством порождения дочерних песочниц в рамках одного потока; циклы перебора байтиков в буфере в стиле Паскаля с неявным алиасингом; отсутствие возможности читать файлы построчно.

http://node-js.prcn.co.cc/#rus

On 11.12.2011 21:24, BulatZiganshin wrote:

Одни субподрядчики сделали нам систему на этом "суперпроизводительном"
node.js, но когда дело дошло до production — node.js отправился в сад,
его место успешно занял glassfish-3.1.1.

Чего и вам желаю.

--
WBR,
Serge.

> Одни субподрядчики сделали нам систему на этом "суперпроизводительном"
> node.js, но когда дело дошло до production — node.js отправился в сад,
> его место успешно занял glassfish-3.1.1.
>
> Чего и вам желаю.

То есть код просто портировали на glassfish?
А основные недостатки нода в чем?

On 12.12.2011 16:08, grosborn wrote:
>
> То есть код просто портировали на glassfish?
Переписали на яву, благо его было не так много.

> А основные недостатки нода в чем?
Основной и единственный недостаток нода в том, что писать под него нужно
на javascript. При этом выяснилось что там "того нет, это не работает, а
с этим есть нюансы", вообщем переписать всё на яву оказалось самым
простым и эффективным решением. Про 7 тыщ запросов в секунду это конечно
мощно, но напоминает анекдот про секретаршу которая печатала 300
символов в минуту ("Да, правда могу 300 симв./мин. Но такая фигня
получается").

--
WBR,
Serge.

Здравствуйте, BulatZiganshin, Вы писали:

** оффтопик
С нетерпением жду, когда пощупаешь erlang и так же будешь агитировать...

Хинт: хотя, не такой и оффтопик

BZ>вообще сейчас популярны асхинхронные веб-сервера — такие где крутится всего один или несколько OS threads, каждый из которых может одновременно обрабатывать тысячи входящих соединений. наиболее производительным и популярным из них является nginx
Жалко правда что у RSDN-а с этим nginx постоянные проблемы его, т.е с nginx производительностью
Это я так, к слову.

BZ>npm install zappa coffee-script htmlkup -g

BZ>вытащил из zappa crash course простенькое приложение на zappa:
BZ>

{@app} = require('zappa') ->
BZ>  @enable 'default layout'
BZ>  @use 'static'

BZ>  @get '/': ->
BZ>    @render index: {foo: 'bar'}

BZ>  @view index: ->
BZ>    @title = 'Node.js site'
BZ>    h1 @title
BZ>    p @foo

BZ>и запустил его: coffee zappa.coffee

в рот мне ноги от такого синтаксиса...

Здравствуйте, Young, Вы писали:

Y>С нетерпением жду, когда пощупаешь erlang и так же будешь агитировать...

а почему ты сам не хочешь это делать?

о многопоточности в различных веб-платформах:

haskell/ghc: выглядит идеально. рантайм умеет запускать тысячи green threads и шедулить их на несколько потоков ОС, при блокирующих внешних вызовах (в C land) рантайм автоматически создаёт себе новые треды, так что другие green threads не блокируются. afaik, I/O реализуется через epoll, так что по крайней мере в Linux не будет блокировки по I/O и масштабируемость ничем не ограничена. синхронный I/O не блокирует остальные green threads

javascript/V8/node.js: один поток ОС, в котором крутится один поток javascript/V8 (разбор от автора nginx). иллюзия многопоточности реализуется за счёт того что все I/O функции принимают в качестве параметра колбек — т.е. работа скрипта на этом обычно завершается, зато шедулится новый скрипт, переданный как колбек

Lua/nginx: один поток ОС, кооперативные Lua green threads с неблокирующим синхронным I/O

в остальных платформах я ориентируюсь плохо:

erlang: вроде как раз для этого и создан, но не знаю как там сейчас положение дел

ruby/rack/sinatra: один поток ОС, вытесняющие green threads с асинхронным I/O (синхронный блокирует)

python/wsgi/?: один поток ОС, доп. потоки для вызовов С и I/O(?), вытесняющие green threads

обнаружилось два сервиса, бесплатно хостящих node.js apps:

http://wiki.joyent.com/display/node/Node.js+SmartMachine+FAQ
http://devcenter.heroku.com/articles/node-js

почему-то в оба советуют деплоиться через git. то ли это просто удобней, то ли принципиальное ограничение

Здравствуйте, BulatZiganshin, Вы писали:

BZ>обнаружилось два сервиса, бесплатно хостящих node.js apps:

BZ>http://wiki.joyent.com/display/node/Node.js+SmartMachine+FAQ
BZ>http://devcenter.heroku.com/articles/node-js

BZ>почему-то в оба советуют деплоиться через git. то ли это просто удобней, то ли принципиальное ограничение

Ну как есть подвижки в изучении?
У меня, по непонятным причинам, некоторые примеры для node.js не хотят работать. Связываю это с тем, что работаю под виндой. А эти хостинги со своим git`ом реально парят. Не привык я работать с командной строкой

Здравствуйте, Volgare, Вы писали:

V>У меня, по непонятным причинам, некоторые примеры для node.js не хотят работать. Связываю это с тем, что работаю под виндой. А эти хостинги со своим git`ом реально парят. Не привык я работать с командной строкой

вот что получилось на нынешний момент: http://jsapp.us/s/250.coffee
контент страниц складывается в файлы views/Default.htm, views/Download.htm и т.д. в общем-то это то, что мне нужно, но не хватает ещё умного кеширования и сжатия

а примеры могут не работать потому, что это — moving target. там даже автоматически генерируемая дока то по старой версии, то по ещё не вышедшей смотри исходники библиотек, которые поставил

вот ещё немного ссылок: http://forum.nodejs.ru/index.php/topic,304.0.html