去年の夏から長々と書いてきましたが、やっとこさ、完成いたしました。お疲れ様です ＞ 日経BP の編集の方

執筆途中に、Azure SDK が 1.4 から 1.6 まで上がってしまったり、色々風邪をひいたりして大変だったのですが、まぁ、それなりに詰め込まるものは詰め込めたかと思います。ざっとした前哨戦は、先月の .NETラボ 勉強会 2012年01月 でお話ししたので、ここでは中身の紹介をざっと。

ひと目でわかるWindows Azureアプリケーション開発入門 増田 智明

■Windows Azure & SQL Azure の開発者向け

タイトルの通り、システム管理者向けではなくて「開発者向け」です。なので、セッティングの細かいところは飛ばして、先頭からプログラミングができるような作りにしてあります。実運用をする場合には、いくつか Azure 自身のチューニングポイントがあるのですが、そこは省略しています。

拙著の ひと目 Visual C++ や ひと目 ASP.NET MVC のように、先頭からプログラムを作って完成させていくという作りになっています。

■3つのアプリを順番に作る

Azure で開発するパターンとして最も使われる（と思われる）、3つのストレージを使ってアプリを作っていきます。

• ブロブストレージ（XML ファイル）
• テーブルストレージ
• SQL Azure

という３パターンで、「どこでも蔵書管理システム」を作っていきます。

インターフェースとしては、蔵書データの一括アップロード、一括ダウンロード、新規追加や修正などの、CRUD の機能を作っています。それぞれのストレージでのデータの扱い方の違いがわかると思います。

■Web フォームを使って学習する

これは執筆前に「かなり」悩んだのですが、ASP.NET MVC ではなくて、Web フォームでアプリを作っています。理由としては、ASP.NET MVC で作ってしまうと、MVC 自体の解説も含めることになってしまい、Azure の本筋がずれてしまうこと。後、ストレージの利用の比較をするには、Web フォームのグリッドを使ったほうが違いが分かり易いということです。

なので、旧来の Web フォームで作ってありますので、MVC が分からないても大丈夫です。ええ、MVC のほうは「ひと目 ASP.NET MVC」を立ち読みして頂けるとよいかと。

連載! コードで学ぶ ASP.NET MVC アプリケーション開発入門 | Code Recipe | MSDN で学ぶのもアリです。

■開発言語は C#

これも悩んだのですが、C# で書いてあります。巷のサンプルプログラムが C# だったので、それにあわせてということで。

付録に Visual Basic 版も入れる予定だったのですが、ページ数が多くなったのと、私の体調が...ってことで、断念しております。「強い」要望があれば、Visual Basic のサンプルを作りたいと思いますので、その時は日経BPさんに要望して頂けると助かるかと。

という訳で、総ページ数 400 ページ、値段が 3,200 円（税抜）ということで、本屋さんへ go !!! ... しても、まだ amazon でも予約みたいですね。発売日は 2/9 だそうです。

Ｍ７級首都直下地震、４年内７０％…東大地震研 : 科学 : YOMIURI ONLINE（読売新聞）
http://www.yomiuri.co.jp/science/news/20120122-OYT1T00800.htm

「検算」します（笑）。

昨年３月１１日の東日本大震災をきっかけに、首都圏では地震活動が活発化。気象庁の観測によると１２月までにＭ３～６の地震が平均で１日当たり１・４８回発生しており、震災前の約５倍に上っている。

同研究所の平田直(なおし)教授らは、この地震活動に着目。マグニチュードが１上がるごとに、地震の発生頻度が１０分の１になるという地震学の経験則を活用し、今後起こりうるＭ７の発生確率を計算した。

という情報から、

• M3の地震が 1.48回/日 以上
• マグニチュード(M)が1上がるごとに、発生頻度が1/10 になる。

ということは、M7 の発生頻度は以下になる。

1.48 x 0.1^4 = 0.000148回/日

4年間(365x4)= 1460日間に1回以上発生する確率は、

1.0 - (1460 日間に1度も発生しない確率)

に等しいので、

1.0 - (1 - 0.000148)^1460

となる。

1.0 - 0.805657962 = 0.194342038 = 20% 弱

おいおい...確率が小さすぎますね。

ここで「M3からM6」の確率なので、中間のM5.5の場合に1.48回/日 以上として検算し直すと、

1.48 \times 0.1^1.5 = 0.0468回/日
1.0 - (1-0.0468)^{1460} = 限りなく1に近い（笑)

ので、もうちょっと1日の地震確率が低くないと駄目ですね。

今度は、70% という確率から逆算してしまいます。

0.7 = 1.0 - ( 1 - x )^1460

の方程式を解けばよいので、

(1-x)^1460 = 0.3
1460 \times log(1-x) = log 0.3
log(1-x) = log(0.3)/1460 = -0.000358136
1-x = 10^-0.000358136 = 0.999175701
x = 0.000824299

ということで、1日あたりのM7の地震を

0.00082回/日

という想定で計算していることになります。

これがどれくらいの頻度かというと、「震災前の約５倍」という表現から、震災前は、0.000164回/日となるので、M3の地震が1.48回/日 以上という、最初の初期値と同じになります。そうなると、震災前って、1日に1回はM3の地震って起きていたっけ？ってことになるのですが...ないですね。変ですねｗ、おそらく計算の前提が間違ていると思われます。

この、4年以内にM7の地震が起こるとか、30年以内にM7の地震が起こるという根拠も実は、同じ計算法から出されているもので、

3月11日以降の首都圏の地震活動の変化について | 東大地震研 広報アウトリーチ室
http://outreach.eri.u-tokyo.ac.jp/eqvolc/201103_tohoku/shutoseis/

なんだかねぇ、マスコミ報道も報道ですが、地震研も地震研ですね。大雑把すぎます。

まず、科学的な比較法としての

• 震災前のM3以上の地震確率、その後のM7以上の地震の確率の統計情報
• 経験則で1つマグニチュードが上がると確率が10%になる根拠（経験上のデータ）
• 現状の日単位のM3の地震の確率、ばらつき

が必要なわけで、統計学的に駄目駄目かと（苦笑）。

ま、兎も角、東大地震研の試算でいえば、日単位でM7の地震が起こる確率は、「0.00082回/日」とのことです。1000分の1弱の確率なので結構高い見積といえば見積もりですが、毎日1000回サイコロを廻して、1が出る確率が200回に1回ぐらいだと思えば、それほどびくびくするこはありませんね。

ちなみに「地震研」の発表が大ざっぱというのは、

• M3地震の確率からM7と拡大させるときに、震災後の余震と前兆との区別ができていない。
• よって相関はあっても、因果関係がないので、論理的思考ができていない。論理的な手順を踏んでいない。

ということです。

■補記

3月11日以降の首都圏の地震活動の変化について | 東大地震研 広報アウトリーチ室
http://outreach.eri.u-tokyo.ac.jp/eqvolc/201103_tohoku/shutoseis/

ブログを書いた後にアップされたので、追記。

「誘発地震」と「余震」を区別せずに推測値を出しているので、誤差が大きいかなと。去年の9月で出した計算だそうなので、再度今年に入った数値で計算し直して、推測値の推移を示してほしいものです...と思った。

定点による経過観測をしていないので、増減が分からないのが問題かと。震災前との直接比較だと、震災時の余震の影響度が分からないので、震災後からの数回の観測値から推移を計算するのがベターかと。まあ、地震に関しては、素人なのでこれまで。確率に関してはセミプロですが。

LINQ to Entities で扱う Entity Data Model のテーブル名やカラム名を変更するツールです。
用途としては「wordpress のデータベースを mysql から読み込んだんだけど、wp_ なにやらというテーブル名がいやらしいし、post_id とかじゃなくて PostId がいいんですッ!!!」という時に使います。非常にピンポイントですねｗ

のように、テーブル名とカラム名を変更できます。Visual Studio 上でちまちまとやってもいいのですが、一気にできるということで。テーブル名のマッピングは *.edmx ファイルを直接弄らないと駄目なので、ツールを使う価値はあるかと。

左上の「一律変更」ボタンをクリックすると、.NET 標準の upper camel calse に変換します。「post_id」だったら「PostId」という具合ですね。カラム名をひとつずつ変換することもできます。

保存先は元の *.edmx ファイルで良いのですが、保存した後に Visual Studio に認識させるのがちょっと面倒で。保存しただけでは、*.Designer.cs ファイルが書き換えられないので、保存した後に *.edmx ファイルを開いて、テーブルの位置なんかをずらします。そうすると、Visual Studio が更新を認識してくれるので、*.Designer.cs が更新されるという具合です。このあたり、edmgen.exe で変更できるのかと思うのですが、ちょっとわからないので、そのままで。

実行ファイルは、こちら。 ModifyEdmx.0.1.zip
ソースコードは、ModifyEdmx at master from moonmile/etc - GitHub からダウンロードしてください。

LINQ to MySQL を使って wordpress のデータベースを弄ろうとするときに障壁になるのが、Entity Data Model の自動マッピングです。

のように、自動でマッピングしてくれるのですが、「wp_」のプレフィックスが邪魔だったり、「post_author」のように命名規則が.NET風ではなかったり（C# だったら「PostAuthor」と書きたいところ）。だから、このテーブル名やリスト名を変更したいと思うわけです。

Visual Studio 上でちまちまと名前を変えることもできるのですが、実は *.edmx ファイルを直接書き換えても、マッピングするときの名称を変えることもできます...と言いますから、デザイナ自体がこの *.edmx ファイルを参照しています。

そのまま *.edmx ファイルをエディタで修正してもいいのですが、どうせならば、ざっと効率よいやり方で編集したい、と思う訳です。

こんな風に、データグリッドを使って編集できればよいかなと。

手元の ExDoc を使って XML ファイルを操作すると、こんな感じです。

string _filename = @"Model1.edmx";
EXDocument _doc = null;

/// <summary>
/// 読込ボタン
/// </summary>
/// <param name="sender"></param>
/// <param name="e"></param>
private void button1_Click(object sender, EventArgs e)
{
	_doc = new EXDocument();
	_doc.Load(_filename);

	// リストにテーブル名を表示
	EXElements tables = _doc * "EntitySet" % "store:Type" == "Tables";
	listBox1.Items.Clear();
	foreach (var el in tables)
	{
		Debug.Print("table: {0}", el % "Name");
		listBox1.Items.Add(el % "Name");
	}
}

/// <summary>
/// リスト選択
/// </summary>
/// <param name="sender"></param>
/// <param name="e"></param>
private void listBox1_SelectedIndexChanged(object sender, EventArgs e)
{
	if (listBox1.SelectedIndex == -1) return;
	string name = (string)listBox1.SelectedItem;
	EXElement el = _doc * "MappingFragment" % "StoreEntitySet" == name;
	var items = from t in el / "ScalarProperty"
				select new ScalarProperty
				{
					Name = t % "Name",
					ColumnName = t % "ColumnName"
				};
	dataGridView1.DataSource = items.ToList();
}

/// マッピングクラス
/// </summary>
public class ScalarProperty
{
	public string Name { get; set; }
	public string ColumnName { get; set; }
}

手前味噌ですが、XML ファイルを直感的に扱えるのでコーディングが結構楽かなと。あと、返す値が List なので、実はそのまま LINQ が使えます。これは結構便利かも。
と言いつつ、ExDoc の Save 機能はあまりきちんと実装していないんですよね。この機会に少しテストをしますか。

「残念、さやかちゃんでした」...じゃなくて、zip 内比較をしようと思って C# で扱える zip ライブラリを探してみる。

J's Memo: C#でZIPファイルの生成
http://beginnerdiver.blogspot.com/2009/01/czip.html

GZipStream クラス (System.IO.Compression)
http://msdn.microsoft.com/ja-jp/library/system.io.compression.gzipstream.aspx

gzip を扱うのであれば、標準で用意されている GZipStream クラスを利用すればよいかな、と思っているわけですが、私がやりたいのは

• windows 上で圧縮された zip 内を検索
• zip 圧縮はいらない。
• zip 解凍はメモリ上でやりたい。

ので、GZipStream クラスでは駄目なのかなぁ。解凍すればよいだけなので、

DotNetZip Library
http://dotnetzip.codeplex.com/

あたりが候補になります。

Ionic Zip Library v1.9.1.6 - Table of Content
http://cheeso.members.winisp.net/DNZHelp/

にあるサンプルコードを見ると、以下のように foreach で ZipEntry オブジェクトを列記できる模様。

using (ZipFile zip = ZipFile.Read(ExistingZipFile))
{
  foreach (ZipEntry e in zip)
  {
    e.Extract(TargetDirectory);
  }
}

次のように、OutputStream が使えるので、MemoryStream に渡せばメモリ上で操作可能

using (ZipFile zip = ZipFile.Read(ExistingZipFile))
{
  ZipEntry e = zip["MyReport.doc"];
  e.Extract(OutputStream);
}

■おまけ

プログラミング言語「ほむほむ」 - ゆろよろ日記
http://d.hatena.ne.jp/yuroyoro/20110601/1306908421

というのがあるそうです。「ほむ」だけじゃなくて「ほむ～ん」とか「ほむほむ」とか、色々混ぜると面白いカモ。

Ａ級リーグ指し手１号
http://aleag.cocolog-nifty.com/

電王戦リアルタイム実況 by やねうらお - やねうらお－よっちゃんイカを食べながら、息子語録を書き綴る
http://d.hatena.ne.jp/yaneurao/20120114#p1

電王戦観戦記 ほかではあまり語られない舞台裏
http://weekly.ascii.jp/elem/000/000/072/72605/

将棋、囲碁とあまりに弱い（でも普通ぐらいには強い...かな。いや、弱いかも）ので、電王戦にはいまいち興味が持てずにいるのですが、ちと古い記事ですが、

ボンクラーズが勝った。そうです。

ええ、正式名称は「bonkras」なんですが、どうやら名称元は↑らしい。実に「爽快」ですね。

将棋とか囲碁、オセロもそうですが、時間があれば必ず解ける（勝てる）問題なので、アルゴリズム自体と高速化に頭を費やせる解決可能な問題です。これはこれで面白そうなので、4年ほど前から考えてはいたのですが、いや、先人が多くて無理、というのと私自身が弱くて無理。開発者の伊藤英紀氏はどうなんでしょう？そこそこ強いのだと思いますが。

名前が痛快ですね（イタイという意味でもｗ）はさておき、

ブレードサーバーを６枚使わないと米長名人に勝てないのか、そうなると、米長名人の頭の中のアルゴリズム（らしきもの、直感も含めて）はどうなっているんでしょう？ということになるわけで、実は棋士一般に云えることで、

• 将棋盤のパターン化で覚える（月下の棋士のように？）
• 膨大な棋譜（記憶にある棋譜）から、似たようなパターンを思い描く。
• 似たようなパターンと、違いを見出す。
• 先読みをする。

といういくつかのパターン化と、アルゴリズム化（決定論という意味で）が混じっています。ボンクラーズなどの将棋アルゴリズムがやることをは、最後の「先読み」を膨大に進めることで、その他の「パターン化」を補っている、と考えられます。ええ、考えられます、ってのは、ボナンザなどなどアルゴリズムを覗いたわけではないので、想像です。

逆に言えば、パターン化を進める、パターン化による省略化、省力化によって、人や動物は変化に瞬時に対応するわけでそのあたりお「いい感じ」（via 岸和田博士）にしてしまうのが、最近の私の目標かなぁと。ちと、他に頭が廻っていますが、また opencv に頭を戻していきます。そうそう、特徴点抽出による物体認識も、初手はテンプレート検索になってしまうので、このあたり認識スピードや卵と鶏の関係っぽいですね。もうちっと、大ざっぱにやりたいと思い直しています。

余談ですが、中村太地五段がボンクラーズの代理をして指しているのを、ロボットが指すと、痛さ倍増かもと思ったりして。このあたりが目標ですね。

Excel ファイル、と言いますか、バイナリファイルの類似検索のツールです。

BinDiffCheck.0.1 からダウンロードしてください。

フォルダ内にある、ファイルを「いい感じ」に比較して、どれだけ近いか、を出すツールです。

1. チェックするフォルダを指定します。
   （複数フォルダは指定できないから...あったほうがいいかな？）
2. チェックする拡張子を指定します。
   空欄の場合は、すべてのファイルが対象になります。
3. 「実行」すると、相互にファイルをチェックしていきます。
4. 結果を「コピー」ボタンでクリップボードにコピーして、Excel に貼りつけてください。
5. 「DiffFile」の値が、小さいほど似通っています。

Diff のロジックは、2007-03-15 - 当面C#と.NETな記録 からそのまま頂いております。

適当に、オートソートを掛ければわかりやすいかなと。

２つの Excel を比較する場合は、vector とかで、ベクター : 「excel ファイル 比較」の検索結果 すると、色々出てきます。

ソースコードの公開は、後程。

単純に２ファイルを比較する部分は、

2007-03-15 - 当面C#と.NETな記録
http://d.hatena.ne.jp/siokoshou/20070315

にある FastDiff のコードをコピーして利用。

namespace SampleBinDiff
{
	class Program
	{
		static void Main(string[] args)
		{
			string srcfile = args[0];
			string destfile = args[1];

			Program prog = new Program();
			prog.Go(srcfile, destfile);
		}

		public int Go(string srcfile, string destfile)
		{
			string src = BinToString(srcfile);
			string dest = BinToString(destfile);

			// DiffResult[] res = FastDiff.DiffChar(src, dest);
			DiffResult[] res = FastDiff.Diff(src, dest);

			Console.WriteLine("count: {0}", res.Length);
			int diffcount = 0;
			foreach (var di in res)
			{
				Console.WriteLine(di.ToString());
				if (di.Modified)
				{
					diffcount += di.ModifiedLength + di.OriginalLength;
				}
			}
			Console.WriteLine("diffcount: {0}", diffcount);
			return 0;
		}

		public string BinToString( string fname )
		{
			BinaryReader br = new BinaryReader(File.Open(fname, FileMode.Open,FileAccess.Read));
			byte[] data = new byte[new FileInfo(fname).Length];
			br.Close();
			StringBuilder sb = new StringBuilder();
			foreach (byte b in data)
			{
				sb.Append(Convert.ToString(b, 16));
				sb.Append("\n"); // 行単位で比較
			}
			string src = sb.ToString();
			return src;
		}
	}
}

バイナリ比較のために FastDiff.DiffChar で比較しようと思ったのだけど、あまり思ったような結果が得られないので、無理矢理改行コードを入れて FastDiff.Diff で比較しています。

実行結果は以下のような感じ。ファイル名を2つ指定すると、diffcount という数値を出します。diffcount が 0 であれば一致、大きければそれだけファイルが違うという感じ。

Debug>SampleBinDiff ..\..\Program.cs ..\..\Program3.cs
count: 2
Common, OrgStart:0, OrgLen:2720, ModStart:0, ModLen:2720
Modified, OrgStart:2720, OrgLen:0, ModStart:2720, ModLen:24
diffcount: 24

これを相互 10,000 ファイルで当たっていけばよいので、適当な閾値をつけて類似ファイルを見つけるか、ヒストグラムを出して、一致する自動的に閾値を見つけるか、という感じで。続きは明日。

Twitter / @futamiryo: 画像は類似検索があるけどxlsやzipは完全一致ばっ ...
https://twitter.com/#!/futamiryo/status/163566455504375808

単純に、バイナリdiff を取ればよいのでは？と思ったり思わなかったりしただけど、

• バイナリ形式で、Excel ファイルを比較するけど、ファイル数は 10,000 ファイルほどある模様。
• なので、単純な突き合わせだと、10^10 のオーダーになって爆発しそう。

な訳で、２段階踏まないと、実運用に耐えなそう。

バイナリ形式の diff は、文字単位に diff を取ればよいので、2007-03-15 - 当面C#と.NETな記録 の .NET diff class の DiffChar を使うのがよさげ。比較するのが string なので、バイナリデータを 0xFF のアルファベットに直してから比較するのが良いでしょう。

比較ファイルの絞り込みは、

• ファイル名の比較（おそらく、似た名前で作っているハズ）
• ファイル長さの比較（あまり違う場合は、はずすとか）

にしておけば、10^10 のオーダーではなくなるハズです。

そして、結果の、DeffResult[] が、少ない順にまとめていけば、なんとなく新旧のファイルがあつまるはずですね。

結果は、なんらかの形でレポートすれば、よかろうと。

ってことで、ふたみさんの作業には間に合わいそうもないけどｗ、ちと、この路線で明日作ってみますか。

Tips と言いますか、メモ書き。時々忘れるので。
画像の編集とかの場合には、「Excel 方眼紙」を作ると便利です。特に Excel 2010 にもなると、ワードアートなんかを使って綺麗なロゴが作れます。ここのロゴや トニー電の.NETプログラミング講座 のロゴは Excel 2010 で作っています。

■背景が白の方眼紙を作る

1.Excel 2010 を起動して、列を CZ ぐらいまで適当に選択
2.そのまま右クリックして、「列の幅」をクリックする。

3.列の幅を「2」に設定
4.方眼紙っぽくなります。

5.リボンで「ファイル」→「オプション」をクリック
6.「詳細設定」のタブで、「枠線を表示する」のチェックを外す。

あるいは、リボンの「ページレイアウト」→「枠線」→「表示」

7.これで、背景が白の Excel シートができます。

■複数のオブジェクトを選択

貼りつけたオブジェクトを選択したい場合は、ひとつひとつ選択してもよいのですが、以前のようにマウスで囲みたいですよね。Excel 2010 の場合は、リボンの「ホーム」→「検索」の▼ボタンを押して「オブジェクトの選択」でできます。

こんな風に範囲で選択できます。

■オブジェクトをグリッドに合わせる

方眼紙なのですから、グリッドにぴったりに合わせることもできます。
何かのオブジェクトを選択した状態で、リボンの「書式」→「配置」の「枠線にあわせる」をチェックします。

こうすると、枠線（グリッド）に合わせることができるので、図形を綺麗にそろえることができます。

微妙な位置合わせは、図形を選択した状態で、カーソルキー（↑↓など）でドット単位（多分）動かせるので、これを使うとよいかも。

■図形から画像ファイルを作る、クリップボードへコピーする

Excel には面白い機能があって、セルを選択した状態にして、Ctrl+C すると、画像がコピーされます。

この状態で、Ctrl+C でコピーします。クリップボードに転送されるので、ペイントに貼りつければ、画像ファイルに保存できます。

こんなところが、私の編集スタイルですね。高価な画像ソフトを持っていないのですが、まあ最近はこれで十分かと。