2006年12月24日日曜日

インテリセンス

今の開発ではなくてはならないIDEにおけるインテリセンス。

今回もこれを利用してコーディングミスを減らすよう色々やってみてるんだけど、いまいち判っていない箇所があったり。

それはインテリセンスに表示される順番の事で、何を条件に最初に表示されるのかが全く判ってない。属性のあたりを一通り見たけども、それらしいのはなかったし。ここが、属性によって表示される順番が制御できたりすると、かなり有り難いんだよねぇ。

#引数の数が多いものが後にくるのは普通だと思ってる。
#気にしているのが引数の数は同じ場合

xmlドキュメントを眺めてみてもいまいち判らないんだよなぁ。VSのアドインな世界になるのか、カスタム属性な世界になるのか・・・?

2006年12月16日土曜日

データクラス

今回のお仕事ではデータクラスを用意して取得、更新、削除などは全てそれ以降のクラスでまかなうようにしているんだけど。

汎用的な仕組みなため、クラスの属性をプロパティではなくFieldsコレクションというプロパティを通してアクセスするように設計しているんだよねぇ。んでもってここが、一番バグが発生しやすい箇所になっていたり(項目名を文字として引き渡すため)。

それの打開策として考えたのが、列挙型定数を用意してアクセスする方法。おかげでタイプミスは減ってコンパイルの時点でミスがわかるようにはなった。でも、似たような問題が他でもあって、検索画面や印刷指示画面などでも同じような仕組みを使っているんだよねぇ。それでもって、ここでは「共通」としているせいもあって、データクラスの際に利用した列挙型定数は利用できないんだよな。

このあたり、なんとかできる仕組みってないのかねぇ。デザインパターンのあたりをもう少し調べてみると、なんかあるのかなぁ。

2006年11月26日日曜日

コンボボックスのダブルクリック

色々調べてようやっとコンボボックスのダブルクリックを拾えるように。

実はダブルクリックについては、PC上の設定さえ拾っていれば問題なくできるとはつかんでいたのでそう難しい話ではなかったんだよね。んじゃあ、なんで今まで実装しなかったか、というと。

アンマネージドな方法しか知らなかったから

せっかく.NetFrameWorkなんだからできるかぎりマネージドな方法で行きたいと思っていたからで、最近になってようやっと資料が見つかったのよ。おかげでなんとかダブルクリックのイベントを拾うことが・・・というよりダブルクリックされたと判断することができるようになったんだよね。

しかしSystemInformationクラス周りはmsdnくらいしか情報なかったのって、結構厳しいねぇ。そのうち色々なサイトで出てくるとは思うけど。

2006年11月15日水曜日

DataGridViewを久々

気がつくとDataGridViewでKeyDownイベントを利用してEnterキーをトラップするロジックが動作していなかった。

まぁ理由は簡単でProcess~系のメソッドをオーバーライドして、Enter押下で次のセルまたはコントロールへ移動するように手を入れていたからなんだけど。今回はProcessDataGridViewKeyメソッドのオーバーライドにて対応しているんだけど、この中で意図的にKeyDownイベントを発生させようとすると「派生したクラスから継承元のイベントを発生させることはできません」というエラー。

あらそうですか、ということでなんとか対応してみたけど、こういう時ってOnKeyDownメソッドをコールするのが正解なんだろうかねぇ・・・。どうにもOn系統のメソッドっていまいちつかみにくい。

2006年11月13日月曜日

後継者

この仕事を続けるほどに思うんだけど、後を継いでくれる人材ってのがとても不足しているんだよねぇ。システムの仕様、という点ではあまり心配してないというか、それはドキュメントしっかり残せば済む話だけど。

テクニカル的な点というか、ドキュメントで引き継げない点がやっぱり悩みだな。こればっかりはとにかく時間をかけるしかない、ってのが今の自分の考え方なんだけど、会社としてはそこまで重要視してないってのが問題でねぇ・・・。

そうやってきた結果、今のように中堅層がごっそりといない状態なんだけどなぁ。

2006年11月7日火曜日

にょろかっこ

今日はWPFのセミナーを受けてきたんだが、その中でも微妙なヒットした言葉がこれ。「 {} のことなんですが私はこう呼んでいます」って、いいのかそれで(w

なんというか中括弧という言葉は実は一般的じゃないのか、と逆に不安になったよ。どうにもネガティブな気持ちが続いていた中で、ちょっとした清涼剤というか。

2006年10月28日土曜日

技術者として

ここ最近色々なことで頭を使っているけど、結構大きいウエイトを持っているのはこの話題。簡単に言えば、これから先に自分が目指す方向な話なんだけど・・・。

同僚にはPGである程度やった後にSEになりたい、という人間が多い。実際自分も以前はそんな感じだったし。でも、今はSEにはあまりなりたいと思っていないのよねぇ。正直SEよりもアーキテクターな方向が自分にとってベストかなぁ、と思うし。

ただ、現状として北海道ではそんな職種は大手にしかないね。それと中小な環境だとPGが育ってSEになるという、ある意味幻想がまだまだ根強い。自分は他の人に教えているときに、必ず「PGとSEは別の職業だし異なる知識がいる」と説明している。プログラムが書けたからといって、システムの設計ができると思うのがつじつまが合わないんだけどねぇ・・・。

PGとして経験を積んでSEっぽく働くことが出来るとしたら、それは今まで上についていた人のコピーとしてSEっぽくできるだけ。厳しい言い方だけど、それほどはずれてはいない(ハズ)。特にここ最近ではかけていい時間が少なくなっているから、経験よりも体系だった知識がまずは必要だと思う。そうでなければ、結局はSEっぽい人間が量産されてしまうだけだよなぁ・・・と。

だからこそあえて、自分としてはSEではなくアーキテクタな道を目指したい。

2006年10月19日木曜日

キャッシュ機能

わけあってデータクラスにキャッシュ機能を実装することに。

というのも、色々考えた結果更新制御を行う場合、それぞれのAPに実装してもらうよりもデータクラス側で実装してあげれば、保守性においていいんじゃないかな、って理由なんだけど・・・。

結構自爆してるかも知れない。

ちょっと早めにテストしないとマズイかもなぁ。

2006年10月14日土曜日

ダメ押し

やはりElTabelle。試行錯誤していた結果、レイアウトとして作成するテンプレートクラスでは、Objectとして受け渡すことが出来たとしてもその情報を保持しているとは限らなかったのが判明・・・。実際はテンプレートだけでなく、全体的になんだけど。

個人的な意見なんだけど、Objectとして渡された物を勝手に変換するのはどうよ?、と思っているのよね。コンボボックスにaddしたものと、Itemsから拾ってきた物が違っていたら結構困ると思うんだけどなぁ・・・。レスポンスとかの問題なんだろうけど。

結局テンプレ情報から自前で保持領域を確保しないといけない事に。んー、テンプレとセルの書式が異なる場合は結構おてあげかも知れない。汎用的なのを諦めて、デザインに制限つけるしかないかな?

2006年10月11日水曜日

ElTabelle・・・んーむ

なんですかコイツのコンボボックスと拡張コンボボックスは。

ヘルプにある「通常のコンボボックスと同様に利用できます」って全然違うじゃないデスカ!

感覚的にはVB6までのコンボボックスなんだよなぁ、これ。.Netに移ってようやっとAddするのはクラスのインスタンス、ってところに慣れ親しんだのに。

いや、だからってダメじゃないし気持ちは分かるんだが(w

今回はそのあたりのコーディングも統一しようとしてるからねぇ・・・。ちょっと苦労しそうな予感。

2006年10月6日金曜日

あれれ?

ElTabelle続行中。

今日の問題はOnEnterをオーバーライドして独自イベントを発生させた際に、BaseGridライブラリ(ElTabelleのライブラリ)でぬるぽが発生してしまっていた。なにか悪い事をやっているからとは思うんだけど、いかんせんなにが悪さしているかがさっぱりおっかけれない。Exception見ても全然情報載ってないんだよねぇ・・・。
まぁ、来週中にどうにかしないとなぁ。

それともう一つ困っているのが、ComboBoxコントロールでどうやったらDoubleClickをイベントとして拾えるか、だな。ComboBoxコントロール自体はDoubleClickイベントは発生しないものなんだけど、色々事情があって今回は拾いたいのよね。どこかでメッセージが捨てられているのかな、とおもってWndProcを調べてみたけどメッセージ自体届いていなかった。このあたり知識が足りないから、なぜ届かないのかが全然判ってない。

しかしComboBoxってMouseDoubleClickイベントもあるんだけど、こいつはどうやったら発生するんだろう・・・?

2006年10月3日火曜日

またElTabbleか!

ElTabbleのラッパークラスと格闘中。しかしなんというか、調べれば調べるだけ、自分と肌が合わないコントロールなことで・・・。なんというか、「そのまま使うことを前提としてます」というコントロールだからなんだろうけどねぇ・・・。

とりあえず、DragDropでの行並び替えと、コンテキストメニューからの行削除は実装して、共通イベント制御へと流すところまではOKになったから、実用には耐えられるんだけどね。

あとはキー制御と色周り・・・色はあたりをつけてあるからいいけど、問題はキー制御だなぁ。

2006年9月30日土曜日

データクラスなんだけど

よく見ている@ITでの掲示板の一つ。

RDBアプリケーションのためのパターン(http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=33879&forum=7&9)

ORマッピングは汎用的な設計パターンな話題では外すべきかなぁ、と思っているんだよねぇ。これってリレーションというかエンティティをオブジェクトに変換する際の違いというか、そこら辺を吸収するための手段であって、設計パターンじゃないよなぁ・・・なんて。自分の理解が間違っている様な気もする。

かといって、今自分でやっている方式も全然ベストではないしねぇ。

2006年9月26日火曜日

ElTabbleちょっとだけ

ラッパークラス作成のため、イベント周りを調査してもらっていたり。
(ちょっと同僚と新人にそれぞれ別系統のイベント調査をお願いしてみた)

新人にはなんちゅーか、説明がうまく伝わらなかったので自分の方でアタリをつけてみたんだけど、DataGridViewやっていた後だからか、ElTabbleってイベント制御がちょっとヒ微妙な感じ。

別にダメって事じゃないけど、EnteredCellやらEnterEditやらセル周りのイベント発生させて置いて、その状態から別コントロールへフォーカスを移すと、LeaveEdit→LeaveとLeaveCell発生しないってのがなんというか変な感じ。

まぁ、触っていると「カレントセルが移動していない」のが判ったので、LeaveCellが発生していないのは理解できたんだけど・・・なんか納得いかないんだよねぇ。

いや、ダメじゃないんだけど。

2006年9月24日日曜日

EnterをTabに・・・

業務系のアプリで必ずと言っていいほど出てくるこの話。そのため、色々なサイトでこれに対するロジックが公表されているんだけど。

SelectNextControlメソッドでは対応できないケースの方が多いんだけど、それでもどうしてそういったサンプルが多いんだろう。理由も簡単で、DataGridViewやその他グリッドなコントロールが絡むとほぼ間違いなく、Enterで次のセルへ移動してほしい、という話もでるだろうから。

だから業務としてはProcessDialogKeyとかそのあたりのメソッドをオーバーライドするのが最もいいのだろうけど・・・利用するコントロールによっては、コントロール側で制御を行う必要があるんだよねぇ(DataGridViewもそう)。

Form側で統一したロジックにしようとすると、こういった問題がでるので各種コントロール側でキー制御を行う、というのが今のところ最もスマートな方法かもしれないね。

2006年9月21日木曜日

次なる強敵

DataGridViewは少しずつだけど対応が進んできた。でも次に控えているヤツがなにげに難しい・・・。

んーTabControlのイベントトラップをやろうとしたんだけど、こいつってIDEでイベントがでてこない。なんか嫌な雰囲気だなぁ、と思っていたらTabControlに関連するTabPage側で結構制御が必要な構造になっていたのねぇ・・・。

んー、まともにやろうとするとCodeDomあたりも研究しないといけなさそうで時間かかりそうだなぁ。

2006年9月16日土曜日

再々度DataGridView

今になってDataGridViewの仕様とぶつかる問題が発覚。うーん、今のところBindingSource関係はほとんど使わないようにしてきたんだけど、これがアダになったのかなぁ・・・という感じ。

問題の発端はActiveControlが変更された際に、イベントを発生させようとしていた事なんだよなぁ。この瞬間をトラップしようとすると、どうしても各コントロールのEnterとLeaveイベントを利用した制御になるんだよなぁ。ところが、DataGridViewは仕様上Enter関連とLeave関連のイベントでは色々と出来ないことが発生してしまう・・・。

んー、今のところ望みとなるのはGotFocus関連なんだが・・・。設定によっては、GotFocusは結構後になってからしか発生しないのが判っているから、非常に手詰まり。

もう一つ考えているのは、DataGridViewRowCollectionクラスあたりに手をいれて、EnterまたはLeaveイベントの最中はキューイングするだけにして・・・と考えたりもするんだけど、そこまでやらないとダメ?

2006年9月11日月曜日

製品版が到着

ようやっとVS2005Pro版とElTabbleの製品版が到着。

今の今までExpressEditionにて無償環境まっしぐらな開発を行っていたんだけどようやく普通に開発ができるのよ。普通にセットアップも作れるのよ(もしかしたらWix使うかも、と考えていたからなぁ・・・ClickOnceではちょっと面倒が多くて)

あー一番嬉しいと思うのは、「新しい項目の追加」で利用できる項目が一気に増えたことかな。これだけで結構嬉しい。

さて、ElTabbleをラップする共通クラス作らないとね。

2006年8月16日水曜日

DataGridView再び

同僚に出した仕様でDataGridViewを利用したメンテナンスAPがあったりした。何しろ仕様を出した自分が、DataGridViewについてそれほどよく分かっていなかったものだから、やってもらうにつれ色々分かること分かること。

とりあえずコンボボックスは今のところ使わない方向で・・・継承したクラス用意するのがちょっと面倒なんで。編集中とそうでない時とで、結構制御が変わってしまうのがなぁ・・・。まぁそれようにメソッド用意したりしたのでとりあえずは何とかなってるっぽい。

ちゅーかもう少しひらめきがあれば、ElTabbleやXtraGridに近づけるような気がするんだけどなぁ・・・。

2006年8月10日木曜日

GIGA-BYTEとASUS

なんか互いに出資した会社を興すことになっているらしい。どっちも有名なパーツメーカなのに、考えてみるととんでもなくすごい話だよなぁ、これって。

そのうちパーツ業界にも統廃合の波がくるのかねぇ・・・ATIが買収ってな話みたいに。

2006年8月2日水曜日

需要はあるかな

色々と試したおかげで、開発ツールに費用をかけることをできるだけ避けた状態で、システム作成できる見通しはたったんだけど、ここらへんのノウハウは需要があるんだろうか?まぁ、極端に言ってしまえば、SharpDevelop2使え、で終わるんだが(w

一応ExpressEditionをベースにした、といえば仕事で開発するとこでも利用はしやすいと思うんだがねぇ。レポートはReportViewer、インストーラはClickOnceかWix。データベースはSqlServerExpressEdition。考えてみると、これでも十分に仕事できるんだよなぁ。エントリさえ考えつけば

2006年7月30日日曜日

使えない

現在某G社のスプレッドっぽいものを色々と触っているんだけど、その直前に洋モノのXtraGridを触っていたせいもあって、機能不足が露骨に感じるのよねぇ。純日本産、というのは聞こえはいいんだけど・・・。正直XtraGridに日本語ドキュメントがあれば、間違いなくそっち使うなぁ。

自分も人のことは言えないが、言語の壁ってのは結構大きいもんだと思う。

2006年7月22日土曜日

新たな悩みどころ

紆余曲折あって、伝票形式コントロールは某G社のコントロールに決まった。最後まで争っていたのは、海外物ながらXtraGrid。はっきり言って、機能的にも強力なのとコンポーネントのソース付き(すべてC#で作成したコンポーネントだからこんな芸当ができるんだよなぁ)というのが、個人的にはものすごく魅力だったのよねぇ。

まぁ、ネックとなったのは日本語の資料がないこと。会社としてはこれはきっついんだよな。自分一人、または同じチームだけと考えるとXtraGridで行けるんだけど、その他の人を考えるとね・・・。

しかし今の悩みは別で、今月で新人教育は一段落させなければならないんだが、来月は今自分たちがやっている案件で使って行かなくてはならないのよ。正直、新人に出せる仕事はまだない・・・まだ画面設計してユーザーと打ち合わせしている段階だぞ?何を出せると言うのかっっっ。こういうときはどうすればいいのかなぁ・・・誰か知恵を求む。

2006年7月17日月曜日

伝票形式のコントロール

挫折中・・・。まとまった時間(1ヶ月ほど?)がとれれば、勢いで作ってしまいたいところなんだよなぁ。できるかどうかは非常に微妙だけどねぇ。

正直、今の某G社のコンポーネントはできるかぎり避けたい。某ARは多分利用しないでも何とかなりそう、というかする。でもネックは伝票形式のUIなんだよねぇ。これだけはかなりユーザー側の希望も高い場面が多々あるんだよなぁ。
そこで一時期はDataGridViewをベースになんとか作成できんのか?と色々試してはみたけれど、「セルベースのコンポーネント」である以上、どっかで面倒な問題が発生するんだよねぇ。セルベースで、うまいこと伝票形式を実現しようと考えたら、RowTemplateの内部で更にRowとColumnを所持する形式、簡単に言うとグループ情報かな?、を持てるようにしてしまえばなんとかセルベースでも実現できるんじゃないのかなぁ、とは考えているんだけど・・・。そこまで拡張する腕がないのが泣き所。

色々と調べる時間が欲しい今日この頃。データベースの設計もやらなければならないのは分かってるんだけど・・・。いやぁ、真面目に影分身でもコピーロボットでも何でもいいから欲しいなぁ(w

2006年7月14日金曜日

ReportViewer一区切り

個人的にしばらく悩んでいたReportViewerを利用しての印刷が何とか解決したっぽい。プレビューとプレビューからの印刷は問題がなかったので、確実に印刷メソッド周りで実装がミスっているんだなぁ、と思って調査していたんだよねぇ。

分かってみればやっぱり簡単な話で。

PageSettings.PaperSizeプロパティ以下の各プロパティを設定しても、実際の印刷については影響がないってのが原因だったのよねぇ。しかしPaperSize.Heightとかも不思議な動きで、変更できないならReadOnlyにしてしまうか、例外でも発生させてくれればいいのに・・・と思ってみたりしたけど、結局は自分が動作を理解していなかったという事なんだよな。

まぁとりあえず一つはOK。次は数値入力関係かな・・・厳密にキー制御しようとすると、結構面倒なんだなぁ。

2006年7月8日土曜日

インターフェースのデザインって

今週に入ってGUI周りのデザインを開始。しっかし元々苦手分野ということもあって、ものすごく悩みまくり。なんちゅーか、「使いやすいデザイン」というのがみじんも思い浮かばなかったりする。

正直オフコン時代の思想をそのまま使ってもいいとは思うんだが、今回のお客さんは多分そういう「今までと変わらないもの」というのが気に入らないタイプなんだよなぁ。

極端でも「キーボードを使わない」デザインってのを考えてみるかなぁ・・・。

2006年7月1日土曜日

データクラスのフレームワーク

HibernateとかSpringとか色々なデータ周りのフレームワークを参考にしつつ、自分なりのフレームワークを改良し続けているわけだけど、ここのところかなり停滞気味。

なんというかテーブル間のJOINをどう扱おうかってところで現在混乱中。VB6時代に作っていたのは、SQL文を生成するだけなクラスだったからオブジェクトの属性なんて何も考えなくて済んでいたのよね。テーブル間のリレーションが属性として設定できるようにしていただけで。
んでも、今回はデータクラスとして、というのがスタートラインだったから「リレーションを考える前にある程度形にしてしまった」のよ。今にして思えばこれがマズかった。これだとO/Rマッピングが大変な事になってしまうんだよねぇ。

Ado.netだとテーブルリレーション関連のクラスが色々あるみたいだから、そっちも構造を参考にしてみようかな・・・

2006年6月25日日曜日

Office2007

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

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

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

2006年6月21日水曜日

ReportViewerもうちょっと

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

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

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

2006年6月15日木曜日

VB6の頃に比べて思うこと

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

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

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

2006年6月11日日曜日

割り切り

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

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

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

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

2006年6月4日日曜日

XML Formatter

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

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

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

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

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

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

2006年5月27日土曜日

DataGridView・・・

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

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

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

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

2006年5月23日火曜日

進んだり進まなかったり

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

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

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

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

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

2006年5月5日金曜日

GW中

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

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

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

2006年4月23日日曜日

面倒くさいなぁ・・・

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

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

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

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

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

データベースの正規化もできない。ADも組めない。XMLも使えない。OOも(少しだけでも)理解していない。年数だけ重ねたいい例だよ。

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

2006年4月15日土曜日

やっぱり時間が足りない

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

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

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

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

2006年3月22日水曜日

仕事でVB6

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

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

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

2006年3月19日日曜日

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

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

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

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

2006年3月2日木曜日

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

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

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

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

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

2006年2月23日木曜日

自分の中では路線変更

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

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

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

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

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

2006年2月22日水曜日

路線変更?

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

2006年2月21日火曜日

サンプル見つけたのとXML

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

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

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

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

2006年2月20日月曜日

帳票と伝票

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

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

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

ActiveReport待ちだな・・・。

2006年2月7日火曜日

一人頭ひねる

相変わらず 仕事2:ライブラリ8、な毎日。

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

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

2006年1月26日木曜日

ライブラリ状況

気がつくとある程度形になってきていた。現状ではこんな感じ。

・Ado.Net管理
接続形態を問わない利用が可能。Accessライクなクラスも用意。

・ログ管理
Log4Netを目標に作成。実行時の出力設定は設定クラスのシリアル化

・共通インターフェース
共通イベントとデコレータによるイベント処理クラスの指定

ログ管理はもう少しで形になりそう。実行時に設定をどう扱おうというところが悩んでいたけど、最近オブジェクトの永続化を勉強していてようやくそこに落ち着いた。なんつーか、まだまだ知らない事が多いのを実感。

2006年1月16日月曜日

鯖がとんだ

といっても会社でのお話。メインで開発に使っているサーバーがすこーんと飛んでしまって、セーフモードでもリブートしまくる状態に。

2003になって結構安定していたので再インストールのやり方をすっかり忘れてた・・・(OEM物なんで普通とはちょっと違う)

結局今日一日はこれで終了。疲れた・・・。