変奏現実

Windows8の次のアップデートでStartメニューを復活する見通しだったがまだ何もしていないようだ。
もしかするとビルド・オプションに-START_MENU（仮称）を付けるだけで十分なのかもしれない。
Startメニューが復活すればデスクトップにアイコンを作らないWindows7向けのインストーラが支障無く使える。
それで困るのはInstellSheild社だけである。
もっともデスクトップに下記のショートカットを作っておくだけでも解決できる。
C:\Users\{ユーザ名}\AppData\Roaming\Microsoft\Windows\Start Menu
 
 

中国は

原因

今なら原油価格が高く、近郊のしょうもない埋蔵量の油田を高い金をかけて掘ってもペイできる。シェールガスで原油価格が低迷直前の今が勝負時、それに油田が枯れてしまえばもうこんな機会は二度とない。

状況の推移

末端の政府機関が勝手に採掘現場を自国のEEZに組み込み中央へは事後報告。後は鼻息の荒い会社の下っ端の荒っぽい現場の判断で力押しさせ、周辺国が軍事活動しないように軍を関与させない。だから痴呆症の将軍様の発言は現状を一応正しく説明している。つまり中央は下っ端のしでかしたヘマをかばうのに必死だし本気だが、嫌々やっていることに変わりはない。

対策

経済制裁として、軍事費を大幅に削って膨大な資金をシェールガス開発に投入し開発をガンガンと押し進め、世界の原油価格相場を１０年ほど半分以下に引き下げ、価格高騰でボッタクな石油資源開発会社を破綻に追い込み、ハゲタカよろしく会社ごと資源回収し、領土問題とセットで国際裁判所に持ち込み仲裁裁判で仲裁契約を穏やかに進める。

影響

北海油田（もう枯渇してたかな？）、ロシアのサハリン１，２など同じネタ振り（やるなら今でしょ的な油田開発）で荒稼ぎしているところも壊滅。

再発防止策

特になし。どうせまたやらかす。

新興ロシアは

原因

シェールガスでLPGや原油価格がいずれ低下し資本が大きく目減りするのが見えている。やりたいことは今のうちにしかできない。

状況の推移

近郊のロシア系住民を勧誘できるのは今のうち景気良くプレゼント（賄賂）を振る舞い夢のある先行きのプランを提示し、そこで住民投票をすれば気前のよいロシア系某会社や組織の主張が圧勝するのは当然。

対策

シェールガス開発をしっかりやっていれば先は見えているので、長い目で経過をみるだけでOK。東西を隔てる鉄の壁を作る予算もないロシアは経済破綻までの期間は先の冷戦よりずっと短い、それまでは地味にロシアの周辺国を経済支援。ロシア再々建はあせらず周辺国を起点にゆっくりを進める。

再発防止策

歴史認識は各国でバラバラになるので、経済指標と状況の遷移を織り交ぜて、状況分析をしっかり行う。

 
という感じかな。
 
原因がシェールガス開発なら、その悪影響を絶つのもシェールガス開発。
そ、後はやるっきゃないのですよ。がんばってね。

先の
<CheckBox IsChecked=”{Binding ＊＊＊＊＊, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}”/>
はどうやってＣ＃でコードするのか？
残念ながら正解は・・・なかった！
頑張って色々C#コードでやってるのも見かけたが、ピッタリそのままとはいかない様だ。
ＸＡＭＬを読み込んでフォームを作る仕組みが実はＣ＃とは無関係に実装されているようで、C#でコードするのはお勧めしませんXAMLファイルをお使いくださいということらしい。
仕方が無いので、上のテキストをXamlReaderに読ませると、エラー　CheckBoxって何？とか言い出す。
ＸＡＭＬファイルの内容をXamlWriterに出力させてみると、
一番Ｔｏｐのノードに妙な属性が付いていた。
xmlns=”http://schemas.microsoft.com/・・・/xaml/presentation”
これが無いと読めないのはなんとなく判る。
更に驚いたのは、
Binding = “False”
になっていたこと。
つまり WPFのフォーム・クラスでは、Bindingに関する何かのstaticなメソッドをインプリメントし、こうならないようにカバーしているのだろう。
でも面倒なのでreplaceで先の設定に書き換えて、XamlReaderに読ませると動くようになった。
※この時点で『ローカル』ビューに出ているテキストをソースに貼りつけBining部分を手直ししてもいいだろうけど、VSの画面で手直しできる方が楽。
さて、やっとのこれでCheckBox付のカラムを好きなだけ勝手に増やせるListViewができた。
単独のコントロールならフォームに_＊＊＊＊＊ のセッター、ゲッターで十分なのだろうけど、DataGridやListViewの場合はカレントの行を意識するのは容易ではない。
残りはコンボボックスかなリストの中身をいつも最新にするには・・・上の方法で十分だろう。（笑
 
と云う感じで、XAMLの論理設計や実装の悪さを痛感した。
XAMLのフォームエディタでフォーム・サイズを変えた時に良い感じになるようにレイアウトを変えようとすると、ただただ変になっていくし・・・どうしようもない。
こうなったら、XAMLを手で直接書き換えた方がマシだ。
それにｊQuery-UIもやっぱり変なものでいっぱいだし、使ってみると、妙な制限が多くて、パーツとして使えないので画面の飾りとして使うしなかいのは御承知の通り。
こんな思いをするならどっちも、自前でXAMLもどきやFormもどきを作った方がマシ。
だから、自分用でOK。

次のWindowsはデスクトップ用とモバイル用に分かれるらしい。
※もちろん、サーバー用のWindows　Serverは全く不明。
どちらもWindowsRTアプリが動くようになるらしい。
しかし、それ以前にWin３２にはプラットフォームとしてはともかくアプリ開発の土台がなってない。
古くあるMFCベースはもうやる気が無いらしく、Windows　FormかWindows Presentation Foundation(以下WPF)をベースに作ることになる。
それにC++、C#、VBの様な言語も選ばなくてはいけない。
ま、その辺の実装に大きな問題は無い、問題は実装した後の結果だ。
C#とVBでリリースした機能に差（VBだけにある機能）があったり、Windows　Formは昔から仕様がほぼ変わらないが流行りの記述方法に変わっている。WPFはBindingに頼り過ぎBindingはJava系で云うところのヘルパークラスやJDBCの仮装実装インタフェース状態にそっくりだ。そう作った奴にしか判らない実装になっている。古いもので云えばOS/2のクラスライブラリィ同然で、サンプルでの書き方（またサンプルの記事の通りの方法）でしか機能しないのだ。
あからさまに云えば、ＸＭＬでサンプルデータを作り、それをフォーム上のコントーロールにBindingしデザインを確認したら、こんどは、そのBindingの設定をＤＢなりクラスなりに置き換えなくてはいけない。ここで不味い実装が露見する。
dataSource  プロパティはもちろん変更が必要だが、末端の Binding   xpath=@<エンティティ名> を Binding　＜クラスのプロパティ名＞に全て手で直していかなければいけない。
この辺の設計者は、どうせ全部部下にやらせるからどうでもいいんだろう。　どこでそうだがSGMLの仕様は一見読みやすいが流用が効かない＝一行野郎魂で出来ている。と判るのは実際に使っている部下だけである。
さらに、C#のWindows　Form　アプリ系は、フォームのビハインド・ソース・ファイルのフォームクラスの前に何か別のクラスを作ると、同列のxxxx.designe.csつまりフォーム設計をC#ソースにしたものなのだが、そのクラス名が先の作ってしまった別のクラス名に裏でこっそり置き換わり、次第にエラーが山の様に積みあがるバグは今も入ったままだ。
また、WPFではそうならないので安心かと思えば、Nameプロパティが名無しの状態からプロパティウインドウで何か名前を与えようと1文字入れると反応しなくなり、続きはXAMLファイルのテキスト・ビューの方で中途半端な名前になっている箇所を正しい名前に書き換えなくてはいけない。
と云う感じで、IDEのUI設計レベル（並）　＞＞（全く越えられる気配が感じられない距離感）＞＞UIの実装レベル（底辺）　なのが現実で、それが、アプリの構成設計　≒　サンプルの実装　の出来なので、応用が利かない。
例えばWPFでListViewをGridViewとして機能させ、列を設定用にチェックボックスで埋めることができる。Windows FormではOwnerDrawイベントを駆使して実装しなくてはいけないのに比べればかなり簡単だ。しかし、それは列に文字を出すだけなら簡単で、チェックボックスでも列の設計が固定なら簡単だ。但し、DBの内容によって列の数が増減するようなダイナミックな設計をしてしまうと、もうXAML式（仕様は永久確定でなければいけないの法則）では無理で、頑張ってBinding するリソースをC#で組み立てなければいけないが、XAMLの　<CheckBox IsChecked=”{Binding IsConverted, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}”/>の属性の部分を　どうC#ソースで書くのかは、var 宣言から逃れられないため、ソース・エディタのヘルプも全く役に立たず、正解はコメントの無い実装レイヤーに包まれている。
さらに５月のSQL Server 2008 のWindows　Updateパッチはいつまで経ってもインストに失敗すると報告する。実はパッチが当たっており、インストーラのバグだったようで、非表示にしてめでたしと思いきや、こんどはデタッチでエラーが出る。強引にデタッチすると、データベースのインスタンスがクラッシュし、再起動しても復旧しない。仕方なく２０１４に置き換え、アタッチすると、何事も無かったかのように動き出すが、今度はVisual Studio 2013のデータベース・ツールからスキーマ詳細構成が見れないのはバージョンが新しすぎるせいなので仕方が無いが、無駄にアチコチにバージョンチェックが挟まっているせいで、バージョンチェックエラーとなり、テーブルのデータも観れないし、SQLを実行することもできなくなっている。
※但し、コンパイルしたアプリはNO　VESION　CHECKED　なので何も支障が無い。
黒猫やCSDが無かったら、どうなってるか？と思うと怖いですね。
という感じで、ボロボロです。
もうご臨終じゃないですかね。
でも、もうすぐ２０１４版がでるんでしょうね。それまでは開発を放棄し、待機してるしかないですね。
てかMSの仕事って雑すぎるってだけの話なんですけどね。
そうでもなければ誰もWindows 9の話なんて耳を貸す訳がないですよね。
ただいま仕事にならない状況です。
次のWindowsの情報を検索してヒマつぶししております。　（世界中の大半のプログラマ
 
所感：
所詮セキュアにしようとすれば、内容の確認もできず、ロクなテストもできないのは当然。出来が悪いのは必然！
そこを頑張ってデバッグしてると思わぬところで天井が抜ける！セキュリティホールがアチコチで見つかる諸元なのだ！
つまり、セキュアにすればするほど、どんどんテスト不十分になり、とんでもない勢いでセキュリティホールが仕込まれていくのである。（証明終了

Surface miniだろうと云う前評判を華麗にかわして出てきたのはSurface 3だった。
12インチのモニタの大きさは微妙だし、Core i3モデルで799ドルなのも中途半端、XPサポート終了特需で世界的にSurfaceが供給不足になっていたので、今まで発表が延期になっていた様な気がした。
そう思ってしまうのも、いったい誰に向かって、付属のペンで手書きしたりフォトショップを使ったりアピールしているのかも判らないシロモノだからだ。
同様なものと云えばWACOMの高価なタブレットCintiq Companion($2,299.00)しかなかく、プロのクリエイターではないけれど絵も描けるWindows８タブレットっていいなと思うけど、Cintiq Companionは高くてとても手が出ない人には丁度いいだろう。このCintiq CompanionはHD解像度(1920×1080)で、Surface3はそれより高解像度(2160×1440)なトコロもそんな人の心をくすぐるだろう。
ただ当たり前のことだけど、どれを使おうが、ペンでサラッとなぞって、絵筆の様に描くことはできない。ペンで絵筆コマンドを送り続け、後で確認する様な気持ちでいないと、反応の鈍さに腹が立ってくる。
プロなら仕上がりをイメージしつつ、少しづつエアガンで塗装する様な感じで、もうちょっと、もうちょっと、と重ね塗りできるのだろうけど、
ボクみたいな素人だと、ペンの動きにラグなしで素早く結果が反映されないとイライラするので、ペンよりもレイヤーを分けてマウスでマスキング指定し塗り塗りした方がストレスが無い。
このSurface3が出て一番うれしいのはAdobeなのかもしれない。パッケージ販売から月額制オンラインサービスに切り替わったからだ。
ｐｓ．
ライバルはMacBook Airらしい。日本では１０万円～らしいので、価格が高いから引き合いに出してきたのかもしれないが、まともにDellや富士通や東芝のコンパーチブルなノートPCと比較する訳にはいかないというのが一番の理由かもしれない。
３でSurfaceの一番のメリットのお得さが無くなり、ハイスペックを重視しだした時点で、他のコンパーチブルなノートPCに埋もれてしまうだろう。
単にメモ帳で記事を書く程度ならCeleronで十分だし、ペンを使うにはプロ並みに使いこなさないと逆にストレスになる。普通は添削で○や×を入れたり、手書き文字で書き込み程度しかしないから、ペイントぐらいかな。やっぱりCeleronで十分だな。
ただ、JavaでEclipseでWEBの開発とかいいだしたら、i7は欲しいけどね。Celeronじゃ起動の待ち時間が何倍にもなるので仕事にならないからね。（大笑