「マーボー豆腐は飲み物です」、終わっちゃうみたいです（；＿；）
ここのブログ
報告。芸能人ではなく芸NO人だから挑戦したい事。決めた事。
http://ameblo.jp/wakatsuki/day-20071231.html
の最後のほうに（以下斜体は上記サイトより引用）
と共に、本日を持ちまして《マーボー豆腐は飲み物です。》を終了させていただきます。
えー（＠＿＠！）
年の最後に、重大ニュース！！
ということで、年内に書きたかったので、とりあえず、ここでアップ
「マーボー豆腐は飲み物です」、終わっちゃうみたいです（；＿；）
ここのブログ
報告。芸能人ではなく芸NO人だから挑戦したい事。決めた事。
http://ameblo.jp/wakatsuki/day-20071231.html
の最後のほうに（以下斜体は上記サイトより引用）
と共に、本日を持ちまして《マーボー豆腐は飲み物です。》を終了させていただきます。
えー（＠＿＠！）
年の最後に、重大ニュース！！
ということで、年内に書きたかったので、とりあえず、ここでアップ
シリーズ「ネットワークのキーワードまとめ」の続き。
前回、相手のルーターに行くまできましたので、今回は、相手側の処理
■相手側のルーター
＜＜物理層＞＞
DSLなど線から送られてきた信号を、マンチェスター符号化などにより、
0と1にして、フレームを作ります。
↓
＜＜データリンク層＞＞
受け取ったフレームのヘッダ部分をはずして、パケットにして、
ネットワーク層に送ります。
↓
＜＜ネットワーク層＞＞
送り先のIPアドレスをみて、
そのサーバーに送るMACアドレスがわかっていれば、データリンク層へ
わかってなければ、ARPを使って、IPアドレスからMacアドレスを割り出し、
データリンク層へ
↓
＜＜データリンク層＞＞
サーバーのMACアドレスを宛先MACアドレスとし、それ以外に必要な情報も付けて、
フレームを作成します
↓
＜＜物理層＞＞
データリンク層で送信するフレームを、マンチェスター符号化
などにより、0と1から電気や光の変化に変えて、線に流します。
■サーバー（相手からの情報を受ける）
＜＜物理層＞＞
データリンク層で送信するフレームを、マンチェスター符号化
などにより、0と1から電気や光の変化に変えて、線に流します。
↓
＜＜データリンク層：NICカードなど＞＞
受け取ったフレームのヘッダ部分をはずして、パケットにして、
ネットワーク層に送ります。
↓
＜＜ネットワーク層：サーバーOS＞＞
パケットを受け取り、指定された宛先ポートに対して、
トランスポート層へデータを送ります
↓
＜＜トランスポート層：サーバーOS＞＞
TCPの場合、3ウェイ ハンドシェークを行い、シーケンス番号を、
取得できます。このシーケンス番号にもとづき確認応答をしながら、
必要なデータ（セグメント）を取得していきます。
実際には、スライディングウィンドウを利用して、ある程度のまとまり
分、データを取り込みながら行います。
↓
＜＜セッション層：アプリケーションプログラム内＞＞
アプリケーション側では、ここにあるように
１．アプリケーション起動時に、そのポートを開いて、
データが送られてこないか、ずーっとまっています。
ServerSocket serverSocket = new ServerSocket(ポート番号);
２．データが来ると、データを受け取り、コネクション（別の相手ごとに１コネクション＝接続
となる）ごとに、別のプロセスを発生させて、
そこで入出力できるようにします。
これによって（別プロセスになるので）同時に複数の通信が可能になります。
Socket socket = serverSocket.accept();
TestThread tr1 = new TestThread();
tr1.setSocket(socket);
tr1.start();
↓
＜＜プレゼンテーション層：アプリケーションプログラムのスレッド内＞＞
セッション層で、コネクションごとに送られてきたデータに対して、
コード変換などをかけます。
InputStream is1 =socket.getInputStream();
InputStreamReader ir1= new InputStreamReader(is1);
↓
＜＜アプリケーション層：アプリケーションプログラムのスレッド内＞＞
プレゼンテーション層で変換したデータを受け取り、解釈します
BufferedReader br1 = new BufferedReader(ir1);
このbr1の内容が、送信された内容です。
すなわち、ここで書いた、
GET / HTTP/1.0
（1.0のあとに、改行２つ。）
が受け取れます。
次回は、受け取ったデータをもとに、サーバーから送信します。
ここのニュース
体感型ゲームより本物の運動を＝子供のエネルギー消費量を調査－英大学チーム
http://headlines.yahoo.co.jp/hl?a=20071230-00000046-jij-int
によると（以下斜体は上記サイトより引用）
テニスやボクシングなどの体感型テレビゲームのエネルギー消費量は、従来型ゲームの約1．5倍だが、本物のスポーツに比べると大幅に低いことが分かった。
まあ、そりゃーそーでしょうな（＾＾；）
体感型ゲームは本物のスポーツの代わりにならず、毎日1時間は活発な運動をした方がよいと勧めている。
いやー、そりゃーわかってるんですけどお。。。
本当の運動ができない（体力的に大変とか）人が、やるんじゃあ。。
身体に動きを計測するセンサーを取り付け、米マイクロソフト社の従来型ゲーム「XBOX360」の車のレースをした後、任天堂「Wii（ウィー）」のボウリング、テニス、ボクシングを立ってリモコンを振る形で15分間ずつ行った。
その結果、平均エネルギー消費量（体重1キロ・1分間当たり、単位キロカロリー）はじっとしているときの19に対し、レースが30、ボウリングが46、テニスが48、ボクシングが47だった。
ボウリングもボクシングも倍以上じゃん！
ってことは、何もしないよりかは効果あるってこと？？
むしろ、そのくらいの運動のほうが、ちょうどいいんじゃないかなあ・・
逆に、Wiiで、「糖尿病予防のための運動」とかで、毎日軽い運動ができるとか
そーいうのが出てくることに期待するなあ・・
運動量は少なくても、時間を長くすれば、効果あるんじゃないかなあ？？
土日シリーズ「いろんなコンピューター言語の覚え方」、
前回までで、いろんなコンピューター言語の覚え方のお話は終わりました。
今回は、このシリーズのまとめとして、結局、一般的に「コンピューター言語」は何を覚えるべきで、どうして、それを覚えれば、言語が覚えれるのか？ということについてです。
■結局、なにを覚えればいいのか？
今まで覚えてきたことをまとめると、
・定数について
・変数について
→型について
・関数について
→型にもとづき、その型にあった処理
→型から型への変換
→入出力
・型における比較など
この、定数、変数、関数、比較など（述語とします）の４つをみて、さらに、それらを利用して、条件式（論理式）をもとに、ジャンプ（条件と無条件がある）、繰り返しなどの制御文を考えました。
そして、プログラムを書く段階になって、Cのように、関数、変数ばーん！と書いていいものもあるし、Javaのように、定数、変数、関数（＝メソッド）をクラスというまとまりの中で書くものがありました。つまり、書式というものが重要になってきます。
ということで、
ある言語を取得するとき
（１）（定数、変数、関数、述語）を、型という切り口で整理しながら学び、
（２）それに論理式をくわえ、制御文とそれ以外の命令について、処理の流れを学び
（３）クラスなどのまとまりを確認しながら、書式について学べばよいということになります。
■なぜ、この順序なのか―言語の一般化
じつは、このような展開で並んでいるプログラム言語の本は多いです。
その理由なのですが、これが、形式言語の体系に結びついているからです。
上記（１）が、プログラム検証論のP55、「形式的理論の語彙」の四重対＜変数、定数、関数記号、述語記号＞に相当します。
そして、（１）は、項であり、論理式と合わせて、項と論理式、つまりP59にある<Term(V),Fml(V)>が（２）に相当し、そこに書かれているように、これで、語彙Vから定義される言語となります。
しかし、言語はこのように定義されても、実際に書くには、どこから実行されるか、どのように関数をまとめるかの知識が必要なので（３）がいることになります。
実際に言語を比較するには<Term(V),Fml(V)>が重要で、ここを考えないといけないのですが、これだけやっても言語は書けないので、書き方である、構文、つまり（３）から入ります（Hello Worldから）。
で、逆に言うと、これでかけてしまうと、一般的に学ぶことをしないで、ふつうは参考書を見ながら、必要なところからテキトーに覚えていってしまうので、結局１つの言語を覚えるのに時間がかかるし、ほかの言語との比較が、ある程度覚えないとできないという結果になります。
これが、いろんなコンピュータ言語を覚えるのに、妨げになってしまっているのかもしれません。
ということで、このシリーズは、これでおしまい。
２０年位前、１９８０年代終わりごろから、最近まで、ソフト業界とかその周辺の変遷について、特にソフト開発の立場を中心に見て行く、土日シリーズ「失われた２０年－ソフト業界は変わったのか？」その第２５回目。
いままでで、その変遷をふりかえってきました。今日は、「で、結局、ソフト業界は変わったのか」ということについてです。
■ネットについては、たしかに変わった
ネットについては、たしかに変わりました。
さっきのNetscapeのはなしもあるけど、昔は、NetWearのLANやパソコン通信だったのが、インターネットがでてきて、一挙に別次元の世界に変わっていきました。
このインターネットも今後、どのように変わっていくのか、まだまだ期待がもてそうです。
（期待しすぎ・・ ＾＾；）
■開発の分野は？言語は確かにいろいろ出てきたけど
では開発の分野は？というと、言語は確かにいろいろでてきました。
COBOL／Fortran／PL1からC、C++、Java、perl,PHP,Ruby、クライアントではjavascriptと
まあ、いろいろ変わってきたのですが、逆な言い方をすると、決定打があるわけではない。
そして、今後も言語が生まれては消えしていくんだろうけど、決定打が出ない理由である、言語として、なにを表現すればOKなのか？という部分がはっきりしていないと思う。これさえ決まってしまえば、それを表現する表現力のある言語を開発すればいい。
いくつかの言語が必要になるだろうけど、その分野においては、その言語で決まり！っていう形になるだろう。
で、これをはっきりさせるには、世の中の仕様の大枠を決定してしまえばいいんだろうけど問題は。。
■開発方法論に関しては、発展したのか？
この世の中の仕様の大枠を決めるための、開発方法論という点について考えると、はたして、発展したのだろうか？
構造化設計がでて、オブジェクト指向がでて、アスペクトにいき、アジャイルにいった。
しかし、では、構造化設計やオブジェクト指向は、仕様に対して、どこまで表現でき、それをコンピューター上に、どのように、落とし込むのか、どこまで落とせるのか？を明確にしているとはいいきれない。どのように落とし込むのかについては、たしかに「方法論」というのだから、きまっていなければ話にならない。しかし、どこまで表現できるのか、表現したものが正しいのかという論証は全く行っていない（DFDは多少やっているけど・・）。
これでは、バグが出てきて、当然だ。なんたって、書いた仕様書やプログラムが正しいことが論証できないのだから。
■この点において、失われた２０年といえる。
この論証は、数学を援用して行う。
ホーア論理やダイクストラの検証論が、かつて出てきたわけだが、それを応用し、論証していくことになるだろう。
このプログラムの検証論と開発方法論を結びつけるという分野は、１９７０年代からいままで、まったくやられていなかった。といっていいだろう。
つまり、いろんな方法論は出ては消え、出ては消えしてるけど、その方法論を使って、正しいプログラムが書けるという保証もないし、そのためには何をしたらいいかという制約もはっきりさせていないという状態が、２０年以上も続いたことになる。
これじゃあ、バグバグシステムが量産されたって無理はない。なんたって、ちゃんとしたシステムができる（数学的）裏付けはないのだから。
＊ただし、ハードのほうでは、すでに数学的検証に基づいた開発は行われている。
■この失われた２０年が、今、かわろうとしているのかもしれない。
しかし、この辺の分野、数学的レベルでの論証をベースにおいて、システムを構築していき、裏付けをもって開発し、どこまでの範囲で正しいと言い切れるのかを吟味していく分野は、最近始まろうとしているのかもしれない。
たとえば、UMLのクラス図を論証していく、兼岩 憲 氏の「UMLクラスダイアグラムの矛盾検証」などがあげられる。
この辺の数学的論証という立場や、計算理論、計算可能性と、各種開発方法論、言語などが結びついてくると、この言語、方法論では、何が表現できて、表現した内容が正しいのか、正しくないのかについて、体系化・さらには自動化ができてきて、あらたなブレークスルーが起こるであろう。
最後の結論が、論理のジャンプが激しすぎてしまいました。
もう一度、別の機会に説明します（年明けにでも）
ということで、このシリーズは、今回でおしまいです。
ここのスラッシュドットニュース
Netscapeブラウザ、開発・サポート終了へ
http://slashdot.jp/it/07/12/29/0225242.shtml
によると（以下斜体は上記サイトより引用）
TechCrunch Japaneaseの記事によると、かつてはMicrosoftとブラウザ戦争を繰り広げ、経営難からAOLに吸収された後も細々と公開されていた、あの「Netscape Navigator」がついに開発終了となるようだ。
うーん、時代ですなあ・・・
Netscape Navigator VS IEなんて、ほんと、only yesterdayってかんじだけど・・
（なこたーねーか ＾＾；）
Google Code ディスカッション グループのメッセージによると、
「Google Gears」についてが話題だった、「Googleデベロッパー交流会」の第4回の内容が、公開されているそうな・・
ここ
Google デベロッパー交流会 ( 第 4 回 ) - Vol.1
http://googlejapan.blogspot.com/2007/12/google-4-vol1.html
そーいえば、ウィリアムのいたずら、交流会のはじめのほうのコトは書いたけど、
パネルディスカッションの様子をまだレポートしてませんね（＞＿＜！）
・・・気が向いたら、今度書きます。
シリーズ「ネットワークのキーワードまとめ」の続き。
前回、ローカルのルーターから、プロバイダへ出るところまできたので、
今回は、相手のルーターに行くまで
＜＜プロバイダ＞＞
プロバイダでADSLなどで受けた信号は、
同一プロバイダ内なら、そちらに信号がわたり、
それ以外なら、相手先プロバイダや、
MEX（メックス）や、JPIX(日本インターネットエクスチェンジ)などの
インターネットエクスチェンジへ送られます。
このとき、ルーティングにおけるあるまとまりがあって、そのまとまりを
自律システム（AS）といいます（くわしくはここ参照）。
当然、いくつかのプロバイダやインターネットエクスチェンジを経るということは、
AS間での通信も行われるわけなのですが、このAS間でのルーティングを行う
ルーティングプロトコルたちが、(前回出てきた）EGPｓで、EGPｓのプロトコルの１つ
が、BGPです。
（一方、AS内で使われるルーティングプロトコルたちが、前回やったIGPｓ）
＜＜インターネットエクスチェンジ＞＞
いくつかのプロバイダのデータがあつまってくるところです。
日本国内には、いくつものIXがあり、また、地域IXもあります。
＜＜海外に出られるプロバイダ＞＞
海外にデータを送るとき、最終的には、海外と接続しているどこかのプロバイダにデータがいき、
そこからデータが海外へ転送されることになります。
＜＜海外のプロバイダ＞＞
で、その国のプロバイダに入って、そこから、いろいろへて
（外国にもIXがあり、途中、そーいった外国のIXにパケットが送られたりもして）
＜＜相手が利用しているプロバイダ＞＞
相手が利用しているプロバイダから、相手先にパケットが送られます。
次回は、相手先のルーター
ここのＳｏｕｒｃｅＦｏｒｇｅ．ｊｐみたいよ
TERASOLUNAフレームワーク
http://sourceforge.jp/projects/terasoluna/
って、何の話？・・・ですよね。
説明しよう。
日経ソリューションビジネス ２００７年１２月３０日号の８２ページに、
「ＮＴＴデータが開発ノウハウ公開
ＯＳＳで業界標準を目指す」
という記事がある。
そこによると、ＮＴＴデータが、TERASOLUNAという開発フレームワークの一部を公開したそうなんだけど、どこに公開したのかが書いていなかった。
そこで、その場所を書いてみたってわけ。
ま、これは自分へのメモで、今度、他社（富士通都下も含め）公開されている開発フレームワークのまとめをちゃんと書きたいと思ってます。
昨日、やる夫で学ぶ著作権のことを書いたけど、
そちらより、
【仁義なき】やる夫で学ぶ著作権Ⅱ【動画配信】
http://urasoku.blog106.fc2.com/blog-entry-252.html
のほうが、面白いかも。
（以下斜体は上記サイトより引用）
著作権著作権と言ったところで、そんなの所詮、交渉材料の一つとして法で保護されてるだけなのよ！
結局は、権利者と使用者の双方が、どう話し合って納得するかに掛ってるって事を知りなさい！
ではじまる、このおはなしは、
やる夫の「ギコギコ動画」と
ちゅるやさんのNyoro-Tubeと
やらない夫のGyaho！の話
なんだけど、
途中、CASRAC（ゴルゴ13がやってる）
やbbexとかでてきて、
最後（の絵はやっぱ ＾＾だけど、そのちょっと前）
では、「ギコギコ動画」の親の親会社（になるのかな？）
のbbexのコンテンツを、「ギコギコ動画」で流すっていう
話になるんだけど・・・これ、実際にありだよねえ・・
bbexの株主シークレットライブとか、b-nationとか、
映像は撮っているはず（シークレットライブは、
A会場の映像がD会場の大型スクリーンに出るようなので、
撮ってるはず。b-nationは、Channel-bで、b-nationの模様を
やるので、撮ってるはず）。
ならば、「ギコギコ動画」に載せれば・・・
bbexの株主シークレットライブは、オープニングアクトで、
（一番初めに出る人）毎年、売り出したい人が出るし、
（今回は、高杉 さと美、その前は中村中、その前はRINかな？）
b-nationは、たしか、メイン会場以外に、若手の部分があった
気がしたので、そこの様子を「ギコギコ動画」に載せれば、
宣伝にはなるかも・・・
bbexは、別にネットを嫌っているわけではなさそうなので・・
シリーズ「ネットワークのキーワードまとめ」の続き。
前回、クライアント側から信号が出るまでをやったので、今日は、そこからローカルのスイッチを通って、ローカルのルーターに行って、プロバイダに信号が出るまで
■ローカルのスイッチ
＜＜物理層＞＞
線から送られてきた信号を、マンチェスター符号化などにより、0と1にして、
フレームを作ります。
↓
＜＜データリンク層＞＞
受け取ったフレームの宛先MACアドレスをみて、それと、CAMをみて、
どこのポートに流したらよいか判断し、そのポートに信号を流します。
このとき、送信元MACアドレスから、どのポートにどのMACアドレスの
マシンがつながっているか学習し、CAMにセットします
（なので、受け取ったとき、CAMを見れば、どこのポートに送るか
わかります）
※信号を流す際、
１．フレーム全体を読み込んでから流す→ストアアンドフォワード
２．先頭６４バイトを読み込んでから流す→フラグメントフリー
３．宛先を読んだらすぐに流す→カットスルー
の３種類があります。
※また、スイッチが階層化されていることもあり、その場合、
「スイッチの」階層構造に基づいたルーティングを行うため
STPが利用されます（これで、スイッチングループを回避する）。
このとき、スイッチに自分の存在を知らせるためBPDUが
使われます
↓
＜＜物理層＞＞
データリンク層で送信するフレームを、マンチェスター符号化
などにより、0と1から電気や光の変化に変えて、線に流します。
■ローカルのルーター
＜＜物理層＞＞
線から送られてきた信号を、マンチェスター符号化などにより、0と1にして、
フレームを作ります。
↓
＜＜データリンク層＞＞
受け取ったフレームのヘッダ部分をはずして、パケットにして、
ネットワーク層に送ります。
↓
＜＜ネットワーク層＞＞
送り先のIPアドレスが、ネットワーク外部に送る場合には、
あらかじめ、ルーティングプロトコル等を使って、ルーティングテーブル
を作っておき、それと、送り先を照合することにより、データを送ります。
ネットワーク内部なら、内部の所定のPCなどに送ります。
※ネットワーク外部か、内部かは、サブネットマスクを使って分かります
※ルーティングプロトコルには、IGPｓとEGPｓがあり、
ある程度のまとまり（自律システム）における
プロトコルであるIGPｓについては、
ディスタンス ベクタ プロトコル:RIP,IGRP,EIGRP
リンクステートプロトコル：OSPF,IS-IS
などがあります(EGPsは別の機会に書きます）。
↓
＜＜データリンク層＞＞
宛先のMACアドレスなどを付けて、IPアドレスにフレームヘッダを
つけて、フレームを作成します
※上位で宛先IPアドレスが分かっても、MACアドレスが分からない場合、
ARPを利用して、IPアドレスからMACアドレスを取得できます。
↓
＜＜物理層＞＞
データリンク層で送信するフレームを、マンチェスター符号化
などにより、0と1から電気や光の変化に変えて、線に流します。
次は、そとに出て行きます・・・
「ハム速 ２ろぐ」の
やる夫で学ぶ著作権
http://urasoku.blog106.fc2.com/blog-entry-251.html
著作財産権と人格権のい違いや問題、喧嘩のしかた
などを、「ひこにゃん」を例に、分かりやすく説明していますね。
なかなか、いいかんじ。。
P.S 「ちゅるやさん」っていうのか、たまに見る、あの絵の人は・・
ちょっと思いついたことなので、忘れないうちにメモ。
（というわけで、これで出来るかどうかはわからないよ（＾＾；）
無責任な妄想ということで・・）
いま、年金で振り込まれていて
・振り込み記録はある
・だけど、照合キーである基礎年金番号や名前等が不明だったり、間違っているときに
・確からしいものを出してきて、その確からしさをファジー演算などをして、表示しなさい
という命題があったとする。この場合のやりかた案
■作戦！！
照合キーが使えないので、
・Aさんが払ってない部分とBさんが払った部分が照合した場合
・Aさんは、本当はBさんじゃないの？っていう確からしさを求めるものとする。
■処理内容
細かくやり始めてしまうと、たまたま当てはまるという偶然も多くなりそう。
そこで・・・
（１）１年以上あいている人をリストアップし、
・開いている部分が多い人を、補充組み
・あいている部分より、収めている部分が多い人を、足りない組とする
（２）補充組みは、納めた期間をDB化する
DB項目：ID(適当）,開始期間、終了期間、基礎年金番号、名前、会社ID
何箇所か、飛び飛びになっている場合は、全部の箇所について登録する
例：昭和４０年から４５年、６０年から６３年、平成８年から１０年だったら、
昭和４０年から４５年
６０年から６３年
平成８年から１０年
の３つを登録する。
（３）足りない組の１データに対して、
補充組みから、足りない組のあいているところが、ピッタシ当てはまる
データを検索し、そのデータと、足りない組データの基礎年金番号、名前
の適合具合を調べ、高い順に並べる
もし、やりたいなら、いくつかの補充データをあわせれば、足りないところが
ぴったり合うかどうかも調べる
■適合具合
で、その補充組みデータと足りない組データの基礎年金番号、名前の一致度だけど、
基礎年金番号空白の場合は、何パーセント、そのほか、１番違いなら何パーセントときめる。
同様に名前の氏が違う何パーセント、名が違う何パーセントときめる。
たとえば、合計１００％で、番号部分５０％、名前部分５０％として、
空白は、３０％
１番違うごとに５％マイナス、１０桁違えば０で、それ以上違っても０
氏がおなじなら２０％、名前が同じなら３０％
として、合計値を求める。
もちろん、このウエイト（％づけ）は、ここが間違えやすいという状況を考慮して、
変えていくものとする。
いやこれ、年金以外のことに使えるんじゃないかと思って（ジグゾーパズルや
割れたものの修復とか）いるんだけど・・
あるパッケージソフトを利用して、自分たちの業務ができるかどうかをチェックするのに、フィット＆ギャップ分析を行う。さてそこで、フィット・ギャップ分析をやる方法なのだが、だいたい、こーいう感じじゃないだろうか？
（１）そのパッケージソフトが想定する業務の流れの、アクティビティ図を作成する →これは、オペレーションマニュアルで分かるのが普通である (リファレンスをみると混乱する。チュートリアルがある場合は、それでもOK。 チュートリアルというのは、コメディアンではない） ちなみに、SugarCRMの場合、「実践！オープンソースCRM アプリケーション入門」の ２章（主にP70からP98)から作成できる。 （２）そのアクティビティ図から想定される、エンティティとその関連をおさえておく （あとで、データレベルでチェックするので、そこにもどれるように） →これは、アクティビティを行った入力画面項目を、正規化処理することによって、 求めることが出来る。 ちなみに、SugarCRMの場合、「SugarCRM Developer's Manual」の５章 ９４ページから１０３ページにER図が書いてある （３）自社のアクティビティ図と、アクティビティに関するER図を作成する。 →対象としようとしている業務の。 なお、（１）、（２）も、対象部分だけ分析すればよい （４）まず、（１）と（３）のアクティビティ図を比べ、業務レベルでの違いをチェックする →まったく違っている場合は（６）へ、 →時間的な流れに注意。同じ在庫たな卸しでも、月次でやっているか、年次でやっている かでは、かならずしも同じ業務にはならない（期間が長いだけで同じってこともあるけど） （５）同じと思われる業務に対して、（２）と（３）のER図で、出力データをとくに注意して その差異をしらべる （６）（４）、（５）の差異、（３）で全然違う場合に関して、既存のパッケージの機能、 あるいは他のソフトを組み合わせて出来ないかを考える →グラフ機能がないとき、データをExportして、Excelに流し込み、グラフを作成するなど （７）それでもできないとき、どこをどのようにカスタマイズすれば、OKになるかを考える （８）そのカスタマイズは可能なのかどうかを考える →既存パッケージの入出力口をチェック。 （９）（６）で、他のソフトを組み合わせるようなもの、 （８）で可能なカスタマイズ が、 カスタマイズ対象となり （７）でなにをカスタマイズすれば良いか分からなかったり、 （８）で方法がないの が、現実とのギャップになる。 →現実とのギャップは、実際のワークフローをかえることで、可能かどうかを考える |
＊パッケージに業務を合わせることは、不可能である。
そんな急激な変化をしたら、みんな会社をやめてしまう（＞＿＜！）
→逆に言うと、社員がみんな辞めちゃうほどの、劇的なリストラをするなら可能。
また、合併で、組織自体が大幅に変わる場合は可能になる。
ここの痛いニュース
Wiiリモコン（+PC）で立体メガネ。衝撃的な動画が公開される
http://blog.livedoor.jp/dqnplus/archives/1071545.html
によると(以下斜体は上記サイトより引用）
Wii リモコンハック界ではおなじみの Johnny Chung Lee(格安ステディカム界でも有名)
の「Wii リモコンでマルチペンタブレット」のニュースをお届けしたのはつい先日のことですが、
予告どおり今度はヘッドトラッキング(頭部位置追跡)システムが発表されました。あわせて
それを応用した3D表示をするバーチャルリアリティシステムも公開されています。
方法は、メガネのはしに、赤外LEDを付けます。で、
ディスプレイ下に置いた Wii リモコンで、赤外LEDを組み込んだ
眼鏡の三次元位置を認識します。頭の位置がわかれば、それに合わせてカメラ位置を
動かすことでよりリアルな擬似3D表示が可能になります。
で、これで、◎が、奥行きがあって動くような絵になっている。
詳しくは、
Head Tracking for Desktop VR Displays using the WiiRemote
http://www.youtube.com/watch?v=Jd3-eiid-Uw
のYouTubeのビデオにある
（注意：上記リンク先のYouTubeは、ロード後、すぐに音が出ます）
なお、ここに出ている人のサイト(http://johnnylee.net）
にいくと、リダイレクトされるんだけど、そこの先をみると、
この人、カーネギーメロン大学の人みたい。
アクセス
トータル
ランキング
