2004年4月の技術日記


Apr.4,2004 (Sun)

久々に寝たいだけ寝る。ぐっすり寝ると、昨日出来ないと思ったことが出来るように思えたり、新しいアイデアが浮かんできたり、とりあえずやる気が出たりする。

図的言語

図は人とのコミュニケーションに重要な役割を果たすけども、描き方の教育はほとんど行われていない。開発関係ではUMLがかなりの成功を収めている。図解言語入門:図解の技術を覚えよう(by @IT)では、図は話をするだけでなく考えをまとめるのにも良いと、めずらしく一般向けに書かれている。最近では開発に関係ないビジネスの分野でもUMLを活用して分析しようという分野もある。文系方面では分析ツールとしてKJ法(by hatena)が有名(*1)

自分もよく図が分かりにくいと指導されるのだけども、普通の人が図を描いて分かりにくくなってしまう原因は一度に多くの情報を図に書き込んでしまうかららしい。自分で作っているとついたくさん書き込んでしまうが、図はシンプルで一目で分かるものが良い。自分が良く遭遇する例は、静的な図と動的な図を一緒に描いてしまう図。組織図とその実際の活動を一緒に描かれてしまうといったい何の図なのか分からなくなる。また、図の中の記号の使い方に統一がない場合も分かりにくい。UMLを小中学校の総合の時間なんかで教えてもいいのではないかと思う。

個人的にはプログラムは図形であるべきだと思っていて、そのとりあえずの第1弾が programa。第2弾は自分の中ではすぐに出す予定だったのだけども、なかなか着手できずにすでに4年経過している。その間、Squeak(Play With Squeak by thoru氏)や、MDAなどのツールを参考にしながら一応自分なりに考えてはいるものの、なかなか時間が取れない。完成すれば、見た目重視のオブジェクト指向な図形言語になる予定。

権利など

自分は、多くのソフトウエアのEULA(ソフトウエアの利用許諾契約)には納得していない(*2)。十分なサポートもする気が無い(少なくとも人が行ってインストールしたり使い方を教えたりするべき)のに、高いお金を要求して、電話サポートのみの売りっぱなしで、電話をかければ「お客様の責任です」と追い返えす。また、ソフトウェアライセンスを考える(by @IT)のように、普通に考えればおかしな権利を主張される。コンピューターが法的に特別だからではなく、単にソフトウエアの開発者や企業が技術で煙に巻いて調子に乗っているだけだと思う。売れる売れないということではなく、使っている人の傍に行ってもっとコンピューター利用者の声を聞くべきであろう。本当にいいものであれば高くても買うし、多くの人がユーザビリティーのひどいソフトで苦労しなくてすむ。

権利ということでは著作権もデジタル万引きやデジタル放送のコピーコントロールなどによって、身近な問題になってきたようである。人はなぜテレビ番組を“録りためる”のか(by ITMedia)では、新しい制度への不満をあやしげな仮説でおもしろく考察している。最近はファイル交換とレコード業界の売上減少は無関係〜米経済学者が論文(by Internet Watch)という話もある。デジタル万引きも個人的にはしょうがないと思っている。大量の情報から必要な情報だけを選択することはこれからの情報化社会の当然の流れであるから、情報提供側が価値の高い情報を小売していかなければならない。本屋やCDショップのような旧来のメディアで情報を売る業界は、消費者が何を求めているのかを考えて行動しなければ本当の意味で生き残ることは出来ないと思う。

なんで多くの人がソフトウエアの特許について文句を言うかというと、やっぱり発明されたと言われているものに納得していないからだと思う。例えば青色LEDのようにすごい発明には、多くの人が納得して権利を認めている。逆に誰もが考え付きそうなアイデアや既に広く使われているモノには、多くの人が納得しないはずである。しかし、「みんなが納得するかどうか」を制度に取り入れて実現するのはやっぱり難しそうだと思った。

*1: しかし、KJ法普及の人たちはなんとなく宗教めいた雰囲気がある。
*2: もちろんライセンスに従ってちゃんと全てのソフトは買っている。

Apr.19,2004 (Mon)

気が付くともう4月の半ばを過ぎていた。

オープンソースライセンス

OSI承認ライセンス 日本語参考訳が公開された。表現の厳密なニュアンスがなかなか分かりにくかったので、非常に助かる。

X31不調

ある日、スリープさせて移動後、ふたを開けても反応が無くなった。AC電源をさしても応答なし。

バックアップはある程度とっていたので、回収修理を覚悟して電話してみる。バッテリーを抜いてAC電源のみで起動せよと言われたので、その通りにすると起動した。あまりにもすばやい回復だったので、こういうことはよくあるのかと聞いてみたけども、教えてくれなかった。

Apr.21,2004 (Wed)

MLの喧嘩

JavaHouse-Brewersにて、全文引用と宣伝の入った署名の是非をめぐった議論(というか喧嘩)が起こっている。どちらも過去に一応の結論が出ていて、引用を削ることをサボらない末尾全文添付は議論にならないなどが、MLのページのトピックからたどれる。もちろん、いきなりトピックの中からそのようなルールを見つけるのは難しいけども、十分な根拠のあるルールであるので、指摘されたら従うのが常識であろう。しかし、なぜこのような見苦しいやり取りが繰り返されるのか考えてみた。

大抵このような喧嘩は、問題の人コミュニティーに自分の勝手な要求を押し付けることから始まる。要求の内容に関しては大抵結論が出ていてそれ以上議論の余地が無い場合が多いため、問題の人が要求を取り下げない限り収束しない。そして、オトナゲ無いやり取りが繰り返され、感情的な対立はいつも後味の悪い終わり方をする。

問題の人は最後まで要求を正当なものとして取り下げない場合がほとんどである。ほとんどの問題の人は正当とする根拠として、問題の人の価値観や、問題の人の周辺の慣習を取り上げることが多い。前者の主張は「自分(少数)の意見をまったく尊重しないのはおかしい」、また後者は「〜は多数の社会の常識であり、このコミュニティーも〜に合わせるべきである」となっている。これらの主張は主観に基づくため、根拠としては弱い。また、コミュニティーのルールが社会の常識と違っていても、それ相当の理由があって(長い議論の結果)ルールを決めているはずなので、その理由に触れずに「個人の意見」や「多数派の常識」を繰り返し主張するだけでは議論は平行線をたどる。問題の人の戦略としては、コミュニティーのルールに論理的な反対意見をぶつけなければならないが、まともな反対意見を見たことが無い。

喧嘩になる原因はほぼ全て感情的な問題(恥をかかされた、メンツがつぶれた、高圧的な態度にむかついた)から発生している。なので、たしなめる方の言い方が違っていれば問題は発生していなかったとも言える。実際に現実社会でも言い方によって、同様な喧嘩は起きうる。

今までの経験から、起きてしまった喧嘩を止めることは難しい。おそらく放置というのが一番簡単で有効な手段であるように思われるが、まともに議論しあう人が多いのでなかなか実現できない。問題の人の傾向として味方の意見には耳を傾けることがあるので、味方を偽装して意見を受け止めてあげて、間違いを遠まわしに指摘して自分で気づかせるという方法もあるかもしれない。この方法は大変だけれども、決まると気持ちよさそう。何れにしろ、感情的な状態のままではいくら論理的に返しても喧嘩が収束することは無い。

個人的には問題の人に非があるように思われる。MLでも現実社会でも、何かコミュニティーに参加したければ、まずはそのコミュニティーについて知ることから始まり、挨拶など交わして自分を受け入れてもらうという段取りを取るはずである。それをいきなり「おれが正しい。おまいら全員間違っている!」から始まれば、コミュニティーから嫌われるのは当然であろう。ただ、現実世界にもそのような頑固で非常識な人間は居るものである。そのような人をコミュニティーに入れないという方法もあるけども、公共的なコミュニティーの場合は居ても何とかなるようなカタチが望ましいと考える。

自分的なまとめ。MLでの結果発生のメカニズムは以下のよう。

  • 0:非常識な人は常に居るものである
  • 1:自分の常識をうっかりコミュニティーに適用する
  • 2:コミュニティーから反発を受け、逆切れする
  • 3:感情的な状態のまま議論を行って、平行線をたどる

よって、以下のように対策が考えられる。

  • 0:非常識な人をコミュニティーが許容するかどうか決める
  • 1:コミュニティーのルールについて明示する
  • 2:ルールに反する人に注意する時は、感情を逆なでしないように気をつける
  • 3:感情的な議論が始まった場合は、とにかく頭を冷やさせる

問題が起きたとき、ペナルティーまで必要かどうかはわからない。また、対策1については、問題を起こす人ほど読まない傾向があるので、相当工夫するか、読まなくても何とかなるような形式を考えるべきであろう。

ところで、ルールやコミュニティーの忠告に従わなかったので不正アクセスだと述べた人がいた。MLはアクセス制御機能で制限されているわけではないので、いくらなんでもそれは言いすぎだと思うけども、興味深い指摘ではあると思った。

気温上昇と熱

最近の気温上昇により、X31や外付けハードディスクの温度も急上昇している。とくにX31のファンはほとんど回り続けていて、しかも排気は火傷するくらい熱い。初めての夏なので耐えられるかどうかちょっと不安。バックアップ体制もちょっと考え直さなければならないかもしれない。

Apr.24,2004 (Sat)

MLの喧嘩2

例の問題の人が詭弁の特徴を備えているということで、詭弁の特徴のガイドライン(by 2ch) を教えていただいた。面白いので引用してみる。

例:「犬ははたして哺乳類か」という議論をしている場合、あなたが
「犬は哺乳類としての条件を満たしている」と言ったのに対して否定論者が…

1:事実に対して仮定を持ち出す
  「犬は子供を産むが、もし卵を生む犬がいたらどうだろうか?」
2:ごくまれな反例をとりあげる
  「だが、時として尻尾が2本ある犬が生まれることもある」
3:自分に有利な将来像を予想する
  「何年か後、犬に羽が生えないという保証は誰にもできない」
4:主観で決め付ける
  「犬自身が哺乳類であることを望むわけがない」
5:資料を示さず自論が支持されていると思わせる
  「世界では、犬は哺乳類ではないという見方が一般的だ」
6:一見関係ありそうで関係ない話を始める
  「ところで、カモノハシが卵を産むのは知っているか?」
7:陰謀であると力説する
  「それは、犬を哺乳類と認めると都合の良いアメリカが画策した陰謀だ」
8:知能障害を起こす
  「何、犬ごときにマジになってやんの、バーカバーカ」
9:自分の見解を述べずに人格批判をする
  「犬が哺乳類なんて言う奴は、社会に出てない証拠。現実をみてみろよ」
10:ありえない解決策を図る
  「結局、犬が卵を産めるようになれば良いって事だよね」
11:レッテル貼りをする
  「犬が哺乳類だなんて過去の概念にしがみつく右翼はイタイね」   
12:決着した話を経緯を無視して蒸し返す
  「ところで、犬がどうやったら哺乳類の条件をみたすんだ?」
13:勝利宣言をする
  「犬が哺乳類だという論はすでに何年も前に論破されてる事なのだが」
14:細かい部分のミスを指摘し相手を無知と認識させる
  「犬って言っても大型犬から小型犬までいる。もっと勉強しろよ」
15:新しい概念が全て正しいのだとミスリードする
  「犬が哺乳類ではないと認めない限り生物学に進歩はない」

詭弁の特徴のガイドライン(by 2ch)の1から

もうすこしまとめて項目数を減らせるような気もするのだけど、細かく挙げておいた方が「君の意見は詭弁の特徴第〜番に該当する」と指摘しやすいのかもしれない。

喧嘩は収束して元の静かなMLに戻った。しかし、MLにかつての勢いが感じられないのは、ちょっと寂しい気もする。もちろんJava人口が増えてML以外の情報源が増えたり、Java本体の技術が成熟して世間の目がWeb系などの応用に移っているためなのだろうけども、「日本のJava使い全員集合!」みたいな雰囲気のコミュニティー(かつてのJavaHouseか?)に変貌してもいいのかなとか思ったり。

Apr.30,2004 (Fri)

仕様書とテスト

開発現場から時代を眺める:TDD(by itpro)。テストを作れば即ち仕様書という説明に使えそう。

VBのいいところ

VBがC#/Javaよりもさえている一つの事例(熱血VBプログラマ応援団 by @it)では、ループの中のVBのSwitchとC#,Javaのswitchの比較をもって言語に優劣をつけているような雰囲気。

多分、書いている本人は分かって書いているのだと思われるのだけれども、ここで指摘されている差はそれほど大きくない。今回の記事では、C#/Javaは毎回caseの中にbreakを書かなければならないことが欠点として挙げられていたけれども、breakを書かずに続けて別の条件の処理も行ってしまえるという別の利点もある。だから、これだけでは言語の優劣について何かいえるとは思えない。

何れにしろ、LispやProlog等に比べたら個人的には今回指摘された言語の差は誤差の範囲だと思っている。VB/C#/Javaの中での言語選択で一番重要なのは、各地で指摘されている通り、開発プラットフォーム・開発環境・ライブラリであり、それらに比べたら言語の差などは非常に小さな違いでしかない。逆に、「コンピューティングのノーベル賞」獲得したケイ氏の功績(by ITmedia)では、「Hello」を10回表示するプログラムでJavaとSmalltalkの違いが示されているが、示されたプログラムは見た目の違い以上の大きな違いがある。言語の違いを述べるのは非常に難しい。

しかしながら、このシリーズは個人的には興味深い。おそらく、単にVBプログラマを無駄に勇気付けているというのではなくて、VBでよいプログラムを書くためにはどうすればいいかということを遠回しに分かってもらうということが著者のゴールなのだと勝手に思っている。今回のようにVBのいいところを紹介しつつ、VBでほとんどの問題を解決できるということを示したり、他の言語でも駄目なプログラムはありえるということを見せておいて、駄目プログラムの本質はVB言語にあるのではなくて、プログラムの作り方に問題があるということを面白おかしく興味を持ってもらえる形で書こうとしているのだと思う。つまり、このような挑発的なタイトルや内容は、ほとんどのプログラミングの方法論はCやJavaを対象にしているので、VBの人に他人事だと思わせないような工夫なのだと思う。

VBで駄目プログラムを書く人は他の言語に移っても駄目なプログラムを書くことに変わりなく、むしろ脅威が増大する。それよりは、慣れたVBでうまく書くコツをつかんだ方が本人にとっても周りの人にとっても幸せである。ということで、このシリーズは期待している。

本日のSPAM

最近はSPAMよりもウイルスの方が圧倒的に多い。


Return-Path: 
Received: from clapton8 (170.176.150.220.ap.yournet.ne.jp [220.150.176.170])
Received: from [127.0.0.1] by clapton8
  (ArGoSoft Mail Server Plus for WinNT/2000, Version 1.8 (1.8.4.7)); Thu, 29 Apr 2004 11:32:29 
Subject: ☆嘘・偽りのない在宅ワーク(想像と違い誰もがびっくり!)☆
From: hot 
X-Mailer: Easy DM free
Message-ID: <20040429.0232280468@ps-info-p-sol.net>
Date: Thu, 29 Apr 2004 11:32:29 +0900
 
☆嘘・偽りのない在宅ワーク(想像と違い誰もがびっくり!)☆
 
┏□■━━━━━━━━━━━━━━━━━━━━━━■□┓
              ホット・ホット・ニュース   <2003.04.27発行>
┗□■━━━━━━━━━━━━━━━━━━━━━━■□┛
 
【↓オススメ情報/ビジネス】━━━━━━━━━━━━1,921,762部発行━☆
レ┃ベ┃ル┃チ┃ェ┃ッ┃ク┃な┃し┃で┃即┃仕┃事┃
━┛━┛━┛━┛━┛━┛━┛━┛━┛━┛━┛━┛━┛ 
┣ 必ず稼げる在宅ワークの募集です。
┣ 年齢は20歳〜60歳まで。
┣ 1日1時間で月5万〜
┣ 一度覚えてスキルアップ必要なし。
┗━━━━━━━━━━━━━━━━━

知らない間に登録されたらしい。2日に1度くらいやってくるようになったしまった。
p-sol.netは各地で評判のSOHOスパム会社らしい。
Easy DM free は典型的なスパム作成ソフト。
ArGoSoft Mail Server はWindows用のメールサーバで一応製品版みたい。
yournet.ne.jp は有名なSPAM天国プロバイダーらしいので、ここから来るメールを全て弾くというのも有効な手段になるらしい。

某所のSPAMフィルターで「SPAM (・∀・)カエレ!!」みたいなメールで反撃するようにしたところ、一応送信はとまったようだ。



[最新にもどる]
桜井雅史: E-mail : m.sakurai@cmt.phys.kyushu-u.ac.jp
Web page : http://www.cmt.phys.kyushu-u.ac.jp/~M.Sakurai/