Testing and Securing Android Studio ApplicationsのKindle版が安かったのと米国レビューもそこそこあったので読んでみました。あと、TestingとSecuringを同時に扱っていたので、基礎的な知見もまとめられているものと期待して。 結果的には、出版日も2014年8月とそんなに古くないので、入り口的な書籍としては良いと思いました。ツールやコードの話もありますが、まだ古くて使えない、というレベルのものではないですし。 内容的には、intentに対するUnit testレベルとInstrumentationを使ったレベルでのテスト方法が、個人的には何気に参考になりました。 以下は、私の備忘録込みでつらつらと… 第1章では基本的なソフトウェアセキュリティ全般の話。 Access control Asymmetric cryptography Authentication Availability Brute force Cipher Code injection Confidentiality Crack Decryption Denial-of-service(DoS) Distributed denial-of-service(DDoS) Dictionary attack Encryption Hash function Hijack attack Hypertext Transfer Protocol Secure Integrity MD5 Man-in-the-middle attack Password Phishing Risk SHA1 Sniffing attack Spoofing attack Threat Vulnerability このうち、Threat、Vulnerabilities、risksに関してはさらに言及されていました。 Threat…More
Category Archives: books
「アンティキテラ 古代ギリシアのコンピュータ」を読んだ
アンティキテラ 古代ギリシアのコンピュータを読みました。 私はこのアンティキテラの計算機の存在を大学時代に教授から聞いて知りました。 確か、アリストテレスの話の時に合わせて聞いた気がします。というのも、品質(Quality)に関する概念は、古代ギリシア哲学 アリストテレスにより考えられ始めたことが歴史上初、とされています。その話に合わせてこのアンティキテラの計算機の話も少し聞きました。共に古代ギリシャが共通ですしね。 のち、教授の退官時にもこの計算機の話が出てきて、頭に残っていたのでいつか読もうと積読していました。ちょっと、技術書から離れた小説を読みたくなって、ふと積読から掘り起こしたのでさっと読んでしまいました。 アンティキテラのコンピュータは、現在知られている中で最古のコンピュータです。2006年のNatureに正式に発表されたことで、その”最古”というものは確実なものになりました。そのアンティキテラのコンピュータに関する史実を、1901年にギリシャのアンティキテラの海底から引き上げられたところを契機に調査する人、歴史的な背景など含めて追っている本です。この本の原書が出版されたのが2008年くらいなので、そこからさらにこの計算機に関する調査が進んでいるかもしれませんが、2008年までの流れで止まります。 最終的にはこの歯車仕掛けのコンピュータが、いつ、何のために、誰によって作られたのかを、実際の調査結果をもとに結論付けていくという本筋なのですが、まだ解明されていない箇所もあるのですべての答えがあるわけではありません。一方、単なる史実の追いかけではなく、その結論の根拠になる数学的な説明や調査を行う上ででてくる技術に関しても大まかに触れているので、推理小説を読んでいるようにも感じます。 なお、この書籍におけるコンピュータとは、ドロン・スウェード氏の定義に従い、数字で答えが示される計測器を指しているそうです。 知識は巨大なジグソーパズルに似ている。誰かがピースを1個どこかに置くと、自分が置くべき場所もわかってくる。 デレグ・デ・ソーラ・プライス 紀元前の頃のギリシャには、後のルネサンス以降のような歯車仕掛けの機械を作る技術がすでに存在していた。争いでそれらが失われたが、それが暦としてレバノンへわたり、イスラムなどの中東で生きた。そして近代になるにつれてようやっと技術的にも復活してきた。そんな史実をみると、コンピュータに関わるものとしては純粋に面白さがありました。 アンティキテラの機械から、その次に知られる最古の歯車付き器具まで、一千年以上時代の開きがある 太陽と月の関係。太陽を入力に、天球にある月の位置を示す。コンピュータープログラム。 パーキンソンの法則、プライスの法則 放射線炭素年代測定法による調査 30個以上の歯車により作られた機械 ライト、フリースによる機械系としては忠実に再現されてきた模型 アルキメデスの影 SFや推理小説好きの人にはオススメな一冊です。あと、こういう書籍は直接技術には関係しませんが、こういう方面の人と会話する上では良い雑談のネタになるし、考えの視野が広がって面白いですね。More
「実践テスト駆動開発」の積読をようやっと読んだ
実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てるを読んだ 有名どころの良書なのですが、積読で放置してしまっていたものをようやっと読みました。 事実が変わったときは、私は自分の考え方を変えます。あなたはどうしますか? ジョン・メイケード・ケインズ TDDにより設計や実装が洗練されてくる話を丁寧に書いています。また、テストコード自体の役割、良いテストコードに関する言及もあります。時刻や外部システムをモックしたり、それらの責務をどのように切り離すか、という話も書いています。 依存性を切り離すこと、テストコードに意味を持たせること、テストコードからテスト対象の関係性を想像できるようにするなど、複数人で開発する上で正しく開発するためのテストに関して言及しています。 テストコードを少なからず書く人は必読な位置付けですね。早い段階で読んだ方が良い感じです。今の段階で読んで、テストコードに意図や実装コードの説明を載せていくとか、そこまで考えることが重要だと改めて感じました。 例えば、処理の順序が大事でないなら、@Afterやexpectationには順序を与えずに独立させて複数メソッドを書き、実行させるとか。setUp()を1つですべての初期化を書くのではなく。 可読性の高いテストコード 何をテストしているのかを理解しやすいタイトル、内容 テストコードの合理化 何を確認しているか(どうやって、よりも、何を) 少ないテストケースで密度の濃いテストが実施できているか 複数のFeatureを1つのテストに含めすぎるのではなく、1つのFeatureのテストを少ないテスト数に凝縮していく、という感じ とかとか。最後のあたりでは、テストをよりよくするためにDBが絡むテストや、非同期、揺らぎのあるテストの話なんかがありました。 依存性注入(dependency injection)をぼんやりとしかわかっていないので、次はそこを学ぼうかな。 そういえば、テストの話でよく テスト自動化を促進するなら、どこから実施しますか? と聞かれることがあります。その時、テスト自動化のしやすさとか、そういう話はありますが私はずっと 境界となる箇所から始める と答えています。これは、テスト対象の境界が壊れたら、その対象に関係する全てが壊れる可能性があるからです。 昨今、Microservicesと叫ばれたり、Webhooks、Web APIを使って複数サービスを1つの大きなサービスに見立てるという風潮があります。その場合は特に、その境界となる動作が壊れるとすぐさまシステムは壊れることは想像しやすいと思います。そのため、私は境界となるところのテスト自動化から手をつける、と伝えてます。 その考えがこの本でも早い段階で書かれていて、とても共感できました。 ちなみに、GUIを持つアプリだと、人との境目でまずは用意する方がよいかなという立場です。過度な量は無いことは前提です。10分かからないくらい範囲でとか。そのあと、高速なUnit test、Integration test、としていく、という感じでしょうか。SOAやMicroservices的な組織構造を持つチームであれば、Integration testの持つ責任が大きくなるでしょうので、そこは大変だけれど誰かが増やさないといけないですね。Androidだとespressoとかがその位置付けになれると感じています。 iOSはどうだろうか。More
システムテスト自動化 標準ガイドを読んだ
この土日は積読の消化をしようと、システムテスト自動化 標準ガイドともう1冊読みました。ここではシステムテスト自動化の本を残します。 このTweetの通り、内容は システムテスト に限りませんでした。個人的には システム は入れなくても良かったのでは・・・と思いました。 実際に自動化に取り組んでいたり、代表的なテストの書籍を読んでいるとそうだよな、という感じで納得できる内容が丁寧にまとまっている感じでしょうか。特に、キャプチャ&リプレイの話だったり、保守しやすい形、自動比較の話なんか。 今、第4章の自動比較、検証が個人的に今悩んでいます。特に、モバイルアプリではViewに対する評価を、単なる表示される要素の確認以上しようとすると画像比較以外できません。その画像比較は最終的には人の目に頼らざるおえないので、時折漏れが発生します。そのため、人目で見ることを前提に、気づきを得られるような施策を打つことはしますがそれ以上どこまでできるか考えます。 これ読んでて思ったのですが、なんだかんだで私はデータ駆動、キーワード駆動のテストまで実装していたのですね。More
『リッツ・カールトンが大切にするサービスを超える瞬間』を読んだ
リッツ・カールトンが大切にするサービスを超える瞬間を読みました。サービス産業におけるサービスの提供がどんなものか、サービスの品質をどのように保ち、より良くしているのかという仕組みに興味があったので、パラパラとめくる感じで読んでいきました。 大事そうなところをさっとまとめると、以下のようなものでした。 従業員も顧客同様の立場で接し合うことで、どのようなサービスがより顧客に価値があるかを考えられるようにする チームワークの良さがサービスの良さにつながる SQI(サービス・クオリティ・インジケーター)を計測、再発防止に取り組むことで日常的に高価値のサービスを提供できる体制を作る 会社の哲学を浸透させる 抜粋 いろいろまとめると長くなりそうなので、いくつか抜粋するにとどめます。半日かからないくらいでさっと読めるので、読んでみると良いかもしれません。 従業員を”内部顧客”と呼び、同じ目線でお互いを理解しあい、心から尊敬しあう リッツカールトンのサービス哲学 「明日はまたどんな感動があるのだろう」と思っていただけるようなサービスが提供できているかどうか 紳士淑女であるお客様に仕える私たちも紳士淑女である We Are Ladies and Gentlemen Serving Ladies and Gentlemen みんなが常にお客様の視点に立ったサービスを心掛けている 会社都合のシステムからは感動は生まれない チームワークの良さが最高のチームをつくる 会社の哲学はクレドとして共有される クレドは会社の哲学や、従業員の行動指針 クレドは時代に合わせて変化する クレドを自分と同じレベルで共有できるかが最上位の優先 同じ結果を出すためにマニュアルは必要 ただし、「ああしなさい、こうしなさい」ではない サービスで重要なことは高く感性を共有すること 技術は訓練できてもパーソナリティは訓練できない サービスを提供するひとは ジャズプレイヤー マニュアル通りで済ませるのではなく、より良いことがあればそれを実施できるように ホスピタリティ(おもてなし)産業 SQI(サービス・クオリティ・インジケーター) 毎日の仕事やサービスを提供する場面で起きてくる 欠陥事項、失敗事例、問題事項などを一つ一つ数値化して、記憶に残す作業。 これらは収集され、同様なことが再現しないように内部プロセスが見直したりされる。 締め サービス産業としては、例えばWebサービスも重要な点は共通しているところが多いです。何かサービスを創り出す技術が高くとも、サービスとして価値を出せなければ消えていくだけです。 こう考えると、SQIのような仕組みを組織全体として循環させることは非常に重要だと痛感します。技法的な文言はこのSQIしか書籍にでませんでした。これからも、科学的なアプローチをあげた場合、SQIは大事な要素なのだと見て取れます。 Webサービスの現場では、テストエンジニアやQA的な役割に責任を持つところはまだ少数だと思います。が、これから広がっていくだろうし、そういう人たちの活躍が会社の成長を、サービスを創り出すエンジニアやディレクター、営業の方々と相まって後押しするものになるのでしょうね。 頑張ろう 蛇足 こういうサービス産業のおもてなし、経験できるときに経験したいですね。サービス的な面白さがありそう。More
『武士道』を読んだ
武士道の根本のところを、お前はどう考えているか >『葉隠』 武士道と云は、死ぬ事と見付けたり >『葉隠』 武士道を読みました。読んだ後になって知ったのですが、こちらの武士道のほうが有名?なのですね。Amazonのレビュー見た感じですと。 この書籍では、”武士道”とは、『対峙的人倫観をふまえた独立の精神』と説いていました。解説によると、新渡戸稲造氏の武士道は、武士道そのものではなく、新渡戸氏の道徳思想を主に説明しています。一方、この書籍では武士道という精神論に対して、様々な原典を持ってきた上で分析しています。そういう意味では少し硬くて読みにくい反面、1つの事柄に関しても多くの原典を参考にしているので本当に理解を深めたい人には良書なのかもしれなです。 『武士道と云は、死ぬ事と見付けたり』 文面にも引用した、おそらく武士道として広く知られるこの引用の一節は、武士道として解かれる『葉隠』の一節でしかありません。そして、その本質は死を目前としたとしても、確かに存在している自己の確立を求めるものであるらしいです。武士道とは、自己を磨くことや、他者へも礼儀を持つことなどの心持ちが多く解かれていたり、また、独立ということも重要な要素として解かれている、同時の人としての有り様全体を説いた道のようです。 ありのまま、名と恥、死の覚悟、しずかながらも力強い、などなど、様々な要素がちりばめられていました。 茶道、禅、武士道と読んできましたが、自己の洗練やそれに付随する質素さなど、多くが繋がっているように見えました。それらはざっと浅く見聞きした今までの知見と大差なく。一方、こういう話は海外の人たちの興味の対象として一定の強さがあることも事実のようです。無知よりは知っていたほうがいいし、宗教のように強く依存するまで行く必要もないけれど、ざっと時間を見つけて技術書以外にも文化を学ぶって良いですね。 食文化にもつながる要素も多い。More
『星の王子さま、禅を語る』を読んだ
最近、茶道の本を読んだり、今回読んだ禅に関して読むことで日本固有の文化に触れてみています。合わせて、禅に触れてみようと思い、星の王子さま、禅を語るを読みました。 ソフトウェア開発において、Zenという言葉が使われることがあります。それらは、簡素・質素といった禅から派生していると説明されていることを見ます。発問もZen(禅)というので、日本の禅が大きく影響しているのでしょう。 海外のソフトウェア開発では、開発物の設計思想だとか、何を大事にしているかといった芯を重要視していることが多いように見えます。そこで、幾つかのきっかけも相まったものの、その禅というものを少し学んでみようと思い今回の書籍を手にとってみました。 自らの立つ場所を深く掘れ。そうすればよい泉が湧くだろう それとは別に、純粋に、 星の王子さま を題材に禅を説明していたという、非常に興味沸かせる題材を扱っていたこともあります。 この書籍は、以下のそれぞれの題目に対して、星の王子さまの引用、その説明という形で流れていました。星の王子さまの引用と、各項目だけつらつらと残しておきます。 不立文字 肝心なことは、目に見えないんだよ 目では、何も見えないよ。心で探さないとね。 目に見えない世界、円 直指人心 どんな大人だって、はじめは子供だった。でも、それを覚えている大人は、ほとんどいない 智慧 脚下照顧 君の探しているものなら、たった一輪のバラの花にだって、一滴の水にだってあるのになぁ 色即是空(平等) ちょっと離れたところから見ると、それはもう、本当にすばらしい眺めでした 空即是色(差別) おれにとって、あんたは、世界中でたった一人しかいない人間になるし、あんたにとっては、それは、世界中でたった一匹しかいないキツネになるのさ もう一度、バラの花を見にいってごらんよ。あんたのバラが、世界中にたったひとつしかないことがわかるからね 一隅を照らす ばかばかしいと思えないのは、あの人だけだ。それは、たぶん、あの人が、自分のことだけでなく、他人のことも考えているからだろう 自由 もし五十三分を好きに使っていいんだったら、僕は、新しい水のわく泉のほうへ、のんびり歩いていくのになぁ 仏性 「砂漠が美しいのはね」、と王子さまがいった。「どこかに井戸が隠されているからさ」 一期一会 最後の朝には、いつもやっていた仕事が、とても大切なことのように思われました 全体的には、思想というよりも禅という考え方について書かれていました。これらは明日から使えるなにか、といった類ではないですが、このような考え方に触れるって面白いですね。 少し蛇足。私の実家では、叔父/叔母が主に信仰していたものが浄土真宗でした。親鸞が有名ですかね。一般的に仏壇などあれば浄土真宗や浄土宗がおもだと思います。それらも茶道や禅などと大きく違わない。異なることはあるけれど、同じところもある、という感じに見て取れました。私自身は浄土真宗を特別学んだりしたりはしていないのですが、質素や簡素、直指人心のようなところは心地よいなと感じました。 茶道と禅に合わせて並んでいた武士道について読んでみようと思います。以前、剣道を学んだときに武士道に関して少し見聞きしたことがあるのですが、それも中学校の部活動なので、正直覚えていない…いずれも質素や芯を持つというところで重なることがありそうな気がしています。 このくらいの本であれば、数時間あればざっと目を通すくらいできて気軽でよいですね。More
基礎教養的な、組込みソフトウェア工学ハンドブックを読んだ
組込みソフトウェア工学ハンドブックを読みました。 組み込みソフトウェアと書かれていますが、組み込みに特化した話ではないです。 ソフトウェアに関わる歴史が、自動車産業から発展してきたことは有名なことでしょう。その流れからソフトウェア工学に関する話を全体的に書いているため、このタイトルになったのだと思います。 この著者に私は大学、大学院と学びました。ここに記載されていることは私が5,6年前の学部時代に学んだことの多くで、こういう話をよく聞いたな、と懐かしくもなりました。 内容は、 ・ソフトウェアの歴史 ・ソフトウェア開発の流れ ・ソフトウェア工学の基礎 ・ソフトウェアの品質 ・ソフトウェアレビュー ・ソフトウェアテスト ・ソフトウェアのメトリクスと品質管理 といった内容です。 いずれも、詳細な技術というよりは、抽象的な内容と簡易な例でまとめられています。少し、ソフトウェアの歴史から見たソフトウェアの品質・テストの流れを知りたいという人にちょうど良いかもしれません。ソフトウェアメトリクスの内容に関しては、数学的な言及もあるので面白いと思います。More
「イシューからはじめよ」を読んだ
イシューからはじめよ ― 知的生産の「シンプルな本質」 [Kindle版]を読んだ ある方からオススメされたので読んでみた。 知的労働者として価値のある仕事を行うために行う問題解決の一連の流れを載せている。問題(issue)の見つけ方、仮説、ストーリー、アプトプットへの変換など。私の読んだことのある問題解決系の本などにくらべて、技法のような話よりも”アウトプット”として誰かに共有、報告するまで全体を書いているところが価値のあるところだと思う。 知れば知るほど知恵が湧くより、知り過ぎるとバカになる という言葉が出てくるが、大学時代の教授の言葉を思い出した。書籍などに載っている既存知識を吸収することは大事だが、一定の基礎を学んだ以降は読みすぎないほうが良い。すでに存在する発想にとらわれ、自分で考えた自分の発想を大きく阻害するから、というものだ。 カナヅチを持っていればすべてのものがクギに見える という、マズローの有名な言葉にもあるように。 メッセージに納得して、行動に移してもらう。いくつかアウトプットの目的をあげていたが、私が常に意識しなければいけないアウトプットの目的が見事にこれだった。最近、外部で発表する機会も増えてきて、資料を作ることがある。その中で、ここでも書かれているようなストーリー性であったり、伝えたいことを絞れなどはよく言われているので、書籍としてまとめて読むことができることは、私には価値があった。頭に常に入れておきたい。 書籍のはじめに、「悩む」と「考える」という2つの言葉を、答えの有無で説明している箇所があった。私の思っていたことに似ていて共感を持てた。答えを見つけるために「考える」のと、答えを見つけるわけでもなく、思考を発散させたり単に思考を巡らせるだけの「悩む」。仕事を行う上での価値の有無は書籍に任せるとして、私はどちらも人なので必要だなと感じた。 何か課題を見つけ、考え、アウトプットへ落とし込む方法をざっと頭に入れておきたい人にはオススメの本。細かな技法を知りたいという人には、他を当たった方が良さそうな内容。 自己啓発とか、課題解決の思考云々の書籍はあまり読まないが、これは文章や発表資料を作成するときは時折読みたいと感じた書籍だった。More
ユーザビリティエンジニアリングを読んだ
モバイルアプリのテストに携わっていると、ユーザビリティと向き合うことが必要だと感じています。 過去、このような記事を書きましたが、それとは別の書籍読んだのでメモがてら。 実際に、インタビューなど実施するときに直面したとき、もう一度さらっと読みたいなと思いまいた。 読んだもの: ユーザビリティエンジニアリングMore