ちょうどいいテクノロジ、というのは確かにあって、誰でもぱっとJSON、Markdownまでは思いつくと思うのだけど、その次が意外と難しい。 morritaさんはdataframeを挙げていて、これは確かに何かの基盤になっているとは思うのだけれど、なんとなく自分的にはjsonと並べるとしっくり来ない。
ちょうど良いでしばらく考えて思いついたものとしては、SQLiteがある。PostgreSQLやMySQLがすでにある所で登場したSQLiteは、 そのちょうど良さゆえに普及した気がする。だけれど、そこから特に語る所が無い。ふーむ。
と考えていて、そういえば最近「これはちょうど良い！」って思ったものがあった気がするな〜と考えていたら、 FlatBuffersがそれだったのを思い出した。
ちょうどいいシリアライザ、FlatBuffers
FlatBuffersはProtocol Buffersのようなもの。 ようなものってことはどこが違うの？という話になるけれど、自分はProtocol Buffersそんな詳しくないので違いを説明するのは難しい。 ということでFlatBuffersの話だけをする。なお、FlatBuffersとは何か、みたいなことはそんなに語らないので公式ドキュメントでも見てください。
FlatBuffersは凄くシンプルで、大したことをしない。そこが良い。 IDLっぽいものからヘッダファイルが生成されて、FlatBuffersのヘッダと一緒にincludeすれば良い。 リンクしなくて良い。いろいろなIDEのプロジェクトファイルと付き合わなくてはいけない自分の環境では大変うれしい。 生成されるファイルも単純で（比較的）小さい。読めばだいたい理解出来る。
メモリ上にすでにデータがあれば、そこからunpackして二重に持ったりしたくない、 オフセット指定してアラインとかエンディアンとか気にせず読み書き出来るくらいのに毛がはえたくらいでいいんだよなぁ、 生成されるenumとかはそのままenum classとしてC++で使えてさぁ、 フォーマットもそんなにかっちりしすぎず、フィールド足すくらいならデフォルト値で読めるくらいで昔のもそのまま読めて、 適当に手作業で必要な所だけ読んだりしたい、 でも配列とかは使いたいし文字列はいい感じに読めてほしい、 でも変な不定長とか要らないので読み飛ばしは簡単に出来てほしい、 みたいな、「こんなもんでいいんだよ」という思いに、ちょうど答えてくれるくらいの複雑さ。
使い方もそれなりにシリアライズの都合に合わせて出来ないこともあるのだけれど、 変にドキュメントできっちり仕様とか説明せずに、都合が悪いような使い方をするとassertで落ちる。そこをデバッガで見ると長々とコメントで何故ダメなのかが書かれていたりする。 そうそう、こんなもんでいいんですよ。
すでにある物を小さくして作るカッコよさ
PostgreSQLやMySQLがある所でSQLiteを作る、とか、Protocol Buffersのある所でFlatBuffersを作る、 というのは、難しいですよねぇ。 あとから小さい物で市民権を得るのは、「より労力を集めた」では無く、センスで勝負している感じがかっこいい。 どうやったらそれが出来るのか？はちょっと難しすぎる気がするので、代わりになぜFlatBuffersを使う気になるのか？を、半歩離れて見るくらいをしてみたい。
FlatBuffersが凄くいろいろな所で使う気になるポイントの一つに、手書きで書いてもだいたい同じ感じになるだろうな、という気がするというのが挙げられると思う。 手書きとの差分としてのゼロオーバーヘッド感というか（FlatBuffersは厳密にはゼロでは無いけれど）。 手書きで書いてもたぶんあんまり変わらないので、手書きの所は全部これでいいか、と思える。 だからちょっとしたものでも少し大きいものでも、なんでもかんでもFlatBuffersにしよう、となる。 最近自分はバイナリフォーマットは全部これでいいんじゃないか、と思って積極的に使っている。
ライブラリにはゼロコストで出来る範囲のことをする、という生き残りの道が一つあるよなぁ。 それでは、ある種の「良くあるがいつもでは無いユースケース」でサポート出来ない物が出てくるのだけれど、 それはライバルのライブラリに任せれば良い。ゼロコストの範囲にとどまる事で必ず一定の需要はあるし、ライバルと差別化出来る。 ゼロコストの範囲で出来る事は限られているのでどんどん機能が複雑になる事も無い。
といっても、こういうのは実際に作って市民権を得る所まで行かないと、作るという選択の正しさを証明は出来ない気がする。 すでにあるのを使わずにダメに再発明しているのとの区別は結果でしか出来ないよなぁ。