BREWのIWEBUTIL_UrlEncode関数の第５引数に関して

　BREWで、IHTMLVIEWER_SetViewStateなどで値を設定したいとき、漢字などは、POSTのように、%81%40のような１６進で表現する。
　で、このことをやってくれる関数がIWEBUTIL_UrlEncodeである。

　逆にIHTMLVIEWER_GetViewStateでうけとった値は、上記のように漢字が表現されているので、その値をふつうの漢字に直すには、IWEBUTIL_UrlDecodeを使う。

---

　で、IWEBUTIL_UrlEncodeのとき
　関数の書式は以下のとおり
char * IWEBUTIL_UrlEncode(IWebUtil * pIWebUtil, const char * cpcIn,
　　　　　　　 int * pnInLen,char * pcOut, int * pnOutLen);

ここで第一引数は、インスタンスなのでいいとして
　　　第二引数は、変換しようとする値
　　　第三引数は、変換しようとする値の長さ
　　　第四引数は、変換結果を入れるところ
　　　第５引数は、変換結果の長さ
ということは、第五引数は、値入れなくてよさそうに見えてしまう（ポインタだけ渡せば）
そうでははない。
　第五引数には、第四引数の大きさ（長さ）を必ず入れてから呼び出すこと
　つまり、ここは書き換えられる。

　もし、第五引数をいれないで呼び出すと、ここが０クリアされていれば、第四引数に変換結果が入ってこない。変な値が入っていれば、その値を長さとみなして処理してしまう。
　
　IWEBUTIL_UrlDecodeもそうかもしんない。
　どっちのときもやっておいたことにこしたことはない。

　つぎのＢＲＥＷネタを書く前に必要なので、つけたしといた

で、Javaのプログラムつくって、優秀なロボットを選んで、総額５億円の話の続きなんだけど。。

　本家のほうでかいた、「総額5億円を優秀ロボットに運用させる！という次回カブロボットコンテストって。。。」で、


トレンドがあるときのロボットを、もみ合いに使うとうまくいかないよ！


って書いたけど、この理由をかいてなかった。
ちょっと、理由を書いておくと、こんなかんじ。
（コンピューターっぽい話になるので、分家に書いておいた）

---

株の自動売買ロボットを作成しようとした場合、大きく２とおりの方式がある。

１つは、逆張りに反応する方法
　　株価が安くなったら買う、高くなったら売る

もう一つは、トレンド、順張りに反応するように作る方法
　　株価が高くなってきたら買う、安くなってきたら売る

　逆張りの方法は、もみ合いのとき有効。安いところで買って、高いところで売るから。
　しかし、この方法は、大きなトレンドが出てしまった場合問題。
　はじめっから高かったら、買えないし、株は一本調子で上がらないので、安くなったら、売ってしまう。ところが、そのあと、窓をあけて上がるから、その窓の分＋手数料分損する。

　順張りの方法は、逆にトレンドが出れば、一本調子で買っていく（あるいは売っていく）ので、そのトレンドが出ているのなら儲かる。でも、もみあいだと、その期間上下して、結局＋－０っていうこともありえる。

　つまり逆の動きをするので、トレンドが出てるときに儲かるロボットが、もみ合いで儲かるとはかきらないと思う。

---

　ただ、順張りの場合、小さなトレンドを狙えばいいんじゃないのとおもうかもしんないけど、今度は、だましがある。
　なので、どの程度のトレンドだと、最高益になるかというのは分からない。

　ってことで、ウィリアムのいたずらが１回目に作ったロボットは、トレンドフォローなんだけど、その「どの程度」という部分をパラメータで調整できるようにしている。

アンケートなどの回答を入力するためのデータ設計方法

　きのう（時間的には日付回ってたので今日）のNHK高校講座情報Aをみて。。
　コリン君、ちょっとまった！
　ここで、アンケートを入力するとき、表計算ソフトをつかって

　１行目に番号
　３行目に１番目の回答
　５行目に２番目の回答
　７行目に３番目の回答

を書いているよねえ。。つーことは言い換えれば、
たとえば、番号１番目の人の回答は、B列、２番目の人の回答はC列。。
と、１レコード（１解答用紙）１列に書いているよねえ。。。

　う、その書き方はまずい。
　きっと、その書き方をしたら、小倉優子が、コリン語で、コリンコリンといいだすぞ（出さないって）

　その理由も、含めて、アンケートの回答のデータ設計について、まとめておきますか。。

---

■アンケートの回答には、大きく３種類ある

　アンケートデータを入力するとき、まず、回答の方法から、３種類にわける。
　これによって、レコードの作り方が違う

●（１）．単一回答（シングルアンサー：SA)
　あなたの性別はA．男　B．女のように回答が１つしかない（１つに限定している）もの

●（２）．複数回答（マルチアンサー：MA）
　あなたの好きな教科は（複数回答可）
　１．数学　２．地学　３．生物　４．日本史　５．世界史　６．地理
　のように、複数の回答が可能なもの

　なお、これには２種類あって、
　（２－１）上記のように、回答範囲は限定されているものと
　
　あなたの好きな、NHK高校講座の司会者、生徒役を３人書いてください
　のように、

　（２－２）回答範囲がアンケート上には、記載されていないものがあります。
（この場合、浅沼コリンはOK、でも、コリン星の小倉優子っていうのは、出てないのでXとなるが、アンケート上には、解答欄が３つあるだけで、だれを回答していいのか、かかれていない）

●（３）．自由回答（フリーアンサー）
　高校講座の感想を書いてください。のように、自由にかけるもの。
　記述式（あるいは論述式？）の回答

---

■アンケートは１人分１レコード１行が原則

　アンケートは、「１人分１レコード１行が原則」です。

　理由は、以下のとおり
・エディタで入れる場合、１人分１列にして入れると、やれないことはないけど、めんどくさい

・表計算ソフトで処理したい場合、列の制限が２５６程度の場合がある。
　このとき、１人分１列ごとに入れると、２５６人分ということになるが、２５６人以上回答者があるアンケートというのは、ざらにある（というか、そのほうが多い）
　これが行だと、数万になるが、何万人にも回答してもらうアンケートは少ない。

　逆に、２５６個の項目があるアンケートというのは、回答するほうも大変で、むしろ、避けるべきである。

---

　　
■原則どおりにならない場合と、その対処法
　ただし、原則どおりにならない場合がある。こんなとき

・とはいっても、回答が２５６個以上になる

・アンケートが３ページくらいになっていて、表計算で入力するとき、
　１シート１ページ１行のほうが入力しやすい場合がある

　この場合、番号部分を必ず入力するようにして、分割してかまわない。
　１シート１ページ１行のときは、アンケート用紙の各ページに回答番号を振っておくのがいい。
　なお、この回答番号をいれないで、同じ行なら、同じ人とやるのは危険。
　しらずしらずにずれてしまうことがあり、そのとき、手が付けられなくなる。
（入力中に休憩を取ったとき、その合間に回答用紙を落としてじゅんばんわかんかくなっちゃった！なんていうときに起こる）

・自由回答の場合でテキストエディタで入れる場合で、回答が長い場合
　この場合は、回答番号をファイル名にして、タグ付けしていれる。
　なお、短い回答なら、表計算に直接入力していいが、その場合は、改行の文字を何かに置き換える。普通\nで、\は全角の￥を使うか、\\を使う。
　

---

■入力方法
　で、１つの設問に対して、どの項目に入力するか。

　上記に書いた

１．単一回答（SA)の場合は、
　１列に１問。たとえば、上にあげた情報Aのケースでは、回答はSAなので（１問につき１つの答え）１問目はB列、２問目はC列のように、１問１列で回答する。

２．複数回答（MA）の場合は、
　２とおりある。

　（２－１）のような、複数回答のケースでは、１選択項目１列にする
　つまり、例
　１．数学　２．地学　３．生物　４．日本史　５．世界史　６．地理
　の場合は、
　B列が数学、C列が地学、D列が生物。。。のように、選択項目１つに１列を当てる。チェックしてあったら１、チェックしてなかったら０にする。
　この場合、集計するときは、COUNTIFを使ってもいいけど、単純にSUMでいい。

　（２－２）のような複数回答のケースでは、回答欄分、列を用意する
　つまり、例
　あなたの好きな、NHK高校講座の司会者、生徒役を３人書いてください
　の場合は、３人＝３個の解答欄、B,C,D列のように３列用意する。
　この場合、集計するときは、COUNTIF(B1：D200,"浅沼コリン")のように集計
　してもいいけど、ここに書いたように、
　シートを分けてしまって集計したほうが、やりやすいこともある。
　詳しいことや理由は別の機会（気がむいたら）。

　ただし、これは、「集計方法」であって、入力時点では、別シートにわけず、
　いっぺんに入力したほうが、しやすい。

　なお、複数回答なんだけど、回答数が決まっていない場合、
　あなたの好きな、NHK高校講座の司会者、生徒役を書いてください（好きなだけ）

　の場合は、カンマなど、区切り文字をきめて、後述（３）のように入力する。
　このとき、最後の言葉にも、区切り文字を入れておくと、集計が便利。
　集計のときは、項目名＋区切り文字が何件あるか？というカタチで集計する

（３）自由回答の場合は、１回答項目１列にする。

---

■ちなみに、解答用紙の作り方
１．単一回答（SA)の場合は、ラジオボタンまたはコンボボックス、リスト

２．複数回答（MA)で
　２－１のように、選択の場合は、チェックボックス、複数選択可のリスト
　２－２のような場合は、回答数分、テキストボックス

３．自由回答の場合は
　テキストボックス（テキストエリア）

を使うのが普通だと思う。

---

で、このあと、手順とか、集計方法、とくに、複数回答でシートを分けたほうがいいケースとその理由（回答項目にゆれがあったり、得点化するときに使う）について書くべきなんだけど、それは情報Aの昨日の話しから、それそうなので、別の機会に、覚えていて、気が向いたら書きます。

ブログマーケティングの考え方が変わるかもしれない。スプーのえかきうたで

　いま、ネットの話題独占といえば？？
　NHKおかあさんといっしょの「スプーのえかきうた」ですよね。

　これ
http://www.youtube.com/watch?v=R-fjqo3dNhg

　注意：

クリックすると、すぐに音が出てしまうので

　仕事中の人は、音が出ない（ミュートにするとか）ようにしてから、
　クリックするなら、してください
（音が出なくても、問題の箇所は意味が通じます）

　問題の箇所は、２分１２秒くらいから２５秒くらいまで。
　しょうこおねーさんの絵に注目！ありえませんぜ、だんな（＾＾；）

---

　でも、これが大ブレーク！
　８時４０分現在、gooのブログトレンドランキング１位で、ブログを中心に、いっきにおかあさんといっしょのしょうこおねーさんが有名になった！

　これで、「おお、おかあさんといっしょを見てみよう」という人も増えたんではないか？（ウィリアムのいたずらは、きょうは見そびれてしまったが、今度みたいと思っている）

　つまり、ブログでのマーケティング的には、NHK、大成功だったといえる！！

---

　最近、ブログを使ったマーケティングというと、

　いくらいくら、謝礼にはらうので、ブログにかいてください。
　その際、ここをリンクしてください

　というカタチが多い。この手のやつは、面白いわけではないので、内容が浅い。
　そのため、一時的にブログランキングで上位に行っても、すぐに落ちてしまうし、もともと無理やりネタにしているわけだから、他の人が、もりあげてくれない。

　そーじゃなくって、今回のおかあさんといっしょのように、ブログを書く人たちがとりあげそうな話題が、番組内に、はじめからあったほうが、ウケルということだろう。

　CMや番組作りも、今後そーいう方向（つまり、ブログを書く人がツッコミやすいような要素を、初めから入れる）で作っていくことが大切になってきたのかもしれない。

---

　ってことで、そういうことまで考慮して、NHKが、しょうこおねーさんを出して、絵をかかせているとしたら。。。おそるべしNHK？？

　というのは、３年前のスプーというのは
　これ
http://www.youtube.com/watch?v=3FT9b-0MA1I
なんだけど、
　注意：

クリックすると、すぐに音が出てしまうので

　仕事中の人は、音が出ない（ミュートにするとか）ようにしてから、
　クリックするなら、してください
（音が出なくても、問題の箇所は意味が通じます）

　これは、２分１８秒のところで、注意してみてほしい。

　絵を書いた面が、違わないか？

　しょうこお姉さん、描いた絵をもって回転してるよねえ、で、回転したまま絵を出してるよねえ。。＝＞裏にかいてある絵をだしている

　つまり、３年間の間に、NHKの放送の方針が変わり

３年前は、きれいなものを出したほうがいいという考え方
　→なので何回か練習して、うまくいったのを出したのであろう

でも、いまは、そのまま出したほうが、おもしろいし、話題になりそうという方針に変わり
　→そのまま、書いたままをだしたのであろう。。

　うん、たしかに、こっちのほうが、話題になっておもしろいもんね。


　とにかく、NHKが、そうおもっているかどうかは別として、マーケティングとブログの関係の曲がり角に来ているということは、いえそうだ。

iアプリによる「カーソル移動」？：入力不可にして、選択項目を変える

　iアプリにおける、複数画面の作成法のつづきです。
（前回と同じ言葉）
画面を表示する場合
（１）アプリ自身のクラス(iApplicationから継承）
（２）１画面分のクラス(PanelまたはCanvas＋リスナー）
にわけ、（１）をここで説明しました
　そして、（２）のpanelのケースについて、２のクラスは、Panelを継承し、必要なリスナーをすべてimplimentしたクラスを作ったうえで、以下のメソッドが必要であると書きました。
　(2-1)コンストラクタ
　(2-2)各種リスナー（複数のメソッドあり）
　(2-3)カーソル移動のためのクラス（いくつかのメソッドに分かれる）

そして、２－３については、２とおり考えられますと、ここで書きました
（あ）キー入力に応じて、カーソルを移動させる
（い）入力できるところを入力可、そうでないところを不可にする

　前回は（あ）を説明したので、今回は（い）です。

---

■入力不可にして、選択項目を変えるのに必要なこと
　これは、そんなにありません。ボタンを押されたら、入力可能項目を変えようとしているのですが、その場合、

・ボタンが押されたら、入力不可・可能を切り替えるメソッドをよぶ
・そのメソッドで、各項目の入力可能・不可をsetEnabledメソッドで切り替える

というだけです。

　以下、それぞれについて説明します。
　なお、ソースコードは、ここにあります。

---

■ボタンが押されたら、入力不可・可能を切り替えるメソッドをよぶ
　これは、componentActionで行います。
　引数のtypeがComponentListener.BUTTON_PRESSEDのとき、フェーズごとに
　　・次のフェーズにして
　　・次のフェーズの入力不可・可能を切り替えるメソッド（setEnableItem）をよぶか
　　　最後のフェースの場合には、終了します（setNextPanel(0)）。

ソースは、こんな感じになります

	public void componentAction( Component source, int type, int param)
	{
		//==============================//
		//	ボタンが押された　　　//
		//==============================//
		if (type == ComponentListener.BUTTON_PRESSED)
		{
			switch(phaseNo)
			{
			case	0:		//	
				phaseNo	=	1;
				setEnableItem(phaseNo);
				return;
			case	1:
				phaseNo	=	2;
				setEnableItem(phaseNo);
				return;
			case	2:
				app.setNextPanel(0);
				return;
			}
			return;
		}		

	}

（上記の＜　＞　￥　は本当は半角です)

---

■そのメソッドで、各項目の入力可能・不可をsetEnabledメソッドで切り替える
　setEnableItemっていうメソッドでやってます。
　フェーズ番号ごとに、
　　そのフェーズで入力可にするなら、setEnabled(true)に、
　　そのフェーズで入力不可にするなら、setEnabled(false)にすると
　入力可のものだけ、フォーカスをあてることができ、はじめに、入力可のなかで
　一番先頭の項目にフォーカス（カーソル）があたります。

　ただ、そんだけです。
ソースは、こんな感じになります

	public void setEnableItem(int phNo)
	{
		switch(phNo)
		{
		case	0:	//	挑戦する
			button1.setEnabled(true);
			textbox1.setEnabled(false);
			button2.setEnabled(false);
			button3.setEnabled(false);
			break;
		case	1:	//	入力
			button1.setEnabled(false);
			textbox1.setEnabled(true);
			button2.setEnabled(true);
			button3.setEnabled(false);
			break;
		default:	//	終了
			button1.setEnabled(false);
			textbox1.setEnabled(false);
			button2.setEnabled(false);
			button3.setEnabled(true);
			break;
		}
	}

（上記の＜　＞　￥　は本当は半角です)

---

ってことで、ＢＲＥＷと同じところまで説明したので、
このシリーズの次回はＢＲＥＷのほうに戻って、項目の入力・出力についてです。
いつやるか未定（まだ材料となるプログラムができていないんで）

動画を２値データで送り、変化した点の色が予測不能なときだけカラーにすると大幅圧縮できるから？

人間の目って、カラーで判断できる部分って、あんまり無くて、多くは、２値（白黒）しか判断できないじゃないですか！

　あれって、いままで、なぜなのかなあ？全部カラーのほうが、便利ジャン！って思ってたんだけど、昨日、気付いた！！

　そっか、カラーで全部送ったら、伝送量も、処理量も、メモリー量も全部カラーでたいへんじゃん！

・データを２値でおくり、
・白黒画像と前に保持しているカラー画像から、動きの無いとこ、予測できるところは補完し、
・予測不能な必要なところだけ、カラーで送ってもらえば

伝送量も、処理量、メモリー量も少なくてすむじゃん！と

---

つまり、こんなかんじ

　　２値で処理する　　　　カラー情報を送る
　　　　↓　　　　　　　　↑　　　↓
　　カラー化に必要なデータの　　　↓
　　ところを、送るように指示する　↓
　　　　↓　　２値データ　　　　　↓
　　２値データと、カラー情報から、カラー化
　　　　↓　　カラーデータ
　　それを表示する

で、このとき、「カラー化に必要なデータのところを送るように指示する」際に

１．２値データを判断して、
　　　動きが無いもの
　　　動きが予想つくもの（アフィン変換すると、その形になる）
　　は送らないでよい

２．予想がつかず、カラー情報が無いものだけ、色を送ってもらうようにする
　　→そのとき、視線を動かすように指令する
　　　（目の中心付近しか、カラーを認識する細胞が無いので）


　ってすると、送る転送量も少ないし、２値なので、処理量も少ないと。。

　そーすると、目の中心にしか細胞が無くても、必要なところだけ目を動かせば見れるわけだし。。

---

　また、２値のバッファ、カラーバッファとあるので、ダブルバッファリングみたいな感じになって、部分部分を並列処理しても、脳に送られる信号は、出来上がった画像を送ることで、あたかも１つの絵みたいにみえるのかな。

　で、この画像作成中も動きを予測して、補完してれば。。
　残像みたいなこともありえるのねと。。

　これは、推測（妄想？）だけど、実際、そーなってるのかにゃー？？

　だとしたら、人間って、すんげー速さで、補完処理をしてるってことで、すごすぎ。
　って、意外と補完処理（アンチエイリアスや補正とか）って、簡単なのかな（＾＾；）
　ウィリアムのいたずらが知らないだけ。。

---

　でも、この白黒で送信＋必要なところだけカラー＆白黒データから色予測＋補完

　っていうのは、圧縮・転送技術的におもしろいのかなあ？？

　って、考えただけで、ほんとうにそーなってるかどうか、わかんないんだけどね。
（目は白黒判断する細胞が多く、中心付近にしか、カラー判断細胞しかないのは、推測でなく、どっかで習った気がする）

放送は、台本もDBに入れて、動画とタグ付けて、台本を検索したほうが、いいかも！

こんなニュース

[東京大学]ＮＨＫ映像データベースの教育利用を研究
http://news.livedoor.com/webapp/journal/cid__1991596/detail?rd

がある。今後、動画をデータベース化し、検索しやすくするってのは、
教育利用以外にもあると思う。ケータイ動画配信や、TVのサーバー型配信などに伴って。。

　そこで、なんだけど。。

　以前のブログで、字幕を検索対象にすればって書いたけど、

　そもそも、

・放送の台本からDB化してしまい、
・その台本に対応するところの動画、音声にタグをいれて
・検索するときは、台本の文字を検索して
・検索結果をもとに、動画を見る場合は、そのタグを元に動画を引き出せば

　NHKの教育番組の場合は、いろいろできそうな気がする。あと、映画とかでも。。

　いや、みのもんたとか、たもりじゃ、ダメだと思うけど。。
　台本に書いてあることを言ってるとは思えないから。。。

　。。。つーか、台本なんてあるのか（＾＾；）

3次元CGで使う要素技術の関連の、大まかなまとめ

　きのう、ブログに書いた「C++による簡単実習　３次元CG入門」に載っていることの、用語の関連の大雑把なまとめ

---

■基本的な座標変換→アフィン変換
・平行移動
・回転移動
・拡大縮小
・それらの合成

---

■CGで書く
　→形状の作成（モデリング）後、描画（レンダリング）する
　モデリングの方法
　　・ワイヤーフレームモデル
　　・ポリゴンモデル（サーフェイスモデル）
　　　　→陰面処理：法線ベクトル法、Zバッファ法
　　　　→シェーディング
　　・ソリッドモデル
　　　　→レイトレーシング
　　　　→ラジオシティ法
　レンダリング
　　・ボリュームレンダリング

---

■質感の変化、映りこみなどの表現：マッピング
→マッピングの手法
　　・テクスチャーマッピング
　　・バンプマッピング
　　・環境マッピング
　　・リフラクションマッピング

iアプリによる「任意のカーソル移動」：キー入力により、カーソルを移動

　アプリにおける、複数画面の作成法のつづきです。

画面を表示する場合
（１）アプリ自身のクラス(iApplicationから継承）
（２）１画面分のクラス(PanelまたはCanvas＋リスナー）
にわけ、（１）をここで説明しました
　そして、（２）のpanelのケースについて、２のクラスは、Panelを継承し、必要なリスナーをすべてimplimentしたクラスを作ったうえで、以下のメソッドが必要であると書きました。
(2-1)コンストラクタ
　(2-2)各種リスナー（複数のメソッドあり）
　(2-3)カーソル移動のためのクラス（いくつかのメソッドに分かれる）

そして、２－３については、２とおり考えられますと、ここで書きました
（あ）キー入力に応じて、カーソルを移動させる
（い）入力できるところを入力可、そうでないところを不可にする

今日は、（あ）についてです。

---

■キー入力に応じて、カーソルを移動させるのに必要なこと
　今回「キー入力に応じて、カーソルを移動させるのに必要なこと」は、以下のとおりです。
　なお、カーソル移動といっても、１文字ごとの移動はシステムで行いますので、項目間移動のみです（項目間移動も、基本的にシステムで行いますが、その移動箇所以外のところにいきたい場合）

・キー入力を受け取り、項目移動が必要か判断
・必要なときは、次の項目番号を受け取り
・次の項目に移動する
・「打ち終わった」など、フェースが終わった場合であれば、
　フェーズ番号を変えて、次のフェーズの一番初めの項目へ

以下、順に説明します。
なお、サンプルソースはここです。

---

■キー入力を受け取り、項目移動が必要か判断
　 keyPressedメソッドで行っています。
　KEY_DOWNまたはKEY_UPのとき（ここでは、うまく入力できなかったので、
　KEY_POUNDまたはKEY_ASTERISKのときにしてあります。）
　　次の項目番号をもとめ、（getNextItem）
　　項目に、カーソルを移動しています（setActive）

ソースは、こんな感じになります

	public void keyPressed(Panel pl,int param)
	{
		switch(param)
		{
//		case	Display.KEY_DOWN:	//	うまくいかなかった
		case	Display.KEY_POUND:	//	#キー
			itemNo = getNextItem(phaseNo,-1,itemNo);
			setActive(itemNo);
			break;

//		case	Display.KEY_UP:	//	うまくいかなかった
		case	Display.KEY_ASTERISK:	//	*キー
			itemNo = getNextItem(phaseNo,1,itemNo);
			setActive(itemNo);
			break;
		}

	}

（上記の＜　＞　￥　は本当は半角です）

---

■次の項目番号を受け取り
　getNextItemメソッドで行っています。
　フェーズ番号と、現在の項目番号をもとに、つぎの項目番号を返しているだけです。

ソースは、こんな感じになります

	public int getNextItem(int phNo,int flg,int nowNo)
	{
		if ( flg	==	1 )
		{
			switch(phNo)
			{
			case	0:	//	はじめの入力
				return	0;
			case	1:
				if ( nowNo	==	1 )
					return	2;
				else
					return 1;
			case	2:
				return	3;
			}
		}
		else
		{
			switch(phNo)
			{
			case	0:	//	はじめの入力
				return	0;
			case	1:
				if ( nowNo	==	2 )
					return	1;
				else
					return 2;
			case	2:
				return	3;
			}
		}
		return	0;
	}

（上記の＜　＞　￥　は本当は半角です）

---

■次の項目に移動する
setActiveメソッドでおこなっています。
指定された項目番号の項目を、requestFocusしています。
そうすると、そこにカーソルがきます。

ソースは、こんな感じになります

	public void setActive(int no)
	{
		switch(no)
		{
		case	0:	//	挑戦する
			button1.requestFocus();
			break;
		case	1:	//	入力テキスト
			textbox1.requestFocus();
			break;
		case	2:	//	打ち終わった
			button2.requestFocus();
			break;
		case	3:	//	終了
			button3.requestFocus();
			break;
		}
	}

（上記の＜　＞　￥　は本当は半角です）

---

■フェーズ番号を変えて、次のフェーズの一番初めの項目へ
　ボタンが押されたとき、フェーズがかわりますので、この処理は、componentAction
メソッドで、typeが、BUTTON_PRESSEDで行っています。
　・フェーズ番号を変え
　・そのフェーズではじめに選択する項目番号を、項目番号にセットし
　・そこにカーソルが来るように、setActiveします。

ソースは、こんな感じになります

	public void componentAction( Component source, int type, int param)
	{
		//==============================//
		//	ボタンが押された	　　//
		//==============================//
		if (type == ComponentListener.BUTTON_PRESSED)
		{
			switch(phaseNo)
			{
			case	0:		//	
				phaseNo	=	1;
				itemNo	=	1;
				setActive(itemNo);
				return;
			case	1:
				phaseNo	=	2;
				itemNo	=	3;
				setActive(itemNo);
				return;
			case	2:
				app.setNextPanel(0);
				return;
			}
			return;
		}		

	}

（上記の＜　＞　￥　は本当は半角です）

---

　今回はここまで。
　このシリーズの次回は、「（い）入力できるところを入力可、そうでないところを不可にする」についです。
ここ　http://www.geocities.jp/xmldtp/index_iappli.htmに今までの内容をまとめています。

音楽再生ケータイ、KDDIはソニーとウォークマンブランドでで共同開発

　ちょっと前、ソフトバンクとIPodの提携があるとかないとか話題になったが、
　今度はKDDIとソニーがウォークマンブランドでで共同開発とのことらしい

ここのニュース
音楽再生携帯、ＫＤＤＩがソニーと開発・多機能化で連携戦略
http://www.nikkei.co.jp/news/sangyo/20060522AT1D190AV21052006.html

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


　携帯電話「ａｕ」を展開するＫＤＤＩはソニーと「ウォークマン」ブランドの携帯電話機を共同開発する。ソニー傘下の携帯電話機大手ソニー・エリクソンと音楽再生機能を持つ機種を開発し、今夏に発売する。ＫＤＤＩは検索技術では米グーグルと提携する。ソフトバンク（現ボーダフォン）は検索はヤフーと、音楽再生機能付き携帯では米アップルコンピュータと提携交渉に動いており、携帯電話の多機能化を巡る協力関係が2陣営に分かれた格好だ。


とのことです。

同じコンテンツをケータイでもPCでも見る話＋字幕を検索対象はアリだよね

　以前のブログに、同じコンテンツをケータイでもPCでも同時に見れる方法をNHK技研が公開する話について書きました。
　PCの比率でケータイでみると、ボールが小さくなってしまうので、ケータイの場合は、ボールを２倍で見るなど、メディアにあったカタチでみる（画像を切り出して、切り出した画像を動かしたり拡大したりするらしい）という技術だそうです。

　で、そのことをやっていた番組、NHKのサイエンスZEROですが、２２日深夜（日付がまわってるので厳密には２３日）に再放送があるので、一応書いておきます。

　５月２２日（月）２４：４０（２３日０：４０）　NHK教育（東京は３チャン）
　サイエンスZERO　「未来のテレビ大集合！不思議な世界を激写」

---

　上記の技術は、NHK技研が開発したAdapTVというものですが、今回は、それ以外（サイエンスZEROではやっていなかったもの）で面白そうなのを発見したのでご報告。

　ちなみに、そのNHK技研のAdapTVと、今回紹介するものは、以下の技研公開２００６で公開されるらしい。
このページ　http://www.nhk.or.jp/strl/open2006/index.html

に期間と場所がかいてあります。

---

　で、今日紹介するのは、「画像認識技術と字幕の言語処理による映像検索」
で、この話はちょっと脇に置き（知りたい人はリンク先をみてね）、この字幕を検索対象にして、たとえば、GooとかGoogleで見るのは、ありだよね！

　たとえば、エンドロールの文字を識別して、それを文章化して、そいつを検索対象にすると、出演者や監督、脚本家で検索できるわけでしょ。映像が。。

　で、日本語訳を対象にした場合。。。うーん便利かなあ？っていうのはあるけど、字幕の「ここ」って指定したら、画像がでてきてくれると、うれしいよね。

　っておもったけど、題名見ただけなので、本当に、こういう技術かどうかはわかんないよ。
　ただ、これができれば、べんりだなあと。。

---

　で、それより、ケータイ的には、きっと、こっちのほうが大事なのかな？
デジタル時代のコンテンツ流通技術
～ 多様な視聴スタイルへの展開 ～
http://www.nhk.or.jp/strl/open2006/tenji/t02.html
（以下斜体は上記記事より引用）

・携帯電話の通信機能と連携することにより、視聴者が好むジャンルの関連情報が受けられるなど、便利で受益感の高いサービスが利用できるようになります＊1。
・携帯端末で複数の通信サービスを利用する際、通常は通信サービスごとに個人認証をする必要がありますが、放送の携帯端末向けサービスでの1回の認証だけで済むようになります＊2。
・通信機能を持たない携帯端末でも、放送波から送られてくる視聴ライセンス情報だけで利用できるサービスを受けられます。


（中略）


＊1 本研究は、KDDI（株）、（株）KDDI 研究所と共同で進めています。
＊2 本研究は、日本電信電話（株）と共同で進めています。

とりあえずリンクページから

　そうそう、前にブログで書いたことの結論かいていなかった。

　組合のようなカタチで、複数企業が、まとまろうとする場合、なにかやろうとすると、かならず、組合内での業務の標準化の問題が出てきてしまう。

　共同発注しようとすれば、発注のフォームを共同にしないといけないし。。
　みたいな。。
　ところが、この標準化というのが、各社のエゴがでてきてしまったり、そもそも、自社の標準化すらできないのに、数社あわせて標準化なんて、無理ってことで、なかなかできない。

　っていうことで、組合なんかの共同作業は、「標準化」のカベに阻まれ難しい。

---

　ってなると、やっぱ、組合なんかで、一番初めにやることって言うと、組合員のリンクページからかなあ。。と。。
　つまり、組合名と、その会員先へのリンクが載っているサイトを作るのがまず初めかなあ。。。という気がする

・組合員個々のサイトをつくる
　→サイトがない場合は、サイトづくりの協力とかをする
・組合全体のサイトを作る
　→リンクページをつくる
・組合員が扱っているものの検索用の商品マスタをつくる
　→組合サイトから検索できるようにする
・組合員の標準の受注／発注フォームをつくり、標準化する
・商品マスタの標準化
　→検索用の商品マスタをもとに
・EDIへ

ってなかんじかなあ。。

　つまり、EDIやマーケットを作ろうなんて、大きなことを考える前に、
　まずは、リンクページから（＾＾）

新たな電脳的脅迫手段？「業務停止しないと顧客にウィルス送りつけるぞ！」

ここのニュース
スパム防止業者、スパム業者とのスパムメールの応酬に敗れる
http://slashdot.jp/articles/06/05/20/2333253.shtml

このニュースに自体については、さておき、最後の部分
（以下斜体は上記ニュースより引用）

さらにスパマーは、同社が業務を停止しなければ、その顧客に対してウイルスを配信するという脅迫メッセージを送付。これを受けて、同社はやむなくサイトを閉鎖することになったとのこと。


　これって、新たな、脅迫・詐欺手段になりそう。。

　入手した顧客名簿の全員に、ウィルスを送りつけて、顧客名簿が漏れていることを公表するので、されたくなかったら、どこどこに、いくら振り込め。。
という形。。。。

　とくに、
Yahoo!BB顧客情報流出事件で一人あたり6000円の賠償命令
http://slashdot.jp/security/06/05/19/1318226.shtml
ってことで、顧客名簿１人漏れて、５００円っていう相場が否定され、６０００円払え！って裁判所が決めたあとですからねえ。。。

　この事件が問題なのは、脅迫なのか詐欺なのか、区別がつかないこと。
　つまり、本当に顧客名簿が盗まれているのか、盗まれてないのに、あたかも盗んだようにだましているのか、言われたほうはわからない点。

　うーん、こーいう悪いことをする人の対策っていうのも、けーさつに考えて欲しいものだが、実際は、ネット会社の仕事なのかしら？それとも、サイバー系の探偵とかができて、その人のお仕事？

シェーディングやテクスチャなどのプログラムを書く本、これがわかりやすいと思う！

　iモードにテクスチャマッピングがあるとか、シェーディングがあるとか書きましたけど、そもそも、テクスチャマッピングとかシェーディングって、どーやるんだっけ？？やばやばあ（＞＿＜！）

　とおもって、（って、フーリエ級数展開がわかんねーほーが、もっとやばやばだろうっていうのは、この際ちょっとおいて＝＞あとで出てくる）本でも見てこようと思って、御茶ノ水にいきました。

　お金がないウィリアムのいたずらにとっては、３DCGの本なんて、高そうです。
　っていうことで、安そうな古本屋さんを見たら。。

---

　お、３DCGじゃないけど、ドラゴン本が売ってるじゃん！
　いくらか見てみましょう。。。４０００円って、１４００円しか安くなってないじゃん！ありえなーい！
　４００円なら、２冊一緒に買っちゃうのに、って、どっちがありえなーいんだ！っていうのはさておき、古本屋さんでは、いまいちだったので、三省堂に行きました。

　そしたら。。。

　この本は、すごいじゃん（＠＿＠！）
　シェーディングも、レイトレーシングも、テクスチャーマッピングもプログラム入りでかいてあるう。。買い買い買い！
　とおもって、買いました。

　この本
　C++による簡単実習 3次元CG入門

　そいと、こいつも。。もちょっと基本的な話を見るのにいいかもと思って買ってしまいました。
GLUTによるOpenGL入門―「OpenGL Utility Toolkit」で簡単3Dプログラミング!

---

　で、本を買うために銀行のATMでお金おろしてきて。。う、どこのコーナーだっけって迷ってたら。。。おお、またまた面白い本発見！

マンガでわかるフーリエ解析

この手の本って、結局数学部分はマンガでも、わかりにくいからにゃーとおもってみたら、おおおお、おもしろそー、わかりやすそー。。

　とおもったけど、だめだめ、予算超過超過しすぎちゃうので、また今度。。

　ってことで、今回はフーリエ解析は、買わんことにしました。

---

　てなわけで、こんど、今日買った、３DCGの本を読んで、お勉強したことなんかも、ここに書いていこうと思っています。

同じコンテンツをケータイでもテレビでも適切に見せるもう１つの方法、NHK技研のAdapTV

　まえに、ケータイとゲーム機で、同じコンテンツを同じように見せるには、どうしたらいいかって話で、動作の制御点を処理スピードに応じて変化させながら表示すれば？なんてことを書いた。

　で、その後、iアプリでは、その動作の制御点をActionTaableクラスにいれられて、動作する物体をFigureクラスに入れられて、移動・回転に関してはアフィン変換するメソッドがあるから、それ使えば、あとは、テクスチャマッピングのクラス（もある）でテクスチャして表示できる。
　ってことは、ActionTaableの制御点や実際に変換する物体に関して、回線速度に応じて優先順位を付ければいいんじゃないか。。ってことに、この話は落ち着きそうだ。
　それは、それでおいておいて。。

---

　同じように、ケータイとゲーム機で、同じコンテンツを適切に見せる技術があるようだ。こいつは、ケータイの場合、みにくいので、画像を２倍にするとかもできるみたいだ。

　今日（再放送があると思うけど）のサイエンスZEROでブログの女王（といってもしょこたんではない）の眞鍋かをりさんがやっていた。

　NHK技研が開発したAdapTVというものらしい

　ここ
http://www.nhk.or.jp/strl/open2006/tenji/t15.html

こんなもののようだ（以下斜体は上記ページより引用）


特長
・多様な視聴環境と放送内容に応じて受信機側でコンテンツを変換し、
　視聴者にわかりやすい形で最適に提示します。
・視聴環境を示す情報（プロファイル）と放送内容の説明情報（メタデータ）
　から、知識ベース＊を使った推論などの知的処理を行います。
・具体的な実施例を以下に示します。
　　ディスプレイの大きさと映像の内容に応じて映像を切り出し、
　　適切な大きさで表示します。

　　　：
　　（以下省略）

　サイエンスZEROでは、サッカー中継のとき、ケータイでみると、ボールがわからなくなってしまうので、ボールの周りだけ２倍にするというのをやっていた。
　これは、ボールと選手だけを、情報を切り取って持っていて、それを受信するときに、２倍なんなり、なんかにするらしい。

これについて、５月２５日、NHKの技研の講堂で発表があるらしい
　スケージュールはここ
　時間は午後 3：25から。。

　ちなみに、これ以外でも、いろいろ展示してるらしい
　サイエンスZEROでも、ほかにいろいろ紹介してた。
　くわしくは　ここ　技研公開２００６　http://www.nhk.or.jp/strl/open2006/index.html