Author Archives: KazuCocoa

『コーディングWebアクセシビリティ』を読んだ

コーディングWebアクセシビリティを読みました。 Apps For All – Coding Accessible Web Applicationsの翻訳版です。 Webに限らずアクセシビリティの重要さは前々から言われてきたことですね。そのW3Cで進められているWAI-ARIA(Web Accessibility Initiative-Accessible Rich Internet Applications)に関して書かれた本です。 すぐに役立つわけではないけれど、すべての人がWebやモバイルアプリなどに触ることができるようになると、需要は低いかもしれないけれど確実に無視されがちな人たちにもハッピーを届けることができそうな気がします。(なので、無知ではいけなさそうだと読んでみました) 技術的な目新しさというよりも、アクセシビリティとして大事だよね、という話。 MozilaでAccessibilityのQAを担当している人のブログもおまけ: https://www.marcozehe.de/ Chrome Extentionで、表示しているWebページのアクセシビリティを確認できます: https://chrome.google.com/webstore/detail/tenon-check/bmibjbhkgepmnehjfhjaalkikngikhgj?hl=en-USMore

Androidのhierarchy viewerをStetho使ってChromeで見られるようになった

Stethoが1.1.0に更新され、CHANGELOGも更新されました。 大きな機能追加としては、hierarchy viewerの追加でしょうか。今までだと、 uiautomatorviewer を単品で使うかAndroid Device Monitorを使う必要があるため、確認が少し面倒でした。 これにより、Chromeブラウザがあれば同様の機能を見ることができます。API Level18以上だと、選択した箇所がハイライトもされます。 個人的には、これでAppiumのシナリオ書くときなんかも、Chrome見れば十分、というのが良いですね。Androidの開発環境が十分でないときでも、シナリオを増強できる。ちなみに、これ有効にしていると、Chromeでviewを読み込むための時間が必要になるのでアプリの動作が若干緩慢になりました。 XPathをコピーすると //*[@id=”@id/example_path”] のような値が取得できるのですが、これはXPath strategyでは正しく識別できない。このidはresource_idなので、 //*[@resource-id=”packagename:id/example_path”] のように指定する必要がありますね。 example_pathちょっとコードを追ってみる。 対象バージョン Stetho 1.1.0 Stethoの開発に使っている依存関係。 なるほど。junit4.12使っているのか。 https://github.com/facebook/stetho/blob/master/stetho/build.gradle#L18 Stetho.java https://github.com/facebook/stetho/blob/master/stetho/src/main/java/com/facebook/stetho/Stetho.java デフォルトで読み込まれるPluginの中は以下で追加している。HprofDumperPluginとCrashDumperPluginは今回の更新で入ったものかな。このようにplugins.addで、このほかにも独自Pluginを導入する方法もreadmeに書かれている。 以下は、Chromeのinspectorで表示するためのものを読み込んでいるっぽい。 なるほど。 全体的に軽く眺めただけなのですが、まだ経験の浅い私からすると色々参考になる。アノテーションの使い方とかも。 あと、Stetho、使いやすいので不具合あったときは積極的にコミットしていきたい。More

『コンピュータシステムの理論と実装』を読んだ(というか、さっと眺めた)

積読消費週間。 コンピュータシステムの理論と実装 ―モダンなコンピュータの作り方を読んでみました。 書籍の読者対象が”大学院生”と書かれていたので、ざっと眺めて、学んだことはないが今学んでいた方が良さそうなものを知る為、でした。新入社員の季節ですしね。 結果としては、特別な目新しいものはなかった、という感じです。ただ、これは大学/大学院と情報系といわれる分野を学んでいると、基本的には全部触れたことがあるような内容が丁寧に網羅されていたため、という非常に良い意味ででした。さすが、読者対象のど真ん中。(ちなみに、私は2011年3月に院を卒業した、という人です。) フリップフロップの話やら、OSの話やら。数学的な理論よりの話も入ってて、コンピュータサイエンスを学んでいなかった人が、学ぶという意味ではとても良いものな気がしました。 私も忘れているものもありましたが(読んでて、やったな〜という感じ)、これ1冊で主要な内容が網羅されているのは良いですね。索引として強い。興味ある分野はよりちゃんとした書籍を読み始めるとなおよし、という感じですね。More

『リファクタリング:Rubyエディション』を読んだ

最近は積読消費週間。積読だった、リファクタリング:Rubyエディションを読んだ。 いつだったか、t_wadaさんのTDDの説明の中で紹介のあった、リファクタリングの書籍に興味を持って購入したやつです。 “エンジニア”と名がつく以上、開発に特化する人も、テストに特化する人も、リファクタリングとは1度くらいは付き合う必要があると思います。テストエンジニアだとテストツールやテストコードが主になると思いますが、製品コードを読むし、必要であれば修正することもそれなりにあるはずです。これは、そんな時の助けになると思い購入していたやつです。 コード書きながらでないとよく分からないところなんかはコード書きつつも、基礎的な考え方は多少プログラミングや設計を学ぶと至るであろうことが丁寧にまとめられている感じ。こういう書籍で、経験をまとめて腹に落とすことができるって、先人の功績を享受できる年代の美味しさですね。ありがとうございます。 Rubyだとそれらをどう行うか、Ruby固有のメソッドでどう簡単に実現するか、というところが言及されててすごく役立ちました。 個人的には暗記が得意ではないこともあり、こういったものはひたすらに暗記するのではなく、実務で必要な時に索引できるよに頭の中にある程度の索引を作っておけることを重要だと考えています。頭の中に多少なりとも索引可能な状態にしておくと、Ruby以外の言語でもこうしたいとか、考えるときに探すあてになったりもしますし。必要であったら、本を持ってコードと向き合いつつ、必要なところをピックアップして体験にも馴染ませる、という感じでしょうか。 ゲートウェイパターンとか、Web開発で肥大化に立ち向かう上では必須なやつだなーとつくづく思う最近でした。More

『スマホに満足してますか？~ユーザインタフェースの心理学~』を読んだ

スマホに満足してますか？~ユーザインタフェースの心理学~が面白そうだったので読んでみました。POBoxやiPhoneの日本語入力システムの開発者として知られている増井さんが書かれたものです。 心理やデザインの話から、開発、トレンド、これからの世界に関してざっと書いていました。単なる読み物以上、がっつりした技術書以下、くらいの感じで読めました。多くの知見や引用資料に基づいた知見は色々学びになります。Kindleで読んだので、気になった引用はさくっと確認できて良い感じでした。基本的に、なんらかの例に対してその多彩な引用からその裏づけを提示し、人とコンピュータ、スマホ、デザインなどの主にはUXと言われるような領域での関係性や観察した内容が連なっています。 デザインでは、”モバイルコンピューティングのために工夫された入出力装置や手法が、そのままユニバーサルデザインへと適用できるものも多いこと”というところが印象的というか、腹に座りました。ユニバーサルデザインのガイドラインとして、ロン・メイス氏らのデザインの7つの原則のほか、W3CのWeb Accessibility Initiative(WAI)、Center for Applied Special TechnologyによるBoddyというツールによるwebページのアクセシビリティ検証などの話もありました。 Testingを行っていると、どうしてもAccessibilityという領域は無視できないものだと思っています。そのソフトウェアなどはユーザに対して使いやすいのか？とか、そういう観点を考えると切っても切れないですね。 苦手は研究の母 という言葉もすごく納得。苦手なものを克服する、解決しようとするところはまさに問題解決ですね。大学など以外でも必要は発明の母とかはよく言われますが、苦手から革命的な解決策が出てきたりとか、すごくありそう。こういうところ、人や考え方の多様性が必要と言われる要因としてすごく納得できるものがありました。知識をつけたり得意なものが多いと 発明できない とはこういうことなのですね。 人の記憶と認証に関して書いている箇所もありました。例えば、忘れにくいとされる人のエピソード記憶からパスワードを自動生成する、という着想のパスワード。それのEpisoPassと言われるツールの紹介は印象的です。単に”パスワード”を設定するというところだけを切り出すのではなく、そのパスワードの安全性を人と結びつけて現実解に落とす。コンピュータの世界と実際の使用者とのつながりを考える興味深い考えでした。 Testingの観点としても役立ちそうな点が多く、また読み返したいと思った一冊でした。 おもしろいなーMore

DroidDriverのJavaDocを少し観察してみた

DroidDriverのJavaDocをもすこし読んでみた。 io.appium.droiddriverのJavaDocsより 以下、いくつかピックアップして読んでみた。 BaseDroidDriver DroidDriverを使ってテストを記述するとき、通常は BaseDroidDriverTest を継承して使う。 BaseDroidDriverTest は、 D2ActivityInstrumentationTestCase2 を継承している。 D2ActivityInstrumentationTestCase2 は ActivityInstrumentationTestCase2 を継承している。 D2ActivityInstrumentationTestCase2 は ActivityInstrumentationTestCase2 で既知の不具合であるISCよりも小さなバージョンのOSで再現するNullPointerExceptionの修正を含んでいるとのこと。 D2ActivityInstrumentationTestCase2 にある scrubClass の引用 Fixes a bug in ActivityTestCase.scrubClass(java.lang.Class) that causes NullPointerException if your leaf-level test class declares static fields. This is a known bug that has been fixed in ICS Android release. But it still…More

忘れないようにIntentのUnitTestを書いてみた

昨日の記事をちょっと手を動かしておこうと思って、IntentのUnitTestを書いてみた。ついでに、@RunWith(AndroidJUnit4.class)を有効にして。 AndroidJUnit4.classを使うにあたってエラーが出て修正したポイントは2つ。あとおまけで1つ。 injectInstrumentationによるInstrumentationへのinject これしないと、super.setUp()で落ちる InstrumentationRegistry.getInstrumentation().runOnMainSync()によるintentからのActivityの起動 これしないと、startActivityがヌルポで落ちる ContextThemeWrapperを使うことで、R.style.AppThemeをテスト時にレイアウトとして使う レイアウトを独自でカスタマイズしている場合、AppThemeが無いみたいなエラーが出てきました どうやら、ContextThemeWrapperで仮のレイアウトを使うことで回避できるもよう 今回はあくまでもintentの確認なので、まー、よしですかね UIスレッドの話しなんかも、対応を終えたあとはなるほどなーという感じ。 ちょっと記述量を減らしたく、ButterKnifeを使ってみました。おまけ程度。 内容は、 com.example.activityのアクティビティを起動する 表示されるボタンをタップして、別アクティビティ(com.example.activity.Next)を起動する という内容に対して、期待したintentが飛ぶことを確認する、というものです。 ActivityUnitTestCaseなので、その実際が描画されたりはしません。これ、Integrationレベルで確認すると、Espressoを使って描画ベースの存在確認を行いますね。 ふぅ。Intent、いろいろちゃんとしておかないと魔の巣窟になって危なそうですね。サービスが肥大化してくると特に。怖い怖い。 最近、StethoをVolleyに適用しようとしています。単純に適用しようとすると、VolleyのHttpStackを活用してOkHttpStackのようなクラスを作成し、QueueRequestにHttpStackを与えます。 なのですが、今取り組んでいるところはそのような形でさくっとできるような所ではなく、少し手惑い気味。More

Testing and Securing Android Studio Applicationsを読んだ

Testing and Securing Android Studio ApplicationsのKindle版が安かったのと米国レビューもそこそこあったので読んでみました。あと、TestingとSecuringを同時に扱っていたので、基礎的な知見もまとめられているものと期待して。 結果的には、出版日も2014年8月とそんなに古くないので、入り口的な書籍としては良いと思いました。ツールやコードの話もありますが、まだ古くて使えない、というレベルのものではないですし。 内容的には、intentに対するUnit testレベルとInstrumentationを使ったレベルでのテスト方法が、個人的には何気に参考になりました。 以下は、私の備忘録込みでつらつらと… 第1章では基本的なソフトウェアセキュリティ全般の話。 Access control Asymmetric cryptography Authentication Availability Brute force Cipher Code injection Confidentiality Crack Decryption Denial-of-service(DoS) Distributed denial-of-service(DDoS) Dictionary attack Encryption Hash function Hijack attack Hypertext Transfer Protocol Secure Integrity MD5 Man-in-the-middle attack Password Phishing Risk SHA1 Sniffing attack Spoofing attack Threat Vulnerability このうち、Threat、Vulnerabilities、risksに関してはさらに言及されていました。 Threat…More

UIAutomator2.0がリリースされていた

3月13日、以下の通りAndroidのUIAutomator 2.0がリリースされていたのですね。 https://plus.google.com/+AndroidDevelopers/posts/WCWANrPkRxg uiautomatorは、AndroidのAccessibility機能やその拡張を介して、インストールされた様々なapkを操作するフレームワークでした。そのため、例えばリリース用apkに対してシナリオテストを自動化するときなんかに使います。例えば、AppiumはAndroidに対してはこのuiautomator1.0を利用してテストを実施することをしています。 uiautomatorあらため、UI Automator 2.0の新しいところは、Instruments経由でUiElementsなどを使えるようになったことらしいです。これにより、./gradlew connectedCheck なんかのコマンドでUI Automatorによるテストを実施できるようになったとか。 まだASOPには公開されていませんが、Appiumのメンバらも公開されたら良さそうなら統合とかするでしょうし、DroidDriverとももしかすると競合するところがあるのかもしれません。 2014年12月のEspresso2.0のリリースとそれに伴うJUnit4の提供、UI Automatorの更新と、比較的テストツールの充実が図られていて良い感じですね。 Testing Support Libraryが提供する大きな機能 AndroidJUnitRunner: JUnit 4-compatible test runner for Android Espresso: UI testing framework; suitable for functional UI testing within an app UI Automator: UI testing framework; suitable for cross-app functional UI testing across system and installed apps AndroidJUnitRunner Require Android2.2(API Level8)…More