Web API: The Good Partsを読んだ

Web API: The Good Parts

この本は良い意味で期待通りだった点と、悪い意味で期待通りだった点、そして良い意味で期待を裏切られた点が一つずつある。

まず期待通りだった点。

プログラミングにおいて一貫性はとても重要だ。中途半端に正しいくらいなら、おかしな方法で一貫している方がまだましではないだろうか。

タイトルからも分かるように本書は Web API を扱った書籍だ。Web API はその対象が社内などの一部の人に公開される場合と、広く一般に公開される場合の二通りがあるが、いずれにせよ世間で受け入れられている慣習があるならそれに従う事が望ましい。独自のルールは極力排除すべきである。

だから Web API を実装するときは、他のサービスでどうしているかが重要になってくる。そういうことが書いてあると思っていたら実際そういうことがたくさん書いてあった。だから Web API を設計する前にこの本を確認すれば、我が社だけの独自ルール、みたいなのを避けることができるだろう。

この本が出版された 2014 年は REST 全盛の時代だったので、この本も基本的に「皆 REST だから REST でいこう」というスタンスなのだが、それが悪い意味で期待通りだった点。目次を見ると 2章 9 節で HATEOAS に触れているが、軽く触れているだけで「時期尚早」みたいな感じで終わっていた。この点については悪い意味で期待通りだった。

ついでに言えば、最近 Web API 界隈を賑わしている GraphQL は 2015 年発表なので、当たり前だけど 2014 年発売の本書にはその影も形も出てこない。もし GraphQL の話を期待しているのであれば他を当たるしか無い。

そして良い意味で期待を裏切られた点。それは HTTP の仕様やブラウザの動作について結構なボリュームで書かれていること。

Web API は当然ながら HTTP を使って提供する。その HTTP についての説明が意外と厚い。キャッシュの話とか、セキュリティの話とか。メディアタイプの歴史的経緯の話とか知らなかったので面白かった。

そういう意味で「Web API: The Good Parts」っていうタイトルは、たしかにその通りなんだけど、読者を狭めているような気がした。逆に言えば「API とか書かないから俺は読まなくていいや」と思っている人も、 Web に関わっているなら読んでみてもいい。技術評論社の「Web を支える技術」と内容的には近いと思う。

いい親になりたい

半年前に父親になってから、「子どもが生まれて何が変わった？」とたびたび聞かれる。そのたびに振り返って、あれも変わったな、こういう変化があったなと発見するのだけど、今日気がついたのは「育児書を読むようになった」ということだ。

これまでは専ら小説を読むことが多く、勉強のために技術書を読むこともあった。今でもそういった本を手に取るが、しかし、そこに育児書という第三勢力が割り込んできたのは、父親になったという出来事を象徴する一つの大きな変化だと思う。

なぜ育児書を読むのか。一言でいえば愛しい我が子にとって出来る限りいい親になりたいと願うからだ。

ではそもそも「いい親」って何だろう？もうこれは本当に人それぞれで、それこそ親の数だけ答えはあるのだろうけれど、今現在僕の心の中では「子どもへのまなざし」の次の一節が残っている。

子どもの精神科の医者として、お母さんやお父さんにお願いしたいことは、子どもの笑顔や喜ぶ姿に、ご自身が喜べるご両親であってほしいということです。親の希望どおりのことを、子どもがしてくれることに喜びを感じるのではなく、子どもの希望にこたえられることに、幸福を感じられる親であってほしいということです。

子どもへのまなざし (福音館の単行本)

俵万智さんの言葉を借りれば、この本を読むと、子どもと向き合うとき、どんな心の持ちようでいればいいのか、その一番大事なことを教えてもらえるような気がする。あるいは答えはすでに心の中にあって、それの輪郭を的確に言語化してくれただけなのかも知れないが。

ちなみに、この本を読むのは妊娠中あるいは乳幼児の時期にしておいた方がいいかも知れない。というのも、乳幼児の時期が人生の土台を作る時期であり、土台がダメだと上にどんな建物をたててもすぐ壊れる、みたいな比喩が何度か出てくるからだ。（全然そんなことはないのだけど）もう手遅れなのか、、、と思ってしまうかも知れない。

「RDB技術者のためのNoSQLガイド」を読んだ

Qiita ぐらいの規模のサイトを開発していると、どうしてもデータ量の上限はたかが知れてくる。圧倒的なトラフィックをさばくために日夜格闘するということはないし、データベースが厳しくなってきても RDS のスケールアップで十分に対応できてしまう。そんな感じなので NoSQL といっても Redis をキャッシュ目的で使うくらいのことしかしたことがない。

僕はエンジニアは知っていることが大事だと思っている。ハンマーしか持っていない人は全ての問題を釘だと思ってしまうように、ブラウザ上でのプログラミングしか知らない人は何でもブラウザで解決しようとしてしまうかも知れない。

そういう観点で言えばデータベースとして RDB しか知らないのは非常にまずいことだと思う。簡単な話がデータを永続化するとなったら何も考えずに RDB を選んでしまうのではないか、ということだ。もちろん RDB の向き不向きはある程度把握できているつもりなので、向いていないことに RDB を使うことはないと思うが、RDB でも悪くはないけど…というような場面でより better な選択肢を選択できないのではないか。一度 RDB の外の世界を包括的に学んでみるべきなのでは？

そんな感じのことを考えて、この本を読んだ。

RDB技術者のためのNoSQLガイド

NoSQL はバズワードであり、その実態は多種多様だ。本書では大雑把に KVS, ドキュメント DB, グラフ DB という分類を扱っているが、これらを

• ターンアラウンドタイム重視なのかスループット重視なのか
• スケールするのかしないのか（≒扱っているデータモデルの複雑さ）

という 2 軸で分類することで RDB との関係性を説明している。ここは「RDB技術者のための」とうたうだけあって、結構分かりやすかった気がする。

特に関心したのが、各種 NoSQL プロダクトが機能拡張で今までできなかったことができるようになり境界線が曖昧になってきていることを指摘したうえで

このように、実際のデータベースは生まれたエリアから出ようと必死です。（略）しかし忘れてはいけないのは、それぞれのデータベースの根幹がどの分野にあるかです。どんなに枝葉を広げて着飾っても、アーキテクチャの根幹を変えることはできないため、枝葉の機能は中途半端になるでしょう。

p.87

という箇所。これは本当にその通りで、RDB で言えば B+ 木というデータ構造をインデックスを使っている限り、 B+ 木でできないことはどんなに頑張ってもできないのだ。それと同じで、各種 NoSQL がもともともっているデータモデルの限界は、それ自体を捨てない限りやはり大きな課題としてついてまわる。逆に言えば、そういう基礎的なところの理論を抑えれば、息の長い知識になるということでもある。

みたいな抽象的な話があったあとで、

• Redis
• Cassandra
• HBase
• Amazon DynamoDB
• MongoDB
• Couchbase
• Microsoft Azure DocumentDB
• Neo4j

という各種データベースの具体的なデータモデルについて 1 プロダクト 1 章という分量でひたすら紹介されていく。そもそも本書はこれまで RDB しか触ったことがない SIer の人が技術選定する助けになることが主題となっている。一人の著者が全部紹介しているのではなく章ごとに対応するデータベースのスペシャリストの人が担当していたり、機能要求だけでなく非機能要求にも着眼して全てのプロダクトで同じ項目について言及していたりと、 NoSQL を銀の弾丸として扱わない誠実な印象を受けた。

1 つのプロダクトについて詳しく知りたいのであれば、それのドキュメントを読むのが一番いいが、この本では一段抽象化された立場から各種データベースを横串で比較できるように書いてくれているので、それぞれの違いが際立って見えてくる。気がする。

簡単な CRUD 操作のやりかたも解説されているが、この点に関しては中途半端なのでだいたい読み飛ばした。

2016年出版なので多少の陳腐化は始まっているはず。しかし、↑でも書いたように、大事なのはそのコアになっているデータモデルやアーキテクチャだと思う。そういう意味で、深く知るには足りないが、概要を把握するにはいい本だと思った。

ひとまず、データベースを選定する必要がでてきても、何も考えずに「RDB にしとくか」とはならない程度の知識は得られたと思う。