2004年 12月 12日

ua.indexOf("MSIE") != -1 ?

UA 文字列を Javascript から得るにあたり検索をかけてみたのだけど、UA 文字列にある文字列 (eg. “MSIE”) があるか調べるときに String.prototype.indexOf の結果が -1 であるかを調べているのが多かった。これはやっぱ String.prototype.match だと遅いとかそういう問題があるからなのだろうか……なんかダサいので今回自分は String.prototype.match を使ったけど、どうなんだろ。

if (navigator.userAgent.indexOf("MSIE") != -1)
// do something for MSIE
if (navigator.userAgent.match(/MSIE/))
// do something for MSIE

さらに && とか使おうとすると演算子の優先順位 (よく忘れる) とか考えることになって面倒臭い……

code をクライアント側で着色

pre に現れるコードを Javascript で着色 (Javascript でやってるのはマークアップ) してみる。重い?

少し前からこれがやってみたかったので class 属性に使用してる言語を書いていたりした。言語ごとにトークンを使いわけたようと思ってたわけだけど、実際そこまでやるのってどうなのよ、とか思い始めた。そのうちやってみて、いけそうだったら採用してみよう。

現状でもかなり重い気が……長くとれるトークンを増やせば (ループ量が減って) 軽くなるかもしれないけど微妙。実際一文字ずつループまわしてるからなぁ。やりすぎか。

Ruby と ECMAScript は別のトークンテーブル使うようにしてみた。別にパースしてるわけじゃない (スキャンだけ) なので微妙にアレな状況が既にいくつか思いつくわけですが……例えば式展開の引数で括ってるクオーテーションつかっちゃうとかが絶対おかしくなる。

それとループ回数を減らすために /[a-z][a-z0-9]*/i は identifer ってことにしてスキップしてる。

Lisp と XML もすっごい適当に加えた。

サンプル 重いので移した。

正規表現はブラウザ毎の違いが殆どない気もする。気付いてないだけかもしれないけど。

FF で右クリックから View Selection Source すると内部 DOM の内容もソースとして出てくるのが役に立った……

そもそもスキャナの実装が激しく間違ってたので修正。根本的な部分を変えたのでバグがあるかもしれない。

Audioscrobbler で他人のやつ混ざる

Audioscrobbler で最近 Recent Tracks に聞いてない曲が混ざることがある。バンプ が車輪の唄のシングルカットしてたなんてそもそも知らないのに、それのカップリングのやつが Recent Tracks に混ざっていたりする。

無作為に混ざっているわけじゃないらしく?同じアーティスト聞いてると混ざるみたい?