青空文庫とAmazon

　昔、青空文庫のテキストをビューアと一緒にアプリ化して配布するサイトを運営していた事がある。当時、ユーザーから直接あるいはblog等で間接的に指摘されていたのが、「作品を選ぶ判断材料が無い」という事。作家とタイトルがあるだけで、読んでみるまで作品の概要も評判も分からないのである。
　ダウンロード数でソートする程度の事はできていたが、さほどアクセス数の多くないサイトだったので、指標としては当てにならない。おそらく、作家の名前を聞いたことがある程度の理由でダウンロードされた作品がほとんどだろうと思う。

　今、不本意ながら自由に使える時間が倍増したので、この機会に青空文庫タイトルとAmazonをつなぐサービスを作ってみようと思う。ヒントになったのは、今春公開されたカーリルである。カーリルは、図書館横断検索を統一的で使いやすいインターフェースで提供すると同時に、Amazonの持っているイメージやレビューを表示してくれる。自分としては、Amazonのユーザーズレビューが、その本を借りて読むべきか否かを判断する上で大いに役に立っている。カーリル出現以前は、Amazonを見てから図書館のネットサービスで予約するという手順を踏んでいた。これをワンストップの使いやすいインターフェースで実現して見せたカーリルは、私にとって衝撃的だった。

　図書館の蔵書をwebで予約する人は、借りてみるまで自分が求めている本であるかどうかわからない。カーリルがその判断材料をAmazonに求めたように、青空文庫とAmazonとリンクしたサービスがあれば、大量の作品を目の前にして作品選択に迷う人の役に立つのではないかと思う。

FreeBSDからUbuntu

　先週末に自宅サーバのOSをFreeBSDからUbuntu Linux Serverに移行した。このサーバとして使っているFMV LOOX T70Hが素直かと思いきや意外と曲者で、思わぬところで落とし穴があった。

　移行の手順は大まかに、

1. 母艦のVMwareでLinuxを準備
2. LOOXのFreeBSDを外付けHDDにバックアップ
3. MondoRescueでVMwareからLOOXの内蔵HDDへarchive&restore

という３段階で行った。

1. 母艦のVMwareでLinuxを準備

　移行に先立ち、VMware上にUbuntu Serverをインストールしてデータの引越しをある程度進めておいた。rsyncでFreeBSDからLinuxに設定内容やデータをコピー。この段階は割と順調だった。

2. LOOXのFreeBSDを外付けHDDにバックアップ

　移行前のHDDの中身は、使っていなかったHDDを外付けして保存する事にしていた。シングルユーザモードで起動して、sysinstallで外付けHDDにパーティション切ってフォーマットが済んだらdump&restoreである。ところが、最近不安定なFreeBSD 8-STABLEがdump|restoreの最中に突然死してリブート。8.0-RELEASEになってから前触れなくリブートする事が月に数回起きていたが、dump | restoreしたら２回続けて昇天。ちっともstableじゃない8-STABLE。方針変更して8.0-RELEASEのLivefs CDからブートしてみることにした。
　Livefs ISOファイルを焼いたDVDで起動して、Fixitコンソールに入ってdump|resore、のはずだった。ところが、DVDから起動はするのだが、Livefsをマウントする段階でDVDドライブを見失う。DVDドライブが着脱式なのが関係していそうだが、解決法がすぐに見つからなかったので、またまた方針転換。USBメモリにFreeBSD 8.0-RELEASEをインストールして、ここから起動後にdump|restore。なんとか成功。

3. MondoRescueでVMwareからLOOXの内蔵HDDへarchive&restore

　次はLinuxの引越し。VMwareでmondoarchiveを使ってリカバリーISOイメージを作成。sambaで母艦に持ってきてDVDに焼いて、いざLOOXへ。ところが、LOOXのCPUであるPentiumMがPAE無しのため、PAE前提のUbuntu Serverのカーネルでは起動しない。VMwareの上でカーネルをPAE無しに入れ替えて、リカバリーISOイメージ作成、DVD書き込みをやり直した。
　さて、カーネルを入れ替えたおかげでリカバリーDVDで起動はするのだが、いざリカバリーという段階でDVDドライブを見失う。FreeBSDのLivefsと同様の症状らしい。こちらも方針変更して、mondoarchiveのバックアップ先をUSBメモリにしてみたが、こっちはLOOXに挿しても起動の初期段階で死んでしまう。状況はかえって悪くなった。しかたがないので、LOOXの内蔵HDDを外してVMwareに物理ドライブとして接続し、mondoarchiveで作ったリカバリーDVDからリストアした。さすがにVMwareでは素直に動く。
これでやっと引越し完了。HDDをLOOXに戻したら無事に起動した。

　予想していなかったトラブルは、

1. LOOX T70HではLivefs DVDが役に立たない
2. PentiumMはPAE無し
3. mondoarchiveは、動く環境が割と限られる。LVMにしたらリストア失敗。USBでもリストア失敗。

が痛かった。土曜の朝から初めて、終わったのは日曜の朝４時ころ。さすがに力尽きて、最終的な目的だったMotionのセットアップをする前に沈没。
　　

AutoItのScriptWriterが雲隠れ

　お気に入りの自動実行アプリ AutoItは最近バージョンアップが活発で、そのせいかインストールされるショートカットがちょっと変。AutoIt用にカスタマイズされたエディタSciTEと一緒にインストールされたScriptWriter(au3record.exe)という操作記録ツールがあるのだが、このショートカットがリンク切れ状態になってしまっている。AutoIt初心者はScriptWriterの吐くスクリプトをベースにして座標やウェイト長を調整するのがお勧めなのだが、ScriptWriterが無くては始まらない。

　SciTEのUpdate Historyによると、

• Removed au3record from the installer as this is now supplied by the Autoit3 installer.

という事なので、AutoIt本体と一緒にインストールされるらしいのだが、スタートメニューはやはりリンク切れ。どこかにあるはずと思って探したら、Extrasフォルダの下に置いてあった。スタートメニューからは、AutoIt v3⇒Extras⇒Browse ExtrasでExtrasフォルダを開いて、そのまた下のAu3Recordフォルダの中。3月7日にバージョンアップされたのに、まだ治って無かったよ。

RichTextBoxでスローダウン

　XMLで書いたスクリプトの指示に従ってシリアルポートを読み書きしつつ、内容をRichTextBoxに表示するC#のアプリを書いた。これを一晩中動かしていたら、見るも無残な劇遅になっていた。3台動かして3台とも劇重。タスクマネージャで見ると、起動時に70MB程度のメモリ使用量が250MBに増えている。
　どこかでメモリリークか？シリアルポート開きっぱなしで.NET Frameworkのバグでも踏んだかと思ったが、原因は表示用のRichTextBoxにあった。最大文字数がデフォルトの2G(21億)字のまま。全てのログを破棄せずに抱えたRichTextBoxが肥大化して、バッファ処理が通信速度について行けなくなったらしい。最大文字数を1M字に変えて解決。通信内容は全てlog4netでファイルに書いているので、表示は短くても構わないのだった。

Relaxerバグ修正

　二カ月前に指摘したW3C XML Schema変換に関するバグがようやく修正された。治るのを待っているわけにも行かず、自分用に俺パッチ作って既に解決済みだったので、もうどうでもいいって感じ。次に使うときは、RelaxerじゃなくてTrangで変換しよう。Relaxerの作者はRelaxer5というのを作ってるらしいけど、 RelaxerとかSmartDocが静かに死んでいく様を見てしまったので、よほど良い物でもない限り、手を出すことは無いだろう。

SmartDocサイト消滅

　成果物のドキュメント執筆にSmartDocを使っているのだが、生成されたドキュメントに挿入されているリンクをクリックしてぶったまげた。ドメイン失効でサイト無くなってるじゃんか。ついに作者にも見放されたか。真剣に乗り換え先を考えないといかんな。

log4netの出力を動的に

　VS2005のClickOnceで配布するアプリでlog4netを使うと、相対パスで指定したログファイルが奥深くに埋もれてしまう。実行時に指定してやればユーザが指定した場所に書けるんじゃないかとググッってみたら、ヒントが見つかった。設定ファイルの大部分をlog4net.cfgという名前で書いておいて、ファイル名だけを実行時に指定したらいいんだな。

　この時、appenderのファイル名を

<appender name="RollingLogFileAppender"
type="log4net.Appender.RollingFileAppender">
<param name="File" value="nul" />

のようにnulにしておけば、log4net.Config.XmlConfigurator.Configureを呼んだ直後の初期状態でログファイルの生成を抑止できる(unixでlog4jなら/dev/nullか？)。nul以外のファイル名を指定しちゃうと、どこかに0バイトのログファイルが生成されてしまうので注意。この後で、ログ出力が有効の場合にのみファイル名を設定してやれば、必要な時だけログを出力することができる。

public MyScriptForm()
{
InitializeComponent();
Properties.Settings appsettings =
new Properties.Settings();
if (appsettings.WriteEnabled)
{
setLogLocation(appsettings.OutputPath);
}
else
{
setLogLocation(null);
}
}

private void setLogLocation(string outputPath)
{
log4net.Config.XmlConfigurator.Configure(
new System.IO.FileInfo("log4net.cfg"));
if (outputPath != null)
{
if (!File.Exists(outputPath))
{
Directory.CreateDirectory(outputPath);
}
log4net.Repository.Hierarchy.Hierarchy hier =
(log4net.Repository.Hierarchy.Hierarchy)
log4net.LogManager.GetRepository();
if (hier != null)
{
log4net.Appender.FileAppender appender;
appender =
(log4net.Appender.FileAppender)
hier.GetLogger("MyScript",
hier.LoggerFactory).GetAppender(
"DebugLogFileAppender");
if (appender != null)
{
appender.File = outputPath +
Path.DirectorySeparatorChar + "debug.log";
appender.ActivateOptions();
}
}
}
...