災害対策には、産官学民の対応が必要でしょ！

　Solive２４のなっちゃんのソラマドオールナイト２部、金曜日に、NIWAさんが、
　このまえの沖縄の大雨の問題について、どうすれば、災害が減るかということについて熱く語ってました。

　まず、今回の災害、ゲリラ雷雨がくることは、予測できたと。
　で、問題は、

１．ゲリラ雷雨がきたとき、どの川がどのくらい危険ということを予測できない。
２．かりに予測できたとしても、それを知らせる方法がない。

　この問題に関し、みんなが危険なところをレポートしてもらって・・・

　とかいう話をしていたけど、これって、ウェザーニューズががんばるだけじゃ、無理あるだろう。日本中の川の危険性を計算するのはたいへんだし、かりに、計算ができたとしても、「土砂崩れが起きる可能性があります」というような地象予想を気象庁が許すかどうか分からない。

---

　現実的には、やはり、高校の地学部とか、中学生の夏休みレポートとかで、地元の川の様子とか、水位とかを調べておいて（ま、大学がやってもいいけど、大学がやるレベルのことではない？）、どのくらいの雨で、どうなるという資料を持っておき、

　それを自治体や、興味のある個人と共有し、

　ウェザーニューズが、自治体（市など）に、ゲリラ雷雨、降水量の情報を提供する。

　危険なレベルになったら自治体が知らせるというかんじ（放送だけでなく、デジタルサイネージ＝電子看板とかの利用もあるかも＊）？

---

　法律の壁があるので、ウェザーニューズが地象の予報を出すことができない（気象庁が禁止している）。そこで、どの川が、どうなるという予測は、自治体がやるしかない。しかし、その判断をするための気象情報を提供するということは、ウェザーニューズはできるので、その気象情報から、どう判断するかということを、（ウェザーニューズの）減災プロジェクトを通じて自治体や高校の地学部、地元の個人の関心がある人たちと考えると・・・

　そういう、産官学民の対応が必要だと思う。ただし、
　　産：ウェザーニューズ
　　官：市などの自治体
　　学：高校の地学部
　とかいった、地方による地元密着の考え方なんだけどね・・・

　そして、民（個人個人の関心）がベースにはあると・・・

＊みんなに知らせるには、デジタルサイネージなんかより、いい方法があるんだけど、その前にあることを書かないといけないので、その話をしてから・・・
　・・・つまり、この話題、続く。

ホワイトボードをデジタルで撮ってほしい

　きのうのピアノより、もっとほしいものがあるので、ちょっと書いてみる。
　それは、ホワイトボードをデジタルで撮るもの。
　ホワイトボードって、紙に書いたものを出してくれるんだけど、
　あれ、紙だからめんどーなのよねー。保存にも、ほかの人にコピーするにも。

　書いた内容をボタンを押したら、イメージファイルで、SDカードとかUSBメモリに保存してくれたり、インターネットとつなげられたりできないかなあ。そーすると、保存にべんりなのよねー。きれいに書くと、もしかして、OCRで読み取れたりして・・・そーすると、議事録とか書くとき、べんりだよねー！！

---

　あ、あと、エコをかんがえると、ホワイトボードに書くマジック、あれも、もったいないのよねー。すぐ書けなくなっちゃううのよ、１日５、６時間連続にかいていると、１週間、いや３日くらいしか、持たない気がする・・・

　あれもさー、ホワイトボードが実はペンタブレットになっていて、ペンで字を書くと、触れたところが色が変わる、黒板消しの代わりにボタンがあって、そのボタンを押すと、いっぺんに消してくれるとかのほうが便利だよねー。

---

　でも、それより、最近興味しんしんなのは、NHKの高校講座や放送大学の一部で取り入れられている、手元の紙に書くと、それを映し出すっていうやり方。

　あれを個人的にやるとすると、

１．ノートや紙の上に、文字を書いて、
２．そのノートや紙をWebカメラでとって、
３．そのWebカメラ画像をPCで表示して、
４．その表示内容を、プロジェクターで
５．ホワイトボードの上に投影する

なんだけど、問題は３の、Webカメラで撮った内容を、PC上に全画面表示できるかどうかなんだよねー。これがうまくいけば、ホワイトボードにかかないでいいとおもうんだけど・・・Webカメラ、買ったことないので、わからん・・・

それより、Webカメラで鍵盤を撮って、レーザーで示してくれたほうが・・・

ここの記事
手に装着すればすぐにピアノが弾けるようになる「Concert Hands」
http://headlines.yahoo.co.jp/hl?a=20090821-00000000-inet-inet

それより、もっとお手軽に、ピアノでも、キーボードでも、エレクトーンでも、とにかく、鍵盤部分をWebカメラで撮ってパソコンに送ると、自動解析して、弾きたい曲に合わせて、レーザーとかなんかで、次の音をポイントアウトしてくれるほうがいいなあ・・

　Webカメラで撮るだけなので、外付けでできるし、ピアノが変わってもすぐ対応できるし、画像処理部分も、そんなに白と黒が規則正しく並んでいるのって、ピアノぐらいだろうから・・・

　あと、その応用で、紙にキーボードを書いて（というか、キーボードをプリントアウトしてくれる）その上を指でたたくと（弾くと）？Webカメラが撮影して、パソコンから音を出すっていうのは、難しいのかなあ・・・

　これと、さっきの次の音をポイントアウトしてくれる機能を合わせれば、ピアノがなくても、楽譜が読めなくても、練習できるよね！

　どちらも、需要がないから、やんないのかなあ？
　YAMAHAとか、ローランドあたりから、でてきてもおかしくない・・・
　・・いや、フリーソフトとか、大学のほうが、ありえるか？

UML等各種ダイアグラムのエラーチェック体系化（その２０：ＤＦＤ その２）

シリーズ「UML等各種ダイアグラムのエラーチェック体系化」です。

　現在「いろんなダイアグラムをＲＤＢにいれよう！」化計画、
　をやっていて、前回、ＤＦＤを入れました。

　今回は、そのＤＦＤのエラーチェック方法です

　なお、ここで書いたとおり、いままでのまとめは

こちら
システム開発における「最小単位」とその連結法
http://www.geocities.jp/xmldtp/index_system.htm

---

■ＤＦＤのエラーチェック方法

　そもそも、このシリーズの表題が、「UML等各種ダイアグラムのエラーチェック体系化」なのに、
エラーチェックについて何も書いていないので、今回はそれについて書きます。

エラーチェックには、
・２つ以上のダイアグラム間のエラーチェック
・あるダイアグラムの詳細・概要間、あるいは１枚のシート内のエラーチェック
と分けられると思います。

　はじめの「２つ以上のダイアグラム間のエラーチェック」については、ある程度ダイアグラムのＤＢ化が進んでから説明しようと思います。後者の「あるダイアグラムの詳細・概要間」については、それぞれのダイアグラムを紹介した後にやろうと思ってます（今まで書いたＥＲ図、クラス図はチェック項目がないので、書かなかった）。

　で、今回は、ＤＦＤのエラーチェック方法ですが、それは、ここ

平成１７年度
　会計検査院法第３０条の３の規定に基づく報告書
　　「各府省等におけるコンピュータシステムに関する会計検査の結果について」
http://report.jbaudit.go.jp/org/h17/yousei5/2005-h17-8092-0.htm

にあるように、

・ＤＦＤ中に書かれたプロセスについて、それを詳細化したＤＦＤが記述されるが
・そのとき、概略を書いたＤＦＤのプロセスに対する入出力のデータソース、データストアは
・詳細化して書かれたＤＦＤのどれかのプロセス（複数あってもよい）の入出力のデータソース、データストアに

なっていないといけない
というおきてがあります。

---

■具体的には

前回の図
http://itpro.nikkeibp.co.jp/article/COLUMN/20080619/308620/zu3s.jpg

を例にとっていうと、たとえば「自動発注」には、在庫データ、受注データ、メーカーのデータストアまたはデータ発生・吸収があります。
　ということは、もし「自動発注」の詳細ＤＦＤを考えたとして、そのときのプロセスを「発注量算定」「発注データ作成」「発注実行」とすると、それら３つのプロセスのどれかが、在庫データ、受注データ、メーカーに「必ず」アクセスするということです（もちろん、２つ以上アクセスしてもＯＫです）

　そして、これ以外のデータ、たとえば「発注データ」というのを「発注データ作成」と「発注実行」でアクセスしていたとすると、このデータは、親プロセス「自動発注」以外の、他の親プロセス（内のプロセス）からアクセスされることはないということです。
（「発注量算定」は「発注データ」にアクセスするかもしれないが、他親プロセスの「注文入力」がアクセスすることはない。

---

■これをＲＤＢで表現するには

まず、プロセステーブルに親プロセスＩＤというのを持ちます。

プロセステーブル：プロセスＩＤ，プロセス名,親プロセスＩＤ

先ほどの例でいうと、
「発注量算定」「発注データ作成」「発注実行」の親プロセスが「自動発注」になります。
なので、データはこんな感じ

プロセスＩＤ，プロセス名,親プロセスＩＤ
　　　　　：
3,自動発注,0
　　　　　：
28,発注量算定,3
29,発注データ作成,3
30,発注実行,3

このとき、データフローテーブルが
10010,3,3003,メーカー
10011,6001,3,注残データ
10011,6002,3,在庫情報

とあったら、

XXXXX,○,3003,******
XXXXX,6001,○,******
XXXXX,6002,○,******

○は、3の自動発注の子である、28,29,30のいずれか
(XXXXX,*****は任意）
となる３種類のレコードが、データフローテーブルにかならず１件は存在する
（１種類１件、最低３種類３件）存在するということになります。

このエラーチェックが出来ます。

---

ただし、これ、若干の問題があります。
それについては、次回に書きます。

Wikipediaのデザインパターンの説明なんだけど・・・

デザインパターンについて書こうと思って気がついたんだけど、

Ｗｉｋｉｐｅｄｉａのデザインパターン (ソフトウェア)

について、Proxy パターンの説明で
（以下斜体は上記リンク先、Wikipediaのデザインパターンより引用：2009/8/21 15:30現在）


Proxy パターン
共通のインタフェースをもつインスタンスを内包し、利用者からのアクセスを代理する。Wrapperとも呼ばれる。


って書いてあるんだけど、Wrapper（ラッパー）は、普通、Ａｄａｐｔｅｒパターンに対していう言葉でないかい？

第3回：AdapterパターンとFactory Methodパターンの事例
http://thinkit.jp/article/933/1/

など・・・

そうでないの？？

UML等各種ダイアグラムのエラーチェック体系化（その１９：ＤＦＤ その１）

シリーズ「UML等各種ダイアグラムのエラーチェック体系化」です。

　現在「いろんなダイアグラムをＲＤＢにいれよう！」化計画、
　をやっていて、クラス図、ＥＲ図を入れました。

　今回は、ＤＦＤ　その１回目です

　なお、ここで書いたとおり、いままでのまとめは

こちら
システム開発における「最小単位」とその連結法
http://www.geocities.jp/xmldtp/index_system.htm

---

■ＤＦＤとは

　ＤＦＤは、データフローダイアグラムで、構造化手法が利用されていたときによく使われていた図です。
　こんなかんじ。
http://itpro.nikkeibp.co.jp/article/COLUMN/20080619/308620/zu3s.jpg

　システムを開発する場合、いろんな業務、つまりプロセス（処理）があるわけですが、その処理を楕円で書き、
その処理で使うデータをデータストアとして書きます。実際には、ＤＢのテーブルなど。
　そして、そのデータの発生源となる人等や、データを受け取る（＝吸収）人等を、四角いデータの発生、吸収であらわします。
　そして、プロセスが使うデータを、線で結び（データが流れていくほうに矢印を書きます）、データフローと呼びます。
　このデータフローには、どのようなデータが流れているかの情報も書かれます。

　つまり、まとめると、以下のもので構成されています。

データの発生・吸収：吸収・発生元名
プロセス：プロセス名
データフロー：向き、データ名
データストア：データストア名

---

■ＲＤＢに入れると、

データフローが、アーク（エッジ）になり、プロセス、データストア、データの発生・吸収がノードになります。
したがって、こんなかんじ

プロセステーブル：プロセスＩＤ，プロセス名
データ発生・吸収テーブル：発生吸収ＩＤ,元名
データストアテーブル：データストアＩＤ，データストア名
データフロー：データフローＩＤ、元データＩＤ，先データＩＤ、フロー情報内容

なお、
　　プロセスＩＤは１～３０００、
　　発生吸収ＩＤは、３００１～６０００、
　　データストアは６００１～９９９９、
　　データフローＩＤは１００００以上
など、ＩＤの値を見れば種別がわかるようにしておき、
データフローの元データＩＤ、先データＩＤは、プロセスでも、発生吸収でもデータストアでも、どれでも入れられるようにしておきます。

---

ってなところでどうでしょう・・・
（次回に続く）

０が入力されるまで数字を受け取り、受け取った数字をソートする。４行で記述するには？

ただしＪａｖａ。４行は、メソッド内の処理が４行。

回答例。

import java.io.*;
import java.util.*;

class Sample1 {
	public static void main(String args[])
	{
		Scanner sc = new Scanner(System.in);
		TreeSet ts = new TreeSet();
		for(int i = sc.nextInt() ; i != 0 ; ts.add(i),i = sc.nextInt());
		for(Iterator ir = ts.iterator() ; ir.hasNext() ; System.out.println(ir.next()));
	}
}

薄型PS3、HDD120GB搭載で29980円・・アナログテレビつければ・・・

ここの痛いニュース
SCE、薄型PS3を発表。HDD120GB搭載で29980円…9月の第1週に発売
http://blog.livedoor.jp/dqnplus/archives/1293993.html

ブラウザついて、ネットが出来るわけでしょ・・・で、２９８００円。
ゲームやんないんだけど、安いなあ・・・

地デジにしたら、アナログテレビって、いっぱい余るんだよねえ。。
じゃあ、そのテレビに、キーボードつけたら、
これ、企業向けによかったりして・・・（＾＾；）

Stateパターンのどこがすごいのか、感心されたので、書いてみる

　デザインパターンで状態を示すStateパターンっていうのがある。
　これを説明して、「Stateパターン、すげー（＠＿＠！）」
って感心されたんで、書いておいて見る。

---

■そもそも、Stateパターンとは？

状態を示す（抽象的な）スーパークラスStateをつくり、
（具体的な）各状態は、それを継承した、各状態クラスを作ります。

例：Stateクラスには、executeがある

public interface State {
	public State execute(State sts);
}

状態Ａ：StateAクラスでは、実行executeで処理Ａを行い、次に処理Ｂに行くため、実行Ｂを行う

public class StateA implements State{
	/*
	 * コンストラクタ
	 */
	StateA(State sts)
	{
		//	ここで初期値を設定する
		//	引数をStateB,StateC等、具体的にして、
		//	設定してもいい
	}
	
	public State execute(State sts)
	{
		//	処理Ａの実行（ここでは出力のみ）
		System.out.println("処理Ａ実行したとする");
		
		//	かえる（次の処理Ｂセット）
		return new StateB(this);
	}

}

状態Ｂ：StateBクラスでは、実行executeで処理Ｂを行い、ここで処理を終了する。

public class StateB  implements State{
	/*
	 * コンストラクタ
	 */
	StateB(State sts)
	{
		//	ここで初期値を設定する
		//	引数をStateA,StateC等、具体的にして、
		//	設定してもいい
	}
	
	public State execute(State sts)
	{
		//	処理Ｂの実行（ここでは出力のみ）
		System.out.println("処理Ｂ実行したとする");
		
		//	かえる(null＝終了）
		return null;
	}
}

こうすると、以下のように、ステータスに応じた処理をします。
＜＜呼び出しmain部分＞＞

public class Main {
	public static void main(String args[])
	{
		//	開始点は状態Ａ
		State sts = new StateA(null);
		//	次の状態がnullになるまで
		while(sts != null)
		{
			//	実行する
			sts = sts.execute(sts);
		}
	}
}

この結果は、当然

処理Ａ実行したとする
処理Ｂ実行したとする

となる。

---

■ここで、おさえておきたいこと

これをもし、ふつーに、状態遷移の変数で書くことも出来る。
こんなかんじ？

public class Main {
	public static void main(String args[])
	{
		int stsno = 1;
		State sts = null;
		//	次の状態がnullになるまで
		while(stsno != 0)
		{
			//	実行する
			switch(stsno)
			{
			case	1:
				sts = new StateA(null).execute(sts);
				stsno	=	2;
				break;
			case	2:
				sts = new StateB(sts).execute(sts);
				stsno	=	0;
				break;
			}
		}
		
	}
}

となる。
このように、状態遷移の番号を使って、switch文で分岐するっていうことは、
イベントドリブンの場合の普通の書き方だ（たとえばＢＲＥＷとか）

---

■Stateパターンのどこがすごいのか

で、ここで、

ステータスＣを追加し、
Ａが終了したら、Ｃを実行した後、Ｂを実行することにする。

そうすると、Ｃを追加したんだから、Ｃを作らないといけないのはあたりまえ、

public class StateC implements State{
	/*
	 * コンストラクタ
	 */
	StateC(State sts)
	{
		//	ここで初期値を設定する
		//	引数をStateB,StateC等、具体的にして、
		//	設定してもいい
	}
	
	public State execute(State sts)
	{
		//	処理Ａの実行（ここでは出力のみ）
		System.out.println("処理Ｃ実行したとする");
		
		//	かえる
		return new StateB(this);
	}
}

呼び出すＡもＢからＣへ、変えないといけないのは、こりゃ、しょうがない

public class StateA implements State{
	/*
	 * コンストラクタ
	 */
	StateA(State sts)
	{
		//	ここで初期値を設定する
		//	引数をStateB,StateC等、具体的にして、
		//	設定してもいい
	}
	
	public State execute(State sts)
	{
		//	処理Ａの実行（ここでは出力のみ）
		System.out.println("処理Ａ実行したとする");
		
		//	かえる＝ここ、ＢからＣに変わった
		return new StateC(this);
	}

}

だけど、逆に言うと、ここしか、かわらないのだ！
状態Ｂも、呼び出し元Ｍａｉｎも、何も変えなくても動く

処理Ａ実行したとする
処理Ｃ実行したとする
処理Ｂ実行したとする

ところが、状態遷移の変数を使って行う場合だと、Ｍａｉｎを変えないといけない。

---

■具体的なケースでかんがえてみると・・・

ここで、今の話を具体的に考えてみる。
Ｍａｉｎのクラスをパッケージソフト、ＳｔａｔｅＡ，Ｂ，Ｃをカスタマイズ部分だとする。


状態遷移の変数を使う方法の場合は、カスタマイズするたびに状態遷移が増えるから、
パッケージソフト（Ｍａｉｎ部分）を修正しないといけない。
ということは、状態遷移すべてまとまらないと、コーディングできないのだ！
そのうえ、Ｍａｉｎ部分を修正してくれるまで、ＳｔａｔｅＣのテストはできない。
・・・っていうか、カスタマイズのためにパッケージソフト本体を直すのは最悪だ（＞＿＜！）


一方、Ｓｔａｔｅパターンのほうは、Ｍａｉｎは、一切、手が入ってない。
ＳｔａｔｅＡとＳｔａｔｅＣのカスタマイズ部分だけだ。
状態遷移図を書いた場合、変更箇所前後だけを治せばいいので、わかりやすい。
自分の呼び出し前後側だけ、対応してくれれば、全体は、どーでもよく、切り替え可能だ。


このＳｔａｔｅパターンのように、状態をクラス化し、それを抽象的に操作してしまえば、
まだ見ぬ状態が出来たとしても、本体を変えることなくカスタマイズができる。
この、「本体を変えないでいい」というところが、すごかったりする。

---

ってことで、「へー（＠＿＠！）」と感心された・・・

デザインパターンの説明って、なにが、どーすごいのか、わかんない例で書いているから、
いまいち、すごさが伝わらないのよね・・・

”ゴールドマン自己「０．０３秒」で出し抜く”なんだけど・・・

これ、儲かるかもしれないけど、リスクもでかいよねえ・・

ちょっと前になるけど、日本証券新聞８月１２日号（駅売りだと、１１日夕方に東京駅、新宿駅などに売り出す）１面ひだり、

米国マーケットで衝撃
ゴールドマン自己「０．０３秒」で出し抜く
NYタイムズ紙がきっかけ

の記事。

要約すると、
（１）ゴールドマンは、NASDAQなどから、一定の料金を払う見返りとして、
　　　０．０３秒早く、株価気配値情報を受け取っている

（２）ゴールドマンは、この差を利用して、高性能コンピューターにより
　　　自己勘定取引により、巨額の利益を上げている
　　→これを「ハイフリークエンシー・トレーディング」（高頻度取引）
　　　といい、これで利益をあげていることは、ゴールドマンも認めて
　　　いる

でも、０．０３秒早いってことは、ほかより、０．０３秒分計算が早いだけでしょ？
（０．０３秒で計算するという意味とは限らない。たとえ、計算に５秒かかっても、
　ほかの会社も５秒かかるなら、０．０３秒分、ゴールドマンが速くなる）
いくら、「高度なイベントドリブン型システムを組んでいる」って言ったって、
たぶん、１注文分早いだけだよねえ。

　１注文分でかなり儲けるってことだから（ふつうは危険なので
何回にも分けるけど）、これ、かなりリスクのある方法なのでは？

　自己勘定だからできるのであって、顧客の委託をうけてやるような話ではないな。。
。。。たぶん

UML等各種ダイアグラムのエラーチェック体系化（その１８：関連のグループ：概念拡張）

　シリーズ「UML等各種ダイアグラムのエラーチェック体系化」です。

　現在「いろんなダイアグラムをＲＤＢにいれよう！」化計画、
　をやっていて、クラス図、ＥＲ図を入れました。

　今回は、クラス図をいれたときに書いた

グループIDについては、別の機会に詳しく説明します。

についてです

　なお、ここで書いたとおり、いままでのまとめは

こちら
システム開発における「最小単位」とその連結法
http://www.geocities.jp/xmldtp/index_system.htm
（更新しました！！１７回までの分が入ってます）

---

■リレーション（アーク）のグループＩＤ

　クラス図の関連等は、リレーション（エッジ、アーク）で示しています。
　リレーション（エッジ、アーク）は、本来２つのノードを結ぶものです。

　しかし、ここの図
拡大画像 | 【連載】ゼロから始めるUMLモデリング講座 (6) クラス図による物・事のモ……
http://journal.mycom.co.jp/photo/series/UML_zero/006/images/001l.jpg

にあるように、（コンポジションは、そのような関係になっていますが）、
制約は、２つのアークを結んだものになっていますし、
汎用（汎化）は、２つ以上（ここでは３つ）が１つに結びついています。

そのようなものも、２つの関係にばらして考えてもいいのですが、めんどっちいので、
以下のような拡張をしてしまいます。

＜＜拡張１＞＞
　リレーション（エッジ、アーク）は、本来２つのノード「または、リレーション」を結ぶものです。
　２つのリレーションを結ぶこともあります。

＜＜拡張２＞＞
　リレーション（エッジ、アーク）グループというものを考えます。
　これは、２つ以上のリレーションが結びついているものです。
　（図の（汎化）にあたります）
　リレーショングループは、１テーブルをもち、リレーショングループＩＤを持つことにします。

＜＜拡張３＞＞
リレーションはテーブルで、項目として、
元ノードＩＤ，先ノードＩＤを持っていましたが、
元ノード・エッジ・グループＩＤ，先ノード・エッジ・グループＩＤ
をもつものとします。

　そうすると、ノードＩＤ，エッジＩＤ，リレーショングループＩＤのいずれかが入ることになりますが、
この番号が重複しないように、
　　ノードＩＤは、１から１０００００まで、
　　エッジＩＤは１００００１から３０００００まで、
　　リレーショングループＩＤは、３００００１から５０００００まで
のように、値の範囲わけがあるものとします。

こうすれば、値を見るだけで、種別がわかります。

---

■ということは、

クラス図の最後で、
関連テーブル（関連ID,元クラス・関連ID,先クラス・関連ID,種別、
　　　　　　　元カーディナリティ、先カーディナリティ、
　　　　　　　（関連名、元関連名、先関連名））
とし、「元クラス・関連ID」と「先クラス・関連ID」には、

　　クラスのＩＤ、
　　関連のＩＤ（制約のとき）、
　　関連グループのＩＤ（汎化のとき）

が、入るようにして、それぞれのＩＤは、

　　クラスのＩＤが１から１０００００
　　関連のＩＤが１００００１から２０００００
　　関連グループのＩＤが２００００１から３０００００

までとして、ＩＤ番号で、何と結びついているか見分けられるようにして、
さらに、

関連グループテーブル
（関連グループテーブルＩＤ）

を別に作ることとします。

---

以上です。次回から、ちゃんと、ダイアログ作成に戻ります。

Strutsの要素技術の基本的構造（その１ 概要）

Strutsの要素技術の基本的構造をまとめてみる

---

■まずは概要

大きく「Strutsを基本的に構成するもの」と＋α技術がある。

○Strutsを基本的に構成するもの
　　　Ａｃｔｉｏｎ
　　　ＡｃｔｉｏｎＦｏｒｍ
　　　Ｓｔｒｕｔｓ－ｃｏｎｆｉｇ．ｘｍｌ
　　　ＪＳＰファイル

　　↓

○＋α
　　入力に関する＋α
　　　　複数選択に関して
　　　　ActionFormのreset()
　　　　エラーチェックに関して
　　　　　　Validator()
　　　　　　Validate()
　　　　　　　→メッセージリソースの利用
　　　　　　Javascriptの利用
　　　　一画面に複数ボタンある場合
　　　　　　Javascriptの利用
　　　　　　LookupDispatchAction
　　　　　　　→メッセージリソースの利用
　　　　　　実は、submitのnameを変えて、valueが入ってるかで・・
　　　　二度押し防止
　　　　　　トランザクショントークン
　　　　　　Javascriptの利用
　　　　メッセージの国際化
　　　　　　メッセージリソースの利用
　　　　DynaActionForm

　　出力に関する＋α
　　　　エラー画面の共通化
　　　　　　globalforward
　　　　繰り返し項目
　　　　　　logic:iterateタグ
　　　　条件
　　　　　　logic:equal,emptyタグなど
　　　　Javascriptによる画面セット

---

　おおざっぱには、こんなかんじ？？
　ここでは、もっと細かいこと書いてたけど・・・
　その２につづく・・

セキュリティのまとめ

セキュリティというと、脅威、脆弱性（＝セキュリティホール）が問題になる。
この関係は、以下のとおりだけど

脅威（どこにでもある、危険性）
　　　↓　　　　　　　　↓
　対　　　策　　　　　　○　（セキュリティの穴）
（問題起きない）　　　　｜　脆弱性（セキュリティホール）
　　　　　　　　　　　　↓
　　　　　　　　　　　　Ｘ　問題発生（インシデント）
　　　　　　　　　　　情報資産

つまり、脅威はどこにでもあって、それに対策を立てていればＯＫだけど、対策してない脆弱性があったとき、
その脆弱性をもとに情報資産に損害を与えると、問題発生＝インシデントとなる。

---

ってことは、セキュリティをまとめるとき

脅威
　　それに対する対策
　　対策しない脆弱性

という感じでまとめると、わかりそう。

---

ってことでまとめてみる

■脅威：コンピューターウィルス
　　対策：アンチウィルスソフトをいれる
　　脆弱性：アンチウィルスソフトを入れていない
　　　　　　定義ファイルが更新されていない
　　　　　　０－Ｄａｙ　Ａｔｔａｃｋ（更新前に攻撃される）

■脅威：不正アクセス
　　対策：ファイヤーウォール（ネットワーク、パーソナル）
　　　　　ポートを閉じる
　　　　　アクセス権の設定
　　脆弱性：デフォルトのまま使っている

　　関連事項：不正アクセス禁止法

■脅威：大量アクセス（Ｄｏｓ，ＤＤｏｓ）
　　対策：ログを分析し、特定の相手、地域からDos攻撃されてたら、
　　　　　アクセスをきる
　　　　　あらかじめ、負荷分散しておく
　　　　　　→ＣＤＮ（アカマイなど）

■脅威：情報漏えい
　　対策：不正アクセス禁止
　　　　　認証（パスワード、生体認証、トークン、ワンタイムパスワード）
　　　　　暗号化
　　脆弱性：パスワード漏洩
　　　　　　　→パスワードクラッキング、ソーシャルエンジニアリング
　　　　　　　　簡単に推測できるパスワード、パスワードを変えない
　　　　　　　　フィッシング

　　関連事項：個人情報保護法→Ｐマーク
　　　　　　　PCIDSS（カード会社のセキュリティ管理）
　　　　　　　不正競争防止法

　　　　　　（暗号化）公開鍵暗号ＲＳＡ
　　　　　　（メール）Ｓ／ＭＩＭＥ，ＰＧＰ　　　　　　　

■脅威：成りすまし
　　対策：認証
　　　　　デジタル署名

■脅威：盗聴
　　対策：ＶＰＮ（IPsec,SSL)

---

こんなかんじ

宇宙人にメッセージを、ケータイやWebから送れる？

soliveでなっちゃんが言ってて知った。

ここのニュース
地球外生命体への「携帯」メッセージ、オーストラリアから発信
http://headlines.yahoo.co.jp/hl?a=20090813-00000094-reu-int
によると（以下斜体は上記サイトより引用）

地球に似ているとされ、生命体の存在も推測される太陽系外惑星「グリーゼ５８１ｄ」に対し、携帯電話で送受信するような簡易メッセージを送るプロジェクトがオーストラリアで始動した。


おお、でも、ケータイで、オーストラリアじゃ、むりでは・・・
と思っている、そこのあなた！

プロジェクトのウェブサイト（http://hellofromearth.net）では、同惑星に送る１６０文字以内のテキストメッセージを、８月２４日まで募集している。


たしかに、http://hellofromearth.netに登録するところはあるけど、当然、英語で・・・というもののようだ。

「Office 2010」を携帯電話に搭載する可能性も

ここのニュース
MS、ノキアと新たに提携か--「Office 2010」を携帯電話に搭載する可能性も
http://japan.cnet.com/mobile/story/0,3800078151,20398208,00.htm
（以下斜体は上記サイトより引用）

米CNET Newsが入手した情報によれば、Microsoftは米国時間8月12日、新たにNokiaと提携して、Nokiaの携帯電話に「Office」ソフトウェアを搭載していくサポートを提供する発表を行う予定であるという


ほー、でも、ケータイブラウザといえば、
ＮｅｔＦｒｏｎｔだけど、いま、ＮｅｔＦｒｏｎｔって、
NetFront Document Viewerで、Ｏｆｆｉｃｅ見れるそうなので、
あと、書き込みとかができるようになれば、
そっちのほうが、各ケータイ端末会社が対応するより、
早くね？