彗星衝突の危険のYAHOO News英語版から、特定の人に特定の広告を出す方法を考える

YAHOOのアメリカ版つーか、本家のYAHOOのニュース（つまり英語）の

元空軍航空管制官が２００６年５月２５日に彗星が地球に衝撃を与えると警告（もちろん原文は英語でウィリアムのいたずら訳）
http://news.yahoo.com/s/usnw/20060413/pl_usnw/former_military_air_traffic_controller_claims_comet_collision_with_earth_on_may25_2006104_xml

なんだけど、記事自体は、どーでもいいとして

（よくなーいって（＾＾；）ちなみに、出だしを訳すと、こんなかんじ

　Eric Julienという元フランス空軍航空管制官で上級空港マネージャー（なんじゃそりゃ）は、73P Schwassmann- Wachmann彗星の研究を完了し、２００６年５月２５日に地球あるいはそのまわりに、（彗星の）破片が、高い確率で、衝撃を与えると宣言した。
　Schwassman-Wachmann 彗星は、太陽系と交差する楕円の５年周期の軌道をとっている。そいつ（＝彗星）は、何百年間もその５年の軌道をとってきたが、１９９５年、神秘的な分裂をした。
　 Julienによれば、。。。

そっからさきは、ウィリアムのいたずら自体、？？？とおもうので省略）

　この記事、こんな風に出るんですよ。


　つまり、YAHOOの英語版をアクセスしているのに、右側に日本語の宣伝が出てる。。。

　これって（アメリカ人に、日本語の広告だしてもしょーがないんで）、IPかサーバー名かなにかをみて、日本からみてるっていうことを確認して、広告を出してるってこと？

---

　たしかに、前に示したように、CGIでもPHPでも、見ている人のIPアドレスやアクセスしているサーバーを取得することはできる。そこで、そのアドレスに.jpという文字列があったら、日本語の広告を出せ！とすれば、簡単に、できることはできる。

　これを応用すれば、ODNからアクセスしてきた人だけは、乗り換えキャンペーンの広告を出すとか。。

　つまりここに書いたように、CGIなら

$host = $ENV{'REMOTE_HOST'};　　　　#これで、アクセスされたサーバー名
$addr = $ENV{'REMOTE_ADDR'};　　　　#これで、アクセスされたIPアドレスがわかる

もし、IPは入っていて、サーバー名が無いなら、gethostbyaddrすればいい。

っていうことで、サーバー名はわかる。

そしたら、そのサーバー名の中に、”ocn.ne.jp”という言葉が入っていたら、広告を出すCGIを書けばいい。
　さっきのYAHOOの広告は，多分、同様に、.jpが入っていたら、日本語広告を出すようにしているのだろう。。

　これって、いろんな応用が出来そうだ。広告だけでなく

　自社のサーバーからアクセスしている人だけ、あるページに飛ぶとか、
　
　仮にIDとパスワードが一致しても、特定のサーバーからアクセスしないと受け付けず、
　さらに、その特定のサーバーに入るには、コールバックしてもらわないと入れない
　（＝なりすましできない）とか。。。

　

---

　で、ところで、彗星は、どーしたんだ（＾＾；）

ケータイ＋webによる業務システム構築の場合、先にモデル部分を先行して作ったほうがいいかも

　表題に書いたとおり、ケータイ＋webによる業務システム構築を考える場合、MVCにわけて、先にモデル部分を先行して作ったほうがいいかもって、最近思う。

　なぜかというと、ケータイには、容量もそうだけど、かなり制約がある。
　審査が必要だったり。。

　ということで、業務モデル部分をケータイの開発と一緒に作っていると。。。
　あちゃー！制約に引っかかっちゃう！っていうことになる。
　この時点で分かっても後には引けない。

　しかし、Javaでモデル部分を開発しておけば、どの機能までをiアプリで、どの機能からは、Strutsやservletでと、切り分けられる。将来的には、iアプリでなく、（ケータイ用の）AJAXを使うとか。。

　ってなわけで、ＭＶＣにわけて、モデル部分は、先行して開発し、入出力、クラス関係を明確にして、その後、ケータイとＷｅｂのきり分けということになるだろう。

　この場合、入出力は抽象的というか、カオル姫方式みたいに、メモリわたし（ハッシュマップの中にいれるみたいな）にしておいて、実装のときに、入出力部分をどーするか考えたほうがいいと思う。

　で、モデルを作成するときには、ドライバをつくり、そのドライバから、そのメモリにセットしておくと。
　後で入出力部分が出来たら、入出力部分がメモリに値をセットすると。。

　そーいうかんじがいいんじゃないかなあ。。

iアプリの仕様からの自動生成を考えるまでもなく、仕様書の画面定義は２ブロックにわかれる

　画面定義書は、まず大きく、
　・画面遷移図と
　・各画面の説明
　にわかれる。これは、いい。

　で、各画面の説明なのだが、これも、２つに大きく分かれる。
　そのうちの１つは、
　　　・画面の項目定義
　もうひとつは
　　　・その項目がなんかされたときにイベント定義
　だ。

---

　この説明を、かりに、iアプリを画面定義書から自動生成することで、考えよう。
　ここではpanelを使うとする。
　１画面で１panelとすると、
class gamen1 extends Panel implements ComponentListener,SoftKeyListener {

:
:

}

class gamen2 extends Panel implements ComponentListener,SoftKeyListener {

:
:

}

class gamen3 extends Panel implements ComponentListener,SoftKeyListener {

:
:

}

とかなるわけ。

　このとき、画面の項目部分っていうのは、panelの仕様で、どういう部品を使うか（addするか）を書く。

　もひとつの、イベント定義っていうのは、イベントリスナーを登録して、イベント処理を呼び出すけど、それのこと。

　この２つがそろって、はじめて自動生成可能になってくる。。

。。。って、なおさらわかりにくいか（＾＾；）
まあ、こんなことをいうまでもなく、２つに分かれるのは明確な気もする。