RadRailsのバージョンが1.0へ - Profiler,CallGraph Analyzer,Rails Shellが追加

作者 Werner Schuster, 翻訳者 長部 広太 投稿日 2008年3月27日 午後6時40分

コミュニティ

Ruby

トピック

Ruby on Rails,

デバッグ,

JRuby,

プログラミング,

パフォーマンス&スケーラビリティ

タグ

Ruby on Rails,

RadRails,

Eclipse,

Rails,

JRuby

RadRails(サイト・英語)は、Aptana IDEの一部で、現在version1.0の利用が可能だ。人気のRails開発ツールは、この間いろいろなものがリリースされた。しかし、この最新バージョンのRadRailsは、RubyやRuby on Railsの開発者に対して役立つ新機能を追加した。RadRails、Netbeans及びCodeGearの3rdRailの機能に関して十分な比較(source)が利用でき、その比較によるとRadRailsはリファクタリング及びプロファイリングのサポートが他のふたつの開発環境よりも充実していることが分かった。もう一つのRadRailsの特徴はRails Shellである。Rails Shellを使う事によって、Eclipse IDEの内側からRailsコマンドを実行出来る。これはコマンド等の引数の自動補完機能が付属している。(スクリーンキャストを見ると、Rails Shellの機能(source) を使っていることが分かる。) 

我々は新しいリリースについて、AptanaのChristopher Williams氏から話を聞いた。 Christopher氏は、2007年にAptanaに雇われ、Ruby Development Tools(RDT)に関する仕事を継続している。RDTはRadRailsの元となったものだ。  

RadRails 1.0は、Rubyのコードのプロファイリングをサポートしており、メソッドのランタイムとコールグラフをGUI化する機能を備えている。Christopher氏は、これがどのように実装されているかを説明してくれた。

プロファイラーは、基本的にruby-prof gem をラップしたものだ。我々はruby-profバイナリスクリプトからRubyスクリプトの実行をラップした。そして一時ファイルへ出力するように指令を出しました。そしてスクリプトの実行が終わると、我々はアウトプットを掴み、それを解析して、Call GraphとSpots viewsを生成します。この機能はまだJrubyでは利用出来ない。理由はネイティブなCコードに相当する、Java版のruby-prof gemがまだ存在しないからだ。それが作られれば、すぐにでもサポートされるだろう。

その機能の先にあるものに関して：我々は、修正したruby-prof gemに取り組むかもしれません。それは、ruby-debugのruby-debug-ide gemと同じ振るまいをするであろう。基本的に、プロファイラーへリモートからの接続とプロファイリングに関連し且つソケットを超えたリアルタイムなコマンドを送る事が出来ます。だから我々はアプリケーションを終了したら、出力を捕らえる代わりにスナップショットを撮れるのです。または、JRuby互換のruby-profを作るかだ。そうだとすると、我々のユーザが何を求めているかということに依存し、それは全く新しい機能となる。だから我々は丁度、機能強化に関するリクエストを貰い始めたばかりだ。

RDTは、Eclipse デバッガーGUIでRubyコードのデバッグを長くサポートしてきた。Eclipse デバッガーGUIは、より処理速度が早いruby-debugをサポートしている。RadRailsもjruby-debugを含めて出荷される。jruby-debugはJRubyのデバッグをサポートした、より処理速度が早い実装である。

はい、RadRails 1.0で我々は現在ruby-debug gemのJRubyバージョンをサポートしています。それで、現在早いJRubyのデバッグオプションがあります。実は我々はJRubyにそれをプリインストールして出荷しています。

RadRails 1.0の機能リストには、Rubinius(source)という名前が含まれている通り、Rubiniusがサポートされた。Christopher氏は、サポート状況を説明してくれた。

現時点で、それはRubiniusをRubyプロセスを起動するためのインタープリタとして使う用途に限られています。Rubiniusがより強力になったので、それでgemsとRailsを試用することはより役立つであろう。Rubiniusに特有の機能というものが現時点ではありません。(たとえJRuby又は標準のRubyの仕様的な機能がないとしても) 我々は、次と同じくらい完全に各々のインタプリタをサポートしようとしている。JRubyとRubiniusでそれが新しいgemまたはアップデートされたコードがより多くの機能を可能にすることができるのを待つのが問題です)

もし多数のユーザーがRubiniusを使用し始めて、デバッガーが懐かしいとユーザが我々に語り始めとしたら、デバッガーの統合に向けて作業します。我々がruby-debugを使っているRuby用のデバッガーを作成した際、我々はコードを共有するためにKent SibilevとMartin Krauskopfと働きました - そしてそれはIDEがruby-debugと統合する共有ライブラリをまとめることで終わりました。それで、RDT/RadRailsとNetbeansをデバッギング・バンックエンドと統合するための一種のデファクトスタンダードが既に存在します。それはソケットを開いて、これらのXML命令を読み取るためにRubiniusのデバッガーを中継することの問題です。もし誰かがそれに取り組みたいのであれば、私かマーティンに連絡を下さい。それは、RubiniusのデバッガーがNetBeansやRDT/RadRails上で効率的に動くようにします。

共通のデバッグキングプロトコルの実装が、debug-commons(source)プロジェクトのRubyForgeで利用出来る。InfoQは、Rubiniusのフルスピードデバッガーに関してリポートした(source)。これは現在、共通のデバッギングプロトコルでサポートされておらず、異なるプロトコルバックエンドを必要とし、フルスピードデバッガーAPIを利用している。 

RadRailsが、Ruby on Railsの開発用のIDEであるにも関わらず、将来それは他のフレームワークをサポートするかもしれない。

今現在、他のフレームワークに対応して欲しいという大きな要請はありませんでした。明らかに、我々はRailsに集中していますが、フードの下には完全に機能的なRuby IDE(RDTで作られた)があります。非常に人気なフレームワークが出現し、利用者からそのフレームワークをサポートして欲しいという要求があれば、我々は確かにサポートすべきかどうか調査するでしょう。

関連した話では、何人かのユーザーは、ブラッドウィルソンのHAMLとSASSエディタを使用していました。残念な事に、最近のリリースでは、RDTとの統合はなくなってしまいました。そしてBrad氏には、それを最新にしておく時間がありませんでした。我々は彼と共に働き、彼のエディタをRadRailsに移植し、その結果それらを維持していけるようになりました(可能ならそれらを向上させる)。

RadRailsとAptanaは、EclipseMonkeyを使っているRubyでスクリプトが書ける(source) - Christopher氏は、この機能の考えを後で話してくれた。

私が、EclipseMonekyとJRubyを統合していたときに、見に来た人の多くをつかまえ、その人たちが「RubyでIDEのスクリプトを書く事ができるんですよ」と言ってくれることを望んでいました。しかし、これまで、コミュニティは私が期待した程、それを全く受け入れませんでした。エンドユーザーのために彼らが、コンパイル ステップ、Eclipse SDKのダウンロードや、ソースコードをチェックアウトする必要もなく新機能を反復的に開発出来るのではないかと理解しました。そして永遠にそれを理解するのに悩むのです。あなたはちょうどRuby又はJRubyのコードを書いて、スクリプトを走らせ、編集し、そして再度実行させます。そしてDOMを使って遊べる、小さくてシンプルなAPIを提供できる。そしてそれはRuby APIのような感じがします。

AptanaやRadRails1.0を始めたり、単純に機能を見たいなら、機能をまとめたスクリーンキャストが利用出来る(source)。

原文はこちらです： http://www.infoq.com/news/2008/03/radrails-1-0-profiler-railsshell

• 次へ >