blancoStrutsによるＰＨＰのソース自動生成の可能性と、ケータイ、Webアプリの統合

　さっきの iアプリやBREWの画面自動生成としてのblancoStrutsの可能性の話。ここで、やっていた、カオル姫方式による、ＰＨＰのＭＶＣ展開、つまり、

１．Ｖｉｅｗ用のＰＨＰを用意し、
　　　それは、セッションに入っているデータをひたすら表示し、
　　　ユーザーからのアクションは、コントロール用ＰＨＰに返す

２．コントロール用のＰＨＰは、ユーザーが入れられたデータをセッションに入れ
　　モデル用のＰＨＰを呼び出す

３．モデル用のＰＨＰは、ひたすら処理して、結果を画面表示できるように、
　　セッションに入れる。

　このとき、セッションは、ＭＶＣのデータをつなぐやくわりを果たす。この様子がＪＴのＣＭのいめーじににてて、そのＣＭの一番初めに出てくるのが、カオル姫だったので、勝手にカオル姫方式と呼んでいるわけだが、

　この方式ならば、blancoStrutsで、１．のＶＩＥＷ用ＰＨＰは、自動生成できそうだし、２のコントロール、３については、からのモジュールを用意できそうだ。

ということで、ＰＨＰでも、これで、自動生成できそうだ。

---

　つーことはですね、このblancoStrutsにより、Struts,PHP,iアプリ、BREW、(たぶんVアプリも）すべてのＶｉｅｗｔｏコントローラーを提供でき、あとは、モデル部分だけということになる。その際、Ｗｅｂかケータイかを問わないということだ。。

　と書きたいが、ここに問題がある。それはまたこんど
　（勘のいい人なら気づくよね。こーやって、業務モデルを作ろうとするとすると、なかまはずれが１つある）

”QRコードから「カラーコード」へ”、そのうち画像透かしを応用してケータイにとか？

　こんなニュースがあった。

白黒のQRコードから「カラーコード」へ──韓国発の新規格
http://plusd.itmedia.co.jp/mobile/articles/0603/28/news011.html

で、その記事の見出しは、こんなかんじ（以下、斜体は上記記事から引用）

日本では広く利用されるようになったQRコードだが、見た目は白黒であまり美しくない。韓国で開発された「カラーコード」なら、これを4つの色のパターンで表現できる。


　えーっと、見た目が美しくないから、４色？？

　４色でも、美しくないと思うのは、ウィリアムのいたずらだけ？？
（その記事の下のほうにある、ちゃっちいい、２０年くらい前の、ゲームみたいな配色しているのが、そのカラーコードの例）

　いや、見た目を美しくしたいんだったら、電子透かしを応用したほうがいいんじゃあ。。

　つまり、画像中に、情報を埋め込んで、それを、ケータイで読み込ませて、解析すると。。
　そーなれば、埋め込まれた文字はフリーフォーマットで入るし。。。
　（もちろん、画像劣化から来る制約はあるけど）

　そーすると、問題はケータイのカメラの精度と、画像に情報を埋め込み、それを紙（インク）で表現して精度的に問題ないか（にじみなどで読み取れないとか）の問題になってくるわけだ。この辺、技術が進めば、解決するんじゃないかなあ。。


　。。。つーか、いまのカメラでも、いけたりしてね！



　ただ、どっちかっていうと、ＱＲより、ＦｅｌｉｃａやＩＣタグみたいな話のほうが、今後発展していくと思うなあ

---

　でも、電子透かしを簡単に入れられて、ケータイで読めるとなると、話はぜんぜんべつ。

　ある、絵が流出して、「おお、某芸能人の、一連のプライベート写真が流出！」と思ったら、実は、中に入っている電子透かしが重要で、そこに国家機密が書いてあったあ！とかとか（＾＾）ｖ

　電子透かしって、目くらましには、おもしろいとおもうよ。簡単に入れられて、読めれば。

---

って頭で、この記事読んでいたので、


カラーコードは赤・緑・青・黒の4色で描かれた絵（カラーコード）を、携帯電話のカメラで読み取り、それをアプリケーションで解析する仕組みになっている。ここで解析された色のパターン情報はサーバに送られ、対応した情報が携帯電話に表示される。


ってところ、思わず「サーバーに送られ、対応した情報！？」そーいや、コンテンツＩＤって、どーなったんだ！？と思ってしまった（＾＾）ｖ

Ｐ．Ｓ　そいと、”「おお、某芸能人の、一連のプライベート写真が流出！」と思ったら、実は、中に入っている電子透かしが重要で、そこに国家機密が書いてあったあ！”を敷衍して、防衛庁の自衛官が、アイドル写真に囲まれて、ひとつひとつ、ケータイを当てて、解析している様子を想像し、勝手に不気味に思ってしまった（＾＾；）

なお、この記事は、昨日一度アップしましたが、一部修正して、今日、再掲載しました。　

iアプリやBREWの画面自動生成としてのblancoStrutsの可能性

　日経コンピューター（もう、前号になってしまったと思う）みてたら、blancoStrutsっていうのがでてたけど、これ、同じ仕組みで、iアプリの画面とか、ＢＲＥＷの画面とか、自動生成できそうだよね。

ＢＲＥＷでいうと、２つの方向性がある。
ひょっとすると、３つかもしれんが、とりあえず２つあげる）

---

１つとしては、そのまま、コントロールに置き換えるというもの。

TextBoxをITextCtlに、

DropDownは、しょがない、IMenuCtlで我慢してもらおう
（我慢できなさそうな気もするが）、
もちろん、このための、コントロールを作ってもいい。

Buttonについては、イメージはりつけるかたちのコントロールを付けたほうが楽かな。

　そーいった、コントロールの生成と、位置などを指定したものをInitAppDataに自動生成。
　Redraw,カーソルコントロール用の関数も、自動生成し
　　（ごめん、前にこのブログでかいたけど、どこにあるか、忙しくて今、しらべられん）。
HandleEventの部分は、これらのイベント処理をする部分を自動生成し、必要な変数を
　カオル姫方式で、変数にいれ、
　それを、引数にして、ユーザー指定の関数(StrutsのActionメソッドに相当）に渡すと。。

HandleEventを自動生成するため、サスペンド、レジューム処理は、わかる範囲でやってくれる（もちろん、指定のアクション関数も呼ぶけど）。

---

　もうひとつは、HTMLViewerを使って、Strutsのエンジン同様の部分の関数を作り、そいつががんばって処理し、ユーザーの関数を呼び出すというもの。。

　で、これで、ウィリアムのいたずらは、大失敗。
　今、まいちにいそがしく、土日も徹夜だ（＞＿＜！）

　どーいう失敗をしたかというと。。
　ごめんなさい、カオル姫様。。なのだが、詳しくは、今度かく。

Ｐ．Ｓやっぱ、敗因は、カオル姫のことでなく、栗原さんのＭＶＰのはなしをブログに書いたことっすかね。（かんけいないって　＾＾；）

でも、自動生成してほしいのは、テストデータだったりする。これは、設計段階でも有効

　さっきの自動生成の話。でも、本当にほしい、自動化ツールは、テストデータ生成ツール、確認ツールだったりします。
　テストデータが早く作れ、確認できるということは、開発上も大切。

　ってことは、誰でも賛成してもらえると思うけど、さらにいうと、設計上でも、テストデータが作れて、データの値を基に、具体的にストーリーを追っていければ、確かなシナリオが書ける。
　っていう意味でも、設計段階でも、テストデータが自動化できて、具体的に考えられると有効なんじゃないかと思う、今日この頃なのだ。

プログラムの自動生成が、効果を発揮するところ＆それ以上に大事なこと

　日経コンピューターの記事、読みかけなので、これについてのコメントはあとにすることにして、読み始めのところで思ったんだけど、プログラムの自動生成は、すべてを自動生成させようとしても、効率がよくない。

　もし、それが可能な業務なら、その業務の、パッケージソフトが出ているのがふつう。

　っていうことで、どこが自動化すると効率的なのかという話なんですけど、
　これには、大雑把に思いつくことが２つある

・自動化することにより、決まりきったパターンに落とし込みたい
　　→フレームワーク関係がこれにあたる

・決まった作業なので、間違いを防ぎたい＆生産性をあげたい
　　→入出力関係（画面、ファイル、DBアクセス、帳票）

ORマッピングなんていうのは、後者の入出力関係に結局なってしまう。

で、この枠にはまらない純粋な業務部分は、自動化するより、プログラムで組んだほうが、早い場合も結構ある。
　暴論を言おう。クラス図を描くより、ウィリアムのいたずらにとっては、javaのクラスと、メソッド（中身は空っぽ）を書いてクラス図を作ってくれたほうが、よっぽど早いし、自分の思考過程に近い。

　こういうのの大切なことは、自動生成より、仕様をしっかりきる事だ。

---

　ただ、そんなことより、大事なことは、自動生成の枠にこだわらないことだ。
　自動生成できるようなものは、ライブラリや関数、クラス化できるものも多い。
　決まりきったことやってるから、自動化できるのだから。

　その場合、ライブラリや関数、クラス化したほうがいい場合もある（あとで手が入る場合は自動生成）。

　そういった、どの場合は、自動生成、どのときは、クラス化という判断基準を設けることが、じつは、大切だったりする。。と思っている、今日この頃なのだ（＾＾）

（・・・どこかで聞いた終わり方　＾＾；）

ウィルコムが位置検索サービス開始。たしかにＧＰＳは届かないとこあるし、それ以外の問題も

　ウィルコムが、位置検索サービスをはじめたそうですね。

「ウィルコム位置検索サービス」の提供開始について
http://www.willcom-inc.com/ja/corporate/press/2006/03/28/

GPSではなくて、基地局を使って位置を割り出すらしい。

　で、そのメリットとして（以下斜体部は、そのプレスリリースから引用）

屋外はもとより、GPSでは電波が届きにくいといわれる屋内や地下鉄ホーム・地下街などでも位置の検索が可能です。


たしかに、ＧＰＳでは、電波届きにくいところもあるし、
衛星を使うんで、結構じかんかかるんだよねー！
なんで、基地局利用というのは、ある意味、妥当なのかも。。

もちろん、ＧＰＳでも、１回目は、衛星にききにいき、あと自動計算させる方法もあるけど。。
その辺の手法が、ケータイアプリなんかの場合、選べるかどうかは、単に関数の引数をみるだけでなく、注意事項が書いてあるマニュアルのところまで、ヨーク読んで検討するよーに！

---

全然関係ない冗談なんだけど。。

時刻認証っていうのがあるんなら、場所認証っていうのもあってもいいと思わない？
ＧＰＳなんかを使って、
「何時何分、たしかにあなたは、ここにいました！」
というのを、証明するっていうの。。
営業の人の監視などにつかえそう（＾＾）

携帯電話で、自宅で録画したテレビを見るサービス開始っていうけど、ビデオが見れたほうが。。

「携帯電話の画面で、自宅で録画したテレビ映像や動画を見ることができるサービスを年内に始める」というニュースが

ここ http://news.livedoor.com/webapp/journal/cid__1808834/detail?rd

にでています。

おお、それって、たしかに、録画したテレビが外で見れるというだけでもすごい。

　でもなあ、むしろ、ビデオ画像が、見れたほうが面白くないかい。。

　個人でとったビデオや、会社でとったビデオの宣伝や会議の様子、学校の講義の様子をビデオで取ったものが、ケータイで見れる。
　携帯制大学（通信制なんだけど、授業をケータイでみて、参加できる）なんかもできるかも（なわけないか　＾＾；）

　仕組み的には、ビデオ信号をなんらかの形でインターネットで配信すればいいわけだから、テレビと似たようなもんだと思うけど。。どーなんだろー、
つーか、それも、できるのかな？この、ソニーのやつで。。。

　よーわからん（＾＾；）

自治体や国のシステムは、全国自治体のセキュリティ意識をあわせなければ、危険

　住基ネットって、安全なんですかねえ？？

　ここのニュースの
ウィニー：住基ネット情報流出　北海道斜里町職員ＰＣから
http://www.mainichi-msn.co.jp/today/news/20060329k0000m040154000c.html

の終わりのほうに、こんなことばが(以下斜体部は、そのニュースより引用）


「住基ネットのパスワードが出たことがそれほど重要なこととは思わなかった」


さらにこのニュースによると、


「セキュリティホール（防御の弱い部分）の対策について」という通知文もあった。０４年８月３日付文書で、ＣＳとＣＳ端末で使うブラウザー（閲覧ソフト）のぜい弱性を説明、速やかに対応することを求める記述があり、対策をとらないと攻撃者にパソコン制御を乗っ取られる危険性があるとしていた。


　つーことは、たぶん、こんな自治体は、こーいうセキュリティホールをうめてないだろーから、ここを踏み台にして、入って、そーしたら、同じく流出した

ＣＳ端末の操作担当者が不在の際に使うとみられるマニュアル

つーのを利用して、入れば、そこに

「パスワード入力画面が出たら××と入力する

って書いてあるんだから。。。みれちゃうんじゃあ（＾＾；）ｖ

---

でも、はじめに書いたとおり、その自治体の人は、重要なことという認識はないそうです。

住基ネットが出たとき、絶対安心みたいないいかたをしてたけど、そもそも、自治体によっては、無線LANでDHCP接続つーのもありえるだろーし、そーしたら、あとは、パスワードさえ流出してしまえば、入れちゃうわけで、といっても、パソコン操作を、住民の誰からも見れなくする、すべての自治体で。。ツーのはむりなわけで（操作画面が見れてしまえば、パスワード入力の手先をみて、パスワードはばれてしまう可能性がある）

うーん、すべての自治体のセキュリティ意識と、セキュリティレベルが合わない限り、国のそーいうシステムは、危険なんじゃあ。。

　そして、すべての自治体のセキュリティ意識と、セキュリティレベルが合わせるっていうのは。。
　まず、不可能だよね（＾＾；）

BREWで、複数の会社、人が開発している場合、分業する方法

　今、考えていることのメモ。これでうまくいくかどうかはわからない。

---

■■　おきて

作る人たちは、以下の決まりをまもる

・ふつうに、ウィザードでつくってください。
・bidファイルのところを、以下のように,ifdef,endifを書きたしてください
#ifndef _YOBIDASHIMOTO
#include "test1.bid" // BIDファイル名：自動生成される
#endif
・クラスの構造体(pMe）の最後に、void *savedata;と追加してください。
　このsavedataは呼び出し元が使いますので、触らないでください。
・プログラムから抜けるときは、
　change_gamen(pMe,1);と書いてください。
change_gamenが入ったプログラムは、こちらが提供します。
　このchange_gamenには、ISHELL_CloseAppletがかかれて、おわるようになっています。
・クラスの構造体の部分（まで）をヘッダーファイルとして、.hで作成し
　プログラムのほうでは、そのヘッダーファイルをインクルードしてください。

---

■■　呼び出し側
・HandleEventで、現在表示中のHandleEventを呼び出す
　その際、呼び出しもとのpMeを、呼び出し先のsavedataにセットし、その関数が抜けたら
　また、savedataを呼び出しもとのpMeに設定しなおす
　画面番号から、表示している画面は割り出せる。

・呼び出し側のchange_gamenは、呼び出されるほうとは違い、以下の内容を書く
　　１．現在の画面番号（＝初期値は呼び出し元のInitAppDataで設定。０）
　　　　より、現在表示画面のFreeAppDataを割り出し、フリーする
　　　　０のときは、なにもしない（初期のとき）

　　２．画面番号を、引数にする

　　３．画面番号をもとに、今度表示する画面のHandleEventのSTARTを呼び出す

・ヘッダーについては、
#define _YOBIDASHIMOTO
#include 呼び出し画面１
のように、_YOBIDASHIMOTOを定義した後で、呼び出し画面分、インクルードする

---

こんなかんじで、できそうな気がする。
たしかめてないけど。

ケータイのAJAXで事務用アプリを組む可能性と、そのときのBREWとの比較ってとこ？

　そうそう、前にAJAXで「ファイルでマスタを置いてアクセスすれば」検索側はブラウザでことがたりるっていうの、何が書きたかったのかというと、最近、ケータイでもAJAXを使えるブラウザって言うのが出るみたいだけど、そーいうのが、もし、ケータイのデータフォルダやSDカードのデータが見れたとすると、面白い展開になるなと。。

　つまり、そーすれば、AJAXでケータイのプログラムが組めることになり（マスタファイルは、SDカードやデータフォルダにいれ、そいつを検索する。結果だけ、サーバーに送って登録する）、そーなってくると、アプリとしてつくるより、AJAXで作ったほうが、流用性が高いと。

　そーすると、会社なんかで、開発する場合、アプリものとしてつくるより、AJAXで作ったほうが、技術者確保の上でも、いいんじゃないかって言う選択肢も出てくる。

　さらにそうなると、いままでWebやさんだった、AJAXの人も、ケータイにまで仕事を広げられ。。
　おもしろくなってくるんじゃないかな。。っていうはなしは、A前にもかいたよね。

---

　で、実は、ここからが本題。

　BREWにおいて、ファイル検索結果を、HTMLVIEWERを使って、ある項目に入れる。これはかんたんにできる。つまり、Webの世界でいうJavascriptみたいなことはできる。

　ところがだ。。。

　AJAXのように、固定の、べたうち文字のところをかえるとなると、もう一度、テキストを読み直しっていうことになるよね。で、テキストの内容が変わると、各項目のIDが変わっちゃうことがあるみたい。
　ということで、AJAXのようなことをBREWでやらせようとすると、ちょっと工夫がいる。
（できないことではない。現に目の前で、今そのプログラムが動いているから。ただ、めんどっちい）

---

　となるとだよ。。。
　むしろ、BREWで難しいアプリ組んで、BREWの技術者さんかかえるより、
　ケータイのAJAXで、もしファイルが読めるなら、そっちを使おうっていうことになってしまう。
　なので、NetFrontのAJAXで、ファイルが読めるかということと、それがauの端末に入るかということは、すごーく重要な気がする

ブログの影響度を調べるサイトと、ブログマーケティングでの活用法

bloginfluence
http://www.bloginfluence.net/
というサイトがあります。


ブログの影響度を調べるサイトだそうです。

結果、

ここのサイトが
1800.5

本家は
26.4

参考までに
きっこのブログは
24201.8

うーん、きっこのブログとの差はわかるとしても、本家とここの差が、こんなに大きいのはなぜ？（＾＾；）

---

てな話はさておき、そーすると、
　ブログを使ってマーケティングするとき、
　　　　この影響度の高いサイトであり、
　　　　ブログと、これから宣伝しようとするモノとの関連性が高いサイト
　　　　　　（類義語がどれだけ使われているかとかで評価するのかなあ）
　を組み合わせて、プロモーションをすると効率的っていうことになるのかなあ。。

　なんか、ブログでマーケティングをやるとき、今後、どこのサイトに宣伝してもらうか（あふぇりえいとしてもらうか）などに、参考になりそうな数値ですね！

BREWにおいて、IFILE_Readで、ある一定の大きさ以上のファイルを読むと。。

　ひょっとすると、はずしているかもしれないし、ひょっとすると、あたっているかもしれない。

　BREWにおいて、IFILE_Readで、ある一定の大きさ以上(32K?)のファイルを、読もうとすると、
よめない。。。っていうか、はじめのほうは、正常な値が帰ってくるけど、あるところから、ごみが入ってくる。。。気がするっていうか、そうなった（ただし、必ずそうなるのか、なにか条件があるのかは不明）

　固定長であれば、単純に、IFILE_SEEKして、レコードの先頭に合わせて、一定の長さ分だけ、とってくればいいけど。。。って、可変長でもそうか（＾＾；）

→たとえば、改行で１レコードなら、１００バイトとか、適当なレコード長よんできて、改行がなかったら、前の行に連結、あれば、改行までの文字長を求めて、改行までを連結、それ以降を次行にすればいいだけなんだけど）

ケータイとかの開発こそ、MVCが必要だよね！

　最近思うこと。
　JAVAでは、とくに業務開発のWeb系では、MVCの開発やフレームワークはよく言われると思う。
　だけど、本当に必要なのは、ケータイとかの開発のほうの気がします。

　というのは、ケータイの場合、モデル部分で、問題が起こると、実機でやると、リセットされてしまいます。そーするとですね、リセットしたときに、coreファイルをはく訳でもないので（って、こーいう話、ひょっとして、守秘義務の範囲（＾＾；）よくわかんなーいっていうのは、もちろんあるけど、そんなことよりなにより、実機に持っていくのがたいへんなんですよ、BREWでは（たしか、この方法は、２ちゃんねるで、よく、守秘義務の範囲だ！って書いてあった気がするので、省略）

　シミュレーターを使えば、たしかに、もちょっとよくわかるけど、でも、モデルでおかしいと、それが、モデルのプログラムのせいなのか、ケータイのせいなのか、よくわかんないわけです。

　なんで、モデル部分は枯れていてほしいんです。

---

　なので、

・モデル部分だけを切り出し、VC++でふつーに開発し
　→コントローラーから呼ばれる形にし、コントローラー部分は、ドライバを開発しておく。
　　で、枯らす。

・VIEWは、BREWで開発しておいて、

・HandleEventの適切なイベントで、モデルの関数を呼び出すようにする

ってしておいて、べつべつに開発しておかないと。。。

　あとでたいへん。

---

　ただ、その場合、モデル間と、VIEW、コントローラーの間のデータわたしをどーするか？

　っていうことになる。

　その辺、ケータイでも、セッションっぽいことを実現し、セッションの代わりの中につめてしまうカオル姫方式だと、実現しやすい(ドライバも、セッション代わりを用意すれば言いだけなので）

　なんつーはなしを、今度暇になったら、またかきたい。

さすがに、全裸でケータイしてる人が、そんなに多いとは、想定してないよね

本家ネタに書いたけど

英国人、男性40％と女性27％が裸で電話＝調査
http://news.goo.ne.jp/news/reuters/geino/20060324/JAPAN-207369.html

　だそうな（＠＿＠！）
　つーことはですよ、ケータイアプリを開発するとき、不用意に、リモートからカメラスイッチを押せるようにすると。。。

　KDDIのGPSマップでカスタマイズできるほうのやつを使って、リモートから、社員の状況確認をするため、カメラスイッチを押せるアプリを作って。。。

　カメラを押したら、

　その光景は。。。全裸で電話中？？

　みんな、おおよろび？？（かあ？？）

。。。うーん、いろいろ、想定して作んないといけないよね。。
。。。って、が、想定の範囲内なのかあ？？

“Webサイト安全マーク”って、効率よくアダルトコンテンツが集められるってこと？

こんなニュースが


総務省、“Webサイト安全マーク”の実証実験
Webサイトの安全性を示すマーク「コンテンツアドバイスマーク」の実証実験を、総務省が27日に始める。
http://www.itmedia.co.jp/news/articles/0603/24/news115.html


　で、どうも、（以下斜体は上記記事より引用）

コンテンツアドバイスマークは、サイト制作者の自己申告にもとづいて第三者機関がサイトを審査し、「12歳未満推奨」「暴力表現あり：12歳以上推奨」などと評価し、所定のマークを表示する仕組み。マークをクリックすると別ウインドウが開き、正式なマークかどうかを確認できる。


　この、マーク取得のAPIとか、公開されるのかなあ？

　そーしたら、これ、効率よく、１８歳以上のアダルトサイトとか、見つけられるっていうことだよね。

　18禁のマークがついているのだけ、アクセスすればいい（＾＾）

　サーチエンジンなんかでも、「アダルトサイトをはずす」というのもできるだろうけど、同様に「アダルトサイト”以外”をはずす」なんていうのができたりして（＾＾）

　うーん、これって、意外と、総務省が想定するのとは、違う使い方を、みんなしそうな気がする（＾＾）ｖ