2008-04-11
XPathGraph がすごい件と、XPath で出来ることのヒント
XPathGraph とは
URL と XPath を指定すると一日に一回その URL をスクレイピングして XPath 式が示す値をグラフにしてくれる!という画期的なサービスです。
例えば、 URL と XPath を指定するだけで以下のようなグラフが作れてしまいます。
本当に楽しいことが出来そうでワクワクしてます!
でも
まだ XPath を登録している人が意外と少ないので、「ひょっとして、このサービスの使いどころが分からないのかなあ。」と思いました。
というわけで
XPath で出来ることのヒントを少し紹介したいと思います。
足し算、引き算、かけ算、割り算
XPath では普通に数値の演算ができます。
たとえば、 //div[@class=counter] で取得してきた div 要素が 1000 という数値を持っていたとすると
2 * (//div[@class=counter] + 200)
というようにその数値を計算式にそのまま突っ込むことができます。
ただし、割り算は / ではなく、 div を使います。
//div[@class=counter] div 3
余りを求める演算は mod を使います。
//div[@class=counter] mod 3
これを使えば、例えば単位を変換してグラフにするということも簡単にできますね。
便利な関数郡
XPathGraph はグラフを作るサービスなので、コンテンツから数値を探してこなければならないように思えますが、実はそうとも限りません。
たとえば、以下のようなものをグラフにすることもできそうです。
count を使ってそのページの全要素数をグラフにする。
count(//*)
count を使って特定の要素の数を調べる
count(//ul[@class="userlist"]/li)
string-length を使ってそのページの文字数をグラフにする。
string-length(//*)
具体例としては CodeRepos::Share ? Trac のページで以下の XPath 式を使うと、 CodeRepos のコミッター数をグラフにできます。
count(id("Committers")/following-sibling::ul/li)
などなど
XPath 式は単純なノード取得をするための式ではなく、文字列の操作、数値の演算もできるのです。
ですので、いろいろと考えれば、 XPathGraph の可能性は無限に広がっていくと思います。
まとめ
XPathGraph すごいです!
みなさんも面白いアイデアがあれば何か作ってみてはいかがでしょうか
駄文 - JavaScript と「クラス」と「コンストラクタ」と「プロトタイプ」って言葉の定義が難しいよなあ
このエントリを見てて思ったんですけど
JavaScript関数の実体は、Functionクラスのオブジェクトです。今回はFunctionクラスの機能を網羅的に解説します。
JavaScriptの関数オブジェクトを完璧に理解する - builder
「Function クラスのオブジェクト」って言いますよねー。
僕もそういう風に言ったりするんですけど、本当は微妙ーに違うんですよね。
でも、そんな細かいことを言っていてもしょうがないので、やっぱり「Function クラスのオブジェクト」って言うんですけど。
なんか、良い言い方ないかなあ。
いや、そもそも
関数って
のどっちなんだろう
Function.prototype を継承するけど[[Call]]を持たないオブジェクトもあるし、[[Call]]を持つけど Function.prototype を持つオブジェクトもあるよなあ。
てか、こんなこと考えてもしかたないよなあ
なので、やっぱり関数は「Function クラス のオブジェクト」なのです。
最初から、変に難しく考えるより「Function クラス のオブジェクト」と割り切ることが大切かもなのです。
駄文 - やりたいことがあるときに Python だからとか PHP だからとかは考えたくない
Google App Engine の言及とかで、「おもしろそうだけど、 Python だしなあ。 PHP でも使えるようになったらいいな」というような反応を見ると残念な気持ちになる。
Google App Engine が今は Python しか使えないなら Python やればいいのに。
自分の好きな言語を DIS られると「言語関係ないじゃん」っていうのに「結局、言語関係あるのかよ」みたいな
まあ、何が言いたいかというと「Google App Engine」やらないか
「Acid2 test」と「マージンの相殺」のちょっとした疑問
マージンの相殺の仕様を読み直していて
Vertical margins may collapse between certain boxes:
…
Box model
と書いてあることに気がついた。
マージンの相殺はあくまで「may」なのだ。
なので、マージンの相殺をしないブラウザでも CSS 2.1 準拠とうたうことは出来る訳だ。
Acid2 test の場合はマージンの相殺が必須
Acid2 test で表示されるスマイルマークのおでこ部分のボックスと鼻部分のボックスはマージンの相殺が行われてあの距離を保っている。
「may」のものもテストの対象になっているんだなあ。
それってどうなんだろう。
「may」なのも「どうなのそれ?」って思うし
「may」なのにテスト対象なのも「どうなのそれ?」って思う。
でも、 UA 間で仕様が統一されてなかったら、それはそれで仕事が大変なんだろうなって思う
「理想」と「現実」ってとこですか。


