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