ExcelのVBAで、Domを使って、XMLを書き出す

こういうサンプルを、このブログで、書いた気がしたけど、
見つからなかったので、書いておきます。
（まじめに探してないので、もし、あって、ダブっちゃってたらごめん）

---

■仕様

　フォルダを選択するダイアログを出し、
　指定されたフォルダの下に、test.xmlというフォルダ名で
以下の内容のXMLファイルを書き出す

＜?xml version="1.0"?＞
＜rss version="2.0"＞
＜channel/＞
＜/rss＞

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

---

■下準備

ここのブログにあるように、参照設定をひらいたら、以下のようにMicrosoft XMLの、どれかひとつをチェックします。

---

■ソース
こんなかんじ

Sub Macro1()
    Dim fDlg As FileDialog
    Dim fname   As String
    Dim xdoc As New DOMDocument
    Dim xtree As IXMLDOMElement

    Dim zyu As IXMLDOMElement
    Dim pi As IXMLDOMProcessingInstruction
   
   'フォルダのダイアログを出す
    Set fDlg = Application.FileDialog(msoFileDialogFolderPicker)
    fDlg.InitialFileName = "C:￥"
    
    'ファイル名決定
    If (fDlg.Show = -1) Then     'OKのとき
        fname = fDlg.SelectedItems(1) & "￥test.xml"
    Else
        fname = ""
    End If
    Set fDlg = Nothing
    If (fname = "") Then
        Exit Sub
    End If

    'XMLのはじまりを書く
    Set pi = xdoc.createProcessingInstruction("xml", "version='1.0'")
    Call xdoc.appendChild(pi)

    '先頭のノード作成
    Set xtree = xdoc.createElement("rss")
    Call xtree.setAttribute("version", "2.0")   '属性設定
    Call xdoc.appendChild(xtree)
    
    'その下のノードの作成
    Set channel = xdoc.createElement("channel")
    Call xtree.appendChild(channel)
        
    '保存
    xdoc.Save (fname)

End Sub

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

---

■参考にしたサイト
http://www2.moug.net/bbs/exvba/20061207000017.htm
（フォルダダイアログの出し方：「あられすき」さんの）

Excelのコメント、タイトルなどをVBAで扱うには（社外にコピーするとき消したいなど）

　ちょっと自分用に近いメモ。

　Excelを開いてもらうと、ツールバーの「ファイル」に「プロパティ」っていうのがあって、ここに、コメントやタイトル、作成者などが入っている。

　ここに、自動的に何かを設定したい、あるいは、消したい、確認したいというときがある。たとえば、社外にコピーするとき、その作成者が誰か、しらせたくないときなどなど。。

　この場合、VBAで操作するわけだけど、このプロパティは、どこに入っているのかという話。

　具体的には、WorkbookオブジェクトのBuiltinDocumentProperties(取り出したいもの).Valueで取り出せる。
　たとえば、現在開いているワークブックのコメント（プロパティの１つ）をメッセージボックスで出したい場合は、

Sub Macro1()
    
    MsgBox ActiveWorkbook.BuiltinDocumentProperties("Comments").Value

End Sub

でOK。逆に設定したい場合は、

ActiveWorkbook.BuiltinDocumentProperties("Comments").Value= "設定したい言葉"

みたいなかんじ。

　で、問題は、そこの「取り出したいもの」に設定する言葉（実は数字でもOKなんだけど、言葉のほうが分かりやすいと思う）。
　この設定する言葉の一覧が載っているブログがあったので、メモメモ

　ここ
BuiltinDocumentProperties一覧
http://www.relief.jp/itnote/archives/000487.php

YouTubeの自動再生「Rimo」、やっぱJASRACも目を付けてるようだが、不気味？

以前、YouTubeの動画再生サイト「Rimo」と、著作権の関係は、
このブログでもとりあげたけど、

ここのニュース
動画再生サイト「Rimo」にも著作権問題？
http://www.j-cast.com/2007/02/21005658.html
によると、（以下斜体は上記サイトより引用）


日本音楽著作権協会（JASRAC）にJ-CASTニュースが問い合わせると、

「著作権保有者の許可なく動画を配信、または再生しているサービスは、それ自体が当然違法性を問われなければならない」
と、Rimoを問題視していることは明らかだ。


そうな。。やっぱね（＾＾；）

だけどお。。その後の言葉が不気味なのよ。。。


著作権が問題となりそうな動画配信サービスは、Rimoに限らず非常に数が多いため、

「個々のサイトではなく、これらのサービスを行うサイト総体に対しての対応を検討中だ」

と、JASRACは語った。


ねえねえ、何を考えてるの、検討してるの？？

たぶん、そのサイト総体の中には、２ちゃねんねるのダウンロードサイトとかも、ふくまれるんだよねえ。。

うーん、きょうみしんしん（＾＾）ｖ

開発の初めから順番に書いていってみる その３：RFP(3)。

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

RFP自体については前回までで、そのサンプルとポイントについて説明したので、今回は、そこまでの流れについて。

---

■キックオフミーティング

　まず、開発しようと誰かが考えると、その開発について、関係者を集めて、「これから開発を始めたいと思います」という提案がされる会議があります。この開発関係者を集めた一番初めの会議がキックオフミーティングです。

　ただ、この会議がない場合もあるし（ワンマン経営者で決めている場合や、他社からの要請で開発しないといけない場合）、ちゃんとした会議として開かれないこともあります。

　いくつかある会議の議題の1つとか（企画案件の中の１つとか）っていうケースもあるし、顔見世だけの懇親会とか（＾＾；）。。。

　まあ、とにかく、なんだこんなで始まったとします。

---

■何を作ってもらいたいかを決める

　で、その会議、およびその後何回かの打ち合わせの中で、何を作ってもらいたいかを決めます。これは、キックオフミーティングがなくても、RPFを書かなくても、必ず決めなければいけません。だって、決めないと、何を作っていいかわかんないでしょ。。

　で、このために、普通は、要望を出してもらうわけです。
　既存システムの改良や移植であれば、そのシステムに対する変更点、改善要望をまとめます。これに、スノーカードをつかうのは確かに効果的。
　ただ、「いまLinuxで動いてるシステムをWindowsにする」って言う場合は、スノーカードを使うまでもないです。

　それと、特に新しいシステムの場合は、目的とか、効果とかを考えます。
　（これが、要望より先にきます）

---

■予算と期間、その制約を決める

　で、そのあとは、コストと期間を決めます。
　このとき大事なのは、これらに制約があるかないかです。

　たとえば、PASMOみたいに、３月１８日サービス開始と決まっているものは、自社の都合では、日にち動かせないですよね（；＿；）

　コストは、ない袖は触れないというケースがありますし。。

　これは、とっても重要なので、制約があるかないか、ない場合でもおおよそのめどとかは決めてください。期間に関しては、明確に伝えたほうがいいです（きまってなくても、この辺ぐらいと）。コストに関して、決まってない場合は。。まあ、その人の考え方次第。

---

■開発の範囲をきめたあと、開発グランドデザインをきめます

　で、開発の範囲をきめます。範囲として限定されるのは
　　　１．利用者
　　　２．他のシステムとのつながり（入出力）

　です。で、できれば、
　　　３．本システムによる出力
　なんかも、わかると、あとあとの作業は楽になります。。。

　そして、
　　　４．品質やシステム（ネットワーク含む）にかかわることの制約
　があれば、それを挙げて置きます。

　が、まあ、この辺はちゃんと要求仕様をつめるときに決めるのでいいですけど、ある程度の範囲を決めないと、どこまで提案していいかわかんないので、こまります。

　あと、おおまかに、この開発の内容を考えます。これがグランドデザインになりますけど。。ま、そこまでやんなくても（＾＾；）

　それと、既存システムがある場合、それらについての資料をまとめます。

---

■RFPを書く場合は書く。提案書を出してもらう準備をする

　で、あとはRFPを書く場合は、これらをまとめて、この前のサンプルみたいな形式で書き、提案してもらうところを決めて（って、自明かも知んないけど）、どんなかんじで提案してもらうかを決めて、提案をしてもらうオリエンテーションみたいなのをして、RFPをあれば渡して、提案してもらいます。

　ここまでの作業を、だれかが（情報システム部があれば、その人たちだろうけど）中心になってやります。
　この中心になってやる人は、キックオフミーティングをやる前には決めておいたほうがいいと思います（その中心になってやる人が、ミーティングを召集するので）

---

　って、こんなかんじですかね。ま、実際には、こんなにまじめにやることはないケースも多いし、これ以上まじめにやるケースも多いと思うけど。。また、順番は時と場合によって違うと思いますが。。。

　っていうことで、このシリーズの次回から、RFPをもらった後、それを受けて書く提案書について書きたいと思います。

「JavaからRubyへ移行する時は今」なんですか？

ここのサイト
Java イベントレポート
Javaの最新動向を見極める デブサミ2007
http://www.atmarkit.co.jp/fjava/special/devsummit2007/devsummit2007_2.html
に、こんな記事が（以下斜体は上記サイトより引用）


JavaからRubyへ移行する時は今だ？


今。。。なんですかあ（＾＾）？

開発の初めから順番に書いていってみる その２：RFP(2)

　シリーズ開発の初めから順番に書いていってみるの続きで、きのうのRFPの話。

きのう、RFPの見本として

ＲＦＰ・ＳＬＡドキュメント見本提供について
http://www.itc.or.jp/foritc/useful/knowhow/rfpsla/rfpsla_main.html

というものをあげましたけど、今日はそれの、具体的内容です。

上記のサイトにある、開発委託用ＲＦＰ見本（kaihatsurfp_v10e.pdf)について説明します。
その提案依頼書には、
１．システム概要
２．提案依頼事項
３．提案手続きについて
４．提案に関する条件
５．保証要件
６．契約事項

とあります。

　で、これをもらって、提案する側としては、

「１．３ 解決したい課題」のそれぞれについて、
　　　こちらが提案する方法で、
　　　「５．保証要件」にある制約を満たしながら、
　　　「１．４ 狙いとする効果」が得られるか
　ということを考えて、提案する方法をきめます。


　そうしたら、「２．提案依頼事項」に書かれている内容に沿って、
　提案をまとめるわけですが、書き方については、いろいろあります。
　提案された側は、「１．３ 解決したい課題」や「５．保証要件」にある制約を満たしているかのチェックシートはつくっているはずなので、

・まず、方法をバーンと出して、それについて、「１．３ 解決したい課題」をクリアしていて、「１．４ 狙いとする効果」が得られるよっていうことを書いてから、依頼事項を細かく書いていくのか、

・それとも、本当に依頼事項に全部沿いながら書いていくか、

・それとも、システムの概要説明から素直に書くか？などです。

　提案書については、今後、もっと詳しく見ていきます。

---

　それ以外の部分については、提案書を出す上で必要な
　　　・事務的事項など
　　　・背景などの参考資料
　なので、とりあえず、目を通して、事務的事項は間違わないように注意して、
　提案書を作っていくことになります。

　なお、これらを無視して、自分勝手に提案をする会社などもありますが（＾＾；）
　大手なら権威で売り込めるかもしれませんが、それ以外では、逆に悪印象を与えるから避けるべきです。

　逆に、自分勝手に提案して、乗ってくる顧客は要注意です。
　とくに、こちらが「儲かりますよ」といって、それに乗ってきた客は、儲け話に目がない、下品な客のため、あとで（とくに儲け話の反対、カネを払う段階になって）問題を起こす可能性があります。
　そういう客は、儲け話が好きなだけなのです。

　また社内規定で「あいみつ」（相見積）をとらなければいけない場合、一生懸命やるとムダなので、（とはいえ、見積もりを立てないと失礼なので）テキトーに提案書をつくることもあります。こういう話は、提案書のところで、具体的に書きます。

---

　それと、RFPがない場合があります（その上提案書もない場合もあるし、提案書は書く場合もある）。

　その際には、ヒアリングして、「解決したい課題」と「保証要件」、それ以外の希望や制約要件については聞いておいてまとめておくことです（こちらからまとめて確認してもOK。つまり、こっちからRFP相当のものを作ってしまうという話もありえる）。

---

　ということで、このシリーズの次回では、今度は逆の立場、このRFPを作る側としては、どういうことをやって、作っていくかについて書きます。

LinuxでVisual Basicが動くってことですか（＾＾；）

ここのスラッシュドットニュース
Monoプロジェクト、GNU/Linux用Visual Basicを発表
http://slashdot.jp/articles/07/02/21/2333212.shtml
によると（以下斜体は上記サイトより引用）


.NETのオープンソース実装を開発するMonoプロジェクトが、Visual Basicコンパイラを公開した。GNU/Linuxは言うまでもなく、Monoがサポートするプラットフォームであれば、どのプラットフォームでもMicrosoft Visual Basic 8.0で書かれたプログラムをコードの変更無しに実行することが可能だという。


おお、LinuxでVisual Basicが動くってことですか！

きょうみしんしん！！
すぐみてみましょう。

ここ
Mono brings Visual Basic programs to Linux
http://www.linuxdevices.com/news/NS9725385854.html
によると（以下斜体は上記サイトより引用）


This new and improved compiler, which supports Visual Basic 8.0 code, is bundled in Mono 1.2.3. In addition to Visual Basic support,


ほー、Mono1.2.3っていうのに、バンドルされている（＝中に入ってる）のね。

じゃあ、Mono1.2.3っていうのは？
ここ http://www.go-mono.com/archive/1.2.3/
みたい（＾＾）
たしかにそこに（以下斜体は上記サイトより引用）


Visual Basic
This is the first release of Mono that includes the self-hosting Visual Basic environment. This is a preview of the Basic support, we will be releasing this officially at a later date.

The source code is available on a separate download (mono-basic package).


ってかいてあるから、そんな気もするが。。。

それ以前に、Monoって何（＾＾；）

開発の初めから順番に書いていってみる その１：RFP(1)

　開発の初めから順番に書いていくシリーズをやるといった話を以前書きましたので、今日はその話。

　開発の流れに関しては、以前書いたとおり

・RFPを受け取る
・提案書を作る
・要件仕様
　　・ヒアリングをする前にしておいたことがいいこと
　　・ヒアリング
　　・要件仕様への展開

・外部仕様書など
　　・画面定義
　　・テーブル定義（ファイル定義）
　　・フレームワークの決定

・詳細設計

・プログラミング

・テスト
　　・テスト仕様書の作成
　　・テストデータ作成・テスト環境作成
　　・テスト実施

・運用

なので、まずは、「RFPを受け取る」から。

---

■開発の始まり

　システム開発は、まあ、いろんなことで始まるわけです。。

　　戦略的に考えて誰かが掛け声をかけて始まるとか、
　　コンピューターの営業にそそのかされたとか
　　なんか、展示会を見て、とちくるったとか
　　自分はしたくないけど、取引先が電子化したから。。

　などなど。

　で、じぶんのところで作れればいいけど、
　たいていの場合はじぶんのところで作れない。

　なので、どういうシステムを作りたいかというのを書いて、ソフトを作ってくれるところ（メーカーさん、ソフトハウスなど）にわたして、提案してもらう。
　この提案してもらうために、「どういうシステムを作りたいか」というのを書いたのがRFPなわけです。

　でも、こんなまじめな開発じゃなくって、ソフトハウスが持ちかけてきたような案件だと、RFPっていうのが、ないわけです。
　つまり、RFPは、必ずしもあるわけじゃないです。
　ちなみにRFPは、request for proposalの略です。

---

■RFPの内容
　RFPには、決まった内容はありません。
　っていわれても、困ると思うので、どういう内容が書いてあるのが普通かというと、
　ここにある
RFP （request for proposal）
http://www.atmarkit.co.jp/aig/04biz/rfp.html
のによると（以下斜体は上記サイトより引用）


　システムの「概要と目的」「必要な機能」「求められるシステム条件」「サービスレベル」「予算」「納期」「契約条件」「評価プロセスと評価基準」「調達方針」「環境」など具体的な要求を盛り込む必要がある。さらに各要求に優先度を付け、システム導入にあたってゆずれない条件を明記することもポイントだ。またベンダに対して、「提案書の形式」「提出期限」「提出先」「提出方法」などを指定する。


で、どんなものかって言うサンプルは、
ＲＦＰ・ＳＬＡドキュメント見本提供について
http://www.itc.or.jp/foritc/useful/knowhow/rfpsla/rfpsla_main.html
つーものがある。

で、次回は、もうちょっと、RFPの中身について、突っ込んだ話を書きたいと思います。

DomでChildの操作がめんどくさいとき、配列に落としてしまったほうが。。。

やりやすいかもお。。
XMLで、あるタグの下にある子供に関して、いっせいに何かしたいという場合、

　もちろん、firstChildで先頭の子供をとってきて、nextSiblingで、つぎつぎと、子供を処理していくって行くようにして、なんら問題はない。

　問題はないんだけど、１個前に戻りたいとか、１個前と１個先を使ってなんかしたいとか、いろいろなケースがあると、めんどっちい。

　配列に入れちゃって、forループでまわしたほうが、やさしいってこともある。

　その場合のメモメモ。

---

■概要

var 子供のリスト = 元のノード.childNodes;

で、子供のノードリストを、「子供のリスト」にいれる。

そしたら、
for (var i = 0; i ＜ 子供のリスト.length; i++)
{
　　var 子供１個分 = 子供のリスト.item(i);
　　やりたい処理;
}
で、ループをまわして処理できる

---

■サンプル

　いま、select1とselect2という、selectタグで書かれたリストがあり、
select1のオプションをselect2に追加したい場合。

	sl	= document.getElementById('select2');
	motosl 	= document.getElementById('select1');
	var chlist = motosl.childNodes;
	for (var i = 0; i ＜ chlist.length; i++)
	{
		var ch = chlist.item(i);
		if (ch.nodeName	!=	"OPTION")
			continue;

		newop = document.createElement("option");
		newop.id 	=	ch.id;
		newop.value	= 	ch.value;
		newop.appendChild(document.createTextNode
				(ch.firstChild.nodeValue));
		sl.appendChild(newop);
	}

（上記＜は、本当は半角です）

手の付けやすい仕事からやると、結局、問題が最後まで残り、どうにもならなくなる

　で、前に書いた主線について、説明するって書いたけど、その話。

---

　システム開発を進めるにあたり、まず、

　　１．フレームワークを決める
　　２．要素技術（特に困難な部分）を解明しておく
　　３．クリティカルパスになる作業を重要な順に、（とはいえ、順番があるので、
　　　　その順番で）ならべて、こなしていく

というのが、安全な方法になる。

　で、この１、２、３がメインストーリーとなり、これ以外の部分は、間に入れていけばいいっていうことになる（遅れが出た場合でも、１，２，３以外は、たいてい、増員することで対応は可能。逆に１～３の遅れの場合、増員すると、なおさら遅くなる。こちらは、残業でないと対応できない）。

　この１，２，３を主線と表現しました（一般的な用語ではないと思います。なので、言葉自体はどーでもいいです）。
　１，２，３の遅れは、即遅れにつながります（だって、クリティカルパスをつなげているわけだから　＾＾；）。逆にいうと、それ以外の遅れは挽回が可能な場合もけっこうあります。なので、主線がおくれないこと、仕様変更がないこと、バグが収束することが重要になります。そこで、まず、主線にエース級の人を投入してしまい、あとののこりをテキトーに割り振るという感じにするほうが安全です。

　ということは、フレームワークをいじってしまって、それが崩れてしまうと、主線がくるうことになるので結構やばいということです。逆に、主線にのってこない画面変更なんていうのは、変更されても問題ないことが多いです。

---

　ところが、これを、手の付けやすい仕事からやっていく人たちが居ます。
　とりあえず、分かったところからやっていこうと。。
　そうすると、初めのうちは、どんどん仕事が進んでいるように見えるのですが、結局、重要なところが残ってしまいます。
　これだけでも、もんだいなことは、高校講座　数学基礎にあるとおり（ここの「独立した仕事の手順」）なのですが、実際には、後回ししたものが、「うん、できない！」とか言うことになって、いままでやったものの仕様変更が必要になったりして（とくに、このとき、フレームワークを修正されると、最悪になる）泥沼に陥る可能性大です。

---

　うーん、でも、実際には「手の付けやすい仕事からやっていく人」がおおいのよねー。
　学校のテストのクセで（テストは、「手の付けやすい問題からとく」のが鉄則）

　こりゃー、高校講座　数学基礎の秋山大先生（駿台でありえないほどの超人気講師だったあの、秋山先生）にがんばっていただかないと。。。って、最近はハッチー（鉢嶺杏奈さんのこと）と楽しんでるだけだしなあ。。（そーじゃないって　＾＾；）

　うーん、でも、日本の底上げよりも、そっちのほうが、ずっと楽しいだろうけど（＾＾；）

P.S　でも、ハッチーは、歌が下手だと思う（＾＾；）

「新電子自治体推進指針」でオープンにしろと言ってけど、今ＰＣに入ってるWindowsは？

ここのサイト
「新電子自治体推進指針」（案）に対する意見募集
http://search.e-gov.go.jp/servlet/Public?CLASSNAME=Pcm1010&BID=145207029&OBJCD=&GROUP=
に、電子自治体の新しい指針（の案）っていうのが出ているみたい。

でね、関連ファイルの「意見公募要領（提出先を含む）、命令等の案」の
「新電子自治体推進指針」（案）（pdf）
の、９ページ（ＰＤＦ的には１３／５４ページ）の「(2) 共同化・標準化の一層の推進」
にこんな言葉が。。。
（以下斜体は上記「新電子自治体推進指針」（案）より引用）

また、関係者が共通に参照できるオープンな標準仕様や共通的な仕様、無
償又は低コストで再利用が可能なプログラムがある場合には、これを活用す
ることにより、効率的な電子自治体の構築を進めていくことが必要である。


WindowsやＯｆｆｉｃｅ、目のかたきにされてる？？（＾＾；）

でも、そんなこといわれても、いまパソコンに入っているWindowsをわざわざＬｉｎｕｘにするのもなあ（＾＾；）

JavaのSwingでフォルダ、ファイルダイアログを出し、フォルダ下を一覧表示

自分へのメモなので、たいした話ではないです。

---

■ファイルダイアログ、フォルダ選択ダイアログを出す

JavaのSwingでファイルダイアログ、またはフォルダ（ディレクトリ）選択ダイアログを出すには、JFileChooserをつかって、

　　　　　JFileChooser fl_dlg = new JFileChooser();

でできる。このあと、

　　　　　fl_dlg.setFileSelectionMode(JFileChooser.DIRECTORIES_ONLY);

で、セットしたモードにより、ファイルがえらべるか、ダイアログが選べるかきまる。
モードは、以下のとおり

　　　　JFileChooser.FILES_ONLY（デフォルト）
　　　　JFileChooser.DIRECTORIES_ONLY
　　　　JFileChooser.FILES_AND_DIRECTORIES

fl_dlg.showOpenDialog(f)で表示され（ここでfは親ダイアログ）
返り値は、以下のとおり
　　　　JFileChooser.CANCEL_OPTION
　　　　JFileChooser.APPROVE_OPTION
　　　　JFileCHooser.ERROR_OPTION
　　　　　 (エラーが発生したか、またはダイアログが取り消された場合)
そして、
　　　　File fl = fl_dlg.getSelectedFile();
で、選択されたファイル、フォルダが取得できる

---

■フォルダの一覧を出したい。

　　　File [] filelist = fl.listFiles();

で、そのフォルダの下のファイル一覧が取得できる。
なお、特定の拡張子などという場合は、引数にFilenameFilterを「実装したものを」つけて渡す。詳細については、後日、気が向いたら行う。

---

■ソース

　b1ボタンが押されたときに、フォルダーのダイアログを出して、選択されたフォルダの下のすべてのファイルを標準出力に出します。

	/*
	 * 	イベントリスナー
	 */
	private class RssMain_HandleEvent implements ActionListener
	{
		/*
		 * 	ボタンが押されたときの処理
		 */
		public void actionPerformed(ActionEvent e)
		{

			Object o = e.getSource();

			if ( o.equals(b1)== true)
			{
				//=======================//
				//	ファイルダイアログを出す
				//=======================//
				JFileChooser fl_dlg = new JFileChooser();

						//	フォルダのみに設定
				fl_dlg.setFileSelectionMode
                                          (JFileChooser.DIRECTORIES_ONLY);

				//=======================//
				// 開くが押された時		
				//=======================//
				if(fl_dlg.showOpenDialog(f)
                                        == JFileChooser.APPROVE_OPTION)
				{
					File fl = fl_dlg.getSelectedFile();
					File [] filelist = fl.listFiles();	//取得
					//	全部のパス表示
					for(int i = 0 ; i ＜ filelist.length ; i ++)
					{
					   System.out.println(filelist[i].getPath());
					}
				}
			}
		}
	}

（上記＜　＞　は本当は半角、なお、fは、Container f;と上のほうで宣言されていて、表示されている）

---

■参考にしたサイト
javax.swing.JFileChooser
http://www5b.biglobe.ne.jp/~taka_2/jclass/JFileChooser.html

と

Javaのテクニック
http://homepage1.nifty.com/d-hara/java.html

---

■ぜんぜんかんけいないけど。。
見つけたもの
JavaTM Advanced Imaging (JAI)
https://jai.dev.java.net/binary-builds.html

Java Advanced Imaging Image I/O Tools
https://jai-imageio.dev.java.net/

テストにしろ、プログラムにしろ、自動化できるための条件

　テストの自動化やプログラムの自動生成などにかんして、いろいろな意見が出ているが、そもそも、どういう状態になるとできるのかというのを、明確に書いていないとおもう。
　このような世の中だと、自動化ツールを作る人にも（一般人が過大な期待を寄せてしまうので）迷惑だと思うので、今日は「テストにしろ、プログラムにしろ、自動化できるための条件」をまとめてみたいと思う。

---

■自動化できる条件（１）出力内容が決まっていること

　あたりまえだけど、自動化するものを造るって言うことはシステムなので、つくる対象物、出力が決まっていないとできない。

　プログラムの場合、ソースプログラムなので明確なんだけど、テストの自動化の場合、キーボードやマウスイベントを記述して、実行するタイプ（MacのAppleScriptのSystemEventsみたいなやつ）のものなのか、それとも、単にバッチプログラムを書くのか？の問題がある。

　前者の場合、そういうものがなければできないし、後者の場合、GUIはできない。ただし、Webのサーバーの確認のさい、クライアントからさーバーにHTTPコマンドを送って自動的に実行したいなら、クライアント側から、テスト用ファイルを書き、それを読み込んで、HTTPをプログラムで発生させればよい。
　逆に、サーバーへの内容であれば、サーバー側で、クライアントから受けた内容をダンプすればいいんだけどね。

---

■２．出力に対する入力内容が、どこかに記述してあること。

　たとえば、画面であったら、画面のイメージがどこかにドキュメントとしてあるとか、

　DBアクセスであれば、あらかじめ入れておかなければいけないデータがシナリオなどにあらかじめ書いてあるとかということになる。

　これがないと、当然作れない。

---

■３．入力から出力までの手順が明確であること

　たとば、画面項目があって、テストを自動化したいとした場合、入力項目については、境界地チェックとSQLインジェクション、URLエンコーディングと漢字、外字について確認し、境界地については、。。。と、そのテスト内容がきまっていないと自動化できない。

　決まってない、分からない、考えてない内容は、自動化できない。

---

■４．具体的に、テストの自動化で言うと

　なので、テストの自動化で言うと、
シナリオに
・あらかじめ、DBにどのような値をセットしておくか
・バッチについての動きの内容
・GUIについて、どのように操作して、どうなるか

が書いてあれば、その言葉とプログラムを対応させることにより

・DBへのデータ挿入のためのSQLとそのSQLを動かすためのバッチなど
・バッチ処理部分、および、クライアントからGUIを入れた結果をサーバーへ送る場合、
　それをバッチにしたもの
・（キーボードのイベントやマウスのイベントが発生できれば）GUI部分

となり、とくにGUIに関しては、
・画面仕様書に項目の属性（テキスト、コンボボックス）がかいてあり、
・その属性に応じて、どのようなテストをするか決まっていて
・協会地などに関して、画面仕様書に指定があれば、
（キーボードのイベントやマウスのイベントが発生できれば）自動化可能である。


ただし、回帰テストに関しては、
一回テストしたときのデータをはじめの状態に戻せて、
そのテストしたときのイベントを全部保存しておいて、
その順番に再度自動的に、動かせる場合は、
仕様書などがそろっていなくても、その「再度自動的に、動かせる」ものをつかって、自動的に再テストができる。

---

こんなんまとめときましたけど、どうでしょう。。

イー・モバイル、HSDPAサービスを3月末スタート、でも、料金が。。。

ここのニュース
イー・モバイル、HSDPAサービスを3月末スタート
http://k-tai.impress.co.jp/cda/article/news_toppage/33265.html
によると（以下斜体は上記サイトより引用）


イー・モバイルは19日、携帯電話事業への新規参入によって2007年3月から開始するデータ通信サービスの内容を発表した。あわせて、シャープ製のWindows Mobile端末「EM・ONE（エムワン）」を披露した。


おお、とうとうはじめるのですね。。。
で、どんなサービスなの？

　3月31日にスタートする新サービス「EMモバイルブロードバンド」は、下り最大3.6MbpsのW-CDMA方式（HSDPA対応）を採用するデータ通信サービス。パソコンに接続した場合も含め、全て定額で利用できる。

ほー、ＨＳＤＰＡなのですね。。
定額っていうのは、いいけど、問題はその金額だよね。。

で料金は。。。

料金プランは、ノーマルな「データプラン（ベーシック）」、1年契約の「データプラン（いちねん）」、2年契約の「データプラン（にねん）」の3種類。いずれも月額利用料は5,980円。ただし、初期費用（端末価格含む）が契約期間によって異なっている。あわせて発表された「EM・ONE」の場合、「ベーシック」で契約すると、初期費用は95,000円、「いちねん」では71,000円、「にねん」だと39,800円になる。


初期費用、端末込みとはいえ、いちばんやすくて、39800円ですか。約４万円ですよね。
で、月々5980円、約６千円。。。

ウィリアムのいたずらには、無理です（＞＿＜！）

さらに。。


　またベーシックは、1年単位の継続利用割引「年とく割」を契約すると、月額4,980円で利用できる。「年とく割」の解除料は3,150円。「年とく割」は「いちねん」「にねん」では契約できない。「いちねん」「にねん」ともに契約期間が満了すると、自動的にベーシックへ移行する。なお、いずれの契約でも事務手数料2,835円が必要。

　また中途解約する場合、「いちねん」「にねん」は経過期間に応じた解除料がかかる。「いちねん」の場合、初期費用がベーシックよりも24,000円安いが、この価格が解除料になる。この解除料は1年経つとかからなくなる。つまり解除料は毎月2,000円ずつ減少することになり、契約直後の解約では24,000円かかるが、1カ月後の解約では22,000円に、2カ月後の解約は20,000円になる。

　「にねん」で解約する場合、「いちねん」と同じ形の解除料がかかる。ただし、ベーシックとの差額は55,200円だが、解除料は最大48,000円になる。7,200円は販売にかかる一時金のような扱いとなり、「にねん」契約時も毎月解除料は2,000円ずつ減少し、2年後には解除料がなくなり、ベーシックプランに移行することになる。

ふ、ふくざつ。。。！？

ソフトバンクのホワイトプランを見てしまうと、
ほかのが、どーしても高く見えてしまう（＾＾；）

バグが、とくに結合で収束しない場合は、設計ミスが多いかな？

　あ、そうそう、まえにバグ管理の話を書いたとき、引用した人のサイトに、
バグが収束しない場合の対策はあるのか？
http://blog.goo.ne.jp/wildriver_1977/e/47394ad4e947aef5f373ff9fa9f9d672
っていうエントリがあったのと、

　そのあと、業績修正のTIS、「失敗案件ではない。結合テストに想定外の手間」っていう話で、結合の話を書いたので、それについて、ちょっと。。

---

　バグが収束しないケースの多くは、デグレードによる発散で、これは、仕様変更にあるってことは前に書いた。

　では、仕様変更がどうして起きるのかというと、

・マネージャーや営業がなんでもほいほい受け入れる
　　→自分の成績を上げるため。それでSEが何人死んでも、
　　　自分は関係ない。

・担当した設計者の設計が甘い。
　さらに、マネージャーが経験不足で、その設計者の甘さを見逃してしまう。
　→各業務において、言わなくても、あらかじめ決めないといけない部分
　　というのがある。
　　　→この部分をユーザーは知らない場合があり、
　　　　そうすると、ヒアリングから抜ける
　　そこの部分を考慮しないで設計しているケース。
　　マネージャーも、その業界に詳しくないと、そこを考慮してないことに
　　気づかない。

・ヒアリングのときにうそが入っている
　→「ぜったいそんなことはない！」とかいっておいて、本当は、あるケース

・想定したプラットフォームや環境、方法では動かない。

なかんじ？

つまり、多くの場合、設計ミスや設計不足である。

---

　なので、設計からやり直さないと、バグは収束しない。

　そして、この設計の品質を高めたり、制約になってしまうのが、フレームワークになる。

　フレームワークがプログラム構造を決定し、取得イベント、タイミングを決めてしまうので、コレに反した動きをさせようとすると、どーしても、無理をさせて、バグになってしまう。（っていうか、ハリウッドの法則で考えると、ここに無理をさせること自体、間違ってるけど）

　でも、設計をやり直すっていう判断はふつうできないので、対処療法的になり、それが、さらなるバグをよび。。っていう構図になる。

---

　なので、ソフトウエアの品質というのは、フレームワークである程度きまってしまう。

　テストでカバーできる品質というのは、設計が間違っていない場合、その設計どおりにうごかすことが限界。

　設計が矛盾している場合（設計どおり作ったら動かない場合、設計どおり作っても足りない場合）には、テストが収束しない（動かないんですから、テストできませんぜ　＾＾；）

　まず、フレームワーク＋要素技術で、要求をどこまで満たせるかの品質のおおまかな枠組みが決まり、それを、設計で落とし込むことで、具体的に、要求を満たす品質がきまる。

　ということで、フレームワークから要素技術、そして主要コンポーネント開発と行く。。。

　あ、で、主線の話を書くっていうのを、前に書いた気がする。。。

　わすれてた。。またこんどになっちゃった（＾＾；）