AJAXによるDTPのレイアウトソフトの可能性っていうか、AJAXとOLEの関係というか

　前の話、ページレイアウトはAJAXでできるじゃん、そーするとっていう話もっていう件について。

　ページレイアウトっていうのは、さっきのWeb形式の場合、結局やることは決まっていて、

１．小組（あるいは小組のかたまり）を、指定されたところに置く
２．そして、その内容（っていってもイメージだけど）を表示する。
３．自動編集の場合は、その小組のデータを集めて、書き出しファイル形式にする
４．DTP形式のときは、指定されたら、その小組のWebアプリを呼び出す。

てなかんじ。

そーすると、
１．は、四角形をかけるドローイングソフトがあれば、その四角形をレイアウトの枠としてしまい、
２．は、小組のDTPサイトを呼び出し、イメージを要求し
３．は、自動編集サイトを呼び出し、出力結果を要求し
４．は、小組のDTPサイトを呼び出せばいい

ってことになる。そうすれば、汎用的なレイアウターができる。

　で、これって、２．３．４は結局、HTTPで、小組Webサイトを呼び出せばOKってなると、結局１．がAJAXでかければ、２．３．４の呼び出しはAJAXでできるわけで、そしたら、２で受け取ったイメージはテキトーに出力すれば言いし、３は、データを受け取ったら、あとはそれをもとに処理すればいいし、４は、呼び出したら別ウィンドウなり、そのウィンドウで表示すればいいわけだ。

　つーことで、AJAXでできそうだ。

---

　で、ここまで書くと気がつかれると思うけど、

・結局、普段はイメージを要求し、
・印刷時に、それなりのものを要求し
・呼ばれたら、アプリを起動するって、

　Microsoftの世界で言うとOLEとおんなじ話なわけでえ。。そうすると、あれ、AJAXとOLEっていうか、COMっていうかDCOMっていうかActiveXって、機能的には似ていて、インターフェースとかが違うくらいってこと？じゃあ、これ、AJAXでなく、ACTIVE　Xで実現してもとかいいだすと、はなしややこしくなるんで、こっちのほうには発展させない。

　とにかく、OLEの世界なら、こういう感じで動いていた、WindowsのDTPソフトっていうのはあったわけで（PageMakerは、たしか、OLEに対応してなかったっけ？）そんならAJAXでもできそうだ、とか妄想しちゃたりするわけだ。

---

　でAJAXにもどすと、AJAXのドローイングソフトをぱちって、あと呼び出しを自由に設定できるようにすればOKってことか？

　とも思う。

　でも、AJAXのぱちりといえば、ライブドアだが、ライブドアは今はないので（いやあるあるーーちゃんと存在するし、まだ上場しているう！！）、まあ、ぱちりはいけないよねということで、どんなかんじのレイアウターにしたら、汎用的なのかは、別の機会に書く。

　まあ、実は上でAJAXからActiveXまで話がとんじゃったように、AJAXでなくてもぜーんぜん問題はないので、具体的に話すときは、AJAXとは関係なく話すと思う。ただ、そのレイアウターの具体論に入る前に、全体的なアーキテクチャーを説明したほうがいいと思うので、たぶん、そっちの話が先だな。

　でも、最近ケータイの話もかいてないので、そっちのほうが、先かもしんない。

Ｗｅｂで自動編集！とＳＯＡ的なＷｅｂのＤＴＰアプリの可能性の概要

昨日書いた ＨＴＴＰのＰＯＳＴ等による、Ｗｅｂで自動編集！とＤＴＰの可能性 途中でとめちゃったけど、なんか、ＤＴＰ関連の人が、見ているみたいなので、続き、かきますね。

　今日は概要で、細かい話は、まだ入りません。

---

　まず、昨日の話しから、こんな感じになりますよね。

本

　｜

ページ

　｜

小　　　　　　　　組

　｜　　　｜　　｜

文字

線画

写真

　イメージなどは、別に小組に入ってないってこともあるけど、かならず小組にいれることにします（そのイメージ１つだけ入った小組）。
　で、文字の入った小組は、連結させることもできます（Ｗｏｒｄでも、この機能あったと思うので、説明は省略）
　小組は重ね合わせることもできます（そのとき、上の層のものだけ表示するか、上のものを透過させるか、回りこみにするかなど、いろいろある）

　そこで、これらのクラスそれぞれにメソッドとして、
　　・自動編集
　　・手動編集
　っていうのを考えます。

---

●文字、線画、写真はどうするか
　文字や、線画、写真をどこか、Ｗｅｂ上の見えるところにおきます。
　httpでアクセスできるようにするということです。

●小組はどうするか－小組サイトをつくる
　小組のＷｅｂサイトは、それらの文字や、線画、写真を、ここに書いてあるように、アクセスすると、その内容を取得できるので、それと、小組のきまり（ファイルやＤＢにある）にもとづいて並べ、結果を

（自動編集の場合）
　ＸＭＬなり、タグつきテキストで、出力します。

（ＤＴＰの場合）
　あるいは、表示し、編集できるようにします

●ページレイアウトは－ページレイアウトサイトを作る

　ページレイアウトのＷｅｂサイトは、

　自動編集の場合、ページレイアウトで指定された小組の自動編集サイトを呼び出します（小組のサイトを、引数として、レイアウトの情報を与えて呼び出す感じになると思う）。もちろん、さっきのＨＴＴＰの方法で。
　そーすると、小組のＸＭＬなり、ファイルなりが受け取れるので、それとレイアウト情報を元に、ＤＴＰソフトに読み込ませられるカタチに変換して、それを出力します。あとば、ブラウザからセーブしてもらうなり、もともと、このプログラム自体がＣＧＩで呼び出されていれば、返り値をファイルに保存するなりすると。。

　で、ＤＴＰの場合は、レイアウトを表示しておき、くりっっくされたところの小組のアプリのＤＴＰ版のサイトを呼び出す。そーすると、小組のＤＴＰサイトは、文字、線画、写真を集めて表示することになる。

---

こうすると、なにがいいのかについてなんだけど。。
ぎゃー、お昼終わっちゃう（＞＿＜！）
昨日、夜ごはん、ゆっくりたべてたら、
まだ食べてるー、と顰蹙買ったので、ここから後の話は、また別の機会に

具体的内容も、

ページレイアウトはAJAXでできるじゃん、そーするとっていう話も

別の機会にね（＾＾）(覚えていたら）

マイクロソフトがiPodに対抗して開発中のTablet PC「Origami」見たあ？？

　マイクロソフトが、iPodに対抗して、おりがみ（「Origami」）つーのを、開発してるらしいですね。

ここのニュース
［WSJ］ MS、iPod対抗プロジェクト「Origami」発表へ
http://www.itmedia.co.jp/news/articles/0602/27/news053.html

で、問題は、その折り紙って、どんなの？っていうことだけど、上のニュースでは（以下斜体は、上記ニュースより引用）、


　Origamiプロジェクトで開発中のデバイスは、音楽プレーヤーではなく、もっと広範なデバイスになるとこの件に詳しい筋は話している。このデバイスは、ペン入力方式のMicrosoftのTablet PCに倣ったスタイルになる。


としか書いてない。

だけど、下のブログには、そのプロトタイプの画像がある。

「オリガミ・プロジェクト」の正体？
http://japanese.engadget.com/2006/02/25/ms-origami/

うーんと、これだと、iPod対抗というより、ニンテンドーDS対抗じゃあ（＾＾；）

ＨＴＴＰのＰＯＳＴ等による、Ｗｅｂで自動編集！とＤＴＰの可能性

　昔書いたブログのおわりで、ＤＴＰや自動編集をＷｅｂシステムでやるとした場合の話として

実際の雑誌は、

・レイアウトサービスが、
　　　小組サービス、イメージサービス、線画サービスを呼び出し、

・さらに小組サービスがデータを呼び出し

という感じにしないといけない


って書いて、そのあと、じゃあ、具体的には、どーなのさ？っていう話は、この前の「 PHPプログラムの中から、他サイトが呼び出せるということは、SOAの段階的導入にいいかも？」の続きの話として書くけど。。って書いておきながら、この件について書いてなかったので、その続きの話って言うやつを、書いておきます。

---

■■　前提条件

　情報誌やカタログ、一部のチラシ（フライヤーじゃなくって、おくさまがみる、ほんまもんのチラシ）、パンフレットなどは、現在、自動的にデータベースから編集できるようになっている。一昔前は、これをデータベース編集といった。

　どうして、こういうことが、可能なのかということを説明する前に、これら、雑誌やカタログは、どういう仕組みになっているか説明しよう。

---

■■　情報誌、カタログのしくみ

　一般に編集の際の素材は、以下のようにわかれる。

・写真（イメージデータ）
・線画（ドローイングデータ）
・文字（テキスト）

　そして、これらを、どう配置するかという、レイアウトデータがある。

　レイアウトデータは、階層になっていて、
・１冊の雑誌や本に、どういう記事を何ページに入れるかという、台割（だいわり）構造、
・１ページの中に、どういう小組を何個、どこに置くかという、ページレイアウト
・どのような小組にするかという小組の構造

である。

　ここで、小組というのは、「こぐみ」とよむ。

　リクルートのFromAなどを見てもらうと分かるが、同じような構造が何個も並んでいるのに気づくだろう。雑誌のテレビ欄、競馬新聞とかも、同じ構造が並んでいる形だ。
　こういう、レイアウト上１まとまりの意味ある構造を小組という。（競馬新聞の１馬分はとくに、馬柱（うまばしら）という）

　そして、この小組の構造というのは、たいてい、雑誌によって、形式・構造が決まっている。
　うそだと思ったら、FromA,Hotpapperなどなど、リクルートの情報誌をチェックしてみるといい。

　FromAなら、１求人広告分の構造、Hotpapperなら、１広告文の構造は、だいたい、なにをかくか、どこに書くかの規則性がある。これは、電子化するためでは「なく」そうしないと、みにくいからだ。うそだと思ったら、テキトーに並べたものを作ってみてみるとわかる。

　目をどううごかしていいか？？？となる。

---

■■　自動編集ができるわけ。

最終的には、

・ＤＴＰが読み込める形式にすれば、ＤＴＰから、印刷用のＰＳファイルを書き出せる
・ＰＤＦを直接作り、ＰＤＦ入稿という手もあるが、それは、現在ではきつい
　→とかくと、ＪＡＧＡＴに怒られるだろうが、きつい。
・ＰＳを直接書いちゃうのは、もっとやばい

　つーわけで、ＤＴＰソフトからまず出力するので、このＤＴＰソフトで読み込める形式にすれば、自動編集できることになるんだけど、それには

・小組の規則により、ＤＢからテキスト、写真、線画をとりだし
・ページレイアウトにより、小組を置いて、
・それをＤＴＰソフトに読み込ませる形式に変換できれば、

ＤＴＰソフトで、ちょっち微調整をして、出力できるので、自動編集できることになる。


そこで、
・小組の規則を編集してもらい、ファイル化し
・ページレイアウトも編集してもらい、ファイル化し
・ＤＴＰソフトに読み込ませる形式は、決まっているので（ＸＭＬも対応しているものもある）
すれば、自動編集は可能になる。

---

　じゃあ、Ｗｅｂベースで、どうやってやるの？っていう話を書こうと思ったら、５時を過ぎてしまったので、この辺でお仕事しないといけないので、今日はここまで。

　またこんど、気が向いたときね（＾＾）ｖ

ケータイの高速化で、テレビ会議も可能になるかもしれないけど、先にKDDIが動画メールと予想？？

　以前のブログで、ケータイの高速化(通信が早くなる）について書いたけど、今度は、会社における利用について。

　ケータイの高速化によって、やっぱ、実現できる大きなものとして、ケータイによるテレビ会議のようなもんだと思う。
　つまり、画像つきのPush Talk。
　Push Talkは、実は、これを狙ってる布石じゃないかと、ウィリアムのいたずらは、うがった見方をしている。


　ケータイによってできるテレビ会議となれば、実は利用価値はもっとあって、お茶の間留学のNOVAみたいなのも、ケータイでできるし、っていうことで、通信教育なんかの分野でも、導入されそうな気もするし、介護の分野というか、独居老人とのコミュニケーション分野での広がりも考えられる（ただ、老人にケータイって言う部分は考えなくっちゃいけない課題もあって、それはまた別の機会に）

---

　ただ、ケータイのテレビ電話には、大きな問題がもうひとつある。
　ストリームで流れる画像を、どのように高速に展開するかという問題。

　で、この問題が解決する間の幕間つなぎとして、動画メールなんかが面白いんじゃないかと思う。

　ケータイは使っているけど、打つのが面倒という、経営者の方とか、年配の方とか、年配じゃないけどウィリアムのいたずらとか、そーいう人は多いと思う。
　なんで、そーいう人のために、動画メールというサービスが出てきてもいいんじゃないかと。

　ムービー撮影で、音声も録画するようにして、それを添付してメールでおくる。

　これなら、キーを打たなくていいので、簡単にできそうだ。。

　基本的に、これ、パケットと通信速度、気にしなければ、今でも無茶すればできそうなので、KDDIが高速化したときに、ナンバーポータビリティされないよーに、こーいうサービスを、仲間ゆきええさんがたりが、気合を入れて宣伝しそう。。とおもっているんだけど、どーだろー(無責任な空想）。

　ほら、WINならダブル定額にすればいいわけだし。。
　で、ナンバーポータビリティにからめていえば、動画「メール」の場合、ポータビリティはない（Eメールアドレスはキャリアがかわると変わる）ので、いい宣伝になりそう！！

---

　でも、ケータイじゃなく、会社から、ケータイに動画メールをする場合も、ケータイをつかってやるのは、ちとめんどう。
　なので、そーいう端末ができるかも！

・相手を選んでボタンをおして（あらかじめ、相手の名前とアドレスは登録されてる）
・マイクスタンドのスイッチを押すと、カメラと音声が同時に収録開始
・スイッチを切ると、録画終了で、メール送信

っていうような機械ができて。。

そーすると、石原裕次郎みたいな上司が、部下に「やまさん、聞こえるか！」とかいうんですよ！！

って、「太陽にほえろ」を見てない世代の人には、さっぱり意味の通じないオチでした（＾＾）

BREWで複数画面を効率的に開発するフレームワーク（その５：複数分の画面作成）

　だれも見てないかもしんない、BREWの複数画面における効率的開発。その５回目
　複数分の画面作成です。

例題の内容については、ここ。

＜＜手順は＞＞

（１）アプリのソース作成
（２）１つ分の画面作成（前編・後編）　　　　
（３）複数画面の作成
（４）コントロールをいれる
（５）画面間項目

今日は、「（３）複数画面の作成」についてです。

---

■（３）複数画面の作成

＜＜１つめの画面ソースを画面分こぴぺ＞＞

１．gamen001.c,gamen001.hをコピーして、gamen002.c,gamen002.h,gamen003.c,gamen003.hを作ります。


＜＜各画面用に修正＞＞

２．gamen002.c,gamen002.hの001を002に変換します。

３．initのところに書いてある、画面番号１を２にします。

４．２、３と、同様のことを、(001を003に）gamen003.c,gamen003.hで行います

＜＜画面表示とイベント処理を記述＞＞

５．第一画面と表示しているところを、
　　gamen002.cでは、第二画面
　　gamen003.cでは、第三画面
　　に書き換えます

６．クリアキーで終了していたところを、
　　gamen002.c,gamen003.cとも、以下のように書き換え、gamen001.cに戻るようにします。

＜＜アプリのファイルを修正＞＞

７．mvctest.cで、gamen002,gamen003のHandleEventを呼び出すようにします。

static boolean mvcsample_HandleEvent(mvcsample* pMe, 
                            AEEEvent eCode, uint16 wParam, uint32 dwParam)
{  
	switch(pMe-＞gNo)
	{
	case	0:	//	一番初め＝初めの画面のinit処理
		return gamen001_InitAppData(pMe);

	case	1:	//	１番目の画面
		return	gamen001_HandleEvent(pMe,eCode,wParam,dwParam);

	case	2:	//	2番目の画面
		return	gamen002_HandleEvent(pMe,eCode,wParam,dwParam);

	case	3:	//	3番目の画面
		return	gamen003_HandleEvent(pMe,eCode,wParam,dwParam);

	case	-1:	//	終了
		return	FALSE;
	}

	return	FALSE;
}

（上記の＜＞　￥は実際には半角です。赤字が追加箇所です）


８．gamen001.cでは、１のキーが押されたら、第二画面、２のキーが押されたら、第三画面を表示するようにするため、gamen001のHandleEventのEVT_KEYを、以下のように書き足します。

        case EVT_KEY:
		    // Add your code here...
			//	ここを追加
			switch(wParam)
			{
			case AVK_1:	
				gamen001_FreeAppData(pMe);
				gamen002_InitAppData(pMe);
				return (TRUE);	

			case AVK_2:	
				gamen001_FreeAppData(pMe);
				gamen003_InitAppData(pMe);
				return (TRUE);	

			case AVK_CLR:	//	クリアキーが押されたら
				gamen001_FreeAppData(pMe);
				ISHELL_CloseApplet(gamen001-＞pIShell,FALSE);
				return (FALSE);	
			}
			//	ここまで追加
      		return(TRUE);

（上記の＜＞　￥は実際には半角です。赤字が追加箇所です）

９．コンパイルしてください。

---

　今回はここまでです。

　次に、コントロールを入れていき、ちゃんとした画面になるようにします。

　しかし、その前に、画面の切り替え方法などについて説明するのと、複数画面を行うときの修正箇所のポイントなどを、１回説明すると思います（先に、コントロール入れのほうを説明する「かも」しんないけど）

日本版SOX法に向けた「内部統制対応文書作成ガイド」、マイクロソフトが公開してる

　マイクロソフトが、日本版SOX法に向けた業務プロセスの文書化を支援するための、「内部統制対応文書作成ガイド」を作成し、ダウンロード可能なように公開している。

　そのニュースリリースは、
ここ
●Microsoft(R) Office 2003活用ガイド「Visioで書く内部統制対応文書作成ガイド」の提供開始
～日本版SOX法対応に向けて業務プロセスの文書化を支援し、効率的な内部統制の確立を実現～
http://www.microsoft.com/japan/presspass/detail.aspx?newsid=2596

実際のダウンロードサイトについては、
ここ
http://www.microsoft.com/japan/office/visio/prodinfo/guide/sox/default.mspx
の一番下を見てください。

　「手順書ダウンロード」に「内部統制対応文書作成ガイド」があって、そのページからダウンロードできる。

　その下の、Visio 内部統制テンプレートは、公開準備中の予定らしい。

　で、ダウンロードしたファイルを（自己解凍形式のExeファイル）実行すると、ファイルとして、flow_diagram.docというＷｏｒｄファイルとサンプルのＡｃｃｅｓｓＤＢが入っている。

---

　そのflow_diagram.docにやり方が書いてある。
　よくみてないけど、Ａｃｃｅｓｓからの文書化手法になっている。

　ＳＯＸ法適用会社は、

・上場しているような会社
・大きな会社の子会社等、連結対象会社（中小もあり得る）
・将来、上場をめざすような会社

　ということで、ＡｃｃｅｓｓのＤＢとは限らないと思う（というか、そうでないほうが多い？？）。

　なので、その場合、既存ＤＢをＡｃｃｅｓｓにリンクしてやるということになるのかなあ？？？（詳しくは、わからん）

---

　ただ、中小企業でも、文書化したほうがいいわけであって、その場合、この手法を使うということは考えられる。その場合、中小企業は、ＡｃｃｅｓｓのＤＢにまず、帳票などの書類を落とし込んでということになるが、この手法に関しては、Ａｃｃｅｓｓでアジャイルで取り上げた手法（ここ、つづきはここ）が使えると思う。

　ただ、そーいうネタは、平日とりあげるような話なので、平日に、思い出したら、書きます。

「Windowsのパスワードを数分で自動的に発見してしまうツール」だって！

　すげー！！と思ったので、メモ
【2006/02/22】
■ Windowsのパスワードを数分で自動的に発見してしまうツール
http://internet.watch.impress.co.jp/static/yajiuma/index.htm

そこの記事から引用すると（斜体部が引用）

OphcrackはWindowsのAdministratorのパスワードをいとも簡単に解読してしまうソフトウェアだ。公開されているイメージファイルをCD-ROMに焼き付けて、PCのCD-ROMドライブに挿入して起動する。しばらくするとツールが自動的に動き出し、数分後にはパスワードを発見するのだ。


すげー！！数分。。。ですか（＠＿＠！）

　ちなみにそのツールは、ここ
　そのツールにやられないようにする方法について書いてあるのは
　　　ここ（マイクロソフトのここの説明を解説してるみたい）

ケータイの高速化で一番初めに出てくる分野は、やっぱ、この分野でしょうね

　ケータイの高速化のニュース（ここ）で、以下のように書かれている。


ただ、世界最速の高速通信を実現しても、見合うだけの魅力的なコンテンツが登場しなければ、利用価値は少ない。


　これは、今の流れからすると、そう思われるかもしれません。
　でも、ウィリアムのいたずら的には、かならずしも、そうは思わないです。
　特に、双方向で動画像のやり取りを楽しめるようになると、魅力的なコンテンツが出なくても、動画メールという分野、つまり、動画をメールで送れるというだけで、利用価値はあると思います。

　で、どのくらい利用価値があるのかについて、会社で、どんだけ有効化ということについては、平日、会社で、見ている人が多いときに書きます。今日は、土日で会社で見ている人は少ない（見てる人、ごくろーさまです。もっとも、ウィリアムのいたずらも、おうちで仕事だけど）と思うので、会社以外の利用法について。

---

　やっぱり、こういうメディアの発達は、アダルトからということで、アダルト路線から始まると思うんですよ。
　つまり、動画をケータイでとって、送るという話。

ビジネスモデル的には、こんなかんじかな

（１）ケータイで、動画をとる。
　　→どんな動画かは、ご想像におまかせするぞ

（２）ブログかなんかで、紹介して、欲しい人は、メールしてと書く。
　　このブログは、ケータイからでも投稿できるよね。
　　メールの受け先も、ケータイにできる

（３）受け取ったメールに、
　　「どこどこ銀行の、なになに口座に、いくら振り込め」
　　とメールで返信する
　　→これも、ケータイからできる

（４）振り込まれたことを確認したら、さっきとった動画をメールで送る
　　→これもケータイから送れる。

　つまり、このビジネスモデル、いままでやるとすると、パソコンがどっかに絡んできていたんだけど、今回、すべて、ケータイだけでやることが可能になってくる。

　ということは、いままで、この商売をやろうとすると、パソコンを持っている、ある程度の人しかできなかったのが、動画を添付してメールで送ればいいことによって、

・１５歳以下のケータイを持っている女の人でも
・ニートの人でも
・暇をもてあましたおくさまでも
・老後のおばーちゃんでも（？？）、

だれでもできる。それも、匿名でできる。人に会う必要がない。
問題が起こったら、ケータイを捨てちゃえばいい。
資本も、ケータイだけ。

っていうことで、小遣い稼ぎに、中学高校生や、ちょっとお金をほしい奥様やおねーさま、年金プラスアルファのお金をねらったおばーちゃんまで、一挙に動画メールが活性化する可能性はあると思う。

　って、だから、おばーちゃんっていう線はないって（＾＾）
　それに、リピーターを確保するには、ある程度の。。。

　。。。っていうことは、やっぱ、魅力的なコンテンツでないといけないって（＾＾；）

　うん、では今度、会社で利用するときは、ぜーんぜんコンテンツに魅力がなくても、使われるよ！という例を挙げよう。

「エイベックスがドワンゴ筆頭株主に」ケータイ動画配信をにらんでかなあ？（考えすぎ？）

　今日は、ブログで稼ぐのをあきらめた理由について書こうと思ったんだけど、それ以上のニュースなんで、こっちを書きますね！

「エイベックスがドワンゴ筆頭株主に」

　おお、ドワンゴ一発逆転！だね（＾＾）

　たしかに、今の着メロ関係なら、むしろ、エイベックスのような１社と組むのは、いいことではない。ソニーミュージックも、いいアーチストいっぱいいるし。ポニーキャニオンは、荒川静香のＤＶＤ出してるし（って、関係ないか　＾＾）

　ただ、ドコモにおいてはドコモ携帯「最終章」　「第４世代」世界最速というところに書かれているように、高速化の実験に成功したし、ＫＤＤＩは、そこのニュースに書かれているように（以下の斜体は、ドコモ携帯。。。のニュースからの引用）今年中に受信速度が最大毎秒３・１メガビットが出る新しい携帯端末を発売ということで、今年中に、動画でのコンテンツ配信が可能になるとのことだ。

　そうすると、見合うだけの魅力的なコンテンツが登場しなければ、利用価値は少ないということになるのだが、今後の路線としては、着うたフルの次は、やはり、ＰＶ全体を流すということであろう。

＊注：ＰＶ　プロモーションビデオ。新曲などで、宣伝用に作るビデオ、ただし、宣伝用というには、もったいないくらいおもしろい。エイベックスは、とくにこっていて、channel-aの「初出しPV」のコーナーなどで、見れる。

---

　ところが、ＰＶを流すといっても、ケータイコンテンツ用に、ふつうのＰＶの直接流用は無理があるだろう（テレビは横長、ケータイは縦長、そもそも大きさが違う。ケータイを横にしてみるなら、すべての操作画面も横にしないといけない、横幅にあわすと、かなり小さくなる）。

　そう考えると、ＰＶ撮影の現場から、テレビとケータイ、両にらみした、制作ができる会社ということになる。さらに、コンテンツのおもしろさが重要になる。ＰＶで、ただ、歌を歌っているだけなら、べつに、動画にして見る必要はない。

　ここまでの条件をそろえている会社。。。
　となると、やはりエイベックスになってくるだろう。

　エイベックスは、数多くの、結構こった（こりすぎの　＾＾；）ＰＶを出している。
　このＰＶ撮影に対し、ケータイでの配信を、上流（撮影時点）から意識し、ＰＶを、動画配信としてケータイで流せば。。


　すんげーパケットだよ。ダブル定額にしないと無理だよね！！


　ちがうって（＾＾；）一挙に動画コンテンツはふえ、収益の機会は増す。
　今、「着うた」とかではお金を取ってるけど、ＰＶを流してお金を取るというビジネスモデルは考えていない（つーか、ＰＶって、ＣＭでしょ。コマーシャルで、金取るっていうのは、普通考えないよね）。こいつを動画配信できるとすれば、莫大な収益になる。

　そこをねらって、ドワンゴがエイベックスと組んだのなら、ドワンゴは、すごい（エイベックスにとっては、ドワンゴじゃなく、インデックスでもフォーサイドでもどこでもいいし、組まなくてもいいだろうけど）。

。。。考えすぎかな（＾＾）。
そこまで、考えてないかな、ドワンゴは。。

BREWにおけるサンプルプログラムと複数画面の違いをクラス図で説明する

　さて、またまたマイナーチックな話題。
　BREWで複数画面を効率的に開発するフレームワークというのを書いています。あの方法と、BREWのウィザードが作るプログラムとの関係についてを、クラスで説明します。

---

■BREWのウィザードが作るプログラムのクラス

　このとき、画面は１個です。そして、画面の下に、テキストとか、メニューとかのコントロールを置くことになります。
　画面は１個で、それはアプリそのものなので、わざわざ、画面を作りません。
　なので、アプリクラスの子供として、コントロールをもちます。
　つまり、こんなかんじ

アプリ

initAppData Handle_Event FreeAppData

　　　｜

コントロール

いろいろな関数たち ： Handle_Event Release

　そこで、前のCからクラスに落とす法則により、アプリのクラス（pMeになるやつ）の中に、コントロールの実体をずらずらと書きます。

---

■■　複数画面になった場合

　この場合、アプリの下に画面があって、画面の中に、各画面のコントロールがあると考えるのが普通です。つまり、こんなかんじ

アプリ

initAppData Handle_Event FreeAppData

　　　｜

画面

initAppData Handle_Event FreeAppData

　　　｜

コントロール

いろいろな関数たち ： Handle_Event Release

　ということは、、前のCからクラスに落とす法則により、

・アプリのクラス（pMeになるやつ）の中に、画面のクラスをずらずらと書きます
・画面のクラスの中にコントロールの実態をずらずらと書きます。

となるのですが、ここで、画面はいくつできるか、あらかじめわかりません。

　そこで、void *dispDataとして、現在表示している画面の領域をとっておき（１つしか表示することを考えていないので、ここでの説明は１個分ですが、複数同時に表示することがありえるなら、ここは配列になる）、実際に表示したときに、表示しているクラスのオブジェクトを*dispDataにセットします。

　コントロールは、画面の中にずらずら書いています。

---

　そして、この場合、いままで、アプリで処理していたイベントは、現在表示している画面で処理すべきなので、アプリのイベント処理内容(HandleEvent)の内容をコピーし、アプリ側では、現在表示している画面のイベント処理関数を呼び出すだけにします。

　そして、画面では、自分の子である、コントロールのイベント処理関数を呼び出し、そこで処理したらTRUEが帰ってくるので、画面のイベント関数からも（TRUEで)抜けます。
　もし、全部のコントロールのイベント処理関数を呼び出してもまだ、処理し切れなかったら、今度は、画面のイベント処理かどうかを確認します。それが、各画面のHandleEventで書かれている内容です。

---

　結果として、複数画面ある場合は、

・画面の関数をアプリからこぴぺし、

・アプリは(子供である）画面を呼び出すだけにし、
　　　子供の画面の構造体(クラス代わり）を、自分の構造体の中にもち、関連を取る
　　　→ただし、表示している子供（画面）だけもつ

・各画面はコントロールを子供として、自分の構造体の中にもつ

ってなかたちになります。

最近は、個人情報が流出しても、損害賠償と言わなくなった？

itochanさんのコメントを見て思ったこと

最近のＷｉｎｎｙでの情報流出をＹＡＨＯＯニュースで検索すると、

こんなかんじ
http://nsearch.yahoo.co.jp/bin/search?p=Winny&b=1&st=n&pt=1

ででてくるわけで、情報流出はもちろん、個人情報もかなり流出していますよね。

　でも、そのわりには、その流出に対して、損害賠償とか、おわびとして、お金をはらったという話を、最近、聞いてない気がするんですが。。。
　むかしは、ソフトバンクとか、１人あたり、５００円とか払った気がするのですが。。。

　もう、最近は、情報流出なんて、当たり前だから、そんなこと、いわないんですかね。みんな（＾＾）

　って、するとですよ。。。

　そのうち、「個人情報保護にお金をかけてもなあ。。。」
　とかいいだして、経費削られてくるとか、ないですかねえ。。。

　ネットエージェントに、 One Point Wallの売り上げを聞きたくなりそうな、ウィリアムのいたずらなのでしたあ。。

---

P.S　ある意味、いわゆる「堀江メール」だって、もし、あれが本物だったら、そんな会社の極秘情報が、出回ってしまうっていうの、問題ですよね。

　まあ、そんなことを言い出したら、ホリエモンが、女優さんに、パソコンをあげて、その中にメールが入ってて。。っていう話だって、それが本当なら、そっちのほうが、大変な漏洩だけどね。

　なんたって、ライブドアは、ネットワーク会社なわけで、そこの社長さんだった人の企業情報管理の意識が。。とかいう話にならんかなあ（＾＾）


　

BREWで複数画面を効率的に開発するフレームワーク（その４：１つ分の画面作成「後半」）

　だれも見てないかもしんない、BREWの複数画面における効率的開発。その４回目
　１つ分の画面作成の後半です。

例題の内容については、ここ。

＜＜手順は＞＞

（１）アプリのソース作成
（２）１つ分の画面作成（前編・後編）　　　　
（３）複数画面の作成
（４）コントロールをいれる
（５）画面間項目

今日は、「（２）１つ分の画面作成」についての後半です。
なお、前半は、「●７．元のソースファイルmvcsample.c の、mvcsample_InitAppDataに、以下のように付け足します。」で終わったので、今回は、つづきということで、番号を８番からはじめます。

---

■（２）１つ分の画面作成の詳細内容：つづき

＜＜はじめの画面のソースgamen001.cを修正＞＞

●８．はじめの画面のInitAppData（初期画面表示部分）の作成
　gamen001.cにある、gamen001_InitAppData(mvcsample* pMe)を、以下のようにソースを書いてください。

　「第一画面」と表示するだけにします。

/*==============================================================================*/
/*		関数名：gamen001_InitAppData		*/
/*		内容：gamen001の初期化処理			*/
/*==============================================================================*/
boolean gamen001_InitAppData(mvcsample* pMe)
{
	char	buf[50];
	AECHAR	szText[50];
	Gamen001 *gamen001;
	
	//	１．表示領域の獲得
	gamen001 = (Gamen001 *)MALLOC(sizeof(Gamen001));
	if ( gamen001	==	NULL )
	{
		return	FALSE;
	}
	gamen001->comData		=	pMe->comData;
	gamen001->DeviceInfo	=	pMe->DeviceInfo;
	gamen001->pIDisplay		=	pMe->pIDisplay;
	gamen001->pIShell		=	pMe->pIShell;
	pMe->dispData			=	gamen001;

	//	２．画面番号の設定
	pMe->gNo	=	1;

	//	３．コントロール設定

	//	４．画面初期表示
	STRCPY(buf,"第一画面");
	STREXPAND((const byte*)buf, STRLEN(buf), szText, sizeof(szText));
	IDISPLAY_DrawText(pMe->pIDisplay,AEE_FONT_BOLD,szText,
                 -1,0,0,NULL,IDF_ALIGN_CENTER | IDF_ALIGN_MIDDLE);
	IDISPLAY_Update(pMe->pIDisplay);

	return	TRUE;
}

（上記のうち、全角の＜　＞　￥は、本当は半角です）
アプリの場合、InitAppDataに書いても、表示されませんが、画面のInitAppDataはSTARTあとに呼び出されるので、ここで書いて、UpdateしてＯＫです。


●９．はじめの画面のFreeAppData(画面終了時の後処理）の作成
　gamen001.cにある、gamen001__FreeAppData(mvcsample* pMe)を、以下のようにソースを書いてください。

/*==============================================================================*/
/*		関数名：gamen001_FreeAppData		*/
/*		内容：gamen001のフリー処理			*/
/*==============================================================================*/
void    gamen001_FreeAppData(mvcsample* pMe)
{
	Gamen001 *gamen001;
	//１．引数の転送
	if ( pMe			==	NULL )
		return;
	if ( pMe->dispData	==	NULL )
		return;
	gamen001	=	(Gamen001 *)pMe->dispData;

	//２．コントロールのメモリ解放

	//３．dispData部分の解放
	FREEIF(gamen001);
	pMe->dispData	=	NULL;

	//３．画面番号設定
	pMe->gNo		=	-1;
}

（上記のうち、全角の＜　＞　￥は、本当は半角です）



●１０．はじめの画面のHandleEvent(イベント処理）の作成

　クリアキーが押されたら、アプリを終了するように書き換えます。
　gamen001.cにある、gamen001__HandleEventのうち、「case EVT_KEY:」の部分を、以下のように書いてください（ほかの部分は書き換える必要はありません）。

        case EVT_KEY:
		    // Add your code here...
			//	ここを追加
			if( wParam == AVK_CLR ) // クリアキー押された
			{
				gamen001_FreeAppData(pMe);
				ISHELL_CloseApplet(gamen001->pIShell,FALSE);
				return (FALSE);	
			}
			//	ここまで追加
      		return(TRUE);

（上記のうち、全角の＜　＞　￥は、本当は半角です）

終了するときは、
（あ）表示している画面の後処理（ここではgamen001_FreeAppData）を呼び出します
（い）ISHELL_CloseApplet(gamen001->pIShell,FALSE);を呼び出します
　→TRUEにしてしまうと、待ち受け画面まで戻ってしまうので、FALSEにします
（う）return (FALSE);で帰ります。

　なお、初期表示画面で、クリアキーが押された場合は、ISHELL_CloseAppletをしなくても、FALSEで帰れば終了します（他の参考書は、こうしていると思います）
　ただし、それ以外のケースでは、終わらないこともあります。
　かならず終わらすには、ISHELL_CloseAppletします。

●１１．ここまで来たら、もう一度コンパイルし、今度はシミュレーターで実行します。
　「第一画面」と画面が表示され、クリアキーで終了するはずです。

---

　これで、１画面分できました。
　説明すると長いですけど、実作業の場合は、実に短時間で、ぱっぱとやっちゃいます。

　で、次は、２つめ以降の画面の作り方について書きます。
　が、今回は、ここまでです。

ナンバーポータビリティで、auのシェアは８％アップだって！

ここのニュースより

MNP"知っている"は94％
"シェアはauで８ポイント増加"と予想
http://news.livedoor.com/webapp/journal/cid__1731810/detail?rd

ちなみに、ここにかいてあるMNP=ケータイナンバーポータビリティの略。

Winny被害、「海自：「極秘」暗号書類などネット上に流出」対策グッズとかあれば売れるかも？

　おお、ここまで、きましたか。。Winnyの被害（＾＾）

「海自機密データ：「極秘」暗号書類などネット上に流出」
http://www.mainichi-msn.co.jp/today/news/20060223k0000m040148000c.html

だそうです（＠＿＠！）

　うーん、でも、そーいう大事な書類は、「極秘」にするだけじゃなくって、
　暗号化しないのかなあ。。

　あれ、暗号化した書類の暗号について書いた書類なのか、今回流出したのは？
　じゃあ、その暗号化した書類の暗号について書いた書類も暗号化して、
　うん？暗号化した書類の暗号について書いた暗号化した書類の暗号について書いた書類は。。

　あ、そうか、この考えは破綻する（＞＿＜！）

　じゃあ、やっぱ、電子化しちゃだめ。。。

　いやいや、いっぱい、そーいう書類をつくって、本当のは、どれかひとつ！としておけば、まぎらわしくてわからない。。

　うん？もし、海上自衛隊が同じこと考えていたら。。。

　暗号化について書いた書類のように見えるけど、実は本物でないとか。。。

　うーん、そーかんがえると、今回流出したものの、真偽のほどは、わからんな。。。

　ただ、ひとついえることは、これで、また企業のWinny対策が話題になりそうだ（＾＾）

　ここまでくると、Winny対策グッズ？？とかあれば、売れたりして（＾＾）