MVCの利点

MVCの利点については、以前にもこのブログで書きました。
その他にも、MVCを採用すると、WEBアプリ等では、よくあることですが、デザインをAさん、内部をBさんのように分けて平行で開発することができます。

これは、WEBアプリだけではなく、WindowsアプリでもMVCを採用すれば、多重化することができ、Viewを専門で作成する人、Modelを専門で作成する人と分けて開発することができ、納期を短縮することができます。

その他にも同期処理なども簡単にできることがあります。

ModelとViewがきっちりと分かれていないと、どうしてもできないことなので、アーキテクチャの基本はMVCだなと感じます。

C#におけるGrid

C#において、表入力機能を実現しようとしたときに、Excelのようにしたい場合に、標準で用意されているDataGridViewでは、どうしても機能が足りなくなってしまいます。
そこで、オープンソースのGridで、CodeProject上にあるSourceGridがあります。

ダウンロードしてサンプルを動かしてみました。Excelライクな感じで動作してくれるので、私が実現したいことができそうです。

Cellの設定も自分で設定して、Rows.Insert()や、ColumeHeaderメソッドをコールすると、ソートをしてくれたり、ソートしたくない場合には、Headerメソッドをコールしてあげれば問題なくできます。セルの結合もできるし、割と多くのことができます。

まだ、調べている部分で、セルにデータを代入して別のセルに移ったときにイベントがどうしてもわからないので、現在調査中です。
SourceGridが簡単に使用できると、Gridを使用するアプリではかなり重宝されると思います。

C#で画面を動的に貼り付ける方法

C#で、画面を動的に貼り付ける方法が見当たりません。
MDIではなく、Panelがある位置に別のFormを貼り付ける場合の方法です。

Delphiだと、Form1上のPanelにForm2を貼り付ける場合には、

Form1側では、
Form2 := TForm2.Create(Panel1)
Form2.BorderStyle := bsNone;
Form2.Align := alClient;
Form2.Visible := true;

Form2側では、Form2のOnCreate内で、
Self.Parent := TWinControl(Self.Owner)

と記述します。

同様の方法をC#で試してみたら、画面がParent上に配置されません。

C#では、動的ではありませんが、UserControlを使用して、貼り付ける方法は見つかりました。

ネット上でも検索しましたが、あまりいい情報がありませんでした。

山梨名物：ほうとう

今週の日曜日に、河口湖に行って来ました。
近くに山梨名物のほうとうのお店があったので、名物を食べなくてはと妻と話してほうとうを食べました。

私は、豚肉ほうとうを食べ、妻はカボチャほうとうを食べました。息子は、私達の分を少し取り分けてあげました。

ありえないなという話があります。
ほうとうには、必ずカボチャが入っております。
妻のカボチャほうとうよりも、私の中に入っていたカボチャの数も大きさもたくさんありました。
なんで、カボチャほうとうなのに他のほうとうの方がカボチャの数が多いのだろうと、大分食べ始めたときに気がつきました。

ある程度食べてしまったので、文句が言えない状態でしたが、おいしいものを食べれたので、3人で満足して帰ってきました。

これからも美味しいものを食べに、どこかに行きたいと思います。

近くに、バッティングセンターがあったので、久しぶりにストラックアウトを試してみたところ、最終的には6枚でした。
最初4枚連続で落としたので、パーフェクトになると思っていましたが、欲が出てしまいだめでした。

意外なところでバグは発生する

あるサンプルプログラムを作成していて、描画する位置が思い通りの位置に表示されないことがありました。
原因をたどっていけば、至極簡単なことでしたが、描画領域を取得する箇所が間違っていたことがありました。

こんな単純なことでもバグは発生します。今回のは単純なミスです。

今回のように、バグというのは、思っていた箇所とはまったく違う箇所で発生することがよくあります。

例えば、画面を貼り付けるときに、同一のメモリを見ているときに、微妙なタイミングの問題でアドレス違反が発生したりなどです。

こんなことがあるので、バグフィックスをするのは難しいなと思います。

アイコンがあるとやはり違う

画面イメージや簡単な操作性を伝えるために、プロトタイプを作成することがあります。

画面イメージを伝えるときに、ボタンなどにアイコンがある画面とない画面では、どうしても差が出てきて、アイコンがあると派手に見えたりしてかっこよく見えたりします。
アイコンがないとどうしても地味な印象をもたれてしまうので、操作感を伝えるために作成しても動作を検証してくれなくなる可能性があります。

アイコンのあるなしで違ってくるので、アイコンに力を入れることで、製品が売れたり売れなかったりを左右するくらいに重要なものであるなと最近になって分かってきました。

場面に応じた対策がある

障害があったときに、テストのところでなんとか発見しようとするのは私は間違いであると思います。
なぜなら、テストではバグを発見することが目的ですが、ただ障害の根本原因がテストにあるのならテストのプロセスややり方を変更する必要がありますが、そうでない、設計や要件定義の段階などであれば、そこを変える必要があります。
そういったことを考えないで、テストで見つければいいやと根本の心理状態にあると、どうしてもコードが読みにくくなったり、手を抜くことが発生してしまいます。
達人プログラマーの割れ窓理論になってしまいます。

そうならないようにするためにも、テストで何とかしようではなく、コードを書いているその場からテストしたり、定義を十分に検討するなどその場に応じた対策が必要であると思います。

C#のListとDelphiのList

C#を最近、使用していて感じることはListの使用が簡単だなと思います。

例えば、整数型(int)をListで保持しようとした場合には、

C#の場合には、List<int>intlistと宣言すれば使用できます。
C++の場合も同様に、std:list<int>intlistと宣言すれば使用できます。

しかし、Delphiの場合には、IntList=class(TObjectList)とクラスを作成して、そこに色々なメソッドを用意しなくてはなりません。

そこから使用する場合には、C#やC++と同様に宣言をして使用します。

このように、言語一つとっても実装の方法が異なってきます。
基本的には、コードの量が少ないほうが生産性は向上しますし、バグも少なくなります。

本当にこんな基本的なことからですが、開発言語を選択するときには、注意をしなくてはならないなと思います。

アコードについて

アコードが納車されて、数週間がたち、ある程度運転にも慣れてきました。

そこでもうすぐ1ヶ月点検になるので、ちょっとした感想です。
まず、足回りですが、特に問題ないと思います。よく曲がるし、そんなに気になる点はありません。
乗り心地ですが、以前乗っていたレガシーに比べるといいです。
前の車はタイヤの厚みがなかったので、道路のわだちをもろに受けましたが、今はまったくそのようなことがありません。

ただ1点気になるのが、CVTを採用しているので、ちょっとした坂道でＡＴなのにミッションの車のように下がります。これだけがちょっとした難点です。

ただその他の部分は気に入っているので、割と楽しんで通勤や遊びに行っています。

テストケース作成時の疑問

テストケースをどのように作成したら効率的なものが作成できるか日々勉強しているときに、色々な書籍を読んだりしているといつも疑問に感じることがあります。

例えば、入力Editがあるときに、仮に最大入力文字数が半角で50文字まで入力できるものがあったとします。
そうしたときの最大入力文字数の確認として、半角で50文字・51文字、全角で25文字、全角で26文字といったことをあげている場合があります。
仮に、Windowsアプリを作成したときに、これらの半角・全角といった場合わけが必要かといわれると、私は必要ないのではないかと思います。
なぜなら、これは使用する言語にもよると思いますが、使用する言語のコンポーネント側で制御しているからです。変な実装で、キーの入力をしている場合を除いてですが...

単純な例でありますが、これらを考えると本当に必要なテストケースというのはなんだろうという疑問が湧いてきます。

境界値分析の例としてはこれらを抽出するのはいいと思います。

まだまだ勉強不足なので、いつも戸惑いながらテストケースを作成しています。

こんな疑問を持つ人は少ないと思いますが、私はいつも疑問に感じていることです。