本の虫: 2009/06

あ、もしもし、オレオレ、そう、株式会社フューチャースピリッツだけどさぁ。ナイスなメールフォーム作ったんで使ってくれ。もちろんSSLだからセキュリティもバッチリ。一昔前に流行った、オレを自称するどこぞのアホの作ったニセモノSSLとは違うぜ。こっとらちゃぁんとEV SSL持ってんだから。何がすごいってブラウザのアドレスバーが緑色になる。SSLが信頼できるかどうか確かめられる新機能。安心だろ？　ん？　オレと全く関係ない奴が、おれのSSL使ってるって？　こまけぇこたぁいいんだよ。EV SSLには変わりねぇんだから。その証拠にほれ、ブラウザ緑、オレ最強。

しかもフォームに入力された内容は、平文でメールにてサービス利用者に送られるという本末転倒なサービス。

2009-06-28

虎の巻には、あまり価値がない

学校の参考書などは、自らを名付けて虎の巻などとしている。しかし、参考書の名前を虎の巻にする筆者が信頼できるかは、はなはだ疑問である。

虎の巻とは、中国の有名な兵法の書、六韜の虎韜に由来するものである。実は、六韜はとても短い。だから、一時間もあれば虎韜は読める。そこで、ちょっと読んでみた。

結果は、あまり価値のあることは書いていない。武王が何を聞いても、太公望は適当に答えるばかりである。太公望の言葉は、一にして足る。曰く、「臨機応変」。具体的には、右にして左にして前後してと、もっともらしいことを云っているが、根本的には、「その時々に応じて最適な方法をとれ」と云っているに過ぎない。何の価値もない書物である。

故に私は言う。虎の巻と称する参考書の筆者は、六韜を読んでいない。もし読んでいたならば、こんな無意味な書物から、名前を引かないはずだ。

ただ、六韜はやたらと読みやすい。だから、読みやすい文章に対して、虎の巻というのは、可だと思う。

坊主頭にしていたら坊主を疑われた件

自衛隊の二次試験にて、面接官が開口一番、曰く、「君は僧侶かね。自衛隊という特性上、何か特定の宗教を強く信奉している人は困るのだけれどね」と。

まあ、確かに京都だ。坊主は多い。しかし、自衛隊の試験だ。気合いを入れるために坊主頭にしてくる人ぐらい、結構いるのではないだろうか。もっとも、当日、坊主頭にしていたのは、私一人だったのだが。

だいたい、私は自衛隊に入るから坊主頭にしているわけではないのだ。いわば趣味だ。髪を伸ばしたり染めたりするのが趣味と認識されるのなら、剃髪するのだって、趣味として認識されてしかるべきだ。私は剃髪するほどまめではないので、いつもバリカン刈りなのだが。

まあ現実に、自衛隊に志願するからといって、頭を丸めてくる人は、極少数なのだろう。私からすれば全く理解できないが、皆、髪に未練でもあるらしい。不思議なことだ。

最近面白かったページのリンク集

PVの水増し以前の問題

一日50万人のアクセスか。海王拳並だな。

Ananova - Luxury yachts offer pirate hunting cruises

ロシア発、豪華海賊撃退ツアー。一日当たりのお値段は3500ポンド、危険な海域をわざと航海します。海賊に襲われたら、グレネードランチャー、マシンガン、ロケットランチャーで撃退、爽快間違いなし。今なら一日5ポンドでAK-47がレンタルできてお得です。ちなみに、弾は100発で7ポンドとなっております。

どうも海賊狩りツアーは嘘ニュースらしい模様。まあ、実際明らかに怪しい文面だったしなぁ。しかも、五月あたりから広まっていたニュースらしい。

一般曹候補生の二次試験の次第

昨晩はXPathにかまけていて、肝心の試験の様子について書くのを忘れていた。

私は六時半に、地本から車で宇治の駐屯地へ向かった。今回は、特筆すべき事はあまりない。予備自衛官補の試験と、それほど変わりないからだ。行うべき事は二つ。身体検査と面接のみ。

身体検査は予備自衛官補のものと、全く変わりがなかった。ただし、やたらと丁寧な検査になっていたと思う。とくに、色覚と聴力に関してだ。予備自衛官補では、色覚のテストを、飛ばし飛ばしにやっていた。ただし今回は、全ページに対して行った。また、聴力も、以前は数種類の周波数でしか行わなかったが、今回はやたらと増えた。予備と現職の違いだろうか。

さて、落ち着いて周りを見回してみると、皆、申し合わせたように同じ格好をしていた。つまり、私も含めて皆、いかにもな若者らしく安物感が漂う、こぎれいなスーツを着用していた。いわゆるリクルートスーツと呼ばれている所のものだ。不思議である。一次試験では、ほとんどの人間がスーツを着ていなかったのだ。もちろん、一次試験は面接などないので、服装にこだわらないというのもあるが、それにしても、この100%のスーツ着用率は不思議である。

そして人数だ。やたらと少ない。中部の二次試験は、27日と28日に、宇治駐屯地で行われる外、24日に舞鶴で行われたらしいが、それにしても人数が少ない。

これは地本の人の話なので、真偽は分からないのだが、何でも、例年の一般曹候補生は、秋にしか試験をしないらしい。それが今年、年二回やるようになったのだとか。更に噂によれば、前期の試験では、三割しか取らないといわれている。残りの七割は秋の試験に取るのだとか。そこで、今回の一次試験突破は、だいぶ厳しかったのではないかと言うことだった。

この私でも通ったぐらいだから、それほど厳しい一次試験だったとは思えないが、現にこうして、全員申し合わせたようにスーツ着用の光景を見ると、まあ、そんな気もしてくる。一次試験の時は、茶髪にピアスで眉そり落とし、アクセサリーをジャラジャラと付けて、やたらと派手なシャツに、両膝の破けたジーンズで、しかも遅れてきた奴がいた。そういう手合は受からなかったのだろう。

試験は、非常にあっさりとしたものだった。特技は英語とプログラミングだと答えたら、何でも、面接官もプログラミングをするらしい。具体的には何もいわなかったものの、「おいおい、何でIF使ってるんだよ。遅いだろうが、SELECT使えよ」という言葉があったところから察すると、SQLだろうか。SQLがプログラミング言語かというと、また別の話だ。SELECTに言及する前に、危うく、「そうですな、ブランチはヘビーなパイプラインを持つモダンなプロセッサにとってはタブーですな」などと言いそうになった。危ない所だった。また、言語だが、ハングルは読めるかと聞かれた。残念ながら、ウリにはハングルは読めないニダ。なるほど、確かに今の情勢から考えるに、使えて重宝される言語というと、ハングルになるのだろう。

いつも通り、私はあらかじめ何も答えを用意せずに望み、その場で正直に答えた。別に己を夏目漱石の坊ちゃんに比したいわけではない。自身の性格からして、あらかじめ心にもない「模範解答」を用意していったところで、その模範解答を答えようとすれば、眉つり上がり、目細まり、口元ゆがみといった、いわゆる苦虫を噛みつぶしたような顔をするに決まっているからである。つまり、私はポーカーが苦手だと言うことだ。

他人の感想を求めても、皆、「やたらとあっさりと終わった」と言うだけであった。誰一人として、「いやぁ、つっこまれまくってダメでした。終わったなオレ」などと答えたものはいなかった。無論、圧迫面接の有効性については疑問だが、皆が皆、あっさりと終わったと感じるような面接でも、やはり評価のしどころに困るのではあるまいか。その辺は、疑問である。

そういえば、ひとつ気がついたことがある。それは、陸と海で、一次試験合格通知の判子が、変わっていることである。陸は楷書の判子だったが、海は隷書だった。海は昔気質なのだろうか。

とにかく、これで試験はすべて終わった。合格通知は七月末、秋の試験の受付は八月からだ。

予備自衛官補の辞令式が、もうすぐある。

続DOM XPath

DOM XPathの実装に、どこか違和感がある。その理由はこうだ。

典型的なXHTMLの場合、HTML要素に、無名の名前空間とでもいうべきものを指定する。（規格を逆さにしてみても、どうもこの名前のない名前空間の正式名称は分からない）

<html xmlns="http://www.w3.org/1999/xhtml" >

これは確かに名前空間だが、とくに具体的な名前を使ってはいない。したがって、そもそも典型的なXHTMLには、名前空間のプレフィクスなど指定しようがないのである。指定しようがないのだから、XPathEvaluator.createNSResolver(document.documentElement)を使って、現在のドキュメントのResolverを作ったとしても、動くわけがない。だから、XPathにおいては、ダミーの名前空間を指定し、そのダミーの名前空間に対して、XHTMLの名前空間を返すResolverを実装するという、不思議なコードを書かなければならないのだ。

具体的に言うと、XPath表現がこんなものだとしても、

/お前は俺を怒らせた:html/だが断るッ！:body/貧弱ゥ貧弱ゥ:p/*

以下のようなResolverを渡せば動いてしまうのである。

var NSResolver =
{
        lookupNamespaceURI : function (prefix)
        {
                return document.documentElement.namespaceURI ;
        }
} ;

なぜなら、このXPath表現はXHTMLに適用することを前提にしているので、名前空間などどうでもいいのである。ただし、名前空間の指定を省略することはできない。どんな文字列でもいいが、何かしら指定しなければならない。なんと無意味なことか。

そもそも、何でこんな不思議な実装になっているのだろう。名前空間が無名なのだから、何も指定する必要はないと思うのだが、よく分からない。

DOM XPath を理解したが、使い物にならん

Document Object Model XPath

DOM XPathは、多くのブラウザでサポートされている。しかし、その実装が、現実的に理解できない。

本物のXHTMLに対してXPathを用いるには、名前空間を明示的に指定しなければならない。省略不可能である。何故だ。何故なのだ。普通、XHTMLの要素に対しては、具体的な名前空間を使うことは、まずない。たとえば、

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html >
<html xmlns:ジョジョ="http://www.w3.org/1999/xhtml" >
<ジョジョ:head>
<ジョジョ:title> 岸部露伴語録集 </ジョジョ:title>
</ジョジョ:head>
<ジョジョ:body>
<ジョジョ:p>
今…家がない……<ジョジョ:br />
康一くんのとこ泊めてもらってるし<ジョジョ:br />
漫画描く机もない<ジョジョ:br />
「セーラームーン」のフィギアも<ジョジョ:br />
「レッド・ツェッペリン」の紙ジャケも<ジョジョ:br />
「るろうに剣心」も全部売っ払っちまった
</ジョジョ:p>
</ジョジョ:body>
</html>

こんなXHTMLを書く奴はいない。皆、XHTMLの名前空間を、わざわざ指定したりしないのだ。そもそも、xmlnsすら、だれも考えて使ってはいない。その意味を理解して使っている人間はすくない。ただ、おまじないに成り下がっている。そこで、XHTML5では、xmlnsもいらないんじゃね、ということになっている。

そして、実際のドキュメントでは名前空間を使っていないにもかかわらず、DOM XPathでは、なぜか名前空間を指定しなければならない。それが面倒なので、ある人は、こういう場当たり的なコードを書いている。このリンク先でやっていることといえば、XPathでは、記述を楽にするため、使っていないはずの一文字名前空間を使い、さらに、愚直にあらゆる名前空間に対してXHTMLのURIを返すXPathNSResolverを実装しているのだ。もはや、XHTMLを使う理由が分からない。厳格に使えないのであれば、そもそもXHTMLを使う必要などない。

そもそも、jQueryを初めとした一連のJavascriptライブラリは、別にCSSのセレクタを、要素検索の言語として選ぶ必要はなかったのである。XPathでも良かったのである。Javascript上でXPathを実装するのは、不可能ではない。ところが、そんな酔狂なライブラリは出なかった。CSSのセレクタに、親要素を選ぶだとか、何番目の要素を選ぶだとかの、軽い独自拡張を施した程度の検索用言語で、皆満足している。思うに、誰も、XPathのような複雑怪奇で、正規表現とも比すべき読みにくさを誇る言語を使いたくなかったのだろう。

これを考えるに、W3Cの規格を書いている人間は、何か特別にすばらしいものを吸っているとしか思えない。その吸っているものがあまりにすばらしすぎるので、まともに現実をみることができていないのだ。

XPathは、XHTMLにおいて使う方法が分からない。

XHTML上でXPathを使おうと試みているが、なかなかうまくいかない。

HTML上なら、何の問題もない。ただ、XHTML（Content-typeが、application/xhtml+xmlである本物のXHTML）で、XPathを使うのが、やたらと難しい。

例えば以下のコード

document.evaluate("count(/html/*)", document, null, XPathResult.NUMBER_TYPE, null).numberValue ;

このコードを、html下にheadとbodyのある、いわゆる一般的なXHTMLに対して適用すると、2が帰ってくるはずである。実際、HTMLでは、2が帰ってくる。ところが、本物のXHTMLでは動かない。

どうやら、名前空間とやらが問題らしい。そこで、以下のコードを試してみた。

var result = document.evaluate("count(/html/*)", document, document.createNSResolver(document), XPathResult.NUMBER_TYPE, null).numberValue ;
var result = document.evaluate("count(/html/*)", document, document.createNSResolver(document.documentElement), XPathResult.NUMBER_TYPE, null).numberValue ;

動かなかった。そこで、XPathNSResolverインターフェースを自前で実装することにした。

// http://www.w3.org/TR/DOM-Level-3-XPath/xpath.html#XPathNSResolver
// に準拠した実装
var NSResolver1 =
{
        lookupNamespaceURI : function (prefix)
        {
                if ( prefix === "html" )
                        return "http://www.w3.org/1999/xhtml" ;
                else 
                        return null ;
        }
} ;

// たんなる関数
function NSResolver2 (prefix)
{
        if ( prefix === "html" )
                return "http://www.w3.org/1999/xhtml" ;
        else 
                return null ;
} ;

どちらを使っても、Chrome、Safari、Firefox、Operaでは動かなかった。

どうしたら動くのだろう。もうお手上げだ。

というかこの場合、名前空間をvalidateすることを望んでいるプログラマはいるのだろうか。普通、速度を気にするはずである。XPathが遅いの早いのと議論されているようだが、どう考えてもこれは、机上の空論による規格としか思えない。実際、誰も使っていないじゃないか。みんな何を使っているかというと、jQueryのようなJavascriptのライブラリを使い、CSSのセレクタで要素を取得しているのだ。実際、要素を検索するといっても、それほど複雑な検索機能を欲してはいないのだろう。所詮はCSSのセレクタ程度で十分だということだ。

そして、実際XPathは遅いと思う。なにしろ、CSSのセレクタのように、単純に1パスというわけにはいかない。場合によっては、ノードツリーをさかのぼって探さなければならないし、その規格はやたらと複雑だ。一体誰が使うのか謎な機能が多すぎる。

XPathは、どう考えても失敗規格だなぁ。第一、XPathの表現は読みにくい。

XPathがうまく動かない

なぜかHTMLだと動くが、XHTMLだと動かない。より詳しく規格を読む必要があるのか

2009-06-26

GoogleのWeb高速化キャンペーンへの疑問

Reducing the file size of HTML documents
CSS: Using every declaration just once

本当に、HTMLやCSSから十数文字程度を削減したぐらいで早くなるのだろうか。積もり積もってファイルサイズが増えることもあるだろうが、仮にわずかなタグ記述の節約によって、ファイルサイズとCPU時間を削減しえたとしても、実際のコンテンツとしての文字だけで軽く上回ってしまうし、画像はいかに最適化しようとキロバイトのレベルだし、広告一発で帳消しどころかマイナスになってしまうじゃないか。Googleとして広告を否定するわけにもいかないだろうに。

現にこうやって書いているだけで、一文字3バイトも消費してしまう（Bloggerの文字コードはutf-8なので、多くの日本語の文字は3バイトである）

中国はなんでああなってしまったんだろう

東京新聞:中国検閲ソフト　低い性能？　毛沢東の顔写真わいせつと誤認:国際(TOKYO Web)

唐の時代は、世界的に実力のある国だったのに、それがどうしてこんな事になっているのやら。

ロシアには王様を欲する国民性でもあるのだろうか

プーチン

「ロシア最強の男」プーチン首相、スーパー電撃視察で値引き指示　写真4枚　国際ニュース : AFPBB News

いつまでたっても、ロシアには自由とか資本主義などという言葉は根付かないようだ。

長年必要だと思っていたユーザースクリプト

// ==UserScript==
// @name        Dislabe ugly style.
// @namespace   http://cpplover.blogspot.com/
// @description disable ugly font-weight and font-style for all web sites
// @match     http://*/*
// ==/UserScript==

(function()
{
 var style = document.createElement("style") ;
        style.setAttribute("id", "hito-disable-ugly-style") ;
        style.appendChild( 
                document.createTextNode( "* { font-weight : normal !important ; font-style : normal !important ;}" ) 
        ) ;

        document.getElementsByTagName("head").item(0).appendChild(style) ;
})() ;

解除用のbookmarklet

Chrome用。GreaseMonkey用にするためには、@matchを@includeに変える必要がある。

世界が変わった。boldもitalicもないWebサイトのなんと読みやすいことか。なぜ外人は、こうもboldやitalicが好きなのだろう。この疑問に対して、或る外人は次のように答えた。

我々には、日本語のように、異なる字形だが同じ文字というものがない。例えば、「俺は馬鹿」という言葉に対しては、「俺はバカ」だとか、「オレはバカ」だとか、違った言い方ができるし、読んだときのニュアンスが微妙に違うが、我々の文字では、こういう事はできない。したがって、何かを強調したい時は、boldやitalicを使うのだ。

うーむ。言語の優劣というものを語るのは、言語学においては野暮だと聞く。文字が多いと面倒な事もあるが、boldやitalicを必要としないので、すばらしい。

そういえば、一昔前の、つまり70年代や80年代の純文学小説では、印刷する文字自体を、表現に含めていることがよくあった。村上春樹や村上龍の小説が有名だと思う。字体や大きさ、太さなどを指定して印刷してあるのだ。あれは、正しい日本語ではないと、私は思う。日本語には、boldやitalicを必要とはしないのだ。

2009-06-25

ZeniMax Mediaがid Softwareを買収

ZeniMax Media Acquires id Software

マジか。

どう評価したらいいものやら。

陳情表

李密の書いた陳情表が名文過ぎて困る。対句はカッコいいし、言いたいことを直接書いていないのに、何故かその意が明確に伝わってくる。一体どうすればこんな文章が書けるのだろう。

臣密言。臣以険釁、夙遇愍凶。生孩六月、慈父見背、行年四歳、舅奪母志。租母劉閔臣孤弱、躬親撫養。臣少多疾病、九歳不行。零丁孤苦、至於成立。既無叔伯、終鮮兄弟。門衰祚薄、晩有児息。外無期功彊近之親、内無応門五尺之童。煢煢獨立、形影相弔。而劉夙嬰疾病、常在牀蓐。臣侍湯薬、未嘗廃離。逮奉聖朝、沐浴清化。前太守臣逵、察臣孝廉、後刺史臣栄、挙臣秀才。臣以供養無主、辞不赴。会詔書特下、拝臣郎中。尋蒙国恩、除臣洗馬。猥以微賎、当侍東宮。非臣隕首所能上報。臣具以表聞、辞不就職。詔書切峻、責臣逋慢、郡県逼迫、催臣上道。州司臨門、急於星火。臣欲奉詔奔馳、則以劉病日篤。欲苟順私情、則告訴不許。臣之進退、実為狼狽。伏惟、聖朝以孝治天下。凡在故老、猶蒙矜育。況臣孤苦、特為尤甚。且臣少事偽朝、歴職郎署。本図宦達、不矜名節。今臣亡国賎俘、至微至陋。過蒙抜擢、豈敢盤桓有所希冀。但以劉日薄西山、気息奄奄。人命危浅、朝不慮夕。臣無祖母、無以至今日。祖母無臣、無以終余年。母孫二人、更相為命。是以区区不能廃遠。臣密今年四十有四、祖母劉今年九十有六。是臣尽節於陛下之日長、報劉之日短也。烏鳥私情、願乞終養。臣之辛苦、非独蜀之人士、及二州牧伯、所見明知、皇天后土、実所共鑑。願陛下衿憫愚誠、聴臣微志、庶劉僥倖保卒余年。臣生当隕首、死当結艸。臣不勝怖懼之情。謹拝表以聞。

Chromeにまともなjavascriptデバッガとプロファイラが追加された

Chromium Blog: Developer Tools for Google Chrome

今まで、ChromeはWebkitのInspectorをそのまま使っていた。ElementとResourceタブは問題ないのだが、ChromeはV8という別のJavascriptライブラリを使っているので、このままではJavascriptデバッガとプロファイラが動かない。今回のDevリリース(3.0.190)で、このInspectorに手が加えられた。Javascriptデバッガとプロファイラが動くようになった。

早速試してみたが、使い勝手が良くてすばらしい。

n2906　Simplifying the use of conceptsがすごい

Simplifying the use of concepts

これはすばらしい。名文だ。あの378通あるMLでの議論を、よくまとめあげたものだ。と思ったら、外ならぬBjarneさん本人の筆だった。これは全C++プログラマが読むべきだと思う

2009-06-pre-Frankfurt mailingが公開された

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/#mailing2009-06

とりあえず、現時点で興味深いものとしては、

Defining default copy and move
Copyコンストラクタのみを持っている型と、Moveコンストラクタのみを持っている型の両方をメンバにもつクラスは、copyもmoveもできないというお話。

Unified Function Syntax
local functionとnamed lambdaが復活してる。うれしいな。

The long pole gets longer
いつconceptに対応したコンパイラが出るのよ、というお話。まず、規格のスケジュールとしては、去年あたりから言われていたのだが、基本的に、今年の10月にFCDがでて、2010年にはFDISを出す予定。FDISがでれば、もう変更は無いので、コンパイラベンダーも安心して実装できる。ただ、ISOの規格として発行するには、その後も少々時間が必要で、まあ、2011年になるかなといったところ。conceptの実装も時間がかかる。まあ、実装が出揃うのは、よくて2011年。私見では、2011年にconceptをサポートするコンパイラが出たとしても、Betaという名を関しているだけだと思う。まともに使えるようになるのは、2013年あたりになるんじゃないかと思う。

New wording for C++0x Lambdas
lambdaの文面に関する疑問が各国から噴出したので、文面を書き直すよというお話。あと、sizeof、alignof、decltypeの中では、lambda expressionを使えないようにするらしい。そんなこと考えても見なかった。もし出来たとしたら、sizeof([] -> int8_t{return 0})なら1が帰ってくるのだろうか。decltypeはもっとひどい。なぜなら、すべてのlambda expressionは別の型を返すのだから、lambda expressionが完璧に同じでも、別の型になるはずだ。つまり、is_same< decltype([]{}), decltype([]{})>　（decltype内は、引数なし、戻り値なしのlambda expression）は、falseのはずだ。

Simplifying the use of concepts
conceptのデフォルトをimplicitにしようというお話。いままで、implicitにするには、明示的にautoをつけなければならなかった。この提案は、明示的なconceptにしたい場合は、explicitをつけるようにする変更。このほうが分かりやすいと思う。

Exported Concept Maps
concept_mapの実装を、unconstrainedなコード（つまり、conceptを使っていないコード）でも使えるようにしましょうというお話。conceptの存在意義が疑われそうな提案だが、いかにもC++らしいといえばC++らしい。それに、実際このままでは、constrainedなコードと、unconstrainedなコードで、実装が重複してしまう。プログラマは単純なコピペを使うだろうと思われる。コピペされるだったら、使えるようにしたっていいんじゃないという意見は、わからないでもない。

Working Draft, Standard for Programming Language C++
会議前だし、大幅な変更は無い。

ほかにはasyncなどもあるけれど、正直スレッドプールが今すぐ欲しい。TR2に予定されているのだけれど。正直、スレッドの利用目的の大部分は、スレッドプールの方が適していると思う。

2009-06-24

Javascriptに関する批判的感想

あまりにも動的過ぎる。いやもちろん、動的な言語というのも悪くはない。プロパティを後から自由に追加できること自体は、別に悪くない。ただし、delete演算子は、正気の沙汰ではないか。一体当時、Javascriptを実装していたプログラマが何を吸っていたのか、非常に気になる。

withの問題、withに至っては、もう吸っていた所じゃない。明らかに静脈注射していたレベルだ。withの問題は、あまりにも有名なので、いまさら言うまでもないだろう。まともなJavascriptプログラマなら、皆知っている。

あまりに型を軽視している。また、数値がすべてfloating pointだ。実際のほとんどの実装では、integerで差し支えない部分は、integerで計算しているわけだし、integerとfloating pointぐらいの区別は、あってもいいはずだ。

コピーと参照を明示できない。時には、オブジェクトをコピーしたいときもあるはずだ。コピーの機能ぐらい、言語として提供しているべきではないのか。また、変数のブロックレベルスコープがない。なぜこんな仕様にしたのだろう。この二つの問題を解決するため、Firefoxで実装されているJavascript 1.7のletを猛烈に欲しているのは、私だけではないだろう。

あまりにもライブラリが貧弱すぎる。Timerぐらいは、DOMに頼らず、言語側に入れてもいいはずだ。しかも、Timerが、明確に規格として規定されたのは、HTML5からだ。

しかしそれでも、Javascriptの手軽さは捨てがたい。C++とは、また違った楽しさがある。

ブラウザの座標再び

CSSOM View Moduleを見ていたら、WindowView interfaceに、面白いプロパティがたくさん見つかった。

たとえば、 pageXOffset/pageYOffsetは、ウインドウのスクロールを、ピクセル数で返す。

また、screenX/screenYというプロパティもあり、これはブラウザの、ディスプレイ上の位置を返す。

他にもscreenインターフェースが規定されている。この歴史的なインターフェースの存在は知っていたが、W3Cにおいても規定されているとは知らなかった。

あと、良く見たら、マウスイベントのoffsetX/offsetYも、ここで定義されていた。ただし、前述の通り、まともに実装しているのはIE8しかないという事実がある。padding boxからの相対位置を返すべきなのに、ボーダーも含めていたり、そもそもpaddingすら無視していたりという実装がある。しかも、規格に従うならば、padding分を差し引かなければならない。面倒だ。さらに、pageX, pageYも規定されていた。なんだ、ここで規定されていたのか。やれやれ。getBoundingClientRect()を使うまでも無かったわけだ。W3Cで規定されているならば、使うのに遠慮はいらない。

それにしても、このあとから付け加えるような形で、一部の規格が点でばらばらの文書で規定されているのは、何とかならないのだろうか。しかも、いまだにドラフト段階だ。

ogg/Theoraを猛烈にプッシュしている人たちがいるけれど

無駄な努力と言わざるをえない。Theoraの画質が、H.264に比べて劣っているのは、まだ開発段階だからだと主張する人がいるが、一体何年開発していると思っているのだろう。H.264の最初の規格制定は2003年のことである。TheoraはOn2 TechnologyのVP3に端を発しており、H.264に比しても同じぐらいの開発期間はある。方やすばらしい画質を誇るH.264と、全くふるわないTheora。どちらが良いかは、誰の目にも明かである。

ライセンス問題など、実際はさほど影響がないのだ。問題は、使えるかどうかである。GIFがうち捨てられたのも、結局256色しかサポートしていなかったというのも大きいだろう。

面白い名前の空港（ただし英語視点で）

World's funniest airport names revealed - News & Advice, Travel - The Independent

もっとも卑猥な空港名は、福井空港(Fukui Airport)らしい。

私は、この手の多言語間におけるジョークが好きな人間である。

自衛隊の地本てふ不可思議な場所

昨日、自衛隊の一般曹候補生の二次試験の、面接予行というものがあった。何でも、親切にも面接のリハーサルなるものをしてくれるらしいということだ。別に面接など、何度受けたって変わらないと思うが、どうせ暇なので、参加することにした。損にはなるまい。

行くと、私を含めてたったの五人しか来ていなかった。えらく少ない気がする。面接の練習というのは、どこの学校やセミナーでもやっているだろう。しかし、それは所詮、外部の人間が行う練習に過ぎない。これは、外ならぬ応募先自身、つまり自衛隊自身が、わざわざ面接の練習をしてくれるというのだ。参加して損だとは思わない。何故こんなに少ないのだろうと、その時は漠然と思った。

さて、面接の予行を受ける前に、どのような態度で臨めばいいのかという、あくびの出るほど暇な説明が、配られたプリントに書いてあることそのままに、棒読みで述べられた。曰く、

第一印象が比較的重要となる。学生あるいは若者らしさが良い印象を与える。
動作は係員の指示に従い、テキパキと若者らしく。
清潔感は好印象を与える。

応答要領

質問した面接官の方をみて回答する
努めて落ち着いた表情で、明るく対応する
正しい言葉遣いに気をつけ、はっきりと意見を伝える
志願の動機を明確にしておく

まあ、代わり映えのしない文句ばかり並んでいる。これ自体は、別に悪くはない。ただ最後に、

※　決め手になるのは入隊意志を如何に表現できるかである！

と書かれていたのが気になった。私は、上で、理由なく"border-style : double"を使ったわけではない。実際に配られたプリントにも、そのように印刷されていたからだ。この一文は、今回、とても重要な意味を持つわけだが、このときの私はまだ、その本当の意味に気がつかなかった。

さて、面接予行前の説明が終わり、実際に一人ずつ、面接練習を行う段になった。私は、地本から家が一番近いので、順番は最後になった。配られたプリントには、「曹候補生２次試験口述模擬質問事項」と題して、本日の面接練習で訊ねる質問事項が、すべて載っていた。自分の順番になるまで、なんと答えるか考えていてくださいとのことであった。そこまでするか。

参加者は、私を除くと四人いるわけだが、そのうちの三人は男で、女は一人だった。ちょうどみんな、職種に関するパンフレットを眺めていたので、私は会話を始めようと、こう言った。

「やあ、皆さん、職種とか、どの辺を希望してるんですか」

返事はない。かろうじて一人だけ、「整備かな……」と答えたきりである。仕方がないので、また聞いた。

「陸海空、どこを受けるんですか」
「空」、「陸」、「同じです」

あとは沈黙のみ。これでは会話というものが成立しない。見れば、みんなメモ帳を片手に、何かを書き殴っている。一体何をメモる必要があるというのだ。あらかじめ、どう答えるか考えた所で、実際にその通りに事が弾むわけがない。その答えに応じて、面接官がさらに質問を発展させるというのが、普通の面接ではないか。とすれば、何をメモる必要があるというのだ。

会話が成立しそうにないことを悟った私は、自宅まで本を取りに戻った。何しろ、私の面接は、一時間後なのである。

さて、本を取って地本に戻ってみると、紅一点の女子が、なにやら地本の担当者と話していた。

女子「わたし、自衛隊の訓練についていけるか心配で」
担当「いやいや、訓練なんて全然心配することないですよ。うんぬんかんぬん」
女子「水泳をやっていたんですけど」
担当「ほう、一日どのくらい泳いでいたんですか」
女子「一日五キロぐらい」
担当「自衛隊の訓練よりそっちの方が厳しい」

地本が、「自衛隊の訓練は心配するに足らず」と言うのは常の事だが、一日五キロも泳げる人間が、何を心配するというのか。

また、他方では、ある男子と担当官との間に、こんなやりとりがあった。

担当「適当に言ったらええねん。例えば、自分は車いじりが好きで学校行ってた頃からやってました。だから自衛隊でもそういう仕事に就きたいんです、とか」
男子「いや、自分、車はいじったことないスよ」
担当「まあウソでもいいやんか。矛盾さえなければ。大事なのはやる気を見せることや」

「やる気」という言葉が私の頭に響いたが、このときも、私はさほど気にはとめなかった。

この二つを除いて、あとは会話らしい会話がなかった。皆、何かメモることに必死であった。不思議なことだ。会話が成立しないので、私は李密の陳情表を読んでいた。すばらしい文章だ。これを書いたのは天才ではあるまいか。

陳情表を読むうちに一時間過ぎ、私の前の番の人が、面接を終えて、出てきた。ひどく疲れ切った顔をしていた。たったの15分、それもリハーサルに過ぎない面接で、何故そんなに狼狽できるのか、私には不思議だった。

ところで、狼狽という言葉は、ちょうど陳情表にも出てくるが、およそ漢文の世界では、狼狽という言葉は、「疲労困憊」と同じ意味で用いられる。中国語にも、「うろたえる」という意味がないわけではないが、文章の上で、狼狽を「うろたえる」という意味に用いることはないそうだ。

この男は、頭髪上指とでも言うべき髪型をしていた。頭髪という頭髪が、皆逆立っているのだ。一体どうすればそんな髪型を維持できるのか、入道頭の私には、分からなかった｡その逆立った頭髪は、狼狽した顔には全然ふさわしくなかった。

私は思わず声をかけた。「お疲れ様です」と。狼狽の男は、何も答えず、頷かず、私に一瞥をくれただけで、速やかに帰って行った。

どうして、集まっている皆という皆が、こういう性格をしているのだろうと、私はいぶかしんだ。もちろん、皆の態度がよそよそしいのは、私の言動の至らぬせいもあろう。それにしても皆、冷徹無関心にも程がある気がする。さらに、これは面接予行、練習、リハーサルだというのに、皆ガチガチに緊張していた。不思議だ。

さて、いよいよ私の番になった。面接予行の内容は、詳しく書くに及ばない。ただ、一つ気になる点があった。というのも、面接らしい面接ではない、ということだった。人の言葉尻を捕らえて、ねちねちと掘り下げた質問をするのを、圧迫面接というならば、この面接予行は、圧迫面接から対極の面接であった。圧迫面接とまでは行かなくても、面接官が質問をして、それに答える。答えた内容について、さらに質問される。これは、面接の基本である。この面接予行には、それがない。質問される、答える、曰く、「ああ、そうですか」。これで終わりである。もう次の質問にうつってしまう。私は未だかつて、いかなる些細なバイトの面接であろうと、こんな歯ごたえのない面接を受けたことはない。今、私が箸にも棒にもかからぬ阿呆で、面接をする価値すらないとせよ。それにしても、これは面接予行である。本物の面接ではない。もう少し普通の面接らしい面接でもいいだろうに、一体これは何なのだろう。圧迫面接に対する対義語を、私は浅学にして知らない。たぶんそんな言葉に需要はないのだろう。

実に異質な面接だった。のれんに袖押しといおうか、豆腐にかすがいと言おうか、とにかく手応えという物が感じられない。そこで私は一計を案じた。
面接官、「団体生活で重要なことは何だと思いますか？」
私は答えた。「はい、周りに流されず、自分の意見を持つことだと思います」
面接官曰く、「ああ、そうですか」と。

待て、この答えすら、聞き流すというのか。普通、「団体生活において重要なことは、自分の意見を持つことだ」などと答えたならば、「でも、自分の意見を押し通せば、みんなから阻害されることにはなりませんか」などと、反論されるはずだ。この面接予行においては、それすらない。一体どういう事だ。

こうして、薄い粥のような面接が終わった。面接について振り返ってみましょうと言われ、見ると、そばの机に、メモ用紙と鉛筆が置かれている。なるほど、メモを取れと言うことらしい。私にはメモを取るという習慣はないが、とりあえずメモ用紙を手に取った。

面接官が言う。あなたは正直すぎますね。中学の頃はサッカーをやっていたけれど、高校はやっていない。そんなことは言わなくても好いじゃないですか。高校のことは、聞かれたら答えればいいんです。高校は将棋部の部長をやっていたが、特に何もしていなかった。まあ、それはそうかもしれませんが、せっかく部活の部長をやっていたんだから、それを生かさないと。大事なのはやる気をアピールすることです。たとえやる気があったとしても、面接でやる気が感じられなければ、採用されるものもされませんよ。それからあなた、英語ですが、TOEICで815点を取っているとか。まあ、それは結構いい点数なのかもしれません。でも、その点数を取るに当たって、どんな苦労をしたのですか。え、何も苦労してない。ええ、そうですか。困りましたね。やる気が感じられないと、云々

聞いていて、私は怒りがこみ上げてきた。何が「やる気」だ。それは、やる気は重要に違いない。しかし、やる気だけあっても何にもならない。およそ言語というものは、苦労して学ぶものではないのだ。必要なのは時間だけだ。あらゆる質問に対して、"Semper fi! Do or Die! Gung ho, Gung ho, Gung ho!"、と答えるだけが能か。そんなチューリングテストにパスしない自動機械を欲しているなら、最初から面接などやる必要がない。もはやこれは、私一個の問題ではない。

私は論じた。

さっきからやる気ばかりを重要視しているようですが、そもそも、やる気とは何ですか。それは、やる気は重要です。しかし、やる気だけではどうにもなりません。自衛隊では毎年、入隊したものの、教育の段階で脱落していく人が何人もいると聞きます。もちろん、たった15分間の面接で人の性格を判断するのは不可能です。ただ、実際の面接の前に、このような予行練習を開いて、教えることと言えば、やる気やる気の一言のみ。このメモに書けるのは、「やる気だけあればオッケー」でしかありません。この助言に従うとしたら、いざ本番の面接という時にも、「やる気があります、とにかく入りたいです、やりたいです」などという人しかいないでしょう。そんな面接では、正しく判断できるものもできなくなってしまいます。一体何でこんな馬鹿げたことをしているんですか。

面接官は言った。「君は、何で、ここにいるのかな」

面接予行を受けるために決まっている。私は言葉遊びをするつもりなど毫毛もないので、何も言わなかった。

「君以外の、ここに来た四人は、みな希望して来ているんですよ。つまり、面接が不安だから練習したいと。そういうわけで、このような練習を開いているんです。担当官になんと言われました。あるいは手違いがあったのかも」

私は自分から面接予行を受けたいと言った覚えはない。無論、面接は不安である。しかしそれは、自衛隊に入る意志があって、而も面接次第では落ちるかもしれないから、不安であるに過ぎない。

「というわけでして、心配しすぎている人に対する予行なんですよ。全員にこんな面接予行をしているわけじゃないんです。安心してください。」

なるほど、それでようやく理解した。この面接予行は、あまりにもやる気がありすぎるあまり、面接が心配で心配で、神経質になっている人のために行っているらしい。それで、自信を持てだの落ち着けだのということが応答要領にあり、さらには、やたらとやる気を強調する内容になっているわけだ。面接が、極力圧迫感を与えないようになっていたのは、そういう人たちへの配慮なのだろう。とにかく普通に、なるべく緊張させずに面接を終わらせることが、自信に繋がるからだ。参加している四人も、つまりはそういう種類の人間なわけだ。皆、やたらと緊張していたり、せわしなくメモを取っていたのも、性格のなせる業なのだろう。やれやれ、つまり、私は場違いらしい。

私はこんな問答をすることからみて明らかなように、議論においては、人を完膚無きまでに言い負かさずにはおれない性格をしている。何とでもいえ。これは私の天性の本能的気質と言ってもよく、矯めることは不可能である。私に必要なのは、むしろ、反論するなという助言だろう。

私が受かるかどうかは分からないし、私以外の、あの四人についても分からない。私が落ちて、あのやる気のある四人が受かるかもしれない。しかし、あの強迫観念に似た不安は、どこから来るのであろうか。なにも、自衛隊に受からなくたって死ぬわけじゃあるまいに。あるいは、私の自衛隊へのやる気が、彼ら四人に比して、あまりに薄いと言うことだろうか。そうとも思わないのだが。

歴史は案外単純なのかもしれないなぁ

かつて、朱熹というアホンダラが、魏呉蜀のうち、蜀が正統であったというトンデモ説を発表する。蜀は一番最初に滅びた国で、当時中国を実効支配していたのは、疑うことなく魏であるにもかかわらず、やたらともてはやされる。これを朱子学と呼ぶ。
清に滅ぼされた明朝に使えていた朱舜水というヘタレが、尻尾を巻いて日本に逃げてきて、水戸光圀に保護される。コイツが王朝の正統論という馬鹿げた概念を、大日本史にもたらす。大日本史は、当時、日本を実効支配していたのは北朝だったにもかかわらず、天皇側の王朝であった南朝を正統に選ぶ。
幕末明治になって、人々は将軍に変わる、新たな王を欲していた。実質には、王が絶対的な権力を持ってはいないのだが、建前として、そういう精神的な指導者が必要だった。そこで、南朝の子孫として続いてきた天皇を担ぎ上げるため、南朝こそが正統な王朝だったと主張した。トンデモ論の集大成である大日本史も、ここで日の目を見ることになった。

案外、歴史は単純なのかもしれない。そういう意味で、私は秀忠と慶喜を尊敬する。彼らは歴史に名を残さず、而も世に多大な影響を及ぼすことに成功した人物なのだから。

2009-06-23

ブラウザって何？

一般人には、ブラウザと検索サイトの区別が付かないというお話。ブラウザと検索サイトが区別できないような人間が、ブラウザのアップデートを手動で行うわけがない。

私は正直に告白する。私には、上記のnoob達は、こんな風に見えている。

canvasとjavascriptによる赤目補正処理

redeye.7z

canvasとJavascriptで赤目補正をするサンプル。赤目の部分だけをぐりぐりと塗りつぶせば、補正完了。なんと修正した画像の保存機能まで付いているというスグレモノ。こんなことがHTMLとJavascriptだけでできるなんて、いい時代になった物だ。

クロスドメイン問題から、このブログで動かすことはできないので、こういう形を取った。落として、解凍して、実行できる。もはやこれは本物のプログラムだから、実行という言葉は正しいと思う。

動作確認は、Chrome 3 、Opera 10、Safari 4で行った。Firefoxでは、前述の通り、ローカル上のoriginを違うと判定する他のブラウザとは違った挙動があるので使えない。一応、修正後のプレビュー表示をやめれば、修正自体はできるのだが、何にせよ画像保存ができないので、意味はない。

参考：http://disruptive-innovations.com/zoo/demos/eyes.html

追記：Firefoxで動かすには、二つ方法がある。まずひとつは、どこかのサーバー上からアクセスすることだ。（試していないが、ローカルサーバーでもいいと思う）。今ひとつは、security.fileuri.strict_origin_policyをfalseにすることである。Firefoxの思想では、ローカル上のファイルとはいえ、originは同じではないらしい。実際、それは間違いではない。

firefoxのcanvasにおける不思議なorigin判定

ローカル上のドキュメントから見て、ローカル上のおなじディレクトリ内のファイルに対して、originが違うと判断する。

再現方法：ローカルディスクの同じディレクトリに、HTMLファイルと画像ファイルを置く。HTMLファイルで、canvas上に画像ファイルを描画する。而る後に、そのcanvasに対して、toDataURL()を呼び出す。あるいは、canvasのcontextに対して、getImageData()を呼び出す。

Firefoxの場合、SECURITY_ERR例外が投げられる。

ローカル上の、それも同じディレクトリ内にあるファイルなのだから、originは同じはずだ。なぜかFirefoxだけ例外が投げられる。なお、ローカルではない場合は、Firefoxは正しく動作する。

問題は、ローカル上のファイルをどう扱うかというのは、定義されていないということだ。

If scheme is "file", then the user agent may return a UA-specific value.

http://dev.w3.org/html5/spec/Overview.html#origin-0

しかし、ローカル上のドキュメントの場合、同じディレクトリの中にあるファイルは、same originと判断しても差し支えないのではあるまいか。

ちなみに、Chrome、Safari、Operaでは、ローカル上のドキュメントから見て、ローカル上のファイルは、同じディレクトリにあろうがなかろうが、すべて、同じoriginだと判断される。

テストコード

マーケティング上どうなんだというサイト

The youlove.us scrolling background effect explained | youlove.us

なるほど、そりゃ確かにクールなエフェクトだよ。でもねぇ、このサイトのページを見ると、CPUが爆速で回転し始めるんだよね。どのブラウザで試しても、CPUコアを一つ浪費してしまう。一昔前ならブラクラもののとんでもないWebサイトだ。こんなサイトを自社サイトとして公開していて（デモじゃなくてあらゆる所で）、We make awesome web sitesなどと、どの口で言えるんだろう。「We make shitty web sites that will completely suck up your CPU time」とでも文面を買えた方がいいんじゃないだろうか。

まあ、たったの4000pxの画像ひとつスクロールさせるだけで、こんなにもCPUを浪費するブラウザもどうかと思うけれど、すべてのブラウザがこうなんだから仕方がない。というか、アニメーションは100秒で終わるように読めるのだけれど、いつまでたっても終わらない。

2009-06-22

canvasによる画像処理

http://disruptive-innovations.com/zoo/demos/eyes.htmlに触発されて、canvasによる赤目補正の画像処理を書いた。なかなか面白い。クロスドメインの問題で、このブログ上で動くサンプルを公開できない使えないのが残念だ。

ニュースサイトの過去と現在

真理だと思う。

本当に、世の中には見にくいページが多い。広告は、いいとしよう。有益な情報にはカネが必要だ。問題はそれ以外の部分で、見にくいページが多いということだ。

例えば、ひとつの文章を、いくつものページに分けているサイトだ。全部読むには、わざわざページをたどっていかなければならない。読んでいるうちに、前のページの情報を参照したくなったとする。戻るにせよ、別タブで開くにせ、読みにくい事この上ない。そして追い打ちをかけるように、サイズ固定。WUXGAのディスプレイで見ているとマヌケでしかない。その手のサイトをデザインする輩は、目が不自由なのだろうと、常日頃から思っている次第である。

RSS/ATOMフィードも、読みにくいサイトが多い。例えば、タイトルしか出さないフィードや、内容の一部しか出さないフィードのことだ。はてなダイアリーの初期設定は、記事内容の一部しかフィードで出さないようになっている。アホとしかいいようがない。何のためのフィードだ。フィードは人間のためだけにあるのではない。検索エンジンも、フィードを見ているのだ。フィードは単純で、まさに検索エンジンのためにうってつけの情報だ。それを、一部しか提供しない。全く提供しないのと、何の違いがあるというのやら。

ちなみに、このブログは、私の理想とするデザインとなっている。文字色は黒、背景は薄いグレー。文字サイズはピクセル数やポイント数で指定しない上に、すべてのブラウザで大きめに描画されるようにする。ブラウザのウインドウサイズめいっぱい表示する。画像は極力使わない。

canvasにはクロスドメインの問題があった

canvasでは、ピクセルを直接読み書きできる。それって、別ドメインソースの画像を描画した時、セキュリティ上の問題があるんじゃないかな、とは思っていた。

さて、今日はcanvasで画像処理を行っていた。canvasで画像処理をしようなどと思うアホは、なかなかいないと思われるので、少々の自負心があるということは、認めなければならない。ローカルの画像では、それなりに動いたので、ネット上の画像をソースにしてテストしてみることにした。ところが、何故か動かない。エラーコンソールを見ると、SECURITY_ERR例外が投げられている。

クロスドメインの問題は、ぬかりなく規定されていた。
Security with canvas elements

さすがだ。やれやれ、Cross-Origin Resource Sharingが広まるのを待つしかないのだろうか。

つぶやき

HTML5のcanvasのImageData周りを試しているが、どうにもうまく動かない。他人の書いたサンプルは動くので、ブラウザの問題ではないのだろう。試行錯誤中。

このjavascriptの外にも、HTMLやDOM、CSSといった風に、細かくラベルを分けるべきだろうか。

そういえば昼飯をまだ食べていなかった。

あまりブログにふさわしい投稿ではない。やはり、ブログはTwitterにはなれないらしい。しかし、Twitterの利点は分からない。後から見直したり、検索したりするのには、すこぶる都合が悪い。

カメラは違法？

高木浩光＠自宅の日記 - グーグル社の東京都への回答「元データは保管していない」は虚偽か
 情報公開・個人情報保護審議会(第39回議事録)｜東京都

法律には詳しくないが、何か引っかかるな。元データを保管するだけで（公開するのではなく）、法的な問題になるとしたら、公共の場所、例えば道ばたで、携帯のカメラで動画を撮るのも、同様にして違法になるのではないか。じゃあ、カメラはどうやったら合法的に使えるのだろう。

カメラを使う際には、絶対に人物車建物その他の個人情報を特定されうるものがうつらないように、極端な注意を払わなければならないのだろうか。その画像を公開しなかったとしても、そうしなければならないのだろうか。

テレビ局は、その手の公共の場の動画を、日々撮影して保管していると思うが、これは問題にならないのだろうか。

公共の場でのカメラの使用を違法にした方が早い気がする。

2009-06-21

getAttributeの実装が規格通りではない

W3Cの規格では、getAttributeの戻り値は、以下のように規定されている。

The Attr value as a string, or the empty string if that attribute does not have a specified or default value.

なるほど、指定された属性が場合は、empty stringを返すのだな。と思って、ある属性があるかどうかを判断するコードを、そのように書いた所、何故か動かなかった。不思議に思って調べてみると、どうやら、すべてのブラウザで、nullを返している。何故だろう。W3Cの規格では、nullを返すべき所は、ちゃんとnullを返すように書かれている。何故ここは、empty stringを返すと規定されていて、しかもすべてのブラウザで、nullを返すように実装されているのか。不思議だ。

こうなってくると、規格が間違っているのじゃないかと思わざるをえない。

追記：https://developer.mozilla.org/En/DOM/Element.getAttribute

やれやれ。まあ、今さら変更すると動かなくなるコードばかりなんだろうなぁ。属性があるかどうかを確かめるには、hasAttribute()が使える。

主要なブラウザでテストした結果。属性がない場合はnullが、属性はあるが、""を指定してある場合は、empty stringが帰ってくる。なんとも面倒な事だ。

ユーザースクリプトは楽し

javascriptを覚えたので、ここらで一つ、ユーザースクリプトでも書いてみたい。しかし、今現在、自分では、とくに欲しい機能がない。そこで、適当に他人の欲しがっている機能を実現してみることにした。

図書館員がAmazonの検索を好きになれないたった一つの理由 - そうだ、図書館へ行こう！

選んだ理由は、たんにはてなブックマークの人気エントリーに上がっていただけだ。なるほど、発売日などの情報を、すぐに見たいという望みらしい。さっそく書いてみよう。

// ==UserScript==
// @name　　　　Amazon Mod
// @namespace　 http://cpplover.blogspot.com/
// @description move Amazon's Product Details to under the product name.
// @include　　 http://www.amazon.*/*
// ==/UserScript==

(function()
{
var holder = document.querySelector("div.buying h1.parseasinTitle") ;
if ( holder === null )
　　　　return ;

holder = holder.parentNode ;

var list = document.querySelectorAll("tbody td.bucket > div.content > ul > li") ;
if ( list.length === 0 )
 return ; 

var elem = document.createElement("ul") ;

for ( var i = 0 ; i !== list.length ; ++i )
{
　　if ( !list.item(i).getAttribute("id") && !list.item(i).getAttribute("class") )
　　　　elem.appendChild( list.item(i) ) ;
}

holder.appendChild(elem) ;
})() ;

上記のコードをユーザースクリプトとして使えば、アマゾンの商品名の下に、登録情報が表示されるようになる。とりあえず、amazon.co.jpとamazon.comでは動いた。

ユーザースクリプトになじみのない場合、このリンクをブックマークして、アマゾンのページで使うこともできる。

Chrome 3、Firefox 3.5、Opera 10、Safari 4で動くことを確認。問題は、querySelectorが、かなり最新のW3C規格だと云うことだ。jQueryなどのライブラリを使えば、最新ではないブラウザで動作させることも可能だろう。

なるほど、ユーザースクリプトは面白い。

しかし、ブラウザがjavascriptの実行に寛大なのは如何ともしがたい。list.item(i).getAttribute("class")の代わりに、list.item(i).classと書いても、Firefox、Opera、Chromeでは、問題なく実行できてしまった。もちろん、classは予約語なので、本来エラーになるべきである。エラーを出してくれたのはSafariのみ。なるほど、Safariは開発用として悪くないブラウザだ。また、最初は、querySelector("div.buying h1.parseasinTitle").parentNodeとしていたのだが、Safariはこれにもエラーを出してくれた。すばらしい。たしかにquerySelectorはnullを返す可能性があり、その場合、parentNodeを呼び出すのはエラーになる。Safariはなかなかやるブラウザだ。これからは、javascriptのコーディングにはSafariを用いようと思う。

ブラウザは強制アップデートするべきだと思う

Firefox.nextのセキュリティアップデートはGoogle Chromeに近づく - Mozilla Flux
http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/f6e197f572d8ac6e#

ブラウザは、もはや欠くべからざる物である。Webブラウザなしでのインターネットなど、今日では到底考えられないことだ。コンピューターにOSが必要なように、インターネットにはブラウザが必要である。してみれば、そのブラウザのセキュリティホールやバグや規格準拠の割合は、とても重要である。すべてのブラウザは、可及的速やか且つ静かなアップデート機能を提供すべきである。

セキュリティは重要である。ただし、たとえ本人が完璧に気をつけていても、使っているソフトウェアにセキュリティホールがあれば、どうしようもない。ただし、セキュリティホールを突くmalwareのほぼすべては、すでによく知られて、しかも修正パッチが出ているセキュリティホールを利用している。それも半年や一年も前にパッチがでていたという事も、珍しくない。zero-day vulnerabilitiesを利用する、実用的なmalwareは、そうそう現れる物ではない。

バグや規格準拠の悪さに起因する、ブラウザ別のブランチコード、これは最悪である。こんな最悪なコードでも、書かなければならないのは、ユーザーが古いブラウザを、使い続けるからである。ブラウザに自動アップデート機能があれば、Developer達は、そんなコードを書かなくなるはずだ。

バカなユーザーは、あたかも宗教的とも呼べる理由で、古いバージョンのソフトウェアに固執する。この宗教的盲信を、教育によって解くことは不可能である。そこで、OSやブラウザのアップデートは、できるだけ静かに、自動的に行うべきだろう。

canvasのサンプルを更新した

HTML5のcanvasを使ってみた

四角形を動かす時に、差分の時間を取得するようにした。これで、FPSに依存せずに描画できる。FPSとmiliseconds per frameと四角形の数を表示するようにしてみた。FPSは本来、パフォーマンスの比較する値として使うべきではないのだが、まあ、広く知られているのはFPSの方なので、一応、表示しておいた。

ところで、改めて試していて気がついたことがある。Safariで、描画する四角形の数が増えると、急に遅くなるのは何故だろうと思っていたが、どうもこれは、Safariが描画できていないのではなく、わざと描画していないのだと思う。canvasではなく、javascriptの問題だと思う。おそらく、あまりにも重いJavascriptは、ユーザーの入力がなければ、実行しない設計になっているのだろう。何かのキーを押し続けると、描画が始まる。ユーザー側からみれば、クソ重いJavascriptなど実行されてもしょうがないので、悪くはない機能だと言える。いかにもユーザーの心をとらえるAppleの考えそうなことだ。将来canvasでの描画が一般的になったとき、はたしてこの仕様をそのまま続けられるだろうか。Flashと同じ土俵にたつならば、この仕様はいただけない。

肝心のパフォーマンスだが、最新のブラウザで試してみた所、Chromeがブッチギリで早い。私の環境では、200個ほどのアニメーションを動かしても、16 miliseconds per frameを維持している。これは、webkitのcanvasの描画の早さと、V8のjavascriptの実行の早さが関係しているのだろう。

次いで、Safariが早い。ただし、safariで描画させるためには、絶えずキーボードの何かのキーを押し続ける必要がある。SafariのNitroは、V8と同じくネイティブコードを生成するので、Chromeと比べて倍ほど遅いのは、このユーザーの入力なしでは、重いJavascriptを実行しない機構が、足かせになっている部分もあるのではないかと思う。

Firefoxは遅い。これはjavascriptが遅いのではないかと思う。

Operaは正直にいって、使い物にならないほど遅い。静的なコンテンツを表示するならともかく、ゲームのような動的な描画には、向いていない。これは、canvasの遅さと云うよりも、javascriptが根本的に遅いためだと思われる。

FirefoxもOperaも、現在、ネイティブコードを生成するJavascriptの開発に力を注いでいる。もはやJavascriptは、単なるHTMLのオマケの域を超えて、本物のプログラムとして認識されるに至ったからだろう。

なお、上記のテストは、すべて最新のブラウザで行った。ベータ版があるブラウザは、それを使った。

Web規格に関する批判的感想

XML

XML宣言のencodingは、無駄である。そもそも、ASCII互換ではない文字コードもあるし、一文字に対するバイト数が混在する文字コードもある。

document type宣言も、無駄である。

DTDは、およそ設計されうるschemaの中で、最悪の物だ。だからこそ、多くの独自schemaが生まれた。DTDは、実態参照のためぐらいにしか使わない方がいいだろう。

xml:lang属性は無駄である。確かに標準の属性はあってもいいかもしれないが、明確に言語を指定したい場合以外は、無駄でしかない。なぜなら、文章中に複数の言語が混じることはよくあることだからだ。

W3C規格の最近の過ち

モジュール化は、大いなる過ちである。すべての環境でサポートされている機能でなければ、使いたいとは思わない。これはWebに限らず当てはまる。DirectXの歴史なんて、ひどい物だった。

現実に即していない機能が多すぎる。例えば、現実に使われているCSSのselectorを見れば、その机上の空論が分かると思う。最近は、二つ以上の実装がないと勧告しないようにしているらしい。まあ、多少はマシだろう。

そのくせ、本当に欲しい機能は、直接に規定されていないという事実。なぜマウスイベントにoffsetX, offsetY相当の機能がないのだ。

XHTML

document type宣言でどの規格を使用するか宣言すること。あれは失敗だった。

HTML5

HTMLとDOMをごっちゃにしていること。間違っている。なぜみなHTML5を使いたいかというと、HTML5にvideoやaudioやcanvasがあるからだ。あくまで使いたい機能があるからであって、規格が優れているからではない。実際、canvasの設計は、あまり褒められた物ではないと思う。とくに、行列周りは、個人的に好かない。なんで演算が逆順なんだよ。ふざけているのか。

2009-06-20

芋粥

芋粥といえば、芥川竜之介の芋粥が有名だ。しかし、あれは駄作である。芥川竜之介は、古典を曲解すること甚だしく、全然、別の物語になってしまっている。むしろその解釈の違いが狙いだという肯定的な意見もあるが、それは、芥川竜之介というのが天才だったという世間の評価に影響されての弁護に過ぎない。第一、今昔物語や宇治拾遺物語を見れば分かるように、芥川竜之介は、両書に共通して出てくる、ある重要な事柄を一つ、書き漏らしている。これだけをもって、芥川竜之介は古典を尊重していないと結論するに足る。

ところで、芋粥とは何ぞや。これは、山芋を甘葛のシロップで煮込んだお粥のことらしい。この話を真に理解するため、私は芋粥を作ることにした。

まず材料だが、山芋というのは、手に入りにくい。どうやら、山芋は栽培が難しいらしい。したがって、普通に売っている山芋は、かなり値が張る。そこで、今回は長芋を用いることにした。これなら安い。
山芋は、高いとはいえ、入手はさほど難しくない。問題は甘葛だ。甘葛というのは、当時の甘味料のことだ。値段以前の問題で、まず、売っている場所を見つけるのが難しい。そこでしかたなく、砂糖を使うことにした。当時から考えれば、結晶の状態の糖なんて、夢のような甘味料だったに違いない。それこそ甘葛など比べものにならない、伝説の物質と云ってもいい代物だ。どこのスーパーでも、キロ単位で売っている今となっては、全くありがたみがないのだけれど。

長芋を薄く切り、茶碗一杯分食べ残していたご飯に、砂糖をガバガバ入れて、煮込んだ。

私は、砂糖を入れた粥などというものは、生まれてこの方食べたことがない。果たしてウマいのであろうか。

まずい。いやになるぐらいまずい。確かに、米と砂糖の相性は悪くない。しかし、やはり甘ったるい。これはチョコレートや清涼飲料水の甘さと違い、とても不快な甘ったるさがある。とてもじゃないが、飽きるほど食べたいものではない。さらにひどいことに、長芋は、大量の砂糖で煮込んでも、全く甘くならない。つまり、甘ったるい米の中に、全然甘くない芋が混在しているのだ。これは最悪だ。

五位が一盛りをだにえ喰わずなりける理由が、明らかに実感できる。これはダメだ。体が受け付けない。なるほど、五位は日頃の望みが叶ってしまって幻滅したわけではなかったのだ。単に甘ったるい物にうんざりしただけだろう。当時は今と違い、ハッキリとした甘い物が貴重であったにせよ、味覚は、昔の人も今の人も、変わっていないはずだ。とするならば、当時、この甘い粥を食べても、うんざりしたことであろう。これは「飽きる」という言葉で表されべき感覚ではない。とにかく最悪だ。

今昔物語、第二十六巻第十七話
利仁将軍若き時、京より敦賀に五位を将て行く語

今昔、利仁の将軍と云人有けり。若かりける時は、□□と申ける。その時の一の人の御許に、恪勤になん候ける。越前国に、□の有仁と云ける勢徳の者の聟にてなん有ければ、常に彼国にぞ住ける。

而る間、其主の殿に、正月に大饗被行けるに、当初は大饗畢ぬれば、取食と云者をば追て不入して、大饗の下をば、其殿の侍共なん食ける。それに、其殿に、年来に成て所得たる五位侍有けり。其大饗の下、侍共の食ける中に、此五位、其座にて暑預粥を飲て舌打をして、「哀れ、何かで暑預粥に飽かん」と云ければ、利仁此を聞て、「大夫殿、未だ暑預粥に飽せ不給か」と云へば、五位、「未だ不飽侍」と答ふ。利仁、「いで、飲飽せ奉らばや」といへば、五位「何に喜ふ侍ん」と云て止ぬ。

其後、四五日計有て、此五位は殿の内に曹司住にて有ければ、利仁来て、五位に云く、「去来させ給へ、大夫殿。東山の辺に湯涌して候ふ所に」と。五位、「糸喜く侍る事哉。今夜身の痒かりて、否寝入不侍つるに。但し、乗物こそ侍らね」と云へば、利仁、「此に馬は候ふ」といへば、五位、「穴喜」と云て、薄綿の衣二つ計、青鈍の指貫の裾壊たるに、同色の狩衣の肩少し落たるを着て、下の袴も着ず、鼻高なる者の、鼻崎は赤にて、穴の移り痛く湿ばみたるは、洟を糸も巾ぬなめりと見え、狩衣の後は、帯に被引喎たるを、引も不は、喎乍らあれば、可咲ども、五位を前に立てヽ、共に馬に乗て、川原様に打出て行。五位の共には、賤の小童だに無し。利仁が共にも、調度一人、舎人男一人ぞ有ける。

然て、川原打過て、粟田口に懸るに、五位、「何こぞ」ととへば、利仁、「只此也」とて、山科も過ぬ。五位、「近き所とて、山科も過ぬるは」といへば、利仁、「只彼計也」とて、関山も過て、三井寺に知たりける僧の許に行着ぬ。五位、「然は此に湯涌たりけるか」とて、其をだに、「物狂はしく遠かりける」と思ふに、房主の僧、「不思懸」と云て経営す。然ども、湯有り気も無し。五位、「何ら、湯は」といへば、利仁、「実には、敦賀へ将奉る也」と云ば、五位、「糸物狂はしかりける人哉。京にて此く宣はましかば、下人なども具すべかりける者を。無下に人も無て、然る遠道をば、何かで行んと為ぞ。怖し気に」といへば、利仁疵咲て、「己れ一人が侍るは、千人と思せ」と云ふぞ理なるや。此て物など食つれば、急ぎ出ぬ。利仁、其にてぞ胡録取て負ける。

然て、行程に、三津の浜に狐一つ走り出たり。利仁、此を見て、「吉使出来にたり」と云て、狐を押懸れば、狐、身を棄て逃といへども、只責に被責て、否不逃遁を、利仁、馬の腹に落下て、狐の尻の足を取て引上つ。乗たる馬、糸賢しと不見ども、極き一物にて有ければ、幾も不延さ。五位、狐を捕へたる所に馳着たれば、利仁、狐を提て云く、「汝ぢ狐、今夜の内に、利仁が敦賀の家に罷て云む様は、『俄に客人具し奉て下る也。明日の巳時に、高島の辺に男共迎へに、馬二疋に鞍置て、可詣来』と。此を不云は、汝狐、只試よ。狐は変化有者なれば、必ず今日の内に行着ていへ」とて放てば、五位、「広量の御使哉」といへば、利仁、「今御覧ぜよ。不罷では否有じ」と云に合、狐実に見返前に走て行、と見程に失ぬ。

然て、其夜は道に留ぬ。朝に疾く打出て行程に、実に巳時計に、二三十町計凝て来る者有り。何にか有んと見るに、利仁、「昨日の狐、罷着て告侍にけり。男共詣来にたり」といへば、五位、「不定の事哉」と云程に、只近に近く成て、はらと下るまヽに云く、「此見よ、実御ましたりけり」といへば、利仁、頰咲て、「何事ぞ」と問へば、長しき郎等進来たるに、「馬は有や」と問へば、「二疋候ふ」とて、食物など調へて持来れば、其辺に下居て食ふ。

其時に、有つる長しき郎等の云く、「夜前、希有のことこそ候しか」と。利仁、「何事ぞ」と問へば、郎等の云く、「夜前、戌時計に、御前の、俄に胸を切て病せ給ひしかば、何なる事にかと思ひ候ひし程に、御自ら被仰様、『己は、別の事にも不候此昼三津の浜にて、殿の俄に京より下らせ給けるに、会奉たりつれば、逃候つれども、否不逃得で被捕奉たりつるに、被仰る様、『汝、今日の内に我家に行着て、云ん様は、客人具し奉てなん俄に下るを、明日の巳時に、馬二疋に鞍置て、男共高島の辺りに参り合へ、といへ、若、今日の内に行着て不云は、辛き目見せんずるぞ』と被仰つる也。男共、速に出立て参れ。遅く参ては、我勘当蒙なん』とて、怖じ騒せ給つれば、『事にも候ぬ事也』とて、男共に召仰候つれば、立所に例様に成せ給て、其後、鳥と共に参りつる也」と。利仁、此を聞て頰咲て、五位に見合すれば、五位、奇異と思たり。

物など食畢て、急立て行程に、暗にぞ家に行着たる。「此みよ。実也けり」とて、家の内騒ぎ喤る。五位馬より下て家の様を見に、脺はヽしき事物に不似。本着たりし衣二つが上に、利仁が宿直物を着たれども、身の内し透たりければ、極く寒気なるに長櫃に火多く□□て、畳厚く敷たるに、菓子食物など儲たる様微妙也。「道の程寒く御ますらん」とて、練色の衣の綿厚を、三つ引重て打覆たれば、楽と云ば愚也や。

食喰などして静りて後、舅の有仁出来て、「此は何に、俄には下せ給せて、御使の様物狂はしき。上俄病給ふ、糸不便の事也」といへば、利仁、打咲て、「試むと思給へて申たりつる事を、実に詣来て、告候ひけるにこそ」といへば、舅も咲て、「希有の事也」とて、「抑も、具し奉らせ給ひたなる人とは、此御ます殿の御事か」とヽへば、利仁、「然に候。暑預粥に未不飽と被仰れば、飽せ奉らんとて将奉たる也」といへば、舅、「安き物にも飽せ不給ける哉」とて戯るれば、五位、「東山に湯涌たりとて、人を謀出て、此く宣ふ也」などいへば、戯れて、夜少し深更ぬれば、舅も返入ぬ。

五位も、寝所と思しき所に入て寝むと為るに、其に綿四五寸計有直垂有。本の薄は六借く、亦何の有にや、痒き所出来にたれば、皆脱棄て、練色の衣三が上に、此直垂を引着て臥たる心地、未だ不習に、汗水にて臥したるに、傍に人の入気色有。「誰そ」と問へば、女音にて、「御足参れと候へば、参り候ひつる」と云気ひ不ば、掻寄て、風の入所に臥せたり。

而る間、物高く云音は何ぞと聞ば、男の叫て云様、「此辺の下人承はれ。明旦の卯時に、切口三寸、長さ五尺の暑預、各一筋づヽ持参れ」と云也けり。奇異くも云哉と聞て寝入ぬ。未だ暁に聞ば、庭に筵敷音す。何態為にか有むと聞に、夜暁て蔀上たるに、見れば、長筵をぞ四五枚敷たる。何の料にか有むと思ふ程に、下衆男の、木の様なる物を一筋打置て去ぬ。其後、打次き持来つヽ置を見れば、実に口三四寸計の暑預の長さ五六尺計なるを、持来て置。巳時まで置たれば、居たる屋計に置積つ。夜前叫びしは、早ふ、其辺に有下人の限りに物云ひ聞する。人呼の岳とて有、墓の上にして云也けり。只、其の音の及ぶ限の下人共の持来るだに、然計多かり。何況や、去たる従者共の多さ、可思遣。

奇異と見居たる程に、斛納釜共五つ六ほど掻持来て、俄に杭共を打て居へ渡しつヽ、何の料ぞと見程に、白き布のと云物着て、中帯して、若やかに穢気無き下衆女共の、白く新き桶に水を入て持来て、此釜共に入る。何ぞの湯涌すぞと見れば、此水と見は味煎也けり。亦、若き男共十余人計出来て、袪より手を出して、薄き刀の長やかなるを以て此の暑預を削つヽ撫切に切る。早ふ、暑預粥を煮也けり。見に、可食心地不為、返ては踈しく成ぬ。さらと煮返して、「暑預粥出来にたり」と云へば、「参らせよ」とて、大きなる土器して、銀の提の斗納計なる三つ四つ計に汲入て、持来たるに、一盛だに否不食で、「飽にたり」と云へば、極く咲て集り居て、「客人の御徳に暑預粥食」など云ひ嘲り合へり。

而る間、向ひなる屋の檐、狐指臨き居たるを、利仁見付て、「御覧ぜよ、昨日の狐の見参するを」とて、「彼れに物食せよ」と云へば、食はするを打食て去にけり。

此て、五位、一月計有に、万づ楽き事無限。然て、上けるに、仮・納の装束数下調へて渡しけり。亦、綾・絹・綿など皮子数に入て取せたりけり。前の衣直などは然也。亦、吉馬に鞍置て牜など加へて取せければ、皆得、富て上にけり。

実に、所に付て、年来に成て被免たる者は、此る事なん自然ら有ける、となん語り伝へたるとや。

宇治拾遺集、利仁芋粥事

今は昔、利仁の将軍のわかゝりけるとき、そのときの一の人の御もとに格勤して候けるに、正月に大饗せられけるに、そのかみは、大饗はてゝ、とりばみと云ふものを拂いて入れずして、大饗のおろし米とて、給仕したる格勤の者どもの食けるなり。その所に年比になりて、給仕したる者の中にはところえたる五位ありけり。そのおろし米の座にて、芋粥すゝりて、舌うちをして、「あはれいかで芋粥にあかむ」と云ひければ、利仁、これを聞きて、「太夫殿、いまだ芋粥にあかせ給はずや」と問ふ。五位、「いまだあき侍らず」といへば、「あかせたてまつりてんかし」といへば、「かしこく侍らん」とてやみぬ。

さて四五日ばかりありて、曹司住みにてありける所へ、利仁きていふやう、「いざゝせ給へ、湯あみに、太夫殿」といへば、「いとかしこき事かな。こよひ身のかゆく侍つるに乗物こそは侍らね」といへば、「こゝにあやしの馬ぐして侍り」といへば、「あなうれし〱」といひて、うすわたのきぬ二計に、青鈍の指貫のすそ破(や)れたるに、おなじ色のかり衣の肩すこしおちたるに、したの袴も着ず、鼻だかなるものの、さきはあかみて、あなのあたりぬればみたるは、すゝ鼻をのごはぬなめりと見ゆ。狩衣のうしろは、おびに引ゆがめられたるまゝに、引もつくろはねば、いみじうみぐるし。をかしけれども、さきにたてゝ、われも人も馬にのりて、河原ざまにうち出ぬ。五位の共には、あやしの童だになし。利仁が共には、調度懸、舎人、雑色ひとりぞありける。河原うち過て、粟田口にかゝるに、「いづくへぞ」と問へば、「たゞこゝぞここぞ」とて、山科もすぎぬ。「こはいかに、こゝぞ＼／とて、山しなも過しつるは」といへば、「あしこ〱」とて、関山も過ぬ。「こゝぞ〱」とて、三井寺にしりたる僧のもとにいきたれば、こゝに湯わかすかと思ふだにも、物ぐるおしう遠かりけりと思に、こゝにも、湯ありげもなし。「いづら、湯は」といへば、「まことは敦賀へ率(ゐ)て奉る也」といへば、「物ぐるほしうおはしける。京にて、さとの給はましかば、下人なども具すべかりけるを」といへば、利仁、あざわらひて、「利仁ひとり侍らば、千人とおぼせ」といふ。かくて、物など食ていそぎいでぬ。そこにて利仁やなぐひとりて負ひける。

かくてゆく程に、みつの濱に、狐の一、はしり出たるをみて、「よき使出来たり」とて、利仁、狐をゝしかくれば、狐、身をなげて迯れども、をひせめられて、えにげず。おちかゝりて、狐の尻足を取て引あげつ。乗たる馬、いとかしこしともみえざりつれども、いみじき逸物にてありければ、いくばくものばさずしてとらへたるところに、この五位走らせて行つきたれば、狐を引あげていふやうは、「わ狐、こよひのうちに、利仁が家のつるにまかりていはんやうは、「にはかに客人をぐし奉りてくだる也。明日の巳の時に、高嶋邊に、をのこ共むかへに、馬にくらをきて、二疋ぐしてまうで来」といへ。もしいはぬ物ならば、わ狐、たゞ心みよ。狐は変化あるものなれば、けふのうちに行つきていへ」とてはなてば、「荒凉の使哉」といふ。「よし御覧ぜよ。まからでは世にあらじ」といふに、はやく狐見返し〱て、前に走り行。「よくまかるめり」と云にあはせて、走先立ちてうせぬ。

かくて、その夜は道にとゞまりて、つとめてとく出て行ほどに、誠に巳時ばかりに、卅騎ばかりよりてくるあり。なにゝかあらんとみるに、をのこどもまうできたりといへば、不定のことかなといふほどに、唯近にちかくなりてはら〱とおるゝほどに、「これ見よ。まことにおはしたるは」といへば、利仁うちほゝえみて何ごとぞとゝふ。おとなしき郎等すゝみきて、「希有の事の候つるなり」といふ。まづ、「馬はありや」といへば、「二疋さぶらふ」といふ。食物などして来ければ、そのほどにおりゐてくふつゐでに、おとなしき郎等のいふやう、「夜べけうのことのさぶらひしなり。戌の時ばかりに臺盤所の、むねをきりにきりてやませ給しかば、いかなることにかとて、にはかに僧めさんなど、さはがせ給しほどに、てづから仰さぶらふやう、「なにかさはがせ給。おのれは狐なり。別のことなし。この五日、みつの濱にて、殿の下らせ給つるにあひたてまつりたりつるに、逃げつれど、え逃げで、とらへられ奉りたりつるに、「けふのうちにわが家にいきつきて、客人ぐし奉りてなんくだる。あす巳時に馬二にくらをきてぐしてをのこども高島の津にまいりあへといへ。もしけふのうちにいきつきていはずば。からきめみせんずるぞ」とおほせられつるなり。をのこどもとくとく出立てまいれ。をそくまいらば。我は勘当かうぶりなん」とおぢさはがせ給つれば、をのこどもにめしおほせさぶらひつれば、例ざまにならせ給にき。その後鳥とともに参さぶらひつるなり」といへば、利仁、うちえみて、五位に見あはすれば、五位あさましと思たり。物などくひはてゝいそぎたちてくら〲に行つきぬ。」これ見よ。まことなりけり」とあざみあひたり。

五位は馬よりおりて家のさまをみるに、にぎはしくめでたきこと物にもにず、もと着たる衣(きぬ)二がうへに、利仁が宿衣をきせたれども、身の中しすきたるべければ、いみじう寒げに思ひたるに、ながすびつに火をおほふおこしたり。たゝみあつらかにしきて、くだ物くひ物しまうけて、たのしくおぼゆるに、「道の程さむくおはしつらん」とて、ねり色の衣(きぬ)の綿あつらかなる、三ひきかさねてもてきて、うちおほひたるに、たのしとはおろかなり。物くひなどして、ことしづまりたるに、しうとの有仁、いできていふやう、「こはいかで、かくはわたらせ給へるに、これにあはせて御使のさま物ぐるおしうて、うへ、にはかにやませたてまつり給ふ。けうの事なり」といへば、利仁うちわらひて、物の心みんとおもひてしたりつる事を、まことにまうできて、つげて侍るにこそあんなれ」といへば、しうともわらひて、「希有のことなり」といふ。「具し奉らせ給つらん人は、このおはします殿の御事ぞ」といへば、「さに侍り、「芋粥にいまだ飽かず」と仰せらるれば、飽かせ奉らんとて、率てたてまつりたる」といへば、「やすき物にも、えあかせ給はざりけるかな」とて、たはぶるれば、五位、「東山に湯わかしたりとて、人をはかりて、かくの給なり」など、いひたはぶれて、夜すこしふけぬれば、しうとも入ぬ。寝所とおぼしきところに、五位入てねんとするに、綿四五寸ばかりあるひたゝれあり。我もとのうすわたはむつかしう、何のあるにか、かゆき所もいでくるきぬなれば、ぬぎをきて、ねり色のきぬ三がうへに、このとのゐ物ひき着ては、臥したる心、いまだならはぬに気もあげつべし。あせ水にて臥したるに、又、かたはらに人のはたらけば、「たぞ」とゝへば、「「御あしたまへ」と候へば、参りつる也」といふ。けはひにくからねば、かきふせて、風のむく所にふせたり。かゝるほどに、物たかくいふこゑす。何事ぞときけば、をのこのさけびていふやう、「このへんの下人、うけたまはれ。あすのうの時に、切口三寸、ながさ五尺の芋、おの〱一すぢづゝもてまいれ」といふ也けり。あさましうおほのかにもいふものかなと、きゝてねいりぬ。あかつき方にきけば、庭に莚しくをとのするを、なにわざするにかあらんときくに、こやたうばんよりはじめて、おきたちてゐたるほどに、蔀あけたるに、みれば、ながむしろをぞ、四五枚しきたる。なにの料にかあらんとみるほどに、げす男の、木のやうなる物をかたにうちかけて来て、一すぢをきていぬ。その後、うちつゞきもてきつゝをくをみれば、まことに口三寸ばかりのいもの、五六尺ばかりなるを、一すぢづゝもてきてをくとすれど、巳のときまでをきければ、ゐたる屋とひとしくをきなしつ。夜べさけびしは、はやうそのへんにある下人の限りに物いひきかすとて、人よびの岡とて、あるつかのうへにていふなりけり。たゞそのこゑの及ぶかぎりのめぐりの下人のかぎりもてくるにだに、さばかりおほかり。ましてたちのきたる従者どものおほさをおもひやるべし。あさましとみたるほどに、五石なはのかまを五六舁もてきて、庭にくゐどもうちて、すへわたしたり。何の料ぞとみるほどに、しぼぎぬのあをといふもの着て、帯して、わかやかにきたなげなき女どもの、しろくあたらしき桶に水を入て、此釜どもにさくさくといる。何ぞ湯わかすかとみれば、この水とみるはみせんなりけり。わかきをのこどもの、袂より手出したる、うすらかなる刀のながやかなるもたるが、十余人ばかりいできて、このいもをむきつゝ、すきゞりにきれば、はやく芋粥煮る也けりとみるに、くふべき心ちもせず、かへりてはうとましく成にけり。さら〱とかへらかして、「芋粥いでまうできにたり」といふ。「まいらせよ」とて、先、大なるかはらけ具して、かねの提の、一斗ばかり入ぬべきに、三四に入て、「かつ」とてもてきたるに、飽きて、一もりをだにえ食はず。あきにたりといへば、いみじうわらひてあつまりてゐて、「客人殿の御とくにいもがゆくひつ」といひあへり。かやうにする程に、向のながやの軒に、狐のさしのぞきてゐたるを、利仁見付て、「かれ御らんぜよ。候し狐の見参するを」とて、「かれに物くはせよ」といひければ、くはするにうちくひてけり。

かくてよろづのこと、たのもしといへばをろかなり。一月ばかりありて、のぼりけるに、けおさめのさうぞくどもあまた具たり。又、たゞの八丈わたぎぬなど、皮子どもに入てとらせ、はじめの夜の直垂はたさらなり、馬にくらをきながらとらせてこそ送りけれ。

きう者なれども所につけて年比になりてゆるされたる物は。さるものゝをのづからあるなりけり。

2009-06-19

javascript 5thの機能

Javascript 5thのドラフト規格を流し読みしてみた。それほど大きな変更は無い。最も大きな変更は、strict modeだと思われる。これは、一部のあまりにも動的なコードを制限する機能のことだ。ひとつのコードの中にstrict modeと、動的で危険なコードを、混在できる。strict modeのコードでなくても、プロパティを付け加えたり消したりするの防ぐする機能などが入っている。

他には、JSONをネイティブにサポートすることや、ライブラリへの細かな変更などだろうか。SetterやGetterは、すでにサポートしているブラウザが多いとはいえ、果たしてそれほど使われるのだろうか。

実際、文法上は、何も変わっていない。だから、いますぐstrict modeで書くことも出来る。

C++一辺倒だったので、もっと動的な言語を学ぼうとしてjavascriptに入ったが、しかし、あまりにも動的過ぎるような気がする。文法が単純なのは、うらやましい限りだが。

なんにしても、言語は複数知っておくべきだと実感した。JavascriptもJavascriptで面白い。

2009-06-18

DOM level 3のマウスイベントにおけるカーソル位置の詳細

マウスイベントは、DOM level 3で定義されている。問題は、規格の定義が曖昧で、ブラウザの実装が救いがたいぐらい異なっているということだ。ここでは、マウスの位置を取得する方法を、完璧に解説しようと思う。とくに、canvasを使うにあたっては、マウスカーソルの位置を取得することは重要だ。

座標とは何か

ここで私の言う座標とは、ある点を(0,0)と置いた場合の、その点からの位置(x,y)のことである。ただし、右下が正になる。これはコンピューターの世界では、一般的な座標系である。では、その基準となるべき「ある点」とはどこか。これが問題である。

次のようなコードを考える。

var mouse_event_listener =
{
        handleEvent : function(event)
        {
                //ここにコードが記述される
        }
} ;

これは、DOM level 3 Eventに準拠するイベントリスナーの、Javascriptによる実装である。このコードをベースに、マウスカーソルの位置を取得したい。

スクリーン座標

var x = event.screenX ;
var y = event.screenY ;

スクリーン座標は、コンピュータのディスプレイの左上を原点とする座標系である。screenX, screenY属性で取得できる。Javascritpでは、同名のプロパティとして実装されている。しかし、これは、現実的には、何の役に立たない。ブラウザ自体がディスプレイのどの位置にいるのかがわからないので、画面上の位置を知ったところで、何にもならないからだ。

ウインドウ座標

var x = event.clientX ;
var x = event.clientY ;

ウインドウ座標とは、現在のブラウザのウインドウの、ドキュメントを表示している部分の左上原点とした座標である。問題は、ウインドウは、必ずしもドキュメント全体を表示するとは限らない。スクロールと呼ばれるUIによって、ドキュメントの一部だけを表示しているかもしれない。

ドキュメント座標

これは、ドキュメント全体に対する座標である。ウインドウ座標が、ドキュメントをすべて表示している場合と考えてもいい。理想は、この座標だ。問題は、この座標を、クロスブラウザな実装で得るのが不可能に近いということだ。これについては最後に解説する。

ある要素からの相対座標

HTML5のcanvasを使う場合、そのcanvas要素の左上を原点とした座標での、マウスカーソルの位置が知りたい場合がよくある。というのも、canvasを使う以上、通常のマークアップ言語を離れた、特殊な描画がしたいのだから、これ自体は不思議ではない。問題は、その方法だ。一体どうすれば、この座標を得られるのだろう。以下に列挙する。

offsetX/offsetY

var x = event.offsetX ;
var y = event.offsetY ;

多くのブラウザで、MouseEvent インターフェースには、offsetXとoffsetYが定義されている。これは、まさに欲している、イベント要素からの相対座標である。問題は、W3Cの規格では定義されていないことと、さらにひどいことに、ブラウザ間で、微妙に異なる実装をしている。そもそも、その要素からの相対座標といっても、具体的にどこを原点とした座標なのか、ということだ。規格では、padding boxの左上を原点としている。ところが、ブラウザによって、原点の取り方が異なる。

IE8は、完璧な実装をしている。
Firefoxでは、サポートしていない。
Safari、Chrome、Konqueror、では、border boxの左上を原点としている。
Operaでは、content boxの左上を原点としている。

ブラウザ間で差異があり、W3C規格で未定義で、Firefoxでサポートしていないことに目をつぶれば、一応この機能は使える。実際に使う際には、要素のpaddingを0pxに設定しておいたほうがいいだろう。

layerX/layerY

var x = event.layerX ;
var y = event.layerY ;

Firefoxのみがサポートしている独自規格で、offsetX、offsetYと機能は同じである。W3C規格には載っていないし、Firefox以外にサポートしているブラウザもない。

ドキュメント座標から、要素への相対座標を得る

今、何らかの方法で、マウスカーソルのドキュメント座標が得られたとする。ここから要素への相対座標を得ることは、可能である。イベントリスナーが登録されている要素からの相対座標を得たいとする。Eventインターフェースには、target属性があり、これを使えば、イベントリスナーが登録されている要素が得られる。Elementインターフェースは、CSSOM View Moduleに定義されているように、offsetLeftと、offsetTop属性を持っている。問題は、これは、親要素からのオフセットだということだ。ある要素の親要素には、さらに親要素が存在する可能性がある。したがって、body要素まで延々と親要素をたどっていかなければならない。いま、x, yにドキュメント座標が入っているとすると、そのコードは以下のようになる。

for ( var p = event.target ; p !== null ; p = p.offsetParent )
{
        x -= p.offsetLeft ;
        y -= p.offsetTop ;
}

body要素のoffsetParentはnullを返すと規定されているので、このコードで、親要素を延々とたどって、相対座標を計算できる。

ドキュメント座標を得る方法

さて、いよいよ本題の、ドキュメント座標を得る方法について解説する。ドキュメント座標が得られれば、上記のoffsetを引くループで、相対座標が得られる。ただし、これがなかなか難しい。

pageX/pageY

var x = event.pageX ;
var y = event.pageY ;

これは、W3C規格では定義されていない。しかし、IE以外の主要なブラウザすべてでサポートされている。これはまさに、ドキュメント座標が得られる。

ウインドウ座標にスクロール分を加算する

// it only worked on webkit.
var x = event.clientX + document.body.scrollLeft ;
var y = event.clientY + document.body.scrollTop ;

// it's worked on Firefox and Opera, but not for webkit.
var x = event.clientX + document.documentElement.scrollLeft ;
var y = event.clientY + document.documentElement.scrollTop ;

// I think this is the perfect solution. but for unknown reason, failed at both Firefox and Opera.
var x = event.clientX + document.getElementsByTagName("body").item(0).scrollLeft ;
var y = event.clientY + document.getElementsByTagName("body").item(0).scrollTop ;

もういやだ。一体body要素のElementインターフェースはどうやって取得すればいいのか。歴史的に、document.bodyが使われてきた。ところが、DOM level 2では、document.documentElementが定義され、かなりのブラウザがそちらに移った。そして、document.bodyが動かなくなった。quirks modeかどうかで、この挙動を変えるブラウザが存在することも、頭を悩ませる。また、HTML5では、document.bodyが規格に入っている。だから、HTMLとDOMを統合したHTML5ならば、document.bodyが正しいということになるし、それ以外なら、DOM level 2の定めるところにより、document.documentElementが正しいといえるのだろう。しかも、たいていのブラウザでは、動かないだけで、実際にはどちらも定義されているので、未定義かどうかでブランチすることも出来ない。したがって、ウインドウ座標からスクロール分を加算してドキュメント座標を得る手法では、ブラウザのブランチが必要不可欠になってしまう。

ところで、三番目のコードは、私としては、正しく動くと期待していたのだが、なぜかwebkit系のブラウザ（SafariとChrome）でしか動かない。もうわけが分からない。

参考

Document Object Model (DOM) Level 3 Core Specification
Document Object Model (DOM) Level 3 Events Specification
CSSOM View Module
HTML5
Javascript Madness: Mouse Events
Javascript - Event properties
Mission Impossible - mouse position | evolt.org
W3C DOM Compatibility - CSS Object Model View

追記：コメント欄より、 CSSOM View ModuleのgetBoundingClientRect()を使う。
基本的に理想主義者の私は、まず先に参考にするのは規格書なので、getBoundingClientRect()の存在は知っていたが、どうもその解説が複雑で、まじめに読む気にならなかった。さて、思い直して読んでみたところ、これはなかなか面白いものだ。これをまじめに解説した日本語の情報がWebあるかどうか、ふとググってみたところ、なかった。そこで、解説してみることにする。

getBoundingClientRect()の仕様を説明するには、まず、getClientRects()を説明しなければならない。これらの二つは、どちらもElementViewインターフェースで定義されており、DOM level 3では、すべてのElementは、ElementViewインターフェースを実装していなければならない。

getClientRects()は、その要素の子のボーダーボックス領域のリストを返す。getBoundingClientRect()は、getClientRects()の戻り値のリストから計算して、TextRectangleを返す。言い換えれば、その要素の領域だ。

重要な事は、これがviewportに対する相対座標だということだ。つまり、event.clientX/Yとは、同じ座標系ということになる。これで、マウスカーソルの、その要素に対する相対座標が得られる。

うれしいことに、これはほとんどのブラウザで動く。有名なquirksmode.orgのW3C DOM Compatibility - CSS Object Model Viewによれば、IE7以前で、2ピクセルずれるとか、Firefoxは結果を丸めないとか、些細な違いがあるが、それはそのブラウザのバグで、私の知ったことではないし、他の悲惨な方法に比べれば、実に他愛ない違いである。

var x = event.clientX ;
var y = event.clientY ;
var rect = event.target.getBoundingClientRect() ;
        
x -= rect.left ;
y -= rect.top ;

これで、この前のHTML5のCanvasの使ったデモは、規格を正しく実装しているどんなブラウザでも動くようになった。

最悪のコンピューター

Fifteen Classic PC Design Mistakes | Technologizer

これはひどい。

DOM mouse eventの座標がカオスだ

Mouse position

マウスイベントが飛んでくるのはいい。だが、canvasにおいて、座標系がまるで使い物にならない。DOM level 2、level 3のEventにおける定義では、screenX/Yと、clientX/Yが使える。screenのコンピューターの画面全体における座標なので、あまり必要ない。clientの方は、ブラウザのウインドウ全体における座標だ。

欲しいのは、そのマウスイベントが発生したElement上での相対座標だ。これを求める方法は、W3Cの規格だけでは実装できない。

あるElementの左上の座標を求めるプロパティはある。しかし、そのElementの親Elementからの相対座標なので、結局、bodyまでさかのぼらなければならない。激しく面倒だ。

前回のcanvasを使ったコード、どうしてもすべてのブラウザをサポートする、workaroundの無いコードがかけない。現在、Operaでうまく動かない。どうも、Operaでは、ScrollTopやScrollLeftが0を返す。ベータバージョンを使っているからだろうか。とにかくブラウザ間の互換性の無さにだけはあきれ返る。

とりあえず、マウスイベントのclientXとclientYを、relativeな座標に直す関数を書いてみた。

function computeRelativePosition(event)
{
        var ret = { x : event.clientX, y : event.clientY + document.body.scrollTop } ;
        for ( var p = event.target ; p !== null ; p = p.offsetParent )
        {
                ret.x -= p.offsetLeft ;
                ret.y -= p.offsetTop ;
        }

        return ret ;
} ;

HTML5のcanvasを使ってみた

マウスイベントのclientXとclientYは、クライアント座標であって、canvasの左上を(0,0)とした座標ではないので、四角形を出現させる位置がずれていた。、offsetTopとoffsetLeftを使って修正したが、これは規格にはない。どうしたものか。

かなりやっつけ仕事。canvas上をクリックすると、どんどん四角形が増えていく。ドラッグすると面白いことになる。回転軸が四角形の中央でないのは仕様。バグだったけど、動きが面白かったので、あえて修正しなかった。

一つだけ気にくわない点がある。いわゆる拡大縮小や回転、移動は、行列で行えるのだが、"The transformations must be performed in reverse order."ってどういう事だ。なぜ逆なんだ。逆にしたら分かりやすくなるとでも思っているのか？　どう考えても混乱するだけだろ。あと、Identity Matirxにするメソッドぐらいほしい。なんでIdentity Matirxのような基本的なものを、手動で書かなければならないんだ。まあ、canvasが普及すれば、javascriptによるベクトルや行列計算のライブラリが発展するだろうが、それでも、FlashやSilverLightに勝てるとは思えない。

2009-06-17

Weird Al Yankovic released a new song!

Fuck Yeah! I almost crapped my pants when I found THIS on digg.com. Weird Al is the best singer ever.

「予防的先制攻撃」が国際法違反であることを知らない人間が党国防部会の委員長と防衛大臣をやっていたという事実

小池元防衛相が党基地対策委員長を「抗議の辞任」 - MSN産経ニュース

自民党の小池百合子元防衛相は１６日、党本部で記者団に、党基地対策特別委員長を辞任したことを明らかにした。
　党の国防関係合同会議が麻生太郎首相（党総裁）に提出した提言の「敵基地攻撃能力の保有」の項目に「予防的先制攻撃を行わない」との文言が盛り込まれたことに抗議したという。
　この文言は、提言の作成過程で、自民党の防衛庁長官・防衛相経験者会議が「外国に誤解を与えてはいけない」とする山崎拓元副総裁らの主張を取り入れて採用した表現。
　敵基地攻撃は国際法や憲法、専守防衛の範囲内の「先制攻撃」の一種。「予防的先制攻撃」は差し迫った脅威ではないが放置すれば将来、受け入れがたい脅威をもたらす可能性のある相手を攻撃する国際法上違法な「予防攻撃」を指す。
　小池氏は産経新聞の取材に対し「『専守防衛』で手足を縛り、『予防的専制攻撃』でさらに縛る。縛る話ばかりだ。日本の防衛政策を縛り続けていいのか。近隣諸国への配慮といっても、向こうは配慮なんてしない」と語った。

おいおい、「予防的先制攻撃」の否定は、先制攻撃そのものを否定するわけではないというのが分かっていないのか。

予防的先制攻撃というのは、将来、脅威になり得る相手に対して先制攻撃を加えるというもので、これは国際法に違反している。アンクル・サムとユダヤ人と共産主義者の大好きな攻撃がこれである。三者とも、常に盛大にこれを行っており、しかも正当な先制攻撃だと主張しているようだが、それはまた別の話だ。

アンクル・サムやユダヤ人や某アカい大国ならともかく、日本が予防的先制攻撃を行ったら、他国から合法的に侵攻する大義名分を与えてしまうことになる。なぜなら、予防的先制攻撃は国際法に違反しており、法を先に破ったのは、日本と言うことになるのだから。だから、日本の脅威になり得る某国としては、おそらく日本が予防的先制攻撃をしてくれることを、待ち望んでいるはずだ。そうなれば、合法的に侵攻できるのだから。

そして、予防的先制攻撃の否定は、先制攻撃自体を否定するものではない。あくまで、「疑わしいな～」とか、「ほっといたら将来ヤバいな～」程度の理由で先制攻撃するのを否定するだけなのだから。

こんな無知な女が、元は党国防部会の委員長と防衛大臣をやっていたというのか。世も末だ。

VC10にSafeIntクラスが入るらしい

Visual C++ Team Blog : Channel 9 Video: David LeBlanc (and Ale Contenti): Inside SafeInt
SafeInt

オーバーフローかゼロ除算を起こす場合に、例外を投げてくれるIntegerらしい。（アンダーフローは規格で保証されている）

2009-06-16

Opera unite

http://unite.opera.com/
http://dev.opera.com/articles/view/an-introduction-to-opera-unite/

この前、ネットエージェントに、BitCommetの使用に情報漏洩リスクがあると考えているのかとメールを送ったら、やけに湾曲的な表現でやんわりとごまかされた。曰く、「BitTorrentプロトコルでmalwareや著作権侵害のファイルが配布されているのは周知の通りで云々」と。これは、わざと直接答えることを避けている文面だ。そんなごまかしで納得はできないので、もっと直接な表現を使った「BitTorrentプロトコル自体にリスクがあると考えているのか」と。答えは、一週間以上たった今でも返ってこない。まあ、はっきり答えられない理由は分かりきっているわけだが。

まあ、そうこうしているうちに、Operaはもっと先に進んでいく。こんどは、ブラウザからサーバを立てられるサービスを始めたらしい。およそ、フリーなサーバー用のソフトウェアは、Windows/Linux/Macを問わず、いくらでもある。しかし、大抵、使い方が難しい。簡単に使えることを目指したソフトウェアとしては、ブラウザから操作するというのは、なかなかいいのではないか。多くのユーザーは、ダイナミックDNSやNATを用いているので、その辺を越えるサービスだけ、Opera側で提供しているようだ。

この試みが成功するかどうかは分からないが、なかなか面白そうだ。

面白い画像と動画

さすがだ。

キンチョールでタイヤははめられるか。

gottardo nord from fb1 visuals on Vimeo.

特殊なレンズを使い、ミニチュアのように撮影した動画。

有機EL

トッキ、有機ＥＬ大型パネル製造装置を開発－４Ｇガラス基板に対応:日刊工業新聞

　トッキは有機エレクトロルミネッセンス（ＥＬ）の大型パネルの製造装置を開発した。第４世代（４Ｇ、７２０ミリ×９２０ミリメートル）ガラス基板に対応しており、２６型を２面、４２型を１面とれる。薄型テレビ向け有機ＥＬパネルの量産用途で国内外の電機メーカーから受注を見込む。大型有機ＥＬの実用化を後押しする。
　有機ＥＬパネルは、ガラス基板に電極を付けた後、有機材料を成膜して製造する。トッキが開発した装置は、真空に保った状態で有機材料を加熱、気化させて基板に薄膜を形成する。成膜したガラス基板を封止する工程まで全自動で行う。
　トッキは携帯電話の画面など中小型パネルに適した３７０ミリ×４７０ミリメートルガラス基板の装置を製品化している。現在、量産実績のある有機ＥＬテレビはソニーの１１型が最大。
（掲載日 2009年06月16日）

26インチが十万ぐらいで買える時代が早く来ないかな。ただし、1920x1080とかは遠慮願いたい。なぜテレビは16:9で、しかも16とか32の倍数じゃない解像度を選んだのだろう。

中国人の書いた緑壩娘がどうみてもパクリな件について

どう見ても東方のパクリだ。

結局、支那が優れていたのは唐の時代までだったんだろうな。宋の時代になってしまうと、漢詩も好いものが少ない。

昆夷道遠不復通
世出切玉誰能窮
宝刀近出日本国
越賈得之滄海東
魚皮装貼香木鞘
黄白間雑鍮与銅
百金伝入好事手
佩服可以禳妖凶
伝聞其国居大島
土壌沃饒風俗好
其先除福詐秦民
採薬淹留丱童老
百工五種与之居
至今器玩皆精巧
前朝貢献屡往来
士人往々工詞藻
徐福行時書未焚
逸書百篇今尚存
令厳不許伝中国
拳世無人識古文
先王大典蔵夷貊
蒼波浩蕩無通津
令人感激坐流涕
錆渋短刀何足云

日本刀歌、欧陽脩

自有五白猫
鼠不侵我書
今朝五百死
祭與飯與魚
送之於中河
況爾非爾疎
昔爾囓一鼠
銜鳴遶庭除
欲使衆鼠驚
意将清我廬
一従登舟来
舟中同屋居
糗糧雖甚薄
免食漏窃餘
此實爾有勤
有勤勝鶏猪
世人重駆駕
謂不如馬驢
已矣莫復論
為爾聊欷歔

祭猫、梅尭臣

あとは、宋代の禅も多少は日本文化に影響を与えているのだが、所詮は、「一休さん」程度にしか残っていない。一休の説話も、詳しく調べれば面白いのだが、悲しいかな、今の世には、全く知られていない。

中国（1949年以降の、中華人民共和国の事を指す）になってからは、もう見る価値がない。「逸書百篇今尚存（いつしょひゃっぺんいまなほそんす）、令厳不許伝中国（れいきびしくしてゆるさずちゅうごくにつたふるを）、拳世無人識古文（よをあげてこぶんをしるのひとなし）」は、おそらく、現代の中国と日本においても、成り立つだろう。文化大革命のおかげで、中国の多くの書物が失われた。

2009-06-15

W3Cの日本語組版処理の要件が正式にリリースされたらしい

日本語版
 英語版

英語版が正式だと言うことだが、日本語版も、まともな日本語になっている。もちろん、編者はほぼ全員日本人だから、当然のことだし、日本語の印刷技術を、日本語で正しく記述していないというのはおかしい。

HTML5のaudio要素のサンプル

wtf! If you can read this, that means your shitty browser *does not* even support proper javascript　and/or DOM level 2!. Throw that browser away man, it's a crap!

audio要素をサポートしたブラウザなら、vorbis.comのサンプルが聞けるはずだ。もし、未サポートのブラウザを使っているならば、屈辱的な文章が表示されるだろう。もし、まともなjavascriptやDOM level 2をサポートしていないブラウザを使っているならば、侮辱的な文章が表示されるだろう。フィードリーダーからでは動かないと思われるので、実際に動かしたい場合は、ブログを直接閲覧して欲しい。

ところで、addEventListener()に渡すのは、W3CのDOM level 2規格によれば、EventListenerインターフェースを実装したものである。W3Cの規格は、プログラミング言語から独立している。これを単純にjavascriptに置き換えれば、handleEventというメソッドを持っているオブジェクトと言うことになる。さっそく、そのようなコードを書いてみたところ、モダンなブラウザすべてで動いた。ただし、単なるfunctionを渡しても、モダンなブラウザすべてで動いた。また、ほとんどの解説サイトでは、単にfunctionを渡している。まあ、そもそもメソッドを持つクラスやオブジェクトという概念のない言語もあるだろうから、一概に言えないが、うーん、何だかなぁ。

javascript 1.7のletがほしい

generatorは、javascriptの様な動的な言語でも、やはり、あまり欲しいとは思わない。しかし、letはとても欲しい。letなしだと、わざわざ明示的にclosureを書かなければならない。それはとても可読性が悪い。

objectが特許侵害だという誤解がなされている件

http://pc11.2ch.net/test/read.cgi/hp/1189817507/738-

738 名前：Name_Not_Found[sage] 投稿日：2009/06/14(日) 20:22:09 ID:???
video要素って何のためにあるんだよ
object要素に謝れ!

739 名前：Name_Not_Found[sage] 投稿日：2009/06/14(日) 20:36:14 ID:???
ビデオのためじゃないの？

740 名前：Name_Not_Found[sage] 投稿日：2009/06/14(日) 21:02:51 ID:???
>>738
そのobject要素関連の技術に特許が認められたから
だいたい、img要素からして意味なかったしな

741 名前：Name_Not_Found[sage] 投稿日：2009/06/15(月) 00:57:20 ID:???
特許ビジネスがある限り、標準化なんて絵に描いた餅ってことでFA？

742 名前：Name_Not_Found[sage] 投稿日：2009/06/15(月) 01:02:22 ID:???
んなわけねー
特許に触れなきゃいいんだから

743 名前：Name_Not_Found[sage] 投稿日：2009/06/15(月) 01:03:58 ID:???
>>741

今の、HTML技術に特許あるの?
結構、勝手気ままにやってねえ?

object要素自体に特許はない。object自体は、外部ソースを指し示す要素でしかない。実際、多くのブラウザでは（というより、IE以外では）、objectの指し示す先が画像だろうがHTMLだろうが何だろうが、およそ描画できるものはなんでも描画しようという傾向にある。ただ、だからといってimg要素やiframe要素を廃止しようなどという動きは起こらない。したがって、videoやaudioも、存在意義がある。だいいち、objectに統一しようと言うぐらいなら、そのほかの要素も同様にすべきで、divとspanだけで、既存のほとんどの要素は置き換えられるだろう。必要なのは、より強力なCSSだ。

特許ゴロのEolasのPatent 5,838,906は、Web上の埋め込みコンテンツを、外部アプリで処理する特許だ。だから、Object要素に対して、Flash、Java、ActiveXなどのプラグインを呼び出すと、この特許に抵触するというらしいのだが。

そもそも、そんな一般的なことが特許として成立するのか？　というのが本音だ。ある埋め込みコンテンツを指し示す文字列がある場合、外部のアプリケーションを呼び出すような仕組みに、果たして特許など認められるのだろうか。しかも、javascriptなどを使って、動的に埋め込む場合は、この特許の範囲外という、なんだか不思議な抜け穴もある。

この特許の有効性については、いまだに争われている。この特許を認めたアメリカ司法の連中は、何か吸っていた（smoking something）としか考えられない。それも、よほど好い何かを吸っていたはずだ。

ちなみに、この特許、1994年の10月17日に申請されているので、2014年には、少なくともアメリカでは、特許が切れる。つまり、有効期限は、あと5年しかないわけだ。

ところで、世の中は面白いもので、どう考えても理不尽だが、結果的に考えて、まあ、悪くはなかったんじゃないかという事例も多い。たとえばこのEolasの特許だが、これがあるせいで、Flashを埋め込むJavascriptライブラリの開発が進んだ。その結果、SWFObjectと、UFOという、二つの有名なライブラリができ、両者は後に統合されて、現在では、swfobjectとなっている。

あのUnisysのGIF圧縮に関する特許は、どうかするとEolasよりタチが悪い。何しろ、当初、非商用目的には金を取らないと言っていたにもかかわらず、後で撤回し、さかのぼって請求し始めたからだ。これも、PNGというフリーで悪くない規格制定の原動力となった。もちろん、8bitカラー以上の可逆圧縮な画像圧縮の規格は、いずれ必要とされただろうが、Unisysの特許問題がケツを叩いたのか、かなり素早く開発された。

世の中は面白い。

2009-06-14

rubyを消すブックマークレット

厳密に言うと、HTML5のrtとrp要素を消すブックマークレットなのだが。ただし、IEでは動かない。というより、まともなブラウザなら動くといった方が正しいか。

hide ruby
show ruby

例：
ラオウはケンシロウの強敵（とも）である。奴は本気（マジ）で強い。
事故る奴は・・・・、不運（ハードラック）と踊（ダンス）っちまったんだよ・・・・
山吹色の波紋疾走（サンライトイエローオーバードライブ）
Bites The Dust（負けて死ね）

追記：なぜかfirefoxでは、hide ruby、こっちじゃないと動かない。よく分からない。ChromeとOperaでは、ブックマークレットの中にreturn文を書けるのだが、どうもFirefoxでは動かないようだ。何故だろう。

やはり、どうもFirefoxは、bookmarklet中のreturn文が動かないらしい。理由は分からない。

そもそも、上記のコードは、関数内ではない。したがって、return文は使えないのが理由なのだろう。そこで、関数内にいれてみた。

hide ruby

これは動いた。なるほど、なるほど。上のリンクも書き換えた。しかし疑問なのは、なぜChromeとOperaでは動いたのかと言うことだ。私の予想では、この両ブラウザでは、return文を実行する直前までは、実行できていたから動いたのではないかと思う。

HTML5とjavascriptを学び始めたが、IEクソだな

この一週間ほど、javascriptを学んでいる。以前、文法だけ学んで、DOMを学ばずに飽きてしまった。とりあえずw3cの規格と、whatwgのHTML5のドラフトに、ある程度目を通したので、早速実際にコードを書いてみた。

結論：IEはクソだ。

DOM level 2すらまともにサポートしていないIE8は、存在すら許されないレベルだ。クソだ。クソにも程がある。IEがこれほどクソとは知らなかった。

HTML5を、XHTML5として書いてみたが、実に分かりやすい。考えてみれば、XHTML1.0や1.1は、理想主義に走りすぎていた感がある。dtdとかxmlnsとか、理想としてはすばらしいのだろうが、ブラウザがまともに処理しないものに意味はない。2.0？　そういえばそんなものもあったような気がするが忘れた。

とりあえず、Chromeで、HTML5のaudio要素を試してみた。これはすばらしい。再生、ストップ、シーク、すべてをjavascriptから行える。

HTML5には未来を感じる。ChromeのJavascriptの早さを考えれば、2Dのゲームなら、ブラウザで十分な時代が、すぐにやってきそうな気がする。

2009-06-13

中国はどうしようもないな

China's New Censorship Software a Potential "Large-Scale Disaster"
Chinese censorware will expose every PC in the nation of malware, ID theft, botnetting
Is China Creating the World's Largest Botnet Army?
Chinese Govt Spyware Puts Computers At Risk
China Demands All New PCs Include Censorship Software
Chinese Government To Mandate PC Censorware

さすが宗主国様。

一般曹候補生の一次試験を通過

とりあえず一次試験を突破。

受けたのは、陸自の一般曹候補生。船には興味がないので海は選択肢に上らない。（訓練に水泳があるのは、ちょっと興味があるが）　空についてはよく知らず、また、田母神みたいなイデオロギーに振り回されている思想家を昇進させるような空気があるので敬遠した。およそ非民間人に現実離れした思想家ほど不必要なものはない。

ところで、以下は私の主観なのだが、試験の時、陸海空のどこを志望するかで、性格が分類できるような気がした。私は一般曹候補生を受けたので、幹部候補を受ける人間はまた違うかも知れない。というのも、幹部は部下の管理などの能力も要求されるので、また違った性格が要求される。それは私の能くする所ではないので、幹部は受けなかった。

まず、陸自志望者は、いろんな人間がいた。スーツを着ている真面目そうな人間もいれば、なんじゃこいつはというような、名状しがたい服を着た奴もいた。しかし一般に、平均的な人間が集まっていると思う。年齢もバラバラだった。

海自は、とにかく俺は自衛隊に入りたいんだという血気盛んな人間が多いように見えた。それも、今年高校を卒業だというかいう、若者が多かった。

空自は少し変わっている。絵に描いたようなヲタク達だ。一口にヲタクと言っても、いろんな種類がいる。いわゆるキモいピザデブも、オタクには違いない。ここで言うヲタとは、そうではなくて、痩せぎすでやたらと知識欲があり、自分の専門分野については､誰かまわず、相手の反応も見ずに延々と語るようなタイプのヲタクだ。

繰り返すが、以上は単なる私の主観である。文章にするから書けるのであって、私の性格上、口頭でこんなことは、あまり話さない。あまり。

2009-06-12

以下について教えてあげよう☠☢☣☤

我、不知其宿題與課題也。そも、宿題と課題とは、同じ義には候はずや。ただし、これ易き文字列処理問題にて候。

・大文字は小文字に、数字は'0','1','2'...を'9','8','7'...と反転させる。
・ただし、'#'以降の文字は変換しない。
・例として "Abc012_59F_#012Gh"を渡した場合の戻り値は "abc987_40f_#012Gh"となる。

僭越ながら、ユーザー定義リテラルを用ひ候。

//　名前空間に入れること肝要なり。
namespace udl
{
        // ユーザー定義リテラルてふものなり。
        std::string operator "" _conv( char const *ptr )
        {
                std::string temp(ptr) ;

                std::transform(
                        temp.begin, std::find(temp.begin, temp.end, '#')
                        , temp.begin()
                          // ラムダてふ便利な無名関数なり。
                        , [] (char const c ) -> char 
                          {
                                if ( c >= '0' && c <= '9') return '9' - c + '0' ;
                                if ( c >= 'A' && c <= 'Z' ) return c - 'A' + 'a' ;
                                return c ;
                          } ) ;

                return temp ;
        }
}



int main()
{
        //使う際には、using declarationにて指定する必要有之候。
        using udl::operator "" _conv ;
        std::cout << "Abc012_59F_#012Gh"_conv << std::endl ;
}

げにユーザー定義リテラルてふものは、その易きこと如此。

V8に関する興味深い動画

Expert to Expert - Erik Meijer and Lars Bak: Inside V8 - A Javascript Virtual Machine | Going Deep | Channel 9

今年の四月という、少々古い動画だが、V8のプログラマとMSのプログラマが、javascriptのVMについて語っている。

かなり考え方の違いが現れていて面白い。MSの開発者が、javascriptから自前でネイティブコードを生成するよりも、JavaやC#のMSILのような、よく知られたバイトコードに変換して、ネイティブコードの生成は、それに任せるというのはどうだと言っているが、V8の開発者からすれば、javascriptというのは、十分分かりやすい中間言語だそうだ。javascriptから意味上の大量のチェックを行った上で、バイトコードを生成して、さらに意味上の大量のチェックを行いつつ、ネイティブコードに変換するのは、二度手間でしかないというスタンスらしい。それだったら、javascriptから直接ネイティブコードを生成した方が早いと言っている。興味深い価値観の違いだ。

2009-06-11

swfobjectが更新された。

whats_new - swfobject - SWFObject 2.2 - What's new? - Google Code

もちろん、2.2を落とすこともできるし、Google AJAX Libraries APIから使うこともできる。私の場合はメジャーバージョンだけ指定しているので、アップデートに当たって、特に何かする必要はない。

しかし、このライブラリも、いつまで使うことになるだろうか。Chromeがそこそこ安定したvideo要素を実装した暁には、即座にそちらに切り替えるつもりでいる。早めにラッパ関数に切り替えておいて良かった。既存の記事を書き換えなくてもいいというのは、実にすばらしい。

予備自衛官補の辞令書の交付式

予備自衛官補の辞令書の交付式の案内状が来た。大津の駐屯地で行う。

辞令書と、訓練に関する説明、駐屯地内の見学、また、実際に駐屯地の昼食が食べられるそうだ。

三輪バイクの道交法での扱いが変わる

三輪バイク：９月から要二輪免許　ヘルメット着用も - 毎日ｊｐ(毎日新聞)

ただし、ソースが毎日新聞だが、変態的な記事ではないので誇張はないだろう。

むしろ、いい加減に、車輪の個数で車種を定義するのをやめた方がいいと思うのだが。これとか、国内法では、二輪車なので、おそらくヘルメットの着用が義務づけられる気がするのだが、どう考えてもヘルメットの必要はない。なにしろ最近の型はエアバッグまで付いているらしいのだから。

google Chromeが更新された

メニューを使おうとするとクラッシュする。

video要素でフリーズしなくなった。ただし、再生がスムーズではない。早くなったり遅くなったりと、まったくもってリアルタイムの再生ができない。しかも、未だに全部再生できずに止まる。

まだ評価するには時期尚早といった所か。

SilverLight 3の正式版が、今日あたりリリースされるという噂を目にしたのだが、所詮は噂だったようだ。残念。

自分は今まで漢詩を全然理解していなかったのだな

漢文が読めるようになるにつれて、漢詩の本来のおもしろさが分かるようになってきた。漢詩というものは、センテンスとしては、とても分かりやすい作りになっている。五言ならば、二、三、七言ならば二、二、三、という具合だ。もちろん、延々と同じでは単調であきるので、長い漢詩だと、たまにこれに当てはまらない部分もあるが、ほぼこの形になっている。たとえば、

離離原上草
一歳一枯榮
野火燒不盡
春風吹又生
遠芳侵古道
晴翠接荒城
又送王孫去
萋萋滿別情

白居易、擬古

臨邛道士鴻都客
能以精誠致魂魄
為感君王輾轉思
遂教方士殷勤覓
排空馭氣奔如電
升天入地求之徧
上窮碧落下黄泉
兩處茫茫皆不見

白居易、長恨歌

やはり、白居易の詩はすばらしい。兼好法師が、「文は白氏の文集」と行っていたのも、宜なるかな。

ついでに私の好みを挙げておくと、やはり項羽や曹操の詩はすばらしい。陶淵明もいい。それから、猫好きだという理由で梅尭臣を評価するし、日本人としては、日本に言及している欧陽脩も、やはり無視することはできない。

ところで、漢詩の要素として、韻がある。問題は日本語には、音による韻はなじみがないので、理解できない。七五調などといったものはあるが、日本語には音による韻文はない。第一、当時の支那語の四声と今の四声は異なる。

2009-06-09

はてなブックマークがセコい手を使ってSEOしているらしい

はてなブックマークのやりすぎちゃったかもしれないSEO - ぼくはまちちゃん！(Hatena)

はてながやっちゃってたらしい。はてなブックマークやはてなキーワードといえば、検索する際に、大した情報価値もないのに引っかかるゴミサイトという認識しかなく、検索の際には"-はてな"を指定しなければならない時もしばしばなのだが、google botだけの特別な計らいがあったらしい。やれやれだ。

追記：このSEO、クローキングには当たらないというのが小飼弾さんの見解らしい。
404 Blog Not Found:「検索ボットのみURI Redirect」はクローキングにあらず
というのも、返すコンテンツは同じで、URLが複数あるだけなので、クローキングの定義には当たらないというのが、その理由らしい。

なるほど、そういう見方もできるか。しかしそれもそれで、あまりよろしくないと思う。SEOのために複数のURLを用意するのが当然という風潮になると、面倒でしかないと思う。しかも、検索ロボット専用のURLとなっては、その存在意義は、自分のサイトの評価を押し上げるためでしかない。もしこれが許されるのであれば、多くのWebサイトは、検索結果の評価を押し上げるためだけに、マルチURLを実装するだろう。そうなれば、もはや、URLが検索クエリーを包括しているという事は、評価を上げる要素に当たらなくなる。何故ならば、みんな行っているのであり、むしろ行っていないサイトは、評価を下げてくれという意味に取られるだろう。これは、もはや何の意味もなくなってしまうだろう。

最適なのは、URL文字列自体を評価の対象にするのをやめるということじゃないだろうか。URLが検索ワードを含んでいるからといって、そのコンテンツ自体が有益であるとは限らないと思う。

using declarationとusing directiveの違い

今まで文法的な違いしか理解していなかったので、詳しく学ぶことにした。

using directiveは、名前空間を、あるスコープの中に持ち込む。

namespace A
{
    typedef int foo ;
    typedef int bar ;
}

// Using directiveはグローバルに書ける。
using namespace A ;

// 関数の中に書ける。
void f()
{
    using namespace A ;
    foo a ; bar b ;
}

// ローカルスコープの中に書ける。
void g()
{

    {
        using namespace A ;
     //範囲、ここまで。  
    }
}

//名前が衝突すると曖昧、どちらの名前も対等に扱われるから。
typedef int foo ;
void h()
{
    using namespace A ;
    foo a ;// Error
}

一方、using declarationはというと、名前を宣言する

namespace A
{
    typedef int foo ;
    typedef int bar ;
}

// 宣言できる所ならどこでも。
using A::foo ;

// クラスの中でも
struct S
{
    using A::foo ;
}

// 関数の中もよし
void f()
{
    using A::foo ;
}


// 名前が衝突した場合、優先される。
typedef char foo ;

void g()
{
    using A::foo ;
　　　foo a ; // int 
}

そんなわけで、using directiveをユーザー定義オペレーターに使うと問題があるかもしれない。

たとえば、ある処理系が、グローバル名前空間に、_a という独自のリテラルオペレーターを持っていたとする。これは、あり得る話であり、規格準拠でもある。（アンダースコアひとつで始まる名前は、グローバル名前空間において、処理系の実装のために予約されている。）

//　処理系によってあらかじめ用意されているユーザー定義リテラル、_a
int operator "" _a(char *) ;


namespace A
{
    int operator "" _a (char *) ;
}

void f()
{
　　　// このコード自体はwell-formedであるが、
    using namespace A ;

    int x = "hello,world!"_a ; //　Error! どちらの_aなのか曖昧。
}

using directiveで導入される名前は、対等に扱われるので、using directive自体を使うことは問題がないのだが、実際にその衝突している名前を使う際に、曖昧になってしまう。

一方、using declarationならば、問題がない。

//　処理系によってあらかじめ用意されているユーザー定義リテラル、_a
int operator "" _a(char *) ;


namespace A
{
    int operator "" _a (char *) ;
}

void f()
{
    using A::operator "" _a ;

    int x = "hello,world!"_a ; //　OK. A::operator "" _aが優先される。
}

なるほど、そうなると、安全を期すためには、using declarationを使うしかない。ユーザーの負担を和らげ、また単純なミスを防ぐためには、ライブラリ側でプリプロセッサのマクロを提供するしかない。已んぬる哉。

果たして、ユーザー定義リテラルは必要なのだろうか。現在、メジャーなコンパイラはどれも、アンダースコアから始まる一連の予約語をユーザーが使用したとしても、エラーを出さない。なぜならば、已に書かれたコードをぶち壊してしまう可能性があるからだ。ユーザー定義リテラルには、互換性の問題はないから、ユーザー定義リテラルの場合だけエラーにする事もできるが、果たしてすべてのコンパイラが、それほど順法意識が高いだろうかというと、疑問である。

最悪なのは、まず初めにユーザー定義リテラルを正式にサポートしたC++0xコンパイラが、この辺の予約語やアンダースコアに関する問題を一切無視してコンパイルを通す実装にしてしまった結果、アンダースコアを用いないリテラルオペレーターのコードが、世に広まり、後の規格改定で、組み込みのリテラルを増やす際に、影響を及ぼすと言うことだ。

奇妙な夢

三時間ほど昼寝をしてしまった。とても奇妙でリアルな夢を見たので、明惠には及ばないが、書いておくことにする

私は、どこかの動画サイトで、動画を見ていた。その動画では、どこかの家々が映されていた。Monty PythonのJohn Cleeseにそっくりの声が聞こえた。

"In this picture, there is one lady who will perform Full Frontal Nudity."
"We can not see where she is. Where are you?"
ある家の窓から、一人の夫人が裸で上半身をだす。（大勢の笑い声）
（場面が変わり、多くのマンションを屋上から移しているような映像になる）
"Here, another couple who will perform Full Frontal Nudity. we can not see where they are, but we can soon find out"
（全裸の人間が二人、マンションの窓から落下、大勢の笑い声）
女性の叫び声："John! John! Full Frontal Nudity is over! Do you hear me. It's over!"
Johnそっくりの声："Here... We have..."

よく分からないが、面白い動画だ。落としておこうと、そのサイトのソースを表示させたところで、こんどは私の方の場面が変わった。なぜか、私はどこかの古本屋にいて、薄汚れた本の表紙を眺めている所だった。いかにもインチキ臭い店主が、隣で何か独り言を言っていた。その古本屋に団体客がいて、「本を買うために、我々はラクダを売るべきだ」ということの是非を議論していた。

また場面が変わった。私は廃墟の屋上から屋上へと、ゲームの主人公のように飛び移っていた。私は、あきらかに非現実的な跳躍力を持っていたが、何故かとてもリアルに感じられた。

ここで、目が覚めた。一体何故こんな夢を見たのか分からない。この夢を精神分析に使っても、ろくな結果は得られないだろうと思われる。

ただ、覚えがないわけでもない。なぜなら、私はMonty Pythonが好きで、毎日のように観ているし、上記の夢の中の動画は、How not to be seen　という有名なスケッチに似ている。また、Full Frontal Nudityといえば、Monty Pythonのスケッチの中でも、いくつかネタにされている。

また、古本屋については、私はしょっちゅう行っては、何か掘り出し物を探しているので、夢に出てきてもおかしくはない。

最後のゲームのようなアクションについては、たぶん、今朝これを観たからだろう。
西川善司の3Dゲームファンのための「E3 2009」グラフィックス講座今期注目の3Dゲームグラフィックスはこれだ！ -GAME Watch

漢文の複雑さ

どうも、宋代、唐代の漢文となると、やたらと技巧にこり出して、複雑で理解しにくくなっているような気がする。また複雑であるが故に、矛盾や非論理的な記述が目に付きやすい。複雑化させたあげくに、肝心の中身まで粗末になっているとあれば、救いようがないと思うのだが、いいのだろうか。

2009-06-07

ジャイロスコープの効果が実際に見れる動画

こいつはすばらしい。

ユーザー定義リテラルの問題に対するふたつの解決案

ユーザー定義リテラルの問題点

ひとつ、グローバル名前空間に定義できないこと。
ひとつ、識別子はかならずアンダースコアひとつから始まらなければならないこと。
ひとつ、リテラルオペレーターを使うローカルなスコープの中で、using declarationをしなければ、本来の意図通りの文法で使えないこと。

およそ物事を設計するにあたって重要なのは、「ユーザーはどうしようもないバカである」という前提に立つ事だ。単なるユーザーに専門知識を期待してはいけないのはもちろんのこと、ユーザーはマヌケなことでも、それが出来るならば、する可能性がある。

だから、グローバル名前空間にユーザー定義リテラルを書くプログラマもいるだろうし、識別子をアンダースコアで始めないプログラマもいるはずだ。現に、C++03において、名前の衝突を防ぐためと称して、グローバル名前空間で、識別子をアンダースコアひとつで始めたり、さらにはアンダースコアふたつで始めたりするプログラマがいる。たとえ規格は未定義としていたとしても、そういうマヌケはいる。そこでどうするか。

ユーザー定義リテラルを規格から取り除く

これは最も簡単な解決方法。最初からユーザー定義リテラルなど存在しなければ、そんなマヌケなコードなど書かれることはない。

ill-formedにする

グローバル名前空間でのユーザー定義リテラルの定義と、アンダースコアひとつから始めない識別子のユーザー定義リテラルを、明確にill-formedにして、コンパイルエラーにする。コンパイルが通らなければ、いかにアホなプログラマでも、間違ったコードを書くことはない。ユーザー定義リテラルに関しては、コンパイルエラーにしても、互換性の問題はない。問題は、コンパイラベンダーが規格を正しく実装することは思えないことだが。

私としては、ユーザー定義リテラルを規格から取り除くほうが簡単だと思うのだが。

ユーザー定義リテラルのRaison d'êtreがますます分からなくなってきた

リテラルオペレーターは、必ず名前空間の中で定義しなければならない。さらに、使う場合は、using declarationするのが一般となるだろう。なぜなら、誰も以下のように書きたくはないからだ。

namespace foo
{
    int operator "" _bar (char *) ;
}

void f()
{
    auto x = foo::operator "" _bar("hello,world!") ;
}

もはや、ユーザー定義リテラルである必然性がない。普通の関数でいい。そこで、以下のようにする。

void f()
{
    using foo::operator "" _bar ;

    auto x = "hello,world!"_bar ;
}

実際には、複数のリテラルオペレーターを使いたいだろうし、ライブラリ側で、一度にすべてのusing declarationをしてくれる、プリプロセッサのマクロを提供するのが一般的となるだろう。しかし、そこまでして使いたいだろうか。ユーザー定義リテラルの本来の面目は、わかりやすいシンタックスシュガーとなることではなかったのか。関数ではなく、リテラルとして自前のクラスの値が記述できれば、分かりやすいコードになるというものではなかったのか。それが、ユーザー定義リテラルを使うには、そのまさに使わんとするローカルスコープ内で、おまじないのようなusing declarationが必要とあっては、一体誰が能く使うというのだろう。

偉い人の考えることは分からない。

ユーザー定義オペレーターの正しい使用方法

ユーザ定義リテラルまとめ - xyuyuxの日記

よくみたら、ちゃんと規格に明言してあったらしい。

A declaration whose declarator-id is a literal-operator-id shall be a declaration of a namespace-scope function or function template (it could be a friend function (11.4)), an explicit instantiation or specialization of a function template, or a using-declaration (7.3.3). A function declared with a literal-operator-id is a literal operator. A function template declared with a literal-operator-id is a literal operator template.

13.5.8, p2

よって、グローバル名前空間に定義されているリテラルオペレーターは規格に違反している。何らかの名前空間の中で定義しなければならない。

しかも、using directiveは使えず、using declarationを使わなければならない。

namespace foo 
{
int operator "" _bar( const char*, std::size_t ) ;
}

void f()
{
    using foo::operator "" _bar ;

    auto x = "hello,world!"_bar ;
}

using declarationしか使えないというのは、少々問題がある。例えば、あるライブラリが100個のリテラルオペレーターを提供している場合、一体ライブラリのユーザーはどうやって、それを使えばいいのか。合法的で、しかも間違いを起こさない簡単な方法は、プリプロセッサを使うというものしか思いつかない。

// UsingLiteralOperator.h

#define LIBRARY_USING_LITERAL_OPERATOR() \
using lib::operator "" _hoge ;\
using lib::operator "" _hage ;\
//以下98個の同様な宣言


// user.cpp

#include < UsingLiteralOperatorHelper.h >

void f()
{
// 使いたいスコープの中でこのマクロを使う
LIBRARY_USING_LITERAL_OPERATOR()

//あとはご自由に。

}

あるいは

// UsingLiteralOperator.h

using lib::operator "" _hoge ;
using lib::operator "" _hage ;
//以下98個の同様な宣言


// user.cpp

void f()
{
// 使いたいスコープの中で#includeする
#include < UsingLiteralOperator.h >

// あとはご自由に。
}

どっちにしろ、あまり使いたくない。それに、いまさら使用に当たってプリプロセッサが事実上必須な言語仕様というのは、どうなんだろう。

2009-06-06

来週のWindowsアップデートパッチは全部で十件

Microsoft Security Bulletin Advance Notification for June 2009

ただし、Vistaのアップデートは四件。具体的な日付は、いつもの如く、日本時間では第二週の水曜日

なんでも、これほど大量のパッチが一度にでるのは、2008年10月以来らしい。

2009-06-05

chromeのvideo要素の実装が不安定すぎる

とにかく不安定すぎる。すぐにChromeのプロセスがフリーズする。

君子遠庖厨

齊宣王問曰、齊桓晉文之事可得聞乎、孟子對曰、仲尼之徒、無道桓文之事者、是以後世無傳焉、臣未之聞也、無以則王乎、曰、德何如則可以王矣、曰、保民而王、莫之能禦也、曰、若寡人者、可以保民乎哉、曰、可、曰、何由知吾可也、曰、臣聞之胡齕、曰、王坐於堂上､有牽牛而過堂下者､王見之､曰、牛何之、對曰、將以釁鐘、王曰、舍之、吾不忍其觳觫若無罪而就死地、對曰、然則廢釁鐘與、曰、何可廢也、以羊易之、不識有諸、曰、有之、曰、是心足以王矣､百姓皆以王為愛也､臣固知王之不忍也､王曰、然､誠有百姓者､齊國雖褊小､吾何愛一牛､即不忍其觳觫若無罪而就死地、故以羊易之也、曰、王無異於百姓之以王為愛也、以小易大、彼惡知之、王若隱其無罪而就死地、則牛羊何擇焉、王笑曰、是誠何心哉、我非愛其財而易之以羊也、宜乎百姓之謂我愛也、曰、無傷也、是乃仁術也、見牛未見羊也、君子之於禽獸也、見其生、不忍見其死、聞其聲、不忍食其肉、是以君子遠庖廚也

孟子、梁惠王上

ここからとってきて、整形したのだが、どうも中国人の解釈は間違っているんじゃないかと思う。変な所で区切ったりしている。

だいぶ難しかったので、わかりにくい所を解説する。

齊桓晉文之事：齊の桓公と晉の文公の事
この両君主は、いずれも武力で国を支配した者として名が高い。齊の宣王は、武力に関心があったので、この二人のことを聞いた。

仲尼之徒云々
儒学者は、武力による支配を好まず、仁徳、王道による支配を良しとしているので、孟子は知らずと答えた。

無以則王乎:やむなくんば則ち王か
以は已と同じ音なので、代わりに使われている。この王は、人としての王ではなく、国を治める道としての王道のこと。孟子は武力について答えることができないので、代わりに王道についてこたえましょうか、と言っている。

莫之能禦也：これを能くとどむる莫きなり
禦は止と同じ意味。述語と目的語が逆転しているのは、目的語が代名詞で、しかも否定文であるから。

將以釁鐘：将に以て鐘を釁せんとす
新しい鐘には、牛を殺して、その血を塗るという儀式がある。

舍之：これをおけ
舍は捨を簡略化したものらしい。それをするな、程度の意味か。

觳觫：こくそくとして
これは二字の母音の発音を重ねる畳韻。意味は、こそこそ、おろおろ、など、恐れる様。

百姓皆以王為愛也：百姓皆以て王は愛しむと為すなり
ここで、愛は惜という意味である。則ち、「臣民は、王は吝嗇で牛を殺すのがもったいないから羊に変えさせたと思っている」という意味である。

隱：いたむ、あわれむ

中島端は正しかった

CNN, BBC and AFP reporters accosted by umbrella-wielding "undercover" police at Beijing's Tiananmen Square [UPDATED] - Shanghaiist

未だにこんなことやっている国だ。中島端は正しかったといわざるを得ない。

足利事件の元県警刑事部長のブログ

http://blog.goo.ne.jp/moririn317
魚拓

炎上中。

「君子は危うきに近寄らず」というから、栃木には行きたくないなぁ。まあ、この言葉の本来の意味は、誤解されるようなことを避けるという意味なのだけれど、礼状もなしで部屋に踏み込まれて、エロビデオがあったために疑われて逮捕なんてことが行われている栃木のことだからなぁ。

ところで、「君子は危うきに近寄らず」の原文が、いまいち思いつかない。「君子近寄危」というのは、どうも変な気がする。出典を探したが、どうも出展と呼べるものは無いらしい。

Chromeのvideoサポートのまとめ　付audioの解説

まず、HTML5のvideoから説明する。これは、単純にvideoなるelementを使う。説明するよりも、サンプルコードをみせた方が早い。

<video width="640" height="480" controls="controls" poster="poster.png" src="video.mp4" />

例えば、上のようになる。説明が必要ないぐらい簡単だと思う。widthやheightは言わずもがなだし、controls属性を指定した場合は、動画を再生を制御するコントロールを表示することをブラウザに指示する。posterは、動画を再生を始めていない時に、まず表示しておく画像へのURLだ。srcが実際の動画へのURLになる。

Chromeは、デコーダーとして、ffmpegを利用しているので、ほとんどの動画のコンテナ、コーデックが再生できる。現在、すこしstabilityに問題があるが、これはDev版だからで、すぐにまともになるはずだと信じている。

ところで、Chromeはまだサポートしていないが、HTML5には、audioもある。これはvideoとほとんど変わらないが、widthやheightなどの属性がなくなっている。どうしても指定したい場合は、style属性で指定することになるだろう。

video要素のまともに使えるブラウザが、ついにでたわけだが。

現在、このブログに貼ってあるほとんどの動画は、JW FLV Media Playerを用いている。しかも、以前互換性をぶちこわすというふざけた変更があったので、用心のために、SWFObjectの外にも、さらに自前のJavascriptを使って書き換えている。以下のコードを使っている。

　　　　<script　type='text/javascript'>
　　　　　　function player(id, width, height, file, image)
　　　　　　{
　　　　　　　　swfobject.embedSWF("player.swf", id, String(width), String(height+20), "9.0.0", null, 
　　　　　　　　{//flashvars
　　　　　　　　　　volume: "100",
　　　　　　　　　　showdownload : "true",
　　　　　　　　　　type : "video",
　　　　　　　　　　fullscreen : "true",
　　　　　　　　　　image : image,
　　　　　　　　　　file : file,
　　　　　　　　　　link : file
　　　　　　　　},
　　　　　　　　{//params
　　　　　　　　　　allowscriptaccess : "always",
　　　　　　　　　　allowfullscreen : "true",
　　　　　　　　　　quality: "best",
　　　　　　　　　　wmode: "direct"
　　　　　　　　} ) ;
　　　　　　}
　　　　</script>

このようにしておけば、将来の変更にも十分耐えることができる。実際、これを、以下のように変更すれば、HTML5のvideo elementに、今すぐ変更できる。しかも、実際の記事は書き換えなくて良い。

<script type='text/javascript'>
function player(id, width, height, file, image)
{

　　　　var v = document.createElement("video");
　　　　v.setAttribute("width", String(width));
　　　　v.setAttribute("height", String(height));
　　　　v.setAttribute("controls", "controls");
　　　　v.setAttribute("poster", image);
　　　　v.setAttribute("src", file);
　　　　　　　　
　　　　var n = document.getElementById(id);
　　　　n.parentNode.replaceChild(v, n);

}
</script>

問題は、現在、Chromeしかまともにvideo要素をサポートしていないことだ。さてどうしよう。

Chromeのvideo elementが動いた！

追記：Chromeがあまりに不安定になるので､まともになるまでしばらくコメントアウトすることにする。

こいつはすばらしい。

デコーダーにはffmpegを利用しているので、大抵のコンテナ、コーデックは動くはずだ。ただ気になるのが、HE-AACをHE-AACとして、正しく再生できているのか気になる。

まだどうも不安定だ。それに描画にGPUを利用していないのも、Flashに劣る。

VC10のgs++

2009-06-04

麻生は首相の器じゃないな

麻生首相、可視化で冤罪減るとは感じない（産経新聞） - Yahoo!ニュース

　麻生太郎首相は４日夜、ＤＮＡ再鑑定で受刑者が釈放された足利事件に関連し、取り調べの可視化について「可視化すれば直ちに冤罪（えんざい）が減るという感じがありません」と述べた。首相官邸で記者団の質問に答えた。

　ぶら下がり取材の詳細は以下の通り。

【足利事件】

　－－（平成２年の足利事件で殺人罪などで服役していた元幼稚園バス運転手の）菅家利和さん（６２）が今日、（ＤＮＡ再鑑定の結果）釈放されました。再審が始まる前の釈放というのは極めて異例だが、首相の受け止めを

　「再審請求に関する、いわゆる司法手続きってのは今から開始されるんだと思いますけれども、私の知ってる範囲でこれは極めて異例っていうけど、前例はないと思いますけどね。まあいずれにしても無実の罪で１７年服役してたっていうのは、こういったようなことはあっちゃいかん。これはつくづくそう思いますね」

　－－似たようなケースがないとも言い切れない状態の中で、日本では再審請求が認められるのは非常にレアケースだが

　「そうですね。今回の場合はＤＮＡの鑑定っていうのが大きな決め手になったんだと思いますけども、昔のＤＮＡ鑑定の、いわゆる科学的なレベルと今のレベルとは全然、倍率がまったく違うことになってるんで、そういったケースもあるかと思いますが、これ一概に一般論として答えるのは難しいです」

　－－この件を受けて、冤罪防止のために、さらなる取り調べの可視化を求める議論が強まると思うが、首相の考えは

　「可視化にしたからといって、途端にそれがよくなるという感じはありません」

　－－そうは言っても、無実の人が捕まって刑に服することはあってはならない

　「それ、今、答えた通りです」

　－－そういった国家のあり方を考える上で…

　「国家のあり方ってどういう意味ですか」

　－－冤罪が起きない国にするために可視化は必要だと思わないか

　「ぼくは基本的には一概に可視化すれば直ちに冤罪が減るという感じがありません」

　－－杉村太蔵衆院議員が…

　（秘書官「終わりま～す」）

こりゃダメだ。

中島敦はどうやってあんな美文を書くことが出来たのだろう

アペママの独裁者テムビノクは今、どうしているかと思う。王冠の代りにヘルメット帽をかぶり、スカアトの様な短袴を着け、欧羅巴式の脚絆を巻いた、この南海のグスターフ・アドルフは大変に珍しいもの好きで、赤道直下の彼の倉庫にはストーヴがしこたま買込まれていた。彼は白人を三通りに区別していた。「余を少しく欺した者」「余を相当に欺した者」「余を余りにも酷く欺した者」。私の帆船が彼の島を立去る時、豪毅朴直な此の独裁者は、殆ど涙を浮かべて、「彼を少しも欺さなかった」私の為に、訣別の歌をうたった。彼は其の島で唯一人の吟遊詩人でもあったのだから。

中島敦著、光と風と夢

私は告白する。私は中島敦の美文を、さらに引用しようとして、思いとどまった。中島敦の文章は、いうまでもなく、すべてすばらしいので、美文のみ引用するというのは、畢竟、中島敦の全著作を引用するのに他ならぬのだから。

荻生徂徠は偉かった

論語を述而まで読み終えた。読んで、理解して、書写してという学び方をしているので、かなり時間がかかる。

思うに、荻生徂徠は偉かったのだなぁ。朱子学的解釈のなんとアホくさいことか。金があったら、荻生徂徠全集を買いそろえたいものだ。

ところで、

子曰、若聖與仁、則吾豈敢、抑為之不厭、誨人不倦、則可謂云爾已矣、公西華曰、正唯弟子不能學也。

赤字の部分の意味が取りづらかったが、おそらくは、「謂云」や「爾已」は、同義語を重ねた言葉なのだろう。だから、「則可謂之已矣」という意味なのだろう。ここで、之とはその上の言葉を指す。

2009-06-03

中島敦著、光と風と夢

中島敦の「光と風と夢」を読んだ。いままで、読もう読もうとは思っていたが、印刷された本が手に入らないため、読む気になれなかったのだ。というのも、96DPIのディスプレイに、日本語は複雑すぎるからだ。

結局、印刷された光と風と夢は手に入りそうにないので、青空文庫のものを読んだ。

内容は、ジキルとハイドを書いた、ロバート・ルイス・スティーヴンソンの、サモアでの生活記である。実に興味深い。

さて、読み終わって、つくづく思った。どう考えても、これが芥川賞を逃したのは思えぬ。中島敦の文章は、どれも第一流に属するものであることは疑いがない。こんなすばらしい文章を評価できずして、一体芥川賞の審査員達は何を読んでいたというのだ。

芥川賞、なんと質の低い賞であることか。中島敦も太宰治も村上春樹も評価できずして、一体なんの面目があるというのか。塵芥川賞とでも改名したほうがいいだろう。

思うに、中島敦の作品は、常に死というものへの覚悟があるように思う。これは、中島敦自身、病弱であったことも、その理由のうちだろう。果たして、死への覚悟があれば、よい小説を書けるのだろうか。ニーチェが熱狂的な読者を持っていることから見ても、これは正しいように思われる。中江兆民の、続一年半も、たしかに優れた文章だった。

然るに、私はいささかの死ぬべき要因をも持ち合わせていない。この二ヶ月運動をしているので、かつて無いほどの健康を感じている。死の実感が無いものに、何で能く覚悟などできようか。