callistoｷﾀｰ

Java

callisto、っつーかeclipse3.2とその他モロモロがついにリリースされた。callistoってのは、eclipse3.2とその他のeclipse.org製プラグインを同じタイミングでリリースして、「このプラグインと、あのプラグインを同時にいれたら動かねー」みたいなバージョン互換性の不確実性を排除して、簡単にeclipse+そのたもろもろを使えるようにしましょう、っていうプロジェクトのこと（だよね？）

eclipse3.2RC7の段階ではなぜかウチのカンキョウではVEがまともに動かなかったのだが改善されてるのだろーか。

  • >改善されてた！

New and Noteworthyを見て気になった機能を以下にズラズラ。

Platform

  • Project Explorer viewの追加。Package ExplorerとNavigator viewが合体したようなもの。
  • History Viewの追加。Eclipse local historyとCVSの履歴を一緒に表示するようなビュー。便利そう。てかそろそろSubversionクライアントの機能を標準装備してくれ・・。
  • Pervasive filtering support。要はインポート、エクスポート、新規作成ウィザード、show viewダイアログなどのフィルタリング機能。たとえば新規にクラスを作りたいときは、新規作成ウィザードを開いて、"C"と打ってやれば"C"から始まる新規作成可能な要素(Classとか)だけが表示される、ってかんじ。日本語化しても機能してくれると助かる。

JDT

  • Indirect Refactoring。いわゆるUtilクラスを簡単に作ってくれる機能。
  • Extract Superclass refactoring。スーパークラスぶっこ抜き機能。おぉ、すごい。とは言ってもクラスの宣言だけをまとめて変更してくれるだけで、共通機能を自動的に探してスーパークラスに移動、みたいなことはしてくれなさそう。あくまで宣言レベル。
  • Clean Up Wizard。プロジェクト中の全ての警告を自動修復したり、コードフォーマットを一括整形したり、インスタンスフィールドにアクセスするコードを必ず"this."で始まるように自動修正したり、できるかぎりの箇所に"final"を自動的に付けるようにしたり、Java1.4のforループを自動的に5.0の拡張forループに変換したり、といったようなことを一括で行えるウィザード。すごい。
  • リファクタリング・ヒストリーダイアログの追加。
  • Surround With機能。選択したコードの断片を、try-catchで囲んだり、if文で囲んだり、synchronizedで囲んだり、Runnableの内部クラスとしてくくりだす機能。
  • JavaSE6.0対応。はえー。
  • Null参照の自動解析。nullっぽいオブジェクトを教えてくれる。えらい！
  • 無意味な$NON-NLS$タグの検知。文字列の外部化に使用する$NON-NLS$タグが、無意味な位置（文字列リテラルが無い行など）に記述されていたら教えてくれる機能。
  • JUnit4サポート。まだ使ったことねえ
  • 実行環境（JVM）が選べる。いままではビルド時のコンパイルモードを選べたり、参照するStandard JRE Librariesを選べたりはしたけど、実行するVMそのものは選べなかった。
  • 破綻した外部化文字列の検索。ありがたい。

Platform&SWT

  • Tabbed propertiesフレームワーク。GMFとかでお馴染みの謎の横向きタブプロパティービューの追加。タブが横向きのメリットは！？
  • JFace field assistance。JFaceのテキストフィールドとかのバリデーション結果表示のために、小さいアイコンを表示したりHoverText表示したりするのが簡単になった。
  • JFaceのTreeViewerがSWT.VIRTUALに対応！これはちょっと興味があるので後で調べる。
  • Welcome画面の設定が可能。eclipse初回起動時に表示されて、即効で閉じられる、あのケバケバしい画面ですね。いらねー。
  • TableとかTreeが、よりWindowsっぽく！カラムの入れ替えが出来たり、WindowsXPテーマが取り入れられたり。
  • っていうか、SWTでWindowsのUIっぽいものをたくさん実現できるようになってる。windowsタスクバーにアイコン追加したりとかも可能。
  • OpenGLサポート。SWTの中でOpenGLインターフェースを呼べるようになった。

Plug-in Development Environment

  • いろんなOSGiフレームワークに対応。うん、、よく知らん。
  • Automated management of dependencies。いままでは、まずplugin.xmlに依存したいプラグインを追加して、その後でコーディングっていう手順を踏んできたけど、今回からはコード中で他のプラグインに含まれるクラスを参照していたら、勝手にdependenciesに依存プラグインを追加してくれるようになった。こりゃちょっと便利。
  • プラグインマニフェストファイル(MANIFEST.MF,plugin.xml,build.properties)のためのQuick Fixサポート。

Eclipseに見る開発サイクルの秘訣

Java

【レポート】JavaOne 2006 - IBM General Session: Eclipseに見る開発サイクルの秘訣 (MYCOMジャーナル)
http://journal.mycom.co.jp/articles/2006/05/19/javaone1/

ちょっと前の記事だけど。Eclipseがいかにして高品質なプロダクトを安定的に長期にわたってリリースし続けているか、というセッションのレポート。このセッションはすごく参加してみたかった（英語が理解できるかは別として・・）。

以下、気になった点（というかほとんど全文だけど^^;）を抜粋。

開発の段階ではFitnessは徐々に低下していくが、安定化の段階でそれを適切なレベルまで引き上げてからリリースする。各マイルストーンでは常にこのリズムでFitnessが上下する。たとえマイルストーンといえども、Fitnessが低下したままでリリースすることが無いという点がポイントである。このリズムによって、製品の品質を常に一定以上の水準に保つことができる。

初期段階では少人数のチームによって細かなアップデートを重ね、ある程度の段階でプロジェクトチームによる週単位でのビルド工程に移る。そして最後にコミュニティ単位でのマイルストーンの開発に着手するという流れである。このときに重要なのは、成果物を自分達で使用し、常にフィードバックを得ることだという。

まず重要なのは繰り返し処理や成果物の提供、プロダクトのパッケージングなどを容易にし、同時にリファクタリングを実施、APIの安定性を高めることだという。

そして・・
次に重要なのが、常にパフォーマンスを維持することだと説く。そのためには開発サイクルにパフォーマンス・テストを導入し、常にパフォーマンスを把握できるようにする。適切な分析のためにパフォーマンスの視覚化ツールなどを使用するのが望ましい。

最後のパフォーマンスの話は、最近ものすごく痛感している。パフォーマンスって、ついつい後回しになってしまいがちですよね。仕事でモノ作ってると「とりあえず動くものを」っていう空気がものすごく出ちゃうんだけど、このまま進んでしまうと、「とりあえず動く->パフォーマンスでない->設計からやり直し」っていう最悪のパターンになりえる。てか、ちょっとウチがそうなってる(T_T)。同じようにテストとかドキュメンテーションも、やはり後回しにしてしまいがちな工程なんですが、コチラの場合は修正はたくさん入ったとしても設計からやりなおし、ってことはあまりない。つーわけで今後はモノを作るときは、どれくらいのパフォーマンスが必要か、ってことを設計段階から重視してくように心がけたい。プラス、デイリービルドのプロセス内で自動テストと同時に、自動パフォーマンステストなんかも組み込んで、かつうまくレポーティングできるような仕組みができればうれしい。で、それを実践してるのがEclipseなんだろーなー。