Latest topics 近況報告
たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。
以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！
parseTemplate() の引数で渡すオブジェクトのプロパティをテンプレート内のコード片で普通の変数として参照したい - May 20, 2009
前書き
PHPとかerbのようなテンプレートをJavaScriptで。という話に書いたやつの続き。
大切な事なので3回言います。
<% for (var i = 0; i < 3; i++) { %>
今日は<%= today %>です。
<% } %>
オーケー？こういう文字列をテンプレートとして解釈したい場面は多分よくあると思う。この例だと、todayという変数をどっか外部から与えて値を埋め込むことになる。で、この変数をどうやって渡したらええねん、と。
解1：グローバル変数を使う
グローバル変数をがんがんに使って構わないのであれば、先にグローバル変数としてtodayを定義しておけばいい。eval()で実行されるコードの中からも普通に参照できる。
しかしアドオンのコードのように、個々のグローバル関数やグローバル変数の寿命が長い事が予想されるスクリプトでは、この手は使えない。
解2：テンプレート内に書くコード片にthis.を付ける
parseTemplate()の仕様としてはあくまで「書かれたコード片は第2引数で渡されたオブジェクトをthisとして実行されます」という風にしておいて、テンプレート風に書かれている方の文字列内のJavaScriptコード片では必ずthis.todayという風に書くようにする、という方法もある。
しかしいちいちthis.を付けるのは面倒だし、そもそも僕がこのような記法を知ったきっかけであるERBでは、self.なんて書く必要がなかった。同じような物は同じように使えた方がいい。なのでこの方法も使いたくない。
解3：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の識別子として妥当かどうかを判別したかった。
ということでやっと、このエントリの本題に入る。
PHPとかerbのようなテンプレートをJavaScriptで。 - May 19, 2009
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);Adobe AIRでMigemo - Nov 25, 2008
AIRMigemoというライブラリがあることをリファラで知った。AIRアプリにMigemo検索機能を組み込むのに使えるということだろうか。でもライセンスが分からない……
肝心の正規表現の生成処理は、かなり真面目にやってるような印象。XUL/Migemoの現在の実装は長い文字列の一括置換と分割とソートによる擬似的な物なので、「短い入力で長い単語にマッチさせる」という元のMigemoの特徴の一つを損なうことなく持っていると考えられる。
Selenium、Selenium IDE - Jul 16, 2008
試してみた。
SeleniumはWebアプリケーション用のクロスブラウザな自動テストツールで、独自の書式または好みの開発言語でテストケースを書いて、Webアプリケーションの機能テストを行える。Selenium IDEを使うとFirefox上での操作を記録して（何もないところでクリックするという風な操作も記録される）、Selenium用のテストケース（の雛形）まで生成してくれる。
あーこれはいいわー。Webアプリ開発やるなら絶対お勧めだと思う。FirefoxでSelenium IDE使ってテストケース作って、それをエクスポートして他のブラウザでも自動テスト、ということもできるようだし。
ちゃんとドキュメント見てないからよく分かってないけど、ユニットテスト（単体テスト）より機能テスト（結合テスト）に特化してるような気がした。単体テストには別のツールを組み合わせることになるんだろうか。あと当然だけどFirefoxのアドオンの自動テストには使えない。
MochiKitのテスト機能 - Jul 15, 2008
MochiKit見てみた。
これも基本はやっぱりユニットテストに特化した感じかなあ。少なくともGUIのテストは意識してないか……
仕事でFirefoxの拡張機能をやるという事になったときに最初に須藤さんに「拡張機能のテスト用フレームワークってあるの？」みたいな事を聞かれて、それでMozUnitに辿り着いたんだけど、その時の僕にはまだ自動テストとかテスト駆動開発という物がどういうものかよく分かってなかった（今もまだよく分かってないかもだけど）。今思うと、その時僕が思ってた「自動テストって、こういう事をしなきゃいけないのかな？」というのは、開発者世界の常識的には相当ワガママな要求をイメージしていたようで、普通は「自動テスト」「ユニットテスト」というともっと低レベルの、あくまで部品単位の品質を高める物という認識でよかったみたいだ。それを知らずに僕はSeleniumのGUIアプリ用版みたいなのをイメージしてたから、「そんなの無理ッスよ……」と勝手に諦めムードになってた。とはいえ、その勘違いが無ければここまで意地になってUxUに手を入れまくる事もなかっただろうしなあ。
JsUnit - Jul 15, 2008
JsUnit見てみた。
オンラインの例はFirefox 3で普通に動いたんだけど、ダウンロードしたやつは何故か動かなかった……パスに日本語が含まれてるとダメとかそういうやつ？
見た感じではWebページ用のJavaScript一般のユニットテスト用という感じで、Chrome特権であれこれするやつを、しかもGUI上の動作をテストするという前提では……ないよねえ、やっぱり。
script.aculo.usのユニットテスト機能 - Jul 15, 2008
script.aculo.usのユニットテスト機能を見てみた。
昔、Firefox上でprototype.jsを試してみたことがあるけど、少なくとも当時のバージョンではprototype.jsはObjectのプロトタイプとかにプロパティを追加する仕様だったような気がする。なんか全般的にfor-inループを多用してる部分で影響が出すぎてて、Firefoxの動作自体がぶっ壊れてしまって使い物にならなかった記憶がある。少なくとも今のscript.aculo.usが使ってるバージョンについてはObjectのプロトタイプは触らないようになってるみたいだけど、FunctionやRegExpなどのプロトタイプには変更を加えてるみたいで、ちょっと怖い……気にしすぎだろうか。
肝心のユニットテスト機能について。
- アサーションが色々ある。アニメーション効果を扱うライブラリってことで、要素が見える状態かどうかとかのためのアサーションもある。
- ベンチマークを取る機能がある。これパクろうかな。
- BDD風の記述もできるみたい。
- 処理待ちについては、setTimeoutを使って一定時間後に渡した関数に処理を移すという機能がある。
Firefox上でも問題なく動くと仮定しても、これを使って拡張機能のテストをやろうとすると結局は「どうやってテストを走らせるのか」「テストの結果をどうやって見るのか」といったあたりは自分で解決しなきゃいけないか……粒度を高めて本当にユニットテストのために使うぶんには十分使えそうなんだけど、いわゆる結合テスト的な所になってくると面倒さが跳ね上がりそう。XULに特化した便利なユーティリティを沢山用意しておくだけでもそれなりにUxU意義はあるのかな。
自分自身が基本的にGUIアプリしか使えない人間なので、script.aculo.usのテスト機能のように「これ使ったらテストができるよ」って機能群をぽんと渡されても、「え？ え？」って感じで戸惑ってしまう。何かしら型にはめて「あなたはここだけやればいいですよ」って感じでやるべき事を絞り込んで貰えないと、どうしていいか分からなくなってしまう。そのあたりが、UxUでMozRepl由来の部分を全然使わずにMozUnitの部分ばかり拡張し続けている最大の理由なんだな。
本気でやるならprototype.jsやjQueryやYUIは避けてonclickを使うべき - May 18, 2008
タイトルは釣り。
- 本気でやるならonclick属性は避けてライブラリを活用すべき - id:HolyGrailとid:HoryGrailの区別がつかない日記
- 本気でやるならクロスプラットフォームは避けてMozillaアプリを作るべき - hogehoge
- onclick 属性問題について - IT戦記
僕自身はなんだかんだで仕様原理主義者な所が今も強いわけで、その考えに則れば、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に仕様があって、仕様が公開されていて、しかもそれをほとんどのベンダがサポートしている。これって凄い事だと思わんかねぇ？（誰ともなく）
UXU - UnitTest.XUL、1000人スピーカプロジェクト - Jan 21, 2008
amachangの1000人スピーカプロジェクトの第1回でお披露目したUXU（うず）のこととか。書くのが遅くなったのは鴉見てたからです。
プレゼンの話
ニコ動に全プレゼンの映像が上がってて、僕の奴も見れるんですが、いやー、これはひどいプレゼンですね。
いや言い訳さしてもらうとですね、前日に仕事用マシン（Let's note W2）のHDDが逝ってしまいまして、前日夕方くらいからそれのせいであたふたして徹夜してて、あんまり頭働いてなかったんですよ。だからこの日はマシンは持参してたけどUbuntu 7.10のLive CDで起動してました。隣の人とか後ろの人とか多分CD-ROMドライブの音がぶんぶんうるさかったと思いますが、それはこのせいです。それにしてもUbuntuすごいね。CD起動なのに無線LAN使えちゃったよ。さすがにプロジェクターの認識は再起動が必要みたいだったからプレゼンの時だけamachangにマシンをお借りしましたが。
プレゼンでちゃんと言えてなかったことの補足。自分がテストという物の意義を理解したのがRailsのそれだったので、UXUを最終的にどういうものにしたいのかという目標も、今の所はRailsに置いてます。なので、今は実現できてないけどfixtureみたいな物もできるようにはしたいと思ってます。
それか、もっと根本的なところで、テスト専用のプロファイルにその時だけ切り替えて……みたいなこともできるようにしたいんですが、この辺になってくるとプラットフォーム用のバイナリを作らないといけないような気がしていて気が重いです。もしかしたらProfile Switcherが解決のヒントになるでしょうか？
yieldの変な使い方の話
yieldの読み方は「いーるど」でよかったんですね。でもそれ知ってもどうしても「いぇーるど」と読んでしまう……
昨年頭にごにょごにょしてたのはプレゼン中に書いたお蔵入りバージョンのUXU 0.1のことなんですが、その時は単にウェイトの秒数を指定するだけでした。つい最近になって奥さんのエントリを見て、そうか「復帰条件」と考えれば返り値は数値だけじゃなくてもっとなんでも渡してイイんだな、とインスパイアされて、フラグを保持するオブジェクトを渡すパターンをまず実装し、それから関数を渡すパターンも実装したという次第です。
UXUでやってることの工夫というか特徴的なところは、yieldの本来の用途であるところのジェネレータ・イテレータの生成という役割を隠蔽してしまって、「処理の一時停止」「再開」という部分だけに特化した見せ方をしているところではないでしょうか。内部的には昨年頭に書いた話にあるとおり、setUpとかテストケースとかの関数オブジェクトの返り値がジェネレータであればタイマーを使ってイテレーションを行う、というだけのことなんですが。
amachangが紹介していたJSDeferredの方がもっときっと便利でいろんな事ができるとは思うんですが、プレゼンでも言った通り僕はN88BASICの行番号の呪縛から未だに逃れられていないような人間ですので、これ以上の複雑なことは脳が拒否して受け入れてくれんのですよ……