という事で取り合えずの組み込み完了

ロゴとかに使う場合ちょっとパースで引き伸ばされる個所のボケが気になるなー、、、まぁ大解像度で素材作れば良いだけなんだけど(^^;;

まぁたまには毛色を変えて

「10年は泥のように働け」「無理です」――今年も学生と経営者が討論

暫くしたら前回同様そこかしこで火が吹き上がりそうな話だなぁ(笑)

別に経営側も裏側にある論点としては間違っているとも思わないのだけど (社員の立場と経営側では果たすべき責任の対象も大きく違う) 議論に窮したか「言っちゃいけない事」を言ってしまっている気がする、ここで経営者が言っている内容をその会社の社員が聞いたらどう思うか、というカンジ.

マクロ的な経営も支えるのはあくまで人、それを忘れると足元をすくわれかねない、統率の中では爆発的に発現する事は無いが、ジワジワと蝕んで行くもの、時にエラく (「偉く」ではない;-) なるとそれが見えなくなるのかなぁなどと思い (まぁ経営者の責任だけでなく周囲の思惑もあってそういう情報が上がってこない・隠蔽されるというケースもあり同情するケースもあるが) ただ人間的にできているが故に上に立った時に経営者としての采配を振るえぬのも見てきたので、どちらが良いかは知れぬ.

まぁ反面上のようなストレートな言及は高度成長期ならいざ知らず、かつて政治を論じる事が学生のたしなみであった時代が、学生運動の失敗を経て政治を論ずるのは格好悪いとなったがごとく、新たな価値観としてビジネスを論ずるもまたバブルの崩壊と共に守りに入った企業が終身雇用など保証してくれない事が露呈し社員との関係も崩れる、既に時代は「真面目に会社の為に働くのは格好悪い・馬鹿馬鹿しい」時代なワケで、それが学生に伝わる事はあるまい (余談だがこれと近年のナショナリズムの高まりとの因果関係はおよそ興味深い;-)

今でも心に引っかかるのはかつて会社を辞める前に社長とした会話、そしてその後のトラブルによる引責、また役員直前まで行ってその役を辞し去った者、夢を追いながらある意味挫折し失意に去る者、また初めからそれらを見捨てて己のみ信じて生きる決意を下した者、あるいは盲目的に傾倒する世界以外受け入れずなんとか自我を保とうとする存在になってしまったかつての友人達、さまざまな人間模様を見つめ人生とは何ぞと問うは愚問也哉.

まぁこのような話を半ば世捨て人然とした生活を送っている僕が言う事自体冗談と言えば冗談、として落としておく:-P

昨日書いた遠近感について、真面目に考えればそれなりにという事で対辺の比をz指標として上手くパースペクティブ補正を算出する事で何とかなったカンジ、後は境界などの処理をもう少し詰めて例のペイントソフトに組み込み予定.

なお一昨日の3,4次方程式の解は検算の為にグローバルな比較誤差を調整する個所が求解の前に入っていた為判定条件が上手く動いていなかったという間抜けな話が原因、修正すした所これも問題なし. ただ実数解の場合でも途中で複素数が発生する為、これをそのままC++のライブラリ化するかどうかはまだ未定、まぁ用途によっては初期条件による収束先の見積もりや調整無しで安定して任意の解を得られるので少し便利、ただ現実の問題では性質的に1変数の式という制限でそれ程ピンポイントで当てはまってくれる問題はそれ程多くないというカンジ、まぁ手法を理解する上で式の展開などあれやこれやいじるのもまた楽しかったので良し.

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

TANEさんとこにMML実装の結果が発表されている模様、矩形波とは懐かしいなぁなど妙にしみじみ(笑) ソースも公開されているカンジで、本来はwaveによる波形合成のサンプルなんだけど、ついついスケルトンの方に目が行ってしまったり、win32は決まったフレームワークみたいなものは無いので、クラス化の部分から人それぞれのああそういうやり方してるんだ、みたいなのが見られるのが妙に楽しい.

ちなみに自分の使っているwindowクラスの基底はこんなカンジで、こんなやり方もあるんだと思うも良し、結構間抜けな事やっているとニヤニヤするも良し、KOJIさんのコードを見た時もそうだけど、GUIの取りまとめの部分は人それぞれやり方があるなぁなど見ていて結構興味深い(特殊な趣味かもしれないけど(^^;;;

まぁ取り合えず悩むより先にという事で作ってみた(bmpファイルをexeにドロップで起動、表示画像の四隅をドラッグで変形) なお画像計算は最終品質で使うバイリニア+面積計算のものを使用している為、確定にはワンテンポ時間が必要、サンプリング見積もりは安易な隣接によるds,dt算出に経験則的なバイアスを少々.

後は遠近感かぁ、、、この式にはちょっと組み込み難いかもなぁ(遠い目)

アイコン作っていて、ふとsaiに持っていって自由変形してみる

、、、うーん、素材作りとしてはこういう使い方も悪くないかも、というかちょっと面白い(笑)

まぁ、あくまで使える形が限定されるので、本当にそういう使い方したいなら3Dと合成しろって話になるのだけど(笑) 本当は変形も自前で持つのが良いのだけど、今の所速度と品質の両立がまだイマイチ:-<

追記)
どんなもんでしょーねぇ、うーん.

安いコストで占有面積を見積もれると良いのだけど、、、インターフェイスも考える必要あるし、色々あってかなりテンション低めなんでなんかめんどくさい(えー
saiと連携できるように作ってるからどうせsaiにコピーして結果取得しても良いワケだし、ってそれを言っちゃおしまいですな(苦笑)

ついでに3,4次方程式の解析解のルーチンを作ってみた (3次はカルダノの公式, 4次はフェラーリの方式にて) けど誤差で阿波踊りするのはいつもの事、3次の方は素直に組んでも5桁程度は安定だが、4次の方は累積誤差が大きくてそのまま機械的に組んだら駄目っぽいX-< 複素数演算まで含む式の演算解析するのは面倒なんで継続するかは未定. 余り使わないと言えば使わないのだけど.

ちなみに5次は楕円関数を使うと解けるのだそうな、ってそこまで行くともうサッパリですわorz

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

ATLのatlhost.hのウィンドウクラスはバグっているらしい (参考) GetDropTargetでコールバックしているの処理に問題がある模様、道理でIDocHostUIHandlerDispatchアタッチしたWindowでDrag&Dropが使えなくなっていたワケだ:-< ヘッダファイルのみなので上のアドレスを参考に修正したものを優先的にincludeするよう指定すれば動くあたりは有り難い所. まぁ個人のメモ代わり.

昨日のシェルコントロールにIDocHostUIHandlerDispatchをアタッチしたらWS_EX_CLIENTEDGEっぽくなる件、Window情報をダンプしてみた所外見上の変化はあってもアタッチの有無でIEサーバまでのスタイルが変更が無い事からどうも勝手にIEのレンダラがやっている処理っぽい.

[016701cc]yash.exe::Internet Explorer_Server id:0 style:56000000 ex:00000000 ""
[014701be]yash.exe::Shell DocObject View id:0 style:56010000 ex:00000000 ""
[011601aa]yash.exe::Shell Embedding id:0 style:56010000 ex:00000000 ""
[017601b6]yash.exe::AtlAxWin id:0 style:50000000 ex:00000000 ""
[010c01c6]yash.exe::NWindow Class Name id:0 style:16ca0000 ex:00000110 "yash"

まぁこれだと手の出しようが無い、documentのプロパティで何かあったかもしれないが、内部のコンテンツについてはこの段階では関与しない方針につき万事窮す、まぁ枠線があっても情報表示用など領域が明確なら問題なし、単純なコントロールではコンテキストメニューは諦めるべしというカンジかも (ってコントロール代わりに使うつもりかというツッコミはあるが(笑)

TANEさんとこでMMLの話が上がってて、そういえば昔midi用のMMLライブラリ書いたよなぁ、などと思い出し引っ張り出してみる、こんな具合 (実行すると下手なきらきら星を延々熱唱するので注意) 確かリズム音パート専用コードに割り当てる項目を考えるのが面倒で放置した記憶がある.

実の所音楽は全然得意じゃないので (小中学校共通信簿は2ばっかりだった、美術は5だったんだけど(※1) そういう人間が作っても申し訳程度にしかならないだろうという思いもありなカンジで、まぁだからどーしたというワケでも無く、ふと思い出しただけというような具合(笑)

MMLも昔のPCには標準装備だったりするワケで、昔は簡単に音や絵が出せたんだよなぁなどと思う. saiの状況なんか見るに現在は開発層とユーザー層は完全に乖離してしまっているなぁなどとも実感するので、ソフトに不満があってもじゃあ自分で作れば良いじゃんという所にほぼ誰も発想が行かないのが傍観者としては面白みに欠ける所もあるのだが、まぁそれだけ一般化したという所か.

※1) 周囲に聞いてまわると大抵どちらかが得意なタイプはどちらかが苦手というケースが多いように思う、どっちもパッとしない層を除外すれば大抵が美術が得意で音楽がやたら苦手か、その逆という人が多いようなそんな印象、まぁ余り真面目な統計では無いけど(^^;;

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

スクリプトでIEイベントのBeforeNavigate2が取れない件、cancelパラメータの参照をサポートしていないからかなぁと思っていたが、sinkに来るパラメータをよくよく見てみると、VT_BYREF|VT_VARIANTで来るパラメータの一つが指している先が更にVT_BYREF|VT_VARIANTになっている、もしやと思いそのパラメータを1段階のVT_BYREF|VT_VARIANTに変換してスクリプトに渡してやると、、、見事に取れました. どうもこれが原因でIDispatchの呼び出しが失敗していた模様、状況はIE6環境にて確認.

というかバグってるやん :-<

なおJScriptでは残念ながら引数は実体になってしまう為ナビゲーションのキャンセルは出来ず、ただ有意義な機能なのでバグ対応と合わせて特化してしまうか、あるいはナビゲータコントロールを別途用意しても良いかもしれない. しかしこちらは片付いたもののhtmlコントロールで自前のコンテキストメニューをハンドルする為IDocHostUIHandlerDispatchをアタッチしたら何故かWS_EX_CLIENTEDGEスタイルが発生してしまっている模様、何だこれはorz

# まぁ何と言うか、そんなにインターフェイスがhtmlの方が楽ならWin32アプリでもインターフェイスはhtmlでやってコールバック先だけNativeで実装すれば良いやん (半ば自棄っぽく) みたいなカンジで. まぁXAMLとかの発想もそういう所なワケですが、 ただhtmlの場合見栄えは良いものの、アルバム程度のアプリ以上の突っ込んだ対話的操作を考えると余り使い物にならないのが難点か、逆に会計ソフトのような半POS系のアプリには向いているかもしれない. dhtmlでguiパーツまで行くと損益分岐点を越えて馬鹿馬鹿しい事になるので限界はあるが、ただ少しでも楽に見栄えも含むソフト製作のコストが抑えられれば良いかなぁ、みたいな. (特に国内ベンダーの業務系のソフト屋の絵心の無さはある意味致命的だ (僕を含め、ね) 外注を一人削ってでもデザイナーは是非確保すべきだと思う;-)

JavaScriptの問題というよりはMSの実装の問題だが、現状配列が戻り値になる個所はVBScriptではSafeArray、JScriptではArrayクラスに変換して返しているのだが、JScriptの場合Arrayクラスのコストが余りに高すぎる.

例えばバイト配列で10MB程度のファイルを読むだけで全く反応が無くなる、読み込み粒度を512kb単位などとすれば実行時の速度低下は抑えられるが、それでも30秒以上かかり、更に GCが発生すると数分待たされる またスクリプトエンジンのシャットダウン時にも最終GCが走っているようで処理完了後実際にプログラムが終了するまで数分という体たらくで、正直遅いとか以前の問題で全く話にならない:-<

理由はJavaScript自体の配列のデザインが実質ハッシュになっている為元々冗長なのに加え、MSのJScriptエンジンのGCが単純なfull GCのみでしかも余りパフォーマンスの良くない実装になっていると考えられる (幾ら大量の要素が絡むとは言えGCの相互関係解析の部分で下手な作りをしていない限りここまでは遅くならない)

解決策はライブラリで配列を返す個所を全て独自のCOM実装での配列に置き換える事だが、これをやってしまうとエンジン上の制約からプロトタイプをいじって拡張した配列の機能などは使えない事になり、 またCOM制約上格納を値型のみにしなければ容易に循環参照が発生し得る等の制約があり余り一貫性及びシンプルさの観点から望ましくはない.

VBScriptではCOM Invokeのオーバーヘッドが比較的大きくVariantの生成コストも割高な為、複雑な処理をさせると他のLL系に比べ速度低下の比率が大きいものの、ここまでの不安定要素は無い、ただ正直VBScriptでだけまともに動いても全然嬉しくない(笑)

、、、さてどーしたものか:-<

# まぁこういう話があるから、既製品よりは言語から実装する方が最終的に早いし総合的なクォリティも維持できるというのは根本的に真であろう、ただ今回の件では既製品の処理系を選んだのは少々別の意図もあるのでその部分に身もフタも無いツッコミを入れるのは無しの方向で＞周囲

まー当初意図したデザインのヒントやプログラム上の収穫は既に大分得られているので拘る必要も無いのも確かですが(苦笑)

ここ暫く文字列がUTF16な環境 (JScript & VBScript) なワケだが、バイナリと文字列が相互可変で無いのが妙に面倒で駄目なカンジ、無論文字コードがある程度制約できる連携に限定できるならアリなのだが、バイナリファイルをいじったりraw socketを扱って入力からエンコードを推定したり、WM_COPYDATAでのメッセージやDLLとの連携などを考えるとどうにも有り得ない気がしてモチベーションが下がる.

無論よくあるC#やJavaのライブラリのようにバイナリストリームとテキストストリームの間に一段かませれば良いのだが、どうにもコードが冗長になってしまって嬉しくない. まぁこの手の問題はよくある話で、最近の高級言語を扱うにつけバイナリの扱いにはウンザリさせられるのは常ではある. C++のstringで扱うのに慣れてしまっている(※1)せいも無論あるのだけど、ルーチンを文字列とバイナリ配列で分けたり必要な時にimmutableなものを期待できなかったりがどうにも煩わしい、無論構造体との相互可変も然り.

まぁそういう想定で使うものでは無いのは分かっているので、言語批判に走るつもりは毛頭無いのだが、やはり既存の(扱うデータが完全に限定できない) クライアント環境で使うには少々手間かなぁというカンジ. まぁ日常的に使っている環境が違えば受け取り方も違うという所かもしれない ;-) (※2

※1) 周囲でも誤解している人がいたので補足しておくとC++のbasic_string<char>は別段'\0' terminatedな文字列を期待していないので、実装でcharの範囲が保証されている限りバイナリを突っ込んでもなんら問題無いし、逆にc_str()が既存のC文字列表現をエミュレーションする為のものなだけで、末尾に'\0'があるワケではない(例えば末尾の'\0'までをデータとして含む文字列と通常のC文字列から生成された文字列は別物になる) よってbasic_stringを扱うライブラリを作る場合にCと同様'\0'が含まれていないと想定したり、末尾の暗黙の'\0'があると想定すると、場合によっては悲惨な事になるので注意. また最近のLLなどを扱う場合にC/C++に慣れたプログラマが陥りがちな話でも文字列が必ずしも'\0' terminateでは無い言語の方が多い事は留意しておいた方が良い.

※2) まぁこういうのは慣れの話、例えば日常的にベクトルや行列を頻繁に扱うコードの場合、参照型や通常のオブジェクトと同列のベクトルや行列など有り得ないという気がする(※3) (この話を人にするとよく苦笑される) が、そうでない環境の人にはそれは実感にはならない、ただ立場を変えると例えばHSPの2.x系列まで整数のみで実数が存在しないというのは「まっとうな」プログラマなら有り得ないという感覚を受けるだろうが、それと同じ事なワケ ;-)

※3) じゃあ単にC++のように実体と参照の区別(コピーとポインタ) があれば良いかというと (それでカバーできる範囲は確かに広がるが) 左辺値として扱える部分集合や行と列単位での代入・交換なども多用されるので、結局それでは足らないので言語レベルでプリミティブとして扱える方が楽になる話になる(※4). 同様に上の文字列の話もバイナリ型と文字列型があれば良いのではという意見もあったが、余程考えて設計されない限り結局.NETやJavaでStringBuilderを使うのと似たような醜悪な話に陥りかねない(※5)

※4) 言語ごとの優劣の話では無く、DSL特化には必ずしもライブラリレベルで吸収できない差異はありうるという話ね;-) まぁそういう意味ではUTF16とバイナリの話もそう、今やそういう言語の方が多いワケで、そういう言語でそもそも既存のバイナリを生で扱うのは言語想定として馬鹿馬鹿しい話という所に過ぎない、難点は特に僕がフォーカスしている分野 (所謂クライアントサイドの汎用アプリケーション) の場合その言語想定と現実の乖離が激しいという所にあるのだけどsigh＞C++から乗り換えられない「ささやかな」理由の一つ.

※5) そういう意味では新しいRubyの文字列は少々面白いかもしれない、内部コードを統一するのでは無く文字列単位で保有エンコードがあるのだそうな、まぁまだ使ってないのでそのアプローチが本当に良いかどうかは断言できないが.

最近とみに思う、例えば2ヵ月後に稼動するシステムの仕事があったとして、 それを請けた場合に1ヶ月でさっくりモノが出て、組み込んでも何のトラブルも無く動いてしまいその後何の問題も発生せず言う事も無いのと、 品質はグダグダではあっても稼動ぎりぎりまで追い込み状態でスクラムを組み、稼動にこぎつけてもその後1ヶ月位は微調整やらなんやらで担当者と一緒に後始末やらなんやらに従事するのと 一段落して 次に心理面を考慮して担当者が継続して仕事を発注するのは「どちら」 か? という所;-)

今まで常に自分は前者の立場で行動し、メンテナンスまで含めたコストを考慮した上で必ず想定コストを上回らず、コスト分のソフトウェアとしての利益を提供し、またプロジェクトにおいて自分や周辺が決して「死なない」よう心掛けてきたつもりだが、両者がもたらし得る可能性について (経営側から) 企業全体の経常利益と雇用維持の安定性を考慮するに、果たして自分は良い仕事人では無いかもなどとも思う、少なくとも「人間」を扱うには少々ドライ過ぎるのだ.

無論理解した所で、人には性分というものもあり、それを実際に「できる」かどうかは全く 別問題ではある、まぁふと何となく 思うだけ というかそんな具合:-P

# そういう意味では建設業界などは実にこなれたものではある、道路がらみでやっていたが業界全体で「公共事業は小さく生んで大きく育てる」などという考えが公然とまかり通っているそうな(笑)(※1

※1) 誤解を招きかねないので注釈しておくと僕はそういったものを全面否定する意図は無い、日本的な国家護送船団的な経済は少なくとも市場が餓えていた高度成長期においては極端な潰しあいによる疲弊を避け全体の成長という点ではそれ程悪い施策では無かったと思う、ただ市場が飽和し人的コストが増加した現在において、資本主義の大原則が安い所で作り高い所で売る、その差益で稼ぐモデルであるとするなら同様の施策が良いかは大いに疑問ではあるという程度のトコロ;-)

※2) なおBGMは「砂の果実(中谷美紀)」でオネガイシマス、生まれ〜てこなければ本当は良かったの〜 みたいな :-P

ここ暫く外部からwindowをコントロールする為のライブラリを試作している、よくある外部アプリからWindowマクロ的な事をするアレ、大体セオリーは分かってきたカンジ、分かってきたが、、、具体的にはVirtualAllocExで該当プロセス内にメモリ確保してWindowメッセージを呼び出してからReadProcessMemoryで強引に情報取得、しかる後にWindowメッセージやkeybd_eventを介して操作をエミュレーションする、という具合.

正直プログラムの常識からは 有り得ねぇ というカンジ(※4

この手のWindows自動化系のUtilはカスタマイズ的な自己満足と相まって1ジャンルとしては人気ではあるものの、正直こんな具合にシステム想定外のメッセージが飛び交っている環境での動作保証なんてまず出来ないよなぁというカンジ、プログラマではこの手のものを入れている人は割と少ないけど、saiのレポート(※1)などを聞いている限り、コンシューマPCというのは怖いなぁと思う事しきり.

※1) ちなみに聞いた話では連日その手の環境依存(※2)や初歩的なインストールの質問ばかりでまともに開発できる状況では無いそうな、、、何ともはや(sigh)

※2) 冗談のような話だがMSのクラッシュデータベースにはxor eax, eaxでクラッシュする例なども世界で数百件以上報告されているのだそうな、ちなみに原因はマシンのオーバークロックやローカルショップブランドの無理のある機器構成による高負荷時の動作不良などだったらしい.

※3) それ以外に宇宙線などの影響も有りえるらしい、以前は冗談でよく「宇宙線が」と言っていたが、詳しく調べると

2008 IRPSレポートリンク集

など、年に数回〜数十回の頻度で発生する代物らしい、よく知らなかったがECC付きってのはかなり重要な話なのだなぁなどと思い知らされる、それ以外にも太陽フレアの活動が活発な時には全世界でエラーレポートの数が大幅に増加するとか、こちらは確認は取れていないが先日の関東圏の地震の直後にもマシンクラッシュによるsaiのライセンス再発行依頼が頻発したとか、その殆どが関東圏に集中していたという話もあったらしい.

意外に不確かな技術の集合体の上に成立しているのだなぁ、と痛感＞最近のコンピュータを取り巻く状況

何とも何とも.

※4) ちなみにEditBoxなどのテキスト(パスワードは当然の事、通常テキストも) はこの方法でも取れない模様、実験中のプログラムのプロセスメモリのゴミに一部テキストが残ってたから、もしかしたらセキュリティホールになるので後付けで修正したのかもしれない;-) これを外部から取る方法も無論あるし、9x系まで含め動作させる事も可能ではある、一応以前はそれ系の専門 (誤解無きよう言っておくけどスパイウェアとか犯罪絡みではなくセキュリティのお仕事です;-)だったのでそれ用のライブラリも手元にあるにはあるのだが、正直そこまではやりたくない、、、倫理的な話よりも可搬性の問題からだけど(えー

久しぶりに自作言語の話、少々思いつきで「バリデータ」と称する機能 (あるいはメタ的な概念的一致) を付けてみる、こんな具合

function @positive_num(n){
    return type(n)=='number' && n>=0;
}

として

10==@positive_num;  -> true
-2==@positive_num;  -> false

みたいなカンジ、これだけでは関数大して変わらないと言われてしまいそうだが、利用価値があるとすれば再帰的な比較を想定している、例えば以下のような具合

data=input_record();
if(data=={ 名前:@名前, id:@登録済みID }){
    ...
}

とか

switch(data){
    case { 品名:@登録済み, 在庫:@売り切れ }:
        ...
    case { 品名:@登録済み, 在庫:@在庫有り }:
        ...
    case { 品名:@未登録, 在庫:@any }:
        ...
}

なんかサンプルの表記にソレ系の (実に面白みのない) 単語が並んでいるからと言って余り軽蔑の目で見ないで欲しい(ぇ
、、、 まぁぱっと見に分かり易い例がこんなのしか思いつかなかったワケです:-<

実際case文に正規表現が使えるのが思いの他便利であった為、これを更に拡張するとどんな具合だろうというカンジ、バリデータというかメタ的な概念を表す概念値のようなイメージでもある. ま、取り合えずは実装は終わったので、暫く使ってみて実際便利かどうか確かめてみたいと思う、果たして多値のように「もう無いとやっていけない」になるか、あるいは一貫性を欠き事前制約的であるので不要との結論に到達するか.

まー多分似たような話は既に何処かで出てると思います;-)

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

WSHの方も順調、ただ周辺固めなので余りここに書く程の内容も無し、しかし想定用途から汎用のライブラリを実装すると、広い内容が含まれるワケで、意外と今まで知らなかった内容が出てきているのも面白い、そして更にその内容を自作の言語やペイントソフトにフィードバックしているので更に時間がかかるという具合、それでも普段余り目をやらないあるいは決まりきった方法でしか使わない機能以外に気付かされるという事では悪くはない;-)

それなりにGUIが揃ってきた、こんな具合

、、、やはりチェックボックスとラジオボタンは自前実装の方が良いかなぁ、とはいえスクリプト内部でシステム背景色は取れるので、複雑なコントロールが並んだ背景はその色で扱う事という事で、外部プログラムとの兼ね合いも考慮して標準コントロールの方が良い気してみたりと悩む:-<

なお現状実装しているのは全てモーダル実行して終了後にデータを取って破綻無く使えるコントロールのみ、リストなどはインタラクティブな操作でイベントでの遷移を考える必要がある為、まだ簡便さの為様子見、作るのは簡単だがこういうものを入れるとコードが長くなるのでまだ少々考察中;-)

しかし、いじるにつけMSはWSHをもっと強力な言語にも出来た筈で、意図的にそれをやらなかったのだろうなぁなどと思う事しきり、まぁ事業戦略の一環でありビジネスというものがそういうものであるので、何ともという具合ではある.

余談だがIE7ではJavaScriptの実行速度がさらに0.8〜0.9倍程度に低下しているらしい、まぁこれもwebベースのインフラが本気で普及してはマズい事を加味すると経営戦略的には予測通り、多分周辺の堀が埋まってからでないとこれ以上改善される事はあるまい;-)

、、、ただその傲慢さがここ十年のwindows開発者を失う原動力となってきた事を考えると果たして正しいかどうかは不明ではあるが:-P

# 余談だが、やはりGUI周りの構築・設計のパフォーマンスは去年の自分を考えるに格段に向上していると実感できる、そういう意味ではあのペイントソフトも (様々な周辺事情がありアレだが) 無駄にはなっていない、という所か. ただ悩ましいのはそれを「仕事」としてスケーリングする方法については逆に全く道を見失ってしまった事であるのだが、、、sigh