[app]fuse

ちょうど、 https://www.fusetools.com/ というツールを見つけたので触ってみた。

期待としては、やっぱり簡単にアプリの雛形を作ることができ、その雛形を参考にAndroid/iOSの各プラットフォームでプロダクトを開発することができる状態でしょうか。

少し触った感じ、previewがうまく動かなかった…
マシンスペックも関係するのか。。。
まだBetaなので、もう少ししたらまた触ってみよう。

こういうのを試してみようとした。
https://www.fusetools.com/examples/circle-menu

[Elixir]Registerを覗く

key-value processとしてElixir1.4に入れる予定の Register というものが公開されました。

付属のベンチマークによると、以下のように高い性能が出ていることがわかります。

このベンチマークの内容は以下

https://github.com/elixir-lang/registry/blob/master/bench/shared.exs

プロセスを起動して、登録して。それを10000回登録する間の時間を計測しているみたいですね。
各ベンチマークの最後で登録した名前をチェックして、その欠損がないことを確認して終わり、と。

register/3 周りは以下

https://github.com/elixir-lang/registry/blob/master/lib/registry.ex#L535

ここら辺を見て回ると、 :ets テーブルを複数に分割(sharding)しているぽい。
同じようなことをしているものがあるのかなと調べてみると、以下のライブラリがすでに。

https://github.com/cabol/shards
https://github.com/cabol/exshards

プロセスを気軽に使えるように便利機能を拡充していく、という感じですかね。


おまけ

テストコード、繰り返しには以下のように fordescribetest を囲むことができるのですね。こう言う書き方もあるのねーという学びでした。

https://github.com/elixir-lang/registry/blob/master/test/registry_test.exs

[Elixir]diff of struct against elixir 1.2.6 and 1.3.1

pattern match with struct

  • Structでもpattern matchingすることができる
    • [Kernel] Allow variable struct names when matching, for example, %module{key: “value”} = struct

__struct__

__struct__ が補完候補に出てこない。けれど、使うことは可能。

  • Elixir 1.2.6
iex(1)> Version.
InvalidRequirementError    InvalidVersionError
Parser                     Requirement
__struct__/0               compare/2
match?/2                   parse/1
  • Elixir 1.3.1
iex(1)> Version.
InvalidRequirementError    InvalidVersionError
Parser                     Requirement
compare/2                  compile_requirement/1
match?/2                   match?/3
parse!/1                   parse/1
parse_requirement/1

ただし、Elixir1.3.1でも、

iex(1)> Version.__struct__
%Inspect.Error{message: "got Protocol.UndefinedError with message \"protocol Enumerable not implemented for nil\" while inspecting %{__struct__: Version, build: nil, major: nil, minor: nil, patch: nil, pre: nil}"}
iex(1)> %Version{}
%Inspect.Error{message: "got Protocol.UndefinedError with message \"protocol Enumerable not implemented for nil\" while inspecting %{__struct__: Version, build: nil, major: nil, minor: nil, patch: nil, pre: nil}"}

と使うことは可能。

[iOS]EarlGreyを使ってシナリオを記述する

過去、 EarlGreyが出たての頃に試してみた のですが、最近またプライベートで使ってみたので自身のために残しておきます。

幾つかサンプルではなくて自分で使ってみて、Appiumとの使い分けやテストレベルの対応などもある程度私の中で腑に落ちた感じがしました。

EarlGreyについて

EarlGreyは、XCUITestみたいに描画要素に対して何らかの操作を行うライブラリです。面白いのは、 UIView をハックしてなにか操作を模倣するのではなく、 UIAccessibility Protocolを操作する。

リポジトリはこちら。

https://github.com/google/EarlGrey

EarlGrey自体の説明はあるのでここでは書きません。

何か困った時

使えるAPIや、使い方がわからないとか、そういう時はテストコード読んだりAPIドキュメント見るとある程度対応できます。

  • APIドキュメント
  • Matcherの実装
    – どのように動作しているか、といった説明も書かれているので、ざっと一読することをお勧めします
    https://github.com/google/EarlGrey/blob/master/EarlGrey/Matcher/GREYMatchers.h
    – AccessibilytLabelやidentifierの他にも、Valueなど多くの要素が使えるのよいですね
    – ただ、 We strongly recommend using an accessibility identifier as it uniquely identifies an element. と書かれているように、やぱり accessibilityIdentifier を使うことが良いことには変わりなさそう。ここは激しく同意。

Other Tips

  • 要素を見つけたい時
    • シミュレータだと、AccessibilityのAccessibility Inspectorを有効にしてそれを使うと良いです
    • Appiumだとinspectorを使ったりPonyDebugger使ってたのですが、このAccessibility Inspectorが実は一番楽なのかも?
  • Search Fieldなどで”Search”をしたい(テキスト入力後の決定)
    • \ngrey_typeText で入力しましょう。そこを契機にkeyboardの”return”や”search”になる箇所の操作と同じ動作をします

シナリオの記述例

以下、Searchフィールドをたっぷ、”KazuCocoa”と入力して決定、検索するというシナリオです。

  • selectElementWithMatcher で要素を見つけ、 performAction で何か操作をし、 assertWithMatcher で要素をチェックする。
  • EspressoのViewMatcher、Perform、Assertの形と同じですね。Googleではこういう形での記述に統一しているような雰囲気を得ます。

具体的には以下。

Appiumとの使い分け

ざっくりと書くと、ツールの使い分けは以下な感じ。Quickなどはありますが、やはりSwiftでシナリオベースのテストコードを書くのは面倒です。なので、本当にその視点から記述したシナリオベースのテストを残しておきたいなら、私はAppium + Rubyをベースにしたものをつかたいと思います。

  • Appiumを使うとき
    • シナリオを記述したテストコードの実行
    • ネットワークキャプチャなどのアプリ全体を操作したい時
  • EarlGreyを使いたい
    • CIに組み込む
    • 限定的な操作を安定して早く実施したい
      • イメージとしては、単一の機能であったり、境界値によってViewが変化するような隅っこのチェック
    • Layoutをチェックしたい(image diffではない)

image diffなんかは単なるassertionの手段なので、必要に応じて使いましょう。

こういうのを、社内で置いているテストレベルと照らし合わせながら導入できると雑多にはならなさそうですね。

XCTest -> EarlGrey -> Appium

という感じで、ロジックのチェックからGUIのチェック、アプリ全体の計測まで進んでいくと順当そう。
ちょうど、テストサイズをベースにするとS/M付近がXCTest、M/L付近がEarlGrey、L/EがAppiumという感じの関係性でしょうか。

締め

あまり情報がないですが、やはり短時間で成果を出すにはこの手のテストコードも素早く安定させた形にすることが必要です。その上で、この手ではできないことを人が実施する。

そのためにはこういうツールやテストの構築方法含め、フルで知見を導入していきたいですね。

Reading “Raft” – consensus algorithm

Raftという、合意アルゴリズムが存在する。これは、多数決を元にした多数派の意見を決定するためのアルゴリズムで、分散環境下における合意形成でも使える。最近、分散系の幾つかのWebサイトを眺めていると見つけた。

私は、こういう系統の技術分野は大学院の頃にByzantine General Problemを扱ってから比較的興味を持っている。

実際のツールだと、CoreOSのetcdやhashicopeのconsulなんかで使われているみたい。

Raft自体に関係するところは以下。

幾つかの言語で実装されているみたい。etcdではgolangぽい。

幾つかRaftの論文のreferencesを見てみましたが、Byzantine faultなんかはやぱり参考にされていました。2014年が論文としては初出?

LESLIE LAMPORT氏によるByzantine General Problemの問題は、懐かしさがある(大学院の頃によく読んでいた)。最近はご無沙汰だけれど、技術だけの話でいうとこれ系が関わる仕事はしてみたいな。

参考

[Elixir][Erlang]difference of binary

double quote and single quote have different meanings between Elixir and Erlang. In addition, “$” and “?” also have.

They make me confuse a bit … 😦

[Elixir]愚直にズンドコキヨシ

こちらの「ズンドコキヨシ」を簡単に実装してみた。Streamとか、そういうのは使ってない。実際に処理するメソッド数は3つ。 Enum.take/2 のようなものは使っていない。

実行

iex> c "zndc.exs"
iex> Znd.kiyoshi
"ズンズンズンズンドコキ・ヨ・シ"

Listの追加方法を先頭から追加する形に少し変更してみた。ついでにdropしてた所を出力してみた。ただ、少しに煩雑になったかな…