■

download_tumblr_image.py
Web::Scraper プレゼン＠YAPC::EU: blog.bulknews.net

77枚目DOM+Element -> XPath にある Template::Extract はじめてしった。
でもこのアプローチだとHTMLが微妙に変わったら取り出せなくなるのは変わんなかったりしないんだろうか。きまぐれで<FONT SIZE=3>みたいなのが入ったりしてもfailするのでは。(ブクマコメントでmiyagawaさんにコメントいただきました。人間がチェックするのを前提にしてるということですね。機会があったら後半部分のお話どこかでお聞きしたいです)

前にmixiとdel.icio.usで、取り出したい要素マーカーとして特定のテキストを埋め込んだテストページみたいなのを作って、そのテキストのXPathを生成して、それをWeb::Scraperにかますっていうのをやってみたけどうまくいかなかった。mixiの日記個別ページはわりとうまく動いた。HTMLがヘンタイ的なのでWeb::Scraper側で微妙に細工が必要で、WWW::Mixi::Scraperはどうやって解決してるのかみてみたらやっぱり細かく細工をしてあった。mixi....
del.icio.usの場合、タグはページ内でuniqueなのでそのXPathを取り出すのは簡単なんだけど、タグの数を取り出そうとすると、同じ数のものが多数あったりしてストレートなやり方だと複数にマッチするのでうまく取り出せなくてもうひとひねり必要だとおもってやめちゃった。
でも今考えてみたらXPath生成は自分の使っているアカウントのデータから作れる必要はないんだから(自分のアカウントのデータから取り出そうとしてたところがまちがい)mixi同様XPath生成用のアカウントをつくってデータをそれようにセットアップしてそこから取り出すべきだった。

プログラムがうまく望みのXPathを取り出せるようにデータをセットアップしてあげてコードを動かすかんじが、プログラムが正しく動いているならばパスするテストを書いてあげるのに似てる(テスト先に書けというのはなしで)。だからコード書くのよりもキカイがうまくXPathをとりだせるようにデータをセットアップしてあげることが大切。キカイにコードを生成させること書いたのはこれやってたときだ。これでつくってたやつが生成するXPathがちょーきたなくて(Mixiがきたないからかも)、あとAutoPagerize IDEのつくるXPathがあまりに汚いっていうのもアタマにあった。
でも自動で生成するならキカイが作ってキカイが読むだけなんだからそんなのsmartyの吐き出すPHPのコードが汚いからむかつくとか言ってるのと同じで、吐き出されたコードをキカイしか読まない前提なら汚かろうがなんだろうが関係ないじゃん。

そうじゃなくてWeb::Scraperのjsバージョンを特権付きでなんかするっていうのを思いついたからメモしとこうと思ったら、中見てたときにDOM+Element => XPath というのを見て思い出して忘れるところだった。