Author Archives: KazuCocoa

Bugsnagを使ってみたが、良さそうだ

主にはモバイルアプリのクラッシュログなどのログ管理に関して、最近の流れを知りたいと思いいろいろ物色してみました。類似サービスとしてはCrashlyticsなんかがありますが、いろいろ使っていると機能的に柔軟性が足りなかったりして目的に沿った利用ができないことが増えてきて、他に手頃なサービスあるのかなと思ったことも要因です。 Crashlytics以外にもいくつか調べた中で、最終的に良さそうと思ったのはBugsnag。 Bugsnagは以前どこかで見たか聞いたことあったのですが、そのときはCrashlyticsのように整ったGUIがある方が使い勝手が良かったのでそこまで調べてませんでした。一方、最近ではGitHubとの連携など、サービス間の連携に対して価値を置くようになりました。そのため、ここでちょっとちゃんと使おうと思って使ってみることにしました。 Bugsnagが良かったところ 多くのプラットフォームに対応したログ収集サービス ログ収集サービスに特化していることもあり、多くの言語、プラットフォームをサポートしていました。 リファレンスが書いてあったものでRuby、Python、PHP、Laravel、WordPress、Android、Cocoa、Node.js、JavaScript、Unity、Java、EventMachine、Go、.NET。 私は今回はおもにAndroidのリファレンスを読んだだけなのですが、ログのフィルタリングやビルドの種類ごとにログに対してプレフィックスを変えるなど、よくできたSDKなように見えます。 ログを取得するときはBagsnag上で見ることもできますし、BagsnagからStreamとしてログを自分たち絵取得することもできるなど、APIの連携もちゃんと整っていました。参考になる。 Bugsnagの方々、ログ収集の知見、深そう。 豊富なAPI ドキュメントを眺めるとわかるのですが、ログを取得するためのAPIを豊富に提供しています。 例えばCrashlyticsのようなサービスだと、ある程度まとまった情報を1つの画面で見ることができますが、求める情報だけでフィルタリングするといった細かいところまでは手が届きません。そのため一時期はWebhookを使おうと思いましたが、WebhookにはCrshlyticsへのURLが含まれているだけなど、ログを取得するにはCrashlyticsのGUIを最終的に見るしかないし画面のカスタマイズがそこまで柔軟ではないので欲しい情報だけ絞って見ることが難しい状態でした。 なので、豊富なAPIは自分たちのみたい情報でフィルタリングするWebアプリを作ればそれらが見る事できるし、便利そう。 GitHubとのissue連携 GitHubとだけではないのですが、バグトラッキングシステムとの連携もちゃんとしていました。GitHubを例にとると、Bugsnagからissueの作成はサポートされているのは当然なのですが、ちゃんと連携しているissueが閉じられたらBugsnagのエラーも解決済みにマークされるのです。また、すでにGitHubにissueとして作られている場合、そのissueをBugsnagと別途連携させることができます。連携したら、やはり閉じられると閉じられる。 こういう流れができるわけですね。 クラッシュなどの不具合、特定のログが一定数発生 => issueを作成 => issueベースで作業 連携済みならBugsnagにマークがつくので、issueとして対応されているものかすぐ判断できます。また、issue作成時になんらかの形で再現性確認を自動化できればさらにハッピーになりそう。（モバイルアプリでは難しそうですが。。。） 以下、GUIと連携の例。 一覧。 エラーの詳細画面です。 GitHub issueとの連携箇所。 GHEとの連携もすでに用意されていることろがなかなかいけてますね。 こんな感じで投稿されます。 issueとの相互連携もできます。関連付けておくと、issueをCloseした時点で、Bugsnagのエラーも解決済みのマークがつきます。 よくなかったところ 良かったところ以外でいうと、GUIは他の類似サービスよりも劣ってるとみられる気がします。ただ、GUIを優先したいという要求は私にはないので、そこはさほどマイナスではないです。（むしろ、ログ収集ツールとして気軽に組み込める体裁を維持しているところがすごいと思いました） 他は、Android以外使ってないのでなんとも言えないです。。。なんかすみません。 締め Trialが14日間で、それが終われば制限化でFreeで利用することもできるようです。私自身の個人利用はFreeで大丈夫なので、今後も使っていきたい。 こういうログ収集システム、サービスの拡大につれて自社で作る状態に落ち着きそうですが、そこまでなる前の段階ではかなり良さそうなサービスに思えます。Crashlyticsなんかは、少数のアプリを監視すれば十分な状態ではほぼ満足いきますが、監視すべきアプリが増えたりしてくると物足りない。その中間がBugsnagで、そこからさらに拡大すると自社、という流れになるのかなと思ったりしました。 これで、私のAndroidアプリの開発環境は以下の形で落ち着きそう。 Circle CI + Bugsnag + Deploygate Bugsnagだ！More

Appium 1.3.5 released

Appium 1.3.5 がリリースされましたね。 リリースノート https://github.com/appium/appium/releases/tag/v1.3.5 ここまでのバージョンになると、開発量も少し落ち着いてきたように見えます。 iOS8.x系に関しても、iOS7=>iOS8のような大きな変更がシミュレータにも入るわけではないので。 driver.get()でpageを取得できなかったところなんかの修正が入っています。あとはiOS8.2。 iOS8.3もbetaで入手できるようになりましたが、iOS8.3からは OS X 10.10以降がRequirementになります。 なので、メンテナンスされるメインストリームもOS X 10.10に移り変わる流れになりそうな予感。 Androidに関しては以下の修正が入っているので、1.3.4使っている人は更新したほうが良さそう。もとより、私の環境では1.3.4があまりちゃんと動かなかったので、masterブランチや1.3.5betaを使っていましたが、ここでnpmから入手できる正式版が使えるようになった。 add workaround for issue where UiAUtomator fails to find visible elements. fixed undefined member error for the release object.More

UiSelectorを使うようにしたほうが良さそうだ

過去いったんまとめた、Appiumを使ってiOS/Androidの要素を取得する方法の数々に追記した。 Appiumの1.3.3まではできていて、1.3.5betaからできなくなったことに以下による要素の特定がある。 これは、以下のようにUiSelectorを使えば問題はないみたいだ。 UiSelectorはこちらから確認することができる。Uixxxxxシリーズは、uiautomatorの要素として提供されているものなので、UiSelectorをちゃんと使っていくという方がAndroidでは正しそう。 心無しか、AppiumもUiSelector使って安定したようにみえる。 Appiumで行うレベルのテストはテスト環境で影響される要素が多いので、地道にFlakyなテストを減らして安定したテストを回したい。。。More

『武士道』を読んだ

武士道の根本のところを、お前はどう考えているか >『葉隠』 武士道と云は、死ぬ事と見付けたり >『葉隠』 武士道を読みました。読んだ後になって知ったのですが、こちらの武士道のほうが有名？なのですね。Amazonのレビュー見た感じですと。 この書籍では、”武士道”とは、『対峙的人倫観をふまえた独立の精神』と説いていました。解説によると、新渡戸稲造氏の武士道は、武士道そのものではなく、新渡戸氏の道徳思想を主に説明しています。一方、この書籍では武士道という精神論に対して、様々な原典を持ってきた上で分析しています。そういう意味では少し硬くて読みにくい反面、1つの事柄に関しても多くの原典を参考にしているので本当に理解を深めたい人には良書なのかもしれなです。 『武士道と云は、死ぬ事と見付けたり』 文面にも引用した、おそらく武士道として広く知られるこの引用の一節は、武士道として解かれる『葉隠』の一節でしかありません。そして、その本質は死を目前としたとしても、確かに存在している自己の確立を求めるものであるらしいです。武士道とは、自己を磨くことや、他者へも礼儀を持つことなどの心持ちが多く解かれていたり、また、独立ということも重要な要素として解かれている、同時の人としての有り様全体を説いた道のようです。 ありのまま、名と恥、死の覚悟、しずかながらも力強い、などなど、様々な要素がちりばめられていました。 茶道、禅、武士道と読んできましたが、自己の洗練やそれに付随する質素さなど、多くが繋がっているように見えました。それらはざっと浅く見聞きした今までの知見と大差なく。一方、こういう話は海外の人たちの興味の対象として一定の強さがあることも事実のようです。無知よりは知っていたほうがいいし、宗教のように強く依存するまで行く必要もないけれど、ざっと時間を見つけて技術書以外にも文化を学ぶって良いですね。 食文化にもつながる要素も多い。More

exclude group: ‘javax.inject’してinjection系のjava.lang.NoClassDefFoundErrorを回避する

espressoを導入するためにcom.android.support.test.espresso:espresso-core、com.android.support.test:testing-support-libをインストールします。 そうすると、テスト実施時に というようなエラーを確認できることがあります。 このエラーはDaggerやRoboGuiceを導入していると確認されました。これは、espressoのjavax.injectが競合しているから発生している模様です。なので、以下のようにexclude groupで指定してあげると、回避できます。 ここらへんのpom.xmlなんか眺めていると、確かにjavax.injectが依存関係で確認できますね。 なるほど。 関連 stackoverflow★More

AndroidのアニメーションをOFFにしてFlakyなテストを減らしたい

モバイルアプリのViewに対する自動テストを行おうとした場合、画面遷移時なんかのアニメーションがFlakyなテストにつながることが多々あります。たとえば、Appiumやespressoなどを使って複数のViewを跨いだりする時なんかはよくある話です。 Androidに関しては、開発者オプションの設定により、以下アニメーションをOFFにすることが可能です。 ウィンドウスケール トランジションアニメーション Animator再生時間スケール この設定をOFFにすることで、アニメーションをOFFにした上でViewに対するテストを実施できるようになるので、より安定したViewに対するテストを実施することができます。ただし、この設定をOFFにするとアニメーションが無視されるようになるので、テストレベルとその時々にどんな不具合を検出したいかというテスト設計に沿って、アニメーションを無視する/しないを決めるとよいでしょう。 個人的な感覚では、Androidにおいてはespressoによるテスト実施時はアニメーションをOFFにしてViewの確認、Appium使うときはアニメーションも考慮して確認が良いかなと思っています。これにより、UnitTestingから徐々に確認する領域を増やしていき、テスト自動化のビラミッドのような形に、自動テストの厚みを調整できそうな気がします。 実施方法 以下コード例に沿って、テストユーティリティを実装しておきます。 Android端末におけるAnimationをOFFにするコード例 DisablingAnimations AndroidManifest.xmlに SET_ANIMATION_SCALE を指定する必要があるのですが、Gradle 2.1からは特定のビルドだけ、特定のマニフェストを追加することができる模様。 そのため、たとえば、 ./gradlew coonectedAndroidTest のときのみSET_ANIMATION_SCALEを増やしたい場合、以下のような感じでAndridManifest.xmlを作れば良いみたいです。 src/androidTest/AndroidManifest.xml ここまでの対応をしたのち、テストスクリプトのsetUpにでもアニメーションをOFFにする変更を書き込み、espressoを実施してみます。問題なく動く!!!と思っていたのですが、以下のようなエラーが… Cannot disable animations due to lack of permission. SET_ANIMATION_SCALEを眺めてみると、以下のようにどうやら3rd party製アプリには許可していない模様。 いろいろ調べましたが、これのWorkaroundは以下のようです。 AndroidManifest.xml にSET_ANIMATION_SCALEを許可しているアプリに対して以下adb shellコマンドを実施する 標準出力に特に何も出力されなければ、成功です。システムのアプリケーション情報に、アニメーションの権限が追加されていることを確認することができます。以降、DisablingAnimationsのユーティリティによりアニメーションをOFFにするということが正常に受け付けられるようになります。 ちなみに Appiumにも、1.4になりますが以下のように計画があるようです。 Appium should disable Android’s system animations to reduce flakiness Appiumでは、ツールの作り上、espressoよりも実現しやすそうとも思うのですが時期があえばなんらかのコミットもしたいかな。adb shellのやり方に関しても同じところを参照しているようなので、実装方針も思っているのと同じ方針な気がする。 締め アニメーションのOFFはViewに対するテストでFlakyなものを減らすという意味でも何気に必要だったりします。ただ、adbコマンドを毎回使ったりすることが面倒なので、一番楽なのはアニメーションをOFFにしたテスト用端末でテストを実施することだったり… 雑談ですが、最近、TestFlightから別サービスに移ろうとする流れがありますね。Appleが旧TestFlightをやめると言ったので。 TestFairyとかとか、代替サービスとして探している人も多いですが、そこらへんでテストサービス それらを見てて感じるのですが、落ちバグ発生時、そのクラッシュログを動画付きで取得して、その再現まで自動的に実施できる環境の構築なんかしてみたいですね。技術的な関心なだけですが。ただ、不具合レポートからUI含めた再現をどうやるかなーと思った時、無理そうと思ってしまう。もしかしたらUnit testレベルなら再現できるかもしれないですが、それがユーザ操作として正しく発生しうるクラッシュを防ぐことにつながるか、と考えるとそうとも言えないことを多々経験したので、やって価値あるかなーと考えてしまう。難しいですね。More

『星の王子さま、禅を語る』を読んだ

最近、茶道の本を読んだり、今回読んだ禅に関して読むことで日本固有の文化に触れてみています。合わせて、禅に触れてみようと思い、星の王子さま、禅を語るを読みました。 ソフトウェア開発において、Zenという言葉が使われることがあります。それらは、簡素・質素といった禅から派生していると説明されていることを見ます。発問もZen(禅)というので、日本の禅が大きく影響しているのでしょう。 海外のソフトウェア開発では、開発物の設計思想だとか、何を大事にしているかといった芯を重要視していることが多いように見えます。そこで、幾つかのきっかけも相まったものの、その禅というものを少し学んでみようと思い今回の書籍を手にとってみました。 自らの立つ場所を深く掘れ。そうすればよい泉が湧くだろう それとは別に、純粋に、 星の王子さま を題材に禅を説明していたという、非常に興味沸かせる題材を扱っていたこともあります。 この書籍は、以下のそれぞれの題目に対して、星の王子さまの引用、その説明という形で流れていました。星の王子さまの引用と、各項目だけつらつらと残しておきます。 不立文字 肝心なことは、目に見えないんだよ 目では、何も見えないよ。心で探さないとね。 目に見えない世界、円 直指人心 どんな大人だって、はじめは子供だった。でも、それを覚えている大人は、ほとんどいない 智慧 脚下照顧 君の探しているものなら、たった一輪のバラの花にだって、一滴の水にだってあるのになぁ 色即是空(平等) ちょっと離れたところから見ると、それはもう、本当にすばらしい眺めでした 空即是色(差別) おれにとって、あんたは、世界中でたった一人しかいない人間になるし、あんたにとっては、それは、世界中でたった一匹しかいないキツネになるのさ もう一度、バラの花を見にいってごらんよ。あんたのバラが、世界中にたったひとつしかないことがわかるからね 一隅を照らす ばかばかしいと思えないのは、あの人だけだ。それは、たぶん、あの人が、自分のことだけでなく、他人のことも考えているからだろう 自由 もし五十三分を好きに使っていいんだったら、僕は、新しい水のわく泉のほうへ、のんびり歩いていくのになぁ 仏性 「砂漠が美しいのはね」、と王子さまがいった。「どこかに井戸が隠されているからさ」 一期一会 最後の朝には、いつもやっていた仕事が、とても大切なことのように思われました 全体的には、思想というよりも禅という考え方について書かれていました。これらは明日から使えるなにか、といった類ではないですが、このような考え方に触れるって面白いですね。 少し蛇足。私の実家では、叔父/叔母が主に信仰していたものが浄土真宗でした。親鸞が有名ですかね。一般的に仏壇などあれば浄土真宗や浄土宗がおもだと思います。それらも茶道や禅などと大きく違わない。異なることはあるけれど、同じところもある、という感じに見て取れました。私自身は浄土真宗を特別学んだりしたりはしていないのですが、質素や簡素、直指人心のようなところは心地よいなと感じました。 茶道と禅に合わせて並んでいた武士道について読んでみようと思います。以前、剣道を学んだときに武士道に関して少し見聞きしたことがあるのですが、それも中学校の部活動なので、正直覚えていない…いずれも質素や芯を持つというところで重なることがありそうな気がしています。 このくらいの本であれば、数時間あればざっと目を通すくらいできて気軽でよいですね。More

茶道の哲学を読んでみた

最近、茶道の哲学を読んでみました。 ちゃんと考えたりすると、哲学的な、思想の話しにもなる内容でした。ただ、そこまでの専門性を求めて読んだわけでもないので、以下では綺麗にまとめたりはしてないです… きっかけ 大きな理由があったわけではないですが、五島美術館にも行ったこともあり、茶道に関して少し知見を広めようと思ったことがきっかけです。 茶道は禅の精神が大元にあることや、以下のような性格、また、一期一会といった比較的知られている熟語に関しても強い関係性があるとは知らなかったです。ただ、茶道の風貌を見ていると、禅のような質素さなんかはつながるものがあるのかなとは感じていました。(千利休とか、日本の歴史でよく学ぶ箇所ですね) 茶道文化の7つの性格 茶道文化には、大きくわけて以下の7つの側面があるらしいです。 不均斉 ものの整ったというような事の否定 簡素 端的で、直截で、簡潔 枯高 やわらかい豊満さよりも、痩せて勁い 自然 無念無想といったもの 幽玄 底の知れない無底の深さ、言語道断、心行所滅 脱俗 人も仏も否定するような、徹底した脱俗 静寂 物の無一物の静けさ いずれも、様々な箇所で禅や仏の話しが取り上げられていました。多くは通じるものがあるのですね。 そのほか気になった言葉 和敬清寂 茶道における”好み” 既成の物事の中から茶道の規範に合うものを択び採る 茶道の規範に合うものを新しく形成するとか、創造するとかいうこと 侘び 足るを知る 一期一会 道 海外の人と話したりするとき、日本の事を少し話せたり、比較的有名な茶道や禅に関して知見があると話しのきっかけにもなります。また、年齢が上の方と話すときも、多少の知見は役立ちます。あまり専門性を求めるわけではなく、少し教養程度にかじる程度ですが、こういう書籍を読むのも気晴らしになって面白いですね。 Zenとか、ソフトウェア界隈でも話を聞いたり海外の人が使ってたりします。が、私はZenに関して質素とか、簡潔とか、そういう薄っぺらい理解しかないので、禅なんかも今度は読んでみようと思っています。硬い文章ではなく、面白そうな書籍を見つけたので…. 量としては半日くらいかな。More

espressoをたしなんでみた

前年末頃、espressoも2.0になり、JUnit4も使えるようになったAndroidのテスト環境。 既存コードの対応を考えるとJUnit4対応も考えないといけないですが、それに見合うだけのメリットが出てきた気がします。 espresso 2.0 release note サンプルプロジェクトはこちらにありました。 私はiOSと合わせてAndroidに関してもAppiumを選定していたのですが、espresso2.0の登場により、役割とテストレベルに応じてViewを含んだテストを行うときに程よい区分ができそうです。結構、良い補完関係を持つツールだなと感じています。 Appiumの特徴は、リリースapkを直接テストできることだと思います。つまり、一般ユーザがそのまま使う操作に近いUI操作を模倣することができます。そのため、様々なテストレベルにおけるテストを実施したのち、E2Eレベルでの、システム全体としてのテストを実施することができます。 espressoの特徴は、やはりViewを構築しながらも実行の速さを出せるところだと思います。そのため、mock serverなどを用意して、短い時間にUIのレイアウト確認を実施することができます。Hermetic testとしてのテスト環境により適しているかもしれませんね。また、JUnitで記述するので、CIに程よく組み込めそうです。 いずれもテスト環境の構築で変化する要素は多分にありますが、Viewの確認を行うにしても、それぞれが得意とする分野は異なるので、テスト戦略や計画、設計に応じた使い分けができれば良いと思います。この箇所は、テストのしやすさがiOSと異なりますね。 espressoを少し espressoのサンプルです。先ほどのGitHub上のサンプルコードより引用しています。 R.id.operation_mul_btnと、要素の指定はidの直接指定をこなうことで要素の特定をしているようです。API18以上だとresoirce_idの直接指定ができるようになったものと同様な感じで要素は指定するようです。 espressoのCheatSheetに以下の画像がありました。 これを見ても、espressoは画面単位で、期待した描画ができているか、というところに焦点を当ててテストを書くことが適していそうです。 想定したユーザシナリオを実施できるかは、Appiumが良さそう。More

Exercism.ioでちょっとしたプログラミング問題を解いていく

最近、exercism.ioというプログラミングを学ぶサービスを使ってみています。 http://exercism.io 世界を相手に腕を磨けるプログラミング学習サイト「Exercism.io」のWIREDの記事に惹かれてやってみたのですが、なかなか面白いです。 これは、ちょっとした問題を順に解いていく、というものです。解いた回答はサイトにサブミットし、サブミットすれば次の問題を取得、解くことができる、というものです。サブミットした回答は様々な人が見ることができる状態になり、時折、気になった解答例や自分の解答にコメントしてくれる人もいます。 同じ解き方を、面白い方法で解いたコードはナルホド、と思うところがありますね。 問題の内容自体は、TDDのようにテストコードがあらかじめ用意されており、そのテストコードがすべてグリーンになるまでプログラムを構築して解いていく、というものです。中には素数判定が必要なものもあったりと、ちゃんと考えればより高速なアルゴリズムで問題を回答できるといった種類の問題も存在します。 ちょっとしたプログラミングを使ったクイズみたいな位置づけですね。他の人の回答みたりすると、自分とは異なる使い方や、よりスマートな記述で問題を解いているものもあって、程よい頭の体操になりそうです。 Code Schoolのようなちゃんとした学習をするサービスもありますが、ここは小さな問題がたくさん転がっているので、カジュアルに遊ぶことができるのが面白い。 2015/01/24 時点で、以下の言語の問題が用意されています。 私はRubyを少しやってみました。他のコードにも触れてみようかなと思ってます。More