2011年1月29日土曜日

Google URL Shortener Fixed Now?

I don't believe it matters much anymore, so I'm writing about a bug (or maybe a feature back then) in Google URL Shortener.  As far as I tested today it's already taken care of.

In short, I think there was a chain-of-shortened-URLs bug, so to speak.  On the release day or so I read about the URL shortener and tried it to see if how it was different from other shorteners.  I liked the simple interface with some extra features like access stats and 2D matrix bar codes.  Anyways, then it occured to me if it can shorten just any URL (well, even when they are descending people still call moving staircases an escalator...).  

So an URL 'http://goo.gl/' is obviously shorter than URLs "shortened" by goo.gl.  Unexpectedly goo.gl actually lengthened the URL, with a hash code:
goo.gl/I349

Then I also wondered what would goo.gl return if a shortened URL by goo.gl itself,  i.e. "goo.gl/I349", was given.  The result:
goo.gl/CCix
And you could repeat the process, making a chain with each time generating a different hash code... 

I'd have reported them if it was really serious problem, or I liked the way google support team responds generally.  So far as I know I don't think they are very good at communicating with users.  Maybe they just don't reply but listens well, I don't know:
my days and responses: Google Translator Toolkit

As for goo.gl I don't know what's been going on, so I can't say if it was really a bug, but to me there were lessons learned:
- Try to find test cases carefully (and never think they are complete).
- Users might help you reporting bugs if you are little more friendly :)

Common sense, but really important...


2011年1月26日水曜日

Thanks to Twitter...

Thanks to people tweeted on my last post, finally there were lots of accesses.  I figure twitter is the quickest way to notify people of such a personal blog post (as most of you already know).

最初はまったく読まれる気配がなかったが、しばらくして主にTwitter経由で結構アクセスが来たらしい。また何かおもしろいものがあったら投稿しよう。


2011年1月19日水曜日

Read an Interesting Article on Facebook Developers(和訳)

I enjoyed reading the article and thought people might find it interesting too... so I roughly translated the article to Japanese.


以下Facebook社の開発プロセスについてのyeeguy氏のブログを日本語訳したもの。95%程度はあっていると思うが詳しく確認していないので詳細は適当な部分がある。題名は原文へリンクしてある。



2011年1月17日 — yeeguy

Facebook社のやり方に感心している。とても個性的な環境で、同じ環境を簡単に作れるようなものではない (もしやってみたとしても、他の会社全てでうまくいくわけではないだろう)。以下に示すのは、会社でどのようにソフトウェア開発をしてリリースをしているのか、Facebook社に在籍する多くの友人と話しているうちに集まったメモだ。


他にもFacebook社に興味を持っている人達がいるようだ…
また、 Facebook社の開発者主導の文化が大いに世間の詮索の的になってい、一方他の会社では開発者主導の文化が実現可能なのか、どんな方法で実現するのかという難しい問題に取り組んでいるしかしながら、Facebook社では内部のプロセスをとても慎重に選定する。新機能や内部のシステムについてFacebookのエンジニアチームはメモを公開するが、これらは大抵「どのように」ではなく「どんな」という類の記事である… そのため、外部の人間にとってはFacebookが他の会社と比較して大幅に効率的にサービスを改良し最適化しているのかが簡単にはわからない。Facebook社がどのように機能しているのかをもっと理解するための試みとして、外部の人間の立場で個人的にこれらの考察を数ヶ月の期間にわたってまとめた。情報提供者に対するプライバシーを尊重し、全ての氏名、特定の機能や製品について言及している部分は削除した。また、これらの考察をまとめてから公開するまでに6ヶ月以上も待ったので、きっとこれらのメモの内容は少し古くなってしまっている。これらのメモを公開することで、Facebook社がカオスな状況に陥らずに組織の意志決定をどのように行ってきたかをいくらかでも解明するために役立つことを期待している… Facebook社の成果、あるいはFacebook社がいかに首尾一貫して製品を提供してきたかについて反論するのは難しい。一般ユーザー(コンシューマ)を対象としている多くのインターネット企業がFacebookの例から学べると思うし、学んで欲しい。

Facebook社の内部についての視点をまとめるのに協力していただいた多くの方々には多大に感謝している。epriest氏やfryfrog氏など、訂正、編集についてのまとめをしていただいいた方々にもまた感謝する。
注:
  • 2010年7月の時点でこの会社には2000人近くの従業員がおり、およそ1100人の従業員がいた10ヶ月前よりも増えている。一年たたずにほぼスタッフが2倍!
  • 規模において上位2つのチームはエンジニアとオペレーション担当で、それぞれ400から500人のチームメンバーが所属する。これらの2チームだけで会社のおよそ50%を占める。
  • プロダクトマネージャとエンジニアの比率は大ざっぱに言うと1対7から1対10程度
  • 全てのエンジニアは4週間から6週間の「ブートキャンプ」トレーニングを経験する。このトレーニングを通してバグの修正をしたりシニア/テニュア(永任権を持つ?)エンジニアによる講義を聴いたりすることでFacebookのシステムについて学ぶ。
  • ブートキャンプを終えると、全てのエンジニアが本番環境のDBにアクセスできるようになる(「大きな権限は大きな責任を伴う」ことについての標準的な講義と「クビに値する違反事項」、例えばユーザーの個人データの公開、の明確なリストも同時に提供される)
  • [記述編集、fryfrog氏の指摘] “内部の権限を持ってすれば可能になってしまうと想像できるようなひどいことを社内の誰かが実行してしまうのを防ぐため、とても優れたセーフガードがある。サポートに連絡するような「立場に」ならざるを得ない場合、その内容が記録されるのには理由があり、しっかりとレビューされる。ここでは道を踏み外す者は許容できない。以上。”
  • エンジニアなら誰でもFacebookのコードベースの任意箇所を思い通りに変更でき、チェックインできる
  • 大いにエンジニア主導の文化である。「ここではプロダクトマネージャは基本的に役に立たない」というのはあるエンジニアによる言葉の引用。エンジニアは開発過程の途中で設計を変えたり、プロジェクトの順位を変更したり、アイデアが浮かんだらいつでも新しい機能を加えたりする。
  • 異チーム合同の月例ミーティングでは、エンジニアが進捗報告を発表する。プロダクトマーケティングやプロダクトマネジメントの人間もこれらのミーティングに参加するが、これらの人が話し過ぎると「この間のミーティングではプロダクトがおしゃべりしすぎた」などという評価がリーダーに対して返ってくる。彼らはエンジニアが公的にプロダクトを所有する状態を望んでおり、開発するものについてエンジニアがコンタクトの中心となるのを望んでいる。
  • プロジェクトに対しての人員配置は完全に自主的である。
    • プロダクトマネージャがエンジニアのグループに声をかけ、アイデアを説明し、熱心に興味持たせるよう働きかける。
    • エンジニアは、取り組むならどのアイデアが面白そうか判断する。
    • エンジニアは上司(マネージャ)に「今週はこの5つのことに取り組みたい。」と話す。
    • エンジニアマネージャはたいていエンジニアの希望をほうっておき、時には特定のタスクをまず片付けるように指示することもある。
    • エンジニアは機能全般にわたって取り仕切る --- フロントエンドのjavascript、バックエンドのデータベースコード、またそれらの間にあるもの全て。デザイナーに助けを求めたければ(人数は限られるが専属のデザイナーがいる)、デザイナーを説得してプロジェクトに参加するように興味を持たなければいけない。アーキテクトに助けを求める場合も同様。しかし一般的には、エンジニアは必要なもの全てについて自ら対応するよう期待される。
  • 機能についてのあるアイデアが実現するに値するかどうかの議論は、一般的に1週間を実装に費やしてユーザーの一部に対してテストすることで解決する。例えば、ネバダ州のユーザーのうち1%を対象とする。
  • エンジニアは一般的にインフラ、スケーラビリティや「困難な問題」に取り組みたがる --- そこに全ての名声があるから。フロントエンドのプロジェクトとユーザーインタフェースに取り組むことについてエンジニアの熱心な興味を引くのは難しい場合がある。「ここは私が作ったんだ」と特定の機能を指差したいがためにお客さんが触れるような箇所に関わる、というようなコンシューマービジネスの場合とは反対の状況である。Facebookでは、ニュースフィードのアルゴリズム、広告のターゲットを絞るアルゴリズム、memcacheの最適化などのようなバックエンドの案件はうまみが多くエンジニアが欲しがるプロジェクトだ。
  • 特定の高優先度の機能(例えばニュースフィード)に影響があるコミットはマージ前にコードレビューを受ける。 News FeedについてはZuckerberg氏が必ずどんな変更点もレビューするほど重要だが、これは例外的なケースだ。
  • [訂正、epriest氏の指摘] “全ての変更点についてコードレビューは義務となっている(つまり、一人以上のエンジニアによってレビューされる)。 この記事の言わんとしているところはZuck氏が個人的に全ての変更点を見るわけではないということだと思う。”
  • [訂正、fryfrog氏の指摘] “全ての変更点は最低1人によりレビューされ、特に招待しなかったとしてもシステムは他の誰にでも簡単に見ることができ、コードをレビューすることができる。レビューされていないコードを混入するには、意図的かつ悪意を持った行動が伴うはずだ。”
  • QAは全く存在しない。関わった仕事についてエンジニア自らがテスト、バグ修正、リリース後の運用に責任を負う。単体テストや結合テストのフレームワークは存在するが、時々利用されているのみである。
  • [訂正、fryfrogの指摘] 実際には会社にQA(チーム)が存在していることを付け加えたい。ただし、正式なQAグループではない。職場にいる、あるいはVPN経由で接続している全ての従業員は次のタイミングでリリースされる全ての変更点を含むバージョンのサイトを使っている。このバージョンは頻繁に更新され、世間のユーザーに見えるものよりも通常1〜12時間先行している。全ての従業員はどんなバグでも報告するように推奨され、これらの報告に対しては迅速に行動が起こされる。”
  • QA(品質保証)や自動ユニットテストが欠如していることの驚きについて — “多くのエンジニアはバグのないコードを書くことができる。ほとんどの会社がそれに対してのインセンティブを設けていないだけだ。QA部署があるなら、単純に彼らに任せてエラーを見つけてもらうのが簡単だ。”  [EDIT: これは主観的な意見であったということに注意してください。他の会社での標準的な開発プラクティスと対照的に述べるためにこの記述を入れました。]
  • [訂正、epriest氏の指摘] “我々はテストを自動化した。その中にはリリースが世に出る前にパスしなければいけない「push-blocking」テストも含まれる。 「ほとんどのエンジニアはバグのないコードを書くことができる」ということは我々は全く信じておらず、ビジネスの基礎とできるような妥当な考えだとも思っていない。
  • プロダクトマネージャに影響力と権力がないことの驚きについて — プロダクトマネージャは独立性と自由さを持っている。影響力を持つカギは、エンジニアリングマネージャと本当に良い関係を築くことである。ばかげたアイデアを提案しない程度に、十分な技術が必要。それはさておいても、ロードマップやバックログを作成する際に許可やレビューを受ける必要がない。”プロダクトディレクタはロードマップに載っている事ついてすら全てきちんと知ってはいない。”  プロジェクトマネージャの数は比較的少ないが、彼らは皆、社内の本当に重要で個人的に興味のある部分について責任を負っていると感じている。
  • デフォルトではコミットした全てのコードは週ごと(火曜日)のリリースパッケージに含められる
  • さらに多くの手続きを踏めば、同日に変更点をリリースすることも可能
  • 火曜日のコードリリースの条件として、その週のリリース候補に対してコードをコミットした全てのエンジニアがon-site状態であること
  • エンジニアは「コードのリリースの知らせ(roll call)」を待つためリリースが開始される前に特定のIRCチャンネルに現れる必要があり、そうしないと公に「さらされる」
  • オペレーションチームはリリースするコードを徐々に反映させることにより実行する
    • Facebookには60,000台程度のサーバーがある
    • 新しいコードのリリースには9つの concentricレベルが存在する
    • [CORRECTION thx epriest] “この9つのレベルは同心的(concentric)ではない。3つの同心的なフェーズが存在する(p1 = 内部リリース、p2 = 小規模な外部リリース、 p3 = 完全な外部リリース)。 他の6つの段階は付属的なものであり、内部ツール、ビデオアップロードホストなどである。”
    • 最小のレベルでは6サーバーだけになる。
    • 例えば、火曜日の新規リリースが6サーバーを対象に行われる(レベル1)場合、オペレーションチームはそれら6つのサーバーを監視し、正しく機能していることを次のレベルへと移行する前に確認する。
    • リリースが問題を引き起こした場合(例えば、エラーが出る、など。)には更新を停止する。問題となるチェンジセットをコミットしたエンジニアは問題の修復に専念することになる。そしてリリースはレベル1からやりなおしとなる。
    • リリースは同じレベルを繰り返し通過する場合がある:  1-2-3-修正。 1に戻る。 1-2-3-4-5-修正。1に戻る。  1-2-3-4-5-6-7-8-9。
  • オペレーションチームはよく訓練を積んでおり、大いに尊敬される存在であり、ビジネスにとても敏感だ。彼らのサーバーメトリクスは通常のエラーログ、負荷やメモリ使用統計の上を行く --- ユーザーの行動も守備範囲だ。例えば、新規のリリースによってFacebookの機能に関わるユーザーの割合が変化した場合、オペレーションチームは彼らの基準でそれを検知し、それを理由にリリースを中止して調査を行うことができる。
  • リリースの過程において、オペレーションチームはIRCベースのページングシステムを使用してFacebook、メール、IRC、メッセンジャ、SMS経由で個々のエンジニアに対して必要に応じて通知できる。おぺれーshチームに対して応答しない場合は公にさらされる。
  • コードがレベル9に達して安定している状態になったら、週ごとの更新で完了する。
  • ある機能がその週の更新に間に合わなくても、大したことではない(外部的に重要な依存関係がない限りは)--- 一般的に、ある機能は完成した段階でいつでも投入される。
  • svnでblameされたり(ソースレポジトリ上のある変更点について非難されたり)、公にさらされたり、プロジェクトを頻繁すぎるほど失敗させたりすると、エンジニアは解雇される。「とても高度な達成度が要求される文化だ。」  マネージャ(上司)は文字通り達成度の低い者たちを6ヶ月の雇用期間で振り分けて「どうもこれではうまくいかない。君はうちの文化には合わない。」と伝える。これは実際のところ、この会社のあらゆるレベルにおいて行われることであり、C(最高責任者)レベルやVP(副社長)レベルであったとしても、彼らが「超」生産的ではない場合は即刻免職となる。
  • [訂正、epriest氏の指摘]  “バグを出すことで呼び出されることはない。 リリース時に変更点を含める依頼をしているのに、そのときに念のため対応できるように待機していない(そして代わりにそれを補ってくれる人も用意していない)場合にのみ呼び出される。
  • [訂正、epriest氏の指摘] “非難されたからといって解雇はされない。 この観点から言うと我々は極度に寛容であり、シニアエンジニアのほとんどが最低1度は恐ろしいことをしでかしており、私も例外ではない。知る限りでは、このような性質の過ちを犯したことで解雇された者はいない。”
  • [訂正、fryfrog氏の指摘] “この記事に書かれているような間違いを犯したことで解雇されてしまったというような人は私も知らない。不注意でサイトをダウンさせた人達を知っている。問題を引き起こしたものが何であれ頑張って修正するし、誰でも失敗から学ぶ。個人的な意見では、公の場でさらされるのは解雇の恐れよりも格段に効果的だ。

Facebookの開発文化がこの先時間の経過とともにどのように進化していくのかを観察するのは非常に興味深い。特に、もしこの文化が数千人レベルの従業員を抱えるまでに成長した段階でもそれに応じて拡大できるのかを見届けたい。


「あなたはどう思いますか?」「開発者主導の文化」はあなたの会社ではうまくいくでしょうか?