今度はあなたの番です。
世の中には「尾ひれをつけたがる人」が多数存在する。 オレは尾ひれをつけたくない。それは倫理とか正義感とかではなくて、 ただもう「うんざり」だからだ。
そういやー google がまえに (現在 google video で使われている Flash ベースのプレイヤーが出る前に) VLC のコードをパクったときは何て言ってたのか、見つけられなかった。 しかし彼らは Summer of Code 2007 で VLC を支援するというから、この件はうやむやにしたいんじゃないかと思われる。 キャッシュにしても、IME パクリ事件にしても、どうせ連中は 「Web のものはオレのもの」とか思ってんだろ。 こういう、ずるずるとした傲慢さ (というか、節操のなさ) は アメリカンに共通して見られる特徴のような気がする。
(免責事項: あ、ここは「気がする」って言ってるダケなんですから、とーぜん 新山のこの発言はいかなる文脈・語法・状況・生存・再生・謝罪においても 一切の責任および保証と賠償を放棄します。)
Wikipedia - 世界最大の匿名論争フォーラム。想像できるあらゆる話題に関して世界中の人と論争できる。 たとえあなたがスティーヴン・ホーキング博士で、いわゆる『専門家』だったとしても、 ブラックホールに関する自分の見解を、アイダホのどっかから書き込んでいるボブ -- 彼は自分がナルニア国を代表していると思っている -- の見解と折り合いをつけて、 双方が合意できる中立的な視点を探さなければならない。
いや、匿名での議論ならいまのところウィキッペはツウちゃんねるには負けているよね。 しかし Wikipedia の本質をもっともよく言い表しているのは、これだと思った:
Wikipedia - 便所の壁に書かれた百科事典。
$ wc *.py artools/*.py newstools/*.py
271 823 7787 cluster.py
109 284 2528 freqdb.py
57 170 1636 get_slot_name.py
34 108 913 getpatlabels.py
102 386 3310 map_filter.py
177 599 6028 map_gen.py
289 997 10389 map_gen_old.py
25 58 493 map_shuffle.py
51 159 1301 map_sort.py
162 624 5593 mapping.py
67 258 1889 mc_filter.py
95 250 2426 mc_gen.py
101 330 2793 mc_index.py
137 490 4127 mc_merge.py
277 976 8721 mc_show.py
114 407 3320 merge_test.py
349 1357 10720 metacluster.py
103 299 2591 pat_count.py
207 685 5588 pat_gen.old.py
210 728 5815 pat_gen.py
375 1150 10701 pat_index.py
20 56 447 pat_purity.py
65 251 1634 patconv.py
0 0 0 artools/__init__.py
90 300 2565 artools/dotglarf.py
40 118 1038 artools/getuncanon.py
684 2033 16976 artools/glarf.py
46 108 1069 artools/glarfdb.py
39 115 963 artools/iglarf2cdb.py
155 386 3498 artools/index_ents.py
42 116 941 artools/labelsent.py
456 1350 11799 artools/mulcoref.py
40 126 970 artools/record2cdb.py
233 634 5873 artools/reformat.py
144 402 3362 artools/weave.py
355 1488 12388 newstools/PorterStemmer.py
0 0 0 newstools/__init__.py
62 302 2039 newstools/art2cdb.py
272 1098 8838 newstools/cluster.py
383 1323 9374 newstools/convchar.py
70 345 2353 newstools/filterart.py
103 431 3055 newstools/filtercluster.py
99 458 3361 newstools/getcluster.py
73 362 2368 newstools/getdf.py
71 330 2330 newstools/getfeats_en.py
159 693 4831 newstools/getfeats_ja.py
91 440 3087 newstools/getsents.py
471 1352 11247 newstools/pycdb.py
198 918 7575 newstools/sentsplitter_en.py
282 918 7368 newstools/simart.py
51 403 2270 newstools/stopwords.py
112 487 3502 newstools/tokenizer_en.py
98 432 2870 newstools/trimsent.py
8316 28913 238660 total
この中で、いちばんロジックが複雑なのは metacluster.py である。 しかしコメント沢山つけてもたった 350行。 おまけに PorterStemmer.py はオレが書いたんじゃないし…。
もちろん、この形になる以前に捨てられたコードは山のようにある (これの数倍) のだが、 コーディングの分量だけを見れば、博士論文になる研究でもこの程度とゆうことだ。 結論: 要するに研究はコードじゃない。
まず、サーバが 2回もぶっとんだ。
原因は (おそらく) メモリのエラーである。
こないだ一度 panic したので、なんかあやしいなとは思っていたのだ。
それが昨日の夜あたりからいくつかのプロセス (ypserv や mountd など超重要なヤツ)
がじょじょに死にはじめ、気づいたときはもう sshd も死んでいて
ログインできなくなり、しょうがないのでそのまま放置。今朝 (といっても午後だけど…)
サーバ室に行ったら、次のようなメッセージが出て init が暴走していた。
kernel: Uhhuh. NMI received. Dazed and confused, but trying to continue
kernel: You probably have a hardware problem with your RAM chips
なにかと思ってソースを調べてみると、このメッセージは
linux/arch/i386/kernel/traps.c の mem_parity_error() 内で
表示されていることがわかった。このマシンは ECC メモリ塔載なので、
メモリに 2箇所以上のパリティエラーが起きた場合 (ECC メモリは 1箇所のエラーまでであれば自動的に修復される)、
NMI が発生するらしい。NMI っつうのは懐かしい響きだけど Non Maskable Interrupt の略で、
つまり絶対に防げない「最重要度の割り込み」である。
つうことは、メモリに欠陥があることはほぼ確定なわけだ。
そこで、マシンを急拠ラックからはずして集中治療室 (=新山の机) へ持ち込み、 edgar と二人で (home が見えないんで誰も実験できない、一蓮托生だ) メモリをとっかえひっかえしながら memtest86 を走らせる。でも、結局どのメモリがおかしいんだか わからん。しょーがないので「メモリは 4枚あるので、とりあえずそのうち 2枚だけを挿してみて (=2G)、 それで落ちるかどうか見てみよう」というチョー日和見的な結論になった。 で、結論: 3時間後ぐらいで 落ちた。 つまりこれは運悪く、最初に選んだ 2枚のうちどちらかがダメだったらしいとゆうことだ。 このマシンは 2枚ずつしかメモリを挿せないので、 つうことでふたたびサーバ室までいってマシンをラックから出してメモリをとっかえて、再起動。 しかしそのあいだにも Ralph から「いつ動くの?」って電話かかってくるし、 H嬢からは別の実験トラブルの件で電話がかかってくるし、はあ、あせりましたわ。 そういえば svn のリポジトリはこのマシンにあるから、これが落ちていると Ralph は commit できないんだった。
結局 (ケッキョキ) きょうは大黒柱サーバを 2回も再起動するはめになり、 しかもそのたびにラックから入れたり出したりを繰り返したら (狭いところに入りこむため、冷却ファンの風圧がすごいのです)、 こいつの筐体が激重くて手の筋はおかしくするし、 そのあいだに python のメーラで改造したところがバグるし (←この件だけはオレが悪い)、もうさんざんな目にあった。
しかし、メモリに問題があるってわかるだけでも、やっぱ ECC はいいよなあ。
しかし、いまならこの手のサービスは LDAP なのだろう。 じつは、いちど OpenLDAP を試してみたのだが、
system(3) が悪いのか、
それとも python が悪いのか。
大学にいたら edgar が来たので、彼を紀伊國屋へ釣れ連れていく。
で、「楽しいムーミン一家」を買わせることに成功した。
しかもなぜか日本語訳を。べつに特にプッシュしたわけではないのだが…。
コトの発端は、新山の thinkpad 250X (古い) が「salome」という名前であることから始まった。
で、じつはこの salome というのは「ムーミン谷の冬」に出てくる
はい虫のサロメちゃんから
取ったもので…という話をしていたら、彼はムーミンを知らなかったらしく興味を持ったらしい。
しかし、こういう名前をマシンにつけてるオレって、
いわゆる萌えキャラな人々と大してかわんないよな。
しかも、彼女しっぽ生えてるし。
ちなみに新山が 2002年ごろから使っているこのマシン (tabesugi.net のサーバ本体) は ホスト名が "giko" である。当時はドーでもよかったのだが、今ならこんなに ツウちゃんねる指向な名前はつけないだろうな。いまだったら… sh○○○○○a にするところだ。ハラへってるのだ。
だから何だって話だけど (オレには関係ない)、ようするにここから得られる教訓は何だろう? しかし「教訓」と呼ばれるものを得るためには、まず失敗を認めなければならない。 そろそろみんなこれを「技術屋の敗北」として認めてくれれば対策を考えられるのに、 なぜかそうしないのね。
いま思いついた。いわゆる「技術バカ」と言われる人々は、 end-to-end の原則を頭では理解していながら (いや、実際には知らない人も多いと思うけど)、 それを自分では実行していない。あるシステム (あるいは特定のモジュール) を 設計するときに技術者がしなければならないのは 「(そのシステム内でしか通用しない尺度での) 性能を最大化すること」じゃないんだよ。 実際に最大化しなければならないのは、 「設計 + 製造 + 流通 + 販売 + 使用 + アフターサービス」というパイプライン全体の性能、 というか効能なのだ。つまり、わかってないシステム屋というのは
を求めようとしているわけだ。ここでの変数 D は設計であり、 関数 f はその設計だけに適用される なんらかの性能評価関数である。ところが、本来求めなければいけないのは
であるような D なのだ。設計するブツがソフトウェアの場合は 製造や流通はほとんど無視できる要素かもしれないが、「使用」の部分はあきらかに無視できないほどでかいので、 「ローカルな性能だけ」を最適化する設計と「全体」を最適化する設計ではかなりズレが出てくるわけよ。 ここをわかってない人が多いんだろうなあ、と思うのである。 さもなければ「最新技術」という言葉に弱い人があんなに多い理由を説明できない。 まあ、趣味でやっているのだらば別にどうでもよさそうだけど、彼らはマジメっぽいからな。
去年はエレベータ騒ぎとガス給湯器騒ぎだったが、 今年はローラーコースターの欠陥がブームになりそうな予感。 おととしはマンションだった。
たぶん日本社会には「かたき役玉座」ってのが存在してるんですよ。 いつもここには何かが入っているが、定員があり、1、2人しか入れない。 たいていは企業とか商品とか TV番組とか北朝鮮とかがノミネートされる。 でもあまり長い時間居座ってると 飽きられるから、数ヶ月スパンで変わるところがポイント。
カード買わなくちゃね…
これは面白そう。行かなければ!
From: Ken Perlin
Spring 2007 Graduate User Interfaces
Final Class Presentations
We are pleased to announce the final class presentations
of the Computer Science Graduate User Interfaces course,
on Monday May 7 from 6-9pm.
Play games on giant interactive projection walls. Make
cybernetic plants dance to music. Help bring line drawings
to life. Discover new uses for the Nintendo WiiMote that
even Nintendo doesn't know about.
All are welcome. Bring the kids!
Location: NYU Media Research Laboratory
715-719 Broadway, 12th floor
Refreshments will be served.
ちなみに EOS Airlines というのは高級サービスに特化した航空会社で、 座席数をうんと少なくしたかわりにファーストクラス並のサービスをビジネスクラス並の料金で実現したということである。 「格安のお値段」とか言われても往復 5,000ドルじゃなあ。オレには縁のないことよ。
3191日が経過している。なんて長いタバコなんだ…。>>> from datetime import date >>> print date(2007,5,4)-date(1998,8,8) 3191 days, 0:00:00
紙巻きタバコ1本分の喫煙時間 (4cm分) が 3分間であると仮定すると、 (3191*24*60/3)*4 = 6126720cm = 6.4×10-12光年のタバコとゆうことだ! すんばらしい。
はら減った。
そういえば新山は 1-2-3 って使ったことないなあ。いや、べつにいいんだけど。
人が職業生活において論理に立脚していないなら、その人の職業人としての基盤はきわめて貧弱である。-- Gerald Weinberg
いやー、「プログラミングの心理学」は quote の宝庫だなあ。
(追記) もういっこ。
しばしば人文科学者たちは、機械は人に厳格な性格を持つことを余儀なくさせることによって 人を非人間化する、と言い立てるが、事実はその逆である。機械が厳格であればこそ、それを使う人々は 本来あるべき程度を超えて柔軟性を発揮しなければならないのだ。たぶん人文科学者たちが「非人間化」 といっているのは、このことを指しているのであろう。というのは、通常の人と人のつき合いでは、 双方が公平に柔軟性を発揮し合うものだから…。一方ばかりが譲り、もう一方は譲られるだけ、という関係は、 十分に人間的だとはいいがたい。それは両者のうちのどちらかに、性格のゆがみを生じさせがちである。 (強調は新山)
(ところでこれ、なんて読むの)
てゆうかさあ、オレは flash そのものとか web会議システムには興味ないんよ。 もともと sxreencaxt crap にも興味ない。新山が興味あるのは 「ドキュメンテーションをどうやってよくするか」という部分だけだ…。 しかもオレが興味あるのは文書の見た目やナビゲーションじゃない。 javadoc とか DSSSL とか文書の形式やフォーマッティングに関することには興味ない。 「文章の中身をどうやって向上させるか」が問題なのだ。 はっきりいうと、昔から人は文書の書式や文書作成ツールをいくつも作ってきたが、 その結果どうなったかっていうと、テキトーに作ったか、あるいは作らされたかの (見た目やナビゲーションだけはすばらしい) 中身のどーしょーもない文書が増えつづけてるのである。 これからもおそらくこのテの規格やツールは山のように増えつづけるだろう。 そして、人はそればっかり (新しいツールを作ったり、それの使い方を覚えたり) やって 一生を終わりそうな気がする。しかし 問・題・は・そ・こ・じ・ゃ・な・い・ん・だ・ (傍点のつもり)。 多くの人は「文書作成を簡単にすれば、文書の質が向上する」と思ってるらしい。 しかしこの 2つはまったく相関性がないのは、現在の web とかブログロを見ればあきらかである。 文書作成を簡単にすれば、しょうもない文書が増えるだけ。 いや、いい文書もすこしは増えるだろうが、探すのも大変になるからエンドユーザからみるとあまり変わらない。
ようするにこれは Precision と Recall のジレンマに似ている。このふたつはたいして相関していない。 現在のところ、人は Recall を上げる (= 文書の作成を簡単にする) ことしかやっていない。 で、Precision のほう (= 文書の質を向上させる) は 「検索技術を改善すればゴミから少数のいいものを見つけてこれるだろう」とか思っている。 アホか! もちろん、技術だけを使ってできることはそれがせいぜいだろう。 周辺技術をいくら向上させても、人の書く文書の質を改善させることはできない。 それは社会が経済的に豊かになれば、自殺者が減るか? ってのと似たようなもんかもしれない。 よくわからん。 しかし、本質的な問題が解決しなければ、それは「ただのムダ使い」だと思うんだよね。 実際に人々が手間をかけなければいけない部分は、技術的 (テクノロジーという意味で) な解決ではないのだ。 でも、そのことがわかっている人間はそんなに多くないようである。なんでか。
フリーのソフトウェアが (一般人にとって) 商用のものよりよくなることはありえない。 RDBMS とか OS とか、そういう下の層はフリーでもいいもんができるかもしれないが、 それらのよしあしを判断するのは基本的には開発者である。エンドユーザ向けの フリーのソフトウェアは、あくまで「テキトーでもいい」範囲においてのみ 「よい」のであって、ちゃんとしたものにしようとすれば結局どこかでカネがかかる。 でも、なーんか今のフリーソフトって、必要以上に「カネと手間がかかる」ものにしようとしているようで、 ついていけないなあ。Gnome とか、Firefox とか OpenOffice とか…。 あんなもんをいじってたら、人手がいくらあってもたりないよ。おまけに 「そもそも本当に必要なのか」という疑問がある。なぜもっと「こぢんまり」する方向が 広まらないのか不思議なんだけど、やっぱりみんな大は小を兼ねると信じているんかねえ。 いっぽうでオレは何に対しても「こぢんまり」を望みすぎだな。
てゆうか、よく「人の欲望には限りがない」とかいうけど、新山は限りはあると思うんですよ。 しかも、人によってはそれはかなり小さい。ささやかな人生で満足できない人は 幼少時になにか致命的なトラウマがあったんじゃないかと思われる。
なぜなら同じ名前のフィールドが複数個存在することを許しているから。
こいつは Python の辞書と相性がわるい。email.Message では、
これはこうやって作るのだが、
>>> import email
>>> msg = email.message_from_string('From: foo\nTo: baa\nTo: ggg\n\nHello.\n')
>>> print msg
From nobody Wed May 2 13:09:31 2007
From: foo
To: baa
To: ggg
Hello.
To: ヘッダが 2個ある場合、ふつうに辞書あつかいすると 1個しかとれない。
全部を取得するには msg.get_all を使う必要がある。
>>> msg['To']
'baa'
>>> msg.get_all('To')
['baa', 'ggg']
しかも、ヘッダの値を修正しようとして代入すると、
これはヘッダへの上書きではなく「ヘッダの追加」になってしまふ:
>>> msg['From']='zzz'
>>> print msg
From nobody Wed May 2 13:10:12 2007
From: foo
To: baa
To: ggg
From: zzz
Hello.
ヘッダの値を上書きしようと思ったら、ヘッダを一旦 del で消さなければいけない。
ところが (てくるが) !!
>>> del msg['To']
>>> print msg
From nobody Wed May 2 13:12:37 2007
From: foo
From: zzz
Hello.
del はその名前をもつヘッダをぜんぶ消しちゃうのだる。くそったれ。
結局のところ (ケッキョキ、) Python でヘッダの値を修正しようと思うと、
次のようなめんどくさいコードを書くはめになる:
def modify_headers(msg):
alt_headers = []
for (k,v) in msg.items():
if k == 修正したいヘッダ:
v = なんか(v)
alt_headers.append((k,v))
for (k,_) in alt_headers:
del msg[k]
for (k,v) in alt_headers:
msg[k] = v
これはべつに Python の emaillib のせいってわけじゃないんだけど、 とにかく、ムカつく。
ところで、ワラった記事:
どぅーでもいぃーけど、オレはいまだに「縁」という字を「緑」と読んでしまうのだけど、 これはどうしたら矯正できるの??
日本人はふつうバナナを食べるときに、 まず上のヘタをポキっと折って、それから上からすこしずつ剥きながら食べていく。 しかし、じつは文化が違えばバナナの剥き方も違うということを思い知った!! こっちに来て、バナナを真ん中から剥く人をこれまでに少なくとも 2人ほど見たことがある。 どちらの場合もまず真ん中にツメを立てて切りこみを入れ、それから完全に皮をむいて バナナを取り出し、それを持って食べるのである。手が汚れるじゃない? なんで彼らがこんな食べ方をするんだろうと考えて気づいたのだが、 そういえば米国で売っているバナナは最初の「ポキっとやる」のが難しいことが多いのである。 なぜかヘタの部分が異様に頑丈で、ポキっとやろうとして力を入れるとバナナごと 「ぐんにゃり」なってしまうことが多い。これが起こると上の部分はブヨブヨ化してしまい、 ひどくムカつくことになる。なんで日本で売っているバナナのヘタはあんなにすんなり折れるんだろう? そこで新山の立てた仮説は「日本で売っているバナナには、じつはヘタの部分に (折れやすいように) 切り込みが入ってるんではないか」というものである。 米国のバナナを食うときは、包丁で少し切り込みを入れておくとポキっと折れやすい。 バナナのブランドは Dole とかだから、 バナナそのものは日本と同じだと思うけれど、パッケージングのときになにかしてるんじゃないかなあ。 推測だけど。
Document ID: c799ae627c8bd47683e93c5ad1572a39
Yusuke Shinyama
