ブログで「悪口」は危険。さて、何を書けばいいのか？

　ここのニュース
個人ブログで「悪口」 それはもう危険なのだ
http://news.livedoor.com/webapp/journal/cid__2548361/detail

なるほどー。

でも、そもそも、ブログって、なにを書けばいいんでしょうねえ。。
下手なこと書くと炎上しそうだし。。

会社で起こった出来事とか、書いたら機密事項に引っかかりそうだし。。
（ウィリアムのいたずらも匿名だからいろいろソースを書けるけど、これ、実名だったら、ＢＲＥＷのソースなんて、まちがっても書けないよねー。下手なことかいたら、機密事項にひっかかりそう。。。）

　そーすると、やっぱり、ニュースサイト化してしまうんですかねえ。。

　それとか、アフェリエイトサイトとか。。。

　小説とか？
　そーなってくると、ブログって、だれでも書けるものではなくなってくるのかもしれませんね。。。

Javaの画面表示－その１：概要

　とりあえず、Javaシリーズは、今回から画面表示に入る予定です（途中、入出力に戻ったりするかもしれないけど）。

　で、画面の表示方法について。

　Javaで画面に表示するというか、ウィンドウを出す方法としては、大きく、スタンドアロン（サーバーがいらないカタチ）で出す方法と、クライアントサーバーを前提としている方法がある。

●スタンドアロンでＯＫ
　　ＡＷＴ
　　Ｓｗｉｎｇ
　　ＳＷＴ
　などなど・・・

●クライアントサーバーが前提で、サーバー側にプログラム
　　サーブレット
　　Java applet
　　ＪＳＰ
　　Struts
　　ＪＳＦ
　などなど・・・　

　なお、Javascriptは、Javaではないので、ここに入れていない。Javascriptを利用するAJAXも、同様に入れていない。

　で、「クライアントサーバーが前提で、サーバー側にプログラム」がある場合、クライアントで起動したときに、悪さをするといけないので（クライアント側に勝手にファイルを作ったり、勝手にファイルを削除したり）、いろんな制約がある場合があります。

　ファイルが作成できないとか、環境変数は変えられないとか。。

---

　で、今回は、上記の手法について説明するわけですけど、たんに説明するだけでは、
　もうすでにJavaでHello Worldなどで取り上げられているので（また、それで十分分かるので）必要がない。

　今回は、さらに、これをＭＶＣで実装する方法について考えて見ます。

　Strutsなどで、MVCを実現するという話はまあ、普通にありますけど、ＡＷＴみたいなもんで、どーやってＭＶＣに分けるか、前に書いたように、画面だけの修正にするか？というところについて、書いてみたいと思います。

---

　なお、上記にあげた全部を取り上げるかどうかはわかりませんが、「スタンドアロンでＯＫ」と「クライアントサーバーが前提で、サーバー側にプログラム」の最低１つは、取り上げる予定です。

auで動くJava,オープンアプリ (Java)の仕様が、今日公開されたみたい！（１６時ごろ追加）

（むかしのEZアプリJavaとは別に）MIDP2.0仕様のJavaアプリを、au端末で動かすための仕様みたい

ここ
オープンアプリ (Java)
http://www.au.kddi.com/ezfactory/tec/spec/openappli.html

Ezファクトリーのトピックスのページをみたら、２００６／１０／１０に
公開になっているので、今日、公開したばっかりだね！

　どーなんだろう、この仕様だと、たしかに、カメラ操作とかはできない
のかもしれないけど（いや、よくわかんない）、ちょっとしたゲームや、
ちょとしたビジネスアプリは組めるのかなあ
（ただ、メガiアプリにはかなわんが）

　ファイルは、「32キロバイトまでのレコードストア容量に対応」してるみたい。

　ＢＲＥＷ以外にも、ちょっとしたゲームくらいなら、オープンアプリ (Java)っていう選択肢も出てきそうだよね！

　そーなれは、Javaのプログラマさんはいっぱいいるし、たしかにウィリアムの
いたずらのような個人は、こっちのほうがいいかなあ。。docomoと同時リリースなんていうことを考える会社にとっても、いい？？


　うーん、やばい、こーなると。。。

　ケータイ買うの、docomoに動いていたのだが、
　一気にauも、検討対象に入ってきた。。。
　ＭＮＰ，一気に面白くなってきたかも！！

１６時ごろ追加＆訂正：
ここのニュース
au、来春にJavaアプリが楽しめる「オープンアプリ」導入へ
http://k-tai.impress.co.jp/cda/article/news_toppage/31388.html

によると、来春からだそうです。。。
じゃあ、今Docomoにして、来春ＭＮＰしてauとか（＾＾）

Ｐ．Ｓ　逆にＢＲＥＷって、今すんげー見つけにくいページに追いやられてしまった
気がするんですけど。。。

BREWで画面間メモリ一括管理（その１－概要とサンプルソース）

シリーズ「BREWで複数画面を（分割して開発可能な）開発する場合の方法論」（ただし、追加書きで 先ほどのBREWで分散環境のまとめの話の追加、があります）のつづき、かつ
　ＢＲＥＷにおける、カオル姫方式の話の実体です。

---

■概要

　いままで、画面間にまたがる変数は、そのたびに、アプリ共通領域に足していました。
　しかし、この方法では、変数が増えるたびに、アプリ共通領域に修正が入ってしまい、安定しません。そこで、アプリ共通領域に１つのハッシュマップもどきを作成し、そのハッシュマップに、変数をputしたり、getしたりすることで、画面間にまたがる変数を設定・獲得するようにします。

　そうすれば、アプリ共通領域には、このハッシュマップのポインタをもっておいて、
　　アプリ起動時(アプリ_initAppData)にこのハッシュマップを生成し、
　　アプリ終了時(アプリ_freeAppData)にこのハッシュマップと要素全部を解放
　すればいいことになります。

　この方式を、カオル姫方式となずけます。
　なぜかというと、昔ＪＴの宣伝で、１つのボール（これがハッシュマップ）をいろんな人々（これが画面とか、関数とか）が打っていって（値を出し入れして）、最後にアタックする（表示する）というものがあったのですが、それと、処理イメージが同じ（カッコの中が、処理イメージ）だからです。
　で、このＣＭのはじめにレシーブしたのが、カオル姫なので、カオル姫方式

　となずけたのがはじめなのですが、カオル姫方式2ndでは、もう一つの理由が出てきます。

　なお、ＢＲＥＷ版カオル姫方式には、２つあります

　　１つは、上記のとおり、画面間にまたがるデータを文字列にして受け渡すもの
　　　→文字列だけが対象です
　　もうひとつは、画面の情報全体を受け渡し、自分が定義した構造体でも、
　　　メモリ取得、一括解放などができるようにしたものです。

　後者をとくに、カオル姫方式2ndとよびます。
　今回は前者のほうの対応をします（ただし、ソース中には、後者の内容も若干入ってしまっています）
　ちなみに、ＢＲＥＷ版としたのは、ＰＨＰ版というのが既にあって、このあとＪａｖａ版もでてきます。

---

■仕様
「BREWで複数画面を（分割して開発可能な）開発する場合の方法論」その９で示したものと、まったく同じ、外部仕様とします。

　つまり、外見は同じで、中身だけ、カオル姫方式を使って、共通領域のところを変えます。

---

■ソース

　今回は、先にソースを示してしまいます。
　以下のリンク先に、ソースがあります。
　　　version.h
　　　fukusu1.c　★
　　　fukusu1.h　★
　　　gamen1.c　★
　　　gamen1.h　★
　　　gamen1.htm
　　　gamen2.c　★
　　　gamen2.h　★
　　　gamen2.htm
　　　gamen10.c　★
　　　gamen10.h　★
　　　IHtmlCtl.c
　　　IHtmlCtl.h
　　　IKHMap.c　●
　　　IKHMap.h　●

なお、fukusu1.mif,fukusu1.bidは、ＭＩＦエディタで作成したものを使います。
ソース名の後ろに、●があるのが、追加、★があるのが、修正したものです
（逆にいうと、無印だと、変更無しという意味です）

---

■今回追加されたソースの概要説明

　今回追加されたIKHMapは、カオル姫方式のハッシュマップもどき（連想配列を実現したもの）になります。なお、IKHMapっていう名前は、本当は、

　　　　IKaoruHimeMap

にしようとおもったのですが、余りに名前が長いので、IKHMapにしました。

それぞれのファイルは、以下のとおりです。

●IKHMap.h
　これが、そのカオル姫方式のハッシュマップもどき（連想配列を実現したもの）の構造体です。
　今回重要なのは、 IKHMapの
　　　　int　　itemsu;
　　　　char　　**key;
　　　　int　　*kind;
　　　　void　　**val;
　です。
　　keyは、キーの文字列配列、
　　valは値（現在は文字列なのでchar *だが、将来的なことを考え、
　　　　char*以外でもOKなようにvoid*にしている）の配列、
　　kindは、値の型がなんであるかをいれておく配列
　　　（今回はすべて、IKHMAP_KIND_STR）
　　itemsuは、配列の要素数
　です。

　上の定数宣言は、kindに入るもの（つまり、値の型）の宣言です。


●IKHMap.c
　ここに、カオル姫方式で使う関数が記述されています。
　今回重要なのは、以下の関数です。

IKHMAP_Create
　この構造体を生成し、初期化します

IKHMAP_Release
　この構造体の領域を開放します。要素も全て解放します
　要素は、キーを解放し、値を、kindに入っている値の型に応じて解放します
　（ただし、今回は文字列のみなのでFREEIFするだけですけど）

IKHMAP_StrPut
　文字列を、この構造体に追加します。連想配列の形なので、キーと値を設定します

IKHMAP_Get
　文字列を、この構造体から取得します。連想配列のキーを指定すると、
　該当キーの要素があれば、それに対応する値を返します
　　(void *で返すので、キャストしてください）。
　該当キーの要素がなければ、ＮＵＬＬを返します

IKHMAP_Remove
　指定されたキーの要素があれば、そのキーと値の組をメモリ解放し、
　要素から除きます。
　指定されたキーの要素が無ければ-1を返してなにもしません。

---

　では、このシリーズの次回より、内容について説明していきます。
　まずは、アプリ全体から。

ソフトウエアの改造には、もともとの設計が重要だと思う。。。

　日経システムの２００６年８月号に、ソフトウエア改造力という話が載っていたが、ある意味、一番大事な話が抜けていると思う。
　ソフトウエアが改造可能かどうか、短期間に間違いなく改造できるか、出グレードなく改造できるかを改造力と呼ぶのであれば、その改造力を決める、一番のキーポイントは、ソフトウエアのアーキテクチャだと思う。

　かりに、ＭＶＣにわけていない形のソフト、つまり、画面のイベントが起きると呼び出されるメソッドで、すべてを書いてしまう（つまり、ここでＳＱＬを発行して、ここで、他の画面の変更とかも修正をかけてしまい、画面表示までしてしまう）というやりかたを、みんながやってしまうと、ある画面イベント処理で、他の画面処理が入ってしまう。
　逆の見方をすれば、ある画面に対する更新処理が、複数の画面イベント処理関数の中に入っているという状況、このような状況である画面の仕様変更が入ると、だれにどこまで影響を与えるかわからなくなってしまう。

　このような、画面とモデルが分離していない、ＤＢとモデルが分離していないことによる仕様変更の問題は結構あって、ひどい場合は、１画面分の複数のイベント処理メソッドがひとつのクラスになっているため、そのソースが１万行以上あるんだけど、分離できないなんていうことが起こりえる。そうすると、その画面担当者にすべての仕事が来てしまうから悲惨だ。

---

この状況をなくすには、ＭＶＣに分けることは当然なのだが、ＤＢ側も分離する必要がある。。ということは確かなんだけど、ＤＢだけでなく、帳票とか、入出力全部を分ける必要がある。しかし、データは共用しないといけない。そこで、ファザードをつくることになる。

　画面操作を行ったあと飛んでくるイベント処理メソッドでは、受け渡し領域（カオル姫方式の場合は、これがハッシュマップになるけど）に対して、画面内容をセットし、その受け渡し領域を引数として、モデル用のクラスのメソッドを呼び出す。

　このとき、モデルのクラスはＰＯＪＯ（どっかから継承のない、Ｊａｖａのクラス。厳密に言うと、Ｏｂｊｅｃｔクラスから継承されている、Ｊａｖａのクラス）だと、テストとかしやすい。

　そして、モデルでは、引数の受け渡し領域から、データを受け取り、処理を行い、次に表示したい内容をセットする。このとき、複数の画面に値をセットしないといけない場合も、複数画面とわかるように、引数の受け渡し領域に設定する（例えばメイン画面のnameにウィリアム、サブ画面のninzuに５人とセットする場合、
　　　　hashMap.put("main_name","ウィリアム");
　　　　hashMap.put("sub_ninzu","5");
　のように、画面名_項目名で値をセットしておく）

　そして、モデルのメソッドから抜け出たら、受け取った受け渡し領域の内容から、各画面に値を設定し、各画面をリドローする。このとき、
　各画面のオブジェクト.リドローメソッド（受け渡し引数）
ってすると、受け渡し引数から、その画面の値を取り出して、その画面のリドローをするようにする。

---

　そしてモデル内でもＳＱＬを発行するＤＢ入出力メソッドや、ファイル入出力メソッド、帳票出力メソッドと、純粋のモデル処理メソッドは分けて、その間を、上記の受け渡し引数（ハッシュマップ）を渡すようにする。

　こういうようにすると、
・ＭＶＣ、さらにモデルの処理加工部分と入出力が分かれる
・Ｖｉｅｗにおいて、一画面の処理内で、ほかの画面を呼び出すのは、生成と消滅（ないしは隠す）とリドローのメソッドを、受け渡し領域を引数として渡すだけで、実際の処理は、各画面内に閉じる。このとき、引渡し関数はハッシュマップときまっている（仕様変更での引数追加などはハッシュマップの中の話であり、受け渡しはハッシュマップということ以外、変わらない）ので、仕様変更に対して、ロバストになる。

　っていうメリットがある。

---

　で、これをＢＲＥＷ上で実現するためにも、共通領域である、カオル姫、IKHMapが必要になる。これが、前のブログで書いたその前に、もうひとつのメリットを書きますのメリットです。

　まとめると、共通領域を、カオル姫方式（ハッシュマップ相当のものを作成し、それで画面間の受け渡しをしていく）にするメリットは、

（１）画面間の受け渡し変数か変わっても、できるだけ仕様変更がないようにする
　　　値を設定する箇所と利用する箇所だけの仕様変更に限定できるようにする

（２）メモリの解放をいっぺんにやれるようにする。
　　　さらに複数画面あるとき、フォーカスの当たっていない画面も含めて
　　　全部の画面の状況を取れるようにする

（３）表示画面（ビュー）とモデルを分離できるようにする

っていうことだと思います。

　じゃ、ほんとに次から、ＢＲＥＷにおけるカオル姫方式を書きます。