C#におけるrubberband(ラバーバンド)

C#におけるrubberband(ラバーバンド)ですが、ControlPaintを使用したり、他の方法を試したりと色々とサンプルを作成しては作り直しをしましたが、解決策が見つかりました。

方法は、以下のコードになります。

private Graphics Layer;

private void DrawRubberBand(Point sp, Point ep)
{
Layer = pictureBox1.CreateGraphics();
Pen p = new Pen(Color.Blue);
pictureBox1.Refresh();
Layer.DrawLine(p, sp.X, sp.Y, ep.X, ep.Y);
Layer.Dispose();
p.Dispose();
}

private void pictureBox1_Paint(object sender, PaintEventArgs e)
{
Graphics g = e.Graphics;
//背景に描いているものを描画する処理
}

こうすると、線を描いたり消したりすることができるので、Excelの線やボックスを描画するようなものを作成することができます。

javaプログラミング：第2日目

今日は、アプレットの作成を行いました。非常に簡単なアプリケーションで、Threadを使用して、文字が右から左へ移動するプログラムを作成しました。

サンプルプログラムが常に再描画をしていたので、画面がちらつくので、ダブル・バッファリングを使用して、画面がちらつかないようにしました。

これだけだとちょっと面白くないので、3日目は、RSSを利用して、ニュースのタイトルを表示するようにしていきます。
イメージは、新幹線の中で流れているニュースのようなものを作成していきます。

目的が共有されないと難しい

ソフトウェア開発に限ったことではありませんが、プロジェクト活動において、目的が共有されないとプロジェクト活動を円滑に進めることはできません。
目的が共有されないということは、そのゴールが人それぞれがバラバラになってしまい、そのプロジェクトはどこに向って進んでいるのかがわからなくなってしまいます。

今日もある案件のテスト計画を立てるために、コンプライアンスを読んでいて、疑問に感じたことや対応がどのようになっているかを確認すると、ある人は対応しなくてもよいというし、ある人に聞けば対応しなくてはならないというように人それぞれで発言が変わってきます。

それって、要件定義の段階で決まっているのではないのかと思ったら誰とも合意をしていないということが発覚しました。

ちょっとかなり厳しい状況であることが、実際に自分が現場に入ってみてわかりました。
やはり、プロジェクト活動において目的を共有し、ゴールを決めて全員が同じ方向を向いていくようにしなくては厳しいなと思いました。
TOC理論ですと、ODSCといいます。

Java勉強：1日目

Javaの勉強を始めて1日目になります。
まずは、Javaの型やクラスの作成方法などの文法的なものを中心に勉強しています。
最近、C++やC#を扱っていたため、文法的なものはスムーズに扱うことができました。

ちょっと違うのが継承の仕方と、インターフェースを利用する場合の宣言が違うだけで、後は問題なく進めることができました。

1点だけわからないが、FrameにsetForegroundColorを設定しているのに、起動時のみ背景が透けてしまうのが、どうしてもわからない部分です。
サンプルプログラムどおりに作成してもどうしても動かないので、どうしてこのサンプルは正常に動作しているのかが非常に疑問です。

とりあえず、1日目は終了したので、次回は、Appletの作成にうつります。

久しぶりのプール

今日、数年ぶりにプールに行きました。
久しぶりにいった感想として、プールって意外と疲れるなと思いました。

子供用のところで、子供と一緒に遊んだり、流れるプールを一緒に泳いだりしただけですが、結構疲れますね。
水深が浅いので、歩いているだけなのに、足にかなり疲れが溜まりました。
だからスポーツ選手などがリハビリなどに使用するのだということがよくわかりました。

子供だけでなく、私も楽しむことができました。それはウォータースライダーがあり、そこで一人で滑ることができたからです。ちなみに2回も滑ってしまいました。周りに大人はあまりいなく、小学生くらいの子が殆んど中、それに滑っていたのは私くらいでした。

新しいデジカメを購入

先日、夏季休暇中に私がデジカメを落としてしまい、電源のON/OFF部分が壊れてしまったので、新しいデジカメを本日購入しました。

購入したのは、RICOHのデジカメで、CaplioR6になります。
このクラスのスペックの中では、コストパフォーマンスが一番いいかなと思い、購入しました。
人気もあり、最近は価格.comでも値段が上がってきていました。
事前に下調べをしていったので、わりとすぐに決めることができました。

購入金額も価格.comの最安値よりも安く購入できたのでよかったです。

これから実際に使用してみないと、どうかはわかりませんが、子供を撮影しながら写真をとる練習をしていきます。

.NETFrameWorkは有効か？

最近、C#の勉強をしていてラバーバンドの描画がうまくいかずに苦労して、ControlPaintのDrawReversibleLineの中身がどのように実装されているかを、Reflectorを使用して、逆コンパイルをしてみたところ、結局は、Win32APIのSetROP2をコールしていることがわかりました。

WindowsVistaの時にも.NETFrameWorkだけになるという話がありましたが、互換性などの問題からそれが実現しなかったのだと思います。

Win32APIでできて、.NETFrameWorkでできないことは結局Win32APIをコールするのだなとわかったら、.NETFrameWorkで良くなった部分もありますが、結局はWin32APIで動作するのだなと思いました。

小さな単位での確認が重要

ソフトウェアを開発するのはやはり小さな単位での確認が必要です。

例えば、テスト駆動開発もそうですし、仕様書・テストケースのレビューを行うときなどがに小さな単位で確認を行うと、その分集中してその部分をチェックできるので、重要であると思います。

人というのは、どうしても大きな単位で、チェックしようとすると、心理的に「こんなに多くのことを確認しなくてはならない」となってしまいます。まして、それが、他の仕事を抱えながらだと、余計にそのような心理が働いてしまい、本人はしっかりとチェックしているつもりでも抜けがでたりしてしまいます。そうなると、重要な箇所を見落としたりしてしまうので、非常に危険な状態になってしまいます。

やはり何事もそうですが、小さな単位で確認を行えば、抜けや漏れといったリスクというのは多少軽減されることになるので、小さな単位での確認というのが重要になってきます。

ただし、注意しなくてはならないことが、小さな単位での確認の後には全体的に不整合がないかなども必要になってきます。
木を見て、森を見ずの状態にならないようにすることも最終的には必要になってきます。

Eclipseの日本語がうまくいかない

たいした問題ではありませんが、EclipseのEurope版をダウンロードして、MergeDocで日本語化しようとしましたが、どうもうまくいきません。
-cleanで設定を初期化しても、メニューが英語のままで表示されてしまいます。

最近、どうもこのようなソフトをダウンロードしてインストールしたときに色々と設定がうまくいかないことがあります。

実際に自分で色々と経験してみるとわかることがあるので、ちょっとトラブルが起きたほうが自分を成長することができるのかなとかなりポジティブシンキングで捉えています。

色々と調べてみましたが、ちょっとわからないので、明日も日本語化に向けてチャレンジしていきます。

ダブル・バッファリング

どうしても複雑な描画処理や重たい処理をしていると、画面のサイズを変更しただけで、画面がちらついたりすることがあります。

そんなときに便利なのが、ダブル・バッファリング機能を利用すると、画面のちらつきを防止することができます。

ダブル・バッファリング機能とは、まず最初にメモリバッファにいったんすべての描画を行い、それが終了したら画面上に表示するものになります。

ゲームプログラミングなどではよく使用されるものになります。