素歩人徒然　アクセスカウンター(その3) カウンター機能を自作する

(203)
アクセスカウンター(その3)

── カウンター機能を自作する
▼不思議なカウンター機能
　カウンターというものに私は以前から疑問を持っていた。これは、誰が、どのように使う目的で用意されたものなのか? という点である。カウンターの現在値は、誰でも簡単に知ることはできるが、そのたびに値は変わってしまうのだから意味がない。値を見るという行為そのものが、カウンターの現在値に影響を与えてしまうのが問題なのである。それを誰もおかしいと指摘しないのもまた不思議なことである。SNSの世界での“いいね!”とたいして変わらない程度の意味のないものになってしまっている。

　もう一つの疑問点は、カウンターの値を「情報」という観点から見た時、誰が管理すべき情報なのかがはっきりしない。例えば、関係者を以下の様に分類するとしよう。

・システム提供者　　　 ‥‥プロバイダー
・閲覧者　　　　　　　 ‥‥読者
・ホームページの作成者 ‥‥私のような個人の立場の人

　「システム提供者」が主たる管理者であることに異論はないが、個々の作成者にも権利があるのではないかと思う。「作成者」はそのデータを使って自分のホームページに関連する様々な情報を引き出したり、あるいはその結果を閲覧者に公開するのが望ましい姿ではないかと考えている。現状では作成者にはそのような権利が与えられていないケースが多いのではないか。これは日本だけのことなのかもしれないが。

　しかし私のようなホームページ作成者にはカウンター値は必須の機能なのである。そのためには、作成者の立場ではむやみにカウンター値を見たりしてデータとしての精度を失うようなことはしたくない。

　そこで、私はできるだけ自分のページは開かないように努力してきた。もちろん新たに情報をアップした場合には表示が正しく期待通りのものになっているかを調べる必要があるから、アップした直後に一度だけ確認することにしている。しかしそれ以外のことでは、あえてそのページを開いたりはしない。私がカウンターを設定する理由は、自分の書いたものが読者にどのような反応を引き起こしたかを知りたいのである。ここで言う“反応”とは必ずしも感想とか反論とかを期待している訳ではない。単に読んだかどうかが知りたいだけである。それだけでも私には価値がある。

　自分で何回も覗いてしまったら、それだけデータへの信頼度は失われてしまうだろう。したがって、カウンターというものは作成者は“覗かなくても”現在値がどうなっているかを知ることができなければならない、と私は信じている。

　私が初めて自分のホームページを作ったのは実は海外でだった。アメリカのプロバイダーYahooが提供する環境に、日本人の私が(日本に居ながら)ホームページを作ったのである。そしてそこにカウンターを設定したのが始まりである。

　アメリカでは、人間が生活する場所としての住所は通りの名前(Street, Drive, Road, ,...)と一連の番号とで表す習慣になっている。インターネットの世界も同様で、蛇行する道が描かれていてその両側に家(ホームページ)があるという夢のある環境の中に構築されていた。私の家の両隣りにはアメリカ人のホームページがあった。アメリカ的にかなり距離間のあるお隣りさんではあったが。

　ところが数年が経過した頃、日本にYahoo Japan が設立されると日本人のホームページはすべて強制的に日本に移住(?)させられてしまった。日本での移住先では、最初はうまく動作しなくて苦労させられたが何とか日本で生活できるような環境にはなった。

　そういう経緯があったので、日本の最初のホームページの構造はアメリカ産のままで使いやすかった。特にCGI環境はまさにそのままの仕様が日本でも使えるようになったのである。しかし時間が経過するにしたがって日本のプロバイダーが提供してくれるCGI機能は日本独特のものに少しずつ変質していったようである。

　その過程で、私はカウンター機能とは一体誰のためのものなのかという疑問を持つようになった。どこかで誤解が生じているのではないか。パソコン環境でのCGI機能は、プログラミングを学ぶ過程では、例題としてよく取り上げられるテーマだったからよく知られていた。以前は、CGIプログラミングの本が沢山売られていたように思う。プログラミングの世界もその後急速に変わっていったから当然かもしれないが、最近はCGIプログラミングの本は見かけないようである。

　最近の日本のプロバイダーは、CGI機能は自分たちが管理するものであって利用者にはデータは見せなくてよいと考えているのではないか。本来はシステム提供者側とホームページ作成者側とで共有するものではないかと思う。当初の考え方に戻してもらいたいものである。

　特に、カウンター機能に関してシステム提供者側と私との意見の違いは「カウンター値は“覗かなくても”見ることができる」様にするかどうかの争いであった。
　最初の環境で使ったカウンター機能では、自由にアクセスが許されていた。それが突然カウンター機能自体が許されなくなり別種のカウンター機能を使うよう指示されたのである。そのカウンター機能でもCGI環境の中に保管されているものを見ることは許されていた。そこで私は毎日それをダウンロード(手作業が必要だった)してからプログラム処理しなければならなかった。そして今回は、遂にデータ自体を見ることができなくなってしまったのである(詳しくは「アクセスカウンター(その１)」を参照されたい)。

▼カウンター機能の開発
　引っ越し先の環境でもカウンター値の公開は同じように許されていない。これは最初からそれを承知で契約したのだから文句は言えない立場である。そこで私は自己流の方法で、自分好みのカウンター機能を作成することにした。

　ホームページの引っ越し作業をしている間に、私はカウンター機能の実現方法についていろいろと考えていた。そして具体的な方法を考える以前から、何となくできそうな感触を持っていた。新しい環境では、ホームページのアクセス記録である“ログファイル”が作成されていて、それを作成者はパスワードを使って見ることができるようになっていた。これを詳しく観察すれば、カウンター値に影響を及ぼすログを見つけ出すことができるに違いないと考えたのである。ログファイルは毎日作られるが一日遅れで公開されている。これを利用することにしよう。

　私はホームページ移転の作業が終わると早速調査を開始した。一日分のログファイルは膨大な分量である、その中から望みのデータを捜し出すのは大変に難しい作業である。比喩として言われているのは、穀物倉庫の中から特定の「小さな麦わら１本」を見つけ出すようなもの、と表現されている程である。それなら私が愛用している Perlというプログラム言語の最も得意とする機能の出番ではないか。

home.s05.itscom.net 157.55.39.29 - - [10/Jan/2022:05:07:24 +0900] "GET /knuhs/css/style.css HTTP/1.1" 404 196 "-" "Mozilla/5.0 (iPhone; CPU iPhone OS 7_0 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11A465 Safari/9537.53 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)"
home.s05.itscom.net 240b:252:30a0:b900:d8b2:e545:19c3:6a58 - - [10/Jan/2022:05:17:20 +0900] "GET /knuhs/shef04.htm HTTP/1.1" 200 10630 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0"
home.s05.itscom.net 240b:252:30a0:b900:d8b2:e545:19c3:6a58 - - [10/Jan/2022:05:17:21 +0900] "GET /knuhs/css/mystyle.css HTTP/1.1" 200 1036 "http://home.s05.itscom.net/knuhs/shef04.htm" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0" home.s05.itscom.net 240b:252:30a0:b900:d8b2:e545:19c3:6a58 - - [10/Jan/2022:05:17:21 +0900] "GET /knuhs/js/menuscript.js HTTP/1.1" 200 44849 "http://home.s05.itscom.net/knuhs/shef04.htm" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0" home.s05.itscom.net 240b:252:30a0:b900:d8b2:e545:19c3:6a58 - - [10/Jan/2022:05:17:21 +0900] "GET /knuhs/images/bottomtitle.gif HTTP/1.1" 200 4238 "http://home.s05.itscom.net/knuhs/shef04.htm" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0"
home.s05.itscom.net 240b:252:30a0:b900:d8b2:e545:19c3:6a58 - - [10/Jan/2022:05:17:21 +0900] "GET /knuhs/images/bdmybookshelf.jpg HTTP/1.1" 200 3319 "http://home.s05.itscom.net/knuhs/shef04.htm" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0"
cgi01.itscom.net 240b:252:30a0:b900:d8b2:e545:19c3:6a58 - - [10/Jan/2022:05:17:21 +0900] "GET /cgi-bin/Count.cgi?df=f1003240.cf04.dat|dd=A|comma=Y|st=90|sh=Y| HTTP/1.1" 200 1571 "http://home.s05.itscom.net/knuhs/shef04.htm" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0"
home.s05.itscom.net 240b:252:30a0:b900:d8b2:e545:19c3:6a58 - - [10/Jan/2022:05:17:21 +0900] "GET /knuhs/b0_on.gif HTTP/1.1" 404 196 "http://home.s05.itscom.net/knuhs/shef04.htm" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0"

図 : ログファイルの例
　具体的な手順は以下のようになる

(1)ログファイルをダウンロードして取得する(手作業)
(2)カウンター値の推測(AnalizeACSL.pl)
　・ログファイルを解析する
　・必要なデータを集める
　・集まったデータを突き合わせて整理する
　・整理したデータから現在のカウンター値を推測する

　(2)を実行するのが AnalizeACSL.pl の役割である。

(3)カウンター値の一覧表を作る(MakeCTTable.pl)
・現在のカウンター値をすべて集める
・カウンター値の変化を捕らえ一覧表にまとめる

　　▼カウンターの一覧表の例

　(3)を行うのが MakeCTTable.pl の役割である。

　なお、ここで得られたカウンター値は、ログファイルを解読しその動きをシミュレートすることにより得られたものである。したがって、システムが提供する本来のカウンターとは別物と考えた方が良い。カウンターの現在値を単に推測したものである。

▼カウンター値と格闘する
　二つのプログラム(AnalizeACSL.pl, MakeCTTable.pl)については、いずれPerlプログラム集の中で公開する予定なので、ここでは詳細な説明は省略する。

　ここでは、過去のログファイルを使ってカウンター値を推測する方法を採用したので、私は開発作業を急ぐ必要はなかった。日々新しいログが生成されているが、そのログをしっかりと保存しておけば、いずれそれを処理してプログラムで答えが出せるはずだと考えていたからである。慌てることはない！　マイペースで開発すれば良いのだ。

　ホームページの引っ越しが終わったのが11/23日であるから、システムの開発を始めたのは１１月末からで、ほぼ予定通り12月末にはテストを始められる時期になっていた。１か月間でプログラムはできあがったことになる。

●12/29日、いよいよテストを開始することにした。

作業日 ログの月 処理日 コメント

12/29
更新作業 2021-11月
分のログ 11/7,8
11/9,10,11,12,13
11/15,16,17,18,19,20
2日分一括テスト
5日分一括テスト
7日分一括テスト

表：11月分のログ情報の処理開始(失敗に終わる)
　ログ情報を数日単位でまとめて、解析・推測とカウンター表の作成のテストを開始した。しかしこの過程で、さまざまな不具合が見つかった。引っ越し作業で２つのモジュール( shef12.htm, spamtaisaku.htm )の書き換えにミスがあったことが明らかとなった。その間違いに気が付いたのは１２月末であるから、その間に集めたログファイルはミスを含む環境下で作られたものであるから解析方法にも影響してくる。その影響が予想以上に大きかったのである。

　ミスをした部分は、その日の内に修正したプログラムと入れ替えられたが、開発の基礎となるログファイルの内容は書き換えられない。間違った状態で記録されたログをデータとして使い続けなければならないのである。このままでは新年早々のリリースは望めなくなった。ここはプログラム作りを一時中断し、対策を練り直すことにした。

しばらくは正月休みに備えての仕事(年賀状作成)に取り組むことにした。
　正月になってから、私はいろいろ考えた末に方針転換を図ることにした。今までは、古いカウンターデータはそのままの形式で残し、新しい環境で使われる度に新しいカウンターの表現に個々に置き換えていくという方針で進めてきた。しかし古いデータの処理がからむと何故かうまくいかないのである。ここで最初の方針を諦め、あらかじめ前処理で古いカウンターの変数名を一括して新しいカウンターの変数名に置き換えてしまうことにした。こうしておけば新旧の変換作業は楽になるはずである。

●2021-1-8日テスト再開
　失敗に終わった最初のテストではカウンター値が変更されているので、それを捨てて元の状態に戻し最初からテストをやり直すことにした。この種のテストでは、テスト中に変更されたカウンター値のみを元の状態に戻すのは至難の業である。やり直しには大変な手間がかかるので、できるだけ避けなければならないことを学んだ

● 2021-11月分のログ

作業日 ログの月 処理日 コメント

1/8
更新作業 2021-11月分のログ 11/7,8
11/9,10,11,12,13
11/14
11/15
11/16,17,18,19,20,21

2日分一括テスト
5日分一括テスト
1日分テスト
1日分テスト
6日分一括テスト

1/9
更新作業 2021-11月分のログ 11/22,23,24,25
(11/26,27,28,29,30)

4日分一括テスト
(5日分行方不明^(*1))

表：11月分のログ情報の処理過程
　テストは、すべて順調に推移している!!

● 2021-12月分のログ

作業日 ログの月 処理日 コメント

1/10
更新作業 2021-12月
分のログ 12/1,2,3
12/4,5,6
12/7,8,9,10
(12/11,12,13,14,15)

3日分一括テスト
3日分一括テスト
4日分一括テスト
(5日分行方不明^(*2))

1/11
更新作業 2021-12月
分のログ 12/16,17,18
12/19,20,21
12/22,23,24
12/25,26,27
12/28,29,30
12/31 3日分一括テスト
3日分一括テスト
3日分一括テスト
3日分一括テスト
3日分一括テスト
2021年最後の日

表：12月分のログ情報の処理過程
　プログラムは順調に、そして期待通りに動いている。自分が設計したプログラムが設計通りに動いているのを確認するのは最高に気持ちが良い。至福の時である!!

【注】(*1),(*2)このときは気が付いていなかったのだが、11/26,27,28,29,30 と 12/11,12,13,14,15 のログデータが行方不明であることが後刻分かってくる。
　一度に処理する日数を３日ごとに一括してテストすると、チェック項目の数も程よい大きさになるようである。

　このテストで検査するのは、AnalizeACSL.pl が出力するデバッグ情報(以下の図参照)を、MakeCTTable.plが作り出すカウンター値一覧の内容と突き合わせるのである。

(*)【22】
(*)$n = 8
(*)$DTname = cx07.dat
(*)$STvalue = 2142
(*)$Url = http://home.s05.itscom.net/knuhs/TOSHIBAComputerS.htm
(*)$DTtime = 2021/11/26:07:05:17 +0900
(*)$DTtime = 2021/11/26:10:09:54 +0900
(*)$DTtime = 2021/11/27:07:30:36 +0900
(*)$DTtime = 2021/11/27:11:23:24 +0900
(*)$DTtime = 2021/11/28:07:29:00 +0900
(*)$DTtime = 2021/11/29:06:58:36 +0900
(*)$DTtime = 2021/11/29:09:07:42 +0900
(*)$DTtime = 2021/11/30:06:58:13 +0900
(*)カウンター値 = 2265$2022/01/26:13:16:04 +0900
(*)加算後の値 = 2273$2021/11/30:06:58:13 +0900

(*)【23】
(*)$n = 1
(*)$DTname = cf24.dat
(*)$STvalue = 30
(*)$Url = http://home.s05.itscom.net/knuhs/shef24.htm
(*)$DTtime = 2021/11/28:02:07:44 +0900
(*)カウンター値 = 32$2021/11/28:02:07:44 +0900
(*)加算後の値 = 33$2021/11/28:02:07:44 +0900

図 : デバッグ情報の例
● 2022-1月分のログ

作業日 ログの月 処理日 コメント

1/12
更新作業 2022-1月
分のログ 1/1, 2, 3, 4

1日ずつテスト

1/13
更新作業 2022-1月
分のログ 1/5, 6, 7, 8, 9, 10, 11, 12

1日ずつテスト
遂に、現実(1/12)に追いついた

1/14以降
更新作業 2022-1月
分のログ 2022-1-13 以降は普段の状態に追いついたので、以後は「前日のログの処理」となる
ホームページ上に公開!!

表：1月分のログ情報の処理過程
　とうとう最後の１月のログに到達した。これからは１日ずつテストすることにした。2022-1-13日のテストで、遂に、現実に追いついたのである。前日(1/12日)のログ記録を処理することができれば完了したことになる。

　以後、AnalizeACSL.pl と MakeCTTable.pl とを別々に実行させる必要はないから連続して実行できるようにした。その結果、毎朝最初にログ情報をダウンロードした後、すぐさま解析と一覧表作りを実行し、そのままアップロードできるようになった。完全に私のルーチンワークとなったのである。

● 2021-11月と12月分のログ発見

作業日 ログの月 処理日 コメント

1/27
修正作業 2021-11月
分のログ 11/26,27,28,29,30

未処理のログを発見

1/29
修正作業 2021-12月
分のログ 12/11,12,13,14,15

未処理のログを発見

図 : 未処理のログ情報の処理
　これで完成したと思っていたところ、この文章を書くためにデータを整理していて11/26,27,28,29,30 と 12/11,12,13,14,15 のログデータが欠けていることに気が付いた。ダウンロードし忘れたかと思い、あちこちと捜した結果、やっと見つかりました。

　これを後から登録しても何ら問題がないことは自明である。ログデータの通り時系列で登録しても、前後を入れ替えて登録しても結果の集計値は変わらないからである。

　終活の一環として、ホームページの整理を始めたのですが、突然アクティブカウンターの使用が制限される事態に直面することになりました。終活を始めたのですからおとなしく引き下がるのが一番だったかもしれません。しかし長年苦労して作り上げた“カウンター値一覧”が露と消えるのかと思うと我慢ができなくなりました。とにかく、今後も動かすことができるようになりホッとしています。

▼最後のプログラム？
　このプログラムを作りながら、これは私が作る“最後のプログラム”になるかもしれないと考えていました。以前、素歩人徒然欄(198)に“最後のコンピュータ”というエッセイを書きましたが、私は“最後の‥‥”が好きなのでしょうね、きっと。

　ところで、私はいつも思うのですが“プログラムを作ること”はどうしてこんなにも大変で、かつ苦しいことなのでしょう。
　そして同時に、
　何故こんなにも喜びを感じる楽しいことなのでしょう。プログラム作りが終わると、私は懲りもせずにまた“プログラミングをしたい”と思ってしまうのです。

　今も昔もプログラマ

なお、ここで紹介したプログラムは、
　【Perlプログラム集】に登録し紹介されています。

　・AnalizeACSL.pl
　・MakeCTTable.pl