「～を買っている人は、～も買っている」とか、「～は高評価」の研究

■「～を買っている人は、～も買っている」

　「Ａを買っている人は、Ｂも買っている」という分析は、一般には、バスケット分析とか、協調フィルタリングとかいう分野になります。


　しかし、こういう複雑な分析が必要なのは、

　　　　ＡとＢの商品が決まっていない（バスケット分析）
　　　　それを買った人の類似性を評価している（協調フィルタリング）

　から、話を難しくしているだけで、



　Ａという商品が決まって、「Ａを買った人は、どの商品を買っていますか？」というだけなら、ＳＱＬでできます。
　たとえば、以下のような受注表があったとします。顧客ＩＤと商品Ｎｏが入っている（実際には受注表に顧客ＩＤ，商品Ｎｏは受注明細に入っていることが多いが、ここでは、それをJoinしたViewで考えているものとします）


この場合、


select distinct shohinNo from jyutyu where shohinNo ＜＞ 1 and kokyakuID in (select kokyakuID from jyutyu where shohinNo = 1 )

（実際には＜＞は、半角）

とすれば、１番を買った人は、他のどの商品を買っているかを出せます。
さっきの、「Ａを買っている人は」のＡが、上記のＳＱＬの１にあたります。
なので、他の商品にしたい場合は、１のところを直すことになります（１は２箇所）。



一応ＳＱＬを説明すると、「Ａを買っている人は」の部分が、サブクエリーの
(select kokyakuID from jyutyu where shohinNo = 1 )
であり、ここで顧客ＩＤを出すことで、その人たちが何を買っているかを絞り込める。
ただ、これだと、違う顧客が同じ商品を買ってしまうと、商品ＩＤが何回も出てくるので
distinctしてる。また、shohinNo ＜＞ 1でＡ自身を除いている。

　今回は、商品Ａそのものでやったけど、カテゴリーとか、もうすこし、大きな区分でやってもいい。

　ただし、購入者の類似性は見ていない。

　だから、「風邪ぐすりを買った人は」とかやると、胃薬、毛はえ薬、ばんそこう・・・いろいろ出てきてしまう（風邪薬は誰でも買うから）。でも、そのほうがいいケースもある（どういう人なのか、わからない場合、とりあえず、可能性を全部出したほうがいい）

---

■「～は高評価」

　これをまじめにやると、テキストマイニングとかになります。

　でも、ものすごく単純にやるなら、こんなかんじで出来るかも・・・

・CaboCha/南瓜を使って、対象となるテキストを解析します
　　すみません、今、南瓜が動かないので（なんでなろ～）
http://code.google.com/p/cabocha/
　にあるサンプルで説明します。（以下太字はサンプル）

% cabocha -f1
太郎は花子が読んでいる本を次郎に渡した
* 0 5D 0/1 1.062087
太郎 名詞,固有名詞,人名,名,*,*,太郎,タロウ,タロー
は 助詞,係助詞,*,*,*,*,は,ハ,ワ
* 1 2D 0/1 1.821210
花子 名詞,固有名詞,人名,名,*,*,花子,ハナコ,ハナコ
が 助詞,格助詞,一般,*,*,*,が,ガ,ガ
* 2 3D 0/2 0.000000
読ん 動詞,自立,*,*,五段・マ行,連用タ接続,読む,ヨン,ヨン
で 助詞,接続助詞,*,*,*,*,で,デ,デ
いる 動詞,非自立,*,*,一段,基本形,いる,イル,イル
* 3 5D 0/1 0.000000
本 名詞,一般,*,*,*,*,本,ホン,ホン
を 助詞,格助詞,一般,*,*,*,を,ヲ,ヲ
* 4 5D 1/2 0.000000
次 名詞,一般,*,*,*,*,次,ツギ,ツギ
郎 名詞,一般,*,*,*,*,郎,ロウ,ロー
に 助詞,格助詞,一般,*,*,*,に,ニ,ニ
* 5 -1D 0/1 0.000000
渡し 動詞,自立,*,*,五段・サ行,連用形,渡す,ワタシ,ワタシ
た 助動詞,*,*,*,特殊・タ,基本形,た,タ,タ
EOS


・Dの部分をもとに、係り受け構造を出します。

★「太郎」「は」→「渡し」「た」
★「花子」「が」→「読ん」「で」「いる」→★「本」「を」→「渡した」
★「次郎」「に」→「渡し」「た」

・この中で、名詞（★がついているもの）について、
　　　　低評価の語にかかっているものをマイナス
　　　　高評価の語にかかっているものをプラス
　とします。高評価、低評価語の辞書はあらかじめ作っておきます。

　http://thesaurus.weblio.jp/

　などを使って、「好き」とか「良い」とかいれて、高評価の類義語を調べていって、辞書を作るとか・・

・この名詞と評価を保存しておく

なかんじで、たぶん出来ると思う。やってないので、確証はない。

Apache Hadoop On Windows

HadoopがWindows（Server）でも動くよ！というマイクロソフトさんからのお話


Apache Hadoop On Windows
http://social.technet.microsoft.com/wiki/contents/articles/apache-hadoop-on-windows.aspx


制限されたコミュニティに対する技術的プレビューバージョン？
は、ここ


https://connect.microsoft.com/SQLServer/Survey/Survey.aspx?SurveyID=13697


ってあるけど、Windows liveに入ってないとだめみたい・・

一番初めに書いたサイトの真ん中あたりに、

Apache Hadoop on Windows Server

ってことで、windowsサーバーのはなしがあって、そのあと、
Apache Hadoop on Windows Azure
って続いている。

Windowsでnode.js：Javascriptでクロージャ

　きのうの、


Windowsでnode.js：ファイルの読み書きと同期、非同期
http://blog.goo.ne.jp/xmldtp/e/f26fd919b3e30a2a7b97b99bdbc51acf


ぜんぜん、サンプルになってない！と気づいた方は、多数いると思う。


そう、

　　・node.jsのウリは、非同期なんだから、読み込みも、非同期でないといけない
　　・それもリクエストを受け取った後に、確実に読み込まないといけない

その方法は、書いてない。

今回は、その方法、つまり、

・接続されたら、データを読んできて、
　　　読んできたデータを表示、
　　　ファイルに書き出す
　というサンプルを、いきなり書きます。

　Javaとかをやっている人には、「度肝を抜かれる」サンプルです。

　こう書きます。

var sys = require('sys');
var http = require('http');
var fs = require('fs');
var outdata;

buf = "abc";
fs.readFile('./helloworld.js',"utf-8",function (err, data) {
		buf = data;
});

var server = http.createServer(
    function (request, response) {
	fs.readFile('./helloworld.js',"utf-8",function (err, data) {
		response.writeHead(200, {'Content-Type': 'text/plain'});
		fs.writeFile('./helloworld2.js', data,"utf-8",function (err) {
			});
		response.write(data);
		response.end();
	});
    }
).listen(8124);

 
sys.log('Server running at http://127.0.0.1:8124/');

createServerのコールバックの中の関数で、
　　　fs.readFileして、その中のコールバック関数＊で
　　　　　response.write
　　　　　fs.writeFile
して書き出すというのはいいと思います。
たしかに、この順になりますよね。

問題は、＊をつけたコールバック関数の中で、何も宣言もせずに、
responseっていう、それを呼び出した、createServerのコールバックの中の関数の中の変数
をつかっちゃってることです。

Ｊａｖａだったら、宣言してない変数を使ってるんだから、エラーになります。

でも、Ｊａｖａｓｃｒｉｐｔでは、このケースでは、ＯＫなんです。
つまり、関数Ａの中の関数Ｂは、関数Ｂの他に、関数Ａの変数が使えちゃうんです。
実際、思ったとおりにちゃんと動きます。
これが、クロージャです。

詳しくは、

JavaScriptクロージャを完全理解！スコープチェインを知る（後編）
http://builder.japan.zdnet.com/script/sp_javascript-kickstart-2007/20378258/2/

を見てください。

わかりましたかあ～

・・・って、何も説明してね～だろって（＾＾；）

Windowsでnode.js：ファイルの読み書きと同期、非同期

昨日の、node.jsのつづき。

---

■同期して、読み書き

　node.jsで、ファイルを読み書きする場合、２通りの方法がある
　　　　同期して読み書き
　　　　非同期読み書き

　同期の場合は、メソッドに、Syncをつける
　こんなかんじ。

var sys = require('sys');
var http = require('http');
var fs = require('fs');
var outdata;


var server = http.createServer(
    function (request, response) {
	response.writeHead(200, {'Content-Type': 'text/plain'});
	buf = fs.readFileSync('./helloworld.js',"utf-8");
	fs.writeFileSync('./helloworld2.js', buf, 'utf8');
	response.write(buf);
	response.end();
    }
).listen(8124);

 
sys.log('Server running at http://127.0.0.1:8124/');

buf = fs.readFileSync('./helloworld.js',"utf-8");
fs.writeFileSync('./helloworld2.js', buf, 'utf8');

で、同期の読み書きをしている。
このプログラムは、http://127.0.0.1:8124/にアクセスすると、
　　helloworld.jsのプログラム内容を表示し、
　　その内容をhelloworld2.js
に書き出す

というもので、これは、問題なく、この処理をする。

---

■非同期で読み書き

　ところが、非同期（fs.readFile、fs.writeFile）で、同じことをしてみると、

var sys = require('sys');

var http = require('http');

var fs = require('fs');

var outdata;





var server = http.createServer(

    function (request, response) {

	response.writeHead(200, {'Content-Type': 'text/plain'});

	buf = "abc";

	fs.readFile('./helloworld.js',"utf-8",function (err, data) {

			buf = data;

		});

	fs.writeFile('./helloworld2.js', buf,"utf-8",function (err) {

		});

	response.write(buf);

	response.end();

    }

).listen(8124);



 

sys.log('Server running at http://127.0.0.1:8124/');

この結果は様々考えられるが、私のところでは、
画面には、abcと表示され、ファイルにもabcと書き出される。
つまり、readFileで指定したコールバック関数には、入っていない。

一方readFileを外に出すと、

var sys = require('sys');

var http = require('http');

var fs = require('fs');

var outdata;



buf = "abc";

fs.readFile('./helloworld.js',"utf-8",function (err, data) {

		buf = data;

});



var server = http.createServer(

    function (request, response) {

	response.writeHead(200, {'Content-Type': 'text/plain'});

	fs.writeFile('./helloworld2.js', buf,"utf-8",function (err) {

		});

	response.write(buf);

	response.end();

    }

).listen(8124);



 

sys.log('Server running at http://127.0.0.1:8124/');

この結果も様々考えられるが、私のところでは、
helloworld.jsの内容が表示され、ファイルにも書き出される

---

■理由

　非同期だから。


　非同期の場合、readFileで読み込みが完了するのを待たずに、次のwriteFileの処理に入る。
　結果、２番目のケースでは、bufに読み込み内容がセットされる前に、次のwriteFileの処理に入ったので、bufの中身は書き換わらなかった。

　３番目のケースでは、ブラウザで表示する前に十分な時間があったから、読み込みが完了、bufにデータが入った状態で、writeFileの処理に入ったので中身を書き出せた。

1月10日(火)のつぶやき

01:28 from web
「八重洲無線株式会社」復活！！－バーテックススタンダードが「八重洲無線株式会社」に！ http://t.co/p1YBnEyI
by xmldtp on Twitter

５大予想：ネットワークの行方－その１：キャリアのスマホ対策としてのOpenFlow

　年の初めに、新年のご挨拶＆今年の５大予測！というのを書いて、前回で、５．（スマートグリッドと原子力の行方）が終わったので、今回から、

３．（ネットワークの行方）
　オープンソースのＵＴＭ(Endian)＋ルーター(Vyatta)＆自作パソコンで、
ルーターからなにから、全部自作可能時代へ→中国から安値攻勢。
　さらに、OPEN FLOWでフロー制御も自作。

を書きます。まずは、OpenFlow

---

■ＩＰＶ４はまだ使い続ける－ＩＰアドレスに紐づけるのは、破綻する

　ＩＰＶ４は、まだ使い続けると思いますね。みんな。
　ＩＰＶ６は、なかなか普及しない。

　ってなると、ＩＰＶ４のＩＰアドレスに何かを紐つけるっていう考えは、破綻する。

　とくに、ケータイとかは、電話番号とＩＰアドレスなんていう紐付け方は、無理になる。
　いままでは、長時間使っていることはなかったので、ＩＰアドレスを利用の都度回収して、再配布すればよかった。
　でも、スマホのダウンロードなんていうのは、長い時間やっているわけで、そうなってくると、スマホユーザーが増えたりすると、問題がある。

　ポートアドレス＋ＩＰアドレスの紐付けなら、問題はない。

　ＩＰアドレス１つごとに、ポートを１万ずつ割り当て、１ポート１電話番号（実際には、送受信で２ポートいるけど、それなら、ポート２万でもよい）にするんなら、クラスＢで、

　　６万以上＊１万(以上）＝６億以上

となり、そんなにケータイ＆スマホのユーザーはいない

---

■ＩＰ＋ポートにＭａｃアドレスを対応させるとか、したくなってくる

　しかし、ＩＰ＋ポートに直接、電話番号を割り振ってしまうと、今度は、制御が大変になりそうだ。
　なので、ＩＰで経路情報、たとえば、基地局ごとにＩＰを割り振り、基地局が、つながってきた電話片っ端から、ポート番号を割り当てていくとかしたくなってくる。

　そうすると、ＩＰ＋ポート番号と、電話番号の対応をしてもらいたくなる。
　電話番号にＭＡＣアドレスを対応させ、ＩＰ＋ポート番号とＭａｃアドレスでもいいけど・・

　つまり、ＩＰと電話番号と結び付けるのでなく、
　ＩＰと基地局（ないしサーバー）、ＩＰ＋ポート番号と電話番号を紐付けたくなる。

　こういう複雑な紐付けに、ＯｐｅｎＦｌｏｗは向いているんじゃないかな？

---

■キャリアが、この辺を考えると・・・ＮＥＣが儲かりそう

　まあ、これは一例だけど、キャリアがいままでのＩＰの制御方法より、もっといい制御方法を見つけて、スマホに対応しようとすると、やっぱ、ＯｐｅｎＦｌｏｗということになる。

　ＯｐｅｎＦｌｏｗっていうと、今のところＮＥＣなのかしら。
　ＮＥＣがどこかのキャリアと何かやりだせば、きっと、それがマーケットで話題になって、株価上がって大もうけ？なんでしょうか？

　株式市場は、内容とかは、関係ないからね・・・

Windowsでnode.js

　サーバーサイドで動くJavascriptの中でも、node.jsは、話題を独り占め！ってかんじだとおもう。非同期処理が出来るから。

　日経コンピューターの２０１１年１２月２２日号、７４ページに
　「Close Up
　　サーバーの常識を覆す「Node.js」
　　大量アクセスを小さいシステムで」
　なんて特集があるくらいだから・・・

　でも、そのサンプルとして、例えば、

サーバサイドJavaScriptの本命「Node.js」の基礎知識
http://www.atmarkit.co.jp/fwcr/rensai2/nodejs01/02.html

とかだと、Linuxの例になっている。

Windowsしか、マシンがない（＞＿＜！）
Mac以外は、パソコンじゃない！（－＿－；）

って人に対して、インストーラーがあるんだけど、そのことについて、
書いてないと思うので、ここにメモメモ
（以下、Windows　ＸＰで動作確認しています）

---

■ダウンロード

インストールパッケージのmsiは、

http://nodejs.jp/nodejs.org_ja/docs/v0.6/

にある。

そこの「download」をクリック

windowsインストーラーをクリック

これで、ダウンロードできる。

---

■インストール

ダウンロードしてきたファイル（さっきダウンロードしたら、node-v0.6.7.msiだった）。
のアイコンをダブルクリックして、起動させる。

ってでてきたら、next。あとは、適当にnextしてれば、インストールされる。

そのようにインストールすると、C:￥Program Files￥nodejsの下に、以下のように
node.exeがインストールされているはず。

---

■Hello World

そしたら、

サーバサイドJavaScriptの本命「Node.js」の基礎知識
http://www.atmarkit.co.jp/fwcr/rensai2/nodejs01/02.html

にある、「helloworld.js」のソースコード、つまり、

var sys = require('sys');
var http = require('http');
 
var server = http.createServer(
    function (request, response) {
 
        response.writeHead(200, {'Content-Type': 'text/plain'});
        response.write('Hello World!!\n');
        response.end();
    }
).listen(8124);
 
sys.log('Server running at http://127.0.0.1:8124/');

(上記囲み内は、上記サイトからの引用）

をコピペして、さっきの、C:￥Program Files￥nodejsの下に、
「helloworld.js」というファイル名で保存する。


そうしたら、コマンドプロンプトから、

cd C:￥Program Files￥nodejs

して、

node helloworld.js

と打つ。そうすると、起動する。

起動したら、ブラウザで、

http://127.0.0.1:8124/

を見ると・・・


hello Worldが出ている。

1月9日(月)のつぶやき

15:03 from web
ソフトウェア工学の授業でastah*教えてくれるらしい。それも本位田先生が！早稲田理工は https://t.co/oJtBO3Hv
by xmldtp on Twitter

５大予想：スマートグリッドと原子力の行方－その３：Googleに続き、データホテル、ＧＭＯが

さて、前に書いた、５大予想の話のうち、今、「スマートグリッドと原子力の行方」を書いていますが、その３回目、こんどは、企業と家庭について

なお、この話は冗談であり、実現性は０です。真に受けないでください。

---

■電気代、上がると思います。

もちろん、福島原発の賠償補填とか、そういう意味もあるかもしれないけど、
それ以前に、上がると思いますね。

理由は、ピーク時電力を下げるため。

原子力発電所はもう、稼動できないでしょう。
火力に頼ると、そのうち、地球温暖化の話が出てきます。
水力発電所を立てるには、間に合わない・・・

となれば、今以上に、節電してもらわないと、ピーク時の電力使用量は、足らなくなる。
でも、節電してもらえるとは思えない・・・どうするか？答えは簡単。
ピーク時の電気代を高くしてしまえば、ピーク時電力使用量は減ります。
昔は、ピーク時だけ別料金ってのは難しかったけど、今、スマートメーターを使えば
できる。実際、実験しているようですよね。


＜電気料金＞需給に応じた価格調整の実証事業実施へ
http://headlines.yahoo.co.jp/hl?a=20120105-00000005-mai-bus_all




■データセンターとか、困ります。

そうすると、誰が困るか？
工場とかは、ピーク時に操業しなければいいかもしれない。
でも、絶対電気を使わないといけない人たちがいます。
通信業です。
その時間に、電話かけられたら、ネットつなげられたら・・
・・ちょっとまって、電気代高いから・・・とはいえない。


こうなってくると、データセンターみたいなところは、電気代勝負になってくる。
電気代を安く抑えれば、会社の経費が減り、利益を生み出せる。
もし、電気を潤沢に使えないと、将来のビジネスが危なくなる。
ルーターは増やす必要がある。ビジネス拡大するには・・・
そうすると、電気が必要・・・経費膨大。

なんとか、電気代を抑える必要がある。
ここで、Ｇｏｏｇｌｅのスマートグリッドに取り組んだ、真の意味を知る。
そう、データセンターとかは、電気を潤沢に使える研究をしないと、
将来、大変なことになる。ルーターの電気代で。

そこで、データホテル、ＧＭＯが、電気代を抑える研究をはじめる。
電気を安く作れないか、電気代が安いところ（国）にサーバー置けないか？
第九研究室は、電気を作る研究を始めます。



■家庭は、エネルギーのダイバーシティへ

　家庭では、もっと大変なことが起こります。
　電気がないと人工呼吸器が止まるとか・・・
　そこで、電気だけに頼らない生活を考えます。

　エネルギーのインフラは、ひとつではなく、多様な（ダイバーシティ）ほうがいいと言うことに、気づき始めます。
　そして、できるだけ安いエネルギーを使おう、さらに、できれば、エネルギーをとってきたり、作っちゃおう！ってことになります。

　その考えを進めると、みんな気づきます。
　地域によって、ベストなエネルギーは違うと・・・

　温泉がわいているところは、温泉を利用するのがいいし、
　太陽さんさんのおうちは、太陽光がいいかもしれない。
　井戸があるところは、冷蔵庫の変わりに、井戸で冷やしたほうがいいかもしれない

　このように、家々ごとに、適切なエネルギーが違う・・・
　ということになり、どのようにしたら、安上がりになるかという、エネルギーのソムリエが出てくるようになる。

---

　つぎは、ＯｐｅｎＦｌｏｗ

「フリー」を読む その７ 第５章 前半

祝祭日は、

フリー~〈無料〉からお金を生みだす新戦略
http://www.amazon.co.jp/dp/4140814047


を読んでいきたいと思います。

前回、第４章だったので、今回

第５章　安すぎて気にならない
　－　ウェブの教訓＝毎年価格が半分になるものは、かならず無料になる

からです。

---

・１９９５、米国原子力委員会のルイス・ストラウス委員長
　　→未来はすばらしい出来事が待っている
　　　電気エネルギーはとても安価になり、われわれの子供たちが
　　　気にせずに家庭で電気を使えるようになると期待していいだろう
　　→戦後の科学技術ブームによって歴史上類を見ないほど生産性を上げた
　　　だが、電気は気にならないほど安くはならなかった
　　→ウラン燃料のコストは石炭に比べ低い
　　　　　→原子炉・発電所の建設という初期費用がかかりかかる
　　　　　→放射能廃棄物の処理：未解決の問題
　　　　　→スリーマイル・チェルノブイリで倍増
　　　→今日の原子力エネルギーのコストは石炭と同程度
　　　　電気の経済学は少しも変わらない

・安すぎて気にならないとは、無料を意味するわけではない
　　→注意を払うほどは高くないという意味
　→もし、ストラウスの予言が当たっていたら？
　　→電気がタダ同然になっていたら
　　→電気に関わるほとんどすべてのものは、変化した
　　→人間は、電気を使いたいだけ使うだろう
　　→化石燃料がバカみたいに高く汚く見える
　　　　　→地球温暖化という言葉は生まれなかっただろう

・実現可能性は？
　電気については無理？（太陽光発電が可能にする？）
　他のテクノロジはすでに実現している
　　　→情報処理能力、デジタル記憶能力、通信帯域
　　　　　→そこにいたるペース：圧倒される
　　　　　　　：ムーアの法則

・各テクノロジのもたらす経済効果はさらに強烈
　トランジスタ１個のコスト→安すぎて気にならない
　情報処理能力、記憶能力、通信帯域→はたく、性能上がり、安くなる
　　→新しい形のフリーを推進：限りなくゼロに近づいている


----

■安くなることを予測する
・製造コストが下がり続ける
　　　→明日に要するであろうコストから価格を決める
　　　　例：フェアチャイルドのＵＨＦＴＶチューナーにトランジスタ
　　　　　　→「安くなることを予測する」
　　　　　　Ｔ型フォード→デジタルテクノロジーのペースには及ばない
　　　　　　　　　→だから今日でも車は高級品

・ムーアの法則は、マーフィーの法則に反するものだ
　　→あらゆることがどんどんよくなる

----

■なぜ、ムーアの法則は成立するのか

・産業プロセスのほとんどは、時間の経過と規模の拡大により、学習曲線として
　知られるプラスの効果が表れる
　　　→半導体の場合は、より速く、長期にわたる

・半導体に表れた違いは、ハイテク製品の多くに見られる特徴だ。
　　　→それらは物質よりも知恵がはるかに重要になる製品
　　　→インプットは知的財
　　　→半導体は物質経済の崩壊を示している

・アイデア：伝達のための限界費用は０
　　→アイデアが生まれると、自ら広く遠くへと伝わることを望む
　　　触れたものすべてを潤沢にする
　　　　　　→ミーム

・アイデアをせき止めて利益を上げる：知的財産権
　　→だが、アイデアを永久に止めておくことはできない
　　→アイデアから作られるものが多くなれば、それだけ速く安くなる
　　　　　　→ムーアの法則

・情報が主要な構成要素となる産業なら何でも、複合学習曲線をたどる
　　　→価格を下げながら、性能を上げていきやすい
　　例：医薬品、ＤＮＡ配列検査、ナノテクノロジー

---

次回は、この続きから

OpenFlowソースコードを提供－Juniperがデベロッパーに対し

あらま！

冗談で書いていた、新年のご挨拶＆今年の５大予測！の３番目、


３．（ネットワークの行方）
　オープンソースのＵＴＭ(Endian)＋ルーター(Vyatta)＆自作パソコンで、
ルーターからなにから、全部自作可能時代へ→中国から安値攻勢。
　さらに、OPEN FLOWでフロー制御も自作。


って書いてたけど・・・OPEN FLOWは、実現しちゃうのかしら


Juniper がデベロッパーに対して、OpenFlow ソースコードを提供し始めた

によると(以下太字は、上記サイトから引用）


Juniper Networks は、自社の Junos SDK に OpenFlow 対応のソースコードを取り入れ、その時流に乗ろうとしている。同社の説明によると、その SDK で開発される OpenFlow アプリケーションは、Junos OS 上で動作するカスタム・アプリケーションに対応する、ネットワークを介したダイナミックなプログラミングを実現するために、そのコントロール・パネルを変更できることになる。


なんだって。

ほお、そのＳＤＫ使うと、５大予測にかいたように、フロー制御、自作できるのかな？

まあ、それはそうと、ともかく、もうそろそろ

OpenFlow
http://www.openflow.org/

を見ておいたほうがいいね。。。

1月7日(土)のつぶやき

17:15 from gooBlog production
ベンダー企業のＳＥ、無能な役立たず社員が増殖中ってこと？ http://t.co/mqPA3S7g
by xmldtp on Twitter

ベンダー企業のＳＥ、無能な役立たず社員が増殖中ってこと？

ＩＴ人材白書2010 概要(H22.4.7)
http://www.ipa.go.jp/jinzai/itss/activity/2010summary_of_ITHR.pdf

の６シート目

ベンダー企業：IT人材の「量」に対する不足感
　　ベンダー企業のIT人材不足感は急激に緩和。IT企業
　　やや過剰と答えた企業が１割以上に急増。

ベンダー企業のＳＥは、あまってるってことでしょうかね？

さらに７シート目

ベンダー企業：IT人材の「質」に対する不足感
　IT人材の質の不足感はやや減少傾向。IT企業
　しかし不足感は依然として強い。


量的にはあまっているのに、質的にはたりない。
求めている質に達していない、余剰人員がいないと、こういう結果にはならないよね。

え～つまり、無能な役立たず社員が増殖中ってこと？

REBOKを読む その１ 全体像

今日から、

要求工学知識体系
http://www.amazon.co.jp/dp/4764904047

（ＲＥＢＯＫ）を読んでいきたいとおもいます。

まずは、全体像。

---

■全体の構成

　全体の構成は、以下のようになっている

　０．はじめに
　１．要求工学の基礎
　２．要求工学プロセス
　３．要求獲得
　４．要求分析
　５．要求仕様化
　６．要求仕様の検証・妥当性確認・評価
　７．要求の計画と管理
　８．実践の考慮点
　その他付録

となっている。

　ここで、「０．はじめに」はＲＥＢＯＫについての説明、
「１．要求工学の基礎」は、機能要件、非機能要件など、要求工学で必要な知識について。
「２．要求工学プロセス」は、プロセス全体についてのお話　

　要求工学で行う各プロセスは、３章以下に述べられている。

　３．要求獲得
　４．要求分析
　５．要求仕様化
　６．要求仕様の検証・妥当性確認・評価

　が行うべき内容である。

　このプロセスの管理として、
　７．要求の計画と管理
　がある。

　８章は、ベストプラクティスについて書いてある。残りは付録。

---

■各プロセス（３章～７章）の構成

　このうち、実際に行うべきプロセスが書いてある、３章～７章に関しては、同じ構成になっていて、
　章.0（３章なら３．０、４章なら４．０）で、各章の内容の概説として、その後で述べられるプロセスがどのようなものかを説明し、それ以降、順番に、（３．１、３．２・・・・）行うべきプロセスというかアクティビティというかが書かれている。

　この３．１，３．２・・・以降は、各プロセス、おおむね以下の構成になっている

　　１．概説
　　２．目的
　　３．アクタ
　　４．手順
　　５．技術
　　６．インプット
　　７．参照
　　８．アウトプット
　　９．関連副知識領域

　ＰＭＢＯＫの場合、インプット、アウトプット、ツールと技術なので、それ以外にも、詳しく書いてある。

---

■次回から

　次回から、各プロセスについて、つまり、３章以降についてみていく。

　その前に、３章以降でよく出てくるＳＭＥという言葉について、ここで説明しておく。

　ＳＭＥは、２．２．５（Ｐ３５）にあるとおり、サブジェクトマターエキスパート、その分野の知識をもっている人で、ドメインエキスパートなどをさす。

　では、次回。

５大予想：スマートグリッドと原子力の行方－その２：地下原子力発電

さて、前に書いた、５大予想の話のうち、今、「スマートグリッドと原子力の行方」を書いていますが、その２回目、こんどは、原子力発電について

なお、この話は冗談であり、実現性は０です。真に受けないでください。

---

■４０年後に廃炉＝その間、地震がきたら、どうなるの？

　福島第一原発の廃炉に４０年かかるという話がありますが、そうなってくると、廃炉までに、地震が起きるかもしれない・・・など、危険がいっぱい！
　そこで、廃炉にするまでに、安全に保つ方法が模索される。


■今ある原発は、とりあえず埋めてしまえば？

　最近、話題にならなくなったが、地下原発という話がある。地下に原発を埋めてしまえば、何か起こっても、放射能は飛び散らない。地下のほうが、安全なんじゃない？という話。
　新規に原発を作るかどうか、それを地下にするどうかはさておき、とにかく今ある原発は、どうにかしないといけない。動かさなくっても、危険なのは一緒。
　となると、とりあえず、地下原発みたいに、埋めちゃえば安全じゃない？
　すくなくとも、福島第一は埋めちゃえば・・・ってことになる。


■埋める土と、除染した土

　でも、埋める土は、どうする？ということになる。
　ここで、除染した土の話題が出てくる。

　カエサルのものは、カエサルに返すなら、やっぱ、放射能は、東電にかえすのが、いいんじゃね？
　みたいな感じで、東電が、除染した土を、最終的にどうにかしないといけなくなる。

　そうすると、大量の土がくることになる。

　そこで、その土を、
　　　汚染して、除去できた土は、埋めるのに使って、
　　　残った高濃度汚染土は、地下を掘って埋める
　　　　　掘って出てきた土で、埋める

　みたいな話が出てくる。
　
■結果として

　原子力発電所は、埋めちゃうことで決着。
　福島第一は、除染した土で埋めてしまう。


となってくる・・・と予測する。

次は、


　家庭内自然発電の家が出始める。これにスマートグリッド技術が使われる。


Ｐ．Ｓ　このブログエントリは冗談です。まじめに受け取らないでください。