僕がEclipseアプリを書く6つの訳

徐々に増えていきそうですがとりあえず><
よういちろうさんのBlogを読んで、これだけはまとめておきたい!と思ったので書く。ときたま拡大解釈しているけど、その辺は許して。

(1) 何もしなくてもプラグインベースで拡張できるアプリが作れる。

Eclipseをベースにしたアプリケーションは自動的にプラグインベースで拡張できるアプリケーションになります。EclipseのMLを見てると時たま「RCPにAPサーバつっこんでリモート操作したいんだけど…」なんて、それはアプリケーションと呼んでいいのか?と言う拡張も見かけたりしますが、基本的に何でもあり。

(2) 主要なOSのサポートがされている。

言っとくけどテストせずに動く、なんて便利なものではないからね。Adobe AIRもマルチOS対応ではあるけれど、Linux版だとリリース当初は日本語IMEが未サポートだった、と言う話もあったので、一日の長があると言えます。*1 *2 ブラウザの互換性とかも気にしないで済みます。

(3) 行くところまで行っているツールは未だブラウザ上で表現しきれそうにない。

XMindとか、2D系の描画ツールはブラウザで表現するのは未だ大変。もちろんそういうライブラリが登場しているのはわかっているんだけれども、それは描画する、と言うDraw2dのレベルで、GEFのように標準でUndo/Redoのアクションまで作れるようなMVCフレームワークは見たことがない。サムネイル表示とかもガッツリ頑張る必要がある。他にも録音するとか、ハードウェアに直結しそうなアプリもWebアプリだとむずいよね。iPhoneとか携帯アプリになると話が違うけど。

(4) ブラウザすら1コンポーネント

いざとなればFlexJavaScriptをのっけられます。そういう用途にコンポーネントのブラウザを使う事はほとんどないでしょうが、Markdownのような簡易記法をサポートするエンジンを組み込んで、それを描画するためにブラウザを使うのは結構強力だと思う。JAM Circleでやってみたけど。JazzTeamServerとかだとブラウザ上のレイアウトとかも拡張ポイントで拡張できるようにできるので、一回見とくといいと思う。

(5) 設計に頭を使うけど、コンポーネントを綺麗に作れるし、そのすっきり具合がきもちいい。

Eclipseプラグイン開発に良くある10の過ち - Fly me to the Juno!でも書かれていたけど、プラグイン構成を作ろうと思ったらあまり大きなコンポーネントを一つだけ、みたいな構成をとらない。むしろ他から利用しやすいように適度な大きさでコンポーネント、つまりプラグインを分割する方向に作っていく。
適度な大きさのコンポーネントは扱いやすいくて分かりやすい。一つ作ったらまた別のを作って…、と言う感じで、漸進的な開発ができる。ふつう漸進的な開発って言うとたまねぎみたいなモデルを想像するとおもうけど、これはたまねぎがツリーグラフみたいに根っこから増えていく感じを想像してほしい。(って言ってもむずいか。)

(6) 幾つかのアプリケーションを同時に作れる。

コンポーネントを適度な大きさで作ると幾つかのアプリケーションで使いまわししやすい。元々EclipseのPlatform自体も複数のアプリケーションをサポートしている。起動引数に-applicationが与えられるのだけど、それによって起動するアプリケーションを切り替えることができる。実はEclipseプラグインのビルドをUIなしで、コンソール上から叩こうと思ったらEclipse上に組み込まれたAntのアプリケーションを実行しているだけだったりする。(ていっても、実行時にインストールされているプラグインによって、Ant Taskが追加されていたりもしますが。)

...とりあえず今日のところはこの辺で勘弁><

ユーザーエクスペリエンス的にはブラウザアプリでもう十分、と語られることが多いけど、本気出して作りこむとまだまだリッチクライアントにはいろんな理由で勝てないと思ってます。ローカルにデータベースを持ちたい、とかね。できるけど、あんまり便利じゃなかったり。

で、みんな敷居が高いっていうけど、超簡単って偉い人が言ってたよ。覚えることがとても多い期もしますが、ブラウザごとの違いとかのバッドノウハウの蓄積に比べたら楽なもんだと思う。

*1:Mac Cocoaのサポートはようやく、と言う感じですが。

*2:JAM Circleのダウンロード数を眺めていると、Windows:Mac:Linux=45:2.5:2.5くらいの勢いw。