一応実務案例ＭＳＤＪ（中5編 .Net Framework解説)

これもつぎの話が分かるための必要知識ですが、オブジェクト指向言語と関係している。

(Object oriented  モジュール化するとの意味です。)

.netFramework（または.net）はマイクロソフト社が提供しているWindowsプログラムミングためのライブラリ（Lib）です。

ライブラリ：図書館→知識倉庫のこと 

 クラス：PGのモジュールのこと。手本、設計図のこと。

中には大きく２タイプあります。

一つはクラスライブラリ（Class liberay） C++やC＃、Javaなどオブジェクト指向言語用のWindorws functionや部品のクラスライブラリです。アプリコンパイル段階で取り込まれる。

一つはダイナミックライブラリといい、コンパイル済の実行コードのライブラリですが、アプリリンク段階で実行ファイルに取り込まれる。

（Javaの場合はリンクは存在しないので、Jarファイルにパケージされる。）

分かりますか？おそらく素人だとぼんやりしていると思いますが、もうちょっと具体的に話します。

例えば：Main窓に押しボタン一個作ります。のbuttonClassはあらかじめ.netframeworkライブラリに定義されているので、最初からボタンを描く必要がない。そして、ボタン関連のすべての動作機能はイベントやメゾードとしてbuttonクラスの定義の中に含まれている。

プログラマーとしては、.netframeworkからbuttonClassを引用するだけで、ボタン関連のすべての機能が使える。実際、WindowsPG上はクラス定義を引用するだけではボタンが表示されないので、ButtonClassの”インスタンス”をプログラムメモリー上で生成することで実際画面上にボタンが現れる。

（つまり、この画面上はボタンは一時的なもので、PG終了すると消えるからインスタンスと呼ばれる。）

OK,分かったね。

さらに、クラス（各種部品）のインスタンスがBIOSのメモリ上（画面上）で生成すると、初期化（コントラストというメゾード）もクラス定義のままで実行される。つまり共通的な初期化手順を書く必要もないです。楽ですね。

そして、個別的な初期化手順、例えば、このボタンの表面に”K1”と表示する場合は、コントラストメゾード内で明示的な書く必要がある。

button.contrast(name='k1'){};

の感じですね。文字列'k1'をボタンの名前にするとのことです。この手順はクラスのオーバーライトと言います。ほか、変動のな機能は継承されるからなにも書かなく出いい。

＊＊＊甚大な問題＃１

パソナさんの派遣エンジニアは（誰かの指図により）BingIMEからのテレメトリー関数をSelectedChangedイベントに埋め込んだ。その結果ですが、プルダウンメニューが選択されるたびにテレメトリーが現在の値を発信することになります。

例えば：IMEスキン選択ComboBoxの場合は、a,b,c,d四つのスキンがあります。大体最初おぼ白いでいろいろ弄ると思いますが、弄っているところはすべて”ユーザーが選択した”と発信されるが、実際”確定”はしていません（使われてもいない）。

設定画面が閉じる時は確定ですから、ほんとうはＣｌｏｓｅＷｉｎｄｏｗｓイベントにテレメトリーを埋めるといいなのに！

このミスはＰＧ自身は動くですが、受信したユーザーユーセジデータは私の予測では４倍膨らむです。その内４の３分は"未確定"データですから、こゆうデータを図表にして分析なんか無意味のほか開発を誤導してしまう。一応多くの人は使っているとの分析結果だけは現場の人には有利で、リストラから逃れるかもしれない。（そゆう意味か？ｗ）

カナイの指摘に対しては、担当Ｋ１さんの答えは”そのままでいい”ということで、コンパイルできっているから急いてＰＪを締めたい感じです。しかしね、K1さんがテレメトリー発信データ応用側のＹＫさんに対しては、”ドッグフードユーザーが画面上で遊んでいるからデータが多くなった。”とプログラム上の不都合を隠したよりも、YKさんやCさんの言い訳らしきことをブーメランしているような感じがあった。カナイの推測では、このオフィスにはCさん以外にパソナさんをPGミング的指図できるものいない（K1さんもWindowsFrameWork理解がないため、分からないだろうと思われたかもしれないが、しかし、K1さんは上海人の小賢い特性が持っているから、なんとなく”故意な誤り”の匂いが分かっているようだ。）。

事実上、この”誤ったやり方”は、偽物の”ドッグフードユーザー”にテレメトリーを多く発生することに便宜を提供した（場合よりロボット的にテレメトリーを大量発生させることも可能な状態です。）。

＊＊＊甚大な問題＃２

パソナさんの派遣エンジニアはBingIMEからのテレメトリーは初期化メゾードに埋め込みしている。このやり方を引き出した問題は：

IME設定画面（タグ）に上から下にプルダウンボックス四つ並んでいる。A、B、C、Dとします。

テレメトリー仕様上は、Aボックスが選択されたら、A＆B＆C＆D四つのボックスの現在値を”論理和”にして送信する。

TelemetoryはInit()メゾード（あるいはcontrast）に埋め込んだことで、Aボックスのインスタンスが生成された時にコントラストは実行され、テレメトリーも同時発信されます。

その時は、B,C＆Dの現在値を取ろうとしますが、B,C,またはDは存在しませんとエラー表示して、失敗してPG終了になります。（実際コンパイル段階で警告メッセージが出ますが、あまり警告多い場合は見逃れてしまうです。）

なぜ？

また追加知識が必要です。

Windowsプログラムミング開発環境ツールいろいろありますが、一番普通に使うVisualStudioを例にします。

VisualStaudioでWIX（MVCモデル）でWindowsプログラム作る場合は、画面作りのCADみたいな機能があります。それは、実際アプリ画面上の部品をCAＤのように配置します。ＶＳは画面定義ファイル（ＸＭＬファイル）を自動的に生成してくれる。

注意！ＣＡＤ画面をコンパイルするではなく、ＣＡＤ画面から生成したＸＭＬ画面定義ファイルをアプリのコンパイルに読ませるです。この方式のメリットは画面部品の位置の座標を書かなくで済むです。自動的ＣＡＤ画面から座標を拾ってくれるので、作業のスピードがアップ。

実際アプリのプログラムはＷｉｎｄｏｗｓ画面を一瞬で同時生成ではなく、Ｍａｉｎ枠から複数の部品のインスタンスを順番に生成していく。つまり、

Ａ、Ｂ、Ｃ、Ｄボックスの順番でインスタンスが生成される。Ａが生成された時にＡのコントラスト中に埋め込まれたテレメトリーはＢの値と取ろうとすると、Ｂインスタンスはまた生成されていないから、見つからないというエラーになる。・・・分かったかね？

だから、実装できない。

カナイの指摘に対しては、担当者のＫ１は”この部分のテレメトリーを消す”との結論だした。そりゃ、察すが経験豊富なカナイを驚いた。このＰＪ仕様は確かにグローバルサーバー上にあるが、Ｋ１が現場で仕様削ることを決めれることは、北京でもＫ１さんに文句いう人がいないことだ。自由自在プロジェクト、今締まりにしないと年末査定が間に合わはいぞ！って感じです。

ここまでくると、ＢｉｎｇＩＭＥのベテランＣさんがなぜＫ１に指導できなかったか？実は指導する気さらさらないじゃない？やはりＫ１は仕事失敗して契約切られるといいね？Ｃさんは完全にＹＫさんの仲間で日本人派だからね。

おまけに、Ｋ１さんはパソナさんの派遣さんが論理演算式間違っていることも軽蔑な笑いして、ＹＫさんを聞かせている。もうしかし、CさんとYKさんはテレメトリーデータを増やすつもりで、二人のメクラをつもりで選んだかもしれない。

年末査定後は、Ｋ１は見事に昇進され組織上はYKさんを取って代わる形になった。ＹＫさんはもうしかし日本マイクロソフトへ出向かもしれない。だから、その後は日本マイクロソフトからＢｉｎｇ派遣さん募集掛けたが、でもこん案件の続きがあれば、ＭＳＤから指示出すから、パソナさんは二重派遣にはまるおそれがあります。

あと、BingIME/CopilotIMEは実は使われていないであれば、Cさんの仕事もなくなる。現在一番使われているのはWindows11に組み込まれているWindowsIMEだ！

正直、K1さんは年末昇進ためこの案件を担当していたから、上流からのバックが強いので、すきなように”完成”されると思う。しかし、この案件の別の側面で、現場の人は”仕事確保”のためこの手あの手使うって、もう日本人が集まるところでは信用できんじゃない？

やはり世帯の教育と育ちの問題？

論語「子曰わく、性相近し。習えば相遠し。」

次章のテレメトリーノ３へ

福主人

一応実務案例ＭＳＤＪ（中4編 Windows FrameWork解説)

IT素人にはWindows　FrameWorkの仕組みを説明しないと、次の”テレメトリー３”には何を話しているか理解しないと思うので、そんな一句二句で説明できないことですから、少々長い内容ですが、勉強と思って読んで貰いたい。ITのプロでも触ったことがない内容と思う。

段１：BIOSとWindows

Windowsパソコンの画面上に”Window”をひとつ開くことは、液晶モニター上にほんとうに窓をひとつ区切ることはない。ただ色違いでWindowのワークを表示して窓のように見える。そして、複数窓を開ける時は、物理上は前後あるではなく、あくまでも”前後あるように”見せてくれるだけです。

メーカーは液晶画面の画素と同じメモリー（VRAM）を積んでいるので、プログラムはVRAMに画素（三原色２進数、例えばRGB010f5dd）を書き込む、モニター制御部分のプログラム（BIOSの一部）がVRAMの値を液晶画面へ刷新する。非常に高い頻率でRefreshするので、目にはスキャン線を見えない。ただ、画像が変わったと映る。

これはBasic I/O system(BIOS)のことで、パソコンメーカーが提供している。画面制御はその内の一部だけです。ほかキーボード、マウス、プリンターポート、シリアルポートなどいろいろ外部入出力制御機能が含まれています。

Operation SystemのWindowsはBIOSとアプリの間にあるものですから、ミドルウェアと呼ばれます。ユーザーがWindowsプログラムを開発の時はBIOSを意識しなくでも書ける。具体的例で、作るWindowsプログラムは必ず最初一つ”MainWindow”があります、そこからサブWindowやポップアップWindowで構成される。

プログラミングの最初に、Main（座標、幅、高さ、スタイル）とのような関数（メゾードともいう）を書きます。この行のコードをWindows11用のコンパイラーでコンパイルすると、Windows上で実行できるプログラムが生成される。WindowsOperationSystemが渡される座標など情報を元ついて、BIOSが提供する”画面上で窓を開ける”ファンクション（アセンブラ関数）を呼び出しして、画面上に一つアプリの主な窓を表示することができる。そして、次アプリなかのすべての操作はこのMainWindowの中の操作だと黙認してくれるから、アプリのプログラマーは”はみだし”の意識はしなくでよいです。

段２：VMCモデル

Windowsアプリのプログラマーは物理画面を意識しなくよいです。見た目上のビジュアル画面を想像して書けばよいです。裏窓とか表窓とか、タグとかポッピアップとかリアルにあるように考えればよいです。マシンコードは全部段１の仕組みが自動的やってくれるです。

OK,だから、プログラマーのため、Windows　Frame　Workという概念がでました。それは上の段落のイメージです。

一つ小さいWindowsプログラムは、例えば：BingIME（日本語変換画面）は一つポップアップ画面しかない。このシンプルなアプリを作るために、C++言語でWIXというExtensionを利用します。C++は最初のオブジェクト指向プログラミング言語なので、その仕組みは後で説明します。

まず、WIXというWindowFrameについて説明します。WIXを実装した場合はWindowsプログラムミングのFrameWorkはMCV(model-View-Control)モデルと呼ばれます。

ここの：

Viewとはイメージ上のアプリ画面のこと、窓と中の部品です。部品って分かりますよね、Window窓の中のテキストボックスや、ラジオボタン、プールダウンボックス、リストボックス、スクロールバーとかいろいろあります。これらの窓と部品は.NetFrameWorkというライブラリ(後編で説明する)が全部提供してくれるので、サイズ、座標とスタイルを設定するだけで済む。

Modelとはアプリ内部のスタック（Stack）のことです。アプリ中のデータ倉庫ですね。時にはWindowsキャッシュも利用する。Model中で定義されたデータ変数はView（画面）上の部品で表示される値と対応している。つまり、View上のデータとModel内のデータは別々だ。

これはWindow11のIME設定画面です。例えば：View上の現在の入力モードは全角と半角２択あります。全角、半角複数回選択繰り返しても、最後この設定画面を閉じないとModelへ反映されない（Windowsキャッシュへ記憶されない）。

注：Windows1０の場合は”適応”ボタンと”OK”ボタンあります。適応クリックするとView上のデータがModelに対応した変数へ書き換える。OKは適応+画面閉じる。

Windows１１では、適応ボタンは省略されて、OKだけでボタンなしで設定画面を閉じるとデータが写される。

では、Viewの部品の値をModelの対応変数に書き換える（双方向）ことはControlモデルの中でコーディングされる。適応ボタンのOnClickイベントに埋め込みされる。（あるいは設定画面閉じるイベントonWindowCloseに埋め込みされる）

VMCモデルは画面作成の人とデータ計算の人と、データ写しの人と分業でプログラミングできるメリットがあります。IMEの場合はWindowPGとしては極めてシンプルで一人やってしまうですが、難しいところはGlobalや各国言語との連携だ。あるいは、外字とか日本のパソコンメーカーへの対応だ。それは別話で省略します。

段３：MVVMモデル

医療システムような複雑な画面、複数窓で数字文字だけではなく、画像動画なども取り扱うアプリの場合はMVCよりもMVVM（WPFというWindowsFrameWork）ほうがPG楽です。

Model-View-ViewModelと言う方式です。ViewModelとはView（Windows画面）上の部品の値をViewModel中の変数とBinddingできる。一旦Binaddingされると、画面上部品の値を変動すれば、自動的にViewModel上の対応変数へ反映される仕組みで、逆も同じです。

だから、WindowsプログラマーはＭｏｄｅｌ（データ計算）に集中すればよいです。ＶｉｅｗＭｏｄｅｌなかでは、自身持っている変数をモニタリングループという単純なＷｉｎｄｏｗｓ原則で動いている。監視と反応の連続です。例えば：Ａ選択ボックスの値は”a”を選択されたから、Ｂリストボックスに”aが選択された”と表示します。ここまではＭｏｄｅｌを行かないです。

もし、aよりデスク上のＥｘｃｌｅファイルからa行の次の列の値”えい”を持ってこいとの複雑な計算が入る場合は、ViewModelはＭｏｄｅｌ中の対応しているメゾードを呼び出しして、帰り値（えい）をＶｉｅｗ上のリストボックスと対応しているＶｉｅｗＭｏｄｅ中の変数へ設定することになります。（画面上は自動的に”えいが選択された。”と表示される。）

これでＭＶＶＭの仕組みが分かりましたか？汗！この仕組みはWPF extentionで提供されているが、日立工業さんのような大型PJでは使用しているが、一般のＷｉｎｄｏｗ機能アプリはそこまでは必要がない。

段４：クラス、インスタンス、イベント、メゾード、コントラスト、デスコントラスト、コンテナー…山ほどあります：うん、話しても素人が分からないので、やめます。

大体この章を多少わかれば、次の章の”テレメトリー３”甚大なミスをよんだった分かるようななると思いますが、分からなくでも仕方がないので、さようならです。

福主人

一応実務案例ＭＳＤＪ（中3編 Telemetoryの意味ノ2）

一つ：テレメトリー（遠隔操作）

遠隔操作は、今言葉で言えば”離れた地点をリモコンすること”と同じ意味があります。

マイクロソフト開発部門は縦割り組織であります。基本的に上級会社や下級会社の同事業の担当とチームを込んでいるので、ジャパン支社のメンバーは例えば隣に座っていっても、仕事の対象は違うので、具体的協力の機会はすくない。だから挨拶も薄いことです。

もう一つ特徴は、開発専門だからお客様対応はないので、マネジャー専門職はいません。社長を含む大体技術職のエンジニアが管理職を兼任している。正直エンジニアの年末査定は子会社内部でも業績はどうかは分からないので、縦割りのグローバルチームのリーダーにやってもらわないといけない。そのため、Regionには人事専任のマネジャーが居りまして、配下サイトのエンジニアをリモコンしている。

けれども、MSDJは日本法人ですから、契約上事務上のことはアプリケーションマネジャーのYHさんがやっている。正直アプリケーションマネジャーは開発部分には要らないと思いまして、営業部門がやればいいけれども、やはりそゆう事務職が必要なので、まあユーザーデータ分析という名目でこのポジションを作ったじゃない？

なぜ、この組織作りの話をするかは、ここからの話に前置きすると分かりやすくなります。

かないがMSDJ入った時は、YHさんは大変困っているです。CopilotIMEのユーザー使用状況のデータはKusutoには入ってこない。手元に見せてくれたのはKusuto構築（親会社）したとこのサンプルデータ２～３０件しかない。これでAriaというクラウト対応のBIツールで図表のサンプルを作っている。（PowerBIで作るという考えがあるけれども、親会社がAriaでやるらしい。）

CopilotIMEでテレメトリー発信コードを埋めたのはパソナの派遣エンジニアでしたが、私が入った時はもうキャンセルされていませんので、日本の方だと思います、指揮命令者はK1さんでした。

一応パソナさんが納品したけれども、ビルドできなかたようで、実装できないから、ＹＫさんはデータが入ってこないと困る。そして、ＢｉｎｇＩＭＥをプログラムしたベテランエンジニアのＣさんと相談しました。

ＣさんはＭＳＤＪ内部では元老級で信頼と尊敬されているから、K1さんを呼んで話を聞いた。

結局聞く人は話が分からないと、聞かれる人も原因が分からないと、白板で何度かロジックを書いて貰いましたが、最終的”分からない”と泣けるほどです。

そして、責任の問題が出ってきました。

Ｋ１さんの主張は契約上は派遣先の責任者はＹＨさんだから、俺は責任がない。

ＹＨさんはパソナさんは派遣さんだから責任取るわけがないので、パソナさんがＫ１の指示通りでやりましたが、Ｋ１さんの指示に問題ありと、

でもね、ＹＨさんはマネジャー専門じゃないから、”日本支社の総意の元で”代理でやっているから、責任をいうなら、支社長じゃ？

けど、支社長も技術者兼任で名義だけで、支社長の上司は北京にいるので、人事などはほとのど北京からテレメトリーされている、時にはシンガポールからもテレメトリー入るので、こゆう時は支社長はも顔出さないように隠れる。

実はカナイはこの業界でバグ探すのは有名で、どなたか支社長にカナイを推薦したから難局に入った。カナイの取り込みは、ＣｏｐｉｌｏｔＩＭＥのテレメトリーの実装を依頼されました。３日でできました。そこからＫｕｓｕｔｏにテストデータは毎日ばんばん入って、ＹＨさんが担当するチャートはいろいろと作れたので、任務完成です。

当然、バグがありました。それは大した問題ではない。直せばいいの話です。しかし、大した問題も発見しました。

一つはパソナさんのエンジニアはプログラミングでの論理演算ができない。多分実装できなかったから、間違っている式の意識はなかったが、ある意味で新人プログラムマーで、コンピュータ専門学校卒以下だ。

一つ：これから詳しく説明しますが、Ｋ１さんとパソナさん二人ともＷｉｎｄｏｗｓＦｒａｍｅＷｏｒｋについて知識がないです。おそらく、パソナさんがＫ１さんの指示通りでコード埋めているので、Ｋ１さんも専門学校程度だから、テレメトリー的な中国人同僚から適当に教われているだけで、でたらめの結果になってしまった。

２人のメクラが夜道を歩くような感じで納品お時期がたどり着いた。正直、このＰＪの本意はどこにあるかは疑わしい。

Ｋ１さんはカナイの同じ上海出身で、感情的はＫ１をけじめしたくないが、彼は上海市民の欠点の見栄はりとか口先では負けない性格あるから、この様子を見て、カナイも教える気分もなくなった。ＹＨさんは自らオフィスで”謙虚にカナイに聞く”手本を見せているけれども、やはりＫ１さんは意識されていない。オフィスの中の中国人同士もＫ１のことを敬遠している感じがあります。こいつはバックが強いって感じがありますね。

それは、ほんとうです。

カナイが考えた末は、ＹＫさんとＫ１さんに”私が見つかった問題点をメモ帳に書くから、時々見てください。”と話をかけた。やはり、高級取っているから、問題を報告しない背任になるので、報告して対策も備える。対応するかどうかはお客様次第ですから、こちらはそこまで責任はない。

ＣｏｐｉｌｏｔＩＭＥのテレメトリーを実装できてから、Ｋｕｓｕｔｏでテストデータを調べられるようになった。これですべての疑問を解決だ。Ｋｕｓｕｔｏに関しては、Kusuto Query Language（ＫＱＬ）というクエリ言語を使用しているので、私はリファレンスを見ながら半日でデータの抽出ができたので、試験データからは発覚されたＰＧ上の”甚大なミス”は次の章（テレメトリーノ３）で話ます。

福主人