Journal InTime

_ メモリスティックリーダライタ

を買ってから結婚すればよかった。

_ サティ

ひさびさにサティに行ったらたまたまバーゲンだった。どおりで人が多いわけだよ。

何も買うつもりなかったのにティーポットなどを購入。しかも値引き対象外:( でも元が安かったのでよしとする。

_ IMAPのtag

IMAPサーバを書こうかなと思ってRFC3501を眺めていると、RFC2060とtagの 仕様が微妙に変わっているのに気付いてしまった。

RFC2060:

tag             ::= 1*<any ATOM_CHAR except "+">

RFC3501:

tag             = 1*<any ASTRING-CHAR except "+">

要は`]'が許されるようになったらしいけど、そんなのtagに使ってうれしい?

うーん、Net::IMAP直さないといかんかなあ。とか言ってたら小人さんが 直してくれたり...しないだろうな。 まあ、クライアントはそんなtag使わなきゃいいわけだけど、サーバは そうはいかないか。何かいきなり萎えちゃったよ、とほほ。

_ 検索ベースのIMAPサーバ

とりあえず、アイデア(っていうほどたいしたものではない)だけメモしとこう。こうしとけば、だれか他の人が書いてくれるかもしれない。

• 何はなくともSEARCHを実装する。
• mailboxは基本的にINBOXだけ。代りにThunderbirdのSaved Search Folderを使う。
• とは言ってもTrashやDraftくらいは必要かもしれない。まあ仮想的に用意すればいいか。
• INBOXのメール一覧では、\Recentフラグが付いたメールだけ(あるいは1000件だけとか)を返す。
• Saved Search FolderがないMUA(ほとんど?)のために、サーバ側で Saved Search Folderを用意した方がいいかも。
• 最近検索した結果は、自動的に上記のServer Side Saved Search Folderにする。しかし、mailbox名が問題
• 手動でspamを学習させる時に類似文書検索が使えたら便利かなあ。 しかし、IMAPでそういうインタフェイスを提供するのは無理か。 Server Side Saved Search Folderの設定などと一緒にWebインタフェイス を用意するとか?
• 検索エンジンにはもちろんRastを使いたいが、属性の更新を効率よく 処理できるようにならないと辛そう。まあ、属性は自前でやる手もあるが。
• RSSも突っ込めると便利かも。あと、NetNewsとか。

morqを改造する、という手あるけど、たぶん大変な部分はmorqから流用できる部分じゃないんだよな。

_ Ajaxで「次へ」

検索サイトで「次へ」というリンクをたどるのがいつも億劫なのだが、最近流行のAjaxで何かできないだろうか。 アクセスキー用意するだけでも便利かもしれないけど、そもそも10件ずつとかで検索結果を表示すること自体、あまり必然性がないと思う。

たとえば、最初はブラウザのスクロールバーを表示させずに一画面で表示できる分だけ出力して、Ctrl-Dとかjとか押してくと必要な部分だけ取って来て表示を書きかえていくとか。 各検索語を座標に取った地図みたいなのを出して、文書を表すアイコンに カーソルを持ってくるとタイトルや概要がポップアップで出てくるとか。

_ チェーン調整

今日はホームセンターで22のソケットと割りピンを購入してチェーンの調整をした。

規定値は25mm〜40mmらしいけど、延びまくっていたのでだいたい30mmくらいに調整。目盛とネジ山の数を参考にだいたい左右を合わせたけど、いまいち自信がない。 割りピンはホームセンターにあった3x30だとちょっと長かったけど、まあ、いいか。

_ 大江戸Ruby会議06で発表してきた

大江戸Ruby会議06に参加してきたが、とても楽しかった。スタッフ・参加者のみなさんありがとうございました。

何となく技術よりのイベントなのかなと思っていたが、思ったよりエモーショナルな発表が多かったような気がする。 自分の発表は感動的なトークの後だときつい内容だったので、順番が最初の方*1でよかった。

• 発表資料

mlterm上のTextbringerでプレゼンしたのだが、事前のプロジェクタチェックでモードラインが切れてるのに気付いていなくて、本番中にウィンドウサイズの調整に手間取ってしまった。 普段タッチパッド使わないので…。

Vimmerばかりだったらどうしようかと思ったが、Emacsユーザが多数派（主観）でよかった。

後でいただいた質問の回答をいくつか。

• Q1. なぜ数ある実装方式の中でバッファギャップを採用したのか。

  A1. 行のリストみたいな方式だと、Rubyの場合たくさんオブジェクトができるのがつらいし、行をまたいだ検索の実装コストも実行コストも高くなりそうだから。 バッファギャップなら一つのStringオブジェクトで済むし、組み込みの検索機能が使える。 Stringはランダムアクセス向けの作りではないけど、Rubyで自前のデータ構造を作るよりは速い。

• Q2. どれくらい使えるのか。

  A2. メールの読み書き以外はTextbringerを使っている。 Textbringer自体もRubyモードを実装したあたりからほとんどTextbringerで書いているが、Textbringer::Windowあたりを壊すとまったく使えなくなるので一時的にVimを使ったりする。 環境EDITORもtextbringerにしている。

• Q3. MUAは本当に作るのか。

  A3. RubyKaigiまでに作りたい。 IMAPライブラリとかも前に自分で書いたので、簡単なものならすぐにできると思う。 問題はTextbringrのバックグラウンド処理APIをどうするかだけど、スレッド（将来はGuild?)＋Control.Invoke()/BeginInvoke()的なものはどうかなとか考えている（要はなるべく同期的に書きたい）。 Emacsの欠点はバックグラウンド処理がバッファに依存した設計になっているところだと思う（最近のEmacs知らないけど）ので、このあたりを上手く作れば差別化できるのではという目論見。

なお、ネットワーク応用通信研究所はこういう話に興味のある人を募集しています。 Vimmerでも大丈夫です。