とある開発でCodeIgniterのUploadクラスを使っていたのですが、
アップロードされたファイルに対して、許可する拡張子を画像＋その他拡張子（例えばzipとかtxtとか）に設定すると、

「許可されていない拡張子です」

というエラーがでてアップロードされません。こんなコードで発覚。
CIのバージョンは1.7.1です。

$config['allowed_types'] = ‘gif|jpg|png|zip|txt’;

// その他config設定は省略

$this->load->library(‘upload’, $config);

$this->upload->do_upload();

こう書くと、画像以外のzipファイルをアップロードしたときにはうまくアップロードされません。
でも、$config['allowed_types']の項目は必須設定です。

「う～ん、なんでかなぁ」と思いながらソースを読んでいたら、

system/libraries/Upload.php line:566くらい

// Images get some additional checks
if (in_array($val, $image_types))
{
　　if (getimagesize($this->file_temp) === FALSE)
　　{
　　　　return FALSE;
　　}
}

と、こんな記述を発見。ちなみに$image_typesには画像拡張子の配列が、$valにはallowed_typesで設定した拡張子（|で分割されています）
が入っています。

これだと、allowed_typesの中に画像系の拡張子が入っていると全てgetimagesize()が実行されます。
で、画像ファイル以外なら当然FALSEが返ります。その結果、アップロードは失敗。

これだと困るので、以下にように追記したらうまく動きました。

// Images get some additional checks
// 画像系の拡張子で、かつアップロードされたファイルの拡張子の末尾が画像系拡張子であればチェック
if (in_array($val, $image_types) && strpos(substr($this->file_ext, 0), $val) !== FALSE)
{
　　if (getimagesize($this->file_temp) === FALSE)
　　{
　　　　return FALSE;
　　}
}

「strpos(substr($this->file_ext, 0), $val) !== FALSE」

とすることで、アップロードされたファイルの拡張子もチェックし、TRUEならgetimagesize()やってくれ、ってことです。
$this->file_extにはドットを含む拡張子の情報が入っているので、substrで1文字目をカットしてます。

セキュリティ的にどうなのかと言われるとアレですが、そもそも画像以外をアップロードさせるアプリケーションはそれだけリスクが高まるので、仕方無いですかね。

私は恒久的に使うのでコアに追記しましたが、疑り深い方はMY_Upload.phpなどでオーバーライドしたほうがいいかもです。

どうブランチ切ったか？　どこからどこまでマージした？　このタグはいつのスナップショット？
その時その時はきちんと名前付けやコメント付けをやってるつもりでも、後から見直してみると「ダメだ・・・このリポジトリは腐ってる・・・」とため息をつくことになるのは、僕だけなんでしょうか（笑）

ので、「とりあえず図にしてみればいいんじゃないかな？」と安直に思ったんですが、MS Wordとかで描くのはつまらない。マウスはなるべく触りたくないし、手で図オブジェクトを操作するのは必ずミステークの原因になるのは目に見えてるし。
大体そういうのって、誰かがツール作ってそうだなぁとも思ったんですが、どうもググっても見つからない。うーん。

だんだん考えるのもめんどくさくなってきて、
「とりあえずGraphViz使えばいいんじゃね？」
という結論にたどり着きました。

コードと図のサンプルはこちら。

digraph repositoryTree {
subgraph cluster_trunk {
fillcolor = “#00DDFF”;
style = filled;
label = “trunk”;
r381 [ style = filled ];
r537 [ style = filled ];
r541 [ style = filled ];

r381 -> r537;
r537 -> r541;
}

subgraph cluster_branches {
fillcolor = “#FF8888″;
style = filled;
label = “branches”;
subgraph cluster_dev_ktai {
fillcolor = “#FFFF00″;
style = filled;
label = “dev_ktai”
r382 [ style = filled ];
r538 [ style = filled ];
r542 [ style = filled ];

r382 -> r538;
r538 -> r542;
}
}

r381 -> r382 [ headlabel = "ブランチ作成" fontsize = 8 fontcolor = "#FF0000" ];
r537 -> r538 [ headlabel = "merge" fontsize = 8 fontcolor = "#0000FF" ];
r541 -> r542 [ headlabel = "merge" fontsize = 8 fontcolor = "#0000FF" ];
}

おっ、意外と見やすい・・・と思う。うん。

個人的にはこれで満足。dotファイル書くのは面倒かもしれないけど、ある程度下地できたらコピペでOKだし。
ちなみに、もうちょっと大きい例はこんな感じ。(ウチのとあるリポジトリから。気まずい部分は黒く塗りつぶしてます)

ちょっとゴチャついてますが、慣れるとどのブランチがどれにマージされてるかなどが1〜2ステップで分かるようになります。
結構いいと思うんだけど、どうかなー。

あと頑張れば自動生成できそうな予感。誰か作ってないかなぁ。

既出かな？

$(function(){

alert($($($($($($($(‘#box’).get()).get()).get()).get()).get()).get()));

});

さて、結果はHTML Elementでしょうか？jQueryオブジェクトでしょうか？

答え：どうでもいい（笑）

一応、jQueryオブジェクトです。

var IE = /*@cc_on!@*/false;

とかやる方法ですね。

ただ、条件付きコンパイルは遅くなるだとか（信憑性は不明ですが）聞いたので使ってませんでした。

で、タイトルの方法。こう書くそうです。

var IE = !+”\v1″;

これで、IEはtrue,それ以外はfalseとなります（Opera,Safari,Firefox,Chromeで検証）。

swfObject.jsのソースを読んでたらこんなことしてるもんだから、もとネタを見たらちゃんと解説もしてありました。ちょろっと見たことを書いてみます。

→もとネタ　http://webreflection.blogspot.com/2009/01/32-bytes-to-know-if-your-browser-is-ie.html

どうやら、\vは通常のブラウザはvertical space（改行つきスペース？）の文字として認識するようで、

var IE = !(+

1

)

と認識するようですね。で、1の否定で0だからfalse。うん、納得。

しかし、IEは\vは文字列として認識するようで、

var IE = !(+v)

カッコ内の結果をisNaNしてtrueになるようです。

こんなのよく考えたなぁ、と関心しながら自分のフレームワークに取り込みました。

indexOfでuserAgent判定してたから、その分早くなったかなぁ。

・・・でもこれってJScriptの解釈のせいなのかな？IE9からできなかったりして。

そうなったら元に戻すしかないね。

もちろん、JScriptのエンジン自体が遅いからなのですが、それ以外にもちょっとしたことで速度が改善したりします。

特に私が感じたのは、「NodeList」のループの部分です。

var list = document.getElementsByTagName(‘p’);

for (var i = 0; i < list.length; i++) {

// do something

};

と書くことが多いかと思います。しかし、これは遅いです。

var list = document.getElementsByTagName(‘p’), len = list.length;

for (var i = 0; i < len; i++) {

// do something

};

これだと数倍早く動きます。600回くらいのループで検証しました（内部処理は++countくらいで）が、

前者はIE6で約500ms、後者だと20数msでループが完了しました。

NodeListはSnapShotではなくLiveなものだから、ループの際に逐一「.length」の変化を見てるのかな？

もしくはNodeList.lengthのアクセス自体が遅いのか。

どちらかはわかりませんが、とにかくループ前にNodeListの長さを変数に格納してループすると

早くなるようです。

「数msくらい気にしない」、もしくは「IEはこんなもん」と思うのならさほど気にしなくてもよさそうですが、検索が遅いとその後の処理も遅くなってしまいますよね。

※どうもセレクタ検索を書くと速度のチューニングにハマって仕事にならないですね。

とりあえずトータルではjQueryより早ければいいかな。

addEventListenerがattachEventだったりgetAttribute(‘className’)だったりnew ActiveXObjectだったりで・・・。

「Firefoxだけで動けばいい」という開発だったら工数は3分の1になりそうな感じです（ライブラリ未使用で）。

とはいえ、最近はIEの挙動不審が可愛く思えてきました。

「手間のかかる子ほど可愛い」とはよく言ったものですが、

ここまで手間がかかると逆に面白いくらいです。

もしもこの世界にIEしかなかったとしたら、それはそれで面白いことになりそうな気がしますね。

JavaScriptの至上命題は「クロスブラウザ」、これに尽きます。

いろいろと動くアプリケーションは簡単に設計できますが、「どのブラウザでも動く」アプリケーションは難しい。

本当に難しい。canvasなんて使った日にはもうお手上げでしょうか。

「IEの実装差分をどれだけ吸収できるか」が良いJavaScripterなのかもしれません。

・・・さすがにIE5とかは手がつけられませんが（笑）

IEだけ動かない、というケースには慣れっこですが（笑）、Chromeだけ動かないのは少し驚きました。

var e = hogehogeGetElement();

var native = e.hugahuga();

みたいなコードが動かなくて困りました。他のブラウザでは全部動いているのに・・・。

何がダメなんだろう、と試行錯誤の末、変数名を変えたら動いた。

var n = e.hugahuga();

「native」ってChromeでは予約語なのかな？この変数を定義すると動かないんですよね。

ちょっと稀な経験をしてしまいました。

DOCTYPEスイッチだとか、いろいろな要因で後方互換モードになってしまうのですが、ここいらで簡単にチェックできる方法があるのでご紹介したいと思います。

javascript:alert(document.compatMode);

こんなJavaScriptをロケーションバーに打ち込んでみてください。ダイアログが出てきます。

CSS1Compat

もしくは、

backCompat

なんてアラーとが出ますね。「CSS1Compat」なら標準モード、「backCompat」なら後方互換モードでレンダリングされている、という感じです。

最近のモダンブラウザなら大概はCSS1Compatでしょうが、IE6等でレイアウトが決まらないときにはチェックしてみるのもいいかも知れませんね。

・・・知ったからどうなの？というのは別問題ですが＞＜参考までに。

みなさんは普段どうやられているのかわかりませんが、要素elmを取ったとして、widthの値を数値で取る時、

var width = parseInt(elm.style.width)

と私はやります。書籍では、

var width = eval(elm.style.width.replace(‘px’, ”))

ってやってた。う～ん、まぁこの方法もアリだとは思うんですけど。

前者だとisNaNのチェックが必要になる分手間かな、とも思ったのですが、後者は結局undefinedのチェックをしないといけないわけで。どっちも一緒かもしれないですね。

時間があったので1000回繰り返す速度計測してみた。どうでもいいだろうけど。

window.onload = function() {
var div = document.getElementById(‘test’), w, w2;
var st = (new Date()).getTime();
for (var i = 0; i < 1000; i++) {
w = parseInt(div.style.width);
w = (isNaN(w)) ? div.style.width : w;
}
var ed = (new Date()).getTime();
var time = ed – st;
alert(‘result : ‘ + w + ‘ , type : ‘ + typeof w + ‘ , time : ‘ + time);
var st2 = (new Date()).getTime();
for (var i = 0; i < 1000; i++) {
w2 = eval(div.style.width.replace(‘px’, ”));
w2 = (typeof w2 == ‘undefined’) ? ” : w2;
}
var ed2 = (new Date()).getTime();
var time2 = ed2 – st2;
alert(‘result2 : ‘ + w2 + ‘ , type : ‘ + typeof w2 + ‘ , time : ‘ + time2);
}

どっちも無ければ空値を返すようにしました。結果は表にするのも面倒なので大体の平均値を。

Firefox3.5   前者　：　6～8ms　、　後者　：　9～14ms

IE8              前者　：　15～16ms(max 31ms)　、　後者　：　15～16ms(max 31ms)

２つしかやってないけど、ややparseIntの方が早いかな？IEはどっちでも同じみたい。意味不明。

好みの問題だと言えばそうかもしれませんが、コンパイラを起動させるevalはあまり使うべきではないかと思います、個人的に。evalなんてresponseTextをJSONに変換する時くらいしか使わないけどなぁ。セキュリティ面でもよろしくない、と「JavaScript:The Good Parts」でも書かれてたし。

parseIntも遅いだろうけど、eval + String.replace()よりは早いってことかな。IE以外は。

CSSセットや値の取得なんて一番頻繁にやる部分だからできるだけ高速化しておきたいところですね。

実際は時間が1時間も無いため、具体的に突っ込んで読書を進めていくことはできないため、読書会の展望や進め方、各都市での開催予定について、お話します。

CakePHPなSymfonyなどの他フレームワーク使いの方々も振るってご参加ください。他のフレームワークを勉強することで、色々な考え方やアイディアも浮かんでくるんではないでしょうか？

セミナー時間割表
http://www.ospn.jp/osc2009-nagoya/modules/eventrsv/?id=1&noform=1

セミナー会場
http://maps.google.co.jp/maps/ms?ie=UTF8&hl=ja&msa=0&msid=108784144899608752188.0004497afc6c98eded884&ll=35.141739,136.928444&spn=0.012283,0.017166&z=15&iwloc=0004497b2056b8feb2e1f&source=embed

参加費：無料

CodeIgniter読書会ML
http://groups.google.co.jp/group/codeigniter-reading

アマゾンのCodeIgniter徹底入門（￥3990）
http://www.amazon.co.jp/dp/4798116769/