制作記事 Web制作WEB設計実例編Facebook Engineering Talk

Facebook Engineering Talk

いつかどこかで見たスライドだったか、誰かがまとめた記事だったのか、すいません、出典元は忘れてしまったのですが、ローカルで見つけたデータをマルっとコピペして公開。とても刺激的で、さすがだなーと改めて感心します。

“Fail Harder”
もっと激しく失敗せよ

  • 失敗しないとイノベーションならず
  • 「失敗は成功の基」精神

“Move Fast and Break Things”
速く動いて色々壊せよ

  • 新入社員は雇われて1週間以内で何かを本番へリリースしないといけないらしい(ブートキャンプ)
  • hackathon
    →徹夜してハックハックハック^^;
    →プロジェクトは適当に選んで作る
    →『目的は「行動を起こす為のエネルギーの壁」を乗り越えるためだ』

“What would you do if you were not afraid?”
もし恐怖を知らなかったら、あなたはどんなことをするのか?

  • 恐怖はいいんだけど、短期的に痛い変更をする決断力も必要
  • Facebook Platformでfeedに書き込めないようにした
    →難しい決断、苦しかった
    →スパムが多過ぎて結局見たい情報が埋もれてしまっていた
  • Graph APIをリリースした
    →既存のAPIがやっぱりダメだったから

“This ___ is 1% finished”
この○○は僅か1割しかできていない

  • 満足しちゃいけない
  • 「これからだよ、これから」精神

雑談

  • 翻訳は、人を雇えない程度だったからコミュニティに任せた。
  • 端末データベースを作るために、pageを作って、見てくれた人から属性を抽出した
  • グリーン・エネルギー
    →データセンターやHPHPなどで
  • 大きく変更したときに反発が起きるのは仕方がない
    →ユーザテストを必ず行う
    →熟慮する
    →利用データを追跡する(多く使ってもらえたら成功)
  • マネタイズよりはユーザ体験を重視する
    →勿論、バランスが大事
    →広告はよりユーザに関係性の高い物を出せる
  • リリースは
    →毎日、一日数回
    →火曜日に大きな変更(アプリケーション)
    →runtimeは別の日
  • 開発フローは?
    →各自開発サーバある(っぽい)
    →reviewツールもある
    →ソース管理へコミットすると自動的にリリース候補になる
    →テスト(自動、手動:社員皆で)
    →事故はコード書いた本人に責任追及(リリース中はずっと待機)
    →機能毎やユーザ毎のスウィッチがある
    →→ユーザの0%~100%や社員のみとか、細かく機能の有効・無効切替ができる
    →→コードはリリースしておいて、後日に機能をスウィッチで切り替える
  • どんなスタック?
    →PHP & JS で page templates
    →MySQL (sharded (1000s) and bucketted)
    →→basic user data
    →→memcache とか
    →”haystack”(ビデオ、写真)
    →mbox? search は Cassandra
    →Hadoop で data processing/analysis
    →”multifeed”でnews feedのキャッシング
    →”ad serving system”
  • 主competitorsは?
    →Googleがちょっと怖い

【2008年から2014年までのメモを整理してて備忘録に残そうと思ったこと No.2】