ObjectSquare [2008 年 9 月号]

[OOエンジニアの輪!]

OOエンジニアの輪!

OOエンジニアの輪!

第 41 回 arton さんの巻

今回のゲストは、arton さんです。arton さんは ActiveScriptRuby や RJB の開発者であり、また Seasar や .Net 関連、Rails など幅広い分野の著作でも知られています。

face1
尊敬する人

リチャード・ストールマン

好きな言葉

「多様性は善」

愛用のツール

emacs


自己紹介

--- 簡単に自己紹介をお願いします。

最初は、外資系のコンピューター会社で、メインフレームのミドルウェア系の仕事をしていました。会社がメインフレームから撤退した後は、サーバをやったり、 POS をやったり、あっちいったりこっちいったり。

そういうことやっていると、ネットワークをいじる必要が出てきて、簡単にソケットがたたけて、正規表現が使えて、そういう簡単なスクリプト言語が使いたくなって、なんとなく Ruby*1 を使うようになったのかな。Ruby を使うようになると、GUI があるといいなぁということで、ActiveScriptRuby*2 を作りました。そこで HTA でやるといいなぁというところから、それがそのまま『邪道編』*3 っていう本になってきたりね(笑)。

まぁいろいろ、というのが本業です。

--- 今現在、やられていることは?

今多いのは、サーバの方だと Java で、拡張するところのインターフェース部分を作ったりとか、あるいは端末の方だと C++ で、やっぱりインターフェースのところを作ったりですね。

後は全体の仕様書いたり、アーキテクチャ決めたりしています。

--- 世間一般的にいうところの「アーキテクト」とって呼ばれるような職種なんですか?

うーん・・・一応そういう風になるんじゃないかなぁと思うんですけど。


【arton】の由来

--- ところで、arton さんの "arton" ってどこから?

メインフレームをやっていた頃ですが、投入するジョブに ID をつけることになっていて、それが自分のイニシャルの間に部門の頭文字を入れたものだったんですよ。私、「田島あきお」で「A.T」で、その当時「リテールシステム」っていうとこにいたんで、「R」を置いて、「art」。

「rms」*4 とか「esr」*5 とか知ってるもんだから、これはかっこいいだろうみたいにね(笑)。 俺は『art』だなと。

で、インターネットでも利用しようとするとそれだと短すぎて、当然メールアドレスとかが何も取れなくて。それで「Online」の「on」をつけて、「arton」って。気持ち的には「rms」とかの真似なんですよ(笑)。

Windows

コンピュータ事始め

face2

--- コンピュータとかソフトウェアの事始めはいつですか?

ぎりぎり大学の時かな。教養か何かで FORTRAN*6 の授業を取ったことはあるけれど、意識的に使うのは会社入ってからですね。

--- 社会人になる時は、この業界に特別な意識があったんですか?

あった訳ではないです。入れるところに入っただけで、成り行きです。

--- 大学時代は何を専攻されていたんですか?

私は商学部。商学部でどちらかというと経営の方のつもり。

--- 勝手な印象なんですけど、哲学科かなぁとか思ってました。

それは趣味で、哲学は好きです。

--- もし歯車が組み合わさっていなかったら、プログラムとかやっていないかもしれない?

それはあるかもしれない。それでも自然にそっちにいったんじゃないかな(笑)。

--- 意外と珍しいタイプですよね?

そうだと思います。パソコン買ったのも会社入ってからかな。

--- どれくらい前に?

85 年に入社だから、 20 年ちょっと前。まず会社に入って触れたのは、その会社のメインフレームですかね。

--- メインフレーム・・・カードとか使ったりしていたのですか?

うん、カードです。カードしまくりましたよ(笑)。 それだけじゃなく、紙テープも使いましたね。

--- 言語はどういうのを使ってったんですか?

「×××」っていう言語ですね。

--- そのメインフレーム特有の言語なんですか?

もちろん、専用の。今でも頭の中で全部コマンド入ってますけどね。0x54 っていうのがオペランド A からオペランド B に移動するやつで、0x2a が実効アドレスをこちらへ持ってくるやつとか。

--- はぁ、相当低級言語なんですね。

もちろんメインフレームだから、実際は生易しくなくて、当然ファームウェアがあって、ファームウェアの上にヴァーチャルマシンがあって、その上で動く 60 年代の(マシンの)エミュレーションっていう感じですかね。昔はアセンブラだったけど、今はそのアセンブラを元にした高級言語みたいな感じ。でも 4 バイト固定長の言語なんですよね。

Windows 3.0 での開発

--- その後、80 年代後半ぐらいは何をされていたんですか?

Windows3.0A の時かなぁ・・・ 90 年代に入ってるような気もしますが、そのときパソコンを使った LAN の仕組みを作りました。ネットワークはもちろん用意されてるんだけど、私はアプリケーションプロトコルを決めたような気がする。アプリケーションは Windows 使おうって言い出したのは私だし、あと設計とほとんど全部やりました。

--- TCP/IP ではなかったんですか?

サーバは UNIX マシンだったから、NetBIOS Over TCP*7 には一応なってたはずですね。

--- 3.0A というは 3.1 の前かぁ。

3.0 でやっててぎりぎりで 3.0A になったんじゃないかな。それで会社が取引のない IBM の OS をバンドルして売るっていうのはどうしたこうしたっていう、結構やっかいなことになりましたね。

あ、そうだ!ギリギリのところでマイクロソフトが 3.0 を出したんで、「お、これ使おう」みたいな話になったんだ。最初は AX でやってて、 AX だと(画面サイズが) 640 * 400 で。どうしてもこの画面だと 640 * 480 必要だから、 DOS-V が欲しい。 DOS-V って何だって訊かれて、それは IBM のだと答えてね。だから IBM のは仕入れない!! って怒られたり(笑)。

--- (笑)

それがマイクロソフト DOS-V6.0 かなんかが出てきたおかげですんなりいったりして。 そういうすごい手作りシステムですね(笑)。 その時に使ったのが BorlandC++ だったかな。それが最初のオブジェクト指向プログラミング言語を利用したシステムじゃないかな。

--- ライブラリはどんなものがあったんですか?

OWL。 Object Windows Library*8 ですね。

--- Borland Component Library より前ですか?

それより遥かに前ですね。だって 16 ビットですよ。 Windows3.0 ですからね。いずれにしても、オブジェクト指向は C++ からですね。

Windows の POS システム

--- その後はどんなお仕事をされていたんですか?

その後は、Windows の POS ですね。(POS では)世界で最初に Windows を駆使して作ったやつです。

--- おぉ!

でも、アメリカまでお伺いに行って、OS2*9 使いなさいって言われましたからね。プロダクトマネージャが「何でそんなの使うんだ」「まともにマルチスレッド、マルチプロセス、マルチタスクで動くのは OS2 の DOS だから」って言うんですよ。

「いや、そういうのしたいんじゃなくて GUI を持ったうんぬんかんぬん」っていっても全く理解してもらえなかったです。

--- この頃、技術情報はどうやって手に入れてたんですか?

えっとね、どうやってたかな。 MSDN 読んでました。あと紙の MSDN ジャーナルも読んでました。それしかないですね。

--- DDJ*10 とかはありました?

あぁ、DDJ は役に立った! DDJ は読んでましたね。というか、DDJJ(Dr.Dobb's Journal Japan) ですけどね。

--- >この頃の流行って何だったんですか?

いや、少なくとも私がいたその業界に関して言えば、他のベンダーは「フレックス」*11 っていう OS を使う完全に組み込みな世界です。逆に、こういう何か Microsoft っていう怪しい会社の、上手く動くかどうか分からないもの使うっていうのは変だっていう話は聞かされました。

--- この頃、オブジェクト的な設計を何かやってました?

Microsoft C++ には、 Microsoft 流の MVC っていうか、Microsoft Foundation Class Library っていうのがついてくるんですよ。それは「CDocument」、「CView」があって、一応 MVC ですよね。

そこでやった POS のアプリケーションって同時に 2 つ動くんですよ。スーパーとか行くと、こっちの方でカチャカチャやってるのに、こっちにもお店の人がいてお金もらうっていうのがあるじゃないですか。あれって二人制っていうんですよね。 POS が 2 つあるわけじゃなくて、普通はチェックしまくるアプリケーションと、キャッシュで支払いするアプリケーションと同時に動くから、それをドキュメント / ビューに乗せるようにしましたね。

--- デザインパターン本には、 MFC の例は書いてありましたよね?

その時デザインパターンはないですから、自分で考えたんだけどね。

イベントドリブンだから、キューでちゃんと待ってるんです。要するにキューから(イベントが)入ってドキュメントのどっちかが動く。だからマルチタスクにしなくても、擬似マルチタスクが自分で出来たから、メモリの少なさをカバーするマージンを取ることができたんです。

それを 6 人ぐらいで作ったんですよね。

--- これが 90 年代の始めっていうことですよね。

それから、やっと 32 ビットの時代が来ます。当然みんな 32 ビットのマシンになっていくし、それに合わせてコンポーネント作りを一生懸命やっていきました。アプリケーションとは別にコンポーネントをいっぱい作っておくと便利になるからね。


オブジェクト指向・コンポーネント指向

face3

--- 90 年代はコンポーネントの時代ですね?

90 年代中盤からね。90 年代の後半になると、ちょうどシステムのリプレース時期に当たって、真ん中にあった中間サーバが UNIX から NT に変わったんですよね。その時はその設計を全部やりました。

でもすごいバグがあって、運用の人たちを苦しめたと(反省しています)。自分でも実装したんだけどね。まぁいろいろ面白かったな、あれは。

--- COM*12 は 90 年代中盤から?

そうですね、Win32 になってからです。

--- DCOM*13 は使っていましたか?

DCOM は使ったけど、それは 98 年ぐらいかな。これはすごいバギーで、使い物にならなくて、お客様にも迷惑をかけました。(今後は)死んでも DCOM 絶対使わないです。

そのおかげで、逆に REST*14 っていうか、XML over HTTP*15 を必然的に選ぶことになったんです。たぶん世界でも相当早い時期に XML-RPC*16 もどきを使った実用システムを作ったんじゃないかな。

--- 当時 XML-RPC はないですよね?x

XML-RPC は、仕様はあったんじゃなかったかなぁ。98 年だから、誰かが SOAP*17 やってて、誰かが XML-RPC やってるみたいな。

同じ頃にそこら中で、みんなやってたんじゃないかな。また独自のプロトコルを作るのはアホくさいから、HTTP でいいやって感じ(笑)。 まともな技術者で 97,8 年に、その通信プロトコル選べるっていったら、HTTP でいいじゃないかみたいな(笑)。

で、アプリケーションは XML を使うという、やっぱりなんかそういう気運があったなぁ、あの時代は、うん。

--- ベンダー的な流れでは、Java だと EJB だし、Microsoft は DCOM がありましたね

まだ DCOM って言ってましたね。でも言いながら Don Box*18 さんとかを SOAP に取り込んで作ってた訳だからね。

DCOM じゃなくてただの COM は、今でも使ってますよ。これは、なくてはならないインフラだと思います。

--- この頃って UML が話題になっていた時期ですが、その流れは感じましたか?x

たぶん 97,8 年に、Microsoft がやっている ActiveStore っていう協議会があって、これは今でも .NET 流通システム協議会*19 って名前変えて生きてるんですけど、いわゆる POS のベンダーと Microsoft が集まって仕様決めようといいながら、結局業界懇親会みたいになっている不思議な集まりなんですけど(笑)。

「WindowsDNA*20 の3階層をやってくれ君たち」ということで、その絵を描かせるために、UML を持ってこようとしたんですよね。フォームがないと VB プログラマにはわかりにくいから、UML でビジュアライゼーションすれば良いだろうとか言ってたような気がするな。Visual Modeler とか言ってね。

その頃 UML の話は聞きました。UML1.0 は今でも大体記述できるよ。

--- UML の分析設計方法論にはまったことってありますか?

ないです。その頃は当然 UML だけじゃダメだからね。

でも、POS をまさに使った UML の教本『実践UML』、GRASP*21 本ね。みんなでこれを買って勉強しましたよ。GRASP 本が確かに POS を題材にするのは分かる。やっぱり題材にしやすい世界ではあるからね。物理的なエンティティがあって、それらが絡んで一つの仕事してるから。

--- 比較的きれいなオブジェクトが出やすいドメインということですか?

そう、そう、そういうことです。

--- GRASP 本は 98 年とかそのくらいですよね。もう最近になってきましたね。もうすぐ Ruby ですか?

もうちょっとで Ruby ですよね。サーバやって POS の面倒もみて、そこで当然のように、それまでの独自通信はやめ、NetBIOS はこんなやつはつかえねーよ、っていう話になった。

かといって、DCOM はとんでもない。じゃあ、HTTP でやるからさという話になる。HTTP でやるからさっていうことは、そのテスト用のサーバさえ用意すれば、クライアントからのテストはパパパってすむし、サーバがいなくてもサーバ代わりのものを立ち上げればクライアントからのテストもすぐできる。

そうすると、いちいち C++ で書くんですかみたいな話になるじゃないですか? それでいろいろみると Ruby だったらその辺が楽そうだなと。

--- やっぱりネットワークなんですね。

そういう意味じゃ、セグメンテーション分けすると、本当は自分、ネットワーク技術者じゃないかなぁって。

邪道編

--- 『邪道編』とか『網道編』*22 とかが出版されたのは 99 年くらいですよね?

『邪道編』が 2000 年ぴったりで、『網道編』は 2001 年じゃないかなぁ。

--- ちなみにそれ以前に執筆活動的なことってしてたんですか?

全く。

--- じゃあ『邪道編』は初なんですか?

邪道編が最初です。ActiveScriptRuby を作ってすぐだったですよ。

--- それって結構意外ですね。分量自体はそんなに多くはないですけど、いきなり一冊書かれたんですか?

うん。あれは、伝説の編集者の金光さんがいい仕事をされたっということで。

--- 金光さんは最初どういう感じ企画を立ち上げたんですか?

えーっと、これも伝説なんだけど、ある日メールが来るわけです。

“本を書きませんか? 金光”って。

--- へぇーー! (笑)

最初に行ったのが助田さんのところで、助田さんが RubyUnit の本*23 の執筆が終わらないんで、じゃあ、次の企画行こう!! って言って、私のところに、ActiveScriptRuby の本を書きませんか?っていうメールが来たんです。

金光さんはいっぱい本を編集してお金が欲しかったんだと思うんだけど(笑)。 突然そういうのがくるから、なんだこりゃって思ってたけどね。

--- 一番最初に執筆したときは結構大変とかいう思いとかなかったですか?

最初はやっぱり楽でした。今の方がよっぽど大変ですよね。迂闊なこと書けないものなんで、調査量とか増えてるから、絶対的には辛いですね。『邪道編』は半分はジョークで済むような本だから(笑)。 ブログ書くみたいなもんですからね。

Java

--- 90 年代終わり頃は仕事で Java を使ってたんですか?

Java はまだ後ですね。メインフレームはもう使ってないんですけど、流通業界のコンピュータですから、一番先に POS がくるわけです。それから、大体お店ごとにサーバがあって、本部にそれらを最後に束ねるサーバがあるんです。大体そういう 3 段構成になってるんです。

それで、POS とお店ごとのサーバの Windows 化が終わったところで、本部のサーバを Sun から調達するっていう話になってくる。そこでしめたなと思って、Java でやりましょうって、アーキテクチャを売りに、と言っても社内ですけど、行ったんですよ。

--- おぉーー! どっちかっていうとバッチ的なシステムですよね?

いや、バッチじゃないです。OLTP。*24

それで、Java で作りますかってことになって、全体的なアーキテクチャ決める人にアサインしてもらってね。でも、自分で一生懸命ミドルウェア作ってたんだけど(笑)。

--- ほとんどゼロからですか?

Tomcat ぐらいしか使わなかったなぁ。Jakarta*25 が大嫌いで、当然 Commons*26 とか使うはずないから、似たようなものを全部作りました。

--- Tomcat 自体は結構ありがたいですよね。

(さすがに)あれを作るのは嫌だからね。

どうも私は(Jakarta 系よりも) Sun の API は好きなんです。やっぱりなんだかんだいって、 Sun はまだ昔ながらのハック魂が残ってるんですよ(笑)。

DI

face4

--- この頃は、今で言う DI コンテナ*27 みたいなものはない時代ですか?

まぁ、そうっすね。その時のアーキテクチャは、「セントラルコンテキスト」って言うみたいだけど、リソースの塊を引数で与えられて、そこから各オブジェクトが(取り出して)勝手にやるみたいなアーキテクチャでした。

その後に、ひがさんのことを知ってしまって、ちゃぶ台返しを自分でやって・・ (笑) ・・しまったと。

--- Seasar1 から Seasar2 になった時ってことですか?

Seasar2 の話を聞いて、DI コンテナのメリットを理解したもんで、自分で作ったものをぽーんって(笑)。

--- 全部入れ替えたんですか!?

独自の DI コンテナを作りました。

--- Seasar2 は使わなかったってことですか?

もちろん使わない。我々はハードウェアメーカーだから、プロダクトに責任持つ必要があるんですよ。そうすると、他人の作ったプロダクトを持ってきても、結局完全に面倒みることを考えると、自分たちで作ったほうが面倒みやすいんですよ。

--- 将来のバージョンアップとかも考えるとってことですよね?

うん。

--- Commons 嫌いも、そんなところから来ているんですかね。

結局同じで、我々は自分たちでメンテできますからってこと。

--- Seasar に関しては製品として使ったというよりは、設計アイディアをもらったってことですね?

もらった。目からうろこでしたね。


EJB*28 には近づかない

--- ところで、EJB とかフルの JavaEE をやるようなタイミングっていうのはなかったんですか?

それはもう、DCOM で懲りてるから、そんな分厚いリモート層のもってるやつは絶対死んでも使わない。

--- 1999 年、2000 年はそれに巻き込まれてクラッシュしてる人が多かった時代ですよね?

DCOM で散々お客さんに迷惑かけたからね。実装そのものがまだまだとても実用的な話じゃないと思いましたね。

--- 分散オブジェクト系で成功してるものって、たとえば何でしょう?

XML-RPC ぐらいだけじゃないっすか。

結局、数じゃないですか。 10 万回に 1 個でもトラブったらダメな世界って当然あるわけですよね。少なくとも業務では使いたくはないな。

--- 最初から EJB に近づかなかったっていうのは DCOM のおかげってことですよね。

うん。

--- ここまでで、何年ぐらいのお話ですか?

2004 年かな。まぁ、そうやって、一度作ったやつを捨てて、DI コンテナ作って、それが動き出したのが 2005 年か 2006 年かな。でその後、私は仕事がなくなってしまったんですよ。Java って、いやぁ、プログラマの層が分厚いからプロダクトラインを変えるくらいのパワーがあるのだなぁと痛感していたり。

というわけで、今すごくやることがなくて困ってるってことで(笑)。

ソフトウェアの工業化

face5

--- 現在、こういうアーキテクチャでこういうシステム作りたいというのは何かありますか?

うーん、作るんだったら業務システムで、プログラマーを使わないプログラムを作りたいね。

--- ソフトウェアファクトリー*29 のような?

うーん、ソフトウェアファクトリーってあれはあれで大げさ過ぎる。DCOM と EJB と同じ話になるんじゃないかなぁ。もっとシンプルでいいはずじゃないでしょうか。

要するに、DCOM も EJB にしても XML-RPC でいいわけじゃないですか? ソフトウェアファクトリーを一言で説明する人が誰も出てこないってことが、その複雑さを示していると思うよ。だから、例によって、彼らは理屈のうえで完全なものを目指して複雑にしすぎてるんじゃないかなという気がする。

ソフトウェアファクトリーは暇があったら見よう見ようと思って、結局 VisalStudio 入れてしばらくみたんだけど、どうもその仕掛けでかすぎる割には、得られるものが少なすぎるっていうのが今のところかな。サンプルがあるけど、これ作ったやつ馬鹿じゃない?みたいなものばかりでしょ。スマートクライアントのサンプルなんて、これ何の役に立つんだって(笑)。

--- (大げさ度合いでは) DCOM とか EJB に近いものがありますね。

近いですね。こんなもん使うぐらいだったら、自分でゼロからペタペタ作ったほうが速いだろうみたいなね(笑)。

どうしてあそこまであの部品がダメなのかって考えると、結局まだギャップがあるんだろうな。どんなギャップかっていうと、スマートクライアントを作ってるアプリケーションプログラマのノウハウがあれば、きっとこういう手順でこうやって作るっていうのがあるはずなんだよ。ところが、今のところソフトウェアファクトリーが難しすぎるから、彼らが自分たちのノウハウから部品を作るんじゃなくて、ここらへんにいるアーキテクチャ宇宙飛行士*30 が部品を作っちゃったりしたんじゃないかな(笑)。 そうすると結局使えないから本来使うべき彼らは使わない。ソフトウェアファクトリーを自分たちで使わないから、自分たちが部品を作ることは当然あり得ない。使われないから、これは機能が足りないからなのだろうと思って、宇宙飛行士たちは頑張っていろんな機能を作る。ますます使い物にならなくなる。負のスパイラルに入ってるのかな、彼らは。

なんとなく傍で見ててしばらく近寄らなくてもいいやって気がしてね(笑)。

ただ、たぶん方向性は正しいんですよ。ソフトウェアファクトリーの考え方ってのは。

--- 業務アプリを記述できる DSL*31 のようなものを目指している?

いや、業務アプリを記述するっていうこととも違うんですよね。特定ドメインだから、入出力は決まってるわけですよ。ある入力がきたら、それに対応する何かをみて、それに見合った更新なり出力なりをすることになるじゃないですか。それをどういう風に記述するか、どう切り捨てればいいかも実は分かっているんです。というのも、プログラム、ソースファイルの資産は山ほどあるわけだから、見れば見るほどどれもこれも全部同じパターンに見えるっていうことなんだよね。今はただ、そこから抽出する作業をさぼってるってことなんだよね。それさえできちゃえば終わりなんだよ、実はさ。

--- 確かにそうでうすね。案件ごとに似たようなものを何回も書いてます。何かが見つかってないですよね、ソフトウェアファクトリー分野。何かはあるとは思うんですけど。

一つは思うにね、ある程度の資産を持っているところはパッケージを作っちゃうのがやっぱり一番いいんじゃないかなって気がするんですよね。カスタマイズできるベースパッケージを持つっていうのが今後の道なんじゃないかなぁ。すべては SAP になるみたいな。さらにそこで、そのカスタマイズをどこまで楽にできるか、誰に、どこまで出すかで、例えば羽生さん*32 みたいな方向もあるだろうし、あるいは、もうちょっと門外不出にして、あくまで、そのパッケージを作って生産するところは自社の奥にしまっておいてっていうやり方も当然あるだろうし。

もう一個の方向は、要するにパッケージじゃなくて、ソフトウェア部品を作るのに 1 万円かかるところを、中国やベトナムに仕様書を書いて渡して結果を得ると全部合わせても 6000 円で済みます、っていうのもそれはそれでありなんだろうなって気がする。でも、それが出来るのはリスクくらった時の赤字に耐えられる会社じゃないとできないだろな。モチベーションもでないですよね。

だから、普通の会社もパッケージをきちんと作るっていうのがやっぱり道なんじゃないかなぁ。これまで SIer は、規模の大きい企業に(IBM、NTT データみたいな)に引っ張られて、つい真面目にパッケージ作りを怠ってきたっていう傾向があるんじゃないかな。ちゃんと資産を評価して、持つべきじゃないかなぁ。そうすると逆に資産として、もっとソフトウェアから部品が出きるんだったらそれはそれで大いに結構な話であって、まずは資産をちゃんと棚卸しして、まず利用しやすい格好でパッケージとして持って、そこからそれを分析するところから始めるしかないのかなぁとは思ってます。

それでいくと、天から Visual Studio と一緒に降ってくる DSL、ソフトウェアファクトリーはまだまだ使い物にならないと思います。要するにそこに何を食わせるかさえ自分たちで分かってないのに使えないよねっていうことです。仕組みが大きすぎるから、埋め込むものをちゃんと考えないと使い物にならない。使ったら使ったで使い物にならない。まず足元見直して、部品表を自分たちで作るところから始めたほうがいいような気がする。それができたら、「なぁんだ。ソフトウェアファクトリーってこうやって使えばいいんじゃない」って、それはそれで使い道あるのかもしれないしね。

と、一応、客観的にしゃべってますけど、そんな感じです。ひとごとじゃないんだけど。

執筆活動

--- 毎年 1 冊くらい本を執筆して出してますけど、どのように進めていらっしゃるのですか?

構想自体は編集の方が企画を出されて、連絡が来るところから始まる訳だけど、無理だなってものは無理だっていいますね。出来そうな場合は、編集者の方と打ち合わせしてどういう意図の本かを伺います。どういうステップでやるかとか、そういう細かい肉付けを決めて、それに合わせて粛々と書いていきます。

--- 何で書いていらっしゃるのですか?

私はエディタで書きますね。emacs です。

--- ちょっとした便利ツールを作ったりしていますか?

埋め込むリストの行番号を付ける elisp とか、そういうのは作りますが、ほとんどないですね。ツールよりも、Seaser 本だけは Word で書けって言われて地獄のようにつらかったです。編集者の癖なんだろうけど、Word の「編集履歴」とか「コメント」ってあるじゃないですか。あれをどうしても使いたかったみたい。それは一つのやり方なんだと思うけど、私としては指使いも違うし、勝手に大文字に変わるし、えらくつらかったなぁ。

--- 執筆する時間は決めてるんですか?

完全にケースバイケースですね。ベストなのは、夜 9 時から 12 時ぐらいまでなんだけど、4 時間、5 時間やるときもあります。

--- 平日にですか?

もちろん。今は子供が大きくなって、「遊んでー」とか来るじゃないですか(笑)。 そうすると、遊んでやろっかなーってね(笑)。 あっという間に、夜 11 時でしょ。そういう訳でコンスタントに書くのは難しいから、結構今は時間かかっているかもしれないな。

--- 基本は家で書いていらっしゃる?

MacBook Air を買ってからは、たまにタリーズ*33 行ってる。あのキーボードは気持ちいいね。でも基本は家です。Realforce*34 とアーロンチェアという態勢を作ってあるし。

--- すばらしいですね。

実はアーロンチェアは失敗したかなという気がするんだよね。ちょっと私には小さかったというか、僕は姿勢が悪いから、すぐこうやりたくなっちゃうしね(背もたれによりかかる姿勢)。Contessa*35 みたいにヘッドレストがあるやつもよかったかな(笑)。Realforce はすばらしいね。


好きなプログラミング言語


--- 一番好きなプログラミング言語って何ですか?

やっぱり Ruby なのかなぁ。何で書いてもいいよって言われたら、よほどのことがない限り Ruby が一番楽ですね。

割りと隅から隅まで分かっているって言ったら Java と Ruby になっちゃう。C# と VB も好きです。モダンな C++ は使えてるとは言えないけど、実は C++ も好きです。

プログラミングと音楽

face6

--- arton さんは(ブログに)哲学、映画、音楽とかについて書いていらっしゃいますよね? そういうのはプログラミングにつながっていたりするんですか?

音楽はなんとなくつながっている気がする。音楽の作り方とプログラムの作り方って、なんか近いものを感じるんだよね。いくつものパラメータを合わせて物を作っていくってすごい似ている気がするんだよな。プログラムって頭の中でいろいろ設計するじゃないですか。私の言う作曲っていうのは西洋音楽なんだけど、例えばベートーヴェンの『運命』だったら、ソナタ形式っていうパターンがあって、そのパターンの中で、“タタタタン”というモチーフを派生して“タタタタン、タタタタン”っていうインスタンスを作って・・・というように作曲されてるんじゃないかなと感じる。そういう意味で作曲とプログラミングって近いんじゃないのかなって気がするんだ。

--- 興味深いお話ですね。

もちろん音楽とプログラムは違うもんなんだけどさ。 でもね、粒度感というか、その辺が似てるんだ。

--- 音楽的な視点で、Ruby と Java の違いってありますか?

Java はクラシック音楽を感じるけど、Rubyに音楽は感じないな。

Java で作っていると、必ず頭の中でモデリングしているからね。音楽を意識するのは、UML の静的クラス図とかが頭の中に浮かんでいる時だからね。UML って、カンディンスキーの絵とかに似ているじゃないですか。カンディンスキーの絵ってよく音楽が聞こえるって言われますよね。私の頭の中で類推されて感じているのかもしれないけど、それってよく分かるんだよね。条件反射かもしれない。 UML のあの形とカンディンスキーの絵がさ。だから Java の場合は、コードより先にあの四角が浮かんでくる。メソッドがあって、ここはインターフェースを継承して、ここでコンポジションしといて、というように。

Ruby で作る時はあの四角は浮かんでこないもんな。もうプログラムのコードが出てきているから。Ruby の方は割りとアドホックというか場当たり的というか、結局設計していないんだよね。

--- 思考の流れがかなり違っているてことですね。

全然違う。競合するものですらない。俺は寿司が好きだからうなぎは死んでも食わないって人は普通いないですよね。うなぎはうなぎ。寿司は寿司。今日は生もの食いたいから寿司を食う。今日はたれが食いたいからうなぎを食うみたいな。

--- 自分は楽器演奏中に「戻る」記号が分からなくなってしまうことをコンパイルエラーって言います(笑)。

それってプログラミングっていうよりも自分が CPU になっちゃっているんじゃないの(笑)。


若手エンジニアへのアドバイス

--- 若手エンジニアへ一言メッセージをお願いします。

「勉強しましょう」

--- 本当に、一言ですね(笑)。

勉強するのが一番じゃないですか。遊んで下さいねとは言えないし(笑)。 勉強した方がいいですよ。

実は、勉強好きな人にしか言っていないんだけどね。そもそもオブジェクトの広場を読む人って、きっと勉強好きな人ですよね(全笑)。

--- そうですよね(笑)。

勉強しましょうというのは、大きな意味では「視野を広く取っていろんなものを受け入れる」ってことです。例えばプログラマだったら、いろんなプログラミング言語使ってみるっていうのも一つだと思うよ。いずれにしても、一言だったら「勉強しましょう」としか言えないですね。

--- 最後に何か宣伝したいことってありますか?

執筆中のものはあるんだけど。

--- 言えない系ですか?

まだね。まぁ普通に Rails 本*36 を買ってよということですね。TDD*37 をあそこまでチュートリアルでしつこく打ち出したものは珍しいんじゃないかと。

--- ありがとうございました!!



*1: オブジェクト指向スクリプト言語 Ruby

*2: About ActiveScriptRuby

*3: Ruby を 256 倍使うための本 邪道編 arton (著)

*4: リチャード・ストールマン

*5: エリック・レイモンド

*6: FORTRAN

*7: NetBIOS Over TCP

*8: Borland C++ 用オブジェクト指向ライブラリ

*9: OS/2

*10: Dr.Dobb's Journal

*11: FlexOS

*12: Component Object Model

*13: Distributed Component Object Model

*14: Fielding Dissertation: CHAPTER 5: Representational State Transfer (REST)

*15: HTTP を RPC として利用し、データの形式に XML を利用するスタイル

*16: XML-RPC Home Page

*17: Simple Object Access Protocol

*18: Microsoft のソフトウェア開発者

*19: .NET 流通システム協議会

*20: Windows Distributed internet Applications Architecture

*21: GRASPパターン

*22: Ruby を 256 倍使うための本 網道編 ただ ただし、arton(著)

*23: Ruby を 256 倍使うための本 極道編 助田雅紀(著)

*24: オンライントランザクション処理

*25: The Jakarta Site - The Jakarta Project -- Java Related Products

*26: Apache Commons - Home

*27: DIコンテナ

*28: Enterprise JavaBeans Technology

*29: ソフトウェアファクトリーとは何か?

*30: Joel Spolsky の造語。抽象化の限界を超えて浮世離れしちゃった人たち

*31: ドメイン固有言語

*32: 株式会社スターロジック

*33: おいしいコーヒー

*34: 東プレのキーボード

*35: Contessa

*36: 10日でおぼえる Ruby on Rails入門教室, かんたんRuby on RailsでWebアプリケーション開発

*37: Test Driven Design



©2008 OGIS-RI Co., Ltd.
Prev Index Next
Prev. Index Next