”「Microsoft Firefox 2007」公式サイト登場”って、一瞬、マジかと思ったよ！

　ギャグですよ、あせったー。いや、マジかと思いましたよ、ＧＩＧＡＺＩＮＥの記事、
表題だけ見たとき。。。

ここの記事
「Microsoft Firefox 2007」公式サイト登場
http://gigazine.net/index.php?/news/comments/20070203_microsoft_firefox2007/

で、そのジョークサイトは、
ここ　http://msfirefox.com/

うーん、よくできてる。。。

でも、マイクロソフトなら、やりかねない（－＿－）
（なこたーねーって　＾＾；）


Ｐ．Ｓ　再度、念のために書いておきます。
　うそですよ！そーいうよくできた、ジョークサイトがあるっていう話ですよ！

アメリカで肥満対策に、コナミのダンス・ダンス・レボリューションを公立校に導入決定

ここの痛いニュース
アメリカでデブ対策としてダンス・ダンス・レボリューションを公立校に導入決定
http://blog.livedoor.jp/dqnplus/archives/912538.html
（元ねたはここ）によると（以下斜体は上記ニュースより引用）


米国最悪の児童肥満問題を抱えるウェストバージニア州が、コナミの「ダンス・ダンス・レボリューション」を使って学校で肥満と戦う計画を強化している。同州はこの人気ゲームを公立学校に1校残らず導入する計画で、1月31日、これが体重増加を食い止める一助になることが調査で示されたと説明した。

そうな。。。

これ、コナミ大もうけだよね。。。

でも、本当にやせるのかなあ（＾＾；）
実験によると

7歳から12歳の太り過ぎまたは肥満の児童50人を24週間にわたって調査した結果、自宅で1週間に5日、少なくとも30分ずつこのゲームをした子供は体重が増えないことが速報値で示され、心臓病や糖尿病のリスク要因も低下が見られた。

　グループ分けしたうちの12人については最初の12週間はゲームをさせず、その後残りの調査期間でゲームをさせた。このグループは調査の前半で平均約2.7キロ体重が増えたが、後半は体重が安定した。

だそうなんだけど。。。

プロセスのカスタマイズとしての委譲・継承とジョブチケット

　で、さっき書いたブログの最後の部分


　おー、これは、ある程度の標準化として、前のＸＭＬ－ＥＤＩよりかは、プロセスも標準化されているので、つかえそうっすね。
　これを、クラス化してしまって、Javaかなにかにしてしまって、業務手順が違う場合は。。

　。。。説明が長くなりそうなので、別の機会にします（＾＾）


　とかいたけど、それについて。

---

　標準的なプロセスがきまると、自社のプロセスと違う（けど似ている）という場合は、
カスタマイズという形になる。

　Javaの場合であれば、もとのクラスから継承して、自分の会社の部分用にカスタマイズするっていうことも考えられる（共通部分はsuperをよぶという感じで）。

　でも、実際には、ソースがあるのなら、そういう継承はできるけど、そーじゃない場合はできないので、委譲ということになる。つまり、自分の会社のプロセス（メソッド）をよびだして、その中で、標準的なプロセスを呼び出し、処理結果を受け取って、返すっていうかたち。

　これなら、Ｊａｖａでやるばあい、標準的なものがＳＯＡで提供されていれば、そのクラスからＳＯＡを呼び出すこともできるし、バッチなり、コマンドラインからのプログラムで提供されていれば、Javaからバッチプログラムなり、コマンドなりをRuntime.getRuntime().exec();で呼び出し、その結果をファイルなりＤＢなりにいれてもらって、それで受け取ればいい。

---

　でも、順番が違うとか、順番を省略するって言う場合がある。
　こういうときは、むしろ、プロセスを細かくくぎって、どのプロセスを動くかをファイルで指定する。

　たとえば、受注のとき
　　受注データ書き出し
　　受注伝票出力
　　在庫引き当て
　　在庫引き当てが全部できるとき
　　　　ピッキングリスト作成

　までを受注ということで、やってしまうとする。

　このとき、これを１メソッドでつくってしまうと、いろいろ汎用的にカスタマイズできない。人によっては、受注のときはデータ書き出しだけする（ペーパーレスなので）とか、在庫は引き当てられない。受注してから製造するので。。など、いろんなお店があるから。。。

　で、こういうケースではどーするかというと、
　ある程度適当な小さな単位
　　・受注データ書き出し
　　・受注伝票出力
　　・在庫引き当て
　　・ピッキングリスト作成
　というかんじにわけて、どのプロセスを今回はうごかすべきかは、ファイルに記述する。
　コントローラーをつくって、コントローラーはそのファイルをみて、処理をするというかんじ。

　こうすれば、モノによってとか、状況によって、やる処理が変わるなんていうケースでもファイルを書き換えればいいだけだから、簡単だよね。

---

　もちろん。ＪＡＶＡでもコントローラーという概念はあるけど、プログラムにコントロールを記述してしまうこの方法では、開発当時予期しなかった処理には対応できない。こちらは、ファイル書き換えだけなので、より柔軟にできる。

---

　で、ＤＴＰの世界だと、これが、ジョブチケットっていうやつだと思った。

　なんで、流通業でもいろいろあるとおもうけど、適度な粒度のプロセスになっていれば、そのプロセスのカスタマイズと、手順をファイル（ＤＢもアリ）で記述し、それに基づいてコントローラーが起動するようにすれば、結構面白いことになると思う。

　もちろんこのとき、適度な粒度のプロセスというのは、Ｊａｖａのクラスとして提供する必要は「なく」、ＳＯＡで良いわけで、まあ、それをコントローラー側で、ファイルにより柔軟に組み合わせるっていうカタチになると面白さ倍増なんだろうね。

流通業の業務プロセス、データ項目の標準が４月に発表？

日経コンピューター２００７年２月５日号（特集　ビジネスを止められないシステム）の
２４ページ（ニュース＆トレンド）

受発注にかかる時間を１０分１以下に
流通業３１社がＥＤＩの業務プロセス標準を実証へ


この記事は、次世代ＥＤＩの実証実験を、イオン、ダイエー、菱食、国分、などで行うという話。
菱食、国分とくるから、これで巧くいけば、大きな流れになる可能性もあるかも。。。

が、そんなことはさておき、問題は３段目（一番右側）の下のほう
（以下斜体は上記サイトより引用）

実験結果を反映した業務プロセスやデータ項目は、「次世代標準ＥＤＩメッセージVersion1.0」として４月にも公開する

そうな。。。

　おー、これは、ある程度の標準化として、前のＸＭＬ－ＥＤＩよりかは、プロセスも標準化されているので、つかえそうっすね。
　これを、クラス化してしまって、Javaかなにかにしてしまって、業務手順が違う場合は。。

　。。。説明が長くなりそうなので、別の機会にします（＾＾）