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 に追加できるような絵を描けてないのがたいへん問題です。