0014 号 巻頭言

初稿：2006-05-15

全部読む。

Rubyist Magazine 第 14 号をお届けする。

今号は、 須藤さん・卜部さんをまじえた角谷信太郎さんへのインタビューとなった「Rubyist Hotlinks 【第 14 回】 角谷信太郎さん」、CGI のエラーの分類とそのデバッグ方法を述べた「Ruby ビギナーのための CGI 入門 【第 3 回】 エラーの修正」、高木さんが最近 Rails 方面で話題になっている RJS テンプレートを謙遜気味に説明する「RubyOnRails を使ってみる 【第 7 回】 RJS を使ってみる」、qwikWeb のプラグインについて、簡単なサンプルから POV-Ray の埋め込みまで紹介する「qwikWeb の仕組み 【第 3 回】 ページの一部分だけ編集できるようにしてみる」、RGSS から EGRS を経て、さらなる展開を目指す Miyako について触れる「Miyako の風 〜夢を捨てきれない人たちへ (笑)〜」、比較的マイナーな言語にいどむ連載として Icon を失敗判定とジェネレータを中心に取り上げる「Rubyist のための他言語探訪 【第 7 回】 Icon」、ありがたい方々のおかげで続けられる好評の「0014 号 読者プレゼント」、さらに本誌初の試みとして「求人情報：ザーグソフト」、そして「0014-RubyNews」・「0014-RubyEventCheck」と、いくつか連載をお休みさせていただいたのはさておいても盛りだくさんの内容となっている。

既報の通り、現在、日本 Ruby カンファレンス 2006 の準備を進めている。 日本 Ruby カンファレンスの詳細は Web サイトに詳しい。 私はカンファレンス冒頭で、Rubyの歴史について話す予定なのだが、その準備をしている際に一つ思い出したことがあったので、そのことについて書く。

私が Ruby のことを積極的に調べようと思ったのは、あまり記憶にないのだが、1998 年ごろだったはずである。 調べるにあたっての情報源は当然ながらネットであった。 そのころでもすでにインターネット上に Ruby のリソースがあったのだが、当時のリソースとしては Web ページそのものはそれほど重要なものではなかった。 そもそも「ruby-lang.org」のドメインもなかった時代である。 Web 上にあった最重要かつ最大の情報源は、原さんによる ruby-list のメーリングリストアーカイブであった。

当時は今ほど忙しくはなかったので、メーリングリストのアーカイブファイルをダウンロードしてローカルで読んだり、直接 Web サイトを w3m で読んだりしていた。 当初は読み始めた時期の前後の記事を読んでいたが、そこからさかのぼり、結局は全ての アーカイブを読むことになった。

この、「とりあえず全部読む」、というやり方は非常に強力である。 なにせ、全てを読むのである。 理解しているかどうかはともかく、一度は全て目を通していることになる。 これは強い。 もちろん、一度読んだだけでそこに書かれていた事柄を使いこなせるようになることはそうそうないだろう。 いや、そういう人も少数ながらいるのかもしれないが、少なくとも私には無理である。 しかしながら、例えば別の場所でそのことが必要になったとき、「そういえば読んだことあるかも」程度には思い出せることもある。 そうすれば、記憶を頼りにもう一度探し出し、運がよければ目指す情報が見つかるだろう。 もし見つけられなかったら、そのときは運が悪かったか、たいして重要ではなかった、とほうっておけばよい。 もちろんここでもう一度、あらためて全部読んでみてもよいだろう。

あらかじめ断っておくと、この手法は特に目新しいものではない。 例えば、小山浩之さんは、Apache の理解のため、Apache の日本語ドキュメントを全部読むことを提唱している (「自信を持って Apache を操るために (InternetWeek2005 資料,PDF)」)。 そのこころはここでの話ともおおむね外れていないだろう。

「全部読む」という手法は案外多方面に応用可能ではないかと思っている。 この手法が効果を発揮する対象としては、以下の条件が考えられる。

  1. そのリソースの全体が入手可能である
  2. そのリソースの全体があまり大きくない

  3. そのリソースの全体は線形 (シーケンシャル) に読解できない、もしくは読解されることが想定されていない

  4. について補足すると、そもそも通読することが期待されているような、書籍などの文書であれば、誰でも特に疑問も持たずに全文を通し読みしているだろう。 ここで対象としているのは、リファレンスマニュアルや説明書、あるいは Wiki ページといった、本来的にシーケンシャルではない資料である。 これを読解するときの手法として、とりわけ威力を発揮する。

さらに、この手法はソースコードを読む技術にも応用可能である。 ソースコードを読む技法としては、「ひらメソッド」が提唱されている。 ひらメソッドは「2005_6_23カーネル座談会 (1) - 読学のススメ」に詳しいが、こちらは関数 (メソッド) とその呼び出し関係をノードと枝と考えると、そこから作られるグラフを深さ優先探索で全て探索し尽くすことと同じである。 一方の「とりあえず全部読む」手法では、ノード間の関係を無視して、すべてのノードを一回ずつ探索することに等しい。 このほうが全てをノードを辿るためのコストはあきらかに少ない。 もっとも、ひらメソッドの場合も、同じ関数が複数回呼び出されることは非常に多いので、2 回目以上の探索はそれほど時間がかからないことが期待できるが、それでも最後まで読み終えるには相当の時間がかかることが予想される。 それよりも、一度で理解することははなからあきらめ、ばんばん読み進めてみる、というのも、方法としてはありうるだろう。

この手法でたいせつなことは、「読む順番にこだわらない」ことと、「よくわからないところは適当に流して読んで先に進む」、ということである。 ソースコードは本来的にシーケンシャルなものではない。 無理にシーケンシャルに並べようとすると、たとえば Ruby であれば「Object クラスから継承関係をたどって読む」、といったことになりかねない。 しかし、ブルバキ好きならともかく、一般にはある程度具体的なクラスから読んだ方がイメージが湧きやすい。 とりあえず一回読めば全体がつかめる (こともある) し、つかめなければ二度、三度通読してみればよい。 最近の英語学習のトレンドで説明するなら、ひらメソッドが古典的な精読であるのに対し、とりあえず全部読むのは最近流行の「多読」に近い。 わからないところは読み飛ばし、あとで読み直せば理解が深まる、ということは、経験的にも納得できる。

さらにさらに付け加えて言うならば、その効果がたとえ薄かったとしても、全部を読むことには意義があると思う。 ソースコードにしろ ML アーカイブにしろ、人の手を介したものは何につけ先人の知恵と努力のいくばくかを含んでいる。 人は去ってもアーカイブは残る (思えば去年の今ごろはまさーるさんのことを書いていたのだった)。 遠くから眺めると莫大にみえるアーカイブでも、所詮はたかだか有限である。 一度は最初から最後まで、人々の軌跡に思いをはせながら読んでみるのも悪くはないと思う。

――もちろんこのことは、過去の号の Rubyist Magazine についてもあてはまる。 読者諸賢のご健闘を心よりお祈りする。