最速インターフェース研究会

出先で回線が使えない可能性を考えて作った。
http://la.ma.la/misc/userjs/ldr_fake_offline_mode.user.js

:offlineで実行。:offline 20だと20件読み込み。適当な実装なので同期とかはない。

仕組みはこんな感じ

// 常にキャッシュを使う
Cache.prototype.check_expr = function(){return true};

// 設定変えて再描画
Config.use_autoreload = false;
Config.touch_when = "manual";
Config.view_mode = "flat";
Config.limit_subs = 100;
get_unread.cache.max = 500;

// 再描画
subs.update();

// reload無効化
Control.reload_subs = function(){}

// 全部先読み
Ordered.list.forEach(prefetch);

----
追記

最初にあげたバージョン、非表示状態のフィードも読み込もうとするので未読が多いと上手く動かないのとサーバー負荷が無駄に増える状態になってました。
インストール済みの人は更新をお願いします。

頑張って作ろうかと思ったら既にConfigLoaderというのが定義されてたからそれ使うだけで良かった。

Add HatenaStar

JSONをevalしないでクライアントサイドでパースしたほうが安全じゃない？というような話。
http://d.hatena.ne.jp/ku0522/20070927/1190868347

Greasemonkeyみたいに外部ドメインのデータ引っ張ってこれるとは限らないので、JSONPがあること自体は良いことだと思う。JSONPがあるのは設定不要で簡単に貼り付けられるようにするためだと思うけど、動的に取得するようになってるとWikiで挙動を変えられてしまうので危険だと思う。例えばJSONを出力する処理にバグがあった場合とか、凄く処理が重くなるセレクタとかを指定されるとか。あくまでコード生成の補助に使うぐらいがいいんじゃないかなあ、という気がする。

整形済みのソース。HatenaStar.js自体のロード完了を検知するのが面倒くさいのでタイマーで回した。

(function(){
    var l=function(src){
        var s=document.createElement('script');s.charset='utf-8';s.src=src;
        document.getElementsByTagName('head')[0].appendChild(s);
    };
    l("http://s.hatena.ne.jp/js/HatenaStar.js");
    var t = setInterval(function(){
        try{
            Hatena.Star.ConfigLoader.addEventListener('load', function(){
                new Hatena.Star.EntryLoader();
            });
            new Hatena.Star.ConfigLoader();
            clearInterval(t);
        } catch(e){}
    }, 100);
})();

9/15日にMozilla 24 出張Shibuya.js 24でしゃべってきました。
http://shibuyajs.org/articles/2007/08/24/Shibuya-js-24

資料はこちら。
http://ma.la/files/shibuya.js/mozilla24.html

JavaScriptでBloom　filterのデモ。今のところ実用性が無い。仕組みを理解するのには良いかも。
http://la.ma.la/misc/js/bloomfilter/

Bloom Filterについてはここら辺が詳しい。
http://chasen.org/~taku/blog/archives/2006/01/bloom_filter_1.html
http://ja.wikipedia.org/wiki/%E3%83%96%E3%83%AB%E3%83%BC%E3%83%A0%E3%83%95%E3%82%A3%E3%83%AB%E3%82%BF
http://dev.ariel-networks.com/modules/xfsection/article.php?articleid=18

以前書いたとおり、livedoor ReaderのFeed Discover APIの中で使っています。存在する可能性が著しく低いキーを大量に問い合わせる場合に有効だと思う。Squidで使われたりしてるみたいですね。

memcachedは存在するデータをキャッシュするのに使えるけれど、ヒットしないことを判別するためにキャッシュを作るようにしてしまうと大量のゴミクエリをキャッシュすることになってしまう。Bloom filterを使うとDBに問い合わせる前にキーが存在するかどうかをオンメモリでチェックすることができます。検索に応用したりもできるみたいで、シグネチャ法という全文検索の手法があります。CPANモジュールのText::Bloomというのがbloom filterを使った実装。古いのであんまり使えないと思うけど。

解説を読むと分かりますが、存在しないキーでもtrueを返す可能性があります。データをコンパクトにできる代わりに、正確じゃなかったりする。そういうアルゴリズムは面白いですね。

CDATA区域を二つに分けるのが正解。周知のために晒し上げ。
http://lowreal.net/logs/2005/07/07/2.html

例えばRSSフィードを作るときにCDATAを使っていてユーザーの入力したHTMLをそのまま入れてる場合に問題になるケースがあります。一ヶ月ぐらい前にIRCでそういう話になったときcho45がおしえてくれた。

cho45++