book – Page 11 – ~ my tech diary ~

『物語スペインの歴史―海洋帝国の黄金時代』を読んだ

過去、シンガポールとハワイの歴史を読みましたが、今度は『物語スペインの歴史―海洋帝国の黄金時代 (中公新書)』を読んでみました。スペインはレパント海戦や無敵艦隊などで有名なので、その辺の話を知っている人も多いと思います。学校の授業などでも有名どころとしてまず学ぶところでしょう。この本はそこだけに焦点を当てるのではなく、そこに至るまでの過去のイスラムによる支配、その国土回復のための活動など、私がよく把握していなかった過去がありました。その後、イギリスのエリザベス1世との関係や、無敵艦隊などの話に続き、その敗戦、現代と話が大きく変化します。大きな局面を例に、スペインの歴史の変化を垣間見ることができました。「ドン・キホーテ」の著者であるセルバンテスが度々出てきますが、これは著者の嗜好も絡んでいるみたいですが、そういう視点での物語も変わって面白いものですね。とはいえ、欧州は侵略など含めて大きく歴史が動き続けた場所でもあります。欧州に足を運ぶ際は、こういう歴史的なところも少なからず知っておきたいところですね。More

Keep Agility with Rapid Deployment

Steve McConnell氏のRapid Developmentを読みました。90年代の書籍。日本語訳はこちらに。ラピッドデベロップメント―効率的な開発を目指して Rapid Developmentは、短いスケジュールで開発をどんどん回していく、という考え方を持った開発スタイルです。最近のAgileの風潮に対して、以前からそういう開発スタイルが提唱されていた、という参考になりました。ただ、読書を進めていくと、開発プロセスに関するところは大学で教授から学んだことと大半が重なってて、なんか講義を見直している感じがしました。 Part1. Effective development For every complex problem, there is an answer that is short, simple, and wrong. — H.L. Mencken 人に関する問題が、最もソフトウェア開発や品質に影響を与える、と早い段階で書いています。また、”Motivation”が強く影響する、とも書いています。 Classic mistakeとして幾つか実例を挙げています。分類として、人、プロセス、製品、技術に関わるところから。いずれも、昨今のAgileの文脈で言われることの多い従来の開発における問題やらなんやら書かれています。これを見ると、結局は問題は古くからあって気づいた人はどうにかしようとしている、ということを知ることができます。ソフトウェア開発に関わる活動のプラクティスを、Management、Technical、Quality-Assurance の面から色々紐解いています。その中では、例えばエラーが出やすいモジュールに対する言及や、Testing、レビュー活動など、現在やっているプラクティスがもろもろ含まれていました。リスクマネジメントのことも。リスクを識別し、分析、優先度をつけて可能な領域で制御する。そこらへんも書いていたり。ここら辺を書いていますが、個人的に良かったのはそれらをまとめ、体験としてまとめているところでした。昨今の開発全体を書いている書籍を読むよりは、これを読んだ方が有益な感じがします。 Part2. Rapid Development Part2では、今までの一般的な効率的な開発の説明のなかから、Rapid developmentとしてのプラクティスをまとめています。 Agileのプランニングポーカーみたいなタスクのサイズの計測とか、そういう話に似たものも出てきます。いずれも、時間に対してどこまでやるか、を現実としてどうするかに関する話を交えています。変えることができるところ、できないところを分けて、いろいろ試行錯誤している感じですね。ただ、現在とは使える周辺ツールにより当時では時間がかかっていたことも短時間で実施できるようになっていることもあり、書籍の数値が完全に正しいというわけでもありません。一方で、考慮しなければいけない要素自体は、ソフトウェア開発という文脈ではとても参考になるものです。ここには時間、コスト、実装する機能の量に関するトレードオフに関しても、すべて書かれています。なので、昨今のAgile開発に類する開発本を読むよりは、この書籍を読む。その上で、当時問題だったところから現在までに変わったところ(例えば、自動化されたテスト環境とか)を把握していく方が、しっかりとした考えを備えることができそう、と感じました。というか、90年代の書籍に開発の根本的な要素がまとめられた書籍が多く、それらが現在の開発においても色あせていないところが多い。それは逆に、ツールが発展しつつも、そのコアとなる問題は変わっていないし、その問題解決は簡単ではないということなのですかね。このRapid developmentの開発プロセスのwaterfallとか、spiralとか読んでいると、大学の頃に学んだことに近い、そのまんまなところが頭に浮かんできた。。。要求分析の話とかも。面白かったのは、high-performance teamというように、チームで高い成果を出すための大事な要素もまとめられていたところです。人やチームに対する考察も、しっかり書かれているのは素敵ですね。その中で、特に楽しもう!! が1つのトピックで書かれていたところが印象的。アンチパターンも多くのっているところも良かったです。ここらへんは昨今のAgileの文脈とか、開発プロセスの話でよくでますね。時代は回る〜。 Silver-Bullet…More

[Erlang]Dive into Designing for Scalability with Erlang/OTP

Designing for Scalability with Erlang/OTPを読みました。Erlang/OTPを軸とした、スケーラブルなシステムを構築するための設計に必要な知見がたまってそうだったのと、半額程度で購入できたのでありがたく読みました。内容として、半分はErlang/OTPのエコシステム周り、設計思想とかの話でした。ただ、残す半分はErlangに限ったことではない、広く使えそうな基礎がまとまっていました。個人的には、Elixir in Actionと合わせて読むとこの系統の書籍は十分そうな感覚です。ちなみに、所どころ使われている例題や、それを個人的にElixirに書き直したものを以下に置いています。(所どころ壊れているものもありますが。) https://github.com/KazuCocoa/erlang-scalable-design 前半部分 Erlang/OTPの全体的な話が書かれています。背景とか。message passingの概要とか。諸々。Erlangの文法も学びながら、gen_serverだったり、gen_fsmだったりといくつかのOTPの話に発展する感じでErlangを学ぶことができます。 debugのための、sysやdbgモジュールも記載されていました。以前読んだQiitaのReconTrace で Erlang VM のトレース機能に親しむでかかれていたrecon_traceなんかのことも言及されています。 proc_libという特別なプロセスの話も。この特別なプロセスは、システムメッセージや、イベント、シャットダウンとが可能動的モジュールのリストを得ることができる debug flagを使ってトレースメッセージを利用することができるといった特徴があります。後半部分(Chapter13以降くらい) Chapter 13のDistributed Architectureは、SOAやP2Pといった大局な設計やinterfaceから、その配布方法などの話まで色々ありました。これはErlangに特出したツールの話以外は、普通にErlang以外でも役立ちそうな情報だと思います。リリース関係の話の中で、riakというdecentralized datastoreなツールの話もあって、面白かったです。Gossip protocolを使ってClusteringしているとか、そういう話も載っていたので。HashiCorpのSurfなんかでも結構知られていますね。Gossip protocol。 Riakのそこらへんのドキュメントはこちら http://docs.basho.com/riak/latest/theory/concepts/Clusters/#Gossiping http://docs.basho.com/ これのErlang client https://github.com/basho/riak-erlang-client Elixir client https://github.com/drewkerrigan/riak-elixir-client Scalableなシステムを組むためのtipsとして、以下の項目がまとめられていました。分割する Distributed architectural pattern(cluster, SOAなど ) Network protocol node間のinterfaceや状態も持ちようやデータモデル node間のretry strategy node間のsharing data…More

『アジャイルの魂2015 アジャイル開発者18人の物語』を読んだ

『アジャイルの魂2015 アジャイル開発者18人の物語』を読んだ。私が気に入ったところはいくつかあった。が、その中で気に入った言葉がある。 QAおじさんのアジャイル奮闘記にある、 Stealth である。ただ、この言葉に感じたものは私はこの著者である永田さんとは異なるかもしれない。私が感じている、というよりも、ずっと意識しているのは自然に居ることである。その中に溶け込むこと。なので見えない、というよりは異なる。だが、その意味は変に意識しなくとも開発に対してテストする人も、コード書く人も、ディレクションする人も普通に居る。そんな世界。なので、私はこの言葉がこの書籍の中で気に入った。More

『ハワイの歴史と文化』を読んだ

ハワイの歴史と文化―悲劇と誇りのモザイクの中で (中公新書) を読んだ。移民の話、パールハーバーの話、観光地としての話、これからの話とハワイの重要な歴史を知ることができました。特に、日本人の関わり方という点でもまとまっているため、過去どのような関係を持っていたのか知ることができました。海外や知らないところに行く時、私はその場所などに関して多少なりとも知見を得て向かいます。教授から学んでいた時に、その地域のことを多少なりとも学んでいくことがわかりやすい礼儀になるという話を聞いてからそう言った習慣がついた気がします。More

『ヒューマンエラー完訳版』を読んだ ~ これが否応のない人生の現実である ~

単に、どんなにうまく運営されている組織でも、影響の大きな意思決定のうち相当の数が、後になって間違っていたと判明することになるという事実を認めることである。これが否応のない人生の現実である。『ソフトウェアの欠陥予防テストより確実な品質改善法』を読んだであったような欠陥分析をする上で、人は一定確率で失敗するという大事な前提があります。一方で、それはどれほどなのか、経験的なものではなくちゃんと研究としてどこまでされているのか気になっていました。そんな中、『ヒューマンエラー完訳版』を見つけたので読みました。そのメモなどをつらつら。ソフトウェアは人工物です。そのため、ソフトウェア開発は人の組織や認知と如何に関わるかというところが大事な要素を占めてきます。(ソフトウェアテストを学んでいると多くの人は行き着くことな気もしますね) この本では、主に原子力発電という安全性が最重要とされる情報をもとに、ヒューマンエラーに関して研究をまとめています。ここら辺は、安全性が重要な要素である航空関係、医療関係でも使われていることでしょう。たとえばスライスチーズモデルなんかで。一方で、スライスチーズモデルの考え方なんかは、実は程度はどうであれそこ以外の分野においても有益な情報が多分にあります。学術的な箇所は端折ってメモ。 GEMS(Generic Error-Modeling System)に沿った定義でエラーを主に扱っている実行上の失敗: スリップ(しくじり)、ラプス(手抜かり) 計画が不適切: ミステイク(mistake) この中で、計画が不適切であるエラーの方がより見つけにくい。(ソフトウェア開発だと、仕様がそもそも誤っているというところですね。) 人の活動は、 SB: skill base RB: rule base KB: knowledge base の3つで構成されるとしている。それぞれの特徴は省略(本書のP.82付近)。この中でSBで発生するエラーは、主には監視の失敗によっている。RB、KBは問題解決能力が大きく関係してくるエラーに対する活動。人は、頻度の高いものほど認知/推論しやすくなる。逆を言うと、そうでないものはエラーを認知することが難しくなる。5章ではそんな人の認知のロジックをモデルに落とし込み、模倣した研究が添えられている。つまり、人の正しいが、時折間違えるという状態がモデルとして扱われ、それを計算機により表現している。第6章の数値は面白かった。データベースアクセス、更新などのある作業がエラーなくできたか、エラーが発生した時に正しく対処できたかを、SB/RB/KBで対策した時の差を計測結果として残している。これによると、 SB ほどエラーが発生しやすいが、同様にSBの人ほどエラーが発生した時に正しく対処できる可能性があることを示している。つまり、プロセスなどを整備することによるリスク低減と、人のスキルが成熟している状態を作ることができれば、低いリスクで万が一にも備えることができる状態を作り上げることができる。ただ、いずれの活動に置いても、手順の飛ばし、抜け、漏れは検出することができなかった。つまり、手順の抜け漏れを探すようなことは、人は苦手。エラーを検出するためには、自己監視過程なんらかの環境の手がかりに気づく誰か他の人が発見するが大事。特に、ほかの人による発見は複雑でストレスの高いものほど効果が高い。つまり、気をつける、…More

『スペキュラティヴ・デザイン』を読んでみた

スペキュラティヴ・デザイン問題解決から、問題提起へ。—未来を思索するためにデザインができることを読みました。デザイン思考と違うのかなとか思ったり、speculativeってなんだ？というところがきっかけです。思考を発散させたいような人は読むと良いかもしれません。一方で、いろいろと思考実験したり考えることが好きな人にはあまり実りはないかもしれないですね。この本で提示するspeculative designは、課題を見つけて解決するためのデザイン思考からさらに進んで”問題に対して考える”ためにデザインする、というもの。比較として課題解決のためのデザインとしてアートとしてのデザインや工学的な設計のデザインなどをとり上げながら、speculative designに対する取り組みをいろいろと書いています。結果的には、変化するためにいろいろ思索するきっかけを作ったり、考えていこう、というものですね。その印象が強かったです。More

『Mobile Testing Interview Questions & Answers』を読んだけれど、これは入り口向け

Mobile Testing Interview Questions & Answers: Guide to Crack Interviews (English Edition) を読みました。この内容は、Q&A形式でモバイルアプリのテストに対する幾つかの疑問に答えていく、というものでした。ターゲットが以下なだけあって、内容としては基礎的なものです。内容は前半がモバイルアプリのテスト全体に対して、後半がAppiumに対してです。 a beginner who has never faced any Mobile Testing interview Anyone who wants a bried on Appium Professional who want answers with example and explanation One who don’t know what “They” really want to hear… 環境の設定変更といった具体的な話もありました。ただ、すでにモバイルアプリのテストを実施したことのある人、またはAppiumを試したことがある人、からすると目新しいものはない感じです。これは本当に知見のない人に対して行う説明、といった感じですね。More

『ユーザインタフェース開発失敗の本質』を読んだ

ユーザインタフェース開発失敗の本質を読みました。名著である失敗の本質と同じ”失敗の本質”を題名に置いていたので、試しに購入してみました。内容自体はよく耳にするユーザインタフェースが関わる開発における失敗パターンの説明に成ってます。それらを、原理主義として大別し、分析したというものでした。内容自体も経験とかけ離れてもないので、多分外れてはないと思います。日本軍の話ほど記憶には残りませんでしたが… ユーザビリティ原理主義アルゴリズム原理主義（及びロンギング原理主義）すごいデバイス原理主義多機能原理主義人に「自然」なインタフェース原理主義エージェント原理主義ユーザの声原理主義メタファー原理主義原理主義は時折現実から目を背けるような傾向を示しますが、そこを認識した上でうまく付き合いたいですね。More

『自由をつくる　自在に生きる』を読んだ

自由をつくる　自在に生きる (集英社新書) を読みました。ちょうど東京に戻る新幹線の中で。森博嗣さんが書かれていたので、惹かれて読んでみました。自由、というものに対する哲学的な話なのかと思いましたが、予想通りそうではなかったことが良かったです。自由を如何に作るか、どのような制限を受け入れるか、といった普段の生活の中での話が中心でした。最終的には自分で考える、というところが多かった印象です。制限というのは自由であることよりも幸せであることも多く、そこらへんの考え方に触れることができたことが面白かったです。More