日々の破片

_ GitHubでJavaはどのくらいメジャーなのか？

この一か月でGitHubで一番人気なのはどの言語なのか？というのを見て、えらく不思議に思った。

というのは、当然、GitHubなのだからRubyが一番だと思っていたからだ。追記：RailsのHubになったとか、いろいろな経緯からRubyコミュニティが大挙してなだれ込んだのを見ていたからそう思うわけで、CodeHausはJavaとかCodePlexはC#とかリポジトリにもコミュニティカラーってのがあるからだ（世の中のオープンソースはRubyが多いという意味ではないことに注意）。

でも、まあ、JavaScriptってのはありだなぁと、それは良いのだが、2位のJavaというのは不思議も良いところだ。

星さんによると(とは言ってもBlogには書いてないな―追記：素早く補足されている)、Apacheなどのフルタイムコミッターを抱えているプロジェクトのミラーがある＝コミット数が多いという説を見たことがあるということらしい。なるほど、元の結果は、アクティビティの数の集計が元になっている。

では、プロジェクトの数そのものはどうなんだろう？ と、当然の疑問を持つ。コミットが多いかどうかよりも、どのくらいプロジェクトがあるかのほうがおれには興味がある。

で、おれも試しにBigQueryをやってみた。クエリが間違っているかも知れないので、利用したものを示す。

select repository_language,count(repository_language) cnt 
 from (SELECT repository_url,   repository_language 
   from publicdata:samples.github_timeline 
   group by repository_url,repository_language) 
 group by repository_language order by cnt desc;

repository_urlでユニークにすれば、アクティビティではなく、プロジェクトが（フォークされたものを含んで）カウントできるだろう。

結果は、以下の通りで、repository_languageが空白なのが一番多いから、全然わからん（言語複合のプロジェクトなのか、プロジェクトオウナーがだらしないからか、とか最初思ったけど、gistを含んでいたりするからだろうな）。

やっぱRubyは多いじゃん（Javaの1.5倍以上）。でもJavaScriptは掛け値なしに1位ですなぁ。

逆に下を見ると、91位はFantomで2プロジェクト（Fantomって何だ?）、90位は、DCPU-16 Assemblyでこれも2プロジェクト、89位がAugeasで3プロジェクト、88位はやっと知っている名前でSelfで3プロジェクト、以降順に下から、Bro、Logtalk、Nu、Max/MSP、Ioke、Fancyと実にファンシーな結果なんだが、世の中知らないことがたくさんあるなぁ（でも、まつもとさんとか、「ああIokeね、あの言語は……」とか語れそうだな：6/6追記 本当に語ってくれた！）。

結果のCSV。

_ ゴードン・ベルの話がおもしろかった

人格というのはなんだろうか？ ってことは、つまり精神ってのは何かみたいな設問だろう。

脳が受け取るすべての信号と（なんらかのフィルタリングをかけた後の）蓄積と、その蓄積された情報がまた新たに受け取りフィルタリングすることで変型されて蓄積されていく情報の積み重ねと仮定することは、確かに自然な発想だ。が、そういうことは考えたこともなかった。

すごくおもしろい。

_ VimとEmacs

VimLはEmacs Lispの2倍以上という結果からは、2つの異なる考察が導かれる。

Vim派の結論：ほら、世の中Vimが人気2倍以上。Emacs死ね。

Emacs派の結論：使えるデファクトなマクロが無いから、一生懸命作ってるわけね。ぷぷぷ.

_ 新国立のローエングリン

何をおいてもフォークトが素晴らしくて、おお、現代のバイロイト歌手はこうなんですか、という説得力のきれいでよく通る声、確かにこの演出みたく天からこの声で歌を歌いながら白い服をきた男が舞い降りて来たら、神が遣わしたと信じてしまうだろうな(8世紀なら)。

開演時間がどの日も妙で、勤め人に来させないための陰謀かとか友人と話していたが、最後に子供を使う演出だからみたいだ(でも、子供の労働時刻制限ってまだあるのかな？)。というのがエクスキューズで、真意はどうだかわからんけど。

エルザのメルベートはかわいらしく、というか今回とてもよい席で観たのだが、3幕1場の演出が、仲睦まじい恋人同士の他愛のない痴話喧嘩みたいな演出で(やれやれこれだから、とか、どーしてそうなるの、とか、ちょっとまじめにきいてよ、とかを演技で示す)その微笑ましさが、一転、ローエングリンの開き直りに変わる作劇の奇怪さ。ただ、ついオルトルートの科白を使って「高慢ちきな」クズ扱いするヴァグナーのシナリオの説明っぷりはおもしろい。

他の歌手も悪くはないのだが、歌劇そのものがまだワグナーの作劇術が発展途上なので2幕の最初とか退屈きわまりなく、3幕だって実際に曲だけ聞いていればうんざりするほど退屈なのだが、とにかくフォークトが出て歌っていればそれだけで舞台が成り立ってしまうので、結局ローエングリンが出てこない2幕の最初（1幕の最初はそれなりにドラマがあり合唱が楽しいのでOK）以外は全編楽しみに楽しめた。あー楽しかった。

ワーグナー歌劇《ローエングリン》バーデン・バーデン祝祭劇場2006 [DVD](ケント・ナガノ)

（生フォークトのほうが良かった！）

ヘルデン(フォークト(クラウス・フロリアン))

（死の都も入っているし、これは買おう）

#それにしても、この数か月の新国立劇場の歌手の良さはびっくりだ。

_ 「アルゴリズムを学ぼう」で質問！

日曜に達人出版会からアルゴリズムを学ぼうを購入して読み進めていたんだけど、ふと、どこで見かけたか忘れたが、「数式を飛ばさずちゃんと読むべし」みたいなことが書いてあったのを思い出して、まじめに読んでみた。

アルゴリズムを学ぼう(川中真耶)

すると、困ったことにさっぱりわからない自分に気付いた。77ページの先頭。

マージソートの計算量としてT(N)=2T(N/2)+cNが出ていて、一応、ここまではわかるつもり。T(N/2)は分割した配列をマージソートするのに必要な計算量で、分割しているから2T(N/2)で2つ分の2×がつく。T(0)はreturnするだけだから、0というのも良い。

で、おとぼけ役の女の子が

えーと、N= 2^k なので、まず T(2^k) = 2T(2^(k-1)) + c2^k と書き直して、2^kで両辺を割る。

で、ここまでも問題ない。2T(N/2)は、2T(N * 2^-1)なので、N=2^kで書き直すと2T(2^(k-1))。

すると、T(2^k)/2^k = T(2^(k-1))/2^(k-1) + cなので、S(k) = T(2^k)/2^k と置けば、S(k) = S(k-1) + cと書き直すことができる。

ここまでも問題ない。

でも、次で引っ掛かった。

T(0)=0だったから、S(0)=0だから、S(k) = ckになる。

なぜ？ T(0)=0はそういう前提だから問題ないけど、なんでS(0)=0になるの？ 初項だから？ S(k) = T(2^k)/2^k で k=0の時ならばS(0) = T(2^0)/2^0で、これはS(0) = T(1) で、T(1)は0じゃないじゃん（と、読んだ時点で、根本的に読み方が間違っているのだろうと判断するわけだが、ではどう読むのが正しいのだろうか？）

で、そこは目をつむって（多分、数式の読み方としては正しくない態度だとは思うが）S(0)=0を受け入れたとしても、なぜS(k) = ck となるんだろう？ （実はここはわからなくはない。Sも漸化式だから、S(k) = S(k - 1) + cということは、SiとSi+1の差はc、したがって、S(k) = ck だと思うのだが、本当にそういう読み方で合っているのかなぁ）

というわけで、漸化式と単なる関数をごたまぜにして読んでいるようでもあり、つまるところはこのあたりをまじめに勉強しなかったうえに忘れきっているのでさっぱりわからない。S(0) = 0のところは、k=0と代入するのではなく、T(0) / 2^k の分子が0なので、Sの初項も0と読むのかな？ とか、考えれば考えるほどむしろわからなくなる状態です。

よろしければ、教えてください、よろしくお願いします。

_ 他山の石

わからないってことの一端には、自信がないってことが、確実にあるなぁ。だから、どう考えても自明なミスでも、読者によっては、それが間違いらしいとは思えても、自信がないだけに自分が間違えてる可能性を捨てきれず、結局そこで足踏みするってことだ。

肝に銘じておこう。

_ 言葉遊び

キリスト教に帰依した人を、キリスト者と呼ぶ。

ならば、幸福の科学に帰依した人は、幸福の科学者だろう。

幸福な科学者は想像しやすいが、幸福の科学者という言葉は違和感がある。

「幸福の」という活用は特異だからだ。

ぱっと考えるとオスカーワイルドが出てくる。

幸福の王子(オスカー・ワイルド)

幸福の王子は、渡りに乗り遅れたツバメを使って自ら身ぐるみ剥いでボロボロになって溶かされてしまう王子の物語であった。

ならば、幸福の科学者も自ら身ぐるみ剥いでボロボロに溶かされてしまうのだろうか。

もしそうならば、実に「の」は恐ろしい。

元の宗教に帰依した人の呼び方を離れると、幸福の科学者ってのは確かに存在することに気付く。

テスラはその筆頭だろう。

テスラ―発明王エジソンを超えた偉才(マーガレット チェニー)

自らを剥ぐといえば、こんな本があって、ずいぶん面白かった。

自分の体で実験したい―命がけの科学者列伝(デンディ,レスリー)

文字通り身ぐるみ剥がされて（受動的）溶かされた女性科学者もいた。

アレクサンドリア [DVD](レイチェル・ワイズ)

溶かしたのはキリスト者なので円環が閉じる。

_ 佐川くんの手紙

ぽっぺん日記を開くと予想外の絵が出ていてびっくりする。

あまりラノベ（なんかアッカンベーみたいな言葉だ）とか読まない人っぽいのだが。

で、本文を読むと、なんとビジネス書みたいだ。佐川流経営とか。

なんと楽しい時代になったんだろう。

佐川萌え(坂口 さゆり)

今のところ技術書分野とビジネス書分野（ドラッカーのやつが先鞭をつけたってことかな）が、この道を突っ走っているわけだが、それは技術者と経営者は当然、時代の流れに過敏だからだ。

ということは、そろそろ海舟萌えとか、後醍醐萌えとかの偉人伝（前者はそう思わなくもないが、後者はむしろ怪人かも）や、五輪書萌えとか花伝書萌えとかの日本の思想書とか、パスカル萌えとかモンテスキュー萌えのような海外思想研究書とか、エチオピア萌えとかモルディブ萌えみたいな観光書とか、子育て萌え（もうありそうな気がする）とか、絵本のジャンルも再翻訳された機関車トーマス萌えとか、小さなお家萌えとかの絵本とか、今日の料理萌えとか、天然酵母でおいしいパン萌えといった料理分野、さらには高慢と偏見萌えとかトニオクレゲール萌えのような翻訳文学まで、本屋中が、このての表紙で埋め尽くされる日も近そうで、わくわくする。

で、そうなると、電子書籍なんか本物の本ではございませぬ、みたいな寝言をたれている人たちが、なんとなく本当の本屋から足が遠のいて電子書籍のほうを買うようになったりして市場が混乱するとおもしろいなぁ。

_ facebookのいいねボタンの謎

良く、Webページにfacebookのいいねボタンが付いていて、おれは、あれを押したくて押したくてしょうがなくて、ついに押してみたわけだ。

で、するとログインしろと出てくるので、ふむふむとメールアドレスとパスワードを入れて「ログイン」をクリックする。

すると「表示された言葉を入力してください。」とキャプチャの存在を匂わせる香ばしいメッセージが表示される。

のは良いのだが、一体、どこに何を入力すれば良いのだろうか？

でも、facebookのタイムラインを眺めていると、「いいねしました」みたいなエントリーを見かけるので、おれ以外の人たちは表示された言葉を入力できているのだろう。

やっぱり、キャプチャはおれには無理っぽい。

_ 黒い社員

それにしても、同じ佐川でも黒い本と萌え本の落差がすごい。

ブラック社員がこんなに！動く　佐川急便の『マネジメント』(大重 寛)

その秘密は黒い本に書かれているっぽい。

中途採用には罵声を浴びせる　／　新卒は我が子のように優しく

なるほど！

_ 半分他人のおれ

子供が本当の赤ん坊をちょっと越えたくらいの頃（まだ乳児ではある）、こんなことがあった。

夏を控えて（ということで思い出したが、つまり11か月目くらいだな）散髪に行って髪の毛をばっさり切ってきた。忙しくてずーっと伸ばしっぱなしだったから、ほとんど刈り上げが入ったおれを見るのは、多分、はじめてのことだろう（ほとんど見えてないような頃は別として）。

で、いつものように、食卓につくと、子供がひきつった顔をして、おれを避ける避ける。（いや、正確にはおびえきった顔をしておれを見ているという感じだった）

ははー、髪を切ったから見知らぬ他人と思ったんだなぁとかその時は思ったわけだが（妻が、ほらほら、いつものやつでしょ、みたいなフォローをしてくれても、とにかくおびえていたのはわかった）、それにしても、ちょっと妙な気はした。あまり人懐こい小僧ではないが、だが、そこまで人見知りというわけでもないからだ。両親が来たとか、保険所のおばさんが来たとかでも、あそこまでおびえた様子はなかった。

で、母親と他人の狭間 －赤ちゃんが示す「不気味の谷」現象を発見－だ。

これはすげぇおもしろい。

元の研究＝1970年（というのを実はこれ読んで知ったくらい、不気味な谷現象というのは、おれは例のアバター以降のCGの文脈でしか知らなかったわけだが）に、こういう分野へ適用されるとは考えもしなかっただろうなぁ（そのくらい、モーフィングやビデオ合成の技術が進歩してるってことだけど）とか、実に奥が深いおもしろさに満ちている。

で、これを読んで、ふと、上のことを思い出した。というか、忘れられないくらいに、印象的だから当然、あてはめたくもなる。

というわけで、あの時のおれは、子供にとって不気味の谷から這い上がる半分父さんに見えたのかも知れないなぁ。

_ 電子投票は難しい

ちょっと電子投票システムについて考えてみたが、おれの想像を超えて厄介なものだな、と気付いた。知らぬはおればかりなりということだ。

東京とかで考えるからいい加減になるので、以下の条件で考えてみた。

・田舎町の市長選挙

・プロバイダはCATV一社のみ。CATVということもあって、ほぼすべての市民はこの回線を利用している。

・携帯回線（3G）はある。

・システムは選挙管理委員管轄で、サーバールームは市役所にある。

・市長選には、現職、対立の2者が優勢で、他に共産党と無農薬エコがそれぞれ立候補している。50:46:4:0 くらいな状況。

・現職市長の一派は地元の昔ながらの経済を牛耳っているので、店子とかは大家から、現職に投票したほうがいいですよ～とかそれとなく言われているので、ちょっと他の候補者に入れると知られたくはない状況。特に地場の企業に就職している人間は毎日演説会にまで動員させられている始末。ちなみにプロバイダのCATVは現職が10年前にてこいれして引っ張って来た会社で、現職市長の弟が社長をやっていたり。

・対立候補は、地元の大手工場の労組が支えているので、工員たちは～君をよろしく、と毎日言われている状況。現職に投票したのがばれるとなんかいやんなことが起きそうな予感。工員はやたらと数がいて、市の半数弱を占めている。

・最近の地元不況で、一部の商店主とかが対立候補に傾きつつあるという噂も流れている。商店会の会長は、裏切りものが出ないか毎日のように親睦会を開いて睨みをきかせている。

・市内でシステムを構築できる技術を持つ企業は、大手工場に付属しているソフトハウスと、現職の甥が経営しているソフトハウス（基本的に市役所のシステム構築は数十年にわたってここが受託している）。

システム要件は選挙である以上は、

・選挙人は全員1票を投票する権利を受けられる

・選挙人は1票のみ投票でき、投票後は再投票はできない

・どの候補者に誰が投票したかは絶対にわからない（あたりまえだ）

・選挙人の数は1万弱程度（ちょっと多い気がするけどまあいいや）と想定する。

・投票された1票は確実に選挙人の投票行動と一致する。（現職に投票したはずが、いつのまにか対立候補にカウントされるということはあり得ない）

問題点

まず政治的な合理性に基づいて考えると、現職が勝てばCATV会社を経由している点が怪しまれる。対立候補が勝てば、市役所内のサーバーチェックだの、CATV会社でのログチェックで、犯人捜しが行われるのも想像の範囲。

というか、投票システムの入札でどこが受託するかはやる前からわかっている。仮に予想が外れても大差がなかったり。というわけで、どうすれば、そのシステムが公正なシステムと担保できるかが最初の問題。

仮にそれが解決したとしても、これまでの紙の投票だと、さすがに1万枚弱の筆跡を分析したりするのは無理だと思っていた連中が、システム化されれば、誰がこの市に住むべきではないかとか、減給対象にできるかとかが、ばっちりわかるのではないかと期待している状態を、どう解決できるかが次の問題。

つまり、選挙が匿名で行われるということ＝誰が投票したかわからないのであれば、現職のほうが得票が多かったと発表すれば済むし（なぜなら誰が誰に投票したか調べられない）、逆に誰が誰に投票したかがわかるのであれば徹底的に社会的報復を食わせられるのでそれもまた良し、と期待にわくてか状態の人たちの期待をどのようにすれば、それが無理だとシステム的に理解させることが可能なシステムとできるかという問題である。

・まず、そう考えてみると、電子投票システムは、暗号のアルゴリズムと同じで、公開システムでなければならないようだ、ということが想定できる。投票箱への投票行為と開票行為は完全なホワイトボックスシステムである必要がある。（受託して開発するようなものではなく、オフザシェルフでなければならない）

・経路の安全は、内容の秘匿だけで不足で、アプリケーション層が内容を取り出した瞬間に経路情報から完全に分離する必要がある（デバッグが大変そうだ）。つまり、このIPアドレスから送られたメッセージというものと、この投票トークンというものを、後から再結合できないようにする必要がある。でも、その一方で、その投票トークンが明白にシステム内で生成されたものではなく、外部由来のものだということが明らかでなければならない。

とすると、まずシステムそのものは、第3者機関が提供、設置するものでなければならない。最初の前提と変わるなぁ。ベリサインみたいな機関が必要なのだな。ISPはそうであれば単なる通過点となるため、内容さえ秘匿できていれば良い。

誰が誰に得票したかは、本人確認が可能であれば良しとして（そうでなければ、その投票は私ではないと名乗ることに問題ない）考えると、個人と紐付けた投票トークン（これは公開）と、そのシステムを通して得られるハッシュ（これは秘密。本人は参照可能）とし、システムはハッシュと被投票人の紐付けペアを持てば良い。追記：投票時に生成する必要がある（おそらく投票時間をソルトとして付加することで、公開の投票トークンを知っていても再現できないものとしなければならない。投票トークンと投票先を送ると、ハッシュ（意味としては秘密の投票トークンだな）が返ってくるので投票人はそれをメモすることで自分の投票を後で検証可能とする、とすれば良いと思う）

そのようになっていれば、最悪の状況として、開示が必要となれば、ハッシュとその投票先のリストを公開する。ハッシュは本人のみが知っているので自分の投票結果と一致するか、あるいは自分がリストされているかを確認できるということだ。もし自分の投票結果と一致しない、あるいはリストされていない、という状況が確認できればそこで文句を言える（と思うが、最初の前提から、対立候補に投じたはずの票が、なぜか現職に投じたことになっていても、公開の場で異を唱えられないということはあり得る。というわけで、バグ以外の原因で投票行為を恣意的に操作することが考えにくい第3者機関がシステムを持つ必要があり、投票結果を左右するような有意な障害は起きないものとみなせなければならない。面倒くさいな。追記：これだと水増しされたリストが発表された場合に間違いを指摘できない。どうやって水増しされていないことを担保できるか？ これも第3者機関なのでそのモチベーションが無いということで担保するしかないのかなぁ）。

ここまでを確認すると、まず投票結果の集積所は第3者機関とし、投票トークンの発行は現在と同様にどこでも良く、ただしハッシュの生成と管理は同様に第3者機関が行うとすれば済む。（通信はSSLで良い）

なんか、まだまだ電子投票が可能な民度に達していませんというように感じてしまうおれがいる。

_ 電子投票は考えれば考えるほど難しいね

昨日は被選挙人側（システム側）の不正について考えてみたが、選挙人側の不正を考えるともっと厄介なことに気付く。

ハガキに投票トークンが書いてあるものが送られてくることを想定する。36桁のトークンだ。

でも、ということは、36桁のトークンジェネレータを利用して、次々とトークンを変えながら投票するプログラムを作られることにどう対応できるだろうか？

同一IPアドレスからの異なるトークンを排除するとした場合は、家庭内で4人がそれぞれ異なるコンピュータから投票することを阻害する。ブラウザで投票するとしてクッキーで管理する？ まさか。

誰かが、既におれのトークンで投票している！ となった場合、選挙管理委員会に苦情を申し立てることで管理できるだろうか？ 大体の投票率は50%前後なのだから、約50%は早い者勝ちの草刈り場となり得るね（つまり、投票人による監視が必須）。

後勝ちで有効票とするというのもだめだろう。朝早く投票して放っておいたら、別のやつが上書き投票できるということだからだ。

いずれにしても、投票人による開票結果の検証は必須となる。

紙と箱の選挙を考えたやつの頭の良さに舌を巻く。

衆人環視の投票所で、ハガキと交換で紙を1枚、投票人に与える。投票人が箱に何十枚も事前に用意した紙を入れないように監視できる（監視している選挙管理人が信用できなければ、投票所にどちらの選挙陣営も第3者管理人を送って不正を見張らせることが可能だ）。

箱を開けて紙の内容をカウントしていく作業も、基本公開だ（なので、双眼鏡を利用して開票所を監視して速報を打てる。これが重要だということがはじめて理解できた）。

明らかにおかしいと考えられた場合、あらためてカウントすることもできないことではない。納得がいった時点で投票用紙は廃棄できる。

電子投票システムは、投票時点の不正確認のためには、2種類のトークンが必要で、結局、投票人が秘密キーを事前にシステムに登録していなければならない。

（投票時点で入力するのであれば、自動投票プログラムで代理投票が可能となるからだ）

事前に登録した秘密キーは開票後の（投票システム側の）不正確認に利用できる（昨日は、このキーは、投票時に生成するハッシュで良いと考えていたが、それは投票人による不正には対応できない）。

shiroさんが教えてくれた論文(Election verifiability in electronic voting protocols)は途中から極端に難しくなる(証明をまったく読めていない。地の文で書いてあることは読めるけどわからない)のでどうしようもなくななめ読みになってしまうのだが、最初のあたりを読むと、既にいろいろ考案されて、課題が確立されているようだということがわかっておもしろかった。さすがに事前にキーを登録するような仕組みではなく、電子署名の利用が前提となっている（と読めた）。

3つのverificationが必要だとしていて（そのうち最後のものが、この論文で提案されたものと読めるのだが、まさに水増し対策を含むものだった）、

・Individual verifiability

投票人が自分の投票が開票結果(the ballots published on the bulletin board)に正しく反映されているかを確認できること

・Universal verifiability

誰もが開票結果(the ballots published on the bulletin board)が選挙結果(the election outcome)に反映されているかを確認できること

・Eligibility verifiability

誰もが登録された選挙人の唯一の投票のみが選挙結果に反映されているかを確認できること

紙と箱のシステムは、このうち1つめと3つめの検証可能性を自ずと備えている。

ところで、この論文を読んでいてへーと思ったのが、FOOプロトコル（1992年のA. Fujioka, T. Okamoto, and K. Ohta.）で、その後の研究の元ネタ(influential for the design of later protocols)としてあって（この論文の中では後続のプロトコルを採用している）、この分野で日本人（だと思うよな）が基盤を提供しているのか、となんとなく（まあ、民族的な自尊心みたいなものが無いわけではないので）嬉しかったりしたけど、後は続いてないのかな。

_ githubのここが大嫌い

githubには、お世話になっているが、どうにも気に食わないところがある。

でも、もしかしたら、おれが知らないだけで、～すればいいだけじゃん、みたいなことも当然あるので、ここで不満点を書いてみる。

何が気に食わないかと言えば、HTMLがまともに読めないことだ。

いろいろ理由があって、HTMLがレポジトリに入っているとするじゃん。

で、それをブラウザーを使って（だって、githubだからね）読みたいとする。

でも、そうは問屋がおろしてくれない。

ファイル名をクリックすると、行番号つきのテキストとして表示される。きれいに色がついているが、styleで指定したcolorが反映されているわけじゃない。タグが紺色っぽい色、属性名名が緑青で、属性が赤になっているだけだ。つまり構文を解釈して種類によって色わけしてあるだけだね。もちろん、おれはHTMLのソースが読みたいんじゃないんだ。

で、右のほうのボタンを見れば、「Edit this file」（もちろん違う）、Raw、Blame、Historyとあるから、そうだ、HTMLのRawってのは、つまりHTMLとして（レンダリングされて、というかcontent-typeがtext/htmlとして）読めるんじゃないかと期待して、クリックしてみる。と、これまたplain/textで返るだけで、行番号と構文の色付けがなくなるだけだから、まったく役に立たない。

ということはなんですかい？ WebサーバーにHTMLが置いてあって、おれはWebブラウザーを使っているのに、わざわざRawを右クリックして「名前をつけてリンク先を保存」して、一度、ディスクにコピーして、それをあらためてブラウザーで開かないと、HTMLとして（つまりレンダして）読めないってことですかい？

もちろん、ソースファイルとしてのHTMLとして見たい場合があるのは、githubなんだから当然で、デフォルトがソース表示で……というのは当たり前にOKなんだが、それでもやっぱり、ばかじゃないのか？ と言わざるを得ない。

構文の色付けできているってことは、これがHTMLだということを認識しているはずなのだ。ところが、たかだか、content-typeをtext/htmlとして送り返すだけの機能が無い。スクリプトをgithubサイドで実行できないっていうような無茶振りとは思えないね。

というわけで、githubのHTMLの扱いは非常に不満だ。不快と言っても良い。

（と、iPadでgithubを撫でまわしてすごく不満を感じるのであった）

_ 礼儀正しさ2.0だと認識しよう

普通の人がネットワークを使い出して15年がたった。言っとくけど、パソコン通信とか、テレホ時代ってのは普通の人の世界じゃないぜ。

という題と枕で礼儀正しさ重要についてかこうと思ったがやめた。

_ Githubのここが嫌いはここが間違い

Chromeはもちろん、IE9でさえ、RawでHTMLを読むとタグの羅列が戻ってきて読む気にならない（承前）。IE4あたりだったら、何も考えずにHTMLとしてレンダリングしてくれたのになぁと思いながら、ふと、iPadのSafariで見てみたら、ちゃんとレンダリングされて表示された。

つまり、前回のエントリーの最後の段落は嘘だったようだ。おかしいなぁ。

_ C#は奥が緩い

public class A {
  public string Test { get; set; }
  public static void Main()
  {
    var a = new A { Test = "abc" }; // new A() { Test = "abc" } と書かなくても良い
  }
}

_ 無駄な未来

今後5年以降のトレンドを考えてみると、考えなくても、ファイルはオンラインストレージに移動すると考えるほうが自然ですな。それがDropboxなのかSkydriveなのか.mac（iCloudだっけ？）のどれが生き残るか、どれも死に絶えて、灰の中から別のフェニックスストレージが出てくるのかは知らんけど。

にもかかわらず、ダウンロード購買した本やら音楽やらは、個人に紐付けされるわけで。

ということは、世界で一番売れた本とか音楽とかは、みんなが一番使うオンラインストレージ上に、ばかのように大量に複製されて乗っていることになる。

無駄だな。

でも、ストレージ業者はばかじゃないから、危険分散のための複製はともかくとして、各個人がコピーした同一ファイルはハッシュか何かでうまいこと単一の実体データとそれに対するリンクのような形式で管理したくなるかも知れない。

でも、購入者個人単位にフィンガープリントを埋め込むとすると、同一コンテントが別データ（バイナリは異なる）となるので、すると上記のような単一化はできなくなる。

というか、インフラ面では、衝突しないで済むハッシュのビット数のインフレが必要となったりもするだろうし。

かと言って、単一ストレージの単一データのリンクという形式は、言論統制の面からは危険極まりない代物だから、その点からは、フィンガープリントが異なるから別実体として購入者分のコピーとして偏在するほうが安全な気もする。

というわけで、無駄ではあるが、全世界のオンラインストレージをコンテンツ単位でまとめると100億分の1くらいの容量で済むにもかかわらず、どんどこサイズだけは膨れ上がる。

ある程度膨張すれば、爆発する。

そして数千年だか数万年だか後に、最終的なストレージ（しばらくは磁気だろうが、それが珪素になるのか何かの反射素材なのかはわからないが）の破片が断層から発掘される。

これは何だろうと、いろいろ手を尽くして調べる。さらにばらばらと断片が見つかり、実はそれが同一のものであることがなぜかわかる。

特定音域を64000個に分割したものを時系列に並べたデータで、それが音波を示していることが突き止められる。

おお、これが21世紀の音ですか、と再生音を鳴らす。

だいたい、そういう場合に再生されるのは、イエスタデーかビートイットと相場が決まっている。彼らはクリスマスは知らないだろうね。

解読方法がわかったこともあって、発掘されたストレージのかけらたちが次々と再生される。

おい、またイエスタデーだよ。

イエスタデーってどういう意味だ？

太古の生物はよほど統制が取れていたようですな。蟻んこのようなものか？

と、謎は謎を呼びながら未来の人たちはイエスタデーをあさるのであった。

イエスタデイをうたって 1 (ヤングジャンプコミックス)(冬目 景)

_ 能楽堂1.3.1

演能にバグというか、うかつなところがあったので修正しました。

で、Rubyも1.9.3p194にバージョンアップして、でもRailsは3.2.2のままとして、能楽堂1.3.1をリリースしました。

ダウンロードはここから

演能の修正点：HttpReceiveHttpRequestに与えるバッファを適当に3Kバイト程度にしていましたが（根拠は以前、IISがURI用に2Kを確保しているとかを読んだことがあるからで、2K+1Kなら良いかなぁといったところ）、当然、それを越えるURIを与えると、思わぬエラーとなることです(しかもHttp.sysは内部UTF-16なので、実際は半減するという)。どういうエラーかと言うと、Rackのlintエラーというもの。Http.sysがバッファが不足しているため、途中でパースを中断し、そのためRackに与える環境変数がほとんどセットされない状態となるからです。

で、死んだり、不正なコードが走るわけではないので、それはそれで良いとは思いますが、ここでHttpAPIのドキュメントをあらためて読んだら、バッファは最低でも4K用意しろ、認証するなら16Kは用意しろと書いてあるので、おおそうですか、と増やしたということです。

問題の報告者：masatecさん

どうもありがとうございます。

_ 奴らにふさわしい花束を

電子書籍に対する意識調査を読んでいて気づいたが、というのは嘘で前からわかっていたが、手触りというか皮膚感覚を伴わないというだけで、コスト度外視で価値が半減すると信じ込んでいるカスにふさわしい商品というものがある。

紙の本で、好みやシーンに合わせた、100種類の商品を生産するのは厄介だ。というわけで、通常はハードカバーを売って、ある程度の費用を回収したところで、まだ伸び代があれば文庫版にして、底辺読書家を拾うということになる。

でも待て、電子書籍であっても、同じことをやるには、少なくとも2種類の表紙絵を用意して、2種類の解説(普通は文庫版特権だけど)を用意したりするからそれなりのコストはかかる。

でも、自動車と同じように1つの書籍について16種類のカラーリング(表紙だけだね)を用意するためのコストはどのくらい必要だろうか？ あるいは、デフォルトのフォントサイズを、シニア用とノーマルと、Reina版の3種類用意するためのコストは？

コスト計算もできない乞食にはそれにふさわしい皮衣を用意すれば良い。

バイオレットで揃える……と、アジュールブラウン(どんな色かな)で揃える……と、シルバーモンブランで揃える……と3種類用意して、しかも3種類のバージョンの一括購入ならお値打ち価格で、個別に買うより1種類分お得！ とか。

紙の本を2種類購入させるのは、内容を読書する人間に買わせるのは難しい。だが、内容を読書しない単なる消費者に対しては、有効に働くと想像できる。ではそれを試すコストは？ というのが、紙の本と異なる電子書籍の販売側のメリットだ。クリームパンナコッタ版が1冊も売れなくてもいいじゃん。重要なのはカタログをふくらませるところにあるからだ。

ジョブズ本を、白表紙のジョブズブックポリカーボネートと、黒いジョブズブック、アルミダイキャストカラーのジョブズブックプロ、そして限定販売のジョブズブックボンダイブルーと用意するコストは？ 棚面積は？ 4冊一括購入特典で3冊分の価格で売ってやるための追加コストは？ システムの初期投資だけだ。

スティーブ・ジョブズ I(ウォルター・アイザックソン)

(ポリカーボネートバージョン)

で、そうやって売って利益を出して、真の読書家のためにプレインテキスト版を提供してくださいよ、本当(やっぱ、Ctrl-vでページを下ろせないと読みにくいんだよね)。

（つまり、iBooksの本棚に色違いの同じ本を並べさせて消費者を満足させることが目標となる。例：ノルウェイの森の緑版、赤版、黄色版、白版とかね。5色そろえた人には表紙がクリスマスツリーの特典版が安く買えるよ! クリスマスツリーの表紙が並んでいれば真のファンだ！ とか煽るのは絶対に必要だな。しかも半年後にはマホガニーが表紙の特典版も出したりしてね）

_ オーディオ的な宗教が生まれるとき

上で書いたことを出版社が始め、しかも成功をおさめたと仮定する。

すると、電子書籍評論家という人たちによって、「やはりノルウェイの森の真髄は赤でなければ味わえない」、「いや、クリスマスツリー特典版がもつ上質な読み応えが最も感動的だ」、「真の読書家であるならば、緑版をiPadでこすっているときの手触りでなければ、登場人物の心理を感じ取ることは不可能だ」といったオカルト談義が楽しめるよ！

ノルウェイの森 上 (講談社文庫)(村上 春樹)

_ 怒りの酸っぱい葡萄

子供がこれおもしろいから読めと、スタインバックという人のエッセイを持ってきた。

英語の副読本だか教材だかのプリントで、どこの誰かは知らないけれど日常の風景としての人物というものに対して書いた小品で、確かに気がきいている。そのしんねりむっつりした背の高いおっさんが誰かは知らないけれど、朝8:12丁度に店の前を通らないと人生の一部に虚無が生じるというような感覚について語ったものだよ（カントの散歩道の商店主談）。

で、スタインバックという名前をスタインバックと認識できなかったおれは、この名前はスタインベックなんだろうか、それともスタインバックなんだろうか、と子供に訊くと、子供曰く、いやSteinbackだからスタインバックなんじゃなかろうか、ではおれが知っているスタインベックはなんだろう？ 昔の日本人はbackをベックと翻訳したのかなぁとか言うと、一体、そのスタインベックとは何者か？ と真顔で訊かれて返答に窮する。

お前はスタインベックを知らんのか？ というかアメリカ文学についてカタログ的に10人上げろといえばまず間違いなく入る名前だし、文学としての価値という点からは最上位に君臨する金字塔がスタインベックだろうと言えば、いや知らんという。

ポオは知ってるだろう？ カポーティは知っているだろう？ マークトェインはもちろん知っているとして、ノーマンメイラーは知らなくてもいいけど、ヘミングウェイは知っているだろう？ というようなどうでも良いやり取りをしながら、とりあえずja.Wikipediaを引くとSteinbeckだった。なるほどこっちはeなのか。良く似た名前があるのだなとか言いながら、でも知らんのなら、とりあえずこの紹介に嘘はなさそうだから読めと、『怒りの葡萄の項』を開いて渡す。

次々と人が死ぬんですが、と子供が言う。しかも風と共に去りぬの次に売れたとか書いてある。

それがアメリカというものだし、アメリカを理解するには何を措いてもまずは怒りの葡萄を読んで彼らの原風景の殺伐さを理解しなければ始まらないから、少なくともおれが幼かったころは、まずアメリカ文学といえば怒りの葡萄を読むところから始まったんだけどなぁと答える。

それにしても、フランス文学では未だにああ無情というかレミゼラブルだし、イギリス文学といえばディケンズ（オリバーツイストでもデビッドコパーフィールドでもクリスマスキャロルでもどれでも良いけど）なのに、アメリカ文学が変わったのだとしたら何かの政治的な意図でもあるのかな？ とちょっと陰謀論がちらちらするが、さすがにそれは無いだろけど。

怒りの葡萄 (上巻) (新潮文庫)(スタインベック)