Web２．０に、青木さやかは似合わない？

　しょーもないはなし。

　前に、ワールドカップ６４試合をアニメでほぼリアルタイム配信、iモードで、サイバーエージェントという話をかきましたけど、Web２．０っていうことで考えれば、ユーザーの見たい角度、見たいカメラで、見れるっていうのが、理想になってきますよね。

　この場合、ユーザーは２つの選択ができると思います。
１つは、カメラの選択
もう１つは、クローズアップする場所の選択

---

　カメラの選択っていうのは、本来、ディレクターさんが編集していた、カメラの切り替えを、ユーザー側で自分でできると。。はい、２カメさんに切り替えとか。。。

　そのためには、さすがに、全カメラデータをユーザー側に流しては大変なので、

　各カメラの画像を、１カメは、一番右上、２カメはそのとなり、３カメは一番右上、４カメは中段右。。。のようなかんじに、１画面に、全部のカメラ映像を合成して送り、ユーザー側で入力すると、指定されたカメラの映像を送ると。。そうすると、サーバー側は、２チャンネル分を送信すればいいことになると。。

　っていっても、まあ、こーいうのをやるには、IPマルチキャストが必要なのかな。。

　なので、これは、現実性低いかも。。。

---

　もう一つは、クローズアップする場所の選択。

　ハイビジョン映像で送信されてきて、見ているのが普通のテレビ。。。
　なーんてケースを考えると、これ、ある一部分を切り出して、そこだけ拡大しても、ふつうのテレビ（SD）くらいの品質になるんじゃないか・・・

　そーすると、ユーザーが、動画の一部分だけを切り出して、拡大してみるっていうのも、ありなんじゃないかと。。。

　もっとも、そーすると、女子バレーなんかは、うーん、そーいうところを切り出すか。。。
　なんてことになったりして、青木さやかじゃないけど、「どこ見てんのよ」って。。

　いや、どこをみろ！とサーバー側で規制されていたWeb1.0に対して、
　どこを見るのもユーザーの自由っていうのが、Web２．０の考え方なわけで

　そーいう意味で言うと、「どこ見てんのよ！」という青木さやかの考え方はWeb２．０に似合わない？？って、そーいうオチかい（＾＾；）

ExcelのＸＭＬソース作業ウィンドウを使って、ＸＢＲＬの必要部分だけを取り出して読む

　前回のExcelでＸＭＬを読んだ例を、東証のXBRL(財務諸表のXML)サンプルで試してみるでは、「ＸＭＬソース」の作業ウィンドウを使って読むやり方をやりませんでした。

　で、これを使わない場合、読み込めるけど、ぼろぼろになると。。

　逆に、「ＸＭＬソース」の作業ウィンドウを使ったら、どうなるかについて示してなかったので、今回、取り上げることにしました。

　これだときれいに読めますが、ちょっと操作に分かりにくい点があります（読み込んでも、読み込まれず、その後、ソースが更新されてないのに、更新する）。その点さえ、分かってしまえば、これでＯＫです。

　では、以下、「ＸＭＬソース」の作業ウィンドウを使ったＸＭＬの読み込み（サンプルとして、東証のＸＢＲＬを使用）を示します。

---

■操作方法
（１）ファイル→開くから、読み込むＸＭＬファイルを選択する
　　　以下の「ＸＭＬを開く」ダイアログが出るから、そしたら、
　
　　[XMLソース]作業作業ウィンドウを使用する

　　を選択する。
　　　

（２）「指定したＸＭＬソースは。。。」というメッセージがもし出たら、
　　　ＯＫをクリック（というか、ＯＫするしかない）

（３）右側に「ＸＭＬソース」ダイアログが出たら、今回使うのは、
　　　NetIncomePerShareなので、そこがくるまで、スクロールして
　　　そこがきたら、クリック。

　　　そしたら、適当なところ（今回はＡ１セルからはじめるので
　　　Ａ１セルに）へ、ドラッグアンドドロップ
　　　そうすると、下の図のようになる
　　　　→この時点でデータはまだ入っていない！
　　　


（４）メニューバーから
　　　　データ→ＸＭＬ→ＸＭＬデータの更新
　　　を実行する（下の図）
　　　


（５）すると、データが入ってくる。
　　　下の図のように、contextRefでThisYearDurationを選択すれば、
　　　それのみ（今年のみ）のものが選択されて表示される。
　　　

---

　と、こんな感じです。きれいに読めこめます。

　ってことで、今度、覚えていたら、東証のＸＢＲＬとＹＡＨＯＯ株価欄から、「手作業」でExcelを読み込む方法をやろうかなーと、いまたくらんじゃってます。

クラスの割り出しをワーカーさんに説明する方法として、いったんＥＲ図にするって言う手はアリかも？

　今日も、軽い話題を１つ。

　この前、アクティビティ図からユースケースを作って、それを文章化、具体化してシナリオとする。ここまでは書いた。

　でさらに、このシナリオ化の過程で、具体的にしないといけないので、その業務過程における、入出力データを明確にする必要があるだろう。
　とくに、出力となる成果物（出力帳票とか）は、システムを何のために作るのかを明確にしないといけないから、かならず出てこないとまずい。

　ということで、シナリオの中には、ユースケースに相当するプロセス（動詞）と出力となる成果物、業務にかかわるアクター（名詞）は、でてくる。このほか、各業務を説明するために、さまざまな名詞が、出てくる。

---

　で、次の工程として、じゃ、クラスを作りましょうっていうことになるが、前に書いたとおり、名詞は、クラスか、クラスの属性になるかわからない
動詞も、クラスになることもあるし、メソッドになることもある
じゃ、恣意的にしか、つくれないじゃん！えいやーと、勘でやったとしたら、人によって、いろいろ違ってきちゃわない？

　そもそも、こんなんじゃ、ワーカーさんに指示が出せない。

　っていう話になると思う。

　で、どーするか？

---

　実は、エンティティになるものは、クラスにしても、差しさわりない。
　（ただし、できちゃったエンティティを除く）
　っていう性質がどーもありそうだ（理由を説明すると、軽い話題どころか、このブログで、２、３回特集しないといけないので、今回は省略。あるとしてください）。

　なお、できちゃったエンティティというのは、ＲＤＢで多対多を認められないため、１対多にするために、エンティティを作成し、そのエンティティの属性値に、結局、外部クラスの主キーしか並ばないようなエンティティ、単純にで多対多の解消だけの目的のエンティティ。
　これは、エンティティと呼べるかどうか疑問なので、仮に「できちゃったエンティティ」と呼ぶ（一般名ではない。ウィリアムのいたずらが、今勝手に付つけた）

　で、エンティティは、ＥＲ図でできる。

　ＥＲ図を作成するには、正規形にすればいい。

　この場合、エンティティが最初の段階ではっきりしなくても、つまり、エンティティが最初の段階ではっきりしなくても、第三正規形の操作で、エンティティが抽出されてくるので、問題はない。

　むしろ、初めは少ないエンティティにしておいて、第三正規形抽出の過程で、エンティティを切り出してゆき、必要なエンティティ（＝クラス）を確定する。

なんで、

・成果物をエンティティとしてＥＲ図をつくり
・シナリオの名詞で、そのＥＲ図を補足し、
・ＥＲ図のエンティティをクラスにしちゃって
・シナリオの動詞をクラスそのもの、またはメソッドにわりふっちゃう

ってすると、手順的には、ワーカーさんに説明できそう。

---

　とすると、こういう指示でいいことになる。

（１）はじめに、出力する成果物を、かりにエンティティ候補としよう。
ただし、一覧とか表・票、情報、処理っていう言葉は除く
　受注一覧表→受注
　在庫一覧表→在庫
　商品一覧→商品

（２）この中で、名詞としたときに、物体とかでなく、かつ動詞にならないものは、
　とりあえず、候補からはずそう（第三正規形で出てくるかも知んないけど）
受注→受注する（動詞）ＯＫ
在庫→在庫するＸ→倉庫はあっても、在庫というものはないＸ
　　　（ちなみに、在庫は入出庫履歴と、
　　　　商品と倉庫の対応関係で表現される場合と、
　　　　在庫クラスを作ったほうがいい場合がある）
商品→動詞ではない→商品は、存在する（この場合、抽象概念でもＯＫ）

（３）これらを、エンティティとして出発し、出力の成果物を
　　第一正規形、
　　第二正規形、
　　第三正規形の処理をして、エンティティをあぶりだす。

（４）第三正規形までで、出てきたものに対して、シナリオで出てきた名詞を、上記のエンティティの属性になれば、それに入れるし、ならなかったら、新しい、エンティティを作ってとりあえず入れておく。その新しいエンティティに対して
　　第一正規形、
　　第二正規形、
　　第三正規形の処理をして、エンティティをあぶりだす。

（５）そのエンティティを仮にクラスとしてしまい、クラスを書く。
　　→できちゃったエンティティは、クラスにしてもよいし、しなくても良い。
　　　って、恣意的なのがいやな人は、どっちかに決める。

（６）シナリオで出てきたプロセスを、上記クラスの中のメソッドあるいは、クラスそのものとして、適当にわりふる。
　割り振れないメソッドがあったら、新しいクラスが必要か考えて、必要ならば、つくる。

---

っていうかんじだと、指示が出せそう。
ただ、ここまで、厳密に考えないで、いつもクラス図作っちゃうけどね。
でも、ワーカーさんに指示を出すとしたら、ここまで必要だよね。

もちろん、第一正規形、第二正規形、第三正規形の方法は、教えるものとする
（やりかたは、このブログのこのへんとか、このへんに書いた）

---

ただ、ＥＲ図ってＵＭＬにないよね。
（ＥＲ図からクラス図ができるなら、ＥＲ図は、確かに描かなくてもいいじゃんっていわれると、それはそうなんだけどね）。

うーん、でも、ふつうＥＲ図も書くのでＯＫ！ってことで（＾＾）

なお、ＥＲ図からテーブル定義の（Ｅｘｃｅｌで書く）設計書にいき、ここからテーブル定義やクラス作成は、自動化されてるよね。

なんで、こっからさきは、ウィリアムのいたずらの本職？
本当にワーカーさんの世界。
　
　

リアルタイムのアニメ中継、重なり判定が難しいそうだけど、サイバーエージェントはどーすんのかな

　ブログに前に書いた、ワールドカップ６４試合をアニメでほぼリアルタイム配信、iモードで、サイバーエージェントの話。

　これ、まさか、上から見た図で、サッカーコート全面を１画面で表示して、選手がすんげーちーさい状態なら、技術的には問題ないけど、まさか、それじゃー、見てる人がっかりになってしまうので、そんなこたーしねーだろー、普通に、選手１人１人のクローズアップもできるんだろー。。。

　そーすると、アニメでも、１人1人の位置関係を知らないといけないわけで、そーなると、その位置関係は、自動的に取り出せないと、間に合わないだろう。。

　で、自動的に位置を取り出しながら、選手１人１人をクローズアップ！のときに、気になるのが、 前のブログの同じコンテンツをケータイでもテレビでも適切に見せるもう１つの方法、NHK技研のAdapTV で書いた、AdapTVについて、技研公開で聞いてきた、サッカーシーンなんかでの、重なり判定。

　つまり、２人以上の選手がボールの奪い合いになって、重なってしまったとき、どのように重なっているのか（１人１人をクロースアップする場合、どちらが手前にいるか）を切り出すのが自動判定だと難しいそーな。

　この点を、どうやって判断しているのか？手動なのか、それとも、そこだけ実写にしてしまう？たしかに、手動って言うのはアリそうで、普通重なるのは、ボールのところだけだろうから、ボールを追っているところだけは、手作業で前後関係を修正できて、それ以外は自動切り出しっていうのは、アリかも？

　まあ、ちょっと、ここらへんが興味しんしん。

　ただ、これ、野球だとできませんな。。。
　乱闘シーンとか、だれがだれを殴っているかとか、わかんなそうだ（＾＾）

国際的に商品名をつけるとき役立ちそうな「世界の言語の中から似た音を探す」phonethica

　これ、広告代理店とか、企業で国際的に商品名を付ける人とかに役立ちそうだよなあ。。
　WBSのトレンドたまごだったかなあ？

　「世界の言語の中から似た音を探す機械！」

　見ましたかあ？みなさーん！
　これ、単なる展示物として、作っているけど、もったいなーい！！

---

　商品企画のとき、商品に名前を付ける際、その言葉が、他の地域でおかしな意味を持たないかどうかのチェックっていうのがあるじゃないですか！

　たとえば、きっこさんのきっこのブログの「亀ちゃんとエビちゃん」にあげられている、日産のホーミーとか（沖縄の言葉でセックスの意味だそうな）
　そんなことにならないように、外国語、とくに進出しそうな国の言葉で、おかしな言葉にならないかというチェックをする（と思う）。

　おお、このソフトは、それにもつかえるわけっていうか、
　まさに、そーいう機械ですよね（＠＿＠）！

---

　っていうことで、この機械、説明していた「遠藤拓巳」さんの名前でしらべてみた。
　そして、行き着いたのが、こちら

　どーも、phonethicaという名前で、IPAの未踏でやってるようだ
　phonethicaのページは、
　こちら　http://www.phonethica.net/

　そう、この写真の一番したのやつだよね！
　テレビでやってたの。。

　で、番組で、これを展示している、NTTの美術館といってたのは、
　NTT インターコミュニケーション・センター［ICC］
　　〒163-1404　東京都新宿区西新宿3-20-2
　　東京オペラシティタワー4階
　　フリーダイヤル 0120-144199

　で、これが展示してあるところは、オープンスペースのネットワークゾーン、
　このページ　http://www.ntticc.or.jp/Schedule/2006/Openspace/network_j.html
の下のほう、

Project Phonethica Installation "Rondo"

のやつです。

さー、広告代理店のかたがた、商品企画のかたがたは、れっつごーだね
（お前はいかんのかいって　＾＾；）