Tweet

実践JS サーバサイド JavaScript 入門がアマゾンのJavaScript部門の売上トップなので記念のスクリーンショットです。

アマゾンに表紙も目次もまだ載っていないのに誰が買ってくれているのでしょう。ありがたいことですが。

ちなみに、書名は当初「実践サーバサイドJavaScript」の予定でしたが「実践JS サーバサイド JavaScript 入門」になりました。アマゾンのページにまだ表紙の画像がありませんが、ぼくもまだ見ていません。実物を受け取ってはじめて見ることになりそうです。

そもそも本の装丁に興味がありません。タイトルも表紙も編集にお任せです。京極夏彦にはなれそうにありません。

パーフェクトJavaの時は、永井さんが本文のフォント含め装丁に注文をつけていましたが、今回は著者が自分ひとりなので完全に出版社任せです。自己弁護ですが装丁はプロに任せればいいと思っています。ソフトウェアに例えればモデルとビューの分離です。ぼくは本の見栄えに関する部分は一切気にせず内容だけに集中しました。

来週か再来週あたり実物を受けとるので、そうしたら目次などをありえるえりあで紹介します。少しだけスニークプレビュー的にネタをばらすと、CouchDBとMongoDBの章があります。これらはJavaScriptエンジンを積んでいるので別におかしくはないのですが、なぜかGoogle App Engine for Javaネタも載せています。まるでNoSQL本みたいですが、正統なNoSQL本ではありません。

関連文書:

• 関連文書は見つからんがな

Tweet

 この本は、行動経済学の権威であるダン・アリエリーによって、行動経済学のなんたるかを、いくつかの事例を用いて紹介をしている。

 本書で紹介されている行動経済学の概説について。いくつかの実例を含めたダン・アリエリー氏本人によるプレゼン動画が youtube に上がっている。

http://www.youtube.com/watch?v=JhjUJTw2i1M

 おおまかに言うと。
 （経済学の観点から見ると）我々は経済活動やそれに類する活動を行う際、経済合理性に則ったある種の費用便益分析を行い、論理的に判断し行動すると考えられている。
 だけど（行動経済学の観点から見ると）実はそんなの嘘っぱちで、全然合理的じゃない行動をたまにするという。それも、誤差やエラーといって履き捨てる事の出来ない規模で。更に面白いのが、これら非合理的な行動が、ある規則性を持っていると言う。

 前者は、何か基本となる原理・原則を定義して、そこから諸処の数学的（機械的）な技法を用いて妄想を膨らせて数々の定理（コンポーネント／モジュール）を編み出す、計算機科学的な考え方であるのに対して。
 後者は、何か現象（木からりんごが落ちる様子とか）を観察して、何かしかこの現象の背景に共通して存在する法則があるのではないかと予測して、諸処の実験を繰り替えして、この現象を説明する自然科学的な考えをしている（ように見える）。

 つまりこの本は。我々の行動には、経済学の常識では測れない（不合理）な行動がままあり、そしてそれらはある種の規則性があると言っており、いくつかの実験を通してその法則性を紹介している。

 では。どのように不合理であり、またどのような規則性があるか。
 動画でもいくつかの例が示されているが。いくつか他の例を挙げると。

 何故、レポートや執筆作業を期限ギリギリまでやらないのか。
 何故、1万円で売られているガラケーを買わないあなたが、数万円で売られている iPhone や android 端末を買うのか。
 何故、2,000 円以上のランチを食べないあなたが、4,000 円のディナーを食べるのか。
 何故、時給 5,000 円以上稼げる優秀なデベロッパーがコミュニティで活動するのか。
 複数人でランチに行った際。何故敢えて、他の人と違う（または同じ）注文をするのか。
 ある店で 300 円のカレーと 900 円の旨いカレーを出す店があり、毎回 900 円の旨いカレーを注文するあなたが。ある日、カレーの値段が無料に、旨いカレーの値段が 600 円になったとき、どちらを注文するか。

 といった事がある。どれも、経済学的な観点（我々が十分に冷静で論理的な思考が働く状況）では、首を傾げたくなる内容ではないだろうか（もちろん屁理屈を捏ねて説明もできるが）。更に、これらの非合理的な行動は、上述の規則性が見られる。
 本書では、このような不合理な行動を我々が行うという事と、これらの行動がある程度予測可能であるという事を、諸処の実験から結論づけている。

 特に、自分の心に刺さった内容として。
 ３章の「ゼロコストのコスト」等で繰り返し紹介される不合理な行動の予測からは、いわゆるマーケティング的な行動を行う上で、かなり有用であると感じた。つまり、誰か（もしくは特定の誰か）に対して、有用な価値がある（ように見える）モノを提供する上で、氏が提唱する行動経済学の規則性は、非常に参考になった。
 また４章の「社会規範のコスト」では、自分のような何か物事を（命令する立場ではなく）お願いする立場の人間において、様々な立場・関係の助力してくれた人間に対して、どのような方法でこれに報いるべきかという、人材マネジメントのヒントが見えてくる。
 更に１１章の「品性について」では、どのような状況下で、どの程度の不正を働き、またこれをどのようにして防ぐのかという、ある種のリスク・マネジメント的な話が（立場的にリスクを引き起こす可能性がある側の人間として）とても参考になった。

関連文書:

• 関連文書は見つからんがな

Tweet

2011年1月号にMap/Reduce(Pig/Hive)の記事を書いたのに続き、ASCII.technologies(アスキードットテクノロジーズ)2011年5月号にHBaseの特集記事を書きました。

ASCII.technologies (アスキードットテクノロジーズ) 2011年 05月号 [雑誌]

まるでクラウドの上の人のようです。

原稿を一部ページ数の関係で削りました。せっかくなのでここに載せます。前後の文脈なしでこれだけ載せてもどうか、という内容ですが、なんとなく言いたいことが伝わることを期待しています。

まとめに代えてHBaseとBigtableを取り巻く技術を紹介する。Cassandra開発元のFacebook社がメッセージシステムにHBaseを採用したニュースが記憶に新しい。これを聞いてHBaseがCassandraより優れていると思うのは早計だ。用途に向き不向きがあるというだけだからだ。このニュースはHBaseが向くアプリを示唆している点で興味深い。HBaseのレプリケーションの戦略から想像できるように同一データへのアクセスが集中しやすいアプリはHBaseよりCassandraが向いている。一方、Facebookの利用者が相互に送るメッセージのようなシステムでは個々のメッセージに各利用者がそれぞれアクセスするパターンが多そうだ。このような大量アクセスにHBaseはスケールする。

最初、上記の原稿が「Facebookメッセージの用途にCassandraよりHBaseのほうがスケールする」と誤読されました。そう主張するつもりはありません。言いたかったことは「Facebookメッセージの用途では、HBaseも(Cassandraと同程度に)スケールする」です。同程度にスケールするなら、より整合性を確保しやすいHBaseを選ぶ理由になります。

さて、まだASCII.technologies誌の他の記事はほとんど読んでいませんが、IBM Watsonの記事は面白かったです。HBaseの記事より面白いです。これは素直に負けを認めます。INDRIとか初めて聞きました。

なんでIBMはこんなに凄いのに、他のソフトは…(以下自主規制)。

関連文書:

• 関連文書は見つからんがな

Tweet

「Emacsのトラノマキ」の原稿を公開します。画面上のメニュー「ドキュメント」からたどれます。今回の記事は佐藤さんが執筆した「Emacsをもっと快適にするElisp集」です。Software Design 2010年3月号の掲載記事です。過去の連載の中でも人気のあった回です。

今発売中のSoftware Design 2011年4月号の「Emascのトラノマキ」は菅原さん執筆の「Major Modeを書こう」です。ちなみに冒頭がこんな感じです。

昔はMajor Modeを作れて、はじめて一人前のEmacs使いと呼ばれたそうです。

実に挑発的です。

Software Design (ソフトウェア デザイン) 2011年 04月号 [雑誌]

関連文書:

• 関連文書は見つからんがな