Matzにっき

_ [Ruby] 『ルビま！』休刊のお知らせ

月刊『ルビま！』は、今月号(2005年4月号)をもって休刊いたします。これまで応援していただいた読者の皆様には深く感謝しております。 大変ありがとうございました。

『ルビま！』200504号（休刊号）
http://jp.rubyist.net/RubiMa/

休刊号の予約購入特典は、まつもとさんの仮契約カードです。

　　　　　　　　　　　　　『ルビま！』編集部　編集長 高橋征義

_ [Ruby] emerald 0.1

Date: Fri, 1 Apr 2005 17:44:51 +0900
Posted: Fri, 01 Apr 2005 08:44:02 GMT
From: Yukihiro Matsumoto <matz@ruby-lang.org>
Message-Id: <mR73e.39335$zZ1.1166538@twister1.libero.it>

Hello,

I'm pleased to announce you the first public release of emerald at

    http://rubyurl.com/b5JtE

Emerald is an object oriented language with constraints and logic 
features, inspired from prolog, Oz, CSP and Hyper/J.

I started this as an hack since ruby is becoming less fun.
It will not be as good as ruby, but please try it out while we wait for 
Rite.

							matz

_ エイプリルフール種明かし

• 『ルビま！』休刊のお知らせ

  「Rubyist Magazine休刊のお知らせ」と読んだ人も多かったようだ。 「いろいろ頑張ってきたがエイプリルフール特集でおしまいなのね。ついに燃えつきたか」 と思われたのだろうか。

  実際は休刊するのは『ルビま！』と呼ばれるエイプリルフール専門のWeb雑誌であり、 『Rubyist Magazine』はなにごともなかったように今後も発行を続けることとなる。 発行協力者も引き続き募集している。

  来年の今ごろには『ルビま！』も復刊するかも。 「勘弁してくれ」との関係者の声も聞こえるような気が。

• emerald 0.1

  もちろんそんな言語を作っていないが、それはリンク先を見ればすぐに分かることだろう。ここで重要なのはこのメールは私が書いたものではない点だ。これはメッセージIDを見ないと気がつかない。あるいはシグネチャの「matz」の後ろにピリオドがないところか。fmlがタイムゾーンをJSTにしてくれるせいでかえって信憑性が上がった気がする。なかなか秀逸。

  以前にも私の名を騙ったアナウンスがあったような気がするけど、見つけられなかった。

_ [言語] Stricter Whitespace Enforcement

現行のPythonでは空白の使い方に自由度がありすぎる、TOOWTDI (There's Only One Way To Do It) 原則から言えば望ましくない。よって、

• インデントは厳密に空白4つ。タブ問題もこれで解決。
• 冗長な括弧は禁止(例: return (1) は駄目、return 1が有効だから)。
• 左括弧直後および右括弧直前の空白は禁止。
• 引数括弧およびインデックス参照のブラケット直前の空白は禁止。
• コンマやセミコロンの前の空白は禁止。
• コンマやセミコロンには厳密に一つだけの空白(行末を除く)。
• 行末のセミコロンは禁止(冗長だから)
• 式の中で二つ以上の連続する空白は禁止。
• 代入および比較演算子の前後には必ず空白が必要。
• 演算子の左右の空白の量は等しくなければならない。
• 式の中の空白の数に変化がある場合には演算子の優先順位を反映していなければならない。 つまり、"1*2 + 3*4" は大丈夫だが、 "1*2 + 3 * 4" は駄目。 しかし、推奨されるのは"1*2+3*4" である。
• コロンの前の空白は禁止。
• ディクショナリリテラルではコロンの直後に厳密に一つだけの空白。 スライスのコロンの直後の空白は禁止。
• ブロックの短縮形式 ("if x: y") は廃止。改行とインデントを使うこと。

というルールを導入する。Pythonの互換性のルールに従い、Python 2.5ではオプショナル、 2.6からは必須となる。Python 2.5でこのルールを使うためにはプログラム先頭で

from __future__ import whitespace

と宣言する。

また、Python 3.0からは縦方向の空白ルールも導入される。

• 関数定義またはメソッド定義の間には最低1行の空行。
• クラス定義間には最低2行の空白。

Python 2.4でこの宣言を実現するパッチもすでに提供されている。

すばらしい。よりPython的ではないか*1。

_ [OSS] オープンソースで育て！　日本のソフト開発力

オープンソースという，誰でも「ものづくり」に参加できる場が，技術力を培うかけがえのない場となっていると感じている。

という結論。我々関係者にとっては当然だと思えるが、 それが伝わっていないほど「一般社会」とオープンソース界の間の解離が大きいということでもある。 広報重要というか。

_ マツダがリコール　ＭＰＶ・プレマシーなど６万台

年式から言うとうちの車も該当しそうな気がするな。

車のリコールって結構多いよね。プレマシーは確か二度目だし、 もう一台(三菱)も一昨年リコールがあった。

_ [言語] Javaのメモリ消費問題の解決を目指すSunのプロジェクト「MVM」

メモリ管理に関心があるものとしては興味のある話題。 でも、記事を読んでも肝心のMVMという技術の詳細がピンとこない。

_ [原稿] UNIX USER 6月号

もう6月の話か、という気もするが。ゴールデンウィーク進行なのでますます早い。

今回は「ハッカーと仕事」。ハッカーが自分の好きなことと生活のための仕事をどう折り合いをつけるかというような話。なんか、以前にも「Ruby開発日記」で似たようなことを書いたような気がする。

「Ruby開発日記」の後を引き継いだ形の『ハッカーズライフ』は与太話が多いが、 UUの編集からは「もうしばらくしたらもっと技術的な話を書きませんか」というオファーをいただいている。 仕事の話は来るのはありがたいが、実際読者はどんな話を望んでいるんだろうか。

1. 今のまま与太話を
2. 方向性は今のまま、増量
3. 方向性は今のまま、減量
4. プログラミングの話を(日経Linuxの連載とかぶるかも)
5. Rubyの話を

ご意見歓迎。

_ 散髪

息子と二人で散髪へ。ふたりとも久しぶりなので伸び放題。 ついでに私はヒゲも剃ることにする。 ま、私がヒゲを剃ってもRubyの行く末には影響ないだろう。

_ [教会] 松江

なんだか久しぶりの松江。ステーク大会があったりしたので実に1ヶ月ぶりか。

断食証会は(珍しく？)行列ができて、時間制限が必要になったりした。

自宅に帰ってからは息子を面接したり、昼寝したり、いろいろ。

夜、ボイラーの灯油が切れたので倉庫までポリタンクを取りに行ったら、 けっつまずいて捻挫してしまった。痛い。

_ [教会] セミナリー

今日から教会の早朝講座の教師を仰せつかってしまった。 今年は「新約聖書」。これまでずっと夜型の生活だったから、5時半起きはつらいなあ。 青少年と一緒に勉強できるのは、私のためにもなるけどね。

しかし、11月まで体がもつかなあ。生活リズムの確立が重要かも。

_ Progenyの改革：FOSS企業がいかにしてドットコム崩壊を生き延びたか

アメリカでは「ドットコムバブル」が大きくて、その崩壊による被害も甚大だった、というお話。

日本とはちょっと違うところもあるが、Ian Murdockが経験から学んだという以下の点は参考になる。

• まず、Progeny社が資金援助の申し出を辞退したことを顧みて、Murdock氏は、「資金援助を断らないこと」とアドバイスする。ベンチャーキャピタルがIT企業全般、特にFOSS企業への投資を今も警戒していることに言及した上で、「今はもうそんなに多くを語る必要はないでしょう」と話した。
• 第2に、Murdock氏は自分たちでことを成そうとしている起業家に警告する。Murdock氏は、起業するタイプのA型人間は、ビジネスに実践的に参加することに慣れているだろうが、こうした姿勢は会社を育てる上で現実的ではないという。それより、「自分が得意なこと、好きなこと、ほかの人にできないことを見つけてください。そして、自分を補ってくれる優れた人材を集めてください」という。
• 最も重要なことに、Murdock氏は、「たっぷり時間をかけてきちんとした事業計画をたててください」という。今日の保守的な景気状況下で資金調達が必要な企業にとって、しっかりした事業計画が必要不可欠な基本事項であることは当然ある。だが、Murdock氏にとっては、事業計画はふだん会社を経営する上での指針でもある。事業計画とは「すべてを飲み込み、不備と着想を探り、採用する人材に会社の考えを伝え、なぜこれをやってこれをやらないのかの理論的根拠を示すためのものです。これはいくら強調してもし過ぎることがないほどです」という。

私(たち)には「資金調達」については別の考えがあるが、その他の点については同意する。 また、「欲しい人材」をあらかじめ具体的にイメージしておく必要があるなあとも感じた。

_ 捻挫に...

昨日の捻挫はまだ痛い。びっこをひいて歩いているのが自分でも痛々しい。 が、肩こり用に買っておいたバンテリンが思いのほか効果があった。 だいぶ痛みが少なくなった。

捻挫にもインドメタシン。

_ 論文

後輩がLC向けの論文を書くとのこと。今日の真夜中(JST)が〆切だそうだ。 で、ぎりぎりになって突貫工事。アブストラクト書きなどを手伝う。

というか、今日になって方針変更というのはいかがなものかと思わないでもないのだが。

_ [Ruby] A Poll

少々古い話だが。

ruby-talkメーリングリスト、 および相互乗り入れしているcomp.lang.rubyニュースグループの読者を対象にしたアンケート。

Two questions:

1.  Do you use Ruby in your "day job"?
    a.)  Yes! Lots!
    b.)  Some.
    c.)  I little bit when I can get away with it.
    d.) I wish!

2.  What are your one or two principal programming
    languages other than Ruby?

[ruby-talk:135549]に集計の結果が発表されている。

Thanks to everyone who responded!  The results:

Answers to Q1 ("Do you use Ruby in your 'day job'?"):
a ("Yes, Lots!"):  21 (30%)
b ("Some."): 16 (23%)
c ("I little bit when I can get away with it."): 23 (33%)
d ("I wish!"): 8 (11%)

The "d" tally includes one from a lua user who is happy not to use
ruby.  I apologize for the biased wording.

As mentioned elsewhere, the showing for "a" is encouraging!  If any of
you "a" people have openings in Dallas, please email me! :)

Answers to Q2 ("What are your one or two principal programming
languages other than Ruby?"):

java:  23 (15%)
c:  19 (12%)
cpp:  15 (10%)
perl:  14 (9%)
php:  13 (8%)
python:  7 (4%)
bash:  7 (4%)
plsql:  5 (3%)
vb:  4 (2%)
csharp:  4 (2%)
sh, sql, and objc each got 3 mentions.

javascript, asp, matlab, delphi, rebol, tcl, lua, and lisp
each got 2 mentions.
ksh, eiffel, forth, miva, sas, asm, ada, haskell, puredata,
fortran, tex, cobol, and vba each got 1 mention.

この簡易な調査にどれくらい意味があるかは別として、 実に３０％もの人が「Yest, Lots! (多いに仕事に使っている)」と回答したところは興味深い。 「Some (ある程度)」と合わせると過半数を越える。

_ [言語] Trails

また本家スラッシュドットでRailsに関するストーリーがポストされていて、いろいろな意見が戦わされていた。 新しいテクノロジーが受け入れられていくためにはこのような「論戦」がつきものなのだろうか。 Rubyはあんまりそういうのやりたくないなあ、と思っていたら、Railsが露払いをしてくれそうだ。 ありがたいことだ。

ま、それはそれとして一連のやりとりで取り上げられたもののうちで、 もっとも興味を引いたのがTrailsであった。

Trails is a domain driven development framework in the spirit of Ruby on Rails or Naked Objects.

The trails project aims to make java enterprise application development radically simpler by allowing developers to focus on the domain model and having other portions dynamically generated. We will leverage existing technologies such as Spring, Tapestry, and Hibernate rather than reinventing.

これまでRuby陣営はさんざんJavaで登場してきた技術を参考にさせてもらった上で、 「動的言語なら同じ技術でももっと生産性が高い」というような話をしてきたのだが、 Ruby陣営が生んだRailsの技術(主にDRYとConvention over Configuration)が Java陣営に取り込まれることが起きたのかと思うと感慨深い。

_ [OSS] サンのJ・シュワルツ、オープンソースライセンスのGPLを批判

これで「オープンソースの守護者を自任自認する」んだからねえ。

GPLソフトウェアのソースコードを非GPLソフトウェアに流用したいという要求は分からないでもない。 が、作者がしてほしくないと思って禁止していることは、そもそもできないわけで、 「だからGPLは」というのはそもそも間違っている。

また、GPLの「どちらかというと略奪的な義務」がなければ、 フリーソフトウェア開発者が 「生み出した知的財産をすべてはき出して、世界で最も豊かな国、 つまり」世界最大のソフトウェア産業を抱える地である「米国に戻さなくてはならない」ということになることに気付いてないとは思えない。

なんで、そんなにGPLを目の敵にするのか。 それには「フリーソフトウェアの成果を自分のプロプライエタリソフトウェアに組み込みたいから」 という欲望や「フリー(無料)なんだからいいじゃん」とかいう態度が透けてみえるような気がする。

_ [Ruby] Objectクラスの上

RubyのObjectクラスはかなりリッチなクラスだ。たくさんのメソッドを提供している。 実際にはすべてのクラスに共通するメソッドはKernelモジュールで定義されていて、 Objectクラスがそれをインクルードしている。

普段はありがたいが、 method_missingを活用するプログラミングでは(定義されているメソッドに対してはmethod_missingが呼ばれないため)嬉しくないこともある。

そこで、Objectの上にKernelをインクルードしない「なにか」を用意しようと思うのだが、 問題は名前だ。

• Nucleus − 「核」。でもKernelも核だな
• CoreObject − 長い方が名称衝突の危険が少ない。でもイマイチ。
• BlankObject − 同上。

良い名前が思いついた人は、気軽にツッコンでほしい。

_ 花粉

が、飛んでいるらしい。今年は鼻炎の症状はまったくないが、 花粉にさらされると、喉がイガラっぽくなるのと、頭が重くなる。 〆切やらなんやらが重なっている時に思考力が下がるのは大変困る。

_ [Ruby] 続、Objectの上

なんとたくさんのツッコミがあったことか。今までで最大ではないだろうか(そうでもないかな)。

いただいた名前の候補は検討材料としたい。

「空っぽ」系

Void, Blank, Emptyなど。 しかし、Objectのスーパークラスであることを考えるとこれら「空っぽ」系は採用しがたい。 Objectの継承ツリーとは独立に導入するならあり得るかもしれないが、 それでも、たとえばDelagatorは「空っぽ」のサブクラスというのは奇妙に感じる。 EiffelではVoidはスーパークラスではなく、すべてのクラスのサブクラスとして定義してあるのが興味深い。

自己言及系

RubyとかMatzなど。少なくとも私が管理している範囲内ではRubyに自己言及的な名前を導入したくない。 Rubyインタプリタ自身を操作するクラス/メソッドにならともかく「すべてのRubyクラスの頂点」である という理由でRubyという名前を使いたくない。ましてやMatzなど。

比喩系

Atom, Idea, Heart, Ghost, Shellなど。 「〜のようなものだから」という理由は誤解を生みやすいので安易に導入できない。 ただし広く使われているので説明されれば納得できるようなものは除く(たとえばネットワークIOにおけるSocketとか)。 今回はそれに該当するものは、Rootくらいか。

ケチつけるだけで申し訳ない。 まだ、考えがまとまっていない。

_ [OSS] No More Free BitKeeper

ここ数年Linuxはバージョン管理システムとしてBitKeeperを利用してきたが、

• これはオープンソースではない(ただし非商用では無料だった)
• でも、CVSなど既存のバージョン管理システムより使いやすいので実利主義のLinusは愛用していた
• パッチ処理効率が数倍になったとの話もある
• BitKeeperの開発会社BitMoverは「BitKeeperの同種ソフトウェアを開発する人は無料版を使ってはいけない」などの制限を付けており、フリーソフトウェア派には大変不評だった
• リバースエンジニアリングでBitKeeper互換クライアントを開発しようという動きはいくつかあった(しかし、これはライセンスで禁止されていた)

という状況であった。そこに「OSDLがスポンサーしている開発者がBitKeeper互換クライアントを開発していた」ことが発端で無償版BitKeeperは今後提供されなくなり、Linuxは新しいバージョン管理システムを必要としている、というお話。monotoneもdarcsも(Linuxのような大規模ソフトウェアには)遅すぎ、らしい。

しかし、なんでバージョン管理システム開発者はトラブルを引き起こす傾向があるのか。 なにか隠された原因があるのか。

_ 桜

ここ数日暖かかったので、すっかり開花してしまった。 通勤途中の玉湯川沿いの桜並木はほぼ満開。 例年通り、涙が出るほど美しい。

とはいえ、日本全国ソメイヨシノのみというのは多様性を書いた欠いた不自然な状況ではある。 たとえその美しさが不自然さにより産み出されたものであっても。

_ [原稿] 日経Linux

「オブジェクト指向の歴史」、「抽象データ」、「継承」などについて。 でも進まない。このペースだと〆切に間に合わないかも。

どーする？ ＞ 自分

_ [OSS] OSI、オープンソースライセンスの分類に乗り出す

OSIは、現行のオープンソースライセンスを「Preferred（優先）」「Ordinary（一般）」「Deprecated（非推奨）」の3つのカテゴリーに分類する計画だ。

とのこと。いいことなんじゃないかな。RubyのライセンスはOSIのリストに入っていないけど、 分類するなら「Deprecated」かな。やっぱライセンスの乱立はまずいでしょう。

でも、それはそれとして、CreativeCommonsみたいに要求に応じて選択できる「メタ・オープンソースソフトウェアライセンス」群は欲しい気はする。でも、結局はyet another licensesになるだけなのだろうか。

_ [教会] 桜と総大会

午前中、花見をしたいと思っていたがすっかり寝坊してしまったので断念。

午後からは先週ユタで行われた教会の総大会のビデオを見る。 良い説教をたくさん聞いたのは良いのだが、いくら途中休憩があると言っても 3本6時間は長い。お尻が痛くなっちゃった。

夕食後、家族総出で玉湯川の桜を見に出かける。夜桜もなかなか良いものだ。

_ [教会] 桜と総大会(その2)

今日も総大会ビデオを見る。 子供たちも付き合っている。 「難しい」と言っていたが、とちゅう小声で解説を加えたりして乗り切った。

生活を改めねばならないなあ、と感じたことが数回。

今年は急激に桜の開花が進んだので、もう散りはじめている。 しかし、毎朝毎晩移動の車の中から花見ができるのは幸せなことだ。 期間限定だけど。

_ [家族] 入学式

長女の中学校の入学式であった。さすがに乳児を連れてきているのはうちだけであった。 式の最中に泣き出しちゃってちょっと弱った。

長女は期待していたやさしい方の担任のクラスになったと喜んでいた。 この先生はうちの会社の同僚の双子のお姉さんなのだ。世間は狭いものだ。 先生も驚いていた。

「先生は双子なんですよね」

「なんでそんなこと知ってるの？」

「お父さんから聞いたから...(以下略)」

長女の中学校はほぼ全員が同じ小学校からの持ち上がりで、1学年2クラスしかないので あまり目新しさはない。クラスもほぼ全員が知り合いだし。 私自身は5クラスの小学校と3クラスの小学校が合わさった中学校に通ったので、 知らない顔ばかりだった。同じ小学校同じ学年でも知らない人がたくさんいたもんなあ。

_ [Ruby]高橋メソッド

高橋メソッドによる高橋メソッドの紹介。

ま、それはいいんだけど、「やじうまウォッチ」でも取り上げられちゃってるな。すっかり有名になったこと。

_ [原稿] 日経Linux 6月号

ゴールデンウィーク進行で〆切は11日だったのだが、 入学式に参加してたりしてなかなか時間が取れず、徹夜する破目になった。 書き終わったのは早朝4時。体壊しそう。 もうちょっと早めに仕事が片づけられるとよいのだが。

で、6月号の「まつもと直伝・プログラミングのオキテ」の内容は、 先月の「ポリモルフィズム」に続いて「抽象データと継承」について。

オブジェクト指向のおおざっぱ(で、やや不正確)な歴史と、 抽象化とDRY原則をベースに、構造化プログラミングの延長線上として 抽象データと継承についてボトムアップに語ってしまうという怪作。

一面的な見方であるのは自覚してはいるが、あまり語られない視点なので面白いと自画自賛。

_ [言語] バールのようなもの

「C言語 ポインタ完全制覇」で知られる 前橋和弥さんによる、 「プログラミング言語を作る」という企画。

作ろうとする言語に対する愛が足りないのが少々不満だが、 言語処理系の学習には実際に動くサンプルをいろいろといじるのが一番なので、 大変役に立つだろうと思う。言語名はcrowbar、そのこころは「バールのようなもの」だそうだ。

_ [特許] 特許における「発明」とは何か

江島健太郎さんのところに届いた元特許庁審判長の丸山光信さんからのメールについて。

これを読んで、「こんなあやふやな定義の元に独占的排他権をこんなに長い期間与えてはいけない」と強く感じた。 もちろんアンチパテント気味のある私だから、その分は差し引いてもらったとしても、 現状の特許制度は知的財産の所有者にとっても望ましくない制度になっていると思う。

というか、金がないから特許に脅える私のような貧者よりも、 金も特許も持っている大企業が別の特許所有者から訴えられるケースの方がはるかに多い現状を考えると むしろ持てるものにとって不利な制度になっているのではないか。

まあ、金持ち同士がやりあってくれるだけなら直接的には私の腹は痛まないのだが、 それでも「人類の進歩と調和」が阻害されるのは嬉しくない。

_ [OSS] マイクロソフトのOOoに対する姿勢は新手のFUDか？

というか、OpenOffice.orgの互換性が低いからって、あなた、 MS Officeのバージョン間の互換性よりはマシなんじゃないですかねえ。 苦労したって話は良く聞くんですけど。

とはいえ、つまり圧倒的有利な立場にあるはずのマイクロソフトが意識しなければならないくらい OpenOffice.orgのプレゼンスが向上したってことなんだろうなあ。

_ [Ruby] Objectの上(その3)

「Objectの上」は空前のヒットとなり、コメント数が百を越えた時点で表示されなくなってしまった。 tDiaryにそんな制約があるなんで知らなかったよ、あんまり感心しない。

で、結局Objectの上のクラス名は

• 衝突を避けるため、あまり単純な名前ではない(2語以上の合成語)
• Objectとどちらか上か悩むことが少ない
• 比喩系を避ける

というような理由によりBasicObjectにしようと思うようになった。 Socket系クラスのBasicSocketからの類推であり、 またSmalltalkのBasicAt:が発想の源になっている。

これがあると、DelegatorやSimpleXMLのようなものが実現しやすくなるのではないかと思う。

_ U-20プログラミングコンテスト実行委員会

今年度の第1回会議のため東京へ。 いや、東京は遠い。さらにすっかり車生活で歩かなくなった足には、 浜松町駅から機械振興会館(東京タワー前)までの距離がつらい。 捻挫したりしてあまり歩かなかったし、すっかりなまっている。

今年のプロコンの実施要領はほぼ昨年度を踏襲。 ただし、

• より多くの参加者をつのるための広報のあり方
• 最終候補者のプレゼンにより最優秀賞を決定
• 「一般的なプラットフォーム」という条件を明確化
• 作品をオープンソース化することを推奨
• 作品完成前に仮応募できる事前エントリ制度

などの点を検討している。今年は体制もより良くして、 よりたくさんの応募が受けられると良いなと思っている。

若人よ、きたれ。

_ 誕生日

またひとつ年をとった。まだまだ20代だ、16進なら。

こうして実際の年齢をダイレクトに語ることに抵抗が出てくるってのは 年をとった証拠なのだろうなあ。

_ 献血

春は血が足りないらしい。オフィスの入っているビルに献血車が来た。 せっかくなので献血する、400cc。

会社の連中もなんにんか受けていたが、採血中に読んでいる本がアレゲだ。 『ハッカーと画家』、『Subversion』などなど。

_ ヒゲ

入浴中、ふと思い立ってヒゲを剃ってみた。 たいして伸びてなかったが、ちょっとさっぱりした。

しかし、家族の誰一人として私が言い出すまで ヒゲがなくなったことに気がつかないというのはどういうことか。

いかに人の顔など見ていないということか。

追記 (2005-04-15):

次の日になっても気付いてない。息子は入浴中(24時間後)にやっと気付いたようだ。 会社でも誰もなにもいわかなかったし、教会で会った人たちも同様だ。

_ SCIgen - An Automatic CS Paper Generator

Paul Grahamの『知っておきたかったこと--- What You'll Wish You'd Known』に以下のようなエピソードがある。

何か重要なことを言っているように見せかけるためにわざとわかりにくく書いてある論文だっていっぱいあるんだ。こんなふうに言うと中傷に聞こえるかもしれないけれど、これは実験的に確かめられている。有名な『ソーシャル・テクスト』事件だ。ある物理学者が、人文科学者の論文には、知的に見えるだけの用語を連ねたでたらめにすぎないものがしばしばあると考えた。そこで彼はわざと知的に見えるだけの用語を連ねたでたらめ論文を書き、人文科学の学術誌に投稿したら、その論文が採択されたんだ。

彼は理系重視主義なので(私もそうだが)ちょっと人文科学を揶揄している。 しかし、これが通用するのはもはや人文科学だけではなくなってしまった。

SCIgenは コンピュータサイエンスの論文を自動生成するプログラムであるが、 このプログラムの「作品」をWMSCI 2005というカンファレンスに投稿したところ、"non-reviewed" paperとして採択されたということだ。

まあ、この採択にはいろいろ事情があるようだが、 それはそれとして。

論文なんて簡単さ、自動生成できるんだから。来月頭に〆切の来る論文もこれで仕上げるかなあ。

_ [OSS] OSCJ.net、オープンソフトOSS開発支援プロジェクトが発足

Apache Foundationのようにオープンソースを支援するプロジェクトになりたい、のだそうだ。 とりあえず支援するプロジェクトは以下の通り。

• Project BlueQuartz
• Seasar
• uCLinux for H8
• Ninja-VA

いや、がんばってもらいたい。でも実際どんな「支援」を行うんだろう。 いろいろ考えられるけど、支援の仕方でプロジェクトの性質が全然変わるような気がする。

_ ドラマに見る「緊急対応」に対する一般的イメージ

Shiroさんが出演していたということで一部に有名な『恋におちたら〜僕の成功の秘密〜』だが、うっかり見逃してしまった。最近ドラマどころかテレビそのものをあまり見てないものなあ。

しかし、見逃すべきではなかったかもしれない。 劇中、システムがウィルスにやられるのに緊急対応するというシーンがあり、 ツッコミどころ満載であったと聞いたからだ。久々にドラマで大笑いできたかもしれないのに。

_ [家族]バプテスマ会

息子が8歳になったのでバプテスマ会。 元々緊張しやすいタイプの息子はバプテスマを受けることそのものは非常に楽しみしていても、 人前に出て注目を浴びるということが耐えられないらしく、そのことは嫌がっていた。 直前になってもかなり尻込みをしている。

着替えている時とか緊張のあまり震えだしていた。というか、今まで私が生きてきた中で、 こんなに緊張している人間を見たことがないくらい。

なかなか踏み出せずにいろんな人に心配をかけたり、迷惑をかけたりしたが、 なんとかかんとか無事にバプテスマと按手礼を済ませる。

すべて終わった後の息子の晴れ晴れとした顔といったら。

また、たくさんの人から祝福の言葉と誕生日プレゼントをいただいた。 こんなに愛されているとは幸せ者だ。

その後、親戚が集まって夕食。解散。

_ [教会] 米子

普段、月に一度の会議は岡山で行われるのだが、年に一度だけ山陰側で開催される。 山陽側の人には大変だが、私にとっては近いのでありがたい。

先月、「会議の結果がアクションに反映されにくい」ということが話し合われたが、 さっそくその点が改善されていた。 当たり前といえば当たり前だが、 会議の結果が単なる「情報の収集と周知」に終わらないためにも必要なことだと思う。 改善されたのは大いに喜ばしい。

その他、いろいろなことを話し合う。姪っ子にあいさつして玉造に帰る。

_ TCPフロー制御アルゴリズムは人のマネージメントへ応用できるか

タイトル通り、TCPフロー制御アルゴリズムを(人間の)マネージメントに応用した場合、 どのような原則が得られるか、ということを示したエッセイ。

あげられているのは以下のような原則。

• 完全に終わったという報告しか信用しない(選択的あるいは否定的な確認応答を返せない)
• 余力があるかどうかを、部下にしょっちゅう自己申告させる(スライディング・ウィンドウ)
• 余力があると言った奴でも、実績の無い奴は信用しない。しかし、可能な限り速く、能力一杯までタスクアサインする(スロースタート)
• 部下の仕事の速さを測定して、状況再確認のタイミングに生かす(RTTの測定とタイムアウトの計算)
• 納期に遅れた(タスクを落とした)奴の信用度は一気に落とす。しかし、タスクを落とさない、ぎりぎりの能力を速やかに見つける(輻輳回避アルゴリズム)

ここから引き出すことのできるマネージメントルールは以下の通り。

• 終わったという報告以外は信用しない
• 「順調です」や「予定通りです」、などの調子の良い途中経過は無視する
• 何も報告が無いのは、できていないと判断する
• 余力があるかどうかを、部下にしょっちゅう自己申告させる
• 余力があるという言葉は、半信半疑で聞く
• 余力が無いという言葉は、信用する
• 余力があると言う部下でも、実績の無い相手は信用しない
• 徐々にタスクアサインを増やして様子を見る(能力を見極める)
• のんびりしてはいられないので、タスクアサインの量は倍々で増やして、能力一杯を素早く見極める
• 見積りのために、仕事の速さを測定して、平均値と偏差を常に荷重補正して知っておく
• 嘘っぽくても、正規分布を描いて、平均値を中心に平均偏差の4倍の範囲に99%以上が収まることを示して、それを越えて報告が無い場合、遅れていると見なすと宣言する
• 納期に遅れた(タスクを落とした)部下の信用度は一気に落とす
• 以前できていた1/2ぐらいのところまではできると仮定してタスクアサインする
• それ以上に負荷をかけるとまた裏切られる可能性があるので、徐々にアサインを増やして様子を見る

面白い。すごくドライな気がしないでもないが、 パフォーマンスのためにアルゴリズムにかけるのと同じくらいの設計努力で、 マネージメントルールもきちんと検討することも重要なのかもしれない。

_ [Ruby] Rails Day

7月6月4日にRails Dayが開催される。

これは24時間の間にRailsを使ってどのようなアプリケーションを作ることができるかを競うコンテストである。

ルールは以下の通り。

1. Your application must be written in Ruby on Rails

   アプリケーションはRuby on Railsで記述されなければならない。

2. Your application must use MySQL

   アプリケーションはMySQLを使わなければならない

3. Your application must be under a license where the code may be viewed by the general public (for inspiration and as a reference). The rest is up to you.

   ソースコードは一般に対して公開されなければならない。ライセンスは自分で決めてよい

4. Your application should be written totally within the 24 hour period. Photoshop comps, CSS and Javascript are included in this time.

   アプリケーションは24時間で記述されなければならない。Photoshopによる画像作成、CSSおよびJavaScriptもこの時間に含む

5. Only libraries installable via gem are allowed. However no gem that uses any of the components of rails is allowed.

   RubyGemでインストールできるライブラリだけが使用可能。ただし、Railsのコンポーネントを利用したGemは利用不可

6. Up to 3 people are allowed to work on a single entry.

   ひとつのエントリには三人まで

7. You are allowed to dream up the idea before the competition you can also do paper mock-ups of database schemas and UIs. No digital mockups any more complex than a paper napkin drawing are allowed before the competition begins.

   事前にアプリケーションを夢想するは許される。 スキーマやインタフェースのプロトタイプを紙の上でまとめるのもOK。 ただし、実際のプログラムやペーパーナプキンのメモ書き以上のものは競技開始前は禁止

8. The applications will all be hosted on the competition server. You will have 24 hours of subversion and ssh access to the server to upload and test your app.

   アプリケーションは競技用サーバーでホストされる。競技中は24時間のsubversionとsshアクセスが許される。

9. You must use subversion and checkin your work at least 12 times at various stages of development

   競技中はsubversionを用い、開発のそれぞれの段階で最低12回はチェックインすること。

審査員

• David Heinemeier Hansson
• Dave Thomas
• Lucas Carlson
• もうひとり秘密の誰か(近日公開)

_ [言語] Dynamic Languages Symposium 2005

OOPSLAと共催される「動的言語シンポジウム」。

なぜか私もProgram Committeeに 名を連ねてたりしている。

今年のOOPSLAは、Ruby Conferenceの直後だし、 Wiki Workshopはあるし、Dynamic Languages Symposiumもあるしで盛り沢山かも。

_ ある「ハッカー」の顛末

IRCでトラブルが起きた時に、ある「ハッカー」が気に入らない相手に何をしようとして、 何が起きたか、というお話。ある意味、喜劇、別の意味では悲劇、かも。

原文はドイツ語らしい。雰囲気を伝える超訳。全然正確じゃないんでそのつもりで。

ハッカー(以下「ハ」): なんで俺をbanしたんだ。
攻撃対象(以下「対」): そんなことしてない。

(中略)

ハ: お前(のPC)をハックしてやる。IPアドレスを教えろっ。
対: えーと、127.0.0.1だけど。
ハ: 俺の持ってるツールを使えばお前のPCは一発だ
対: なんと恐ろしいことだ(棒読み)
ハ: バイバイ
! bitchchecker (~java@euirc-61a2169c.dip.t-dialin.net) Quit (Ping timeout#)

数分後

+ bitchchecker (~java@euirc-b5cd558e.dip.t-dialin.net) has joined #stopHipHop
ハ: 運がよかったな。ちょうど俺のPCがクラッシュしたんで助かったな
対: ならもう一度ハックしてみてよ。IPアドレスは127.0.0.1だよ
ハ: 馬鹿が
ハ: バイバイ
! bitchchecker (~java@euirc-b5cd558e.dip.t-dialin.net) Quit (Ping timeout#)

さらに数分後

+ bitchchecker (~java@euirc-9ff3c180.dip.t-dialin.net) has joined #stopHipHop
ハ: お前ずるいぞ。ファイアウォールを使ってるな
対: そうだっけか
ハ: お前のファイアウォールが停止信号を俺のPCに跳ね返したんだ
対: そんなことできるなんて知らなかったよ
第三者: お前いくつだよ
ハ: 26だ
ハ: ファイアウォールを使うなんて男らしくないぞ
ハ: ファイアウォールを使うのは女々しいやつだ
ハ: 男らしくファイアウォールをオフにしてみろ
ハ: 俺のウィルスがお前のPCを破壊してやる
第三者: ファイアウォールをかいくぐるのが「ハック」じゃないのか

対: 分かったよ。同僚にファイアウォールの止め方を聞いた
対: オフにしたからアタックしてみな
ハ: IPアドレスを教えろ
対: 127.0.0.1
ハ: よーし、見てろ

ハ: お前のG:ドライブは削除されたぞ
ハ: 後20秒でF:ドライブも削除だ
ハ: F:ドライブもE:ドライブもおシャカだ
ハ: D:ドライブも削除
ハ: インターネットでIPアドレスを公開するなんて馬鹿なやつだ
ハ: C:ドライブももう30%削除した

手元のPCのディスクには異常はない。 「ハッカー」に、彼が攻撃してるのは違うPCだと教えるべきだろうか。

! bitchchecker (~java@euirc-9ff3c180.dip.t-dialin.net) Quit (Ping timeout#)

遅かったようだ。それ以来、bitchcheckerと名乗る「ハッカー」を見かけない。

「ハッカー」は用量・用法を守って正しく使いましょう。

_ [OSS] L・トーバルズ、新しいLinux開発管理システムに「Git」を選択

やっぱ、自作ということになったか。

Monotoneは全ファイルのMD5をタグにするからLinuxカーネルくらいファイル数が多いとまともには動作しなそうだものな。しかし、gitは主にLinux向けで汎用にはならないかも。

Gitには、Linux本体のようにGeneral Public License（GPL）が適用され、約5〜10人のプログラマが「本格的に開発に携わっている」とTorvaldsは語っている。しかし同氏は、このプロジェクトがLinuxのカーネル開発作業以外にも役立つものになるとは予想していない。

パッチをうまく管理できる汎用のバージョン管理システムというのはLinuxに限らず役に立ちそうだ。 もっとも、中央レポジトリが許容できるならCVSでもSubversionでもたいして困らないのかも。

_ Why Smart People Have Bad Ideas

Paul Graham最新作*1。 「なぜ賢い人々がまずいアイディアにとらわれるのか」というお話をPaul自身の失敗談を含めて語る。

詳細は原文を読んでもらいたいが、 理由は大きく言うと

• 最初に思いついたアイディアが一番良いとは限らない。 が、まずいアイディアと気づいても過去の投資を考えるとなかなか止められない
• 楽しいことはカネにならない(言語を設計することとか)。
• 臆病さ。強そうに見えるプレイヤーが本当に強いとは限らない。 参入しなければ成功はない

があげられている。そして成功するための秘訣とは...。

_ [Ruby] 新GC

ようやっとCVSにブランチを作って新GCの実装に取り掛かる。 論文の〆切が来月頭であることを考えるとあまりにもとりかかりが遅い。

今日はとりあえず最新1.9にライトバリアを追加する作業を行う。 木山くんのライトバリアが参考になるからさくさく進む。

これなら −もしかしたら− 間に合うかもしれないぞ。

「もしかしたら」じゃダメなんだけど。

_ 「1週間コンピュータなしで暮らそう」--米で『無使用週間』実施へ

1週間、コンピュータなしの生活とか、まったく想像ができないなあ。

考えてみると、朝起きて、食事して(時にもう一度寝て)、 そこからコンピュータを開いて、後は通勤のための運転中と、 食事時と夕食後家族で過ごす時間を除いては、 ほとんど毎日コンピュータ(とインターネット)を利用していることになる。 時には深夜・早朝にいたるまで。

休日はだいぶ減るけれども、まったくコンピュータを使わない日はない。 1年365日、毎日平均だと12時間以上はコンピュータの前に向かっているような気がする。

これはもしかすると異常？

「もしかしなくても」という声が聞こえるような気がする。

_ [家族]買い物・食事

先週だった息子の誕生日のカードが届いたので(わずかな割引に釣られて)昼食はレストランで。

その後、長女の自転車通学用の自転車を購入。二件目の店で娘があげていた条件全てを満たすものを見つけた。 しかし、「配送がいつになるかわからない」とのことなので、 月曜日に取りに来ることにする。後部座席をたためばうちのミニバンにも載るだろう。

_ アクセス

先日の「ハッカー」の顛末が、やじうまウォッチなどにとりあげられたせいで、アクセス数がすごいことになっている。 マシンリプレース前だったらパンクしてたかも。

楽しんでいただけてさいわいだ。でも、アクセスさせるのはこんな下らないネタなのね。 もうちょっと有意義なネタでアクセスされたいものだ。

もっとも「有意義」ってのは人によって違うしな。 小難しい話より、馬鹿ネタの方が有意義と思う人が多いってことかも。

_ [教会] 倉吉支部大会

年に一度の支部大会。倉吉ってほんとうに久しぶりだけど、こんなに近かったっけ。

久しぶりに訪問すると、子供が大きくなってたり、 人が増えてたり、結婚した人がいたり、結婚が決まった人がいたりする。 まあ、基本的によい変化ではないかと。

あまり責任の割り当てがなかったので、わりと気楽に参加できた。 やったのは急遽依頼された指導者会の司会だけ。楽なものだ。

_ [用事] 自転車運搬

午前中、長女の自転車を取りに行く。ついでに妻と昼食。

_ [Ruby] 新GC

とりあえず動くようになった。これで測定できる。

ただまだバグバグで、ちょっと凝ったプログラムを使うとすぐに動かなくなる。 アルゴリズムの原理的な有用性を示すのには十分だが、実用にはまだ遠そうだ。

基本的な考えは1ビットリファレンスカウントとZCTを組み合わせることで、 寿命の短いオブジェクトを再帰的にスキャンすることなく回収するというものだ。 このことにより、世代別GCと同等の効果をあげることができる。

ただし、ライトバリア(というかリファレンスカウントの管理)のコストと、 より頻繁に発生するconservative stack scanのコストは増えるので、 通常GCの削減とのトレードオフになる。

ざっと動かした範囲内では、「生きているオブジェクト」が多いケースではそれなりに有効、 「生きているオブジェクト」があまり多くないケースではすこしだけ遅くなる、 といったところか。

ただ、1ビットリファレンスカウントだけを使ったマイナースキャンはスレッド独立にできるはずなので、 native threadを使う処理系では同期の回数が減ってもっと嬉しいかも。

しかし、本当に論文〆切に間に会うのかちょっと不安。

_ [言語] Lightweight Language Day and Night(通称:LLDN)

Ploneを使ったこぎれいなページができている。大したものだ。

しかし、ゆうべ突然メールがきて、8月27日、28日に別の用事が入ってしまった。 こんな急な日程変更があるとは。 LLDN、昼の部だけなら出れると思ってたのになあ。

外出する用事なのでSkypeも使えそうにない。弱ったなあ。

私にとってどっちも大事だしなあ。

_ [Ruby] YARV?

Pythonの偉い人で最近Parrotにも手を出しているSam Rubyが、 YARVに関心を持っているという話。

名前にかけたジョークが出るかと期待したが、そういうのはなかったみたい(期待するものが違います)。 これで、SamはPython, Perl(Parrot), Rubyの全部を制覇か。

_ [Ruby] Ruby is the "Most Loved" programming language

以前にもあった、Googleで「"i love x" programming」と「"i hate x" programming」とを検索して、 LOVE/HATE比を出す、というお話。ここで「x」にはRuby, Java, Pythonなどが入る。

なんと、Rubyはダントツの一位。ま、しょせんお遊びだけど、それでも嬉しい。

_ [Ruby] 訃報x２

宅急便で献本が届いた。『4839917299』。

著者の秋山さんからは正月にメールをいただいていて「献本したい」とのことであった。 ようやっと完成したということだ。まだ読み込んでいないが、なかなか良いテーマで書かれた本だと思う。

が、しかし、編集の方から連絡があって 「秋山さんは2月18日に亡くなられました」とのことだった。著者紹介の欄にもそう書いてある。 36歳、クモ膜下出血だったそうだ。 まだ若いのに。自分とほぼ同世代でまだまだ若い人(しかもRubyユーザ)が亡くなるのを聞くのは切ない。

また、先日の尼崎の列車脱線事故の被害者の中に石井 勝さんがいらっしゃったのだそうだ。彼とも直接面識はないが、彼を通じてRubyを知ったという人も多かったようだ。 彼もまた同世代(37歳)であった。

彼らの魂よ安かれと祈る。

_ [Ruby] スクリプト言語人気に思う，動的型付け言語の可能性

「動的言語ってばけっこういいじゃん」ってお話。

Javaのような厳格な言語を自在に使いこなして大規模な企業システムをバリバリと作っている技術者の中にも，スクリプト言語ファンは多い。彼らを惹きつけるものは，いったい何なのか。

Rubyを愛するそんな技術者のお一人に，この疑問をストレートにぶつけてみた。その方いわく「とにかく楽なんだよなあ，Rubyでプログラミングするのは。なんでだろう。よく分かんないなあ」。

この言葉を聞いてはっとした。この一言に，スクリプト言語が持つ魅力が凝縮されているように感じたのだ。言葉にできない何か，感覚的な「楽」さ。それこそが，スクリプト言語人気の根底にあるパワーなのではないか。

パワーなんです。

八木さんからは先日の「日経バイト」の特集のためにメールでインタビューを受けていて(ちゃんと献本していただいた、感謝)、その内容がここでも再利用されている。 あ、そのインタビューの中では動的言語のデメリット(型がないから実行してみないと分からないとか、プログラムを見ただけでは何を渡してよいか分からないとか)についても触れていた。記事には使われなかったけど。

まあ、こういうところで紹介されるというのは動的言語がメインストリームに近づいてきたということなのだろうか。１０年時代を先行していたということか。そんなこと言ったらLispなんか４０年時代を先行しているわけだけど。

_ プロポーショナル？ 固定ピッチ？

あまり登録した記憶がないメールマガジンが送られてきた。 忘れているだけできっとどこかでアドレスを渡したのだろう。

しかし、妙な記述が。

このメールマガジンは、日○○○○主催または協賛の展示会やセミナーに
(Webセミナーを含む)にお申し込み・参加された際に、情報提供について
ご了解いただいた皆様にお届けしています。
このメールはプロポーショナル「固定ピッチ」でご覧ください。

えーと、つまり要するにフォントはなにを使えと。 「プロポーショナル」で「固定ピッチ」などと自己矛盾するフォントは持ってないっす。

_ [言語] PEP #340 Anonymous Block Statements

RedHandedより。

PythonにもRubyにあるような「ブロック」を取り入れようというアイディア。

文法はこんな感じかな。

block with_file(filename) as f:
   for line in f:
     print process(line)

これをRubyに翻訳するとこんな感じか。

open(filename) {|f|
  for line in f
    print process(line)
  end
}

Rubyのブロックに似ているのはわざとらしくて、Guido自身も次のように語っている

I think we're on to something. And I'm not too proud to say that Ruby has led the way here to some extent (even if Python's implementation would be fundamentally different, since it's based on generators, which has some different possibilities and precludes some Ruby patterns.)

(超訳)
それなりの案になったと思う。この分野においてRubyの方が進んでいると認めざるをえない。 (Pythonのはgeneratorをベースにしているので実装は全く異なっていて、 Rubyのとは違った(使い方の)可能性があるし、逆にRubyにできてPythonにできないこともあるだろう)

私からの印象は

• blockキーワードはちょっとうっとうしい。 でも、まだ「仮」だそうだから、実際には違うものになるだろう。
• asキーワードもあんまりピンとこない
• generatorを使っているので、blockに使うメソッド(関数)は専用のものが必要。 Rubyのように「ブロックが与えられたら動作が変わる」タイプのものは実現できない。 名前を考えなくてすむのはRubyの方がありがたいが、 きちんと区別したい人にはPythonのやり方を好むかもしれない(私は強制されたくはないが)。
• else節をつけられるのはPythonのループ類の特徴。 便利な局面もあるらしい。 Python以外ではあまり見かけないが、ずっと以前にどこかで見たようなおぼろげな記憶が。
• Pythonの文法の制約から(それとgeneratorを使っていることから)ブロック付き関数は値を返せない。 Rubyでのブロック付きメソッドの使われ方から考えると、 これは結構厳しい制約だと思う。魅力半減以下というかなんというか。

まあ、対抗する立場の人からのコメントなので話半分に聞いてほしい。 いずれにしても我々のアイディアが広く受け入れられるのは嬉しいことだ。

_ 論文

去年の夏に出した論文の査読が終わって帰ってくる。いやあ、長かった。

そして査読の結果を見ると...すみません、...私が悪うございました。 はっきりいって論文をナメてました。いや、書いてる時は自覚してませんでしたけど、 未定義の言葉とか、考察が足りないところかが満載なのが厳しく指摘されてました。

これにくじけず再挑戦しますです。書き直す時間を取らなきゃ。 こんどはもっとマシにしなきゃな。

_ [家族] 宍道ふるさと森林公園

教会の活動で子供を連れて森林公園へ。 そんなに遠くないのに、実はここに来るのははじめて。 長女と末っ子と妻は留守番。

２日の論文の〆切が気にはなるが、家族と過ごす時間も重要だろうということで。 しかし、体力が尽きてはいけないので、わりとおとなしめに過ごす。 気をつけないと、体力ないくせに全力で遊んで、後で動けなくなるから。

日陰の芝生に寝転んで、考えことをしていると、論文で見落としていたことを見つけ出した(と、その時点では思い出したが、最終的にはこのアイディアは論文には反映されなかった)。

夕方、帰ってから、最終のデータ取り。予想通り、当初の期待よりは性能が出ない。 プログラムのアクセスパターンによっては、 今使っているプログラムよりも性能が出る可能性は否定できないが、 そんなプログラムを今から探し出して、きちんと測定する余裕はなさそう。 まあ、勘弁してもらうしかない。

_ 論文書き

土曜日。本来なら休日だが、今日は一日論文書きをすると決める。 家族も協力してくれて、半日放置してもらえる。

今まで構想で練ってきたものを一気にに文章化(いや、それが望ましいやり方かどうかは置いといて)。 ８ページ。

笹田くんが協力を申し出てくれる。一人でやってると、どこが良くてどこが悪いのか見えなくなるので、ありがたい。現時点で書けたものをメールで送って読んでもらう。はたして、ほんとうに間に合うのか。