AndroidでのAdapterView-Adapter

どうもJudaです。

今日はAndroidでのAdapterVIewとAdapterの関係についてです。

AdapterViewの継承クラスでは、Adapterを使ってデータと表示を密に連携させることだと思います。
この場合にAdapterViewは大量のデータを高速に表示し、スクロールをよりよくサポートしていることを要求されます。

単純なLinearLayoutの実装では、子要素の数が増えれば増えるほど遅くなります。
これは表示可能領域以外の要素の計測、レイアウト、描画を行ってしまうからです。
また合わせて覚えておきたいことは、Androidでもっとも計算コストの高い処理の一つにLayoutInflaterでのinflateメソッドがあります。XMLからのパース処理はAndroidでもやはり遅いのです。またView要素のコンストラクトも同じく重くなる可能性が高く、あまり多用すると著しい処理コストになります。

上記のような制約がある中で、ListViewなどは高速な表示を可能にしています。
これは、一度生成したViewを再度利用しているからです。
ここからがAdapterViewとAdapterの連携に関わります。
AdpaterViewは、onLayoutでItemを準備します。
この際に、新規にレイアウトする際に、スクロール変位を計算し、それのあと可視領域内に残っているView要素のみを残して、可視領域を外れたものをリサイクルするために格納します。ここでAdapterのTypeIDCount分の格納場所が用意されています。
Viewは排除したあとに、新しく可視領域に出現するView要素を子要素として追加します。このときに使われるのが、addViewInLayoutです。この段階では、単純に子要素として追加したのみであるので、計測処理を行い、のちにLayoutを行います。これはAndroidのLayoutメカニズムの基本です。
addViewInLayoutで追加する際に、利用しているViewは、AdapterのgetViewメソッドによって提供されるものです。このときにconvertViewとしてViewが提供されます。このViewは先ほどの可視領域外にでてしまったViewを格納したところからリサイクル用に提供されたり、また存在しない場合にはnullで提供されます。

大まかな流れはこんな感じです。Adapterには、今回説明していない実装を行うことが求められるメソッドがあります。

静的なIDはデータベースで言うところのIDであり、通常使われるPositionは抽象的な意味でリストの「位置」を表します。またこれを抽象的な意味での「位置」とすることで、内部でソートを行っても、フィルタリングをかけても、とにかく該当するデータを取得する、表現を行うViewを提供することの実装部分をうまく隠蔽できます。

ただ、よくできたInterfaceなのですが、AdapterViewからの実装がめんどくさいです。AbsListViewはそもそもの実装がY-座標系指向が強いので、X-座標系向けではありません。

CppCheckの雑感

どうもJudaです。

CppCheckを利用してみました。

とりあえず日本語の動作がクサイので、setlocale(LC_ALL, "");でビルドをする。

動作的には問題がなさげ。

検出件数とかは、よくわからないけど、未初期化の指摘をしてくれるのが、個人的に嬉しい。

現在わかっている困った点はQtで作成されているGUIで日本語が読めないのか、そもそも日本語パスの扱いがおかしいのか、不明だが、利用できない。

これによって、日本語パス以下にあるファイルの解析がままならない。

手っ取り早く、.NET FrameworkでFork用のGUIだけ準備すればいいのではないかと思う。あとは、Includeディレクトリを常に覚えるのが困るので、とりあえずそこもなんか変えたいと思う。

そんな感じ。

C++における様々なツールについて

どうもJudaです。
最近CIについて、かなり興味が湧いてきました。また、それ以上に体系的なテストの重要性を痛感している今日この頃ですが。
CIを調べながら、いくつかのツールによる自動化も調査しています。現状ではまだ列挙段階ですが、いくつかのジャンルで情報をまとめておこうと思います。
インスペクションツール
CheckStyle
Uncrustify
Artistic Style

（追記：02/2011/09）Simian

静的解析ツール
CppCheck
ドキュメント化ツール（＋可視化）
Doxygen+Graphviz
OpenSource で利用可能なものはこんな感じですかねぇ。
とりあえず多くの人々がこれらを公開してくれていることに頭が下がります。
Doxygen+Graphvizは導入済みですが、これを自動化して、
Commit毎にドキュメント化するようにするところから初めてみたいですね。
あとはインスペクションツールでリファクタリングの目標を絞ること。
『パターン指向リファクタリング』、
『デザインパターン』、
『実装パターン』、
『リファクタリング』
と開発に関する良い指針となるような書籍を読み進めています。

Doxygenによる開発のカンフル

どうもJudaです。

最近Doxygenをはじめました。

Doxygenはコメント生成ツールでかなりメジャーなものだとおもいます。類似したものにはJavaDocやphpDocsとかあるとおもいます。

Doxygenの導入は基本的にはInstallerをOfficialからもらってきて、終わりだとおもいます。DoxygenのGUIとしてDoxyWizardがついているので、比較的簡単にDocumentの生成まではいけるとおもいます。

GraphVizも簡単に手に入れられるので、いれてみるとよりクラスダイアグラムなどが綺麗に画像データになります。

そして、日本語でDoxygenを動かす際にいくつかの問題が起こると思います。

1. 出力ファイルで文字化けが起こること。
2. 入力ファイルが読み込めないこと。
3. ファイルの検索がうまくされないこと。

１、は基本的にはExpertの設定でDoxygen_OutputEncodingのような設定のパラメータを「Shift_JIS」など日本語に対応したものにすればよいとおもいます。

２、もInputを「Shift_JIS」ないし、日本語に対応したものにして、なおかつ読み込ませるデータのEncodeを整えることと、Encodeできない文字を使用しないということになります。

３、もファイルパスをコピー＆ペーストしているとよく起こるのですが、Doxygenでは￥のディレクトリの区切りが利用できないので、/に変換してください。

それで本題。

DoxygenではCalledByやCallという関数での関係性を表示し、リンクを張ってくれる機能があります。

これを利用すると、呼び出し先と呼び出し元をしっかりしらべることができます。さらに、ソースコードを合わせて出力するようにしていれば、対象となる関数のソースコードを表示してくれるので、より一層ソースコードを探検するのが楽になります。

Doxygenを導入すること、運用することには、コメント付けなどいくつかの規約がありますが、単純に関数の呼び出し関係を整理して表示してくれるので、これだけでもかなりツールとしてありがたいものがあります。ただ静的な解析でのサポートなので、動的な解析はたぶんサポートしていません。それでも改修やDebugのときの一助になることは間違いないでしょう。

Google C++ Test Framework

どうもJudaです。
最近Google C++ Test Framework(以下googletest)を いまさら 導入してみました。
googletestはxUnitの流れをくむTestのFrameworkで少しでもxUnit系のテストについての知識があれば、すぐに使えるという触れ込みです。とりあえず公式な情報を翻訳したサイトで勉強すれば、何とかわかります。ちょっと面白いのは、OpenCVのドメインでGoogleTestDocsの日本語訳がホストされていることかなぁ。
肝心の使い方は、公式に書かれているので、割愛しますが、ちょっと読み解くときに面倒に感じたことをいくつか。

• メジャーなコンパイラのためにはすでに特別なプロジェクトが用意されているので、それを利用すること。MSVCとかG++とかは用意されているので、それを利用すればいいので、Cmakeを利用しなくてもいいこと。ただしCmakeを利用した生成もサポートされているので、そちらを利用してもいい。
• MSVCに限らないと思うが、Runtimeの種類で別のSolutionが用意されている。たとえば、マルチスレッドとマルチスレッドDLLで別のRuntime体系になるので、別のSolutionが用意されていて、基本的にはマルチスレッドになっている。なので、MSVCの人でMDｄとかMDのRuntimeを使う人は、gtest_md.slnを利用する。
• MSVCはテスト用のプロジェクトにgtest.projもしくはgtest_md.projをプロジェクトに含めて、テスト用のProjectはその追加したgoogletestのProjectへの依存関係を作ることが必要である。
• TEST_Fを使う場合には事前に::testing::Testクラスを継承したクラスをつくる必要性がある。TEST_F(test_fixture, test_name)でtest_fixtureの部分には利用したい::testing::Testを継承したクラス名を使う。またTest部分ではクラス内部のように変数を扱ってテストできる、はず。
• ::testing::Testの仮想メソッドにはSetup(),TearDown()があるが、名前は厳密に継承元にある奴でないと動作しない。(当たり前) またそれぞれのクラスの利用のタイミングであるが、それぞれデフォルトコンストラクタやデストラクタでは利用できない仮想メソッドや例外が発生しやすいメソッドの利用などの場合には、利用する価値が出てくると思う。この質問に対する回答もある。

上記のような部分で疑問がわいてくると思う。それよりもまず入門ガイドを読まないと話にならないし、それぞれの利用シナリオもに記述されているので、こちらも参照したい。翻訳サイトがあるので、そちらで知識を得ることを優先して、効率よくテストをするために、まずは効率よくFrameworkを使いこなさないといけない。

Code Kata的な 練習

どうもJudaです。

// Kata000.cpp : コンソール アプリケーションのエントリ ポイントを定義します。
//

#include "stdafx.h"
#include 
#include 
#include 
#include 
#include 


void foreachMethod(const size_t& size)
{
  boost::progress_timer t;

  using namespace boost::lambda;
  using namespace std;
  vector tmpArray(size);
  tmpArray[50] = 200;

  boost::progress_display show_progress( tmpArray.size());
  for_each(
    tmpArray.begin(),
    tmpArray.end(),
    (_1 + 1) );

}
void forMethod(const size_t& size)
{
  boost::progress_timer t;

  using namespace std;
  vector tmpArray(size);
  tmpArray[50] = 200;
  boost::progress_display show_progress( tmpArray.size());
  for( size_t i = 0; i < tmpArray.size(); i++){
    int itt = tmpArray[i] + 1;
    ++show_progress;
    //cout << tmpArray[i] << endl;
  }
}
void foriterMethod(const size_t& size)
{
  boost::progress_timer t;
  using namespace std;
  vector tmpArray(size);
  tmpArray[50] = 200;
  
  boost::progress_display show_progress( tmpArray.size());
  for( 
    vector::const_iterator i = tmpArray.begin();
    i != tmpArray.end(); i++){
    int itt = *i + 1;
    ++show_progress;
    //cout << *i << endl;
  }
}

int _tmain(int argc, _TCHAR* argv[])
{
  const size_t size(1000000);
  foreachMethod(size);
  forMethod(size);
  foriterMethod(size);
 return 0;
}

とりあえずいえるのは、VS2008のReleaseならforeachがはやい。Debugならforが早い。とりあえずどれでもイテレータは遅い。でもこの場合に重要な点は、こんな単純なケースで通常のイテレータ回しはあまり有用ではない、という点と、イテレータでの制御はもっと凝ったもののほうがいいかもしれない。とりあえずforeachすげー。投げる要素数が増えるとかなり露骨に早くなる。

WinSxSについて

どうもJudaです。
今日はVC++2005から導入されているManifestについての再配置について。
VC++2005以上でコンパイルされたプログラムは、以前存在していたDLL地獄に対応するために、ManifestによるDLLの選択という機構を取り入れました。
これによって起こっている問題は、VC++2003以前でコンパイルして、配布する際には、プライベートアセンブリや共有DLLは同名のDLLファイルが存在していれば、動作できるのです。しかし、これは正しいDLLかどうかは保障されませんでした。DLL地獄の本当のところは調べれば出てきますので、割愛します。
とりあえず手っ取り早く配布をしたい場合には、以下の手順を踏めばいけます。
・VSコマンドプロンプトでmt.exeを動作させます。
・mt.exe -inputresource: -out:を使って、埋め込まれているManifestを分離します。inputfilepathはEXEやDLLをいれて使います。
・分離されたManifestに記述されているDLLを集めます。
・DLLの場所はVisualStudio/VC/redistのところにある場合とWINDOWS/WinSxSにあります。そこから該当するものを取得します。
・WinSxSの場合には、該当するDLLとそのDLLに合致するManifestが必要になります。ManifestファイルはManifestフォルダにあります。ここから取得します。
･アプリケーションを入れるディレクトリにEXEとDLLと同じフォルダ内に、最初に取得したManifestのName属性に記述されている名前と合致するようにフォルダ名を変更して、そこにDLLとそのDLLのためのManifestを入れます。
これでたいてい動きます。それでもWinSxSのエラーが出るときには、コントロールパネル：コンピュータの管理：イベントビュアーにエラーログがでますので、そこから、問題のDLLを調べることができます。
またmt.exeを利用しなくても、VSのソリューションにExeやDLLを登録して、開くとリソースビューが開き、MT_MANIFESTとかかれている項目があります。そこにEXEなら1、DLLなら2と書かれた項目が格納されていますので、それを開きます。その際に表示された文字列が埋めこまれたManifestになります。これは最初に分離したものと同じになります。
またMSDNで記述されているようなDLLのライブラリをフォルダに入れて云々は、Manifestファイルに記述されていない際には、EXEと同じ階層に置くようになりますので、この方法から除外されます。しかしながらDLLのManifestのほうも問題がありますので、そこも要調整になります。

Silverlight 覚書

どうもJudaです。

Expression Blend 3のSketchFlowで作成したScreenを別のApplicationでホストすることはあると思います。参照を追加して、xmlns:の名前空間を適応して、いざコントロールをビルドできるようになって、ひと段落ですが、このあとになんかきなくさい実行時エラーがでます。

pb:NavigateToScreenAction TargetScreenのターゲットがうまく見えないっていう罠が。

SketchFlowの時には見えていたものが見えなくなっているのですが、これがまたよくわからない。

あと意外と参照がずれている可能性があるのが、Resource系の.xamlファイルへの参照パス。

SketchFlow時にAppに書き込まれているもののうち、独自のものは再び必要？だったりするので、それも追加する。もっともこれは大本に追加しておけば回避できるような気がする。

KB958017 Rollup Hotfix

WPF デザイナーの修正プログラム ロールアップは。

上記の二つが該当するような気がするが、直るかどうかはわからない。

VS2008＋XPでWPFに関連するプログラムはほとんど鬼門である。でもVS2010で直っている保証もないのでややこしい。

またSilverlightはWizardが悪魔のごとき動きをしてくれるので、魂を売り渡せば、もれなく地獄ゆきという特典つきである。問題の調べ方も難解極めるので、ある一定以上になるとExpressionBlendは敵以外の何者でもなくなる。作るコードも汚いし。

追記：7/22 0：41

とりあえず入れてみても問題は解決しない。AG_E_PARSER_BAD_TYPEのエラーはHOTFIXでは解決しない。

またAG_E_PARSER_BAD_TYPEというエラーコードは古くからあるエラーで、XAMLのパルスエラーであるので、かなりの頻度で出るみたい。というか、これ、汎用過ぎて意味わからん。

Solving AG_E_PARSER_BAD_TYPE In Silverlight

このエントリをみると、別のPOSTをみろってある。

AG_E_PARSER_BAD_TYPE Adding Silverlight Toolkit control to module

。。。なんかDLLを足せばなおるって書いてある気がする。

とりあえず文字列でクラスを指定しているところはかなりの確立でエラー起こす。そんな気がする。

でも直し方わからんし、パルスをステップインで追いかけられないし、しょんぼり

追記：7/22 1：00

とりあえずMicrosoft.Expression.Prototyping.Interactivityを参照に追加したら、エラーは起きなくなった。しかし、しかしだ。Navigationがきかないじゃないか。がびーん

NavigateToScreenAction programmatically

で少し調べてみたが、なんか飛び先を指定する文字列に癖があるみたいなことがかかれている。こいつは厄介だ。ここを変数かするのもいいが、そもそもSketchUpで作ったものを移行するのはどうすんだよ。ってところのツッコミがあると思うが、開発末期の部分の処理について書かれたものがない。

とりあえずSketchUpスゲーはわかったから、終わり方を教えてくれ。このゴミのような開発の終わり方を。

そもそもScreen内に遷移情報をかかないわけがないのに、なんでこんなことになるんよ。

拡張保護を使用した統合 Windows 認証ってなんだ？

どうもJudaです。

http://msdn.microsoft.com/ja-jp/library/dd639324(v=VS.90).aspx

http://msdn.microsoft.com/ja-jp/library/dd470100(VS.95).aspx
Extended Protection for Client Applications

とりあえずなんかVS2008でWebServiceの追加を行って、更新をかけたら、動作がおかしくなったので、調査。もしかするとVS2010を入れると内部のVerが変わるのかも知れない。

ここは調査の必要がある。

追記　2010　06　21　1：46

http://msdn.microsoft.com/ja-jp/library/system.security.authentication.extendedprotection.extendedprotectionpolicy.aspx

Version情報からするとWindows7と.net Framework4 でサポートされているのだけれども、VS2008では当然サポートしていないにも関わらず、なんかエラーでるし。。。

追記　２０１０ ０６ ２１ １：５２

http://connect.microsoft.com/onecare/feedback/details/567198/could-not-load-type-system-security-authentication-extendedprotection-extendedprotectionpolicy-exception-after-automatic-updates-kb976769v2-and-kb908773-installed

どうもWindowXPの特定のUpdateを行うと壊れてしまうみたいだ。

http://lemtodev.blogspot.com/2010/06/could-not-load-type-systemsecurityauthe.html

ここに解析しているものがある。これを読む。

Webサービスを利用する際の大容量データの受信について

どうもJudaです。
ちょいと失念してしまうことをいくつか。
http://msdn.microsoft.com/ja-jp/library/aa480521.aspx
大量データに対する戦略 -　MSDN
ここに書かれているのですが、
今回はぶち当たったのは、SOAPで提供されているサービスである特定のリクエストに対して大容量データを返す場合に、エラーが起きて受信出来ない問題があったのですが、これは、VisualStudioを利用している場合には、Webサービス参照の追加でSOAPサービスなりを追加するのですが、ここで記述されるApp.configもしくはWeb.ConfigファイルにXML形式で記述されている部分で、受信サイズなどを決定している属性があるのですが、そこがデフォルトの値だとうまく処理ができなかった。
このデフォルト値には、意味があり、不用意な大容量データを受け取らないようにするためであり、基本的には問題にならない。しかし今回起こったような大容量データを受信しようとすると、そこで初めて属性情報に処理を止められると言う事態になる。
この一件を総括するならば、「ウィザードが作ってくれるものは、便利だが、その構築がむき出しの元になったときには困難が起こる」ということになるだろう。これは「達人プログラマ」でも指摘されていることで、悪い魔法使いの話だ。
よくよくデータを確認してみる必要性があるなぁとつくづく思った。

SilverlightにおけるCustom Template Controlの作り方について

どうもJudaです。

今回はSilverlightにおけるカスタムテンプレートコントロールの説明です。

コントロールのカスタムテンプレートとユーザーコントロール継承の違いですが、私見では、

1. カスタムテンプレートは、再利用可能なユーザーコントロールの開発
2. ユーザーコントロール継承は、再利用を含めないユーザーコントロールの開発

であり、後者のユーザーコントロール継承は、特定の部位に別のコントロールを埋め込んだりと言うことを基本的に考えていない場合だと思います。もちろん様々な方法が考えられますが、構造を変えたりはできないので、基本的には作成した際の構造を逸脱することは出来ず、またユーザーコントロールの構造を残したままの改造なので、DependencyPropertyの数が増えすぎる傾向にあります。

今回はCustomTemplateControlの話なのですが、こちらの開発に関しては、注意することは主には二つ。

1. TemplatePartAttributeなどのパラメータは今度の実装者がどういうパラメータをUIとして定義しているのかを知るための補助的な情報であること。メタデータとして定義されるので、当たり前ですが。
2. GetTemplateChildというメソッドを使って、自身で定義したフィールド変数にそのコントロールへの参照を設定します。これをしないと煩雑な呼び出しがいっぱいなMFCみたいなことになるので、注意です。

呼び出しのタイミングですが、MSDNのベストプラクティスによれば、OnApplyTemplateのオーバーライドのタイミングが最速になるようです。またイベントの定義の問題などもありますので、変数を直に触らせるのではなく、いくつかのレイヤーをかませて抽象化して、エラーを発生させない機構を作る必要がありますが、あくまで再利用を考えれば、ベストプラクティスに乗っとる必要性がありますが、自己で管理しているレベルでの開発ならば、そこまで神経質になる必要性はなさそうです。

テンプレートコントロールの呼び出しタイミングですが、コンストラクタ→Load→OnApplyTempleteになるので、カスタムユーザーコントロールからの移植の場合には注意が必要になります。

またGeneric.xamlに記述されるので、Blendではすこぶる開発しにくいと思います。また基本的にクラスの定義部分が大きくなりすぎる感がありますので、可能であれば、Partial Classの利用をおすすめします。

ADO.NET Data Serviceにおける注意点

どうもJudaです。

ADO.NET Data Serviceの暗黙的な制約があるっぽいので、注意を。

このサービスを作るときに.svc.csファイルに記述をしていくと思いますが、この時に注意があります。基礎となるデータ構造へのアクセスを提供するIQueryableのプロパティを持つクラスはすべて一箇所にDataServiceと同じところに書いておかないとサービスが使えない。どうもそうらしい。もう少し厳密に調べてみる。それにしてもややこしいなぁ、このシステム。どうも最近VisualStudioのWizardが生成するコードとの相性が悪い。どうも道から離れているみたい。

追記

どうも原因が一定しないみたい。問題を捉えたと思ったら逃げられた。一箇所にデータを入れておいたのに、サービスが認識されない。要求エラーが表示されて、内部にエラーが潜在してしまう。作り方自体は、各種サンプルを参考にしているがどうしても問題点を捉え損なう。

バイナリ化しているものの参照がうまく行っていない気もするけれど、いかにしてそれを捕まえるのか分からない。最近こんなんばっか。はしごが外されている。

もいっちょ追記。

DataServiceのTが扱っているEntityにNullにならない一意なIDになるものプロパティがないと、駄目だ。これがないだけで、全てがおじゃんになる。あとはEnumの継承型をEntityに含めることはできない。使えないんだよ。だから、大抵はint,stringのオンパレード。ちなみにDateTimeも使えない。これが痛い。使えるのかも知れないけど、とりあえず直接は入れられない。とりあえずこうすれば、コードを分割して記述してもいけるし、DLLで参照もできる。これもEntityをDBから作らないから、エラー出力をする属性も分からないし、調べ方も分からない。

Silverlightのためのいくつかの話

どうもJudaです。
Silverlightリファレンスブック
ASP.NET MVC実践プログラミング―.NET Frameworkによる標準Web開発技法
Silverlightで開発するデータ駆動アプリケーション
とりあえずこの3冊は現状で手に入る日本語のSilverlightまわりの書籍としてはとってもいい。

リファレンスブックは、「そうなんだよ、この実装をどうやるか知りたかったんだよ」っていうものがちらほら。
ASP.NETは、「そもそもSilverlightのクロスドメイン回避するWebサービスが必要だな」ってときに助かる。
データ駆動は、「Silverlightを使い倒してやる」っていうアプリケーション開発者にはぴったりな一冊。

ADO.NET Data Servicesに関する情報は少ないし、そもそもWebアプリケーションに関するビビッとくる本に未だ出会えていない。誰かご存じないですかねぇ。

どうもJudaです。
いきなりSilverlightというか、WPFというか、
Bindingで使われるDependencyPropertyの話をMSDNの項目からかなり抜粋するが、
細かな部分だが結構込み入った使い方をする。
依存関係プロパティは、DependencyObjectに存在するPropertyのことで、
DependencyObjectプロパティストアに格納されている。
このプロパティストアを所有するDependencyObjectは、
public static readonlyで修飾されるDependencyProperty識別子を使って、識別される。
この依存関係プロパティを実装しようと思うと、通常のプロパティ(CLRプロパティ)をラップする必要性がある。
この依存関係プロパティがなぜ「依存関係」プロパティというのかという一因は、
あるプロパティが別のプロパティを値としてい持てるからであり、
実行時までその値を評価するのを遅延させることができ、
そのことによってプロパティに依存関係を作ることができるからである。
これはBindingとも関連する。
このプロパティを記法は似ているが、異なる添付プロパティが存在する。
例えば、Canvas.Leftのような個別のオブジェクトが所有していないプロパティである。
この添付プロパティの実装は、依存関係プロパティと似ているが、
設定された値が、自身ではなく、要素に対する付加的な意味合いがある。

カスタムしたイベント群を作っていこうと思うと、後半の添付プロパティをうまく使っていかないと、
XAMLで楽をできない。
ましてや、サポートされていない機能であるDrag&DropやDoubleClickの基本構造を適応していこうと思うと、
添付プロパティを使わなくてはとてもコーディングできると思えない。

ただイベントの登録をどうするのかが若干困りものではある。
大まかにはわかるのだが、
Propertyとして設定しようとして
そのプロパティを呼び出したときのオブジェクトを知らせてくれるならば、
オブジェクトとともにイベントハンドラを持てばいいのだろう。

関連付けさえうまくできればなんとかできそうではあるが、煩雑なことにはかわりない。
あとはListBoxからのDrag&Dropに関しても、内部で取得されるItemsSourceが不定であるので、
Converterを指定し、さらにDrag時の描画や、Dragのイベントなどの処理まで考えるとうんざりしてしまう。
ちょうどいいことにライブラリはあるのだが、Telerikのライブラリいいんだけど、10万も出せません＞＜
でもこの機能で10万は安い買い物だと思います。
ちなみに体験版もあるので、ぜひ！

電子書籍の新しい形をサービスへ

どうもJudaです。

前回描いた電子書籍の新しい形をやっぱりサービスにしたい。

友人と話をしていてとっても勇気づけられたから、なんとか夏までにサービスに原型を作る。

そのときに新しくあるといい機能が出たので、メモしておく。

1. 本から別の本への参照機能
2. 気に入った部分のリスト機能
3. リスト公開機能
4. 書籍の情報入力の簡易化

とりあえずメモの共有機能をやるとどうなるのかやってみる。

Silverlightとの戦い

どうもJudaです。
Silverlightと最近は格闘中ですが、面白いです。TemplateやBindingはパワフルで使い出のあるアドバンテージです。これらの機能を使いこなすことでコーディング量を劇的に減らすこともできますし、自分の中のデータとビューの関係性を捉え直す機会もくれます。実に取り組みがいのある技術です。この先には、まだまだ多くの発展技術がいることを考えると、挫けそうですが。
それはそうとSilverlight4RCがきましたが、まだ確認をしていません。それよりなによりVerUpの頻度が多い気がします。それ自体は悪いことではないですが、技術書が出揃わないうちにVerUpされると出版側が手を出しにくくなって、困ります。ただでさえ、少ないのに。
ブログなどもいくつも見ていますが、重要なのは基本的な機能に十分習熟することと、Bindingをコード側からも理解することがかなり重要ですね。特にとっつきづらいのはCanvasとGridの実際的な制約事項。
Canvasは自由配置できるのですが、Grid内に配置しても自由に配置を出来ること。Gridのみの場合には、自由配置が全くできないので、XAML側での構造の構築には気を使わなければなりません。あとはDrag&Drop機能を使おうと思うときには、構造をよくよく見れば明白ですが、ListBotのListBoxItemはListBoxの外ではそのまま使えないので、取り出したあとなんらかのコンテナを必要とする点や、データ自体の受け渡しのみならば、別のItemSoruceをもつものとも融通がきくことなど。
実際にコードを触らないとあまりに些末で考えなければならないことが多いです。

Silverlightの開発環境

どうもJudaです。

Silverlightの開発環境はここをみれば、一発。だってここが本家だもの。

インターフェイスの使い方

どうもJudaです。
インターフェイスの使い方は疎結合のための考え方だろうとおもう。個人的にはpImplイディオムと似た匂いを感じます。ちなみにpImplイディオムの関連して記事
Pimpl イディオムのお手軽な実装
PImpl イディオム
pimplイディオムを語る
このイディオムの重要性は、その結合が粗であること。それによって得られる副次的な作用は、コンパイル時間の短縮、変更の容易さが得られますが、代償としてこのイディオムを知らない人に対してはなぜこのような実装をしているのかが、わかりにくくなります。
これは、開発者のレベルに差がある時には非常に問題になりますが、それはOOPも一緒だし、他の様々な実装方式も同一の問題を抱えます。
インターフェイスベースと言うとCOMですねー。COMあれもめんどくさい。
インターフェイスを重要視して開発すると実装の詳細はあまり関係はなくなりますが、十分に動作や手続を説明していないと使い物になりません。また実装が隠蔽されていることによって、慣れると手続きを構築するのは簡単になるのですが、それを学習するコストが大抵はソースコードをみることができないことによって増加しますし、関連ドキュメントがないことによってさらに増大っと利用に関しては結構な関門があるのと思います。
ここまで考えが至るプログラムを組むことに対して、思慮深くなる。うむむ。

ちなみに参考
プログラミングメモ - インターフェイスの使い方

NVIDIAのCUDAを利用したSolution

どうもJudaです。
とりあえずこれを見てほしい。

NVIDIA「OptiX」エンジン発表、GPUでレイトレーシングを高速処理
NVIDIA® OptiX™ ray tracing engine
引用、ただし体裁は変更。
System Requirements

• Operating System: 32 or 64-bit versions of Windows XP, Windows Vista, Windows 7, Linux
• CPU: x86 compatible
• System Memory: matches graphics board recommendations
• GPU*: NVIDIA Quadro FX or NVIDIA Tesla (GT200 class required for multi-GPU scaling and technical support)
• Frame buffer memory: varies with data complexity
• Driver: NVIDIA Unified Driver r190 or later, CUDA toolkit 2.3 or later
• C/C++ Compiler: Visual Studio 2005 or 2008, along with CMAKE
• NVIDIA GeForce to be supported with NVIDIA's upcoming "Fermi" GPU architecture- see OptiX 2 Beta.

今回のSDKのBeta版から計算用のGPUでなくても、実行可能になりました。
以前は40万からしかOptiXを実行することができなかったのですが、今回は2万円のGPUでも実行可能らしいので、とても楽しみです。
これはCUDAベースのライブラリ群です。開発用にSDKを取得するのは、ちょこっと登録すればダウンロードできるので、オッケーです。
でもGPUをまだ買ってきていないので、実験すらままなりません。どうしましょう、どうしましょう。

xUnit Test Patterns買った

どうもJudaです。xUnit Test Patterns: Refactoring Test Code, Mobipocket (Kindle Edition)
最近の金遣いが最低な人間レベルになっていることは気づいているけど、Kindleは便利だ。すぐに洋書が手にはいるのが素晴らしい。中古販売の権利はないから、もうちょい安くして欲しいと思うけど、さっさと読んで、できれば日本語訳をこっそり作りたい。
テスト系統の学習を早く業務に役立てて、会社に普及させたい。
周りを変えたいと願うなら、まず自分から。とりあえず情報系の大学卒者でいけ好かないやつを　m9　したい。学習コストを支払い続けないとどうなるのかを教えてやる（メラ