ビヨンド ソフトウェア アーキテクチャをずいぶん前に積読にしていたので読んだ。 読む前はシステムアーキテクチャの話だと思っていたのだけれど、フタを開けるとソフトウェア開発に関する全般を扱っていた。単にシステム開発に限った話ではなく、ソフトウェア開発する対象や、マーケット、人といった様々な要素に対するアーキテクト、つまり様々な構造にまでその話の範囲を広げていた。 ソフトウェア開発と人の関わりから始まり、ソフトウェア開発とマネジメントの話(ここには、プロダクト開発におけるコンセプト提案などの重要なところも書かれていた)に入りながら、だんだんとシステムによっていく。作るシステムのマーケティングの話やテクニカルな話。もう少し進むと、ログやセキィリティ、リリース、変更管理なども取り扱う。 このように、ソフトウェア開発においてシステム自身の狭義のアーキテクチャではなく、全般を扱っている内容となっていた。 そういえば、私は大学なんかでプロジェクトマネジメントを少し学んだり、話を多く聞かせてもらったのだけれど、こういう全般的な話を受けたなーと思いながら読んでいた。社会人になって、経験も多少積んで、その上で読むと頭の中を整理したり、そういえばこれも必要だったなと思い出すことができた。 最後に。この本で印象的だったことは、品質保証という役割が度々出て来たことと、その活動の範囲の広さをちゃんと説明しているところだった。More
Author Archives: KazuCocoa
Read “Functional Programming: A PragPub Anthology”
Functional Programming: A PragPub Anthology を読んだ。まだβだったけれど、内容はだいぶまとまっててあとは微調整して発売という感じを受けた。 The Functional Paradigmから入り、Scala、Clojure、Elixir、Haskell、Swiftと関数型というテーマに絡めたそれぞれの言語の特性に触れながら話は進む。それらがひととおおり終わり、考え方を経験した後、Going Deeperということでそれらを再び題材に、より言語毎の特性、テスト(コード)の話、タイプシステム、The DCI architecture、そしてLuaと理解を深めていく。 この書籍をまるっと読むと、いくつかの言語から関数型言語、関数型な考え方に触れ、それらを学ぶことができる。さらには軽くそれらに触れることで、いわゆる写経もやりながら理解を深めることができるので、とっかかりとしても有用な内容だった。特に前半は、その言語に触れたことがある人からすると読み物的な内容に見えるので、考え方を整理するという形で触れることができると思う。 個人的にはElixirやSwift、Testing周りが関係が強いので、そこら辺は特に楽しむことができた。 例えば、ElixirやSwiftのProtocolの話。SwiftではProtocolはGlobalスコープに対して定義される一方で、Elixirでは特定の型に対して定義することができる。そのため、影響範囲を限定することができるのでより安全に利用することができるという話も。 テストの話としては、Elixir、Haskellが題材になっていてよかった。Elixirの話では、TrueStoryを題材にして、可読性の高い(テストしたいシナリオ・ストーリーを理解しやすい)テストコードの書き方に対しても言及している。その中で、パイプ演算子を使った関数型としての書き方に触れながら話を進めている。 Haskellでは、型システムのほか、C言語で書かれたコードをHaskellでラップしてテストコードを書いていく方法を載せている。ほかの言語をテストするためにHaskellを使う形は興味深かった。 やー。思いの外、Elixirに関する話が多かったのとHaskellを使った説明も多く、個人的にはそれだけで満足度が高かった。Haskellはがっつり触れたことはなく、考え方を学ぶために触れている側面が強いけれど、触れる機会が増えてきたらまたこの書籍でさっとHaskellは頭の中を整理したい気分。More
Classification Treeの歴史
知らなかったので、メモMore
[iOS]What’s new Testingを見た
What’s new Testingを見た。 https://developer.apple.com/videos/play/wwdc2017/409/ 見ている途中でいくつかメモしたので、その記録として… multiple appのテスト、URLを引数で与えることできるのね Accessibility Dataのところで説明しているsnapshot、WebDriverAgentが使っているやつぽいな おー。いちいちsnapshot取得する必要がなくなるのか。実行時間改善しそう 要素の検索で全捜査でなくて最初にマッチしたものだけさっと返すようにした、という話だけれど、ようやくという感じ。 ここら辺は元からそうなのでそうよねという感じだ。 ここはどこまで厳密に書くかはどれだけ内部実装と結合を強くするかの問題ですね。Espressoでも同じ問題をもつ。 地味に嬉しい Activity styleの書き方、Cucmberとかイメージすると良さそう。stepsにいろんな処理を入れて、シナリオはstepsを並べて記述するような感じが使い方として近そうだ。 非同期の奴も良さそう。XCTestなので、XCUITestでも使えるし。 snapshotのところはほんといろんな3rd partyも恩恵受けるだろうし、良いことづくしな気がする。けれど、これはXcode8でないと使えないOSテストするときは恩恵受けられないので、完全に恩恵を教授できるのは数年後かな… Xcode9のいくつかの機能、Xcode9以前でも使えると恩恵大きくて良いな…More
[ReactNative][Test]Detox instead of Appium
2017/06/08現在 過去、ReactNativeに対するUITestに関して書いていたのですが、今の段階ではAppiumよりはDetoxを使うほうが、JSを経由したテストツールとしては良さそう https://github.com/wix/detox EarlGreyも参考にしている所とかあり、より安定したUIテストを実施するには現実的な気がします。 Androidのサポートも計画されているので、必要に応じてコミットしたいですね。 参考: [ReactNative][Appium]testIDの振られ方More
read “ZERO BUGS シリコンバレープログラマの教え”
ZERO BUGS シリコンバレープログラマの教えを読んだ。 タイトルと、その副題の高品質なコードを書くための物語というところですね。 エッセイ形式なので、全体を通して、物語を楽しむように読んでいきました。 わかる、あるある、なるほどなーというようなところが色々あり面白かったです。 「すべてのエラーは、あなたが最後にプログラムを変更した場所から3行以内にある」 by Joe Armstrong の引用。 ドナルド・クヌースの、ソースコードがドキュメントになるような文芸的プログラミング(literate programming)に対する考え方。 トランザクション処理のACID(Atomic, Consistency, Isolation, Durability)への言及。 人月の神話と、小さなチームならどんな方法論も上手くいくという話。これは、プログラマが習熟すれば、自分自身を実質的に管理できるようになるから。 Linuxカーネルのコードスタイルにある、それぞれの関数のすることは1つのことだけという姿勢。それとそのコードたちがPolymorphism、オブジェクト、関数型プログラミング、メッセージパッシングの全てをCで実現していること。 OpenBSD開発における、1箇所の修正に対して全体を見直すという、局所と全体の繰り返しのループ。 Erlangのモジュール同士のメッセージパッシングの形が、アラン・ケイがオブジェクト指向で表現したかったアイディアの理想形の1つであるという話。 などなど。 私の専門は品質/テストにあたる分野ですが、そのような立場の人も様々な領域を学ぶ必要があるのと同様、こういう話も知ってもらいたいですね。 「ソフトウェア品質の重要性が広く理解され、もはやこの仕事を能力のないテスターにアウトソースできなく」だそうです RT ソフトウェア開発におけるソフトウェアテスト（2）–開発者とテスターの違い https://t.co/E3J0PeQs4q @zdnet_japanさんから — Tsuyoshi Yumoto (@yumotsuyo) June 4, 2017More
read “実践 日本人の英語”
実践 日本人の英語を読んだ。 3作目。 ちょっとしたtipsとして読める点が良いですね。その中で、自身が出来ていること/いないことを確認しながら頭の中に印象付けることができている感じがします。 そういえば、so/very は同じ副詞として使えると思っていたのですが、違ったのですね。お恥ずかしい。 so…that… の形が必要で、感嘆詞などはこのthatが省略されているから類似用語として使うことができる。一方、この that… が使えないような文章の場合はsoではなくveryを使っていくべきという。例を見ていると、感覚的には正しく使えていたみたいですが、運が良かっただけぽい。 接続詞のつながりも。so, since/because, as, for, and 。因果関係の繋がりで、 so が強く、 and がよりカジュアルな弱い感じになるとか。 as/for は書き言葉のような強さがあるみたい。これらはあくまでも論理的関係性だけを指す模様。 普段、 and と since, so をよく使うなーと読んでいたのですが、所々、因果関係が弱い(必然性がない)のに so を使うところとかちらほらあった気がします。 and と since はそこまで外れた使い方はしていなかったぽい。最近。 あと、小技として紹介されていた副詞の位置、接続詞、分詞構文の使い方は感覚的にやっているところもあったけれど、色々と説明を読んで入るとこうする方が良いのかとか気づけてよかった。 色々と自分のケアが届いていないところだけれど、意味としては大事なところに気づかされるというのが良いですね。この本。 反射的に英語が出る、出すことができる語彙/文法はまだ限定的だけれど、それがスラスラ出るように継続して学んでいきたいですね。More
“~ility testing”, not “no-functional testiong”
“~ility testing” is preferred than “non-functional testing” since “non-functional testing” indicate only others. I agree with the opinion because “non-functional test” already have many kind of test.More
UberがRuntime Validationを実現するRaveのv2を公開していた
HOW UBER ENGINEERING VERIFIES DATA AT RUNTIME WITH THE ANNOTATIONS YOU ALREADY USE を公開していた。 彼らが、Androidでよくある問題(NPEとか)に対して、model層の例えばAPIの結果をvalidationし、その結果が期待していないものなら必要な例外を投げて、意図しない値を不用意に使わないようにするとか、NPEになるようなExceptionの発生を抑制してしまおうとか、そういう話のようですね。この判定はRuntimeに行われます。 それにより、意図しないデータが帰ってきたとか(例えばnonnullなはずなのにnullがAPIで得られたとか)に対して必要な処理を実施できるようになる、と。 ( reference from: https://eng.uber.com/rave/ ) https://github.com/uber-common/rave が対象となるリポジトリ。 Ecceptionを一様にCrashlyticsにnon-fatalで送るとか、クライアントのエラーログをサーバに蓄積するとかも良いですが、こういう形でそのエラーを区別できるようになると監視なども捗って良さそう。More
Netflixの複雑なマイクロサービスに対するテスト自動化
とても面白い。 Netflixの、マイクロサービス環境下におけるテストの複雑さを解決しようと取り組んでいたことの内容と、その1年の成果が書かれている。 here 読んでいてもとても面白く、テストエンジニアという立場からすると純粋にとても挑戦的に面白い内容だと思った。 また、社内の利用をより簡単に、利用者に負担をかけない取り組みも良いですね。 カッコ良い。More
