memcachedをnode.jsで

順番的に行くと、memcachedをnode.jsで・・ということになる。
これは、すでに、判りやすいブログが書かれている。

node.js から memcached を利用する + おまけ情報
http://hiroki.jp/2011/11/12/2368/

今回は、それをそのままやっただけのを、載せる。

---

つまり、

１．node.jsをインストールしたところにいき、npmでelbart / node-memcacheをインストール。つまり、

npm install memcache

ってコマンドラインから打つ



２．サンプルプログラムをうつ
　上記サイトにある、「memcache.js」をそのまま打てばよい。
　ちなみに、今回は、キーのところをちょっとだけ変えて、
以下の内容で

var memcache = require('memcache');
var client = new memcache.Client();
 
client.connect();
 
client.set('newKey', 'value', function(error, result){
}, 3600);
 
client.get('newKey', function(error, result){
    console.log(result);
});
 
client.close();

sample1.jsとして保存した



３．memcachedが動いていることを確認
　前に書いた、


memcachedをWindowsXPにいれて、Javaで操作する
http://blog.goo.ne.jp/xmldtp/e/9d0f3f127829ed2d617d3f52668177f3

の「■起動」で、「サービスの状態」が「開始」になっていることを確認する。


４．node.js起動
　node.jsのフォルダに行き
　　　node sample1.js
　とうつと、以下のようにvalueと出てくる。

Office15（Office2010の次期バージョン）テクニカルプレビュープログラム開始

って、日経

MS、「Office 15」のプレビュー開始　製品版は2013年か

ぐらいしか、ニュースにしてないよね

ニュースにならないのかな？
スラッシュドットにもない？

みんな、MS Officeには、興味ないってことかな？
Excel君、涙目（;_;）

"Office 15" Begins Technical Preview
http://blogs.office.com/b/office-exec/archive/2012/01/30/quot-office-15-quot-begins-technical-preview.aspx

アジャイルはやっぱり、ＳＥＳ契約化して行くのが、妥当？なら契約的にもイマドキだよね！

　アジャイルの問題点として、昔は、契約形態について話があったと思う。

　請負にしてしまうと、最終的にモノをつくって納品→検収って形にしないといけない。
　そうすると、はじめに仕様を決める形でないと、どんなものを納品、検収するか確定しない。
　だから、請負はアジャイルになじみにくい。
　無理やりやるとすると、スクラムの場合、１スプリントごとに契約する？


　派遣にしてしまうと、顧客が仕切ることになる。
　これだと、現実的には働いた期間に対して、お金を払うので、成果物の規定がいらず、
　成果物を柔軟に変えられる。という点に関しては、アジャイルに向いている。
　しかし、派遣だと、ＳＥを提供する側としては、派遣業の申請とか・・・
　っていう問題もあるけど、それ以前に、仕事のコントロールが顧客先に行ってしまうので、
　仕事を顧客が仕切らないといけない。それは、きついもんがあるでしょ
　（それができるなら、顧客はすでに派遣で人を集めて開発してるはず）
　開発側も、いろいろと、問題がありそうだ・・・

---

　ということは、委託になる。
　でも、委託だと変。委託っていうのは、顧客と技術者間で結ぶもんでは、ないかい？

　ということで、ＳＥＳ契約（システムエンジニアリングサービス契約）というのが出てきた。
　この場合、”ＳＥの能力を”契約対象とし、ＳＥを送り込めばよい（たいてい常駐）ということになる。
　そして、法律的には、「送り込む請負契約」なので、作る成果物は評価されない。
　　　→成果物を規定しなくて良い。
　現状の中小ソフトハウスとの契約は、ＳＥＳ契約が多い（とおもう）。
　　　→つまり、人を送り込んだけど、モノが出来るかどうかは、ベストエフォートとなる。　

---

　たぶん、アジャイルの場合は、ＳＥＳ契約化していくのが、妥当なんでしょうね。

　この人がこの期間担当します。成果物にかんしては、ベストエフォート（＾＾；）
　場所に関しては、今は相手方常駐が多いと思うけど（ほとんどなのかしら）、この辺は、開発会社側とか変わっていくと思う。

　という感じの契約。これだと、モノができないリスクはあるかもしれないが、それは、はじめは期間を短く設定し、出来そうだと感じたら、長く期間を設定する。
　はじめの期間で失敗した場合のリスクはあるけど、請負で長い期間開発して、結局だめでした・・・よりかは、損失は少ないかもしれない（って発想もアジャイルっぽい）。

---

　なお、ＳＥＳ案件は、偽装請負（偽装派遣）化しやすいという問題はあるのだが、アジャイルでＳＥＳを使う場合に関しては、その心配はない。

　お客さんは、プログラムを作る知識はない。ので、ＳＥＳによって提供される技術者が自主的に動いて作ることに間違いない。お客さんが開発業務のやり方を指揮監督する（＝派遣行為）とは思えない。それは、ＳＥＳ契約で提供される技術者（の１人のスクラムマスター）がやる行為である。
　だから、その心配はない。

---

　ただ、いまのＳＥＳの枠組みが、そのまま使えるかどうか？というと・・・？？？
　でも、ちょっとの契約を変えれば、行くんじゃないかと思う。

　今って、ＳＥＳ案件が多いわけで、そうすると、アジャイルって、契約的にも、（昔は向いていないと思われていたが）実は、むしろ、今の時代に、向いているんじゃないか？？