やってしまった。MacBookを机から落とした・・・。

どうせ壊すなら、水没の方がウケが良かっただろうに・・・。

去年でAppleCareも切れたんだよなぁ・・・。はぁ。

追記 02/06 0:15
　早速、新しいMacBookPro 15を買ってきました。

　アンチグレアとか、SSDが欲しかったけど、店頭では扱ってないらしいので、あきらめました。
アンチグレアは後日シートでも買います。

　メディアを見ていると、iPadを「電子書籍端末」として、取り上げられていることが多い様に感じますが、ほんとにユーザは電子書籍を読むんでしょうか？

　もちろん、iPadの使い道として電子書籍ビューアもありますが、Appleもあまり重要視していないようで、Jobsのプレゼンの「iPadの使い方」の中でも一番最後でした。^@naofumi

　すでに出版業界は壊滅的と言われ、１世帯あたり月の雑誌購入額が376円、書籍を入れても月1000円程度、すでにKindleやiPadなど、5万近いを買って書籍を読むユーザは居ないことを示唆しています。

　また、AmazonはKindle向けの電子出版では印税を70%に設定するなど、積極的に動いてます。

　しかし、これは単純に流通コストだけの話で、校正も装丁も責任も取らないので、既存の出版社と比べるのは、無理な話です。

　もし、それらを自分で行ったとしても、電子書籍は、紙の書籍に比べて価格が安くなっています。その為、印税率が上がっても、実際の手取りが上がるかは不透明です。

　紙の書籍には、閲覧性の高さや、質感、借り貸しが出来る、書き込める、軽い、電気が要らないなど多数のメリットがあります。

　これに対して、電子書籍のメリットは、どこでも買える、場所を取らない、検索できる、絶版になりにくいではないかと、思います。

　しかし、これらのメリットは、多くの人が書籍を買わなくなった今、ほとんどの人に取ってメリットになり得ません。唯一「どこでも買える」というのがメリットですが、一般雑誌は、コンビニでも駅の売店でも手に入りますし、地方に居てもAmazonがあります。

　さらに電子書籍は、ディスプレイで表示した時点で、Webと戦う事になります。
　多くのメディアがWebサイトを提供し、多くの個人がブログを書いている昨今、コンテンツの差だけで、お金を払うようになるのは難しいのではないでしょうか。

　ユーザに取って、電子書籍は「有料Web」程度の扱いになると考えられます。

　Webサイトの有料購読は、多くのサイトが挑戦して、失敗してきています。2011年からNY Timesが有料化に踏み切りますが、動向が非常に注目されます。

　電子書籍だけでは、読者に取って新しい価値はほとんど無いように思えます。

　可能性があるとすれば、購入履歴の公開、読者同士のコメントや、補足情報の書き込みなどソーシャル化ではないかと思います。
　今のところ、Kindleなどの電子書籍ビューアでそのような機能を積極的に採用している例は聞きませんが、本を単にデジタル化しただけでは、電子書籍が一般に普及することはないのでは無いかと思います。

追伸
　あと、電子出版を専業したら出版社が出て、新しい価値を作ってれるんじゃないかと期待してます。

次回予告
　iPadを販売支援とかに使うのが面白いんじゃないかなー？って話です。

　iPadが発表され、いろいろなメディアやブログで紹介されています。
ハードウエア的には目立ったところがないため、多くの人に取ってあまり目新しさがなく、残念に思った人も多かったように感じます。

　私がiPadに期待するところは、タブレット型デバイス向けの、新しいユーザインタフェースです。
　うちには、富士通製のWindowsXPのピュアタブレット(キーボードが無くペンだけで操作するタイプ)があります。
ちょっと重いのですが概ね便利で、布団や居間でネットをするときに使っています。

　しかし、普通のWindowsアプリケーションは、マウスでの操作を前提にしているので、余り使いやすくありません。
普通は、Firefoxを起動しっぱなしにしているのですが、いくつかアドオンを入れて、さらに自作のアドオンも使っています。

　iPhoneが成功した一つの要因に、OSXのユーザインタフェースを引き継がずに、小さいタッチパネルディスプレイ用にユーザインタフェースを設計したことがあると思います。
入力方法も画面サイズも違うデバイスですから、PC用とは異なったユーザインタフェースが必要になります。

　同じようにタブレットサイズのユーザインタフェースは、iPhoneとも、デスクトップとも違うものが要求されます。

　アップルのPRビデオを見ていると、ドロップダウン式のメニューや、左右の２ペインなど、iPhoneでは見たことのなかったUI部品が使われていることが分かります。
　実際に指で画面を触るUIを多くのiPhoneユーザが体験し、デベロッパーもそれに慣れています。その上で画面の大きなiPadが出て、ユーザもデベロッパーもそれについて行くという流れができています。

　iPadは、大衆向けの製品としては、初めてタブレットサイズに最適化されたUIを持った製品だと言えます。

　MSは、数年前からTabletPCをリリースしていますが、これはノートパソコンにタッチパネルをくっつけただけのものでした。
多くの人が自由に扱えるパソコンに必要だったのは、タッチパネルだけではなく、それに最適化された新しいUIだったのだと思います。

　ビルゲイツは、1990年に”Information at your fingertips“というコンセプトを掲げました。私はこのコンセプトにとても感銘を受け、いまでも好きな言葉の一つです。
　しかし、このコンセプトに見合う製品は、その後MSからリリースされてきませんでした。MSは過去の資産から抜け出せず、せいぜい”Computing at your fingertips”止まりだったと思います。

　iPhoneが出たときに、”Information at your fingertips”といえる初めての製品が出た。それもアップルから！と感動しましたが、iPadは扱えるInformationをさらに大きく広げ、一般的なWebや動画も十分に鑑賞できるようになっています。

　iPhone向けのUI部品では、iPadの画面は大きすぎます。そのため、多くのデベロッパーは、iPad向けに画面の再設計を行うことになると思います。
　その時に多くのアプリケーションが、「情報を直接、指で扱う」感覚を持ち、それを多くの一般ユーザがリビングで操作する、そんな世界が広がるのが非常に楽しみです。

p.s
　iPadが出るときに期待された点の一つに、マルチタスクがあります。

　Google携帯こと、Androidではマルチタスクがサポートされ、アプリケーションの中で辞書を引いたり、常駐するアプリケーションが、アラートを鳴らしたりと、iPhoneでは出来なかった多くのことができるようになっています。

　その代わり、ユーザはアプリケーションが使うメモリ量やバッテリに気を遣う必要が出て、さらにアプリケーションがクラッシュした際の原因究明が非常に困難になります。
　多くのユーザはメインメモリと、ハードディスク容量の区別が付きません。そんな中、同時にアプリケーションを起動するとアプリが落ちる、などということを理解させるのは困難です。

　またウイルスやスパイウエアが発生する可能性が高くなり、アンチウイルス的な仕組みが必要になってくる可能性もあります。

　Windowsの様に使っているとよく分からないけど重くなる、アンチウイルスは必須、とならない為に、マルチタスクのサポートはこの先も行われることはないと思います。

　個人的には、マルチタスクは欲しいですが、自分の両親にiPadを持たせることを考えると、マルチタスクと引き替えに、メンテナンスの必要性が少なくなるのは大歓迎です。

p.s – 2
　iPad用の鞄をどうするか激しく迷い中。
MacbookPro用に使ってる、MEGALOPOLISじゃでかいしなぁ。
SAMには入らないし、今持ってる、Tumiのバッグには入るかなぁー。
PEOPLES DELITEを買おうかなぁー。
　iPad用じゃないけど、MEGALOPOLIS A1欲しいなぁー。

　CSSで、式とかマクロが使えたらなーと思うことがよくあるので、この際だからプリプロセッサを作ろうと思っています。

　文法としては、CSSの構造を大きく変えないで行きます。あくまでプリプロセッサ的な役割で。Sassの様に構文を変えてしまうと、デザイナーの人が取っつき難くなりそうで。

　今のところ、考えている文法の例を下に置きました。誰でも考えそうな所で、includeによる読み込み、ネストをサポート、式と制御構造のサポートを行います。

　このプリプロセッサはサーバサイドで動的に生成するのではなく、一度静的にCSSに変換して使うことを考えています。その為、User agentなど外部からの変数はサポートしません。

　使い方としては、コマンドラインツールによる変換と、Javascriptによる動的な読み込みをサポートする予定です。
開発中は、HTML内に<script src=”ecss_loader.js?test.ecss”></script>と書くことで、サーバに何も導入することなく、動的に拡張されたCSSを読み込むことが出来るようにします。

　文法や機能のアイディア、同じようなプロダクトを知っている！と言う方がいましたら、ぜひコメントお願いします。

例)

%include "common.ecss";
%focus_color = "#4444ff";
%w = 32;
%property x-opacity $value
  opacity: $(value);
  filter: alpha(opacity=$(value*100));
%end

#mailbox {
  width: $(w+2+"px");
  border: 1px solid gray;
  .item {
    width: $(w+"px");
  }
  .focus {
    background-color: $(focus_color);
  }
  .disable {
    x-opacity: 0.5;
  }

%for x in ['red', 'green', 'blue']
  $(".item-"+x): background-color: $(x);
%end

%if debug==1
    .item {
      background: red !important;
    }
%end
}

　前回、最後にGeohashのエンコード・デコード方法を解説、とか書いたのですが、私が書く前にyuroyoroさんがブログで解説していました。しっかり解説されているので、ぜひ、そちらをご覧ください。

　Geohashのミソは、座標を2進数にして、それを交互に並べる所にあります。そしてそれをBASE32でエンコードすることで、座標を文字列にして表現しています。
　BASE32は、5ビットで1文字なので、Geohashの長さが奇数の場合は、経度の方がビットが短くなります。 (例: 5文字の場合 全25ビット 緯度が13ビット、経度が12ビット)
　そのため、グリッドの大きさが、Geohashが奇数の場合は縦長、偶数の場合は横長になります。

　ビット列から文字列へのエンコード方法に、BASE32を使っているのは大文字小文字を区別しないためだと思いますが、これを16進数で表したら、もっと細かいグリッドで表現できるのではないかと思い、試してみました。

　そうしたところ、BASE32では6〜8文字で、600m、150m、19mとなるところ、16進数では7〜9文字で、1200m、305m、76mとなります。この感じだと、グリッドの大きさ的にも、BASE32の方が使いやすいように見えます。

　このアルゴリズムは、2次元の座標を1つの文字列にまとめることができ、緯度経度以外の座標系にも応用できるんじゃないかと思います。

　これは、その名の通り、位置情報をハッシュで表す規格なのですが、いろいろおもしろい特徴があり、調べているうちに楽しくなってきたので、勢い余ってPure Rubyのライブラリまで書いちゃいました。

　そのあと、結局ライブラリを作ったところで満足して、アプリは何も作らなかったので、せめてGeohashの解説でも書いておこうと思います。

　位置情報は通常、緯度経度で表します。たとえば東京タワーの緯度経度は35.65861, 139.745447です。
北を上にした地図でいうと、緯度がY座標で経度がX座標です。英語では緯度をlatitude、経度をlongitudeと呼びます。

　この緯度経度は測地系によって値が違いますが、ここではGPSなどで使われている世界測地系を前提にします。

　位置情報系のアプリでは、「今いる場所をGPSで取得して、その近くにあるランドマークを表示する」ということがよく行われます。
　これをGoogle App EngineのDataStoreで行おうと思うと、2つのカラムで比較ができないという、DataStoreの制約が問題になります。(例: x>1 and y>1の様なことができない)

　そこで、GeoHashの登場です。GeoHashは、緯度経度の二つの座標を、一つの文字列にまとめたものです。

　東京タワーをGeoHashで表現すると「xn76ggrw26」になります。GeoHashはグリッドになるので、緯度経度のようにポイントではありません。
　先のハッシュが8文字あると、19m*31mのグリッドになります。

　GeoHashの最大の特徴は、その長さによって精度が変わることです。
東京タワーを中心とした 19m*31mのエリアは「xn76ggrw」ですが、これを頭5文字「xn76gg」だけ取り出すと、下の図の様なエリアを表します。

　データベースから、「xn76gg」の前方一致で検索することで、エリア内のポイントを簡単に取り出すことができます。

　しかし、これでは、上の図の様に、ランドマークがメッシュの端にある場合、すぐ近くのポイントもヒットしなくなってしまいます。
　
　そこで、geohashで検索する場合は、右の図の様に隣接するブロックも同時に検索します。東京タワーの周りを探す場合は、「xn76gg」だけを検索するのではなく、’xn76gu’,'xn76gf’,'xn76u5′,’xn76ge’,'xn76gs’,'xn76uh’,'xn76u4′,’xn76gd’,'xn76gg’も同時に検索することで、おおよそ2km*3kmの範囲で検索が可能です。

　多くのGeohashライブラリには、隣接するGeohashコードを計算する関数が用意されています。
それを使い、上記のように近接のブロックのGeohashコードを同時に検索することで、東京タワーからおおよそ1〜1.5kmのポイントを割り出すことができます。

　GAEのDataStoreは、文字列の前方一致が高速に行えるので、Geohashで場所の絞り込み検索などを容易に行うことができます。

　緯度経度から、Geohashで計算するライブラリは各種言語用にリリースされています。
Pure Rubyで書かれたライブラリが無かったで、自作したライブラリもありますので、Rubyの人はぜひ下記のコマンドでインストールしてみてください。

gem install pr_geohash

使い方は、READMEをご覧ください。

　実際にGeohashを試すことの出来るデモを下記のURLに設置しました。興味のある人は、直接触ってみると簡単に使い方が分かると思います。
http://blog.masuidrive.jp/wp-content/uploads/2010/01/geohash.html

　緯度経度を精度も含めて、文字列一つで扱えるのでURLに位置情報を入れたい場合など、便利なケースがあるんじゃないかと思います。

　Twitterでも緯度経度じゃなくて、Geohashで位置情報を管理してくれたらよかったのに。
そしたら、5文字ぐらいにすることで「だいたいシアトルにいる」みたいな大まかな位置情報だけ公開するとかできて、プライバシー的にも利点があったのになー。

p.s
　Geohashのエンコーディング方法の解説も欲しいって人います？
もし居たらコメントください。

追記 01/13 0:34
　Geohashのアルゴリズムを書きました。

参考データ:

=begin
東京付近のGeoHashの精度を算出するRubyスクリプト

|文字数|   南北  |   東西  |
|    6 | 609.08m | 988.77m |
|    7 | 152.27m | 123.60m |
|    8 |  19.03m |  30.90m |
|    9 |   4.76m |   3.86m |
|   10 |   0.59m |   0.97m |
=end

puts (6..10).map {|i|
  lng_bit = (5 * i / 2.0).ceil
  lat_bit = (5 * i / 2.0).floor
  lng_grid_size = sprintf("%6.2fm", (360.0 / (2 ** lng_bit))*(25.0*60*60))
  lat_grid_size = sprintf("%6.2fm", (180.0 / (2 ** lat_bit))*(30.8*60*60))
  [i, lat_bit, lng_bit, lat_grid_size, lng_grid_size]
}.map{|r| "|#{r.join('|')}|"}.join("\n")

　ここ最近、海外のブログで「NoSQL」という単語をちょこちょこと見るようになりました。

　これは新しいデータベースのムーブメントで、「SQL=リレーショナル」ではないデータベースの事を指しています。

　NoSQL DBサーバの有名な物は、Facebookがリリースした「Cassandra」、Erlangで書かれた「CouchDB」、日本からは、mixiがリリースしている「TokyoTyrant」があります。
　またGoogle App Engineでは、DataStoreというBigTableベースのNoSQLサービスが提供されています。

　ある程度ユーザを集めたコンシューマ向けサービスは、大抵の場合パフォーマンスとの戦いとなります。

　技術誌の中でも「スケールアウト技法」的な記事を目にすることが増えてきたことからも、多くのサイト運営者が、パフォーマンスの問題を抱えていることがわかります。

　多くの場合、問題になるのは、データベースのパフォーマンスです。

　アプリサーバは台数を増やせばその分パフォーマンスが向上するケースが多いですが、データベースは、単純にサーバを増やしてもパフォーマンスは向上しません。

　そこで、スケールアウト（サーバの台数を増やしてパフォーマンスを向上させる手法）がしやすいデータベース＝NoSQLDBを導入しようという流れが出てきています。

　WikipediaのNoSQLの項目をみると、既に20個近いNoSQLなデータベースサーバが並べられています。

　この2週間ほど、Google App Engine(GAE)に挑戦しているのですが、ここではDataStoreというNoSQLのデータベースしかサポートされていません。

　このDataStoreはSQLの様な複雑なクエリーをサポートしておらず、「SELECT * FROM users WHERE x>10 AND y<10」の様に複数のカラムに対しての比較演算や、「SELECT count(*) FROM users」の様に集合関数を使うこともできません。

　初めは「こんなデータベースでプログラムが組めるのか？」と心配でしたが、データの構造をよく考えることで、多くの場合、乗り越えることが出来ることが分かってきました。

　まだデファクトスタンダードもないので、一般に使われるようになるまで、2,3年かかるかもしれませんが、トラフィックやデータ量の大きいサイトでは必須の技術になると思います。

　リレーショナルからNoSQLのデータベースの移行は簡単ではなく、ものすごく大きなパラダムシフトになります。
　この頭の切り替えは結構大変で、今からGAEなどを通じて慣れておかないと置いて行かれそうと思い、勉強中です。

参考リンク

• Rackspace Cloud Computing & Hosting | NoSQL Ecosystem
• SQL Databases Don’t Scale
• 6 Reasons Why Relational Database Will Be Superseded | HaveMacWillBlog (aka Robin Bloor’s Blog)

　これは、MySQL 5.1がセットアップしてあるインスタンスで、Small(1CPU, 1.7 GBメモリ)〜Quadruple Extra Large(26CPU, 68 GBメモリ)までスペックが提供されています、Smallは$0.11/時 ($81/月)か。Largeだと$0.44時で$327/月なので、通常のEC2よりはちょっと高めの様です。
　EC2と違うのは、ネットワーク代は別でDBへ外部からアクセスした場合には、1GB辺り、Inは$0.10、Outは$0.10〜$0.17掛かります。

　これ以外に、1GB辺り$0.1のストレージ代と、100万IOアクセス辺り$0.1の代がかかります。この辺はEBSと同じみたいですね。

　アプリケーションからアクセスする場合、今までのMySQLと同じように見えるので、特に変更無く使えるようです。

　インスタンスを起動した後でも、ディスクやインスタンスのサイズを変えることができるようです。
しかし、その場合には、行う時間に制限があり、その間はデータベースが使えなくなるようです。(要調査)

　FAQを読んでいると、「High Availability option for Amazon RDS」という、複数のavailability zonesにまたがって同期レプリケーションを行うサービスを提供する予定があると書いているので、普通の非同期なレプリケーション以外にも何か提供してくるのかもしれません。

修正 10/27 21:00 JST
　ネットワーク代が掛かると書いていましたが、EC2などと同じでAWS内の場合は無料でした。

とりあえずツールのインストール

1. 下記のURLからツールをダウンロードして解凍
http://developer.amazonwebservices.com/connect/entry.jspa?externalID=2928&categoryID=294
2. binにパスを通す
3. export AWS_RDS_HOME=~/local/RDSCli-1.0.001 の様に環境変数AWS_RDS_HOMEを設定

リンク

• Amazon Relational Database Service (Amazon RDS)
• DeveloperGuide
• FAQ

　さらに、各レシピのページに「簡単リンク　外部のブログにこのレシピのリンクを貼れます」って書いてあるのに。

　「トップページ以外にリンクしては行けない」という話は、「ディープリンク問題」としてかなり昔から議論され、もうとっくに「他人にディープリンク禁止は強制できない」ということで決着しているものだと思っていました。

　どうしてもディープリンクを禁止したい場合は、サイト側で技術的に対策が可能です。
　ニュースサイトのITmediaでは、画像への外部からのリンクを禁止し、実際に外部からリンクを行っても画像が見れないように対策されています。また検索エンジンにリンクされたくない場合は、robots.txtと言う方法で簡単に行えます。

　本意はディープリンク禁止ではないかもしれませんが、ネット系ベンチャーとして、いまさらディープリンク禁止を掲げるのは、恥ずかしくないのかなぁ。

[追記]
　リンクに関するページが更新された模様。素早い対応、すばらしい！

　でも「クックパッドにリンクしていること自体をサイト運営や
営業の手段としないでください。」ってどういう意味だろう？
これだと、「美味しいレシピを見つけましたブログ」の様な形態のサイトを作る事は、NGって事かな？
クックパッドにリンクしている言うことを目立つところに書かなきゃOK?

しかし、そのままだとmerb 1.0.12ではエラーが出て動きません。
そのときは、下記のコードを適当な所で実行してください。

class Merb::Orms::DataMapper::Associations < Merb::BootLoader
   def self.run
     DataMapper::Model.descendants.each do |model|
       include DataMapper::Resource
       touch_child_keys(model)
     end
   end

   def self.touch_child_keys(model)
     model.relationships.each_value { |relationship| relationship.child_key }
   end
end

引用元