«前の日記(2007-02-07) 最新 次の日記(2007-02-09)» 編集

Matzにっき


2007-02-08 [長年日記]

_ 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から

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

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

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

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

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

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

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

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

本日のツッコミ(全8件) [ツッコミを入れる]
_ ささだ (2007-02-19 19:20)

ぜひカニを食べながらした議論についての詳細を! 彼にIRCで聞いたほうがはやいかしらん。

_ まつもと (2007-02-19 22:20)

書きました。

_ toshihiro (2007-02-19 22:20)

>さあ、どうやって機嫌を取ろうかな。<br>そういう理由でしたか。自分も今回の視察は命がけ。<br>保育園の発表会にはいかないパパでした。

_ Betakhi (2007-02-20 01:00)

I am learning Ruby in University and I found it wonderful to have such a convenient and powerful programming language.<br><br>http://myweb.polyu.edu.hk/~05041683d/RubyTanPublish.jpg<br>This is Rubt-tan(Ruby娘), a mascot that I design for Ruby and I would be happy to hear comments on it, esp. from the designer of Ruby, you!^^<br><br>Once again~Please keep your good work!

_ eto (2007-02-20 10:29)

encodingがunknownの場合はどうすんだろう.例えばSJISのはずだがはっきりそうとはわかっていなかった文字列が,SJISだとはっきりわかった場合とか.その場合もencodeで作り直すのかな.

_ まつもと (2007-02-20 11:20)

そうです。<br><br> unknown.encode("shift_jis")<br><br>という感じですね。変換元がunknown(binary)の場合はエンコード情報が変わるだけで実際のコード変換は行われません。<br>第2引数を指定した場合には(iconvなどを利用して)コード変換が行われます。<br><br> # shift_jisからutf-8への変換。順序は逆になるかも<br> unknown.encode("utf-8", "shift_jis")

_ 成瀬 (2007-02-24 04:43)

unknown.encodeを使うやり方だと、<br>1.encodeしていないのにencodeメソッドを使うのに違和感<br>2.encodeメソッドはあるのにdecodeメソッドがない<br>3.sjisとして入ってきたが、その文字列が実はutf-8なので、encodingを訂正したい場合に対応できない(sjis.encode("utf-8","utf-8")とかしますかね)<br>といったデメリットがあるように感じます。

_ まつもと (2007-02-24 10:02)

まず、1.と2.については慣れだと思います。<br>encodeしたものはかならずdecodeしなければいけないわけではないですし(2)。<br>実際には符号化方式を指定するだけで符号化するわけではないのにencodeという単語は少々おかしい(1)というのは一理あります。が、致命的ではない気もします。<br><br>でも、encodeの代わりにencoding("utf-8")とでもするかな。<br><br>3.のエンコーディングが間違っていて直したい場合には、当面は<br><br> sjis.encode("binary").encode("utf-8")<br><br>で対応することを考えてます。必要性によっては専用のAPIを作った方がよいかもしれません。<br><br> sjis.encode("utf-8","utf-8")<br><br>もそんなに悪くないかなあ。

お名前:
E-mail:
コメント:
[]

«前の日記(2007-02-07) 最新 次の日記(2007-02-09)» 編集

track feed Matzにっき Creative Commons License This work is licensed under a Creative Commons License.