4797314087 初心者向けとして定評の高い4797314087の増刷が決定しました。 監修者としては嬉しい限りです。 私にもこういう良い本が書けたらなあ。
の印税が小切手で送られてきたので 地元の銀行に換金に。 アメリカは小切手社会なのか、振り込みにしてくれと頼んでも小切手で送ってくる。 しかし、たかだか250ドルほどの小切手換金に2000円以上の手数料がかかると言うのはいかがなものか。
次のプロジェクトではXPを採用することが決まったので、 練習ということで、後輩がペアプログラミングを試している。 年寄りは見てるだけ。
しかし、慣れないせいか、 いちいちテストケースを作るのが面倒だったり、 いつもよりはるかに時間がかかっているようだ。 とはいえ、はたから見てると楽しそうだ。 私もやってみようかなあ。
なかなかリリースできない1.8だが、 リリース前にやっておきたいことがあとどれくらいあるのか。
は片付けておきたいなあ。
Module#instance_methodsなどは引数が省略された場合、 あるいは引数として偽を指定した場合にはそのクラスで定義されているメソッドのリストを、 真を指定した場合にはスーパークラスまでさかのぼってメソッドのリストを返します。
しかし、Rubyのような言語にとって継承は単なる実装の共有が目的ですから、 興味があるのは「そのクラスのインスタンスが持っているメソッドのリスト」のはずです。 ということは、現在のデフォルトは間違っていることになります。 またやっちゃった。
そこでさっそく修正しました。
ところが直後に、この修正によってirbが動かなくなったとDave Thomasから報告がありました。 具体的にはdelegate.rbがこの変更に対応していなかったせいです。 この問題そのものはdelegate.rbを修正することで簡単に直せたのですが、 この一件で大きな矛盾が明らかになったような気がします。
つまり、言語またはライブラリのデザインに間違い(使いにくさ、一貫性のなさ)があったとき、 長期的な観点からは修正した方が良いに決まっています。 間違い、一貫性のなさは言語の良さを損ねます。 しかし、その修正の結果、非互換が生まれれば、少なくとも短期的には多くの問題が生じます。 ユーザが多ければ多いほどその問題は深刻になります。
かつて、Rubyのユーザがわずかであった頃にはこれはあまり問題ではありませんでした。 しかし、いやまRubyユーザは世界中に数えきれないほどいます。 ささいな変更でも影響がばかにできなくなっています。
短期的な視点に立って欠点を放置するか、長期的な視点に立って欠点を修正するか。
アジャイルな立場からいえば、変化を恐れず対応するべきなのでしょうが、言語の場合には
という点で、急激に変化してはいけない傾向があります。 アジャイルの指導者の一人であるDave Thomasに相談しましたが、 彼にも良いアイディアはないようです。
結局今回の問題は、
という方向で結論を出しましたが、変化に強い言語デザインとはどのようなものかということについては 結論が出ないままなのです。
4月に出すつもりだったRuby 1.8のリリースが遅れている。 自分の誕生日に出すつもりだったのだが。
リリースが遅れている理由はふたつある。 ひとつはリリースマネージメントの問題だ。 つまり、私はリリース前になにをなすべきかを十分に把握していないことだ。 これについてはこれから文章化して明確にして行こうと思っている。
もうひとつはもうちょっと深刻で、私が内心ではリリースを望んでいないことだ。 より正確には、望んでいないのはリリース前のfeature freezeだ。 私が一番関心があるのは言語をよりよくすることで、 「よりよく」には本質的に変化が伴うので、 変化を止めてしまうfeature freezeは嬉しくないのだ。
ここにもまた矛盾がある。
Ruby 1.8にこれから加えるかもしれない最大の変更がこれだ。 現時点ではProcクラスにはcallメソッドと新たに追加されたyieldメソッドがある。
本人はこれで満足していたのだが、 David Alan Blackが「yieldって名前はおかしい」と指摘したので少々話がややこしくなった。 とはいえ、まだ名前に対する考えはそれぞれだし静観してればよいと思っていたのだ。 しかし、[ruby-talk:70220]で「BlockとProcを導入する」というアイディアを見て考え直した。
callとyieldの両方のメソッドを持つということは、 呼び出し側がある手続きオブジェクトを手続き的に呼びたいか、ブロック的に呼びたいかを決めることを意味する。 しかし、実際には手続き的に呼ばれるもの(lambdaで生成されたものとか)と、 ブロック的に呼ばれるもの(ブロック引数で得られるものとか)は、はっきり異なるのではないか、 別の言い方をすると、手続き的に呼びたいか、ブロック的に呼びたいかは、 呼び出され側が決めるべきことではないかと。 別の呼び出し方がしたい場合には明示的に変換すると。
考えれば考えるほどこっちの方が妥当のように思えてきたのだが(1.6からは上位互換だし)、 変更が相当大規模になるので尻込みしているのだった。
これも懸案のひとつ。instance_methodsなどと一貫性を持たせるため、 methodsもrecurseするかどうか指定できる引数を追加するという Dave Thomasの案をとりあえず採用したのだが、 この場合特異メソッドはどうなるのだろうか。
現状では
を返すと言う「実装の都合で支離滅裂」な挙動になっているから、 変えなくちゃいけないのは確かだが、問題はどう変えるのか、だ。
追記(2003-05-06): 結局、デフォルトと真のときにはすべてのメソッド、 偽の時には特異メソッドのリストを返すことにしてみました。
こっそり書いてたんですが、いつの間にか見つかってしまいました。 別にいいけど。
あ、私は「blog」と「にっき」を区別しない人です。 あんなのたんなるスタイルの違いじゃないかと。
日本語で「Matzさん」と言われると恥ずかしい。 よければ「まつもとさん」でお願いします。> みなさま
callやyieldで私がなにを問題視しているのか理解できないとの指摘が多い(ような気がする)ので、 もう一度まとめてみたいと思います。分かってる人には繰り返しになりますが。
Rubyのブロックってのはもともとループの抽象化のために生まれたものですから、 以下のような性質を持ちます。
ブロックをオブジェクト化したProcオブジェクトも同じ性質を受け継いでいます。 ところが、普通の人が「手続きオブジェクト」に期待するのは、 無名の関数オブジェクトですから(私もそう期待します)、
の方が嬉しい場合が多いでしょう。後者は必須じゃないけど。
これはどういうことかっていうと、 誕生の歴史的には「オブジェクト化されたブロック」に過ぎなかったProcが、 その名前(ProcはProcedureの略だろう)と、他言語でからの類推により 無名関数として振る舞うことが期待され、期待とのズレが発生しているということなんでしょう。 lambdaなんて名前を用意している時点でこの期待は必然なんですが。
1.7ではこのズレをProcを実行する側(caller)が、 関数オブジェクト的に呼び出したい場合にはcall、 ブロック的に呼び出したい場合にはyieldで呼び出すことで対応しようと考えました。 ブロックの呼び出しにはyield文を使うわけですから、これはこれで自然かなと。
しかし、あるひとつのオブジェクトを関数的に呼んだり、ブロック的に呼んだりするもんでしょうか(いや、ない)。 とすると、ユーザにその選択を強制するのは不合理です。呼ばれ側(callee)がよしなに振る舞うべきでしょう。 コンピュータが決められることはコンピュータがやるべきです。
とうことで、新たにBlockクラスを導入して(BlockはProcのスーパークラス)、 ブロック引数で与えられるオブジェクトはBlock、 lambdaで与えられるオブジェクトはProcとするのはどうだろうか、と。 そうすると関数オブジェクトを期待する局面ではProcオブジェクトが得られ(Procの挙動は1.6までとほぼ互換)、 手続きオブジェクトを期待する局面ではBlockオブジェクトが得られてきれいにまとまるような気がしています。
問題は100%互換ではないことと、これを実現しようとするとeval.cをだいぶ修正しないといけないこと。
あと、パラメータ受渡のセマンティクスを見直すのも大変そう。でも、
lambda{|a| p a}.call(1,2) # => [1,2]
がエラーにならないこと(これもズレが原因)に不満を持っている人は多いわけで、 「親切な言語」を目指すRubyとしてはなんとか救済してあげたいんですよね。
昨年秋に発生した「テレビがテレビ台に入らない」という異状事態をやっと解消する。 テレビを買うときには高さ・幅だけでなく奥行きも確認しましょう。
今日になって出るとは。ペダルボートを漕いだ足が痛いぞ。うう。
4894712741を注文する。 020161622Xは著者たちからもらったサイン入りを持っているものの、 日本語訳は持ってなかったからだ。
これは自分が読むのももちろんだが、プロジェクトメンバに読ませることになると思う。 今回のプロジェクトは時間も人間もタイトなので、かえってこのような「知恵」を 身に付けてもらうことが重要になると考えたからだ。
彼らのインタビューも参考になる。
しかし、DaveとAndyはすごいなあ。 このような人たちに注目してもらって、4894714531まで書いてもらった Rubyはなんとラッキーなのだろう。
で、Pragmatic Programmersのインタビューの最新が XML批判であった。ちょうどLinux Magazineの最新号の連載で展開していたXMLについての批判とほぼ共通している。 要するにXMLは広く使われすぎ、ということである。
XMLは元々マークアップ言語である。それが構造データの表現として使えるからという理由で 使ってしまうのは、開発者の怠慢に過ぎない。XMLは
という特徴によって、構造データ表現としては最悪に近い。 連載でも述べたが、構造データ表現のファイルフォーマットなら、 YAMLの方が1024倍は良い。
ただし、XMLにも価値がないわけではないと思う。 文書データ相互変換のピボットを考えるならば、 (たとえばdocbookなどとともに)XMLを使う以外に「まともな」解は存在しないだろう。 ツールもプロトコルも適材適所ということである。
「ハンマーを持つ人にはすべてが釘に見える」ということわざはXMLに限らず真実である。 いや、Rubyにおいてもその通りであろう。自戒しなきゃ。
Numeric#stepがFloatに対して正しく動かない問題に半日悩んでいたのだが、 こちらを直せば別の問題が出る、という具合でなかなかうまくいかない。 結局、田中昌宏さんが[ruby-dev:20177]で対応してくださった。 これは全部のテストが一発で通った。うーん。
やっぱり、私が数値関連に手を出したのがまちがいだった。 「下手な考え休むに似たり」あるいは「餅は餅屋」。
THANK YOU MATZ for a scripting language where parts don't snap off the objects and choke small children. -- Rasputin
お子さまにも安心なRubyをどうぞ、ってか。
次女が熱を出した。また風邪かしら。 この冬から春にかけてわが家はたびたび風邪に襲われている。 これで何度目か。
来週金曜日に開催される「第103回ヒューマンインタフェース研究発表会」のプレゼンテーション資料を書きはじめる。
昨年松江で開かれたソフトウェアシンポジウム2002のキーノートを聞いた中小路先生が呼んでくださったのだ。 タイトルは「インタフェースとしての言語のデザイン:Ruby」というもの。 プログラミング言語はユーザインタフェースであるという(私にとってはいつもの)話をすることになる。 ユーザインタフェースという観点から見た言語デザインが一般のインタフェースのデザインに役に立つように還元できるといいなあ、と思っているのだが、はたして。
プレゼンテーション資料は公開する予定。
YAMLの方が1024倍良いという主張をより明確にしたい。
まず、前提から。前にも述べたがあらゆる局面でYAMLがXMLより優れていると主張するつもりはない。 YAMLは基本的には構造データ表現フォーマットである。 文章のマークアップの領域でXMLと競うのは無意味だ。「YAMLの方が良い」という主張は当然「汎用データ表現」、 今月のLinux Magazineで使った用語を使えば「メタ・データフォーマット」として、という意味だ。
では、そのような前提のもとに、なぜYAMLが優れているか。
データ量
XMLを採用するとデータが膨らむのは多くの人が経験している通りだ。 その理由はテキスト形式を採用していることもあるが、なによりもあのタグ形式が原因だ。 XMLってなんであんなに冗長なんだろう。その点、YAMLは記号とインデントで表現がコンパクトである。
可読性
YAMLの表現がコンパクトであると言うことは、すなわち読みやすさにつながる。 もちろん、YAMLだって万能ではないので、読みにくいYAMLは当然あるわけだが、 YAMLで読みにくい構造データは、当然XMLでも読みにくい。逆は必ずしも成立しない。
柔軟性
XMLとYAMLを比較すると、XMLの方が圧倒的に柔軟性が高い。 XMLはスキーマによってあらゆる構造が表現可能だし、 「構造データも表現できる柔軟性がある」というだけで、構造データ表現専用というわけではない。 一方、YAMLにもYOD(YAML OK Document)というドキュメント形式があるが、 やはり構造データ表現のためのフォーマットと考えるべきだ。 YAMLは「XML+スキーマ」と同等の位置づけになるだろう。
柔軟性がある方とない方を比べたら、ある方が良いように感じられるかもしれない。 しかし、なんでもできるツールが使いやすいツールとは限らない。 むしろ目的に適合したツールの方が優れたツールである可能性のほうが高いだろう。 また、過度の柔軟性は人間に優しくないことを覚えておくべきだ。
使いやすく、現実に即したAPI
XMLを解析するAPIとしてはDOMやSAXがある。 しかし、構造データ表現のためには整形式では情報が足りない。 XMLを読み込んで取り出したノードからプログラム側で適切に型変換してやる必要がある。 XMLスキーマには型情報が含まれる(らしい)が、お手軽にXMLスキーマを使えるAPIってあったっけ。 一方、YAMLはロードとセーブのふたつのAPIでとりあえず利用できます。 YAMLデータは型情報を含んでいますから、型変換を気にする必要はありません。
「XMLは現代のS式」と呼ばれることがある。 どのような構造データもとりあえず表現できるという点ではその通りだろう。 しかし、一般人に広く知られてしまったという点でS式より罪は深い。 『図解で分かるS式とLisp』なんて本は今までもこれからも出版されないだろうし。
追記: 「YAMLが良い」という主張にもうひとつ暗黙の前提があるのに気がついた。それは「人間が読み書きする可能性がある」という点だ。人間の目に触れないならYAMLである必然はないものね。
Linux Magazine6月号が届いた。 ということは、次の月の〆切がすぐ近いということだ。 そろそろ書きはじめなきゃ(←もっと早く書きなさい)。
次号のテーマも今回に引き続き「XMLとYAML」。
この日記でもAmazonのアソシエートを利用している。 Amazonは使い勝手は良いのだが、アメリカのAmazonが面倒な特許を次々と取ってくれるので、 そのたびに心を悩ませることになる。 悩みつつも、結局使いつづけてる軟弱ものなんだけど。
で、今日、久しぶりにAmazonアソシエートのレポートをチェックしに行ったら、 リンクした覚えのない書籍が購入されている。
まいどあり(笑)。しかし、どういう経緯で購入されることになったのか。
...コナンか、先日のNHKの放送は3話だけだったものな。欲しいな。 うちの子は「江戸川コナン?」とかほざいてたけど。
追記: Amazonって、リンクをたどった後に購入したものにまで、紹介料を払うのね。 知らなかった。
当地では金曜夕方に放映される「アバレンジャー」の録画に失敗してしまいました。 息子が激怒してます。
Gコードで予約したのでよもや失敗することはないだろうと思いこんでいたのですが、 時計が狂っているのは予想を越えた事態でした。 先日の模様替えのときに1時間ずれていたのにずっと気がつかなかったのですね。
ここから得られる教訓は
ということでしょうか。
しかし、今週は「仮面ライダーファイズ」の録画もうっかり忘れちゃってるんだよなあ。 そろそろボケてるかも。
というのは確かにその通りだと思います。もっとも、
という対策で満足できる人も多かろうとは思いますが。
さっそく、原稿に取り込もう。ありがとうございました。(_ _)
初等協会の活動として、子供たちを連れて教会とその隣の宣教師のアパートの周辺の草とりをする。 かなり生えてた雑草を片付けて気持ちよくなった。 で、すっかり疲れてしまったりすると、普段の運動不足を実感したりする。
「blog」と「にっき」を区別しない などと書いたものの、数日間日記をつけてみると、やはりこれは違うものだと感じるようになった。
blogは、〆切や分量などの制約はゆるいものの、 やはり雑誌の記事やコラムなどに近いものが本来のあり方なのだろう。 新聞や雑誌の記事で「今日は子供と草刈りをした」なんて個人的な話題を読まされたら、 あまり気分は良くないように、ある程度読み手もなにかテーマに沿った一貫性のある記述を期待しそうだ。 ただ、既存のメディアとは違い、blogは個人に所属しているので、 パーソナルな記述が現れるのはむしろ当然で、それが日記との区別を難しくしているのだと思う。 また、パーソナルな記述があるがゆえに既存のblogのメディアより面白いという点もあると思う。
一方、日記のあり方はまったく逆だ。 一貫したテーマに対する「記事」にパーソナルな記述が入り込んでいるblogに対して、 日記は基本的に日記なので、自分の生活に起こったことも、その時に考えたことも、なんでもありだ。 紙の日記と違って、不特定多数の目にとまる可能性のあるWeb日記でも、原則は同じだろう。 極端にパーソナルな誰が読むかわからないから書けないことはある けど、日記ではパーソナルな記述こそ主体である。
まあ、blogと日記はあくまでも便宜的な分類で、blogのような日記も、日記のようなblogもあり、 またその中間にも連続的に存在している(だろう)ことが話をややこしくしている。もっとも、 読者にとっては、重要なのは「読んで面白いかどうか」で、blogらしいとか日記らしいとかは、 面白さとはまったく関係ないのだろうとは思う。
で、今後私はどうするかというと、やはり、たあいのない日常の当たり障りのない記述と、 折々の興味あるネタに関する長めの考察の入り交じった「日記」を書き続けるのではないだろうか。 少なくとも書くことに飽きるまで。
4834030326 ここのところ息子が誕生日に買ってもらった4834030326を 毎晩1章ずつ読んで聞かせてやっている。 今はちょうど4834000354のまん中あたりだ。 全三巻のこの話、すごく有名なのに子供のとき読んだことなかった。
息子は保育園でなんども読んでもらったことがあるらしく、先の展開までぜんぶ知っているのだが、 知っていることそのものが嬉しいらしく、かえって喜んでいる。 そういえば彼はいつも読んだことがある絵本を借りてくるのだ。 安心感があるのか?
4834000109 しかし、最近の白眉はやはり4834000109だろう。 これまた子供のときに読んでなくて、子供に読んでやったのがはじめてだったのだが、 日常的な風景がいつのまにかファンタジーになってしまっている様子が心に残った。 積み木の船がごく自然に大海原に出帆してくじらをつかまえて帰ってくる話とか。 しかし、息子にとっては当然のようであまり感動していなかった。 そうか、彼にとってはこれこそが今生きている世界なのだな。 私も昔そうだったのだな。
同じようにファンタジーに迷いこむ絵本としては、 4834000508や 4834008738がある。 「てぶくろにクマがはいるかっ」とか「おふろにクジラがはいるかっ」とツッコミたくなるのだが、 そこが良いのだ。どちらも(私も子供たちも)大好きな絵本だ。
今日は米子の教会に訪問の責任。母の日に実家の教会に出席の割り当てがあるとは粋な計らいか。 お話のテーマは「個人的な啓示」。 先日のビデオ予約の失敗の件を導入にいくつかの聖句を引用して。
今月のLinux Magazineの原稿にも応用できそうだし、 Web日記は思ったより役に立つようだ。
教会が終わった後、実家によって母の日に感謝の気持ちを示すべく、 昨日用意しておいた花を贈る。喜ばれる。もっとも、手配をしたのは妻だ。 こうして1年に1度感謝しておくと、残りの364日良い思いができる…
なんてことは考えていないよ、決して。
子供たちはカレーを作ることによって感謝の気持ちをあらわしたつもりのようだが、 かえって親の仕事が増えてたような気がするのは内緒だ。
今回の米子への移動は、妻の軽自動車を使った。 久々のマニュアル車の運転にクラッチを踏むのが0.5秒くらい遅れたことが数度。
ずっとマニュアル車じゃないとダメだとか主張していた人間が1年やそこらでこの堕落ぶり。 恥ずかしい。しばらく慣れてくると「軽自動車はギア比が」などど考え出すが、 堕落した運転者にはそんなこと言う資格はありません(<自分)。
なひさんがYAMLなんてWikiページを用意してくださる。 要旨はここへのツッコミそのまま。
で、Wikiなので自分の意見を書き込んでおく。記録のためにここにもコピー。
まつもとからの意見
実際に比較しているのは
なんだよね。
実際、なひさんの意見はXMLについて無知な私にとって非常に参考になる。 でも、こんなことしてないで原稿を仕上げた方が良いな。
私の同僚たちは今日からXPを実践しはじめました。 ストーリー、タスクの抽出など、はたから見る限りは順調のようです。
今は4人でひとつのディスプレイをのぞき込む「カルテットプログラミング」を行っています (私がのぞきに行くと「クインテット」)。まさにエクストリーム。
Linux Magazine 7月号の原稿はさきほどしあがりました。
予告通り、タイトルは『XMLとYAML(その2)』。 この日記での議論もある程度反映したものになっています。 みなさん、ありがとうございました。
[ruby-talk:71112]などでSimon Strandgaardくんが要求していることが ずっとわからなかったのだが(お互い英語は得意じゃないし)、 しばらく彼のメールを読むうちにやっと分かってきた。
要するに彼はRubyインタプリタをC++プログラムに組み込むことを行っているわけだが、 その時に、$stdin, $stdoutなどに代入した効果をRubyの中だけで閉じたい、と考えているようだ。 これは
ということから来ているもののようだ。しかし、いくら組み込みだとはいえ、
stdinなどはプロレスプロセス全体でひとつずつしか持てない資源なわけで、
それをRubyの世界の中だけで繋ぎ換えるのは無理な話である。
彼にはあきらめてもらうしか。
しかし、それはそれとして、この議論は私には有意義であった。 つまり、Rubyに足りないと思われる点がいくつか見つかったからだ。
ひとつは、エラー出力のリダイレクトである。Rubyの通常出力(printやputsのデフォルトの出力先)は、 すべて、変数$defoutという変数に格納されたオブジェクトに対して行われる。 このオブジェクトは必ずしもIOである必要はなく、writeメソッドを備えていれば良い。 しかし、エラー出力に対しては問答無用でstderrに出力していた。 しかし、一貫性の観点や便利さから言えば、同様の仮想化が行われるべきだ。
ということで、新たに$deferrという変数を用意し、エラー出力はすべて、ここを通すようにした。 さらにwarnメソッドも新設した。その動作は
$deferr.write(s) $deferr.write("\n")
と同じである。
もうひとつは標準入出力を切り替えることのできるsystem関数である。 すでにOpen3というライブラリはあるのだが、これのあり方も含めて再考したい。
最後に変数$stdinなどである。現在はこれらの変数に代入すると内部的にreopenを行っている。 しかし、この動作がSimonの誤解を招いたと言う事実は否定できない。 むしろ、これらの変数はread-onlyにして、警告などを使って、 最終的にはSTDINなどを使うように誘導した方が良いような気がしてきた。
間違いを招くような機能はむしろない方が良いし、それを放置しないことが良い言語であり続ける秘訣だと思うのだ。 これを「broken window theory」と呼ぶ。
そういえば、Rubyを直したい点というのがもうひとつある。 正確にはひとつだけではないが、今日になって改めて思い出したものがひとつある。
それはメソッド結合である。モジュールをincludeしたとき、そのモジュール独自の初期化を行いたい場合がある。 そのような場合、現在のRubyならinitializeメソッドを呼ぶことになるだろう。 しかし、どのようなクラスにincludeされるか事前にはっきりとはわからないモジュールでは、 includeするクラスがinitializeでsuperを呼んでいないかもしれない。 そうするとそのモジュールのinitializeは呼ばれず、 オブジェクトは初期化されていない半端な状態で取り残されることになる。
superを呼ばなかったのがいけないんだ、と責任をユーザに押しつけるのは簡単だが、 多重継承に近いモジュールで呼び出し関係を維持するためsuperが必要か必要でないのか悩むのは、 プログラマの時間がもったいない。
他の言語ではこれらの問題をどう解決しているかというと、
こっちの方がスマートだ。
Rubyでもなんらかの方法で解決策を提供したいが、どのような機能、記法が良いのかは、 まだだいぶん思案しないといけないだろう。メソッド結合が良さそうなんだけど。
あるいは1.7から導入された define_method と同じような形で、 たとえば define_hook (あるいは define_advice) というメソッドを用意するのはどうだろう。
module Foo define_hook(:initialize, :before) { p 44} end class Bar include Foo def initialize() p 55 end end bar = Bar.new # => 44 # 55
が、before hookで44を出力し、initialize本体で55を出力するわけだ。もちろん、after hookも定義可能とする。 が、around hookはいらないだろう、きっと。
でも、define_method同様、いや、それ以上に醜いと言うのは欠点だ。
先日、正規表現の「$」が「改行と文字列終端の間」にもマッチするように変更したのに合わせて、 「\Z」も同様に「改行と文字列終端の間」にもマッチするようにしました。
Internet Watchの 検索エンジンの裏側という連載の第5回 で面白い記述があった。
blogってそういうものだったのね。
この定義は明確だ。この定義なら日記とは全然違うし、混乱することもない。 でも、それってやっぱり違うんじゃないかなあ。
これでは自分から情報を発信するタイプのサイトはblogと呼べなくなるんじゃないだろうか。 しかし、そのようなタイプのサイトがあるからこそ、 いわゆる「blog文化」あるいは「blog publicity」が成立すんじゃないかと思うんだけど。
昨日、メソッドフックについて書いたら、 akrさんからフォローがあった。
define_before_hook(:initialize){...} define_after_hook(:initialize){...}
とか
define_method(:before, :initialize){..} define_method(:after, :initialize){..}
はどうだろうか、という提案だ。フックの種類なんてbeforeとafterで十分だろうから、 これで良いのかもしれない。個人的には後者の形式は順序を変えて
define_method(:initialize, :before){..} define_method(:initialize, :after){..}
の方が良いとは思うけど。
もう一つ別の考えとしては、
def initialize__before(*args) ... end
と普通のメソッドのように定義するというものだ。あるいは名前は
def initialize:before(*args) ... end
のように普通の識別子でない方が良いかもしれない。
いずれの記法を選ぶにしても、現時点では効率的な実装方法が思いつかないという、 それはそれで大きな問題が残っているのだが。
ということで、$stdinなどをリードオンリーの変数にした。 最終的には、STDINなどの定数のほうを使うように仕向けたい。 やっぱり「$」は醜いから。
Dave Thomasが0201710897の新版を書いているらしい。
で、「いつfeature freezeするの?」って聞いてきた。 まあ、freezeしてないとドキュメント書きにくいからな。 前にも書いたようにfeature freezeはしたくないんだけど、 しかたがない。「1,2週で」と答えておいた。
ということで、決めた。来週末(5月23日ごろ)feature freezeしよう。 もっとも、これはインタプリタ部分だけで、 ライブラリについてはもうちょっと先になると思うけど。 で、このあたりで新しいpreview(えーと、preview3だな)を出そう。
とりあえず、彼には <URL:http://www.ruby-lang.org/ja/man-1.6/?cmd=view;name=ruby+1.8+feature> を紹介しておいた。
彼は日本語は読めないけど、コードは読めるので、日本語のページも結構参考にしているらしい。
0596002149 海外では0596002149の評判が良くないらしい。 いわく、
いえ、確かにその通りです。
まあ、著者も役者訳者も編集者も経験がないことを短い期間でやりとげたから、
という言い訳は一応あるのだが、そんなの自己満足だけで、
お金を払った「お客」には関係のない話だ。
もうしわけない。
そこで、どうだろう。現状の Rubyリファレンスマニュアル をベースに、まず、日本語の新版「Ruby in a Nutshell」を出版し、 それを英訳すると言うのは。
いや、それだとDave ThomasのPickaxeと正面衝突かな。彼との関係を悪くしたくないな。 だったら、英語は彼に譲って、日本語版だけというのはどうだろう。
calendar3プラグインを使ってみたのだが、エントリが有る日付がリンク色になってしまうのだ。 CSSはわからんのお。実用上問題はないけど。
追記: たださんに教えていただいて、対応できました。ありがとうございます。
B00006IZRF うちに帰ると、妻がレンタルビデオで『サイン』を見たと言う。 しかも、彼女の感想は「おもしろかった」というのだっ。 実はこの映画は去年国際線の機内で見ていて、個人的な印象は「最低」であったのだ。
夫婦でも感性の違うことよ。
んで、いろいろと感想を述べあった。彼女によると
という点が良かったと言う。私はだいぶ記憶が薄れていたのだが、 確かにそんな話もあったような。 そうだな、そこのところだけ取り出すとそんなに悪い話ではなかったかも。 少なくともクリスチャンにとっては。
なんか、トウモロコシ畑のミステリーサークルとか、なぞの宇宙人とか、 納得の行かないオチとか、つじつまがあわなかったり、 説明されずじまいのストーリーが鼻について、そういうところは記憶から抜け落ちていた。 エンジニアはそういう論理の破綻が目につくのだ(本当か?)。
一方、彼女の方は、私の言葉を聞いて、上記の「欠点」が気になり出したらしい。 あと、「牧師たるものが伴侶を亡くしたくらいで信仰を失うなよ」とも言ってたな。 私もそう思う。
結局、見た直後の印象は正反対で、意見交換によって感想がお互いに歩み寄った映画であった。 良かったのか悪かったのか。
しかし、この監督、この前の『アンブレイカブル』も最低だったと思った。 『シックス・センス』はまあまあだったけど。あれは原作がある(らしい)からかな。 そのまた前の映画もBSで見たような気がするんだけど、タイトル忘れちゃった。 そんなに悪くなかったように思うのだが。
昨日宣言したfeature freezeだが、 忘れないうちに検討項目をリストアップしておこう。
バグ修正
仕様検討
忘れたもの、落ちているものがあればツッコんでください。
予想以上に人が多い。80名ほどの出席だろうか。 で、「ユーザインタフェースとしてのプログラム言語」というようなネタで1時間ほど。 より正確には 「良いプログラミング言語をデザインする間で学んだ、良いインタフェースを作るための原則」 というような話題かな。 発表資料は近日公開。
発表の後、中小路先生が 「今年のSIGCHIのキーノートで『ユーザインタフェースの本質はEmotionである』との発言があったが、 私は昨年この話(SS2002)を聞いていたので、当たり前のことと感じた」とおっしゃっていたのが、 なんか自尊心をくすぐって、嬉しかったのだった。まあ、「インタフェースは気分」というのは、 ちょっと考えれば分かる「当たり前」のことかもしれないけど。
ただし、PR#231の修正には問題があり、あおきさんからパッチが提供されている。 [ruby-dev:20203]
jitterbugで残っているのは、
だが、これは鬼車の方に合わせてもらった方が良いと思う。 というのも、空パターンの繰り返しは
のいずれかの解釈になり、より自然なのは前者だが、実用的なのは後者だと考えるから。 鬼車がこれをマッチするということは、もしかして
と解釈してるのかなあ。
お昼過ぎに出雲空港に着く。機体はA300。第2便もエアバスになったのね。
午後は米子に。新しくできた讃岐うどんの店に。 話題の釜玉うどんを食べるが、予想通りというか、期待したほどではないというか。 夕食後、実家によってから帰る。
今日は岡山の教会。早朝、出発直後に後輪タイヤにネジがつきささっているのを発見して、動揺したりもするが、 タイヤ交換の後、無事に出発。
ツーリング日和のせいか、BMWバイクの集団、ハーレーダビッドソンの集団、競争用自転車の集団に遭遇する。 特に数十台並んだBWM軍団は壮観であった。 岡山はツーリングの聖地か。
最終的には4分の遅刻。4分で済んだのはさいわいと考えるべきか。 なんだかんだで、うちに帰りついたのは午後8時すぎ。疲れた。
これで抜けはないかな。
top_includeは現状では本質的には解決不可能なので、対応を止めちゃおうかなと思ってます。 Integer#gcdは他にリクエストがないので、このままなら採用せず。
Exception#initializeは効果がよくわからないので、現時点では保留。 pipe reopenとautoloadはなかださんが責任もって(?)コミットしてくださるなら、どうぞ。 あ、break/next/redo in condtionも同様。
String#=~は議論が必要でしょう。
Bindingのメソッドは実はlocal_variable_setだけが必要なのではないかと思ったりもします。 これも議論が必要。
block_passはこれからデバッグします。 実は修正した時点ですでにダメなケースがあるだろうなとは思っていたのです。
「本日のリンク元」でアンテナとそうでないものが混ざっているのが嬉しくない。 分離してくれるプラグインはないものか(他力本願)。
どこかの日記で分けられているのを見たような気がするのだが。
追記: disp_referrer2ですか。まずNoraを入れなくちゃな。
追記2: referer-antibot.rbがあれば、Nora不要なんですね。しかし、refererとreferrerが混ざってるな。
日本科学未来館は、昨年の情報処理学会オブジェクト指向シンポジウムや、 ソフトウェア科学会のガーベージコレクションチュートリアルの会場で、 そのとき見学した「インターネット物理モデル」にはいたく感動した覚えがあったのですが まさかRubyで動いているとは。
クマムシサイトでBioRubyのバナーを見つけた時よりびっくり感激しました。
1.8のリリースに向けて、本気になってきてます。
initialize_copy
cloneやdupがそのオブジェクト専用の状態をコピーするために呼び出す。 古い名前はcopy_object。initialize_copyはinitialize同様デフォルトでprivate。
multiple values for a block parameter
今まで不評だった
lambda{|n|p n}.call(1,2)
のようなケースに警告を出す。将来的にはエラーにしようかと。
というわけで、いろいろ非互換のある1.8仕様ですが、 皆の幸せのため、以下のような手順で行おうと思います。
で、長い長い1.7の期間の間に完全非互換で、かつ警告が出ないようなものがたくさん含まれているのではないかと思います。気が付かれた方はどうぞご一報を。
なぜクマムシを調べてたかって、そりゃ、もう今クマムシといえば、 NHK教育『なんでもQ』の『水の中の小さなクマ』や、4056018758 の『不死身の怪物!?クマムシ』でも取り上げられて、トレンド以外のなにものでもないでしょう。
150℃の熱さにも耐え、マイナス250℃の寒さにも耐え、真空中にさらしても大丈夫、 なんてタフでキュートなんでしょう。どこにでもいるということですから、 そのうち顕微鏡を手に入れて、クマのようにノシノシ歩く体長1mmの実物を観察しようと思っています。
わくわく。
今週と来週は教会の宗教講座(インスティチュート)の代理教師を仰せつかった。 範囲は「教義と聖約」26章から31章まで。 90分のクラスの教師は久しぶりなので緊張した。あまり充実したとは言えなかったように思うのだが、 とりあえずなんとかこなしたという感じかな。
「しゃべリッチ」というのはNTTコミュニケーションズの割引サービスのひとつで、 あらかじめ指定した2箇所の電話番号に対する通話が通常の45%から50%引きになるというものです。 ですから、県外通話先が限られている家庭ではお得になりますよ、ということです。 実際、私のうちも含めてそのような家庭は多いと思われます。 このサービスは県外通話のマイラインプラスをNTTコミュニケーションズに指定している場合には無料ですが、 そうでない場合には毎月200円の定額料が必要です。
先日、妻がNTTの電話営業を受け、「お得です」という言葉に負けて、 このサービスの申し込みを承諾してしまったそうなのです。 しかし、私は「きっと後で申込書を送ってくるだけだろう」と思って無視してました。
ところが、今日になって「サービス開始のお知らせ」なるハガキが送ってきました。 もう正式に申し込んだことになっていたのです。
予想外です。
実はうちは県外通話はフュージョンコミュニケーションをマイラインプラスに指定しているのです。 ということは、「しゃべリッチ」を申し込むと毎月200円引き落とされることになるのです。 しかもうちの場合、県外通話にはNTTコミュニケーションは使われませんから、 この割引サービスの恩恵を受けることはまったくないわけです。
にもかかわらず、「サービス開始のお知らせ」には
月額定額料: 無料 マイラインプラスの「県外への通話」区分で弊社からのご登録を解約された場合、 200円となります。
と書いてあり、あたかも解約と言う積極的なアクションを起こさない限り、 現状では無料であるかのような表現です。 現在マイラインプラスがNTTコミュニケーションズでないヒトが 「しゃべリッチ」割引を申し込むとは考えていないせいでしょう。 これでは、もし自分のマイラインプラスの加入状況に関心がない、 あるいは忘れてしまっている人は、この問題に気がつかない危険性があります。
妻は電話営業のヒトから200円の定額料のことを告知されていませんでした。 このヒトは、うちがNTT以外から電話の請求書を受け取っていることを聞き出していますので、 うちのマイラインプラスがNTTコミュニケーションズでない可能性について当然配慮すべきだったはずです。
さっそくNTTコミュニケーションズに電話して、告知義務に違反すると指摘して解約しました。 また営業のやり方に対して抗議しておきました(効果はないでしょうけど)。
もちろん、NTTに悪意があったとは考えていません。 ただ単に(おそらくは社外の)電話営業のヒトが、 マイラインプラスへの加入状況を確認することを怠ったという ヒューマンエラーだと思います。
それに加えて、NTTコミュニケーションズの思いこみにより問題が見えにくくなってしまっていたのでしょう。
というような、単純な「思いこみ」が重なって、 予想外の(悪い)状況が発生する典型例ではないでしょうか。 インタフェースやひいてはヒューマンエラーに関心を持つものとしては興味深い事例です。
いや、待てよ。
もし、誰かがこの問題の見つけにくさに気がついて、悪意を持ってこの種の営業をしたとしたら、 気がつかずに毎月200円引かれる人はかなりいるでしょう。 実際に割引は行わなれないわけですから、この額はまるもうけです。 ひとつひとつは小さな額でもたくさんあつまると結構な稼ぎになるような。
いやいや、考えすぎに違いない。
LinuxWorld Expo/Tokyo 2003の特別基調講演より。
経済産業省、商務情報局情報処理振興課・課長補佐、久米 孝氏による調べでは、 日本発のオープンソースはわずか42件なのだそうだ。「これは非常に少ない件数だ」などと評論してくれてます。
先生っ、この42件にRubyは入りますか?
mod_rubyやerubyやerbやtDiaryやRuby/GtkやRuby/QtやSOAP4Rやxmlscanや、そのほかもろもろは?
日本発のオープンソース(ソフトウェア)の基準がなんだか知らないけど、 「海外にもユーザがいる」という条件をつけても、Ruby関連だけで40やそこらじゃきかないと思うんだけど。 これって自己憐憫とか卑下とかいうヤツ? それともFUDの一種?
確かに、 考えてみれば「1万人ミスしてもせいぜい200万」ですものね。 個人なら大きいけど、大企業にとってはゴミのような金額ですね。 どう見ても私の考えすぎでしょう。
前の文では書きませんでしたけど、妻が電話営業を受けてから、 マイラインプラスの申し込みのダイレクトメールが2度ほどきましたから、 営業のヒトの本当の意図は
というものだったんでしょう、きっと。
残念なことに妻には伝わってなかったけど。 現在マイラインの変更は有料(800円だっけ)だということも、 しゃべリッチの「お得」で変更料を相殺するにはうちのペースでは何年もかかることも、 告知されてなかったけど。
単なるミスですよね。
FUDとはFear(恐怖)、Uncertain(不確実さ)、Doubt(疑い)の略である。 つまり、根拠レスな主張を大声で述べることにより顧客の不安をあおり、 相手に流れることを妨げようというマーケティング戦略である。 追い上げを受けている陣営が新興勢力を振り払う時に有効だと考えられている。
さて、「日本発オープンソースは42件」という言明がFUDだとすると、 その目的はなんだったのだろうか。久米氏はマイクロソフトではないし、 むしろIPAを通じて(制約は多いものの)オープンソースソフトウェア開発を支援しようとしている*1、 いわば「味方」である。彼にはオープンソースを迫害する理由がない。
その彼が、必ずしも事実でない「日本発オープンソースの弱み」を強調する目的とは一体なんであろうか。 考えられるのは
1番と3番の合わせ技あたりがかなりありそうなんですが、 実際のところどうなんでしょう?
*1 うちの会社も応募しました
朝日新聞の記事によると 経済産業省はこの夏「ハッカーの甲子園」を開くのだそうだ。
で、そのハッカーの甲子園では
だそうだ。
ここで疑問がある。この「ハッカー」はいわゆるハッカーなのだろうか。 つまり、我々が言うところの「ハック」するところのプログラマである「ハッカー」、 あるいは言葉を変えれば「ハッカーはクラッカーではない」の「ハッカー」なのか、 それとも、最近指摘するのもあきらめそうなマスコミ用語としての「ハッカー」、 すなわちシステム侵入者としての「ハッカー」なのか。
このハッカー甲子園(正式名称は「第1回セキュリティー甲子園」らしい)の競技内容がシステム侵入である以上、 この「ハッカー」は「クラッカー」と同義でシステム侵入者の意味であることが推測できる。
ところが、一方、 朝日新聞の当該記事には、
とあり、経産省もこの大会の目的として
を掲げているらしいので、集めたい人材は「破壊活動に長けた人物」ではなく、「優秀なソフトウェア開発者」としてのハッカーのようにも思われる。
これは一体どういうことなのだろうか。
「ハッカー」と「クラッカー」が混同されているのは周知の事実だが、 そのねじれが生んだ偶然のいたずらなのだろうか。 あるいは、高いシステム侵入能力を持つ人間は、情報を集め、 実践する能力と知識の故に優秀なソフトウェア開発者になれると考えたのか(スクリプトキディーは優秀な開発者にはなれそうにないけど)。
はたして、システム侵入能力の高い人物は、ソフトウェア開発において「優秀な人材」たりえるのだろうか。
いや、待てよ。
という流れが考えられないだろうか。なんとっ、恐るべしニッポン、恐るべし経産省っ。
いやいや、考えすぎに違いない。
例の「42件」についてスラッシュドットからリンクされたせいで、 アクセス数が10倍くらいに伸びた。さすがスラッシュドット効果。 しかし、本家slashdotのように、リンクされたせいでアクセスが集中しダウン(→slashdotted) というほどではないようだ。
しかし、このネタは「あれ、ちょっと少ないんじゃない」程度のことで、 本当に書きたかった(これから書くつもりだった)のは、
などだったりする。前者については、八田さんのjapan.linux.comの記事で扱われてしまったので、あまり書く事もないかもしれないが。
今日は教会のホールで知人の結婚披露宴だったのです。
会場で手持ちぶさたにしていたら「機械に強そう」という理由で(本当はそうでもないのですが)、 ビデオ撮影係に任命されてしまいました。 しかし、機械操作はともかく、ビデオ撮影の才能はないのです。自分たちの新婚旅行でも、 私が撮ったところは構図もフレーミングもダメダメで、画面が揺れまくっていたのでした。 妻が撮ったところの方がずっとよくて、旅行の後半はずっと彼女に任せっきりでした。 あれからずいぶん経ちましたが、改善されていると考える理由はないのですが。
撮影したビデオを確認する暇はありませんでしたが、 見てると船酔いしそうな画面でないことを祈るだけです。
今日は出雲支部の支部大会ということで、出雲訪問。
ずっと外回りばかりで、そろそろ松江に出たいんですが。 えーと、スケジュールを確認すると、来週は松江ですか。
先週は1.8の準備で忙しかったし、結婚披露宴の裏方などのせいか、 かなり疲れてしまい、うちに帰ると寝入ってしまった。
まあ、昼寝も安息日にふさわしい活動のひとつだそうだが。
葛藤を感じつつも、利用しているAmazonだが、 やはり機能的には一番充実している。
中でも「おすすめの本」という機能は、なかなか面白い。 自分が買ったり興味を示した本から連想される本を紹介してくれるというものだ。 誰がどの本とどの本を買ったというような売り上げデータベースの一部を見せてくれているようだ。 やはり、実際のデータは強く、なかなか面白い本を紹介してくれる。
しかし、中には変な紹介もある。 先日勧められたのは4797323256。
「ワタシはゲームには興味がないのに」と思い、「おすすめの理由」を見ると,
この商品が購入または評価されていたからです…
0471941484
なんじゃそら。なんでガーベージコレクションの本との関連づけが。 共通点は...マニアックなところ、とか。
懸案のBlockとProcの分離をコミットしました。 かなり大きな変更なので非互換が出るかもしれません。当面は要注意。
変更の要旨は以下の通り。
それに伴い、以下の変更も行いました。
使ってみてくださいませ。
これが落ち着いたら、1.8.0のインタプリタ本体には大きな変更は行わないと思います。 ただ、<=>の例外の扱いとか、まだ考えなくてはいけない点もいくつか残ってますが、 まあ、些細な修正で終わるでしょう。
「その本を買って、さらにゲームの本を買った人がいたのでしょう」というのは まさにその通りなのでしょうけど、
という点をことさらに取り上げて、笑い飛ばそうという意図だったわけで。
まあ、説明が必要という時点で外してますな。
とはいえ、こういう現象が出るってことは、まだまだサンプル数が少ないってことなんですかねえ。 日本最大のオンライン書店のはずなのに。
いや、待てよ。
特定の分野の書籍の数には限界があるわけで(たとえばRuby関連書籍は20冊強しかない)、 買った本、興味を示した本と強い相関を持つ本だけを「おすすめの本」とするならば、 そのリストに登場する書籍も非常に限られてくる、偏ってくる可能性がでてきます。
これでは「書店店舗でたまたま目に入り、興味をもって購入した」という購買行動に相当する行為が、 Amazonでは発生しにくくなります。売り上げという点からは、 事前に買おうと思ってなかった本を思わず買ってしまったというパターンはぜひ欲しいでしょう。
そこで、 少ないサンプルを強調して、ときどきこうして全然関係ない書籍を「おすすめリスト」に加えることにより、 思わぬ売り上げを期待しているのではないでしょうか。恐るべしAmazon。
いやいや、考えすぎに違いない(このパターンは3度目か)。
世の中にはメイド喫茶・コスプレ喫茶などというものがあるのですね。知りませんでした(世間知らず)。
とするともしかして先日の披露宴で女の子たちがメイド服を来ていたのはそういう流れだったのでしょうか。 確かに彼女たちの友人にはコスプレする人がいたような。
メイドというのは、女性を隷属させたいという男性の願望を含んでいるようで、 手放しで肯定できないのですが、実際にメイド服を着ていた彼女たちもまんざらではないようでした。
そうするとその趣味の人たちには、メイド服の若い女の子が給仕し、 最後にはその服のまま会場を掃除していたあの披露宴はたまらないものだったのでしょうか。 なんかヤダなあ。会場にはその趣味を理解する人はひとりもいなかったようでしたが。
公開を予告していたが、とうとう公開した。
http://www.rubyist.net/~matz/slides/ipsj-hi103/index.html
まあ、どこかで見たような資料ではある。
先程公開した資料の中で、 「関西O+Fで脳力(ブレインパワー)だったところが、ストレスに変わっていますね」 という指摘はなかなか鋭いですね。
今回はユーザインタフェース研究会でしたので、より平易な表現に変えました。 ストレスを解消するためには脳力を消費するので、このふたつはほぼ同じ曲線を描くはずです。
なんて、ヨタ話もこんな風に解説するともっともらしく聞こえるかも。 念のため断言しておくと、「脳力」説には私個人の直感以外の根拠はゼロです。
そして、ええ、C++のグラフではちゃんと笑いが取れました。
オモイカネの大熊氏から「日本発オープンソースは42件」ということについて 反論[PDF]が出た。
が、私に限って言えば、 久米氏の講演には「42件」という数字だけでその基準は明らかになっていなかったことだけをとりあげていたので、 別に反論していただく必要はない。
疑問を呈した時点で、 大熊氏の元の資料の存在は知らなかったわけだが、そちらの方を読む限り、基準は明確になっている。
という基準を満たすのが、氏によると42件なのだそうだ。
まあ、基準が明確になってめでたしめでたし、としたいところだが、いまだに引っかかるところがある。
この4つの基準のうち、「オープンソースソフトウェア」を除いた3つに関しては、 大熊氏が恣意的に決めたものであるが、もっとも目的にかなった数字を出すためにどこかで線を引く必要があるということで、基準が明確である限り、受け入れることに問題はない。 問題にしていたのは、基準が明らかにされないまま「42件」しかないと断言されたことなのだから(そしてそれには大熊氏には責任がない)。我々が少ないと感じたのは、我々は「一定規模」とか「良く使われている」とかの基準を共有しなかったからに過ぎない。
5000行や「よく使われている」にはそれほど意味はないと思うけど、それは立場の違いということで。
どうしても無視できない問題はこのリストに「オープンソースソフトウェア」でないものが含まれている点だ。
その点について大熊氏も「反論」の中で
と述べておられるが、これは見当違いである。 繰り返しになるが、少ないと思ったのは「5000行以上」で「ディストリビューションに含まれる」という基準を共有していなかったからで、それが明確になった後では数が減るかどうかはもはやどうでも良い。 むしろ適切な基準が適用されているかどうかだけが重要である。
大熊氏はこの資料について
と述べておられる。
数を数えることを目的としなかった資料の中の数字が講演で引用されたばかりに独り歩きしてしまったことは、 大熊氏にとっても不幸だとは思い、同情もするが、 「発想を広げていただくため」だろうがなんだろうが、 誤解を生まないためにOSIが苦労して明確に定義した「オープンソース」という単語をないがしろにするのは、 OSIにも個々のオープンソース開発者にも失礼である。
たとえ基準の中で
と定義していたとしても、それはやはり問題だと思う。
「フリーソフトウェア」あるいは「自由なソフトウェア」ほどではないにしても、「オープンソース」という単語も また思想や信条を反映したものであり、その思想信条を表現するために定義されていることを忘れてはいけない。 その定義を自分勝手に改変してしまうことは 他人の思想や信条を大切にしない行為であり、それしかよりどころのない 「オープンソース」や「フリーソフトウェア」活動にとって致命的な問題であると考える。
さらに
という発言からは、「オープンソースかどうかなんてどうでも良い」という大熊氏の考えがよりはっきりうかがえる。 「5000行」、「ディストリビューションに含まれる」という恣意的な基準を導入しておきながら、 結果の数が期待より少なければ、そちらの基準を変えるのでなく 「じゃあ、オープンソースじゃないけどこれも足しとこう」 ということになる発想はオープンソースの定義を軽んじていると言われてもしかたがないと思う。
氏はVzエディタでかつて実現されたようななんらかの「オープンソース的なもの」のイメージをもっておられるようだが、 それはやはりオープンソースではない。別のものには別の名前が必要だろう。
もちろん、政策を語る時に重要なのはライセンスではなく、経済効果、産業競争力であるという考え方は 理解できるし、
という言葉が間違っているとまでは言わない。
しかし、オープンソースの定義やその背景の思想を無視してしまえば、 後に残るのは単なる「無料ソフトウェア」でしかない。 個々の開発者が共感し実践している思想抜きでオープンソースが存在できるかといえば、 ほとんどのケースで「否」なのではないだろうか。 オープンソースあるいはフリーソフトウェアの思想を背景とする開発者なしに単体で 「ネットワークに密着したソフトウェアの開発・流通・マーケティングの構造」 が成立するわけではないのだ。
ということならば、「OSIの定義を厳密に適用することには意味がない」とは言えないのではないだろうか。
むしろ、「意味がない」と言えてしまうのは、オープンソースに対する表層的な理解から来るのではないか、 ということを危惧してしまうのだ。
我々フリーソフトウェア開発者が個々のユーザから対価をもらわず日夜開発を行っているのは、 自らの思想の実践であり、ソフトウェアの自由を実現するためである。
ユーザには我々の思想をないがしろにする自由があるのだろうか。 たぶんあるのだろう。しかし、少なくとも私は愉快ではない。
東京に行ってIPAヒアリングに参加する。 予定された時間を大幅にオーバーしてプロジェクトの目的や計画について説明を行う。 実際に採択されるかどうかは結果の公表待ちということになる。
オープンソースで食べていくというのは、それはそれは大変なので、 公的な支援を受けられるということであれば、それが不当なものでない限り、 喜んで受けようと思うのだ。
しかし、東京という街はなんでこんなに歩かせるんだ。 日帰りのスケジュールもあって大変疲れた。あさっても東京なんだよなあ。
今朝、書いた
という表現に関連していろいろとツッコミをもらう。
要約すると「私は自由を実現するためにフリーソフトウェアを書いているわけではない」ということのようだ。
いや、まあ厳密に言えば、全員が同じ動機でフリーソフトウェアを書いているなんてことはありえないので、 直接的な動機はさまざまあると思う。ちょっと考えただけでも
などなどが考えられる。
しかし、考えてみてほしい。
これらの理由のうち、「ソフトウェアの自由」に間接的なりとも関係しないものが存在するかどうかを。 過去のフリーソフトウェア(オープンソースでもいいけど)という「実績」があればこそ 公開する気になったんじゃないだろうか。
「無料でソースコードまで手に入るソフトウェア」は、その利用者にとってはこの上なく都合が良いだろう。 利用するにあたっては妙な制限は少ない方が良い。思想や信条なんて邪魔なだけだ。 そう思う人もいるだろう。気持ちはわかる。
しかし、思想や信条を手放してしまえば「ソフトウェアの自由」は危険にさらされるのではないか、 思想や信条を抜きにして利用者の都合ばかり考えていては、 フリーソフトウェアの供給は維持できないのではないか、 私はそれを危惧するのだ。
「ソフトウェアの自由」を手放す時、 フリーソフトウェア開発者はソフトウェアをタダで産み出す便利な存在に 成り下がってしまうんじゃないだろうか。今でもしばしばそう思われているのに。
我々は搾取の対象ではない。
これは杞憂だろうか。
『サイン』の次に妻が借りてきたのは『B00006RD6X』だった。 それは私に対する挑戦かっ。あらかじめサイテーだって言ったじゃん。
で、感想を聞いたら、
だって。
いや、確かに『スパイダーマン』はマンガだ(言うまでもなくアメコミ原作だし)。 普通の高校生が遺伝子操作されたクモに噛まれて超能力を身につけるなんて 「そんなことあるかよっ」とツッコミをいれたくなるような話だ。
しかし、しかしだ、それと
ようなツッコミたくてもツッコミようがない映画と一緒にするのはマンガに対して失礼だというものだろう。 『シックス・センス』のようにラストのどんでん返しを狙ったのはミエミエだけど、 オチは少々意外だったのは確かだが、私にはおもっきり外したように感じられたなあ。
大傑作だとは言わないが、すくなくとも『スパイダーマン』の方がエンターテインメントに対して真摯だ。
もっとも、妻はマンガを軽蔑してるから、無理もないのかもしれないけど。
そんな彼女が映画館に『スパイダーマン』を見に行った理由は謎だ。 しかも、面白かったって言ってたよなあ。
あまり戦線を拡大しても疲弊するだけなので、まず私の意見をまとめておこう。
私は「OSIマンセー」*1ではないと思っているのだが、用語の定義についてはこだわる。 定義が違ったままでは対話が成立しないからだ。 そして「オープンソース」という用語についてはきちんとした定義が与えられており、 それに従わない(≒合意を破壊する)のは対話を拒否することを意味しかねないからだ。 自分の意図を正しく伝えたければ、自分勝手な用語の定義を用いるべきではない。
オープンソースという言葉について誤解する人(あるいは誤解したい人)はいると思うが、 それはオープンソースという言葉の定義を好き勝手にしてよいという理由にはならないはず。 定義を知らない人には教えれば良いだろう。間違えた人には諭せばよいだろう。 そして、定義をねじ曲げたい人には抗議するべきだ。
オープンソースの定義は客観的なものだ。 「思想が入っているからオープンソースとは呼ばない」というのは無意味だ。 あるソフトウェアがオープンソースかどうかは、 そのソフトウェア(のソースコード)をどう扱ってもよいかということ(つまりライセンス条項) から客観的に決められ、開発者の意図や思想とは無関係である。
一方、フリーソフトウェアの方はちょっと思想が入っている。 が、フリーソフトウェアは自動的にオープンソースになるようにOSDは定義されている。
ストールマン的には大違いであろう。 彼は「フリー(自由)」という言葉を手放すことは危険だと感じているからだ。 また、「オープンソース」という単語が利用者だけに都合が良い「無料でソースが入手できる」ことを 意味して使われるようになることを彼は危惧していた。
私は今までそれほど心配していなかった。OSDの定義を使う限り、
オープンソースという単語を使ってもソフトウェアの自由は保護されると思っていたからだ。
だから、「フリーソフトウェア」という言葉を使っても、「フリーソフトウェア」「オープンソースソフトウェア」という言葉を使っても、
結局は同じだと思っていたのだ。「無料」と誤解されるよりはずっといい、と。
しかし、この言葉が使われるようになって数年、いまだにこのようなことをわざわざ説明せねばならないようでは、 彼の危惧が当たっていのではないかと感じる。
あなたは本当にソフトウェアの自由はどうでもよいのか。
あいかわらず、そんなものはごく少数だと思っている。 実際に自由を実践していない、ソフトウェアの自由なんかとはいかなる形でも関係のない、 「オープンソースソフトウェア」が無視できない数あるというのであれば、報告していただきたい。
そのようなものがないのであれば(ストールマンの危惧を別とすれば)、 フリーソフトウェアとオープンソースソフトウェアを区別する必要はないだろう。
ただ、「フリーソフトウェア運動」と「オープンソース運動」はまったく違うものであり、区別すべきだ、 ということは付け加えておこう。
どうも「思想」という言葉は忌避すべきものだととらえている人が多いのではないかと感じられる。 戦後日本の悪癖だろうか。って、自分自身が戦後日本の申し子のようなものだが。
しかし、人間は思想なしで存在することはできない。 本当に思想がないというならば、それは考えないということである。 ということは「ノンポリ」さえ思想である。
であれば、「思想」という単語に過剰反応するのは無意味であろう。 あと、「宗教」もそうなのだが、これについては今日は触れない。
*1 「OSIマンセー」ってOSI絶対主義ってことですかね
もはや私は「42件」に興味はない。たださんの日記の記述で十分だし。
これからは6月の討論会に向けて
などのテーマについて考察していきたい。
まず、「作業メモとか考えた事とか(5月)」が 参考になるだろう。
ぶじに開催されました。「10年後も通用するソフトウェア技術者になるには」とかいうような テーマでしたが、自分自身が10年後も通用するかどうかもわからないのに、えらそうなことは言えないなあ、 と思いつつ臨んだのですが、なんか思いっきりえらそうなこといってたような。
会場にいた、咳さん、たださん、きたさんをはじめとする皆さんはどのように感じられたのでしょうか。
<URL:http://capsctrl.que.jp/kdmsnr/diary/?date=20030530#p09>に良いまとめがあります。
そうそう、私と斎藤さんって180度方向性が違いますよね。 片方はエンドユーザとサービスだけに関心があり、 片方は技術の深いところにどんどん潜っていっちゃう。
言えることは、
ってことですかね。お金が要らないわけじゃないんだけどなあ。
APSLがありましたね。 私は客観的に判断できるオープンソースの方向性も好きなのですが、 APSLのようなものを許容するのは「OSDのバグ」のように感じているせいで、 無意識に無視していたのかもしれません。
あんまり良いことではありませんね。どう考えるべきなんだろう。
オープンソースはフリーソフトウェアと同じものを違うアプローチで表現しようとしてるが、 まだ、完全には表現しきれてないと考えるか。 いや、本当にPerensやRaymondがそう思ってるかどうかは未確認だけど。
なんとこの季節に山陰直撃コース。帰れるかな。
東京の神殿に行きました。あやうく遅刻しそうだった。
田舎の人は、いつも車で移動するので距離だけで判断するのですが、 都会では駅まで歩いて、電車を待って、駅から目的地まで歩くという手順があるので 思ったより時間がかかるんですよね。
結局タクシーを使ってしまった。思わぬ出費。
結局出雲便は欠航しました。どうやって帰るかなあ。
結局、新幹線+特急で帰りました。1時間のフライトで済むところが7時間近くかかりました。 疲れた。台風なんて嫌いだ。