2015年4月6日月曜日

WorldEye

WorldEyeは学研のデジタル地球儀だ。
正確には半球形ディスプレイだ。
様々な応用が考えられる面白いデバイスだ。

表示できる動画および画像のサイズは480 x 480である。
例えば、以下のような画像を表示させてみる。



付属USBメモリのFREEフォルダに入れ、本体のメニューで選択すればよい。
ちなみにmini HDMI端子が付いているので、PCの映像も表示できる。ケーブルが手元にないので、まだ試していない。

上の図は円を等間隔で描いたものだ。しかし、残念ながらWorldEyeでは等間隔で表示できない。見た目には気にならない程度だが、中心は短く、周辺は長くなる。もっとも内側の円の半径は約4.6mmだが、順に4.7mm、4.95mm、5.3mmと間隔が長くなる。微妙に比例でないのが困る。中心と周辺で約1cmの差ができるので、無視するわけにもいかない。

この辺は座標変換の問題なのか、デバイスの問題なのかよくわからない。
ちなみに、WorldEyeの地球儀データはきちんと補正されている。

おそらく魚眼カメラの映像を表示したり、Ricoh Thetaのパノラマ映像を表示することを考える人がいるだろう。
しかし、魚眼カメラの比率とはかなり違うし、Thetaの映像とは向きが違う。単純にはいかない。
魚眼カメラではないが、Google Earthを表示してみたので、比べるとよい。経度の長さがかなり違う。


2015年3月19日木曜日

Leap Motion + Smartphone

マルチタッチが革新的なスマホを生んだ。(単にスマホがマルチタッチを選んだだけかもしれないが、マルチタッチがなければスマホの成功はなかったろう。今まで失敗し続けたPDAが証明している。)
さらに、もう一段進化すると、今度はノータッチになるかもしれない。Leap Motionとスマホの組み合わせだ。スマホ画面から離れたところでアクションし、操作するようになるかもしれない。
Leap MotionはKinect同様の赤外線3Dスキャナ、モーションセンサといってよい。
現在のところ、かなりのCPUパワーを必要とするが、スマホがそれだけのパワーを手に入れるのは時間の問題だ。
ただし、片手がスマホで埋まってしまうことがおしい。どのように使うとよいか考えることが楽しい。

2015年3月8日日曜日

ヒトを知るプロジェクトからヒトを創るプロジェクトへ

少し前はヒトゲノムが話題になった。実に実りあるプロジェクトだったと思う。
今度はヒューマンブレインが話題となっている。同様に多くの成果が期待できる。

しかし、ゲノムに比べると成果は限定的となる。
機械による知性は楽観的にできるだろうと予測する。
しかし、より欲しいのは知識のコピーである。
ヒトが考えるしくみがわかったとしても、生きている人の脳に干渉できなければ、コピーはできない。
よって、ナノマシンの研究が不可欠である。むしろ、ナノマシンの成果に依存している。

ヒトの脳にチャレンジすることは意義深い。
しかし、人工知能を作るだけなら、必ずしもヒトである必要はない。知性が最低でもあるとされる生物であれば、何でもよい。
しかし、ねずみの脳が大きくなればヒトの脳になるかどうかは断言できない。

人は脳だけで生きている訳ではない。
生命の定義は有機であるがゆえに、人工知能は機械である。
人工知能の進化には、五感が重要である。
少なくとも視覚、聴覚は脳と直結して学習する必要があるだろう。
これらのインターフェースもヒューマンブレインの成功には不可欠であろう。
あるいは、これらがあれば、もっと豊かな成果が期待できる。

よって、ブレインの次は人体の創生が課題となるだろう。
再生医療の発達も時期を同じくしている。
個別に作成した臓器を組み合わせる方法がもっとも初期に選択されるだろう。
この場合、新たな生命を生み出すのではなく、医療の一環として考えられる。

次は、人工細胞が課題となるだろう。
細胞から分化し、発達する過程を調べる。
さらに発達の過程を制御し、不具合を除去する必要がある。
また、事前に遺伝疾患を除去しておく必要がある。
これにより発達障害の多くが克服されるだろう。


フォグレットの課題

フォグレットは、現実世界に仮想空間を実現できるだろうか?
将来的な問いの意味により答えは変わる。

仮想世界を物体として実現したいなら、多くの課題があり、困難である。
1つは、当然だが、ナノテクの進歩によりフォグレットが実現できることが前提である。
1つは、フォグレットの結合方式が問題となる。機械的な結合でなければ加えられる力に耐えられない。極端な話、自重で瓦解する。
1つは、エネルギーの供給である。無線による電力供給を仮定しているのでは、永続的な仮想空間は実現できない。同様にエネルギーが必要となる磁気的な結合も困難である。

現実的な可能性としては、3Dプリンタなしに3D造形を実現するクレイとしての応用であろう。
単に形を作るだけなら、エネルギーの問題も発生しない。結合方式も機械的でよい。ただし、用途によっては強度が足りない可能性もある。

仮想世界をフォグレットのみで仮想的に実現したいなら、可能かもしれない。
フォグレットは人体の内部から視覚と聴覚を操作する。
どうやってというのはよくわからない。これも当然課題の一つだ。しかし、できるという人はいる。
この方法は理性を保ったまま幻覚を見ているようなものだ。
物理的制約はずっと少ないが、倫理的制約はずっと高くなる。
文化は技術ほど簡単には変わらない。しかし、技術がある世代の大半に普及したとき、文化は一気に変わる可能性がある。それでも、その他の世代との競争により淘汰される可能性がある。


2015年2月28日土曜日

Kindle

Kindleを買った。
今までは、iPhoneにもKindleアプリを入れているので、わざわざ買う理由がなかったのだが、iPhoneでは画面が小さすぎるのでKindle購入に踏み切った。
今回の購入は自分のためではなく、スマホが使えない人向けだ。
紙に比べて便利な点が多くある。
1. 字を拡大できる
2. その場で辞書を引くことができる
スマホに比べても利点がある。
3. 画面が大きい。
4. 消費電力が小さい。
5. 価格が安い。
もちろん欠点も多々ある。しかし、価格や消費電力とのバランスの問題だ。

Kindleを家族で使い分けるには、アカウントで接続した後、コンテンツをダウンロードし、使わせる前にアカウントの接続を削除すればよい。

ここで、電子書籍について改めて考えてみたい。
もしも、すべての書籍が電子化されたらどうなるだろう。
90%は問題がないどころか、便利になるだろう。
しかし、残り10%が解決できない限り十分とはいえない。

例えば、絵本は難しい。
PC並みの大画面のデバイスを使えば、従来以上の絵本ができるのはわかりきっている。しかし、絵本を見る子どものためにそのような高価なデバイスを買う親がどれだけいるだろう。絵本だけでは、デバイスの価格に対して十分な価値があるとはいえないだろう。
むしろ、スマートTVのアプリとして位置づけた方がよいかもしれない。
メディアに応じて出版部門の再編が必要かもしれない。

次は付録付き雑誌だ。
付録というリアルなモノが主役なので、電子書籍にはなりえない。

低学年向き学習教材も電子化が難しい。
ユーザの年齢が、デバイス自体を使えないほど低いからだ。
とはいえ、小学校1年生でもタブレットは十分に使える。
学校でタブレットを使わないのは、単に導入コストが大きいからだ。
タブレットがあれば、問題なく使える。
実際、ベネッセは教材としてタブレットを提供している。個人的にはアプリで十分だと思うが。
教科書会社が教科書に沿った学習教材をアプリとして販売すればよいだろう。
このように家庭では教材の電子化が進むだろう。しかし、学校では電子化はあまり進まないかもしれない。主に経済的な理由により。
低学年向き学習教材は、すぐには電子化されないが、徐々に電子化されるだろう。それでも年齢的な限界はある。

絵本や雑誌だけでは本屋の商売は成り立たないだろう。
Amazonだけがあればよいという未来が垣間見える。


2015年2月14日土曜日

Firebaseで認証付きアプリを作るには

Firebaseはバックエンドサービスです。BaaS(Backend as a Service)と言われますが、Firebaseのサイトには直接BaaSという言葉はなさそうです。
一言で言うと、ドキュメント型データベースとそのライブラリからなるシステムです。ドキュメント型データベースはMongoDBが有名です。Firebaseはデータ全体がJSONです。Firebaseのデータをビジュアルに編集できるWebページを提供しています。
これだけなら単にMongoDBをWebサービスにしても同じことです。しかし、Firebaseが面白いのはAngularJSなどのクライアントサイドフレームワークとの相性が抜群だということです。AngularJS用にAngularFireというライブラリを提供しています。AngularFireでは、MVCをクライアントサイドで実現します。AngularFireのModelは、DOM、Firebaseと3方向に同期されます。その結果、クライアント単体でアプリケーションを実現します。つまり、アプリケーショサーバがいらないのです。

Firebaseにはホスティングの機能があり、Webサーバとしても働きます。しかし、それはWebページを配信するためのものであり、サーバ側で処理するアプリケーションサーバを意味しません。
Webアプリケーションは3層モデルを採用してきました。3層からアプリケーションサーバが除かれると2層のクライアントサーバに戻ります。しかし、アプリケーション配信が不要などWebアプリのメリットは維持しています。
なお、その他のJavaScriptでも同じく2層モデルを構成できます。しかし、JavaScript以外の言語では従来通り3層モデルとなります。
2層化にはセキュリティの問題があります。クライアントに自由にデータベースを操作することを許すので、不正アクセスも簡単です。よって、読み取り専用データを除けば、必ず認証(Authentication)・承認(Authorization)と組み合わせる必要があります。

FirebaseではOAuthのライブラリも提供しています。GoogleでログインするWebアプリも簡単に作れます。OAuthのクライアントIDおよび秘密鍵はFirebase側に登録され、リダイレクトページも用意されます。承認はFirebase側でセキュリティルールを設定することで実現します。一般的には、ログインしたユーザだけがアクセスできるように設定します。
問題となるのは、クライアントコードが不正に改変された場合です。特にOAuthを使うと、例えばGogoleのユーザなら誰でも不正アクセスすることができます。そのため、OAuthに加えて独自の絞り込みが必要になります。なお、OAuthには送信元が登録されるので、クライアントコードをコピーしてもOAuth認証を回避できるわけではありません。

実際に、AugularFireで認証付きアプリを作成しようとすると、情報が少ないことに驚きます。そこで、具体的な方法を紹介します。ただし、この方法は試行錯誤の結果なので、必ずしもベストあるいは公式に推奨される方法とは限りません。

ポイントは$firebaseと$firebaseAuthの2つを使う点です。
$firebaseAuthからFirebaseデータにアクセスできるかと思って試したのですが、どうやら認証専門のようです。二重の参照は美しくありませんが、やむをえません。$firebaseAuthが$firebaseを継承してくれればよいのですが。
Googleのメールアドレスの中で@toyo.jpを持つユーザだけに限定しています。auth.uidは意味不明の数字なので、{scope: "email"}がかかせません。該当しないユーザは$unauthしてしまえばログインを拒否したことになります。ちなみにメールアドレスはFirebaseのnameにできません。メールアドレスに含まれる特殊記号がはじかれます。

var app = angular.module("sampleApp", ["firebase"]);
app.controller("SampleCtrl", ["$scope", "$firebase", "$firebaseAuth", function($scope, $firebase, $firebaseAuth) {
  var ref = new Firebase("https://minoru-uehara.firebaseio.com/");
  var auth = $firebaseAuth(ref);
  $scope.logout = function() {
    auth.$unauth();
  };
  $scope.login = function() {
    auth.$authWithOAuthPopup('google', {scope: 'email'});
  };
  auth.$onAuth(function(authData) {
    $scope.authData = authData;
    if (authData) {
      var mail = authData.google.email;
      if (! (/@toyo.jp$/i).test(mail)) {
        auth.$unauth();
      } else {
        var denys = [
          /^[A-Za-z]{2}[0-9]{2}[A-Za-z0-9]+@toyo.jp$/i,
          /^[A-Za-z][0-9][A-Za-z0-9]+@toyo.jp$/i
        ];
        for(var i = 0; i < denys.length; i++) {
          if (denys[i].test(mail)) {
            auth.$unauth();
          }
        }
      }
      // unauthさせずに到達すればOK
      // 共有データ
      $scope.data = $firebase(ref.child('data')).$asObject();
      // プライベートデータ
      $scope.users = $firebase(ref.child('users').child(authData.uid)).$set({email: authData.google.email});
    }
  });
}]);