-S”というmetricsが追加されている。-S”を使うことになるはず。Labsというサービスがあって、WindowsやMac、iOSやAndroid等の各種OS上の各種ブラウザを仮想マシン上に立ち上げて、ブラウザ上でブラウザを操作することができるサービスです。WebDriver経由でユニットテストを実施することが本来の用途らしいので、コードをコミットしたら各種ブラウザでテストを実施してダメだったら教えてくれる環境というのを構築してみました。webdriverが登場した頃から、理屈の上ではできると言われていたテストですけど、あれこれの環境を個人で維持するのは現実的でないので、こういうのをサービスとして提供してくれるのは嬉しいですよね。Platformsからコピペすることが出来て、必要な設定に書き換えればMacのChromeでもWindowsXPのIE6でも、iOS7でもAndroidでも、任意のブラウザで同じテストを実施することが出来ます。いうことで、環境変数BROWSERでブラウザの種類を指定してunittestができる仕組みを作ってみました。SaucelabsTestCasePCを継承してテストを作れば、環境変数BROWSERで指定したブラウザでテストを実施することができるようになります。pc/search.rb:テスト結果はunittestとして成功失敗を判定する以外にも、Saucelabs上ではこのようにキャプチャ画像や動画として保存されているものを見ることも出来ます。ここまでできれば、あとはいつもどおりにunittestを書いてjenkinsさんにお願いしておけば、コードをコミットするだけで各種ブラウザの動作確認をしてくれるようになりますね。Labsは月額課金のサービスで、月一時間位までは無料で使うことが出来ます。1テスト30sくらいで実行できるので、全部のテストを一度通してみるくらいなら無料でも行けるけれど、本当にコミットするたびに全テスト走らせるのであれば、$12のManual会員か、$49のAutomated会員くらいは必要になるかもしれないですね。今これを書きながら気づいたのですけど、githubに公開してあるコードは無料でテストできるらしいです。7日目は、大さん橋を見ながら@mogyaがお送りします。山下公園でコード書くとかかっこよくない?と思ったんだけど、寒くてコードどころじゃない感じでした...さてさて、TitaniumにはMapViewというのがあって、これを使うと簡単に地図アプリが作れるのですが、GoogleMapsSDKのバージョンが上がった関係で、現在Androidでは標準のMapViewではなくてModules.Mapを使うように言われていて、ちょっと混乱期にあります。3.2.0で旧バージョンが削除されるらしいので、来年には落ち着くんじゃないかと思うのですけど。現行だと、こんなかんじで書かないといけません。map_view.jsさらにさらに、MapViewを使って、地図をドラッグした時に発生するregionChangedイベント(これも最近名前がregionchangedイベントに変わりましたw)を契機としてモバイラーズオアシスAPIを呼び出すようにすれば、電源が使えるお店を一覧するアプリを作ることが出来ます。実際作ってみるとわかるのですが、このつくりだと微妙に使い勝手の悪いアプリになります。離れた位置を見ようとして移動を繰り返すと、画面がちょっと動くたびにデータをロードしに行くので、処理がたまってだんだん重くなってしまうのです。ブラウザ上のGoogleMapsSDKで開発する場合には、処理が落ち着いた時に呼び出してくれるidleイベントというのが存在するので、これを使えば綺麗に実装することが出来ます。もぎゃろぐで、idleイベントが存在しないAndroidやiOSのSDKでどうするか、というのがこの記事のテーマです(前置き長すぎだろうw)idleイベントと近そうなイベントとして、completeイベントというのがあって、これを使うのも一つのアイデアです。このイベントは、地図のロードが完全に終わってから呼び出されるので、これで実装すると、「ユーザーがドラッグ→地図がロードされる→(一呼吸)→店舗が表示される」という、これまた使い勝手の微妙なアプリになります。今年リリースした電源検索新バージョンや、iPhone版の電源検索では、regionChangedイベントでそのままAPIを呼び出さずに、キューにイベント情報を積んでおいて、一定時間regionChangedイベントが発生しなくなったら、最後の一回分だけAPIを呼び出す、という実装を行いました。data_task.jsdata_task.js部分が問題のロジックをカプセル化したものです。regionChangeイベントが発生したらとりあえず全部requestでDataTaskにあずけてしまいます。mapview.addEventListener(regionchanged,function(evt){datatask.request(evt);});DataTaskは内部でタイマーを持っていて、一定時間が経つと、最後に呼び出したrequestの引数を使って、actionコールバックを呼び出します。actionコールバックの中でAPI呼び出しを行うようにすれば、おおむね、ユーザーが地図をドラッグしおわったタイミングでAPI呼び出しを行うことが出来ます。DataTask({interval:3000,action:taskAction,caller:this});datatask.start();書きながら「そこまで頑張る必要があったんだろうか。実はcompleteイベントでいいんだったりして」とちょっと不安になってきたのですけど・・・大丈夫なはずだ。神は細部に宿る!明日はryugooさん@ChatWorkです。TitaniumMobileコメントするlatlngの宗教問題geocoderの話が予想以上にうけてびっくりしたので、ジオコーディングのくだらない話を一つ。ジオコーディングに関するコードを書いているとたいていハマる問題が一つあって、それは緯度経度をどういう変数で表すか。Qiitaによると、だいたい世界には6つの派閥が存在するらしいです。latlngじゃなくてxとyで済ませちゃう人たち個人的には、上記の他に、[34.12345,135.98765]とArrayで表す派閥が存在すると思っています。例のRubyGeocoderは、もともと文字列を受け取ることになっていたのですが、最近Arrayも受け取るように修正が入ったようです。ついでなので、Ruby界から、{lat:34.12345,lng:135.98765}と表す新Ruby派と、{"lat"=>34.12345,"lng"=>135.98765}と表す旧Ruby派なんかも参戦していただくと、問題が混沌としてきて、より宗教戦争らしくなってきますね。戦争を煽るばかりでは申し訳ないので、みんな仲良くできるコードを用意してみました。緯度経度を表す多様なフォーマットを全部受け入れて任意のフォーマットで出力する試みhttps://gist.github.com/mogya/6978002これをつかえば、上記で上げたようなパターンをすべて扱うことが出来ます。:longitude=>135.98765}使わなくて済んだはずのCPU時間を横着のために使うのはどうかという気もするのですが、気にならない方は自由に利用してください。APIを使うとまあたいていのことはできる。ロケタッチAPIとか、Yahoo!ジオコーダAPIという手もある。それはともかく、そのへんをパチパチ叩くコードを書いていて、「こんなのもうとっくに誰かが書いてんじゃないかなー」と思ってぐぐってみたらなんかすごいのが出てきた。Geocoder住所と緯度経度の相互変換はもちろん、距離や範囲の扱い、Google以外のAPIへの対応、キャッシュ処理など、「実装しようかなー。めんどくさいよね」とか思って先送りしていたような機能がほとんど全部実装されている。みたいなこともできるらしい。みたいなこともできるようになるらしいです。早く探しておけばよかったなー。「フットインザドア」とかの交渉術じゃなくて、交渉がどういうものでどういう力学が働くのかといった解説をした本。無意識に実践しているような内容も多かったのですけど、体系的にまとまっているので思考を整理することができました。「窓を開けたい」人と「窓を閉めたい」人が交渉する場合、そのままだと要求を突きつけあうだけで妥結の余地がない。「なぜ窓を開けたい/閉めたいのか」情報交換して「風が吹き付けるから寒い」「空気を入れ替えたい」という利害を明らかにすることで、両者の利害を満たす結論を出すことができる(「ここじゃなくて、むこうの窓を開けましょう!」)『BATNA』(不調時代替案)。交渉が破談になったとき取れる対応のこと。中古ノートパソコンを友達から買う場合、最悪ヤフオクで買ってもいいのであれば、ヤフオクで買う場合の想定値段がBATNAになる。自分のBATNAを明かしてはならない。「ヤフオクで10万円だったからそれより安く」と言ってしまうと、たぶん9万8千円くらいで買うことになる。相手は5万円でもいいかな、と思っていたかもしれないのに!相手のBATNAを知っていれば有利に交渉ができる。友達が捨てるしかないと思っているのなら、一万円と申し出てもお得だと思ってくれるかもしれない。『ZOPA』(交渉可能領域)お互いのBATNAを並べて譲りうる余地のこと。最低1万円で売りたいA君と、ヤフオクで買えば10万円で買えるB君の間では、1万円から10万円までの間がZOPAになる。Aくんが20万円で売りたい場合は、ZOPAが消滅するので交渉の余地がなくなる「パレート最適」ZOPAの中で、お互いの利益が最大化する解の事(略)この本の前半分がこんな感じの、1対1の交渉理論について書かれている。後半は、より複雑な、複数の人が絡んだ場合の交渉学。ビジネス上の交渉で使うことは少なそうだけれど、世の中なんでこんなことになっているかを理解するうえで面白かった。2で以前から気になっていた問題。command+Fで検索パネルが開くのだけれど、カーソルで文字列を選択した状態でcommand+Fしたら選択された単語を検索してほしい。秀丸エディタがそういう挙動だったので、これがないととっても不便。機能としてはslurp_find_stringというコマンドがあるみたいなので、いっそプラグインを書くか、と思って色々調べていたのだけれど、設定一発でできることが判明しました。trueを追加するだけ。finding関連する不満だった、検索パネルを開いた時カーソルが検索後の後ろにいる(そのまま文字を入力したら以前の検索語の後ろに入力される!)という謎仕様も、この設定で改善されます。検索パネルを開いたら検索語が選択された状態で開くから、command+aで単語を上書きしなくても、そのまま検索語を入力することが出来ます。3.1.3が正式リリースになりました。使おうかと思ったのですが、ひとつ気になることが。TitaniumSDKのバージョンをあげるということは、古いiPhoneやAndroid端末のサポートを切り捨てることになったりしないかな?結論から言うと、3.1.3にあげても市場にある大半の機種で動作するようになっているので、あんまり気にしなくてよかったわけですが、せっかく調べたので一応まとめておきます。SDKの範囲はこの辺に載っています。8.5%2.2は切っていいような気がします。S(SC-02B)がぎりぎり生き残るくらいの目安です。2.3.3以降をサポートすることにすれば、TitaniumSDKは最新の3.1.3でも大丈夫なことになりますね。「最高のタブレット」を求めて!(公式データのコピー)iOS6が93%、iOS5が6%。それ以前は切ってよさそう。iPhone3GSですらiOS6対応ですから、iPhone3Gを切るくらいは十分アリでしょう。5.0-7.0サポートなので、これを使って問題なさそうです。3.1.3を使っても古い機種を切る心配はしなくてよさそう、という調査結果でした。ThemeCountry。