[Android][Accessibility]accessibility check in Espresso

Androidでは、以下のようにしているといくつかのAccessibilityCheckをEspresso実行時にViewに対してチェックしてくれます。

import android.support.test.espresso.contrib.AccessibilityChecks;

@RunWith(AndroidJUnit4.class)
@LargeTest
public class AccessibilityChecksIntegrationTest {
    @BeforeClass
    public static void enableAccessibilityChecks() {
        AccessibilityChecks.enable();
    }
}

これに似た機能をEarlGreyでも実現してほしいというissueが立ってました。
https://github.com/google/EarlGrey/issues/393

ここら辺をうまく拡張していくと、自分たちの組織におけるViewなどのチェックを拡充していくことができるのでないかなーと期待。

[React][iOS][Android]Try ReactNative + TypeScript

以下を参考に、ReactNative + TypeScriptでアプリを書いてみる。
ReactNativeでは testID としてiOSはaccessibilityIdentifier、AndroidはView#setTag/getTagが使われている。(ただ、2016/9ごろにAndroidに対してresource idを付与できるようになったとあったので、ReactNativeでもresource idベースでも今後は大丈夫かも)

以下を参考にした。環境構築周り。


ただ、上記のどれもそのままでは動作しなかったので、本格的にはまだ触っていない。

「消極性デザイン宣言」を読んで、approchiabilityという言葉を知った

消極性デザイン宣言-消極的な人よ、声を上げよ。……いや、上げなくてよい。」を読みました。

シャイハック。
私自身、ここに書かれていたように消極的な人間で、V字タイプな人。少人数や大人数だとある程度大丈夫だけれど、微妙な人数になると「・・・」となるような。

そんな人たちのコミュニケーションの話から入り、だんだんとモチベーション、インタラクションの話へと内容が移ってきます。個人的に面白かったのは、approchiabilityという考え方と、モチベーションの話。ここのモチベーションはやる気を出していく話ではなく、やる気がわかないことを前提とした(意識の低い)モチベーションの話なので、疲れず良かったです。

人間は基本的には消極的

これが基本的な立ち位置でした。消極的なので、自然にできるようにどうデザインするかとか、そういう話になってきます。

機能があることではなく、”機能する”こと、その機能を使おうとしやすいことなど。

Usability と Approachability

Usabilityは使いやすさとしてよく言われます。品質の話になるときや、人間工学の話、デザインの話といったように様々なところで出てきます。一方、Approachabilityという言葉は私が把握している限りでは初耳でした。

Usabilityとの対比としては、Usabilityが製品/サービスそのものの使いやすさを評価の対象とするのに対して、Approachiablityは対象となる製品/サービスがどれだけ”使おうとしやすいか”を評価しようとしている、という感じ。なので、製品/サービスのその周辺から連続した出来事を評価の対象に加えるという感じでしょうか。モバイル端末などの使いやすさとしてはこういった連続性に言及しているものもちらほら見ますが、そこに焦点を当てたものがこの”Approachiablity”という感覚を受けました。

使おうとしやすさ、行為の切り替え・接続、やめやすさ、いかに無理せず自然とできるか。

特別ではなく日常に溶け込む系のサービスとか製品ではこういう考え方って大事なデザインの話になりそうですね。

そういえば、インタラクションデザインにも言及していて、その中であったモチベーションの設計は色々なところで関係しそうな感じがしました。

締め

こういう書籍は時折読みますが、Approchiabilityという言葉の定義はなかなか良い発見でした。

[Design][iOS][Android][windows]

メモ

[ReactNative][Appium]testIDの振られ方

ReactNativeだと、 testID としてiOSだとaccessibilityID、Androidだとview tagを使ってIDを埋め込むのですね。なので、ReactNativeのアプリに対してidで要素を検索したい場合はAndroidだと特に従来のAppiumやEspressoとは少し異なる。

Appiumだと、以下でview tagの取得をサポートするらしい。

これつくと、resource idが同じ要素も細かくidを振って操作することもできるようになるので、安定性向上に寄与しそうですね。

Does EarlGrey support finding react-native elements?
https://github.com/google/EarlGrey/blob/master/docs/faq.md

react native

2016年振り返りと2017年へ

2015年振り返りと2016年へ ~20代も最後~からもう1年たったのですね。30歳ですかー。

今年の活動を簡単に振り返る。2017年のことも、最後に。来年振り返る時にちゃんと達成できているとよいな。

全体

今年は私の中ではOSS周辺の活動が大きく動いた気がします。あとは機械学習系とかも今後テストでは標準的なスキルになるはずなのでそこらへんを学んだり…

振り返り

仕事(Works)

活動(Activity)

発表系

2015年はJaSSTなんかに積極的に募集したのですが、今年は少し異なる方面の活動をしていました。人のキャリアプランに影響を及ぼしているという話も耳にし始めました。

OSS系

一番大きかったのはAppiumのRuby bindingのメンテナになったことでしょうか。他には言語ではElixir、Ruby、Swift(Objective-C)、Java周りで既存OSSにPR投げたりOSS公開したりしました。今の会社に入って、会社がOSSを推奨するのでOSSに対する活動を広げてきましたが、ここにきて世界的に使われているツールのライブラリメンテナになるとは思ってもなかった…

screen-shot-2016-12-31-at-22-17-10

  • AppiumのRuby bindingnのメンテナになった
  • 公開したもの
    • DroidTestHelper
    • anticuado
      • 対象となるプロジェクトのoutdatedなライブラリをHash形式で整形されたものを取得可能なライブラリ
      • Android(Gradle)、iOS(CocoaPods/Carthage)、Ruby(Bundler)、Elixir(Hex)、JavaScript(npm)を今サポートしている
      • https://github.com/KazuCocoa/anticuado
  • 以下のOSSに不具合修正などのPR投げた
    • Elixirやその周辺ライブラリ
    • EarlGrey、Turnipなどのテストライブラリ
    • toothpick といったAndroid向けDIライブラリ

その他

  • とあるソフトウェアエンジニアリング系の書籍の翻訳を複数人で実施中

専門性

  • ソフトウェアテストや品質改善に関してはちらほらと勉強会に顔を出したりしています
    • JaSSTの廊下で話すようなところが一番実りある会話できますね。そういえば…
  • 引き続き、自動化研究会に参加
  • UdacityのDeepLearning系とか学んだり

2017年へ

いくつかやりたいことに向けて蒔いたタネが実ってきているので、もう少し先のやりたいことへ手を出したいなーと思う次第。
あとは健康に気をつけながら…(私生活は言わずもがな)

やること

やりたいこと

  • DMM英会話など使って英語の会話に慣れる
    • try!SwiftTokyoに向けて週2、3で最低限やっていきたいのですよね
  • 海外に出張/移住ベースで何か仕事していきたい
    • 外にいくだけなら旅行でも良いのですが、仕事としてちょっと活動したいかなーという感じ
    • ちょっと親知らず抜いたりするので、前半は厳しいけれども…
  • Swift/Kotlinに関するプログラミングスキルを補填したい
    • 仕事…

興味の対象を主な活動の範囲として楽しみながらやりたいですねー

[Elm]getting start Elm language

Elm is a functional language that compiles to JavaScript

GitHub : https://github.com/elm-lang

知ってはいたのですが触っていなかったElm。少しきっかけがあったので触ってみました。
※Elmについて、といった内容はここでは触れません。

この理由としては、チームメンバの1人がSwiftでとある機能を実装している時にこのElm Architectureから構成をインスパイアされたといっていたためです。といっても、Elm Architecture付近をチュートリアルを元に学んでみたというくらい。なので記法を学ぶというよりは、どんな問題を解決しようとどういう設計を行ったか、です。(そういえば、このElm->JSのコンパイラはHaskell製)

試したElmは0.18.0

tutorial(guide): https://guide.elm-lang.org/

tutorialをいくつか実際に動かしたGitHub repository: https://github.com/KazuCocoa/my_first_elm

Elm、実行環境も elm-repl コマンドでターミナル上から簡単に動作みることできるし、 elm-reactor コマンド実行するとローカルホストにブラウザでアクセスするとすぐに動作みることができるので触ってみる障壁がとても低くて感動しました。ドキュメンテーションとか、コミュニティパッケージ群も揃っていました。テストツールとかも、パッケージとしていくつも既に存在しているみたいです。

Elixirをもともと触っていると感じたのですが、なかなかElixirと似通ったものがありました。類似言語に影響を受けているっぽいので文法的なところもなのですが、 One crucial detail here is that commands and subscriptions are data と書いていたり、 Elm treats errors as data とあるように、データの流れを基軸として表現しようとしているところです。

では、かいつまんで。

Architecture

Elmの実装設計パターンは画面の操作を以下のように3つに分割してデータを記述するところ、データを更新するところ、それをViewに反映するところ、で分けるところです。これにより、基本的なボタンをタップするとか、そういうことに対してデータを受け取り、更新し、Viewに反映するという一定の操作を決まった定型文によって区切りながら実装することができるようになっています。

  • Model — the state of your application
  • Update — a way to update your state
  • View — a way to view your state as HTML

これに加え、例えばHTTP通信などの非同期処理などの命令を扱うためにも以下のように2種類の定義も追加されました。( https://guide.elm-lang.org/architecture/effects/ )

  • Commands — A Cmd lets you do stuff: generate a random number, send an HTTP request, etc.
  • Subscriptions — A Sub lets you register that you are interested in something: tell me about location changes, listen for web socket messages, etc.

Elmはこのeffectsの箇所でも以下のように書いている通り、この commandssubscriptions もデータを記述しElmフレームワークに渡すためだけのものとして扱うようです。そこらへんから結果を受け取ってViewに反映させるまでの受け渡しはElm側がみていると。

Aside: One crucial detail here is that commands and subscriptions are data. When you create a command, you do not actually do it. Same with commands in real life. Let’s try it. Eat an entire watermelon in one bite! Did you do it? No! You kept reading before you even thought about buying a tiny watermelon.
Point is, commands and subscriptions are data. You hand them to Elm to actually run them, giving Elm a chance to log all of this information. In the end, effects-as-data means Elm can:
– Have a general purpose time-travel debugger.
– Keep the “same input, same output” guarantee for all Elm functions.
– Avoid setup/teardown phases when testing update logic.
– Cache and batch effects, minimizing HTTP connections or other resources.
So without going too crazy on details, pretty much all the nice guarantees and tools you have in Elm come from the choice to treat effects as data! I think this will make more sense as you get deeper into Elm.
> from https://guide.elm-lang.org/architecture/effects/

あと、エラーハンドリングのところも昨今のnullやexceptionの扱いに関して言及していてよかったです。Erlang/Elixirを触っていると結果はだいたい {:ok, xxx}{:error, xxx} として処理を分けることがほとんどなのですが、そのような感じですね。

実装され、提供されている機能は以下。

  • Maybe
  • Results
  • Task

Null

I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.
> 本文より

Exceptions

Joel Spolsky outlined the issues with exceptions pretty nicely in the year 2003. Essentially, code that looks fine may actually crash at runtime. Surprise!

以下なんかをみていると特に、Elixirでいう case ... do ... end の形を思い出します。

締め

1日程度触った感じですが、Elm、なかなかElixirやSwift書いている人にすると比較的学びやすいJS実装な気がします。今後使い続けるかは別にして、関数型言語の領域を学ぶというところでは情報も多すぎず程よいかもしれません。