Previous Next Contents


2。 なにはともあれメールは通せ

1993年以来、ぼくはペンシルバニア州ウェストチェスターにある、 Chester County InterLink (CCIL) という小さな フリーアクセスISPの技術面を担当してた (ぼくはCCILの共同創設者 で、ぼくたちが使ってるユニークなマルチユーザBBSソフトを書いた。 興味があれば、locke.ccil.org に telnetしてみてほしい。 いまでは19回線で3,000人弱のユーザをサポートしてる) 。この仕事 のおかげで、CCILの56K回線を通じて1日24時間ネットにアクセスし 続けられるようになった――というより、仕事柄そうせざるをえな かったというのが実状かな!

そういうわけで、インターネットの電子メールがすぐに手放せなく なった。なんかややこしい理由で自宅のマシン (snark.thyrsus.com) と CCIL とでSLIP接続するのに手間取って、それがうまくいくと、 今度はしょっちゅうlockeにtelnetしてメールをチェックするのが えらく面倒になってきた。メールをsnark に配信してもらって、 新しいメールがきたらbiff(1) が報せてくれるようにしたかったわけ。

Sendmail の転送機能は使えない。snarkはネットにつないでないとき もあって、IPアドレスも固定されてないからね。SLIP接続経由で手を のばして、メールをローカルマシンに引っ張ってきてくれるような ソフトがほしかったわけだ。そういうソフトがあるのは知ってたし、 そのほとんどがPOP (Post Office Protocol) っていう簡単なアプリケーション・プロトコルを使ってるのも 知ってた。そして、確かにlockeのBSD/OSには、ちゃんとPOP3サーバ ソフトが含まれているではないの。

あとは POP3のクライアントがあればいい。そこでネットで探して みると、3つか4つ見つかった。しばらくは pop-perl を使ってたけ れど、これには当然あるべき(と思われる)機能が欠けていた。 とってきたメールのアドレスをいじくって、返信がうまくいくよう にするのができなかったんだ。

つまりこういうことだ。locke上の「joe」という人が、ぼくに メールを出したとする。このメールをsnarkにとってきて、それに 返信したら、メールソフトはsnark上の「joe」にそれを送って 悦に入っちゃうわけ。そんな人物はいないのに。返信アドレスを手で なおして、@ccil.orgを最後にくっつけてたんだけれど、これは すぐにえらい手間になってきた。

こんなのどう見ても、コンピュータがやるべきことだよね (実は RFC1123 のセクション 5.2.18によれば、これはsendmail が処理しなきゃいけないんだけど)。でも、既存のPOPクライアント はどれ一つとしてこいつがこなせなかった! というわけで、教訓その1:

1。よいソフトはすべて、開発者の個人的な悩み解決から 始まる。

これは自明のことかもしれない(昔から「必要は発明の母」って 言うし)。でも実際のソフト開発者ってのは、お金で横っ面はられて 自分では要りもしないし好きでもないようなソフトを一日中シコシコ 書いてることがあまりに多いんだ。でも、Linuxの世界ではちがう ――Linux界出身ソフトの質が、平均してすごく高いのはこのせい かもしれないね。

そこでぼくは、既存のものとタメを張るようなまっさらのPOP3 クライアントを書き上げるべく、即座にコード書きの渦中へ猛然 ととびこんだ――かな? ご冗談を! ぼくはまず、手元にある POPユーティリティをじっくりながめてこう考えた。「ぼくの欲しい ものにいちばん近いのはどれかな?」 というのも:

2。何を書けばいいかわかってるのがよいプログラマ。 なにを書き直せば(そして使い回せば)いいかわかってるのが、 すごいプログラマ。

――だからね。すごいプログラマを気取るつもりはないけど、でもそのまね くらいはしたい。すごいプログラマの大事な特徴の一つが、建設的な 面倒くさがりってヤツなんだ。評価してもらえるのは結果であって、 そのための努力じゃないってのがわかってるってこと。そして白紙から 始めるよりは、よくできた部分解からはじめたほうがほぼ絶対に楽。

たとえばLinusは、Linuxをゼロから書き始めたわけじゃない。386マシン 用の、小さなUNIXっぽいOSだったMinixのコードやアイデアを再利用する ところから始めてる。やがてMinixのコードは全部落とされたか、あるいは 完全に書き直された――でも最初のうちは、やがてLinuxとなるべき 赤ん坊のための簡単な囲いを提供してくれてたんだ。

同じ精神から、ぼくは既存のPOPユーティリティを探しに出た。そこそこ 上手にコーディングされてて、開発のベースに使えるようなヤツを。

Unix界では、ソース共有の伝統のおかげでコードの再利用が昔から とってもやりやすかった(このせいでGNUプロジェクトは、UnixというOS そのものついては、かなり不満を持ってたんだけれど、ベースOSには Unixを選んだ)。Linux界は、この伝統を技術的な極限にまでつきつめ てる。だれにでも使えるオープンなソースコードが、何テラバイトも ある。だからだれかほかの人の、ほとんど使いものになりそうな コードを探すのは、Linuxの世界ではほかのどこよりもすごくいい結果 をうみやすい。

ぼくの場合もそうだった。もう一度探しに出た結果、最初に見つけた のとあわせて候補が9個あがってきた―― fetchpop、PopTart、get-mail、 gwpop、pimp、pop-perl、popc、popmail、upop。最初に落ち着いた先 はSeung-Hong Ohのfetchpopだった。ぼくは自前のヘッダ変更機能をそれ に加えて、その他いろいろ改良を入れた。作者はそれを受け入れて、 1.9リリースに含めてくれた。

でも数週間たって、Carl Harrisのpopcleintのコードに出くわして、 困ったなと思った。fetchpopはなかなかいい独創的なアイデア(たとえば daemonモードとか)が入ってたんだけれど、POP3しか扱えないし、 コードもいささか素人くさかった(Seung-Hongはプログラマとして 才能はあるけれどまだ駆け出しで、その両方の特徴がfetchpopには 出ていた)。Carlのコードのほうが優れていて、プロ級のしっかり したものだったけれど、大事なのに実装が面倒なfetchpopの機能が いくつか架けていた(ぼくがコーディングした機能も含め)。

このままいくか、乗り換えるか? 乗り換えたら、開発ベースは よくなるけれど、かわりにこれまでのコーディングは全部捨てること になる。

実際問題として、乗り換える理由の一つに複数のプロトコルが扱える 点があった。POP3はpost-officeサーバプロトコルで一番普及はしている けれど、唯一無二ってわけじゃない。Fetchpopをはじめとする競合ソフト は POP2もRPOPもAPOPも扱えなかったし、ぼくのほうではIMAP (Internet Message Access Protocol、一番最近に設計された、最強のpost-office プロトコル) のサポートを入れたらいいかもしれないな、なんてことを すでにおもしろ半分で考え始めていた。

でも、乗り換えたほうがいいかもしれない理論的な根拠もあった。 これはぼくが、Linuxよりずっと前に学んだことでもあ驕Bこういうこと だ:

3。捨てることをあらかじめ予定しておけ。どうせいやでも 捨てることになるんだから(Fred Brooks『人月の神話』 1

あるいは言い換えると、一回とりあえず解決策を実装してみるまでは、 問題を完全には理解しきれないってこと。二回目くらいになってやっと、 正しい解決法がわかるくらいの理解が得られるかもしれない。だから ちゃんとした問題解決をしたいなら、少なくとも一回くらい はやりなおす覚悟はしておくこと。

ま、(と独り言)fetchpopの改良が一回目だったわけだ。というわけで、 ぼくは乗り換えた。

最初のpopclient用パッチを1996年6月25日にCarl Harrisに送ったんだ けれど、実はかれはしばらくまえに、popclientに興味をなくしているこ とがわかった。コードもほこりをかぶってる状態で、ちょっとしたバグ も残ったままだったし。こっちとしては、いろいろ変えたいところも あった。だから、ぼくがこのプログラムを任されるのがいちばん 理にかなってるということで、両者はすぐに合意した。

自分でも気がつかないうちに、プロジェクトは拡大したわけだ。もはや ぼくは、既存のPOPクライアントにちょっとパッチをあてるような話を してるわけじゃない。プログラムをまるごとメンテする作業を引き受けて たんだ。そして頭の中ではいろいろアイデアも湧いてきていて、これを やったら大幅な変更が必要になるな、というのもはっきりしてた。

コード共有を奨励するソフト文化にあって、これはプロジェクト発展 の自然な道筋ではある。ぼくは次の原理を実践していたことになる:

4。まともな行動をとってれば、おもしろい問題のほうから こっちを見つけだしてくれる。

でも Carl Harrisの行動のほうがもっと大事だ。かれが理解していたこと:

5。あるソフトに興味をなくしたら、最後の仕事とし てそれを有能な後継者に引き渡すこと。

なにも相談なんかしなくても、カールもぼくも、自分たちがこの世で 最高の問題解決方法を実現するという共通の目標を持っていることが わかっていた。二人にとって唯一の問題は、ぼくがこれを安心して任 せられる人物だってことを証明できるかということだけだった。それ を実証してみせたら、かれはすぐさま優雅なふるまいを見せて、ソフト をゆだねてくれた。ぼくの順番がきたときにも、Carlと同じくらいの 鷹揚さを示したいなと思う。

1 邦訳は巻末文献リスト参照}第11章


Previous Next Contents