バグのデータベースとか

　バグトラッキングシステムをお使いの皆様方こんばんわ。
唐突ですが、失敗知識データベースってご存知でしょうか。
たしか、科学技術関連の雑多な「失敗」をデータベースとして管理公開して、
みんなで教訓を共有しようぜ！というプロジェクトだったと思います（うろ覚え）
どうもこのサービスは終了が決定しまったようですが。

　最初は面白くて色々とみて、へーへー言っていたのですが、だんだん飽きてきてすぐに見なくなった覚えがあります。

　こういうのが、「バグ」に対してあってもいい。いやむしろあるべきだと思います。

　前述のDBにはコンピュータで起こった過去の失敗事例というものが入っていますが、
かなり具体的な、個別のインスタンスの事例と実際の対策であって、もちろん有用と思いますが、もう一歩踏み込みたいところです。

　すなわち、問題をより抽象化し、デザインパターンならぬバグパターンのようなものを考えて、みてはどうだろうか。
デザインパターンというと数はそんなに無いけど、バグパターンだったらわりと数ありそうなのでDBとして蓄積し、それを共有財産にしてはどうだろうかという感じです。
もちろん、数が少ないなら、4人集まって本を出せばいいと思います。

　とずっと思っていたんですが、本日その道では有名な人の講演を受けたら、
似たようなことを考えていて、それなりにきちんと作っているそうな。
僕のぼんやり思っていたものに比べ、断然かっちりしていて、差異はあれど、それはそれで。
すごい人っているのね。

　と、ここまで書いて、たった今ググったら、バグ・パターンという言葉自体がすでに言っている人いるし。
これ。

アンチ・パターンまでは知っていたけれど、これは。
記事で扱っているターゲットの粒度は僕の考えているものと少し違うけど、これはこれで。

こういうことがあると、自分の考えは正しいという気になれる一方で、
自分ごときが思いつくことはもう誰かが思いついているのだと、ちょっと寂しくなる。

json hijack、ブラウザセキュリティ、サイト側のセキュリティリテラシーとかなんとか

　JSONハイジャックでよく攻撃の例として挙げられるパターンとして、

　サイトAの認証Cookieを持ったマシンBが、攻撃者Cのサイトにアクセスした際、
BにAからデータをリクエストさせるという例が良くあります。

　形式的にはまあ、昔々からあるお話で、通路がJSON、というかjsというだけですね。
こういったCookieの情報を利用してリクエストを投げさせるっていうのはわりとしょっちゅうで、
クロスサイトリクエストフォージェリもおんなじ様なことをしてます。
JSONだとArrayコンストラクタとかを改造して、うまいことデータを抜くのが主な用途？ですが、
CSRFの場合は、リクエストそのものに意味？がある感じでしょうか。

　最近だと、この手の脆弱性に対して、ブラウザ側でも対策を入れるようになってきているようです。
ですが何が切ないって、この辺の脆弱性といわれるものって、個人的には、ですが、わりとサイト側のつくりが悪いに尽きると思っているからです。
ブラウザ屋さんはSafety Browsing!とかなんとか言いたからやっているのかもしれませんが…

　むしろその辺に頼らせるようになった場合、UAとかで判断して、いつもは正常なサイトなんだけど、
古いブラウザやマシン、アップデートの難しい組み込みブラウザなんかを使っている人たちが来たら攻撃、
みたいな感じで狙い撃ちするような攻撃者が増えるだけなのでは。そのほうが露見が遅そうだし。
根本的な問題は、やっぱりサイト側にある（あくまで個人的な考えですが）以上、その辺を何とかするべきなんじゃ…
　まあ、多分やらないわけにはいかないんでしょうけどね。

　なんというか、Cookieもjsも、本当に出たてのころ（Netscapeとか、あのあたり）は、
危ない危ない言われていましたが、結局やっぱり色々と攻撃手法が出てくるもんです。

　最近だとFileAPIとか、JSONPですか？
今のうちにあら探しをしてみると、意外な落とし穴があるのかもしれません。
WebSQLは、どうせXHRみたく各ブラウザが微妙な互換の別実装をするでしょうから構えておいていい気がします。
もうすでにあらかた食い尽くされた後なのかもしれませんが、少なくとも僕は知りません。
見つけてもお願いですから悪用はしないで欲しいですが。

URIの長さの上限とブラウザいじめ

　URI(もしくはURL)の長さの上限ってどれくらいだろう？
GETを多用する人やブックマークレットでありとあらゆることをやりたい人は一度は興味を持ったことかと存じます。

　僕の知る限り、RFCではURL（の長さ）を規定はしていないはず。
俺責任取れないから、長さとかグレーにしとくわ、見たいな事が書かれていたような気がします。完全に気のせいかも。

　でも世の中には、死ぬほど長いJSとかをロケーションバーに突っ込むクレイジーさんだっているでしょう。途中で切ったりしてないのかな？

よし、ちょっといじめてみよう。
というのが今回のモチベーション。

98000000 = 9.8 * 10^7文字長まで試した。

●環境
　Windows7/i7-920/3Gbyte

●結果（文字数）

 IE    8.0.7600.16385 .... 2048
 Opera  10.53         .... 65531
 Safari 5.0.3         .... 50881
 Firefox 3.6.3        .... inf (?)
 Chrome 8.0.552.237   .... inf (?)

●やり方
　１．　テキストエディタでとてもながい文字列を入力
　２．　ロケーションバーにコピペ
　３．　ロケーションバー上の文字列を全選択してコピペ
　４．　txtに貼り付けてwc

●考察
　IEが残念すぎる。さすがにこの長さだと、GETのクエリとかやばいんじゃないの。
ちなみに、MSのページには2083文字と書いてあったので、多分この結果が当てにならないんでしょう。

　Firefox, Safariは多分制限を設けていないっぽい。
長い文字列をロケーションバーに食わせたときのFF,CHの挙動は以下のとおり。

○Firefox：
　ある一定以上長い文字列をペーストすると、ペーストはされているんだけど、
文字が表示されないという問題が。さらにそれをオーバーするとクラッシュする。
最新の3.6.13でも再現したけど再現率低い。というか、再現する前にクラッシュすること多数。
セーフモードではやってない。

○Chrome
　捌けるんだけど、長い（僕の環境だと3 * 10^7くらい）文字列は捌くのに5分くらいかかる。それをオーバーすると、わりと早々にあきらめてクラッシュする。
　今回気になったのは、右クリックでロケーションバーに貼り付けしようとしたときに、
クリップボードを先読みしているのか分からないんだけど、右クリックだけでクラッシュしたりしていた。ちょっとっ。

　で、この結果は、あくまでブラウザのアプリに対するロードテストで、
コアがどうURL捌いているかに直接関係無い可能性大きいのであしからず。

●今後の展望

　バリエーションとしては、リンクやdocument.location.hrefやらなんやら、その辺で以上に長いURL指定したらどうなるのかなぁ、ということを調べても良いかもしれないですね。
僕はもう飽きたのでやりません。

　後々知り合いに教えてもらったんですが、今回の件と同じことを考えて実践してみた人もいるみたいです。
5年前のことなので、比較してみるのも面白いかと思います。

SPACE ALC用のブックマークレット

なんてやる気のない表題なんだ。

　情強の方々はSPACE ALCなんぞ使わなくても脳みそのMySQLで間に合っているのでしょうが、
僕はその辺が足りないようなのでいつもお世話になっております。
きっとALCとLSDがあれば英語についてはもういい気がします。

　そんなときはブックマークレット。
新規ブックマークを追加　→　アドレス欄に以下のスクリプトを突っ込むことで、
トップページをすっ飛ばして検索結果にダイレクトにいけます。2011/01現在。

　いい加減、新しいタブ開く→トップページを待つ→入力という
一連の流れに耐え切れなくなって、たった今書いたのを貼り付けただけです。

実は結構使えるのでだまされたと思って使ってみてはいかが。

別ウインドウで開く

javascript:window.open("http://eow.alc.co.jp/"+prompt("look up word in SPACE ALC")+"/UTF-8/")

現在のウインドウで開く（使い勝手は良くない）

javascript:document.location.href = "http://eow.alc.co.jp/"+prompt("look up word in SPACE ALC")+"/UTF-8/"

O'REILLYどうした

　もともと翻訳どうよ、と思うものが多い出版社でしたが、
久々の出物、しかも大物、しかも２つ。

あまりに酷いので、ここで血祭りにあげようと思います。

プライムナンバーズ ―魅惑的で楽しい素数の事典 (O’Reilly math series)

数学を生み出す魔法のるつぼ ―実験数学への招待 (O’Reilly math series)

これはひどすぎる。読めたものではないとはまさにこれか。

分かりにくい日本語とか、そういうレベルではなく、
もはや日本語の体をなしていない文章だらけ。
誤植等も非常に多い。

久々に焚書目録に登録しました。

なお、非常に残念ですが、内容については触れることはできません。
５０ページくらいで読むのをやめてしまったので。
そのうち原書のほうを買います。

原著をなぶって遊ぶのはやめたらどうかと声を大にして言いたい。

....追記
プライムナンバーズを無理やり読んでみた。
普通に原書がほしい。

はじめてのMac

　時代の流れに負けてMac book Proを買った。

とりあえずキーボードの使い方がwindowsと違いすぎて困ったが、

GUIのとてもきれいなlinuxなんだという友人のアドバイスでバリバリ使えるようになった。

　もちろんコマンドラインでしか使ってない。どうしてこうなった。

Git使ってみる

　とりあえずMSysGitを入れ、TortoiseGitを入れる。

　リポジトリを作ろうとする。
→ MSysGitのPATH設定しろエラー
→ MSysGitのPATH設定する
→ メッセージがブランクのエラー
→ tgit.exeをgit.exeにリネーム
→ リポジトリ作れた。

TortoiseSVNと違って、まだまだこなれていない感じがしますねー。

Lightweight Language Tigerに行った

　用事があって大分後半からしか見られなかった。

見た中で、特に印象的だったのは、並列化とLT。

並列化について：
　話にあったとおり、時代はそっちに流れていくと思う。
　しかし、これまた話しにあったとおり、それに対応させるには困難を伴うと思う。
何しろとあるアルゴリズムを並列化しますよっていうんだけで、ひとつの論文になるくらいだし（もちろん非自明であれば）
　まあ、これまでの流れと同様に、あれもこれもライブラリになって、今と同様、ライブラリ組み合わせプログラミングになっていくんでしょうけど。

　でも、どうやってもシーケンシャルにしか解けない問題っていうのは残るので、ある意味でそこがコンピュータの最初の高い高い限界になるんでしょうね。
ずいぶんメニーコア、はやってますけど、コア数ではどうにもならない部分どうするのっていうのは、あんま聞かないすね。
研究分野ではきっと言われてるんでしょうけど。

　並列化時代にそこんとこうまくやるっていうのを考えるのも、悪くない気がします。
でも結局これまでの最適化系の話になってしまいそう。
その辺がソフトウェア屋さんの限界な気もします。

　ちなみに電力がコア周波数の2乗になるってのは知らなかった。自分、出自は電気電子系なのに。

LTについて：

　shibuya.jsのLTが本当にすごかった。
Javaをjsに変換して実行。すごく刺激を受けた。
なんか色々とやる気になった。

　改めてこれからはブラウザがOSの代わりになるんね、というのを確認した。
のだけど、コードが丸出しになっちゃうのが何とかならないと、
その手のビジネスはどうにもなんないんだろうなぁ。難読化なんてjsでは限界ありそうだし。
　しかしまあ、昔はあれほど嫌われ者だったjsちゃんが、
よくもまあここまでV字回復したものだと思う。
きっとこんな感じで、ホントは可能性に満ちているのに、
ユーザーがつかずに眠ってしまったものっていっぱいあるんだろうな。
Google Waveとかさ。

　逆に、その辺のマイナー技術を触ってみるという方向性も楽しそうだ。

　次回からは最初から参加しようと思った。
これで2000円は安い。一部しか聞かないなんてもったいない。

　あと来場者の方々が、会場でTwitterとか内職とかしすぎてて笑った。
これからもそんなフランクな会であってほしいと思った。初めて行ったけど。

4ヶ月ぶり

　お金がないので課金をやめてしまいました．ごめんなさいはてなさん．
　でもカウンターからページビューにダウングレードする際にカウンターがリセットされるのは切ないのですが何とかなりませんか．
別に僕しか回していなかったからいいのですが．

ちと最近バタバタしていて，大分しばらくバタバタする予定．
ライトなネタでも探してきましょうか．

機械学習のお勉強

　本当に今更ながら，ナイーブベイズをインプリしました．

　世の中の実アプリは猫も杓子もナイーブベイズ，
研究レベルのアプリは釈迦も達磨もSVMかCRF，これはちゃんと勉強しなきゃ．
勉強するにはインプリするのが一番の近道．というわけです．
（なんで実アプリは生成モデルで研究アプリは判別モデルなんだろう）

　結局勉強するために組んでいるにも関わらずgenericなコードへ無駄に拘り，
本質と関係ない部分に必要以上に時間がかかってしまいましたが，
そういうことをしなければ実装は無茶苦茶簡単で，
ストレートに組めば多分2時間くらいで組めちゃうんじゃないでしょうか．いや分かりませんけど．

　とはいえ，情報をネットで探してみると本当に大雑把な記述か，数式オンリーという二極化しており，
これ読めば何も考えず速攻でインプリできるぜ，というようなものが僕には見つけられませんでした．
微妙に断片的な情報ばかりで，
「え，これどうすりゃいいんだ？」
と色々と躓くこともあり，結局元論文へ…みたいな感じで，
自分の頭の悪さにホトホト嫌気が差した次第です．

　はてさてさて，出来上がったナイーブベイズのコードはgenericを追求しすぎた余り
巨大で複雑怪奇になってしまったので，ここに貼り付けることはできません．
ですがせっかく勉強したので，少しでもそれをアウトプットしたいぞ．

というわけで，今度，「これ読めば速攻でインプリできるぜ」というような文章を書いてみようかと思います．