(1:18) 今日もいつもの休日と同じく、2〜3時ごろにプールに行って喫茶店でまったり読書などしようかと思っていたら、昼寝してしまって結局晩ご飯までずっと家にいた（プールはその後行った）。
どうしてかと思ったら、そういえば昨日飲み会があったからだな。
体力がない。
Maverick Bird の音楽を買った。
4ユーロ（600 円ぐらい）。
Maverick Bird の音楽についてつぶやいていたら教えてもらえたのでソーシャルすごいと思ったけど、maverick bird music あたりで検索するとすぐ出てくるのでそんなにすごいわけでもなかった（教えてもらっておいて）。
この音楽めっちゃ好き。
聞きながらプログラミングしたら効率1.5倍ぐらいになりそう。
そういえば、プログラミングで IDE 対エディタみたいなやつがあるけど、IDE の欠点というのは、GUI なのでどうしても「不確実」な動作が入ってしまうというところ。
たとえば、別のファイルに移動するというのを「タブをクリック」という動作でやっていると、正しいタブをクリックしてやらないといけない。
これは集中力を下げる。
その点、Emacs であれば、たとえば 3分割した画面の間をショートカットキーで移動するということが簡単にできる。
キーボードであれば、ほぼ不確実なことはない。
新しいファイルを開くような場合でも、文字を打てばいいので楽だ。
GUI でも、ソフトによってはうまく設定したら理想の状態に持って行けるのかもしれない。
しかし、Emacs のようなメジャーなエディタに比べるとそれは面倒だ。
Emacs なら、いくらでも情報がある。
そういうわけでぼくは Emacs が好きなのだが（といっても elisp? とか全然書けないのでただのワナビーっぽい）（Vim についてはよく知らない。あのモード切り替えというのが正気の人間がやることのように思えないので深入りしていない。ちゃんとやったら Emacs 以上のものがあるのかもしれないが未知数だ）、Java に関して言えば IDE のサポートがないとやってられない。
そういうわけで、会社では Eclipse を Emacs キーバインドで使っているが、やっぱりマウスを使うときには気が散ってしまう。
まあ、このあたりは多くの人が感じていることだから、改めて書くまでもないけど。
なぜこの話になったか。
そう、音楽。
音楽を聞きながらコーディングすると、気が散らない範囲での集中力は上げることができるが、マウスでタブをクリックする速度や、ましてや PukiWiki を編集する速度が上がったりはしない。
（そして、なぜ MIT ライセンスが怖くないのか、使っても会社のすべてのコードを公開させられるようなことにならないのかといったことを調査する速度も上がらない）
プログラマの生産性の話は、この辺とも絡んでくる。
ぼくがコーディングだけをしたら、平均的プログラマの3倍（適当な数字）の生産性（≠速度。アルゴリズムの時間・空間的計算量を考えられるという意味で）（そもそも、平均的プログラマには、計算量という語彙がないのだ）で働けると思っているが、その途中にくだらないアリバイ作り的作業が絡んでくると、どうしてもそれだけの生産性は出せない。
もちろん、そういう場にいまいるのは純粋にぼくの能力不足によるものだが。
（どちらかというと就活能力だ。しかも、就職先を探すといった超基礎的なレベルの）
ちなみに、ぼくはプログラミング面接通過能力は、上で書いた3倍よりもっと上だ。
（こう言うのも何だけど）そうでなければGoogleの面接は通れない。
そういう面接では、「わかっている」かどうかが重視される。
文字コードや、ソートなどのアルゴリズムから、ブラウザ周りの何もかも（HTML-JavaScript-CSSあたりとか）とか。
また、純粋にアルゴリズム的な問題を解くことができるか、など。
しかし、実際のプログラミング能力ということになると、もっといろいろな要素が絡んでくる。
たとえば、設計のようなところ。
面接で聞かれるおもちゃ的なところを超えて、ちゃんとしたものを作ろうとすると、クラス構成（あのUML的な）がなかなかできない。
ウェブアプリケーションでいうと、MVC 的な考え方がうまくできない。
これは致命的だ。
しかし、これは前者では頑張っているのに後者をサボっているというわけではない。
弱いながらも、頑張って強くしていこうとしている。
でも、生きていくにあたって、強いところを伸ばすのがいいのか、弱いところを補うのがいいのかは必ずしも自明ではない。
そこら辺を考えつつやってきた結果、必ずしも弱いところを補うということだけをしてきたわけではない。
面接通過能力というのは、まあ「頭の良さ」のようなものだ。
しかし、それをもって「頭がいいくせに（それに対応するレベルで）プログラムが書けない」というように言われるのは、まあ仕方はないが、すぐにはどうにもできないし、長期的にマシになったとしても最初からできる人ほどはできないだろう。
まあ、プログラミングのできるミサワ的な人にはその辺をわかってほしい（わかってもらってどうなることでもないが）ところだ。
最初から「頭が悪い」人間なら、そういうできる人にもアフリカのかわいそうな子供に対するようなやさしさを持って接してもらえるところだが、ぼくのような半端に頭がいい（自分で言うのもどうかという気もするが）（しかし、ぼくのような人間が「自分は頭がいい」と言っていかないと、自分のできる部分について「努力の結果」だというようなものだ。それは事実の半分でしかない）人間は、「できるならコード書けよ」のように思われてしまうことがある。
でも、ぼくだってぼくにできる限りで書いているつもりなのだ。
（その成果物は少ない）
（また、文章を書いている暇があったらコードを書けというふうに思われたとしても、日記を書くことは自分の人生をオーガナイズするうえで必須なのだ）
話を変えて。
今日は、Counting Bloom Filters というおぞましいデータ構造について知った。
Bloom Filters の 1 ビットの代わりに 4ビットぐらい使って削除を可能にするというもの。
正気か？
サイズが 4倍になるじゃないか。
元々偽陽性率をどのくらいに設定するつもりか知らないが、それを 1/n とすると、数を覚えておく代わりにフィルタに使ったら 1/(n^4) にまで低くできる。
「ぶつかったら別のデータ構造で覚えておく」というほうが省メモリで確実じゃないか。
もちろん、偽陽性率が高いと別のデータ構造のサイズも多く取らないといけない。
しかし、偽陽性率が高いような状況なら、カウンタのビット数だってもっと増やさないといけない。
このあたりについて、もうちょっと考えてみたいところだ。
ところで、こういう低レベルなところはぼくの得意とするところだ。
（Bloom Filters については、ぼくは自分で再発明していたぐらいだ）
（もっとも証明できるものでもないのでハッタリと思われるかもしれないが日記だしどうでもいい）
しかし、こういうのは情けないほど仕事には結びつかない。
Bloom Filters について考えたりしないで、Rails の勉強とかをちゃんとやったほうがいいのか？
その辺のバランスはよくわからない。
まあ、面白いと思ったことは面白いと思ったときにやっておこう。
バランスとして、そうするのがいいんじゃないかと思うからだ。
