JavaScript Patterns 2章ではevalの代替としてFunctionコンストラクタを使う方法が紹介されています。Functionコンストラクタは、普通にJavaScriptを書いている分にはなかなか使うことがないので、馴染みがない人も多いだろうと思います。そこで関数式との比較を中心に簡単にまとめておきます。

Functionコンストラクタは、関数オブジェクト（つまりJavaScriptにおける関数）を作るためのコンストラクタです。文字列をJavaScriptコードとして扱えるという点ではevalにも似ていますが、戻り値は普通の関数なので、その他の方法で作った関数と全く同じ使い方ができます。

var funcObj = new Function('x', 'y', 'console.log(x + y);');
 
//普通に呼び出す
funcObj(1,2); // 3
 
//コンストラクタとして使ってみる
funcObj.prototype.hello = function(){ console.log('World'); };
(new funcObj(4,5)).hello(); // 'World'

ちなみにコンストラクタではなく関数として呼び出した場合は、コンストラクタとして呼び出した場合と同じ結果になります（仕様上そう規定されています）。よって以下の2つは同じ意味になります。

var funcObj1 = Function('x', 'y', 'console.log(x + y);'),
    funcObj2 = new Function('x', 'y', 'console.log(x + y);');

この形、関数式にnew演算子を適用した場合と見た目が似ていますが、全く意味が違うということに注意してください。

// 関数式で関数を作る
var funcObj = function(){}
 
// 関数式で作った関数をコンストラクタとして呼び出す
var newlyCreatedObject = new function(){};

varの解釈について

Functionコンストラクタで作った関数においても、関数本体の中でvarステートメントを使って宣言した変数はローカル変数になります。

var a = 100,
    func1 = new Function('var b = 200; return b;'),
    func2 = function(){ var c = 300; return c; };
 
console.log(a); // 100
console.log(func1()); // 200
console.log(func2()); // 300
 
console.log(typeof b); //undefined
console.log(typeof c); //undefined

変数の生成（instantiation）は関数が呼び出されたときに実行されるプロセスなので、どのような方法で作った関数でも同じです。

スコープについて

関数式で作った関数は、関数式の外側のローカル変数を参照できます。しかしFunctionコンストラクタで作った関数はグローバル変数しか参照することができません。

//JavaScript Patterns Chapter2の例の改変
(function(){
    var local = 1;
    (function(){ local = 3; console.log(local); }()); // 3
    console.log(local); // 3
}());
 
(function(){
    var local = 1;
    Function("console.log(typeof local)")(); //undefined
}());

言い換えると、関数式で作った関数オブジェクトが「関数式が評価された時点でのスコープの状態」を保持しているのに対し、Functionコンストラクタで作った関数オブジェクトは常にグローバルなスコープしか保持していません。なぜこの差が生じるかというと、単に仕様でそう決まっているからです。関数に保持されるスコープは関数が作られたときに決定されるので、関数をどこでどのように作ったかによって結果が変わるということです。そして一度作られたあとは変更されることはありません。

この理屈によって、関数式ではクロージャを作ることができるが、Functionコンストラクタでは作ることができない、ということになります。

全くの余談ですが、クロージャが”閉じる”のは、スコープチェーンに組み込まれたActivation Objectがプログラマからは操作不可能だから、という事情によります。よってその他のオブジェクトをスコープチェーンに組み込んでやれば、クロージャと似ているが”開いた”関数を作り出すこともできます（役に立つかどうかは不明ですが）。

var func,
    scope = {alert: function(msg){ console.log(msg); }};
 
//スコープチェーンの中にオブジェクトを組み込む
with(scope) {
    func = function(x, y) { alert(x + y); };
}
 
//グローバルのalertは隠蔽されてconsole.logが実行される
func(1, 2);
 
//scopeのプロパティを削除することでグローバルなalertが実行されるようになる
delete scope.alert;
func(3, 4);
 
//再びalertを隠蔽する
scope.alert = function(){};
func(5, 6);

ECMAScript5の用語で言うと、Declarative Environment Recordに関数外部から束縛を追加したり削除したりはできないが、Object Environment Recordならbinding objectを通してそれが可能だということです。

参照

仕様書の中で関連する部分は多岐にわたるため、一部のみを挙げておきます。

• 15.3 Function Objects – Standard ECMA-262 3rd/5th
• 13 Function Definition – Standard ECMA-262 3rd/5th

またこの記事はazuさんのJavaScript Patterns読書記録を踏まえて書かれました。

• Chapter 2. Essentials – prog*sig

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ)

すごく良い本なんですが、どうしても気になってしまったので、この部分だけ先に書きます。297ページ、17.2『関係モデルからの導出』で示されている郵便番号の関係モデルは変だと思います。ER図は次のようになっています：

「郵便番号データのER図」、『Webを支える技術』298ページより

これのどこが変かというと……要するに正規化が不十分なので、いろいろなところが変です。

• 郵便番号エンティティが都道府県エンティティと市区町村エンティティを別々に参照しているので、「東京都のIDと大阪市のIDをもつ郵便番号」のようなものが作れてしまいます。
• 市区町村エンティティが都道府県エンティティに依存していないので、「どの都道府県にも属さない市区町村」が作れてしまいます。
• 町域エンティティが郵便番号エンティティに入り込んでいます（町域名フリガナは町域名に関数従属する）
  • 町域と都道府県-市区町村の関係が保証されていないので、「東京都のIDと大阪市のIDと愛知県の町域名」みたいなものが作れてしまいます。

実装のことはさておき、純粋にデータの数的な関係に着目するなら、モデルは次のようになるのではないかと思います。

郵便番号データのER図・作図例

（モデルの”意味”を明確に示すために、あえて数値のIDではなく都道府県名や郵便番号などをそのままPRIMARY KEYとしています。また町域と郵便番号の関係などは日本郵便のサイトを参考にしています）

『Webを支える技術』300ページでは「階層構造は関係モデルからはわかりにくい」とありますが、それは誤解だと思います。普通は正規化を進めれば進めるほどエンティティの階層は深くなっていくはずです。市区町村->町域という階層も上のモデルからは自明です。むしろいかに階層を（正規化を）崩してリソースを抽出するかのほうが難しいと思います。

私はモデリングの専門家ではありませんので、勘違いしている点があったら教えてください。

『まぐれ―投資家はなぜ、運を実力と勘違いするのか』の感想。

著者は『ブラック・スワン』のナシーム・ニコラス・タレブ氏。この本は『ブラック・スワン』の一つ前にあたる著作。

日本語の副題「投資家はなぜ、運を実力と勘違いするのか」が的確に内容を要約している。哲学やら社会学やら心理学やら、かなり幅広い話題を扱っているが、結局のところ「市場においてトレーダーはどう振る舞うべきか」というテーマが中心にあって、トレーダーとしての自身の経験と運用哲学が根底にある。非合理的な振る舞いを繰り返す同僚たちをバカだアホだとこき下ろしながらも、実はその一部は自分自身のことで、人間はどうやっても合理的になりきれないと告白する。自分が愚かであることを理解し、受け入れた上で、うまく向き合っていく方法を身につけるしかないのだと。

この本は著者がそういう自分のやり方に、自分で納得するために書いているのではないか、と思える部分がある。結構ドギツイ文章を書く人で、読んでいてうんざりしてしまうことも多かったが（特に前半）、実際はとても正直な人なのだろう。

以下、特に印象に残った内容を6章以降から。この本は6章から俄然面白くなるので、6章までは頑張って読み進めることをお勧めする。

• 「確率」と「期待値」を混同してはいけない。0.7の確率で1%の上昇、0.3の確率で10%下落なら、期待値は2.3%の下落だから下落にかけた方が良い。勝つ可能性が高くても、それで儲かるとは限らない。
• 確率と期待値を混同してしまう原因の一つは、確率を習うときにコインの裏表のような対称な分布を使うから。正規分布も典型的に対称な分布。
• 稀な事象は、めったに起こらないというだけで、起こるときには起こる。そしていつも思いがけないときに起こるので（そうでなければ稀な事象ではない）、起こったときには心理的なバイアスによって適正な値段がつかないことが多い。よって大きく儲けるチャンスがある。
• 人間は刺激の大きさよりも刺激の有無に敏感な傾向がある。だからトータルで利益が出るかどうかではなく、「損失の回数が少なく、利益の回数が多い」ような戦略を選んでしまう（日本で毎月分配型の投資信託が好まれる理由？）
• ある理論が「検証可能」であるということは、数量的な要素に分解して統計的に調べることができるということ。よって間違っていると証明すること（反証）はできるが、正しいと証明することはできない。「（今まで）〜ということはなかった」は「（これからも）〜ことはない」とイコールではない。
• 科学的と言える理論は2種類しかない。(1).反証されて、間違いであることが分かっている理論。(2).まだ反証されていないが、いずれ反証される可能性のある理論。反証できない理論は科学ではない。
• 取引戦略を立てる時も反証可能性について考えることは重要。どういう状況になったら自分の戦略が間違っていたことになるのかをはっきりさせておき、そうなったときには即座に手仕舞う（ストップロス）。

そして個人的にこの本の中で最も面白いと思ったのは、無限匹のサルがタイプライタを叩く話（170ページ）。サルが無限匹いれば、中には偶然に名作を書き上げてしまう奴が必ず一匹は現れる。ここまでは割とよく聞く例え話だ。しかしここからが面白い：名作を書き上げたその一匹があなたのもとを訪れて、自分で書き上げたその「過去の実績」を示し、パトロンになってくれと頼んできたらどうだろう！そのサルがその名作を書き上げたのは紛れもない事実なのだ。そしてその他大勢のサルたちは皆（特に目立った成果を挙げられなかったのだから当然）どこかに行ってしまった。あなたの目の前にいるのは”奇跡のサル”だけだ……。

どんなに無能な集団でも、母集団が十分大きければ、必ず一定数は成功する。成功しなかった大多数は消えてしまうので、あとから見ると成功した一部しか目に入らない（これを生存バイアスという）。よって「過去にどれだけの実績を上げてきたか」が分かっても意味がない。当初その人が属していた母集団の大きさをこそ知らなければいけない。

ヤバい経済学 [増補改訂版]の感想。

科学としての経済学

経済学は計測の学問だと言う。それは経済学が”科学”であるための方法なのだろうと思う。

自然科学において仮説を検証するには実験を行う。狙った現象が観測可能になるようなうまい状況を整えて、仮説に整合的な結果が生じるかどうか調べる。しかし経済学の対象は現実そのものなので、仮説を検証するための実験を行うことは難しい。代わりに現実の中で得られた膨大なデータに統計学的な分析を加えて、ある現象の原因と結果がうまい具合に立ち現れるよう工夫する。

そういう意味で、経済学におけるあらゆる種類の実験は、あらゆる条件下で常時行われていると言えるかもしれない。

インセンティブは発明されたものである

インセンティブとは「発明」されるものだと言う。もっと稼ぎたいからがんばって働く、警察に捕まるのが怖いから不正はしない。現代社会では当然のことと考えてしまいがちだが、これらは普遍的な原理でも何でもなく、そういう風に行動するようにインセンティブが設計されているのだ。ここで私はおれカネゴンさんの日記の次の箇所を思い出した：

ところで、「よいことをするとよい報いがある」「悪いことをするとそれなりの報いがある」という因果は、実はまったくの非合理的な信念 (irrational belief)で、この因果は合理的なのだ(筋が通っている)とすべての人によって信じられているということ以外にこれを支える根拠は本来どこにもなかったりする。かといって、論理療法とかを真似て、にわかハッカーのように「これは非合理的です」と斬って捨てたままにしていいことにはならない。というのは、人類は数千年かけて、本来は非合理的であるはずのこの信念が本当になるように全力を尽くしてきたからで、その最たるものが法律なのだと思う。

法律はインセンティブを導入するための強力な手段の一つだ。そして経済学者は、インセンティブを発明したり設計したり導入したりすることで、あらゆる問題は解決できると考える（らしい）。

『割れ窓理論』という通念

150ページからは有名な「割れ窓理論」をもとにしたニューヨーク市の防犯対策と、実はそれは全く効果がなかったという著者の主張が述べられている。主張の根拠は次の3点にまとめられる：

1. 犯罪の急減はニューヨーク市にけではなく、全米で起こっていた。
2. 対策が始まったのは1994年からだが、1990年には既に減少が始まっていた。
3. 対策の内容とは無関係に、警官が増員されていた（警官が増えれば犯罪が減ることは証明できる）。

これだけの証拠があったのに、なぜ割れ窓理論に元づく説明が広く世間に受け入れられ、「通念（conventional wisdom）」となったのか。『通念は、単純で都合がよくて居心地良さそうで、実際居心地がよくなければならない』と著者は言う。確かに、割れ窓理論が提示する筋書きは心地よい。身近なところで起こる軽微な犯罪を徹底的に取り除いていけば、やがて街から犯罪の臭いが消え、殺人や強盗といった重大な犯罪も減少する……。警察が、街のみんなが頑張ったから犯罪は減ったのだ！というのは、ぜひとも信じたくなる考え方だ。

…

「銃とプール、危ないのはどちらか」、「ヤクの売人はなぜママと住んでいるのか」、「黒人と白人の成績格差は何が原因か」といった本書の話題の多くは、基本的に米国人の通念を前提としており、日本人が読んでも「ふーん」という以上の感想を持つのは難しい。例えばアメリカでは近年、子供に変な名前をつける親が増えているらしい。日本でも同じような話は聞く。しかしそこから親の傾向とか子供の成績との相関を調べたら、アメリカとは全く別の結論になるのではないかという気がする。

世界一シンプルな経済入門 経済は損得で理解しろ! 日頃の疑問からデフレまでの感想。

飯田泰之先生の経済入門本。発売がなぜかエンターブレインだったり、帯にでかでかと勝間和代さんの写真が載っていたり、外観は良く分からないことになっているが、内容はとてもとても分かりやすかった。

主に3章以降から、特に印象に残った部分をメモ。

• 不況には2種類あり、また2種類しかない。すなわちスタグフレーションか需要不足型不況である。
• 経済政策には成長政策、安定化政策、再配分政策の3種類があり、それぞれ目的も効果も異なる。間違った状況で間違った政策をとると効果が出ない
• 60〜70年代の世界はスタグフレーションに陥っており、「成長政策」こそが必要だったが、「安定化政策」をとってしまった。また90年代以降の日本は需要不足型不況で「安定化政策」が必要なのだが、「成長政策」をとってしまった（小泉改革）。
• 成長政策は中長期的な潜在GDPの上昇に効果がある。代表的な政策は「民営化」と「規制緩和」。
• 安定化政策は潜在GDPと実質GDPを安定的に一致させる。経済の安定は中長期的な潜在GDPの上昇にも欠かせない。代表的な政策は「財政政策（公共事業/給付金）」、「金融緩和政策」
• 再配分政策が必要なのは、セーフティネットを整備して成長のための挑戦をしやすくするため。過剰に再配分をやると逆効果。
• 2002年から2007年までの「いざなぎ超え」は、それだけの期間回復基調が続いたというだけで、需給ギャップはほとんど埋まっていなかった。成長率そのものも低く、結局のところ需要不足型不況が続いていた。
• デフレ下では名目金利がどれだけ低くても、実質金利=名目金利-予想インフレ率は高くなり、企業の投資活動は萎縮する。
• ミクロの視点では正しくとも、それが合成されたマクロの世界では正しくなくなることを「合成の誤謬」という。デフレ下の個人個人の選択は合理的なので責めようがないが、最終的には自分たちの首を絞めることになる。
• 税収の増加率≒名目GDP成長率＜国債の名目利子率　が成り立っている限り、どれだけ無駄を省いたとしても、必ず財政は破綻する。

Amazonのレビューにも書いてあるが、一部で図が間違っている。あと誤植が割と多い。そこだけが気になった。

タイトルはちょっとアレだが、至極真っ当な本。インデックス連動型の海外ETFを買って、世界経済の成長に参加しよう！というお話。敢えて一文、本書の肝となる主張を抜き出すとしたら、次の文だろうか（258ページ）：

長期的にみて、世界経済が発展する限り、市場は全体として右肩上がりになります。

この理屈が理解できなかったせいで、私にとって長らく投資という行為は胡散臭い儲け話と区別がつかなかった。いや、多分今でも心の底では理解できていないと思う。失われた10年に青春を過ごした私（たちの世代）にとって、世の中というのは「短期的な上下を繰り返しながらも、緩やかに下降していく」ものだという認識が染みついているので、株価であれ、何らかの指数であれ、投資信託の基準価格であれ、中長期的に右肩上がりに上昇し続けるというのは、鼻で笑ってしまうような馬鹿げた幻想にしか思えないのだ。……むしろそういう世界観を相対化してみたくて、今の私は投資を行っているのかも知れない。

それで海外ETFだが、実際に買おうと思うと、やはり普通の投資信託よりもいろいろと敷居が高くて躊躇している。特に面倒なのが税金。海外ETFは海外株式と同じ扱いになるため、手数料の安いネット証券では特定口座が利用できない。ならば自分で確定申告を、と考えて調べてみると、これがよく分からない。売買差益が譲渡所得で申告分離課税、為替差益が雑所得で総合課税という基本は簡単なのだが、ここで日本円を米ドルに換えて、ここで○○ドルでETFを買って、ここで××ドル分を売却したとして……というリアルなシナリオに沿って考えていくと、いつどのレートでどういう所得が発生するのか、頭がこんがらがってくる。

他にも、これは本にも書いてあることだが、ETFは最低取引金額がまだ高いし、購入する際の手数料もかかるので、小額ずつ積み立てて行くのには向いていない。やはり当面は普通の投資信託で積み立てていくのが簡単そうだ。本書執筆時点では存在していなかったMSCI エマージング・マーケット・インデックスに連動するインデックスファンドも登場したことだし……。

11章途中まで読んだ。

他言語のプログラマに向けたLisp本。リストがどうしたコンスセルがどうしたという定番の説明をすっ飛ばして、とにかくまずはCommon Lispの凄さを見ろと言わんばかりに、最短距離でマクロの実演に突き進む。その姿勢は正しいと思う。ある程度経験のあるプログラマならリストやコンスセルの基礎くらいは知っているものだし、その上で「Lispって、結局何がどう凄いのかよくワカンネ」という人がこの本のターゲットだろう。

実際途中まで読んだだけでも、マクロの凄さはひしひしと伝わってくる。他言語での経験を振り返って、果たしてプログラムを書くということはどういうことだっただろうかと、改めて考え直してしまうくらい示唆に富んだ内容を含んでいる……。

ところでマクロのイディオムとして、次のように処理の”本体”となるコードを埋め込む形が多用されている。

(defmacro foo (a b &body body)
    `(bar (baz ,@body))

これはRubyのブロックによく似ている。一般にRubyのブロックは無名関数に対するシンタックスシュガーと見なされることが多いのだが、むしろLispのマクロを意識した部分も大きいのかも知れない。

…検索してみるとやはりLispのマクロとRubyのブロックを比較する視点は存在するようだ。Ruby作者のまつもとさん自身も取り上げている：

• [Ruby] Why Ruby is an acceptable LISP – Matzにっき
• まつもと直伝　プログラミングのオキテ 第0回　あらためてRuby入門（基本と他言語との違い）

少しずつだが『実践Common Lisp』を読み始めた。3章の where の例で早くも感動。Lispのマクロはとにかく凄いのだと、著者がくどいくらいに主張する理由が分かってきた。確かにこれは凄い。

練習のために update のマクロ版も書いてみた。後の章で出てくるのかも知れないが。

(defun make-update-expr (field value)
  `(setf (getf cd ,field) ,value))
 
(defmacro update (selector-fn &rest clauses)
  `(setf *db*
	 (mapcar
	  #'(lambda (cd)
	      (when (funcall ,selector-fn cd)
		,@(make-expr-list #'make-update-expr clauses))
	      cd)
	  *db*)))

make-expr-list は make-comparison-list を一般化したもので、次の通り。

(defun make-expr-list (make-expr-fn fields)
  (loop while fields
       collecting (funcall make-expr-fn (pop fields) (pop fields))))

Authenticated encryption：機密性と完全性を同時に守るための暗号システム。対称暗号とMACとの組み合わせで実現するか、もしくは専用に設計された対称ブロック暗号のモードを使用する。最近になって活発に研究されている分野らしい。

そのような対称ブロック暗号のモードは Authenticated Encryption Modes といった名称で分類され、中でもNISTが標準化しているのは CCM と GCM モード。CCM モードは IEEE 802.11i 規格の一部として実用化されている。また他にNISTに提案されているものとしては CWC, EAX, OCB モードなどがある。

一般に使用可能な実装としては、Brian Gladman氏のサイトで CCM, GCM, EAX, CWC モードの実装がBSDライクなライセンスで公開されている。またパブリックドメインの暗号化ライブラリ libTomCrypt（工事中の新サイト） では EAX, OCB, CCM, GCM モードが利用できる。

『C/C++セキュアプログラミングクックブック〈VOLUME2〉対称鍵暗号の実装』でイチ押しされているのは CWC モードだが、世間的にはNIST標準である CCM モードや GCM モードの方が広く使われているようだ。

比較的新しい分野のためか、WEB上には日本語の情報は少ない（探し方が悪いのかも）。唯一CRYPTREC が2003年に公開した報告書（pdf）『ブロック暗号を使った秘匿、メッセージ認証、及び認証暗号を目的とした利用モードの技術調査報告』の中で「認証暗号に関するモード」として安全性や効率について詳しい検討を行っているが、ちょっと専門的過ぎる。一方でWikipedia英語版の充実振りは素晴らしい。

GWなので欲しかった本をまとめ買いしてきた。

『WEB+DB PRESS vol.50』
だいたい読み終えた。Gitの記事とkey-value storeの記事が面白かった。Gitは内部の構造まで理解しないと使いこなすのが難しい。Subversion とは対照的。でも総合的な使い勝手ではやっぱりGitの方が上だと思う。

Subversion が提示する世界観は分かりやすい。リポジトリ全体は「ディレクトリツリー」なのだという比喩が中心にあって、そのツリーに対する更新やらコピーやらの操作が、各種バージョン管理の操作に対応するようインターフェイスが工夫されている。オブジェクト指向的とも言えるかも知れない。一方Gitは機能指向的というか、まず自分が何をすべきなのか、どのような操作を実行すべきなのか理解した上で、対応するコマンド（とコマンドラインオプション）を選ばなければいけない。操作対象の抽象度も低く、あくまでもプログラマ向けという匂いが強い。そして実際、プログラマなら（慣れれば）Gitの方が使いやすい。

一見「分かりやすい」比喩を用意したとしても上手くいくとは限らないということか、単に比喩の妥当性の問題なのか。いろいろ考えさせられる。

『C/C++セキュアプログラミングクックブック』
前々から買おうかどうか迷っていた本。熟慮の末volume 2と3を買った。立ち読みした限りではそこまでハードなC言語の知識は要求していないっぽい。ギリギリ「コードが読める」レベルの私でもなんとかなりそう。

まだvolume 2を読み始めたばかりだが、まさに私が求めていた本、かもしれない。暗号化周りは実際にコードを書こうとすると分からなくなることが多すぎる。「IVって公開して良いの？」とか「『鍵』ってパスワードみたいにコード中に直接書いておけば良いの？」とか「ソルトってどうやって作って管理すれば良いの？」とか。自力で一つ一つ理屈を積み重ねて判断していくのは辛過ぎる…。しかもこの分野ほど”素人の直感”が裏目に出やすい分野はない。

本文中では「一般人は生の暗号化操作をするな。信頼できる高水準のインターフェイスを使え」と繰り返されている。Ruby やら PHP やらの階層でごにょごにょやるより、既存のC実装へのインターフェイスを作った方が良いのかも知れない（私にそのスキルがあればの話だが）。

以下はまだほとんど手付かず。