明日からちょっと来月頭まで音信普通不通になりに休暇で南極に行ってきます。南米最南端まで飛行機で行って、そこから「ザ・ワールド」という船に乗ってクルーズし、最後はホーン岬を回って帰ってくるというコース。ペンギンを撮るためにPENTAX K10Dを新調したので、電池を懐にいれて温めつつ行ってまいります。

ついでに、本日衝動買いでたまたま緊急入荷していたWiiを買った。荷物に余裕があれば持っていって船上でWiiスポーツダイエットにいそしもうかな。

追記 2/3:無事に帰ってきました。この世の果てのさらに向こう側というだけあって、幻想的かつペンギン超萌えな世界が広がっていました。これで7大陸全制覇だが、南極が観光旅行としては一番良かった。現地からupした写真を何枚かmixiに載せてあるが、整理したらちゃんとしたところに置いて、ここからもリンクします。

南極旅行記　写真集（抜粋)

slashmaster宛に謎のメールが届いた：

６月３０日

実は我が家でもミドリ亀ちゃんが卵を９個産みました。
一匹で飼っているのですが、この卵は有効でしょうか。
この卵の扱い方法を教えて！返事を待っています。

亀亀より

これは新手のspamなんだろうか？slashmasterはアドレス帳に入っていて誤送信する様な宛先ではないし、亀亀というのがぁゃιぃ。返答に期待してアドレスの有効性をチェックする系統のものだろうか。しかし、亀が無精卵を生んだりするのか、交尾から排卵まで期間が長いのかどうか知らないが、普通は単体で育てている亀が卵を生んでも子孫は生まれないだろう。

test.slashdot.jpのテスト、開始当初はチューニング不足でOOM状態でswap stormになり実質停止したりしたが、いまでは安定して動いている様だ。こまかい指摘は多数いただいているが、致命的なバグはいまのところ発見されてない。これから友達データも含めた新しいデータを移行する前に、各所に分散しているバグ報告をTODOの形でここにまとめる、随時更新する。

• アツイコメントのスラッシュボックスの中身がオカシイ? (#757145)
• コメント数が多すぎて分割される時、ネストだと切れ目がおかしい? (#757827)
• ユーザ設定で、トップページの設定を保存すると並び順が変わってしまう (#75682)
• 「ユーザスペース」スラッシュボックスで使えるタグが制限されるようになった。使えるタグを明記。自己紹介や署名欄も (#75682)
• コメントフィルタの整理・移行
• linuxkernelセクションのスラッシュボックスをlinuxセクション用に変更 → 移行スクリプトに組み入れ
• ケータイ版。現時点ではまだノータッチ
• サイドバーのチェック
• 記事本文の終わりに(none) -> 広告のテスト
• 空白のない長い文章に空白が強制挿入されるが、日本語はブラウザがやるので対象外に
• モデレーションの詳細以下の邦訳 (#756541以下のスレッド)
• FoFの邦訳 -> 再びストーリ立てて案を募集

• IDN未対応->「日本語.jp]へのリンク (test上のコメン ト)

• トピック増強。本家からいくつか持ってきたり、真面目なモノ以外には日記用に「エロ」を増やしたり、ついに鉄道をいれてもいいかな、と思ったり
• メッセージで発送されるメールのSubject:がMIME-encodedなUTF-8。これで間違いではないが、完璧にするならISO-2022-JPに (タレコミ)
• データ移行時に全角逆斜線が半角逆斜線に誤変換 (#758774)
• article.plで表示されるユーザプロファイルが不評？非表示に？

解決済：

• セクションページで左上のユーザ情報のリンクが/section/~foo/になっていて404 (タレコミ)
• タレコミページの連絡先欄に二重括弧 (タレコミ)
• Copyright表記の2005年対応 (test上のコメント)
• コメント設定の誤植：「スコアを表示しない (しきい値は適用さる」->「適用される」、「インデックスに溢れる」->「に漏れる 」or「インデックスモードへ移行」あたり (#756582)
• パスワード変更画面の誤植：「認証クッキーが無効なり」→「認証クッキーが無効になり」 (test上のコメント)
• ログイン設定のマシン種別が未訳 (#757549)
• 日記へのコメントだけウェブでメッセージが飛ばない? (#757719) →テンプレートがバグってて発送されてなかった
• 各Indexページの「もっと読む」のリンクがストーリーの所属セクションへのモノじゃない
• モデレーションの任意のスコア補正が設定できなくなっていたNoGoodさんの日記とタレコミ)→本家仕様でバリバリにハードコードされてたので改善 ([Slashdotjp-dev 303])
• M2の「see context」リンクが抜けてる? (test上のコメント)
• M2で初期状態ではラジオボタンが未選択(test上のコメント)
• 自身のユーザ情報のスラッシュボックスにメールアドレスが「非表示」設定でも表示される (#75682) →バグではなく仕様、が変更
• コメントのメッセージ：自分自身もしくは自分がACとしてコメントした場合は発送されない?　(タレコミ) →自分自身の場合発送されないのは仕様。ACが発送されないのはメッセージの設定にある「しきい値」が設定されてない場合のデフォルトが1だったから。0に変更
• delとinsタグを許可するタグのリストに追加。citeとdatetime属性をそれぞれ許可。(NoGoodさんの要望)
• firefoxで本来不要な横スクロールバーが出る (test上のコメント)
• アイコンを表示しない設定時のトピック表示 (#756781)
• 静的ページの「もっと読む」リンクが/slash/slash/風に間違ってる→解決、残ってるのは静的ページ再構築時に修正される
• 一部ユーザが日記があるにもかかわらずユーザ情報のページには「日記を書いてないと表示される」(タレコミ) →　要約として抽出される日記の一行目が短い場合のバグ。users.pl 1.8で修正。正規表現はパーザーになったつもりで分解していけば、いつかは理解できる。
• ライトモードで一部 white-on-white (#757357)→ IF user.light式で回避。CSSを使った抜本的対策が必要。が、ライトモードなUAはちゃんとCSSに対応してる？
• 掲載記事の時間が強制的に20分未来→すぐに記事が表示されない本家仕様(編集者からの指摘)、0秒未来に設定してたらperlのIFでは偽と判定されてしまう。Ruby慣れしすぎだ。
• 「公衆端末」の解説 →メインのログインフォームで解説：10分有効のクッキーがアクセスの度に期限更新
• 「公衆端末」チェック状態でログインに失敗しても、チェックが消えない
• 本家からSupercomputing, Math, Imput Devicesトピックもってくる
• ストーリー表示画面右上、ユーザボックスからユーザ情報へのリンクが間違い。 gSkin.rootdir -> constants.absolutedir
• 各セクション内のページで左上のロゴのリンクが各セクションのページをさしていたのが不評だったので、本当のトップページに変更
• 最大パスワード長が減った？ログインできない (#757193) →前から20文字だった。超初期に一時的に32文字と表示だけされていた可能性はアリ

ちなみに、友達データの公開を発表してからの縁切りは約80件で、全体の0.4%。2-3人がガバっと整理した分が大半の様だ。

Slashdot Japanでも掲載しているユニークなバナー広告でおなじみのTech総研で1年以上続けてきた「電網"Tech人"ニュースウォッチ」の連載を終了させてもらうことになった。そこで、これまではメールのみだった担当編集に一度は会いたい、ということで都内某所にあるTech総研編集部にお邪魔させていただいた。

結果、自分が大昔バイトしたり出入りしていた編集部と名のついたものとは違い、とても整然としていてシャキシャキと媒体が創造されていく雰囲気な素敵な編集部だった。寝袋がなかった! 太陽光でもみんな平気そうだった! しかも、訪ねていったら、メンバーがわらわらと集まってきて取り囲まれた。これは勝手にやめるから糾弾か、と思いきや、ものすごい熱烈歓迎で、就職祝いとして巨大なヒマワリの花束まで貰ってしまった。かなり感激。編集部の皆さん、更新前日の忙しい時にもかかわらず、ありがとうございました。

Tech総研は『エンジニアのための「いつかは転職」ブレーンサイト」をモットーとしているが、学生時代にもとても役に立った。他ではなかなか見れない各職種の給与水準やいろんな人の転職経験談は希望する職種を決める上でも参考になったし、よく特集される現場の心の叫びはスラッシュドットで日々みているものを補完してくれた。バナーも毎回楽しいし、たとえ転職する気がなくても読物として今後も楽しみたい。

連載自体は来月掲載分で最終回だが、6月のアレゲニュースウォッチ前半部が今日から掲載されている。今回のネタはピアス型USBメモリや.xxxドメインなど。金曜掲載の後半部ではTIEファイター型PCなどを扱っている。よろしく～

OliverはTech総研を応援しています。

Rammsteinのショーケースライブin川崎に行ってきた。一言でいえば「燃えた」。もう消防法に挑戦どころか完全に挑発モード。爆竹すら使えないといわれている会場であっただけに、どうなるか心配だったが、開演前に「心臓が弱い方、気の弱い方は...」というアナウンスがあった頃からドキドキワクワク。最初にちょっと爆竹があったあと、ずっとなにもなかったのでションボリしかけたが、4曲目「Feuer Frei!」で顔面装着型火焔放射機が登場。キターー状態に。それ以降はたびたび煙で舞台が見えない状態に。Rammsteinの本領発揮という感じだった。自分も超ハイテンション。家に帰ってから鼻をかんだら、ティッシュが真っ黒に。

演奏された曲：

1. Reise Reise
2. Links 234
3. Keine Lust
4. Feuer Frei!
5. Rein Raus
6. Morgenstern
7. Mein Teil
8. Stein um Stein
9. Du Riechst so Gut
10. Du hast
11. Sehnsucht
12. Amerika
13. Rammstein
14. Sonne
15. Ich will
16. Ohne Dich
17. Stripped

これで4500円というのはお買い得スギ。誘ってくれた友よ、ありがとう。

Hyper Estraierはパフォーマンス重視のDBMとして開発されているQDBMの作者による全文検索エンジン。同じ作者によるわかり書きを使った全文検索Estraierをn-gram方式に再実装したものを出発点とし、将来はP2Pによる分散検索も目標としている。ライセンスはLGPLで、特徴は：

• n-gram方式。しかし、キーを減らしたり検索性能をアップするためにいろいろ工夫している様子
• Cライブラリ＋サンプルアプリのコマンドラインツール
• 他の言語のバインディング(まだ)なし
• CGIもセットですぐ使えるレベルの高い完成度。ドキュメントもちゃんとしている

手元のamd64環境でビルドするにはMakefileに-fPICの追加など、ちょっと手を加える必要があった。Perlバインディングが存在しないので、テストは属性値を含めるEstraierの「文書ドラフト」形式にデータをファイルシステム上に書きだし、付属のCで書かれたコマンドラインツールでindex登録および検索することによってベンチマークを取った。

Journals Indexing

10000 entries: 0m27sec (27MB)
+10000 entries: 0m28sec
=================================
20000 entries: 0m55sec (47MB)
+10000 entries: 0m35sec
=================================
30000 entries: 1m30sec (75MB)
+10000 entries: 0m36sec
=================================
40000 entries: 2m06sec (105MB)
+10000 entries: 0m41sec
=================================
50000 entries: 2m47sec (138MB)
+10000 entries: 0m43sec (174MB)
+10000 entries: 0m47sec (209MB)
+10000 entries: 0m50sec (245MB)
+10000 entries: 0m57sec (284MB)
+10000 entries: 1m02sec (323MB)
+10000 entries: 1m07sec (362MB)
+10000 entries: 1m19sec (403MB)
+10000 entries: 1m30sec (448MB)
+10000 entries: 1m28sec (492MB)
+10000 entries: 1m36sec (541MB)
+10000 entries: 1m42sec (590MB)
+02783 entries: 0m57sec (599MB)
==================================
162783 entries: 16m45sec (599MB) [累計]
162783 entries: 11m46sec (436MB) [まとめて登録]

Journals search "foo"
10000 entries: 0.020sec (9 hits)
20000 entries: 0.025sec (17 hits)
30000 entries; 0.030sec (26 hits)
40000 entries: 0.033sec (32 hits)
50000 entries: 0.035sec (37 hits)
60000 entries: 0.042sec (45 htis)
70000 entries: 0.051sec (55 htis)
80000 entries: 0.058sec (64 htis)
90000 entries: 0.065sec (72 htis)
100000 entries: 0.072sec (87 htis)
110000 entries: 0.080sec (96 htis)
120000 entries: 0.087sec (102 htis)
130000 entries: 0.089sec (110 htis)
140000 entries: 0.092sec (116 htis)
150000 entries: 0.100sec (125 htis)
160000 entries: 0.109sec (138 htis)
162783 entries: 0.109sec (139 hits)

速度低下はかなりリニアで、とても素直な挙動といえる。indexのサイズも元のデータが693MBなので、かなり優秀。成長させていったindexに対してestcmd optimizeを実行したところ、300MBまで縮んだ。

全体的に以前にいちど全文検索エンジンを作ったことのある作者の経験が活かされ、ドキュメントやツールなど、かなり質の高いものに仕上っている。他言語バインディングはないが、それは必要となれば比較的簡単に作れそうだし、速攻でいまのNamazu版を置き換えた感じのSlashcodeと統合されていない並行システムが容易に作れそうだ。

今後の検証課題はQDBMの排他処理とNFS経由で複数のホストがindexを使った場合の挙動。

Rast.pmの作者でもあるYappoさんのアドバイスに従い、Rastをちょっとチューンしてベンチマークを取り直した。

今回もベンチマークは1万エントリをindexし、その後に1万エントリづつ追加するのに必要な時間を計測し、index増大に伴う速度の低下を検証した。前回との変更点はsync_threshold_charsを100万に設定したことのみ。未設定時の場合は10万なので、ちょうとシンクロ回数が10分の1になるはずだ。

Journals indexing:
10000 entries: 0m49sec
+10000 entries: 1m26sec
=========================
20000 entries: 2m15sec
+10000 entries: 2m00sec
=========================
30000 entries: 4m15sec
+10000 entries: 2m11sec
=========================
40000 entries: 6m26sec
+10000 entries: 2m41sec
=========================
50000 entries: 9m07sec
+10000 entries: 3m14sec
+10000 entries: 3m46sec
+10000 entries: 4m24sec
+10000 entries: 4m58sec
+10000 entries: 5m58sec
+10000 entries: 6m21sec
(中略。いっきに作成)
162783 entries: 282m15sec (711MB)

ディスク上のDBへのsync回数を減らすことで実時間ベースのパフォーマンスは劇的にアップした。この範囲で5-8倍であるというのは、ストレートにsync回数が減ったのが響いていると思われる。この設定での使用メモリは約300MB。しかし、テストで16万エントリをいっきに登録するテストをしたところ、10万エントリを越えたあたりからパフォーマンスは劇的に低下していった。

チューンした結果、数万エントリではindex作り直しでも十分に実用になるが、数十万エントリにはまだまだ届かない、というのがいまのところの結論だ。バックエンドに使っているBerkley DBへsyncする段階が明らかにボトルネックとなっている。一回一回のsyncがそれだけ時間がかかる、ということはエントリをひとつだけ追加するのでもかなりの時間がかかってしまう、ということであり、初期index作成時だけの問題ではない。

明日のLinux Conference 2005にてRastの作者が講演するので、行けたらここらへんをコメントとしてぶつけてみようかな。明後日の全文検索BOFにもなるべく行きたい。

以前から友達認定時に「友達リストはプライベートなものではありません」と告知していたとおり、数日中に公開ベータテストを始めるSlashcode 2.5ベースのテストシステムではテストデータを取る時点の友達データが公開される。想いを恥しがる理由はなにもなく、逆に胸を張っていいものだが、念のために「一般公開間近」と警告しておく。

「やばーっ」と思い、脊髄反射でせっかくの縁を切ってしまう前に、もう一度考えてみよう。そのリストが公開されることによって、本当に自身が不利益を被るのかどうか。消してしまう前に「ま、いっか」と考えてみた場合、どうなるかの思考実験をしてみる事をオススメする。友達にされている当人はほぼ確実に嬉しく感じるものだし、自分が熱心に読むほど素晴らしい日記に巡りあう機会を他のユーザから奪ってしまうのは、もったいなくないか? 自分がイイと思っている人のオススメの日記を知りたくはないか?

Friend or Foeシステムには賛否両論があり、以前に何度も議論が水かけ論にまで発展し、/.jp独自の制限を導入するアイディアもあったが、いずれも決定的なものとはいえず、制限の必要性についても自分は説得されていない。FoFというシステムに関する断片的な情報しかなく、さまざまな間違ったイメージが先行していた時の議論なので、まずはFoFシステムを体験してみた上で、しばらくテスト後に再度、邦訳も含めて議論したい。

なお、現時点で行っている「テストを知っている人だけのクローズドベータ」でもテストデータを取った時点での友達データが公開されているが、もし一般公開された時に消されているものがあったら、「それはみてない」という事にするのというのがテスターとしての礼儀である事をテスターの皆様には忘れないでいただきたい。

RastはIPAの平成16年度オープンソフトウェア活用基盤整備事業の一環としてRubyを筆頭にいろいろなオープンソースの港であるNaClで開発されている全文検索エンジン。ライセンスはGPL2だ。特徴は：

• n-gram式で高精度
• コマンドラインのツールを含まない純粋なライブラリ
• C、Ruby, Perl, PHPのバインディングが存在
• APIはとてもシンプルで簡単に使える
• バックエンドはBerkley DBM

Slashcode的にはPerlバインディングが存在するのがポイントが高い。が、Berkley DBMがバックエンドということは排他処理の問題で実質的にNFSでindexを共有して複数のフロントエンドサーバーが並列に検索する処理分散の方法が取れないし、複数のサーバーからindexに書き込むというのはもっと危険だ。もし使うなら、Ruby APIでも使って、簡単な常駐型のXML-RPCサーバでも立てる必要アリ

最終的には約1万のストーリー、30万の日記、70万のコメントが検索対象になるので、パフォーマンス的には初期のIndex作成が現実的な時間で作成でき、検索と単エントリの登録とがまあまあの時間(0.5秒いないとか)でできればいい。

ベンチマークとしてはindexerの性能を見るために、日記エントリを1万個づつ登録していき、かかった時間とindexサイズを求め、同じ検索を成長していくindexにたいして発行した。

Rastの場合：

Journals indexing:

10000 entries: 2m39sec
+10000 entries: 7m24sec
========================
20000 entries: 10m06sec (117MB)
+10000 entries: 13m03sec
========================
30000 entries: 23m09sec (163MB)
+10000 entries: 24m12sec
========================
40000 entries: 47m21sec (206MB)
(中断)

Journals search "foo"
10000 entries 0.04sec (17hits)
20000 entries 0.03sec (34hits)
30000 entries 0.07sec-0.12sec (55hits)
40000 entries 0.07sec-0.13sec (75hits)

index成長率も検索時間の悪化も悪くはない感じだが、いかんせindex作成時間がエントリ数増加にともない激しく延びていくので、とてもじゃないが数十万の文書をindexする気になれない。1万のストーリーだけなら、APIのシンプルさからRastを使うのだがなぁ。