Google Developer Summit Tokyo 2015の感想と参加メモ

1 Star2 Stars3 Stars4 Stars5 Stars (まだ評価されていません)
Loading...

2015.4.9開催
公式サイト: https://events.withgoogle.com/gdstokyo-201501/
Twitterハッシュタグ: https://twitter.com/hashtag/GDSTokyo
Togetter: http://togetter.com/li/806050

まとめと感想

発表を聞いて

  • Physical Web知らなかった。実験的とはいえ、URLを飛ばすという発想が非常に面白い。
  • Google Playのポリシー、ガイドラインをちゃんと把握できてとてもためになった。
  • Google Playでは評価4.0以上をめざすことが大事(収益につながる)。
  • Android TV向けのアプリは開発しやすそう。UIや操作系まわりで苦労は多そうな印象。
  • レーティング設定は非常に重要。4月中にやるべし。
  • Firebaseはデータ同期のスピードに非常に魅力を感じた。IoT用途にも向いていそう。
  • BigQueryの良し悪しがとてもわかりやすく解説されていてためになった。
  • 速度を求められるケースにはBigQueryは有用。他のオープンソースでもできるかもしれないがマネージドな点が相当有利。
  • Android TVでの音声入力の認識率が気になった。(いずれ使ってみたい)

イベントを通じて

  • 最新の情報がまとまっていて、さまざまなことについて理解が深まった
  • 開会時に写真撮影のマナーや、資料、内容の共有についての周知があったら更に良かった
  • ノベルティが良かった(モレスキンノート、ステッカー)
  • スタッフの配置、案内がとても良かった(迷わなかった)
  • 無料コーヒー最高(おいしかった)
  • 質疑応答の時間があると良かった(1〜2個でも)

その他

  • 普段は運用ばかりしているが、話を色々聞いてコードを書きたくなった(特にAndroid TV, Wear)
  • この1年でWearとSmartphoneとの組み合わせで新しいUXが生まれるのではと期待。

以下は発表のメモ(私が参加したもののみ)

多様化するデバイス環境から考えるユーザ体験とエコシステム – 及川 卓也

  • Web技術25周年
    • WebGL, WebRTCなどを通じて表現が広がってきた
    • 言語やフレームワークが進化してきた。たとえばAngular.jsなど。
  • Web Components
  • Web Starter Kit (beta)
    • 会場でも1/5くらいの認知度
    • Web Fundamentalsというノウハウ、Tipsを参考に
    • パッケージ化したもの
  • Material Design
    • GoogleのプロダクトはUIがバラバラだった
    • polymer, PaperElementを使うことで統一できる
  • ツールの進化
    • Chrome Dev Editor (developer preview). Dartで書かれたオフラインで使えるエディタ
    • Chrome Dev Tools
    • さまざまなエミュレーション。GPS, Orientation
  • モバイルデバイスの普及
    • ネイティブとWebのハイブリッド
    • 平均33個のアプリをインストールしているが、実際は1/3しか使わない
    • 昔はディレクトリ型の検索が主流だった。今のアプリストアが同じような状況。検索で解決していく。
    • Deep Linking & App Indexing
  • Physical Web
    • IoT向け
    • GitHubにプロジェクトがある https://google.github.io/physical-web/
    • 実験的なプロジェクト。提案フェーズ。
    • いろんなIoTデバイスがあってビーコンを飛ばしてくるときに専用アプリが必要になってくるケースに対する解決
    • ビーコンでURLを飛ばすという方法
    • BLEのAdvertise Packetというものを使ってURLを飛ばす
    • IoTデバイスからPushはしてこない
    • スマホがビーコンをキャッチして「いまできること」を探す
    • TEDに提唱者が出ているので参考に

ユーザーを魅了するネイティブアプリ経済圏の広がり 〜 モバイル、ウェアラブル、リビングルーム – 松内良介

ひろがるアプリ経済圏

  • Google Play
  • 2014年、70億ドルを開発者に支払っている
  • 190地域で提供
  • 130地域で有償販売可能
  • 65カ国は現地通貨での販売
  • 決済手段の拡大に力を入れている。ギフト、キャリア課金、PayPal
  • 月額課金の広がり。急成長している。Google In-app Billing API。
  • ユーザーの不満と期待
  • ユーザー評価が高いと収益性が圧倒的に高い(アプリ内課金)
  • 期待値の上昇
    • 不満があれば即アンインストール
    • 数百ミリ秒の差を敏感に感じる
    • オフラインでも使えることを期待
    • バックグラウンドで同期
  • 今も昔も動作速度が大事
  • 何かするたびにいちいち通信しない
  • 中断感の少ない効果
  • できるだけ起動前にデータをダウンロード
  • 会員登録などの要求でユーザーを邪魔しない(できるだけ後回しに)
  • スクロール時の問題。RecyclerView + Adapter, Glideで処理を任せることでスムーズに。
  • Strict modeを使ってデバッグ。
  • 電池を使いすぎるというクレーム
  • Battery Stats Tool(Lolipop)
  • Transferring Data Without Draining the Battery
  • RAMの消費を抑えるノウハウ
  • procstatsツール(Android 4.4以降)
  • Memory Monitor (Android Studio)
  • タブレットに最適化されたアプリとの売上ギャップ約10倍
  • Google Identity Platform (Google Sign-in)
    • 2015年3月公開
  • 通知の表現に対する不満、苦情
  • ユーザー評価はよく読むと、期待していることがわかる
  • 評価4.0以上を目指す
  • アンインストール数はインストール数と同じぐらい重要
  • Android App Quality ガイドラインを参照すること
  • 良いアプリの例
    • iQON, Wantedly, テレビ東京ビジネスオンデマンド
    • Etsy, Airbnb, Expedia, The Whole Pantry

Google Cloud Platformで知るGoogleクラウドの「Googleらしさ」 – 佐藤一憲

資料リンク

  • Googleのデータセンター
    • サーバもスイッチも自社製
  • Colossus, BigQueryで使っているファイルシステム
  • Googleは10年以上前からコンテナを使ってきた
  • Googleのインデックスサイズ 100petabytes を超えている
  • BigQueryと競合: Impala, Apache Drill, Presto
  • サービスごとにラックやサーバーを分けていない
  • 2004年以前からcgroupsをcontributeして使ってきた
  • SnapChatがGoole App Engineを使っている
  • SnapChatが100million request/secを達成
  • Load BalancerでAnyCastの提供

Android TV で実現するリビングルームでのアプリ体験 – 江川 崇

資料リンク

TVのクリエイティブビジョン

  • Casual
    • Leanback, 気軽に楽しむ、家族や仲間と空間を共有する
  • Cinematic
    • 体験への没入、コンテンツ重視、不要な情報を出さない
  • Simple
    • ユーザーは約3,4m離れている
    • 最小のステップでの操作
    • テキストの代わりに音声や絵
  • ランドスケープ固定
  • フルHD想定, xhdpi
  • オーバースキャン(5%程度の余白を周囲に)
  • D-Padまたはゲームコントローラ, ViewPager禁止
  • 常に1つのオブジェクトにフォーカスをつける
  • 音声入力で検索させることが求められている
  • ホームスクリーンバナー
    • ホーム画面のアプリ起動ボタン
    • 320×180 pixelで作り、アプリ名を必ず入れる。国際化必須。
  • ホームスクリーンに表示されるおすすめ行
    • より大きなアイコンで表示される
    • 2016×1134 pixelの背景画像も設定できる
  • 色彩はなるべくダークに
  • 細いフォントは避ける

開発について

  • スマホ、タブレットと同じSDK、Android Studioを使う
  • UIはTV向けに構築し直すべき
  • Googleによる事前の品質審査(主にUI)が必要
  • Leanbackライブラリ
    • かならず使う必要はないが、なるべく使ったほうが良いというライブラリ
  • 検索インタフェース
    • ホームスクリーンからの検索は従来のスマホとかと同じ感じ
    • アプリ内検索はBrowseFlagmentを使うと簡単
  • TVかどうかの判別、搭載ハードウェアの有無のチェックをして処理を分ける
  • ゲームかどうかのフラグ設定がある。ゲームの場合はisGameをTrueにセットしておく。
  • 静止画はPicasso
  • 動画はExoPlayer

Google Play コンテンツ ポリシーにおける注意点や変更点 – 寺前 桜

を確認してほしい

ポリシー違反について

キーワードスパム

  • キーワードの繰り返し
  • 関係ないキーワードや参照
  • 過度の詳細や他のアプリへの参照
  • アプリのタイトルに含まれる他社商品名やブランド名

偽りの評価やレビュー

  • 偽りのまたは不適切な評価やレビュー
  • ユーザーの評価の勧誘

知的財産権ポリシー

  • 著作権侵害
  • なりすまし
  • 商標権侵害

広告とシステムへの妨害

  • コンテンツとユーザーの成熟度
  • ユーザーへの広告の開示
  • アプリやサードパーティ広告への妨害
  • システムユーザーインタフェイスの偽装

露骨な性的表現

  • 露骨な性的表現を含むコンテンツは禁止

最近の変更点

  • アプリの事前審査
  • 新しいコンテンツレーティング制度

アプリがGoogle Playストアに公開される前に審査

公開ステータスの表示
  • 不承認
  • 削除
  • 停止

が加わった。

  • 公開までの時間は気にしなくても良いとのこと
新しいコンテンツレーティング制度
  • カテゴリの選択とアプリのコンテンツに関する質問に回答すると、レーティングが決まる
  • 5月から一般ユーザーに見えるようになる
  • 設定していないとレーティングなしの表示になる
  • 国によってはアプリが表示されなくなる
Google Playからの違反メールを受け取った場合
  • 期日以内に対応しないといけない
アプリ削除判断に異議がある場合
  • 異議申立て用のリンクから
Q. 他のアプリも同じことをしているのになぜ停止、削除なのか
  • A.該当アプリについてはひとまず迅速に対応してほしい
  • A.ほかの不正アプリは報告フォームからお願いします
Q. 新しいコンテンツレーティングを設定しないと削除されるのか
  • A. 5月以降もレーティングがないとレーティングなしのラベル
  • A. 一部の国、地域で表示されないケースがあります

Android Wear でのアプリ開発手法 – 山口 能迪

Android Wearのコンセプト

  • 今までは、みんなでスマホやタブレットをただ見つめている状況
  • より現実世界に時間を使い、それでいてよりネットにもつながった状況を目指したい

スマートフォンに時間を使う理由

  • 高機能、できることが多い
  • 通知があって取り出してみるまでの時間
  • 本来からの目的の流れで違うことをしてしまう

  • モバイルでもパソコンと同じUIを目指していた時代があった

  • ウェアラブルでも同じ考えでいいのかどうか(スマホからウェアラブル)

  • 同じUIを当てはめてはダメ

  • 画面の形状が違うものもある。ウェアラブル専用を考える。

2つの基本要素

  • アクション ユーザーからデバイスへ
  • コンテキスト デバイスからユーザーへ

この2つをしっかり抑えていきましょうという考え

コンテキストの表現方法

  • 起動は自動的に
  • 一瞬で理解できる表現が必要
  • ユーザーに提案しながら対話する。なるべく小出しで。
  • 操作はそもそも不要または極小に。できることはなるべく減らしてあげる。歩きながら操作できないならUIを見なおした方がいい。

コンテキストは通知の次のステップ

  • ペアリングされたAndroid端末が必要
  • デフォルトではAndroid内に通知が届く

  • 本当に伝えたいコンテキストを抽出する

  • 通知の中から本質を切り出す

  • ピークには多くて2単語

  • アイコンを有効活用する

コンテキストの表現方法

  • ページング
  • スタック
  • 2Dピッカー。2次元で情報を整理してあげる。

開発環境

  • Android Studio(現時点で最新版 1.2Beta)
  • Android Wear端末

通知

  • 通知がうるさいのはストレス
  • L0: Androidアプリの通知そのまま
  • L1: Androidアプリの通知を拡張
    • 通知をリッチにする
    • WearableExtenderを使うことでWear側での通知の表示を変更できる

マイクロアプリ

  • L2: Wear上で動作するマイクロアプリからの通知
    • マイクロアプリを使って柔軟なデータ通信やUIを提供できる
    • Google Play開発者サービスが必要
    • マイクロアプリでできること
    • データの送受信(Node API, Message API, Data API)
    • カスタムUI(GridViewPagerをよく使う, BoxInsetLayoutを使うと丸と四角の画面を吸収できたり)
    • ボイスアクション(Presetされているもの以外の定義。スタート<ラベル名>でマイクロアプリを起動できる)

L1まではコンパニオンアプリの開発のみ

ウォッチフェイス

  • 時計型デバイスならではの遊び心
  • 最近ウォッチフェイスのAPIが公開された
  • Santa Trackerがオープンソースに
  • 作るには、Android StudioでActivityを追加
  • isAmbientModeで暗い状態かどうか判断して秒針を表示しないなどの制御ができる

アプリの配布

  • Androidアプリの配布と同様
  • スマートフォン用のapkにmicro apkが一緒に同梱される。
  • Wear対応アプリの配信をオンにして配布。おすすめWearアプリに表示される。

実践 Google BigQuery – 本多 一行

資料リンク

BigQueryを選択する理由

  • 最速ではない
  • データの構造によって変わる
  • Presto, Redshift Impalaでも同等かそれ以上の速度が得られることがある
  • Full Managed Serviceということが利点
  • 容量無制限のディスク、初期費用の安さ、WebUI,CLIが標準装備
  • Google Apps Script, App Engine, Cloud Logging, Analytics Premiumとの連携
  • BigQueryは「遅くならない」ことがポイント
  • スタートアップには最適
  • 小さく安く始められて、大きくなっても遅くならない
  • Hadoopクラスタを持っていないならBigQueryを導入してみて損はない
  • Hadoopクラスタの管理がつらい人にもよい

課金体系

  • Storage 500GBで1000円
  • Streaming Inserts 1億行で1000円
  • Query 3TBで1000円(1TBは無料枠)
  • Streaming Inserts, Queryの課金に気をつける必要がある

BigQueryがやってくれること

  • ストレージの管理
  • シンプルだけど有用なWeb UI

やってくれないこと

  • スキーマの管理
  • 統計解析、機械学習関連の機能
  • 可視化
  • ETL関連の処理

教えてくれないこと

  • Backend Errorの原因
    • Backend Errorがたまに起きる。そんなときはリトライする。予測できない。
  • 詳細な機能アップデートの内容
    • いつの間に機能追加されているときがある

ETLツール

  • Streaming Insert fluentd
  • Bulk Insert Embulk

BigQueryの応用

  • Table Decorator
    • Query速度の改善とコスト削減の両方に有効
  • Table wildcard functions
    • 正規表現などでテーブルをまとめて指定できる
    • 日時で分割したテーブルをまとめて指定できる
  • JSON functions
    • とりあえずスキーマに悩んだ場合に使える
    • 手元のJSONをそのまま突っ込みたいとき
  • Streaming Insertsのリミットを解除できる
    • 1万行/秒がデフォルト
    • 申請すれば10万行/秒までリミット解除できる

Quipperでの活用事例

  • 10万行以下のCSVに落とす
  • FluentdとEmbulkを使っている
  • Apps Scriptとの連携が最高

コミュニティについて

Firebaseによるリアルタイムモバイル開発 – イアン ルイス

なぜモバイルが重要なのか

  • マルチデバイス。デバイスがいっぱいあって、ユーザーもいっぱいいる状況。
  • たくさんのユーザを集めるにはモバイルが重要。

バックエンドサーバの構築

  • 何をどうやって構築したらいいのかわからないという問題
  • データベースの選定も難しい
  • そういったところではなく、UI/UXにフォーカスしたい
  • モバイルは・・・様々な画面サイズがある、個人で利用するデバイス、ネットワークの信頼性が低い
  • モバイル開発はチャレンジング
    • 多数のプラットフォーム
    • リアルタイム性への期待
    • 常につながっているデバイスはアプリの状態が分散される(どのユーザーでも同じ情報を見るというのが難しくなる)
    • 多数のデバイスな巨大なスケールが必要

なぜFirebaseが便利なのか

  • 会場の半数くらいがFirebaseを知っていた
  • リアルタイムアプリケーションプラットフォーム

リアルタイムのDB

  • NoSQL, JSONデータベース
  • ミリ秒単位で更新をプッシュ
  • デバイスから直接のアクセスを可能とするセキュリティモデル
  • データとURLのマッピング

  • 計算性能のシフト(クライアント側の性能の向上)

  • ClientとFirebaseのデータの同期が可能

  • 複数のデバイスでも同期できる

  • 圏外から復帰した場合でもSyncしてくれる

ユーザー管理

  • メールアドレスとパスワードで簡単にログインできる
  • oAuthプロバイダ(Google, Facebook, Twitter, GitHub)
  • カスタム認証トークン

ファイルホスティング(データのホスティング)

  • カスタムドメイン
  • セキュア(SSL)
  • 高速(CDN)

今後について

  • より強力なクエリー対応
  • 全プラットフォームのオフライン対応
  • よりいいユーザー管理とAnalytics
  • Google Cloud Platformとの連携
    • たとえば同期時にWebHookでApp EngineとBigQueryと連携するとか

デモ

https://github.com/firebase/office-mover-5000


1 Star2 Stars3 Stars4 Stars5 Stars (まだ評価されていません)
Loading...
      この投稿は審査処理中  | 元のサイトへ