read “オブジェクト指向入門 第2版 原則・コンセプト”

KazuCocoaコメントをどうぞ

積読になってた オブジェクト指向入門 第2版 原則・コンセプト を、少しきっかけがあって主に11章付近の契約による設計付近を読みました。

内容自体は、ある社内勉強会で得たこと中心でしたが、幾つか自分のためにメモ。

  • ホアトリプル(Hoare triple)による正しさの公式
    • {P} A {Q}
      • P: 事前状態、A: 処理、Q: 事後状態
  • 防御的プログラミングと、契約によるプログラミングの違い
    • 前者は、他を信頼しないことを前提に入力値などを検査していく
    • 後者は、契約により表明されたことを信頼し、過剰な防御は行わない。
  • 冗長な検査は、ハードウェアは経年劣化などがあって時間によって変動があったり、例えば電気的な干渉などがある。そのため、電気的なシグナルの送り手と受け手の両方で整合性の検査を行うことはよくある方法。ソフトウェアは、何も経年劣化するようなことはないし、電気的な関与を受けるといったこともない。例えば sqrt(a) というメソッドを一度ちゃんと実装すると、それが1年後に挙動が突如変わる、ということはない。(実行環境の変化やシステムが更新されるとか、そういう外的な変化はないものとする)
    • こう見ると、ハードウェアは過剰な防御をしているようで、実は冗長検査と言いつつも、特別・補足的な確認として利用されていることになる。
  • require/ensureによる事前/事後の表明
    • これは表明のサンプル
  • 表明するモチベーション
    • 正しいソフトウェアを書くのを助けるため
    • 文書支援のため
    • テスト、デバッグ、品質保証をサポートするため
    • ソフトウェアの耐障害性(fault tolerance)をサポートする

最後に

ここら辺を学んでいると、Elixir/Erlangをやっていると、関数に対するマターンマッチや when によるguard clauseを思い浮かべました。Swiftでは where みたいなやつですね。

でも、この青い辞書はとても厚い…

read “The Way of the Web Tester”

KazuCocoaコメントをどうぞ

The Way of the Web Tester を読んでみました。

私が読んだ時は、まだBeta3でした。最近、Beta4が出て、JSによるテストコードの話が追加されている状態でした。

この書籍は、自動化されたテストを書くための、テストエンジニア向けの入門書という感じです。内容はいかが大まかなところです。

  • Unit/Integration/UIのテストピラミッドの話
  • Unit/Integration/UIのテストコードの書き方(Rubyを例に)
  • コラムとして、例えばrecord/playbackの使えないところ、など

全般的にWebだけの言及なので、モバイルに関しては対象外でした。Selenium系の書籍のようにツールに特筆してはいないので、そういう意味では確かに全般的な入門書という感じです。

ただ、コードの書き方などの話になるとリーダブルコードの内容や実装に近いところの話が含まれてきていたので、そこらへんの実装よりを詳しく学びたいとなったら何かWebフレームワークを使った実装とそのテストコードを書く、というところを開発者向けのなんらかの書籍など見て行う方が良いかもしれないです。

ある程度、書籍などで学んでいたり実装を経験した人からすると確かに入門的なものなのでザーッと読み飛ばしながらコラム中心に読んで終わり、となりそうです。

reading “Advanced Software Testing – Vol. 3”

KazuCocoaコメントをどうぞ

ISTQBのTTA(Technical Test Analyst)がどのようなことを学んでいるのか、を知るために読んでみました。

Advanced Software Testing – Vol. 3, 2nd Edition: Guide to the ISTQB Advanced Certification as an Advanced Technical Test Analyst

ざっというと、様々なソフトウェアに関するメトリスクやその計測方法、カバレッジの話、さらにはテスト自動化に関する話までありました。

内容として、これはゆるSoftware Engineer in Testと呼ばれるような位置の人は頭に入れておくべき事柄、という感じでしょうか。

data driven や keyword driven なテストコードの話とか、静的/動的テストの分け方やその詳細への落とし込み、様々なコードカバレッジの定義やその役割など。

中でも、コードカバレッジをはじめとした様々なカバレッジ(それこそ、変更量とか含む)の厚みはすごくページを割いていて、その計算(アルゴリズム)の理解までこの書籍でできる感じです。

ただ、これだけできても十分ではなく、ここと実際の経験(開発など)が合わさって相乗効果を発揮する、という感じでしょうか。

効率性のテストの中で、以下のように数多くの xx testingという呼び名があったことは今回初めて気付きました…

  • Load Testing
  • Stress Testing
  • Scalability Testing
  • Resource utilization Testing
  • Endurance or soak Testing
  • Spike Testing
  • Reliability Testing
  • Background Testing
  • Tip-over Testing

[Elixir]ets vs Agent

KazuCocoaコメントをどうぞ

on-memory vs processであるets vs Agentに関して、過去に以下の議論があったのでメモ。

https://groups.google.com/forum/#!topic/elixir-lang-talk/RyhiBcD_Zvw

以下の回答は、Elixir in Actionを書かれたErlang developerの方

There are some gotchas with ETS:

  • No garbage collection of individual rows. Memory is released when the owner process dies (and there’s no heir process).
  • Data is copied to / from ETS table. Usually not a problem, but might be when individual rows are huge.
  • Changing individual rows is concurrent safe. Changing many rows, or read-modify-write operations aren’t. You need to synchronize through some process(es) if you want to do that. Even when modifying individual rows, race condition may appear if two processes try to modify the same row.

That said, there are some occasions where I find ETS useful:

  • A structure which multiple processes access frequently (essentially, a shared state). Using processes for this may introduce a single process bottleneck, while ETS allows processes to read concurrently.
  • An in-memory store for preservation of a state which should survive a process crash.
  • Optimization of a HashDict. Having two element tuples as rows, and if both elements are small in size, ETS might work faster than HashDict, being implemented in pure C. Should be used only sparingly.

As said, it’s hard to give general conclusions. If you have multiple processes which need to share state, and access it frequently, then ETS seems like a good candidate.

ここまで。
違いがわかって良いですね。

read 「料理のアイデアと考え方」

KazuCocoaコメントをどうぞ

料理のアイデアと考え方 -9人の日本料理人、12の野菜の使い方を議論する- を読んだ。

日本料理を専門とする料理人が、どのような考えで、何を狙って、技術/表現を使ってデザインして料理を造るという一連の流れを知ることができました。やっぱり、ソフトウェア開発など含め、達成したい意図を落とし込む、というところは同じものがありますね。

面白かったのは、この中で各々の対談の記録を形態素解析などの分析にかけてどういうものが日本料理として大事にされているのか、という思考パターンの分析などもしていたところです。世界の地域ごとの料理で何が大事にされているのかなとが分析、可視化されて面白かった。

書籍では幾つかの食材をピックアップしていたのですが、ナス、トマトのところで取り上げられていた料理たちが個人的には美味しそうだった。ので今度作ってみよう。

Download precompiled package and execute library with its binary

KazuCocoaコメントをどうぞ

I’d like to run http_proxy without install package management for Elixir as portable aspect.
So, I prepare simple shell script to help the problem.

It is that downloading precompiled package and unzip it, run http_proxy with the precompiled mix.

Example

https://github.com/KazuCocoa/run_http_proxy

minimal ruby client for WebDriverAgent

KazuCocoaコメントをどうぞ

WebDriverAgent developed by Facebook is one of WebDriver tool which run on iOS.

Previous some posts, I investigated this module. And now, I develop minimal wrapper Ruby cli client to help some operations.

I implemented some operations such as taking screenshots, getting source tree, status about the driver and install arbitrary app to the launched iOS target and get its session id. This minimal library will support some tasks for handling iOS applications.

This library does’t have concrete plan to develop as testing library for WebDriver for now. Just helping some operations against WebDriverAgent.

If you’d like to run tests via WebDriverAgent, please use Appium and it’s ruby binding. Because Appium will support WebDriverAgent in the future. (https://github.com/appium/appium-xcuitest-driver)

some references