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.

Advertisements

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”
> https://en.wikipedia.org/wiki/Antifragile

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」を読んでHTTP/Sの、特に暗号周りの基礎を学ぶ

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

大学時代に鉄板とされていたマスタリングシリーズの話題がでてきたりと、おぉという良い驚きの感じでした。ネットワークに関する日本語を真面目に学んだ時によくお世話になりましたね。。大学後もいくつか大学時代のものにお世話になるのですが、これはよく見ていましたね。

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

私はこのてのプロトコル実装自体には関わっていないので、基礎を丸っと復習したのと、OpenSSL周りの話を熟読して、他はさっと内容を学ぶ感じで終えました。

今やインターネット、特にHTTP/Sは生活から切り離すことができないところまで浸透しているので、エンジニアであれば基礎としてこれは学んでおいて損はないだろうなーと感じました。

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を今更だけれど読んだ

そういえば、半年以上はもう経ってますよね…

飛行機の待ち時間とかにざっと読んだり、所々、きになるところは写経しながら読んだ。知っているところ、知らないところと様々あったのですが、あの時期にこれだけのものをリリースしたのってやっぱりすごい…

個人的には、Decodable付近の話が一番実際の仕事にも結びつく感じでよかったです。PDFKit付近は、簡単なアプリ作成も兼ねて作ってみようかなと思いました。技術書系も大体はebupで購入してGoogleBooksにあげている生活なのですが、たまにPDFのものを手に入れることもありますし。そんな時に自分で作ったものでサクッと読むとかやっぱり面白いですよね。(そこまで簡単にPDFを組み込める、というところが特に面白かった)

iOS 11 Programming

iOS 11 Programming

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

そういえば、Metalもそうだったんだ、確かにというところが多くてとても為になりました。

ありがとうございました。

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.

“ジョブ理論”を読んだ。原書タイトルの方がしっくりくる内容だった。

ジョブ理論を読んだ。確か、昨年の間に買っていたのだが、Kindleの整理で見つけたという感じ…

中身に関しては、問題発見自体の難しさ、捉えにくさに対して「ジョブ」という表現を持ち込んだ、という感じのもの。それを様々な実例から実証している。大学時代に学んだ教授のもとで耳にタコができるくらい?よく言われたことを想起した。つまるところ、一番難しい、問題を発見し、定義する。それを行う1つの手法という感じですね。

“理論”といっているのでどれだけ確立されたものかと見てみると、実証的なものが多く、”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 https://codescene.io/ 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

Conclution

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.

2017年に新たに読んだ書籍群を振り返って

毎年、2015年に新たに読んだ書籍群を振り返って2016年に新たに読んだ書籍群を振り返ってをなぞって。

今年くらいからか、LeanPubだったり、PragaticBookshelfといったところから購入する本が増えてきたように思える。β版のうちから気になるものを買っておけば、すこし安くてに入るというのもあるかも。頭でっかちになるつもりはないけれど、いろんな人と話すときにこういう整理された情報源から話を引っ張ってこれるとだいぶ会話が楽なのですよね。海外の人と対話するときの表現とかも学べますし。

そういえば、日本国外の人と活動する頻度が上がってきたことにより、異文化交流などの書籍も読んだりするようになりましたね。また、それに伴って専門性のある言葉に関しては特に、日本語を主に覚えていたものを英語に慣れさせるために英語の記事をあたるとか、そういう類のものも増えてきた気がします。ここ半年くらいは特に。

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

programming language

Swift

Kotlin

Ruby

Elixir

Software Testing

Software Development

Service Development

Other

end

そういえば、ここ最近でElm系書籍を目にし始めたので驚いている。。。(ただ、最近の言語系は書籍よりも公式なWebページが充実しているのでそちらで触れる方が良いですよね)
JavaScriptとPython、OSS活動で必要になってきているのでどこかでガッと学んでおこうかな…
すこし前に読んだWriting Great Specificationsを頭の中整理のためにもう一度読みたいな。多分、必要になるので。