GREE TechTalk 『スマートフォン時代のソフトウェアテスト』に行ってきた

資料は公開されれば貼ります。

モバイルテスティング・クロニクル 松木 晋祐(株式会社ACCESS)

内容としては以下の3つ

  • 「モバイル」コンテキストの成立まで

昔どんな物があって今が存在するかだがimodeの話か始まりという感じの歴史。

  • 「モバイル」コンテキストにおける品質要素とテストのアプローチ。スマホがでてきてどんな事になったか。

AndroidiOSの違いは?共通の課題はどんなものか?といったお話。 セキュリティとプライバシー保護の問題があるが、プライバシー保護はセキュリティが守られた上で語らなければならない。

  • これからの話

クラウドのアプリケーションが増えてモバイルやインターナルなアプリはクラウドにシフトしている。 必要な技術として テストエンジニアリング基盤、出荷判定からKPI、フロントエンド技術 TATを高めるテスト自動化などがあげられる。

ちっともスマートじゃないスマートフォンアプリのテスト事情 山本 健 (グリー株式会社)
  • スマホは開発地獄だ。

永遠につづくかのような新しいバージョンへの対応。
元締め(Apple)による突然のレギュレーション変更。
ユーザから不具合報告がある端末は高い確率で社内にない。

  • スマホの罠ポイント。 いろんな形が存在する、機種、ブラウザ、ネイティブ。
    テスト環境とか。
    ちなみにGREEのエレベータは電波がきれるのでテストに使える。

  • 罠を総括すると結局はアンドロイド軍団vsテスタ。

そしてたまるバッドノウハウの数々、バージョン、デバイスのバリエーション。
もっとスマートにするには。
ナレッジを蓄積して罠をさける。
端末の選定をする。

グリーではマトリクスを作成しピックアップ、新発売は最低一代担保。
ガイドラインやナレッジの調査 を行っている。
QAサイドからの自動化。
TestEnginneringTeam 自動化による品質向上、費用削減を目的としたチームを作っている。テストエンジニアに近づいていく。
経緯としてはQAエンジニア確保の要請が来始めたところから。
今はドリランドのテスト自動化をしている。
理由は人気があり更新が多いプロダクトだから。
リグレッションテストの機会が多い。
Selenium pyhotn bindings 等を使っている。
現在、チュートリアル、主要機能をカバー。

  • スマートなまとめ 不安定な要素をできるだけ整理しハイスピードの反復に耐える健全な企画・開発・研修フローを確率する。
    自動化の導入は必須。
    モダンな開発スタイルが前提とされる感。

開発はTDD, CI Continuous Deliveryを行い。
QAはTest Enginieringを行う。

UnityによるGameObjectとコルーチンを利用したTestingフレームワーク 奥村 典史 (グリー株式会社)

C#でテストをしようという話。
sharpunitとかあるテストしたいことがある。
例えばロジック間違ってないか、
通信が想定した結果がえられているかパラメータバグはない、
実機でも動か、
メモリリークしてないか。

shapunit不便な点。
1フレームで簡潔しない処理が書けない。
テストツリーをコードベースで編集する必要がある。
ログがどのテストのログがわからない、どこで落ちたかわからない。

unityの特徴。
コルーチンで1フレームで完結しない処理が書ける。
hieraruchy オブジェクトのツリーをビジュアル化できる。
unityの特徴を生かしたらいいテストフレームワークができるんじゃないか。

というわけでuniunitst を作った。
テストがfailした時にUnityのconsoleにでてクリックするとfailしたところに飛ぶのは便利。
非同期の時はタイムアウトの値を設定したりできる。
sharpunityだと非同期ではできないので。

Q.sharpunitと併用?置き換えることができますか。
A.できる。

パネルディスカッション: Jenkinsによるテスト自動化の会社への導入 。 パネラー:太田 健一郎 (株式会社SHIFT) 、岡崎 隆之 (グリー株式会社)モデレータ:粉川 貴至 (株式会社セガ)

各事例に対してききたいこと各自の現場で困っている事内部品質が売り上げが比例するかというとそうでもない。
ただ、内部品質が低いとだんだんとコストがかかってくるのでそこは守ろう。
自動テストがない既存コードとかはあきらめよう。
新規コードはステートレスにしてユーティリティクラス静的検証ツールの導入しよう。自動テスト以外自動ビルドを頑張る事により時間と余裕を作ろう。

Q.自動デプロイCI導入時に手元で先にストを走らせるか?サーバでやるか?
A.できれば両方やりましょう。導入するときは最低限からでいいんで。

Q.上司に言われた言葉、テストの品質を誰が担保するんだ。
A.新規で作ったところを自動テストを行う。warningが減りますよね。
自動テストとメトリクスを合わせて。 テストを上手に書くようにスキルをあげていかないといけない。
どういうテストがいいのかディスカッションする。
まずはテスト技法とか考えるよりも境界値分析くらいはやっておくべき。
最低限の部分を実際にやると本番での障害を防げる。

Q.自動テストをやって仕様変更があった場合はコードを直さないといけないがどうする?
A.テストを先に直すのが理想だが、緊急だったらたそのタイミングで直す。

まとめ、できるところからやってこう!工夫を積み重ねよう!

というのまでが内容でした。個人的な感想としてはUnityのテストは徐々にだが自分のプロジェクトでも導入していきたいなと思いました。後、テスト技法とかばかり注目してきましたけどマインドも重要だなと思いました。

MongoLab にローカルのMongoDB のデータを import する方法

Heroku でアプリを作っているのだがローカルでテストを行い Heroku のAddon で使用している MongoLab に方にデータを移したくなったので。 至って簡単でまずは mongo コマンドで collection を export する。

mongoexport --db <db名> --collection <collection名> --out <ファイル名>

例えば baske という db のなかの categories というcollection を export したい場合は

mongoexport --db baske --collection categories --out categories.json

みたいにする。

そんんでもって https://www.mongolab.com/ のページにいって tool → import のあたりを読めばわかるのだが、

mongoimport -h ds<アプリ番号>.mongolab.com:<アプリ番号> -d <dburl> -c <db name> -u <user> -p <password> --file <input file>

上記のようなコマンドでいける。 これでローカルでOKだったかテストしてから本番にデプロイできますね。

Deemo 素晴らしいピアノ演奏アプリ


【Deemo】 Gameplay Video - YouTube

最近有料アプリランキングでも上位の Deemo をやっているのだが完成度が凄く高いと感心している。世界観やそれを支える UI 、曲、どれもこれ以上の改善点が見つからないくらいよくできているなと感じた。クリエイターのこどわりが感じるアプリというのはやっていて気持ちいいものである。

ちょっと調べたところこのアプリを作ってる会社、台湾の会社で従業員数が22名らしい( http://appsjp.com/?p=50776 ) しかもこの写真を見たところ Deemo のチームは6名くらいしかいない。少ない!と思うと同時にこれくらいの人数じゃないと逆にこれだけ完成度の高いアプリは作れないのかもしれないなと感じた。

ただ、残念なのがこれだけ素晴らしいアプリなのにトップセールスでは100位にもなかなか入ってこないということ。トップセールスはソーシャルゲーム系がほとんどである。それらのアプリのいくつかより僕はこのアプリの方が完成度が高く感じるし毎日触りたくなるのだが。トップセールスで100位近辺ということは売り上げどれくらいなんですかね。月1000万はいかないと思いますが。200円ちょっとでこんなアプリが楽しめるっていうのは消費者側からしたらいいことですが複雑な感じです。

Heroku の Node.js アプリで Redis を使用する方法

https://devcenter.heroku.com/articles/getting-started-with-nodejs#using-redis の言う通りにやる。それだけ。

Redis To Go を使うのだからhttps://devcenter.heroku.com/articles/redistogo#using-with-node を見た方がいいんじゃないかと最初は思ったのだが、こちらの方法ではなぜかできなかった。しかもこちらの方が書くコードが長いし。

とりあえず短くて確実な前者の方でやるのがよいかと。

ビッグデータで NBA は面白くなるのか

NBA が巻き起こすビッグデータ革命 http://www.newsweekjapan.jp/stories/business/2013/11/nba_1.php

NBA の試合をモーションキャプチャしてデータを集めるというもの. 技術者としては是非そのデータを活用してNBAゲームの発展, 選手のパーソナルデータの分析, あるいはもっと別の新しいコンテンツへの活用などで夢は膨らむのですがプレイヤーとかファンして考えた時にどうだろう.

レブロンの弱点は左80度からのシュートだ, コービーはドリブルを2回ついた後に必ずジャンプシュートする. みたいなのを知ったところで果たして相手プレイヤーは対応できるのか. また対応したとしてそれが NBA のエンターテインメントとしての面白さになるのか, 試合のランダム性みたいなのが段々と排除されてつまんなくなったりしないか. そこが心配.

ただ, データ蓄積されることによってドリブルスピードNo.1 とかジャンプ力 No.1 とか簡単に決められてそこらへんが素直に面白いと思う. 後, できれば NBA だけじゃなくオリンピックとかでもやって日本のプロとの違いをデータで見てみたい. 絶望味わうかもやけど.

Node.js (Express) でuncaughtException が起きた時にエラーページを表示する

Node.js で予期せぬエラー uncaughtException が起きた時にサーバを止めないためには

process.on('uncaughtException', function(err) {
    console.log(err);
});

としてエラーをキャッチしてサーバを止めないようにするというのは一般的に知られた方法であるがエラーページを表示したいとかになった時にどうすればいいかわからなかったので調べてみた。 どうやら domain を使えばできるよう。以下は Express フレームワークを用いて書いたサンプル

var express = require('express')
  , routes = require('./routes')
  , domain = require('domain');

var app = express();

app.configure(function(){
  app.set('port', process.env.PORT || 3000);
  app.set('views', __dirname + '/views');
  app.set('view engine', 'jade');
  app.use(express.favicon());
  app.use(express.logger('dev'));
  app.use(express.bodyParser());
  app.use(express.methodOverride());  
  app.use(function(req, res, next) {
      var reqd = domain.create();
      reqd.on('error', function(err) {
          res.render('error/index', {title:'error'});
      });
      reqd.run(next);
  });
  app.use(app.router);
  app.use(express.static(path.join(__dirname, 'public')));
 });

app.configure('development', function(){
  app.use(express.errorHandler());
});

app.get('/', routes.index);

http.createServer(app).listen(app.get('port'), function(){
  console.log("Express server listening on port " + app.get('port'));
});

domain reqd を生成して request ハンドラで next が受け取れるので reqd.run(next) とすることで next 以降の処理でエラーを受け取るようにしてエラーが起きた場合は res にエラーページを返してやるというもの。便利ですね。

YouTube ifame API の使い方

自分のサイトで YouTube のプレイヤーを表示しようとしたのだが、FlashAPI だと play とか stop とかのタイミングがタグが表示中じゃないと効かなかったりするので iframe API が便利という話。 iPhone でも表示できるしね!

MyApp = {};
function onYouTubeIframeAPIReady() {
    MyApp.YtPlayer = new YT.Player('videoDiv', {
        height: '390',
        width: '640',
        videoId: 'M7lc1UVf-VE'
    });
}

(function() {
    var tag = document.createElement('script');
    tag.src = "https://www.youtube.com/iframe_api";
    var firstScriptTag = document.getElementsByTagName('script')[0];
    firstScriptTag.parentNode.insertBefore(tag, firstScriptTag);
})();

これで id=videoDiv の要素に iframe が埋め込まれて再生されたりする。

MyApp.YtPlayer.play(); 

とか

 MyApp.YtPlayer.stop();

とかやることによって再生と停止が切り替えられたりします!