プログラミングを簡単にする

プログラムをすべて一から作成するのは骨が折れるものだ。
処理の幹になる部分と枝葉の部分を一気に考えると、どうしてもバランスの悪いプログラムになりがちである。

よくやるのが、「共通部分を部品として作り上げる」ことだ。その上で幹の部分を作っていけば結構バランスのよいプログラムができる。
もっといいのは、共通部品をある程度揃えておいてそれを再利用する方法。ただ、すべてがすべて可能な訳ではない。

モジュールとしては
・プロジェクトごとの処理の流れ
・プロジェクトごとに必要な共通部品
・少しカスタマイズすれば汎用的に使えそうな共通部品
・カスタマイズせずとも汎用的に使えそうな共通部品
くらいに分けられそうである。
これを、それぞれ分けて揃えていく方が効率がいいだろう。

Javaなどでは結構フレームワークとして揃えてあるようだが、VBAでは量も少ない。
・少しカスタマイズすれば汎用的に使えそうな共通部品
　→ツールで生成可能とする。
・カスタマイズせずとも汎用的に使えそうな共通部品
　→出来合いのモノを提供する。

ということを考えている。

年金特別便来たる

私にも年金特別便が届いた。

公務員を経て、会社員になり、現在個人事業主だ。その公務員分がすっぽり抜けていた。しかし、しばらく前に公務員時代の共済組合から手紙が届いて（どうやって住所を調べたのだろう？）、それを転記して送り返すことにする。

しかしながら、通常の転職でも漏れるなんて、かなりお粗末だったんだなあ、と思う。

DSNを利用しない方が利便性が高い

データベースへの接続の際には、ODBCドライバに接続情報を与えてDSN（データソースネーム）として登録して利用する場合と、DSN情報に依らずに利用する場合とがある。

プログラムからのデータベースへの接続方法はいろいろある。最近、OLEDBを使ったADO接続について、実務でも必要だったため調べたが、接続方法の種類は多い。その中でも、ODBC／DNSを使った接続方法は歴史が古い。

この中でもDNSを使う／使わない、という観点でいえば、経験上DSNを使わない方が利便性が高かった。クライアント側にDSNの設定が要らないからだ。

どちらの方法でも、データベースの接続先を変える際、プログラムを入れ替える、環境ファイルを書き換える等の方法で可能であるので差異はない。
しかし、接続するデータベースが変更になったり追加されたりした場合に、クライアント側のDSNに設定が必要か否か、という手間の差が出てくる。この手間の差が違う。

DSNの情報はレジストリに書かれている。レジストリに追加するのはいい。しかし
・DSNの登録情報を手で入力するなら手間がかかるうえ、接続情報がバレバレである。
・コマンドでDNS情報をレジストリに書き込む場合、テキストを開けばやはり接続情報はバレバレである。ただし、経験上設定がうまくいく場合と走でない場合がある・・。
・ばれないようにプログラムを配布するのも、手間である。
設定が要らなければそういうことを考えなくてよい。

多くのクライアントからサーバーアクセスが必要な場合は、上記も考慮に入れるとよいだろう。
ただし、当たり前の話であるが、クライアントから直接データベースにアクセスしないもの、クライアントからはリクエストのみでデータベースへのアクセスがサーバー側に閉じている場合は、この限りではない。