Read “A Practical Guide to Testing in DevOps”

A couple of weeks ago, I read A Practical Guide to Testing in DevOps

The book explained and described DevOps x Testing with many references and keywords.

you can see why people struggle to understand where testing fits in a model that doesn’t mention it at all. For me, testing fits at each and every single point in this model.
> by Dan Ashby

Continuous Testing in DevOps…

In the book, we can see many words, beyond the team boundary. We can see explanations about separated test teams and activities in many traditional style world. But recent Agile and DevOps culture breaks the separations. It is the natural thing.

We can see some concrete steps about pair work and test activities. For example, first 10 min …, next 20 min is… etc. We can image how to work them in our activity quickly, I believe.

Comparing testing too deeply or too shallow also helps us.

The book is useful to understand recent development and testing culture. And almost stories were very proper for my current environment. I had some unknown words, but we’ve been working such things and knew the word and definitions.

I’d love to recommend this book to other guys who would like to catch up with recent development style include testing.


Read “Antifragile Systems and Teams”

I read Antifragile Systems and Teams. Entirely, this book is DevOps book, I thought. This book also short. So I just left some lines in this article and I’ll leave here.

Anyway, do you heard Antifragile? I hadn’t known the word before.

Let refer the Taleb’s word from a book.

“Some things benefit from shocks; they thrive and grow when exposed to volatility, randomness, disorder, and stressors and love adventure, risk, and uncertainty. Yet, in spite of the ubiquity of the phenomenon, there is no word for the exact opposite of fragile. Let us call it antifragile. Antifragility is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better”

As the word said, antifragile is anti + fragile. But it isn’t not fragile. It’s more robust and resilient thing. And this book tried to show how to build such systems/teams, especially software development industry.

Lately, I believe DevOps methodology became common. We can imagen agile, flexible, robust and autonomous things. And this book also challenges to show use cases and examples for it.

What I surprised was I saw QA(Quality Assurance) related engineers often appeared. I thought this kind of books shows some ideal story, but this book was more close to real DevOps story. I also read DevOps and Testing books as same as this book.

This book is too short. Only 20 pages in PDF and they were summarised good enough things. So, if you have an opportunity to read it, let’s read it.

See you happy DevOps? 🙂


プロフェッショナルSSL/TLS を読んだ。


楕円曲線暗号(Elliptic Curve Cryptography)の話なんかもでてきて、大学のころにやったことも含まれて良い感じだった。主にはセキュリティ関係のところを想像しながら聞いていた。



Read “Practical network automation”. It was for network engineers

I bought the book of Practical Network Automation when the book was discount.

The main topic is Ansible and Python code for network engineers who have few experience for Python/PowerShell. I expected more programming related stories, but it is a bit fundamental stuff.

BTW, when I saw some word such as “Software Defined Network”, “Open Flow”, etc, and it made me nostalgic… (My previous company and sort of my university age.)

iOS 11 Programmingを今更だけれど読んだ




iOS 11 Programming

iOS 11 Programming

  • 著者:堤 修一,吉田 悠一,池田 翔,坂田 晃一,加藤 尋樹,川邉 雄介,岸川 克己,所 友太,永野 哲久,加藤 寛人,
  • 製本版,電子版
  • PEAKSで購入する



Read “Mastering Blockchain”

One day, I encountered Mastering Blockchain. When the book was available with some discount, I purchased it and I finished reading it lately.

I was able to enjoy reading the book since I have some knowledge of distributed system especially the Byzantine General Problem in theoretical aspect and cryptography.

We can lean not only the Blockchain and its implementations but also the more fundamental knowledge such as what distributed system is and cryptography. It’s essential thing than concrete implementations. If the implementation is disrupted, you can implement other way or new way because you know the fundamental stuff.

I strongly feel again. Lately, academical/scientific stuff and industrial stuff become closer. For me, it’s very exciting things though.

I left my thought for the book which I’ve posted on Twitter.

Read a part of “Practical Monitoring”

I was interested in the book for a long time. The O’Reilly has published a part of the book and I also read it to know the book.

Practical Monitoring

Just I read only one section. I couldn’t more monitoring stuff in this book, but I got some antipatterns.

  • Anti-Pattern #1: Tool Obsession
  • Anti-Pattern #2: Monitoring-as-a-Job
  • Anti-Pattern #3: Checkbox Monitoring
  • Anti-Pattern #4: Using Monitoring as a Crutch
  • Anti-Pattern #5: Manual Configuration

When I read the above sections, I can imagine why they are the antipatterns. Some of them have similar issues creating the autonomous team.

In short, to scale the system, we must make the system automate. And the book should have many practices of the monitoring.

Anyway, we should take care monitoring stuff as well.




“理論”といっているのでどれだけ確立されたものかと見てみると、実証的なものが多く、”jobs theory”と強くいうにはまだのよう(ここは著者も言及してはしますね)。原書のタイトルを見てみると Competing Against Luck: The Story of Innovation and Customer Choice とあるので、個人的にはこちらの方がスッと中身も、読んだ後も馴染む感じがしますね。

視点を利用ユーザ、顧客に合わせ、彼ら/彼女らが何か進むために “何か” を雇用する。そういう考え方で物事を捉え、実装に落とし込んでいくという流れ。






また、アンチパターンとして、うまくいっているというものに対する誤謬(logical fallacy)を以下のように列挙していました。

  • 能動的データと受動的データの誤謬
  • 見かけ上の成長の誤謬
  • 確証データの誤謬

この本書の最後にあった、このジョブ理論によって期待されることは、マイクロサービスの文脈でよく言われるOrchestration vs Choreographyの話にも通じるものも感じましたね。

  • 意思決定の分散
  • 資源最適化
  • 意欲の向上
  • 適切な測定能力




Read “Software Design X-Rays”, measure code quality

This month, I read Software Design X-Rays and leave summary and my memos here.

The book shows us how to measure one of code quality and find hotspots, and how to fix or improve them. We also can learn some helpful git script to measure them quickly and get an opportunity to consider how to find/what kind of code is/will be hotspots.

We know some situations will be hotspot like:

  • Files/Classes/Methods which have a large number of lines
  • Files/Classes/Methods which have complicated logic
  • Files/Classes/Methods which change frequently
  • Files/Classes/Methods which are modified by many developers
  • Project structure is complicated

In this book, we can see them and suggestions how to improve them and real data from OSS projects. It was so interested in large-scale systems related talk.

Human memory is fragile and cognitive biases are real

The significant thing when we consider this kind of topic, we should mention what is technical debt. Technical dept depends on several situations. e.g. Business phase.

So, this book also mentions such thing and sometimes address the organisation itself. We must keep in mind what/when/which is suitable for our world.

Visualise codebase

The book tries to visualise codebase. The author develops and serves to measure and visualise codebase.
We can see examples from the site for some OSS projects such as .NET and Ruby on Rails. Hotspots have a large circle and red colour…

The next figure shows the Ebbinghaus forgetting curve where we quickly forget information learned at day one.

In measuring some metrics, indentation based complexity metrics was the most impressed thing. I also considered such thing and can agree with the way as simple measurement.

Not only coding

One of the interesting thing about this book is this book also mention about organisation and development process.

The data shows us no process, and complicated organisation structure leads hotspots. So, this book also tries to measure team oriented measurement and mapping codebase and organisation/team structure. In the mapping, the author considers boundaries in codebase and organisation base.

A common fifteen-minute coffee break is the cheapest team building exercise you ever get, and we shouldn’t underestimate the value of informal communication channels that help us notice new opportunities and work well together.

Detect Hotspot

  • How frequent each file changes
git  log --format=format: --name-only | egrep -v '^$' | sort | uniq -c | sort -r
git log --format=format: --name-only --after=2016-01-01 -- drivers/gpu/ | sort | uniq -c | sort -r
  • To show who commits and how many commits they are
git rev-list --count HEAD
  • Get authors
git shortlog -s -- .
git shortlog -s --after=2016-09-19 -- . | wc -l
  • Get the age of code
git log -1 --format="%ad" --date=short -- particular/file.path


The book is in beta yet. But it’s worth for Test/Quality related engineers and some managers and developers as well.

Recently, we can see frequently autonomous team and team autonomy related topics. I read “Designing Autonomous Teams and Services”を読んだ before.
Recent Agile, Microservices and other things step toward to autonomous thing. Personally, the way is the lovely thing.





そういえば、オライリーから無料で配布される電子書籍が情報が整理されていて良い本であるように思える(ここだと、Chaos EngineeringとDesigning Autonomous Teams and Services)のですが、これを無料で配布できるって驚き…

programming language





Software Testing

Software Development

Service Development



すこし前に読んだWriting Great Specificationsを頭の中整理のためにもう一度読みたいな。多分、必要になるので。