mizzy.org

このブログではタグづけなんかをしてるわけですが、ひとりでタグづけしてても、なんか虚しいんですよね。

なので、タグをdel.icio.usやtechnorati.comと繋げてみることにしました。各エントリの下の方で、タグごとにdel.icio.usやtechnorati.comにリンクしてます。なんか見づらい気がするけど、あとで考えよう。

ここを見てくださっている方が、更に関連情報を辿りたい、って時には便利になるような気がしないでもないです。

それから、Blog Hackers Conference 2005に行きます。このエントリとは関係ないですが、独立したエントリ立てるほどでもないので。

del.icio.usを使いやすくしようという目論見で開発中のツールですが、セッションまわりで意図した動作になっていなかったので微修正。サンプルとソース。

「使いやすく」とは言っても、何が不満で、どうしたいのかを整理していなかったので、ちょっと整理してみます。その方が、今後の開発の方向性が見えやすいかな、と。

まず不満な点は、「登録はしやすくていいけど、後から参照しづらい。」ってとこですね。自分が登録したブックマークを参照しようとすると、

1. ページをめくる。
2. タグで絞り込む。
3. 検索する。

といったあたりが主な方法かと。で、これらの方法には以下の不満があったりします。

1. 前後にしか移動できない。最初や最後、任意のページに飛べるといいのに。
2. タグが多くなってくると、目的のタグを探すのがめんどう。画面スクロールさせないといけないし。
3. 検索はなるべくなら、最後の手段にしてあまり使いたくない。検索せずに目的のブックマークに到達できるのが理想。

（もしかして俺が使い方わかってないだけ？もっと便利な使い方をご存知の方は、ぜひご教授下さい。）

で、次にどうしたいのか、という話になるわけですが、当たり前ですがこれらの不満を解消したい、ってことですね。つまり、

1. ページ移動にもっと幅を持たせて、任意のページに飛びやすくする。
2. 目的のタグを見つけやすいインターフェースの実装。
3. 検索も当然できる。ただし、最後の手段。

といった形にしたい、と。更にプラスして、キーボードショートカットで操作できたりとか、他にも便利な機能があれば実装したいな、と。

要するに、del.icio.usをベースにして、（俺にとって）究極のオンラインブックマークを作りたい、というのが野望です。世の中には様々なブックマークツールがありますが、どれも一長一短があって絞りきれなくて、今は色んなところにブックマークが分散した状態となってしまっています。この状況を打破すべく、「これさえあればOK」みたいのを作りたいな、と。さて、どこまでできることやら。飽きっぽいので、ある程度技術的好奇心が満たされたあたりで、満足して投げ出しちゃうんですよね、いつも。

前回は、del.icio.usを使いやすくするための、Firefoxサイドバーを作ろうと試みたのですが、ものすごく中途半端な状態で放置するはめになりました。敗因は、「俺はブラウザの機能としてのサイドバーが嫌い」ということを忘れていたから、ですね。ブラウザのメイン画面が狭くなるのでいやなんですよ。自分で使う気がないものを作ったって、いいものになるわけがない。

で、今回は自分で使いたくなるようなものをちゃんと作ろう、ってことで作ってみました。 サンプルはこちら。で、ソースはこちら。

サンプルを試してみよう、という方は、パスワードの取り扱いにご注意下さい。セッションとひもづけて、こちらのサーバに保存してますので。一応暗号化して保存してますし、ブラウザ経由では見えないようにしていますが、できれば捨てパスワードに変更してから試して頂いて、その後元のパスワードに戻す、というのがよろしいかと。またはソースをお持ち帰り頂いて、ご自身で設置して頂くとか。

Firefox 1.0.4(Win)でしか試していません。IE6はエラーが出ます。あと、Firefoxでもエラーが出て、del.icio.usからデータを取得できていないことがあります。原因不明。

Spurlの方が自分用オンラインブックマークとして使いやすい、と前に書いた気がしますが、SpurlBarはレスポンスが悪いんですよね。特に、関連するタグを取得する時。それに、SpurlBarは俺が嫌いなFirefoxサイドバーだったりするし、My spurlの使い勝手はSpurlBarに及ばないし。それにSpurlはAPIがない。2月末ぐらいにAPIについて問い合わせたら、「あと3,4週間でフルAPI提供できるぜ」と返事が来たものの、いまだAPIは提供されていないし。

なので、これを作ったのを機に、del.icio.usに復帰しようかな、と思ってます。今のままだと、登録データが増えてくると最初の待ち時間が長くなるので、そのあたりの解決策も考えないといけないですね。

bloglinesモバイルゲートウェイを久々にアップデート。

• マルチユーザ版
• シングルユーザ版

うたかた - scatterbrain - いつでもどこでもなんでも巡回にて、「未読をクリアする機能があると更にスバラシイかも」というお言葉を頂きまして、俺自身もその機能があった方がいいかなぁ、と薄々感じてはいたので、実装してみました。

記事表示画面の一番下に、「このフィードの記事を全て既読にする」というリンクを表示するようになってます。

既読にした直後にも、既読にする前の記事が表示されてしまいますが、記事を読んでから既読にするまでの間に、更に新着記事があったりすると、その記事まで既読にされてしまうので、こういった仕様になってます。

記事を取得した時刻を記録して、それより以前の記事だけ既読にする、ってことができればいいのですが、Bloglinse APIではその様な機能がないんですよね。

Sack of AjaxというJavascriptライブラリがあるんですね。Simple AJAX Code Kitの略だそうです。

同じ様なajax Javascriptライブラリのprototype.js（厳密にはprototyps.jsは、ajaxだけのライブラリではないんですけどね）と比較してみると、prototype.jsでは

new Ajax.Updater(
    'id', 
    '/url',
    { 
      parameters: value,
      onLoading: function(request){loading()} 
    });

となるコードが、

var mydata = value;
ajax = new sack('/url');
ajax.element = 'id';
ajax.onLoading = function(){loading()};
ajax.runAjax(mydata);

といった形で書けるようです。これはresponseTextを直接特定のエレメントにはめ込む例ですね。

responseTextを一旦変数に入れて何かしたい場合は、「Catalystでajax - 補足」で触れた例を使うと、prototype.jsでは、

new Ajax.Request(
    '/deislde/index.cgi',
    {
      method: 'GET',
      onComplete: function(request){
        eval('tagsListObj = ' +  request.responseText);
	displayTags();
      }
    });

というコードが、Sackの方では

ajax = new sack('/delside/index.cgi');
ajax.method = 'GET';
var response = ajax.response;
ajax.onCompletion = function() {
		        eval('tagsListObj = ' +  response);
		        displayTags();
                    };
ajax.runAjax();

といった感じになるようです。（ここで挙げたコードは、たぶんこうだろうというのを書いただけで、実際には試していませんです。）

prototypeでは、オブジェクトをnewすると同時に必要なパラメータを全部与えて即実行、という感じですが、Sackではオブジェクトをnewしてから、必要なパラメータを1つづつセットして、任意のタイミングで実行、という感じですね。

俺はどちらかというと、Sackの方が好みなんですが、prototypeの方はフォームデータをシリアライズするメソッドなどがあって便利なので、両方組み合わせるとより快適ににajaxできるんではないでしょうか。

taggingプラグインをアップデート。

storyサブルーチンで、meta-tagsを抜き出すルーチンを自前で書いていたのですが、metaプラグインが$meta::tagsという変数に入れてくれてるので、それを利用するようにしました。なので、コードが少しすっきり。

以前はtaggingプラグインがmetaプラグインより前に呼び出される必要があったのですが、この修正により、逆にmetaプラグインよりも後に呼び出されるようにしないと、正常に動作しなくなりました。ご利用頂いている方は、ご注意下さい。

taggingプラグインをアップデート。させざきさんのご要望により、storyフレーバでtag毎のリンクを表示できるようにしました。

リンクを表示したい位置に、$tagging::tags_in_this と入れてください。各エントリの右下にある、「tags: ...」の様な感じで表示されます。（「tags:」という文字はプラグインは出力しないので、自分で好きな文字を入れてください。）

おそらく、metaプラグインよりも前に読み込まれないと、うまく動作しないと思いますので、「01tagging」みたいなファイル名にして、metaよりも先に読み込まれるようにして下さい。

させざきさん、ご要望どおりのものになってますでしょうか？「思ってたのと違う」とか「ここはこうしてほしい」とかありましたら、お知らせ下さい。

permalinkは変わらないからこそpermalinkなわけですが、事情があってpermalinkを変更せざるを得ないこともあると思います。

そこで、permalink変更後に古いpermalinkにアクセスがあった場合、自動的に新しいpermalinkへリダイレクトするようなプラグインを作ってみました。redirect_permalinkプラグイン

permalinkが変わるといっても、どんな場合でも対応できるわけではなく、ファイル名が変わらない場合のみ有効です。例えば、このサイトの場合、古いpermalink http://mizzy.org/web/ajaxWebMail02.htmlが新しいpermalink http://mizzy.org/program/ajaxWebMail02.htmlに変更されたとします。太字の部分（ディレクトリ）が変更されていますが、ファイル名ajaxWebMail02は変更されていません。

この状態で古いpermalink（存在しないpermalink）にアクセスすると、自動的に新しい方へリダイレクトされるのが分かるかと思います。

想定している用途としては、カテゴリ構成を見直す場合、ですね。ファイル名を変更してしまうと、古いものと新しいものを自動的に関連付けるのが難しいので、現状では対応できませんが、プラグイン中に古いファイル名と新しいファイル名のマッピングを記述することで、対応できるようにしたいな、と考えていたりします。

このプラグイン、blosxom.cgi本体の修正も必要です。406行目あたりの、

    # Plugins: Last
    foreach my $plugin ( @plugins ) { $plugins{$plugin} > 0 and $plugin->can('last')
    and $entries = $plugin->last() }

という記述を、

    # Plugins: Last
    foreach my $plugin ( @plugins ) { $plugins{$plugin} > 0 and $plugin->can('last')
    and $entries = $plugin->last($ne) }

と修正します。本当はblosxom.cgi本体の修正は、最終手段にしたかったのですが、指定されたpermalinkが見つかったどうかを判断する方法が、これ以外は思いつきませんでした…

せっかく作ったものの、自分では使うことはないかも。カテゴリ構成を見直す必要がないように、taggingプラグインを作ったので。

そろそろ自分が作ったプラグインを一度整理しないとなぁ…

前回触れて以来放置していたajaxなウェブメールですが、約束どおりサンプルを公開します。guest/guestでログインして下さい。

といっても、まだ全然完成ではないです。現状どんな感じかを箇条書きにしてみます。

• IMAPでメールサーバと通信します。
• 画面左はフォルダ表示。フォルダをクリックすることで開いたり閉じたりできます。
• 画面右上サマリのページ切り替えは← →キーで行います。→で次へ、←で前へ。2ページ分先読みしていますので、先読みが完了していれば、瞬時に切り替わりますが、先読みが追いついていないと、ちょっと待たされます。
• subjectクリックでメッセージ表示。単にIMAPで取得したものをそのまま表示してるだけですので、Base64エンコードされているものは、エンコードされたまま表示されます。日本語以外のマルチバイト文字はたぶん表示されないでしょう。
• ajaxなのでメッセージも先読みすべきなんでしょうが、まだ未実装です。これから。
• フォルダペインとサマリペインの適当なところをクリックすると、各ペインがフォーカスされます。（枠がグレーでハイライトされます。）といっても、現状は何も意味がありません。今後すべてキーボードで操作できる様にしたいと思っているのですが、そのためには操作対象がフォルダなのかサマリなのかを明確にする必要があるため、そのための布石です。
• emacsと同様にCtrl + x, oでフォーカスの移動ができます。Wanderlustライクな操作性目指してます。
• spaceキーでメッセージをスクロール、backspaceで逆スクロールします。
• まともなエラーハンドリングをしてませんので、Server Errorが出ることがよくあります。

基本的にウェブメールに感じるストレスは、「レスポンス」と「操作性」に大別できるかと思うのですが、俺が目指すのは「操作性」に関するストレスの軽減です。レスポンスはウェブメールである以上、ある程度はしかたないかな、と。といっても、レスポンスを全く考慮していないわけじゃなく、サマリやメッセージの先読みでレスポンス向上も目指してますが、「どこまで先読みすべきか」という判断が難しいと思います。IMAPサーバ上にあるメールを全部先読みしてしまえば、レスポンスは最速になりますが、現実的ではないですしね。ですので、レスポンスについてはあまり追求せずに、ある程度のところで妥協する様な感じになるかと。

Javascriptがローカルファイルのread/writeに対応していれば、サマリ情報をすべてローカルにキャッシュすることで、かなりのレスポンス向上が見込めるんですけどねぇ。

あと、IMAPなので、CGIベースだとアクセスするたびにIMAPコネクションを張りなおすので、このあたりも何とかしたいですね。

blosxomのエントリをRastで検索するためのプラグイン、rastプラグインを修正しました。修正点は以下の通りです。

• 検索インデックスを作る際、ファイルの内容からタグを消去するようにした。
• Rast->createでpreserve_text => 1を指定する様にした。
• 検索結果表示の際、今まではヒットしたエントリの内容を全て表示していたが、検索語の周辺のテキストのみ表示する様にした。（これはRastが元々持っている機能を使ってます。）
• 検索結果表示の際、検索語を強調表示するようにした。

どんな感じで表示されるかご覧になりたい方は、左メニューの「search」から検索してみて下さい。これでだいぶ実用的になってきた気がする。