John Allsopp著「マイクロフォーマット」の話題からです。

この本は（純粋に）技術面では (X)HTML と CSS の話題なのですが、テクニカルな面でのクライマックスは、イベントをマークアップする hCalendar を、二次元のタイムテーブルとして表現された複数のイベントに対して適用するにはどうすればいいか？という話題です。要するに

みたいなタイムテーブルの個々の要素（計５つ）について、それぞれを個々の vevent としてマークアップするためのテクニックの話です。でやはりこれを、DRYなマイクロフォーマットらしく

HTML のあまり知られていない属性をうまく活用

して乗り切っているわけです。まあ、

ふ～ん、こんなんあるんだ

と思って読んでしまえばソレまでなのですが、少し面白がって調べて見ることにしましょう。

というのは、

もしマイクロフォーマットが「無益」ではなくて「有害」であるとするのならば、その根拠は「多重マークアップ」という点

だろう、というのがまず大前提の問題としてあるからです。マイクロフォーマットは、周知のように既存の(X)HTMLボキャブラリを「乗っ取る」かたちで自らのマークアップを行います。ですから、結果として、

HTMLとして正しく、かつマイクロフォーマットの構造としても正しい

状態になるように、注意深くマイクロフォーマットの定義が定められているわけですが、ある意味、これが実現できるケースは「ラッキー」であり、一般に要求するのは難しいのでは？というのが、（もしあるとすれば）有害論の根拠なのですね。まあ、ここらへんの議論は「多重マークアップ」とか「平行文書構造」とか呼ばれるもので、例のキマイラ飼育記（「Microformatsと多重マークアップ」）で指摘していたりします....まあここらへんマイクロフォーマットの本質なのでどうしようもないところなのですが、特に先ほどのタイムテーブルの例だと、

テーブルヘッダ(TH)として、会場情報（横）と時間情報（縦）があり、個々の TDセルが具体的なイベントの中身である

という「HTMLの構造」が、

個々のイベントを示す hevent でマークアップされた（TDセルの）要素の中に、時間を示す dtstart, dtend、会場を示す location でマークアップされた要素がある

という「マイクロフォーマットの構造」と整合性が取れない状態になっているわけです！とはいえ、こういう「タイムテーブルのレイアウト」は非常に一般的なものであるに違いありません。レイアウトは正しいわけです....

まあ、次のような（姑息な）解決方法はあります。

1. 1. TDセルの中に、表示上は CSS で隠すかたちで、時間と会場のマークアップを入れる
2. 2. include デザインパターンを使ってヘッダに書かれた時間と会場のマークアップを引用する

....が、Allsopp はそうではない「真正面からの突破」をしてます。それが TD,TH のあまり使われていない属性である、headers, scope, axis を使うというやり方です。

まあ、具体的に「マイクロフォーマットではこうマークアップするんだ！」というのを知りたい人は、Allsopp の本を買いなさい（まあ、このエントリのソースを見てくれてもいいんだけどね）。この知られていない属性をググってみると、一番キッチリした説明は「神崎先生」にありました（「テーブルとアクセシビリティ」）。一般にはまだそれほど使われていないこの３つの属性ですが、しかしマイクロフォーマット以外のある「使い方」で、とっても重要な属性になりそうなのです....それはですね、

音声ブラウザ

なのです。つまりアクセシビリティの問題であり、大きなテーブル構造を読み上げた時、「そのセルがどういうものか」を聞く人にとって判りやすく「うまく読み上げる」手がかりになる属性なのです。勿論規格としては、「テーブル構造の論理的な関係を明示する」ように定義されていますが、この「論理的な関係」を記述する属性が、マイクロフォーマットと音声ブラウザの双方にとって非常に有益なものだったりするわけです！　たとえば、

scope属性

row か column の値を取って、そのセルがどちらの方向に対する見出しか明示する。

headers属性

その内容セル(TD)が、どのヘッダセル(TH)と関係を持つかを、ヘッダのid属性を参照するかたちで、内容セルに指定する。

axis属性

そのヘッダセルが、どういう性質の見出しであるかを説明する。たとえば上記のテーブルの例だと、「会場」とか「時間」といった説明的な内容がこの属性の値になる。

まあ勿論これらの属性は、フツーの（非音声）ブラウザでは何の意味もない属性です。しかし、今後特に「ユニバーサルデザインを心がけてます」と言いたい人にとっては、かなり重要な属性になるのかもしれません....

「アクセシビリティ」というと、マイクロフォーマットでは例のabbr デザインパターンと音声ブラウザの問題で、

厄介....

というイメージでしたが、ちょっと認識を改めました。あらゆる面で、

論理的な関係を記述する

というのは、根本的なメリットがあると考えるべきなのですね。

 けど逆にこういう headers 属性の適切な処理を、アグリゲータはちゃんと実装しないといけない......逆に厄介、ですね、ふう。

少し「集合知プログラミング」のネタかな。あの本の中で、

Tanimoto係数

という「２つの集合の類似度」を計る尺度を紹介してます。私これは知らなかった....調べてみるとバイオインフォマティクス関連でよく使われているもののようです。Tanimoto 係数のお姿はですね、

集合a と集合b があるとき、
T = N _a∩b/ (N_a + N_b - N _a∩b)
ただし、N _x は集合x の元の数

と計算して、２つの集合の類似度（全く違えば０）を得る尺度です。ですから、

Ａさんが見た映画 = { 崖の上のポニョ, ダークナイト, デトロイトメタルシティ }
Ｂさんが見た映画 = { 崖の上のポニョ, スカイクロラ }

だった場合、Tanimoto 係数は

T = 1 / (3 + 2 - 1) = 0.25

と計算されるわけです....

まあ、「私が知らなかった」のは、こういう「定性的な状態を、数値の値に変換するための手段」というのが、実はいろいろとあるのが現実だからです。たとえば、情報理論でよく使われるハミング距離で考えば（ハミングも人名ですよ）、

「XOR」行の合計 3 が、Ａさんの見た映画とＢさんの見た映画の「差」であるハミング距離になるわけです（Tanimoto係数だと一致すればするほど値が大きくなりますが、ハミング距離だと一致すれば最小の０になります）。

その他にも、いろいろな「（集合の違いなど）定性的とも考えられる「状態」を、違いを表す数値にする」さまざまな尺度があります。まあ、ですから、ここらへん「どれを使うのか」というのは

場合によりけり...

というものです。こういう尺度を使うと、

差の値が２倍だから、中身の違いも「２倍違う」

なんて思うと大間違いなのが一般です。単に大小関係しか信用できないケースがほとんどです。ここらへん大きく見るといわゆる「ノンパラメトリック検定」と呼ばれる統計手法で、

母集団の分布に関する一切の仮定がない検定手法

の手法の一つなんですね。勿論いわゆる「連続な値を計れる数値」でやる検定で、しかも測定値が正規分布するものについて適用される、パラメトリック検定（平均や標準偏差に意味があるフツーの統計）と対応する手法です。勿論、

何でも適用できる、ということは、検定力（要するに「違い」を検出する力）はパラメトリック検定と比較して弱い

という、いわゆる「ノーフリーランチ定理」そのままな結果になるのも事実なんですけどね.....

まあ、一般にノンパラメトリック検定は計算量が多いものが多い傾向がありますから、実はコンピュータの恩恵をかなり強く受けているものです。以前少し紹介した「パーミュテーション検定」も、このノンパラメトリック検定の一つで、「すべてのありうべきデータの組み合わせ」を出しますから、手計算だとちょいとかなわないような計算量になります（一個一個は単純ですけどね）。

とはいえ、「あまりそのスジ以外では知られてないし、検定力も弱く頼りない...」ようにも思うかもしれませんが、いろいろ「プログラマの小技」として使える余地がかなりあるわけです....

たとえば、

コインの表・裏を投げて記録していたが、表が連続１５回出てしまった。このコインの表裏が出る確率は1/2 であると言えるか？

という問題だと、ラン検定と呼ばれるノンパラメトリック検定手法を使って検定できたりするわけです（参考→相関のノンパラメトリックなど）。というように、検定技法というのも、今後のプログラマの教養知識として面白いのかもしれませんね....

さて、去年のエントリでも紹介しているんですが、バートランド・メイヤーの古典的名著「オブジェクト指向入門」の第２版（前半の「原則・コンセプト」）が、去年の１月に出て以来、翻訳刊行が待たれていた後半の「方法論・実践」が、８月２９日に出るようです。

この本は第１版を読んでメイヤー信者と化した人々（私もそうです）にとっては、ホントずっと「出ないかなぁ...」と待たれていた第２版なんでね。原著はかなり前に出ていますから、「英語をガンバりゃね」というのはあるのですが、何せ第１版ですらかなり分厚い翻訳（700ページにわずか足りない）だったのが、「上流工程に踏み込んだ」第２版ではさらに膨れ上がり、960p + 800p と倍以上になってしまったこともあって、「原著読むんだとよっぽど暇のある時じゃないと....」となってしまったのは仕方がないかもしれませんね（苦笑）。

この後半ではやっと Eiffel の解説になります。前半は「原則・コンセプト」と銘打たれていることもあって、具体的なＯＯＰ言語仕様については触れていないのですが、今度出る後半で、メイヤーが自分の理想を実現した言語である Eiffel の具体的な仕様の説明になってきます。第１版でも Eiffel の説明はあったのですが、第１版が出た後で、Eiffel の仕様が進化しちゃって、本の説明が時代遅れになっていたのがようやく解消できるというものです（苦笑...どっちかいうと、それでもこの本の評価が少しも揺るがないのが凄いところ）。

とはいえ、これほど厚くても、「ＯＯＰの原理面（言語仕様に制限されない）でのトピックはほぼ完璧に網羅している」と言っても過言ではない本ですから、「ＯＯＰの考え方」のリファレンスとしても使えちゃう（研究者の書いた本ですからね）凄い本です。技法書というよりも、「コンセプトの解説」が中心なのですけど、観念論に陥らずに「理念」を説いた稀有な本なのですよ！

夏休み読書感想文には時期を外してますが、それでも秋の夜長の読書にどうぞ！

ちなみに、わたしはこの本をきちんと読んで理解している人、あるいはEiffelで網羅されているソフトウェア概念すべてについて自分なりに考え抜いたことのある人を除いて、そのひとをオブジェクト指向の専門家とは認めないことにしています。（オブジェクト指向の広場）

さて、なぜか久々になっちゃったデザパタ話です。まあ、仕事で遭遇した問題なんですけどね...

問題：プログラム中にすでにあるインスタンスに対して、それを少しだけ値や動作を変えたインスタンスが欲しい。再利用するにはどうすればいいか？

1. 条件１：新たに欲しいものと、もともとあったものと、動作が両立しなくてはならない。（両立条件）
2. 条件２：もともとあったものは、抽象基底クラスとして定義されて、その派生クラスが手に入るものとする。その時、再利用すべきオブジェクトの実装クラスは、何種類もあるものとする。

....要するにですね、既存インスタンスをコピーして使うこと、の問題なのです。この時、そのコピー元の実装クラスがバラバラなのです。ですから、

「少しだけ変える」のに、新たに継承クラスを作るのが現実的ではない

というのがポイントです。なぜなら、コピー元実装クラスがたとえば３０種類もあるかもしれませんし、それが増えたらコピー先実装クラスも増やさなくてはならなくなります。メンテナンスの困難は避けたいですよね。

まあもちろん、これ「DRY原則」をプログラムに適用する、という理念的な目標があるわけです。一度（複雑なコンストラクタによって）明示的に作ったインスタンスを、もう一度同様に複雑なコンストラクタの定義を書いて、作り直すのを避けたい、というのは当然でしょう。

また、クラス間の関係としては、これは一種の「多重継承」みたいな格好になります。しかしこれは「事後的な（あるいはインスタンスの上での）多重継承」と呼んだらいいのでしょうか...

というような関係になるわけです。Java で書いていますから、「多重継承」とは言っても言語的にできませんので、代用策を考えます。すると、これの解決はおおまかに２つのやり方があります。

1. 1. コピーするときに、値を修正しながらコピーする。勿論これは手で書いてはならず、「コピーするメソッド」を作って、プログラムとして自動的にコピーすべきである。だから、これは Prototype パターン（の変形）になる。
2. 2. 抽象基底クラスを継承した新しいクラスを作り、その中でコピー元インスタンスを保持する。この新しいクラスはコピー元クラスのインターフェイスをすべて備えて、かつ処理は実質的にコピー元インスタンスへの委譲（delegate）になるが、「変えたい内容」は自分で処理することになる。こっちは一種の Decorator である。

まあ、2 については、

1. 2'  新しいクラスを作る...のではなくて、AOP の発想でかぶせる

というのもないわけではないでしょうが、直接インスタンスを書き換えるタイプの AOP では「両立条件」が満たされないので、プロキシタイプの AOP でないとまずいでしょう。

この時ですね、「新しいインスタンスも、コピー元のインスタンスもどっちも有効」という両立条件がかなりキビシイ条件となります....実はですね、私が遭遇したケースでは、

こんなこともあろうかと（大げさ..）、そのインスタンスが Immutable で定義されており、Extrinsic なデータを受け取り、不変の Intrinsic なデータを参照して書き換えて戻す動作で一貫していた

ので、生成後にコピー元インスタンスが「内部状態を変更しない」のです...だったら、複数のインスタンス（自分自身と Decorator 内のインスタンス）が同じモノであっても、少しも問題がないのです....まあ、これは一種の Flyweight パターンになるわけですが、一般に Flyweight は

同じインスタンスを共有することで、リソースの無駄を省く

ことが強調されますが、

DRY 原則によって、「同じような複雑な設定を何度も繰り返さない」こと

を目的として使う...というのもアリじゃないかな？とも思われますね。

ですから、DRY、再利用、Flyweight、Immutable というキーワードは、たとえば Decorator パターンといったやや複雑な構造を持つ応用編でも、実に有効なのです。あまり現在では重視されているとは思えないのですが、インスタンスの Immutable 性というのは、かなりフレームワークの基本性能を向上させる重要な性質を持っているのでは...と改めて実感しちゃいました。Immutable性とは、ちゃんと心がけて「可能ならば与えておく」べき性質なのかもしれませんよ！

前回「『Powers of Ten』っぽいかな？」を書いた後で、 あ.....書いたときは「予感」してたんだけども、ちゃんと解ってなかったな.... と反省したことがあったので、それを補足しましょう。ふう、修業が足りませんね！

それはですね、Firefox+Operator で、geo マイクロフォーマットを使ったページを見ると、こういう感じでいろいろなウェブサービスに対するリクエストを発行できたりします。

 ここでは、GoogleMap, MapQuest, Yahoo!Map の３つのサービスと、GoogleMap で使う「ファイル交換用フォーマット」である KML（XMLのボキャブラリです）での出力が選択できます。要するにこの Operator は、マイクロフォーマットが埋め込まれたページに対して

それをどう扱うかについての多様な選択肢を提供する

プラグインとして提供されているわけです....

しかし、逆に考えると、ここで geo によるマークアップがされたエレメントが何か...と考えると、

<a href="http://maps.google.com/maps?t=h&amp;ie=UTF8
   &amp;ll=27.987778,86.944444&amp;spn=0.720326,0.725098
   &amp;z=10">
<abbr class="geo" title="27.987778;86.944444">エベレスト山</abbr></a>

というようなマークアップを私はしているわけです。つまり、GoogleMap へのリンクと、そのアンカーテキストに対する geo マイクロフォーマットのマークアップが

実質重複したカタチで

なされているわけです。勿論コレ、DRY に反してるのが残念と言えば残念なのですが、本題はそういうことじゃないです。それよりも、

「geoマイクロフォーマット」と、「GoogleMapへのアンカータグ」の関係
＝
「Webサービスへの interface」と、「Webサービスの実装」との関係

ということになるのでは....ということなんです。

まあ、マイクロフォーマットは「現在成長中」なセマンティックな試みですから、「よく使われているマイクロフォーマット」というと、

既存の知られた仕様をベースにしたマイクロフォーマット

というのが多い（まあ、例外は hReview とかいろいろありますが）のは当然なので、全体から見るとあまりまだ目立っていないのですが、今後を考えてみたときに、「マイクロフォーマットがこうだから、マイクロフォーマットに合わせたインターフェイスで、Webサービスを提供しよう」という流れになってくるのは、実は必然のように思います。そういう側面から考えたら、

GoogleMap へのアンカータグ

現時点での一番解りやすい（とページ作者が思う）地図への参照と例示

geoマイクロフォーマット

将来に亘って、具体的なサービスに依存しない恒常的な地図情報の記述

という役割分担のような格好になる（まあ、それが「セマンティック」と「プレゼンテーション」の関係なのですが）ということなのですね！

まあ、この geo は現時点で非常に有用なサービスが稼動していて、しかも「マークアップの自由度」がかなり薄いマイクロフォーマット（地図は二次元情報ですから、ただ２つの独立パラメータに帰着できますね）なので、ここらへんが露わに見えたようにも感じます....

今はGoogleMap がメジャーな地図サービスの一つだけども、２年後もそうだ、と確信できる人は多分、いない

ということにもなるわけです。リンクは切れたら終わりですが、マイクロフォーマットはそうではありません。「恒常的な情報」をマークアップする唯一の（抽象化された）手段として、実はマイクロフォーマットの占める位置は極めて重要なものになってくるのではないのでしょうか？

このところ、休みの日に今まで知らないカフェに用があって行くことが多いのですが、そういう時に重宝するのがやはり Google Map です。単に行きかたを地図で確認するだけではなくて、航空写真で街のイメージをつかんでおけば、ちょっとしたシミュレーションになって全然迷わずに目的地に到着でできる...なんてのは、別に目新しい話題でも何でもないです。すみませんね！

そういえば私は小学校に上がる前の頃でしょうか、地図が大好きで、親に高校生向けの地図帳を買ってもらって、その「絵」で飽かずに遊んでいた記憶があります....地図ってそれ自体として、とてもイイものですね！空想の中ではどこへでも飛んでいけるのです。

ですから、Google Map ででも、自分が行ったことがなかったり、行けるわけがないようなところへでも、行けるわけです。日本国内だと結構、住宅地図並に詳細まで完備してたりしますが、たとえば「ニューヨークの中心」とか「 ロンドンの街中」でも、海外は道路までくらい...という感じみたいです。ちょっと日本が異常なのかな。

ですから、これは逆に、絶対に行けないような「ロマンな場所」の方が面白いのかもしれません....たとえば、「 エベレスト山」「 アマゾンの河口」「 ネス湖」「 世界貿易センタービル崩壊跡」とかね...でこういう時に威力を発揮するのが、

１０進表記の緯度・経度

なんですが、

１０進表記の緯度・経度＝度.(分+（秒/60))/60)

でアタリマエのように計算できます（というか、こういう計算が必要になる、ということ自体ごく最近の現象のような.....GoogleMap 同様に、geo マイクロフォーマットでもこれで指定します。このページは付いてますから、FireFox+Operator で見ても面白いのでは？）。元々Usenetの登録に所在地の経緯度を示すいわゆる「ＩＣＢＭアドレス（ミサイルアドレス）」が必要だった....なんてことはあったりもするのですけどね（シャレですよ）....けど、GeoURL ICBM Address Server（経緯度でブログをカテゴライズするアグリゲータみたい...） なんてのがありますね！。

こうやってGoogleMapで遊んでいると、一番連想するのはデザイナーで有名なイームズが作った科学教育映像作品の「Powers of 10」(YouTube)です。これは公園にピクニック中の男性（１ｍオーダー）から、大宇宙の果て（10²⁴ｍオーダー）、大宇宙の果てから原子核の世界（10^-16ｍオーダー）にまで自在にスケールアップ・スケールダウンして、対数尺度の世界を見せる....という、いわゆる「コスミックズーム」の先駆の映像作品です....こういう感覚で少しアタマをクールダウンするのも、暑い夏をすごす良いレクリエーションになるのではないでしょうか。

そういえば 1 Google Googol = 10¹⁰⁰ でしたね...Googol とは、「あまりに大きすぎて、数字で表現できても、宇宙に対応するだけの何かの量がありえない数」のことです。

買い物です....懸案だったオーディオインターフェイス、というもの（ＤＴＭ話の続きです）。

まあ、結構MIDI機材もあるので、それをコントロールするための端子が要る...という事情から購入したのですが、ポイントはですね、

でも、やはりパソコンに元々付属されているオーディオ機能と、
音楽鑑賞、DTM向きの市販されているオーディオインターフェイスとでは、
性能や音質に天と地の差があります。（コニーの非常識なDTM作曲講座）

と、言われるくらいに「音が改善するの？」という関心でした。

....というか私は、ハッキリと「コンピュータでの音」って苦手です。ＣＤとか聞いてる人の気が知れない、ってずっと思ってました。どうも堅すぎるし、その癖にスカスカで、これだと「音像のカリカチュア」みたいな感じにしか聞こえなくて苦手だったんですね。そもそも仕事の時に音楽なんてかけてたら、気が散ってダメな人ですから、「コンピュータとは音楽を聴くものに非ず」という感覚が強かったわけです。

で買ったのはこの世界でのヒット商品の Roland UA-25EX（実売24,900円）。で....ですが、やはりお金を出しただけあって、別次元の音になります！ 音のコマ数が増えたというか、リアリティが全然違うんですね。単体のCDプレーヤーとかそういう感じの音になります。ふう、これならＯＫです、楽しめます。いかにデフォのサウンドカードのアナログ回路が適当か...ということですね！

土日は手持ちのMIDI機材をこのオーディオインターフェイスで繋いで、ちょい録音でも....という感じ。この UA-25EX にはオマケで Project 5E という Roland の作曲ソフトが付いているので、その付属でのソフトシンセがまた増えたので、その音の確認とかしたのですが...意外にここらへんのプリセットの音って

数あるんだけど使えない...

のでがっかり。インターフェイスとか面白いんだけどね...マジにお金出して買うべきということ。どうも存在感が薄いんです。やはり手持ち外部機材のKORG Prophecy の太く存在感があり、主張の強い音に頼りそうな感じです...（特にベースと管が大好き！）

.