ACCSがプロバイダを介してWinnyユーザに警告メールを送付

ここのスラッシュドットニュース

ACCSがプロバイダを介してWinnyユーザに警告メールを送付
http://slashdot.jp/articles/06/12/12/0651258.shtml

によると（以下斜体は上記ニュースより引用）

ACCSが「 Winnyと著作権について」とした内容のメールを送付していたそうだ。送付に際しては、Winnyネットワーク上にファイルをアップロードしているユーザのIPアドレスをWinnyのノード調査により割り出し、利用時間とIPアドレスをプロバイダに連絡して実際の送付を依頼するという手段を取っていたようだ。


ちなみにＡＣＣＳとは社団法人コンピュータソフトウェア著作権協会のことで、
この件に関しては、以下
http://www2.accsjp.or.jp/winny/
にいろいろかいてある。

かりにＡＣＣＳは、合法だとしても、ＩＰアドレスを指定して、このメールを送ってくださいと頼んだら、プロバイダは、送っていいのか？個人情報保護法上、問題ないのか？
っていう議論はおこりそうだけど、ウィリアムのいたずらが問題にしたいのは、
そーいうことではない。

これって、一歩間違うと、おれおれ詐欺に、加担しちゃわない？ってこと。。。

たとえば、ＪＡＳＲＡＣを装った人が、
「あなたは、著作権違反してるから、
　ここに、お金を振り込んでね！
　そうすれば、以降、ＯＫ
　＝＞スナックのカラオケとおなじしくみだよ！」
っていうメールを作って、

今回ＡＣＣＳがやったのと同じ方法でＩＰアドレスを調べて
プロバイダに行ったとする。

プロバイダに行ったときには、その悪いやつは、ニセＪＡＳＲＡＣの名刺
（もちろん、電話番号は、悪い人一味の電話番号になっている）をだして
「わたくし、こういうものですが・・・」
「このＩＰアドレスのやつら、わるいやつなので、
　このメール送ってちょ！」

っていって、プロバイダも、

「ちょっとおまちください、確認してみます。」

っていって、その名刺の電話番号をかけて、ほんとうにＪＡＳＲＡＣか、確認しても。。
でるのは、悪い人一味のやつなわけで、うーん、これじゃわかんない。。

って、ことで、プロバイダが信用しちゃって、そのメールを流したら。。（＞＿＜！）
メール受け取った人の中には、「まじまじい！？」と思って、
振り込んじゃうやつとか、出てきそうに思うけど。。

大手プロバイダなら、ここまで、おばかさんはいないとおもうけど。。
中小プロバイダのなかには、こーいう間違いをしてしまい、
振り込め詐欺に思わぬ形で加担してしまうとか。。あり得ないことではないような気がする。

。。。考えすぎ？？
　

COBOL時代の分析手法で、ＪＡＶＡとかのプログラムが作れるか？という視点でＥＡを考える

　以前に、要求分析と実装部分（外部設計部分）で、断層が起こるという話を書いた（ここ）

　で、この問題、国家を挙げて行っているe-Japan構想でも起こっているようだ。。

　ちょっと古いが、ここ
崖っぷち！電子政府～迷走する4500億円プロジェクトの行方・第3回：
問われるGPMOの調整機能 (1/2)
http://www.itmedia.co.jp/enterprise/articles/0608/15/news002.html
の真ん中くらいの図を見ていただきたい。

　最適化というのは、国がＥＡをいうときの言い方（最適化計画という言い方をする。なぜこういうのかは、後述）。

　この最適化計画から、基本設計（ウィリアムのいたずらが行っている外部設計の部分にあたる）にいたるところがあいまいであるというのを示している。

　ちなみに、その詳しい話は、上記サイトに譲る。。。が、一点問題にしたいところがある。
　それは（以下斜体は上記サイトより引用）

最適化計画は上流工程に当たるが、下流工程のプログラム実装やハードウェア販売で儲けたいベンダーは最適化計画を軽視しがち。事実、財政当局は上流工程に多くの予算を割かないため、それを安値受注したコンサルティング会社や監査法人も最適化計画を熱心につくらない。その結果、肝心の方式設計が曖昧になる悪循環が続くのだ。


　これは、技術論敵に言うと、ちょっと違うのだ。
　（もっとひどいのだ　＞＿＜！）正確に言うと、

　　　最適化計画で使っている（多くはＤＯＡやそれ以前の）分析技法と、
　　　現在のプログラムで使う（オブジェクト指向の）フレームワークの方式は、

　合わないのだ（＝連携が取れないということ）。だから、かりに、きっちりしっかり分析したとしても、方式との連携ができないので、ここは、あいまいになってしまうのだ。

　なので、肝心の方式設計があいまいになるというか、つながんないのだ。。（＞＿＜！）

---

　具体的に話そう。

　世の中のコンピューター設計の考えには、ＤＯＡとオブジェクト指向の２つの考えがある。

　ＤＯＡは、全社的にデータを洗い出し、そこから最適なプロセスを考えていく。

　一方、オブジェクト指向というのは、カプセル化を基本とする。ある部署なら部署、担当者なら担当者のオブジェクトを生成し、そこに送るメッセージと答えが満足できるものであればＯＫ。
（ちなみに、にているけど、ちょっと違うなんていう場合は、継承して、それにあったオブジェクトをつくる。これも、オブジェクト指向の基本的な考えだ）
　このとき、そのオブジェクト内の処理は不問とする。だから、オブジェクト内が、最適になっているかどうかは、わからない。

　このため、大きなプロジェクトでは、中身が不問になる、オブジェクト指向のほうが、向いているとされる。

　ウィリアムのいたずらは、一概にそうとは言えないと思うが（前に、大きなシステムはむしろＤＯＡが向いていると書いている）、システムを手早く作るには、オブジェクト指向が向いている（ウィリアムのいたずらの考えは、そのため、いったん部分部分を、オブジェクト指向でつくり、全体を見切った上で、ＤＯＡでもう一度、きれいに作り直したほうがいいという考えを持っている。上記は、その意味で書いている）

---

　さて話を、国のＥＡに戻して、ＥＡは部分最適でなく、全体最適になるような組織を目指している。ここから、最適化計画という言葉が来ている。

　このため、現状の全体の組織、データ構造を明らかにし(AsIsモデル）、そこから全体最適の理想像(ToBeモデル）の組織、データ構造を作り上げていく。

　そして、実際手法としては、
　ＥＲ図、ＤＦＤ、情報システム関連図といった、
　ＣＯＢＯＬ時代の構造化分析、その後のＤＯＡ時代に良く使った手法がでている。


　一方、現在は、クラス内に、データとメソッドを隠蔽し、メッセージ中心のアプローチになっている。この形に落とし込めば（ＵＭＬでも、それは可能）JavaやＶＣ＋＋にも落とし込めるし、Ｗｅｂアプリにも落とし込める（ブラウザの画面とは、属性値が入力欄、プッシュボタンがメソッドにあたるクラスと考えられる）。

　今のＪａｖａでの開発は、したがって、クラス図中心、場合によりシーケンス図であり、（あと分析にアクティビティ図、ユースケース図）このクラス図は、あくまでもカプセル化のために、データとメソッドをひとまとめにする。

　ところが、ＥＡでも、クラス図は使われるが、それは、データ体系でデータの構造をまとめるための利用でしか過ぎない。ビジネス（ＢＡ）とデータが分離されてしまっているのだ。これじゃー、オブジェクトにならないので、使えない。

　さらにもっとひどいのは、ＣＩＯ連絡会議では、クラス図が、政策業務体系（ＢＡ）で使うという。。おい、どっちなんだよ（＾＾；）

　っていうか、この２つを分けちゃうことに問題があるんだけどさ（＾＾；）

---

　てなかんじで、ＥＡでの分析体系は、ＤＯＡとかにむいていて、一昔前のＣＯＢＯＬ開発に向いている（ＤＯＡではＪＡＶＡ開発は無理という意味ではない。なぜなら、ＤＯＡのＥＲ図とＤＦＤから、クラス図に持ってくる手法はあるので。。しかし、その場合でも、Javaに落とし込むときは、クラス図を使う）。

　情報システム関連図からは、ＣＯＢＯＬのような処理を持ってくることにはいいんだけど、Javaのように、カプセル化する言語だと、なにをカプセル化して、あるメソッドにおいて、他のクラスにどういうメッセージを送ればいいかはっきりしないので、処理があいまいになる。

　っていうか、情報システム関連図作るんだったら、クラス図しっかり作ってくれってかんじ。
　publicやprivateまできっちりしっかり、引数もきっちりしっかり決めて。。

　っていうかんじで、ＣＯＢＯＬ時代の上司のプロマネが、部下のＳＥやＪａｖａのプログラマに指示出しているような感じで、話が合わないのだ。。この図の体系は。。

---

　なんで、この場合は、ウィリアムのいたずらが言った、要求と方法論の断層というよりかは、もっとひどい、世代間（ＣＯＢＯＬ世代とＪＡＶＡ世代）の断絶、それが、大人が中途半端に、若者に擦り寄って、若ぶってクラス図なんか、もちだすから、なおさらわけわかんねーっていう感じに見えてしまう。

　。。。なーんてかいて、大丈夫かなあ（＾＾；）

　まあ、かいても、
　　批判がこなかったり、
　　削除命令がこなかったり、
　　ブログがある日突然潰れている（＞＿＜！）
　とかいうことがなかったら、

　もっと、根本的な問題、そもそも、全体最適化をすることは、可能なのか、
　もっと根本的な、全体最適化をすることは、本当にいいことなのか？

　っていう話題を、書いてみたいと思います。

Javaの画面表示－その３：ＪＳＰで表示、サーブレットで処理（リダイレクト編）

　シリーズJavaの画面表示のつづきです。

　今、ＪＳＰで表示画面を作成し、サーブレットで処理部分を書くということをやっていて、前回までで、フォワードを使って、つなぐことをやっていました。今回は、もうひとつのやり方、リダイレクトを使ってやってみたいと思います。

---

■リダイレクトとフォワードの違い

　リダイレクトとフォワードの違いは、
ここ
http://www.atmarkit.co.jp/fjava/javatips/062jspservlet029.html　
にあるように、

　フォワードは、サーバー内での処理（そのため、サーバーのクラス内のJSP,サーブレットにジャンプできる）のに対し、

　リダイレクトは、いったんクライアントにもどして、クライアントのブラウザが、表示先にジャンプします

　そのため、リダイレクトの場合には、まったく違ったサーバーにも、移動できます。
　ただし、違ったサーバーに移動する場合は、セッションは使えません（セッションは、そのサーバー内でしか、値は参照できない）。そのため、ＧＥＴ型、ＵＲＬに引数の値を設定して、移転先に渡す形になります。

　今回は、サーバーを変えないので、セッションでもいいのですが、サンプルということで、ＵＲＬの引数に結果をセットする形でやってみたいと思います。

---

■変更内容の仕様と概要

＜仕様＞
以下の２点が変わります
（１）入力結果、エラーメッセージ、正解率の受け渡しが、
　　　セッションから、ＵＲＬの引数にかわります。

（２）フォワードからリダイレクトに変わります

＜仕様変更対象ファイル＞
以下のファイルが変更対象になります
・index.jsp
・kekka.jsp
・shori.java

＜変更の概要＞
（１）セッションからＵＲＬの引数へ
ＪＳＰで、
String msg = (String)session.getAttribute("msg");
のようにセッションから取得していたところが、
String msg = request.getParameter("msg");
のように、パラメータを取得するように変わります。

なお、Javaのほうも変わりますが、それについては（２）
でやっています。

（２）フォワードからリダイレクトに変わります

shori.javaで、いままで、

getServletContext().getRequestDispatcher("/jsp/index.jsp").forward(request,response);

のようにやっていたところを

response.sendRedirect("http://127.0.0.1:8080/test/jsp/index.jsp?msg=NoData");

のように変えます。

---

■ＪＳＰソース

　では、ＪＳＰ側のソースindex.jspとkekka.jspを以下に載せます。

●ソース index.jsp

＜html＞
＜head＞
＜%
//==============================================//
//	画面用の部分			  //
//==============================================//

//	変数を受け取る
	String msg = request.getParameter("msg");
	if ( msg	==	null )
	{
		msg	=	"";
	}


//==============================================//
//	以下、画面表示			  //
//==============================================//
%＞
＜title＞早打ちの練習＜/title＞
＜/head＞
＜body＞
＜h1＞＜font color=red＞＜%=msg%＞＜/font＞＜/h1＞
＜H1＞早うちの練習＜/H1＞
以下の文を打とう！＜BR＞
＜B＞This is a pen＜/B＞＜BR＞
＜form method=get action="http://127.0.0.1:8080/test/servlet/shori"＞
＜input type=text name=nyuryoku size=20＞＜P＞
＜input type=submit name=do value=打ち終わった！＞＜P＞
＜/form＞
＜/html＞

（上記＜　＞　￥　は本当は半角です。赤字は、今回変わったところ）

●ソース kekka.jsp

＜html＞
＜head＞
＜%
//==============================================//
//	画面用の部分			  //
//==============================================//

//	変数を受け取る
	String ritu = request.getParameter("ritu");

//==============================================//
//	以下、画面表示			  //
//==============================================//
%＞
＜title＞早打ちの練習＜/title＞
＜/head＞
＜body＞
＜H1＞結果＜/H1＞
正解率 = ＜%=ritu%＞＜BR＞
＜/html＞

（上記＜　＞　￥　は本当は半角です。赤字は、今回変わったところ）

---

■ Javaのソース
●ソースshori.java

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class shori extends HttpServlet {
	public void service(HttpServletRequest request, 
                      HttpServletResponse response) 
                          throws ServletException, IOException {
		//セッション開始
	 	HttpSession session = request.getSession(true);
 
		//==============================//
		//	データの取得	　　//
		//==============================//
		//Fromの引数取得
		String nyuryoku = request.getParameter("nyuryoku");
		if ( nyuryoku	==	null )
		{
		  response.sendRedirect("http://127.0.0.1:8080/test/jsp/index.jsp?msg=NoData");
		}
		else if ( nyuryoku.length()	==	0 )
		{
		  response.sendRedirect("http://127.0.0.1:8080/test/jsp/index.jsp?msg=NoData");
		}

		//　処理
		int	i,atari;
		atari = 0;
		String chk = "This is a pen";
		for(i = 0 ; i ＜ nyuryoku.length() ; i ++ )
		{
			if ( i ＞= chk.length() )
			{
				break;
			}
			else if ( chk.charAt(i) ==  nyuryoku.charAt(i) )
			{
				atari++;
			}
		}
		//==============================//
		//	ビューにフォワード	　　//
		//==============================//
		//	結果の設定
		String sendPara = "";
		sendPara = sendPara + "?msg=%20";
		sendPara = sendPara + "&ritu=" + Integer.toString(atari*100/chk.length());

		//	結果
		response.sendRedirect("http://127.0.0.1:8080/test/jsp/kekka.jsp"+sendPara);
	} 
}

（上記＜　＞　￥　は本当は半角です。赤字は、今回変わったところ）

---

ということで、今回はここまで。

Tomcat6.0が4.Xとちがう点操作編、マネージャーでアプリごとに停止、起動可能

　Tomcat6.0が4.Xとちがうところについて、前にプログラムのことを書きましたけど、操作の点でも違います。

　Tomcat4.Xだと、Stop TomcatとかStart TomcatとかRestart Tomcatとかいうのが、
　スタートボタンからたどっていって、できますが、

　６．０にそんなもんはありません。

そーいうことをしたいときは、
（１）Tomcat Managerというのがあるので、それを起動します。
（２）ユーザー名、パスワードを入れてください
　　→adminのユーザー名をインストールのときに入れていると思うので、
　　　admin 入れたパスワードではいります。
　　　設定してなければ、ユーザー名adminでパスワードなしでＯＫ
　　　新たに設定したい場合は、わざと適当なユーザー名を入れてください。
　　　エラーメッセージ画面に、どうすればいいか書いてあります。

　そうすると、以下のような画面が表示されます。

（図は、再リロードした後に撮ったので、メッセージの部分は起動時と違ってます）

あとは、お好きなように停止、再ロードしてください。
実行すると、結果は、上の図のように、メッセージにでます。

２足歩行ロボットの実用化、実は遠かったりして。。。

ここの動画
ASIMOがとんでもないことにｗｗｗ
http://video.google.com/videoplay?docid=-6947118853654187245&sourceid=docidfeed&hl=en
（読み込み後、音がなります）

をみると、うーん、２足歩行ロボットとか言うけど、
現実的には、実用化になるんですかねえ。。。
ＡＳＩＭＯですら、これじゃーねー。。

でも、このおねーさん、すぐに「中止」って、言ったって言うことは、
これ、あらかじめ想定していたのかなあ。。
ロボットが転倒したら、中止にしてくれって。。

でも、ＡＳＩＭＯ君、転倒しても、「人間も・・・」とか、
一生懸命解説してるけど。。。
うーん、むなしいものがあるぞ。。
人間は、その程度の階段で、転倒はまずしないぞ。。
（もししたら、ラッシュアワーとか、怖いものになるぞ　＾＾；）