Matzにっき

_ [会社]ペア・プログラミング

実は今までペアプログラミングをしたことがない。 性格が破綻しているのでプログラミング上の相方が見つからないからだ。

なんてなことを言ってたら、後輩から「うちのプロジェクトに来てみませんか」とのお誘いを受ける。

というわけで、今日からペア・プログラミング初体験だっ。 といいつつ、初日から寝坊して遅刻。 さらに始まってからは、ドライバーは相棒に任せて、後でひたすらツッコミを入れる役。

本当に役に立ってるんかいな。

_ [OSS]日本におけるOSSの幻想-OSS界のガラパゴス諸島、ニッポン

日本においてはOSS振興の流れが出てきてはいるが、「すべてがうまくいっているわけではない」とVAリナックスの佐渡氏は話す。いびつに変質したコミュニティなど、日本はOSSのガラパゴス諸島であると持論を展開する。

佐渡さんってば前にも同じようなこと言ってるよね。

佐渡さんが言ってるようなことが起きていないとは私は言わない。 OSS全体を見れば確かに日本からの貢献は少なく見える。 少なくとも多くの人はそう認識している。 ついこないだもEric Raymondが「日本は人口や教育レベルの割にハッカーが少ない」ってメールに書いてたし。 でも実際のところはどうなんだろう。

まず、(私の感じている)事実から。佐渡さんの意見を裏づけるものは以下の通り。

• 日本人であって日本人以外から広く知られているOSS開発者は非常に少ない。本当に少ない。
• SourceForge.jpのプロジェクト数は1,297で、本家の91,783にははるかに及ばない。 もっとも本家にプロジェクトを持っている日本人もいるから一概には少ないとは言えない(いや、少ないと思うけど)。
• 日本におけるOSSの利用は他国に負けていない(らしい)。
• 日本からのパッチ(特に国際化関係)が無碍に受け入れられなかったケースはいくつか知られている。 特にコミュニケーション不全によるものが目立つ。

でもね、それって結局「英語が下手くそ」という点に還元されるような気がする。 しかも、英語が下手くそな理由は「使わなくてもすむから」なわけで。

たとえば、英語以外の母国語だけでOSS関連のちゃんとしたイベントができる国は少ない。 私の知ってる範囲内では、フランス、ドイツ、デンマーク、ベルギー、オランダ、メキシコ、ブラジル、中国、インドのイベントでは英語は必須。日本は貴重な例外。お隣の韓国はどうか。

ということは、佐渡さんが観察した「問題」は、結局日本は恵まれている(恵まれすぎている)ということの 現れのような。

であれば、言うべきことはただ単にダメだ、ダメだとか、

肝心なのは日本で閉じることなく、グローバルに出て行くこと

なんて どっかで聞いたような結論じゃなくて、 なぜグローバルに出て行くべきか、 ちゃんとコミュニケーションするとこんなことがトクってことじゃないだろうか。 あるいは日本で閉じているとこんなに損だ、とか。

ところが、数少ない「グローバルに出て行くこと」を実践している人物のはずの私でさえ、 改めて考えるとなにがトクなのかよくわかんないんだよね。 「グローバルに出て行くこと」で海外から収入を得ているわけでもないし、 より多くの人に恩恵を与えているってことで 「エゴ(自尊心)を充足させる空間が広い」ってことくらいか。

でも、エゴは食えないしな。

ORCAについては...、いろいろあるが、別の機会にしよう。

_ [OSS]なぜグローバルか、私の場合

2日のエントリでは、 「なぜグローバルに出るべきか示されていない」という話をしたが、 私の場合について書いておくべきだろう。

とはいえ、たいしたことをしたわけではない。私がやったことは

1. 英文ドキュメントを用意した
2. 英語メールの問い合わせに対応した

これだけである。英文ドキュメント作成の動機は単純である。 以前、技術的に非常に興味深いSchemeインタプリタのソースを入手した時に、 ドキュメントやコメントが全部ロシア語だったことがあった。 で、非常に腹立たしかったので、自分が人に同じ思いをさせるのはイヤというのが直接の動機だった。 英語の勉強にはなったしね。

とはいえ、私も英語は下手くそなので、 当初はあちこちのドキュメントから切った張ったして作った醜いもので、 いまだったら紅白出場停止になりそうな代物だ。

でもって、検索エンジンなどを経由してRubyに興味をもってくれた人が メールをくれたので、それに返事をした、それだけである。 もっとも「やったこと」はそれだけでも、量は半端じゃないんだけどね。

で、グローバルに出ていったことが私にとってどのようなメリットになったのか、と言えば、

• 海外でも名前が知られるようになった

  「RubyのMatz」と言えば、知っている人は知っている存在になった。 名誉欲はオープンソース開発の動機のひとつと聞いているので、 価値も意味もあることなのだろう。個人的にはあまり重要ではないけど。

• 海外に友達ができた

  まあ、これ以外の方法で、Dave Thomas, Andy Hunt, Martin Folwer, Ward Cunningham, Bjarn Stroustrupなどなどと親しく話 す機会は、私にはなかったろうなあ。

• 人の金で海外旅行ができた

  エージェントが倒産して、踏み倒されてしまったLinux Expo Parisを除いては、 JAOO(x2)、OSCONなど年に数回旅費向こう持ちで海外に旅行している。 もっとも観光は全然してないけど。

• 「外圧」で国内でのポジションも高まった

  国内で知られているオープンソースソフトウェアを開発している人は珍しくないが、 海外でも広く使われているものは例外的だ。海外でRubyが使われているおかげで、 国内での立場も向上しているような気がする。 おかげで今の職を得ているような気がするので、このメリットは無視できない。

というようなものだろうか。結構あるじゃん。

しかし、Rubyの開発を始めた10年前ならともかく現在なら、 多くの場合、国内だけでオープンソースソフトウェアのエコシステム(生態系)が確立できそうな気がする。 だとすると、「グローバルに出て行くだけが道でない」という意見に対する適切な反論はないような。

私だって「グローバルに出て行かないともったいないよね」とは思っている。 現状で、それが「万人が」、「英語という壁を乗り越えて」、「出て行くべきだ」と言えるほど 強い動機づけかどうかは自信がないってこと。

むしろ、壁があるっていうなら、それを乗り越えることがビジネスになる。 佐渡さんの話ではそれは「Fake Open Sourcer」なのだそうだが、 僕の目から見たら、(日本の事情を反映した)立派なOSSビジネスに見えるけどなあ。

ビジネスじゃなくても、「日本のOSSを海外に紹介する」なんてのはひとつのプロジェクトになるかもね。 個々の開発者を強制するよりもマシなやり方があるかも。

追記:

在外邦人さん:

give してトクしようって話じゃなくて、take ばっかしてると嫌われるから give もした方がいいんじゃないかって話なだけだと思うんだけど違うんですかね。

「嫌われる」んですかねえ。オープンソースソフトウェアに限って言えば、 いくら take されても実害はありません。「使ってやってるんだ」と言われれば腹が立つけど、 静かに使ってくれているぶんには邪魔にはなりません。

もちろん、giveしてくれるぶんには大歓迎だけど、 「giveもしないでtakeばっかり」というのは違う気がします。

knokさん

得する例としては、ローカルパッチをちゃんと上流に取り込んでもらうことで、新しいバージョンへの追従をいちいちしなくて良くなることが挙げられるとおもいます。

パッチを本家に返さないってのは私にも理解できないのですが、 国際化パッチのように挙動や仕様を変更してしまうようなものについては そういうことが起きやすいのかもしれません。

_ [原稿]Linux Magazine 2月号

年末進行で思いっきり〆切が早い。先月に比べると10日も早い。

今月はDependency Injectionがテーマ。 一気呵成に3分の2ほど書いた時点で、内容が Rubyist Magazine 2号のRuby Library Reportとかぶりまくっていることに気がつく。 この記事を読んだ時からイヤな予感はしてたんだ。

あわてて書き直し。間に合うかしら。

_ バグレポート指南

Joel on Softwareより、

バグレポートにもうまいやり方がある、という話。

すべての良いバグレポートに必要なものは正確に3つだ。

• 再現する手順、
• 期待されること、そして
• その代わりに観察されたこと。

全くその通り。バグレポートする人はこの3つを忘れないで。

あ、私宛のバグレポートには第4の要素として

• それを修正するパッチ

が付いてると大歓迎です。

_ [教会]命名

末の子の命名の儀式を行う。 何度も行うことではないので、すっごい緊張した。 とちるし。

おまけに娘は途中で泣き出して、ほとんどパニックだった。 泣いたのは4番目にして初めてだなあ。

_ [原稿]Linux Magazine 2月号(その2)

先日も書いたように書き直し。 結局、「自前でDIコンテナを書く」という荒技に。

しかし、DIコンテナの基本部分がわずか20行ほどで書けてしまうという事実に、 我ながら驚愕する。

_ [言語]言語設計者とヒゲ

「Why Microsoft can Blow-Off with C#?」によると、成功する言語の設計者にはヒゲが生えている(だから、C#はダメ)らしい。Java、C, C++, PerlはOK。

そこには、

The authors of others script languages have no moustaches. Ruby and the Python is better, than Perl, but meet where less often than Perl. There is, however, a hope for Van Rossum, suddenly will grow a beard. It is not necessary to count on Mr. Matsumoto - at Japanese the beard grows badly.

とあり、ご丁寧に私の写真まで載せている。これは島大で撮ったものだな

「日本人にはヒゲがあまりない」だと。決め付けるなっ。

悔しいので、古い写真を引っ張り出してきた。 これは長女が生まれる前だから、Rubyを作りはじめるよりは前の写真だけど、 作りはじめてからも数回伸ばしたことがある。

これでどうだ。

追記:

「プログラミング言語の設計者に女性はいないのでしょうか」とのことだが、上記のページにもあるGrace Hopper女史(COBOL開発者)は女性だし、 Barbara Liskov(CLU)も女性だ。もちろん、ヒゲはない。

_ [OSS]ガラパゴス

佐渡さんからメールをいただく。

予想した通り、本人の意図とは違う部分が強調されているとのこと。 ま、そんなもんだ。

_ [OOP]Traitsについて再び

OOPSLA 2004の「Applying Traits to the Smalltalk Collection Classes」を読み返し、 Traitsについて考えてみる。

で、しばらく考えるにRubyのようなOpenなクラス/モジュールを持つ動的言語では、 TraitsよりもMix-inの方が適しているという結論に達した。

しかし、Traitsの演算は魅力だ。Moduleへ演算を追加することで、 Mix-inのまま、Traitsの利点を導入することは理論的には可能のような気がするが、 普通に実装すると実行効率が下がりそうな気がする。

内部的に多重継承を素直に実装するのが一番単純だが、 CLOSのように毎回クラスリストをソートするのは避けたい。

いろいろ考えるに、

• モジュールに変更タイムスタンプをつける
• メソッド検索時にタイムスタンプの比較も行う
• モジュールに対してメソッドの削除(exclude)演算を用意する。 あるいはモジュールのundefの挙動をexcludeにする。
• モジュールから、そのモジュールから指定したメソッドをexcludeした新しいモジュールを生成するメソッド(exclude)を新たに定義する

ことで、Traitsの良さとMix-inの良さのいいとこ取りができそうだが、 タイムスタンプを格納する領域とか、excludeの効率の良い実装とか、 実現までには解決しなければならない問題がいくつかありそうだ。

_ [OSS] matz氏とoswayについて話す

佐渡さんのブログ。私宛のメールの公開。

_ [PC] 米IBM、PC事業をLenovoに売却

せっかくX31を買ったのに。

いや、IBMブランドにすごく思い入れがあるというわけではないので、 今までと同じサポート、今までと同じ方向性、そしてタッチパッドでないポインティングデバイスが維持されれば、それでいいんだけど。ちょっと不安。

_ Linux Magazine休刊

噂は聞いていたが、今日、担当編集から直接メールをもらった。正式決定らしい。 3月号(2月8日発売)で休刊。

長らく続いた私の連載も最終回となる。通算16回。 前の連載も加えると実に58回も書いたことになる。

これで毎月原稿を書かなくてよくなるのは、 楽になるので嬉しい、と感じる一方で、 おこづかいが減るのは寂しい気がする。

ちゅーか、オープンソースで直接的に*1収入を得る手段のひとつだったのに。

この機会に論文に力を入れるべきか、それともどこか別の雑誌で書くべきか。 どこかの雑誌が声をかけてくれたら考えよう。

_ Linux Magazine 1月号

届く。3月号のことはなにも書いてない。当たり前か。

Pythonを紹介する連載が始まっている。その名も『サルでもわかる モンキーPython』。

うまい。

誰が書いているのかと思えば、堀川さんではないか。寝返ったな(笑)。

それはともかく、判官びいきのまつもととしては、 日本におけるPythonを応援します。

海外では圧倒的にRubyなんだけどなあ(マイナーなのが)。

_ [映画]サンダーバード

B00017YVCA

地元の映画館ではあっという間に終わってしまって見に行けなかった作品。 やっとDVD化されたので。

往年のファンをくすぐりつつ、現代の子供にアピールすることを狙った作品といえよう。

• マシンのデザインはかっこいい。というか、上手に現代風にアレンジしたなあ。 ただ、4号は小さすぎないか？
• 基地のガジェットも最高。各機の発進シーケンスがそのまんまなのが感動的。
• 飛べるロールスには爆笑。でも、笑えただけであんまり感心しなかった。 飛べる必然性はないし。 出てくるマシンの中で唯一気に入らないデザインと設定。 最悪なのはフロントグリルがロールス・ロイスではなく、ミニクーパーにしか見えないところ。
• ブレインズに息子がいたなんて。ていうか、家族が持てたのか、あの性格で。 ま、ありえないことはないか。私だって家族持ちだものな。
• オリジナルよりも前という時代設定は秀逸。 子供時代のアランの活躍という形でオリジナルを知らない若いターゲットの共感を呼びやすくしている。 ところでアランってレーサーの彼だよね。後の3号のパイロットの。
• ティンティン(オリジナル吹き替えではミンミン)にあんなパワーが。知らなかった。
• オリジナルより前だから父ちゃんは前線に参加してるのね。
• パーカーっ！ 最高。一番似てたぞ。人形に似てると言われても嬉しくないだろうけど、きっと。
• オリジナル(吹き替え)ではサンダーバードはマシンのコードネームで、 第三者からは一貫して「国際救助隊(International Rescue)」と呼ばれていたように記憶しているのだが。 映画では国際救助隊という呼称は一度も登場しなかったように思う。
• フッドはモーセ役のベン・キングスレー。役者だ。
• ストーリーの穴(特に考証)は追求してはいけない。これはサンダーバードなのだ。
• 兄ちゃんたちの登場がほんのわずかでキャラが立ってない。 結局最後まで区別つかなかったぞ。 トレーシー家でアラン以外にはっきり個体識別できたのはジェフ・トレーシー(父ちゃん)だけだった。
• 息子たちの名前はなんだっけ。スコット、バージル、ジョン、アラン、それからもう一人。 えーと、.....忘れた。
• Googleした。ゴードンだ。4号のパイロットだったか。ちなみに1号、スコット(26)、2号、バージル(24)、5号、ジョン(22)、4号、ゴードン(22)、3号、アラン(21)だそうだ。ジョンとゴードンは双子か？ 年齢には異説あり。

楽しい映画であった。サンダーバードを知らない人はどう思うのか。

_ [言語]Dynamic Java

動的言語について学ぶため、SunがPerl (Larry WallとDan Sugalski)、 Python (Guido van Rossum, Samuele Pedroni, Sean McGrath)、 Groovy (James Strachan)を呼んだというお話。

個人的な注目点。

• Guidoはヒゲを生やしているように見える。先日の話の影響か(そんなはずはない)。
• ダイナミックディスパッチ、バイトコードジェネレーション、クロージャ、コンティニュエーションなどなど動的言語をJVM上でサポートするのに欠けている要素について、SunのVPを交えて議論されたということは非常に喜ばしい。未来のJVMにはそれらの機能が追加されるかも。
• ある「R」で始まる名前の言語が徹底的に無視されているみたいなんですけど...。

ま、呼ばれても困るんだけどね。

_ [特許]MS対Eolas、ブラウザ特許訴訟控訴審で再び対決

Eolasの弁護士は正気なのだろうか。

Eolas Technologiesは、ブラウザがWebページに組み込まれたアプリケーションを認識して実行する機能に関して特許を保有しているが、この機能は Viola WWWブラウザを開発した“ペリー”・ペイ-ユアン・ウェイ氏が1993年にデモを行っており、これはEolasの特許が認められる5年以上も前のことだ−− 。コンスタンティン・トレラ弁護士はワシントンDCの米巡回連邦控訴裁で、裁判官を前にこう語った。

と、先行発明について指摘されると、こう反応する。

これに対してEolas側弁護士のマーティン・ルーク氏は、特許は有効だと反論。ウェイ氏のブラウザは後のバージョンでこの機能を捨ててしまい、自分のブラウザで組み込みアプリケーションを実行できる機能のデモは誰にも見せたことはなく、1993年5月のSun Microsystemsのエンジニアとの会合でも披露しなかったと主張した。ウェイ氏が行ったViolaのデモにはインターネットに接続されていないコンピュータが使われており、従ってSun関係者に対し、自分のブラウザでインターネットを介してアプリケーションが実行できる様子を示すことはできなかった、とルーク氏は述べている。

私の理解が正しければ、 特許は「後に捨ててしまった」かどうかは問題ではない。先に発明したかどうかが問題だ。 さらに言えば実装を誰かに見せる必要もない。そのアイディア(あるいはEolasの特許の新規性を失わせるに十分なアイディア)が、先に知られていれば十分無効にできる。

おそらくは「インターネットを介してアプリケーションを実行できる」ことが本質だ、 と主張したいのだろうが、だいぶ無理筋ではないかと。そもそもViolaはWWWブラウザなんだし、 たとえ、そのデモではインターネットを使わなかったとしても、 WWWブラウザであるViolaにプラグイン機能があれば「普通の技術者」は「インターネットを介してアプリケーションを実行できる」ことに気がつくだろう。

それで5億ドルぶんどろうっていうんだから、まったく。

追記:

CNETでも面白い主張が読める。発言者は「Robins, Kaplan, Miller & Ciresiのパートナーで、UCおよびEolasの代理人を務めるMartin Lueck」、つまり上記の「ルーク氏」と同一人物。

Weiが1993年5月に行ったデモは正当な先行技術とは見なされないと述べ、その理由として、このデモがインターネットに未接続のコンピュータ上で行われた点を挙げた。

上でも述べたが、あるデモがスタンドアロンコンピュータで実行されたからと言って、 それをインターネット上に展開することが、「普通の技術者」に思いつかない新規性のある発明であると言う主張には無理がある。ソケット通信は当時でも常識だったし、それについての知識が少しでもあれば、 ループバックデバイス上でローカル実行することとインターネットを介して実行することに本質的な違いはないことにすぐ気がつくはずだ。

さらにLueckは、「Weiのプロジェクトは、詳細が一切公開されず、立ち消えになった。コードの開発に大金をつぎ込みながら、それを利用することも公開することもしないのは権利放棄だ」と述べた。

確かに「権利放棄」であろう、特許的な見地からは。特許申請もしてないだろうし。 だから、Wei氏は5億ドルをマイクロソフトに要求できない。 が、Wei氏が権利を「放棄」したという事実は、Eolasが権利を主張できることを意味しない。

• Eolasの発明とWei氏の発明が同等のものであるとするならば、 Wei氏の発明とその「放棄」により、この発明は公知になり、他の人は権利宣言できない。 よってEolasの特許は先行発明の存在により無効。
• Eolasの発明になにかWei氏の発明にないなんらかの新規性があったとしても、 まったくのオリジナルではないことになり、発明価値は激減する。

これはたとえWei氏が権利を放棄していようと関係ない。

このルーク(Lueck)氏は正気なのだろうか。

1. 勝利を確信しているので、法廷外ではテキトーなことを発言している
2. 敗色が濃厚なので投げやりになっている
3. 上記の論理が正当だと信じ込んでいる(バカ？)
4. 本人はそんな意図はない。メディアの取り上げ方の問題
5. 本人はそんな意図はない。日本語訳で変になった
6. その他

さて、正解はどれだろう？

_ [Ruby]Facets of Ruby

Dave ThomasがPragmatic Bookshelfから出版するRubyシリーズの著者を募集している。[ruby-talk:123137]

英語圏でも256倍シリーズのような出版ラッシュが到来するのか。

Dave ThomasはPickaxe IIに続く2冊目としてRuby on Railsの本を書いているそうだ。

私自ら英語の本を書く根性はないが、応援したいものだ。

_ 山陰中央新報『特集 しまねIT新時代』

山陰中央新報は、島根県の地方紙だ。うちも取っている。今日は『特集 しまねIT新時代』なる折り込み別冊が入っていた。なんと、Rubyのことも載っている。田舎で開発されている「言語」はものめずらしいらしい。

通信環境生かし活動の輪

コンピュータ言語「Ruby」開発

...

世界に数千あるとされるプログラミング言語の中で、注目を浴びているのが「Ruby(ルビー)」と呼ばれる言語だ。

Rubyはソフトウェア開発などのネットワーク応用通信研究所(松江市学園南二丁目)に勤めるまつもとゆきひろさんが、十年前から開発してきた島根県発の言語といえる。

...

県は、Rubyを生かした産業振興を目指すため十月から、同社と、若者の就業を支援するふるさと島根定住財団ジョブカフェしまねに呼び掛け、県内でRubyを扱う技術者を育成する講習会をスタートさせた。

...

同社の井上浩社長は「Rubyを使おうと言う気運が盛り上がればうれしい」と、島根発の技術を島根の行政機関や企業で使う情報技術の「地産地消」に期待を込める。

さらに「Rubyを使える人が増えれば、県内で仕事や雇用が増え、県外から仕事も取れる」と、県の担当者もRubyを生かした産業振興の可能性に注目する。

「Rubyなら島根県といわれるようにしたい」。関係者が描く将来像だ。将来、多くの技術者を抱える島根にRubyの開発業務が集積する「Rubyの拠点」を目指す。

えーと、島根県は本気なんでしょうか。「情報技術の地産地消」って、いったいなんなんでしょうね。10年前には島根に住んでなかったとか、元々島根県の生まれじゃないとか、そういうことは置いておいて、 まつもとは島根県を応援します。

上記の将来像には、どこからか「取らぬ狸」という声が聞こえてきそうですが。

でも、ここまで目立つと下手に転職とか引っ越しとかできないなあ。島根県から出ていったら、裏切り者とか言われそう。

_ 体調

PCの画面が妙にまぶしい気がしたが、 だんだん頭が痛くなってきた。 どうも具合が悪い。

風邪を引いたか、あるいは睡眠不足か。

今日は寝て暮らすことにする。

_ 「白血球不一致の父から骨髄移植」

というニュースを新聞で読む。 ここで予告されていた手術が無事行われた、ということらしい。「患者の状態は良好」とのこと。

HLA不一致は大きな問題なので、それが克服できるということであれば、 白血病や再生不良性貧血の患者にとって朗報だ。

_ [教会]岡山

会議。訓練について提案する。教会(宗教団体)と訓練という単語はなじまないようだが、 実際には必要だと強く思う。方針として受け入れられるかどうかは未知数。 ま、管理する人には管理する人の考えがあるからな。

集会終了後、セミナリー卒業式。青少年の頑張っている姿は美しい。 鳥取支部の若い人たちが頼もしい。鳥取は全体の人数は少ないが、 若い人たちが多くて未来が期待できる。

今回は私が行き帰りとも運転。寝不足で少々辛かったが、 帰りはおしゃべりしながらだったので、眠気に襲われることはなかった。 同乗者に感謝。

_ [OSS]「IBMとの訴訟が決着するのは来年末」、米SCOのマクブライドCEO語る

まだやる気ですよ。来年末まで保つのかな。

個人的には途中で破産したりせずに、きちんと決着をつけてほしいと思ってるんだが。 どうせSCOの負けに終わるから。

下手に曖昧なまま残されて、「SCOの資産」が売却され、 他の会社の資産として計上されてしまうと、 その会社が傾いた時にきっと同じことが再発すると思う。 一連のSCO事件だって、結局は資金ショートしかかった企業が、 よそから受け継いだ資産を現金化しようとする行為にほかならない。

会社が傾きかけた時のなりふり構わぬ行為はあちこちに迷惑を及ぼす。 これは別にSCOだけに限らない。

この際、きちんと「SCOの資産」に価値がないことを明らかにしといてほしいものだ。 そのためなら来年末くらいまで待ってもかまわない。

_ 誤解

先日の日記に「体調が悪い」などと書いた。 日付は11日だが、実際に書いたのは14日の午前中であった。

たまたまこの日は都合があって出社が遅くなったのだが*1、 このエントリを読んだ同僚は、「ああ、まつもとは体調が悪いんだ。きっと休みなんだろう」と思ったという。実際は体調が悪いのは土曜の夜には回復してたんだけど。

すんません。これからはちゃんと遅れずに日記を付けます。

_ The Complete History of the Internet

えーと、ハッカーやらプログラミングやらの歴史。 なかなか興味深い。

[1994 Dec] The first alpha version of Ruby is released by Yukihiro "Matz" Matsumoto.

というエントリがあるのが嬉しい。

このリストにエントリされている言語は

• Flow-Matic programming language
• COBOL
• BASIC
• C
• Perl
• Python
• Java
• Ruby
• C#

後、名前だけ登場しているのが

• Pascal
• Scheme
• Tcl

FortranとかLispとかが全く登場しないってところが偏ってるっていうかなんというか。

_ [Ruby]TraitsとMix-in

数日前、「Traitsの良さとMix-inの良さのいいとこ取りができそう」などと書いたが、 世の中そんなに甘くなかった。クラスの関係が複雑になると、メソッドの衝突の解消など Mix-inでは嬉しくないケースがかなりある。

現実に、そんなに複雑なクラス構成にするのか、という点に疑問が残らないでもないが、 この辺をきちんと考察して、論文を一本書こうかと思う。ちょっと新規性がなさすぎるか。

が、バグ取りや子育てなど、ささいなことにじゃまされて、まとまって考える時間がなかなか取れない。 うーむ。

_ 『ウルトラマン』＠てれびくん

「てれびくん」という小学館の雑誌がある。

ま、子供向けテレビを解説する雑誌で、 私の子供のころにあった「テレビマガジン」や「テレビランド」と同類のものだ。 「テレビマガジン」はまだあるようだな、そういえば。

で、息子が買っていた「てれびくん 12月号」をぱらぱらと眺めてみると。

新連載 ウルトラマン・ネクサス
原作: 円谷プロダクション
漫画: 椎名 高志

うーむ、しばらく見かけなかったと思えば、こんなところに。 しかも、サンデーに書いてる時よりずいぶんシリアスなんですけど。 陰影のくっきりしたタッチとか。

_ 小さなP2P

発端は「TinyP2P」。 Pythonで書かれたわずか15行でのP2Pアプリケーションである。 もちろん実用的ではなく「基本はこんなに簡単」ということを示すためのもの。

これに対してMoleSterなる Perlによる9行の実装が登場。 こちらは、さらに以下のような制約を加えているところがすごい。

• 明らかなセキュリティホールはないこと
• なんらかの認証手段をもつこと
• TCP以上のプロトコル抽象化ライブラリを使わない(これは大きい)
• 言語処理系標準添付以外のライブラリを使わない

実装は以下のようになる。

$/=$_;$,=shift;$w=$a=shift;sub g{open(F,'<',$4)&&t($2,$a,"e$4",<F>);close
F}$k{+shift}=1;socket S,2,1,6;bind S,&a;sub e{open F,'>',$4;print F
$';close F}sub h{t($2,$_,id)for keys%k}sub i{$k{$2}=1}sub f{t($_,$2,$4)for
keys%k}sub a{$w=~/:/;pack'CxnC4x8',2,$',split'\.',$`}for(listen
S,5;$SIG{ALRM}=sub{};m!^(.*?) (.*?) ([e-i])([^/]*)/!s&&$,eq$1&&&$3){alarm
9;(accept(C,S),alarm 0)?read C,$_,1e6:($_="$, $a f".shift);close
C}sub t{socket X,2,1,6;$w=shift;$k{$w}=(connect X,&a)?print
X"$, $_[0] $_[1]/".pop:$/;close X}

目がつぶれそうだ。

Rubyも負けていない。以下はFlorian Grossによる実装([ruby-talk:123789])。

#!/usr/bin/ruby
# Server: ruby p2p.rb password server server-uri merge-servers
# Sample: ruby p2p.rb foobar server druby://localhost:1337 druby://foo.bar:1337
# Client: ruby p2p.rb password client server-uri download-pattern
# Sample: ruby p2p.rb foobar client druby://localhost:1337 *.rb
require'drb';F,D,P,M,U,*O=File,Dir,*ARGV;def s(p)F.basename p[/\w.*/]end;def c u
DRbObject.new((),u)end;def x(u);[P,u].hash;end;M["c"]?c(U).f(x(U)).map{|n|p=x(n)
c=c(n);(c.f(p,O[0],0).map{|f|s f}-D["*"]).map{|f|open(f,"w")<<c.f(p,f,1)}}:(DRb.
start_service U,Class.new{def p(z=O)O.push(*z).uniq!;O;end;new.methods.map{|m|m[
/_[_t]/]||private(m)};def f(c,a=[],t=2)c==x(U)&&(t==0?D[s(a)]:t==1?F.read(s(a)):
p(a))end;def y;(p(U)+p).map{|u|c(u).f(x(u),p(U))rescue()};self;end}.new.y;sleep)

コメントを除けば6行。密度でも負けていない。

ただし、dRubyを使っているから「TCP以上のプロトコル抽象化ライブラリを使わない」というMoleSterの制約は満たしていない。

_ [Ruby]るび…ま？

Rubyist Magazine 第4号、本日発行っ。

今月も充実してます。目次は以下の通り。

• 巻頭言
• Rubyist Hotlinks 第 4 回
• Ruby ではじめるプログラミング
• RubyOnRails を使ってみる
• Ruby Library Report 第 3 回
• lilyでブログカスタマイズ 第 2 回
• Win32OLE活用法 第 2 回
• build Ruby on Windows 第 1 回
• Ruby/Tk 講習会レポート
• RubyNews
• RubyEventCheck
• 編集後記

個人的に驚きだったのは子供のころ読んだ「ゼロの怪物ヌル」の作者がムツゴロウこと畑正憲であったこと。 全然覚えてなかったなあ。

_ japan.linux.comにて「JLC Diary」の正式運用開始

だそうだ。さっき(3:00pmごろ)、「プレスリリースを出します」と佐渡さんから電話があった。 直接電話をもらうってのも珍しい。

以下はプレスリリースの一部。

japan.linux.comにて「JLC Diary」の正式運用開始

-- 最前線のオープンソース関係者による生の声を伝え、業界のトレンドを発信 --

VA Linux Systems Japan株式会社(本社: 千代田区神田錦町3-11、 代表取締役社長：上田 哲也、以下 VAリナックス)のOSDN事業ユニット (OSDNジャパン)は本日、Linuxとオープンソース関連の総合ニュースサイトである 「japan.linux.com」(<URL:http://japan.linux.com/>)内の一コンテンツとして、 「JLC Diary」(<URL:http://japan.linux.com/diary/>)の正式運用を 開始したことを発表致します。

JLC Diaryは、Linuxとオープンソースソフトウェアに関わる開発者から ビジネスの現場で活動する関係者まで幅広く招聘し、ブログの感覚で コンテンツを執筆して頂くという試みです。運用開始の現時点は、 八田 真行氏(GNU Project、Debian Project、東京大学大学院)、 まつもと ゆきひろ氏(Ruby開発者、ネットワーク応用通信研究所)、 佐渡 秀治(VA Linux Systems Japan(株) OSDN事業ユニット長)の3名 で開始しますが、今後随時に執筆陣を増強する予定です。

というわけで、あっちにも時々は書きます。 従来の「Matzにっき」ともども「Matz日記(linux.com分室)」もよろしく。

しかし、どうやって使い分けようか。

_ 買い物

クリスマスの買い物に出かける。

街はクリスマスの気配、だがもうあちこちで片づけが始まっている。 クリスマスシーズンであっても、商売上はもう正月気分らしい。

クリスマスツリーが飾ってあっても、それは客引きのため。 クリスマスソングが流れていてもただ雰囲気作りのため。

主はどこにおられるか。静かな細い声はどこから聞こえるか。

_ [教会]出雲

訪問。10月の訪問は末の子が産まれる直前だったのでお休みさせてもらったが、 その結果、実に4ヶ月ぶりの訪問となる。なんだか浦島太郎。

出雲支部はなんだか人数が増えていて、部屋のレイアウトも変わっているし、 新しい顔もいくつか見かける。しばらく見なかった顔も戻ってきていた。 おまけに赤ん坊も生まれていた。 うちの子より1ヶ月早く産まれた男の子は、ふたまわりくらい大きかった。

集会を抜けて、悩みがあるという人の話を聞きに行く。 問題を解決してあげられるわけではないが、 話を聞いてあげることくらいはできるだろうと思って。

まわりの人の認識とその方の認識がずいぶん食い違っていることに気づく。 どちらが正しいとか間違っているとかではなく、 結局、人間は自分の認識の世界に生きているのだということも感じる。

いずれにせよ、否定しないように、一方的な見方を押しつけないように気をつける。 普段からこれができれば、喜ぶ人も多かろうに。いや、貴重な実践の機会で、 学ぶことが多かった。

最後に神権の祝福を残して帰る。このささやかな時間が有意義なものとなればよいのだが。

夕方は米子でクリスマスディボーショナル(のビデオ)を見る会に参加する。 途中、子供の宿題の面倒を見たりして聞けなかった話もあったが、 それでも私にとって有意義だった。 昨日、クリスマスツリーやクリスマスソングからは感じることができなかった クリスマスの本質(イエス・キリスト)について思いをはせることができたから。

_ IPAヒアリング

今日はIPAの方から人が来て、昨年度の「オープンソフトウェア活用基盤整備事業」*1についてヒアリング。

IPAは今年から独立行政法人になったので、今まで以上に投資が有効活用されているかチェックする必要があるので、改善点があるか、無駄はないかなどをチェックする調査を行うことになったのだそうだ。わざわざ松江までいらっしゃるというのは本気である。

で、つらつらと普段から考えていることなどをお話しした。 IPAの事業はオープンソースソフトウェアのスタートアップを直接支援する数少ない事業なので、 ぜひ継続していただきたいと考えている。 「スタートアップを支援するだけでよいのか」という声があることは承知しているが、 企業系オープンソースソフトウェアで一番の難関は始めるためのリソースの配分であるのは事実なので、 それを支援することは有意義であると考える。「継続を支援する必要があるか」については、 別のところで今後書くことにしよう。

また、IPAは私の知っている「お役所系」の中ではもっとも対応が良い。 毎回いろんなチャレンジを行い、毎年改善されている。 現在残っている不満といえば、2点だけ。

• 応募時にどのくらいの規模のプロジェクトになるのかを人月ベースで見積もる必要があるのだが、 詳細な見積もりを行うためにはあらかじめ相当突っ込んだ設計を行う必要がある。 しかし、採択されるか分からないものをそんなにコストをかけて設計・見積もりするのは難しい。 これが普通のビジネスなら顧客が「そのプロジェクトの成果でどれだけの価値を創造するか」という点からキャップをかけるのだが、ほとんどの場合IPAは成果物のfirst userではない。
• 事業開始時に「実施計画メモ」というのを作成するのだが、 これが開発内容の詳細を記述したものであるので、 プロジェクト開始時に開発成果物のほぼ完全な具体像が必要。 Exploratory Developmentは難しい。

まあ、国民の税金を無駄づかいさせるわけにはいかんので、 正しく使われたことを担保することが必要なのは分かるし、 そのために我々がきちんとレポートするのはやぶさかではないのだが、 開発に制約が付くのはあまり嬉しくない。

アイディアとしては、「300万コース」、「1000万コース」、「3000万コース」など複数のコースを設け、 「社会に対するプロジェクトの価値」を外部の有識者(PM)に評価してもらう。 応募の中から「プロジェクト(or アイディア)が応募したコースに見合う社会的価値があるかどうか」を判断基準にする、 というはどうだろう。

あまり欲を出して高いコースに申し込んじゃうとアイディアは良くても落ちちゃう。 あるいは「もうちょっと金額の低いコースに申し込みませんか」とか勧めるとか。 もちろん、最終的に無駄づかいしてないかのチェックはきっちりやるとして。

ああ、でも単年度主義が障害になるかもしれないな。 「あなた3000万コースだったけど、使わなかったから実際には1500万ね」とかやっちゃったら、 予算が余っちゃうものな。来年に回すというわけにはいかないのが日本の行政のようだから。

参考:

「経産省の2005年度オープンソース関連予算は2004年度の1.5倍」 − NikkepBP ITpro

追記

あ、今思い出した。私の立場から、オープンソースを支援することが意味があるのは確かなんだけど、 それだけじゃなくて、 支援の成果物をオープンソースにすることで、成果物が埋もれてしまう(＝支援が無駄になってしまう)ことを避けることができるのは、税金の無駄づかいを避けるという立場からも有意義だと思う、というような話もした。

_ 豆蔵

朝から東京に移動。豆蔵を訪問。

しかし、豆蔵って上場もしているし、わりと有名だと思っていたのだが、私のまわりの同僚たちは誰も知らなかった。 「豆蔵？ コーヒーの会社ですか」とかめちゃめちゃなことを言ってる。 きみたち、それはあんまりじゃないかと。確かに変わった名前だけど。

私にとっては有名人がたくさんいたり、 過去の(オブジェクト指向繋がりの)知り合いが次々と転職したりして 縁浅からぬ印象がある。実際、今日も以前の同僚から来た話だし。

昼食は新宿住友ビル51階の「地鶏や」。 味もサービスもまあまあだが、お昼時だというのに分煙されていないのは大減点。 たぶんもう利用しない。

午後は豆蔵のスタッフと顧客を交えての情報および意見の交換。 非常に興味深い話を聞いた。

杭州富士制冷機器有限公司は、 富士電機の中国子会社で自販機の製造を行っている。 富士電機は日本最大の(ということは世界最大の)自販機メーカーであるそうだ(富士電機にはもうひとつ世界一があると聞いたのだが、忘れてしまった)。

さて、自販機に内蔵されているソフトウェアの開発は、 コンピュータの能力に制約があることもあり、 再利用度も低くあまり効率が良くなかった。 そこで杭州富士制冷機器有限公司では、 Rubyを用いたプラットフォームを用いて、まずプロトタイプを作成し、 それを組込用Cに(人間が)変換することで生産性を高めるアプローチを取った。

私が驚いた点は以下の通り。

• 継承とアスペクト指向を利用したプラットフォームでソフトウェア部品の再利用度を向上
• 型による情報がない部分はApolloを用いた一種のブラウザでカバー
• プロトタイプをドキュメントとすることで属人性が排除され、 多数のプログラマで分業できるようになったため、開発期間が3分の2になった。
• しかも、中国人プログラマを(言語の壁にあまりじゃまされずに)活用できるため、 ソフトウェアの開発コストは従来の2分の1に。
• このプラットフォームの基本部分は、 杭州富士制冷機器有限公司の社長(総経理)が自ら開発した。

えーと、削減したコストを考えると、これは驚くべき適用例ではないかと。

_ 年賀状

ようやっと年賀状に手をつけた。例年、実は業者に依頼して写真年賀状を作っていたのだが、 今年はプリンタを購入したこともあり、 自分で印刷することにしようかと。

が、年賀状を作るなんてやったことがない。どうやったもんだか。

まず、KreetingKardを試す。 なかなか快適な使い心地。郵便番号から住所を埋めてくれるのもラクチン。 しかし、

• 連名(奥さんの名前とか)に対応していない
• 住所が長くなるとはみ出し部分を折り返してくれない

ので、宛て名印刷には使えない。しょうがないので裏はKreetingKardを使うものの、 宛て名は断念。その辺の冊子についている年賀状ソフトを使おうか。 なんか負けた気がする*1。

なお、私に年賀状を送る人は、今年引っ越しましたから、 従来の住所の番地の部分を「361」に変更して送ってください。 転送願いを出してあるので、旧住所でも届くと思いますが。

_ [会社]忘年会

会社の忘年会。中華料理。

しかし、あの苦しそうな酒の飲み方はなんとかならないものか。 ぜんぜんおいしそうじゃない。 あれではなんのために飲むのか全然分からない。 何人もツブれてたし。

生涯を通じて一度も酔ったことがない私には理解できないなにかがあるのだろうか。 自分の精神を麻痺させる化学物質を、 自分の体が拒否する分量を越えて積極的に体内に取り込む行為を正当化するなにかが。

自分が宇宙人であるかのように感じた。

新婚の後輩から、夫婦関係を長続きさせるにはどうしたらよいですか、などと わりと根源的な質問をされる。 答えに窮しているうちに、上司(前社長)がとうとうと話し出したので、 私からはたいしたことが伝えられなかった。 「夫婦の関係は後天的だからメンテが必要なんだよ」くらいか。

しかし、帰宅してから風呂に入って考えると、 「誠実であること」がキーワードのような気がしてきた。 また、「自分たちが決めたルールを守ること」が有効かもしれない。 クリスチャンである私たちは戒律があるので、ルールが多いのだが、それでなくても、たとえば

• 食事はできる限り家族全員で一緒にとる
• 食事中にはテレビを見ない
• 月曜の夜は家族全員が集まり活動をする

など家族の決め事を守る誠実さが家族関係を良好なまま維持できるかも。 制約がある方が自由であることのひとつの例かもしれない。

_ [教会]クリスマス会

天皇誕生日はジョセフ・スミスの誕生日でもある。

今日は教会のクリスマス会。 今年はコーラス、 スライドやビデオなど少々大人向きの感じであった。 私は「クリスマスの雰囲気」を堪能できた。 米子の会員がお手伝いに来てくれていた。

次女は友達を連れてきていたのだが、「ちょっと眠かった」だそうだ。 上映中は暗かったしね。

キャロリングに参加した長女以外は 帰りにBaskin & Robinsによってアイスクリームをいただく。 そういえば日本にSteve'sはないのだろうか。

_ 『今年もキミは来ないのね−聖夜にかけるIT戦士かく闘えり』

今年もやってくれるなあ。三人称で書いてあっても記事末尾の署名が本人だというのが痛々しい。 こんな名物記者に育つとは事前に誰が予測しえただろう。 未来を予想するのは難しい。

_ 年賀状

やっと購入。100枚も買ってしまった。これを片づけられるのか。

うっかり入力しかけのKreedingKardの住所録をふきとばしてしまうし(~/.kdeを消去してしまった)。 やっぱ、「筆まめ」のお世話になるしかないのか。 「不自由なソフトウェア」は避けて暮らしていたのだが。

_ クリスマスの朝

子供たちは枕元にプレゼントがあったらしい。 ただ、全員が望み通りではなかったようだ。サンタも失敗するらしい。

その上、私の枕元にもプレゼントがっ。 サンタさん、今年は良い子にしてたのを見てくれてたんだねっ。 来年もがんばるよ、ぼくっ。

_ クリスマス・リリース

今年はクリスマス・リリースが流行らしい。

後輩たちが開発しているソフトイーサがリリースされたかと思うと、Sylpheedも1.0がリリースされている。噂によるとmplayerもリリースされたらしい。

しかし、クリスマス・リリースならRubyに一日の長がある。 過去をふりかえると

• ruby-1.0-971225 (1997-12-25)
• ruby-1.1b3 (1997-12-25)
• ruby-1.2 (1998-12-25)
• ruby-1.3 (1998-12-24)
• ruby-1.4.3 (1999-12-08)
• ruby-1.6.2 (2000-12-25)
• ruby-1.6.6 (2001-12-26)
• ruby-1.6.8 (2002-12-24)
• ruby-1.8.1 (2003-12-25)

と、1997年以降ほぼ毎年(1999年だけちょっとずれているが)リリースしている。

ちなみにもう一つのピークはお盆で、 8月リリースは、1.4.0(1999年)、1.4.6(2000年)、1.8.0(2003年)がある。

しかし、今年は(今年も？)リリースミスがあり、 最後のコミットしないでパッケージを作ってしまった。 夕方になって気付いて、あわてて再リリースするはめになってしまった。 サンタも失敗するらしい。

ダウンロードはこちらから。 MD5SUMは

8ffc79d96f336b80f2690a17601dea9b

Happy Hacking!

_ 『「メリークリスマス」は時代遅れ　宗教からみ米で議論』

うーむ、Happy Holidaysという表現をよく見かけるようになったな、と思ったらこういうことなのね。 しかし、PC運動は「気を使う」以上になってきて、ほとんど言葉狩りのレベルに近くなってるような。

_ [教会]松江

もうクリスマスも終わってしまったし、 ごく普通の集会。帰省する人もいるせいかいつもより少々人数が少ないかも。

クリスマスパーティーのポップコーンが大量に残っていたのだが、 子供たちを中心に群がるように食べていた。悪いけど、ピラニアとかハイエナとかを連想してしまった。 食い物には弱いらしい。

_ 年賀状

印刷した。結局「不自由なソフトウェア」のお世話になってしまった。 負けた気分でいっぱいだ。

表裏を間違えたり、インク切れで色が変になったり、 なぜが画像がずれたりで、6枚も失敗してしまった。余分に買っといてよかった。 失敗したのは(くじ番号をチェックしてから)郵便局で交換してもらおう。

ついでに娘の年賀状も作ってやる。 コンピュータ三昧の生活をしているくせに、 こういう一般の人がよくやるような使い方に滅法弱いのは、家人には理解できないらしい。

_ [聖書]イエス・キリストの誕生日

クリスマスはイエス・キリストの誕生を記念するキリスト教の祭だが、 イエス・キリストが12月25日に生まれたとする証拠は聖書には見当たらない。 これは「死と復活」をイメージさせるヨーロッパ土着の当時のお祭りが起源となって、 発生したものらしい。

では、キリストの誕生日について推測できるものはないのか。

聖書の記述に誕生日について季節が推測できる記述は少ない。 数少ない例は以下のようなものである。

ここから分かることは、この日はエルサレム近郊で羊飼いが野宿できる季節であった、 ということである。ということは少なくとも冬真っ盛りの12月ではありえない。

『マタイによる福音書』にも生誕についての情報が記されている(2章) こちらには「東からきた博士たち」(Magi)についての記述がある。 しばしば三博士と呼ばれ、 「メルキオール」、「カスパール」、「バルサザール」とそれぞれの名前まで知られているが、 これらは単なる「言い伝え」で、意外なことに聖書には人数さえ明記されていない。

しかし、直後にヘロデ王が

ところを見ると、博士たちの到着は誕生当日どころか、何ヶ月も、あるいは何年も後であることが推測され、 誕生日を推定するための材料にはならない。

結局、聖書からの情報だけでは、イエス・キリストの誕生日は「真冬ではありえない」という以上のことは分からないわけだ。 私たちの教会には「イエス・キリストの誕生日は4月6日」という言い伝えがあるが、 これにも確証があるあけではない。

では、誕生年はいつか、という別の疑問もあるわけだが、これはこれで別の機会に述べることにしよう。

_ [言語]The Aikido Scripting Language System

Sunからリリースされているスクリプト言語。「合気道」とはまた変わった名前だこと。

特徴は

• Block structure. A Pascal and Ada like block nesting structure
• Object orientation. Classes, Interfaces and packages, with single inheritance and operator overloading
• Multithreading. Threads can be created as easily as making a function call. Monitors are provided for synchronization
• Block extension. The ability to extend any "block" (function, class etc)
• Streams. These are builtin channels connected to devices (screen, disk, network etc)
• Garbage collection. This is done using reference counting
• High level data structures. Strings, vectors, maps, etc.

ということらしい。ざっと見た感じではGroovyとの差別化はできてないように思う。 が、スレッドやストリームの扱いとかは面白そう。

_ [言語]The Spry Computer Language

Prototype版PythonことProthonの作者、Mark Hahnが開発した.NET用動的プログラミング言語。 同じ.NET上のPython系言語でも、Pythonに静的型を付けたBooとは逆に、より動的な側面を強調した言語。

しかし、...。

(続きは後述)

_ [言語]企業システムにおけるPHP5の可能性

Javaと比較してPHPを紹介する記事。 しかし、しつこいくらい繰り返しているが「PHPの良さ」はどこにあるのだろうか。

この記事ではこんなことを書いている。

PHP5はJavaと比較して、パフォーマンスの面では圧倒的に遅れをとりました。オブジェクト指向機能についてもPHP5は今ひとつJavaにはおよびません。しかし、PHP最大の利点はパフォーマンスやオブジェクト指向機能ではなく開発生産性の高さです。まずは下記をご覧ください。

本連載で掲載したソースコードの行数

	PHP5	Java
5000までの素数をWebブラウザーに表示する	28行	34行
5000までの素数を画面に表示する（バッチ）	28行	32行
データベースへの接続を繰り返す	88行	122行
Singletonパターン	57行	58行
例外処理	122行	97行
合計	323行	343行

上記は本連載で掲載したソースコードについて行数をまとめたものです。いずれも小さなプログラムですが、例外処理を除いてPHP5の方が少ない行数となっています。

こんな短いプログラムで比較するのもどうかと思うのだが、 Rubyで書いたら絶対これより短くなる。 ということは、PHPではなくRubyを使えという話なのか。どうも、そうではなさそうだ。

よくいただく反論は「PHPでもできる」ということであって、 同じくらい良い(動的)言語からPHPを選ぶ理由ではないはずだ。

PHPは決して速くないし、記述力が高いわけでもないし、たくさんの欠点が残っているように見えるが、 あちこちで「そのシステムPHPで書かないの」という質問が出る*1ところをみるとそれなりに使われているようだ。

もっとも、PHP陣営から出てくる数字はmod_phpのインストール数とか、mod_phpのパフォーマンスと(mod_perl抜きの)perl CGIとの比較とか、あんまりフェアでない印象があるが。

あるいは「すでにPHPを覚えているので、いまさら他の言語を覚えたくない」ということなのかもしれない。 その気持ちは理解できる。 もしかすると、よく分からない初心者をイメージ先行で取り込んでしまい、 「いまさら他の言語を覚えたくない」という」意識でロックインしてしまうというのは、 初心者をターゲットにした素晴らしいマーケティング戦略なのかもしれない。

もしそうだとするならば*2、Rubyは絶対にその戦略を取りたくない。 それくらいだったらマイナーなままでいてくれた方がずっと良い。

_ [会社]仕事納め

今日で仕事納め。毎年恒例の机の片付け。 机の上に積み上がった書類や論文のうち、要らないものは廃棄、 将来読みそうなものは本棚に戻す。

年に一度、机の表面が見える日である。

_ 片付け・来客

大変散らかっている自宅を片付ける。ついでに廊下をぞうきんがけ。

夕方から来客。早めの夕食を一緒にいただく。 楽しい時間を過ごした。

_ [言語]A crisis of faith

先日の続き。

Prototype版PythonことProthonの作者、Mark Hahnが、その後、.NET上の動的言語の開発を始めたが、

• C#がスクリプティングにも十分に使いやすい
• それは豊富なライブラリのおかげである
• Visual Studioはすばらしい
• 静的言語はタイプ量は多いがツールでカバーできる

というようなことから、動的言語への「信仰」を失ってしまった、とかいう話。

もっとも、動的言語の利点は

• Duck Typingによる柔軟性
• 生のコードがコンパクトなため読みやすい

ことにあり、これらはツールによってカバーされるものではないと思うが。

_ 年賀状

早くから印刷していたのに、結局今日まで投函しなかった。 やはり手書きのメッセージを書き加えたいという妻のリクエストと、 住所の確認などに手間取ったからだ。結局住所の間違いがひとつ、 名前の感じ漢字が違っていたものがひとつあった。

_ [言語]同じスクリプト言語

たかはしさんの「ただ、風のために。6」より。

こう言うとまつもとさんは納得しなさそうですが、 PHPにしろRubyにしろ、2万フィート上空から俯瞰すれば同じスクリプト言語、あるいはLightweight Language(LL)で、そんなに変わらないんじゃないかと思うわけですよ（やっぱり納得しなさそう……）。

いや、十分納得しますよ。私が言語を比較してどうこう言っても、外部からみれば「コップの中の嵐」であることは最初から自覚しています。 これはyooseeさんのツッコミに対しても同じことが言えます。

ドキュメント・ユーザ・利用例が多い、とにかくとっつきやすい(HTML に数行足せばWeb上で動くものが作れる)、始めに覚えることが少ない(基本がオブジェクト指向ではない事も多分大きい)、と言うあたりで初めてWebシステムを作る人が最初に使い始めて、その後乗り換えるほどのモチベーションを他の言語から受けない、と言うあたりだと思うので、純粋に言語の優劣を語っても個人的にはあまり意味がない気がします。

とはいえ、そういう大局的な立場から公正な見地の意見を述べてもあんまりおもしろくないわけです。むしろ、他人から見たらめちゃめちゃ些細な「意味がない」ことを真剣に論じるというのが、この「Matzにっき」のスタイルではないだろうか、と自覚しているわけです。

また、そういう「些細な違いが大きな違いを生む」というのは、Rubyのデザインポリシーでもあります。 「些細な違いは重要ではない」とか「意味がない」とかで、切り捨ててしまうのは、 他の人にお任せして、私はこのやり方を突き進んでいくのがよいのではないかなあ、と。

_ 散髪

息子と二人で床屋に。しっかり短くしてもらった。サイドが短すぎて「のびた」くんみたいになったような気がする。

_ 10大ニュース

2004年もいろいろありました。まつもと家の10大ニュースといえば、

1. 三女誕生
2. 引っ越し
3. ゆきひろ屋根を踏み抜く
4. 新居で雨漏り
5. 息子小学校入学
6. 両親が浜松へ
7. 弟の帰還
8. 一族全員大集合(合計19.5名)
9. 1.8.2リリース
10. 家庭菜園で大収穫

みなさんのところではいかがでしたでしょう。 2005年はどんな年になるでしょうか。