[Silverlight] MEF を使って XAP を動的に読み込む その1

前の記事で Silverlight 4 では MEF (Managed Extensibility Framework) を使って XAP を動的に読み込めばいいんじゃないかと書きましたが、せっかくなのでサンプルを紹介しときます。
内容自体は VSUG Day 2010 Summer 大阪 のセッションで紹介したのとだいたい同じだったりしますが。

まず、MEF っていうのはプラグインといった仕組みを実現するフレームワークだと思ってもらえばいいんじゃないかと思います。結構いろいろな機能があるため全体としてはそれなりにややこしくなっていますが、基本的な部分を使うだけならば、いくつかの約束ごとを覚えればなんとかなる感じです。
私も全体をきちんと理解出来ているわけではありませんが、単純な例と XAP を動的に読み込む例の 2回に分けて MEF の概要を紹介してみます。
なお、MSDN ライブラリの解説は 「Managed Extensibility Framework の概要」 などにありますから詳しい話はそちらを参照してみてください。（残念ながら MSDN ライブラリの解説もすべてを網羅してるわけではありませんが）
ちなみに、MEF は 「メフ」 と発音されることが多いみたいです。（Microsoft の人のチュートリアル動画を見てたらそう発音してた）

では、まず手始めに単純な例。
（C# で書いてますがもちろん VB でも同じです）

なお、Visual Studio 2010 のソリューションを http://cid-ca42d76a68f54d16.office.live.com/self.aspx/Public/Sample/MefSample.zip に置いておきます。
ZIP ファイル内の MefSample01 フォルダが以下の例です。

Visual Studio 2010 で Silverlight 4 プロジェクトを作ります。
MEF の多くは System.ComponentModel.Composition.dll に含まれてますので、まずはこれを参照設定します。
続いて以下のような内容の Person.cs を追加。

using System.ComponentModel.Composition;

namespace MefSample01
{
    public class Person
    {
        public Person()
        {
            this.Name = "MEFサンプル";
        }

        [Export("PersonName")]
        public string Name { get; set; }
    }
}

次に Silverlight のメインページのクラス （MainPage.xaml.cs） を以下のように書き換えます。

using System.ComponentModel.Composition;
using System.ComponentModel.Composition.Hosting;
using System.Reflection;
using System.Windows;
using System.Windows.Controls;

namespace MefSample01
{
    public partial class MainPage : UserControl
    {
        [Import("PersonName")]
        public string personName;

        public MainPage()
        {
            InitializeComponent();

            var catalog = new AssemblyCatalog(Assembly.GetExecutingAssembly());
            var container = new CompositionContainer(catalog);
            container.ComposeParts(this);

            MessageBox.Show(this.personName);
        }
    }
}

これで実行してみると実行直後に “MEFサンプル” という内容のメッセージボックスが表示されるはずです。
このメッセージボックスは personName フィールドの内容を表示してるんですが、一見すると personName フィールドに内容をセットするコードが見当たりません。もちろん、本当にセットされていなかったら null 参照で例外が出ちゃうので、どこかではセットされてるんですが。
それをやってるのが

var catalog = new AssemblyCatalog(Assembly.GetExecutingAssembly());
var container = new CompositionContainer(catalog);
container.ComposeParts(this);

この 3行です。そして、この 3行が MEF のキモと言っていい部分です。

まず 1行目。ここでカタログを作っています。カタログというのは 「エクスポートしたいもの」 の所在を指定するもの、と思ってもらえばいいんじゃないかと思います。上のサンプルでは AssemblyCatalog を使って今現在実行中のアセンブリをカタログとして指定しています。（要するに自分自身をカタログに指定しているってことです） カタログには、AssemblyCatalog の他にも、ディレクトリの中のアセンブリを探してくれる DirectoryCatalog、XAP をダウンロードしてくれる DeploymentCatalog などがいくつかの種類があります。
次の 2行目でコンテナを作っています。
そして、3行目でこのコンテナに対して自分 （this） のインポートを解決するように依頼しています。
この 2行目と 3行目はお約束と思ってもらっていいんじゃないかと思います。

この 「カタログ作って、コンテナにカタログ入れて、そのコンテナにインポートの解決を依頼」 というのが MEF のキモなわけですが、もうひとつのキモがインポートとエクスポートの指定です。

MainPage クラスの personName フィールドには Import 属性が、そして、Person クラスの Name プロパティには Export 属性が付いています。
MEF のインポートの解決とは、

• container.ComposeParts() メソッドに渡された引数のオブジェクト （今回の場合は this） の中の Import 属性が付いているものを探す。
• コンテナの中の Export 属性が付いているものを探す。
• 名前と型が一致するものがあったらエクスポート側から値を取り出し、インポート側にセットする。

ということです。
ちなみに、エクスポート側から値を取り出し、インポート側にセットするというのは、具体的に書くと

var person = new Person();
this.personName = person.Name;

というのと同じことが実行されています。

あと、MEF のサンプルを見ていると、上記の 3行が

var catalog = new AssemblyCatalog(Assembly.GetExecutingAssembly());
CompositionHost.Initialize(catalog);
CompositionInitializer.SatisfyImports(this);

こんな感じに書かれているものがあります。
これは自分で明示的にコンテナを作らずに、MEF に内蔵されているデフォルトのコンテナを使っているということみたいです。ただ、デフォルトのコンテナを使うことにどんな利点があるのかは私は良くわかってません。
ちなみに CompositionHost などを使う場合は System.ComponentModel.Composition.Initialization を参照設定する必要があります。

この例ではプロパティを Export しましたが、クラスを Export することもできます。
次の例ではクラスを Export し、XAP をコンテナとして指定して動的に XAP を読み込むようにしてみます。

「[Silverlight] MEF を使って XAP を動的に読み込む その2」 に続きます。

[Silverlight] Silverlight アプリケーションの起動時に関するベストプラクティス

「Silverlight Startup Best Practices」 より。
Silverlight アプリの起動を速くするために気をつけるべきことがまとめられていました。
なかなかおもしろかったのでざっと和訳してみました。

それにしても Info-ZIP で圧縮しなおしたらそれだけで 20% くらい小さくなるとか、ちょっと驚き。というか、起動時間を気にしなくちゃいけないくらいの規模のアプリにとっては 20% って大きいよな。
あと、紹介されている Tim Heuer 氏のビデオ 「Loading Dynamic XAPs and Assemblies」 ですが、これは Silverlight 2 のころの内容です。Silverlight 4 では MEF (Managed Extensibility Framework) を使えばいいんじゃないかと思います。

では、以下和訳。Introduction と Conclusion 以外はだいたい訳してますが、一部はしょったり適当だったりします。あと、そもそもそんなに英語力があるわけじゃないので間違ってるところもあるでしょう。なので、きちんとした内容は原文を見てください。

---- ここから和訳したもの

■ ダウンロードサイズを最小にしろ
起動する前にまずはダウンロードしなくちゃいけないわけだから、ダウンロードサイズは起動時間に直結する。複数の XAP ファイルに分けることができないか検討すべし。メイン画面に必要な部分と中核となる機能の部分だけを最初の XAP ファイルに入れておく。Tim Heuer 氏のビデオ 「Loading Dynamic XAPs and Assemblies」 にこういったやり方の詳細が解説されている。

他にもすばらしい方法がある。XAP ファイルを圧縮するんだ。Silverlight の XAP ファイルは ZIP ファイルをリネームしたものだけど、Silverlight 4 の XAP 圧縮アルゴリズムは最高のものってわけじゃない。最適な圧縮アルゴリズムの物を使って ZIP 圧縮しなおせばダウンロードサイズを 20% くらい （最高では 70% くらい） 小さくできるかも。詳細は David Anson 氏の 「Smaller is better!」 を参照。

■ ネットワーク I/O を待つな
これは起動中にしちゃうことの中でもっともリスキーなことのひとつ。ネットワーク I/O の待ち時間は一定ではない。Web サービスを呼び出したりネットワークからデータを取り出したりするとき、その要求は 2ミリ秒で済むかもしれないし、2秒かもしれないし、2分かもしれないし、それ以上かもしれない。UI を表示する前にデータが必要な場合は画面を表示しようがないかもしれない。一番いいのは、起動時間を決めるのがネットワーク接続の速さだってことに賭けちゃうってことかな。 せいぜい、アプリの起動時間を決定づけるネットワーク速度がそこそこ速いということに期待するぐらいしかなかろう [訳注: 原文は “At best, you are gambling on the speed of your network connection to determine your startup time.” こんな訳でいいのかまったく自信なし。いいとしたら、当然これは文章通りの意味ではなく、「だからそんなことにならないようにうまいこと考えろ」 ということだと思われ] [8/24 追記: コメントにてやねうらおさんに正しい訳を教えていただいたので修正。ただ、原著者さんは 「だからそんなアプリの作りにはするな」 ということが言いたいのであろうことは変わりません]

■ ディスク I/O を最小にしろ
ディスクからロードするデータが増えれば待ち時間も増える。

・起動時に読み込むアセンブリを少なくする
ディスク I/O を少なくするにはアプリのロード時に読み込まれるアセンブリを少なくすることだ。Silverlight では、CLR の just-in-time (JIT) コンパイラがあるメソッドに最初にアクセスしたときに、そのメソッドを含むアセンブリが読み込まれる。例: 単純な “Hello World” アプリに DataGrid を加える。すると DataGrid が含まれている System.Windows.Controls.Data.dll が起動時に読み込まれるようになる。Sysinternals の VMMap を使えば読み込んでいるアセンブリとそれぞれのメモリ使用量を見ることができる。[訳注: 原文には WMMap の使用例のスクリーンショットあり]

アセンブリはそれの型のどれかが使われるまで読み込まれないので、2つのやり方を覚えておくといい。

1. スタティックメンバーはアセンブリの読み込みの依存関係に強く影響する。たとえば、DataGrid をスタティックフィールドに持つようなコードがあると、起動時にそのスタティックフィールドを初期化するために System.Windows.Controls.Data.dll が読み込まれる。これは System.Lazy<T> を使えば回避できる。詳細は、MSDN の 「Lazy の初期化」 などを。
2. 必要になったときにアセンブリが読み込まれるようにメソッドを書き直す。
   [訳注: 以下、とりあえず原文のままコード例をコピペ。コンストラクタで生成するんじゃなく OnLoaded で生成するようにすれば起動時にアセンブリが読み込まれなくなる、ということだとはわかる。MehodImplOptions.NoInlining でインライン展開されないようにするってのはどういう意味なんだろ？インライン展開されても OnLoaded に組み込まれるだけだと思うんだけど。”if (b == true)” もわからないな。というかこれって最適化されたら if 文自体が消されちゃうと思うんだけど。]

private void OnLoaded(object sender, RoutedEventArgs e)
{
    bool b = true;
    if (b == true)
    {
        // Instead of this, refactor into a method, this will
        // prevent System.Windows.Controls.Data.dll where
        // DataGrid lives (and which is not one of the core
        // SL assemblies) from getting loaded.
        //   DataGrid myDataGrid = new DataGrid();
        //   LayoutRoot.Children.Add(myDataGrid);
        AddDataGrid();
    }
} 
//prevent in-lining if method implementation is too small.
[MethodImpl(MethodImplOptions.NoInlining)] 
public void AddDataGrid()
{
    DataGrid myDataGrid = new DataGrid();
    LayoutRoot.Children.Add(myDataGrid);
}

・データの読み込みを減らす
最初の表示に必要無いコンテンツやコンフィギュレーションデータの読み込みを避ける。例: フラットファイルにメッセージデータを保存している email クライアントがある。この場合、メイン画面が表示されてからメッセージデータを読み込むようにすべき。そして、ロード中アニメーションを表示するか、もしくは、操作可能であることを示すようなものを表示する。
他の例: 拡張可能なプラグインモデルのアプリケーション。この場合、メイン部分を表示してから各プラグインを読み込む。そうすれば無作法なプラグインによって起動に余計な時間がかかるのを防ぐことができる。

■ テンプレートとスタイルの最適化
アプリの初期表示が定義されているいくつかの XAML を起動時にパースする必要があるのは避けられない。だから、起動時間のために初期表示に使われる XAML を最適化すべき。

• 要素数を最小に。ビジュアルツリー上の要素数がパースの時間に影響する。XAML をリファクタリングしたとき、無意味になった要素を見つけることがある。子がひとつしかなく、意味あるプロパティを持たないような Grid なんかがいい例だ。こういう要素はとっとと削除すべき。
• 死んだ XAML を削除しろ。スタイルやツリーの一部に使っていないものがあったら削除するように！見えもしないし使うこともないものをなんで取っておく？
• ユーザーコントロールにはテンプレートを使え。ユーザーコントロールはインスタンス化のたびにパースされるが、テンプレートは最初の一度だけパースされる。特に、同じスタイルのセルが何百もあるような DataGrid では DataGrid セル・テンプレートを使うことがとても重要。もしセルにユーザーコントロールが使われていたら何百回も同じ XAML をパースすることになるがテンプレートを使っていれば一回で済む。
• プロパティにデフォルト値をセットするな。Opacity=”1” だとか、値なしの RenderTransform をセットするだとかいうような。デザインツールの中にはこういった嫌な癖を持つものもあるから出力結果を監視した方がいいかもしれない。我々もこの点がもっと良くなるように作業していく。

■ スプラッシュスクリーンの使うか検討する
起動時に関するベストプラクティスをいろいろ実装しても、まだ機敏さが足りないと思ったらどうする？そんなときはスプラッシュスクリーンを使うことを検討すべき。Silverlight アプリはデフォルトのスプラッシュスクリーンをもってる。（球体がくるくる回るやつ） このデフォルトのスプラッシュスクリーンを変更すれば起動時間が早くなったように見えるし、自分のブランドをすぐにユーザーに見せることができる。スプラッシュスクリーンを置き換える方法については 「方法 : Silverlight の単純なスプラッシュ スクリーンを定義する」 を参照。

[F#] F# の開発環境

「Announcing the F# 2.0 Standalone Tools Update (for .NET 2.0, 4.0 and other CLI Implementations)」 より。
（私自身は F# はまったく触ったこと無いんですが）

どうやら F# のスタンドアローンの開発環境の新しい CTP がリリースされたようです。
以前からある “Visual Studio 2010 Shell” を入れておいて、今回リリースされた “the F# 2.0 August 2010 MSI” を入れると F# が使えるようになるみたい。よくわかってませんが、要するに Visual F# Express Edition みたいなもんだと思えばいいのかな？

ちなみに、一番下に 「Visual Studio 2010 Professional かそれ以上ですでに F# を使ってる人は気にする必要は無い。今回のでサポートされている F# のバージョンは今までのと同じだ」 というようなことが書かれてますのでそういうことみたいです。

[C#][VB][C++] All-In-One Code Framework Coding Standards

All-In-One Code Framework というサンプル集は有名ですが、その All-In-One Code Framework を作っているプロジェクトチームが C#、VB、C++ でコードを書く上でのコーディング規約をまとめたそうです。
http://1code.codeplex.com/releases/view/50431

ちょこっと中身を見てみましたが、コメントはこう書くべしとか、”{“ の位置はここにすべしとか、命名はこうすべしとか、よくあるコーディング規約です。ただ、それだけじゃなく、例外の使い方とか Dispose パターンの使い方とか P/Invoke を使うときの書き方とか結構突っ込んだところまで書いてあります。

なお、「VC++, C#, VB.NET Coding Guideline of All-In-One Code Framework」 によると、継続的に進化中なのでもっといい方法とか追加すべきことがあったらメール頂戴とのこと。（ガイドラインにも同じことが書いてありました）

いいなぁ、これ。日本語版なんて出ないんだろうなぁ。

[Win7] こんなショートカットがあったのか

「Windows 7 Tip: Aero Snap Feature and Multiple Monitors」 より。
Windows 7 に標準であるキーボードショートカットについてです。

アクティブウインドウを左にやったり右にやったりするショートカットなんですが、マルチディスプレイのときは隣のディスプレイに移動するようになってます。

• Windows キー + 左カーソルキー　…　アクティブウインドウが左側に張り付く。すでに左側だったときは左隣のディスプレイの右側に行く。
• Windows キー + 右カーソルキー　…　アクティブウインドウが右側に張り付く。すでに右側だったときは右隣のディスプレイの左側に行く。
• Windows キー + 上カーソルキー　…　アクティブウインドウが最大化する。すでに最大のときは元に戻る。
• Windows キー + 下カーソルキー　…　アクティブウインドウがアイコン化する。

紹介されているのは以上ですが、ひょっとして他にもあるかも、と思いやってみたらみつけました。

• Windows キー + Shift キー + 左カーソルキー　…　アクティブウインドウが左隣のディスプレイに移動。
• Windows キー + Shift キー + 右カーソルキー　…　アクティブウインドウが右隣のディスプレイに移動。

おぉ、こんなのあったのか！

って、改めて見てみたらちゃんと 「Windows 7 のキーボード ショートカット集」 ここにも載ってるんですけどね。

[LINQ] CompiledQuery を使ったときの LINQ のパフォーマンスの注意点？

「Potential Performance Issues with Compiled LINQ Query Re-Compiles」 より。
何度も実行するクエリーは CompiledQuery を使ってキャッシュするとパフォーマンスを向上することができます。しかし、気をつけないとリコンパイルされてしまってパフォーマンスに影響する場合があるので注意、というような内容です。
紹介されているクエリーはこんな感じ。

static Func<NorthwindEntities, string, IQueryable<Customer>> compiledCustQuery =
   CompiledQuery.Compile((NorthwindEntities ctx, string start) =>
   (from c in ctx.Customers
    where c.CustomerID.StartsWith(start)
    select c));

これを

var qryAnyCust = compiledCustQuery(ctx, "C");
if (qryAnyCust.Any())
{
    var qryCust = compiledCustQuery(ctx, "C");
    qryCust.ToList().Count();
}

このように使う場合の問題点が紹介されています。
Any() を使って 「該当データが存在すれば○○、しなければ××」 みたいなことをする場合ってことですね。
（2回 compiledCustQuery を呼び出さずに 1回にまとめられるだろ、というのは横に置いておいて。あくまで例ってことで）
compiledCustQuery がコンパイル済みクエリーなんですが、Any() を使うとリコンパイルを引き起こすそうです。
ではどうするんだ、というと、

static Func<NorthwindEntities, string, bool> compiledAnyCustQuery =
   CompiledQuery.Compile((NorthwindEntities ctx, string start) =>
   (from c in ctx.Customers
    where c.CustomerID.StartsWith(start)
    select c).Any());

if (compiledAnyCustQuery(ctx, "C"))
{
    var qryCust = compiledCustQuery(ctx, "C");
    qryCust.ToList().Count();
}

こんな風に Any() の呼び出しまで含めたコンパイル済みクエリーを別に用意してやればよい、とのことです。
これで 9ms だったものが 6ms と 33% も速度が向上したそうです。

と、ここまで読んで、ちょっと疑問が。。。
リコンパイルされるってほんと？

もともと、LINQ to SQL の仕組みは

コンパイル時にやること
LINQ 構文を本来の拡張メソッド （Queryable.Where() とか Queryable.Select() とか） に置き換えてそれらを呼び出すコードを作るだけ。
ちなみに、Queryable.Where() の引数はラムダ式で書かれた条件式が式木 （Expression Tree） に変換されたものが渡されるようなコードができあがる。これは引数の型が Expression<Func<TSource, bool>> とかになってるのでコンパイラがラムダ式を Exression 型へと暗黙の型変換してくれるから。Select() とかも同じ理屈。

実行時にやること
LINQ to SQL プロバイダが Where() やら Select() やらに渡された式木を見つつ SQL 文を構築する。
そして、実際に SQL を実行して結果を得る。

のはず。
これは CompiledQuery クラスを使っていても基本的には同じ。
ただ、実行時の遅延実行のタイミングが微妙に変わります。
というか、私もきちんとは知らなかったので SQL Server のトレースログを取って確認してみました。
そうしたら以下のようになってました。

var qryCust = compiledCustQuery(ctx, "C");
    ↑この行を実行した時点で SQL 文が構築される。
     （SQL 文はキャッシュされて 2回目以降は使いまわされる）
     また、この時点で SQL Server に接続し、SQL 文が発行される。

foreach (var row in qryCust)   ←データの取得はこの段階で行われる。
{
    
}

このように CompiledQuery.Compile() メソッドで取得したデリゲートにアクセスした時点で SQL 文が構築され、SQL Server に接続し、SQL 文が発行されていました。
ちなみに、CompiledQuery を使っていないときは foreach などで最初に結果セットにアクセスしたときに SQL 文構築、SQL Server への接続、SQL 文の発行が行われます。

ということを踏まえて Any() の話。
紹介した記事では Any() を呼びだすとリコンパイルされる、となっていますが本当でしょうか？
実際に DataContext.Log や SQL Server トレースログを見てみましたが、Any() を呼び出す時点では SQL 文の構築らしきことは何もされていません。

var qryAnyCust = compiledCustQuery(ctx, "C");
    ↑この行を実行した時点で SQL 文構築、SQL Server 接続、SQL 文発行。

if (qryAnyCust.Any())   ←SQL 文を再度発行なんてことはしていない。
{
    
}

上で示した CompiledQuery の遅延実行の流れとまったく同じですが、このように Any() を呼び出す前の段階で SQL 文の発行までは終わってました。Any() は IQueryable を通じて結果セットにアクセスしてるだけにしか見えません。

ですから、Any() を使うとリコンパイルされるということは無いんじゃないかと思います。

では、Any() まで含んだ CompiledQuery を用意してやると 33% も速くなったという話。
これは、試してみればわかりますがそもそも構築される SQL 文が違います。

SELECT
    (CASE
        WHEN EXISTS(
            SELECT NULL AS [EMPTY]
            FROM [dbo].[Customers] AS [t0]
            WHERE [t0].[CustomerID] LIKE @p0 ESCAPE '~'
            ) THEN 1
        ELSE 0
     END) AS [value]

Any() が付いてるとちゃんと 「条件に該当するものが 1件でもあれば 1、なければ 0 を返す」 という SQL 文を作ってくれます。実行している SQL 文が違うんですから、そりゃ速度も違うでしょうし、普通に考えてこっちの SQL 文の方が効率いいでしょうね。
しかし、Any() があるとこんな SQL 文を作ってくれるなんて、ほんとに LINQ to SQL のプロバイダーはよくできてるなぁ。

あと、紹介した記事の後半に IQueryable の代わりに IEnumerable を使うという例が紹介されていますがこれはよくわかりません。
IEnumerable を使うと一気にメモリに取り込むからそれに Any() を適用してもそれなりに速い、ということみたいですが、私が試してみたところでは IQueryable の場合とほとんど変わらないような感じでした。理屈的に考えても、結果セットの大きさが小さい場合はあまり変わらないように思うんですが。。。

■ 結論
Any() を使ったからといってリコンパイルされることは無いですし、遅くなるということもありません。（と思う）
けど、CompiledQuery で取得したものに後から Any() を付け足したりすると非効率になる場合があるのは確か。きちんと Any() まで含んだクエリーを CompiledQuery にした方が効率が良くなる場合が多い、とは言えると思います。まぁ、どっちの方がいいかは、構築された SQL 文を見てみないとわからないって場合もあるとは思いますが。

一応書いておきますが、ずっと Any() を例にしてますが、もちろん他のメソッドでも同じです。Any() が特別なことをしているというわけではありません。

[Silverlight] Zoom.it

Microsoft Live Labs の Seadragon が Zoom.it になったそうです。
（正確には Seadragon の Deep Zoom フォーマットを作ってくれるサービスが Zoom.it になったということかな？）

Zoom.it は Web 上のイメージを Deep Zoom フォーマットに変換して公開できるようにしてくれるサイトです。
JPEG や PNG といった画像の URL を与えるとそれを Deep Zoom フォーマットにしてくれます。また、Web サイトの URL を与えるとその Web サイトのイメージを画像化して Deep Zoom フォーマットにしてくれます。
表示には Silverlight が使われています。ちなみに、Zoom.it のサーバー側は Windows Azure が使われているそうです。

試しにこのブログ自体を Create して埋め込んでみました。
（えらく縦長に。そりゃ、このブログの URL をそのまま渡せばそうなるわな。ちなみに、Create には数分間くらいかかりました）

Zoom.it は API も公開しています。
この API とは、URL を与えるとそのイメージを Deep Zoom フォーマットに変換してくれる、というものです。

「API Quickstarts - JavaScript」 には、jQuery で Zoom.it を呼び出して Deep Zoom フォーマットに変換、その結果の URL を Seadragon Ajax Viewer に与えて Ajax で表示するというサンプルがあります。
また、「API Quickstarts - Silverlight」 には、Silverlight helper library を使って Zoom.it で Deep Zoom フォーマットに変換、その結果の URL を DeepZoomImageTileSource に渡してそれを MultiScaleImage.Source にセットして表示するというサンプルがあります。ちなみに、DeepZoomImageTileSource や MultiScaleImage は Silverlight の標準クラスです。
（Zoom.it だったり Seadragon だったり Deep Zoom だったりと、同じようなものが違う名前で呼ばれていてちょっとややこしい）

ところで、以下のサイトって 70ギガピクセルの画像を Silverlight で表示してるんですが、これって Deep Zoom なのかな？
http://70gigapixel.cloudapp.net/index_en.html

[IE9] ついに ActiveX Scripting Engine がお払い箱に！

HTML5, Modernized: Fourth IE9 Platform Preview Available for Developers
この記事を見てて知りました。

記事の前半は 「IE9 のプレビューでは SVG、canvas、video、audio、text がハードウエアアクセラレーションされてめちゃ速になったよ」 というような話ですが、中程に 「Native JavaScript Integration」 なんていう話が。

今までの IE は JScript や VBScript のエンジンを内蔵しているわけではなく、別に存在するこういった言語を解釈・実行するエンジンを呼び出してるだけでした。そのエンジンのことを ActiveX Scripting Engine なんていうわけです。これは COM ベースなので、きちんとプログラミングすれば自分で作っているアプリに JScript や VBScript を使ったスクリプティング機能を持たせることができたりするわけです。
検索してみたら、まだ一応ドキュメントは残ってるみたいですね。「Microsoft Windows Script Interfaces - Introduction」

しかし、普通に考えて、こういう汎用的に作られたエンジンはパフォーマンスなんかが犠牲になったりするわけです。で、ついに IE9 では JavaScript のエンジンを内蔵するようにしたそうです。（”Chakra” というのがコードネームとのこと）
すると、IE8 に比べて何倍も速くなったそうです。

そうそう、タイトルには 「お払い箱」 なんて書いちゃいましたが、内蔵されるのは JavaScript だけで、VBScript などは依然として ActiveX Scripting Engine を使うみたいですね。過去の資産が使えるようにってことでしょうね。さすがに、HTML5 アプリを作るのに VBScript を使う人はいないでしょうし。

ところで、IE9 って Web Strage とか Web SQL Database とかもサポートするのかな？あと WebGL とか WebSockets とかは？

[Silverlight] ビヘイビアーの開発 その4

「[Silverlight] ビヘイビアーの開発 その3」 の続きです。

■ TargetedTriggerAction<T> の補足
「[Silverlight] ビヘイビアーの開発 その2」 で書いた TargetedTriggerAction<T> の補足です。
Target プロパティの型が T になっていると書きましたが、（それはそうなんですが）、TargetedTriggerAction<T> では AssociatedObject プロパティの型が DependencyObject となっています。

Behavior<T>、TriggerAction<T> では、たとえば、T を Button にすれば Blend 上でボタンとその子孫のオブジェクトにしかドロップできなくなります。しかし、TargetedTriggerAction<T> では T は AssociatedObject の型ではなく Target の型の指定になっているためこういったことができません。そこで TypeConstraint 属性が用意されています。

[TypeConstraint(typeof(Button))]
public class TargetedTriggerActionSampleBehavior : TargetedTriggerAction<FrameworkElement>
{
    protected override void Invoke(object parameter)
    {

    }
}

このようにクラスに対して TypeConstaint 属性を指定してやれば OK です。

■ 最後に
以上、ビヘイビアー開発関連でとりあえず知ってることをまとめてみました。
もともとは その3、その4 あたりで書いた属性のことがきちんとまとまってる資料がなかなか見つからなくて探し出すのに苦労したので忘れないようにと書いておいたのがベースになってます。

[Silverlight] ビヘイビアーの開発 その3

「[Silverlight] ビヘイビアーの開発 その2」 の続きです。

■ サンプル
トリガーをきっかけにストーリーボードを開始するビヘイビアーを作ってみます。
と言っても、たいしたものではなく、基本的には

• Storyboard 依存プロパティを定義する。
• Invoke メソッドで Storyboard 依存プロパティのストーリーボードを開始する。

としてやればいいだけです。（実際にはこれだけではちょっと問題があります。それについては後述）
実際のコードは以下のようになります。

public class PlayStoryboardBehavior : TriggerAction<FrameworkElement>
{
    public Storyboard Storyboard
    {
        get { return (Storyboard)GetValue(StoryboardProperty); }
        set { SetValue(StoryboardProperty, value); }
    }

    public static readonly DependencyProperty StoryboardProperty =
        DependencyProperty.Register("Storyboard", typeof(Storyboard), typeof(PlayStoryboardBehavior), null);

    protected override void Invoke(object parameter)
    {
        if (this.Storyboard != null)
        {
            this.Storyboard.Begin();
        }
    }
}

■ CustomPropertyValueEditor 属性
上記のコードで一番の問題はストーリーボードの選択が Blend 上できちんとできないことです。
Storyboard プロパティの部分は以下のようになっています。

XAML 上にストーリーボードがあっても 「新規作成」 ボタンしか無いためそれらを選択することができません。これでは実用的に使うことができません。（XAML を手で編集すれば使うことはできると思いますが）
これを可能にするための専用の属性 CustomPropertyValueEditor が用意されています。

    [CustomPropertyValueEditor(CustomPropertyValueEditor.Storyboard)]
    public Storyboard Storyboard
    {
        get { return (Storyboard)GetValue(StoryboardProperty); }
        set { SetValue(StoryboardProperty, value); }
    }

このように Storyboard 依存プロパティに CustomPropertyValueEditor(CustomPropertyValueEditor.Storyboard) を追加してやるだけです。
このようにすると Blend 上での表示が以下のようになります。

ちゃんとドロップダウンコンボボックスになって既存のストーリーボードを選択できるようになりました。

なお、CustomPropertyValueEditor は他にもいくつか用意されています。詳しくはリファレンスマニュアルの 「CustomPropertyValueEditor 列挙」 を。

■ Category 属性
プロパティに Category 属性を付けておくと Blend のプロパティウインドウ上での表示場所を指定することができます。

    [Category("Common Properties")]
    [CustomPropertyValueEditor(CustomPropertyValueEditor.Storyboard)]
    public Storyboard Storyboard
    {
        get { return (Storyboard)GetValue(StoryboardProperty); }
        set { SetValue(StoryboardProperty, value); }
    }

このように Category("Common Properties") を付けてやると 「その他」 ではなく下図のように 「共通プロパティ」 の方に入るようになります。

■ DefaultTrigger 属性
トリガーのデフォルト値についてですが、Button に接続した場合は Click イベントがデフォルトとなるようです。
しかし、他の多くのオブジェクトでは Loaded がデフォルトとなってしまいます。以下は TextBlock に接続したときのトリガーのデフォルト値です。

今回のような 「ストーリーボードを開始するビヘイビアー」 の場合は、ボタンでは Click イベント、それ以外では MouseLeftButtonDown イベントあたりをデフォルトにしておきたいところです。
それが、DefaultTrigger 属性で指定できます。

[DefaultTrigger(typeof(Button), typeof(System.Windows.Interactivity.EventTrigger), "Click")]
[DefaultTrigger(typeof(FrameworkElement), typeof(System.Windows.Interactivity.EventTrigger), "MouseLeftButtonDown")]
public class PlayStoryboardBehavior : TriggerAction<FrameworkElement>
{
    ...
}

■ サンプルの完成コード
一応、サンプルコードの完成形を載せておきます。 

[DefaultTrigger(typeof(Button), typeof(System.Windows.Interactivity.EventTrigger), "Click")]
[DefaultTrigger(typeof(FrameworkElement), typeof(System.Windows.Interactivity.EventTrigger), "MouseLeftButtonDown")]
public class PlayStoryboardBehavior : TriggerAction<FrameworkElement>
{
    [Category("Common Properties")]
    [CustomPropertyValueEditor(CustomPropertyValueEditor.Storyboard)]
    public Storyboard Storyboard
    {
        get { return (Storyboard)GetValue(StoryboardProperty); }
        set { SetValue(StoryboardProperty, value); }
    }

    public static readonly DependencyProperty StoryboardProperty =
        DependencyProperty.Register("Storyboard", typeof(Storyboard), typeof(PlayStoryboardBehavior), null);

    protected override void Invoke(object parameter)
    {
        if (this.Storyboard != null)
        {
            this.Storyboard.Begin();
        }
    }
}

「[Silverlight] ビヘイビアーの開発 その4」 に続きます。

[Silverlight] ビヘイビアーの開発 その2

「[Silverlight] ビヘイビアーの開発 その1」 の続きです。

■ TriggerAction<T>
何らかのトリガーを持つビヘイビアーを作成するときの基本クラスです。
以下のように中身が何もないビヘイビアーを作ってみて Blend に貼り付けてみるとすぐ意味がわかるんじゃないかと思います。

public class TriggerActionSampleBehavior : TriggerAction<FrameworkElement>
{
    protected override void Invoke(object parameter)
    {
        
    }
}

Invoke メソッドが abstract なので中身のないメソッドを定義してますが、それだけで他には何にもありません。これを Blend でボタンに接続してみたときのプロパティウィンドウは以下のようになります。

コードの中身は何も無いのにちゃんとトリガーが選択できるようになっています。
上記の図だと親オブジェクトの Click イベントをトリガーに指定しています。この場合、Click イベントが発生すると Invoke メソッドが呼ばれます。
だから「接続しているオブジェクトでトリガーが発生したら○○する」 というビヘイビアーを作るときに必要なのは Invoke メソッドの中身を書くことだけです。

■ TargetedTriggerAction<T>
こちらも TriggerAction<T> と同じように中身無しでビヘイビアーを作り Blend に貼り付けてみます。

public class TargetedTriggerActionSampleBehavior : TargetedTriggerAction<FrameworkElement>
{
    protected override void Invoke(object parameter)
    {

    }
}

まぁ、クラス名からだいたい予想は付くと思いますが、TriggerAction<T> と比べると 「TargetName」 が増えています。
要するに 「接続しているオブジェクトでトリガーが発生したらターゲットに○○する」 というようなビヘイビアーを作りたいときに TargetedTriggerAction<T> を基本クラスとして使えばいいわけです。
TargetName に指定したオブジェクトは Target プロパティに格納されています。Target プロパティの型は T です。

「[Silverlight] ビヘイビアーの開発 その3」 に続きます。

[Silverlight] ビヘイビアーの開発 その1

ビヘイビアーを開発する際に必要となる基本的なところをまとめておきます。

■ ドキュメント
とりあえず、以下のヘルプファイルが入っているのは見つけました。
これらのファイルがいつ入ったのかまでは調べてませんが、名前的に考えて Expression Blend を入れたときだと思います。

※以下、”%PROGRAMFILES%” と表記していますが、64bit OS の場合は “%PROGRAMFILES(x86)%” になります。

Blend 3 （英語版）	%PROGRAMFILES%\Microsoft SDKs\Expression\Blend 3\Help\en\BlendSDK.chm
Blend 4 （日本語版）	%PROGRAMFILES%\Microsoft SDKs\Expression\Blend\.NETFramework\v4.0\Help\ja\.NETFramework40BlendSDK.chm

また、Blend SDK は Microsoft のダウンロードサイトからダウンロードできますので、きっとそれにも入ってるんだと思います。（確認はしてませんが）

もっとも、このヘルプファイルにはちょっと不満が。。。
Blend 3 のやつはクラスのリファレンスが載ってるだけで解説なんかは全然ありません。
Blend 4 の方はちょっと解説なんかも増えてますが、「ビヘイビアーの追加の仕方」 みたいな Blend の使い方について数ページの解説があるだけで、ビヘイビアーの開発方法についてはほとんど何も説明がありません。「カスタムのトリガーとアクションの作成」 というページと 「カスタム ビヘイビアーの作成」 というページがそれぞれ 1ページづつあるだけみたいです。
英語のヘルプと日本語のヘルプとでは翻訳してあるだけで基本的に内容は同じみたいですし。。。
うーん、どっかにまともな開発用ドキュメントってあるんでしょうか？

■ 参照設定
Visual Studio で作った Silverlight プロジェクトの場合、ビヘイビアーの開発に必要となるアセンブリを手動で参照設定する必要があります。
Blend で作ったプロジェクトの場合は最初からこれらの参照設定が含まれています。どうやら以下のファイルが参照設定されているようです。

Blend 3 （英語版）	%PROGRAMFILES%\Microsoft SDKs\Expression\Blend 3\Interactivity\Libraries\Silverlight フォルダの下 System.Windows.Interactivity.dll Microsoft.Expression.Interactions.dll
Blend 4 （日本語版）	%PROGRAMFILES%\Microsoft SDKs\Expression\Blend\.NETFramework\v4.0\Libraries フォルダの下 System.Windows.Interactivity.dll Microsoft.Expression.Interactions.dll Microsoft.Expression.Drawing.dll

ビヘイビアーの開発という意味では本当に必要なのは System.Windows.Interactivity.dll だけみたいです。Behavior<T> や TriggerAction<T> といったビヘイビアーの基本クラスとなるクラスなどがこれに含まれています。
Microsoft.Expression.Interactions.dll には標準で付いているビヘイビアー （ChangePropertyAction や PlaySoundAction といったもの） が入っているようです。
Blend 4 で増えた Microsoft.Expression.Drawing.dll には星とかのシェープが入っています。

■ ビヘイビアーの基本クラス
ビヘイビアーを開発する場合、Behavior<T>、TriggerAction<T>、TargetedTriggerAction<T> のいずれかを継承する必要があります。

■ Behavior<T>
もっともシンプルなビヘイビアーの基本クラスです。
サンプルコードは以下のようになります。

public class BehaviorSampleBehavior : Behavior<FrameworkElement>
{
    protected override void OnAttached()
    {
        base.OnAttached();
        this.AssociatedObject.MouseLeftButtonDown += AssociatedObject_MouseLeftButtonDown;
    }

    protected override void OnDetaching()
    {
        base.OnDetaching();
        this.AssociatedObject.MouseLeftButtonDown -= AssociatedObject_MouseLeftButtonDown;
    }

    void AssociatedObject_MouseLeftButtonDown(object sender, MouseButtonEventArgs e)
    {
        MessageBox.Show("left button down");
    }
}

AssociatedObject プロパティにビヘイビアーが接続しているオブジェクトが格納されています。
ですので、アタッチのときにイベントハンドラを登録し、デタッチのときに削除する、というようにしてやると好きなイベントに反応することができます。

■ ジェネリック引数 T について
Behavior<T> の T ですが、これは 「どのオブジェクトに接続することができるのか」 を示していると考えるとわかりやすいです。
T を FrameworkElement か UIElement にしておけば 「何にでも接続できるビヘイビアー」 ということになります。（XAML に出てくる普通のオブジェクトはみんな FrameworkElement から派生したオブジェクトだから。Resource とかは違うかもですが、そういう特殊なやつはここでは横に置いておきます）
T を Button にすれば Button （と Button から派生しているもの） に接続できるビヘイビアーということになります。

Blend はきちんと T の型を見ています。
Blend でビヘイビアーをドロップしようとすると、マウスの下がドロップ不可のときは進入禁止マークになりますが、T が Button になっていると Button （と Button から派生しているもの） の上にマウスがある時だけドロップ可能になって、それ以外のときは進入禁止マークになります。

そして、もちろん AssociatedObject プロパティの型は T です。

「[Silverlight] ビヘイビアーの開発 その2」 に続きます。

[ASP.NET] RSS を受け取って表示する ASP.NET のコード

勤め先の Web サイトで RSS を受け取って表示したいってことだったので、ちょこちょこっと書きました。

aspx は単に DataList を置いただけです。以下のような感じ。

<asp:DataList ID="DataList1" runat="server">
    <ItemTemplate>
        <asp:HyperLink ID="HyperLink1" runat="server"
            Target="_blank"
            NavigateUrl='<%# DataBinder.Eval(Container.DataItem, "Link") %>'
            Text='<%# "[" + DataBinder.Eval(Container.DataItem, "Published", "{0:MM/dd HH:mm}") + "] " + DataBinder.Eval(Container.DataItem, "Title") %>'></asp:HyperLink>
    </ItemTemplate>
</asp:DataList>

aspx.cs で以下のよう DataList にデータバインドして表示します。

protected void Page_Load(object sender, EventArgs e)
{
    var rss = XElement.Load("http://shinichiaoyagiblog.divakk.co.jp/feeds/posts/default");
    var ns = XNamespace.Get("http://www.w3.org/2005/Atom");
    var titles = from entry in rss.Elements(ns + "entry")
                 select new
                 {
                     Published = DateTime.Parse(entry.Element(ns + "published").Value),
                     Title = entry.Element(ns + "title").Value,
                     Link = entry.Elements(ns + "link").Single(x => (x.Attribute("rel").Value == "alternate")).Attribute("href").Value,
                     Author = entry.Element(ns + "author").Element(ns + "name").Value
                 };

    this.DataList1.DataSource = titles.Take(5);        // 最初の 5件
    this.DataList1.DataBind();
}

Linq を使ってごく普通に RSS を取ってるだけです。
あぁ、RSS って書いてますが、上記は Atom 専用のコードになっちゃってます。
あと、例外なんかもまったく考慮してないので、そのあたりはもうちょっとちゃんとした方がいいかもしれません。

[ASP.NET] ASP.NET 4 と ASP.NET 1.x/2.0 を混在させる

最近 （ASP.NET 4 から？） は複数のバージョンの ASP.NET を一つの Web サイトでホストできるということで、それをやってみようとしたときの記録です。

サイトの構成を以下のようにしようとしました。

• http://www.divakk.co.jp/ … ASP.NET 4 にしてみようとした。
• http://www.divakk.co.jp/blog/ … .Text が ASP.NET 1.1 で動いている。

もともと .Text （C# で書かれたブログエンジン） が動いているところの親フォルダを ASP.NET 4 にしてみようとしたわけです。
OS は Windows Server 2003 の IIS6 です。
.NET Framework 4 をインストールしたらいつの間にか /blog/ の方も 4 になっていたので、以下の手順でマルチバージョンにしました。

1. IIS マネージャの 「アプリケーションプール」 を右クリックして v1Pool という名前のプールを新規作成。
2. IIS マネージャで仮想フォルダ blog を右クリックしてプロパティで 「アプリケーションプール」 を v1Pool に、「ASP.NET バージョン」 を 1.1.4322 にした。
3. （ルートの方は始めから「アプリケーションプール」 が DefaultAppPool、「ASP.NET バージョン」 が 4.0.30319 になっていたのでそのまま）

ひとつのアプリケーションプールに違うバージョンを入れることはできません。マルチバージョンにしたいときはこのようにバージョン別にアプリケーションプールを作ってやれば OK です。

が、ここで問題発生。
blog フォルダの方は勝手に親フォルダの web.config を見にいっちゃうんですね。
もちろん、blog フォルダは Web アプリケーションにしてあるので独自に web.config を持ってるんですが、実行時に勝手に親フォルダの web.config も内容がチェックされてしまいます。
それで、親フォルダは ASP.NET 4 になってるので web.config も ASP.NET 4 のものになっています。それを ASP.NET 1.1 としてチェックしてしまうため （blog フォルダは ASP.NET 1.1 だから）「connectionString なんて知らね」 「targetFramework なんて知らね」 とかって感じで web.config が不正だというエラーになってしまいます。
この、親フォルダの web.config までチェックしにいっちゃうのって止められるんでしょうか？
ちょっと調べてみたところでは止め方がわかりませんでした。
今回の場合は、親フォルダは特に web.config に書かなくちゃいけないことは無かったので、中身をばっさりと削除して ASP.NET 1.1 と非互換な部分が無くなるようにしちゃいました。その結果、親フォルダの web.config のせいでエラーになることは無くなりました。

そして、次の問題が発生。
.Text では http://www.divakk.co.jp/blog/aoyagi/ のようにアクセスできるようになっています。aoyagi という名前のフォルダは実在しないのですが、うまいことマッピングして処理するようになっているんです。
ところが、実際にアクセスしてみると 「eurl.axd/xxxxxxxxxxxxxxxxxx が見つからない」 とかっていうエラーになります。
検索してみるとどうやらこちら。
http://www.asp.net/learn/whitepapers/aspnet4/breaking-changes#0.1__Toc256770153
（日本語は [PDF]ASP.NET 4 の互換性に影響する変更点 ）
一部抜粋してみると、

ASP.NET 4 を使うように構成されていると、拡張子なしの URL に eurl.axd を追加してしまう。ASP.NET 2.0 は eurl.axd を認識しないのでファイルが存在しないという例外が発生する。

ということだそうです。
解決法も書いてあるんですが、

1. ASP.NET 4 を使うのをやめる
2. ASP.NET 2.0 だけのサイトを別に作る
3. レジストリを書き換えて eurl.axd を使わないようにする

うーむ。
今回は 3 の eurl.axd を使わないようにして対処しました。

一応、最初に意図した構成にはできましたが、ちょっとなんだかなぁという感じです。
ASP.NET のバージョンを混在させるのはいろいろと落とし穴がありそうですね。

[始めに] 技術系の記事を書くためのブログを作成しました

今まで http://shinichiaoyagi.blog25.fc2.com/ で技術系のことも趣味系のこともごちゃまでで書いてましたが、技術系専用のブログをここに立ち上げました。
ここでいう技術系っていうのは、Windows、.NET Framework、C#、VB、WPF、Silverlight といったもののことです。

見てもらったらわかるとおりここは http://shinichiaoyagiblog.divakk.co.jp/ と私の勤め先のドメイン （ http://www.divakk.co.jp ） の下になってます。（下というか、ドメイン内のホストですが）
けど、まぁ、これにはあんまり深い意味は無くて、普通に青柳個人が好き勝手に書くブログですし、もちろん、会社の公式ブログとかそういうのとも違います。

また、独自ドメインを使っていますが、バナーに出しているようにここは http://www.blogger.com/ です。
blogger.com は無料で独自ドメインを使えるとのことでしたのでお借りすることにしました。

[CRT] Re:一歩ずつ （CRT エミュレーション）

前の記事に続いて、Jitta さんの 「一歩ずつ」 の出題 7 の CRT のにじみについて。
（またまた回答とかじゃありません）
そういや、以前に見かけたなぁ、と思って検索してみた。

A Television Simulator
Atari 2600 VCS エミュレーターの話なんですが、CRT エミュレーションをするにはどういったことをすればいいかといったことが書かれているようです。
すごくいい加減な訳ですが、どうやら

• Texture … 格子を抜けてきた電子ビームによって蛍光物質が光ってるとかそういった構造上の理由から CRT はドットとドットの間にわずかに隙間がある。
• Afterimage … 蛍光物質がわずかな間焼きつくのと、LCD に比べると人の網膜に残像が残りやすい。結果、画像が動いたり変化したりしたあとすぐに消えずに残存したりする。
• Color Bleed … LCD のように輪郭がくっきりせず CRT では周囲ににじみ出すし、色が混じりあったりする。
• Noise … 伝送に RF を使っているのでノイズがそれなりに乗る。普通のテレビと違ってビデオゲームの広くフラットに塗りつぶしたようなところでは、それがわずかなバイブレーションとして見える。

といったところみたいです。

で、2009年春に Stella という Atari 2600 VCS エミュレーターに上記の内容を実装してみたと。
結果は “ファンタスティック” だったそうです。
こちら の June 9, 2009 のところに CRT エミュレーションが追加されたとあります。
Open GL 2.0 以上で GLSL が必要とのことです。

残像とかは以前のフレームの状態とかがわからないとダメそうなので難しいかもだけど、ドット間の隙間やにじみなんかは Silverlight の PixcelShader でもなんとかなるかな？（いや、私は作りませんが。つか、HLSL とかあまりよく知らないし）

[Small Basic] Re:一歩ずつ （Small Basic でやってみた）

Jitta さんの 「一歩ずつ」 を読んで、ふと、Small Basic でやってみました。
（出題に対する回答ではなく、そのまんま Small Basic でやってみたというだけです）

実は Small Basic を使ってみるのは今回が初めてです。存在を知ってただけで、インストールもしたことがありませんでした。
なので、まずは http://smallbasic.com/ から msi をダウンロードしてセットアップ。
ダウンロードサイズも 5Mバイトちょっととすごくコンパクトなんですね。
セットアップ中に聞かれる Custom Setup のところの “Main Files” を展開して English と Japanese を “Will be installed on local hard drive” にしておきました。
そうすると、ちゃんとスタートメニューに Microsoft Small Basic (English) と (Japanese) が追加されました。（English は別にいらなかったかも）

さっそく Small Basic を起動して以下のコードを入力。
Small Basic の文法もほとんど知りませんでしたが、インテリセンスもよくできてるし、すぐに完成。

GraphicsWindow.Width = 800
GraphicsWindow.Height = 600

For x = 0 to GraphicsWindow.Width Step 5
GraphicsWindow.PenColor = "Blue"
  GraphicsWindow.DrawLine(0, 0, x, GraphicsWindow.Height)
EndFor

For y = 0 To GraphicsWindow.Width step 5
GraphicsWindow.PenColor = "Blue"
  GraphicsWindow.DrawLine(0, 0, GraphicsWindow.Width, y)
EndFor

実行してみたらちゃんと青い線が描けました。

Small Basic のおもしろいところは、書いたコードをすぐに公開できるところです。
やり方は簡単でツールバーの 「発行」 ボタンを押すだけ。
ユーザー登録とかそういったとも何にも無しにボタンを押すだけでコードが Web で公開されます。
そうやって公開したのがこちら
http://smallbasic.com/program/?ZWL954

Web 上では Silverlight で動いてるんですね。
リンクするだけでなく、<object> タグで自分のブログなんかに貼り付けることもできます。（右側に表示されている “Embed this in your website” のタグ）
なかなかおもしろいなぁ。
リファレンスマニュアルも日本語化されてました。 http://smallbasic.com/doc.aspx?l=ja

あと、Jitta さんの記事の出題 7 の CRT のにじみについてですが、これについては別記事にて。

[WPF][Silverlight] Silverlight を WPF/XNA でホスト

CodePlex にこんなのがありました。
http://silverlightviewport.codeplex.com/
すごく簡潔な説明しか無いですし、ソースを見たわけでもないので詳細はわかんないんですが、WPF/XNA 上で Silverlight をホストするものみたいです。（Host ではなく Render になってますが）
また、「まだめっちゃ実験的なもんだよ！」 とのこと。

作者さんのブログの記事はこちら
Render Silverlight in WPF ? WPF SilverlightViewport
まず、「より明確に理解するために取り組んでみたホビープロジェクトだ」 といった文からはじまってます。
で、以降をざっと要約すると 「Silverlight は COM API でホストできる。C++ のサンプルコードもある。けど、これは Win32 のウインドウに描画するのが前提。Silverlight はウインドウレスもサポートしてるはず。なので、Silverlight をウインドウレスにロードして画面の代わりに GDI ビットマップに描画させてみたらうまくいった。ただ、CPU 使用量が高かったのとアルファが透過できなかったけど。で、ちょっと汚くなったけど interop でごにょごにょしたらアルファも抜けるようになったし、パフォーマンスも良くなった。WriteableBitmap も使ってみたけど、結局 InteropBitmap にした。パフォーマンスも良くなったし。」 という感じです。

ソースをダウンロードして Visual Studio 2008 でソリューションを読み込んでやればビルドして実行できます。
（XNA を入れていない場合、XNATestApplication プロジェクトと Primitives3D プロジェクトが読み込めませんが、無視して読み込んでしまえばとりあえず TestApplication を動かしてみることはできました）
TestApplication を実行してみるとちゃんと動いてます。動いているのは http://silverlight.net/ にある SHOWCASE を表示しているやつです。
Window1.xaml の <slvp:SilverlightViewportElement ...> の Source を Source=”http://silverlight.net/content/samples/sl3/toolkitcontrolsamples/run/System.Windows.Controls.Samples.xap “ と書き換えてやって Silverlight 3 Toolkit を動かしてみましたが、それなりに動いてます。
なお、マウス入力はそれなりに生きてますが、キー入力は未対応みたいです。
（マウス入力は WPF 上のイベントを転送してやってるんじゃないかと思いますが、キー入力は IME とかいろいろ絡んできそうなので簡単ではないのかも）

作者さんもホビープロジェクトと言ってる通り、実用性についてはよくわかりません。
そもそも、「Silverlight をホストしなくても WebBrowser を使えばいいんじゃね？」 という気がしなくもないですｗ
けど、試みとしてはおもしろいですね。

[Silverlight] Silverlight 4 で AR

World# - Real Time 3D Augmented Reality with Silverlight より。
Silverlight 4 では webcam API がサポートされるってことで、当然のように AR している人がいましたｗ
完全にマネージド （C#） な NyARToolkitCS という ARToolkit を使っているそうです。
また、3D モデルのレンダリングに Balder というマネージドなゲームエンジンを使っているそうです。

上記は実際に Silverlight 4 で動かしてるところをスクリーンキャプチャしたものだそうです。
記事に 「スクリーンキャプチャソフトがリソースをえらく食ってる」 といったことが書かれてますので、カクついて見えるのはキャプチャムービーだからみたいです。
記事によると 50～60fps でスムーズに動いているとありますね。

[Silverlight] Wiki-OS と Userware API

Wiki-OS を作ってる Userware 社による Wiki-OS などの紹介ムービー。
英語ですが絵を見てるだけでもだいたいわかるんじゃないかと。

2:10 くらいから始まるプロダクト & デモでは以下のものが紹介されています。

• Wiki-OS … そのまんま Wiki-OS ですね。
• Wiki-OS Enterprise … どうやら Wiki-OS サーバを自分で立ち上げることができる模様。ムービーでは .xbap になってるので WPF 版ですが、これは WPF 版と Silverlight 版があるのかな？
• Userware API … どうやら自分のアプリケーションに Wiki-OS の機能を組み込める模様。ムービーではイメージエディター （自分で作ったアプリ） のフィルターを Userware API 対応にしておき、「他に欲しいフィルターがあったら誰か作ってね」 なんてことをしています。（「Create New Filter...」 で Wiki-OS と同じ C# コードエディターが開きコードを書ける。もちろん既存のコードを編集することも可）
• Userware for Office … Microsoft Office のアドインを Userware API なコンポーネントでできるようにするもの。

いやぁ、おもしろいなぁ。
特に Userware API なんてすごく興味深い。実用的に使えるのかどうかはまだ何とも言えない気がするけど、けど、なんかわかんないけど 「おもしろそう」 と感じるｗ
ちなみに、http://www.userware-solutions.com/ にあるように Wiki-OS Enterprise、Userware API、Userware for Office は有料な商品みたいです。

ところで、ムービーの 3:00 くらいのところ。
Wiki-OS アプリをブログに貼り付けてみるというデモですが、”貼り付けてみるテスト” なんて日本語が見えたので 「おぉ、日本語！」 って思ったんですが、「あれ？このブログ、見覚えが、、、」
うはっ、ここじゃんｗ

[Silverlight] Silverlight を使った Virtual DVD

Silverlight-powered Virtual DVD now available from Tesco より。
このタイトルを見たときはさっぱり意味がわかんなかったんですが、記事によると 「9月に Microsoft と Tesco が次世代のホームビデオ提供方法を Silverlight を使って行う予定とアナウンスした。”Virtual DVD” は物理的な DVD/Blu-ray を購入した Tesco の顧客がそのディスクとまったく同じものの Silverlight 版をダウンロードできるようにする仕組み」 ということだそうです。
記事には書いてないんですが、やっぱり Live Smooth Streaming を使ったものなのかな？
ただ、チャプター、マルチランゲージ、字幕もサポートされるとありますね。Live Smooth Streaming ってこういったこともできるようになってるのかな？

ところで、つい最近ほとんど同じようなニュースを見たような気が、、、
Amazon、DVDやBDを買うとその場でデジタル版を観られるDisc+ On Demandを開始
これか。

[Silverlight] Silverlight 4 の COM 呼び出しはアウトオブプロセスな COM サーバのみらしい

Silverlight 4 COM Support and 32/64 bit machines ? the C64 Emulator より。
以前に Commodore 64 エミュレータを Silverlight で作ってる 方の記事を紹介しましたが、その方のその後です。

ジョイスティックなんかをエミュレートするためにタッチ・インターフェースでできるようにしようとしたとのこと。
このために Windows API Code Pack を使って （おそらく C# で） DLL を作り、これを regasm で COM として登録。そして、Silverlight 4 の COM 呼び出しを使ってこの COM を呼び出すようにしたようです。
（Silverlight から直接 API を呼び出すことはできないため、COM 経由で呼ぶようにしたということですね）
で、パフォーマンスも問題ないしうまくいったと。

が、Silverlight の PM の一人である Ashish Shetty 氏にこのことを話したところ驚かれたようです。こういうシナリオはサポートされてない、と。
太字で強調されてますが、COM 呼び出しはローカルマシンにインストールされているアウトオブプロセスな COM サービスに使うことが前提になっていると。

PDC でこのデモを動かしてやろうとしたけどデモ機が Windows 7 64bit だったので動かなかった、なんてことも書いてありますね。
インプロセスな COM の場合、64bit アプリでは 64bit の COM、32bit アプリでは 32bit の COM しか呼び出すことができないからですね。
って、あれ？
Silverlight 4 の Out of Browser は 64bit OS だと 64bit なの？
いや、そもそも regasm で登録した COM って 32bit なの？64bit なの？（アセンブリは AnyCPU だとして）
気になったので検索してみた、、、
おぉ、

• C:\Windows\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe
• C:\Windows\Microsoft.NET\Framework64\v2.0.50727\RegAsm.exe

があるのか。
Framework の方で regasm する 32bit COM、Framework64 の方だと 64bit COM になるのね。知らんかった。

ちなみに、アウトプロセスな COM サーバーの場合は間にマーシャリングが入るため違うビット幅の COM サーバーも問題なく呼び出せます。

ちょっと話がそれましたが、インプロセスな COM に使うことを想定してないというのはちょっと意外。
Having fun with Silverlight 4 Beta and the Speech APIs
こちらの人なんて Speech API を呼び出して Out of Browser な Silverlight 4 アプリにしゃべらせたりしてるし。
# Sapi.SpVoice はインプロセスな COM でした。

おまけ
Silverlight 4 で dynamic 使うときは Microsoft.CSharp.dll を参照しないといけないのか。

[Silverlight] WriteableBitmapEx が CodePlex で公開

http://writeablebitmapex.codeplex.com/
WriteableBitmap に便利なメソッドを追加する WriteableBitmapEx が CodePlex にて公開されています。

Silverlight 3 では WriteableBitmap クラスを使ってイメージを描くことができるようになりました。
こいつには、UIElement を Render するという方法と、イメージのバイト配列にアクセスして各ピクセルの色をいじるという方法で絵を描けます。
けど、あるのはそれだけなので、線分ひとつ描くのにも、System.Windows.Shapes.Line を生成してそいつを Render するか、自分で DDA とかを使った DrawLine のようなメソッドを用意するかしないといけないんですよね。

というわけで、DrawLine などを一通り用意したのがこの WriteableBitmapEx です。
今のところ用意されているのは、

• Clear
• SetPixel
• DrawLine
• DrawPolyline
• DrawTriangle
• DrawQuad
• DrawRectangle
• DrawEllipse
• DrawEllipseCentered
• Blit
• ToByteArray
• FromByteArray

と言ったところです。
すべて拡張メソッドとして実装されてますのでかなり自然な感じで使うことができます。
ソースを見ればすぐにわかりますが、「内部で UIElement を作って、、、」 なんていう方法ではもちろん無く、DDA などのアルゴリズムを使ってピクセル単位で描画しています。
トップページ の “Performance!” のところに 「WriteableBitmapEx のメソッドは Silverlight の Shape よりずっと速い。たとえば、WriteableBitmapEx の DrawLine は System.Windows.Shapes.Line 要素を使うより 20～30倍速い。だから、もし多数の図形を描く必要があり、アンチエイリアスや Silverlight シェープのプロパティなどが必要ないのであれば WriteableBitmapEx のメソッドを使うのがいいだろう」 といったことが書いてあります。

なお、Downloads のところにあるのはバイナリだけでした。
Source Code の方からソースをダウンロードすればサンプルなども含まれています。
ドキュメントが見当たりませんが、まぁ、ソースを見ればすぐにわかるでしょう。

[Silverlight][.NET] Silverlight 4 と .NET Framework 4 の互換性

PDC の Scott Guthrie 氏のキーノートスピーチでも 「Silverlight 4 と .NET Framework 4 のアセンブリには互換性がある」 と言ったことがちらっと触れられてましたが、それの詳細が CLR Team Blog にありました。

Sharing Silverlight Assemblies with .NET Apps
Silverlight 4 用にコンパイルしたアセンブリと .NET Framework 4 用にコンパイルしたアセンブリには互換性があるようになっているそうです。
ただ、そうは言っても、たとえば .NET Framework 4 にしかないクラスを呼び出しているアセンブリを Silverlight 4 で動かすことは当然ながらできません。（もちろんその反対も）
この点については、Silverlight 4 の

• Mscorlib
• System
• System.Core
• System.ComponentModel.Composition
• Microsoft.VisualBasic

のクラスを使っている限りは .NET Framework 4 でも問題なく動くようです。
.NET Framework 4 の方が機能が多いため、.NET Framework 4 のこれらのアセンブリのみを使用しているアセンブリが Silverlight 4 で動かせるとは限らないようですので注意。
なので、Silverlight 4 と .NET Framework 4 の両方で使えるようにしたい場合は Silverlight 4 のプロジェクトとして作った方がいいようです。

これと関連して、
Silverlight 3 & 4 Library Sharing with .NET 4.0 Library or WPF
これを見ると、どうやら Silverlight 4、.NET Framework 4 からは Silverlight 3 のアセンブリも参照できるみたい。

ただ、
On Silverlight 4 Beta / Silverlight 3 backward compatibility
によると、

• Silverlight 4 ランタイム上で Silverlight 3 アプリが動くときは Quirks Mode になって Silverlight 3 互換になる。
• Silverlight 4 アプリの中に Silverlight 3 アセンブリが含まれている場合は Quirks Mode にはならない。

ということになるそうです。（まぁ、そりゃ当然という感じですが）

[日本語入力] 思いどおりの日本語入力 - Google 日本語入力

思いどおりの日本語入力 - Google 日本語入力
なんかすごい。
開発メンバーがハンパ無さそう。

というわけでさっそく入れてみた。
64bit はまだ未対応ということなので Virtual PC 上の XP 32bit へ。
いろいろおもしろいし、常用したいと思うくらいな感じ。

と思ったら大きな問題あり。
私はかな入力なんですが、「っ」 を入力しようと Shift+「つ」 を押すと 「Z」 になってしまい、しかも、それ以降は勝手に半角英数になってしまう。
他にも 「ぃ」 も同様。（「ぁ」 は入力できるのでかな入力時の 『Shift+英字キー』 がおかしいのか？）
あと、「－」 が Shift キーを押しながらじゃないと入れられない。なんで？

後者の方はまだしも、前者の方は 「これじゃあ、まったく使えない」 というレベル。
これって Virtual PC 上だからとかあるのかな？
ちょっとでもかな入力で試してみればすぐわかりそうなもんだし。うーむ。

追記
上記の現象は 「メモ帳」（notepad.exe） で発生しました。
けど、IE のテキストボックスやワードパッドでは正常に 「っ」 が入力できるようです。「－」 も Shift キーを押さなくても入力できます。
いくつかのアプリで試してみたら、どうも正常に入力できるものとできないものとマチマチです。

で、その後、Virtual PC を再起動したりとかいろいろしてたら再現しなくなりました。（いつも正常に入力できる）
何かしらの条件によって発生するのかもしれませんが、とりあえずかな入力でも大丈夫そうです。
（あとは 64bit 対応版さえ出てくれれば）