回転木馬のデッド・ヒート（村上春樹）
動機
動機は、私が日頃から影響を受けているid:finalventのこちらを見て。
finalvent 長期というなら聖書かな。あまり本という感じはないけど。小林秀雄「考えるヒント」もなんども。村上春樹「回転木馬のデットヒート」なんかも。“@kazu_yama1003: @finalvent 先生が今までで一番読んだ本って何ですか。聖書ですか、やはり?” 4月30日
「考えるヒント２」も買ってきたけどそちらは未読。
感想
本書の内容は、村上春樹が人から聞いた話、つまり体験談集ということになる。
一つのエピソードは、２０から２５ページであり、長編と比べるまでもなく内容が凝縮されている。
感想を一言で言ってしまうと、全体を通して「理解はできないけど、納得はできる。」
細かく解読出来るかといえば出来ないけれど。ただぼんやりと、ああ、そういうことだよね。と。
エピソードは、その語り手ですら感覚的にしかわからない（と言っている）ものも多く、私が論理として理解できないのも自然であると思う。
ただ「そういうものなのよ。」ということは共有できる。
ところで、極東ブログの書評では、こうある。
最初の作品が発表されたのは１９８３年の秋で、私はその年に大きな人生の転機があった。印象深く思い出す。私が２６歳。春樹さん（まだ超メジャーな作家とも言えなかった）が３５歳だ。
読む時期というのはやはり大事で、それが何かの転機の前後であるとか、それこそ年齢としての転機の前後であるとか（まさに、それについてのエピソードもある。）、そういうときは普段より感じるところが多い。
また、ここでは「書かれた時期」についても言及しているが、この場合は読み手が書き手に追いつく年齢というのも、やはり重要になる。
ところで、今の私は当時の翁よりは年長で、当時の著者よりは年少だ。
なんらかの転機かと言われると、そういうものはここ最近感じていない。
そんな状況で一読したわけだが、特に「影響」を受けた感じはしなかった。
ただ、静かに、糧になったな、と。こういうものを摂っていかなければいけないのだな、と感じた。
（それを影響というなら、確かにそうなのだが。）
誰もが生きて行く中で、自分では決して通りかからない、足を踏み入れないような道というのはあって。
それがどんな道なのか、縁のない自分にはわからないし、何事もなければその道程を想像することすらできない。
本書は、そんな道の中でも、とびきりのやつを集めたような。
私が例えると、そういう印象の一冊。
村上春樹の中でも、特に長編と比較するとずいぶん読みやすい。平易という意味ではなく、簡潔であるという意味で。
★をつけるとしたら、ちゃんと5をつけられるし、図書館で読んだとしても、自分のために買ってしまうくらいの本。
こういうものを、しっかり摂っていかないと。
35歳までに、何度も読み返すことになりそう。
（はてな年間100冊読書クラブ、8冊目。）
私がiPad2発売日に、WiFi32GBのBLACKに決めた理由
iPad2は回線、容量、色の違いで合計12種類もあるため、買うことは決めてもどれがいいか迷ってしまう。
私はタイトルのものを入手したが、ここでその理由と、初日の使用感を書いておく。
・iPad2購入について
・なんでWiFi32GBのBLACKなの？
・初日の使用感
iPad2購入について
当初は退社後に買おうと思っていたのだが、売り切れる可能性があると判断したので昼休みに秋葉原へ。
ヨドバシカメラは、12時過ぎにはWiFiは全て品切れということで、私は焦りながらいくつかの店舗を回った。
最終的にはソフマップMac館で買うことができた。時刻は12:20くらい。
安心して、さてtweetでもしようと思ったら、dankogaiさんも同じタイミングで同じものを買っていたようで、少し驚いた。
なんでWiFi32GBのBLACKなの？
結局のところ、一番人気は「白の64GB」だったようで、午前中から各地で売り切れの報告があがっていた。
発売前のwebでも、黒より白の方が圧倒的に人気があるようだったし、妥当な結果だったと思う。
私も「ここは白を買って自慢するべきか？」と少し考えたが、結局は自分が使うものなので、決めていたものを買った。
WiFiにした理由は、主に自宅で使うから。
もし外で使うようになって困ったら、そのときに（持ち歩けるWiFiなどを）検討する。
時間が経つとそのあたりのコストも下がってくるだろうし、今必要無いものは買わない。
プログラミングのYAGNIと同じで、どうせ使わないよ、って。
32Gにした理由も同じで、今は32Gあれば十分だから。
1年後に足りなくなったら、iPad3で64Gを買えばいい。
最後に、色。
これは、白の方がシャレオツであると思う。私はそう思うし、おそらく一般的な評価もそうだ。
さらに、iPad(1)との差別化ができる。白ということは、「2」だ。
それでも私が黒を選んだのは、実用性を気にして。
いくつか比較サイトを見たところ、白では「フレームが浮く」と感じた。
何を見ても白い縁が気になってしまう。
これは昼の時点でdankogaiさんも言っていた。
Dan Kogai 画像を見る時、より本体の存在感がなくなる方を< @willmonia blkにした理由はなんでしょうか？やはり（明るく見えるらしい）画質の面でしょうか。 RT @dankogai: #iPad2 入手なう。WiFi 32GB blk
追記：エントリも書かれてました。＞404 Blog Not Found:news - Faster, Cheaper, Lighter, and Righter = iPad2
とはいえ、白という選択はアリだと思うし、むしろ白のほうが人気がある。
私もきっと「せっかくiPad2なのに、なんで白にしなかったの？」と何人かに聞かれると思う。
プログラマーは自分のコードを疑え
若い頃にはよく陥る過ちだと思う。
最近やってしまったので自戒エントリ。
1.テストでバグ発見。
2.共通で使っている様々な計算をするクラスのメソッドから期待した値が戻ってこない。
3.どう考えてもこの（自分以外が作った）メソッドが業務上の例外を考慮してないだろ（履歴を見ると何度も問題があったモンスターメソッドだ）。
4.読み辛いながらも、そのメソッドのバグを探す。
5.どうもバグってないように見えるので、そのメソッドが使っている定数まで疑いだす（どんだけだよ。）
6.よく見たら私が書いたメソッドの呼び出し方が悪かった（結論）
この歳になってこれはないよ。。。
でも「今更やってしまった」と実感できたのは良かった。
今後、バグを見つけたら、自分のコードを徹底的に疑う。
以下余談。
テストのコストが高いのがネックだと感じる。
数秒で終わるUTのコードがあればぐるぐるまわすんだけど、テストコードを作る時間が認められていない。
テストとは、オフショアが手動でやってくれるものだという慣習（かつ、契約）だ。
コーディングとは、設計書と脳内デバッグを駆使して書くもので、そう、えいやっ！と、「コードを書いて、祈る」のだ。
テストがないコードはレガシーコードだ。
VMware Fusion3を買った
iMacと一緒に購入したWindows7 HomePrem32bit。
これをBootCampに入れていたが、ここ半年は一度も起動せず、もったいないなぁと思っていた。
そこで、評判が良いVMwareFusion3の、30日無償評価版を使ってみることに。
VMware Fusion： Mac をデスクトップ仮想化に使用して、Mac 上で Windows を実行
これは想像以上に使い勝手が良く、30日経過と同時に購入した。
BootCampと比較
大きく二つの利点がある。
1.再起動が不要。
ただのアプリとして立ち上がるので、すぐにWindowsに入れる、しかもまったくモタつかない。
私はSpacesで一つ割り当てているけど、これは楽だ。相性が良い。
BootCampは再起動が必要だったので、どうしてもというときじゃないと使いたくなかった。
そして、どうしてもという機会は半年間で一度も無かった。
2.MagicMouseの精度がいい。
MagicMouseはBootCampでは正直使いたくないレベルで、別途マウスを買おうかと思うくらいだ。
Fusion3ではMacOSXと同じように動いてくれる（と私は感じている）。
できるだけ安く買う
安く買えるのに越したことはないなと調べ、結局980+3551円で購入。
（もっと安く買う方法があるかもしれません。）
act2.comから。
404 Not Found - act2.com
Fusion 2 サポートレス→Fusion 3 サポートレスへアップグレード / 980 + 3,600 = ￥ 4,580
購入の流れは簡単で、全部合わせても10分程度。
・ユーザー登録をする
・Fusion2を980円で購入
・Fusion2のシリアルがメールで送られてくるが、特に使わない。
・Fusion3（アップデート版）を3600円で購入（ポイントが49あるので49円引かれる）
・Fusion3のシリアルがメールで送られてくるので、評価版で使っていたFusion3を立ち上げて、シリアル番号を入力する。
結局、購入後の作業はシリアルの入力だけ。
Windowsの再アクティベート
使いはじめたら一つ問題が起こった。
「このWindowsコピーは正規品ではありません」という表示が出て、プロダクトキーを入れ直してもダメ。
原因はBootCampにも入れていたから？（随分前に削除済みなのだが。）
仕方ないのでWindowsに表示されている指示に従い、フリーダイヤルのサポートに電話をかけた。
全て自動音声で、5分ほどで再アクティベートが完了した。
環境構築
まだ全然進んでないけど、ドキュメントフォルダの共有など便利な機能がある。
しっかり使うならメモリ（4G）が足りないと感じたので、先日追加で8Gを買ってきたら本当に快適になった。
サブで使ってるXPから徐々に環境を移行して、そろそろ隠居させてあげよう。
プログラマが知るべき97のこと
前回書いた通り、オススメの一冊。
今春“プロ”グラマーになる人が、あと1週間で学ぶ３つのこと（＋１） - holyppの日記
見出し
・私の選んだ２つのこと
・プログラマーの考え方になる
私の選んだ２つのこと
本書の内容について。
テスト、デプロイ、レビュー、開発環境（IDE/unix）、開発技法の話はもちろんいくつもあり、
それに「良いコードとは何か」「ちょっとした開発のコツ」「経験談（失敗談)」などたくさんの考え方が書かれている。
人によって、また読む時期によって感じ方が全く変わってくる類の本なので、さしあたり今の自分が気になった２つを選んでみた。
64.プロのプログラマとは （ロバート・Ｃ・マーティン）
タイトルの通り。解っていたはずなんだけど、まだまだ。
プロのプログラマとは、どういう人のことでしょうか。 プロフェッショナルなプログラマの最大の特徴は「自分が責任を取る」という態度、責任感です。
もちろん誰もが責任を持って仕事をしている。
ただ、それが「どれくらい？」となると、ちょっと足りてなかったかな、と思わされる。
たとえば、あなたがもし、心臓切開手術を受けるとします。そしてその様子を幽体離脱して上から見ているとします。医師に与えられた時間は限られています。 こういう時あなたが患者なら、医師にはどう行動して欲しいでしょうか。 納期に追われるプログラマのような行動を望みますか。「とにかく時間内に終わればよい」というようないい加減な仕事をして欲しいですか。あるいは「今、ちょっと治せないので、 後にします」などと言って欲しいですか。
納期に追われるプログラマのような行動を望みますか？
19.誰にとっての「利便性」か （グレゴー・ホーペ）
技術よりの話ではこれを。API設計について。
メソッドwalkとrunがあったとして、これらはメソッドをまとめてしまっても良いと考えられる。
例えばwalk(true)と書けば走っている、とする。普段はそれで良いが、対象がAPIであったらどうか。
API では、1 つの問いに対応する動詞、つまりメソッドが必ず1つとは限らない、ということです。 ボキャブラリーに多様性を持たせれば、微妙な意味の違いが容易に表現できます。 たとえば、walk(true) というようなコードを書かされるよりは、単に run と書ける方が間違いなく使いやすいでしょう。
「することがほとんど同じなのに、2 種類の呼び出しを使うのは不便ではないか」というのは、要するに呼び出す側にとって不便というのではなく、コードを書く自分が、内容のほとんど同じメソッドを2つ書くのが「面倒」という意味なのです。
つまりタイトルの通り、「それ」は、誰にとっての「利便性」か、ということ。
APIでは利用する側の利便性を考えることが良い設計になる。これは「言語」と一緒だという。
そういえばRubyもString#length()とString#size()など、様々な表現ができる。
プログラマの考え方になる
詰まるところ、本書の効能としてはこれが一番大きいのではないか。
朱に交われば赤くなるという。
81人のプログラマの考え方と、そこで使われている言葉によって、読者は特に意識をしなくてもプログラマになっていく。
これは「48.いろいろな言葉を学ぶ（クラウス・マルカルド）」に書いていることにも通じる。
たとえば、話す相手が会計士ならば、原価センタ会計、投資資本、使用資本、といった概念についての基本的な知識が必要です。 マーケティング担当者にも、弁護士にも、やはりそれぞれに特有の言葉や概念ががるので、それを多少は知っておかなければうまく話ができません。
これはプログラマが会計士/弁護士と話す場合に「相手の言葉」を意識する必要性を書いている。
ここには、プログラマが「プログラマの言葉と概念」を使っているという前提があるが、日本の（様々な）プログラマがそのような「考え方」をしているのかといえば、必ずしもそうではない。
私の周りでは「サラリーマンの考え方」をしている人の方がよほど多い。
本書の全てのエッセイには、プログラマの哲学が根底にある。
通して読むことで、初学者やサラリーマンでも「プログラマっぽく」なる。
その際、ひとつひとつの言葉の意味がわからないかも知れないが、それでも「プログラマっぽく」なるのだ。
そこから真にプログラマになるためには、本書で紹介されている本を読んでいけばいい。
「リファクタリング」や「レガシーコード」は読まなければならないし、まだそれらを敷居が高いと感じるなら、先に「テスト駆動開発入門」を読んではどうだろうか。
「テスト駆動開発入門」は比較的薄く、内容は「テストを書いて、コードを書いて、リファクタリングする」という実践的なものなので、スラスラと進むし、楽しいし、身になる。
終わりに
本書はオライリーにしては安くて薄い。
それに、気が向いたときに、気が向いたところから読み始めて、止めたいときに止められる。一つのエッセイは、ほとんどが２ページである。
座右の書にいいかもしれない。
個人的に、内容が同じらしいけどリファクタリングRubyエディションが気になってる。
はてな年間100冊読書クラブ、7冊目。
※（2011/4/4）何点か指摘いただいた点を修正しました。 @JunichiIto77 @pplaceinfoに感謝します。
今春“プロ”グラマーになる人が、あと1週間で学ぶ３つのこと（＋１）
元記事はこちら。
今春“プロ”グラマーになる人が、あと1週間ですべき7のこと | Act as Professional - hiroki.jp by HIROCASTER
シリーズ化？
今春サーバを触っていくのにびくびくしてる人が1週間ですべき7のこと - カイワレの大冒険
今春“組み込み”プロ”グラマーになる人が、あと1週間とはいわないけどこれからやってほしい7のこと - what you see is what you get
元記事はターゲットが広すぎたからか、対象を指定したエントリが書かれている。
私はもう一度、対象を広く戻して、自分なりのエントリとしてまとめてみた。
と、いうのも。
元記事は少なくとも「新卒」が一週間で準備すべきことには当てはまらない。
「新卒プログラマーがこの１年で意識すること（マスターすること）」という趣旨なら十分納得できるのだが。
プログラミングの知識
プログラミングの知識というものは、はじめは入社後にその会社に最適化させて覚えていくべきだ。
例えば、入社前にマーチン・ファウラーやケント・ベックに心酔し、マイケル・フェザーズよろしく「テストがないコードはレガシーコードだ！（キリッ」と言ったとしよう。
そこで「それはもちろん正しいんだけど、このプロジェクトはテストコード書かないんだよ」と先輩に言われたら、残念だが従うしかない。
それが嫌なら、学ぶべきはプログラミングではなく根回しの方法になる。正しいという理由だけで物事が受け入れられることは少ない。
また、例えばあなたがギークだったとしても、支給されるPCは「低スペックのWindows」であることもよくある。
そこで「かぁーっ！俺のMBPでEmacs使って書いたら１日で書けるのにな〜！ほらみてこの小指？かぁーっ！」と言ったところで、ニックネームが「ミサワ」と決まる以外に事態は変わらない。または無駄に悪化する。
もちろん、プログラミングの知識が多いに越したことはない。
ただ、まだ知らなくてもいい。
入った職場で言われた規約に従いながら結果を出し、それから勉強しても遅くはない。
私が新卒プログラマーに求める３つのこと
では何が大切なのか。プログラマーなのにプログラミングの勉強をしなくて良いのか。
ひとつの例として、私が新卒の社員に求めるものは３つある。
・素直さ
・論理的思考力
・会話力
素直さ
まずは、素直で真面目であること。
前述のように、素直になることを知識が邪魔をするならば、そんな知識はまだ必要ない。
素直で真面目であれば、なんでもすぐに吸収できる。
プログラミング規約や技法はもちろんのこと、社内の人間関係や権限まで、見えないものも理解するよう心がける。
組織で働くというのは、とても人間くさいものである。
それに、できれば時間は守ったほうが良いし、整理整頓（自分のPC内も）など細かいところに気がきく方が上手くいく。
あわせて「人」というものがどういうものであるかも知っておくべきだろう。
私は「新卒が１冊だけ読んできてくれるとしたら」迷わずこれを推す。
上に書いた「正しいという理由だけで物事は通らない」理由など「教えづらい」ことが、これを読むことで理解してもらえるから。
オススメは左の三冊セット。文庫サイズなので電車でも読める。
論理的思考力
これは技術だから学ぶしかない。オススメはこちら。
「ロジカルシンキングって当時流行ってたね」という印象があるかもしれないが、実際に知ってるかどうかで全然違う。
たまに読み返してる。わけのわからない仕事を大量にふられたときの対処法。「マッキンゼー式」を再読する。 - holyppの日記
会話力
いわゆるコミュ力だが、「素直さ」「論理的思考」があればあまり問題にならないだろう。
弊社で中途採用をするときには、プログラミング能力はもちろんとして会話力があるかを見る。
システム開発は一人で最初から最後まで行うことは（一般的に）無い。
自分が作ったものは、自分では承認できない。
例えば、コードレビューでは意図を説明しなければならないし、問題が起きた場合は具体的に説明しなければならない。
また、必要があれば情報の提供の依頼をしなければならない。つまり、人を動かさなければならない。
それに、「メールで１０往復しても何も決まらなかったけど、電話したら５分で決まったよ」なんてこともよくある。
会話重要。
（＋１）それでも読むべきプログラマーのための本
「全然プログラマー向けじゃないじゃないか！」と怒りの声が聞こえてきそうなので、One more thing.
（とはいえ上記を満たす、つまり「学ぶ姿勢がしっかりしており、人間とはどういうものか理解があり、きちんと考えをまとめられ、話もできる」人材であれば、これを読まずともすぐに頭角をあらわすことは間違いない。）
上記にあわせて、この時期は多くの人の考えに触れ、それをもとにして自分を創っていく時期でもある。
本書の内容は、コーディングやデプロイ、設計から、心構えや人間関係まで多岐に渡るので、学ぶところが多い。
この本には 73 人のプログラマによる 97 本のエッセイと、日本人プログラマ 8 人による 書き下ろしの 10 本、合計 81 人による 107 本のエッセイが収録されています。
最後になるが、目次から日本人プログラマの部分を抜粋する。
日本人プログラマによる知っておくべき 10 のこと 1 命を吹き込む魔法 森田 創 2 ロールプレイングゲーム 関 将俊 3 ルーチンワークをフローのきっかけに 宮川 達彦 4 プログラマが持つべき 3 つのスキル 吉岡 弘隆 5 快適な環境を追求する 舘野 祐一 6 見知らぬ人ともうまくやるには 小飼 弾 7 不具合にテストを書いて立ち向かう 和田 卓人 8 育ちのよいコード 森田 創 9 No といえることの大事さ 宮川 達彦 10 名前重要 まつもと ゆきひろ
＋１というか、＋１０７ですが。ぜひ。
プロジェクトの打ち上げが説教部屋だった
先日、プロジェクトの打ち上げがありました。
そういった場での会話は、マネージャーやプロジェクトの中核となる方々からの労いが多いと思います。
「みんながんばったねー、君もがんばった、君もがんばった。みんなのおかげでプロジェクトが成功したよありがとう。」
そう思っていたら、今回は全く正反対で、
「君はもっとがんばって欲しかった、君ももっとがんばって欲しかった、オレはあんなにがんばったのに、君の分まで仕事したよ」
と、40代の偉い方々からの30代へお説教が続きます。
私もいろいろと指摘をいただいたので、改善していかなければなりません。
しかし、最初から最後まで説教部屋状態だったのはさすがになぁと思うので、私からだけでも労っておきます。
「メンバー全員が持てる力以上の貢献をしたからこそ、不可能と思われたプロジェクトを計画通りに終わらせることができたと思います。
お疲れさまでした。」
