Konqueror
そういえば、このサイトが Safari ではどう見えているのだろうかとふと思った。Safari は KHTML を使っている。そして、元々 KHTML は KDE プロジェクトが開発したレンダリングエンジンだ。同様に製作されたのが視覚系 UA でもある Konqueror である。
ということで、Vine Linux 3.2 において KDE を apt-get install task-kde で導入してみた。無論、Konqueror を呼ぶだけのために。KDE のウィンドウマネージャは重いので起動させない。WindowMaker で十分。
……結局、KHTML は Gecko や Opera と同様に、標準準拠レベルの高い優秀なレンダリングエンジンだけあって、全く問題がなかった。これなら、たまーにチェックしてやるぐらいでいい。About の UA 一覧にも追加した。
やはり優秀なソフトウェアは、利用できるデータの移植性が抜群だ。IE もこのぐらいになるといいのだが……。
注文の多い常連客
注文を出していた本が届いたというので、書店まで足を運んだ。そうしたら、思いがけないブツも転がっていたので、ついでに購入。
- 「太陽の汗」（神林長平 ハヤカワ文庫SF）
- 「猶予の月（上）」（神林長平 ハヤカワ文庫SF）
- 「猶予の月（下）」（神林長平 ハヤカワ文庫SF）
- 「死して咲く花、実のある夢」（神林長平 ハヤカワ文庫SF）
- 「鏡像の敵」（神林長平 ハヤカワ文庫SF）
- 「言壷」（神林長平 中公文庫）
- 「イノセンス After The Long Goodbye」（山田正紀 徳間デュアル文庫）
- 「ユリイカ 2005年10月号 特集 * 攻殻機動隊 STAND ALONE COMPLEX」（青土社）
神林長平の作品が注文品。残りがついで。
それにしても、まったく早川書房はいい時期にフェアを開催してくれたものである。版元品切だった作品が軒並み再版されている。S-F マガジン 2005年10月号を見て、即座に注文を決意した。この期を逃してはならない、次はないかもしれない、と。「言壷」はそのついでである。
思えば、P・K・ディックの著作を大量入手した時も、丁度「マイノリティ・リポート」フェアが開催されていた。今回注文を出した同じ書店には、早川から出ていたディックの作品がそれこそ平積みされているという状況が発生していたものだ。小遣いをはたいてせっせと買ったのが懐かしい。
私にとって、神林作品の始まりは、短編集「狐と踊れ」だった。作品の名前としては、アニメ化云々の話で書店が盛り上がっていたので、「戦闘妖精・雪風」の方を先に知っていたのだが、まずは初期作品から読むのが妥当だろうと考えて、「狐と踊れ」をチョイスした次第である。
そして、ああコレなら次に進んでもいい、と思った。後はもうハマるだけである。
私は著者略歴を見る。そこには代表作と（恐らく）編集者が認めている作品が列挙されていることが殆どだからだ。そこで私は、初めて神林氏が高専出身だということを知った。
かなり衝撃だった。確かに、高専を五年間で卒業しようとはせずに退学したり休学したりして、ちょっと違った道を歩む人間は割と多い。休学して一年ほど外国に行ってくる、なんていうのは最早ザラである。また、退学して別の道を歩む人間も結構いる。純粋に高専に嫌気が差した者もいれば、写真家になりたいといって専門学校へ行ってしまった者、果ては三年で辞めて芸術大学に進学した者までいる。
「それにしても小説家とは！」と感じたものだ。だが、そんなに不自然ではないな、と考え直した。一般的に、工学系の学生は文章を書かないと思われがちらしい。しかし、実際は違う。事あるごとにレポート、レポート、レポート。演習をやった、じゃあレポートを書け。考察しろ。所感を記せ。与えられた問題について簡潔に論じろ。……その連続だ。勿論、意味不明瞭であったり支離滅裂だと減点される。だから、徹底的に論理的な文書を求められる。一番忙しい時は、週に五つも六つもレポートが課せられたものだ。入学当初から完全週休二日制だから、一日につき一枚のレポート課題を出された計算になる。科目も分量もまちまちで、指定されたフォーマットまで違うという有様。休む暇も無くレポート漬けの日々を送った。
学校・学科によって差があるにしろ、どこも似たようなものだろう。「文学的な表現」を抜きにすれば、高専生の文書作成能力を侮ってはならない。楽して良い評価をもらおうとする学生ほど、どれだけ文面を切り詰めて最適化できるかを考える。もしレポートをコピーしたとしても、そのまま使うのはかなり危険だ。教官曰く、「コピーしたものは十中八九判別できる」という。コピーした側もさせた側も減点対象になる。そのことは、入学一年目にしてみっちりと叩き込まれ、実例も見てきた。コピーするにしても、うまく切り貼りし、自分の脳味噌に即した日本語に変換する必要がある、ということだ。そうして文書のこねくり回し方を身につける結果になる。
神林氏はそういう叩き上げの力を持っていて、それをベースにしたのかもしれない。
ノートのマウス、調子悪し
きちんとマウスパッドに乗せてやっているにも関わらず、ポインタが動かないという状態をよく引き起こす駄目駄目エレコムマウスはもう嫌だ。
私が初めて買ったマウスは、今ノートで使っているものと同じ型のものだった。というより、その初代が駄目になった（マウスホイールの支持プラスチック部が修復不能な破壊を遂げた）後、何を思ったか同じマウスを購入したのだ。秋葉原に行ったとき、安くセール品で店頭に出てたもの。それが今の二代目。
まだ二年も使っていないのに、もう寿命が来ているらしい。まったくもって駄目すぎる。よって、金輪際エレコムのマウスを買うのはやめる。
具体的には、以下の問題点が発現している。
- マウスホイールが購入当初とくらべて軽くなりすぎている
- ホイールクリックが購入当初と比べて感度が良くなりすぎている
- 光学センサの認識不良
致命的なのは認識不良。レンズを掃除しても全く改善されない始末。そして Firefox でブラウジングする際に不便きわまりないのが他の二つ。特にホイールクリックは、新しいタブで開く動作を司る大事な要素。しかしもう駄目になってきている。ワンクリックでタブが5つも開くなんて、一体何を寝ぼけているんだ？
マウスにごてごてした機能は求めない。使う時は限られている（Firefox を起動したときぐらい）し、ボタンは3つで十分。握りやすく大きすぎない（かといって小さすぎない）文字通りの手の平サイズがベスト。デザインも、グロテスクなのは却下。Microsoft や Logitech の大型モデルには、凄まじく不格好なものがある。あれは駄目。というかそもそも大きすぎ。店頭で実際に握ってみたけれど、全然手に合わない。私の手が小さすぎるからだろう。同じ背丈の人間と比べて、関節一つ分は確実に短いのだから。
……この間話題になっていた、Apple のマウスが結構気になる。でも高価だし、第一今のクソ味噌にダサいノートパソコンには絶対に合わない。デスクトップの方も、ケース色が黒だから駄目。……やはり、他の会社のものを探すか。
道具は手に合ったものを使うべきだ。そしてそれは長持ちして、手入れのできるものが望ましい。
そういう意味で、Happy Hacking Keyboard (Lite 2) はよくできていると思う。結構頑丈だし、キーも簡単に外せて掃除ができる。場所も取らず、私にとって無駄でしかないテンキーやシフトキーが存在しない。そして何より、打鍵感。学校にあるどのキーボードよりも心地良い（だが、Professional には敵わない……あれはもう別次元）。
いつか、運命のマウスに出逢える日が来るのだろうか。
Xfce を試してみた
軽量との噂を聞き、Xfce というウィンドウマネージャを試しに導入してみた。
結論。重いじゃねーか。
……いや、確かに動作は軽快そのもの。でも、メモリを喰う。Xfce 関連のプロセスを top なんかで見ると、皆 二桁 MB クラスのメモリを使っている。これじゃあ常用できない。
そういうことで、引き続き WindowMaker をウィンドウマネージャとして使うことに。Dock アプリに惚れた人種ですから。
今日からテスト。ロボット工学か……。適当にやっておこう。それより去年落とした単位の再評価が重要。最重要。JABEE の関係で、非常に面倒なことになっているから。詳しいことはまたいつか書くつもり。
blog のナビゲーション実装完了 - 新しいサイトデザインを実装中・その5
Blog にだけ存在するナビゲーションを実装。それから、CSS ファイルの些細な変更。最適化というか、共通項をまとめたというか。そうしたらかなりのコードが同一であったことがわかり、normal-plus.css がめちゃめちゃ短くなった。何たることだ。
共通点や初期設定をまとめたスタイルを予め作っておいて、それにプラスアルファという形で "Space" やら "Paper" やらの「名前つきスタイル」を組み上げている。C 言語でいうなら、前者が標準ライブラリ、後者が自作ライブラリといったところか。基本を同じにしてあるので、応用がききやすい。
例えば normal.css というファイルでは、XHTML 1.1 に定義されている要素について、スタイルの平滑化と共通スタイルの実装を行っている。最たる例が body 要素の margin と padding。UA 毎に違うこれらをまとめるのは基本中の基本。そして自分の思い通りになっている下地を使って、新たに margin や padding を指定する。
そして normal-plus.css というファイルでは、独自の、「名前つきスタイル」に関係なく共通するスタイルのクラスを定義している。無論、「名前つきスタイル」で多少の変更を行う場合もあるが、それは大抵色指定や normal-plus.css では指定されていないプロパティである。
同様に、print.css では印刷用の共通スタイルを定義している。
……で、結局のところ新しいスタイルはまだ未完成。いつになったら完成するのやら。
ScrapBook 0.17.0 Release
Mozilla Firefox の拡張機能である ScrapBook の最新版がリリースされた。
この拡張は以前から使っている。気になったページを好きなだけスクラップすることができ、系統的に管理することができ、エクスポートして他のマシンに持っていくこともでき、といいことづくめ。他にも色々便利な機能が目白押しな、私の Firefox ライフに欠かせない必需品。
今回備わった新機能の一つが、階層指定可能な取り込み。似たような機能は前にもあったが、今度はより使いやすくなっている模様。これはオンラインマニュアルを取り込むのにめちゃめちゃ便利。W3C REC の翻訳で、圧縮されてないまま掲載されているものなどの技術文書に使える。いちいちページを開いてはスクラップ（ないし保存）しなくてもよい。
更に、あたかも1つのファイルであるかのように扱えるようになった。中のアンカーも URI が置換され、ローカルに保存したそれを指すようになった。ますます階層化された文書の取り込みが便利になっている。
世の中便利になったもんだ。まだ不安定だった Phoenix 0.5 の時代が懐かしい……。
メニュー実装完了 - 新しいサイトデザインを実装中・その4
メニュー部の実装が完了した。見たい人は代替スタイルチェンジャから。例によって IE 対策は何もしていない。
ようやく画像を作成し、メニューとして実装。トップページや Storehouse インデックスのような、縦幅が少ない #body である場合を想定して、#body に min-height をつけた。また、その時に border が現れないよう色々と工夫。
そんなこんなで実装完了。あー疲れた。でも、一番厄介な部分を終えたのだから、あとは作業量自体は多いものの頭を使わなくて済むものばかり。
でも、まだ #header の背景が残ってるんだよな……。描くのが面倒。
そして気付いたこと。IE で見てた人ごめんなさい。IE では Alternate Stylesheet が共通 Stylesheet と同一視されてしまう（というより、Alternate を知らない）ので、Space スタイルと Paper スタイルがぐちゃまぜになっていた（と思う）。SSI での書き換えで対処してあるのでもう安心。いやはや、Linux ノートパソコンでしかネットワークに接続できない環境ならではの失態。でも、もう大丈夫。
Mozilla Firefox 1.0.7 日本語版が出ている。個人的には、Firefox のインターフェース中に日本語を見かけない日々。特に問題ないから別にいいけど。
Mozilla Firefox 1.0.7 Release
Mozilla Firefox 1.0.7 がリリースされた。セキュリティアップデートなので、1.0.6 以前のバージョンを使っている人は必ずアップデートしないと色々と後が恐い。
つーても、私は 1.5 Beta 1 を常用しているのであまり関係ない。でも Beta 1 にも IDN セキュリティホールあるから、本当なら 1.0.7 の方が安全。一応 IDN 無効にしてあるけど。
今日また学校へ行ったら、明日からまた三連休。しかし、その後から五日間連続でテスト。私を殺す気か。今までこの学校に居て、何度か休みを挟まないテスト週間は経験してるけどさ。
三日目が山場かもしれない。四教科連続。でも、持込み OK なのがその内三つ。……多分、大丈夫。
明日提出のレポートがまだ終わってない。というより手を付けてない。今日も徹夜か。結構徹夜って好きだからいいんだけれども、テスト週間で寮の消灯が自主消灯（制限なし）になってなかったらどうしたんだろう？
Opera の広告消えました & AOL の行く末・Google の傘下となるか？
Opera 公式サイトでもアナウンスされているように、今まで広告の除去を行うにはライセンスを買わなければなららなかった Opera が、ついにその広告を全廃した。
これは、かなり歴史的な大事件だ。流石に Netscape ソースの公開程のインパクトはないものの、いままで Opera に広告ありき、というイメージしかなかったのが撤廃されたのだ。驚かずにはいられない。
お陰で、今日書こうと思っていたネタをひとつ、お蔵入りにしてしまったぐらいだ。Opera のイメージ戦略にまんまと嵌まってしまった。まあ、これからも開発スピードを落とさずにバグフィックスと機能増強をしてもらえれば嬉しい。先日、Opera のバグ云々について延々と論じたものだが、この度新たにリリースされた Opera 8.5 ではどうなっているのだろうか。また調べてみるつもり。
次に、AOL が Google に買収されるかもしれない、という話。これは、元々 Microsoft が買収しようと計画していたのを、Google が抑えにかかる可能性がある、というアナリストの指摘が記事になっている。個人的には、Microsoft が買収すると Netscape ブランドがどうなるのか非常に心配。それだったら、Netscape から派生した Mozilla プロジェクトにかなり肩入れしている Google が AOL を買収し、Netscape ブランドの UA を提供する、という状況になれば、後腐れは残らないと思う。よく考えれば Microsoft が買収した場合、かの会社は自社内に2つの UA ブランド（IE と Netscape）を持つことになり、社内競争をさせるとはまず考え難い（ただでさえ IE の開発でいっぱいいっぱいを装っている・現実にそう）のに。同じことは、IM の分野でもいえる。AOL と MSN メッセンジャーが競合するのだ。
（脳内妄想開始）よって、もし Microsoft が AOL を買収するならば、その目的は恐らくブランドイメージの削除。そして独占の強化。
そんなアホな、考えすぎだよ、という意見もある。だが、Microsoft ならやりかねない。あの会社の凄いところは、やろうと思ったことは、例えそれがどんなに倫理・道徳からかけ離れていようとも躊躇しないことだ。企業が生き残る為に必要な合理性の、まさしく象徴的な存在。それが Microsoft であるといえるだろう。だから、例えそれが失敗しようとも、侮ってはならない。大事なのは、それを「やろうとした」ことであり、成功したか失敗したかは結果論に過ぎない。問題になるのは、「発端」なのである。ハロウィーン文書を思い出すべきだ。あれは教訓である。「プロトコルの脱共有化」を促進する手段として、「ブランドイメージの抹殺」は機能することができる（脳内妄想終了）。
……証拠がない文書ってのは、別の意味で頭を使うもんだ。
最近、また色んな意味で話題が増えてきた。良いことはより大きな波に、悪いことは鎮まってくれれば一番なのだが、そうもいってられないのが現実の辛いところだ。あー、畜生。
hate : 100%; - 新しいサイトデザインを実装中・その3
タイトルは誤字に非ず。
ページのメニューを実装していたところ、height がらみの挙動にとことん悩まされる羽目になり、もう嫌だよ畜生という状況になったので、仕方なく妥協することにした。
因みに、今日の文はかなり長いのでそのつもりで。
引用文は、全て「標準情報(TR) TR X 0032:2000 CSS2」からのものである。
引用文は原文のままではなく、英単語と日本語文字の間にスペースを入れ、（略）（前略）（後略）により関係のない部分を略してある。
また、XHTML / CSS 断片は、直接関係ない部分をオリジナルから略してある。
以下の XHTML 断片を考える。
<div id="header">
<h1 id="top">Blog</h1>
<ul id="navi" class="nl">
<li><a href="../">Top</a></li>
<li><a href="./">Blog</a></li>
<li><a href="../storehouse/">Storehouse</a></li>
<li><a href="../about.html">About</a></li>
<li><a href="../link.html">Link</a></li>
</ul>
</div>
そして、以下の CSS 断片を与える。
#header
{
border-style : none;
margin : 0 0 -9px 0;
padding : 0;
position : relative;
}
h1
{
font-size : 150%;
border-style : none;
margin : 0;
padding : 4em 1.33em;
}
#navi
{
border-style : none;
margin : 0 0 0 -25px;
position : absolute;
top : 0;
height : 100%;
}
レンダリングの結果、Opera 8.2 では height : 100% が意図した値をとっていないことが判明した。height : 100% で意図した値とは、#header の高さと同じ値のことである。Gecko/20050908 rv:1.8b4（Mozilla Firefox 1.5 Beta 1）では、height : 100% が #header の高さと同値になり、結果として #navi li の位置が #header の丁度真下にくる。私はその位置に #navi li を持っていきたいが為に、#navi に height : 100% を指定した。しかし、Opera は意図しないレンダリングを行った。
これは由々しき問題だ。どうして Gecko と Opera で挙動が違うのか？ 何か理由があるに違いない。
よくやってしまいがちな過ちは、この時点で「思い通りにならないから Opera が間違ってる」という結論を出してしまうことだ。それだけはやってはならない。まさしく技術者らしからぬ行為である。実際のところ間違っているのは Gecko の方なのかもしれず、果ては両者とも間違っているのかもしれないのだ。直感で決めてよいことではない。
ここは理論的に原因を究明し、どうしてこのような挙動が発生したのかを突き止める必要がある。そして、論理的帰結として現れた事象は、異なる事実が現れない限りそのままである。つまり、認めるべき事項になる、ということだ。
そういうわけで、CSS Level 2 の仕様書と睨めっこすることにした。こういう時に仕様書は便利だ。何しろ、仕様書は絶対なのだから。それが前提であり、結論でなければならない。
まずは、大前提となる #navi の包含ブロックについて考えてみる。
要素のボックスの位置及びサイズは，一定の長方形に関連して計算されることが多い。この長方形を要素の包含ブロックと呼ぶ。要素の包含ブロックの定義を次に示す。
- （略）
- （略）
- （略）
- 要素が 'position: absolute' という値をもつ場合、包含ブロックは、最も近接する先祖によって、次の方法で設定される。この場合の先祖は、'static' 以外の 'position' をもつ。
- 先祖がブロックレベルである場合は、包含ブロックは、先祖のパディング辺によって形成される。
10.1 "包含ブロック" の定義
#navi は position : absolute である。よって、包含ブロックはその先祖である #header が position : static 以外である場合、そのパディング辺によって形成される。#header は position : relative である為 'static' 以外の 'position' をもつ
場合に相当する。よって #header のパディング辺が #navi の包含ブロックになる。
#header のパディング辺 ⇔ #navi の包含ブロック
では、その #header のパディング辺はどのようにして生成されるのだろうか。
（前略）要素がブロックレベルの子供をもつ場合は、高さは、最上部ブロックレベルの子ボックスの境界上辺から、最下部ブロックレベルの子ボックスの境界下辺までとする。（後略）
10.6.3 通常のフローにあるブロックレベル非置換要素及び浮動非置換要素
h1 以外の #header 子要素は、全て position : absolute である。よって、通常フローから解き放たれている。このことから、ブロックレベル要素として #header に作用するのは h1 だけである。
ゆえに、#header の最上部ブロックレベル子ボックス、即ち h1 の境界上辺から、最下部ブロックレベル子ボックス、これまた h1 の境界下辺までが #header のパディング辺、ということになる。
#header のパディング辺が成す高さ = h1 のパディング辺が成す高さ
#navi の包含ブロック定義より、#navi の包含ブロックは #header のパディング辺であった。そしてそれは、#navi の包含ブロックが成す高さが、#header のパディング辺が成す高さと同じになることを意味している。
更に、#header のパディング辺が成す高さは、h1 のパディング辺が成す高さに等しかった。よって、x = y ∧ y = z ⇒ x = z より、#navi の包含ブロックが成す高さは、h1 のパディング辺が成す高さと等しいことになる。
#navi の包含ブロックが成す高さ = h1 のパディング辺が成す高さ
h1 は margin や border を持たないので、h1 のパディング辺が成す高さは、h1 が成す高さと等しくなる。
#navi の包含ブロックが成す高さ = h1 が成す高さ
次に、問題となっている height の仕様を見てみる。
- 'height'
値: <length> | <percentage> | auto | inherit 継承: しない メディア: 視覚メディア この特性は、ブロックレベル要素及び置換要素が生成するボックスの内容の高さを指定する。
この特性は、非置換行内レベル要素には適用されない。行内非置換要素のボックスの高さは、要素の（継承される可能性がある）'line-height' 値によって提供される。
値には次の意味がある。
- <length>
固定された高さを指定する。
- <percentage>
高さをパーセントで指定する。パーセントは、生成されたボックスの包含ブロックの高さに関して計算される。包含ブロックの高さが明示的に指定されない場合、すなわち、内容の高さに依存する場合は、値は 'auto' と同様に解釈される。
- auto
高さは他の特性の値に依存する。以下の説明を参照すること。
10.5 内容の高さ（'height' 特性）
height の値に <percentage> （つまり % 値）が指定されている場合、指定されている要素の包含ブロック高さが明示的に指定されておらず、従って包含ブロックの内容高さに依存しているならば、height の値は実質的に auto へと書き換えられてしまう。
height : auto;
さて、そろそろ高さ計算のアルゴリズムを参照する。#navi は position : absolute を持っている「絶対位置決め要素」である。更に、ul 要素であるから「非置換要素」でもある。即ち「絶対位置決めされる非置換要素」となる。
絶対位置決め要素に対しては、上下方向の寸法は、次の制約を満足しなければならない。
'top' + 'margin-top' + 'border-top-width' + 'padding-top' + 'height' + 'padding-bottom' + 'border-bottom-width' + 'margin-bottom' + 'bottom' = 包含ブロックの高さ
境界スタイルが 'none' である場合は、境界幅として '0' を使用すること。この制約の解は、次の順序で置換を実施する。
- （略）
- 'height' 及び 'bottom' の両方が 'auto' である場合、'bottom' を0で置換する。
- （略）
- （略）
- この時点で 'auto' がただ一つしか残っていない場合は、その値について等式を解く。
- （略）
10.6.4 絶対位置決めされる非置換要素
まず、#navi に指定されている、高さ計算に関わる CSS プロパティ群を思い出す（関係ないプロパティは省く）。因みに border-style : none であるから、仕様によれば border-width : 0 に自動設定される。
#navi {
border-top-width : 0;
border-bottom-width : 0;
margin-top : 0;
margin-bottom : 0;
padding-top : 0;
padding-bottom : 0;
height : auto; /* 前述のように、100% から書き換えられた */
top : 0;
bottom : auto;
}
すると、引用した計算式は簡略化することができる。殆どが0であるから、height と bottom だけが残る。
height + bottom = 包含ブロックの高さ
しかも、height と bottom の両方が auto である場合、bottom は0で置換される。よって、height だけが残る。
height = 包含ブロックの高さ
そして、この時点で auto がただ一つしか残っていない場合は、その値について等式を解くことになっている。つまり、height : auto の auto 値についての計算になる。
height の auto 値 = 包含ブロックの高さ
先程から整理してきた事項を使い、まとめてみる。
#navi 包含ブロックの高さは h1 の高さであった。また、height の auto は、元々 100% という指定値であった。そして height : 100% は、#navi の高さそのものである。よって、#navi の高さは h1 の高さと同値でなければならない。
#navi の高さ = h1 の高さ
以上の結果より、#navi の高さと h1 の高さを同じ値にして計算している Gecko は、仕様通りの動作をしている。対して、#navi の高さを0にしてしまっている Opera は、仕様通りの動作をしていない。
故に、Opera の挙動は CSS Level2 の仕様に反している。q.e.d.
……と、ここまできて、ようやく Opera の挙動が変だ、ということがはっきりした。
以前にも、line-height に関する仕様の考察と証明を行ったことがあった。今回よりも単純なものだったが、思えばそれがこういう「仕様の証明」の始まりだった。今の卒研も、「実装が仕様の通りになっているかをチェックするシステムの開発」である。今更ながら、その同一性に気付いた。
こういう、論理でギチギチに攻める証明は大好きだ。また疑問点が浮かんだら、同じような証明をするだろう。繰り返すが、論理的帰結として出てきた結論は、それに反論する為の証拠が存在しない限り、覆ることがない。そして事実となる。
……こんなことやっても、現実は Opera の挙動がおかしいのだから、修正されないのならそれを回避するような実装を考えなければならない。今思いついたのは float を用いる方法。そうすると、「浮動要素」の計算が絡んでくるようになり、先の計算式はご破算になるだろう。Opera でもうまくいくようになるかもしれない。やってみる価値はありそうだ。
参考文献を列挙する。
新しいサイトデザインを実装中・その2
現在、border-radius の実装が完了。未完成ながらも代替スタイルとして指定しておくので、見たい人はどうぞ。
かなり色々な問題が立ちはだかったものの、ネガティブマージン、z-index、ポジショニングをフル活用して解決。最後まで悩んだのは border-radius-bottomleft をどうするか、ということ。結局 #banner をレイヤとして利用することで妥協。
因みに、IE 用スタイルには手をつけていないので、IE ではまともに見れない。とはいえ、Gecko と Opera で見ながら実装して、その後で IE 用のスタイルをシコシコと書いた方が楽。IE にしても XML 宣言入れてるから Quirks モードになり、その為の面倒なコードを色々と追加してやる必要があるので、かなり手間。ぶっちゃけ面倒なのでやりたくない。でもやらないと何か悔しいので、結局私は書いてしまう。
まだ、一番の難所（デザインするのが難しい）であるメニューの実装と、ヘッダ部の背景画像が残っている。特に後者は、構文解析木のイメージにしようと思っているので、描くのがだるい。……絵を描くのは苦手だ。直線的なイメージでいいものだとしても、苦手なのには変わりない。というより、絵を描くという行為自体にあまり喜びを感じることができないのだ。その代わりといっては何だが、コードを書くのは幸せだ。それが自然言語の文書（英語は駄目だが）であろうと、人工言語であろうと。
明日も明後日も休み。明日は鰻でも喰いに行こう。再来週はテスト週間、五日連続の地獄が始まる。精をつけておかないと、身体が保たない。勉強もぼちぼち始めないとなぁ……。過去問の入手を最優先にしなければ。
GDB
今日は GDB (GNU Debugger) を使ってみた。卒業研究の前任者が書いたプログラムを打ち込んでコンパイルしたところ、実行時にセグメンテーション違反。ある意味一番性質が悪いバグ。コンパイルはできるものの実行できないのだから、文法エラーではない。しかも実行時のセグメン違反なのだから、動的に確保される部分で不正なメモリ領域を参照している可能性が非常に高い。これがもしコンパイル時のセグメン違反なら、静的に確保された領域に対する不正位置の参照になる。よって、これはもう printf デバッグ（C++ だから cout）かデバッガを用いる方法しか、バグを見つける手段がない。
ということで、GDB の出番。早速 Makefile の中で -g オプションをつけさせて、コンパイル。
そして Emacs 上から GDB を起動。これ大事。
何故なら GDB は Emacs 上で動かしてこそ、素晴らしい機能を発揮してくれるから。例えばトレス地点を別ウィンドウで逐次表示。しかもきちんとバッファにファイルを開いてくれるので、編集するだけで反映される。ウィンドウ間を Ctrl-o で縦横無尽に駆け巡ればいいだけの話。ホームポジションから動かさなくて済む快感。でも虫退治をしなければならない。
現時点で、原因地点を掴むことには成功した。だが、それの修正方法がわからない。もしかしたら、GCC のバージョンが前から上がったせいで、当時は表面化していなかったバグが出てきたのかもしれない。しかし、それはあまり考えるべきではない。一番の原因はこの私自身であり、一番信用できないのもまた、自分自身なのだ。
暫く頭を冷やしてから、考え直してみることにしよう。明日になれば、何か発見できるかもしれない。
国勢調査
今日、調査票を配布された。これから書いていくつもり。
で、ひとつ個人的に注意しておくべきところ。それは、黒鉛筆で記入しなければならないという点。
いつも正式書類はボールペンで書いているので、ついうっかり使ってしまいそうだが、マークシートなので鉛筆を用いなければならない。読み取りの方法にも様々な種類があるようで、一つ知っているのは通電式。何でも、電気抵抗の違いを判別してスイッチングを行うのだとか。鉛筆は主成分黒鉛だから、一応導電体。その辺を利用している。あまり高級な形式ではないらしく、だから安価。ウチの学校ではそれを使っているらしい。国勢調査は流石に違うだろうけど。
「調査票の記入のしかた」パンフの表紙にいる「センサスくん」が持っているのがしっかりと鉛筆だったり、風船の紐を持っているようで実は掌に巻きつけているだけだったりと、変なところに目が向いてしまう私なのだった。
新しいサイトデザインを実装中
スタイル名「Paper（仮）」の CSS を実装中。外見こそどこにでもあるような Blog 風の代物かもしれないが、シャドウのつけかたと四隅に radius をとる方法に工夫を凝らしてみる予定。
多分、できあがったら代替スタイルとして適用すると思われるので、Firefox や Opera 使いなら簡単に変えられるはず。IE は……専用のチェンジャでも実装しておくかも。例えば「Style Sheets Selector」をベースに改良したものとか。
しかし、もうすぐテスト。現実逃避の手段にならないよう、その辺は自己管理しないと点数がとんでもないことになる悪寒予感。
ちなみに再評価は合格。これで一安心。まだ他の再評価が残ってるけど。
再評価、終了
設計工学の再評価を受けた。自作のノート（コピープリント添付不可）なら持ち込みオッケーの、楽々テスト……というわけでもないのだ。
何より計算問題が厄介。概念設計段階において意思決定に用いられる、ベイズの定理に関する問題とか。それを更に発展させると、以下に引用するような問題が出てくる羽目になる。
市場調査の結果、θ1とθ2という自然状態に対して、事前確率を得た。更に専門の調査機関に依頼して、情報 I と事後確率を得た。以下の表を用いて問いに答えよ。
効用と事前確率・事後確率 自然の状態 θ1 θ2 行動 a1 3 14 a2 8 7 事前確率 0.6 0.4 情報 I z1 0.85 0.15 z2 0.38 0.62 z3 0.55 0.45
- 情報 I からメッセージ z1, z2, z3 を受け取ったときの事後確率に基づき、それぞれのメッセージの場合について最適行動を求めよ。
- 情報 I からメッセージ z1, z2, z3 を受け取る確率をそれぞれ p(z1) = 0.58, p(z2) = 0.32, p(z3) = 0.10 であるとすると、情報 I を利用したときの最大期待効用を求めよ。また、情報 I の価値も求めよ。
- 情報 I が完全情報で、必ず θ1 のときメッセージ z1 を、θ2 のときメッセージ z2 を出すとき、情報 I の価値を求めよ。
設計工学テスト問題
これがまた計算がクソ面倒なのだ。表計算ソフトにやらせれば一発なのだが、生憎とテストなのでそうも言ってられない。全部電卓を使っていいとはいえ手作業である。無駄の極みだ。
計算そのものは単純な四則演算。しかし、式がぐちゃぐちゃ。もう記号の使い方からして汚らしい。……もっとマシな記号はなかったのか。
それでも、何とかなったからいいんだが。テストは思いのほか楽だった。問題数も少なく、これといって難しいものもなかった。
無事に合格できていればいいのだが。
Mozilla Firefox 1.5 beta 1 Released!
少し古いネタだが、Mozilla Firefox 1.5 beta 1 がリリースされた。ついにベータ版。感慨深い。
早速導入して、動作を確かめてみた。外見上は特に Deer Park から変わったところも少なく、動作もより安定・高速化している感覚。個人的には十分常用に耐え得る品質。0.5 辺りの時代はよく落ちてたなぁ……レンダリングで CPU 使用率 100% もザラだったし。
ヘルプが全面的に変更されていたり、Windows 版のメニューデフォルトスタイルが XP の Luna テーマに合わせてフラットになっていたり、DOM Inspector などで使われる outline のスタイルが変わっていたりと、細かいところに変更点を散見できる。
SVG レンダリングは、まだまだ Opera 8.2 より低速。スクロールは全く実用にならない。しかし、明らかに Alpha 2 の時よりは高速化している。2.0 辺りになればいい感じになるのだろうか。
次に、Mozilla Firefox 1.0.6 に関わる緊急重大なセキュリティホールの話題。What Firefox and Mozilla users should know about the IDN buffer overflow security issue で述べられているように、国際化ドメイン（IDN）に関するバッファオーバーフローが見つかった。ユーザはセキュリティ確保のために以下に記すどちらかの行動をとる必要がある。
- パッチをインストールする
- about:config などから
network.enableIDNをfalseにする
どちらも、やっていることは「IDN を無効化する」ということ。前にも IDN 絡みのセキュリティホールが発見されたような気がする。やはり、長大な文字列を与えてしまうことで発生するバッファオーバーフロー問題だったように思う。
C++ や C で開発が行われている Gecko レンダリングエンジンは、もろに影響を受けやすい。そもそもバッファとして取得されているメモリ領域より外にまでデータが及んでしまう（侵蝕してしまう）ことで、任意のコードを実行することが可能になるのだから、ガベージコレクタが無い言語は必然的にこの問題を抱えていることになる。ガベージコレクタがある言語でも、インタプリタやコンパイラがバグを抱えている場合があり、一概に安心してはならない。
とはいえ、Gecko のように、複雑で速度を要求され、かつバイナリサイズを極力抑えたうえでマルチプラットホームを実現するには、C や C++ で開発するしかないのだろう。Java は移植性に問題があるし、Perl / Ruby / Python といった言語は、ファイルサイズと実効速度の点でどうしても劣る。Lisp もまた然り。
それに、C / C++ は ISO で標準化されているという強みもある。要するに、言語仕様が安定しているということだ。特に、C はかなり「枯れた」言語なので、ノウハウも実装も程よい最適化を施されたものが存在している。C++ にはかなり「コンパイラが対応してなくて使えない機能」が存在しているものの、オブジェクト指向プログラミングの利点を使えることは、大規模プロジェクトである Gecko 実装にはうってつけである。
……と、ここまで色々書いてきたけれども、私は Gecko の開発に関わっていないので詳しいことが何も言えない。つまり要約してしまえば、「C / C++ で開発するとバッファオーバーフローの危険性をどうしても包含せざるを得ない」ということ。
改造
友人が、サイトで「お題ボタン」なるものを公開していた。絵のネタが思い浮かばなかったとき適当に押して、ランダム生成されたお題を使う、という目的の、JavaScript で書かれたツールだ。私には思いつかない動機だといえる。
これは結構面白いな、ということで、オブジェクト指向で設計しなおしてカプセル化し、更に DOM によってその結果を表示するように改造してみた。本人の許可をとったので掲載してみる。
スクリプトの本体は draw_theme.js。動作は Mozilla Firefox 1.0.6、Opera 8.2、IE6 で確認。
使い方は簡単。「お題を生成」ボタンを押すだけ。
| お題 | DOM を利用できません |
|---|---|
| 解説 | DOM を利用できません |
友人作（以後「プロトタイプ」と呼称）の方は、お題の探索ができるようになっていたので、それも実装したのだが、インターフェースには反映していない。
それから、追加機能として以下のものを実装した。
- ハッシュ法によるお題の探索
-
通常の探索。プロトタイプの探索は線形探索だった。データを格納しておくデータ構造を連想配列（ハッシュ表）にしたので、必然的に探索もハッシュ法にできるという寸法。
- 正規表現によるお題の探索
-
正規表現による探索。お題を正規表現によって探索することができる。線形探索に正規表現を組み合わせている。
インターフェースさえちゃんと書けば、検索機能も使える。でも今日は面倒なのでやめ。
コレ書いていて改めて思ったのは、実装の中心部とインターフェース部は分離しないと、コードが動脈硬化を起こしやすい、ということ。まず汎用性が無くなる。中心の、一番重要な部分を抽象化しておいて、その上に継承なり新たなクラスを作るなりでインターフェースを定義しないと、インターフェースの呪縛に囚われる。これはソフトウェア開発の常識ともいえる（基本中の基本？）事項だけれども、以外と忘れがち（というか勢いで書いてしまってどうしようもなくなる）なので、注意する必要がある。
因に、件の友人。最近親からトレス台を奪取することに成功したらしい（トレス台を没収する方もする方だ）。私だったらパソコンだろうが、取り上げられたら……ひたすら本を読むだけになってしまう。せめて一日一回はキーボードの上に指を這わせたい。彼もまた、同じような心境なのだろう。
.htaccess での指定がうまくいっていない件について
以前、.htaccess にあれこれと追加して、application/xhtml+xml に対応していない UA には text/html を送付するやり方を載せた。
しかし、それは特定の条件下ではうまくいかないことが判明した。もう一度、抜粋したコードを載せてみる。
AddType "text/html; charset=euc-jp" xhtml
RewriteEngine On
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml
RewriteRule \.xhtml$ - "[T=application/xhtml+xml; charset=euc-jp]"
問題があるのは、RewriteRule の行にある正規表現。つまり \.xhtml$ のこと。これがよくよく考えてみると、拡張子 .xhtml のファイルを直接参照した場合だけを想定している。ということは、ディレクトリ指定――URL 文字列の末尾が /――の場合では、.xhtml という文字列が存在しないため、常に text/html を送出してしまう。実に由々しき事態だ。
ということで、改良を加えることにした。まずは、文字列末尾がディレクトリを示す / であった場合を想定する。
RewriteRule /|\.xhtml$ - "[T=application/xhtml+xml; charset=euc-jp]"
しかし、駄目だった。何故か / の指定は無視され、改良前と同様の動作をとったのだ。原因は不明。
因みに、以下のような Perl スクリプトを組んで、実行してみた。
#!/usr/bin/perl
use strict;
use warnings;
my @list = (
"/",
"index.xhtml",
"/index.xhtml",
"/blog/",
"/blog/index.xhtml"
);
for (@list) {
m#/|\.xhtml$# and print "MATCH : $_\n";
}
exit;
出力は以下のようになった。
MATCH : / MATCH : index.xhtml MATCH : /index.xhtml MATCH : /blog/ MATCH : /blog/index.xhtml
つまりは、全部マッチングに成功しているということだ。
Apache 2.x の正規表現は Perl5 互換ということなので、Perl5 で動作するなら Apache 2.x でも動作するはずである。しかし、実際はうまくいっていない。
何故だろうか？ また色々と試してみるつもりだが、根本的に何かが違っているような気がしてならない。Apache め……今にみていろ。
GMail アカウント、あげます
GMail を開いてみたところ、アカウントを紹介できるようになっていた。しかも凄い数。だって奥さん、50件ですよ。50件。これを一人で持っててもしょうがない。
ということで、先着50名様に GMail アカウントを漏れなく進呈。宛先は taku.eofアットマークgmail.com まで。アットマークは勿論 @ に置換して。但し、本文と件名の両方に必ず「GMail のアカウントください」のような文面を入れること。片方でも空白だったり、GMail について全然触れていなかったりしたら、この文を読んでいなかったということとみなすので、あげるわけにはいきません。
今日はネタに困らない日。まず ipod nano。私は音楽を全く聞かない人間なのだが、周囲はそういうわけでもなく、友人の一人が ipod shuffle を持っていたりする。だから ipod の美しさというものを手に取ったことがある。……今回登場した ipod nano は、そんな ipod shuffle の後継なのだそうだ。
で、少し引っかかったのが、その名前。何故に nano なのか、ということ。別に micro でもいいじゃないか、と思ったわけで。でも、micro は任天堂が Gameboy micro という製品を最近になって出しているから、止めたのかもしれない。
canvas 要素の使い方。簡単だが、例にそって説明されているので分かり易い。
今、「ピープルウェア 第2版」（トム・デマルコ/ティモシー・リスター 日系BP社）を読んでいる。結構納得。プログラマには個室を割り当てて欲しいというのは自分だけじゃなかったか。他の人に画面を見つめられるのは、それを許容している時を除いてあまりいいもんじゃない。
きょうはまとまってないな……。まあいいや。
メールアドレスを変えてみる
Hotmail のやつを GMail のやつに変えただけ。ついでにページ末尾の address 要素にもアンカーをつけてみる。
今日は雨の後だったので、虫が大量発生していた。どこからともなく部屋の中へと進入してくる羽蟻ども。まったくもっていらだたしい。水性の蚊取りをつけっぱなしにして、網戸に網戸キンチョールを大量噴霧し、熱源である蛍光灯にも吹きかけた。
床にボトボトと落ちる羽蟻の大群。せっせとそれをクイックルワイパーで掃除して、徹底的にクリーンな状況を保つ。虫は大嫌いだ。ぺとっ、と肌にくっついてきて、うぞぞぞぞっぞぞと這い回り……あぁぁぁああああ！ イラつく！ もう、この世から虫なぞ消えて無くなればいいのにと思う。とにかく、もう羽蟻は見たくない。
そんな虫も嫌いだが、コンピュータに巣食う虫も嫌いだ。所謂バグである。……とはいえ、そんなバグを特定したときの開放感は、たまらなく気持ちいい。それが、物理世界の虫とは異なる点だ。だからまだ許せる。自分のミスで生まれたものでもあるだろうし。人間の責任なのだ。
が、物理世界の虫は許せない。いくら食物連鎖のバランスが云々といっても、嫌なものは嫌なのだ。私にとっての虫は、いいことをしない存在。存在の価値を認められない、しかし存在してしまうモノ。だからぼんやりと妄想する。私の周囲だけ虫が消滅するようになればいいのに、と。叶わぬ戯言と知りながら。叶えてはならぬ夜迷い言と理解しながら。
――まぁ、美味い虫もいるから、全く無価値というわけでもないか。
捕捉されている！
のり未刊に捕捉されてた。……いつの間に。こういう場合は、何か一言言ったほうがいいのだろうか？ よし。じゃあ少し検討してみよう。
「捕捉して頂いて誠にありがとうございます。しがない雑文サイトではありますが、これからもご愛顧の程宜しくお願い致します」
駄目だ。何か堅苦しい。
「ありがとチャーン！ 色々カキコしてるんだけど、これからもよろしくっす！ じゃ！」
……どこのバカだ。
「捕捉して頂いてありがとうございます。当サイトは雑文の列挙を主とする完全趣味サイトです。2005年の4月に発足して以来、ごく少数の方の閲覧を頂戴しています。さて本日は捕捉のお礼を一言申し上げたく、この文章を書いている始末であります。今後とも変わらぬご愛顧を申し上げるとともに――」
長すぎ。つーか全然一言じゃないし。
「TNX」
短すぎ。
「これからもよろしく」
……これでいいかも。一番シンプル。でも短すぎず、決して長すぎず、単調でもない、慣用句。だから、今まで生き残ってきたのだろう。時代の流れに移ろい行く言語の性質上、同じ語句が留まり続けることは、それが完成されており、しかしアレンジがきくことを意味していると思う。
シンプルであれば応用が楽になる。単調ということではなく、単純ということ。しかし、決して一つの可能性に束縛されるのではなく、かといって四方八方に手を広げすぎて収拾がつかなくなっているわけでもない。
思えば、プログラミング言語の「シンプル」も、様々な形がある。典型例が C 言語。設計思想が Keep it simple, stupid
。実にわかりやすい。そして、現に仕様がシンプルであり続けている。
かと思えば、Lisp もまたシンプルである。それは、文と式の区別がないことだ。厳密にいえば、Lisp にあるのは式だけである。それは、括弧の多さに辟易することさえ克服すれば、恐ろしいまでに強固な言語仕様（ものにもよる）と、凄まじく融通の利く拡張性を手にすることができる。
Perl はどうだろう。これは、物事をシンプルにこなせる力を秘めている。正規表現を用いた文字列操作の柔軟性を見よ！ 拡張された正規表現とさらりと書ける構文が、このツールを見事なまでに使いやすいものにしている。
しかしながら、C にも欠点はある。不明瞭な言語仕様がその一つだ。演算子の優先順位もよく言われる。Lisp は括弧の多さと言語仕様の多さ、Perl は汚い（といわれている）構文を欠点として指摘されている。
とはいえ、最初から完璧な言語などあるわけもない。それは、これから形作られていくものだ。欠点の無い言語は、完璧でしかない。そしてまた、完璧は閉塞した環境でしかない。それ以上の進歩は無い、ということだ。つまりそれは、完璧であるが故の死を示す。
シンプルであることは重要だ。私もシンプルなものが大好きだ。だからサイトのデザインもシンプルでありたいと思っている。しかし、単調とシンプルは紙一重だ。その難しさをどうにか克服することにこそ快感を覚える。
えっと、まあつまりは、Simple is the best internet experience だ、ってこと。
因みに、タイトルは AOC の「攻撃されているぅ！」風に読むのが正解。
パトラッシュ僕もう再評価課題に疲れたよ
ようやく「設計工学」の再評価課題終了。夏休みにやるべきだった課題を丁度一日で終了させたという無茶苦茶具合。例の如くエスタロンモカと栄養ドリンクの力でゴリ押し。夜なべして翌朝朝飯を喰った後に暫く仮眠。昼頃に起きて再開。そして23時00分頃に終了。
正直、駄目かと思った。
これを5日までに提出できなかったら、再評価受けられずに2単位がパー。単位が足りなくて卒業できなかったかもしれない。……それだけは考えたくない。折角就職できたのに。色々と申し訳がたたなくなる。
今こうして、何にも束縛されずにキーボードを叩けるひとときが、何より幸せ。
Eterm - the Enlightened terminal emulator for the X Window System
現在再評価の課題を黙々と作成中。あと4時間程度で終わればいいな。この文書はある意味で気晴らし。そんなことしてるから提出期限明日なのに計算問題（ベイズの定理その他諸々）が半分以上残っていて血反吐吐きそうなのに。でも止められない止まらない……。
それはそうと、最近使っているターミナルエミュレータは Eterm だ、という話をする。xterm から派生したもので、日本では有名であろう Kterm と同じようなものである。
但し、その機能にはかなり差がある。例えば背景の透過。デスクトップに文字だけが踊る様を夢見ていた私にとって、その機能は必要条件だった。Kterm の拡張パッチ当てバージョンには、背景の張り付けはあっても、透過はなかったと思う。
元々 Eterm は Enlightenment ウィンドウマネージャ用に作られたものだが、他のウィンドウマネージャ上でも動作する。GNOME にくっついてくる gnome-terminal を使っても背景透過を実現することができたのだが、生憎とメモリ使用量が莫大で、何と17MBも使う。対して Eterm は、驚くなかれ、Kterm と殆ど違わない。たった 1.2MB程度である。それでいてカスタマイズ性に優れ、日本語表示も問題無く、Vine Linux において apt-get すれば簡単に導入できる手軽さ。メモリ128MBのオンボロノートパソコンには優しい設計であるといえよう。早速メインのコンソールとして重宝させてもらっている。
Eterm の特徴に、そのテーマを比較的簡単に変更できるという点が挙げられる。私は独自のテーマファイルを作って、それを読ませている。
スクリーンショットを見れば一目瞭然だろう。前々からこれがやりたかった……。Emacs も Eterm 上で動かせば、この透過背景を享受できる。今はやっていないが。
高性能ながら軽量な Eterm。Kterm を使っている方には、是非お薦めしたい逸品である。
アルファ系衛星の氏族たち
「アルファ系衛星の氏族たち」（フィリップ・K・ディック 創元 SF 文庫）読了。版元品切だった為、中古で入手した。いつもいつも神保町にはお世話になる。そういえば、今のところ創元 SF 文庫から出ているディック作品のうち、まだ入手できていないものは「死の迷路」と「ティモシー・アーチャーの転生」だけになった。どちらも読んだことはあるのだが、まだ手元にない。気長に集めるしかないか。
「アルファ系衛星の氏族たち」（以下「アルファ」）は、ディックの作品中でも典型的といえる、夫婦仲の解決に焦点が当てられている。特に、「去年を待ちながら」と非常によく似ている。事実、「去年を待ちながら」巻末にある「ディック 自作を語る」を見ると、「去年を待ちながら」の原稿到着が1963年12月4日、「アルファ」の原稿到着が1964年1月16日になっている。星間戦争、技術者の主人公、トラブルを生んでしまう妻、雑多なエイリアンの登場という共通点も伺える（他の作品にも見られる傾向だが）。
ディックの作品で何が好きか、という質問をされたなら、「ユービック」「アンドロイドは電気羊の夢を見るか？」「時間飛行士へのささやかな贈物」「フロリクス8から来た友人」「暗闇のスキャナー」「ティモシー・アーチャーの転生」と答える。順番に意味はない。「ヴァリス」もリストに入れようかと思ったが、止めておいた。物語の完成度としては「ティモシー・アーチャーの転生」の方が上だと思ったからだ。
以前、とある友人に「何か SF で面白そうなのあったら今度貸してよ」と言われ、散々悩んだ挙句に渡したのが「アンドロ羊」だった。結果、その友人が私に返して曰く、「よくわからなかった」。……それを言われては元も子もない。比較的、ディックの作品としてはウケを狙いやすいと考えたからこそ渡したのだ。それとも、個人的に SF の入門作のひとつだと思っている、アシモフの「われはロボット」にしておけばよかったか。同じ高専生だからロボットものなら面白いと感じるだろうし。
今は「模造記憶」（フィリップ・K・ディック 新潮文庫）を読んでいる。「悪夢機械」も欲しいが、まだ見つかっていない。来年は東京住まいなので、神保町にも行きやすくなる。じっくり探せばいいだろう。
空澄の姫に引っ掛かる理由
先日、本を買いに近所の書店まで行った。以下、購入リスト。
- 奇跡の表現 II（結城充考 電撃文庫）
- 七姫物語 第二章 世界のかたち（高野和 電撃文庫）
- 七姫物語 第三章 姫影交差（高野和 電撃文庫）
- ビートのディシプリン（上遠野浩平 電撃文庫）
- 戦闘妖精・雪風 解析マニュアル（早川書房編集部編 早川書房）
今日は、「七姫物語」について少し語ってみることにする。かなり長文なので、覚悟して欲しい。
「七姫物語」は、この手の文庫には溢れているファンタジーの一種であり、「三國志」の系列に属する群像劇である。ただ、様々な論客が指摘しているように、視点が独特だといえる。古典的には主人公＝ヒーローが種々の困難を乗り越え、やがて目的を達成するに至る（か挫折する）までの道程を描く作品になりやすい。だが、「七姫物語」の主人公である空澄姫（カラ）は、その立場こそ一国の主たる姫であるものの、実際にはお飾りの人形であるに過ぎない。政治や戦争は、真の主役たるトエとテンが司っている。カラは、ただそれを離れたところから見物しているだけだ。
カラというキャラクターは、これでもかというぐらいに特殊性を剥ぎ取られた人物像として創造されている。まず政治に関する、即ち知の部分をトエが。次に戦争に関する、即ち力の部分をテンが。そして自己の防衛に関する、即ちアイデンティティ保護の部分をヒカゲが、それぞれ肩代り＝剥奪している。更に、姫であることの真性を捨て子という設定が。ストレス増大による自我崩壊を年齢の低さと陽気である性格が、これまた見事に打ち消している。容姿も、腕のいい衣装役によってスイッチを切り替えるが如く完全変換させられる。このスイッチは、後に述べる視点の「疑似的」多重化に貢献している。更に言えばこの衣装役、教育係として、また精神安定剤としての役割も与えられている。
そうしてあとに残ったものは、可愛さと、自分の方向性を信じてよいものかどうか悩むことしか持っていない女の子。ここまで希薄なキャラクターというのも珍しく、唯一持っている特別性――姫とされていること――もまた、不安定な政情から常に脅かされ続けている。確固たるものは何もなく、自身の命すらも危うい状況が横たわっている。だがそれも、情勢の中心から微妙に遠ざかっていることから、非常に危険というわけでもなく、かなり中途半端である。
だからこそ、この主人公は特殊たりえる。何故なら、ファンタジー小説において重要な要素である、「特徴による特殊性」が、わざと消失させられたことにより、「特徴なき特殊性」が誕生したのである。例えば「十二国記」の主人公（空澄姫と同じく女性）を引き合いに出してみればいい。「平凡な十代の女の子が突然異世界へと引きずり込まれ、そこは戦国の世であり、いくつもの国が対立しており、波乱万丈の冒険を繰り広げた挙句に君主となる」。……共通する部分が多いことがわかるだろう。ただ決定的に違うのは、主人公の肉体的（外面的）な面である。前述の通り、空澄姫には何もない。が、「十二国記」の主人公には大量の属性が付与されている。言葉に不自由しない、特殊な肉体、特殊な刀。全部自分で持っている。本来、古典的なファンタジーはそういうオールインワンタイプが多かった。もしくは、一点特化。
だが、空澄姫は何にも特化していない。ただただ平凡である――が、そのことが特殊である。こうした「平凡であるが故の特別」は、近年、既に採り上げられている。
小説の名は、「空の境界」（奈須きのこ 講談社 NOVELS）。同人出版では異例の話題作となり、商業出版社から再販されたという、前代未聞の伝奇小説である。この「空の境界」下巻解説では、「平凡であるが故の特別」について詳細な考察が行われている。
幹也は、荒耶のように「自身が特別であろうと」するわけではない。いや、絶対的な再生に憑かれた荒耶だけでなく、相対的な差異化に狂奔する日常人もまた「自身が特別であろうと」して必死に足掻いている。「特別になろうとして、成り得なかった結果が平凡な人生」なのだとしたら、「初めからそうであろうとして生きる」少年こそ“特別”ではないのか。
「「リアル」の変容と境界の虚無化」 笠井潔
しかしこれも、カラの状態を言い当てている論とは言い難い。何故なら、カラは「自ら平凡であろうとする」のではないからだ。
では、カラはどうなのか？ それは単純だ。「他者によって平凡にさせられている」のである。無論、その他者とはトエとテンのことに他ならない。二人が首謀者であり、更に平凡にするための材料として、ヒカゲや衣装役が登場してくるのである。
そこで、じゃあ待てよ、という声が出てくるかもしれない。それでは、カラの状態は特筆すべきことでもないのではないか？ 自ら平凡であろうとするわけではなく、他者によってそれが成されるのであれば、別に我々のような「一般人」とさして変わらない境遇なのではないか？
それが、そうとも言えないのである。何故ならそこには、「人為的」という言葉が含まれてくるからだ。
「空の境界」の幹也は、自ら平凡であろうとした。対して、「七姫物語」のカラは、他者によって平凡であろうとした。実は、双方に共通する事項として、「人間の手により、故意的に、確実に平凡である」ということが挙げられる。対して、我々が平凡であるということは、自分が意識してそうしているわけでもなく、他者によりそうさせられているわけでもない。ただ、自身が特別であろうとして足掻いた結果、それに失敗し、所謂「一般的で平凡」な状態に収束してしまっているだけの話だ。そこには全く逆の結果が生まれているのである。
ここまで考えると、カラと幹也の平凡性が、実は同じ土壌の上に成立していることが浮き彫りになってくる。どちらも平凡であろうとし、結果的にそれが特別になってしまっている。
しかしながら、カラと幹也の在り方は全くといってよい程に異なる。根源は確かに同じだ。ところが、そこから伸びる木そのものが、全く違うのである。
よくよく考えれば、カラは、元々平凡（孤児であることは、当該世界において珍しいことではないものとして描かれる）な存在であった。勿論、これは「結果としての平凡」の方である。しかし、そんなカラが、明らかに非凡であろうとするトエとテンにより見出され、外見的な非凡になることを自ら選択する。しかし、当のトエとテンによって様々な方法による属性の略奪が行われ、内面的な非凡の道をわざと塞がれてしまったのである。
そう。カラは「純粋培養の平凡」になってしまったのだ。ここに、第三者の作為を加えなければカラというキャラクターが発生しない道理が見えてくる。確かに、姫という立場は非凡な存在であるかもしれない。しかし、それは外部から見たところの非凡であり、その中身は絶妙なバランスで統制された平凡なのである。
こうして、「視点が変わっている」という論の土壌が一つ整ったことになる。ある意味で平凡であるから、非常に感情移入しやすいキャラクターになっているにも関わらず、どこか本質的に異なるような気がしていたのは、「外面的な非凡」であるカラの表面を我々は論理的に確認し、「内面的な平凡」を本能的に察知していたからなのだ。しかも、「内面的な平凡」にしても、我々のような「結果としての平凡」ではなく、「意図的なものとしての平凡」であった。更にそこには、「第三者による平凡性の維持」という要素まで加わっている。逆や裏の関係ではなく、いわば対偶のような関係だったのだ。
さて、私は先程、「土壌が一つ整った」と述べた。実際、まだ他にも「視点が変わっている」理由がある。それは今までの話に比べれば簡易なものなので、手早く説明することにしよう。
小説内で描写されるのは、ある意味で疎外された場所から、非常に狭い視点で見られた世界でしかない。当然だろう。カラは、情報を集める手段を初めから持っていないのだから。つまり、自分の目で見ることすらままならず、人づてに聞き及ぶ話が世界を決定する要因の大半を占めている。輪をかけて、真の主人公（作者自ら認めている）たるトエとテンのする話も、嘘である場合が多々ある。「事実」でない、ということだ。とはいえ、事実でない情報も、それが定着してしまえば「真実」になる。こうして、二人はあらゆる意味で空澄姫にとっての世界そのものを「創り上げて」しまっている。この部分を、様々な論客は「変わった視点」だと感じているのだろう。
しかし、違和感の原因はこれだけではない。何故なら、こうした狭い視点で語られる小説は、前例が沢山あるからだ。有名なところでいえば「ブギーポップ」シリーズだろう。「ブギーポップ」は、多人数によって語られる世界をうまい具合に継ぎ接ぎして、一つの物語に仕立て上げている。勿論、個々の視点は固定的であり、さらに様々な意味で周囲の環境に影響されやすい十代中盤～後半の年齢層を中心に登場人物が構成されている。こうすると、小説内の人物にとっては意味がわからないことでも、ある意味で俯瞰視点からその世界を眺めている我々読者は、情報の断片をつなぎ合わせることができる為、理解することができる。作中にも、わざとそれを読者に対して示すような部分が設けられている程である。
対して、「七姫物語」はどうか。そこでは、確かに「空澄姫」と「カラカラ」という二つの存在を意図的に構築し、場面転換を行うことによって、視点を切り替える役目は果たしている。
だが、それだけだ。役目は果たしているが、明らかに「ブギーポップ」とは異なる視点を提供している。
それは何故か？ 様々な視点から見つめているのではないのか？
答えは NO だ。それは、視点の主そのものが常に同一であるからである。立場こそ違えど、その人物、肉体は「カラカラ」のままである。よって、思考回路も、文体も、視野すらも全部同一である。多少、他の姫の視点も含まれてはいるが、圧倒的にカラの一人称であることが多い。これは、「視点の擬似的多重化」とでも呼べばよいのだろうか。実際には一つなのに、あたかも分裂しているかのような振る舞いをみせる――。そういう状況、物凄く狭い世界しか見ていない環境である。幼児は、自分こそが世界そのものだと感じているそうだが、まさにそれである。カラは幼いとはいえ十代なのだから、広い世界の存在は自覚しているし、実際にそれを体感してもいる。しかし、世界の情報は耳にしただけ。嘘も沢山ある。よって、ある意味で「閉じた世界」が構築されてしまっているのである。セカイ系の小説と近いところがあるといえるだろう。
この、極端までに一人称である視点。「完結一人称」こそ、視点の違和感を覚える二つ目の要因である。
まとめよう。「視点が変わっている」のには、以下の二つの理由があることをこれまで述べてきた。
- 「第三者により意図的に創造された、純粋な平凡」であること
- 「完結一人称」の導入
どちらも、「七姫物語」という小説世界をうまく表現する為の方法だといえる。群雄割拠とはいえ、どこかのんびりとした感のある世界を描写するのに、まるで世界と同調しているかのようなカラの無邪気さはうってつけだ。その根源を覗いてみれば、大体二つに絞れるというだけのこと。
まあ、最後にいえることは、これからもかなり期待できる小説であるということだ。遅筆なのを本人はえらく気にしているようだが、それはそれで、好きなようにすればいい。質が落ちてしまうようなら、本人が気づくだろう。空想世界を破綻なく描くには、自分の筆をしっかりコントロールする必要があるからだ。
最後に。少し引っかかるのは、「空の境界」と「空澄姫」。どちらも空という漢字が使われている。コレの意味について、もしかしたら共通点があるのかもしれない。また長々と考察してみるのも一興だろう。
