ちょっと数日だけ国内旅行する機会があったのだが、 フォーラムの保守とか休むわけにいかないので、 何とかモバイル環境を確保しようとするわけだが、 その昔はモデム接続しかなかったので、とにかくモジュラーケーブルを繋ぐための道具であるとか、 場合によってはカプラを持ち運ぶなんてこともあった。 いつの時代だ。 これが、携帯電話という便利なものが普及したおかげで、 DoPaというサービスを使って接続することができるようになって、 ノートpcを持ち運べば、まさにどこでも作業できるような環境になったわけだが、 最近getしたのがAirH"である。 ちょっと速度が遅いのが気になるが、 固定料金だから接続時間が気にならないというのは猛烈なメリットで、 極端な話、数MBのデータでも時間をかけてゆっくり転送してよければ…という状況になったわけである。

※ DoPa: NTT DoCoMo の携帯電話を使ったパケット通信サービスで、 転送パケット量に対して課金されるため、 接続したままでも実際にパケットが流れなければ料金はかからないのが特徴。 速度は 9600bps。

ただ、接続したままで使いすぎると、やはりバッテリーという壁があるわけで、 ACが使えない状況ではちょっと節約しながら使おうとして、 すぐに切ってしまったりする。

こうなるとDoPaも契約しなくていいか、という話になりそうなものだが、 今回行った所がたまたま Air H"のサポートエリアから外れていて、 DoPaも念の為持って行ったのが幸いしたのである。 パケット通信に対応したエリアは、 iモードの普及にあわせて急速に拡大しているようだ。 こんな山の中で大丈夫かというような状況下でもDoPaは使えたりする。 もっとも、Air H" の方も、思ったよりはエリアが広くて安定していたのが印象的だったが。 どちらかというと東京よりも速度が出るような気もしたが、これは気のせいかもしれない。

※ Air H": 最近は Air Edge と書くのですか?

旅行に出る前は、@niftyのログの整理とかしてから行ったものだが、 常時接続できるようになると、これをついサボってしまう。 最近、PostgreSQLを使ってログ管理してみようかと、 マジで考え始めたりしているので、 すると、会議室の発言ごとにファイルを分けて保存するというのも意味があるのだが、 どうもpcとかWindowsという環境だと、 数万個とか数十万個のファイルを作るのが何となくイヤな予感がして抵抗感もあるので、 結局全部ごっそりと同じファイルにappendした状態で持っていたりする。 その結果、 さっき来た数行のメールを確認するために10MBのテキストファイルを開くというようなとんでもない…という程でもないのだが、 何となくあまり面白くない状況になってしまうのだ。 だったら、2か月分程度を残して「昔のメール」を別ファイルにしておけば、 もっと効率的に作業できるのだが…というのが、 「ログの整理」の具体的な内容なのである。

データをバックアップする時も、 更新されているファイルだけバックアップしているつもりなのだが、 ファイルの最後にちょっとだけ追加しても、 全く変更していないその前に残っている10MBのテキストを同時にバックアップしてしまうという、 念には念を入れたと言えば分からなくもないが、 やはりちょっと無駄な気がしないでもない。 だいたい、バックアップの時間もやけにかかったりする。 ファイルの差分だけ保存する方法もありそうだが、 あまりややこしいことをすると復元時に訳が分からなくなりそうだし、 結局どのあたりで妥協するかというと、 私の場合どうもずぼらな方向に偏っているような気がするのだ。

§

コマンドライン(に限らない?)でプログラムを開発する時に 便利なツールが make である。 古典的なツールだから解説するまでもないと思うが、 基本は簡単で、ソースファイルと生成物の時刻を比較して、 ソースファイルの方が新しい場合には指定したコマンドを実行して、 生成物を作り直すという仕組みである。 例えば、C言語でプログラムを作る場合、 Cのソースファイルをコンパイルして.oという拡張子の付いたオブジェクトファイルを生成する、 という処理が基本になる。 オブジェクトファイルが更新されたら、 全体のリンクも自動的に処理する、というような感じだ。

make 以外に最近使われているツールとしては、ant というものがある。 なぜ make があるのに ant なのか、 という理由は ant のサイトにしっかり説明されているのでここにはあえて書かない。

ところで、よくあるシチュエーションなのだが、 個人でサイトを公開する場合、 サイト上で直接ページを編集するというのは稀なことで、 手元で一旦サイトと同じ構成を作り、 それが出来上がったらサーバに転送する、 という感じの処理を行うはずである。

サイトに含まれているページの数が結構あったりすると、 ごく一部を修正したり追加した場合に全ファイルをサーバに転送するのは無駄だ。 更新したものだけを転送すればよい。 ということは、make のアイデアでこの処理を実現できそうだが、 ここで問題は、比較したいファイルが手元ではなくサーバにあるということである。 もちろん、サーバに存在するファイルの作成(更新)時刻と、 手元にあるファイルの時刻を比較すればいいだけの話だが、 サーバ上のファイルの時刻を全て確認するという処理は、結構重いのである。 できればそういうことはしたくない。

make で同じことをしたいなら、どうすればよいか。 サーバにファイルを転送した場合に、 何かその時刻を意味するオブジェクトを生成してしまえばいいかもしれない。

私のサイトでは perl を使っている。 多分、ちょっと気の利いたフリーのftp転送ソフトなら、 ファイルの時刻を比較して、更新されたものだけを転送する機能があると思うのだが、 実は ftp の転送処理を、 自前で作成したものを使って処理しているのである。 具体的には、指定ディレクトリ下にあるファイルから、 まだ転送していないものをピックアップして、 それらを指定したサーバにftpで転送するという処理になる。 これをperlで実現するのだ。 実は「perlで」というのは正確ではない。 perl で行っているのは ftp のスクリプトを生成するという処理であり、 ftp の転送処理そのものは外部コマンドを呼び出しているのである。 perl の機能だけで ftp を実現することも可能だが、 ftp のスクリプトを生成するのはさらに簡単なので、 つい安易な手段に走ってしまうのである。 昔、ファイルの削除を行うのに、 del コマンドを羅列したファイルを作っておいて実行する話を紹介したが、あれと同じノリなのである。

幸い、Windows であれ UNIX であれ、 余計なことをしなくてよければ、 コマンドラインから ftp を実行する手順は全く同じで済む。 ftp で実行するスクリプトを ftpscript とかいうファイルにしておいて、 ftp -n < ftpscript というコマンドで一発okである。

※ パスワードを指定するあたりでちょっとセキュリティ的に気になる。

§

では、このperlスクリプトは、更新されたファイルをどうやって判定しているのだろうか。 実は、転送したファイルの転送時刻を全て記録しているのだ。 実際に記録している内容は List 1 のような感じになる。 つまり、 処理を行うための perl スクリプトの中から require 等で読み込むだけでいいようにしてある。 タブ区切りか何かでファイル名と時刻情報だけ書いておけばよさそうなものだが、 そのデータを読み込むのが面倒…って程でもないが、 ちょっと工夫のベクトルがあっち向いているという感じで、 時刻情報を書き込む処理に工夫したのである。

※ これ自体を perl スクリプトの一部として処理可能なのである。

---- List 1 (perlスクリプトの作った送信履歴) ----

$transfered{"./INDEX.HTM"} = 1004642724;
$transfered{"./d200110.htm"} = 1004642428;
$transfered{"./images/20011011.png"} = 1002769766;
$transfered{"./images/20011003.png"} = 1002163052;
$transfered{"./d200109.htm"} = 1002027464;

---- List 1 end ----

この perl スクリプトには結構便利な機能がある。 もし全ファイルをあえて転送したいと思ったら、 単に過去の送信履歴を消してしまえばいいのだ。 機能でも何でもないか。

サイト管理で問題になりがちなのは、 全体の構成を修正したときの後始末である。 うまく処理しないと、 リンク切れ状態のファイルが奇妙な位置に残ってしまったりするものだ。 特に、ディレクトリがたくさんある構成で、 多数のファイルを移動したりすると話がややこしくなる可能性が高い。 この時に、ファイルをコピーして タイムスタンプが更新されればよいのだが、 移動しただけではファイルの更新時刻が変化しないようなシステムだと、 makeのアイデアで処理し損ねる危険があるからである。

その点、どのファイルをいつ転送したか覚えているような perl スクリプトは、 ファイルを単に移動しただけでも、 今まで転送していなかった位置にファイルが出現したら、 それは明らかに転送対象になる。 これはある意味安全な処理だが、 サーバから見れば、新規ファイルが転送されたのと同じことだから、 元のファイルがゴミで残りかねないという、 新しい問題が生まれることになる。

理論的に最も美しいのは、 ローカルのファイルを移動したのなら、 サーバに置かれているファイルも移動する、というような対称性を持った処理だ。 ただ、これは確かに美しいのだが、 プログラムで実現するのは結構面倒なのである。 そのようなコマンドが実行されたことをアプリケーションレベルで判断することが、 ちょっと難しいからだ。

※ まずファイルのリスト (ls) を取得して比較し、 違いに注目する、という手がある。

現実的にこういう場面でどうすれば確実なのかというと、 サーバのデータを全て削除してから、もう一度全部転送してしまうというものである。 最近は接続速度が早くなったので、数MB程度のデータならあまり気にならない。 しかし、自宅は実はフレッツISDNなので、数十MB程度になってくると、 ちょっと気乗りしなかったりする。 現実は、まだ少し厳しい。

※ Bフレッツにしたので速度の問題は殆どなくなった。 毎回全部転送してもいい位だ。 でも、ここに書いてある処理は健在だし、 今このページを更新するのにも使っている。