@thorikiriのてょりっき

@thorikiriがWebとかAndroidとかの技術ネタや本を読んだブログです

トップ > event

appengine ja night #26 #ajn26 に行ってきました

event appengine

とりあえず、メモを。

Compute Engineについて

  • Compute Engine
    • 3つの分野で構成されている
      • VM
      • Network
      • Storage
    • GoogleのDNAが詰め込まれている
    • 最新情報ではあるが、全体の話をする
      • 使い方
      • 何に使えば良いのか
      • 3つの構成について
      • Q&A
  • 使い方
    • 全てAPIを経由して利用する
    • gcutil listinstances
    • add instance [instance名]
      • インスタンスを追加
      • 場所や、サイズ、OSなどを選択していく
      • すぐに起動するのでsshで接続が可能
    • gcutil ssh [instance名]
      • すぐにsshでの接続が可能
    • 一度インスタンスを作成すると、全く同じ構成で作るためのテンプレートが作られている
      • OAuthのTokenも同時に作ることが出来る
  • 何に使うか
    • Linuxなので、Linuxで出来る事であれば何にでも使える
    • Googleのネットワークの近くにある
      • GoogleのAPIを利用する場面ではLatency的に有利
    • Chrome World Wide Maze
      • WebSocket部分をCompute Engineで実装していて、他のフロント部分はApp Engineを利用
    • Hadoop等にも使える
      • Googleのネットワークなのでスピードが良い
    • AppEngineのバックエンドとして利用する
  • VM
    • マシンタイプ
      • CPU、メモリと値段がセットになっているもの
      • CPUが重要なもの、メモリが重要なものなど選べます
      • 1〜8つのCPUコア数を選択できる
      • CPUを専有出来るタイプもある
    • f1-micro, g1-smallはCPUをシェアします
      • 週末に16時間稼働させるくらいなら40円程度で住みます
      • 料金は1時間あたりで表示していますが、1分単位で計算されます
  • Block Storage
    • Scratch Disk
      • 期間限定用、インスタンスを終了させるとデータは消える
      • サイズはマシンタイプと紐づく
      • 2コアのものから専有するようになる
    • Parsistent Disk
      • 永続化されたディスク、10TBのサイズでもOK
      • ディスクを作成してから、VMからつなげる
      • Rootディスクとしてや、外付けディスクとして使用する
      • Read Onlyであれば複数のVMから参照することが出来る
      • 複数のDiskに同じデータを保存しており、読み込みは一番早くレスポンスが来たものを利用する
      • OSのスナップショットを保存しておくことも出来る
      • 課金は使用している容量分だけ
  • Network
    • TCP, UDP, ICMP, ping
    • IP
      • publicもprivateも可能、staticもephermeralも可能
    • Firewall
      • 初期はSSHポートのみ開いている
      • ポートを開けたい場合は、Firewallの設定を行う
      • どこからどこへ、どのポートを開けるかを指定する
    • Gateway, VPNs
      • VMからインターネットへ出て行く方
      • Firewallと同じように設定する
    • LoadBalancing
      • TCPとUDPのバランシング
      • Googleの他のサービスと同じものを利用している
      • HelthcheckはHTTP 200 OKで問題なしとチェックされる
  • Automation
  • まとめ
    • これからも頑張ります
      • Googleの社員自身が自身の為になる環境を、皆さんにも提供してく
    • ソフトウェア・エンジニアは素晴らしい
      • 思いついたアイデアで世界を動かすことが出来る
  • Q&A
    • Scratch DiskとParsistent Diskの違いについて
      • ほとんどParsisntent Diskを利用する方向で良い
      • すぐに捨ててしまうようなデータであればScratch Diskを利用する
    • AWSとの比較
      • 1分おきに立ち上げて、処理して、落とすなどのことをしたい場合は良いと思う
      • App Engineの連携はスピード的にも良い
      • アップロードするデータの転送料がタダ
    • Helth Checkの単位について
      • Compute Engineのインスタンス毎です
      • その中のプロセスの単位ではない
    • 選択できるOSについて
      • OSの選択肢は確かに少ないので、がんばります。
      • このOSや、この機能が無いので使えないという場合は、リクエストしてください

VM-based backends (VM Runtime) について

  • App EngineのインスタンスがCompute Engine上で動作する
    • AppEngineでは、PythonやJavaが使えるが、本物ではない
    • 制約を取っ払いたい
      • なのでVM-based backendsを作った（名前は変わるかも）
    • Compute Engineのインスタンスを使うのでとてもパワフルである
      • ポートを開けることも出来る
      • インターネット側からCompute Engineにアクセス出来る
    • 全てのライブラリや、Javaのクラスが使える
      • RedisもOK
      • WebSocketも利用することが出来る
  • AppEngineの制約を取り除くための歴史
    • 2008年 オートスケールするPython環境として提供
      • トレードオフがあった
      • スレッドが使えない、外部プロセスが使えない、30秒制限など
      • 弱点として、長いプロセスや、ライブラリ、限られたCPU・メモリ、ネットワークコネクションなど
    • 2011年 AppEngine Backends
      • リクエストのデッドラインがなくなった
      • バックエンドスレッド
      • 素晴らしいけれども、インスタンスのライフサイクルが短い
      • Python 2.7
      • マルチスレッド、30秒から60秒への制限緩和、サードパーティモジュールなど
      • ただ、全てに対応できたわけではない
      • 料金改定
    • 2013 4月
      • 外向きのSocketに対応した
  • VM-basedを作ろうとおもったモチベーション
    • インスタンスライフタイムをもっと長くしたい
    • CPUやメモリをもっと多く使えるようにしたい
    • 外部プロセスを使えるようにしたい
    • 要するに、IaaSとPaaSのいいとこ取りをしたい
      • ダメなとこどりにならないように
  • まとめ
    • リリースされたらいろいろはかどります
  • Q&A
    • すみません、メモれてないです

Android Casual Talks #1 #androidcasual に行ってきました

event android


クックパッドで開催されたAndroid Casual Talks #1に行ってきました。
美味しいタイカレーも頂きました。
http://images.miil.me/i/fe4abd0e-109b-11e3-8a3d-22000a84999a.jpg
Android Casual Talks #1 : ATND
Android Casual Talks #1 #androidcasual まとめ - Togetterまとめ
以下、メモを。

クックパッドの開発環境について

  • 以前の状況
    • 開発者が1人だった
      • 規約無し
      • 手動ビルドだった
      • などなど問題があった
    • 属人性を下げるために
      • 快適にコードを書くために
      • 継続的に改善するために
  • コーディング規約
    • コーディングスタイルが統一されていなかった
    • Prefixのmがついていたり、ついていなかったり
      • 開発者が1人だが、ずっと同じ人と言うわけではなかった
    • サーバ側のRubyチームのコーディングガイドラインなどは、Github Enterpriseで管理されていた
    • AndroidのJava用も作りました
    • 規約があるので、書きやすく、レビューも楽に
  • Eclipseから、Android Studio + Gradleに移行
    • Ant、MavenのXMLファイルの設定から、GradleでのGroovyのDSLで設定を書くことに
      • プログラムで書くので、条件をで色々書くことができるので良い
      • Gradleは割りと新しいものであるが、大概の事は出来る
    • Mavenリポジトリのサーバ
      • ライブラリプロジェクトを登録。
    • Android Studioはまだ早いんじゃないの？
      • でも、Rubyチームは新しいものを取り入れる文化だった
      • なので、Androidチームもそれを踏襲する
  • ビルド
    • Debugビルド
    • Betaビルド
      • マスターブランチのビルド
      • セキュリティ試験などが行われる
      • 社内の人が実際に利用してβテストを行う
    • リリースビルド
      • クラッシュレポートを有効
      • デバッグをオフにするなど
      • PAPAと言う社内ツールでアナリティクスを行う。お問い合わせとかにも使われる。
  • まとめ
    • ゴールはユーザに価値を届けること
    • 高品質なアプリを早く作る事ができる環境を作る

品質を保つための組織的な取り組みと人に依存しないテスト

  • ポイント
    • マインド
      • 人です。組織の目標を統一する
    • 反復
      • 開発は繰り返し、小さな目標に分割する
    • 計測と評価
      • 品質を正当に評価する、メトリクスは大事
  • 開発プロセスの決定
    • ウォーターフォール
    • メンバーは20人くらい。
    • まず開発方針、プロセスとかを決める。
      • バグがゼロとかではなく、前回より、何%向上とかそういう事
      • レビュー工数の割合とか、自動で計測できるカバレッジを計測
      • レビュー工数は全体の15%は確保するなど
      • 不具合発見工程、原因工程など
    • 開発者の中で話し合う
  • イテレーションで行う
    • 1週間でイテレーションして、お客さんに見せる
    • そのなかで、設計、実装、テストでどんどん確認していく
  • 良い点
    • 4ヶ月のように長いスパンだと、振り返る時に忘れる
      • 振り返りは早いほうがいい
    • 単体テストの自動化はやる、JUnitとか
      • テストの密度が少なかったら追加する
    • テスト設計は結構きっちりする
      • 直交表を作るなど
    • 設計と検証はワンセットでやる
    • 作りきったものに、テストフレーム枠を入れるのは難しい
      • なので、初めから導入する
  • マインド形成
    • 開発者が納得する目的を探す
    • QCDを全て満たすのは不可能である
      • Weeklyで何にプライオリティを置くか変える
    • テストの重要性を理解する
      • 不具合を修正するときに、テストをスキップしたがる気持ち
      • フェーズ毎にによってスキップしてはいけないフェーズを決める
  • 結果
    • とは言え、不具合は発生する
    • 残業を敵視するようになる
    • 目標通りの納期
      • 数値化されているので、機能を落とす交渉に説得力がある

グリーにJenkinsを導入して2年半でおこった事

資料 → 2013 08-29 jenkins for cookpad android

  • Jenkins（Hudson）に関する記事をBlogに書いたのが2006年
  • 移行普及活動などをしていた
  • IndesignのデータからJenkinsで自動で電子書籍アプリを開発したり
  • 2年半前にGREEに入社して、Jnekinsを導入。
  • 導入のモチベーション
    • 変えないことは、大きなリスクです
      • 内的要因、競合変化、技術発展
    • 変えないと技術的負債が大きくなる
      • ひたすら負債を返済するために働くようになる
  • 導入のポイント
    • ツールを導入すれば良いのではなくて、ワークフローを変えなくてはならない
    • じっくり慎重にやる
    • 無理強いしない
      • 無理強いすると開発者の反乱が起こる
      • ある程度は許容すること
    • 拡張、改善の余地を残す
      • 見守る
      • 変化についてくるための時間は待ってあげる
      • ゆっくり熟成されるまで
  • GREEの場合
    • エンジニア、デザイナー、ディレクター、プロダクトマネージャーが関わっている
    • 作業が属人化してしまう
      • 見ているバージョンが違ったりする
      • 違うバージョンを見ていて咬み合わないことがある
    • 先ずはビルドをするところだけを、Jenkins導入
      • 同じビルドを使ってテストをすることが出来るようになった
      • ここまで来たら、見守ってあげる
    • 自然にワークフローを変えるようなことをしてくれる
      • 仕組みを改善することで、自然に色々と改善してくる
  • 指標、マトリクスを取得する
    • 取るだけでは自己満足になる。
      • リリース基準との結びつきがない
    • あるべき論や精神論から、許容できる範囲の仕組み・制度にする。
    • 品質基準については、ゆっくり合意していく
      • 徐々にワークフローに組み入れる。
      • → 仕事の方向が揃うと大きな力になる
      • 方向が揃わないとダメ
      • 一緒に揃えていく
  • もうひとつ
    • トヨタのかんばん方式
      • トヨタ系列で作って、売っている
      • 季節などによって出荷量が変化しない
      • 顧客が出荷まで3週間くらい待ってくれる
      • いくつ売れたか、陸運局に登録されるので、わかる
      • なので、在庫とかの調整が出来る
    • 野菜農家（でも何でも）
      • 季節によって出荷量は変わる
      • 幾ら消費されて、いくら破棄されているかわからない
      • なので、野菜農家では、かんばん方式はうまくいかない
    • 業種業態や、ビジネスによって、方法は同じではない
      • なので、良い方法を見つける必要がある

injectionの基礎（android編）

資料 → @inject presentation by G G on Prezi

  • DI 依存性の注入。
    • Inversion of Control、制御の反転。
    • マーチンファウラーたんの仕組みを考えたとき、IoCだった
    • プログラマとプログラムのインタラクション
      • 誰が制御するかを変える。
  • チャットアプリを作るのを例として考える
    • 自分の連絡先の一欄を出す画面
      • List contacts = Contacts.query(...);
      • 普通なら、こんなふうに考える。
    • 同じようコンタクトリストを表示する他の画面ではどうするだろうか？
      • コピペするだろうか？
      • リファクタしますね
      • 役割を持ったクラスを作って、実装を一箇所にする
    • 現在オンライン中のコンタクトリストは
      • Lister contactLister = new OnlineContactLister(connection, ...);
      • これで、よくなったでしょ、一箇所にまとまったよね。
    • 仕様が変わりました
      • 連絡先を外部のデータベースに置き換えてみる
      • これを変更するのは結構大変です。Contextが無いとか。
    • Factoryパターン
      • 自分でnewするのではなくて、ContactListerを作ってもらう。
      • Localから取得するのか、Onlineから取得するのかは、どこかの設定ファイルで見る
      • 設定ファイルを変えるだけで、実装を変更しなくてもよい
      • Factoryは、DIの機能に近い
    • パラメータはどうしましょうか？
      • オフラインでLocalから取得する場合はコネクションとか要らないですよね
      • ここで、DIのフレームワークになります。
  • Ingector
    • Ingectorオブジェクトがあります。
    • Ingectorの設定ファイルに、このインタフェースは、この実装クラスを作りますよ、とかを書く
    • 実装では、
      • @Inject Lister contactLister;
      • とするだけで、自動的に、NetPersonListerを作って当てはめてくれる
    • 依存関係を設定ファイルによって自動で設定してくれる
      • 設定ファイルには、パラメータを設定するようなことも出来ます
      • 柔軟性が上がる
      • Injector Modules 設定のまとまり
  • とは言え、そんなに置き換えないじゃない？
    • テストの時に一番役に立つ
    • Onlineから情報を取得するとなると、Onlineから取れる情報がいつでも同じというわけにはいかない
      • なので、擬似データを取得するための方法として、DIが良く使われる
  • フレームワーク
  • Spring
    • サーバサイドでは有名
    • Android向けのSpringも出ているらしい
  • Roboguice
    • GuiceのAndroid向けに作ったもの
    • Activityクラスの場合に、RoboActivityを使うようにする
  • Proton
    • 軽量
  • Dagger
    • Staticでインジェクションをやっている
      • コンパイル時に実際のコードを置き換える仕組みで、ランタイム時ではない

意外と役立つ？Android Open Source Projectすすめ。

  • OHA
  • Androidのアーキテクチャ図
    • 多くの人は、Application層を作っている
  • アプリ開発で悩んだときは？
  • それでもわからないときは？
    • 他のアプリを逆コンパイル
    • 明日考える
    • 仕様をドロップする
  • 最終解決方法
    • OHAのコードリーディングをする
    • 事前準備
      • 言語を英語にしましょう
      • 設定アプリ内の画面に表示されてるものを検索するため
  • OpenGrokと言うサービスを使う
  • 検索する
    • string.xmlが引っかかるので、name="aaaa" の部分で、再度検索する
    • Javaファイルが出るので、そのあたりのコードをコピペします
    • 一般のアプリでは通常は使えないAPIが表示される事もある
      • @Hiddenが付いているAPIは使えない
    • 諦めたら試合終了だよ。

アプリのリニューアルとその効果測定について

  • PixivのAndroidアプリをリニューアルしました
    • 黒ベースから、白ベースに華やかに
    • 今風のUIに
    • 使いやすくなったはずだ
    • レビューを見ると、前のほうが良いという意見が沢山
    • 批判レビューが沢山出てくる
    • しかしながら、レビューの意見だけがユーザの意見ではない
  • GA等を使って解析してみよう
    • ブックマーク機能
    • コンテキストメニューから、アクションバーに移行
      • ブックマーク操作のイベント数は約7倍になっていた
    • 画面遷移を少なくし、操作数を減らす
      • ステップ数が4つあった物を１つにしました
      • スクリーンビューと滞在時間を比べて見る
      • ムダな画面は見なくなったけど、一つの画面での滞在時間は増える傾向になりました
  • ポイント
    • よく使う機能はアクセスしやすく
    • ムダな画面遷移をさせない
    • 戻るボタンを多用させない
    • おかげでユーザ数も増えています
  • とは言え
    • レビューは批判も含めて貴重な意見
    • ユーザ全員がレビューしてくれるわけではない

第41回 HTML5とか勉強会 #html5j に行って来ました

event html5

メモったことをアップしておきます。
11月30日にHTML5カンファレンス2013が行われるそうです → HTML5 Conference 2013

Inside wri.pe

  • wri.pe の話
    • ブラウザ上で使えるメモ帳。
    • 操作はカーソルキーでも出来るようにしている。
    • 日付を入れておけば、カレンダービューに表示される
    • GoogleカレンダーとSyncするようになっている
    • HTML5なので、iPhone, Androidでも使える
  • 開発についてなど
    • ゴールデンウィークで開発した。
      • 篭って開発していました。
    • OSS開発に行き詰まったので、気分転換に開発
    • 作りたい物リストを公開している
    • 煩雑なメモをどうにかしたい
      • 以前はデスクトップにメモを置いていた
      • メモには書いてありました…的なのをなくしたい
    • プログラマにはマークダウン
    • 検索にひっかかるようにアーカイブにはしたいが、一覧には出ないようにする
    • キーボード操作が出来るようにしたい
    • 基本機能は2日で書いた
    • テストもかねて、Rails4とRuby2で実装。
    • フロントもbackboneなど新しいものを盛りこんでやってみた
  • 自分で使うために
    • サーバの運用は自分でしない。
    • バックアップも全自動。
    • 軽く動く
    • なので、Herokuで動作するようにする
    • 一晩で200人くらい登録した
    • メディアに紹介されそうになったので、真面目に開発しようとした
    • そのために、英語とデザインを何とかしたい
    • 英語
      • 知り合いに書きなおしてもらった
    • デザイン
  • 運用
  • プレスリリースも打った
    • ライターの知り合いに書いてもらった
    • 英語圏では、HackerNewsに書き込んだ
      • そのほうがいいらしい。
  • 得た物
    • 7000人くらいのユーザが居る
    • レビュー記事もある。
    • 英語や、その他のヨーロッパの言語でもレビューを書かれる
    • 要望のうち、プレビュー、Export、Evernoteなどはすでに対応済み
      • 複雑にしない範囲で、機能追加はしていきたい
  • まとめ
    • エンジニアにとって、自分で使うものを作れるのは特権
    • デザインはツールでなんとかなりそうだ
    • プロトタイプから、製品になるまで、10〜15倍かそれくらいの時間がかかる

Inside "お台場合衆国　リアルスコープブースサイネージ"

  • HTML5でサイネージは作れる
    • WebGLをメインに各種APIを利用
    • クオリティは担保しなければならない
    • 8時間連続起動しなくてはならない
      • リロードや再起動などはしない
      • スケジュールも1.5ヶ月程度でタイト
    • 42インチのタッチパネルのディスプレイを縦置き
  • 作ったもの
    • リアルスコープは、大人の社会科見学的な番組
    • クイズで3問だして、正解するとインセンティブがある
    • 最後にカメラで撮影して、後でダウンロード出来る
    • オープニング、エンディング、問題、解説などの動画がモリモリのコンテンツ
    • 背景はWebGLで書いている
    • 前面は、canvasの2Dでレンダリングしている
    • オーディオも流したり、タッチに反応したりする
    • 隠しコマンドで管理画面が出来るようになっている
      • 再起動も出来るようになっている
      • 写真が取れないケースはありそうなので、写真を取る事もできる
  • 感想
    • Web技術だけでもサイネージは作れる
    • でかいは正義
      • 42インチのディスプレイだと、開発時の画面等と全く違うコンテンツに見える
    • Google Chromeすごい
      • 普段どれだけ、技術的には出来るのに断念しているかを知ることが出来た
      • IEだと出来ないとか
  • ポイント
    • WebGLでリッチ感はアップする
    • プラグインなしで動画再生
    • カメラで撮影した画像をXHRでサーバに
    • UIをほぼFULL canvasで実装
      • 上がってきたデザインがほぼそのまま再現出来る
    • 画面がデカすぎて、普段慣れ親しんでいるUIはそのまま使えない
    • WebGLの部分、THREE.jsを利用するのがデファクトとなっている
      • しかし、今回はInka3Dを利用した
      • Maya2014に対応している
  • WebGL
    • Inka3Dで出力した
    • 難読化されているので、Mayaで作ったシーンを表示するくらいならOK
    • WebGLのcontext lostが多発している
    • WebGLのクラッシュでOSまで巻き込んで落ちる。
  • カメラ
    • パーミッションは最初の1回だけにしました
      • ストリームを保持し続けなければならない
    • httpsであれば、使用許可が1回で済む
      • httpだとリロード毎に聞かれる
  • 画像を別サーバに送信出来ない
    • クロスドメインの関係で直接アップロード出来ない
    • 送信先はローカルサーバに一度送信してから、ローカルサーバ内で処理させる
  • 動画の再生が止まる問題
    • エラーをキャッチしたら、強制的に、load/playをする
      • ただ、それでもダメな場合もある
      • JavaScript側から判断がつかない・・・
      • 動画の再生自体がダメになったのではとかんがえられる
      • VideoとCanvas要素には、CSS Shaderが効かない
  • メモリ管理
    • 8時間のロングランなので徹底して行った
  • 現場対応
    • 現場で想定される対応ををペーパープロトタイピングでやった
  • 耐久テスト
    • 8時間動かす
    • 出社したら起動、帰るまで再生しっぱなし
  • 実機テスト
    • 現場で使うものを借りてやった
    • 本番設置のために返さないといけないので、本番前はきつかった
  • 設置後
    • 現場で再起動した不具合をその場で修正→繁栄させる
    • SVNで管理していたので、svn upコマンドだけでOK
  • まとめ
    • Webとサイネージの親和性は高い！

Inside World Wide Maze

  • Chrome World Wide Maze
  • 主な技術
    • WebGL … THREE.js
    • Web Workers … ammo.js, physi.js
      • 裏側で処理する
      • ボールの動きの物理演算
    • Web Socket … Socket.IO
      • スマホの傾きデータをリアルタイムに送信するため
    • DeviceOrientation
      • 傾きを取るためのAPI
  • 制作で苦労したところ、全て
    • 6ヶ月かけて作った
    • 通常のキャンペーンサイト等は2ヶ月以内
  • スマートフォンの傾きをリアルタイムにPCに送信する
    • 傾き情報を取得する
    • windowにイベントリスナーを設定
    • 一定間隔で呼び出されるので、送信するだけ
    • イベントオブジェクトで、alpha、beta、gammaがXYZを表す
      • 仕様的には決まっている
      • んだけれども、実装がまちまちで間違っている
      • ある程度規則的に間違ってるので、変換すればOK
    • 取得した角度をPCに送ります
      • WebSocketで、つなぎっぱなし、リアルタイム、サーバからのプッシュもOK
      • スマホからPCに直接送る事は出来ない
      • 実際には、サーバを経由する必要がある
      • node.jsのSocket.IOでやっている
  • モバイルとPCのペアリングをどうするかをちゃんとしなければならない
    • 番号によるペアリング。
    • 間にサーバを挟むので、レイテンシーが発生します。
    • サーバがアメリカにあります
      • 200msかかります
      • Google Compute Engineを使っている関係で
  • WebRTCであれば、スマホからPCにデータ直接送れる

Inside マンガテレビ

  • マンガテレビ
    • リアルタイムにマンガチックなエフェクトをかけるアプリ
    • 漫画家の人と対談するときで、話のネタとして作りました
    • リアルタイムフィードバックしたり、コミュニケーションしたりしています。
  • マンガ化
    • getUserMediaでビデオ取得して
    • CanvasPixcelArray取得して
    • フィルター処理をする
  • 音声認識
    • WebSpeech API
    • W3Cでドラフトにもなっていない、Chromeのみで実装されている
    • 認識自体はGoogleさんががんばっています
      • 日本語でも、英語でも
    • 意外に重要なのが、httpsにすること
      • そうでないと、確認ダイアログが頻繁に出てしまう
      • カメラもそうだけど、こういうのはhttpではなく、httpsがいい
  • Headtrackr.js
    • 顔認識のためのライブラリ
    • Face.jsより高速で動く
      • ただし、最初の認識は遅い
      • 一度認識すると、その後は認識した周囲のみを認識するので早い
      • 一人しか認識しません
  • パフォーマンスについて
    • 毎フレーム30万回のループ処理をします。ここがキモです。
    • 1回の処理を10msで行わなければいけません。
    • Chromeのプロファイルは結構使える
      • 関数呼び出しは減らす
      • プロパティ参照は無くす
      • 演算処理はなるべく減らす
      • ビットシフトは、若干早くなる
    • パフォーマンスチューニングはエコ
      • 特にモバイルでは
      • 電池のもちがよくなるから

HTML5ガイドブック 増補改訂版 (Google Expert Series)

HTML5ガイドブック 増補改訂版 (Google Expert Series)

appengine ja night #25 #ajn25 に行ってきました

event appengine

会場についたらすでにピザが用意してあってビックリしました。
というわけで、メモです。PC忘れて行ったので、手書きの書き起こし。つらい。

App Engine の新機能の話 & Peter と話そう！

資料 → あるのかな？
App Engineの現状と、課題と、その解決のお話。すでに公開している情報も含まれています。

  • App Engine
    • 開発者がインフラを気にせずに開発できるようにしている
    • アプリやロジックに注力できる
    • 今まで順調にユーザが増えてきている
    • しかしながら、まだまだやらなくてはならないことが沢山ある
  • 現状
    • Versionが複数あり、複数のインスタンスが立ち上がる
    • Memcacheを使ったりもしている
    • バックエンドで動く機能や、データ解析をするような機能もある
    • Task QueueやBlob Storeなども使われている
    • ビジネスが成功すると、複数のアプリを使うことになる
      • 特性の違う機能でも同じ設定しかできなかったり
      • データを共有することが難しかったりする
  • 課題
    • DatastoreはApp Engineでしか使うことができない
    • Memcacheは1アプリでのみキャッシュが有効
      • Youtubeなどとも共有のものである
    • 規模が大きくなることの課題
      • Task Queueが滞ったり、タスクが消えたりしてしまう
      • Blob Store、Cloud Storageがバラバラ
  • 現在の取り組み
    • App Engine Modules
      • アプリを複数のコンポーネントに分割する
      • それぞれをバラバラに取り扱うことができる
      • それぞれのコンポーネントにスケーラビリティ、予算の設定ができるようになる
      • ただし、Storageについては共有することになる
    • 例
      • ひとつは、信頼性の高い、応答速度を求められるような機能で沢山のインスタンスを必要とする
      • もうひとつは、時間がかかる処理であるが、応答速度はそんなに求められない
      • これまでは、ひとつのアプリケーションで2つを両立していたために、高いインスタンスを沢山使う必要があった
      • App Engine Modulesでは、それぞれに対して、設定ができるので、コストを下げることができる
      • 開発チームの効率化も出来る
    • Dedicated Memcache
      • 今までのMemcacheと異なり、アプリ専用のMemcache領域を持つことが出来る
      • 必要であれば、容量は増やせる。
      • 2TB利用している顧客もいる。
      • 専用領域なので、長期間保持したい場合にも利用することが出来る
      • 今までは、共有していたため、すぐに消えていた
    • Blob StoreはCloud Storageに
      • 多くの場合には、Blob StoreよりもCloud Storageを利用したほうがよい
    • PHPもサポート
    • App EngineとCompute Engineの融合
      • 2つの方法を行っている
      • 1つはApp EngineとCompute Engineの通信を高速化するということ
      • そのために、データセンターを同じところに移した
      • App EngineとEC2に分けてやっていたことを、Google Cloud Platform1つで出来るようになった
      • もうひとつは、VMランタイム
      • App EngineによりカスタムしたVMである
      • 既存のApp Engineアプリをデプロイするだけでよく、Compute Engine上で動かすことが出来る
      • コードはそのままで、設定を1行変更するだけでよい
      • 他のバイナリ（アプリ）も動かすことが出来る
    • Task Queue
      • パフォーマンスと信頼性の向上
      • 使われ方が想定外で、思った以上に使われている
      • cronの代わりと想定していたが、1秒に5000のタスクが作られるとは・・・
    • DatasotoreをREST APIで公開
      • App EngineとEC2でDatastoreを共有することが出来るようになる
      • Hadoop用のプラグインを作った
      • Cloud Storageで動かすことが出来る
    • Cloud Playground
    • App EngineにVMが追加
      • Runでプロジェクトを実行
      • デプロイをブラウザ上で行うことが出来る
      • Compute Engineだが、App Engineで管理されている
      • どんな言語でもOK
      • App Engineで次にどの言語がサポートされるの？と言う疑問には、すべての言語と言うことが出来る
  • QA
    • Google モデレーター
    • アジアのデータセンターは年内に出来る？
      • No データセンターが複数無いと、分散することが出来ないので年内ではない
      • 複数エリアで作らないといけない。
      • たとえ、1つの国が無くなっても大丈夫なように作っているところです
      • 静的コンテンツに関しては、Edge-Cachingサーバが日本にある
    • Play Groundは自分の作ったものが他の人にコピーされるの？
      • Yes 引き回していきます
    • Python3は？
      • 予定はあるが、時期は未定
    • Cloud StorageとGoogle Appsとの連携は？
      • 今言えることはないです
    • Search ServiceのIndexの見積はどうやるの？
      • 確認します
    • Memcacheの1M制限について
      • 確認します。
      • Cloud Storageでどうにかなるかな？
    • Java Servlet3
      • VMランタイムで！
    • Blob Storeから、Cloud Storageに移行するとURLが変わってしまう？
      • エンジニアに確認しないとなんとも
      • スマホアプリでURLを使っているけど、リダイレクトとかどうなるのか知りたい
      • アプリのバージョンアップを必ずしてくれるわけではないので・・・
    • Backendsの問題
      • VMに置き換えられます。
      • ただし、7日間に1回はリスタートします
      • Backendsは残して欲しいとのリクエストもあるので、移行ではなく、機能追加かも？
    • Backendsのログが最後しか出ない
      • んー・・・
    • ステートフルにするような、sticky sessionをサポートする？
      • スケーラビリティがApp Engineの哲学です。App Engine道です。
      • スケーラビリティが中程度でよければ、Compute Engineを利用してください
      • 最近の傾向としては、クライアントサイドで状態を持ち、サーバ側はステートレスが良いでしょう

Android アプリのガチ開発者が Mobile Backend Starter を使ってみた

資料 → 「Android アプリのガチ開 発者が Mobile Backend Starter を使ってみた」

  • Mobile Backend Starterとは？
  • メリット
    • サーバ側のコードを書かなくて良い
      • アプリ開発者でサーバ側を知らない人とかには非常に嬉しい
    • スケーラビリティが高い
    • 認証の機能がある
    • GCM（Google Cloud Messaging）の機能が組み込まれている
  • 使い方
  • 使い道
    • メッセージング
    • データ永続化
    • クラッシュログ
    • センサーなどのログ
  • GCM
    • アプリ ⇔ Google Playアプリ ⇔ Google Playサーバ ⇔ サードパーティサーバ
    • サードパーティサーバが必要で、GCMを送信する機能を作らないといけない
    • pushする
      • 同期のトリガーや、チャット、SNSなど。
      • お知らせ、アプリの状態を同期
      • 位置情報の共有など
    • オフライン対応必須
      • デバイスのDBにもデータを持つ
      • Backup Agentと言うバックアップ機能がある
      • 同期が面倒でコンフリクトにも対応しなければならない
    • クラッシュログ
      • 自前のクラッシュログ機能を入れる人向け
      • 既存の提供されている機能は、動作しなかったり、ユーザが送信してくれるとは限らない
      • α版、β版など
    • センサーデータの収集
      • 歩いている、走っているの情報など
      • 定点カメラ的に、定期的に写真をアップするものなど
    • アプリ内課金の検証
      • アプリの公開鍵をサーバ側に持たせる
      • セキュアなハンドシェイク
    • 複雑なものは出来ない
  • Client Library
    • Androidアプリ用のSDKやライブラリを作るときに抑えておきたいこと
    • SDKやライブラリを使ったサンプルアプリは作りましょう
    • 広く使って欲しい人には必要です
    • サンプルとライブラリをバンドルしないようにしましょう
      • Androidに依存しないものは、jarファイルにする
      • Androidに依存するものは、Android Library Projectとして提供する
      • リソースIDには注意する必要があるので、プレフィックスをつけるなどする
      • ActionBar Sherlockが参考になる → ActionBarSherlock - Home
    • build pathには注意すること
    • 画面の回転には注意すること
  • まとめ
    • サーバを書かずにGCMが使えて便利
    • 1分もかからずにpush通知が来て便利

Google App Engine for PHP

資料 → appengine ja night #25 Google App Engine for PHP

  • Google App Engine for PHP概要
    • まだLimited Previewです。GAE/PHPがどうこうと言うより、現状はこうですと言う内容。
    • PHP 5.4.8
    • MySQL互換のCloud SQLを利用する
    • DatastoreはAPIを利用して使う
  • Google I/O後のアップデート
    • mbstringが使えなかったが、使えるようになった
    • mcript、iconvも追加された
      • Issue Trackerの報告を元に使いされているので、追加すれば入れてくれるかも？
    • Cloud Storageに置いたPHPファイルも動かすことが出来る
      • ただし、遅くなる
      • require "gs://mybacket/file.php"; // のように書くと読み込まれる
  • IDEについて
  • 既存アプリ
  • 気をつける点、制限
    • ローカルファイルが使えないのでCloud Storageを利用する
    • $_FILEが使えないので、Cloud Storageに対してアップロードするようにする
    • ファイルシステムに対するI/O
      • バグがある、存在チェックとか
      • realpathをサポートしていない、必ずファイルが見つからないと返される
      • ファイルアップロード、ログ出力なども注意
    • セッション管理
      • Memcacheのみで、制限がある
      • Session Handlerで、Cloud SQLに書き出すことも検討
    • メール
      • 標準のAPIは利用できない
      • MailServiceを使うように書き換える必要がある
    • 拡張モジュール
      • 入っていない拡張モジュールがあるかもしれない
  • フレームワーク
    • 一時ファイルを書き込まない
    • ログはSysログに書き出す
    • CakePHP
    • CakeMail
      • そのままでは駄目
      • MailServiceを使うように書き換えて、設定で変更しなければならなかった
      • 添付ファイルの送信も出来なかった
  • まとめ
    • アプリのポータビリティはそこそこあった。フレームワークも使えた。
    • 一部機能が透過的に動くようになればいいのに
      • メールとか、ファイルとか
    • スケーラビリティ
      • Datastoreも使えればいいのに

Google App Engine と Google Apps API

資料 → 2013-07-16 ajn - Google スライド

  • File APIとGCS Serviceについて
    • File API
      • 非推奨になりました
      • 1年くらいで使えなくなると思われる
      • 問題があってもサポートされないので、なるべく早く切り替えたほうが良さそう
    • GCS Service
      • pom.xmlに追加する
      • 依存ライブラリは、guavaだけなので、本体と、guavaのjarを追加するだけでも良さそう
      • API自体はFile APIと似ているので、置き換えは容易
  • 問題点
    • Cloud StorageはAPI Console Projectから
    • ただし、組織ドメインのアドレスしか追加できない
    • 対応1
    • 対応2
      • GAE Service Accountを追加したGoogle Groupを作成し、API Console ProjectにTeam Memberとして追加する
      • 特に知識無くても出来るので、敷居が低い
  • Cloud Console と Cloud Integration
    • Cloud Console
      • API Console Project, GAE Projectを連携した状態でプロジェクトを作成可能
    • Cloud Integration
      • GAEと連携した状態のAPI Console Projectを作ってくれる

何やかんやあって・・・

    • Cloud Console と Cloud Integrationを使うと、問題点が解決できると思ったが、そうはならなかった。
    • しかも、容易なはずの、対応2が出来なくなった。
  • まとめ
    • Google Apps向けのアプリを作っている人は
      • Cloud Console、Cloud Integrationの利用は、とりあえずは見送ったほうが良い
追記
  • Dedicated MemcacheをDelegated Memcacheと勘違いして書いていたのを指摘いただいたので修正しました。
  • GAE/PHPの内容で発表者の@vierjpさんから指摘いただいたので修正しました。

東京Node学園 9時限目 #tng9 に行って来ました

event nodejs

色々あって勉強会に出るのも久しぶりな気がします。
だいぶ遅くなりましたが、資料がアップされて下書きしていたのを思い出したので、メモを投下しておきます。


TV視聴参加型システムを支える伸縮可能型Socket.IOクラスタの裏側

資料 → TV視聴参加型システムを支える Socket.IOクラスタの裏側 // Speaker Deck

  • MIESとは
    • http://www.bascule-go.com/product/
    • ダブルスクリーン視聴によるテレビ番組への参加体験を提供する
    • スマートフォンの操作が連動する
    • テレビを見ながら、テレビとスマフォが連携する、それがテレビに表示される
    • BloodyTube
      • テレビの中のゲームに参加出来る
      • ポイントは実店舗で利用できる
    • これの裏側でMIESが動いている
  • リアルタイムメッセージングシステム
    • 要件
      • リアルタイムに友達の情報を共通したい
      • ブロードキャスト配信したい
      • 1つの案件ではなく、色々と使えるように汎用性を持たせたい
      • クロスブラウザ
      • なるべく安く
      • スケール、番組は1時間くらいだから、20万ユーザくらいはよろしくね。
    • Socket.IO
      • マルチトランスポート
    • 問題点
      • 2回アクセス問題
      • スケールアウト、RedisStore
      • プロキシで対応する
      • 独自ノード管理する　これを採用した
    • 何が出来るの？
  • ソケット接続確立まで
    • 一度コンシューマで認証してから、APIサーバに認証しにいく。
    • 接続先を返してもらって、そこからソケットサーバを見に行く。
  • メッセージ配信
    • ユーザAがAPIを叩くと、APIサーバがソケットサーバへ
    • ソケットサーバから別のユーザにプッシュする
  • メッセージ配信
    • コンシューマからAPIを叩く
    • APIサーバから、ソケットサーバ群にブロードキャストし、ソケットサーバがプッシュする
    • ソケットサーバ間もSocket.IOで接続する
      • パフォーマンスが良くなった。でも問題もある。
  • ノード管理
    • バッチでソケットサーバ群を監視している。その情報をDBに入れている
    • APIサーバはDBを参照して、どこに繋げれば良いかを判定する
    • ノード追加
      • 死んだら、DBを更新する、更新されたら、APIサーバは別のところにつなげるようにする
  • サーバTips
    • 特定のノードに偏らないように、ノード毎に重み付けを保持する
    • Socket.IOのコネクションの数により決定する
    • github node-sio ...
      • Socket.IOのパラメータ調整
      • reconnect_failedのバグがある
  • さらなるステップ
    • 実績
      • 同時20万ユーザ接続。テストですけど。今の構成で2倍3倍はいけそうです。
    • 100万超えを目指したい。
    • そのために
      • APIサーバとソケットサーバの結合度を下げる
      • 間にリレーサーバを挟む
      • ジョブキュー
      • Amazon SNS
      • データストア
      • Twemproxy＋Redis
      • Riakを検討
  • 1台あたりの接続数を上げるための施策
    • Cluster化を採用する
    • あるいはSocket.IOをやめる
      • Sock.js ただし、レイヤーが違うっぽいので、
      • Engine.io
  • まとめ
    • TVとスマフォがリアルタイムに連動するプラットフォーム
    • Socket.IOでも十分に大量の接続が捌ける が 工夫は必要
    • リアルタイムによる弊害を認識しておく
      • アクセスが集中しない工夫
      • ソケットが繋がらなかったクライアントも救う手段を用意しておく

Co-Meeting のリアルタイム Web プラクティス

co-meeting | リアルタイムコラボレーションツール

  • co-meeting
    • チームの全てを共有するリアルタイムコミュニケーションシステム
  • CROWY
  • co-meeting
    • リアルタイムな掲示板みたいなもの
    • Evernoteがリアルタイムになった感じのもの
    • インプット→まるまる→アウトプット
      • GithubのIssueとか
      • PivotalのTrackerのストーリー
      • BasecompのTodo
      • Redmineのチケットなど
  • 実装について
  • stunnel-haproxy で接続
    • リアルタイム意外の部分はRails
    • Jetty上でSocket.IO-Javaで実装している。ApacheWaveでチャットを使っている。
      • その関係でJavaで実装している
    • 画像系はAmazon S3
    • アプリケーションデータはMongoDB
    • RailsとのデータやりとりはRedis
    • OCFS2＋iSCSI
  • Apache Wave
    • Google Waveが前身です
      • 2009年9月プレビューリリース：リファレンス実装
      • 2010年5月 正式リリース（Google.IO）
      • 8月 クローズ宣言：Wave in a Box , work around
      • 2012年3月閉鎖：Apacheプロジェクト
  • waveプロトコル
    • 一文字一文字送信して、返す。
    • チューニングポイントでもある。
    • JSONでやりとりする。Wave GWTでHTMLをレンダリング
    • Jettyで受けて、Socket.ioからWaveサーバにいく。そこからProtcolBufferで。
    • WebSocket, XHR-PollingをSocket.ioで吸収する。
  • Socket.io-java
    • Socket.ioのプロトコルのJavaサーバー実装
    • Socket.ioの機能が利用できる
    • ただし、あんまり使っている人が居ない。
      • バグが多い、対応しているバージョンが古い
      • 本家がどこかわからない
      • 無いよりましな程度でしか使えない
  • 改修ポイント
    • Socket.io-javaは1人コケると全員アウト！
      • そこは非同期で吸収して、1個1個送るように修正しました。
    • レスポンスが帰ってこないと次が送らない
      • 競合の整合性を担保するためのもの
      • レスポンスのバージョンをあわせないといけない
      • 今は、ポップアップでアラートするにとどまっている
  • インフラとしてのJava
    • メモリ管理リツールや、ノウハウが豊富
  • Ruby on Rails + Apache Wave
    • ユーザ管理とか、普通の画面はJavaで実装する必要はない
    • Railsは何でも揃っているから、色々と頑張らなくてもよい
      • コアな部分にリソースを投入出来る
    • セッション情報は、Redisに登録する（RailsのセッションIDを使う）
    • Socket.io接続後、認証をリクエストする
  • RailsのPubsub
    • Rails側からPublishして、SubcribeでJetty側に通知して、ユーザにプッシュする、ユーザがRails側から取りに行く。

LT

Node.js + Unity
  • Unity
    • 3Dゲームの開発ツール＆ゲームエンジン
    • iOS,Android,デスクトップ向けが作れる
    • ゲームに限らず、３Dでやりたい場合には、Unityを使えばいいとおもう。
    • unity <-> node <-> smartphone
"Yeomanでtmlib.jsのゲームを量産する"話
  • tmlib
    • Time is Maney Library
    • ゲーム用のライブラリ
    • b-rogue
      • これもtmlibで作られている
  • 今、tmlibとsocket.ioでゲームを作っている。
    • YomanでScaffoldのツールを作って、やっています。
    • Yoman1.0で、yoって言うものになっています。
      • Gruntとかそのまま使えたほうが良いから。
    • Express
      • Scaffoldだけでこれが出来上がる
第1回 納涼もんご祭り
  • http://mongodb.jp/mongo/noryo2013/top*title
  • 7/28 東工大蔵前会館 参加費無料
  • 隅田川の花火の翌日です。いつきてもいいですよ。
  • 懇親会もあります。渋谷のイカセンターでやっています。
  • スタッフも募集しています。