So-net無料ブログ作成

本のベストセラー
プログラミング ブログトップ
前の3件 | 次の3件

アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン [プログラミング]

抽象化は人間だけのものだが、パターン認識はそうではない。
飼い犬だって週末のお出かけの前兆をかぎつける。
でも、パターン認識の先、「ああ、またアレだ!」といいう気づきは動物にはやってこない。

パターンは時間をかけて吸収され、洗練され、精神の奥深くへしまいこまれ、直感という形であらわれる。
それだけでも価値はあるが、じっくり考えそこから明確な知見を導き出せればその価値はずっと高くなる。

右脳の直感と左脳の言語が結びついたとき、本質をとらえて言葉にすることができる。
言葉があれば、書き留めたり、他の人と共有したり、他の人の知見と融合させたりできる。

この本は150年にわたって吸収してきたパターンを6人の人間が文章にしたもの。
順番は特に意味はない。楽しく読めるようには工夫した。

必ずしも読者の組織にあわないかもしれないが、以前は直感に過ぎなかったものをチームの知見にする手伝いになるとうれしい。
よく考えられた抽象化はどのような題材でもわかりやすく人に伝えることができる。


1 アドレナリンジャンキー
 みんなが猛烈に必死に働いている、いつも緊急で重要な仕事でいっぱいだ。でも生産性をたかめる本質的に重要なことは緊急はないので置き去りだ。だから生産性はいつまでもあがらないし、少人数で必死に働いてなんとかなる範囲のものしかつくれないので、大きなプロジェクトは行えない。
 こうした組織の特徴は、優先順位が絶えず変化すること。いつも「きのう」必要だという。

2 スピード勝負
 スピードの速いチームは、議事録が届かないうちに決定した行動経過のうち1項目めか2項目めが終わっている。
 もしかして、会議中にインスタントメッセージで問い合わせ、会議が終わるまでに報告できるかも。
 速いチームは強いチームで、以下のような文化をもっている。
  ・本能的に切迫感をもっている。
  ・個人とチームの能力に絶大な自信をもっている
  ・反復に価値があると信じている・・・間違ってもいい、修正するから。
 弱いチームの会議はトークショーである
  ・完璧な情報をもとめる・・・それが得られるまで何一つ決まらない
  ・なんでも「保留」しただる・・・決定や行動を後回しする理由をさがしている
  ・左かっこのオンパレード・・・思いつきで会議が進む
  ・キャンプファイヤーを囲んでおしゃべり・・・組織の過去や現在についてとめどもなく語る
  ・すべの道は設計に通ず・・・アーキテクトや開発者の力がつよいと設計議論におちいりやすい
  ・次の会議の予定をたてるための会議

3 死んだ魚
 時には手ごわいプロジェクトに挑戦して、譲歩する前に精一杯の努力をするこも必要だ。
 しかし、最初から納期にまにあわないとわかっているのにそのままプロジェクトをすすめ、「一生懸命がんばったのにできなかった」というのが文化なら問題だ。
 死んだ魚=最初から納期にまにあうとだれも思っていないプロジェクト

4 幸福礼賛会議
 時間も労力もつかわずに士気が高くなる方法として使われることが多い。
 全員が参加して上司が「問題があればなんでもきかせてください」というが、実際に厳しい質問をすると後で叱責される。求められているのは意見ではなく賛同。
 それは間違いなく幸福礼賛会議。

5 乳母
 良いプロジェクトマネージャーはイギリスの乳母と共通するスキルをもっている
 乳母は子どもを守り、運動させ、外の世界で生きていけるように教育する。環境をととのえるのだ。
 良いマネージャは、開発者が雑用にわずらわされないように気を配り、必要な情報を伝え(ウワサ話の時間が減る)、機材や職場環境をととのえ、コミュニケーションの時間(朝のコーヒー会や、金曜午後のブックレビューなど)を用意する。自分を支援者ととらえて、メンバーが役割をこなし、生産性が高まり、自分の仕事に満足してくれることを喜びとする。
 この反対は、マネージャーの関心が社内での駆け引き、出世にあり、チームと話をするより、PERT図やガントチャートをつくったり手直しするのが大事、あるいは開発にかかりきりである。

6 関連痛
 関連痛・・・原因箇所ではない身体の部分に痛みがあらわれる状態のこと
 プロジェクトを立ち上げるときに、目に見える問題に目をうばわれて、肝心の問題が解消できないことがある。
 また、使い慣れた技術でなんでも解決しようとして、最適でない技術を使ってしまうこともある。
 回避策を多用しないといけない状況が続くなら、関連痛にかかっている可能性が高い。
 本質を解決するのは困難だが、見返りは大きい。

7 マニャーナ
 マニャーナ・・・スペイン語で「いつかそのうち」
 たいていのプロジェクトは人間の切迫感の時間枠(30-90日)より長くかかる。だから30か月後の納期に切迫感を感じることはない。
 こんなときはメンバーの意識を時間枠に集中させるために90日あるいは30日以内に成果物を仕上げるように指示をだす。もちろん本当のゴールに向かうために必要なものでなくてはならない。
 あと、50%など判定が難しい設定は切迫感がでにくい
 また作業やテストの用のツールを必要以上に探し回るなども、たちの悪いマニャーナだ。

8 アイコンタクト
 フルタイムの熱心なプロジェクトメンバーが1か所に集まると、ある種の奇跡が起こる。息をあわせるには物理的に近くにいる必要がある。
 緊急かつ複雑ならば、要因は同じ場所に配置すべきである。

9 ムードリング
 結論のない進行形の活動ばかりに注目するプロジェクトマネージャーは、自分たちが最終的に何を達成しようとしているかわかっていないことが多い。
 こういったマネージャの報告の特徴
  ・感情や熱意に重点がおかれ(がんばっています、間に合わせるべく努力しています)
  ・現在に集中している(全体のどこではなく)
  ・計画通りにすすんでいないことには感情でかたる(少々心配です)
  ・結論がなく進行形で語る(あといくつかの機能もすぐに完成させてくれるにちがいありません)
  ・マイナス要素にはふれるが全体的に楽観的
 なにをすべきかわかっているマネージャの報告の特徴
  ・作業内容、成果物の状況によって評価する。
  ・中断、問題、計画変更に注目、必要な修正と決定項目を明示
  ・だらだらせず区切りがある
  ・客観的情報と判断的要素のバランスがとれている。
 ほとんどのマネージャは上と下の中間。上の要素が多くなってきたら、自分を修正しよう。

10 信者
 特定の技術を信奉しなんでもそれで解決しようとするひとがいる。
 しかし、どの手法やツールにも限界がある。
 異なる教義の信者が争いを起こすと収集がつかなくなる。
 「異なるプロジェクトには異なる方法論が必要である」 アリスター・コーバーン(アジャイルソフトウェア開発)

11 魂を貸す
 一流のプロは魂を貸しても、売らない。
 確立された個人やチームの技能を問題にあてはめるのではなく、問題に合わせた解決策をさがそうとする。
 慣れ親しんだやり方を、いつでも捨てる勇気があり、かつ流行りの方法に安易にのらない。
 大事なのは「この技術は何に適しているか」であって「どうしたらこの技術でこの問題を解決できるか」ではない。

12 レミングサイクル
 プロセス改善プログラムの一環として、開発プロセスの社内基準をもつ企業は多い。
 しかしなにがなんでも標準プロセスを守ろうとすると、いらない仕事を増やしていることも多い。
 万が一失敗した場合、標準プロセスを守っていなかったからだといわれる。
 またどのプロセスを削るべきか検討する時間が惜しい。
 このような理由でやみくもに標準プロセスに従うのは、厳格にレシピを守る料理人のようなもので、優れた料理人にはなれない。

13 ベンチに人なし
 組織をスリム化しすぎて、予備要員がいなくなっていませんか?
 プロジェクトの主要メンバーのだれにでもとってかわれる幅広い人物を一人か二人用意すべき。
 コストはかかるが、プロジェクトにとって足りなくなるのはコストより時間のはずだから。

14 フェイスタイム
 小数精鋭チームの開発効率がいいのは30年もまえからいわれている。
 今日なら、ここに「同じ場所で働く」がつくだろう。
 しかし分散プロジェクトが普及して、難しくなっている。
 それでもメンバーはできるかぎり会うべきだとして、その一般的ガイドラインをあげていた。
  ・サイト間の作業を担当する人(プログラムマネージャー、プロジェクトマネージャーなどの肩書)はリリースサイクルごと。3か月に1回では少ない
  ・開発者、QAエンジニア、テクニカルライターのなかなら、リリースサイクルに最低1回、各サイトのベテラン同士が顔をあわせるべき
  ・若手メンバーが他のサイトを訪れることで、自分たちの仕事の一や、他のサイトのベテランからの教育、評価がうけれることがある。
 サイト間で、あそこは使えないサイトなどと序列ができたりするのは最悪。
 
15 「どうしてミケランジェロになれないんだ?」
 「たがね」はミケランジェロが手にとらなければ、へりの鋭い金属片にすぎない。
 ツールを導入しても、使いこなすためのスキルがなければ、生産性はまったく上がらない。

16 ダッシュボード
 車のではなく、プロジェクトやビジネスプロセスの状態を視覚化して伝える手段として普及したもので、各種指標を通常は図表と数値の両方で表示し、プロジェクトやプロセスの進捗状況を全体的に描きだす文書やWebページのこと。
 トップレベルにはかくパフォーマンス指標の要約が表示され、ユーザーがそれらをドリルダウンしてさらに詳しい情報を見られるタイプのものがある。
 ダッシュボードは強いチームが使えば役にたつが、弱いチームが使うと全く役にたたないどころか邪魔になる。

 弱いチームがダッシュボードを使っているときの兆候
  ・赤は失敗を意味すると信じている。音がうるさいからと煙感知器をきっているようなもの
  ・橙は現実から目をそむけた赤である・・真実に向き合えないで、警鐘をならすことを避けたがる
  ・緑はあまり見るなという意味である。・・・ぎりぎりに突然赤になる。そこには赤だとダメだという文化がある
 このようなチームは成功への情熱でなく批判への恐怖を原動力としている。

 強いチームの有効なダッシュボートの特徴
  ・ダッシュボードを使ってもデータに圧倒されない・・・すべてを報告するのではなく、限られた指標を慎重にえらんで報告する
  ・ダッシュボードを抜粋・編集できる・・・どの情報をフロントページんに表示し、どの情報を3階層下に埋めるかを決める過程で、重要項目がはっきりする
  ・情報を示すだけでなく判断を促す・・・現状の報告だけでなく、判断を促すようになっている
  ・現状を反映するだけでなく未来を予測する・・・現状を報告するだけでなく、将来なにが起きて何がおきないか予測を示せる「バランス・スコアカードー新しい経営指標による企業変革」
  ・長期的なトレンドを示す・・・現在のスナップショットだけでなく、いままでの軌跡、黄色の前は何色だったのか?がwかる
  ・チームが主観的な評価を報告しなければならないときに、比較をするための枠組みがある
    色は主観であり、そうあるべきだが、定義はあるべきだ
     緑=順調で、修正はいらなそう 黄=ただちに十分な修正措置をとる必要あり 赤=プロジェクトは計画にほど遠い、ただちに変更措置がいる

  成功する確率を高める為にただちに修正すべき天意チームの注意をむけることができる


17 永遠の議論
 プロジェクトリーダーが、不満を述べるのを許している限り、決定に従わない人がでる。
 こういう人は賛同するまで決定に従わなくていいと思っている。
 組織として行動するなら、意見をきいて決定するまでの期間をきちんときめて、いったん決まったら賛同していなくても決定に従うという文化が必要である。
 そうでなければ永遠の議論が続くことになる。


18 子犬と老犬
 組織に一定以上の若者がいると、そこはみながよく働き、明るくくつろいだ雰囲気で、いい意味で「楽しい」職場になる。若い人々は高揚感がある、これからスキルを身につける最中で、次第に成長を実感し、いい仕事がしたいと思っている。それにつられて老犬も若返る。
 
 老いぼれ犬ばかりの組織になってしまうのは
  ・組織が成長していないため、若者を雇う機会がほとんどない・・・政府機関のような場所に多い
  ・組織が経験者だけ採用することにしている・・・XMLの経験15年!
  ・組織が徹底的に冒険を避けている

 パートタイムでいいので若者を起用しよう。


19 映画評論家
 プロジェクトの成功とは別の成功を目指している人。
 プロジェクトが終わりに近づいたとき、プロジェクトの間違いを指摘したりする、あくまで指摘するだけで、修正方法などは言わない。
 プロジェクトは失敗しても、自分は成功できると信じていて、事実上黙ってプロジェクトチームから分離している。
 この映画評論家が生まれやすい組織は、経営者の文化として間違いを犯さない文化をもっている。ひとの間違いを指摘せよと組織にシグナルをおくるので、参加しているプロジェクトに対して他人事のように映画評論を行う。
 そういう人を許容すると、責任あるリーダーやメンバーになるより映画評論家になるのは簡単だから増えることになる。
 プロジェクトの成功を目的としない人が参加することで、誰の努力も実をむすばない、逆効果になる場合がある。


20 一人一役
 一人一人が責任をもち、その責任がどういうものかを理解していることが、人々のやりがいになりチームとして力を発揮する。
 一人で責任を引き受けたから、同僚や関係者に協力を求めたり、必要な意見を得たりしてはいけないということではない。
 すべを全員の責任にしたら、全員があらゆることを心配し、どれ一つうまくいかない


閑話 プロジェクト言葉
 このスケジュールは果敢です・・・おれたちはおしまいだ。
 もうすぐ遅れは取り戻せます・・・やっぱりもうおしまいだ。


21 ソビエト式
 意図された機能ははたすが、やり方がまずい、いらだたしい。
 あるいは使い勝手が悪い、見た目や雰囲気に魅力がない、必要な安全性に欠けているという利用する人に魅力を感じさせるという要求を満たしていない。
 こんなソビエト式製品を作ってしまったことはないだろうか、こういったものは修正が異常に多いか、極端に少ない(使われないから)
 優れたチームは、機能面以外の要求をシステマティックに引き出すことを重要なプロセスの一環と位置付け、これらの分野でユーザビリティモデルを構築し、スペシャリストを採用している。
 プロトタイピングを行い、ユーザーに好まれる機能面以外の品質について有意義なフィードバックを集めることが重要


22 自然な権威
 権威は、能力のある人に備わる。
 大事なのは知識があってその分野をよく理解している人に相談し、権威ある人が判断すること。
 階級が↑=権力のあるひとが、権威のある人を無視して判断をしてもうまくいかない。
 沈黙は同意とみなされるので、あなたが権威のある人ならば、だまっているのは責任の放棄である。
 しかし文化として権力が権威を無視する企業では、だれもそんなことは気にしなくなる。


23 静かすぎるオフィス
 廊下歩くだけでソフトウエア開発チームのことはわかる。
 チームのメンバーが目的をもって楽しそうに動き回っている職場は良いチーム
 人々が家に帰れる時間を待ち、次の給料日を待ちながら、何かおもしろいことはないか、あるいは早く退職する日がこないか考えている職場は静かすぎる。


24 白線
 システムやビジネスエリアは、データを変化させるプロセスで構成されている。
 プロセスは属性セットを別の属性セットに変換し、データの状態を変えてからそれを次のプロセスへ渡す。
 このようなプロセスとデータの集合体をかき、そこに白線を引くことでシステムのスコープが明確に定義できる。


25 沈黙は同意とみなされる
 約束の誤解が起きるよくあるパターンは、要求に対して、沈黙でこたえること。相手は異を唱えなかったら同意とみなし、こちらはYesといわなかったらNoだと思っている。
 これは双方にとっていいことはない。
 これを避けるには、少数の重要な約束を公言し、文書化して、関係者全員に配ること。
 そして「同意しなければ同意とみなされない」というルールを作ること。


26 かかし
 人は白紙から答えをつくることは嫌がるが、すでにあるものは平気で批判する。
 だから、優秀なアナリストは「何をお望みですか?」とは聞かない。相手を不快にするから。
 「かかし」のソリューションは、クライアントの望みを引き出すために提示される。最高の「かかし」は意図的に間違いを組み込みさえする。そうして最速でソリューションやデザインに近づくのだ。
 早いうちに間違え、何度も間違えることが、できるだけ早く正解にたどり着く方法。
 われわれが直面する問題は複雑すぎて、一人の頭ではどうにかすることはできないのだkら、覚悟をきめて「これはどうだろう?」と聞いてみよう。それが有効な「かかし」になる。


27 いつわりの緊急任務
 リスクを取らないの間違いであることは理解されつつあるが、最初から失敗するとわかっている開発期間に挑戦するのはいつわりの緊急任務であって、リスクをとることではない。
 いつわりのリスクを生み出すと、組織は本物のリスクに挑戦する機会を失う。
 

28 「時間」に切り札を奪われる
 プロジェクトに影響を与えるのは、マネージャがごく早い時期に下した決定である。
 早い段階での人員増加は、有効だが、のこり2か月の人員増加は失敗の可能性を高める。
 機能を早い段階で絞り込むのは、重要なものを完成させるため。さもないと締め切り間際に完成間近な多くの重要な機能と、完成した小さなこまごました機能に直面して、何を先にリリースするべきかの選択肢はなくなっている(完成しているものをいれるしかないだろう)
 優秀なプロジェクトマネージャは「時間」に負けないためにいつ切り札を切るべきかしっている。

29 ルイス&クラーク
 1803年あめりかが五大湖と大西洋海岸の州だけで独立したあと、フランスから西の領土を買った。
 1804年から1805年にかけて、ジェファソンの命で新領土の調査をおこなったのがルイス&クラーク。
 二人は何を見つけるべきか指示されなかった(できなかった)
 プロジェクトの探検隊は抽象的な意味で仕事を調査する。しかし結果は必ず有益なものがみつかるわけではないことは承知しておくべき。しかし、有益なものがみつかれば、無駄な探索の分も十分カバーできる利益が得られるものだ。


30 ちびた鉛筆
 コスト削減が続くと、組織の競争力は落ちる。
 最初のコスト削減では、利益が増えたことだけがクローズアップされるが、一時的なものであり、コスト削減が続けば組織はやる気を失い、やがて売り上げがおちていく。
 1つくらいコスト削減プログラムを実施するのは賢明だが、さらにコストを削減しようとするより、自分自身の幸せを考えるべきた。


31 リズム
 リズムのあるプロジェクトは、巨大で複雑な仕事にひるむことなく、小さく規則的なステップを踏んでいくうちに、一定のテンポをきざんで目標へたどりつくことがでる。
 そのとこを理解しているので、まず目標をきめ、通常は1か月で完了しそうな計画をたて、毎日あつまって進捗やアイデア質問をかわし翌日の計画をたてる。プロジェクトの目標、毎月の目標となる成果物、毎日のフィードバック会議が作業のリズムをつくる。人々がリズムと認識できればサイクルの長さは問題でないが、6か月以上になるとマニャーナが起きるので注意。
 リズムのあるプロジェクトはリズムのないプロジェクトより短期間で役立つ製品をつくりだせる。個人個人が他のチームメンバとの約束を果たしているから。リズムにあわせて働くのは自己強化型の活動になり、健全な駆動力になる。
 ただし、マネージャーが強制的にリズムをつくったり、リズムをあげたりしてはいけない。リズムはチームが作り出すものだ。


32 残業にみる予兆
 若いマネージャは、部下が残業するのをみると、意欲の表れとみて喜ぶ。
 追い込みの時期の残業ならいざしらず、早い段階の残業にはチームの恐怖があらわれている可能性が高い。
 
 組織が恐怖の文化にとらわれいる場合のよくある原因
  ・恐怖によるマネジメント・・・トップから最下層まで恐怖で運営されている。やめるのをすすめていた
  ・コスト削減のための人減らしへの恐怖・・・首切りをかわせないかと長時間働く
  ・個人的な失敗に対する恐怖・・・仕事に自信のないメンバーは、能力を高めてくれる追加研修やコーチングより長時間働く方を選ぶことがある
  ・プロジェクトの失敗に対する恐怖・・・計画通りのスケジュールで時間が足りないとおもうとスタートダッシュをかけることがあるが、続かない。
  ・プロジェクトの失敗が確実な場合の個人的避難位対する恐怖・・・きたるべき大失敗の咎を逃れる為に、あえてこれ見よがしに長時間はたらく

  早い段階の残業は、プロジェクトが思わしくない予兆


33 ポーカーの夕べ
 職務に関係ない活動のために組織のあちこちから従業員があつまり、顔見知りなるのは、組織にとって有効である。
 しかし人為的にコミュニケーションの流れを円滑化しようとしても、個人が自らの意志で参加しているという意識が乏しいのであまり有効でない。人々が集まり、楽しみ、とに成功する状況をつくるだけでいい。あるいは集まった人の活動をつぶさないようにすればいい。
 例としてポーカーの夕べ、マラソンの給水所のボランティアなど


34 エセ品質ゲート
 意味が欠落しているのに、形式の心配をしても仕方がない。
 We eat breakfast in the evening.
構文は正しいが意味は通っていない。
 エセ品質ゲートの兆候は、フィードバックのうち、内容でなく形式が大半を占めていることでわかる。
 無益な手続きに時間が浪費させられたうえ、内容の欠陥が見過ごされることになる。


35 テストの前のテスト
 製品開発のごく初期の段階や各イテレーションの初期にテストを開始する。
 プロジェクトで予定されている成果物が完成したときに、間違いがないかどうかテストできるするためのテストは、あとのテストの有効性を高め、エラーを避けられる。
 これを行わないのは「期待通りに動く」とはどういうことかが正確にわかっていないから。
 初期テストは要求だけでなく、あらゆる成果物に有効。製品の設計、プロジェクト計画、スコープ文書などテスト可能な形式で提出されれば初期テストのメリットを享受できる。テストされると思えば製作者の意識もちがうので中間成果物がわかりやすくなる。
 製品ができあがってからテストしてもプロジェクトの成功の役にはたたない。
 テストの前にテストすることは、最初から品質管理を導入することである。


36 サイダーハウス・ルール
 現場にいないひとが決めたルールは、無視されるか回避される。
 ルールは必要だが、策定には作成者が現場に入り、現場の人の世界を共有することが必要である。


37 まず話す、次に書く
 大企業や分散チームは文書に頼る傾向があり、小規模なチームは会話に頼る傾向がある。
 優れたチームは、その時その時の作業に応じて、文化的にあまり慣れていないコミュニケーションでも採用するよう心がける。意思決定を短時間で効率的に行うには会話を使い。あとに残すべき決定を伝えるときは文書を使う。


38 ダボハゼ
 心の中で仕事は多いほどいいと持っていませんか?
 しかし、最大限の側で処理できる以上の仕事をひきうけていると、いずれ遅くなるのは当然。
 多くの組織は膨大な量の仕事を完成させようとして、ほぼ停滞状態にまで減速してしまう。
 立ち止まって価値あるものとないものに選り分ければ、自分たちが山ほどのカスのために遅くなっていることに気が付くはず。


39 アトラス
 アトラス=なんでもできる優秀なプロジェクトリーダー
 一見問題ないようにみえるが、自分でなんでもやってしまうために他のリーダーが育たない。だから運営できるプロジェクトの規模に限界があり、アトラスが抜けた後はだれもフォロー不可能である。


40 裸の組織
 情報が多すぎると注意力はなくなる。
 全員がすべてのことを知っている必要があるならその組織はおしまいである。
 多くの情報を抱え込むことの問題は、情報をうけとってそれに文句をいわなければ事実上同意したことになること。
 多くの情報を抱え込もうとして、自分の情報プレートをあふれさせてしまうのは、はじめて大人の宴会に参加した子供がおいしそうなものをすべて口に抱え込んでしまうようなものである。


41 ピア・プレビュー
 採用候補者と同僚になるスタッフを採用プロセスに参加させるのは、採用される側、受け入れる側双方にメリットがある。もちろん一次審査などはマネージャの判断が優先されるべきだが、面接はスタッフで行い、多数決で決める。
 チームリーダーの採用もそうしてはどうか?


42 シュノーケリングとスキューバーダイビング
 広い範囲をみるならシュノーケリング、深く潜って調べるならスキューバダイビング。優れた開発者は自分を制限しないで、なにをみるべきかによって方法を選ぶ。


43 いまいましいインターフェース
 まだ細部まで煮詰まっていないプロジェクトの初期段階で、実装が可能なほど厳密にインターフェースを宣言するのは難しい、しかしわかるかぎりのインターフェースを定義しなければならない。インターフェースの欠陥をよく知っているマネージャはプロジェクトチームのインターフェースに気を配り、どこかのグループがインターフェースについて誤った仮説をたてる可能性とたたかう。
 プロジェクトの人間のインターフェースが複雑だと製品のインターフェースも複雑になる


44 ブルーゾーン
 プロジェクトの任務を割り当てるには、3つの権限ゾーンをつくること
  ・グリーンゾーン・・・明確に任務の一部であること、つまり遂行すべき仕事の核である。
  ・レッドゾーン・・・任務の範囲から明確に除外されるものがすべて含まれる
  ・ブルーゾーン・・・それ以外のすべて、任務で求められても禁じられてもいない活動。
 ブルーゾーンで行動し、ときにレッドゾーンで行動させてほしいという人物は貴重である。ひやひやさせられるときもあるが、その大胆さのおかげで、当初の任務で想定されていたものよりも革新的で優れたソリューションを創り出すこともよくある。


45 ニュースの改良
 組織によっては悪いニュースがまったく上に伝わらないことがあるが、それ以上に多いのが悪いニュースが1階層上がっていくたびに改良される例。
 チームリーダー「おそらく1月は無理です」
     ↓
 プロジェクトマネージャ「正直言って1月では不安です」
     ↓
 アプリケーションマネージャ「1月というのは難題だと思いますが・・・」
     ↓
 CIO「1月には間に合うと自信をもってご報告します」
 
 原因は組織の文化として「悪いニュースを伝えた人が災難にあう」がある。
 プロジェクトが困難な状況にあることを証明できるまで時間がかかる。早くに間に合わないといえば臆病者といわれる。だから惨事がだれの目にも明らかになるまでだまっている。
 
 悪いニュースを隠すと解決できる問題が解決できない問題になってしまうことがある。


46 真実はゆっくり告げる
 本当のことをゆっくり告げる理由は
  ・企業文化として散らかっていることに気付いたものが片付けろという空気があるので、真実を告げると尻拭いをさせられる。
  ・すぐに対策をたてられないのに問題をもちだすと「泣き言」といわれる
  ・他の誰かがもっと大きな問題を暴露して自分たちの問題が陰にかくれるのをまっている。
 こうして真実を話したらつらい目にあるだけだと学ぶ。
 組織は真実を知りたくない、できるだけ長く幸せに浸っていたいのだ。


47 エンドゲームの練習
 エンドゲームの練習をするチームは、プロジェクトの早い段階でリリース基準を作成する。次に製品がリリース基準をみたしているかどうかを評価するために必要なテストを開発する。開発のイテレーションが完了するたびにこれらのテストを実行し、そのあとで簡単なレビューを行う。
 こうすることで、
  ・チームは開発のどの段階でも、製品を出荷するための残りの作業にあらためて専念できる。
  ・以前満たしていた基準から後退した場合、早い段階で気付くことができる。
  ・途中でリリース基準を見直す機会が何度もある
  もし早い段階で測定が難しいなら、大きく未定と書いておくだけでも効果はある。


48 ミュージックメーカー
 IT組織には音楽をたしなむ人が多い。
 自分の組織で周囲に田津寝て、音楽家の同僚が何人ぐらいいるかたしかめてみよう。結果はiPadへ


49 ジャーナリスト
 プロジェクトマネージャーが、なんのためにプロジェクトの状態に注意を払うのか、それを見失うとジャーナリストになってしまうことがある。プロジェクトの状態を正確に描写するのが目的になり、プロジェクトの成功とは別の成功をおいかけてしまうのだ。映画評論家と似ている。


50 空席
 多くのプロジェクトには「ユーザーの立場に立って、製品が完成したときにビジネスプロセスがスムーズに機能するように考える」という任務を負った人が一人足りないために本当の成功をおさめることができない。
 プロジェクトマネージャやリーダーではなく、ユーザーと製品がどのようにかかわり合うかということだけに神経を使う人をおくべきだ。(顧客サイドにいるのでもいい)
 多くのプロジェクトはこの席が空いている。


51 いとこビニー
 良い解決策を求めて議論するメンバーは、お互いを尊重している。お互いのことが好きだといってもいい。そうでなければ生産的な議論はできない。議論が流れているとき、チームのメンバーは自分たちのアイデアを議論を精査することは攻撃ではないとしっている。最高の製品を効率的な方法で完成させようとしているだけだ。
 経営陣やチームリーダーの発言はたとえ好意的でも、悪意がなくても同じようには受け取られない。仲間内(いとこのビニーだとわかっているから)安全なのだ。議論は上下関係を確立するためでも、個人の知識をひけらかすためでもない、相手のアイデアを試し、進化させようとしている。


52 機能スープ
 人は普通自分の要求が最も大事だと考える、同じ組織でも場所が違っていたり顧客が違ったりすれば、自分たちの独自の機能がほしくなる。その要求がビジネス全体の整合性を考慮していないのも普通のこと。
 この問題にアナリストが適切に対処しなければ、無関係の断片をはぎあわせた製品ができることになる。
 そうしないために
  ・何がプロジェクトの目的で、何が目的でないか、可能な限り早い段階で明確に定義している。
  ・プロジェクトのスコープを、入出力データの正確な定義と対照して宣言し、つねに更新している
  ・明言された目標に寄与せず、プロジェクトのスコープの範囲外であることがあきらかな要求は鉄の意志をもって拒否する。
  ・新しい要求は、承認・変更・追跡という一連のプロセスを通して、その過程でプロジェクトの目標と比較評価する。
 機能のスープを避けるには自制が必要。スープになって困るのは断片的な要求をしたひとではなく自分である。


53 データエラーの真犯人
 データベースソフトの品質より、処理するデータの品質の方が劣っているのはよくあること。
 でも、数の少ない方がシステムの品質低下の原因とされ、ソフトの方を変えようとする。
 データが壊れているなら以前のバックアップが使えるし、同じデータを複数のシステムに別々に記録している場合に自動データクレンジグが使える。
 しかし、データの品質が低下する最大の原因は変更で、そのような損傷は手作業でなおすしかない。他の方法を空想してもツケを先延ばしにするだけだ


54 その名は「ベン」
 ベンは素晴らしい数学の才能をもつエンジニアである。通常のプロジェクト業務の他に、一人で解決できない問題を抱えている人たちを手助けする。問題がベンの職務の範囲外であること、部署の範囲外であることさえある。でも仲間と一緒に考えているうちに、たいてい良い解決策を思いつく。
 ベンは仕事を楽しんでいる、仕事を愛し、仕事にやりがいを感じ、仕事をクールだと感じて、決して金のために働いているのではない。
 ベンはいたるところにいる。さまざまな仕事をしている。そして扱いやすい。だから扱いを間違えやすい。
 あるマネージャは欠員がでたときベンに仕事をまわして欠員を補充しなかった。最初はよかったが、仕事が耐えられないレベルに達したとき、ベンは仕事が楽しくなくなって会社を去った。
 ベンの仕事はすぐみつかるだろう。でも、マネージャはベンを見つけるのは難しいだろう。


55 ミス・マナーズ
 仕事の結果と仕事をした人間がいっしょくたにされるのは間違い。
 人を批判するのをさけようと、礼儀をまもっているのは、弱気。
 こういったミス・マナーズの職場では批判は許さないという暗黙の掟がある。


56 知力の集中
 一つの演目に集中したほうが舞台はうまくいく。
 プロジェクトもフルタイムで参加したほうが、切り替え時間の無駄がなく、個人のパフォーマンスは最高になる。


57 野球に泣くなんてのはないんだ!
 自分の仕事に情熱的になれる人をプロジェクトに投入することは、成功の秘訣である。
 情熱は時に爆発するが、その後始末くらいは高い目標を達成するために支払う代償の一部にすぎない。
 仕事を大事にしていなければ、仕事に感情が入り込むこともない。


58 暴力脱獄
 仲間同士の意見の違いを「コミュニケーションの失敗」にするのは間違いである。
 仕事の対立はプロらしくないというのは思い込み。
 品質と生産性は常にバランスをとる(対立している)。
 そこらじゅうにれっきとした対立があることを認めよう。そして実証された対立解決手法を使おう。
 その方がコミュニケーションの対立より確実によい結果が生まれる。


59 期日はかならず守る
 必ず期日をまもるなら、品質基準はゆるんでいるはずだ。
 組織にあるプロジェクトのかじ取りのための5つの「レバー」
  1.人 2.技術 3.スコープ(どのような機能を開発するか) 4.時間(いつ完成させる予定か) 5.出荷時の品質基準
 時間がたつにしたがって、使えるレバーは4と5だけになる。


60 フード++
 「千と千尋の神隠し」は夏の公開に間に合わせる為に長時間働くことにした。そのためチームの誰かが全員の夜食の用意をするようになった。一緒に調理して食事して後片付けをすることでチームの結束は強くなり、映画は期日までに完成した。
 食べ物は人々を結びつける。
 一緒に食事をしたからといって、チームが成功する保証はない。しかし、成功するチームは一緒に食事をつくって食べることで生まれる豊かな対話を利用することが多いようだ。


61 ほったらかしの成果物
 あらゆる成果物のなかで間違いなく必要なものは製品だ。しかし他のものはどうだろう。
 もし、品質管理や再利用のために作成する成果物があるのなら、その作成のリソースにはスポンサーを探すべきだ。
 コストにみあう効果があるかどうかを検討しないで、あれをつくれこれをつくれというのは簡単。しかし資金も人間も出さないのに現場がすんなり受け入れるとは限らない。また作成されてもほったらかしになる。
 アイデアがいいならスポンサーを探すべき。


62 隠れた美
 指定された機能が果たせるかだけが仕事の成果であり、美観など関係ないというのは間違い。
 すべてのデザインには美的要素があり、すぐれたマネージャは部下のデザインを詳細に見る能力と意思を持つ。すばらしい設計を評価する。
 すばらしいデザインはそぎ落とすことにある。どんなに機能をつけたしてもデザインはよくならない。


63 わかりません
 「わかりません」をやる気のない証拠とみる組織は、すべてのことを知ることができないという真実を無視している。
 「わかりません」ということで、助けが得られる機会が得られるのをすてて、余計な時間をかけている。
 「わかりません」が言えるのは、人々が安心して助けを求められるということ、あらゆる階層で真に協力を推し進め成果を得ることができるということ。


64 レイクウォビゴンの子ども達
 大規模チームのメンバーの間では、ソフトウェア工学の能力にケタ違いの差があると何十年もいわれている。
 それなにに、成績評価はほぼ全員平均以上の評価をうける企業が多すぎる。
 この場合マネージャが真実をつたえているのは本当に中程度のぶかだけで、成績優秀な部下に彼の仕事の素晴らしさを伝える機会を失い、成績の悪い部下に、このままでは首が危ないと知らせる機会を失う。
 そのかわり、成績の悪い部下のコーチ役になったり、任務を縮小して失敗しないようにしてしまう。そんなことより恐れず建設的に向き合った方がよい。水準に達していないことを知れば努力して人並み以上になるかもしれない。


65 共同学習
 プロジェクトが始まるときに、将来どのような状態になるのが望ましいのか、個人やグループが理解していると考えるのは非現実的である。
 つくり手は消費者が要求を完璧かつ正確に列挙できないとしるべきだし、消費者は作り手が要求を正しく理解できると考えてはならない。
 必要なのは共同学習である。
 開発が始まらないうちに要求仕様書の作成を済ませようとするのは間違いだ、初期プロトタイプや試験モデルをつくり発見と学習を繰り返すべきd。
 ステークホルダーの中には、自分は何が必要かわかっているという人がいるが、そのような人が必要だとするのは目の前n問題に対して思いついた解決策で、もっと大きなニーズに応じられる解決策ではない。全員が理解するのは問題であって、解決策はそのうちでてくるものである。
 学習は早くはじめるのがよい、プロジェクトが進行するとアイデアが固まってしまう。早いうちに機会をとらえイノベーションを成功させよう。
 ステークホルダーはそれぞれ何かを、それもかなり多くのことを知っている。互いに教えあるために共通の言語が必要で、モデリングを繰り返し、それをすてて学習は進む。
 もっとも難しいのは共同学習に努めることが必要だと認識すること。


66 魂の仲間
 仮に「ゲリラ」チームと呼ぶ開発チームがある。アジャイルの世界によくみられる。非常にイノベーションに優れたチームである。
 特徴は
  ・予定された会議は嫌うが臨機応変に少人数の会議を何度も行い、そのほとんどが設計会議になる。
  ・アイデア、デザイン、ToDoリストをメモするのにホワイトボードを好む
  ・不完全で高水準な要求定義書をもとに作業する。せっけいぶんしょはすべて省略し、開発プロセスのごく初期からコーディングに移る
  ・大量のコードを破棄しては書きなおす。機能のデモを行うと、すぐに改良にとりかかる
  ・これらを非常に速く行う。一般的な機能の開発にかかる時間は1-3日、極めて複雑なら10日、多くのタスクは半日で完成してテストできるようになる。

 従来型のソフト開発では「問題を見つけて修正するコストは開発サイクルが進むにつれ急激に上昇する」という考えに基づいて、できるだけ早く要求と設計をきちんと定義しておきたがる。またきちんと機能するソフトの構築と検証には時間がかかるので、それは1回か2回だけとする。

 ゲリラチームは何を構築すべきか発見する過程で迅速にコードを開発してテストするため、実に大量のコードを破棄する。こういったチームは新製品のバージョン1にむいている。得意なのは比較的新しい問題涼気を探索し、革新的なソリューションを考案すること。耐久性と安全性に優れたコードもつくれるが、イノベーション志向である。
 たいていは一人か二人の魅力的なリーダーの周りに有機的に発生し、ゆっくりと増えていき、結束が弱まるとあっという間にバラバラになる。命令によってつくることはできないし、ずっと維持することもできない。
 ゲリラチームに仕事をさせるなら新天地を与え、システムが確立してしまったら他の新天地を探せるようにすべき。

 最後に「偽物が多い」、このモデルはあらゆるレベルの開発者にとって魅力的なため、少人数チームの多くは自分たちをゲリラチームだと思っているが、本物は稀。まかせるなら相手が本物かたしかめよう。


67 十字穴付きねじ
 ヘンリー・F・フィリップスが十字穴付きねじを開発したのは1930年代初頭だが、使われだしたのは1985か1990年ごろ。
 明らかに優れたアイデアであってもすぐに受け入れられるとは限らない。
 トーマス・アルバ・エジソンは、何度も新しいアイデアを考え付く能力があった。
 一つのアイデアを推奨する人はプロモータであり、過去にいくつもの優れたアイデアを考え付いてきた人はイノベータである。イノベータになるには何年もかかるが、地道な努力を伴うが、予想外の恩恵がある。実績のあるイノベータの提供するアイデアは人々にうけいれられやすい。


68 イノベーションの予測
 プロジェクトのイノベーション・・・チームがそれまで経験したことのないなにかをやるということであり、メンバーが問題を違った方法で解決できるかどうかにプロジェクトの成否がかかっているということである。
 一方で完成する時期をかなりの精度で予測する必要がある。
 マネージャは開発者にイノベーションの時間を提供しつつ、顧客にはプロジェクト完成について正確な予測を提供しなければならない。
 どちらかの領域に迷い込まないためには、開発プロセスのイテレーションをおこなうこと、それぞれのイテレーションの器官は1回につき1-4週間で、1-3までは未知の要素を洗い出し、開発作業に持ち越す不明点を減らすためにあてられる。この間のコードは次のイテレーションに使われる必要もない。
 決められた開発期間の中でイノベーションを必要とする問題領域を何度か通るようにすることで、バランスをとる。
 プロジェクトの成功の源はイノベーションであるが、予測可能性も必要である。


69 マリリン・マンスター
 「マンスターズ」はモンスター一家のはなしである。金髪美人のマリリンは一家の親戚で美人な人間の容姿をもっているが、一家の仲では不器量で役立たずといわれる。
 マリリンのような人生を送っている開発者の組織は、マネージャが主役だ、開発者はコストの一部であり、取り換えの聴く部品だと思われている。給料もマネージャのほうが断然多い。変化形として営業があらゆる権限をもている組織もある。
 反対に開発者の能力の差が大きいことを理解して、よい開発者を雇うために努力している組織もある。そのような組織は自社のソフトウェアまたは製品の主要部分を自社で開発しているところが多い、
 開発者がキングの文化が行き過ぎると、自分の仕事を最適化しすぎて、プロジェクト全体の最適化を妨げることがある。
 組織の成功のために品質とイノベーションが重要であり、そのためには本当に有能な開発者が必要である。
 あなたが優秀な開発者なのに、マリリンのような気持ちなら、他の家庭を探すべきである。


70 ブラウン運動
 プロジェクトの最初に人数を投入するのは間違い、ビジョンを形成するのは少人数のグループである。
 Linuxのビジョンは一人がつくり、C++もそうである。


71 音吐朗々
 プロジェクトの目標はもっとも高いレベルでの要求と制約である。
 相容れない個人的目標がある人間たちがまとまってプロジェクトの成功に向かって働くために必要である。
 よい目標は、ステークホルダーが対立しない目標になっており、そして目にみえるところに常に掲げられるべきである(会議室では椅子を与えよう)


72 安全弁
 チームは仕事の緊張に立ち向かうため、ガス抜きの方法を考え出す。
 「シークレット・アサシン」・・・それぞれのメンバーに標的が割り当てられ、同時に他のメンバーの標的になる。みなはナーフガンを携えて標的に忍び寄るが、標的が自分のデスクにいるときには暗殺することはできない。
 シークレット・アサシンが生産性を高めることがわかっている。
 ただし、チーム内で自然に発生したものでないと意味がない。上司やマネージャが指示しないこと。
 みつけたら、黙ってみのがそう。奨励もいけない。


73 バベルの塔
 お互いが使っている言語が、同じ意味か確認することは重要だ。
 しかし組織は常に変化し、言葉の定義も変わっていくものだ。それでも定義にこだわっていくことが大切
 チームが一貫した言語をつくっても、その努力は外部から評価されないが、言葉の定義につりつかれたようにこだわるチームは成功するチームだ。

74 サプライズ
 ささやかなサプライズ報酬を提供する弊害。
 こんなはした金のために、貴重な家族との時間をすてたのではないといわれる
 プロジェクトが終わったらどんなサプライズ報酬?がもらえるかと期待する人がでる


75 冷蔵庫のドア
 すべての情報を伝える必要はないが、すべての情報を開示する意味はある。
 冷蔵庫のドアのように、みんなにみえるところ(廊下や作戦会議室)に成果物や進捗状況をはっておく。
 冷蔵庫のドアは面倒な文書配布やバージョン管理の手間をはぶき、メンバー間の信頼関係をよくし、不完全な点やスケジュール遅れを他の人に見つかるのを恐れる必要がなくなり、ねつ造はなくなる。全員同じ基準で作業できるようにあうる。


76 明日には日が昇る
 マネージャは将来の進捗の平均を、過去の進捗の平均より上になると信じている。
 しかし、それは危険だ。
 たとえ、現在の進捗が偶発的要素による不幸な結果であっても。この先もそういった事態が起こらないという保証はない。
 いままでの進捗速度で将来をみて、スケジュールの変更やスコープの変更を行うのが賢明である。


77 パイリングオン
 アメリカンフットボールのパイリングオン・・・すでに倒れているボールキャリアの上に守備側のプレーヤーが飛び乗る反則行為
 プロジェクトを失敗させたかったら、パイリングオンをおこなえばよい、すなわちそのプロジェクトをもっとよくすると称して追加機能をいれるのだ。
 開発期間を複数のイテレーションに分けているプロジェクトでは、パイリングオンに対する免疫がある。初期のイテレーションで重要な機能のみを実装し、その他は最後に追加するのだ。追加するコストが、効果より高ければ機能追加をやめるという選択肢をとることができる。

78 変更の季節
 スコープ(白線)の定義はプロジェクトへの影響が大きい。
 しかし、いつでもスコープが変更できるようにすることは、開発の遅れを引き起こす。
 イテレーションの間に限定すべきである。もちろん長すぎるイテレーションはいけないが。


79 製紙工場
 文書を作成する人に「なぜ」と聞くと「プロジェクトのこの段階ではこの文書を作成しないといけないから」という。
 「その文書は正確にどういうことを書くんですか?何のための文書ですか?誰が意思決定に使うんですか?」ときくと、そこまでわかっていないことが多い。このようなプロジェクトは製紙工場になっている可能性がある。
 みんながコピーを欲しがる。文書さえあれば、プロジェクトの目標に貢献する有益な仕事をしているかどうかを検証しなくなる。
 製紙工場でないプロジェクトチームは自動的に文書をつくるのでなく、その他の方法で進捗状況を伝えることを考える。ホワイトボード、テレビ会議、ブログ、プロトタイプなどだ。成果物はプロジェクトライブラリに置き、だれでも自由に入手できるようになっている。
 重要なのは、作成される文書はすべて何らかの明確なニーズを満たすもので、その内容はプロジェクト全体の知識にもとづくべきであるということ。


80 オフショアの愚行
 サブコンポーネントのインターフェースの複雑さを最小限にするようにシステムを分割するように、開発チームのワークフローの設計もするべきだ。
 サイト間コミュニケーションとサイト間イテレーションのコストを甘く見積もってはいけない。
 
 オフショア開発資源を利用するなら
  ・イテレーションはローカルで、一つのサイトで行う
  ・オフショア開発モデルの最初の数回は国内で同じことをするより時間がかかると認識すること
  ・オフショアチームは国内開発チームとかわらない、やりがいのある仕事をしたいと思っている
  ・各サイトの目的を育てる。活気あるサイトは具体的使命がある。雑多で多数の開発をおこなっていて、共通の目的もなく各チームをサポートするサイトはエネルギーも士気も低い。(国内でも同じだ)


81 作戦会議室
 専用の作戦会議室をもつプロジェクトはまっしぐらの成功へ向かう傾向がある。
 直接会って存分に対話することがプロジェクトの成功のために必要だという姿勢の表れ
 成果物を壁に貼って掲示するのはチームの結束を強めるためにも、作業を推敲するためにも重要だという主張の表れ
 プロジェクトのメンバーは作戦会議室の近くにいて、プロジェクトマネージャは作戦会議室にいることが多い。
 ただし、ただ作戦会議室のスペースを確保するだけはだめで、作戦会議室をプロジェクトの活気あふれる有機的なプロジェクトの要素にすることである。


82 何のにおい?
 組織の中にいる人は、組織の根底にある生命力にも腐敗にも気が付かない。それはパン屋のにおいのなかでも鴨の農場でも人間はにおいに慣れてしまって気が付かなくなるようなものだ。
 外からの新鮮な鼻を持ち込み自分の周りのにおいをかいでもらおう。そして次の行動をきめよう。深呼吸して何もかえないか、窓を少し開けるか、燻蒸消毒するか

83 身につかない教訓
 プロジェクトが終わってから反省し教訓を引き出すのは難しい。
 問題がチームの外にあったり、内にあったら変化を起こすのは気が遠くなるほど難しいからだ。
 反省会のプロセスがガス抜きで終われば、公表されるのは所見ばかりでアクションアイテムはない。
 反省で成果をあげる勇気ある組織になりたければ、チームの権力の内外に実現可能で明確なアクションアイテムをあげることだ。

84 生半可なアイデアの美徳
 チームのメンバが生半可なアイデアをだしあえる文化があるべきだ。
 人は新しく考えるより、あるものを改良するのを好む。たいていのアイデアは根気よく取り組めば改良できる。すぐれたアイデアでなくてもたたき台になる、議論を通じてアイデアは成熟し向上する。
 生半可なアイデアを封印すればイノベーションがおきる可能性を封じてしまうだろう。

85 リーク
 時間とコストは、注意深く測定されるカテゴリーからさほど厳しく測定されないカテゴリに逃れる傾向がある。
 これは割り当て時間いっぱいまで作業してしまって、まだ完成していないからと別の作業に、今使っている時間をわりあてたり、締め切りがまだ先の作業に割り当てたりすることである。割り当てが残り少ない仕事、締め切りの近い仕事は注意深く観察されるからである。
 こうしてリークはプロジェクトがコントロールを失う。


86 テンプレートゾンビ
 製品を完成するために必要な思考プロセスではなく、テンプレートによって作業をすすめる。
 こういうチームは文書の内容と検討するより、標準文書を作成することに懸命になる。
 テンプレートが埋まっていればよしとするのだ。
 アイデアがテンプレートの項目にあわなければ無視したりする。
 テンプレートはチェックリストやフレームワークになる良い方法だが、固定化して埋まっていたら成功と考えるのは間違いである。


 
アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン

アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン

  • 作者: トム・デマルコ
  • 出版社/メーカー: 日経BP社
  • 発売日: 2009/10/22
  • メディア: 単行本



nice!(0)  コメント(0)  トラックバック(0) 
共通テーマ:

ビューティフルコード (THEORY/IN/PRACTICE) [プログラミング]

いろいろな人が美しいコードとはなにかで書いた本。
印税はアムネスティに寄付されているそうだ。
33の章がそれぞれ独立しており、興味ある章をよむことができる。範囲もコードそのものからデバッガまで広い。

第1章 正規表現マッチャ ブライアン・カーニハン
正規表現・・・テキスト中のパターンを指定する記法の一つ
正規表現にはバリエーションが多いので、使うときには注意が必要
正規表現は有限オートマトンの記法として発明されたもの。
プログラミング作法を教えるうえで、正規表現にふれるため、grepのコードなどを使おうとしたが500行以上あった。
そこでページ1枚におさまるような、正規表現の基本的な考え方がわかり、有用なコードをかいてもらった。
それが「プログラミング作法」の9章に掲載されている。
この内容についてポイントを解説。
改善案を解説。
実用性の検討
発展課題の例
このコードが美しいポイント・・・正規表現の機能がうまく選ばれている、再帰がうまくつかわれている、ポインタというプログラミング言語の特性をうまくつかっている。

第2章 Subversionの差分エディタ:存在論としてのインターフェース カール・フォーゲル
Subersion・・・オープンソースのバージョン管理システム
差分エディタ・・・ディレクトリツリーの差を表現する、また他方のツリーに変換するときにも使われる

Subersionの差分エディタはプログラマが良いデザインに乱す複数の特性を体現している。
 ・問題を非常に自然な境界に沿って分割しているので、新しい機能を追加するとき、だれでもいつ何のためにそれぞれの関数を呼べばいいかわかる、効率を最大化するための機会をごく自然に提供する。追加作業を簡単に組み込める。設計が機能強化や改訂に対して弾力的。
作ったのは1人でほんの数時間。
Subversionの処理解説。リビジョン番号とツリー構造、差分エディタのインターフェースの解説、最初はかなり面倒だったが、ジム・ブランディが作ったシンプルなものが最終的に使われている。コードがのっており、最初に処理の内容がテキストで1ページ分くらい書かれている。さらに関数の使用法が2ページ半くらいあって、コードがコメント入り2ページかかれていた。
 結果として深さ優先順にかかれているそのコードは、最初は美しいと思わなかったが、使用しているうちに美しいとおもうようになったという。
 一つのツリーを編集して2つ以上の異なる変更を行う必要がある場合の例。
 Subversionでツリーを変更する操作は共通のやり方に統一されている。だから既存のコードを学ぶために費やされる時間は少なくてすむ。また設計方法にあれこれ悩み迷う必要もない。それは大きな利点。


第3章 私が決して書かなかった、一番美しいコード ジョン・ベントリー
 コードを削ることで機能を追加する。
 これを語るためにクイックソートのプログラムの実行時間について新しい分析をする。
Cで実装したクイックソート12行。
最悪の場合、クイックソートがn個の配列要素を整理する時間はn×n時間。
最良の場合は2を帝都するNの対数=2を何乗するとNになるかの答えになる。
ではnこの値がランダムに並んだ配列では平均何回比較を行えば整列できるか。
ホーアの分析は美しいが、難しい。今回は実験でたしかめながらその分析にちかいところまでいく。
最初のCプログラムに改良を加えながらコードを削っていく。
次にクイックソートを解析するのに使ったプログラムの発展をまとめる。最終的には漸か式に解釈していた。
おまけの解析として「データ構造は凍りついたアルゴリズム」ならクイックソートのアルゴリズムが凍りつくと2分木だとして、2分木に要素を一つ挿入する平均コストについて述べていた。
プログラムは傾倒だって導き出された正しいものだが、実装はしていないと筆者はいっている。美しさが損なわれないようにだって。
プログラムの名言がのっていた、
プログラムを書くヒント・・・プログラムの解析(計測のしくみをつけて代表的データで実行する)、小片のコード(プログラミングは実用スキルであり、マネと練習で手に入る、美しいコードを読もう)、ソフトウェアシステム(ここに表れている原理は大きなプログラムや巨大システムでも使える)


第4章 ものの見つけ方 ティム・プレイ
 現在のコンピュータの最も多い使われ方は検索である。データの増大で探し出す仕組みはより重要性をましている。
 探索手法を選ぶことにもトレードオフがある。
 
探索に要する時間
 実際に検索を実行する時間、探索プログラムが完成するのを待つ時間

著者のブログへのトランザクション記録を例に探索プログラムを解説。
正規表現(Ruby)で探す方法解説、

記事の参照頻度を計算するプログラム
基本的検索パターンはキーに基づいて対応する値をみつける(連想記憶)、Rubyプログラム。

実行時間をくらべるためにPerlでも書いてみると実行時間は半分だったので最適化を行う例

誰が、何を、いつ取り出したかを調べるプログラムを作る。
巨大なハッシュ表を使う例。
2分探索での例と、そのトレードオフ解説。

ウェブの探索も基盤はテキスト検索。
変わったのは結果のランク付けを行うやり方
ポスティング・・・ドキュメントを全部読みながら、各単語について「単語XがドキュメントYの位置Zに現れた」を生成、単語で整列させた固定長のデータ。
ポスティングを扱う自然な方法は2分探索。
探索自体は(複合探索も含めて)難しくないが、結果のリストを並べ替えて、良い結果=品質の高い結果が短い時間で現れる、が上のほうにくるようにするのは難しい。
Googleではページランクで実現している。
ページランク・・・あるページについてそのページを指しているハイパーリンクが多数あると人気があるとみなす。
巨大な検索エンジンが、データ量やユーザ数の増大に追従してきたのは、並列処理を大規模に適用(小さなコンピュータに処理)してきたことによる。ポスティングは並列処理にむいている、例えば英単語ならアルファベット順に26にわけるのは容易。

コンピュータアプリケーションのほとんどが、データを格納しておいてそれを内容に基づいて探して取り出す処理を含んでいる。ウェブ検索はその代表。
プログラマにとっては様々な種類の探索プログラムを実装することは楽しいことの一つ。


5章 正しく、美しく、早く(この順番で):XML検証ソフトの設計から エリオット・ラスティ・ハロルド
XMLの入力検証を行う2つのルーチンJDOMとXOMのはなし・
JDOMからわいたアイデアはXOMに伝わり、速度の向上を目指すたびにコードが美しくなった。
最新の最適化コンパイラ JTT,RISCアーキティクチャ、マルチコアCPUの影響を考慮すると、美しさの改善=速度の向上になる。

XML検証の役割
 XMLの正しさを完全に保つため、以下の2つの冗長性をチェックする
 1 入力に対する検証。開始タグには終了タグがある、規定された位置にあるなど、文書が妥当であるか検証。
 2 出力に対する検証。XML APIを使ってXML文書を生成するとき、パーサはAPIを通して受け取った文字列すべてをXMLの文法に合っているかどうか確認することで、出力全体が正しいXMLであることを保証する。

JDOMの最初のベータ版での問題とその改善を解説。
 最初はJavaで普通にかいたが
 BNF記法をまねてコードはながくなったがわかりやすくなった
 検証方法を工夫して最適化
 重複チェックを省略とか
 キャッシングとか

まず設計をちきんとすること、CPUが早くなるのだからプログラムが最初の段階より遅くなることはない
きちんと設計して上で実行性能について検証すべき。
早いけれど醜いコードを美しくするのは大変
美しいけれど遅いコードを早くする方が簡単。


6章 テストのための統合的フレームワーク:脆さから垣間見る美しさ ミカエル・フェザーズ
プログラマは実践を通して作り上げた「よいデザインとはなにか」の見解を持っている。
 Publicを使おうとするときは普通は悪いデザインだと考えたり、実装のため継承を使うときには継承よりも委譲のほうが子好ましいと思い出したりする。
しかし、経験則はかえって仇になることがある。
FIT・・・ソフトウェアテストを自動化するフレームワーク
 実行可能なアプリケーションテストをHTMLの表で書くことができる。
 HTMLの表ごとにフィクスチャオブジェクトを生成、結果が期待通りかチェックしてセルを塗りつぶす

FITは美しいコード、初期リリースの一つをみながら、設計について著者に再考をうながした部分をみていく。

FITの3つのクラス、Parse,FIxture,TypeAddapterの解説

フレームワーク設計のもっとも大変なところは、そのフレームワークを使うコードを制御できないこと。
FITは他のフレームワークと違う。フレームワークの核になる部分はほとんどすべてデータさえもPublicである。
これはFITがオープンフレームワークでフレームワーク全体が拡張できるようにデザインされているから。
FITのHTML構文解析のすべてをクラスParseがおこない、コンストラクタ内で構文木全体をつくりあげる。
それまでコンストラクタであまり多くのことをやらないという経験則をうけいれていたが、Parseは違うしかしエレガントである。HTMLを扱うように設計を制限したことで、フレームワークを小さく保ち、理解しやすくしている。
正しいことを定数に固定してしまえば、得るものは大きい。
また隣への参照をもっておくためにコレクションオブジェクトを使っていない、代わりにpartsとmoreを直接のリンクとして使っている。

産業界では困難にブチ当てるスタイルの学校で学んできた人が多い。選択を制限して拡張性を保とうとする経験則を身につけているひとが多い。
FITはフレームワークをできるだけ柔軟で簡明に作るようにするため、フレームワークを数十のクラスに分解するのではなく、各クラスを内部でどのようない構造化するかに注意を払い、ユーザーが通常のコースからはずれたいと思ったときはそうできるようにメソッドをPublicにするという過激なもの。
そうすると、変更は困難なものの、他の人は利用しやすくなり、新しいものを作り始める。
著者にとってFITは美しいフレームワーク。


7章 ビューティフル・テスト アルベルト・サボイア

テストの本質は組み合わせや探索の問題。
物事の組み合わせがテストを美しくする。

テストを美しくする3つの手法
・簡潔さゆえに美しいといえるテスト
 数行のテストコードで対象コードの基本的な動作を文書化したい検証したりできる。JUnitを使って検証
・コードの優雅さ、保守性、テストしやすさを増す方法がわかるために美しいと言えるテスト
 コードをもっと美しくするのを助けてくれるようなテスト。テストを書いているうちに気が付く。
・幅と深さゆえに美しいテスト
 綿密かつ網羅的なテストはすべてのケースについてコードが期待通り動くという確信を強化してくれる。

例題に2分木探索をあげていた。
 2分木探索は非常に簡単でありながら実装を間違いやすいので格好の例

著者の2分木探索のテストの初期戦略
 ・スモークテストからはじめる・・・そのコードをもっとも基本的な形で使用した場合正しいことをすると確認するテスト。
 ・境界値のテストを付け加える・・・データの配列と目的の値それぞれについて境界について考える
 ・さまざまな種類のテストを完全に尽くして行う・・・ランダムなテスト
   1 データ量が多く、かつ多様な入力セットを生成する方法・・・著者の実装を(負の数もはいる)をあげていた
   2 どのような入力にも適用できる、汎用的な検証方法・・・定理を4つをあげて解説
 ・最後に実行性能に関するテストを付け加える・・・システムクロックでは早すぎて測定できないので比較回数を使う。

テストのコードを書くことは対象コードをかくのと同じくらい創造的で挑戦的である。
テストとは自分のカンバスから一歩下がって自分の仕事を批判的な眼で異なる視点からみること。


8章 画像処理のためのその場コード生成 チャールズ・べゾルド
コードとデータは分けられているのが普通だが、障壁が破られることがある。コンパイラはコードとデータの区分がない。
その場生成コード(on-tye-fly)・・・コンパイラ出ないプログラムが実行中にコードを生成すること
その場生成コードはWindows1.0にでグラフィカル関数に広範囲に採用されている
限られた時間で動作する必要のあるサブルーチンが多くの演算を繰り返し実行する。その反復において条件分岐する。
こういったときその場生成コードは実行速度に大変有効にはたらき、著者はそれを美しいと表現していた。


9章 下向き演算子順位解析 ダグラス・クロックフォード
下向き演算子順位解析は1973年にボストンで開催された第1回POPLシンポジウムにおけるボーガン・プラットによる発表論文の題名。
再帰下降解析とロバート・フロイドによる演算子順位を用いる解析手法の良い点を組み合わせた解析手法を提案。
理解しやすく、実装しやすく、使いやすく、極めて効率的で非常に柔軟性があるといわれているが、著者はさらに美しいといっている。
論文ではLisp言語でほとんど労せずしてトークン列から解析木を構築しているが、Lispに構文がないことが称賛されがちなんでうけない。
また普通の性的手続きではこの方法は使わないのでうけない。

しかし今はJavaScriptがある。
これをつかってトークンの配列を生成し、配列を順次みながら解析木を組み立てていく方法を解説。

構築した構文解析器は容易に拡張可能。


10章 高速ビットカウントを求めて ヘンリー・S・ウォーレン
ビットカウント・・・コンピュータの1語の中で「1」であるビットの数を数えるアルゴリズム
この命令を実装していないマシン上でビットカウント関数を計算する方法について述べる。
ただし、RISC/CISCコンピュータが普通に備えているShift ass ansa load、条件分岐などは使えるとする。
ビットカウントの問題
・コンピュータの1語の中で1の立っているビットを数えるkと
・配列中の要素など多数の五の中で1の立っているビットを数えること

基本的な方法(シフトする)から始め、
分割統治法(16ビットの語に足してビットカウントを計算する方法があるとして、32ビットなら右と左半分に並列に操作を行う)応用事例は2分木探索、クイックソート、語のビットを反転する方法への適用など。
論理回路を使う方法を解説。

ビットカウント命令の用途
集合をビット列で表しているばあに、集合の大きさを求める
エラー訂正コード


安全な通信:自由のための技術 アシシ・グルハッチ
著者がLFCのために一人で作ったセキュアメールシステム(Cryptonite)の開発とその成果
・このシステムは大部分がヒマラヤ山脈でVSAT、無線LAN、Bluetooth FGPRSとCDMAらの無線技術を使ってかかれた
・既存のコードライブラリを最大限に再利用する。そのためPerlを選択
・エンドユーザ向けアプリではシンプルで使いやすいことが第一
・スタートダッシュのために動くプロトタイプを構築して本質部分の機能を実装してみてから
・システムはできる限りシンプルに保つ
・サクサク動くようにつくる
・ソフトウェアアプリケーションは生もの、更新、機能増強、テスト修正、マーケティング、サポートを何年も行う必要がある
・解こうとしている問題にあなたが興味をもっていること

セキュアなメっセージ送信の複雑さを解決する。
 鍵の認証問題方式の解説
ユーザビリティを保ち、セキュアであるものを作る。

基盤
設計上の目標と決定
基本システム設計
テスト郡・・・インターフェースとコアは切り離しているから別々にテストできる。テストコードの例
動作するプロトタイプ
整理し、つなぎ換え、動かすを続ける
ヒマラヤ山脈でハック
見えざる手が動く・・・市場にでていたから開発の優先順位をあげることができた
速度が問題・・・・IMAPにキリかえてメールボックスが大きくなると速度がおちる。その対応
これらについて解説。

個人の権利のための通信プライバシーについて必要性を解説
文明をハックする・・・コードは世界を何度もかえてきた。グローバルな数学的に保護された開かれた社会を実現することはマシンをつかさどる我々の責任。


12章 BioPerにおける美しいコードの成長 リンカーン・シュタイン

生物情報学(バイオインフォマティクス)はDNA配列解析マシンやマイクロアレイ技術による複雑な遺伝子発現パターンのスナップショットなど、テラバイト単位のデータを生成し、それをフィルタにかけたり、保存したり、操作したりデータマインニングするためのソフトウェア工学を応用する学問分野
ウォール街のソフトウェア工学と類似して足が速くなければならない。エクストリームプログラミングやあじゃいる開発手法、迅速なプロトタイピングと稼働を可能にするツールキットを好む。またデータの資格化やパターン認識に特に重きがおかれる

BioPerlは生物情報学向けに開発されたラピッド開発ツールキットのひとつ。Perlで書かれた再利用可能なコードを集めた広範なオープンソースライセンスライブラリ。DNAとタンパク質の解析、京討議の構築と解析、遺伝子データの解釈など生物情報学において最もよく扱う問題を処理するモジュールを提供する。

Bio::Graphicsモジュールを使ってゲノムとその前アノテーションを迅速に視覚化できる。
どんな風につかい、どんな出力があるか解説

Bio::Graphicsの要件
・問題のオープンさ
・フィーチャーの密度
・倍率の扱い
・対話的ウェブアプリケーションでの活用
・画像形式に依存しないこと
・データベーススキーマに依存しないこと

Perlはコード例をざっと読み通して、設計ロジックの全般的な感覚をつかめばよいといっていた。

Bio::Graphicsの設計プロセス解説
・オプション設定
・オブジェクトクラスを選ぶ Bio::Graphics::Panel Bio::Graphics::Track
・オプション処理
・コード例
・動的オプション
・Bio::Graphicsを拡張する
・ウェブ開発者をサポートする
・出版向け品質の画像をサポートする
・新しいグリフの追加

他の開発者たちに使われるソフトウェアの設計はチャレンジング。
Bio::GraphicsはPretty Goodで実装にあたり改善したいところもあるが、それでは既存のグリフクラスをかきなおさなければならないので、今の状態が最善であろうといっていた。


13章 遺伝子ソータの設計 ジム・ケント
遺伝子ソータ・・ヒトゲノムの約25000の遺伝子を素早くふるいにかけて、科学者たちが自分の研究に関係する遺伝子をみつけるための手伝いをするプログラム。約2万行のサイズの中規模プログラム。その本当の美しさは全体の読みやすさ、理解しやすさ、拡張しやすさにある。
概要紹介
 遺伝子ソータのユーザインターフェース
 ウェブ上でのユーザーとの対話管理
コードの重要な個所を注目
 少しのポリモルフィズムを使い倒す。
 フィルタで関連する遺伝子の実に絞る
数千行を超える長いプログラムを楽しく、そしてさらには美しく扱っていくためには、どんな留意点があるか議論。
 プログラミングにおける最大の制約となる資源は人間の記憶。
 コードの各部分についてそれを理解するのに必要な範囲が1画面に収まる必要がある。
 名前付けの選択がうまいこと、
 できるだけ局所的なスコープを使う
 関数は返り値を返すだけで、どの変数も変更しないようにする

遺伝子ソータはC言語で書かれた、素直なポリモルフィズムを使ったオブジェクト指向の設計になっているので、列を追加するのに簡潔なテキストファイルを編集するだけで済む。
ディスクシークも最小になるようにしている。

14章 エレガントなコードはハードウェアに合わせて進化する:ガウスの消去法の場合 
ジャック・ドンガーラ ピョートル・ラスツゼック

線形代数、とくに連立1次方程式をとくことは多くの科学技術計算の中心部分になっている。
密行列に対する問題をガウスの消去法(LU分解)で取り上げる。
LU分解は比較的簡潔で、境界要素法を用いるいくつかの科学技術計算(電磁散乱、計算流体力学)において重要な役割をはたす
 
効率の良い線形代数アルゴリズムを設計する際の鍵となる動機、データがメモリ階層の間を移動する頻度を最小にする。
考慮するコンピュータアーキティクチャ
・ベクトルマシン・・・1ステップでベクトルレジスタに格納されているかなり多数のオペランドに対して1つの演算を実行できる。行列アルゴリズムをベクトル・ベクトル演算として表現するのが自然
・キャッシュ階層をもつRISCコンピュータ・・・最初はベクトルマシンより遅かったが、CPUの性能向上でそれほど遜色なくなった。
・分散メモリ方式の並列システム
・マルチコアコンピュータ

行列データを任意の自明な方法で分割しただけでは、アムダールの法則によって述べられるスケーラビリティの問題がすぐ表面化してしまう。ほとんどの計算が独立に実行可能でない限り、並列度を増しても高速化しなくなる。

行列分解・・・行列Aに関係する問題があたえられたとき、Aをより簡単な行列の積に分解することにより、問題が簡単に解けるようになるというアイディア

連立方程式 Ax=bを解く問題を考える。
A=LU
単純版としてLU分解の素直な実装をします。n-1個のステップからなる。対角線より下をすべて0にしていく
美しさを犠牲にして効率を上昇する方法。
LINPACKのDGEFAサブルーチンを使う方法
再帰的LU分解
ScaLAPACK PEGETRFを使う方法
マルチコアシステムのためのマルチスレッド化
誤差解析と操作数について・・・実行性能をあげるためにエレガントさを犠牲にすることは受け入れられても、数値的安定性は重要であり犠牲にはできない。

将来の研究動向
ハードの変化(マルチコア)などによってソフトウェア開発者が直面する問題は複雑化しており、いま効率的なコードでも将来もそうとは限らない。


15章 美しいデザインの長期にわたる恩恵 アダム・コラワ
丸め誤差の問題など、うわべは素直で単純な数式のアルゴリズムで現実に実装するのは極めて大変というものがある。
力任せの方法では時間がかかりすぎるものがある。
データセットが異なると違うアルゴリズムの方がうまくいくこともあるので、美しいコードと美しい数学は必ずしも同一物ではない。
CERNの数学ライブラリを例に理論と実践の違いを解説。

コードの究極の目的は使われること。
信頼できるコードのなかに美がある。

数学ライブラリの最大の問題点の一つは丸め誤差と浮動小数点演算が解の不安定さや間違った結果になること。
各アルゴリズムがうまく働く範囲をきめる、丸め誤差が互いに相殺するように書く必要がある。

外側の美しさ
CERNライブラリはアルゴリズムは非常に明確な方法で記述されており、どのルーチンも何をするのか説明が付されている。
言語は問題でなく。どこからでも呼び出せるインターフェースがあるのがよい。

内側の美しさ
コードの実装の詳細
美しいコードは短い。コードが何をするのか理解するために数百行のコードを読む必要はない。
サブシステムのルーチンに分かれており、他のドライバルーチンからも呼び出すことができる。
明快かつ簡潔なコードがコードの再利用を促す生命線。
C++で書かれているものの多くが軽傷とオーバーロードの濫用のしすぎでコード自体が本当は何をやっているかわからない。美しくない。
コンピュータの有限な処理速度を考慮しているモノが美しい。
流れの中にある美しさ、タスクがサブルーチンへと論理的に再分割されており、本を読むように読めるのが美しい。

短くて、明確で、質素で、現実を考えて書かれているモノが美しい。
CERNライブラリはその一つ。


16章 Linuxカーネルのドライバモデル:一緒に働くことの恩恵 グレッグ・クローハートマン
LinuxカーネルでUSBで接続された2つのプリンタをどちらに先に電源をいれても、Linuxカーネルがどちらを先にみつけても同じ名前をもつようにしたいという問題を解決する。
Linuxカーネル内部でドライバとデバイスを統合するモデルで解決する

カーネル中のすべてのデバイスのための「基底」クラスの構造体
型チェックをしないことで種別チェックに寄り掛かることなく論理でコーディングすることを強制していくれる

C言語で書かれているマルチスレッドのプログラム構造が持つ主な問題点は構造体が占めているメモリを安全に開放できる時点を見極めるが難しい。
構造体の参照カウントを行う構造体のフィールドを一つにして構造体を安全に開放できる時点を決めている。

小さいので数千個のデバイスへの規模拡大ができた。
LinuxのドライバモデルはC言語を使って多数の小さなオブジェクトを生成する行動にオブジェクト指向的なモデルが実現できる。
Linuxカーネルの開発方式がもつ、興味深く強力な二つの側面
第1 開発プロセスは極めて反射的。システムが変化する環境で生き延びていくために進化の必要性がある。モデルの様々な面を抽象化して変化にそなえる。
第2 デバイス管理コードの歴史をみると、開発プロセスが極めて協調的なことがわかる。開発がそれぞれ独立したアイデアを実現しようと、ソースコードをよんで改良をくわえていった。それが1人ではたどりつけない共通解をもたらした。


17章 もう一段の関節参照 ディオミディス・スピネリス
バトラー・ランプソンの言葉「コンピュータ・サイエンスにおける問題のすべては、もう一段の関節参照によって解決できる」
複数のまったく異なるファイルシステム形式をサポートする典型的なオペレーティングシステムの問題を考える。

Switchを使って実装する方法
FreeBSDのreadシステムコールにおける関節参照のレイヤー構造一覧
関数の引数を引数ポインタにする
システムコール内のバイパス関数を経由した呼び出し図

先の言葉には続きがあって「しかし、そうすることで、たいてい、新たな問題が作り出されるのだ」
間接性や階層構造は空間的、時間的オーバヘッドとコードの理解しにくさをもたらす。
時間的、空間的オーバーヘッドはあまり重要でない、しかしり理解しやすさが損なわれるのは重要な問題。
なにか漠然として、明記されていない要求で将来表れるのでは想像しているもののために階層を増やすことには慎重になるべき。
パート・スマールダーはアンチパターンの議論で「層はケーキにあるべきもの、ソフトウェアじゃない」といっている


18章 Pythonの辞書実装:すべての人々にすべてのものであること アンドリュー・クッヒリン
プログラミング言語Pythonにおいて、辞書は基本的データ型。awkの連想配列やPerlのハッシュのように、辞書には一意的なキーから値への対応表が格納されている。
辞書にたいする基本操作
・新しいキーと値の対を追加する
・あるキーに対応する値を取り出す
・既存の対を削除する
・キー、値、またはキーと値の対を列挙する
Pythonインタプリタのプロンプトに向かって辞書を扱っている例をあげる

辞書の内部の構造の解説
特別扱いのコードをまぜることで効率をあげるアイデア、ただし、やりすぎ注意
ハッシュが小さい場合の特別な最適化・・・8スロットのハッシュ表
特別なキャッシュが負荷に見合うとき・・・文字列しかうけつけないケースのデータ型
Java版の実装:もう1つの特別扱いによる最適化
C版の実装:記憶関数をダイナミックに選ぶ

ハッシュ表の実装で重要な判断事項になるのは
2つのキーが同じスロットにわりあてられたときどうするか
連鎖法と開アドレス法の解説

辞書のハッシュ法の大きさはキーが付け加えられていくうちに、調整が必要になる。
辞書の管理コードは表の3分の2がうまっていることを目標にする。
辞書の大きさは4倍を目安にする
メモリのトレードオフが見合うとき・・フリーリスト。未使用のデータ構造をリサイクルして、malloc()とfree()の呼び出し回数を減らす
繰り返しとダイナミックな変更をおこなっているとき、項目の追加と削除を禁止

Pythonの辞書は多くの機能やオプションを提供し、処理系内部で広範囲に使われている。Cpyrhonにおける辞書の実装は全般にとても素直。
ソースファイルを読んでみて、コメントとコードを読むのをすすめていた。


19章 NumPyの多次元イテレータ トラビス・E・オリファント
NumPyはPython言語のオプションパッケージで、強力なN次元配列オブジェクトを提供する。
 一次元配列は音の波形のサンプリングデータ、2次元配列は白黒画像、3次元配列は(3つの次元のうちの1つに3または4の長さをもたせる)カラー画像を、4次元配列にはコンサートの時間ちゅの部屋の各店の圧力値を格納することができる。
配列の任意の部分をスライシングという概念で選択で来たり、見境なくコピーして計算資源を食い尽くさないという特徴がある。

これを実現しているループ、メモリモデル解説。
イテレータがどのような由来をもち、設計され、進み方、終了の仕方を解説。
イテレータがつくられるとき、カウントをたどる方法、イテレータの構造、インターフェースを解説。

イテレータの利用として
次元を一つだけ除外して他の全要素を繰り返すを解説。

イテレータはNumPyのコードベースのいたるところで、N次元ループの構築を簡単にするために使われている。
イテレータを効果的に活用することでデータ配列から配列へコピーするコードがNumPyのブロードキャストの定義と矛盾しないよう手直ししたときの例をあげていた。

NumPyのイテレータオブジェクトはプログラミングを簡単かするコーディングの抽象化の一例。


20章 NASAの火星探査機計画のための高信頼エンタープライズシステム ロナルド・マック
NASAの可視探査機計画に作られた協調的情報ポータルシステムCIPについて、
エレガントのアルゴリズムや小さなプログラムとは違う巨大なソフトウェアにおける美を解説。
火星探査機の目標
 火星の表面に液体の水が流れたことがあるかどうか調べる。
 2003年と2004年に打ち上げられた地質学者ロボット。星の表面を自力走行でき、関節のある腕の先端に搭載されたスペクトラム測定機などの科学機器、ドリルと顕微鏡画像装置で表面の岩の下を調べる。これを無人でおこないデータと画像を地中に送信する。

ミッションのニーズ
 時刻管理
 関係者の管理
 データの管理

システムアーキティクチャ
CIPの3層サービス指向アーキティクチャ図、クライアント、ミドルウェア、データ
重要な設計原理
 標準に基づくこと
 ゆるい水美月
 言語独立
 モジュラリティ
 スケーラビリティ
 信頼性

事例としてミドルウェアの一つであるストリーマサービスをみる。
JPLに設置されているミッション用ファイルサーバーからユーザーが自分の個人用ワークステーションやラップトップマシンにデータや画像ファイルをダウンロードするための検索用メタデータが生成されている。ストリーマサービスはファイルのダウンロードとアップロードのサービスを行うミドルウェア。
サービスアーキティクチャの図解 遠隔クライアントアプリケーション→アプリケーションサーバー→ミッション用ファイルサーバー2階層のサービスでファイルのダウンロードを行う様子を図解、クライアントアプリケーション→ストリーマサービスプロバイダ→ファイルリーダ
同様にアップロードも図解

CIPプロジェクトにおけるシステムの本質的信頼性を確かめるための速度基準
・業界標準とベストプラクティスに従う。J2EEなど
・適用可能な個所についてはCOTSソフトウェアを採用する。
・モジュール化されたサービス構成のサービス指向アーキティクチャ(SOA)を採用する
・ミドルウェアサービスの実装を簡単かつ直線的なものとする。
さらに著者たちは信頼性を高めるために「ログをとる」「モニタする」を行った。
コードとモニタリング画面がのっていた。

頑強さのために
・ミドルウェアサービス中ではパラメタを直接ハードコーディングすることを避ける
・すでに運用に入っているミドルウェアサービスへの変更が、クライアントアプリケーションに及ぼす影響を最小限にとどめる

動的な再調整
パラメタ値をハードコートしない。これは巨大なアプリケーションでは特に重要

ホットスワップ
 すでに実行している状態のミドルウェアサービスを落とすことなくミドルウェアサービスを新しいものに置き換えさせてくれる。
巨大エンタープライズでは特に意味がある。

巨大アプリケーションのための美しさは必ずしもエレガントアルゴリズムはない。CIPではサービス指向アーキティクチャの実装と多数のシンプルな、しかしよく選び抜かれた要素群の中に美しさがあった。熟練したソフトウェア製作者の選択の勘所が美の極み。


21章 ERP5:高水準の適応性に向けた設計 ロジェリオ・アテム・デ・カルバルホ  ラファエル・モネラ
ERP5は、ERPシステムのオープンソース。システムのコアを構成する5大要素にちなんでなずけられた。
ERP5はドキュメント中心のアプローチを選択したことで、開発者でもユーザでも容易に機能向上できる。

著者たちが作ったプロジェクト管理モジュールERP5Projectを創り出すためにどのようにラピッド開発手法を用いたか解説。

ERPは組織のすべてのデータとプロセスを1つのシステムとして統合することを目的とするソフトウェア。

ERP5で使用されるZopeの要素の主なもの
・ZODB・・オブジェクトデータベース
・DCWorkflow・・・ワークフローエンジン
・コンテンツ管理フレームワークCMF・・コンテンツを追加したり削除したりする基盤
・ZopeページテンプレートZPT・・XMLベースの簡易GUIスクリプト

ERP5でビジネスプロセスを表現するための土台となる5つの抽象概念
・資源・・・個々のスキル、商品、機械など
・ノード・・・資源を受け取ったり送り出したりするビジネスエンティティ
・パス・・・あるノードが他のノードから必要な資源にアクセスする方法の記述
・移動・・・ある時点、一定期間のノード間の資源移動の記述。
・品目・・資源の一意的なインスタンス。例CDドライブはPCをくみたてる資源だが、商品番号のついた品目でもある。

Zopeプラットフォーム基盤解説
動作タブ画面とシステムクラスの解説

ERP5 Projectのコーディング
タスクのワークフロー図・・・発注とか計画済みとか
タスク報告のワークフロー図

ERP5は高度な柔軟性をもつツールを実装できた。
再利用は日常的であり、新しいモジュールをつくるときも、GUI要素を取り換え、ワークフローを調整するだけで済む。
オブジェクトデータベースの問い合わせは抽象レベル=特定のビジネス分野の概念が取り出されるないし、ポータル型のメタクラス=UBMの汎用概念に関係する全オブジェクトが取り出されるで処理される。


22章 スプーン一杯の汚水で ブライアン・キャントリル
たる一杯のワインにスプーン一杯の汚水を注ぐと、たる一杯の汚水になる  ショーペンハウエルのエントロピーの法則

ソフトウェアの正しさは2進法。正しいかそうでないか、そこは数学に似ている。
普通の工学のように負荷率や最高速度、環境条件などはない。
そうであるから、一つの欠陥がソフトウェアに情けない失敗をもたらす。

著者が1999年にSolarisカーネルの重要なサブシステム開発中に遭遇した、深い設計上の欠陥がどのようにしてバグとしてあらわれてくるか。そして複雑で重要なソフトウェアを完璧に動作させようとするとその詳細がいかに悪魔的であるかを解説する。

ターンスタイル・・・Solarisオペレーティングシステムにおいてスレッドをブロックしたり起こしたりするのに使われるメカニズム。mutex(排他ロック)やリーダライタロックのような同期の基本操作の土台部。

ターンスタイルの概要をコード10行のほど、コメントは15行ほどで解説
そして問題になった実装コード2行とコメント3行を紹介。

ターンスタイルが古典的問題優先度逆転についてどのように処理するか解説。
解決方法1 優先度継承 Solarisで採用されていた。

ブロッキングチェーン・・・待ち状態のスレッドの連鎖
例としてカーネルのメモリアロケータとゼタバイトファイルシステムの間のやりとりをあげていた、
ある優先度のスレッドが待ち状態に入ったときには、対応するブロッキングチェーンに連なるスレッドすべてが整合性を保った状態で優先度を上昇させるひつようがある、
Solarisではスレッドのディスパッチ状態はスレッドロックとよぼれる特殊なスピンロックで守られている。
整合性を保つためにはすべてのスレッドロックを獲得すればいいが、スピンロックへのポインタで実装されているのでうまくいかない。
ブロックキングチェーンが巻き戻されるのは待ち状態にない側からに限られるので、同時に2つの連続した要素のロックを保持しておきさえすればよい。
しかし、ターンスタイルテーブル(同期プリミティブの仮想メモリアドレスをキーに持つハッシュ表)中のロックとブロッキングチェーンをたどり二つのロックを保持するという状況があわさるとロックの順番という問題が発生する。
これにも対処したはずだったが、OSの欠陥は発見される。
著者と同僚はコアダンプをつかい(検死デバッグ)から原因をつきとめ、それが設計上の問題であることに気が付いたという。
著者のバグレポートがのっていた(スレッドA,Bについて優先権のかくとくを細かくおったもの)
ユーザレベルのロックを獲得解放するときにもカーネル内のロックを獲得記録解放することが必要。
ブロッキングチェーンがループになっているように見える場合があり、カーネルはそこで緊急停止してしまう。
これをもとにバグを発生させるテストケースを書く。・・・満塁ホームランの気分
さらに偽デットロックが発生する場合があると気が付く。
いくら議論してもそれを避ける方法が見つからないので、問題の状態がおきる2つの場合、パニックと偽デットロックがおきたとき対応する方法を考えた。
そして修正して負荷テストをおこなったところ、OSがただハングするというさらに暗黒な問題が発生
ユーザレベルの優先度継承を行う獲得と解放の時、カーネル内のロックの獲得・解放が必要。しかしカーネルレベルロックとユーザレベルロックのハッシュ関数がたまたま同じで同じターンスタイルテーブルにエントリしているとデットロックになる。
さんざん悩んだ末に、ターンスタイルテーブルをユーザレベルの優先度継承の状態をガードするためのロックのハッシュ表とそれ以外に分ける。抽象かよりも、特定で問題を解く。
これで問題は修正されたが、もっとも低級な解き方であることは認めるといっていた。

良いソフトウェアエンジニアリングの原理
・早く実装する。
・集中的に攻める
・境界条件に注意する
これらが行われればプロジェクトの初期段階で最も難しい問題を実装することに注力することになり、全体構造がうまく働く検証になる。設計上の変更がまだ間に合う時期にとらえられて、ワインが汚水に代わることはなくなるだろう。


23章 MapReduceでの分散プログラミング ジェフ・ディーン サンジェイ・ゲマワト

MapReduceは大規模なデータ処理問題を解くプログラミングシステム。Googleで開発された。日用的マシンのクラスタ上
で並列実行される。実行時システムが入力データを分割する手順の詳細を担い、一群のマシン上でのプログラム実行をスケジュールし、マシンの障害に対処し、またヒチョウとなるマシン間の通信を管理する。

単語検索の例題
200億個の文書があって、それらの中にある1つの単語がなんかいでてくるか数えたいものとする。
文書の平均サイズ20kbとすると1台のマシンで合計のデータ量400テラバイトを読み通すのには、だいたい4か月かかる。
コードの例 素朴で並列化してないバージョン。
次は並列化バージョン
記憶域を分割した並列化バージョン
プロセッサ分割を用いた並列版

これらをみると、単語を数えるという単純な作業が並列化を管理するための多数の詳細な点にうもれてしまったことがわかる。
並列化のパターン(下の二つ)をつきとめ、問題を解く手順の詳細と分割するのをめざす。
・各々の入力レコードについてそこから関心を持つキーと値の対を抽出する。
・抽出されたキーと値の対それぞれを、同じキーを持つ他の対と結合する。

単語計数プログラムMapとReduceに分割する例
そのためのドライバのコード

MapReduceを使った別の例
・分散Grep
・ウェブリンクの逆フラグ
・ホストごとの単語やベクトル
・逆引き検索
・分散ソート

分散MapReduceの実装
さまざまな計算プラットフォームに対して、それに合ったMapReduceプログラミングモデルの実装が可能。
ただしい選択は環境に依存する。

Googleの計算環境は、多数の日用的なPCがスイッチを用いたイーサネットで互いに接続され、大規模なクラスタを構成しているもの。
ここでの実行の概要を解説。

実践的に役立つことがわかった基本モデルの2・3の拡張機能について説明
・分散関数
・順序の保証
・悪いレコードを飛ばす

2007年初頭、Googleでは6000個以上のMapReduceプログラミングモデルが付くアラレいて、一日に35000個のMapReduceジョブが実行されている。
ウェブサーチのサービス用に索引付のシステムを書きなおそうと開発されたが、機械学習、統計的機械翻訳、ログ解析、情報検索の実験、汎用の大規模データ処理や計算処理などに役立つことがわかってきている。

付録 単語計数問題の解法


24章 美しきかな、並列 サイモン・ベイトン・ジョーンズ

次世代プロセッサを購入すればプログラムが速くなる時代は終わった。
次世代チップは多くのCPUをもつが、個々のCPUは前年のモデルより速くない。
自分のプログラムを速くしたければ並列プログラムの描き方を学ばなければならない。

並列プログラムは非決定的に実行されるため、テストは困難で、バグはほとんど再現できない。

美しいプログラムは単に明らかな間違いがないだけでなく、明らかに間違いがないと一目でわかるような単純でエレガントなプログラム。

並列プログラムは逐次プログラムに比べて美しくなく、モジュラリティが低いことがしばしばある

STM・・・ソフトウェアトランザクションメモリは共有メモリ型並列プロセッサをプログラミングする有望なアプローチ。著者にとっては現在の技術がサポートしていない形でのモジュラープログラミングをサポートしていると感じるそうだ。

例題 銀行口座問題
ある銀行口座から別の銀行口座にお金を転送する手続きを書く。
どちらの口座もメモリ内に格納されていて、データベースとの交信は不要とする。
多数のスレッドが同時に転送手続きを呼ぶ可能性のある並列プログラムでも正しく稼働する。

同期メソッドでロックと条件変数を使う例

ロックの問題点
 獲得したロックが少なすぎる
 獲得したロックが多すぎる
 間違ったロックを獲得する
 間違った順序でロックを獲得する
 エラーの回復
 スレッドを起こしそこなったり間違って起きた時の処理を忘れる。

言語HaskellとSTMを使って上の問題を解決する過程を解説。
言語とSTMの解説もおこなっていた。

STMの解説にサンタクロース問題をあげていた。
Haskellではアクションが値であることが特徴といっていた。

STMを使うことでロックによる平行プログラムを苦しめる標準的な問題の多くを回避できる。
特にHaskellと組み合わせることでエレガントになる。
STMを使うのはアセンブリの代わりに高水準言語を使うのに似ている。


25章 構文の抽象化:syntax-case マクロ ケントディヴィグ

コンピュータのプログラムを書くとき何度も同じパターンが出てくるときがある
こういう時に「構文の抽象化」を行う仕組みが用意されうことがあり、C言語のプリプロセッサマクロやLispのマクロなどである。
どちらもマクロ呼び出しフォーム内部に出てくる識別子のスコープは入力側できはなく出力側になるので、変数参照の意図しない補足がおきる可能性がある。

syntax-caseは元のアルゴリズムへの欠陥を克服するために開発された。
ローカルなマクロ束縛をサポートし、定数オーバーヘッドで済み、しかもマクロがScheme言語の表現力をフルに使えるようにする。
そのかわり展開アルゴリズムは複雑になり、コードも大きくなるので、この章ではアルゴリズムの基礎と実装の最重点の説明のみ解説。

syntax-case使用例
展開アルゴリズム
構文オブジェクトとして表現
展開出力の生成
構文オブジェクトのそぎ落とし
構文エラー
構造に関する述語
wrapの生成
環境の操作
識別子の判別
エクスパンダ
コアの変換
構文オブジェクトの解析と構築
識別子の比較
変換
展開の開始

例題をあげて追跡

簡単化したマクロエクスパンダはsyntax-caseの完全版の実装が用いている基本アルゴリズムを説明するもの
複雑なパターンマッチ機構、内部定義の処理、コアフォームの追加は省いた、
環境の表現方法も1変数版のものを使った
syntax-caseマクロエクスパンダは健全なマクロ展開アルゴリズムKFFDに局所的な束縛構文、制御された補足機構などのサポートを追加し、計算量が2時である点を改良している。
KFFDの展開プログラムの方が美しいコードになるが、設計通りなことをするsyntax-caseのエクスパンダのなかにも複雑なソフトウェアの美しさがあるはずだ。


26章 労力節約のアーキティクチャ:ネットワークソフトウェアのためのオブジェクト指向フレームワーク 
ウィリアム・R・オッテ ダグラス・C・シュミット 

ネットワークアプリケーションのソフトウェア開発が大変なのは、分散システムに固有な複雑さの他に、非本質的な複雑さがある。それはCレベルのOSAPIをつかっていること、これは機能分解による開発を奨励する設計になっており、機能分解では保守や改訂は複雑になる。幸いC++、Java,C# などのオブジェクト指向言語、方位ふぁさーだ、アダプタなどのデザインパターン、ACE、javaネットワーククラス群などのフレームワークが低レベルのOSAPIをカプセル化してくれるようになった。

しかし、そのようなフレームワークをいかにして作るかはブラックアートのままだ。
ネットワークソフトウェア向けのオブジェクト指向フレームワークの事例研究について述べる。

簡単なアプリケーション:ログ記録サービス
アーキテクチャの図
・開発者がログレコードを送ったり受け取ったりするのに使えるような、プロセス間通信のための各種機構(ソケット、SSL,共有メモリ、TLI、名前付きパイプ)
・開発者がログレコードを処理するのに使えるような、各種の並列処理モデル(反復型、反応型、接続ごとのプロセス、各種のスレッドプール)
・開発者が複数スレッドの共有資源(回数を数えるカウンタ等)へのアクセスを順次かするのに使えるような、各種のロック方式(スレッドレベル/プロセスレベルの再帰mutex、非再帰mutex、リーダライタロック、null mutexなど)
・クライアントからサーバへ伝達されるログレコード形式、サーバが受け取ったらそのろぐレコードはさまざまな形で処理される。例、コンソールに出力される、1つのファイルに保存される、あるいはディスクへの並列書き込みを最大化するためにクライアントごとに1つのファイルに保存される。

これらのどれを選択しても実装は比較的素直に行える。
しかし、顧客の要求や動作環境がちがうとすべてのログ記録のニーズをみたすことはできない。
チャレンジすべきは柔軟に構成可能なログ記録サーバを設計すること。
そのチャレンジの核心はデザインパターンと関連する設計技法を理解したうえで、
・基底クラスやジェネリッククラスを用いて共通の構造と動作を補足
・サブクラス化やジェネリッククラスのパラメタ化による選択的なカスタマイズの実施

上記を踏まえたオブジェクト指向ログ記録サーバ用フレームワークの設計の図
設計の核になっているLogging_Serverクラスでは
・C++のパラメタ付きの型を使う。開発者はジェネリッククラスで使われているデータ型や機能の選択をインスタンス生成時点まで延ばすことができる。
・テンプレートメソッドパターンを使う。個々のステップはサブクラスによりオーバライドされる可能性のあるメソッドにまかせながら、アルゴリズムの骨組みを定義する。
・包囲ファサードパターンを使う。オブジェクト指向でないAPIとデータを、型安全なオブジェクト指向クラスの内部にカプセル化する。

ログ記録サーバ用フレームワークのオブジェクト指向設計
重要な概念
・ドメインに特化したオブジェクト構造と機能を具現した半完成品のアプリケーションを定義
・フレームワークは能動的であり、実行時に制御の反転を伴う
・スコープ・・・ドメイン(フレームワークが記述する問題範囲)とフレームワークのコンテキスト定義
・共通性・・・フレームワークに基づくファミリー製品すべのものに繰り返し現れる属性の記述
・可変性・・・ファミリー製品の個々のものに固有な属性の記述

フレームワークによって実装される共通性とサブクラスやパラメタによって特化される必要のある部分(可変性)にわける、
ログ記録サーバのメインループ図
変化に対応するための、テンプレートメソッドパターンとそのログ記録サーバへの応用の図
IPCと同期メカニズムを並列性戦略に関連づける方法を考える。
 ・Strategyパターンを使ってアルゴリズムをオブジェクトとしてカプセル化し、実行時に入れ替え可能にする。利点と欠点・。 
 ・C++のパラメタ付きクラスを用いてIPCと同期のための特定の包囲ファサードを持ったログ記録サーバを実体化すること。
2番目の方法でコードがのっていた。

逐次的なログ記録サーバの実装
 すべての処理が1つだけのスレッド内で実行されるような、ログ記録サーバの実装。反復型と反応型の2つを説明
この方法では一つのクライアントの処理だけを行うのではなく、複数クライアントのサービスをインターりーぷするという点はよいが、OSの並列実行機能を利用し枝いないので、マルチプロセッサの能力を有効利用することはできない。新しいレコードを読み込むのと並行して炉グレードを処理することもできない。それでクライアント数が増大した場合のスケーラビリティがない。
 しかし、簡潔であるのでオブジェクトフレームワークに基づいた美点を浮き彫りにしてはいる

並列ログ記録サーバ実装
OSが提供するAPIを使ってスレッドやプロセスを作るのは、それらの理由が本質的な理由でないのに複雑で気が遠くなる作業である。その複雑さを克服する解決策としてプラットフォームをまたがる一貫したインターフェースを提供する包囲ファサードを使用して、Logging_Serverのオブジェクトフレームワークに統合する。

接続ごとスレッドによるログ記録サーバ
 クライアントからの接続を受け付けるmainスレッドを実行、接続が来たら新しいワーカスレッドを生成し、ワーカスレッドがその接続からのログレコードを処理する。
 プロセスの手順と実装の検討を解説。

接続ごとプロセスによるログ記録サーバ
 上と同様だが、スレッドではなく新しいプロセスを作って各クライアントからやってくるログレコードを処理すること。
 並列性のためにプロセスを使う場合、プラットフォーム間でのプロセス生成セマンティクスの差異に対応できるような設計上の選択が必要。例としてLinuxとWindowsのプロセスAPIの相違点とカプセル化がのっていた。

並列ログ記録サーバはマルチスレッド実行をサポートするハードウェアやOSを活用してクライアント数が増えてもスケーラビリティを発揮するという面で強力。プラットフォームを関知しない形で開発するために包囲ファサードを使った。

ログ記録サーバアプリケーションはオブジェクト指向設計/プログラミング技法、デザインパターン、フレームワークをネットワークアプリケーションのためのソフトウェア実装に適用する方法を示すための、消化しやすいけれど現実的例題。


27章 ビジネスパートナーをRESTfulにまとめ上げる アンドリュー・パッツァー
 著者が経営コンサルタントだったころ、だれもかれもが自分のビジネスソリューションのためにウェブサービスを必要としていると思っている時期があった。しかしそれは流行によるものであることも多い。
 ビジネスパートナーに一連のサービスを提供する現実のプロジェクトをみてみて、その過程でなされた設計上の選択について議論する。
 Jave(J2EE)、XML,e-ビジネスプロトコルRosettanet、AS/400で実行されるプログラムとの通信に使われる関数ライブラリのはなしがでてくる。

プロジェクトの背景
 大きな電子部品工場から「我々のシステムを販売店の1つと統合するためのウェブサービス一式を整えたい」という要求
 採用していたのはMAPICSというAS/400で実行するRPGで書かれた製造システム
 販売店は独自のビジネスシステムを採用していた。
 これまでは、販売店のオペレータは工場のAS/400システムに遠隔接続してからホットキーを押して必要な画面にアクセスしていた。
 将来加わる販売店のことも考えて、どんなプロトコルや要求がきても対応できるようにする
 ソフトウェアの保守と拡張をするスタッフのスキルは低いので、シンプルで容易に拡張できる必要があった。

 最初はSOAPを考えたが、その後HTTP経由のGETとPOSTリクエストで表されるサービスを使ってリクエストやレスポンスをXMLで行う方法が適していると判断した(これはのちにRESTと呼ばれる)
 判断ポイント
  ・何種類の異なるシステムがサービスにアクセスするのか、またそれらのすべてが現時点でわかっていない
  ・提供するサービスはごく限られた高度な知識をもつユーザが使うのか、それとも自動的に接続してくる不特定のユーザにサービスの説明を見ながら使ってもらうひつようがあるようなものか
  ・1つのトランザクションを通じて維持される状態は何種類か?前の結果に依存するリクエストをすることはあるのか?

サービスインターフェースを決めるにあたり、最初はユーザがどんなふうにリクエストをだし、レスポンスを受け取るかきめる、
HTTP POST リクエストをXML文書でだし、HTTPレスポンスのXML文書を受け取る。

ファクトリパターンを使ってサービスを振り分ける
 実装を一つのコマンドインターフェースまで最小化し、そのインターフェースに多様なリクエストにこたえるのに必要な基本メソッドを提供させることで、その要求仕様を満たす。受け取ったリスエストデータのリクエスト種別を教えてくれる特別な文字を探して振り分ける。

e-ビジネスプロトコルでデータを交換する
 著者にとって新しかったのは標準的e-ビジネスプロトコルを使うこと。
 まず特定の文書のダウンロードを行い、ダイアグラムとXMLのリクエストとレスポンスの仕様をみつけた。
 試行錯誤が必要そうだったので、最初に自分で実行できる販売店とのやりとりのシュミレーションテストを設定
 これでさまざまなタイプのリクエストを試してその結果をみることができたので、理解が加速度的に増えた。
 著者はできるだけ速くコーディングに飛び込む主義の信奉者であるといっていた。

XPathでXMLを構文解析する
 XMLリクエストデータは単純なXMLとは言い難いので、XPathで解析。マッピングはHashMapを使った。

XMLでレスポンスを組み立てる
 XMLは単なる大きなテキスト文字列なので、DOMや特別なXML生成ライブラリを使うよりもStringBufferで書きだすだけの方が普通は簡単。
 コードがのっていた。

著者が2年前に書いたコードなので、実装は変えたいところもあるが、デザインはよかったといっていた。だから時間の経過に耐えられるだろうと。
現在生態情報学部の学部長をしているが、オブジェクト指向設計お設計原理やXMLの構文解析技術を教えるときスタッフにデモとして使用しているコードなのだそうだ。


28章 美しいデバッグ アンドレアス・ツェラー
 デバックは魅惑的なものなどなにもない。
 エラーを避ける為にすべてのことをやったとして、それでもなおデバッグが必要なときがある。
 著者がであった美しいデバック(デバッグの生産性を本当に押し上げてしまうような新手法)について述べる。
 それは問題を解決する方法にあなたを導いてくれることを保証するだけでなく、ある程度まで「自動的」であなたが別の仕事をしていられるくらいである。

デバッガをデバッグする
 GNUデバッガgdbを内包して実現されたデバッガdddのバグ報告がくる
 原因はdgbの変更にあるので、diffをかけたところ178200行、8721か所の結果を返された。
 これを一つ一つつぶす前に美しい方法を考える

系統だった方法
 原因をみつけだすための一般的科学的手法
 1 プログラムの失敗を観察する
 2 観察と矛盾しない失敗の原因について仮説をたてる
 3 仮説を使って予測する
 4 予測を実験でテストして、さらに観察する
     実験と観察が予測を満たすなら、仮説をさらに精密なものにする
     満たさないなら別の仮説をたてる
 5 仮説がこれ以上精緻にできなくなるまで3,4を繰り返す

これをバグ報告にあてはめて、問題は解決した。
系統だったデバッグ手法の訓練をする方がデバッグツールを習うよりも大切。

探索問題
 変更による不具合とわかっているなら、過去から未来に向かって変更を加えながらデバッグすればよいが履歴がわからないのでできなかった。
 そこで変更をいろんな順番で試してみる方法をおもいついたが、計算すると量子コンピュータが発明されそうなくらいかかりそうだったのでやめた。
 ソースコードに加えられた前半の変更を加えてテスト、分割統治法をおもいつく

失敗の原因を自動的に見つける
 アイデア
  ・変更の半分を適用することで矛盾しないビルドを得られる可能性は小さい。でも得られたら変更点の集合が素早く狭まる
  ・変更点を1つづつ加えていけば意味のあるものを得られる可能性は高くなる。

折衷案で、半分から開始してどちらもビルドできない場合は4分割する、だめなら8、16、32に分割。
これをPythonで書いてみる。すると3日待ったあげくスペルミスでつまづいた。
今度は問題点を修正して5日間動かして原因箇所をつきとめた。
原因は埋め込みテキストの1行だった。

このアルゴリズムとツールを磨き上げ、差分デバッグとして公開。
 アルゴリズム
  ・リストc_passには「うまくいった」構成が入る。例題の場合プログラムを動かすためにくわえなければいけない変更点のリスト。空リスト
  ・c_failには「失敗する」設定が入る。例題の場合、プログラムを失敗させる変更点のリストで今回の例では8721個の変更点のリスト。
  ・関数testは変更点のリストを受け取り、それらの変更を適用してからテストを実行する
  ・関数ddは系統的にc_passとc_failの差を狭めていく。
実装のコードの例があった。

入力の最小化
 プログラムの入力に失敗の原因を探すのに差分デバッグを使う例

欠陥を狩り込む
 差分デバッグを使ってプログラム全体のコードを最小化し、重要なものだけを残すこともできるはず。
 例としてNTMLページを印刷している間にブラウザがクラッシュしたとしたら、そのプログラムコードに差分デバッグを適用すれば、クラッシュを再現する最小限のコードだけが残る。
 しかし、実際にはうまくいかない。なぜならプログラムコードの要素どうしは互いが密接に依存しているから。
 ソースコードの失敗の原因を刈込たい、それも自動で、このようなことを達成する差分デバッグを考える。
 問題
  ・プログラムの状態をどうやって取得するか
  ・2つのプログラムの状態を比較する方法
  ・状態と状態の間の差分を適用するにはどうする?
 うまくできれば億万長者になれるかも。

研究室では問題を絞り込んで上の問題を解決できたが、商品になるレベルではなく、脆い。
しかし、入力に対する差分デバッグを実装したコマンド行ツールが利用できる。Eclipseのプラグインddchangeがその一つ。

デバッグをするときは可能な限り苦痛のないデバッグ体験にするべき。
科学的手法で系統的に行う、そしてそれを自動化できればもっとよい。自分のコード開発プロセスに労力を投入しよう


29章 エッセイのごときプログラム まつもとゆきひろ
 プログラムはエッセイあるいは小説に似ている。エッセイであれば「何が書いてあるか」プログラムであれば「何をするか」、その他に「どのように書いてあるか」も重要。どんなに良いことが書いてあっても読めない、読みにくければそれは読み手に伝わらないから
 どんな優秀なプログラムでもプログラムを一気に完成させることはほとんどない。プログラムが段階的に成長するのは小説の推敲ににている。また、ほとんどのプログラムはデバッグや仕様変更や機能拡張があるから、読むことがあるものだ。
 読みやすいプログラム=美しいプログラム。
 プログラムの美の基準は効率。
 どんなプログラミング言語でも「ひどいプログラム」を書く人はいるが、美しいプログラムを支援するプログラミング言語はある。

簡潔さ
 プログラムの美しさを構成する要素の一つ。
 簡潔なプログラムを開発するための近道は簡潔なプログラム言語を選択すること。Rubyなどをはじめとする最近の「軽量言語」が支援してくれる。
 型宣言が不要で、本当に必要なとき以外クラス宣言やmainルーチン定義を要求しない、トップレベルで命令を実行できるというプログラムをjavaとRubyの階乗を求めるプログラムで示す。

保守的
 人間は手になじんたツールを取り換えたり、新しい言語を学ぶなどよっぽどでないとやらない。
 Rubyは純粋オブジェクト指向といわれながら、Smalltalkのような革新的な制御構造は採用せず、伝統的な手続き型言語の制御構造を踏襲している。革新的すぎない美がある。

シンプルさ
 そもそも人間が自分の手で解決するのではなく、プログラムを書くのは、その仕事が本質的に面倒で複雑だから。
 複雑さをできるだけコンピュータに押し付けるのに重要なのは人間が書くコードのシンプルさ。
 ややこしいのは人間がプログラムを書くときに使うツールも人間が書いたプログラムだということ。
 自分の作品をシンプルに保つために他の人の作品に複雑さをおしつけるのは本末転倒。
 Rubyはシンプルな言語ではないが、それを使って記述されたプログラムがシンプルになるように努力している。
 「軽量言語」といわれる言語は仕様や文法、ライブラリの量などは軽量でない。

柔軟性
 コンピュータの都合よりも人間の都合を優先させること
 状況の変化に対応が難しい硬直的なプログラムの例として引数としてうけとったファイル(IOオブジェクト)にログを出力するloggerというメソッドの例をあげていた。これの仕様が変更され文字列として読み出したいときRubyならどうなるか解説していた。

バランス
 「簡潔さ」「保守的」「シンプルさ」「柔軟性」どれかだけが突出していても美は実現されない。これらが調和してはじめてプログラムの美が実現され、書いて楽しく、読んで楽しい、幸せなプログラミングライフが実現できる。


30章 世界につながる手段がボタンだけだったら アラン・メータ
「スティーブン・ホーキング教授ができるのはボタンを押すことだけだ」が仕様。
現在教授が使っているEqualizerというシステムはソフトをボタン一つで操作する。しかしソースコードは失われテキストを音声にするための箱は製造されていない。
 そのため教授は重度の障害者のためのソフトを発注した。著者の会社がこの試みに挑んだ様子。

基本設計モデル
 言語はVB6を採用。組み込みの入力機能が豊富で、プロトタイピングが容易(おそらく多くの試行錯誤がいるとみて)なので。
 身体障害のある人の情報の受け取る量がすくない。選択肢のなかから望むものが表示されたときクリックする方法をとる。前方検索とユーザがみたいと思うものの予測をつけることで入力を効率化する。そのための画面がのっていた。
 入力予測のために、データベース、キャッシュ、特別なグループ化の知性が採用された。

入力インターフェース
 マウスの右ボタンを利用

ツリー
 すべての選択を2分木構造の形で順番に示すインターフェースしかありえない、このツリーをたどる方法、動的に再構築する方法をつくる。

マウスの長押し
 ボタンはクリックするだけでなく、長押しすることができる。これでナビゲーションの高速化をはかる、

他に単純な入力、単語補完と次に来る単語の予測、データベースの任意の文章をテンプレートとする方法、キャッシュの実装方法、共通の単語と好みの扱い、ツリーのパスの取り消し、入力バッファ、編集、スクロール、クリップボード、探索(スクロールの特殊ケース)、マクロ(一連のコマンドを実行する)、ユーザインターフェースの効率をクリック数で計る。ダウンロード先などがあった。

今後は重度の身体障害者でもMacやLinuxを使えるようになるといいといっていた。Emacsspeakなどの技術をつかったり、Emacsを拡張してボタン一つで操作できるようになるといいとも。
読み書きができないひとでも使えるコンピュータがあるといい。だれか一緒に挑戦しませんか


31章 Emacspeak:完全に音声のみのデスクトップ環境 T.V.ラマン
 目を使わなくても視覚を使うのと同じような作業場を実現できる音声デスクトップ開発(Emacspeak)の試み
 目標
  ・電子メッセージのあらゆる種類のサービスを使ってコミュニケーションできるようにする
  ・クライアントのローカル文書とウェブの文書を容易に使えるようにする
  ・目を使わなくても効率よくソフトウェア開発がdきる。
 目で見て読むために画面に書いた情報をよみあげるだけでなく、実際の情報からはじめて音声にしないと効率よく情報が伝わらない。
 音声デスクトップのために選ばれた環境に必須だったもの
  ・発話による音声出力と発話でない音声出力サービスがコア部分にあること
  ・音声出力化する価値のある既存のアプリケーションが豊富にあること。

音声出力の生成
 1994年10月、LinuxラップトップPCと研究室のワークステーションをターゲットに開発開始。DECTalkExpressを使用。
 クライアントサーバ方式で作ったので、Emacspeakをリモートマシンで実行させるのも楽にできた。

音声版Emacsは1時間で完成。
EmacsLispのアドバイス機能を参考に音声版Emacsにアドバイス機能をつける。ユーザが上下の矢印キーを押すとEmacsにかーそるのある行を読み上げさせる。
 音声出力用サーバーが受け取った個々の音声出力コマンドをキューにためて実行する。
 アドバイス機能の概要 before after around

良質な音声出力の生成
 voice-lockによる音声データの整形
 音声出力リスト作成のためのEmacsの拡張
 音声出力リストから整形された音声出力

ACSS(音声スタイルシート)で発話のスタイルを指定する
音声アイコンの追加
コンテンツを読み上げながら音声アイコンを生成する。
カレンダー:文脈依存の意味情報を用いた音声出力の高機能化
オンライン情報へのスムーズなアクセス
基本的なHTMLをEmacsW3とACSSで扱う
タスク指向サーチのためのモジュール emacspeak-websearch
ウェブコマンドとURLテンプレート
フィードリーダの出現

Emacspeakは日常のコンピュータ作業を目を使わずにフルパワーで行えるインターフェースとして計画された。
システムはデスクトップワークステーションのあらゆる計算の側面に直接アクセスが可能でなければならない。
目を使わないで流暢なやりとりをするために、単に画面に表示されている情報を読むだけでなく、音声出力と音声メディアを扱う必要があった。
土台となるアプリケーションのソースコードを変更することなく拡張した、

12年にわたりEmacspeakを管理する。
最初の6週間の開発のあと、Emacspeak自身で開発と保守を行ってきた。
複雑なコードを長期間管理するのに有効だったこと、技術者が一人きり。コードは小さく、ファイルは細分化されていて独立に改良しやすい。

Emacspeakを実装、使用した経験からのまとめ
・Lispのアドバイス機能やそのオブジェクト指向版であるアスペクト指向プログラミングは視覚インターフェースを音声出力できるようにするなどの横断的側面の実装に有効な手段
・アドバイス機能は、複雑なソフトウェアシステムにおいて、拡張可能な点を発見するための強力な手段
・基本的なウェブアーキテクチャに注目し、標準のプロトコルとフォーマットに裏打ちされるデータ指向のウェブを利用することで音声でのウェブへのアクセスを強力なものにできた
・スライダーやツリーコントロールなどの個々の対話用部品に着目する代わりに、最終的なユーザの体験に着目することで、視覚に頼らない高度に効率的な環境が構築できた。
・耳から視覚ほどの情報を聞き取るのは時間の無駄。
・視覚的な複雑さは、視覚を使わないユーザにとっては致命的。RSSフィードやTOMフィードは画面をほりおこさずタイトルなどを取り出す、Emacspeakでは内容をフィルタにかけるために2000年にXSLTを使いだした。

開発者コミュニティに対する謝辞


32章 働くコード ローラ・ウィンガード クリストファー・セイワルド
コードがどのようにみえるか、とりわけ人がみてわかるコーディングの様々な特性がどのようにして、ある人が書いたコードを別の人が読み、それを通じて共同作業を可能とさせるか議論する。

セイワルドの「整ったコードの7か条」
・「本のよう」であること・・ 本のように段組みされ塊になっていると読みやすい
・似たものは似て見えるようにすること・・whileの条件が4つのうち3つまで実質的に同類であると示す例、1つだけ他と違うと示す例
・字下げを克服すること・・字下げは理解を助けない、入れ子は理解を妨げる、入れ子の字下げはわかりにくいという表明、なるべく使わない。
・コードをもつれさせないこと・・・コードをナビゲートすること。
・コードにコメントをつけること・・・コードをナビゲートすること。
・ごちゃごちゃにしないこと・・・コードをナビゲートすること。
・既存のスタイルに溶け込むこと
これはコーディング規約以上のものである。

7か条を意識して書いたコードは可読性が高い
DiffMergeの例

働くコードにかかわるプログラマにとって、美しいコードは、できるだけ混乱なしに変更できるコード。
だからコードを読むプログラマがどれだけ読みやすいかにかかっている。
diff marge バッチ、コンパイラのエラーメッセージ、デバッガなどを通してもプログラマはコードを読む。


33章 「本」のためにプログラムを書く ブライアン・ヘイズ
 この世のどの図書館の棚にもない伝説の「本」そこに刻まれているのは数学の定理のこの上ない出来栄えの証明の数々。ならばプログラムやアルゴリズムの「本」をあるはず。
 ただ動くだけでなく、「本」に乗せられるようなプログラムを書きたいと思うはず。
 著者が苦闘の末、これなら「本」にのせられるのではと考えたプログラムにいきつくまでを書く

取り組んだのは計算幾何学
 最初は簡単に思えるのに詳細にわけいると本当は難題だとわかる分野
 「平面上の3点が与えられたとき、その3点が同一直線状にあるか」という問題に回答するプログラム。

Lisp関数定義の例
髪と鉛筆で問題を解くとしたら?
3点の共線性解説
あぶない傾きについて解説(3点目がその直線上にあるか)
三角形の不等性解説
「紆余曲折」・・・書く線分の交差を片っ端から調べる必要があるコードは判定の枝が1ダースもあって、不必要に複雑に見えた。交差問題を調べたりしていた、妙案をみつける。他の人も苦労しているとしって、コードを公開して意見をもとめるといっぱいよせられた。

アハ!体験
シュウチュク氏の「幾何学的頑健さに関する講義ノート」で示された共線性のアルゴリズムがピタリとはまった。
三角形の周囲の長さでなく面積を使うとというアイデア。

正しい解法を探すベストな方法は、すぐに助けを求めること。
ただやはり自分で解いてほしいけど。
成果のでないプログラムをどのくらいやればいいかはよくわからない
また、ただ動くだけでなく、美しいコードを追求するのをどこまで追求すべきかもわかない。


久野靖×まつもとゆきひろ 対談 コンピュータサイエンスをなめるな!
fjの思い出話とか、ビューティフルコードの面白さとか。



ビューティフルコード (THEORY/IN/PRACTICE)

ビューティフルコード (THEORY/IN/PRACTICE)

  • 作者: Brian Kernighan
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2008/04/23
  • メディア: 大型本



タグ:Brian Kernighan
nice!(0)  コメント(0)  トラックバック(0) 
共通テーマ:

達人プログラマー―ソフトウェア開発に不可欠な基礎知識 バージョン管理/ユニットテスト/自動化 [プログラミング]

達人プログラマになるために習得しておくべきソフトウェア開発の技術として、
バージョン管理
ユニットテスト
自動化
を使いこなすことを推奨していいる本。
コードの書き方やロジックなどの本ではない。

もともと、この3つについて3部作で別々に出版したものを日本語版では1冊にまとめたもの。

第1部 バージョン管理
第1章 はじめに
メリット
・チームプロジェクト全体に及ぶUndo
・複数の開発者が管理された方法で同じコードを基に作業できる。
・時間とともに行われた変更を保持、変更を加えた人と時間、運が良ければ理由もわかる
・メインの開発を続けながら複数のリリースを同時にサポートすることができる。

CVSを例にどんなことができるか、具体的な導入方法、競合がおきたときなどを解説している。


第2章用語
最初に用語がいろんな使われ方をしているので定義するといっていた。

ワークスペース・・・プロジェクトの一部に取り組むために必要なリポジトリ内にあるすべてのファイルのローカルコピーする場所

チェックアウト ・・・リポジトリからファイルを取得すること

リポジトリ・・・プロジェクトファイルのすべてのバージョンに対してマスターコピーを置くための中心的な場所 。格納するもの=それが無ければアプリケーションの構築と提供が行えなくなるならすべて、でも生成可能なものはいれない 。プログラムのソースファイル 。Antツール(スクリプト)が作るスクリプトなど。 メタデータ ドキュメント、重要な電子メール、会議の議事録、Web情報 。

コミット・・・行った変更を再度リポジトリに保存すること

更新 ・・・誰かが行った変更を手に入れるため、リポジトリから最新のファイルを入手すること(最新の更新をチェックアウトしているので、更新のことをチェックアウトという人もいる)

バージョン・・・リポリトジは現在のコピーだけでなく、チェックインされたすべてのバージョンを格納している。そのメリットはファイルの特定のリビジョン(システムが付けるファイルの番号)を取り出す。システムのすべてのコードを2か月前に戻す。バージョン間での変更を表示する。

タグ・・・ある時点でのファイルの集合(または、モジュールやプロジェクト全体)に名前を割り当てる

ブランチ・・・本流の作業から離れて、特定のリリースを作成するときなどにブランチをつくり、そこでリリースチームが作業。メリットは本流の作業を止めずにリリースを作成できる

マージ・・・ブランチ内での修正を本流に反映させる。 メリットはブランチ内で発見したバグの修正を本流にコピーペーストする必要がないこと。

ロックオプション・・・二人が同時に同じファイルをチェックアウトして変更し、チェックインしようとした場合競合が起きる 。kのときの処理方法は二つ
厳格なロック・・・誰かが編集中のファイルは編集できない。メリットはファイルの整合性が保たれる。デメリットは特に見返りのない多くの面倒な作業が追加される
楽観的ロック・・・何人でも編集可能だが、チェックインしようとすると競合の警告がでるので、それを手動で解決する。 著者はこちらを推奨していた。実際にやってみれば競合はほとんどおきないとも。


第3章 バージョン管理システムCVSについて
インストール
 手順
   ・インストールされているか確認。コマンド「cvs -v」を入力、CVSのバージョンが表示されなければ、ダウンロードしてインストール
   ・リポジトリの作成。HDの置き場(階層の先頭のみ)「cvs -d ディレクトリ名 init」
   ・GUIフロントエンド、WinCvs TortoiseCVS(Visual Studioにプラグインできる)などを使う。IDEではEclipseがCVSをサポートしている。 注意 それでもCVSのコマンドを知ることは大切。

シンプルなプロジェクトを作成しCVSを使う
 ・ファイルをつくりインポートする例、引数importにメッセージをつけて格納
 ・ローカルマシンのどこにファイルの作業コピーを置くか決定し、チェックアウト 「cvs -d ディレクトリ名 co プロジェクト名]
 ・チェックアウトしたファイルに変更を加えて戻す。
   手順
    ・プロジェクトの状態を確認「cvs status ファイル名」
    ・リポジトリとローカルコピーの変更点を出す「cvs diff ファイル名]
    ・リポジトリの更新(ユニットテストも行ってOKならね!)「cvs commit -m "メッセージ"]
      一つのファイルが2人のユーザーに変更された場合
        ・変更されたコードに競合がなければ、リポジトリの変更に現在のファイルを合わせる。もちろんdeffで確認してから。「CVS update」でリポジトリに合わせて(もちろんローカルの変更はなくさない、マージされるのだ)から、自分のコードをチェックインする。
        ・変更されたコードが競合する場合「cvs update」はエラーを返すが、ローカルの変更は失われず、CVSが競合している部分を教えてくれる。は、「cvs log -rバージョン ファイル名」で誰がコードを変更したか調べ、確認する必要がある。cvsが勘違いを防いでくれたともいえる。ただし、こんな事態はめったに起きない。


第4章 バージョン管理に関する問題
バージョン管理の利点があるににも関わらず採用されないのは、理論と実践は違う、バージョン管理はとても面倒だとみなされるから。

基本的な哲学としてバージョン管理は軽量で、シンプルで明白でなければならない。変更したコードをチェックインするために複雑な手順や、作業の中断があってはならない。また実行していることやバージョンが明確にならなければならない。

CVSリポジトリにソースを整理するための基本的な規則
・開始する前にリポジトリにアクセスするための効率的かつ安全な方法を確立する。
・アクセス可能な状態になった後は、シンプルなCVSコマンド軍を常に使用します。
・個々の企業で開発する各プロジェクトは、異なるCVSモジュールとして利用できなければいけまない。プロジェクトの完全なソースを一か所からチェックアウトできるようにすべき。
・切り離して取り組むことができる下位のコンポーネントがプロジェクトに含まれる場合や、プロジェクト間でコンポーネントを共有しようとする場合は、これらのコンポーネントは名前を付けたモジュールに格納する必要がある。
・プロジェクトがサードパーティ(ベンダーやオープンソースのプロジェクト)のコードを組み込んでいる場合は、リソースとしてこのようなコードを管理する必要がある。
・開発者は、リリース、バグの修正、主なコードの実験の開始など、適切なタイミングにおける特異点を識別するのにタグを使用する。


第5章 リポジトリへのアクセス
通常ネットワーク経由でアクセスするセントラルリポジトリをもつのが普通。重要なのは間違った方法で初めても問題ないこと。接続方法にはリポジトリに影響しない。

接続技術にはpserverとexternalがある。
pserverは独自のネットワークポートを使用するので、企業のファイアウォールの多くはこのトラフィックの通貨を許可しない。パスワードの暗号化が脆弱でファイルの内容が平文で送られる。などの問題があり、匿名のリモートアクセスを行う場合以外は推奨しない。

externalでは既存のOSコマンドを使用してクライアントとサーバのデータパイプをつくる。外部のDVSのデフォルト設定ではrshを使うが、これは安全性が低いのでsshを使う方がいい。

CVSはリポジトリにアクセスして変更を行う人をユーザとして扱う。方法によらずユーザIDが必要。
そして一つのユーザIDでリポジトリにアクセスするという怠慢は避けるべき、だれが変更を加えたかわからなくなってしまうので。
環境変数CVSROOTにデフォルトのリポジトリの場所を設定して使う。
sshをインストールしてCVS_RSHにsshを指定する。Unixの場合は。Profileに設定を追加してsshでログインして使う。

pserverを使用してリポジトリにアクセスする場合、管理者はサーバにCVSパスワードを設定する。ユーザは[「cvs login」ではじめる。セキュリティが懸念する場合は使わないこと。


第6章 共通のCVSコマンド

毎日のタスクを行うために使用するCVSコマンド例
チェックアウト先のディレクトリに移動してからコマンドを実行
チェックアウト cvs co .... ファイル名日付タグなどを指定して取り出す。
最新の状態に保つ cvs update... ディフォルトでは最後にチェックアウトした後にリポジトリに新たに追加されたディレクトリは作業ディレクトリには反映されないので、-dオプションをつけると反映される。またファイル名を指定して特定のファイルだけを更新することもできる。
ファイルおよびディレクトリの追加 cvs add ... バイナリファイルは-kbで追加する。忘れた場合の対処方法の記述あり。
cvswrappersを使用してファイル名に基づいてデフォルトのファイルの種類を指定する方法解説。
特定のファイルを無視する .cvsignoreの内容を読み取ってそれを無視する。総てのひとが同じ環境で作業している場合は .cvsignoreもチェックインすることを推奨していた。
ファイル名の変更 かなり面倒くさそうな手順がのっていた。mv とかremoveをつかう。
ディレクトリ名の変更 ファイル名よりさらに長い手順が載っていた。
変更された内容の確認 cvs diff... ディフォルトではチェックアウトされた時点のファイルとローカルのファイルの差異を調べる。リポジトリの最新バージョンと比較するには cvs diff -r HEAD ファイル名
差異をパッチとして出力する。オープンソースコミュニティなどでよく使われる。 cvs diff -u >出力ファイル名。こうして作られたパッチをソースに適用するには patch -p0 <パッチファイル名
マージ競合の方法。同じファイルの異なる部分を変更した場合はcvsはマージする。同じファイルの同じ部分を変更した場合はcvsはそれを宣言して人間に解決をゆだねる。いずれにせよ変更がなくなってしまうことはない。かえって、解決すべき問題がわかってよい。
変更のコミット 変更して(何も壊れてないことをテストしたら)、そのファイルをリポジトリに格納する。 cvs commit ...しかし、これを行う前にローカルを最新のリポジトリと一致させて(cvs update)競合の解決とテストの実行を行うことを推奨していた。
変更履歴の調査 cvs log...ログメッセージはどんな変更をしたかでなく、なぜそう変更したかを書くように推奨していた。cvs annotate はファイルの各行がいつ、だれにどのリビジョンで変更されたか示す。
変更の削除 まず最新のリポジトリに合わせて(update)、ログを出力し(log)、詳細な差分を調べ(diff)担当者と話し合い、削除しろ(cvs update -jリビジョン番号 -jリビジョン番号 ファイル名)といっていた。そしてコミット。大きな変更の時にはタグで同じことができる。-jオプションをつけるとcvsは現在の作業コピーに変更をマージする。-jオプションを二つ指定するとcvsは2つのリビジョン間で行われた変更をマージする。逆に指定すれば戻すことになる。

CVSキーワードは情報の重複になるので使わないといっていた。


第7章 タグとブランチの使用
タグとブランチは正しく使用しないとリポジトリの構造は複雑に絡み合ったスパゲッティのように見える。
またマージを先送りしていると、最終的に悪夢のような競合がおきたりする。

用語定義
タグ・・・識別名 必ず英字ではじまり、英字数字ハイフンアンダーバーを含めることができる。
通常のタグ・・・ある特定の時点におけるモジュール内のファイル群につける名前。
ブランチタグ・・・ブランチはリポジトリの履歴における分岐点。同じファイルに対して2つ以上の個別の変更がなされ、それぞれ別のブランチに格納されていることが考えられる。ブランチを作成するときにはブランチタグをつくる。

タグとブランチには何通りもの使い方があるので、過度に使用すると混乱する。
シンプルな状態を維持するために推奨される4つの目的
1 リリースブランチ・・・リリースは別のブランチにいれる
2 リリース・・・リリースされた時点を特定する
3 バグ修正・・・適切に修正されたら本流にマージ
4 実験
上記について、具体的に作成するコマンドや注意点を解説。


第8章 プロジェクトの作成

プロジェクトをバージョン管理するためのディレクトリ構造の例
work/
wibble/README BUIDING GLOSSARY
util/ src/ doc/ vendor/ vendorsrc
さらにsrcの下をclieant/ serverという風


第9章 モジュールの使用
モジュールはリポジトリ内の様々な部分をまとめてプロジェクトに論理構造を作成する際に使用する。
モジュールを使って特定のプロジェクトまたはサブプロジェクトが何を意味するかの正確な定義を一か所で行うと、開発者の誤りが減少し、すべてのプロジェクトに対して一貫性のある外部構造を維持できる。

ある程度のプロジェクトの規模になったら水平またはクライアントサーバーなどのサブプロジェクトに分割したほうがよい。
通常独自のサブツリーにサブプロジェクトを割り当てる。
ビルド構造という観点から
1 動作するディレクトリ構造を選択する
2 選択した構造をリポジトリ内で使用する
3 この構造を使用してチェックアウトするように、すべての開発者に要求する。

CVSモジュールは基本的にはリポジトリ内の1つまたは複数のサブディレクトリに名前をつけるための方法のひとつ。
モジュールはリポジトリ内のソースを使用しやすい塊に整理する際に生じるすべての問題に対処するのに役立つ。
CVSROOT/modulesファイル内にはモジュールが定義されている。

cvsのサポートする3種類のモジュール
別名モジュール・・・CVSROOT/modulesファイルに 別名 -a 実際のディレクトリ名で定義されたもの。その別名でリポジトリから呼び出せる。例では、3つのディレクトリをそれぞれ別名をつけ、それらの別名3つをさらに別名にして一括で扱っていた。

一般モジュール・・・チェックアウトする際にツリーの特定の部分の名前を変更できる。本来ディレクトリ構造が違ってしまうのはビルドをまとめるのが困難になるので悪いことだが、サブプロジェクトが相互に依存していない時にはとても有用。例として、社外で必要なファイルだけをチェックアウトすることが頻繁にあるときモジュールファイルに一般モジュールを設定して使う方法がのっていた。 モジュールファイル内に「チェックアウトするディレクトリ名リポジトリ内のディレクトリ名」として定義。

アンドモジュール・・・モジュールは他のモジュール名の前にアンド記号を付けることで他のモジュールの一覧として定義できる。例として一般モジュールを定義した後 モジュールファイル内で「モジュール名 &先に定義したモジュール名・・・・」として、一つのモジュール名で複数のモジュールをチェックアウトしていた。


第10章 サードパーティのコード
プロジェクトが依存する外部ライブラリ(Cならヘッダファイルなど)は、CVSのリポジトリに含めることを推奨していた。バージョンの変更があってもプログラムが動作するようにするためである。リポジトリの位置としてはプロジェクトの最上位レベルの下にvendorというディレクトリをつくり、その下にlib includeというディレクトリを切っていた。

ビルド環境と統合するために、プロジェクトツリーの最上位のプロジェクトディレクトリをします何らかの外部変数を設定し、関連するすべてのビルドでこの変数を参照するようにするのを推奨していた。

ソースコードを含んだライブラリを管理する方法として、ベンダーからリリースが来るたびにリポジトリにインポートする方法を解説していた。

サードパーティの提供するコードを使用していて、それを修正した場合。理想的なのはサードパーティにそれを通知して変更をリリースに反映してもらうこと。でも、それができなければ、リリースがあるたびに、自分たちの行った修正をマージする必要がある。cvsでそれを実施する方法を解説。


付録Aとして cvsコマンドの要約とレシピがのっていた。
cvsは 「cvs <全体にかかるオプション> コマンド <オプションと引数>...」という構造になっている。
全体にかかるオプション一覧
フラグ文字
環境
cvsコマンド一覧
その解説など

レシピとしてはsshによる接続例が何ページにのっているかなどがならんでいる。


付録B  リソースとして
オンラインのCVSリソース
他のCVS書籍
他のバージョン管理システム
参考文献



第2部 JUnitによるユニットテスト

第1章 はじめに
テストが重要なことは誰もが認めているが、実際にはプロジェクトの終盤で行われるだけであることが多い。
しかし、これではバグの発生源を探すのは困難である。
ユニットテストは開発者の作成する部分的なコードであり、とても小さな特定のコードの機能が動作するかテストするもの。開発者が意図したようにコードが動作するかを検証するために行われる。
コードが予想通りに動作するかを確認しなければ、その他の形式のテストを行うのは時間の浪費である。

ユニットテストの目的
・意図したとおりに動作するか確認する
・常に意図したとおりに動作するか確認する・・・開発者は唯一の正しい経路のみをテストしがち
・信頼できるか確認する・・・完全なコードを作成できる人はいない。なにが来ても動くようにコードをかけば、コードは膨れ上がってしまう。どこに問題があるかわかっていれば十分、例として数字の一覧を入れ替えるルーチンを作成していると、空の一覧の場合はどうするかという問題があるが、メソッドの仕様として空の一覧で呼び出されたら例外を返してもいいわけで、どんなときでも動くようにするというわけではない。
・意図を記録しているか確認する・・・さまざまな条件下でコードがどのようにふるまうか示す実行可能なドキュメントとして機能する。書面と違って内容がコードから離れていくことはない。

ユニットテストの実行方法
コードを作成する前に対象となるメソッドのテスト方法を決定し、実装コードと同時にテストコードを作成する。
そして、新しいテストだけでなく、以前のテストにもパスすることが大事。
すべてのテストにパスしたかは自動で判定される必要がある。

テストしないことに対する言い訳
・テストの作成に時間がかかりすぎる・・・終盤の一括テストの方が時間がかかる
・テストの実行に時間がかかりすぎる・・・そのようなテストはいけない。ユニットテストは迅速にほんの数秒でテストできるようにすべき。長いテストは切り離して、1日または数日ごとに実行する。
・自分のコードをテストするのは別の人の仕事だ・・・自分の仕事は動作するコードをつくることです
・コードがどのようにふるまうべきがよくわからないのでてすとできない・・・ではどうやってコードを作成する?
・コードはコンパイルすることができる・・・コンパイルやインタープリタは構文が正しいと保証してくれるだけ
・テストの作成ではなくコードの作成で報酬を得ている・・・同さするコードで報酬を得ているのだ
・テスト担当者と品質保証スタッフを失業させてしまうことに罪悪感がある・・・ユニットテストと機能テスト受け入れテスト、パフォーマンステスト、環境テストなどとは違う
・社内規則のため本番システムでユニットテストを行うことができない・・・本番システムで行うのはユニットテストではない


第2章 ユニットテストの開始
ユニットテストは、別の部分のコードを実行し、他の部分のコードが意図したとおりに動作するかを判断するコード。
具体的にはアサートを使用する。
実装の例
Public void asserTrue(boolean condition)
if (!condition){
abort();
}
}

テストの例として数字のリストから最大値をみつけるための1つの静的メソッドをあげていた。
シンプルな数列 [7, 8, 9]なら9をみつける。
このメソッドの考えられる限りのテストを見つけるという例題
並べ替え [7, 8, 9] [8, 9, 7] [9, 7, 8]
最大値が重複 [7, 9, 8, 9]
一つの数字しかない場合[1]
負の数の場合[-9, -8, -7]
これで実際に問題がおきるのを確認。こうして問題を解決しておけばよい。
本では、テストするメソッドとテストコードがのっていた。
バグは端にもっとも多く現れる。(渡す配列の最初または最後に最大値があるときに生じる。
例では7,8,9の配列を入れ替えて試していた。そしてforループの終了が早いエラーを発見する例をやっていた、
元からバグのあるメソッドのコードをつくって、このようにバグを発見していく手順で説明していた。
また、空の配列をどうするかという問題にあたって、これは仕様で決まっていないことに気が付いて、設計上の問題をはっけんできることを示していた。


第3章 JUnitによるテストの作成
テストコードの命名規則 createAccountというメソッドをテストしたいなら最初のテストメソッドはtestCreateAccountにするとよい。

テストコードの行うべきこと
・テストに必要なすべの条件の設定(必要なオブジェクトの作成や必要なリソースの割り当てなど)
・テスト対象のメソッドの呼び出し
・テスト対象のメソッドが予想通りに機能するかの確認
・テスト実行後の整理
コードを実行するときには、本番コードを実行する代わりに、テストコードを実行し、慎重に管理されたっ条件下で本番コードを順番に試す。テストフレームワークに関する一般概念はどのような言語や環境であっても同じ。

JUnitの提供するassertメソッドの解説
assertEquals・・・期待値と実際の値を比較、配列の内容は比較しない。浮動小数点の場合は許容誤差(有効桁数)も指定
assertNull・・・特定のオブジェクトがNullである、またはNullでないことを調べる
assertSame・・・期待値と実際の値が同じオブジェクトを参照することを調べる
assertTrue・・・特定のboolean型の条件式が清であることを調べる。ただし、一番最後にassertTrueが一つだけあるテストは、最後までコードが実行されたのだから動作するはずという考えがみえて、テストではなく希望的観測といっていた。
fail・・・任意のメッセージを表示して、テストを即座に失敗させる。
テストではメソッドの様々な面と関係をテストするので、通常はテストメソッドには複数のassertメソッドがある。どこかのassertで失敗すればテストはそこで終わりになる。その修正が終わるまで先に進んではいけない。常にすべてのテストをパスするようにすべき。

JUnitフレームワーク
assertを動作させるフレームワーク
実際にテストコードで解説
import junit.framework.*;

pubulic class TestSimple extends TestCase {
pubulic TestSimple(String name){
super(name)
}
public void testAdd(){
assertEquals(2, 1+i);
}
}

TestCaseという基底クラスはassertメソッドなどユニットテストに必要な機能の大部分を提供する。
テストすら素にはtestではじまる個別のテストメソッドがある。
またSuiteメソッドを定義すれば特定のメソッドを指定して実行することもできる。

Junitテストの複合
テストスイーツを作成すると、希望するテストのコレクションを返すことができる。
各テストがすべてのテストから切り離されて実行されうためには環境の一部を初期化するか、テスト実行後に後片付けを行う必要がある。設定を初期化するためのメソッドprotected void setUp(); テスト環境を整理するためのメソッドprotected void tearDown(); が提供されている。これの使い方解説。
テストスイートごとの前処理と後ろ処理・・・必要なテストの集合を取得してTestSetupオブジェクトにラッピングする必要がある。同じクラスでテストごとのsetUpメソッドとテストスイートごとのsetUpメソッドの両方を使える。

assertメソッドをカスタマイズして、独自のassertメソッドを作る場合
TestCaseクラスをサブクラス化し、すべてのテストがそのサブクラスを継承するのを推奨していた。

JUnitと例外
テストするメソッドに例外を起こさせる例・・・nullのリストを渡したら例外を起こす
public void testForException(){
try{
sortMyList(null);
fail("Shoud have trown an exception");
}catch (RuntimeException e){
assertTrue(true);
}
}
最後のassertTrueは制御フローはここを通過すべきと予想するのを明記している。後で生じる可能性のある誤解を解くためのドキュメントの役割をする。
一般的には宣言された例外ごとにメソッドをテストする必要がある。
予想外の例外はJUnitに任せることを推奨していた。
public void testDatal() throws FileNotFoundException{
FileInputStream in = new FileInputStream("data.txt");
.....

}
これで、JUnitフレームワークは発生した例外を受け取り、エラーとして報告する。さらにバグに至るまでのすべてのスタックトレースが報告されるので失敗の理由を見つけるのに役立つ。

通常JUinitはtestではじまるメソッド名を実行するので、取り組む準備ができるまでpendingTestMyThingなどの名前をつけておくことを推奨していた。このpendingは実行まちのテストの命名規則として統一して使う。

絶体にしてはいけないのはテスト結果の失敗を無視するという習慣。

JUnitを使用してテストを作成するのに本当に必要なのは
1 junit.Framework.*を取り込むimport文
2 クラスをTestCaseから継承させるextends文
3 super(string)を呼び出しているコンストラクタ
多くのIDEでは少なくともこれらは提供されている。
こうして作成されたクラスはJUnitのTestRunnerを使用して実行し、そのクラス内のtestではじまるメソッドは自動的に実行される。
TestRunnerを使用しないでテストクラスを直接実行するためのスケルトンの作成を付録Cで解説。


第4章 テストする内容:Right-BICEP
「失敗しそう」な状況は経験で感じ取れるが、初心者用にテストすべき6つの特定の部分を解説

・Right(適切)・・・その結果は適切か
 「コードが正しく実行されたと、どうすればわかるか」に満足に答えられないとコードやテストを作成できない。もし、はっきりしなければ、自分で考えた動作を予測してつくることはできるはず。そしてフィードバックで予測を微調整すればよい。大量のテストデータを使うときにはデータファイルから読み込ませるとよい。例が載っていた。ただし、エラーがでたら用意したデータの妥当性はチェックすべきともいっていた。

・Boundary(境界)・・・すべての境界条件はCORRECTに従っているか
 端になるのに考慮すべき条件
 ・完全に偽の入力値や矛盾した入力値
 ・不適切な形式のデータ
 ・空の値や欠落した値
 ・合理的な予想をはるかに超える値(人の年齢が10000歳など)
 ・リスト内で発生してはいけない値の重複
 ・順序付けされていない順序月リスト。あるいは順序付けされている順序なしリスト(ソートアルゴリズムとして、ソート済みリストや逆順のリストを処理するなど)
 ・一貫性のない順序で発生したり、予想される順序に反して発生するもの(ログインするまえにドキュメントをプリントするなど)

 CORRECTの内容は5章で解説

・Inverse(逆の関係)・・・逆の関係を確かめられるか
 計算結果を2乗して、その結果が元の数字にある程度近いことをテストすることで平方根を計算するメソッド。
 データを検索することによって、そのデータがデータベースに適切に挿入されたことを確認するなど。
 注意すべきは両方のルーチンにある共通のエラーでバグが隠される場合があること、狩野なら別のソースを利用して逆のテストを行うこと。

・Cross-check(クロスチェック)・・・他の手段を用いて結果をクロスチェックできるか
 図書貸し出しシステムなら、貸出部数と書庫の部数の合計はつねにすべての部数と一致するなど

・Error conditions(エラー条件)・・・エラー条件を強制的に発生できるか
 著者らが考え付いた環境的問題
 メモリ不足、ディスクの空き容量不足、実時間に関する問題、ネットワークへのアクセス可否、システム負荷、カラーパレットの制限、高すぎる低すぎるビデオ解像度。

・Performance(パフォーマンス)・・・パフォーマンス特製は妥当な範囲か
 パフォーマンス特製の簡単な回帰テストを行うことを推奨していた。例として特定のWebサイトを遮断するフィルタをあげ、1万とか10万のサンプルサイトで動作確認をして、パフォーマンス目標を満たしていることを確かめる。ただし実行には時間がかかるので、毎晩とか2・3日おきに実行していると、どんな変更を加えた時にパフォーマンスがおちたか、迅速にはっけんできる。
JUnitPerfなどにタイミングや重い付加条件のシュミレーションをサポートしている。


第5章 境界条件:CORRECT
 根本的な疑問「他に失敗する可能性があるのは何ですか」
 しっぱいしそうなことを思いついたらそのためのテストを作成し、パスしたら再度同じことを問いかける。

・COnformance(適合性)・・その値は予想される書式に適合していますか。
 電子メールからユーザー名を抽出するメソッドなら、@の前の文字を抽出すればいいが、もし、@がなかったらどうする?
 あるいはデータレコードに、最終的にはトレーラレコードにリンクされているヘッダーレコードを含む何らかの報告データをよんでいたとしたら、ヘッダーがなく、データとトレーラだけの場合は?データがなくヘッダーとトレーラだけの場合は?トレーラがなく、ヘッダーとデータだけの場合は?トレーラしかない場合は?ヘッダーしかない場合は?データしかない場合は?

・Ordering(順序)・・・一連の値は必要に応じて順序付けされる、もしくは順序付けされないという状態になっているか
 検索対象がリストの最初または最後に存在する場合のテストはバグが多いのでテストする必要がある。
 他の順序の例としてレストランの注文を処理するメソッドで、前菜からデザートになっているはずのリストで逆になっているならどうなるか?普通はそうだが、甥っ子のアイスクリームは前菜のサラダといっしょということもある。そういったときどうなるのか?
 またソートルーチンで一連のデータがすでに順序付けられていたら?あるいは逆順でソートされていたらどうなるのか?問題を引き起こすことがあるのか?
 自問して、必要なテストを作成する必要がある。

・Range(範囲)・・・その他意は合理的な最小値と最大値内になっているか
 型を指定しただけでは必要以上の広い範囲の値を変数にだいにゅうできてしまうという状況を意味する、便利で包括的な言葉。人間の年齢や角度、円周など。
 優れたオブジェクト指向設計では、境界のある整数を格納するのにそのままでは使用しない。
 例として角度0-359の整数で生成される変数をあげていた。これでシステム全体に対してその変数の範囲は保障される。
 例として配列を使用して文字列のスタックを実装するクラスをつくり、空スタックやスタックオーバーフローがチェックされていないのでバグが潜んでいるとしてチェックを追加するのをあげていた。

・Referrence(参照)・・・コードはそのコード自体の直接制御下にはない外部の要因を参照していますか
 クラスの状態と他のオブジェクトや全体的なアプリケーションの状態について前提をもたなければならない場合は、そのような条件がみたされない場合はコードが正しく動作するか確認が必要。例口座利用履歴を表示するなら、顧客がログインしていなければならない。
 一部の言語(Eiffel)には事前条件、事後条件のサポートがある

・Existence(存在)・・・その値は存在していますか(たとえば、null意外、0以外、1つの集合に含まれるなど)
 潜在的バグの多くは「ある特定のモノは存在するか」という重要な疑問を尋ねることでみつけられる。
 渡す値や保持する値は、その値が存在しなかった場合、null 空白 0だったらメソッドに何がおこるか自問するべき。
 ほとんどのjavaライブラリメソッドは存在しないデータに直面すると何らかの例外を返すが、一般的な実行例外をデバッグするのは困難。それよりは「年齢が設定されていません」がかえってくれたほうがよっぽど親切。
 ネットワーク、ファイルのURL、ライセンスキー、ユーザ、プリンタこれらがなかった場合どうなるかメソッドの動作を確認すべき。

・Cardinality(カーディナリティ)・・・十分な数の値が存在しているか
 360㎝の芝生を90㎝幅のフェンスで区切りたい場合ポストは4本ではなく5本必要。これは一つ違いのエラーの例。
 値の集合の数は3つ、0、1、2以上。
 例パンケーキ店の注文ベスト10をリアルタイムで更新してマネージャのPDAに報告するプログラムをつくる。テストするのは?
  ・一覧のケーキが10に満たなくても報告書をつくれるか。
  ・一覧にケーキがまったくなくても報告書を作れるか
  ・一覧のケーキが一つだけでも報告書をつくることができるか。
  ・一覧のケーキが10に満たなくてもケーキを追加することはできるか。
  ・一覧にケーキがまったくなくてもケーキを追加することはできるか。
  ・一覧のケーキが1つだけでもケーキを追加することはできるか。
  ・メニューのケーキが10に見た以内場合はどうなるか
  ・メニューにケーキがまったくない場合はどうなるか
 すべてを検討した後に、マネージャはトップ10でなくトップ20を見たいというかも、あるいはトップ5を
 変更するのは一行
  private final static int NUMBER_TO_RETAIN = 20;
 テスト用アクセッサー
public int getMaxEntries(){
return NUMBER_TO_RETAIN;
}

・Time(時間 絶対的および相対的)・・・すべてが順次、適切なタイミングで時間内におこっているか。
考慮すべき時間の側面
 ・相対的な時間(時間内の順序)
 ・絶対的な時間(経過時間と実時間)
 ・並列処理の問題
 
 一部のインターフェースは基本的にステートフル loginメソッドはlogaputメソッドの前に呼び出される。これらのメソッドが不適切な順序で呼び出されたらどうなるか?
 一時リソースが使用可能になるのをメソッドがどのくらい待つかという問題もある。永遠に待つのはもっともいけない。
 一日の長さは24時間ですか?これが問題となることもあります。夏時間と冬時間の境目もある。基本ライブラリがこれらの問題を処理してくれると考えてはいけない。
 複数のスレッドが同じオブジェクトを同時に使用した場合はどうなるか?
 同期をとらなければいけないグローバルまたはインスタンスレベルのデータやメソッドはあるか?
 ファイルやハードウェアに対する外部アクセスはどうか?
 同期をとる必要のあるデータ要素やメソッドにはsynchronizedキーワードを加えてテストの一部として複数のスレッドを同時に実行するようにする。

演習問題として
1シンプルなスタッククラス
2ショッピングカート
3ファックススケジューラ
4刺しゅう機能付きの自動ミシン 座標
5オーディオ/ビデオ編集


第6章 モックオブジェクトの使用
 テスト対象のメソッドが、ネットワーク、データベース、サーブレットエンジンなど他の扱い難いものに依存する場合は、注意しないとテストを実行できるだけの状況を与える為に、最終的ににはほとんどすべてのシステムコンポーネントを初期化するようなテストを作成することになってしまう。このようなときは照明チェックの代役のように目的に安易に取り組むことができる安価な代役をたてる。
 モックオブジェクトは現実世界のオブジェクトをデバッグ用に置き換えたもの。

モックオブジェクトが役立つ状況
 ・実際のオブジェクトには、費決定性のふるまいがある(株式相場の情報提供のように予期しない結果を生む)
 ・実際のオブジェクトは設定を行うのが大変である
 ・実際のオブジェクトはトリガを引き起こすのが困難な振る舞いがある(ネットワークエラーなど)
 ・実際のオブジェクトは遅い
 ・実際のオブジェクトはユーザインターフェースを保持している、またはユーザインターフェースである。
 ・テストでは、どのようにしようされたのかを実際のオブジェクトに尋ねる必要がある
 ・実際のオブジェクトはまだ存在していない。

モックオブジェクトを使用するための3つのステップ
 ・インターフェースを使用してオブジェクトを記述する
 ・そのインターフェースを本番コード用に実装する
 ・そのインターフェースをテスト用のモックオブジェクトとして実装する。

例として代謝時刻になったら音楽を鳴らすプログラムで、時刻のオブジェクトのモックオブジェクトを作成していた。
現在時刻など、現実世界のさまざまな環境の物事にに対応するインターフェースから始め、実装し、時刻をずらしながら音楽がなったかたしかめる(確かめるのはassertで自分で耳をかたむけている必要はない)

サーブレット・・・Webサーバが管理するコードの塊。特定のURLへのリクエストはサーブレットコンテナ(またはマネージャー)に転送されて、コンテナ化がサーブレットのコードを呼び出す。

javaプログラマのためのMok Objectsというフレームワークがあるので、サーブレット環境でのテスト用クラスもある。

EasyMockはモックオブジェクトを動的に作成するためのJavaAPI。対応するモックオブジェクトに対して記録モードと再生モードを指定して使用する。オブジェクトが記録モードのとき、注目すべきメソッドを呼び出し、希望する返り値を指定する。そして再生モードにして、メソッドを呼び出すと指定した返り値が受け取れる。残りのメソッドは呼びだれると実行時例外を起こすが定義は必要ない。他にもメソッドが特定の値を何かい返すか指定したり、voidを返すメソッドが実際によぼれたことを検証するオプションもある。

サーブレット環境ではモックオブジェクトに代わる方法としてCactusという重いフレームワークを使う手がある。

演習
指定されたメソッドをもつMP3プレーヤーのコントロールパネル用のシンプルなモックオブジェクト(手動)を考える


第7章 良質なテストの特性
 ユニットテストは強力な魔法であるが、不適切に作成、実装されるとテスト時代の保守とデバッグにとても多くの時間を費やすことになり、プロジェクト全体が損害をうける。
 良質なユニットテストが問題を起こしにくくすることを証明するために、ユニットテストが実行された(assertのある)モジュールとないモジュールで問題の発生数の統計をとると、テストされているモジュールほど問題がないとわかった。

良質なテストの特性A-TRIP
・Automatic(自動)
 テストの実行とテストの確認が自動でないといけない。特に確認はテストがすべき。
 テストの実行はIDEのボタン一つで実行できる簡単なものでないといけない。モックオブジェクトなどを使ってテストに必要なものも自動で用意されるようにする。コードがチェックインされたら自動でテストするような無人のチェックシステムが必要。人間はテストしないことがあるので。

・Thorough(徹底)
 失敗しそうなことすべてをテストする。網羅性を高めるにはコードカバレッジツールを使用するとよい。バグはソースコード全体に均等に分散されるわけではなく、ある領域にままって集まる傾向がある。バグの塊であるコードは破棄して、ゼロから書き直す方が安価で苦痛はすくない。

・Repeatable(繰り返し可能)
 すべてのテストが任意の順序で繰り返し実行できて、同じ結果をださなければならない。データベースやWebサーバのような環境はモックオブジェクトでつくりだし、開発者用の分離された実験用の「砂場」が必要。そうでないと本物のバグでないテストの問題による錯覚で時間を浪費する。

・Independent(独立)
 テストを作成するときには必ず一つのことだけをテストする。
 テストが失敗したらコードのどこに隠れたバグがあるか明らかになるべき。
 個々のテストを任意の順序で実行できるようにすべき(setupとreardownメソッドを使う)

・Professonal(専門的)
 テストコードは実際のコードと同じように同じようにかく。同じようなコードを何行も繰り返し、何の関数もオブジェクトもない地道なことを行うコードを作成すべきではない。テストを作成する目的だけでテストを作成すべきではない。テストコードはバグが含まれる可能性のあるメソッドに関して興味深いことすべてをテストする必要がある。
 また、テストコードは本番コードと同じくらい作成する必要があると考えて間違いない。本番コードと同じくらい専門的にきちんと整理し、適切な設計と分解をおこなわなければいけない。

テストコードが正しいことを確認する方法
・バグの修正時にテストを向上させる
・バグの導入することでテストを検証する

バグの修正方法
1 バグを識別します
2 失敗するテストを作成し、バグが存在することを検証する
3 今度はテストがパスするようにコードを修正する
4 すべてのテストが依然としてパスすることを検証する
「これと同じような問題が他にもどこかで起こる可能性はあるか」と自問する。
プロジェクト全体に学習したことを適用する。新たにみつけた知識を適切なすべてのユニットテストに反映する。そうすることで類似のバグすべてをとらえたことになる。

テストが正しく作成された確信がないときは、検出しようとしているバグを本番コードに恋に含ませて予想通りにテストが失敗することを確認する。
例としてデータベースに口座を追加してその口座をみつけようとしているテストメソッドをあげていた。口座を追加するとき単に値を返すだけにして検索が失敗するようにする。


第8章 プロジェクトのテスト
 プロジェクトの全員がユニットテストを行うことで生じる問題

テストコードの格納場所
 小規模なプロジェクトなら本番コードと同じディレクトリにテストコードを置くので十分。しかし、これでは本番コードのディレクトリ内にテストコードが散在してしまうデメリットがある。
 邪魔にならないサブディレクトリtestにテストコードを入れる場合は、テスト用に本番コードのサブクラスを作成しない限りprotectedなどのメンバにアクセスできないデメリットがある。例をあげて説明していた。
 並列ツリーは本番コードと同じパッケージにTestクラスを格納するが、ソースコードは別にすること、両方のツリーのルートディレクトリをCLASSPATHに置くのが必須。ディレクトリ構造は同じにする。
 いずれにしてもチームで一貫した方法で行うことが大切。

テスト作法
 チームメンバと一緒に作業しているときは何らかのバージョン管理を使っているのが普通。チェックインする前に完全なユニットテストを行いテストをパスすることが必要。また誰かか自分のコードにアクセスしたらすぐに、あらゆる場所にあるすべてのテストがパスする必要がある。「すべてのテストは常にパスする」が大切。
 コードに関する違反
 ・不完全なコード(1つのクラスファイルだけをチェックインし、そのファイルが依存する他のファイルをチェックインするのを忘れるなど)
 ・コンパイルできないコード
 ・コンパイルできるが、既存コードをコンパイルできなくするような、既存コードを破壊するコード
 ・対応するユニットテストのないコード
 ・ユニットテストが失敗するコード
 ・対応するテストはパスするが、システム内の別の場所にある他のテストを失敗させるコード
コードに対して矛盾する変更を行う必要がある場合やシステムの別の場所で他のテストを失敗させる要因となる変更を行う場合は、プロジェクトで使用している方法やプロセスに依存するが、すくなくともチーム全員がビルドが壊れていることを把握している必要はある。


テストの頻度
 一般的な指針として
 ・新しいメソッドの作成・・・ローカルのユニットテストをコンパイルして実行
 ・バグの修正・・・テストを実行してバグを明らかにする。コード修正を行いユニットテストを再度実行する。
 ・コンパイルの実行・・・ローカルのユニットテストを実行
 ・バージョン管理への個々のチェックイン・・・すべてのモジュールまたはシステムのユニットテストを実行
 ・常時・・・専用マシンは1日中何もない状態から完全なビルドとテストを自動的に実行している必要がある。
なるべく常時ビルドをおこなうのを推奨していた。

テストとレガシーコード
 プロジェクトがユニットテストのない大量のコードをすでに保持している場合どうするかは、コードがどのような状態かによる。必要とする個々の部分に容易に到達できるような適切に分解されたモジュールであれば、ユニットテストを容易に追加できる。コードの状態が複雑に絡み合った「大きな泥団子」なら大幅な書き直しなしにテストすることは不可能に近い。
 既存のコードのテストできるすべてのコードに対してユニットテストを追加するのはあまり達人的ではない。労力に見合う見返りをうけるためには、ほぼ壊れているコードから最初にテストを行うほうがいい。
 もっとも重要なのは「逆行」を防ぐこと。保守の修正と強化を行うことで既存の特性にバグが発生するというデススパイラルを回避すること。新しいコードが既存のコードを何もこわしていないことを確認するために回帰テストとしsてJUnitテストを行う。レガシーコードに対応するときには全体を網羅する必要はないが、痛みのひどい部分だけ摘要する。
 例として、オブジェクトデータベースアクセスに使用される下位レベルのライブラリにバグがある場合のアプリケーションレベルでの修正がのっていた。名前にスペースが入っているとアプリケーションが壊れるのだが、これを修正したところ、こんどはディレクトリにスペースが入っていると壊れるという別のバグが発生。この時点で下位レベルAPI呼び出しをテストするJUnitテストを作成。コードがリポジトリにコミットされるたびにユニットテストが自動実行されるようにしたところ、テストが2日連続で失敗。バグは固まっているのだ。そして、テストがなければ毎晩ビルドのたびに不正なコードが会社全体に伝播されていしまう。2度現れた問題にはその週のうちにJUnitを作成するという規則を作ったそうだ。

テストとレビュー
 著者はコードのレビューを推奨していた。その順番
1 テストケースやテストコードを作成する
2 テストケースやテストコードをレビューする
3 レビューを受けてテストケースやテストコードを修正する
4 テストをパスする本番コードを作成
5 テストコードと本番コードをレビューする
6 レビューをうけてテストコードと本番コードを修正する

レビューはチームの意思疎通を向上させるという意味で有効で効率的。
何度も発生するよくある問題を記録することで、よりシステムを安定させることができる。


第9章 設計上の問題

テスト容易性を保持した設計
 テストできるようにコードを明示的に設計することで、コードを適切に分解し(内気にする)コードの保守を容易に行える。例として何かを計算して、その秒数sleepするコードをテストする。失敗する可能性があるのはシステムのSleep呼び出しではない可能性が高い。必要なのは秒数が正しく計算されるかテストすること。常に「このコードをどのようにテストするか」考えることで、設計上の誤りを見つけることができるはず。

テストのリファクタリング
 例としてレシピ管理システムのコードをあげ、初心者が書いたコードではテストが困難であることを示す。GUI操作で必要な部分にたどりつかないといけないから。そして、レシピデータのテストを容易に構築し、レシピが画面、ディスク、ネットワーク、その他どこでも行き来できるようにするために、レシピを保持するためのオブジェクト作成から始め、コードを作成。そしてGUIコードを使用しないでディスクへの読み書きをテストする本物のテストケースを作成。テストを行い問題を発生させ「この問題がコードの他の場所でも起こる可能性はあるか」自問自答する。そして問題を修正するという手順をとっていた。結果といして設計がとてもきれいになることを示していた。

クラスの不変条件
 クラスの設計を改善する方法はクラスの不変条件の定義と検証を行うこと。
 クラスの不変条件が適用される可能性がある領域
 ・構造的領域。データの構造的な特性、怜として受注システムでは各明細は何らかの注文に属さなければならないなど。不変条件をチェックすると、運がよかったとうだけでテストをパスしていないか確認できる。
 ・数学的な領域。データ構造の論理的なモデルを考察。例として銀行口座の貸借は、残高に対応づけられなればいけない。境界条件ともいえる。
 ・データの一貫性 オブジェクトは同じデータを異なる方法で示す。例、ショッピングカートの商品一覧、売上総額、カート内の商品の総数は密接に関連する。詳細な商品一覧から他の2つの値を得られる。これらの値は不変条件として一貫していなければバグがある。

テスト駆動設計
 テスト提唱のメソッドを作成する前にテストする技術。
 テストを先に作成することで、コードの実装者としてでなく、コードの利用者になれる。するとインターフェースを実際にどのように使用するかについて、はるかによく理解でき、その設計を改善する機会を見いだせる。例として印刷ページに特殊な書式設定を行うルーチンを作成する。テストコードを先に作成すると用紙のサイズ指定を別のオブジェクトに抽出することが必要とわかり、テストは整理され読みやすくなり、使用するアプリもきれいになる。

演習として、2つの日付の間にある営業日数に基づいて利息を計算する利息計算器をテストファースト設計を使用して1度に少しずつ作成する。

無効なパラメータのテスト
 入力データの妥当性を確認するのは誰かについては場当たり的な解答しかないが、特に自分と関係がある入力データの側面は自分で確認すべき。しかしこれでは多くの部分で確認が行われ時間と労力が無駄になる。すぐれた設計では妥当性を確認する部分をあらかじめ構築して、システムの小さな既知の部分に局所化する。
 一般的に最も容易に採用できる規則は「入り口で野蛮人を遮断する」方法。自分が入力データに責任を負っているなら、それを確認するのに時間を費やすべき。

付録A 落とし穴 不注意から繰り返し浮上する問題や誤解
1 コードが動作する限り問題ない・・・テストのないコードやユニットテストが失敗したコードは壊れている。
2 スモークテスト・・メソッドが最後まで失敗せず実行されればそれでパスと考えること、しかしデータやその他の古い米の妥当性を確認しないのは錯覚のテスト。
3 自分んおマシン上での動作
4 浮動小数点の問題
5 時間のかかりすぎるテスト・・・平均よりも時間がかかるテストは抜き出してどこかにまとめる。そして1日1度などの実行にして、他のテストの邪魔にならないようにする
6 失敗したままのテスト
7 一部のマシン上でのテストの失敗
8 実行されていないmain・・・JUnitのTestRunnerではmainは実行されない、設定コードは置かないこと。

付録B JUnitのインストール

付録C JUnitスケルトン・・・テストを実行する決まり文句が記述されているテンプレート

付録D リソース
 Web上のリソース・・・Ant、CactusなどのリソースURLがのっていた。
 参考文献

付録E ユニットテストまとめ
 一般原則、テストする内容、問うべきこと、適切なテスト、境界条件

付録F 演習問題の解答



第3部 プロジェクトの自動化

第1章 はじめに
 プロジェクトの作業の一部をコンピュータにやらせ、人間は人間が得意とすることだけを行う方法を解説。

 自動化の種類
 ・コマンドによる自動化・・・すべてのマシンで同じ状態になるようにビルドを生成するステップを実行したり、アプリケーションを一貫して配置するために決まりきった指示を出すスクリプト
 ・定期的な自動化・・・コマンドの自動化を手動で実行する必要がないように、スケジュールにそのコマンドを入力する。
 ・トリガによる自動化・・・サイトにエラーイベントがあるか定期的に見張りポケベルに知らせるモニタなど、何らかの重要なイベントが発生したときに自動的に実行する。

自動化を開始するために必要なこと
・バージョン管理
・自動テスト(結果を自分で確認するテスト)
・スクリプト化
・通信デバイス

なぜ自動化する必要があるのか
 ビルドを組み合わせ、リリースコマンドでいっぱいのチェックリストを尊守し、サーバに存在するコードをコピーし、実行しているプログラムを監視すろいった作業よりも、プログラマには行わなければいけないことが他にある。また、自動化された手続きは正確で一貫性があり、繰り返し可能なので、自動化することで自信が持てる。またドキュメント化の必要性も軽減する。ビルドやリリースの生成方法を説明する代わりスクリプトの実行方法を示せばよい。作業を軽減し、重要な手続きを必要な回数だけ実行できる

いつ自動化するのか
 手動での作業に飽きた時はいつでも。経験上は2回より多く実行される手動のタスクは自動化すべき。
 エラーは退屈から自然に発生する。繰り返される主導のタスクに一貫性と正確性を持たせる必要があるときは自動化を導入する。ただし、自動化の時間が、自動化によって節約される時間より長くてはいけない。

いつ自動化を実行するか
 自動化のロードマップがのっていた。
 1ステップのビルド(コマンド指定)→定期ビルド(毎時)チェックアウト+コンパイルとテスト→プッシュボタンリリース(毎週)ブランチテスト、パッケージ化リリース→インストールと配置(毎月)自動更新・インストール・テスト・納品→最初に戻る。
このサイクルの真ん中に監視(常時)があり携帯電話や視覚デバイスRSSを使う。


第2章 ステップビルド
 コードのビルドとテストを自動化する
 ビルドプロセスはソフトウェアを大量生産するレシピ。

CRISPなビルドの作成
 ・Complere(完全)
  ビルドプロセスの実行前や実行後にファイルを追加するようなことはない。自立している。

 ・Repeatable(繰り返し可能)
  CVSなどのバージョン管理システムにビルドファイルとビルドのすべての入力を格納すること。そうして前のソフトのリリースが容易に作成できる。

 ・Informative(詳細な情報)
   ソフトウェアの状態を常に把握できるように有益な情報を発信する。成功すれば動作するという自信になり、失敗すれば問題をデバッグする時間を節約できる。

 ・Schedulable(定期実行可能)
  ビルドを完全かつ繰り返し可能にすることで、ビルドをスケジュール通りに効率的に実行できる

 ・Portable(移植可能)
  ビルドの実行が特定のIDE、マシンのIPアドレス、実行元のディレクトリに依存しない。Windows上でUnixのアプリをビルドするという意味ではない。

プロジェクトのディレクトリ構造をつくる
ルートの下にsrc, test, vendorというディレクトリをつくりこれはバージョン管理内。ビルドの出力するbuildディレクトリなどを解説。

最初のビルドの作成はコマンドラインによって行いそれをスクリプト化していた。

Antによるビルド
Ant・・・Javaプロジェクトに特化したオープンソースのビルドツール
 メリット Antのビルドファイルは移植可能、Antはファイウrの依存性を追跡する、Javaソースファイルのコンパイル方法を理解している。またJUnitテストを実行するタスクも含まれている。他にもタスクを拡張できる
 デメリット ビルドのレシピをXMLファイルで表現しなければならない。

Antのビルドファイルの作成方法を解説
JavaプロジェクトのビルドにはmakeよりAntが適しているといっていた。Antは専用ツールでmakeは一般ツールだからと。


テストのコンパイルと実行、テスト結果を表示する、テストスイート作成をAntで解説。

出力が再現できるならビルドの出力をすべて削除するAntのターゲットを定義する方法を解説。

複雑なプロジェクトをビルドする際のビルドのスクリプト化の解説
Groovyというスクリプト言語を使っていた。

コードが蓄積するまでビルドの自動化をおくらせてはいけない。
ディレクトリが決まったらすぐに行おう。
しかし、コードが溜まってしまっているから遅すぎるということはない。


第3章 定期ビルド
 1ステップのビルドプロセスはコマンドによる自動化のメリット。
 次はコンピュータにボタンを押させるという定期テストの段階に進む。
 一定の間隔で実行されるビルドは問題を迅速に発見し、修正を容易にする。

 cronによる定期実行方法解説・・・バージョン管理あから最新のコードをチェックアウトしてビルドファイルを呼び出し、コードのビルドとテストを行う。ログファイルにビルドの結果を記録する。
 ただ、結果をWebに掲示したり電子メールにしておくるなどの場合独自のビルドのスケジューラを入手したほうが達人に近づける。

 CruiseControlによるビルド解説。
  ビルドマシン選択
  インストール
  ビルドワークスペース用意・・・ビルドディレクトリ作成、プロジェクトチェックアウト、ログディレクトリ作成
  デリゲート用ビルドファイルの作成
  ビルドプロセスの設定・・・プロジェクトの定義、ビルド起動、変更の確認、ビルド間隔定義、ログ保存。XML形式でテスト結果の生成、ビルド結果の公開

 CruiseControl実行解説

 CruiseControlにビルド状況の公開を行わせる方法・・・電子メールで知らせる、するとWebページからビルドの履歴が取得できる。

 CruiseControlを大規模プロジェクトで使用している例


第4章 プッシュボタンリリース
 ビルドやテストは重要だが、納品しなければ意味がない。リリースが最終目標。
 リリース手順を自動化する。

プロジェクトが複雑になる前にソフトウェアのリリース生成を開始すべき。

リリースの中身
 名前とバージョン番号で一位に識別される。通常名前は市場が手イグするソフトウェアプロダクト名に似ている。バージョン番号はメジャーとマイナーがある
 各リリースはリリース内に含まれる昨日軍によって定義される。エンドユーザに価値をもたらす機能が制作されたときリリースを生成する。
 リリースには必要な内容がすべて含まれている、ドキュメントも含む
 リリースのインストールに複数の手順が必要になる場合は、インストールスクリプトまたはユーティリティを1回実行するだけで必要な手順がすべて行われる。

架空のプロジェクトについてリリースの例をあげる
 最初はQAチーム向けリリースを行い、作業が増えないうちにリリース生成を行う。
 リリースに向けて作業の同期をとる
 プログラマでなくリリースマネージャになって開発ディレクトリでないきれいな場所でバージョン管理リポジトリから現在のファイルをチェックアウトしてビルドし成功を確認。
 リリースブランチを作成する。
 リリースブランチをチェックアウトしてテスト集成しコミット
 リリースを顧客が扱いやすい形にパッケージ化する・・・配布ファイルの作成。標準的な配布ファイルの中身がのっていた。ZIPかtarが一般的。これを行うスクリプトを作成する例。
 普通は無いが、テスト用追加配布ファイルのパッケージ化の例もあった。
 配布ファイルの生成
 配布内容のテスト・・・ファイル内容の比較(diffコマンドなど)、アプリの実行、テストの実行
 模擬的なインストールを行う
 配布ファイルの確認作業が終わったら、ブランチディレクトリ内の現在のコンテンツにタグをつける。これでいつでもこの時点までタイムマシンで戻ることができる。
 リリースの出荷
 
これまでの内容を自動化する。変化するのはバージョン番号だけなので、リリース手順を2つのスクリプトで自動化する。
1本流ディレクトリにある内容のテスト
2 リリースブランチの作成
3 リリースブランチのチェックアウト
4 リリースブランチのビルドとテスト
ここまでは新しいリリースブランチを作成するたびに実行すること。
5 リリース用配布ファイルの作成
6 配布ファウルの内容のテスト
7 リリースのタグ付
8 QAチームへの配布ファイウrの出荷
5-8はリリースブランチが作成されたら行う

スケジューラに登録してデイリー配布を生成する方法。毎日最新のコードが実行できる。


第5章 インストールと配置
 ソフトウェアをユーザの手に届ける皇帝の自動化

 エンドユーザの望みはただ一つ、配布ファイルの内容を使うこと。だからインストールはできるだけ容易であるべき、ZIPなら展開するだけ。

 理想的なのはうまくインストールできないユーザから連絡がこないこと。
 同じインストールの問題が何度も発生する場合は対策が必要。トラブルシューティング用チェックリストから一歩進んで診断テストでの自動化を行う。

 JUnitを使用してインストールにいつどのような理由で問題が生じたか診断する方法解説。
 この診断テストは必要に応じてユーザに配布する追加のZIPファイルにするとよい
 ユーザがすべての診断テストを1度に実行できるようにJUnitのテストスイートにすべてのテストケースを格納する。

インストールイメージの拡張
 ZIPは展開するだけなので、追加のインストールステップは実行できない。
 インストーラで手順を自動化する方法解説・・・NS.ISの例を解説

ホストされるアプリケーションの配置
 サーバへの配置が必要なJavaアプリケーションのインストール自動化
 配置モジュールの作成方法解説。サーバの動的配置をつかうとかAntのタスクを使って自作する方法など。

インストールされたアプリケーションの自動更新
 定期的に更新をチェックする自動更新プログラムがあるのが理想。

 自動更新プログラムの作成
 1 敵的またはイベントに基づいて、更新を開始する。
 2 プログラムから既知のWebサイトにアクセスして、現在のバージョン番号を取得する。
 3 現在のバージョンがインストールされているバージョンよりも新しい場合は、現在のバージョンを自動的にダウンロードする。
 4 新しいバージョンが利用でき、インストールすべきであることを知らせるダイアログボッスを表示する(オプション)
 5 最新のバージョンをインストールする

 Java Web Startを使った自動更新プログラムの作成例

第6章 監視
 トリガによる自動化を使って、ビルドの監視と実行中のプログラムの監視を行う。

定期ビルドの監視
 携帯電話へのビルドの結果の送信・・・CruiseControlへのemailパブリッシャーの追加方法
 RSSシグナルのブロードキャスト・・・CruiseControlへのXSLTパブリッシャーの追加方法

視覚デバイスからのフィードバッグ
 ビルドモニタやビルドの成功を示す泡の例を表示。一目でビルドの成功と失敗がわかる

Javaプロセスの監視
 配置したソフトウェアの監視を自動化する方法。Unixのシェルスクリプトでjavaプロセスが実行されているか監視して異常があったらemailに知らせる例。もちろん再起動もついている。

Webアプリケーションのチェック
 curlやwgetという強力なHTMLスクレイパーがあるのでそれを使った定期的チェック方法を解説。

ログファイルの監視
 javaアプリが出力するログファイルを監視するRubyプログラムの例。FATALを含むメッセージを監視。

log4jでの監視
 アプリケーションがlog4jの」ような設定可能なログ出力プログラムを使用すると、外部の設定ファイルを変更するだけで、アプリケーション内部で発生するイベントログを捉えることができる。
 log4j動作方法と監視用アベンダの組み込み法帆う

RSSによる監視メカニズムの構築
 重要なイベントであるが、発生しても即座に通知を受ける必要がない場合など、log4jでRSS経由で通知が送信される方法を解説

デバッグコマンドによる健全性監視
 リモートアプリケーションが不具合の兆候を示しているとき、その原因をしらべるデバッグコマンドを作る。
 出力に
 ・JVMの統計
 ・ログに最後に記録されたエラーメッセージ
 ・システムの同時利用ユーザ数
 ・開いているデータベース接続数とコネクションプールの大きさ
 ・主なWebページの平均応答時間
 これをWebインターフェースで実現する方法解説。

クラッシュレポートの作成
 スクリプトまたはバッチファイルで以下のような情報を収集
 ・ログファイル内の最後からX行のメッセージ
 ・アプリケーションのバージョン
 ・OSとJVMのバージョン
 ・主な環境変数とシステムプロパティ
 ・動作中の他プロセスの名称

繰り返し可能なビルドをまとめて、自動的に実行されるように整理
インストーラを作成し、アプリケーションの配置が行える
クライアントの環境にインストールされたソフトのテストを可能にする
世界中のどこにいても問題が発生したときには通知されるような仕組みを用意する。
そうして人間は興味深いコードの開発に遷延する。


付録A リソース・・・Antなどの場所 参考文献

付録B プロジェクトの自動化のまとめ





nice!(0)  コメント(0)  トラックバック(0) 
共通テーマ:資格・学び
前の3件 | 次の3件 プログラミング ブログトップ