Building Evolutionary Architectures: Support Constant Changeを読みました。 “Evolutionary”というものをどう表現しているのか、そのケーススタディを知ってみたいと思ったからです。 Evolutionaryとは、小さく変更をくわえながら、フィードバックループを回し、どのようにシステムを開発していくかを学ぶというところをいっているようです。その要素としてCI/CDの環境を作っていたり、例えばMicroservicesなどの話が出たり、チーム構成の話にも及んでいるところがあり、なかなか面白いものでした。チームの話だと、そういえば”Culture”という言葉も度々出てきたので、そういう環境づくり含めた全体の、文字通り”システム”（複雑系）を対象として設計するというものという印象を持ちました。 Fitness Functionと表現している、拡張していくような機能を対象に、その機能を壊さずに変化させていくか、というところでどのようなプラクティスがあるかとか書かれていました。そのように変化させていくことを”incremental change”というような表現を使ってたりします。Microservicesの文脈で度々目にするConsumer-Drivern Contractsの話も出ていました。この書籍を読んでいると、様々な小さなチームの責任範囲が重なる(もしくは重ならない)、システムの境目となるところを横断的な、例えば横断組織としてのテストチームがケアする、などにも言及していて、Consumer-Drivern Contractsが単なるツールの話ではなく、むしろそういう境目に対する話に絞っていたのはよかったです。（Pactガーというような言葉だけで終わらなかった） もちろん、そういうテスト/品質をみる人は各々の責任領域ベースでのチームにいたりしてるけれど、横断的な人の役割などを別途明言しているところがよかったですね。 Re-engineering Legacy Softwareなど読んでいると、色々なところで話が重なっているところが見えたりするかと思います。また、Servive Oriented ArchitecturesやEvent Driven Architectures、Service Based Architectures、Serverless Architecturesなどのツール側の設計の話もありました。これらの説明、システム間の関係、要素技術などを整理してたりします。ある程度知ってる人には良い要点整理になるかと思います。 Amazonの有名な2枚のビザの話もコラムにありました。 Each team is cross-functional, and they also embrace the philosophy of “you build it, you run it,” meaning each team has complete ownership of their service, including operationalizing it. ということをいっていて、それを最適化するような活動までを責任持つことを意味すると書いているところが個人的には好きだった。…More
Tag Archives: book
[book]Read Chaos Engineering again
I read the Chaos Engineering again. This book also. And I chatted a little bit with one of my friends on the Twitter. So, I also put the conversations here. またChaos Engineering 読んでるけど、fault injection testing との違いも書いてたのね。イメージとしては、探索的テストに近い仕組みっぽい。 — KazuCocoa (@Kazu_cocoa) November 1, 2017 ICST 2016のIndustry TrackのNetflixの方の発表で"Chaos Engineering"が初耳でした。昔からFault injectionという用語はあったけど、彼らがFailure injection testingと呼ぶのは何かこだわりがあるのかな? — Keizo Tatsumi (@KeizoTatsumi) November 1,…More
“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
[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
「The Art Of Software Testing 3rd Edition」を読んだ。
The Art Of Software Testing 3rd Editionを読んだ。 翻訳がされている2版との、大きく差分になっている箇所を主に。その主に増えていたのは、Agileの話とモバイルの話。3版であるこの本は、2011年に出ているので、モバイルが流行りだした前後になるのでしょうか。 Agileは、Agile Manifestoや、XPの話が紙面を割いていたことが印象的でした。モバイルは、Connectivity、Diversity Devices、Device Constraint、Input Devices、Installation and maintainceといった特性から入り、実機などの話や挑戦的なところの話が含まれていた。 いずれも、私個人の経験としてはずれていない話だったのですんなり読むことができた。これは、なるべくは特にテスト界隈に触れる人たちには読んで欲しいものの1つですね。 XPの話がこのソフトウェアテストの話にもでるように、やっぱり技能としてはプログラミング能力の必要性は高いのだろうな。More
~ my tech diary ~ 