昨年から書いていたReal World HTTPがAmazonのページに表示されるようになりました。最初にコミットしたのは昨年の8/1ですが、たぶん、その数ヶ月前から書き始めていたと思うので、ほぼ丸一年です。途中でASCII.jpのシステムプログラミングの連載が始まったり、Software DesignにSphinxについて寄稿したり、もう１つ別の翻訳の企画があったり、三女が7/4に生まれたり、なかなかハードな一年間でした。
なお、表紙は皆さんが知っているものとはちょっと違うのですが、系統的に一番近いのがハシビロコウさんらしく、和名もそれしかないそうです。狙っていたわけではなく、そもそも出版時期にはアニメも終わってしまっているし、話題の動物は辞めたほうが良さそう、という話をしていたのですが、偶然これが選ばれました。
本の内容の紹介
裏表紙の紹介はこんな感じです。
本書はHTTPに関する技術的な内容を一冊にまとめることを目的とした書籍です。HTTP/1.0、HTTP/1.1、HTTP/2と、HTTPが進化する道筋をたどりながら、ブラウザが内部で行っていること、サーバーとのやりとりの内容などについて、プロトコルの実例や実際の使用例などを交えながら紹介しています。 GoやJavaScriptによるコード例によって、単純なHTTPアクセス、フォームの送信、キャッシュやクッキーのコントロール、Keep-Alive、SSL/TLS、プロトコルアップグレード、サーバープッシュ、Server-Sent Events、WebSocketなどの動作を理解します。 これからウェブに関係する開発をする人や、これまで場当たり的に学んできた人にとって、幅広く複雑なHTTPとウェブ技術に関する知識を整理するのに役立ちます。HTTPでは日々新しいトピックが登場していますが、本書によって基礎をしっかりと押さえることは、さまざまな新しい技術をキャッチアップする一助にもなるでしょう。
目次はこんな感じです。
- HTTP/1.0 のシンタックス:基本となる 4 つの要素
- HTTP/1.0 のセマンティクス:ブラウザの基本機能の裏側
- Go 言語による HTTP/1.0 クライアントの実装
- HTTP/1.1 のシンタックス:高速化と安全性を求めた拡張
- HTTP/1.1 のセマンティクス:広がる HTTP の用途
- Go 言語による HTTP1.1 クライアントの実装
- HTTP/2 のシンタックス:プロトコルの再定義
- HTTP/2 のセマンティクス:新しいユースケース
- Go 言語による HTTP/2、HTML 5 のプロトコルの実装
- セキュリティ:ブラウザを守るHTTPの機能
- クライアント視点で見るRESTful API
内容としては、HTTP/1.0、HTTP/1.1、HTTP/2というおおざっぱな期間ごとに次の３つの章を繰り返してその時期に登場した技術のトピックをいくつか紹介し、最後にセキュリティとRESTfulの章が追加されている感じです。
- HTTPのシンタックス
- HTTPのセマンティクス
- 実際にコードを書いて試してみる
実際にはHTTPのバージョンは時期的な目安なので、そこまで厳密ではありません。消化不良にならないように読みやすく分割するための分け方です。人間の記憶はエピソードとともに知識を固定する方がやりやすいので、そういったことを心がけています。普通のHTTPのプロトコルの技術的紹介だとなかなか詳しく紹介されないであろうトピック（TLS、認証／認可、セマンティックウェブのその後、セキュリティを守るためのブラウザ技術）についても、多くの方々の強力なバックアップのもとに概要をきちんとつかめるように書きました。
アプリケーション開発だと、ウェブに関係しないシステム自体がだいぶレアになってきているので、かなり多くの人に末永く参考にしていただけるのでは、と思っています。CGI時代やJ2EE初期時代に学んだ人も、その後の知識のアップデートに役立てていただけると思います。最新のブラウザの機能（セキュリティのヘッダーとか）も、過去の経緯や機能を踏まえて追加されることがほとんどです。一通りきちっと学ぶことで、今後出てくるトピックを追いかけるのがとても楽になるはずです。「読める！読めるぞ！」とムスカになったような感動が味わえるはずです。
後は、書いていてワクワクしていたポイントは、HTTPまわりの仕様にはさまざまなエンジニアリングの創意工夫があることです。後方互換性を維持するしくみとか、サーバー・クライアントでベストな選択肢を選ぶ方法、効率の改善。こういうところに着目して読んでもらえると（上級者には）楽しいと思います。
なぜ書こうと思ったのか
書き始めたきっかけは、cURL as DSLというツールの開発です。現在ではウェブ上の資料も充実してきて、本がなくても調べる難易度が下がっていますが、書こうと思った当時はGo言語でREST APIのクライアントを書く情報がまとまっていませんでした。curlコマンドの使い方やJSONのパースなども含めて、Go言語のネットワークプログラミングを一冊で理解できる本とか面白いのではないか？と思って書き始めました。しかし、書く以上は言語が変わっても使える知識がきちんと伝わる本にしよう、と思ってウェブの知識をいろいろ補完する内容を増やしていきました。
この時点では100ページちょっとの電子書籍の予定で、夏ぐらいにはだそうと思っていました。しかし、ウェブの基礎知識というのが結構厄介で、インターネット上に書かれている内容は玉石混交で、すでに古くなった内容や、今ではバッドノウハウでしかないことがベストプラクティスであると喧伝されている例も数多くあります。徐々に、Goの本から離れて、ウェブの基礎知識の内容が増えていきました。間違ったことを書いてはいけないので、RFCとにらめっこする日々でしたが、現代のブラウザ技術というのは、かなり複雑で、いろいろなレイヤーを理解しないと把握することすら困難です。新しい技術やら、セキュリティのニュースやらは流れてきますが、なんとなく雰囲気で「ふんふん」とわかった気になっている人も多いのではないでしょうか。僕もそういう所が多かったな、と書きながら思い知らされました。
Sphinxで書いていましたが、当初予定の夏頃にはPDFのページ数がどんどん増え「なかなかゴールが見えてこないぞ」という状況が続きました。1つの機能の紹介を書くにも、一週間から数週間はかかりました。とはいっても、つらいとか、うんざりとかはなくて、「この仕組の裏側はどういうヘッダーがやりとりされているんだろうか？」と、どんどん好奇心が湧いて収められなかった、という感じです。他の執筆と並行で走っていた時期があったとはいえ、ずーっとワクワクしながらRFCやらW3Cの仕様を見たりしていました。
年が明けるころには300ページを超える見込みになり、改めて企画会議をやり直して、紙の書籍として本屋に並ぶ運びとなりました。「Real World HTTP」というタイトルや、「ブラウザ視点でユーザーから見える機能の裏側を解説する」というコンセプトが決まってからは、構成が散らからずにうまくまとまる方向で原稿が転がりました。章内の各項目は比較的独立しているため、興味のあるところをつまみ読みもできる構成になっています。自分が知りたいことを集めて書いた本なので、ゲラが上がってレビューをするのも「すごい！このPDFには自分が知りたかったことがいっぱい書いてあるぞ！」と楽しく何度も読めました。
書く時に心がけたこと
まずは書かないことを決めました。ブラウザを扱いますが、JavaScriptのUIレイヤーは扱わないことにしました。Mithril本で扱ったレイヤーです。Reactが勝ちつつありますが、Fluxレイヤーまわりのゴタゴタが落ち着くまでは手を出すつもりはないです。Mithrilは1.0が出て、アグレッシブにダイエットしてきているので、Mithril本のアップデートは今後考えたいところです。
あとは、サーバーサイドの設計についても考えないことにしました。ちょうどオライリーには水野さんのWeb API: The Good Partsがあります。また、マイクロサービスが出てきて、デプロイの戦略も一緒に考えないといけない感じになってきており、手広くなりすぎます。また、低レベルの通信に関しては、これまたオライリーのハイパフォーマンスブラウザネットワーキングがあり、僕の技量的にもあれは絶対超えられないので、そこはスルーすることにして、この二冊の間をカバーするということにしました。
書籍にするにあたっては、現代で使われてなくて覚えるだけ無駄となる機能というのは極力排除し、現在でも使われているもの、あるいはその礎となったものをきちんと網羅するように書いていきました。書籍というメディアには得意なところと不得意なところがあります。電子書籍になってライフサイクルが変わりましたが、紙を前提とするとバージョンアップが頻繁なものは取り上げるのが大変です。また、辞書のように網羅性をとことん高め、検索もできる、というものはウェブの方が得意です。単なるRFC集ではなく、エピソードでイメージが想像しやすいように構成しています。超長文となると、ウェブよりも書籍の方が読者体験をデザインしやすいメリットがあります。途中「こんなに時間かけてもいいのかな？他の人が同じ内容で先に出してしまわないかな？」と（HTTP特集がSD誌やWeb+DBの予告に乗るたびに心配になったりもしましたが、編集をしてくださった瀧澤さんからは「一人の著者が、１人のブレない視点で内容をまとめるということ自体にも価値がある」と言ってくださいました。
ローカルの執筆環境としてはVimでSphinxです。gitlab CIでepubとPDFをビルドするようにしていました。こちらのchezouさんによる「Gitlab CIを使ってSphinxのドキュメントを自動でPDFにビルドする」のイメージを使わせてもらいつつ、Sphinxは最新のmasterをぶっこむビルド構成にしています。ちょうど昨日、@tk0miyaと@shimizukawaの不断の努力によってSphinx 1.6.1がリリースされましたが、このリリースはepub checkの警告とエラーが激減（Sphinx本体のドキュメントはゼロ）しています。自分の本の原稿とSphinx自身のドキュメントを題材にエラーを潰してコミットしまくっているうちにコミッターに推薦されてコミッターにもなりました。O'Reillyさんの中のフローは今まで通りですが、epubからkindlegenでKindleのファイルを生成することも可能になったりもしたし、Sphinx自身も今後、同人活動やら出版に活用できるように頑張っていきたい所存です。
あと、今回はAmazon Pollyを執筆に活用しました。Sphinx拡張を作り、段落ごとにMP3化して、最後にファイル単位のMP3を作成しています。レビューというのは視点を変えるのが大事です。紙で印刷して見る、というのも視点を変える方法ではありますが、今回はAmazon Pollyで音声ファイルにして耳で確認する方法にしました。助詞間違いとかは耳で聞くとすぐ分かりますし、文章の繋がりが悪かったり、定義を説明せずに先に行ったり、文章の内容が飛んだりといったことがかなり拾いやすくなります。一冊を全部音声化すると15時間ぐらいになりますが、通勤時間などで繰り返しレビューしてました。有料API（無料枠がでかいので実質かかりませんでしたが）はCIでは利用せず、ローカルで必要に応じて作っていました。「サーバー」「ヘッダー」など、長音をなるべく付けるようにしたのは、音声合成との相性によるものです。ついでに好きな声優の声とか選べるとうれしいです > Amazonさん
耳でレビューで気づいたのは、1.2倍速ぐらいまであれば細かい文法を気づけるんですが、それ以上になると文法ミスの発見には不向きということですね。ただし、説明していない概念が突発的に来たぞ、とか、大きな流れのデバッグには1.5倍速ぐらいでもいけました。2倍速ぐらいになると間違いとかまったく関係なく意味だけが流れ込んできますね。高速音声で洗脳とかできそうだなってちょっと思いました。
これまで関わってくださった多くの方々に感謝
ウェブの開発はあまりにも普遍化してしまったので、もはや誰に何を教わったかも思い出せないぐらい、ずっと過去からいろいろな人に教わってきたことがこの本には入っています。Twitterでのちょっとしたやりとり、Qiitaのコメント、社内外の人とのSlackの会話、会社での雑談や立ち話。もちろん業務を知りながら学んだことなど、細かいものも含めればきりがありません。謝辞には本書に対する直接的な貢献をしていただいた方々の名前を入れていますが、僕と技術的な会話した人はほぼ例外なく入っていると思っていただけると幸いです。また、直接会ってない方々でも、いくつか本文から参照させていただいたウェブサイトやスライドなどで助けていただいた方もたくさんいます。この場を借りて感謝申し上げます。
特に、この本の「こんなところまで知ることができる！」というカバレッジを上げるウリであるところのTLS、セキュリティ、認可・認証まわりは、僕にとってもチャレンジングでした。その分野の専門の人達にレビューしてもらい、安心して読めるものになったと思います。ラムダノートのプロフェッショナルSSL/TLSはもっと早く読みたかったですね（購入して速攻読んで今後読むべき本として紹介しています）。
子供もいるので、土日はなるべく家族の時間としていますが、去年は並行でいろいろやりすぎたのもあるので、もう少し余裕を持ちたいところです。家族にも感謝。いつ書いているの？とよく聞かれるんですが、執筆と仕事と子供と遊ぶ以外はほとんどしてません。テレビもほとんど見ず（SHOW BY ROCK!!#を除く）、ゲームもほとんどやらず（SHOW BY ROCK!!を除く）、コンピュータ以外の本もほとんど買わない（SHOW BY ROCK!!#オフィシャルブックを除く）ですが、子供の成長を見るのが趣味となっています。4歳の長女はバランスバイクのおかげで転ばずに一発で自転車乗れるようになったり、インラインスケートで1.5m間隔のパイロンのスラロームもできるようになったし、英単語勉強しているし、先日3歳になったばかりの次女もスケートを始めました。両親の子供時代よりも着実に小さい頃からいろんなことができるし、子供にいろいろなチャレンジを楽しく提供するのが楽しみです。