祈祷連歌

「アクセスログ改良」（MT導入と改造）

◇ ◀ ▲ ▶

外部には公開してない(つもりだ)し、robots.txtも設定している(つもりな)のだが、 最近よく検索エンジン経由でwikiやblogにアクセスがある。

Apacheのログだとうじゃらうじゃらとなんだかいろいろ出力されていて解析するのがたいへんだから、「どこから飛んできたのかなるべくすぐわかる」ことに特化したApacheのext_filterを作ってみた。

といってもperlで日時やrefererとか最小限の情報を出力するフィルターで画像とかのアクセスを無視するやつを/wiki/などにつけただけなんだけども。 標準のカスタムログでもできるんだろうが、ちょっと遊んでみたり。

「量の世界と質の世界」（OO百韻）

◇ ◀ ▲ ▶

一口に平均といってもさまざまなものがあるが、 抽象化のレベルを一つ上げて考えてみると その本質は非常にシンプルであり、 また普遍的な構造を持っていることがわかる。

平均というのは一般に次の式で定義される。

これは相加平均とよばれるものだが、 数学の世界ではこれ以外にも、相乗平均、調和平均などと沢山の種類の平均がある。 これらはそれぞれ意味や用途が微妙に違うわけだが、実はその本質は一つの式で表される。

もしくは、

ここで、f(x)にどんな式をもってくるかで、どの平均であるかが決まる。 いくつか代表的な平均を挙げてみよう。

の場合：相加平均

この場合、となるので、平均の式は次のようなよく見慣れたものになる。

実はこの相加平均には他のすべての種類の平均の要となる重要な役割がある。

の場合：相乗平均

なので、次のようになる。

fを展開すると、最初は一見して複雑な感じだが、log同士の足し算はlog内でのかけ算になるので、最終的には非常にシンプルな式となる。日常生活においては、この形の平均はそうとは気づかないだけで非常によく見かけるものである。 音の強さ、光の強さ、痛み、地震の震度など、 感覚的に「一つ目盛りが上がった」と思う場合は その強さを計測すると実際には数十倍であったり桁が上がっていたりする。

の場合：調和平均

なので、次のようになる。

調和平均は割合とか比率などをものさしにするような場合の平均を表している。 例えば、４km先にある倉庫まで歩いていって荷物をとってくるとしよう。 行きは時速４kmで歩いていき、帰りは荷物を担いだために時速１kmで あったとする。この場合、往復の平均速度は調和平均で計算するのが正しい。

の場合：相加平均±標準偏差

なので、次のようになる。

この式ははしょって乱暴な言い方をすれば 「平均からの差の平均」ということになるだろうか。 平均のを基点に考えれば、その値は誤差のことであり、 つまり標準偏差のことである。

ところでfはいったい何をしているのだろうか？

実はfは「質の世界のものを、量の世界に対応させる」役割をもっているのである。質の世界にあるものは、そのままでは平均という演算を施す事ができない。 そこでfによって量の世界に場所を移し、そこで平均を計算し、今度はfの逆演算によって量の世界から質の世界へ逆対応させているのである。

ちょっと話が飛躍するかもしれないが、自然科学とは全般に、 実際に計測された数値に、その意味を説明づける学問であるとも言える。 そういう意味ではその本質は量の世界と質の世界のできごとを 橋渡しする対応付けの部分にあるともいえるのではないだろうか。

「二律背反：ドラフト状態でパブリッシュしたい」（MT導入と改造）

◇ ◀ ▲ ▶

ドラフト状態のエントリーだけをまとめて書き出す方法はないものなのだろうか。

まだ書きかけのエントリーで、日記的でないものはドラフトにしているのだが、 そういうエントリーはリビルドで表に出てこない。 そして、ドラフト状態のエントリーがけっこうたまってきてしまっている。

そういうものはプレビューで見るしかないのだが、半完成品の段階で、ちゃんとしたページとしてみてみたい。

ドラフト状態のエントリーをまとめて一つのカテゴリーアーカイブのようにできるといいのだが。 MTのソースをざっとみた感じだとちょっとよくわからん。

「アクセスログとSSI」（MT導入と改造）

◇ ◀ ▲ ▶

せっかくアクセスログをとるようにしたわけなので、それを解析してみた。 すると、けっこう思わぬところで参照されているのが分かって面白かった。

アクセスがあるのはもっぱら検索エンジンからで、内容はUTF8やメールのエンコーディングがらみ。 みんなここで一度はつまづくということなんだろう。 自分だけじゃないことが分かってちょっと安心。

で、ページにSSIでCGIスクリプトをバーチャルインクルードしておくと、そのページの アクセスログをリストアップするようなものを作ってみた。

ところが、どうもうまくうごかない。 スクリプトの単体テストではうまくいくのだが、実際のページに埋め込んでみると ページが表示されなくなる。どうやらSSIのところで反応がなくなっているらしい。

だが、アクセスログをとっていないフォルダーからだとちゃんと表示される。 とはいっても、アクセスログをとっていないページなんだから、当然リストアップされる内容は空である。

どうやら、SSIとアクセスログのOutputFilterが、同時に働くと途中でとまってしまうらしい。 何故かはわからない。どうしてなんだろうか。 まったく根拠のない想像だが、SSIも出力フィルターも両方ともおそらく それぞれがフィルターとして前段階のものからの出力を待っているわけで、 順番に待つなら問題ないのだが、どういうわけか互いに待ちあうような デッドロックに陥っているのではないだろうか。標準入出力をフラッシュ してあげればいいのだろうか。

これじゃあ役にたたないのでアクセスログのフィルターのスクリプトにアクセスリストの表示もやらせてみることにする。アクセスログのフィルターでSSIに似たことをして、ある種の文字列があった場合にはそこをアクセスログのリストに書き換えるようなものを作ってみた。ついでに、サイト内アクセスランキングも。

ちょっと表示が汚い感じがするが、とりあえずはこれでしばらく様子を見てみよう。

「猫が死んだ」（行動記録／日記）

◇ ◀ ▲ ▶

昨日、実家の母から電話があり、タクという名前の猫が死んだということだった。 享年１３歳。猫にしてはよく生きたと思う。 母は涙ながらに、これでクロの血筋が絶えたと泣いていた。

クロというのは大学時代にアメリカで飼っていた猫で、大学卒業とともに日本に連れ帰った猫だ。 お腹と尻尾の先がちょっとだけ白い黒猫だった。 非常に大きな猫で、あるとき量ったら１３キロあった。 といっても、太っていたわけではなく、見かけはほっそりしていた。 太ってないのに重いというのは、つまりでかいということ。 アメリカから日本に連れ帰るとき、空港で「これは本当に猫か？」と聞かれたほどだった。 ダイニングテーブルに手をかけてテーブルの上が覗けてしまうほどの大きな猫だった。 人間がご飯を食べていると、よくテーブルの上に顔をだして、おねだりしていた。 頭もよく大抵はこちらのいうことを聞き分けていたと思う。 だから、基本的に行儀はよかったと思う。 テーブルの上に顔をだすのは、上にのると怒られるのをよく分かっていたからで、 そのかわり、隙をみてはこちらを出し抜くのもまたうまかった。 ただ、日本の流感に免疫がなかったために、五歳の若さで意外なほど早死にしてしまった。

クロと一緒に、クロの娘のブチ子という、黒と白のまだらの猫も連れ帰ったのだが、 このクロとブチ子の間にできた４回目ぐらいの子供の一匹がタク(写真)だった。 ブチ子はクロの兄妹のミケという猫との間に生まれた猫だったので、タクは血が非常に濃い。 だからか、クロとブチ子の子供はみんなチビばっかりだった。 獣医師である弟の診断によると、タクは心臓に欠陥があるそうで、 タク以外にも４年ほど前に死んだチビクロもまた心臓が悪かった。 近親相姦の弊害なのだろうか。

タクのほんとうの名前はタクトンという。 尻尾がリズミカルに左右に振れるのが印象的で、父が指揮棒のようなのでタクトという名前にすると言い張ったので、４文字にしてタクトンという名前になった。 実は自分でかってに作った命名規則があり、クロは２文字、クロの子供のブチ子は３文字、 だから、ブチ子の子供であるタクは本当は４文字であるのが正しい。 ただ、実家の人間はそんなことは気にせずいつの間にかタクという名前に落ち着いてしまった。

タクは親のクロに似ず、小柄で気が弱いねこだった。 生まれてすぐ母猫のブチ子が死んでしまったので、母が育ての親だ。 人間の赤ちゃん用の哺乳瓶とミルクで育てた。 タクは寝るときも哺乳瓶を放さず、自分の身体より大きい哺乳瓶を抱えて寝ていた。 用意するのはもっぱら母の役目だ。 それもあってか、常に母のそばを離れず、母が買い物に出たりすると、 玄関の前で帰ってくるまで鳴いたりしていた。 また、兄弟猫たちはみんなすぐに外を覚えて、しょっちゅう外に出たがったものだが、タクは外には興味がないようだった。 あるとき庭に抱いてでたところ、恐がってしがみついて大変だった。 今思えば、タクの頭にあるのは母のことだけだったのではないかと思う。

母はクロの血筋が絶えてしまったと言っていたが、 実家の周囲で黒い猫をみかけるとクロの血筋は絶えたわけではないだろうと思っている。

「アクセスログ改良その後」（MT導入と改造）

◇ ◀ ▲ ▶

アクセスログフィルターを改造していくうちに、 「SSI風ページビューログ表示＆アクセスランキング表示割り込ませ機能付きアクセスログフィルター」になってきてしまっている。ちょっと詰め込みすぎかな？

あるとき表示がハングってしまいperl.exeがデッドロック状態でプロセスリストを食いつぶしてしまうようになってしまった。 ページを開くと応答がなくなってしまい、ホストマシンではプロセスに休止中のperlがたまっていくという状況だ。 これはSSIとext_filterを同時使用したときのトラブルに非常によく似ている。 ただし、小さなファイルでは問題なく、大きなHTMLファイルだとそうなるようだ。

で、いろいろとやってみたところ、どうやら原因が分かった。 入出ストリーム間のデッドロックが原因のようだ。 スクリプト自体はperlで書いたのだが、フィルターとして機能している部分の核心は、次のようなコードになっていた。

binmode(STDIN);
binmode(STDOUT);
while (<STDIN>) {
    # $_ を加工
    print $_;
}

binmode()を呼んでいるのは、画像などのバイナリーデータもこの処理を通過するからである。

いろいろと試行錯誤して、 ハングする箇所はSTDINを読み込んでいるところであることが分かった。 入力が止まっているので、出力も止まる。 なぜそこで入力が止まるのかは分からないが、とにかく入力ストリームを読み込んでいる 途中で止まっており、その結果出力も止まってしまっている。

これに対処するため、あまり好みではないが、最初にいっぺんにすべての入力 ストリームを読みだし、それから加工して出力するようにした。

my @lines = <STDIN>;
for my $l (@lines) {
    # $l を加工
    print $l;
}

他にも、gifやjpegなどバイナリーデータの場合と、htmlなどテキストの場合とで 処理を分けるようにもした。

これで今のところは応答がなくなってしまうトラブルはでなくなった。

perlやapacheを最新のものにアップデートするなど、いろいろとやってみたのだが、結局はプログラム上の問題であったようだ。だが、なぜフィルターに入力するデータがもうなくなっているはずなのに、入力がストップするのかは依然として謎だ。

「富士登山」（行動記録／日記）

◇ ◀ ▲ ▶

１９日から２０日にかけて富士山に登った。 今回で富士登山は１６回目になる。 ただ、今回は初めて富士登山する女性を同行するので、５合目からの登山となった。 ５合目からの登山はこれで２回目になる。

朝６時半に家を出て、９時過ぎに富士吉田。

浅間神社でお参りをして、川口湖駅からバスで５合目へ。

５合目の一つ手前のバス停で降り、御庭を歩いて１５時ごろ５合目へ。 今回は富士登山が初めての初心者がいたこともあるので、 ５合目で充分時間をとって体をならし、ゆっくり行くことに、 そうすれば高山病にかかりにくい。

１８時ごろに５合目を出発し、１９時ごろ６合目、２０時ごろに７合目。 時間がちょうどよく７合目では西湖のあたりで花火が。 ２１時ごろ７合目の最後の山室あたりでは山中湖の辺りで花火。

８合目へ向かう途中、風が非常に強く、おかげで気温のわりには寒かった。 風は強かったが、天気は非常によく、２日前が新月であったので、満天の星空がきれいだった。

２４時すぎに本八合目最後の山小屋である、富士山ホテル別館。 ここは休憩で中へ入れる唯一の山室。 そこで長休みをとって、２５時過ぎに出発し、２７時すぎに頂上に。 ５合目の出発が早かったので、山頂到着も少し早かった。

２８時４０分ごろに御来光を拝んだ。 ちょっと雲があったが、基本的には今回は大成功。

１０時に頂上を出発し、富士宮５合目には１４時すぎに到着。

新富士まではバス。 駅からタクシーで１０分ぐらいのところにある「ゆらぎの里」の温泉で汗を流し、 ２０時４１分の新幹線で東京へもどった。

タイムテーブル

時間	場所
06:50	中野駅出発
09:20	富士吉田駅到着
10:00ごろ	浅間神社
11:30ごろ	富士吉田駅から河口湖駅へ
13:10	河口湖出発
14:00ごろ	御庭到着
15:00ごろ	５合目到着
18:00ごろ	５合目出発
19:00ごろ	６合目
20:00ごろ	７合目
21:00ごろ	７合目最後の山室
22:00ごろ	８合目
23:30ごろ	本８合目
24:30ごろ	本８合目最後の山室
25:00ごろ	本８合目出発
27:00すぎ	１０合目到着
28:40ごろ	御来光
10:00ごろ	下山
14:00すぎ	富士宮５合目
15:30	バスで新富士駅へ
17:10	新富士駅
17:30ごろ	ゆらぎの里
19:41	新富士出発
21:00ごろ	東京到着
21:30ごろ	中野到着

「韓国ホスト発のスパムが多すぎ！！」（行動記録／日記）

◇ ◀ ▲ ▶

やけにウザい出会い系の日本語のスパムが多い。 文面からするとやけになれなれしく、基本的に買春を誘う内容だ。 そういったものが一日に何通も来る。

そういう類のところにはネット上でも実生活でも一切出入りしたことがないのに 何処からアドレスを得たのだろうか。スパムの類には返信した事もない。 そう思ってよくみてみると、みんなメールドメインがnifty.com宛である。

自分のアドレスは、ニフティサーブが@niftyになって、 nifty.ne.jpからnifty.comになる以前から 使っているので、nifty.comのアドレスは今までに使った事がない。 が、ニフティのメールアドレスは@nifty.comのものも、 @nifty.ne.jpのものも、ユーザー名の部分がちゃんとしていれば、 どちらでも届いてしまうようだ。 ニフティは昔からアルファベット３文字＋数字５文字というユーザーIDがそのまま メールアドレスになるようになっている。そうでない設定もあるのだが、昔からの成り行きでニフティIDのメールとそうでないメールとで使い分けている。 つまりnifty.comのドメインにメールアドレスのユーザー名の部分はめくら打ちでニフティIDを当てたメールアドレスなんだろう。 普段は気をつけてあけないようにしているのだが、HTMLメールをうっかり開けてしまったときとかに 埋め込まれた画像かなにかで存在確認がとられてしまったのだろうと思う。

最近はスパムが多いので、定期的にメールボックスをスキャンして条件がマッチしたら 問答無用で削除するという自作ツールを使っている。 最近ではスパムの場合だとFromとかは全くアテにならならず、 もっぱらReceivedフィールドを見るようにしているので、 Receivedフィールドのfromのclauseのところに別途設定しておいたドメインやIPレンジの ものがあるとそのメールそのものを削除してしまうのだ。

こういったツールを使っていると、それまでは見過ごしていたことがいろいろ分かるようになる。スパムが多いのはアメリカからだと大学のアドレスだとか、アジア圏からのスパムは韓国や中国からがほとんどだとか。 とくに最近目に付くスパマーには結構いやらしいのがあって、niftyのMXサーバーにアクセスしてきてメールを送っているのに 自分はそのniftyのMXのIPを名のるというとっても不届きなヤツが最近ずいぶん増えてきた。 もっとも、niftyのサーバーはちゃんと送信元のIPも記録してくれるので無意味なのだ。ざまあみろ。

いまでは、ReceivedのfromにマッチするドメインとIPレンジやIPのリストはすでに１５０を越えた。 IPのエントリーもずいぶんあり、同じネットワークIDから来るやつは、いっそのこと IPレンジでまとめて削除するようにしている。 しかし、そういうところからスパムでないメールがくると それも削除されてしまうわけで、いずれ困る事になるかもしれないなぁなどとノンキにかまえている。

で、圧倒的に多いのが韓国からのメールである。多い時は１日に２０通は来ているようだ。 現在IPレンジで考えておそらく韓国ドメインの１０％は刎ねている。 それでいてほぼ２日に一度は韓国発のリジェクトIPを登録するような状況である。 次に多いのが中国から。これは韓国と比べるとまだまだ多くはないが増加傾向にある。

このIPレンジを調べるのがちょっとばかし面倒。 APNICはなぜ国ごとにまとまったIPを割り当てないのだろうか？　 このように日中韓で混在しているのはなにかの陰謀なのだろうか？　 いまのところは、どうせ仕事で韓国や中国からメールがとどくことはないので、 どうせなら国別にまとめておいてくれれば、いっそのこと韓国からのメールは全てリジェクトして 面倒が少なくてすむのだが。

ちょっとネットで検索してみたら、決め手がないしいたちごっこだし、どこも困ってるんだねぇ…、ということが分かっただけだった。 スパムに関してはこの迷惑メール(spam)撲滅私的調査会（高崎作成） なんかに、並々ならぬ熱意が感じられた。 単に無視しているだけではダメだということのようだ。 でもスパマーが使っているISPなどに抗議するにも、国外じゃあ難しそうだし、 しかも韓国や中国が相手だと効果はなさそうだなぁ。 かといって反撃ツールなんかをつかってしまったら、 一転こっちが加害者になってしまうかもだし。難しい。

とりあえずは分かる範囲内でこっちで把握したスパマー(あるいはスパマーの顧客)同士を相互に登録させることで溜飲を下げることにする。

「映画『スパイダーマン２』」（行動記録／日記）

◇ ◀ ▲ ▶

映画『スパイダーマン２』を観て来た。非常に良かった。 １作目の終わりがネガティブなものだっただけに、今回の終わり方は一安心できた。 精神がリセットされ、何だか元気をもらえたような感じ。

今回も、ただSFXを見せるだけのアメリカ映画にありがちな作品というわけではなく、 主人公をはじめとする登場人物たちの苦悩などもしっかりと表現されており、 ちゃんとしたドラマになっている。

映画を観た後ノベライズを読んだが、 ところどころ映画のほうではしょられているようなところなどがあり、 どちらかというと原作本っぽいプロットなので、 映画を観る直前に読む、もしくは映画の後に読んだならもう一度映画を観たほうがいいだろう。 そのほうが映画を楽しめると思う。

「Wiki改良」（MT導入と改造）

◇ ◀ ▲ ▶

前々から考えていただけで手をつけていなかったWikiの改良をした。 改良したのは、日本語ウィキ名、見出しのName属性、中心揃えブロックの三つ。

日本語ウィキ名

と でアルファベットと英数以外の日本語の 文字列を囲むと日本語ウィキ名になる拡張はすでに施していたが、 今回それに加えてこの書式で日本語ウィキ名を指定すると、以後のテキスト中で 出現する文字列を と で囲まなくても日本語ウィキ名として扱うようにした。 このエントリー中最初に出現する日本語ウィキ名のみが と で囲まれているが、 ２回目以降は特に指定せずともリンクが設定されている。

初回の日本語ウィキ名の指定だけ と が残ってしまっている。 プレビューだとちゃんと出るのに、なぜだろう？

と思ってよく実行時ログダンプを見直してみたら、format_text_to_htmlが リビルド時には一つのエントリーに対して何回も呼ばれてるじゃないか。 ２回目の実行時には前回の登録が生きていてそれで と が２回目以降の 分として残ってしまっていたわけだ。

見出しにName属性を指定できる

行頭が*で始まると見出しになるが、見出し中に#があるとそれ以降は<A>タグの NAME属性になる。これにより文書中の任意の見出しのところへ外部からリンクが設定 出来るようになる。

中心揃えブロック

引用と同じような指定のしかたで、><や>><<の行で始まり、<>や<<>>の行で終わる 部分は中心揃えのブロックになる。><と<>の組み合わせでソフトブロックになり ブロック中ではインライン要素による書式指定が有効になる。>><<と<<>>の組み合わせは ハードブロックになり、ブロック中では書式指定は効かなくなる。