“Humans vs Computers” has educational case studies

I had read Humans vs Computers. This book has a bunch of stories against bugs, how bugs affect humans, humans how embedded bugs in computers. Various case studies help you understand what happens if developers embedded bugs into the real-world computers. Thus, you can learn them in one book. So, I describe this book as…More

[Swift] Identify not XCTest against XCUITest and EarlGrey

XCTestでは、Swiftの時にAppDelegateを取得しようとするとクラッシュする問題があります。 そのために、 などを使い、XCTestである場合はmockしたAppDelegateを使うなどの対策を行うことがあります。ただ、この場合だと、 XCUITest や EarlGrey によるテストを行うときもこの判定に引っかかります。 以下の差分には、XCUITestとEarlGreyに置ける上記判定を入れています。両方とも同様に判定が行われます。 https://github.com/KazuCocoa/test.examples/commit/cd3ec48b741320071471b27b3ad6254ce4fbacd5 これを避けるために、例えば環境変数でEarlGreyであることを指定する、などが必要。 https://github.com/KazuCocoa/test.examples/commit/aa527223208d4d56260fa0111ccf158554c0d12f プロセスに対する環境変数、iOSのテストだとちょくちょくお世話になることがあると思うので、覚えておくと良さそう。xcodebuildなどに対して環境変数を与えると同じようなことになりますが、これはプロセスに対する環境変数なので注意が必要（プロセス外で定義した環境変数は参照されない） reference https://stackoverflow.com/questions/26946677/uiapplication-sharedapplication-delegate-as-appdelegate-causes-exc-bad-access?answertab=active#tab-top https://stackoverflow.com/questions/39478895/can-you-pass-environment-variables-into-xcodebuild?rq=1 https://stackoverflow.com/questions/27930137/ios-swift-separate-appdelegate-for-xctest/27981726#27981726More

[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関係の他には、以下のようにパターンマッチを使うことができると知らず、本書でできるとしったことがよかった。新たな知見 🙂 ともあれ、ざっとGraphQLの概要を知りたいとかだけだとこの書籍は不要そう。実際にElixirを使いながら学ぶという形には良い。実際のサンプルコードもあり、そのコードはドキュメントなども豊富なので、コードリーディングの良い題材にもなると思う。More

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

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など含めてモックライブラリなどのライブラリを追うと良いでしょう。様々な、それぞれ使用感の異なる多様なライブラリに出会い、それぞれの良し悪しを学んだりできるかと思います。 また、ここの学んだことをベースに、アジャイルテスターのような方面に足を踏み入れることも挑戦的で面白いかと思います。開発プロセスなどが絡む方面に進むこともまた面白いかもしれません。 いずれにせよ、本書は様々な経験をする足場を学ぶことができるので、ぜひ手を取ってみていただければと思います。More

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な関数宣言を適切にモジュール内で使っていたリファクタリングの話なんかは、少し新鮮で面白かった。 あと、 :ok, :error で結果を出し分ける言語文化(from Erlang)の話も触れていたり、コラムもほどほどに詳しいところに踏み込んでいて良かった。 最初の一冊よりは、少しチュートリアルをやった後にElixirらしい記述をするためのとっかかりとして学ぶとか、そういう書籍っぽい。More

Read “Sprint”

Sprint: How to Solve Big Problems and Test New Ideas in Just Five Daysを読んだ。 この書籍は仮説に対する価値検証を行うまでの流れを1週間という時間制約をつけた中で行い、より特定の問題に焦点を当てた解決策がどの程度価値のあるものかを計測できるようにする方法をまとめている。その流れを月曜から金曜まで、1日づつテーマを決めて進めていく。 月曜：取り組む課題の全体像を描く。対象とする 課題 を選択する。 火曜：その課題に対して解決策をあげる。 水曜：解決策から、プロトタイプを行う策を決める。 木曜：プロトタイプを作成する 金曜：評価など これらに対して、色々なtipsの紹介などがあった。 ただ、内容としては要求分析の話だったり、ブレインストーミング、優先順位の設定など、特別変わったことをしているようなものは少ない。議論と合意を持って進めるというようなところは根気が必要かもしれない。 これで、ある程度同じ内容を前提に会話できるかな…More

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

ラムダノートから出版されている、RubyでつくるRubyを読んだ。 とちぎRuby会議07で、同書籍の一部を学び、そこからまるっと学んだ感じ。ElixirのMacroやLispがこの木構造と同じ形をとるので、木構造に分解された抽象構文木を見てもさほど読みにくさはなかった。 大学の頃、コンピュータサイエンス系をかじると大体はこういう分解された処理機構に触れるのではないかなと思います。それをRubyを使い、わかりやすく表現している書籍。プログラミングにまだ慣れていない人でも、読みながらインタプリタを書き、どういう形で構文が解析され、実行されるかを観察することができるとても良い書籍だと思います。 良い復習になったと思う。More

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

異文化理解力を読んだ。 現在、新しいチームの立ち上げとして異文化の環境で活動を始めている。 その中で、単なるGitHubなどの上での活動ではなく、直接議論したり、対話したりする必要がある。 この書籍自体を信じるすぎることは、特定の文化などへのステレオタイプを生むことになったりとマイナスな面もある。そのため、こういう面もあるという一つの意見としてしる、に止めることが大事だと思う。そのため、そのことを考えながら読んでいた。 異文化を考えるときに考慮した方が良い指標として、以下をこの書籍では言及している。 Communicating Evaluating Persuading Leading Deciding Trusting Disagreeing Scheduling この中では、日本も多々出て来ていて、日本やアジア圏はハイコンテキストな文化というような、自分でも納得するような見解も述べられている。一方で、日本人でも自分の周辺は少し雰囲気が異なる面もいくつかあり、やはり1つの意見として触れる方が良いという感じ。 また、フィードバックを行うときなど、”ネガティブさ”を強調する、弱める言葉がある。フィードバックは大事だが、簡単に関係を壊したり、逆に意図が伝わらないことも多い。そのためこういう言葉を使いつつ、ちゃんと伝える/和らげることを覚えたい。 批判を和らげる言葉としては: kind of, sort of, a bit, maybe, slightlyなどがある。 批判を強める言葉としては: absolutely, totally, stronglyといったお馴染みの言葉が並ぶ。 多分化なチームはやはりコミュニケーションコストが増える。そのため、時間を節約したいのであれば文化の違いを抑える構成にする必要がある。一方で、イノベーションや創造性といったところを時間の節約以上に重視するのであれば文化の多様性を、プロセスをしっかりした上での取り入れると良い。 このような視点からも、この異文化というものは見て取れることができる。 信頼の形もいくつかあって、1. cognitive trust(認知的信頼) , 2. affective trust(感情的信頼)にも分けられる。 これは、前者はタスクのような認知されるものをベースにする一方、後者は関係性といった要素をベースにする。つまり、業績や技術といった確実性に対する確信に基づく信頼と、親密さや共感・友情といった感情から形成されるものに分けられる。 全体を通して、日本に関して言及しているものの中でも納得できるもの、できないものもあった。そのため、やはりステレオタイプではなく、全体としてこういう 多様さがある ことを認識する1つの意見と理解するのが良いのだと思えた。 英語で対話することが中心になるため、他者にも伝えることができるようにこの書籍の原書よりも少し新しい、英語の The Culture Map を読んでみようかと思っている。More

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

長らく読んでいたのですが、Kotlin in Actionをようやく読み、写経などし終えた。 他にも同時にやっていたとはいえ、このときからすると時間としては結構長かった… ただ、Kotlin全体の形や、以下のような処理を書いたりしてというところが理解・発想できるようになったぶん、読んで全体を知ることはよかったかなと思います。 以下は、KotlinでSpekといった大きなライブラリを使うほどではないけれど、テストにコンテキストを持ち込みたい時なんかにプロジェクトに書いておくと良いのではないかな、と思うやつです。 KotlinだとWhenが予約語になっているので、Spekででもなのですが、Given/On/Itスタイルにすると良さそう。 すぐに書くことはできるものですが、一応、ここではライセンスをMIT Licenseにしておきます。More