最近 tdiary.org, tdiary.net がハードウェア障害で落ちっぱなしだ。ずっとただのにっきの rss の取得に失敗していたのでまた重いだけなのかと思ってしまっていたけど違った。mod_rewrite か何かでフツーにブラウザでアクセスしたときにはどんなパスでも障害が分かるようになっていたんだけど、自分とサーバに負荷が少ない（はず）の rss リーダーではパースできずに error になってしまうという困った状態。
しかしサーバ側で rss を生成している場合は障害情報のエラーを rss で出すのはちょっとメンドイよね。障害情報用のテンプレートを手元に用意して置いておくとかが現実的な対応方法だろうか。で、request uri が .rss とか /?cmd=rss とか index.rdf とかだったらそっちを返す。
こういうのは明日は我が身なのでほんとはどこかに情報が集まってるといいんだろうなぁ。Web サーバ管理者のほんとの虎の巻とでも言ったらいいのか。。。障害告知だけを目的とした緊急事態セット、みたいな。分かる人なら適当なマシンに Apache 突っ込んで rewrite とか 403 でとにかくエラーを吐く仕掛けを作るのは雑作のないことだけど、この RSS ってのは普段自分で使っておきながら盲点だと思った。もう一度整理しよう。
- 障害告知用緊急 Web サーバセット
- 通常のアクセスには 403 や mod_rewrite を使ってエラーページを返す
- mod_rewrite で、使っていた blog ツールに応じて index.rdf, index.rss, index.xml, /?cmd=rss などの uri の際には rss の形のエラーページを返す
よし。とりあえず Apache 前提だけど、使い慣れたアプリケーションサーバ（Zope とか）で同じことができればそれを使ってもいいと思う。（「アプリケーションサーバ」になっちゃうと緊急事態に使うにはちとヘビーな気がするけど。）
とりあえず普段からそれなりに見栄えのする error ページをどうにかして（それこそ blog ツールの吐き出した HTML をもとにしてもよい）用意しておいた方がよさげですな。手書きであろう素っ気ない HTML を見ると、なんかどうも痛々しい。（実際痛いんだろうけど。）
明日からの課題にしておこう。
それにしても tdiary.org, tdiary.net の障害、長いね。tdiary.net のサーバは複数あるんだけど、それぞれでバックアップの役割を担えるような、そういう運用体制を目指すべきでしたな。あとから言うのは簡単だし、当事者には申し訳ないけど、これはこれで勉強になる。
tdiary.net は確かサーバ提供者を募集していたように思うんだけど、その際のサーバの運用体制はオープンなドキュメントにはなっていなかったように思う。（Zebedee を入れてくれとかそういう指示はあったけど。）例えばこういう運用体制でいきますってのがもっと明確になっていれば、「あ、こういう管理なら（ハードウェア資源は出せないけど）オレも手伝える」という人が出てきたかもしんないなーとか、ちょっと妄想してみる。流行り言葉で言えばオープンソースなサーバ管理？ ひょっとするとこういう運用の方が障害に強いぞ、という意見が出てきてもっと「強い」tdiary.net ができたのかもしんない。（逆に初心者が実運用の輪に入っちゃうとセキュリティ的にはかなりやばいけど。）
考えたらディストリビューションやアプリについてはユーザーコミュニティってのは簡単に見つかるけどサーバ管理コミュニティなんてないよな(^^; あんのかな。自分もそうだけど「あーこういうときのノウハウってどうなってんだ？」てなことを思ってる人って結構居るんじゃないかなと思うし、「自分はこういうノウハウはあるけど、こっちのノウハウは誰かに教えてもらいたい」なんてケースもあるような気がする。
広告の挿入位置を自由に自分で決められる（例えば xrea とか）ところはともかく、そうでない場合はたいていページ上部（または、および下部）に自動挿入される。
これは例えば Apache の mod_layout なんかを使えばできる（文字コード判別とかどうやってんのか知らないけど）。mod_layout はとにかく吐き出される HTML の <body> 直後と </body> 直前にあらかじめ決められた文字列を吐き出すもの。HTML が生 HTML だろうが動的に生成されたものだろうが関係ない。そういう仕掛けがサーバで動いてるんだなってことが分かればこの広告の仕組みはまったく不思議でもなんでもないし、ページデザイン上の配慮もやりやすい。
いちばん簡単なのは自分の作るページを <div id="page"></div> などで囲ってしまうことである。そうするとヘッダおよびフッタに影響を与えずに自分の作ったコンテンツだけにデザインを施すことができる。全部 div#page 内に対してスタイルを指定していけばよい。ソースで書くとこんな感じ。
<!DOCTYPE>
<html>
<head>
ここは自由に書ける
</head>
<body>
<!--
ここは mod_layout でコンテンツが挿入される
-->
<div id="page">
この中に自分の作ったコンテンツが入る
</div>
<!--
ここは mod_layout でコンテンツが挿入される
-->
</body>
</html>
で、css はこんな感じ。
body {
ここは広告に対するスタイルにしておく
}
div#page {
ここに自分のコンテンツ全体に対するスタイルを書く
}
div#page table {
広告はたいがい table 組みしてるので、
素の table にはスタイルを設定しないでおく
table に class を指定してもいいけど
html を手書きするときは邪魔くさいし、ソース
読みにくくなるじゃん
}
ドローと言っても自分が求めているのは「手早いテクニカルドローイング」であって、Illustrator のような精緻な絵が描けるものじゃない。概念図、構成図が掛ければいいのだ。この自分の求めているタイプのドローソフトは
- クロスプラットフォームを意識した製品がインスピ以外は Canvas くらいしかない
- それか Illustrator とか FreeHand とか Corel Draw とか、およそ手早さとは縁のない世界の製品ばっかり
- Canvas も機能てんこ盛りで高い
- そのインスピを始め、海外の製品は多言語対応を意識していないものが多い
- インスピは日本の代理店がちゃんと最新版フォローしてくれないのに料金は元の3倍くらいする。パッケージもマニュアルも要らんから安くしてくれ。
- 日本製のものは Windows 依存しまくりなうえに、なんだか微妙にダサい（まだあまり試してない）
- フリーのものはグリッドが粗すぎたり操作が洗練されてなかったり、汎用的なベクトルグラフィック形式に export できないとか、できてもマニアック（sodipodi の SVG 限定）とか、あれこれ面倒な制約がついてまわる
ということなので、
- 汎用の形式に export 可能
- 操作性や目的の構成図、概念図に必要なパーツが揃っている
のであれば、クロスプラットフォームにはこだわらないでみようかなぁと思い始めてきた。とりあえず Mac では OmniGraffle がそこそこの値段だし UML も構成図も描けるのでこれがいいかなと思い始めている。
と思ったら Dia 0.94 for Windows でなんか不自由なく日本語入力できてるよ！
まだ全部読んでないし、全部読めるかどうかも分からないけど。
たぶん Ruby 界隈では極めて珍しいゲーム業界の人。スラドでも言われていた入門記事に果敢にも挑戦しているのは評価したい。まだあんまり読んでないけど。
Ruby の気持ちよさがどこからくるのかを社会システム理論という大ナタを使いながらも具体的で分かりやすい例とともに考える。個人的には特異メソッドとか分かりにくい言葉は Ruby の弱点のようにも思えるけど、機能としては非常に魅力的だ。しかしその辺の周りからは分かりにくいところにもだえている喜んでいる人が大勢居るように見えるところが Ruby厨のキモさなのかもしれないなーなんてことを思った。
この文章は全体的にはとても分かりやすく書かれている。枕の長さがちょっとアレだけれど、七並べの話だけ読めばずいぶんすっきりと理解できるはずだ。
熱いなー。
しかしこれ
- それぞれの役所の素人がみな見ようみまねでひどいことになっている
可能性は高いだろうけど、案外
- どこも同じ制作会社に発注してひどいことになっている
可能性もあるような気がしてきた。あるいは
- どこのWEB制作会社もセキュリティやプライバシーについて無頓着
ということもあり得る。こっちの方が可能性は高いかな。電子政府の中の人だけでなく、その周りに居る人がみんなダメっていう事態。あー十分にありそう。
セキュリティを分かっている技術者は自分の目にする Web 上ではたくさん居るように見えるが、実は比率的には少数なんじゃないかなぁ。Web ベースのシステムを作ってはいても Web のなんたるかすら分かっていない人なんていくらでもいるもの。Perl や PHP と HTML と JavaScript がコピペできれば Web サイトなんて作れるんだから。