2010年10月27日水曜日

お掃除ロボ ルンバ527

SEの仕事とは全く関係無い話です。。

前から気になっていたお掃除ロボ・ルンバ。近所のK'sデンキに行った際に思わず買ってしまいました。値段は46,000円。ルンバの隣には何やら安い廉価版みたいな自動掃除機もあったので店員にどう違うのか聞いてみると、彼曰く、、
「これはルンバの二番煎じ。全然売れてないです。やっぱりルンバですよ」
との事。値段は高かったですが、我が家は共働きで、休日以外に全く掃除機をかけない為、外出中に勝手に掃除してくれる事を期待して思い切って購入しました。

で、実際に使ってみて感じた事は以下です。
・案外、吸引力は無い
・普通の掃除機ほどでは無いが、それなりにうるさい。(昔のラジコンみたいな音がします)
・電気コードに引っかかってしまい、抜け出せなくなる事がある
・掃除機をかける為に、床に落ちているものを片づける必要有
・K'sデンキに置いてあったパンフレットには「人口知能」と宣伝されていたようだが、そのかけらも感じない
・突然、掃除するのを止めるように思う
・じっと見てると、「何故そっちばっかり行くのか?!」と多少いらつく
・毎回、ロボの中のごみを取る必要があるが、これが意外と面倒
・我が家のソファー下を掃除してくれる事を期待したが、高さ制限で入れずっ!

と、否定的な事ばかり書いてしまいましたが、家を出る時に掃除をスタートさせて、帰ってきたら「それなりに」綺麗になってる感じがするので、「それなりに」重宝しています。

改善してほしいなと強く感じるのはやはり吸引力でしょうか。ルンバだけでその他の掃除機はいらなくなるのかなと思っていましたが、ルンバは所詮サブ掃除機としてしか使えません。それと、もう少し効率的に掃除出来ないのかっ?とも思います。しかし、これはカメラ等を搭載の上で、映像から位置を掃除機自身が把握したりしないとダメかなーと思います。まあ10年以上先の事ですかね。

尚、私が買ったのはルンバ527という一番安いモデルですが、上位機種では
・充電が必要になったら勝手に充電してくれる
・タイマーで自動起動してくれる
との事です。私は全くこれらの機能に魅力は感じませんが。。。

汚い写真ですが、これが我が家のルンバ527


高さはティッシュボックスより少し高い程度?
我が家のソファーの下には残念ながら入れませんでした。。

2010年10月15日金曜日

よく分からないCAP定理の話をしよう

MongodbやCassandra等の最近流行のNosqlの紹介に何故かついてくる「CAP定理」。その内容はさらっと書くと以下との事。


分散システムでは以下の3つのうち、2つしか満たす事は出来ない。
C:Consistency(一貫性)
A:Availability(可用性)
P:Tolerance to network Paritions(ネットワーク分割耐久性※)
※造語です。


で、例えばMongoDBはCPのシステムですよー。CassandraはAPのシステムですよー。OracleやPostgresql等の従来型RDBはCAですよー。という解説が大体続く。


上記説明を聞いて、「はっ??」と思う人は多いんじゃないでしょうか。
私がよく分からなかったポイントは以下です。


・C(一貫性)の定義が不明。私はACID特性の"C"を連想してしまう。Mongodb等はTransactionの概念が無く、ACIDもくそも無いはずだ。


・A(可用性)の定義も不明。例えばMongodbは"A"が無いという分類になっているが、障害が起きたらしばらく復旧できない、とか、Dataが消失する。。という事を連想してしまう。それは無いだろう。


・P(ネットワーク分割耐久性)の定義も不明。何となくだが、スケールアウト出来るか、出来ないか?という事だろうが、OracleのRAC等は"P"では無いのだろうか。


と言う訳で、CAPのそれぞれの意味を深く考える事がCAP定理の理解につながると考え、色々調べてみました。


CAP定理をGoogleで検索してみた。役に立ちそうなのは以下。。。


http://www.hyuki.com/yukiwiki/wiki.cgi?BrewersCapTheorem
↑訳は間違ってはいないと思うが、この記事の内容は日本語にすると何だか変な気がします。


http://yohei-y.blogspot.com/2009/03/cap-base.html
↑CAP定理が生まれるまでが分かりやすい流れで記載されています。


http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf
↑Brewerさんが問題提起した時のスライド。この中でCAP-theoryという用語で出てきます。(読みましたが、意味があんまり分かりません)


http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.20.1495&rep=rep1&type=pdf
↑CAP定理の証明、らしい。どういうものかと思ってたが論理学?っぽい。
  この論文の中にC、A、Pのそれぞれの定義が記載されている。(上記に同じくよく分かりません)


http://el.jibun.atmarkit.co.jp/forest1040/2009/06/caporacle-rac12.html
↑ORACLE RACの例を取ってCAP定理を解説しています。


日本語の本では以下の解説が分かりやすかったです。

クラウド・アーキテクチャの設計と解析―分散システムの基礎から大規模データストアまで




・・・私の思考過程は省きます



【まとめ】
CAP定理のC、A、Pの定義は"大体のところ"以下だと思う。


Consistency:
あるデータを更新後、他のユーザからの参照時に必ず更新後のデータが読める事。
※ACIDでの"C"とは直接関係は無い。


Availability:
いつでも、ストレス無くデータの読み書きが可能な事。
※高可用性を意味する"High Availability"とは関係が無い。


tolerance to network Partitions:
データを複数のサーバに分割保持する事。
※Oracle RACはデータファイルを分散して持てない為、これには該当しない。(ように思う)

"CA"を満たすシステムの例
→従来型のRDBMS(Oracle,Mysql,Postgresql ...etc)


"CP"を満たすシステムの例
→DNS等


"AP"を満たすシステムの例
→分散データベース等


分からなかったのはココには、"AP"の例としてCassandra,CouchDBを挙げ、"CP"の例としてMongoDBを挙げているのですがなぜなのか分かりませんでした。


また、"A"の定義がやはりあいまいだと感じます。どんなDBMSでも程度の差はあれ一貫性を保つ為に排他制御を行ってるし、それがどの程度でストレスになるかは人によって違いますし。


しかし、この"CAP定理"、米国のwikipediaにも掲載されていませんし、Net上でもあまり目にかかりません。そこまで気にする必要は無いのかなと感じました。

2010年10月9日土曜日

HackerJapan

HackerJapanという雑誌。

前から少し気になってはいたんですが、いつも行く本屋ではなんだかやばそうな雑誌群の近辺にあったので確認はしていませんでした。
今回、何となく手にとって確認しましたが、驚くほど普通のセキュリティ関連雑誌です。初心者にも分かりやすく解説しており、非常に好感が持てました。

http://www.byakuya-shobo.co.jp/hj/

セキュリティ関連の仕事をしてる人は要チェックかと。。

2010年10月2日土曜日

ITゼネコンビジネスモデル

Web+DB Press(No.58)を久しぶりに買って読みました。その中で記事の一つが色々と考えさせてくれる内容だったので紹介します。

題は「なぜ日本のソフトウェアが世界で通用しないのか」というもの。米国と日本のソフトウェア産業の仕事のやり方を比較していますが、日本でのソフトウェア開発は、ITゼネコンビジネスモデル(大手ベンダが仕事を受注し、実際のプログラミングは下請けベンダが行う構図)であり、その事が以下のような副作用ともたらしているとの事。

・結果的にソフトウェア開発が労働集約型のビジネスモデルとなってしまっている
・必然的にウォーターフォール開発となり、人手と手間がかかりがち
・IT関連企業の海外での競争力低下
・ベンチャー企業を立ち上げにくい環境
・エンジニアの地位の低下

ソフトウェア産業は本来知識集約型産業であり、ソフトウェアは流れ作業で大量に作れるものでは無く、優秀な頭脳により作りあげるものだ。日本企業のやり方だとソフトウェア開発の優秀な人材は海外に流れていくのでは?と結んでいます。

私は「海外ではこうだ。それに引き換え日本はこうだからダメなんだ」的な記事は好きにはなれませんが、そもそもなぜ日本がITゼネコンビジネスモデルになっているかを考える必要があると思います。

海外は知りませんが、日本のIT現場では「人月」がまるで通貨単位のように現状では使われています。見積もりの段階でも、XX人月なんでXX円です。という金額計算が使用されてます。変な話ですが、「なぜ、XX円なんですか?高く無いですか?」という質問に対して「この作業がXX人月だからです」という変な会話も日本のIT業界だと十分ありえる話です。

そこでプライムベンダーはXX人に相当する人数を連れてこようとしますが、一人当たりの金額を下げないと利益は出ない為、本当に何も分かっていない人を連れてきたりします。そういうIT知識がほぼゼロの人でもものづくりに参加させるには、設計書を出来るだけ細かく書き、プログラミングをほぼタイピングのようにさせる必要があります。

全部がこのような発想とは言い切れませんが、日本ではプログラミング作業=タイピング作業ととらえている節があります。自動車工場で自動車を作るようにシステムを作り上げようという発想でしょう。まさに労働集約型+ITゼネコンビジネスモデルです。

と、本当に簡単に書きましたが、上記が日本のIT現場の典型的な仕事のしかたではないでしょうか。もちろん、Webサービスを展開する企業や、ミドルウェア等を自社で作っている会社はこの限りではありません。


現状は確かに問題点が多いとは思いますが、変わるのは時間がかかりそうです。