高出力電子タグシステムの一部が心臓ペースメーカーに影響

スラッシュドットの以下の記事
高出力電子タグシステムの一部が心臓ペースメーカーに影響
http://slashdot.jp/hardware/07/04/26/0431232.shtml
によると（以下上記サイトの記事を、４月２６日１８：２８分現在、”原文のまま”引用－もう直ってるかも　＾＾；）


総務省は、電子タグシステムのうち高出力型の一部機種が心臓ペースメーカーに影響することが分かったと発表したという。影響が確認されたのは利用届出が必要なUHF帯(950GHz)を使う据え置き型の電子タグシステムで、現在倉庫などで約200システムが使われているという。


あ、そーっかあ、確かに電子タグ、ペースメーカーだと危ないかも。。
って、そこがポイントなんだろうけど、
ウィリアムのいたずら、違うところに目が行ってしまった。。（＾＾；）

(950GHz)

って、９５０”ぎが”ヘルツっすがあ（＠＿＠！）
そんな高い周波数、使ってるんですかあ？？
そこって、赤外線とか光じゃなかったっけ？？

と思って、元ネタ
電子タグ：ペースメーカーに一部機種が悪影響
http://www.mainichi-msn.co.jp/science/medical/news/20070425k0000m040097000c.html

みたら、やっぱ、メガヘルツでした（＾＾；）

でも、これって、わざと。。強烈な皮肉？？
つまり、光を発光するとか、反射するタイプのタグ（＝って、それってバーコードだけど）っていうものを考えたら、心臓のペースメーカーにも影響ないのに。。って。。
洋服なんかの場合、電子タグより今までどおり、バーコードのほうが安全？？

ただ、９５０GHzっていったら、いわゆるテラヘルツ波なわけで、たしかにテラヘルツ波のバーコード応用って。。うーん、高そうだぞ（＾＾；）

開発の初めから順番に書いていってみる その３６：詳細設計（３）詳細設計書

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

　設計手順には、要求分析、外部設計、内部詳細設計・プログラミング、単体テスト、結合テスト、総合テスト、運用テスト及び運用とあります。
　前回までで、要求分析と、外部設計がおわりました

　外部設計までは、
　ここ http://www.geocities.jp/xmldtp/index_kaihatsu.htm
　にまとめてあります。

　現在から、内部詳細設計で、前回は成果物を説明しました。今回はそのうち、詳細設計書です。

---

■詳細設計書の構成

　詳細設計書の構成は、

　　１．外部設計書との関係を示す表紙の部分
　　２．ひたすらプログラム内部を書く

　にわかれます。
　１の部分は、JavaDocの内容と同じで、そのプログラム名と、関数、クラス、メソッドの書式、概要説明が入ります。

　２の部分は、処理内容をことばで書きます。
こんなかんじ

１．トランザクションファイルから１件データを読んでくる
２．マスターファイルから１件データを読んでくる
３．トランザクションファイルのデータがなくなるまで、以下の処理を繰り返す

３－１．トランザクションファイルのキー＞マスターファイルのキーのとき
３－１－１．マスターファイルのレコードを出力する
３－１－２．マスターファイルからレコードを１件読む
３－１－３．３へ戻る

３－２．トランザクションファイルのキー＝マスターファイルのキーのとき
３－２－１．トランザクションのレコードを出力する
３－２－２．マスターファイルからレコードを１件読む
３－２－３．トランザクションのレコードを１件読む
３－２－４．３へ戻る

３－３．トランザクションファイルのキー＜マスターファイルのキーのとき
３－３－１．トランザクションファイルのレコードを出力する
３－３－２．トランザクションのレコードを１件読む
３－３－３．３へ戻る

４．マスターファイルのレコードが残っていたら、全部出力する

５．トランザクション、マスタクローズ

　で、そーでない場合、決定表による書き方というのがあります。

---

■決定表による書き方

　ここにあるようなやつです。

http://club.pep.ne.jp/~yama.ok/FE/H14AutamnFEAM/H14A_q14.htm

　上に条件が書いてあって、下にアクションが書いてあって、それが表になっているもの。

　で、これ、プログラムの仕方によっては、えらい汚くなり、バグの宝庫になってしまいます。逆にきれいに組むと、すっごい拡張性が高くなります。

　ジョブチケットっぽく組むといいんですけどね。
　これについては、また今度、別の機会に書きます。

---

■インターフェース記述とサンプルソース

　で、中の部分はあんまり必要ないんだけど、表紙のJavaDocのようなものは、そのソースを使う人以外でも必要です。
　そこで、Javaでない場合でも、インターフェース記述（関数定義書）として、イロイロ書きます。

　で、それだけなら外部設計の話なのですが、実際には、それだけでは、うまくくんでくれません。
　サンプルコードが必要になってきます。
　そこで、詳細設計の２のところのかわりに、
　呼び出し方やサンプルコードをつけたものを、インターフェース記述として、公開することがあります。

---

　てなかんじの話で、次回は残りのコーディング規約について。

Web2.0というバズワードが問題なのではなく、WebAPIで提供する中身が重要。。

えー、まとめますと、

「Web2.0というバズワードが問題なのではなく、
　WebAPIで提供する中身が重要である。

　WebAPIで提供するサービスがゴミだったら、
　それを集めて、いくらマッシュアップしても、
　ゴミにしかならない（GIGO）」

ってことですかね。。
（ある人から聞いた話をまとめてみた。。）