インテリジェントフォーマッターあるいは自動化リファクタリングであるコードコンプリートを支援するIDEなしで、JavaオーダーC#コードを記述しようとするデベロッパはほとんどいないであろう。動的言語の世界においては、大/小文字はそれほど明確ではない。
その1つの理由は、静的言語と肩を並べるツールが確かに不足していることである。それは単に動的言語のツールの構築は、ずっと難しいという事実があるからだ。幸い、こうした言語で記述されたプログラムは、一般的にたとえばJavaで記述されたものより短くなる傾向があり、冗長が少なくなる。
それでも、ときとしてソースコード管理ツール、プロジェクトファイルのナビゲーションからプロジェクトのコンパイル、デバッグおよび配置に至るまでの、デベロッパの日常業務をすべて網羅する統合開発環境があれば便利なことがある。
このシリーズでは、動的言語のIDEに携わっている人にインタビューをおこない、IDEの現状についてその概要と考えを聞いた。
すべてのIDEが強調表示のような基本動作を処理すると仮定するので、それゆえリファクタリングのような高度な機能に焦点を置く。自動化リファクタリングをおこなう機能は、IDEの成熟度を示すよい指標である。その訳は、それにはソースコードの詳細な分析および重要でない分析があり、言語に無知なエディタ が容易に提供することができず、かつサードパーティーのツールなしでは、提供することができない機能の1つだからだ。
Aptana Ruby
EclipseベースのRuby開発ツールは長年存在してきて、広範にわたり使用された。特にRadRailsにより提供される拡張子を通じたRailsの開発において使用されてきた。少し前にRDTおよびRadRailsは、両者ともAptana Studio(リンク)に統合され、RDTの主力デベロッパであるChris Williams氏はAptanaに採用されている。
AptanaのRuby Studioではたいして目だった動きがなかった。そこでChris氏と情報交換をし、現在の状況について聞いた。
過去半年から7カ月間、新たなオファリングに取り掛かってきた。Aptana Cloudである。Aptana Studio、サードパーティーホスティングプロバイダおよび、Webサイトをホストする実際のボックス間の調整をするAPI/サーバに関するすべての作業に取り組んできた。結果として、通常、RubyサポートやRadRailsに ささげるほど多くの時間を費やすことができていない。今回以降、基本的にバグ修正をしていて、時間を見つけてはクラウドのサポートをツールに統合し始めて いる。クラウドが正式に発表された今、Railsをサポートする作業に乗り出し、それから多かれ少なかれ専任でRDT/RadRailsに再び着手するこ とができる。
Chris氏はまた、「プラグインにおいて、開発が着実に進んでいるようにするため」さらに採用を検討していることを述べた。 IDEの拡張を望んでいるRubyデベロッパは、Javaをプログラムする必要がない。
エンドユーザがEclipse Editor APIの小セットに対し、Rubyコードを記述できるようにするプラグインがある。したがって、Rubyだけを知っている場合、小さなマクロ/スクリプト をそれを使って記述することで、実際に大いに役に立つだろう。また、JRubyのエキスパートなら、おそらく独自の拡張子を記述して、Rubyに接続して 完全なEclipse APIにアクセスすることができる可能性がある。
注：JRuby Eclipseのスクリプト記述機能については、以前InfoQで取り上げた(参考記事)。
Aptanaは、Ruby、JavaScript、PythonおよびPHPに対するサポートがある。次は、どんな言語か?
Web開発プラグインという観点から見て、コミュニティが望んでいるものをわれわれはつねに追求している。十分なサポートが見込めれば、確実にそれを追い求めるつもりである。われわれはつねに一心に耳を傾けている。何が実現されたらいいか、われわれに知らせて欲しい。
次のステップに含まれるのは、Studioを現在のEclipse Ganymedeリリースに移行することである。「高機能なクラウドサポートをもう少し追加し、重要なバグを修正し、1.3.x RadRailsのタイムフレームで、一息入れて、次は何をするかを再び計画することになるだろう」。
Rubyの開発ツールは、今となってはかなりの期間リファクタリングサポートがある。たとえば、さまざまなリネームリファクタリングの実装、抽出、移行お よびメソッドのインライン化である。どんなときでもリファクタリングは、しくじりようがなく、正しいというわけではないが、ほとんどの一般的なケースで機 能し、手でコピーアンドペーストをするより、相当改善されている(このテキストの作成者がその実装に加担したことに注意)。
Aptana(参考記事リンク)またはRadRails(参考記事リンク)タグは、Aptana IDEの関連コンテンツをさらにリストしている。
DLTK Ruby
動的言語IDEがEclipseで必要とするすべての再利用可能なコンポーネントを1つのフレームワークに統合しようする場合、動的言語ツールキットは、 興味深い場所にある。それゆえ、新たな言語サポートの実装が簡単になる。Rubyは、最古のDLTK言語の1つである。またTCLと共に、DLTKの中核に属する。
悲しいことに、DLTKでは目立った動きがなかったので、プロジェクトリードであるAndrey Platov氏に話を聞いた。
TCLと言えば、DLTK TCLがすでに最高のTCL IDEであるととらえている。実装を高度にし、TCLインタープリターベンダーとの統合に取り組んでいる。そうした作業は、事実あまり知られていない。
Ruby(および一般的なDLTK)に関して、まず最初にDLTK(Rubyコンポーネントを含む)は、プラットフォームである。エンドユーザが要求した 機能をすべて網羅するつもりなど、始めからない。たとえば、 Ruby on Railsサポートを提供する計画などは、なかった。DLTK Rubyが目指すところは、それに加えて、完全な機能を備えたツールを構築している他のベンダーに対し、堅固で分かりやすいRuby言語の基盤を提供する ことである。1つの好例は、CodeGearによる3rdRail(リンク)と呼ばれる、包括的なRuby IDEであり、DLTK Ruby上に構築されている。
上記のすべてが、DLTK Rubyが使い物にならないスタンドアロンだということを意味しているわけではない。Rubyソースコードと機能する素晴らしいツールであるため、多数の 言語マニアによって使用されている。なので、デベロッパにRuby on Railsスタイルを強要しないし、RSpecについて述べるように強制しない。単に純粋な言語であり、デベロッパの創造性である。別の観点から見ると、 そうした「クリーン」なIDEは、自分で選んだフレームワークやテクノロジーをサポートする製品を構築する素晴らしい機会をベンダーに提供する。また、そ れらはすでに無償の言語サポートがある。
質問に戻ると、われわれの現在の作業は、DLTK Rubyがより言語を「理解する」ようにし、Rubyソースをさらに適切に処理するようにすることである。
「コードコンプリート機能を試してみてはどうか」とAndrey氏は指摘している。今後は、言語サポートを改善し「コード分析や、リファクタリング、クイックフィックス機能のようなRubyをより良く理解する」計画がある。
DLTKの側面では、現在追加の言語サポートは予定されていないが、「彼らのIDEでIDEをおこなっている企業に助言を求めている」。また、 Andrey氏によると「DLTKに加えて、PHP Development Tools (PDT) 2.0がリリースされる予定である」。また、ANTLR、Lua、D、PerlおよびScheme向けのDLTKベースのIDEが製作中である(リンク)。さまざま なDLTKビルドおよびパッケージがDynamic Languages Toolkitダウンロードサイト(リンク)で利用可能である。
このニュース項目は、動的言語IDEに関する継続中のシリーズの一部である。InfoQの「DynamicLanguageIDEs」のタグ(参考記事リンク)で、他を参照 することができる。まだRuby IDEについて十分でなけらば、InfoQの記事、NetbeansのRubyサポート：パート1(参考記事)、パート2(参考記事)を参照してもよい。