IPA未踏ソフトウェア千葉滋PM案件最終成果報告会

IPA未踏ソフトウェア創造事業の平成17年度上期千葉滋PM案件最終成果報告会に行ってきた。裏のテーマはRuby vs Javaということで、コアなRubyistと先端を行くJava使いが集まった。

千葉先生のところの報告会というだけでも十分に話題性があるところ、採択案件の中にはYARVは入っているしMayaaは入っている。これを逃す手は無いと思って即座に申し込んだのだった。更に、あとからまつもとさんやひがさんまでやってくることになって、参加希望者が殺到、定員200人に対してキャンセル待ち50人となったらしい。

Ruby界隈、Seasar界隈の人達でいっぱい。まだそれほど顔が広くない私は、Rails勉強会でお会いした日経ソフトウェアの方にだけ御挨拶してきた。

未踏ソフトウェア創造事業とは

最初に未踏ソフトウェア創造事業自体について簡単な紹介があった。採択案件の名前は良く聞くけれど、どういう仕組みになっているのかよく知らなかったので、「へー」と。

ひがさん曰く、「仕事でオープンソース・ソフトを開発したければ有名人になれ」とのこと（Developers Summit 2006)。でも、無名でも能力のある人はいる筈で、そういう人を発掘するために仕事でオープンソースを開発してもらう事業が未踏ソフトウェアであるそうな。「あなたの作りたいものを発注します」というのを公募していると考えればよいらしい。

従って、発注経緯こそ通常とは異なるけれど、基本的な契約形態としては通常の受託開発契約と同じらしい。納期もあって、進捗報告があって、それをPMが管理するのだな。

そして、最終成果報告会では「納税者への説明責任を果たしてほしい」とのこと。

ひがさんの講演

まずは、ひがやすおさんの特別講演「Configuration Files must Die!!!」。「Rubyお誕生日おめでとう」との言葉の後、Seasar2の背景と哲学についての一般向けの説明といった感じ。

ひがさん、声が若い。それに、写真で見るよりもずいぶんと雰囲気が柔らかい。

Less Configration

DIをはじめ、Javaな方面の問題としてXML HELLがある。設定を利用場面から分離するのはいいのだけれど、分離した設定を外部設定ファイルに書くのは大変である。小さな実験的開発のうちは目立たなくても、現実的なプロジェクトではDI対象となるオブジェクトの数が1000を超えるようなこともあるわけで、そうなると設定の肥大は深刻な問題となってくる。

クラスに対応する設定がどこに書いてあるのか探すのが大変
設定エラーが起きたときに該当箇所を探すのが大変

そこで、考えられたのがソース自体からは分離して、ただしソースの近くに設定を記述する方法であった。すなわち、XDocletであり、Annotationである。これによってソースの1ヶ所を見るだけ関係する設定が全て分かるようにはなった。しかし、代償として設定変更のときに一々recompileする必要が発生してしまった。

どこで設定するのかを悩むのは設定するからである。設定しなければよいということで、Less Configurationである。Zero configurationとは言わないけれどもそれに近く。Convention over Configuration, Configuration by Exceptionの両原則によってこれを実現する。

Convention over Configuration(CoC)原則

Railsで言われているあれ。フレームワークの定める規約にしたがっている限り、設定しなくてよいということ。規約といっても、もともと「そうするのが望ましい」「そうしておいたほうが開発者が楽」なものであるから窮屈なものでは無い。私の言葉で言えば「どうせそうするんだから書かなくていいでしょ」。フレームワークとユーザーコードの間に暗黙の文化的文脈を導入するって解釈してもいいかもしれない。

Seasar2の定める規約としては

プロパティの型がinterfaceなら、それを実装するクラスを勝手に探してきてinjectする
プロパティの名前にマッチするオブジェクトがDI containerに登録されていたら、それをinjectする。
InterfaceNameがinterfaceの名前であるとき、InterfaceNameImplというような名前のクラスを勝手にDI containerに登録する。

単純な規約ではあるけれど、これだけで設定量はぐっと減ることだろう。勝手に登録されるクラスは、パッケージを指定できたり、名称を正規表現で設定できたりするので十分に柔軟かつ、変なinjectionが起きて混乱することもない。

そして、この規約に基づく自動設定ができなかった場合には、

例外を投げる
warningを出す
何もしない

のいずれかを選択できて、デフォルトではwarningとなっている。

Configuration by Exception

そして、規約から外れる例外的な部分だけ設定を書く。Seasar2は、Javaの5.0環境では勿論Annotationを活用する。それだけでなく、Backport175を採用して1.3, 1.4環境でもAnnotation記法を実現する。backport175のXDocletに対するアドバンテージとして、

eclipseのプラグインがコンパイルエラー（Annotationに対応するインターフェースが存在しないなど）までチェックしてくれる
compileするだけでクラスファイルに情報が埋め込まれる。わざわざ設定ファイルを生成したりする必要はない。

例外的部分については設定する仕組みを提供して、規約が足かせにならないで済むことを保証する。CoCが効いているのでクラスが増えても設定する内容はそれほど増えないで済むとのこと。

私の直感では、一般的にはシステム規模に対して対数オーダーか最悪でも線形の「例外的設定」で済むのではなかろうか。Less Configuraion以前のDIでは最良で線形、最悪ではn^2オーダーかそれ以上であったから、クラス数1000の世界ではこれは大きな改善であろう。

将来的には、自動設定の結果を設定ファイルの形式で書き出す機能もサポートするらしい。

再び、どこに設定するか

Less Configurationな世界では、何をどこに設定するべきであろうか。もはや、考えるべきは例外的なわずかな設定だけに絞られたので考えるのがかなり楽になっている。ひがさんは次のような判断を提案している。

環境に依存するもの => 変わりうる => 外部の設定ファイルに
それ以外 => 変わるかどうかよく分からない => たぶん変わらないだろう => Annotationに

AOPについて

正規表現でアスペクトの作用する対象を設定することにすると、メソッドの名称を制約しがちである。けれども、メソッド名はその機能に応じて柔軟に付けられることが望ましい。そこで、ビジネスインターフェースでメソッドを定義し、これによってAOPの作用対象を定める。らしい。あとで書く。

標準準拠の心

標準があるならそれに準拠してユーザー資産の有効活用を図ろう、ということで、Seasar2はEJB3をサポートする。売りはアプリケーションサーバーから独立したEJB3実装であるということで、これによって

TomcatのようなEJB3を実装しないサーバーでもEJB3が使える
デプロイすることなく、Mockではない本物のEJB3オブジェクトを使ったテストを実施可能
- packagingもしなくていい。ただコンパイルしてclassファイルを作るだけでEJB3オブジェクトをテスト可能

Ruby言語による生物化学情報基盤ライブラリの開発

BioRubyとChemRubyの開発。

2000年にヒトゲノム計画も完了し、時代はポストゲノムだそうな。ヒトを含めた300種以上の生物のゲノムは解析終了し、現在2000種以上が解析進行中。

バイオインフマティクスの領域ではゲノム、化学物質等々のデータを活用して研究を進めていくのであるけれども、ゲノムはテラバイト単位のデータで、その他、世界中に数千ある化学物質データベースを利用することになる。しかも、ソフトウェア別に様々なフォーマットが使われている。ここで、グルー言語としてのRubyを活かしていこうというのが趣旨だそうな。

バイオインフォマティクスの研究者が日々の研究で使えるようにするのが目的で、未踏事業の中では

文書の充実
1000以上のユニットテストを追加
irbを拡張した対話的シェルを提供

これによって、先行するBioPerlよりもプログラミングしやすいシステムを実現したとのこと。

更に、生物分野ではBioPerl, BioPython, BioJavaなどがある中、化学分野・ケムインフォマティクスでは初のものとしてChemRubyも実装したという。ChemRubyもまた、数多くのフォーマットへ対応し、数多くの計算化学ソフトウェアへのインターフェースを提供した。中でもChemRubyの類似構造の物質を高速に検索する機能は画期的らしい。従来の商用ソフトウェアではプログラミングインターフェースが十分に提供されなかったので一々画面上でクリックして処理しなくてはならなかったところを、バッチ処理によって類似の物質を次々に検索できるようになったという。

発表では、デモンストレーションとして対話的シェルを通じてクマムシのゲノムをロードし、アミノ酸配列に翻訳、更にWebインターフェースである"BioRuby on Rails"で閲覧して見せた。

処理結果のオブジェクトは各種画像ファイル、PDF、ついでにMIDIファイルへの変換も可能という。会場ではクマムシゲノムを変換したMIDIを演奏してくれた。

Tuigwaa - ユーザー手動型ウェブアプリケーション作成ツールの開発

あーうー。Tuigwaa、完成度が素晴らしいよ。もっとちゃんとチェックしておけば良かった。今回の報告会の申し込みサイトもTuigwaaで作られているという。

前に調査したときに調査範囲には入っていた筈だけれど、その時ドキュメントから読み取った以上に使えるプロダクトだ。というか、実は私ゃRailsベースでTuigwaaの劣化コピーみたいなものを開発してしまったのだ。Tuigwaaの方が適用範囲も広く、遥かにUIのセンスがよい優れものだけれどね。Tuigwaaがここまで素晴らしいと知っていたら私のつまらないコピーなんか開発しなかったのに。悲しいから、あとでこっちの成果物をRailsからTuigwaaにportして公開できるかどうか調整してみよう。

Seasarの方面はちゃんとアンテナ張ってるつもりなんだけどなー。

背景

既に基幹業務、定型業務についてはシステム化が進んでいる世の中であるけれども、その他の雑多な業務はシステム化されずに代替手段が利用されている。例えば、メールにスプレッドシートを添付したり、メールで定型フォーマットのテキストをやりとりしたり。

しかし、添付方式だと版管理に問題を生じて手戻りを発生させてしまったりするし、テキストのやりとりでは集計に手間が掛かったりする。本当は、こういうものこそweb化すれば業務の効率を上げることができるのであるけれども、でもシステム化は行われない。

なぜシステム化されないか。得られる業務の改善に対してシステム開発のコストが高かったり、システム化に掛かる時間に比して業務の変化が速かったり、そういう事情である。

ところで、こういうシステム化の経済的/時間的コストはユーザーと開発者の隔たりが生んでいるものである。であるから、スプレッドシート一枚で済むような簡単なアプリケーションについては、ユーザー自身が簡単にシステムを作れる仕組みがあれば、日々の中でボトムアップに作成し、業務を改善していけるのではないだろうか。

これがTuigwaaの開発背景ということだ。「HTMLを知らない人が自らDBと連動するウェブアプリケーションを作って、ボトムアップに業務を改善」

Tuigwaaの機能

Tuigwaaはデータベース, ディレクトリサービス、J2EEコンテナに依存する。このうち、データベースとディレクトリサービスは既存のものがなければTuigwaaにバンドルされたHSQLDB, ApacheDSを利用することもできる。

Tuigwaaでは個々の「参加申し込み機能」や「飲み会出欠管理機能」といったものを「サイト」という単位で管理する。

次のような機能をwebベースで利用できる

ページの管理
- ページの作成、修正、削除
- WikiフォーマットまたはWYSIWYGエディタを使用
データベースの管理
- 表の作成、修正、削除
ロジックの管理
- 特定操作をトリガーとしたロジックの実行を設定
- メール送信など
..
出力
- Web
- PDF
「サイト」のimport, export

実績と今後

現在は、主なユーザーはほとんど開発者のみである模様。しかし、その中でも次のようなシステムがTuigwaaで作成された

最終報告会参加申し込み
Tuigwaaのバグトラッキングシステム
Tuigwaaの、千葉PMへの報告書

本日ver. 0.8がリリースされ、今後seasarからリリースされる予定であるという。

拡張性など

ロジックの追加: プラグイン形式でロジックを追加でき、実際カウンターはプラグインとして実装されている。ただし、今後APIは変わるかもしれない
デザイン: 現在はいくつかのオプションを選択できる程度である。スキンのような機能を追加するかどうかは未確定
国際化: 未対応
スケーラビリティ: 同時に20users程度であれば3秒以内にレスポンスが得られた

実演

AJAXを利用した柔らかくユーザーに優しいUIが印象に残る。プルダウンメニューからデータ型を選択して、一般的な統合オフィスソフトの利用者であればそれほど悩むことなくテーブルを作成できるだろう。

そして、そのテーブルに基づいて数クリックで簡単に入力フォームを作成でき、カラムに対する書込み権を設定できた。実演では主にWikiスタイルを利用したがWYSIWYGスタイルの機能も充実しているように見える。編集領域上部のツールバー部分に必要十分なコマンドが並んでいる。

反響

実演では、その機能の完成度の高さに会場はどよめいた。アプリケーションサーバーさえ走っていれば通常のwarとしてデプロイできる手軽さもあって、開発者自身の身近なところには急速に浸透していくだろう。その後については、千葉先生の講演に書く。

まつもとさん講演

我らがまつもとゆきひろさんの講演「2010年のRuby 当たるも八卦当たらぬも八卦」。

まずは、Rubyのお誕生日について。1993年2月24日、Rubyと命名された。プログラミング言語は形が無いもの故、名前が重要。というわけで、命名日をもって誕生日としたらしい。

まずは現在の業界動向の分析。これはオブジェクト倶楽部クリスマスイベントでのセッションに近い。

Webの台頭（web 2.0)
動的言語の台頭
開発期間の短縮傾向
ビジネスの急速な変化にあわせた仕様変更の必要性増大

これにより、「アジャイル重要」

そして、Ruby界隈で今なにが起きているかというと、

Railsの普及
- 2004年に開発が始まったRailsは2005年を通じて爆発的に広まり、今やRuby自体を牽引している。
YARV - これはあとのYARVの報告で詳述
開発ブランチにおけるいくつかの変更。下位互換性のない変更も一部行われる

そして、Ruby 2.0へ動こうとしている。そういう流れから、まつもとさんはRubyは2010年には次のようになるであろうと予測する。

Ruby 2.0が完成しており、普及する
携帯電話からスーパーコンピュータまででRubyが動く（既にPythonは携帯で動いているらしい）
文法が整理され、より問題が起きにくくなる。

ビジネス面では次のようになるだろう

Web開発言語として一般に認知される。現在のPHP程度の認知を得る
Rails周辺が充実する
Rubyを中核としたビジネスも軌道に乗り始める

この他、文法整理として考えられている内容について説明があったが、Ruby 1.9やMatz日記を追っている人には周知であろうし、それ以外には冗長と思われるので「あとで書く」。

会場からの質問

ビジネスへの適用で問題となるのは遅いこと、商業サポートが無いことである。パフォーマンスはYARVで解決されると見込まれるが、商業サポートはどうか。

詳細を公開できる段階ではないが、複数の企業でRubyの商業サポートを提供する話がある。2010年というほどではない、もっと近い将来、プレスリリースがあるだろう。

他の言語に対するアドバンテージは

文法の柔軟性。Railsに触発されてPerl, Pyhon, PHP, Java, C#でも同様の動きがある。Railsの特徴として次のものがある。

Agile開発をサポートする機能
動的型を活かした柔軟性と開発の容易さ
DRY(Don't Repeat Yourself)原則に基づく設計
CoC(Convention over Configuration)原則に基づく設定
言語内DSLによるわかりやすく強力な記述

他はともかく、Railsの強力さを生み出す言語内DSLを構成する記述力に関してはRubyは他の追随を許さない。さすがにRubyもLispには劣るので、Lisp on Rails(yugui註: Lambda on Railsとしても知られる）が出てくると負けるかもしれないが、まつもととしてはLispは好きなので別にそれでもいい、とのこと。でも、一般の人は何か括弧にトラウマでもあるらしいのでLispは流行らないだろう、とも。

Rubyの言語内DSLを構成する力とは

かなりの局面で括弧が不要な文法
シンボルの存在 => 名前を扱うのに便利
ブロックの存在 => ローカルなコンテキストを生成する記述

YARV

YARVの発表「オブジェクト指向スクリプト言語Rubyの処理系の刷新」。

YARV(Yet Another Ruby VM)は昨年度未踏ユースに採択されたプロジェクトで、Ruby処理系をstack machineとして実装しなおすものである。次世代Ruby(Rite)のコアとして採用が内定している。

まつもとさんが偉くなってしまってなかなか暇が無いのでRuby処理系の刷新計画(Rite)が進展せず、ならば代わりにやってみようということで始まったらしい。

現在のRubyは再帰によってノードツリーを辿る形式であり、そこかしこでsetjmp(3), longjmp(3)するために速度が遅い。スクリプト言語では速度は不要という見方もあるが、Rubyの用途が多様化したことで性能が重要な局面も見えてきた。実は、文字列処理はPerlと比較してもそう遅くないのだが、数値処理、記号処理がどうにも遅い。そこで、Rubyをバイとコードにコンパイルしてstack machine形式のVM上で実行し、高速化を図るのがYARVである。

本年度の目標と結果

Ruby本体とのマージ: マージ完了した。
native threadのサポート: Giant lockを使用する形で実現した。
multi VM: 動いた。まだ改良の余地あり。

プロセス内に複数のVMを起動できるようにする

Ruby本体のマージ

昨年度はRubyの拡張ライブラリとしてRubyコアと協調して動作していたが、これを完全にRubyに埋め込んでしまう。これにより、Rubyコアを積極的に触って改善していくことが可能になる

native threadのサポート

従来のRubyのスレッドはUser Level Threadであった。そのため、

Multi core, Multi Processor環境であってもCPUを1つしか活用できなかった
C言語関数内ではスレッド切替えが発生せず、パフォーマンス低下につながった
tkのようなnative threadを使用するライブラリと相性が悪かった。

そこでPOSIX thread, Win32 threadを利用してMulti Processor環境ではCPUを有効に活用できるようにした。

ただし、現時点では同時に実行されるRubyのスレッドは1つである。CPU1,2があるとき、CPU1上のスレッドを止めてからCPU2のスレッドを起動する。それでも、スレッド切替えに伴うコストの軽減にはつながるだろう。

また、CPU2にスレッド実行が移りCPU1でのRuby本体の処理が止まっている間、CPU1を用いてRuby拡張ライブラリの処理を行う。そのためのAPIも用意された。NArrayライブラリに適用したところ1.5倍の性能向上が得られた。

今後はスレッド間の排他ロックの粒度を細かくして性能の向上を図る。

なお、native threadはやはり生成コストが高く、スレッドを大量に生成/破棄するような使いかたでは従来のuser levelのものに比べてパフォーマンスの低下がみられた。native threadのサポートに伴いRubyプログラムでもthread poolingを利用していくべきかもしれない。また、user level threadとnative threadをコンパイル時に選択できるような仕組みも考慮の余地がある。

multi VMのサポート

Rubyをアプリケーションに埋め込む場合、mod_rubyなどでは1つのプロセス内で複数のRuby VMを使用できることが望ましいが、従来のRubyは処理系にグローバル変数が多く含まれていて実現できなかった。

また、同一VM上のスレッド同士は違いに依存関係を持つので、真の並行動作は難しく、現段階では上記のように、Multi Processorであっても同時に複数のスレッドが動くことはない。しかし、異なるVMは違いに独立に動作できるので真の並行動作が可能である。複数VMを立ち上げて並行動作させればCPU資源を更に有効に活用できる。

動作確認

OptionParser, mkmf他のビルド系ライブラリが動作した。これによりminirubyが構築できるようになった。つまり、他のライブラリを含むruby全体をYARVベースで構築できるようになった。

その他、Railsなど多数のライブラリ, アプリケーションがYARV上で動作した。

JavaServer Templates 「Maya」の開発と世界発信

採択時はMayaであったが今はMayaaと改称。大規模開発を主眼においたJ2EEのView技術。

B2C開発向け
非常なHigh Availability。大規模開発にスケールする
- 1,800万view/monthの案件実績あり
デザインとしてのHTMLと、そこに適用するViewロジックを別ファイルに持つ。
- id属性やXPathで作用対象の要素を指定してweaveする。
- 原則としてオブジェクトがstatelessで動作するので、High Availabilityにつながる
- JSPと異なり実行しなくても確認できるので、デザイナとの分業が容易
既存資産の有効活用
- JSPを前提とするフレームワークの中でJSPの代りに使える
- JSPのカスタムタグを流用可能
  - ただし、流用した場合は処理がstatefulになってしまう
サイトに技術書一冊分相当のドキュメントあり

JSF対応としてMayaFacesなどもある。seasarにてリリースされていく予定。

感想

いいものだと思うけれど、発表がうまくない気がした。ターゲットが不明確。技術者対象としては営業トークが多くて、技術的な具体的なところに宿る魅力が伝わってこない。J2EE開発を知っている技術者や、あるいは非技術者を対象とするには既存のJ2EE技術についての説明が冗長。J2EEに詳しくない技術者にとっては説明不足。営業としても、それならもう少し実績についての詳細がほしかった（どうやら、まだ公開できないらしいからこれはしかたがないけれど）。

千葉滋PM特別講演

千葉先生の特別講演、「ソフトウェアを使ってもらうには --- Javassist の場合」。キャズム理論をJavassistの例で説明し、後にこれに沿って各案件についての講評を行った。

Innovators: 開拓者。業界用語では人柱, geek。良いものを見つけ出してきて評価する目利き
Early Adopters: 先駆者。最初の実ユーザー。Innovatorが発掘してきた新しいものをどのようにビジネスにつなげられるかを評価し、リスクを取って競争相手に差を付けようとする。
Early Majority: 現実派。同業者、仲間の評価に基づいて利用する。「定番」のものを採用する。最初のユーザーにはならない
Late Majority: 世の中に普及した後に利用する
Laggards: 他に選択肢が無くなるまで新しいものに移行しない。新しい技術に対する優れた批評家になることもある。

Early Majorityとは「みんなが使っているものを使う」人達であるが、「みんな」とはEarly Majorityのことである。そのため、一般には彼らに新しい製品を受け入れてもらうのは容易でなく、Early AdopterからEarly Majorityの間には裂け目（chasm）がある。このchasmを越えるのが、市場において成功するかどうかの大きなポイントである。

「定番」にならなくては普及しないが、普及しなくては定番にならないのが問題である。そこで、すき間市場を狙うことでそれらを確固撃破し、「特定の局面における定番」となる。それを足掛かりに市場全体への進出を図る。

各プロジェクトの場合

Javassistに関しては、元々がInnovators, Early Adoptersの集団である研究者世界で生まれたものであるため、Early Adoptersまでは順調に進んだ。(2002年)

その後、AOPに特化しすることでJBoss AOPに採用され(2003年)、AOPの世界における「定番」となった。そして今、SeasarプロダクトやEJB3関連で広く採用され始めている。(2006年)

そして、各案件について講評があった。

BioRuby: 未踏ソフトウェア採択時、early adotpersは確保済。今はchasmを越えつつある
Tuigwaa: 本日innovatorsを確保。これからEarly Adoptersを見付ける
YARV: 今はchasmを越えたかどうかというところ。
Mayaa: 実案件として十分なEarly Adopterを得て、Chasmを越える準備ができた。

世界線航跡蔵

2006年02月24日