Windows UX ガイドライン

Windows7対応版ということで提供されていた。

Windows ユーザー エクスペリエンス ガイドライン

で、ローカルで読みたかったのでPDF版をDLしてみたんだけど、どうやらた一部ハイパーリンクが間違っている模様。

http://hiroyuk1/～といったアドレスになっているんだよなぁｗ
きっとこれはレアだな！ｗ

GUIのデザイン作業

設計上どうしてもやることの一つがコレ。
そして今回はものすごくこのジャンルで苦しんでいるわけですがｗ
ネックになるのが「VisualStudioでデザインするのが一番楽」と思えてしまうこと。
個人的にはVisualStudioでデザインするってのは、どちらかというと最後の手段というか時間的都合でというか、とにかくそういう面が大きいと思っているんだよね。
要は「誰でも楽に使えるデザインツールがない」というところ。
そんなことを思っている時に見つかったのがコレ、FireFoxのアドインPencil。

ぱっとみは何かのツールに見えるんだけど、実はこいつがFireFox3のアドオンだというｗｗ
「Pencil」というプラグインなので使ってみたい人は、FireFox3をインストールしてこのプラグインもインストールするといいかも。

フリーのＥＲ図作成ツール

仕事でデータベースやら色々触る身分なので、どうしてもＥＲ図というのは書く場面が多々あるんだけど、
有償製品ならともかくとして無償となるとなかなかよいツールがないのもこの分野なんだよね。

現在はDBDesigner4をメインで利用しているんだけど、さすがに開発が止まっている現状(有志がDBDesingerForkとして引き継いではいるけど）なので、使いやすいツールがないものかと探してはいるんだよね。今のところ候補に挙がっているのは次のものくらいかな？

MySql Workbench
A5:SqlMk2

まーEclipse＋CｌayプラグインとかAmaterasERDとかそっち方面もいろいろあるんだけどねー。
見た目がね・・・ｗ（同じ理由でA5：SqlMk2もねぇ）

いやね、見た目よりも内容が重要なのはわかってるんですよ。でも最初に出会ったのがDBDesigner4だったもんで、それなりに見た目も欲しいんですよ。ということで現在の期待はMySqlWorkbench。こいつはDBDesignerの開発メンバーが作成しているし、.Netアプリだしと、DBDesignerのファイル取り込めるし、見栄えもいいしといいことずくめ（ｗ）なので、そのうちこれを使うようにしてみようかなぁ。

そのうち、というのには理由があって。

日本語周りで色々と不具合が多く、今のバージョン（5.0.23）ではデメリットの方が大きいから。

んー、一番の解決策は自前で作ることなんだけど、時間と腕がないからなぁ・・・。

.Net Framework4.0とVisualStudio2010

どうやら来月あたり行われるTechED2008ではこのあたりのネタも話されるみたいで。ちくしょう、横浜じゃなかったら是非行きたいってんだけどねぇ。
まだまだ詳しい話は全然流れてこないんだけど一つ流れてきたのはAsp.Net系の話。

T2-402：ASP.NET MVC Framework 概説 ～ .NET Web アプリケーション開発のパラレル ワールド!? ～

Asp.NetではFramework4.0でMVCモデルのフレームワークが追加されるんだってねぇ。
んー、個人的にはアプリケーションのアーキテクチャとかそっち系の話題としてMVCモデルを捕らえているんで、ベースとなる.NetFrameworkに搭載されるってのはなんというか微妙なところ。
実際には設計モデルによっては「実装しにくい」とかはあるからいいことだとは思うけどね。
来月あたりから色々話が流れてくるだろうから要チェックかな。

SqlServer2008の新機能

ちょろちょろっとPASSJ（SqlServerのコミュニティ）がINETAJ Day 2008というイベントでプレゼンした内容のスライドを見ているんだけど、なかなか2008になって追加されている面白い機能ってのがあるねぇ。まだまだ見ている途中なんだけど、次の2点は今すぐにでも欲しい！

・複数行INSERT
INSERT INTO T1 VALUES (1, 'A'),(2,'B'),(3,'C');
なんて書き方が可能に！大量データ生成の際はレスポンスを一気にあげれるかも。

・MERGEステートメント
詳しい書き方やレスポンスがわからないんだけど、「データが存在する際はUPDATE、存在しない際はINSERT」というのをやってくれるそうで。今まではロジック判断だったのが、SQLステートメントでできるってのは楽だねぇ。

・変更追跡
簡単に言うとレコードレベルの変更を追跡できる仕組み。今までだったらトリガとか使って履歴情報作っていたようなことが、SqlServerの機能として提供されるとな。

これだけでも結構嬉しい機能強化かも・・・。実際には暗号化の話やデジタル証明書の話とかもっとあるみたいなんだけどね。自分たちの仕事にもろ影響がでそうなのは、まずこのあたりかな？

画面デザインの重要性

ERPはフロントシステムから見直せ！－ ＠IT情報マネジメント
元ネタはERPの話として言われているんだけど、ものすごく重要なことだったので。

『アマゾン・ドットコムやアップルのiTunes Storeの使い方を、皆さんは誰から教えてもらいましたか。研修を受けて使えるようになったのでしょうか。そんなわけはありませんね。こうしたシステムは初めから誰にでも使えるように、直感的で分かりやすい操作性を兼ね備えているのです。これからの業務システムもこうしたシステムと同様に、直感的で操作性に優れているべきです。操作が複雑で研修が長時間必要になるシステムは、すでに時代遅れになりつつあります』

これはSalesForce.comという企業のCTOな人が講演で話した内容。
個人的にはまさしくその通り！というところで、業務システムだから教育しないといけないとかそういうのは思い込みであって、本当なら少数の時間教育するくらいで使えるようになっていないといけないだよねぇ。

ただこれを踏まえたデザインというのは、ものすごく難度が高く専門性も高いんだよなぁ・・・。だからデザインだけで一分野築けるくらいなんだし、専門の本とか雑誌とか色々売っているくらいだもんね。たまーに読むけど、元々センスがない人間なのでなかなか身につかないｗ

継続して努力せんといけませんなぁ・・・。

MultiRow Ver5.0

今日付けのプレスリリースで発表された、「MultiRow for WindowsForm」。

えーと、Ver4を利用しようとして断念した経緯を持つこちらとしては「なんだとこのやろう」的な感じですがｗ

内容を見てみるとさすがに、Ver4と互換性はありません！と普通に言って来るほどだから、内部的にがっつりと構造から何から何まで変更したんだなぁ・・・というのがよくわかる。
ExpressEditionに厳しくなったのも仕方ないんだ、とはわかる。デザイン用アプリ用意していないからExpressEditionの時は、自前でロジック組めよ、というのもわかる。
しかしなんというか微妙な気持ちだ・・・。

GrapeCityはVer4のMultiRowは黒歴史として封印でもしようとしてるのかねぇｗ

SilverlightでWinForm

GOA - System.Windows.Forms for Microsoft Silverlight and Adobe Flash

なんというか今日はこういう見てくれの話題に驚きっぱなし。
SilverlightやFlashでWinFormを再現しようということを、この会社（？）が実現しちゃったんだよなぁ。
正直なところ、これをみるとAsp.Netでふつーに作った画面がさみしくてしょーがないくらい。マシンパワーが潤沢になっている今、冗談抜きでこういうUIを要求されるのが多くなるだろうなぁ。

今までは「ブラウザだから・・・」といって回避できたことが、それも通用しなくなるんだろうね。

だって、できてしまっているんだから。

Health COMMON USER INTERFACE -MS CUI-

元ネタ：Microsoft Health Common User Interface - Home

CodePlexにて始まっているUIのデザインインターフェースに関してのプロジェクトで、Silverlight2を利用してこんなこともできる、というデモサイトが作られていたんだよね。

ざっと眺めてみて・・・発想力の違いに驚かされる。
めちゃくちゃなほどの大量の情報をうまいこと視覚的にまとめているんだよねぇ・・・。
こういうセンスが今ものすごくほしいんだけどｗ
Silverlight2は1.0と違って.Net系言語から操作することが可能だからなぁ・・・。
できるようにはなっておくべきだねぇ。

オブジェクト指向への壁

なにかにつけて「３年はかかる」と言っている、オブジェクト指向へ考え方を変えるということ。これは冗談でも誇大広告でもなくて、実際の体験談として言っているんだよね。

「仕事上の経験とかがあればもう少し短くなるんじゃないか？」と思われそうだけど、ここに限ってはまったくもって逆。経験があればあるだけ障害が多く時間がかかるんだよねぇ。

最初の１～２年は暗中模索というか「何がメリットなのかわからない」という状態が続くんだけど、それを超えたあたりで、急に「あー、こういうことか」とひらめいてしまうんだよなぁ。ここをクリアしているかどうかは、クラスを使った設計ができるかどうかで見分けられると思う。

実際自分の場合、VB4（古い・・・）時代に一度クラスに取り組んだんだけどまったくくもって意味もメリットもわからなかったのでそこで一度断念してるんだよね。その後、ちょっとした縁で関わったとある案件で、大分叩き込まれたんだけどその時ですらメリットはわからなかった。
でもその案件から離れて、全然違う業種のところへ出向していた時に。
何故か閃いたんだよねぇｗ
確かにこれは考えやすい、って。

システムを考えるときに「データ」をベースにした考え方でいる限り、オブジェクト指向には中々たどり着けないと思う。事実データをベースにする考え方はデータ指向ということで、開発工学上も分けているしね。相性が悪いんだ、データ指向とオブジェクト指向は。

自分はデータベースの設計においてはデータ指向で、システムを設計する時はオブジェクト指向でと切り替えて使うように心がけているんだけど、まだまだうまいこといってないってのが本音かな。
プログラムというところでは、ちゃんと考えないとクラス指向というちょっと違った道にいってしまいやすいので気をつけないとねぇ

ＥＲ図作成ツールで

A5:SQL Mk-2 - フリーのSQL開発ツール/ER図ツール

フリーのＥＲ図作成ツールは常に色々探していて、このあいだ日経ソフトウェアで紹介されていたので試してみた。
ツールとしての機能はかなり豊富だねぇ。ＥＲ図作成ツールというよりも、データベースに関連する作業を一通りできるツールスイートってところかな？
トランザクションをコマンドでなくツールボタンで開始終了できるってのは何気に便利。Oracleだと普通がそういう感覚（コマンドでCOMMIT切らないと適用されない）んだけど、SqlServerは暗黙的トランザクション（指定しない場合はコマンドの開始終了でトランザクションをCOMMITさせる）だからたくさんの処理をやるときにはちょっと疲れるんだよね。

自分が今回の案件で利用しているDbDesignerだと論理名が入力できないので、他人に見せるときに結構文句がでるんだけど、こいつはそのあたりもカバーしてくれてる。

ただちょっとだけまだ使いづらいのがあって、テーブル数がそれほどない小規模な開発だといいんだけど、ある程度以上を超えるとこのソフトで扱えるＥＲ図領域ではちょっと手狭なんだよね。それと見てくれはやっぱりDbDesignerの方がキレイ。

しかしこういったツールってDelphi製が結構多いねぇ・・・。やっぱりHack的な人はそっちが多いんだろうなぁ。

データが「ある」ということ

データベース屋さんとしては正規化を行って適切な粒度で細分化されたテーブル構造を正とするのが、嫌な言葉だけど「一般的」なんだよね。
もちろんここにはちゃんとした理由もある。

一つは「異常データを排除する」というため。もう一つは「レスポンス向上」のため。

データの排除についてはそれほど異論はないと思うんだけど、恐らくはもう一つの「レスポンス向上」についてが、変に思うところだと思う。
SqlServerも含めて殆どのRDB系DBMSはインデックスの構築の仕方がレスポンスに直結してくるんだよね。インデックスを利用できないような抽出条件（部分一致検索とか、値がNullという条件とか）をなくすことが、そのままレスポンス向上につながるので、システムの動作速度の大半は実はここで決まってしまうんだよね。

そしてインデックスというのは、参照するのは早いけど更新するのは遅い、という性質を持っているんだ。簡単に言うとSELECTするのは早いけどINSERTやUPDATEは遅い、というところで。

ここで最初の話に戻るけど、なぜ正規化したほうがレスポンスの向上が見込めるかと言うとこの条件指定に関連してくるわけだ。
WHEREが適切に動くようなインデックスを構築する場合だと、参照はそれで済んだとしても更新の際には主キー＋インデックスの更新も必要になる。でも正規化して「データが存在すること」が条件になるようにできていれば、殆どはクラスタインデックス（主キー）の更新だけで済むようになるということなんだよね。以前に１つのテーブルに10以上のインデックスを構築したテーブルに対しての更新処理を行ったことがあるんだけど、それはもうなんじゃこりゃ的なトロさだったね（ｗ
インデックスはずして更新するとエライ速度が変わるという。
なのでインデックスでどうこうするのではなく、テーブルにデータが存在することで条件指定を兼ねるよう正規化して設計することが後々で重要なんですなぁ。

OOとAO

これだけしか書いていないと、なにがなんだか（ｗ
ＯＯ（Object Oriented）はオブジェクト指向で、ＡＯ（Aspect Oriented）はアスペクト指向の略。

今現在のフレームワークのようにオブジェクト指向（的な）で設計・開発を行っていると、どうしても面倒なというか、あまりスッキリしない部分というのが色々とでてくるんだよね。

それは「どこでもやるような共通的な処理」。

オブジェクト指向は名前の通りオブジェクト（＝物）を基本とした考え方なので、売上伝票とか契約書とか、そういった実際の物をベースとした設計になるんだよね。今回もデータクラスのまとめ方はこの発想になっている・・・つもり（ｗ
でもそのオブジェクトの中では、ログへの出力とかトランザクションの制御とか、どこでも必ずやるような共通的な処理というのも出てくるわけで、こいつが思想の上ではなかなかに相性が悪かったりするわけだ。というのもそういった共通的な処理というのは、そのオブジェクトが本来するべき振る舞いとは異なるから、なんだよね。

そこでそういった本来の振る舞いは本来のクラスで、それ以外の処理は別のクラスで分けて管理したほうがスッキリとして扱いやすくなるんじゃないのか？、というのがアスペクト指向。

.NetFrameWorkとしてはそういった思想は持っていないので、言語レベルやフレームワークとしてのサポートはないけれど、属性を利用してそれとほぼ変わらないことは実現できるんだよね。そのあたりをもうちょっと手を入れて使いやすくしたのが、Spring.NetとかS2Container.Net（Seaser2）とか、そういった有志の手によって製作されているフレームワークだったりするわけだ。

AO自体はDI（Dependency Injection：依存性の注入）と一緒に語られることが多いね。DI自体は今回の手法だと、DataComponentクラスとか定義ファイルからのデシリアライズとかで行っているのよ。あとはコレをうまいこと扱えれば・・・。

自前でそういったことをやろうとすると、でてくる壁はカスタム属性とかにたどり着くんだよね。んー、あると確実に楽なのはわかっているから何年かかけてとりこむべきだなぁ・・・。

ライブラリ屋さんとして

元ネタ：ディベロッパー製品開発統括部 Blog : 開発者共通の悩み？Yomi-Autocompletion の動作に関して

いやぁ、よくわかるわこの悩みが・・・。
案件に依存したものしか作っていない場合には、絶対にたどり着かないこの悩み（ｗ

汎用性と専門性とのバランスというのは、常に悩みどころなんだよね。
極端な話、案件依存したヤツは社内で統一的に使うライブラリにはなるわけがないし（ｗ

いや、声を大にして言えないけど。

オブジェクト初期化子

VB9から利用できるようになったというオブジェクト初期化子。
こいつを使うとクラスをNewする際にプロパティを指定して初期化できるってヤツで。

Dim cust As Customer = New Customer() With { .Name ="libaty" }

これ、今からでも欲しい！コイツが使えると、引数つきコンストラクタ作らないで済む！
ライブラリ屋としては今すぐにでも欲しい機能だ！

O/Rマッピングツール

【VB.NET開発コンポーネント・O/Rマッピングツール】ObjectService

リレーショナルデータベースの設計をキッチリやった場合には、多かれ少なかれクラスとの間で存在理由とか色々な点で違いが発生する（インピーダンスミスマッチ）ので、設計上でマッピングを行って関連付けをする工程が必要になるんだよね。

これはそもそもの設計手法としての問題（データ指向なRDBとオブジェクト指向との差異）なので解決するには、データベースをooDB（cacheとか）へ変更しオブジェクトをそのままデータベースに永続化できるようにしてしまうか、「何かを行って相互間で橋渡しをする」しかないんだよね。

でもって自分はooDBはあまりわかっていない（ｗ）ので、マッピングを行う方向でしか設計できないわけなんだけど、その際の負荷を減らしてくれそうな製品がこれ。
Javaとかだと既にHibernateとかiBatisとか色々とフレームワークが整っているんだけど、.Netではまだまだ少ないのが実態。NHibernateとかS2Da0.NetとかiBatis.NetとかJavaで利用されているフレームワークの移植版が殆どかな。

そんな中で見つけたのがコイツだったんだけど、こいつはVisualStudioの環境にマージしてくれるので他のツールに比べると使いやすさはかなりいいね。後は実際の実行速度とかがどんなもんかとか、今回みたいな複雑なテーブル設計した際にどうなるかとかだけど、さすがに今はそこまで試せない・・・。

ただ今後はこういったツールは絶対必要だと思っているんだよね。
そのための布石というかなんというか、社内用ライブラリのDataComponentクラスはそれ自体を永続化する機能というのは持たせているし、定義を外部から取得するインターフェースも用意している。このあたりは、もう少しS2DaoとかSpringとか研究して、同等機能は持たせたいんだよねぇ・・・。
ただ「自分以外に使うか？」と言われると・・・ｗ

ＡＰの配布を考慮した場合

ClickOnceとかWindowsInstallerとかで配布することを考えると、どうしても今の案件のようなファイル構成というのはあまり相性がよくない。良くないというか発想が間違っている（ｗ

今みたいに画面単位＝Exeファイルという構成がどう考えてもマズイ。
そうなると基本的にシステムとしてはExeファイルは一つで、画面単位はDllファイル一つ（もしくは複数を合併）させた形でないと、Vista以降の環境においてはどうやっても問題が出てくるなぁ。

「インストール時に制限すればいいんじゃね？」

という考えもあることはあるけど、それはシステムを提供する側としては問題アリだと考えるんだよなぁ。完全にこっちの都合だし。
アプリケーション（またはソリューション）を「どこにインストールするか」は、そのクライアントＰＣの利用者が決めることであって、開発者が決めることじゃないのがあるべき形だと思う。

というか、自宅ＰＣとかで考えてもらえば、普通のソフトはそうなっているじゃないの？なんでそれを業務用だからといってルールを変えようとするんだろうね。どっちもWindows上で動くソフトなんだけどなぁ。

売上～請求～入金と、発注～支払～出金

今現在請求周りの再設計・・・。
そこで今まで考えてはいたけれど、ということを改めて見直してみた。それは「請求の裏返しが支払」という事。まぁ販売管理やっている人だと、結構こういう事言うのはあるね。

でも、それを実際にやってみたことはないんだよな。
絶対にデータのストレージ先は分けて設計しているんだよな。

ということで、頭の回路をフルフルに動かして考えてみた。結果、多分いけそうだね、という形までは思いつけたのよ。大元の考え方は次のような感じで。

ある科目なり項目に対して、金額（売掛または買掛）が発生するその金額に対して回収または支払の予定をたてる予定に対して金種（現金や振込み）の移動が発生する

こういう観点から見れば、売上～入金も発注～出金も同一のフレームワークで定義できるんだよね。
ついでなんでよく言われそうな点についても考えてみた。

（１）売掛と買掛を同一テーブルにすると見づらいし、メンテのときに面倒
ビューを利用すれ。本来はテーブルを直接触るほうが変。つか「見づらい」という観点でＤＢ設計するな。

（２）売掛と買掛は意味合いが違うんだから、別テーブルじゃないとおかしいのでは？
情報を定義する際の視点の違い。どちらでも意味がちゃんと通るので、「こうじゃないとおかしい」のは成り立たない。どちらでもいい、が正解。

・・・まぁこんなところかと。ああ、なんかグチっぽいなぁｗ

自動採番

昨日、自動採番周りを再設計していた際に思い出した。
別の案件で同じように自動採番の仕組みを構築していたんだけど、排他制御まわりで上手くいかなかったんだよね。
で、そこで単純なことを忘れていたのに気づいたわけで。

「大きなトランザクション中だから、自動採番近辺でトランザクション終了してもロックが外れるワケがない」

・・・あたりまえだわなｗ
ということで今回はくだらないミスをしないためにも、自動採番周りは別セッション開いてやることにしようかと。ついでに、コネクションブールを考慮して、トランザクション終了時に自動で接続切るようにしてしまおうかな。

昔と違ってコネクションの接続解放のコストって大分なくなってるからねぇ。ＡＰ単位でコネクション維持しておく必要がなくなってるもんな。

SmartUIアンチパターン

[ 技術講座 ] Domain-Driven Designのエッセンス 第2回から。

Smart UI（利口なUI）アンチパターン

層状アーキテクチャの対極をなすアンチパターン。ビジネスロジックやデータアクセスのコードが、UIのコードと一緒になってしまっている、いわばスパゲッティな状態。利口なUIと呼ぶのは、ビジネスロジックを含むすべての処理がUIの中で行なわれるから。最もやっつけで手軽なやり方がこれなので、設計を何も考ないとこの状態に陥ってしまう。開発チームのスキルが低くて、かついわゆる第4世代（4GL）と呼ばれるようなグラフィカルな開発ツールを最大限に利用する場合は、このパターンの採用にも一理ある。しかし、利口なUIを採用してしまうとMDDが一切機能しなくなるので、DDDは諦めるしかない。

いやはや全く。あまり強くは言えないけれどなー。
目標とするのはこういうところじゃないと、どこかでせっぱつまるっす。というか、つまったｗ