トップ «前の日記(2015-12-20) 最新 次の日記(2015-12-25)» 編集

日々の破片

著作一覧

2015-12-21

_ APIデザインケーススタディ読了

RubyKaigiの前日に技評の方からダウンロード版のダウンロード権をいただいたので(ありがとうございます)、最初半分ほど一気読みした後しばらく寝かせて今読了した。

本書はRubyが持つAPIについて(田中さんが修正したり追加したりしたものを中心に、というか全部なのかな?)なぜそうしたのか、そのためにはどういう制約なり考慮があったのか、その結果どうだったのか、といった事例集だ。パターン集のようには抽象化されていなくて、題名通りケーススタディなので具体的だ。

おもしろかったし、教訓にあふれている。

以下の人は読む価値がとてもある。

・Rubyプログラマ (ここで紹介されているAPIのうち、おそらく半分は使わないかも知れない。しかし田中さんのAPIデザインに対する影響力を考えれば、コアAPIや添付ライブラリのAPIを使う場合に、持っていると便利なお約束というか考え方を知ることができる。これはプログラミングにあたって大きなメリットとなる)

・ライブラリ作成者 必読でしょう

・API設計者 必読でしょう

・技術読み物好き 文句なくおもしろい。4章は歯ごたえがある。

・Ruby以外のプログラマ よほどどうしようもないものならともかく、どのプログラミング言語にもその言語やライブラリの設計者がいて、暗黙知として、本書で解説しているようなことを考えて設計している可能性は高い。したがって、読めば役に立つはず。

まず帯の惹句が良い。「想像上ではなく、実際の問題をどう解くか?」だ。ライブラリかくあるべしという理念とか方法論を考えるのはできるが、実際に広く利用されているプログラミング言語の標準あるいは添付ライブラリのAPIにデザインを反映させて、フィードバックを受けたりした結果の考察なので、書いてあることには重みがある。

一部はこれまでのRubyKaigiなどで発表した内容だったりする(例:Unix修正主義)が、あらためて項目別にまとまっていると読みごたえがある(open-uriについてのプレゼンを聞いた覚えがあって、あれも面白かった記憶があるのだが、出ていなかった)。

短いが最初のまつもとさんの前書きでは「楽しいプログラミング」という気持ちの問題をスローガンにしているが、それはまさにデザインの問題で田中さんの貢献の大きさという点に触れている。

続く田中さんの前書きは、「使いやすい」とは何か? についての考察。これはいろいろな考えの種子になる良い前書き。

全体は5章で、1章がIO、2章がソケット、3章がプロセス、4章が時刻、5章が数、文字列。

僕は最初から順に読んだが(でも目次を読んでおもしろそうだったので、というよりもそんなメソッドを知らなかったので5.02のInteger#nonzero?だけは最初に読んだけど)、もちろん読み手に依存するだろうが、その読み方はあまり推奨しない。

3種類のスタンスの読み方があると思う。

・ライブラリ作者のスタンス(なるほどそうデザインするのか→いやおれならこうするor今度はそうしてみようorがーん考えもしなかった)

・ライブラリ利用者のスタンス(なるほどだからそういうデザインなのか→だが使いにくいぞorだから使いやすいのかorなんのことかわからない)

・もう少し抽象度を挙げたインターフェイスデザイナーのスタンス(ふむ→ふむ)

で、まあ、2のスタンスで読むのが楽だし(というのは、引き付けて読んで考察しやすいからだ)、60%はそういうスタンスで読むのが良いと思う(おれはなんとなく、20:30:50くらいのスタンスで読んでいたが、この読み方だとTimeは読んでいていやになる。で、そこでは50:40:10くらいに変えた)。

すると、必然的にライブラリ内部の動きよりも実際に使った場合のことを想像しやすい(というよりも実際に使っていることが多く、しかも内部処理をあまり知らずにすむ)5章の数・文字列を最初に読むのが良いと思う。そして2章に進む。2章はアドレス用のオブジェクトを追加することで、ソケット処理全体がどれだけ一貫性を持つようになったかというわかりやすいストーリーがあるからだ。

3章も勉強になる。Open3には似たような名前で何が違うか良くわからないメソッドがpoepn2とpopen2eとpopen3とたくさんあっておれは避けていたのだが、実はおれが良くわかっていないのはUnixのプロセス生成/実行のお約束であって、なぜそうなのかがクリアに説明されていた。この章は純粋におもしろい。

1章はCのstdio.hとio.hの世界で、バッファの部分は読んでもぴんと来ない人もいそうな気がするが、EOFのあたりは普通におもしろいと思う。この章を読むと、なるほどAPIデザインというのは広範なバックグラウンドと知識を駆使した精緻な作業だなとちょっと感動的になるかも知れない。

で、4章が時刻だ。読んでいて、日本は2~3回、太陰暦と太陽暦の辻褄合わせをしたはずだが、そのあたりはサポートされているのだろうか? あるいはサポートする意味あるのだろうか? とかいろいろ余分なほうに考えが向かった。確か信長が馬を揃えて京都で軍事示威行動したときが変わり目の一つだったような記憶があるのだけど。Bignumがあるので、いくらでも負の方向に日付が遡れるというのはなかなか難しい問題を含んでいるのだなぁというのが正直な感想である。


著者のサポートページ

writeとwirteの誤記を見て、C#の数値サフィックスを思い出した。

0Lはlongの0となるわけだが、0lと書くと警告を受ける。サフィックスは伝統的に大文字小文字両方認めるわけだが、あえて小文字のlを使うのはよろしくないということだ。

warning CS0078: 'l' と 数字の '1' との混同を避けるため、'L' を使用してください。

お節介だとも思うが、Rubyもこのレベルまで踏み込んでも良いのかも知れない(-wとかーvを付けた時は。でも具体的に何について出すのが良いのだろうか。andやorが単体で使われたら&&や||を使えとかかなぁ)

APIデザインケーススタディ ~Rubyの実例から学ぶ。問題に即したデザインと普遍の考え方 (WEB+DB PRESS plus)(田中 哲)


2003|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|

ジェズイットを見習え