[Android]Dive into Toothpick

過去の調査に加えて、Toothpickに潜ってみました。 簡単なまとめ @inject アノテーションが付いている要素を、 scope.getInstance(); したクラスでinjectionして利用することができる。 inject可能な要素は木構造で表現され、親scopeに含まれる要素をinjectしたメソッド/クラスとして利用することができる scope外の要素を使おうとするとクラッシュ bind(IFoo.class).to(Foo.class) で Foo.class を使い回すことができるし、 bind(IFoo.class).to(new Foo()) では都度新しいinstanceを生成して利用可能 ActivityやFragmentといったライフサイクルに対して Toothpick.openScopes(getApplication(), this) してscopeを設定した場合、そのライフサイクルの onDestroy のタイミングでそのscopeをcloseする必要がある Scopeはアノテーションベースでも独自で設定できる 導入 ライブラリとして利用するための導入は こちらのWiki に任せて省略。 例えば、以下のFooクラスに対してinjectしようとします。 この時、scope.getInstance(Foo.class) したら、そのクラス内でこの Foo.class でinjectされている Foo、Bar、setQurtz を @Inject で指定して使い回すことが可能となります。 ついでに bind に関して少し触れておきます。以下のようにbindすると、 それぞれのケースにおいて以下のようになります。 case1 では、すでにFoo.class のインスタンスが存在するならそれを使い、それをIFoo.classに紐付ける case2 では、常に新たな Foo.class のインスタンスを使い、それをIFoo.classに紐付ける Scopeの種類 Scopeの種類としては2つ存在します。 a binding 都度、bindされるたびに新しいインスタンスとして利用される 子要素では親要素を上書き可能 bind(IFoo.class).to(Foo.class); みたいな感じで都度bindされるやつです scoped…More

[Elixir](UndefinedFunctionError) function List.Chars.to_charlist/1 is undefined or private with Elixir 1.3.0

https://github.com/elixir-lang/elixir/releases/tag/v1.3.0-rc.0 Elixir 1.3.0では to_char_list がsoft deprecatedになり、 to_charlist にリネームされました。 そのため、例えばelixir 1.2.x以前でビルドしていたバイナリが存在している状態で 1.3.0 で 再ビルドなし でコマンドを実行した場合、エラーが発生します。 例えば、 Doctest の場合、以下のようなエラーが表示されました。 これを解決するには、 _build を削除して再ビルドすればOK。この逆もありました。注意が必要ですね。 あと、もう1つ。ExUnitに標準で describe/2 が入ったことは良いですね。1段のコンテキストの分離はだいぶグルーピングに使えそう。 shouldi を使わなくても良くなりそうです。 注意が必要。More

[Android]ToothpickでTree Based DI

最近、Tree Based DIツールのToothpickを知りました。 https://github.com/stephanenicolas/toothpick このメンテナは、RoboGuiceをメンテしていたGrouponの人です。RoboGuiceの更新を見に行った時にたまたま見つけました。ここ数ヶ月で作り上げられたDIライブラリのようです。このリポジトリWikiのあるページに、AndroidにおけるDIの歴史や経験をまるっと学ぶことができて良かったです。 https://github.com/stephanenicolas/toothpick/wiki/FAQ#why-creating-toothpick- さらには、彼らがRoboguiceからDagger1/2と触れた上でこのToothpickを作るに至った流れも書いています。 まだWikiと簡易サンプルをさっと眺めた程度なのですが、備忘録がてら。 AndroidでToothpick Toothpick自体はJavaのTree Based DIです。これ単体ではAndroidはサポートしていません。Androidをサポートするために、smootheがあります。 このサンプルにあるように、Toothpickはsmoothieを介してAndroidにDIを提供します。 幾つかのDIツールとの速度比較 Roboguice4/Dagger1/Dagger2/Toothpickのinjectionするメソッドの個数による速度差が以下の通り。 https://github.com/stephanenicolas/toothpick/wiki/Benchmark#benchmark-raw-data Androidの環境でいうと、injectionするメソッド数が1000個超えるとかな大規模なものになることはまだそこまで多くはないはずなので、速度としては申し分ないのではないでしょうか。 初期設定では一部reflectionを使っている 以下の通り、default設定ではfactoriesの読み込みやmember injectorsを読み込むにあたりreflectionを使っているらしいです。 https://github.com/stephanenicolas/toothpick/wiki/Configurations ただ、このreflectionはOFFにすることができるそうな。そのためには以下の通りToothpickを使う時に reflectionFree の設定を与える必要があるとのこと。これにより、完全にToothpickはreflectionなく動作し、高速になると。 ベンチマークはこちら => ★ 確かに、reflectionの有無で何倍も速度差がでますね。ここら辺の積み重ねで性能差が大きく出てきそうな。 scopeにより意図しないクラッシュを避ける Scopeという概念を入れることで、Scopeに属さないfragmentなんかを意図せず読んだ時にクラッシュする、というような不用意なinjectionを回避できるようにしているそうな。ここはまだこのツールの中身を追ってはいないのでなるほどなという感じ。 あと、ここなんかでは、メモリリークに対するこのツールの見解といったところも記述されています。 締め まだざっとWikiなんかを眺めただけで中身を追ってはいないのですが、tree based DIが、学習コストがあまり高くなくとも比較的容易に使えるライブラリなのであれば結構有力なDIの選択肢になるのではないかなと感じています。個人的には、toothpickにはテストコード向けの機能も提供しているので、テストコード書くにあたってもかきやすいものであればなお嬉しいなという感じです。シンプルにinjectionするモジュールの関係性や使い方を理解して使えるのであれば、内部品質向上へ大きく寄与するし、テストコードを描きやすいのであればクラッシュや機能不全などの外部品質の担保にも寄与できると期待できるためです。 ちなみに、過去、私はDagger2を学んでいました。このBlogの過去のDagger2関係 => 検索 その中でDagger2を使ってテストコードのDIによるテストも書きはしたのですが、そんなに簡単に書けた!というほどでもなかった記憶が。。。 ともあれ、Dagger2と同じくらいには使い方などを追ってみようと思っています。(少し気長に…)More

[Android]codelabsがいろいろ参考になる

最近、Googleのcodelabsを覗きながらGoogleIOであった新しめなツールの把握をしています。 https://codelabs.developers.google.com/ どのくらい時間かかりそうかも書いているし、実際経験したことある人だと表示されている時間ほどチュートリアルにも時間がかからないので効率的にざっとした内容は把握できそうな気がします。 ConstraintLayout ConstraintLayoutを試してみました。 こちら AppleのStoryBoard上でAutoLayoutを操作する感じで使えますね。 サンプルを基に、自分で少しやってみました。 https://github.com/KazuCocoa/myconstraintlayout XMLは微調整をする時以外見なくてよさそうな感じまでなると良いですね。古くからAndroidアプリ開発されている方はXMLとの対話の方がまだ効率的なのかな。 Android Testing Codelab こちら これはオマケみたいなものです。 Espressoを使ったサンプルと、MVCの説明ですね。Activityへの依存性を少なくしてテスト可能な範囲を広げるとか、interfaceを定義してその実装をstub/mockするやり方とか、そこらへんの導入が書いています。 Espresso-contrib はRecyclerViewに対して使えるメソッドを提供していたのは知ってたのですが、 DrawerActions や DrawerMatchers に対してもそうであったのですね。ここは知らなかった… (と思ったら、ATSLのページには書かれていた.. Espresso-contrib for DatePicker, RecyclerView, Drawer actions, Accessibility checks, CountingIdlingResource) あと、@SmallTest, @MediumTest, @LargeTestの説明あったけれど、社内で定めた基準とだいたい同じ感じ。 そういえば、Espressoでは、waitとか用意しなくて良いのね。Espressoのテスト、ちょっと調整しよう。 Espresso waits until the UI is idle before it moves to the next operation. Likewise, it waits for AsyncTask…More

[Swift]protocol、再び

Object Orientedではなく、Protocol Oriented(Swift)への理解を深めたい最近です。 https://www.raywenderlich.com/109156/introducing-protocol-oriented-programming-in-swift-2 の記事をざっと読みながら思ったのですが、protocolでは let の定義がつかえないことに疑問を覚えました。StackOverflowでも確かにありました。 http://stackoverflow.com/questions/34385897/why-i-cant-use-let-in-protocol-in-swift protocolは抽象インタフェースになるので、具体的な値が入りません。letはconstantな振る舞いが必要ですが、protocol自体は具体的な値はその具体化されたstructやclass、enumなどで変化するためですね。なので、protocolでは var を使う必要があります。ただ、そのstructなどのprotocolを引き継ぐ時はその先で let を使ったりできます。 なるほどね。 ちなみに、以下がprotocolとそれを使ってstructやenum、extensionした簡単な例です。protocolで { set } を指定していると、当然ながらemutableではいられないので継承した先で同名の変数は let で定義することはできません。 This file contains hidden or 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…More

[Elixir]add search box

ある人に検索窓まだー?と言われたので、メモがてら軽くサンプル実装してみた。 こんなもんで良いかな… controller def search_email(conn, %{“search” => %{“query” => query}}) do result = User.search_user_with_email_ilike query <> “%” users = Repo.all(User) render(conn, “search_index.html”, users: users, assigns: result) end model def search_user_with_email_ilike(email) do from(user in User, where: ilike(user.email, ^email)) |> Repo.all end web/router.ex post “/search”, UserController, :search_email search_index.html %script function sample(users) { window.alert(users) } – form_for @conn,…More

[Erlang][Elixir]if condition in Erlang/Elixir

昨夜のElixirのifの使いかたに対しての話に参加して。メモ。 Elixirのifって、以下の通りcaseから構成されるmacroとしてKernelに定義されているのですよね。nilとfalseに一致したら else を行い、それ以外は if を行うと言う。 This file contains hidden or 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 Show hidden characters # https://github.com/elixir-lang/elixir/blob/v1.2.5/lib/elixir/lib/kernel.ex#L2321 defmacro if(condition, clauses) do build_if(condition, clauses)…More

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

過去、 EarlGreyが出たての頃に試してみた のですが、最近またプライベートで使ってみたので自身のために残しておきます。 対象のproject: https://github.com/KazuCocoa/MyGithubSearch 対応コミット: https://github.com/KazuCocoa/MyGithubSearch/commit/bd83bf8668260978ec6941bd8c003470c9443167 幾つかサンプルではなくて自分で使ってみて、Appiumとの使い分けやテストレベルの対応などもある程度私の中で腑に落ちた感じがしました。 EarlGreyについて EarlGreyは、XCUITestみたいに描画要素に対して何らかの操作を行うライブラリです。面白いのは、 UIView をハックしてなにか操作を模倣するのではなく、 UIAccessibility Protocolを操作する。 リポジトリはこちら。 https://github.com/google/EarlGrey EarlGrey自体の説明はあるのでここでは書きません。 セットアップ、導入 https://github.com/google/EarlGrey/blob/master/docs/install-and-run.md Swiftサンプル https://github.com/google/EarlGrey/blob/master/Demo/EarlGreyExample/EarlGreyExampleSwiftTests/EarlGrey.swift 何か困った時 使えるAPIや、使い方がわからないとか、そういう時はテストコード読んだりAPIドキュメント見るとある程度対応できます。 APIドキュメント https://github.com/google/EarlGrey/blob/1.0.0/docs/api.md 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を有効にしてそれを使うと良いです…More

Reading “Raft” – consensus algorithm

Raftという、合意アルゴリズムが存在する。これは、多数決を元にした多数派の意見を決定するためのアルゴリズムで、分散環境下における合意形成でも使える。最近、分散系の幾つかのWebサイトを眺めていると見つけた。 私は、こういう系統の技術分野は大学院の頃にByzantine General Problemを扱ってから比較的興味を持っている。 実際のツールだと、CoreOSのetcdやhashicopeのconsulなんかで使われているみたい。 Raft自体に関係するところは以下。 https://raft.github.io/ http://thesecretlivesofdata.com/raft/ 幾つかの言語で実装されているみたい。etcdではgolangぽい。 Erlang実装の1つ https://github.com/dreyk/zraft_lib Elixir実装の1つ。 https://github.com/mururu/rafute 幾つかRaftの論文のreferencesを見てみましたが、Byzantine faultなんかはやぱり参考にされていました。2014年が論文としては初出? LESLIE LAMPORT氏によるByzantine General Problemの問題は、懐かしさがある(大学院の頃によく読んでいた)。最近はご無沙汰だけれど、技術だけの話でいうとこれ系が関わる仕事はしてみたいな。 参考 http://blog.obfuscatism.net/2014/12/01/raft.html http://kumagi.hatenablog.com/entry/distributed_system_taxonomy_part4More