たとえば光制御型素子を使ってトランジスタと同じことが出来たら、コンピューターは・・？

　結局、クラウドにしてもデータセンターにしても、コンピュータの現状の技術で議論してるけど、
　これ、技術的にブレークスルーが起こった場合、どーなんでしょーねー。

　たとえば、今って、半導体を使った集積回路がベースとなって、CPUとかが出来ているわけじゃないですか。それに伴い、熱の問題とか、電気の問題とかあり、その観点から、巨大データセンターの是非が論じられたりします。

　だけど・・・ですよ、

　光制御型素子ってあるじゃないですか？
　この手のものって、量子コンピューターへ応用しようとしているから、ずっと先の話になっているけど、

　そうじゃなくって、今のトランジスタが、（エミッタ－コレクタ）電流を（ベース）電流で制御しているように（C-MOSのようなFETの場合、電圧で制御するけど）、

　光を光で制御するって素子を作って、
　　　トランジスタやFETを置き換える

という程度の革新を行うのであれば、量子コンピューターほど、非現実的な話じゃないんじゃないか？

　で、もし、そー言うのが出てくれば、今よりも処理スピードが速かったり、熱の問題が少なかったりするんじゃないか？

　そして、そのようなコンピューターが出た場合、今とは処理形態が違ってくるんじゃないか（たとえば、光ファイバを使って、光でサーバーに入力、光のまま処理、結果を光ファイバーに出し、クライアント側で光を電気に変換する）

　なので、そんなことが起こってくれば、今のコンピュータの現状の技術での議論って、意味なくなってくるよねえ・・・

　問題は、そんな光技術のコンピューターへの応用は、いつ起こるかってことだと思う。

　ウィリアムのいたずらは、もうじきかな？という気がしてるんですけどねえ・・・
　政府とか、こーいう研究に力を入れないんですかねえ？

　ま、まずは、コンピューターより、ルーターにおいて、光信号を電気信号に変えない光デバイスの話があって、その次に、それを応用して、コンピューターへという流れだとは思うけどね！

JavaBeansと多態性を使って、入出力デバイスを柔軟に切り替える

　まえに、


オブジェクト指向で開発するという場合、多態性を利用して、はじめのうちは、メディアをはっきりさせず、入力、出力を共通的なインターフェースを使って設計しておき、最終段階で実際の入出力メディアを決めるという開発方法もありえます。


と書いたけど、実際に、どうやるかを書いていなかったので、ちょっと書いてみる。

---

■まず、各入出力デバイスのクラスを作るんだけど・・・

　Readable,Writableというインターフェースを用意する。

interface Readable
{
	int	open(String name);
	int	read(byte[] str);
	int	close();
	String	get(String key);
	void	set(String key,String value);
}

interface Writable
{
	int	open(String name);
	int	write(byte[] str);
	int	close();
	String	get(String key);
	void	set(String key,String value);
}

各入出力メディアでは、これらを継承して、入出力メディアクラスを作成する。

たとえば、データベースの場合

public class DbAccess implements Readerble,Writeable
{
	/*
	 * SQLマップ：openしたとき、名前とSQLの対応表
	 */
	public HashMap sqlMap = null;

	//	このほか、DBアクセスに必要な変数

	public static initialize()
	{
		//	DBの環境設定を読み込んでなければ、
		//	DBの環境設定を読み込む
		//	これでSQLマップと
		//	接続に必要な変数は設定される
	}

	public DbAccess()
	{
		//	initialize()を実行
	}

	public	int	open(String name)
	{
		//	nameをもとに実行するSQLを選択する
		//	接続に必要な変数を利用し、接続する
	}

	int	write(byte[] str)
	{
		//	たぶん、タブ区切りみたいな形式で来るので、
		//	それを分解して、openのときに選択された
		//	SQLに埋め込み（PrepareStatementを利用してる場合、
		//	そのまま値を設定し）
		//	DB書き出し実行
	}

	int	read(byte[] str)
	{
		//	リードバッファにデータがない場合
		//	　　openのときに選択されたSQLを実行
		//	　　結果をタブ区切り（セルの区切りはタブ、レコード区切りは改行）
		//	　　にして、str分データセットし、のこりをリードバッファへ
		//	リードバッファにデータがある場合
		//	　　リードバッファからstr分データセットし、
		//	　　のこりをリードバッファへ
	}

	int	close();
	{
		//	接続終了
	}

	String	get(String key)
	{
		//	keyで指定された変数を返す
		//	指定された変数がなければなにもしない
		//	StringでないものはtoString型等を返す

	}
	void	set(String key,String value)
	{
		//	keyで指定された変数を設定する
		//	指定された変数がなければなにもしない
		//	設定ファイルの形式で設定＝Stringのはず
	}
}

のように作成する（もちろん、コメントをそのようにプログラムした上で）。

---

■各メディアごとの設定ファイル

上記のコメントにあるように、そーすると、DBの環境設定が必要になる。
そのDBの環境設定で、

・openのときに指定された名前に対するSQL
　（writeでセットするようなところは$1とかにしておく）

・そのほか接続に必要な変数（ユーザー名、パスワード、接続URLなど）

をXMLで定義する。

このほかの入出力メディアでも、設定ファイルを用意し、そのメディア固有の情報
（ファイルの場合のファイルパスとか、メールの場合の送り先、POPサーバーなど）
は、それぞれのメディアの設定ファイルを用意する。

　なお、設定ファイルは静的な情報となるので、動的に情報を変えたい場合は、setを使う。

　たとえば、DBのSELECT文などで、USER_IDを動的に設定したい場合、
　
　　　設定ファイルでは、名前はUSER_SELECT、
　　 SQLは SELECT * FROM USER WHERE USER_ID=$1

　とかにしておき、プログラム中で、set("$1","1235");のようにIDをセットする。

　大幅に変えたいときは、set("WHERE","USER_NAME='Tom'");のように、WHERE句全体を変えられる
なんていうのもあるといいかもしれない。

　ただ、あまり多用しないようにする。

---

■入出力ごとのjavaBeansを用意しておき・・・

そしたら、こんどは入出力ごとのJavaBeansを用意しておき、
とりあえず、まだ、メディアがきまっていなかったら、

Readerble,Writeable

でコーディングしておき、メディアがきまったら、そのメディアにする

public class zyutyu {
	DbAccess  acc = new DbAccess();

	//	フィールド変数

	//	セッター

	//	ゲッター

	public int read()
	{
		// 	accをオープンして、
		//	acc.read()して
		//	読み込んだ内容をセットして
		//	acc.close()する
	}

	public int write()
	{
		// 	accをオープンして、
		//	beanの内容をレコード化し
		//	acc.write(そのレコード)して
		//	acc.close()する
	}

}

こうすると、すべてのメディアが基本的に

Openして
readして結果をタブ区切りで受け取り
beanをwriteして
クローズする

という形になっているので、たとえば、DB書き出しをメールしたりする場合でも、
DbAccessをMailAccessにかえればいいだけになる。

動的に変えたい場合は、setを利用するが、メディアを切り替えた場合、
前のメディア用のsetが残っていても、新しいメディアでそのsetのキーのものを
使っていなければ、何もしないだけなので、問題がおきにくい
（でも、そのような差異があるため、set,getは多用しないほうがいい）

---

■ちなみに

public static initialize()としたのは、設定ファイル読み込みを、
はじめてアクセスしたときにされてしまうと、
その「はじめてのアクセス」のときに遅れてしまうので、

システムの起動時に、
DbAccess.initialize();
のように書いて、起動時に設定ファイルを読み込ませるためです。

---

何でこんなことを書いたかは、もちょっとするとわかる・・・かも？？


　

Japan Linux Symposium 基調講演、トーバスルさんの内容

で、昨日のJapan Linux Symposium　基調講演での、トーバスルさんの話の内容

（メモしてる所だけなので、聞き洩らしているところ、勘違いしてる所もあるかも。
　ここの写真のとおり、Q and Aの形式で、トーバルスさんが語る）

・自分（＝トーバルスさん）がLinuxを開発した時、成功を意識していない。
　Hobbyとしてやった

・開発プロセスとコードはうまくいくかを考えている

・Linuxの開発は、トーバルスさんと一緒に１０～１５人くらいが開発していて
　（このメンバには日本人はいない）それぞれに、また１０～１５人くらいの
　人がいて・・・みたいなかんじ

・対立はめったにおきない。対立が多発するときは、開発プロセスが問題

・開発モデル：エンベットと協力していく体制
　（ごめん、メモがここでおわってて、そういう体制になってるのか、
　　そういう体制を作りたいと言ったのか、はっきりしない）

・デバイスサポート：苦情は残っているかもしれない。
　ただ、今は開発方法が違っていて、昔はトーバルスさんのほうが開発してたけど
　今は多くの企業がドライバを書いている

・Linuxの成功：
　複数の要因がある。
　ビジョンを持っていたわけではなく、新しいアイデア、バラエティを受け入れた

・フリーソフトウエア運動とのバランス
　オープン化がもっともよい
　Linuxは、商業界にとって、参加しやすい
　　（？メモが汚くて・・・他のOSSに比べ、Linuxは、ビジネスの人が入りやすいってこと）
　コマーシャルVSオープンソースという対立があるわけではない

・Linuxの開発プロセス＝有機的プロセス
　初めから開発を考えたわけではない
　プログラマが変異、進化する

・もし、第二のトーバルスがでるとして、アドバイスは？
　OSは、やめてください（＾＾）ｖ
　深く関心が持てるものを、１日１０時間づつ続けられれば成功する。
　他の人に役に立てばいいけど、そうでなくても、それだけすれば、成功する


ってなかんじだったかな