今この時期、もちろん弊社もCOVID-19関連の事情を鑑みてテレワーク……とはあんまり自分の回りでは言わない、リモートワーク(もっと言うとWFH: Work From Home)してる。自分が完全WFHに切り替えたのは1月半ばくらいだったかなー。もう3ヶ月ですね。 で、どうかというと、業務のパフォーマンスで見ると、自分のいまのパフォーマンスは明らかに悪い。少なくとも良くはない。それは自分でもわかってる。 でももう、これはしょうがない、と思うので、覚悟している。高パフォーマンス出せたらいいとは思うけど、同時にどう考えても無理して仕事で高パフォーマンス出すような時期でもないと思う。 だからこのエントリは、まあしょうがないよね、というのを受け入れよう、という話です。*1 なおこのエントリは業種柄、リモートワークに移行しやすい自分の話しかしていません。生活必需品や医療品関連の小売店舗や病院、窓口が

※この投稿は米国時間 2020 年 4 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。 ほとんどのソフトウェア デベロッパーがご存じだと思いますが、API 設計には RPC と REST の 2 つの主要なモデルがあります。モデルに関係なく、ほとんどのモダン API は、なんらかの方法で同じ HTTP プロトコルにマッピングすることによって実装されます。また、RPC API 設計では、RPC モデルの範囲から外れずに HTTP から 1 つまたは 2 つのアイデアを採用することが一般的になっています。これにより、API 設計者に提示されるオプションの範囲が広がりました。この投稿ではこれらのオプションについて説明し、どれを選ぶか決める際に役立つガイダンスを提供します。 gRPC は RPC API を実装するためのテクノロジーで、HTTP 2.0 をその基盤