cles::blog

リポジトリの可視化ツールをちょっと調べていたら、Gourceというちょっと面白いツールを見つけたのでメモ。

gource - Project Hosting on Google Code

Gource is a software version control visualization tool.

リポジトリの変化を独特のうにゅうにゅ動くアニメーションで可視化してくれます。リポジトリがCVSの場合にはcvs-exp.plを使ってログの変換を行う必要があります。試しに自分のNucleusのCVSリポジトリの可視化してみました。綺麗で面白いのですが、このアニメーションから何か（ソフトウェアエンジニアリング的な知見という意味で）読み取れるかと言われると、自分には難しそうな感じですが、今後の発展に期待したいと思います。

先日、メトリクスのまとめをちょっとやったので、今日はツールを使って実際にメトリクスを取ってみます。

手っ取り早く自分のプロジェクトに適用するのであれば、Eclipse Metrics Pluginを使ったり、Maven2のプラグイン経由でJDependやJavaNCSSを使うのが楽なのですが、今回はSLoCをメソッド単位で取得する必要があり、しかも大量のプロジェクトをコマンドラインで一括処理したかったのでCCCC (C and C++ Code Counter )というツールを使ってみました。

C and C Code Counter | Get C and C++ Code Counter at SourceForge.net

CCCC is a tool which analyzes C++ and Java files and generates a report on various metrics of the code. Metrics supported include lines of code, McCabe's complexity and metrics proposed by Chidamber&Kemerer and Henry&Kafura.

インストーラーにそってインストールした後、ソースコードのあるディレクトリにcdして、マニュアルにあるとおり、下記のコマンドを打ち込むと解析が開始されます。

解析が完了すると、.ccccというフォルダに結果が格納されます。今回のサンプルには愛用しているサーブレットコンテナのWinstoneのソースコードを使ってみました。研究用のデータを作るには、XMLで出力された結果をパースして一覧を作る必要がありますね。

ちょっと古い話ですが、How to be a program manager - Joel on Softwareの日本語訳を見つけたのでメモ。開発に携わるエンジニアは原文も含めて一度読んでおいて損はなさそうな感じ。

「program manager」というフレーズは聞き慣れないけれども、良いプロジェクトには必ず存在する、客と開発者と上司の間に挟りながらも、コンセンサスを作り出していく「頼れる人」と考えればわかりやすいかも。挟まれるんでなくて、自分から挟まる人なのがポイント。現場では、こういう人の特性を属人的なものとして片付けてしまいがちだけど、こうやってそういう人の性質を棚卸しして、整理している文章を読むと、ソフトウェア工学の基本に立ち返ることができる感じがします。

【翻訳】How to be a program manager - Joel on Software - GoTheDistance

大抵の場合、プログラムマネジャーになることはまさに学習だ。技術、人間、政治的な組織においてどうすれば役に立てるのかを学ぶことだ。優れたプログラムマネジャーは政治家としての手腕を技術を持ってして設計するというエンジニアのやり方に結び付けてコンセンサスを構築し、一緒になって人々を導いていくものだ。

自分にもいつかこういう仕事ができるようになると良いんですけどね。ちなみに日本語訳をしたgothedistanceさんの最新のエントリを見ると、この方は僕と同い年。こうやって人に翻訳しましたよって出せるのはうらやましい限りだなぁ。

最近ちょっとメトリクスまわりでゴソゴソやっているので、オブジェクト指向のソースコードを解析する際によく使われる３つのメトリクスについてちょっとまとめてみました。

・McCabeのサイクロマチック数(Cyclomatic Complexity)
・Martinのメトリクス(OO Design Quality Metrics)
・ChidamberとKemererのメトリクス(CK Metrics)

これらは輪講なんかで何度も聞いているものの、いざ自分で使おうと思うと意外と定義を覚えていないものですね。

IEの脆弱性（というか、ATLの脆弱性）が一文字のミスで引き起こされているという話。

プログラミングを知らない人には、驚愕の事実なのかもしれませんが、プログラムの欠陥なんて元をたどればほとんどがこういうものです。この記事は欠陥の大きさと、その欠陥が結果としてどのような影響を及ぼすかと言う事には何ら関係性がないということを良く表していると思います。幸いにもこういう致命傷には至らなかったものの、小さなミス自体は自分もよく犯しているので、このミスをしたエンジニアのいたたまれない気持ちはわかるような気がします。

「IE」に対する最新攻撃の原因、たった1つのタイプミス--MSが認める:ニュース - CNET Japan

Howard氏が読者に提示したコードは、以下の通りだ。

__int64 cbSize;
hr = pStream->Read((void*) &cbSize, sizeof(cbSize), NULL);
BYTE *pbArray;
HRESULT hr = SafeArrayAccessData(psa, reinterpret_cast(&pbArray));
hr = pStream->Read((void*)&pbArray, (ULONG)cbSize, NULL);

そして、Howard氏は読者に次のように出題した。「もう1つ手がかりをだそう。タイプミスは1文字だ。降参だろうか。では、最後の1行を見てもらいたい。最初の引数が間違っている。正しくは、『hr = pStream->Read((void*)pbArray, (ULONG)cbSize, NULL);』だ」（Howard氏）

このような欠陥を自動的に防ぐ、もしくは検出する枠組みを作るのは現在のソフトウェアエンジニアリングの技術では限界があるはずなので、そのような制約を踏まえつつ、現実的にどのように改善してくれるのかというＭＳの今後の取り組みにはとても興味があります。

研究室の有志メンバーを募ってオブジェクトデザインという本の輪講みたいなことをやってるんですが、その中でCollaborateに意外と大人な意味があることが載っていたので驚いてしまいました。

5.3.2: オブジェクトはお互いをどの程度信頼すべきか^*1

Collaborate（コラボレートする）: 1.協力すること。特に一緒に知的な活動において協調すること。2.敵の占領部隊に対するように、腹の中では裏切りながら表向きは協力すること。
---The American Heritage Dictionary

2番目の意味の部分太字にしていますが、実際の本でもこの部分が太字になっています。
英英辞典のThe American Heritage Dictionaryの原文は下記のようになっていました。

Collaboration Definition | Definition of Collaboration at Dictionary.com

col·lab·o·rate
1. To work together, especially in a joint intellectual effort.
2. To cooperate treasonably, as with an enemy occupation force in one's country.

仕事のコラボレーションって2番目の意味の場合が多いのが現実でしょう。この解説が、オブジェクトはお互いをどの程度信頼すべきかという部分に書かれているあたり、オブジェクト指向って哲学が入ってるなと思います。

• ^*1: レベッカ・ワーフスブラック, アラン・マクキーン, "オブジェクトデザイン," 翔泳社, p.179, 2007

オブジェクト指向におけるロジックの実現方法については、PofEAAでFowlerがテーブルごとにクラスを作成してロジックを実装するテーブルモジュール、ロジックのプロシージャ（手続き）ごとにモジュールを作成するトランザクションスクリプト、振る舞いとデータをカプセル化したモジュールを作り、オブジェクトの関連しあうことでロジックを実現するドメインモデルという3つに分類されています。

この中でどれがいいかというのは賛否があると思いますが、最近のアプリ開発では普通にになりつつあるDependency Injectionとの相性を考えると、データとロジックが分離されているトランザクションスクリプトが優勢のように思えます。というか、自分が実装したものは一部を除いてほとんどがトランザクションスクリプトなので、そう感じているだけかもしれませんが、その実装で他人からおかしいという指摘を受けた事がないというのも事実です。

ただ、この中でもっともオブジェクト指向らしい実現方法はと聞かれれば迷わずドメインモデルと答えますが、誰もがいちばん困っているのがこのドメインモデルの作り方だろうと思いますし、僕のように「いつかはドメインモデル」みたいな人も少なくないだろうと思います。

InfoQ: Domain Driven Design（ドメイン駆動設計） Quickly 日本語版

巨大なソフトウェアプロジェクトが直面する最も複雑な局面は、実装ではなく、ソフトウェアが提供する実世界のドメインです。ドメイン駆動設計(Domain Driven Design)は、非常に複雑なドメインを取り扱うためのヴィジョンとアプローチです。このヴィジョンとアプローチは、ドメイン自身をプロジェクトの主な焦点とし、ドメインの深い理解を反映したソフトウェアモデルを維持します。 このビジョンは、Eric Evans氏の本「Domain Driven Design」によって世界に広められました。

Domain Driven Designは僕も原著を持っていて、完全に読みこなせているわけではありませんが、ドメインモデルの勉強をするには良い本だと思います。ただ、日本語の資料が意外と少なく、まともに読めるのはオージス総研のDomain-Driven Designのエッセンスくらいしか知らなかったのですが、上記のDomain Driven Design Quickly 日本語版は本の全体を掴む上ではかなり良さそうな感じです。このPDFはダウンロードには会員登録が必要ですが、無料なので、原著を買う前に目を通しておいて損はないと思います。

邦訳版がないので原著を取り寄せたWorking Effectively With Legacy Codeですが、来月邦訳版が出版されるみたいです。

完全にClean Codeの時と同じ失態をかましてしまいました。気合いを入れて原著を読もうと思っていたのですが、完全にやる気が萎えました。とりあえずこの邦訳版を読んでから原著のポイントを確認するという作戦に変更しようと思います。

面白そうだったので、原著を取り寄せたら、最近邦訳が出版されたことに気づきました。僕が英語が苦手な事をよく知っている教授には「原著には原著のニュアンスがあるから、英語の勉強だと思って読んでみたら」と笑われてしまいましたけど。

とりあえず邦訳版も買って読み進めたいと思います。

一緒に食事をしたBさんが、「今、これ読んでるんだけど面白いよ」と教えてくれた本。

この本のLegacy Codeというのは、テストケースのない汚いコードのことらしい。つまり、Legacy Codeは大概汚いので、拡張にあたってリファクタリングしなければならない場合が多いですが、テストケースがないと本当のリファクタリングはできないわけです。一方、Legacy Codeにテストケースを書こうとすると、構造の拙さからリファクタリングをしないとテストを書く事が難しい。このようなジレンマというかデッドロック状態にどのように対処していくかと言うことを語った本みたいです。

こういうときにネイティブであるということが本当に羨ましいです。情報格差ってこういうところから始まっていますね。