Node.jsのStreamのpipeの練習

(他の言語での成り立ちなど)Streamの概念的な話ではなく、とりあえず Node.js の Stream を使ったコードが動くまでが分かりにくかったので練習したよ、ってだけの話。1

特に、例題として上がりやすいのはファイルを読み込みながらファイルの書き出しや HTTP レスポンスを返すとかそういうやつなんだけど、その説明は Node.js のよくある用途的には分からなくはないけど、自分の場合はそういうことよりもメモリの中身と stdout の方が分かりやすかったのでそれでやってみて、自分なりにまとめてみた。

※ 分かりやすさを重視してコードを触っていましたが、やはりダメでした。続きは StreamをEventHandlerを使ってPromiseに変換して成否を待ったり途中で止めたりする で。

Streamのメリット

大きなデータを小分けに扱うことができるので、Node.js の特徴であるシングルスレッド、イベントドリブン、ノンブロッキングI/Oの特徴を活かしやすい。

もちろんメモリ消費も抑えることができる。

Streamの種類

Stream には種類があり、以下の3つが基本。(Duplex はあえて省略。)

  • Readable
  • Writable
  • Transform

基本的な使い方と罠

誇張や嘘はあるかもしれないが、以下のように割り切っておくと分かりやすい。

  • Node.js では Stream は結局のところ EventEmitter である
  • Read Event が発生しないと次に処理が進まない

つまり、なんらかの出力を行いたい場合は最低でも Readable Stream と Writable Stream をワンセットで使う必要がある。

※ 出力を行わない場合は Readable Stream で渡ってくる chunk を淡々と処理するのでもよいが、今回はそれは扱わない。

メモリの内容をstdoutにstreamしてみる

最低限必要な準備はこんな感じ。

const {Readable} = require('stream')

const readable = new Readable()
readable.pipe(process.stdout)

これで「Readable Stream にデータが渡ってきたら STDOUT に出力するよー」という意味になる。

実は Node.js では process.stdin が Readable Stream で process.stdout が Writable Stream なので、Unix パイプを awk っぽく扱うのに向いている。ただし process.stdin を process.stdout に pipe するだけだと Node.js 要らないじゃんて感じになるので、あくまで Node.js の中のメモリの情報を stdout に出力してみることとする。

というわけで Readable Stream にデータを送ってやる。

readable.push("Hello World\n")
readable.push(null)

これでできあがり。無事に STDOUT に Hello World と表示される。

全体像は以下のようになる。

const {Readable} = require('stream')

// stream の構築
const readable = new Readable()
readable.pipe(process.stdout)

// stream にデータを流す
readable.push("Hello World\n")
readable.push(null)

もうちょっと本格的にメモリの内容をReadable Streamにする

実際には Readable Stream にわざわざ push しなきゃいけないシーンはないというか、こういう書き方は書く順番に依存しすぎてるし、おまじないじみててよろしくないので、実際にやる場合はもうちょっとなんとかした方がよい。

そこで以下を追加する。(似たような npm はいくつもあるが、これが人気っぽい)

memory-streams - npm

実際のコードはこんな感じになる。

const streams = require('memory-streams')

(new streams.ReadableStream(
  JSON.stringify({
    foo: 'bar'
  }) + "\n"))
  .pipe(WritableStream)

これで Writable Stream しか用意されていない pkgcloud/pkgcloud の Storage のようなものにもメモリから直接書き込むコードを分かりやすく書くことができるようになる。

ただし、メモリの内容を Stream で扱う際に注意しなければいけないのは、Stream は小分けに順番に処理するためのものなので、Array や String など順番が決まっているものしか扱えないということ。そのため上の例では Object を JSON に変換しているが、もし元の Object そのものが巨大な場合はその部分で小分けにするのは不可能である。

※ JSONStream という package もあるが、これはあくまで巨大なデータに対する JSON.parse を Stream ベースで行うためのものと割り切った方がよさそう。JSON.stringify を効率的に行うにはいずれにせよ Array を基本に置く必要がある。

参考

ついでにブラウザ周りも

ブラウザーは Fetch や XHR などの操作を完了前に中止させることができる AbortController および AbortSignal インターフェイス(つまり Abort API)に実験的に対応し始めています。詳しくはインターフェイスのページを参照してください。

2018-09-24 確認時点で

IE は非対応、Firefox は Stream には一部設定で対応、という状況らしい。

こういう微妙な差異をすべて開発者でフォローするのは大変つらい。

  1. 例によって3, 4年遅れの話なんだけど、まぁ避け続けてた Node.js でこの程度の遅れならだいぶマシな気がしている。 

nodejuiceがヤバい2011

※ nodejuice は決して 2011年製のアプリではありません。Vimeo 上のデモムービーは 2009年に上がっています。同時に、開発は止まっていません。

ブラウザのリロード自動化2011秋 から読んでもらえると嬉しいです。

ブラウザの自動リロードの話が長くなりそうだったので特に紹介したいものは別エントリにした。まずは nodejuice から。

三行紹介

http://nodejuice.com/

node.js を使ったアプリなんだけど npm からインストールできずにやや面倒くさい。また、割と最近の Web アプリの考え方が分かっていないとそもそも WSGI などの用語が分からない。ということはつまりアプリの動作イメージがつかめない。

実際には

  • 特定のフレームワークに依存しない
  • ブラウザも選ばない
  • HTML を自分で書き換える必要もない

と、かなり素晴らしいツールである。何しろ HTML の調整もせずにブラウザも選ばないとなればあの IE でもリロードを自動化できて、検証のコストを下げることができるのだから。

もう少し特徴を列挙

  • ブラウザとサーバの間に入って動作
    • サーバがない場合は自身が Web サーバとして動作(WSGI)
  • サーバ側のファイルの変更を検知して通知(seeker)
  • アプリケーションの返す HTML に変更を加える proxy として動作
    • ここで seeker の js へアクセスさせる <script> を追加してくれる
    • サーバ側ですべて完結するので複数のブラウザを同時に reload させられるし、ブラウザを選ばない
  • アプリケーションサーバ内で動作する必要はないのでアプリケーション環境も選ばない
  • 難しいことを考えなくても static なサイトのためにもすぐに使える
  • Mac + nodejs + nodejuice なら環境を作るのはそれほど難しくない。やってみた。
    • この Mac 上にサイトを起き、Windows からこの Mac へアクセスすれば Windows での検証の手間も減らせる

準備のハードルは若干高い1が、より多くの環境での検証の自動化を助けるという意味ではエンジニア好みな感じ。またどの言語、どのフレームワークでの開発にも使えるのが大きい。

※ node.exe で nodejuice を動かせるかどうかは試していないので分からない。

まとめ

nodejuice はアイディアは良いんだけど、使い始めをもう少し簡単にしてくれるとドキュメントや実際に試す人が増えてくるのかなぁという感じ。両方ともあまりに少ないのが難点。やってることのイメージがつけばそれほど難しいものではないと思うが、あまりに声が少ないと不安になってしまう。

それとも気づいてない問題があるのか。WebSocket を使わずに status check しまくり script を挿入しておくのはブラウザによっては壊れやすいような気がしないでもない。デモムービーもよく見ると一部リロードできていないウィンドウがあるように見える。

ちなみに macports からは install できた。他の環境では恐らく手で入れないとダメ。

  1. と言っても node.js の環境がすでにあれば落としてきて広げるだけ 

JavaScript の debugger で勘違い& (function(){})() の中に入る

javascript には debugger って予約語があるじゃないですか。あれって

debugger を起動するためのものじゃなくて、break するためのものなんですね

分かってなかった。

  1. debugger を書き足してブラウザを reload してボーっ。何も起きないなー。
  2. あ、debugger というか Firebug は自分で開いておかないとダメなのか。おばか。
  3. ぼー。
  4. あれ? window.onload で走る処理が動かない <- その前に break してた。
  5. あれ? じゃあどうやって (function(){})() なコードの中に入るの?
  6. setTimeout() でタイミングをずらして break

なんとかなった。

ETag って特に書式ないの?

RFC 2616 - Hypertext Transfer Protocol – HTTP/1.1

3.11 Entity Tags

Entity tags are used for comparing two or more entities from the same requested resource. HTTP/1.1 uses entity tags in the ETag (section 14.19), If-Match (section 14.24), If-None-Match (section 14.26), and If-Range (section 14.27) header fields. The definition of how they are used and compared as cache validators is in section 13.3.3. An entity tag consists of an opaque quoted string, possibly prefixed by a weakness indicator.

weakness indicator と quote 以外はなんにも言ってない気がする。

実際例に挙がっている文字と例えば Apache の返す ETag 文字列とはまったく異なる。要は

リソースの変化が検出できる仕様になっていて " で囲まれていれば何を基準にどんな文字列を生成するのも自由

ってことかな?

あーなるほど。この解釈で合ってるみたい。

  • Apache はデフォルトでは inode, mtime, size を - で結んだ文字列を返す
    • core - Apache HTTP サーバ
    • inode が絡むとスケールアウトさせられないので大規模なサービスでは inode は使わない設定にするらしい。
  • Rails は response body の md5 を返す

単純なファイルを返す場合以外は Rails 方式を採用するのがいい感じだ。

crontab モジュールで warning

RAA - crontab

を require したら怒られた。

warning: parenthesize argument(s) for future version

引数を与えるなら ( ) を書きましょう、ということらしい。

cf. [ruby-dev:17868] Re: parenthesize argument(s) for future version

@@ -111,7 +111,7 @@

   def add(str, job = nil)
     job = proc if iterator?
-    @table.push((parse_timedate(str) << job).extend CronRecord)
+    @table.push((parse_timedate(str) << job).extend( CronRecord ))
   end

   attr_reader :table
@@ -173,9 +173,9 @@
              elsif l.nil?
                f.to_i .. f.to_i
              elsif f.to_i < first
-               raise FormatError.new "out of range (#{f} for #{first})"
+               raise FormatError.new( "out of range (#{f} for #{first})" )
              elsif last < l.to_i
-               raise FormatError.new "out of range (#{l} for #{last})"
+               raise FormatError.new( "out of range (#{l} for #{last})" )
              else
                f.to_i .. l.to_i
              end

こんな感じですか。よく分かってないけど、警告は出なくなった。使ってみるのはこれからです。

……。

おっと。これ、環境変数を定義している行を無視できてないな。(MAILTO = とか使いませんか。)

@@ -136,7 +136,8 @@
   def parse(str)
     res = []
     str.each{|line|
       next if /(\A#)|(\A\s*\Z)/ =~ line
+      next if /(?:\S+\s+){5}(.*)/ !~ line
       res.push(parse_timedate(line).
               push(line.scan(/(?:\S+\s+){5}(.*)/).shift[-1]))
     }

こういうことですか。なんか二度手間っちゃ二度手間なんだけど、いきなり res.push しちゃってるからしょうがないか。parse_timedate() が解釈に失敗したときに false を返すとかすればいいのかしらん。

上のレイヤーに絞ってみる

odz buffer - だれかまとめてくれないかな

※ まとめる気全然なくてごめんなさい。

特定の処理系ベッタリになってもらっちゃ困るっつーのは当然上のレイヤーでもあって、

  • オブジェクト指向 = Java のオブジェクト指向と思い込む
  • 何で書いても BASIC みたいなコードを書く(BASIC は適当な他の言語に置き換えてもらっても ok)

人って意外と多いよねぇ、てなことを思いました。つかありゃいったいなんなんだという怒りを素直に表明しておきますが。

こういうのに巡り会うともっとちゃんと勉強してほしい、と強く思いますね。お前は Java の教科書(当然仕様書じゃなくて、本屋で手に入る割とやさしめの本)に書いてあったことがすべてなのか、とかいつまで変数名 8文字までなんすか、とかなんでイマドキすべて for ( ;; ) なんすか、とか。

でもこういうのって何を学ぶべきなのかなぁ。

いろいろやれ

ってことなのかなぁ。実際いろんな言語は触っておいた方がいいと思うし、自分もできればいろんなものを習得したいと思ってるんだけど、なんかすごくアバウトで、それを他の人に言ったところで、ふーんでおしまいですよね。

cf.

WAP1 は禁止にしませう

http://www.zdnet.co.jp/mobile/0309/22/n_hdml.html

カメラは要らないし折りたたみもきらいだけど XHTML には対応しててほしい。

いや、実際はよく考えられてるんですよ、HDML って。実によくできています。携帯のスペックが上がったからあんまり必要ない工夫なんかもありますけどね。少なくとも DoCoMo のなし崩し CompactHTML 拡張よりはなんぼかマシです。現場ウケは悪いでしょうけど、現場ウケとモノの良し悪しは別ですから。(だからと言っていつまでも残っていてほしくはないです。早くみんな XHTML になっちゃってくれ。DoCoMo は PNG もちゃんとサポートしろ。)

テンキーレス Realforce

http://www.zdnet.co.jp/products/0309/22/topre_new.html

あぁ。。。

トラックポイントさえつけば。

About

例によって個人のなんちゃらです