Posts Tagged ‘test’

shibuya_sp 勉強会 vol1 アウトラインメモ

#shibuya_sp 勉強会 vol1 : ATNDに参加してきたので、その時のメモです。

iOSアプリケーションのUnit Test – 岸川

テストを習慣化するには

なぜテストを書かないか

  • テストの効果がわかりにくい
  • iPhoneアプリのテストってどう書けばいいのかワカラナイ
  • デバイス固有のデータを利用していたりする

ツール/フレームワークを使う

  • 繰り返し実行するのが簡単
  • 自動化できる
  • テスト結果が見えてくるようになる

無理をしない

  • モデルのテストは書きやすい
  • 論理構造はそう簡単に変わらないはず
  • 繰り返し実行するメリットがあるので(正常系/例外/異常/境界値)をちゃんとテストする

表示は論理構造が簡単にひっくり返る事があるので、テストを無理に書こうとしない

テストしやすいコードを書く努力はする

  • テストしやすいコードは、使い易いコードなので良い設計にも繋がる
  • メソッドをきちんと分けてあげる

単体テストをワークフローに取り入れる

  • OCUnit
  • GHUnit
OCUnit
  • XCode標準
  • XCodeと統合されてるが、アサーションが貧弱
  • 非同期テストがサポートされてない

GHUnit

  • XCode非標準
  • アサーションが豊富
  • まともなテストができる(teardown/setup)
  • 非同期テストのサポート(waitを使える)
  • OCUnitのテストケースも実行可能
  • viewのテスト機能が追加された

Viewのテスト

GHVerifyView あらかじめ取っておいた画面の画像と照らしあわせてテストしてくれる 画像での比較

Flashからcocos2dに移植した話 – CAつりポンチーム

  • Flashとcocos2dに移植した

  • 1万7千件のレビュー

  • 平均4.5☆

  • Twitterによる拡散

  • 完全無料広告なし
  • アメーバピグ
  • ストレスフリー
  • App Storeのレビュー誘導

オフライン対応

非会員対応

  • ほぼすべての機能を非会員でも遊べる
  • 会員と非会員の差別化
  • タイトル画面の対応のみ
  • ポイントの管理をローカルにおいて、サーバ側からポイント管理を排除

iPod Touchのユーザーが30% => オフライン対応の成果?

cocos2dとFlash

大量の画像を書きだす

  • 手動は日が暮れるので
  • アクションを作って、画像ファイル名=レイヤー名にしてバッチで生成

texturepacker を知る

  • 一枚の画像に素材を貼り付けて、座標データからファイルを切り出して表示する
  • CSS スプライトみたいな

AutoSD

自動でRetinaと通常の解像度を作成できる

Spriteはフォルダ管理

Finder上でフォルダ構造そのままにSPriteを管理できて楽 texturepacker上に反映する

見ていて飽きないガチャを作れという司令

まずはFlashで動きを作る

  1. 色を選ぶ
  2. ガチャを出すアニメーション

自作AIRツールで座標の抽出

swfから座標の抽出をするソフトを作成した

  • 座標系の違いを補正する スクリーン座標 -> デカルト座標
  • Flash上のレイアウトがそのままcocos2dに移植

cocos2dを利王した最適化と高速化

  • 描画処理の高速化
  • テクスチャロードの非同期化

iPhoneのOpenGLの傾向と対策

  • OpenGLの描画を呼び出すほどオーバーヘッドが大きなリ重くなる傾向
  • なので、texturepackerを使ってテクスチャを一回でロードしたりして 呼び出し回数を減らした。

テクスチャロードの非同期化

  • 非同期で先にテクスチャを読み込んで、読み込み待ちを減少させる
  • addImageAsyncを使って非同期ロード

テクスチャフォーマットの調整

  • RGBA4444に統一してる(32bit -> 16bit)

モーション制御の最適化

CCPawnやCCSequenceを処理コストが多いでの、人体とかが苦手だった。 モーションデータを削減して、モーション制御をNEONで並列処理にして最適化

コンフィグの微調整

ccConfig.hでCCUSESVBOを無効にするだけで結構変わる

Time Profiler

順次上から見て最適化をしていく

まとめ

  • テクスチャは一枚にまとめてCCSpriteBatchNodeで描画
  • NEONなどSIMDを使って最適化
  • ccConfig.hをみてチューニング

OCTOBAから見た面白いAndroidアプリ – 丸岡

Android Market

アプリ削除率

  • 37%?

OCTOBA

  • 男性が多い
  • 30-40代が多い

パーミッションの問題

Any.Do

  • 機密ログデータの読取
  • このパーミッションを要求するアプリはレビューしない

いろいろなパーミッション

  • 機密ログデータの読取
  • 連絡先データの読取
  • SMSメッセージの送信
  • アカウントの認証情報を利用
  • 起動中のアプリケーション情報
  • 端末ステータスとIDの取得

広告SDKでGPSデータを利用してターゲティングを使用したりするものもある。 組み込んだアプリでGPSを使ってなくても、パーミッションが求められる

レビューの基準

人気ジャンル

セキュリティが5月(2011)あたりが入ってる

  • ツール・設定系
  • ゲームエンタメ系

昔はツール系が多かったが、ゲームエンタメ系が増えてきている

検索キーワード

  1. 電話帳
  2. 時計
  3. メール

使ってもらえるアプリの考え方 – fladdict

ATMアプリを考えてみる

架空の事例で考える

リサーチ

  • 既存のATMの機能?
  • 既存のATMの不便?
  • どういう時に使う
既存のATMの機能
  • 残高確認
  • 入金、引き出し
  • 送金
  • 設定変更

オンラインバンキングを含めるともっとたくさんあるので、 どの機能をアプリに含めるのかを考える -> 絞り込む、利用の想定

シナリオ

  • 通販などの振込
  • 通常の送金
  • 支払い忘れへの緊急対応
  • 残高確認

逆にスマートフォンで保険や税金管理などの操作はしないとのでいらないはず

90%のユーザーが必要な機能を入れる

  • ヘルプなしでわかるアプリを作る
  • アプリを起動してからそのアプリのタスクを1-2駅程度の間に完了できるようにする

必要な機能を絞り込んでから、コンセプトを立てる

コンセプトの定義

iPhoneアプリは大体4つの形がある

  • ユーティリティ型
  • ナビゲーション型(TableView)
  • タブ型
  • 没入型(全画面)

それぞれのタイプをプロトタイピングして検証していく。

ユーティリティ型

  • 最低限だけの機能
  • 残高の確認
  • 送金ができる

ナビゲーション型

ユーティリティより機能は増える

  • ニュース
  • 残高
  • 送金
  • 設定

タブ型

ナビゲーション型と似た機能を持つが、平行して機能を使える

没入型

iPhoneのUIに頼らないので時間がかかる

  • 実際の画面に似せるなど
  • ナビゲーションを出してみたり
  • 現実のメタファ

今回はナビゲーション型かタブ型

ナビゲーション型

  • 拡張しやすい
  • 単純

タブ型

  • 拡張に限界がある
  • 平行して機能を利用できるのが利点

ナビゲーション型は階層が深いと、作業を切り替えるにコストがかかるので、タブ型の方がやりやすい

タブ型のメニュー

よく使うものから左から右へ配置していく

ニュースを残高確認後に見る人はあまりいない ニュースをATM側としては配信したいので、ニュースを左に持ってきて自動的に見せるようにした。

設定画面

  • ピンコード
  • アカウント名
  • 銀行アカウントのパスコード

入力UI

  • Pickerを使って桁ミスなくすなど
  • 送金時はボタンのミスタッチをなくす
  • スライドで送金処理を完了させる <= 難しいUIな気がする…
  • 最初にボタンを詰め込みすぎない

Edit Qute for PC/Mac

東京Node学園 1時限目のアウトラインメモ

東京Node学園 1時限目

~サーバサイドJavaScriptの幕開け~

http://atnd.org/events/13529

Togetter - #tng1のまとめ

http://togetter.com/li/115851

 

タイムテーブル

時間

題目

発表者

Ust

19:00-19:25

開場

 

 

19:25-19:30

ご挨拶 / 5分でわかるNode.js

@meso

#1 04:42AM

19:30-20:00

ECMAScript5時代のJavaScript再入門

@masuidrive

20:10-20:40

『非同期プログラミングの改善』のエッセンス

@koichik

21:50-21:20

Nodeにおけるテスト手法

@Jxck_

#2 05:49AM

21:30-21:50

LT大会

 

 

 

Kinect + node.js + Audio Data API でテルミンみたいな楽器を作る

@hakobera

 

「node.jsによるマルチプレイヤーネットワークゲームの可能性」

@ndruger

-22:00

完全撤収

 

 

 

ご挨拶

http://tng1.mesolabs.com/

Node.jsについては著者のブログを読む

Node.jsの目的はスケーラブルなネットワークプログラムを作成する

既存のI/Oライブラリがないため、位置からブロックしないライブラリを作成することができる。

 

ECMAScript5時代のJavaScript再入門

増えた機能

JSONサポート

配列のイテレーター

Getter, setter

Strict mode

5thは誰のためのもの

独自仕様の整理してAjaxなどから大規模なものも増えてきた。

多人数の開発やコードのりユーズのための整理

非同期処理

JavaScriptは非同期処理を書きやすいけどネストが深くなる。

JSDeferredライブラリで縦に非同期処理がかけるのとエラー処理を最後にまとめて書くことができる。

Property Descriptor

Setter/Getter

ObjectFreeze/Sealでアクセスレベルの指定

Object.create(),cloneなど

Objectの拡張はライブラリでも似たようなことが可能だが、ESでの仕様としてあることで共通知識として利用できるため可読性などが向上する。

PhotoShare

サーバー側はRuby

HTTP経由でアプリテストすると時間がかかる。

 

ES5によって独自から共通へ

 

『非同期プログラミングの改善』のエッセンス

http://www.slideshare.net/koichik/node1

Node.jsの非同期スタイル

イベントリスナ・スタイル

onメソッドでイベント

コールバック・スタイル

APIの最後にコールバック関数を渡す

(プロミス)

今はない

Deferredみたいなメソッドチェーンもできた

 

コールバックスタイルの問題

無名関数を使うとネストが深くなってしまう

関数名をつけて使うとgotoもどき

try..catchがうまくいかない

改善するには

コールバックと無名関数を分離する

コールバックの役割は「次」の無名関数を読み出す

その無名関数は「アクター」と呼ばれる

アクターとコールバックを結びつける

フロー制御モジュールライブラリを使う

複数のアクターを受け取ってって、アクターにコールバック(next)を提供する。

フロー制御を導入すると

ネストが深くならない

可読性が向上する

エラー時のルーティング

アクターごとのエラー処理をしたくない

エラーが起きたら途中のアクターを飛ばす

 

Nodeにおけるテスト手法

Nodeにおけるテストの考え方

Assertion

require(“assert”);

Testing フレームワーク

 

require(“should”);

obj.should.test(“”)

Objectを拡張して、列挙されないようにしてる

require(“expresso”);

赤いシャツの人が作った

jscoverageの出力

tearDownとかない

require(“nodeunit”)

Unit系のモジュール

qunitみたいな感じ

ブラウザでも動作する

exportの代わりにthisを使うことで、どちらでも動作するコードがかける

sandbox機能

CI的な機能もあるよ

クライアントとサーバサイドどちらも同じようにかけるのは大きな利点になる

require(“Vows”);

非同期に適してる作り

 

require(“tobi”)

ブラウザ的なものをシミュレートしてテスト(envjsみたいな)

 

 

LT大会

Kinect + node.js + Audio Data API でテルミンみたいな楽器を作る @hakobera

http://d.hatena.ne.jp/scalar/20110324/1300983209

kinnect hackatonではXBOX360所有者がで2/20

kinect+node.js+Socket.IO

Kinect -TCP/IP - NodeJS – Socket API – ブラウザ

 

Kinect.jsの作成

C++実装 -> Javaラッパー -> Rhino -> JavaScript

JavaScriptkinectで動くものが帰る

DSJ(デバイスサイドJavaScript)

現在の欠点

遅い

使ってるラッパーの制限

node.jsではない

 

node.jsによるマルチプレイヤーネットワークゲームの可能性 @ndruger

http://www.slideshare.net/ndruger/nodejs-7375453

リアルタイム→Node.jsなら簡単

サーバークライアントで693行程度で簡単にかける

敷居が高かったものが手軽に作成できる時代

 

 

他の参加者のまとめ

東京Node学園 1時限目 メモ – すぎゃーんメモ

2011-03-25 – のりーごのアミーゴ日記

東京Node学園 1時限目にいってきた – Web::Service::Blog->new( user => ’hide_o_55’ )

東京Node学園1限目行ってきましたメモ – y-kawazの日記

詳細に書かれているので参考になる

 

感想

会場(リクルートアネックス1ビル B1F)も伴ってか何かゆったり広々な感じであんまりガツガツとした雰囲気がなかった。角度、距離(文字サイズなども)的にスライドを見るのがつらい部分もあった。

『非同期プログラミングの改善』のエッセンスLTが面白かった。


タイムテーブル

時間


題目


発表者


Ust

19:00-19:25


開場







19:25-19:30


ご挨拶 / 5分でわかるNode.js


@meso


#1 04:42AM

19:30-20:00


ECMAScript5時代のJavaScript再入門


@masuidrive




20:10-20:40


『非同期プログラミングの改善』のエッセンス


@koichik




21:50-21:20


Nodeにおけるテスト手法


@Jxck_


#2 05:49AM

21:30-21:50


LT大会










Kinect + node.js + Audio Data API でテルミンみたいな楽器を作る


@hakobera







「node.jsによるマルチプレイヤーネットワークゲームの可能性」


@ndruger




-22:00


完全撤収





JavaScriptコードのパフォーマンス比較ができるWebサービス「jsPerf」の使い方

自分が書いたJavaScriptのコードスニペットに対してどのコードが早いのかベンチマークを比較することができるWebサービスであるjsPerfの紹介と使い方。JavaScriptでは同じ機能を実現するための方法は様々であり、どのコードが優れているのかを調べる方法としてプロファイラなどを利用することがあります。しかし、JavaScriptはブラウザ毎によっても速度が変わることが多いため、ブラウザ依存のツールだと比較しにくくなるため、ブラウザ上でテストコードを実行し、それらのベンチマークを簡単に記録、比較できるサービスがjsPerfです。

jsPerfの比較方法

jsPerfの内部ではBenchmark JSというベンチマークライブラリが使用されています。(jsPerfの運営者が作成している)
jsPerfの計測方法は一定時間内にどれくらいコードスニペット部が実行できたのかで比較します。そのため数値が大きいほどパフォーマンスがよい(=一定時間で多く実行できる)となります。
ブラウザ固有のテストやライブラリを読み込んでのテストも行うことができます。

使用方法

http://jsperf.comにアクセスします。
過去に他のユーザーが比較した結果は
Browse test cases · jsPerfから見ることができます。
Googleのsite:検索を使って事前に行おうとしている比較があるかを検索するといいかもしれません。
(join vs concat site:jsperf.com – Google 検索みたいな感じで)

ユーザー情報の入力(Your details)

ユーザー情報の入力部

これは任意ですが、名前やメールアドレス(Gravatarを利用したアイコン表示のため)やサイトURLを入力することができます。
ユーザー名が入力してあった場合はhttp://jsperf.com/browse/<USERNAME>.atom というURLからRSSを見たり、過去に比較したものも一覧できるのでユーザー名は入れた方がいいです。
Publishedのチェックを外すことで非公開でテスト行うことができます

テストケースの情報(Test Case Details)

テストケースの情報

 

この部分はテストケースのタイトルや説明などを入力する場所です。
後で見た人が何のテストなのかわかるように書いておくといいです。slugはタイトルから自動で入力されますが任意で決めることもできます。

事前準備のコード(Preparation code)

事前準備

Preparation code HTMLには必要なライブラリを読み込むScriptタグやDOM操作が関係するテストならDOMを書いておけます。
Preparation code JavaScriptにはテストで使うJavaScriptコードで事前に書いておけるもの(共通して使うなど)を書いておけます。

テストケースの入力(Code snippets to compare)

テストケースはタイトルをコード部分を入力できます。デフォルトは2つ入力する場所がありますが、Add Snippet Codeから増やすこともできます。テストケースのコードを入力する際に気をつけるべきことは、テストコードにテストと関係ないループ文などを含めないことです。
jsPerf側でテストケースのブロック毎に繰り返し実行するため、テストコード内のループ文がテストの本質と関係ない場合は含めない方がいいです。

これで入力は終わりで後は実行して結果を見るだけです

実行して結果を見る

テストページにあるRun Testボタンからテストを実行することができます。
Tipsとしてテストページの最後に#runと付ければボタンを押さずに自動的にテストが実行されます。

  • UserAgent
    実行したブラウザのUA
  • 中央のエリア
    テストの名前とそれぞれの実行結果のスコアが載っています。
    数字が大きいほどパフォーマンスが良いことに注意してください。
    また実行環境が違うものも記録されるため、縦方向に比較をしないで横方向に比較をするといいと思います。
  • #Tests
    テストの実行回数

ここに表示される実行結果は自分以外の人が実行したものも記録されていきます。
また他人のテストケースをフォークして新たなテストケースを作成することも可能です。

以上で簡単な説明は終わりです。
より詳細な疑問点はFrequently asked questions · jsPerfを見るなどすると良いです。

この記事は以下をかなり参考にして作成しました。(テストもその記事内から借用しています)

Nundefined :: About jsperf.com
http://nundefined.tistory.com/25

GoogleのJavaScriptコーディングスタイルチェッカー「Closure Linter」

GoogleではJavaScriptは特定のコーディングスタイルで統一されるようにClosure Linterという専用のスクリプトを使用しているそうです。
Google JavaScript Style Guide(Google JavaScript Style Guide 和訳)という規則に従ってjsのコードは書かれていて、その規則に沿っているかを確認するgjslintとその規則に合うように修正するfixjsstyleからなるスクリプトです。

インストール方法

How to Use Closure Linter – Closure Linter – Google Code
pythonで書かれているのでeasy_installを使ってインストールします。
まずはPythonをインストールしてなかったらインストールして、次にeasy_installコマンドを使うためにsetuptoolsを自分のPythonにあったものをインストールします。
WindowsならC:\Python26\Scriptsに環境パスを通せば、コマンドプロンプトからeasy_installが使えるようになるので、

> easy_install http://closure-linter.googlecode.com/files/closure_linter-latest.tar.gz

と打ってたらインストールできます。(パス通してないならC:\Python26\Scriptseasy_install でも大丈夫)

*注意 (修正済み)
現在配布されるやつはfixjsstyleがTypeError: ‘NoneType’ object is unsubscriptableのようになって動かないので、

easy_install -Z http://closure-linter.googlecode.com/files/closure_linter-latest.tar.gz

という感じでファイルを展開するオプションをつけてインストールしてから、/python2.6/site-packages/closure_linter-2.2.1-py2.6.egg/
closure_linter/fixjsstyle.py の36行目にargfとなってるtypoがあるのでそれをargvにすれば動きます。

使い方

使い方は単純でHow to Use Closure Linter – Closure Linter – Google Codeを見ると分かりますが、

gjslint path/to/my/file.js
fixjsstyle path/to/file1.js path/to/file2.js

のようにファイルやディレクトリを指定して実行するだけです。
–strictオプションやディレクトリに対してまとめてやる再帰オプションもあります。またGoogleのコーディングスタイルではJsDocを使う事になってるので、それを無視するオプションもあります。

fixjsstyleはE4Xとか特殊なものは認識してないっぽいので無理に書けると構文エラーを出すようになったりしますが、
Googleのコーディングスタイルはそこまで特殊ではないので、ちょっとした確認に使えたりして便利です。
JavaScriptの整形にはOnline javascript beautifier(これ自体がJavaScriptで書かれているのでEmeditorやNILScriptで動かせるgist: 453042 – クリップボードのJavaScriptコードを整形してクリップボードに返すNILScript – GitHub)とかと併用すると面白いかも。

Introducing Closure Linter – Closure Tools Blog
http://closuretools.blogspot.com/2010/08/introducing-closure-linter.html
プロフィール: azu(アズ)
Firefoxの事やソフトウェアの紹介や使い道、Greasemonkeyの作成
  • OS:Windows Vista, 7
  • ブラウザ:Firefox
  • Twitterのアカウントはこちら
  • azu_re
  • メールアドレス(Twitterの方が確実)
  • info@ドメイン名
リンク

WebMoney ぷちカンパ