アクセスログをもっと活用する計画

おいらの契約しているXREAは「アナログ」というアクセスログの解析ツールを提供してくれている。このツールによってアクセスの大雑把な傾向はつかめるものの、サービスとして提供されているものなのでカスタマイズができるわけでもなく、自分で細かく調査ができないのだ。

そういうことを知ってか知らずかXREAの個人ディレクトリには前日分の生ログが置かれている。こいつを手に入れてあれこれするのも手だと思う。もちろん手元でアナログを走らせてもいいんだが、さっきも書いた通りXREAのアクセスログ解析を使えばおおかまかな傾向はわかるので、自分の好みのデータを調べる方法を考えたほうがいいのかも。

つーわけで、考えたのがUNIXコマンドの活用。まるで情報処理の授業の1回目か2回目（というか大学生の頃はコンピューターに興味がなかったので、そんな授業取ったこともないのだが）みたいだが、まずは初歩的なやりかたで欲しい情報を手に入れてみることにした。とは言うものの、いつまでたってもヘタレなおいらは一歩一歩ずつしか進めないのだが。

まずログを手に入れるところから。XREAの場合、その人のサーバールートから見て「/log/ユーザ名.サーバー名.xrea.com.log」という形で置いてあった。なので、ここからFTPでファイルを落してくる。落してきたログは日付けで管理できるといい。それからログが増えたときのことを考えて圧縮しておくのも手かなぁと。

となると、これらをシェルスクリプトで書く場合FTPコマンドに喰わせるシェルスクリプトと、ファイルを圧縮して日付けをファイル名に付けるスクリプト、これらを連結するスクリプトの3つを書けばいいかな。

まず、FTPのほう。ちと危険だがFTPコマンドを起動して、FTP上での処理を書いたシェルスクリプトを用意することにする。以下の内容を「ftp -n < xreaftp」つーかたちで喰わせるわけだ。

これ何がヤバイかっつーと、このシェルスクリプトにIDとパスワードが書いてある点。なのでそもそもログイン時にパスワードが必要なシステム上に置いておくべきだし、万が一を考えてパーミッションは「500」、このファイルを置く「~/bin」自体もオーナー以外は覗けないようにしておいたほうが懸命かも。こいつを「~/bin/xreaftp」として保存しておく。

で、次に圧縮に関する処理。ここではホームに落してきたログファイルを圧縮して日付け付きのファイル名を付け、~/Sites/logs/以下に保存するという話。リダイレクトとか変数とかよくわからないので苦労したけど、こんなスクリプトになった。

ええっと、日付けの部分が不完全。なぜなら実際のファイルに付く日付けが、こちらの意図しているものと異なるため。落してくるのは前日のログなんだけど、Mac OS Xに標準で入っているdateコマンドは日付けの加算減算を行なう「-v」オプションを持っていないくさい。後日、そういうのができる方法を探さないといけないかも。ソースからコンパイルしなおせばいいのかなぁ。それとも別のオプション？ とりあえず、これでOKなので「~/bin/logz」として保存。ファイルに実行権限を与える。

最後にこれらを連結するスクリプトを書く。ftpコマンドから先程のxreaftpを実行。ただし現在位置によって、ftpコマンドからxreaftpが見えないことがあったので、最初にホームに移動してからコマンドを実行している。

つーわけで、これを「~/bin/getlog」として実行権限付きで保存。実行すると、FTPサーバーに入る際に「?Invalid command.」と出るんだが、おいら何か問題になりそうなことをしているのかなぁ。

4/5追記：えすともさんに「xreaftp」の1行目のインタプリタ指定がそもそもいらんよ、と言われた。そういやFTPにそんなものいらんわ（￣△￣；。

とりあえず、これで保存されたファイルを見る場合は「[Macintosh:~] anoh% zcat ~/Sites/logs/20030403.log.gz | less」といった感じで指定。特定の内容を含むログを見たい場合は「zcat ~/Sites/logs/20030403.log.gz | grep Safari/60」ってな感じで指定するわけだ。「zcat ~/Sites/logs/20030403.log.gz | grep Safari/60 > Safari.txt」といった形で指定すれば、Safari/60を含んだログの一覧をSafari.txtという名前のファイルで保存してくれるので、自分の好きなソフトでゆっくりいじくりまわせる。

つーのが基本的な流れ。欲しい情報をもう少し得やすくしないといけないので、それはまたそのうち。

モジラパーティに行ったずら（2）

何はともあれモジラパーティへの参加は今年で3回目になる。よくも毎年と思うのだが、いわゆるエキスポの類は見に行かない人なので、まぁこれくらいは見に行っておこうかという感じ。去年に続いて報告をば。

まず新ロードマップに関しての紹介。mozilla.orgのロードマップのページに説明されている通り、ブラウザーとメールを担当するアプリケーションとして従来のナビゲーターおよびメール&ニュースグループに代わってフェニクス（旧名）とミノタウル（旧名）が採用されるとのこと。以前より話の出ていた個別起動もやっと実現するみこみ。

フェニクスでは新しいモジラのツールキットを使って開発されているので、これ以降のモジラの各コンポーネントもこのツールキットを使うことになる。ツールキット上で動くコンポーザーならびにチャットジラは、開発を担当する人間のなり手がなく、このままではこのプロダクトが死んでしまう可能性があるそうだ。また、従来のxpfeベースでのビルドはいずれ中止されるので、ネットスケープなどのサードパーティがxpfeベースのビルドシステムが欲しい場合は、自前で用意する必要があるらしい。

いずれにせよ、xpfeベースのシステムはややこしくなり過ぎたうえ、フェニクスのようなカスタマイズ性の高い柔軟なGUIを提供できない、すでに開発が進んでいるフェニクスをxpfeベースで作り直す必然性が見つからないというのが移行の最大の理由とのことだ。

ナビゲーターの機能を削るのではなくフェニクスを新たに採用したのも、シンプルでサイズが小さい（これはサファリやオペラの宣伝文句でもあるが）が故に、高速で管理がしやすい点、そしてモジラツールキットの採用によって実現できることの多さの2点が評価されたようだ。

とは言え、フェニクスもバージョンを重ねていく上でコードサイズが肥大化するおそれがある。今後モジラの開発体制が従来の「CVS平等主義」より、コアメンバーによるコードレビューを経た選別主義に移行していくようなので、「コアはミニマムに、その他はアドオンに」という方針を強力につらぬくことで肥大化を防いでいく考えらしい。mozilla.org中心部での見解はネットスケープAOLの桃井さんより紹介があった。

フェニクスの名称は登録商標のからみで「ファイアーバード」に変更されるという発表があったが、同じく「ファイアーバード」の名称を使っているオープンソースのデータベースコミュニティの方より現状説明があった。

このファイアーバードというプロジェクトの名称自体は登録商標化されていないが、ファイアーバードという名称自体がよくあるものだけに「問題が起きて訴訟があって始めて結論が出る」というアメリカ社会の通例に従ってそのままにされているらしい。その一方でようやく第3のオープンソースのRDBという認識が出てきたところなので、この問題で「フェニクスとはブラウザーのこと」という認識が広まることによるダメージを受けたくないという気持ちもあるらしい。「名前の衝突という問題があることが判った以上、道義的に判断し、2つの製品がともに発展していく方向に進んでほしい」ということだった。

桃井さんによると、まだmozilla.org中心部では名称変更に対する動きは出ていないとのこと。オープンな論議より当事者同士の話合いが重要だろうと見解を述べていた。

続いて行なわれたセッション「ゲッコー/モジラが組織単位で利用されるには？」では、企業導入に必要な機能やセキュリティに対する紹介や疑問提示が行われた。

ここで大きく取り沙汰されたのは、オープンソースのソフトの安全性を誰が保証するのか、といった点。

これに関しては、開発者コミュニティは保証責任の問題から切り離しておき、ネットスケープを始めとする企業がビジネスとしてソフトの安全性を保証していくような、いわば「クリーンな開発団体と金儲けという汚れ役を受け負う企業」の体制も今後必要になってくるだろうという見解が出ていた。また、質の高いソフトであり続けるために、重要な機能の開発に投資する基金の設立もあっていいだろうとのことだった。

また、企業や官庁での導入に必要な要素としては導入や維持の手間の削減という点がある。

カスタマイズを施した状態でのインストーラーをビルドするツールをIE（インターネットエクスプローラ アプリケーション キット）とモジラ（モジラ クライアント カスタマイゼーションキット）を例に対比させていた（※注：オペラにもウェブベースの同様のツール「オペラコンポーザー」が存在する）。これを使うことで、あらかじめプロキシーやメールサーバーの設定を済ませておいたり、独自のスキンやスタートスプラッシュ、組み込むコンポーネントの選択などを行える。

また、社内イントラネットのツールとしてXULを有効活用する提案があった。XULベースのアプリケーションならローカルで動作するので、何かのデータを読み込むフロントエンドを開発し、ソートなどの抽出処理をローカルで動作させることでネットワークの負荷を低減させたりするのも手だろうということだった。

企業導入に必要なアピール点として、サプライヤーの意図を受けないのも重要だとされていた。それはスパイウェアという観点でも、30年後にもこのソフトで作った書類が開けるかといった観点でも重要な点になる。ビジネスではすべてのものをコストとして換算できるが、結果としてオープンソースソフトの採用によってTCOを抑えられるのでは、という結論だ。ただしその一方で、運用責任の問題が解消されていない点が問題だとされている。これは先程のビジネスとしてオープンソースの成果を利用する企業の出現が必要だという点がもう一度繰り返された。

セキュリティに関しては電子政府などの推進に際して特に気にされている点だという話があった。とくにセキュリティで問題になるのは「パラサイト」（外部からのアタックではなく内部から情報が漏れてしまう）点。ブラウザーのセキュリティホールにはこういったパラサイト的なものも含まれるが、多くの目にコードが晒されるオープンソースのソフトであれば一定問題が見つからなければ安全と判断できるだろうとの見解だった。

またアカデミズムのように、反証を基にした安全性の論議が一般化する必要も提案されていた。現在、セキュリティの指摘を受けると動揺してしまう開発者がまだまだ多いが、実社会とオープンソースが結び付いてきた以上、欠点を指摘しない美徳とされた（セキュリティの重要性が考慮に入れられていない時代の）ハッカーの論理は、そろそろ変えていく必要があるだろうとのこと。その際に相手を貶していくやり方ではなく、アカデミズムのように一定の書式で指摘する方法が生れてくるだろうとのこと。

新機能の追加に対する慎重さや、問題の暴露による社会に対する悪影響の発生を起さないためのセキュリテイ専用連絡窓口の開設など、ベンダー側の努力も必要だろうという提案もあった。モジラにはバグジラがあるが、さて、あれがセキュリティに関する報告などに対し、有効に働いているかどうか。また、モジラのコードに関しては、ネットスケープ側で定期チェックが行なわれていることが言及されていた。

続いてモジラおよびオペラ関係者による、ブラウザー限定サイトに対する標準化活動に関する取り組みが紹介された。

日本の代表的なオペラ情報サイトであるMoonstone's Labratoryの発表によると、企業サイトで問題とされた大多数はブラウザ判別による除外（問題を把握したうちの43パーセント）および独自DynamicHTMLによるもの（15パーセント）など互換性に対する非配慮であり、個人サイトで問題になった大多数はHTMLやCSSの記述の問題（49パーセント）やブラウザー判別による除外（13パーセント）、コンテントタイプの記述ミス（13パーセント）、OperaのCSSに関するバグ（25パーセント）などで最後の1つを除けば技術不足や誤った知識によるものが原因とされている。

もじら組によれば、問題の指摘を行った際に起る反応は「次回の構築時に対応する」といったものが多く、これは公的機関など外注任せですぐに対応できる体制にないところの典型的な回答だという。逆に言えば標準化に対するリクエストさえクライアント側が出してくれば、外注が対応してくれる可能性が高いことも伺える。また個人ユーザからは「すべてのブラウザーで確認できるわけがない」として断わられたこともあるそうだ。これについてはいろいろ反論があると思いますが（￣△￣；。また、ブラウザーを限定することが当り前、対応ブラウザーさえ書いておけばいいという考え方が根強いことも紹介された。

これに対し、修正例の提示や典型的レイアウトのCSSでのテンプレート作り&公開といった普及活動、書籍やウェブ上などで誤った知識を流布している著者への啓蒙、発注側に対するウェブ上でできることできないことなどの知っておきたい知識の提示、ウェブの勉強する人向けの定番サイトの充実、などが今後の展望として紹介された。また、モジラやオペラに関する活動から標準化プロジェクトを独立させることが課題として挙げられた。

このほか客席からは、標準化を納得させるために、SEOや製作/管理コストへの影響を提案していく、UAごとの振り分けではなく標準対応と標準非対応で振り分けを行うようにスクリプトを変えるように企業に提案を行った、標準化に対応しやすいオーサリングツールとはどういうものかの例を提示していく&開発者にリクエストしていく、などの意見が紹介された。

今回の来場者はざっと見たところ150人程度。インスタントメッセンジャーを使った中継も合わせると、多くの人が参加したことになる。それだけこの分野の注目が高く、またビジネスなどに関わる緊急命題であることがよく理解できた。モジラには勢いがあるが、他のブラウザーからも負けずにいろんな提案が出てくるとこの分野は今後も発展していきそうだ。

えーっと、会場の片隅でXULコンテンスト参加作品の紹介が行なわれていた。Tabbrowser ExtensionsとMoz2chが高い評判を集めており、来場者からは「やっぱりこの2つが定番かねぇ」というような声が聞かれたことも報告しておこうかな、っと（￣△￣；。