Matzにっき

_ [映画]『アンブレイカブル』

『サイン』の次に妻が借りてきたのは『アンブレイカブル』だった。 それは私に対する挑戦かっ。あらかじめサイテーだって言ったじゃん。

で、感想を聞いたら、

まあ、『スパイダーマン』と同じようにマンガよね

だって。

いや、確かに『スパイダーマン』はマンガだ(言うまでもなくアメコミ原作だし)。 普通の高校生が遺伝子操作されたクモに噛まれて超能力を身につけるなんて 「そんなことあるかよっ」とツッコミをいれたくなるような話だ。

しかし、しかしだ、それと

• マンガとリアルの区別もできないアメコミコレクター、サミュエル・L・ジャクソン
• ご都合良く、理由もなく、マンガから抜け出してきたような能力を持つ男、ブルース・ウィリス
• スペクタクルもカタルシスもない展開、しょぼい悪党
• 映画の本質なのに、なぜ超能力があるのか一切説明されない、説明する気もない

ようなツッコミたくてもツッコミようがない映画と一緒にするのはマンガに対して失礼だというものだろう。 『シックス・センス』のようにラストのどんでん返しを狙ったのはミエミエだけど、 オチは少々意外だったのは確かだが、私にはおもっきり外したように感じられたなあ。

大傑作だとは言わないが、すくなくとも『スパイダーマン』の方がエンターテインメントに対して真摯だ。

もっとも、妻はマンガを軽蔑してるから、無理もないのかもしれないけど。

そんな彼女が映画館に『スパイダーマン』を見に行った理由は謎だ。 しかも、面白かったって言ってたよなあ。

_ [OSS]オープンソースの定義と思想

あまり戦線を拡大しても疲弊するだけなので、まず私の意見をまとめておこう。

まず第一にオープンソースの定義について。

私は「OSIマンセー」*1ではないと思っているのだが、用語の定義についてはこだわる。 定義が違ったままでは対話が成立しないからだ。 そして「オープンソース」という用語についてはきちんとした定義が与えられており、 それに従わない(≒合意を破壊する)のは対話を拒否することを意味しかねないからだ。 自分の意図を正しく伝えたければ、自分勝手な用語の定義を用いるべきではない。

オープンソースという言葉について誤解する人(あるいは誤解したい人)はいると思うが、 それはオープンソースという言葉の定義を好き勝手にしてよいという理由にはならないはず。 定義を知らない人には教えれば良いだろう。間違えた人には諭せばよいだろう。 そして、定義をねじ曲げたい人には抗議するべきだ。

次にフリーソフトウェアとオープンソースについて。

オープンソースの定義は客観的なものだ。 「思想が入っているからオープンソースとは呼ばない」というのは無意味だ。 あるソフトウェアがオープンソースかどうかは、 そのソフトウェア(のソースコード)をどう扱ってもよいかということ(つまりライセンス条項) から客観的に決められ、開発者の意図や思想とは無関係である。

一方、フリーソフトウェアの方はちょっと思想が入っている。 が、フリーソフトウェアは自動的にオープンソースになるようにOSDは定義されている。

では、フリーソフトウェアとオープンソースソフトウェアは違うのか。

ストールマン的には大違いであろう。 彼は「フリー(自由)」という言葉を手放すことは危険だと感じているからだ。 また、「オープンソース」という単語が利用者だけに都合が良い「無料でソースが入手できる」ことを 意味して使われるようになることを彼は危惧していた。

私は今までそれほど心配していなかった。OSDの定義を使う限り、 オープンソースという単語を使ってもソフトウェアの自由は保護されると思っていたからだ。 だから、「フリーソフトウェア」という言葉を使っても、「フリーソフトウェア」「オープンソースソフトウェア」という言葉を使っても、 結局は同じだと思っていたのだ。「無料」と誤解されるよりはずっといい、と。

しかし、この言葉が使われるようになって数年、いまだにこのようなことをわざわざ説明せねばならないようでは、 彼の危惧が当たっていのではないかと感じる。

あなたは本当にソフトウェアの自由はどうでもよいのか。

自由を実践していない「オープンソースソフトウェア」について。

あいかわらず、そんなものはごく少数だと思っている。 実際に自由を実践していない、ソフトウェアの自由なんかとはいかなる形でも関係のない、 「オープンソースソフトウェア」が無視できない数あるというのであれば、報告していただきたい。

そのようなものがないのであれば(ストールマンの危惧を別とすれば)、 フリーソフトウェアとオープンソースソフトウェアを区別する必要はないだろう。

ただ、「フリーソフトウェア運動」と「オープンソース運動」はまったく違うものであり、区別すべきだ、 ということは付け加えておこう。

最後に「思想」について。

どうも「思想」という言葉は忌避すべきものだととらえている人が多いのではないかと感じられる。 戦後日本の悪癖だろうか。って、自分自身が戦後日本の申し子のようなものだが。

しかし、人間は思想なしで存在することはできない。 本当に思想がないというならば、それは考えないということである。 ということは「ノンポリ」さえ思想である。

であれば、「思想」という単語に過剰反応するのは無意味であろう。 あと、「宗教」もそうなのだが、これについては今日は触れない。

_ [OSS]42件の収束

もはや私は「42件」に興味はない。たださんの日記の記述で十分だし。

これからは６月の討論会に向けて

• フリーソフトウェアの経済効果
• 政府とフリーソフトウェア開発者とのかかわり

などのテーマについて考察していきたい。

まず、「作業メモとか考えた事とか(5月)」が 参考になるだろう。

_ クラックされました

www, ftp, cvsなどを提供しているhelium.ruby-lang.orgがクラックされました。 クラックされたのはnamazu.orgなどと同様に CVSの脆弱性によるものです。アップデートをサボっていました。迂闊。

28日に確認したところ、未知のプロセスがいくつか動作しており、 バックドアが仕掛けられていました。

ただし、helium.ruby-lang.orgではCVSはchroot環境で動作しており、 またバックドアポートへのアクセスもフィルタリングされていました。

ですから、helium全体が侵入されていない可能性はかなり高く、 現時点ではchroot環境外での改竄は発見されていないのですが、 侵入者の意図、目的、手段、技術レベルが分からない現状では安心は出来ません。

現在、スタッフが安全性の確認を行っています。

• 各メンバのsshキーの確認
• CVSリポジトリの改竄確認
• ftpで提供されているrubyの各バージョンのチェック

などはほぼ完了しています。しかし、改竄されていないことの証明は難しいですよね。

作業してくださっているみなさんに感謝します。特に前田くんは金曜・土曜がつぶれちゃったね。

犯人が見つかった場合には不正アクセス法違反に加えて、 (netlab.jpに被害を加えたことで)会社として損害賠償も請求することになると思います。

前田くんたちの単価は高いぞぉ。

_ [教会]松江

回復しきっていない妻と末娘には留守番をお願いして、教会へ。 教室の鍵の整理などした他は特に変わったこともなく。

ただ、結構風邪などで休んでいる人が多い。今週は監督もお休みだったし。

夕方、年に一度の非常時対応訓練で連絡網を通じて連絡を行った。 今年からケータイメールを活用してみたのだが、首尾はどうだったのだろうか。

_ [Ruby] yieldとProc#call

歴史的に見るとyieldを使うのが先にあって、&block (ブロック引数)でオブジェクトとして受けとり、callメソッドで呼び出すのが後から登場している。 記法的に考えると後者の方が優れている(現在の実装では、効率は前者の方が少しだけ良い)。

しかし、ブロック引数を使うとエラーの出力が良くないのが欠点である。 つまり、

def foo1
   yield
end
def foo2(&block)
   block.call
end

foo1  # => in `foo1': no block given (LocalJumpError)
foo2  # => in `foo2': undefined method `call' for nil:NilClass (NoMethodError)

どちらもエラーには違いないが、メッセージが直接的に意味するところを考えると 前者の方が優れている。

で、1.9ではこうしようかなと考えている

• Proc#yieldメソッドを導入(これには他にも理由があるのだが、別のときに述べる)
• nil.yieldメソッドも用意。これが「no block given」のメッセージを出す

すると、こうなる。

def foo1
   yield
end
def foo2(&block)
   block.yield
end

foo1  # => in `foo1': no block given (LocalJumpError)
foo2  # => in `nil.yield': no block given (LocalJumpError)

「foo2」が表示されないのが惜しいが、まあ、だいぶマシになったのではないだろうか。

_ A Unified Theory of Garbage Collection

ガーベージコレクションの大統一理論。 だいぶ古い論文(2004)だが、最近改めて読み直したので。

一方にルートから生きているオブジェクトをトレースするtracing gcがあり、 他方に参照数を数えることにより、死んだオブジェクトを発見するrefernce counting gcがある。この二者は「物質」と「反物質」のように相対する関係であり、 片方を改善するテクニックには、かならずそれに対応する他方を改善するテクニックが存在する。結局は組み合わせにすぎない、という理論。

将来、誰も知らなかったようなGC手法が登場する可能性は低いことを示しているが、 逆に状況に最適なテクニックのセットを発見するための、理論的な背景にもなるので 非常に有用のような気がする。

_ 東京へ

8時ちょうど...ではなく、7時59分のあずさ6号に乗って東京へ。

松本から東京は思ったよりも近い。飛行機じゃないから気楽だしね。

東京ではニューヨークから来たRubyユーザと一緒にお昼。 Rubyのこと、ほめてもらえるのはうれしい。けど、照れ臭い。

あと、日本の食事は安いとか、日本のベーグルは本物じゃない、とか。 文化とか食べ物とかのこと。あと2週間日本にいるというのに RubyKaigiのこと知らなかったので紹介しておく。 が、今からチケット買えるんだろうか。

_ プロコン実行委員会

U20プロコン実行委員会。 今年はどのくらい集まるかなあ。

会合終了後、よしおかさんのポロシャツをほめたら できたばかりというレアモノのAsianuxポロシャツをいただいた。

ラッキー。

_ 明日の準備

明日のLinux World/Expo Tokyo 2007での発表は 後半にRailsのデモをやってもらうように会社の人にお願いした。 が、あんまり発表とか経験がなかったので 緊張しまくり。とにかく準備するしかないと

• 台本の用意
• 練習

の繰り返し。コストに見合うかどうかはともかく、熱意はすごい。 今後の成長の糧になるといいね。

_ ホテル

稲荷町のホテル。古いのはともかく、 浴室がひどい臭い。もう泊まらない。

_ [言語] Rail - Esolang

Railsでなく、Rail。Rubyとは関係ない。

RailはBefungeやPATHの流れを汲む二次元言語。 Railでの「Hello World」はこうなる。

$ 'main' (--):
 \
  \-[Hello World!\n\]o-#

標準入力を標準出力にコピーするcatはこう。

$ 'main' (--):
 \
 | /---------\
 | |         |
 | \    /-io-/
 \---e-<
        \-#

ループが「ループ(輪)」として目に見えるのが特徴。

_ [Ruby] Google Translateよ、まつもとゆきひろ氏の出演はヒミツじゃありません - Allegro Barbaro [ITmedia オルタナティブ・ブログ]

CodeGearのイベント記事をGoogle Translateで翻訳したら 出席するはずの私の名前が消えてしまったという話。

なぜ、むしろ翻訳しやすいひらがなの「まつもとさん」の名前を翻訳できず、漢字の木村明治さん（Akijiになっているけど、正しくはMeijiさん）が翻訳できるのか、不思議。

となっているが、実はひらがなの名前は機械翻訳泣かせである。 つまり、漢字の羅列は名前として認識しやすいが、 ひらがなだと、通常の文の一部として解釈することが多いようだ。 たとえば、

まつもとゆきひろ

を

「まつも」と「ゆきひろ」

と解釈し、「まつもってなによ」と混乱してしまうとか。

というわけで、6/5にはCodeGearデベロッパーキャップゲスト出演します。

_ ITmedia +D LifeStyle：飽和するコンパクトデジカメ、脱却の糸口を探す (1/3)

デジカメにおいて、機能競争が飽和してきていて、 打開するためには「時流に反した割り切り」ではないか、という話を、 リコーを題材にして。

機能競争というのはソフトウェア(や言語)の世界でも日常的で、 なんだかんだ言っても「なにができるか」で評価されることが多いんだけど、 そういう時こそ違う評価軸(たとえばRubyなら「どのくらい気分が良いか」)を 提示することが成功の鍵になるのではないか、と思う。

_ [言語] PHP is dead ... long live PHP! | Dries Buytaert

連日PHPを話題にしているのは、 PHPを嫌いだからじゃなくて、PHPという言語の状況が素材として面白いからである。

今回のお話は

• PHP5への移行が進んでいない(20%以下)
• 各種アプリもPHP4/PHP5両対応
• 現在のペースから演繹すると2009年になっても70%程度ではないか
• PHP5の機能は活用されていない
• PHP5への移行インセンティブが弱い

結果として開発者はPythonやRubyに逃げていき、PHPは死んでしまうのではないか、という懸念。

あらゆるソフトウェアについて新しいバージョンへの移行は 難しいことであるが、PHPの場合、それが顕著なのかもしれない。

Rubyでも1.8と1.9の間にギャップがあるので、 似たような状況にならないとは限らない。