刊行記念：artonさんインタビュー 第２回
『Ruby環境構築講座 Windows編』の刊行を記念して、著者であるartonさんにお話をうかがいました。
（2010年10月22日、聞き手：高橋征義）
(「artonさんインタビュー第１回」からの続き)
arton: Rubyとの関わりという点について言うと、私は積極的にバグ探しはしないし、利用していて困ることはほとんどない。 もともと、るびまのHotlinksのインタビューにも載ってるけど、あんまりやばいところにはぶつかんないですね。 仕事上のクセでやばいところは基本避ける。 あるいは見なかったことにするとかね。 そして迂回路を取る。 だから現実問題としてぶつからない。
Windowsはそもそも素直に使ってるから（笑） Rubyもどちらかというと素直に使ってるし。
でも最近素直に使わなくなって。デバッガとか作ると途端にいろんなものが出てきて、 redmineとかに登録したりする。 ruinedね(ソース)。
ruinedについて説明すると、というのは実はこの本の内容にも関係してくるからなんだけど、もともと、名前が先にあったんだよね。 Rubyのプログラムってだいたい「R」で始まるじゃない。 Rのつく悪い言葉ってないかなあと思ったら、廃虚がruin。 で、ぶっ壊れたっていうのがruined。これで何かできないかなと。 おしりにdがつく、と言ったら、これはデバッガだよなあ（笑）。 だいたいデバッグするっていうのはプログラムぶっ壊れてるからちょうどいいじゃん、という感じで、 デバッガを作ろうかなあと考えた。
どういうデバッガがいいかなと考えたら、 なひさんのデバッガがあるじゃん。でも使わないな、なんで使わないのか…… ああ、思い出した、EmacsでGDB、あるいはJavaのJDEとかもそうだけど、 結局ブレイクポイント探して、Ctrl-Xなんちゃらやって、 止まったところでLやってリスト出して、Sやって先に進めて……って、 すごくめんどくさいじゃん。
ところがVisual Studio使ってデバッグするのはラクじゃん。 なんでラクかっていったら、 ソースファイルが見えて、スクロールバーもあって、ソースをクリックして、 実行ボタン押して、てーって実行して、 てってってって進めて、 この辺のウィンドウに、その時点の変数の値が出てる。これはラクだ。 ところがいくらEmacsが好きだって言っても、やはりGDBは苦痛か？ と言われれば苦痛なわけ。 まあ2400bpsで端末につながってますって世界だったら、もちろんそっちじゃないと駄目なんだろうけど。 さすがにEmacsの時代じゃないな、というのはそういうところで感じるわけ。
そういうわけで、 デバッガを使いたくないのは、これは結局コマンドラインだからで、 これが見渡し良くなるといいなあと。
さらにもう一個あった。 メインフレームのプログラミング言語を触った後で、 一番最初にパソコンのプログラミング言語に触ったのは、 AmigaのAmiga BASICってやつ。 Amiga BASICってMiscrosoft BASICなんだけど、 マルチウィンドウを意識しているから、 実行速度はバカみたいに遅い代わりに、 デバッガ実行すると、 リストのところでオレンジ色のライン線がピーっと、 ピンコンピンコン進むわけ。 その頃になると、もうプログラムはがんがん作ってるから、 そんなにif文の動きとか、whileのとか、 そんなの見てもうれしくないからもっと早く動けと思ってたんだけど、 でもあれは動きが面白かった。
ああいうのって、教育的にはいいなあと思ったわけ。 制御構造の動きとか。 動くたんびにこう変数の値が減ってくるとかね。 その二つが合わさって、GUIでどこでも動くって言ったらブラウザベースしかないなあと。 でブラウザーベースの、デバッガだったら、今言ったようなこともできる。
だから逆に言うとruinedってフル実行モードがないの。 高速ってやっても必ずあの一行一行のやつになる。 まあ所詮その程度の規模のものしかデバッグしないだろうと思ってるから。
どっちにしても、Rubyのtrace interface APIは、何かっていうと呼ばれるから。 どっちにしたってbreakpointはチェックするんだし、 チェックするんだったら、ローカルのブラウザのやりとりだったらまあちょっと重くてもいいかなあと。 その辺もあってそのruinedを作った。
あれは、そういう意味じゃ、面白いから使って欲しいんで、 ruby-talkの方にもいちおう報告してみたけど、 反応がぜんぜんなくてさみしい（笑） でもRubyGems.orgを見てると、一応２週間で300個くらいダウンロードされてる。
それでstdoutをがめようとすると、いきなりsegvくらって、redmine登録。 そういうのはあるんだけど。 なんか変なことやると確かにバグを見つけて、 パッチを書いたりするんだけど、 そういう意味じゃそんなにパッチとかは作ってない。 WIN32OLEはなんとなくお手伝いをしてるから、 そういうパッチは結構作ってるけど、 コアの方のやつってのは、バグも見つけてないから報告もしてないし、 パッチもほとんど投げたことない。 というわけで、コミッタになるもへったくれもなさそうな気がしてたんだけど。
本来話が出てた、readlineのパッチは結局高尾さんにおまかせになったんだけど、 あの後どうなったのかさっぱりわからない。 相変わらずコミッタになったけどコミットしてないから。 助田さんにお願いして、ほんとにコミットできるかどうか試してみようと思って、 Win32OLEのテスト用のちょろいパッチを一発、コミットさせてもらったくらい。
何の話だっけ？ RubyKaigiの話か。 テキストを書こうとおもった動機、その時思ったのは、 養成講座って言うのをやるときに、 教えたいことって言うのは所詮はmakeの仕方にすぎないんだけど、 まずmakeの仕方って言っても駄目だろうなって思ったわけ。 そりゃもちろんわかる人はさっさとやるに決まってるからいいんだけど、 裾野を広げたいっていうのがもともとの目的なんだから。 実際に、要するにCのソースを自分のマシンに入れて、 自分で新しいの出たら「make」ってやって、 少なくとも動かないよ、 場合によってはさらに、でもこうやれば治るよ、と。 そういう人が欲しいんだから、数は多ければ多いほどいいんだから。 そうすると、やっぱftpでgetしてconfigureしてmakeすればいいよってんじゃすまないよなっとか思うじゃないですか。
なぜすまないのかって言ったら、もともとconfigureするとか、 tarball取ってきて展開してmakeするっていうのって、 Windowsの文化じゃぜんぜんないわけ。 そりゃやっぱりUNIXのほうで。 その辺の感覚って、持ってなければはなから何を言ってるか理解してもらえないかもしれないな、 というのはちょっと不安に思ったところ。
Eclipse使ってるひとたちには、 classpathも知らないのになんでこの人たちはJavaのプログラムをできるんだろうと（笑） 知らなきゃ書けないわけないけど、知らなくて書けるのっていうのは、 仕様書通りのプログラムだけで。 でも、いま私がここで養成したいっていうのは、 なんとバグがあるみたいだ、これこれこういうことをすると落ちる、っていうのが最低級のひとで、 できれば、ここをこうやると治りますよっていう人なんだから。 Eclipse使って満足してるような人じゃなくて、 Javaのたとえでいうと、classpathはこうやって通すんだよね、 でここでjavacってやるけど、あ、そうだ1.4.2でやるんだからpathはこっちに変えてこっちでjavacだと。 そういうことができるひと。
だいたいUNIX使ってると当たり前のようにできるようなあ、 なんで当たり前のようにできるのかなあと。 もちろん、2010年の今となっては、きっとLinux使ってる奴の100人中98人はapt-get、apitiude、あるいはGUIのあれを使ってるとは思う。 それでも、この5年前まではずっと野良ビルドするのが当たり前で、 そういうことをやってるうちに分かってくる、 少なくともconfigureっていうのはこんなことするものらしいとか、 そういうのはいやでも分かってくるよね。 というか分かんないと何もできないし。
普通にmakeして、sudoでインストールすると、 /usr/localの下に、/usrと同じようなかっこうでlibとbinがあって、そっちの方に入るんだよねとか、 そういうのはまあだいたいわかってくるはず。と、思いたい。 ということは、そもそも野良ビルドをするっていう感覚っていうものを わかってもらえないともしかしたら駄目なんじゃないか、 というところまでちょっと考えた。 それが第1章の分。
なんであの、意味なくiconvの話だとか、OpenSSLの話だとかあるかと言うと、 野良ビルドするっていうことはこういうことなんだよ、 っていうのをまずRubyのビルドを始める前に、軽く出したかった。 だからあそこはわりと重要で、要するについ数年前までは、 Unix系含めて、Windows以外は、こういうことをやって、自分の環境を作っていったんですよ、という意識合わせの章。
そうすると、本当は書かなきゃならないんだろうけど書いてないのは、 diffの使い方。あれが実はなかったりする。 grep、diff、あとfindか、この辺ってのは今回はそこは割愛させてもらったけど、同じノリで本当はあるべきことなのかも知れない。
その辺の、Unixだったらなんとなく普通これくらいはやるよね、っていうようなところが、 まずWindowsの、仮に開発者だとしても、全然ないだろうと。そういう感覚がね。
つまりコマンドライン開いて、手で何かひっぱってきて構築してインストールする、そういうところをまず、 こういう文化がUnixにあって、そこでRubyのビルドってのをしなきゃなんないんだよ、と。 そこをまず書きたかった。
そして、じゃあ実際Rubyをビルドするのに何が必要かっていったら、 そこからは実用情報がガンガン入ってきて、 Makefileってのを元に、ビルドが行われるんだよ。 そのmakeってのはじゃあどういうものなんだよ、 実際Rubyの中だとどういうターゲットがあって、それによってどういう動きをするのか。 上手くいかない場合、何を調べれりゃいいのか。 あと部分実行するためにはどういう風にするのか。 っていうようなことまで説明している。
第3章以降になると、さらに一応Visual Studio使えるっていう人をターゲットにしていて、 最終的な目標はWindowsプラットフォームで自分が引っかかったところのパッチ書ける人が少しでも増えればいいなあ、 っていうのがあるから、まあデバッガ使うべきだよね。 そこで、さっき延々と話してたruinedの話にやっとつながるんだけど、RubyのデバッグにVisual Studioのデバッガが使えるんだよね。 自分で構築するとソースファイルとデバッグ用シンボル情報が手元に残るからすぐにソースコードレベルデバッグに入れる。コマンドラインベースのデバッガじゃなくて、本物のGUIデバッガだ。 これが実はMSWin32版Rubyの一番のメリットと言える。
でまあ、そんなとき自分で作ったプログラムを足場にすると、 デバッガ引っ掛けるのが楽だから、 そこで、拡張ライブラリを作ると。 拡張ライブラリはいずれにしろ、作り方知ってて損なんてないはずだし。 もしかしたらWindowsの場合って、Rubyのプログラムで無理やりWin32APIをDL経由で呼ぶよりは、 むしろCで書いちゃった方が早いんじゃないかと思うっていうのもあって。 要するにWindowsの場合って、POSIXで使えない部分がいっぱいあるから、 逆にWin32ならではの、あるいはWin64ならではのがいっぱいあるから。 そういうのは拡張ライブラリ作ればいいはずだし。 そうするとデバッグの必要が出てくるよね。
そうやって拡張ライブラリを書くっていう話と、そこでソースレベルデバッガをひっかけるという話。 そこができた上で、こういうやり方をするとRubyのもできるよと、脚注や何かにちょろっと書いたり。 まあ、最適化した上でのデバッグ情報なんで自動変数がレジスタにしか無かったり関数のフレームが作られていなかったり、そこはくせがあるんだけど、Visual Studioのデバッガを使えば例外のトラップだのメモリーやらレジスター眺めるだのはえらく簡単だから、これは出したかった。
で、実際にバイナリの中身をいじくる話を出してきて、ここまでとりあえず一通りかな。 あとは応用編だから、各自頑張ってくれと（笑）
で、頑張る人がいっぱい出てくると、私はもうインストールパッケージ作んなくてもいいかなと（笑） まあ、自分で使ってるし、職場のマシンに入れるためにいやでも作るんだけど。 まああと１０年くらい作るような気もするんだけど、 もっといいのができてきたらそれでもいいし。 今は、Diceさんって人が自分でインストーラを作ってるけど、 あれだったら俺の選択の方がいいやと思って俺は使わないけど（笑）、 ただ、いろんな人がいて、いろんな切り口でいろんなパッケージが出てくれば、 そのほうがいいんじゃないのかなあ。とりあえず。 その中でさらに淘汰されて、生き残るものが出てくるのはそれはそれでありだろうと。
今は選択の余地が少なすぎるね。 usaさんの作ったzipを、よくわけも分からず展開して、 パス通さずに動かねえって言ってる人がいるかと思えば（笑）、 一昔前のRuby Installerを入れちゃってディスクが足りなくなったとか、 わけの分かんないのがいっぱいメニューに入ってて、英語しかなくて困ってるとか。 そういうことするより自分でビルドしろと。 もう一個は、さすがにMicrosoftがいろんな面でやばいと思ったのか、 VisualStudioを、変な登録とか必要だけど無料で出すようになって。 だから無料で強力なソースコードレベルデバッガ付きでCコンパイラが使えるようになった。それはでかいよね。 せっかくMSが、開発者は金払えっていうのから、 最近Windows開発者の数が減ってるような気がしてならないから、 っていうたぶんテコ入れで、 あとオープンソースに少しはコミットしているふりをしないといけないと思ってるのかどうか、 ともかくコンパイラを開放してる。 でも誰も使わないんだったらやっぱり引き上げるか、 っていう風になったら世の中よろしくないから、 せっかくあるんならみなさんちゃんと使って、 Microsoftにいいですねって言ってやってね、というのも一つある。
別にMicrosoftの宣伝をする気はないけど、 それなりにやってることについては評価するべきだと。 この場合「評価する」っていうのは使ってやることしかないわけで。 そういうのが合わさって、野良ビルド養成塾やこの本になりました。
── この本を書くにあたって、こだわったところ、気をつけたところがあれば教えてください。
arton: Unix文化風なところ、要するに野良ビルドっていうのはどういうものかっていうのを少しでも分かって欲しいし。 最終的な目標としては、相当な情報を出してるはずだから、 そういう所を総合して、あとは自分の力でやれるようになってほしいなあと。 だから、そのために、必要そうな情報は一応、Rubyのビルドに関しては出せるものは出したと。
なんでそうなってるかっていう理由付けのところは、やっぱり書きたかった。
気をつけたところというのは、何も知らない人を連れてきても、 まっさらのきれいなマシンに書いたあるとおりにやれば、たぶんRubyのインストールができるはず。だといいなあと。 でも実際にやってみると、んー、やっぱりWindowsは多様だわ（笑）
なんかねえ、拡張ライブラリ作るためにsetup.rbを使うんだけどまともに動かない人がいてねえ、むしろわかっている人なんだけど、理由がわかんないだよこれが。未だにわからない。 setup.rbがあるのは確実に分かってる。でもここで ruby setup.rbのconfigってやっても、なぜかMakefileが作れない。 でも、setup.rbも他の人が使ってるのも、私が使ってるのも同じsetup.rbだし、 Visual Studioも同じだし、nmakeもnmakeでディレクトリ構造も同じで extconf.rbの中身も間違っていないし、そもそもRubyがエラーになってないのになぜ、Makefileが作れないんだろう（笑） そういう、やっぱり訳わからないのがある。
その場合はクリーンインストールすればきっと問題解消なんだろうなぁ（笑） 別のRubyかもしれないし、もしかしたらmkmf.rbが違うrbconfig.rbを見てるのかもね。 一応確認したんだけど。環境変数かなぁ。
── RubyはAPI設計等でUnixの影響を強く受けていることもあり、 熱心なRubyistの間ではWindowsはあまり使われていないように見えます。 とはいえ、WindowsプラットフォームでRubyを使われている方も多いのは事実です。 Windowsの世界からRubyを見るとどのように見えるのか、良いところや困るところなどを教えてください。
arton: まず、「熱心なRubyistの間で」っていうのは二種類いるんじゃないかと私は思ってます。 一つは真に熱心なRubyistで、彼らはLinuxというかDebianを使ってる。 でも、一般論として熱心なRubyistが使っているのは、OS Xじゃないかな。
良いところ……。私は特にパスのところとか、 内部ではPOSIXというかUnix流儀になっているけれど、コマンドラインレベルではちゃんとWindows流儀で動くところとか。 ただ困るところって、この10年間でほぼなくなったよね。 小松さんや、ebanさん、なかださん、助田さん、usaさんのおかげ。
小松さんがライブラリの問題点を見極めてDLLでやろうって方針を打ち出してきてと思うけどこのあたりはうろ覚え。 で、ebanさんがbinの存在するところから、 相対的に自分の位置をみるってやり方を出してきて。 Windowsの場合って、結構Program Filesの、まあAppleのも同じだと思うけど、 自分のインストールされた位置を元に見るっていうのが、 Windowsの流儀じゃん。そういう意味でWin32版のRubyはそれやってくれてるから、ちゃんと。 そこで、えいっとコピーすればちゃんと自分のいるところを上に行って、 lib見てshare見てってやる。 あと助田さんがWin32OLE作っていたりね。
で、usaさんが、がんがん直して。 前はgetsなんかだとマルチスレッドではそもそもselectがないからうまくスレッドの切り替えができてなかったけど、 今やちゃんとできるようになってる。 前はgetsってやったらそこで止まってた。
よくあるのは、DRb試してみたいと思います、で、DRbServer立ち上げて、 そうすると咳さんの本を読むとそこでgetsって書いてある。 そこでgetsってやって、……あれ、返事がないなあ、と（笑） いや、Windowsの場合はgetsってやるとそこで止まっちゃうんだよと。 今はちゃんと、DRbでも返ってくる。
そういうわけで、着実にWindowsでRubyをまともに使えるようになってきている。 要するにこれなんですかっていうと、その場その場でちゃんと直してくれる人がいるから。 みなさんも問題みつけたら自分で修正するといいね。
── 本書の執筆以外の活動について、何かこの場で宣伝しておきたいことがあれば教えてください。
arton: Rubyの本は前に書いたやつだけど、 Ruby（１）はあまりに初心者向けなのであれだけど、Ruby（３）はやっぱり、ある程度中級の人も読んでほしいよね。
Ruby（２）も地味に良い本だと思ってるんでよろしく。 なんか死ぬほど難しいらしいよ（笑） 俺はそうは思わないけど。
── あれは（１）はむちゃくちゃやさしいんですよね。
arton: うん、知ってる。
── なのに（２）があれですから。
arton: でも、（１）の路線で（２）を書きようがないじゃない。 ライブラリの説明のふりをして、ある程度コンピュータサイエンス的な話題につなげようとすると、 あんまり細かいことを懇切丁寧に（１）の調子で書いてたら、たぶん終わんないと思う。 逆に、（３）ってその意味じゃ、OOPってこういう書き方をするんだよ、考え方をするんだよという本だから、 あれで逆にやさしく揺り戻しが来てるかもしれない。
その意味じゃ、順番は（１）、（３）、（２）の方が良かったかもしれないな。 ３はサイエンスじゃなくて、経験的なOOPだからね。 こうしたほうがいいよの世界。
なので、RubyでOOPという時には、（３）はちょっといい本かもしれないよ。
ただ、自分で読んでて思うんだけど、花井さんのパートはちょっと難しいかなと思った。 デザインパターンのところ。 あそこは花井さんが力を入れて書いたので、やっぱ力入ってるな というのがよくわかるんだけどちょっと難しい。 そのあとのフレームワークやテストユニットのところと、 すごく落差があるよな気がするんだよな。
でもデザインパターンってあれは、 もうちょっとやわらかく書くことは可能かもしれないけど、 とりあえずはまあ、ああいう世界だよな。
結局デザインパターンはそれぞれいろいろあるんだけど、 あの本の文脈で分かりやすいのは、多態をいかに、 というか群を、いろんな処理をいかに一つのコードで扱うかというところ。 まあ結局はポリモーフィズムの書き方なんで、あの配分になるのは当然なんだけど。
で、とにかく編集の方から、 「継承」「カプセル化」「ポリモーフィズム」、これはもう絶対あるの当たり前でしょ、って。 それはまあ当たり前っていうか、なかったら逆に変だって話になるよなあ……。 やっぱそこからはじめるか、と。それで多態にどうふっていくか、という書き方だからわかりやすいと思うし、そこからデザインパターンへつながるのは自然な流れではあると思う。
あの本の最後はユニットテストになるわけだけど、 ユニットテストがあるのはフレームワークの例としてもいいじゃん、っていうのはあるから。 使うって意味になるとフレームワーク的な考えってすごく重要じゃん。
まあオブジェクト指向全体がそうなんだけど、 「呼ばれる」っていうのをすごく意識しないとだめじゃん、 呼ばれるのを意識するからポリモーフィズムみたいなのも出てくるわけだし。
というわけで、あれは正直、我ながら上手く説明できてるような気がします。
── 最後に、これからこの本を読もうとしている読者へ向けて、何かメッセージをいただければ。
arton: メッセージねえ。メッセージとか偉そうだから嫌なんだよな。「買ってね。」（笑）
買ってねはともかく、そういう意味では簡単で、「Rubyの明日は君のコードにかかってる」。 まさにそういうことなんで。Windows版は特に死ぬも生きるも君次第。
あと何よりもやっぱり、 Rubyのソースコードを手元に置いて眺めるっていうのはすごく勉強になると思う。 それは眺めてるだけじゃ意味がなくて、いや、眺めてるだけでもいいかもしれないけど、 やっぱりmakeした方がいいし、 ソースコードがあって眺められてmakeして、Ruby組み立てられるんだったら、 さらにデバッガでどう動くのかを眺めて、メモリーダンプで構文木を追っかけたりしたり、じゃあここのノードにこう余分なもん入れたらどうなるんだってね。 俺はここはこうしてみたらどうだって、 それをさらに提案してみたり、っていう風に。
Rubyをいじくるっていうのは、 『たのしいRuby』を読んでRubyのプログラムを作れるようになるっていうとは別に、 Rubyのソースコードを読んで、Rubyの動作に踏み込んで、直したり改良したり、 提案したりするっていう方向が当然あるわけで。 こっち側っていうのはこれまであまり文章化されてなくて、 それがなぜか知らないけど、こうすればとりあえず作れるから、 ここからはあなたにおまかせ！っていう変わった本なので、 お買いください（笑）
── どうもありがとうございました。