2011/02/18 デブサミ2011 セッションメモ - fslashtのサアラたん日記

　デブサミことDevelopers Summit 2011に参加してきました。
　２日間の開催ですが、二日目の午後から参加。
　会場は目黒の雅叙園です。

　雅叙園、もう何度も行ってるけどこの手のイベントの時ばっかだ…

　どのセッションもほとんど満席。
　セッションについては「デブサミ2011 資料・Togetter集」が大変参考になります。

　上記のまとめもあるので、あんまりいらないと思いますが、セッション参加中とったメモを載せておきます。
　GREE 伊藤氏のセッションが開発手法の選択や各種ミドルウェアの紹介が大変参考になりました。

※ メモ内容については正確ではないかもしれませんのでご注意。資料公開されてるセッションについてはそちらを見たほうがいいです。

●【18-A-3】スマートフォン向けソーシャルアプリケーション開発の現在　GREE 伊藤直也氏

【ビジネストレンド】
世界での出荷台数：スマートフォン（１億台）＞PC（９２００万台）

３G回線の成長は、日本は成熟。US,中国が急激に伸びている。
日本でのスマートフォンの契約台数は、2000,4000,6000万台へ（2014年でガラケーのシェアを超える）出荷台数でも、2010年では若干うわむきに
音声ARPU減少分をデータARPU上昇が補う（スマートフォンがデータARPU上昇に貢献、各社スマートフォンの販売を強化している）
ananなど女性向け雑誌にもスマートフォンの特集が組まれたりしている

スマートフォンユーザーの利用目的
50%:メール、Web、電話 / 50%:ゲーム、ソーシャルアプリ、SNS（こちらが増えてきてる）
コンソールゲーム市場は前世界的に減少
オンラインゲーム市場は成長している

ソーシャルアプリ
・ミニゲーム
　例）AnglyBird 4200万ダウンロード、うち有償1200万。1200万DL x 100円 = 12億円/年。Free版公国1M$/月
・ソーシャルメディア
　・Facebook モバイルアクティブユーザー 2億人(1009/2は5000万人）
　　※モバイルユーザーはPCの倍
　・Twitter　アクティブユーザーの46%がモバイルから

アプリ内課金
　従来はダウンロード課金だけだったが、アプリ内での課金に対応した　
　アプリ内課金の成長が顕著
　（iPhoneでは、アプリの売上の50%がアプリ内課金によるものになっている。アイテム課金、有料コンテンツ追加など）
　Appleは、月額課金のモーとも追加された。※iModeでのビジネスモデルに近い、毎月の課金は収益がみこめる
　アプリ内課金に切り替えることによって、5〜10倍の売上になった例がある。

　アプリ市場 $6.8B(2010)　→ $25B(2015) ※うち$12Bがアプリ内課金

　売上トップのアプリ
・AnglyBird,フルーツ忍者、（日本では、カメラアプリなども人気）

　アンドロイドのシェア、iPhoneを抜いて２位に（1位はRIMのBlackBerry)
　Andoird2.3で、NFC搭載（おさいふケータイの技術）。iPhon5,iPad2にも搭載との見方(2011/6)
　※ Android+NFCでtagletというアプリがりイース済み。個人情報交換アプリ、mixiチェックイン

【ゲームトレンド】
シンプル、直感的なゲームが人気
・AnglyBird , Cut the rope , fruit ninja
本格的なゲームもでてきているが、人気なのはシンプルなもの

本格的なソーシャルゲームもでてきてる
・RESTRAUNT STORY (レストラン経営ソーリャルゲーム。Facebookとの連携もあり）
　※デザインやアイテムには有料課金のものもあり

プラットフォームを提供しているベンダーもおおい
・open feint
・Apple game center
・pankia
など

【単機能＋ソーリャルアプリ】
・Path (写真系SNS) ユーザー数　数十万（アクティブユーザー20%) $8.5MM資金調達済み / 良いデザイン（機能をしぼりこんでるからこそ）
・instagram (写真と共有。エフェクトなど特徴) 200万ユーザー
・foursquare　（位置情報）
・Quora (Q&A)
ほぼすべてのアプリが、SNSと連携している

【GREE】
GREEと垂直統合先
SNS:facebbok
自社アプリ：Xynga
プラットフォーム:OpenFaint

GREEのスマートフォン向けゲーム
・XHTML / JavaScript をふんだんにつかって実現できた。
・WebKit
・AJAX
・CSS3のアニメーション（アクセラレーションが効く）

GREEのiPhoneアプリ
HTMLだえｋでできないことをネイティブがおぎなう
メインは、WebView(実態はHTML)で、それいがいをアプリで実装
　※HTMLアプリ開発ノウハウの活用、開発効率向上

アーキテクチャの比較
・HTML5 (動的更新、開発工数）
・ネィティブ (速度、UI、機能)
・JSミドルウェア(Titaniumなど）
・ハイブリッド（動的更新）　※GREEはこの形式を押している

モンスタープラネット
（ブラウザ型ソーシャルゲーム。HTMKL5/CSS3/JS)

ワークアラウンド
・Andoird でアニメGIFが出来ない。→アニメGIFをJSで解析して描画した
など

【ミドルウェア】
「Titanium Mobile」
JavaScriptのミドルウェア
 iPhone,Android,RIMマルチプラットフォームのミドルウェア
 JavaScriptをネイティブアプリにコンバートする
よくできてる。基本的にネイティブと遜色ないアプリがつくれる
※ MogSnapはこのミドルウェ2222222

「PhoneGap」
ハイブリッド(HTML5+ネイティブ）アプリ開発フレームワーク
基本的にHTML/JSで開発して、ネイティブの機能にもアクセスできる

そのたHTML5アプリフレームw−開く
・JQuery Mobile　（HTMLだけでJSなしでもアニメーションのある画面がつくれる）

ゲームエンジン
・Unreal Engine (C++開発、iPhone用。Android対応も予定）本格的な3D
・CoronaSDK　（Luaで２D開発。ActionScriptライク）
・AirPlay SDK (C/C++。iPhone , Androd , PSP...)
・Unity3 (JS,C#,Kua) 3D開発。本命か。マルチプラットフォーム/MONOベース。ライセンス安価
　※ GREEのiOS SDKと連携できるようにする予定

【まとめ】
・２０１１年　スマートフォンビジネス本格化
・Mobile = Global
・アプリ内課金がビジネス的にトレンド
・NFC
・ソーシャルゲーム。とあたらしいタイプのソーシャルアプリ
・クロスプラットフォーム開発ウェアは旧発展の最中（まだデファクトはきまらず。長期的にはHTML5へ。短期的にはネイティブアプリ）

■ 【18-C-4】Google App Engine - 無限の彼方へ　松尾貴史氏(@tmatsuo)
スピーカー紹介
・App Engine Developer Advocate
・kay-framwork開発 (App EngineのPython フレームワーク）

App Engineの状況（リリースされてから３年）
10万開発者/月
15万アプリアクセス/週
10億ページビュー/日

２ヶ月に１度、新機能が搭載。常に最新の機能をアプリにとりこむことができる→陳腐化を防げる

これからのロードマップ
・カスタムドメインでSSLが使用できるようになる（おまたせ！）
・データストアにいれentityに全文検索
・バックグラウンドサーバ
・ログ保存サイズを増加
など

日本での事例
・mixi アプリのバックエンド(the actress 60万ユーザー、mixi xmax 2010 200万ユーザー）
・朝日新聞のメディア配信サービス
・ソニー - chan-torn (BLレコーダーの録画予約などの操作をおこなうサーバー）
・業務アプリケーション多数（旅行代理店旅券管理、ワークフロー、Google社内でも数百のアプリ）

App Engine for business
・99.9% SLA
・クラウド SQL
など

おすすめの本
・オライリー　プログラミング Google App Engine

- - - - -

Google App Engineでスケールするアプリの開発
開発する際の注意点
（スケールするためのコツ）

Data Storeの設計
・非正規化を嫌がらない - no join
　データストアへの保存は、Entity単位で行うが、ここに必要な情報をいえておきSatastoreへのアクセスを最小限にする。ネットワーク越しにAPIを呼ぶ回数を減らすようにする。
・必要なindexのみ作成
　インデックスが増えると書き込み速度が遅くなる。ストレージ量も増える。
　なにも指定しないとインデックスがつくられる。不要な場合は、indexed = false で抑制。
・最小限のEntity Group
　トランザクションが必要な箇所のみ使用する
　単純にエンティティを作成すると、それ自体が新しいEntityFroupになる。親を指定すると、親と同じEntity Groupに所属することになる（kindはちがってもかまわない）
　エンティティグループは、トランザクション処理に使用する（同時に安全に更新できる）。
　大きなEntityGroupをつくると書き込み時に競合がおこりやすくなるので、トランザクションが必要が箇所に使う。
　ただし検索用インデックスを自前で作成する(textProperty()用など）場合、fetchする際にindexesのデシリアライズが発生する（無駄）。hozonjini Entity Groupを作成すると無駄な展開が発生しない。
・可能なら早い方を使う
　・queryよりkeys_only quesy
　・queryよりget
　・複数のgetより、batch get
・Entityを分割
　ファイルシェアリングサービス（ファイル自身、メタデータを管理すると、ファイルの一覧で必要なのはメダデータだけ。別にしたほうが効率的）

・少しの失敗を受け入れる(確率として0.3%程度)
　自動スケールする際に、BigTableの自動分散の仕組みを利用(Tablet単位で分散。ひとつのtabletへのアクセスが多いと自動的に分散される）
　→分割する瞬間は数百msec〜2秒程度アクセスできない→リトライ処理する、deadline指定
　※おてがるな自動リトライのレシピもある

最小限の仕事をする
大事な用語
・ユーザー向けリクエスト(User Facing Request) インターネット側からくるすべて
・バックグラウンドリクエスト(Background Request) TaskQueue,Cronなど
大事なポイント
・ユーザー向けリクエストは1000ms以内に応答する
最小限の仕事
・より速い方を使用
　・query　より keys_only_query
　・queryよりget
　・datastoreよりmemcache
　・memcacheよりglobal変数(static変数)
・時間のかかる処理は、TaskQueueに投げる（バックグラウンドで処理される）
　→処理結果は、Channel APIでブラウザへプッシュ
・Datastore Contentionをさける
　ひとつのEntity,EntityGroupへの書き込みは、１秒に１度程度
　→Entity Gropuはなるべく小さくする。
　アクセスカウンターのようなものの実装はどうする（１秒に１回以上ある）
　→シャーディングカウンターなどのテクニックを使用する（複数カウンターを用意して、集計時には合計する）
　→fork-join quereをつかったカウンタ
・memcacheを効果的に使用
　・人気あるページのHTMLをまるごとキャッシュ
　・memcache.incrを使用したカウンター
　・頻繁に使用されるentityやqueryのキャッシュ（古キャッシュの破棄もわすれずに。データ更新時などに）
・パフォーマンス測定用ツールの活用；AppStats
　RPC使用状況を可視化してくれるツール

さらなる高みへ
・Request数のFixed Quotaはデフォルトで500QPS程度
　→それ以上必要な場合は、Quota Increaseのフォームから申請するか松尾氏へ相談
・Tablet Serverのsplitを抑制
　・頻繁にEntiryの作成を行う場合、idの自動採番によりsplitを起こりやすい。キー名を指定して、頭文字が類似だとsplitが起きやすいので、ランダムにする。hash値などと前置する。

まとめ
・Datasoteに適した設計(RDBMの考え方を一旦忘れる）
・最小限の仕事(1000ms以内）
・Datastore Contentionを避ける
・memcacheの効果的な利用
・AppStatsを使用してパフォーマンス測定
・FixedQuotaを増やす
・Tablet Serverのsplitを抑制

いまでは個人の開発者でも簡単に世界を相手にできる
ただスケーラビリティは難しい。→AppEngineを使えば無限に近いスケーラビリティを得られる

■ 【18-A-5】前例のないソフトウェアを作る！コミPo!開発秘話　小野知之氏 / 田中圭一氏

まったく絵を描かなくても　気軽にポッっと漫画がつくれちゃう！夢のコミックシーケンサー
いままでなかったソフトの開発について

● 企画〜開発スタート (田中）
（紹介ムービー）

コピPo!のたまご
・田中圭一氏の経歴（漫画家、ソフトウェア技術者）
・ウェブテクノロジー（グレフィック系ソリューション：独自原色エンジン、OPTPix imestaシリーズ：コンシューマーゲーム向け開発ツール）

時代のながれで、ソーシャルゲームの台頭、スマートフォンの登場から減色エンジンのニーズがへってきたことから新規授業への挑戦
・既存の技術
・時代のニーズ（CGM)
・マンガ表現の優位性

基本構想
・ゲーム会社時代の企画
・３Dデータで漫画をつくる
・いくつ用意すればいいのか
　学園漫画にすれば用意するデータが限定できる

プロトタイプの完成
（いままでないものなので、説明が難しい。実際にうごくものをつくった）

仕様を確定して本格開発がスタートした

● 小野氏

使いやすい７つの理由
１．よくあるソフトを手本にする（デファクトにあわせて直感的にわかりやすくすｒU)
２．カーソルにしゃべらせる（マウスカーソルの形の変化に気を使う）
３．左クリックと左ドラッグ（ユーザーは、それ以外の操作はまずしない。これだけで主な重要な機能をすべて使えるようにする）
４．コンテキストメニューの活用（とりあえず右クリックすれば、いまできる操作がわかるようにする）
５．配置を考える（操作のながれを考えて配置）
６．アクセラレータキーへの対応（キーボードショートカットがないと使い慣れたひとに使いづらいという印象を与える。キーは、メニューやツールチップにも表記してマニュアルレスに）
７．高度な機能は小さく（とっつきやすく、奥がふかいソフトのコツ）

今後
・漫画をつくるよろこびの提供
・新しい表現方法の提供
・世界にむけて日本文化の発信

■ 【18-C-6】Webサービス開発におけるニフティクラウド活用事例とチューニングTips
大石良氏 / 仲山昌宏氏 / 吉田雄哉氏 / 渡辺一宏氏 / 久保田朋秀氏

ニフティサービスイン：１年（現状７００社が使用）
パネルデスカッション形式での討論

ニフティクラウドは、CPU性能、ネットワーク性能が高いので強みを活かす設計をすべき。リスクを正しく評価、評価できる人材を育てるべき。といった内容
※ 詳細は割愛
ニフティクラウドはAmazonなどと比べると高いなーと思ってましたが、これはこれでありかなあ

■ 【18-A-7】オープンソース白熱教室〜たまには“ライセンス”の話をしよう〜可知豊氏
クレオ（筆まめ、クラウド型IT管理ソリューション）

OSS理解度チェック

テーマ
● 1.オープンソースライセンスの基礎知識（復習編）

1.バザールモデル
　・分散化されたコードレビュー
　・高速な品質向上
　・コミュニティによる開発体制
2.オープンソースの定義
　・ソースコード小海
　・自由な再利用の保証
　・ただしオープンソースライセンスごとに条件の細部は違う

簡単な歴史
・1967年 UNIXの登場
　牧歌的
・1985年ごろ
　コンピュータープログラムを著作権で保護(日本では1986)9
　リチャードストールマンが、GNU宣言を発表（ライセンスにより、ソフトウェアの自由を宣言）
・199x年はじめごろから
　インターネットブーム
　Linuxの台頭 OSS普及
・1998年
　複数のOSSライセンスを抱合　ビジネス利用をアピール
　・Netscape ぶらずあのソースを公開
　・オープンソースの定義を公開
・2002年クリエイティブコモンズ公開
・2005年 Web2.0

オープンソースは、
「ソースコードを誰でも自由に利用できる」とするライセンスをつけることで利用を樹有にする

著作権の基本
　著作権は、作品の利用（主に複製＝COPY)をコントロールする権利(Copy right)
　「利用」「使用」の違い
　ソフトウェアの利用：作者が権利をもつ（複製、配布、改良）
　ソフトウェアの使用：自由に使える（実行）

ソフトウェアライセンスとはなにか
　ソフトウェアの利用（複製・配布・改変）に対する著作権差hからのライセンス
　著作権を超えた使用許可を制限する

オープンソースの場合
　ライセンスで「複製・配布・改変」を許可する

→バザールモデルを促進するため

定義
・オープンソースの権利
　・利用者が、ソースコードのコピー当t栗、配布できる
　・入手できる
　・改変できる
・オープンソースライセンスが備える条件
　・作者のソースコードの完全性を維持すること
　・個人団体を差別しない
　・使用分野に対する差別をしないこと
　・再配布時には追加ライセンスを必要としないこと
　・特定の製品に固有なリアセンスを使用しないこと
　・他のソフトウェアにたいする干渉をしないこと
　・特定の技術に異存しないこと

主なライセンス
・修正BSD,MIT
・Apacheライセンス2.
・MPL
・GPL/LGPL/AGPL
※GPLが一番有名だがさまざまなライセンスがあるので注意

ポイント
・無保証
・配布時に、著作権表示、免責条項をふくめる
・コピーレスと条項をもつことがある（ないこともある）
・デュアルライセンスで運用されることがある
・ライセンス以外の条件で制限されることがある（特許条項、商標）
・ソースコードとバイナリーコードの配布条件はことなる場合がある

● 2.オープンソースライセンスをどのように選択するか

どんなライセンスで公開しているか
【会場の意見】
・BSD
　負担がすくない。ゆるい
・GPL
　GCCの拡張だった。RMSのファンになった時期がある
・MIT
　JQueryのプラグインなので、ライセンスを合わせた

・BSD
　・仕事で必要となるプログラム
　・でも仕事として作るのは調整が大変
　・プライベートで開発し、会社のプロジェクトにとりこめる

・GPL
　・自分の得意分野でプログラムを開発
　・仕事上の立場・自分のキャリアでの有効性を最大化したい
　・特定の企業にとりこまれにくい。自分に成果がかえってくるのではない

どんなときに、どんなライセンスを選ぶべきか
自分自身と自分の創作物のチカラを最大限に引出するには？

楽天吉岡氏の意見
　企業が使う場合はBSDが使いやすいと誤解されているかもしれないが
　実はGPLのほうがやりやすい
　自社の製品の派生物が他社にとりこまれない（ソース公開の義務がある）
　企業が新規に公開する場合は、GPL以外はありえないだろう。
　バザールモデルでコミュニティのチカラを借りる（またはイメージアップなど）場合についても、GPLがおすすめと考える

質問
　GPLの感染性の誤解を払拭しきれにあので、LGPLで提供したことがある。これについてはどうか

吉岡氏
　秘密にすることで利益を得るという行動様式があるが、これは多くの場合幻想でしかない。
　公開することによって、他社がより多くの利益をあげるおとを恐れる。しかし、公開しても自社の利益が減るとうことは実際のところはほろんどない。
　オープンソースとして
　・コミュニティとともに開発することでコスト削減できるかもしれない
　　その時、ライセンスの問題は実はあまりかかってこない
　→経営層に説明しやすい方便を考えましょう
　　（ノウハウを共有しよう）

DeNAのモバゲーのプラットフォームもオープンソースになっている。

■ 会場にて

ユーザーグループなどの展示も