言語ゲーム

とあるエンジニアが嘘ばかり書く日記

Twitter: @propella
トップ > QCon Tokyo 2014

QCon Tokyo 2014

http://www.qcontokyo.com/ にお邪魔しました。一日一杯勉強しました。

ベロシティ(速度)の好循環： 速く進むことの重要性に関して、GoogleとeBayで学んだこと : Randy Shoup さん

  • eBay, Google を経て Kixeye (ゲーム会社) の Google App Engine 対応
  • 速い組織の作り方
  • 量より質
    • User Experience as whole
    • Less is more: ユーザは中途半端な二つの機能よりちゃんと動く機能が欲しい。
  • Culture of learning : 失敗から学ぼう
  • Google の blame free post mortems 誰も責めないで問題分析
    • 問題を文書化し、誠実に議論する。
    • エンジニアは我も我もと責任を負いたがる。
      • 何故かと言うと、良い物を作りたいから。
  • Service Team
    • 小さく、きちんとインタフェースが定義されたチーム
    • チーム間に「契約」が存在する (このチームは○秒以内に反応する○を作らなくてはならない)
  • Ownership Culture
    • ツールを選べる自由
    • 明確な目標
    • 目標の例: 「ゲームに使うスケーラブルなシャーシを作る」
      • 最小、最短のリソース (3人1ヶ月)
  • プロセスとは実験です。
    • Launch はただの最初のステップ
    • A/B テストで改良してゆく。
    • この実験的手法で eBay の打ち上げを 2% 上げた。
  • 品質は優先順位 0 (何より重要)
    • 砂の上より固い地面の方が早く走れる。
  • Google の技術
    • Code review, automated test, single logical repository.
    • 単なるバグレポートは存在しない。
      • バグレポート、修正コード、テストコードが報告される。
  • 技術的負債を管理しよう。不足をいつ返すのか決めておく。
  • Google の採用戦略
    • False negative is ok but false positive are not.
    • 迷うなら雇わない
  • eBay の反省
    • Train Seat 方式
    • Designer が設計を列車の椅子に詰め込んで Implementer が実装。Designer は実装しない。
    • 上手く行かなかった。。。

ロボットは東大に入れるか？ : 荒井紀子さん

  • 1997年にチェスのチャンピオンが IBM deep blue に負けた。
  • 2013年に将棋のプロが負けた。電王戦
  • 東大入試はチェスのや将棋より難しい。
    • コンピュータにとって知的レベルは関係ない。
  • どれは犬でしょう？
    • 80年代の解き方。特徴を抜き出す「猫の耳は三角」例外が多すぎて失敗。
  • なぜ東大入試は解けるか?
  • 機械学習: 論理は無いけど結構正しい。
    • 東大入試を分類問題として捉える。
  • 過去問を学習すれば良いか？サンプルが全然足りない。
  • 相談すると、「第五の事を忘れたか！」と言われた。
  • ワトソンは問題の型が決まっていて、固有名詞を答える。
    • 東大入試はもうちょっと難しい。
  • 論理と確率統計で東大に入れるか？
    • 必要なもの
    • 含意関係、正確な言語処理、否定や論理を理解できる。
    • 社会科や英語は素晴らしいサンプル。
      • 教科書と同じ文が存在しない。
  • 東ロボ君は半数くらいの市立大学に入れると代ゼミが判定。
  • なぜ東ロボ君を作りたいか?
    • 福井県三国の博物館に船の写真があった。
    • 鉄道の時代になってすぐに寂れてしまった。
    • 「コンピュータが仕事を奪う」を書いた。
      • コンピュータに解けないとはっきりしたら人間にアウトソースすれば良い。
      • 人は承認欲求があるのでタダで働く。
    • 知的コンピュータによって上下に分断される労働。
    • コンピュータに出来る事のエッジを明確にする事が重要。

人気クラウドアプリ Summly が低予算で可用性 99.999% を実現したクラウドの旅: Eugene Ciurana さん

  • Spider-Man の服で登場
    • なぜ Cloud を使うのか? モバイルではバッテリーが大問題! 出来るだけクラウドで処理。
    • アプリは常にオンラインに見えなくてはならない。
    • デバイスをキャッシュとみなす。
  • Pricing horror story with Amazon EC2
    • 70,000 USD/day
    • Understand the cost model
    • Use open source
  • Typical BAD application architecture
    • iOS or android
    • App server
    • Message broker
    • Database
    • Caching ... Later
    • (どうすれば良くなるのか忘れました。)
  • Managing your cloud
    • Find macho devopos
    • Chef pupper
      • Plan configuration not vm
  • Monitoring
    • Zabbix
    • New relic
  • Use Jason-ld
    • All API should be stateless raml.org
    • Smart caching in DB won't scale
    • Brewer's CAP theorem
  • Caching
  • Summly のサーバ構成について
  • 質問: 設計を助けるツールはあるか。
    • ログをとって分析する

DevとOpsをより良い関係に導く、新世代のアプリケーションテスト : 西野 寛史さん

  • 日本 CA で ITIL (運用ノウハウ集) に関わる
  • Google トレンドで伸びてる。特に日本
  • 開発と運用。お互いのゴールは同じなのに壁がある。
    • 開発 用意なアクセスすぐ実施実用性
    • 運用 セキュリティ、正しく実施、準拠重視
  • DevOps とは?
    • 開発と運用のコラボレーション
  • DevOps の目的 開発と運用の組織横断的改善活動 (特に日本では)
  • 「CA DevOps 調査」で検索して下さい。
    • 日本企業の 47% は企業の作業工程の改善を重視
    • 日本以外ではビジネス目標(売上等)の改善を重視
  • DevOps の技術領域
    • リリース自動化
    • アプリケーション監視
      • アプリケーションのトランザうション(実際のユーザの振る舞い)に沿って監視(APM)
      • 問題発生時「うちじゃないんじゃないの?!」とつい思っちゃう。
      • APM によって問題の切り分けを行う。
  • テストの革新がなぜ DepOps か?
    • リリース前アプリ品質向上 : どんどんテスト
    • テストのスピードアップ : さくさくテスト
    • 異常時の認識共有 : いろんなテスト
  • 日本の家具メーカーの例
    • 二つの部品が上手く噛み合わない。
    • 自動車の製造プロセスにならって治具ありきのプロセス
    • 部品単位で治具を当てはめ、部品ごとに検品。
    • 最終検品が不要になった!
  • 航空機開発の例 (プロトタイプ飛行まで) シミュレーションありきのプロセス
    • シミュレーション設計によって組み立ててクラッシュする必要が無い。
    • シミュレーションによって環境を完全にコントロール出来る。
  • IT の世界 (SDLC) V 字モデルに重ね合わせると。。。
    • コンポーネント志向テスト
      • 組織論:
      • プロセス論: 機能面ではこれから、性能面では確立されている。(全体は何秒だから、この部分は何秒で。。。)
      • 技術論: 治具 サービス仮想化ツール(スタブとドライバ)
        • 自作スタブ。機能が貧弱。
        • UI - Backend に渡って高度なシミュレートを実現出来ないか? サービス仮想化ツールを使ったら出来ます。
  • サービス仮想化ツール
    • ドライバとスタブでサンドイッチ
      • ドライバ側は割りとある。スタブはあまり無い。
    • キャプチャ&プロセスモデル 実際のトラフィックを元にシミュレータデータを生成

Enterprise Cloud Design Pattern 〜前編：クラウドアーキテクチャ−の3要素〜 : 谷口 有近さん

  • 今日の話
    • 非同期: 入力と出力、長時間ロードの分割　-> CPU 時間を変換
    • 運用性: 負荷移動 -> 人の次アカンを変更
    • 完全性: -> 情報の時間を変更
    • クラウドとは? CPU 時間変換と障害管理に尽きる。
  • 。。。でない三要素の話をします。 普通の話が聞きたい方は Architect Bootcamp に来てください。
  • ACE http://a-c-e.biz の紹介
  • 今日の話のキーワード:「復元力」壊れる事を前提に設計する。
    • 2000 年以前: 壊れないシステムを指向する。
    • 2000 年以降
      • 予期せぬ負荷が起こる:
      • 構成変更しやすい基盤構成で負荷バランスを調整
      • 運用自動化と分散処理で回復しやすいシステムを指向
  • 「壊れないシステム」 -> 「柔軟なシステム」
    • 行き過ぎた仮想化はコストが下がらなかった。
    • コード側での実装が必須になった。
  • トレンド
    • 負荷分散 〜2000前半 L7 persistent -> 2006〜 L7 stateless -> 2012〜roundrobin
    • 2012- クラウド分散処理: 機能毎の SLA, バックアップ困難、コード構造単位のシステム設計、一日数回更新。
    • 実装負荷が高い非機能要件は PaaS 側でカバー
      • 例: Azre Web Sites
  • 復元力
  • 新しトレンド - サイエンス指向の言葉で会話
    • Business Architect : SLA を決める
    • Infra (Model) Architect : データの整合性、数理的観点
    • Code Architect : 運用負荷を決定するコードの負荷を考える
    • 将来は Infra Architect は居なくなる? (クラウドの役割になる)

.NET Microframework : 太田垣寛さん 新館さん

Ameba 流 Scrum を浸透させていく方法 : 大崎浩崇さん

  • アメーバピグのアイコンを使った可愛らしいプレゼン。
  • 2010 - 2012 開発者の急増で混乱した為、Scrum を導入。
  • 良い噂が広まった。
  • 品質を担保・自律的なチームへ
  • 役員が興味を持ち始めてくれた
  • 社内研究レポートで受賞
  • 社内勉強会が多く開催された。
  • 2014 統一期: 人材の流動性を高めるために開発の統一化が検討されていた。
  • 開発支援ツールの統一: JIRA, JIRA Agile, HipChat, Confluence,
  • Scrum を組織に浸透させる Tips
    • 強制されると移植する -> 真似されることによって自律的な浸透を促す。
    • 組織の目標と Scrum の目標が異なる場合 (組織の目標がKPI 等の目標数値の達成の場合)
      • パターンを作って一つ一つ試す (Jenkins 自動ビルド等)
      • チーム内で別の管理方を作る(デザイナーはカンバン方式等)
  • タスクの粒度と WIP 制限
    • 進行中のままになっているタスクがあったら翌朝の朝会で議論
  • ストーリーの並列着手を辞める
    • みんなで一つのストーリーを進める
  • 質問: 真似から広めたという事ですが、間違って広まってしまう事もあるのでは?
    • 正しい Scrum というよりは成果主義が浸透している。Scrum として間違っていたとしても成果があれば良いとみなしている。
  • 質問: Scrum Master はどれくらいいるか?
    • 厳密には Scrum Master はいない。
    • 流動性が高いので、良い悪いの噂はすぐ広まる。
  • 質問: ツールの選定はどうやったか? 新しいツールを使いたい人がいたら?
    • JIRA が良かったので Confluence HipChat を選んだ。
    • 新しいツールについては良いかなと思う。古いツールを使っている人には移行をお願いする。
  • 質問: 失敗したプロジェクトはあるか

生活家電インタフェースの新潮流 : 塚田浩二さん

  • イグノーベル賞受賞研究: スピーチジャマーを作った人
  • 知識よりも刺激を与えたい。
  • 日本人の受賞例
    • たまごっち。バウリンガル。糞からバニラ。粘菌(粘菌がパズルを解ける)
  • イグノーベル賞を受賞するとどうなるか?
    • ノーベル賞と勘違いした近隣からの祝辞
    • 旧友からの連絡
    • 訳の分からないメールが来る (どこからとも無く聞こえる声を消して欲しい等)
  • 日用品インタフェース
    • Ubi-Finger: 複数の家電を指さして、さらにゼスチャで操作
    • ActiveBelt: 地図を見なくても触覚情報でナビゲーション
    • 実験住宅: Tagtansu ハンガーにタグを付いている。ハンガーに服を吊るすと写真が撮られ服をデータベース化。コーディネートを記録出来る。
    • Drawerfinder 収納棚にカメラを付けて収納箱の写真を撮りwebブラウザから閲覧。
      • 誰が物を持って行ったかわかる。
    • Lettertwitter 郵便箱の中身をメールしてくれる。
    • Awarehanger 洗濯物が乾いた事をがわかる。非常に安く作れる。
    • MediAlarm 就寝状況を twitter に投稿。他の人がリプライすると目覚ましが鳴る。
    • SyncDecor 遠距離の家電(電灯やゴミ箱)が同時に動く。遠距離恋愛のカップルが一緒に住んでる感じ。
    • Eathermin 食べると物によって音が鳴るフォーク
  • プロトタイピングの講義 研究室の機材でだいたい何でも作れる。
  • 空気のようにデバイスとwebを融合
  • 社会参加型研究室
  • Quantified self Tokyo