Developer @ ADJUST

[動画あり] Visual Studio の強力な JavaScript インテリセンス機能の活用 - WSHスクリプトエディタに最適!

21世紀の WSH

Windows OS の次世代スクリプティング環境は PowerShell ... のはずだが、皆さんいかがお過ごしだろうか。

未だに、WSH、すなわち、Windows Scripting Host ベースでのスクリプトを書いていたりしません?

自分は PowerShell は苦手意識が強いのだが、その代わり次世代スクリプティングは F# スクリプトだ、などと吹聴している。

にも関わらず、実業務では .js や .wsh による WSH スクリプトを書くことがいまだにある。

というのも、F# スクリプト環境は、(近代の)すべての Windows OS にはじめから入っている、わけではないからだ。

JavaScript + Visual Studio

WSH といえば VBScript、という方が多勢かもしれないが、自分は Web アプリケーションが主たる業務であることもあり、JavaScript ( 厳密には JScript? ) で書いている。

そこで大変役に立つのが Visual Studio、だ。

「スクリプトのいいところはエディタひとつで簡単に書けることでは? そこへもって、なんであんな巨大な IDE を使うのか?」というご意見はごもっとも。

たしかにそうなのだが、にもかかわらず、Visual Studio を立ち上げるのは他ならない、"インテリセンス" のためだ。

もともと、Visual Studio は、ASP.NET Web アプリケーション開発の効率化のために、JavaScript に対するインテリセンス機能を代々強化・進化し続けてきた。

その成果が、JavaScript による WSH スクリプト記述にも大変役に立つのだ。

とは言っても、WSH のために機能強化されてきたためではないため、WSH 環境下で提供される WScript オブジェクトや、Scripting.FileSystemObject COM コンポーネントなどに対するインテリセンス機能が、なにもしなくても手に入るわけではない。

WSH 用のインテリセンス機能を提供する WSH-vsdoc.js

ということで、WSH JavaScript の記述にあたってインテリセンスが機能するように、1つ、JavaScript ファイルを作成し、GitHub で公開を始めた。

https://github.com/jsakamoto/WSH-vsdoc

能書きはともかく、どれくらい Visual Studio のインテリセンス機能が強力か、以下の動画をご覧頂いた方が話は早いかもしれない。



いかがだろうか。

WScript オブジェクトのインテリセンスが機能しているのは当たり前。

加えて new ActiveXObject("Scripting.FileSystemObject") が返した COM オブジェクトに対して、ちゃんと GetFolder などのメソッドが候補に表示される。

さらに、Files などのコレクションプロパティに対して Enumerator を new して item() を取ると、ちゃんと File オブジェクトのメンバが候補に表示されるのだ。

また、同じ ActiveXObject であっても、コンストラクタ引数に "WScript.Shell" を渡した場合は、ちゃんと WScript.Shell オブジェクトとして振る舞い、Run などのメソッドが候補に表示されるようになる。

また、Run メソッドのパラメータヒントを見れば、「うーん、外部プロセス起動時の、ウィンドウスタイルで最小化を指定するには何を指定するんだっけ?」という疑問もすぐにわかる。

自分は WSH スクリプトを日常的に書いているわけではないため、多くを覚えずに済むこのようなインテリセンス機能は大変ありがたい。

使い方おさらい

WSH-vsdoc.js の使い方は、上記動画のとおりなのだが、念のため、テキストでもおさらいしておく。

1. 上記 GitHub の WSH-vsdoc リポジトリから、WSH-vsdoc.js を入手し、適当なフォルダに配置しておく。
2. Visual Studio で .js や .wsh、.hta などのファイルを開く。
3. 開いたファイルの JavaScript セクションの最初の1行に、
   「/// <reference path="...."/>」
   として、先ほど入手・配置した WSH-vsdoc.js のフルパスを記述する。
   （※パス中のバックスラッシュはエスケープする必要はない）

たったこれだけで、Visual Studio による WSH 用各種オブジェクト類のインテリセンスが機能するようになる。

だがしかし WSH-vsdoc.js は作りかけ :P

しかしながら、この WSH-vsdoc.js、誠に残念ながら、すべてのメンバを網羅していないのだ。

自分が最近使ったメンバだけを記載してある。

今後もリファレンスを引く羽目になったメンバだけ、少しずつ、この WSH-vsdoc.js に書きためていくつもりだ。

なお、GitHub 公開しているので、fork ご自由に。
なにかメンバ追加されたら是非 pull request を送っていただければ幸いである。

この調子で Excel-vsdoc.js も!?

この調子で、誰かが Excel-vsdoc.js 作ったらおもしろいかもしれない。

var excelApp = new ActiveXObject("Excel.Application");

とやって、

excelApp.W

とまでタイプしたら、"Workbooks" が候補に現れるような。
　
ん?
いつまで WSH を使い続けるのか?
　
うーん... Windows 8 でも WSH 使えるんですよね?
だったらまだ当面暫くは、でしょうかねぇ。
　

続・F# スクリプトをコマンドラインから簡単に呼び出す - コマンドライン引数の取得

前回の投稿で、Windows のコマンドプロンプトから「test」[Enter] と入力すると、test.fsx が fsi.exe に読み込まれて実行されるよう設定する手順を説明した。

しかしながら、一点、大事なことを書き忘れていたので補足する。

F# スクリプトでのコマンドライン引数の取得

F# スクリプトでは、コマンドライン引数は fsi.CommandLineArgs という配列によって取得できる。

しかし、コマンドプロンプトから次のように実行してみると...

>echo printfn "Hello, %s." fsi.CommandLineArgs.[1] > test2.fsx
>test2 F#

残念ながら、fsi.CommandLineArgs は1要素しかないが故の、配列添え字が範囲外との例外となってしまう。つまり、コマンドライン引数がうまく F# スクリプトに渡されていないのだ。

そこで、この点を改善すべく、再びレジストリ設定を変更する。

レジストリ設定の修正

レジストリエディタを起動し、まずは HKEY_CLASSES_ROOT\VisualStudio.fsx.11.0\shell\openRunFsi\command キーを開く。

ここに、fsi.exe を起動するコマンドが記述されている。
"(Default)" の値を編集し、いちばん末尾に「%*」と追記すれば OK。以上で「test2 F#」[Enter] と入力すれば、「Hello, F#」というように、コマンドライン引数を取得して表示されるようになる。

Webkit 系ブラウザに日本語ファイル名でダウンロードさせると文字化け - 対策したはずなのに!?

ブラウザに日本語ファイル名でダウンロードさせる

ASP.NET による Web アプリケーション開発での話。

ASP.NET Web アプリ側からブラウザ側への応答返信時、Content-Disposition 応答ヘッダに、"attachment; filename=～" という値を指定すると、ブラウザ側ではファイルのダウンロード処理が行われる。
ダウンロード処理時のファイル名は、この応答ヘッダの filename=～ に指定する。

たとえば次のようなコードがあったとすると、

Response.AppendHeader(
  "Content-Disposition",
  "attachment; filename=something.zip");

"something.zip" というファイル名で応答が保存されるのだ。

このときの "ファイル名" に日本語のようなマルチバイト文字列を指定しようとすると、実は結構やっかいだ。

とりあえず今日現在の状況をおさらいしてみると、マルチバイト文字列をダウンロードファイル名に指定する方法は、ブラウザに応じて以下のとおりのはずである。

• IE8 以前は Unicode 文字列を UTF-8 エンコードして生成したバイト列を URL エンコードした 7bit ASCII 文字列で指定。
  
  
• IE9 以降、および、いつ頃からかの Firefox では、IE8 以前と同じ手順で生成した文字列を使うが、ただし、"filename=～" に続けるのではなく、"filename*=utf-8''～" という、一瞬誤記ではないかと疑いたくなるような特殊な記述で指定（RFC 6266）。
  
  
• Safari や Google Chrome など Webkit 系では Unicode 文字列を UTF-8 エンコードしたバイト列をそのままで指定。

すみません、Opera は不勉強でわからないです...
(ただ、これは想像だけど、Opera は最新仕様に早くから対応するイメージがあるので、たぶん、RFC 6266 のとおりでOKじゃないかな?)

それでもWebkit 系ブラウザでファイル名文字化け

さてところで、上記のとおりのダウンロードファイル名指定を実装したにもかかわらず、動作検証中に、Webkit 系ブラウザでのみ、日本語ファイル名によるダウンロードでファイル名が文字化けする、という怪現象が発覚した。

それも本番環境をかなり正確に模擬した検証環境でのみ発生するのだ。

開発環境ではぜんぜん再現しない。

IE9 の開発者ツールでネットワークのキャプチャで観察しても、たしかに、検証環境から返される応答ヘッダはしっかり文字化けしていた。
Web アプリケーションのバイナリは、いずれの環境でも慎重に正確に一致させてある。
よって、アプリケーション側のコードになにか原因があるとは考えにくい。

となると、原因があるのは、アプリケーションを取り囲む環境構成にあるのではないか。

検証環境とそれ以外の環境の差異はなにか。

それはリバースプロキシの存在にあった。

IIS7 + ARR

検証環境では、Web サーバーが直接クライアントにさらされているのではなく、IIS7.5 + Application Request Routing 拡張機能 (以下 ARR) によるリバースプロキシを介して接続する構成になっていたのだ。

Application Request Routing - IIS TechCenter
http://technet.microsoft.com/ja-jp/iis/ee839425

すなわち、IIS7.5 + ARR が Web サーバーからの応答を中継するときに、何か起きているのではないだろうか。

ということで試しに、IP 経路を変更したりして、リバースプロキシを迂回して直接 Web サーバーと通信できるように構成し、改めて Safari for Windows でダウンロードしてみた。
すると、さすがに期待どおり、正しい日本語ファイル名でダウンロードされるようになった。

ということで、ほぼ間違いなく犯人は ARR である確信を得た。

しかし原因はそうだとしても、どうすればこの現象を回避できるのだろうか。

ARR の設定を IIS マネージャを通してあれこれ探索したりいじってみたりした。
しかし結局、応答ヘッダの中継とその文字コードに関係しそうな設定項目をつきとめることができなかった。

そこでいったん手を置いて休憩し、ゆっくり考えてみた。

文字化けしている、ということは、Web サーバーが返した UTF-8 エンコードされている応答ヘッダを、ARR が正しくデコードできていないに違いない。
いったい ARR は、応答ヘッダのエンコード方式が何であるとして扱っているのだろうか。

そこでふと思い立って、ASP.NET Web アプリ側が返す応答ヘッダのエンコードを SHIFT-JIS に変えてみた。

設定は簡単。
当該 ASP.NET Web アプリの web.config 構成ファイルをエディタで開き、system.web - globalization セクションの responseHeaderEncoding 属性に "shift_jis" と書いて保存すればOK。

これで再び ARR によるリバースプロキシ経由で Safari for Windows によるアクセスを行うと、正しく日本語ファイル名でダウンロードされるようになった。

とりあえずこれにて一件落着とした、が...。

たまたま今回のアプリでは、応答ヘッダのエンコードを SHIFT-JIS にしても問題ない仕様であった。
しかし、日本語以外のファイル名や、SHIFT-JIS エンコーディングの範疇外の文字を含むファイル名を指定したい場合は、これではお手上げだ。

ARR の挙動が本当に変えられないものなのか、まだまだ要調査である。
　

F# スクリプトをコマンドラインから簡単に呼び出す方法

小さな作業

最近の仕事では、以下のような作業がちょくちょく発生している。

1. 文字列を MD5 や SHA1 などのアルゴリズムでハッシュ
2. 新しいGUIDの生成
3. 英数字による任意の文字数のランダムな組み合わせの生成
   etc. etc...

これら作業が発生するたびに、いままでは手近にあるプログラムでこなしていた。

1. LINQPad を起動してC#コード片をぱっぱと入力するか（たとえば Guid.NewGuid().ToString("N") とか）、あるいは作り置きしておいたテンプレを開いて実行
2. GUID 生成であれば、SQL Management Studio でクエリウィンドウが開いていれば、そこで SELECT UPPER(REPLACE(NEWID(), '-', '')) を実行
3. GUID 生成であれば、Visual Studio が開いていれば [ツール(T)]-[Create GUI] ツールを起動（Alt, T, G の打鍵で開くことができる）
4. F# インタラクティブ（fsi.exe）を開いて、F# コード片を入力

ざっとこんな感じ。

Ruby や Python、はたまた、PHP などがインストールされている環境で、かつ、ちゃんと使い方に慣れているのであれば、そういったツールや言語を使ったかもしれない。
また、コマンドラインが充実している *nix 系の OS なら上記タスクはコマンドラインからこなせたりするのだろうか。

さてさてそれはともかく、今日までは、上記のような感じで、その場その場でやりくりしてきた。
しかしどうにも不効率だとは常々感じていた。

そこでようやく重い腰を上げて、上記小さな作業を効率よくこなせるようにと、環境整備に着手した。

F# スクリプト

そこで採用したのが F# スクリプトだ。

上記作業をこなす小粒の .fsx ファイルたちを、Path の通ったしかるべきフォルダに置いておき、コマンドプロンプトを開いて呼び出すのだ。

先述の小さな作業をこなしてくれるツール類は、今時代、インターネット上に散在していることと思う。

しかしながら、それらをネット上から探してくるよりは、自分のやりたい作業と自分の感性に完璧にフィットした、小さなスクリプトをぱぱっと書いてためておく方が、よっぽどストレスがないと判断した。

それに F# の勉強にも多少はなろう。

ちなみに、Windows でコマンドラインなら PowerShell がある。
また PowerShell のコマンドレット、スクリプレットは、F# スクリプト同様、.NETer による自作は容易なはずだ。

しかしながら、自分は PowerShell は不勉強なので、今回の選択肢からは漏れた。

環境設定

そうはいっても、そもそも F# スクリプトをコマンドプロンプトから快適に起動するためには、一仕事しないとならない。

まず、そもそもの、F# 処理系自体のインストールだが、自分の場合はたまたま Visual Studio 2010 Pro を利用しており、F# もインストールしてあるので、とくになすべきことはない。

拡張子 .fsx の関連づけ

Visual Studio と F# がインストールされている場合、拡張子 .fsx にはプログラムとの関連づけがされている。
しかし既定で起動するプログラムが、Visual Studio となってしまっている。

たとえば、コマンドプロンプトにて、以下のように入力すると、

echo printf "%s" "Hello" > test.fsx
test.fsx

Visual Studio が起動し、test.fsx をエディタ画面で開いてしまうのだ。

しかし自分がやりたいのは .fsx を fsi.exe で読み込んで実行させることである。

そこで拡張子 .fsx に対する既定のプログラムを、fsi.exe による実行に設定変更することにする。

いろいろやり方があるはずだが、自分はレジストリを直接いじることにした。

レジストリエディタを起動して、HKCR\.fsx を開くと、"VisualStudio.fsx.10.0" といった記述が見つかるはずだ。
そこで続けて、HKCR\VisualStudio.fsx.10.0\shell を開く。
shell の下にはさらに、Open と openRunFsi のサブキーがある。

Open には Visual Studio で開く指令が、openRunFsi には fsi.exe で開く指令が設定されている。
いまのところ、これ以上の設定がないので、Windows OS は、.fsx を "開く" にあたり、既定でいちばん優先順位のたかい Open 指令を実行していたわけだ。

これは、サブキー shell の "(Default)" ノードの値を指定することで設定変更できる。

サブキー shell の "(Default)" ノードに、"openRunFsi" と記述する。
これで、拡張子 .fsx のファイルを "開く" ときの既定の動作が openRunFsi 指令となり、結果として、fsi.exe による実行となるわけだ。レジストリエディタによるこの設定変更がすんだあと、先のコマンドプロンプトに戻って "test.fsx" [Enter] と入力する。
すると、"Hello" と表示されるはずだ。

拡張子の入力を省略

これで目的はほぼ達成できた感じだ。

しかし、かならず拡張子 .fsx までつけなくちゃいけないのが、せっかくのコマンドプロンプト用のツールなのに、感覚を台無しにしている。

幸い、拡張子を省略しても実行されるようにするのは難しくない。

OS の環境変数 PATHEXT に、拡張子 .fsx をセミコロン区切りで追記しておけばよい。これでコマンドプロンプトにて "test" [Enter] と打鍵するだけで、"Hello" と表示されるようになった。

環境変数 PATH の設定

あとは、作成・保存しておいた .fsx ファイルたちをどこか適当なフォルダに集めておき、そのフォルダへのフルパスを、OS の環境変数 PATH にセミコロン区切りで追記しておけば万全だ。

コマンドプロンプトを開けば、いつでもどこでも、自分の作った F# スクリプトを実行できる。

起動が遅い?

ただ、せっかくのコマンドライン環境に水を差すようだが、F# スクリプトは、どうにも起動が遅い。

今回の投稿では割愛するが、ngen による事前コンパイルも当たり前のように済んでいたし、fsi.exe 起動時のオプションスイッチもいろいろいじったが（--gui- などなど）改善には至っていない。

これが今のところの悩みである。
　

[動画あり] ASP.NET MVC4 アプリに Twitter Bootstrap を5分で組み込む

Visual Studio を使っての ASP.NET MVC4 Web アプリを作るときの話題。

Twitter Bootstrap について

"Twitter Bootstrap" とは、Twitter 社が公開している CSS/UI フレームワークの名前だ。

Twitter Bootstrap
http://twitter.github.com/bootstrap/

Twitter Bootstrap の CSS ファイルや JavaScript を自分の Web アプリに読み込み、適宜コーディングしてやれば、Twitter ライクなきれいな画面が作れる、しかもレスポンシブ (Responsive、デバイスの画面解像度にあわせて柔軟に自動でレイアウトされる)、という代物である。

ASP.NET MVC4 Web アプリに組み込む

NuGet からパッケージ入手

手持ちの ASP.NET MVC4 Web アプリに Twitter Bootstrap を組み込むには、もちろん、いろいろなやり方がある。

とりあえず自分は、NuGet から Twitter.Bootstrap パッケージをプロジェクトに追加して使っている。

Twitter.Bootstrap
http://nuget.org/packages/Twitter.Bootstrap

ちなみに、Visual Stuio Gallery には、Twitter Bootstrap をベースとした View で作ってくれるらしいプロジェクトテンプレートも見受けられる。
しかしプロジェクトテンプレートだと、既存のアプリに Twitter Bootstrap を組み込むのは難しい。

その点、上記 NuGet パッケージは容易に既存のアプリに Twitter Bootstrap を組み込むことができる。

レイアウト用の View は用意されていない

ところで上記 NuGet パッケージは、Twitter Bootstrap の CSS や JavaScript を適切に配置してくれるものの、レイアウト用の View などはさすがに用意してくれない。

自分でレイアウト用の View を書くことになる。

しかし、毎度毎度、Twitter Bootstrap のサイトからテンプレートをコピーしてきて ASP.NET MVC4 プロジェクトにフィットするよう書き換えるのは、まったくもって生産的ではない。

レイアウト用の View をテンプレ化、VS Gallery に公開

そこでレイアウト用の View を、Visual Studio のアイテムテンプレート化。

さらに、Visual Stuido Extension インストーラの形式にパッケージし、Visual Studio Gallery に公開した。

MVC 4 TwitterBootstrap Starter Layout Page (Razor)
http://visualstudiogallery.msdn.microsoft.com/268d0b05-6ba5-4793-9a10-7d9d2a478881

上記から .vsix ファイルをダウンロードして、エクスプローラ上で開けば、インストーラが起動する。
あとは画面の内容に従ってインストールを済ませるだけだ。

手順

具体的な手順としては次のとおり。

1. 先に書いたとおり、あらかじめの準備として、"MVC 4 TwitterBootstrap Starter Layout Page (Razor)" アイテムテンプレートを Visual Stuio にインストールしておく。
2. Visual Studio で ASP.NET MVC4 プロジェクトを開く。
3. NuGet Package Manager を使って、NuGet パッケージ: Twitter.Bootstrap を、そのプロジェクトにインストール。
4. 続けて、~/Views/Shared フォルダなどに、先にインストールしておいた "MVC 4 TwitterBootstrap Starter Layout Page (Razor)" アイテムテンプレートから、レイアウト用のビューを新規作成し、 ( たとえば _BootstrapLayout.cshtml などのファイル名で ) 保存する。
5. _ViewStart.cshtml を書き換えるなどして、いま新規で作ったレイアウト用ビューを使うようにする。
6. そのプロジェクトにインストールされている jQuery のバージョンを 1.7 以上の最新版にアップグレードしておく。
7. あとは順次、Twitter Bootstrap の機能に則って、.cshtml ビューをマークアップしていく。

こんな感じで、5分ほどあれば、最低限の対応ができる。

これらの手順を動画にまとめて公開した。



どうぞご参考まで。
　

AppHarbor + SQL Server + EF CodeFirst 開発 - EF4.1はOK、EF4.3はNG ではまる

背景

まずはじめに: AppHarbor とは?

今回のお題にある "AppHarbor" ( 発音は アップハーバーですね ) とは、サービスないしはそのサービス提供のサイト名。

Ruby on Rails 開発されている方なら、「ASP.NET 版 Heroku」といったほうが通じるだろう。

すなわち、ASP.NET のクラウドプラットフォームサービスである。

AppHarbor - .NET Cloud Platform as a Service
https://appharbor.com/

Heroku 同様、ASP.NET アプリのデプロイを、分散型バージョン管理システムの Git ( 発音はギットですね? ) を使って行う。

AppHarbor にサインアップし、アプリを作ると、そのアプリの Git のリポジトリが、AppHarbor 上に用意される。

この AppHarbor 上のリポジトリへ、ローカルの開発環境に作成した自分の Git リポジトリから Push することで、デプロイとなるのだ。

ビルドしたバイナリ類をアップロードする、いわゆる "発行" とは異なり、Git Push したプロジェクトソースコード一式から AppHarbor 上でビルドされ、ビルド成功すれば配置されるという仕掛けだ。

単体テストプロジェクト ( MSTest? ) がソリューションに含まれている場合は、その単体テストがすべてパスした場合にのみ、配置されるらしい（自分は試していない）。

自分が試した範囲では、今日現在、.NET Framework 4、ASP.NET MVC3 のアプリのデプロイ & 稼働を確認できている。

F# のプロジェクトもビルド & 配置成功した。

しかも、1worker のみであれば利用料が ￥0 だというのだ。
フリーミアム万歳である。

俗に言うレンタルサーバとは異なり、あくまでも PaaS。
有償になるが簡単にスケールアウト可能な感じだ。

よって、ファイルストレージの永続性は当てにならない。
Git Push してビルドが走るたびに ~/App_Data を含めたファイルシステムがリセットされるようだし、それ以外の理由でも、仮想マシンがリセットされることだろう。
そもそも有償プラン契約してスケールさせる場合は、ファイルシステムが各インスタンス間で共有されるのかどうかすら今の自分には未知である。

よってファイルベースのデータベース、SQL Server CE や SQLite は使えない。

しかし、Add-on として、なんと、SQL Server によるデータベーススペースが、20MB までの上限付きであるものの、￥0 で使える。

具体的な使い方は割愛。
もし希望があればコメントまで。

Entity Framework - Code First 開発

そして今回のエピソードのもうひとつの要素、Entity Framework による Code First 開発について。

Enity Framework は Microsoft が提供するデータアクセスライブラリである(以下、"EF" と略記)。

EF の ver.4.1 からは、「C# などで作成した "素のクラス" (Plain Old CLR Object, POCO) をモデルとして、モデルからデータベースを生成する」という、"Code First" スタイルの開発が可能になった。

Ruby on Rails では古くから(?)、このスタイルによる開発がサポートされていたと記憶している（rake migrate とかやりますよね?）。

詳しくは下記記事がわかりやすくてよいかもしれない。

@IT 連載：～ScottGu氏のブログより～ Entity Framework 4でコード・ファースト開発
Scott Guthrie 著 / Chica 訳 2010/07/20
http://www.atmarkit.co.jp/fdotnet/scottgublog/20100726codefirst/codefirst.html

Code First スタイルの開発では、データベースが存在しない初回起動のときに自動でデータベースが新規作成される。

さらにモデルクラスにプロパティ追加などの変更が発生すると、次にアプリが動くときにデータベースを作り直すようになっている。

"データベースを、いつ、どう作り直すのか" を指定する、"イニシャライザ" クラスが EF 標準でいくつか用意されている。

CreateDatabaseIfNotExists

データベースがない場合に新規作成する

DropCreateDatabaseAlways

アプリ起動時に毎回データベースを削除して新規作成し直す

DropCreateDatabaseIfModelChanges

もしスキーマ変更が発生していたらデータベースを削除して新規作成し直す

Global.asax の App_Start のタイミングなどで、お好みのイニシャライザを EF ランタイムに登録しておくわけだ。

なお、同じ EF でも、今日時点の最新リリース版 ver.4.3 からは、スキーマ変更に対するやり方が変わっているらしい。

まめしば雑記
Entity Framework 4.3 Beta 1 のコードベースマイグレーションを試してみた
http://d.hatena.ne.jp/shiba-yan/20120118/1326815828

AppHarbor では、EF 標準のイニシャライザは使えない

さてさて、AppHarbor とその Add-on の SQL Server を利用した、ASP.NET アプリをデプロイする場合、注意すべき点がある。

まず、データベースを削除(Drop)することはできない。

なんとなれば、それはレンタルされたデータベースであり、自分のものではなく、AppHarbor 彼らのものだからだ。

AppHarbor の管理画面上で SQL Server の Add-on をアプリに追加すると、所定のデータベースとその接続文字列が提供されるわけである。

また同様の理由から、データベースを新規作成することもできない。
繰り返しになるが、データベースが貸し出されるのであって、SQL Server そのものが貸し出されるわけではないからだ。

となると、EF 標準で付属しているイニシャライザは、軒並み利用できない。
いずれも、データベースを削除したり、新規作成したりする動作がともなうイニシャライザだからだ。

しかしこれでは、EF + Code First スタイルによる ASP.NET アプリを配置することが難しくなる。

EFCodeFirst.CreateTablesOnly を使え!

しかし朗報。

データベースは削除せずにテーブルだけ削除して作り直すイニシャライザが NuGet パッケージとして公開されている。

EF Code First (CTP5) IDatabaseIntializer that only recreates tables 1.0.2
EFCodeFirst.CreateTablesOnly
http://nuget.org/packages/EFCodeFirst.CreateTablesOnly

このイニシャライザを使わせてもらえば、データベースは削除せず、データベース内のテーブルを削除して作り直してくれるようになるのだ。

具体的な使い方としては、NuGet から上記パッケージをプロジェクトにインストールし、Global.asax の Application_Start 内でイニシャライザを以下の要領で設定しておけばよい。

using Devtalk.EF.CodeFirst;
...
protected void Application_Start()
{
  Database.SetInitializer(
    new DontDropDbJustCreateTablesIfModelChanged());

本題

ということで、AppHarbor 上でも、EF の ver.4.1 を使って、Code First な開発をエンジョイしていたある日。

ついうっかりというか、何というか、あまり気にも留めずに、AppHarbor に Push しているとある ASP.NET アプリにインストールされている EF のバージョンを、4.1 から 4.3 にアップグレードした。

すると、とたんに例外発生するようになってしまった。

例外の内容は以下のとおり。

InvalidOperationException:
The entity type EdmMetadata is not part of the model 
    for the current context.

なにが起きたのか?

ネット上で調べたところ、StackOverflow にスレッドができていた。

どうやた EF 4.3 からはスキーマ変更の追跡のやり方が変わり、EdmMeatadata テーブルが作られないから、ということらしい。

EF4.1 にダウングレードして終了

ということで、すったもんだあったが、EF を 4.1 にダウングレードして終息させた。

ダウングレードさせるには、いったん EF 4.3 を削除して、改めて EF 4.1 をインストール、という手順になる。

たぶん、GUI の NuGet Package Manager からはこの操作を行うのは難しいと思うので、Visual Studio 内の NuGet Package Manager Console を開き、コマンドで処置するのがよいと思う。

PM> Uninstall-Package EntityFramework -f
PM> Install-Package EntityFramework -version 4.1

なお、このとき、web.config 中にアセンブリバージョンのリダイレクタが記述されていた。

<configuration>
 ...
 <runtime>
  <assemblyBinding...>
  ...
   <dependentAssembly>
    <assemblyIdentity 
name="EntityFramework" 
publicKeyToken="b77a5c561934e089" />
     <bindingRedirect 
 oldVersion="1.0.0.0-4.1.0.0"
 newVersion="4.3.1.0" />
   </dependentAssembly>
  </assemblyBinding>
 </runtime>

この記述が残っていると、EF を 4.3 から 4.1 にダウングレードさせても、アプリは ver.4.3 のアセンブリを読み込もうとしてこけてしまう。

上記記述は削除しておくべし。
　

CLR/H 勉強会 - 勉強会申し込みサイトを作る - 第3回

先日2012年3月10日に開催された、第68回 CLR/H 勉強会に登壇させて頂いた。

今回はそのセッションのまとめを。

無料期間は終わっていた...orz

「Windows Azure で "無料" で運営する勉強会申し込みサイト」と題して、セッションを担当させて頂いたのだが、不勉強なもので、Windows Azure 導入特別プランはとっくに終わっていたのだった...。

現在は、Sインスタンス x 1個、および、SQL Azure x 1GB を 90日間無料で試用可能である。
また、この枠内を超えて使おうとすると、差分の従量課金が始まるのではなく、キャップしてくれるそうだ。

結局、今回のセッションは、この90日間お試しプランでやらせて頂いた。

永続化記憶域としての Google Docs スプレッドシート

で、当初プランでは

「Webロールは無料だけど、SQL Azure はじめ記憶域に従量課金される。
意地でも無料で済ませられないものか」

という、"無料" のテーマに意味も無く執念を燃やして（?）捻り出したのが、「Google ドキュメントのスプレッドシートに保存しよう」というアイディア。

先に書いたとおり、実は、今や、Windows Azure Platform 90日間試用プランでは、SQL Azure x 1GB 枠が付いているので、SQL Azure に保存しても良かったというオチが付いている。

結局 "無料" というテーマでは意義がなくなってしまった Google ドキュメントスプレッドシートを使うアイディア。

しかし、実際にやってみると、

• 基本、SSL でセキュア。
• チームでの共有やアクセス権の管理がしやすい。
• そのまんま、受付名簿として使える。

というメリットが見えてきて、むしろ Google ドキュメントスプレッドシート使って正解だったね！という結果オーライ的な結論である。

ただし、Google ドキュメントスプレッドシートも無敵というわけでなく、
処理速度は遅い。

後で紹介するライブサイトを試して頂くと、登録にずいぶん時間がかかるのを体感できるだろう。

この点は少々注意されたし。

GDataDB

Google ドキュメントスプレッドシートへの書き込みは、GDataDB というライブラリを使うと恐ろしいほど簡単。
NuGet パッケージマネージャ経由で、簡単に自分のプロジェクトへダウンロード & インストールできる。

使い方も、ドキュメントなど見ることなく、なんとなくインテリセンスをたどってるだけで、直感的に難なく使えた。

いちばん核心となるコードを披露すると、下記のとおり。

[HttpPost]
public ActionResult Index(Attendee attendee)
{
    // ここでスプレッドシートへ書き込み
    var gdbclient = new GDataDB.DatabaseClient(
        "(user name)", 
        "(password)");
    var db = gdbclient.GetDatabase("Attendees");
    var tbl = db.GetTable("Sheet1");
    tbl.Add(attendee);

    return RedirectToAction("Complete");
}

https://gist.github.com/2011416

スライド

セッションに使用したスライドは slideshare に公開しておく。

View more presentations from Jun-ichi Sakamoto

今回デプロイしたアプリの URL

今回デプロイした勉強会申し込みサイトは、下記 URL で絶賛稼働中（90日間限定であるが）。
http://clrhatnd.cloudapp.net/

実際にいろいろ登録頂いても結構。
ただし、後述のとおり、登録内容はインターネット上に公開されているので注意されたし。

保存先のスプレッドシートの URL

上記 Web サイトから登録した内容は、下記の Google Docs スプレッドシートに保存される。
https://docs.google.com/spreadsheet/ccc?key=0AlEGbHJFTDmydGtGSFB6UXg4NFc2YnN0WTVQZHBLa2c#gid=0

ソースコード一式

今回作成した ASP.NET MVC3 Web アプリのプロジェクト一式は .zip ファイルにアーカイブして、SkyDrive に公開しておく。
https://t.co/kJiyxUQO

用途があるかどうかは知らないが、再利用はどうぞご自由に。

Windows Azure は "レンサバ" ではない

ということで、どうにかやり遂げたセッションではあるのだが、一点、心しておくこととして、「Windows Azure は（俗に言う） "レンタルサーバー" ではない」ということがある。

今回のお題では、たしかに、"無料" にこだわったせいで単なる Web サーバー的な扱いをしてしまったけれど、Windows Azure の本質は、"クラウド" であることのはずだ。

@satonaoki さんのブログ記事から引用するが、「高可用性、耐障害性、自己管理、伸縮性のあるスケールアウト...」こそが、Windows Azure を活用することで得られるものだと思う。

単なる Web サーバーとしてみた場合、値段だけみたら ExpressWeb のほうが安いけど、Azure の本質は、ただの Web サーバーとは違うんだよ、ということで。

それでも無料にこだわるなら

それでも無料にこだわるなら "AppHarbor" という選択肢はどうだろう。

AppHarbor
https://appharbor.com/

AppHarbor とは ASP.NET をホストできる PaaS のひとつ。

.NET 版 Heroku とでも言えば、Ruby 界隈の人たちにも通じるだろうか。

そして、フリーミアム戦略なのか、\0 プランが用意されているのだ。

おまけに、たかだか 20MB までとはいえ、SQL Server も、この \0 プラン内で利用可能だという。

自分はまだ試したことはないが、とても気になる存在である。

最後に: Visual Studio でのライブコーディングは楽!

ということで、今年1月から@sandinist さんに始まった「勉強会申し込みサイトを作る」シリーズは、いちおうおしまいである。

前回は WebMatrix を使ってライブコーディングしたのだが、そのときと比べると Visual Studio を使ったライブコーディングの楽さ加減は、インテリセンスとコードスニペットのお陰で、もう比べものにならないくらい楽ちんであった。

Visual Studio のインテリセンスとコードスニペットは最強である。

もちろん、WebMatrix とて、"Remote View" など Visual Studio にはない強力かつ便利な機能を備えていたりするし、PHP での開発もできるので、なかなかどうしておもしろいプロダクトには違いない。

ただ、WebMatrix でのライブコーディングは、デモンストレーター泣かせだということだ。
　

ASP.NET MVC4 WebAPI サイトで認証・承認を行う

ASP.NET MVC4 WebAPI とは

この投稿を書いている時点ではまだβ版である ASP.NET MVC4。
この ASP.NET MVC4 の新機能のひとつとして、"WebAPI" という機能がある。

これは、ASP.NET MVC の仕組みを基盤とし、"GET api/values" というような RESTFull な HTTP 要求に対して、JSON や XML 形式でのリソース公開・更新を可能とする Web アプリを、容易に開発可能とするものだ。

より具体的には、ASP.NET MVC4 によって提供される ApiController という新顔のコントローラクラスがキモ。
1. この ApiController クラスから派生したコントローラクラスを実装し、
2. さらに HTTP の動詞 ("GET", "POST", "PUT", "DELETE"...) と同名のメソッドを実装することで、
上手いこと先述の "GET /api/values" といった HTTP 要求がこれらメソッドの呼び出しにマッピングされる仕掛けである。

メソッドの戻り値も ActionResult ではなく、シンプルにただの string だったり、IEnumerable で返すようになっている。
この戻り値は ASP.NET MVC4 WebAPI の仕掛けによって、JSON または XML に整形されてクライアント側へ返信される次第。

詳しくは、もちろん、公式サイトを参照されたし。
数分程度の短いビデオで、1トピックずつ入門することができてわかりやすい。
解説の音声は英語だが、コードを書いている画面を見ていれば充分理解できる。

Web API: The Official Microsoft ASP.NET Site
www.asp.net/web-api

ASP.NET MVC4 WebAPI の用途

さてこの新機能、"WebAPI" の用途だが、上記公式サイトのビデオなどを参照する限りでは、"Single Page Web Application" のように、クライアント側で jQuery や knockout.js といったライブラリを活用しサーバー側と XHR で通信してリッチな UI と体験を実現する、そのサーバー側実装とすることが主眼に置かれているようにも見える。

しかしながら、当然、この WebAPI 機能は、(同サイト上の) HTML ページ内の JavaScript から呼び出す用途に限らず、ほかのアプリケーションにリソースへのアクセスや機能を公開することにも使える。

ただし、GET アクセスのみならず、POST や PUT などのような、追加/更新/削除までも、誰彼無く匿名のクライアントに広く許す API 公開は、実運用上は考えにくい。
(GET だって、公開するリソースの内容によるが、多くの場合は匿名アクセスは禁じたいだろう)

ASP.NET MVC4 WebAPI を認証&承認で保護する

ということで、認証済みのクライアントからのアクセスのみ、WebAPI の使用を許可することを考えてみる。

方法1. Authorization 属性

ASP.NET MVC では、コントローラクラスに Authorization 属性を付けることで、匿名アクセスを拒否することができる。
ApiController に対しても、もちろん、これは通用する。

[Authorization]
public class ValuesController : ApiController
{
...

Authorization 属性のパラメータを指定すれば、特定のユーザーやロールに対してのみアクセスを許可する、といった指定も可能だ。

方法2. URL 承認

ASP.NET Framework の基幹部分として、UrlAuthorizationModule というものもある。
要求 URL に応じたアクセス許可を行うモジュールだ。
こちらも、Web Forms に限らず、MVC アプリに対しても普通に機能する。

例えば web.config に下記のように記述可能だ。

<configuration>
  <system.web>
    <authorization>
      <deny users="?"/>
    </authorization>
    ...

匿名ユーザーは "?" で表現される。
よって上記記述は、Web サイトのルート以下は、匿名ユーザーによるアクセスは拒否(deny)する、というわけだ。

URL 承認は、location セクションを記述したり、サブフォルダに配置された web.config で重ねて記述したりすることで、きめ細かく設定することが可能だ。

匿名ユーザーによるアクセスを拒否するとどうなるか

さて、上記いずれかの手段により、WebAPI への匿名ユーザーによるアクセスを拒否したとしよう。

すると、何が起きるか。

Visual Studio 11 Beta のプロジェクトテンプレートの、「Web API」テンプレートから作成したてのプロジェクトの場合、web.config の設定で、Forms 認証が有効になっている。

その結果、API への要求が、ログインページへのリダイレクト(HTTP 302 Found)となって返ってくるのだ。

ちなみに、「Web API」プロジェクトテンプレートにはログインページの実装は含まれていないため、最終的に HTTP 404 Not Found となっておしまいである。
もちろん、ログインページを実装し、適切にメンバシッププロバイダ等の認証まわりを配線・設定しておけば、これはこれで機能する。

人が Web ブラウザを介して API へアクセスを試みたのなら、このリダイレクトされたログインページで、予め構成しておいた然るべきユーザーによるアクセス名・パスワードを入力することで認証を済ませることができる。

しかし、先に書いたとおり、今回のテーマはほかのアプリケーションからの機械的なアクセスである。
ログインページたる HTML 文字列がアプリに返されたところで、その HTML をスクレイピングするのもおかしな話で、困ってしまうだろう。

HTTP 基本認証

ということで今回は、まず、HTTP 基本認証 (ベーシック(Basic)認証) で認証させてみることにした。

まずは NuGet Package Manager を使って HTTP Authentication Module をプロジェクトにインストールする。

なお、今日時点の HTTP Authentication Module の NuGet パッケージによるインストールには不足があって、インストール直後にそのままアクセスすると、web.config の構成エラーになってしまう。

web.config のどこかに、

<authentication mode="None"></authentication>

という行があるはずなのでこれを削除。
さらに、同じく web.config のまた別の箇所に、

<authentication mode="Forms">

という行があるはずなので、この mode 属性値を、Forms から None に書き換えておくこと。

ちなみに、この設定変更によって、ASP.NET 既定の認証モジュールは機能が無効化され、HTTP Authentication Module による認証機構のみが動作する次第。

以上で、まぁ、至極当然のことではあるのだが、普通に HTTP 基本認証にてユーザーを認証するようになった。

HTTP 基本認証であれば、たぶん、大抵の HTTP クライアントから、Credential 指定することでアクセス可能になるはずだ。

ただ、基本認証はそのままではユーザー名・パスワードが平文でネット上を流れることになる。
SSL 経由でのアクセスが前提となるだろう。

なお、HTTP Authentication Module は、HTTP ダイジェスト(Digest)認証にも対応はしている。
ダイジェスト認証であれば、非 SSL な通常の HTTP プロトコル上であってもユーザー名・パスワードが平文で流れることもなく、リプレイ攻撃にも耐えられる。

ただしダイジェスト認証を使うには、ASP.NET のメンバシップなどは使えず、HTTP Authentication Module 独自の構成セクションに独特のルールで MD5 ハッシュ値を記述しなくてはならない。

またどのみち、認証&承認によって保護したいリソースであれば、そもそも SSL でセキュアに保つことが前提になるだろう。
そんなわけで、実際のところ、ダイジェスト認証による認証は実用的ではないだろう。

認証方式を仕分ける(未達成)

以上で、いちおう、ASP.NET MVC4 WebAPI サイトを、HTTP 認証による認証にて、アクセス制御ができるようになった。
HTTP 認証なので、様々なプラットフォームから、認証可能なはずだ。

ただし、この方法では、サイトがまるごと HTTP 認証による認証となってしまう。

人が Web ブラウザを使ってページを開くときは Forms 認証、外部アプリケーションからの API への直アクセスに対しては HTTP 基本認証、といったように、アクセスの仕方に応じて認証方法を違えるのは、このアプローチでは限界がある。

実はすでに本件に関しては、@takepara さんがブログに記事を投稿されている。

ApiControllerで認証する際にログインページにリダイレクトしたくない
http://takepara.blogspot.com/2012/03/apicontroller.html

@takepara さんの作戦では、やはり何かしらの ASP.NET HTTP Module を実装するということになるのだが、その HTTP Module の実装において、要求処理完了時の通知を捕まえ、
1. 認証されていない、かつ、
2. 要求が API のアクセスである、かつ、
3. ログインページへのリダイレクトである
場合に、HTTP 401 Unauthorization を返すよう、FormsAuthenticationModule の処理結果を上書きするようになっている。

この作戦であれば、

a) 人が Web ブラウザを使ってページを開くときには Forms 認証が機能、
b) そうではない何かしらのアプリケーションが API への直アクセスをしたときには HTTP 401 Unauthorized が返る
というように、ちゃんと仕分けされるようになる。

なお、@takepara さんのブログ記事では、API に直アクセスするアプリケーションがどのように認証をするのか、というところまでは具体論はだされていない。

とはいえ、HTTP 401 を返すところで HTTP 応答ヘッダにいくつか加えれば、ブラウザに対する基本認証の要求を発動することができるし、とにかく重要なポイントは十二分に示唆されている。

Forms 認証にまかせるかどうかの判定方法についても、現在の要求のハンドラの型を見るやり方の他、Twitter 上ではMVC コントローラに対するフィルタにて、要求コンテキストに対して何かしらのフラグを立てる方法についても言及されている。

https://twitter.com/#!/takepara/status/175748244490563586

この投稿を読まれた方は、@takepara さんのブログ記事は是非ご一読を。

ということで、この投稿では、認証方式を場合や状況に応じて仕分けるところまでは完成に至っていない。
とはいえ、ゴールにたどり着くまでの重要なヒントはいくつか示唆できたのではないかと思う。

ご意見・ご質問は、この投稿にコメント頂くか、@jsakamoto までどうぞ。
　

jQueryMobile+PHP+MySQL+WebMatrix+ExpressWebで作成・公開する勉強会申し込みサイト

先日 2/11(土) に開催された CLR/H 第67回 勉強会。

Web 系で固められた全 4 セッション中、3セッション目を担当させて頂いた。

諸事情により大変遅くなったが、使用したスライド資料に、いくつかネット上のリソースの URL を書き加えたものを slideshare に公開した。

View more presentations from Jun-ichi Sakamoto

以下、いくつか補足を。

HTML5 Forms Validation を使わなかった理由

HTML5 からは、input 要素に required 属性を書いたり、type="email" などとすることで、入力必須や e-mail書式の入力検証が機能するようになる。

にも関わらず今回のセッションでは、あえて jQuery Validate を使ったのは、手持ちの Android 2.2 ケータイ標準のブラウザで試したところ、HTML5 Forms Validation が機能しなかったから。

Windows7上の Firefox9 や Google Chrome 16 ではちゃんと機能したのだが。

ということで、HTML5 Forms Validation に頼ることはあきらめて、jQuery Validate の利用に走った次第。

なお、jQuery Validate による入力検証結果を、jQuery Mobile のダイアログで表示させるサンプルにもなったので、まぁ、これはこれでよかったのでは、と思っている。

jQuery 類のロードに CDN を使わなかった理由

単純に、セッション会場のネットワーク回線をなるたけ信頼しないことにしたからである。

なので、通常は、jQuery などの JavaScript ファイルやスタイルシートなどなどは、CDN 経由でロードするようにしたほうがいいであろう。

プロジェクトのソース

Zip 圧縮して SkyDrive に置いておく。
https://skydrive.live.com/?cid=5dd1e083875ff918&id=5DD1E083875FF918%211128#

サンプルコード的なものにすぎないので License とか適当でいいです。
ご自由にどうぞ。
（困るなら、Ms-PL か CPOL のお好きなほうで）。

WebMatrix v2βがインストール済みのWindows OS 上で、上記 Zip ファイルを適当なフォルダに解凍、そのフォルダを右クリックすると、「Open as a Web Site with Microsoft WebMatrix」というメニュー項目があるはずなので、これを選べば、WebMatrix で開くことができる。

なお、MySQL のデータベースは別途ご自身で用意しないと、すべての機能は動作しないのでご注意を。

オープンソースカンファレンス 2011 のセッションビデオ

実は今回のセッションも Microsoft Expression Encoder Screen Capture で PC 画面を動画記録していたのだが、大変残念ながら Expression Encoder Screen　Capture が途中でクラッシュしてしまった。

代わりと言っては何だが、昨年6月に開催されたオープンソースカンファレンス 2011 Hookaido でも、WebMatrix ( ただし v1 ) を利用しての、jQuery Mobile によるモバイルサイトのライブコーディングをやっていたので、そのときの練習ビデオを再録する。

CLR-H-59-OSC11Do.wmv
http://t.co/tVC06s9

謝辞

最後になったが、当日のセミライブコーディングのこのセッション、ご参加頂いた皆様の支援で、どうにか時間内にデプロイにまでこぎ着けた。

コーディング中のタイプミスをご指摘頂けなければ、あのセッションはかなり残念な形で終わっていたと思う。

この場を借りて御礼申し上げたい。

　

[書評] Windows Azure Platform 開発入門

Windows Azure Platform開発入門 (MSDNプログラミングシリーズ)

WINGSプロジェクト / 日経BP社

「Windows Azure Platform 開発入門」を読んだ。

その感想を。

入門には違いない、が...

本のタイトルにある「入門」の文字であるが、たしかに、まだ本格的には Windows Azure Platform をバリバリ活用できていない自分にとっては、かなり最適な "入門" 内容だったと思う。

とはいえ、本書を読破するのであれば、ASP.NET、あるいはせめて、.NET Framework について習得していないとついていけない感じがした。

あくまでも .NETer に向けての "入門書"、すでにオンプレミス環境である程度のスキルや経験がある人に向けて、オンプレミスの "重力井戸" からの解放を誘ってくれるガイドとしての入門書である印象である。

わかりにくかったサンプルコード

ストレージサービスの解説において、けっこうな量のサンプルコードが掲載されている。

しかし少々このサンプルコードが読みにくかった。

例えば P.135 あたりからキューサービスの説明が始まり、キューサービス経由の指示によって Worker ロールに画像ファイルのサムネールを生成させるサンプルコードが掲載されている。

ただ、どうも全体像を俯瞰しにくい。

サンプルのコーディング過程をつらつらと平板に書かれている印象で、そのコードはキューサービスの説明としてのキモなのか、それともあくまでサンプルアプリとして成立させるために必要なだけのコードなのか、区別というか、重み付けというか、それが見えてこない感じがしたのだ。

なにも、文章の書き方がーという話でなく、単純に見出しの外観 ― フォントサイズとかインデントとか ― を工夫してメリハリつけるだけでも随分違ったのかもしれないのに、と思ったりしてしまった。

まだある。

P.127 にもサンプルアプリの説明があり、Web フォームにポトペタで貼り付けたコントロールのプロパティを次のように設定せよ、との記述があるのだが ― ユーザー名を入力するテキストボックスの Width プロパティを 200px に設定せよ、とあるのである。

その 200px はテーブルサービスを説明するにあたり重要なのか?

Web フォームに配置したコントロールについて、ことごとこの調子。
ID=AddButton のボタンのキャプションを「追加」とせよ、などなど。
それ、図にちゃんと見えてるじゃん。

うーん....。

網羅度は素晴らしい

などと、サンプルアプリの解説には少々戸惑いを感じたものの、Windows Azure Platform を構成する各種テクノロジの網羅度は、さすがに書籍らしくなかなかのものである。

なんといっても

ブチザッキが読めるようになった

のだ。

ブチザッキとは、@kamebuchi さんが書かれているブログサイト http://buchizo.wordpress.com/ のタイトル。

ここのブログ記事は Windows Azure Platform を活用するにあたっての貴重な情報源なのだが、略語があったり、ある程度 Windows Azure Platform の構成についての理解が前提だったり（そりゃそうだ）で、自分にはまだまだ理解が及ばないこともあったのだ。

それが本書を読破して、ひととおり Windows Azure Platform を構成する各パーツを俯瞰したことで、ブチザッキのあの記事この記事が、以前よりすんなり頭の中に入ってくるようになった。

PowerShell による管理・操作も

そして個人的によかったのが、PowerShell による管理・操作にもページを割いていること。

実際、別にクラウド環境とかに限らずどんな運用でも、本格的にまわすとなると、シェルスクリプトによる自動化は、退屈な作業の一掃のためにも是非ともとりくみたい点である。

その点、PowerShell からこうやることでアプリケーションを配置したり起動したり削除したりできますよ、といった事例が書かれているので、本格運用の見通しがずいぶんと明るくなった。

「入門とは言うけれど、.NETer 向けの入門書ですよ」と先に書いた。
しかし、それと引き替えに PowerShell の章などにページを割くことによって、

入門時だけでなく本格運用のそのときまで

ガイドしてくれるのが本書なのかもしれない。

最後に。

Kindle で読めるともっといいんですけど。

自炊?
いやそんなの面倒だし。

でも Kindle DX は日本語版ないし、ねぇ。