最近、Coding Bubbles プロジェクトがステレスモードから出てきた。新しいIDEの相互作用モデルの概念は、ソフトウェア開発コミュニティの注目を集めた。 InfoQは、最近、引き続き、生みの親である Andrew Bragdon 氏にプロジェクトについて詳しく尋ねた。
InfoQ: たったの数日で開発者の間ですごいセンセーションになった気分はどうですか？あなたが受け取ったもっと顕著な反応は、何ですか？
アハハ、プロジェクトがオンラインで作り出した興奮のレベルを見るとちょっと驚きました。あなたもまったく想像していなかったですよね。しかし、論文を仕上げるために、１年半の間、プロジェクトで猛烈に開発した後に、この注目のレベルを見るのは、非常にうれしいです。
ええ、確かにものすごくメールを受け取りました。実際、これまですべてを読み通す機会は、なかったですね（返事を待っている人達には謝ります－いつか必ず返信します）。おそらく一番予想していなかったのは、私にメールを送ってくれた人達がいくつも仕事のオファーをしてくれたことですね。またベータに多くの人が興味を持っていて、ベータについての質問がメールでたくさん来ています。いつベータが手にはいるのかとか、早く実際に使うことができるのかとか，多くの人が聞いてきます。他の共通の質問としては、他の言語サポートを加えられのか（Python と C/C++が特に人気があるようです）と言う質問ですね。
InfoQ: サイトでバブルのメタファについて語ってますね。それはそれとして、アイデァを思いついた最初のインスピレーションは、何でしたか？
Code Bubblesプロジェクトは、元々始まったのが２００８年の１月で、机で小さなスクリーンのあるフラットコンピュータ(Tablet PC) で、ペンを使ってソースコードをアノテートしたり、ジェスチャ的な操作をするという、別なアイデァで遊んでいる時でした。私が実装した初期のアイデァのひとつが、ペンで関数を選ぶことができ、それからその関数を切り離して浮かんでいるバブル（泡）の中に飛ばすというものです。これができると、ユーザは，コードベースのいろんな所からバブルに切り離せるので、コードの全てを一度に見ることができます。一旦これを実装すると、コード片は、広い範囲わたるいくつものコーディングタスク、例えば、読んだり、編集したりすることからアノテートしたり、協同作業したり、デバッグすることまで、にとって都合がいいことが、私には非常に明白でした。その時は、非常に興奮しました。というのもその潜在的な価値がわかる一方で、使えてスケーラブルなものを作るためには、やるべき非常にたくさんの設計と実装がありましたから。
これに加えて、利用すべき、長年にわたる多くの関連した開発もありました。実際、コード片での作業という考えは、我々の発明ではない、ということをはっきり言う事は重要です。元々そのようなことは、 Smalltalk環境にあり、後に Squeak環境にもあって、関数を１つづつ、浮遊した別々の子ウィンドウに開けます。
それからは、近年のIDEは、コード片からは、離れて、もっとファイルベースの編集の方向に向いました。なぜこのようになったか確かなことを言うのは難しいですが、元々の方法には、いくつものスケーラビリティ上の問題があり、Javaには適しませんでした。Javaのコードは、長くなる傾向があるので、関数を小さなスペースに合わせるのは、難しいです。更に、子ウィンドウの問題は、どのウィンドウを前面に持ってくるかをユーザが管理する必要があり、非常にうんざりします。子ウィンドウを持つすべての凝ったUIは、気を散らすものだと見られてしまうのです。結局、ウィンドウで画面がいっぱいになると、スペースが無くなった，ということになるわけです。
そこで Code Bubblesでは、これらのスケーラビリティの問題を設計によって解決し、この初期の開発の上に作りました。長い行数の関数を扱うために、プログラマがやるやり方で、長い行をまとめるのに、リアルタイムで走る、シンタックス認識するリフローを使います。長い関数を扱うのに、垂直方向の省略機能を使って、デフォルトで大きなブロックは、畳みます。どのウィンドウを前面に出すかの管理を減らすために、バブルを、重なることはできません。その代わりに、再帰のアルゴリズムにより、自動的に、動いているバブルに重なろうとするバブルを邪魔しないようにどかします、しかも必要な移動距離が最小になるようやります。見た目に乱雑にならないように、バブルそのものへの、メッキはできるだけ除きました。最後に、バブルは、連続的にパンできる２次元の垂直な作業スペースに存在していて、画面スペースがいっぱいになったら，単にもっとスペースを作るためにパンするか、新しいタスクをするのにスペースの使われていない部分にナビすればいいのです。他にも、我々が加えたフィーチャがいくつもあります、一時的なズーム機能、軽量のグループ化、作業スペースのタスクもスケーラビリティに役立ってます
InfoQ: デモを見て私が感心したひとつは、その考えを得て、それをメソッドレベルの編集ばかりでなく、デバッグ、コードの完成、参照検索などの他の領域にもそれを適用していると言うことです。そのプロセスをもっと説明してくれませんか？
もちろんです。バブルのメタファのいいところのひとつは、コードを読んだり，編集したりだけにではなく、他にも使えることです。スクリーン上のバブルのグループをワーキングセットと呼んでいます。ワーキングセットは、当然、複数のメソッドあるいは、コード上の場所を出力するプログラミングツールにとって、大変役立ものになりえます。例えば、デバッガは、しばしば実行時のトレースに沿ってステップ動作します、そこで我々は、トレースを画面上に見せるのにバブルを使います、ユーザが様々な関数にステップインしたり、ステップアウトしたりする時に、バブルを横に並べてね。
複数のメソッドを出力するという特性を持ったたくさんの開発ツールがあります。例えば、バージョン管理と差分を考えたら、変更のあったメソッドを見せるために、バブルのグループが表示されるでしょう。またバブルは他のツールにも使えますよ、例えば、プロファイラ、自動バグ発見ツール、単体テストの結果などです。これらの場合、ユーザではなく、開発ツールが出力として、ワーキングセットを作成します。しかしその利益は、似ています：簡単に、コードベースの色々な場所にある、多くのメソッドを横にならべて見ることができ、ナビする必要がありません。
バブルは、ユーザがすでに１つあるいはもっとバブルを画面上に開いている場合には、ツールへの入力としても使えます。例えば、２つの開いているバブル間で、ユーザは線が引ける、というフィーチャがあります。その時、バックエンドで、静的なコールグラフ探索を実行していて、もしあれば２つのメソッド間の最短のコールパスを特定します。この時は、２つの間にあるバブルを開いて、このコールパスを表示します。また軽量のグループ化機能を使って、ユーザが「関連するバブル」という概念すなわち、過去に，おそらく他の開発者によってこのメッソドといっしょに集められたメソッド群をクエリできます。それで、私は、開発ツールへの入力やクエリとしてバブルを使うことも意味の有ることだ，と考えています。
Code Bubbles インターフェースの自然な側面の一つは、私が今，お話した入力と出力が連結できることです。例えば、もしユーザがある識別子 をもとに全参照検索を実行したら、その右側に結果を持ったバブルのスタックが開きます。ユーザは、このスタックの中で関連するメソッドを開けます。今度は、もう一回全参照検索を実行します、そうするとその右にまた結果を持ったバブルが開きます。この時、ユーザは、それらの関係についての完全な履歴が、一度に画面上に見ることができます。バブルを横に並べる方が、このようなクエリの枝分かれする性質にもっと簡単にもっと自然に対処できます
InfoQ: 上記の領域に概念を適用しようとする際に、失敗した方法は何でしたか？またどのような概念が簡単にはパラダイムに合わないと思いましたか？
良い質問ですね。我々は、フィーチャの最初のプロトタイプを設計／実装する時には、反復型の設計プロセスを使ってました、それからその領域のプロの開発者を連れてきて、彼らのフィードバックを得て、それを基に設計を更に改善しました。それから我々は、最後には何らかの形で使われることにはならないものも実装した、とまでは言いませんが、いくつもの設計変更を経たフィーチャがたくさんあります。
初期の最大の要望の１つが、より多くのキーボードショートカットでした。やってきた多くの開発者は、猛烈なキーボードユーザで、もっと多くのキーボードショートカットを望みました。このために、簡単に隣に新しい関数を開いたり、定義に行ったりなどができるように、当該のバブルの隣に検索ボックスを出させるショートカットのようなものを加えました。
また、最初は、バブルをナビしたり、再配置するための、一時的なズーム機能はありませんでした。やってきた多くの開発者が自分の作業スペースを再配置できるようにするズームアウト機能と、しかし意外にも、自分の同僚に「肩越しに」仕事をよく見せるためのズームイン機能の両方を要求してきました。
ユーザからの重要な要求を基に加えた別のフィーチャとして、画面をPDFにエクスポートする機能です。多くの開発者が、これがあれば、バグを文書化したり、チームの他のメンバとコード中に散在しているフィーチャについて議論するのが簡単になると言いました。
InfoQ: webサイトには、プロジェクトは、 Eclipse上に作られているとありました。 プロジェクトをEclipse foundationにオープンソースとして提供する考えはありますか（webサイトには、ライセンスについて何も見つからない）？商用製品として開発を進めることについてはどうですか？
プロジェクトのオープンソース化は、ぜひ今年やりたいと思っています。また早くプラグインのアーキテクチャを加えたいとも思っています、そうすれば，開発者が自分のニーズに、よりよく合うように環境を拡張できますからね。
現在の計画では、無料です。非営利のシステムでは、単にダウンロードして、すでにインストールした Eclipseと一緒に使えます。我々は、もちろん喜んで Eclipseチームとおそらくいっしょに働けるように、合意したいですね。
InfoQ: Eclipse foundationを前提として， Bubblesコンポーネントは、 Eclipseがサポートしている Ruby/Groovyのような他の言語とも動きますか？
もちろんです。理論的には、 Eclipseで充分サポートされている言語なら何でもサポートできます。実際は、言語を加えるには、いくらかの作業が必要ですが。長い行をまとめるのに使っているシンタクス認識するリフローは、その言語用のパースツリー（抽象シンタックスツリー）を基にしていて、言語用のカスタマイズが必要な他のいくつかの作業もあります。
これは、絶対に早くやりたい事ですが。
InfoQ: このプロジェクトで次にやりたい事は何ですか？
我々にとって次の重要なステップは、ベータをリリースして、開発者が、家や職場で使って、我々にフィードバックできるようにすることです。もしこれが成功すれば、我々は、反復開発プロセスを続けられます、しかしずっと大きな規模でできます。そうなれば、新しいフィーチャを出して、そのフィードバックをすぐに受け取れるようになります。
我々の現在の計画では、４月の中頃に限定的なリリースを行い、その後の数カ月は、徐々にベータの規模を大きくしていき、同時に、更にフィーチャを加えつつ、システムを安定化させていきます（ついでに、「厚かましい宣伝」 codebubbles.org で、ベータへのサインアップができます）。その後で、一般向けのダウンロードができるようにしたいと思っています。
