DE0でMIDIをデコードしてみた。

前回のDE0で正弦波を出してみた。の続き。音は鳴ったものの、440Hzしか出ない。つまらない。しょぼい正弦波のみの音源ではあるが、やっぱりキーボードで鳴らしてみたいなぁ。。その野望を叶えるためには、まずMIDIでつなげるようにせねば。

DE0にMIDIをつなぐ

もちろんDE0にはMIDIインタフェースなどないので、どうやってつなぐか考えた。USB経由の方向はプロトコルとか面倒そうな気がしたので調べてない。RS-232Cが付いてるので、MIDIから232Cへのコンバーターかなぁ、、いやしかし、MIDI信号について調べてみると、フォトカプラを入れるだけで割と簡単に信号読めそうだな、、パーツ屋でフォトカプラ買ってくればいいのかな？いや、フォトカプラやコネクタ等ひととおりボードに載ってるArduino用のMIDIインタフェースがあるな！これ流用しよう。

ということで届いた。それっぽい端子をテスターで探して、MIDIキーボードとDE0につないで内蔵ロジアナで波形を観測する。おぉ、意外にあっさり波形がとれたぞ。

MIDIは非同期シリアルだった

つづいては、この0と1の羅列からなんとかして「どの鍵盤を押したか」って情報を取り出すためのHDLコードを書かねばならない。まず俺はMIDIがどんなプロトコルなのかを知らない。なんだかやけに遅いシリアルって印象。。いろいろググったら、このサイトの図がとってもわかりやすかった。

自作midiデバイス1 : 自作電子楽器ノブログ via kwout

MIDIはUARTっていうRS-232cと同じ非同期シリアルのプロトコルを採用していて（しかし信号電圧等は232cとは異なる）、ボーレートは31.25Kbpsで固定。鍵盤を押すと、8ビットのデータが3つから成る「MIDIメッセージ」が鍵盤側で作られて、各8ビットの前後にスタートビットとストップビットをつけた10ビット×3つがずらずら送られてくる。受け取り側は、そこから3バイトのMIDIメッセージを取り出せばよい。

ということで、HDLで非同期シリアル信号をデコードするコードを作成すればよい。Verilog HDLで書かれた既存のUARTライブラリも見つけたけど、そのまま使っては練習にならないので、自分で書くことにした。

非同期シリアルの読み方

非同期シリアルという名前が示す通り、同期用のクロック信号がない。ではどういうタイミングで信号を読めばいいのか。ネット上で見つけたいくつかの説明のなかでは、ここが参考になった。

FPGAの部屋 シリアルインターフェース（RS-232C)の説明 via kwout

つまり、31.25Kbpsより数倍速いクロックで信号を常時チェックしながら、スタートビットがはじまったな？と検知したら、31.25Kbps＝32μs間隔で8ビットのデータを読んでいく。結構単純な方法でいいらしい。そこでこんなコードを書いてみた。

// decoding MIDI_IN
reg [5:0] dec_cnt;
reg [7:0] dec_reg;
always @(posedge CLK) begin
	if (sp_clk) begin
		case (dec_cnt)
			0, 1, 2: // wait for a start bit
				if (MIDI_IN) begin
					dec_cnt = 0;
					dec_reg = 0;
				end else
					dec_cnt = dec_cnt + 1;
			6, 10, 14, 18, 22, 26, 30, 34: // sampling data bits
				begin
					dec_reg = {MIDI_IN, dec_reg[7:1]}; // right shift
					dec_cnt = dec_cnt + 1;
				end
			38: // stop bit
					dec_cnt = 0;
			default:
				dec_cnt = dec_cnt + 1;
		endcase
	end
end
wire dec_done; // decoding a byte finished
assign dec_done = sp_clk & dec_cnt == 36;

ここでsp_clkっていうのは31.25Kbps x 4倍のクロック。そのタイミングでMIDI_IN（MIDIの入力波形）をチェックする。dec_cntっていうカウンタを用意して、スタートビットからストップビットまでの10ビット分流れてくる間に0〜38まで数える。0〜2のタイミングでスタートビットを検出したら、6、10、14、18...といった具合に4つ増えるごとにデータビットを読み取って、シフトレジスタdec_regに詰めていく。36に来たら8ビットのデータが溜まっているので、dec_doneフラグを立てる。これで1バイト分を読み取りできたことになる。

さらに、MIDIメッセージの3バイト分を貯めるレジスタを用意して、dec_doneフラグが立つたびに1バイトずつ入れてくコードを書いた。キーボードを叩いてはロジアナで波形を観測しながら繰り返しデバッグすることしばし。。。ついに「90h xxh xxh」っていう3バイトのMIDIメッセージ取れた！わーい！

ロジアナで動きを見るとこんな感じ：

ノートナンバーをLEDで表示してみる

しかし音を出すにはまだまだやることがある。3バイトの中身は「ステータスバイト」「データバイト1」「データバイト2」って分かれてて、例えば「90h 3Ch 40h」なら「ノートオン（打鍵）」「真ん中のC」「強弱は中くらい」っていう意味になる。これを解釈して出力する周波数に変換しなければならない。ちょっと今日中にはムリなので、次回やることにした。

MIDIメッセージ一覧 via kwout

とりあえずは、取れたノートナンバーをLEDに表示してみた。こんな感じ：

ちょっとみづらいけど、Cを押したら30hといった具合にノートナンバーが表示された。いぇ〜い！

次の野望：次こそいよいよキーボードで正弦波を鳴らしてみたいっ。

今回書いたソースコードはここに置いておいた。

Zynqサーバーの使われ方を妄想してみるスレ

（アカデミアの状況とか追ってないし専門外なので、もしかしてかなり既知／的外れなこと書いてる可能性あり）

15年くらい前にIP Switchって製品が登場して画期的だった。これってZynqサーバー（Xilinx Zynqを搭載したサーバー機器。そんなものが実際にあるのか俺は知らないがいずれ出てくるだろう）におけるARMとFPGAの使い分け方法を示唆してるのではないかなという思いつきをメモっておく。

IPスイッチ＝Linux IPルータ＋ATMスイッチ

当時、IPルータやATMスイッチはあったけど、IPスイッチはなかった。IPルーティングにはBGPやらOSPFやら複雑なアルゴリズム使った経路制御が必要でCPU処理が不可欠。CPU使わずハードだけでスイッチングは難しかった。するとどうしてもCPUがボトルネックになる。

そこで、53バイトの固定長セルを定義し、そのヘッダのアドレスを見てCPUなし（＝布線論理のみで）でスイッチングすることを想定したプロトコル、ATMが登場した。ATMスイッチはIPルータより速かったけれど、結局はインターネットの隆盛に負けて、コンピューター間の通信プロトコルとしてATMがIPを置き換えることはなかった。

でもATMはしばらくプロバイダのバックボーン構築に使われてた。IPスイッチが登場したからだ。IPスイッチは文字通り、ATMスイッチの速さでIPをルーティングできる機械。中身はLinuxベース（いや正確にはIpsilonの中身はBSDだったかな）のIPルーティング制御箱とATMスイッチ。Linuxの方で経路制御したら、その経路をATMスイッチに設定する。あとはLinuxを介さずめっちゃ高速にIPスイッチングできるという仕組み。後にMPLSとして標準化された。

ポイントは、「めんどくさい処理はCPUで、簡単なストリーム処理はハードウェアで」という使い分け。これはZynqサーバーの使い方を考える上で面白い。

アプリごとに俺様SIMDを定義したい

いまのWebアプリやビッグデータの処理はほとんどがCPUによって実装されてて、まさにIPルータ時代。すべてのデータを一度CPUに持ってこないとなんにも処理できない、典型的なフォン・ノイマン・ボトルネック。でも、よく考えると、例えばSSLの暗号化とか、ロードバランサーとか、ファイアウォールでのウィルスチェックとか、RAID5コントローラーとか、CRCでデータ保護とか、簡単なところから脱CPU化は始まっている。

ZynqのようなARM＋FPGAなヘテロコアを搭載したサーバーが一般化すれば、もっともっといろいろなアプリケーション特化した処理がハードウェア実装に移行できるはず。例えばTBクラスのデータに対してパターンマッチング／ソート／マージとか、大容量のストリームデータをフィルタしたりcontinuous query適用したりウィンドウ処理したりとか、そういう比較的単純な処理までいちいちディスク→メモリ→キャッシュ→レジスタって持ってきて64ビット単位でちまちま加工する必要はないのでは。Supersonicみたいに、既存CPUのSIMDを活用してデータ処理を高速化しようって動きもある。GPGPUでも何かできるかもしれない。でも、もしサーバーにFPGAがついていれば、例えば1024とか4096ビット、いやもっとデカい単位でデータをDMAしながらCPU介さずにストリーム処理する俺様SIMD命令を、アプリごとに定義して使うことだってできそうだ。できたらいいな。

FPGAでストリーム処理っていうのは、アカデミアや金融分野では結構前から研究されてる。特に金融はHFTっていうハードリアルタイム要件があるためFPGAでないと追いつかないみたい。

Webアプリやビッグデータも「CPUが必要な処理」と「ハードでできる処理」に分けてみよう

金融でのFPGAみたいなのは特殊用途だけど、Zynqサーバーが普及することで、もっと一般的なWebアプリやビッグデータの世界にもこの波がくるんじゃないかなぁ。。来てほしいなぁ（面白いから）。。そこで思い出すのが、IPスイッチにおけるCPUとハードの役割分担。HTTPリクエストを解釈したりユーザー認証したりトランザクショナルにデータベースレコードを書き換えたり、、っていったOLTPな処理はCPU任せでいいと思う。一方で、上述した比較的単純なストリーム処理は、CPUからFPGAに指令を出してオフロードする。CPUは太いデータの通り道を構成して展開する役割に専念する。すると、「CPUによるOLTP処理」と「FPGAによるストリーム処理」を組み合わせたWebアプリ設計技法ってのが生まれるんじゃないか、そんな時代にはFPGAプログラマ（まぁHDL直接書くっていうより高位合成主体だろうけど）がモテるんじゃないか。。

ってところで目が覚めた。

あまりパッとしたDremelクローンが出てこないので俺が考えた

ディスクI/Oの並列度が1000超えてないDremelクローンって…

Apache DrillやCloudera ImpalaといったDremelインスパイア系のリアルタイム低遅延でカラム型なデータストア的何かがいくつか出てきて、最初はちょっと身構えた（Amazon RedshiftはRDBクラスタって感じでDremel系とは違うかも）。Dremelの立場危うし！ しかし、よくよく話を聞いてみるとどれも並列度が数十って規模らしく、ちょっとガッカリ＋安心した次第。オープンソースでDremel的なものを作るなら、俺ならこうするぜ！ってアイディアを今朝思いついたので、自分で実装する気はないけど書き残しておきたい。

ビッグデータの最大のボトルネックはディスクドライブ

先日公開されたBigQueryのホワイトペーパー、英語だし基本はDremelペーパーを読みやすくした程度の内容なのであまりまじめに読んでる人はいないと思うのでポイントをかいつまむと：

• 世の中のビッグデータ処理にはおおざっぱにOLTP系、バッチ系、OLAP系の3種類の要件がある。前者2つはBigtableクローン（Cassandra等）やMapReduceクローン（Hadoop）が普及しつつあるけど、OLAP系に対応するDremelクローンってのはあまりない（最近いろいろ出てきた）。実業務ではこのOLAP系が速いとめっちゃ便利なのに…
• OLAP系につかう既存のデータウェアハウス製品とかアプライアンス製品では事前設計したインデックスやディメンジョンから外れるクエリはほとんど実用にならない。でもOLAPって基本、エラい人の気まぐれな疑問に答えるためのad hocなクエリとか、予期せぬトラブルにサクッと対応するための柔軟なドリルダウン作業がキモ
• となると、結局はインデックスなしのフルスキャン／テーブルスキャン性能をどれだけ速くできるかが重要。ディスク上の1TBのデータを1秒でフルスキャンするには、1万台のディスクを物理的に並べる必要がある。そこでこれまでは、ディスクを使うのあきらめて、データベースアプライアンス製品等にものすごくお金かけてメモリやSSD大量に積んで解決するしかなかった。
• でもクラウド上には何千・何万ってサーバーとディスクがすでにあるのだから、そこにデータをバラけさせてフルスキャンしてみればいいのでは？＞これがDremel

つまり、ビッグデータな今の時代なのに、あいかわらずそのデータをディスクドライブという、すべてのデータをシーケンシャルに読み出していちいちCPUまで持ってこないと何にも処理できないデバイスに貯めこんでるのが最大のボトルネックになってる。これが例えば、ARMチップとSSDがくっついてSQLを直接解釈するようなスマートなストレージ等を大規模並列に並べたりすると世界が変わるはずだが、そういうのが価格容量比的にペイするようになって普及するのはもうちょっと先になる。なのでとりあえずは現状のディスクをどれだけたくさん並列に動作させられるかがポイントだ。

しかし冒頭の書いたように、最近出てきたDremelインスパイア系はどれも数十台規模の並列度な様子。まぁDremelとはそもそも違う用途を想定してる面もあると思うけど、OLAP系のフルスキャン用途については、Dremelのパフォーマンスには何ケタも劣ってしまうはずだ。

自分のデータを自分のディスクに入れてるから遅い

Dremelみたいにサクッと数万ノード上に展開できるような環境がDremel以外にはないからしょうがない…のだけど、でもよく考えたら、大きなデータセンターではディスクは何千、何万って数で動いている。物理的には大規模並列ディスクI/Oのための環境は整っている。問題は、それらのディスクの持ち主が自分のデータを入れるためだけに使ってるってことだ。もしデータセンター上のディスクを利用者全員で共有できるって運用にすれば、ビッグデータの最大のボトルネックを解消できるはずだ。例えば1000万件のデータを保存したかったら、それを1000台のディスクに1万件ずつ分散保存する。それだけで、フルスキャン性能は1000倍にはね上がる。

中央集権的な分散系の構築・運用はきびしいから、ふるゆわP2P系で

もちろん、信頼性の高い分散系を誰が構築・運用するのか、セキュリティの確保、リソース配分で割食わない方法…等々の現実的問題はいろいろ立ちはだかるだろうけど、逆に言えばそれらの問題を解決したオープンソース実装やデータセンター事業者が現れれば、Dremelに十分対抗できる存在になるかも。しかしDremelやHadoopのような中央集権的な設計で分散系構築＆運用はヘビー過ぎるので、BitTorrentみたいなP2P系・冗長性の高い・運用とかゆるふわにできるアーキテクチャやノリなら、最初小さく次第に拡大する自然発生コミュニティ的にディスク共有仲間が増えるような気がしないでもない…と思った。誰かやってください。

DE0で正弦波を出してみた。

前回のDE0で音を出してみた。のつづき。前回は0と1を440Hzで繰り返すことで矩形波を鳴らしたけど、今度は正弦波を出してみる。となると、スピーカーに単純に0Vか5Vかを送るんじゃなく、0〜5Vのアナログ信号で波形を作る必要がある。つまりDAコンバーター（DAC）が要る。

DAコンバーターとたたかう

こないだ買ったDE0拡張キットにはMCP4922っていうDACのICが入ってたので、まずはこれをブレッドボードに載せて、DE0の外部インターフェースやスピーカーとつなぐ配線をする。ブレッドボードって使うのは実は初めて（俺の子供の頃はこんなのなかった気がする。電子工作と言えばラグ板かエッチングだった）。

このMCP4922は12ビットのDACなので、12ビットのデータを入れると0〜5Vのアナログ信号に変換してくれる。がしかし、12ビットのデータをSPIっていうシリアルインタフェースを通じて渡さねばならない。SPIってなんぞ。。ググったら出てきたこのページの真ん中あたりの解説を読んだり、DE0拡張キットのマニュアルを読んだりして理解を試みる。12ビットのデータの頭に4ビットのヘッダ情報をつけて、合計16ビットのデータを1ビットずつ順番に入れてあげると、それに応じたアナログ信号を出力してくれる…って仕様らしい。見よう見まねでHDLのコードを書いて動かしてみるけど、最初は当然動かない。なのでロジアナとにらめっこしながらデバッグ作業。。結局はこんなコードになった。

module SPI (
	input ICLK,
	input [7:0] DAT,
	output nCS,
	output SDI
);

	// base 18 counter
	reg [4:0] cnt;
	always @(posedge ICLK) begin
		if (cnt == 5'd17)
			cnt = 0;
		else
			cnt = cnt + 1;
	end

	// CS
	reg cs;
	always @(negedge ICLK) begin
		if (cnt == 5'd17)
			cs = 1'b1;
		if (cnt == 5'd15)
			cs = 1'b0;			
	end
	assign nCS = ~cs;

まずはクロックを18回数えるカウンタをつくる。カウンタが0〜15のときはSPIでデータを1ビットずつ送り、16・17のときはCS#（データを送ってることをDACに伝える信号）を介して「データ送ったよ」と教える。そのタイミングでDACがデータの数値に応じた電圧でアナログ信号を出力してくれる。データの中身としては、とりあえず簡単な矩形波を出してみるために、440Hzで0xFFと0x00を出力する簡単なカウンタをつなげておいた。

このデータを1ビットずつ送るために、16ビットのシフトレジスタを用意する。

	// 16 bit shift register
	reg [15:0] sreg;
	always @(negedge ICLK) begin
		if (cnt == 5'd17) begin
			// load command and data into sreg
			sreg = {4'b1111, DAT, 4'b0000};
		end
		else begin
			// shift
			sreg = {sreg[14:0], 1'b0};
		end
	end
	
	// SDI
	assign SDI = sreg[15];

endmodule

カウンタが0に戻るタイミングで、コマンド4bit＋データ8bit＋パディング4bitの合計16ビットをレジスタsregにロードする。あとは、sreg = {sreg[14:0], 1'b0};って書けば1回ごとにレジスタ内容が左にシフトするので、sreg[15]（一番左のビット）の値をDACに送る。

このやり方は理解できるのだけど、デバッグが難しかった。。DE0に内蔵のロジアナとにらめっこすることしばし。しかしこのロジアナはFPGAの中のレジスタの値しか見られない。DACまわりの信号がどんなことになってるか調べるために本物のロジアナがほしいなぁ〜とつくづく思った。しょうがないので年季の入った俺のテスターを引っ張りだしてきて、DACの足の電圧をひとつひとつ確かめる。例えばクロックのところが2.5Vくらいなら、まぁそんなもんだろう。。とか。信号の確認とデバッグを地道に進めていって、やっと音が出た。嬉しい。。しかしハード開発は難しいなぁ。。仕事でなくてよかった。

サインテーブルを作る

あとは正弦波のデータをDACの送るだけ。Google Spreadsheet（Excelなぞ使わない）でこんなテーブルを作る：

そして、440Hz / 128の間隔で0〜127の値を出力するカウンタを使い、このテーブルから値を読み出すコードを書く。

	// clock for each step
	// 50Mhz / 440Hz / 128 = 887.78 
	reg [11:0] cnt;
	wire stepclk;
	always @(posedge CLK) begin
		if (cnt == 12'd888) 
			cnt = 0;
		else 
			cnt = cnt + 1;
	end
	assign stepclk = cnt == 0;
	
	// counter for each step
	reg [6:0] stepcnt;
	always @(posedge stepclk) begin
		if (stepcnt == 7'd127)
			stepcnt = 0;
		else
			stepcnt = stepcnt + 1;
	end
	assign DAT = sin(stepcnt);

	// sin table
	function [7:0] sin;
		input [7:0] step;
		begin
			case (step)
				8'd0: sin=8'd128;
				8'd1: sin=8'd134;
				8'd2: sin=8'd140;
				8'd3: sin=8'd146;

この8ビットデータをさきほどのSPIのコードに入れてあげると、おぉ、たしかに正弦波っぽい音がでた！

..ちょっとザラザラした正弦波な気もするが、まぁスピーカーもビットレートもアレだしこんなもんだろう。

次の野望：次はなにやろうかなぁ〜。。Web MusicのAdvent Calendarにエントリするまでにもうちょっとヒネりたい。

コード全体はここに置いといた。

DE0で音を出してみた。

前からFPGAでHDLを書いてみたかったので、２か月ほど前にDE0っていう入門用ボードを買って遊んでる。デジタル回路といえば中学のころにフリップフロップでLEDをピカピカさせた程度の経験しかないため、入門書を読みながら勉強し直し。デジタル時計くらいは作れるようになった。

つづいては4bit CPUを作ってみたいのだけど、その前にDE0で音を出してみたいなぁと思ってた。画像処理とか敷居高いけど音声処理ならFPGAでわりと簡単にいじれるかな？と思ったのと、G+でとよしまさんに教えてもらったWeb Music Developers JP Advent Calendar 2012にも何かエントリしてみたかったし。。

標準のDE0にはUSBやボタンやSDスロットは付いてるけど音関連のインターフェースはまったくなくて、FPGAで音を出したいときどうすればいいんだろ。。このあたりの電子工作的発想とか経験がまるでないので、DAコンバーターやアンプが必要？とか考えて、DE0拡張キットってやつにDAコンバーターとスピーカーが付いてるらしいのでポチってみた。なんか俺、ソリトンの思うつぼ。。

今日その拡張キットが届いたので、さっそく音の出し方のところを読んでみた。するとなんと、FPGAの出力端子にそのままスピーカーつなぐだけで、あとは適当な周波数で0と1を出力してやれば音が出るらしい（330Ωの抵抗をかます）。そんなもんなのか。DAコンバーターなくてもよかったなｗ

というわけで、まずは440Hzで0と1を出力するところからトライ。DE0では50MHzのクロックが供給されてるので、50MHz ÷ 440Hz = 113636回に1回の割合で0と1を繰り返すカウンタを作ればよいはず。適当に32ビットくらいのカウンタを用意すればいいか。こんなVerilog HDLのコードを書いた：

module Osc(
	input CLK,
	input nBTN,
	output SPKR
);

reg [31:0] cnt;
always @(posedge CLK) begin
	if (cnt == 32'd113636)
		cnt <= 32'd0;
	else
		cnt <= cnt + 1;
end
assign SPKR = !nBTN && (cnt < 56818);

endmodule

まずはreg文で32ビットのカウンタcntを用意しとく。CLKの値が50MHzで0と1を繰り返すので、always @(posedge CLK)っていうループ文みたいなやつで、そのクロックごとにcntに1を足すコードを書いておく。そして113636回数えたら0に戻す。あとは、cntの値が0〜56818（113636÷2）までの間なら1、そうでなければ0をSPKR（スピーカーにつながる端子）に出力する。そのとき、nBTN（ボタン）と&&しとくとボタンが押されたときだけ音がなるはず。

このコードをDE0のツール（Quartus II）でコンパイルしてUSB経由でDE0に読み込ませる。HDLってこんなふうにあたかもプログラミング言語みたいにロジックを書けるけど、もちろんCPUが手続き的に処理するんじゃなくて、すべて論理演算とフリップフロップのデジタル回路に変換されて、FPGA上でそれが再現される仕組み。だから俺の書いたコードが光の速さでしかも全演算が超並列に動くわけだ。HDL惚れてまうで。

ロードすると、それっぽい音がでた！やった！

次の野望：正弦波を出してみたい。サインカーブの波形データをHDLでベタに並べてサインテーブルを作って、それをD/Aコンバーターを通せばよいはず。D/Aコンバーター使わずとも、PWMとか、とよしまさんが教えてくれたDelta-Sigma modulationって回路を組んでもよいらしい（シャープの1bitオーディオみたいなやつですな）。まぁ、せっかく買ったのでラクしてD/Aコンバーター使う方向で行こうかな。

appengine ja night #22が終わりました！

すっかり半年に1回ペースになってしまったappengine ja night、22回目がニフティさんの会場で先日開かれました。今回はこんな内容：

• Google Cloud Endpointsでかなりラクするモバイルアプリ開発 by @kazunori_279
• Google Cloud Platformの海外エンタープライズ事例紹介 by グーグル株式会社エンタープライズチーム 福田潔さん
• 世界有数規模のApp Engine事例の開発ノウハウとBigQueryによるログ解析 by 株式会社アプリボット 永井友之さん

（いずれも公開資料は残念ながらありません。。代わりに @thorikiri さんの超詳細なまとめブログをご覧ください）

私の方からはGoogle Cloud Endpointsのご紹介。これはGoogle I/O 2012で発表された、Android/iOS/JSクライアント向けアプリAPI提供のためのWebフレームワークです。例えばサーバー側コードのメソッドfooに"@ApiMethod"ってアノテーションを付けてEndpointsのツールをゴニョゴニョ動かすと、Android/iOS/JS側で"obj.foo(bar)"って書くだけでサーバー側メソッドを呼び出せるようになります。REST APIやJSONの定義やそれを呼び出すクライアント側ライブラリの生成、そしてOAuth2認証まわりをまとめて面倒みてくれます。Endpointsは現在Trusted Tester向け公開の段階ですが、いずれ正式公開されるといいですね！

グーグル福田さんからはApp EngineやBigQuery、Cloud Storage等のCloud Platform製品に関する国内外の事例を紹介していただきました。AKB総選挙やRoyal Weddingみたいな瞬間風速トラフィックを扱うにはApp Engineぴったりですね。

つづいてアプリボット永井さんは、同社の大人気iPhoneアプリ（米国AppStore総合ランキング2位、国内総合1位など）のサーバー側を支えるApp Engine開発のノウハウを紹介されてました。1つのアプリで数千ファイルもデプロイしたり、デプロイに何時間もかかったりって、あまり他では例がなさそうですね^^; またBigQueryを使ったログ解析のデモを実演されてました。BQはインデックス使わないフルスキャン検索なので、CONTAINS（LIKEみたいなの）や正規表現を使った部分一致検索をバカでかいテーブルに対して実行しもさくっと結果が得られるのが便利ですね。

BeerTalk

BeerTalkは以下の2つ。

• VPSとGCSとGAEをハイブリッドで使う事例 by @stakezaki
  • 資料はこちら
• NEWSTRAINERのご紹介 by ENQUIRE 岩堀慶輔

たけざきさんは、VPSサービスとGoogleクラウド（App EngineとCloud Storage）を組み合わせて1千万件PDF文書の検索サービスを構築されたお話。Cloud Storageは速い！って強調されてたのが印象的。それと、VPS上のWebSocketsサーバーを使ったリアクティブなUIがかっこよかったですね！データが更新されると、WebSocketsでpush通知されてユーザーのUIが動的に更新されてました。

続いて岩堀さんは機械学習を使って記事を自動振り分けするRSSリーダーNEWSTRAINERをApp Engineでつくったお話。これ、RSSリーダーとしてすごく便利そう。ちょっと試してみます。機械学習の実装の解説ではベイジアンフィルタをApp Engineで実装する際の苦労話等がためになりました。

まとめなど

• appengine ja night #22 まとめ by @thorikiri さん
• ajn22のBTで発表してきました by @stakezaki さん
• appengine ja night #22 Google Cloud EndPoints by @vierjp さん
• appengine ja night #22 #ajn22 に行ってきました by @thorikiri さん

会計

• ビールとピザ：34,270円
• 集金：57,000円
• 前回繰越：7,378円
• 次回繰越：30,108円

今回も会場の準備等でニフティの飯塚さんはじめ皆さまにたいへんお世話になりました！ありがとうございます。

appengine ja night #21が終わりました！

appengine ja night #21が終わりました。今回は銀座のリクルートMTLにて。今回も盛況でしたね〜18:30の開始時点ですでに会場はほぼ埋まっていて、後半はイスが不足気味でした。

今回のセッションは以下の２つ。

• 「GAEで使えるぞ！！SPDYとその実践」by 小松健作 @komasshu
  • 資料はこちら

• 「数十億件をインデックスなしで数秒で全検索できるGoogle BigQueryってどんな仕組み？」 by @kazunori_279
  • すみません、公開資料はありません。。BigQueryのサイトはこちら

@komasshuさんのSPDY解説、これは分かりやすかった！　なぜTLSが必須か？　WebSocketとSPDYはお互いどんな位置づけにあるか？　SPDYの"server push"といわゆるserver pushの違いはなにか？　。。などなど、これまでモヤモヤしていたところがかなりスッキリしました。。App Engineではhttps://を使うだけでSPDY対応サイトとなるし、Channel APIもSPDY対応済み。

わたくし@kazunori_279のBigQuery解説では、BigQueryの概要やデモを紹介したのち、実際にGoogle社内ではBigQuery（社内ではDremelと呼ばれてます）がどう活用されてるかを、かなりぶっちゃけトークを交えながら紹介しましたw

BeerTalkは以下の３つです。

• 「BigQuery + Google Apps Script」 by @soundTricker
  • 資料はこちら

• 「App Engine Search API で嵐を見逃さない方法」by @ikasamt

• 「写真共有アプリのバックエンドサーバー」 by @tokibito
  • 資料はこちら

@soundTrickerさんのBTは、Google Apps ScriptからBigQueryのクエリを実行してSpreadsheet上にグラフを描くというデモ。GASにはちょっと前からBQのAPIがありましたので、やればできるんだろうなぁ〜と思いつつも、実際に動いているところを見ると感動ですね！ @ikasamtさんのBTではSearch APIの実際の使い勝手のところがレポートされてました。というかむしろ本題は最後のPyCharm絶賛タイムと@yukopさんのラテアートですよねわかります。私もJetBrainsにすっかり汚染されてるんで何も付け加えることはありません。最後、@tokibitoさんのBTは、写真共有サイトCottoをApp Engineで構築した事例の紹介。App Engineによるソーシャルメディアのproduction開発で必要となる実践的なノウハウ（画像のキャッシュ手法、タイムラインの実装方法、実際のコストとか）が紹介されてて大変ためになりました。

まとめなど

皆さんまとめありがとうございます！

• @thorikiriさん：appengine ja night #21 のまとめ
• @thorikiriさん：appengine ja night #ajn21 に行ってきました
• @wmo6hashさん：Google BigQueryなどの仕組みを知りたいときの列指向データベースの説明に
• 今回は機材の関係でustありませんでした。。すみません！！次回こそは。。

運営など

• ビールとピザ：57340円
• 集金：84000円
• 前回繰越：-19282円
• 次回繰越：7378円

いつもいつも会場の準備から後片付けまで大変お世話になっておりますリクルートの黒田さん、本当にありがとうございました！