nDiki : WWWOFFLE

■ Web広告に興味を持つ

私はあまりWeb 広告のある Web ページは好きではない。 理由は、

• 不必要な帯域を使う。
• ページ閲覧が遅くなる。
• 広告画像の分だけ表示領域が狭くなり、コンテンツを見るのにスクロールが必要になりがち。
• 本来見たいコンテンツが見にくくなる。
• キャッシュの容量を食う
• ほとんどの広告がうるさい(アニメーション)
• バナーのデザインが派手でページにマッチしない

等。まぁ嫌いだという人は、同じような理由が多いのではないだろうか。

「広告があるけれどコンテンツが見たくて何度も定期的にアクセスするページ」は、proxy で広告をロードしないようにしている(WWWOFFLE の DontGet 機能)。 まぁ、そういうページはタイトル画像やアクセスカウンタも DontGet してしまうのだが。

ということで、もちろん拙作のページにも広告は掲載してこなかった。 といってもいままで大学のサーバで公開していたので、それ以前の問題としてもともとマズいし。

また、各 Web サイトのアイコンを使ったリンクというのも、重いのであまり好きじゃない。 リンク先のイメージが沸くかというと、そうでもないし。 アニメ絵系のは、それ系かなとは思うけど。

で、なぜ今回興味を持ったかというと「今ホスティングサービスを受けている会社(ソリッドネットワークス株式会社※)の現状はどうかな」、と全文検索していたらその会社の広告を出している人を発見。

hosted by ……. なんてページのどっかに書いてもいいかなと前から思っていたんだけど、まぁその部分を広告経由のリンクにしてもいいかなと。

もちろん、広告収入でサーバ代の一部でも pay できたら嬉しいというのもある。

ということでその広告を斡旋しているらしい ValueCommerce に登録してみた。 3営業日以内に審査の結果連絡とのこと。

ついでにメジャーどころの、valueclick の方も登録してみた。 こちらは10営業日以内の審査とのこと。

今後どうなるか楽しみ。 審査自体通らなかったりして。

もし、サイトの品を落とさないようにできそうな、広告配信サービスがあったら実験的に掲載してみようかな。

• 株式会社NEXON JAPAN、旧ソリッドネットワークス株式会社

@ 追記

※現在は社名変更し株式会社NEXON JAPAN。 ソリッドネットワークスホスティングサービスへのリンクを追加。(2001年8月5日)。

■ 21:10 安部 竜治さんに捕捉されているのを発見

mknmz-wwwoffle をご存じでいらっしゃる。 mknmz-wwwoffle、はやく WWWOFFLE の圧縮機能に対応しなきゃなぁ。

■ [ mknmz-wwwoffle ] ギリシャから「win32 で動かないよ」

ちょうど、新婚旅行に行ってきたギリシャドメインの人から、mknmz-wwwoffle が win32 でうまく動かないよというメールを頂く。 Namazu はギリシャでも使わてれいるんですねぇ。

mknmz-wwwoffle の win32 対応は TODO のまま。 path の処理等をサボっているのでそのままでは動かないはず(試してみてもいないので不明)。 せっかくの機会なので win32 対応するかな。

Win32 に Namazu と WWWOFFLE (と要求ライブラリとかPerlとか)をセットアップするのがちょっと面倒かな。

■ Apache Proxy で アンテナの ?%MM%%DD%%HH%%TT% 除去

アンテナページの多くはリンクURLに更新日時を付加する。 例えば

 http://www.naney.org/personal/diary/hns/

が、10月02日 14:46 に最終更新されているとう情報を取得すると

 http://www.naney.org/personal/diary/hns/?10021446

という、URL を持つリンクをアンテナページに生成する。 ページが更新されるとURLも変化するので、(Mozilla, Internet Explorer 等の)以前にアクセスした事のあるリンクの色を変えるブラウザでは、更新されたことを確認しやすい。

が、これはキャッシュ proxy には仇になる。 更新されるたびにURLが変化するということは、そのURLごとにキャッシュが作られるということだ。 私の愛用の WWWOFFLE もご多分にもれずそうである。 私は3ヶ月間キャッシュを保持するようにしているから、一日に3度更新されるページをアンテナのリンク経由で見ると、約90のコピーがキャッシュされる事になる。 そして、最新以外のキャッシュは(通常)2度と利用されることもない。 もはや、その URL ではアクセスされないから。

これはもったいない。 ようは、アンテナ経由でのアクセスの ? 以下を削除してキャッシュすればいいのだが、WWWOFFLE にはあいにくそのような機能はない。 そこで、URL を書きかえる proxy をブラウザと WWWOFFLE の間にカマせようということになる。

 Mozilla -> rewrite proxy -> WWWOFFLE -> target site

ここでは、Apache を rewrite proxy にすることにしてみた。 Apache は mod_proxy で proxy になるし、mod_rewrite で URL を柔軟に変更できる。 もともと、自分の Web サイトのチェック用にローカルマシンで Apache も常時起動しているので設定を変更するだけだ。

とりあえず、大抵のアンテナは ?と8桁の数字(「なつみかん」でいうところの?%MM%%DD%%HH%%TT%)を付加するので、これをもぎとればよい。 以下、httpd.conf の修正。

 LoadModule proxy_module /usr/lib/apache/1.3/libproxy.so
 LoadModule rewrite_module /usr/lib/apache/1.3/mod_rewrite.so

とモジュールをそれぞれ有効にする。rewrite_module より proxy_module を先に Load するようにする(デフォルトでは逆順なので注意)。

そして、httpd.conf の最後に

 ProxyRequests On
 ProxyRemote * http://127.0.0.1:8080/
 NoCache *
 <IfModule mod_rewrite.c>
 RewriteEngine on
 #RewriteLog /tmp/rewrite_log
 #RewriteLogLevel 9
 RewriteRule ^proxy:(.*)\?[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]$ $1? [L]
 </IfModule>

を追加。ProxyRemote で、WWWOFFLE の proxy を指定。 RewriteLog, RewriteLogLevel はうまく書き替らない時に有効にしてログを確認するのに使う。 最後の RewriteRule で実際に書き替えを行う。 ポイントは $1? と、置換後の文字列指定で最後に ? をつけること。 これをつけないと query-string が削除されない(これに気がつくのに随分かかった)。

後はブラウザ側の http プロキシ先を 127.0.0.1:80 にすれば OK。

無条件に ?と8桁数字が末尾にくれば、取り除いてしまうので荒っぽい RewriteRule だ。 だが上記のような query string を使っているページは(多分)そうないから、とりあえず、これで良しとしよう。 困ったら直せばいい。

@ 追加リンク

• いやな日記:URL末尾の ?01234567 のような文字列を除去する
  • (2004年3月16日追加)

■ 25:45 Apache Proxy で アンテナの ?%MM%%DD%%HH%%TT% 除去

最近、アンテナを活用するようになった。 が、アンテナの多くは URL の末尾に更新時間情報(?10021446 等)をつけるため、本来同じ URL のページが違う URL で、どんどんキャッシュ proxy (WWWOFFLE)にたまってしまう。

そこでブラウザと WWWOFFLE の間に aAache proxy を挟んで ?10021446 等を取り除いてしまうことにした。 RewriteRule の substitution の最後に ? をつけないと query string が除去できない事に気がつかなくて随分はまった。

とりあえず、うまくいったみたいなのでコンピュータ日誌の10月2日のところに、設定をまとめておく。

■ [ Java ] 22:30 Cocoon2 はどうかな?

最近、本サイトの生成フレームワークを一新すべく模索中(現在は XML + 自作 Perl スクリプト)。 今の最有力候補は XML + Ant + Xalan。 他にいろいろ見ていたら、Cocoon 2 はどうかなと。 XML から XSLT 他を用いて HTML とか WML とかを生成する server application なんだけど、ローカルで立ちあげて Wget とかでローカルに静的なファイルとして落とせば、それをサーバに置けるんじゃないかなぁ。 すぐ思いつく問題は、

• 「make 的(必要なファイルのみの)更新」(毎回すべて更新されるとサーバへのアップロードで困る)、
• 「SSI がちょい面倒?」(Coccoon 2 では処理しないでそのまま出力させる)、

「コンテントネゴシエーションまわり」(en, と ja を別々のファイル名できちんととりだせるか)

等々。ドキュメントだけ静的にアーカイブしたものとかあるから、静的なファイルに落とせるんだろうなとは思いつつ。 とりあえず、インストール。 まず先に Tomcat

 cd /usr/local
 tar zxvf jakarta-tomcat-4.0.1.tar.gz

次 Cocoon 2

 cd /usr/local
 tar zxvf cocoon-2.0-bin.tar.gz
 cp /usr/local/cocoon-2.0/cocoon.war /usr/local/jakarta-tomcat-4.0.1/webapps/

Tomcat がデフォルトで 8080 ポートをつかうのだが WWWOFFLE が既に使っている。 Tomcat の方をずらすより、WWWOFFLE の変更の方が勝手がわかるのでそちらをずらす。 で

 /usr/local/jakarta-tomcat-4.0.1/bin/startup.sh

で起動。http://localhost:8080/cocoon/ に Galeon でアクセス。 一発目は非常に遅い。他のページも一度目は閲覧は遅いがキャッシュが効くので次からはそれほどでもない。

とりあえず、ドキュメントを読んでいろいろ調査。

■ 12:30 「日記文中の他ページリンクへどの程度ジャンプするか?」by やまぐう

私は、とりあえずおもしろそうな記事中のリンクを、(Galeon なので)がんがん別タブで開く。 日記記事を読んでから、リンク先のタブを順番にチェック。

オフラインの時もガンガン、別タブで開いて WWWOFFLE のリクエストにため。 次のオンライン時にまとめて fetch (このパターンの場合は結局後で見ないものもあるけど)。

@ 追記

URL を http://www.konlab.j.dendai.ac.jp/... から http://www.lomelette.org/~yamagu/... に修正 (2002年12月25日)

■ 22:00 User-Agent=DoCoMo/Galeon

WWWOFFLE の CensorHeader Section で、

 <http://mobile.yahoo.co.jp/*> User-Agent = DoCoMo/Galeon

とかしてみる。

■ 去年の今ごろ

2001年12月16日より。

• インデックス作成でメモリを食い潰す
  • 自宅でADSLを契約してから、WWWOFFLE ともおさらばしていた。しかし最近、仕事でネットワークにつながらない場所*1に行く機会がちょっと増えたため、ほと WWWOFFLE が懐しく感じたり。

■ 久しぶりに WWWOFFLE

ノート PC に久しぶりにインストール。 正月は常時接続ではなくなる(場合によってはダイヤルアップも不可に)ので、今のうちに必要なものはできるだけキャッシュしておくように。

■ 例によってPHS接続用に WWWOFFLE を設定

夏休みでしばらく数日(常時接続ではない) PHS 接続生活になるので、例によって WWWOFFLE をインストール。しばらくは WWWOFFLE + Privoxy の2重 proxy 生活。

今回はDNS キャッシュサーバとして pdnsd も入れておく。

あわせて resolvconf パッケージもインストールして、ifup / ifdown の実行などで問い合わせにいく DNS サーバが変わっても pdnsd が追従するように設定(というか pdnsd のデフォルトの pdnsd.conf がそのようになっている)。

これで /etc/resolv.conf はいつも

 nameserver 127.0.0.1

にしておけるので 実際に問い合わせにいく DNS サーバが変わっても WWWOFFLE の再起動が必要なくなる。

[ Debian ]

■ Linux で使えるデスクトップ検索ツール Beagle でローカルファイルを検索

Windows だと Google Desktop でローカルファイルの検索ができるのだが、残念ながら Linux 版はでていない。 そこで Beagle を入れてみることにした。

Beagle はデーモン形式のバックエンドと、検索インタフェースであるフロンエンドに分かれたているデスクトップ検索ツールである。

ファイルシステム上にあるテキストファイルだけでなくメールや、Firefox でアクセスしたページ、OpenOffice.org や Microsoft Office のファイルなどをインデックス化し検索できるようにすることができるらしい。

@ ちなみに今まで

ローカルファイルの検索は

といった感じかな。

それ以外はだいたいファイルの位置をうろ覚えしているので、何カ所か探せば見つかることが多い。

問題はうろ覚えの場所になかった時。 その時はなかなか見つからない。

そんなファイルを見つけるのが楽になれば、導入効果あり。

@ インストールして試してみる

@ Linux kernel の inotify を有効にする

まずは Linux kernel の設定を確認。inotify が有効になっている方が良いらしい。 この間ビルドした時の .config を見て

 CONFIG_INOTIFY=y
 CONFIG_EXT2_FS_XATTR=y
 CONFIG_EXT3_FS_XATTR=y

となっていることを確認。

@ /home の extended attributes を有効にする。

/etc/fstab を編集し、

 /dev/hda4 /home ext3 defaults 0 2

を

 /dev/hda4 /home ext3 defaults,user_xattr 0 2

に変更する。書き換えたら、

 mount -o remount /home

でマウントしなおす。

@ Beagle のインストール

Debian パッケージでインストール

@ Beagle を起動

一般ユーザで

 beagled

で起動する。停止は

 beagle-shutdown

で。

@ Beagle を設定

 beagle-settings

で設定 UI を起動し、インデックスに含めたくないディレクトリなどを設定。

@ 検索してみる

 beagle-search

で検索 UI を起動し検索してみる。 日本語も OK のようである。

GNOME 環境をほとんどインストールしていなかったので、検索結果からファイルを開けずつまらなかたので gonome-control-center、gnome-panel あたりをインストールして環境設定等をしてみた。

KDE 系のクライアントもあるので別途いろいろ確認。

@ Firefox 拡張

xpi ファイルを入れておく。 後は普通に閲覧したページが、Beagle でインデックス化されて検索できるようになる。

設定してしまえば、以前開発して使っていた WWWOFFLE + Namazu よりお手軽である。

@ 感想

デーモンが逐次インデックス化していくので、明示的定期的にインデクサを走らせなくていいというのは楽でいい。

日本語関連がどの程度うまく検索できるのか、検索結果は使いやすい順に出力されるのかが未知数。 しばらく遊んでみて便利かどうか確かめてみたい。