開発中
未整理
真夜中の決闘 ~Gという名の強敵（トモ）~
出たよ。 出ましたよ、とうとう。 Gがよ。
2年前、マンションに引っ越した当日に台所の排水溝でご対面して以降の再会、ただし種類は違うっぽいけど。（Gだと思うけど、一瞬コオロギにも見えた。小さいタイプ。）
深夜4時頃、詰めて作業を行っていたら突然、液晶ディスプレイの裏からカサカサ、っと（「ｺﾝﾆﾁﾜ！」）
「出たっ！」と一瞬で戦闘態勢に入り、すぐ身の回りにあった物で身構える。
叩く棒になるものが無く、右手に程よい長さのガムテープ。
ファーストコンタクトでは見失い、それからしばらくは右から出ては消え、左から出ては消え、
着地に失敗していきなりキーボートの脇に落下してきて俺をビビらせてくれるなどの繰り返しで15分くらいが経過…
「また現れてからやっちまおう」と席に戻り、作業にまた集中していたところ。「････
･感じる。」 こういうシチュエーションの時にはよくある、「見られてる感」
をビリビリ感じ、床に目を落としたところ ?居たっ！?
叩くものは無い、ガムテープも遠くにある。殺虫剤なんて後がめんどくさいので使いたくない、さぁどうする？？
そんなことを考えている間に、隣の部屋でスヤスヤと寝ている嫁さんの布団なんかに逃げられたら、俺の命が危うい！！
ていうか明日以降、昼の食事を用意してくれなくなるぞ！と様々な事を一瞬のうちに考えながら、ある天才的な行動にでた。
（ここからは文章だと分かりにくいので、添付の図を参照。こんな図をパワーポイントで書いたのは初めて）
■まず、作業机の上に置いてあったアルミ製のペン立てを手に取り、床にいるGを閉じ込める。
■次に、閉じ込めたペン立ての口を密封するように、厚手の紙を床との間に瞬時に挟む。ペン立てはメッシュになっているので、
Gが登りやすかったのはラッキー、浮かして挟みやすかった。 Gの自業自得だが、閉じ込められた瞬間に触覚を両方とも無くしたらしい、困るだろうなあ。
■本音を言うと無益な殺生はあまりしたくないので、厚紙とペン立てを上手く手で押さえつけ密封したまま、手で持って移動。うちを出て、
マンションの植木がある庭に、Gを開放してやる。
というわけで、被害は最小限にくいとめ、殺生もすることなく、後味の悪い後片付けもする必要がない完璧な勝利をおさめた俺は、なんとかこの強敵（トモ）との闘いを記録に残したく、
仕事そっちのけでブログを書いてみる。
明日、マツキヨでコンバットを買い込んでおこっと。
公的年金も毎月、被保険者に対し「明細書」を発行すべきだ
「領収書がなければ受け付けません」という態度だった社会保険庁が、最近は「領収書が無くても、できるだけ明確にできるよう、調査いたします」という態度に豹変したらしい。
領収書だとか社保庁の記録が、とか言う前に何故、毎月もしくは毎年にこれまでの累積納付額や支給予定額などがチェックできる明細書を発行してこなかったのだろうか？
発行するのに費用がかかる？そんなの送って誰が見る？ なんていう反対意見もあるのでしょうが、それをしてこなかったために社会保険庁の信用が一気に地に落ちたのでは？ せめてでも毎年、被保険者に対して現在のステータスを通知する仕組みさえあれば、全てが社保庁の責任と問われず「明細をちゃんとチェックしてこなかった国民にも非がある」と、喧嘩両成敗（まではいかないか？）にできたのではないだろうか？
そんなことを常々考えていたのですが、磯崎さんのisologue、「年金を受け取れる権利」なんて、もともと存在しない（補足編） にて参考になる意見を発見。
引用させていただきます。
通常、預金でも投資信託でも証券でも、自分の口座にいくら金がたまっているかは、「債権者」によって定期的に（またはランダムに）チェックされ、それによって一種の牽制が働いているわけです。民間だけでなく、役所の仕事でも、たとえば地方税で、自分の申告と住民税の通知の額が大きく違っていたら、その場で「あれ？」と思うでしょう。
ごもっとも。銀行やクレジットなどは最近はコスト削減のため、印刷物の郵送ではなくWebから残高などをチェックさせるようにしてるよなあ。社会保険庁さまならば、そんな仕組みを導入するなんて難しくないだろ。 住民基本台帳ネットワークシステムと繋げばもっと管理しやすくなるんじゃね？
年金や預金の定期通知はありがたいのだけど、学生時代の奨学金返済の明細が定期的に届くのは勘弁してくれ…凹むから。
なぜかアクセス増大
きのう6月9日だけ、なぜかこのブログのアクセス数が増えている… なんでだろう
特別なにかエントリーしたわけでもないし。うーん、わからん。
参考：「Google のエンジニアはどうやって開発しているのか?」
「へ?たのめも」 さんとこのエントリーにあった「Google のソフトウェア・エンジニアリング 」を発見。Google Developer Day Tokyo での鵜飼さんのプレゼンがわかりやすくまとめられていました。
最近、あるきっかけで異様にGoogleへの興味が沸いてきているのですが、その理由はおそらく企業としての興味というよりも中の人たちの文化的な部分に対する興味なんだろうな、と実感。
いくつか注目した点をピックアップ。
Google のプロジェクト・チーム
- 開発はデザイン、コーディング、テスト、改善、デモの運用まで上流から下流まで同じチーム(同じ人)が全部やる
- チームは少人数 (2?6人)。これ以上に増えると、プロジェクトのフォーカスを絞ってチームを分割
２?６人っていうのがバランスがよさそう。なるべくフォーカスは絞ってシンプルでコンパクトにってことですね。
Google のソフトウェア・ライフ・サイクル
-
アイデアが出たら、Design Doc と呼ばれるドキュメントを書く
Design Doc
- Google で必ず書くことになっているドキュメント
- プロジェクト立ち上げ時の 1?2週間をかけて書く。ある程度ポイントが書けたら、もうコーディングへ。
- 一般的にはあんまり長くない。詳細を書かなきゃいけなくなったら、それはまた別プロジェクトになることが多い
- Design Doc の内容
- プロジェクトの背景、目的
- おおまかな設計(コードを見ただけでは判らないような、アーキテクチャ)
- プロジェクトの参加者(このプロジェクトに関して、誰に連絡を取ればいいのか)
- セキュリティやプライバシーについての考察(問題と対処方法)
- テスト、モニタープラン(運用時の考慮。障害の発見と復旧手法など)
- レポジトリ上の位置やサーバのアドレスなど
- コードを書いていると解離していくので、できるだけ解離しないようにアップデート
ふむふむ。 自分達はいままで「企画書」と呼んでいた部類のドキュメントのことですね。ひとりで取り組むことが最近多いけど、それでもやっぱりDocを書いて残す習慣付けをしていた方が、今後会社を大きくしていくためにも良さそうだ。
自分の社内のプロジェクト管理に限らず、ちょうさん達とやっている「わくわくオープンラボ」にもうまく取り入れていけないかな。
Google のコーディング
鵜飼さんは普段、毎週 0?20個のパッチを書く。年間 3万5千行くらい。シニア・エンジニアやフェローになると、もっと書いていて、Google では、偉い人ほどコードを書きまくっている。
ハンパねぇ?
- ユニット・テストは必須。ユニット・テストを自動で実行するシステムもあり、テストが通らなくなると「直せ」 とメールが飛んでくる
- "testing on the toilet"。テストに関する intergrouplet が、トイレの壁に 「テストのコツ」を書いて貼っている。単体テスト普及活動の一環。
ユニットテストは大事。 おろそかにしてしまうことが多いけど、継続していくシステムの場合はユニット単位でのシステムのクオリティが重要だと実感。
Google の開発方針
- パフォーマンス重視(まず計測、とにかく計測、良いアルゴリズムの採用、コーディング・テクニックの積み重ね)。 Google グラフ書くのが好き。数値化重要。
- スケーラビリティ重要(いずれは Google Product になるのだから当然)。 たくさんのマシンで並列化できるように
- 信頼性(Google はマシンが大量にあるので、ハードウェアは毎日壊れる。レプリカを作ってデータは多重に持つ。 障害監視と自動的な障害復旧に力を注ぐ)
模索中ではあるのだけど、シンプルで汎用的に使える数値化の基準とか、可視化の方法がないかとここんところ悩み中。 Googleくらいになるとノウハウが詰まってそうだから、こんど知人にノウハウを聞いてみよう。