最近は無料で作れるブログも結構あったりするので、 あちこちにブログを開いてしまう人もいるというか、私もそうなのだが、 そうなるとどこに何書いているのか分からないとか、 読者から一箇所にまとめてくれみたいなメールが来たりするとか、 そういう話が出てくる訳だが、 私の場合は一箇所にまとめろと言われたことはまだないような気がする。 ブログ毎にテーマを決めて書いているからだと思う。

ココログの「裏の裏ページ」にはどうでもいい話を書いている。 Jugem の「裏表」には最初、株の話を集めていたが、 予定が変わってプログラミングに関する話を中心にした。 Ameba Blog の「裏ご意見番」には、 主にユーザーインターフェースに関するコラムを書いている。 自分としては、ここが一番ブログっぽいような気がするのだが、 最近は、ブログといえばショートメッセージの日記みたいな感じのものが主流になっているような気もする。 最後に、かなりの冒険だが、 livedoor の「幸せはいつも窓の外側にある」ではネット小説を連載している。

※ 他にも個人ブログがある。

この中で一番無節操なのがココログの「裏の裏ページ」だ。 冗談を1行だけ書くこともあれば、 真面目に時事論評を書くこともある。 無節操なのは私のキャラだから別にいいが、 流行ネタの場合、1年たつと自分ですら「何だっけ」ということがあるのが困る。 本家「裏ページ」などは前世紀から公開しているのだし、 プログラマーズフォーラムの不定期連載ともなると、 十数年前に書いたものもある。 こうなると、 自分で書いた文章の意味がさっぱり分からなくなってしまうのだ。

そこで、 まず試しにカコログというページを公開することにした。 「裏の裏ページ」に書いた記事を別サイトに転載するのである。 その際、 コメントも含めてコピーすると何か著作権関係で波乱が起きそうな気がするので、 転載するのは私の書いた本文だけにしている。 逆に、本文だけ転載することを前提にして、 あまりコメントの連鎖で話が進行しないよう、 面白そうなコメントにはレスポンスを別記事に書いてしまうとか、 そういう工夫もしている。

§

ココログの記事をカコログに転載するときに、 かねてからやりたかったことを一つ実現した。 後から書いた注釈を、本文の横に表示するのだ。

※ このコラムのページがそうなっている。

先に書いたとおり、 流行ネタはすぐに自分でも分からなくなる。 そこで、 後で分からなくなりそうな内容を、注釈としてメモっておくのだ。 例えば「ヒロシです」とはどういう意味なのか、 ということを、本文の横に書いておく。 これで十年たっても意味が分からなくなることはまずないし、 文化史のようなドキュメントになるというメリットもある。 自分の書いたことに補記も書けるし、 かなり便利である。

ヒロシ: 2004年にブレイクした自虐系お笑い芸人。

記事を転載する狙いが、実はもう一つある。 ココログのサイトを表示すれば分かるように、 ココログは TypeAad というソフトウェアがベースになっている。 TypePad は、記事を書いた時点で、 いろいろな読まれ方を想定し、 その時に表示するためのページをあらかじめ作っておく仕組みのようだ。 例えば「ヒロシです。買ったソフトのCD-ROMがエラーで読めません。」 という話を書いたとしよう。 その文章は、単独の記事として参照するためのファイル、 コンピュータというカテゴリ別になっているファイル、 日付別のファイル、 月別のアーカイブのファイル、 といったように複数のコピーを作って保持されるようなのだ。

このようにファイルをあらかじめ作成すれば、 サーバーがページを表示するときの負荷は軽くなる。 この手法に対して、 記事データは1つだけ保存しておき、 「月別のページを表示しろ」のような要求があったら、 そのときにページを生成するやり方もある。 この場合は、基本的には毎回ページを生成することになるから、 サーバーの負荷は高くなり、 ページの表示が遅くなるリスクが高くなってしまう。 もちろん、 キャッシュを使う等の工夫をして、 負荷を軽くすることも不可能ではないが。

さて、ファイルをあらかじめ作るということは、 そのためのディスクを消費することを意味する。 実際、ココログを使ってみた感じでは、 私の場合、文章データの約8倍のディスクスペースが必要になるようだ。 大雑把にいって、1年間で書いた内容が約1MBあるのだが、 ココログの管理画面でディスク使用量を見ると、8MB使ったことになっている、 という意味だ。

ココログのディスクは無料で30MBまで使える。 ということは、画像とかも含めると、 3年程度で容量を使い切って更新できなくなりそうだ、という計算になる。 実際、思ったより急激に残り容量が減っているため、 あえて画像をあまり使わないようにするとか、 そういう余計な心配をしなければならないという弊害もある訳で、 一利用者としてはあまり面白くない。 もちろん、料金さえ払えば、容量を増やすことは可能なのだが。

※ 無料で使える容量をじわじわと増加させていく戦略らしい。

ということで、ココログの記事をカコログに転載して、 ココログの本文は消してしまう、という対応方法も視野に入れているのだ。 カコログは1か月単位で記事をまとめてある。 日付別やカテゴリ別に記事を読むことはできなくなるが、 1年もも前の記事をそういう読み方することもないだろ、 と勝手に決め付けて、1か月単位の記事だけにした。 ということは、1MBのテキストはあくまで1MBしか使わないで済む。

§

カコログの画面は、注釈を本文の横に表示するようになっている。 これを HTML の TABLE を使って実現している。 別に本文横に注釈を書かなくてもいいのでは、 というご指摘もいただいたのだが、 確かにそれはそうである。 ただ、カコログは、もともと「注釈を本文の横に表示したい」 という要求から始まって作ったページなので、横に書かないと、 その点、意味がなくなってしまうのだ。

技術書とか、コラム、エッセイ系の本を買うと、 本文があって、その下のスペースに注釈だけを分けて書いてあるものがある。 自分としては、このような構成は意外と読みやすいじゃないか、 とか思っていたので、Webページもそういう表示にしたかったのだ。 ただ、そういう形式の画面を作るのが、かなりの手間なのである。 TABLE を使うとあっさり紹介したが、 後で編集したい場合にどうするとか、 注釈の位置を変更したいときはどうとか、 実際にやってみれば、すぐに挫折するのが分かると思う。

そこで、カコログを作るにあたり、 次のような手順を踏むことにした。 まず、ココログの内容をファイルに保存し、 それを編集して注釈を付ける。 これに手作業て TABLE タグを付けるなんてのは論外だから、 注釈付きのデータを変換して、横に注釈を表示するための TABLE 状態にしたものを生成するプログラムを書くのだ。 もう少し本気になれば、GUIを駆使してそのためのエディタを作る、 という所まであるのかもしれないが、 そこまでは意欲が…ということで、いい加減なところに妥協点を見出したのである。

§

まず仕様を固めよう。 注釈は具体的に、どのように書くことにしようか。 本文が段落ごとに <p> で区切られているという前提で、 次のいずれかの条件を満たすものを、注釈と判定することにした。

(1) 段落の最初の文字が「※」の場合。 つまり、本文中に注釈を後から追加したい場合、 単に「※」で始まるパラグラフを追加すればいいことにする。 「※」で始まる本文は書けないことになるが、実用上問題ない。 この仕様で、手間は猛烈に軽減されるわけだ。

(2) 段落に note というクラスが指定されている場合。 つまり、<p class="note"> というパラグラフは注釈とみなすことにする。 これは、注釈の先頭に「※」を書きたくない場合や、 注釈が長くなって、1つのパラグラフでは書ききれないような場合に使うことにする。

このような書き方で注釈を本文に混ぜるということを決めたら、 次は、そのように書かれた HTML のデータを、 TABLE を使って整形するプログラムを作る必要がある。 fig.1 のように書いたデータは、 整形することで fig.2 のようになる。

---- fig.1 整形前の画面----

　(1) 本文
  (2) ※注釈

---- fig.2 整形後の画面----

　――――――――――――――――――
　(1) 本文　　　　　　　　　(2) ※注釈
　――――――――――――――――――

「裏ご意見番」には、 このように変換するアルゴリズムを考えるという問題だけを紹介したが、 Cマガジンに実装例を紹介するつもりで、 解答なしの状態で放置してある。 「裏ご意見番」には、ややこしい例として、 (1) 注釈、(2) 注釈、(3) 本文、(4) 注釈、(5) 本文、 (6) 本文、 (7) 本文、 (8) 注釈、 (9) 本文、 の順にパラグラフが出現した場合を紹介している。 期待する結果は fig.3 である。

※ アルゴリズムのクイズで紹介した。

---- fig.3 ややこしい例 ----

　――――――――――――――――――
　　　　　　　　　　　　　　(1) 注釈
　　　　　　　　　　　　　　(2) 注釈
　――――――――――――――――――
　(3) 本文　　　　　　　　　(4) 注釈
　――――――――――――――――――
　(5) 本文
　(6) 本文
　――――――――――――――――――
　(7) 本文　　　　　　　　　(8) 注釈
　――――――――――――――――――
　(9) 本文

なお、この仕様だと、 複数の本文に対して一つの注釈を書くことができない。 そこまで実現するには、どんどん処理がややこしくなりそうなので、 既に十分ややこしいということで、 実用的にこれで十分か、というあたりで妥協したのである。 結局今回も解答例が書けないので、この話は次号に続く。