日々の破片

_ 謎現象

と書いた瞬間に、Windows2000のIEとWindows XPのIEの差かな、と思いついたので明日もう一度Windows2000側でチェックの予定（追記：チェックした。IEはUTF-8で送ってる）。

現象：UTF-8で書いた（漢字を含む）metaタグも何もないHTMLを、Windows2000のIE（バージョン不明）に送る。このとき、content-typeはtext/htmlでcharset指定なし。IEは、記述したとおりに表示する（UTF-8と理解しているように見える）。

IEからINPUT(type=text)へ漢字を入れて送る。

すると、formデータはシフトJIS（といっても当然CP932のはず）で出て行く。

サーバーはそれをUTF-8と解釈する。ドカン。

仮説：IEは、formデータを送信元のcontent-typeに従う。無設定ならANSIで送る。日本語だとCP932。

検証：で、試してみた（XP IE6SP2）が、そんなことは起きないなぁ（ちゃんとUTF-8で送っている）。

追記：IEは正しい。サーバーのアプリケーションがどこかで妙なことをしているらしい（8ビットずつをANSIとしてさらにUTF-8にしているとかかな？）。手のうちようがないのでメール発信。

_ MSのやる気のないActiveXコントロールをほじくりだす

AJAXのXMLHttpRequestみたいな例外はあるけど、相手にされていないものにはたいてい理由があって、そんなものをほじくり出してもやっぱり役には立たない。

でも、その役立たずな理由を考えるということには意味が無いわけではないだろうということで、ひさびさにいじろうとしたけど、それにしても、MSDNの記述はことごとく間違っていてそのとおりに書くと動かないは、全然サイトは更新されていないは（「わ」かな？）、MSのこのテクノロジーにかけるやる気のなさには驚くばかり。

たとえば、MSDNに出ているHTMLの書き方の例。

<OBJECT
  classid="clsid: D45FD31B-5C6E-11D1-9EC1-00C04FD7081F"
  CODEBASE = "#VERSION=2,0,0,0"
  id=Agent
>
</OBJECT>

これ、動くわけないけど、ついコピペしてずーっと悩んでいた。というかnullにならずになぞのオブジェクトを返してくるDocument#getElementByIdもちょっと勘弁してほしいが（プレースホルダーオブジェクトとかなのかな？）。

っていうか、リンク切れもあるし。

_ 語彙に関する仮説

語彙が乏しい人は（乏しくなくても良いかも知れない。しかし、乏しいだけに言葉に対する耐性が無いという可能性もある）、ある言葉のコンテキスト（ニュアンスって書けよ>オレ）がわからない。なぜなら、その言葉を知らないから（普段、接していないから）、辞書上の額面どおりの意味にしか取れないからだ。（でも、辞書をひく人はましなわけで、ニュアンス面での齟齬はあっても、話は通じる、はず。辞書もひかなければ、単に罵られたというように勘ぐる可能性が高いかも知れない）

自分が普段接してない言葉であっても、それを日常的に使う人間には正しくニュアンスがわかる。逆にいえば、語彙が乏しそうだな、と思ったら、使う言葉は1000語くらいにおさえてやったほうが良いかも。

たとえば、粗忽といえば粗忽の宿とか粗忽の主とか、用例的には軽いのりの意味しかないわけで、「おいおい（しっかりしてくれよ とまでは付かない）」といった程度のニュアンスしかないわけだ。でも、まあ、使う側がどういうニュアンスをこめているかはわからないのもまた文章。その意味じゃ相対化されてはいるわけだが。

ってわけで、「言葉尻をとらえる」のはバカ、という言葉が今ほど意味を持つ時代もあるまい。みんなが顔も合わせずに書いた文字でやり取りしてるわけだからねー。

_ メイヤーと継承

mumrik2さんの「Open-Closed Principle」を読んでいて幾つか。

Object-Oriented Software Construction (Book/CD-ROM) (Prentice-hall International Series in Computer Science)(Meyer, Bertrand)

どうも幾つもの論点が入り混じっているように思える。それは当たり前で世の中は単純じゃないから原理だけじゃうまくいかない。でも、それにしても基本となる考え方はあるわけで、それは押さえてから口を利いたほうが良いだろうと原理を求める。と脱線してるけど、そういうとこが同じようにあるように思う。

1.変更のための継承（元のコードが残る）

2.コピペで済む場所はどうでも良い場所だから別にいいじゃん

3.再利用できなくなったオブジェクトを継承を使って残すのって変だ（1.と同じか）

4.コード抽出のメリットは？ 別オブジェクトでいいじゃん

5.でもテンプレートメソッドパターンは便利だよね、実際。

6.重要な2割をガチでやれば残りはどうでもいいよね。

7.重要な2割を最初から見抜くのは難しい。しかも本質なんだからコピペのはずない。つまり継承できるようなものではない。ライブラリのほうがいいじゃん。

ってことなのかな？ 6と7の当たりが行ったり来たりするのでわかりにくいのかな。

っていうか、ネタで言ってるんじゃなければ、デザインパターン読め、というのが答えのように思うのだが。

Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing Series)(Gamma, Erich Helm, Richard Johnson, Ralph Vlissides, John)

（原書のほうを載せてるのは、そのほうが読みやすいだろうと思うからで、僕は日本語のやつを読んだけど）

メイヤーは先駆者だけど、それだけに宇宙飛行士的なところがあるように見える。わかりやすい例だと多重継承に対する自信とか。Eiffelはもしかしたらすばらしいのかも知れないけど、少なくても今はメジャーではないし、それには理由があるはずだ。もし処理系の実装が難しいというのが理由なら、そんな難しい処理系を使って安全なのか（メイヤーの会社では何かあったらすぐ直せるから安全だろうけど）とか（でも、この言い方はFUDだな）。もし使いこなすのが難しいのなら、それはだめだろ。ただ、有名な契約の考え方とか、例外についてとか、たくさんたくさん定義した。それらが価値があるのも間違いないところ。でも、それが現実に大して受け入れられていないEiffelだとしたら、別の落としどころがあるはずだ。

今のところ、20%の見極めが難しいに反対する人はどこにもいないはずだ。

難しいからそこは決定したらいじりたくないし、いじるならその20%だけを安全に挿げ替え（すげかえってこう書くのか）たい。

4人組のデザインパターンは、実装継承の代わりに（これはうそだな。テンプレートメソッドパターンのような使いどころも出ているから）なる、再利用しやすいオブジェクト設計のパターン集だ。

これがその（少なくても現時点での）落としどころということになっていると思う。実装継承は最低限にして、インターフェイス継承を多くする。実装そのものの再利用ではなく、設計を再利用するための仕組みで、実装物は交換することを主に考える。JavaもC#もこれだ。

ってことでいいのかな？ アイフルー。