従来のJAVAScriptの書き方より、AJAXの書き方のほうが、MVCや自動生成がしやすいかも。

　あくまでも、独断と偏見の話なんですけど、最近AJAXの本を読んでて思うのは、AJAXになって、JAVAScriptより、ソースをViewと他のところに分離しやすいんじゃないかなって思います。

　AJAXが従来と違うところというと、もちろん、非同期にアクセスできるための

１．HTTPによるデータ取得が可能

ってこともあるけど、それ以外に、

２．動的に表示部分を書き換えることを可能にするため、Pタグやdivタグなどなどに
　　IDをふり、document.getElementByIdで、それらにアクセスでき、値を設定
　　できるようになった。

３．前からできるものの、イベントリスナーによって、イベント関数を記述できるように
　なった。

っていうことが、あげられると思うんです。

---

　で、とくに２の効果により、いままで、Javascriptのときは、文字を書き出すのに、HTML内に、スクリプトをわりこませ、document.writeとしなきゃいけないところも、ID指定して、プログラム内で値を設定できることになったので、まあ、これ以外もそうなんだけど、IDさえ降ってくれれば、わざわざ、HTMLの中に、途中割り込んで、JavaScriptを書く必要が無くなった。

　で、３の効果により、onClick=などなどの形でJavaScriptをかかないですむようになった。
　onClickなんとかの形で書く場合、自動生成させようとすると、そこだけ、自動生成させるってことはむずかしいので、input文全部。。。ってことは、画面自動生成かい？？ってことになってしまったが、イベントリスナーの関数の自動生成なら、画面の項目を書かなくていいので、自動生成時に画面のことを考えなくていい。

---

　っていうことで、画面であるViewの部分と、プログラムの部分である、モデル、コントロールの部分（ここがJavaScriptになる）が、分離しやすくなった。

　で、さらに、コントローラーの部分は、イベントリスナーで、addListnerした関数っていうことになるので、明確になる。あとは、コントローラー部分の役割と規約を決めれば、（つまり、コントローラーでチェックまでするのか、値セットはするのか、それともなにもしないでモデル呼び出しか？などなど）とりあえず、コントローラーの分離もできそうだ。

---

で、自動生成になるわけなのだが、画面定義書を
１．画面遷移図
２．各画面について
　　　（・画面の図）
　　　・各画面項目の説明
　　　・イベント発生時の処理
　と別れている場合、画面の図がViewであり、ここをXHTMLで書くようになる。
　このとき、各画面項目の説明で示された、IDをXHTMLでセットすることになる。
　各画面項目の説明から、自動生成もありだ（ぶらんこみたいなかんじ）

　イベント発生時の処理に対応する関数をaddListnerすることになる。
　なお、画面表示時はLoadイベントになる。

---

なーんておもったりしたわけ。
けっこう、AJAXの場合、型にはまりそうだ。

ケータイで英語を提示、発音等をチェックするっていうのは、確かにアリかも

　昨日のＮＨＫラジオ「ビジネス英会話」で、たしか、高橋修三が言ってたと思うんだけど、ケータイ端末で英語を提示して、それを読み上げ、発音をチェックするっていう教材は、アリかもしれない。

　ちょっと、高橋修三と考えているやり方はちがうかもしんないけど、こんなかんじ。

ケータイのテレビ電話って、普通、顔を映すけど、ここでは、

１．先生のかわりに英語教材（英語で書かれた文章と、絵）を写す
２．生徒は、テレビ電話でその文章を読む。まあ、質問なんかもＯＫだ
３．先生は、（英語教材が写っているので）写ってないけど、実際には、いて
　　ケータイのテレビ電話で、生徒の読み上げた英語の発音などをチェックし、
４．良くなかったらコメントし、良かったら、次にいく。

　この方法だと、先生は、どこにいてもいいし、映らないので、どんなかっこしててもいい。
　そう、生徒は一生懸命、ケータイに向かってお勉強しているが、実は、先生は、人件費削除のため、インド人で、インドにいるなんていうのもＯＫ（コメントするとき、しゃべらないで、文章で提示するようにすれば、インド人って、ばれないばれない　＾＾；）

　つーか、人間じゃなくってもＯＫだけどね。

　たしかに、これは、アリかも

ケータイ、webアプリで必要な「ファイル等のデータをどこに置くか」戦略（その２：データの種類）

　前に書いた話のつづき。
　ファイルをクライアント側に置くのに制限がある（容量が少ないとか、クライアント側では更新できないとか）場合に、あらかじめ、ファイルをどこにおくか（サーバーか、クライアントか、それとも他の外部か？）の戦略を決める必要があるときがある。
　そのときの考え方。

　で、その手順を、前のブログでは、以下の３段階で考えると書きました。

　戦略には、次の３ステップがある
第一ステップ：どこにおけるか考える
第二ステップ：どんなデータがあるか考える
第三ステップ：どんなデータをどこに置くかを考える


今回は、第二ステップ。どんなデータがあるかについて。

---

■データは、マスタ系とトランザクション系にわけられる
データは、マスタ系とトランザクション系に分けられると思います。

＜＜トランザクション系＞＞
　業務を遂行するときにできるデータ（発注・受注データなど）です。
　業務を行う中で、作成され、更新されたりします。たいてい参照され、削除されることも多いです（かならずしも、削除されるとは限らず、ずーっとたまってしまうケースあり）。
　業務を行うことによってできることが特徴で、多くは、業務名＝ファイル（ＤＢ）名になります。

＜＜マスタ系＞＞
　業務を行う以前に、すでにないと困るデータ（ファイル・ＤＢ）です。
　たとえば、受注業務を行う前に、商品マスタがないと困ります。そうしないと、商品が発注できませんから。。

　ちなみに、中間的なデータとして、ファイルを利用する場合、連番用のファイルというのがある（受注データの連番ファイルで、新規受注データ書き出しことに１上げて保存する）

　なお、上記はウィリアムのいたずらの独断と偏見であり、受注マスタというファイルが存在する場合がある。この場合のマスタの意味はちがい、その場合は、夜間バッチをやる前のデータがマスタであり、今日１日の最新データがトランザクションという意味である。昔のＣＯＢＯＬなどで、この概念がある。

　さらに、感覚的にマスタ・トランザクションといっている人もいる。

　でも、ここでは、そんなことはどーでもよくて、あくまでも、話をすすめるための分類なので、今回は、上記の分類で行く。

---

■トランザクション系は、画面に対応していることが多い
　で、トランザクション系は、業務に関係していると書いた。
　で、一般に、業務にそって、画面を設計することが多い。そのため、

　　「この画面では、このトランザクション系のデータを扱う」

という形になることが多い。

　たとえば、受注と受注明細データは受注画面であつかう。
　たとえば、発注と発注明細データは受注画面であつかう。

などなど。

　そーすると、画面表示（切り替え）のタイミングで、ファイルを参照・更新できればいいということになる。なので、これらのデータは、サーバーにおいておいて、画面切り替えのたびにサーバーアクセス、必要なデータをとってくればいいというケースが多い。

■マスタ系は、おおきく２つのタイプがある
　で、マスタ系だが、大きく２つのタイプがある。
　１つは、コード的に短く、種類も少ないもの
　　→コードが短く、種類が多いと、表現できない。
　　　２桁で、１０００００個の種類のデータを表現しろって（＾＾；）
　　　例：性別、星座、都道府県コード、曜日、

　もうひとつは、コード的に長く、種類が多いもの
　　例：従業員コード、商品コード

　で、マスタ系は、参照されるのが不定期で、入力したら、すぐに反応しないといけない場合もある。たとえば、商品を入力したら、単価をすぐに出し、あと、数量をいれるなど。
　この場合、商品マスタのデータをすぐに表示しないと（画面切り替えしないで）入力のときに待ちができてしまう。

　逆に、マスタデータとおなじで、画面切り替えのタイミングで参照したり、更新するときだけ必要などというものもある。

---

　そして、この場合、こんな性質を持っている気がする
　（あくまでも経験上、大雑把に分けたもので、例外はある）

　コードが短いものは、変更されることが少ない。
（性別は、たいてい男女しかない。星座は１２だし（１３？）都道府県は、たぶん合併されることはない。年号は、とーぶん増えそうもないし？？仮に増えたら、つぎ増えるのはずっと先）

　コードが長いものは、変更されることが結構多い
　商品マスタ、従業員マスタ。。。

---

　ということで、「第三ステップ：どんなデータをどこに置くかを考える」場合、トランザクション系はサーバーにおくのはいいが、問題はマスタデータをどこにおくか？という戦略が重要になる。

　で、第三ステップになるのだが、まあ、それは気が向いたときに。。

昔の購買過程と、インターネット時代の購買過程では違うそうな、ってこれって衝動買いでは（＾＾；）

　放送大学大学院、総合情報学（’０６）によると（テキストP３１、第二回）、

　昔の商品を買う購買過程と、
　インターネットによる商品の購買過程でちがいがあるそーな。

---

　昔の購買過程は、AIDMA（アイドマ）と呼ばれるもので、以下のように、購買過程が進みます

　認知(Attention)：ほお、こんなものが売っていると知る
　↓
　興味(Interest)：興味を持って調べる
　↓
　欲求(Desire)：買いたいと思う
　↓
　記憶（Memory)：商品を買うことを、記憶にとどめておく
　↓
　行動（Action):お店に行って買う

　頭文字をとって、AIDMAといいます。はい。中小企業診断士のお勉強で、勉強した気がします。
　ここの特徴は、「記憶する」という過程が入ることです。

　買いたいと思っても、お店に行かなけりゃ買えません。
　持ち合わせが無ければ、買えません。

　なので、その間記憶しているわけですが、そーすると、忘れるっていうことももちろんあるけど、冷却期間もあるわけです。例えば、買いに行こう！と思っても、いやまてよ。。高くないかあ？とか・・
　したがって、興味を持ち続けさせることが重要なわけです。

---

ところが、インターネット時代は違うそうです

　認知(Attention)：ほお、こんなものが売っていると知る
　↓
　興味(Interest)：興味を持って調べる
　↓
　検索(Search)：ネットで検索してお店を調べる
　↓
　行動(Action)：その場で発注・購入
　↓
　情報共有(Share)：メールやブログで買ったことをいろいろ話す。

　つまり、検索して、お店が見つかったら、もう、行く必要が無く、すぐに買えて、すぐに決済です。記憶している必要は無いです。お店に行かなくていいし、カードがあれば即決済ですから。。

---

　って、これって、よーするに、「ネットは一歩間違えば衝動買い！」って言ってるような気が。。

　たしかに、それはありますよね。

　カード決済の場合、お金は出さないので、１０万円、２０万円といっても、その重みというのは感じられない。
　とくに、これはカード決済ではないけど、株の信用取引なんかそーです。
　３０万のものを買いを入れたり、ふつーにしますけど。。
　３０万円って、すごいっす（＞＿＜！）

　ってなことで、ネットの場合、すぐにお店を見つけられて、すぐに買えてしまい、決済のときにあんまりお金の重みを感じないので、今までの購買パターンとは、ちがうかもしんない。
（知らず知らずのうちに、無駄遣い？）

家庭用電話機をスカイプに利用できるアダプタ「すかい楽」

こんなニュースが

イーレッツ、家庭用電話機をスカイプに利用できるアダプタ「すかい楽」
http://bb.watch.impress.co.jp/cda/news/13684.html

一瞬、「おお、これいいかも、入れようかな。。」って思ったけど、
冷静に考えたら、スカイプで話さなきゃいけない相手は、いなかった（＾＾；）
あ、入れてもムダだ・・・

ケータイ、webアプリで必要な「ファイル等のデータをどこに置くか」戦略（その１：置き場所）

　ここに書いた、ファイルをどこにどう置くかという戦略について。

---

■なぜ、そんな戦略が必要か

　FlashやJAVAScript、Javaのアプレットを利用したプログラムの場合、参照・更新できるデータがある場所というのは、（セキュリティ上）限られている。ローカルのファイルを、基本的に更新・削除できないなど。

　また、ケータイの場合、ＢＲＥＷは、そんなに容量的な制限を感じないかもしんないけど（なことない？）、iアプリなどでは、容量的な制限があるかもしんない。

　てなことで、データをどこにどのような形で置くかということを考えないと、システム的な処理スピード上、問題が出ることがある。

　たとえば、商品コードを入れたら、商品マスタを参照し、単価を表示するといった場合、商品マスタがサーバ側にあると、必ず、サーバー通信が入る。そうすると、商品１件ごとにサーバーと通信しないといけなくなり、入力が極端に遅くなって、実用にならなくなる。
　このようなことを避けるために、データのおき場所戦略が必要になる。

---

■戦略の立て方
　戦略には、次の３ステップがある
第一ステップ：どこにおけるか考える
第二ステップ：どんなデータがあるか考える
第三ステップ：どんなデータをどこに置くかを考える

今回は、まず第一ステップについて考える

---

■第一ステップ：どこにおけるか考える

　データを、どこにおけるか、そしてどうやってアクセスするか考える。
　この場合、今回、話題がクライアントなので、クライアントを中心に考える。
　なお、ここであげた置き場所は、考えられるものを挙げただけで、実際の場合は、この中にも使えないものがある（ケータイの場合、環境変数って？のように）

おき場所

（１）サーバーにおいて、サーバー通信で取得する
　サーバーに、ファイル、ＤＢ，プロパティファイルの形でおいておき、サーバーと通信することによって、値を取得する。一般的な方法である。
　クライアントの立場から考えているので、サーバーでは、どんな形（ファイルかＤＢか）ということは問わない。とにかく、サーバーにあるものは、クライアントは通信して取ってくることになる。

（２）クライアントの環境変数
　クライアントの環境変数の中に入れる。
　一般にこの場合は、
・複数のアプリで利用するもの
・（後述の各プログラムの）プロパティファイルのありか
　を入れておくのがいい。なんでも環境変数にいれてしまうと、バージョンごとの競合が起こったり、予期しないアプリ同士の名前の一致で変な動きになったりする危険があるので。

（３）プロパティファイル、INIファイル
　クライアントの中にあるプロパティファイルや、INIファイル。
　クライアントのプログラムごとに、独自のデータを入れとくのに都合よい

（４）クライアント側のファイル、ＤＢ
　クライアント側にファイルを持つ。もてないものもある。
　制約は、いろいろある
　また、BREWの場合、IDATABASEを使って、クライアント側にＤＢっぽいものももてる。
　ある意味、ケータイのアドレス帳もＤＢとみていいだろう。

（５）プログラムの中に埋め込み
　短いコードなどでありえるのだが、プログラムの中にコードとして埋め込んでしまう。
　たとえば、Webアプリの場合、性別：男、女は、これ以外、普通ないので（ということにしておく）
＜Select name=seibetsu size=1>
　＜option value=1＞男＜/option＞
　＜option value=2＞女＜/option＞
＜/selected＞
としてしまって、もう、男、女を１、２で返すものと、ＨＴＭＬファイルの中で埋め込んでしまうのもありだ。星座、血液型、都道府県、などなど、この手は結構いっぱいある。
　Javaの場合は、static finalの形、Ｃなどの場合はdefineにする。

（６）データを返すアプリをつくる
　あんまり言われないけど、こーいうことも考えられる。
　アプリ側で、値を返すアプリを作ってしまい、そいつを呼び出すということだ。
　これが、サーバー側にあると、ＳＯＡということになる。

（７）外部から
　ＱＲコードやＩＣタグなど、外部からデータを持っているものを取り込むケース。
　現在は、コードのみだが、ＱＲコード等の場合、データだけでなく、商品名、単価を持つことも、可能である。

---

■実際には
実際には、ケータイの場合、
（１）サーバー、
（４）ファイル
（５）プログラム埋め込み
（（６）データを返すアプリもあり？）
（７）外部から
が利用可能であり、

JavaScriptの場合、
（１）サーバー、
（４）ファイル（読み込み）
（５）プログラム埋め込み
が中心となる。

---

っていうことで、今回はおしまい。続きの「第二ステップ：どんなデータがあるか考える」については、また気の向いたときに。

これって、ケータイでとった写真をフィギアにするサービスもできる？なんか、出てきそーだよね！

　たまたま、「くるくるドカン」というフジテレビの番組を見たら、マスターマインドっていう会社をやってました。
　この会社、曲面に印刷するプリンターを出していて、プリクラの写真を小型の人形に印刷する（顔の部分を、人形に印刷する）っていう機械を作ったらしい（ここのニュースにも載ってる）。

　プリクラの写真でできるなら、別にデジカメの写真でも、ケータイでとった写真でもいいわけっすよね。
　おお、じゃあ、ケータイでとった写真をフィギアに印刷するなんつーサービスも出てきそーだったりする。。

シンクライアントには、大きく４種類あるようだ

　やっと最近、時間ができて、日経System４月号を読むことができた。
　で、１７４ページの

　プロダクト　知る・選ぶ・使う
　シンクライアント

をみて口あんぐり
　前のブログで書いたのは、シンクライアントの１方式であり、
　また、後半に書いた端末に仮想側にメモリのドライブを用意して（ってできるのか？）そことやりとりっていう方式も１方式で、すでに製品があり、結構、手を入れないといけないって書いたけど、その機能を行うミドルウエアやＬＡＮカードもあるようだ。

---

　ということで、その内容をまとめると、

　シンクライアントには、以下の４種類があるらしい
●サーバーベース
　前のブログで書いた、サーバーですべて処理するもの
　問題点としては、そこに書いたとおり、ＣＡＤなど高速で画面が変わるのが苦手

●ＫＶＭスイッチ＋ブレードＰＣ
　ＯＳやアプリをユーザーごとに用意するブレードＰＣ単位で管理

●サーバーベース＋ブレードＰＣの混合
　ＯＳの処理はサーバー側で実行
　端末側では画像データの再生処理などを行う
　製品例：日立、日本ＨＰ、

●ネットワークブート
　前のブログの後半で書いた、ディスクイメージを端末のメインメモリに展開してしまう
　方法。これを行うために、ミドルウエアArdenceとPXE対応のLANカードが必要になる
　製品例：NEC,DELL(ThinkPC)など　実用例：外為どっとコム
　なお、この方法にはディスクイメージを共有する方法と非共有の方法がある

---

　おお、でも、ネットワークブートの方法では、今度、特殊なアプリが必要となってくるわけで、お金かかりそうです。

もっと手軽にクライアント側で処理させるには、ディスクのファイルを２種類にわけて、
・サーバー側においておきたいファイルを利用する処理は、サーバーで処理
・クライアント側では、ファイルごと（メモリに）転送し、クライアントで処理
として、これでクライアント処理をブラウザで行えれば、現状のブラウザによるＷｅｂアプリでできることになります。

　で、そのためには、
・まずサーバーに置くべきファイル、クライアントに置くべきファイルとは？
・クライアント側に転送って？Ｗｅｂでは、保存できないけど。。
　っていうことを説明する必要がある。それが、今後暇なときに書こうとしている
　そして、ここで書こうとしたファイルをどこにどう置くかという戦略っていう話だったりします。

「今年中にPDFとFlashを統合する」とＡｄｏｂｅのＣＥＯが発表、で、ケータイは？

ここのニュース
米AdobeチゼンCEO、「今年中にPDFとFlashを統合する」
http://news.goo.ne.jp/news/internet/it/20060422/iw2006042205-internet.html

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

注目されるPDFとFlashの統合については、「PDFが持つ信頼性・セキュリティと、Flashが持つアニメーションにより、より表現力豊かなコンテンツを作ることができる。統合に向け力を入れている」と、積極的に取り組んでいるとした。統合の時期については、「年末までには示すようにしたい」と、年内に統合製品を発表する考えであると述べた。

　PDFとFlashの統合製品については、「提供の形態については現在検討しているが、PDF・Flashの両方に対応し、またHTMLにも対応したプレーヤーとなるだろう」と説明した。


ご、ごめん。。。どんなもんなのか、ちょっと思いつかない（＾＾；）

さらに

　日本市場については、「Adobeにとって、日本は米国に次いで世界で2番目の市場。特にモバイル市場については、米欧が発展途上国と思われるくらいに先進的だ。携帯電話の各キャリアや端末ベンダーと今後も協力し、積極的に展開したい」と説明。


ってことは、多分そのＰＤＦとＦｌａｓｈの統合製品も、ケータイに対応していくのかなあ。。今、Ｆｌａｓｈがケータイで動くのだから。。。

　うーん、やっぱり、もっと、わからん？？

NHKが１番組まるまるネット配信、これぞ放送とネットの融合？でも民業圧迫に配慮してか。。？

　おお、これぞ放送とネットの融合？なのかあ？

　ＮＨＫがテレビ番組１番組丸ごとをネットで見れるようにしてますね。
　それも、放送後、すぐに。。

ＮＨＫ高校講座　数学基礎
http://www.nhk.or.jp/kokokoza/suugakukiso/2006/study01/index.html
ここの「番組を見る」をクリックすると、１番組まるまる見れます。

　ラジオ番組ではありえたけど（実際、たしか数学基礎も、ラジオの内容が公開されてた気がする）テレビ番組１番組、丸ごとノーカットで流してしまうとは（＾＾）。。
　それも放送後、すぐに。。

　ＣＭとか、著作権関係の問題が出そうな民放なんかでは、まねできない芸当なのかも。。

　とはいえ、民業圧迫に配慮してか、数学基礎だけみたいです。
　数学基礎の講師は秋山仁と、まあ、昔有名な、（講義を取るのに徹夜しても取れない）カリスマ講師。。。ではありますが、今、高校講座で一番人気といえば、物理の山本薫タンのようですので。。。それは、はずしているようです。

　また、将来的に薫タンの強敵となりそうな高橋あゆみさんの数学１もはずしているみたいですけど。。。

　それはいいとして、平野麻樹子さん（今回は水着姿をリンクしてみました）の地学と、小笠原亜里沙さんの日本史をネット配信してよ（＾＾）／。。ＮＨＫさん！

MS OfficeのバージョンアップOffice2007、タブUIが売り物のだけなら。。

Microsoft Officeがバージョンアップするそーですね。
ここのニュース
タブUIを採用した「Office 2007」公開
http://www.itmedia.co.jp/news/articles/0604/20/news063.html
タブＵＩになるくらいの変更なら、前のOffice使ってよーかということになるけど、

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

Office 2007では、Word、Excel、PowerPointでMicrosoftが推進するXMLドキュメント規格「OpenXML」ファイルフォーマットを採用する。各アプリケーション間でデータ交換を単純化し、連携を高めるのがねらいだ（関連記事参照）。

　ファイルの拡張子は「.docx」「.xlsx」「.pptx」と標準で末尾に「x」が付く。現行のファイル形式との互換性は維持し、新形式のファイルをOffice 2000／XP／2003でも「保存」「開く」が可能にする「File Format Compativility Pack」をOffice Updateなどから無償提供する予定という。


うーん、フォーナットが変わるのかあ。。
互換性は維持するとはいえ、Excelの２００３のときも２０００と違って、お仕事上、こまったことがあったしい（２００３のExcel VBAで開発して、できてると思ったのに、検証不可、理由は検証したひとが２０００でみてたからで、たしかに２０００で見ると。。おお、そろってないじゃん（＾＾；）納品先は２００３なので、そのままでＯＫとなったが、気づくのに半日かかった）。

やっぱ、バージョンアップしないといけないかにゃー。
でもタブＵＩとＸＭＬ書き出しのためにバージョンアップはもったいないなあ。。

シンクライアントの場合、CADとかで、問題が起こるって、昔聞いた。

　前のブログでも書いた、サーバー側に全てをやらせる場合の問題の話。

　シンクライアントなんかでも、それで問題があるという話を昔、あるセミナーできいたことがある。

　そのシンクライアントは（つーか、一般にそうなのかも知んないけど）、
・サーバーがわで全て処理する
・画面の内容を、クライアント側に送る
・キーやマウスの操作情報をサーバーにおくり、サーバーで処理する
→つまり、昔でいうダム端とおなじ。
ってなかんじなのだ。
　で、講師は、この優位性を説いていたわけなのだが、質問の時間に、ある人が、

「CADとか使うと遅くなりませんか？」

といっていた。

---

たしかに、この方法だと、画面が変化するたびに、画面データを送るわけで、さらにサーバーでは、何台分のクライアントのCAD操作を処理するわけで、さらに何台もの画面データを送るとなったら回線が・・・
　などと考えると、このサーバー一括処理というのは、CADやフォトレタッチなどでは、きつそうだ。

　ちなみに、講師はしどろもどろになりながら、たしかにCADなどでは、遅くなるが、そーあんまり使わないでしょ！といっていたが、それは、そーとーむりがある。

　お役所などで導入するとすると、CADのようなデータはかなり多いわけで（道路工事するときの図面。どこにガスがはいってて、どこに電話線が埋まっててみたいな図を役所は保管している）、CADデータは重要なのだよ。

---

　もちろん、この場合、CADデータを読み込み時に、クライアント側のメモリ領域に転送してしまい、保存するときに、サーバーに保存するようにすれば、処理はクライアントのメモリ領域内のファイルだけとのやりとりなので、スピードはうるわしく速くなるだろう。

　しかし、この場合、端末に仮想側にメモリのドライブを用意して（ってできるのか？）そことやりとりなどというように、あとからこのやり方をするとなると、結構、手を入れないといけない（CADのプログラムのほうも対応しないといけないかもしんない）

現実解としては、こーいうシンクライアントを導入せず、ファイル共有によって、ファイルサーバーにデータを保存し、クライアント側には、保存しないということが考えられる。
　これでも、クライアント側はディスクレスにできるので、シンクライアントに近いものができる。
　しかし、この場合、今度は作業ファイルも、サーバー側にあるため通信でやりとりするようになる。

---

　あ、そうそう、そんなこと書くと、いやー簡単ジャン！自分のところにサーバー立てて、ファイルはそこに保存し、そことやり取りすれば、いいじゃんっていうかもしんないけど、それは、自分のところにファイルを保存することになるのでシンクライアントにならない。

　
　っていうわけで、サーバーに全部の処理を任せるという考えは、破綻してしまう。
　ということで、適所適材にデータを置くということになる。
　それが、前のブログで書いたファイルをどこにどう置くかという戦略が必要になってくるっていうことだったりする（ちょっと話がそれたので、強引に結論に持っていきました）。

iアプリとＢＲＥＷの開発上の違い：ファイル編

ちょっと時間とお金に余裕ができたので、
「iモードJavaプログラミング５０４i対応版」
っていう本を買ってみた。

ぱらぱらとめくってみて、ちょっと感じたのは、

ＢＲＥＷ２．１の場合、ファイルアクセスは
・IFileMgrからIFileで、自分のアプリフォルダの中のファイルの入出力
・IFileCpで、データフォルダへのファイル書き出しと読み込み

ＢＲＥＷ３．１の場合、ファイルアクセスは
・IFileMgrからIFileで、自分のアプリフォルダの中のファイルの入出力はもちろん
・IFileMgr(ファイルはfs:/card0/pc)からIFileで、MiniSDカードへの入出力
・IFileMgrからIFileで、その他共通エリアへのアクセス
　→審査上の規制有（出さなきゃいけないメッセージなどあり）
・IDataFolderで、データフォルダへのファイル書き出しと読み込み

となっているが、この本では、iアプリのファイルアクセスの方法がよくわかんない。。

どうも、ここによると、ScratchPad領域というのがあり、そこへ書き込み、読み込みができるようだ。
　ただ、ここに書いてあることが、今もそうなら、ScratchPad領域というのは、ＢＲＥＷのファイルで書ける容量より、はるかに小さそうだ

　とすると、システム設計する際に、iアプリでやるとすると、ファイルをどこにどう置くかという戦略が必要になってくる。テキトーにファイルに保存してしまうと容量が足りなくなるし、ネットワークアクセスしてサーバーに必ずお伺いを立てると、アプリとしてのスピードが遅くなるし、パケ代の問題も出てくる（定額制なら関係ないけど）

　これは、シンクライアントの場合などでも、問題になりそうなので、他の機会に書こうと思う。

　ただ、もちろん、定額制で、回線速度が速くり、サーバーに十分なリソースがあれば、このような戦略は要らず、どーんと、サーバーと通信してしまえばいいわけですけど。。

ファイル間でトラックバックを付けて文書管理：IFRAMEからCGI呼び出し

　前のブログで書いた、ファイル間にトラックバックを付けて、元の文書をなおさずに、修正文書や関連文書にリンクを貼る方法について。

そのために必要なこととして、
（１）トラックバックを手動で作成するプログラム
（２）トラックバックを受け付けるCGI
（３）トラックバック表示CGI＋トラックバックされるファイルにIFRAMEタグ

ということで、（１）、（２）、（３）のCGIは前に書いたので、今回は（３）の後のほう、「トラックバックされるファイルにIFRAMEタグ」についてです。

---

■トラックバックされるファイルにIFRAMEタグ仕様
　前の、トラックバック表示受け付けCGIで、表示する内容はできているので、
　IFRAMEタグを使って、最新のトラックバック内容を表示するようにします。

---

■HTMLの内容

　HTMLファイルを作成したら、最後のところに、
　＜IFRAME　SRC=”表示CGIのURL"＞＜／IFRAME＞をいれてください。

こんなかんじです。

＜html＞＜title＞ファイルのテスト＜/title＞
＜body＞
＜P＞
ここの部分に本文が入ります＜P＞
＜p＞
●このページについているトラックバック＜BR＞
＜IFRAME SRC="http://mokano.main.jp/temp/tbdisp.cgi?ID=20060218001"＞＜/IFRAME＞
＜/BODY＞
＜/HTML＞

（上記プログラム中、　＜　＞　￥　は、本当は、半角です）

そーすると、こんなかんじに表示されます

ここのリンク先をクリックすると、トラックバック先が開きます。

---

ということで、気が向いたときに、あとはこのプログラムを使って、実際にトラックバックをつけた例を示します。

ファイル間でトラックバックを付けて文書管理：トラックバック表示CGI

　前のブログで書いた、ファイル間にトラックバックを付けて、元の文書をなおさずに、修正文書や関連文書にリンクを貼る方法について。

そのために必要なこととして、
（１）トラックバックを手動で作成するプログラム
（２）トラックバックを受け付けるCGI
（３）トラックバック表示CGI＋トラックバックされるファイルにIFRAMEタグ

ということで、（１）、（２）は前に書いたので、今回は（３）トラックバック表示CGIについてです。

---

■トラックバック表示CGI仕様
　前の、トラックバック受け付けCGIで、
　　CGIのあるところに、引数のIDに指定された値でフォルダを作り、
　　その下にitem_番号.txt （番号は連番）というファイル名で
　　　ファイルの中身は
　　　１行目にトラックバック元URL
　　　２行目にトラックバック元の名前
　　　３行目にタイトル
　　　４行目に内容
　が入っています（改行で１行、もともとの改行データは＜BR＞に書き換えられています）

　このトラックバック受付CGIと同じところにトラックバック表示CGIも置きます。
　このトラックバックCGIが、例えばtbdisp.cgiという名前で、ローカルのcgi-binになったとしたら、こんな感じで呼び出します。

　http://127.0.0.1/cgi-bin/trdisp.cgi?ID=20060218001

　IDは、トラックバック受付CGIで設定したIDと同じで、
　１トラックバック先１IDとなるようにしてください（名前は任意）

---

■プログラムの概要
・引数をとっきて、IDを決定
・指定されたIDのディレクトリの中をみて、
・itemという言葉を含むファイルであれば、その１行目から４行目をとってきて
・てきとーに表示する内容を出力し
・ディレクトリ内の全ファイルをみたら、close

で、そーすると、以下のプログラムになります。

---

■プログラム

#!/usr/local/bin/perl
use CGI;


				#################################
				#	必要な変数の取得	#
				#################################
##引数を取得
if ( $ENV{'REQUEST_METHOD'} eq "POST" )
{
	read (STDIN, $qs, $ENV{'CONTENT_LENGTH'});
}
else
{
	$qs = $ENV{'QUERY_STRING'};
}
@qs = split(/&/,$qs);
foreach $i (0 .. $#qs) 
{
	($name, $value) = split(/=/,$qs[$i],2);
	$value =~ tr/+/ /;    #“+”を空白
        $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;   # %XX変換
	$qs{$name} = $value;
}


				#################################
				#	受信チェック		#
				#################################
#フォルダ名の取得
if ( $qs{"ID"} eq "" )
{
	$qs{"ID"} = "default";
}

#見出しの表示
print "Content-Type: text/html￥n￥n";

#受信したか、ファイル確認
opendir chk_dir,$qs{"ID"};
while (($fname = readdir chk_dir))
{
	# itemという言葉が入ってなかったら対象ではないのでジャンプ
	if ( index($fname,"item") == -1 )
	{
		next;
	}

	#ファイルＯＰＥＮ
	open (CHK, $qs{"ID"} . "/" . $fname);

	#データの取得
	$sakiURL=＜CHK＞;		#	1行目のＵＲＬの
	$sakiName=＜CHK＞;	#	2行目の名前の取得
	$sakiTitle=＜CHK＞;	#	3行目のタイトルの取得
	$sakinaiyo=＜CHK＞;	#	4行目の内容の取得

	#ファイルクローズ
	close(CHK);

	#出力内容の作成
	print '●' . $sakiName . '＜BR＞　　＜A HREF="' . $sakiURL . 
		'"  TARGET=_blank ＞' .$sakiTitle .'＜/A＞＜P＞';

}

closedir chk_dir;

（上記プログラム中、　＜　＞　￥　は、本当は、半角です）

---

ということで、次回はIFRAMEのほうです。