来年のRubyKaigiのオフィシャルスポンサーにマイクロソフトが登場して、Silverlight+IronRubyのテクニカルスポンサーセッションをしたりとかが見られたりするんだろうか?で、ノベルもオフィシャルスポンサーになってて、Moonlight+IronRuby(Monoの上で動けば)のテクニカルスポンサーセッションがあったり。SunがJavaApplet+JRubyのテクニカルスポンサーセッションをやってみせたり。実際にそうなった状態を想像すると、あまりおもしろくなさそうな気がするわけだが、おもしろいかどうかだけじゃなくなるのが2008年なんだろうか(とか勝手に予想してみたり)。おもしろくないとつまらないからなぁ。プログラムをおもしろくするのには、レースコンディションを導入すると良い。解決するのが効率的か、とか。見分けるのが難しいのだが、思わぬところに穴があってNullPointerExceptionしてしまったり。それぞれを代表するちからびとが入場してきて、ということは、後楽園ホールの地下を借りれば良いだろうな。マージャン卓みたいなところで、決められたお題をハック開始だ。そこに、オーガが乱入してきてコアを吐かせるとか。オーガだから、プロプラエタリは嫌いだろうしな。テクノロジーゲリラで、やりたいひとはやれば良いだけなのだが、愛は確かに重要だ。NetBeansはインストールしてあるのに、JavaでプログラミングするときにEmacsを起動して、結局APIはHTMLを眺めながらコード書いている自分がいたりするわけで、それはEmacsを愛してるからだ。ついてちょっと考えてみる。立場的に佐官ではなく尉官の下のほうという前提。取得できるから)とか野心があるとすると、内部でどうにかしなければならないわけだから、取り得る戦術は比較的限られてしまうかも。考えつくのは分割戦術だ。大規模であってまともなアーキテクチャが採用されていれば、システムは分割され、いくつかのサブシステムが疎結合されているはずだ。その中には、障害耐性要求やパフォーマンス要求が比較的低く、長期的には利用されないことがわかっているサブシステムがあるだろう。なければ、そういうサブシステムの必要性を指摘して需要を喚起すべきだ。それによって、そのサブシステムに対する適用というのが取れる。後はそのサビシステムに対するコミットメントの問題となる。コミットメントが見えないから信用がおける方法を取っているというのが実情のはずだ。そのサブシステムが成功すれば、次は適用領域が拡大できる。逆に適用結果が思わしくなければ、コミットメントに従い、リカバリーするしかない。したがって、開発速度は非常に重要となる。01:12)バキネタがくるとは。