某日記

(中期)

平成18年12月11日(月曜日)

一つの話

新しい OS が出るとえてしてトラブルに巻き込まれるものだが、ここでトラブルに巻き込まれた一つの例について話をしよう。

そのアプリケーションは 10 年前に販売を開始してからバージョンアップを重ね、今でも売りつづけているロングセラーのソフトウェアだが、まだそれなりに売り上げは出ているものの、パッケージソフトウェア衰退の並には抗えずにチームは縮小傾向。できれば余計な手間は掛けたくない。そんな状況で新しい OS が発表され、β版、 RC1 、 RC2 とリリースが刻々と近付いてきた。しかし、アプリケーション自体が枯れているので新しい OS でも動くであろうとタカをくくって RC1 や RC2 でのテストをしていなかった。

さて、新しい OS が発売寸前になって開発者向けにリリースになった。ここでようやく重い腰を上げて、こちらもアプリケーションの次期バージョンに合わせて新 OS 対応と謳いたいと思い立った。早速開発者向けプレビューを入手してそのアプリケーションをテストしてみたところ……案の定動かない。これはマーフィーの法則によって約束された振舞いである。

これは、該当 OS の開発版で一度でもそのアプリケーションを動かしてみようという気になっていれば避けられた事態であった。実はチームが縮小傾向とはいえ、マンパワーが足りないということはないのだが、余力のある人間のモチベーションが最低なので、自分の仕事だと思っていること以外にはあえて手を出さないのである。その人間は未だに開発要員であって、サポート要員やテスト要員としての役割を明示的にアサインされたわけではないから、これは間違いではない(しかしながらこれを「間違い」「悪い」と決めつける経営者とかその幇間みたいなのは多いが……少なくともその善し悪しは状況による)。こういう場合、適切にそういう役割を空いている人間にアサインするか、チームの人間が自発的にそういう役割を買って出るようにモチベーションを高めるか、いっそ人間を取り替えるのが組織の役割であって、それができない組織はダメなのである。

今日

そういう感じでお仕事。

書評「福知山線5418M 一両目の真実」 - 6 ページ目 の次の部分はいただけない:

原らは、線路を広げる資金があるならば、狭軌のままで全国隅々にまで鉄道を敷設することのほうが先決だと主張したのだった。自らの地元に鉄道を呼び込みたいという議員らの利益誘導への願望が、より安全な標準軌へという動きに勝ったのである。
まるで当時の議論が安全性のために改軌するか否かという話であったかのように読めるけれど、そんな事実はない。こういうのを我田引鉄というのだ←違う。後藤新平とか軍部が改軌を支持していたのは、幹線における輸送力の強化と大陸との共通化が目的であって、安全だからそうしようと考えていたわけではない。もちろん「もしそこで改軌していれば」という点については間違いないけれど、当時の感覚として「狭軌が安全性を犠牲にしてる」なんて誰も思っちゃいなかったんだから、そんなことを言っても無意味。だから、たらればってのは基本的に無意味か、あるいは有害なんだってば。

しかしながら「どちらかといえば標準軌の方が安全である」という事実は知っておいて損はないし、この件に関してはむしろ、関西私鉄とか、あるいは特に京急の保守的姿勢をポジティブに評価するに留めておくべきだろうな。消されちゃったので Web Archive からだが京浜急行の先頭電動車編成について/丸山信昭(IE で見えないけど)とか。

いっそ我田引鉄で全国津津浦浦ミニ新幹線にしちまえばいいんじゃね?(ぉぃ

あの話。モダンの帰着の一つが正義であれば、ポストモダンは正義を否定したがるわけだ。なんか納得した。

めいすやんことまつやんで盛り上がる VIPPER 達 - 盛大に肩が赤い。

大日本帝国憲法が残した悪しき伝統の一つは、憲法というものを「不磨ノ大典」と看做すことそれそのものかもしれぬ。

平成18年12月13日(水曜日)

Version 1 までなら誤射かもしれない

ウィニー開発者に罰金150万円の有罪判決 京都地裁 - さもあらん。

「新技術の開発、どうして罪に」ウィニー判決受け被告 - 「不当判決」ってのはサヨクさんみたいにうさんくさくなるから止めれ。というか、やっぱり巻紙に毛筆でないと風情がないよね。

「ウィニー」裁判、判決要旨 - 「ソフトウェアを作って配ったこと」が犯罪行為だとは言ってないので脊髄反射しないように注意。要約すれば「Winny を作って配ったことによって大きな社会的影響が生じていることを認識していながらそれを容認し、対策を取ろうとせず、それどころか新しいバージョンを開発した」ことをもって犯罪行為だとしている。

少なくとも不当というほど不当でもないし、被告の言うほど基準が不明確ということもない。もちろんグレーゾーンの幅が広いのは確かだろうが、明確に白となる行為と明確に黒になる行為の区別は付く。被告側の言い分は「ソフトウェアを作って配ったこと」と「それ以上のこと」をごっちゃにしていて見苦しく思う。

ところで「態度が気にくわないから有罪にされた」というような考えをもっている人がいるかもしれないが、事実認定が一切そういうことに左右されていないということに注意。むしろ首尾一貫「著作権違反を促すような積極的意図があった証拠はない」としてる。

いずれにしても、この事件に於ける論点はむしろそういう行為が幇助を構成するのかどうかという成否の方にあるべきじゃないのかねぇ。

この判決の影響は、一方で、確かに危惧すべき部分があるのも確か。被告側が「ソフトウェアを作って配ったこと」と「それ以上のこと」をごっちゃにしているのと同じように警察や裁判所の(あまりこの問題に明るくない)当直判事がこの点をごっちゃにしないとも限らず、確かに裁判の場に立てば白黒が明確になるのだとしても、現実問題として逮捕されるリスクを多めに見積もらなければならないということになるかもしれない。

結局、この裁判そのものの有罪無罪はどうでもいいし、いつまでも拘泥すべきではなくて、むしろこういう事件が生じたということが適切な法整備が必要だということを明らかにしたという点で意味があったと見るべきではないかのう。あと、技術屋がいつまでもサヨクじみた駄々っ子では困る、というところか :-p

今日

Any Key - 馬鹿が出たぞー。

殺人予告 - 誰か保護してあげてください。

Fuzzy Zoeller Amazing Hole In One - 何このゴルフィンググレイツ。

今日の wikipedia: 旧暦2033年問題 - 旧暦はしばしば破綻する年があって、直近が二千卅三年。

平成18年12月14日(木曜日)

今日

私は不思議に思うのだが、裁判の勝ち負けなんてのは結局は法を取り扱う技巧の問題なのであって、それ以上でもそれ以下でもないのに、なんで「こんな判決はソフトウェアの進歩を阻害する。だから不当だ!」みたいな意見を言う人がいるんだろう。

結局日本という国が法治国家である以上、社会的に困った判決が出るようならもうそれは立法の出番なのよ(ここで「いやまだ一審なんだから控訴すれば」とかそういうつまらん茶々を入れないように)。 結局この裁判が最終的に無罪と確定しても、「不明確な基準」とやらで白か黒かが決まるんなら、別のソフトで逮捕されるリスクは大して変わんないんだぜ。こんな裁判にいつまでも拘泥してもしょうがないと思うんだがなぁ。

少なくとも「この裁判の戦いかた」と「この裁判を受けてどうすればいいか」というのはまったく別々に論じるべきであって、基本的に前者は当事者以外にはどうでもいいことだから、この裁判に危惧を抱く外野の人間は後者に注力すべきではないかと思う。

エクストリーム・アイロン掛け - この手のもので主将が知らないというのも珍しい。 エクストリーム・アイロン掛け エクストリームスポーツ

夜。言葉の独り歩きが面白くなってまいりました。注意深い読者は、今年流行ったとある造語がこの日記で一度も使われていないことに気づいているはずで、もちろんそれは意図的なものです。私とオフラインで会えるほど仲良くなると、そういう「この日記に書かれないようなネタ」についての私見が聞けます。

某所を見て気になってる人のためにリンク: マンガ蟹工船 / 小林 多喜二, 藤生 ゴオ - 大して長くないんだから原作で読めよ :D

夕飯ついでに某 blog についての打ち合わせなんぞを。何のひねりもなくただ分量だけがあるというような体のあの文章に過分な評価を頂いて恐縮しきり。

平成18年12月15日(金曜日)

昨日

査収物(まだ読んでない):

よつばと!(6) / あずま きよひこ

School Rumble(15) / 小林 尽

ケンコー全裸系水泳部ウミショー(4) / はっとり みつる

となりの801ちゃん / 小島 アジコ

今日

査収物(まだ読んでない):

ラズ・メリディアン(2) / 結賀 さとる

レモネードBOOKS(2) / 山名 沢湖

DVD - きみたちは「クオリティの上昇が必ずしも売り上げにつながるとは限らない」という現実を知ることになるだろう(ぉぃ

ところで、キャベツのリアルさは増したかもしれないが、絵面としてはまだまだ全然ダメで、これじゃあせいぜい切れて豆腐くらいなもんだろう --- いや豆腐だってこんな不自然な握り方では切らんけど……普通は人差指の第二節ないしは第二関節と垂直に刃が向くように握るので、普通の握りかたで手首がこういう向きだと刃が横を向いちゃう。ましてやキャベツくらいの固さのものを切るときは、肘から第二関節までを一直線上に並ぶようにして、肘の上から刃の上に向かって体重をかけるようなイメージで行かないと切れない。

だいたい、包丁をこういう風に腹の前でヘソとほぼ垂直に構える時はだな、右手はまあこれでいいとして、左手の手の平を柄の尻に添える。このとき、力が逃げないように手首の近くに柄の尻が当たるようにする。これが基本姿勢。で、いよいよ料理の方法だけれども、まずターゲットに気づかれないように 5m くらいのところまで近付いて、物陰からやおら飛び出し、目の前にいる組長だか若頭だかに向かって「コラァ◯◯!! テメエのタマぁ取っちゃる!!」とか叫んで怯んでるところに腰からぶつかっていくもんだぜ……ゴホン、せっかく直したことをアピールするなら、人物も「キャベツくらいの固さのものをちゃんと切れる姿勢」にしよう。

ATSミス防止で駅改造へ - 三月までに突貫工事で北宇智駅を移設してスイッチバック解消。消されるだろうから転載:

ATSミス防止で駅改造へATS=自動列車停止装置のスイッチを入れ忘れたまま電車を走らせるミスが今年相次いだ奈良県五條市のJR和歌山線の駅で、ミスのきっかけとなったスイッチバックと呼ばれる構造をなくすため、駅を移設する大がかりな改造工事が行われることになりました。
改造工事が行われるのは、奈良県五條市にあるJR和歌山線の北宇智駅です。
この駅は、蒸気機関車が走っていた時代のなごりで、構内に入った電車がいったんバックして引き込み線に入った後再び前に進む、スイッチバックと呼ばれる特殊な構造になっているため、運転士が車両の前後の運転席を2度にわたり移動する必要があります。
その際、運転席のATSのスイッチを入れ忘れたまま電車を走らせるミスが今年3月に2回相次ぎました。
JR西日本は再発防止策を検討した結果、ミスのもとになったスイッチバック自体をなくす必要があるとして、線路を直線に敷き直す大がかりな改造工事を行うことにしました。
この工事に伴って、北宇智駅の場所も北側に110メートル余り移設されることになり、総工費は1億7000万円余りかかるということです。
JR西日本は今月中にも工事に着手し、来年3月のダイヤ改正をメドに新しい線路での運行を始めることにしています。

平成18年12月18日(月曜日)

今日

Winny事件判決の問題点 開発者が負う「責任」とは - 専門家がメディアにおいてこういう真っ当なことを言ってくれると、世の中の動向について楽観できるというものだ。こういうものをもって「それがジャーナリズムです」と叫ぶのならば、賛成するに吝かでない。

世の中は諦めが肝心だ。よく馬鹿の一つ覚えで「諦めたら終わりだ」とか言う人がいるけれど、そんなのは状況による。「しょうがないねえ」で現状を受け入れて初めて先に進める場合というのも確実に存在するのだ。

魔法瓶(まほうびん)はなぜ冷(さ)めないの? -

いっぺんにたくさん作る場合(ばあい)、工場(こうじょう)の部屋(へや)全体(ぜんたい)からポンプで空気を抜(ぬ)いて真空状態にした後(あと)、外瓶と内瓶をくっつけているんだって。
おー。

複数のファイルの特定文字列を一括変換したい場合、

for i in *; do cat < "$i" | sed 's/AAA/BBB/' > "$i"; done
とすると良さそうに見えるけど、これってポータブルなのかねぇ。

しかし

for i in *; do sh -c "sed 's/AAA/BBB/' > \"$i\"" < $i; done
ではうまくいかない。これは既存のファイルオブジェクトをそのままにしておいて truncate(2) で切り詰めてる時の挙動だ。したがって、一番最初の方法でも長いファイルだと尻が切れるのかもしれない。open(2) の O_TRUNC もこういう挙動だっけ? うっかり O_TRUNC というのは「ファイルを消してから再度ファイル生成」と等価だと勘違いしてたが、よくよく考えてみればそんなわけはないよな。だから最初の方法もきっと駄目だ。

一方で

for i in *; do sh -c "rm \"$i\"; sed 's/AAA/BBB/' > \"$i\"" < $i; done
だとうまくいく。

sh の評価順序が信頼できるならこれは

for i in *; do (rm "$i"; sed 's/AAA/BBB/' > "$i") < $i; done
と簡単に書くことができるし、NetBSD の /bin/sh や zsh はこれでうまくいくようだが、やっぱりポータブルかどうかはわからない。

これらの方法がポータブルでない理由として考えられるのは、

  1. unlink したファイルを読めるかどうか分からない
  2. sh の評価順序が意図した通りかどうか分からない
という二点で、 1 はカーネルの実装に、 2 はシェルの実装に依存する。 sh -c を使う方法ならば、 2 には依存しない。括弧を使う方法では、サブシェル内のリダイレクトの評価がサブシェルのキックより前に行われているとうまくいくかどうか怪しいが、そういう風に実装するとサブシェルの意味がないような気がするので大丈夫なような気がする。

GNU の sed だと

for i in *; do sed -i -e 's/AAA/BBB/' "$i"; done
でいいらしい。なんて軟弱な!

オリコンが自分たちに都合の悪い記事を書いたジャーナリストを潰すべく高額訴訟を起こす - 片方の言い分だけでは判断できないけれど、こういうのは難しいね。ライターさんたちも、こういうことに備えて互助会でも作って訴訟資金のプールをしておくとか、そういう防衛策を用意しておく必要があるのかもしれないね。

平成18年12月19日(火曜日)

昨日

貧乏姉妹物語(4) / かずと いずみ - 完結。

学園アリス(12) / 樋口 橘 - 花園会篇終了。

ブラッディKISS(1) / 古都 和子 - 及第。父親の汚名を濯ぐために弁護士になろうとしている主人公が、学資に充てようと祖母の遺産である屋敷を処分しに行ったところ、その屋敷には祖母の縁の吸血鬼二人が住んでいて云々。

REC(6) / 花見沢 Q太郎 - ユニット結成篇。

今日

某所から ほったらかし温泉 - ネーミングセンスに萌えた。

しょんぼりサタデー - そういえば、この言葉の意味を書いていなかったことに気づいたが、要するにそういうことです。祝日法は割と頻繁に改正されていて、直近の改正によって 2008 年には連休が大量生産されることになっておるのだが、未だにしょんぼりサタデーは対策されていない。これは世の中の多くのサラリーマンの労働意欲を維持するために、可及的速やかになんとかされるべき問題である。

今日の朝日新聞の一面を見ていたら、なんか「日本は最近、カンボジアのころと比べると PKO への積極性がなくなってイクナイ!」みたいな感じのことが書いてあったんだけれども。朝日新聞って PKO に賛成なんだっけ? 彼らとしてはこの話を「イラク派兵イクナイ!」ってところに帰着させたいようで、そのためには自分たちの過去の主張を撤回しないまま簡単に棚に上げられると思っているのかもしれないけれど(そしてまた自分たちの都合によって棚から下ろしてこれると思ってさえいるのかもしれないけれど)、そうは問屋が卸さない。

査収物:

鉄道に魅せられた旅人 宮脇俊三 / 別冊太陽編集部

オフ・オフ・マザー・グース / 和田 誠

メモ: Winny裁判を考える なぜ「幇助」が認められたか - 小倉秀夫弁護士との一問一答。

権威は正しく使おう

百式の中の人、RFC違反はもちろんWebサーバ運営者の迷惑をまるで考えない設定を推奨するの巻 - とりあえず迷惑云々という主観的なところは置いといて、この RFC についての記述は正しいのかしら。

私には「RFC2616には『同時接続数はhttp/1.1では2まで』と明確に定められている」という事実が確認できなかった。かわりに RFC2616 に次のような文章があるのを見付けた:

Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy.
(8 Connections / 8.1 Persistent Connections / 8.1.4 Practical Considerations より)
これを邦訳すると
永続的なコネクションの仕組みを使うクライアントは、自身が管理している接続について、ある与えられた一つのサーバに対する同時接続数を制限すべきである。一人のユーザが使うクライアントは、どんなサーバやプロキシに対しても、二つ以上の接続を保持すべきではない。
となる。まあだいたい SHOULD / SHOULD NOT 項を守らないことをもって「違反」とまで言えるかどうかも疑問ではあるけれど、それを置いといても、これは、「永続的なコネクションの仕組みを使うときに今まで通りたくさん繋がれると折角の仕組みが逆効果だからやめてくれ」っていう記述であって、したがって "close" なコネクションなら HTTP/1.0 と同様に無制限なんじゃないのかな。

もちろん、 HTTP/1.1 のデフォルトとして放っておけば "persistent" なコネクションになるんだから、やっぱり max connections を増やせばこのガイドラインに反する可能性が高いんだけど、しかし、だからといって上の文章を「RFC2616には『同時接続数はhttp/1.1では2まで』と明確に定められている」と要約することはできないでしょうね。

結局のところ、原典(RFC)の引用の一つもしないんだったら、最初っから RFC を引き合いになんか出さなきゃいいのではなかろうか。 MS が信用できないとは言わないけど、所詮は二次情報ですから。そういうところで手を抜いちゃいかんですよ。

なお、私が見付けられなかっただけで、実際にはどっかに別の記述があるのかもしれないけど。その場合には私の間違いなので御容赦ください(が、同時に、原典をもってちゃんと示しておいてください、とも言いたい)。

しかし HTTP ってシンプルなプロトコルのはずなんだが、 1.1 ではもう全然細部まで把握しきれませんな。

やまやさんとこも参照。私はどちらかといえば「persistent connection の時だけなんだから普遍的に『http/1.1 では明確に定められている』ってのは語弊があるよね」という方に重きを置いているのだけれども、「SHOULD / SHOULD NOT をもって『明確に定められてる』ってのは語弊があるよね」と言うのがやまやさん。いずれにしても「原典に当たれ」というのがこの辺のジジイ共の主張。

まあ迷惑だという主張そのものにはあまり反論はないのだけれども。 HTTP/1.1 は次のようにも言っている:

HTTP implementations SHOULD implement persistent connections.
(8 Connections / 8.1 Persistent Connections / 8.1.1 Purpose)
なので、「HTTP/1.1 時代のシステムは persistent connection と pipeline くらいちゃんと実装してね、おねがい♥」というのが規格策定者からの要請なんだろうね。

この業界、モノがあってナンボ

Matz 氏の HSP についての話 - たしかに HSP みたいにひどい言語がそれなりに使われているという事実は言語原理主義者 Matz 氏でなくとも訝しく思うところがなくもないが、結局のところはバランスとタイミングなのだと思う。我々としては「何であんなウンコなカーネルなのに」とかそういうような類の話はとうの昔に通過してきているのである。

HSP という言語がウンコなのは、どちらかといえば処理系としての HSP の実装者の都合だろう。実装者の知見の狭さというのもあるかもしれないし、あるいは、いい言語はえてして処理系そのものを実装するのが難しい。

ある言語がいい言語だったとしても、結局はそれだけのことであって、必ずしも目的に合致してるとは限らない。たとえば俺がエディタを作ったとして、そのマクロ機能に何か既存のいい言語を使おうとしても、多くの言語処理系はそういう再利用がしにくい。じゃあ自分でそういう言語の処理系を実装するかというと、そんな暇はない。結局、ろくでもない言語を自前で設計実装して組み込むことになって、目も当てられないというようなことになったりする。いかにいい言語であっても、目的にあった処理系や言語実装が用意されていなければ使われない。そういう手頃なものがなければ自前で実装することになるけれども、大抵はひどい言語のほうが簡単に実装できるから、その時点でひどい言語が実装されることが約束されている。

最近は Lua みたいに始めから組み込まれることを意識してる言語実装があるけれど、そういう流れは評価できる。私は個人的には、パーサから何から全部ライブラリになっているべきだと思っていて、たとえばパーサがライブラリになってれば、統合環境にありがちなハイライト処理とかコンテキストヘルプとかの処理がやりやすくなると思うんだが、そうなってないのでうんざりする目に遭う。プログラミング言語の作者はとかく言語そのものの仕様に目を奪われがちだけども、言語の処理系実装そのものの再利用の便宜みたいなところにもちゃんと目を向けるべきです。

平成18年12月20日(水曜日)

今日

- やべえ、ピンチになったらおもむろに頭に手をやって、奈良カッターを撃ちそうだ。

しかもこの奈良はメガネをかけてないので最強の奈良だ。なんと言っても川す……じゃなかった鈴木智恵子にぞっこん。

ふと思い立ってアキバに行ってマイ Wii リモコンとヌンチャクを買ってみた。

帰ってきたら奈良が勝ってた。決まり手は奈良づくしなのではないかと思うが詳細は不明。