自分の意見を伝える最良の方法は、相手を攻撃して自分の優れた知性を主張することだね。

そうそう、この記事は名誉の殿堂級の複合的誤謬で始まる。誰も主張してない仮想のアドホミネムを反論するストローマン。著者が一年以内にいくつかの大手テック企業から追い出された理由がなんとなく分かるね、LinkedInによると。

この記事が問題の詳細な分析と解決策も提供してくれたらいいのに。あ、実際そうだ！読んでみるべきだよ。

アマチュアが書いたものだけど、Google（世界で一番大きくて進んだテック企業の一つ）だけが抱える問題を解決してるよ。

そのラインの理由は根本的な緊張を示している。デビッド・ウィーラーが有名な言葉で言ったように、「コンピュータサイエンスのすべての問題は別の間接的なレベルで解決できる。ただし、間接的なものが多すぎる問題を除いて。」時間が経つにつれて、ますます巧妙な抽象が蓄積されていく。内面的に取り入れた抽象は見えなくなってしまう。それが私たちのやり方になって、他の人にどんなコストを強いているのか分からなくなる。すべての抽象は漏れがあるし、すべての抽象はメンテナンスプログラマーにとって障壁になる。これが、ブライアン・カーニハンが警告した問題につながる。「誰もがデバッグはプログラムを書くのの2倍難しいことを知っている。だから、書くときにできるだけ賢くなったら、どうやってデバッグするんだ？」結局、デバッグしなきゃいけないのは、あなたの抽象を知らないメンテナンスプログラマーだろう。Googleのアプローチから見える重要な知恵の一つは、業界全体が抽象に対して持つ傾向が有害だということ。特定の抽象が強力であっても、あまりにも多くなるとそれ自体が問題になる。だから、例えばGoは過剰な抽象を強く抑制するように設計されている。プロトバッファーは、言っている通りのことをする。意図されたシンプルな使い方をしていれば、うまく機能する。彼の不満は結局、「新しい抽象を生成するためにメタ操作を試みたけど、デザインがそれを許さなかった」ってことに集約される。それはアマチュアが書いたからではなく、ほとんどのプログラマーが無視できるほど賢いと思っているエンジニアリングの知恵を取り入れるために書かれているからだ。（過去の自分もそのプログラマーの一人だった。）技術は悪用されることもあるし、バカなことをする人もいるし、やりたいことができないこともある。もちろん。でも、KISSを守れば、うまくいく。シンプルに保てば保つほど、うまく機能する。これが、より良いエンジニアリングデザインを生み出すためのインセンティブだと思ってる。

if (m_foo = null) Googleをアマチュア呼ばわりして、その書いたコードが代入と比較演算子を区別できない一年生のエラーを含んでるなんて想像してみて。プログラマーが基礎的な技術について文句を言うクラスの愚痴がネット上にはあって、スキルの問題を認める代わりにそういうことを言ってる。もしその穴に深く入り込むと、最終的にはRustでカーネルを書き直す羽目になるよ。

うん、記事には皮肉がたくさんあって、彼らの主張を台無しにしてるよね。

あまり広く使われてないけど、Typicalのアプローチは好きだな。https://github.com/stepchowfun/typical > Typicalは、互換性を壊さずにレコードタイプにフィールドを安全に追加または削除するための古典的な問題に対する新しい解決策（「非対称」フィールド）を提供してる。この非対称フィールドの概念は、和集合型でケースを追加または削除する際に互換性を保つという二重の問題も解決するんだ。

好きってわけじゃないけど、SBE（シンプルバイナリエンコーディング）は、逆互換性と前方互換性の領域ではまあまあの解決策だね。

ASN.1はメッセージのバージョニングを非常に正確に実装してる。リンターを実装するのは簡単だよ。

その通り。プロトバッファはJavaやGoと同じように考えてる - 少なくともC++で書いてるわけじゃないしね。あまり仕様がはっきりしてないJSONを使うのをやめるのは、こういう小さなストレスを考えると価値があると思う。

ゲームでプロトコルバッファを使ってて、互換性のあるやつを常に使ってるよ。ゲームのリリースごとにバージョン番号を含めてる。プロトを変更するときは新しいフィールドを追加して古いのを非推奨にして、バージョンを上げる。バージョン番号を使って古いフィールドを新しいものにアップグレードするための一連のステップを実行してる。

逆互換性を持つ変更を定義し、逆互換性のある変更を強制するリンターがある別のシリアライズ宣言フォーマットを挙げてみて。この記事では「逆互換性と前方互換性の嘘」というセクションでこれを扱っている。プロトコルバッファーを使った経験は、著者がこのセクションで説明していることと一致してる。

この記事では誰も逆互換性のあるものを使っていないって言ってるけど、それはちょっと変だと思う。Nクライアントとサーバーを設定してプロトコルバッファーで通信させて、スキーマにフィールドを追加して、サーバーとクライアントをどの順番でもデプロイできるのは、他のフォーマットよりずっと楽だよ。なのに著者はプロトバッファーの作者（元々はジェフ・ディーンたち）を「アマチュア」って呼ぶなんて、ほんと大胆だよね。

これを考えるときは、常に「代替案は何か？」ってことを探るべきだよね。そして、なんでより良いものがないのか。protobufのほとんどのユースケース、特にそのデザインに影響を与えたものが理解できない。ESPホストで使って、2つのMCU間で通信するために使ってるけど、見た中で一番摩擦の多いシリアライズプロトコルだし、バイト効率もあまり良くないかも。もしかしたら、特化したシリアライズライブラリ（bincodeやpostcardなど）の方が簡単かもしれないけど、ネットワークシステムに適用される抽象について何か見落としてる気がする。

その2つの基準だけで、せいぜい6つのフォーマットに絞られるけど、その中でProtocol Buffersが一番広く使われてる。こういうブログ記事で一番嫌なのは、ブロガーがいろいろ批判的で意見を持ってるのに、記事が2018年のもので、protobufがまだ支配的だってこと。しかも、こんなに長い間、ブロガーが自分の考えに合ったより良い解決策をまとめられなかったのが明らか。トピックに強い思い入れを持つのは全然いいけど、批判するためにこんなにエネルギーを使って、プロジェクトに貢献した人に個人的な攻撃をするのは無意味だし、ただの自己宣伝に過ぎない。自分のビジョンを実現するものを作るか、他の人を貶めるために時間を使わない方がいいよ。かっこよくないね。

Protobufは新しいものじゃないよ。要するに、https上のrpcみたいなもんだ。1997年にIDLを使ったdce-rpcを使ったことがあるし、CORBAもIDLを使ってたと思うけど、個人的には使ったことないな。他にもejbみたいな試みがあったけど、基本的には同じパラダイムだよ。Protobufの一番の利点は、技術面じゃなくて、社会的・経済的な側面だね。オープンソースで、以前のソリューションみたいな独自のハックからも解放されてるし。それに、rpcがサブトピックの分散システムは一般的に難しいから、期待値としてはあまり良くないかもね。

まあ、どんなシリアルフォーマットでもネストしてエンコードできるからね。これはProtobuf特有の問題じゃなくて、開発の組織図がデータ構造として現れてるだけだよ。

それはひどいね。なんかAppleのソフトウェアはもっとクリーンだと思ってたけど、結局はマーケティングに影響されてたのかな。実際は中身は同じスパゲッティだよね。

https://github.com/RhetTbull/osxphotos

これ、シンプルなJSON文字列で済んだんじゃない？JSONをシリアライズフォーマットとして解析するのは全然「シンプル」じゃないよ。

JSONバージョンも間違ったエンコーディングになってたはずだよ。すべてのフォーマットは、人間が書いたコードから供給されたデータのフレーミングに過ぎない。Macの場合、エムダッシュは常に問題になる。だって、Macがそれを意図的に決めたからね。

もしそれが慰めになるなら、現在のバージョンのスキーマでは、ZASSETテーブルの中で単にZLATITUDE FLOAT、ZLONGITUDE FLOATになってるよ。

これらの古いスレッドには素晴らしいコメントがたくさんあって、2018年以降この分野で新しい科学はあまりないから、古いスレッドの方が今のより読み応えがあるかも。面白いのがあるよ：https://news.ycombinator.com/item?id=21873926

関連して、著者の懸念のほとんどはメッセージでラップすることで解決できる。 > oneofフィールドは繰り返せない。繰り返せるメッセージでoneofフィールドをラップすればいい。 > mapフィールドは繰り返せない。繰り返しフィールドを含むメッセージでラップすればいい。 > mapの値は他のmapではいけない。mapを値として使えるメッセージでラップすればいい。これ、ちょっと不便かもしれないけど、著者はこれを「プロトは基本的にできない」って位置づけてる。

シリアライズの複雑さの大部分は、異なる時点間の実装の互換性から来ている。著者は互換性についてかなり語っていて、特に設定されていないフィールドと、意図的にデフォルトに設定されたフィールドを区別することの重要性について話している。プロトバフがこれをどう回避したのか、彼らは何を理解していないと思う？

それにUDPだから、もしパケットが失われたらそれで終わり。標準のHTTP/JSONじゃないから、1年後には誰も理解できなくてデコードもできない。学んだり遊んだりするにはいいけど、なんでわざわざ人生を複雑にする必要があるの？

埋め込み型/制約のあるUDPでは、プロトバフのワイヤフォーマット（でもGoogleのライブラリは除く）が素晴らしい。セルラー越しのIoTなど、すべてを単一のデータグラムに収める必要があるからね（往復回数が消費電力を決める）。「UDPは信頼性がない」と言う人には、アプリケーションレベルでARQを実装すればいいんだ。TCPがやってるのと同じだけど、SYN-SYN-ACKのハンドシェイクに往復を無駄にする必要もないし、もはや関係ないデータを送るためにバイトを無駄にすることもない。バリアントで勝負だね。時系列データをバリアント配列の列として送信すれば、デルタやRLL圧縮もかなり簡単になる。そしてボーナスとして、デバイスに新しいフィールドを実装してすぐに展開できる。サーバー側のサポートは、実際に必要になるまで待てばいいからね。フラットバッファやキャプテンプロトは固定レイアウトのせいで大きすぎて受け入れられない。CBORは絶対にダメだよ。毎回スキーマに貴重なバイトを無駄にする理由がわからない。一般的な圧縮（gzipなど）は、こんな小さなサイズではあまり効果がないし、逆に悪化させる可能性が高い。はい、ASNが正しい解決策のはずだけど、$$$がかかる完全な実装はないし、全体的に膨れすぎてる。期待されていることに対してうまくいかないのはちょっと面白いけど、他のところでは実際に光ってるんだよね。

UDPでもJSONを送れるよ。Wizのスマートバルブがコミュニケーションにこれを使ってるんだ。https://github.com/sbidy/pywizlight?tab=readme-ov-file#examp...

すべてのアプリでワイヤアプリコンバータを書き直すことができる これがGoogleのやり方だよ。私たちは「プロトバフAをプロトバフBに変換する」ことが私たちの仕事だと冗談を言ってる。

ネットワークの帯域幅が気になるなら、送信前に圧縮すればいいよ。ほとんどのウェブアプリがそうしてるしね。そうすれば、アプリのフォーマットのスペース効率についてあまり心配しなくて済むよ。

これを実現する方法は、コード生成のステップをハードコーディングしないことから始まる。代わりに、コード生成をデータスキーマオブジェクトとコードテンプレート（例えば、Jinja2テンプレート言語で表現されるもの）両方の関数にするんだ。コード生成の段階は、テンプレートをデータスキーマに適用してコードアーティファクトを生成するだけ。テンプレートは、データスキーマがメタスキーマ（例えば、JSONのデータスキーマ用のJSONスキーマ）に従って提供されることを前提に書かれてる。例えば、言語ごとのテンプレートを開発して、シリアライズコードやシリアライズ形式（ワイヤ上）とアプリケーションフレンドリーな形式の間の変換器を生成することができる。特定のターゲット用のテンプレートを開発するための追加の努力は、共通のメタスキーマに従うすべてのデータスキーマで機能するから、コストが分散される。「コード生成」段階では、もちろん「コード」テンプレート以外のものを使って、データスキーマに関するリファレンスドキュメントをHTMLやテキスト、nroff/manなどの異なる形式で生成することもできる。

これは両方の方向で機能する。一般的な構造は過度に抽象的になりがちで、ちょっとした抽象の変更でいろんなところに隠れたエラーが出てくることがある。古い格言のように、これは好みの問題だよね。良いソフトウェアエンジニアリングには、まず第一に、選んだ道やツールに関係なく、素晴らしい規律が必要だよ。