KazuCocoa

Appium 1.3.5 beta released!!

Appiumの1.3.5がリリースされていた。 1.3.4では、環境によってはadbコマンドかinstrumentsへのコマンドが正しく動作しないことがあったのでmasterブランチを追ってましたが、これでnpmの世界で過ごせる! 比較的大きなものとしては、iOS8.2の対応とかでしょうか。とはいえ、対応バージョンの追加などの比較的細かな所になりますが。あと、Androidに関してはUiAutomatorあたりでworkaroundが入っていたりとするので、AndroidでUiAutomor使っている人には良いのでは。何も問題なければ、多分1.3.5はこのままリリースされるはず。 https://discuss.appium.io/t/appium-1-3-5-beta-released/2511 iOSアプリで要素を取得するとき、Appium.app経由だと取得できる要素が、コマンドラインから起動したAppiumサーバ経由だと取得できないものに出くわしたのですよね。？？と思って、コマンドラインのAppiumサーバ経由で起動したあと、inspector経由でアクセスすると、確かに見えない。これは何だ。。。と疑問に思って調査しようとおもってはいるのですが、致命的というわけではないのでんーという感じでうやむやに。そろそろ、コード書いて、コードを読む量を増やしたい機運。More

Why The Facebook App is Rated Below 2 Starsを読んだ

最近みたこの記事から、モバイルアプリ開発に関して学ぶことができた気がするので、メモ。これはメモなので、興味のある方は本文読んだ方が良いです… 最近のiOSのFacebookアプリは、各国で以下のように平均で低いレートを得ています。この記事では、その原因を分析していました。 Breakdown of Issues Reported 以下は、1月1日〜1月15日の間の、USにおけるレビューの内容を集計したものです。これを見ると、マイナス要因になるレビューはアプリのクラッシュコア機能の2つが大きいそう。他にも要因も書かれていましたが、大きくはこの2つのようですね。リリースサイクルとQAチーム FacebookのiOSチームは、2週間のリリース間隔を持っているようです。また、1週間ごとのスプリントで開発サイクルを継続しているよう。このYouTube記事によると、FacebookはQA期間を設けていますが、公式なQAチームは存在しないらしいです。その代わり、テストベースの開発に注力しているようです。 “As you may know, Facebook does not have big QA teams…we believe that developers are responsible for their own code, and they’re supposed to write the tests to do that.”- Quote from Alan Cannistraro 実施しているテストツールの一部以下のようなテストツールを使っているそうです。 Snapshot unit test ios-snapshot-testingのやつですね。GitHubで公開されています。…More

Pactのサンプルを動かしてみた

Constomr-Driven Contract PatternのPactのexampleを実施して動きを観察してみました。 GitHub: https://github.com/realestate-com-au/pact 対象 zoo-app zoo-app配下で、以下のコマンドを入力します。 MockServerがService Providerの役割を担います。 Service Customerである ZooApp::AnimalServiceClient がテスト対象です。ここのテストでは、CustomerがProviderに対して成立させたい機能のリクエストを送り、それに対してProviderが成功/失敗の応答を行うという振る舞いにたいしてexpectで結果を検証します。 Contractフェイズにおける、Customer => Providerへ使いたいサービスの契約を実施しようとするときのもののようです。 animal-service animal-service配下で以下のコマンドを入力します。 Service Providerに対するテストなので、ProviderにConsumerに対するテストデータを保存しておき、Providerに対するリクエストに対して正しく応答ができるか、をテストしています。そのため、想定したHTTPリクエストが正しく行われているか、が主なテストの合否判定になりますね。締め Customer-Driven Contracts Pattern自体、サービス間の関係性を確認するためのパターンです。そこに限ってテストを実施するのであれば関係性を確認するときのやりとりをテストすることに限定されそう。 Consumer-Driven Contractsを採用するのであれば、この関係性が破綻しないように正しくすることは必須要素なので、これのようなシンプルさがあったほうが良さそう。なるほど。以下のpactoも、振る舞いとしては同じことを確認しようとしてそうです。テストダブルとか、そこらへんの機能は必要性が増えたら見てみようと思います。 https://github.com/thoughtworks/pacto http://thoughtworks.github.io/pacto/patterns/cdc/More

MicroServices Patternを読んでみた

こちらの、パターン集を集めている？Webサイトに載っていたので読んでみました。 http://microservices.io/patterns/microservices.html Context and Problem レイヤー分けされたり、hexagonal architectureをもつアプリケーションは、以下のようなコンポーネントから構成される。 Presentation compornents Business logic Database access logic Application integration logic このような様々なレイヤー分けされたサービスから構成されるシステムを(ざっくりと)マイクロサービスと呼ぶ。これらの構成をもつアプリにおけるデプロイアーキテクチャはどのようなものか？ Solution Scale Cubeなアプリケーションアーキテクチャ機能的に分解された多くのサービスの集合としてアプリケーションが動作するサービスは、HTTP/RESTのような同期的なコミュニケーションと、AMQPのような非同期的なコミュニケーションを使うサービスは、それぞれが独立して開発/デプロイされるそれぞれのサービスは、それぞれが分離するために自身のDBをもつ。それらのDBはレプリケーションやアプリケーションレベルのイベントで保守される。 Solutionの問題開発者は、モノリシックアーキテクチャ以上の、分散システムを構築するための複雑性を扱わなければいけない IDEやツールの多くは、モノリシックアーキテクチャ向けのもの Testingがより困難になるサービス間の内部処理の実装が必要それぞれの開発チーム間の連携を構築する必要がある分散トランザクションを使う必要が有るデプロイが複雑個々のサービスが独立して起動、利用可能になるまでの時間が必要なので、サービスが利用可能になるまでに最大でサービス分のオーバーヘッドがかかる類似 API Gateway pattern APIを受け取るgatewayを境界に、Client/Serverで扱う処理を分散させる Netflix APIのようなもの Scale Cube The Art of Scalabilityに記載されているパターンアプリケーションのスケールを、箱型のXYZ軸のそれぞれの軸をもとに表現して説明したパターン X軸スケーリング Horizontal duplication アプリケーションのクローンを増やすことでスケールさせる Y軸スケーリング Functional…More

基礎教養的な、組込みソフトウェア工学ハンドブックを読んだ

組込みソフトウェア工学ハンドブックを読みました。組み込みソフトウェアと書かれていますが、組み込みに特化した話ではないです。ソフトウェアに関わる歴史が、自動車産業から発展してきたことは有名なことでしょう。その流れからソフトウェア工学に関する話を全体的に書いているため、このタイトルになったのだと思います。この著者に私は大学、大学院と学びました。ここに記載されていることは私が5,6年前の学部時代に学んだことの多くで、こういう話をよく聞いたな、と懐かしくもなりました。内容は、・ソフトウェアの歴史・ソフトウェア開発の流れ・ソフトウェア工学の基礎・ソフトウェアの品質・ソフトウェアレビュー・ソフトウェアテスト・ソフトウェアのメトリクスと品質管理といった内容です。いずれも、詳細な技術というよりは、抽象的な内容と簡易な例でまとめられています。少し、ソフトウェアの歴史から見たソフトウェアの品質・テストの流れを知りたいという人にちょうど良いかもしれません。ソフトウェアメトリクスの内容に関しては、数学的な言及もあるので面白いと思います。More

DockerでAndroidビルド・Roboletricとも戯れる

Dockerと、Androidのunit test frameworkであるRoboletricと戯れてみました。共に今更感ありますが、ご愛嬌で… Dockerfile 今回作成したDockerfilrと、imageは以下です。 GitHub: https://github.com/KazuCocoa/docker-appium Docker: https://registry.hub.docker.com/u/kazucocoa/docker_android_testpack/ Docker Hubにあげているので、以降は以下コマンドだけでbuildする必要はありません。(いつ消すかわかりませんが…) boot2dockerをMac OS Xにインストールして、環境を構築しました。Dockerfileに、GooglePlayServiceやら含めたAndroidアプリのビルドに必要になりそうなライブラリすべて入れてみました。 Dockerfile書いているとふと思うのですが、Circle CI、完全にymlがDockerfileですね。Travisにくらべても、まんまDockerだと感じました。ちょっと面白かった。 Androidのビルド環境をDockerで作ってどだったか開発環境としては強いメリットはなさそう。確かに、環境構築が楽でDockerfileを配布すればOKという開発環境に持っていけそうです。が、多くのAndroidアプリ開発はEclipseやAndroid StudioなどのIDEを使います。そうなると、Mac OS X やLinux、Windowsをそのまま使ったほうが楽そう。一方、CIとしてDockerを使うとういうのはビルド環境の管理という観点では有用そうでした。ビルド完了後、必要な成果物をマウント先に保存したり、Deploygateなどに上げるとそれで終わり。TEみたいですね。実機を接続してテスト速度を上げるときは、adbコマンドのtcp接続すればよさそう。（有線より不安定な可能性ありますが） Roboletric使ってみて Roboletric、以下の通りサンプルコードが用意されているようですね。なので、さっとサンプルコードで手を動かしてみました。 https://github.com/robolectric/robolectric-samples このサンプルで使われているRobolectric3.0-SNAPSHOTはまだ正常に動作しない模様。(2015/01/14現在)。Roboletric 2.4とAPI 19向けにアノテーションを加えたコピーを作成して実施してみました。 https://github.com/KazuCocoa/sampleRoboletricTests 正常にテストを実施しても、API 21でテストが失敗しますがRoboletricのAPI 21対応が3.0なので、一旦は気にしないことに。締め Roboletric + GradleでTDD for Androidを実施しようというライブラリもありました。こちらも少し手をつけてみようと思います。 https://github.com/robolectric/deckard-gradleMore

KarmaのMicroserviceへの取り組みを読んでみた

KarmaのMicroserviceへの取り組みを読んでみた。検索する限りでは、以下URLの企業のよう。 https://yourkarma.com/ Microserviceにおける、個々のサービスがコミュニケーションする方法として以下の2通りを用いているそうな。 Communicate each other with HTTP requests Communicate each other with a message queue この中で、HTTPリクエストベースで、あるサービスから別のサービスへメッセージを投げる形をはじめはとっていたけれど、これはサービスが増加してきたらより複雑になってくるからmessage queueを使うようになってきたとか。実現のため、Amazon SNSをイベントを配信するために使い、Amazon SQSをそれらイベントを蓄積するためにつかったそうな。プロセスが成功したらjobがQueueから取り出され、進行し、削除される。もしプロセスが失敗すれば、そのプロセスはqueueに戻ってくる。新しいマイクロサービスが追加されたら、そのサービスはメッセージのタイプを受け取るか、何のメッセージを配信するかという設定ファイルを読み込む。Fareと呼ばれる内省ツールを使っている。 The Biggest Challenge is Testing とあるように、系として如何にテストするか、が大きな挑戦だと言っていたところが面白かった。この記事のコメントのところに、Pactの話も出ていて、Consumer-Driven Contracts Design Patternはサービスごとの依存性を緩和する手段としてベストプラクティスになりつつあるのかなという感じを受けました。More

Consumer-Driven Contracts Design Patternを読み漁ってみた

Microserviceのテストの話を調べていると、以下のような記事を見つけました。 Simplifying Micro-Service testing with Pacts このPactoと呼ばれるツールがConsumer Driven Contractsと呼ばれるデザインパターンを使っていると書いていたので、同デザインパターンを少し調べてみました。関連: MartinFowler氏のブログ記事 Pactoに関するGitHub デザインパターンとしての説明 http://www.servicedesignpatterns.com/WebServiceEvolution/ConsumerDrivenContracts http://java.dzone.com/articles/application-pattern-consumer アプリの実装寄りの話はこの記事が参考になりそう消費者主導契約を使ったサービス指向開発元記事 Consumer-Driven Contracts Design Patternをざっくりいうと Consumer-Driven Contract patternは、Consumerが取得可能な必要なサービスをProviderと共有(規約)し、Customerごとに特定のサービスのみをProviderから利用可能にするパターンです。特定のCustomerが使う機能をProviderから取得することで、Customerは限定された範囲の機能を利用します。CustomrはProviderにより提供されるであろう機能の取得を試み、契約(Contract)を成立させようとします。このとき、Customerが利用する機能の補助的な説明をProviderに提供することもできます。ここで契約が正常に成立すると、サービス実行時には基本的にCustomerは契約の成立した機能を使ってProviderからサービスを受けます。 Customerが使っている機能はProviderに適宜提供されます。ProviderはすべてのCustomerが利用している機能の規約の集合をもちます。登場人物 Provider contracts Providorから提供されているサービスに関する規約。XMLなどで記載される。 Consumer contracts Provider Contractのうち、個々のCustomerが必要とする範囲の規約個々の消費者が必要とするサービスの契約 Consumer-Driven Contracts(消費者主導契約) Service Providerが満たすべき全Consumer Contractsの集合を書いた規約 Summary of Contract Characteristics MarfinFowler氏の記事のなかで、Provider,Consumer,Consumer-Drivenのそれぞれがどのような関係を持つものかをまとめたもの。 Contract Open Complete Number Authority Bounded Provider Closed Complete…More

NetflixのHystrixにも使われるCircuit Breaker patternを調べてみた

Testing Strategies In A Microservice Architectureを読んだを読んでいる途中に出てきた、Circuit Breakerと呼ばれる機構を調べてみました。Martin Fowler氏がこの記事で言及しているものでした。このCircuit Breaker patternは、Release It! 本番用ソフトウェア製品の設計とデプロイのためにで描かれているような、本番環境化において発生する、複数システムが関係するからこそ発生する障害を抑えることも目的としたデザインパターンのようです。「複数システムが関係するからこそ発生する障害」とは、一部システムの負荷が高まりタイムアウトするといったことを含みます。内容自体は、障害検出のための共有のオブジェクト(Circuit Breacker)を用意して、監視・検出できるようにするということらしいです。NetflixのHystrixがその実装としてこのパターンを含んでいます。ちなみに、RubyだとここなんかがOSSの実装例として上がっていました。 Circuit Breacker Pattern Circuit Breaker patternの考え方は単純で、以下の図のようにClientとSupplierの間にCircuit Breakder Objectを配置し、そのオブジェクトが障害のモニタリングを行いエラーを制御する、というものです。以下の図では、Circuit Breadker Objectが、Supplierのエラーを複数回検出すると、以降は復帰するまで必要以上にリクエストしないように制御します。サンプルプログラムも置いていています。それを見ると、@failure_countのインスタンス変数にエラーの回数を足していき、一定数超えるとCircuit Openな状態にする。意図的にリセットされるとそのインスタンス変数がゼロになる、という処理で単純に書けますね。 Circuitの状態遷移は以下と定義されています。以下ではClose/Openの2値からさらにHalf Openというものも加え、Openな状態からresetされた後の復帰確認の状態を作っています。この実装には、並列プログラムのデザインパターンであるFutures and promisesが良い知見を持っているそう。 Circuit Breakersのオブジェクトを設置することは、失敗するであろうオペレーションを抑制することができるところに価値があります。例えば、HTTPリクエストが30秒タイムアウトを繰り返す間、関連するサービスはそれを待たないといけないですが、そもそもCircuit Openな状態が既知であれば失敗することがわかっている処理に30秒も待つ必要がなくなるわけです。締め Breacker自体が障害になることもあるので、ClientはCircuit openな状態含めて適切な処理を実施する必要があります。一方で、Microservicesのような複数システムが連携する場合、監視・検出はシステムの品質を高めるために非常に重要な役割を担います。その仕組みを共通化してライブラリとして用意しておくことは価値が高そうです。More

Broad Stack Testとは

Broad Stack Testに関して、Testing Strategies IN A Microservice Architectureを読んだで言及されていたので少し調べてみました。 Martin Fowler氏がこの記事にて言及しているテストタイプです。同記事では、end-to-end testや、full-stack testに似ていると書いています。 Broad Stack Testは、SelneiumやSahiのようなツールを使い、UI越しに実施されるテストだそうです。テストピラミッドにおいてもUIテストに区分されると書かれていたので、Microservicesにおいて末端のユーザが使うUI越しの操作をテストする、というテストタイプのようです。なるほど。More