日々の破片

_ XmlSerialization

なんか、馬鹿くさくなってきた。 単なる値型でどう考えてもシリアライズ/デシリアライズ可能なのにも拘らず、Web参照による自動生成だとプロパティのみが生きるし（自動生成されたプロクシに手を入れるとその後が厄介だし）、結局、値型への変換処理をクライアントとサーバでそれぞれ別個実装しなければならなくなった。 開き直って

[WebMethod]
public void Foo(String xmlSerialized)
{
  StringReader stm = new StringReader(xmlSerialized);
  XmlSerializer ser = new XmlSerializer(typeof(Bar));
  Bar b = ser.Deserialize(stm);
  ...

としてしまえば簡単なんだが。っていうか、バイナリシリアライズ＋Base64とか、直接バイナリのPOSTとか、手段はたくさんあるんだが、自動生成縛りなんでそうはできない。結局、マニュアルならソース共有で構わないんだが、自動生成だと1度WSDLが噛むから別扱いになってしまう。

_ WebMethodで値オブジェクト

[Serializable]
[XmlRoot]        // ← これがミソ
public class Bar {
 ....
}
public class Service
{
   [WebMethod]
   public void ComeOn(Bar b)
   {
      ...

_ 今日買った本

エンタープライズアプリケーションアーキテクチャ パターン。

紀伊国屋で約10000円だが、アマゾンなら吹き矢の嵐をかわしながら44$だ。これなら船で山を越えても大丈夫。しかし、紀伊国屋で買ったわけで5000円近いお布施を国内産業に払ったってことになる。

しかし、読み始めて思ったが、別に読む必要は無いんだな、これが。しかし、書かれた知識はともかくとして、それを記述する能力ってものが差として厳然とあるようだ。

特に序文に書かれている、narrativeとreferenceという切り口は重要だ。もちろん、こういうスタイルの本はよくあると言えるんだが（たとえばGoFデザインパターン）、

人間の脳の働きというか思考をソフトウェアで記述する試みがAIならば、ビジネスをソフトウェアで記述する（ためのモデル化の段階の）試みがエンタープライズアーキテクチャで、多分、AIと同じように、バベルの塔だろう。

にもかかわらず、非常にエキサイティングなのは、それがまさにバベルの塔だからに違いない、と思う。

ただし、この本は名前のとおり、エンタープライズアーキテクチャについての本じゃなくて、エンタープライズアプリケーションのアーキテクチャパターンの本だけど。

もちろん、バベルの塔を作るためには、権力、資材調達、労働力調達、資金調達、労働力配分、設計、資材選択などなどなどなどなどなどなど、もろもろもろもろもろもろの活動があり、だから、神を怒らせたわけだろうが、要するに人間様が人間様であるために1番重要なもののひとつがそこに収斂しているわけだ。収斂するっていうのは、集約するってのとは違う。

_ ロボットの国、日本

かも。紀伊国屋で思った。日本がロボットの国じゃなければ、ロボットスモーなんてタイトルは付かないだろう。やりたいこと、やらなければならないこと、がはるかに少なければ、この本読みながら、スモートリを作りたいなぁ。分身！（快楽篇の変身！のように）

というか、これ、高専対抗とかNHKで良くやってる（わけないが、たまに見るTVがそんなのだから、「よく」とか形容しちゃうんだろうな）あれの公式ガイドなんだろか？

MINDSTORM本も目立つ。あとなんかおもしろそうだったのが、忘れちゃった。

_ 上の馬鹿臭いやつ

微妙に意味は違うんだが、ファウラーの(ここは署名が無いからファウラー自身のパートだろう）レコードセットパターンを俺定義したもの（と最初に微妙に違うと書いていながら付け加えておく）がやっぱり正解だろう。

最初にクラスから値オブジェクトを導出してXMLシリアライゼーションの対象とするアプローチより、XSDでスキーマを決定して単純にレコードセット化するほうが、VS.NETでの開発は遥かに高効率だ。

どうも、頭の中でモデル化するとき、操作を中心に考えてしまうからクラスで考えてしまうんだが、その方法はうまくいかない。あとから分散を意識した時点で無理矢理になってしまう。つまんねぇな。

逆に、データオリエンテッドにスキーマを決めていくと、ぴったり嵌る。

あーそうか、だから、MSがDOAを持ち出すのは、必ずしもユースケースドリブンに対抗するためではなく、VS.NETを中心にした開発戦略に合致するからなのか。

スキーマからモデルを作っていくと、操作はどうしても外付けになるというか、操作を考えてもしょうがない（実現手段が無いから）。

重要なのは、OOかどうか、DOAかどうか、分散か、集中か、ではない。まったくない。

おもしろいかどうかだ。

が、それはおいておくと、いかに正しいかだ。

が、それもおいておいて、（なんか、重要なことは、すべて、ビジネス的に意味がなかったり、不可能だったりする）、開発効率と運用効率と、実現された処理の現実性（すべて合わせてROIってことになる）だ。

_ Ruby発見

P.XX（序文の20ページ目）

My apologies to those who like Smalltalk, Delphi, Visual Basic, Perl, Python, Ruby, COBOL, or any other language. I know you think you know a better language than Java or C#. All I can say is I do, too!

読者層を考えた順序のようだな。 Smalltalkが1番なのは出自から当然だろう。どうも、エンプラ開発は、噂と違ってアメリカでもDelphiは強いんだろう。VBも当然だ。そしてスクリプト三国志がきて、COBOL。でも、JavaとC#じゃなきゃ現実じゃないよね。 って言うか、このおっさんは、独特の文体/言及を持つところが好きだな。

_ 虫じゃないのよ

IMG SRCがCGIと言えば、Webバグだが、こういうこともまあ、あるかも知れないなぁ。

_ 別の見方

Smalltalk, Delphi, Visual Basic, Perl, Python, Ruby, COBOLプログラマーなら、JavaやC#のコードくらい読めるだろうとか。VBerとCOBOLerには無理か。

_ ちょっと感心

くそだと思ったWSDLへの値オブジェクトの取り込みだが、

[XmlInclude(typeof(Foox))] // ←ミソ
class Foo {
  virtual public string Seven
  {
    get { return null; }
    set { throw new NotSupportedOperation("are you sure?"); }
  }
}
class Foox : Foo {
  string[] seven;
  override public string Seven
  {
    get { return seven; }
    get { sevent = value; }
  }
}

では、ちゃんとFooのプロクシにstring[] のインスタンスが生成される。

_ わお

インターフェイスのスタブの自動生成がサポートされている。これ、2003じゃないVS.NETにもあったかな？

ないんじゃないかな。: Ixxxxと書いた瞬間に「タブを押せばスタブを生成する」と薄いグレーでヒントが表示されたけど、これは初めて見た気がする。

これは、無茶苦茶、楽だ。（他のインターフェイス継承を持つ言語の統合環境は知らんけど）

_ 忘れてたこと

Nunit試そうと思って忘れてた。