サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
デスク環境を整える
kazucocoa.wordpress.com
少し前に米国で就労するためのO1ビザを取得しました。友人の何人かに内容を聞かれたことと、日本語による米国ビザ取得の話もあまりない為、ここに少し内容を残しておきます。どなたかの、今後の手助けになればと思います。 私はいくつかのきっかけが重なり、1年ほど前からある米国スタートアップでSenior Software Engineerとして働き始めました。米国における就労はビザの都合上できないため、ずっと日本の自宅から働いています。就労ビザ取得までには1年程度かかったことになります。流れとしてはH1への申請、その抽選に漏れてからのO1申請という形です。 ここでは、そのスタートアップで就労しはじめてO1ビザ取得までの全体の流れを残しておきます。O1ビザの取得にはUSCISが要件を出しています。この要件は見せ方など含めて移民弁護士との調整に依存することも多いので、ここではいくつか私の例に触れる程度にし
単に、どんなにうまく運営されている組織でも、影響の大きな意思決定のうち相当の数が、後になって間違っていたと判明することになるという事実を認めることである。 これが否応のない人生の現実である 。 『ソフトウェアの欠陥予防 テストより確実な品質改善法』を読んだであったような欠陥分析をする上で、人は一定確率で失敗するという大事な前提があります。一方で、それはどれほどなのか、経験的なものではなくちゃんと研究としてどこまでされているのか気になっていました。 そんな中、『ヒューマンエラー 完訳版』を見つけたので読みました。そのメモなどをつらつら。 ソフトウェアは人工物です。そのため、ソフトウェア開発は人の組織や認知と如何に関わるかというところが大事な要素を占めてきます。(ソフトウェアテストを学んでいると多くの人は行き着くことな気もしますね) この本では、主に原子力発電という安全性が最重要とされる情報を
Selenium/Appium Advent Calendar 2018、4日目の記事です。 1 日目の 2018 年の Selenium と Appium について、なるべく他の人とかぶらないことに言及するテスト でも言及いただいたのですが、ちょうどこの 12 月より HeadSpin にて活動をはじめました。現状はまだ日本に滞在しています。 今、私は Appium project をメンテしています。その中で感じたここ最近の 普通 になったなということに並列実行(parallel execution)があります。 Appium の公式ドキュメントでも parallel-tests にある通り、その実行方法に関して言及しています。人によっては Selenium Grid を介していたりもします。その中で大事なものは、Appium の各種 Driver と通信できるように、ポートの設定とテ
主にはモバイルアプリのクラッシュログなどのログ管理に関して、最近の流れを知りたいと思いいろいろ物色してみました。類似サービスとしてはCrashlyticsなんかがありますが、いろいろ使っていると機能的に柔軟性が足りなかったりして目的に沿った利用ができないことが増えてきて、他に手頃なサービスあるのかなと思ったことも要因です。 Crashlytics以外にもいくつか調べた中で、最終的に良さそうと思ったのはBugsnag。 Bugsnagは以前どこかで見たか聞いたことあったのですが、そのときはCrashlyticsのように整ったGUIがある方が使い勝手が良かったのでそこまで調べてませんでした。一方、最近ではGitHubとの連携など、サービス間の連携に対して価値を置くようになりました。そのため、ここでちょっとちゃんと使おうと思って使ってみることにしました。 Bugsnagが良かったところ 多くのプ
『すごいErlang ゆかいに学ぼう』を読みました。すごいE本、Elixir学んでいると必然的に？いきつく先ですね。C++学ぶためにCを学ぶ、みたいな。 Programming Elixir、Elixir in Actionを事前に読んでいたので、内容の大半は頭の整理のためにさらっと読んだくらいでした。その中で、最後付近のCommon Testとかは目新しいものでした。王道としては、Programming Elixir + すごいE本、でしょうか。 ※すごいE本、もとはこのURLのもの？: http://www.ymotongpoo.com/works/lyse-ja/ 学習曲線 Elixir/Erlangの学習度合いがどのくらいかな、と思って残してみました。ここまでくるのにざっと平均して 3ヶ月 x 1h/day くらいかなーという個人的な感想です。この間に写経やら、ちょっとしたライブラ
過去、 EarlGreyが出たての頃に試してみた のですが、最近またプライベートで使ってみたので自身のために残しておきます。 対象のproject: https://github.com/KazuCocoa/MyGithubSearch 対応コミット: https://github.com/KazuCocoa/MyGithubSearch/commit/bd83bf8668260978ec6941bd8c003470c9443167 幾つかサンプルではなくて自分で使ってみて、Appiumとの使い分けやテストレベルの対応などもある程度私の中で腑に落ちた感じがしました。 EarlGreyについて EarlGreyは、XCUITestみたいに描画要素に対して何らかの操作を行うライブラリです。面白いのは、 UIView をハックしてなにか操作を模倣するのではなく、 UIAccessibility
ちょっとしたWebサイトを作ろうとして、Elixirを最近触っていることもあってElixir x Phoenixで構築し始めている最近です。 その中で簡単なログイン機能を追加しようとしたところ、awesome-elixirにてGuardianなる開発途中の認証ライブラリを見つけました。開発者はRack Authenticationのwardenの開発者でもあるのですね。ほー。 試したのは、v0.5.0 Readmeを見ながら作業かなーと思っていたのですが、サンプル実装を公開していることを知り、まずはそこから動かしてみることにしました。 ただ、動かしてみるとPhoenixが0.13.1ベース。 私が今使っているのは0.15.0ベース。 …. ということで、サンプルをPhoenix 0.13.1ベースから0.15.0ベースに書き換えました。開発者の方へPRも投げたので、もしかするとマージされる
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ベースのアーキテクチャとして大事な要素 C
最近、Jupyterを知りました。 Python/Rubyで学んだのですが、Elixirでもあるか探してみたらありました。(なかったら作ってみようとしてた) 使い方は簡単で、Readmeに書いている通りにするだけです。 Jupyter https://jupyter-notebook.readthedocs.org/en/stable/index.html https://github.com/jupyter IElixir https://github.com/pprzetacznik/IElixir IErlang https://github.com/robbielynch/ierlang そのほか、利用可能なKernelは以下 https://github.com/ipython/ipython/wiki/IPython%20kernels%20for%20other%20lang
ちょろっとしたお遊び程度ですが、Supervisorによって管理されているプロセスをkillしたりしてプロセスをみてみました。書籍には載っているのですが、特に何も見ずにお遊び程度にサラでやってみたのでそのメモ、みたいな感じです。 初めに… 空のsupervisorプロジェクトを作ります。 $ mix new SupervisorTest --sup $ cd SupervisorTest $ mkdir lib/supervisor_test $vim lib/supervisor_test/neko_supervisor.ex defmodule SupervisorTest.Neko do use GenServer def start_link(opts) do {_, name} = opts GenServer.start_link(__MODULE__, :ok, [name:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
HerokuがErlang製のHTTP Proxyを公開しましたね。少し中身見てみたのですが、彼らもForkしたCowboyを使ってProxyを構築しているっぽい。他にも軽く読んでは見たのですが、Erlangも多少読めるようになっててびっくり。 https://github.com/heroku/vegur 話は少し変わって、[Elixir]Elixirで簡単なHTTP Proxyを書いているときに出会ったエラーのメモで、Supervisorのworkerごとに異なるportを待ち受けてそれぞれが独立したproxyとして動作する機構を書いてたのですが、PIDの衝突の発生で思った感じでできてませんでした。 でも、考えるほどにやっぱりできるはずだよなーと思いもう少しやってみました。それと、先ほどのVegurでもやっぱり異なるPortで待ち受ける処理が書いてあって、やっぱり実装間違ってるなと確信
追記 2015/11/08 [Elixir]1worker、1portでリクエストを待ってHTTPのリクエストをProxyする で解消済 最近、簡単なHTTP Proxyを書いてみています。Elixir/Erlangの多プロセスで動作する点を利用して、軽量なproxyとして動作できるのかなー？というところがあってです。 https://github.com/KazuCocoa/http_proxy 以下のような感じでportを指定したら、そのportに対してどんなパスでアクセスしたかで接続先を制御できる感じにしています。 use Mix.Config config :http_proxy, proxy: %{port: 4000, default_to: "http://google.com", path: [ %{from: "", to: "http://yahoo.com"}, %{
ここら辺がこの書籍の真骨頂でしょうか。 Chapter11ではよく知られたOTP applicationを作るためのファイル構成とか、書き方な話なのですっ飛ばして、Chapter12のメモ。 ざっと読んで、触った感覚としては、分散システムは無知では手を出さないほうが良いかなーということ。色々考慮漏れで溢れそうな予感… Erlangベースのシステムでは、processとmessageによって分散システムを構成します。(伝統的なRPCと混同しないように) BEAMによる分散システムは、複数のnodeがそれぞれ接続されてクラスタ化されることで実現されます。このnodeは、BEAMインスタンスと呼ばれます。 Nodeの接続 以下のようにして、簡単なnodeを立てて接続、クラスタを組むことができます。 node1 $ iex --sname node1@localhost iex(node1@loc
PhoenixのPlugの説明を読んでいると、Plug自体の動きが少し気になったので読んでみました。 ここでは、以下の Hello World を追ってみることに。 https://github.com/elixir-lang/plug API Document: http://hexdocs.pm/plug/ Plug自体、簡単なWebサーバの機構を提供するものですね。 ひとまず、 iex> {:ok, _} = Plug.Adapters.Cowboy.http MyPlug, [] {:ok, #PID<...>} を実行してみる。 まずは以下が呼ばれる。 https://github.com/elixir-lang/plug/blob/master/lib/plug/adapters/cowboy.ex#L41 @spec http(module(), Keyword.t, Key
ElixirによるRoR実装と表現される、Phoenix Frameworkの作者による書籍『Programming Phoenix』を読んでみました。今はドラフト版ですが、こういうフレームワークの基本的な思想とか好きなのと、PhoenixはElixirのmacroを駆使しているという話をみて、気になって買って読んでみました。(Elixir、macroがほぼそのままLips形式の記述なのですが、そこも著者は気に入っているそう。) 以下ではElixir 1.1.0、Phoenix 1.0.3を対象としてます。 内容としては、簡単なサンプルを作りながらPhoenixの話、Ecto、Plug.Conn、Ecto.QueryなどのElixirの基礎要素の話がありました。テストの話なんかはまだ書きかけ。Phoenixの話ばかりと思ってたら、結構Elixirの周辺の機構の主要な要素をかいつまんでいて、
以前、FitNesseなどによるSpecification By Exampleで少し示した keyword driven testingは、入力値とその操作まで変数としてテストコードに与えることができていました。 このような形式で記述するテストは、「テストしたい対象のメソッドの入力とその期待値が異なる組み合わでいくつも存在するが、それらのテストを可読性の高い状態、簡潔な表現で保ちたい」というような場合に使えます。実際、開発速度が速い場合、仕様書を別ドキュメントとして厚く保つことは難しいと思います。その対策として、可読性の高いテストで低レベル（メソッドの入出力レベル）のテストはテストを仕様書に見立てていく、というアプローチが重要な一手となります。 以下は、パラメタライズドテストと呼ばれます。rspec-parameterized’というgemを使ってます。 検証コード class Calc
ちょっと追えていなかったのですがEspresso関連のライブラリが2.1が2015年4月21日に、2.2が2015年5月28日にリリースされたのですね。 ちょっと順に追ってみます。 android-test-kit release note 内容としては、2.0=>2.1では破壊的な変更が発生したので移行時には注意しましょう、でしょうか。ただ、 ActivityInstrumentationTestCase2 を脱却して、 @Rule ベースでアクティビティの起動/終了が管理されるようになったので、個人的には移行をためらう理由もなく、という感じですね。 そのほか、intentなんかも含め、JUnit4らしく？Ruleベースのテストの周辺環境記述に移り変わってきた感じがします。 from 2.0 to 2.1 com.android.support.test:testing-support-
2015年7月10日、納豆の日のときの話になります。納豆食べてないな。。 軽いまとめ Google Cloud Test Labsの、 Out of the box, without any user-written tests, robot app crawlers know just what to look out for and will find crashes in your app for you. が他に比べて優位性を高く持っている感じ 他サービスは昔からある、テストシナリオ与えたりするとそれを実行、レポートを得られるサービス テストシナリオをメンテできる人でないと運用は難しそう 最近、GoogleやAWSから実機テストに関するツールの発表がありましたね。勢いあるなーってことで、ああいった方面の、昔からあるものなんかを並べてみました。 こういうサービス、TaaS(Test
少し前から、モバイルアプリケーションに対してHermetic testと呼ばれる類のテストタイプを実施できる環境を整え始めました。その中で、JSONで記述したHTTPレスポンスを返すだけのような、簡単なMockServerを探していました。 なければ簡単なものを作ろうとも思ったのですが、結構期待していたものがあったので、メモ。 調べたもの MockServer WireMock mockwebserver OCMock あたり。他にもありましたが、ざっと見て次〜としていた。 求めたもの Android/iOSに特化しない、共通で使えそうなMockサーバ JSONのような可読性のあるテキストでテストデータ(HTTP Request & Response)を管理できる Stand Aloneで動作し、設定ファイルとそのMockサーバアプリが手に入れば誰でも環境を構築できる 複数のライブラリをダ
Testing Strategies In A Microservice Architectureを読んだを読んでいる途中に出てきた、Circuit Breakerと呼ばれる機構を調べてみました。Martin Fowler氏がこの記事で言及しているものでした。 このCircuit Breaker patternは、Release It! 本番用ソフトウェア製品の設計とデプロイのためにで描かれているような、本番環境化において発生する、複数システムが関係するからこそ発生する障害を抑えることも目的としたデザインパターンのようです。「複数システムが関係するからこそ発生する障害」とは、一部システムの負荷が高まりタイムアウトするといったことを含みます。 内容自体は、 障害検出のための共有のオブジェクト(Circuit Breacker)を用意して、監視・検出できるようにする ということらしいです。Ne
はじめに LEANやAgile、BDDやATDDなどとあわせて、Specification by Exampleという、包括的な考え方が広まってきました。 これは、例によって振る舞い（仕様）を定めていく、という形のアプローチになりますが、そのときによく使われるツールが着想として面白い。 仕様としての例をWikiにより管理し、実装対象の例えばAPIに対してインプット、アウトプットを定義する。そしてそれを受け入れ試験の1つとして活用する。 これは、自然言語で例を与えながら仕様を明確にしていくことと、Wiki形式で表現することで理解しやすい形式にすること、開発物のインタフェースの検証のテストとして受け入れテストのインプット・アウトプットの検証にそのままWikiの記述が使われるところが有用です。 つまるとこ、仕様がそのまま受け入れ基準になるため、仕様と実際のインターフェースの振る舞いの差分を小さく
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 アプリの実装寄りの話はこの記事が参考になりそう 消費
Dependency Injectionの、Dagger1とDagger2を学んで、DIの理解を深めてみる。Tasting Dagger 2 on Androidを参考にしました。 Dagger1はGuiceに影響を受けている。特徴は以下。Compile time injection。 Multiple injection points: dependencies, being injected. Multiple bindings: dependencies, being provided. Multiple modules: a collection of bindings that implement a feature. Multiple object graphs: a collection of modules that implement a scope. Dagger2はA
android-test-kitの理解を深めようと、以下を眺めていました。 https://code.google.com/p/android-test-kit/wiki/AndroidJUnitRunnerUserGuide この中で、JUnit4の枠組みの中でContextを取得するためのInstrumentationRegistryがどのように振る舞うのか気になったので少し追ってみました。 InstrumentationRegistry is an exposed registry instance that holds a reference to the instrumentation running in the process and it’s arguments and allows injection of the following instances: Android
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 clas
少し前に、雑にモバイルアプリのリリースサイクル毎で行っているテストの流れという記事を書きました。 考え方が少し変わったりしているのですが、そこからE2Eテストという枠を抜き出して、さらにはテスト自動化という文脈で少し話を整理してみようと思います。 ここでは、効率的なコード、失敗時の解析の容易さなどに対する言及は致しません。また、サーバ側に対するテストの話にはちゃんとは触れません。 E2Eテストに含まれる目的 モバイルアプリにおけるE2Eテストという言葉には、恐らく以下の目的(と雑なテストタイプ)が含まれていることが多いと思います。 アプリのGUIから操作した (もしくは表示される要素に対して直接操作した)という文脈を持ったうえでの、 シナリオテスト 想定したStoryやFeatureを含んだシナリオを用意し、そのシナリオを達成できるかを検証したい 機能テスト(システム全体) サーバ側機能を
次のページ
このページを最初にブックマークしてみませんか？
『~ my tech diary ~』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
