Visual Basic(.netも)と共に生きてきた約２５年の振り返り その２
というわけで、その２を始めて参ります。
もう少し、昔話にお付き合いください。
ASP.NET と VB.net（と Java Webアプリ）
2006年ごろだったと思います。評価検証という意味合いで、ASP.NETでのWebアプリケーションのプロトタイプ開発を行ったことがあります。
ASP.NETに関わる前に、Java & IBM Websphere & IBM MQ(PL/I(ピーエルワン、COBOLでもない・・)) という組み合わせで、Webアプリケーション開発に携わったことがあります。クライアントサーバーアプリケーションを主体に開発してきた自分としては、このときのWEBアプリケーション開発は「別次元」のものでした。
今なら、 「HTTP通信はステートレスである」 という前提を理解できていればなんら悩むことはないのですが、
「どうして、Me.xxxx という参照で、画面に表示されている項目の値(テキストプロパティ)を参照できないんだ！」
とひたすら悩んでいた当時の自分がいました。（ブラウザに表示された単なる結果に過ぎないものであり）状態管理をしていないのだから、当たり前ですよね。
また、画面で入力された値のチェックにおいて、今ではばかばかしい？話かもしれませんが、「HTTP通信は信頼性が低く、サーバー側に正常なデータが送られてくるかは怪しい。なので、例えば数値項目であれば、クライアント側のJavascriptでチェックした項目は、サーバーサイドのデータ受け取り側でも同じように数値であるかをチェックする必要がある」、という、今なら考えられない仕様で、クライアントとサーバーの両方で、同じように項目内容のチェック処理を走らせるということを行っていました。
話は戻り、ASP.NETでも、VB.net で利用し開発が可能という点で、マイクロソフトはある程度の囲い込みを意識していたと思いますが、IISのライセンスの縛りが強く、Webアプリを採用する局面においては、Java & Servlet & JSP(Apache Struts) というスタイルが多かった記憶があります。
WPF と Windows Forms
VBというよりかは、Windows関連のアプリ開発の話になってきていますが、VisualStudio2010 .NetFramewrok3.0から WPFが採用されました。実際どうだったのか？と思いネットを彷徨ってみると、@itに紹介記事がありますね。
2010年当時に掲載された記事でした。
この当時、自分はどうしていたかといえば、新しい考え方を把握する余裕もなく、Windows Formsで.過去技術の延長にてNetFramework4.0のアプリを作っておりました。今の職場でのアプリ開発となりますが、社内システム開発着手という点もあり、目新しい技術を使うことにはむしろ否定的で、安定的に動くこと、素早くアプリを構築できること、という、ある意味、目先のことしか見えていない現実もありました。
（正直、WPFとともに提唱された、 MVVM とか XAMLによるGUI画面 など、非常にとっつきにくいものでした。）
ちなみに、社内システムアプリケーションにおいては、
・リリースする端末の数が限定的なことが多い
・仕様変更の度合いがあまり高くない（自分はこの部分がいまだに馴染めず、仕様変更に強いアプリを意識して設計するが、そうでない既存アプリが散在しているのが現実。つまりロジック記述がおざなりになりやすい・・）
・保守メンバーが長年固定化される可能性が高い（よって、偏ったアプリが出来上がっていく）
という理由で、奇抜なこと、変化点が多いことを嫌う現実もあります（個人的にどうしても馴染めない部分でもあります）。
あの当時は意識していませんでしたが、もう少し、WPFの思想のように、データとガワ（GUI）の分離、という部分に大事に接していれば、今のように Vue.js などのWebアプリフレームワークを利用した Web開発への理解力ももう少し高かったかもしれません・・。
文化オリエント(グレープシティ)の存在
Windows GUIアプリケーション開発で忘れてはいけないのが、「文化オリエント（あえてこの呼称にします）」の存在です。社名変更して、ずいぶんと経ちましたね・・。
VB5(6) OCXコントロール時代から、Inputman,VS-Flex,VS-View、Spread、TrueDB Gridと、いろいろお世話になりました。.Net時代（現在）でも、ActiveReportsなど、お世話になっております。
独自コンポーネントを利用することは、技術的な使いこなし要素に偏りが生まれる点はありますが、現状のWebアプリケーションフレームワークの「偏り」に比べたら、文化オリエントの開発ツールは可愛いものだと思います。
こういった開発ツールを利用すれば、アプリ開発生産性をアップすることができることはわかっていても、社内システム開発規約により、外部コントロール導入は不可 といったプロジェクトもありました。そういった場合は、Inputmanのようなコントロールを「自作」する羽目になることも・・。
自分が設計側の人間であれば、迷わず「Inputman」を購入、採用します（自分で作るんだ！という気持ちも大事ですが・・）。
またまただらだらしてきました。
その3へ続きます。
Discussion