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/

Javascriptで、リストの全要素を削除する

いや、まったくたいした内容じゃないんだけど、
自分に対するメモ

HTMLのselectタグで書くようなものがありますよね。
たとえば、こんなかんじ

今日のニュース（見たいものを選択）
＜select id="deltest" name="deltest" size=1＞
	＜option value="1" selected＞フェリー離岸＜/option＞
	＜option value="2"＞会長志望＜/option＞
	＜option value="3"＞７歳児行方不明＜/option＞
	＜option value="4"＞Officeを攻撃＜/option＞
＜/select＞＜BR＞

(上記　＜　＞　は、本当は半角）

で、このとき、このリストを全部消したいというときがある
（たとえば、１時間おきにニュースを消したいとか）
そんな場合、Javascriptでかくには？

もっといい方法があるかもしれないけど、とりあえず、これで消える

	sl = document.getElementById('deltest');
	while(sl.lastChild)
	{
		sl.removeChild(sl.lastChild);
	}

バグ管理の話

きのう、たまたまなんだけど、（blog.goo.ne.jpをみていたときに、たまたまみつけた）
こんなブログをみつけました
Excelを有効活用すれば効率は上がる
http://blog.goo.ne.jp/wildriver_1977/e/cebd060cf404e78d7409902c01720f26

そこに、

例えば、ソフトウェア開発の世界では、バグトラッキングシステムを活用して、バグの情報を登録しています。
そこで、その機能にExcelやCSV出力機能がついていれば、あるいは自分でつけてしまえば、簡単に集計することができます。

ってかいてあるんだけど、
　Excelや桐やAccessや紙ベースでしか、
バグ管理したことしか「ない」私の立場は（＾＾；）

---

　最近は「バグトラッキングシステム」なのかもしれないけど、現実的に、朝会、誘拐（夕会？）とか、とくに立って会議をするような状況において、バグトラッキングシステムでネット上でバグ報告をみるっていうのは、きついんじゃないかなあ。。

　紙にだすんだったら、Excelのほうが、きれいで早いし、見やすいしね。。

　また、各社と協業でする場合、ファイヤーウォールを越えてバグトラッキングシステムをみせるっていうのは、やっぱ”やばさ”があると思う。それより、各社の管理台帳、バグ票をメールでやり取りして、集配信したほうが、Excelマクロですむから、らくなわけっすよ。

　ってことで、ウィリアムのいたずら、個人的にやる場合は、また、会社でやる場合も、管理台帳はExcelがおおいかなあ。。ふつうのバグトラッキングシステムで必要な内容程度は、すぐにExcelのマクロでつくれるしね。
　っていうか、そのぐらいのマクロが作れないと、テストデータとか、プログラムの自動生成できないもんね（＾＾；）

---

あ、ここで意識合わせ。

Wikipediaのバグ管理システムの説明（以下斜体はそこからの説明）には


バグの発見日時や発見者、再現方法、修正担当者、修正履歴、修正方法、重要度、テスト状況などの多くの情報


ってかいてあるけど、これは、おもに３つの情報から成り立つ

＜＜サマリーデータ＞＞
バグID、発見日、発見者、バージョン、緊急度（重要度）、ステータス（原因解析中／修正中／修正確認中／リリースまち／リリース／再現不能など）、障害箇所（複数の場合もあるけど）、障害概要、修正担当者（複数の場合もあるけど）、修正日、修正バージョン、

＜＜詳細データ＞＞
（サマリーデータにくわえ）
・障害発生手順（再現手順・テスト状況など）
・障害理由
・修正箇所
・横並びチェック事項

＜＜添付資料＞＞
・障害発生手順および修正に関する資料
　（バグの帳票、画面、外国人が開発者の場合、操作ムービーが取れるときには、
　　それとかもあり。あと、再現不能、再現手順不明の場合はcore dumpとか、
　　エラーが出るデータをDBに登録するSQLとか）

●ここで、サマリーデータは管理上必要な情報で、コレは（複数項目があるので、第一正規形にならないけど、Excelなら、カンマうって並べればいいので）、Excelで表であらわせるから、表にして管理する。これが、管理台帳といわれるもので、これは、集中管理する。

　なぜならば、バグのIDをシーケンシャルに振るからである
　（番号を重複させないためには集中管理が必要）

　この管理台帳を元に打ち合わせでは管理する（朝会、プロジェクトマネージャーの誘拐じゃない、拉致じゃない、夕会等は、この表ベースとなる）

●一方、添付資料は電子化できないこともあり（帳票出力のバグの場合、帳票は紙である）、紙ベースで管理することもある。そこで、詳細データを紙で印刷してしまい、その添付資料の表紙につけ、リンクファイルに管理すると便利。

　電子化されている場合は、バグIDのフォルダーをきって、そこにいれておく。
　Excelシートなら貼り込み可能なのだが、そーいうことはあんまりしないなあ。。？？

●詳細データは、一般にバグ票といわれているもので、担当者が受け取り、修正したら担当者が記入し、リンクファイルに保存するか、次の担当者に行く。これを、紙ベースでやると、同時に２人が持っていることはない（同じ紙を持つことは物理的不可能なので）ので、修正担当者が１人となり、２人が同時に直すことはなくなる。ただ、逆に言うと、同時並行で２人ガ修正したい場合は、どーするんだということにはなるが、同時に直されるとデグレードするリスクは大きい。

---

ということで、バグの管理台帳は、Excelや紙で、バグ票も、ExcelやWordや紙などで、添付資料は電子媒体または紙で管理される。

　という前提があって、バグトラッキングシステムは、このうち、管理台帳部分をやる場合、バグ票まで管理する場合、添付資料まで管理する場合、さまざまある。

　どこまでやっているのかを明確にしないと、たとえば、管理台帳の機能しかないのに、バグトラッキングシステムで全部やろうとすれば、添付資料はどうなるんだ？ってことで、情報は欠落し、品質は急激に落ちる（添付資料をどうつけるか、バグ票の手順をどう書くかによって、バグの発見のしやすさや完全性は、大きく変わる）。

---

　ということで、Excelは、管理台帳作成に良く使う。

　で、ピボットテーブルより、データのオートフィルタをつかって、担当者ごととか、発生箇所ごとやバージョン（これは修正バージョンも、発生バージョンも）ごとに見ることが多いかなあ。。

---

　あ、で、そのあと信頼度成長曲線の話がでてくるので、これについても書こうと思ったけど、ながくなるので、この辺できるね。

　ちょっと予告しておくと、信頼度成長曲線の話は、むかしのウォーターフォールでは成立した話なんだけど、いま、仕様変更が多く、そうなると、あるところで、発散してしまうケースがあったり、急激にバグが増えてしまう（秘孔をついてしまうんだな）ってことがあって。。ってはなし。ではでは（＾＾）ｖ