2002年11月29日
# PCで音楽
CDプレイヤーが壊れているのでパソコンでCDを聴いているのだけど、意外とイイ感じ。
ディスプレイかコンポどちらを買うか迷っていたけど、コンポは買わずに、音楽はPCで聴くようにしようかなぁ。
# 新種チェス風ゲームArimaa
元NASA職員のコンピューター・エンジニアが20日(米国時間)、チェスのルールを大幅に変更し、人間がコンピューターに勝ちやすくしたゲーム『アリマア』(Arimaa)を考案したと発表した。
http://www.hotwired.co.jp/news/news/20021125205.html
最初のコマの配置の組み合わせや、対局中に打てる手が多いので総当たりで読むのは困難なのだそう。でもルールはシンプル。
オフィシャルサイトではすでに対局もできるようになっていて、FlashやJavaScriptでのデモも用意されている。
2002年11月28日
# コタツムリ
最近、眼によくないと思いつつも、ついついコタツの中に寝ころがって読書してしまう。そして、夜はもちろんフトンミノムシに完全変態。
# QuickML
あまりにも便利なメーリングリストなので、いろんな人に薦めてしまった。
それにしても、こんなに便利なメーリングリストがあると自分で作る意味が薄くなってしまったなぁ。
2002年11月25日
# メーリングリスト
高林哲さんのQuickMLというメーリングリストシステム。とくに面白いと感じたのは、
1、管理者という概念がなく、MLの管理が自動的に行われる
2、エージェント・プログラムで機能拡張
というところ。1は管理者がいなくても運用ができるので、MLに対する敷居がぐっと低くなりそう。2はエージェントという、メールを受信することにより起動するプログラムを利用してログ保存機能などのシステムの拡張ができる仕組み。この仕組みはいろいろ応用できそう。
2002年11月24日
# メーリングリスト
いろいろ調べ中。今までに分かったことは、
- メールのヘッダーにマルチバイト文字が含まれる場合はMIMEエンコードする必要がある（ただしSubjectはJISでもOK）
- .（ドット）だけの行は..（ドット2つ）に置き換える。.1つの行はメールの終端を意味するので。
あと、メールが2つのサーバー間で無限に届け続けられるループに陥らないように注意しないと。
_ つけたし
.（ドット）で始まる行はすべて..（ドット2つ）で始まるように変換する必要があるみたい。
# ソースはテキストかHTMLか
21日の続き。
HTMLファイルとテキストファイル（.txtの拡張子でサーバーのレスポンスヘッダのContent-typeがtext/plainのもの）として置く場合では、訪問者の便利の他にも微妙な違いがあると思う。HTMLファイルとしておいた場合の特徴は、
1、検索エンジンにページの語句が拾われることが期待できる
2、多くのブラウザで期待通りの表示がされることが期待できる
3、そのページから他のページへハイパーリンクを張ることができる
4、ページを装飾できる（色分け表示など）
5、ソースリストをダウンロードしにくい（ページ中からコピー＆ペーストする必要がある）
テキストファイルとして置いた場合はHTMLの逆。
この中で、3はGoogleなどの検索エンジンがページの重要度を決めるときの要素の1つである被リンク数を増やすことができる。けど、1と3は動機が少し姑息な気もする。
# 最近のGoogle
あんまりGoogleのことばかり書くのも控えたいけれど。
最近はGoogleは一定以上のPageRankのページはかなり頻繁（毎日くらい）にキャッシュの更新をし、それ以下のページは数ヶ月経っても検索結果に反映さえされない様子。PageRank 4くらいが基準になってそう。
ということは、Googleの利用率が他を圧倒している現状では、情報を発信する側としてはPageRank 4以上のページに情報を載せないとなかなか見てもらえないことになる（リンク経由での場合は別）。これはPageRankによってちょっと差を付けすぎのような気がするんだけど、どうなんだろう。PageRankが下がるにつれてページ数は指数関数的に増えていくので、すべてを同じように扱うのは難しいとは思うけれど。
最近は、インターネットの情報検索で1つの検索エンジンだけに依存しすぎるのはちょっと危険な気がしてる。他の検索エンジンにも期待したいところ。
2002年11月22日
# メーリングリスト
借りているサーバーは共有型なので、サーバー内ではuttsuは1つのユーザーアカウントであるわけだから、そのサーバーのドメイン名でのメールアドレスも使えるのでは、と思って試してみたところちゃんと使えた。
サーバーの自分のアカウント宛てにメールが送れるということは、メールの受信によってプログラムを実行することもできるので、これで長い間作りたかったメーリングリストのプログラムが作れそう。
メーリングリストの機能はサーバーにも用意されているのだけど、自分でプログラムを作るとCGIなどを通した管理機能などもつけられるので柔軟性が高いし。
作るのが楽しみ。
2002年11月21日
# POPメール
以前（といっても数ヶ月も前のこと）試したときはuttsu.comのサーバーでは追加したPOPメールアカウントでメールの送信を行うことができなかったのだけど、さっき試してみると送れるようになっていた。ここ数ヶ月の間にSMTPサーバーも使えるようになったのだろうか。
SMTPサーバーが正式なサービスなのかちょっと不安だけど、便利なのでいくつかアカウントを作ってみた。
# Perlでウェブページ取得
昨日の「PerlでSocket」について。
Perlでは簡単に他のサーバーのホームページの内容を取得できるので、面白い使い方ができそうです。
socket.plの使い方は「socket.pl URL」で、たとえば、
socket.pl http://uttsu.com/
とすればuttsu.comのトップページの内容が取得できます。後はテキスト処理をすれば色々できます。
こういうことができることは知っていましたが、実際にやってみてその簡単さと可能性にちょっと感動してしまいました。ぜひお試しあれ。
# ソースはテキストかHTMLか
ウェブで公開するプログラム言語のソースファイルは、たとえばファイル名に.txtを付けるなどしてテキストファイルのまま置いておいた方が便利なのかなぁ。どうなんだろう。
2002年11月20日
# メールでコマンドを実行
大学のメールアカウントにメールを送ると、fingerの実行結果を返信してくれるようにしてみた。あまり意味ないけど…。
メールを送ってコマンドを実行するには、ホームディレクトリの.forwardファイルに
"|/my/home/directory/hoge.pl"
のように記述すればOK。引数を渡す場合は
"|/…/hoge.pl arg1 arg2"
のようにするとのこと。メールの内容（ヘッダーと本文）の取得は標準入力から。
# Perl2HTML
Perl言語のソースファイルをHTMLファイルに変換するスクリプトです。これ自身によってHTML化したソースは以下です。
# PerlでSendmailとSocket
昨日書いたスクリプト。テスト用のスクリプトですが、よかったらどうぞ。Sendmailでメールを送るものと、Socketによって接続して、任意のURLの内容をGETするものです。
# PerlでPOST
HTTPでアクセスできないサーバーにあるデータを取得するために、いったんHTTPでアクセスできるサーバーにデータを送信するためのテストスクリプトです。send.plとreceive.plの2つを使います。
2002年11月19日
# Web Scheduler
設定しておいた時刻にメールを送ってくれるスケジューラーを作ろうといろいろ調べ中。
cronとsendmailを使うとできそう。CGIと組み合わせて、ブラウザ上から設定できるようにしておくと便利そう。
# PerlでSocket接続
異なるサーバーにあるファイルを処理したい場合はSocketを使って接続する必要があるので、これも調べ中。面白い使い方ができそうな気がする。
それにしても、異なるサーバーからデータを取得するくらいなら簡単にできるんだなぁ。
2002年11月18日
# 検索してほしい情報はトップページに？
昨日、日記をトップページにも表示するようにしたわけだけど、今さっきGoogleで検索してみるとトップページの内容がすでにキャッシュに入っている模様。これまでもGoogleではトップページの情報は結構頻繁に収集されるけど各コンテンツのページはめったに収集されないみたいだったし。
とはいっても、Googleのキャッシュの内容は結構不安定で、いったん新しくキャッシュされたかと思ってもしばらくするとまた古いキャッシュ内容に戻ったりする。おそらくデータベース管理のアルゴリズムや、サーバーの切り替えを行っているためではないかと。
トップページの内容だけがよく反映されるのは、PageRankが他のページより高いためでしょう。PageRankなどによって巡回頻度を調節しているのかと。更新頻度がクローラーの巡回頻度に影響しているかは分からないけど。
それにしても、書いた情報がすぐに検索されるようになるというのはかなり強力な気がする。いろんな意味で。
_ つけたし
今回はたまたまキャッシュの更新日と重なっただけという可能性も。
# 携帯版日記のURL構造
昨日設置した携帯版日記のURL構造について。
携帯端末（主に携帯電話が対象）では、一度に受信できるデータ量に制限があったりするので、URL構造も工夫が必要になってくる。
携帯版日記では、最初は日毎にURLを作るのではなく、各セクションごとに作ろうかと考えたけれど、いままでで1日に書いた量を見返してみると1日ごとのURLでも大丈夫そうだったのでそうすることにした。その方がファイルとも1対1で対応していてシンプルだし。また、1月ごとのURL（yyyymm.html）では各日へのインデックスを表示することに。そしてディレクトリ名だけ（diary/）の場合は各月へのインデックスを表示するようにした。
URL 内容
diary/ 各月へのインデックス
yyyymm.html 各日へのインデックス
yyyymmdd.html その日の日記（全文）
月数が多くなってきたら、各年のURL（yyyy.html）を作ってその年の各月へのインデックス用にすればよさそう。
こういうふうにしたけれど、ディレクトリ名だけのURL（diary/）を各月（各年）へのインデックスとして使っているので、最新の日記へのリンクは別のページに用意することに。これはいまのところは携帯版のトップページからSSIで呼び出して行っているけれど、ディレクトリ名だけのURLに最新の日記へのリンクを付けるのがURLの構造的には理想的かも。
理想的版
URL 内容
diary/ 各年へのインデックス＆最新の日記へのリンク
yyyy.html 各月へのインデックス
yyyymm.html 各日へのインデックス
yyyymmdd.html その日の日記
というふうに。また、
理想的版その2
URL
diary/
yyyy/
mm/
dd.html
のようなのもいいかもしれない。
PC用のページだったら1ページのデータ量をそれほど気にしなくていいので、yyyymmdd以外は省略もできるのだけどね。
2002年11月17日
# 日記をトップページへ
トップページはあまり更新されなくて寂しいので、日記をトップページにも表示するようにしてみた。
これで、あまり更新されていないという印象をちょっとは軽くできる？？
# SSIで引数を渡すには
ApacheではSSIのexec cmdなどで引数を渡せないようになっているらしい。セキュリティー確保のためとのこと。ちょっと調べたところ、次の方法で代用できるみたい。
- 環境変数を使って渡す
- exec cmdやexec cgiの代わりにinclude virtualを使う
include virtualを使う場合は、CGIのときのようにHTTPヘッダーを出力する必要があるとのこと。また、HTMLファイルへの記述は
<!--#include virtual="hoge.cgi?arg1+arg2"-->
のようになるとのこと。
# AlltheWeb ヒットしないことも
検索エンジンのAlltheWebでは、検索するキーワードによってはヒットするはずのページがヒットしないことがあるみたい。比較的データも新しくて精度もよいので気に入っているのだけどなぁ。
# スタイルシートのクラス名
Netscapeではスタイルシートのクラス名に_（アンダーバー）が使えない(?)とは知らずに大苦戦…。
# 全角文字と半角文字で異なるフォントを使う
font-family: Verdana, ＭＳ Ｐゴシック;
のように指定すれば、半角文字は「Verdana」、全角文字は「ＭＳ Ｐゴシック」というように半角文字と全角文字で別々のフォントを指定可能。これは、最初のフォントにない文字（全角文字）は次のフォントの候補から選ばれるためらしい。
# 携帯版日記
日記を携帯からも見れるようにしてみた。
2002年11月16日
# ディスプレイ故障
ディスプレイの調子が前からよくなかったのだけど、とうとう映らなくなってしまった。
仕方がないので相当古いディスプレイをつないでみたけど、以前はよく平気だったなと思うくらい見づらくて、眼もチカチカする。これじゃあまりパソコンを触る気にもならないなぁ。
早めになんとかしたいところ。
2002年11月15日
# Javaを勉強中
Javaの基本中の基本を勉強中。
それにしてもJavaは文法がきれいでいいな。classの中にメソッドを記述できるのも個人的にはとても気に入っている。以前JavaScriptで同じように書こうとしたけどうまく書けなくて残念だったし。記述の方法がまずかっただけかもしれないけど。
Javaに慣れてきたら、プログラムを書くのはJavaとPerlがメインになりそう。
# リンクでURLを表示すべきか
ウェブページを印刷したときにもリンク先のURLが分かるようにURLも表示しておくという考えもあるけど、個人的にはこれはブラウザの機能で実現すべきことだという感じがする。印刷時のオプションで、
HTMLの規格はw3c (http://www.w3c.org/) で提案されています。
などのようにURLを表示して印刷するか選べれば、作り手は印刷時のことまであまり考えなくてよくなると思うのだけど。
URLを表示するのはリンク先がはっきり分かるというメリットもあるのだけどね。
# ウェブページのタイトル
ウェブページのタイトルは、ブックマークリストや検索エンジンの検索結果の一覧表示などで使われるので重要だと言われるけど、タイトルの付け方はなかなか難しい問題だと思う。
普段検索エンジンなどを利用していて思うのは、そのページの内容を要約したタイトルだけをつけているケースが大半だということ。たとえばuttsu.comで言うなら、トップページから進んで「Products」−「CGI/SSI」にある「Fortune」というSSI用のスクリプトを紹介したページだったら単に「Fortune」というようなタイトルがつけられているケースが多いように思う。
このタイトルの付け方もシンプルでいい気もするけど、わりと起こりがちな問題は、Fortuneのページにもしかしたら「SSI」という言葉が使われてないかもしれないということ。この場合、検索エンジンで「SSI ことわざ表示」（Fortuneはランダムにことわざなどを表示するスクリプト）などと検索してもページは見つからないことになってしまう。
uttsu.comで採用しているタイトルのつけ方は「翔星ワールド」を参考にさせてもらっていて、
Fortune [uttsu.com - Products - CGI/SSI]
という風になっている。このタイトルの付け方は、一番最初にページのタイトルが書いてあって、その後にページへの順路が書いてあるのでサイト内での位置も分かりやすいし、検索でもちゃんとヒットするので気に入っている。
同じような書き方で、
uttsu.com - Products - CGI/SSI - Fortune
というようにトップページから書く書き方もあるけど、一番大切な「Fortune」というタイトルが最後にあって目立ちにくいし。奥が深いです。
「日記」というような適当そうなタイトルばかり付けていて言うのもあれだけど…。
# Windowsで文字列の置換
多くのファイルの文字列を一気に置換するのに「Speeeeed」というソフトを最近よく使っている。このソフトでは正規表現が使えるので複雑な条件を指定して置換ができて便利。
2002年11月14日
# 外部JavaScriptファイルで最新情報を提供
外部JavaScriptファイル（.jsファイル）を別のサーバーから呼び出してもらって、常に最新の情報を届けるというアイデアは面白いと思うんだけど、これってXSS（クロスサイトスクリプティング）の危険性もあるから、信頼してもらえるサイトのサービスじゃないと使ってもらえないなぁ。
用意する外部JavaScriptファイルの中では、単にdocument.write()によってHTMLを書き出すだけにしておくと古いブラウザにも対応できて汎用的。それに表示速度も速いし。実は最初はこのことに気付かず、思いっきりオブジェクト指向で書いたコードを用意してみたけどNetscape Navigator 4.0などで読み込んでみると表示にかなり時間がかかった。
ちなみに利用する側からの呼び出し方法は、HTMLファイルの中で（外部JavaScriptファイルによる情報を）表示したいところに
<script src=http://domain.com/hoge.js></script>
などと書くだけでよくて、とても簡単。
# ＠nifty、So-net、OCNがIP電話相互接続テストで合意
この話は少し前から聞いていたけど、将来的には電話の通話料は（基本料金以外は）無料の方向に進んでいくのかな。
# JPEGファイルも圧縮！ ソースネクストの「超縮」シリーズ
例えば、3.33MバイトのJPEGファイルをZIP圧縮した場合、約3.31Mバイト程度にしかならないものが、超縮（quf）では、約114Kバイトまで圧縮できたとしている（同社調べ）。
ええッ。そんなに圧縮できるのかなぁ。
2002年11月13日
# イントラネット・ユーザビリティ：1兆ドルの問題
Jakob Nielsen博士のAlertbox。
イントラネットのことだけど、参考になるなぁ。
# ネット上の差別的言論の非合法化で対立に向かう欧州と米国
欧州議会で、差別的なコンテンツとそれへのハイパーリンクが有罪になる規定案が承認されたとのこと。
# パンク防止剤
あらかじめチューブにゲル状の液を入れておくことで、パンクしても穴が塞がるというものらしい。ホームセンターなどで800円くらいで売られているのだとか。初めて知った。
ただし、パンク修理のときにも穴を発見しにくくなる欠点もあるらしい。
2002年11月12日
# AlltheWeb
AlltheWebで日本語のページを検索するなら、「Any Language」だと検索結果がかなり少なくなってしまうみたい。「Japanese」を選ぶとちゃんと検索される。
よくあるキーワードでも、キーワードによってはまったく検索されないこともあるみたい。まだ日本語に対応しきれてないところがあるのかな。検索できるキーワードの場合は、検索結果の精度はかなり高い感じ。昨日も書いたけど、Googleよりもやや高いような気もする。
検索結果がGoogleの場合と似ていることがあるけど、Googleのエンジンを使ってるってことはないよね。単にデータが新しいから精度がやや高いだけとか。
# Webページと画像
Webページに画像を載せる場合、<img>タグのwidthやheightでサイズを小さめに指定して画像を縮小させると荒い画質の画像になってしまう。多分、拡大や縮小に時間のかからないアルゴリズムを使っているからなんだろうけど。
そこで縮小表示用に小さ目の画像を別途用意して使うわけだけど、画面のキャプチャー画像のようなベタ塗り部分の多い画像だと縮小するとディザリングされて、もとがファイルサイズが小さいだけにあまりファイルサイズを減らせない。
2つの画像を用意するとそれだけ容量も必要だし、転送量も増えてしまうし。うーむ。
# AlltheWebでサイト内検索
結城浩さんの「サイト内の検索にGoogle.comを使う方法」を参考に、Googleの代わりにAlltheWebを使ってサイト内検索をする方法を考えました。言語は日本語に限定しています。
_ HTMLのみの場合
以下のコードをHTMLファイルに記述すればOKです。uttsu.comのところは自分の使っているサーバー名にします。
<form action=http://www.alltheweb.com/search> <input type=hidden name=cat value=web> <input type=hidden name=cs value=cp932> <input type=hidden name=l value=ja> <input type=text name=q size=25 maxlength=256 value=site:uttsu.com> <input type=submit value=検索> </form>
_ HTML+JavaScriptの場合
HTMLだけの場合だとテキストエリア内に「site:○○」という文字が予め入っています。JavaScriptを使えば、これを表示しないようにできます。結城さんの「サイト内の検索にGoogle.comを使う方法」−「JavaScriptを用いてサイト内検索」で解説されている方法がAlltheWebの場合でもそのまま使えると思います。
_ CGIの場合
これも結城さんのページを参考に作りました。
#!/usr/local/bin/perl
use strict;
my $my_site = 'uttsu.com';
my $my_keyword = 'uttsu';
my $q = $ENV{QUERY_STRING};
$| = 1;
main();
exit;
sub main {
$q = join('', grep(/^q=/, split(/&/, $q)));
$q =~ s/^q=//;
$my_keyword =~ tr/ /+/;
$my_keyword =~ s/(\W)/'%'.unpack("H2", $1)/ego;
print "Location: http://www.alltheweb.com/search?cat=web&cs=cp932&l=ja&q=site:$my_site+$my_keyword+$q\n\n";
}
$my_siteは自分の使っているサーバー名。$my_keywordに自分のサイト内の全てのページに含まれるキーワードを指定することにより、ドメインを持っていない場合でもサイト内検索ができるようになります。詳しくは結城さんのページを参照してください。
HTMLファイルから、次のように呼び出します。
<form action=search.cgi> <input type=text maxlength=256 name=q> <input type=submit value=検索> </form>
_ ダウンロード
簡単なスクリプトですが、サンプルのHTMLファイルと一緒に置いておきます。
# 情報セキュリティー侵害の実態とマスメディア報道
高木浩光さんのコラム。
2002年11月11日
# Webの「正しい」アーキテクチャ
・Webサイトが保持していて、外部に公開される内容には、すべて（論理的な）URI（URL）が付いていなければならない。
・Webサイトへのアクセスは、HTTPのPUT（Create)、GET（Read）、POST（Update）、DELETE（Delete）で行い、それぞれ処理内容に合わせた結果が返されなければならない。
・Webサイトへアクセスした結果返されたものがリソースの表現（Representation）であり、ページからページへの遷移が状態の遷移（State Transfer）と見なされる。
http://www.atmarkit.co.jp/fdotnet/opinion/yoshimatsu/onepoint05.html
論理的なURI。さらにそれが不変であることも求められるわけだから、なかなか難しい。設計段階でしっかり決めておかないとあとから大変になるのが通例。
唯一のURIを持つ必要がないページを出力するなら、GETではなくPOSTメソッドを使った方がいいのかな。内容とURIが論理的に結びついていないけれどGETメソッドを使うと、URIばかりを増やしてしまうし。
# 「使い勝手の悪いイントラネットは高くつく」、米調査
Nielsen Norman Groupのレポート。
# 一般人にとっては見た目がサイトの評価軸
ネット上では情報の信憑性を確かめるのが難しいから、「見た目」の比重が大きくなるというのもあるかも。
# 小さなプログラム
プログラミングを勉強する上で、小さなプログラムを数多く作ることはとても重要だと思う。とくに新しい言語を始めるときなんかは。
目的の言語に慣れていない段階では、そもそも規模の大きいプログラムを作ること自体困難なことなのだけど、少し規模が大き目のプログラムを作っていて行き詰まったりしたところで他の小さなプログラムをいくつか作ってみることは、ぼくの場合案外収穫が大きい場合が多い。小さいプログラムの方が構造が単純で理解しやすいし、数をこなすことによってその言語の「流儀」みたいなものに慣れられるし。
数をこなすことで得られる一番の成果は、自分のスタイルが固まって来ることではないかな。それまでは上級者の書いたお手本のスタイルをもとにみようみまねで書いていたのが、だんだんと自分のスタイルだと思えるようになってくる。それがもし（見た目は）手本のスタイルとあまり変わらなくても、自分のスタイルにできたということが大きい気がする。
自分のスタイルが確立してくると、こういうときはこういう風に書く、というのがある程度定まっているから、プログラムを作るスピードが早くなるし、そうなってくるとある程度思い通りにプログラムを作れるので、プログラムを作ること自体が楽しくなってくる。プログラミングの勉強を始めたばかりの人には、小さなプログラムをたくさん作って早く慣れてほしいと思う。
実はいま、ようやくPerlに少し慣れてきて、ある程度思うようなプログラムが書けるようになってきた。そういうわけで、小さいプログラムをいろいろ作り中。
# AlltheWeb.com
AlltheWeb.comという検索サイトがなかなかいいらしい。
いまいくつかのキーワードで試してみたところ、検索精度も<em>かなり</em>いい感じ。試したキーワードがたまたまなのかもしれないけど、もしかしたらGoogleよりも精度がいいかも。それにデータが新しい模様。
検索エンジンはGoogleの一人勝ちかと思っていたけど、ここまでのものが他にあったとは。かなり驚き。
# kartoo
kartooのFLASH版はキーワードに関するマップが表示される。面白い。日本語には対応していないっぽいけど、精度もよさそう。
2002年11月10日
# ホスト名でアクセスログを取る方法
現在使っているレンタルサーバーのアクセスログはクライアントのIPアドレスが保存される設定になってるみたいだけど、ホスト名で保存された方が分かりやすいので、強引に変えてみた。
.htaccessで、ホスト名でアクセス制限をかけるようにしておけば、アクセスログもホスト名で記録されるみたい。一度ホスト名に変換させればいいわけだから、次のように実際にない適当なホスト名を追加しておけばOK。
deny from hoge.hoge
アクセス制限をしているページのログだけはホスト名で記録されていたので、もしかしてと思って試してみたらどんぴしゃり。サーバープログラムはapache。
でも、サーバーへの負担は大きくなるけれど…。
# Proxyサーバーに潜む危険性
様々な理由でproxy serverが使われると思うんですけど、やりとりされるデータがproxyサーバーで収集されて、そのときに情報が漏れてしまう危険性もあるかもしれないですね。パスワード認証のために入力したパスワードなどもproxyサーバーを経由するわけですし。
大事なデータを扱うときは、信頼できないproxyは避けた方がいいのかも。
# RewriteMap使えず
一昨日のRewriteEngineを使ったアクセスカウンターは、現在使っているサーバーではReriteMapが使えない設定になっているらしくて実現できなかった。スクリプトを書く前に試せばよかった…。
サーバーのエラーログは以下。
.htaccess: RewriteMap not allowed here
# Dynamic Access Analyzer
RewrietMapが使えなかったので、今度はサーバーにあるアクセスログを直接処理するスクリプトを作ってみた。こっちの方がスマートかも。
1日ごとの表示などをつければそれなりに使えるかも。
2002年11月9日
# スパムメールとwebmaster
ホームページなどでメールアドレスを公開すると、広告のメールやウィルス付きのメールなどの迷惑なメールが届く原因になるけど、そのアドレスがwebmaster@○○.comのようにwebmasterアカウントのものだと迷惑メールの数が少ないような気がする。はっきり確かめたわけではないけれど。
以前2つの団体のサイトを運営していて、片方はwebmaster、もう片方は無料メールサービスのユーザーアカウントで運用していたときは、後者のサイトの方はアクセス数は少し少ないくらいだったけど迷惑メールの受信数は多かったし。
どうなんでしょう。
# リンクに許可は必要か
ぼくはリンクに許可は不要だと思っていますが。
奥村晴彦さんの「リンクに許可は必要か」に分かりやすくまとめてありました。
また、後藤斉さんの「ウェブページのリンクおよびその他の利用について」によると、
リンクは自由である!
印刷媒体での言及も自由である!
引用は公正な慣行に従って!
無断複製は違法である!
とのことです。引用と無断複製のことについても書いてあります。引用や無断複製の問題は紙面媒体などでも言えることですけど、まだ守れていないケースも多いのではないでしょうか。
ところで、ウェブ上の文書などから引用する場合、出典を明示するにはそのページへのリンクを張る（＝URLを明示する）のが一番の方法だと思いますが、リンクに許可が必要となるとこれもやりにくくなくなって、引用さえできにくくなる気もします。
「トップページから○○へ行って、△△の中の□□にあります」
というような説明でサイトのトップページへリンクされていることもときどきあるのですが、これだと利用にちょっと不便です。
# 音声付き百人一首
昨日の百人一首は、ダウンロードしたものを実行してもやはりフリーズするようでした。
少し探してみたんですが、読み上げ機能付きの百人一首のソフトで他に無料のものは見つかりませんでした。学習用にも有用だと思うんですが…。
2002年11月8日
# RewriteEngineを使ったアクセスカウンター
RewriteEngineでは、振り分けの条件判定にプログラムを指定できるみたい。ちょうどCなどのsort関数のような使い方のよう。
それで、これを使えばスマートなアクセスカウンターができそうな気がする。サーバーのルートディレクトリに.htaccessファイルを置いて、その先頭あたりでRewriteEngineを使って、ルールの指定に常に真（または偽）を返すPerlスクリプトを指定すればよさそう。この振り分け条件は結局無意味なのだけど、ここで指定されたプログラム中で環境変数を参照してアクセスログを取ることができる仕組み。
この方法だと、各ページごとにCGIから出力する画像ファイルを埋め込んだりする必要は一切なくて、しかも全てのページそれぞれについて個別にカウントしたりもできるメリットもある。
さらに、HTML以外のファイルにも対応できるので、ファイルのダウンロード数をカウントするDownload Counterも兼ねることができる。Download Counterと比べて優れている点は、
- ファイルの出力はあくまでサーバーが行うので、プログラム側でヘッダーなどを補完してやる必要がない
- CGIを通してファイルを出力するのではないので、CPUパワーを節約できる
- CGIを通してファイルを出力するのではないので、.htaccessなどでのセキュリティーを保てる。.htaccess以外でも、CGIを通してファイルを出力するのはセキュリティーポートとなりやすいと思うので。
がありそう。
環境変数を参照してログを取る機能だけを書けばいいので、カウンターのスクリプト自体もシンプルに記述できそうだし。
# 音声付きオンライン百人一首
やっぱり読み上げてくれるとゲームとしてとても楽しめますね。ゲームバランスもよくて、しばらく没頭してしまいました。ただ、100問終えた時点で固まってしまうような…。
音声データがあるので、ブロードバンドでないときついかも。
2002年11月7日
# RewriteEngine
ApacheのRewriteEngineについてちょっと勉強。環境変数を参照して表示ページを振り分けできるのでかなりいろいろなことができそう。
uttsu.comでは/doc/以下へのアクセスの場合はDocument表示スクリプトによってテキストファイルを動的にHTMLに変換して出力しているのだけど、サーバーにもともとHTMLファイルが存在すればそちらを出力するようにしてみた。たまにはHTMLファイルとして置いておきたい場合もあるかもしれないし、過去に書いたHTMLドキュメントをそのまま置くこともできるし。
実はこの機能はCGIでも実現できるのだけど、Last-Modifiedフィールドなどのヘッダーを出力したりするのが面倒なのと、なによりもこういうことはCGIよりも前の処理であるべき(?)なので、RewriteEngineを使った方がスマートだしね。
.htaccessの内容は以下。
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([0-9].*)\.html$ index.cgi?$1
# [日記システム] 付けたい機能
- レスポンスヘッダーにLast-Modifiedフィールドを出力
- 注釈機能
Last-Modifiedを出力しないと無駄なトラフィックを生んでしまうので。
# [情報] GoogleパワーがWebの脅威に？
「最強検索エンジン」の誉れ高いGoogle。だが同社の影響力はあまりに強く、企業のビジネスをも左右するほどだ。この強大なパワーに対し、業界の一部が懸念を高めている。
http://www.zdnet.co.jp/news/0211/06/ne00_google.html
これは確かにあると思う。他の検索エンジンにも頑張ってほしいところ。
2002年11月6日
# Referrer消去リダイレクト
リンク元URLを渡さずにリンクするCGIを公開しました。プライベートなページからのリンクなどに使えるかも。
# ライセンス
配布しているプログラム数が増えてきたので、そろそろライセンスについて考えようかな。今までは何気なく「フリーソフト」としていたけれど、解釈の仕方がいろいろあるみたいだし。
ライセンスは基本的にはGPLに則したものにしたいけど、GPLではソースも公開しなければならないらしい。昔のBASIC用のプログラムにマシン語をデータとして含んでいるものがあるので、このアセンブリ言語のソースも付ける必要があるのかが気になる。プログラムを探して動作確認が面倒なので…。
2002年11月4日
# モジュラーケーブル張り替え
ADSLの速度アップのために、保安器からのモジュラーケーブルをツイストペア＆シールドのものに替えることに。
その前にまず、ADSLモデムやスプリッターと一緒に付いてきた、スプリッターとモデムを繋ぐ2m程のケーブルをノイズ対策をされた上記のケーブル（20m）と交換してみると、スループット値が平均610kbpsくらいから640kbpsくらいに上がった。長いモジュラーケーブルはその分ノイズを拾いやすいので、20mのものの方が速度が上がったのも意外だったけど、モデムと一緒に来たケーブルがノイズにあまり配慮していないものだったとは…。
それで、保安器からのケーブルをツイストペアに替えてみたところ、こちらも平均610kpbsだったのが640kbpsくらいまででるようになった。スプリッターを介さず、直接モデムに繋いでも同じくらいの値。でも、ケーブルの長さの割には効果が微々たるものなので、結局張り替えはせず、元のケーブルを使うことに。
# 過去の日記データを移行
すべてこの日記のページにまとめました。
# ブックマーク活用法
最近は、IEの「お気に入り」の中に「_未整理」というフォルダを作って、面白いと思ったり、気になったページをまずそこへ登録することにしてます。そして、後日何回か見てみて、適切なフォルダへ移動。こうすると、気軽にブックマークに登録できて便利です。（フォルダ名の先頭にアンダーバーを付けているのは、登録のときにそのフォルダが先頭に表示されるようにするためです）。