日々の破片
| 著作一覧 |
2005-11-01
_ SQL
かって書いたことがないほどSQL依存してみてるんだが、正しく書けてるかどうかさっぱりわからん。
パフォーマンスとか無視してプログラムドリブンでリレーション（シップというコメントもあるようだ）を扱ったほうが全然楽だ。
_ 111
うううううううううううううううううう
2005-11-02
_ はやぶさ
カッシーニが土星に着いたりしてた頃って、子供も学校で聞かされたりしてたわけなんだが、昨日ふと気になってはやぶさのことを聞いてみたら全然知らなくて/聞かされてないことがわかって、ちょっと驚いた。
今日だってイトカワから4kmなんてあたりを飛んでるのだが。
ミネルバが降りると変わるのかな？
#土星は理科の教科書に出てくるがイトカワ（というか小惑星群そのものも）は出てこないからどうでも良いとかかな。
でも、それって確実に退歩だと思う（と、いきなり追記）。
アポロ見た子供とか、スペースラブ見た子供とかってののうち、何人かはそっちっかわへ引っ張られるわけじゃん。それが機会を与えるってことで。
それでいけば、同じ国の人が小惑星にロケット飛ばしてすごく近い距離を回ってロボット降ろしたりするんだよ。3個あるエンジンの2つが逝っちゃったけどどうにかそれでもいけそうだってめどがついた。ほら3人寄れば文殊の知恵（じゃなくて毛利の矢のほうか、どうでも良いけど）、みたいなことをちゃんと子供に示してやるべきじゃないか。そのうちの1人でも2人でもそっから何かを見つけるかも知れないわけだし。
#というようなことを学校がやらずに（もちろんマスメディアはやらないし）親がやれ、それが機会不平等時代ですかそうですか。いやいいんだけど。
2005-11-03
_ JavaOne
夏がTechEdなら、秋はJavaOneだ。
それにしてもLG3Dの人気っぷりが目をひく。が、ハンズオンは満杯だけどBoFが空いているのでそっちに入れてみたり。BoFだとPOJO＋アノテーションが満杯なのが不思議なような当然なような。
awayと言えば咳さんだが、JavaOneでは萩原さんがawayerのようだな。
実はJavaOneは初めての参加なのでどうも勝手がわかりにくい。TechEdだと30秒くらいで何に出るか決められるのだが……
逆に言うと以前はTechEdにも、わーすげーいろんなものが詰ってるけどどれにしようかな、という目移り感があったわけだけどそれが今やなくなってしまったということで（PDCだとまた違うのだろうが）、JavaOneにはまだそれがあるということかも知れない（それは初参加で勝手がわからないということと等しいんだろうけど）。
#うが、余分なこと書いている間にどんどんfullに変わっているようだが、考えることは皆同じで、今登録している人がたくさんいるみたいだ。
ジョシュアブロック（ヨシュアかも）(って今はグーグルさんなのか)の「毎年、ナンバーワンクラスの人気」のStill More Programming Puzzlerがまだ空いているわりにへーと思うようなものが塞がっていたりなかなか興味深い。
2005-11-04
_ 獲物がない
最近どうしたんだろう？
_ 形式主義vs実質主義
という命題。
これだけ見れば、直観的に「形式主義はだめ」と考えるよ、僕は。
でも、TBスパムについてはどうかな。
実質主義とはTBスパムのことを
(1)営利目的
−営利かどうかは実際のところはわからない。たとえばアフィリエイト満載のHPは営利目的で、ちょっとだけなら非営利か？ でも、満載しているのは批評の便のためでちょっぴりでも売れ筋押さえだと実際は営利目的かも知れない。つまり定性的にしか判断できない
(2)無差別
−同様
(3)大量配信
−大量というのも定性的な規準だ。またそれが大量かどうかを判断することは相当難しいと思う。
というそこらで見かけた3本柱によって定義するものだとする。−で書いたように、これらは形式化できない以上、実質という曖昧な言い方でしか示せない。
それに対して形式主義の場合
・言及リンクが存在しない
とする。これは現実に形式化可能だ。具体的には多分たださんのところでやられているように、tbを受けたらtb元をプログラムから参照してそこのhtmlからアンカータグを探しhrefにtb先が存在することを確認することで判定可能だ。
面倒になってきたから、思ったことを書くと、こういった問題に対して定性的な規準を振り回しても無意味だな、ということだ（人間の裁判だとまた違うんだな。殺したら死刑と形式主義だけだとどうもいろいろ具合が悪いようだ。なぜなら人間は機械じゃない）。
つまるところ、こういうことだ。
spamは機械的な操作なのだから、防御も機械的に行えなければ勝ち目はない。したがって、その判定のための定義も形式的でなければならないということで、最初に誰かが上げた3点みたいな、「ばかで、めちゃくちゃで、てんでなっていなくて、あたまのつぶれたよう」（どんぐりと山猫）な定義については、そんなものは知ったことではない、と考えるのが具合が良かろうということだ。
グスコーブドリの伝記―猫の事務所・どんぐりと山猫 (ますむら・ひろし賢治シリーズ)(ますむら ひろし)
で、形式化された定義の意味を理解できないという相手を想定する必要があるのかどうか、あるいは、形式化によってどんな恩恵が得られるかを想像できない相手と言い換えても良いが、そういう問題もありそうだ。不思議だな。想定対象は形式主義者を想像力が無いと判断している節があるのに、実際はその想定対象のほうに想像力のかけらも無いわけだから。このタイプの不思議はそこら中にあったりするのだが（ここはセーガンのエセ科学本みたいなものを想定しても良い。宇宙人がやって来る（川口主義者）は科学者に想像力――この「想像力」は一般的に「ロマン」という言葉で置き換えることができる――がないと考える。科学者は川口主義者に想像力――この「想像力」は難しいな、文字通り想像力なんだが、推測力とでも言えば良いか？――がないと考える。実質想像力と形式想像力だ）。
なんでこんなことを思ったかと言えば、こないだからうんざりするようなSQLを書いてみたりして、いかに自分がプロシージャに毒されているか（別にそれが悪いとは思ってないから「毒」ってこともないけど）を思い知ったってこともあるのだが。意外なほど、手続きによってプログラムを記述するのは形式からは離れた作業で、むしろ形式は構造のほうにあるんだけど（注）、SQL（でその先として想定しているのは関数型プログラミングなんだけど）みたいに状態を保持できないプログラムってどこかで頭の切り替えが要求されるみたいだ。そのあたりの頭の切り替えとなんとなく結びついてるような気がする。手続き型＝エセ科学のロマン派プログラミングで、関数型＝古典派プログラミングとか？
注）ここは知見だ。手続き主導のプログラムの場合、静的なモデルはどうも必須に思える（うまく説明できないけど、静的なモデルによって全体を固めておかないとなし崩しになるんだと思う）。逆に関数型の場合にはモデルというのはどうなるんだろう？
わけわからんからここまで。あー、ちらしの裏がコンピュータ上にあるってのは便利なことだ。
_ あっちはあっちで動いてる
it should be available within the next two or three weeks. And we've got two new features lined up for you as well
DSL Tools with Visual Studio 2005 RTM。
とにかく、今やってることをさっさと終らせなければ。次が始まってるじゃん。
2005-11-05
_ すごくバカバカしいことを書く
だいたい思いつきだし、気分が悪くなる人がいること間違いない。
ようするに昼飯食いながらバカ話を先日してたのだった。
アフリカ（アジアもだけど）には野生の象がいる。野生のイノシシが犬を襲うような感じで野生の象が大群で街に攻めてきたら多分、戦車でも持ってこなけりゃ勝てないよな、というような感じ。
でも、アフリカ象は気が荒いからやばそうだけど（幸い、街が近くにない）、アジアの象は気は優しくて力持ち、それが証拠に家畜化できてるじゃん。
それにつけても野生の象ってのは何食ってんのかな？ たちまち山は丸坊主とか。葉っぱとかかな？
それにしても、最初にああいったケモノを見た連中は腰抜かしただろうな、だって象が出て来たらそりゃ魂消るだろ。
ふと思ったが、（とこれは2人の野郎の会話である）サイとかカバってのもびっくりだよね。しかも草を食うわけだし。
で、ヨーロッパに帰って一角獣になるわけだ。サイが。どこからああいった絵になるんだ？
と言えば人魚よ人魚。
ジュゴンのことだな。あれ、カバだよね、顔は。どこをどうすればあれが人魚……
というところから話はよからぬ方向へ。
絶対、あれ、中国人の航海（テイワの航海とかあったね。徐福とかが先駆かも）だったら、食っただろうな。アフリカへ行けば、カバを食う、ゾウを食う、サイを食う。で、うまいかどうか記録する。
ふむ。
絶対に、一角獣みたいな妄想はうまれっこないと思う。
ふむ。
何しろ食うから。イテキも食う。赤ん坊も食う。食い物がなければ女房を質にいれるかわりに殺して食う。
そんなバカな。
少なくても三国志では劉備が食ったことになってるよ。旅の途中で泊まった家の主が食い物がないんで奥さん殺して二人で食った。
で、翌朝、それを知って劉備は怒るというわけか？
まさか。感謝して、ああうまかった。ママさん、おかわり。
それは嘘だな。
まあな。
というくらいに中国人は、人類の食文化に多大な貢献をしてるわけだ。
人間については別だと思うが、確かになんでも食ってみてるとしか思えんな。っていうか、ツバメの巣だの猿の脳みそだの熊の掌だの良くメニューに入れる気になったもんだと感心する。
それは多分違ってあらゆるものを喰らって喰らって喰らい抜いて、おいしかったものがメニューに残ったに違いない。
そうかも。
でだ。オレは気付いた。
何を？
人類の2大欲望は、喰らうことと喰らうことだ。
オーガじゃねぇんだから、喰らうは無いだろう。
まあまあ。
で、中国人がジュゴンを見たら煮て喰らう。
ふむ。
で、西洋人がジュゴンを見たら寝て喰らう。
はぁ？
というようにモノの本には出ていた。
嘘つけ。
いや、嘘じゃない。想像してみろ。長い長い航海で、周りはむさくるしいヤロウばかり。ああたまにはケツ以外のあなに入れたいなと皆むらむらしてるところに、手頃な大きさのケモノが泳いでるってわけだ。で、中国人なら喰らうわけだが西洋人は別の喰らい方をする。
かわいそうなジュゴン……
で、カバどんとは言いにくいもので人魚の絵ができた。
セイレンとかはギリシャ神話にも出てくるからそれは嘘だな。
いや、嘘というよりは、方便として人魚としたわけだ。っていうかあの頃から北アフリカと船で行ったり来たりしてたからその頃からの伝統行事かも知れないけど。で、だ。つまり、中国人がアフリカへ行ってああいう奇怪なケモノを見ると、まず鍋を用意して喰らう。しかし、西洋人がアフリカへ行ってああいう奇怪なケモノを見ると、まずロープを用意してよってたかっておさえつけて喰らう。で、帰ってからこういう妄想をしました、という絵になる。で、中国の文化は日本の文化のモトでもある。
何を突然？
さて問題です。イルカやクジラを見たらどう思う？
かわいいなぁ。
でも航海していていつも干し肉食らわされていたら？
うまそうだな。
だろう。しかし、西洋人は、そういう発想にはならない。特にイルカは大きさも手頃だ。
で、かわいいなぁ、周りは野郎ばかりだし……と発想すると、そう言いたいってわけだな。
当然だ。それが、おれたちの食い物にヤツラがいらぬ干渉をする理由だ。犬を食うな、馬を食うな、羊を食うな、ヤギを食うな、みんな同じ理由だ。
っていうか羊とヤギは食ってるはずだが……
そういうこともあるかも知れないが、そこに東と西の差があるってことだ。
おれたちはケモノを見ると食い物として考える。だから殺すのは当然だ。しかし西洋の連中は神に許された羊、豚、牛を除けば、みんな性欲の対象だ。殺すなんてとんでもない。つまり、グリーンピースの連中は、頭がいかれたケモノ主義者だということだ。そう考えると、あいつらが理性もへったくれもなく、クジラやイルカを保護したがるのは（あの連中が直接喰らうことを意識しているはずはないと思うが）文化的な深層心理から、あれを食い物ではなくあたかも……
さて時間だから仕事に戻るとするか。
2005-11-06
_ ロバの皮
（でもなぜか王女とロバ）。
ひさびさのジャックドゥミ。
絵本の中の城から映画が始まる。
青く塗った家臣群。やたらと肩幅を強調した服のジャンマレー。
ジャンマレーは普段は猫の彫刻にまたがっている。幸せな王国のようだ。
デルフィーヌセイリグ（この人、去年マリエンバードででは白黒のせいか静謐な感じだが、妙におちゃらけたティンカーベルみたいなリラの精として登場）。ピンクのドレスが気に食わず青いドレスに変換する。
明日までに縫え。しょうがないですな。
空のドレス（青が刻々と変わる）。すげぇぞ眼鏡の職人。
屋根を破って妖精が登場。あら本当に作っちゃったのね。
明日までに縫え。しょうがないですな。
月光のドレス。すげぇぞ眼鏡の職人。
妖精登場。あら本当に作っちゃったのね。どうすれば良いの？ こんだ、太陽、最終秘策は我に在り、ひそひそ。それを言うくらいなら結婚するわ。あら、それは絶対だめだめ。
明日までに縫え。しょうがないですな。
太陽のドレス。すげぇぞ眼鏡の職人。
最後に、ロバの皮。マレー、むっとする。が了承。夜でっかな頭付きの皮を持ってきてベッドに置く。本物の質感。寝たふりをしている王女。
妖精登場。
なぜ意地悪をするの？ それは秘密。顔に墨を塗って醜く変えたことにするが鏡の中にはやはりカトリーヌドヌーブ。
この杖を上げるわ。消えようとして杖が無いのに気付く。消えるからちょっと返して。消える。杖は宙に残る。ドヌーブ杖を取る。消す。
裏口から覗いて衛兵が通り過ぎた隙に川の上の小船へ。
通りで白馬2頭立ての馬車に飛び乗りふかふかのクッションで寝入る。
普通の2頭の馬が引く荷馬車に敷いた干し藁の上で目覚める。
時間が止まった村の中をおばさんの家へ。ガマ蛙を口から吐く。
豚小屋から水を汲みに行く。子供、選択女、バカップル、みんなにバカにされる。親父2人組みにバカにされて池のほとりで恨み言。
赤い馬の赤い家臣群と王子。
横一列に整列して食事。
退屈して森へ。バラの花の中にリラの精の口と目。
ガラスかなにかで前に進めず、屋根の窓から覗く。
鏡で気付く王女。光を反射。
王子が戻ると家臣はテーブルに腰掛けたりしてくつろぎきってる。
城へ戻る。衛兵の槍の位置を直す王子。
でも帽子は鹿の置物に無造作にかける。寝台で寝る。
母親登場。鹿の置物にかけられた帽子を直す。
ロバの皮のお菓子。
メニューを箱から出して読む。王様のための……あら、これは違うわ、で愛のケーキ。
太陽のドレスを着た王女が料理を作り、ロバの皮がレシピを読む。レシピがほとんどそのまま唄になり、それに合わせて料理が進行。すばらしい。
医師群勢ぞろいして恋煩いと告げる。鷹揚な王様。
指輪。
さっそく怪しげな緑のクスリを売る男。
指を酸に漬けて骨が出たり、しめつけて痛くなったり。
で、大行列。そういえばファントムオブザパラダイスのオーディションもこんな感じだったな。王女が最初、あとは公候伯子男。
子供が2人目。ぶかぶか。早すぎたようだね。大人になったらまた来るわ。
おばあさんの公爵令嬢。
料理人の後ろが洗濯女……
というか、絶対狙っているだろうが、美人は庶民のほうが多い。とんでもなく太った料理女。
無職の女。「ぜーたーい、むりだとおもーけどー」とヌーベルバーグ女っぽい。退屈しきっている王様と后。
王子はいつも律儀に指輪をはめようと試す。特に美人には。素直な人間らしい。
あれー変だなぁ。どこかにこの指輪がはまる人がいるはずなんだが。（というか顔は知らないのであった、そう言えば。位置関係は窓に王子、背中のロバの皮、鏡。ロバの皮は鏡を見て窓の王子を見つける。鏡の反射で王子は目が眩む）
ロバの皮は？ 呼んでこい。
そこへ登場。あまりの異臭にみんな飛びのいたり苦しんだり。
指輪がぴったり。
ロバの皮を脱ぎ捨てると太陽のドレス。
一同ナットク。
白い服の結婚披露宴。突然、文明の音。ヘリコプターが空から降りてくる。
中からジャンマレーとデリフィーヌセイリグ。結婚したのよ。
めでたしめでたし。あー、満足した。
_ 何も考えずに船に乗せてはみたが
The paper's definition of the term "relation" is worth examining briefly. That definition runs more or less as follows:
- Given sets S1, S2, ..., Sn (not nessarily distinct), R is a relation on those n sets if it is a set of n-tuples [ or rows] each of which has its first element from S1, ...（面倒なんで省略）
っていうか、
- 3. Operations of Relations
という言い回しさえある。（複数形のsがカタカナ化するとき消えることは良くある）
で、Where is a term 'ship' ? とおれは不思議に感じるんだが、なぜお約束としてシップがどうしたとか出てくるんだろう？
ちなみに、いずれもDATEの以下の本からの引用
Database Relational Model, The: A Retrospective Review and Analysis(Date, C. J.)
というか、そもそもの始まりのCoddの1969ペーパーのタイトルが、Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banksなんだから、大規模データ庫にストアされてるのがリレーションじゃなくて他のなんなんだ？（エンティティだとかだっていうのは無しとして） というわけで理由が知りたいのだが。
#追記：ためしにrelationを辞書で引いてみたら米語ではrelationshipが多いとか書いてあった。っていうことは、用語として最初に言い出した英国人のコッドを無視して、広まった米語での言い方をしたいということなのかな？ もしそうだったら正直言ってわざわざ指摘するようなものではなく、むしろ第3国なんだからオリジンに敬意を表してリレーションと表記すべきかあるいは自分の流儀は自分の流儀として布教をわざわざすべきではないと考える（カタカナ用語なんだから短いほうを利用した方が具合が良いだろう）。まあ、理由がわからないから推測なんだけど。
2005-11-07
_ ソウヤー
東急ブンカムラは整理券を配るから早めに行かざるを得ない。
すると待ち時間ができる。
したがって、本を持ってくことになる。厚いのはいやだがスタックにある文庫はソウヤーだからホミニッドを持ってった。
が……強烈な一種のネタバレを先に読んじゃったもんだから、妙に実感があっておもしろいのなんのって結局読み終わってヒューマンにそのまま突入。ちょっとまずいので中断したが。
確かに、サザンクロスシティの無法者がそのまんまその外見をもっと強烈にして、しかし中身が例のアレだ。まさに文字通り。
「天国というのは、わたしたちが死語も存在しつづけることになっている場所」
「それは撞着語法です」
っていうよりも、ヒューマンのこの部分が端的だな。
「ご存じでしょうが、グリクシンのひとりがボディット特使を殺そうとして、わたしにも発砲したんです」
「ああ、それは聞いた。だが、ふたりとも生きのびたのだろ？」
…（略）…
「とにかく、グーサなら、グリクシンが使っている物体発射式の武器から身を守る手段を考えつくはずだ。…（略）…球形エミッタが必要だな。そいつを帽子のなかにでも組み込めばいい。ささいな問題だ」トゥカナに顔をむける。「これがきみの要件なのか？ だったら、きみのかわりにグーサに連絡をとって、わしは日々の生活にもどるが」
というわけで、技術的な対処方法がとれるなら「ささいな問題だ」。これはいいな。
2005-11-08
_ ヒッツビルUK
サンディニスタ!(紙ジャケット仕様)(ザ・クラッシュ)ロバの皮を見に行ったら予告編でヒッツビルUKが流れてきた。
おれの大好きなほうのクラッシュだ。スパニッシュボム、ステイフリー、そしてヒッツビルUK。
というわけで、これまであまり興味がわかなかったけどダニーボイルの映画を見に行くか。そのうち。
_ アマゾンのムラ人たち
もしかして、ホミニッドのアマゾンでの評が低いのは彼らがムラの人たちだからかなぁ？
−−登場人物たちが独りよがりな価値観で討論を戦わせているだけ
−−登場人物の魅力のなさ
でもなぁ
「失礼ですが、あなたは正式な外交官なんですよね？」
「そうです」トゥカナは弁解するようにいった。「サルダクの代表として、エヴソイとラニラスとナルカヌですごしました。しかし、そうした討議の場では、できるだけ速く要点を述べるようにしているのです」
おれは、そのほうがいいと思うな。速く要点。もっともこの外交官はそれが必要だとわかると「具体的なことはほとんど口にしなかった」ということもできるわけで、さすがに外交官だ。
_ 青赤白
見てる時はまったく気付かなかったが、あれはフランスだったのか。
でもどの色がどの概念か思い出せない。
内容から想像するとマレーの王国（青）が自由、赤が平等、最後の白が友愛なんだが。
追記：青は自由、赤が友愛、白が平等、が正解だった。（赤＝平等と発想したのは多分、共産主義の赤と、王子の国がすべての未婚の女性にチャンスを与えたことからそう考えたのであった）
2005-11-09
_ JavaOne初日メモ
EJB3.0。すっきり。
追記：この上下で全然異なる話ですよ。DとBはdataやbaseじゃないですよ。と念のため。
DとBの7の間に水平に移動できる通路が必要だと思う。すごくバカな建物だ。でも話によるとこのあたりの利用方法も含めてデザインされているらしい。異なる利用方法をすると罰金刑もあるらしい。いいねぇ、バカなデザインを強制できるってのは。
でもバカなデザインと規定が合理性を持つ可能性についても一応は考えてみると、何が理由となるだろうか？ 大量の人間の水平移動によって何か問題が発生するので、少量ずつボトルネックとしてのエレベータを利用して一度に移動可能な量を制限しているのかも。横移動ではなく縦移動が必要な構造なのかも知れない。だとすると、バランスが非常に悪い建築物なのだろう（もし、本当に、それが必要なのならば）。とすると、やはりバカな建物だということになると思う。
あるいは、毒ガスが充満した場合に、各棟で被害を押さえ込めるように分けているのかも。火事になったら毒ガスがもくもく出て来る仕組みなので被害を最小に留めるためには分離しておく必要があるということだ。やはりまともなデザインではないな。火事になったら消せるように考えれば良いと思うし、有毒ガスが発生しないような考慮はできないんだろうか？
他にはどんな理由があるのかな？
_ 可変性と共通性
萩原さんのセッションのテーマ。
ユースケースは拡張の記述が追記できる。
しかし、静的なモデル図ではどうすれば良いのだろうか。
フィーチャモデルでは必須なものとオプションを書き分けられるし追記もできる。
大雑把には、@itの連載のサワリの部分。
以下はそれについて考えたこと。
カスタマイズ可能なソフトウェアについて当てはめて考えてみる。
あるべきありようというのは
・コアコンポーネントはそのまま他のカスタマーのところへ持ち込める。削除できる
・可変部（カスタマイズが必須な部分）は、当たり前だがカスタマイズできる。追加できる（基本はゼロなので削除は考える必要がない）。
・可変部からコアコンポーネントへの影響をどう吸収するか。
継承（実装継承、デリゲート含めて）をパッケージで分離するとDolphinのモジュラー化機能が利用できるのだろうかと考えたり
修正というのはソースを作成する（カスタマイズする）時のオマケとして、追加と削除だけで考えられるようにするというのが、間違いは少ないのではないか。
_ イルカ
マスタングのことだと思い込んでいたorz。
_ 紙は平面
紙は平面だが巻物にすると収納しやすい（しかしランダムアクセスはしにくい）、製本するとランダムアクセスしやすい（直方体になるので積み重ねしやすい）というように、人間はおつむを使うことができた。
いやでもCPU作ってる会社とGPU作ってる会社がそれをしたいわけだし、MSも（多分Appleも）それを使おうとしている。
ということは、いやでも2Dのものを3Dに配置するデスクトップはやって来る。
やって来ることがわかっていて、おつむを使う余地が開けきっているわけだ。
UIに少しでも興味を持っているのなら、今すぐ使える3Dの世界、つまりLG3Dに飛び込まなきゃ嘘だろう。
Project Looking Glass Developer's Guide。
と煽ってみたり。
2005-11-11
_ JavaOne3日目
基調講演。特に印象に残ったことは無い（今のところ）。
追記：なんで忘れてるんだか。2日目のJavaNightのチャンピオンたちのデモ。携帯電話のQVGAの中が3Dでデュークが手を振ってたりするのはすげえじゃん。HTMLでWindowを配置する場合（いや、多分divの配置でも）奥行きなんかのパラメータを使うようにそのうちなるんだろうなとか、3D空間をどう利用するか（奥行きと側面からのビューの2つが今のところキモのように思える）。特に感動したのはBOFでデュークの鼻のテカリをちゃんと処理しているとか言ってたところ（エイタロウソフトの人）。細部に無駄に凝るって、やっぱり（というのは時々無意味な処理は無駄だと考えることもあるからだが）重要なのかも。多分、すごく重要なんだろう。とか。
#Macだとユーザー切り替えの部分にだけ、その未来がほの見える気がするわけだが。（ここまで追記）
スループットコンピューティング。でっかな箱を無尽蔵に置くことは不可能だ。あるいはマシンはブレードになったけど、電力が問題だ。増やせば増やすほどコストがかさむ。そこで場所を食わない、電力を食わないようにするにはCPUのマルチコアですよ。言われてみればその通りだ（つい、HTの流れでメモリーアクセス待ちで暇だから使っておけの発想しかしてなかった。全然わかってなかったということか）。
Linux＋Apache＋Tomcat＋Jboss＋PostgresとHP-UX＋WebLogic＋Oracleの比較。これはすごくおもしろかった。実行特性が全く異なったり（前者はシンプル）、バックログに追いやられたコネクション要求の消失問題とか。前者に対しては再試行回数で調整し、後者はタイムアウト時間で調整するとか（障害発生時の検出パターンが理論通り。前者がでたらめというわけではなく役者が多いということもある）いろいろな知見が得られた。こういうセッションを聴くとさすがにNEC、でっかいだけに多士済々だな、と思う。（今になって気づいたがLinuxには踏み込んでなかった）追記：HTを有効にした場合のパフォーマンスダウン（6割程度になっていたような）。キャッシュミスが原因ではないかというような話が出ていた。
プロファイラ。ちょっといろいろ考えた。
アノテーション。今の知見を2001年に持ってたらVC#の本に属性の利用方法をいろいろ書けたはずだなぁ、と思ったり。ちなみに、属性についてはIDL（端的な利用としてはtypelib）ベースでやってたから良く知ってるわけだが、アスペクトという見地が無かったからなぁ、と感慨。たとえば、uniqueといった属性を元にプロクシ／スタブのマーシャリング用コードが生成されるわけだけど、それは確かにコンパイルタイムのウィービングだし、propertyputという属性を元にセッタ呼び出しへの変換を行うわけだけど、それは実行時だ。Win32OLEのmethod_missingで、"foo="の呼び出しを検出したらfooというメソッドのうちpropertyput属性を持ったものを探すが、これなんか二重にメタプログラミングしてる（method_missingによるインターセプトと、typelibの検索）。と考えると、単にAOPという名前を付けただけという言い方を以前見かけたが確かにそうだ。名前を付けて利用パターンと利用のされ方のそれぞれのアスペクトに名前を付けるということ。
LG3D。プレゼンテーションツールのAPIをツールキットとして公開というのは、グラフィックツールのAPIをツールキットとして公開（GTKだっけ）というのに似ていて（構造）違う（ツールそのもの）が、そこの違いがなんとなく興味深い。
kawa見て思ったが、rjbのダメパターンは、異なるスレッドからのイベント受けなんだから、MacみたくUIスレッドをメインにおけないという制限を持つOSやLinuxみたいにシグナルを使いまくるOSじゃなければ（というとWin32とSolarisしか知らないわけだが）、rjbでも動かせそうだな、と気付く。
_ 忘れてたorz
動くな死ね甦れ、見に行くの忘れてた……
2005-11-12
_ トルコ風の青い（憂鬱な？）輪舞曲
デイブブルーベックのやつじゃなくて、ブルーロンドアラタークのブルーロンドアラタークが聴きたいんだけど、アマゾンにも無いし、iTMSにも無い。
_ 吉祥寺
そういや、ペンギンカフェってのがあったような。それとも国立か。
Music from the Penguin(Penguin Cafe Orchestra)
Penguin Cafe Orchestra(Penguin Cafe Orchestra)
どんなんだっけ？
たしか、白いような。ハイテク、ハイタチ、ナイロン100%。
さっきTVを眺めてたら、住宅の遮音性が高まって外部の音が入らなくなってきた。だから30db程度になる。すると、それまでの基準で35dbならOKだった換気扇の音が嫌でも聞こえる。
とか、以前は紛れてしまった赤ちゃんの泣き声が恐怖の大王のように振ってくるという研究。確かに言われてみればありそうな気がするから検証するのは重要そうだな。住宅の静音性の向上と育児ノイローゼみたいなものって相関性がありそうな気が確かにしないわけじゃない（あと、外出良くするのに対してしない母親の場合とか）。しかし、マッチポンプの香りが漂ってくるのがなんとも。
むしろ、音が溢れて混じるのが当たり前、60db程度までは外部にどの家も垂れ流しOKとかにしたほうが良いような（街宣車のレベルは許容しがたいけど）。
いずれにしても、本末転倒な気がする家具の音楽。
_ iTMSシングル買い
ビーバップデラックスのシスターシーガル（ジャカジャカジャ、チャッチャチャラチャラチャッチャッチャッチャ、シスターシーガル、オーヤー、フライングミートゥーハイ。ハードロック以外のナニモノでもない古くさいギター−−聴いた当時ですら−−なのだが、どこかにモダンな香りがするのはシーガルだからかflying me to highだからか）。
リープザワイルドウィンド（この頃は売れたほうのUltravoxなんかにはこれっぽっちも興味はなくなってたし、健康的な山男がアルプスを登るというわけのわからないプロモビデオだったりしたのだが、曲は悪くない）
キャントスタンドルージングユー（シングル−EPってんだが、しか持ってないので買い直してみたり。お前の兄貴と親父がライフル持ってオイラを撃ち殺しにやってくる。逃げなくちゃベイビー、でも別れるなんて我慢できないといういつの時代のどこの国だというような歌。で警察が唄ってるところがミソ800）（追記：うう、やたらテンポが早いし、妙なコブシが入ったり、とどめのようにイヨーイエーイエーヨが入ったり、「おい嬢ちゃん（もちろん空耳だが、実際にはなんて言ってんだろ）」とか変なのが聞こえると思ったら間違ってLive盤のほうのを買ってた。しょんぼり）
スージーと泣き叫ぶ精霊のホンコンガーデン（これが一番好きなんだが、シンプルでおばか）
スージーと愉快なバンシーズのハッピーハウス（これもついでに。雨に唄えばを真似したプロモビデオ。
ホンコンガーデン聴いてたらトムロビンソンの2-4-6-8モーターウェイを聴きたくなってきたが、こいつは持ってるので問題なし。
2005-11-13
_ 正しいコピペ
コピペはコードを書くときに必要な技術の1つでそれはうまく使わなきゃならない。
で、実は正しくはコピペではなくカトペであるべきだ。
public class Foo {
public void bar(Baz baz) {
...
if (baz.getA() > 0) {
baz.bazzzzzzz(Goo.newInstance());
baz.cazzzzzzz(Hoo.newInstance());
baz.dazzzzzzz(Ioo.newInstance());
}
...
}
...
public void car(Baz baz) {
...
if (baz.getB() > 0) {
baz.eazzzzzzz(Goo.newInstance());
baz.fazzzzzzz(Hoo.newInstance());
baz.gazzzzzzz(Ioo.newInstance());
}
...
}
...
}
というコードがあったとする。で、実はこれが半分しか正しくなくて、barもbazのgetB()の処理（carでやってるやつ）が、carもgetA()の処理が必要だと判明する。
で、なぜかこういうふうに直す人がいる。
public class Foo {
public void bar(Baz baz) {
...
if (baz.getA() > 0) {
baz.bazzzzzzz(Goo.newInstance());
baz.cazzzzzzz(Hoo.newInstance());
baz.dazzzzzzz(Ioo.newInstance());
}
if (baz.getB() > 0) {
baz.eazzzzzzz(Goo.newInstance());
baz.fazzzzzzz(Hoo.newInstance());
baz.gazzzzzzz(Ioo.newInstance());
}
...
}
...
public void car(Baz baz) {
...
if (baz.getA() > 0) {
baz.bazzzzzzz(Goo.newInstance());
baz.cazzzzzzz(Hoo.newInstance());
baz.dazzzzzzz(Ioo.newInstance());
}
if (baz.getB() > 0) {
baz.eazzzzzzz(Goo.newInstance());
baz.fazzzzzzz(Hoo.newInstance());
baz.gazzzzzzz(Ioo.newInstance());
}
...
}
...
}
ここで利用されるのがコピペだ。同じテキストなので、手で打ち込む手間の軽減とタイプミスの防止のために範囲を指定して一時的にヤンクバッファにテキストを覚えさせてそれを指定した個所に埋め込むことである（とか自明のことをだらだら書いてみたり）。
が、これはカトペのほうが良かろうと思う。
public class Foo {
public void bar(Baz baz) {
...
setupBaz(baz);
...
}
...
public void car(Baz baz) {
...
setupBaz(baz);
...
}
void setupBaz(Baz baz) {
if (baz.getA() > 0) {
baz.bazzzzzzz(Goo.newInstance());
baz.cazzzzzzz(Hoo.newInstance());
baz.dazzzzzzz(Ioo.newInstance());
}
if (baz.getB() > 0) {
baz.eazzzzzzz(Goo.newInstance());
baz.fazzzzzzz(Hoo.newInstance());
baz.gazzzzzzz(Ioo.newInstance());
}
}
...
}
カトペは元のテキストをヤンクバッファにコピーした後、削除する。つまり、テキストのクローンを生まない方法だ。
なんでこうしないんだろう？
それなりに説得力があるコピペの理由は、途中で「やっぱり元通り」とか「実はbarではgetB、carではgetAですた。すまん」とかがあった場合に、コピペのほうが対応が楽だし、どうも仕様が信頼ならないというものだ。確かに途中で変わったわけだからまた変わる可能性は十分にある。（にもかかかわらずこれはだめだろう）。
（追記）カトペだとキーボードに対して操作が発生するが（上の例だとメソッド定義と呼び出しの部分）、コピペだとうまくやると一切キーボードに手を触れなくて済むから疲労度が小さくて済むとか……というか名前重要と強調し過ぎると名前をつけるのを怖がってしまうとか？
実際は、最初の時点で間違っている（なんかコピペはどうでも良くなってきたので論点をずらしてみたり）。
最初から意味単位でばらしときゃ済む話だ。
public class Foo {
public void bar(Baz baz) {
...
setupBazA(baz);
...
}
...
public void car(Baz baz) {
...
setupBazB(baz);
...
}
void setupBazA(Baz baz) {
if (baz.getA() > 0) {
baz.bazzzzzzz(Goo.newInstance());
baz.cazzzzzzz(Hoo.newInstance());
baz.dazzzzzzz(Ioo.newInstance());
}
}
void setupBazB(Baz baz) {
if (baz.getB() > 0) {
baz.eazzzzzzz(Goo.newInstance());
baz.fazzzzzzz(Hoo.newInstance());
baz.gazzzzzzz(Ioo.newInstance());
}
}
...
}
で最初の仕様変更が来たら
public class Foo {
public void bar(Baz baz) {
...
setupBazA(baz);
setupBazB(baz);
...
}
...
public void car(Baz baz) {
...
setupBazA(baz);
setupBazB(baz);
...
}
...
ほら、コピペで問題なし。
追記：
いや、問題なしとは言えないかも。だいたい、5行のコピペはだめで1行なら問題なしとはなんじゃらほい。それにもしsetupBazA()+setupBazB()のペアで1つの処理ならば、それをさらに束ねておく意味はある。
public void bar(Baz baz) {
...
setupBaz(baz); // Bazで終えてよいかどうかは別問題
...
}
...
void setupBaz(Baz baz) {
setupBazA(baz);
setupBazB(baz);
}
...
}
そうでないと、一連の処理である「べき」だった場合に、ばらけた1つだけを呼び出したせいで不完全な状態になることだって考えられる。
public void dar(Baz baz) {
// 良く理解しないでdarを追加
...
setupBazA(baz); // setupBazBを呼び忘れている
...
}
で、もし一連の処理ならば、setupBazAとsetupBazBの2つとそれを束ねたsetupBaz、という組み合わせではなく、setupBazAとsetupBazBをカトペしたsetupBazを作りsetupBazAとsetupBazBは発展的に解消（妙な言い回し）させてしまうほうが良いかも知れない。でも、そうでないかも知れない（やっぱり、あの修正依頼はうそー、とかなった場合のことを想定）。
常に統合するのではなく、多段階にメソッドを束ねる作戦を取ると、良く似た細かなメソッドがわらわらと生まれてくるかも知れない。
void setupBazAB(Baz baz) {
setupBazA(baz);
setupBazB(baz);
}
void setupBazAC(Baz baz) {
setupBazA(baz);
setupBazC(baz); // こんだ、こんなのが出てきました
}
void setupBazBC(Baz baz) {
setupBazB(baz);
setupBazC(baz); // こんだ、こんなのが出てきました（コメントで、コピペがばれたり）
}
...
}
こうなると収集がつかなくなってくる。
そうなるくらいなら、setupBazというメソッドで束ねたのが実はあまりうまい方法ではなくて、setupBaz?の粒度で揃えておくほうが良かったということになる。どのsetupBaz?を呼ぶかは個々のpublicなメソッドの仕様として考えておいて、それ以上の深入りは避けておくということだ。
実際には、ABだのBCだのという組み合わせが出て来たら、そこで一度構成を考え直すのが良い。
具体的には、Baz側に局面に応じた状態設定メソッドを用意しておくということだ（setupBazAとかをFoo―呼び出し側―に持たせるのではなくBazの側にsetupByA、setupByB……を用意するということ）。
かくして、クラスをまたがるリファクタリングということになる。
実際には、FooとBazの関連（Bazはブラックボックスで変更できないという場合もあり得る）やその他の局面（どういう変更がありえるか、ありえないか）に応じて、使い分けることになる。
で、5行のコピペはだめで1行ならOKなのかとか、どの粒度で揃えるかとかって、機械的に決定できるか？ と言うと、多分できない。見てくれは揃えることはできるかも知れないが（おそらく徹底的にメソッドを細分化して多段階の束ねたメソッドを用意すればできるが、まじめにやればやるほどそれは羹に懲りて膾斬の刑と等しい）ろくでもないソースになるはずだ。となれば最後にモノを言うのはつまり属人性ですよ。カタカナ使うとセンスということだ。
そこで究極のコピペという手段が1つの解決策となる。Wizardとか自動生成。コピペ単位の設定に人間が介入するだけなので、生成されたソースが最初に挙げたようなものでもそれほど問題はない（読むのはイヤだけど）。
木目のある板を利用して壁を張ると、職人のセンスが問われる（木目をどうあわせるかどうか、微妙な色味の違いの組み合わせとかも）。でも合板を使えば何も考える必要はない。
という結論になるのかなぁ。
人間はできるだけカトペにする。
意味あるまとまりを作る（基本的に）。
複雑になりそうな場合には、組み合わせを記述する言語を作り、機械にコピペソースを作らせる。
2005-11-14
_ FileOutputStream#closeとwriteの競合
FileOutputStreamがスレッドセーフだなんてどこにも書いてないが、なんとなくスレッドセーフだと思いこんだのが運の尽き。 writeが先なら問題ないし、closeが先ならwriteがクローズ済みの例外になるだろう程度にたかをくくっていると。
j2se1.4.2だと、
FileOutputStream#write →FileLockImpl#release(FileLockImplをロック） →FileChannelImpl.removeList（lockListのロック待ち）と
FileOutputStream#close →FileChannelImpl#implCloseChannel（lockListをロック） →FileLockImpl#invalidate(FileLockImplのロック待ち）
となる（ことがある）。典型的なデッドロックだ。それにつけてもSIGQUIT。
writeはFileOutputStreamでロックをかけるがcloseはかけないのが原因か（でも、この動作はcloseの意味を考えると正しそうだ）。（nioのFileChannelImplの実装はまずいとは思う）
いずれにしろ、書き込みしているスレッドがいる間は、closeを呼ばないようにアプリケーションを修正。
2005-11-15
_ ウィザード
たった2つの質問に答えるだけでハローワールドを生成するウィザード。
実行例
C:\Home\arton\work\hello>ruby hellowizard.rb
あいさつは?
Hello World !!
クラス名は?
HelloWorld
ビルドします
実行します
Hello World !!
C:\Home\arton\work\hello>type HelloWorld.java
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello World !!");
}
}
C:\Home\arton\work\hello>
試しに実行までしてくれるらしい。
それではどんなウィザードか見てみよう。
#/usr/local/bin/ruby -Ks
puts 'あいさつは?'
hello = gets.strip
puts 'クラス名は?'
classname = gets.strip
File.open("#{classname}.java", 'w') do |x|
x.write <<EOD
public class #{classname} {
public static void main(String[] args) {
System.out.println("#{hello}");
}
}
EOD
end
puts 'ビルドします'
system "javac #{classname}.java"
puts '実行します'
system "java -cp . #{classname}"
でも、ウィザードって結局はこういうことなんだよなぁ……
なんだよなぁ、と思いながらも「Javaにはウィザードが必要」（「にも」じゃないのかな、とは思うけど）のNetBeans 5（もしかして4.1でもできるのかな？）には期待していたりもするのであった。
現実的にはウィザードで必要と思ったときに生成というのが流行るのではなかろうか
というのはちょっと思い当たる節があったり（思い当たったのはシェルとかスクリプトのその場しのぎウィザードなんだけど、たとえばfindみたくなにやら無闇にパラメータがあるコマンドにウィザードがあると便利だとは思う。結局、Emacsで画面を2分割して片方にM-x man、片方にM-x shellしてたりするわけだし。Javaで必要と思ったときに生成というパターンがあるのかどうかはわからないけど）。
しかし、それにつけてもVC++（単なるC++じゃ意味が通じない）に遅れること10年というのは大きい気はするが、結局、Javaな人たちってMSのそのへんの技術を知らないのかなぁとJavaOneだとWebアプリケーションのアノテーションを見て感じたりもしたのだけど。
_ すっかりポテトになっちゃった
ずいぶんと煽り気味だが、その分野での危機感って相当なものなようだ（理屈はわかるし）。ただ、頻繁な変更と組ならば、それほどの危険はないような気もするのは、僕がそれほど失うモノが無いからかも。
それにしても、この分野は奥が深いな。
_ LCD、RCA
京都賞記念ワークショップ（大島芳樹のカリフォルニア日記）
おもしろい。
会社はLCDをやりたくなかったので、「プロトタイプを作るのにも2百万ドルはかかる」とはったりをかましたのだが、広告業者は「問題ない。タバコの広告だけでも去年2千5百万ドル使ったのだから」と言われた。それでも上層部はやらなかった。
RCAってこれ読むと本当に自滅をしたんだな、と思わざるを得ない。というか、それが1960年代のことなのか。
内田先生が、「このようにきれいなディスプレイができております」と言いながら寿司の写真を見せていたが、あれはきっと寿司ではなくてなんらかのディスプレイに写っている寿司だったのだろうな。
YarvでExcelを動かせますみたいな感じ。
_ 特異OS（でよい？）
大島さんのところ経由。
An Overview of the Singularity Project
信頼性を主眼としたソフトウェアプラットフォームをスクラッチから記述したら一体どのようなものになるか？
ざっと眺めた感じではAppDomainの再定義のような気もするが、ちゃんと読んだわけでは無いので全然嘘かも。
2005-11-16
_ MicrosoftがGoogleをつぶす戦略が動き始めたようです。
同じネタを同じような切り口から取り上げてもcnetのやつと違って、勿体つけやはったりがない。したがって、論旨が明確で絵が見える。そこまで見えている人がいるということは、おそらく明晰なビルゲイツの頭の中でも同じ絵が見えているのだろう。しかもMSの他の実験群と異なって未知のファクターがほとんどない。基本的にMS内部で閉じた戦略だ。ということは、相当な確度で正しい推測だと思える。
遠見明察賞をあげたい。
_ 今日のアマゾンさん
絵をみてできる数学実験 (KS科学一般書)(礒田 正美)とりあえず、手に入るときに買っておいた。
ハイブリッド―新種 (ハヤカワ文庫SF)(ロバート・J. ソウヤー)
というわけで3冊目に突入。
レボリューション・イン・ザ・バレー ―開発者が語るMacintosh誕生の舞台裏(Andy Hertzfeld)
絶対価格は高いが、相対価格は安い気もするし(エディトリアルデザインの本でもあるからだ)、後で入手できなくなると寂しいので買う。
とは言うものの買う気になったのはNerdTVのせいであり、NerdTVの内容を知ることができたのは福盛さんのおかげなわけで、感謝。
それにしても、BASICにまつわる個所だけ目に付いたので読んだのだが、MSって本当にシビアなビジネスをする会社であるなぁ。
・ウォズニャックがBASICの必要性を感じてハックしてAppleIIに仕込む。
・でも浮動小数点数を実装していないという問題が（ウォズニャクのメモみたいなのが付いていて、そこではもう少し微妙なニュアンスになっているけど）。
・MSから6502用BASICのFDが届く。浮動小数点数を当然使える。
・AppleII PlusのROMにはMS製が入る。
・それはそれとして、MacにもBASICが必要だ。当然、GUIを操作可能なBASICである。
MacintoshのUIを活用できるBASICのプログラムが書けることが重要だと考え、サードパーティに頼らずに、自分たちで作るべきだと決意した。
しかし不思議なのは、マルチスレッドのインタープリタで同時に複数のウィンドウにグラフィックを描けたとか書いてあるけど、最初のMac OSってノンプリエンプティブ（お譲り制御）のはずだが、yieldをどういうふうに実装していたんだろう？
・MSが政治力とApple IIへの影響力から開発中のMac BASICを捨てさせることに成功。
しかし驚いたことに、Microsoftは開発中にも何も明かさずに、いきなりMacintosh用のBASICをリリースした。それは僕らが心配し、恐れていた通りのものだった。基本的にコンソールベースになっていて、Macのユーザーインターフェースをまともに使っていなかったのだ。
ところで、この連中が、BASICが必要だ! とか、BASIC! BASIC! とか言うのは、ウォズニャックの証言に如実に出ているけど、
私は、言語などというものを書いたこともなく、そんな授業も受けたことはなかった。実際、私はインタープリタやコンパイラについての授業さえ受けたことはなかった。
で、アセンブラしか知らない状態でエンドユーザーにプログラムをさせる……となった時にBASICしか知らなければ、
私はBASICでプログラムを書いたことはなかったが、BASICで書かれたゲームの本などを見て、これからの言語だと感じた。
と感じるのもしょうがないかも。
という具合に単に他のインタープリタ言語を知らなかったということなんじゃないかな、と思う。
たとえば、なんでエンドユーザー用にSmalltalkを乗せるというような発想をしなかったんだろう？ それなら最初から「MacintoshのUIを活用できる」となるんじゃなかろうか。メモリーの制約からBASICを乗せることにしたというような技術的な判断が行われたようには読めない。もう、自明のこととして、BASICを乗せる、と決まっていたようだ。
そう言えばAmigaも素でMSのBASICが載っていたが、普通（というのもPDS―当時の言い方―はCで書かれているのがほとんどだし）はAztecかLatticeのCを買うような気がする（ちなみに僕はAztec）。
なんで、BASICだったんだろう？ それが既にMSのマジックの始まりなのか？
_ NetBeans5 beta
とりあえず使って見始めた。いきなり、エディタ設定にEmacsテンプレートがあるのでにっこり。デフォルトはハードタブを空白置換だし、やっぱりこうあって欲しいものだ。
追記：^dの動きがおかしい……
さらに追記：ベータ2にしたらちゃんと動いた。
2005-11-18
_ NetBeansここが素敵
なんか無闇にサイトが重いが、人気爆発かそれともDoSでも受けてるんだろうか？
それはともかく、リコマンデッドな環境だが、Solarisで500MHz Ultra60＋512MBとかのBlade100あたりで、Windows/LinuxならPIII 800MHz＋512MBくらいなのに、なぜかMacだとG5＋1GBと倍のスペックになるんですが。
というわけで僕もiMac G5が欲しいんだけど、なんでみんなiMac G5と急に書いているんだろう？ ご成婚祝いで国民の1%に配るとか発表があったとかかな。
_ 100ドルPCを400ドルにしたら
先進国に生まれて教育を受けることができたってことは、すごくラッキーだったわけだから、自分がすごく損をしない限りはそれほどほっときたいとは思わない。
世界を不幸にしたグローバリズムの正体(ジョセフ・E. スティグリッツ)
スティグリッツも書いていたが、さらに遡ると収奪理論のころから、結局は教育だってことは薄々は誰でも感づいてはいる。その教育によって平坦化されるのがさらに長い目で見て幸福かどうかはわからないけど、その教育が有効になる10〜20年といった短期的にはそれ以上の不幸にはならないようには思える。なんと言ってもその国の一番のインフラは教育を受けた人間だ。
きちんと国連のような機関が動き、対象となる国がその普及と利用を保証するならば、僕は100ドルPCが400ドルPCという値付けで売られても買うだろう。さすがにあのスペックで1000ドルだったら（すごく損に傾くので）いやだけど。
もしその値段で10000人の日本人が購入すると少なくても200ドル程度のオフセット＋10000台分の量産効果が生まれるのではなかろうか。300ドルPCだったらどうだろうか。それでもオフセットとさらにその分の量産効果があるかも知れない。先進国の人間が1台買うと、本来与えたい人に2台以上が届く勘定となる。
ブラックボード-背負う人- [DVD](サイード・モハマディ)
あれがリーダとして利用できるというのは大きい。本は重く輸送も大変だ。大体、湿度が高い日本でもそれなりに保存が大変なのだから、地域によってはさらに紙というメディアを長持ちさせるのは難しいようにも思う。だが、学校は紙によって成立しているメディアだから（その一方で教える側には黒板と白墨があれば良いというのはうまいアイディアだと思う。考えた人は偉大だ）その紙がうまく扱えないような地域であれば、ますます効果があるだろう。
紙がない、筆記用具がない、教科書がない、といった問題を技術的に解決可能なのように思えるのだ。無線ネットワークのインフラをどう解決するのかは僕にはちょっとわからないけど。教育用衛星というのはおもしろそうだが。
だから、先進国では先進国料金で売れば良いなと思う。すくなくても白い包帯を腕にまくよりも、緑と黄色のマシンを持ち歩いてそのへんでなんか打ったり読んだりしてるほうがオサレとしたほうが、値段は100倍かかるけど、世界に対する貢献度は計り知れないほどでっかい（何しろそれで教育ができるようになるんだから）、と僕は思う。
#よく考えたら120ドルっていうのは原価で流通コストなんかを上乗せしていない価格みたいだな。すると、先進国価格は1000ドル（含む寄付の2台分）とかにしないとそもそも成り立たないような気がしてきた。
2005-11-19
_ 世界の果てにいつの間にか連れて行かれて
よしきさんが教えてくれたお話知ってるよを読んでたら、三匹のビリーゴーツグラッフの話が出てきた。橋の下のドワーフの話だ。トリップトラップ、トリップトラップ。
これ読むと、今となっては古色蒼然たる翻訳でとても読みにくい瀬田貞二だが（5年くらい前にドリトル先生を子供に読んでやろうとしたらあまりにも読みにくてびっくりしたのだが、と言ったって子供の頃には平気で読んでいたわけで、言葉遣いの問題ではなくてモノの名前の扱いが現在と微妙に異なっているように思える。もう少し年齢が高い子供向けのナルニア国にしてもそれほど読みやすいわけではないように思う）、絵本では全然古びていないことに気づく。ビリーゴーツグラッフとカタカナの名前が、がらがらどん。トリップトラップが かた こと かた こと。オノマトペをきちんと翻訳しているのだが、それがとても良い味になっているからだ。ドワーフがトロルになっているのは、良くわからないが。フィンランドにはムーミントロルがいるくらいだから、北欧民話では元々トロル（これは巨人のはずだ）だったのが英語化の過程でドワーフ（これ、白雪姫の小人もドワーフだからきっと背が低くてがらがらどんに突き飛ばされるのも当然のように思える）に変わったのを瀬田貞二が元に戻したのか、マーシャブラウンが自分の絵と合わせるためにトロルにしたのかはわからないけど。（なんとなく橋の下の屈強な小男と言うと丹下段平を思い出したり、とか）
追記：劇団プークのがらがらどんに子供を連れて行ったらトロルが怖くて泣きそうになって、でも我慢しながら見ていたのを思い出した。
三びきのやぎのがらがらどん (世界傑作絵本シリーズ)(マーシャ・ブラウン)
それはそれとして、絵の違いはさらに輪をかけて大きい。マーシャブラウンの極端におそろしいビッグブラザーのがらがらどんと地獄からやって来たようなぼろぼろのトロルの対決シーンのダイナミズムと、なんかイソップの橋の上から水面に浮かんだ自分に吠えて骨を落としてしょぼくれた犬の話のようなI KNOW A STORYの絵だと受ける印象が全然違うな。
で、マーシャブラウンって他にどんな本を書いているんだろうと思って見ていたら
影ぼっこ(ブレーズ・サンドラール)こんなのもあるのか。
je m'ent foutrist（綴りを忘れたが、ジュモンフートリストとカタカナで書くともっとわけがわからない。フューチャリストと似ているようで全然違う。今の日本の言葉だとDTということになるような気がしないでもない）の絵本ってどんなもんかとても興味を惹かれてついクリック。
世界の果てまで連れてって!… (生田耕作コレクション)(ブレーズ サンドラール)
日本語で読めた唯一の長編は品切れか。
黄金―ヨハン・アウグスト・サッター将軍の不可思議な物語(ブレーズ サンドラール)
と思ったら、こんなのも出ていたのか。まったく知らなかった。読みたいがやはり品切れ。
2005-11-20
_ 大人の科学#9
届いた。
ムムリクさんのとこを参考にさせてもらってさっくりと作ってみるかと思ったが、
- 付録プラネタリウムを作ってみた(写真入りで注意点が書いてあるので参考になりそう)
- 大人の科学のプラネ（３）（北斗七星の部分の組み立て上の注意がある）
恒星原版を貼り合わせるには、まず展開したのを置いておく場所を確保しなければならないということに気づく。
もうちょっと後回しだ（今月中には作りたいが）。
2005-11-21
_ 獲物がひさびさに仕留められている
_ ミリオンズ
MTV世代固有の薄っぺらでポッポッポッポップな絵。でも、大演技が無いからたとえば似たような作りでもジュリアンテンプルなんかより遙かに楽しめた。というか、ハリウッド映画じゃないってことは素晴らしい。最後に出てくる聖モーリーン（聖者じゃないけど）がただのオバサンという点も。
というあたりから、舞台の大演技＝名演は、!=映画での優れた演技＝大根ということを、アクターズスタディオの大演技者達＝映画に砂糖水をぶちまけて台無しにする連中に対するジョゼフコットン＝自他ともに認める大根＝映画をすばらしく生き生きとしたものにする名優というようなことを考えているうちに、以前、すごく以前、アンバランス劇場がまさに幻だったころ、唐十郎の講演付きで上映会があって、そこで唐十郎が階段落ちしたりするところで名演技をすると全然だめで棒読みで素人のマネな大根役者みたいな演技をするとすばらしい絵になるんで、映画（TV含む）と演劇は根本的に異なるというようなことが良くわかったとか言ってたのを思い出した。というか、階段落ちも思い出した。ブリッジとか。
#追記：末日聖徒が妙な役回りで出てたがなぜ末日聖徒なんだろうかとか疑問に思ったり。英国には結構いるのかな。（若者が3人で質素な集団生活をしているが実際には現世的という役回り）
_ NetBeans5ベータ2のくだらないバグ
多分、修正済みだとは思うがメモ。
ConnectionManager#showAddConnectionDialog(JDBCDrvier d);
を呼び出すと、d.getName()でNameを合わせずに、d.getName()した結果でクラス名と見なす。その結果、最初にオープンされた状態ではドライバーが不正な状態となる（どうせ名前が違うので設定し直すため問題はないのだが）。
2005-11-22
_ NetBeans5の昨日のやつ
cvsのstableを見たら、明らかにソースが異なっているし、見た感じ合ってるっぽいので終わり。
（API[説明には2引数のものが出ているが、ベータ2のパッケージのは1引数のしか無いところがなんとも、修正進行中という感じが漂っている）
このへんは、正規版あるいは、ベータ3とかでJavadocと配布jarが一致した時点で、チュートリアルを書いてもいいな（というか、CodeZineという手もあるような）。
_ 今、熱いのはここだ
と書いてから、炎上って言葉は「熱い」からきてるのかもしかして、と思ったけどやっぱ、火事は火事だな。
で、火事ではなく、良い意味で熱いのが福盛さんのところで進行中の 「アルゴリズム＋データ構造＝プログラム」？ 本当に？。
どういう話かの要約は次のであってるかな？
プログラムは、アルゴリズムとデータ構造から成り立っていると言われているけど、インターフェイスって鼎の一本の脚くらいの重要性があるんじゃない？ だからインターフェイスにもっと着目したほうが良い。
僕は直観的には・ティアが異なる気がする・しかしティアと言うとアルゴリズムとデータ構造だって異なるティアじゃないか？・ならばその3つのティアでプログラムというのはもっともではないか？・他に同格のティアは本当に無いのか？ と思った。でもそこで止まっているので成り行きに注目中。
ちなみにインターフェイスは独立して洗練させることができるから、データやアルゴリズムとは独立しているのは間違いなさそうだから、あとは同格かどうかに尽きると思う。
それとは別に「面のイメージ」でということからはインターフェイスではなく「界面」を使ったほうが良いのかな。
（ちなみにYakumo Projectにも注目。Seasar2の翻訳プロジェクトと言い、こっちから向こうへというのがぼつぼつと出始めたのはきっと良い事なんだろうと思うが、ごくたまに来るsubjectにrjbとか入ったメールに返事書くのでアップアップな僕としては見守るしかないのであった）
追記：おお、書いてみるものだ。トラックバックでさらにいろいろ出てきた。おもしろい。ところで、ビジネスシステムだと、RDB＋ビジネスルール＋通信＋UI＝システム（＝広義でプログラムと言って良いと思う）だと思うけど、データ構造はRDBMSへ収斂、アルゴリズムはビジネスルールとして（ずいぶん薄っぺらな感じではあるが）収斂（で、その上にワークフローがあるんだと思うけど、ワークフローについては真の定義をわかっていない可能性があるので眉唾）、メッセージは通信（ノードをネットワーク上のホストに限定せず、同一プロセス内のオブジェクトとしたって良いと思うから、とてもスケールがある−というのは大島さんのところから考えたこと）、でUI（ワースの頃は、RPGとかCOBOLのようなソフトウェアサイエンスからは異質な世界でのレポート出力こそが一番の関心事だったのだと思うが−だから出てこないのではというのはbabieさんのところから考えたこと、今はインタラクティブだ）。で、ここでの「通信」がプログラムインターフェイス。で、同じインターフェイスという言葉で括れるてはいるけど、UIとPIは独立したティアとして別に考えたほうが良いのではないか？ で、現在のプログラミング（ビジネスシステムと限定するとよりしっくりする）ではデータ構造はデータベースという形で外部にあり（データ構造をモデルと言い換えるとよりしっくりする気がする）、アルゴリズムは全体としてのフローによって表現されてはいるけれど、個別のルールにまで落とすと単なる条件判断に過ぎずプログラムの構成要件の一つというほどのことでは無いようにも思える。そうすると、今のプログラムで一番重要なのは他の何者でもなくインターフェイス（UIとPI）であり、もうアルゴリズム+データ構造というのはミクロ過ぎて意識する必要が無い（C++のSTLにアルゴリズムというテンプレートクラスがあるけど、コレクションを含めてライブラリ化されている−で規模が大きいライブラリとしてのRDBMSもある）のではなかろうか。
#で、いい加減な結論だけど、ギークがメーカーに不在(という最近の話題)なのは当然で、UIとメッセージがプログラムの先端(Ajaxは象徴的に象徴なわけかも)だからということに繋げてみせたり。
#にもかかわらず、検索技術とかが実はその大元にあったりするわけで、アルゴリズム+データ構造が命な分野はあるわけだし(そこに富豪検索とかがからむのが検索2.0か?)、bainary2.0ですな(でもこれはABIという意味ではPIってことなのかも)だったりもするのだが。(ここの#は2.0と書きたかっただけだけど)
2005-11-23
_ NetBeans5でデータベース探検
NetBenas5のチュートリアルの最初の部分（データベースエクスプローラ自体の利用と、ウィザードの用意の部分まで）。
この後、実際のConnectionManagerやらを利用してJDBCのConnectionを使っていろいろすることになるわけなので、まだ前置きみたいなもんだけど。というか、プログラム作ってないし。
3:05：最初にウィザードを作成するときにcustomを選択していたために、ファイル作成と連動していなかったことがわかったので修正。とりあえず、接続先選択のページまで。
_ Wizardってなにものだ？
上のに関連して、VisualとWizardの関連がビミョーだ。
Nextして良いかの判断はWizardが行う。これは良い。IteratorはWizardだけを意識するから。しかし入力を実際に受けるコントロール（Jxxx）はVisualが持つ。これも当然と言えば当然。
なんか、モデルとビューが逆転してるみたいなんで、そこでWizardはモデルではなくコントローラと考えてみる（モデルはコントロールが持つし）。
で、操作が双方向になるのだが、ここがあまり気に入らない。
ビュー→コントローラで、入力受けたからNext表示してOK。コントローラ→ビューで入力教えて。
これ、モデルとビューが逆転した感じに見える。モデル→ビュー（おれ変わったからカキコよろ）、ビュー→モデル（データくれくれ）。
しかも、ウィザードが作成するソースがまたわけわかめ。
Wizard→Visualでデータ寄越せとやるなら、Componentの参照ではなく最初からVisualの型でフィールド作るべきだし（キャストはいやだね）、コントロールがprivateなのも妙な感じだ（これはマーティーのデフォルトだからで、これをパッケージプライベートにしてやれば良いのかも）。
逆にVisual→Wizardでイベントを出したくても逆参照が無い。
……
そうか、コントロールをprivateにするのと、Componet参照の2つを取り払って、Wizard→Visualの単方向にすればきれいかも知れない。どうせ内包するし、イテレータからは実際のVisualはWizardによって肩代わりされるのだから、WizardはViewのフロントコントローラでVisualとは密結合と考える。Component参照とするところが奇妙なのだろう。
#と、NetBeansのサンプルを見ずにいろいろ考えてみたり。
2005-11-24
_ 登極せし者は則ち王
始皇帝―中華帝国の開祖 (文春文庫)(務, 安能)秦始皇帝（もっともこの時点では秦王政）は、前の秦王の実子ではなく宰相呂不偉の子供であった（公然の秘密というやつだ）。それでいろいろ陰謀や策謀が巡らされる。まだ、少年の秦王政もいろいろ悩まないわけでは無い。もし風説が事実ならば血のつながりはない弟が本当の王かも知れない。実際に弟を真の王として秦王政に対してクーデターを図る動きもある。それが大義なのだろうか？ いったい、自分は真に秦の王なのか？
そこで賢人の蔡択が教える。「登極せしものすなわち王」
近代（2500年前かどうかはあまり関係ない）の法によって成り立つ国家においては、正当な手続きを経て王位についたものはその出自がなんであれ、それが正当な手続きを経た（法に則っている）というその1点において何の問題もなく正統な王である、ということだ。Y染色体がどうのとかはまったく関係がない。
エロスを介して眺めた天皇は夢まぼろしの華である―御落胤と偽天皇(玉川信明)
アナアキストの玉川氏のまとめた微妙な（いろものっぽいものが多分に含まれているのだが、蜂須賀家の娘のエッセイとか滝川博士の解説記事とかまともなものが無いわけではない）色彩を放つ御落胤や南北朝のあれこれについての本である。
何度か北朝天皇家には血筋がどうした関係の危機があった。おそらく最大の危機は南朝の系譜をひく(と自称する)熊沢天皇らしい。なぜならGHQもからんだ戦後の国家体制の見直し中のことだからだ。
既に明治時代に、南北朝時代については南朝を正統とするという形で決着が着いている。足利尊氏は逆賊で、楠正成は忠臣というやつだ。これについては大逆事件の時に一躍クローズアップされた問題であった(文部省の責任が追求され第2次桂内閣が教科書問題の責を取って総辞職するという結果になった)。この問題の結論は、当初は南朝が正統ではあるが、後小松天皇(北朝)に後亀山天皇(南朝)が正式に譲位したのでその後は北朝が正統というものだ。実際にはこの譲位自体が怪しげなものだったために後南朝問題という形でしこりが延々と残ることになるわけだが(それにしても長祿の変は無道だ)、それが怪しいかどうかは正式な手続きを踏んでいるかどうかに比べれば瑣末事項だ。則ち正式な皇位継承の手続きを経て登極せしものすなわち王。
その意味で熊沢がGHQに訴えたというのは興味深い。その時点で正式な手続きを特権的に持つ法としてGHQを想定したのは良い着眼点だ。
いずれにしても、これら古き時代においても、なぜその時点で今の天皇が天皇なのか？ という疑問に対しての結論は、それが登極したからだ、という点にある。逆に言えば明治時代に南朝が正統であると決めたのも、それが正規の手続きを踏んで登極したのが南朝の側であり、北朝はどさくさまぎれに正規な手続きを経ずに天皇となったという点が問題なのである(正確には後醍醐天皇は北朝の光明天皇に譲位しているのだが、偽の3種の神器を渡しただけだから光明天皇は正規の天皇ではない、ということらしい。でも元々の3種の神器は少なくても安徳天皇といっしょに壇ノ浦に沈んだはずだから偽とは一体なんなんだか不思議な話でもある)。
結論は、単純。染色体や血は関係ない。それが正当な皇位継承の手続きを経たかどうか、だけだ。
それにしても、
熊沢天皇がこの隠れたる後南朝の史実を指摘したことは正しい。しかし、それ故に、南朝の後胤に皇位継承権があるというのはおかしい。日本国憲法において世襲の天皇というのは、明治天皇の後子孫を意味するのであって、「万世一系ノ天皇」の語は既に省かれている。
と喝破した滝川政次郎博士が昨今の議論を見たらどう考えるだろうか？ なんで今頃になってまた血を(Y染色体と装いは変えてはいるわけだが)持ち出すんだろう？
追記：応仁の乱も最終的に西軍は南帝を担いでいたりするのだが、子供の歴史の教科書を見てもそのへんは見事に無視して単に細川と山名の政争ということにしている。相変わらず後南朝というのはタブーなんだろうか(単にややこしいだけとも)？ 多彩なり室町時代、豊かなリ室町時代。子供の頃、歴史年表上では結構な長さの室町時代なのに、鎌倉時代−建武の新政まではそこそこ詳しいのに、急に御朱印船貿易、金閣寺、銀閣寺、信長が出てきて楽市楽座でまた詳しくなる、と室町時代がすっ飛ばされるのが不思議だったのだが、それだけに興味深い時代ではある）
2005-11-27
_ 久しぶりに最近はゴール人
ゴール女かも。そう言えばジプシー女だし。あの国では女性なんだろうか？
_ で、初台から帰ってきた
つくづく、おれは、あれが好きだということがわかった。
なんでか知らんが好きなものは好きなわけで、すごくおもしろかった。
とくに、玉が2つあって触り方で音高が変わるやつ(エレクトロニック・ラーガ)。
4つの部屋を順に回るやつ(《ものと音，空間と身体のための4つの作品》――なんか椅子が違うぞ)なんて多分19.2周くらいは楽しく過ごせそうだ。1周で交代するのは残念だ。
子供は江渡さんのModulobeにすっかりはまってしまってずーっと作る場所を占有してたり。で、家に帰ってからもPCに向かってなにやらいろいろ作っている。これは、すごく良い作品だ。だって自分でも作りたくなって(フィードバックが得られるのが大きいのかも。それと動きがおもしろいとかいろいろ)、しかも実際に作れるわけだから。
こういう作品っていうのは、コンピュータならではだなと、家にある岩井俊雄さんのエレクトロプランクトンとかシムチューンとかを思い返してみたり。
メディアってのは口から白い綿を噴出したりするわけだが、ちょうどそんな感じで、どこかに蟠っている白い綿がメディアにふれることでぼわぼわ湧き出してくる、いったいどこにそんなものが詰っていたのか不思議なくらいにいろいろ湧き出してくるのだが、どこに詰っているのやら。
帰りにトルコ料理を食いながらの子供との会話：「林檎が落ちてきて、ああ食べようってだけじゃだめなんだよね？」
「どうして？」
「なんで落ちてくるんだろう、と考えるのが重要なんでしょ」
「ああ、そうか、その通りだ。だけど、それだけでもないような気がするな」
「どうして？」
「なぜ、と考えるのはすごく重要で、それは学者だ。考えなければ何も広げることはできない。でも、それだけでもだめだと思う。さて食べるか、でもこの赤いの取ったらどうなるんだ？ 赤いのは何かに使えないかな？ 焼いてみたらどうだろう。煮てみるってのもありそうだ。すり潰したらもっとおいしく食べられるかも知れない。塩を振ってみたらどうだろう、とか、いろいろ試して、違う食べ方をしてみるってのも重要だと思うな。多分、それは技術者だ。そうやって失敗したり成功したり、なぜと考えるのとは別に今あるものをあらゆる手段を試して別のものに変えてみる人が必要だ。」
「そうかぁ」
「いずれにしても、ただ落ちてきた林檎を拾って食べるだけじゃだめだってことは変わらないけどね」
その時は考えつかなかったがなぜ落ちたか考える人と、どうすりゃもっとうまく食えるか考える人、でももう１人くらい居たほうが良い。ものが落ちている瞬間を切り取って「不安定」というような題を付ける人だ。
2005-11-28
_ マウスホイールと叩く
昨日行ったNTT ICCのとこのModulobeだが、マウスホイールでの上下引っ張りをコンソールを叩く動作に割り当てていたのも子供受けの理由の1つみたいだと思い出したのでメモ。
ぜんぜん関係ないが、人力飛行機の歴史をすごーく昔、真崎守の漫画で読んだことがあるが（？年生の科学あたりか？）、足踏みじゃ効率悪いので自転車のように変えることにした、という箇所をはっきりと覚えているのだが、それとちょうど逆なのがおもしろい。どんどん叩くと宙に浮かぶ、というののどんどん叩いて止めないようにするというのは、ロードランナーみたいでもあるけど。
さらに思い出したが、いきなりコンソールを前にすると、とりあえずその時点で表示されているModulobeをいじくることになるけど（いきなりnextとbackを押す人はいないように見えた）、たまたま子供が作ったModulobeが表示されているところにカップルが来て、妙に受けて笑いながら操作してた（これは子供の作品がおもしろいというのではなく、Modulobeそのものが受けていたのだと思う）のを子供が見ていて、後になっても、すごく受けてたね、と嬉しそうに何度も口にしてた。自分が作った作品が赤の他人に受けるというのは、ましてその現場を目の当たりにするというのは、子供にとっては得がたい経験だろう、確かに。というかおれにはそんな記憶はない。
_ 雌雄同体
ブロッガーについて。
ブロッガーには、アフィリエイターと日記書きがいます。アフィリエイターはアフィリエイト広告だけを作ります。日記書きは誰にも伝わらないミームを作り、長年日記で自分をリンクすることにより誰にも伝わらない思いを残します。一方、アフィリエイターは日記書きにトラックバックすることによってリンクを残すことができます。
babieさんがミームについてトラックバックの如く書いているのを見て、そんなことを思った。が、元の文章に合わせて変形させたら、誰にも伝わらないミームになってしまった。
_ REST,Ajax,Remix
つまり、誰かがあの資料のHTMLを100枚1ページとして表示するRemixページをAjaxで作れば良い、ってことだな。でも、おれはやらんけど。でも、練習問題としてはちょうど良さげではある。
2005-11-29
_ REST,Ajax,Remix(続)
とは言うもののちょっとやってみたくなってやってみてしくじった。
最初考えたのは非同期にGIFを取り込み続ければ割りとさくさくうごくんじゃないかってことで、でimgのonlickかonmouseoverででかくする（というか、divを2つ用意して1つはサムネイル用の固定サイズでblock、1つは実際の大きさでinvisibleでblockのほうのonmouseoverでblockにしてクリックで再度invisibleっていうinamodeみたいなやつ）というのを考えた。(追記：しかし考えてみるまでもなくimgタグってHTMLのレンダリングとは非同期に4コネクションくらい利用して処理してるからやろうとしてることはとっくのむかしに実装されているということだったり)
が、いつもここで失敗する（ってことは何度目かだ）。
(手元にコードが無いのでうろ覚えだからそのままでは動かない)
var imgs = new Array();
function open(http, index) {
var name = "img" + index;
http.open("GET", "....img" + index + ".gif", true);
http.get();
http.attachstatechange = function() {
if (http.asyncState == 4) {
imgs(index) = http.responseBody;
document.all(name).src = "javascript:imgs(" + index + ");";
index = next_index(index);
if (index < 0) return;
open(http, index);
}
}
}
function start_fetch(index) {
var http = new ActiveXObject("MSXML.XMLHTTP");
open(http, index);
}
function start() {
for (i = 0; i < 219; i++) {
// 実際はもっと複雑
html += "<img name=\"img" + i + ";\"/>";
}
document.all("imgs").innerHTML = html;
for (i = 0; i < 4; i++) {
start_fetch(i);
}
}
何をしくったかといえば、img src="javascript:xx"としておいて、xx = http.responseBody;としてイメージを突っ込もうとしたところ。
src="javascript:変数"ではXBMしかサポートしてないらしい。
そして、既にご存知のようにdata:には制限がある（まったく動かないか、または約2K以内。まだ確認してないんだが）のでそれも利用できない。
つまり、せっかく非同期にイメージデータを取り込んでもなんの役にも立たない。（追記：っていうか、そもそもバイナリを正しく取り込んでるんだろうか？ 妙なUTF-8変換とかされてたりして……）
運が良ければXMLHttpRequestの結果がIEのキャッシュに入ってそれが利用できるかも知れない（img src=のURLをステートが4になった時点で設定すれば）が、スニファしながら観察したところリクエストをやり直しているように見えた（要確認。うんざりしてたのでまじめに見てないから、100%の確信は持てない）。
それにつけてもdata:でもjavascript:でもどっちでも良いけどどうにかしてimg.srcにデータを送り込めないものか。……mimetypeのプロパティを設定してから変数に値を突っ込むってのは試してなかったから、そっちをやってみるかな？
追記：いろいろめんどうそうだ。JavaScriptとIMGのブックマーク
_ 上のリストで好きなところ
そりゃ、クロージャをstateChangeイベントハンドラとして設定するところだ。あそこでのhttpという変数は実際には4インスタンスがそれぞれで利用できる。複数のインスタンスを利用したい場合に配列を使ったりしてインスタンスを区別する必要がないってのは良いことだ。
MSDNのサンプルだと静的に定義したfunctionを設定する例(Cでの関数ポインタの利用のようなものだ)しか出ていないから複数のXMLHTTPを利用する場合、どうやってXMLHTTPのインスタンスを区別するか方法が見えない（クロージャ以外のやり方、多分プロパティを利用すれば良いと思うが）。あと、VBScriptだとAddressOfを使うしか方法がないからやはり相当に工夫が必要なんじゃないかな。
_ IE on Firefox
世界中でこれが求められていたのかも（台湾発らしいというかなんだあのリンクは?）。でも、IEのurlmonとレンダラを使うわけだから（しかもインストールしてあるわけだし）、なぜ、IEを素で使わんのかと？ つまるところFirefoxを使っているといいたいだけでは。という実利的な視点とは別に、これ相当なハックだと見た。
This extension is derived from the famous extension IE View, but they are quite different.
While IE View always open IE-only pages in newly launched windows of Internet Explorer, IE Tab can open them in tabs of Mozilla/Firefox.
via ― Kickstart my heart.
（追記：良く考えたら上のblockquoteは変だな。MSHTMLをOCXとして利用する手段は提供されている。IE Viewってなんだかは知らないけど。MozillaのタブをActiveXコントロールホストとして実装したということなんだろう）
2005-11-30
_ 犬はワンと鳴く
IT*Proに rjbが出ている。ありがたいことだ。でもWindowsやSolarisでもイベントハンドラを記述したら即死（の可能性が高い）なので、マネする人が出てこないことを祈るばかりなのだが。単にモーダルダイアログを表示して情報を受け取ったり出力するだけなら良いのだけど、普通に利用すればイベントハンドラを記述したくなるだろうし。
後、ちょっと気になったがもしかしたらJRubyとの対応のためかも知れないけど(Object#send|__send__が実装されていなければ使えないわけだし)、この目的のためならevalよりsendのほうが良いように思える。
require 'rjb' Pet = Rjb::import(ARGV.shift) pet = Pet.new pet.send(ARGV.shift)
やっぱり、pet.の部分は文字列じゃないほうがなんとなく気分が良い。
ジェズイットを見習え |
_ WR [リレーションシップぅぅぅぅ・・・というお約束のツッコミ（笑）。]
_ WR [なんか、ツッコミミスのようなので、謹んで取り消させていただきます。すんませんー]