VB：「VB 再考 VB はオブジェクト指向言語か？」

いまさらですが。

今朝はおきてからこの内容が頭を離れません。（どんなだよ・・）
ずーっと悶々と脳内議論していたのですが、ちょっと書いてみます。


■ 何でそんなことを考えていたかの背景




なんで、いまさらオブジェクト指向かどうかなんて話題なのかというと
今やっている仕事やフリーソフトを公開する場合のデメリットとして、
．ＮＥＴじゃないこと、移行しづらいことに原因があります。
VB6 や その技術を使ったVBA（非.net） のような技術を
シュウカツ中も含め散見しましたし、現在そんな仕事をしています。

でも、なんだかVB6ってバカにされてませんか？
Webの人たちからするとVB6 ？ぷふー。
移行できなかった人たち？？？
的な目線で見られている気がしてなりません。

が、フリーソフトでは、環境が千差万別といえるほどなので、
はっきり言って、．ＮＥＴは向いていない。と、思っています。

広く環境を制限しない開発がフリーウェアでは
結構、重要だったりするわけです。
そういうネイティブＥｘｅが作成できる言語。
ＶＣ、ＶＢ、デルファイ などがあります。

Javaも比較的軽いランタイムだけで動くと思えば、候補のように
思えますが、クライアントアプリを作る上で、何がよいかにおいて
ネイティブに勝てるわけではなく選択肢にＪａｖａは入れません。
というより、Ｗｅｂに強いだけでクライアント用のＧＵＩ機能が
貧弱なものについては、正直却下なのが心情かもしれないし、
私が嫌いなだけかもしれない。

が、時代はＪａｖａ ですよね。
ＵＩ だってＪａｖａ + αであればなんでもよいわけです。
けど＋αを最初から考えるならＷＦＰで充分なわけで・・。
やはりあえて、特別にＪａｖａ を選ぶ理由はない気がします。

なので、結果、レガシーでもお客さんがそれでよいならそれで。
と、なることもあるわけです。
そこに参加している人は多いわけで、少しでもバカにされない理由を
考えてみたいなぁ・・と、妄想してました。（ｗ

移行できなかった人々。。ぷっふー。
って、思われてそうな理由のひとつに
ＶＢ6技術者は、.ＮＥＴに移行しにくいなんて迷信があるけど、
どちらかというと本当はＪａｖａ技術者のほうが来ない気がしています。
Ｃ＃ですら、Ｎoな感じでした。

この迷信の裏には、VB6 ＝ 非オブジェクト指向言語。
という定着が進んでしまったというのもあるかもしれない。
2001年ごろ、確かにそんな話題が持ちきりで、.NETはガンガンに違いない！
って、私も思ってました。

蓋を開けてみると手続き型でも書けてしまう・・。（← 書くなってほどじゃない。
なんだこれ・・？？（← こっちのほうが衝撃的だったわ。ｗ
というより、根本が間違っていたわけで。

VB6は、オブジェクト指向言語じゃない！。では、ない。ｗ
というのが、自分の中の答え。
正確には、色々加味してこれなんですが、少なくともVb6技術者は、
.NETにチェンジできる知識しかない。
ではなく、意図して使いこなしていないだけ。ということが最大の理由。

Set objA = new myClass()

これのどこが新しかったのでしょう？
つまり、そういうことだと思う。（厳密にはもっと。）




なので、少しでも自分がバカにされている気分を晴らすために書いてみます。
というより、自分で納得したいだけ？








■ そもそもオブジェクト指向 ってなに？

　まずはこの話に決着しないとダメですよね。

存亡危機のウィキペを使って読んでもらうと、こんな感じ。

http://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91

そう重要なのは、オブジェクト指向 と呼ばれる条件（構成概念の項）です。
本などを読むと、オブジェクト指向と呼ばれる条件として毎回出てきます。

聞き飽きましたよね。
・カプセル化
・継承
・多様性多態性（ポリモー なんとかｗ
・動的束縛？？？？？

（失礼・・。なんか、多様性って書いちゃったｗ＠2011.11.01）

そう・・・なんだこれ！！？？
４つ？３つじゃねぇのかよ！？
(ときどき、多重継承が４つめだったりしますね。)

と、思う人とそうでない人。いるはず。
説明にも書いてあります。

この特性を備えていないオブジェクト指向言語もある。

と。
ここ一番重要です。
そんで、説明がスゴイわかりにくい（とうか、なってない！）ので
書いてみると、

オブジェクト指向言語 と呼ばれるための条件、それは

カプセル化できるかどうか。

だけです。
ってことは・・・ぉい！
VB6はオブジェクト指向言語ですか？
ってなります。
まぁ、話のネタ元はこういうことです。

頭の中で考えた妄想。（いや、よく言われるんだけど）
誰か：「VB6って、オブジェクト指向言語じゃないジャン！」
私：「厳密な意味ではね。」
誰か：「厳密って・・負け惜しみするなよｗｗｗｗｗｗｗ」

てなのをよくやられるわけです。
で、上の話を言うわけです。
すると、

誰か：「でも、最近はこの３つでオブジェクト指向が一般的だよねｗｗ」

と、当然なる。
それは、このwikiを読んで疑問に思った人ほとんどそれかな。
なので、こう答える。

私：「主流がそれであれば、厳密な意味では、Javaも違いますよねｗ」
誰か：「？」

そう。多重継承はどうしましたか？
いつからJavaは厳密な意味でのオブジェクト指向言語に進化したの？？
バージョンを教えてくれ。
（ぃや本当に・・いつ対応したの？？してないの？？どっち？）

記憶では、Java は多重継承できなかった。
今時点2010年の何かを読んでもダメとある。

というより、オブジェクト指向言語の条件と書いたけど、これらは
正確にはオブジェクト指向言語の要素でしかない。
全部を実現すると無駄が増えるので結局のところ

2011年11月時点では完全なるオブジェクト指向言語は存在しない。

というのが個人的な認識。（この発言を読んだのは数年前ですが。）
なので、

「オブジェクト指向じゃない言語VB6ぷっふーっｗｗｗ」

は、

「ばっかじゃねぇーのぷっふーｗｗｗ」

と、今でも思っている。

それと、wikiではわかりにくいですが
・オブジェクト指向
と
・オブジェクト指向言語
と
・オブジェクト指向開発
は、ばらばらで別のものである。という、認識。

特に、オブジェクト指向開発は、その言葉自体が後発で、
Win95以降の世代には、あたかもこの頃に流行りだしたのが
オブジェクト指向のように感じる節がある。（と思っている）

オブジェクト指向は、80年代だっけ？
オブジェクト指向開発と同義のオブジェクト指向プログラミングは、
その近辺だったように思うけど、最近じゃない。
当然、オブジェクト指向言語もそう。
つまり、概念的なものと同義、そうでないものをごっちゃにして
一緒くたに覚えてしまったのが問題なのかもしれないけど、別もの。
なので、

「だって、VB6ってオブジェクト指向開発できないじゃんｗｗ」

という、ヤツには

フォームにボタンでも貼り付けさせてやれば良いと思うよ♪（シンジ風味

やり方は、VB IDE開いてフォーム追加して、ボタンをその上に作るんだよ。
ほらできた。
これ君の言う「オブジェクト指向の継承と生成動作ね。」

wikiにもちゃんとオブジェクト指向の方式として書いてあるけどわかりにくい。
クラスを継承するか、インスタンスを引き継ぐか。の違い。

VB6 は、Com なわけ。
コンポーネント
オブジェクト
モジュール(モデルは、概念だったはず・・・）

いわゆる部品をオブジェクトと呼ぶし、相手がクラスであるかどうかはどうでもよいの。
オブジェクトって意味あいがいつも食い違うのはココ。
あんたらが知らないだけだよ。

最初のフォームをマウスで作る作業をコードで書くと

dim objFrm as formA ' ← いわゆるformA.frmね。
Set objFrm = new formA()

なわけ。（ごめん、formをNewするメソッドが浮かばない 苦笑）
型として使ってるからわかりにくいけど何処が継承なわけ？
タダのクラスのインスタンス生成じゃん。とは、思う。

ところが、このFrmA内には、新しくメソッド追加もプロパティ追加も出来ちゃうわけだな。
たとえば、このフォームモジュール内に

public sub tuikaMeth()

なんてものを書いたりできる。
この作業だけ見るとわからないけど、これって実際には

Application.Form から FormA を定義して、そのFormAにメソッドを追加した。

ということ。
さて、コレは継承でしょうか？それとも継承ではない何かですか？

というか継承ってなに？
VBはコンポーネント指向言語ですからそもそも継承（という、クラスベース方式の考え）が
できるわけがない。
なのに、継承がオブジェクト指向の条件みたいに言われちゃうから、
○○っぽい。ことをできる。といわざるを得ない感じなのでしょうか。
再利用に必要なもの＝継承という発想もMSにはあるらしく、
それでいくと、まさにこれなんだよね。

一応、MCSDのVBの本には、VB6はオブジェクト指向開発に必要な要件を
満たすと書いてある。
ようするに発想と実現方法の違いで継承と同じく再利用できることで
要件を満たしたといってるんですね。

いつからオブジェクト指向の開発要素が
・再利用
・多様性
・カプセル化
になったんだ・・・orz

ちなみにその本にもどんな本にもきちんと
VB6は継承をサポートしません。
とある。
そして、但し書きとしてそれを実現するためにActiveX（Comのことね。）を
使った継承動作（つまり今書いたプログラム）が行えることになっている。

まぁ、確かに継承の使い道ってそういうことだよね。
とある定義（Com内の定義）を元にクラス（Form）が作れて、中身（メソッドの数）をいじれる。

無茶苦茶言っているようだけど、そういうことだと思う。
MSのよくいうActiveX技術を使った継承とはまさにこれなんだと思う。

でも、それはJavaやC++からみたら継承ｗｗｗって呼ばれるかもしれないけど、
クラスベースかComベースかの違いに過ぎない。
継承できないじゃん！＝オブジェクト指向じゃないじゃん！
っていわれるのが嫌でこだわってるなら、そもそもオブジェクト指向の原点が違うってことに
気づいてない可能性が高い。

最初に書いたように

・カプセル化

ができるかどうか。がオブジェクト指向言語の唯一の定義ならVB6は、
カプセル化できる言語です。としか、答えようがない・・。
(ただし、プロパティの隠蔽方法が他と違う。)

でも、
・カプセル化
・継承
・多様性多態性

といわれてしまうと、VB自身継承はできない。と、書いている通り違うとなる。
が、それらしきことができますよ。
というのもまた事実。

コンポーネント化しなくちゃ、要素満たせないし、そもそも部品化して出すとか、
どんだけDLL地獄！！！って、笑われちゃうよね。
（いや、Java技術者はそこまで詳しくしらないからいわないか・・。）

でも、部品化＝ばかじゃねぇの？
ってなったら、Beansはなんのマネか？
と問えばよいと思うよ。

あれこそCoｘ（コンポーネントオブジェクト ほにゃらら）のJava版でしかないわけで。
わかるよ、VisualEditor（Eclipseに付属するVB IDEのRADみたいなやつ）を
一時期でもはずしちゃうわけだ・・。

まぁ、書き直せるかどうかでDLL地獄かどうかの違いは絶対的にあると思うけどね。

・・・やべぇ・・長文になってしまった・・。
多少、Java=オブジェクト指向！！最高！みたいな発想の人に
苦しめられているVB＆VBA技術者に心安心していただけたでしょうか？？

実は、次が本題で・・・やっぱVB6って・・・開発効率上げるための
オブジェクト指向プログラミング要素足りなすぎｗｗｗ
って、話だったのですが・・疲れました。

またこんど。

でも、まぁ・・VBにしろJavaにしろ効率よければ何でもよいと思うのですがね。
私は。
保守的な意味では、
「動いているものを替えたくない」
という力の方が遥かに強く働くわけですから・・。

そして、それと同レベルに思うのが、
いいから開発効率上げるための要素は満たそうぜ・・。
とも思う。
FWでも自作してみれば良いと思うよ・・（ふ・・ふるい。

VBA：「リファクタリング調査中の話」

気になる記事（？）を見つけた。

http://ameblo.jp/partner2/entry-11014203388.html

え？VB6の利用率が英国/米国ではなんだって？？
2009年時点で87％？

なんじゃそら・・・。

とかいって、実は亡国日本もVB6インフラ及びVB Calssic といえるVBA の比率は異様に高いとシュウカツして思いました。
派遣に登録するとさらにスゴイんだなぁ・・って、思います。
まぁ、AccessVBAがほとんどですが・・・。

VB：「速度実験室」

ドライあーしていると、またくだらないことを考えました。
車輪の再発明 大好き人間ですな・・。

VBは基本的に．（どっと）結合（参照）に弱いとされている。

つまり、

Ａ．Ｂ．Ｃ．Ｄ．Ｅ．VALUE

というプロパティ参照が存在すると

Ｅ．Ｖａｌｕｅ

に比べて遅いということだ。

これの理由についてはさておき（しらねぇだけじゃねぇの？ｗ）たまに

With 句はただの記述省略なのか、With イコール 内部代入処理なのか迷うことがある。
内部代入処理なわけだが（ぉい）、その場合、何処まで高速化されているかを知りたくなる。

C言語で書いていた頃はASMとの中間言語を確認することから高速化作業が始った。
IFは、Else はElsseIFは？Case は？Switchは？

などなど。
当時は、実験する時間がネェー！
と嘆きながらも暇を見てテストしていたが、最近では
ダメ・・・だるいわ・・・。
という、堕落プリ。

そう、でも正直ダルい。
IDEに速度実験室機能が存在すればいいのに・・・。

あ・・・。
まぁ。
ほら。

フリーソフトとかでは良くあるわけですが、IDEに欲しいよね。
いまこのFunction はどれくらい速くなったわけ？的な。

指定したメソッドCall をフックさせるだけなのだが、やり方（フック指示させるUI設計）が思いつかない。
思考停止中・・・。

とりあえず、メニューバーからずりずりっとして、このメソッドの開始と終りを計測。
見たいなのでいいと思うのだが。

ま、IDE助けんジャー。（また、唐突に命名ｗ）の機能に盛り込む予定で考えておくか。

そう考えると

・IDE助けんジャー
・のっとNET
・VBAふぁふぁふぁふぁふぁ（また、勝手に命名ｗ テストUNITですｗ。）
・すーぱーめにゅー（これは、Excel入力支援ね。）

と作るものが増えてきてしまったなぁ。
ちなみにのっとNET対応のIDE助けんジャーなので、その中には当然帳票システムが含まれますね。

そういや、昔って帳票をVB Formで作ってなかった？
サラなフォームにコントロールを必要数Addしてゴリゴリやるやつ。

なんだか懐かしいね。
むだむだむだむだむだむだむだむだむだむだむだぁぁぁぁぁ。（壊れすぎ 苦笑）

追記：
どうやら今日は脳みそが死んでるらしくしょーもないことばかり考える。（笑

これら機能をまとめたものを

VBAマクロス

と命名したらやはり怒られるのでしょうか？
そうなるとやはり、長時間の処理には歌を歌ってもらうしかなさそうですね・・。（ どんなだ。。

残念ながら変形はしないと思うが・・・。

VBA：「フレームワークの話」

おはようございます。

眠いですえ・・。
昨日、一昨日と・・・本当にどうでもよい低レベルな技術アピール？のような話を書いてしまいました。
凹んでいます。

あまりに低レベルというか、情けない話が多かった。
今日はもっと低レベルに具体的なFWの使い方の例を書いてみます。

え？それFWじゃないんじゃないの？？
って、思うかもしれません。

FWの定義については、個々どう思うかあるところでしょうけど、私は私が作りたいFWを作っています。
どうぞご了承下さい。

いきなり読んでもわからないと思うので、初見の方は、前回のFWに関する投稿をどうぞ。

▼ 「フレームワークの条件」
http://bsn.cocolog-nifty.com/blog/2011/08/vba-0d30.html

FWがあると何が嬉しいか。
いや、正確にはどんな処理が同じ記述を繰り返すのか。
そう考えた時に旧式VB記述であれば以下の処理が最もそれに近いと書きました。

Private Sub UserForm_Initialize()
    Me.Caption = "タイトルだヨン"
    Me.TextBox1.Text ="しょきちだよん"
    Me.Lable1.Caption = "てきすとぼっくすのせつめいだよん"
    ：
    以降、これらをコントロール群数繰り返す
End Sub

これをFWの用意した関数を使うとこうなります。

Private Sub UserForm_Initialize()
    Call setFrmCaption(Me)
    Call setSystemTextToCtrl(Me)
End Sub

setFrmCaption で、タイトル設定をします。
setSystemTextToCtrl で、フォーム内のコントロール（TextBox,Label、ListBox、CombBox、CheckBoxなどのすべて）のコントロールに対して、設定値（シートに記載）された値で設定します。

え？設定値がシートにあるの？どんなセキュリティだよ。
って、思うかもしれませんが、VBAソースに書いても一緒ですし、外だしすることでソースに手を加える必要がなくなり、納品後もユーザが自分で修正することが可能となります。

設定シートはこんな感じ。

フォーム名+コントロール名で一意のKeyを生成しています。
これをCollectionに投入します。
Collectionには、ユーザ型は入りませんのでValue値に該当する部分にはクラスを使います。

例えば、ログイン画面の「パスワード」というラベルをlblPassword に設定するには

me.lblPassword.Caption = "パスワード"

となりますが、
FW内では、

if Typename(obj) = "Label" then
   obj.Caption = CollectionSys(obj.Parent.Name & "_"  & obj.Name).Value(LangJPN)
end if

となっています。（正確にはちょっと事前処理とか挟むので違うのですが。）

CollectionSys(obj.Parent.Name & "_" & obj.Name).Value(LangJPN)

では、CollectionSys というコレクションからバリューというプロパティの値を取得する際、LangJPNという定数を使うことで日本語のValue を取得しています。
これが、英語ならLangEng という定数を使うと英文で書かれたValue値が入ります。
クラスのプロパティ値には、TextBox の既定プロパティがText であるようにValue だけを指示する、またはValue抜きで支持することも本来可能ですが、メンドクサイのでつけていません。

また、このコレクションのValueにはクラスが設定されているので、Value以外にも

・Enable
・Visible

などを設定できるわけですが、今回はAuth（権限3種の設定値）を持っています。
例えば、Login Button とあれば当然ログインボタンですので誰でも押せる設定としてYes（規定値） が入っています。
（未記入字の動作は、CollectionSｙｓのコンストラクタ側で判定処理しています。）

この権限はフォームにもコントロール別にも設定できますから、Aさんのログイン権限が社員レベルであればマスタ系の画面へは遷移でできないようにそれら画面への遷移ボタンには、各種Noを設定しておきます。
（設定値は、最初の画像にある設定シートで行います。）

まぁ、これはあくまでもシステム機能なのですが、通常良くあるものを設定できるようにしています。

参考までにログイン画面を表示するとこんな感じです。

こういう表示名称の変更がいとも簡単に切り分けられるのはシェアウェアなどでよく使われるテクニックですが、要するにConfigとして外だししているからこそのメリットです。

まぁ、ここまで書くとそのコントロール名を列挙するのがとても面倒くさいですよね。
なので、当然この設定シートでは右クリックすると、そのFormのコントロール名を出力し、Keyは自動計算で作成されるようにしています。

これが確かにFWかというと違うのですが、コントロール設定を毎回書かないというのが標準化されている部分です。
この辺は、仕事でもいつも使う手でした。

うーん、とりあえずこんな感じ。
少しイメージつきましたでしょうか？

加えて言うと、Initializeで記述している内容は、前回書いたでこれーたに近いラップを用いることで自動化もできるはずですし、皆さんそうしているのだと思います。
が、今回はFWの機能の洗いだしをしながらの開発なので、その辺はまだ保留中です。
（あまりがちがちにFWすると自由が利かなくなってしまうので・・。）

VBA：「フレームワークの条件」

やばい、ヤル気が・・。

自分の悪い癖ですが、完成が近づくと作りたくなくなる。という、ヘンな癖があります。
創造性が減ってきてしまうというのも大きいのでしょう。

が、もうひとつ考えることがメンドクサイという場合もある。
いまそれ。

脳みそが停止しているので考えるのが面倒。
です。
Do すればすぐにヤル気はでるのでしょうが・・。

さて、知人の会社向けにVBAでマクロを書いているわけですが、その中にFrameworkとなるものを組み込んでいます。
正確にはフレームワークだけではなく、それを使いこなすためのIDE的なものも組み込んでいます。
本来の仕様だけでも大変なのに何してんだか。

ところでフレームワーク。
いまだに何だかわからない。ってひとが多い。
特にMSしかいじったことがない人はフレームワークは.NET フレームワークのこと（だけ）だと思っているふしがあるし、.NET Frameworkをいじくっているとフレームワークとは何か・・がわからなくなることがある。

ココからは個人的な定義です。

フレームワーク＝関数ライブラリ群ではありません。
フレームワーク＝クラスライブラリ群であり、ラッパ群に近いです。
フレームワーク＝開発環境に必須なものではありません。
が
フレームワーク＝実行環境に必要なものです。

１つめは、ただの関数群ではないので関数、メソッドコールだけをするイメージではありません。
２つめは、オブジェクト指向っぽいものを使っています。と、言っています。
３つめは、.NET Frameworkへのアンチテーゼです。
　　　　　　なくても作れるはずのことを補助するために使うのだという趣旨を示しています。
４つめは、.Net Framewrok使用者への誤解を解くものです。
　　　　　　環境依存を生み出す結果になりうるものを当たり前のように使う必要性に私はNoと言いたい。

.NET は4つ目の問題を解決するために産まれているはずでした。
COMアーキテクチャの集大成であったはずのWindowsDNA。
そこに介在した問題を意図も簡単に解決したのが.netのCLRです。（と、彼らは言いたいのだと思う）

が、いつの時代もVer問題における下位互換の問題は介在し、OSと根っこごと組み込ませてしまった.NETは厄介な存在になりました。
.Net の成功のひとつはCLRにおける技術者の取り込みにのみあり、frameworkとしての有効性を認識してもらった結果ではないと思う。
事実、私は、IDEプロバイダー経由のデータアクセス機能は使わないし、使えたものじゃなかったと認識している。

CLRを実現した最大の功労者はCTSでありCTSは、Frameworkの真髄だと思う。
その根元にあるのはVariantのようなデータ型を内包できる仕組みで、いわばラップすることで製作者が意識しないで制作できる技術にあると思っている。

話をはじめに戻すと何かというとFrameworkの条件とはなにか。
そして、Frameworkとは何なのか。どうあるべきか。

個人的解釈を逆に辿ると見えてくる

フレームワーク＝実行環境には必須ではないが
フレームワーク＝開発環境にあると便利で
フレームワーク＝非オブジェクト指向のメリットも使うことで
フレームワーク＝非オブジェクト指向の人も意識せず使える

こんなところ。（かなり無理がある？）
まぁ、個人的展開なんて意図と目的あってのコトなのでご了承を。

ナゼ非オブジェクト指向にこだわるか。
それはVBA2003だからです。
.NET機能を存分に使わないことを旨とし、AcitveX的なオブジェクト技術を書いてまで作るものでは本来ない。
と思っているから。

AcitveX的なオブジェクト技術とは、VBにおける唯一（？）のオブジェクト指向の継承導入方法であり、実際VBAでそのオブジェクト指向を使わないかというとそんなことはなくて、すでにVBの段階でUI作ると使っているわけです。
それの実体はDLLなのかComなのかは参照先の違いでしかなくて、実際にはボタンひとつ作るたびにオブジェクト指向を利用している。
しかし、利用者はそんなことを知る必要もなく作れてしまう。
まさに意識しないで使える技術と環境だ。

フレームワークとはそうあるべきだと思う。（特にVBAは。）
Strutsがフレームワークであるとするならば、それを使うには彼ら自身をラップしたクラスを生成するところから始るのはおかしくて、すべてのハンドリングをパラメータのみで制御すべきだ。

それはイコール 処理の自動化を示唆する。

私は

常々プログラムとは処理の自動化に過ぎず、それ以下でもそれ以上でもない。

と思っている。
感動を貰えるソフトがあるじゃないか！と、言う人もいるだろうが、それはついて回った結果でしかなくてプログラムそのものの目的を厳密に示していない。

（なんで・・こんなに教科書口調なんだ？ｗ）

すると、プログラムは処理の自動化を目指し、フレームワークは開発者に開発支援として技術導入の自動化を行うもの。と考えることも出来る。

なので、私はフレームワークとは

高度な知識を必要とせず、意識しない利用ができる技術導入のツール

であるべきだと考える。

ようやく本題です。（なげぇ・・・ｗ

フレームワークの条件それは、フレームワークとは何かから見えてきたものを備えていることだ。
ココから話がかなり簡単になります。（ｗ

では、自動化したい開発支援とは何か。
確かに.NETのプロバイダー生成機能はすばらしくそれを具現化しましたが、選べないという選択肢を生んでしまった。
これはフレームワークの宿命かもしれない。最近そう感じる。
なので、選べる技術や考慮を導入すべきというのは、今後のFW（もう面倒なのでフレームワーク 以下：FW）に必要な視点だと思う。

その上で自動化できる点を列挙してみる。

▼ 自動化可能な点
　・ログ作成
　・メッセージ処理
　・MVCに近い処理
　　　.. データセット処理
　　　.. バリデータ処理
　　　.. コントロール制御処理（ん？英訳OKか？ｗ
　・データ処理

ここまで書くと、なんだStrutsにあるようなものばかりじゃん。
と思うかもしれないが、Strutsを初めて使ったときの感想を正直に思い出してみて欲しい。

なんで、UI からConfig生成できない？

って、思いませんでしたか？
他もそうです、ハイバネなどなどなどなど。
なんで、テキストちまちまカクンだよ。！

まぁ、最近はEclipseでなんでもできるようになってきましたよね。
そう。あれです。（たぶん・・使ったことないけど。）
つまり、Frameworkを使うなら使うための設定をするUI から提供しないとだめなんだよ。
そして、その設定が他の設定と連結して動くこと

も

可能であること。
という発想。

それは、.NETが最初からやってくれたこと。（失敗点は、先にあるとおり選択肢が煩雑化したこと）

では、具体的に何をどうすべきか。
ログで考えるとこれこれこういうところにはログがほしいので出力。
これがログ。
逆説的に書くとこれこれこういところ以外はログはいらないので勝手に判断して出してくれ。
そのための支持は、FWアーキテクチャの思想に任せる。

まぁ。このFWアーキテクチャ思想に任せるというのが問題でどれだけ優秀かってのと、自由、選択の自由の介在を何処まで許容できるかに掛かってくる。

そうすると、やっぱりココで必要だから設定でこう書いたらこう出力すべし。
となる。
問題はどう書いたら出力するようにするか。
通常あるのはエラーをトラップ（これはクラスが親から継承されているため）しているのでトラップレベルに応じて出せ。
である。

そういった意味合いでログは良くできてきてたと思う。
他に方法がないのかは考えようだが。

そんで、これは本来メッセージ処理にも活かせるはずなのだが、WebはWebサーバにお任せすることが多く、MVCで書かれているものはそちらで動く。
そのためにFWを活用するかという次元で同様になるのだが、VBAはMVCモデルもなければWebサーバもない。
あるのはVBAのためのランタイムだけだ。
これを大きくラップするにはハンドリングをフックさせる以外方法はなく、いてれーたは使えずでこれーたなる。

でこれーた でFWを書くとさすがにVBAしか書いたことがない人には突然フックされ書き換えられている怖さはあるだろうが、それさえ克服すればどうにかなるんじゃないかと思う。

いきなり、自動化のための技術解説になったがそれが本質ですべて。
ただ、そうじゃない方法がある。

それが改めて関数という概念で自分が指示するという原始的な方法。
最初に書いたのと違うじゃん。と、思うなかれ。
どの道選んで書いていくのがConfigになるかソースになるかの違い。
フックさせるか指示するかの違いです。

なのでVBA FW に必要なものはその２つを選ばせることに始る。
が・・ちょっと時間的に難しいのとFWナレッジが不足しているので前者フック型は後者関数型の後で制作することにする。
（まぁ、順序的にそちらのほうがよいのもある。）

と、まぁここまでは自動化可能な点の話を書いたわけですが、OR。
つまりインピーダンスミスマッチの部分について、本来FWが持つべき思想なのかというのがある。
Java系、MS系でもこの辺は別離しているものが多い。

が、私が目指すものは取込んでいる。
なぜかというと、インピーダンスミスマッチを解消するためのView（これはビューテーブルのほう）に該当する部分は、通常エンティティクラスなどを代用するわけですが、これはMVCが独立してもてて初めて意味を成す。

つまり、最初にVBA の処理をMVCに落とす必要がある。
（といっても、MVCを目指して作っているわけではないです。）
通常の検索一覧画面などならVBA及びVB6技術者は、UIに情報をセットする場合以下のようにしてきた。
（スゴイ適当）

１） UI 表示（form.show）
　　・textbox.text = 検索値
　　・label.caption= 検索値入れてね
　　・button.value = 検索

２） 検索処理(call kensaku)
　　・データ一覧=kensaku(textbox.text)
　　・データ一覧があれば
　　 なければ・・・
　　・Ui.リスト.1行目 ...
　　　2行目...
　　　3行目 ...
　　・画面に反映

こんな感じ。
勿論、プログラムを書くとこんな簡単な話ではなくて、kensakuに渡すテキストボックスの値は検索値として正しいかどうかをロジック的に判断する必要があり、そこにエラーがあればエラー処理を開始する。
なんてことを毎回毎回毎回書いてきた。

FWはこれらを自動化するためにある。
なので、FWを使うとこうなる。

１） UI 表示（form.show）
　　画面表示関数（form）

２） 検索処理
　　検索結果表示関数(form)

以上。

それぞれの関数は、渡されたformの構造を理解しており
・どんなコントロールとどんなテーブルのどんなカラムがどんなときにリンクしているか
を知っていて、
・どんな表示を行い、どんなエラー処理が必要か
を知っている。

だって、テキストボックスはテキストボックス名.text でしか値を入れることはなく、取り出すこともない。
（断っておくが、テキストボックス.text とテキストボックス で取り出しているものは必ずしもイコールではない。デフォルトプロパティの存在だけで済むことでもないのは理解のうえで書いてます。）

ということは、画面にどんなコントロールがあるときはどんな設定の仕方になるかは決まっている。
つまり、MVCでいうビューコントローラーです。
また、画面に表示する値はどのデータベースのどのテーブルのどのカラムがでるかはある程度決まっている。
これはMVC２におけるコントローラーとOR機能です。
当然、どの画面に出すのかがわかっているのでどのコントロールにどのような整形が必要かも決まっている。
これはMVCにおけるメソッド、ビジネスロジックですね。

決まっている＝自動化できる部分だ。
でも、自動化に必要な指示はどうするかという問題が残る。

それがFWの思想で行うか、個別に指示するか、個別に指示する設定集を作るかどうかという部分。
この３つを自由に選べるようにしたのが.NETでありFWだ。

しかし、.NET とそれ以外のFWで圧倒的に違う部分、それがデベロッパへのUIの提供だと思う。
確かに技術者はテキストベースに設定ファイルを作成することは難しくないし、どうでもよいと思っている。
が、なぜ効率化を目指すFWの設定作業自体に効率化を目指さないのか不思議でならない。
敷居がどうのこうの、開発効率がどうのこうの。
あると思う。
統一され洗練された機能のUI設計は本来スゴイ難しい。

そこに力を入れるくらいなら実機能であるFWそのものに力を入れるのは当たり前だろう。
が、これはJava、.NET などのように先進的に進んでいくべき言語及び環境にのみ当てはまる。

申し訳ないがVBAは枯れた技術といえる。
枯れた技術のFW機能を期待している人は、おそらくほとんどいない。
また、VB6 及び VBA はAPIコーラーの代名詞だと私は思っている。
すると敷居が下がり使う人も幅広くなる。
故に寿命が異常に長い。
FWは、どうあるべきか。
それはVBA であるか それ以外であるかで大きく異なるといえる。

VBA で必要なのは開発支援の自動化をUI付で提供でき、かつRUPのようにそれ自体が道標になる手続き型であり続ける必要がある。

なので、私が作っているFWではORのための設定ファイルは書けるが書かない方法も選べ、設定ファイル生成に必要な煩雑な作業（別名コピペ、記述の嵐）は、できるだけ手続き的にできるようにしている。
（といって、まだまだ洗練されていないので公開はできないが）

OR設定ファイルがあるのならば、本来MVCの設定ファイルに使えるはずである。が分けている。
UIには
・表示文字列
・表示状態
・挙動

が存在するわけだが、これらは最初に書いたでこれーたで付ける機能であるべきです。
が、まだ自由度の介在見地が定まっていないため挙動はVBからとし、挙動による表示状態の設定もFWをコールするという原始的な手法になっている。

　　：
　　：
　　：

なんか・・・全然書きたいことと違うことを書いてきてしまいました。
掲題のフレームワークの条件とは、フレームワークが備えるべき機能のことをさしており、それが備わっていればFWと呼ぼうと。書きたかったわけですが、備えるべき機能は自動化すべき機能で片付けてしまいました。
自動化すべき機能とは煩雑化している作業であり、その作業にはFW自体の設定を含みました。
そして、FW自体の設定は、UIとして提供されることが必須である可能性はVBAのFWにのみかなりの確度で存在すると書きました。

まとめるとFWの条件とは、

・煩雑化した作業を煩雑化させなくする為のなんらかの機能を持ったもの

ということになり、
FWの機能とは

・煩雑化した作業を煩雑化させなくする為の技術提供

となる。
ふぅ・・・。

ここまで書いていてなんですが、VBA向けのFWまたはFW利用技術はIDE に統合されるべきかという問題がある。
IDE専門で行くともっと違った機能が欲しくなる。
例えば、前から書いている通りリファクタリングの機能がそれ。
しかし、これはFWといわない。

つまりFW機能利用技術とは上記煩雑処理を非煩雑化させる機能ではあるが、実行時の挙動に影響を与える範囲で非煩雑化を行う技術といえる。
なので、今後作るであろうVBA Unit2（ぉいｗ）のようなものがどちらに含まれるべき要素なのか・・・。
ちょっと考えたくもない気がしてきた・・・。

手本はVSであり、.NET向け開発Devである。
それは確かなようである。（なんで・・・ある止めｗｗｗ
しかし、技術としての.NETはFWとして失格（やりすぎ）な要素もあってCTSとCLRがそれ。
アレがなければ本来.NETが環境依存を生み出すことはなかったはずだし分離も出来たと思う。

ソフトウェアはソフトウェアインストールですべての問題を完結すべきでそれが理想

そう思っている。
故にVBAのFWはそれを実現できるMS向けFWということになるし、そうあるべきだ。

えー。
なんか思いつきで書いたら長くなりました。
ごめんなさい。
そして、ここまで読んでくださった方いらしたらありがとうございました。

よろしければFWについての見解、いただけると幸いです。
（小生の技術力が低いのでそれを実現できるとかできないとかありますが、伺っては見たいものです。）

※----ついき----※

ちょっと文面あさるのが面倒なのでここに書きますが、いてれーた と でこれーた って対比のように書いてるところはシャレです。ｗ
誤解しないように。

いてれーた は、要素を順次的に操作するためのもので
でこれーた は、要素を継承とは違った形で装飾させるためのものです。
なので、全然意味は違いますよ。（あくまでも音的に似ているだけです。）

加えて言うと、非オブジェクト指向型のFWを作るにはビルダーやコンポジットなどの要素（ようそのみです。）をイメージしてもらうとわかりやすいです。
再帰的である必要はありませんが、コントロール群を画一に操作するにはインスタンス生成（つまりInitialize）に置いて、コントロール群に順次または、ランダムにインタプリタされた構文に基づいてアクセスする仕組みが必要です。
これらは実現する際にオブジェクト指向が持つ性質を備えた言語でなければ実現できないことがありますが、別にそれらパターンもFWも経験定石の集まりであることに違いはなく、作ろうと思えば非オブジェクトで作れるわけです。

あくまでもオブジェクト指向を使うかどうかは、この場合、メンテナンス都合でしかなくて逆に使ってしまってはVBA及びVB6技術者にとってデメリットでしかないことは言うまでもありません。

デザインパターン？っけ！

それでOKだと思います。

VB.Net：「久しぶり！VS2005」

こんにちは。

ちょっと、久しぶりにVS2005をいじる機会がありまして、いじりました。
VSじゃないな・・VB2005だな。

で、VBA2003（非.net） ばっかりやってたから、そのIDEの操作に戸惑う戸惑う・・W
何処に書くんだっけこれ？

何でもかんでもフォローされて書きにきぃーー。（笑

なれないといけないなぁ・・・って、思うんだけどちょっと時間がなくなってしまったので頓挫中。
いまはVBA Excelで知人の会社の受注管理システム作ってます。

私が忙しくなっても大丈夫なようにほとんどをFW化してしまうことで、キャプションの入れ替えや設定をすべて外に出していく設計な都合で、少し進みが遅い。
というより、あまりに仕事から離れすぎていてビビるくらいに設計能力が落ちている。

簡単に作れば半日だったものをハードコーディングを極力減らしたりしたためスゴイ時間掛かってる。
DB設計も久々にやってるのだが、本格的なDB設計にするわけにはいかず適当なDOAにしたらなんかめんどくさいことになった・・orz

ちゃんと時間をがっつりとってやってあげたいんだけど色々と忙しくて・・。
すまん。

で、ふと思ったこと。
VBA は良いツールだと思う。
VB.net は自由度が高くなったから一度やりだすと止まらないくらい楽しいと思う。
C＃ は、もう間違いなく楽しいと思う。

が、就職活動で感じる需要は常にJavaだ。
99％がjava。
なので、あえてMSだけを狙っていくのもありなのか？と思えた。（ｗ
どのみちアンドロイド需要が終わると、クラウド需要でUI設計がどれくらいできるかに掛かってくると思う。
サーバサイドを作りこめる人は沢山いるからね。
WPFのようなものを今から使い慣れるのはとてもよいことだと思うが、Azure を利用しつつというのが前提じゃないとMSである意味は無いと思う。
と、感じた。

まぁ･･･猛烈に感じたのは異様にAaccess VBA の需要があることと、Excel VBA ばかりやってるとAdo.net とかの使い方を忘れてしまうよね。ってこと。

今後はVB.NET かC＃ で外面作りつつ、帳票周りをExcelVBA のFWでって感じに慣らしていくのがベストかな。
そう思えた。

VBA：「なんかよくくるんですが・・」

『VBA マクロを無効 開く』

てな、キーワードでいらっしゃる方が恐ろしくいらっしゃいます。
おそらく、睡眠日誌と同じレベルの検索ワードです。

・プログラミング的なものとしてのマクロ無効で開く

ってのと、

・単純に「マクロ無効にしますか？」でメッセージにどう対応したらよいか

の2通りの意味があるんだと思います。

前者は、開発者向けの話で、後者はどちらかというと一般の人向けの話ですね。

やたらといらっしゃるのに実はこのブログにはそんな人のための情報は載せていません。
なぜ来るかというと、この記事が引っかかるのです。

http://bsn.cocolog-nifty.com/blog/2010/08/vba-1a12.html

その記事にも書いてますが、プログラミング的なことはここに書けません。
ただ、ヒントだけ書きます。

が、
まず、VBA でマクロを有効にすることの危険性を知ってもらうために後者の一般人が考える

・単純に「マクロ無効にしますか？」でメッセージにどう対応したらよいか

について、書きます。
マイクロソフトのExcelやWord、Access、PowerPoint、Outlook などなどの製品にはVBAと呼ばれるプログラムを作成するための環境が付属しており、それらで作成したものはマクロと呼ばれています。

マクロは、通常の編集結果や画像をExcelファイルなどに保存するのと同様にそれらファイルに一緒に保存することが出来ます。
マクロという呼び名ですが、詰まるところ普通のプログラム同様のソフトウェア（処理を自動化するためのもの）と思ってもらって構いません。
なので、がんばれば結構危険なことをそのプログラムが出来てしまうのです。

一時期、それらを悪用してファイルを開いたら何か悪いことをするプログラムが流行りました。
そういった事態でも突然プログラムが動き出さないようにマクロが一緒に保存されたファイルを開く場合には、

「マクロ無効にしますか？」

と聞かれるわけです。
初めてそのファイルを使う場合や、信用できないところから落としてきたファイルならば

「無効にして開く」

を押せばよいです。
するとマクロ（プログラム）は、その時開いたファイルについては、その時だけ動かないようにして開くことが出来ます。
注意すべきは、その時の1回限りなので次開いたら、また同じメッセージがでます。
これは、「無効にして開く」を押しても「有効にして開く」を押しても同様です。

なお、一番よいのはその画面で右上の × ボタンでそのメッセージを消してしまえばファイルすら開きませんからよほど信用できないファイル（ウィルスチェックし忘れたファイルなど）なら先にそれを押して、ファイルを先にウィルスチェックなどでチェックしてから開くというのが正しい手順になります。

何事も

１） ファイルを落としたらウィルスチェック
２） マクロを無効にしてファイルを開き、中身が目的のものか。怪しくないかなどを確認する。
３） 問題なければ、「有効にして開く」 で開く。

とすればよいのです。
会社などであればそもそも送られてきたファイルを開くこともあります。
その場合も同様です。
ただし、３） の手順だけは本当に信頼できる相手なのかどうかを判断した上で押すべきです。

そして、わからなければ社内SEにでも電話して聞いてください。
彼らはこの手の質問に慣れっこですし、セキュリティに関わることもありますので、必要とあらば飛んできて確認してくれます。

とはいえ、やはり何事もむやみにファイルを落とさないのが一番ですね。
また、マクロが入ってますよ。と予告されて渡されていないのにマクロが入っていると警告された場合には絶対に開かず、ファイル提供者に確認を取る手順は絶対に必要です。
これはSE業界の人でもやっている手順です。
恥ずかしがらずに確認しましょう。

そもそもそんなプログラムつきのファイルなんて使うことはない！
という人は、Office製品のセキュリティレベルを最高にすれば済みます。
もうこのメッセージはでてきません。（変わりにVBAは何も動きません。）
この点は、2007以降のOffice製品であれば最初から最高になっていた気がします。

Excel であれば、[ツール] - [マクロ] - [セキュリティ] から設定画面にいけます。

また、会社であれば社内SEが社内PC全体の設定として最高にしているはずです。
（マクロを動かせるマシンというのを別に用意したりします。）

続いて・・・技術的にマクロを無効にさせる手順です。
おそらく用途としては、他プログラムからVBA付きのファイルを開きたいとかその辺だと思います。
その場合確かに聞かれちゃ困るよね。
でもその辺のスキルもナレッジも無い企業が連結プログラムを書くなと言いたい。

そう思うと、そもそもこの質問で来ることが裏を書いている可能性がある。
つまり無効にさせる方法＝有効にさせるヒントが出ていると思っている人がいるって事。

どちらかというと、社内SE的にはこれが一番多い問題なんですね。
わかるけどさ・・・。
ただ、その前にどうしても社内で使うマクロでメッセージがでるのが・・・という人向けにいくつかの提案です。

１．そもそも確認が出てほしくない理由は何かを考える。
　　→ メンドクサイ。という、社員の意見なら「セキュリティポリシーが足りない！」と、一喝しましょう。
　　　　「都度確認させることに意味があるのです。」くらいは言いましょう。
　　　　行動認知的にどうこう言われても同様です。

２．どうしてもそれを実現しないと客先のなんだよね・・・。
　　→ １．同様です。
　　　　が、仕事が取れないとあらばまずは、御社セキュリティポリシー的にそれでも問題ないのかを
　　　　確認することから始めるべきです。
　　　　それで納得しないなら少し怪しい会社かもしれないですが、今回限りということなのであれば・・

３．例えば、配布方法を考えます。
　　→ ひとつは、認証が通るように署名を使う方法やActiveDirectoryのように権限設定等から入ることもできます。

４． いやいや、ADなんて高くて買ってないよ・・。（← あるのか？）
　　→ 再三確認し、なおかつ誓約書取るくらいとってからであれば、彼らの責任で「無効にする設定の逆をやればできます。が、会社が潰れますよ？」といえばいい。

わかりますね。
潰れちゃ嫌だからどうにかして。といってきます。
腕の見せ所ですね♪がんばって。

でも実際には、よく聞かれますよね。
VBA を最初から有効にして開きたいんだけど・・・。
って。

でも、何度も言いますがあなたが会社の利益を守るSEならば、ない。と答えるべきです。
リスクジャッジが出来ない人をリスクから守るのもSEの仕事ですよ。
一番や厄介なのが「他でそういうのをやってもらっていた」というヤツ。
さぁ、今度は自社と仕事の天秤です。どうしますか？
事前に答えを考えておきましょう。

あぁ・・・私もよく言われたなぁ・・・・胃が痛てぇ・・・。

で、今更ながら、検索ワードの第三の理由が思いつきました。

・VBAを全部消したのに「有効にするか」と聞かれるので無効にしたい。

ってのがありました。
これ・・・SE初心者に多いんですが、単純にコードが残ってるんですよ。消しなさい。
むしろ、それを自動化するマクロを作るのが君の仕事だ。（笑

.NET「．ＮＥＴ 鳥瞰＠2011」

こんにちは。

珍しく．ＮＥＴについてです。

なんとなくボーっとしていたので、睡眠日誌メーカーのOutlook向けマクロでも書こうと思って作成し始めたのですが、30分、1時間と立っても品質ばかり気にして完成しないので飽きてきました。（ｗ

で、このマクロの中で配布目的のVBA スクリプトの癖にフォームを使うという面倒臭いことをし始めました。
受信フォルダを選択するための画面を作ってあげよう。

ってなのが始まりなのですが、配布の問題がありますよね。
それにVBAでフォーム処理となると・・・どうにか効率化しなくては・・と、部屋を眺めたら、ふと

「Java デザインパターン」の本が目に入りました。
？
はて？
純正VBでデザインパターンのようなことできないだろうか？

オーバライドのようなことをさせたいわけじゃありませんから、概念だけです。
例えば、FormのようなMSオブジェクトはどんなに構造化していっても、Builderパターンのようなものになってきますよね。
つまり、そういうこと。
それをまとめてくれちゃったりしてるサイトないかなぁ・・・。（← おまえがやれ・・
なんて、考えて検索してみたらたまたま、この記事が出てきました。

http://www.atmarkit.co.jp/fdotnet/vbcheer/vbcheer12/vbcheer12_01.html

VBでデザインパターン？？
はて？本気か？（← お前もだろ・・

で、読んでいくと・・・そう、VB とはVB.NETでした。
ちゃんちゃん。
てか、この並びで探すとなかなか読み応えのある資料がでてきますね。ちょっと感動。
以外にもがんばる人多くて、感動です。
でも・・・きっと彼らもなぜVB6でそこまで・・と思ってはいるのだろう・・か？。
いや、実行形式が作成できればなんでも良いんだと思うんですが・・？ちがう？

で、その並びから見えたリンクをぽちっとおしてみた。

http://www.atmarkit.co.jp/fdotnet/special/dotnet/dotnet_01.html

はい。
まったく前段の解説とは関係の無い話のようで関係のある話のようで・・。

要約します。
.NET ってのは、.NET Framework ってのが技術名として長いからそう略して呼んでた頃とそうでない頃があるんだよ。って話。
ではなくって。（ﾆﾔﾘ

.NET というややユビキタスに似た需要取り込みの世界観、つまりビジョンを当初は指していたんだ！
と、言いたいらしい。

はて？
いや、確かに当初にその辺のビジョンをやたらと語っていたのは覚えているが、それが崩れたきっかけがSOAPに代表される通信技術の取り込みミスでウンたらカンタラ。

はい？
単純にプロダクトライフサイクルミスでしょ・・。

自分も2002年のβから.NETに触れてきたけど、そんな技術云々感じたことが無い・・。
あ、自分のレベルが低いからか・・・orz
いや、そういう話だけじゃなくて、当初から言語転換、移行の難しさが叫ばれたわけで・・実は最近でもVB6システムなんてザラにあるわけですから・・。

逆に技術的に先進的じゃなかったというのであれば、いつになったらJavaはVCで作るようなレベルのUIを提供するのかしないのか・・。なんてね。
クリックの仕方に特徴があるけど、仕様です。は、通じないわけで・・。
先進技術だけが理由ではないと思う。
（Javaで私が一番嫌な部分です。）

で、最初の話に戻しますね。
VB6的デザインパターンを探すような人が今でもいるわけです。

ごりっとね。
勿論、そこにはMSクラスはいわゆるClassじゃなくって、MSクラスです。
と、認識している前提があるにしても試みは面白い。
というより、そこはサイエンスな世界になってきたね。（ｗ

そんで、今度は記事に話を戻すと・・・散々技術でけなしておきながら、

「.NETとはなにか！？」 ← 10年前も聴いたよ・・それ・・ｗ

で、技術構成を列挙して終わるって・・・・。
ナンノ記事かいな？？これ・・・。
10年前との呼称に関する違いはどうした？

あ・・・この記事の目的は鳥瞰なのか・・・？
なら・・.NET 単体で考えることの意味がないことを書いたほうが良いと思いますよ。
いまどき単独で何かしましょうなんて・・。まず、ないから。
チームファンデを買える会社ばかりじゃないでしょう。

.NET で作成できるプログラムの鳥瞰を書きたいのか単なる構成を書きたいのか・・。
構成＝鳥瞰ではなく・・それはただの構成です。と、言いたいな・・。

じゃぁ、実際にASP.NETでUI を支える言語技術は？
間接的に補助するFWは？
直接的に支援するサードパーティーは？

どした？

ってことで、ヤル気がなくなってきたので・・・VisualBasic6.0 ステップバイステップでも読もうかな・・冗談です。
（どんだけ、VBずきなんだよ・・ｗ）

で、池ネェ・・・。
一番重要な話。
最初の話に戻ります。
VBと書かれていても、実はVB.NETだったりします。
それはVBAにもある話なので、技術の見極めは必要と思う。
が、VBAをバカにするわけじゃないけどVBAでゴリゴリ書くってのは・・やはりどこかナンセンスを感じる。

だからこそ、せめてデザインパターンでも適用できればなぁ・・・なんて？
考えるんでしょうかね？？

お？まとまった？（笑
って、なんで、記事に対してキレてるんだ？自分。

いやぁ・・・最近、やほーでもなんでも記事のレベルが酷くないですか？

昨日見たWoｒld IPV6 Day の記事なんて酷かった。
アレなら書かないほうがマシ。

ま、おかげでうちの記事が検索されまくりましたが。ありがとうｗ

って、このワード書いたらここも検索されてしまう・・・orz

そのうちの記事は、こちらです。

も一個ついでに言うと、VS_LightSwitch β2がリリースされていました。
ISO で600ちょい。

VS2010のSP1が必要なようですので、私はXPモード側にいれることになりますね・・。

そうそう。
1G → 2G にしたんですが結構快調にWin7が動くようになりました。
VSはドローの問題があるのだと思いますが、まだ重い気がします。

ま、頭悪いんだけどね。

追記します。＠同日。

なんか面白い技術情報ですね。
http://msdn.microsoft.com/ja-jp/library/55yzhfb2(v=vs.80).aspx

今サラダと思うんですが・・・。
そこまでしてOOPで行く必要はあるの？VB6。（おい

コレクションにしろ、ジェネリクにしろいいよ・・別に。（← とかいって、仕事で自作したバカ。

自分のスキルレベルの低さに久々に反吐が出ました。
勉強します。はい。

さらに余談ですが、睡眠日誌のマクロの話。
内部でフォーム作成しちゃうってのもあったけど、処理時間でいくことにします。
（つまり、全メールをごっそりと処理対象・・。）

なぜって？
誰でも使えるマクロって事は・・・そう、配布はテキスト文字で手順をコチラで説明しかないわけで・・。
VBSにして外部から操作ってのもありかな・・・。
え？Excel使えるからそっちから？

あ・・・そっか。(なんで独り言・・・。