「コメントスパム対策として、ニセのコメントフォームを設置する」だって！

ここのGIGAZINEの記事
コメントスパム対策として、ニセのコメントフォームを設置する
http://gigazine.net/index.php?/news/comments/20070217_fake_comment_forms/

に興味ぶかい話が。。。

こんなはなし（以下斜体は上記記事より引用）

いわゆるネガティブキャプチャ（Negative Captcha）というもので、全自動でフォーム入力を行うボットが引っかかりそうなニセのフォームを設置し、そこに入力がある場合にはスパムと判断し、弾いてしまおうというアイディアです。

自動ではない手動スパムだと効果がないのですが、相手が日本人でない場合にはさらにもう一段階、罠を仕掛けることが可能です。


で、具体的な方法を書いたサイトを、GIGAZINEではリンクしているんだけど、
そのうちの１つの例がこんなかんじ


おとり用のフォームを設置して、CSSで「visibility: hidden」というようにして非表示にすれば人間が投稿する際には見えないので間違うこともない


ほー。。。いろいろ考えますな（＾＾）

Vista売れず、販売数がXPを大幅に下回る…発売後一週間集計

ここの痛いニュース
Vista売れず、販売数がXPを大幅に下回る…発売後一週間集計
http://blog.livedoor.jp/dqnplus/archives/923416.html
（元ねたは、ここ）によると（以下斜体は上記サイトより引用）


小売店におけるパッケージ版「Windows Vista」の発売後1週間の売上数が、「Windows XP」の時を大幅に下回ることがNPDの集計から明らかになった。

市場調査会社NPDのデータによると、発売後1週間を見た場合、VistaはXPより売上本数が約59％少なかったという。売り上げも減少したが、その差は売上本数ほどではなく、Vista発売後1週間の売り上げはXPの時と比べて32％減にとどまっている。


やっぱ、売れないよね（＾＾；）
ウィリアムのいたずらも、買わないもん
（このパソコン、たしか、メモリが２５６Ｍなのよ・・なんで。。）

きっこさんが”悪口を書いたやつは順番に賠償請求してやる”だって！

ここの痛いニュース
きっこが「２ちゃんねる等であたしの悪口を書いたやつは順番に賠償請求してやる」と宣言
http://blog.livedoor.jp/dqnplus/archives/923263.html

（Ｗｅｂ魚拓はこちらの下のほう）によると
（以下斜体は上記痛いニュースより引用）、

きっこさん、


今月から、インターネットにおける個人情報開示の法律が変わったので、
匿名掲示板などで、あたしのことを誹謗中傷してる人などに対しても、
ソッコーで情報開示を要求して告訴できることになったのですが、
そこまでやってるヒマもないので、しばらくの間は、嫌がらせのメールを送って来た相手だけ、
法的措置を取らせていただきます。


だって。。。


すべてこの日記で晒して行きますので、
皆さん、楽しみにしていてくださいね♪

そんな感じなんで、よろしくです♪

って、ことらしいです。。
（念のために言っておくと、上記の「この日記」とは、「きっこの日記」をさします。）

どーいう展開になるのか、きょうみしんしん。。。

Hello World程度のデータベース（その７：概念スキーマ（５）第一正規形の多対多） 。

　情報処理とは何から、データベースの基本的な話(情報処理試験のデータベーススペシャリスト程度の話まで）を書く、土日のシリーズ「Hello World程度のデータベース」です。

　前回は６回目ということで、第一正規形でした。
　まず、データを１箇所にだけ現れるようにする手法が正規化で、正規化のレベルとして、第一正規形から第五正規形まであります。でも、普通ＤＢを作るには第一～第三正規形まででよく、それは、以下のとおりです。

第一正規形：繰り返しをなくす
第二正規形：エンティティごとにまとめ、主キーを決め、
　　　主キーが変わると、他の属性地の値がきまるようにする
　　　　→これを主キーに対して完全関数従属といいます
第三正規形：主キー以外で、ある値が決まると、他の値が決まってしまう
　　　ところがあればそいつを分離する
　　　　→これによってできる状態を推移的関数従属性がないといいます。

で、前回は第一正規形の繰り返しについて考えました。今回はその話のつづきです。

---

■１対多と多対多

　前回の話は、こんな例でした。

　総務部には、安倍さん、麻生さん、柳沢さんといたとします。

　そして、この会社では、２つ以上の部に所属になる（＝兼任する）社員はいないものとします。


この場合、１つの部署に対して、複数（多数）の社員がいます
でも、社員から見ると、１人１部署です。
このような状態を、１対多といいます。

で、今日は、兼任する社員がいると考えましょう。
具体的に、こんな感じにしましょう。

・この会社は、総務部、営業部とあります（ほかもあるかもしれないが、おいておく）。 ・総務部には、安倍さん、麻生さん、柳沢さんといたとします。 ・営業部には麻生さんがいます（兼任です） ・社員の評価はこんなかんじ 　　　　　　　安倍さん　△ 　　　　　　　麻生さん　◎ 　　　　　　　柳沢さん　Ｘ

この場合、１つの部署に対して、複数（多数）の社員がいます
社員から見ると、１人の社員に対して、複数（多数）の部署がありえます（兼任時）。
このような状態を、多対多といいます。

---

■多対多は、そのままテーブルにできない

　前回の１対多のときのように、部署テーブルと、社員テーブルに分けてしまうと、以下のようになってしまいます

●部署テーブル

部署Ｎｏ	部署名
1	総務部
2	営業部

●社員テーブル

部署Ｎｏ	社員NO	社員名	秋葉原での人気
1	1	安倍さん	△
1	2	麻生さん	◎
1	3	柳沢さん	Ｘ
2	2	麻生さん	◎

　ここで、こまったことに、部署テーブルで、麻生さんのレコードが２つでてきてしまい、秋葉原の評価が、同じ内容（◎）なのに２箇所にでてきてしまいました（＞＿＜！）
　正規形は、１事実１箇所書くっていう考えなので、同じ内容を２箇所にかいてはいけません。どーしましょう。

---

■多対多の場合は、対応テーブルを作る

　このような多対多のときは、キーだけを抜き出した、対応テーブルというのをつくります。
　こんなかんじ

●部署・社員テーブル

部署Ｎｏ	社員Ｎｏ
1	1
1	2
1	3
2	2

そうすると、部署テーブルは、以下のように同じなのですが
●部署テーブル

部署Ｎｏ	部署名
1	総務部
2	営業部

社員テーブルは、麻生さんをくりかえさなくても、兼任している情報は、
部署・社員テーブルに入っている（２レコードと４レコードに）ので、
ここでは、社員の情報だけを入れればいいことになります。
こんなかんじ。
●社員テーブル

社員NO	社員名	秋葉原での人気
1	安倍さん	△
2	麻生さん	◎
3	柳沢さん	Ｘ

---

　こんなように、多対多の場合は、対応テーブルというのを作ります。
　で、繰り返しをなくします。
　ということで、次回は、第二正規形に入ります。

ひろゆき氏が違法ダウンロードに意見

ここのアメーバニュース
2ちゃん管理人ひろゆき氏が違法ダウンロードに意見
http://news.ameba.jp/2007/02/3418.php
（元ねたはここ）に、ひろゆき氏が違法ダウンロードに対しての意見が載っている。

それによると。。（以下斜体は上記アメーバニュースより引用）


それは、富める者から盗みを働き、庶民に盗んだものをばらまく「義賊」である石川五右衛門や鼠小僧はいまだに歌舞伎や小説の題材になるなど、人々から愛されている。これは「盗みであっても、富めるものから、貧しいものへの分配は善良な行為であるという価値観」であるという話。

　現代における「違法なアップロード」も石川五右衛門や鼠小僧と同様に、「逮捕されるというリスクを負いながら、貧しいものに財物を無償で配布しているわけ」なのだという。

　石川五右衛門や鼠小僧と現代の違法アップロードをする人の違いは、原本がアップロードされても、これは八百屋がリンゴを盗まれたようなものではなく、原本が磨耗したわけではない、と指摘。「盗みと配布によって、具体的な誰か誰かを困らせてるわけではない」と結論付けている。いくらこれらが違法行為であろうが、日本人のモラルから考えればこれは「義賊」の行為であり、「滅私の行為」だと語っている。


だそうな。。
えー、ここからいえることといえば。。。
２ちゃんにダウンロード板がなくなることはない（＾＾；）

データベースからＷｅｂや本、雑誌などを自動生成するＤＢ編集の考え方（その１：レイアウト）

　土日シリーズで、土曜日に書く、新しいネタとして、こんなのをやってみたいと思います。

　ちょっと前のブログで、雑誌などの自動編集という書き方をしたけど、雑誌だけでなく、Ｗｅｂやチラシ、カタログなど、データベースから自動編集することがあります。
　そのとき、どのように考えていくかのお話です。

---

■そのまえにまず、レイアウトについて

　そのまえに、用語の説明。
　雑誌でも、本でもチラシでもパンフレットでも、Ｗｅｂでもなんでもそうなんだけど、以下のように、レイアウトというのを考えます。

・まず、ページという概念があります。
　紙なら、１ページって言うのがわかると思います。
　Ｗｅｂでも、ホームページっていうように、１ＨＴＭＬで開いて見えるのを
　ページとします。

・ページの中にどんなものを、どこに置くかというのを、レイアウトといいます。

・どんなもの？っていうのは、ひとつのまとまった記事とかを、枠で示します。
　枠は四角形とは限りません（雑誌などだと、丸い枠とか、ふきだしの枠もありえます）

・この枠１つ１つを、ここでは、小組（こぐみ）と呼びます。

・この小組のなかに、文字や絵があります。

---

■具体例

　具体的な例を示します。
　以下のようなページがあったとします。


　このとき（黒い部分が実際の印刷物で赤い部分が説明だとして）、
　長方形の３つ、小組１、小組２、小組３と、
　爆弾マークの小組４は、明らかに、上記の説明でいう小組みです
（上記のケースで、見出しと、場所のようなやつは、小組という人と、言わない人がいる）

　基本的に小組ごとに、仕事を任せて（別の人に同時並行にやってもらってＯＫ）、
それをライブラリに入れておいてもらって（ライブラリは共有する）、最後に、レイアウト上に貼りこんで、仕事を完結させます。

　この一連の作業を自動化するわけです。

---

■素材について

　小組みの中に、素材となる、文字やデータが入っています。
　（上記の例では、文字、パソコン１個１０万円とか書いてあった）

　素材には
　　　文字データ
　　　線画データ
　　　イメージデータ
　の３種類があります。

●文字データは、文字のデータ（テキストデータ）です。
　コードの問題、フォントの問題が発生します。
　なお、文字には、飾り文字というのがあります。

●線画データは、ベクトルデータと呼ばれるもので、絵です。
　ただ、イメージとちがって、どこからどこまで線を引くという書き方をしているので、解像度には関係ありません。イラストレーターの絵（図）などが、それにあたります。

●イメージデータは、写真のデータです
　ドットで表現されます。

１つの小組みの中には、複数の文字、線画、イメージが共存します。
というか、小組みの中に小組みがあったりもします。

---

■まとめ
こんなかんじ

１つの本、サイト
　　＋ページ
　　　　　→ページのなかに、どのように小組をおくか、「レイアウトする」
　　　＋小組
　　　　　→小組のなかに、どのように素材をおくか：決まってることが多い
　　　　　＋素材
　　　　　　　＋文字データ
　　　　　　　＋線画データ
　　　　　　　＋イメージデータ

　ちなみに、「ページのなかに、どのように小組をおくか」というのを、レイアウトデータと呼びます。

YouTube自動再生のはてなの「RIMO」 VS JASRAC

　きのうから、Ｙｏｕ　Ｔｕｂｅの人気動画を自動再生する、はてなの
ＲＩＭＯ
http://rimo.tv/
が、話題なわけで、ウィリアムのいたずらもブログに書いたけど、

冷静に考えると（って、考えなくてもわかるが　＾＾；）、
著作権的に問題のありそうなもん、ばりばりに流れてるよね。。

でも、まあ、そのぐらいは「はてな」はサービス始めるまえに
わかっているはずで、

きっと、

ＪＡＳＲＡＣとなんか話をつけたか、
絶対に訴訟を起こされても勝てる！というものをもってるのか、
ＪＡＳＲＡＣに訴えられない「なにか」があるとか。。。

なんか、手を打っているから、サービス開始したんだろうな（＾＾；）

---

やっぱ、考えられる論理としては、
ＲＩＭＯは、ＹｏｕＴｕｂｅのビデオを流しているだけで、

著作権違反をしているのはＹｏｕＴｕｂｅで、

ＲＩＭＯ自体は、
　　「著作権を守っている」といっているＹｏｕＴｕｂｅから
　　　データをうけとって、ながしてるんだから、
　うちにいわれても。。。

っていう論理なのかしら？

でも、この論理が成立するとすると、
著作権に違反してないファイルを交換するとおもって作ったソフトが
結果として利用者によって著作権違反されてした場合は？
（Ｗｉｎｎｙとか。。。）

逆に成立しないとすると、
掲示板のアプリケーションを開発した開発者まで問題になっちゃうよね。。

まあ、このへん、どーいう話になるのか。。。
興味。。。は、ないな、あんまし（＾＾；）

Linuxパソコンにアップグレード版Vistaをインストールする記事が載ってるが！？

つまり、Windowsがなにものっていない、Ｌｉｎｕｘマシン上に、
「アップグレード版」のWindows　Ｖｉｓｔａ（つまり、新規ユーザー用のやつより、安い、アップグレード版）をつかって、
Ｖｉｓｔａをフルインストールする方法ってのが

アップグレード版Vistaを新規インストールする方法が明らかに
http://news.livedoor.com/article/detail/3030899/
に載っているけど（以下斜体は上記ニュースより引用）


　Microsoft関係者は、「この迂回方法を実行するのは非常に限られたごくわずかな人々だけだと信じている。


って、書いてあるように、たしかに、これで、恩恵を受ける人はほとんどいないような気が。。。

今Linuxマシンになっているのは、いっぱいあるかもしれないけど、それは、買ったときにはたいていWindowsがはいってるわけで、（その場合、Windowsユーザーでもあるわけで）

ということは、これで恩恵を受ける人は、Ｌｉｎｕｘしかはいってないマシンで、かつ、Ｖｉｓｔａが動く環境のマシンの人。。。が、わざわざ、Ｖｉｓｔａを入れるかなあ。。

　Ｍａｃの人は、Windowsマシンにする気はないだろうから、Ｖｉｓｔａなんてかわないだろうし。。

　って考えると。。。対象者は、ほとんどいない（＾＾；）？

なお、言うまでもないことですが


　Microsoftは、この方法が可能であることを認めたが、これを利用する者は同社のライセンス条件に違反すると警告する。

　Microsoftの関係者は、「『Windows XP』またはそれ以前のバージョンのWindowsのライセンスコピーを所有せずにこの迂回方法を利用する者は、Windows Vistaのアップグレード版を購入する際に同意した使用許諾書に違反することになる」と述べた。

ですので、方法がわかっても（その生地の下のほうに書いてある）、
やっちゃ、だめですよお（＾＾；）！！

「YouTubeの人気動画をダラ見」っていうはてなの新サービス！いいかもお。。。

ここのブログ

YouTubeの人気動画をダラ見しよう！
http://zook.seesaa.net/article/33821415.html

でしったんだけど、はてなが、
ＲＩＭＯ
http://rimo.tv/
っていうサービスをはじめたんだって！！

以下斜体は上記ブログより引用

YouTubeの人気コンテンツを、
次々に自動で再生してくれるサービス
つまり、テレビのようにつけっ放しにしておいて、
興味がなかったらチャンネルを変えたり、電源を切る。
いたって操作はシンプルだ


で、見てみたんだけど、
はじめに、桜チラリだっけ、のＰＶで、そのあとからも、
おお、いいかんじ（＾＾）
あんまり好きではない音楽の場合は、先送りしちゃえば良いし。。

もちろん、世の中には音楽が好きでない人もいるだろうから、
その人はちゃんねるを変えればいいっていうわけ。。
といっても、いろんなチャンネルがあるわけではなく


１：音楽
２：お笑い
３：アート＆アニメ
４：ペット＆アニマル


だけなんだけど（＾＾；）。。。

おおおおお、このサービス、いいよお（＾＾）ｖ

Ｗｅｂ２．０のなかで、一番ウィリアムのいたずらのツボに
はまったサービスかも（＾＾）


これほどまでユーザーにとって受動的なサービスは、
今までのHatenaの（Web2.0っぽい）サービスとは離れてる気がするけど、


世間はそれを求めてるんだと思う。
だから、テレビをみるし、Ｙａｈｏｏでマッシュアップされている
ニュースをみる。

こりゃー、はてな、お金がなくなったら、
（いや、あっても）
このビデオの間にＣＭ流したりして。。

音楽チャンネルでエイベックスのＰＶがながれても、
ぜんぜん違和感なく見てしまうと思う。
（あ、レコード会社のＰＶだったら、逆に入って欲しい気がする。。）

大きなトラブルになるプロジェクトは、初期段階で兆候が顕れています

今日、たまたま検索していたら、興味深いサイトがひっかかったので、
ご紹介。。

　金融ビジネスアンドテクノロジーの金融ＩＴニュースコメント

で、その中でも
開発プロジェクト・リスク（遅延、中止が相次ぐ）
http://www.fin-bt.co.jp/comment371.htm
に（以下斜体は上記サイトより引用）


大きなトラブルになるプロジェクトは、初期段階で兆候が顕れています。


とかいてあって、そのあとに、その兆候が書いてある

第一に、アプリ・ドメインの選定を間違える。
第二に、意思決定メカニズムが不明確。
第三に、トップの参画が不十分。
第四に、検証不十分なプラットフォームの採用。
第五で最大は、下から信用されないＰＭです。


たしかに。。。


これが全て揃っているプロジェクトは、間違いなく破綻します。

っていわれちゃうと、ほとんどのプロジェクトが破綻したりして（＾＾；）


プロジェクトの失敗は、多くの場合、ベンダーに責任があると思われガちですが、真の原因はユーザー側にあることが大半です。ベンダーは、ユーザーの言いなりではいけません。正しいことを堂々と主張し、それを受け入れるユーザーとだけ付合うべきです。そうしないと、共倒れになります。


そのとーっり！！いいこというじゃん

---

あ、で、その記事の一番上の新聞の切り抜き？？写真。。

笑える（＾＾；）


業績修正のTIS、
「失敗案件ではない。結合テストに想定外の手間」


いや、結合テストに手間取ってるって言うことは、失敗なんじゃあ（＾＾；）
仕様書の設計の矛盾や想定漏れは、結合テストで現れるので、
そこで、「想定外の」ことがあるっていうことは。。。
失敗なのですよ（＾＾；）。。。と、おもうけど？

ある時点からの更新履歴をとる場合のRSSとPINGの話

　忘れそうなのでメモ
（すみません。メモなのでまとまった話ではないです..）　

　ふつうのRSSサーバーだと、RSSには、最近の更新情報（30個分とか）しか載せない。
　なので、RSSをつかって、ある任意の時点から、更新された履歴の全部を仮にとりたいとすると（ふつうは、そんな使い方はしないけど、さっきみたいに、RSSフォーマットを使ってデータを集信する場合にはありえる）、

・一定時間ごとにRSSを取得して、
・その結果をDBとマッチング、
・更新された部分をDB修正する

っていう機能を持ったRSSアグリゲーターが必要になる。
（クライアントはRSSアグリゲーターにアクセスする）

---

　でも、この方法だと、それが、現時点で本当に最新かどうか分からないっていうことになる（RSS取得後にまた更新されてるかもしれない）。

　これを避けるには、更新されたたびにRSSアグリゲーターにpingをあげたほうが早い。

　でも、もし、更新されるときにRSSアグリゲーターにPINGを通知するなら、そもそも、RSSアグリゲーターはRSSを読みに行く必要はない。（でRSSを読まないでPINGだけで処理するなら、このばあい、”RSS”アグリゲーターとはいえない）

結論：
・データの更新履歴サービスなら、RSSを受け取るより、PINGをあるサーバーが受け取って、クライアントは、欲しい条件をCGIでそのサーバーに対して聞いたほうがいいかも。。。

ごめん、まとまったはなしではない。。

雑誌なんかの編集・更新を元にＲＳＳフォーマットの利用を考える

　ちょっと思いついたことでメモ。

　ＲＳＳフォーマットでデータ交換する（実際に書きたい内容は、descriptionにかく）と、タイトルを適切なものにすれば、ＲＳＳリーダーなんかで、汎用的に確認できるねっていうお話を、さっき、電車の中で思いついたので書きます。
　例として、雑誌なんかの自動編集をあげます。

　雑誌なんかの自動編集の場合、おおきなページ内のレイアウトはきまっていて、（たいたいＦＲＯＭ　Ａの紙面って、そーぞーつくでしょ　＾＾；）、その中の枠がいくつかあるかたちになっていて（２つ連続してとったりとか、変形して取ったりする枠もある）、枠の中を編集するということになっています。

　この（レイアウトの中にある、）枠１つ１つを小組（こぐみ）といい、この小組に、データをながすことによって、自動編集は出来ます。
　リアルタイムで時時刻刻と編集内容を変えたい場合（テレビ欄とかもそう。ニュースはもっと大掛かりな話（枠が浮動する）んだけど、にたようなもん）、一度流したものをそこだけ編集するっていうことになります。

---

　さてこのとき、小組の種類によって、流し込むデータはちがうんだけど、ここで、ＲＳＳを使って、

１チャネル１雑誌の１号分

１小組１アイテム

タイトルで何ページのどこの小組かわかるようにして

リンクは、あらかじめ、この自動編集で流し込むイメージデータなどを、どこかの
　　　　　フォルダにまとめておいて、そこのＵＲＬ

descriptionに
　　　　　ＣＤＡＴＡとして、自動編集として流し込むタグデータ
　　　　（あるいはＸＭＬ，ＣＳＶなど）

pubDateに更新時間

をいれておけば、タイトルとpubDataでどこの枠を、どう更新されているかが
わかるし（ＲＳＳリーダーでそういう機能あるかな？なければ、作っても簡単）
データ流し込みには、descriptionとリンクをつかえばいい。
　小組によっては、流し込みプログラムが番うかもしれないので、ＲＳＳを読み込んで
からタイトルを見てディスパッチするのかな？

　とにかく、小組以外は、共通に扱えるので、タイトル名を工夫することによって、
いろんな風に並び替え、絞込みが（違う小組のスタイル間でも）できる。
　そして小組のスタイルごとにプラグインを用意する形で、対応ができる。

　そのうえ、そのＲＳＳに対応するＸＳＬを用意しておけば、ブラウザでも見れるし。。。

---

　ということで、ＲＳＳとは関係ないデータでも、ＲＳＳでラップする（エンベロープとして利用する）ことによって、汎用的なＲＳＳリーダーでいろいろ見えたり、いろんな情報整理が出来て、さらに、新しい小組スタイルの追加も、プラグインで対応できて、おもしろそうだ。

2036年問題や2038年問題のほうが、Ｙ３Ｋ問題よりも問題だろうと思ったら（＾＾；）

この表題
今度は「Y3K問題」、Visual C++に
http://www.itmedia.co.jp/enterprise/articles/0702/14/news024.html

だけをみたら、いやー、３０００年は生きてないだろうけど、
それよりも、あと３０年後におこる、
２０３６年問題（インターネットの時刻同期のＮＴＰの桁あふれ）や
２０３８年問題（Dateの桁あふれ）
のほうが、重要だろう。。。

っておもったら。。。
（以下斜体は上記ニュースより引用）

大きな時間の値を使ってDoS状態が誘発され、アプリケーションが終了してしまう可能性がある。

あ、大きな値を先に入れるんですね（＾＾；）

信頼度成長曲線は、仕様変更が頻繁に起こらない場合はそうなんだけど。。

　で、前のバグ管理の話のときに書こうとした、信頼度成長曲線の話。

　信頼度成長曲線は、横軸に期間、縦軸に累積のバグ量をとると、だんだん収束していく。。。はず（＾＾；）

　っていうのもだけど、実際にやると、必ずしもそうならないと思う。

---

　たしかに、納品局面において、バグは収束しているんだけど、その途中の局面では、急速にバグが出るという状況が何度も発生してしまうと思う。

　どーしてそういうことが起こるかというと、

（１）仕様変更がおこり、なにも手段を講じないとデグレードするから
　　→そのデグレード部分が急激にバグになる

（２）テストで、秘孔を突いてしまうと、一気にバグが出るから。

　で、問題なのは（１）。
　信頼度成長曲線が語られる文脈は、昔のウォータフォール型開発で、仕様変更が頻繁に起こらないことを前提にしていると思う。なので、修正により精度が上がっていくことになる。
　一方、現在の場合は、仕様変更が頻繁に起こるから、デグレード対策をしておかないと、アウト！になる。とくに、インターフェースの仕様変更が起きるようなケースでは、関連箇所に対する変更通知が確実でないと、デグレードが起こる。
　このとき、関連箇所が全部確認できていれば、そこに通知するだけで問題ないが、そもそも、関連箇所全部が見えていればインターフェースの仕様変更って言うのはそんなにおこんないわけで、それが起こるということは、なんらかのインターフェース設計に問題があるって言うことになる。

　なので、その辺、体制を立て直さないと、デグレードになるリスクが多い。

---

　これを防ぐには、リグレッションテストで、はじけば良いわけなんだけど、そのリグレッションテストも全部やっている時間がない。

　で、そのために、ある程度の自動化って言うことになるけど、インターフェースが頻繁に変わると、この自動化も、たいへんになる気がする。。

　なんで、たぶん、やってないだろう。。

　そーすると、修正したときに、デグレードになってしまい、信頼度成長曲線は、わけわかんないことになってくる。

---

　で、この場合、バグが収束するか、発散するかの決め手は、主線が、どうなっているかによるんですけどね。主線が、発散しなければ、どうにかなるし、逆に主線が発散してしまう（あるいは、矛盾がおきたり、できなくなってしまう）と永遠に発散してしまう。

　この場合、主線が固まると、急速にバグは収束する。

　で、主線ってなに？っていう話になってしまうが、それはまあ、今回は置いておくとして（気が向いたら書きます）

---

　てなわけで、信頼度成長曲線をそのまま信じるのは危険だし、
　「なんでデグレードするんだ！」っていう上司に限って
　　　デグレード対策してない（だから、デグレードするんだよ）し

　　そもそも、なんで、上司の問題なんだ？って聞いちゃいそうだし。。
　　　念のために、この問題は、今度説明しておくか。。

　　簡単に言うと、インターフェースは担当者では読みきれないのよ。
　　インターフェースは、対外に関するので、対外との交渉担当である
　　マネージャーじゃないと管理できない。

　　でも、問題は、その対外担当のマネージャーが、自分の仕事を理解できない
　構造にあるって言うこと（これは、昔は違った）なんだけど。。ね。

JavascriptでIEからテキストファイルを保存、読み込みする

Windowsでかつ、InternetExplorerを使ったときだけなんだけど
（また、セキュリティ上、HTTPを使わないで、そのファイルをダブルクリックして表示したときだけなんだけど）

Javascriptから、テキストファイルを保存、読み込みさせる方法

　　　Scripting.FileSystemObject

を使います。

---

■仕様

outtest.txtというファイル名で

test	123	ABC
test	456	EFG

と書き出す。

また、このファイルを読み込み、ダイアログで表示する

---

■ソース
こんなかんじ

＜html＞
＜head＞＜title＞ファイルのテスト＜/title＞＜/head＞
＜body＞
＜SCRIPT Language="JavaScript"＞
＜!--
	//======================================//
	//	ファイルシステムの取得	   //
	//======================================//
	var fs	= new ActiveXObject("Scripting.FileSystemObject");

	//======================================//
	//	ファイル書き出し		    //
	//======================================//
    	var outf = fs.CreateTextFile("outtest.txt", true);
    	outf.Write("test￥t123￥tABC￥r￥n"); 
    	outf.Write("test￥t456￥tEFG￥r￥n"); 
    	outf.Close(); 

	//======================================//
	//	ファイル読み込み		    //
	//======================================//
	var inf = fs.OpenTextFile("outtest.txt", 1, true);
	var str1= inf.ReadAll(); 
    	inf.Close();
	alert(str1);

// --＞
＜/SCRIPT＞
＜/body＞
＜/html＞

（上記　＜　＞　￥　は、本当は半角）

デスクトップにouttest.txtというファイル名で書き出しました
（起動したのはデスクトップではないですが。。
　WindowsXPのSP1でIE6でファイルをダブルクリックして確認しました
　実行する前に、「問題ありませんか？」という警告ダイアログが出ます）

---

■参考にしたサイト
Flash Desktop Clock
http://dawgsdk.cside.com/desktop/develop/clock/