お掃除ロボ ルンバ527

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

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

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

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

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

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

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

高さはティッシュボックスより少し高い程度？

我が家のソファーの下には残念ながら入れませんでした。。

よく分からない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もくそも無いはずだ。


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


・Ｐ（ネットワーク分割耐久性）の定義も不明。何となくだが、スケールアウト出来るか、出来ないか？という事だろうが、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：
あるデータを更新後、他のユーザからの参照時に必ず更新後のデータが読める事。
※ＡＣＩＤでの"Ｃ"とは直接関係は無い。


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


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

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


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


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


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


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


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

HackerJapan

HackerJapanという雑誌。

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

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

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

ＩＴゼネコンビジネスモデル

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

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

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

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

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

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

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

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

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


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

HTTPHeaderの"Server"をいろいろ確認してみた（ドイツDAX編）

HTTPHeaderのServerをドイツの株式指数(DAX)を構成している銘柄で確認してみました。
英語社名をgoogleで検索しましたが、困ったのはgoogleで1位となるのはドイツ語のサイトでは無かった為、ドイツ語のページがあればドイツ語のページを確認し、英語のページしか見当たらない場合には英語のページを確認しました。結果は以下の通り。。。



アディダス Microsoft-IIS/6.0
アリアンツ Apache
BASF -
バイエル Microsoft-IIS/7.5
バイヤスドルフ Consultix WebServer
BMW BMW Webservice
コメルツ銀行 Apache
ダイムラー IBM_HTTP_Server
ドイツ証券取引所 -
ドイツ銀行 -
ドイツ・ポストバンク Apache
ドイツポスト WEB
ドイツテレコム Apache
エーオン Apache/2.0.59(Unix)  PHP/5.2.3  mod_jk/1.2.23  mod_ssl/2.2.13 mod_perl/2.0.3 Perl/v5.8.8
フレゼニウス -
ヘンケル Apache/2.0.49 (Linux/SUSE)
インフィニオンテクノロジーズ Apache-Coyote/1.1
ルフトハンザドイツ航空 IBM_HTTP_Server
リンデ Microsoft-IIS/6.0
マン Apache-Coyote/1.1
メトロ Microsoft-IIS/5.0
メルク -
ミュンヘン再保険 Microsoft-IIS/6.0
RWE Server
SAP Microsoft-IIS/6.0
K+S Apache/2.2.10(Unix) DAV/2 mod_jk1.2.27 mod_ssl/2.2.10 OpenSSL/0.9.8a
シーメンス Microsoft-IIS/7.0
ザルツギッター Zope(Zope 2.7.5-final, python 2.3.5,linux2) Zserver/1.1
ティッセンクルップ Apache/2.2.13(Unix) mod_ssl/2.2.13 OpenSSL/0.9.8k  DAV/2  PHP/5.2.10
フォルクスワーゲン Apache

NYダウよりも若干Server名を変更してたり、Server名を出して無かったりする会社が多いかなー。。。というところでした。まあ、何回もやってるのであまり新鮮味は無いです。


尚、FireFoxで簡単にServerヘッダが分かる・・・と以前書きましたが、正確にはアドオンでLiveHTTPHeaderを入れれば分かる。。でした。

HTTPHeaderの"Server"をいろいろ確認してみた

HTTPには応答headerとして"Server"があります。クライアント側から送信する"User-Agent"のサーバ版みたいなものなんですが、セキュリティ監査等で「"Server"を表示していると、サーバ側のハードやミドルウェアが攻撃者に分かってしまう為、消した方が良い」と指摘される事があります。
日本の大企業は一体"Server"をどういう設定をしているのか？以下はTOPIXを構成する銘柄100社のServerヘッダを確認した結果です。"-"はServerヘッダが無かった企業です。以外に少ないのが以外でした。（FireFoxだと簡単にHTTPヘッダの値が確認できます）　日本語の社名をgoogleで検索し、１位にヒットしたページを確認してます。



国際石油開発帝石 Apache
大和ハウス工業 Mircosoft-IIS/6.0
積水ハウス Apache/2.0.46 (Red Hat)
キリンホールディングス Apache
日本たばこ産業 Apache
セブン＆アイ・ホールディングス Apache
東レ Apache/2.0.61 (Unix)
旭化成 Sun-ONE-Web-Server/6.1
住友化学 Apache
信越化学工業 Apache
三菱ケミカルホールディングス Apache
花王 Mircosoft-IIS/6.0
武田薬品工業 Apache
アステラス製薬 Apache
エーザイ －
第一三共 Apache
ヤフー －
富士フイルムホールディングス Apache
資生堂 Mircosoft-IIS/6.0
新日本石油 Apache
ブリヂストン httpd
旭硝子 Apache/1.3.37(Unix)mod_jk2/2.0.4 mod_ssl/2.8.28 OpenSSL/0.9.7m
新日本製鐵 Apache
住友金属工業 IBM_HTTP_Server
神戸製鋼所 Apache
JFEホールディングス Apache
住友金属鉱山 Apache/2.0.52 (CentOS)
住友電気工業 Apache/2.0.59(Unix) mod_ssl/2.0.59 OpenSSL/0.9.9a mod_jk/1.2.19
ＳＭＣ Mircosoft-IIS/6.0
小松製作所 Apache
クボタ Apache
ダイキン工業 Apache
日立製作所 Apache
東芝 Apache/MAGNIA
三菱電機 Apache
日本電産 Zope(unreleased version, python2.3.3, linux2) Zserver/1.1
日本電気 Apache
富士通 Apache
パナソニック －
シャープ Apache
ソニー Apache
ＴＤＫ Mircosoft-IIS/6.0
キーエンス －
デンソー Apache/1.3.41 (Unix)
ファナック Apache
ローム Apache
京セラ Apache
村田製作所 Apache
日東電工 Apache
三菱重工業 Apache
日産自動車 IBM_HTTP_Server/6.0.2.7 Apache/2.0.47(Unix)
トヨタ自動車 －
本田技研工業 IBM_HTTP_SERVER
スズキ Apache/2.0.46 (Red Hat)
ニコン Apache
ＨＯＹＡ Apache/2
キヤノン Apache
リコー Sun-ONE-Web-Server/6.1
凸版印刷 Apache
大日本印刷 Apache
任天堂 Apache
伊藤忠商事 Sun-ONE-Web-Server/6.1
丸紅 Apache/2.2.15(Unix) mod_ssl/2.2.15 OpenSSL/0.9.8m
三井物産 Apache
東京エレクトロン Apache
住友商事 Apache/2.0.52 (Red Hat)
三菱商事 Apache
イオン Apache
三菱ＵＦＪフィナンシャル・グループ Apache
りそなホールディングス IBM_HTTP_Server
三井住友フィナンシャルグループ IBM_HTTP_Server
横浜銀行 Apache
住友信託銀行 －
みずほフィナンシャルグループ Apache
オリックス Apache
大和証券グループ本社 httpd
野村ホールディングス －
三井住友海上グループホールディングス Apache
損害保険ジャパン Mircosoft-IIS/6.0
東京海上ホールディングス Apache
Ｔ＆Ｄホールディングス Apache/2.0.52 (Red Hat)
三井不動産 Apache
三菱地所 Apache
住友不動産 Apache
東日本旅客鉄道 －
西日本旅客鉄道 Apache/2.0.52 (Red Hat)
東海旅客鉄道 IBM_HTTP_Server
商船三井 Apache
日本電信電話 Apache
ＫＤＤＩ Apache
エヌ・ティ・ティ・ドコモ Apache
東京電力 Apache
中部電力 Apache
関西電力 Apache
東北電力 (Unix)
九州電力 Apache
東京瓦斯 Apache
セコム Sun-ONE-Web-Server/6.1
ヤマダ電機 IBM_HTTP_Server/1.3.6.4 Apache/1.3.7-dev (Win32) PHP/4.3.10
ソフトバンク Apache

この調査をするまではServerなんて誰も表示していないだろうと思ってましたが、結果は意外にもほとんどがServerを表示していました。"Apache"については細かいバージョンを出さなければ問題は無さそうですが、IIS、IBM、SUN のように思い切り名前を出している場合があり、即脆弱性がどーのという話にはなりませんが、あまり好ましくないように感じます。

個人的に笑えたのは以下です。

・ヤマダ電気→IBM_HTTP_Serverのバージョンが古すぎないだろうか？

・日本電産→Zope(unreleased version, python2.3.3, linux2) Zserver/1.1　とある。ここまでOSSの名称を出すのは珍しい。同社はPythonが好きだと思われる。

・東芝→Apache/MAGNIA　MAGNIAとは自社で出しているIAサーバのブランド名のようである。自社愛なんだろうか。

・セコム→同社は情報セキュリティ分野にも強い。思いっきり"SUN"と出ていて少しがっかりした。

【番外編】

三菱東京UFJ銀行のHPを個別に確認したところ、、

"MUFG Web Server/1.0"と表示された。

いつバージョンが1.1になるのか目が離せない。

↑ここからも分かるように現状ではサーバ側のソフトによっては、結構自由な値を設定できるようである。

いずれにせよ、、デフォルトのままだとServer名に自社名を出すというのは自信の表れかも知れないが、次期バージョンあたりではIBMさんもMicroSoftさんもOracleさんも(

+東芝さんも）控えた方がいいんじゃないだろうか。

SSL/TLSで使用している暗号を銀行のサイトで確認してみた

Webサイトを閲覧時の暗号通信には通常SSL/TLSが使用される。

（実際にはほぼTLSであり、SSLが使用される事はまずない）

どういった暗号を使用して通信を行うかはクライアントPCとサーバ側のSSL/TLSのHandShakeにより自動的に決定される為、何の暗号が使われているかを意識する事は少ない。実際にどういう暗号が使われているのかを確認する方法としては、FireFoxで見るのが簡単だ。

以下はみずほ銀行のネットバンクをFireFoxで表示させて、暗号モードを確認した例だ。

かなりはしょって表示されるが、AES-256 256bit（高強度の暗号化）と表示された。

その他のサイトはどうなってるのか？個人的に興味があったので日本の銀行系のサイトに対して確認を行った。結果は以下の通り。

（個人向けのインターネットバンキングと思われるサイトを確認してます）

【AES-256だったサイト】

東京三菱ＵＦＪ銀行、みずほ銀行、りそな銀行、ゆうちょ銀行、ソニー銀行、楽天銀行

【RC4-128だったサイト】

三井住友銀行、セブン銀行、住信ＳＢＩ銀行、シティバンク、ジャパンネット銀行、新生銀行

AES-256、もしくはRC4-128に二分される。尚、クライアントPCはWin VISTAである。どちらの暗号がいいのか？それはもちろんAES-256である。


じゃあ、RC4-128だとダメなのか？と言われるとそういうわけでも無く、暗号強度は十分であり、少なくとも盗聴されたとしても解読される事は無いだろう。


しかし、、、近年のサーバ側の機器やソフトウェアはほぼ間違い無くAES-256に対応している事を考えると、上記でRC4-128となっているサイトは
①サーバ側の機器／ソフトが古い
or
②サーバ側の機器／ソフトは最新だが、暗号云々に詳しい人がいない、もしくはさして関心が無い
のいずれかじゃないかなと思う。


私も上記でRC4-128の銀行を使用しており、、、
早くAES-256にして欲しいなと思う今日この頃。。