ちと補足
昨日JScriptの実行環境については割り切った用途以外の使い方はすべきでは無いと結論付けたワケだが、逆に言えば割り切った使い方なら良いワケで、決して収穫が無かったり、その方法論自体が無益と言っているワケではない;-)

例えば件の手法と合わせて、アプリのコア部分がコマンド的に呼び出せるコンポーネントに分割でき、全体の遷移がページ的になるのであれば、自前の拡張HTAホストのようなものを作成してonLoadでScript側に機能群をオブジェクトとして公開し、実際のアプリの画面などについてはhtml+JavaScriptを使用するような考え方もある.

少なくともその系統のクライアントアプリの外観がwebっぽいものがトレンドになっている昨今では、ホスト側のデザインさえある程度しっかりしていれば比較的分業やカスタマイズのコスト削減などに効果的だとは思う. COMとしてコンポーネントを登録する必要も無いので、オブジェクトの公開粒度がある程度細かろうが構わないし、互換性の縛りなども拡張htmlを読み込むホストのバージョンだけでコントロールできるので管理なども遥かに楽になる、.NETとの連携や外枠まで含めアプリの外観やアンカーの拡張など細かくコントロールでき、また分業や比較的容易に確保できる人材の技術レベルで分業体制を敷けるなどコストの点からは上手くやれば大幅にメリットは打ち出せる.

ただ正直個人的にはダイアログベースで全体の遷移が成立するアプリなど何で作っても同じという感覚で、正直目指す所にあるものでも無いカンジである為、趣味として扱うにはもはや興味に欠けるというだけの事 ;-)

---------------

ミスった、可逆演算の過程でイプシロン近傍で元に戻った場合の整数化がおかしな事になっていた、浮動小数型xについてx-1, x, x+1, x+2を個別に整数化した場合差が安定しない事をすっかり失念していた、間抜けX-<

BiCubicはやはり若干リンギングが強いのが難点か、「絵」なら大概の場合問題ないが記号的な「素材」の場合極端に非等方的に引き伸ばされ占有面積の近似が荒くなってくると場合によってはかなり目立つかも. かと言ってlanczos2は仕上り的にマイルド過ぎて好みでは無いし、lanczos3はサンプリングが更に増えるので現在想定している個所に適応するのは若干辛い気がする、かといってBiLinearはこの仕上りに慣れてしまうと論外のような気すらして来るし、、、うーむ、どうしたものか :-<

まだ内臓は本調子では無いもののほぼ回復、ここまで長引くとは正直思ってなかったのと久しぶりの高熱で (いつもは体調崩しても37度後半程度まで) 一時は正直どうなるかと思ったけどというカンジ、という事で仕事(?)再開なのだが送られてきたコードチェックして幾つか気になった個所の想定を聞いてみると俺のやること無いやん(爆死) みたいなカンジだったり.

病気空けでSYSTEMAXのサイトを覗いて思いっきり吹いた 広告でSAIのムックの写真が貼られてるだけの事なのだが、普段そういう事は絶対やらない性格だと思ってたので、うわぁ みたいな. ＫＯＪＩさんキャラクター違ぇみたいなカンジでもしアレであれば思いっきり揶揄してみようと電話で確認してみると、どうやら出版社の方から写真添付で依頼があったのだそうな、なるほどねー、まぁ色々あるらしい、そして先週も色々あったらしい(苦笑)(※1)

※1) ちなみに公式ガイドブックとあるけど、確認済みというだけで、別段SYSTEMAXが関わってるとか売れたら売上になるとかそういう話では無いのだそうな、結構よく見かける「公式」って実はアバウトなのかも(^^;;

SAIと感覚的には似た部分が多いので、今作っているペイントソフトの彩色部分のワークフローの考察にも使えるなら買ってみようかとも思ったのだけどamazonのプレビューに出てるサンプルに普通にドン引きしてしまったのでちょっと(苦笑)

---------------

ここ暫くは例のペイントツールの微調整やチューニングばかり、実験的なアルゴリズムを色々試す為プログラムはできるだけ簡素な作りにして殆ど小難しい最適化はしていないのだが、コンパイルオプションで-G7 -arch:SSE2オプションで最適化した所馬鹿速になってつい面白くなり、その速度で想定される解像度で快適になるよう各機能のチューニングを色々と、という具合.

暫くいじるものを変えて振り返ったら「どうでも良く」なっているので、暫く書いていたCOM-JavaScriptネタは破棄決定、やはり余りに配列のコストが大きすぎて、またGC実装自体の安易さから webページを飾る的な要素ならともかく、汎用的なプログラムとして多量のデータを内包する想定なども考慮するとエンジンとして全く使い物にならない & COMによる参照とGCがきっちりインテグレートできない事により公開Objectのデザインに大幅な制限されるなど、問題が多く、割り切った用途以外への適用はすべきでは無いと結論付ける.

、、、しかしそういった意味ではそのレベルのエンジンがシェアNo1の状態でのajaxというのは色々厳しい状況なのかもしれない、まぁ仕事にしてないからそれ程深刻では無いけど(^^;; (※2)

※2) 間違ってもじゃあクライアント全部にFireFoxを導入すれば良いなどと言ってはいけない、比較的見かける系統の議論ではあるが、ともすると陥りがちなエンジニアの視野狭窄で、別段クライアントの目的は「ソフトを動かしたい」のではなく「その結果が欲しい、手段は(楽であれば)何でも良い」のである事を忘れてはいけない、無論それを意識した上での刷り込みと意識操作の種まきとして発言するならまた別ではあるが(※3)

※3) 最近は(半)技術系の記事 (そういうプログラマ向けサイトにあるような) を見る時、気になった記事はその書き手の過去の記事の傾向やその周辺から透けて見える人間・仕事関係なども調べてからその記事を何故書いたかの意図まで含め考えるカンジ. またプログラム系のブログなどはその人間が実際に作っているものを調べて、どのような経験・背景事情・洞察からそういう発言が出ているのかなどを含め考慮するようになったのは良いのやら悪いのやら(苦笑)(※4)

※4) こういうのは議論においてはメタ的なすり替えにもなるから時にフェアでない事も確か、ただここ暫くの体験で口や周りの評判でどれだけ良い事を言っていても、結局エンジニアってのは実際に作ったものや一緒に仕事をしてみないとその実体は分からないものだなぁという話が余りに度々あったので X-< (ま、だからと言って余り(その時点での情勢に左右されうる)実績だけに妙に傾倒したり固執してしまっても「老害」になってしまうのでダメなんですけどね、 あくまで主張は常に検証・結果と対にてなされるべき (さもなくば単なるメルヘンに過ぎぬ、但し新しい仮定の提示と検証の可能性の検討は除く) という程度の話に止めるだけの事 ;-)

熱は何とか平熱近くまで下がった (まだ若干不安定だが、その前は38度台が3日も続いた、、、) のだがそれ以外の症状はまだ回復せず、どうも症状から見るに細菌性の食中毒の可能性が高そうな模様、症例としてはサルモネラ菌によるものが最も近そうなカンジ&心当たりもちらほら (先日食べた鳥料理の専門店の鳥刺しかあるいは閉店間際の半額になった卵を使ったお惣菜etc.)

珍しく小腸がやられたっぽく慢性的な痛みで未だ半分寝たきり状態、食事はここ数日栄養補給のドリンクとそうめんのみ、痛みが激しくなるので煙草もまともに吸えず (これはここ数年本数が増えてたから丁度良いかもしれないが) という事でまだ余裕があるなら安定してPC前に座っていられるようになるまでもう少し仕事の件待ってもらえると有り難いです＞某氏m(_ _)m

現在38.8度の高熱によりほぼ死亡中、脳の蛋白質の変質が心配につき思い付きのメモのみ.

以前書いたFPUの結果が環境によって変わるケースを考えてて、ふとmsvcrtも共有リソースだし、ショボい常駐プログラムと併用すると十分ランタイムを不安定にし得るよなーとかそんなカンジ、不安定にならないケースでもスレッドによる割り込みでのsrandとかは心配(※1) フィルタとか実装するプログラムでは真面目にlibcmtの使用とどちらがベストかまで考えるべきかもしれない. まぁ無論他にも沢山dllがプロセス内で共有されているうちの一つと言えばそこまで、ただ他が元々APIとしてデザインされているのに対しランタイムはそういう環境を想定していないデザインを無理矢理dllに乗っけたカンジだからという所.

意識がかなり朦朧とするので備忘録X-<

※1) 安易にMT(メルセンヌツイスタ)などと言わない事:-P 確かに標準の線形合同法の乱数はシミュレーションなどの分野(や暗号)にはダメダメだがある程度真面目なシミュレーションなどを行わない限り一般向けのプログラムでそこまで系列の問題が顕著になる事は無い、例えモンテカルロ系のアルゴリズムでも厳密なものでは無くエンドユーザー向けにブレークダウンしたものでは実はそれ程差が出なかったりする. 真面目な分析なしに掲示板のレスなどで得意げに書いてると時々恥ずかしいなぁと思う事があったり、などと最後に毒を吐いておく(えー

固有名詞を含むのでどうかとは思ったのだが、あまりに面白かったので紹介 (クレームがあれば削除しますm(_ _)m

cppllで交わされた浮動小数点の取り扱いに関する議論

まぁネットでよく見かけるタイプの議論ではあるのだが、ここには数値計算を専門に扱うプログラマと普通のプログラマとの大きなギャップが見て取れるという所、実際先の日記の内容とも少々かぶるが、数値計算の専門家などが余りに数値計算について世間はおざなりに見過ぎると嘆く話は比較的よく聞く事、そしてそれを専門に扱っている人間にしかその「気になる部分」というのは理解されないという数値計算屋とその他のプログラマのギャップを端的に現している気がして、一連の議論は非常に興味深い (無論該当スレッドでは多少論点の進め方に問題があり、上手く話がかみ合ってないという問題もあるが.

まぁ、この辺は苛立ち、怒りという感情が非常に端的に人間の背景を現すのが面白いと感じるからかもしれないが(^^;;

数学屋と他のエンジニアの断裂は余りにギャップが激しい (例えば数字の丸め方向や最適化や処理系により極限付近の精度が不定である事が問題であると言っても大抵何がそんなに問題なのか理解してもらえない) が、同じような「断裂」はソフト屋とハード屋、アプリケーション屋とWeb屋とエンプラ屋、またLL系メインのプログラマとアセンブラとCを併用しなければならないプログラマなどにも見られる.

世間一般で一括りに「エンジニア」もしくは「プログラマ」といってもその常識は別の国と同じ位のギャップがあり色々考えさせられるというトコロ.

# なお僕自身は普通の業種のプログラマに比べると数値演算の厳密さを考えねばならず、ただ数値計算屋から見ると僕のやっている内容などは児戯にも等しいという事で丁度コウモリみたいな位置にいます(苦笑)

---------------

なお友人と丁度話題になっていたのだが 浮動小数点数->整数のキャストは意外とコストがかかるという話

実際自分の経験でも浮動小数を使った計算を中途半端に整数化すると逆に遅くなってしまうのは良くある話、とは言えそれ程クリティカルになった事は無いので漠然とキャストが重いんだろーな位で真面目にチェックはしていなかったが、案の定.

、、、多くの言語で多用するのは分かっているんだからIntelも専用の(１命令で完了する)FPU命令用意してくれていれば良いのにorz

スレッドプール実装のデバッグの為に全然使っていなかったHyperThreading機能をオンにして検証、HyperThreading自体今更感はあるが、ちょっとした検証レベルで割と普通の組み方をしたルーチンではせいぜい30%程度の向上、まぁ大体は公表通り、但しHyperThreading ONにするだけでパフォーマンスが10〜15%低下しているので実質20%程度とそれ程嬉しくない、整数レジスタだけしか使っていない極めて単純なものでは200%近い数字が出てたのでスケジューリングには左程問題無くやっぱりHyperThreading自体がCPU資源のかなりの部分を共有しているのがネックになっているのかも、などと思い巡らせながらつらつらいじる.

複雑なものでは全然速度が変わらないものも結構あったりで、まぁ何となく流行らなかった理由も納得. なおスレッドの同期の部分でクリティカルセクションを使っているのがパフォーマンス的にどうなのか気になっていたのだけど、自前でInterlockedExchangeでスピンロックしての同期でもそれ程変わらなかったので、思ってた以上にオーバーヘッドは少ないのかもしれない.

TANEさんとこの6/1の日記ネタ

そういえば余り見かけませんね(^^;;＞自前のGUIツールキット

一応 (知っている人は知ってると思うけど) 以前会社勤めをしていた時はWindowsのクライアントサイドのソフト中心の部署にいましたが、社員についてはごく一部を除いて余りアテにならないので除外して(ぇ そこに来る外注さんなんかとは良く話をしたのですが、やはりMFCが中心で後はVB系の経験者、Win32の比較的細かい話が分かるのは5人に1人程度、後は稀にマニア系でVCL(Delphi/C++Builder)で、プライベートまで含めGUI部分を自前でやっている人は見た試しは無いです. 母体の方の仕事なんかも面白そうなプロジェクトは色々話を聞いたりしていましたが、それもMFCが中心. ただ有名メーカーとは言え中身は惨憺なものなので極端な言い方をするとライブラリを作るという考え方すら未熟な部分があったとは思いますが(^^;;

後は 「そういう設計系に傾倒したマニア」 が関わっているプロジェクトで再利用可能なライブラリという形でかなり大規模かつ膠着したものをぶち上げてしまい、結局製品ラインに乗せるにはメンテナンスコストがペイしないで消えて行くとか、そのプロジェクトが終わると誰も見向きもしない (依存関係が多く把握するだけでも一苦労なので) で消えて行くというパターンは結構あったように思います、ただこれも完全に0からフレームワークを構築しているものは見かけませんでした.

Win32メインで組んだ経験となると唯一聞いた話はゲーム屋さんでの経験者の話位でしょうか、これもGUI的にはフラットなフレームバッファが1枚あれば良い話なので余りアテになりませんが(^^;;

ただ趣味でソフトのdependencyやGUIのWindowクラス構成 (RegisterClassのアレ) などを眺めるのが好きなんですが、オンラインソフトや市販パッケージで割と凝ったソフトなどは自前のWindowクラスで作っているものが多いのですね、無論MFCのアプリも見かけるのですが、比率としては1:1か下手するとMFCで作っているソフトの方が少ない位で僕の(少ない)実社会での経験上のサンプル比率とは大きなズレがあります. Webで見かけるWin32のサンプルはグローバル変数などを多用してフラットなものが殆どなので、これがサンプル故の簡便さの為なのかやはりWin32でフラットにゴリゴリ書く人が多いのかは不明ではありますが.

Webを見回すとフリー/シェアウェアなどを作っているプログラマは沢山いる筈なのに、何故か実社会ではついぞお目にかかれないという不思議と似ているかもと思ったり.

# ちなみにGet/SetPropを使う方法はKOJIさんがsaiでやってる方法を頂きました、自分も最初は別リストでインスタンスとWindowハンドルの対応付けを管理していたのですが、本来Window個別の情報がグローバルと絡んで2重管理になるのが気持ち悪かった&柔軟性に欠ける気がしたので. これ以外にはSetWindowLongを使う方法もありますが、これは1つしか設定できないのでライブラリの組み合わせで競合が起きる可能性があるという事で除外しました.

一応KOJIさんのsaiや仕事のプログラム、自分もこの方式で幾つかの仕事や例のペイントソフトなどでも多用している方法なので、それなりには大丈夫なんじゃないかなーと言う具合で、今の所これが原因で起因する問題は発生していません. 実際にはあの基底クラスとコントロールの薄いラッパ、Windowのリサイズのアンカーライブラリやカスタムコントロール、ビットマップ操作、文字列・数学処理などのライブラリがほぼ独立、もしくは最低限1〜2ファイル程度の依存関係である状態が今の自分のメイン環境になっています. (ついついフレームワークを作ると「世界」を記述したくなるのですが、上の話や抽象化の漏れが常に存在するごとく結局膠着してしまうので、紆余曲折を経て最近はシンプルで薄ければ薄いだけ良いという発想に落ち着いてます.

---------------

以下独白、Win32+自前フレームワークが (デスクトップ) ソフトウェアを作る上で良い選択なのかはまだ少々疑問が残る所はあるのですが、反面Win32をメインで使うようになってから会社時代に 「MFCのテクニック」 として知られていた多くの内容が単にフレームワークの想定外を回避する為だけの無駄なもので制限がWin32だけの環境ではなんでもない話な事が多い事も痛感しています. 分厚いフレームワークの難点はある機能を実装する場合にシステムの制限とフレームワークの制限の両方を考慮せねばならない所にあり、その枷が無い状態でシステムの限界のみで自由に作れる事が (最初の敷居は高くとも) こんなにも楽なものなのかと実感する次第です.

Win32の難点は情報が分散している所とクラス化のような情報の集約に関する資料が極めて少ない事にあり、ポインタを隠蔽してガベージコレクタに依存させる最近の流行もそうなのですが、抽象化には常に漏れがありそれを隠蔽しようとすると下手な嘘を重ねるがごとくその隠蔽技術がどんどん肥大化して行きながらも、ある一定以上の規模で顕在化するソフトウェアの「構造」の難しさについては何も隠蔽しない事を考えると、最初の難しい1ステップを避ける事が本当に良い事なのかは最近は多少疑念が出ています. その辺を見極める為にスクリプトや.NETなども積極的に触るようにしてきたのですが、常に導き出される結論はOSがC/C++ (もしくはアセンブラ) 環境を前提にしている以上 (フレームワークの想定以上の) ある程度以上詰めたアプリを作るならそこに親和性・柔軟性の最も高い環境で作るのが最良であるという結論になってしまっています. (銀の弾丸などは存在せず、よくある言語論争などはそれが汎用的な主張ではなく、単にそれを主張するユーザーがそれ以上のものを必要としていないから成立する一方的な背景に過ぎないという具合)(※1)

実際例のペイントソフト (あれは一般のユーザーが業界やプログラマの都合など関係無く「ソフト」としてイメージする標準的なソフトを作るコストの見積もりの実験でもありました) のコアの部分は大体4ヶ月でしたが、同様のものをMFCで同じ期間で作ろうとすると今までの経験からしても正直無茶な気がしますし、GUIの細かい部分を詰めるのはVCLでも難しかったのではなどと感じます.

残念ながら上のコンシューマがイメージする平均レベルでの「普通の」ソフトを作っているプログラマが 「沢山いる筈なのにお目にかかれない」 不思議と相まって、未だ結論を出すにはサンプルが欠けています、ただ世間に出ているものから透けて見える仮説はともすればIT業界のメソドロジー傾倒のマッチポンプ的な文化の全てを否定する(※3)ような結論に辿り着くのかなぁ、などとも正直薄々感じてはいる所です.

※1) 逆の言い方をすればその想定に収まるならその中で最も効率的な開発環境を選べば良いという話でもあります、ただ常に道具は道具、ある言語を使えば魔法のように「僕でもできた」を実現するものでは無く、常に最後は人に集約されると言うのが正直辛い所です(※2)

※2) 上の会社勤め時代以来、傲慢な言い方になりますが 「何故プログラマにプログラムが書けないのか」 という現状のIT業界の惨状は常に僕のトラウマとしてその後を蝕んでいます、某氏には 「他人に期待などする方が間違いだ、その中で浮かび上がってくるものだけを見れば良い」 などとも言われてしまいましたが、企業として本来そうあるべきでは無いという信念から、ここ数年の様々なメソドロジーや開発環境、LLなどに対する傾倒はメルヘン的な言い方をすれば銀の弾丸探しであったと言えます、そういう意味では一周して当たり前の帰結に戻っただけなのかもしれませんが、不特定多数の人に期待するなど無駄な事、となってしまう為正直非常に苦々しい帰結でもあるワケですsigh. X-<

※3) 厳密に言えば否定するというよりは、その前にある大前提が欠けているという所、すなわち「全てはまず人ありき」という話から目を背けているという所になるかもしれません、即ち「ヤムチャはヤムチャ」という具合で(えー

以上、７つの大罪の一つ、傲慢なプログラマの独り言でお送りしました、なれば地獄の業火に投げ入れられるは我也哉(苦笑)

# まぁ別に慢心するつもりも無いです、逆に今回のペイントソフトでようやく一般のイメージと乖離がないソフトウェアを作るに至った所でようやくプログラマとしてのスタート地点に立てたのかなぁというかまぁそんな具合、、、って今更スタート地点とかって世間ではプログラマは35歳で定年とか言われているワケですが(爆死) 、、、まぁ物覚えが悪いのは否定できんですよ＞自分 orz

という良く見かける言い回しはこういう使い方で良いのだろーか(笑)

まぁ一部には話したのだが、ここ暫く浮動小数の扱いについて余りに知られていないで「おまじない」的になってしまっているのが目に付いたので登録制の掲示板などには書かない主義なのだけど、つい突っ込んでしまったという話.

実際ちゃんと扱おうとすると浮動小数型というのは概念だけでもポインタと同等か、下手をするとそれ以上の難易度があるテーマなので、あまりおろそかにするのは良くない気もするのだが. ただポインタとの違いはポインタはそれを知らないで扱うと「落ちる」のに対し浮動小数演算は「落ちないで何となく動いてしまう」という所かもしれない :-<

余談だがVC++では殆どの浮動小数点演算の例外がマスクされてしまっているので、自作処理系のコードの抜粋になってしまうが、計算アルゴリズムの検証の場合こんな具合

unsigned int flag=_control87(0,0);
_control87(_EM_INEXACT,_MCW_EM);
try{
    ...何かの処理
}catch(runtime_error e){
    _control87(flag,_MCW_EM);
    throw e;
}catch(...){
    unsigned int st=_clear87();
    _control87(flag,_MCW_EM);

    string type="unknown?";
    if(st & _SW_UNDERFLOW)          type="underflow";
    else if(st & _SW_OVERFLOW)      type="overflow";
    else if(st & _SW_ZERODIVIDE)    type="zero divide";
    else if(st & _SW_DENORMAL)      type="denormal";
    else if(st & _SW_INVALID)       type="invalid";
    //else if(st & _SW_INEXACT)     type="inexact";

    eval_error(t->line,"FPU exception(%s) detected in checked statement",type.c_str());
}
_control87(flag,_MCW_EM);

にチェックしてやると演算の特異点の検出に便利かもしれない. _EM_INEXACTフラグは非厳密結果例外 (値の指定で丸めが発生した事をレポートする) で一見便利そうなのだが0.01など値の2進化誤差までレポートしてしまうので不用意に設定するとプログラム自体がまともに動かなくなるので注意. またOpenGLなど一部ライブラリの内部などでは問答無用でオーバーフローなどを起こしているのでグローバルで有効にすると色々えらい事になるので注意 ;-)

まぁもう一つのテーマであるポインタは「落ちる」為IT業界のトラウマにまでなっているのに対し、こちらは「何となく動く」から数値計算の専門分野以外では下手をするとかなりやり手のプログラマにまでおろそかにされているのはイカンよなぁ、などと思うワケです :-<

※ 余談だがこのFPUレジスタの設定は本来言語やOSの管理に近い部分なので 行儀の悪い常駐プログラムや共有DLLなどで下手にいじるとえらい事になる. 演算精度や丸め方向なども設定できる為、場合によっては同じプログラムであっても環境で結果が違うなどという状況を引き起こすし、例外マスクの操作によっては本来クラッシュする筈のないプログラムがクラッシュするケースもある、また悲劇的な事にこの辺の規定は言語ランタイムによっても相違がある.

実際saiのクラッシュレポートでも本来発生する筈のない (VC++の場合FPU例外は全てマスクされている) 浮動小数例外によるクラッシュがレポートされている (流石にこういうのはプログラム側では何とも出来ないしユーザーの自己責任として放置する以外無いのだが) そうな、やれやれX-<

---------------

少々スランプ気味、考えが散漫になりどうにもコーディングに手がつかない、まぁ数ヶ月に1回程度ある話なのでこういう時はダラダラするのが吉.

少々脱線してコントロールパネルアプリの作り方を調べたりJavaやActionScriptをいじってみたり. コントロールパネルの方は思いの他簡単だった、直にリンクするのは気が引けるので詳細はCPlAppletで検索のこと、MSのサイトの情報などではCOMがどーたらなどと書いているものもあったが、基本は特定の関数エントリをエクスポートするだけのdllを拡張子をcplに変更してsystemディレクトリに放り込むだけ、至って簡単.

まぁ実際使う事があるかどうかは不明だが、システム寄りの常駐ソフトで頻繁に設定の変更を行わないものであれば設定がコントロールパネルに存在するのも妥当な所だろう、というカンジ. まぁ割と見た目だけの問題であるのは否定せぬが、エンドユーザー向けのプレゼンでは見た目が非常に重要(※1) その辺に胡座をかいていられるのは受託で発注したユーザーがどうしてもそのソフトを使わざるを得ないという背景があり、ターゲット層と事業戦略・顧客拡大の路線などを総合的に加味する場合には打てる手数は多ければ多い程良い ;-)

※1) 大多数の「コンピュータに詳しくない」ユーザーは見た目が90%まずいソフトを見ると、そのソフトの90%がまずいと判断する傾向にある、思いとどまってそのソフトの機能がどんなに便利かなどとは考えてくれない、また心理的な印象で対象が能動的働きかけを観測者に行えない状況での第一印象での評価を覆すのは非常に難しい、心理学の実験では評価が悪い→良いという順序で更新される場合に最大利得を得るという研究結果があるので、意図的な戦略としてそれを狙うのでなければ万全を期しておくに越した事は無い. よくこの手の反対派が言うように「見た目は決定的な要因では無く、中身である」という反論は確かに真実だが、正確には見た目で受諾される事は無いが棄却はされる、という所 :-P

---------------

Javaの方は既存のWin環境でのGUIとしてはイマイチだが、新しいMetalのOceanテーマが以外に (デザイン的に) Webとは合うのではなどと思ったので、ただ実際触ってみるとやはりAppletは起動の重さが致命的でやはり非特定クライアント向け用途としては無理がある. 問題は初回のJREの起動でブラウザのプロセス空間にVMを読み込み初期化する個所にあり、VMが常駐している状態では (標準で起動時にフォーカスを奪うのはともかく) flashとほぼ同等の速度で起動できる. ただブラウザを一旦閉じるとやり直し、また初回起動で10秒超待たされる.

それならばという事でCOM経由で裏でブラウザにVMを読み込ませた状態で起動して常駐させておけば良いというカンジで常駐ソフトを作ってみた所、flashよりも快適に起動するように、常時この状態を維持できるならクライアント用途としてもまだ選択肢がありそうではある. 但しIEが常に単一プロセスで起動するなら問題無いが、既存プロセスにアタッチされるのはダブルクリックでの起動などに限定され、exeのクリックでは別プロセスになってしまう. また既存プロセスへのアタッチもVM読み込み済みのブラウザの後でexeのクリックにより別プロセスのIEが起動した場合にダブルクリックを実行すると新しい(VMの読み込まれていない)exeにアタッチされてしまい、やはり初期化で10秒待つ事に、公開されているインターフェイスだけで抜本的に解決できる方法は思いつかず (BHOならプロセスごとにインジェクトはできるが、非表示でこっそり起動ができないし :-<

一応調べた所では最近のUpdateではアプレットの起動が改善されているらしいという事で無印1.6.0から1.6.0 update 6に変更してみた所確かに複数回の起動では1.5倍〜2.0倍程度効率化されている模様、ただ統計的な改善なだけで、、、初回ボトルネックはほぼ変わりなしで相変わらず10秒近く待つ事になりやはりダメダメ :-<

かたやActionScriptの方 (MTASC + 関連ツール使用) はとなると素の状態ではサポートされる機能が少なく (Flashには幾つかコントロールライブラリが付いて来る模様だが) いちいちリソースの参照など間接的な手間が多い為殆どを自前で作らないと駄目である事、また速度的に向上していると言っても速度はやはりスクリプトスケール (本格的なVM系ランタイムの数100倍スケールで遅い) という事もあって余り複雑なライブラリを書くのはかなり躊躇いがある、オーサリングソフトとの組み合わせでは化けるかもしれないが、今の所コード書き主導での開発はやはり難しい印象.

Ajax系のネタである画像とDHTMLを無理矢理組み合わせてコントロールを作る所にはやはり無理があるなぁという思いからJavaとActionScriptをいじってみたのだが、未だ決定打は存在せずという所か、今の所Win32メインで作っていての所感としては (分野によるばらつきはあるが) 意外に標準的なコントロールの組み合わせだけで改善できるワークフローには限界があり、それ以上のインタラクティビティと効率、操作感を求めるなら結局カスタムコントロールを作る所に注力すべきとの結論に到達し、別の分野でも同様のデザインを実現できる素材を得たかったのだが、なかなかそうもいかない模様.

無論上の話はユーザビリティに富んでいても状態遷移系が増えるにつれメンテナンスの複雑度が指数関数的に上昇する為、開発のスケーリングにおいて良いかどうかは大いに議論の余地はある、伝統的にコアは少人数での開発が主であったパッケージ系分野特有の側面もあるかもしれない. またモノリシックになりがちである為不定要素への接続の柔軟さには大いに劣る. その辺は業務系とパッケージ系での価値観の比重の違いがあるのも事実. ただそういう事はさておき、やはり作る以上は良い道具とは何ぞ、あるいは思考と実行のマッピングのダイレクト性がもたらし得る可能性とはという所を追ってみたいと思うはエゴ也哉.

まぁそんなカンジでここ数日は脱線気味 :-)
、、、一応例の宿題は終わってます、素直に消失点を算出して再計算するよう修正. なお例の解析解の導出部は僕は結局面倒な個所は数式処理ソフトを使って検算しながら出したのだけど、手動だけで展開するとやたら面倒かも、とまぁ分かる人にだけ分かるネタで〆.