Office2007

この間セミナーというか説明会に行ってきたんだが、Officeも2007になってかなり「使ってみたい」ソリューションになっているなぁ、という感じがする。

特に今までは単品単品での使い方しか考えていなかったんだけど、今回はShareServerやFormsServerなど連携して使ってみたくなるんだよねぇ。個人的には承認ワークフロー周りの機能を用意してくれている部分かな。

とりあえずベータ２で試してみる事にしようかと思ってみた。

ReportViewerもうちょっと

WinFormでReportViewerコントロール利用してプレビューを表示していて気づいたんだけど、プレビュー画面が表示されただけでは、物理ページ数でページコントロールが更新されていないのよねぇ。

手作業でページスクロールかページ指定するとはじめて更新されるのよ。ＰＤＦエクスポートというもう少しなんだよねぇ。まぁＰＤＦ周りは独自で拡張できるみたいだけど、ページだけは継承して拡張しようとか、インターフェースも用意されていないとかでいかんともしがたいのよ。

WebForm版は問題ないくせになぁ・・・。

VB6の頃に比べて思うこと

継承できるってなんてスバラシイ！、というのが一番思うトコだろうか。ＶＢ６でなんちゃってＯＯＰ形式なプログラムを作っていた身としては、普通に継承できるっていうことだけでもかなり感動なんだよねぇ。

でも、ＯＯＰなやり方を見たこともやったことない人にしてみると、これがそうでもない。まぁ、自分も体感するまでに数年かかっているから気持ちは分かる。

でも「そんなレベルで社内標準とかを語る」のはやめてくれ。マジで。おいらが何も言っていないのは、それでいいと思っている訳じゃなくて、「あなたに理解してもらうのが面倒だから」なんだよ・・・。

割り切り

今回のシステムでは帳票関係としてエクセルへの出力が必須となっていたり。まぁ理由も簡単で、レイアウトの微調整などが発生しやすいから、なんだよねぇ。そこのお客さんでは、今まで利用していたシステムではプレビューがなかったり（！）、外部出力がｃｓｖだけだったりしていたそうなので、独自にエクセルシートを作成してデータ貼り付けて色々ドキュメントを作っていたそうだ。

ま、こういうふうにシステムのデータを加工してやってくれる風土があるってのが個人的には嬉しいんだよねぇ。システムを上手に活用する方法を考えてくれるから。なもんで、今まで自分が関わったシステムではできるだけ、データとして出力できるような仕組みはシステムとして用意していたんだよね。利用されるシーンはまだそんな多くはないのが難点だけど・・・。

んでもってさすがに帳票ツール決めていないのは問題なので、もう自分の中では決めてしまうことにした。今回はエクセルとReportViewerの２本で行こうかな、と。
費用云々な話もあるけど、ReportViewerってその後の展開を考えたときにも、結構他ベンダーの製品より有利にはたらきそうなポイントがあったりするのでねぇ。自分の中ではActiveReportよりも色々いけそうな気がしてならないしなぁ。

まぁ、腹を決めた以上はやいところ今回の仕事用ライブラリ作っていかないとねぇ。ReportViewerは用意してあるけど、エクセル関連って何もやってないから結構急がないとね・・・。しかしそうなると今回のOffice2007で大きい変更がないことを祈るよ。

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の既存案件を同時にこなしているけど、案の定というか時間が足りない。いや、自分の割り振りがうまくないってのが大きいんだけどね。

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

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

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