【node.js】サーバサイドjavascript 4【io.js】 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2016/04/11(月) 16:28:34.52

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 3【io.js】(c)2ch.net
http://echo.2ch.net/test/read.cgi/tech/1419673207/
【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/

**デフォルトの名無しさん** · 2017/04/08(土) 02:35:20.51

>>498
分かってないなｗ
なんでシステムコールの話がでてくるんだってことだよ。

nodeのAPIと、OSのシステムコールを
一対一で直接結びつける必要はないっつーの

nodeのAPIは単純な一命令でも、内部の実装は
何回もシステムコール呼んだって良いわけだ。

それが分かってないから、お前はシステムコールが
キャンセルできるかどうかなんて言い出したんだろ
こっちは全部お見通しだってーの

**デフォルトの名無しさん** · 2017/04/08(土) 05:35:10.56

fetchはキャンセルできる必要があるが、
fetchの戻り値をObsevableにするのは駄目。
Obsevableって一様な幾つものデータを受け取るのに向いているので
fetchのように幾つかの段階で全然違うものが帰って来るのには向いていない。

単純に、Responseにabortメソッドを付けるのが良いと思う
勿論途中のStreamをObsevableにするのはとても良いと思うけど、
それを含んだ全体をするのはおかしい。

**デフォルトの名無しさん** · 2017/04/08(土) 05:38:38.21

というか考えたら分かると思う。
キャンセルしたいのはfetchではなく、DLなのだから。
やっぱりCancelToken以外の解は無いと思うよ。

**デフォルトの名無しさん** · 2017/04/08(土) 17:16:04.09

イベントでいいじゃんかよ、もう

**デフォルトの名無しさん** · 2017/04/08(土) 17:29:52.27

> キャンセルしたいのはfetchではなく、DLなのだから。

fetchはデータ送信もするんだが？
その場合キャンセルしたいのは何だよ

**デフォルトの名無しさん** · 2017/04/08(土) 17:40:38.81

>>500
> 単純に、Responseにabortメソッドを付けるのが良いと思う

fetchの戻り値はpromiseであってresponseではない。

responseはpromiseのthenの時に渡される。
promiseのthenが呼び出されるのはfetchの処理が完了した後。

つまりresponseを取得したとき＝fetchし終わった時に
abortするのは遅すぎる

**デフォルトの名無しさん** · 2017/04/08(土) 18:46:58.17

>>499
なにを見通してるのかさっぱり分からんがnodeは低水準のapiを提供するものだ
そうすれば複数のシステムコールを組み合わせた高水準apiはユーザーレベルのライブラリで実現できる
だからfsモジュールは意図的にposixの薄いラッパーになっていてキャンセルはない

**デフォルトの名無しさん** · 2017/04/08(土) 18:50:52.30

>>504
仕様にはstreamが追加されてる
https://fetch.spec.whatwg.org/#streams

**デフォルトの名無しさん** · 2017/04/08(土) 18:56:59.44

>>505
> nodeは低水準のapiを提供するものだ

どこにそんなことが書いてあるのか？

nodeの立場はブラウザと同じだ。
JavaScriptの実行環境だ。

お前の理屈だと、ブラウザは低水準のAPIを提供するものということになる。

**デフォルトの名無しさん** · 2017/04/08(土) 18:58:44.31

>>505
> だからfsモジュールは意図的にposixの薄いラッパーになっていてキャンセルはない

じゃあ、例えば、fs.lstatSync は posixのどの薄いラッパーなのか言ってみ

**デフォルトの名無しさん** · 2017/04/08(土) 19:01:09.86

>>506
> 仕様にはstreamが追加されてる
どっちみち仕様を加えるなら
Observableにした方がいいだろうな。

**デフォルトの名無しさん** · 2017/04/08(土) 19:02:35.33

しかもPOSIXは非同期I/Oをキャンセルする機能あるじゃんｗｗｗ

https://linuxjm.osdn.jp/html/LDP_man-pages/man3/aio_cancel.3.html
aio_cancel - 完了していない非同期 I/O リクエストをキャンセルする
POSIX.1-2001, POSIX.1-2008.

**デフォルトの名無しさん** · 2017/04/08(土) 19:22:58.68

>>507
https://nodejs.org/api/fs.html
File I/O is provided by simple wrappers around standard POSIX functions.

>>508
lstat

>>510
posix aioはほとんどのosで実装されてないしnodeでもサポートしてない

**デフォルトの名無しさん** · 2017/04/08(土) 19:25:59.41

>>510
細かく言うとposix aioはほとんどのos kernelで実装されてない
gnuがユーザーレベルのライブラリとして実装したものがあるだけ

**デフォルトの名無しさん** · 2017/04/08(土) 19:34:34.87

manだとlstat(2)に対して>>510のaio_xxx(3)なのでシステムコールじゃないことが分かる

**デフォルトの名無しさん** · 2017/04/08(土) 19:36:55.48

>>511
lstatは非同期じゃないぞｗ

**デフォルトの名無しさん** · 2017/04/08(土) 19:39:34.36

>>504
fetch apiが返すpromiseはfetchが完了してからresolveするわけではない
完了してからresolveするのはres.text()が返すpromise

**デフォルトの名無しさん** · 2017/04/08(土) 19:40:34.49

>>514
>>508のlstatSyncは非同期じゃない

**デフォルトの名無しさん** · 2017/04/08(土) 19:43:59.84

>>516
逆だったなｗ
fs.lstatの方だ

**デフォルトの名無しさん** · 2017/04/08(土) 19:45:48.32

>>517
lstat

**デフォルトの名無しさん** · 2017/04/08(土) 19:46:03.01

>>515
> fetch apiが返すpromiseはfetchが完了してからresolveするわけではない

完了してからだよ。正確にはレスポンスが返ってきてから、
データの受信が完全に完了してからではない。

でないと、Response.statusが取れるわけがないだろう？

**デフォルトの名無しさん** · 2017/04/08(土) 19:46:40.03

>>518
それではシステムコールにあるPromise相当のものは何？ｗ

**デフォルトの名無しさん** · 2017/04/08(土) 19:51:37.12

>>519
そう、だから完了してからじゃないじゃん
最初のチャンクが届いたらresolveする
「fetchの処理が完了した後」は明らかな間違い

**デフォルトの名無しさん** · 2017/04/08(土) 19:53:33.42

>>520
システムコールにはない
単にワーカースレッドでlstat呼ぶだけ

**デフォルトの名無しさん** · 2017/04/08(土) 19:53:53.72

>>521
Fetchの処理はリクエスト投げてレスポンス戻すところまでだよ。
ダウンロードが終了するまでの話は最初からしてない

で、Fetchのキャンセル（thenが発動する前）はPromiseでできるの？
できないでしょ？
そこに新しい仕様が必要ならObservableを使えば良いわけさ。

**デフォルトの名無しさん** · 2017/04/08(土) 19:54:42.49

>>522
だろう？　Promiseを含めて「システムコールの軽いラッパー」と
お前が呼ぶならば、Observableを含めたって「システムの軽いラッパー」になる

**デフォルトの名無しさん** · 2017/04/08(土) 20:03:11.46

>>523
fetch apiがpromiseベースでバカなのは何年も前から言われてるし俺も言ってきたからそこに反論する気はない

**デフォルトの名無しさん** · 2017/04/08(土) 20:05:16.72

>>524
キャンセルできなくて単発で結果が決まるシステムコールのラッパーにpromiseよりobservableを選ぶメリットは？

**デフォルトの名無しさん** · 2017/04/08(土) 20:20:53.33

システムコールとライブラリの違いをわかってないやつがいそうだから、用語をシステムAPIかOSのAPIで統一してくれ

**デフォルトの名無しさん** · 2017/04/08(土) 20:27:37.55

>>526
並列処理がしやすいから

**デフォルトの名無しさん** · 2017/04/08(土) 20:31:19.27

>>523
何度も説明してるが、キャンセルは必要だが、Observableはそぐわない
CancelTokenのようなものじゃないと実際齟齬が出るし
その流儀に則って真似して使いやすいように色んなAPIを実装していくのは大変

**デフォルトの名無しさん** · 2017/04/08(土) 20:33:09.43

俺がobservableの話で並列処理の話を始めると
すぐにキャンセルの話に変えるやつってなんなんだろうねｗ
わざとなのかな？

**デフォルトの名無しさん** · 2017/04/08(土) 20:38:17.35

>>528
正しくは並行処理だが常に必要となるわけではない
必要ならpromiseをobservableでラップすればいいだけ
そのために無駄に高機能なapiを土台にするメリットはない
シンプルの上にリッチを乗せることは有意だが逆は無意味だ

**デフォルトの名無しさん** · 2017/04/08(土) 20:40:15.25

> 正しくは並行処理だが常に必要となるわけではない

絶対に必要ないならいらんだろうさ
常に必要となるわけではない＝必要な場合もある。
ならば同じやり方でやったほうが楽

**デフォルトの名無しさん** · 2017/04/08(土) 20:49:17.82

長さ1の配列があればスカラ値の変数はいらない

let x=1
let y=2
let z=x+y

これは配列が必要な場合と同じやり方で

let x=[1]
let y=[2]
let z=[x[0]+y[0]]

ってやった方が楽
なるほど

**デフォルトの名無しさん** · 2017/04/09(日) 16:42:26.31

なるほどじゃねぇよ

**デフォルトの名無しさん** · 2017/04/09(日) 17:00:22.44

Observableだけでなく、jQueryもLodashもそうなんだけど、
配列をスカラのように扱うことができるんだよね。

1と2以上を同一化して処理できる。

例えばquerySelectorAllは配列を返す。$()だとスカラ値を返す
どちらもセレクタから複数の要素を検索しているようだけど、この違いによって
querySelectorAllではループ処理が必要になるが、jQueryではループ処理が不要になる

Promiseも単数だから並列しようと思ったら配列が必要になってループも必要になる
つまり>>533でいう後者の書き方
Observableであれば単数も複数も同じように処理できるから、>>533の前者の書き方で
複数の対象を単数と同じ書き方で並列に処理できる。

**デフォルトの名無しさん** · 2017/04/09(日) 18:21:09.53

querySelectorAllが配列を返すなんてとんと知りませんでしたわ

**デフォルトの名無しさん** · 2017/04/09(日) 19:39:40.08

そもそも「配列」という言葉の定義がない
因みにNodeListは@@iterator対応の予定がずっとある

**デフォルトの名無しさん** · 2017/04/09(日) 20:58:23.64

jQueryしか使わないゆとりだから下のレイヤーのことは知らないんだろ

**デフォルトの名無しさん** · 2017/04/09(日) 21:08:17.95

下層民同士仲良くしなさいよ～
粛清すっぞ

**デフォルトの名無しさん** · 2017/04/10(月) 16:04:40.78

一年に１，２回はtoArrayをどうするかの話題で盛り上がるよね
Array、TypedArray、@@iterator、length、Array.isArrayとか沢山楽しい話できるよね

**デフォルトの名無しさん** · 2017/04/11(火) 15:44:57.90

キャンセルトークン方式のプロポーザル
https://github.com/tc39/proposal-cancellation

**デフォルトの名無しさん** · 2017/04/11(火) 20:28:11.22

>>541

https://azu.github.io/slide-what-is-ecmascript/slide/12.html
Stage 0: Strawman
アイデア

から抜け出したら、もう一回知らせてくれ
せめてStage 3にならなければ評価する価値もない

**デフォルトの名無しさん** · 2017/04/11(火) 20:53:27.45

stage1のobservableも評価する価値がない
よってこの話題完全終了

**デフォルトの名無しさん** · 2017/04/11(火) 20:56:52.33

50歩100歩ってやつだな。
差は2倍もあるということだ

**デフォルトの名無しさん** · 2017/04/11(火) 21:09:11.09

デバッグ用にconsole.logで出力を行ってるんだけど、foreverで起動するときはどこにも出力されてないって事でいいのかな？

**デフォルトの名無しさん** · 2017/04/11(火) 21:46:41.59

今日追加されたのより一歩進んでたって話にならんよ

**デフォルトの名無しさん** · 2017/04/12(水) 12:43:00.43

>>544
ゴールまで千里の道というオチですね

**デフォルトの名無しさん** · 2017/04/12(水) 16:04:44.52

>>545
Optionsを観ると以下のようになってる。
-o OUTFILE Logs stdout from child script to OUTFILE
-e ERRFILE Logs stderr from child script to ERRFILE

**デフォルトの名無しさん** · 2017/04/16(日) 06:10:01.13

ln -s -f /dev/null /dev/stdout

**デフォルトの名無しさん** · 2017/04/21(金) 22:47:20.35

Converting circular structure to JSON
at JSON.stringify

自分なりにdeepCopyつもりのコードで
上記エラーが出た場合に、原因なコードを簡単に見つける方法ってどんなのがありますでしょうか？

**デフォルトの名無しさん** · 2017/04/22(土) 11:59:52.05

>>550
http://stackoverflow.com/questions/14962018/detecting-and-fixing-circular-references-in-javascript

**デフォルトの名無しさん** · 2017/04/25(火) 16:04:38.46

circular structur
原因書いてますやん

**デフォルトの名無しさん** · 2017/04/26(水) 14:11:46.04

>>551
まさにピッタリの解説でした。ありがとうございました。

**デフォルトの名無しさん** · 2017/04/28(金) 08:36:18.97

循環参照を持っていてもちょっと関数噛ましてテーブル２つに変換すればJSONに落とし込むことは可能だよ

**デフォルトの名無しさん** · 2017/04/28(金) 12:43:11.19

以下のように表記を統一するクラス（またはデータベース）でありますでしょうか？

'php' => 'PHP' ,
'perl' => 'Perl' ,
'javascript' => 'JavaScript' ,

**デフォルトの名無しさん** · 2017/04/28(金) 13:10:12.31

自然言語処理用でいいの最近見たけど忘れた

**デフォルトの名無しさん** · 2017/04/28(金) 15:01:07.81

思い出してください w

「自然言語処理 "単語の正規化" 」でググってみましたがズバリ思っているようなのはヒットしませんでした。
どなたか是非！

**デフォルトの名無しさん** · 2017/04/29(土) 05:10:42.30

つうか全部小文字の単語を直したいだけの辞書なら
通常の固有名詞辞書にちょっと手を加えればいいだけじゃん

あ · 2017/04/29(土) 11:53:18.38

freetaggerとか昔使ったことあるけど、javaScriptなんかの表記の統一は辛かったような。
isDisabledのiはどうするのとか、結局プロジェクト向けのスクリプト書いた気がする。

**デフォルトの名無しさん** · 2017/04/29(土) 12:10:57.72

>>559
結局はそうだよな
完全な答えがあるものじゃないし

**デフォルトの名無しさん** · 2017/05/03(水) 23:37:41.27

package.jsonの"scripts"に書いたコマンドをnpm runで実行する際はnode_modules/.bniがPATHに
追加されますが、これ以外に任意のディレクトリをPATHに追加する方法ってあるでしょうか。

**デフォルトの名無しさん** · 2017/05/03(水) 23:44:19.89

実行するコマンドの前で設定するとか

**デフォルトの名無しさん** · 2017/05/04(木) 01:58:16.57

windowsだからpythonのpip以上にnpm厄介だな

**561** · 2017/05/04(木) 11:09:36.82

ありがとうございます。でもwindowsだとうまくいかないなぁ。

"somecommand": "set PATH=%PATH%;<パス> && <コマンド>"
＃<コマンド>は内部でPATH環境変数を使用するスクリプトで、これ自体にはPATHが通っている。

&&の両側のコマンドが同時に立ち上がるんだから当然と言えば当然か。
でもコマンドプロンプトで順次実行する&に変えても結果は同じだった。
bashのexportみたいなのが使えればいいんだけど。

**デフォルトの名無しさん** · 2017/05/04(木) 11:15:14.24

めんどくせぇなぁ、
そのためのnpmライブラリでもあんだろ

**デフォルトの名無しさん** · 2017/05/04(木) 14:13:58.13

cross-envが定番
https://www.npmjs.com/package/cross-env

**デフォルトの名無しさん** · 2017/05/04(木) 14:31:06.73

他にnpm-run-allとかrimrafとかあればwinでも動くnpm scriptsが書ける

**561** · 2017/05/04(木) 15:13:22.65

ありがとうございます。cross-envでいけました。

**デフォルトの名無しさん** · 2017/05/06(土) 06:40:04.53

カオスですね

**デフォルトの名無しさん** · 2017/05/08(月) 19:19:22.70

node.jsでimportを使うと
SyntaxError: Unexpected token import
ってなるんですが、importに対応したnode.jsはまだ出てないのでしょうか？

**デフォルトの名無しさん** · 2017/05/08(月) 19:53:32.68

質問する前にぐぐれ
http://sakamock.hatenablog.com/entry/2016/02/03/091623
http://yosuke-furukawa.hatenablog.com/entry/2016/05/10/111102
http://va2577.github.io/post/18/

**デフォルトの名無しさん** · 2017/05/09(火) 01:01:42.73

>>571
importの使い方を聞いていません
babelとwebpackでimport書いてるので使い方は知ってます
node.js自体がimportを実装しているのかを聞いています

**デフォルトの名無しさん** · 2017/05/09(火) 06:20:18.78

してないよ

**デフォルトの名無しさん** · 2017/05/09(火) 06:58:49.50

*.mjsからはimport出来るようにしようぜ
ってのを結構前に読んだ気がするけど、まだ実装されたないんか?

**デフォルトの名無しさん** · 2017/05/09(火) 08:05:18.10

実装どころか提案文書はドラフトのままだよ
(技術的検証が済んでACCEPTされないと実装に進まない)
検証だけであと1年以上掛かるってさ

なお拡張子(*.mjs)でES moduleかどうか判別する手法は
考え得る限り最低の糞という判断が下されたので無くなる

**デフォルトの名無しさん** · 2017/05/09(火) 14:19:15.46

そこはESの管轄外だよ
NodeがWebと合わせる必要もない

**デフォルトの名無しさん** · 2017/05/09(火) 14:46:23.14

相互運用性は必要

**デフォルトの名無しさん** · 2017/05/09(火) 14:48:00.66

いやnodeってv8使ってる立場だから何もできんでしょ
間違ってる？

**デフォルトの名無しさん** · 2017/05/09(火) 15:09:01.72

v8はネットワークもファイルシステムも持ってないからimportは環境(ブラウザやnode)に丸投げでしょ

**デフォルトの名無しさん** · 2017/05/09(火) 15:45:52.73

なるほど

**デフォルトの名無しさん** · 2017/05/09(火) 16:25:22.62

Buffer.byteLengthをブラウザ側でも利用できるように移植して欲しい
今時バイトでカウントするにも自力でコード書かないといけないのは無駄すぎる

**デフォルトの名無しさん** · 2017/05/09(火) 21:56:24.65

importはJavaScript（EcmaScript）の仕様範疇の中に入れてもいいが、
ブラウザで動かすJavaScriptにおいて、
importはビルド時に解決する問題になるんだよね。

なぜならファイルのアクセス数が増えてパフォーマンス低下につながるから。
JavaScriptファイルを結合することでパフォーマンスをあげるという目的があるから
結合させずに動いたとしても、ビルド時に結合させるという手段は今後も続く。

ウェブサーバーのプラグインでJavaScriptファイルをimport定義に従って
結合するという仕組みができるかもしれないがこれもビルドを配信時に行うってだけ

**デフォルトの名無しさん** · 2017/05/09(火) 22:01:42.74

>>581
ブラウザ側で実装する or 自力でコードを書く

の中間に、ライブラリを使うという方法があるよ。
この方法を使えば、既存のブラウザでも動くし
自力でコードを書くムダもない

自力でコードを書けるたぐいのものなら、ブラウザに移植してほしい理由を言うとしたら
「ネイティブで実装されていれば速い可能性がある」であるべきだろう

あ · 2017/05/09(火) 23:27:53.20

>>582
すごく巨大なファイルへのアクセス数でパフォーマンス低下するか、
CDNで配信されてて、もうすでにブラウザキャッシュに存在するかだと、後者の方が速いと思うけど。

**デフォルトの名無しさん** · 2017/05/09(火) 23:38:56.70

すごく巨大なファイルもCDNで配信されブラウザにキャッシュされるだろw

**デフォルトの名無しさん** · 2017/05/09(火) 23:45:41.79

お前らhttp/2知らんのか

**デフォルトの名無しさん** · 2017/05/10(水) 02:35:14.26

>>586
コネクションが再利用されるとしても、
ファイル要求は別に行われるだろうが

**デフォルトの名無しさん** · 2017/05/10(水) 02:43:19.47

要求されるまでもなくプッシュできる
キャッシュとの絡みで今んとこ絵にかいた餅だが

**デフォルトの名無しさん** · 2017/05/10(水) 06:37:42.31

ふーん
そういう妄想は同人誌即売会で売ってるといいよ

**デフォルトの名無しさん** · 2017/05/10(水) 11:21:57.19

それよりもminifyが未だにes2015を正式対応してないの早くなんとかしてほしい。ブラウザがes2015サポートしてても結局es5で吐き出してる

**デフォルトの名無しさん** · 2017/05/10(水) 22:20:22.50

babel使えば？
babel自体にminify入ったろ？

**デフォルトの名無しさん** · 2017/05/10(水) 22:27:47.55

>>591
おー。愚痴ってみるもんですな。
typescript使ってたんだけどbabel挟んでみようかな。

**デフォルトの名無しさん** · 2017/05/10(水) 22:31:57.68

typescript使ってるならビルドした後minifyすればいいだろ

**デフォルトの名無しさん** · 2017/05/10(水) 23:04:23.70

>>593
そう言ってるんだよ

**デフォルトの名無しさん** · 2017/05/11(木) 09:14:44.78

jsでデスクトップアプリケーションが作成できるelectronでソフトを作りたいのですが、
http通信のためのモジュールであるrequestモジュールを、main processからrequireするといろんなプロパティを持ったオブジェクトが返ってきてその中の関数でhttp通算できるのですが、
renderer processからrequireするとただのrequestという名前の関数オブジェクトが返されるだけで使い物にならないです。
pc通信でrenderer processからmain processにhttp通信を代行してもらうしかhttp通信をrenderer processで扱うための方法はないですか？

**デフォルトの名無しさん** · 2017/05/11(木) 09:15:08.72

x pc通信
o ipc通信

**デフォルトの名無しさん** · 2017/05/11(木) 15:47:14.50

>>595
renderプロセスはブラウザと同じなのでfetch使えばいいですよ

**デフォルトの名無しさん** · 2017/05/12(金) 10:36:16.44

>>582
なんかごちゃごちゃ言ってる間にブラウザがモジュールサポートし始めたで
https://medium.com/dev-channel/es6-modules-in-chrome-canary-m60-ba588dfb8ab7