【node.js】サーバサイドjavascript 3【io.js】©2ch.net

pythonやrubyやPHPと同じ土俵でjavascriptが使えるようになりました。
サーバサイドjavascriptについて語りましょう。

node.js - googleが開発したV8エンジン上で実行できる処理系
http://nodejs.org/
io.js - node.js 互換で Joyent の影響からの脱却を目指す処理系
http://iojs.org/
Rhino - JVM上で実行できる処理系
https://developer.mozilla.org/ja/Rhino

io.js の経緯
http://stackoverflow.com/questions/27309412/what-is-the-difference-between-node-js-and-io-js
javascriptはrubyと比較してもかなり速い
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=v8&lang2=yarv
基礎から学ぶNode.js
http://gihyo.jp/dev/serial/01/nodejs
node.jsの概要とアプリケーション開発の準備
http://gihyo.jp/dev/serial/01/realtimeweb/0002

前スレ
【node.js】サーバサイドjavascript 2【Rhino】
http://peace.2ch.net/test/read.cgi/tech/1358937029/
【node.js】サーバサイドjavascript【Rhino】
http://toro.2ch.net/test/read.cgi/tech/1310087535/

あけおめことよろ

yesde.js

node.jsって流行るの？

流行ってる
流行ってた

gulp 4 って使えるの？

node-webkitやatom-shellはスレチ？
OKなら、今どっち採用するか凄く迷ってるんですけど

「node.js覚えればクライアントもサーバもjavascriptだから他の言語覚えなくてすむぜ！」
と安易に寄ってきたにわかがイベントドリブン周りが頭に入らなくてすごすご退散するケースが多そう

>>8
俺はそれに近い

とりあえずPromiseを理解しないと非同期のメリットを生かせないだろうな

>>8
自己紹介乙

Promise って非同期処理のコールバックを比較的キレイに書ける、
って以外のメリットって何かあるの？

>>12
綺麗っていうのが曖昧な表現だがおおむね以下のメリットがある
・コールバック関数から更にコールバックを呼ぶ時にネストが深くなるのを防げる
　(ソースが三角形になるのを防げる)
・A,B,Cの内ABが終わっててかつCが終了した直後に処理を開始するとかの制御が簡単になる
　(つうか自前でやろうとするとかなり面倒な事になる)
・エラー処理を一纏めにしたりなんかの制御が簡単になる

これを綺麗に書けるの一言でくくってしまったら他のメリットは無い

>>13
レスさんくす。

>>8 に対しては、むしろコールバック関数を使ったやり方のほうが
node.jsの動作を理解できていいんじゃないかと思ったのでね。

>ソースが三角形

漏れはチベット国旗みたいになる

Promiseなんて実際綺麗に書きやすいライブラリの一つってだけだから
「Promiseを理解しないと非同期のメリットを生かせない」ってのは
表層しか理解してないって証だわな
Promiseと非同期をjQueryとDOMにでも置き換えて考えてみるといい

>>16
実際生かせないだろ
> ・A,B,Cの内ABが終わっててかつCが終了した直後に処理を開始するとかの制御が簡単になる
非同期処理をやってると↑こういう事がしょっちゅうあるけど、どうやって自前でやんの？
単にフラグだらけの糞みたいなソースが出来るだけだ

その程度は自前でも並列と逐次の小さなヘルパ関数を用意するだけで十分きれいに書けるだろ
実際はそんなもん自前で書かずにasync使ってたけどな
ECMA標準だから仕事じゃPromise使ってくけどそんなのは所詮表層の話に過ぎないよ
PromiseよりStreamが適することも多いし

>>18
どうせマルチスレッドvs非同期処理の事いってんだろ
そんな事言ってんじゃねーんだよ
スレの流れも読まずに何一人でブチ切れてんだよアホか

>>18
一方俺は、asyncもどきを自前で作った。（趣味でだけど）

非同期処理の中でさらに非同期処理をして、それぞれの終了時に指定された関数を呼び出す
可能性があるようなプログラムだったんで、途中頭がこんがらがったけど何とかできたわ。

>>20
一応だけど、ブラウザ内蔵のPromiseはJavaScriptで実装出来ない事をしてるから
Promise使った方がいいとは思うよ
・渡されたコールバックを確実に非同期で実行する
・飲み込まれた例外をデバッグ出来る
ってのがそう

>>19
どこを誤読するとそうなるんだよwww
並列ってのはPromise.all()やasyncのparallel()のような処理フローのこと
逐次ってのはPromiseのthen()によるチェーンやasyncのseries()・waterfall()のような処理フローのこと
俺の方はスレの流れを読めてると思うぞ

>>21
ブラウザのJavascriptもシングルスレッドじゃなかったっけ？
であれば、
・渡されたコールバックを確実に非同期で実行する
・飲み込まれた例外をデバッグ出来る
はPromise使わなくてもできるよ。使った方が楽だろうけど。

>>23
> ・渡されたコールバックを確実に非同期で実行する
これはsetTimeout使ったハックがあってほぼ確実なのは可能だけど、
絶対確実な実装はブラウザが内部で実装しないと無理なんだよね

> ・飲み込まれた例外をデバッグ出来る
そりゃ、ライブラリ内部のcatch内にブレークポイントを張って待ちかまえていれば
可能だが毎回そんな事すんのか？いやするわけない
そして例外がスルーされて何も起きない

>>21
サーバサイドJSスレで「ブラウザ内蔵のPromise」ってw
そこはv8のPromise実装って書けよ

>>22
QとかBlurbirdはそれらをJSで実装してるわけだからな
どうしてJSで実装できないと思い込んだのか謎だ

安価ミス、>>25の後半は>>23へのレス
あとBlurbirdじゃなくてBluebird

>>25
ブラウザ内蔵って…ごめんちゃい

QとかBlurbirdはほぼ確実な実装でお茶を濁してる (実用上問題ないけど)
例外の件は>>24の通りだ

>>27
「お茶を濁してる」について詳しく
nodeではprocess.nextTick()かsetImmediate()で確実に非同期にできるが？
v8のPromiseだってマイクロタスクキューに入れられて結局はnodeのイベントループで処理されるのは同じ

例外のデバッグって具体的には？
Promise.catch()にブレークポイント付けれるって話？(それはブラウザ関係ないと思うが…？)
もしそうならライブラリがcatchした例外はコールバックの第1引数に渡されるのがnodeの流儀で同じようにできるが？

で、>>19は>>18を誤読してたってことでいいのか？ >>22を読んだ上での反論は？

>>28
> nodeではprocess.nextTick()かsetImmediate()で確実に非同期にできるが？
Qとかはnode用やIE用じゃないが、場合分けしてる可能性はある
> v8のPromiseだってマイクロタスクキューに入れられて結局はnodeのイベントループで処理されるのは同じ
それがJavaScriptで実装出来ない事をしてることじゃなくて？

> 例外のデバッグって具体的には？
説明が面倒になってきた…
Promiseに限った話しじゃないが、ライブラリ内でtry,catchしちゃってると
呼び出し側に例外が来ないって事だ (当たり前の事だけど)
で、Promiseの場合は呼び出し側がエラー処理もしてない場合でも、
デバッガが気を効かせて例外を上げてくれるってだけだ

ま、薄々感づいてると思うが、俺はずっとブラウザ実装の事を言っていた…
しかしPromiseが満たすべき一般的な動作仕様を言ってるつもりではある

>>30
> それがJavaScriptで実装出来ない事をしてることじゃなくて？

nodeではv8のマイクロタスクキューもsetImmediate()もnodeのイベントループで処理されるのは同じって意味な
つまりJSのsetImmediate()でコールバックを確実に非同期にできるってこと
これはブラウザでも同じはずだ
違うなら「ブラウザが内部で実装しないと無理」な理由を具体的に書いてくれ

> 呼び出し側に例外が来ないって事だ (当たり前の事だけど)

ライブラリの実装依存ではあるが、nodeでは当たり前じゃない
nodeでは例外を第1引数としてコールバックすることで呼び出し側に例外を伝えるのが流儀だ
だからPromiseでnodeのAPIやライブラリをラップしてもPromise.catch()に例外が渡る
(ラッパーはコールバックの第1引数に例外が渡されたらPromise.reject()を呼び出す)

>>21を見てから薄々じゃなく確信していた

>>31
> 違うなら「ブラウザが内部で実装しないと無理」な理由を具体的に書いてくれ
setImmediate()がコールバックを確実に非同期に出来るっていう仕様ではないだろ
確実に非同期って意味は
setImmediate(function callback() {
});
a += 1;みたいななんらかの処理 ←これが実行される前にcallbackが絶対実行されない
ことを保証してんの？
そもそも非標準のAPIなんだけど…

> ライブラリの実装依存ではあるが、nodeでは当たり前じゃない
QとかBluebirdみたいに自前で実装すると例外が飲まれるって話しじゃなかったのか…
Promiseの実装を熱弁してるけど、とりあえずそういう事でいいよ

>>32
> これが実行される前にcallbackが絶対実行されない
ことを保証してんの？

仕様はそうなってる
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/setImmediate/Overview.html

> そもそも非標準のAPIなんだけど…

そこはこのNotesに書いてある"platform code"から好きなものに置き換えてくれ
https://github.com/promises-aplus/promises-spec

> QとかBluebirdみたいに自前で実装すると例外が飲まれるって話しじゃなかったのか…

>>23（これは俺とは別人）からは「それPromise使わなくてもできるよ」って話をしてるな
それは当然JSで書かれたQやBluebirdでもできるってことだから元の話と違ってるわけではない、スコープが広がっただけ
で、QとかBluebirdだと例外が飲み込まれるわけ？コードで示せる？

>>33
> 仕様はそうなってる
Schedules to run handler immediately after user agent events have been flushed.
user agent eventsってなんだ？
a += 1;の実行が終わってからとは言ってないと思うが

> そこはこのNotesに書いてある"platform code"から好きなものに置き換えてくれ
置き換えて何だよ？
platform code(要するにJavaScriptでないコード)を実行しろとわざわざ書いてる
> 違うなら「ブラウザが内部で実装しないと無理」な理由を具体的に書いてくれ
元の質問は↑これ、お前は論点をずらそうとしてるだけだな

> で、QとかBluebirdだと例外が飲み込まれるわけ？コードで示せる？
お前眠いのかw
俺はもうもちそうもないが
>>30の下の方で言ってるよ

https://twitter.com/msdev/status/551558635198099457/photo/1
もし1995年にnode.jsがあったら

入れ替えんのがとてつもないボトルネックやな

こんな難しい議論理解できないと
綺麗なコード書けない時点で人気出ないだろうね

そんな難しい話かぁ？

>>35
そいつがアホなだけ

>>39
ﾈﾀﾆﾏｼﾞﾚｽｶｺﾜﾙｲ

その頃にはもうMPC規格が普及して
CD-ROMドライブが標準でついてるというのに(TOWNSユーザー並の感想

>>37-38
技術的に難しい話はしてないが、こういう場で会話を成立させるのは難しいなw
できれば誰か ID:kuXg+7pG の主張を翻訳して欲しい

>>34
> a += 1;の実行が終わってからとは言ってないと思うが

"5 Processing Model"の4に、5以降は非同期に実行すると書いてある

> 置き換えて何だよ？

お前が使ってるブラウザに合わせて読み替えろというだけだ
サーバサイドJSスレとしてはnodeで使えるprocess.nextTick()やsetImmediate()で何の問題もない

> platform code(要するにJavaScriptでないコード)を実行しろとわざわざ書いてる

"paltform code"はプラットフォームごとに異なるコードという意味で
それがJSで実装されてようがされてまいがどうでもいい
実のところnodeのsetImmediate()はJSで実装されている

https://github.com/joyent/node/blob/v0.10/lib/timers.js#L361

> > 違うなら「ブラウザが内部で実装しないと無理」な理由を具体的に書いてくれ
> 元の質問は↑これ、お前は論点をずらそうとしてるだけだな

いみふ
「ブラウザが内部で実装しないと無理」の対象はPromiseそのものの実装だ
Promiseの実装が呼び出すAPIの話じゃない
「stringはブラウザで実装されている」を理由に「stringを使うのはブラウザが内部で実装しないと無理」っておかしいだろ？
"platform code"がブラウザやnodeで実装されていても、それを使うコードはJSで書ける
たとえばQはこの辺で"platform code"を呼び分けてる (モダンブラウザだとpostMessage()が使われてるな)

https://github.com/kriskowal/q/blob/v1/q.js#L160

これは「ブラウザが内部で実装しないと無理」ではなく普通のJSのコードだ

>>34
> >>30の下の方で言ってるよ

話がループしてるな… その>>30の以下について

> Promiseに限った話しじゃないが、ライブラリ内でtry,catchしちゃってると
> 呼び出し側に例外が来ないって事だ (当たり前の事だけど)

これはPromiseを実装するQのようなライブラリ側の話だよな？
ライブラリ側がcatchした例外を飲み込んで捨てた場合は確かにそうだが、
QやBluebirdは飲み込まずにPromise.catch()に通知するだろ
Promiseを使わない場合でもnodeの流儀ならコールバックの第1引数で通知する
だからこれは「ブラウザ内蔵のPromiseはJavaScriptで実装出来ない事をしてる」に該当しない
っていうのが>>31で書いたことだ
それに対して>>32で

> QとかBluebirdみたいに自前で実装すると例外が飲まれるって話しじゃなかったのか…

と返されたわけだが、前述の通り飲み込まずにPromise.catch()で通知されるはずだから
そうじゃないっていうなら

> で、QとかBluebirdだと例外が飲み込まれるわけ？コードで示せる？

と>>33で尋ねたわけだ
その返事が>>34の「>>30の下の方で言ってるよ」だと完全にループ
まずは確認だが、

・QとかBluebirdでは例外が飲まれる

って主張してるんだよな？
それならどういうケースでそうなるのか例を示してくれ
Promise.catch()に伝わらないケースがもしあるなら、おそらくそれはただのバグだ

JavascriptとPHPでだいたいのことはカバー可能という認識でおｋでしょうか？

MySQLかSQLiteも欲しい

やはりMySQLがないと片手落ちなのですね
どうもありがとうございます

>>34,43
>Schedules to run handler immediately after user agent events have been flushed.
>user agent eventsってなんだ？
ここで言っているuser agent eventsはHTML要素のon〜属性に指定したイベントハンドラ関数みたいだね。
1章のIntroductionで「user agent eventsの中で画面を書き換えるような処理を書いて、
その後の処理を行う前にその変更を画面に反映させたいときに、今まではsetTimeout(fn,0)を
使ってただろうけど、それだと遅延が発生するからsetImmediateてメソッドを定義するよ」
ってな感じのことが書いてある。

>> そこはこのNotesに書いてある"platform code"から好きなものに置き換えてくれ
>置き換えて何だよ？
Notes の記述に、
This can be implemented with either a "macro-task" mechanism such as setTimeout or setImmediate,
or with a "micro-task" mechanism such as MutationObserver or process.nextTick.
「これは、setTimeout,やsetImmediate (”マクロタスク”機構）、またはMutationObserverやprocess.nextTick
（"マイクロタスク"機構）を使っても実装できるよ」
って書いてあるね。この中のどれを使って置き換えても実現できるということだね。

例外処理についても>>44の通りで、それ以上に言うべきことはないかな。
ただデバッガとかブレークポイントとかの言葉が出ていたから、
必要以上に難しく考えていたんじゃないかという気がしないでもない。

>>43
>たとえばQはこの辺で"platform code"を呼び分けてる (モダンブラウザだとpostMessage()が使われてるな)
MessageChannel 知らんかった。。。
node.js では process.nextTick、ブラウザでは setTimeout と使い分けるだけだったよ。
勉強になった、サンクス。

>>44
> Promiseを使わない場合でもnodeの流儀ならコールバックの第1引数で通知する
通知しても呼び出し側がハンドリングしてなきゃ意味ないだろ
別にハンドリングしたきゃrejectjをハンドリングすりゃいいんだよ、アホか

まったくハンドリングしてない予期しない例外でも内蔵Promiseならデバッガが
気を効かせて例外を通知してくれるって事を言ってんのに
お前はなんで分かんないんだよマジで無能だな

>>44
お前がPromise使ってプログラムなんかした事ないド素人なのは分かったよ
じゃなきゃ、そんな事言う訳ないし
普通はそうだね、で終わる話しを、ドアホのお前がバカみたいに突っこんでるだけなのを
オレが暇だから相手してるだけだよ

暇ならもう少し相手してもらおうか
まず

> ・渡されたコールバックを確実に非同期で実行する

これがJSで実装できないって主張は間違いだったということでいいのか？
次に

> ・飲み込まれた例外をデバッグ出来る

「まったくハンドリングしてない予期しない例外」をデバッグできるのは内蔵Promise関係なく
JS処理系(Chromeならv8)のデバッガの機能だろ
nodeでもv8のデバッガは有効だからnode debug x.jsで実行してbreakOnExceptionしておけば
「まったくハンドリングしてない予期しない例外」でブレークする
nodeはprocess.on('uncaughtException')があるからそれでデバッガ使う機会は少ないけどな
だがこの話マジでPromise関係なくね？

つか「ハンドリングしてない例外」でなく「ハンドリングしてないreject (uncaught promise rejections)」
のデバッグを言ってるのか？
だとすると全然話が違うが、debugger文を使えば内蔵Promiseじゃなくても実装はできるな

> お前はなんで分かんないんだよマジで無能だな

お前以外誰もお前の言ってることを理解できてないんじゃないか？w
できてる人がいるならマジで翻訳してくれ

あと俺はECMA入り前を含めると2012年頃からPromise使ってる
ただしnodeでの話だからブラウザ固有の話は知らない可能性は高い
ここはサーバサイドJSスレなんだからその辺はお前の方が考慮してくれ

せっかくなので具体的に
こういうコード(x.js)があるとするじゃろ

process.nextTick(function() {
　throw new Error('unhandle');
});

こうやって実行するじゃろ

$ node debug x.js
< Debugger listening on port 5858
connecting to port 5858... ok
break in x.js:1
> 1 process.nextTick(function() {
　2 throw new Error('unhandle');
　3 });

1行目で止まってるからおまじないを唱えるじゃろ

debug> breakOnException

実行再開するじゃろ

debug> c
exception in x.js:2
Error: unhandle
　1 process.nextTick(function() {
> 2 throw new Error('unhandle');
　3 });
debug>

ハンドルされてない例外のせいで2行目で止まったじゃろ

ところで「ハンドリングしてないreject」のデバッグって
最新のブラウザではサポートされてるのか？
たとえば

Promise.resolve(true).then(function(v) {
　throw new Error('then');
}).catch(function(e) {
　console.log(e);
});

と最後にcatch()すべきところを忘れてしまって

Promise.resolve(true).then(function(v) {
　throw new Error('then');
});

とした場合、これをChrome安定版(39)で実行してもブレークしない
スローした例外は内蔵Promiseの実装でcatchしてるからv8から見ると
ハンドルされてるって扱いなんだろう
Chrome開発版や他のブラウザだとブレークするのか？

>>50
横から失礼、俺も読んでて意味わからないから質問させてくれ

＞まったくハンドリングしてない予期しない例外でも内蔵Promiseならデバッガが
＞気を効かせて例外を通知してくれるって事を言ってんのに
＞お前はなんで分かんないんだよマジで無能だな
内臓Promiseの利点はデバッガが気を利かせて例外通知をしてくれる、と読めるんだけど、つまり製品に使うと勝手にデバッガが動いてる状態になるから開発時以外は使っちゃいけないって事でOK？
それともPromiseには何らかのデバッガが内臓されている感じなのかな？もしそうだとして、デバッガが動作してることを前提でコードを組むのがPromiseの使い方って事？

もし前者なら(特に将来的に)仕様がどうなるかは環境依存って事になるから、Promiseは使ってはいけないんじゃないだろうか？

面倒だがこうなったらしょうがない少し付き合ってやる

>>52
> > ・渡されたコールバックを確実に非同期で実行する
>
> これがJSで実装できないって主張は間違いだったということでいいのか？
setImmediate()の仕様は、渡されたコールバックを次のJavaScriptの命令が確実に実行された後に
実行するとは読めなかったが、もし内部の実装がそうなってるのであれば、setImmediate()で
実装できるよ
ただし、本当に内部の実装がそうなってるかどうかはお前が確認して報告しろ

> Chrome開発版や他のブラウザだとブレークするのか？
通常のChromeとFirefoxでブレークするのを確認した

>>55
> つまり製品に使うと勝手にデバッガが動いてる状態になるから開発時以外は使っちゃいけないって事でOK？
デバッガは普通のブラウジング時には有効になってないよ
有効にするにはブラウザごとにやり方が違うから自分で調べてくれ

>56
> ただし、本当に内部の実装がそうなってるかどうかはお前が確認して報告しろ

process.nextTick()もsetImmediate()もsetTimeout()もそうなってるよ
どの関数もreturnして後続のコードが実行されてイベントループに戻るより前に
コールバックが呼ばれることはない

> > Chrome開発版や他のブラウザだとブレークするのか？
> 通常のChromeとFirefoxでブレークするのを確認した

>>54が引用されてるが、それはお前の言う「ハンドリングしてない予期しない例外」
とは別の「ハンドリングしてないreject」の話だぞ
>>54の一行目にそう書いてあるだろ

それより

> まったくハンドリングしてない予期しない例外でも内蔵Promiseならデバッガが
> 気を効かせて例外を通知してくれるって事を言ってんのに

について具体的にコードでも書いて説明してくれよ
日本語じゃまともに通じてないんだからその方がお互い手っ取り早いだろ？

これは「ハンドリングしてないreject」としてのレス

>>56
> 通常のChromeとFirefoxでブレークするのを確認した

まずは確認だが、Chromeで"Pause On Caught Exceptions"は外してるよな？
あれはハンドリング「してる」例外でもブレークするからここでは邪魔になる
その上で、rejectをハンドリングしている

Promise.resolve(true).then(function(v) {
　throw new Error('then');
}).catch(function(e) {
　console.log(e);
});

はブレークしないが、rejectをハンドリングしていない

Promise.resolve(true).then(function(v) {
　throw new Error('then');
});

はブレークするのを確認した、ということで間違いないか？

俺のChrome 39ではどちらもブレークしない
(通常の「ハンドリングしてない例外」はもちろんブレークする)
もしChromeの設定が必要なら教えて欲しい

これも「ハンドリングしてないreject」としてのレス
例外ではなくrejectの話ということがより明確になるようにコードを修正した

rejectをハンドリングしている

Promise.resolve(true).then(function(v) {
　return Promise.reject(new Error('then'));
}).catch(function(e) {
　console.log(e);
});

はブレークしないが、rejectをハンドリングしていない

Promise.resolve(true).then(function(v) {
　return Promise.reject(new Error('then'));
});

はブレークするのか？

ちなみにQを使う場合はQ.getUnhandledReasons()で
「ハンドリングしてないreject」の一覧を取得できる
nodeではsetInterval()で定期的にログ出力すればデバッガの必要性は低い

>>57
> process.nextTick()もsetImmediate()もsetTimeout()もそうなってるよ
調べもせずに適当な事言うなよ
少なくともsetTimeout()は絶対違う

他は日本語が意味不明
Promise.resolve(true).then(function(v) {
　throw new Error('then'); ← ここでデバッガがブレークする
});
アホなお前はこれでも理解出来ないと思うが、俺はこれ以上説明しない

> nodeではsetInterval()で定期的にログ出力すればデバッガの必要性は低い
糞みたいな負け惜しみすんなよw

> 少なくともsetTimeout()は絶対違う
捕捉するがタイムアウト時間を1msとかにすれば、99.9%実用上問題無いだろう
だが「確実」に非同期にするという事とは全く意味が違う

>>58
> もしChromeの設定が必要なら教えて欲しい
デバッガのデフォ設定では飲み込まれて無反応だ
さんざんケチつけてる割にはそんな簡単な設定も分からんか
ただ、激しくスレチな事なんで無理もないからそろそろ黙ってくれ

>>60
> 調べもせずに適当な事言うなよ

調べて言ってるけど？
まずは仕様

https://html.spec.whatwg.org/multipage/webappapis.html#timers

"timer initialisation steps"の10で"Return handle, and then continue running this algorithm in parallel."
となっていて、コールバックが呼び出されるのは14の"Queue the task task."によってだ
そしてNodeの実装

https://github.com/joyent/node/blob/v0.10/lib/timers.js#L194

203行目でTimeoutオブジェクトを作って225行目でactive()に渡してる
175行目からのactive()はリストにTimeoutオブジェクトを追加してるだけ
どうやってもsetTimeout()がreturnする前にコールバックが呼ばれることはない

> 少なくともsetTimeout()は絶対違う

その根拠は？ お前は主張するばっかで根拠は何も示さないのな

>>61
> 捕捉するがタイムアウト時間を1msとかにすれば、99.9%実用上問題無いだろう
> だが「確実」に非同期にするという事とは全く意味が違う

お前「非同期」の意味わかってる？ タイムアウト時間は非同期とは一切関係ないぞ
setTimeout()は常にコールバックを非同期に実行する
ただしコールバックが実行されるまでの時間は指定したとおりになるとは限らないだけだ
特にネストした呼び出しでは0〜3msを指定しても最低4msは待たされる(上の仕様に書いてある)
だが常に非同期だ

>>60
> 他は日本語が意味不明

お互いになw でもJSのコードは分かっただろ？
だからお前が言いたいこともコードで示してくれって何度も言ってるわけだ
なんでコードで書かないんだ？

> Promise.resolve(true).then(function(v) {
> 　throw new Error('then'); ← ここでデバッガがブレークする
> });

それだけだと"Pause On Caught Exceptions"を有効にしてるようにしか見えないな
その場合ブレークするのは内蔵Promise一切関係ないからな
catch()してるケースではどうなんだ？ ブレークしちゃうんじゃねーの？
>>59のPromise.reject()版でもブレークするのか？ しないんじゃねーの？

> アホなお前はこれでも理解出来ないと思うが、俺はこれ以上説明しない

それこそ負け惜しみだろw
「しない」じゃなくて「できない」んじゃねーの？

> > nodeではsetInterval()で定期的にログ出力すればデバッガの必要性は低い
> 糞みたいな負け惜しみすんなよw

繰り返すけどここはサーバサイドJSスレなんでな
動かしっぱなしのサーバではロギングして調べる方が基本なんだよ
ぶっちゃけこのスレでもNodeでデバッガ普段使いしてるヤツの方が少数派じゃね？
他の人どうよ？

>>61
> デバッガのデフォ設定では飲み込まれて無反応だ
> さんざんケチつけてる割にはそんな簡単な設定も分からんか

わからんな
頼むから教えてくれよ
煽るより少ない文字数で終了するだろ

> ただ、激しくスレチな事なんで無理もないからそろそろ黙ってくれ

何を今更w
>>55とか他の人も興味あるかもしれないだろ
そんな簡単な設定ならさっさと書いてくれよ

>>62
This API does not guarantee that timers will run exactly on schedule.
って書いてある
いつ実行されるか保証してないじゃん
上の方のa += 1;を実行するまでに100msの時間が掛かったとすると、その前に実行される可能性がある

昔WebkitかFirefoxのPromiseの実装を見た時に、これで非同期にしてんのかと思った事があった気がするから
とりあえずソースをあたったみるから待ってろ
それで全て解決だ
ソースを落とすには滅茶苦茶時間掛かるし、ブラウザで探すにしても時間が掛かる

> わからんな
> 頼むから教えてくれよ
デベロッパーツールを出して一番右にある黒丸に縦二重線のPause on exceptionsを押しといてリロードだよ

>>65
> いつ実行されるか保証してないじゃん

それ俺が書いた

> ただしコールバックが実行されるまでの時間は指定したとおりになるとは限らないだけだ

のことな

> 上の方のa += 1;を実行するまでに100msの時間が掛かったとすると、その前に実行される可能性がある

その可能性はないんだよ
ステップの10でリターンした「後」、残りのステップは並列に実行される可能性がある
その一つのステップ14でコールバックを実行するタスクがキューに入れられる
タスクはキューに入れられるだけで実行はされない
そしてそのタスクがキューから取り出されて実行されるのは制御がイベントループに戻った後だ
お前の言うa += 1;の実行が終わらない限り制御がイベントループに戻ることはない
だからsetTimeout()はタイムアウト時間に一切関係なく常に非同期だ
詳細は"14. Queue the task task."のリンク先を見てくれ

そんな難しく考えなくてもシングルスレッドなんだからわかりそうなもんだがw

>>67
> そしてそのタスクがキューから取り出されて実行されるのは制御がイベントループに戻った後だ
イベントループに戻るのはsetTimeout()の直後の位置だ (a += 1;の前)

>>66
> デベロッパーツールを出して一番右にある黒丸に縦二重線のPause on exceptionsを押しといてリロードだよ

それ黒丸に縦二重線を押して出てくるパネルにあるチェックボックスのことだよな？
それ「Pause on exceptions」じゃなくて「Pause On Caught Exceptions」だよな？
俺がこれまで書いた↓全然読んでなかったのかwwwwww

>>58
> まずは確認だが、Chromeで"Pause On Caught Exceptions"は外してるよな？
>>63
> それだけだと"Pause On Caught Exceptions"を有効にしてるようにしか見えないな

"Pause On Caught Exceptions"って有効にすると

try {
　throw new Error('err'); //ここでもブレークする！
} catch (e) {
　console.log('handled');
}

こんなのまでブレークしちゃう代物なわけよ
内蔵Promiseがどうとか一切関係なく、自前のライブラリだろうがなんだろうが
どこでも例外スローするとブレークするオプションなわけじゃん
内蔵Promiseでないと実装できないとかって話と何の関係ないよな？

>>24
> > ・飲み込まれた例外をデバッグ出来る
> そりゃ、ライブラリ内部のcatch内にブレークポイントを張って待ちかまえていれば
> 可能だが毎回そんな事すんのか？いやするわけない
> そして例外がスルーされて何も起きない

↑の説明は"Pause On Caught Exceptions"と矛盾してることはわかるか？

>>68
> イベントループに戻るのはsetTimeout()の直後の位置だ (a += 1;の前)
は？ え？ え？

setTimeout(function() {
　...
}, 0);
// (a)
a += 1;

こういうコードで(a)の位置でイベントループに戻ると思ってるわけ？
いやいやいや、いくらなんでもそれは。。。 あー

>>69
あっそう、俺はFirefoxしか使ってないからChromeの事はそれでいいと思ったよ
Firefoxだと
try {
　throw new Error('err'); // ここでブレークしないで
} catch (e) {
　console.log('handled');
}
Promise.resolve(true).then(function(v) {
throw new Error('then'); // ここでブレークする
});
になる
もはやV8とも関係無くて悪いなw

>>69
ChromeでPromiseをブレークさせる方法は無いのか何らかの方法があるのか調べておくよ

>>72
別にいいよ、開発版で取り組んでるから
https://code.google.com/p/v8/issues/detail?id=3093
https://code.google.com/p/chromium/issues/detail?id=393913

俺が勘違いしていた
Promiseの仕様的にイベントループが1回以上発生する事を保証しないといけないから
setTimeout()では完全ではないということだな
はいおしまい

まだやってんのか…

ざっと読んでたら、
イベントループ＝非同期
って話してるのかと思った(笑)
何に対しての同期かにもよるだろうけどね

>>76
JSの世界(特にコールバック絡み)で同期・非同期といったら

function foo(function callback() {
　... //(1)
});
... //(2)

(1)->(2)で実行されるのが同期 (Array.forEach()とか)
(2)->(1)で実行されるのが非同期 (setTimeout()とか)

「Effective JavaScript」の項目67とか以下とか参照

http://blog.ometer.com/2011/07/24/callbacks-synchronous-and-asynchronous/

>>16
> 「Promiseを理解しないと非同期のメリットを生かせない」ってのは
> 表層しか理解してないって証だわな

真理だったな

JavaScriptはシングルスレッドだけど
NodeのIOは非同期、つまり別スレッドで行われる

>>78
まぁまぁw

>>79
別スレッドなのはファイルだけでネットワークやパイプはメインスレッドだよ
Windowsではファイルもメインスレッドかもしれん

>>78
ただ煽ってるだけだろ
理由を述べよ
すぐに理由を述べられなければただの煽りと認定する (たぶん無理だろうけど)

>>80
何がまぁまぁだよw
お前もどうせ無能なんだろ
とりあえずすぐに理由を言ってみろよ、言えないくせに

>>80
そんな事無いだろ
メインスレッドでやる意味ないし

>>83
逆に考えるんだ
ネットやパイプはノンブロッキングI/Oで多重化できるからワーカスレッドでやる意味の方がない
UnixのファイルI/OはそれができないからワーカスレッドでブロッキングI/Oせざるを得ない
以下のNoteにもそういうことが書いてある

http://nikhilm.github.io/uvbook/filesystem.html

ソースだとファイル系の操作(839行目〜)はみんな以下のPOSTマクロを使ってる

https://github.com/libuv/libuv/blob/v1.x/src/unix/fs.c#L97

その中のuv__work_submit()がワーカスレッドに処理を依頼する関数
ネットやパイプではそんなことしてない

詳細を知りたければブロッキングI/O、ノンブロッキングI/O、
多重化、非同期I/Oと順に説明してる解説を読むといい
そしてUnixでは本物の非同期I/Oは事実上ないことを知るw

ついに本日 io.js 1.0.0 が正式リリース。
v8エンジンのおかげで node より大幅速度向上。

本日は io.js の誕生日であるとともに node の命日ともなりましたﾅﾑﾅﾑ

2ちゃんもお別れの日が近い気がする

CPUを使う処理の速度は確かに向上している
が、node-gypがライブラリをダウンロード出来ずビルドに失敗したり
v8のAPI変更でnanがコンパイル失敗したり
ちょっと困った

node-gypはどこに対策版があるか分からず自分でちまちまファイル名を直した
nanは本家リポジトリに対策版のブランチあり

io.jsのことね

後、Path追加するように指定してインストールしたつもりなのに何故か追加されてない

nodejs、Javascriptに詳しくないけど。
基本が非同期ってのが面倒。
同期のJavascriptとは別物だ。
同期のソースコードに適合させたい。
これはどうやったら実現できますか。 downloadでの同期処理。


data = download("http://www.google.co.jp/");
dataに対する処理;

こんなふうにやっても待ちが出来ず。


url = "http://www.google.co.jp/";
data = download(url);
console.log(data);


function download(url) {
data = undefined;
request = require('superagent');
request.get(url)
.end( function(resp){ data = resp.res.text; });
for(i=0; i<10 && data==undefined; i++) setTimeout(null, 500);
return data;
}

同期のJavascriptってレアだな
generatorで擬似的にやるかasync/awaitを待て

>>90
こんなんでいいんじゃない？

var httpsync = require('httpsync');

var url = "http://www.google.co.jp/";

var req = httpsync.get(url);
var res = req.end();
var data = res.data.toString();

console.log(data);

JavaScriptで大量のリクエストを処理するなら
使うべきはメインスレッドをブロックする同期IOなんかじゃなくて
当然非同期IOだよな

にわか

本家のネスケが最初に作ったサーバサイドjavascriptは同期でマルチスレッドだった

nodeの公式が同期とスレッドを使ったプログラムをこき下ろしてるぞ
Thread-based networking is relatively inefficient and very difficult to use.
とか

http://nodejs.org/about/

そりゃ最初のサーバサイドJSなんてほとんど20年前の代物だからw
こんなのあるから暇なヤツは聞いてみれ(ES7ってことはasync/awaitだろうけど)
https://player.fm/series/lately-in-javascript-podcast/asynchronous-javascript-without-callbacks-in-ecmascript-7-lately-in-javascript-podcast-episode-50

promise使うといたらええんや

promiseじゃ同期っぽく書けない

perlに帰ろう

StackOverFlowのスコアを上げとくと、何かいいことがあるかもしれない。

『【翻訳】多種多様な基準から見るプログラマの市場価値』
http://postd.cc/how-much-do-you-cost/

くだらねぇｗ

2chで質問スレの住民やって回答してます！(ｷﾘｯ
みたいな面接のネタAAがあったけど似たようなもんだな

2ちゃんも回答者にポイントくれないかな

非同期だとデバッグ大変じゃないかな。
ブレークポイントで止まってる間もsetIntervalは裏で動いちゃって、待ち行列が出来たりするでしょ。

メーリングリストみたら0.11.15が出るらしいけど使われているv8がとても古い

>>106
それもip.jsがフォークした理由の一つ

>>106
それもip.jsがフォークした理由の一つ

>>106
それもip.ry(

レスをフォーク

何？また別のがフォークしたの？

node-gypはio.js 1.0.3では動かないけどpangypは動作するらしい

lodash 3.0 リリース間近！

https://github.com/lodash/lodash
3.0-preから-preが外れました！


スレが多すぎてどこに書けばいいかわからないので
関連スレすべてにマルチポストしています。m(__)m

Chrome 40(v8 3.30)のPromiseはハンドリングされてないrejectのデバッグがサポートされて>>59で書いたようになった
しかしio.js 1.0.3(v8 4.1)の組込デバッガは未対応

io.jsもvert.xのように一時期話題になるだけでnode.jsの代替にはならないよ

なんでvert.xが出てくるんだよ、全然別物じゃん
node.jsとio.jsは名前とリポジトリが違うだけでコードも開発者もほぼ同じだぞ
oracleの支配を嫌ってhudsonからフォークしたjenkinsに近い

性能ではもうio.jsが圧勝みたいだよ。
あとv8のバージョンもnodeはまだ3.*なのにio.jsはもう4.*に上がってる。

　　　　　　,,､､､,,,、,,z､,_,､、
　　　　 ,r三ミﾐﾐヾヾﾐt,X(ﾘﾐ､,
　　　　 ミﾆﾐﾘ" ゛ミ､"゛ﾘ"ミﾐ､>
　　　　三ﾆ"　　　　　　　　゛ミi
　　 ,､_ミ爪",,-____　　　　　　,,<､.
　　 i ﾄ､ﾐﾐ　,r‐- ､｀`'ニ=‐、.彡ﾘ.
　　 ヾ,iﾊ゛.´ _,,､_ 　i.;　_,.　｀ 彡'i)
　　　 ｀､j,'　 `ﾟ''´:.ﾉ i::<･ゝ) .ﾊン 　　　　　！？
　　　　　i, 　 ｀ ,､/　i_　｀`　,r'
　　　,r〃'i　 ,r'ヽ、 _,〉　　/. 　
　　 /i:ﾄ､;;i, 　ﾐ=_‐_-, 'i　/ヽ__
r-‐'´i::::ﾊ;;ヾ、‐‐-､　 ノ´/i:::'i｀i‐- ､_
::i' .l:i 'i::::i ヾ;;`‐---‐'i':/ i､ 'i::!　i::::i　｀
:i'　i:|　!:::l _,r.､;;;;;,r''´ヽi. ll::i　i::i　l:::'

つか性能差のほとんどはv8のバージョンの差だろ
io.js = node.js 0.11 + v8 4.1 + より多くのバグ修正
使う側はnode.js 0.12の次のバージョンから名前がio.jsに変わるくらいの認識でいいんだよ

紛らわしいのは、io.jsは1.0といいながら
実態は0.10と0.11の間ぐらいなんだよな。

0.10よりかは機能が増えているかもしれないが、
0.11よりかは劣っているわけで。

>>120
そりゃ誤解
io.jsのv1.xブランチはnode.jsのv0.12ブランチから派生したものだ
https://github.com/iojs/io.js/issues/218

io.js v1.0はnode.js v0.12と互換つってるしちょくちょくマージもされてる

v0.12はまだリリースされていないんだから、
v0.12より劣っているのは確かだな。

い み ふ

紛らわしいことがあるとするなら、io.jsはsemver採用で開発版と安定版を
バージョンで区別できないことかな
今v1.0.3まで出てるがこれは全部開発版で、安定版はたとえばv1.0.15からみたいなことになる
io.jsの安定版はおそらくnode.js v0.12が出た後にそれをマージしてからリリースされるだろう

ベンチマーク見たがたいして違いないしnodejsのままでいいや

>>123
semverだと、1.0が正式版なので、
0.12相当なのに1.0を名乗っているから
最初からおかしいんだよ。

なんで1.0.0-betaとかじゃないんだろとかは思う

>>125
semverではpre-releaseはMUSTじゃなくてMAYだし、実装が不安定でもAPIを固定すれば1.0.0を名乗れるだろ
どこがおかしい？

"-beta"がpre-releaseの部分な

そんな事ないうんどろの差だよ

>>127
だからMAYだろ？
MAYとはいえ、決まっているわけで、
その決まってることを意味なく破るのはなぁ。

こんなに広く使われているのに何でずっとバージョン0.xなんだYO

>>130
付けてもいい (MAY)
付けるべき (SHOULD)
付けなくてはならない (MUST)
付けてはならない (MUST NOT)

MAYなんだから付けなくて何の問題もないし、何も破ってない
だいたいsemverの主目的はAPIの互換性を示すもので実装の安定性を示すものではない

>>131
安定するより早く広まってしまった
元々v0.12の次の安定版がv1.0になると言われてたんだがv0.12が出ないうちにgruntなんかが出てきちゃったから…

安定する前に分裂とかｗ

結局のところ、io.jsは安定してないのに、
1.0を名乗っているわけで。

だから、io.js v1.0はAPIを固定したという決意表明なのよ、semver的に
実装の安定ではなく
この辺はsemver自体が広く理解されないと紛らわしいよね

いや、だから本家がAPIを固定してないから
0.xという名前なわけで、なぜAPIを固定してないかというと
そこにまだ変えるべき問題があるからなわけで。

変えるべき問題があるのに、1.0を表明しているからダメだって言ってるんだよ。
これが後々、悪いAPIだけど変えるに変えられない状態を生み出してしまう。

よくわからんな

・node.jsはsemverではないので0.xだからといってAPIを固定してないとは言えない
・node.js v0.11はすでにv0.12のRCであり、この系においてはAPIは固定されたとみなせる
・io.jsはAPIを変えたければv1.1.x、v2.0.0などにバージョンアップすればいい (すでにv1.1向けのPRも存在する)

何か問題が？

io.jsはAPIが固定されてなく、
同じくAPIが固定されてないnodeのバージョンアップに
追尾することで、APIが変更になる。

つまりio.jsはこれから互換性がないバージョンアップを
短期間に繰り返すことになり
今使うべきじゃないプロダクトだねって話になる。

OH "io.js is a way better name than node.js" --Ryan Dahl. #forreal
https://twitter.com/mikeal/status/558787202919186432

どうせタイプ数が少ないからとか言う、そういジョークだろうなｗ

検索する側からしたら迷惑な名前

io.jsも最初はsocket.io.jsがヒットしたりioとjsが含まれる関係ないサイトがヒットしたりして検索しにくかったけど
今はio.jsで検索しやすくなったし
ググラビリティー(検索しやすさ)の問題は知名度で改善する面もあると思う

何しろ線を意味する一般名詞が多大な知名度のおかげでIMサービスの名称としてググラビリティーをほとんど損なわずに成り立ってるわけだし

念のため書いておくと、>>140のポイントは語ったのがnode.jsの作者で命名者でもあるRyan Dahlってとこな
消息不明みたいなものだったから「ライアン生きてたっ！」とまずは喜ぶべき

ググラビリティーｗ
変な和製英語作んなよｗ

googleability

Likelihood of being found by an internet search engine, especially Google's.

googleability - Wiktionary

プログラミング言語の Processing なんか、

Proce55ing で検索する

知名度ではnode.jsのほうが上だし！

io.jsは
10.jsで検索しろとでも？

お前らググラビリティ低いなｗ
io.js だけでなくて v8とかforkとかbranchとか組み合わせて検索すればいいだよｗ

別にフォークしたって記事を探したいわけじゃない

どうせio.jsなんて消えるよ

互換性があるなら本流になってから移動してもいいしな。
互換性がないなら、それに見合う状態になってから考えるよ。

>>151
だからターゲットが見つかりにくいときの検索テクニックの話をしてんだよ。
レベル低いなぁ。

だからフォークした記事がターゲットじゃない

アスペが二人いる

レッテル貼るだけの簡単なレスです

しね

nodeは死ね！iojsは生キロ！

github見ればコミュニティーがio.jsを選んだのは一目瞭然

綾鷹みたいなもんだな

TLDにjsが採用されたらio.jsってずいぶんややこしい立場に
立たされるような気がする。

それは思った。node.jsでもな
まあ三文字までのドメインは取れないんじゃね

s.ex

no.de
p.ph
ru.by
pyth.on

io.js は嫌がらせドメインの代表

.jsドメインってどこで取れるんだろう？

sukisuki.js とか空いてるかな？

なんだ。まだないのか。.jkはあるんだっけ？

どうせならcgiとかphpとかhtmlとかいうトップレベルドメインも作ればいいのにね。

　
お世話になります。
私、責任者の加茂と申します。以後、宜しくお願い致します。
http://www.apamanshop.com/membersite/27009206/images/kamo.jpg
浪速建設様の見解と致しましては、メールによる対応に関しましては
受付しないということで、当初より返信を行っていないようで、今後につい
てもメールや書面での対応は致しかねるというお答えでした。
　
このように現在まで６通のメールを送られたとのことですが、結果一度も
返信がないとう状況になっています。
　
私どものほうでも現在までのメール履歴は随時削除を致しております
ので実際に１１通のメールを頂戴しているか不明なところであります。
　
　
　・Ｔ　　　http://s-at-e.net/scurl/ia-T.html
　・Ｚle　　http://s-at-e.net/scurl/ia-Zle.html

yahoo.co.jp.V.akuinoarusaito.js/a.js

これなに？ >>170

触らんほうが良さそうな雰囲気醸しとるね

うちの専ブラだとなぜかAA扱いになってる

つまりjsドメインは危険だから出てくることはないという事だ

jsは同意の有無に関係なく強姦罪になるからな

近年は図体でかいjs、jcが増えてるから要注意だよほんと

だがそれがいい

jcはこの板的にはjavaになるのか？ (java compiled)

間違えた、名前欄にsageを入れてしまった。

.cはバイセクシャルですねわかります

exportとか言語仕様の内容はnodejsのドキュメントに載ってるか教えてください
APIしか見つかりません

載ってない
ECMAScriptの仕様見れ

ECMAScriptの仕様、日本語のページあったっけ？

仕様を解説した日本語の本はあるな
es5.1だけど

本気で普及させたいんならまず日本語情報を充実させないとな。

もう十分普及してるし日本語の情報も溢れてる

atomがnode.jsからio.jsへ移行した

>>187
いやいやio.jsとnodeのごたごたの経緯なんて
日本語だとろくにわからないし、io.js1.0の情報なんて
とても「日本語の情報が溢れてる」という状況じゃない。

とりあえずio.jsがnodejsのどのバージョンに当たるのかだけ教えて
あとさ、今後io.jsはnodejsをフォークしながら開発されていくのかもおしえて

>>189
そんな経緯なんか普及とは関係ねぇよ
ほとんどの利用者はgruntやgulpのインストール手順がio.jsに書き変わればio.jsを使う
開発者はes6が使いたければio.jsを使う

>>190
v0.12をベースにv8を新しくしたのがio.js

nodejsっていつ0.12が安定版になりますか？
いまってまだ0.10が安定版だから次の安定版が0.11ってことですよね

v0.11は開発版でv0.12が次の安定版
年末にv0.11.15が出た後2週間でv0.12.0の予定だったがずるずる延びて、v0.11.16が出てv0.11.17が出る可能性もある
この遅さ、思い切りの悪さもフォークの原因の一つだろうな
来週のnode summitで動きがあるかどうか

node.js v0.12.0リリース
http://blog.nodejs.org/2015/02/06/node-v0-12-0-stable/

iojsに煽られてあわててリリースしたというふいんきだな。

つまりio.jsは噛ませ犬だったってことかｗ

競争相手がいないと組織は腐る

0.12でharmonyオプションとりはずせるけど
0.11以下でも動かすかもしれないからharmonyつけたままにしたいんだけど
0.12でharmony付けるとどうなる？

出世して彼女ができて宝くじがあたります

>>199は簡単にオレオレ詐欺にダマされるタイプ

Microsoft、オープンソースの.NET実行エンジン「CoreCLR」を公開 | スラッシュドット・ジャパン オープンソース
http://opensource.slashdot.jp/story/15/02/08/0721252/

>>198
Node0.12は知らんがV8最前線は少し前からharmonyでは全機能が有効にならなくなった。
有効にするには個別のフラグを指定する必要がある。

0.12でもharmonyつけないとfunction *(){}が使えなかった

ttp://www.nodebeginner.org/index-jp.html#finding-a-place-for-our-server-module
今さっきnodejs入れてこのビギナーズブックを見てるんだけど
ブロッキング項目で例がsleepもどきから途中でchild_process.execへ変わってるのは
sleepもどきのままでノンブロッキングは無理又は難しいからって認識で合ってる？

違う
sleepは値(結果)を産み出さないから間違ってても気づかない
だからlsコマンドの実行に変えた
そしてlsの結果じゃなく"empty"って表示されて「あれ？」と思わせるというシナリオ

Joyentが「Node.js Foundation」設立を発表。IBM、Microsoft、PayPal、Fidelityなどが創立メンバーに
http://www.publickey1.jp/blog/15/joyentnodejs_foundationibmmicrosoftpaypalfidelity.html

io.jsに未来なんてねえんだよ

そうかな
本家争いで joyent は焦ってるように見える

2015年の活発さはforkのたまもの。ユーザメリットも多いんだからiojs歓迎だよ。

>>205
レスさんくす
項目の目的が非同期でまず躓く失敗を体験させることなのはわかった

そして申し訳ないけど寝ぼけ眼で書いたせいか質問文がおかしかった
sleepもどきのような重い処理をノンブロッキングにできるのかが知りたかったんだ
ブラウザで例えるならWebWorkerに投げるみたいな
移動中にググって基本的には難しいってのがわかった、いい勉強になった

io.jsもnodojsと同じシングルスレッドならnodojsから乗り換える価値ないよね

joyentにガバナンス手放してファウンデーション作らせただけでもio.jsの勝利

io.jsの成果はio.js 1.0じゃないんだ。

nodejsを活発化させたことが
io.jsの成果なんだ。

forkしたものはどうでもいい。

活発化してるのはio.jsリポジトリのv1.xブランチだけどな

V8が最近moduleに手を入れはじめたから、特にioの方はそろそろ無視できなくなって来るな。

そして最後に全部nodejsがかっぱらう。
オープンソースですからねｗ

>>216
そもそも、名前が悪いから検索に引っかからないしね。
おまけにフォークした程度の内容。

かませ犬でも良いよ成長促進されるなら

io.jsの目的はio.jsそのものじゃなくてnodeのしりを叩くことだったりして

いまio.jsに乗り換えましたって主張をわざわざブログやツイッターに書き込んでるのは主導権握りたいから

>>220
主導権なんて握れないけれどな。所詮フォーク。

expressのtemplateライブラリって何のためにあるの？
あんなもの使うなら、phpで書いた方がマシ

時代はkoaですよ

>>221
☓フォーク
◯スポーク

>>222
Angularかbackboneで表示するから、あまり使わない

この先もずっとioが必要かは分からないが、
今年来年くらいはまさにhttp2やES.next対応やらの需要がピークなわけで、ioには頑張ってもらいたい。

joyent/[email protected] 2月に入ってからの半月で17コミット
iojs/[email protected] 2月に入ってからの半月で100コミット

どうして差がついた。慢心、環境の違い…

本家が安定版だからだろ。io.jsなんて犬も喰わない

>>223
koaはio.jsではそのまま使えるけど、node.jsで使うにはオプションが必要だからその人には、ねw

koaも過渡期の産物で本来は基本モジュールが全部Promiseを返すようになって、
ES7のawait/asyncが使えるようになれば最高。

Open GovernanceなTechnical Committeeって、Node Foundationはio.jsを丸ごと受け入れるっつか本丸明け渡す体制だな
TrademarkもFoundation Boardに移るようだし、Joyent完敗やん
io.jsの実体とNode.jsの名前が残るベストな結末になりそうでいいことだけどな

https://github.com/tmpvar/jsdom/blob/master/README.md
Note that as of our 4.0.0 release, jsdom no longer works with Node.js, and instead requires io.js.
You are still welcome to install a release in??the 3.x series??if you are stuck on legacy technology like Node.js.

> legacy technology like Node.js

node.jsとio.jsはテクノロジー的には
同じだと思うけどね。フォークしたんだからｗ

どこまで行ってもベースのテクノロジーは同じだろうが
ひょっとすると表面のAPIがガラッと変わっていくかもしれないし

>>234
それはSafariとChromeは同じだと言っているようなものでは

Io.jsって、node.jsのリーダーが独裁的だったから反発して分裂したらしいな
リーダーって誰だよw
こいつの社会的評価は急転直下なんだろうなw

>>237
Timothy J Fontaine

よいリーダーというのは独裁的であるべきだよ。
それで大成功しているプロジェクトもたくさんある。
問題は開発が停滞したことでしょ。

同意します

iojsで実験的、先進的な機能を実装→nodejsにフィードバックという流れができれば。

>>241
と、期待していたのに全然ダメとわかったから離れだしてるんだろ

Fedora rawhideとCentOSみたいな関係でいいよ。

>>239
独裁者が独裁で主要開発者を排除して開発が滞ったんだろ

>>244
ソースは？

おいおい、この文脈でそれを言うのは、全く面白くないジョークだぜ

リポジトリからpullして名前とバージョン番号だけ変えるようになったら笑える、
いや笑えない

nodejsがマルチコアに対応するのはいつになるのかね

だいぶ前に放棄されたからもうしないんじゃね

WebWorkerを使って自分でする

何をもってマルチコア対応と言ってるんだ？
Nodeの内部は当然昔からマルチスレッドで動いているんだが。
結局表面のJS部分でスレッドが使いたいという話だろう？

おわこん

Nodeがオワコンかどうかは知らないが、完成形とは程遠いのは分かる。
そういう意味ではサーバサイドJS環境は始まってすらいない。

実りの時期を待たずに刈り取ろうとしたのかｗ

>>245
ben noordhoisが辞めた時に一悶着あったらしい
ソースは検索してみて

>>255
いい加減なこと書くんじゃねーよ糞が
そん時のリーダーは今の人とは別人でio.jsで仲良くやってんだよ

>>254
ま、創始者が作りそしてぶっ壊しちゃったね。
馬鹿な創始者だなって思う。

結局サーバサイドJavaScriptはこうして歴史を閉じるわけだ。
せっかく一つの分野を開拓したのにね。

かといって、io.jsがメジャーになることはない。

間違った進化は淘汰される

どうせ統合されるから

などと言われて本当に消えてものはない。

日本語でおけ

まあJavaScriptが終わるかどうかは分からないが、
ES6,7,8...の予定を見てると飛躍的に進化するなと感じるし、
SaneScript構想なんかを見ると、今までのJSとは違うなって思う。

TimeZoneを識別子で設定できるようにならないから
あとサマータイムの考慮できるようにしてほしい
そういうライブラリでもいいんだけど

それはDateクラスで何とかすべき問題ではなくて？

定番のmoment.js

>>257
みたいにio.jsを目の敵にしてる知恵遅れのキチガイは何なん？
もうio.js様大勝利確定でjoyentは三顧の礼でもってio.js様を迎え入れようとしてるのに

はぁ？"node"という商標使いたさに頭下げてjoyentに軍門してるのに？

商標もnode foundationに移すじゃん
io.js様に出ていかれたままじゃ商標の価値そのものが無くなるからjoyent必死だな

社員以外の開発者に出ていかれて泣く泣く商標もガバナンスも手放してNode Foundationへの合流を望むJoyent
合流するかどうかはオープンに議論する余裕のio.js
どうして差がついたのか…??慢心、環境の違い

軍門に降る
な！

「軍門してる」って、io.jsに親を殺された池沼は日本人じゃなかったのかw

nodejsとsocket.ioで掲示板を作ろうと思うんですけど
1000人がページを開きっぱなしにするとwebsocketで接続しっぱなしってことでリソースを食いつぶしちゃいますか？

サーバーの性能による。

>>272
タイムアウト時間決めて無通信状態が続けば切っちまえ

えっと、何ていうんだっけそういうの？KeepAlive?

>>272
接続だけならどってことない
接続ごとに持つ情報も掲示板で1000程度なら問題にならん
仮に1接続あたり10KBも持ったとして、それでも1000接続でたったの10MBだ

一人が更新しても残り全員にメッセージを送らないといけない
クライアントから新着を一定間隔でポーリングするのか
サーバーから全接続にpushするのか知らんけど

ROMの人だと本当に見てるかどうか判別できないな

ダイアログだして延長するかどうか尋ねるとか？

まあ仲間内だけのサービスなら開きっぱでも問題ないだろうけど

通常の範囲で使われている限りは何の心配もすることはないよ。
問題はWebSocketはblobも送れるし、容量制限が実質ないこと。
本来容量で弾かないといけないけど、受信しきってからイベントが発生するタイプだと厳しい。
また、文字列前提で、blobが送られた時エラーで落ちるってのはよくハマること。
open2chのチャットも当初そのバグが有った。

そこまで考えてなかったけど勉強になりました

nodeからmongodbを操作するmongooseの解説書に
プロセス終了時にコネクションを切断する以下のようなコードが紹介されているのですが

process.on('SIGINT', function() {
mongoose.connection.close(function () {
console.log('Mongoose disconnected through app termination');
process.exit(0);
});
});

プロセスが終わったらコネクションは明示的に切断処理をしなくても切断されるのではないかと
思うのですが、違うのでしょうか？

自動で〜と言う部分は保証されていない限り、どの言語でも終了処理は自分でした方が良い

なるほど、そういうものですか
ありがとうございました

>>279
PCで言うとシャットダウンしないでいきなり電源切るような使い方で良いなら好きにすれば

普通はそれで全く問題ないが、mongoは散々DB破壊問題を起こしてきたから特に信用出来ない。

>>251
JSが動くのはメインスレッドだけで、他のスレッドは主にブロッキングI/Oするだけだから1プロセスじゃマルチコア使えない

>>283
sqliteといい、ext4といい、出始めは安定しないものだけど
こいつがもんだい起こしてるとは知らなんだ
安定は、まだ先そう？

俺はそもそもMongoを使う気がしない
使うやつの気が知れない

>>284
使えないというのではなく、活かしきれないと書いたほうがいいと思う。
libuvは一応マルチコア使ってくるはず。

>>287
だからfsモジュールとかブロッキングI/Oで寝てるだけなんだからCPU使わないんだって
zlibを並行で使い続けるような特殊なアプリでもない限りな

>>283
node.jsは信用に値するのか?

OOPLなのに+で文字列結合とか無いわー。
集合型と互換性なくなるじゃん。

"集合型と文字列型が互換性を持っているSmalltalkの例"
| value |

"加算"
value := #( 1 2 ) + 1. "-> #( 2 3 )"
value := 'AB' + ( $a - $A ). "-> ab"

"結合"
value := #( 1 2 ) , #( 3 ). "-> #( 1
2 3 )"
value := 'example', 10 printString. "-> example10"

"備考:書式付き文字列結合"
value := 'example%1' % { 10 }. "-> example10"

>>290
スモールマウス。ちがったトーク。うざいよ？

>>289
ウォルマートみたいな大企業が使っているんでしょ？

マルチコア活かしたいなら子プロセスやJavaScriptのスレッドを作るアドオン、JXCoreがあるだろ

今のJavaScriptはスレッド間でオブジェクトを共有できないから他の言語と比べたらマルチコアを活かす処理は書きづらいかもしれない

JavaScriptじゃ無理そうな時はuv_queue_workを使って特定の処理をするアドオンを書いたら良いんじゃないか

Meteorって、おいしいの？
以前とは比較にならないぐらい、サイトデザインが垢抜けてるんだけど

>>292
試験的にちょこっと使ってるのかと思ったら、フロントエンドで使ってるんだね。
日本だとうまく動かなかった場合に言いだしっぺの全面的な責任になるので使うのを躊躇する。
うまく動いた場合は上司の手柄になるしな。

というか、ゼネコン構造の日本のIT業界だと提案しても通らないべ。
日本で使ってるのは自社開発してるところしか使ってないのでは?

ほんそれ

海外じゃ他にPaypal、LinkedIn、Yahooと大手の事例も多い
日本ではソーシャルゲームばっか

海外大手はソフト内製、日本はアウトソーシングばかりだから。
でも、海外企業は朝出社したら、「今日からキミは首だから、もう帰って良いよ」って事が普通にある。

「node.js 国内事例」でggrと最初に出てきた記事(の連載目次、引っかかったのは第3回)だがリクルートは内製？
http://www.atmarkit.co.jp/ait/kw/pushinfra.html

ソシャゲ以外の他の事例が見つからね

>>256
いや、その時の実質的なリーダーは今のリーダーだぞ

>>300
お前、何の話してるかわかってないだろ
>>237 >>238 >>239 >>244 >>245 >>255 >>256を続けて読んでみろ
誰が「実質的なリーダー」かなんて話はしてねーんだよ

Ben Noordhuisが去ったのは2013/12/01だ
https://github.com/joyent/libuv/pull/1015#issuecomment-29568172

Ben Noordhuisがクローズしたこのプルリクエストをマージして衝突したのは Isaac??Z. Schlueterで、彼が当時のNode.jsのリーダーだ
https://github.com/joyent/libuv/pull/1015#issuecomment-29542508

Timothy J Fontaineはこの件に参加してないし、Node.jsのリーダーになったのは1ヶ月半後の2014/01/15だ
http://blog.nodejs.org/2014/01/15/the-next-phase-of-node-js/

その前からリリース作業を担当していても、Timothy J Fontaineは>>237や>>244に該当しねーんだよ

死んどけ糞野郎が

Joyentが糞なのは間違いない

実際、BenのことをAssholeだの解雇するだの言ったのは
joyentのCTOのBryanだな
TJは無罪かもしれないが、joyentが高圧的だってことは間違いない
主要開発者が去ってnodeの開発が停滞し大きな要因だろう

Mongoの代替データベースってなに？

>>304
PostgreSQL のhstoreかjson

>>303
StrongLoopもブログで「Benが学習できなければ首にする」と書いたがBenはStrongLoopをやめてない
https://strongloop.com/strongblog/collaboration-not-derision-in-the-node-community/

BenがNode.jsから抜けたのは差別問題ではなくIsaacを信頼できなくなったからだ
https://groups.google.com/d/msg/nodejs/ipnv3VCDwVk/5WvtUfrUE3EJ

それはBenの誤解でIsaacに謝罪した
https://groups.google.com/d/msg/nodejs/ipnv3VCDwVk/Y24y4VLdwZwJ

勝手な妄想で悪役を作るな

Joyentが白旗を上げた: Node.jsは新しい基金の手に
http://readwrite.jp/archives/20489

酷く煽ったタイトルだがそういうことだな
io.jsアンチ惨めだな

ん？つまり元に戻るって事？

nodeは2つに分ける意味ないもんね
分裂後、双方が独立して発展して行っていると言うわけでもなし

>>309
io.jsは名前が悪いから普及しない

検索エンジンだと弾かれる。短すぎてね。

うむ

たまにはGoの事も思い出してあげてください

golang

碁のことも思い出してgolang？

>>306
それらの記事のどれも>>303を否定していないが？

>>315
>>303の最後の行が他の3行と無関係ならそうかもしれないが、そう読むのは無理だろ
まともに読めば>>303は「joyentが高圧的」*だったから*「主要開発者が去ってnodeの開発が停滞」したという主張だろ
>>306はそれ(>>303の始め3行と最後の1行の関係)を否定してる

このスレではmongodbが不評ですが何故ですか？

何故ですよ

>>317
XMLDBがなぜ廃れたのか？
それがわかればその質問はない。

あれは遅いからだと思ってた

XMLDBの事情なんかMongoよりもっと知らんだろ
XMLDBが廃れたって言われるほど普及したのかさえ知らんわ