@thorikiriのてょりっき

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

トップ > event

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

event html5 javascript

多少遅れて行ったので、途中からですけれども。急遽サテライト会場も出来るくらい大盛況だったようです。

JavaScriptテスト最新事情 Why? What? How?

資料 → JavaScript Unit Test Why? What? How?

  • なぜJavaScriptでテストを書くのか？
    • 実践アジャイルテスト
      • ビジネス面⇔技術面 の軸
      • チームを支援する⇔製品を評価する の軸
    • 結合テストは左上の領域
      • ビジネス面を支援する、技術面のテスト
      • どんなサービスでも必要
      • 自動化が推奨
    • ユニットテストは左下の領域
      • チームを支援する、技術面のテスト
      • 開発者による開発者のためのテスト
      • 大規模では必須
      • 自動化が必須
    • TDDと黄金の回転
  • JavaScriptを取り巻く状況
    • 規模も大きくなって、大事になってきている
    • ロジックをJavaScriptで書くことも多くなった
    • テストをする環境も充実してきている
      • node.jsによる恩恵
    • MV*が流行っている
      • モジュール化の仕組みが成熟してきている
    • ユニットテストがしやすくなった
  • JavaScriptのテストの難しい理由
    • コードがViewと結びつきやすい
    • どうしてもブラウザで実行されるので扱いづらい
  • 解決策
    • コードがViewと結びつきやすい
    • どうしてもブラウザで実行されるので扱いづらい
  • MV*
    • 色々宗派はあるが、やりたいことは、ロジックとビューを分離することである
    • 分離さえ出来てしまえば、ロジックのテストが出来るはず
  • 例
    • メール一覧
      • Model:全件取得する、宛先絞り込み、タグで絞込み
      • View：受け取ったリストを表示する
  • Modelのテストをしよう！
    • Viewのテストは。。。
      • DOMのテストは書きにくい
      • ユーザビリティのテストは出来ない
      • 画面を見ながら試行錯誤が必要になる
      • ある程度できてきたらテストにチャレンジしてみれば？
  • テスト
  • テスティングフレームワーク
    • テストの記述と実行を担当する
    • 成熟してきているのでどれを選んでも間違いはないレベル
  • 実行環境が重要
    • 実ブラウザでテスト
      • 本物だけど、面倒くさい、遅い
    • ヘッドレスブラウザ（PhantomJS）
    • シミュレータ（jsdom, envjs）
      • 偽物だけど早い
  • リモートテストランナー
    • ブラウザをキャプチャリングして、リモートでテストを実行するツールです
      • 一般的な言葉ではないかも
    • 実ブラウザの欠点を補う
    • 同時に複数のブラウザでTDDが可能
    • Testem、Karma(旧名称 Testacular)、JsTestDriver、Buster.JSなど
  • DEMO
    • Jasmine + Testemを使うのが導入が簡単
    • 簡単なFizzBuzz
    • npm install testemで一発でインストール
    • コマンドでテストを実行する
      • TDDする、実行すると、実装が無いのでエラーになる
    • 実装を書いてあげる
      • テストが成功する
    • テストを追加していく
    • 特に設定ファイルとか書かなくても始められるので、お手軽
    • PhantomJSとも連携できる
  • それ以外
    • カバレッジ
    • 静的解析
    • Lint
    • 型チェク（Cloure、TypeScript
    • それらをまとめるGruntなど
  • まとめ
    • JSでもユニットテストは大事
    • モデルのテストからはじめよう
    • テスト関連ツールの深化がやばい
    • TDDで楽しい開発

いつやるのか？今でしょ！

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践)

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践)

実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)

実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)

jasmine

資料 → Unit-Testing With Jasmine // Speaker Deck

  • jasmineを使ったユニットテストについて
    • BDDとは？
    • jasmineとは
    • それらについてくわしく
    • jasmineで使えるツール
    • クリスチャンヨハンセンの言葉
      • テスタビリティはグッドデザインである
      • もしテストするのが難しければ、それはコード自体が良くない
    • jasmineはBDDのツールです
  • BDDとは？
    • BDDはTDDから派生したもの
    • TDDの混乱や誤解の6個
      • どこから始めるのか
      • なにをテストするのか
      • なにをテストする必要はないのか
      • どの程度テストすれば良いか
      • テストを何と呼ぶか
      • テストが失敗した理由をどう理解するか
    • その回答
      • これから作成しようとしているプログラムに期待されている振る舞いや制約条件を記述する
      • アプリケーション全体ではなく、小さく1つのことのみ記述する
      • テストを文章のように記述する
      • ビジネスの観点を入れる
      • JasmineはBDDをJavaScriptで実践するためのツール
  • Jasmineとは？
    • ある仕様に対して、コードがどんな振る舞いをするべきかを表現するのを手助けしてくれるツール
    • ダウンロードすると、サンプルが含まれている
    • Jasmineは本当にシンプル
      • describe: Suite（スィート）と言う
      • it：Spec（スペック）と言う。プログラムの断片がおこなうこと
      • describeの中でdescribeを定義をすることもできる
      • expect：期待される振る舞いを書く。英語の文章のようになる。
      • toEqualのような比較することをMatcherと言う
      • ○○が含まれている場合のMatcherは、toContain
      • Matcherの一覧はドキュメントを参照
  • Jasmineについて詳しく
    • Before/After
      • beforeEach() / afterEach()
      • たいていの場合はセットです
    • Async
      • waitsFor
      • 指定の時間まで繰り返す
      • 1000ms以内に値を返さないと失敗とみなすなど
    • SPY
      • Test Double : UTのパターンのひとつ
      • 関数に成り代わって、その関数がどう呼び出されたのかを教えてくれる
      • 関数が呼び出されたか、何回、引数は？など
  • Jasmineまとめ
    • Jasmine単体で使えるわりには、色々出来る。
    • Jasmineは歴史があるので、様々な補助ツールがある
  • 厳選ツール
  • まとめ
    • テストを書くことは、デベロッパーズブロックに解消につながる
      • 文章がかけなくなることをライターズブロックと言う
      • 書くことでしか解決しない
    • ライターが推敲するように、デベロッパーはリファクタリングする
    • そのためにはテストが必要
    • アウトラインをテストで書くことでリファクタリングに強くなる
    • テストがあれば再利用しやすくなる

テスト駆動JavaScript

テスト駆動JavaScript

SinonJS

資料 → Sinon.JS

  • SinonJS
    • 神話の中のスパイの名前
  • Sinon.JSとは？
    • Test Doubleのライブラリ
    • QUnitやMochaなどと組み合わせて使用する
    • Test Doubleとは？
      • テストしずらい部品をしやすいものに置き換えてテストする
  • Spy
    • Queryのtriggerの例
      • 1回しか呼び出されないときは簡単だが、2回呼び出されたことをテストするのは面倒である
      • カウンターとかで判断しなければならないため
    • Spyはその面倒なことを解決してくれるもの
      • スパイオブジェクトを作る
      • スパイオブジェクトは、何回呼び出されたか、どんな引数で呼ばれたかを保持する
      • 通常であればカウンターを使って書いたものが、簡単に表現出来るよ
      • イベントは、発火していなくても通ってしまう不具合等が発覚しづらい
      • 書いた順に呼ばれるので、Spyであれば見やすい
      • callbackは記述の順番と実行の順番が異なるので見にくい
    • 既存のメソッドをSpy化することも出来る
      • jQueryのremoveメソッドをテストするのは面倒である
      • removeをスパイする
      • var spy = sinon.spy(jQuery.fn, 'remove');
      • 既存のメソッドをどのように呼ばれたかがわかるようになる
      • Spyは、書き換えてしまうので、Before,AfterでRestoreする必要がある
  • Stub
    • Spyを拡張しているのでSpyの機能を持っている
      • 元の関数を上書きする
      • 例えば、window.confirm等（書き換えないとテストしてられない）
      • スタブでwindow.confirmを上書きする
      • どう振る舞うかを設定することが出来る。例えば、必ずtrueを返す等
  • Mock
    • Stubを拡張しているので、Spy、Stubの機能を持っている
    • 予め、どう振る舞うかを定義しておく
    • mock.verify()を呼べば、振るまいが定義した通り動いたかを判定できる
    • MockとStubは同じ事が出来るので、使い分けすれば良い
      • Stubの方がわかりやすいかもしれない
  • Fake Timer
    • 日付に関するところが面倒である
      • 日曜日か判定するテストは、日曜日しか通らなくなる
      • UseFakeTimeで、日付を指定する
      • 必ずリストアすること
    • setTimeoutなどのTimerを変えることが出来る
      • 時間を進めることが出来る
      • clock.tick()関数を使う
      • 簡単に、同期的にテストをすることが出来ま
  • Fake XHR
    • リクエストがちゃんと飛んでいるかを確認する
      • 通信する部分をまるごと書き換える
    • 別の書き方で、FakeServerもある
      • 比較的直感的になる
  • まとめ
    • Sinon.jsとても便利
      • でも、使いすぎには注意しましょう
    • 何でもかんでも、MockやStubにするのはやめておこう
      • 何をテストしているのかわからなくなる
  • 宣伝
    • CodeGridのサービスをやっています
    • 週3回配信
    • 月額840円で、初回1ヶ月は無料

JSテストフレームワークの比較（QUnit、Mocha、Jasmine...）

資料 → Java script testing framework for around html5 studies-

講演者による座談会

  • テストをテスト未経験者に取り入れてもらうには
    • 佐伯さん
      • 自分の経験では、最初に訓練をうけたので、それが当たり前だと思っている
      • 開発標準を決めてしまう会社なので、盛り込んでしまえば良い
    • 斎藤さん
      • テストが楽しそうというところからはじまった
      • コードを書く上で大切なひとつのプロセスである
      • ペアプロでやっていくのがいいのかなぁ
      • 赤いものを緑にしたくなるゲーム性
      • 一緒にみていくのがいい
    • 佐藤さん
      • テストのスケルトンとか、生成するものを作ってくれた
      • 書き始めるまでが、よっこらしょだったのが、楽になった
      • とりあえず、コンストラクタまででいいから書けよがルール
    • 外村さん
      • ちょっとしたライブラリから始めたらいいのではないかな
      • いきなりアプリだと難しい
  • テストを書いていてよかったと思ったエピソード
    • 斎藤さん
      • テストがある状態のコードがあれば、いきなりリファクタリング出来る
      • まず、綺麗にしてからコーディングすることが可能
    • 佐藤さん
      • コードの書出しが苦しむところ
      • まずテストを書いてしまえば、滑り出しがよくなる
      • コメントで書いていたことをテストに置き換えた
    • 佐伯さん
      • テスト無しでリファクタリングはありえない
      • 途中で任された場合
      • ちゃんとメンテナンスされていれば、そこから仕様を読み取れるので良いですよね
    • 外村さん
      • 1年前に書いたコードをメンテナンスすることになった時に良かったと感じました
  • システムの規模は
    • 佐伯さん
      • 逆に聞きたいです
    • 斎藤さん
      • プロジェクトのしごとをあんまりしていないので、あんまりわかんないです
      • 100％書きたいですが、一旦メインで30％書いて、あとはドキュメンテーション
    • 佐藤さん
      • kintonを作っています、3年以上開発
      • JavaScriptだけで17万行あります
      • フレームワークにClosureライブラリを使っているので、冗長感はあります
      • テストコードは2万行強、カバレッジは計測していない
      • 結合テストも合わせてやっていた。結合テスト偏重だった
      • だんだん立ち行かなくなったので、UTを今増やしているところ
      • カバレッジは？
      • 30%くらいですかね
  • 結合テストはどこまでやっているか
    • 佐伯さん
      • やんなきゃいけない。Seleniumでやっている
      • Unitが足りてないので、片手落ち
    • 斎藤さん
      • Unitテストはやっているけど、結合テストはやっていないような状況
    • 佐藤さん
      • Seleniumはやっていると膨大な時間がかかってしまう
      • 受け入れテストレベルに限定すると、現実的な時間で終わるようになる
      • Seleniumは何を作るべきかを担保する
      • 中身については、Unitでやっていこうよ！となっています
      • Jenkinsで回しています
      • 対応ブラウザもろもろで
  • UI（View）のテストをどこまでやっているか
    • 佐藤さん
      • Viewの部分はあんまり書いていない
      • Renderで要素が入った・・・くらいまでしかやっていない
      • Clousureライブラリだと、JavaScriptの型チェックが出来る
      • よってビューのテストは型チェックだけ通ればOKだとおもわれる
      • それ以上のロジックが書かれていないことが前提
    • 斎藤さん
      • ロジックの部分がほとんどです
      • Renderに入ったとこくらいです
    • 佐伯さん
      • やってないっす
      • 導入する時に、ここまでやればいいんだよ！って決めてしまえばいいだけです
      • むしろ、ちゃんとアーキテクチャを設計するのが先で、後は、努力目標とすればよいと思います
  • TDD VS BDDについて
    • 外村さん
      • どっちでもいいと思います！
    • 佐藤さん
      • 違いが正直わかっていません
      • 書き方レベルで言うと、BDDの方が好きです
      • テスト名を文字列で定義出来るのがいいですね
      • 2重のフィードバック・ループを考えるとBDDになるのではないでしょうか。
    • 斎藤さん
      • 平和主義なので、どっちでもいいです
      • スタイルとしては、BDDの方が好みではあります
      • テストがあればいいよ
    • 佐伯さん
      • テストの見通しをもった上では、BDDの方がいいのかなとは思います
      • ペアプロでやるのでは、BDDの方がやりやすいかもしれないですね
QAタイム
  • テスト結果の出力は？
    • 佐藤さん
      • テストはCIツール（Jenkins）でやっています。
      • リポジトリにコミットするごとに動きます。
      • それで、エラーがあれば通知しています。
  • テストの工数はどうやってもらえますか？
    • 佐藤さん
      • 難しいので、誤解を恐れずに言えば、多めに工数を取ればよいです。
      • コードを品質を担保するためには、その工数を取ればいいです。やましいとかではないです。
      • 細かいこと言ってもしょうがないです。技術じゃない人に対して。
      • これを実装するなら、これくらいと言ってしまえば良いのでは。
    • 佐伯さん
      • お客さんに、最初に説明をしました。
      • その上で、納得して頂く。結構しっかりやっていたパターンです。
    • 外村さん
      • バグったらその分工数食うんだから、最初から取っておいてもいいのではないか

Googleのえーじさん

東京Node学園 8時限目 #tng8 に行ってきました

event nodejs javascript

と言うことで、メモを投下。

Param Tuner

資料 → ParamTuner 東京Node学園#8
しばらく中に入れなくて、聞けてませんでした。
統計解析の話だったようです。資料見て自習します。

  • QA
    • JavaScriptで統計解析やるにあたってデータの量とかはどうなんですか？
      • 実際にはHadoopで裏でやっていますが、その前段階の傾向を見るのに使っています
      • なので、そんなにデータは多くはないです。

Nodeとプロミスと時々、関数型

資料 → Node, Promises and Functional Programming // Speaker Deck

  • ことの経緯
  • 非同期処理を書く時に何を考えるのか？
    • タスク同士の依存関係を考える
    • 必要な操作の順序を考える
    • 最後に、その制御フローを考える
  • コールバック VS プロミス
    • コールバックの良くないところ
      • 処理をモジュール化したり組み立てたりするのが難しい
      • 逐次処理か並列処理かを明示的に制御する必要がある。
      • あと、ネストが深くなってしまう問題があるけど、重要な論点ではない。
  • 例
    • 複数のファイルを並列的にfs.statしてmtimeを取り出す処理
    • 複数ファイル全ての結果が揃ったら次の処理を行う
    • この実装をした後に、追加の処理を入れたいとする
      • 1つ目のファイルからサイズを取り出したい処理を追加
    • 単純に追加すると、ファイルに2度アクセスすることになり効率が悪くなる
    • 正しい順序で、効率良く処理させると、実装がかなり複雑になる
    • 結果
      • 正しくコードを書くのが大変
      • 設計の意図が明確にならないので、メンテナンスが大変
      • 逐次処理か並列処理かで、後続の処理を実装する方法が変わってしまう
  • プロミスとは
    • 完了していないかもしれない計算の結果が入っている箱
    • プロミス自体も値なので、関数の間で受け渡しが出来る
    • 計算が完了すると特定の処理を呼び出したりする（ものが多い）
  • しかしながら
    • 必ずしも全てのプロミスが関数型ではない
    • 言語やライブラリによって異なる
  • 関数型とは？
    • あらゆるものを値として扱うことで問題を解く手法
    • 命令型はHowを記述して伝える
    • 関数型はWhatを値同士の関係によって記述して伝える
      • 関数は、値同士の依存関係を定義するもの
    • 関数は、引数を得て、戻り値を返す
      • 複数の関数を合成して、大きな関数にする
      • 別の関数への入力として、パイプラインを作る。
  • 関数型プログラミング
    • あらゆるものを値として扱い、
    • 値同士の依存関係を関数で表現し、
    • 複数の関数を合成してより大きな関数を作る
  • 先の例で言うと
    • 複数の非同期計算を合成して大きな計算をする
    • 後で処理を追加したいときには
      • thenを使う
      • thenは、プロミスに依存する別の非同期処理を記述する
      • thenで記述された処理は、値がいつ利用可能になり、どんな順番で処理するかを気にする必要がない
  • プロミスとthenを使うと
    • 記述された依存関係を元に実行順序を自動的に解決するので、
    • 依存関係でプログラミング出来る
  • 結果を待ちたい場合
    • プロミスの配列をリストに対するプロミスにする
    • これによって待合せが表現できる
  • 課題に戻って
    • プロミスを使うと、必要な操作の順序を考えなくても良い
    • なので、非常にシンプルにプログラミングが出来る
  • プロミスは難しい
    • 先のブログに対する反論記事
    • プロミスを使うと
      • thenやlistで意味的に隠蔽してしまうので、認知的コストが大きい
      • プロミスを使ったものは、学習コストがかかる
  • 反論に対する反論
    • 簡単であるかよりも、シンプルであるかを問うべき
    • やりたいことが変わった時に、コードの変更が少なくて済む
  • 結局
    • どちらもただしいと思う
    • コストとメリットを天秤にかける
      • ただ、非同期プログラミングのコストの支払期限は意外と早いのでは？
  • まとめ
    • コールバックはとっつきやすい
    • 変更に強くするならプロミス
  • メッセージ
@koichik さんから
  • 3年ほど前はnode.jsでもプロミスを使っていました
  • しかしながら、あんまり評判が良くなかったようです。
  • プロミスが嫌われていたのは、プロミス自身ではなくて、JavaScriptでのプロミス自身がいけていなかったから。
  • 先の例で言うと、実際にはエラー処理をしなければならないが記述されていない
  • エラー処理を実装すると、結局冗長にせざるを得ない
  • 現在、node.jsではメカニズムとして一番シンプルなコールバックのみ提供している
  • プロミスの実装は、別のモジュールで色々な人が作っている
  • node.jsのスタンスとしては、モジュールとして好きなものを作っていいよということが現在のスタンス

LT

LET IT CRASH!?

資料 → 東京Node学園#8 Let It Crash!?

  • Let It Crash?
  • 堅牢なコードを書くには？
    • ディフェンシブプログラミング
      • 失敗する可能性があるものは失敗するので、失敗に備えておこう
      • 引数などはチェック、例外を捕まえる
      • アプリがエラーから回復する
      • 通常処理とエラー処理が混在する
    • Let it crash
      • 失敗に備えない
      • 例外を捕まえないで、スーパーバイザがエラーから回復する
      • 通常の処理と分離出来る
  • スーパーバイザ
    • 1つクラッシュすれば、それだけリトライ。One4One
    • 1つクラッシュすれば、関連を全てリトライ。All4One
  • You! さっさとクラッシュしちゃいなよ!
    • process.on('uncaughtException')
      • OnErrorResumeNextとは違うのですよ。
    • domain.on('error')
      • エラーを無視するな
      • エラーが起きたら、プロセスをシャットダウンしなさい

といった所でLTタイム終了しちゃいましたが、まだ半分までです。
domainのAPIドキュメントを見てね！

LT2 Object.defineProperty

資料 → 不明

  • Object.defineProperty
var obj = {};
Object.defineProperty(obj, 'prop', {
    // ここにプロパティのオプションを書く
});
  • オプション
    • configure
      • falseを設定すると、上書きとか削除とかできなくする
    • enumerable
      • for inのループで出てこなくなる
    • wraitable
      • 上書きできなくなる。
      • 定数とか。厳密には定数とは違う。現状のJavaScriptで実現出来る方法。
    • get, set
      • getter / setter が定義が出来る
  • 複数のプロパティをまとめて定義することも可能
Object.defineProperty(obj, {
    'prop1': {
         // オプション
    },
    'prop2': {
        // オプション
    }
})

サーバサイドJavaScript Node.js入門

サーバサイドJavaScript Node.js入門

appengine ja night #24 #ajn24 に行ってきました

event appengine

というわけで、メモです。

ゲスト Googleアジア・パシフィックの方

Appengineへこれまでの投資や利用ありがとうございます。皆さんの貢献ありがとうございます。これからの継続的な発展を期待しています。
アジア・パシフィックは日本での成功に依存しています。アジア・パシフィックでは、年度内に3つのデータセンターを作ろうとしていて、さらにサポートも強化していきます。
Google Cloud Support Services — Google Cloud Platform

  • 質問
    • データセンターに東京は？
    • ヨーロッパでは選択出来るみたいだけど、選択出来るの？
      • AppEngineとComputeEngineは、EUとアメリカで選択出来る。アジア・パシフィックも同じように選択出来る。
  • Google Compute Engine
    • Google Compute Engineも使えるようになっている
    • GoldSupportに入って頂く必要がある

ゲスト Google法人営業の方

昨年から、Google Cloud Platformの営業活動を始めている。日本は2名体制となっています。
サポートのパッケージがグローバルで変更になりましたので、アナウンスします。
オンラインサインアップで、クレジットカードで申し込めます。今は、フォーラムでのQAがメインです。
もう一つの契約形態で、契約書ベースのものもあります。カスタマーサポート部隊でサポートします。
今までは日中時間帯のみでしたが、いつでもよくなりました。

  • 契約は4段階
    • ブロンズ：無償のフォーラム形式のみ
    • シルバー、ゴールド、プラチナが有料
      • 昨年までは1つでした。シルバーサポート同等で、月額500ドルでGoogle App Engineで、他プロダクト毎に＋α
    • 今回、法人ごとに1契約で済むようになりました。
    • 今までと同じ内容よければ、シルバーサポートで、月額150ドル
    • ゴールドは、24時間365日
      • 電話は英語になる
      • ポータルでは英語だけど、日本語書いてもOK
    • プラチナは、完全にカスタマイズなサポート
      • エンジニアを1人貼り付けるとかそういうこと
    • Google Compute Engineが誰でも使えるようになったが、Goldサポートがないとダメ

セッション1：「Google Cloud Endpointsを使って作るJS/Android/iOS対応Webバックエンド」「BigQueryの大規模JOINとGROUP BY」

資料 → appengine ja night #24 Google Cloud Endpoints and BigQuery

Google Cloud Endpoints
  • 概要
    • AppEngineをクライアントアプリのバックエンドとしてより簡単に使えるようにするもの
    • クライアントーサーバで連携する場合
      • Endpointsでは、通信部分が隠蔽される
      • クライアントライブラリのメソッドを呼ぶだけで、サーバのメソッドを呼び出すことが出来る
      • サーバのことを知らない人でもOK
    • Android、iOS、JavaScriptのクライアントライブラリを作成可能
    • OAuth2.0認証をサポートしている
    • Google App Engineで動いているので、Datastoreなど各種Serviceを利用することが出来る
    • APIエクスプローラで実行可能
      • Google APIs Discovery Serviceに準拠しているため
      • Endpointsで生成したクライアントライブラリは準拠するので使うことが出来る
    • OAuth2での認証した状態でのAPI実行も可能
  • 実装手順
    • 環境
    • 手順
      • プロジェクト作成
      • サーバ側実装
      • APIエクスプローラで動作確認
      • クライアントライブラリの生成
      • クライアントの実装
    • プロジェクと作成
      • Androidアプリを作る場合、クライアントとなるAndroidプロジェクトを作ってから、連携用のサーバ側プロジェクトを作ったほうが良い
      • Androidアプリが不要の場合、普通にサーバ側プロジェクトを作れば良い
    • サーバ側実装
    • 異常系の場合
      • NotFoundException
      • InternalServerErrorException
      • HTTPのステータスコードごとにある
      • 例外を自作する場合には、ServiceExceptionを継承して作る
      • アノテーションに指定した情報が、APIのなるので、命名などには気を使った方が良い
    • ポイント
      • API名は、小文字から始める
      • 戻り値として、リテラルは使えないし、EntityクラスもNG
      • 独自のDTOクラスを作る
      • リテラルを戻り値にしてもコンパイルエラー等は発生しないが、クライアントライブラリを生成する時にエラーが出る
      • ページングにはCollectionResponseをつかうと、ページング情報を保持できる。
      • HttpServletRequestなども引数にすれば使える
    • JUnit
      • Slim3をつかうと簡単です
    • APIエクスプローラでのテスト
      • 必須項目は赤字
      • プットではテキストフィールドを入力する
      • OAuthが必要で認証していない場合エラーになる
      • エクスプローラの右上のON,OFFボタンで認証する
      • 認証してからだと正常にput出来る
    • クライアントライブラリ作成
      • エラーはこのタイミングで表示される
      • Eclipseの「問題」のタブではないので注意すること
  • クライアントの実装
    • JS
      • AngularJSとの連携
      • APIの実行後のコールバックで$scope.$apply()を呼ぶ必要がある
      • エラーハンドリング
      • エラーメッセージとステータスコードを元に判断する
      • エラーはローカル環境と、サーバ環境で異なってしまっているので注意してください
      • 今後修正されるかもしれません
    • Android
      • CloudEndpointUtilsを使うと良いかもしれない
      • 例外は、GoogleJsonResponseExceptionでキャッチする
      • ステータスコードとエラーメッセージでハンドリングする
      • 通信出来ない場合は、IOExceptionが発生しますので、ハンドリングする
    • ポイント
      • 一度書き方を覚えてしまえば、通信処理とかを考える必要はない
      • Google純正のAPIと似ているので、実装の参考にすると良い
    • CloudEndpointsUtilを使う場合
      • デバッグ用の環境に接続出来る
      • 設定が必要
  • OAuth2認証
    • APIConsoleでClinetIDを作成
      • クライアントの種類ごとに作成
    • Androidの場合は、Audienceの定義も必要
    • APIメソッドの引数に、User userを付け加える
      • 認証していない時にはUserがnullになるので、nullかどうかで判断する
    • クライアントJavaScript
      • CLIENT_IDを設定して、SCOPEを設定
      • SCOPEとしてuserinfo.emailが必要
      • load関数でoauthを読み込んでサインインする
    • Androidの場合もサンプルどおりでOK
      • GoogleAccountCredentioanが必要。
      • アカウント取得用のPicker経由でアカウントを取得して、認証する。
    • OAuth2での開発での注意点
      • APIエクスプローラからと、JavaScriptやAndroidからとで、サーバ側の挙動が異なる場合がある
      • User型のデータから取得出来る項目に差異がある
      • ID TOKENと、ACCESS TOKENでのアクセスとで違うから
      • 本日リリースされた最新版でも治っていなかった
  • 資料一覧
BigQueryのBigJoin
  • BigQuery
    • テラバイトクラスのデータを扱えるようにする
    • SQLライクなクエリが出来る
  • 今までは、JOINする対象のテーブルに制限があったが、BigJoinによって制限がなくなった
  • GROUP BYも同様
    • GROUP BY → GROUP EACH BYにするだけ
  • 以前より制限が緩和されました
    • 一応、ドキュメント上は制限がなくなったとはありましたが、大きいデータで、エラーが発生したり、帰って来なかったりします
    • 限界がどこにあるかはわかりませんが、お金がかかるので検証出来ていません
  • 参考資料
QA
  • Google Cloud Endpoints
    • テストの時に、Mockを返すには？
      • わかんないっす
    • 認証関係のテストは？
    • 生産性上がるの？メリットは？
      • 通信部分を作りこまなくて良いのがメリット
      • BaaSではなく、RPCのフレームワークと言える
      • JavaScript、Android、iOSのクライアントライブラリがつくれるのがメリット
  • BigQuery
    • 常にEACHをつけたら？
      • EACHを付けない方が速度は早いです
    • サブクエリでGROUP BYするとエラーになるのですが
      • 小さいサブセットでやってみてください
      • 必ずエラーになるのであればIssueを登録します
      • 結果が大きいとエラーになるので、それが原因の可能性もある

セッション2 「Datastoreへのアクセスを楽してMemcacheアクセスに置き換えるライブラリ作った in GAE/J」

資料 → Datastoreへのアクセスを楽してMemcacheアクセスに置き換えるライブラリ作った

  • Google App Engine Datastore
    • お金がかかる
      • Datastoreに対するREAD、WRITEの回数に応じて課金される
      • 1回Entityをputすると、Entity本体の他に、Indexを更新する
    • Memcacheを使ってREAD回数を減らす
      • 通常は、Memcacheにデータがあればそれを使い、なければDatastoreから取得する
      • put時には、Memcacheから削除するなどする
      • Queryを保持している場合、Memcacheからデータをクリアしてあげなければ、更新時に正しくなくなる
      • がんばって実装して、正しい状態を保たなければならない
      • 一箇所にデータアクセスを纏めなければ、バグの温床になる
      • Memcacheを使えば、安くなるけど、複雑になる
  • Memvache（めむばっしゅ）
    • データストアへのアクセスを書き換えてMemcacheを使う
    • Memcacheを使っていないコードはそのままでOK
  • 仕組み
    • 通常の流れは次の通り
      • Request→AppServer→RPC→Datastore
    • RPCの裏で流れているデータをフックして、実装している
      • ProtcolBufferでSerializeなどをやっている。
    • ApiProxyのgetDelegate, setDelegateで書き換えている
      • getDelegateを書き換えている
  • Memvache
    • Strategyを組み合わせている
    • PutとGetでMemcacheに置き換える場合
      • GetPutCacheStrategy
      • Txが効いている場合は素通りになる
    • QueryをMemcacheに置き換える場合
      • QueryKeysOnlyStrategy
      • 自動的に、KeysOnlyに書き換える
      • Keyをゲットしたら、BatchGetを実行する
      • EventualなEntityをとれる問題も回避出来ます
      • 少なくとも、古いデータではない
      • ただし、正しい検索結果には必ずしもならない
    • Queryをまるごと自動でキャッシュする
      • AggressiveQueryCacheStorategy
      • Kindが更新されたら、カウントをインクリメントする
      • キャッシュ自体は消さない
  • 導入方法
  • 自作のStorategyを作る
    • Storategyを実装して、preProcessとpostProcessを実装する
    • 自作のFilterを作らないといけない
    • RpcVisitor もあり、フックすることが可能
  • AggressiceQueryCacheStrategy
    • 設定ファイルを書く
    • 期間と、無視するKindを設定する
      • ただし、今後変更する可能性もあります。
  • 問題点
    • Slim3以外での利用実績がない
      • JPAとか、生のLL APIとかの実績
    • Slim3以外の環境では、バグが出る可能性があるので、何かあったら教えて下さい
    • ProjectionQueryは考慮対象外になります
    • プロジェクトの途中から導入したことはないので、気をつけて。
    • AggressiveQueryCacheStorategyの無効な理由
      • 内部的に、状態を持っているので、不用意にキャッシュ出来ないため
      • Cursorには、IDが振られていて、キャッシュしたQueryだと、IDが・・・。
      • 後で、Nextが発生するとやばい
      • Limit ＜ PrefetchSize であればOKかもしれない
  • GAE活用事例
    • TopGate社の場合
      • Android 3〜4割
      • GAE 2〜3割
      • GAE + Google Apps 2〜3割
      • GAE + AWS 1割 （ファイルをあつかうもの）
      • 今後は、GAE＋GCEになるかも
    • 製品
      • SmartBiz＋
      • Chienoki 社内ナレッジベース的なもの GAE＋Appsを利用
    • Memvache
      • 2案件、まだリリースしていない
      • 個人での利用はあり
  • その他
    • DatastoreV4
      • 現在は、DatastoreV3です。
    • GAE/Go正式版まだー？
    • GAE/Python
      • ndbで同様なことをやっているらしい
      • いいアイデアあったら教えて下さい
  • QA
    • データストア以外を触るは？URLFetchとか
      • Memcache以外は今のところ考えていませんでした
      • おれおれStorategyで実装すればいけると思う
    • ライセンスは？
      • Apache2 です。
    • ダッシュボードから触る場合は？
      • 開発環境では、Filterが適応されるので大丈夫かもしれません
      • プロダクション環境では、Flushしてください
    • 効果は？
      • 計測はしていない
      • ケースバイケース
      • ちゃんと使えば9割くらいだと思う
      • PUTが多いアプリだと恩恵が少ない
    • LocalCacheについては？
      • static変数で保持するのもStorategyで作れる？
      • 作れるとおもう

BeerTalk（懇親会）

BeerTalk1：「Google App Engineを使って仕事をするということ」
  • 仕事で使うメリット
    • 開発環境をすぐに構築できる
    • 複製も出来る、○○環境用
    • 環境構築しなくてよい
    • 運用費の見積はむずかしい
    • システム管理者の管理が簡単
    • ログインも簡単、Google Account
  • 苦労
    • Kind設計
    • 60秒制限が、業務用では厳しい場合もある
    • 他システムとの連携で相手側のIP制限が出来ない
    • ログの保存が大変
  • 業務アプリの特徴
    • CPU利用率で・・・20%しかつかっていない
    • ただし、データ量が結構多い
    • マスタ件数が25万件とか
      • 月1で全量更新
    • マスタ件数10万件で、毎日全量更新
    • 小さい規模の会社でもサーバとかいらないから色々出来る
  • GA使用料
    • 114アプリで、100ドル+サポート500ドル
  • 検証
    • 検証してほしいもの募集です
  • QA
    • 見積はどうしてるの？
      • READ/WRITEの量、
      • Indexの貼り方で変わるけどノウハウ
      • アプリ保守料という形でやってます。とは言え、実績はまだまだです。
    • 整合性
      • EntityGroupは使っていない
      • あんまりシビアな状態はない
      • 数万人規模であれば、そんなでもない
      • 業務アプリの場合は、夜間に止めるなど出来るので大丈夫
    • 年末に不安定になることは？
      • 今のところ３０分程度で復旧するので、問題無さそう
BeerTalk2：「Dig・基幹系でAppEngineを掘る」

資料 → Ajn24

  • 基幹系でAppEngine
    • ジャーナルエントリーが発生するものです
    • Cloud First
    • Offline First
      • Offlineでの操作をする。
      • 日本以外では、Offlineが圧倒的に早い。
    • Mobile First
  • 基幹系
    • CloudSQLはDatastoreに比べて遅い
    • Memcacheの方が圧倒的に早い
    • とは言え、Client側で図ると、あんまり変わらない
      • ネットワークレイテンシーの方が桁違いかかるから
      • あんまり差は感じられない。サーバがアメリカにあるから。
      • なので、日本に作って欲しい
    • WebStorageの方が圧倒的に早い
  • 在庫管理とはのトランザクションは？
    • アナログと組み合わさった業務なので大丈夫
      • 現物を見ながら、やりますよ。
  • Cloud+UX技術(?)と言う本で今書いている内容です

Google API Expertが解説する Google App Engine for Java実践ガイド

Google API Expertが解説する Google App Engine for Java実践ガイド

ng-mtg#2 AngularJS 勉強会 #angularjsja に行って来ました

event angularjs

今回は入門編なので、経験者の人は知っている事が多いかもしれないです、難しい質問とかは懇親会の席でお願いしますとのことでした。
そのなわけで、メモったことなどを。

AngularJS 入門

使い方とか、こんなのあるよ的なところ。

  • AngularJSについて
    • Google製のMVCフレームワークです
    • コンセプトは、
    • 得意なところ
      • CRUD系のアプリ
      • 管理画面、マイページ
      • 1ページで完結するアプリ（Webアプリのフレームワークであればどれも得意）
    • 苦手なところ
      • モバイル向け
      • 重いから
      • ハイブリッドであれば問題ないかもしれない
    • ゲームなどで使うグラフィック系、エフェクト系
      • 例外：Bombermine（1000人で同時プレイ出来るアプリ）
      • Game Of Bombs
      • ゲーム本体ではなくて、ゲームの枠組みで使っているぽい
  • 動かしてみる
    • AngularJS — Superheroic JavaScript MVW Framework
    • 公式サイトの一番はじめに出ているデモコード
    • 双方向データバインディングができている
    • ng-app : AngularJSを使いますと言う宣言
    • ng-model : Model名を定義
    • {{}} でモデルにアクセスして表示する
    • 入力フィールドに入力すると、リアルタイムに表示される
      • ここまで実現するためにJavaScriptは一切書いていない
    • ng-appで囲ったHTMLタグの範囲内だけが適用範囲
    • jQueryで実現した場合
      • $('#input').on('keyup', function() {$('#text').text($(this).val())})
      • のような記述を書かなくてはならない
    • 同じ名前のモデルを作れば、すべて同期してくれる
    • ng-xxx を記述すると、HTMLのバリデーションチェックで引っかかる
      • 気になる人は、data-をつければOK
      • ng:xxx とか、x-ng-xxxでもOK
    • ng-bindと{{}}は同じだから、{{}}を使った方が良さそう
    • {{}}の中には、5*modelnameみたいに式を書いたりすることも出来る
    • 初期値を与える場合は、ng-initを使う
      • ng-init="hoge"ではダメで、ng-init="modelname='hoge'"とする
    • コントローラは、ng-controller="controllername"で定義する
      • TestCtrl
      • 初期値を与えたい場合には、$scope.modelname = 'hoge';とする
    • ng-repeatは繰り返し処理をするためのもの
      • ng-repeat="data in list"とすると、listの中身をdata変数で扱うことが出来るようになる
  • イベントとフィルタ
    • Event
      • ng-eventnameで定義
      • 普通にイベント名にngをつければ良いだけです。
      • ng-click="alert()"とかする。
      • alert関数はControllerの中で定義する。
      • $scope.alert = function() {/* 処理 */}
    • Filter
      • Angularのいいところ
      • 予め用意されているものだけでなく、自分で作ることも可能
      • 使い方は、{{}}の中で、パイプでつなぐ
      • numberやcurrencyのFilterを利用すればカンマ区切りで表示することが出来る
      • orderByでソートが可能
  • FormValidation
    • HTMLフォームタグは勝手に監視下に置かれる
    • フォームと、フォームの中のインプット要素等毎に、Validなのか、Invalidなのかを取得可能
    • CSSを組み合わせることで、入力エラーの表示が簡単に実装出来る
    • valid, invalidとng-showを組み合わせることで、エラーメッセージを表示したりすることも出来る
      • ng-show="myForm.myInput.$invalid"でエラーメッセージの表示制御を行う
    • ValidationがOKの場合はng-valid、エラーの場合は、ng-required等のCSSクラスをつけてくれる
      • CSSファイルにスタイルを定義しておけば簡単に表示を切り替え可能
    • ng-patternは正規表現がかけるので、結構複雑なチェックも可能
  • Directive
    • 独自のタグを作ることが出来る。
    • 独自の属性も作ることができる。
      • Eであれば、要素
      • Aであれば、属性
      • Cであれば、クラス
      • Mであれば、コメント
  • プラグインとか

AngularJSで開発したい

  • どういうふうに開発すればいいの
    • ソースコード
    • StableとUnstableがある
    • Stable よくテストされており、このバージョンのAPIは任意のさらなる変化を起こさない
      • 2〜3ヶ月ごとにあっぷされてる？
      • Unstable 開発中で、APIは予告なく変更することがある
    • Extras
      • 公式のモジュールがあります
    • モジュールの使い方
      • ただたんにscriptタグで読みこめば良いだけ
      • angular.module('CookieTest', []);
      • $cookieでControllerの引数の名前で使えるようになる
      • AngularのControllerの引数は、名前が合っていれば良くて、順番はどうでもいいです
  • API リファレンス
  • Batarang
    • Chromeのエクステンションがある
    • スコープ内のプロパティが見える
    • パフォーマンスが確認出来る
    • 依存関係がグラフで見れる
    • これがあるとないとでは、生産性に違いが出る
  • Testacular
    • Node.jsを利用したテスト用のもの
    • 各種ブラウザでテストが出来る
    • Jasmineなどのテストライブラリが使用できる
    • Testacularではなく、Karmaという名前に変わります
    • karma initで設定ファイルを作っていく
    • karma startで開始

AngularJS

AngularJS

第4回 PhoneGap UserGroup勉強会 #PhoneGapUG に行って来ました

event phonegap

山手線が止まってたので、ちょっと遅れ気味に到着。以下メモってたことなどを。

PhoneGapBuildの話

  • ライセンスについて
  • 無料版
    • Privateなアプリ1つと、オープンソースのプロジェクトがいくつでも作れる
    • 基本的にはフル機能が使える。
  • プロジェクトを作る
    • デバッグオプションなどを選べる
    • RedyToGoボタンを押せば良い
    • それぞれのプラットフォームごとの状態が見れる
    • 日本ではあんまり見られないプラットフォームのものもあります
    • それぞれのプラットフォームの実行ファイルを意識する必要はない
    • HTMLファイルとかをアップロードするだけでOK
    • そのままだとiOSでは、エラーになるけど、プロビジョニングファイルなどを設定すればOK
    • QRコードからアプリをダウンロードしてインストールする
  • UpdateCodeから、新しいバージョンのアプリを作成
    • Testerや開発者をプロジェクトに追加する事が出来ます
    • 設定画面では、デバッグとハイドレーションの設定が出来ます
    • PhoneGapBuildはバージョン管理機能等はないので、削除ボタンを押すとアプリが削除される
    • Githubとかであれば連携できるので、使いやすい
  • OpenSourceだと、GitHubのリポジトリから連携することが可能
  • 毎回Zip作るのはめんどうなので、EdgeCode（Bracelets）を使うと、便利
    • EdgeCodeであれば、PhoneGapBuildと連携出来るので便利
    • 連携のエクステンションを入れると、連携アイコンが出来る
    • 連携アイコンを押して、IDパスを入力すると、連携状態を見ることが出来る
    • Create New PhonegapProjから、設定ファイルなどを作る
  • デバッグとハイドレーション
    • デバッグ
    • ハイドレーション
      • Zipファイルではなくて、ソースコードを変更して保存して、Send PhoneGap Buildを選択すると、再ビルドが行われる
      • ハイドレーションでは、もう一度インストールしなくても、上書きすることが出来る
      • アプリを再起動すると最新版のコードに書き換わっている
      • 新しいバージョンが作られていたら、更新情報を取得するようなコードが自動的に追加される
      • アプリ側でアップデートを押すと、最新版を取得するようになる
      • アプリの削除＆インストールは必要なくなる
      • 製品版では、OFFにするが、開発中はONにしておくと良い
  • お値段
    • CreativeCloudの一部として使えます
    • CreativeCloudはAdobe製品全般が月々5000円くらい
    • PhoneGap Buildだけであれば月々1000円
    • 無料で使える1つのプライベートアプリを使い回せば無料で使うことが出来る

PhoneGap 最新情報

  • 2.3 と 2.5の情報
  • 2.3
    • WindowsPhone8対応
    • ダウンロードすると、Windows8とWindowsPhone8が入っている
    • 使い方は、PhoneGapのサイトのGettingStartを見るとわかる
    • InAppBrowser、アプリの中でブラウザを開くもので結構便利
      • window.open()のイベントが取れるようにもなっていて、ハンドリングが出来るようになりました
    • iOS5.X以降をサポート
      • iOS4.Xはサポートしない
      • iOS4.Xをサポートするアプリの場合は、2.2を使う
    • cordva.plistをconfig.xmlを設定出来る
    • ホワイトリストはPhoneGapの設定はアプリのメインWebViewのみ適応
    • デバイスAPIの仕様変更、でプラットフォーム毎の条件分岐方法が変わる
    • LocalNortificationイベントをプラグインが受け取ることが出来るようになった
  • 2.4
  • 2.5
    • プラグインの新機能
    • config.xmlのルートがwidgetから、cordvaに変更
    • NSURLCacheをつかうようになったので、キャッシュを参照するようになって、パフォーマンスが向上
      • 特に、実装上の注意点はありません
    • NativeURLが使えるようになった
      • assets-library:// でカメラロール等にアクセス可能
    • PhoneGap Wiki はじめに読んでおくように
    • Getting Startガイドは読んでおくように
    • プロジェクトを作成するときは、コマンドラインを叩くことになっています
    • Wikiには、デバッグの仕方や、アイコンサイズ、スプラッシュスクリーンなどが書いてあるので、読んでから開発に望むのが良いでしょう
  • Workflow
    • EdgeCodeで編集すると色々捗る
      • ライブプレビューを選択すると、Chromeが起動
      • ライブコーディングが出来る
      • EdgeCodeで変更して保存すると、画面がリロードされる
      • jQueryMobileを使ったりするのもすぐに反映されてテストしやすい
      • JavaScriptも、consoleが使えるし、リソース（LocalStorage等）の中身も見れる
  • PhoneGapエミュレータ
    • PhoneGap Emulation powered by Ripple
    • Chromeのエクステンション
    • HTMLファイルを開いて、右クリックして、エミュレータをenabledにする
    • デバイスのサイズとか、プラットフォームとかを選択する
    • イベントを発行したり、バックボタンを押したり、Geolocationを使ったり、ネットワーキングなどが可能
    • ビルドしなくても、エミュレータで色々と出来るので非常に便利です
      • 残念ながら、EdgeCodeと同期しないので、不便です
  • jQueryMobileが1.3になった
    • codiqaを使えば本当に簡単にモックアップが作れる
    • テーマはテーマローラーを使えば簡単に作れる

HTML5でゲーム

  • HTML5でゲームを作る上での問題点
    • 音楽、複数の音を同時に流すのが難しい
    • Streamingだと、時間がかかってすぐに再生出来ない
    • 最新のブラウザでも、複数の音楽を同時に流せない
    • アセットとしての、画像をどうやって画面上で動かすかも問題になります
    • 仮に、リフレッシュすると、真っ白になってしまう問題もあります
    • リモートで通信する場合には、ユーザにはフィードバックしなければならない
    • オーバーレイも可能であるが、パフォーマンス的に厳しくなってしまう
    • データの解析も結構JavaScriptだけでは限界が来てしまう
    • ネイティブでしかないAPIはJavaScriptでは出来ない
  • こう考えると、HTML5は良くなくて、ネイティブが良いんじゃないか？とか思う
  • Audio -> Media API
  • Asset Management -> FileAPI、Storege API
  • スプラッシュスクリーン
  • ゲームセンター（iOS）
    • 結構いいところまでいくけれども、まだまだ足りない。
  • PhoneGap プラグイン
  • いくつかのプラグインについて
    • AssetManager
      • シンプルなアセットマネージメント（簡単に使えるように設計されている）
      • サーバにあるファイルを同期するときに良いようにある
      • サーバ側にもアセットのマップがあって、クライアント側にもアセットのマップがある場合、自動的に更新されるようになっている
      • ファイルの場所がわかるので、絶対パスではなく、相対パスで扱うことが出来る
      • Wizcorp · GitHub
    • ViewManager
      • canvasなどのコントロールが出来る。
      • view同士でメッセージングをすことが出来る。
      • createで名前をつけて、名前で参照することが出来るようになる。
      • 内部では、別のSoftwareを使っていて、CanvasのAPIと同じだが、ネイティブの機能を使っている
      • loadで、createで作った名前で参照することが出来る
  • いずれ、プラグインを書くことになるかと思います
    • だいたいの機能はPhoneGapが出している
    • 簡単にプラグインは作れるので、あんまり心配しないでください
    • 基本的にPhoneGapはオープンソースなので、誰かが作っている可能性があるので、まずは探してみることをおすすめします