仕様書からプログラムソースを生成する方法（Ｅｘｃｅｌの仕様書編 その１５：下に続く場合－問題点）。

　以前やっていた仕様書からプログラムソースを生成する方法の続きとして、またちょっと書きます。

　いままで、これを利用してＢＲＥＷの仕様書を出すという話、TextとHTMLは対応しているのですが、メニューに対応していません。

　それは、メニューは問題があって、その問題の解決法を示さないといけないからです。

　で、この問題が解決しないと、イベント部分もできず、さらにそうすると、先ほど書いた、iアプリとも一緒に対応することができないのです。

　ということで、今回は、その問題について書きます。

---

■問題点

　もし、メニューもやるとすると、以下のような形になると思います。


つまり、メニューの部品を書いて、その下に、メニュー項目を書くという形になります。

イベントと関数も追加したら、さらにその下にイベントを書くことになるでしょう。

ところが、雛形は、

#$REP 5$#$
　　　繰り返したい内容
$#$REPEND A$#$

のように、REPタグで、何行目からはじめるか、指定してしまいます。
そうすると、部品は５行目から書くのでいいのですが、
　　メニュー項目は、部品が終わって、数行開いたところから、
　　イベントも書くとすると、メニューが終わった後、、数行開いたところから
書くはずなので、メニューとイベントの書き始めが決まらず、
#$REP 5$#$
のように、行数が指定できません。どうしましょう。

---

■解決策：かきはじめに、下にあるものを横に書く
　これは、出力を始める前、つまり、ＶＢＡのマクロのinitAppDataのなかで、
１．新しいシートをつくり
２．備品までをコピーし
３．メニュー項目はＰ桁の５行目から、書き始めるように移して
４．イベントはＵ桁の５行目から、書き始めるように移します。

そうすると、メニュー項目の繰り返しは
#$REP 5$#$
　　　繰り返したい内容
$#$REPEND P$#$

イベントは
#$REP 5$#$
　　　繰り返したい内容
$#$REPEND U$#$
となってかけます。

このシートは処理が終了したfreeAppDataで削除します。

---

このシリーズの次回以降において、もっと具体的な解決策を書いていきます。

ソフトウエアの品質管理とか、知識体系のメモ

■ソフトウエアにおける品質管理
●ＩＳＯ９０００－３と、ＩＳＯ９０００３
　ＩＳＯ９００１が品質管理の標準とされたが、それが摘要しにくいということで、ＩＳＯ９００－３が生まれた。その後ＩＳＯ９００１が、２０００年に改定され、それに対応する形で、ＩＳＯ９０００３が作成されている。

詳しい経緯
http://www.itscj.ipsj.or.jp/topics/tr90003.html

ＩＳＯ９０００３のポイント（英語）
http://www.praxiom.com/iso-90003.htm


●共通フレームＳＬＣＰ－ＪＣＦ９８
　ＩＳＯ９００３、ソフトウエアの品質管理をさらにひろげて、ソフトウエア全般にかんする、供給サイド、需要（取得）サイド両者のソフトウエアにおける「共通のものさし」が必要になった。
　ソフトウエア全般（ソフトウエアライフサイクル）にわたる規約としては、ＩＳＯ１２２０７があるが、これを日本で、ものさし化？したもの。

概要（体系図：ＰＤＦ）
http://www.meti.go.jp/policy/it_policy/si_so/si_slcp98.pdf

---

■品質管理を含んだソフトウエア開発のモデル

●ＣＭＭＩ
ソフトウェア能力成熟度モデル、ソフトウエア開発をレベル化し、そのレベルで達成すべきプロセスについて書いてある。

概要
http://www.netlaputa.ne.jp/~hijk/study/pmp/cmmi_overview.html

---

■知識体系

●ＳＷＥＢＯＫ
　ソフトウエア開発の知識体系
団体（英語）：
http://www.swebok.org/

●ＰＭＢＯＫ
　プロジェクトマネジメントの知識体系
概要
http://pmos.jp/honpo/method/PMBOK.htm
ウィリアムのいたずらページ
http://blog.goo.ne.jp/xmldtp/e/98b7a1f786a573bdbee81394da813653

●ＩＴＩＬ
　運用の知識体系
概要が書いてある本が買える（そこの書籍のところ）
http://www.itsmf-japan.org/itil/

---

■各社の開発体系（標準）

●富士通ＳＤＡＳ
http://magazine.fujitsu.com/vol57-1/2006_01.html

●ＮＥＣ　WATool
http://www.nec.co.jp/products/pdf/WAtool.pdf

BREWでiアプリっぽくリスナーをつけるため、１イベント１関数にする方法（その１：概要）

　いままで、シリーズBREWで複数画面を開発する場合の方法論をやってきましたが、

今後の方向性として、
　　iアプリの高レベルAPI(Panelを使うやつ）と、
　　BREWの画面（コントロールを使うやつ）について、
BREWでいままで書いてきたExcel仕様書をつかって、雛形を切り替えるだけで対応する

という話をやりたいと思ってます。

---

　で、その話をするためには、iアプリのイベントというか、Javaのイベント処理方法と、BREWのイベント処理方法をあわせないといけません。

　で、そのためには、なにをしたらいいか。

　ＢＲＥＷプログラミング実践バイブルの（私の持っている第１版第２刷では）９１ページに書いてある

イベントモデルとコントロールコンテナは表裏の関係にあり、階層化されたコントロールコンテナのフォーカス管理が存在して

とありますので、これを実現すればよさそうに見えます
（これが実現されていないのでＢＲＥＷはだめだめだ！というのが、上記の本の主張でなので）。

　で、これを実現する方法をこれから書いていくのですが、いっぺんに書くと・・・
　？？なんじゃこりゃ？？

　と奇想天外プログラムになってしまううえ、

　そこまでしなくても、実は、BREWとiアプリを仕様書レベルで共通化できるので、

　まあ、順番にやっていって、適当なところでとめることにします。

---

■方針

　では、どのようにやっていくかというと、

・Javaのように、イベントリスナーをAddして、そのイベントが起きたとき、
　指定された関数に飛ぶようにします

・このイベントを階層化します

・ＢＲＥＷのコントロールとiアプリのコントロールを対応させます
　→その際BREWのコントロールに皮をかぶせて、この中にイベント処理を入れます

・ＢＲＥＷのコントロールの対応アクションとiアプリのコントロールの対応アクション
　を対応させます

　で、まずは、イベントリスナーの話から

---

■仕様

　つまり、どういうことをやるかというと、

１．あるイベントが発生したときに、ある関数に飛ぶように登録します
　　→Javaだと、画面クラス.addなんとかListener(クラス）ってするんですけど、
　　　ＢＲＥＷには、クラス概念はないので

　　　　　add(画面クラス,関数）

　　　とやることにします。

２．そのイベントがきたら、登録してある関数をディスパッチします

３・結果として、イベントごとに関数を用意すれば、その関数に飛んでくれることになります。

・そして、２のディスパッチを、アプリ－現在表示画面－部品と階層化すれば、
階層化されたコントロールコンテナのフォーカス管理画実現するのですが、

　今回は、上記１、２、３を実現します。
　話を簡単にするため、アプリレベルで考えましょう。

---

■概要

で、どうやるかというと、

１．まず、イベントを保持しておくリストを用意します。
　そのリストは、こんなかんじ

typedef struct _IEventList
{
	int		eventsu;		//	イベントの数
	int		*kind;		//	判断種別
	AEEEvent	*eCode;			//	コード
	uint16		*wParam;		//	第一詳細引数
	uint32		*dwParam;		//	第二詳細引数
	PFNAEEEVENT 	*func;		//	呼び出し関数
	void		**pArg;		//	引渡し関数
} IEventList;

２．アプリのinitAppDataで、そのイベントリストを生成し、
　　イベントを登録します。

	//	イベント領域確保
	if ( (pMe-＞pElist = IEVENTLIST_Create() )	==	NULL )
	{
		return FALSE;
	}

	//	イベント設定

	//スタート時に、event1_STARTEventを実行
	IEVENTLIST_Add(pMe-＞pElist,pMe,0,EVT_APP_START,0,0,event1_STARTEvent);

	//クリアキーが押されたら、event1_CLREventを実行
	IEVENTLIST_Add(pMe-＞pElist,pMe,1,EVT_KEY,AVK_CLR,0,event1_CLREvent);

（上記＞は、本当は半角）

３．イベントがきたら、イベントリストをチェック
　　イベントがあったらディスパッチします（下記のIEVENTLIST_HandleEvent）

	if ( pMe	==	NULL )
		return	FALSE;

	if ( pMe-＞pElist	==	NULL )
		return	FALSE;

	return	IEVENTLIST_HandleEvent(pMe-＞pElist,eCode,wParam,dwParam);

（上記＞は、本当は半角）

４．アプリ終了時(freeAppData)に、解放します

	IEVENTLIST_Release(pMe->pElist);

---

そうすると、このとき、以下の関数を作ればいいことになります。

//　　　生成
IEventList　*IEVENTLIST_Create();

//　　　解放
void　IEVENTLIST_Release(IEventList *pMe);

//　　イベント登録（addListenerにあたる）
int　IEVENTLIST_Add(IEventList *pMe,void* pArg,int kind,AEEEvent eCode,
　　　　uint16　wParam,uint32 dwParam,PFNAEEEVENT func);

//　　イベント処理（ディスパッチ）
boolean　IEVENTLIST_HandleEvent(IEventList *pMe, AEEEvent eCode, uint16 wParam, uint32 dwParam);

次回は、これらの関数の中身についてです。

依存性の問題の対応策（その５：引数の共通化で継承を使う場合）

　シリーズ依存性の問題の対応策の前回書いた内容について。

　仕様変更が多かったり、汎用化させたいため、引数を共通化する場合、

１．いくつかの引数を１つのハッシュマップに入れてしまうという方法があります。
　　この場合、ハッシュマップに入れるときに、クラス化すると、クラスが
　　変わったことによって、エラーではじくことができます
　　（あと、ハッシュマップの場合は、キーを変えることでもはじけます）

２．引数を汎用的な型から継承させ、メソッドの引数自体は、その汎用的な型のほうを
　　書く。

　　Strutsなどでは、これが利用されています。

　　画面（フォーム）の値はActionFormという型から継承します。
　　たとえば、No1ActionFormという画面があったら、

public class No1ActionForm extends ActionForm
{
　　private String val1;
　　private String val2;
:
setter/getter続く
}

という形で、ActionFormから継承させて、各画面の値をもつクラスをつくり、
実際に呼び出されるメソッドは

public ActionForward execute(ActionMapping mapping,
　　　　　　　　　　　　　　ActionForm form,
　　　　　　　　　　　　　　HttpServletRequest req,
　　　　　　　　　　　　　　HttpServletResponse res)
{

というかんじで、派生させた、ActionFormを引数とします。
そして、executeのメソッドの中で、

No1ActionForm no1form =(No1ActionForm)form;

とキャストして使います。

　では、１と２、どのように使い分けるのでしょうか？

---

■ポイントは、汎用的にやることがあるかと無規則でよいか

　世の中の流れ的に言えば、POJO（extendsって書いてない、Javaのオブジェクト、
これでも、オブジェクトからは、継承されてるけど）なんつー言葉が出てくる
くらいですから、あんまり、継承されたくはないということになります。

　継承が深いと、「このメソッド、どこのクラスに記述されているの？」なんていう
ことになったり、継承しているものも管理しないといけない（継承元の依存性がかわり、
引数が１個抜ける場合、継承先のものにも影響が出てしまう）など、めんどっちいので。

　ただし、以下の２つの場合、あえて継承したのを使うこともあると思います
・汎用的にやることがなにかある
・無規則だとこまる

　たぶん、Strutsの場合は前者のような気がします。
　システムで、引数に対して、共通に何かしているのでしょう。
　この場合は、継承しないとできないので、継承させる必要があります。

　無規則だとこまるというケースは、ハッシュマップに入れてしまう場合、
　どーにでもいれられるので、それはやだ。なんか、決めておきたいというときです。
　まあ、この場合も、将来的に、汎用的に何かやりたい場合が多いんですが
　（なので、無規則だと、今はいいけど将来困る）

---

■逆に、ころころ変わるのは、ハッシュマップに入れちゃうほうがはやい

　逆に、継承しないほうがいいのは、引数がころころ変わりそうなとき
（仕様が不安定、あるいはない）。
　この場合は、前回のように、クラスにいれてからハッシュマップっていうのもしないほうがいい
　単純にキーワードと値の組をputして、ハッシュマップを引数として渡したほうが、
　仕様の変更にすばやく対応できる。

---

てなかんじですかね（＾＾）
ウィリアムのいたずらは、カオル姫方式っぽく、
ハッシュマップになんでも詰め込んでしまうのが
好みです。

近畿大学ＨＰ、「既卒者は肉体労働に近い職を探すことになります」。ＳＥやプログラマは？

近畿大学のホームページで、「新卒で就職出来ていない人は欠陥品」と載せて、
削除した話は、まあ、知られていると思うが、

ここのニュース
フリーターは惨め」　近大、ＨＰの文章削除
http://www.sanspo.com/sokuho/1129sokuho026.html
によると（以下、および上記の斜体は上記ニュースより参照）

以下のような文章もあったそうな


「既卒者は肉体労働に近い、人が敬遠するような職を探すことになります」という表現もあった。


えー、既卒者、つまり中途採用で、ＳＥ、プログラマ募集って、よくありますよね。
上記の表現にたっていえば、

　新卒で、ゼミ経由で就職したような人ではなく、

　　中途採用で入ったＳＥ、プログラマ、
　　いやプロジェクトマネージャーでさえも、
　
　実は、人が敬遠するような肉体労働に近い仕事です

という意味に。。なりますよね！

おおお、近畿大学、するどいっつーか、なんちゅーか、ほんちゅーか。。。

Javaの画面表示－その２：ＪＳＰで表示部分、サーブレットで処理部分（その３：配置）。

シリーズJavaの画面表示のつづきです。今、ＪＳＰで表示画面を作成し、サーブレットで処理部分を書くということをやっています。

　前回はJSPのソースと、サーブレットのソースについて公開しました。
　今日は、それらのソースをどこに置くのかということと、それ以外に記述するファイルについてです。

　前回の、ソース作成後以降の手順は、以下のとおりです

１．サーブレットのコンパイル
２．フォルダを作成して、ファイルをおく
３．web.xmlの作成
４．server.xmlの編集
５．Tomcat立ち上げ

　以下、順に説明します。

---

■１．サーブレットのコンパイル
　前回作った、サーブレットshori.javaをコンパイルして、クラスファイルを作成します。
　前回にも示しましたが、servlet.jarというファイルが必要です。
　詳しくは、

JavaでHello World ＞ サーブレット (Servlet)編
http://www.hellohiro.com/servlet.htm
の「◆コンパイル」に出ています。

　なお、Tomcatが、javaの1.4で動いているとき、コンパイルをjavaの1.5でやるといったように、javaの動作環境と、コンパイル環境が違うと、実行時にエラーメッセージが出てえらーになることがありますので、動作環境とコンパイル環境のjavaのバージョンはあわせたほうがいいです。
（「っていうのは、ソース作成するときにいってくれよ！」といわれそうですが。。）

で、うまくいくと、shori.classというのができるはずです。

---

■２．フォルダを作成して、ファイルをおく

今回のシステムのフォルダ構成は、以下のようになります

Tomcatのフォルダ（Program Files/Apache Tomcat 4.0　等）
　　　｜－conf （フォルダ）
　　　｜　　｜－server.xml （ファイル）
　　　｜　（つづく）
　　　｜
　　　｜－webapp
　　　｜　　｜－test
　　　｜　　｜　　｜－jsp
　　　｜　　｜　　｜　｜－index.jsp
　　　｜　　｜　　｜　＊－kekka.jsp
　　　｜　　｜　　｜
　　　｜　　｜　　＊－WEB-INF
　　　｜　　｜　　　　　　｜－web.xml
　　　｜　　｜　　　　　　＊－classes
　　　｜　　｜　　　　　　　　　｜
　　　｜　　｜　　　　　　　　　＊- shori.class
　　　｜　（つづく）　
　　（つづく）

（説明に関係ないフォルダ・ファイルは省略しています）

confフォルダから下のものはあるので、やる作業は
（あ）．webappフォルダにtestというフォルダを作ってください
（い）．testフォルダの下にjspとWEB-INFというフォルダを作ってください
（う）．jspフォルダのほうに、index.jspとkekka.jspをコピーしてください
（え）．WEB-INFにclassesというフォルダを作ってください
（お）．そこにさっき作ったshori.classをコピーします
（か）．（え）で作ったWEB-INFフォルダの下にweb.xmlというファイルを作成します
　　　　　→web.xmlの内容は後述します。

となります。JSPの配置をすでにしていれば、（あ）と（い）のうちのjspフォルダ作成、（う）の作業はやっていると思うので、残りの作業をしてください。
（ただし、（う）の作業中、index.jspは、JSPのみのものと、JSPとサーブレットのものとでは、
　ソースの中身が違うので、index.jspについては、今回コピーが必要です）

---

■３．web.xmlの作成
上記のweb.xmlを作成します。
中身は以下のとおりです

＜?xml version="1.0" encoding="ISO-8859-1"?＞

＜!DOCTYPE web-app
    PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
    "http://java.sun.com/dtd/web-app_2_3.dtd"＞

＜web-app＞

＜/web-app＞

（上記　＜　＞　は、本当は半角です。なので、実際作るときは、これを置換したりするより、
　ここをコピーしたほうがいいかも。
　ちなみにリンク先はJavaでHello Worldでweb.xmlのサンプルがあるところ）
これを、WEB-INFの下にweb.xmlというファイル名で保存します。

---

■４．server.xmlの編集
　JavaでHelloWorldを見ている人は、ひきつづき、＜TomcatへのWEBアプリケーションの登録＞
　ってかいてあるところのことをやってください。
　具体的には、confフォルダの下、server.xmlファイルを開いて、
　ずっと下のほうに

　　　　＜!-- Tomcat Root Context --＞
　　　　＜!--
　　　　　　＜Context path="" docBase="ROOT" debug="0"/＞
　　　　--＞

　　（実際には＜　＞　は半角）

と書いてある行があるはずです。
その下に、以下のように書きます。
　

　　　＜!-- Tomcat UserTest Context --＞
　　　　＜Context path="/test" docBase="test" debug="0"
　　　　　　　　reloadable="true" crossContext="true"/＞

　　（実際には＜　＞　は半角）
　そして、これを保存します。

　なお、この作業は、サーブレットだけ、ＪＳＰだけのときでもやる作業で、事実、ＪＳＰだけでやる方法を紹介したときは、ここの「■手順」の２で、同じことをやっています。

---

■５．Tomcat立ち上げ

　ここでTomcatを立ち上げてStart Tomcatを実行して）ください。
（すでに立ち上げてある人は、Stop Tomcatで一回とめて、その後Start Tomcatを実行してください）。

　で、立ち上がったら、
　http://127.0.0.1:8080/test/jsp/index.jsp

を開いてください。
（ローカルのＩＰはかならず、127.0.0.1です。:8080は、デフォルトなら、そのはずです）

---

■つけたし

　なお、index.jspのファイルで、呼び出し先が、http://127.0.0.1:8080/test/servlet/shoriになっているのに、ファイルを置いているのはWEB-INFの下なのは、間違っているのではなく、これで正しいです（つまり、ファイルシステムのWEB-INF/classesの下が、ＵＲＬ上、servlet/の下になる）

---

以上、配置方法でした。

YouTubeの、携帯電話からのムービー視聴の予定

ここの記事
YouTube、ついに携帯電話からのムービー視聴が可能
http://gigazine.net/index.php?/news/comments/20061129_youtube_mobile/
に、YouTubeの、携帯電話からのムービー視聴についての話（ただし、アメリカ中心みたい）が書いてあります。それによると
（以下斜体は上記ニュースより引用）

サービス開始時期は今年の12月初旬頃を予定しており、1日3ドルか月額15ドルの有料サービスである「V Cast」に加入すると閲覧可能になるという仕組み。閲覧するだけでなく、携帯電話で撮影したムービーを直接YouTubeにアップロードすることも可能。この携帯電話からアップロードする仕組みは今年の5月から実装されており、「YouTube to Go」という名前で呼ばれています。


有料にしちゃうのですね。

でも、それより

著作権侵害の可能性のあるムービーやアダルトムービーの閲覧はできないようになっているとのこと。

おお、どーやって、チェックするんだろう。。。
このチェックは、将来ＰＣにも（つまり、今のYou Tubeにも）入ってくるんだろうか？

高橋名人とニンテンドーＤＳブラウザと、ゲーム市場

高橋名人が「１６連射のつぶやき」でつぶやいている、いや吠えている（＾＾；）
ここの痛いニュース

高橋名人「とあるゲーム雑誌は勘違いをしている」
http://blog.livedoor.jp/dqnplus/archives/862604.html

によると（以下斜体は上記ニュースより引用）


今までにも、私は何回か言っていますが、いままでのゲーム業界が目指していたのは、ピラミッドの頂点であって、しかし実はもっと目指さなければいけないのは、ピラミッドの中腹から底辺に近いところにいるユーザーなのです。

テクニック重視のゲームも、もちろん必要かもしれませんが、そのピラミッドの中腹に居られる方にとって大事なのは、そのゲームが面白いという意見が直感的に出てくることだと思います。
遊べるというのは、ゲームの完成度ではなく、それが直感的に遊べるかどうかだと思うのです。

ピラミッドの頂点を目指したために、ダメになったジャンルがあるのに…
で、それを今でも引っ張ろうとしていて、それが頂点を走っていると勘違いをしている雑誌社とかがあるので、こういう意見を言いたくもなってきてしまいました。


まず、この手の話題の場合、ゲームと雑誌では同じ市場でも、表現が違うことは、
確認しておく必要があると思う。

雑誌社の場合もゲームメーカーの場合も、メイン市場は、顧客層の多いピラミッドの中腹から底辺に近いところにいるユーザーの市場だとは思うのですが、雑誌社の場合、その人たちに、あんたは中流ですよ！ということを再認識させる雑誌を作っても売れない。
　雑誌の場合は、中流の人が読んで、ちょっとハイレベル！っていう雰囲気を出せるほうが売れるのだ。

　ファッション雑誌でかんがえてみるとわかる。
　ＪＪやＣａｍＣａｍを読んでいるお姉さま方は、みんな、エビちゃん似かっていうと。。。（＾＾；）
　でも、ふつーのオネーサンがでても、雑誌としては売れない。なので、ちょっとレベルたかめの、押切もえにしろ、エビちゃんにしろがでている。

---

　しかし、洋服で売れるのは、エビちゃんレベルも売れるけど、Ｔシャツも良く売れるわけで、メーカーとしては、エビちゃんレベルも意識しながら、Ｔシャツを手がける。ここで、メーカーが注意しないといけないのは、洋服を買っている人はエビちゃんレベルでは、かならずしもない（つーか、エビちゃんみたいなおねーさまは、そーそーいないって　＾＾；）、でも、売れる洋服は、エビちゃんレベルの場合もあるし、それより１段下の現実路線の場合もあるってことだ。

　ゲームメーカーも同じで、雑誌社は頂点を書かないと売れないが（ＪＪに、ふつーのねーちゃんが出ても売れないが）メーカーは、エビちゃんレベル（頂点）も、ふつーのねーちゃんレベル（中腹）も、両方ださないといけない、どっちを出せば、今のタイミングでは売れるかは、まあ、メーカーの読みになってくるっていうことだ。

---

　っていうことで、雑誌とゲームはちがうんで、高橋名人の言っていることは、まあ、微妙ではアル。微妙ではあるのだが、この議論は、十分意味ある、考えなきゃいけないお話ではあるのだ。

　この話を読んで、ハドソンってことで、高橋名人は、ニンテンドーＤＳの数独を意識してるのかなあ？と思った。

　たしかに、あのゲームは、中腹レベルをねらったように見えるゲームである。

　しかし、この手のゲームばかりを出していた場合、問題がないかというと、そうではない。

　というのも、ニンテンドーＤＳの、ブラウザができてしまったことにより、ゲーム屋さんでない人たち、アマチュアや学生さんが趣味でゲーム市場に参入してくる可能性ができてしったからだ。

　つまり、ユーザーインターフェースがブラウザで、すんでしまうため、グラフィックがこったものでなければ、ゲームメーカーでなくても作れてしまう。

---

　具体的に言うと、数独をたしかに自動的につくるのは難しいだろう。

　しかし、１００問問題を考えて、それを乱数で選んで出題するようにするのであれば、JavaScriptがかければ、ブラウザでできる可能性は大いにあるのだ。

　ってことで、ニンテンドーＤＳのブラウザが出てきてしまったので、グラフィックにこだわらないのであれば、いろんなゲームが、ゲームメーカー以外でも作れることになってきた。ここで、ニンテンドーは、ゲームメーカーは、どう動くか（グラフィックにこだわらず、アイデア勝負で素人と競い合うか、それとも、グラフックに力を入れるか）ってことは、戦略になってくるだろう

---

　てなわけで、メーカーよりの意見ではあるが、高橋名人のお話は、
　古川氏のブログのツッコミよりか、まっとうなツッコミだとは思う。。

情報処理技術者試験が資格試験になるかも?、更新制になるかも?

っていう、スラッシュドットにニュースがあったんですけど。。
情報処理技術者試験が資格試験になるかも?、更新制になるかも?
http://slashdot.jp/articles/06/11/28/0927254.shtml

本ねたは、ここだって
情報処理技術者試験の改革論議が本格化－－業務独占の是非や新試験の創設，更新制など
http://itpro.nikkeibp.co.jp/article/NEWS/20061127/255005/

更新制は、べつにいいけど。。
資格試験になっちゃうと、いろいろ問題ありそうな。。

プロジェクトマネージャーは、プロジェクトマネージャー試験に受かってないといけない

っていったら、ちと、大変なことになりそうだ。。

。。。っていうか、オフシェア開発って、できなくなっちゃうんじゃあ？？
（っていうより、プログラマーやＳＥが足りなくなさそうな気が。。）

BREWで複数画面を開発する場合の方法論（その２０：Ｅｘｃｅｌで自動生成－その５：公開しました）

　シリーズBREWで複数画面を開発する場合の方法論のつづきというか、事務連絡です。

　いままで、このシリーズでやってきた、仕様書、および雛形ソースファイル、

　また、プロジェクト作成の際に必要な
　　　　HTMLViewerを扱いやすくした関数群IHtmlCtl.c,IHtmlCtl.h
　　　　画面間引数を保持する共通領域（カオル姫方式ＢＲＥＷ版）IKHMap.c,IKHMap.h

　それと、説明や、その他サンプル用のHTMLなどなどをまとめたものを、
　さっき公開しました。

以下のページ、
仕様書からＢＲＥＷのソースファイル自動生成
http://www.geocities.jp/xmldtp/bw_makebrew.htm
にいってもらったら、一番下に

ダウンロード：
　　　　makebrew.lzhのありかは、ここ

という言葉がありますので、「ここ」をクリックしてください
（geocitiesの場合、圧縮ファイルのＵＲＬを直接ブラウザに入れて、アクセスしようとすると、準備中になってしまうみたいです）

　今回公開しているものは、まとまっているので見やすいのと、あと、いままで、雛形ファイルにバグがあったのですが、そいつも、ちょっとなおしておきました。

---

　なお、これは現状のまとめということで、
　いま、部品のメニューコントロールがはいっていないのですが、
　それについては、ちょっと説明しないといけないことがあるので、
　今回のには入れていません（といっても、今後アップデートするかは不明ですが）。。

　また、修正についても、どう修正したらよいか、
　完成品が入っていないので、分かりにくいと思います。
　それも、今後、アップデートする機会があれば、アップデートしたいと思います。

　ということで、以上、事務連絡でした。

Javaの画面表示－その２２：ＪＳＰで表示部分、サーブレットで処理部分（その２：ソース）。

シリーズJavaの画面表示のつづきです。今、ＪＳＰで表示画面を作成し、サーブレットで処理部分を書くということをやっています。

　基本的には、
　　　・入力画面からサーブレットを呼び出し、
　　　・サーブレットでは、処理をして、表示内容をセッションに入れ、
　　　　　　　　　フォワードして表示画面を呼び出し
　　　・表示画面では、セッションから値を取り出し表示する
　という方法をとることにしました。
　つまり、値はカオル姫方式で、そして、サーブレットとJSPの呼び出しはフォワードを使います

　仕様について、及び必要なファイルは、前回書いたとおりです。
　そこにあるように、
JSPは、
　　・入力／エラー画面・・・JSP (index.jsp)
　　・結果表示・・・JSP(kekka.jsp)
サーブレットは
　　・処理部分・・・サーブレット(shori.class)
が必要になります。

　今回は、そのソース内容を説明します。

---

■入力／エラー画面 (index.jsp)ソース
　入力エラー画面のＪＳＰは、以下のとおりです。

＜html＞
＜head＞
＜%@ page session="true" %＞
＜%
//==============================================//
//	画面用の部分			  //
//==============================================//

//	セッションを変数に入れる
	String msg = (String)session.getAttribute("msg");
	if ( msg	==	null )
	{
		msg	=	"";
	}


//==============================================//
//	以下、画面表示			   //
//==============================================//
%＞
＜title＞早打ちの練習＜/title＞
＜/head＞
＜body＞
＜h1＞＜font color=red＞＜%=msg%＞＜/font＞＜/h1＞
＜H1＞早うちの練習＜/H1＞
以下の文を打とう！＜BR＞
＜B＞This is a pen＜/B＞＜BR＞
＜form method=get action="http://127.0.0.1:8080/test/servlet/shori"＞
＜input type=text name=nyuryoku size=20＞＜P＞
＜input type=submit name=do value=打ち終わった！＞＜P＞
＜/form＞
＜/html＞

　上記＜　＞は、本当は半角です
　赤字は、すべてＪＳＰで作った場合と、違っているところを示しています。


■処理部分（shori.java)ソース
　処理部分のサーブレットのソースは以下のとおりです

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class shori extends HttpServlet {
	public void service(HttpServletRequest request, 
                      HttpServletResponse response) 
                          throws ServletException, IOException {
		//セッション開始
	 	HttpSession session = request.getSession(true);
 
		//==============================//
		//	データの取得	     //
		//==============================//
		//Fromの引数取得
		String nyuryoku = request.getParameter("nyuryoku");
		if ( nyuryoku	==	null )
		{
			session.setAttribute("msg","なにも入力されてません");
			getServletContext().getRequestDispatcher("/jsp/index.jsp").forward(request,response);
		}
		else if ( nyuryoku.length()	==	0 )
		{
			session.setAttribute("msg","なにも入力されてません");
			getServletContext().getRequestDispatcher("/jsp/index.jsp").forward(request,response);
		}

		//　処理
		int	i,atari;
		atari = 0;
		String chk = "This is a pen";
		for(i = 0 ; i ＜ nyuryoku.length() ; i ++ )
		{
			if ( i ＞= chk.length() )
			{
				break;
			}
			else if ( chk.charAt(i) ==  nyuryoku.charAt(i) )
			{
				atari++;
			}
		}
		//==============================//
		//	ビューにフォワード	     //
		//==============================//
		//	結果の設定
		session.setAttribute("msg","");
		session.setAttribute("ritu",Integer.toString(atari*100/chk.length()));
		//	フォワード
		getServletContext().getRequestDispatcher("/jsp/kekka.jsp").forward(request,response);
	} 
}

　上記＜　＞は、本当は半角です
　赤字は、すべてＪＳＰで作った場合のshori.jspと、違っているところを示しています（jspもサーブレットも基本的には、似たようなプログラムを書きます）。

　なお、コンパイルするとき、servlet.jarが必要です。くわしくは、ここの「◆コンパイル」を参照

---

■結果表示(kekka.jsp)ソース
　結果表示のＪＳＰのソースは以下のとおりです

＜html＞
＜head＞
＜meta http-equiv="Content-Type" content="text/html; charset=shift_jis"＞
＜%@ page session="true" %＞
＜%
//==============================================//
//	画面用の部分			   //
//==============================================//

//	セッションを変数に入れる
	String ritu = (String)session.getAttribute("ritu");


//==============================================//
//	以下、画面表示			   //
//==============================================//
%＞
＜title＞早打ちの練習＜/title＞
＜/head＞
＜body＞
＜H1＞結果＜/H1＞
正解率 = ＜%=ritu%＞＜BR＞
＜/html＞

　上記＜　＞は、本当は半角です
　赤字がないように、これはすべてＪＳＰで作った場合のkekka.jspと同じです。

---

　ということで、今回はソースを公開しました。
　次回のこのシリーズでは、これらのソースをどこに置くのかとか、これ以外の必要なファイルの作成、修正についてです。

ライブドア、最終損益が４０８億円の赤字に

ここのニュース
＜ライブドア決算＞最終損益が４０８億円の赤字に　
http://headlines.yahoo.co.jp/hl?a=20061127-00000133-mai-bus_all

あちゃー、ぼろぼろっすね（＾＾；）
そのニュースによると

特別損失が３７１億円に膨らんだ。


ってあるけど、特別損失が３７１億、
で最終損益４０８億の赤字ってことは。。。
結局経常利益の段階でも、赤字ってことっすよねえ。。

えーっと、一言で言って。。だめだめっすね（＾＾；）

ま、イメージ悪化で宣伝ださない会社が増えたわけで、
当然といえば、当然なんだけどね。。

依存性の問題の対応策（その４：引数の共通化しても、実行時に知らせる方法）

なぜか、シリーズ化してしまった、依存性の問題の対応策、前回は、汎用性を高めるため、引数だけ、共通化するという方法を書きました。
　具体的には、

１．引数をハッシュマップなどにいれ、そのハッシュマップを引数にする

　　か、Strutsなどで利用されている

２．引数を「ある型」から継承したものにして、メソッドの引数には、「ある型」を書く

ということについてあげました。

今回は、１において、コンパイルでは、引数は共通だから通るんだけど、実行時には、落ちて分かるようにする方法を書きます。実は、この方法、２では、同じ仕組みでわかるようになってます。

　では、それについて書きます。

---

■「引数は共通」だけど、実行時に落ちる方法（変更前）
　いままでの例である、エラーメッセージを出すという話です。

　今回は、引数をまず、argというクラスの中に入れ、そのargを、ハッシュマップにセットします。
　argの内容は、以下のとおり

public class arg {
	public	String	msg 	= 	null;
}

そーなると、a（呼び出し側）は、こんなかんじ

import java.util.*;

public class a {
	/*
	 * メイン処理
	 * @param	args	外部から渡される引数
	 */
	public static void main(String[] args) {
		HashMap map =	new HashMap();
		arg hikisu	=	new arg();
		hikisu.msg	=	"aのメッセージ";
		map.put("arg",hikisu);
		b.errmsg(map);
	}
}

呼ばれて、エラーメッセージを出すbは、こんなかんじ

import java.util.*;

public class b {
	/**
	 * エラーメッセージ出力
	 * @param	map		引数が入ったハッシュマップ
	 */
	public static	void errmsg(HashMap map)
	{
		arg	hikisu	=	null;
		try
		{
			hikisu	=	(arg)map.get("arg");
			if ( hikisu == null )
			{
				System.out.println("引数がない");
				throw new RuntimeException();
			}
		}
		catch(Exception e)
		{
			System.out.println("引数が古い");
			throw new RuntimeException();
		}
		
		//	出力		
		System.out.println(hikisu.msg);
	}
}

もう一方の呼ばれる側d（呼び出し側）は、こんなかんじ

import java.util.*;

public class d {
	/*
	 * コンストラクタ
	 */
	public	d()
	{
		HashMap map =	new HashMap();
		arg hikisu	=	new arg();
		hikisu.msg	=	"作成";
		map.put("arg",hikisu);
		b.errmsg(map);
	}
}

---

■「引数は共通」だけど、実行時に落ちる方法（仕様変更の結果）
ここで、レベルを入れるということに変更します。
ただし、aとbだけに連絡が行っているとします。

　今度新しい引数をarg1とすると、その内容は、以下のとおり

public class arg1 {
	public	String	msg 	= 	null;
	public	int	level	=	0; 
}

このとき、aは、以下のとおり

import java.util.*;

public class a {
	/*
	 * メイン処理
	 * @param	args	外部から渡される引数
	 */
	public static void main(String[] args) {
		HashMap map =	new HashMap();
		arg1 hikisu	=	new arg1();
		hikisu.msg	=	"aのメッセージ";
		hikisu.level = 	10;
		map.put("arg",hikisu);
		b.errmsg(map);
	}
}

（赤字は仕様変更で修正したところ）

そして、ｂは、以下のとおり

import java.util.*;

public class b {

	/**
	 * エラーレベル
	 */
	public static	int	errlevel	=	0;	

	/**
	 * エラーメッセージ出力
	 * @param	map		引数が入ったハッシュマップ
	 */
	public static	void errmsg(HashMap map)
	{
		arg1	hikisu	=	null;
		try
		{
			hikisu	=	(arg1)map.get("arg");
			if ( hikisu == null )
			{
				System.out.println("引数がない");
				throw new RuntimeException();
			}
		}
		catch(Exception e)
		{
			System.out.println("引数が古い");
			throw new RuntimeException();
		}
		
		//	出力
		if ( hikisu.level ＞= errlevel)
		{		
			System.out.println(hikisu.msg);
		}
	}
}

（赤字は仕様変更で修正したところ。＞　は、実際には半角）
　つまり、引数を受け取るときにキャストし、古い型だったら、ランタイム例外で落とします。

で、dは修正していませんが、問題なくリンクできます。
そして、dがどこからか呼ばれて、表示しようとすると、
”引数が古い”とでて、ランタイムエラーになるのでわかります。

---

　これは、引数をキャストするとき、型が違うため、エラーになるということを利用しています。
　おなじような現象として、Strutsなどで、実際に引数を利用するときは、引数をキャストして使うので、ここで、古い型のものでかいてあれば、エラーになります。

　ということで、
・今回の例のように、なにかを包んで、中身から出すときにキャストして、
　古かったらエラーにするもの（ある意味委譲のやり方に似ている）や、


・Strutsのような、継承の型で、親の型を引数とし、実際に利用するときキャストして
　古かったらエラーにするものがあるのですが、

この継承でやる方法と、委譲でやる方法、意味があって、使い分けます。
それについては、次回のこのシリーズに書きます。

Javaの画面表示－その２１：ＪＳＰで表示部分、サーブレットで処理部分（その１：仕様と方法）

シリーズJavaの画面表示のつづきです。今、ＪＳＰをやっているのですが、この前、前のほうの机の人が「処理はサーブレットでやるのが普通だよねえ」といってたので（って、ぜんぜん別件なんですけど）、サーブレットで処理して、ＪＳＰで表示するって言うことを、示してみたいと思います。

　ただ、この前と、仕様をちょっと変えます。

---

■仕様

以下の画面

が表示されたら、ＪＳＰの表示のときのように、入力内容に応じ、エラー画面（何も入力されなかったとき）か、結果画面を出します。

　つまり、問題文が、日本語でなく、英語(This is a pen.)に変わっただけです。

　日本語だと、いろんな説明が要るので。。

---

■構成

　以下の構成になります
・入力／エラー画面・・・JSP (index.jsp)
・処理部分・・・サーブレット(shori.class)
・結果表示・・・JSP(kekka.java)

そして、サーブレットを利用するため、以下のファイルが必要になります
・web.xml
また、以前ＪＳＰのとき（ここの■手順）に書いたように、以下のファイルは修正が必要です
・（confの下の）server.xml

---

■方法

　はじめの入力画面で、サーブレットを呼び出します。

　サーブレットでは、
　　　・セッションをtrueに
　　　・値を受け取る
　　　　（セッションの値：今回はない）
　　　　フォームの値（画面から直接入力の場合）
　　　・やりたい処理をする
　　　・結果を、セッションに詰めて
　　　・画面表示へフォワードする
　という処理をします。つまり、shori.jspでやっていたのと、ほとんど同じようなことです。

　そしたら、結果画面で表示します。
　表示画面では、ＪＳＰのときにやったように
　　　０．（前提、準備）セッションをtrueに
　　　１．セッションから表示する値を取得する
　　　２．＜%=変数%＞という形で値をかいたり、
　　　３．値を書くために繰り返しの処理をする
　ということをします。

---

　　
　入力画面は、（今回は、入力文字を変えたので、そこをThis is a pen.に変えましたけど）
　基本的にＪＳＰと違うところは、呼び出し先のＵＲＬをＪＳＰからサーブレットのものに
　かえるだけです。

　結果表示画面は、かえる必要がありません。

　サーブレットを利用するに当たって、ＪＳＰを利用する時点でserver.xmlを編集（追加）していれば、それをいじる必要はなく、

　サーブレットを作成してできたclassファイルをおくフォルダを作って、web.xmlを作成する作業が追加となります。

---

ということで、このシリーズの
　　次回では、サーブレットのソースファイルについて、
　　さらにその次には、クラスファイルを置くところとweb.xmlファイル
について書きたいと思います。

「近未来通信」、とうとう総務省が立ち入り検査

ここのニュース
「近未来通信」の実態解明へ、総務省が立ち入り検査
http://headlines.yahoo.co.jp/hl?a=20061127-00000105-yom-soci
によると、近未来通信、とうとう総務省が立ち入り検査した模様。

そりゃーそーだよね、昨日の報道特集で、サーバーの中身の写真っていうのがでたんだけど、
あれ、（＠＿＠！）これで、いいんでしょうか？？
（まんなかが、異様にあいてるのよ。ここに、マザーボードが入るんじゃないの？
　っておもうくらい空っぽ）
っていう感じでしたもんね。。

おー、どうなるんでしょう。。。