[NEWS] 採用天気予報

●IT業界の求人市場は引き続き活況(元ネタ)

IT業界、といってしまうと幅が広すぎるのですがドカタもSEも基本的にはまだまだ買い相場なので、良い条件があれば転職をするのがよいかもしれません。

本筋とは違いますがアプリ系SEの最後の文章も要注意ですね。
たしかに現在ケータイ系のクライアントさんはどこも（大手さんも）、フィルタリング強化の話で持ちきりです。
各社の公式サイト登録はかなり審査が厳しく、おそらく公式になれないASP系の業者、特に10代をターゲットにしている業者は大打撃です。
逆にF1ターゲットなどの上の世代の顧客を抱えている業者はどこ吹く風、という感じで業務拡大の話を良く聞きます。

[C#] NAnt を使う・・・

NAntを使って

• ビルド→テスト→リリース

の自動化を行いたかったので、社内公開用のメモ書きを作っていました。
無事に設定ファイルも下記、実行されたところで気がつきました。
NAnt、まだVisualStudio2005には対応していません(泣
設定ファイルの書き方を書き終えてから気がつきました・・・。
もうメンテナンス用でしかVS2003以前は使わない予定なのでショック大。

代わり、とはいえないかもしれませんが、MSBuildにextensionをつけることで同等のことができるようなのでそちらの調査を行います。

[Ruby] 擬似変数・真偽値

C++だとbool型があり、true/false はbool型の定数の予約語となっています。
RubyではTrueClass / FalseClassというクラスがあり、true/falseはそれぞれ の唯一のインスタンスという位置づけになります。
C++でも定数扱いですが、Rubyでもインスタンスではありますが、代入不可能な オブジェクトです。

#! /usr/local/bin/ruby
#
#	問題
#	真偽値の表記

print "\n";

print true;
print "\n";

print false;
print "\n";

これ をどこかに保存します。
さくっと実行。

> ruby step02_02.rb

true
false
>

擬似変数はtrue/falseの他にも、

• self
  現在のメソッドの実行主体（？）
• nil
  NilClassの唯一のインスタンス。C++でいうところのNULL。
• __FILE__
  現在のソースファイル名
• __LINE__
  現在のソースファイル中の行番号

があります。

[Ruby] 変数・定数

変数名は 通常の変数の二文字目以降は英数字または '_'から構成されます。
C/C++ と異なるのはインスタンス変数（メンバ変数）、クラス変数、グローバル変数の書式が決まっている点です。

• ローカル変数
  １文字目が小文字または'_'で始まる。
  例:  int index;
• インスタンス変数
  １文字目が'@'で始まる
  例:  int @currentPageNumber;
• クラス変数
  '@@'で始まる
  例:  int @@criticalSection;
• グローバル変数
  １文字目が'$'で始まる
  例:  int $sharedCounter;
  
• 定数
  １文字目が大文字で始まる（通常すべて大文字）
  例:  int MAX_BUFFER_SIZE=256;

[Ruby] 値

まずは atom たる値と変数に関して。

2. リテラル

リテラルは大別すると

• 数値
• 文字列

があります。
ほかにも

• コマンド出力
• ヒアドキュメント
• 正規表現
• 配列
• ハッシュ
• 範囲オブジェクト
• シンボル

などがありますがこれらは追々やっていきましょう。
まずは数値と文字列。

#! /usr/local/bin/ruby
#
#	課題
#	数値と文字列の違いを示してみよう

print "\n";

print 5 + 1;
print "\n";

print "5" + "1";
print "\n";

print '6' + '0';
print "\n";

これをどこかに保存します。
さくっと実行。

> ruby step02_01.rb

6
51
60
>

数値はそのまま1とか5と記述し文字列は「"」「'」でくくります。
文字列の表記方法は C/C++ とは異なるので気をつける必要があります。

[暇な人向け問題]

上記コードを改変して 44 + 33 の結果がわかるようにしてみましょう。

[Ruby] Hello World!(続き)

前回は Shift-JIS で rb ファイルを作成したのですが UTF-8 だとどうなるでしょうか？
前回のファイルを UTF-8 で保存しなおしてみます。
これをどこかに保存します。
そしてコマンドプロンプトを立ち上げ

> ruby step01_01_utf8.rb

を実行します。すると

縺薙ｓ縺ｫ縺｡縺ｯ・∽ｸ也阜縺ｮ逧・＆繧・

>

という感じに文字化け化けで出力されます。
これではなんだかわからないので、出力結果をファイルに保存します。

> ruby step01_01_utf8.rb > res.txt

を実行します。すると生成された res.txt の中身には

こんにちは！世界のみなさん

になっています。きちんと UTF-8 も扱えるようですね。

[Ruby] Hello World!

Railsまでの道のりは遠いですが、リファレンスを参考に順を追って学んでいきます。

1. Hello World

まずはRuby の雰囲気を味わいます。 開発環境はLinuxマシンが手近にないのでWindowsXPに。<< 玄箱は？
こちらからActiveScriptRuby 1.8.4.1をダウンロードしてきます。

#! /usr/local/bin/ruby
#
#	問題
#	Hello World を表示するプログラム
#
#	課題
#	ruby のプログラムの書き方・実行の仕方を覚えましょう

print "\nこんにちは！世界の皆さん\n";

これをどこかに保存します。
そしてコマンドプロンプトを立ち上げ

> ruby step01_01.rb

を実行します。すると

こんにちは！世界の皆さん

>

という感じに出力されます。
なおWindowsのコマンドラインを扱う分には１行目は必要無いです。
Apacheで扱うにしてもWindowsでは拡張子で判断されると思われますので必要ないでしょう。

[暇な人向け問題]

上記コードを改変して「Hello World!」を５回出力するようにしてみましょう。

[C#] ちょこっとだけ変更

半年前に納品したC#のプロダクトの修正依頼がありました。
見積もりでは３日ぐらいかかるかと思ったのですが、設計がうまくできたためコード変更は30分程度でした。
コード変更が短かった理由は設計の良さ以外にもあり、

• データ変換のクラスが単体テスト済みのため気軽に使える
• 修正部分の単体テストのコードが既にあり、修正後、テストコードも少し手を加えただけで動作確認が出来た

変更による影響範囲もリファクタリングが結構なされていたおかげですぐにわかり、見やすいコードはメンテナンスも容易であることが実感できたいい機会でした。

[環境] Borland Developer Studio 2006

●「Borland(R) Developer Studio 2006日本語版」を販売開始

「思惑」さんの過去ログを読んで知った驚愕の事実。
年内には出ないだろうと思っていたBDS。
先月末に販売がすでに開始されていました。
会社には全くアップデートの案内がきていないのですが・・・DelphiもC++Builderもせっせと使っているのになんということでしょうか。
出来はよいのでしょうか？
まあ、BDEはすでに死んでいるので移行するにしてもDB系はかなり書き直しになるのでしょうから、C#でもいいかな～という気もしています。 BDEがWindows2003ServerSP1で１ユーザで複数プロセスから利用できないのには困っているのですが・・・。

[環境] VS2005日本語版リリース

●Visual Studio 2005日本語版が完成，MSDN会員はダウンロード可能に(ITPro)
●MS SQL Server 2005/Visual Studio 2005日本語版開発完了 Expressの提供も(MYCOM)

というわけで期日通りリリースされました、VisualStudio2005が。
個人的に気になるのはTeamEditionだったりします。
会社で使う分には買ってもらえなくはないでしょうが、高いですね。
ただ、機能的にはこれが注目です。
あとはC++/CLIでしょうか。
紹介記事ぐらいしか追いかけていませんがMFCとU/Iでおさらばできるのが一番の利点だと思っています。
ただ、boostが対応されていないのが難点です。

[XP] XP実践入門 - 第10章

(13)第10章 バグを発見し、テストを作成する

　ついにU/Iのバグが出てきました。
これをどのようにテストするのか楽しみでした。
しかし、バグ修正は１行追加するだけのものです。
どのように挙動テストを行うのかと思いきや・・・・(;;
挙動のテストは行わず、Mockを用いてMockにて正常にメソッド呼び出しがおこわなわれることを確認したのみです。
このテストは「あるメソッドが呼ばれている」という確認にはなります（今後の安心感も大でしょう）。 しかし、挙動が正しいかどうかは別物です。
このあたりも手動テストではなく（U/Iを眺めて「あ、うまくうごいた」ではなく）、自動テストできないのでしょうか？
章の最後でも必要性の指摘はあるのですがうやむやになっています。
　Mockに関してはinterfaceを利用するのですが、なかなかおもしろいやり方でした。

public interface ITestTextBox {
	int SelectionStart { get; set; }
}

public TestableTextBox : TextBox, ITestTextBox {
	//	空っぽ
}

public MockTextBox : ITestTextBox {
	public int SelectionStart { 
		get {
			// 実装 
		}
		set {
			// 実装
		}
	}
};

というようなコードを用意し、通常のU/I部分には TextBox ではなく TestableTextBox にします。
そしてテスト用コードでは MockTextBox を new して引数なりに利用します。
これがMockの基本のようですね。
なおNUnit2.2ではMockテストのための拡張が行われているそうです。
詳しくはこちら(@IT)。

[XP] XP実践入門 - 第8章・第9章

(11)第8章 InputCommand オブジェクト

　テキストを扱うModelのなかで読み込んだデータを適切な形で処理するためのオブジェクトクラスを作成することになります。
リファクタリングというよりは手戻りとなっています。
この章ではInputCommandオブジェクトクラスをテストファーストの実践として１ステップずつ解説しています。

(12)第9章 最初のストーリーの完成

　ストーリーが完成してもやることは残されています。
リファクタリングです。
リファクタリングといってもアルゴリズムの整理などの手がかかるものや変数名などの最適化など簡単なものと幅があります。
不要なもの（関数・変数・コメント）は削除するというのも大切なことだと思います。
よくコメントアウトしてコードを残しておくことがありますが、CodeManagerがあるのでいざとなればそれを見ればよいので不要な場合がほとんどでしょう。
そのほかにも現状では特に問題ないが将来的に問題を引き起こしそうなコードなどはリストアップしておく必要があります。
それらをすべて終えた後にストーリーの終了となります。

[XP] XP実践入門 - 第6章・第7章

(9)第6章 最初のユーザ受け入れテスト

　受け入れテストのためにU/I以外の部分がテストできるように簡単なスクリプト読み込み機能を実装しています。
この章で重要とおもわれるのは

新しい機能を開発している場合、実際にどのような問題があるかについて多くを学習することに最初に取り組みます。
（中略）
知っていることを解決し、知らない部分は後に残しておきます。

今必要ない部分に関しては「課題」として残しておくことで現在の進捗が遅れることがなくなりますし、後で取り組む場合も問題があること＝時間がかかるかもしれないことを明確にできます。

(10)第7章 一切合財

　ここで初めてCode Managementに関して出てきます。
驚いたことにVSSを利用せずにRubyのスクリプトで管理していたのです。
そういえば社内を調査して驚いたことがVisualStudioは利用していなくてもVSSを利用しているチームがあるということです。
ライセンス数を数えると微妙に足りなかったりしたので買い足したりした記憶があります。
VisualStudioを使わないのであればCVSとかSubversionとかを利用した方が良いような気がするのですが・・・。
　話を戻してこの章ではコードを捨てて前のコードに戻すことに関して議論されています。
テストがこまめにできないような状況は設計に何らかの誤りがあると考えるべきというのは大いに賛成です。

[XP] XP実践入門 - 第5章

(7)第5章 アイデアの表現

　コメントの意義、リファクタリングとはということを解説しています。
C#では関数名に日本語を利用できるのですが、

{
	if (!入力値判定(this)) {
		例外処理(this)
		return false;
	}
	値保存処理(this)
	return true;
}

みたいなコードは可読性が高いかどうか微妙です（慣れもあって私には読みづらいです）。
で慣習として英語で関数名を書くのですが、名が体を表せない場合も有り、そういった場合コメントは有効だと思います。
また、トリッキーなコードを書かざるをえないときなどもコメントはありがたいです。

(8)「ここでテストが必要になる」

　テストファースト、といってもU/Iがからんでくるとうまくテストできないことがあります。
そのため後回しになってしまう場合も。
その例を取り上げています。

[XP] XP実践入門 - 第3章/第4章

(5)第3章 緊急事態

　タイトルはショッキングなのですが中身はそんなことはないです。
開発していると良くある、「フレームワークが思った通りに動いてくれない」という場合の対処を書いています。
ここではEnterキーの処理をどこで行えばよいのかということを取り上げています。
Windowsの場合はWebでさがすと大概のことはわかるのですが、中には同じ問題にぶつかって結局解決策が見えないということもあります。
会社で契約があればMicrosoftに聞くという手段もあるのでよいですが（お金かかりますので）、個人ではなかなかできないですね。
本書でもMSDNで調べて、WebやNewsで調べて、それでも良い方法がわからなければ対処療法という感じです。

(6)第4章 モデルの抽出

　今までは全部FORMのイベント関数部分にコーディングをしていたので、処理部分をビュー(Form)から分離してModel部分に取り出します。
これによりModel部分のテストを行えばロジックのテストは完了することになります。
Modelへの切り出しで悩むところはViewとの関連性をどのくらいなくすかという部分だと思います。
たとえば一連の処理が、

Aの状態に従ってBの状態を変更する

という場合、Aの状態取得、Bの状態変更は誰が担当すべきかというところです。
本書ではView - Model の構造でViewで取得、変更を行い、変更すべき内容の検討をModelで行うようにしています。
Bがたくさんある場合、この方法だと速度に問題がでる場合がありますが、Modelは完全に処理のみをおこなうようになるのでテストはModelを分離して行えるのが利点です。

[XP] XP実践入門 - 第2章

(4)第2章 NUnitを用いたテスト

　テストファーストの安心感の解説。
そしてNUnitのインストール・設定、実際のコーディングなど、順を追って説明しています。
まずはユニットのテスト、というよりテストによってスパイクを行うとどうなるかという感じで進んでいきます。
これは自分がどんな感じで勉強していったかという履歴をコードとして残せるという利点があります。
自分の環境にも早速NUnitをインストールしました。
読み終えてからGoogleさんに聞いてみると、

●@ITのこちら
●ObjectClubのXPのページのこちら

が参考になりました。
これらはクラスのテストというNUnit本来の使い方で説明しています。
これを参考にしてプロジェクトを構成し直そうと思います。
章の最後に「Printfデバッグ最強」というような説明があります。
デバッガにおんぶにだっこになるとデバッガが変な挙動を示したときに怖い、ということなのでしょうか。
私としてはユーザ環境でしか再現しないバグに対処するために「ログデバッグ最強」と言いたいです。
ログをファイルに残す仕組みを最初にかんがえるべきかも。

[XP] XP実践入門 - 序章/第1章

  また寄り道です。せっかく本を買ったのもありますし、自分に活を入れる意味もあるので、本をなぞりたいと思います。

(1)プロローグ（序章）

　XPの説明ですのでこれはとばします。
日本語でXPといえばこちらからいろいろ読んでいただければと思います。
ピアソン・エデュケーションからでてる一連の「ＸＰエクストリーム・プログラミング XX編」も予算の都合があえば読んでおくとよいですね。

(2)第1章：ストーリー/スパイク

　まずは、開発側・ユーザ側にわけて要求=>工数=>費用対効果検討などの流れを見るわけです。
自分プログラムだとどうしても工数を無視して、技術的探求にいそしんでしまいます。
しかし、「こんなものがほしい」という欲求から、業務同様の流れを追いかけていきます。
で、書では著者（プログラマ）がC#に慣れていないため見積もりができない、という点から実験フェイズを行います。
私の場合では、C#自体は

●プログラミング作法は何となくわかる
●.netはVCLもどきと信じて何とかなる

という思いこみから実験フェイズ(スパイク)をとばしました。
「何とかなる」「何となく」」は良くないですね。
スパイクの対象としては

●thread処理
●socket処理
●XML読み書き

あたりが必要とおもわれます。
それぞれざっとGoogleさんに聞いてみると

●thread処理 => こちら
●socket処理 => こちら？
●XML読み書き => こちら

あたりが参考になりそうです。socketの受信非同期処理がいまいち見えてきていませんが、.NETのSOCKETクラスの説明を読み込んでみてのお楽しみにしたいと思います。
なお、書ではVisualStudio.NET Enterprise Architectに基づく、という設定です。
お金持ちはいいですね(うちはProfessional)。

(3)第1章：ストーリー/作成

　書にもありますが、ストーリーは２パターン必要です。
まず全体の工数を見積もるためのもの。これがないと仕事をとることは現状難しいですね。
次にこれから取りかかるべき詳細なもの。工数が１日とかはっきりと見積もりのできるもので、ユーザも容易に納得できます。
後者は短いリリースで確実にユーザが進捗をつかむためにも必要なものという位置づけです。
書では全体工数は扱っていません。また、残念ながら細かいU/I配置等の工数も扱っていません。
全体のストーリーは私も面倒なので扱いません。
都度、必要なストーリーを書くようにしてきます。
今までやったものに関しては以下の通りです。

●起動後メインウィンドウを表示します。メインウィンドウにはclose boxとメニューがあります。
●メインウインドではclose boxおよび「閉じる」メニューを実行するとを非表示状態にします。
●タスクトレイにアイコンを表示します。タスクトレイでは右クリックで（ウィンドウを表示）（終了）メニューが表示されます。アイコンをダブルクリックすると（ウィンドウを表示）を実行します。

次はいよいよNUnitの扱い方です。

[C#] 制御アプリケーション(6)

　ちょっと寄り道をしてclose boxを押された場合、タスクトレイのみにするようにします。
方法としては

  ●close box のメッセージを受け取ったら挙動変更
  ●メインウインドウの他にダミーの非表示のウィンドウを用意

の２通りが考えられます。
VCで良くやるのは後者です（じゃないとWindow Messageを処理するところがなくなるので)。
今回は前者でやってみます。
close boxを押した場合、WM_SYSTEMMENU / SC_CLOSE が来ます(Spy++などで確認してみてください）。
なのでこれを受け取れるようにWndProcをフックすることにします。
MainForm に以下を追加します。

protected override void WndProc(ref Message message)
{
  const int WM_SYSCOMMAND = 0x112;  //  (*1)
  const int SC_CLOSE = 0xF060;    //  (*1)

  switch (message.Msg)
  {
    case WM_SYSCOMMAND:
      if (message.WParam.ToInt32() == SC_CLOSE) {
        //Xボタン、コントロールメニューの「閉じる」、
        //コントロールボックスのダブルクリック、
        //Atl+F4などにより閉じられようとしている
      }
      break;
  }

  base.WndProc (ref message);
}

VCでコード書いていた人は(*1)の部分が「なんだかな～」という感じでしょうね。
VCならSDKのHeaderファイルをincludeしておけば直接数値をコード上に記すなんてことは必要ないですね。
ユーザがわざわざ値を調べなければいけないところは退化ですよね・・・。
　これでメッセージを受け取った際に別処理することができるようになりました。
ではメインウィンドウを消すコードを書きます。

protected override void WndProc(ref Message message)
{
  const int WM_SYSCOMMAND = 0x112;  //  (*1)
  const int SC_CLOSE = 0xF060;    //  (*1)

  switch (message.Msg)
  {
    case WM_SYSCOMMAND:
      if (message.WParam.ToInt32() == SC_CLOSE) {
        //Xボタン、コントロールメニューの「閉じる」、
        //コントロールボックスのダブルクリック、
        //Atl+F4などにより閉じられようとしている
        this.Hide();
        return;
      }
      break;
  }

  base.WndProc (ref message);
}

this.Hide(); でウィンドウを非表示します。
そして base.WndProc を呼ばれないように（本来の処理をさせないため）、return; で処理を中断します。
一応これでclose boxでメインウィンドウを非表示に、タスクトレイからでないとアプリケーション終了ができない状態になりました。
・・・でもアプリケーション終了手段はやはりメインウィンドウに別途必要（政治的理由）。

[C#] 制御アプリケーション(5)

　タスクトレイのアクションを実装します。
ようやくコーディングです。
まず、フォームデザインで

・trayContextMenu(ContextMenuの実体)を選択
  ・ウィンドウ上の[ショートカットメニュー]を選択
  ・[ウィンドウを開く]を選択
  ・[ウィンドウを開く]をダブルクリック

します。

そうするとフォームのコーディング画面になります。

private void showWindowMenuItem_Click(
  object sender, System.EventArgs e)
{

}

これに実体を追加します。
現在はウィンドウをアクティブにするだけなのでForm::Activate()メソッドを呼び出します。

private void showWindowMenuItem_Click(
  object sender, System.EventArgs e)
{
  this.Activate();
}

同様に、[終了メニュー]の実体も実装します。

private void quitAppMenuItem_Click(
  object sender, System.EventArgs e)
{
  this.Close();
}

ついでにタスクトレイのアイコンダブルクリック時も「ウインドウを開く」と同じ挙動にします。
フォームデザインで

・trayNotifyIcon(NotifyIconの実体)を選択
  ・[プロパティ]ウィンドウのの[イベントアイコン(稲妻マーク)]をクリック
  ・[アクション]-[DoubleClick]をダブルクリック

を実行します。

これでイベントに対応したメソッドが追加されるので、実装します。

private void trayNotifyIcon_DoubleClick(
  object sender, System.EventArgs e)
{
  this.Activate();
}

以上でいったんBuildしてコードの動作を確認してみます。

[C#] 制御アプリケーション(4)

　タスクトレイのメニュー表示です。
前回同様にメインフォームに対してツールボックスから

[Windowsフォーム]-[ContextMenu]をDrag&Drop

で追加します。
そして、メニューの内容を編集していきます。
先ほど追加したアイテムがフォームデザインの下部、NotifyIconの隣にあるはずなのでそれを選択します。
するとメインフォームの方に「ショートカットメニュー」というのが現れます。
それをクリックするとその下に空のメニュー領域が出現するのでそこで

右クリック-[新しい項目の挿入]を選択

これでデフォルトのメニューアイテムが登録されるので、Name, Text, Shortcutなどを編集します。
ここでは「ウインドウを開く(O)」と「終了(Q) Alt+F4」を追加してみました。

まだ一行もコード書いていませんね(汗

[C#] 制御アプリケーション(3)

　ウィンドウは開けましたので、次はタスクトレイにアイコンを表示します。
VCだと結構面倒ですが、アイコンの表示も、メニューの表示もツールチップの表示も簡単です。
まずはアイコン表示。
メインフォームに対してツールボックスから

[Windowsフォーム]-[NotifyIcon]をDrag&Drop

で追加します。そして、

・NotifyIconの[Icon]にトレイに表示させたいアイコンを指定
・このアイコン上でのツールチップ表示は[Text]プロパティに文字列を指定

簡単ですね。

これでBuildしてチェックします。
実行するとこんな感じでアイコンがタスクトレイに表示されます。

[C#] 制御アプリケーション(2)

　まずは何も考えずにU/Iを作ります。
C#のWindowsアプリケーションのプロジェクトを作成します。
そしてフォーム(Mainウィンドウ)の設定を多少変更します。
今回変更したのは次の通りです。

●ファイル名
●アイコン
●最大化ボタン消去
●Name
●GridSize(5x5)
●開始表示位置をScreenCenterに
●FormBorderSizeをFixedDialogに
●ウィンドウタイトル

これでいったんBuildして問題がないことを確認します。

# ウィンドウのスタイルが違うのは気にしないでください。
# 趣味で変えています。

[C#] 制御アプリケーション(1)

そろそろ仕事でC#でのプログラム作成が本決まりになりそうなので、それと似たものを自宅でも作っていこうと思います。
今回例として作成するシステムの構成としては以下の感じ（例なので実際には映像装置とかはありません）。

操作端末では

・録画済みのビデオの再生・停止処理指示
・スケジュール通りの地上波・衛星番組の放送表示指示

を行います。
その指示はTCPにて映像操作アプリケーションに伝えられます。
映像操作アプリケーションは映像描画装置が理解できる命令に変換して通知します。
なお、映像描画装置は複数台存在することを前提とします。
映像描画装置は指示を受けたらビデオ再生もしくはTV放送表示を行います。
また面倒なのでここには表記していませんが音声装置も映像装置と同様に存在します。

今後、このシステム例における制御アプリケーションを作成していきます。
要点は以下の通りとします。

・指示の通信（送信・受信）
・スケジュール実行
・状態確認用 U/I

これを作れれば、C#.NETにおけるU/Iの実装およびTCP/IPの通信方法の実装の仕方がそれなりに見えてくるのではないでしょうか。