たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能!
先日のブラウザー勉強会で吾郷さんにお会いした際に、JavaScriptには言語の仕様として「例外がどこから投げられたのか」を知る為の仕組みが無いので独自のフレームワークを作る時に困ったという話を伺った。オレ標準JavaScript勉強会で何話せばいいか困ってた所だったので、それをネタに発表させてもらう事にした。
改めてECMAScriptの仕様書を確認してみたけど、確かに3rd Editionと5th Editionでは、例外オブジェクトの機能としてはError.prototype.name
とError.prototype.message
しか定義されていなかった(あとはconstructor
とかtoString()
とかその程度)。Wikipedia(英語の方)のECMAScriptの記事によるとECMAScript 3rd EditionはJavaScript 1.5とJScript 5.5の共通部分を抜き出す形で策定されたようで、実装してない方のIEに合わせてこうなったのか?とも思ったけど、調べてみたらJavaScript 1.5の頃はMozillaもError.prototype.stack
はサポートしてなかった。それ以降にMozillaが独自に拡張した箇所ということのようだ。でも今回調べた限りではOperaもChromeもError.prototype.stack
をサポートしていた(Operaの場合はこれに加えて、少しフォーマットが違うスタックトレースをError.prototype.stacktrace
でも取得できる、ということをedvakfさんに教えていただいた)。メジャーなJavaScript実行環境でこれに対応してないのはIE(IE9PP3を含む)くらいのようだ……と思ったらSafari(Windows版)もサポートしていなかった。
吾郷さんのそれやUxUのようにデバッグを支援するためのフレームワークでは、スタックトレースは欠かせない要素だ。将来のECMAScriptの仕様に取り込まれてくれればいいのになあ、と思う。
勉強会ではせがわようすけさんに突っ込まれたけど、セキュリティのためにはなるべくこういう情報は出さない方がいいものらしい。しかし自分はスタックトレースの何がまずいのかがよく分かっていない。会場では「例えばスタックトレースでスクリプトのURLの中にセッションIDが含まれていたらセッションハイジャックされてしまう危険性がある」という例を教えていただいたけれども、それでもまだピンと来ていなかった。
さらにツッコミを受けたことで「なるほど、クロスドメインの制約を突破されてしまう」という事が問題なのだと分かった。ただ、実際にそれが問題になるケースってほんとにあるのかな? という疑問はまだ残っている。
分かりやすい話として、通常のXMLHttpRequestやiframeでは、別ドメインのドキュメントを読み込む事ができない・読み込んだとしてもその内容にスクリプトからアクセスすることはできない。
var iframe = document.createElement('iframe');
iframe.setAttribute('src', 'http://www.google.co.jp');
document.body.appendChild(iframe);
window.setTimeout(function() {
try{
alert(iframe.contentDocument.body);
}
catch(e){
alert(e);
}
}, 3000);
例えばこういうのは、Error: Permission denied for <http://piro.sakura.ne.jp> to get property HTMLDocument.body from <http://www.google.co.jp>.と言われてエラーになる。しかしスタックトレースにエラー行の詳細な情報が含まれていると、
try {
document.write('<script type="text/javascript" src="http://www.google.co.jp/" async="false" defer="false"></script>');
}
catch(e) {
var contentsFragment = e.stack;
}
とか
try {
var script = document.createElement('script');
script.setAttribute('type', 'text/javascript');
script.setAttribute('src', 'http://www.google.co.jp/');
script.setAttribute('async', 'false');
script.setAttribute('defer', 'false');
document.body.appendChild(script);
}
catch(e) {
var contentsFragment = e.stack;
}
とか
// window.onerrorはECMAScriptの仕様にはない独自拡張
window.onerror = function(aMessage, aSource, aLineNumber) {
// ここでaMessage, aSourceから情報を取れる可能性がある
}
var script = document.createElement('script');
script.setAttribute('type', 'text/javascript');
script.setAttribute('src', 'http://www.google.co.jp/');
script.setAttribute('async', 'false');
script.setAttribute('defer', 'false');
document.body.appendChild(script);
という風にして、別ドメインのドキュメントの内容を部分的にとはいえ読み取れてしまう可能性がある、というわけだ。特に3番目のwindow.onerrorを使う例はMFSA 2010-47: エラーメッセージのスクリプトファイル名からのクロスサイトデータ漏えいで実際に脆弱性になっていたことが確認されていて、既に修正されている。
なお、実際に現行バージョンのFirefox・Opera・Chromeで試してみたところ、1番目・2番目のtry-catchを使った例ではそもそも例外を例外として(そもそも、エラーが発生したのかどうかすら)捕捉できなかったので、今の所問題にはならない。ただ、今は問題にならなくても、今後登場するJavaScriptの実装ではこういう場合でも情報を取れるようになっている可能性はあるので、将来的に脆弱性の原因になるかもしれないという警告は確かにアリだとは思う。という所までは何とか理解できた。
ブラウザのレベルでは、クロスドメインやクロスオリジンになる時だけは例外を出さないとか詳細な情報を出さないとか、そういう対応の仕方はあるだろうけれども、「ECMAScript」の仕様でそこに言及するのは変だろうなあ。というややこしい事情を勘案すると、もう丸ごと全部仕様からドロップしてしまえという判断になるんかなあ。
10分プログラミング - hogehogeを見て、10分でコーディング|プログラミングに自信があるやつこい!!に挑戦してみました。
結果。コーディング(と検証)だけで6分くらいかかりました。しかもエレガントでもなんでもありません。
function Cards() {
}
Cards.prototype = {
deal : function(aPlayers, aDeck)
{
var result = [];
for (var i = 0; i < aPlayers; i++)
result.push('');
aDeck
.split('')
.slice(0, aDeck.length - (aDeck.length % aPlayers))
.forEach(function(aCard, aIndex) {
result[aIndex % aPlayers] += aCard;
});
return result;
}
};
var c = new Cards();
alert(c.deal(4, "123123123"));
クラス名がどうとか書いてあったから馬鹿正直にそれに従ってしまったし。
追記。いかん、人数よりカード枚数が少ないときの考慮が足りてなかった。修正した。
PHPとかerbのようなテンプレートをJavaScriptで。という話に書いたやつの続き。
大切な事なので3回言います。
<% for (var i = 0; i < 3; i++) { %>
今日は<%= today %>です。
<% } %>
オーケー?
こういう文字列をテンプレートとして解釈したい場面は多分よくあると思う。この例だと、today
という変数をどっか外部から与えて値を埋め込むことになる。で、この変数をどうやって渡したらええねん、と。
グローバル変数をがんがんに使って構わないのであれば、先にグローバル変数としてtoday
を定義しておけばいい。eval()
で実行されるコードの中からも普通に参照できる。
しかしアドオンのコードのように、個々のグローバル関数やグローバル変数の寿命が長い事が予想されるスクリプトでは、この手は使えない。
this.
を付けるparseTemplate()
の仕様としてはあくまで「書かれたコード片は第2引数で渡されたオブジェクトをthisとして実行されます」という風にしておいて、テンプレート風に書かれている方の文字列内のJavaScriptコード片では必ずthis.today
という風に書くようにする、という方法もある。
しかしいちいちthis.
を付けるのは面倒だし、そもそも僕がこのような記法を知ったきっかけであるERBでは、self.
なんて書く必要がなかった。同じような物は同じように使えた方がいい。なのでこの方法も使いたくない。
var
で宣言し直す先のエントリに当初書いていたコードでは、parseTemplate()
の第2引数で渡したオブジェクト(ハッシュ)のプロパティを走査してそれをvar
で変数として宣言し直す、ということをしてた。外の名前空間をなるべく汚さないための苦肉の策だ。
if (aContext && typeof aContext == 'object') {
for (var prop in aContext) {
if (!aContext.hasOwnProperty(prop)) continue;
__parseTemplate__codes.unshift('var '+prop+' = aContext.'+prop+';');
}
}
こんな感じ。
でも、これだとエラーになりそうな場合がけっこう考えられる。例えばハッシュのキーが01234
という文字列だと、実行されるJavaScriptのコードはvar 01234 = aContext.01234;
となってしまい、eval()
にかけた時点でSyntaxError: missing variable name
と怒られてしまう。
なので、こういうエラーの元になる名前のプロパティを除外して、安全な物だけをvar
で宣言する、ということをやりたかった。言い換えると、そのプロパティの名前を構成している文字列がJavaScriptの識別子として妥当かどうかを判別したかった。
ということでやっと、このエントリの本題に入る。
UxU 0.5.11に入れ損ねた。次版で標準のヘルパーメソッドに入れるけど、割といいかげんな実装で、たいした規模じゃないから、テストケースの中に直接書いて使ってもいいと思う。
function parseTemplate(aCode, aContext) {
var __parseTemplate__codes = [];
aCode.split('%>').forEach(function(aPart) {
var strPart, codePart;
[strPart, codePart] = aPart.split('<%');
__parseTemplate__codes.push('__parseTemplate__results.push('+
strPart.toSource()+
');');
if (!codePart) return;
if (codePart.charAt(0) == '=') {
__parseTemplate__codes.push('__parseTemplate__results.push(('+
codePart.substring(1)+
') || "");');
}
else {
__parseTemplate__codes.push(codePart);
}
});
var __parseTemplate__results = [];
with(aContext|| {}) {
eval('(function() { '+__parseTemplate__codes.join('\n')+' }).call(aContext|| {})');
}
return __parseTemplate__results.join('');
}
var source = <![CDATA[
大切な事なので3回言います。
<% for (var i = 0; i < 3; i++) { %>
今日は<%= today %>です。
<% } %>
オーケー?
]]>.toString();
var params = {
today : (new Date()).toString()
};
var result = parseTemplate(source, params);
レガシーだけどクロスブラウザな書き方だったら、こうか。
function parseTemplate(aCode, aContext) {
var __parseTemplate__codes = [];
aCode = aCode.split('%>');
var strPart, codePart;
for (var i in aCode) {
aCode[i] = aCode[i].split('<%');
strPart = aCode[i][0];
codePart = aCode[i].length == 1 ? null : aCode[i][1] ;
__parseTemplate__codes.push('__parseTemplate__results.push(unescape("'+
escape(strPart)+
'"));');
if (!codePart) continue;
if (codePart.charAt(0) == '=') {
__parseTemplate__codes.push('__parseTemplate__results.push(('+
codePart.substring(1)+
') || "");');
}
else {
__parseTemplate__codes.push(codePart);
}
}
var __parseTemplate__results = [];
with(aContext|| {}) {
eval('(function() { '+__parseTemplate__codes.join('\n')+' }).call(aContext|| {})');
}
return __parseTemplate__results.join('');
}
var source = '大切な事なので3回言います。\n'+
'<% for (var i = 0; i < 3; i++) { %>\n'+
' 今日は<%= today %>です。\n'+
'<% } %>\n'+
'オーケー?';
var params = {
today : (new Date()).toString()
};
var result = parseTemplate(source, params);
AIRMigemoというライブラリがあることをリファラで知った。AIRアプリにMigemo検索機能を組み込むのに使えるということだろうか。でもライセンスが分からない……
肝心の正規表現の生成処理は、かなり真面目にやってるような印象。XUL/Migemoの現在の実装は長い文字列の一括置換と分割とソートによる擬似的な物なので、「短い入力で長い単語にマッチさせる」という元のMigemoの特徴の一つを損なうことなく持っていると考えられる。
MochiKit見てみた。
これも基本はやっぱりユニットテストに特化した感じかなあ。少なくともGUIのテストは意識してないか……
仕事でFirefoxの拡張機能をやるという事になったときに最初に須藤さんに「拡張機能のテスト用フレームワークってあるの?」みたいな事を聞かれて、それでMozUnitに辿り着いたんだけど、その時の僕にはまだ自動テストとかテスト駆動開発という物がどういうものかよく分かってなかった(今もまだよく分かってないかもだけど)。今思うと、その時僕が思ってた「自動テストって、こういう事をしなきゃいけないのかな?」というのは、開発者世界の常識的には相当ワガママな要求をイメージしていたようで、普通は「自動テスト」「ユニットテスト」というともっと低レベルの、あくまで部品単位の品質を高める物という認識でよかったみたいだ。それを知らずに僕はSeleniumのGUIアプリ用版みたいなのをイメージしてたから、「そんなの無理ッスよ……」と勝手に諦めムードになってた。とはいえ、その勘違いが無ければここまで意地になってUxUに手を入れまくる事もなかっただろうしなあ。
JsUnit見てみた。
オンラインの例はFirefox 3で普通に動いたんだけど、ダウンロードしたやつは何故か動かなかった……パスに日本語が含まれてるとダメとかそういうやつ?
見た感じではWebページ用のJavaScript一般のユニットテスト用という感じで、Chrome特権であれこれするやつを、しかもGUI上の動作をテストするという前提では……ないよねえ、やっぱり。
script.aculo.usのユニットテスト機能を見てみた。
昔、Firefox上でprototype.jsを試してみたことがあるけど、少なくとも当時のバージョンではprototype.jsはObjectのプロトタイプとかにプロパティを追加する仕様だったような気がする。なんか全般的にfor-inループを多用してる部分で影響が出すぎてて、Firefoxの動作自体がぶっ壊れてしまって使い物にならなかった記憶がある。少なくとも今のscript.aculo.usが使ってるバージョンについてはObjectのプロトタイプは触らないようになってるみたいだけど、FunctionやRegExpなどのプロトタイプには変更を加えてるみたいで、ちょっと怖い……気にしすぎだろうか。
肝心のユニットテスト機能について。
Firefox上でも問題なく動くと仮定しても、これを使って拡張機能のテストをやろうとすると結局は「どうやってテストを走らせるのか」「テストの結果をどうやって見るのか」といったあたりは自分で解決しなきゃいけないか……粒度を高めて本当にユニットテストのために使うぶんには十分使えそうなんだけど、いわゆる結合テスト的な所になってくると面倒さが跳ね上がりそう。XULに特化した便利なユーティリティを沢山用意しておくだけでもそれなりにUxU意義はあるのかな。
自分自身が基本的にGUIアプリしか使えない人間なので、script.aculo.usのテスト機能のように「これ使ったらテストができるよ」って機能群をぽんと渡されても、「え? え?」って感じで戸惑ってしまう。何かしら型にはめて「あなたはここだけやればいいですよ」って感じでやるべき事を絞り込んで貰えないと、どうしていいか分からなくなってしまう。そのあたりが、UxUでMozRepl由来の部分を全然使わずにMozUnitの部分ばかり拡張し続けている最大の理由なんだな。
タイトルは釣り。
僕自身はなんだかんだで仕様原理主義者な所が今も強いわけで、その考えに則れば、onclick等のイベントハンドラは一応W3Cの仕様に含まれてるから(HTML4、XHTML 1.0、XHTML 1.1)OKだけど、ライブラリは業界団体の作る標準仕様になってないからNG、と言える。というのはまあ半分冗談だし、そもそもHolyGrailさんの指摘とは次元が違う話なのですが。
しかしこの考えも、権威主義だけじゃなくて、実利的に考えて「そうあるべき」と僕は割と真面目に思っていたりもする。
この三つの点について、満たしている物が多ければ多いほど、満たしているレベルが高ければ高いほど、それは良い物で学ぶ意義も大きいと僕は思う。
今でこそ僕はFirefox一辺倒だけど、これも「1」と「3」がそれなりに満たされているからという所が大きい。仕様は無いにしても実装がソースコードレベルで公開されているから、必要とあらば「こういう時にどうなるのか」をどこまでも追いかけられる。また、少なくともWindowsとMacとLinuxというマルチプラットフォームで使えて、どれか一つの環境で作り込んでおけば、他の環境でもそのまま使える(最悪でも、それほど大きな労力を掛けずにポーティングできる)。
そして上記三条件それぞれを最も突き詰めた物が、オープンスタンダードであり、デジュールスタンダードであり、デファクトスタンダードだ。
一昔前までは、ことWebについてはデファクトスタンダードとデジュールスタンダードが激しく乖離しているのが当たり前で、GeckoくらいしかまともにW3Cの仕様を実装している物が無い頃には「W3Cの仕様はWeb標準だからこれに則ってればいいことあるよ」と言っても「でもそれって夢物語じゃん」と返されるのが世の風潮だったと思う。でも今は時代が変わった。OperaもSafariも高いレベルでWeb標準に対応してきたし、IEも少しずつだけどWeb標準に合わせてきてる。今だったらはっきりとこう言える。「Web標準の技術を使っていれば、FirefoxでもOperaでもSafariでも動作するし、AirでもGoogleガジェットでもFirefoxの拡張機能でも使えるし、いいことだらけだよ」と。
不遇の時代を乗り越えて、「Web標準」は今、上記三つの条件を兼ね備えた物にようやくなりつつある。W3CやWHATWGやISOやECMAに仕様があって、仕様が公開されていて、しかもそれをほとんどのベンダがサポートしている。これって凄い事だと思わんかねぇ?(誰ともなく)
にゃるら、さんのselector.jsをベースに色々やってたらそれっぽい物ができたので、氏に敬意を表しselector.js相当の部分をMITライセンスで公開しときます。冒頭のコメントを見ての通りですが、元のselector.jsで対応されていなかったCSS3のセレクタをだいぶサポートしてます。正しく動かない事があるかもしれないのでその時はフィードバックください。
改造版の一番の特徴は、document.convertSelectorToXPath()
ですね。CSSのセレクタを文字列で渡すと、対応するXPath式を生成できる場合はそれを返します。ダイナミック疑似クラス等、XPath式では表現できない内容の時は空文字を返します。
var nodes = document.getElementsBySelector('li:nth-child(even)');
for (var i in nodes)
{
nodes[i].style.backgroundColor = 'gray';
}
var expression = document.convertSelectorToXPath('p:not(li > *)');
// → /descendant::*[local-name() = "p" or local-name() = "P"][not(self::*/parent::*[local-name() = "li" or local-name() = "LI"])]
silhouettePseudElementsAndClasses
がtrue
の時は、:first-line
疑似要素や:first-letter
疑似要素など、無茶すればどうにか再現可能な物については、勝手に要素を生成したりclass
を設定したりしてそれを使ったXPath式を返します。document.evaluate()
を多用してるので、DOM3 XPathを実装したブラウザでしか動かんです。というか多分Gecko専用? 他のブラウザでも動いたら教えてください。:nth-child()
とかは、カンマ区切りのセレクタのリストにそれがあるだけで、その宣言ブロックが丸ごと無視される模様です。(豆知識)