Misc: サイト管理メモ (001)

RSS をなんとかしたい (2006/08/06)

＠ニフティがココログを始めたのが 2003 年 12 月。そのころすでに blog が話題にはなっていましたが、＠ニフティに追従するように他の大手プロバイダも無料あるいは安い課金で blog サービスを提供するようになって、いつのまにか blog というか、スクリプトによる自動生成のウェブページというのが「標準」みたいになってしまいました。

その結果、日本語のウェブページも UTF-8 が標準になってきていて、日本語コードが 3 種類もあって、正統派は EUC-JP だけど普通に書くのは Shift_JIS が便利で、だけどときどき ISO-2000-JP も混じっているし、ソースに書いてあるコード指定と実際の文字コードが違うのでブラウザが混乱して文字化けしていることもしばしば、というこれまでの状況がだんだん統合に向かっているらしいのは、いいことだと思います。

また、blog スクリプトは新しい XHTML や CSS の基準に沿ったコードを生成するので、ウェブ全体としてはなんか急に「正しい XHTML」の割合が上がったようです。

しかし、blog とか CMS とかの自動生成スクリプトが主流になってきて、それとともに RSS とか ATOM とかの、サイト概要や更新内容を記述したファイル（フィード）を提供することが当たり前になってくると、HTML を手書きで書いている場合、ここの欠落を自力でなんとかしないと、「標準と比較して不親切」になってしまいかねません。

どうしたもんか。

サイトの移転にあたっては、普段はできない「全面的な構成の見直し」ができるので、各種の blog スクリプトや CMS も検討してみました。だけど、複雑なわりに自由にならないとか（カスタマイズも面倒）、ローカルのミラーリングにならない、とかで、とりあえず今回は採用見送り。PHP が使える環境になったので PHP は（ちょっとだけ）使うが、基本的に手書き路線続行。

……ということは、RDF、RSS、ATOM を自力で作成する必要がある、というところに現在おります。

サイト全体に PHP を使うので、動作確認のためローカルでも常にサーバーで PHP 稼働中であり、PHP によるファイル生成もできるはず、なのですが、いやはや、意地を張ったばかりに泥沼、と言えなくもない。

そういうことをやりながら、PHP スクリプトの書きかたとか RSS の仕様とかを覚えていけるのはプラスではあるのですが、サイトの移転作業としてはたいへん効率の悪いことになってます。

でも、なんとかしたい。TINAMI による自動更新チェックにも RSS を使うようになったので、それに対応したいというのもあるのです。

なんとか自力 RSS 実現 (2006/08/08)

……というわけで、2 日ほど RSS フィード関係の仕様を調べたり、Movable Type や WordPress が生成するファイルの内容を参照したり、PHP の勉強をしたり、試行錯誤を重ねて、ひとつのデータファイルから RSS 1.0、RSS 2.0、ATOM 形式のフィードを生成する PHP スクリプトが、なんとかまともに動くところまで漕ぎつけました。細かいところで不具合があるかもしれませんが、ともかくフィードの提供を開始してみます。

Blog スクリプトなどではないので、フィードを生成するにも、まずその元となるデータファイルを手作業で作成。ここに記事のタイトルや作成日時、要約などを書いておき、そのファイルを PHP で読み込んで加工という手順。

たいへんまだるっこしいことになってる、という自覚はあるんですが、手作業でウェブページを書いていると、どうももっとマシな選択肢がないわけで。でも、いまひとつわかっていないままに、形式だけ合わせてフィードを作成しているので、何か間違っている可能性もかなり高いですね。不具合あったら教えてください。

あ、連絡用のメールフォームも設置しないといけないんだった。さて、これも PHP でできるんだろうか。文字コードが UTF-8 のときの文字列処理についても、確認を取らないと……。

さらに、そんなことより、トップページにフィードへのリンク張らないとダメですよね。うむむ、しばらく何かが抜け落ちたままになりそうです。

追記 (2006/08/09) >> RSS と XSL で検索して出てきたいろいろな例を参考にして、表示変換用 XSL を作成し、この XSL を適用した RSS 2.0 のフィードを更新情報ページとしました。

RSS ICON 自動作成サービス (2006/08/08)

RSS 配信のリンクに使う小さなバナーについて、FireFox でも RSS フィードがあるページで自動的にアドレス欄に表示する小さなオレンジ色の「電波発信」アイコンが、標準として採用されていくようですが、RSS フィードの種類が複数あるので、このへんも表示しようとすると他のものが必要になります。

だいたいの形式は決まっているようなので、それに沿って自分で作成しようとも考えましたが、小さい文字の部分がなかなかうまくいかない。いろいろ探しているうちに、RSS Icons というサイトに行き当たりました。ここではスクリプトによる自動生成で、文字入りバナーを作成してくれます。「Create RSS-ICONS」のリンクから作成ページに入り、バナーのサイズ、左右の色、分割線の位置、その他を指定して「Build Icon」をクリック。

文字が詰まりすぎるときはスペースを入れてバランスを取ります。英数半角文字のみの対応です。

上記のサイトで自動生成されるバナーは色数の少ない GIF 形式です。作成後に色を変更したくなった場合は、「パレットの編集」（使用されている限られた色のそれぞれを変更する）を行います。Windows ユーザーでしたら、IrfanView （or 日本語サイト）がおすすめです。最近のは「言語ファイル」の切替でメニューをいろいろな言語に対応させることができ、日本語の言語ファイルもあります。

GIF の色パレットを編集するには、「画像」－「パレット」－「パレットの編集」とたどり、変更したい色をダブルクリックして編集、色選択ダイアログを閉じたら「更新」ボタンをクリックして画像を確認します。他に編集する色がなければ「OK」で終了し、ファイルを保存します。

トップページの画像ランダム表示について (2006/08/10)

現在、トップページの Contents 部分の画像は、ページを読み込むたびに違うものが表示されるようになっています。絵の展示をしているサイトでは、トップページに新しい画像を表示するのが普通なのですが、わたしの場合、もとからちゃんとした作品の更新頻度が低い上、このところは新しい作品を全く描いていないという状況で、すでにあるものをどう使い回すか、という方向で考えました。

この画像は、ページのソースを見ればすぐわかることですが、通常の画像のようにページの本文中にリンクを書いて表示しているのではありません。ヘッダ内での背景画像指定です。

わたしの目的としては、リロードするたびに画像が変化すればなんでもよかったのです。まず最初は普通の文中のリンクから出発。Photo Matt » Random Image Script を参考にしてやってみました。しかし、本文中のリンクにすると、リロードして画像が変化するごとに、同じページのすべてのデータが再読込されることに気がつきました。現在のうちのトップページではギャラリーの絵のサムネールも表示していますが、こういう細かい画像については、ページが更新されたという情報が発生せず、キャッシュが有効なほうがよい、と気がつきました。（このサイトの場合、日本からアクセスするとちょっと反応が遅いアメリカ西海岸のサーバーに置いているので、細かい画像の再読込はかなりマズいんです。）

本文にはキャッシュを生かしてなんとかしたい場合、本文に連動して読み込まれる CSS のほうで指定した画像を毎回変化させれば、リロード回避ができます。まずはこれをやってみました。CSS で指定する画像リンクを PHP スクリプトにする、という方法です。しかし、この方法だと、CSS ファイルそのものは毎回更新されるわけではないので、ブラウザが CSS を再読込せず、画像がなかなか変化しません。

たくさんウェブ検索した結果、やっと発見したのがページのソース内にスタイル指定を入れる方法。ページのソースのヘッダ部分にこのように記述しました。「#panel」というのは、この背景画像を適用する「<div id="panel">」に適用するスタイルということです。

<style type="text/css">
#panel { background-color: #ffffff; background-image: url($file); }
</style>

ページそのものは PHP を使って生成しています。PHP のスクリプトで先に次の処理をしてあります。

$folder = 'panel/';
$number = date('s');
$file = $folder . $number . '.jpg';

これにより、スタイル指定の url($file) の部分には、PHP スクリプトで指定した JPEG ファイルが記述されます。「date(s)」というのは「現在時刻の秒の部分」です。

なぜランダムでなく「秒」なのか、というあたりは、個人的な好みです。「秒」を使うと 60 という数がベースになるので、このままですと画像を 60 枚用意しなければなりませんが、次のように記述すれば、現在の秒数を 20 で割った余り、という数値を使うので 00.jpg から 19.jpg までの20 枚で足ります。数の組み合わせがハンパだと、画像ごとの表示の確率が均等ではなくなります。

$number = sprintf("%02d", date('s') % 20);

とりあえず画像が 40 枚ほどあったので、数は 60 のままにして、足りないぶんは適当に重複コピーを置くことにしました。使えるものが増えたら、重複するものは順次新しいもので置き換えていく予定です。

ついでに、画像の位置指定が思ったようにいかないのを避けるため、ここで使用する JPEG ファイルはすべて白の余白のある同一サイズになっています。

以上、ここで解説した「トップ画像（疑似）ランダム表示システム」を考えて構築するのには、スクリプトの問題ではなく仕組みの検討で、かなりの時間がかかりました。せっかく考えたので方法を書いておくことにしました。使えるかたは参考にしてください。

トップ画像の番号順閲覧 (2006/09/09)

トップ画像は重複分も入れて 60 枚あるわけですが、たまには自分でもぐるぐるとめくってみたくなります。で、ちょっとスクリプトを書いて、表紙からリンクで閲覧できるようにしました。スクリプトはこんなんです。数が 60 と決まってるので、ループさせるのに「%」（剰余 = 割算の余り）を使っています。


<?php
$num = $_GET['num'];
if ( $num == '' ) { $num = date('s'); }
$num = sprintf('%02d', $num % 60); // 範囲内の数値に強制変換
$image = $num . ".jpg";
$left = sprintf('%02d', ($num+59) % 60);
$right = sprintf('%02d', ($num+1) % 60);
$left_arrow = '<img src="left.gif" width="9" height="9" alt="" />';
$right_arrow = '<img src="right.gif" width="9" height="9" alt="" />';

include('header.php');

print<<<_BODY_
<img src="$image" width="760" height="400" /><br />
<p class="center">
<a href="showcase.php?num=$left">$left_arrow</a> &nbsp; $num &nbsp; 
<a href="showcase.php?num=$right">$right_arrow</a>
</p>
_BODY_;

include('footer.php');
?>

PHP でページのヘッダ部分とフッタ部分をつけるのって、便利ですね。まだ慣れていないので物珍しいのもありますが、なかなか気に入っています。

追記 (2006/09/12) >> 公開された場所に置くスクリプトは渡されるデータにチェックを入れなければいけない、というルールを思い出したので、悪用のしようがないと思われるスクリプトですが、ルールに合うように補完（強制変換）しました。

追記 (2006/12/14) >> このページでのコード表示を、スクリプトファイルそのものを読み込んで PHP の highlight_file 関数で色分け表示する方法に変更しました。

DreamHost の再出発 (2006/10/07)

現在このサイトは DreamHost に置いているのですが、きょうコントロールパネルを見たらディスク容量が 420 ギガになってました。あれれ。10月初旬に大幅増量があったようです。「ほとんどのユーザーは容量を使い切らない」想定での上限ではあるのですが、それでも今後、いろいろな種類のファイルを置くこともあるだろうと考えると、これは安心。あと月ごとの転送量の上限も 4.6 テラバイトになってました。

ここを契約したのは 2005 年の 8 月で、コースは Code Monster、2 年ぶん先払いで月額 $15.95、契約当時のディスク容量は 15 ギガくらいか、もっと少なかったかも。やたらと容量が増えた今では、いちばん安いコースでじゅうぶんですね。

じつは 7 月、 8 月、9 月と DreamHost はトラブル続きで、いったいこのままここでサイト運営をしていけるんだろうか、とたいへん心配しました。まずは夏の酷暑による Los Angeles 地域の大停電。サーバが入っている建物は電源が 2 系統で供給され、さらに非常時自家発電装置も備え付けではあるのですが、うまく自家発電装置が稼働せずサーバダウン。それに続いてファイルサーバの問題、ルータの問題、その他よくわからない専門的な問題がいろいろ。

断続的につながらないとか、つながるけど重いとか、そういう状態が数日続くというのが何度もありました。しかし、DreamHost が面白いのは、この経緯をたいへん正直かつ丁寧に説明してくれるあたり。Anatomy of a(n ongoing) Disaster.. と Anatomy of a Disaster, Part 2。どちらも長い記事です。

この記事が掲載されたのは The Official DreamHost Weblog ですが、なんと言うか、会社というより大学のサークル的なノリ。でも、サポートは今まで使ったなかでいちばん感触がいい。コントロールパネルから「こういう問題がある」というのを報告すると、必ずちゃんとしたメール連絡があり、同時にそれが自分のアカウントの記録として残っていきます。

この「なんとなく雰囲気が好き」という理由で、夏のトラブルの間もガマンして耐えてたのが、やっとこのごろ根本的な見直しも終わって、本来の状態で稼働するようになりました。このままだといいんですが。

ただし、日本語関係は PHP のマルチバイトが公式にはサポートなし、MySQL も日本語はうまくデータのエクスポートができない、など問題がたくさんあるので、それほどおすすめはできません。

カスタム 404 ページで 404 ヘッダを返す (2007/02/19)

ウェブサイトをある程度設定が自由になるサーバで公開するとき、存在しないページを呼び出そうとしたときのエラー表示である「404 Not Found」をカスタマイズする、というのはわりとよくやることだと思います。うちのサイトでも 404.html を用意し、.htaccess ファイルに設定を書いて、呼ばれたファイルがないときはこのページを表示するようにしています。

が、この設定とバッティングする事態が出てきました。Google Webmaster Tools というのがあるのを見つけて、これを使ってみようとしたら、サイト管理者本人であることの確認（Verification）が必要になったのですが、「この名前のファイルをインデックス直下に置け」と言われてそのとおりしても、「存在しないページでちゃんと 404 ヘッダが返ってこない、200 OK が返ってくる」という理由で「確認できず」という結果になってしまったんです。

確認の方法としては、この他にも、「インデックスページに指定されたメタタグを入れる」という方法もあるのですが、Google だけのためにメタタグを入れるというのも、あまりやりたくない。

となると、カスタマイズした「そのページはありません」表示をしていても、ヘッダは「404 Not Found」でなければならないわけです。で、ヘッダというのはページのソースでもなくて、どうしたもんか、と考え込みましたが、PHP に header という関数があるのを思い出したので、これで解決しました。そういうわけで、現在のうちの「404.html」ページの先頭には、

<?php
header("HTTP/1.0 404 Not Found");
print<<<_HEADER_
<?xml version="1.0" encoding="UTF-8"?>

_HEADER_;
?>

と追加してあります。これで Google も納得してくれたようです。ソースを表示して見えるのは「<?xml version=」以下です。（この行は XML 宣言が PHP の設定でショートタグがオンの場合はエラーになるので、print で書いています。また、その直後の空行は、ここで改行を入れるためのものです。）

uptime ログ取り (2007/10/07)

現在このサイトを置いている DreamHost は、容量のわりに安くて自由度が高いのがよいのですが、料金が安い理由というのは当然ながら、ユーザーを詰め込んでいてこそ実現できているわけです。詰め込みつつもそこそこ動くようにしているあたり、スキルのあるところだという印象はあります。しかし、サーバーが不調になったり、あるいは落ちることもときどきあるのも事実。

重大なトラブルであれば DreamHost Status でも報告があります。ブログ形式でコメントもつけられるため、「使いものにならないので他に行く」というコメント多数。その気持ちもわかる。でも、そんな都合のいい「他のところ」はたぶん、ない。

そういうわけで、まだしばらくはここを使っていくつもりですが、多少はサーバーの状態も把握してみようか、と、uptime のログ取りをしてみることにしました（最新のログはこちら）。で、しばらくしてサーバー落ちの痕跡発見。

 08:25:04 up 3 days, 21:11,  3 users,  load average: 31.29, 30.78, 21.11
 08:42:48 up 3 days, 21:29,  3 users,  load average: 73.62, 84.81, 815.26
 08:45:42 up 3 days, 21:32,  3 users,  load average: 729.77, 14.51, 54.69
 09:10:03 up 6 min,  0 users,  load average: 7.14, 5.98, 2.77
 09:15:02 up 11 min,  0 users,  load average: 6.79, 6.07, 3.70
 09:20:03 up 16 min,  0 users,  load average: 4.36, 5.29, 4.07

誰かが何か暴走させたのか。ユーザー多いからなぁ。逆に、サーバーに再起動がかかってもこんなところにしか痕跡がないのは、それなりにうまく管理されているということなんだろうか。

load average は恒常的にかなりダメ（というか、悲惨？）な領域の数値なのに、ウェブページ読み込みはそれほど重くないようです（データ転送はすべて圧縮してるというようなことが、どこかに書いてあったと思います）。サーバーの構成が複雑で（実体上は隣にあるサブドメインどうしが、まったく別の IP アドレスになったりしてます）、いろいろ処理が分散されてて、ユーザーからは見えない部分で何とかしてるらしいです。わたしはこのへん知識もないので、「動いてれば、ま、いいんじゃないの」としか言えません。

DreamHost 内でサーバー移動 (2007/10/13)

こんとこサーバーが重かったり、さらにそれがひどくなって完全に落ち、再起動がかかったり、という状況が数日続いたので、サポートに連絡したら、load average が高すぎる状態が続いていることはすぐ認めてくれて、「じゃ、他のサーバーにアカウント移しましょうか」ということになりました。

高負荷の原因については、少数の特定のスクリプトなどが問題なのではなくて、多数のものがさまざまな時間帯に分散して負荷をかけているので、対応がむずかしい、ということでした。まあ、サーバーあたりのユーザー数はかなり多いようなので、そういうこともあるかと思います。

ファイルを漏れなくきっちり移動してもらえるのか、ちょっと心配だったのですが、さっき「移動完了しました」という連絡がありました。なんか 3 分で処理できたようです。ちょうどそのあたりの時間帯にファイルをアップロードしたりもしてたので、キツネにつままれたような気分でしたが、自動実行で取っている uptime のログ内容が切り替わってるので、ホントに移動したようです。

 07:00:02 up 16:18,  4 users,  load average: 7.74, 9.61, 8.77
 07:05:02 up 16:23,  4 users,  load average: 7.63, 9.66, 9.22
 07:10:02 up 16:28,  4 users,  load average: 4.45, 7.70, 8.66
 07:20:02 up 229 days, 15 min,  3 users,  load average: 3.88, 7.05, 5.18
 07:25:01 up 229 days, 20 min,  3 users,  load average: 4.27, 6.17, 5.33
 07:30:01 up 229 days, 25 min,  4 users,  load average: 3.83, 4.83, 4.98

追記 (8 hours later) >> DreamHost のサーバー構成はかなり複雑なので、「別のサーバーに移動」というのは「処理をするサーバー」が変更になっただけで、「ファイルの置場」はこれまでと同じなのかもしれません。ついでですが、Xeon 2.4GHz x 4 のサーバーから Xeon 2.8GHz x 4 のサーバーに移動になりました。ここのサーバーは Xeon x 4 か Opteron x 2 のようです。

Gallery 英語対応完了(2008/09/16)

サイト移行からこれまで、Gallery は日本語ページだけでしたが、すべてのページを英語と二重化する作業を 3 日ほどかけて完了しました。英語セクションへは Gallery のインデックスページから English というリンクがあります。

サイトの英語対応は当初から計画していましたが、なかなか時間を取れずにサイトの構築そのものが滞るなかで、2 年間放置したままになっていました。具体的にどのように二重化するかという点も、ディレクトリごと二重化するか、ページのみを重複させるか、という選択肢を長いこと行ったり来たりしていました。

そして、先週やっと本格的に手をつけて少し作業を進めた時点で、このサイトは Painter 関連が中心でもあり画像が多いこともあり、ディレクトリごと二重化することは単にファイルの数や容量だけでなく、管理の点からも望ましくないという結論を出しました。

そういうわけで、基本的に英語のページは日本語のテキスト部分だけを別ファイルとし、共通の画像ファイルを読み込むという仕様になっています。できるだけ今後の更新およびメンテナンス作業をシンプルにするため、PHP による横方向へのリンク記述のスクリプトなども共通ファイルによって行うことにしました。

このスクリプトの改造作業のなかで、ちょっとした小細工のために以前に行った調整について、その意図をすっかり忘れていたために、ムダなルーチンだと思って削除してしまって（まあ、なんつか、コメントの記述が曖昧だったのがイカンのですが）、それに後から気づいて戻したり、たまにしかサイト編集をしないと混乱します。

この仕様で何とか無事に構成できました。が、英語のテキストの作成は自動化できないので、数年分の Gallery の内容ですからそれなりに数があり、かなり時間を取られました。それにしても、このところ時間がなくて Gallery に追加できるような絵を描けてないのがたいへん問題です。

DreamHost での HTML > PHP 設定 (2009/01/09)

DreamHost では現在、新しく設定したドメイン及びサブドメインについて、PHP5 を CGI で動かすという選択肢しかありません。PHP が CGI として動作している場合、HTML ファイルを PHP ファイルと同等に処理させるにはどうするか、.htaccess でひとしきり試してみたので、その結果をメモ。

AddType php-script .html ― PHP4 mod_php
AddHandler php-script .html ― PHP4 mod_php
AddType cgi-script .html ― 500 Internal Server Error
AddHandler application/x-httpd-php .html ― PHP4 mod_php
AddType application/x-httpd-php .html ― PHP4 mod_php
AddHandler php-cgi .html ― PHP4 CGI
AddHandler php5-script .html ― 処理されず（生コード）
AddHandler php5-cgi .html ― PHP5 CGI

「AddHandler php5-cgi .html ― PHP5 CGI」以外はここのサーバーではサポート外であり（いつ全く使えなくなるかわからない）、さらに phpinfo で確認すればわかりますが、それ以外では PHP の機能が削られるみたいなのであまり使わないほうがよろしいようです。

ついでに少しあちこちのファイルを見直していたら、Gallery のヘッダスクリプトにバグ発見。「=」で内容を割り当てるべきところが「==」になってたのと、変数先頭の「$」抜けという初歩的なやつ。英語と日本語の振り分けを入れたときに、混入したもよう。あわてて修正しました。

PHP4 から PHP5 へ (2009/04/26)

とっても今さら、な感じですが、ローカル環境もレンタルサーバの環境も PHP4 から PHP5 に移行しました。ローカルは新しいパソコン組んで環境が変わり、新規に XAMPP を入れたため、レンタルサーバは .htaccess で無理やり mod_php で動かすのをやめたため、です。使用しているレンタルサーバの DreamHost ではずっと前に mod_php モードが使える PHP4 は新規では選択できなくなってました。サイト内容を別のサブドメインにコピーして PHP5 の CGI モードで動かしてみたら、速度もまったく遜色なかったので、4 月 19 日あたりに「無理やりな .htaccess」をはずして、PHP5 に切り替えました。

メインのマシンを入れ替えるというのは、なかなかの手間で、1 月中には組み上がっていたものの、ツール類の移行が一瞬ではできず、（この際、どうでもいいのは少しは取捨選択したい、と思ったりするので、ちょっと目を通したりすることもあります）、組立場所から通常稼働位置に移動したのが 4 月 15 日で、まだ未インストールのツールが残っています。

さすがに新しい環境では Painter 11 も快適に動いています（古い環境は Windows 2000 なのでインストールもできませんでした）。Windows XP になってシステムがデュアルモニタに対応してるので、アプリケーションの「全画面表示」モードはメインの画面に対してのものになり、Windows 2000 （デュアルヘッドのビデオカード使用）のときみたいに Painter の起動スプラッシュや Welcome 画面が 2 つの画面の継目のところに表示されることがなくなって、かなりうれしいです。

というわけで、このサイトの各ページの自動リンクとか「伝言板」とかも PHP5 で動いております。CGI モードだとパーミッションが楽になるし、もっとさっさと移行してもよかったのですが、「いちど変更したら戻せない」という選択なので躊躇して延ばしてました。最後は「サイトの内部に DokuWiki を入れてみたい」という動機で踏み切りました。DokuWiki は自動インストーラがすごく便利な、ファイルベースの Wiki です。mod_php で動かすとキャッシュフォルダとかのパーミッション設定を手動でやらないとダメで、アップデートでインストールしなおすことも考えるとしんどくなったので、見切りをつけました。

DokuWiki をサイト内に設置 (2009/06/14)

このサイトではブログツール類は、このサイトを作成する以前からサイト外で使っている painter log の他にはずっと使ってこなかったのですが、ウェブページの自動生成、すなわちタグ打ちとページ管理からの解放というのはやはり魅力的であり、ヒューマンエラーを減らすことにもつながるので、サイト構築をほぼ手書きでやりながらも、ずっと気になっていました。ブログツールや CMS もわりといろいろウォッチングしたり試用したりしてきました。その検討にたいへん時間がかかったのですが、このたび DokuWiki をサイトの一部に使ってみることにしました。

自動生成機能があるスクリプトというのは、いったん稼働させはじめたらサイト内構造とかを変更するのが面倒だし、ほんとうにそれなりに快適に使えるのかどうか納得するために、しばらく他の場所で動作させてみたりもしました。そしてやっと Memo コーナーとして導入。

なぜ DokuWiki に落ち着いたか、というあたりは DokuWiki 覚書を読んでいただくとわかると思います。まずは「ファイルベース」の Wiki だったこと。個人が管理するものとしては、ファイルベースのほうが扱いやすいと思います。

サーバー上にこういったものを置いておくと、自分用のメモを取るにも便利です。メモを記録し、さらにそれを再編集できるようなスクリプトを自分で書くよりは、すでに公開されている高度なツールを使わせていただいたほうがよい、と考えました。

Wiki 本来の複数の書き手による情報集積というのは、その情報がきちんと永続的に共有される保障がないかぎり、書き手がわに「ムダ働き」の懸念があるわけで、組織の内部のような場所か、あるいは完全に個人を離れた公共のサイトでないとむずかしい気がします。ここはどうしても「個人サイト」という枠組みがありますので、この Wiki は基本的に Painter の質問に答える場になる予定です。（ただ、公共性を目指して、「基本的に再利用自由なデータ」として公開するべく、Creative Commons の宣言をしております。）

質問を受ける目的のために普通の「掲示板」を設置することも考えたのですが、以前に掲示板で質問を受けたときに、どうしても実例や図解の画像ファイルを参照する必要が出てきた経験があり、添付ファイルをどうするか、という課題が残っていたために現在まで設置に至っていませんでした。DokuWiki を使うと、このあたりはセキュリティ対策も含めてきちんと対応できます。いっぽう、Painter 11 の公開あたりから Painter Factory など Painter 関連の英語のフォーラムも時々見るようになり、多少複雑な掲示板でも質問の場として問題なさそうな印象を得ました。

……というような経緯での設置です。この Wiki の運用について疑問や提案などありましたら、Wiki 内、伝言板、連絡フォームなどで教えてください。

RSS 周辺の再確認 (2009/06/15)

DokuWiki で RSS フィード読み込み機能を使ったページを作成してみたのをきっかけに、自分のところの RSS も見直してみました（個別アイテムにも作者タグを入れるように変更しました）。以前、更新メモから RSS フィードを作るスクリプトを書くために RSS の仕様について調べたとき情報が少なくて苦労して、TypePad が生成するファイルなんかも参考にしたのですが、きょう「RSS specification」で検索したら何だかけっこういろいろあるみたい。以前に調べて回ってから約 3 年、RSS もさらに普及したわけですね。RSS 2.0 の仕様も少し改訂されてオプション項目が増えたようです。（日本語圏の情報は「RSS 仕様」で検索できます。）

よく見に行くウェブサイトの更新状況を知りたい、という要請はずっと以前からあって、一時は WWWC という更新チェックツールが日本ではわりと使われていました。情報をチェックするがわでリストしたサイトに対して WWWC を走らせて、トップページのファイルが更新されたかどうかをチェックするしくみですが、さらに WWWC に合わせた META タグをトップページに入れておくと WWWC がその内容を読み、まとめてくれるという機能がありました。しかし、普及度がいまひとつ。

このほかに「はてな」が登録ページの更新チェックのサービスをやってたようですし、以前の TINAMI の更新情報は WWWC と同じく専用 META タグによるものでした。

ブログツールの普及によって、高レベルでのウェブページの作法の平準化が起き、高度な CSS の使用があたりまえになり、日本語サイトの UTF-8 化も進みました。さらに、ブログや CMS で生成されるウェブページの割合が日増しに高くなる中で RSS があたりまえになり、利用者が増えて、そろそろ「RSS が提供されていないと不便に感じる」ところまで来てしまったような印象です。

RSS フィードを生成するためのツールも有料・無料、いろいろあるようです。上記の「RSS specification」での検索でトップに表示されたのが RSS 作成ツール販売の会社でしたが、「RSS 生成」で検索すると無償のものもかなりあるのがわかります。窓の杜 RSS 作成支援のものが無料のものでは代表的らしいです。

なお、RSS 生成についてかなり前から公開されている CGI スクリプトとして The Web Kanzaki - RSS 生成スクリプトのサンプルがあります。これは特定のページに「更新情報」のセクションがあることを前提に、そのデータを RSS に加工するものです。うちのサイトでやっていることも基本的なアプローチは同じで、RSS のために特定のデータを用意します。ただ、「更新情報」のページから RSS を生成するのではなく、多少自動化した（テキストエディタマクロ使用の）手書きによる元データを加工して RSS と更新情報の両方を生成しています。