Servlet Garden

NetBeansのRuby Packを開発された方々のお一人であるTor Norbye氏へのインタビューがOn Ruby: NetBeans 6.0: Interview with Tor Norbyeに掲載されていました。とてもおもしろそうな内容なので、勝手に和訳してみました。

RubyとRailsの開発を十分にサポートしているNetBeans 6.0がリリースされたニュースをみました。Tor Norbyeや他のNetBeans開発に携わった人達はその成果からして、称賛されるべきでしょう。

Torは時間をとってくれて、RubyとNetBeansについての質問に答えてくれました。以下がその内容です—

ーーーーーーーーーーーーーーーーーーーーーーーーーーー

Emacsやvi, textmateなどのカスタマイズに熱心なRuby/Rails好きの人達でも、わざわざNetBeansをダウンロードして試してみるべきである理由は何でしょうか?

Tor:
NetBeansには彼らの生産性を向上させると思われる機能がいくつかあります。彼らは開発環境をNetBeansに切替えたくないかもしれませんが、少なくてもツールボックスにいれておいて必要なときに引っ張りだして使えばいいでしょう。

(1)まずは、統合されているデバッグ機能です。ちょっとしたセットアップ(fast ruby debuggerのインストール)をすれば、簡単にRubyとRailsアプリケーションをデバッグできるようになります。デバッグ時には一行ずつの実行したり、ブレークポイントの設定したいr、call stackやローカル変数の値を調べたり、データ構造の中身をのぞいたりといったことができます。エディタ上で変数にカーソルをあわせるだけでツールチップスとして現在の変数の値をみることもできます。このようなデバッグ機能はRubyファイルだけではなく、ERBやRHTMLファイルでも同様に使えます。

(2) 私がお薦めしたい2つめの機能はセマンテック・エディットです。この機能は構文解析のツリーを利用してNetBeansが追加機能を足せるようになっているものです。もっともわかりやすい例はクイック・フィックスです。手短に言うと、クイックフィックスは構文解析ツリーを参照して発生しそうな問題を探すセマンティック・チェッカです。問題が見つかった場合、エディタ左側のスペースに小さな電球を表示して、問題があることを警告します。ユーザを警告を見て問題を見つけて、どのように解決するか判断できるようになっています(通常、セマンティック・チェッカは自動的に問題を解決できるような選択肢も用意しています)。

したがって、クイックフィックスは”Rubyのlint”のような機能です。この機能があるので、もし今のエディタを使いつづけたい場合でも、ときどきNetBeansでソースコードを開いてコードをチェックしてもらいたいと思うでしょう。チェッカで調べられるバグは次のようなものです：

• ・意図しているクラスの属性の代わりに間違えてローカル変数を代入してしまった(よくある間違いについてはすでにPickaxe本(注:Programming Ruby; The Pragmatic Programmer’s Guide; Dave Thomas, Chad Fowler, Andy Hunt著)にリストアップされています。私はこの本でRubyを勉強しましたが、NetBeansで本にリストされているような問題を見つけ出す機能をつけようと決めたため、すぐにそのページの端を折りました。最近は折ったところは元にもどしたのですが:))
• ・間違えて、ローカル変数をブロック変数として再び使ってしまった
• ・間違えて、ifブロックの中で変数の値を代入してしまった
• ・DeprecatedとなっているRails APIを使っている(例えば、sessionの代わりに@sessionを使っている、あるいはlink_toの代わりにlink_to_imageを使っている、など)
  　　(このようなヒントのうち大多数はNetBeans6.0をダウンロードしたままでは有効になっていません。NetBeansのToolsメニューをから6.0 Stable Plugin Centerにアクセスしてください。(注:Available Pluginsタブをクリックすると表示される一覧のうちRuby Extra Hintsプラグインと思われる)RubyHints wiki pageに現時点で可能なヒント全てのリストがあります。)

(3) 他にも便利だと思うような編集の機能がいくつか使えるようになっています：

• ・メソッドを抽出して変数を追加する：この機能を利用すると長くて複雑なメソッドを簡単に小さなメソッドに分割できるようになります。ここでも、構文解析木を使ってNetBeansは確実に正しくコードのフラグメントを取り出します。フラグメントは全ての必要な入力を受け取り、また全ての出力を戻すようにできています。
• ・リファクタリングによる名前を変更する：Javaほど正確ではありませんが、search/replace機能を使って名前を変更するよりも信頼できる機能です。これは、例えばNetBeansはローカル変数”foo”への参照を関連のないメソッド”foo”と間違えることはないためです。
• ・宣言部分に移動する：この機能があると素早くクラス内の目的のところへ移動できます。新しいクラス内を見て回るのに便利です。

(4) ERB/RHTMLの編集機能があります。ほとんどのエディタはRubyだけをサポートしているのみで、ERBファイルについては同等のサポートがありません。例えば、クイック・フィックス、リファクタリング、再フォーマットの機能はすべてRHTMLファイルに対しても有効なので、ERBファイルを編集することがよくあり、ERBファイルを再フォーマットしたいなどの場合には、そのためにNetBeansを使ってみたくなるでしょう。

とても長い道のりであることがわかってきましたが、（面白いので）止められません。:)

うまく動くようにするために、一番たいへんだったのは何ですか？

Tor:
なんといっても型推測ですね。正確に行うのは不可能です。幸いにも、特にRailsはたくさんあるパターンのどれかに一致しているので、NetBeansはできるだけ多くのケースでうまく動くものを見つけるといったヒューリスティクスを使えました。私はリリースの直前までこの方法をチューンアップしましたが、その過程でいろいろと勉強しました。しかし、終わった作業が増えれば増えるほど、TODOリストが新しいアイディアでどんどん長くなってしまっています…

未だにやらねばならないことがたくさんあるのはどこですか？

Tor:
型推測はなんといっても今後予想される作業が一番ありそうなところです。—きっと、向上させるためには10年かかるでしょう。しかし、私は現状の推測のレベルでいいと思っています；おそらく、Rubyユーザはこの機能を信頼できるとき、できないときに私たちがやってきた推測の総量を知ることになるでしょう。私には、次のリリースで行いたいと思っていることがいくつかありますが、それらはどれもすごいという部類のものではありません。

今、もっとも弱い部分は(IRBやRailsコンソールを動かすための)ターミナルのハンドリングだと思います。ほとんどのRailsツールはターミナル・エスケープ・コードを発して、出力に色をつけるのが好きです；例えば、RSpecはサマリを色付けして目立つようにしていますし、ActiveRecordはSQLのログ出力を色付けしています。NetBeansのoutputウィンドウはターミナル・エスケープをサポートしていませんので、現在は単純にコードからエスケープを取り除いているだけです。将来的には、完全な機能のあるターミナルエミュレーションが必要で、IRBを動かすのに必要な”readline”をきちんと扱えるような仮想ターミナルをサポートする必要があります。同様に、IRBセッション(あるいはRailsジェネレータのようにスクリプトも実行できるもの)をIDEの統一的な色つけやコードコンプレッションなどと結び付けることもかなり需要があるでしょう。

もしも、魔法の杖を振ることができて、NetBeansになにか一つRuby/Rails関連の機能を追加するとしたら、それが何でしょうか？

Tor:
おそらく、先ほど触れたoutputウィンドウの機能強化でしょう。以前、ターミナル・エミュレータのコードを眺めたことがあるのですが、これを再びやりたいとは思わないので…

IDEではないツールのうち、ルビイストがもっと使うべきと思うのは何でしょうか？

Tor:
Rubyの世界で私がやや足りないのではないかと思うのはドキュメント作成関連です。ほとんどのクラスはファイルの冒頭部分に詳しい解説があるのに、各メソッドや属性については大抵、控えめというか、あまりドキュメントがありません。これはおそらく、ユーザは使っているライブラリのどのソースコードを見ようとしているときに、何気なくファイルの冒頭部分だけを見てライブラリが何であるか調べようとしているからでしょう。このような方法はコード・コンプレッション(あるいはriでさえも)のような何かを経由してAPIをいろいろと調べたいと思う人には役に立ちません。ライブラリのうち、どれが”exported API”で、どれが”実装”メソッドで外部から使用されべきではないといったことが明らかになると便利です。NetBeans 6.0開発サイクルの最後に私が追加したもののひとつに、コード・コンプレッション・フィルタがありますが、これは”# :nodoc:”のマークがあるメソッドを対象外にするフィルタです。これですこしはましになりましたが、それでも、これは実装であり、クラス外にさらすべきではないと思われるような、#:nodocの対象となるべきコードを多数見てきました。つまり、私はもうちょっとドキュメンテーションが向上してほしいと思っています。これは、まぁ、ツールそのものの問題ではないのですが、できれば私は”rdoc”をもっと使って、自分が書いているコードのドキュメントをみるように主張したいと思います（またここで、話をIDEに戻してしまってすみません—1996年以来ずっとIDE分野で仕事をしてきたので止められないんです。ドキュメンテーションをサポートするために私がNetBeansに追加した機能は、コメントを書いているときにCtrl-SpaceをタイプするとHTMLビューがポップアップして書いているコメントを表示してくれるものです(RDoc変換は全て実行されています)）。

とにかく、Rubyコミュニティに参加すると楽しいですよ。とても熱心で、優れたプログラマがたくさんいますからね！