硫黄島生還者の手記が、映画「硫黄島からの手紙」の公開と同時にアクセス急増らしい。。

ここの話
硫黄島の激戦が克明に、生還者の手記をネットで公開。
http://www.narinari.com/Nd/2007017019.html
によると（以下斜体は上記サイトより引用）

アカデミー賞候補となった映画「硫黄島からの手紙」（クリント・イーストウッド監督）の大ヒットによって再注目されている硫黄島戦。日米双方で約2万7000人が戦死した太平洋戦争屈指の激戦だけど、2万933分の804の確率で生還した日本兵の手記がネットで公開され、話題になっているのだ。

手記を遺したのは、31歳の時に陸軍工兵兵長として硫黄島に配属された高知県須崎市出身の故高橋利春さん。硫黄島戦で背中を撃たれる重傷を負いながら米軍の捕虜となり、1946（昭和21）年2月に帰還した。その後、高知県土佐清水市の清水署に勤務した後、1986年に74歳で永眠した。


で、その手記を、お孫さんの藤原貴宏さんが公開したそうだ。

で、


藤原さんのホームページは、「硫黄島からの手紙」の公開と同時にアクセス数が急増。1日1万2000件を記録した日もあったのだそう。


ウィリアムのいたずらは、映画も見てないし、詳しく知らないので、
てっきり硫黄島の戦いは、日本人殲滅で、生きているのはアメリカ人のひとだけだとおもってたので、そんな記録が残ってるなんて、ビックリ（＠＿＠！）

こりゃー、みなきゃですよね！

ちなみに、その公開されている手記のサイトは
ここ　http://www5f.biglobe.ne.jp/~iwojima/

こーいうことがきっかけになって、ネット上に戦争のときとか、
いろんな自分たちの体験談が自分のページやブログとしてアップされたり
するかもしれませんね。今後。。
（たとえば、原爆のときの様子などを、記憶をうしなわせないためにというので、
　広島、長崎の人たちが、自分たちの体験談をアップするとか。
　ある団体がまとめるのでなく、個人個人がサイトをつくってかくと。。
　それを誰かがまとめサイトかするとか。。）

OpenOfficeで、データベース(Base)の内容を、表計算(Calc)に書いて印刷するマクロ

　OpenOfficeの話で、いままで印刷とデータベースの話を書いたので、２つあわせて
データベース(Base)の内容を、表計算(Calc)に書いて印刷するマクロについて取り上げてみます。

---

■仕様

●C:￥temp￥テスト.ods（￥は、本当は半角）にあるOpenOffice Calc（表計算）の"テスト"というシートを開き、

●データベース名が"テスト用"という名前の、データベースをアクセスして、
"Select * From 顧客テーブル"
を実行して、顧客テーブルの内容を受け取り

●DBの内容を
　　１項目目をA桁、
　　２項目目をB桁、
　　３項目目をC桁、
　　４項目目をD桁、
に、１行目から、１レコードづつ、順に、上記の「テスト」というシートに書いて
印刷する

---

■ソース

ソースはこんなかんじです。

sub Main
	dim document   as object
	dim dispatcher as object
	dim args1(1) as new com.sun.star.beans.PropertyValue
	Dim oDoc as object
	
	'**** データベース関係
	Dim DatabaseContext as object
	Dim DataSource as Object
	Dim Connection as Object
	Dim Statement as Object
	Dim ResultSet as Object

 	'**** スプレッドシートを開く
	sURL = ConvertToURL("C:￥temp￥テスト.ods") 
	oDoc = starDesktop.loadComponentFromURL(sURL,"_default",0,Array()) 

 	'**** 値を設定する
	Sheet= oDoc.Sheets.getByName("テスト") 	'	シートを選ぶ

	REM  *****　データベースのコネクション　 *****
	DatabaseContext=createUnoService("com.sun.star.sdb.DatabaseContext") 
	DataSource=DatabaseContext.getByName("テスト用") 


	REM  *****　SQLの実行　 *****
	Connection = DataSource.GetConnection("","")
	Statement = Connection.createStatement()
	ResultSet= Statement.executeQuery("Select * From 顧客テーブル")

	REM  *****　レコードをワークシートに設定 *****
	If  IsNull(ResultSet) Then
		MsgBox("レコードがありません")
	Else
		i	=	0
        While   ResultSet.next
			Cell =Sheet.getCellByPosition(0,i)	
			Cell.setString(ResultSet.getString(1))		
			Cell =Sheet.getCellByPosition(1,i)	
			Cell.setString(ResultSet.getString(2))
			Cell =Sheet.getCellByPosition(2,i)	
			Cell.setString(ResultSet.getString(3))
			Cell =Sheet.getCellByPosition(3,i)	
			Cell.setString(ResultSet.getString(4))
			i = i + 1
        Wend
	End If

	'**** 印刷
	mPrintopts = oDoc.getPrinter() 
 	mPrintopts(0).Name = "CopyCount"
 	mPrintopts(0).Value = 1		'１個出力
 	oDoc.Print(mPrintopts())
end sub

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

松丸アナとプラナリアで、目が不自由な人でも、初めての場所でも自由にいける？

　で、さっきの場所を分かる方式としてのGPSとプラナリアの話の続き。

　昨日、松丸アナが、トレンドたまごで
ブルっとナビゲーション
http://www.tv-tokyo.co.jp/wbs/2007/02/01/toretama/tt.html
というのをやっていたのですが、あれ、目が見えない人とかが、いろんな場所にいくのに役立ちそうな気配。

　ちなみに、どんなものかは、上記のところにあるムービーで、松丸さんのついでに見ていただければわかるとおもうけど、行きたい方向などに、引っ張ってってくれるというもの。

---

　GPSと組み合わせてしまうと、細かい地形、たとえば、どっちの道にいくべきかとか、デパートの売り場のような、細かいところや、階が問題になるようなところは使えない。

　しかーし、下山せいらさんのプラナリア方式と組み合わせれば、つまり、前に書いたとおり

１．ICタグでも、音のバーコードでも、あかり通信でもいいから、その場所をうめこみます。
２．曲がり角では、どっちにいったら、どうっていうように書いておきます。
３．で、こういうICタグを何メーターかおきに置くようにする。
４．どっかに行きたい人は、サーバーにアクセスし、道順を聞く
５．そーすると、ケータイとかが、その道順に沿って、誘導してくれる

ってすれば、たとえば、初めにどっかの駅にいたとして、市役所に行きたいとすれば、

・駅のICタグなり、駅の音声に音のバーコードが入っていて、
　　そこで駅のどこ！ってわかるようにして、

・そっからサーバーにアクセスして（たぶん、ケータイに音声で言うんだろうなあ。。）
　なんとか市役所っていうと、

・そこまでの経路・・この場合だと駅からバス停に乗るまでの行き順、
　バス停から降りてから市役所までの行き順を、
　このICタグに入っている順番で、教えてくれると。。

・で、この機械をもっていると、まず、自分の移動する方向に、この松丸アナの機械
　が引っ張って言ってくれて、曲がり角になると、ICタグに、何度曲がるとどの道って
　かいてあるから、それと受け取った行き順を比べて、どの方向に曲がればいいかもとめて、
　それを、この機械が引っ張ってくれると。。

・バスに乗って降りた後でも、こんど、降りた先でも、このICタグがあれば大丈夫！！
　みたいな。。（＾＾；）

おお、松丸アナが紹介しただけあって、さすがです！
（べつに、目が見えない人向きでなく、目が見える人がつかっても、よさそう）
松丸アナと、プラナリアの下山せいらさんの発見したことをあわせると、
いろいろ発展しそうです。この機械！！

（って、この機械をつくっているのは、松丸アナじゃなくって、ＮＴＴ 先端技術総合研究所なんだけどね　＾＾；）

利用者の出力から業務を分析していく手順（その５：ヒアリングとの関係）

　利用者の出力から分析して、DOAでも、オブジェクト指向でも、どっちにでも展開して、プログラムまで落とし込める業務をまとめたシートと、入出力についてまとめたシートを作る方法について書く、シリーズ（になってしまった）利用者の出力から業務を分析していく手順の５回目です。

　今回は、いままでやってきたことと、ヒアリングとの関係についてです。
　とくに、ヒアリングについては、要求をヒアリングしてから、DOA,オブジェクト指向の各種の図に展開するまとめかたというところで、書いています。それとの関係です。

---

■ヒアリングの場合
　上記に挙げたところでは、こんな風にまとめていました。

（A）要求をヒアリングして、その要求に関連する業務を挙げる
（B）「業務をまとめたシート」を作成し、業務の上下（親子）関係を決める
（C）各業務をヒアリングし、「業務をまとめたシート」を埋めたり、追加する
（D）同時に、現在の帳票、画面から、「入出力についてまとめたシート」をうめる
（E）「業務をまとめたシート」の入出力から「入出力についてまとめたシート」を補完する
（F）確認する

ただし、順番は、あとで分かりやすくするため、ABCDにしてあります。

で、いままでの利用者のところでは、こうやって書いていました。

（１）利用者を体系づけて分けます
（２）今回対象の利用者について、システム利用（入出力）場面を考え、業務シート作成
（３）利用者が利用する一場面をとって、入出力を、まず出力から確認します
　　（３－あ）まず、外部に対して出力になっているものを取り上げます。
　　（３－い）その外部出力の具体的内容を考え、入出力のシートに書きます。
　　（３－う）その外部出力を出すために必要な情報が、入力されているかどうか、確認
　　（３－えお）（３－う）までで、入出力のシートはできているので、それに対応する
　　　　　業務シートがなかったら追加、完成させます。
（４）利用者からの入力を受け取ってから、利用者への出力まで、
　　　システム内の業務を追加します
　　（４－あ）まず、システムトップを書き加える
　　（４－い）中間のアクティビティとデータ加工を追加する
　　（４－う）出力から考えて、足りない部分のアクティビティがないか、確認する
（５）利用者への出力ごとに、シナリオをつくります
（６）利用者の範囲を広げていきます。

　なお、（４）に関しては、それを説明したところから、付け加えました。

　上記２つの体系が、どのようにあわさるかについて書きます。

---

■あわせたかんじ

あわせると、こうなります。

＜＜要求分析段階＞＞
・要求を出す（ここ）
→「(A)要求をヒアリングして、その要求に関連する業務を挙げる」が、コレに相当します。

＜＜ヒアリング準備段階＞＞
できれば、ヒアリング前に、入出力関係の資料をもらっておいて、
ここまでやっておきたい（でも、できなきゃしょうがないけど。。。）

（１）利用者を体系づけて分けます
（２）今回対象の利用者について、システム利用（入出力）場面を考え、業務シート作成
（３）利用者が利用する一場面をとって、入出力を、まず出力から確認します
　　（３－あ）まず、外部に対して出力になっているものを取り上げます。
　　（３－い）その外部出力の具体的内容を考え、入出力のシートに書きます。
　　（３－う）その外部出力を出すために必要な情報が、入力されているかどうか、確認
　　（３－えお）（３－う）までで、入出力のシートはできているので、それに対応する
　　　　　業務シートがなかったら追加、完成させます。

→ここで、入出力は完成させます。
　つまり、ヒアリング前に、入出力を抑えておくということです。
　そうしないと、ヒアリングのときに入出力がもれたり、
　言ってることがちんぷんかんぷん
　。。はひどいけど、誤解したりします
　（営業報告が月ごとだと思ったら日報だったとか）


＜＜ヒアリング＞＞
・ヒアリングする。とくに、入出力の関係について、相手の言っている話に、矛盾や
　漏れがないか（事前に（３）までで確かめているはず）、
　自分の想像と、ぜんぜん違うことをしているとかないかを、確認する

＜＜ヒアリング後＞＞
（４）利用者からの入力を受け取ってから、利用者への出力まで、
　　　システム内の業務を追加します
　　（４－あ）まず、システムトップを書き加える
　　（４－い）中間のアクティビティとデータ加工を追加する

→ここが
　　（B）「業務をまとめたシート」を作成し、業務の上下（親子）関係を決める
　　（C）各業務をヒアリングし、「業務をまとめたシート」を埋めたり、追加する
　になります。ヒアリングの内容をもとに、業務をまとめたシートを埋めていきます。

●なお、ここで、前の手順では書かなかった
（D）同時に、現在の帳票、画面から、「入出力についてまとめたシート」をうめる
（E）「業務をまとめたシート」の入出力から「入出力についてまとめたシート」を補完する
　が入ります。

　つまり、入出力について、ヒアリングのときにはじめて知った（＠＿＠！）とか、
　矛盾を追及してきたら、出てきた！っていうのがあります。
　そいつを書き加えます。で、入出力を完成させます。

　　（４－う）出力から考えて、足りない部分のアクティビティがないか、確認する
→ここが
（F）確認する
　になります。  

＜＜シナリオ作成など＞＞
（５）利用者への出力ごとに、シナリオをつくります
（６）利用者の範囲を広げていきます。

こんなかんじです。
つまり、大きくまとめると、

●要望を聞く

●ヒアリングする前に、事前準備として、入出力関係はもらっておいて、
　一通り、確認して、まとめておく
　→ヒアリングのとき、相手の言っていることが入出力レベルで確認できるくらい
　→ここからどんな業務がありそうで、ヒアリングのとき、何を聞くかまで
　　考えられれば、ベスト！

●ヒアリングする
　入出力ベースに一連の動作を確認する
　→そのときヒアリング前の入出力で、もれていたら追加する

●シナリオの形でまとめる
　理解しているかどうかまとめる

ってかんじになります。

　問題は、事前準備です。この準備がないと、結局、お客さんのいっていることをうのみにすることになり、おきゃくさんが、言い忘れたことがあったり、余計なこと（他の部署の話を想像で言う、上司が理想論を語るなど）を言われると、仕様に矛盾が出て、仕様変更が頻発になり、デスマーチになったりします。

---

　ってかたちですかね、だいたいのところは。。。

場所を分かる方式としてのGPSとプラナリア

　ちよっと、あとの話で使いたいので、前フリの話

---

■場所をわかる－１．GPSの利用

　居場所を分かる方法として、一般的に使われているのはGPSです。
　GPSなら、ケータイがあれば、緯度経度もわかるし、ケータイの場合、（GPSだけでなく、基地局情報などもあるけど）高度まで指摘してくれる場合もあります（GPSケータイで、GPS入りで写真を撮ると、Exifファイルの中に、高度まで入ってくる）。

　でも、問題もあります。
　GPSなので、電波の届かないところはダメです。
　ウィリアムのいたずらが確かめた結果、緯度経度は、まあまあなんだけど、高度はうーん、どーなのどーなの？？でした（正しいのかなあ？？）

　ってことで、たとえば、駅の構内とか、百貨店の売り場などを正しく誘導するなどというのには、使えなさそうです（階＝高度が性格に、場所が少なくとも数十メートルレベルで正確に、かつ鉄筋の建物の中で、蛍光灯がついている状態で、わからないといけない）。

　一方、車など、速く走っているところや、砂漠のど真ん中のように、何も目印がないところでは便利です。

---

■場所をわかる－２．プラナリア方式
　では、駅の構内とか、百貨店の売り場などを正しく誘導するなどというのには、どうしたらいいでしょう。

　これは、やっぱり、下山せいらさんがプラナリアで発見した方法の応用でしょう。
　プラナリアは目が見えなくても、えさにありつけます。なぜなら、化学物質をたよりにあるいていっているからです。

　同じように、

１．ICタグでも、音のバーコードでも、あかり通信でもいいから、その場所をうめこみます。

　たとえば、ICタグに、

　　　　東京都千代田区永田町1-7-1　2F-10

　とか、埋め込んで、これを国会議事堂（住所は東京都千代田区永田町1-7-1）の２階のNo10っていうところにおいてあるとする。

２．曲がり角では、どっちにいったら、どうっていうように書いておきます。

　たとえばさっきの例だと、２階の１０番のところから、まっすぐいき、曲がり角のところで
　右９０度にまがると、１１番、直進すると１２番、左９０度に曲がると１３番になるとすると

東京都千代田区永田町1-7-1　2F-10　90:11 0:12 -90:13

　とかかいてあるとする。

３．で、こういうICタグを何メーターかおきに置くようにする。
　　（曲がり角には絶対）

４．どっかに行きたい人は、サーバーにアクセスし、道順を聞く

　たとえば、国会議事堂の玄関（これが１階の１番だったとする）に居る人が、参議院議場（これが、かりに２階の９番だったとする）にいきたいとすると、
　現時点の場所をICタグでスキャン、サーバーに、行きたい場所を伝えると（音声入力でも、ホームページから選ぶでもなんでもいいけど）1F-1:1F-5:1F-U:2F-U:2F-3:2F-5:2F-9とか、道順を示してくれて（Uは階段、ちなみに、数字は、テキトーでたらめです）
　　　　　
５．そーすると、ケータイとかが、その道順に沿って、誘導してくれる

　まあ、音声誘導でもいいけど、この誘導の仕方が。。。

　話したい内容なのだ（＾＾）

YouTubeユーザーの3分の1が「TV視聴時間が減った」米調査。でもね。。。

アメリカの話らしい

ここのニュース
YouTubeユーザーの3分の1が「TV視聴時間が減った」――米調査
http://headlines.yahoo.co.jp/hl?a=20070131-00000030-zdn_n-sci
によると（以下斜体は上記ニュースより引用）

YouTubeを頻繁に利用する人の32％は、YouTubeに時間を費やす分、テレビの視聴時間が減ったと回答している。

ほー、アメリカのみなさんは、そんなに見てるんですか。。

でもね。。

すべてのビデオに広告が挿入された場合、ヘビーユーザーの73％が、YouTubeの利用度が減るだろうと答えているのだ。31％は「かなり減る」42％は「多少減る」としている。


そんなに、広告ってじゃまですかねえ（＾＾；）
まあ、広告入ったらテレビと同じジャンって言われれば、そうなんだけどね。。。