最終更新日：2005.07.17
webmaster@kototone.jp
こととねは、クリエイティブ・コモンズ・ライセンス（表示 - 継承 2.1 日本）の下でライセンスされています。
6月5日に公開されたweb拍手改造文書において致命的な誤りを発生させた問題について、簡単ながら分析を行ってみた。以下はそのレポート。
実をいうと、私はweb拍手改造についていろいろと書いてはいるものの、実際にその改造を自サイトに設置したweb拍手に施しているわけではない。私のweb拍手CGIは、本年3月1日に公開されたその時点で施されていた改造を最後として、その後は手を加えられていない。私が行った改造は、HTMLの書き換えと外部CSSへのリンクの作成くらいなもので、基本的な部分はほぼデフォルトのままであるといってよい。
2005年4月14日から掲載され始めたweb拍手改造については、Windows機上でプログラムを変更、動作を確認した上で、プログラムファイルをメインマシンであるiBookに送り、改造文書を書くという手順をとっている。なぜここでiBookでプログラムを作成せずわざわざ別のWindows機で行っているのかというと、私の使用しているWebサーバがMicrosoft社のIIS 5.0であるため。テスト環境には、サーバで使われているActivePerl 5.6 Build 629に合わせて、ActivePerl 5.6.1.638がインストールされている。
PerlがデフォルトでインストールされているOS X（現時点におけるPerlのバージョンは5.8.6だった）をメインマシンに用いながら、テスト環境にWindows機を使用するのは、以上の理由からである。
プログラムを書き換え、動作を確認した後、変更箇所だけをまとめたテキストファイルを作成。改造CGIと改造のサマリーをiBookに送るのがいつものプロセスである。これまでのweb拍手改造文書においては、ただ一度の例外を除き、常にこの手順が踏まれていた。プログラムソースを、例えば画面を見ながら、あるいはプリントアウトを見ながら打ち直すのは誤りの元であり、あまりよい手とはいえない。そのため、コンピュータお得意のコピー＆ペーストを行うのは、誤りを発生させないという点からも、また効率の面からも非常に正しいやり方だろう。
しかし、6月5日文書では、その改造の範囲が非常に小規模であったために、ファイルを移す手間を嫌ってしまった。オリジナルのweb拍手CGIから改造箇所をコピーし、改造文書上で改変を行うという手段をとった。
この際、私の頭の中では、次の更新――プランAを用いた改造――に焦点が合わせられていた。より説明がややこしくなることを予想して、必要な説明の大半を問題文書中で行おうと考え、結果的に説明の作成に労力を集中させることとなった。
私は、問題の改造――プランB――は簡単であると考えていたため、問題の改造コード例を作成するときには、すっかり気を抜いてしまっていた。そうして、それまで散々説明してきた手順とは異なる改造例を作成するにいたった。
誤りの発生にいたった背景は以上のとおりである。すなわち、ファイルを移すという手間を惜しんだこと、改造失敗時の危険性を軽視したこと、そして改造を簡単に考えてしまっていたこと。
以上である。
琵琶記に曰く、好事魔多し。私は今回ほどその意味の重さを思ったことはない。もし私の誤りをもとに改造を試み、無駄に時間と労力を浪費した方がいらっしゃったら、心からおわび申し上げたい。
< web拍手改造文書における誤りとその修正 web拍手改造：文字化け要因を解消する >