翻訳: よい作曲家／システム構成者はきわめて稀だ
このところある洋書の翻訳に掛かりきりで、こちらにほとんど記事を書いていませんでした。ようやく翻訳も終わったので、また少しずつ記事を書いていこうと思います。翻訳書の方は、年内または年始に出版の予定なので、出版が近づいたらまたお知らせします。
といいつつまた翻訳ネタですが、gregor-ramblings-jaプロジェクトに翻訳記事を1本追加しました。今回は「Good Composers are Few and Far in Between（よい作曲家／システム構成者はきわめて稀だ）」です。
非同期メッセージングなどを使って非常に疎結合なシステムを作ろうとすると、コンポーネント（SOA的にはサービス）をどう組み合わせていくか、という構成（composition）の問題が重要になってきます。Gregorは、ここにOOPなどとは異なるプログラミングモデルに支配された「構成層」という新たな層が導入される、と言います。
そして「構成層」をテストするのが統合テストの役割なので、疎結合システムでは統合テストの役割が非常に重要になってくるのです。新たな「構成層」をテストするには従来的な統合テストではダメで、新しいアプローチが必要になります。この記事では、その新しいアプローチを検討しています。
つづきは、こちら。
といいつつまた翻訳ネタですが、gregor-ramblings-jaプロジェクトに翻訳記事を1本追加しました。今回は「Good Composers are Few and Far in Between（よい作曲家／システム構成者はきわめて稀だ）」です。
非同期メッセージングなどを使って非常に疎結合なシステムを作ろうとすると、コンポーネント（SOA的にはサービス）をどう組み合わせていくか、という構成（composition）の問題が重要になってきます。Gregorは、ここにOOPなどとは異なるプログラミングモデルに支配された「構成層」という新たな層が導入される、と言います。
そして「構成層」をテストするのが統合テストの役割なので、疎結合システムでは統合テストの役割が非常に重要になってくるのです。新たな「構成層」をテストするには従来的な統合テストではダメで、新しいアプローチが必要になります。この記事では、その新しいアプローチを検討しています。
最近は、結合性についての議論が活発だ。実は、この話題については言いたいことが山ほどあるので、大部分は別のポストに取っておこうと思う。今回は次のことだけに留めておこう。私の考えでは、結合性とはシステム間の依存性を測る指標だ。David Orchardは、究極の疎結合ソリューションを次のようなナイスな言葉で定義している。「2つのシステムを疎結合にするにはどうすればいいか？ 接続しないことだ！」 私が思うに、結合性についてこんなにも議論が白熱する理由の1つは、もともと接続を必ずしも想定していなかったシステム同士を接続することが一般に多い、という現実があるからだ。自然と、議論はどこまでの依存を、したがってどこまでの結合を、システム間に導入すべきかということになる。
つづきは、こちら。
Neat or embarrassing
大統領の家族になるということ。
Michelle told me once, only half joking, seeing your dad's picture in the paper may be kind of neat the first time it happens, but when it happens all the time it's probably kind of embarrassing.
ミシェルはあるとき私に言った。半分冗談だが半分は本心で。お父さんの写真を新聞で見るのは、それが初めてのときには気分がいいかもしれないが、いつも見るようになると居心地悪く感じるだろう、と。
—Barack Obama, The Audacity of Hope
opencsv
アプリケーション開発で、古典的だが必ずといっていいほど登場するのが、CSV（Comma Separated Values）ファイルの読み書きだ。単にデータ列をカンマ（,）で区切っただけの単純なデータ形式なのだが、RFCなどの正式な仕様がないせいか、CSVを扱う標準的なライブラリというものが存在しない（少なくともJavaでは）。
（8/4追記: とおりすがりさんからコメント欄でご指摘いただいたが、CSVのRFCはあるそうだ。→ http://www.kasai.fm/wiki/rfc4180jp ）
そのため、CSVを扱う要件が出てくるたびに独自のライブラリを作るという、車輪の再発明が至るところで行なわれている。しかし、このCSVは一見単純なのだが、データの中にカンマが入っている場合とか、データをダブルクォート（"）で囲ってきた場合とか、データの中にダブルクォートがあってそれがエスケープされている場合とか、細かいところを厳密に考えだすと結構面倒くさい。
再利用可能なCSVライブラリはいつ出てくるのだろうかとずっと思っていたのだが、先日opencsvというライブラリをSource Forgeで見つけた。
http://opencsv.sourceforge.net/
CSVの読み書きに対応していて、まず読み込む場合は以下の通り。
書き出す場合は以下の通り。
使ってみた限り、ダブルクォートによるエスケープ処理にもきちんと対応しており、性能は十分実用に耐えるものになっていそうだ。
Mavenを使っている方は、pom.xmlに以下のように書くだけですぐ導入できる。
これでついに、アプリケーション開発でCSVライブラリを書かなくてもいい日が来るのだろうか。
（8/4追記: とおりすがりさんからコメント欄でご指摘いただいたが、CSVのRFCはあるそうだ。→ http://www.kasai.fm/wiki/rfc4180jp ）
そのため、CSVを扱う要件が出てくるたびに独自のライブラリを作るという、車輪の再発明が至るところで行なわれている。しかし、このCSVは一見単純なのだが、データの中にカンマが入っている場合とか、データをダブルクォート（"）で囲ってきた場合とか、データの中にダブルクォートがあってそれがエスケープされている場合とか、細かいところを厳密に考えだすと結構面倒くさい。
再利用可能なCSVライブラリはいつ出てくるのだろうかとずっと思っていたのだが、先日opencsvというライブラリをSource Forgeで見つけた。
http://opencsv.sourceforge.net/
CSVの読み書きに対応していて、まず読み込む場合は以下の通り。
CSVReader reader = new CSVReader(new FileReader("input.csv"));
try {
String[] line;
while ((line = reader.readNext()) != null) {
// 読み込んだCSVデータで何かをする
}
} finally {
reader.close();
}書き出す場合は以下の通り。
CSVWriter writer = new CSVWriter(new FileWriter("output.csv"));
try {
String[] data = ... // 書き出すCSVデータ
writer.writeNext(data);
} finally {
writer.close();
}使ってみた限り、ダブルクォートによるエスケープ処理にもきちんと対応しており、性能は十分実用に耐えるものになっていそうだ。
Mavenを使っている方は、pom.xmlに以下のように書くだけですぐ導入できる。
[pom.xml]
<dependencies>
<dependency>
<groupId>net.sf.opencsv</groupId>
<artifactId>opencsv</artifactId>
<version>1.8</version>
</dependency>
</dependencies>
これでついに、アプリケーション開発でCSVライブラリを書かなくてもいい日が来るのだろうか。
翻訳: 同期的非対称性と非同期的対称性
gregors-ramblings-jaプロジェクトにeverpeace君が参加してくれました。彼は、「The Core Protocol」の翻訳などもやっている人です。さっそく、記事「"同期的な非対称とか非同期的な対称"って言ってごらん（Can You Say "Synchronous Asymmetry or Asynchronous Symmetry"?）」を翻訳してくれました。
SOAの世界では、非同期のメッセージングが非常に重要な役割を果たします。オブジェクト指向においても古くから「オブジェクト同士のメッセージのやり取り」こそが本質とされてきたので、SOAにおける「メッセージング」とオブジェクト指向の「メッセージのやり取り」の違いが見出せず、混乱してしまうことがあります。
私は、オブジェクト指向とSOAとはやはり本質的に異なるパラダイムだと思っていますが、そのポイントがこの記事のいう「同期的非対称性（Synchronous Asymmetry）」と「非同期的対称性（Asynchronous Symmetry）」にあるのではないかと思います。Hohpe氏がたびたび指摘しているように、SOAのアーキテクチャスタイルは「パイプ＆フィルタ」であって、同期的非対称性のあるオブジェクト指向のスタイルではないのです。
つづきは、こちら。
SOAの世界では、非同期のメッセージングが非常に重要な役割を果たします。オブジェクト指向においても古くから「オブジェクト同士のメッセージのやり取り」こそが本質とされてきたので、SOAにおける「メッセージング」とオブジェクト指向の「メッセージのやり取り」の違いが見出せず、混乱してしまうことがあります。
私は、オブジェクト指向とSOAとはやはり本質的に異なるパラダイムだと思っていますが、そのポイントがこの記事のいう「同期的非対称性（Synchronous Asymmetry）」と「非同期的対称性（Asynchronous Symmetry）」にあるのではないかと思います。Hohpe氏がたびたび指摘しているように、SOAのアーキテクチャスタイルは「パイプ＆フィルタ」であって、同期的非対称性のあるオブジェクト指向のスタイルではないのです。
呼びだしスタックは、あるメソッド"caller"がある他のメソッド"callee"を呼びだすという点で本質的に非対称だ。この時、calleeが実行中の間はcallerは処理を中断していて、calleeの実行が完了すると処理はcallerに戻る。calleeの処理が完了した直後にcallerの処理が確実に続行する事を保証するのが呼び出しスタックだ。また、このcallerとcalleeの非対称性はUMLの表記法にも表われている。
メソッドの呼びだしは実線で描かれ、戻り値は在る場合と無い場合があるが、もしあるなら点線で描かれる。また、仮想計算機やプロセッサレベルでもpush/popペアやcall/retペアという形で非対称性が表われている。このように、メソッドを呼びだしたり、サブルーチンを呼び出したりする事は、メソッドやサブルーチンから値を戻す事とは本質的に違う事なのだ。
つづきは、こちら。
翻訳: 名前がいったい何だというの？
ずいぶん間隔が空いてしまいましたが、gregor-ramblings-jaプロジェクトで「Gregor's Ramblings」の記事をまた翻訳しました。今回は「What is in a Name?（名前がいったい何だというの？）」です。
JMSなど非同期メッセージングを使ったシステム間統合では、「チャンネル（channel）」という概念が登場します。この記事は、チャンネルにどんな名前を付けるべきか、という議論を展開しています。チャンネルにどんな名前を付けるかが、単なる名前の良し悪しだけでなく、システムのアーキテクチャを「呼出スタック」ベースのスタイルから「EDA（Event Driven Architecture、イベント駆動アーキテクチャ）」へ遷移させるインパクトについて語っています。
EDA、イベントベースのシステムについての秀逸な解説記事になっていますので、興味のある方はぜひ読んでみてください。
つづきは、こちら。
JMSなど非同期メッセージングを使ったシステム間統合では、「チャンネル（channel）」という概念が登場します。この記事は、チャンネルにどんな名前を付けるべきか、という議論を展開しています。チャンネルにどんな名前を付けるかが、単なる名前の良し悪しだけでなく、システムのアーキテクチャを「呼出スタック」ベースのスタイルから「EDA（Event Driven Architecture、イベント駆動アーキテクチャ）」へ遷移させるインパクトについて語っています。
EDA、イベントベースのシステムについての秀逸な解説記事になっていますので、興味のある方はぜひ読んでみてください。
メッセージング・ベースの相互作用では、2つの新しい要素が導入される。チャンネルとメッセージだ。この2つの新要素そのものは単純なのだが、選択肢の幅が広がるので、新しい決断を求められる。一見簡単そうだが注意を要するのは、「チャンネルにどんな名前を付けるか？」という問題だ。メソッドが別のメソッドを直接呼ぶだけだった時代には、媒介する要素が間に何もなかったので、何も決めなくてよかった。今や、われわれは新しいレベルの間接性を手にしてしまったので、それに適切な名前を付けなければならないのだ。さて選択、選択・・・
つづきは、こちら。