Excelから書き出したHTMLファイルがジオシティーズでは表示されない場合の対処法

　昨日のブログ、「FrontPageでHTMLファイルで保存すると、Excelで開いてもExcelファイルで保存不可」の続きです。

---

　Excelを開き、１のＨＴＭＬファイルを読み込もうとしたら。。。
　読み込めない！
　FrontPageが開いちゃうんです。
　なので、ここで保存してももともとのファイルが保存されるだけでExcelファイルに変換されないのです。。。。

　というところで終わりました。

　で、どうするか？
　はじめから(Front Pageでなく）Excelファイルで作成し、「webページとして保存」すると、ＨＴＭＬファイルで保存されますが、次回から立ち上げたときも、Excelで開け、操作できます。
　ということで、はじめから、Excelファイルで作成し、webにアップしたいときは、ＨＴＭＬ形式にする（webファイルとして保存する）ということにしましょう。

---

　ちなみに、なぜ、Excelで読み込もうとしても、Front Pageが立ち上がるかというと、
　FrontPageでＨＴＭＬファイルとして保存すると、
＜meta name="GENERATOR" content="Microsoft FrontPage 4.0"＞
＜meta name="ProgId" content="FrontPage.Editor.Document"＞
　というタグが書き出されてしまいます。
　このタグをみて、Excelは、FrontPageを立ち上げているようです。
　だからこの２行を削除すると、Excelから読み込んだとき、Excelに変換されて、１シートとして読み込めます。

　また、なぜ、HTML形式なのに、Excelが立ち上がるかというのも、Ｅｘｃｅｌから「Webファイルとして保存」を実行して保存したＨＴＭＬファイルは、Excelで作成した旨のタグが書き出されるので、それで判断しているようです。
（どれを削除すれば、解釈されないか、までは、実験してないです）

---

　じゃあ、Ｅｘｃｅｌで、webファイルとして保存を実行したＨＴＭＬを、ジオシティーズにアップしようとすると。。。

　できないんだな、これが！！

　まず、Excelファイルをwebファイルとして保存すると、ファイル名.filesというフォルダができます（たとえば、Book1を保存するとBook1.filesというフォルダが出来る）
　この.を含むフォルダは、ジオシティーズでは、作成できません。
　そこで、.を_に変え、ファイル名_filesというフォルダにしましょう。
　（例だとBook1.filesをBook1_filesにする）。変えるとき、たぶんメッセージが出ると思うけど、無視っす。

　で、そうすると、もとのＨＴＭＬファイル（例の場合Book1.htm)のほうと矛盾してしまうので、元のＨＴＭＬファイル（Book1.htm)を開いて、ファイル名.filesをファイル名_filesに置換します（例だとBook1.filesをBook1_filesに変える）

　こうすると、ファイル名_filesのフォルダを、作成することはできます。
　で、ファイルを転送すると、表示しないんだな。これが！

---

　ところが、ロリポップのサーバーにアップして表示させると、表示するんだなこれが！

　理由は、リンク先のチェックをしているからみたいです。
もとのＨＴＭＬファイル（例の場合Book1.htm)中に、
＜link rel=Edit-Time-Data href="./Book1.files/editdata.mso"＞
＜link rel=OLE-Object-Data href="./Book1.files/oledata.mso"＞
という記述がありますが、editdata.msoというファイル等はありません。
そこで、この２行を削除します。

　そうして、もう一度ジオシティーズにアップすると、やっと表示できます。

アンニュイな午後、きれーなおねーさまと語る、汎用と最近のシステムのテストの違い

　昨日の午後のことです。コーヒーでも飲みながら、きれーなおねーさまと語らう、アンニュイな午後を過ごしておりました（＝ひまで、お仕事もらってる会社に最近入社したＳＥさんと、話してました）。
　
　そのきれーなおねーさま（＝ＳＥさん）は、汎用のほうをやっていたそうなのですが、会社に入社してから、ＪＡＶＡで組むようになったそうです。そこで疑問があると。。。
　汎用のときは、プログラムのホワイトボックステストを主流にやっていて、分岐ごとにチェックしていたのに、この会社のスケジュールにホワイトボックステストがないのはなぜ！？

---

　ご説明いたしますです。

　汎用機のシステムの多くは、９０年代前に作られました。
　そのときの仕様書（詳細設計書）は、プログラムの分岐にいたるまで、書かれているのが主流でした。
　また、当時＆その後に流行ったＤＯＡにおいても、最終的にはミニスペックに落とされるため、ミニスペックに、分岐の内容まで記述されていることが主流でございました。

　ここで、問題です。テストを行うには、どうしたらよいでしょうか。
　SLCP(特にSLCP-JCF98）における、設計とテストの関係の話題を持ち出すまでも無く、仕様書がなければ、その仕様を満たしているかどうかのテストは行えません。

　つーことはですね、結局できるのは、仕様書が存在するところまで、でございます。

　つまり、ＵＭＬにおいて、クラス図があって、インターフェースがテキトーにきまっていれば、「あとはよろしく」でプログラムを書かされてしまうわけですが、
　その場合、クラス図のメソッドにかかれた引数で、思った帰り値が帰ってくるかまでしか、テストできないっす。
　分岐までのドキュメントがあれば話はべつですが、そのドキュメントを作らない場合（さいきん、つくらないなあー）、そのクラス図レベルなのでございます。

　さらに、ＭＶＣに分けた場合、モデルとなる、クラスの引数と帰り値、こいつはテストするんですが、ビューとコントロールはたいてい、決まった作り（ドキュメントからＪａｖａのクラスを自動生成なんていうこともありますよね。そういう自動生成プログラム作成の仕事、ウィリアムのいたずらは、多いんですけど）をしているので、そのへんは、ブラックボックステストでいいんじゃない！ということになってしまうのでございます。

　つまりですね、単体のホワイトボックスをやろうにも、そこまで細かいドキュメントを作らないことが多いので、ブラックボックスっぽいテスト中心になってしまうのでございます。

---

　という説明をしたら、そのきれーなおねーさま（＝ＳＥって、くどいね！）いわく

「そんなんで、いいんですか？」

　いやー（ことば、ございません）

　うーん、こんなんで、品質とか、本当にいいんだろうか？
　クラス図で止めるのって、結構やばい気がするんだよねー。
　でも、実際、それよりも細かく書くのであれば、実際プログラム書いちゃったほうが早いし。
　うーん(^^;)。