[Elixir]read “Craft GraphQL APIs in Elixir with Absinthe”

Craft GraphQL APIs in Elixir with Absintheを読んだ。Amazonからはこちらから購入可能になる予定らしい。

Beta配信されて購入できるようになったので、GraphQLを学ぶことも含めて購入、読み進めてみた。GraphQLは、ざっと情報を巷のBlogなどで見ているが、実際にサンプルアプリ以外でコードを書いてWebアプリを開発したことはない状態。

はじめにGraphQLの簡単な話があったのち、ElixirのAbsintheを題材にしてGraphQLを実際に作り、実装してみるという流れ。これにより、GraphQLのクエリの形や仕様を学びながら、実際のツールの使い方を学ぶことができる。この書籍を書いているBruce Williams氏とBen Wilson氏は実際にGraphQLを使いプロダクションの開発を行なっているらしく、その知見も少し味わうことができる。

デフォルトではAnsintheはこのブラウザツールが有効になっている状態で開発を行うことができる。一方、プロダクション向けには interface :simple という形式を router.ex などに指定すると良い。なお、本書ではAnsintheはPhoenixフレームワークを題材として、提供されるサンプルコードもそれを使っているがAnsinthe自体はPlugなど含めて別にPhoenixに限ったフレームワークではない。

GraphQL関係の他には、以下のようにパターンマッチを使うことができると知らず、本書でできるとしったことがよかった。新たな知見 🙂

# define `fn` with some pattern matching
f = fn
  1 -> 1
  2 -> 2
end

# Pattern match
f.(1) # 1
f.(2) # 2

ともあれ、ざっとGraphQLの概要を知りたいとかだけだとこの書籍は不要そう。実際にElixirを使いながら学ぶという形には良い。実際のサンプルコードもあり、そのコードはドキュメントなども豊富なので、コードリーディングの良い題材にもなると思う。

Advertisements

“初めての自動テスト”は様々な人に手にとって読んでほしいものだった

9月21日に発売された”初めての自動テスト ―Webシステムのための自動テスト基礎”を恵贈いただいたことと、少しレビューさせて頂きましたので合わせてこの書籍に関して書こうと思います。(以下、本書)

この本は元々、The Pragmatic Bookshelfでβ販売から開始されたThe Way Of The Web Testerが玉川さんによって翻訳されたものです。この書籍の著者は、アジャイルサムライを書かれたJonathan Rasmussonさん。

私はβ配信の頃にこの書籍を見つけ、過去、このBlogにおいても簡単な感想を書きました。その頃から少し後半が更新、少し内容が追加され、2017年6月29日に最新版が配布されました。本書はその最新版を翻訳したものですので、その内容は最新のThe Way Of The Web Testerと同等のものとなっています!

私は、玉川さんととある活動で知り合っていたこともあり、本書の翻訳レビューと主にはRubyコードに関わるところで相談させていただきました。また、過去にこの書籍の原書を読んで内容の素晴らしさを感じていたので、レビューの相談を頂いたさいも良い意味でとても驚きました。レビュー時から感じていたのですが、この翻訳版である本書の表現などの素晴らしさは玉川さんのご尽力のおかげです。とても良い仕上がりになっているかと思います。

本書に軽く触れる前に、私がこの書籍で好きなところを残しておきます。本書は、開発プロセスなどのテストに関わる周辺環境をなるべく剥がし、テストやそのコードに関わるところの足場に注力しているところです。一方で、ただ単にテストコードの話だけに止めるのではなく、そこに至るまでの話を チーム を中心にしているところが気に入っています。そのため、英語版、日本語版共に、これからテストに入門する人、経験の少ない人、経験の深い人各々に、それぞれの良さをつけてオススメしたいと思っています。

ここで少し話を脱線すると、本書に書かれているレガシーコードに対するUIテストの導入話や、テストピラミッドの話は、少し前にtry!Swiftにてお話させて頂きました内容と同じようなことも言っています。そのため、本書はWebと題しながらも、モバイルなどにも汎用的に使える考え方も多いことを感じるでしょう。

では、少し本書に触れます。

チームの人に

第1章、第8章は概念、実際にテストを導入するときに気にしないといけないところを中心に書いています。そのため、広くチーム全員にオススメします。この箇所で共通認識を持っていると、導入するテストの全体像に対する共通認識を説得する手間が省けるとおもます。読書会みたいな感じで話し合うのも良いかもしれません。また、ここではプロダクトに対するテストの全体像、どんなテストを、どのくらいの量、自動化すると有用かということを知るもとができます。

コード書く経験があまりない人に/手動テストが主な人に

8章までは基礎的なことが書かれているため、そこでテストコードの実装含め、基礎を学ぶことができます。実際にコード書きながら様々なユニットテストを学んだり、Webアプリの仕組みを大まかに学ぶことがでるためです。ここを学ぶと、発展的な内容を学ぶ土台となる知識が得られ、プログラミングが関わるような勉強会でもある程度話が想像できるようになると思います。

9章以降ではもう少しちゃんとプログラミングに触れたり、より良いテストコードの書き方、テストファーストの考え方まで学ぶことができます。本書にも書いてますが、本書をざっと学び、コードを書きながら経験を積んだ後には、よりテストコードを書き、よりコードを書く経験を増やし、他の書籍などを読みながら自分の力で自動テスト関係やその周辺環境の経験を増やしていけるでしょう。

本書を読み終えたら

プログラミング言語でいうとここではRubyを題材にしていますが、モバイルに足を踏み入れるとJavaやKotlin、Objective-CやSwiftに触れる必要が出てくるでしょう。また、Webでも他の言語を学ぶことができます。言語におけるテストコードの文化や書きやすさの違い、プラットフォームによるテストし易さの違いを学びながら、より発展的なエンジニアとしての道を歩むことができるでしょう。

よりテスト技術に関して学びたい場合は、テスト技法関連の書籍を追ったり、GitHubなど含めてモックライブラリなどのライブラリを追うと良いでしょう。様々な、それぞれ使用感の異なる多様なライブラリに出会い、それぞれの良し悪しを学んだりできるかと思います。

また、ここの学んだことをベースに、アジャイルテスターのような方面に足を踏み入れることも挑戦的で面白いかと思います。開発プロセスなどが絡む方面に進むこともまた面白いかもしれません。

いずれにせよ、本書は様々な経験をする足場を学ぶことができるので、ぜひ手を取ってみていただければと思います。

read “Learn Functional Programming with Elixir”

少し気になっていたLearn Functional Programming with Elixirがβ公開されたので、気になって読んでみた。

内容自体はすでになんらかのElixir本を学んでいると特に目新しいものにはでくわさないと思う内容だった。ただ、7、8章の Design Your Elixir Applications, Handle Impure Functions はまだ公開されていないが、この箇所は少し雰囲気がElixirの説明から実際のアプリケーションに話が寄っている感じがしている。

内容として、高級関数の他に、末尾最適化の話も触れていたし、そこは実際のプロセスモニタリングしながらmemory消費の優位性を明記していたところが良かった。

あとはeager/lazy関数のことも言及していて、以下のような無名関数を使い、lazyな関数宣言を適切にモジュール内で使っていたリファクタリングの話なんかは、少し新鮮で面白かった。

a = fn x -> IO.puts x end
a.(1) # 1, :ok

あと、 :ok, :error で結果を出し分ける言語文化(from Erlang)の話も触れていたり、コラムもほどほどに詳しいところに踏み込んでいて良かった。

最初の一冊よりは、少しチュートリアルをやった後にElixirらしい記述をするためのとっかかりとして学ぶとか、そういう書籍っぽい。

Read “Sprint”

Sprint: How to Solve Big Problems and Test New Ideas in Just Five Daysを読んだ。

この書籍は仮説に対する価値検証を行うまでの流れを1週間という時間制約をつけた中で行い、より特定の問題に焦点を当てた解決策がどの程度価値のあるものかを計測できるようにする方法をまとめている。その流れを月曜から金曜まで、1日づつテーマを決めて進めていく。

月曜:取り組む課題の全体像を描く。対象とする 課題 を選択する。

火曜:その課題に対して解決策をあげる。

水曜:解決策から、プロトタイプを行う策を決める。

木曜:プロトタイプを作成する

金曜:評価など

これらに対して、色々なtipsの紹介などがあった。

ただ、内容としては要求分析の話だったり、ブレインストーミング、優先順位の設定など、特別変わったことをしているようなものは少ない。議論と合意を持って進めるというようなところは根気が必要かもしれない。

これで、ある程度同じ内容を前提に会話できるかな…

「RubyでつくるRuby」を読んだ

ラムダノートから出版されている、RubyでつくるRubyを読んだ。

とちぎRuby会議07で、同書籍の一部を学び、そこからまるっと学んだ感じ。ElixirのMacroやLispがこの木構造と同じ形をとるので、木構造に分解された抽象構文木を見てもさほど読みにくさはなかった。

大学の頃、コンピュータサイエンス系をかじると大体はこういう分解された処理機構に触れるのではないかなと思います。それをRubyを使い、わかりやすく表現している書籍。プログラミングにまだ慣れていない人でも、読みながらインタプリタを書き、どういう形で構文が解析され、実行されるかを観察することができるとても良い書籍だと思います。

良い復習になったと思う。

[Android]Run orchestrator 1.0.0

Download apks from maven:

And install them and start the process like https://developer.android.com/training/testing/junit-runner.html

adb install -r path/to/orchestrator-1.0.0.apk
adb install -r path/to/test-services-1.0.0.apk

# Replace "com.example.test" with the name of the package containing your tests.
adb shell 'CLASSPATH=$(pm path android.support.test.services) app_process / \
  android.support.test.services.shellexecutor.ShellMain am instrument -w -e \
  targetInstrumentation com.example.test/android.support.test.runner.AndroidJUnitRunner \
  android.support.test.orchestrator/.AndroidTestOrchestrator'

If you have a custom runner, you can replace android.support.test.runner.AndroidJUnitRunner to yours.

After the above, you can start instrumentation tests via the orchestration layer.

./gradlew connectedAndroidTest

“異文化理解力”を読んだ

異文化理解力を読んだ。

現在、新しいチームの立ち上げとして異文化の環境で活動を始めている。
その中で、単なるGitHubなどの上での活動ではなく、直接議論したり、対話したりする必要がある。

この書籍自体を信じるすぎることは、特定の文化などへのステレオタイプを生むことになったりとマイナスな面もある。そのため、こういう面もあるという一つの意見としてしる、に止めることが大事だと思う。そのため、そのことを考えながら読んでいた。

異文化を考えるときに考慮した方が良い指標として、以下をこの書籍では言及している。

  1. Communicating
  2. Evaluating
  3. Persuading
  4. Leading
  5. Deciding
  6. Trusting
  7. Disagreeing
  8. Scheduling

この中では、日本も多々出て来ていて、日本やアジア圏はハイコンテキストな文化というような、自分でも納得するような見解も述べられている。一方で、日本人でも自分の周辺は少し雰囲気が異なる面もいくつかあり、やはり1つの意見として触れる方が良いという感じ。

また、フィードバックを行うときなど、”ネガティブさ”を強調する、弱める言葉がある。フィードバックは大事だが、簡単に関係を壊したり、逆に意図が伝わらないことも多い。そのためこういう言葉を使いつつ、ちゃんと伝える/和らげることを覚えたい。

批判を和らげる言葉としては: kind of, sort of, a bit, maybe, slightlyなどがある。
批判を強める言葉としては: absolutely, totally, stronglyといったお馴染みの言葉が並ぶ。

多分化なチームはやはりコミュニケーションコストが増える。そのため、時間を節約したいのであれば文化の違いを抑える構成にする必要がある。一方で、イノベーションや創造性といったところを時間の節約以上に重視するのであれば文化の多様性を、プロセスをしっかりした上での取り入れると良い。

このような視点からも、この異文化というものは見て取れることができる。

信頼の形もいくつかあって、1. cognitive trust(認知的信頼) , 2. affective trust(感情的信頼)にも分けられる。

これは、前者はタスクのような認知されるものをベースにする一方、後者は関係性といった要素をベースにする。つまり、業績や技術といった確実性に対する確信に基づく信頼と、親密さや共感・友情といった感情から形成されるものに分けられる。

全体を通して、日本に関して言及しているものの中でも納得できるもの、できないものもあった。そのため、やはりステレオタイプではなく、全体としてこういう 多様さがある ことを認識する1つの意見と理解するのが良いのだと思えた。

英語で対話することが中心になるため、他者にも伝えることができるようにこの書籍の原書よりも少し新しい、英語の The Culture Map を読んでみようかと思っている。

[Kotlin]Kotlin in Actionをようやっと終えた

長らく読んでいたのですが、Kotlin in Actionをようやく読み、写経などし終えた。
他にも同時にやっていたとはいえ、このときからすると時間としては結構長かった…

ただ、Kotlin全体の形や、以下のような処理を書いたりしてというところが理解・発想できるようになったぶん、読んで全体を知ることはよかったかなと思います。

以下は、KotlinでSpekといった大きなライブラリを使うほどではないけれど、テストにコンテキストを持ち込みたい時なんかにプロジェクトに書いておくと良いのではないかな、と思うやつです。

class Then {
}

class When {
    fun then(description: String, then: Then.() -> Unit) {
        then.invoke(Then())
    }
}

class Given {
    fun `when`(description: String, `when`: When.() -> Unit) {
        `when`.invoke(When())
    }
}

fun given(description: String, given: Given.() -> Unit) {
    given.invoke(Given())
}

given("description for given") {
  `when`("description for when") {
    then("description for then") {
      println("finish")
    }
  }
}

KotlinだとWhenが予約語になっているので、Spekででもなのですが、Given/On/Itスタイルにすると良さそう。

class It {
}

class On {
    fun it(description: String, it: It.() -> Unit) {
        it.invoke(It())
    }
}

class Given {
    fun on(description: String, on: On.() -> Unit) {
        on.invoke(On())
    }
}

fun given(description: String, given: Given.() -> Unit) {
    given.invoke(Given())
}

given("description for given") {
  on("description for on") {
    it("description for it") {
      println("finish")
    }
  }
}

すぐに書くことはできるものですが、一応、ここではライセンスをMIT Licenseにしておきます。

The MIT License (MIT)

Copyright (c) 2015 Kazuaki MATSUO

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

[Android]composer and swarmer

I’ve posted [Android][iOS]Awesome tips about composer and swarmer.

The following is my trial with them.

https://github.com/KazuCocoa/run_parallel_tests_android

[Android]Checking Android Testing Support Library 1.0

update: Aug 9, 2017

I encountered no tests found error when running tests with AssertJ and AndroidJUnitRunner1.0.0.
https://stackoverflow.com/questions/45402645/instrumented-tests-failure-with-androidjunitrunner-1-0-0-and-assertj


A few days ago, Android Testing Support Library 1.0 was released.
I pick up some awesome stuff for me, and I think this release will help enhance test automation for other 3rd party libraries.

IdelingResources

help synchronise against

  • Executors
    • com.android.support.test.espresso.idling:idling-concurrent:3.0.0
  • network requests and responses
    • com.android.support.test.espresso.idling:idling-net:3.0.0

New view matchers/actions/methods

Parameterised testing

GrantPermissionRule

Understand how to write/think test for Android

Android Test Orchestrator

Runner related command options

  • -e classLoader – Provide the ability to pass class loaders using runner args
  • -e filter – Add support for custom JUnit filters to be specified using runner args
  • -e runnerBuilder – Allows developers to provide their own implementations of RunnerBuilder that can determine whether and how they can run against a specific class