ぱろっと・すたじお

技術メモなどをまったりと / my site : http://parrot-studio.com/

Developers Summit 2014 2日目 まとめ

devsumi2014

1日目の続きです

Developers Summit 2014 1日目 まとめ - ぱろっと・すたじお

Developers Summit 2014：開発者のためのITカンファレンス

デブサミ2014、講演関連資料まとめ：CodeZine

2日目は例の大雪でえらいことになり、
さすがに雅叙園前の急勾配は危ないだろうと、
Amazonさんの入っているビル経由で向かいました

エントランスももちろん綺麗なのですが、
度肝を抜かれたのは社食と思われるホールです
これが吹き抜けでびっくりするほど広いという(lllﾟДﾟ)

柱にはダンボーのイラストも描いてありましたが、
勝手に写真を撮るのもためらわれたので撮ってません
共用エリアから見えるので、一度見てみると面白いと思います

ただ、ビル内で相当迷いまして、
そもそもどこからどこまでが「入っていいエリア」なのかもわからず、
「THE・リア充」な雰囲気とあわせて混乱しましたΣ(ﾟДﾟ；≡；ﾟдﾟ)

2つ目のセッションから参加で、他に人が少なかったのもあります
人がたくさんいれば後ろをついていけたのですが・・・

14-B-2 グリーを支えるデータ分析基盤の過去と現在

「ビッグデータ」という言葉がバズワード化してしまってあれですが、
真の意味で「大規模なデータをどう分析するか」のお話でした

ただまあ、正直ここまでの規模のデータ分析（システム）は、
よほどの大企業・・・それこそGREEやDeNAクラスでないと、
とても考えられないレベルだと思います(lllﾟДﾟ)

ただ、他のセッションでも頻繁に出てきた、
「Fluentd」は気になりました

http://fluentd.org/

アーキテクチャの説明を見ていただければわかると思いますが、
ログデータを構造的に扱うため、入出力を仲介するもの・・・と考えればいいでしょう
Ruby系WebアプリにおけるRackの立ち位置だと思います

データをJSONとして扱っているのもポイントで、
これにより構造的なログ解析が可能になっているわけです

うちのような普通の会社であっても、Fluentdは使えそうな気がするので、
今度提案してみようと思います...φ(･ω･｀)

あと、Hadoop周りに関しては、あまりに規模が違いすぎて縁がないというか、
Hadoopの出始めの頃に買った本がまだ手つかずだったり・・・
技術的にどうって前に、そこまでのサーバリソースはなかなか用意できませんし

  • 既存の構造
    • Webサーバ->ストレージ->MySQL->分析
    • ストレージ->バッチ->分析
    • ストレージ/DB->SQLServer（生データっぽいもの）
  • 問題点
    • データ分析するユーザが増えた
    • エンジニアがデータを提供するのが難しく（人が限られる）
  • 改善へ
    • Accessability：誰でも自由に
    • Scalability：システムがスケールするように
    • 既存は維持
  • Treasure Data
    • Hadoop構築不要
    • ログの集積：fluentd
      • スキーマレス
      • データウェアハウスのコスト低減
      • BIツールと連携可能
    • 規模
      • ゲーム20タイトル
      • Webサーバ2000台
      • log aggregatorサーバ40台
      • 1TB/月
  • データ分析基盤
    • ログから分析して改善
      • Webサイトのアクセス改善を応用
    • ジョブ管理
      • 投げられた分析タスクを監視
  • ログ解析
    • ページ遷移（GoogleAnalyticsっぽいあれ）
    • 離脱（ユーザ属性・プレイ時間など）
    • クリック
      • Chromeの拡張で画面にクリック分析データをオーバーレイ
      • JSでクリックログを送信
  • 分析ジョブ管理
    • 社内一般ユーザにデータを解放 => 非効率なジョブが投げ込まれる
      • ジョブの可視化
      • 送信元の特定
      • スロークエリの可視化と判定
      • 強制kill
  • （以下、Hadoop周りの具体的な実装については割愛）


14-C-3 Web Platform 最前線 ～Web技術とアプリ開発のトレンド～

Slide : (not yet)

今年のデブサミで、自分にとって一番インパクトがあったというか、
パラダイムシフトを感じたのがこのセッションでした
資料が現時点で公開されていないのが残念です(´･ω･`)

いわゆる「WebOS」、さらにいえば「FirefoxOS」の話なのですが、
それが意味するところは「ブラウザOS」よりもはるかに大きくて、
「ソフトウェアとハードウェアの標準化」くらいのインパクトがあると思います

今までのOSにおいては、ハードウェアとのやり取りにデバイスドライバを使っており、
OSレベルで「API」としてハードウェアの機能を隠蔽していました
逆に言えば、OSレベルAPIの範囲でしか互換性を持たなかったのです*1

一方、現在W3Cが目指しているのは、
まさにその「ハードウェアレベルAPIの標準化」であり、
その現時点での実装が「FirefoxOS」なのです

ある意味、OSとアプリケーションが真の意味で分離されようとしており、
その技術としてHTML5とその周辺技術が存在しているわけです
OSやハードウェアを意識せずに、本当の意味でアプリが汎用化される可能性があります

かつてはJVMや.NETという形でバラバラに「マルチデバイス化」されていた概念を、
WebAPIという形で標準化しようとしているわけです
なので、おそらく「ブラウザOS」という表現は本質を捉えていません

もちろん、現時点ではまだパフォーマンスに問題があり、
機能もまだ揃っていません*2

ただ、WindowsやIEが今ではWeb標準に従っているように、
悪い意味で「昔のWindows化＝断片化/独自仕様化」しているAndroid等も、
何年先かはともかく、後々追随してくる可能性はあるでしょう

このセッションを聞くまで、FirefoxOSについて、
「真にOSSのAndroid」くらいの認識でいましたが、
全然見ているものが違いすぎました(ﾉ´･ω･)ﾉﾐ(m´_ _)m

個人的に思ったのは、CやJavaで実装されている「Ruby」が、
JavaScript上で実装されたとすると、相当面白くなると思うんですけどね・・・
その鍵を握るのが「asm.js」だとは思いますが(´-ω-) *3

ということで、FirefoxOSが動く端末を手に入れたいと思ってますが、
海外から輸入ってのも面倒なのでどうしたものか・・・

  • 背景
    • 従来：OSごと / Webはサブセット扱い
    • プラットフォーム依存
    • 不透明な継続性性・再利用性
    • 分断・実装依存
  • "APIが標準化されていない"
  • Web Platform
    • マルチデバイス（言語やAPIの共通化）
    • ベンダー非依存（持続性）
  • ブラウザ上で動くアプリ
    • ブラウザの開発にエンジニアリソースが割かれるように
  • Firefox Apps / Chrome Apps -> ローカルAppと区別できない
    • 例の「Flappy Bird」はFirefox Apps
  • WebOS
    • FirefoxOS / ChromeOS / TizenIVI / webOS -> Web主体
    • Win8 / Tizen Mobile -> ネイティブ主体
      • TizenはIVI と Mobileはカーネルが共通だけど別物
      • Tizen IVIはWebベースで完全にかける
  • WebOSが各種デバイスへ
    • モバイル/テレビ/デスクトップ/車載/健康/ライフサイエンス・政府/教育/ビッグデータ
    • ChromeOS -> アメリカのノートPCの20％（3万くらいの端末）
    • FirefoxOS -> 新興国系でそこそこ売れている
  • 課題：機能不足・パフォーマンス不足・エコシステム
  • デバイス系機能の標準化
    • 例：バッテリー残量取得のAPI化
      • FirefoxOSで実装 -> 他のOS
  • 大規模アプリでは遅い
    • asm.js
      • Cと比較して数十倍遅い から 数倍遅い程度まで＝Java/C#と同程度以上？
      • 現在はCの1.5倍程度（ただし苦手な処理もある）
        • （asm.jsを「ちょっと早いブラウザJS実行系」くらいに思っていた）
        • （実際はもっと上の概念のために実装されている）
  • Webテクノロジー
    • HTML5/CSS3を中心にかなり広域に
    • モバイルOSの標準化はほぼ完了
      • TVや車載OSはW3C以外との調整がいまいち
    • 実装されないと意味がない -> 今年色々出てくる？
  • UNREAL Engine
    • Webだけで3DゲームレベルもOK
      • （デモがめちゃくちゃ綺麗で軽くびびる(lllﾟДﾟ) ）
  • AOTでロードタイムも軽減
  • GCも軽減する手段がある
  • デスクトップのリモート実行
  • AmazonのGPUインスタンスで画面を描画
  • 「赤いきつね」：赤いネクサス5にFirefoxOS
    • （やりたいけど、お金が・・・(´-ω-) ）
  • OSが軽量なのでメモリを積まなくてもOK -> 安く売れる
  • OSカーネルとブラウザが分離されている
    • セキュリティパッチをブラウザレベルでできる
  • パナソニックがスマートTVをFirefoxOSで
  • 今後も端末やデバイスがいろいろ


14-C-4 DeNAにおけるゲーム以外の新規事業の立ち上げ方

Slide : https://speakerdeck.com/okitsutakatomo/debusami2014-14-c-4-denaniokerugemuyi-wai-falsexin-gui-shi-ye-falseli-tishang-gefang

DeNAは今でこそソーシャルゲーのイメージが強いですが、
元々はオークションや広告等、様々なカテゴリで事業を行っている会社です*4

とはいえ、今の主軸は間違いなくソーシャルゲーであり、
同時にソーシャルゲー自体がもはや微妙な立ち位置になっているため、
「次」を開拓するのは急務だと思います*5

そんな中でのこのセッションだったわけですが、
「事例」に寄っていて、非常に面白い内容でした(｀･ω･´) ｂ

ある意味では「今風」のやり方ではあるのですが、
そのバックボーンに「確立された技術」があるように見えましたし、
なによりとても「現実的」だと思います*6

  • エンターテイメント事業本部
    • 非ゲーム事業をやる
    • ゲームの次の領域を探す
  • マンガボックス
  • Showroom
    • アイドルのパフォーマンスを配信
    • （文字列ではなく）アバターが視覚的にコメント
    • UIでニコニコ等と差別化している
  • etc...
  • 一つの事業部で全部回している
    • "やることが多い"
    • 基本的な人員構成を揃えつつ、他の部署が全面的にバックアップしている
  • DeNAのスクラム
    • 守・破・離
    • 過去：スクラムフレームワークに忠実 -> コストがかかる
    • 現在
      • スクラムマスターを廃止
      • タスクの粒度を荒く、ストーリーポイント廃止
      • バーンダウンチャート廃止
      • タスク管理はチームでやりやすい方法
      • 少人数体制で適宜周囲がサポート
      • チーム単位で座席をまとめる
    • 各自が考えて行動している感が高まる
    • 少人数なのでコミット意識高い
    • 定量的な進捗管理をなくしたけど遅れはあまりない
    • 人が増えてくると意思疎通等のコストが -> 適宜最適化
  • プロダクト
    • みんなで必死に考える -> 作る -> 使われない
    • ユーザにインタビュー -> ⚪︎⚪︎機能に需要が -> 作る -> 使われない
    • "ニーズを検証する"
  • 例1：チラシル
    • 検証項目
      • 暮らしの中で使ってもらえるか？
      • 長期的に使ってもらえるか？
      • 紙と同じように使ってほしい
    • 練馬区限定でバイト募集 -> 社内に呼んで使ってもらう -> フィードバック
  • 例2：アプリゼミ
    • 検証項目
      • 長時間勉強して欲しい
      • 長時間勉強するのに何が楽しいか？
      • 親は子供が勉強しているかしりたいのか？
    • 最小限のモックを作って親子に評価してもらう
  • 例3：peko -> USの大学生向け
    • 検証項目
      • 初対面でもコミュニケーションは成立する？
      • 位置情報とか気にする？
      • FBログインは使う？
    • USの大学前でチラシを配ってテスター募集
      • 2週間試してもらう
      • ログを仕込んでおいて、何を使ったのかを調べる
      • ヘビーユーザにインタビューもする
        • アンケートだとFBログインを使いたいのは半分程度
        • 実際に使わせると8割は使っている
    • 定量化は重要
  • 企画の進め方
    • プロデューサーとエンジニアが意思疎通して意思決定
    • 9サービス中4サービスはエンジニアが立案
    • 全ての意思決定にエンジニアが参加
    • UserTesting,com
      • リモートでアプリを使ってもらう
      • 日本でも徐々に出てきている？
  • アーキテクチャ
    • リードエンジニアが好きに決めている
      • 結果的にPerlが多い
    • JSON-RPC or JSON on HTTP
  • 自社のデータセンター
    • ソーシャルゲーで鍛えられたインフラ部隊
      • たいがいのことは解決してくれる
    • 必要ならAWSも
  • スケーラビリティ
    • どんなにスモールスタートでも意識する
  • インフラ基本構成
  • コミュニケーション
    • GitHub Enterprise
    • 全リポジトリを全エンジニアが見られる
    • デザイナもpull-request
    • 画像のやりとりも
  • ネイティブアプリ
    • iOSかAndroidかどちらかを集中開発
    • いけそうならもう片方
    • 当たるかわからないものは最小のリソースで
    • ほとんどiOS6対応だが最近はiOS7専用が多い
      • カバー率よりスピード
    • Androidは2.3以降をサポート
  • 通知
    • OSが提供するpush通知だけではコミュニケーションスピードに対応しきれない
    • TCPでonlineサーバと常時接続（APIと別に）
      • （バッテリーとかどうなんだろう・・・？）
    • Node.jsでWebSocket
    • 通知以外でも常時接続を活用
  • 分析用のロギング
    • Server -> Fluentd -> HDFS
    • 分析者（非エンジニア）：HiveQLでHive
      • （GREEもそうだけど、DeNAでもプロデューサークラスがHive等を使えるのが前提になっている？）
    • バッチによる分析
  • ログの種類
  • 広告
    • リリースしても何も起こらない
      • ほっといても30-40程度
    • 広告を使ってユーザを流入させる
    • FacebookAdやTwitterAdはお安い
  • FBAd
    • キャラクター系 / 人物系 / アプリのUI系 -> どれが効果的か？
      • アプリのUIを見せるのが一番クリック率高かった
    • オフラインプロモーション in US
      • バーで「ビールをおごるからアプリを入れて」
  • 1年振り返って


14-A-6 Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所

Slide : http://www.slideshare.net/sifue/developers-summit-2014-play2scalaweb

えー・・・資料みてください、以上Σ(・ω・ノ)ノ

いや、あまりに高密度すぎて、Scalaの件あたりまではきっちり聞いていたのですが、
後半のスクラム周りは( ﾟдﾟ)ﾎﾟｶｰﾝと見ているしかなかったので・・・

この事例からもわかるのは、「フレームワークの作り直し」をする際に、
必要なのは「少人数のできる人"だけ"で構成されたチーム」ってことです

フレームワークができあがれば、多少の差を吸収できますが、
やはり基盤部分は「わかる人」が手を動かすのが最速である、ということです
今の「はてブ」だって、最初はnaoya氏が一人でベースを作ったわけで

ただ、後で個人的に思ったのは、ちょっとScalaにこだわりすぎかな・・・というところで

今の仕事をするまでは、私もそこまで考えてなかったと思いますが、
適切にサーバサイドAPIとViewが分離されていれば、
View側のアーキテクチャまでScalaである必要はないのではないかと

というのも、発表の中でScalaのテンプレートで引っかかっているという話があり、
わざわざGroovyまで使っているとのことですが、
それならいっそView部分だけPHPで実装する手もあったのでは

もちろん、PHPでは既存のアーキテクチャに引きずられるとか、
パフォーマンスの問題とかいろいろ背景はあったと思いますし、
そもそも、私ごときが何言ってるんだって話なんですが(´-ω-)

あと、DDD周りの話を見ていて思ったのが、
大規模なWebシステムは、もはやSIの領域と何ら変わりない、ということで

大規模化したシステムを滞りなく動かすノウハウという意味では、
どう考えてもエンタープライズ系が先行しているわけですが、
表面上のレイヤーが違うだけで、やってることは一緒になってます

その辺に気づいているWeb企業が、SIerの転職を歓迎していたりするわけで、
おそらくドワンゴもそういうフェーズに入ったってことでしょう*7

その他、細かいことは資料でみてください(´･ω･`)



ということで2日分をまとめてみました

やはり自分の中でインパクトがあったのは「FirefoxOS」です
別にフォクすけを愛しているからではないですよ(´･ω･)？ *8

エンジニアってやっぱり怠惰なもので、「面倒なこと」はしたくないわけですよ
例えば、環境ごとに言語レベルでコードを書き換えるとか

その現時点での解が「Xamarin」等の開発環境であり、
未来における解がFirefoxOSが目指す「APIの標準化」なのだと思いました

前回の冒頭でも書きましたが、
「未来の話」はそれはそれで面白いし大事なのですが、
「今、何ができるか？」はより重要です

とりあえず、「私が今できること」は、FirefoxOS周りの情報収集ですかね・・・(´-ω-)

*1: Windows同士とか、Mac同士とか・・・

*2: とはいえ、Rubyだって当初は「こんな遅い言語は使えない」と言われていたそうですが、今は時代が変わり、むしろメインストリームの一角です

*3: どちらにせよ、何年も先の話でしょう。でもRuby界隈の人なら考えそうな話で・・・

*4: GREEに比べると、圧倒的に「手堅い」イメージがあります。でなければ球団とか持てません

*5: とはいえ、GREEやソーシャルゲーに特化してしまったWebゲーム会社に比べればはるかにましかと

*6: 後に出てくるニコニコの事例は、たしかに「ハイレベル」ではあるのですが、まだ「教科書通り」のレベルから大きく離れていないというか・・・(´-ω-)

*7: C++の有名人を雇用（？）したりもしているようですが・・・Σ(ﾟДﾟ)ｶﾞｰﾝ

*8: Android版Firefoxのキャンペーンで当たったフォクすけぬいぐるみは、家宝として大事にしまってあります(*ﾟ∀ﾟ)=3