AJAXベースの開発フレームワーク、マスカットをお勉強中、特にサーバサイドの実装PHP編を。。。

AJAXベースのオープンソースな開発フレームワーク、マスカットっていうのがありますよね。

ここ
マスカット プロジェクト
http://maskat.sourceforge.jp/index.php?FrontPage

現在、お勉強中。
そこのチュートリアルに
サーバサイドの実装　PHP編
http://maskat.sourceforge.jp/index.php?Tutorial%2FPHP
ってあるので、サーバー側をＰＨＰで作って、クライアントサイドで動く部分をＡＪＡＸでやるっていうことができるのかな？とくに、そこをただいま勉強中。

　そのうち、お勉強内容をご披露。。。できるかなあ（＾＾；）

3Dキャラクター作成ソフト「Poser 5 日本語版」が無料になるらしい。ただし１９日正午まで

ここのブログ
3Dキャラクター作成ソフト「Poser 5 日本語版」が無料に
http://gigazine.net/index.php?/news/comments/20061011_poser5_jp/
によると、ぽざまんなんかで使っている有名な３Ｄ作成ソフト、Poserの日本語版が、無料になるそうな。。。

　１９日正午まで。
　ダウンロード先や、そこからの手順は、上記のブログに書いてあるみたい

　ただし、ウィリアムのいたずらは、３Ｄ作成ソフトなんてもらっても、うまく作れないので、ダウンロードはしません。なので、本当に上記の手順でやればいいのかどうかとか、本当に無料なのかどうか等については、一切確かめてません（知り合いに教えるためのメモで、この記事を書いております）。

　なので、実際にやってみる人は、自己責任でやってください。
　なにか、不都合があっても、ウィリアムのいたずらは、一切知りませんので。。。（＾＾；）

Javaの画面表示－その２：一般的な本に載っているＡＷＴのやり方と問題点

　さて、今日は、Javaの画面表示について、実際にＡＷＴでやってみるわけなのですが、まず、よく本に載っている形で書いてみて、その場合の方法と、問題点について書いてみたいと思います。

---

■仕様
　ＢＲＥＷシリーズで作っている第一画面、つまり、これと同じ画面をつくります。ただし、カーソル制御はいれないで、「打ち終わったよ」ボタンがクリックされたら、終了します。

---

■ソース
　これを、一般的な本にあるようなやり方で、作ってみると、こんなかんじ

import java.awt.*;
import java.awt.event.*;

public class test{

	/*
	 * 	メイン処理
	 */
	public static void main(String[] args) 
	{
		Frame 		f;
		Button		b1;
		Button		b2;
		TextArea	t1;

		//	フレームを作成する		
		f = new Frame("test");
		f.setSize(240,320);
		f.setLayout(null);

		//	アクションを作成する
		allActionListener al = new allActionListener();

		//	ラベル
		Label l1 = new Label("早うちの練習");
		l1.setLocation(10,30);
		l1.setSize(100,30);
		f.add(l1);

		Label l2 = new Label("これは、練習文です。");
		l2.setLocation(10,120);
		l2.setSize(150,30);
		f.add(l2);

		Label l3 = new Label("以下の文を打とう！");
		l3.setLocation(10,70);
		l3.setSize(100,30);
		f.add(l3);

		//	テキスト
		t1 = new TextArea();
		t1.setLocation(10,160);
		t1.setSize(150,80);
		f.add(t1);
		
		//	ボタン作成		
		b1 = new Button("挑戦する");
		b1.setLocation(120,70);
		b1.setSize(100,30);
		b1.addActionListener(al);
		f.add(b1);

		//	ボタン作成		
		b2 = new Button("打ち終わった!");
		b2.setLocation(10,250);
		b2.setSize(100,30);
		b2.addActionListener(al);
		f.add(b2);

		f.setVisible(true);
	}
	
	/*
	 * 	イベントリスナー
	 */
	private static class allActionListener
				 implements ActionListener
	{

		public void actionPerformed(ActionEvent e)
		{
			Object o = e.getSource();
			System.out.println(e.getActionCommand());

			if ( e.getActionCommand().equals("打ち終わった!")
					 == true)
			{
				System.exit(0);
			}
		}
	}
}

---

■説明

　ＡＷＴを使う場合、

　まず、フレームを生成します。
　レイアウトマネージャーは使う場合はそのレイアウトマネージャーを生成してセットし、
　使わない場合はnullをセットします。
　今回はnullをセット（＝使わない）しています。
　この場合は、Locationとsizeで設定したとおりになります。

　そのあとで、各部品（ラベルとか、ボタンとか）を作成して、それをフレームにaddします。
　このとき、レイアウトを指定してないので、各部品はすべて、setLocation、setSizeして、大きさを指定してください。
　それと、ボタンに関しては、後述するイベント処理用の内部クラスを、addActionListenerします。
　そして最後に、f.setVisible(true);して表示します。


　さらに、このクラス内に、もうひとつクラスをつくって（内部クラス）イベントが飛んできたときの処理を書きます。このクラスがallActionListenerで、アクションリスナーをインプリメントしています。

　ということは、アクションリスナーにあるメソッドを実装しないといけません。
　それが、actionPerformedで、ここで、「打ち終わったよ！」がクリックされたら、終了するように設定しています。

---

■こうすると、何が問題なのか。。

　よく、本には、このようにmainのところに、画面を書いちゃうケースが多いんですけど、
　こうすると、複数画面を出すときにこまります。

　他の画面から、ある項目に対して、値をセットしたくても、その部品は、mainメソッドの中に書かれているだけなので、値をセットできません。

　じゃあ、mainメソッドの外に出してということで、
　　　　Frame　　　　f;
　　　　Button　　　　b1;
　　　　Button　　　　b2;
　　　　TextArea　　　t1;

　　　　public static void main(String[] args)
　　　　{
　　　　　　：
　　　　　　：

　と書いてしまうと、エラーになります。
　staticメソッド内で使うので、上記の変数は、
　　　　static　Frame　　　　f;
　　　　static　Button　　　　b1;
　　　　static　Button　　　　b2;
　　　　static　TextArea　　　t1;
　にしないと、エラーになります。

　でも、こうしてしまうと、今度は２つ以上、同じクラスのウィンドウを開いたとき、staticなので、あとのオブジェクトに変数が変わってしまいます（staticはクラスで１つ）。

　あちゃー（＞＜）。
　この方式では、複数画面のときは、うまくいかなさそうです。

---

■どうしたらよいか

　なので、
・メイン部分があるクラスと
・ウィンドウ１つ分のクラス
に分ける必要があります。

　つまりＢＲＥＷのように全体アプリ用（クラス）と、各画面用（クラス）の２種類を作り、全体アプリからは初期画面だけを呼び出し、画面はそれぞれクラスとして作成するというかんじです。

　次回は、その例を示します。

BREWで画面間メモリ一括管理（その２－アプリ全体領域）

　きのうからの 「BREWで画面間メモリ一括管理」つまり、ＢＲＥＷでカオル姫方式、その２回目は、全体のアプリにおける共通領域のかかわりについて説明します。

---

■きょうの概要

　いままで、画面間をまたいで受け渡す引数は、その領域を全体のアプリ領域の構造体のところにとっていました（ここのsei_ritu、byo、username）。

　でも、これだと、受け渡し変数が増えるたびに修正しないといけないし、
　全体のアプリを直してから出ないと、各画面のソースをコミットすることができません
　　→コミットしてしまうと、全体アプリ領域には、その変数がないので、コンパイルエラー
　　　になってしまう。

　そこで、全体アプリには、IKHMap　*pMap;という、連想配列を入れる（ハッシュマップもどき）領域をとっておきます。

　こうすれば、各画面において、変数をセットしたり、変更する場合は、この連想配列に、値とキーをputすればいいし、必要な画面で、キーをもとにgetすれば、値は取り出せます。
　今回は、この連想配列をとるため、全体のアプリでなにをすればいいかを書きます。
　なお、全体でIKHMap　*pMapというのをとっておいて、そこに各画面で、putしたりgetしたりする方法を、「カオル姫方式」とこのブログでは呼んでいます。

---

■全体ヘッダでの対応　

これは、上記の概要にも書いたとおり、

// 共通領域
IKHMap　*pMap;

を、構造体の中に宣言するだけです。
ここに、ソースがあります。

---

■全体アプリソースでの対応

●初期化（fukusu1_InitAppData）内
　この領域を、生成します。

　　　pMe->pMap　=　IKHMAP_Create(pMe->pIShell,pMe->pIDisplay);

　で、生成します。

　なお、このカオル姫方式は
　　・文字列を保持しておく
　　・あらゆる構造体を保持できるようにしておく
　の２種類あって、今回は「文字列を保持しておく」だけなので、この処理だけですが、
　今後「あらゆる構造体を保持できるようにしておく」には（これをカオル姫方式2ndと、このブログでは呼んでいます）、この初期化部分で

　・ユーザー定義した構造体を生成する場合に呼び出すべき関数と
　・ユーザー定義した構造体を解放する場合に呼び出すべき関数

をセットします。

●アプリ解放（fukusu1_FreeAppData）
　メモリをとったpMe->pMapがＮＵＬＬでなかったら、
　IKHMAP_Releaseを使って解放します。
　ここで、要素もすべて解放されます。カオル姫方式2ndでは、ユーザー定義した要素に関しては、その値は、「ユーザー定義した構造体を解放する場合に呼び出すべき関数」が呼び出されて、解放することになります。

●その他
　今回はありませんが、カオル姫方式2ndでは、
　・ユーザー定義した構造体を生成する場合に呼び出すべき関数と
　　　　→かりにこれをfukusu1_UserAreaMake(IKHUserStr *pMe);とします

　・ユーザー定義した構造体を解放する場合に呼び出すべき関数
　　　　→かりにこれをfukusu1_UserAreaFree(IKHUserStr *pMe);とします
　を作成してもらうことになります。

　仮に今、ユーザー定義構造体を
　　typedef struct _abc{
　　　　int a;
　　　　char buf[50];
　　}abc；

　だとすると、

void fukusu1_UserAreaMake(IKHUserStr *pMe)
{
　　　switch(pMe->kind)
　　　{
　　　case ITEMKIND_USER_ABC:
　　　　　pMe->area = (void *)MALLOC(sizeof(abc));
　　　　　break;
　　　case ITEMKIND_USER_EFG:
　　　　　:
　　　　　:
　　　}
}

void fukusu1_UserAreaFree(IKHUserStr *pMe)
{
　　　switch(pMe->kind)
　　　{
　　　case ITEMKIND_USER_ABC:
　　　　　FREEIF(pMe->area);
　　　　　break;
　　　case ITEMKIND_USER_EFG:
　　　　　:
　　　　　:
　　　}
}

みたいなかんじの関数を書き、これを、初期化のときにセットすることになります。
ただし、今回は、ここまでやりませんので、この関数はありません。

●ソースは
　ここにあります

---

　ということで、このシリーズの次回は、各画面における処理（領域を受け取って、画面間項目を設定、受け取る）について、書きたいと思います。

真暗でも化学物質を塗ればロボットは歩けるかも？という基礎研究をやった女子高生すら受験って？

　たとえば、真っ暗な場所でロボットを歩かせるということを考える。
　この場合、光は使えない。
　電波、つまりＲＦＩＤタグを使う場合、複数のＩＤタグを使って（ＧＰＳみたいに）位置を知ることは可能かもしれないが、かなり高精度の受信装置が必要だろう。。。。

　ところが、化学物質、たとえば、砂糖でもなんでもいいんだけど、そいつを、通り道に塗っておく。ロボットは、化学物質（例なら砂糖）を検知して、その上を歩けばいいことになる。

　つまり、真っ暗闇でも、化学物質を塗って、それを検知するシステムを作れば、ロボットはその上をあるいていける可能性がある。

---

　同様に、金属で密閉された箱の中に、何個入っているかっていうのを確認したい場合を考える。

　ＱＲコードは、箱の中に積み重なっている場合、見えないので使えない

　電波を使うＲＦＩＤは、金属の箱の中にあるものに対しては、電波が外へは、届きにくい。なので、箱の蓋を開けて、測っても正確に測れるかどうかは疑問。

　ここで、その確認すべき物体に、化学物質を塗って、それを確認するミニカーみたいなセンサーを作っておけば、その化学物質をチェックして、個数とかも確認できる。。かもしれない。

　化学物質なら、食べちゃっても大丈夫なものにしておけば、商品に塗ってもＯＫだし、安価でできる可能性もある。また、抗体反応をするときみたいに、反応するところを微妙に変えることによって、いろんなものが表現できるかもしれない（たしか、この抗体反応をするところは、柔軟に変えられるというのを研究したのが、利根川博士だと思った）

---

　ってことで、タグに化学物質を使い検知したり、化学物質を塗って、その上を走らせるというのは、真っ暗なところでもできるので、いろいろと、無限に応用範囲が広そうだ。
　化学物質を利用したマーカー（タグ）ってことになれば、どんどん小さくもできそうだ。

　この応用のもととなる、基本的な事実、

　「真っ暗で見えないところでも、化学物質を探知できれば、行動は可能だ」

　という発想は、実は、プラナリアの生態


視覚が発達していないプラナリアがエサに近づく際、口から管を伸ばす動きに注目。その行動を促す物質が、エサの細胞に含まれるグリコーゲンで、それを感じ取る部分が口の周りにある


　で知られていることであり（まあ、これだけじゃないだろうけど）、これを見つけたのが、本家でも取り上げた、プラナリア天才！美少女？？？女子高生（＠＿＠！）下山せいらさんだったりするわけだ。

　で、下山せいらさんの話を書いた、本家のＵＲＬは、以下のとおり
プラナリア女子高生、下山せいらさんがＮＨＫの情報Ａで出てる（＠＿＠！）英語のプレゼンで、自作のプラナリアのぬいぐるみと！
http://plaza.rakuten.co.jp/struts/diary/200610100003/

　ところが、こんなすごいこと（専門家でも知らない事実を、突き止めたそうな）を調べて、さらに、もっともっと可能性の広がりそうな、工学的にいろいろ応用できそうなことを突き止めたのに、この記事

科学者の卵　支援が課題
http://www.yomiuri.co.jp/kyoiku/renai/20060425us41.htm
によると（上記斜体および、以下の斜体は、上記読売の記事からの引用）

下山さんも「実験ばかりやっていたから、受験は悩みの種」と顔を曇らせた。


　えー、（＠＿＠！）
　こんなにすごいことやってるのに、大学受験しなくちゃいけないの。。。
　日本の教育制度は間違ってる！
　
　プラナリアの生態から、化学物質を利用したマーキングとかなんかが、大学で開発できれば、大もうけ！なので、そんなすごい研究をやっているせいらさんは、もう、私立大学ならどこでも無試験で引っ張りだこでも、不思議ではないでしょう。

　特例で、無試験で東大合格、いや、日本のために、生物と情報工学両方を研究している奈良先端大学院大学へ、無試験で飛び級で合格でも、おかしくないっしょ。。

　だってだってだよ、日本の大学は大変とか言われて、もし、海外の大学にいかれちゃったら、どーすんのよ。。。
　この化学物質によるマーキングにより、ロボットを走らせたり、確認したりする技術は、軍事的にも、応用範囲、広そうだよ。。もし、軍事転用されたら。。。

　こりゃー、日本の国家をあげて、下山さんをどこの大学にでも受からせるべきであります。

---

　そして、目をつけるのは、やっぱ企業でしょうなあ。。。
　これからプラナリアの生態とかをさらに研究して、それを応用して、
　化学物質をつかったマーキング方法を「せいら姫方式」とか命名して、特許とって、それで動くロボットとかを作ったら、「スーパー女子高生が”発見”したロボット」とかいうので、売り出して、すごい人気になりそうだ。

　プラナリアのグッズ販売でも儲けられそうだ。。。

　おおお、浦和第一女子高校（下山せいらさんが通っている学校）に、一万円札をボストンバッグに一杯入れた企業がやまのようにきて、「研究協力してくれええ・・」「４年、６年、いや９年後はぜひうちの会社へ」という企業の人たちが山のように来る。。。

。。。って、それはないか（＾＾）

Ｐ．Ｓ　これで下山さんが「せいら姫」とかいわれて、有名になったら、ＮＨＫは、すげーっていうことになるんだろうな。。

XMLによる簡易BREWアプリ制作ツールと、決まった動詞で基本機能記述と、Ａｃｃｅｓｓのマクロ。

ＢＲＥＷといえば、このブログでは、勝手サイトがＪＡＶＡで作れるようになるというオープンアプリの話題とか（ここ）、マルチウィンドウのニュースとか（ここ）を取り上げたが、まだ取り上げてないけど、これにひけをとらないほどすごい話題がある。

　そいつが、ＸＭＬで動作を記述すると、それを実行してくれて、さらに、そいつは、審査がないっていう、簡易BREWアプリ制作ツール、「ケータイ・カスタム・キット」だ。

　ちと（いやかなり　＾＾；）古いが、その話は、ここ


【WIRELESS JAPAN 2006】
KDDI、携帯向けRFIDリーダーや簡易BREWアプリ制作ツール
http://k-tai.impress.co.jp/cda/article/event/30213.html

そこから引用すると(以下斜体は上記記事より引用）、

デモアプリ制作ツールと案内されていた「ケータイ・カスタム・キット」は、簡易的なBREWアプリを制作できるというもの。企業に向けてBREWアプリを使ったソリューションを提案する際に、具体的なイメージを抱きやすくする、あるいは試験運用するといった目的で、スムーズにテスト版アプリを提供できるようにすることを目指している。

　あらかじめ「カメラで撮影する」「録音する」「GPS測位する」といった命令が用意されており、XMLとして記述すれば、記述した順に動作する。BREWアプリの場合、au端末で動作させるには事前にKDDIの審査が必要となるが、「ケータイ・カスタム・キット」では動作をシンプルにしたこと、GPS測位時などに毎回ユーザーの同意を得ることなどで、審査なしで提供できる。また、WebDAVサーバーに対応している点も大きな特徴という。


とのことだ。

---

問題は、デモとはいえ、このＸＭＬを記述することで、プロトタイプに十分な機能のアプリが作れるのかどうかであろう。

　ウィリアムのいたずらは、このブログの「ＵＭＬや自動生成、形式仕様の接点は、決まった動詞で仕様を表現し、システムに翻訳すること」において、基本機能を定義し、入出力関係の関数とあわせて提供すれば、要件を満たすプログラムを、それらの基本機能と入出力で表現することは可能とかき、具体的な内容として、さいきんのＪａｖａシリーズでその内容を書いている。

　しかし、それだけで、本当に、できるかどうかを吟味することはできないだろう。

　でも、実は、ＸＭＬを記述することで、デモを作ることは可能であり、そのために必要な関数は、これらだ！というのを示したものがある。
　それが、マイクロソフトＡｃｃｅｓｓの、マクロである。
　実際にマクロを使って、デモをするということはある。
　ということは、
　　現在のＡｃｃｅｓｓのマクロ
　　　　－Ａｃｃｅｓｓのテーブル関係の命令
　　　　＋カメラ操作などＢＲＥＷ独特の命令
　　　　＋ＤＢの代わりのファイル操作
　なんかを加えれば、そこそこ、デモできるものが作れそうだ。
　（あと、条件分岐あたりも入れておいたほうが、書きやすいと思う）

---

　さらに、Ａｃｃｓｓのマクロ形式からＸＭＬに落とすことは、これは、普通の制御文であれば、アクションをタグ、引数を属性値にすればいいし、条件分に関しては
＜ＩＦ　zyoken="A == B">
＜ＴＲＵＥ＞
　　＜ＣＯＭＰ siki="A = A+B"　／＞
＜／ＴＲＵＥ＞
＜ＦＡＬＳＥ＞
　　＜ＣＯＭＰ siki="B = A+B"　／＞
＜／ＦＡＬＳＥ＞
＜／ＩＦ＞

みたいに書けばいいから（ＳＷＩＴＣＨの場合は、ＴＲＵＥとかＦＡＬＳＥがＣＡＳＥになると思うけど）まあ、書けるでしょう。

---

　そうすると、ＢＲＥＷとオープンアプリの機能的な差は、「カメラ操作などＢＲＥＷ独特の命令」だと思うから、その部分を抜けば、オープンアプリでもおなじＸＭＬの仕組みで作れることになる（とくに、Ａｃｃｅｓｓのマクロみたいな形のツールができれば、そのツールから、オープンアプリもＢＲＥＷも作れる）。

　さらに、Ｄｏｃｏｍｏのiアプリも同じように作れそうだ。

　そうなると、問題は、このＡｃｃｅｓｓのマクロっぽい画面で、コマンドとなるＸＭＬを作成するツールと、できたＸＭＬを読み込んで実行する部分を作成し、ＢＲＥＷかオープンアプリか、Ｄｏｃｏｍｏiアプリかによって、使えるアクションや引数を切り替えればよいということになる。

　もし、こういうツールが出てくると、この話、面白くなりそうだ。