Google Developer Day Tokyo の video を見た

Google Developer Day Tokyo - 鵜飼 文敏 を見てみました。先に自戒も含めてダメだしすると、話す事は決まってても滑らかに、テンポよくはなせた方がカッコいいよね。電車で通勤してた頃はずっと IT Conversations をひたすら聴きまくっていて --まぁアレは選りすぐりだから単純な比較は出来ないけれど-- 欧米人のプレゼンの巧さに舌を巻いていたものでした。

それはさておき。今回新たに知った内容を簡単にまとめておきます。

Design Doc

新しいプロジェクトを始めるときなどに書くものらしい。

背景・目的

（Why）

設計

（How）コードが常に見られるようになっているので、余り細かい設計は書かない。むしろコードではわからないような事を主に。

メンバー

（Who）後から全く別な部署などからコンタクトがあったときのために。

セキュリティ／プライヴァシーの考察

テスト・モニタプラン

ダウンタイムを少なくするための工夫があるか、とか。

セキュリティ／プライヴァシーの考察が一番最初の企画書に書き込まれているのはとても興味深い。僕が修論制作でとあるサービスを企画して、発表した時に一番ネガティヴな反応はプライヴァシー上の問題だった。ある人に取っては全く些細な事でも、それが大事な人も居る。また企画書を読む人は、作る人の意思ではなく、読む人の理解の範囲でしか物事を理解しない。１つネガティヴな事があると、使う側は使わないし、作る側はやる気がそがれる。その時、僕が得た教訓、実際ユーザを相手にするときは双方の信頼が大事、という事をこれは大きく裏付けてくれている。

三大言語

C++

インフラに近い所

Java

Frontend でよく使われるようになってきた

Python

内部サービス。Housekeeping 的。Guido の書いた Mondrian というレビューシステムがあるらしい。

他にもブラウザ上での Javascript やファイナンスなどでグラフを描画するのに ActionScript を使う、とか。Sawsall は鵜飼さん自身は“たまに”触るらしい。そうなのか…

コーディング規約重視

EWT Review を通らないと、コミット制限がある。

Eric Schmidt の言葉

Build for scale as the world and the internet are both very big places. Don't accept anything less than being the best.

---

全体を通して感じたのは、未来のため、っていう意識の高さ、でしょうか。僕も前職では（まぁプログラマではなかったけれど）まったく記録なんてとろうと思わなかったけれど、今では率先して書いてるし。そういう意識を保つのは大事ですね。