ARウィンドウ
窓ディスプレイで見える景色に情報をかぶせるというコンセプト
「あの船はどこに行くんだろう?」「あの車欲しいな。どこのメーカーでいくらぐらいだろう?」というところでしょうか。自宅の窓にあってもあまり使わないでしょうけど、観光地のホテルの窓にあれば楽しそうです。
窓ディスプレイで見える景色に情報をかぶせるというコンセプト
「あの船はどこに行くんだろう?」「あの車欲しいな。どこのメーカーでいくらぐらいだろう?」というところでしょうか。自宅の窓にあってもあまり使わないでしょうけど、観光地のホテルの窓にあれば楽しそうです。
ツイッター側の許容する頻度を越えてAPIを呼びだした際のエラーコードが、Search APIで503、その他のREST APIで400と違っていたのが、Search APIでも400を返すようになるということです。12月16日から。
検索APIのエラーコードの種類を見て何かしてるクライアントやスクリプトがあれば、開発者はチェックしたほうがいいかもしれません。
早いですね。
gotweet Go言語によるコマンドラインtwitterクライアント
gomemcached Go言語によるmemcachedクローン
"Go"で検索できない、という件は、"golang"とかになっていくんですかね。C言語の検索のしにくさを受け継ぐことはなかったのに。
マイクロソフトリサーチの研究成果をライセンスした新しいライフログカメラが、市販へ向けて始動したという記事を読みました。
イギリス・ケンブリッジのマイクロソフトリサーチでの研究名はSenseCamというものでしたが、この研究は首からぶら下げたカメラで日常の風景を撮り続けることで、人生を記録(ライフログ)するというものです。
ライフログというコンセプト自体はかなり前からあるようで、僕が初めてライフログというのを知ったのはライフスライスというプロジェクトのことを(ツイッター解説本がベストセラーになりつつある)いしたにまさきさんに聞いたのがきっかけでした。今なら組込のPCも部品やメモリもずっと安くなっているので、より安価に長時間記録できる機械が作れそうだというのはわかります。
SenseCamの特徴は、それまで一定時間置きに自動的にシャッターを切っていたところを、加速度計や光センサー、色センサー、温度センサー、服の温度センサーなどを使うことで、装着者が新しい環境に移ったタイミングを検知してシャッターを切る、ところにあるようです。変化が起こったところを撮ることで、同じ記憶容量でもより多くの情報が取れたり、一定間隔のシャッターでは取り逃してしまっていたような、短時間で大きく場所を移動したり景色に変化があったりしたときの記録も取れる、ということでしょうね。
このSenseCam技術をベースとしてこの冬に発売されるというVicon Revue(バイコン・レビュー)は、まず研究者向けに500ユニットが500ユーロ(7万円弱)で発売され、来年にはコンシューマー向けバージョンが発売される予定だということです。量産されれば価格はもっと安くなるのではと思われます。
別の認知学の研究者のコメントでは、ノートやシステム手帳に記録をするのと同様に、普通の人がこういった機械を使って日常を記録するようになるのも近い、ということです。
via New Scientist
3年前と2年前にMicrosoftが開発しているPhotosynthという技術を紹介しました。複数の写真から共通した部分を発見し、つなぎあわせることでパノラマ写真を作り上げるというものでした。
Photosynthのベースとなっていた研究から、さらに多くの画像を高速に処理できるようになっている様子が、New Scientistでレポートされていました。
上の動画では、ウェブから
- 「ローマのコロッセオ」で検索した2000枚の写真をつなげ合わせ、数百台のコンピューターでコロッセオの3Dモデルを作る様子
- 6万枚の写真を22時間で処理して、クロアチアの美しい古都ドブロヴニクのモデルを作成
- 65時間かけてベネチアの3Dモデルを構築
したと報告されています。
Flickrから持ってきた実際のローマの観光地の写真と、その同じ場所のモデルを何枚か並べているページがあるので、ローマの写真をFlickrに上げた人は、自分の写真が載ってるかもしれませんね。
日本人研究者古川泰隆さんを含むこのチームの研究では、ウェブから検索してきた大量のスナップ写真から、同じ箇所を写した画像をマッチさせ、ローマのような一つの都市の3D構造を一日で作成する並列分散システムの開発に取り組んでいるそうです。
1936枚の写真から作ったトレビの泉、
ベネチアのサンマルコ広場。画像の撮影ポイントを表しているマークの分布を見ると、建物の上から撮られた写真も多いですね。
そしてアドリア海の真珠ドブロヴニク。ローマは観光ポイントの周りばかり写真が集まるそうですが、こちらは街がコンパクトな分よく街全体が再現されているようです。
via TheNextWeb
これがその写真の一枚
マサチューセッツ工科大の二人の学生Justin LeeさんとOliver Yehさんが、普通にお店で入手できる部品を組み合わせることで、これまでにない超低予算(148ドル)での成層圏からの地球撮影に成功した、ということです。
その手順ですが、まず、気象観測用の300グラムのゴム気球(1800円)、それにパーティーグッズの店でヘリウムを2700円分詰めてもらいます。
成層圏での気温は-55度にもなるので、普通のバッテリーは動かなくなります。そこで、高価な耐寒機器やヒーターを搭載する代わりに、携帯カイロを電気系に密着させ発泡スチロールでカバーします。
撮影した写真がどの高さから取られているかを記録し、撮影を終えたカメラを回収するためには、カメラの場所を追跡する必要がありますが、これも高価で重いGPSモデムではなく、GPS内蔵の携帯電話(4500円)を使うことに。カメラと接続された携帯電話は、定期的にGPSで取った位置をテキストメッセージで送らせます。
この一式を積んだ気球は今月初めに飛ばされ、高度18マイル(約28.9キロメートル)まで上昇してから地表に戻ってきたということです。
数十ドルで買えるデジカメが当たり前になったり、携帯電話のGPS内蔵が進んだことなど、いろいろなことで、かかる費用が安くなったのでしょう。この学生さんたちもコメントしてますが、一万円ちょっとで成層圏にカメラを送り込めるようになったことで、誰もが、たとえば高校のクラブ活動なんかでも、こういう実験をできるようになってきたということですね。
上のケースでは実際にはカメラが降りた個所に拾いに行かないといけないので、車とかガソリン代とか要りそうですし、そもそも回収できないところに降りるケースもありそうですけど、携帯から直接画像を送れば、さらに回収も不要になる可能性もありますね。カメラや携帯電話の再利用はできないので、そこがさらに安価になったらかもしれませんけど。
via MIT Students Take Pictures from Space on $150 Budget. - iReport.com
WordPress.comが、ホストするブログのすべてにおいて、RSSCloudに対応したというニュースが入ってきました。
WordPress.comサービスに存在する750万個のブログすべてが、この仕様に対応したということですが、さらに、WordPress.org、つまり自分のサーバにインストールするタイプのWordPressでも、プラグインRSS Cloudが提供されています。早速自分の持っているWordPressブログの一つにインストールしてみました。
それで何が起こるかというと、RSSのソースを見たときに、cloudというタグで情報が増えます。こんな感じ。
<sy:updatePeriod>hourly</sy:updatePeriod> <sy:updateFrequency>1</sy:updateFrequency> <cloud domain='akimoto.jp' port='80' path='/blog/?rsscloud=notify' registerProcedure='' protocol='http-post' /> <item> <title>Symfony Meetup Tokyoやります</title> <link>http://akimoto.jp/blog/2009/09/05/symfony-meetup-tokyo/</link> <comments>http://akimoto.jp/blog/2009/09/05/symfony-meetup-tokyo/#comments</comments> <pubDate>Fri, 04 Sep 2009 23:24:04 +0000</pubDate>
これによって、RSSCloudに対応しているリーダーでは、購読しているブログの更新を数秒で取得することができるようになります。リーダーが
今のところ、RSSの生みの親であるDave WinerさんによるRSSリーダーRiver2のみがこのRSSCloudをサポートしていますが、Daveさんは様々なクライアントがこのRSSCloudに対応するように呼びかけています。
# 発表からまもなく、LazyFeedというRSSリーダーも対応を表明しました。
実装方法を解説した文書と、WordPressのRSSCloudプラグインの、たいへん短い4つのソース、およびWordPressプラグインの解説が参考になると思います。(これによると、ホスト型WordPressの方の通知はページの表示タイミングで起こるので、たとえば新しい記事を書いても書いた本人自身が記事を表示せず、誰もサイトに来なければ、数秒で通知されることはないようです)
[追記]
PubSubHubbub側としては、Prior Artとして、「RSSCloudというのが先行して存在するが実際には使われておらず、機能的にも不十分」という主張をしています。RSSCloudはPubではあるがSubは無い、と最初は書いていたようですが、それは他からの指摘を受けて修正されています(PubSubHubbubとRSSCloudの比較)。ただし、2001年に書かれたRSSCloudに比べて、多少なりともPubSubHubbubのSub側の利点はあるような気もします。PubSubHubbubの方はGoogle ReaderやBloggers, livedoor ブログ/リーダー等が対応していますね。
# Dave Winerさん絡みということで、なんとなくRSS1.0/RSS2.0/Atomの時のことを思い出してしまいますが
また、Robert Scobleさんのブログでは、どこか一社、twitterのことですが、が集中管理してその中のユーザー間でメッセージを送りあうサービスではなく、各自が自社・個人のドメイン下でRSSCloudのような仕組みを使ってリアルタイム(に近い)通知をすることでオープンな代替twitterが実現できる可能性について論じています。
via ReadWriteWeb
カンヌの広告フェスティバルでお披露目された、マルチタッチ、RFID認証に対応したインタラクティブ・ウォールの動画です。まさに「壁」と呼ぶにふさわしいサイズ。
Touchwall Demo from Joel on Vimeo.
同時に複数の人が使えるようにするために、既存の一人用向けのアプリケーションの転用ではなく、専用のソフトウェアを開発する必要があったと語っています。
最近は、街角の不動産屋の店頭でも、タッチスクリーン式で物件を検索表示するようなディスプレイを見かけるようになりましたが、とにかくサイズが大きいこと、複数人の同時利用が可能なこと(もちろん一人のマルチタッチも)、RFIDで個人個人に合わせたコンテンツを提供できること、などが新しい点なのかなと思います。
動画中では、カンファレンスの参加証をかざすことでRFIDを使ったユーザの特定を行い、ユーザ名等を表示していますけど、身の回りにつけている持ち物のRFIDを使えば、近づいただけでその人向けの情報・広告が出てくる壁になりますね。使っている様子はクールです。そしてここでも「トム・クルーズ」が言及されています。マイノリティ・リポートで描かれたあれこれの近未来描写が、いろいろな人がこの手のインタラクティブなディスプレイを話すときの共通基盤となっているんですね。
via Digg
60fps撮れるカメラと、家庭用ランプ、タッチパネル(色などの切り替え用)を使って、文字を描くバーチャル・カリグラフィーの動画です。
Digital Slaves [RT Virtual Calligraphy] from Digital Slaves on Vimeo.
一番最初に、明るい状態で演者が文字を書いていく動きを見せてくれます。ランプを動かした跡がカメラで撮られて、スクリーン上に残されます。タッチパネルで色や筆の模様を変更もしています。プロジェクターで映すので、写真の上に文字を描くことも。
via Digg
Phototypeは、Javascriptの呼び出してサーバ側のPHP/GDを呼び出し、画像を加工させるというアイデアの実装サンプル。
こういう元画像を、
縮めて、回転させて、影をつけて、キャプションをつけると、こう表示される。
Javascript側は、PHPの呼び出しをラップしただけで、ほとんど処理らしい処理は無い。PHP側では、指定した画像をURL経由で読み込んで、GDで変換して表示しているが、ソースを見ると危険が満載なので、これをそのまま設置して使ったりはしない方がいい。あくまで「やってみた」レベルの話だと思う。
作者のページのサンプルも、結果の画像をstaticに保存しなおして貼ってあるぐらいなので、表示のたびにPHPで画像を生成するこのままの仕組みでは実用にならないとは思うけれど、パラメータの受け取りやエラー処理を改善し、キャッシュを効かせて限定した用途で使えば、Javascript側から画像の加工ができるという仕組みで何かサービスが考えられるかもしれない。
via AJAX Magazine: Phototype, Image Manipulation With PHP And Prototype
サーバ側(PHP)とクライアント側(Javascript)でDOMアクセスの書き方が異なるのが面倒、ということへの回答か、FluentDOMというPHPのプロジェクトが始まっていました。
jQueryライクに、ということですけど、要素の選択はCSSセレクタじゃなくてXPathで行ないます。PHPのDOMDocument, DOMXPathを使ってるからこっちの方が実装が楽だということらしいです。(CSSセレクタからXPath表記への変換もToDoには入っています)
全部の
のテキストを抜き出すという処理を、素のPHPで書いたのと、FluentDOMで書いてみました。
<?php$xml = <<<XML
<html>
<head></head>
<body>
<div>
<p>Hello</p>
<p>cruel</p>
<p>World!</p>
</div>
</body>
</html>
XML;// PHP DOMDocument
$dom = new DOMDocument;
$dom->loadXML($xml);
$xpath = new DOMXPath($dom);
$node_list = $xpath->query('//p');
for($i=0; $i<$node_list->length; $i++){
$node = $node_list->item($i);
echo $i . ': ' . $node->nodeValue . "\n";
}// simplexml拡張
$gottenObj = simplexml_load_string($xml);
$counter = 0;
foreach ($gottenObj->xpath('//p') as $item) {
$counter++;
echo $counter, ': ', $item, "\n";
}// FluentDOM.php
require_once('../FluentDOM.php');foreach (FluentDOM($xml)->find('//p') as $key => $value) {
echo $key, ': ', $value->nodeValue, "\n";
}
jQueryのメソッド名とまったく同じものが使える(nextだけPHPのイテレータと衝突するので、兄弟=siblingsをつけたnextSiblings, prevSiblingsになっている)ので、jQueryでのDOM操作に慣れているPHPユーザは楽かもしれませんね。
週三日勤務でこのブログを書き、残りの日は個人で活動しています