ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

Javaマスコット「Duke」もオープンソースに

2006-11-14 20:56:07 | Weblog

ここのニュース
Javaマスコット「Duke」もオープンソースに
http://www.itmedia.co.jp/news/articles/0611/14/news091.html


によると、Duke君も、オープンソース(ライセンスはBSDなんだって。GPLじゃなくって。。。って、正直よくわかんないのだが ^^;)になるそうな。。

 おお、じゃあ、ホームページにも、はれるのかなあ。。

 年賀状の図案にも、使えるのかなあ。。

。。。って、年賀状にDuke君を書いても、業界の人でなければ、
不気味なキャラクターになっちゃうか(^^;)

。。。プリクラやケータイのフレームには、流行りそうもない(^^;)
(わかんないけど。。。最近は、コー言うのが、かわいい。。って、そりゃないか ^^;)


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

成人識別たばこ自販機が導入されるけど、一番儲かりそうなのは?

2006-11-14 18:41:17 | Weblog

 タバコの自動販売機、成人が発行するICカードがないとダメっていう
「成人識別たばこ自販機」が導入されようとしてますね。

ここのニュース
成人識別たばこ自販機 08年春鹿児島お目見え
http://373news.com/modules/pickup/index.php?storyid=1260


で、このICカード、「taspo」(タスポ)というそうだけど、ただ、
成人識別をするだけでなく、電子マネー機能も備えるというそうです。




このプロジェクトに関しては、日経コンピューター2006年11月13日号、
”たばこ協会、「800億円プロジェクト」の全容判明
自販機での成人認証に向け、3000万人分のID管理”
ってあって、コンピューター的な流れについてはかいてある。

このプロジェクトは、NTTデータが受託して(プロジェクト管理はNTTデータみたい)
っていうことだったけど、お金の流れ(つまり、800億円の流れ)
については、説明していなかった。




で、それについて説明してたのが、今日のオープニングベル、

 たばこ自販機
 成人識別をめぐるビジネス
http://www.tv-tokyo.co.jp/biz/obell/days/061114/o1.htm


ただし、特集の中ではなく、最後のエンディングで、末武アナがフリップの一部に
手書きで書いて説明してたんだけど、

JTが650億、のこりを外国のタバコ会社とかが出して、800億くらい。
で、そのお金が、いったんNTTデータにはいり、これは、どうも計上済み?
で、そのあと、各社が、開発して、まあ、お金を分けるわけだけど。。。

そのフリップにも、そして、上記の日経コンピューターにも、書いていない
会社名をちょこっと言ってた。

買い替えってなると、機械の置き換えで、自販機メーカーにもお金が入ってくる。

自販機メーカーとしては、富士電機リテイルシステムズなどって、これは、今日の特集を説明する人がいっていた。




上記日経コンピューターによると、800億円の内訳は

  システム開発費用  約380億円
  自販機交換費用   約420億円
  運営費       約100億円(年間)

だそうな。

うーん、このプロジェクト、一見すると、電子マネー部分をやり、一挙に、
2000万人以上の顧客をつかみそう。。っていうのが、話題?かもしれないけど、

一番儲かるのは、ひょっとすると、自販機メーカー??



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

建築用でも、農業用でも、ビジネス、宇宙開発、軍事でも汎用的なロボットを作るとしたら。。

2006-11-14 17:39:21 | Weblog

 以前、ロボットでも複合機でも使えるようにするためのMVCの考え方というのを書いたんですけど、その後の話、「View側(画面が普通だが、ロボットもあり得る)でどこまでの機能を持たせるのがいいかという話」ということについて、書いていないのでその話。




 たとえば、建築用でも、農業用でも、ビジネス、宇宙、軍事でも汎用的なロボットを作るとした場合を考えます。建築用ロボットは、軍事には使わないよ!という意見もあるかもしれませんが(いや、まてよ、そんなことないか^^;)建築用にもいろいろな用途があるわけで、それらの条件をみたすには、もっと極端な例を考えればよい!ってことで、軍事用とか、一見関係ないのまで含めて考えます。

 で、これらは、人間は、すべてやっているのだから、人型ロボットを用意すればいいということになります。

 でも、ロボットの個体ごとに、値は少しづつ違うだろうし、用途によっては、二足歩行でなくてもいい場合もある。

 じゃあ、その汎用的なロボットを、どう設計していけばいいかということになると。。。
 人型なんだから、人と同じようにとりあえず考える。

 大脳で考え、小脳で運動系をやって、反射なんかは、脳までいかない。。
 っていうふうに、重層構造になっている。
 この前のブログに書いたように、MVCの考え方は、何段にでも、階層的にできるので、人間と同じような階層構造にしましょうっていうことになる。

そーすると、

1.センサーの値を数値にして返す、アクチュエーターに対する値に基づき動くというレイヤ
    →目とか手とか、そういう器官に相当する

2.基本的な汎用的な動作(歩くとか、走るとか、乗るとか)を示すレイヤ
    →反射や、小脳の運動系の処理に該当する

3.建築用、軍事用などにおける、ロボット単体の目的に合った動作をさせるレイヤ
    →相手を認識して機関銃を撃つとか、みかんを認識してみかんを摘み取るとか
    →大脳あたりの処理になってくる。運動を状況によって統合する

4.複数のロボットに対して、あんたは、これして、あんたはこれして、と操作する
    →管理職に相当する


のように、4段階にわけて、レイヤ化する必要があると思う(もっと細かくっていうのはあるかもしれないけど)。

 そして、たとえば、車輪がついてるロボットと、2足歩行ロボットでは、3のレイヤから2のレイヤに対し、「歩く(200m)」っていう命令をしても、それによる、アクチュエーターの動き方は、2のプログラムが車輪がついてるロボットと、2足歩行ロボットでは違うので、2のレイヤから1のレイヤに対する指示は、車輪がついてるロボットでは、車を動かすことになるし、二足歩行では、あるく指示がでることになる。

 で、1、2,3はロボット本体のソフトウエアとして搭載され(ただし、3に関しては、プラグイン可能っていうことにして)、4は、サーバーで処理するということになる。

 ただし、宇宙用なんかだと、サーバー地球、ロボット火星では、指示するまでに時間がかかりすぎるので、その場合は、地球の指示を受け、各ロボットに指示を出す現地のサーバーが必要になる。
 何か予期しないことがあった場合は、とりあえず現地のサーバーで自律的に処理し、各ロボットに指示を出し、地球からの連絡を待つという監事の操作が必要になると思う。

 また、軍事用の場合には、サーバーがダウンした場合(壊された場合)、次のサーバーを切り替える手順と、どんなことをしても、サーバーと通信不能になった場合の処理(ロックがかかって動かないなど)を、各ロボット側に持たせる必要があると思う。




 3と4について、4のサーバー側の機能をロボットに持たせるのもありだと思うけど、基本的には、サーバーは分かれるような気がする。

 建築などで、ロボットを動かそうとしたら、2台以上のロボットを協調させて動かすことも多いと思う(長い柱を運ぶ場合など)。そのようなケースでは、建築の手順とロボットからあがってくる進捗に応じて、次はどの作業をさせるかというのは、サーバーを1台立てて、人間がサーバーを監視しながら、ある程度自動化されて指示するという形になると思う。

 で、そのサーバーから各ロボットに対する指示は、無線やケータイ、PHSを使って指示が出されると。。




 MVCをこの前のように円であらわし、それが何段もつなげられるというようにして、さらに、場所を問わないということに考えを拡張したことによって(ウィリアムのいたずらは、これをWeb3.0と呼んでいる。なお、出力先が、画面でも、ロボットの動作でも、汎用的に扱えるという考えをWeb4.0としている)、ロボットに汎用性を持たせることをここでは考えた。

 汎用性を持たせるためには4つのレイヤが必要で、複数ロボットの操作にはクライアントサーバーになるということでした。

 で、ロボットの話はこれくれいにして、次回は、画面の話にしたいと思う。
 その際もロボットの4つのレイヤの考え方を基礎におくことにする。



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

仕様書からプログラムソースを生成する方法(Excelの仕様書編 その13:IF文の使用例)

2006-11-14 15:09:32 | ケータイ

シリーズ仕様書からプログラムソースを生成する方法の続きです。

 現在は、このプログラムは一通り完成したけど、仕様追加で、条件によって出力するというのを、やっています。

 前回、この仕様として、新しく、こんなタグを用意しました

$#$IFCELL セル,値$#$
 指定されたセルが、値だったら、$#$IFEND$#$までの中を書き出します。
 値でなかったら、書き出しません。

$#$IFKETA 桁,値$#$
 繰り返しの中で利用します。
 指定された桁で、現在対象行のセルが、値だったら、$#$IFEND$#$までの中を書き出します。
 値でなかったら、書き出しません。

$#$IFEND$#$
 上記2つのIF文の終わりを示します。


 今回は、そのタグを追加した場合のソースについて、公開すると同時に(ただし、差分のみです)、その例について、書きたいと思います。
(すみません、字数制限で、例までしかかけませんでした)




■使用例
 雛形ファイルは、ここの、「■ソースの変更ポイント」で、枠で囲まれているところのソースとします(これを、gamen_c.txtとします)

 このとき、第一画面の仕様書を、以下のように書きます。


このとき、以下のように書き出します。
/*==================================*/
//関数名:gamen1_InitAppData //
//内容 :領域確保・描画	         //
/*==================================*/
boolean gamen1_InitAppData(fukusu1* poya)
{
	char		*fdata;
	gamen1	*pMe;
	AEERect		rect;

	//==========================================//
	//	領域確保			        //
	//==========================================//
	pMe	=	(gamen1 *)MALLOC(sizeof(gamen1));
	if (pMe	==	NULL )
	{
		gamen1_FreeAppData(poya);
		return	FALSE;
	}
	//	アプリ領域へ設定
	poya->garea	=	(void *)pMe;
	poya->gno	=	1;

	//	初期設定

	pMe->pHc1		=	NULL;

	pMe->pText1		=	NULL;

	pMe->pIDisplay	= poya->pIDisplay;
	pMe->pIShell	= poya->pIShell;



	//==========================================//
	//	表示するHTMLファイルの取得     //
	//==========================================//
	fdata = IHTMLCTL_GetDispFileData(pMe->pIShell,gamen1.htm);
	if (fdata	==	NULL )
	{
		gamen1_FreeAppData(poya);
		return	FALSE;
	}


	//==========================================//
	//	HTMLViewer生成		       //
	//==========================================//
	//	読み込んだfdataをHTMLViewerに設定する
	if ( (pMe->pHc1 
		= IHTMLCTL_Create(pMe->pIShell,pMe->pIDisplay))
			==	NULL )
	{
		FREEIF(fdata);
		gamen1_FreeAppData(poya);
		return	FALSE;
	}

	//==========================================//
	//	HTMLViewerデータ設定	       //
	//==========================================//
	if ( IHTMLCTL_SetDispData(pMe->pHc1,fdata)
		!=	TRUE)
	{
		FREEIF(fdata);
		gamen1_FreeAppData(poya);
		return	FALSE;
	}

	//==========================================//
	//	追加:HTMLViewer大きさ設定     //
	//==========================================//
	rect.x	=	0;
	rect.y	=	0;
	rect.dx	=	240;
	rect.dy	=	200;
	IHTMLCTL_SetRect(pMe->pHc1,&rect);
	
	//==========================================//
	//	HTMLViewer表示・メモリ解放     //
	//==========================================//
	FREEIF(fdata);




	
	//==========================================//
	//	追加:テキストエリア設定	       //
	//==========================================//
	if	( ISHELL_CreateInstance( pMe->pIShell, 
		AEECLSID_TEXTCTL, (void**)&pMe->pText1 ) != SUCCESS )
	{
		gamen1_FreeAppData(poya);
		return FALSE;
	}
	rect.x	=	0;
	rect.y	=	210;
	rect.dx	=	240;
	rect.dy	=	60;
	ITEXTCTL_SetRect(pMe->pText1,&rect);
	ITEXTCTL_SetProperties(pMe->pText1,TP_FRAME|TP_MULTILINE);



	gamen1_DispAppData(pMe);

	//	共通領域を設定
	pMe->pMap	=	poya->pMap;

    return TRUE;
}





すみません。このあと、変更のプログラムを貼ったら、1万字をこえてしまったので(Gooブログは1記事、たしか1万字まで)、今回はここまで。

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

PS3、互換性に不具合のPS2ソフトが200タイトル

2006-11-14 09:16:10 | Weblog

ここのニュース
PS3、互換性に不具合のPS2ソフトが200タイトル
http://japan.cnet.com/news/tech/story/0,2000056025,20311967,00.htm


まーねー、互換性をとるのは大変だし、
さらにそれをテストするとなると。。。。
って考えると、互換性がないソフトが出てくるのはねー。。

 ただ、PS2のときは、互換性に問題がある一覧が出てたのに、PS3になると、検索形式になって、一覧ではわからないようにしたのはなーぜー。。。

 やっぱ、一覧だと、ずらずら並んで、なんか、だめだめにみえちゃうからかなあ。。

 そこのニュースによると(以下斜体は上記ニュースより引用)

PS3では(不具合の)症状に併せて遊んでもらうことができるようにするため、それら(各ソフトの不具合状況)を細かく書いていくスタンスを取っている」としている。


 うん?症状にあわせて遊んでもらう。。。どーなんでしょ(^^;)

 なんか、メーカー側は、ニュースの追記に、
「PS3発売日の11月11日までにソフトの動作に対する修正をするため、我々は寝ずの作業を続けるなど、最大限の努力をしてきた。(中略)我々は利用者の立場を第一に考えている。
 って書いているけど、利用者の立場を一番に考えるなら、徹夜で修正することじゃなくって、障害のあるソフトを一覧で載せることだぞ。。その後、ゆっくり修正したとしても、問題はない。

 なぜなら、PS2用のゲームを持っているお客さんは、PS2は持っている(じゃなきゃ、何でゲームをもってるんだ?)。だから、PS3で互換性に問題がある場合は、それが解消されるまで待つか、それでも、PS3を買うか、どちらかの判断ができる。この場合、顧客にそんなに不満はない。自分の意思で選択して、動かないとしてもわかって買っているわけだから。

 でも、今のように、利用者にとってわかりにくい状態で提示されてしまったら、お客さんはそれを知らないで、つまり互換性があり、PS3でも動くと思って買ってしまう。それが動かなかったら、「だまされた!」って言うことになる。お客さんは不満!!ってなる。そりゃーそーだ。動くと思って買ってるのに、動かないんだから。。。
 そしたら、そのお客様に対して、徹夜で対応するって言うことになってしまう。

 もともと、出荷台数が少ないんだから、本来、今買うべきでない人には買わないで、あとで買ってもらえるように、購入者を散らすべきだ。そのために、後で買ったほうがいい購入者情報(たとえば互換性状況一覧など)は、積極的に、わかりやすく流したほうが、企業にとって、非常に得なはずだ(一時的に売れるより、継続的に売れたほうが、経費のかかりかた、在庫の読みやすさでも違う)。
 なのになのに、こーいうみにくいカタチで流すって言うのは。。。どうなの。。。

 検索ができるなら、一覧表示もかんたんにできるはずで(プログラムのCGIなりPHPなりを一覧形式に修正すればいいだけだから)それを出さないってことは、顧客に対してやはり、不親切じゃないのかなあ。。もちろん、この場合でも、詳しい情報は検索サイトで出すって言うことにはなるんだろうが(その一覧から検索サイトへとび、さらに現行の検索サイト独自でも使えるようにする)。正直、利用者に不具合の全体像を隠すための不親切な態度と見られてもしょうがないんじゃないかなあ。。。

もっとも、メーカーが一覧出さなくても、結局、
PlayStation3初期不良まとめwiki
http://wiki.livedoor.jp/yuuyaap1/d/damePS2list1

っていうふうに、一覧がでちゃうんだけどね(^^;)。。。


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする