Latest topics 近況報告

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さんの指摘とは次元が違う話なのですが。

しかしこの考えも、権威主義だけじゃなくて、実利的に考えて「そうあるべき」と僕は割と真面目に思っていたりもする。

1. いつでも詳細な取り決めを確認できて、不安無く使える。
2. 特定のベンダの意向や、世間の流行り廃りに振り回されずに、安心して使える。
3. 学んだことが無駄にならず、他の場面でも使える。

この三つの点について、満たしている物が多ければ多いほど、満たしているレベルが高ければ高いほど、それは良い物で学ぶ意義も大きいと僕は思う。

今でこそ僕は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改 - Jul 31, 2007

selector.js改（ミラー）

にゃるら、さんの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式を返します。
• 上記の例を見ても分かるとおり、まあ、無駄が多いです。XPathの勉強用か、内部処理用と割り切って使う事をお勧めします。
• 内部でdocument.evaluate()を多用してるので、DOM3 XPathを実装したブラウザでしか動かんです。というか多分Gecko専用？　他のブラウザでも動いたら教えてください。
• Geckoの仕様上、スタイルシートに記述してあっても、内部のテーブルに存在しないセレクタは無視されるようです。:nth-child()とかは、カンマ区切りのセレクタのリストにそれがあるだけで、その宣言ブロックが丸ごと無視される模様です。（豆知識）

併せて読みたいですか - Jun 16, 2007

のりさんに倣って、あわせて読みたいを始めてみた。

のりさんとこが上位に出てきてるのは予想通り。

ここを見てる人のためにって言うよりは、僕自身が知りたいだけかもしれん。フィードリーダー使うようになってから、いわゆる「新規開拓」をしなくなってしまったし……

「Webデベロッパがローカルアプリケーションとmash upする環境」、Apollo - May 24, 2007

募集開始と同時にあっという間に席が埋まってしまったというApollo mini Camp @ Tokyoに、潜り込んできた。

本家の開発者が来てApolloの概要と現状、将来について詳しく語っていた。Apolloの凄さは、実際に動いている所を見るとよく分かる。とても充実したセッションだったと思う。

講演の内容はWeb Designing2007年6月号の特集の内容と被っていた所も多かったけど、メモに残せた範囲で書いていこう。

講演の中の言葉で印象的だったのは、「Apolloを使うと、Webサービスだけでなく、ローカルアプリケーションとマッシュアップできる」という表現。発想の立脚点が、アプリケーション開発者の視点ではなく、Webデベロッパの視点である、という事を端的に示す名言だと思う。

プレゼンでは、Web上にある楽曲ファイルを再生するプレーヤー機能を持ったWebサービスFinetuneを例に挙げ、WebサービスとしてのFinetuneの欠点として

• ブラウザを再起動する度に演奏が途切れてしまうので、BGMを流しっぱなしにするというような使い方ができない
• ブラウザのタブの中にページが埋もれてしまい、曲飛ばしなどの操作をし辛い
• 手元のCDなどの曲を演奏できない

といった点を挙げた上で、Apollo上で動作するFinetune Desktop Playerを起動して、

• ブラウザと全く別に動作する
• iTunes Music DBにアクセスして、ローカルにある楽曲ファイルを再生する
• Webページ内の埋め込みプレーヤーで「再生」ボタンを押した時に、そのメッセージを受け取り、Desktop Playerの方で楽曲を再生する

といった例を示していた。これはApolloのコンセプトを特に分かりやすく示してくれる好例だ。

そういった例の数々やなんかを見るにつけ、似たコンセプト・似た機能のXULRunnerがWebにもローカルにもどっちつかずな印象（のように僕には見える）なのに比べて、Apolloはとても明快な印象を受けた。Apolloは明確に「Webデベロッパのもの」を意識している、ということを、メッセージとして発信している。ターゲットを見据えた上で、物を作ってきているし、物を見せてきている。

続きを表示する ...

CSS Naked Day 2007 - Apr 05, 2007

今日はCSS Naked Dayという日だそうなので、このサイトもCSSを無効化してみました。

HTMLの方を書き換えるのがめんどくさかったので、スタイルシートの方を空のファイルに入れ換えただけですが。

しかもフィードリーダで見てる人には違いが分からない罠。

What happened to the design?

To know more about why styles are disabled on this website visit the Annual CSS Naked Day website for more information.

（訳：デザインに一体何が起こったんだ？　このサイトで何故スタイルが無効になっているのかについて詳しい理由を知りたければ、年に一度のCSS素っ裸デーのサイトを見るがいいYO！）

普段何気なくスルーしているスタイルシートを敢えて無効にすることによってWeb標準技術というものをプロモートする、というのがこのイベントの趣旨だそうです。

yieldをwait代わりに使っちゃっていいのかなー - Feb 16, 2007

MozLabの一機能の単体テスト用ツールMozUnitではasync型のテストケースを書くことができる、というのは前にここでも書いたんだけど、使い勝手の悪いポイント？が一つある。それは、テストケースの中で、ある処理が終わってから次の処理に進むといったことが簡単にはできないこと。

現状の仕様では、

1. 共通の前処理（処理待ちできる）
2. テストケース1（処理待ちできない）
3. 共通の後処理（処理待ちできない）
4. 共通の前処理（処理待ちできる）
5. テストケース2（処理待ちできない）
6. 共通の後処理（処理待ちできない）
7. 共通の前処理（処理待ちできる）
8. テストケース3（処理待ちできない）
9. ...

という書き方しかできなくて、各テストケースの中でコールバック関数を使って準備が整うのを待つという使い方はできない。一般的な意味での単体テストというのがどうある「べき」なのかは知らないけど、やりたいこととしては、

1. 共通の前処理（処理待ちできる）
2. テストケース1（処理待ちできる）
3. 共通の後処理（処理待ちできない）
4. 共通の前処理（処理待ちできる）
5. テストケース2（処理待ちできる）
6. 共通の後処理（処理待ちできない）
7. 共通の前処理（処理待ちできる）
8. テストケース3（処理待ちできる）
9. ...

の方が便利ですよね？　ね？

んでscript.aculo.usのユニットテストの機能ではwaitという機能を使って処理待ちができるそうだから、MozUnitステでscript.aculo.usを拡張機能の開発でも使えるようにせよ！という指令が須藤さんから下ったのだけれども。

なんか仕様があちこち違うから今までMozLabベースで作ってた物をこれ用にするにはscript.aculo.usのソースもガッツリ読まなきゃいけないっぽいし、どうもscript.aculo.usは複数のテストが同時に動くことを想定していなさそうな雰囲気だったので、MozReplみたいな機能を使って同時に複数人でテストするようなことは難しいっぽかった（そんな事ほんとにやるのかどうかはさておき）ので、新しいこと覚えるよりは今までの知識がそのまま使えた方が僕が楽だと思った。

ということでMozUnitのTescCaseクラスの定義をゴニョゴニョと書き換えて、JavaScript 1.7のジェネレータを応用し、テストケースの中で yield 5000; とか書くとそこで指定時間（ここでは5000ミリ秒＝5秒）待ってから次の処理に進むということができるようにしてみた。テストケースの実行結果の返り値を見て、 [object Generator]である場合は、StopIteration例外が出るまでタイマー使って何度もnext()を実行して、それが済んでから次に処理を進めるようにした次第です。

……ということなんだけど、yieldってこんな使い方しちゃっていいのかしらん？　yield（生産）って書いてるのに何も生産しとらんし。

古いIEをCSSのmax-height, min-height, max-width, min-widthに対応させるスクリプト - Feb 05, 2007

minmax.jsというライブラリを使うと、最小サイズ・最大サイズを設定するCSSの機能を古いIEでも使えるそうで。IE6でやっても動いた。

IE6でもXML宣言があると後方互換モードになってしまってこれらのプロパティが機能しなくなるんじゃなかったかな。だとしたらもうしばらくの間は有用かも？

なんか文章が分かりにくいと言われたんで言い訳しとくと、スクリプト発見→IE6で表示→おお確かに動いてるねぇ→説明読む→ってIE5用なのかよ！→でもIE6で動いたなぁ→ていうかそもそもIE6って本体でmax-widthとか実装してたよね→でも後方互換モードじゃ使えないんだよね、XML宣言あると後方互換モードになっちゃうんだよね→じゃあやっぱりIE6でも有用なんじゃね？　という流れがあった結果としてのこのエントリなんですよと。読む人の都合とか利便とか考えてないオナニー文章の典型ですね。

JavaScript 1.7のyield文ってなんじゃらほ - Aug 07, 2006

JavaScript 1.7 の yield が凄すぎる件についてを見てもyieldってそもそも何なのかちいとも分かっとらんかったのでそこから調べてみた。

続きを表示する ...