B0000W3OHY 話題の大作ではなく、1978年のアニメ版。 『王の帰還』を見る前に全体を振り返っておこうと思ったからだ。 「ひどい作品」という噂は聞いていたが、ダイジェストとしてしか期待していないので、 まあ大丈夫だろうと推測したのだ。
ロートスコープ(実写をそのままアニメ化する技法...らしい)を使ったアニメーションは、 見慣れないという意味で奇妙な印象を与える。 バルログだけは勘弁してほしい造形だったし、オークもいまいち。 実写もどきと安っぽいアメリカテレビアニメを混ぜたような映像を形容すると、やっぱり「奇妙」かなあ。 好きな人はいるかも。
でも、ストーリーについては原作(読んでません)を極端に圧縮しているだろう事を考慮に入れると、 そんなに悪くない。
が、始まってから2時間後、話の位置としては『二つの塔』の終盤でいきなり終わってしまう。 尺が尽きたか、気力が尽きたか、予算が尽きたか、いずれにしても、あんまりだ。
「ひどい作品」という噂の真の理由はそこにあったか。
魔球のことは秘球と呼ぶのですか、勉強になります。
そうすると、私が見たのはもしかすると「ゼロの秘球」ではなく、「黒い秘球」の解説だったのかもしれません。 記憶がかなりおぼろげですから。
もうひとつ、「回転するボールが水蒸気を巻き込みカクテル光線を反射して七色に輝く」魔球という解説の 記憶があるのですが、これはいったいなんなんでしょう？ いずれにしても、物理法則を無視した話ではありますが。
中部でもどこでもいいから、ちゃんとしたハブ空港がほしいものだ。 地方から海外に出ようと思うと、羽田から成田が遠すぎ。 関空も国内便が少なすぎてハブになってないし。
私の住んでるところが田舎すぎるというのはあるにしても。
ミラクルのよしおかさんが加わってるなら、 そんなに変なことにはならないかな。
とはいえ、「世界に通用するオープンソース人材」としてどのような人材を想定しているのかは、 興味深い。私には「コードが書けるだけでなく、コードが読める」ことと、 「メールなどネット経由でのコミュニケーションができる」ことくらいしか思いつかないのだが。
あ、あと「ほっといてもプログラムをばりばり書くほどのプログラミング好き」というのも必須かな。 育成するものではないような気もするけど。
そういう人材がいればうちの会社で欲しい。 Rubyでばりばりプログラムが書けるし、オープンソースの開発も優遇される。
XP界(というかテストファーストプログラミング界か)の「Mr.マリック」こと、 Brian Marickによる書籍のドラフト。まだ、中身読んでない。
彼にもらったCow Magでホテルのカードキーをダメにした人は私だけではないに違いない*1。
追記: よく見れば日付が2001年だ。もうすぐ出る、とかいう話ではなさそうだ。
*1 Brian Marickの奥さんは獣医なんだそうで、それが理由かどうかはわからないけど、毎回新しく知り合いになった人にCow Magを配っている。で、うっかりこの磁石をカードキーやキャッシュカードに近づけてしまった人は悲惨な目に遭っている。彼曰く「だから気をつけろって言ったじゃない」だって。
登録してみる。 が、Japan/Matsueなんてところに登録する連中は、 (いたとしても)ほとんど私の席から半径10メートル以内のような気がする。
増井さんがキーバインドを変えてセミコロンをリターンにしちゃった、という話。
それから、最近気がついたことは、セミコロン打たなくていいですよね、あんまり。キーボード入力してる時、セミコロンって小指にあるじゃないですか。これは非常にいいポジションなんだけど、C とか Perl では打つけど、Ruby では打たなくていいですよね。で、使わないキーがこんないいところにあるのはもったいないから、これリターンにしちゃったんですよ。
だから、私の機械は今全部、右手の小指がリターンなんです。すると手を全然動かさなくていけるんですよ。普通の人は、バックスペースで右手を動かすし、リターンでも動かすから、かなり無駄なんですよ。日本語を入力しててもかなり手が動いてるはずです。でも、ここをリターンにしてから、ほとんど手を動かさずに舐めるように入力できるようになりましたよ。
ところで、セミコロンはどこへ行ったかというと、キーボード右下部のキーを全部セミコロンにしちゃった。
まあ、私の場合、「；」は「え」の入力に使うから外せないのだが。
そういえば、もう10年以上前、飲み会の帰りにすっころんで、 左手首を傷めた時、左手をひねって小指でコントロールキーを押すのが辛かったので、 スペースバーをコントロールにしたことがあった(で、スペースを代わりにどこに割り当てたのかは覚えていない。たぶん「無変換」か「変換」だと思う)。なかなか快適であったが、 コントロールよりもスペースを押す回数の方が明らかに多かったので、 手首が治ったら元に戻したけど。
この時の経験が自分専用のキー配列の追求のきっかけになり、 最終的に「きゅうり改」を作る原動力になったような気もしないでもない。
次々と独自のライセンスが出てくるのは事態を複雑化させるだけだし、 整理できるものならした方が良いとは思うので、 この動きそのものは大歓迎。
ただ、ライセンスの移行は相当に面倒が予想されるので、そんなに簡単には進まないかも。
もうひとつ気になるのは、見出しの「OSIの動き」は歓迎されるものだとしても、 なんか本文の中身に違和感がある。
OSIが自らの役割の重要性を自覚していないのは明らかだ。彼らには、オープンソースが依拠するライセンスについての基盤が、信頼に足るものであるよう確実を期す責任がある
現状のライセンス認定プロセスでは、単に特定の仕様を順守しているかどうかが審査されるだけで、オープンソース業界のビジネスモデルをさらに革新する力がそのライセンスにあるかどうかは見過ごされている。これは、オープンソースを機能させている核心の部分に対して、はっきりと直接的に危険を及ぼすものと私には思える。OSIがいまのやり方を続けるなら、彼らは的外れな方向へ進んでしまうだろう
いや、OSIのやり方が良いといってるわけではないが、 上記の発言はなんだか「俺オープンソース」の匂いがする。 OSIが保証したかったのは「ソフトウェアの自由」だったはず(たとえその「自由」がfree software陣営が考えるものと少しずれていたとしても)、「業界のビジネスモデルを革新する力」があるかどうかなんて元々は関係ないはず。
OSI Certifiedライセンスの種類が増えてトラブルが多くなっているのだとして、 OSI Certifiedの認証プロセス中で、既存のライセンスを使えないかどうか説得する手順を増やす というならともかく、OSDを満たすライセンスを
われわれが、Sunに対して『（CDDLという）独自のライセンスがオープンソースとして認定されるわけがない』と言っていれば、SunではおそらくMozilla Public License（MPL）を選んでいただろう
と「門前払い」するのが正当のような物言いはいかがなものだろうか。
ちなみに上記の「的外れな方に進んでしまうだろう」という、 私からみれば「そっちの方が的外れでは」という発言は、 先日も批判したHewlett-PackardのLinux担当バイスプレジデントでOSDL理事のMartin Finkのものである。なんだかなあ。
追記
原文を読んでみた。 Finkの主張のニュアンスが翻訳で変化していてはいけないと思ったからだ。
該当部分は以下の通り。
"Clearly, the OSI has not internalized its critical role to ensure that the licensing underpinnings upon which open source is built remain a force to be reckoned with," Fink said.
"This current path of approving licenses--based simply on the compliance to a specification rather than on the basis of a new license's ability to further innovate the business model of the open source industry--represents to me a clear and present danger to the very core of what makes open source work," Fink said. "If this is the path the OSI continues to choose, then it is choosing a path towards irrelevance."
この部分に関してはニュアンスの変化はないようだ。Finkが徹底的にビジネスサイドからしかオープンソースを見ていないことがうかがえる。「混乱」して困るのは主にビジネスに利用したい連中で、個別の開発者のさほどでもない(でも混乱を増加させる必要はないと思うけど)。そこを「OSIがそうする責任がある」とか「的外れな方法」と強く強く主張するのは、FinkがOSIやひいてはオープンソースというものを、「利用」して(自分の)ビジネスのネタにしたいという「欲望」の現れではないだろうか。いや、そのような「欲望」が悪いとは言わないし、オープンソースをビジネスに利用してくれて結構なのだが、こうあからさまに押しつけられると迷惑な感じだし、ちょっと食傷気味。
それはそれとして、興味深いのは以下の部分が翻訳されていないこと。
Greenblatt, and other industry executives, believe the number of licenses can be dramatically distilled down.
"Eventually there should be three licenses: The GPL, a commercial version of the GPL and, of course, there will be the BSD because you can't rid of it," he said, referring to the Berkeley Software Distribution, or BSD, a popular variant of Unix developed by the University of California, Berkeley in the 1970s.
Greenblatt added that elements of other licenses, such as Sun's CDDL, could be used to form the short list of open-source licenses.
生き残る3種類のライセンスとは「GPL、商用版GPL、BSDライセンス」らしい。
日本語タイトルの「オープンソースライセンスを3種類に」というのはここから出ているのに、 この重要な部分が翻訳されなかったのはなぜだろう。そういえばITmediaでも翻訳されてないなあ。 ちなみに原題は「Open-source board eyes fewer licenses」である。 ここでの「Open-source board」はかならずしもOSIだけのことではなく、OSIとOSDLなどのメンバーからなる 「委員会」のことではないだろうか。
よくわかるのは今住んでる島根県と育った鳥取県なのだが、まあ、「くすっ」と笑えるくらいか。
しかし、宍道湖七珍の「すもうあしこし」ってなんだったっけ。
...だったかな。Googleするとトップはうちの会社の人だった。
よしおかさんによる。人財という話になっているようだ。まあ、そうかも。
コネクションは重要だ。が、そのコネクションを上手に活用するのはもっと重要だ。
私は幸い日本のオープンソース界ではたぶんトップレベルのコネクションを持っていると思うのだが、あんまり活用しきれてないなあ。
マレーシアで時間があったら、よしおかさんとそういう話もできるといいな。
1.9で定数探索のルールを変更した。1.8までの定数探索ルールは
だが、これはスーパークラスの定数とスーパークラスの定数がどちらが優先かよくわからない、とか、ネストの外側の定数参照はレキシカルな参照に見えるが実はそうじゃない、とか、あまり気に入らないと思っていたのだ。
新しいルールは以下の通り。
本当はもっと単純なルールにしたかったのだが、結局前と同じくらい複雑になっている。いろいろな局面でもっとも便利なルールを考えていたらこうなってしまった。
このルールの(2)でObjectを除いているのは、 Objectがグローバルな定数の置き場所になっているため。グローバル定数よりはよりスコープの狭いネストの外側の定数を優先したかったため。ネストの一番外側はObjectと決まっているので、このルールで見えるべき定数は全部見える。
探索順序が変わっただけで、探索範囲は減っていないから、定数の名称が重複しない限り問題は発生しない。
標準添付のライブラリの範囲内で問題が起きたのは以下の二ヶ所。
webrick/httpservlet/cgihandler.rb:
class CGIHandler < AbstractServlet
Ruby = File::join(::Config::CONFIG['bindir'],
::Config::CONFIG['ruby_install_name'])
Ruby << ::Config::CONFIG['EXEEXT']
CGIRunner = "\"#{Ruby}\" \"#{Config::LIBDIR}/httpservlet/cgi_runner.rb\""
ここではトップレベルのConfigとWEBrick::Configが混在している。 5行目を以下のように書き換えた。
CGIRunner = "\"#{Ruby}\" \"#{WEBrick::Config::LIBDIR}/httpservlet/cgi_runner.rb\""
よりわかりやすい方向に矯正されたと思う。
もうひとつはresolv.rb:
class A < Resource ClassHash[[TypeValue = 1, ClassValue = ClassValue]] = self
ここの「ClassValue = ClassValue」が問題の箇所。これはネストの外側の定数を自クラスにコピーしている、と読むらしい。
以下のように書き換えた
class A < Resource TypeValue = 1 ClassValue = IN::ClassValue ClassHash[[TypeValue, ClassValue]] = self # :nodoc:
こちらもより明確になったのではないだろうか。大差ないけど。
ついでに、load()のwrap modeにおいて正しい順序で定数探索するようにした。 1.8ではwrapを行うanonymous moduleの優先順位が高すぎる。 1.9でもメソッドの探索順位は直ってないわけだが...。
これは将来Classboxを導入した時にwrap modeをClassboxで実装すれば根本的に解決するように思う。Classboxっていろいろ使えるな、魔法のようだ。効率良く実装できれば世界が変わるかも。
それはめでたいことで。
うち(Ruby)も構想ばかりでなく、もっと前進させよう。 考えるばかりでなかなか踏み出せない。 なにか機会が必要なのだろう。
私と笹田くんへのインタビュー。今回は第一回目。
朝から雪で、教会から帰ったら家の前の坂道が雪で滑って登れない。 先に帰った妻は子供たちと一緒に雪かきをしていた。 子供たちはどちらかというと雪遊びをしていたんだけど。
しかし、今年高校受験の長女は、勉強もせずに雪まみれになって 「滑ったり」、「転んだり」、「(溝に)落ちたり」していたのだが、 それはそれでいいんだろうか。
ところが、夕方になって妻が「寒気がする」とか言い出した。 どうやら先週の半ばに引いていた風邪が治りきっておらず 再発したらしい。
微熱と関節痛など典型的な風邪症状。 インフルエンザではなさそうだが。
あんまり具合が悪そうなので、 明日からのアメリカ行きは無理かもしれないと思った。 ただ、私が行かないとツアーの人に迷惑をかけちゃいそうなので 家族と仕事の都合の板挟みになって、精神的にかなりつらかった*1。
*1 結局、朝にはかなり回復していたけど