Flash Player 10.1 beta 3公開
Flash Player 10.1 beta 3 が公開された。
今まで Intel GMA500 で正常に動画が再生されなかった問題が修正されており、早速 VAIO X にインストールして確認してみたが、最新のバージョン 5.2.1 ドライバと合わせてインストールすれば YouTube で 720p の動画がスムーズに再生できた。さすがに 1080p はカクカクになってしまう。
気になったのは、動画再生中は Flash のコントロールの反応が鈍く、動画を途中で停止したくてもボタンを押して5秒くらい待たないと反映されない点である。
あと思わず笑ってしまったのが、全画面表示中にボリュームを下げようと Fn キーと音量下げキーを押すと、オーバーレイで画面下部にボリュームが表示されるのだが、これだけで動画がカクカクになってしまった。正確にはビデオ信号を重ねて行われるオーバーレイではなく、単純にソフトウェアでビデオにボリュームをレンダリングしているのだろうと考えられる。
これで VAIO X の可能性が広がると思われるが、そもそも動画を全く見ないので家にはテレビすらなく、動画再生支援の機能はあまり使う機会がないかもしれない。
Visual Studio 2010 RC（英語版）
Visual Studio 2010 RC（英語版）が公開されたため、実際にインストールして動作を確認した。
前回の Visual Studio 2010 ベータ2まではとても動作が緩慢としていて、ネットブックなどの非力なマシンではコードすら書けない有様であったが、今回は全体的なパフォーマンスが向上しており、手元にあるVAIO Xでも十分な速度で動作した。ただし、Tools > Options > General の、Visual experience 内のチェックをすべて外しておかないと、グラフィック能力の低いマシンではまともに動かない。
LINQ to SQLで継承を使用した場合の注意
LINQ to SQLでは、クラスの継承構造をRDBのテーブルで疑似的に表現することができる。
具体的な使い方については、他のサイトに優れたものがあるのでそちらを参照されたい。
『（C#によるプログラミング入門）―[雑記] O/R インピーダンスミスマッチ（クラスの継承）』
http://ufcpp.net/study/csharp/sp3_ormismatch2.html
RDBでも継承構造を使うことができれば、よりO/Rマッピングのインピーダンス ミスマッチが軽減されるが、制約も存在する。継承した派生クラスに対する他のクラスとの関連を付けることができないのだ。
LINQ to SQLの継承クラスでは、最上位の基底クラスだけが主キーを持つことができる。従って、主キーを参照する他のテーブルからの関連は、派生クラスで持つことができず、全て最上位の基底クラスへ関連を接続することしかできない。
UserControlを2つ以上配置するとエラーになる
Silverlight 3にはElement-to-ElementバインディングというUI要素間のプロパティを相互にバインドできる機能がある。この機能を利用すれば、例えばスライダーのつまみを移動した場合に、テキストブロックにその値をバインディングして自動的に表示させるということがプログラミング無しで可能になる。
この便利な機能を早速試してみようと思い、UserControlにItemというプロパティを追加して、Expression Blendを開き、UserControlに配置されているTextBoxのTextプロパティからItemプロパティをElement-to-Elementバインディングの対象として参照させてみた。そのUserControlをメインのコントロールに貼り付けて実行してみると、見事にItemプロパティの内容がTextBoxに表示された。
これは便利な機能だと調子に乗って、今度はStackPanelの中に先ほど作成したUserControlを複数個挿入されるようにして実行してみた。
すると次のような例外が発生した。
「ArgumentException: 値が期待される範囲にありません。」
例外が発生した箇所を見てみると、StackPanelにUserControlを追加する行を指している。同行にブレークポイントを追加して再実行してみると、どうやら１回目は追加に成功しているが、２回目の追加で例外が発生するらしい。Silverlightにありがちな描画タイミングの問題が発生しているのかとも思い、ボタンを作ってそれを押すと１個ずつUserControlがStackPanelに挿入されるようにして実験してみた。すると、１個目は挿入されるが、２個目はやはり同じ例外が発生してしまう。
試しにTextBoxに設定したItemプロパティへのバインディングを解除して実行してみた。そうしても結果は同じく２回目の追加でエラーとなる。
こうなるといよいよ追い詰められるわけだが、中身を何も変更していない素のUserControlをStackPanelに追加してみた。すると、当たり前のことだが正常に挿入される。
そこで、空のUserControlにやはりItemプロパティを記述し、TextBoxを貼り付けてElement-to-Elementバインディングを設定してみた。そして実行すると、やはり例外が発生する。
段々訳が分からなくなってきたが、Blendで編集されたXAMLをもう一度よく確認してみると、何やら思いがけないコードが挿入されていた。それはUserControlのx:Nameアトリビュートだ。もともとUserControlには何も名前を設定していないのでx:Nameアトリビュートは付いていなかったのだが、Element-to-Elementバインディングの設定をしたときに、Blendによって自動的に付加されたようだ。
確かによく考えてみると、Element-to-Elementの設定では要素の名前を指定している。そのため、何も名前が付けられていないコントロールにはElement-to-Elementバインディングの設定ができない。従って、Blendはご親切にもコントロールに名前が付いていない場合は、コントロールと同名の名前を勝手に付けて、それを要素の名前として設定しているのだ。
このUserControlに勝手に付けられた名前がなぜ問題になるのかといえば、BlendのXAMLエディターで確認すると良く分かる。そこにはUserControlのx:Nameアトリビュートの箇所に、UserControlを同じXAML内に配置した場合に、名前が競合する問題が発生する可能性があるということが表記されていた。
結果的には同じXAML内に2つ以上配置するUserControlには、直接Element-to-Elementバインディングの設定をすることはできないということである。
はじめに
このブログのタイトル『ああ無情』は、ユゴーの『レ・ミゼラブル』の邦訳であるが、内容に直接の関係はない。ただ私の好きな小説であることは間違いない。
日々プログラミングに戯れていると、いつもよくわからないエラーによって作業を中断させられる。どれだけ調べても問題の核心にはなかなか辿りつけないことも多い。不合理にも思えるコンピューターの仕打ちには、必ず何らかの原因があるはずであり、その根本的原理を知りさえすれば、恐るべき複雑さに満ちた挙動といえども、合理的に認識可能な領域なのである。
そのような光景を無情と表しているのだが、これは単なる人間の心の温かみがないという意味ではない。
ソクラテスは、自分の愛人は哲学だと言った*1。人間は時々によって言うことが変わってしまうけど、哲学はいつでも同じことを言うのだと。
ソクラテスの言った言葉は、プログラムでも同じことであって、それはいつでも同じことを言うのだ。けれども、我々の理解の及ばない領域が存在する場合、「同じ」ようには聞こえないであろう。
そのような暗闇に少しでも光を当てることがここでの目的であり、無情にも思えるプログラミングの世界に魅入られた人々の一助になれば幸いである。
