ADFSとACSの関係がいまいちよく理解できない

企業内のシステムの拡張としてAzureを利用する場合
ADへのログインでそのAzureサービスにアクセスすることになる。らしい。
我社のADに外部の彼はログインできない。ので、そのAzureサービスは彼は使えない。（安心）

という感じの、ADFSとACSがふぇでれーしょんしてSSOなAzureサービスの検証例がいくつか見つかる。
まあ、そのシナリオでADFSとACSは両方必要で、その例のとおりやればできる。たぶん。

で、ADFSって何？、ACSって何？を理解するのに説明を読む。
すると、ADFSはSTSであることがわかる。
そして、ACSもやはりSTSであるようだ。
つまり、ADFSもACSもSTSだ。なんで？どうして？
ふたつのSTSが必要になるわけがわからなくなって混乱してくる；；；
そもそもなぜ、ACSだけじゃあだめなの？
いやなぜ、ADFSの他にACSが必要になるの？
辺りがわかってない→ぼけ！かす！（Ｔ.Ｔ）

クラウドで運用してローカルへバックアップする

役場も一緒に流された！とか聞いて、あらためて、クラウドの意味を考える。
災害の考慮も含めて一番安全なデータ保存先としての価値は高まる。
てことで、ふたたびサービス＠Azureの検討をしている。
でもって、今の仕事の展開を考えると、オンプレミスとの連携ははずせない。
とりわけ、会社なIDで利用できるクラウドなサービス
は、あえてクラウドを意識する必要もないし、
たんなる社内Webサービスのひとつ
なので、Cloudであることが障害になることはない。
要するに重要なのは、どのIDでその（クラウド）サービスを利用するのか？ということ。
閉じたシステムには閉じたIdPが必要。ってことで
まず必要なのは、ForAzureなIdPなんだと気づく…そうなの？？

RIA ServicesのデータをWindowsフォームに表示する

業務アプリのプラットフォームとしてSilverlight & RIA Servicesはけっこういけてる。
で、バックグラウンドで実行される定期的なバッチ処理などは依然としてWindowsアプリケーションで作成する。
そこはこれまでとおりのC/Sで十分。
サーバーで処理させるのでパフォーマンス的にもDBに直接アクセスでいい。

が、ユーザー管理にMembershipを使ったため
入出力するデータの作成者、更新者に関する情報もMembership経由で取得する必要がある。
サーバー側にMembershipをラップするfor Windowsなサービスが必要になる。
WCF RIA ServicesはOdataエンドポイントのエクスポーズが可能になっている。
ので、新たに別途サービスを追加する必要はなく、for Silverlightのサービスを利用できる。

Odataエンドポイントの構成は、最初にDomainServiceを作る時のウィザードで指定する。
既に作成済みのServiceに追加で構成することもできる。
その手順は、ここ
http://blogs.msdn.com/b/brada/archive/2010/03/16/silverlight-4-ria-services-ready-for-business-exposing-odata-services.aspx

作成したDomainServiceの名前が、P2.MyProject.MembershipServiceなら
OdataエンドポイントのURLは、http://（MyServer）/(MyProjectAppWeb)/P2-MyProject-MembershipService.svc/Odata/ となる。
という説明（点を棒にして、.svc/Odata/をくっつける）がなかなかどこにも見つからない；；；
BradさんがGoogleへいっちゃったのが惜しまれる。
あとは、Windowsアプリケション側でこのエンドポイントを指定してサービス参照の追加を行い利用することができる。

DevExpressロードマップへの反応にしばし耽る

http://www.infoq.com/jp/news/2011/03/WinForms-ERP

そうなんだよね
新しいものはいつもどこかなにか足りない。
それはボロボロすぎて成熟したそれを置き換えるにはまったく役不足！
それでも、いつのまにか外堀は埋められて
ある朝突然にすっかり色が変わった世界が現れる。

なので、古い（成熟した）ものを使いつつ、新しものも育ててく。
要するに、どっちも大事。どっちも使う。
あたりまえのこと。それだけのこと。

そして、それにはそれだけのコストはかかる。
コストがかかるって？そんな馬鹿な！そんなことは認められないっ！！
ので、いろいろ騒がなくちゃならない。
が、かかるものはかかるのだ。それだけのこと。

でだ、ビジネスはいつでも先の先取りだから。
ロードマップがそうなるのはいたしかたない。

過去のそれで回収する利益を
未来のそれに投資していくしかない。
過去に投資することはないでしょう。

DevExpressは信用できる会社だ。

Silverlgiht側でEntityのKeyはReadOnly

RIA Servicesのクライアント側に生成されるEntityクラスのKey項目には、自動的に
[Editable(false, AllowInitialValue=true)]
属性がつく
これをサービス側でなんとかすることはできない（おそらくたぶん）

なので、DataFormに配置したその項目にBindingするDataFieldは、自動的にReadOnlyになる。
もしかするとコードでReadOnlyを解除することはできるのかもしれない。
が、それはたぶんしないほうがいい。

EntityFrameworkを使う
と決めた時点で、そのKeyはつまりObjectIdentityで
それは自動的に生成されるものと考えた方がいい。

もし、ユーザーに入力させたいID項目があるなら
それはEntityのKey項目とは別に項目を追加すればよいだけ。
と納得するまでに1日消費する。 時間かけすぎ；；；
歳だな

RIA Servicesを採用するなら
SQLServerに作成するテーブルのキーは全てIdentity＝Yesで決まり
と割り切る。そこは崩さない。戻らない。

TextFieldParserで日本語が混じった固定長ファイルを読むのはできなさげ

FieldType.FixedWidthを指定すれば固定長ファイルも処理できる
が、FieldWidthsに指定したField長はByte数ではなく文字数として処理される
ので、２バイト文字と１バイト文字が混じったフィールドは思ったように処理されない。
日本でいうところの固定長ファイルを読むのはだめぽい

EverNoteのエディタがバージョンアップで改善されて使いやすくなった

エディタがぼろでどうも気持ちよくなかった→Evernote
が、バージョンアップで確実に進化している
起動も早くなって、おらの用途にはもう不足がない

一方、比較になるOneNoteはページリストの並び順があっしにはダメ

用途によって一長一短なのだろうが
なんでも全部入れていまうのがノートの役割で
用途で使い分ける。とうい使い方が…一番だめぽ