urlwatch採用
チェック対象のページ数からして、wgetとdiffでやっていくのが効率的だろうという考えには達しました。
しかしもちろん、手でwgetやdiffを動かすわけにはいきません。
wgetだけなら、あるいはdiffの実行までなら手動操縦もありえます、が、diffの結果のチェックまで目視でやるには無理があります。
少なくともdiffの結果は一つのテキストファイルにまとまっていてほしいものです。
それともう一つ、diffにかける前に、チェック対象外の部分を削除する方法も検討する必要があります。
このあたりの実験的なコード作成には、深く考えることなくPythonを選びました。
自分にとって一番手っ取り早いという理由です。
そして、チェック対象のページが決まっていて、Pythonを使うとなると、wgetすら必要はありません。
Pythonのurllib2を使うと、HTMLのダウンロードができてしまうからです。
しかし実は、そこまでやる必要すらないだろうと思っていました。
urlwatchというPythonスクリプトを見つけてあったからです。
HTMLの取得からdiffの適用まですべて自動で作業してくれる優れものです。
手でフィルターを書けば、diffにかける前にHTMLデータの不要な部分を削除しておくこともできます。
これで、動物園・水族館WEBサイトのウォッチが現実のものになる、と思ったものでした。
実際のところ、これでもがんばればどうにかなるレベルではありました。このブログ内で動物園・水族館のWEBサイトの更新状況を報告していた時は、このurlwatchを使用していたのでした。
しかし、urlwatchにはurlwatchなりの問題がありました。
urlwatchを使っていて困ったこと
urlwatchはすばらしいソリューションを私に提供してくれました。
けれども、十分といえる域には達していなかったのです。
まずurlwatchの挙動について、簡単に説明しておきます。
- 監視対象のurlのリストを作ってurlwatchに投入すると、urlwatchはその対象のHTMLファイルをサーバーから取得します。
- 初期設定のままだとurlwatchはそのHTMLファイルをlynxに食わせてプレーンなテキストファイルにします。
- さらに、ユーザーが設定したフィルタを通してそのテキストファイルを加工します。
- フィルタ後の結果と、前回の実行結果であるキャッシュファイルをdiffで比較し、比較結果を出力します。
- 今回のフィルタ後の結果でキャッシュファイルを上書きし、次回以降の実行に備えます。
lynxを通した結果に対してdiffを適用することで、無関係なjavascriptの変更やcssの変更を気にする必要がなくなり、WEBサイト上の意味のある文言だけを比較できるわけです。
相手がセマンティックなWEBサイトならこれで十分ではありませんか。
しかし、動物園・水族館はそのような相手ではありませんでした。
まず、urlwatchは必ずしも日本語を正しく扱うことができません。UTF-8しかまともに扱えません。
Shift_JISやEUC-JPエンコーディングのサイトは文字化けしてしまいます。
文字化けしながらも新旧比較はできるので、サイトが更新されたということと、大体の更新箇所はわかるので、ブラウザでそのサイトを開いて実際の変更箇所を目視確認するという作業が必要になります。
動物園・水族館が日本語文字コードの問題について深く考えているはずもなく、普通にShift_JISやEUC-JPエンコーディングのサイトがあります。
そしてもう一つの大きな問題。
それは、urlwatchのセールスポイントの一つであるフィルタの使い方が難しいことです。状況によっては使い物になりません。
フィルタはlynxを通した後のテキストデータに対して適用されます。
フィルタが使えるには、この時点で文字化けしていないという前提が必要になります。これで半数近くのサイトではフィルタが機能しないことになりました。
さらに文字化けしていなかったとして、どのようなテキストデータが出力されているのか、ハッキングなしに確認する方法がないため、フィルタの書きようがありません。
対象のサイトをlynxで開いて実際に見てみるくらいしか手がありません。
そしてさらにやっかいなことに、そのフィルタが正しく動作しているかテストする方法が見当たりません。
urlwatchを動作させてしまうと、たとえフィルタが間違って書かれていたとしても、その間違ったフィルタを通した結果がキャッシュに書きこまれてしまいます。原本はどこにも残りません。
フィルタの間違いに気づいて修正したとしても、再実行することができないのです。
せめて原本がどこかに残っていてほしいものなのですが、urlwatchの仕様上、フィルタを通した後のファイルしか残されません。
また、動物園・水族館のサイトはセマンティックなものであるとは限りません。正規表現でのフィルタ作成すら困難です。親切に表示された今日のお天気をどうやって正規表現で切り抜けというのでしょうか。
というわけで、urlwatchをベースに、自分なりのツールを開発する必要性に迫られたのでした。
ちなみに、urlwatchで200のサイトを監視していたところ、次のような時間がかかっていました。
大体動物園・水族館が一日の業務を終えるのは午後6時くらいだろうと目途をつけていました。もちろん実際には、動物園・水族館の主業務はWEBサイトの更新ではありませんから、とっても遅い時間に残業してブログとか書いていらっしゃる職員さんがたくさんいることも今ではわかっています。が、こちらもこちらの作業時間の都合上、午後6時くらいというのが一つのタイムリミットでした。
で、午後6時を過ぎたあたりでurlwatchを走らせます。200のうち大体50から80のサイトで更新がかかっていることが分かります。
明らかに無関係な「あなたは○人目のお客様です」のような更新内容を除き、それらのサイトを一つ一つブラウザで開いて目視確認し、変更箇所を手でテキストエディタに入力していきます。
北海道から鹿児島まで、全データをチェックすると作業完了が早くて午後8時、遅い日は午後10時手前までかかりました。
ということは1回のチェックの作業に2時間から4時間をかけていたことになります。
これで給料がもらえるならまだしも。あるいは給料がもらえたとしても連日午後6時から10時まで拘束、かつ集中して作業というのはちょっときつすぎます。
urlwatchで監視を続けるのは非現実的と言わざるをえませんでした。
0 件のコメント:
コメントを投稿