Matzにっき

_ Happy Birthday

今日は妻の誕生日。なのにダンナはアメリカにいるわけで、 不興を買っているわけである。 日本時間の8日にSkypeしたんだが、ぜんぜん通じないのである。 この辺、電話にはまだかなわない。

さあ、どうやって機嫌を取ろうかな。

_ Meeting with Sun Microsystems

今日はSunキャンパスのEBC(Executive Briefing Center)で Full-day Meeting。ここが本社だと思ってたんだけど、 登記上の本社は別にあるのだとか。

で、いろいろな「偉い人」から

• Sunのソフトウェア戦略 David Bryant, Senior Director of Marketing, Application, Platform Products - 隠さない、「間違った側」に立たない、イノベーションを継続する
• Webベースソフトウェア戦略 Tim Bray, Director of Web Technology - 特定の言語(Javaを含めて)に必要以上に肩入れしない、でも、PHPのセキュリティ問題は勘弁してほしい。できることならPHPの代わりにRubyを勧めたい
• JRuby戦略と現状 Charles Nutter, JRuby Core Developer - もっとも「ダイナミック」な言語、この知見は他の言語にも応用可能。JavaOneで1.0アナウンス(か？)。NetBeansすげーっ。
• 松江市のオープンソース戦略(一部オフレコあり) - 田中さん, 松江市役所
• Sunのオープンソース戦略 Barton Geroge, GNU/Linux Strategy and Community Manager, Free and Open Source Group

などを聞いた。ここでしか聞けないすごい濃い内容であった。 詳細なレポートを書きたいが、それにはこの余白は(ry

また、後でまとめたい。できれば。もうだいぶ忘れてるけど。

特記すべき点はみっつ。

• 通訳。すっごい上手だった。 白人紳士と日本人女性の二人組が交代で通訳するのだが、 これほど上手な技術系通訳には会ったことがない。 感動モノであった。
• お弁当。すっごい豪華だった。和食弁当だけど。 なんか終始日本食なのが今回の旅行の特徴というか何というか。
• 生Jonathan。なんかビジターセンターみたいなところで Sun CEO、Janathan Schwartzその人がインタビューの収録をしていた。 また、あとでキャフェテリアを訪問したら、彼がふつーに歩いていた。 いやあ、すげーっ、至近距離だよ。 あと、Tim BrayにSunソフトウェア担当VPの人にも紹介してもらった。 (私から見ると)大物ばかりで緊張しちゃう。

参考: この日のミーティングに関するTim Brayのブログ。

_ カニ

明日にはもう帰国するので今夜が最後のアメリカでの夕食になる。 で、連れて行ってもらったのはCrusatceamという店。

で、カニ。

見たことないほど巨大なものが一人一人の皿に配られるのは圧巻であった。 バジルとオリーブオイルで炒めたものらしい。日本では見かけない味つけ。 意外(？)なことにおいしかった。

今日は今回の旅行のひとつのハイライトと言ってもよい。 あ、いや、Sunの訪問がね。

で、カニを食べながら隣に座っていた Charles NutterとRubyの可視性(visibility)やUnicode対応について 熱く語ったのであった。正直、ここまでRubyそのものの話ができる機会は 日本でもなかなか無い。

_ [Ruby] 可視性メモ

で、Charlesと話したことのメモ。

private visibilityが必要になるのは、 ローカルなルーチン(関数 or メソッド)の名前がpublicなメソッド名と偶然衝突することを避けるため。

で、組み合わせとしては以下のような場合がある。

スーパークラスとサブクラスで同名のメソッドがあり、 それぞれの可視性の組み合わせの可能性は(左がスーパークラス)、

1. private × private
2. private × public
3. public × private
4. public × public

である。ここで4は通常のオーバーライドなので問題なし。 1と2に関してはすでに解決策がある(functional styleではオーバーライドしない)。

で、残る問題は3。私の元の案では、 privateを先に検索してからpublicを検索することにしていた。 しかし、これについてはCharlesから

• 継承をさかのぼった検索が２度起きるのは性能上問題
• 継承のどこにあるメソッドが呼ばれるのかわかりにくい

という指摘が。前者はメソッドキャッシュでほぼ軽減されるとは言え、 指摘はもっともだ。で、ここまでで悩んでいたのだが、 今回、カニを食べながら、Charlesが 「でもさ、無理に解決しようとするから難しいんで。 Javaならpublic × privateはそもそもエラーだぜ。 Rubyでもエラーでいいんじゃね(意訳)」という指摘が。

まったくだ。どうしてそれに気がつかなかったんだろう。 一種の視野狭窄か。

「public × private」がエラーなり警告なりで存在しない (あるいは承知でやっている)と見なすことができればシステムがずいぶん簡単になりそう。

あとでもうちょっと考えてみよう。

あと、Unicode対応では、以前の案からencoding=メソッドをなくすことにした。 つまり、ある文字列のエンコーディングは動的に変更できないということ。

変更するためにはString#encodeメソッドを使って新しい文字列を作る。 おそらく性能のため実装はcopy-on-writeを使うことになるだろうけど。

というのも、JRubyではBinary StringとUnicode Stringで クラスを分離したい(少なくとも内部的には)というニーズがあるようだ。 となると「普通の言語」ではオブジェクトのクラスを動的に変更するのは難しいので エンコーディングは変更可能でない方がありがたいことが多いだろうということ。