hsimyu's diary

ゲームなどをします。

10/10 お湯がうまい

10/10

ごはん

朝: オールブラン

昼: お弁当(魚、春巻)

夜: 鶏きのこ鍋

仕事

メインの仕事は小さい調整入れつつ、別件。git worktree でワーカーリポジトリを生やしまくっていた。submodule の init も作成時に行ってほしいな。面倒だから。

午前午後ともにひたすらビルド業。午後は計測屋さんもやっていた。

妊婦健診

少しだけ早く退勤して同行。26週目。特に問題なし。お疲れ様でした。

Protocol Buffer

次のような感じでメッセージを定義する。各フィールドには整数値のタグをつける。

    // 点
    message Point {
      required int32 x = 1;
      required int32 y = 2;
      optional string label = 3;
    }

XML より小さくて、XML パースするより高速(という主張)

https://ja.wikipedia.org/wiki/Protocol_Buffers

RPC で実際に使われている?JSON, XML に代わるシリアライズ形式として有望?

qiita.com

上記の記事だと、シリアライズよりもスキーマ(定義?)言語として優秀という意見。

Protobufはスキーマ言語だ!

一般的にはProtobufは「Googleが内部で利用しているシリアライゼーション形式」とか解説されていて、それは嘘ではない。ただ正直なところ、幾つかの理由でシリアライゼーションはどうでも良いと思う。

プロセス内部の簡素なデータ構造をシリアライズするためにスキーマ定義用のドメイン特化言語があって、こいつがなかなか優秀だというのがProtobufが生き残っている理由だろう。

言語仕様としてタグが定義されてて、こいつがあることによってフィールドが追加されたりしてもシリアライズが失敗しないように(互換性が保たれるように)なっているというのが重要?

色んなところで使いまわすためのデータ構造を定義するため(だけ)の形式で、ここから各種アプリケーションで使うためのデータ構造(定義)を自動生成できる。

スキーマ言語が必要なのはおわかり頂いたとして、なぜProtobufが良いのか。 簡単に言えば、シリアライゼーション形式としてJSONが良いのと同じ理由だと思う。

簡素で可読で、プログラミング言語から独立で、任意のデータを表現できるわけではないが十分に適用可能範囲が広い。すべてのニーズを満たそうとして仕様が膨れあがったりしていない。

仕様が小さいので、実装間の意図せぬ非互換性で苦しめられることが少ない。そして、周辺ツールを簡単に開発して足りない物を自分で補える。

納得

あくまでデータ構造定義のためだけの言語で、データから切り離されているというところがミソっぽい気がする。

その他

紅葉さんのおっぱい、デッッッッッッッッッッカ

スケールを間違えて提出したのか?

朝起きたら院生時代に共同研究してた先生から「コードにバグが出てて分からんから助けて〜」みたいなメールが来てたんだけど、エラーログなしで推察するの無理すぎる。ワロタ。