adiary開発日誌

Wikipedia APIとは

というふうに、サムネイル作成で使わせて頂いているSimple APIが提供するWikipediaの情報を取得するAPIです。これを adiary で Ajax 風に実装しようと思ったんですが、XMLHttpRequest ではセキュリティ上の問題でクロスドメイン（Simple API提供のWikipedia API）から直接データを取得することができないんですね。

よくよく調べると、JSONPというのがありまして、別にhandlerの名前を指定出来なくていいから対応してもらえないかなーという感じです。

例えば

呼び出すhandler名は固定で、引数も現在のAPIを文字列に変えたものでいいんですけど…。例えば、http://wikipedia.simpleapi.net/api?keyword=Google&output=xml&jsonp=1にアクセスすると、特定の関数をXMLを文字列として戻してくれるとか。

追記 2006/12/28

JSONは既に対応済だったらしい（恥）

サンプルと概要

ASIN記法のサンプル

上のリンクのマウスを乗せるとわかりますが、画像がポップアップで表示されます*1。

このようなポップアップを実現するには、Firefox (Netscape)において、onMouseMoveを使うことが一般的のようです。しかし、マウス座標を取得するためだけに、マウス移動のイベントを拾うというのは非効率的すぎてどうにも釈然としません。

IE/Firefoxで使えるポップアップウィンドウ

以下のスクリプトは自由に使って構いません。（2008/09/17 Update）

function popup_img( img_url, evt ) {
	var text  = "<img src=\"" + img_url + "\">";
	var div   = document.getElementById( 'popup' );
	var style = div.style;
	var cx; var cy;
	if (! evt) { evt = event; }
	cx = evt.clientX + (document.body.scrollLeft || document.documentElement.scrollLeft);
	cy = evt.clientY + (document.body.scrollTop  || document.documentElement.scrollTop);
	style.left = (cx + 16) + 'px';
	style.top  = (cy + 12) + 'px';
	div.innerHTML = text;
	style.zIndex   = 9999;
	style.display  = 'block';
}

function popdown() {
	document.getElementById( 'popup' ).style.display = 'none';
}

となります。ポップアップを実現したい場所では、

<tag onMouseOver="popup_img('<画像URL>', arguments[0])" onMouseOut="popdown()"></tag>

とします。

仕組み

見ればわかりますが、呼び出し側でarguments[0]と書かれた場所があります。これがミソです。onMouseMoveを使う実装方法では、マウスを動かすたびにいちいちイベントを取得していましたが、この方法ではonMouseOver発生時のイベント（イベントオブジェクト）をarguments[0]によって取得しています。

Perlで「use strict」で使用している場合、ファイルハンドルを動的に生成し変数に代入するには一工夫する必要がありました。

さらに、このファイルハンドルに標準入力などを代入する場合、

my $fh = 'STDOUT';

ではダメで、

my $fh = *STDOUT;

とします。少々気持ち悪い感じもしますが、STDOUTという定義済の名前に対する型グロブを与えることになります。Symbolなどのライブラリをみると分かりますが、動的ファイルハンドルの実体は、特定の名前に対する型グロブになっています。

所詮Perl？

ネットをみていると「所詮Perl」的な発言をみかけるのですが、いやいやマテマテマテマテ。かと思うと、はてなもmixiもPerlだ！　的な肯定意見があったりして、それもまた視点としておかしいような。

Perlの長所

• Rubyなどのスクリプト言語と比べ速く動作する（時に数倍以上）。
• CやC++に比べはるかに開発が容易。
• CやC++に比べどうしても遅くなるものの、重い計算をループ処理させなければ実用上そこまで大きく変わらない。
• PHPに比べ、MVC的なソース（ソースとHTML部分を分離させるコード）を書くのに適当である。
• 世の中のほとんどのサーバで動作する

という特徴があります。adiaryの基礎になっているスケルトンシステム（Satsuki-system）開発時、本当はRubyも検討したんですが、簡単なテストスクリプトをいくら走らせてもRubyの処理速度はPerlのそれに到底及びません。Perlは隅々まで最適化が行き届いていて、うまく書いてやれば相当早く動作します。

Perlの短所

• 言語仕様が非常にきたない（アセンブラおなじくスクリプト言語として原始的）。
• 標準ではCGIとして動作させるため、スクリプトとしての起動が遅い。処理が遅いのではない。

ほとんどこの２点に尽きると思います。１つめは対Rubyで考えると非常に分かりやすい。互換性を保ってきた結果が現在のPerl 5＋オブジェクト指向という複雑な状況なんですが、それでもこのゆるゆるのオブジェクト指向がまた逆手に取ってうまく使うと非常に効率的なシステムが作れます。

２つめはネットを検索すると沢山出てきますが、「PHPはPerlより速い」という意味での速いです。起動が速い。ネット上の共有レンタルサーバでなければmod_perlなどを使うことで解決できますし、うまく書けばCGIとして動かしてもそこまで重くなりません。*1

結局

Perlってのは使い倒せば大規模開発にも十二分にも耐えられる言語です。ただこの辺は適切に判断すべきで、仕様をきっちり決めることで綺麗なメンテ性を取るならRubyもありですし、Webアプリとして手軽に作りたいならPHP、処理速度と開発効率を同時に求めるならPerlということになると思います。*2

adiaryを開発する人間としては

「早くPerl6出ないかなぁー」ってのが本音です（笑）　Satsuki-systemが全面書き直しになりそうで怖いのは怖いけども（苦笑）

CSSの中でjavascript実行しちゃったりする問題

CSSXSSというのがあるんですが、もちろんIE専用。要するに「罠サイトからスタイルシートに見せかけることで好きなサイトのデータを（クライアントに）取得させ、それをJavaScriptで処理することで罠サイト側に情報漏洩出来る」セキュリティホールです。さすがIEやることが違う！

というわけなんですが、CSSXSSさせない（加害者にならない）対策は取れても、CSSXSSされない（被害者にならない）対策は取りようがない。漏洩したことろでセッションは盗めないのですが（でも機密とかダダ漏れ）、CSSXSS＋CSRFされるともはや手の打ちようがない。

世の中のIE使ってる人、危険極まりないですよこれは（汗