“199ドルノート”日本発売決定、予価は5万円前後＝１９９＊１２０（円くらい）＝？。。。

ここのニュース
“199ドルノート”こと「Eee PC」が日本発売決定――予価は5万円前後
http://headlines.yahoo.co.jp/hl?a=20071218-00000038-zdn_pc-sci
によると(以下斜体は上記サイトより引用）


　ASUSTeKは、低価格モバイルノートPC「Eee PC」の日本発売決定をアナウンスした。OSにはWindows XPを搭載。発売予定時期は2008年2月で、価格はオープン。予想実売価格は5万円前後の見込みだ


えーっと、

１９９ドル＊１２０円くらい（１ドルの値段）＝２３８８０

えーっとえーっと、おかしいなあ。。５万円くらいにならないぞお（＾＾；）

可能性
（１）ウィリアムのいたずらの電卓が壊れている
（２）２月ごろには１ドル２５０円になる（まさか　＾＾；）
（３）オープン価格なので、２３８８０円で売る店も・・・ある？？
（４）その他・・・

のうちどれ！

これって、不当表示にならないの？（冗談ですよ　^^;)

ネットワークのキーワードまとめ－セッション層～アプリケーション層編

　シリーズ「ネットワークのキーワードまとめ－トランスポート層編」の続き。
　今回はセッション層～アプリケーション層編。

---

＜＜セッション層～アプリケーション層＞＞

■機器
PC

■プロトコルというか、アプリケーション名
DNS
FTP,TFTP
HTTP
SMTP
SNMP
Telnet

■関連用語
・URL、ポート番号
・Socket（セッション層）
・コード／フォーマット変換（プレゼンテーション層）
・CISCO IOSイメージ（TFTP)
・SNMP
　　・NMS（ネットワーク管理システム）
　　・管理対象デバイス
　　・エージェント

---

次回は、超大雑把な、「インターネットとは？」の説明

Google GearsのローカルDBにキャラクターデザインを入れておき、AJAXで表示とか？

ここの岡崎さんのブログ
Google Gearsについて考えてみる
に（以下斜体は上記サイトより引用）

Google Gearsでのサーバー・クライアントの役割分担として

処理の役割に注目していきます。たとえばクライアント側で処理すべき役割はユーザインタフェースそのものの実現や、表示用のデータの管理です。一方、サーバ側では画面遷移や画面自体の生成が主な役割になります。画面遷移や画面生成をクライアント側に持っていくこともできなくはないですが、システムによっては画面要素に対してそれぞれ権限のチェックなどが必要だったりすることとから考えてサーバ側に置かれているべきでしょう。


　とあります。人により、システムにより、実現方法は違うので、そのような考え方に向いたシステムもあるかもしれません。ただ、画面と処理は明確に分けたほうが、プログラム上は、やりやすいと思います。

　つまり、以下のようにします。

・サーバーはRESTなりSOAPなりで、引数を受け取り、XMLを返す
　→認証に関しては、初めに認証を行ってセッションを保持することによって実現するか、
　　通信のたびに認証データを送信する

・クライアントは受け取ったXMLを元に、マッシュアップして（まあ、しなくてもいいけど）表示する
　そこで、画面遷移が起こることもあるし、画面自体を生成するようなケースもある。

　そーすると、サーバーは画面を意識しないので、提供するサービス＆認証チェックにのみ専念でき、
　SOAのように、サービス提供部分に前年することが出来ます。

　もし、端末を考慮するようになると、各種のケータイとかに全部サーバーが対応しないといけなくなり（ケータイごとに画面の大きさとかは違うので）たいへんなことになっちゃいます。というより、レスポンスが追いつかないです。

---

　で、こうなってくると、サーバーアクセスを毎回していたら、大変です（今、そーいう状態だけれど）。
　そもそも、業務で扱うデータは
　　　取引を保持するトランザクションデータ
　　　取引以前に存在し、あまり変わることのないマスターデータ
　に分けられます。

　このうち、マスターデータをサーバーだけに保持してしまうと、たとえば、入力時に、１文字入力したら、その名前で始まる人、あるいは商品を表示し、文字を入力するごとに絞り込むといった入力方法の場合、サーバーに逐次アクセスしなくてはいけないため、処理が追いつかなくなってきます。

　そこで、マスターデータの一部を、クライアントのローカルデータベース（というのが、Google Gearsにある）におき、適当なところ（１日一回とか）で同期を取るということになります。
　そして、受注とかの取引にかかわるトランザクションデータは、入力完了したところで、サーバーにおくるということになります。

---

　もし、このとき、ローカルとサーバーのマスターデータが同期が取れてなくて、サーバーデータのほうが更新されていたとしても、送られてくるトランザクションデータに含まれているデータをチェックすることによってはじけます。

　具体的に言うと、たとえば、

　受注品目：クリスマスケーキ
　価格　　：３０００円

　というのを、１２月の２５日の２１：００に注文したとすると、朝は、３０００円だったかもしれないけど、２１：００の時点では１０００円になっているかもしれません
（２６日は０円になってしまうう　＞＿＜！）。
仮になってたとしましょう。

　そーしたら、受注金額のところを、サーバーでチェック、値段が違うので、クライアント側に、「エラー」として返せばいいわけです（このとき、今の値段を返すか、同期を取るようにするかは、システムの事情次第）

　っていうことで、Gearの１つの利用法としては、あまり更新されないようなマスタデータをおき、レスポンスをよくするということがあると思います。

---

　また、昔、スクラッチド・パド・ファイルと呼ばれたと思うけど、検索件数が多くて表示し切れない場合、その表示していないデータも含めてローカルDBに入れておき、次の画面に行ったときには、ローカルDBから表示するという使い方もあると思います。

　それをさらに敷衍して、１画面分のアクセスをまずして、それを表示している間に、バックで、２画面目、３画面目をアクセスしていき、ローカルDBに蓄えておくという方法も考えられます（けど、ちょっとめんどっちいいかな）

　さらに考えると、ゲームのキャラクターデザイン、背景のデザインなどは、クライアント側のローカルサーバーにもっておいて、画面書き換えのときは通信しないで、ローカルサーバーのデータをみて書き換えるとすれば、(通信量が減るし、画面書き換えがスムーズにできるので）よりゲームとして完成度が上がってくると思います。

---

このように、Google　Gearによって、データを蓄えておく場所ができたので、完全にサーバー側はSOAに徹して、画面を意識せず、RESTでXMLを返すとかSOAPとかでのやり取りが出来るようになったと思います。
　そして画面側は、受け取ったものをとりあえずDBに入れて、必要なときに取り出して表示するという形をとることによって、データの先読みとか、サーバアクセスしないレスポンスが実現できると思います。

　そーやってつかうのが、よさげにおもいました・・