Block Rockin’ Codes

back with another one of those block rockin' codes

2012 年をふりかえる

intro

恒例の振り返りです。

Output

それなりにアウトプットを意識してきたので、今年は多かった気がします。


共著ながら書籍もやっと出せたし、 Web+DB Press へのデビューもしました。


あと、学園祭にも携わったし Node 学園だけでなく、 Pyfes などでも発表させてもらったりしたので、
イベント関係も多かったとですね。


逆にイベントの準備や、文字でのアウトプットが多かったので、
来年はもっとソースでのアウトプットを増やしていきたいです。


この Blog については、月一回は必ず書くという地味な目標を立てているんですが、
今年は 1 月から落としてしまって、悔まれる。
(hatena 過去一覧で書かなかった月が欠けるのですぐわかる。)


しかし、それ以外の月はそれなりに意識して書いたので、来年もこのペースで忙しかろうと続けたいと思います。


総じてアウトプットよりな一年だったかなと思う。

Input

「 1 年に 1 つは新しい言語を」的な意味では、今年は Haskell のつもりだったんだけど、
結局満足にできなかった。


言い訳は色々出てくるけれど、なによりも言語を学ぶこと自体を目的にしてたのが失敗だったのかなと思います。


モチベーション自体はあるので、いずれ再チャレンジかな。


あと読んだ本と言う意味では、少し少なかった気がする。


ただ、近年は本を買ってまるまる全部読むみたいなことは余りしてなくて、
必要な時に必要なページだけ読むスタイルになっていることもあると思います。
(なので、購入はしている)


あと、今年は RFC 読んでた時間が長かったですね。


もう少し違ったタイプの本に手を出すのも良いですが、
今関心がある分野は、書籍が出る頃には古くなってるような物が多いので、
どちらかというと書籍にはこだわらずにインプットを続ければよいなかなとは思ってます。

I/O

今まで色々な勉強会に行ったけど、もっと議論するような場の比重を増やしたいなと思ったのが今年でした。


ちょうど HTTP2 とか WebSocket まわりの話もあったので、「次世代 Web 勉強会」(といっても少人数で議論ベース) 的なのをやろうかと思った時期があったんだけど、
あれよという間に、それが CROSS2013 でやらせてもらえる事になって、登壇者も凄い人たちに集まって頂けたので、今から楽しみです。


ただ、ここだけで終わるんじゃなく、もう少し規模を小さくして来年何かしらにつなげられればとは思っています。


ということで、来年は Input, Output 単位ではなく I/O をより意識したいです。

2013

今少し思うところがあって Go を触ってます。
これは、割と明確な目的があって触ってるので、今のところ割と順調に進んでる気がする。


来年は、この辺を少し掘り下げて自分の手札をもう少し広げたいなと思いまます。



HTTP2 と WebSocket 周りは引き続き追いつつも、追うだけではなく、もう少し踏み込んだ関わりもしたいかもというのもあります。
その辺が上と繋がるイメージ。


あとは、自分の弱点が色々見えて、それがために苦い思いもしたので、
目の前に感じてる壁を超えて、もう一歩次のレベルに行けるようにがんばりたい。


そんなこんなで、 2013 年も、どうぞよろしくお願いいたします。

これからの Web の話をしよう。 (次世代 Web セッション @ CROSS2013)

cross http2 spdy websocket

update

2013/1/13
終了したので録画やログを追加

intro

2013/1/18(Fri) に開催される CROSS2013 にて、「次世代 Web セッション」というセッションを担当させていただくことになりました。


次世代 Web セッション


今日はこのセッションの内容と、このセッションで自分がやりたいと思っていることについて書こうと思います。

Theme

このセッションは「次世代 Web セッション」というタイトルとし、主にいま起こっている Web の変化(リアルタイム Web, HTTP2.0 の登場 など)について、

  • 「何が起こっているのか」
  • 「どこに向かっているのか」


を、


の 2 つのセッションに分けて議論したいと思っています。
(枠自体は 「次世代 Web セッション」の 1 つですが、内容的には 2 つのセッションからなります)

Motivation

HTTP, CGI, Ajax, HTML5 etc と、 Web には今までもいろいろな変化がありました。そして今また、 Web が大きく変わりつつあると感じています。


この変化をキチンと把握するのはなかなか難しいです。


例えば「WebSocket とは？」といった部分的話は割りとしやすいので、初心者向けの話は多くのイベントでされています。 一方で、そうした初心者向けの話は、もう聞き飽きている人も多くいます。 しかし、初心者向けセッションの「その先」を扱うのは実は結構難しいのが現実です。


今回の CROSS では各 1 時間という時間をつかって、初心者向けセッションで語られない「その先」に挑戦したいと思っています。


「Web がどうなるか」に答えを持っている人はいません。しかし、僕ら技術者はそこにコミットすることはできると思います。


「どこに向かっているのか」を考えるには、まず今「なにが起こっているか」をきちんと把握する事も必要です。


そこで自分は

  • 「何が起こっているのか」
  • 「どこに向かっているのか」


について、きちんと議論する場を作りたいと思い、それの議論ができるであろう方々に、声をかけさせて頂きました。

「プロトコル編」(14:00-15:00)

今起こっている変化の主流には、プロトコルレベルで Web を見直すという取り組みが大きく関わっていると考えます。


そこでは様々なステークホルダが参加しているので、議論される問題は Web の現状を浮き彫りにし、非常に興味深いものがあります。


プロトコル編では、主に Web のプロトコル自体の変化(WebSocket, SPDY, WebRTC, HTTP2.0 etc)について、低レイヤで何が起こり、どこに向かっているかを議論したいと考えています。

登壇者
  • 小松さん(@komasshu)
  • 大津さん(@jovi0608)
  • 清水さん(@kazubu)

「アーキテクチャ編」(15:15-16:15)

プロトコルが変わると、アーキテクチャが前提としていた制約が変わります。 すると、自ずとアーキテクチャも見直す必要が出てきます。


また、プロトコル以外にも、サービスに求められる要件の変化によっても、アーキテクチャは変化しています。


「アーキテクチャ編」では、そうしたプロトコルの変化、時代の要求の変化により、Web のアーキテクチャがどうなっていくだろうかという点について、議論したいと考えています。
キーワードとしては REST や MVC、リアルタイム、リアクティブ、バイナリベース/テキストベースなどを考えています。 ただ、キーワードはあくまで議論の呼び水であり、議論の主軸は「何が起こり、どこに向かっているのか」です。

登壇者
  • 山本さん (@yohei)
  • 江島さん (@kenn)
  • 佐々木さん (@yssk22)

扱わない内容

今回は、各セッションが 1 時間しかありません。 これは、ちょっと真面目に議論すればあっという間に過ぎてしまうと思います。
その限られた時間の中でとにかくテーマに集中するために、いくつか切り捨てる内容について書きたいと思います。


これは、自分が今回「あまり積極的に扱う必要がない」だろうと考えているものです。 といってもさじ加減なので、実際は登壇者の方々に委ねます。
しかし、参加者の方には「前提」として考えていただきたいと思っています。

初心者向け内容

難しいところですが、例えば「WebSocket とは何か？」「REST とは何か？」「IETF とは何か？」etc といった話は要らないと思っています。
知識を得て Catch Up するためではなく、議論を通して Keep Up するセッションにしたいという思いがあります。

過去の事

今回、テーマにはあえて「過去」を入れていません。 懐古するためのセッションとは考えていません。

  • 「何が起こっているのか」(現在)
  • 「どこに向かっているのか」(未来)


もちろん、古きを知ることは重要です。 Web の歴史、HTTP の歴史 etc 引き合いに出るでしょう。
しかし、過去を改めてから未来を語るには時間がたりません。過去は基本的には共有された前提として考えて、それらを踏まえた「その先」を中心に議論したいと考えています。

登壇者紹介

特に自己紹介で大きく時間を使ってしまうセッションが多いです。
今回の登壇者のみなさんは著名な方が多く、このセッションを聞きに来る方は知っている人が多いと思うので、冒頭に自分がみなさんの名前を紹介する程度とさせて頂きます。


各登壇者の紹介は、 セッション概要 から見ることもできますので。予め見ておいて頂けると良いと思います。

進め方

流れを決めすぎると予定調和になってしまうので、打ち合わせの段階でおおまかな方向性とキーワードのみを決めておき、
当日はそれについて基本的にはフリースタイルで議論を進めていきたいと思っています。


あまりズレて行くなら、途中で切るなどはしまが、その場で起こる議論をなによりも大事にしたいです。

最後に

今のWeb について

  • 「何が起こっているのか」
  • 「どこに向かっているのか」


に 1 時間フォーカスし続けたいです。 「その話はもう知ってるよ」とか、「何度も聞いたよ」みたいな話を無くして、少しでも議論の密度を高めたいです。
そのために参加者には「前提」を求める部分が多くなる点はありますが、限りある時間を有効に使うためにご理解ください。
これだけの方が揃ったセッションなので、変わりゆく Web の今後を考える上で、少しでも熱く有益な議論ができる場を作れればと考えています。



CROSS には、このセッション以外にも興味深いセッションが多数あります。
現在エンジニアや、それに関わることを何かしらをしていれば、気になるセッションがきっと一つはあると思います。
なにとぞよろしくお願い致します。

本番終了後ログ

無事本番を終えました。
自分としては、上記に望んでいたセッションができたので満足しています。


以下が録画です。


(前半) プロトコル編


(後半) アーキテクチャ編


スライド

最後の yohei さんの一言「あとは自分の頭で考えろ」が何よりのまとめです。
そして、それを考えるに足るだけのエッセンスはほぼ出てきました、
来ていただいたみなさんにとっても、これからの Web を考えるきっかけになったなら、よかったと思います。


今回のセッションを作るにあたっては、(最終的には登壇もして頂いたんですがw) t_wada さんに色々な面でアドバイスを頂きました。
こうしたセッションを作るには自分はまだまだ力不足だったので、非常に心強かったです。


そして、このセッションのために非常に豪華な登壇者の方に集まって頂きました。
みなさん忙しい中自分のわがままに付き合って頂いて、本当に感謝しております。


最後に muddy さんを始め運営のみなさん、このような機会を頂き本当にありがとうございました。


Jxck

アナログシンセのモジュールアーキテクチャ

stream

intro

この記事は、 Web Music Developers JP Advent Calendar 2012 の 22 日目の記事です。


今日は、モジュラーシンセサイザーの仕組みと、それがアーキテクチャ的にはモジュールの集まりで、
しかもそれらモジュールは Stream であると解釈できる点について紹介する。


このブログでは基本的に技術的なトピックしか扱わない。今回も限りなく音楽ネタに近い技術ネタ？だというつもりで書き始める。

"音" とは何か？

「音」とはなにか。


さて、ここから始めねばなるまい。
(と、書き出したかっただけで、読み返すとあまり必要はなかった)


音の世界の深淵に潜り込むと出てくる前に左小指が腱鞘炎になってしまうので、
ここはひとつ、音の「三大要素」にご登場願おう。(理科の時間に習ったよね？)

  • 音圧
  • 音程
  • 音色


まず、音圧だがこれは面倒だから音量(大きさ) と同じだと思っておいていい。
例えば(正確には違うが)、同じピアノを弾いていても、叩く力を変えれば変えることができる。


音程は高さ、ドレミファで表せるあれだ。同じピアノでも叩く鍵盤で高さを変えられる。


音色、これは楽器で言えば個々の独自の音だ。
例えばピアノの「ド」と、バイオリンの「ド」は違う音だ、
当たり前だが、この音色は基本的には楽器を持ち替えない限り変えることはできない。
ピアノを何十年弾きこんでも、バイオリンの音は出せないのだ。


シンセサイザーの挑む領域は、ひとつの楽器でこの三つの要素を全てコントロールしようというところにある。

コラム

Dr.Moog がアナログシンセを発明したばかりの頃、この電波実験器具のような機械を「楽器である」と宣言したことにより、「罪の意識は無いのか？」などと言われたという。
当時、楽器とは弦を弾き、管を鳴らし、皮を叩いて音を出すものであり、電気信号で音をだそうなど異端も異端、音楽に対する侮辱だという反応が多数だったようだ。このあたりは映画 Moog にて、 Dr.Moog 本人の口から語られていたと記憶する。

synthesiser

synthesis とは「合成」という意味であり、
synthesiesr は「波形を合成して音を作り出す」装置ということ。


音の基本となる波形を作り出し、それを鍵盤でコントロールし、アンプで鳴らすというのが、
楽器としてのシンセの基本構造だ。


スピーカで実際の「音」に変換されるまでの全ての工程では、あくまでも電気信号である。
この電気信号に対する操作を行うための様々なモジュールをシンセサイザーは備えている。


基本的なモジュールには以下の種類がある。

  • Oscillator
  • Filter
  • Low Frequency Oscillator
  • Envelope Generator


他にも色々な種類があるが、今回は上記基本モジュレータを例にシンセサイザーの仕組みを解説してみたい。
サンプルとして、手元にある Korg の名機 MS-20 の MIDI-Keyboard で実装を確認する。

http://pbs.twimg.com/media/A-u_GKWCAAEMYFc.jpg

Oscillator

VCO (Voltage Controlled Oscillator) と呼ばれ、日本語では発振器という。
音の基本になる波形信号を生成する装置、シンセの心臓だ。


最も基本的な波形はサイン波であるが、これはスピーカーを通しても味気ない音しか出ないので、
多くの場合合成波形を生成する。典型的な波形は以下の様なものだ。

  • サイン波
  • ノコギリ波
  • パルス波
  • ホワイトノイズ
  • リングモジュレータ(本格的なシンセにしかない)


これらを、ピッチやパルス幅などのパラメータを与えて生成する。
つまりシンセ内でのインタフェースとしては、幾つかのパラメータを取得して波形を生成する
Readable Stream といえる。


MS-20 の場合は、二つの VOC を搭載しており、ここで生成した波形をミキサーで混ぜることで、
より幅広い音作りができるようになっている。


http://pbs.twimg.com/media/A-u_QXdCUAEMtE4.jpg

Filter

基本的には以下の二つがある。

  • High Pass Filter
  • Low Pass Filter


例えば、High Pass Filter はすなわち Low Cut Filter と同意であるがフィルターの命名規則は「パスする帯域」に由来する。


名前の通り、 VCO からの波形をインプットとして受け取り、不要な周波数帯域をカットしてアウトプットする Filter Stream である(これぞ Filter !!)。


MS-20 の場合、カットオフ周波数とレゾナンス(peak)をパラメータとして渡すことができる。
アナログ回路の場合、レゾナンス値を振り切るとフィルターが発振し、オシレータになるという荒業がアナログファンを虜にした。
(にくい事に、KORG のアナログモデリングシンセは、デジタルでもこの現象が起こるようにしてくれている。さすがは日本が世界に誇る企業だ、わかってらっしゃる。)


http://pbs.twimg.com/media/A-u_UckCYAAF6dQ.jpg

Low Frequency Oscillator

LFO もオシレータなのだが、このモジュールの目的は音自体ではなく低周波数の波形を合成した時に生じる波形の「うねり」の生成が目的だ。


このうねりは、シンセによっては様々なパラメータに作用させることができる。
例えば、フィルターのカットオフをうねらせたり、ピッチをうねらせたり、音量をうねらせたり。


また、この周波数を変更することはうねりの幅を変化させるので、いわゆる

「みょーーんみょーんみょんみょんみょんみょみょみょ〜〜〜〜〜〜〜〜〜〜〜〜〜」

みたいなあれ(ww) をやるには、大体この辺をいじると変態感が味わえてメシウマである。


パラメータとしては、別のオシレータ出力を受け取り、それを元の波形に合成するので、
Stream としてはちょっと複雑な実装になるだろう。

http://pbs.twimg.com/media/A-u_XDPCQAApzQq.jpg

Envelope Generator

これは、音の時間的な音量変化を決めるモジュールだ。
基本的には音の時間変化を ADSR という 4 つのフェーズで調整する。

  • Attack
  • Decay
  • Sustin
  • Release


Attack は音の立ち上がりだ、鍵盤を押した時に一番大きな音量になるまでの時間を決める。
打楽器などは短く、バイオリンなどの音色を作るときは多少長くしてやる。


Decay は Sustin で決めた音量に遷移する時間。


Sustin は鍵盤を押している間になり続ける音の大きさだ。


Release は鍵盤を話した時に、音が消えるまでの時間を調整する。余韻の部分になる。
よくある図では以下のようになる。


http://pbs.twimg.com/media/A-vAo8-CQAENLT0.jpg


このモジュールはパラメータに時間を取り時間軸でコントロールをするため、自身も内部にタイマーを持つ、もしくは外部から時間を取得し合成するような特殊な FilterStream と考えることができる。


MS-20 では 2 つ積まれている。

http://pbs.twimg.com/media/A-u_bTBCQAAa8hq.jpg

パッチング

他にもシンセは様々な機能を持つが、多くは上記に挙げたものを基本としている。
つまり、モジュールとして用意した Stream をつないで波形を生成してく構成だ。


そして、モジュラーシンセはこうしたモジュールを、インプットとアウトプットを公開した形で用意している。そして、それらのインタフェース(多くは電圧)を合わせた上で各モジュールをケーブルでつなぐと、機能を拡張することができるのだ。


MS-20 では盤面右側がそこにあたる。以下の写真では

  • White Noise(右下) を用いて VOC の周波数(左上)をランダムに変化させる
  • パルス(左下)を用いて LPF のカットオフ(右上)を変更させる

というパッチングをしている。
他にも外部からのインプットを受け入れたり、波形をコントロールトリガとして再度別のモジュールに適用したりなど、自由度の高い音作りが可能だ。


よくシンセサイザーの写真がケーブルだらけなのは、こうしたモジュールの pipe() を自前でやっているからである。このケーブルがまさしく pipe 処理になるわけだ。

http://pbs.twimg.com/media/A-u_f8jCIAAZPQ6.jpg

スケーラビリティ

これらのモジュールは、基本的にインプットとアウトプットと合成のみを行うため、参照透過性を守っており、スケールさせやすい。

最終的なアウトプットをまとめるミキサーのインプットが許せば、無限にスケールさせることも可能だ。


以下は、アナログシンセの父である Dr.Moog の有名な写真だ。
手前のは VCO が 1, 2 個しかない mini moog というシリーズだが、
奥に並んでいるシンセは今回紹介したようなモジュール一式を縦に並べたものをユニットとし、ユニットごと水平にスケールさせていることがわかる。


http://moogarchives.com/bobmoog.jpg
(http://moogarchives.com/ より引用)

また、同様に外部モジュールもユニットにまとめてスケールさせており、必要に応じてケーブルで pipe されているのも見て取れるだろう。


日本では箪笥(たんす)と呼ばれた moog のアナログシンセは、こうした洗礼されたインタフェースを持つモジュール(stream) を pipe により自由に組み合わせ可能な疎結合な形で用意し、さらに水平スケールも可能な秀逸なアーキテクチャだというわけである。


駄文もいいところだが、書いた本人は非常に満足しているのでこの辺で終わりたいと思う。
(本当はもっと書きたいことがあった気がするが、それはまたいつか)

次世代規格 HTTP2.0 のファーストドラフト公開

http2.0 spdy

intro

少し経って、去る11月28日に、HTTP プロトコルの次期規格となる HTTP2.0 のドラフト、


draft-ietf-httpbis-http2-00

が、IETF の httpbis ワーキンググループで公開されました。


このドラフトは Google から提案された仕様である SPDY が採用されています。

HTTP1.1 からのアップデート

HTTP1.1 の RFC が提出されたのは 1999 年で、
13 年経った今年 2012年8月 に、 HTTP の仕様を議論する httpbis というワーキンググループが、
HTTP1.1 のアップデート版になる仕様、 HTTP2.0 の策定を開始しました。


これは、 HTTP1.1 の仕様策定がある程度落ち着いてきたこと、次期仕様を考える良い時期であること、
そしてなによりも、 Web の使われ方が大きく変わり、
求められている要求を満たすためには、見なおすべき点が現行の HTTP には多い、
という点からの策定着手と見ることができます。

複数の Proposal Draft

HTTP2.0 のドラフトに対する提案は、いくつかあげられていました。
主な個人ドラフトは以下の 3 つです。


(今回公開された draft-ietf-httpbis-http2-00 のように ietf という文字が入っているものは WG(ワーキンググループ) ドラフトと言い、
httpbis WG の中で採用されたものということを意味します。それに対して、ここに個人の名前(ないし愛称)が入っているものは、
個人ドラフトであり、ようするに WG ドラフトの元になる提案です。)

SPDY

http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy


今回採用されたドラフトであり、Google の Mike Belshe 氏の名義で出ています。
2009 年ごろから Google 内で開発され、現在では Google のほとんどのサービスで採用されているプロトコルです。
実装があり実績も十分にあるというのが、このドラフトの強みと言えます。
(最初に知った頃 はこんなことになるとは思わなかった。。)


multiplexing や compression などの基本的な効率化仕様はもちろん、 Server-Push や優先度付きストリームなどの仕様も含んでいます。
TLS に依存しないと言いながらも、ブラウザの場合は NPN(Next Protocol Negotiation) を用いて接続するため TLS が事実上前提となります。


現在 SPDY には仕様が 4 バージョンまでありますが、実質中身があるのは 3 つです。 SPDY Protocol - The Chromium Projects
今回 IETF にあがったのも、この SPDY Draft-3 でした。

HTTP Speed+Mobility

http://tools.ietf.org/html/draft-montenegro-httpbis-speed-mobility


Microsoft の Gabriel Montenegro 氏名義で出ています。
モバイルを重視し、スピードとセキュリティを強調した仕様として出ています。
ベースは SPDY であり、幾つかの仕様を外したりオプション扱いにしているものです。


大きな特徴として Session Layer に WebSocket を採用し、その上で通信を行うこと、
暗号化を必須にすべきではないとして、 TLS を必須にはしてないことが挙げられます。
(SPDY も使用上は必須ではないんですが、 NPN を使うのでブラウザからだと事実上必須な実装になります)


Network Friendly

http://tools.ietf.org/html/draft-tarreau-httpbis-network-friendly


HAProxy の作者 Willy Tarreau 氏名義で出ています。共同で Squid の作者 Amos Jeffries 氏も関っているよう。


正直自分はこの仕様についてはよく知らないです。


他のも含めて、こちらに概要がまとまっているので説明は譲らせて頂きます。
【HTTP 2.0の最新動向】 第1回：HTTP/2.0の策定、ついに始まる -INTERNET Watch


HTTP/2.0 Deliverables

こうした複数のドラフトの中から、 SPDY が HTTP2.0 のドラフトとして採用したのには、
やはり既存の実装があり、それが Google で全面的に採用されているという実績があるようです。


とはいえ、実は SPDY が HTTP2.0 のたたき台になることは、策定に着手した段階からある程度決まっていたことなので、
驚くほどではないといえば、そうなるかもしれません。


HTTP2.0 策定開始時には、以下のように宣言されています。


http://trac.tools.ietf.org/wg/httpbis/trac/wiki#HTTP2.0Deliverables

We're also chartered to work on a replacement for how HTTP is expressed "on the wire."
This effort is known as "HTTP/2.0", although it is not a ground-up rewrite of the protocol.

The basis of the work is [http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00:title=SPDY].
However, we will be collecting issues against this document, as well as confirming consensus over individual portions.

See also [http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00:title=Tickets] related to HTTP/2.0.


また、 HTTP2-00 が公開された日にも ML で以下のように強調されています。

http://lists.w3.org/Archives/Public/ietf-http-wg/2012OctDec/0447.html

This draft is (obviously, I'd hope) NOT for implementation.
When we get to a point where we've addressed some issues and evolved the protocol sufficiently,
we'll mark a draft for test implementation;
I'm hoping this will happen very early next year, and we'll iterate as necessary after that.

So, please have a look and start thinking about what needs to change.


要するに、 SPDY はあくまでも議論のたたき台(呼び水) であり、ゼロから議論を開始するより既存の仕様をもとにしたほうが良いだろうという目的です。


ここから、様々な議論をもとに diff を積んでいくことになりますが、それでも多重化や圧縮などの仕様は入るだろうし、
バイナリフレームなのも避けられないだろうから、そこをベースにできるものがある方が議論が捗るだろうというのが採用の大きな理由と言えます。
また、既存の実装があると試せる(ベンチがとれる)というのも大きいでしょう(S+M はそこが弱かった)。

大きめな問題

こうして、SPDY が土台となったわけですが、もうすでに issue となっている点がいくつかあります。
現在 HTTP2.0 を策定するにあたって、議論の対象となっている幾つかの問題について紹介します。

Upgrade

HTTP2.0 のプロトコルをどうやって使うのか、といった問題です。
この議論の前提には 「HTTP2.0 も 80/443 ポートで使いたいよね」という要望が透けて見えており、
実際 80/443 を基本(capability but not the requirement) として話が進んでいます。


SPDY では、 TLS が事実上の前提となっているため、 NPN(Next Protocol Negotiation) を使って SPDY に移行し、
もし SPDY がアクセプトされたなかった場合は、 HTTPS で接続するという方法が取られています。


これでは HTTP2.0 を事実上 TLS 前提のプロトコルとしなくてはなりません。
しかし、 HTTPbis では「HTTP2.0 が TLS でしか動かないという仕様は避けるべき」という流れもあり、
TLS でない場合は HTTP1.1 の 101 Switching Protocols を用いて upgrade する方法が提案されています。

draft-lear-httpbis-svcinfo-rr-00 - A DNS Resource Record for Service Descriptions

この方法は WebSocket でも採用されており、互換性の観点から移行しやすいのが特徴です。


upgrade などを用いる方法は、要するに一度サーバに問い合わせてから、その後の通信方法を決めるわけですが、
もし、クライアントがサーバの対応するプロトコルを「事前に」知ることができれば、
最初から HTTP2.0 などを用いた接続をすることができます。
この観点から、 DNS の srv レコードなどを用い、名前解決時に解決先のサーバの情報(対応するプロトコルなど)を送るという方法も提案されています。

draft-lear-httpbis-svcinfo-rr-00 - A DNS Resource Record for Service Descriptions


新しいプロトコルを策定する際に、一番大きな問題になるところなので、先の IETF 85 のミーティングでも議論が盛り上がったようです。
minutes を見ると、 DNS から着手する感じなんでしょうか？ DNS 詳しくないので、勉強が必要です。。

http://www.ietf.org/proceedings/85/minutes/minutes-85-httpbis:minutes-85-httpbis

TLS

TLS の扱い(必須とするかどうかなど)という点も、重要な論点となっています。
これは、前節でも触れたように NPN を使ってプロトコルを変更する場合は TLS が必至となりますが、
それ以外にも「TLS を必須にしたほうがいい」と「そもそも TLS を必須にするのはいかがなものか」という
二つの議論があるようです。


もちろんセキュリティ面から TLS を必須にするというのもありますが、
暗号化してしまえば、パケットの中身は基本的にエンド同士しか見れなくなるわけなので、
intermediaries (中間サーバ e.g. proxy) などを通しやすくなるというメリットもあります。
一方で、 Web において TLS を必須にするということ自体が、
様々な点で自由度を下げるという意見もあります。


また、 NPN もまだドラフトの段階であるため TLS の WG とも調整が必要といった、
影響範囲の問題なども出てきているようです。

Compression

CRIME の登場で一時荒れた圧縮関連ですが、概ねヘッダ圧縮は必要という論調です。
SPDY のドラフトを書いた Mike Belshe は、 S+M のドラフトがヘッダ圧縮をオプションにしたことに対して以下のように言っています。


http://www.belshe.com/2012/03/29/comments-on-microsofts-spdy-proposal/

Lastly, I’m puzzled as to why anyone would propose removing the header compression.
We could argue about which compression algorithm is best,
but it has been pretty non-controversial that we need to start compressing headers with HTTP.
(See also: SPDY spec, Mozilla example, UofDelaware research)

要するに、「ヘッダ圧縮を仕様から外したがる理由がわからない。そこの議論より、早くどの圧縮アルゴリズムがベストかを議論したい。」という感じ。

コメント欄では、デバッグ目的で圧縮をオプションにするのは良いかもといいつつも、基本は前提で考えているようです。


そもそもの目的に HTTP の高速化がある以上、バイナリベースのプロトコルで圧縮を必須にするといった仕様は、入ってくるんじゃないかと思います。


WebSocket は、圧縮の仕様を WebScoket Extension (拡張) の仕様として策定中で、 Deflate を基本としています。
HTTP2.0 においても、圧縮を前提にする合意が取れると、 CRIME の件も含めてどの圧縮アルゴリズムを使うのかの議論が始まるのではないかと思います。

その他

issue で上がってるものとしては、

  • Server Push
  • Flow Controll
  • prioritisation

など、 SPDY が定義していた機能が上がっています。
特にこの辺は割りとエッジが効いた機能なので、色々な意見があがりそうです。

情報

issue

HTTP2 Tickets – httpbis


チケットはこちらで管理されています。
もし、 「HTTP について一言ある」といった方は、こちらから登録されると良いかと思います。

HTTP2.0 twitter acount

https://twitter.com/http_2


まだ少ないですが、最新情報を呟いてくれるそうです。

HTTP2 Github Account

https://github.com/http2


検証コードやサンプル実装が上がるようです。

ミーティング

http://trac.tools.ietf.org/wg/httpbis/trac/wiki/F2F/Jan13


なんと、この HTTP2.0 の issue を徹底的に話し合う場として、
HTTPbis のミーティングが開催されることになりました。


期間は、 2013/1/30 から 2/1 まで。
場所はなんと日本！！ 、東京六本木の Google 本社で行われるようです。


参加に特に条件は書かれてないけど、 IETF の ML くらいは参加してれば、
基本は誰でもいけるのかな。。
しかし、行きたい人は直接 Chair にメールをするというハードルの高さ。。
そして「ど平日」。

うーん行ってみたい。。

まとめ

まだまだ、本当に始まったばかりの仕様ですが、これは「次期標準仕様」のためのドラフトです。
つまり、我々が普段当たり前のように使っている Web を、根っこで支えている HTTP に
まさしくメスが入ろうとしています。


Web に対する大きな変化はこれまでにも色々あったと思います (CGi, Ajax, HTML5 etc)。
しかし、HTTP 自体がここまで大きく変わるのは、それらと比較してもやはりインパクトのある変化といえるでしょう。
この影響範囲の大きさは、このブログを読みに来た方ならお分かりかと思いますが、
特に技術者サイドから見ると、大きな影響のある変化になりえます。


今回提出されたドラフトが、来年どうなっていくのか、注目してみたいと思います。

注意

なるべく出展を明示していますが、それ以外は自分自身の意見や、自分自身が感じてる議論の雰囲気をもとに書いています。
また、ここに書かれていることの賞味期限はとても短いと思います。ご注意下さい。


また、例によってもし間違っている点などあったら教えて頂けると幸いです。

東京 Node 学園祭 2012

node.js nodefest

intro

去年に引き続き 東京Node学園祭2012を開催しました。
今年も、スタッフとして参加させて頂きました。


今年は去年より規模を大きくし、海外のゲストも 4 人呼ぶことができました。
個人的には孤高のハッカー substack と行動したのが思い出深いですw


一緒に運営をしたスタッフの皆さん、出て頂いたスピーカーのみなさん、
法政大学さん、スポンサーの皆さん、
ワールドツアーで忙しい中日本に来てくれた izs, mikeal, charlie, substack
みなさんありがとうございました！

omake

substack に「学園祭のロゴ書いてよ」っていったら、おもむろに書き始めた図。
(途中で料理が来てしまったので中断。完成版を送ってくれると良いなぁ。)

substack drawing from Jxck on Vimeo.

Engine.IO からみる Socket.IO の今後

engine.io socket.io

intro

この記事は 東京Node学園祭2012 アドベントカレンダー : ATND の 24 日目の記事です。


Socket.IO の 1.0 が、出る出るといって全然出ないので、
やきもきしている方も多いと思います。


しかし、その裏では Engin.IO という、割りと良い感じの
ファミリープロジェクトができていて、
ちょうど先日 RealtimeConf でもその話がありました。


これは Socket.IO にも繋がるはなしなので、
今日はその Engine.IO の話をします。


参考はこのへん、

Engine.IO と Socket.IO (と WebSocket.IO)

Socket.IO は、 1.0 を視野に入れたあたりで、
関連プロジェクトとして、 Engine.IO と WebSocket.IO の
二つのプロダクトを新たに立ち上げました。
(この辺は Web+DB Press でも触れました。)


この二つは、開発が進んで多くの機能を単一のプロダクトに内包していた Socket.IO を、
より小さなモジュールに別けて、保守性・再利用性を高めるといったことを目的としています。
最終的には以下のような依存関係になります。

Socket.IO
    |
Engine.IO
    |
WebSocket.IO
    |
  (ws)


具体的な役割は次に説明します。

WebSocket.IO

過去にあった WebSocket プロトコルの仕様変更と、それがもたらしたブラウザの実装差異を吸収することを目的とした、
WebSocket のラッパモジュールです。(実際はそのほとんどを ws というモジュールがやっています。)


これで立てた WebSocket サーバは、どんなバージョンの WebSocket を実装していても、
同じインタフェースでやり取りできます。


対応プロトコルなど、詳細は以下を参照ください。

LearnBoost/websocket.io · GitHub

Engine.IO

WebSocket を実装しないブラウザに対して、 Flash Socket や Long Pooling へのフォールバックを提供します。
WebSocket の通信には WebSocket.IO を使っています。

だったんですが、今はここが少し変わっています。その話は後ほど。

詳細は以下。

LearnBoost/engine.io · GitHub

Socket.IO

Engine.IO をベースにし、その上に namespace や authentication, custom events などの高レベル API を提供します。
しかし、この構成は Socket.IO@1.0 からで、 0.9 ではまだ Socket.IO は Engine.IO に依存しておらず、
従来通り自前でトランスポートを実装しています。


最近、更新があまりないのは、 Socket.IO を 1.0 にするために、
Engine.IO と WebSocket.IO の安定が欠かせないからです。
WebSocket.IO は割りと落ち着いて、現在は Engine.IO の実装を進めています。


しかし、 Engine.IO にも Socket.IO@1.0 タグがついた issue がちらほら残っているので、
まだちょっとかかるかなとは思っています。


LearnBoost/socket.io · GitHub


フォールバックとアップグレード

(何回か書いた気がしますが)
Socket.IO では、これまで接続の確立に WebSocket をまず試し、
ブラウザや中間サーバなどの影響でダメだった場合のみ、
XHR や Flash にフォールバックする方式をとっていました。


しかし、この方法ではフォールバックが重なってしまった時、
実際に通信可能な接続が確立するまで、結構な時間がかかっしまう場合がありました。


問題は、ブラウザの実装というよりは Intermediaries (Proxy, Personal Wirewall etc)が多いことがわかっています。
Personal Firewall に関する Socket.IO のチームの調査は、 wiki にまとまっています。
そこで Engine.IO では、まず最初に最も安定して接続を確立できる XHR LongPooling による
接続を確立し、その後によりよい通信方法(FlashSocket, WebSocket)を試して、可能だったらそちらに
アップグレードするという方法をとることになりました。
(だから、このコンテキストの Upgrade は HTTP1.1 の Upgrade とは意味が違うので注意)


Socket.IO が Engine.IO に依存することになれば、 Socket.IO の挙動もそうなることになります。
これでイニシャルの接続速度の向上が見込まれます。

MetaEvent

いくつかのイベントが API として公開されることになりました。
現時点では以下の二つが予定されています。
(といっても、発表聞いて自分が実装したんですが。)

socket.on('packet', callback); // すべての packet (ping, message, close etc) を受信
socket.on('packetCreate', callback); // すべての送信


これで、より細かな内部状態を取得できます。
ロギングや可視化、フックなどがしやすくなるでしょう。

Visualization

Guillermo 達はリアルタイム Web の開発場面において、圧倒的に足りてないのが、
「内部の状態の可視化(Visualization)」だと考えています。

  • コネクションの数
  • その中の WebSocket 接続の数
  • 発生した送受信の数
  • レイテシ
  • どのトランスポートを使ってるか
  • etc


そこで彼らは、それを解決するために engine.io-monitor というプロジェクトの立ち上げを
考えているようです。


今はレイティを見るサンプルが engine.io の example に入っています。
engine.io/examples/latency at master · LearnBoost/engine.io · GitHub


中で何が起こっているのかをきちんと把握することはとても大事ですね。
Engine.IO のレイヤで見られれば、 Socket.IO の開発でも使えるはずなので、
この辺は、期待したいところです。が、ほんとまだサンプルしか無いので、どうなるのかなぁ。。

debug

ちょっとずれますが、Socket.IO ファミリーでは TJ の debug というモジュールを採用しています。


https://github.com/visionmedia/debug


これは、Node.js の起動オプション、環境変数、npm start の話 - Block Rockin’ Codes でも紹介した
環境変数を使ったデバッグ出力の応用です。


Node 本体には NODE_DEBUG で指定すると表示されるデバッグ出力が仕込まれています。

$ NODE_DEBUG=http,net index.js

これは基本標準モジュールのものですが、この方法に則って自分のモジュールに
デバッグを仕込むモジュールが debug です。

var debug = require('debug')('fuga')
   , http = require('http')

   debug('start');

   http.createServer(function(req, res){
       debug(req.method + ' ' + req.url);
         res.end('hello\n');
   }).listen(3000, function(){
       debug('listening');
   });


このように、 require 時に ('http') と、このモジュールの名前空間を指定し、
debug() に出力したいログを仕込むと

$ DEBUG=fuga node index.js

などとした時に、仕込まれたデバッグを出力できます。
fuga を * にすれば、全てのモジュールのデバッグが出ます。


Socket.IO ファミリーはこれを使って、接続の確立やメッセージ通信などの
情報を出せるようにしてるので、開発時に DEBUG=engine.io などとすれば、
色々見えるようになって便利です。


また、 debug には掛かった時間を出したり、browserify を使ってブラウザで使う(出力先は localstrage)
もできるようなので、クライアントのデバッグも捗りそうです。

まとめ

ということで、 Socket.IO の更新頻度は下がっているし、
1.0 が出る出るといっておきながらなかなか出ないで、やきもきしてる方も多いと思いますが、
裏では engine.io、 websocket.io が進んでいるので、そちらも合わせて見てみると、
今後の動向が分かりそうということでした。


ちなみに、 http://realtimeconf.com/ は他にも色々おもしろいセッションがあったし、
録画もあるようなので、興味のある方は見てみると面白いかと思います。

サーバサイドJavaScript Node.js入門 を執筆させて頂きました。

node.js book

intro

本当にお待たせいたしました。


出す出すといってなかなか出せなかった Node.js 本が、ついに出版されました。
共著の一人として、自分も書かせていただいています。


http://pbs.twimg.com/media/A6Q2xmrCAAEsFxi.jpg


サーバサイドJavaScript Node.js入門

サーバサイドJavaScript Node.js入門


これを書いてる時点では、 JavaScript 部門では 1 位、 プログラミング部門では 4 位 となっているようです。
それなりに、興味を持っていただけているようで良かったです。


自分の記録としても、少しだけ書かせて頂きます。

2 年間の執筆

書き始めたのは、かれこれ 2 年前になります。
その頃はまだ node.js@0.2 とかでした。(今は 0.9, もうすぐ 1.0)


本当は年が明けた春(2011/4 とか)に出そうって話で書き始めたんですが、
実際はそうはいかなかったです。


一番の理由は、僕らが書くと同時に Node とその周辺自体がどんどん新しくなることです。
書いてるそばから内容がどんどん古くなる。これは結構書いてて辛かったです。


なるべく使える情報を届けたいけど、一方で書きなおしを続けててもエンドレスになってしまうということで、
何度も話し合いながら、ここだけは対応したい、というところを直しながら走り続けてきました。


自分が担当した章では、書き始めから(ブランチ数で)約 20 回くらい書きなおした章もあります。


もしただ単純に執筆をサボってて遅れてただけなら、きっとこの本の話自体が消えていたでしょう。
むしろ、この本の企画をゴールまで守って頂いた嘉平さんには、本当に感謝します。


Node@1.0 のリリースとか、学祭の直前云々のタイミングに合わせず、今このタイミングで出版したのも、
今ちょうど、少しでも早く出すための色々な条件が重なったからです。
もしこのタイミングを逃してたら、今頃まだ書き直しを繰り返して、どの段階で出すべきか議論してたかなと思います。


とはいえ、読者の方からすれば中々出なかったという事実だけなので、
そんなのは関係ないですね。その点に関しては本当に申し訳なかったと思っています。

書き直し

ちなみに自分が覚えている、「これは書き直し、書き足しが必要かな。。」ということになった、
大きい変更はざっとこんなのがあったなと思い出します。

  • npm が標準になる
  • windows 対応が始まる
  • libuv が出てくる
  • Cluster が標準になる TJ の Cluster がオワコンになる。
  • Isolate が出そうで無くなる
  • Express が 2.0 になり、色々変わる。
  • Express に routes ディレクトリができる。
  • Expresso がオワコンになり、 mocha + chai になる。
  • Socket.IO に色々機能が増える
  • Domain が入る
  • etc, etc, etc....


思い出すだけでも目から汗が。。

API より考え方

最初の頃は、色々な場面で API について書きすぎたのが間違いだったなと途中で気づきました。
あと、やっぱみんなそれぞれ詳しいモジュールとかあるし、ソースとかも読んでから書いてるので、
ドキュメントに載ってない API についてとか、マイナーな設定方法とか書いてしまっていました。


でも、 API は変わるんですよね。しかも最初の段階は割りと早く。


それがバージョンに追従するための書き直しに大きく響いていたし、
それは同時に内容の寿命を縮めていることに気づきました。


だから、途中からもっと「考え方」にフォーカスして書きなおすようにしてます。


もちろん、モジュールを使ってる章は API について(ときには本家のドキュメントより)詳細な解説をしているんですが、
なるべく「そのモジュールのバージョンが上がっても、変わらないだろう "考え方"」を書くようにしました。


どっちにせよ、この本が出たあとも、ものすごい速さで Node は進んでいくと思いますが、
その流れに乗るために必要なものを、この本から得て頂ければいいなと思っています。


ちなみに、manning のように、電子書籍でアップデートしながら走るという方法については、本当に多くの方に言われます。
実際自分たちも最初の段階から話はしました。ここには書けないですが、それはそんな単純でもないかなと未だに思います。

写経

この本の特に「実践編」は写経されることを意識して Diff で書いています。
この本を読むほとんどの方には、その方がわかりやすいでしょう。
ちょっと慣れが必要かもしれませんが、慣れれば開発の過程を追体験しながら、
写経することができます。


使用する Node と基本全てのモジュールはバージョンが明示されているので、
モジュールがどんどん新しくなっても、
同じバージョンを指定して npm でインストールすれば、同じように動くはずです。


最終形態とその他のリソースは、出版社のサイトから落とせるようになるので、
そちらも合わせて参考にしてみて下さい。

おわりに

今のところ、世界でも珍しいくらい Node についてガッツリ書いてあります。
海外でこの話をすると、みんなに「英訳は出ないのか？」と言われるとか。


必要なことは大体書いてあるはずなので、
これを期に、 Node に少しでも興味を持って頂けるといいなと思います。


書ききれないこと色々あるけど、この辺にしておきます。


最後に、
一緒に執筆させていただいた著者の皆さん
レビューしていただいた皆さん
担当いただいた嘉平さん


本当にありがとうございました。


see also: http://meso.hatenablog.com/entry/2012/10/26/111330