変奏現実

もういらないもの：United Nations
今までは、紛争や経済などの調整を行っていたが、今の総長になってからは結果として双方を激怒おさせ紛争を助長し、経済摩擦もさらに積み上げる始末。
一度、組織解体し組み上げ直すべき。
 

このブログをはじめてから最大の危機を迎えました。
 
DiCEのログを見ると
★ 6/29 19:47 にssiscirineが実行されました。
IPアドレスを更新しました
そう　6/29、までは毎日1回自動更新しており、
○ 7/16 3:09 IPアドレスが変わりました　***.***.***.*** -> ***.***.***.***
で止まっていました。
 
そしてDiCEの画面には何も設定がありません。
6/30にDiCEに何かが起こったようです。
 
設定しなおしてみると、
▲ 7/21 10:48 にssiscirineの実行に失敗しました
お約束ですね。
パスワードを忘れてました。
 
そしてDDNSの設定を書いたファイルが見つかりません。
そう書いてなかったのです。
 
んーDDNSの管理人にメールしようかなとも思いましたが、
そんなメールは毎日いっぱい届いているような気がする。
ボクだったらそんなメールを見るだろうか？
絶対に見ない。（確信
。。。
あーでもない、こーでもない。
。。。
★ 7/21 11:41 にssiscirineの更新が実行されました。
やっとのことで思い出し、困難を乗り越えることができました。
。。。
疲れた。
。。。
もし、思い出せなかったら、どうしよう？
それはそれで
フェードアウトできたんだから
いいじゃないか？（笑

4.2GHｚでSSDを認識できないので、足回りが付いてこないらしい。
4.0GhzはOK。待機状態ならCPU温度は３９°で安定してるから、コアはまだ余裕なんだろう。
空冷のデカイのを付けても効果は期待できそうもない。
何か忘れてるのかな。
UEFIでオーバークロック用のデフォルト設定のリストから４．５GHｚを選択したらあっさり動いた。
いったい？

このたび、「ＯＣＮブログ人」は、２０１４年１１月３０日をもちましてサービスを終了させていただくことになりました。

と云うことらしい。すでに、ここに移動済みで、ここが落ちてる時しか書いてなかったけどね。
引っ越し先の案内もあったけど、記事はともかく画像は1枚づつコピペだろうから大変そう。
SNSはギスギスしだしたら居心地悪いし、定期的に記事を書くようにしないとあっという間に過疎スレ状態になってしまうので、知り合いとLINEで会話すれば十分、ならブログを使ってる人は絶滅危惧種なんだろうね。
ま、ツィッターで下手なことも書けないご時世になってしまったからね。（大笑

「殴ったほうが訴える……？」横暴やまないサッカー韓国代表に、世界中から非難の目
 
ま、かわいそうな人たち。
そう思うしかない。

新聞には過去の例を挙げ、前世期で大失敗したのだから、「積極的な平和主義」をやるのはバカだ。という論調に傾いているが、「モンロー主義」すなわち「引籠り型（自分の国だけ）平和主義」が、対岸のナチスドイツの侵略戦略を生温かく見つめて、「第二次世界大戦」までやらかした苦い歴史のことは一字一句も出てこない。この辺は「敗戦国である日本」としては都合の悪い話ではあるけれど、なぜアメリカが何かの戦争をやろとするたびに議会の承認を得ないとできないのか？というあたりが理解できないだろう。
この辺は「机上の空論」をたたきつけたところで、堂々巡りをするだけだし、それに「机上の空論」の事前協議通りに「やっちゃいました」は無茶すぎる。
大義もなく大敗まですれば大勢の兵士がただの無駄死してしまうんだからね。
というあたり前なことだ。
だが、テレビや新聞で流れてくるのはこの「机上の空論」が空転する話ばかりだ。
単純に戦闘区域の近くまで来てSOSを受けたら助けに行く？行かない？
答えは、A.助けられるなら行く。B.助けられるないなら行かない。の２択だ。
A.は素直な回答。B.は二重遭難の回避的な回答。かもしれない。
だが、よく考えれば、相手が居るのだから、状況次第でどちらになるか判らない。
と云うか

そうなったときに現場がどれくらいの状況が判っているのか？

の方が心配の種だ。
法律で「助けなければいけない。」と書かれても、助けられるないものは助けられるないので、
法律で「助けてもよい。」と書き、後は

現場の判断。

これでは、心もとなさすぎる。

気が付いたら、

どこかの某国と戦闘状態になってました。ごめんなさい。

と、テレビの向こう側で

高級幹部に一斉に頭を下げる。

ということになっても何も不思議ではない。
要は「全く信用が無い」というのが根本的な問題なのだ。という訳で、無理はしない方がいいよ。
だいたい何事も初戦は「敗退する」というジンクスがありますからね。
 
それにしても、ひどい内容だな。小説の子ネタにもならない。

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の情報を検索してヒマつぶししております。　（世界中の大半のプログラマ
 
所感：
所詮セキュアにしようとすれば、内容の確認もできず、ロクなテストもできないのは当然。出来が悪いのは必然！
そこを頑張ってデバッグしてると思わぬところで天井が抜ける！セキュリティホールがアチコチで見つかる諸元なのだ！
つまり、セキュアにすればするほど、どんどんテスト不十分になり、とんでもない勢いでセキュリティホールが仕込まれていくのである。（証明終了