Springが、Netflixが公開している彼らのOSS群を説明している記事を読みました。ちょっと、記憶に止めておきたい内容を探っているのでそのメモがてら。 記事: http://cloud.spring.io/spring-cloud-netflix/spring-cloud-netflix.html これは、Netflixのmicroservicesを構成するツール群を説明していました。 Service Discovery Eureka Clients Circuit Breaker Hystrix Intelligent Routing Zuul Client Side Load Balancing Ribbon Service Discovery: Eureka Clients Service Discoveryはmicsoservicesベースのアーキテクチャとして大事な要素 Circuit Breaker Hystrix Clients Netflixは、CircuitBreakerを実装したもの。Microservicesでは、複数のサービスコールのレイヤを持っている。 低レベルのサービス障害が発生すると、障害がユーザまで伝っていくので、障害のあったサービスをフォールバックすることで障害の伝搬を抑制することが目的 ↑の状態になるサービスは、例えば /health の応答として “CIRCUIT_OPEN”というstatusを返す Dashboard circuitがOpenかCloseかを知ったり、応答速度を監視するためのダッシュボードですね Turbin すべての /hystrix.stream エンドポイントを、Dashboardの /turbin.streadm エンドポイントに統合するアプリケーション。アプリのインスタンスはEurekaにある。 Declarative REST Client Feign Feignは、Web serviceクライアント この記事では、Spring frameworkとして使える方法も紹介してました。 Client Side Load Balancer…More
Author Archives: KazuCocoa
Testing Strategies in a Microservice Architectureを読んだ
2014年11月18日に公開された、Testing Strategies in a Microservice Architectureを読んでみました。Microservicesに対するテスト戦略に関する大まかな方針を書いています。想像した通りだったのですが、理解しやすく、例も記載しているので取り組む人はいったん読んでおいたほうが良さそうです。 http://martinfowler.com/articles/microservice-testing/ 目次 Some Definitions What is a microservice ? Anatomy: a loook inside a microservice Architecture: choreographing service then the Testing Strategies… Unit: mockist vs classic Integration: datastores and eternal services Component: in or our of process ? Contract: ensureing consistency across boundaries End-to-end: tips and tricks the some…More
iOS向けBDD Toolsをいくつか使ってみた
OBJC #15 TESTINGを読んでで並べられていたBDD Toolsを使ってみました。今更感あるものもありますが、そこは復習込みで、という感じで。 Swiftで書かれたものに関してはGitHubにサンプルを作りました。Objective-Cのものは確認程度。あとはXcode 6 Beta時代のTDDチュートリアルを行ってみました。Xcode6.1.1環境で私は実施したので、いろいろAPI変わってて辛かった… Objective-C時代のBDDフレームワーク Cedar Kiwi Specta Pure Swiftで開発されているフレームワーク Quick https://github.com/KazuCocoa/sampleQuickSpecs Sleipnir https://github.com/KazuCocoa/sampleSleipnirSpecs あと、ついでにBDDのチュートリアル。 https://github.com/KazuCocoa/sampleTddInSwift XCTestを使った例 サンプルを使ってみたところと、ざっと見た感じ、Quickは良さそう。Sleipnirは、最近はさっぱり開発が止まっている様子。黒魔術な気がしたSleipnirも、XCTestを使っていないという点で面白そうでした。 Onjective-Cも、知名度も合わせてKiwiを使っていたのですが、Spectaを使ったほうがよかったかもなと感じました… ただ、SpectaはQuickの開発に本腰入れている感じがするので、今からならSpectaよりもQuickのほうが良さそう。 あと、やはりモバイルアプリはコードレベルでテストを充実できるのはModel、頑張ってControlerレベルですね。Viewははやり実際に描画させないといけないので、AppiumとかCalabashとかが必要そう。More
Appium x Androidの要素指定の手段にtext要素による指定を追加した
Appiumを使ってiOS/Androidの要素を取得する方法の数々に以下のAndroidによる要素の取得方法を追加しました。 Androidでは、Android SDKに同封される uiautomatorviewer コマンドで要素を表示確認します。そのツールで text 要素に表示される文言からその要素を特定する場合、上記のようにXPathの記述で要素を特定することが可能です。 利点 contentDescription指定が不要 表示されている文言ベースで要素を指定可能 比較的手軽 欠点 TextViewやButtonなど、表示される要素が異なると使い分けを行う必要がある 共通でresorceIDやcontentDescriptionで指定可能であれば、そのような使い分けはしなくてもよくなる テキストが表示されない要素を特定することは不可能 UIの表示文言にテストの安定性が左右される システムの言語設定に依存したり… ここまで揃えば、iOS/Android共に多くのシナリオを比較的容易に自然言語でシナリオ自動化できそう。More
「イシューからはじめよ」を読んだ
イシューからはじめよ ― 知的生産の「シンプルな本質」 [Kindle版]を読んだ ある方からオススメされたので読んでみた。 知的労働者として価値のある仕事を行うために行う問題解決の一連の流れを載せている。問題(issue)の見つけ方、仮説、ストーリー、アプトプットへの変換など。私の読んだことのある問題解決系の本などにくらべて、技法のような話よりも”アウトプット”として誰かに共有、報告するまで全体を書いているところが価値のあるところだと思う。 知れば知るほど知恵が湧くより、知り過ぎるとバカになる という言葉が出てくるが、大学時代の教授の言葉を思い出した。書籍などに載っている既存知識を吸収することは大事だが、一定の基礎を学んだ以降は読みすぎないほうが良い。すでに存在する発想にとらわれ、自分で考えた自分の発想を大きく阻害するから、というものだ。 カナヅチを持っていればすべてのものがクギに見える という、マズローの有名な言葉にもあるように。 メッセージに納得して、行動に移してもらう。いくつかアウトプットの目的をあげていたが、私が常に意識しなければいけないアウトプットの目的が見事にこれだった。最近、外部で発表する機会も増えてきて、資料を作ることがある。その中で、ここでも書かれているようなストーリー性であったり、伝えたいことを絞れなどはよく言われているので、書籍としてまとめて読むことができることは、私には価値があった。頭に常に入れておきたい。 書籍のはじめに、「悩む」と「考える」という2つの言葉を、答えの有無で説明している箇所があった。私の思っていたことに似ていて共感を持てた。答えを見つけるために「考える」のと、答えを見つけるわけでもなく、思考を発散させたり単に思考を巡らせるだけの「悩む」。仕事を行う上での価値の有無は書籍に任せるとして、私はどちらも人なので必要だなと感じた。 何か課題を見つけ、考え、アウトプットへ落とし込む方法をざっと頭に入れておきたい人にはオススメの本。細かな技法を知りたいという人には、他を当たった方が良さそうな内容。 自己啓発とか、課題解決の思考云々の書籍はあまり読まないが、これは文章や発表資料を作成するときは時折読みたいと感じた書籍だった。More
モバイルアプリのCIサービスが増えてたのでいくつか使ってみた
iOS/AndroidのCIサービスがまた増えてきたようなので、少し触れてみました。安定性はやはり以前からあるものが良さそうですが、今年は選択肢の多様化と価格競争も進みそうですね。あとは対Enterprise向けサービスも今はTravisだけですが他の選択肢も出てきそう。 今まで触れたことのあるCI環境 Travis CI, Travis CI Enterprise Wercker CloudBees Hosted CI 新たに触ってみたもの GreenhouseCI Ship.io Circle CI 試したことは、適当なサンプルプロジェクトを、GitHubのPushなどを契機にビルドするということです。それぞれのサービスの制限(ディクス容量や、時間制限など)までは確認していません。 GreenhouseCI ビルド対象はRepository URLの直接指定で行います。Publicなものであればそのままビルドすれば良いのですが、username & passでのログインやSSHの利用が提供されているので、private repositoryも対象にすることができます。 ビルド設定すると、Cloneしてきて、Android/iOSを識別、いったんビルドを試します。その後、スキャンしたビルドオプションをプルダウン形式で選ぶことができるので、そこで次回以降実施するものを選ぶことができます。 GitHubのWebhookに所定のURLを設定したら、GitHubへのイベントをきっかけにCIを回すことができるところまでサポートされている模様。 Ship.io GitHubに接続し、リポジトリを指定してビルドを開始します。こちらはまだBeta版らしく、動作が重たいです。 重たかったので、ちゃんと試せていないです… Circle CI Android、iOS共にビルドできそうだったけれど、iOSをビルドしようとすると以下のような文言が表示されました。まだBetaなので、気長に待つことが必要そう。 Warning: Sorry! Your build didn’t run because we are still adding capacity to the iOS beta and haven’t enabled your organization yet. We know…More
2014年もあとわずかですが振り返る
ギリギリですが、2014年を振り返ります。 今年1年で一番大きかったのは、転職です。 中途、しかも社内では1人目の専門職ということで、その専門性を持つエンジニアとして成果をどれだけ出せるかがガチな問題でした。そのため、社内で成果を出すことに一番力を注いだ年だったと思います。 やったこと 仕事 転職しました。年明けて少したったらちょど1年 同僚らにまだ入社して1年満たないことに驚かれるほどには馴染んだ模様 モバイルアプリ開発関連のテストエンジニアとして成果を出せた気がする 少なくとも、組織として安定したリリースサイクルを回せるようになった 外部活動 JaSST 14 Hokkaidoで発表しました 第2回 日本Seleniumユーザーコミュニティ勉強会で登壇しました WACATE 2014 冬に参加しました 専門性 テストエンジニアとして、100%力を注ぎ込む環境に身を置くことができました 今まで読んできた書籍などが血肉になった プライベート ブログ、年間で100投稿超えました 文字としてアウトプットすることを私の中で気軽なものにするために取り組んでみましたが、思いの外続けることができました 次はブログの質に気を配りたい 技術書など含め、平均して月に2〜3冊は読めた気がする 小説、漫画などはのぞく やりたいこと 仕事 Rails(Ruby)、iOS、Androidのそれぞれのテストコード読んでレビューできるようになりたい モバイルアプリで使っているツールをほかの人も手軽に使えるように、広める段階に持っていきたい テストの考え方を社内でアプトプットしていきたい 外部活動 JaSST 15 Tokyoのパネリストとしての役割を果たしたい Appiumなどの、モバイルアプリ開発に関わるテスト関連の知識を共有するコミュニティを促進したい 自動化研究会にお声掛け頂けたので、日程あえば足を運んでみたい 専門性 書籍の量は落として、写経などのテストコードと遊びたい(質をあげたい) Android or iOS or Web Appで何かちゃんとゼロから開発してみよう サンプルコード触ってみました、操作してみました、ではなく プライベート コンサートやミュージカルなどにいきたい 旅行(海外?)行こうと言われているのでいきたい 締め 最近、忘年会などで同僚から聞かれるようになりました。 なんでサービス開発側ではなくテストエンジニアとして活動しているの？ 普段の活動の中で、コード読んだり、書いたりしています。Productivity向上を専門とするエンジニアと言われるような領域の活動とも重なっている領域の活動もしています。そういうことを行うテストエンジニアとの交流が同僚の経験上少ないらしく、こういう質問を聞かれているようです。 就職時は将来のキャリアを考えたり、転職時も同じように考えていました。一方で、転職してからはキャリア以外のところでもテストエンジニアとして活動するところで良さを感じました。アプリ開発などを行ってもテストエンジニアから完全に外れることはないかなと思います。…More
WACATE 2014 冬に参加してきた
最近常々思うのですが、テストエンジニアも役割が細分化されて、役割が再定義される時代がすぐそこそうですね。開発者が、xxx(特定の言語)エンジニア、サービス開発エンジニア、インフラエンジニアなどのように区分して呼ばれるように。例えば、最近、テスト自動化エンジニアと呼ばれる人たちが出てきましたが、それもその一つだと思います。 さて、話題は変わり、12/6、12/7の2日間で開催されたWACATE 2014 冬に参加してきたのでその話をまとめます。1ヶ月くらい経ちましたが、ようやっとブログポストになります。。。Twitterにおけるハッシュタグは #wacate だそうです。 WACATEとは WACATEは「Workshop for Accelerating CApable Testing Engineers」の略で、「内に秘めた可能性を持つテストエンジニアたちを加速させるためのワークショップ」という意味です。 前々から日程が合えば参加してみたいと思っていたのですが、日程が合わず今回初参加。初参加ながらも、分科会をさせていただきました。 ここでふと疑問に思うのが、若手の定義です。こちらのCIAの資料によると、日本の平均年齢は46.1歳のようです。そこから考えると、30代までが若者といっても良さそうな範囲ですね。 なお、WACATEとはによると 35歳以下 だそうです。More
デザイニング・マルチデバイス・エクスペリエンスを読んで
「われわれはまったく新しい状況に直面すると、つねに、もっとも近い過去の事物とか特色に執着しがちである。われわれはバックミラーを通して現代を見ている。われわれは未来に向かって、後ろ向きに進んでゆく by Marshall McLuhan, “The Medium Is the Massage” 最近発売された、デザイニング・マルチデバイス・エクスペリエンス ―デバイスの枠を超えるUXデザインの探求を読みました。モバイルアプリを含む、サービス開発に関わっている人におすすめできる本です。自分たちでマルチデバイスを対象にサービスを開発、世に提供している人たちは、昨今の端末の多様性に対する話の整理とユーザ体験の整理ができると思います。実例が非常に豊富で、マルチデバイス環境下における自分たちのサービス/アプリを考えさせられると思います。 今勤めている企業と私の今の役割からいうと、社内のモバイルアプリに横断的に関わっていて、それらをリリース前に少なからず触れるという立ち位置にいます。もしかすると、社内では機能的に一番多くのモバイルアプリに触れているかもしれないです。今まではそのプラットフォームに対してや、デザイナさん、プロジェクトの人が持つ芯に沿って関わっていましたが、そこから一歩進んで関わることができるかも。機能的なテストで終われないですよね。 いろいろ書かれていたのですが、何が重要か？に関しては、よく聞くけれど以下をしっかり考え取り組むことが重要だと言っています。 ユーザのニーズやゴールは何か？ メインフロー、及び利用のコンテキストは何か？ デザインアプローチは最適か？ 使用されるデバイスは何か？ コンテキストを満足できるか？ 以下、かいつまんでまとめを。この本は事例が豊富なところがとても良いので、ざっと読んでみることをお勧めします。1日ないし、半日あれば読み終わることできます。More
Objc #15 Testingを読んで
ワザノバの記事で知ったのですが、iOSに特化して、特定のテーマごとに発信しているブログを覗いてみました。 その中に、Testingに話題を絞って話している回があり、面白かったのでまとめてみます。 Issue #15 Testing Behavior-Driven Development What Should I Test?という問いかけから始まり、BDD DLSの話、BDDフレームワークを使いながら、BDDに関して説明している記事。以下の流れで実際にBDDフレームワークを使って、Behaviourとしてテストを記述するとこうなる、という事例を提示しています。 BDDフレームワークとその特徴を簡単に説明 機能に対するテストの記述 ただし、これはユーザから見ると何もテスト対象がどのように振る舞うのか書いていない、と指摘。 どのような要素が表示され、それをどうするとどうなる、というような記述に説明を加えながら発展 View Controllersのテストの具体例まで表示 締め 記事の中で、BDDのフレームワークとして以下を紹介。KiwiとQuickしか頭に入っていなかった… Objective-C時代のBDDフレームワークとしては以下。 Cedar Kiwi Specta Pure Swiftで開発されているフレームワーク Quick Sleipnir SleipnirはCedarに、QuickはSpectaに影響を受けているらしいです。個人的に、Sleipnirには興味が湧きました。というのも、XCTestを使っていないらしいです。実際に試して、どこまでできるのかを図らないとなんとも言えないのですが、XCTestに縛られず、どういう風にBDDとしてテストを実施するのかに興味があります。試してみよう。 Core principles • Sleipnir is not dependent of NSObject, it is pure Swift BDD testing framework • Sleipnir is not using XCTest • Sleipnir has nice…More
