7 件 見つかりました。
文房具について書いた記事 [2006-06-15-1]に「ぺんてる社員」な方からコメントが!!!! K105 も K104 も現役だそうです．これで安心．ありがとうございました．
「画像で取得するAPI」ではてなブックマーク件数をお手軽に表示してみた矢先なのだが [2006-07-15-3]，やっぱりやめた．
はてなが重いときとか反応しないときに，自分のページの表示が影響を受けるのが嫌だってのがまずあるけど，そのときに，あー，俺いまはてなサーバに無駄に負担かけてるーという罪悪感があって精神衛生上よろしくない． (いや，もちろんトラフィック全体からみると，うちから発生する分なんて誤差に過ぎないわけですが，単に気持ちの問題なので)
つうわけで真面目にはてなブックマーク件数取得APIを叩いてみることにしたですよ．
やり方はいろいろあると思いますが，定期的に件数を取りに行っておいて， HTML から SSI で include することにしてみた．こんなのを cron で定期的に走らせます:
#!/usr/bin/perl
use strict;
use XMLRPC::Lite;
my $html_clog_url = 'http://www.kagami.org/diary'; # don't add trailing slash
my $html_clog_dir = '/home/swk/www/diary';
my $hatebu_count_dir = '/home/swk/www/hatebu_count';
my $EndPoint = 'http://b.hatena.ne.jp/xmlrpc';
my @urls = ();
while (<$html_clog_dir/*.html>) {
next unless /\/(\d{4}-\d{2}-\d{2}-\d+)\.html$/;
my $ymdi = $1;
push(@urls, "$html_clog_url/$ymdi.html");
if (@urls == 50) {
&writecount(\@urls);
@urls = ();
sleep(3);
}
}
if (@urls > 0) {
&writecount(\@urls);
@urls = ();
}
sub writecount
{
my ($uref) = @_;
my $map = XMLRPC::Lite->proxy($EndPoint)
->call('bookmark.getCount', @{$uref})->result;
foreach (@{$uref}) {
my $url = $_;
my $count = $map->{$_};
my ($ymdi) = ($url =~ /\/(\d{4}-\d{2}-\d{2}-\d+)\.html$/);
if ($count > 0) {
my $str_count = $count . " user" . (($count > 1)? 's': '');
my $str = << "HTML";
<span class="hatebu_count">
<a href="http://b.hatena.ne.jp/entry/$html_clog_url/$ymdi.html">
$str_count</a></span>
HTML
;
&save_file("$hatebu_count_dir/$ymdi.htmlin", \$str);
} elsif (-e "$hatebu_count_dir/$ymdi.htmlin") {
unlink("$hatebu_count_dir/$ymdi.htmlin");
}
}
}
sub save_file { # from kuttukibbs-1.0rc3
my ($fn, $strp) = @_;
open(F, "> $fn") or die "can't open $fn : $!\n";
flock(F, 2);
print F $$strp;
close F;
}
chalow のテンプレートは，
... <h3 class="subtitle"><TMPL_VAR name=header> <TMPL_VAR name=cat> <!--#include virtual="../hatebu_count/<TMPL_VAR name=ymdi>.htmlin" --> </h3> ...
な感じにする．
結論から言うと，敗北です．
kuttukibbs に，できるだけ簡単な修正を加えるだけでどこまでコメントスパムをブロックできるか試してみた．
巷でよく行われているのは，「2 byte 文字がいっさい含まれていないものは無条件で弾く」というもの．日本語サイトの場合，ほぼこれで問題無いわけなのだけど，なんていうか，ほら，技術的に 負け って感じがするじゃないですか(ぉ．というわけでもう少しギリギリの所で戦えないかと試してみたかったわけですよ．
戦略は以下の通り:
やってみるといずれもそれなりに有効で，そこそこ引っかかってくれる．最初の hidden なタグを埋め込んどく程度の低レベルなやつでも，全く無力というわけではないみたい．
だけど，ある特定の記事 (具体的には [2006-03-07-2] なのだが) については，これらをすり抜けて来る奴ら続出．強力なのにマトかけられちゃったっぽい．というわけで「この記事限定」で「2 byte 文字が含まれておらず，かつ URL らしき文字列で終わっているもの」はすべて弾くことにした．
一応これでいまのところ完全封殺．なのだけど，勝ち負けで言ったら敗北ですな．
Movable Type とかだと，いったん必ず Preview ページを表示して，そこで hidden なパラメータを配るなんて方法がよく使われているらしい．でもこれも対策が取られるのは時間の問題かなという気もする．
結論:
今まで使ってたメイルネットのサーバでは perl 5.005_03 (i386-freebsd) が使われていた．モジュール群はあまり揃っていなかったので，必要なものは ~/lib/perl に自分でインストールして使っていた．
さくらインターネットでは，/usr/bin/perl は v5.8.4 (i386-freebsd-64int)．モジュールもそこそこ揃っている．これなら自前でモジュールをインストールする必要はないかなと思っていたけど，甘かった．
Storable に互換性がない．
tb.cgi では，トラックバックのデータの保存に Storable が使われている．そのデータが読めなくなってしまった．Storable::retrieve が「Byte order is not compatible」とおっしゃっている．うーむ．
幸い，さくらインターネットのサーバには perl 5.005_03 built for i386-freebsd も /usr/bin/perl5 としてインストールされているので，こっちを使うことにした．こっちのバージョンではモジュールがあまり揃っていないらしい．というわけでメイルネットのサーバで使っていた ~/lib/perl 以下をごっそりコピーして使うことにする．再コンパイルとかせずにそのままで動くのはありがたい．
他の CGI (clsearch, kuttukibbs, noascii) は perl v5.8.4 で問題なく動くようなのでそちらで動かす．ただし use lib で ~/lib/perl を指定しているとモジュールの互換性の問題で動かないので，指定を止める．
とりあえずはこれでいいけど，いつまでもこのままってわけにもいかないかな．過去データをまとめて新しいファイル構造に変換して，v5.8.4 に移行するようにした方がいいかも知れない．調べてみると，Data::Dump を使って一旦テキストとして吐き出させるという方法があるらしい．そのうち試してみるか．
おまけ．というかちょっとだけはまった落とし穴．
さくらインターネットのサーバには，以下の 2 種類の perl がインストールされている．
そして以下のような symlink がある．
/usr/local/bin/perl5 は 5.005_03 を指しているのが自然だよなあ．どうしてこんなことになっているんだか．
くっつき BBS を SSI (server-side include) 化してみた．ってもしかして既に「くっつき」と呼べなくなってますか? 作者さんに怒られそうだ…．一応このような改造をしようと考えた理由を議論しておこう．
一言でいうとページ表示の速度改善が目的．もちろんメリット・デメリットがあって，このサイトにとってはメリットの方が大きいと判断したというだけ．
まずメリット: くっつき BBS が採用する CSI (client-side include) だと， include ごとに js ファイルを取ってくるための HTTP request/response が発生する．大抵は日ごと，あるいは記事ごとに include する使い方なので結構な数になる．ブラウザがそれらを受け取ってレンダリングを完了するまでユーザは待たされる．レスポンスの悪いサーバだとこれがかなりいらつく．SSI 化すればこの点が改善される．(というわけなので，インライン画像などをいっぱい貼っているサイトだと，いずれにせよ HTTP トラフィックが多数発生するので，改善率は低いと思う) あとは当り前だけど， JavaScript が使えないクライアントでも大丈夫．
逆にデメリット: サーバに HTML ファイルを parse するための負荷をかけてしまう．HTTP のハンドリングよりこっちの方が遅い状況だと，上記メリットが完全にスポイルされる．でも普通に考えて，かたや system call をばりばり呼び出すネットワーク処理，かたやユーザ空間で閉じた単純な文字列マッチング，後者の方が重いという状況は限られていると思う．よっぽどでかいファイルで，かつ含まれている include の数が少なかったりするとこれが起きるかな． あとはこっちも当り前な点として，そもそも SSI が使えるサーバじゃないと使えない．
というわけでケースバイケースなんだけど，うちの場合は明らかに SSI の方が向いている．ちゃんと測定してないけど体感速度で 1 桁は違う感じ．結果として，javascript feed は一切なくなりました．今後どうなるかわからないけど．
変更点としては，kuttukibbs.cgi の中で js ファイルを書き出すところで生 HTML も別ファイルに書き出すようにしておいて，呼び出したいところで <!--#include virtual="..."--> するだけ．注意点としては
<!--#config errmsg="" -->
を入れておくってのがミソ．これがないと include するものがないときにエラーメッセージが表示されてうっとうしい．
くっつき BBS を導入してコメント記入欄を作ってみた．
このサイトのコンテンツは，自宅の PC からレンタルサーバにアップロードされていて，ログデータはその中のサブディレクトリに置かれる．このサブディレクトリはアップロードで上書きしちゃダメなので特別扱いする必要がある．むしろ，このサブディレクトリはダウンロードして，手元にバックアップを取っておきたい．
ところが sitecopy はどうもこれには向いていないっぽい． ~/.sitecopyrc でディレクトリまるごと ignore に指定してみたのだが，うまく動いてくれない．
sitecopy の man には ``Ignored files will be created, moved and deleted as normal'' って書かれていて，要するに ignore は単に内容の変更が無視されるだけなのかな．ファイルがどんどん増えて行くケースは想定外っぽい．本家のメーリングリスト眺めると，似たような質問は出てるんだけど無視されてるし．
結局以下のようにした，まず自宅 PC 側でログデータをバックアップするディレクトリは，公開ディレクトリツリーの外に置くことにした．これは ftpmirror でサーバから自宅側へ sync する．
一方，公開ディレクトリツリーの中のログデータ置場は，自宅 PC 側では初期状態(管理用ログファイルだけがある)のままで触らないようにしておく．このままでは管理用ログファイルが上書きされるので，~/.sitecopyrc でこのファイルを ignore 指定しておく．sitecopy は，サーバ側で生成される新しいファイルの存在は関知しないので，これでとりあえず問題ない．
というわけですごく面倒くさかった．やはり ssh + rsync が使えるサーバに移るのが正しいのかな．
皆さん普通はどうやってるんでしょうか? てことで早速コメントキボンヌ↓．
ChangeLog INDEX