（このエントリーは「Javascriptクイズ：無名関数と実行効率の話」の続編。） 「？？？」と頭をかしげる太郎に、「じゃあ、これだったらどうかな？」と三郎はコードを書き始めます。 function code2name(code) { var mapping = { 'us': 'United States', 'ja': 'Japan', 'ko': 'Korea', 'ru': 'Russa', 'uk': 'United Kingdom', 'fr': 'France', 'cc': 'China', 'gw': 'Germany' }; return mapping[code] || '(unknown)'; } 「カントリーコードを国名に変換しているんですね。」と太郎。 「どこが問題だか分かる？」 「うーん、マッピングのためのオブジェクトを毎回作り直しているところかな。」 「そう

Apparently, it is a fake. But you just have to think how much effort has been put to make this trailer. Impressive!

Javascriptを使い始めたばかりの太郎君に、上司の花子さんから「スタイルシート用のスタイル名をDOMからアクセス可能なプロパティ名に変更するJavascriptのライブラリを作って欲しい」という課題が与えられました。何のことか分からずにポカンとしている太郎君に、花子さんは「"font-style" を"fontStyle"に変更する関数を作ればいいのよ」と言い残して立ち去ってしまいます。 O'ReillyのJavascript本としばらく格闘した太郎君は、やっとライブラリを完成させます。 function capitalize(str) { return str.charAt(1).toUpperCase(); } function style2prop(str) { return str.replace(/-[a-z]/g, capitalize); } "font-style"が

先日公開した、iPhone/iPod touch用アニメーション・ライブラリ「ianime.js」、夕食を食べながらもっと早くできそうなアイデアが浮かんだのでちょっとトライ。これが思い通りの効果を出して、５０個のアイコンを特別な効果なしに動かした時のフレームレートを11fpsから15fpsに改善。 iPhone/iPod touchのJavascriptの実行があまりに遅いので、ちょっとでも余計な条件判定やファンクションコールが入るだけで格段に遅くなる。そこを上手に避けながら、かつさまざまなオプション機能を提供する、というのはなかなか難しい。 ちなみに今回のデモは、アイコンの落ちるスピードに少し変化を持たせたベンチマーク。これだとその変化の分だけ遅くなり14fpsほどだが、ちょっとした落ちゲー（「さめがめ」とか「bejewlled」）の効果には十分。「連鎖」だってこなせる^^。 http:

ということでやっとRubyの勉強を始めた私だが、「何かを学ぶには人に教えるのが一番」というポリシーの私としては、早速Rubyに関するエントリーを書かずにはいられない。 Rubyという言語に関しては色々な意見があるとは思うが、私が（いまのところ）一番気に入っているのはイテレータという考え方。これは美しい。できることならば、forとかwhileのない言語にしてくれればもっと美しかったのにと思うぐらいだ。ここからしばらくは、forとwhileを一切使わずにどこまで出来るかを試してみようと思う。 そう思いながら読み始めた「オブジェクト指向スクリプト言語Ruby(以下「Ruby本」)」。Rubyの生みの親であるまつもとゆきひろ氏自身の手になるものだ。彼なりのイテレータへの思い入れが伝わってくるに違いない... ところが、である。 この本の最初の方に出てくるサンプルがなぜかイテレータを使わずにwhil

年配の人が「最近の若者の言葉はめちゃくちゃだ」と言うのは、言葉が進化しているから。誤用する人が増えて来て、多くの人に通じるようになれば、りっぱな日本語だ。その過程で年配の人が「わかもの言葉」に違和感を持つのは当然。そんな「新しい日本語」を発掘してみるというのも楽しそうなので、一つ実験をしてみる。 下の６つの文を、あまり深く考えずにさらっと読んで欲しい。そして違和感を感じたかどうかをコメント欄なり、ブックマークコメントでいただきたい。「最初に読んだ時は違和感を感じなかったけど、もう一度読み直してみたらどれが変なのか気がついた」、「どれに問題があるかは言われれば分かるけど、別に通じるからいいじゃん」、「普通に使ってたけど、これって間違ってたの？」という返事もOK。 ・そこの公園で子供が遊んでいる ・そこのクラブで彼女が踊っている ・そこのコンビニでおでんが売っている ・そこの畑でキュウリがなっ

404 Blog Not Found の「LiveCoding に学ぶプログラミングの三原則」を読んでいたらどうしても書きたくなったので。あくまで私のスタイルなので、参考にするもしないもご自由に。 1. スタードダッシュでできるだけはやくめどをつける 学生時代から夏休みの宿題は７月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、本当は大幅な設計変更をすべきなのに応急処置で

Google AnalyticsのUIが大幅に改良されたので、解析結果を見なおしていたのだが、そこで気が付いたのが、見覚えのない"petals around rose"というキーワードで来る人がたくさんいること。私にはなじみのない言葉だったので調べてみると、以前のエントリーのコメント欄にこのパズルのことが書かれており、それが検索エンジンに引っかかっているようである。 実際のパズルも見つけて遊んでみたが、なかなか手ごわい。Total Roll=10あたりでやっと法則を発見し、Total Roll=14で"Correct again! We think you've got probably got it"と褒めてもらえた。パズルの場所は、 Play Petals Around the Rose だ。このサイトによると、ビル・ゲイツもかなり苦戦したらしい（参照）。 ちなみに、説明が英語なので日

昨日のエントリーで、「人は一つの仕事を処理するときには、それを小さな仕事に分割して、順番に処理する」と書いたが、「パンを焼く」という仕事を例に取れば、こんな風になる。 １．イーストを３０℃のお湯と一つまみの砂糖とまぜて１５分間予備発酵させる ２．ボールに強力粉、予備発酵させたイースト、砂糖、塩を入れて良く混ぜる ３．こね板の上で生地をこねる ４．ボールにラップをして室温で１時間発酵させる（一次発酵） ５．適当な大きさに生地を分割し、丸めて形を作る ６．オーブンに入れ、３０分発酵させる（二次発酵） ７．オーブンの温度を２００度にして１８分焼く これは、ソフトウェアで言えば「手続き型のプログラム」であり、人間が一連の作業を把握するのに最も適した記述の仕方である（その証拠に、実際のどのレシピブックを見ても、レシピは必ず「手続き型」で書かれている）。 興味深いのは、このレシピにおける、「１５分予備

UIEngineの説明をする際に、「通常のウェブ・アプリケーションと異なり、非同期通信を使ってクライアント側でデータ・バインディングをするので、ストレスの少ないユーザー・エクスペリエンスを提供できます」と言ってきた私だが、「データ・バインディングとは何か」を知らない人が意外に多いことに気がついたので、ここで解説しておく。 得意の食べ物にたとえれば、データ・バインディングは「調理」に相当する。定食屋のように全ての食材（データ）をキッチンで調理をしてしまってから一度に持ってくるのが「サーバー・サイドでのデータ・バインディング」で、紅花レストランのように食材をテーブルまで持って来て目の前で調理してくれるのが「クライアント・サイドでのデータ・バインディング」である。 食材を一度にはテーブルに運ばず、客が一つ目の料理を食べている間に二つ目の料理の食材を運んで料理をしておき、一つ目の料理を食べ終わった

今回のみずほ証券による株の誤注文事件は、１株を６１万円で売るところを、オペレーターが誤って「６１万株を１円で」と誤入力してしまったのが原因だが、その際に端末には市場価格との隔たりを示す警告が表示されたにもかかわらず、オペレーターが「（警告が）よく出るので慣れの中で結果的に無視してしまった」という点が注目に値する。 以前にも、「事故防止の難しさ」というエントリーで触れたことがあるが、「不必要な警告をしょっちゅう見ているとそれに慣れてしまい、本当に対応が必要な時にも無視してしまう」というのは人間の性である。この手のミスをした人を一方的に非難したり、「これはヒューマン・エラーでした、今後はこのようなことを繰り返さないように注意します」と謝るのは簡単だが、それでは根本的な事故防止はできない。 「不要な警告」と言えば、パソコンがその代表選手。ファイルを消去した時の「本当に消去したいですか？」という警

根っからの理科系人間の私が、何を間違ったかベンチャーキャピタル（ベンチャー企業を対象とした投資会社）にパートナーとして参加したり、米国で起業したりするものだから、否応なしに金融だとか経済のことを勉強するハメになった。幸いなことに、最近の経済学は統計学などを駆使した数理経済学となっているため、数字に強い理科系人間であることが大いに役立っている（ちなみに、日本の大学の経済学部は相変わらず「文科系」扱いで入試に数学が必要ないために、数理経済が理解できない学生が沢山いるっていう噂は本当なのだろうか？）。 そんな私の数年前からの疑問は、「米国が毎年莫大な貿易赤字を出しているのに、なぜドルの値段はどんどん下がっていかないのか？」である。「それは日本が米国の国債を買ってあげているからだよ（日銀の米債買い支え説）」、「アメリカ政府はドル紙幣をどんどん印刷しているからだよ（ドル紙幣印刷説）」、「アメリカ人は

他の夫婦にもあるとは思うが、私と妻の間には二人にしか通じない「言い回し」が幾つかある。どれも、ある特定の考え方とか行動を一言で表すものなのだで、とても便利に使っているのだが、一つ問題がある。せっかく便利なものなのに、他の人との会話で使えないのだ。たまに「この場面で使えれば便利なのに」と喉まで出かかるのだが、いつもグッと押えている。 そこで思いついたのだが、このブログを使って、そういった「言い回し」を広めて日本語の一部にしてしまえば良いのだ。「現代用語の基礎知識」に載せるのは難しいとしても、少なくとも私の知り合いには広めることが出来るかもしれない。 記念すべき第一弾は、『床屋の満足』である。これは、「本来顧客の満足を最優先すべき商売もしくはもの作りをしている人が、自分の満足を優先して行動してしまうこと」を意味する。語源は、筆者の名前は忘れてしまったが、大昔に読んだエッセイである。そのエッセイ

「自分にできるだけ相応（ふさわ）しいパートナー」を見つけることは、我々人間にとって、人生の最も重要なのテーマの一つでもある。しかし、そのプロセスである「恋愛」や「お見合い」に関して、なぜか今までシステマティックな考察がされて来なかったように思える。そこで、今回はその「パートナー探し」のプロセスをモデル化・数値化することにより、最適なアルゴリズムを見つけようと思う。 まずは、「自分にできるだけ相応しいパートナーを探す」というあいまいな問題を、もう少し明確にモデル化された問題に単純化する。もちろん、単純化するとはいえ、あまり現実とかけ離れていては役に立たないので、現実味を壊さない程度の単純化を行う。 ［モデル化された問題］ 結婚適齢期の女性が、これから１０人の男性と順番にお見合いをして、その中から結婚相手を見つけることにしたとする。相手の意思は無視して良く、「この人と結婚したい」と宣言した時点

最近、「これからのウェブ・アプリケーションはAjaxだ」という声を良く聞く。ソフトウェアを生業としているエンジニアとしては、この手の「流行もの（hype）」に触れた時には、表面的なものに踊らされずに、その本質を自分なりにしっかりと捕らえて消化・吸収して自分のものにしなければいけない。今までも、「オブジェクト指向」、「マルチ・ティアー・アーキテクチャー」、などの言葉が一人歩きするたびに、「これからは○○だ」とか「○○の時代は終わった」などと、過激なことを言って読者の目を引こうとだけするマスコミや企業のマーケティング戦略に数多くの人が踊らされてきた。 そんなノイズだらけのメッセージに混乱させられた結果、「Ｃではオブジェクト指向のプログラミングは出来ない」と信じているエンジニアがいまだに沢山いることは全く嘆かわしいことだ。「オブジェクト指向のプログラミング」は、設計姿勢・プログラミングスタイルに