XML Formatter

現在帳票系のソリューションとして評価中。元々自分の中ではＸＭＬを主体としてシステムを構築してみたいという気持ちがあったので、できれば導入したいと考えてはいるんだけど。Ｃ／Ｓ系システムで効果的に利用するには、どうしてやればいいかねぇ。

最も効果的に利用できるのはｗｅｂ系なんだろうけど、今回のお仕事はＣＳなのでそういった選択はナシなのよ。

自分として最も望ましいのはこんなソリューション。

・帳票デザインの為にかける時間が少なくてすむ（直感的にデザインできる）
・用紙に対する制御が豊富（ストックホームや伝票系も楽にデザインできる）
・プレビュー画面などはこちら側で継承することによってカスタマイズが可能

後は変更に対して強いとかもあるけど、これは帳票側というよりはシステム側だろうしねぇ。ちなみにXMLFormatterを評価していて、一番どうしようかと考えているのは、ＰＤＦありきな点かな。なんとかイメージデータとしてＣＳ間でやりとりできないものかなぁ。詳しく見ていないからなんとも言えないけど、今の知識だとＰＤＦ生成→ローカルコピー→Reader起動という流れになりそう。なんつーか、しっくりこない。予算的に余裕があれば、クライアントすべてにFormatter導入とかでいいんだろうけどねぇ。それもなんだかなぁ。そんな環境構築を面倒にすることはやりたくないしね。今回はシステムメニューをClickOnceで配布してそれ以外はメニュー内部で更新制御を行うつもりだから出来るだけ楽をしたいのよねぇ。

将来のためにもどうにか使ってみたいんだけど・・・もう少し時間が欲しいね。

DataGridView・・・

今さらになってDataGridViewを利用したエントリ系を調査中。以前のDataGridに比べると確かにデフォルトでの表現力などは向上しているので凄いと思う。

でも「もう少し」なんだよな・・・。

Textのセルなのに、TextBoxと違う実装がされていたり「なんで？」という部分も色々あったりする（まぁそういった所は自分で拡張しなさい、って事なんだろうけど ←事実そうしました）。技術者としては色々手を加えることができそうなので面白いのはあるね。でも他の人に使って貰うとなると、ちょっと微妙。
中小企業の開発で使うコンポーネントとなると、おそらくはグレープシティ社とかそういったところから色々出ているコンポーネントを素直に利用するのが多いと思う。
ただ最初の開発案件によってはサードパーティ製品を利用するってのは難しいところもあるねぇ。受注額として７桁とかだと恐らくは次の案件にて購入する、とか今回の案件の開発費用として計上するのは難しいだろうしね。まぁそういった縛りがあるからMSのReportViewerとかをみつけることが出来たってのはあるけど。

なので個人的にはしばらくDataGridView周りを色々と調査して、サードパーティに頼らない開発基盤を用意できるようになりたいもんだ、と思いますわ。

進んだり進まなかったり

社内で独自に進めていた.Net用フレームワークもある程度の形になってきたので、今月に入ってからは一緒に仕事している人にメンテナンスと更新系を何本か作成してみてもらった。

更新系は俺がきれいさっぱりと忘れていた、IDataReaderをオープン中にはそのConnectionからSQLは実行できないという罠に引っかかっていたので、急遽DataSetを利用したループ構造が作れるように変更。メンテナンスだとそんなロジック作らないから、モノの見事に忘れていたんだよねぇ（最初はTransaction関連が原因だと勘違いしてたくらい）。

でも実際にメンテナンスを作ってもらって今日のところ、１本２時間未満で用意できるようになってくれたんだよね、これが。心底嬉しかったねぇ、目指していた方向が間違っていないってのが見えたもんで。別の都合があって３層構造にするのは断念したけど、今回のフレームワークに慣れてもらえば、次の開発案件あたりでは３層構造も導入できるかもしれないな・・・。とりあえず目標の一つである、実装量を減らして品質の高いＡＰ作成ができるってのは実現できそうだなぁ。

それとスケルトンをフレームワークと言っている人たちへはこっちで用意した仕組みではなく、ロジックゴリゴリなサンプルを渡してやったりした（ｗ
俺の気持ちとしては、「とりあえず頭抱えて苦しんでこい。話はそれからだ」というところなんでＯｏな設計とそうでない設計の違いをそのうち見せてやる！、とある意味間違った方向に熱意を傾け中（ｗ

次の課題はやっぱり帳票・・・。いまだにツールが選定できませぬ。
(;´Д`)y─┛~~

ＧＷ中

カレンダー通りの休みを満喫しているんだけど、休み明けからどないしましょう、ってのが今の悩み所。連休前の時点で、データクラス周りにDIコンポーネント的な要素を持たせてみようとやっていたんだけど、果たしてこれがどれくらい実装やその後の保守に影響をあたえるか、ってのがあまり読めてない。

依存性をＡＰでなく外部に保存しておけるってのが、保守性においては有効なのは分かるんだけど、実装効率としてはどうなんだろうなぁ、ってところ。自分一人でやっている分にはかなりの効率UPにつながるんだけどねぇ（ｗ

ある意味Vistaから利用できるXAMLも、UI要素という依存性を外部へ切り分ける手法だからねぇ。これからはこういったやり方がメジャーになるとは思うんだけど・・・。Javaで言うSpringFrameworkってどこまで一般的になっているのかな？

面倒くさいなぁ・・・

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

社内の雰囲気としてはおおむね.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を利用する、ってとこがわかればそれなりのシステムやパッケージなら開発ソフト費はほぼフリーで抑えられそう。

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