実はiPhone対応する自体がいいことなのか、っていうのはあったのだけどね。普通にフルブラウザがあって、タップで簡単に拡大もできるし、とか。でも、やっぱり自分がiPhone使って、他のサイトを見るときに、対応しているサイトの方がいいかな、と思うことが多くなってきたので、対応してみた。
CSSだけでできる方法で、メインのhtmlに、
<link href="/css/iphone.css" media="only screen and (max-device-width:480px)" rel="stylesheet" type="text/css" />
<meta content="width=320, initial-scale=1.0, maximum-scale=1.0, user-scalable=no" name="viewport" />を、書く。場所は元々のCSSの後にする。で、その /css/iphone.css の中で、元々のCSSを上書きする。
汎用性のないcssだけど、短いので乗せる。
h1 {font-size:1.5em; margin: 5px 5px 5px 5px; letter-spacing:0;}
h2 {font-size:1.0em; margin: 5px 5px 5px 5px; letter-spacing:0;}
#slogan {font-size: 1.0em; margin: 0px 0px 20px 10px; letter-spacing:px}
#wrap {width: 318px; text-align:none; margin: 0;}
#sidebar {float: none; width: 318px; }
#content {width: 318px; text-align:none; float:none;}
img.attach_img {max-width: 300px}
pre {width: 300px; padding: 5px; margin: 5px}やってることは、タイトル (h1/h2) の文字を小さくして、本文とか画像の最大幅をiPhoneに合わる。後は、サイドバーのfloatをやめて下に持っていくだけ。
クール！なページにしたければそれなりにcssでがんばる必要あるけど、ここぐらいだったらこれで十分。
こんな感じになる。
昨日の朝、通勤の電車を降りたらiPhoneが無くなっていた。車内で途中まで使っていたので車内でなくしたのはすぐにわかった。浅いポケットに入れていたこともあったし、車内で使っているのを見られているし、3GSだし、32GBだし、「盗まれた！」と最初は思った(日本でならそうは思わなかったかもしれないけどロンドンなので。ロンドンは基本的に安全だけど軽犯罪は多い)。
結局はただ落としただけのようで、いい人に拾ってもらって、その人が着信履歴か何かを見て家族に連絡してくれた。
ロンドンも捨てたもんじゃないなって話ではなくて、まー、つまり情けないことにiPhoneをロックをしてなかったわけだけだ。それで、もしロックしてたら、どーなってたのかなー、という話。
たとえ拾ったのがいい人でもめんどくさくて放置してしまうかもしれない。
今回のように電車で落としたなら、まだ駅関係のどこにあるかもしれないけど、その他だったらどこを探せばいいのか見当もつかない。それに悪い人はロックぐらいやぶりそうだ。
もちろん、大事なデータも入っているのでカジュアルな悪戯を防ぐ意味でもロックはしておく方がよいとは思う。
で、ロックした上で、待受画面の画像に連絡先を書いておくのはどうかと思った。これならロックした上で親切な人に連絡先を伝えられる。わりといいアイデアだと思うんだけどどうだろうか。
どっかのライフハック系にありそうなネタだけど見つからなかった。
後、昔どっかで見た、笑顔の赤ちゃんの写真を待ち受けにしておとくと戻ってくる率が高いらしいというライフハックはたまたま実行してた。 (見つけた。待ち受けじゃなくて財布だった。)
ドキュメント指向なKVSってことと、字面が似ていると言うことぐらいしか比較する意味がなさそうなCouchDBとMongoDBだけど、ここ2，3ヶ月で両方をそれなりに突っ込んで見てきたので比較してみた。実装面やパフォーマンス、ということよりはどちらかというと(私が感じる)思想的なものや、ユーザ側からの視点での比較。
共通するところ
これはもう簡単に、
- ドキュメント指向データベース - RDBMSのようなカラムと言ったものを持たずにスキーマレスで好きな情報を入れられる
- Javascript/JSONを使用 - データ自体もJSONというJavascript由来のフォーマットで持ち(MongoDBはJSONを元にしたBSONというものだが)、データベースのアクセスにはJavascriptを使用する
- スケールアウトするように考えられている
- NoSQLな流行
CouchDBの特徴
機能を限定しているが、その中にいる限りは幸せになれることを目指しているのがCouchDB。たぶんそのことを"Relax"と呼んでいる。
Viewが中心
クエリ(一般的なRDBMSで言うとSQL)のようなものがほぼないCouchDBにとって、(RESTでアクセスする)Viewがそれに代わるユーザとの接点になる。
CouchDBのViewは、RDBMSのViewのイメージとは違い、実体を持ち永続的/静的なものになっている。そのため、内部的に、同じ実体のViewがすべてのユーザでシェアされるので効率もよい。Viewを作った時点で、Viewに対するIndexも作成され(開発者が余計なことをしなくても)パフォーマンスがでる。
ただ、それを実現するためにViewを作る上での制約が多い。Viewは、map-reduce(のようなもの)を使ってドキュメント本体から作るのだが、世の中の他のmap-reduceと比べるとかなり貧弱。ちょっと複雑なViewを作ろうとすると挫折する。(例えば、A:B=1:N と B:C=1:N のような構造で、Cをキーとして、BとAも持ってくるView、とかはたぶん無理。RDBMS的に言うとJoin2回以上は無理、な感じ。)
これは、CouchDBは、ドキュメント(RDBMSで言うレコード)が一件追加(更新や削除も)されたときに、View全体を作りなおすことなく、View側もデータ一件分の変更で済ますことがでることを目指しているからだと思う。このため一つのドキュメントが他のドキュメントと関連するようなViewを作ることができない。上記の例だと、Aが追加されたときにCとの関連が(Bを経由しないことには)持ってこれないのでダメ、という感じ。
きれいにViewに落とせるようなデータ構造とViewの定義さえ作れれば、データの追加も、更新も、参照も、さほどサーバ資源を使わなくてすむし、スピードも速い。
Tableがない
もう一つの大きい特徴が、CouchDBは、RDBMSで言う”テーブル”のようなものを持たないということ。「1つのデータベース」は「何を入れてもいい巨大な箱」という感じ。
RDBMSでいう"テーブル"なような物を持つ場合には、自分でそれ用のメタ情報を各ドキュメントに持たせる必要がある。
各言語のライブラリ(mapper)では独自にそういうことをしているが、mapper間でそのメタ情報の互換性がない。また、1ドキュメントを1テーブルと見たてるようなライブラリもあるが、複数のドキュメント間ではViewを作れないのでCouchDBの大きなメリットが消えてしまう。
スキーマレスで、何でも突っ込む、というのはドキュメント指向なデータベースとしては正しいのかもしれないが、いざ、この上でシステムを作るとなるとあまりにも自由過ぎると個人的には思っている。
アプリケーションを書ける
CouchDBはアプリケーションの層までCouchDB内に書くことができる。もちろんよくあるRDBMSを使ったWebシステムのように、CouchDBを単機能な「データベース」として使い、フロントエンドは別のシステム、という構成も取れる。ただ、CouchDBが目指しているところはデータベースとアプリケーションがセットになったオールインワンなものなのかな、と感じる。
MongoDBの特徴
CouchDBと比較すると、MongoDBは「なんでもあり」と言った感じ。
なにしろ、MongoDBの公式ページの最初の宣伝文句が「Combining the best features of document databases, key-value stores, and RDBMSes」だ。KVSとドキュメント指向データベースとRDBMSのいいとこ取りのデータベースを目指すと言った感じだろうか。
一般的に、RDBMSに慣れた人がKVSなデータベースを触る場合、「RDBMSのことは忘れろ」が定石だ。実際、私もそう思うし、そうした方がいいんだろうけど、やはり長年RDBMS生活をしていると難しい面もある。MongoDBを触っていると、あちこちで懐かしいRDBMSの匂いがするので、RDBMS出身の人には入りやすいデータベースだと思う。
たとえば、以下の点でRDBMSと似ている。
- コレクション(Collection)というテーブルのようなものを持つ
- (SQLではないが)クエリーを持っている。またその書き方
- indexの考え方
- データベースチューニングの考え方
- データを直接コマンドラインから操作できるシェル的な物が付属されていたりと言った環境面
これに加えRDBMSでは色々とめんどください、データを複数のデータベースに分割して保存する(Sharding)といったKVSらしい機能がついてくるのがMongoDB。
まとめ
これらの特徴から、CouchDBは、できるだけユーザ(or/and開発者)にとって単純なインターフェースにして、(そんなに多くない)ルールにさえ従っていれば、幸せになれるものを目指している、という気がしている。
一方のMongoDBは、何でもありな方向で、多機能高機能を目指している。たとえば、RDBMSでできることはなるべく実現できるように考えられている。ただ、これは、もちろん「ごちゃごちゃ」しすぎたり「パフォーマンスが出なかったり」する原因になりやすく、そうなってくると、「なんでMongoDB？ "RDBMS"でいいんじゃない？」ということにもなってしまうので、その辺のバランスについては今後見ていきたいと思っている。
簡単に言うと、まったく新しいデータベースを目指しているCouchDBと、超現実指向のMongoDB、といったところだろか。
おまけ - CouchDB/MongoDBを始める
CouchDBは、公式ドキュメントはいまいちだが、このドキュメント(本？)がすごくよくまとまっているので、最初にこれを読むのがおすすめ。
MongoDBは、公式ドキュメントがそれなりにまとまっているのでそれを最初に読むのがおすすめ。日本語版も少しある。翻訳に関してはこちら。
追記：
CouchDB詳しい方からフィードバックを頂いたのでそちらも見てみてください。
Twitterでも少し話したのですが、私は、基本的に現行のWebシステムのどの部分をKVSに持って行けそうか、というのがベースにあるので、どうしてもそういう目線になってしまいます。それと、完全CouchDBの世界に入るにはまだ少し怖い。DocumentとViewだけで表現できることから少し飛び出すだけで、突然色々なことが難しくなるのが今のところのCouchDBと感じてます。
ただ、MongoDBはいい意味でも悪い意味でも「普通」なので、CouchDBの方が化けるかなという感じはしているので期待して追って行こうと思ってます。
RSSリーダで読む