ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

消火ロボットとか、災害救助ロボットとか、必要だよね!

2007-07-20 19:33:33 | Weblog

ここのニュース
自主消防体制の強化を=原発保有11社に指示-柏崎刈羽被災受け・経産省
http://headlines.yahoo.co.jp/hl?a=20070720-00000107-jij-soci


ただ、消防隊で、人が消火するって言うのは、
原発の場合、場所によっては、危険じゃないのかなあ?
放射能もれの危険とか。。。

スプリンクラーの設置とか、
消防用のロボットとか、必要ですよね・・
消防用のロボットがあれば、あついところでも、だいじょーぶ!
やっぱり、ロボットを遠隔操作する形なのかなあ・・
そーすると、無線通信・・だと無理なのかなあ・・?




消火だけでなく、災害用ロボットも必要ですよね。
人が埋まっているのを助けるとか・・
遠隔操作で・・

なんか、建設用のロボットの応用のような気がするんだけど。。
そんな単純じゃない??

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

オブジェクト指向で開発の最初から最後までの手順例-その13:データルートまとめ

2007-07-20 18:00:06 | 開発ネタ

 オブジェクト指向でやる場合の最初から最後までの流れを、実際の例を挙げて書いていくシリーズ「オブジェクト指向で開発の最初から最後までの手順例」、今、ここの順番の 「(5-1-2)正規化理論を利用し、ER図にまとめる」で、前回までで、第三正規形まで行ったので、今回は、データ部分のまとめとプロセス部分のつなぎです。




■ER図のまとめとテーブル作成

 前回までで、エンティティはあげたので、それを、ER図の形にまとめて、いきます。エンティティは、このまえ、<< >>でかいたやつ、リレーションは、外部キーになっているものに対して貼られます。主キーのほうが1、外部キーになっているものは、Nが基本ですが、0を含むかとか、そーいうのは、データによって違うので考えてください。

 あとは、項目をいれると、できあがります。

 エンティティ1個がテーブル1個です(テーブルしか使わない場合。ファイルもありえる)正規化してしまった結果に対してやる場合はそうです。
(正規化する前だと、多対多がありえるのですが、正規化してしまったものを元にやる場合は、第一正規形でそれははじかれれます)

 厳密に言うと、エンティティとエンティティの対応「関係」を示した対応表はエンティティではなく、「関係」=リレーションなのですが、ま、いっか(^^;)

 ってことで、テーブルもかけそうですね。




■テーブルのCRUDは必要になる

 ここで、テーブルのデータの作成、読み込み、更新、削除の必要があります。で、とくに、読み込みを行う前に、データを作成しておく必要があります。
 そうしないと、読み込めませんから・・・

 また、親子関係があるモノ(発注企業と店舗など)の場合は、親を先に作る必要があります。

 ってことは、業務要件になくても、それらのデータは、どうにかして作成しないといけないということです。




■今回の場合

 今回の場合は、
・発注企業
   発注企業部署
   発注企業店舗
   納入先

・受注企業

・商品

・消費税

のデータは、発注業務にはなくても、入力編集画面をつくって、入力、編集、検索、削除できるようにしないといけないということです。

ちなみに、今回の場合あと、逆に発注と、発注明細の入力、編集、検索、削除できるようにして、それらをすべてWebAPIで提供してしまえば、あとは、クライアント側でMashUpしてくれると、もう、業務関係なく出来ちゃうんですけど・・




 とはいえ、それで話をおわりにしてしまうと、プロセスの話をぜんぜんしないことになってしまい、複雑なシステムの場合、問題なので、次回からは、「(5-2)プロセス解析ルート」のほうについて話したいと思います。



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

AJAXやJavaScriptにおける、「先読み」について(ゲームみたいなもん)

2007-07-20 11:54:42 | Weblog

たとえば、ある商品の仕入の可能性のあるお店全部を表示したいとする。
(仕入先はコードではなく、仕入先の名前で)
このお店の仕入先と商品は、ある程度限られているとしたとき、
どうするか・・・なんだけど・・

まあ、単純に考えると、このテーブルは、

商品テーブル、仕入先テーブル、商品仕入先テーブルとなっていて、
この条件を満たすには、

商品テーブルと仕入先テーブル、商品仕入先テーブルを内部結合して、
そのとき、商品テーブルの商品コードが指定番号のものの、
仕入先テーブル.仕入先名

を表示することになる。




 しかし、ここで結合が2テーブルではいる上、このような方法だと、
サーバー側は、クライアントで見たいモノのサービスを全て提供しない
といけないことになる。

 これじゃあ、AJAXをやる意味が無い。

 クライアント側で、簡単にマッシュアップできないか?




 と考えると、そもそも、仕入先テーブルは、他でも読む必要があるはずである。
 立ち上げ時に読んでしまってもいいかもしれない。

 商品テーブルも、たいてい、商品の仕入先をみる前にどっかで読んでいるものである。

 とすると、仕入先テーブルを読んだときに、

sire[仕入先コード][仕入先名] で、仕入先を受け取れるように、
 読み込ンだデータを保存しておいて
 (あるいは、そーいう.jsファイルを作って、そいつをインクルードする。仕入先が
  編集されるたび、.jsファイルも書き換える)

 さらに、その前に、商品マスタも読んでおけば、

 ここでやらなきゃいけないことは、商品仕入先テーブルを、指定された商品コード
 (商品名=>商品コードは、商品マスタを読み込んでいるのでわかる)で読んで
 くればいいだけ。

 そうすれば、その仕入先コードを受け取って、上記のsire[仕入先コード][仕入先名]
から、仕入先名が分かる。

 なお、もし、読み込み時の時間の関係で、データ矛盾(あるはずのデータが無く結合できない)が起きた場合は、ユーザーはリドローすれば、最新のでーたになる。




 このように、先読みしておけば、(更新の場合は排他が必要なので、いっぺんにやらないと無理だけど)各テーブルの検索APIを提供するだけですむ。

 問題は、どのように先読みさせるか(読み込みを散らすか)だけど、それは、画面上の設計に関わる(画面で、順番に読み込でいくようにする)

 その場合、テーブルはエンティティに関係が深いので、テーブルを順番に読むような画面設計にするということは、エンティティ=>オブジェクトベースでの画面設計ということになる(つまり、1業務1画面ではなく、1エンティティ1画面のようなかんじで設計し、ボタンなどのイベントが1業務になる)




 ゲームだと、先読みして画面を作るというのは、あたりまえだけど(ダブルバッファリングとか)AJAXでも、そうなるかもしれない。。。


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

kizasiにヤフーが出資

2007-07-20 08:40:12 | Weblog

以下のニュース
kizasiにヤフーが出資
http://headlines.yahoo.co.jp/hl?a=20070719-00000083-zdn_n-sci

によると(以下斜体は上記サイトより引用)


 ヤフーと、ブログから話題のキーワードを抽出するサイト「kizasi」を運営するきざしカンパニーは7月19日、業務・資本提携すると発表した。きざしカンパニーが7月25日付けで行う第三者割当増資をヤフーが引き受け、発行済み株式の5%を取得する。出資額は非公表。

 kizasi.jpをYahoo!JAPANの広告ネットワークに参加させるほか、有料サービス「ブログクチコミサーチ BY kizasi」のログインにYahoo!IDを、決済にYahoo!ウォレットを利用できるようにする、といった連携を検討する


なにかがおきそうな兆し(きざし)?


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

「コピー10回だからこそ、補償金制度が不可欠」――権利者団体が主張。。

2007-07-19 22:37:01 | Weblog

ここのニュース
「コピー10回だからこそ、補償金制度が不可欠」――権利者団体が主張
http://plusd.itmedia.co.jp/lifestyle/articles/0707/17/news065.html

によると(以下斜体は上記サイトより引用)


音楽や映像、実演に関する権利者団体で組織される「デジタル私的録画問題に関する権利者会議」(以下 権利者会議)は7月17日、都内で会見を開き「コピーワンスの回数制限緩和には私的録音録画補償金制度の維持が不可欠」との声明を発表した。


つーか、そのお話の前に、「私的録音録画補償金制度」とかいうやつで、集まったお金がアーチストまでどのように(公平に?)分配されているのかすら、よくわかっていないウィリアムのいたずらなのであった(^^;)



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

オブジェクト指向で開発の最初から最後までの手順例-その12:第三正規形

2007-07-19 16:31:58 | 開発ネタ

 オブジェクト指向でやる場合の最初から最後までの流れを、実際の例を挙げて書いていくシリーズ「オブジェクト指向で開発の最初から最後までの手順例」、今、ここの順番の 「(5-1-2)正規化理論を利用し、ER図にまとめる」で、前回までで、第二正規形まで行ったので、今回は、第三正規形です。




■第三正規形-主キー以外でも、従属性があるのをなくす

 第三正規形は、第二正規形までやってもまだ、関係がある項目があれば、はずします。

 どういう項目かというと・・

・エンティティはないけど、決まりごとがあって、そうなっている。
   ・法律みたいな決まりで、そうなっている
      例:郵便番号が決まると、都道府県名が決まる(たぶん)
   ・計算上もとまる
      例:金額=数量 X 単価
   ・会社の決まり(=これは、結構危険)
      部署と内線番号
     (部署1つに内線1つという決まりがあるとき)

ようなケースでおこります。




■第三正規形にしないほうがいいケース(正規化崩し)

 しかし、正規化を崩しておいたほうがいい場合もあります。

・たしかに求めることは可能だが、困難、あるいは面倒なもの

 進捗状況を表すステータスなどは、たしかに、前の工程が全部終わっているというのが分かればいらないという場合もありますが、前の皇帝が全部終わっているのを確認するのには明細を全部読んできて・・・なんていう、めんどっちい場合は、そのままのこしておきます。

 介護料金なども、実は論理的な計算式があるのですが、その計算式で求めず、点数のテーブルをもって、そこから引いてしまいます。

 
・いまは、そのきまりがあるが、将来わからないもの
 さきほどの部署と内線番号のように、将来変わる可能性があるモノは、変わったときにテーブル作り直すのもなんなので、そのままにしておきます。


・実は他の意味がある
  計算式などで、答えが入っていない場合、そこを空白にするなどという場合、計算結果の項目をそのままのこしておくこともあります(空白のケースのフラグを持つ場合もある。そのほうがきれい)




■こんかいは・・

消費税.税率
消費税.税区分

これは、税区分がきまると、消費税が決まります・・・

っていうと、「え、消費税って、5%だろう」と思う人がいると思うので、一応説明して置きますと、消費税がかかるものと、かからないものがあります。
 この消費税がかからないものについては、国外取引のような、そもそも、消費税の範囲ではないものがあります。これは、不課税で、課税売り上げに入りません。
 もうひとつは、非課税取引といわれるもので、土地の譲渡そのもの(手数料にはかかる。譲渡した何億円とかの土地の値段そのもの)には、消費税がかかりません。これが非課税。これは、課税売り上げに入ります。

 税金がかかるのは、内税と、外税がありますが、これは、どちらも5%、

 ここで、税率とは、かける値とすると、内税外税は、5%の税率を含み、非課税不課税は、0%(じゃほんとうはなくって。。。でもまあ、便宜上)っていうことになります。

で、消費税の税区分で、まあ、キーになるんだけど、そーすると、文字(非課税とか)になっていやなので、新しくこうもくをつくっちゃいました。

こんなかんじ

<<消費税>>
消費税種別番号
消費税.税率
消費税.税区分





それと、
「発注明細データ」の、
  「原価金額」は、「数量*原単価」、
  「売価金額」は、「数量*売単価」
でいいかなということで(伝票非表示の場合とかはあるけど、まあ、こんかいはいいかなということで、)この項目はカットとします。

そうすると、きのうのは、こんな感じのテーブルになります。


<<発注企業>>
発注企業.企業コード:主キー
発注企業.企業名漢字
発注企業.企業名カナ
発注企業の分類コード


<<受注企業>>
受注企業.企業コード:主キー
受注企業.企業漢字
受注企業.企業カナ



<<発注企業部署>>
発注企業.企業コード:主キー・外部キー
発注部署.課コード:主キー
発注部署.売場部署名漢字
発注部署.売場部署名カナ
発注部署.発注担当者カナ




<<発注企業店舗>>
発注企業.企業コード:主キー・外部キー
発注店舗.店舗コード:主キー
発注店舗.店舗名漢字
発注店舗.店舗名カナ



<<納入先>>
発注企業.企業コード:主キー・外部キー
納入先.納入先コード:主キー
納入先.納入先名漢字
納入先.納入先名カナ




<<発注>>
発注伝票番号:主キー
受注企業.企業コード:外部キー
発注企業.企業コード:外部キー
発注部署.課コード:外部キー
発注店舗.店舗コード:外部キー
納入先.納入先コード:外部キー
メッセージID
データ作成年月日
伝票作成年月日
伝票有効年月日
発注年月日
発注時間
発注管理番号
納品指定年月日
特価区分
企画コード
入力種別
伝票区分
納品区分
発注企業組織.伝票企画コード
受注企業組織.伝票企業コード
消費税種別番号:外部キー



<発注明細データ>>
発注伝票番号:主キー・外部キー
行番号:主キー
商品番号:外部キー
発注情報.数量
発注情報.単位数
発注情報.単位入数
発注情報.原単価
発注情報.売単価
特価区分
消費税種別番号:外部キー



<<商品>>
商品番号:主キー
商品.GTINコード
商品.代替商品コード
商品.商品名漢字
商品.商品名カナ
商品.原単価
商品.売単価



<<消費税>>
消費税種別番号
消費税.税率
消費税.税区分






ということで、第三正規形も終わりです。



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

FireFoxとIEの差、textとsrcElementに、はまる

2007-07-19 12:04:36 | JavaとWeb

いやー、また「フォクすけのいたずら」にはまってしまった。

(1)XMLをDomにいれて、テキストノード.textとやっても、IEだったら、
文字を返してくれるが、FireFoxでは返さない。
テキストノード.nodeValueにしないと。。
(IEでも、テキストノード.nodeValueはOK)


(2)イベント処理で、FireFoxには、srcElementがない。
 そこで、event.srcElement.valueのところは、event.target.valueと
 しないとだめなようだ。

 このとき、IEと、FireFoxの切り分けは、
自作プラグイン/cookie.inc.php
http://pukiwiki.sourceforge.jp/?%E8%87%AA%E4%BD%9C%E3%83%97%E3%83%A9%E3%82%B0%E3%82%A4%E3%83%B3%2Fcookie.inc.php

に書かれているように、document.allをつかって、
	if (document.all)
	{
		val = event.srcElement.value;
	}
	else
	{
		val = event.target.value;
	}

のようにすればいいみたい・・

こんなのに1時間も費やしてしまった。。うーん(>_<!)

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

フジテレビ「ゴールデンタイムの視聴率が悪いのはゲームのせい」

2007-07-18 20:58:39 | Weblog

そうなのかあ??
ここの痛いニュース
フジテレビ「ゴールデンタイムの視聴率が悪いのはゲームのせい」
http://blog.livedoor.jp/dqnplus/archives/1005298.html

によると(以下斜体は上記サイトより引用)

7月の第1週、日本のテレビ業界に大きな衝撃が走った。
なんと1週間の間に放送された番組の中で、ゴールデン・タイム
に視聴率9%を超えたものが1つもなかったのだという。


ひえー(@_@!)
やっぱ、今はテレ東の時代なんだよなあ・・と思ったら

フジテレビの専務取締役は「日本のテレビ視聴率は常に上下しやすいが、
このように著しい低下はあまり経験がない。
テレビそのものに問題があるというよりは、Wiiなどの外的な要素に左右されて
いる可能性が高い」と話す。


いや、そーじゃないでしょー。
単にテレビが面白くないから(というか、フジテレビなどが面白い番組をしないから)でしょう。。

テレ東のほうがおもしろいし。。

幽遊白書でも流したほうが、ドラマやるより、視聴率取れるんじゃないか?

そのうち、テレ東深夜番組の「もやもやさまーず」(街歩いて、がちゃがちゃやって、お金を使う”だけ”の番組)にゴールデンが負けたりして(^^;)

高校講座に負けたら。。。いや、負けるかもしれないよ(^^;)


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

AJAXで操作するとして、サーバー側に必要な最低限のAPIは?

2007-07-18 18:37:37 | Weblog

 エンティティに対するC(作成)R(読み込み)U(更新)D(削除)。

 ただし、これらを、クライアントからやることを禁止しているのであれば、その機能はなくても良いが、手作業もふくめ、これらは、どこかでやる必要がある。

 逆にこれらのがAPIがすべて、クライアント側でAJAXで操作できれば、面倒くささは別として、全部のエンティティの操作はできる。。

 が、そうなると、今度は矛盾した操作をされることがありえる(受注明細はあるのに、対応する受注がないなど)ので、そういう操作が出来ないために隠蔽する必要がある。このため、すべての機能を提供するとは限らない(これが上で言う、「クライアントからやることを禁止している」操作のひとつになる。このほかに権限的に禁止するものなどある)

 さらに利便性などを考えると、複雑な操作をするAPIも付け足したほうがいいということになる。

ってことを、ちょっと思いついたので、メモメモ。


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

オブジェクト指向で開発の最初から最後までの手順例-その11:第二正規形。

2007-07-18 16:19:03 | Weblog

 オブジェクト指向でやる場合の最初から最後までの流れを、実際の例を挙げて書いていくシリーズ「オブジェクト指向で開発の最初から最後までの手順例」、今回は、ここの順番から言うと「(5-1-2)正規化理論を利用し、ER図にまとめる」で、前回、第一正規形を行ったので、今回は、第二正規形です。




■第二正規形-主キーをきめる

 第二正規形は、主キーを決めます。

 このとき、エンティティをあらかじめ決めておいて、そこに当てはめる「トップダウン的手法」と、データを総当りで見て、ある項目がきまると、自動的にきまる項目を見つける「ボトムアップ的手法」が考えられます。
 ボトムアップにおいては、第三正規形の項目までも、ここで分解してしまい、っていうか、そもそも、全部のデータで考えるのはたいへんなので、エンティティを基に考ええる、トップダウンの手法をとります。




■エンティティをきめる

 まず、第一正規形が前提になります。
 つまり、

・発注
・発注明細

に分かれることは確かです。

 また、このほかのエンティティとして

・発注企業
  ・発注企業の部署
  ・発注企業の店舗
  ・発注企業の納品先

・受注企業

・商品

があります(実体をもって、存在します。部署のような抽象概念もありますが・・)

 なお、発注部署と店舗の関係ははっきりしませんけど、まあ、別物と考えましょう。納品先も、数社で同じ倉庫を利用することもありますけど、まあ、店舗に従属する(発注企業が違えば同じ倉庫でも違う納品先として登録する)ことにしましょう(じゃないとめんどっちい)





■データの振り分け

 で、その場合、親子関係があったり、関係がある場合、相手のテーブルに、こちらのテーブルの主キーを入れます(相手のテーブルから見ると、外部キーになる)
  親、あるいは、1対多の場合、1しかないほうが主キー、
  子、多のほうが外部キー

となります。 

 なお、主キーがないときは、勝手に主キー項目を作ります。
 商品番号のように。。




■そうやってわけると・・・

こんなかんじかな(内容良く分かってないで振っているので、まちがいがあるかも)。

<<発注企業>>
発注企業.企業コード:主キー
発注企業.企業名漢字
発注企業.企業名カナ
発注企業の分類コード


<<受注企業>>
受注企業.企業コード:主キー
受注企業.企業漢字
受注企業.企業カナ


<<発注企業部署>>
発注企業.企業コード:主キー・外部キー
発注部署.課コード:主キー
発注部署.売場部署名漢字
発注部署.売場部署名カナ
発注部署.発注担当者カナ


<<発注企業店舗>>
発注企業.企業コード:主キー・外部キー
発注店舗.店舗コード:主キー
発注店舗.店舗名漢字
発注店舗.店舗名カナ


<<納入先>>
発注企業.企業コード:主キー・外部キー
納入先.納入先コード:主キー
納入先.納入先名漢字
納入先.納入先名カナ


<<発注>>
発注伝票番号:主キー
受注企業.企業コード:外部キー
発注企業.企業コード:外部キー
発注部署.課コード:外部キー
発注店舗.店舗コード:外部キー
納入先.納入先コード:外部キー
メッセージID
データ作成年月日
伝票作成年月日
伝票有効年月日
発注年月日
発注時間
発注管理番号
納品指定年月日
特価区分
企画コード
入力種別
伝票区分
納品区分
発注企業組織.伝票企画コード
受注企業組織.伝票企業コード
消費税.税率
消費税.税区分



<発注明細データ>>
発注伝票番号:主キー・外部キー
行番号:主キー
商品番号:外部キー
発注情報.数量
発注情報.単位数
発注情報.単位入数
発注情報.原単価
発注情報.原価金額
発注情報.売単価
発注情報.売価金額
特価区分
消費税.税率
消費税.税区分


<<商品>>
商品番号:主キー
商品.GTINコード
商品.代替商品コード
商品.商品名漢字
商品.商品名カナ
商品.原単価
商品.売単価





■2つのテーブルに入るケース

 基本的に1事実1箇所ですから、2つのテーブルに入るわけはないのですが、たとえば、商品の原単価のように、2つの意味がある場合があります。
 商品テーブルに入る単価は、現在の価格、発注テーブルに入る単価は、そのとき売った価格です。だから、値上げされたりした場合、現在の商品の価格と、売ったときの価格は違う(実際には1事実ではなく、2つの値)ので、2箇所に値が入るようになります。




■納品先のようなケース

 発注伝票に納品先コードをいれ、納品先のテーブルを持つと、すべての発注先は、納品先テーブルにいれないといけません。
 こうなると、たとえば、「何とか催事場何とかフェア会場」みたいな、1回しか使わないものも納品先テーブルにいれないといけないことになるけど・・
 ま、いっか(^^;)

 ちなみに、全部納品先に入れない場合は、発注のほうにも、
納入先.納入先コード
納入先.納入先名漢字
納入先.納入先名カナ
 をもっておいて、上記のようなテンポラリの場合は、納品先コードを空にして、発注データに、納品先名を直接入力することになります。




■主キーは一意にならないとまずい=NULLは?
 主キーNULLが複数できるとこまります。
 商品で、GTINコードを主キーにせず、商品番号という主キーをだしたのは、GTINがない商品があった場合、ここがNULLの商品が複数できるからです。




■ボトムアップとの違い
 ボトムアップの場合は、消費税区分も、この段階ではじかれます。
 エンティティ的には、消費税・・・うーむ・・・

 となってしまうのですが、第三正規形で、これは別テーブルにします。




ということで、次回は第三正規形です。




  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

開発の初めから順番に書いていってみる その69:プログラミング(31)入出力の自動生成19

2007-07-18 14:32:00 | 開発ネタ

 シリーズ「開発の初めから順番に書いていってみる」の続きです。

 設計手順には、要求分析、外部設計、内部詳細設計・プログラミング、単体テスト、結合テスト、総合テスト、運用テスト及び運用とあります。
 現在プログラミングで、画面の自動生成のイベントリスナー部分をやっています(バックナンバーは、ここ http://www.geocities.jp/xmldtp/index_kaihatsu.htm)

 前回、つくるソース(イベント部分)について、書きました。

 が、イベント部分、動くソースの形でまとまっていなかったのと、今回の複数コンポーネント対応で、画面のほうのソースも変更になっているので、それらのソースをまとめて載せて置きます。

 起動するクラス、testクラスのソースは、ここ
 画面クラス、gamen1クラスのソースは、ここ
 昨日説明した、イベントクラス、gamen1_HandleEventクラス はここ
 処理クラス、Shoriクラスは、ここ

で、今日はイベントの仕様書に入ります。




■イベントの仕様書

 イベントにおいて書いてもらわなければならないのは、

 イベントごとに、
  どの部品のどのイベントが起きたら、どんな処理をするのか?

 1画面に対して、
  画面名など=>ここから、イベント名のクラスを作る

 となります。なので、以下のような形です。


 実際には、このように、1シートにまとめてもいいし、
 画面の下に、この部分の記述を書いて、自動生成時に、別シートに(1シートに)してもいいです。




■で、そうすると、Adapterは・・

 しかし、そうすると、イベントに対応するアダプターの内部クラスを作らないといけません。そして、そのアダプターの一覧も必要になるはずです・・

 こんなかんじ



 でも、ヨーク考えると、アダプタはいっぱいありますけど、使うのは、ボタンとキーとマウスと・・・と、数えるほどしかなく、まあ、これらを全部書いておいても、使わないだけだから・・・いっか(^^;)

 ということで、アダプタは、使いそうなやつをあらかじめ全部書いておくことにします。
(アダプタを書いても、イベントを取得して何もやらなければ=仕様書になんか処理をすると書かなければ)なにもしないで抜けるだけです)。




 ということで、仕様書も、これでいいっていうことにします。



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

「顔ちぇき!」のジェイマジック、携帯画像を使った情報検索機能をAPI化

2007-07-17 21:17:26 | Weblog

すげー!!おもしろそー!!
ここのニュース
「顔ちぇき!」のジェイマジック、携帯画像を使った情報検索機能をAPI化──「SAYL」を発表
http://headlines.yahoo.co.jp/hl?a=20070717-00000001-zdn_m-mobi

によると、(以下斜体は、上記サイトより引用)

 ジェイマジックは7月12日、同社のモバイルソーシャルメディア「eyenowa」などで提供している、携帯カメラ画像を使った情報検索機能をAPI化し、「SAYL」として提供することを発表した。


つまり、今回提供されるAPIは、

画像を使って情報検索するためのAPI。


で、そのSAYLのサイトは
ここ http://www.j-magic.co.jp/02_solution/sayl.html
をみると、APIが公開されていて、みんなが今すぐ使えるという感じ
ではなくって、

そーいうAPIがあるよ!っていうお話みたい。。。



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

IEでJavascriptのエラーを出す

2007-07-17 20:33:16 | JavaとWeb

メモメモ。
IEを普通に使ってると、多分Javascriptのエラーは出ないと思う。

で、それを出す場合、
(1)ツールのインターネットオプションを選択
(2)「インターネットオプション」ダイアログで、「詳細設定」タグを選択
(3)「ブラウズ」のところを、以下のようにチェックをはずしたり、
   入れたりする


こんなかんじで、うちの環境では出来ました。

ちなみに、エラーがでるとき、2種類ありました。

メッセージボックスが出るだけのものと、
「詳細」というボタンがあって、そこをクリックすると、いろんな情報が出てくるもの。

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

JSPで../で指定するとうまくいくのに、サーブレットでフォワードすると失敗

2007-07-17 17:57:57 | Weblog

今はまったやつ。

JSP(中身はJavascriptで書かれている部分がある)のプログラムで、あるjsファイルをSCRIPTで読ませようとしたとき、

<SCRIPT type="text/javascript" src="../abc.js">

でうまくいったのに、そのプログラムを、サーブレットからフォワードしたとたんに、そのabc.jsに書かれている関数を読まなくなった。。。

 はまりました。。




 理由は、サーブレットのベースがfooだとすると、サーブレットをフォワードした時点で、/foo/servlet/そのプログラム が基準となってしまう。

 jspはjspでまとめていると、
フォワードするときに/foo/jsp/xyz.jspと送って、
それが表示できたとしても、
ベースは、/foo/servlet/なので、
../abc.jsっていうと、
とんでもないところを見に行ってしまう。




 この場合、以下のように

<SCRIPT type="text/javascript" src="/foo/jsp/abc.js">

 みたいなかんじで、トップから..を使わずに指定したら、なおりました。

うーん・・・奥が深い
(上記< > は本当はすべて半角です)


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

開発の初めから順番に書いていってみる その68:プログラミング(30)入出力の自動生成18。

2007-07-17 13:36:27 | Weblog

 シリーズ「開発の初めから順番に書いていってみる」の続きです。

 設計手順には、要求分析、外部設計、内部詳細設計・プログラミング、単体テスト、結合テスト、総合テスト、運用テスト及び運用とあります。
 現在プログラミングで、画面の自動生成のイベントリスナー部分をやっています(前回までについては、ここ http://www.geocities.jp/xmldtp/index_kaihatsu.htm

 で、今回は仕様書の予定だったのですが、
 作ってみて気づいた・・・

 これ、ボタン以外のイベントをとるとき、だめじゃん(>_<!)
 イベント処理のところ、アダプタを、extendsで継承してやってるけど、extendsは1つしか継承できない(javaは多重継承できない)。

 ということで、今回はやり直し。
 複数種類(テキストとかボタンとか)のコンポーネントでも扱えるイベントリスナー部分の方向性を示します。




■やりかた

 そーなってくると、

●(1)イベント用クラスをつくる(gamen1_HandleEvent )
  →こいつは継承しない

●(2)その中に、インナークラスをつくり、そのインナークラスが
   アダプタを継承する。

public class gamen1_HandleEvent 
{
	public class Select extends SelectionAdapter
	{

	}

	public class Key extends KeyAdapter
	{

	}
		:
		(アダプター分つづく)
}



●(3)そいつに実体をもたせるため、コンストラクタの中で、
   生成する。
public class gamen1_HandleEvent 
{
	public Select sl = null;
	public Key    key = null;
	gamen1	g = null;

	/*
	 * 	画面つきコンストラクタ
	 */
	public	gamen1_HandleEvent(gamen1 g)
	{
		this.g	=	g;
		this.sl =	new Select();
		this.key =	new Key();
		:
		(アダプター分つづく)
	}

	public class Select extends SelectionAdapter
	{
		/*
		 * 	ボタンが押されたときの処理
		 */
		public void widgetSelected(SelectionEvent e) 
		{
			Object o = e.getSource();
			shoriPro("widgetSelected",e.getSource());
		}
	}

	public class Key extends KeyAdapter
	{
		/*
		 * 	ボタンが押されたときの処理
		 */
		public void keyPressed(KeyEvent e) 
		{
			Object o = e.getSource();
			shoriPro("keyPressed",e.getSource());
		}
		public void keyReleased(KeyEvent e) 
		{
			Object o = e.getSource();
			shoriPro("keyReleased",e.getSource());
		}
		public void keyTyped(KeyEvent e) 
		{
			Object o = e.getSource();
			shoriPro("keyTyped",e.getSource());
		}
	}
		:
		(アダプター分つづく)
}



●(4)生成後、画面のイベントを取るときは、いままで、このクラスをaddなんとかListener(addSelectionListener等)していたけど、このインナークラスを、addするようにする

例:
b1.addSelectionListener(al.sl);

●(5)すべての処理が、shoriProにあつまり、そこに仕様書のものが
   書かれるのはおなじ。

まとめると
public class gamen1_HandleEvent 
{
	public Select sl = null;
	public Key    key = null;
	gamen1	g = null;

	/*
	 * 	画面つきコンストラクタ
	 */
	public	gamen1_HandleEvent(gamen1 g)
	{
		this.g	=	g;
		this.sl =	new Select();
		this.key =	new Key();
		:
		(アダプター分つづく)
	}

	public class Select extends SelectionAdapter
	{
		/*
		 * 	ボタンが押されたときの処理
		 */
		public void widgetSelected(SelectionEvent e) 
		{
			Object o = e.getSource();
			shoriPro("widgetSelected",e.getSource());
		}
	}

	public class Key extends KeyAdapter
	{
		/*
		 * 	ボタンが押されたときの処理
		 */
		public void keyPressed(KeyEvent e) 
		{
			Object o = e.getSource();
			shoriPro("keyPressed",e.getSource());
		}
		public void keyReleased(KeyEvent e) 
		{
			Object o = e.getSource();
			shoriPro("keyReleased",e.getSource());
		}
		public void keyTyped(KeyEvent e) 
		{
			Object o = e.getSource();
			shoriPro("keyTyped",e.getSource());
		}
	}
		:
		(アダプター分つづく)
	/*
	 * 	すべての処理
	 */
	public void shoriPro(String eventCode,Object o) 
	{
		//  まだ、画面がセットされていなかったら、抜ける
		if ( g	==	null )
		{
			return;
		}

		//	仕様書に書いた条件分、ならぶ
		if ((eventCode.equals("widgetSelected") == true) &&	
			( o.equals(g.b1)== true) )
		{
			//	ここで処理呼び出し
			//	g.shori.shori1(g);
			return;
		}
			:
			(処理分、つづく)
	}
}






ってなかんじですかね・・・




  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする