久しぶりの更新です。今回のgitの使い方のお話です。
本来gitは分散型で、中央集権型のサーバを持たない使い方が想定されていると思いますが（実際オープンソースの開発だと特に）、仕事でgitを使うような場合はやはりSubversionに慣れているのもあり、共有サーバを一台用意し、それに対して開発メンバがPushしていくという使い方が多いかと思います。
そのような使い方の場合は、リモートにあるブランチを追跡する追跡ブランチをローカルに持っておくのが便利ですが、今までは「ローカルブランチ作成」→「追跡ブランチ化のコンフィグ設定」→「リモートへ作成したブランチをPush」という手順で追跡ブランチを作成していました。
ちょっとgitの使い方を調べていた所、もっと賢い方法があったので紹介します。（自分への備忘録としても。。。）
これで、追跡ブランチとして新しいブランチを作成できます。
Windows Azure Tableに対するLINQクエリおよびREST APIでは、Joinによるエンティティの結合をサポートしていません。もちろんAzure Tableを使う時には、関連するエンティティのプロパティをコピーさせるなどしてJoinする必要がないようにデータモデルの設計を行います。
ただそれでも、仕様変更や機能追加によって当初想定していなかったデータの結合が必要になる場合もあります。そして、どうしてもデータモデルを変更したくないような場合には、Join処理が必要になってくると思います。
今までシステムを実装してきた中で行ったJoinの実装パターンを紹介します。
Windows AzureのTableストレージにおけるデータ検索では、基本的にはStorage Client LibraryのLinq to Azure Tableを使って開発するものの、AzureのLinqでは一部のLinq式しかサポートしておらず大部分のLinq式がサポート外になっています。http://msdn.microsoft.com/en-us/library/windowsazure/dd135725.aspx
そのため、Azure Tableにおいてデータ検索を行う際は、Linq to Objectを並行して利用する必要が出てきます。この使い分けについての基本的な考え方は表示対象エンティティをLinq to Azure Tableで取得し、その後のデータ加工処理をLinq to Objectで行うといった雰囲気です。ただしこの２つのLinqの使い分けでは、Linq to Azure Tableにおける取得可能なエンティティ数に制限がある（1000件未満、クエリ実行時間5秒以下 参考：http://msdn.microsoft.com/en-us/library/windowsazure/dd179421.aspx）ので、この制限にかからないよう十分にLinq to Azure Tableで絞込みを行う必要です。
Windows Azure上で、Log4NetのRollingFileAppenderによりBlobストレージ上にログファイルを書きだすようにしてみたので、その方法についてまとめです。
やり方自体は単純で、RollingFileAppenderのログファイルの出力先を Windows Azureの Local Storageに設定し（これが意外と面倒）、出力先のLocal Storageの内容をDiagnostics Monitorで転送させてるだけです。またlog4netの設定ファイルlog4net.configはBlobストレージ上に置かれたものを使うようにしました。
標準のAzure Table Storageにおいては以下の型のみが保存可能な型としてサポートされており、これ以外のプロパティとして持つエンティティを保存しようとするとエラーになってしまいます。
| EDM型 | CLR型 | 詳細 |
| Edm.Binary | byte[] | バイトの配列 (サイズは最大 64 KB) |
| Edm.Boolean | bool | ブール値 |
| Edm.DateTime | DateTime | UTC 時刻として表現された 64 ビット値 (サポートされている値の範囲は 1/1/1601 ～ 12/31/9999) |
| Edm.Double | double | 64 ビットの浮動小数点値 |
| Edm.Guid | Guid | 128 ビットのグローバル一意識別子 |
| Edm.Int32 | Int32 or int | 32 ビットの整数 |
| Edm.Int64 | Int64 or long | 64 ビットの整数 |
| Edm.String | String | UTF-16 でエンコードされた値 (サイズは最大 64 KB) |
ただ、この制限に従って実際にシステムを作ろうとすると、ビジネスロジック層がドメインモデルとして設計されている場合に、ドメインオブジェクト群をストレージへ保存する際、そのオブジェクト構造をフラットに展開してからデータを保存しなければなりません。また、そのデータを読み込む時もフラットな構造から元のドメインオブジェクトに戻す処理が必要です。
データを読み書きするためにいちいちこんなことはやってられないので、今回はStorage Client APIをカスタマイズして、オブジェクト構造をそのままTable Storageへ保存できるようにします。
