2011年 01月 31日

gerry++

JSDeferred の setTimeout 版の効率あげた版

setTimeout() を毎回やると、ブラウザ内部でタイマーオブジェクトが大量にできるんだろうなー とは思いつつ、そんなのの効率化ってブラウザ側でやるべきことでしょ? という感じなのでナイーブな実装にしていたのだけど、一応タイマーをできるだけ作らないバージョンもつくってみた。けどやっぱあんまり意味なかった (Opera では意味あるかもしれない)

Deferred.next_default = function me (fun) {
	if (!me.nextTicks) me.nextTicks = [];
	if (!me.timer) {
		me.timer = setInterval(function () {
			if (me.nextTicks.length) {
				for (var i = 0, len = me.nextTicks.length; i < len; i++) {
					me.nextTicks[i].call();
				}
				me.nextTicks = me.nextTicks.slice(len);
			} else {
				clearInterval(me.timer);
				me.timer = null;
			}
		}, 1);
	}

	var d = new Deferred();
	me.nextTicks.push(d);
	if (fun) d.callback.ok = fun;
	return d;
};
2011年 01月 28日

gerry++

2011年 01月 27日

Plack 版の CocProxy

CocProxy という、HTTPレスポンスの一部をローカルファイルで置き換えるプロキシがあるのだけれど、それの Plack/Perl 版を書いてみた。Plack::App::Proxy は reverse proxy を想定していて普通の proxy としてそのまま使えるわけじゃなかった ($env->{'plack.proxy.url'} = $env->{REQUEST_URI} が必要) のと、PATH_INFO に REQUEST_URI がそのまんま入ってくる (よく追ってない) とか謎の挙動がありつつ、以下のような感じでうまくいった。(Twiggy で起動する必要あり)


2011年 01月 22日

MySQL 5.0 の TIMESTAMP 型の2038年問題 (インデックスを貼るだけでひけなくなる)

TIMESTAMP 型のカラムにインデックスはったら何もひけなくなるということに遭遇した。手元の MySQL 5.1.53 だと再現しないので、一部のバージョンにおけるバグかもしれない。2038年問題におけるX-dayは1/19なのに、なぜか 1/1 が終わった時点で invalid になっていた。面倒なのでよく調べていない……

Your MySQL connection id is 3495640
Server version: 5.0.22

(nobody@192.168.2.155) [log]> select * from log where created < '2038-01-02 00:00:01' limit 1;
Empty set, 2 warnings (0.02 sec)

(nobody@192.168.2.155) [log]> show warnings;
+---------+------+-------------------------------------------------------------------------------+
| Level   | Code | Message                                                                       |
+---------+------+-------------------------------------------------------------------------------+
| Warning | 1292 | Incorrect datetime value: '2038-01-02 00:00:01' for column 'created' at row 1 |
| Warning | 1292 | Incorrect datetime value: '2038-01-02 00:00:01' for column 'created' at row 1 |
+---------+------+-------------------------------------------------------------------------------+
2 rows in set (0.03 sec)
2011年 01月 20日

gerry++

2011年 01月 18日

Android の、こうであって欲しいところ:startActivityForResult のインターフェイス

なんかあの、startActivityForResult と onActivityResult による処理の分断感と、requestCode まわりの感じが気持ちわるくてしかたないので、以下のようなインターフェイスならいいのになあ……とよく思うんですが、こうなってないのはなんででしょうかね……

        startActivityForResult(intent, new ActivityResultHandler() {
            public void run (int resultCode, Intent data) {
                if (resultCode == RESULT_OK) {

                }
            }
        });

実装自体は簡単なんですが、Java は mix-in できないので使いにくいのですよね……

    interface ActivityResultHandler {
        void run (int resultCode, Intent data);
    }

    protected HashMap<Integer, ActivityResultHandler> mActivityResultHandlers = new HashMap<Integer, ActivityResultHandler>();
    protected void startActivityForResult(Intent intent, ActivityResultHandler handler) {
        int code = handler.hashCode();
        mActivityResultHandlers.put(code, handler);
        startActivityForResult(intent, code);
    }

    @Override
    protected void onActivityResult(final int requestCode, final int resultCode, final Intent data) {
        ActivityResultHandler handler = mActivityResultHandlers.remove(requestCode);
        handler.run(resultCode, data);
    }
2011年 01月 11日

gerry++

2011年 01月 05日

gerry++

2010年 12月 31日

gerry++