「弾くと音が鳴るTシャツ」があれば、Wiiリモコンで60インチリアプロテレビ破壊しなくてすむ？

すみません、ちと古い話なのですが。。

フリーペーパーの、TokyoHeadlineをみていたら、こんな記事が
弾くと音が鳴るTシャツが豪州で登場
http://www.tokyoheadline.com/vol282/news09.html


つまり（以下斜体は、上記ニュースより引用）

オーストラリアの研究者らが、エアギターで実際に音を鳴らすことのできるTシャツを開発した。

という話だそうだ。しくみは


このTシャツは、ひじと袖の部分に腕の動きを感知するセンサーを内蔵しており、Tシャツを着た人のエアギターの動きに合わせてギターの音が鳴る仕組みとなっている。


ほー、なんか、太鼓の達人とか、スティックなしでもいけそうだし、
ほかの運動競技でもつかえそうだよね。。

エアギターならぬ、
エアー太鼓とか、エアーゴルフとか、
エアー野球とか、エアーテニスとか。。

Wiiのコントローラーをぶん回していると。。
Wiiストラップが切れてリモコンが大型モニターを直撃、破壊
http://blog.livedoor.jp/dqnplus/archives/857589.html

60インチリアプロテレビを破壊しまうような人が出てくるから、
（も、もったいねー　＞＿＜！！）

こっちのＴシャツをコントローラーにしたほうが安全？？

なんかでてきそうだよね、このＴシャツをコントローラーにするゲームとか。。

。。。でないかなあ？？

Javaの画面表示－その１９：ＪＳＰで、表示部分と処理部分を分ける（その１：仕様）

　シリーズJavaの画面表示のつづきです。今、ＪＳＰやってます。
　で、ＪＳＰでツールとかを使わないで、画面部分と、処理部分を分けてみたいと思います。
　もちろん、 処理部分をコントロールとモデルに分ければ、ＭＶＣになりますが、そこまでやんなくてもいいけど、画面と処理を分けたいケースがあります。

　その例と、どのようなときに、そういうことが起こるかということについて、今日は書きます。
（やり方は、このつぎです）

---

■仕様
以下のような入力画面において

もし、何も入力されなかったら、以下のように

エラー画面を出して

入力されたら、
　　入力された文字列と、
　　チェックする文字列を比較して、
一致したら、その割合を以下のように

表示します

---

■画面と処理を分離しないと、どうなるのか？

　もし、これを、たとえば、
１．初めの入力画面と
２．処理した結果エラーだったらエラー画面表示
　　　ＯＫなら正解率表示画面

というふうに、画面と処理をわけなかったとすると、

　　入力画面とエラー画面の内容は、基本的に同じなので、

　　入力画面を直したら、エラー画面も直さないといけません・・・

が、そーすると、さっきの依存性みたいに、直し忘れる可能性があります。

---

もっと一般的にいうと、

１つの処理でも、正常系とエラー系、さらにいろんな状態によって
画面が変わるし、

画面のほうも
１つの画面でも、場合によって、呼び出す画面は変わるし、
さらに、いろんな画面が１つの処理を呼び出すことがあります。

ということで、画面と、処理は、１対１では「ない」ので、
それを一緒にしてしまうと、
　１つの処理プログラムに複数画面が入ったり、
　１つの画面プログラムに複数処理が入ります。

さらに、いくつかの画面に、同じ処理が入るので、修正し忘れた！

という危険があります。

---

■今回の構成

そのため、画面と処理を分離したいわけです。

つまり今回だと
１．入力画面（と、エラー画面）
２．結果表示画面 　　

という画面部分と

３．処理部分

という処理部分にして、画面と処理をわけ、
合計３つのファイルにしたいわけです。

---

ということで、このシリーズの次回では、具体的な内容にはいります。

依存性の問題の対応策（その２：古いメソッドを入れておく）。

前に書いた、依存性の問題の対応策について
今回は、古いメソッドをいれておいて、「推奨しない」にするという方法を示します。
一般的には、これが良く使われますが、これにも欠点があります。

---

■もともとの話について

　どーいうはなしか？というのは、前回の「■そもそも、どーいうケースなのか」に示してあります。

　もともと、エラーメッセージだけを引数にしていたのを、エラー”レベル”も引数にしたのですが、

　aとbにはその変更の連絡が行き、dには変更の連絡が行っていないという状態です。

　このとき、bは、エラーメッセージ出力、aとdは、bのそのメソッドを利用します。

---

■古いメソッドを残す方法

このとき、Javaならば、引数が変わっただけで別メソッドとして扱われるので、bのエラーメッセージ出力を、以下のように、古いメソッドものこしておき、@deprecatedを、Javadoc用のコメントに入れます。

/**
 * エラーメッセージ出力クラス
 * @author ウィリアムのいたずら
 *
 */
public class b {

	/**
	 * エラーレベル
	 */
	public static	int	errLevel	=	0;

	/**
	 * エラーメッセージ出力（旧式）
	 * @deprecated
	 * @param	msg	出力メッセージ
	 */
	public static	void errmsg(String msg)
	{
		System.out.println("このメソッドは古いので使わないで！");
		throw new RuntimeException();
	}

	/**
	 * エラーメッセージ出力
	 * @param	msg	出力メッセージ
	 * @param	level	このメッセージのエラーレベル
	 */
	public static	void errmsg(String msg,int level)
	{
		if ( level	＞=	errLevel)
		{
			System.out.println(msg);
		}		
	}
}

（上記　＞　は、本当は半角）

こうすると、eclipseを使っていれば、ワーニングが出ますし、

コンパイルしたとき、少なくともjava1.5なら、いかのようなエラーメッセージが出ます

注:d.java は推奨されない API を使用またはオーバーライドしています。
注:詳細については、-Xlint:deprecation オプションを指定して再コンパイルしてください。

なので、コンパイルしたとき分かるし、さらに、古いメソッドをランタイムエラーで落としているので、実行したときも分かります。

---

■古いメソッドを残す方法のメリットとデメリット

●メリット
　古い方法も残しておくので、コンパイルエラーにならず、依存性の問題に夜コンパイルの問題は起きません。
　また、@deprecatedをいれておけば、エラーメッセージがでるので、これで構成管理中でもわかります。
　ただ、構成管理で、ワーニングが出るといっても、緊急度を低く考えられてしまうので、ランタイムエラーで落としています。

●デメリット
　とくに、古いものをランタイムエラーで落とさない場合、コンパイル時のワーニングなので、緊急性が低いと考えられ、いつまでも直してくれないと、古い関数を、いつまでも、直してもらえないという欠点があります。
　なので、ランタイムエラーで古い関数が呼ばれたら落としてしまうわけですが、これは、前回同様、回帰テストが（あるていど）できていないと、この部分のバグが残ってしまうという危険性があります。

　あと、修正量が、前回の窓口一本化より、多いケースが多く、
　とくに、「こうやって修正するつもりだったんだけど、やっぱやめた！」といったとき、「へー、また戻すのお。。。前のメソッド部分を削除しちゃったから、よくわかんないよお（＞＿＜！）って言うことがあります。

　なお、それを回避するため、「ソースを削除するのでなく、コメントにしろ！」という意見もありますが、そーすると、ソースが何がなんだかわかんなくなり、追えなくなってしまいます。

---

■どこで使うか

　というか、一般的な修正は、このやり方でやるのが普通です
　（ただし、ここでやったような、前のものを、ランタイムエラーで落とすのではなく、そのまま残しておくほうが普通）

　ただ、これには、上記に書いたように、「こまらないので修正しない」というケースが起こる場合が多いので、それに対する対策が必要です。
　具体的には、このワーリングが出たら、（「依存性の問題」の）バグ票を自動的に作成し、この依存性の問題のバグ票を受け取ったら、最優先で、このバグを調べるとか。。。

　ただし、修正量が多くなるので、不安定な部分が多いようなケースでは、これ以外の方法（一本化や「引数だけは、共通化する」など）を使うこともあります。

「Googleマップで自分がどこからアクセスしているかが分かる」というサービス登場

ここの記事
Googleマップで自分がどこからアクセスしているかが分かる「IP-address.com」
http://gigazine.net/index.php?/news/comments/20061121_ip_address/
によると、（以下斜体は上記記事からの引用）

ページにアクセスするだけで、自分がだいたいどの辺りからアクセスしているのかをGoogleマップを使ってグラフィカルに表示してくれるサービスがあるそうな。。

My IP address and location? Show my ip address and locate the ip!
http://www.ip-adress.com/

実際にはプロバイダのアクセスポイントの値が入るみたい。

もし、これが便利だとすると、ケータイをかけたひとの居場所が
Google Mapに表示されるとか、auあたりで、技術的には作れそうだけど。。
それって、逆に困るよね（＾＾；）
アリバイ工作ができない。。