1. Ryan Slobojanと申します。私は今Erich Gammaの隣にいます。Erich、Jazzプロジェクトについて少し教えていただけますか?
わかりました。Jazzは新しいテクノロジで、私も参加しています。私達がプロジェクトを始めたのは3年前で、Eclipseから得た本当にたくさんの経験を元に作っています。Eclipseを通じて私達はアジャイル・プラクティスや、分散開発について学び、開発やコーディングにパワフルなツールを使うことはどれほど素晴らしいかを学びました。
しかし私達はチーム開発の現場に摩擦があることも学びました。IDEから受けられるのと同じ十分なレベルのサポートをチームから受けられていないように感じています。だから私たちはチームのために新しい世代のツールが本当に欲しかったのです。そのツールはEclipseと同じ精神で、一般的なプラットフォームをサポートし、また拡張を可能にしたプラットフォームで、様々なツールを同一プラットフォームで動くように統合したかったのです。
そう、あなたのデスクトップの上と同じように、チームのためのツールとして統合しようと思ったのです。そしてこのシームレスな統合として、最初に注目したのは仕事を追跡するためのバグトラッキングシステムや、継続的なビルドをするためのビルドシステム、そして新しいコンポーネントベースで開発を進められるようなソースコード管理システムが欲しかったのです。そうすることで実装を高いレベルで協調してすすめられるような、簡単に流れを変更でき、平行して開発を容易に進められる環境を作っています。
これらを実現するために作ったのが、Jazzという技術プラットフォームです。このプラットフォームの上にはこの先Jazzを有効に使った様々な製品が出荷され、アプリケーションのライフサイクルをすべてカバーできるような製品群を手に入れることが出来るでしょう。ただ、我々が最初に力を入れたのは、実装だったり、ビルドだったり、仕事やバグの追跡、ソースの管理などでした。しかし、やがて多くの機能が成長をし、搭載されることになるでしょう。
2. あなたはJazzプラットフォームの最初のリリースをいつしようと考えていますか?またあなたはリリースされることによって何ができるようになることを期待していますか？
私はJazzは技術プラットフォームで、製品はその上に構築されると言いました。私達は昨年の6月に使えるようになったJazzをコミュニティにリリースし、それをbata1と呼びました。そしてbata2を12月に使えるようにし、bata3は4月4日にリリースする予定です。1.0に到達するのも6月の終わりに予定しており、もうすぐです。
そしてJazzは我々がRational Team Concertと呼ぶ製品の中に含まれる予定です。
「コンサート」という言葉が強調するように、チーム同士が協調し、そしてAgileなチームが求めていた高い透明性を持って仕事を出来るように、イテレーティブに繰り返し開発ができるように作っています。
製品の中にはソースコード管理システムや、ビルドシステム、バグトラッキングシステムが含まれています。
加えてこれまでに存在する技術とも接続できるように、例えばソース管理で言うと、Subversionとのブリッジを用意しています。Subversionを使い続けながら新しいテクノロジーに慣れていけるのです。
そうです。Subversionを使い続けながら、バグの追跡や、計画のサポート、そしてビルドシステムを使えるのです。
私達は他にも接続も用意しています。もちろん、Rationalが提供してきた技術、例えばClearCaseやClearQuestとの接続もあります。だからJazzに移行しやすいのです。私達は今、製品の出荷をするための終了フェーズの真っ只中にいます。
このリリースは6月の終わりにする予定だからです。いいですか?
ソフトウェア・エンジニアリング・カレンダー上はずっとその日が出荷予定日です。もしあなたが最初の四半期と呼んだものが最初の四半期の終わりを意味するなら、そのリリースは6月の終わりに行う予定です。
そこにはいろいろな理由があります。
一つはEclipse上に載せられた製品を開発している人たちがいることを知っているからです。ご存知ですよね?
Eclipseはプラットフォームで、そこには様々なレベルでの予測が必要です。それを私達にとって一番楽にしたかったのです。もしみんながいつものリズムに乗っていたら、誰もそれを覚えて無くてもいいのです。ただリズムに乗っていればいいだけですから。
だから年に一度のリリースにすることで、高い確度の予測にしています。年に一度、彼らが新しいEclipseのリリースを手に入れ、私達は年に一度のリリースのために計画と調整をすることで年の終わりにリリースすることができます。だから私達は本当に厳格です。
私達は失敗したくないから、機能を破棄することを選びます。
昔の人の「ユーザーは失敗したときのことは忘れないけれど、つぶしてしまった機能のすべてについては忘れてしまうだろう」という言葉は間違っていません。これは私達にはとても重要なことで、7年か、8年くらい6月のリリースを続けていますが、今では私達の誇りの一つになっています。だからこの日に固定することが出来ているのです。
そしてこれはチームにとってはもちろん名誉なことなのでそうするためにみんな活動することができています。6月はただその日のために、私は前にも話した事がありますが、6月だったらただその日のために活動できます。ちょっと他の月の制約に目を向けて欲しいのですが...あなたは年に1度のリリースを義務付けられているとします。
クリスマスの周りになんか終わらせることはできませんよね。夏の終わりとか、夏の最中に終わらせることもしたくないでしょう。なぜなら夏休みがありますからね。だから私達は本当に夏休みの前に終わらせます。
6月は私達にとって理想的な日程なのです。そしていつも私達をそこにあわせています。すぐに慣れましたから。そのほかの理由は、もう分かるでしょうけれど、私達はこれをつづけていますが、一度も失敗したことがありません。と言うわけなのです。
もちろん、ここは私たちの到達したかった見果てぬ夢だったのです。
私は様々なことがおこったと思います。いろいろ正しいと思うことをしてきました。例えば、知っていると思いますが、私達はこのアイディアのために拡張性という視点から設計し、構築しました。
拡張性にはスケーラビリティも含んでいますので、スケールできるシステムとするためにとても気をつけてきました。今では
本当に数千のプラグインが動くので、スケーラビリティも到達したと言えるでしょう。
それは私達のプラグインモデルが、遅延ロードや、宣言的な拡張ポイントを使っているので、本当に必要なときにコードが使われるためなのです。私はこれはコンポーネントモデルにとって重要なステップだと考えています。
他に必要なことはあなたにも簡単にコンポーネントを開発できることでしょう。だから私達はプラグインの拡張ポイント以外の方法も取れるコンポーネントモデルにしました。そして私達は開発のための強力なツールも提供してきました。その一部分は、もちろん、Java開発ツール(Java Development Tools)です。Java開発ツールに加え、Eclipseを拡張するのに適したPlugin開発ツール(PluginDevelopment Tools)もあります。
これはすべてのプラグイン間の依存という関連性のメンテナンスと定義を簡単にすることができました。
これは二つ目の理由だと思います。3つ目は、別々にコミュニティとして成長していくと…、これはAPIにとってポイントになります。
私達は安定したAPIにしていくことに注力しました。だから私達はAPIの整備については前もって合意がいることを理解していました。私達はコミュニティが壊れていくのを避けたかったのです。
これが3つ目の理由です。
あ、もう一つ思いついきました!
4つ目の理由は、私達はこのインタビューのように開かれたチャンネルを設立しています。私達は活発なニュースグループを持っていますし、そこでは活発な開発者たちが参加しています。もし質問に対して違った答えを受けたとしても、違う開発
者から正しい答えを受け取ることができるでしょう。これはコミュニティを面白くしてます。
6番目の理由は前進し続けていることだと思います。コミュニティが前進し続けている事を見せることで成長し続けています。みんなそれを望んでいます。彼らもフィードバックを得ることを望んでいますし、そうすることでみなとともに成長するきっかけを得ることができます。だからコミュニティが継続して前進しつづけることは私達のマイルストンの進行上に欠かせません。
チャンネルやフィードバックを得ること、コミュニティが継続して前進し続けること、全てがコミュニティにとって欠かせない要素なのです。わかりますか？そしてもちろん彼ら自身も各々の興味を伝え合っています。
ある人々はプラグインに対して貢献を始めてみたり、他の人はプラグインにどういった機能を追加していくのかを話し合ったりしています。そう、そしてそれはとっても楽しいのです!
年に一度EclipseConというカンファレンスを行っていますが、いつも新しいものを見つけることができます。今では私も追いかけられないくらいたくさん新しいものが。
そうこれが、Eclipseという組織の6番目の理由です。
Eclipseは一つの企業によって管理されているわけではありません。Eclipse Foundationという独立した企業であり、そこには新しいプロジェクトをどのように作り、運営していくかなど、とても厳格に規定された政治的な構造があります。
この独立した組織は他にも説明していない重要な要因があります。
IBMはEclipseプロジェクトを開始しましたが、幾つかの点で決めていたことがあります。本当に開かれた環境で、誰でも参加できて、そして独立したものにしたいと。私はIBMの戦略的な決定で、とてもいい動きだったと思います。なぜなら開かれたドアは競合企業に対して、Eclipseの上に乗っかったらいいじゃない?と言えましたからね。知っていると思いますが、BEAの製品もEclipseの上で動いています。そしてこれは独立した組織であったから成し得たことではないでしょうか。
そうでしょう?
これは決して一つのことじゃありません。技術やコミュニティ、主体性。それらが全て私達の推進力の源になっています。
5. 私の記憶が確かならば、あなたはKent BeckとJUnitを作りましたよね。
面白いことを聞いてくれますね。Eclipseからの一歩と考えると、JUnitに対しては強力なアーキテクチャ的な拡張ともいえます。本当に小さなことなのですが。
別の領域から見てみると、うぬぼれた目で影響について言いますが、本当に興味深いです。Kentは本当のところ、ユニットテストフレームワークを持っていただけなのです。SUnitって言う、Smalltalk用のユニットテストフレームワークをです。
彼は2年間チューリッヒでコンサルティングをしていたことがあって、私達はいつもプログラミングを一緒に楽しんでいました。そしてそのときから彼は、より私を便利にするためのものを見せはじめました...
「見て。System.out.println()をテストのためにコードに入れたんだけど、目で見ることなく確認することができたらイケてると思わない?」
もちろんこれでもいいかもしれないけど、System.out.println()をコードの中に入れるくらい複雑じゃなくて、簡単に確認できるならいいよね。
そして彼はSUnitを見せてくれました。これは文字で結果を知らせてくれて、とてもシンプルでした。そしてテスティングフレームワークにありがちな複雑な代物じゃない、とてもとてもシンプルなものでした。
OOPSLAに一緒に行く飛行機の中で、それは起こったんです。よくは覚えていませんが...
なんと、
10年前、何が起こったのでしょう。
私達はこう決めました。「一緒にプログラミングしようか?」
彼はSUnitの精神をいだいていましたし、どうしたいかわかっていました。Kentはそのとき、Javaプログラマの経験はありませんでしたけれど、私は既にJavaプログラミングに習熟していました。
だから私達はペアプログラミングをし、JUnitを育てていきました。それはとても楽しかったです。私達はいつも言っていたのです。System.out.println()を書くようにシンプルで、でも全自動にしたいですね、と。
私は30分後には私達のフレームワークのためのテストを書いていたと思います。そしてそれが私達を軌道に載せました。
私達は機会があるたびにJUnitのペアプログラミングをしました。これを私達は「レクリエーション・プログラミング」と呼んでいました。そしてコードが成長するにつれ、リリース1、リリース2となり、いろんな人に発見され面白がられました。そして統合していくにつれ、本当に面白かったです。
鍵となったのはデバッグ文を書くくらいテストを書くのが簡単だというアイディアだったと思います。そのアイディアこそがポイントでした。とてもシンプルなので書くコストはかからないし、学習コストもかかりません。だから普通に使ってもらえるようにできたと思います。そうですよね？
だから私達は顔をあわせる時間が無くても、リモートでスクリーン共有することでペアプログラミングしてきました。いつだったか、これもポイントだと思いますが、Kentはいつもスクリーンを共有していましたが、彼はリポジトリの中にある全てのコミットを見せてくれました。
そのとき私達はJUnit4の開発を始めました。Javaの新しい環境を使ってよりシンプルにするため、より少ない依存にするためにです。時を同じくして、.Netで動くJUnit、NUnitができたり、TestNGの開発が終わったようにみえました。どれもかっこいい代物です。でも私達はいつももっとシンプルに保てるように開発を始めていました。
私はJUnit 4よりも後はちょっとさぼっていますけれど、今もKentとDavid Saffが全ての事を進めています。
6. 他にも、あなたは様々なデザインパターンを識別したデザインパターンの本について関わっていましたよね。デザインパターンをどのように見つけるのか、そしてアンチパターンからいえることについて教えてください。
あぁ、あなたの質問は本当に昔までさかのぼりますね。そんなにも昔の事に関する質問だと答えるのも厄介になってきますね。
デザインパターンは、
そう。
私は今も好きですし、今も見つけることが好きです。そしてパターンについて話すことも好きです。どうやってデザインパターンを見つけるか・・・。それは本当にコードを読むことと、どう働いているかを探すことに尽きます。もし設計のなかから「これはもう少しすっきりできそうだ」ともやもやしたものを感じたら、それは自明なものではありません。
リンクド・リストはデザインパターンではありませんよ?
はっきりとしていないようにすべきだし、一度識別することができたらあなたはとてもいい気分になれますよ。
「わ、なんてすっきりしたんだ。」って。そう。私は最初にパターンを見つけた瞬間にあなたはそう感じると思います。
でもちょっと待ってください…私たちが出版した本も1つのインスタンスに過ぎなくて、本物のパターンとは言えないと思います。ルールと呼ぶには3回は出くわすものだからです。
一回目は出会いで、二回目は何を知らないのか気づくためのもの、三回目でやっとパターンと呼べるものになります。
だからあなたはパターンを見つけたいのであれば、他のところでも同じ構造を見つけてみてください。見つかれば、その効果についてより信頼を与えてくれます。それはパターンの潜在的な力を見つけることですしね。
でも、ふりかえってみると、私は本の中で紹介した私達が見つけたパターンは、全て同じレベル品質ではありません。だからもし私がリストを見返してみたら、全てのものがパターンとしないかもしれません。
そこで孤島から島民を投票で追い出すように、パターンも投票によって省きたいのです。私は何年か後のOOPSLAでは彼らが幾つかのパターンを投票によって省きたいと思っています。
それは初期化のようでもあるし、私はより賛成したいのです。幾つかのパターンは私達をこう思わせます。「これはすっきりしていますね。」と。そして私達はその気分が好きなのです。でも十分ではないものもまだあります。
なぜならあなたはVisitorのようなパターンをかっこいいと思ったでしょう？「わー、なんてかっこいいんだ。これによって直行する振る舞いをもたせることが出来る!」と。でもこれは限定的な使い方しか出来ません。ASTs(Abstract Syntax trees:抽象的な構文ツリー)と一緒に使うととてもよいですが、階層が固まっている必要があり、そして拡張できる種類のものではありません。
だから私は複数の使い方ができるより便利なパターンをパターンと呼びたいのです。それ以外には何もありません。あなたにも定義すべきですし、そこから次のパターンが生まれるでしょう。
簡単なことですよ。こういったパターンを識別することは簡単なのです。パターンを定義してみて、他の誰かに理解され、再生産されるのは楽しい事です。そしてそれは独りで行うのは大変なことです。なぜならパターンを定義するためには繰り返し考える必要がありますからね。
もし他の人からのレビューされるプロセスがあるならとても助けになります。パターンのコミュニティーにはそういった、どうやってパターンを見つけるか、教育してくれる場があります。そこではとてもよい彼らなりの儀式、パターンの記述者のワークショップや、レビューのサイクルなどを持っています。
だから私はパターンを書く場合は少なくとも1回繰り返してください。そして私達の本を読み直してみてください。私は全ての記述されているパターンについて少なくとも3回、書いてみて、書き直し、それから4人の著者すべてがレビューした結果をとりこんで、最終的にあなたは幸せな気持ちを得られるまで繰りかえしました。
そして私は今でもパターンが好きなのです。
だから私はEclipseを発展させている間、実際にEclipseのアーキテクチャーをパターンを使って説明したのは本当に楽しかったです。
私が説明した、「Contributing to Eclipse:(和名:Eclipseプラグイン開発 デザインパターン×テスト駆動開発)」では、あるチャプターで…、あ、その本の共著もKent Beckでしたね。私はEclipseのアーキテクチャについて、パターンを使って説明することに挑戦しました。
それは私にとってとても良いテストとなりました。なぜならEclipseはまだ全然、ある種の「私達はパターンを使っている」と言ってきたわけではありませんからね。それは開発者たちの経験からできたものなのです。
彼らはオブジェクトの設計技術についてとても理解していて、だから私は最後のほうは、もし、あなたがEclipseの中にあるアーキテクチャや設計について探してみると、どれだけパターンによって、キーとなる部分を説明できると思いますか?それは私にとってちょっとした喜びでしたし、幾つかのよい感じの対象を見つけることができました。そして幾つかのポイントはパターンで補うことができました。
しかし、キーポイントとなった宣言的な拡張部分の、XMLによる宣言について私達はパターンで補足することが出来ませんでした。私はみんなにデザインパターンはインターネットが、Javaが、XMLが、様々なものが出来る前に出てきたものだということを忘れるなといいたいのです。そこには驚くべきけん引力が存在しますし、未だに人々に読まれています。
この種の興味はオブジェクト設計についての生き残った全ての技術の基礎になっています。でも私は新しい技術についても、今ではテコになっている多くのパターンがまたあることを示したいのです。
パターンにおける現実的な強みは、パターンを適用しているときはとても柔軟な設計になるところにあると思います。パターンの定義にはどのように定義すべきか幾つかの点で熟考する必要があります。
でもそれは大いに変化できるところなのです。
私がパターンを適用するときでさえ、パターンを変化して適用するときもあれば、違ったように使うこともあります。もし私が全く同じように使っていたならば、私は、なぜそれをパターンとして適用しないか、もし3回も4回も適用できたんだったら、それをより汎用的に展開できないか、考えます。
でも典型的な例でも、私がパターンについて好きな部分は柔軟的なところで、それはあなたも変えられる部分です。あなたがぶつかっている問題に対し、パターンを適用するときは変化させられるのです。私達はパターンを説明するのにクラス名を使いませんでした。でもそれは間違いでした。
あなたが使うドメインにとても特化した名前でよかったのです。そしてライブラリの中にただ存在しているものを全てのぞくのです。そのバリエーションは私は必要なことだと思います。
8. あなたは昔のほどパターンに積極的に関わっていません。あなたから見て、みんながパターンをうまく扱えていない事や、POSA本が出てきたり、他のパターン本がGoFを乗ってしまうことなどは心配ないですか?
一言で言うと心配していません。IP(Intelectual Property: 知的財産権)-私はきょうびすべてのソフトウェア開発者がIPについて検証しないといけないと思っています。それはもしあなたが言うとおり、ソフトウェア開発者が基本的なIP教育を受けていないとするならそれは不健全です。
他の人々がパターンを乗っとること？まったく心配していません。
パターンはコミュニティのアイディアです。本当に大切なのはコミュニティなんです。それはかっこいい考え方かもしれませんが...繰り返しますが、Eclipseとパターンの間の共通点は、私にとっての共通点はコミュニティです。
Eclipseのためのコミュニティもあります。パターンのためのコミュニティもあります。あなたはコミュニティの周りでコミュニティの成長を阻害してはいけません。だからコミュニティへの対応は完璧にしてきました。彼らは何ができますか。Gang of Fourのパターンも本当によく批評されてきました。
でも私は全てに納得できているわけではありません。もちろん良い出来事もコミュニティの中でおきました。
そしてコミュニティが今まさに彼ら自身の手で再発展していくことに興味があります。今まさに新しい世代の人々が引っ張っています。
9. Gang of Fourの本の続編など、デザインパターンの本の執筆予定はありますか?
私達はデザインパターンを見つけることを愛していますから。
私達は実際続編のアウトラインを持っています。それで十分ですって?
でも興味深いことに私達はそれを書きたいのです。さっき言ったとおり、私はパターンを記述することを愛しています。それだけがGoFのメンバーの私達の責任なのです。
残念なことにJohn Vlissidesは昨年亡くなってしまいました。だから次の本は全く同じ感じには出来ません。3人だけになってしまいましたからね。でも私はパターンを書くことを愛していますから。
私はアウトライン以上のものをすぐに出すことを約束することはできません。アウトラインから本にするのには、みんなも知っての通り、80%から100%にできるまでの間、とても泥臭くて大変な作業が待っています。
アウトラインでは私達が知っていることのうち、10%しかあなたに伝えられませんからね。
10. DI(依存性の注入)はパターンですか?そうではないですか?
私はパターンとして捉えることが出来ると思います。
そこにはたくさんのトレードオフがあるでしょう。例えば作成領域に適合させないといけません。
私達のアウトラインの中では、それは一つの点ですけど、どうやってみんながパターンとして見出せるか、研究しているところなのです。そこにはあなたが識別できるたくさんのバリエーションがあるでしょう。コンストラクタベースや、パラメーターベースなど、トレードオフがあります。
私はパターンを書くのは楽しいですが、トレードオフを必要とするものを解決方法として記述できません。そして厳密に適用できるものにしたいのです。
今はもやもやしたものです。
私はパターンとして捉えられるようにし始めたところですし、パターンとして書いたこともあります。それははっきりしていないですけどね。でもそれは新しい技術の例としても説明できるでしょう?
たくさんの宣言的な依存は私は私達のデザインパターンの中でも見てきたと思います。
デザインパターンの中で私達はたくさんの抽象的な組み合わせについて話しましたが、抽象的なクラスを組み合わせることもできますが、その参照は抽象クラスのインターフェースしかなかったと思います。だから私は次のレベルにしたいのです。
あなたは実際はクラスを組み合わせたいわけではないですよね。それはただ外部にだせると思うのです。そして興味深い次のステップは私達が本の中でカバーできなかった部分だと思います。でも幾つかは本の中で見つけることが出来るでしょう。