gRPCを学んでいる

マイクロサービスや自作ミドルウェアのAPIをメンテナブルにしたいよねっていう文脈で、OpenAPIやGraphQL、gRPCといった技術が採用されるのを最近よく目にする。

バックエンドを実装しているWebエンジニアとしては、こういう仕組みが整備されつつあるのはありがたい。APIをシステムの外に公開しようとすると、ドキュメンテーション/バリデーション/クライアントの実装など、意外と副次的な作業が必要なので、、汎用化されたツールに頼れるのは助かる。マイクロサービスを用いたアーキテクチャを考えるにあたっても、システム間のアダプタをイメージしやすくなる。

そういう背景で、最近家ではgRPCを調べている。このあとはgRPCについて調べたことのメモや感想のコーナーになっているので、興味があったらどうぞ。

主な情報源

だいたいこのへんを眺めておくと、gRPCの基本については抑えることができる。

試しにコードを書いてみた

自分でprotoを定義して、gRPCのプログラミングを体験してみた。

いくつかの言語でgRPCのサーバ/クライアントを実装してみたかったので、同じメソッドを実装したgrpcサーバをたくさん立てると、勝手に連携して動作するような構成にしてみた。コードはGitHubに置いてある。Dockerを使って試せるようになっているので、make build && make upとすると動いているところが見れる。

github.com

全体を管理するBossプロセスとその元で働くMemberプロセスがいて、以下のような感じで動作する。特に何かの役に立つというモノではない。


  1. Bossプロセスを起動する
  2. いくつかのMemberプロセスを起動する。Memberプロセスは起動したらBossプロセスのJoinメソッド呼び出す、このシステムに参加する
  3. Boss プロセスはしばらくMemberプロセスの参加を待ったあと、Memberプロセスの順序を決める。
  4. Bossプロセスは決めた順番になるように、各Memberプロセスに対して、そのプロセスの次のプロセスを指定するSetNextメソッドを呼び出す。循環するように一番最後のMemberプロセスの次のプロセスは最初のプロセスになるようにしておく
  5. Bossが最初のMemberに対してPokeメソッドを呼び出す。MemberプロセスのPokeメソッドを呼び出すと、そのMember次のMemberのPokeを呼び出すようにしておく
  6. 一度投入されたPokeメソッドの呼び出しは連鎖して無限に呼び出され続ける

本当は、gRPCのサーバとクライアントを10言語で実装してみた結果www みたいな感じでレポートしようとしたけど、似たような実装を繰り返すだけみたいな雰囲気になったので途中で飽きて終わった...。

感想

  • データ型とメソッドのシグニチャのみでRPCのインタフェースを定義できるのが簡潔で良い
    • クエリやPOSTされたメッセージとデータ型との対応をちまちま定義する必要がない
    • RPCのドキュメントとしてみたときも分かりやすい
  • プログラミング言語ごとにprotocで生成されるgRPCサーバの実装モデルがまちまちなので注意する
    • 共通のgRPCサーバ実装というのはなく、各プログラミング言語ごとに丁寧に実装されている(それぞれの言語の実装を眺めるとおもしろい)
    • 実装モデルを理解して利用しないとパフォーマンスの問題が起こるかもしれない(PythonやRubyではGILに注意するとか)
    • PHP ではそもそもサーバの実装がなかったりした
  • プログラミング言語ごとにprotocで生成されるgRPCクライアントの機能がまちまちなので注意する
    • Pythonのクライアントでは非同期にgRPCのメソッド呼び出しをして結果をfutureで得たりできておもしろい
  • 静的型付けのプログラミング言語と相性が良い印象
    • Protocol Bufferで定義したmessage型と、gRPCを実装しているプログラミング言語上の型との間に直接対応があるとわかりやすい

書いてみた中では、Goと相性が良かったように思う。Google文化圏の技術同士だからという感じはある。

次のアクション

ひとまずシンプルなサーバとクライアントを実装しただけなので、もう少し進んだトピックにも取り組んでみる

  • ストリーミング
    • gRPCはストリーミングでメッセージを送受信できるので体験してみる
  • ロードバランシング/冗長化
    • 実際のシステムで利用するにはロードバランシングや冗長化が必要になる。gRPC的には一つのトピックみたいなので調べてみる
    • GCPだといい感じのグッズがあるだとか、AWSのALBと相性が悪いっぽいとかの噂を聞く
  • grpc-gateway
    • gRPCはバイナリプロトコルということもあって、gRPCに対応しづらいシステムからアクセスできなかったり、気楽にcurlで試せなかったりする
    • gRPCのメソッドにそれぞれ対応するREST APIを生やしてくれるグッズがあるらしいので試してみる。実運用ではどうせこういうのが必要そう
  • 意味のあるgRPCを喋るアプリケーションの開発
    • もうちょっと現実味のある課題に出会えるかもしれない

やっていく技術テーマを探す

Webエンジニアを8年くらいやっていて、なんとなく、一通りのことはできるようになってきた。ただ、ちょっと得意な分野もあるとはいえ、基本的になんでも屋さんとしてやっているので、技術者としてのアピールがいまいちだなーというのが気になっている。そこで、技術者としての自分をアピールできそうな技術テーマを一つ選んで、それにじっくり取り組んで見ようと考えた。

しかし、取り組む技術テーマをうまく選ぶ自信がない。そこで、ちょっと作戦を考えて取り組む技術テーマを見つけようと試行錯誤してみたので紹介してみる。

ステップ1: 指標を考える

やっていく技術テーマを見つけるにあたって、テーマの候補をスコアリングしてみることにした。漠然とスコアをつけるのは難しいので、自分が普段技術テーマに取り組むかどうかを考えるときに気にしていることを思い出して、5つの指標に分解してみた。

  • 指標1: 自分の興味
    • 自分がおもしろい、やりたいと思うかどうか
    • モチベーションがないとやりはじめることもできない
  • 指標2: すぐに役立つか
    • すばやく学べて、すぐに実際の問題解決に活かせるかどうか
    • すばやく成果が出せるとうれしいし、モチベーションも持続する
  • 指標3: 長く役立つか
    • 流行り廃りに影響されにくく、将来に渡って活用できそうか
    • 学んだことが無駄になりにくいし、多くは下地になるような技術だろうから基礎力がつく。 この記事でもそういった話題について言及してる
  • 指標4: Web技術者人気
    • Web技術者にとって人気があって注目されているか
    • いろんな人に役立ったほうがうれしいし、評価もされやすい
  • 指標5: ブルーオーシャン度
    • 取り組んでいる人が少ないか
    • 競争相手が少ないほうがのびのび取り組めるし、第一人者になりやすい
    • (追記 2018/03/18 9:00: この指標はしっくり来てない感じはある。自分が入り込む余地があるかというイメージなので"スペースがあるか"くらいが良さそうかな。)

あくまでも僕が何を大事にして技術テーマを選びたいかに基づいている。人によってはブルーオーシャンかどうかは気にしないとか、もっと別の評価軸があるとかはあると思うので各々考えると良いと思う。とにかく分解して考えられるようにする。

ステップ2: 取り組めそうな技術テーマを羅列する

まぁ、これは良さそうなテーマを思いつく限り羅列する。会社の人とかにも聞いてみたりした。

ここでは、ポケモンエンジニアリング、エンジニアの学び方、機械学習、Goというテーマが思いついたとする。自分は20個くらい思いついた。

ステップ3: 技術テーマにスコアをつける

ステップ1で考えた指標にもとづいて点数をつけて表にする。点数の付け方はなんでも良いと思うけど、13までのフィボナッチ数を使ってみた。仕事でタスクの見積もりとかでよく使っているので、自分は相対感がつけやすい。

例として選んだテーマについてめちゃくちゃ適当に点数を埋めてみた表が以下のようになる。実際にはGoogle Spreadsheetを使ってる。

技術テーマ 自分の興味 Web技術者人気 すぐに役立つか 長く役立つか ブルーオーシャン度 合計値
エンジニアの学び方 8 13 8 13 5 47
ポケモンエンジニアリング 13 2 8 3 13 39
IoT 8 8 5 13 1 35
Go 8 8 8 8 3 35

この表にうめている点数はめちゃくちゃ適当につけたやつなので、本当に意味はない。目的は自分のやっていく技術テーマを決めることなので、実際には主観的にえいやっと点数を決めていくと良いと思う。自分の興味とかはそもそも主観的だし、Web技術者からの人気なども自分の判断で決めるしかないだろう。

点数をつけ終わり、合計値のランキングの上位を調べることで、自分にとっての有望な技術テーマがわかってくるはず。

ステップ4: レーダーチャートで可視化する

ステップ3までを自分でやってみたところ、合計値ランキングの上位の技術テーマが似たような点数になったので、点数の傾向がひと目でわかるようにレーダーチャートで可視化してみた。

例の表のデータを使って可視化してみると、以下のようになる。

f:id:hakobe932:20180317174538p:plain

これで、分析がしやすくなった。このレーダーチャートはChart.jsを使ってサクッとつくった。GitHubにコードをおいてある。

感想

実際やってみてて、どうだったかというと、ランキング上位になった技術テーマのラインナップを眺めると、大方まぁそうですねという感じであった。だが、1つだけ自分の興味がめちゃくちゃ低いが、他のスコアが高いために上位にランクインしているテーマがあり、ふーむなるほどねという発見があった。逆にランキング下位になった技術テーマにも、自分では良さそうに思っていたテーマのスコアが意外と低いということがあった。

指標を分けてそれぞれ評価することで、多少は客観的な評価ができたのだと思う。副作用的に指標を考えることで自分が技術テーマについて何を大事に思っているかを整理できたのも良かった。

さらにスコアの内訳をレーダーチャートで眺めると、平均的に全部が良いテーマはなく、指標が偏っていることがわかるなど発見があった。上位テーマのスコアは点数が似たり寄ったりなのだが、5つの指標の中から何を大事にしていくかを考えていけば、自ずと良さそうなテーマに辿り着けそう。

正直まだ点数を見直したりして、やっていく技術テーマを決められていないのだけど、このままではワナビーで終わってしまうので、このあとえいやっと決めようと思う。

Fluent Pythonを読んだ

技術書レビュー

Fluent Python ―Pythonicな思考とコーディング手法

Fluent Python ―Pythonicな思考とコーディング手法

ちょいちょいPythonのコードを書くことが出てきたので、ちゃんとした使い方を学ぶために読んでみた。Pythonic にオレはなる！

目次 を見るとわかるのだけど、データ構造、関数、オブジェクト、制御構造、メタプログラミングと言語の機能を広く深く取り扱っていて、Pythonをしっかり理解するという目的にはぴったりだった。Pythonの基本文法は抑えてるのが前提になっているので、初学者は入門 Python 3あたりを読んでおくと良いと思う。

この本が良いのは、各章ごとに参考文献がかなり充実している点だ。章の終わりに油断していると何ページも資料の紹介が続いてびっくりする。各トピックについて本書の内容だけでもよく説明されているのだが、さらに踏み込んで調べられるように、ドキュメントや書籍、役に立つ記事をコメント付きで紹介してくれている。ときにはフォーラムやカンファレンスでの発表へのリファレンスもあり、コミュニティがどこでも盛り上がっているのかも自ずと伝わってくる。著者がPythonコミュニティで長年活躍されているなかで得られた知見を、効率良く摂取できる本になっている。

また、Pythonの様々な言語機能の実現メカニズムを学ぶことを通して、Pythonの設計思想全体を学べる構成になっているのも良い。例えば、抽象基底クラスを実装しているかどうかは、isinstance関数を用いてチェックできるのだが、これはデフォルトでは継承関係によってチェックされる。しかし、実は特殊メソッドである __instancecheck__ の実装により振る舞いをオーバーライドすることで、特定のメソッドを実装していることで実質的に同じクラスとみなして良いかをチェックできるようになっている。これはPythonがもともと持つダックタイピングの考え方を、Python的特殊メソッドを用いて導入していたりするわけで、なかなか面白い。機能ごとに、こういう実装パターンを学んでいくことで、自ずとPythonicな考え方がみについてくる(ような気がする)。

原著がPython3.4あたりベースなのでちょっと古いのには注意したい。最近のPythonだったら f stringやasync awaitなど、紹介されている機能のより良い代替手段があったりする。

とにかくページが多く読むのは大変なのだけど、上記のようにPython的考え方を密度高く学べるので読んで損はないと思う。加えて著者の熱量が高く、そこらかしこで良いことを教えてくれるので、Pythonの話題にかぎらずかっこいいハッカーの考え方を盗める良い本だと思う。

ドメインをRoute53に移した

冬休みにもうちょっとなんかやっていたのを思い出した。個人の実験サーバを"douzemille.net" というドメインでホストしているんだけど、ドメインのレジストラとDNSをVALUE-DOMAINからRoute 53に変更した。

VALUE-DOMAINは長年使っていて特に不満はなかったし、お名前ドットコムに買収されたあとも普通にサービスが維持されていて助かっていた。一方、Route 53はAWSの他のサービスの連携がしやすく、近代的なDNSの機能が使えそうな雰囲気があったのでちょっと試してみたかった。最終的には興味が勝ってRoute53を使ってみることにした。

設定の手順については、AWSのドキュメントを見れば詳しくのっているので言うことはない。読みましょう。

docs.aws.amazon.com

WHOISに記載されているメールアドレスが利用可能でないと移管の手続きはできないので注意しておきたい。

1月2日とかの正月真っ只中に手続きをしたので、1週間くらいは時間がかかるのかと覚悟していたのだけど、1月3日には手続きが終わっていた。さすがにだいたい自動化されているような感じがする。

移行前のVALUE-DOMAINではドメインの料金を5年分くらい支払い済みだったのだけど、Route53へのドメインの移管後も有効期限は維持されていたので助かった。なんとなくこれはTLDを管理している組織ごとに扱いが違うような気がする。気がする以上の根拠はないです。

コスト的なメリットはないというか悪くなっていて、ドメイン利用料以外にDNSの利用に従量課金が発生する。料金表を見た感じ100万クエリごとに0.400 USDとかそういうオーダーなので気にせんでええことにしてる。

ポケモンのタイプ相性チェッカー作った

急にポケモンの話をします。最近、熱心にポケモンの対戦動画を見ていて、自分でも昨年11月に発売されたポケモン ウルトラサンムーンで対戦用ポケモンの厳選環境を作ってしまった。

ポケモンは対戦においてはタイプがとても大事なのだけど、タイプ同士の強弱関係を覚えるのが意外と大変。タイプは18種類ありすべての組み合わせに相性が設定されている(公式のタイプ相性表)。タイプ相性には方向があり、対象性はあったりなかったりするので、基本的には全組み合わせ覚えるしかない。また、2つのタイプをもつポケモンもいるので、複数のタイプ相性関係をかけ合わせて考える必要もある。

たぶん全部覚える必要はなくて、頻出の組み合わせを覚えば、なんとかなると思うのだけど、慣れるまでは大変。タイプ相性表を印刷なりして都度確認しつつ覚えていくのが良さそうだったけど、ちょうど良さそうな課題だったので自分でタイプチェッカーを作って見ることにした。

できたもの

こういう感じのWebアプリケーションを作った。

f:id:hakobe932:20180108120310p:plain:w320
選択したタイプでぼうぎょするか、こうげきするかを選んでおき、上部のボタンを押してタイプを選択する。そうすると下の方に、タイプ相性の計算結果が一覧になって表示される。

スクリーンショットの例では、ゴーストとフェアリーの２つのタイプを持ったポケモン(=ミミッキュ) に対して、どんなタイプのわざが効果があるのかがあるのかがわかるようになっている。ミミッキュはこうかはばつぐんになる技のタイプが少なくて優秀ですね、という感じ。

https://douzemille.net/poketype/ にデプロイしてあるのでどうぞご利用ください。

実装

ポケモンタイプ相性チェッカーのコアドメインはタイプ相性関係である。そこで、まず、その部分を抽象化したnpmモジュールを実装した。

github.com

ここは一番大事なので、Flowで型アノテーションをほどこしてある。全組み合わせのテストはできそうにもないので、代表的な部分だけテストも書いてある。実装で一番大変だったというかだるかったのはこのへん。

このモジュールを使うと特定のタイプを持ったポケモンに対して、特定のタイプの技のこうげきを行ったときの効果を得ることができる。だいたい以下のようなイメージ。

import poketype from 'pokemon-type'

const { ほのお, くさ } = poketype.Types

const フシギダネ = poketype.createPokemon(くさ)
const ひのこ = ほのお
const effectiveness = poketype.calcEffectiveness(ひのこ, フシギダネ)

console.log(effectiveness.message) // 'こうかは ばつぐんだ！'

まだ、npm publish してないけどそのうちしたい。インターフェースに日本語使っているのだけはやめたほうが良いかもと思っている。すでに、flow gen-flow-filesすると日本語の型定義の部分が8進数のunicode表記に変換された結果、use strictされたJSの処理系で評価できなくなるという問題に遭遇している。

そして、このpokemon-typesモジュールを利用して、今回のWebアプリケーションを実装した。

github.com

このWebアプリケーションはフロントエンドだけで完結していて、ペラ1のHTMLとJavaScriptで構成されている。見よう見まねで現代的な感じのするReactアプリとして実装した。状態の管理にはRedux、コードのbundleを作るのには、webpackを使っている。

コアの部分はちゃんと実装できているという前提でこちらのコードはわりと殴り書きしている。実装がすべてindex.jsに書かれていたりしてひどいがまぁ動く。デザインセンスはないものの18種類の色のボタンを並べるとカラフルで華やかにはなった。

感想

できたものは、まぁ普通に便利という感じになった。UIの操作感のこなれなさはあるものの、とっさにぱぱっとタイプ相性を調べられる。

ただ、対戦相手のポケモンが登場したときに、そもそもそのポケモンのタイプを覚えていないことが多く、結局ググって調べることも多い。また、ポケモンにはタイプ以外にもいろんなパラメータがあるので、タイプ相性だけ知っていてもどうしようもなく総合的な情報がどうしても必要になる。そこまでくるとデータベースサイトを運用するみたいな世界になってくるが、そういうサイトはすでに存在するので自分でやるメリットはそんなになさそう。

まぁタイプ相性表を実装するのは世の中に何人もいなくて良いはずなので、公開しておくと誰かにとっては便利になるかもしれない。

自分のプロダクトでフロントエンドのJavaScriptを書くのはひさびさだったので、技術的な感想も羅列しておく

  • VSCode でFlowのコードは書けるけど、VSCode自体はTypeScript推しなので時々TypeScriptっぽい型の解釈をしはじめたりする。設定でjavascript.validate.enableをfalseにしておくと良い
  • eslint --fix + prettier で完全なる心の安心が得られる
  • 日本語の識別子使うとテンションは上がるけど、動かないツールに遭遇する心配は増える(そして実際遭遇した)
  • webpackは普通に良くできていてコレでいいじゃんという感じ。gulpよりも実際のユースケースに合わせてもうちょっとモデリングされている
  • SASSでMap型の値をループするのは便利。ポケモンのタイプの数だけCSS書かずに済んだ
  • eslintとbabelとflowとwebpackの設定をすべてやらないと開発が開始できないのは大変。一つのプロジェクトで設定を作ったらその後は使いまわせるので楽。ポケモンの厳選と同じやな！
    • create-react-app には途中で気づいた

追記 (2017-01-09)

motemenさんによる先行研究があった

motemen.hatenablog.com

タイプ相性表を入力しているひとがここにもいた。その部分だけでも拝借すれば良かった...!

micro:bitを買うてきた

あけましておめでとうございます。今年もよろしくお願いします!

それはさておき、micro:bitを購入してしまったので、年末年始のひまつぶしによかろうと、雑なプログラムを幾つか作ってみた。

micro:bit is 何

micro:bitはイギリスのBBCが作っている教育用のマイコンボード。イギリスでは子どもたちに無料で配っているらしい。25個のLEDと2つの入力用ボタン、温度センサーやジャイロセンサー、BLEの通信コンポーネントなどが一つのボードにパッケージングされていて、部品を組み立てたり配線しなくてもいろんなことができる。ともかくオフィシャルサイトの紹介 を見るとわかりやすい。ボードの見た目がかわいい。

開発は本格的なプログラミング言語も使えるが、Web上で動作するScratchみたいなブロックスタイルの開発環境も良くできている(なんかMicrosoftが作ってるみたい)。

サイコロ

ボード自体を振ると加速度センサが反応するので、それをトリガーにサイコロを振ってくれるプログラム。ちょっとしたエフェクトが表示されたあと、1~6の数字がランダムで1つ出力される。

firmwareのコードは以下のような感じで素朴。ご覧のとおり開発環境にはシミュレータもついてたりして試行錯誤しやすい。

Twitterの特定キーワードを監視してLEDで通知してくれるくん

Twitterのfiltered realtime apiを使うと適当なキーワードを含むツイートをストリームで受け取ることができる。これを使って、Twitter上で特定のキーワードをつぶやいている人がいることを検知し、それに合わせて micro:bitのLEDを点滅させることで、すぐさま話題に気づけるというプログラム。

キーワードに反応したら以下のような感じで光る。

micro:bit には無線LANインターフェースとかはついていないので直接インターネットに接続することはできない。一方、Bluetooth LEのインターフェースはあるので、他のコンピュータと通信することはできる。今回は母艦のMacでTwitterのストリームを見ておいてイベントが起こったら、BLEでLEDを光らせる命令をmicro:bitに送るようにした。

micro:bit側で動作させるfirmwareのコードはめちゃくちゃしょぼくて、以下のとおり。コードには現れていないが、右上の歯車からたどり着ける"プロジェクトの設定"で、"No Pairing Required: Anyone can connect via Bluetooth." しておくと良い。

母艦のMac側のコードはNode.jsで実装する。BLEでmicro:bitを接続するための便利なnpmモジュールがあるのでそれを使うと良い。

github.com

罠があって、このモジュールが依存しているnobleというモジュールが Mac OS High Sierraでは使えない。ありがたいことに、パッチを書いてくれている人がいるので、それを使おう。

とにかくnode-bbc-microbitを使うといい感じに、micro:bitと通信できるようになる。今回の仕組みを実現するために自分で書いたソースコードは以下のリポジトリにあるので見てくれ！

github.com

たいしたことはしてないけど、チカチカ点滅させる部分をasync/await使って書いているのがいい感じに書けたポイント(コールバックとかPromiseでやるとダルそう)。

for (let i = 0; i < 5; i++) {
  await writeLedMatrixState(microbit, PatternSmile);
  await sleep(100);
  await writeLedMatrixState(microbit, PatternBlank);
  await sleep(50);
}

ちょっと使ってみたところ、"紅白" みたいなキーワードだと無限にチカチカしていて意味がなかった。"ポケモン配布"みたいな微妙にニッチ感のあるキーワードだと程よい間隔で反応がある。普段は "はこべ" とかで検索しておくと良いか。

Twitterのキーワード監視だと微妙に使いでがないけど、要はイベントにトリガしてLEDが制御できるということなので、ログをtailしてERRORって文字列があったら光らせるとか、Googleカレンダーの予定の10分前から光らせておくとかできそう。

感想

振ったらデバイスが反応したり、LEDが光ったりするのは楽しい。1ボードで完結して動くので物理的な安定感があって扱いやすい感じがする。開発環境はとてもよくできてて使いやすい。電子工作のキットもいろいろあるので、ボード単体で飽きても拡張していけそう。

BLEで制御できるのが便利。いろいろ活用の仕方がありそうで、そのへんにあるRaspberry Piに母艦をやらせて、micro:bitをセンサ付きビーコンとして家とかオフィスにばらまくとかするとおもしろい?

年末年始のひまつぶしにはちょうど良いので、近所の電子部品店になどで購入しましょう。京都のマルツにはまだもうちょっとありました。電池ボックスが地味に便利なのでスターターキットがおすすめです。

BBC micro:bit go スターターキット リテールBOX(CFD販売 6ヶ月製品保証付)

BBC micro:bit go スターターキット リテールBOX(CFD販売 6ヶ月製品保証付)

micro:bitではじめるプログラミング ―親子で学べるプログラミングとエレクトロニクス (Make:PROJECTS)

micro:bitではじめるプログラミング ―親子で学べるプログラミングとエレクトロニクス (Make:PROJECTS)

  • 作者: スイッチエデュケーション編集部
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2017/11/25
  • メディア: 単行本（ソフトカバー）
  • この商品を含むブログを見る

Real World HTTP を読んだ

技術書レビュー

そんむーさんもおすすめの Real World HTTP を読んだ。たまには現代的なHTTP周辺の技術をおさらいして安心したいという気持ちで読み始めた。

Real World HTTP ―歴史とコードに学ぶインターネットとウェブ技術

Real World HTTP ―歴史とコードに学ぶインターネットとウェブ技術

著者の紹介 にもあるように、Web API: The Good Partsとハイパフォーマンスブラウザネットワーキングの間を補完する内容で、HTTPとその周辺技術をかなり網羅的に紹介してくれている。

自分がWebアプリケーションを書き始めたころは、例えばフォームをsubmitした時のrequest bodyには実際にどういうデータが入っているのかとか、基本的なことが学ぼうとすると意外と情報源がなかった気がする(結局LWPの実装読んだりしてた思い出)。この本は、そういったHTTPの基本的なことも歴史を辿りながら丁寧に紹介していってくれる。

最近の新しいHTTP関連技術についても網羅的にとりあげられている。現代的な技術をおさらいしたかった自分にはちょうど良くて、あまり良く知らない部分を認識できた。HTTPライブストリーミングとかよく知らなかった。

ところどころGoでHTTPの機能を実装してみてみるコーナーも、実装を見ることで具体的な技術のイメージができてよかった。HTTPのプロトコルUpgradeなんかは実装をみるまでいまいちイメージできなかったので、とてもためになった。

最近のHTTP関連技術の見取り図がほしいという人にはぴったりという感じの本だった。個々の技術についてはさらっとした紹介になっているところがあるものの、参考資料への参照がしっかりしているのでこの本からスタートして学ぶことはできそうである。HTTPの基本を学ぼうとしているひとにもおすすめできる。そうでなくても普段からWebアプリケーションを書くときに辞書的にそばに置いておくと良さそう。