Google の HDD のレポートの衝撃

Google によるHDDの故障率に関するレポートを見て、今まで信頼をしていたものが失われてしまった、、。これは、かなり衝撃的なレポートだ、、。ただ、改めて考えてみると、そもそも、HDD は消耗品なわけで、ある程度の故障はやむをえない、、。Google のように "必ずコピーが3つ存在する" というように、HDD の構成に頭を悩ますより、単純にデータのコピーを複数作成して、それをいかに上手に運用するかの方が理にかなっているという事なのかも、、。
「S.M.A.R.T」による計測値も、ほとんど当てにならないらしく、、真にハードディスク障害の早期発見ができるツールが出てこない限り、ユーザー側でなんらかの措置が必要になりそうです。。
きっと、この辺をうまい事やってくれるオープンソース系のプロジェクトが発生するかも？もしかしたら、もうあるかも？

Googleによると、ハードディスクは温度や使用頻度に関係なく故障する
ハードディスクに関する4つの都市伝説

jQuery Form Plugin ステキ

jQuery 単体で、Ajax 通信とかしようとしたら、標準の serialize とか使いづらくて、みんな、どうしてんだろう、、、とか思ってたら、"Form Plugin" とか発見！なるほど、みんな、これ使ってるのかぁ～、納得。ってなわけで、次回は、"Form Plugin" を使って、楽々 Ajax 通信なわけです。
そして、jQuery の Plugin のページ 見たら、ものスゴくいっぱいPlugin あるじゃないですか、、。いろいろありすぎで、迷いそうです。。まぁ、じっくりと触ってみるとです。

jQuery Form Plugin

Perl プロトタイプ宣言

List::MoreUtils の any の実装と使用方法を見て再発見。

# 実装
sub any (&@) {
    my $f = shift;
    return if ! @_;
    for (@_) {
        return 1 if $f->();
    }
    return 0;
}

# 使用方法
print "At least one value undefined"
    if any { !defined($_) } @list;

何故に、ハッシュリファレンスが、コードブロックとして、ちゃんと評価されるのか、疑問に思った。。。で、any の実装で、プロトタイプ宣言を行っていたから、これが、何か怪しいなぁって事で、プログラミングPerl〈VOLUME1〉を開いてプロトタイプについて再確認してみると。

& が最初の引数であった場合、特別扱いされることを示している。通常は、プロトタイプ文字 & は \&foo や sub {} のような引数を要求する。しかし、 & を最初の引数として指定した場合には、無名サブルーチンの sub を省略して「間接オブジェクト」スロットにブロックだけを置くことができる（この場合、ブロックの後ろにはコンマは置かない）。
& の素晴らしい点は、 & を第１引数とすることによって、新しい構文が作り出せることである:
～ プログラミングPerl〈VOLUME1〉 page 263 より引用

なるほど～、プロトタイプ宣言した場合は特殊なのね、だから、ブロック渡しが完結にコーディングできるのですな。普段、何気なく使っていた、map や grep、sort も、そうゆう実装になっているのかなぁ、とか思った。あと、$_ のスコープが、グローバルだから、ちゃんと中でも参照できるのだなぁ、とかも思った。

html-tt.el & javascript.el を入れました。

Template::Toolkit と、只今、話題の jQuery を使い始めたので、会社の Meadow へモードを追加しました。どちらも、良い感じです、オススメ。
作者の皆様、多謝。

html-tt.el
Clouder::Blogger - html-tt - emacsのTemplate Toolkit用のmode

C-c m → [% SWITCH %][% CASE %][% END %]
C-c w → [% WHILE %][% END %]
C-c f → [% FOREACH %][% END %]
C-c e → [% ELSE %]
C-c i → [% IF %][% END %]
C-c n → [% INCLUDE "" %]
C-c d → [% *** %]
C-c s → [% %]

javascript.el
Yet Another Hackadelic - [Emacs][JavaScript] javascript.el

デブサミレポート - 第１回 Google

第１回目は、これ↓。一日目のセッションに関しては、今後、資料があがるかと思われるので、一番、資料が公開されそうにない、ここから、レポートあげます。

2/15 10:00-10:50
Googleを支える大規模分散システム / Google における開発プロセス

-- Google における開発プロセス --
スピーカー：小松弘幸 Profile
Googleトランジット モバイル担当

- プロジェクトの始まりからリリース
プロジェクトの立上げ。20%ルールプロジェクト／開発者によるアイデアやデモなど
↓
プロジェクトメンバー。デモを見た社員が希望で参加したり、または、支援を行ったり
↓
プロジェクトが起動に乗り始める。
↓
プロジェクトの本格化。エンジニアに加えて、プロダクトマネージャー、デザイナー、マーケティング、広報、各チームの方が参加する。
↓
beta リリースを行う
↓
フィードバックをもらって、機能拡張やバグフィクスを修正。
↓
正式リリースへ

プロジェクトは基本的に、エンジニアが、企画、設計、運用を行う。

- 20%ルール
Googleの全社員が、好きなプロジェクトや自己研鑽など、自分の好きな時間。既存サービスの拡張。新しい技術の習得。数学の学習。会社にとって、長期的にでも、メリットがあれば OK みたい。プロジェクトの立ち上げには、まず、モックの作成などを行ってから。何故なら、見ればわかるから。何をしたいのかを伝え、プロジェクトの賛同者を募る。発表の場としては、アイデアメーリングリストというものがあり、発表したアイデアに対して、１〜５点の得点とコメントをつけて返信をする形になっている。プロジェクトが成長したら、目的を明確にし、違う所のプロジェクトなどで、似たような機能が無いかなどを確認して、車輪の再発明を防いでいる。

- 情報共有
デザインドキュメント。読めばわかる。まわりからの質問に対して、何度も回答をするより、書いた方が楽なので。社内wiki wikiにプロジェクトに参加するため必要な情報、まとめなど。プロジェクトチームは、エンジニア４〜５人、プロジェクトマネージャー、ユーザーサポート、など、、１０人に満たない。weekly meeting 一周間に一回のミーティング。自分たちの進捗の報告など。

- 開発環境
全てのソースコードが一元的に管理されている。他のプロジェクトの人間が、Gmail のソースコードの閲覧や変更も可能。コミットログ。コード検索。テストツール。単体テストツール、プロファイラ。ほとんどのツールが、自社開発。
テストなどで、マシンパワーが必要な場合には、大規模データを扱うなど、デモを作る段階で、数千代のクラスタを利用可能。うまい具合に処理が隠蔽されていて、ジョブの割り当てや、故障等に関してエンジニアが考える必要が無い。デモの作成段階で、ペタバイト級のストレージの利用や、ミニチュアインターネットによる、ウェブデータが自由に利用可能、個人で利用可能。

- 開発期間
納得いくまで作る。自分たちが、目標を決めて期限を設定。納得の行く所で、提出。延長の場合は再設定をする。

- 目標と成果の設定
エンジニア個人。プロジェクトチーム。会社全体。各単位で設定。四半期単位で今後の事など。

- Google トランジット
- サービス概要
最寄り駅の自動判別。目黒雅叙園は、目黒駅とか。同じ駅名でも、大手町は、東京の大手町じゃんみたいな事をしてくれる。
- 開発のお話
アメリカ版のトランジットが、別で発足していた、ソースコードを流用。
どのように統合したか、それぞれ、違うエンジンを持っていたので、それぞれを、プロトコルバッファーを利用して統合（シリアライザーのようなものらしい）。データをどのように流すのか、異なる言語間でも利用可。あらゆる所で。利用しているらすぃ。
ユニットテスト書く。コードレビュー。レポジトリに入れる前に、ソースコードレビューを少なくとも、一人に行ってもらう。
リリースに向けて。テクニカル、UI,セキュリティレビュー、、、。などなど。
最終リリース。リリース用マシンの割当。マシンのメンテは選任者がやってくれる。
リリースエンジニアと一緒に、共同作業でリリースを行う。
メーリングリストもひとつ。ソースコードレポジトリもひとつ。情報もいつでも引き出せる。

-- 鰯の感想 --
エンジニア主体で経営されている Google は、まさにエンジニアにとっての天国なのかもしれない、その反面、高い技術力や成果を求められる部分もあると思う。。。設備も体制もかなりできあがってきているのだろう、、社員同士が切磋琢磨し合える環境は非常に大事だと思う、今の会社では、切磋琢磨し合える人が、ほとんどいないため、、非常に残念で仕方が無い、、技術者としてもっと、常日頃から勉強をしてもらいたいものです。

※「Googleを支える大規模分散システム」にてついては、次回投稿します。。

サロゲートキー

ナチュラルキー - 顧客コードとか自然発生するキー
サロゲートキー - システムが自動付加するキー

サロゲートキーは変更に強い
　顧客コードのフォーマットの変更
　過去ログなどとの整合性

ビジネス的な変更が、システムに大きな影響を与えないので、この考え方は重要ですな。
確かに、今までの自分が触れてきたシステムは、ナチュラルキーを主キーにしている部分が大きく、その部分の変更には、大きなリスクを伴うため、、"さわらぬ神に祟りなし" といった感じで扱われてきた、、、。サロゲートキー重要ですな、、

参考
代理キーは「スタイル」ではなく「テクニック」
- サロゲートキーは万能では無い的な話？
第３回：BIシステムの特性を知る－基礎知識編(2)