面倒くさいなぁ・・・

週末に今の会社の上期会議があったわけで、その場で各個人の上期目標などを色々発表していたんだが。

社内の雰囲気としてはおおむね.Netに進むという考えが浸透していたのが分かったのは良かった。これまで２年くらいかけて、今までと異なる設計思想やらフレームワークやらなんやらを言い続けてきた甲斐があったってもんだ。
ただ厄介な人物はあいかわらず厄介で。

「今までＶＢ６で利用してきたフレームワーク（実際はただのスケルトンなんだけど）を.Netに移植したりして、.Netに移行するかどうかを判断しようと思う」などと言う始末。

思わず言いたくなった。
「あなたにはそこまでできません。」
「ジャマだから.Netの開発に関わってこないでくれ」と。

資格試験を色々とうけて資格を取得しているのはえらいと思う。ただ、資格の悪いところが思い切り現れているんだよなぁ。「知識があることを示してはいるが、能力をあることを示してはいない」という点が。正直、この人は資格をたくさんもってはいるが、所詮それだけだなぁ、というのが自分からみた感想だな。全然レベルが低い。社内しか世界を知らないから、ものすごく見識が狭い（あまり人のことを言えた義理でもないのは承知でな）。
そして悪いことに今の社内に、自分と同レベルかそれ以上の見識をもった人間は開発にいないので、自分以外誰もその人に意見を言わないことだ。

データベースの正規化もできない。ＡＤも組めない。ＸＭＬも使えない。ＯＯも（少しだけでも）理解していない。年数だけ重ねたいい例だよ。

この先どこかでまたこの人とやり合う場面が生まれることになるとは思う。それを考えると正直面倒くさいな・・・。「好きにやってくれ、ただし俺には構うな」と言ってしまいたいよ、ホントに。

やっぱり時間が足りない

.Netの教育とVB6の既存案件を同時にこなしているけど、案の定というか時間が足りない。いや、自分の割り振りがうまくないってのが大きいんだけどね。

でも教育については、いまのうちからやっておかないと、後々もっと厳しくなるのは目に見えているので可能な限り時間を用意するようにはしている。会社としては、その点に気がついていないのかあまり賛同されていないのがネックだけどな・・・（単純に自分の仕事こなしてからやれ、という話かもしれないが）

まぁ、何とかこの後輩を自分のレベルに近づくように設計・実装共に色々教えているので数年間かかるという前提だ、ってのも周囲に対するウケは悪いわなぁ。でも、実際問題数ヶ月でＯＯな設計できるようにしろ、なんてムリ。絶対ムリ。ＯＯＰできるようにしろ、ってならまだ可能性はあるけど。設計分野についても出来る限りは教えていくという方針にしているとはいえ、ねぇ。

自分の中に蓄積されている知識と暗黙知をどれくらい伝えることが出来るか・・・。まぁ長い目で見てくれることを周りに望みますわ。

仕事でVB6

ちょっとこの頃は仕事の都合でＶＢ６をまた触っている。まぁ、他社パッケージ関連のカスタマイズだからなんだけどねぇ。

でもVB2005触った後にVB6を触ると、何とも言えない不便さを感じるねぇ。VB6だけやっていたころはまったく気づかなかったけど、VB2005をある程度使っているとその差がものすごく体感できてしまうのよ。結構開発環境は進化していることに改めて感心したねぇ。IntelliSenceとスニペットがなんといっても強力。FF12で言えばミストナックくらい強力だ（ｗ

しかし一番の困りどころは、頭の中で考える構成がすべてクラスを利用したロジックに染まってしまったのでVB6では非常に辛いとこだね・・・。

メール送受信のライブラリ

バーコードはEAN128用の画像作成という形でなんとか作成できたので、現時点ではここまでにした。それでもって最近は仕事８：ライブラリ２な状態に入れ替わってしまったので、VB.Netライブラリは最近触る頻度がへってしまっているのよねぇ。

まぁ少しずつは手をかけているわけだけど、最近主に手をいれているのはメールの送受信周り。業種上EDIが絡みやすいのがあって、どうしても必要になっているワケで。今まではBASP21とかを利用してあれこれやっていたのが多いんだけど、今回は.NetFrameWork側での実装が結構変化していたこともあって、自前で用意しはじめているところ。
ただまだまだ実装度合は進んでいなくて、SMTPS・POP3SとPopBeforeSmtpが絡んだときの挙動がまだまだ実装しきれていない。

つーか、POP3Sな環境でPopBeforeSmtpな人はどれくらいいるんだろうか・・・。それによってはテスト環境用意しないとなぁ。

バーコードってめんどくさい

帳票周りも暫定的にReportViewerコンポーネントを利用したライブラリに落ち着いて、今はバーコード関連などを調査、実装中。

ｉＴｅｘｔ関係を利用すれば作る必要がないのはわかっているんだけど、なんというかやっぱりある程度ライセンスに囚われないライブラリを用意したいモノ。どちらかというと、オープンソースはプログラマー的には賛同できない性質なんでねぇ。まぁＥＡＮ１２８とかの１次元バーコードなら、色々資料も出そろっているからなんとか用意できるとは思う。時間がかかりそうなのはＱＲコードかな・・・。まだ資料に目を通していない。

余談だけど１次元バーコードでコンビニとかで利用されているＥＡＮ１２８だけど、コンビニ（というよりスキャナのメーカー）によって読めたり読めなかったりの差が結構あるんだよねぇ。なんとかならんのかな、これって。

それと最近設計から見直しているのはデータベース周りだな・・・。DataSetを上手に利用すれば変にArrayList使う必要もなさそうだし。ただまぁ、どこまでをサポートするか、という線引きは常に悩んでいるねぇ。変にロジック詰め込んでもあまりいいことないし。

自分の中では路線変更

昨日書いた帳票系での話の前に今日になってようやく気づいた事がひとつ。

ExpressEditionではIDEを拡張するような製品は利用できないということ・・・。つまるところActiveReportとかが使えないのよねぇ。いや、まあ企業で使うんだから普通にVisualStudio購入しなさい、って意見はごもっともですが。

んでもまぁ、中小企業だと案件あって初めてツールを購入できる、なんて事が普通にあるわけで・・・。ウチもご多分にもれずそのクチなもんで、今のところ予算は確保できてませぬ。

そんな状況の中、なんとか見つけたのがReportViewerコントロール。こいつはSqlServerのReportingServiceテクノロジ出身なのと、フリーで利用可能ってのがナイス。性能的にも他の製品と比べても、罫線周りを覗けば遜色ない。詳しいことはSqlServerのページからたどって貰えればわかるかと思う。帳票のデザインにVisualWebDeveloper ExpressEditionを利用する、ってとこがわかればそれなりのシステムやパッケージなら開発ソフト費はほぼフリーで抑えられそう。

とりあえずはこのスタイルで社内用のライブラリを揃えていこうかな・・・。

路線変更？

またまた昨日の今日でアレなんだが帳票系で変わりの手段が見つかったかもしれない。詳しいことは明日出社してから確認してみるけど、グルーピング系帳票と定形伝票が出力できれば本格的に採用するかも・・・。

サンプル見つけたのとXML

昨日の今日でアレなんだが、ＭＳＤＮ２を色々読んでいるとサンプルになりそうなソースってのは見つかった。

予算の都合でActiveReportの数が限定されてしまいそうだったので少しだけ光が見えてきたのかも・・・。

まぁサンプルっても意味がまだまだ理解できないんだけどねぇ。

それとは別にウチは携わっている業種の都合上ＥＤＩの話が多々あったりする。結構パッケージとしても数をさばいているから、ひょっとしたらどこかで見たことがある人もいるかも。
んでもねぇ、ＸＭＬ対応ってのがかなり消極的なのよね。自分の場合は．ＮｅｔになってＸＭＬが（ＶＢ６と比較して）かなり楽に扱えるようになっているのを知っているので、はやいところＸＭＬ対応してしまいたいのよ。ただ地域的な問題と業種的な問題があってなかなかこれが進まない。ユーザー側で使い出してから対応する、じゃ遅いと思うんだけどねぇ。どうなることやら。

帳票と伝票

ライブラリ作成続行中。まぁ来月はそれほど時間をさけないので今のうち、ってとこなんだが。

帳票周りと伝票入力周りが相変わらず手詰まり。というかムリ（ｗ
伝票入力周りだけなら設計構造はなんとか思いついているから出来るかもしれないけど。（もちろんＵＩエディタなんてものは考えない）

帳票は本気でムリっぽい。Documentクラスがわかっていないせいもあるんだけど、あの構造で、今までページ単位の制御に慣れ親しんだ人間が使えるような構成がまったく思いつかないのよ。

ActiveReport待ちだな・・・。

一人頭ひねる

相変わらず 仕事２：ライブラリ８、な毎日。

ある程度形になっているとはいえ、今のところどうにかしないと行けない問題な伝票入力と帳票周りがまったくもって進まない。サードパーティ製品も４月くらいにならなければ出そろわない様子だし。

エディタの事を考えなければ帳票は用意できるんだけどねぇ。ＵＩＥｄｉｔｏｒがまったくもって理解が追いつかない。どっかでサンプルになるようなコンポーネントが見つかればいいんだけどねぇ。