_ スズメが襲う 会社からの帰り道、スズメが歩道で何かきらきらしたものを突いているのを見かけた。 何かと思ってみると、それは動いている。コガネムシだ。 スズメは突つきまわすと、2、3歩、ぴょこぴょこ後ずさりする。すると、コガネムシが動き出す。すると猛然と前進してまた突く。コガネムシが固まると、2、3歩ぴょこぴょこ後ずさりして、またコガネムシが動き出すと……を繰り返している。 食べるつもりかな？ と思ったが、普通は米を食うはずだし、ミミズならともかく、甲虫を食べるとは思えない（でかいし）。 まるで、ネコが食べる前にいたぶるってやつみたいだなぁとしばらく見ている。 すると、コガネムシが隙を見つけたのか、いきなり飛んだ。するとスズメも飛び上がり、鋭く嘴から体当たり。コガネムシが落ちる。そこを着地してクチバシで突きまわす。コガネムシの動きが止まると、2、3歩ぴょこぴょこ後ずさり……また、これか。

_ わかりやすい文章はエレガントではない 人は自分のインセンティブを高めるためなら平然とダブルスタンダードをやらかしてくれる。 今、次の言明について考える。 文章はわかりやすさをもって本分とし、漢語はもちろんのこととして、倒置法、体言止めなどの本則を外れた表現、陽か陰かを問わず喩えを排除せよ、と。 でも。実のところその言葉を吐き出した同じ口から、次のような言葉が出て来ることがある。 もっとエレガントなコードを！　パターンを！　switchを捨てよ！　重複を排除せよ！ この口は頭が悪いのだろうか？ エレガントなコードは良くて、エレガントな文章は悪いのか？ だが結論を急ぐことはまったくない。 光あるところに影がある。 別の側には、非エレガントコードの推進派がいるのだ。 かれらの叫びに耳を傾けてみよう。 コードはわかりやすさをもって本分とすること。3項演算子はもちろんのこと、仮想関数は利用せずs

_ プログラミングの技をめぐる探究 Coders at Workをいただいたので、紹介します。 と言っても厚さが約600ページという分厚い（と言ってもうまく紙を選んでいるのでそんなに厚くはなく約2.5cm）本をもらったその日に紹介できるわけじゃない。レビューに参加させていただいたので、相当読んだからだ（でも、期間内に全部は読み切れなかった、すみません）。 これはオーム社同時代開発者叢書の白眉とでも言えるやつで、15人のすごいコーダー（コードを書く人）が、ピーター・サイベルというインタビュアー（追記：この人が実に良く、直前のインタビューイがくさしたものを次の人に弁護させたりする）に応えて、どうやってプログラミングを学んだとか、プログラミングってどんなものかとか、設計はとか、どんな本を読んだかとか（ほぼ全員がクヌースを挙げる。で、本書のトリはドナルド・クヌースなので、ちゃんとそれについてインタ

_ 感覚の違い みねこあさんの『「気が狂っている」感触』を読んでいて思い出したことがある。 10年以上前のことだと思うけど、アメリカのどこかの会社の出張RDBセミナーみたいなのに出たのだが（日本に出張してセミナーをしてくれたのだが、黒と赤と青の3色のボールペンを使って分析したことは覚えている）、そこで講師の見るからに賢そうな女性が、1対1の例として墓(tomb)のことを持ち出してきた。 で、おれは日本では1対1じゃなくて多対1だと何気なく言ったらさあ大変。いきなり興奮してそんな気持ちが悪いことはあり得ない、それは異常だ。それはあり得ないからお前はおかしいとか、まさに気が狂っている扱いだった。いや、おかしいのはお前の頭だろうと思ったが、後になって考えてみると、あの連中は野蛮だから土葬なんだな。で、連中の狭い了見で死体と死体がミソくそ一緒に押し込められているところでも想像したのだろうと納得して

_ 森を見て木を見ないバグ おとといのバグ。 バグ自体はくだらないのだが、原因追究に無駄な時間を使ったのでメモ。 次のようなプログラムを作った。 void Write(string templ, params object[] args) { string msg = string.Format(templ, args); ...//IOを伴ういろいろな処理 } void FooBar(object a, object b, object c, object d) { ... Write("{0} {1} {2} {3}", a, b, c, d); ... } が、テンプレートのパターンと引数に齟齬があり、例外が投げられるバグが見つかった（たとえば、{}内で特定の型を指定しているのに、引数がそれとは合わないなど）。 そこで、以下のようにした。 void WriteAsABCD(objec

_ アプリケーション死すともプロセス死せず CPUが早くなって、しかもコア数が増えて同時実行可能なプロセス数が増えると、考えもしないタイミングが生まれる。 GetExitCodeProcess APIは、"If the process has terminated and the function succeeds, the termination status returned may be one of the following"だから、プロセスは現在完了形でターミネートしていて、呼び出しに成功したらステータスが返る。ということはプロセスはターミネートしているはずだ。 でも、どうもそうではない。というのは、ロジカルに特定のプロセスがCDしているディレクトリが、そのプロセスがターミネートした（追記：と、上のようにGetExitCodeProcess呼び出しの結果から判断した）にもかかわ

_ 今日の、一つかしこくなった インドで留学生してあっちで数年就職してた人とちょっと話して、長年の疑問というか不思議について別の見方が聞けて納得感があったのでメモ。 おれ：子供（たぶん、小学高学年か中学）のころに、インドってカーストとかのせいでえらく非効率だって聞いた。んだけど、なんかそれは偏見じゃないかって疑ってるんだけど。その例に出てきた話ってのは。ホテルに泊まったら電灯が切れている。フロントに電話したら、しばらく待っててくれと言われた。しばらくするとノックの音がした（エヌ氏じゃないけど）。開けるとインド人が4〜5人入ってきた。梯子を用意する係が梯子を電灯の下に置いた。電灯を外す係が切れている電灯をはずした。電灯を付ける係が…… インド帰り：ああ、それはわかりやすくて良い例ですね。もっとも、8人から10人くらい来ると思いますけど。 おれ：えー、これは良い例……というか、もっと多いのか！

_ 正しいインセンティブ 青木さんが訳したTEDのやつを読む。 クリエイティブで素晴らしいパフォーマンスを引き出すにはどうすれば良いか? おれには、ここで語られていることは次のように読める。 給料はそれほど高くなくても良いが、リラックスできて安心感があり、適度な権限と解決すべき課題があること。 なるほどね。 だから、年功序列、生涯雇用は、ばっちり機能していたわけだ。それは理にかなっている。 なんでそれをやめさせたい奴がいるのかな?

_ 1つの言葉、複数の概念 winplusさんの『売上の「正しい」名前とは何か』を読み、頭をひねる。 ビジネスの世界じゃなければ、名前空間で分けるけど、そういうことでもなさそうだし。 でも、もし、それがOOPの世界だったらどうだろうか？ 売上はSalesで、SalesのデータなんだからSalesDataとかいうPOJO（POCOでも良いけど）を作ることにして、工場と商品企画で異なる名前空間があるとする。 namespace 工場 class 売上 { 顧客 {get; set; } } namespace 商品企画 class 売上 { 顧客 {get; set; } } これについては、それほど違和感ないな。 名前空間ってのは、日常生活での言語においては文脈ってことになるけど（文脈によって同じ言葉が異なる概念を持つ）、データベースではそれは何だろうか。データベース（カタログ？）ってやつか

_ 目標設定の記述方法 アスキーの嘉平さんから妙な本をもらったので読んだ。多分6ポモロード(注:正しくはポモドーロ。完全に逆転して書いているので注意)くらいで読み終えた（つまり通勤3日分）。おもしろかった、ありがとうございます。 アジャイルな時間管理術 ポモドーロテクニック入門(Staffan Noeteberg) ということは大ざっぱに3時間弱くらいで読了できるということだ。おれはこの文章を書くためにいろいろひっかけながら読んだからそれだけかかったが、多分、もっと早く読めるかも知れない。 ポモロードってのはトマトのことで（子供が表紙を見て、トマトの本か？ と訊いたくらいだ）、それをポモロードと呼ぶことによる異化効果はあまり日本ではなさそうだが（トマト銀行という銀行名から受けるインパクトに比べると赤やなんか間抜けっぽさや薄皮っぷりとかの印象が抜け落ちるからだけど）、でも謎めきっぷりからは良

_ 正規表現は重要でしょう Javaでも.NETでも普通にクラスが用意されているわけで、以前ならなんかforとかでクルクル回す必要があったコードも"^¥¥d+$"とか使って楽勝でチェックできるようになった。 というわけで、自分が正規表現を読み書きできるのは当たり前として、周りも読めるようにならないと、三流プログラマの呪いの言葉「難解なコード」攻撃に襲われることは確実だ。あの連中は概念の難解さではなく、見た目の記号含有率で難しさを判定するからな。 このままだと、コーディング規約に「ソースが難解になるので正規表現は禁止。1文字単位にswitch、caseでチェックすること」と書かれる日は近いぞ。 というわけで、いやいや、正規表現は四則演算程度に常識ですよ、ナンカイはナンカイでも南海のパラダイスと言えるように、周囲のみんなや後輩に、こいつを薦めて学習させよう。職場へのクリスマスプレゼントにピッタ

_ マイクロソフトは何か勘違いをしている Windowsの開発をすることを考える。スタンドアローンのWindowsアプリケーションではなく、クライアント＋サーバのシステムだ。 組み合わせは次のいずれかとなる。 1. クライアント＝Windows7(x64)＋サーバ＝Windows Server 2008(x64) 2. クライアント＝Windows7(x86)＋サーバ＝Windows Server 2008(x64) 3. クライアント＝Windows7(x86)＋サーバ＝Windows Server 2008(x86) 4. クライアント＝Windows7(x64)＋サーバ＝Windows Server 2008(x86) で、問題は、1と2の場合だ。 この場合、開発環境は次の組み合わせが考えられる。 1. クライアント(x64)PC + サーバー用(x64)PC 2. クライアント(x

_ 粘膜人間 Twitterでma2さんが最近読んでる本として挙げてくれた粘膜人間を読了。 粘膜人間 (角川ホラー文庫)(飴村 行) うーん、なんというか、どんどん読めるぐいぐい読める、後に残るは時間の経過というか、まるでファストフードみたいな本だなぁ。 どんどん読めるぐいぐい読めるっていう意味ではつまらなくもなければ退屈でもない、つまりはおもしろいのだが、なんというか感興ってのが湧かない。 色っぽい描写もあるのだが少しもエロティックじゃないし、暴力がばしばし振るわれるのだがまったく恐怖はない。なんなんだろうか？ 選評が収録されていて荒俣宏がこういうのが今様なんだろうなぁとか書いているが、きっとそうなんだろう。ヴィッテプロプル。 という意味ではおれはいろいろ面白い移り変わりを楽しめて来たのだろう。 でももしかすると単に年を取って擦れただけなのかも。そういえば昨日子供に借りて魍魎の匣の最終巻

_ 匿名（ちょっと意地っぱり）デリゲートとラムダ式 ちょっと.NET WindowFormsアプリケーションを作っている。 そこで、イベント処理を書くわけだが、当然のように次のようにやる。 ctrl.AddEventHandler(delegate (object o, EventArgs e) { ... }); それから、今はdelegateなんて余分なキーワードはいらないんだなと思い出して ctrl.AddEventHandler((o, e) => ....); と、書く。 が、これはまずかった。 実際にはイベントによって次のハンドラに替えていくプログラムである。 void InitState() { ctrl.AddEventHandler((o, e) => FooState()); } void FooState() { ctrl.AddEventHandler((o, e)

_ 現実はおっかない ソルトって映画の中で、ソ連のスパイ養成所のエピソードがあった。 そこでは誘拐されてきた子供たちが本名を名乗らないで、圧倒的なエリート教育を受けていたのだった。 ソルト ブルーレイ＆DVD セット [Blu-ray](フィリップ・ノイス) で、モスクワ攻防戦を読んでいたら、同じようなエピソードが出てきて、あながちフィクションとばかりも言えないのだな、とちょっと驚いた。驚いたというのはあまり正確ではないが（北朝鮮が誘拐した人を利用したりする、というのがあることは知っているわけだから）不意を突かれたというか、なるほどなぁと納得したというか、そういった感覚。 そういう破壊活動を仕込まれる運命をたどった人たちが何人か登場するのだが、そのうちコクロフという人に興味を持った。 19歳の口笛吹きなのだが、ドイツがモスクワを占領した場合に将校を暗殺するためにNKVDに雇われる。優秀なボ

_ モスクワ攻防戦がおもしろい 何気なく本屋で手に取りついふらふらと買ったのだが、もちろんスターリンとヒトラーという二人の歴史を変えようとした政治家への興味、個人的にはモスクワ攻防戦に対する興味（ショスタコーヴィッチがビルの屋上で敵機を監視する仕事をしたということだけしか知らない）が根底にはあるのだが、これは大当たりだった。 まさに読書する喜びにしびれまくる。500ページ近い本のうち100ページ程を読んでしまったが、次々と出てくるエピソードの数々に圧倒される。 モスクワ攻防戦――20世紀を決した史上最大の戦闘(アンドリュー・ナゴルスキ) 突然気付いたが、戦争が歴史のネタに特になるのは、それが戦争という極限状況を描いているからではなく（もちろん、それがあることは間違いないが）、「記録」が圧倒的に多いからだ。当時～だった～の思い出話のようなものに始まり、国家の正規な機密文書、公式の外交文書、戦

_ エンタープライジーなREST オライリーから私が監訳（という作業を初めて経験したわけですが、それは別の物語）した、『JavaによるRESTfulシステム構築』という本が近々出ます。 JavaによるRESTfulシステム構築(Bill Burke) この本は、実にいろいろな面からおもしろい。おもしろいので、オライリーの編集の方に翻訳して出版する価値もあれば意義もあるとお勧めしたわけで、当然、読むことをお勧めします。 さて、何がおもしろいのか。一端は後書きに書いたけど、当然、書ききれない点や後書きに書いてもしょうがない点とかは省略しているので、そのあたりを含めて紹介します。 1. 著者がBill Burke これはおもしろい。というのは、BillはJBoss野郎なのだ。当然、CORBAからのORPC男。当然EJB。もちろんEJB3。 なぜ、そのBillが『JavaによるRESTfulシステ

_ 子供との会話 「腕時計が要るんだけど」 「どうせ、後、2、3年したらiPhoneかAndroid持ち歩くことになるんだから、腕時計なんて親のお古でいいだろ?」 「それは無理じゃないかなあ」 「何が？」 「後、2、3年」 「そうか? 大学生なら授業中に使っても問題ないと思うけど」 「違うよ。さすがにまだ出来てないよね?」 「?」 「アンドロイド」 「え」 「え」 まあ、その程度の知名度(家はauってのもあるかも)。 (C3POみたいなのを連れて通学する自分を想像したってことだと思うが、楽しそうな近未来だよなぁ)

_ Javaのスコープの続き いずれにしても、スコープルールがよろしくないのは議論の余地がないと思うので、とはいってもJavaを利用する限りは現時点ではそういうルールなのでとりあえずはしょうがない。 ではどうするのが良いのだろうか？ という点に絞って考えてみる。 BufferedReaderについては明かなことがある。 それは、このクラスが利便性追求クラスだということだ。 というのは、すでにしてFileReaderがあるのだから、実際問題としてBufferedReaderのメリットは（バッファリングなんてOSが勝手にやってくれるのだから、別にJavaのクラスでやらなくても良い）、readLineメソッドの存在にある。 つまり、行指向のテキストファイル（CSVもそうだし、プロパティ形式もそうだし、まあ、世の中たくさんある）の読み取りを簡単にするための存在である。 java.io.*には、IO

_ Javaのスコープの素朴な疑問 ある人が書いた本の中のサンプルコードに次のようなものがあった。 do { String buff = bufferedReader.readLine(); if (buff != null) { doSomething(buff); } } while (buff != null); これはもちろんコンパイルできない。 String buffの可視性は{}の中で閉じているからだ。 でも、次のは違う。 for (int i = 0; i < len; i++) { doSomething(i); } iのスコープは、for節全体となり、for()の中で宣言したものが{}内でも有効で、そこを外れると参照できなくなる。 この、あるステートメントを構成する()内で変数を宣言できるというのをwhile系にも適用すればよかったのだ。 while ((String b