早速 Windows 7 Beta に触る機会があったのですけど、ほとんど Vista と変わっていなくて残念な感じでした。
細かいユーザビリティの修正点はあれど、どんどん Mac や Linux の GUI のアイディアを拝借しているなぁ、という感触。
UAC の「Windows 自体の設定を変更する場合のみ警告しない・その他のインストールやレジストリエディタなどのみ表示する」機能（デフォルト）はなかなか良い線いってると思いました。反面、無効化の作業がカジュアルになっていて若干の不安を覚えたり。

　＊

Mac Box Set、そう来たか。
この時期にそのセットということは、Snow Leopard の発売が遅れると見た。
そして Mac mini はナシ…。

パナソニック、HD-PLCの技術が「IEEE P1901」で認定

これは、勝ち組・・・か？

アップル最後のMacworld基調講演まもなく開始、日本時間7日午前2時から

＜脳内プラン＞
1. 基調講演で新 Mac mini が発表
2. Apple Store「We'll back soon」
3. しばらくして、バラシ記事がアップされる
4. メモリの増設が簡単になったことが判明
5. BTO なしの Mac mini ＋メモリ＋ディスプレイ＋Bluetooth キーボード＋マウスを安いところで購入
6. Enjoy my New Mac Life!

という妄想に浸りつつ、寝る。

Google Apps で管理しているメールの場合、DNS に

v=spf1 include:aspmx.googlemail.com ~all

のような TXT レコードを設定するわけですが、この場合、ISP の SMTP サーバ経由で独自ドメインのメールを送信すると SoftFail となってしまい好ましくありません。

次のように設定を確認します。
XXX.so-net.ne.jp は、自分の使いたい SMTP サーバに対応する自分のメールアドレスのドメイン部です。

$ dig -t txt XXX.so-net.ne.jp

...
;; ANSWER SECTION:
XXX.so-net.ne.jp. XXXX IN TXT "v=spf1 include:a.spf.so-net.ne.jp include:b.spf.so-net.ne.jp include:c.spf.so-net.ne.jp include:d.spf.so-net.ne.jp ?all"
...

So-net は SPF に対応しているので、これらの include 設定を追加すれば Pass することができます。

v=spf1 include:aspmx.googlemail.com include:a.spf.so-net.ne.jp include:b.spf.so-net.ne.jp include:c.spf.so-net.ne.jp include:d.spf.so-net.ne.jp ~all

とか、アルファブロガーさん的なタイトルにしてみたりして(笑)。

えっと、FSWiki の検索の遅さにウンザリして、検索時の動作をプロファイルしたよ。Perl のバージョンは 5.8.8。

テスト環境では、およそ 800 ページ・200 行/ページ（同一内容）の日本語・英語混在文章を対象にした。
さらに、その中の 1 ページにだけ「My Search Keyword」というキーワードを書く。

この状態で、「My Search Keyword」というキーワードで AND 検索を行った時の結果がこちら。
（なお、pagelist.cache は生成済みの状態です。）

================================================
Total Elapsed Time = 8.040466 Seconds
  User+System Time = 8.040466 Seconds
Exclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c  Name
 80.5   6.478  6.476   3216   0.0020 0.0020  Jcode::getcode
 5.75   0.462  0.397   3216   0.0001 0.0001  Jcode::tr
 5.67   0.456  0.456   4818   0.0001 0.0001  Encode::XS::encode
 2.61   0.210  0.213    807   0.0003 0.0003  Wiki::DefaultStorage::get_page
 1.26   0.101  6.640   3216   0.0000 0.0021  Jcode::set
 1.26   0.101  0.101   9648   0.0000 0.0000  Encode::XS::decode
... (以下略)
================================================

ここから、ページのエンコードを自動判定する Jcode::getcode に時間を食っていることが分かります。

Jcode::getcode は、Jcode のオブジェクト生成時にエンコードを指定しない場合に呼び出されます。
英語・日本語混在時など、エンコードの判定が難しい場合は特に処理が長引く傾向にあります。
現在のところ、FSWiki のページデータのエンコードは EUC-JP で固定なので、これを決め打てばこのルーチンはまるまる起動されないことになるでしょう。

ということで、こんな感じで修正します（行番号は 3.6.3-dev3 を基準）。

================================================
[plugin/search/SearchHandler.pm] の 66 行目:
- my $page2 = ($word =~ /[A-Za-z]/) ? Jcode->new($page)->tr('a-z','A-Z') : undef;
+ my $page2 = ($word =~ /[A-Za-z]/) ? Jcode->new($page, 'EUC-JP')->tr('a-z','A-Z') : undef;
================================================

上記修正後、改めてプロファイリングすると…

================================================
Total Elapsed Time = 2.024995 Seconds
  User+System Time = 2.024995 Seconds
Exclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c  Name
 47.5   0.962  0.937   3216   0.0003 0.0003  Jcode::tr
 22.0   0.446  0.446   4818   0.0001 0.0001  Encode::XS::encode
 9.93   0.201  0.201   9648   0.0000 0.0000  Encode::XS::decode
 4.94   0.100  0.093    807   0.0001 0.0001  Wiki::DefaultStorage::get_page
 2.52   0.051  0.077   1615   0.0000 0.0000  CGI::cookie
 2.47   0.050  0.050   3238   0.0000 0.0000  CGI::Util::rearrange
... (以下略)
================================================

ということで、6 秒以上も高速化に成功！　正月から目出度いですね。
みんなも試してみてねー。早くならなかったらゴメンヨ

　＊

訂正(20:44): 修正後のプロファイリングの結果、違うものを掲載してしまっていたので差し替えました。
（間違えて掲載していたものでは、一時的に data ディレクトリを /dev/shm に置いていたので、Wiki::DefaultStorage::get_page が異常に速いことになっていました）

追記(20:48): どうせ EUC-JP 決め打ちなら Jcode 使わなくてもいいじゃん、という気もしてきた...。