複雑性を軽減する開発環境の補助も、現在と比べて全く不足していた。.NETで複雑な処理も簡単に実装できるようになったので、相対的にCOMのランタイムが複雑に見えるようになった。アパートメントという抽象性の高い概念が理解できなくて躓く。COMを正しく実装するのが大変。VB6か、スクリプトコンポーネント(VBSやJSをCOMコンポーネントとして実行可能な、今考えるとやはり早すぎた感のある技術)でないと辛い。これだけ複雑であるにも関わらず、COMを知っていて良かったと思える事として、やはり「インターフェイス」を強く意識する事になったことが、数人の意見で一致しました。この経験が、現在の.NETのインターフェイスや、ウェブシステムでのAPI設計の粒度やさじ加減と言った点にとても役立っています。これは、COMのインターフェイスがほぼ最小のメソッドレベルの粒度で公開可能で、しかもDCOMによってマシン間のRPC呼び出しへの簡単にスケールアップ出来るにも関わらず、その細かい(Chatty)呼び出しが、システムのパフォーマンスと安定性に問題を起こす事が経験として理解できたと言う事です。COMはとても良い経験を与えてくれた良き技術・通過点でした。卒業の頃だと思います。個人的な思いこのブログでも、COMの解説を試みた記事を書いています(未完)。アパートメントの種類はどのように決まるのかこれが未完となっていたのと、内容としてこなれていないのが、ずっと喉の奥に引っかかっていたのです。今回のChalkTalkで完全に咀嚼して、完了させたかった。その目的は達成できたかなと。やってよかったなと思います。COMは愛すべき対象でしたね。「ナナリィ...」って感じです。次回もよろしくお願いします!追記ここで扱っていない、COMの重要な要素として以下のものがあります。メモとして残しておきます。第38回@名古屋、今年もやってきました。APIをてなずけよう」というお題で登壇してきました。今回もギリギリまでかかりましたが、何とか形にできてよかったです。普段は言語系に生息していますが、プロ生は総合力が試される良い機会だと思っています。APIの融合セッション中でも説明しましたが、WindowsのクライアントサイドはこれからUWPが環境の主役となっていくと思いますが、一方で制限された環境故に外部との連携にはどうしても大きなリソースを必要としてしまいます。APIがあるので通信が可能ですが、生USBデバイスなどの、もっと軽量なデバイスとの通信のニーズもあるかと思います。C言語インターフェイスしか持たないサードパーティ製のライブラリなどもそうです。これらを.NET上で簡単に有効活用するための方法の一つとして、P/Invokeを紹介しました。APIを呼び出し、最終的にプロ生ちゃんをデスクトップのウインドウ上を走らせてジャンプさせる、というネタです。APIを主眼に置いて、どうやってアプリを成立させるかと言う事を背景に解説しましたが、P/Invoke自体は定義さえ出来れば、Win32に限らず他のライブラリにも応用できるため、前述のターゲットも視野に入れることが出来ます。Studioのウインドウ外周に光彩(ぼんやり光るヴェールのようなもの)のエフェクトがあり、このエフェクトを表示するために、外周を取り囲むように半透明のウインドウがあるからです(つまり、理論的にはバグではないです)。詳しくはぐらばくさんの記事を見てもらうとして、これを無視するのもちょっと難しい課題ですね。究極的には、人間の目で見てそこに「上辺」があるかどうか、だと思いますが、それを言い始めると半透明だったらどうするんだとか、矩形じゃないウインドウはどうするんだとか、色々ありそうです。P/Invokeの説明を主体にしていますが、実際に作ったコードはほかの肉付けが大きかったです。ソースコードにはコメントを多数入れて、サンプルじゃなくて現実的なコードを作るにはどうしたらよいか、という事に注意しています。ソースコードはGitHubに上げてあるので、スライドの最後で紹介した改良を試したりしてみてください。Fifteen.%d人のブロガーが「いいね」をつけました。