開発関連

.NET Framework 4のメール送信機能

がんふぃーるど(ganfield@wankuma.com) — Tue, 21 Sep 2010 22:35:00 GMT

一時期、DocomoやauでRCFに準拠していないメールアドレスが送信できないといった問題がありましたが、.NET Framework 4のSystem.Net.Mailでは送信できるようになっているんですね。

MSDNのSystem.Net.Mail.MailAddressクラスの説明でも、「ユーザー名内の連続ドットと末尾のドット」が使用可能なメールアドレスの形式として明記されています。
http://msdn.microsoft.com/ja-jp/library/system.net.mail.mailaddress.aspx

実際にRadishというSMTP/POP3サーバを立てて試してみましたが、.NET Framework 4ではうまくいきました。（当然.NET Framework 2.0ではダメでした。）

RCFに準拠していないメールアドレスを新たに登録することは既に禁止されていますが、依然そのようなメールアドレスが残っている状態なので、日本のSIerとしては非常に助かります。
http://www.nttdocomo.co.jp/info/spam_mail/measure/change_add/
http://www.au.kddi.com/service/email/support/meiwaku/email_boshi/mail_address.html

ちなみに、SmtpClientにも変更があり、SmtpClientクラスが新たにIDisposableを実装しています。MSDNの説明を見るとFinalizeメソッドが無いのでしっかりとDisposeを呼び出してアンマネージリソースを解放する必要があるそうな。
http://msdn.microsoft.com/ja-jp/library/system.net.mail.smtpclient.aspx

Team Foundation Serverの作業項目の高さを調整

がんふぃーるど(ganfield@wankuma.com) — Fri, 31 Jul 2009 06:43:00 GMT

作業項目のコントロールの高さを指定する方法です。独自の作業項目を作成していたら、TFS 2005とTFS 2008で異なっていた、というかTFS 2005の場合はドキュメントに記載されていない、のでメモ書き程度に。

TFS 2008の場合

括弧あり

TFS 2005の場合

括弧なし

MinimumSizeがMSDNのマニュアルに記載されたのはTFS 2008からですが、TFS 2005でも使用することはできます。ただし、記法に若干の違いが見られる通り、使用は自己責任で。また、TFS 2005⇒TFS 2008移行時にプロセステンプレートをアップロードしてMinimumSize関連でエラーが出たら、疑ってみてください。

参考

Control 要素 (作業項目の種類の定義スキーマ)

Undocumented attributes for controlling the Work Item form layout

CSS Expressionって難しい

がんふぃーるど(ganfield@wankuma.com) — Thu, 23 Apr 2009 08:36:00 GMT

IE8ではすでにサポートされていないCSS Expressionですが、業務では使っています。んでもって、やっぱり難しいですね。思わぬところで無限ループが発生してしまう。

たとえば、次のようなソース

<html>
<head>
<style type="text/css" media="all"> 
.maxheight { 
width:60px;
overflow:auto;
height:expression(document.all('testdiv').clientHeight > 79 ? "80px" : "auto");
} 
</style> 
</head>
<body>
<div id="testdiv" class="maxheight">
<div width="100%">
aaaaa<br/>
bbbbb<br/>
ccccc<br/>
ddddd<br/>
eeeee<br/>
fffff
</div>
</div>
</body>
</html>

BR>

高さを80pxに制限するmax-heightのCSS Expression版ですが、このままであれば全然問題ありません。ただし、aaaaaやeeeeeの文字列を増やすと、横スクロールバーが出現して無限ループ突入。

実際に発生したケースとしては、横幅をwidthでガチガチに固め、さらにword-breakを雨あられと定義し、縦スクロールバーが出現しても大丈夫なように右側に十数pxほど余裕を持たせてありました。

こちらも通常の場合は問題なく動くのですが、Windowsの「画面のプロパティ」からデザインタブのフォントサイズを特大にすると、縦スクロールバーの横幅が広がり、十数pxの余裕を食いつぶして横スクロールバーが出現。当然のごとく無限ループ突入です。

behaviorを使用して挙動を制限しなかったのは間違いかもしれませんが、これはちょっと気付かない…

しょぼーん。。。

MVC - モデルビューコントローラ

がんふぃーるど(ganfield@wankuma.com) — Mon, 16 Jul 2007 12:21:00 GMT

仕事でMVCやプレゼンテーション部分のアーキパターンについての話題が挙がったので、真面目に調べてみました。ということでノート代わりにここを使用します。間違っていたら指摘して下さいね。

1. 発祥

1978年にSmalltalkを開発していたXerox社の研究所で生まれる。その後、MVCの実装を記述した論文「Applications Programming in Smalltalk-80(TM):How to use Model-View-Controller」が発表されるとその有用性から多方面へと広がる。

2. 構造

UIの構造やビジネスロジック（データ含む）などの利害関係の異なるそれぞれの要素に対し、どのようにすればそれらを奇麗に分離することができるのか？という問題に対する一つの解として登場したのがMVCです。MVCではビジネスロジックやUI、ユーザからの入力の三つ(つまり、処理/出力/入力)をそれぞれModel/View/Controllerの3つの要素に分離し、役割を設けます。

Model	ドメイン（ドメインレイヤーではない）についての情報や捜査を担当する要素。主にビジネスロジックを実装します。
View	ユーザへの情報の表示を担当する要素（UI）。Modelのデータを出力します。
Controller	ユーザからのアクションを受け、ModelやViewの操作を担当する要素。

※　実線は直接的な関連性、点線は間接的な関連性を示す。

3. 分離と依存性

MVCの最も重要な点として、Presentation(ViewとController)とModelの分離が挙げられます。ModelをPresentationから独立させ、更にPresentationに依存させないことにより次のメリットが得られます。

Modelにおける処理が簡素化される。
Model単体でテストを行うことが可能である。非UI要素なので、単体テストも比較的容易に可能である。
Presentationの修正をModelをいじらずに行うことが可能となる。

尚、Modelに関しては「Passive Model」と呼ばれるパターンと「Active Model」と呼ばれる二つのパターンが存在します。Passive ModelはModelがControllerによって排他的に使用される場合は使用することができます。例えば、Webアプリケーションなどは基本Modelのデータは顧客単位で保持している場合が多く、この場合ModelはControllerより（実質的に）排他的に利用されると考えてよい。とうぜんModelを共有する可能性が出てくる場合もあるが、楽観ロックや悲観ロック等で同時実行制御を行うことで問題を回避することができる。

一方、複数のViewからModelを参照し、そのどれかのControllerによりModelが更新され、その更新を各Viewに反映する必要がある場合Passive Modelを使用することはできません。Modelの変更をController抜きにViewへ反映する必要がある場合、「Active Model」を使用することになります。Active Modelでは、Modelの変更をViewに反映する必要があることから、Modelに依存しているViewを管理するどこかで必要があります。Model要素にView要素への直接的な依存性を持たせてしまうと、Model View Controllerと分離させた意味が無くなってしまうので、依存性を管理するコレクションを利用したり、Observerパターンを利用することによりViewとModelの直接的な依存性を回避する必要があります。

（ちなみに、この辺でよくある勘違いとして、PresentationがModelに依存しないと思ってしまう人がいます。これは大きな間違いで、PresentationとModelは分離しても、PresentationからModelへの依存性は必ず発生します。重要なのはModelからPresentationへの依存性を無くすことです。というか、依存性無しじゃプログラム作れないよっ）

もう一つViewとControllerの分離もありますが、こちらはPresentationとModelの分離ほど重要視されていません。これはViewとControllerを明確に分離すること自体難しい場合が多いからです。（ただWebアプリケーションなどはそうも言ってられないみたいですが…）

4. MVCの実装と派生パターン

MVCの実装方法としてはPage ControllerやFront Controllerパターン、MVCからの派生パターンとしてMVP(Model View Presenter )があります。が、まだしっかりと調べきっていないので、また次の機会に説明します(；´Д｀)

参考文献

[1] Model-view-controller wiki

[2] MVC - XEROX PARC 1978-79

[3] Applications Programming in Smalltalk-80(TM) : How to use Model-View-Controller

[4] モデルビューコントローラ MSDN

[5] Martin Fowler, エンタープライズアーキテクチャパターン, ISBN4-7981-0553-8

[6] GoF, デザインパターン, ISBN4-7973-1112-6

# 書き始めたころに大きな地震がありました。またもや新潟らしいです。北陸地方の人大丈夫ですかね…

最近読んだ一冊『システム基盤の構築ノウハウ』

がんふぃーるど(ganfield@wankuma.com) — Sat, 27 Jan 2007 11:46:00 GMT

『システム基盤の構築ノウハウ』

アプリケーションというよりもインフラ寄りの本です。対象は中～大規模プロジェクトっぽいですが、基本的な考え方は小規模にも当てはまります。

章立は

システム基盤とは（概要）
OLTPシステム（クラサバ）
WEBシステム
バッチシステム
バックアップシステム
統合運用管理

となっています。ボリュームは300頁弱。1章辺り1～2時間ぐらいで読めました。

内容としては、あまり深く掘り下げるようなことはせず、要所要所を抑えるにとどめていまが、システム全体を見渡せる数少ない本だと思います。~~左右の余白が多く、字も大きくて~~サクサク読み進むので、結構勉強してるなって気にもなれます。特に最後の三章はアプリケーション開発側としてはメインではないので疎かになりがちですので、読んでおくといいと思います。知っておけば、ほにゃららを記述したドキュメントが足りなーいなんてドジを踏むことが少なくなるかもしれません。

コードが汚い理由？

がんふぃーるど(ganfield@wankuma.com) — Wed, 17 Jan 2007 01:24:00 GMT

過去に自分の書いた設計書やコードって破いて捨てたくなるときってありませんか？

私は大いにあります。

多分他の皆さんも幾度と無く経験していることだろうと思います。

そんな私たちに対してか、@ITでキミのコードが汚い理由という記事がありました。

内容としては、リファクタリングやAgile系の本に書かれていることと大差無いのですが、ここで紹介したいと思います。

まず、題名からなんとなく分かってしまうのですが--最終的にはコードを綺麗に書く為にはどうすればいいかというのを説明する為に--コードが汚い理由（問題点と背景）が書かれています。

まず、汚い理由として三点

時間のプレッシャー
勉強不足
熱意（周囲のコードに対する熱意のこと）

（非常にありふれた三点（；´Д`A ```。）

次に、コードを汚くしないための対策が三点

クリーンなコードを書くことを自分のプロセスに取り入れる
クリーンなコードの書き方を教える
クリーンなコードを評価する（周囲に評価されるようにする）

　記事の最初の方に、著者が汚いとしているコードAと綺麗だとしているコードBがある。見た目的に良いコードはBであるが、現在問題として現場で受け入れられるコードはAであると思う。何故か？それはITの現場にはピンからキリまでいるからである。

　サッカーを例に取ってみると、バルセロナや少し前のレアルのサッカーは非常に素晴らしい。ただ、同じことを日本代表にやらせようとしたらどうなるだろうか？JFLの選手などに至ってはどんなことになるであろうか？当然不可能である。個々の能力に差があるからである。高い戦術には高い個々の能力が必要とされるのである。正確なトラップ、正確なボールコントロール、正確なポジショニングが要求される。

　では、ITの現場はどうだろうか？ITの現場では先ほども言ったとおり、ピンからキリ、バルセロナ級から二部三部級の能力の人が同じプロジェクトに集まり、一緒に仕事をしているのである。レベルを能力の高いの人に合わせてしまうと、能力の低い人が仕事をできなくなってしまうので、レベルは低めに設定することになる。当然受け入れられるコードの質も低下し、最終的には綺麗なコードBよりも汚いコードAの方が現場に多く蔓延る事になる。

　著者としては、こういう現状を打破すべく--全体のボトムアップを目的とし--プロセスの改善を行うと共にコードの書き方を教えることの重要性、そしてそれらのモチベーションを維持するためにも周囲の理解の必要性を説いているのだと思う。

ということで、まずは勉強勉強！ｗ

P.S. 記事のコードB。if分の条件判定の順番間違ってるよね。記事の本質とは関係ないけど。