ロンドンで一番ひどいバス停を見つける – ビッグデータ活用事例

ビッグデータ解析サービスの英コグニシオ社(Kognitio)が公開している、ロンドン最悪のバス停(The worst bus stop in London)は、ロンドン交通局の運営するバス運行に関する膨大なデータを使って、運行状況に関して優秀なバスやひどいバスを見つけるというプロジェクトです。 対象となるデータの規模は以下。 データ数 4,938,534,706 バス停の数 19,687個 バス路線数 675本 バスの台数 9,641台 ロンドン交通局のオープンデータというページがあるので、ここから入手できるのでしょうね。 これらのデータから、たとえば、7つの運行ゾーン毎に、「バスがとても遅れるバス停」「時刻表より前にバスが来がちなバス停」などのランキングが求められています。 これは「ロンドンで最も出発が遅れる路線」。走ってて遅れるのではなく出発が遅れるってどういうこと? と思いますが、運転手が遅刻するとかそういうのもあるんでしょうか。 こちらなんかは良い方の結果で、最も時間に正確なルート。路線のバスのうち85%が時刻表から外れずに走っているそうです。 郵便番号でランキング バスが正確な地域、不正確な地域をランキングするには、郵便番号(の上3桁)が使われています。 なんで郵便番号?

CSSスクロールで(マリオ風)横スクロール、(マリオカート風)キャラクター操作

CSSだけで(JavaScript無しで)動くページを作る、というお題でこんなものが AキーとDキーで車が左右に動いています。 こちらが作者のステファン・クックさん(Stephen Cook)による解説ページで、13行のhtml以外はすべてCSS、画像ファイルも使っていないということです。 CSS内に定義したデータから絵を描くのは、グラデーションとbox-shadow を使っています。1ピクセルごとに色を指定しているんですね。 キー入力の方はというと、こちらのCSSだけで検索エンジンを作るという記事(デモはこちら)にあるように、inputフィールドの value 属性に反応させればと思ったそうですが、ユーザーの入力に応じて value の値がアップデートされるということは無く、こちらの検索デモでは1行のJavaScriptを使っていることがわかりました。 クックさんは数週間前に間違ってブラウザのJavaScriptをオフにしてしまい、未だに戻す方法を見つけられていないということで、JavaScript を使わない方法を探さざるを得なかったよう。たいへんですね。 疑似セレクタ :valid, :invalid で、フォームフィールド内のタイプ内容がaを含むかどうかを場合分けし、さらにフォームフィールドにプレースホルダーを表示してるかどうかの :placeholder-shown と併せて、キー入力に応じて3値を見分けることにしたそうです。 レースゲームとして背景が動くところは、アルシデス・ケイロスさん(Alcides Queiroz)が公開していたマリオ風横スクロールにヒントを得たということです。 See

学生の小論文を代筆してくれるサービスがYouTuberで宣伝しすぎてBBCに見つかる

宿題の小論文を代わりに書いてくれる、という EduBirdie というサービスがあるそうです。 どんな感じで小論文を発注できるのか、注文画面を見てみました。 「推薦入試用」「研究」「ビジネスプラン」「書評」などから種類を選び、書くタイトルと分野を指定します。 分量(ページ数/単語数)、納期(短いと高くなるんでしょうね)、一から書くか・既存の何かをリライトするか・編集だけ頼むか、他の論文をどこから何本参照するか、関連する画像や図などがあればそれらもアップロードし、送信すると、この注文を受けたいという代筆者達が料金を提案してくる、という仕組みですね。 YouTuber を多数起用したプロモーション BBC が先日報じたのは、この EduBirdie をいろいろな有名 YouTuber が動画の中でオススメしている、という現象。BBC が調べただけでも250名以上が動画の中で EduBirdie を薦めていて、これらはたぶん EduBirdie からお金が出ている動画内宣伝なんでしょうね。 それらの宣伝コーナーの動画を、EduBirdie

子供の歌声を腕のイレズミにした母親

腕の刺青に対してスマートフォンをかざすと、スマートフォンから子供のかわいらしい歌声が再生される、という動画がありました。 https://www.youtube.com/watch?v=xxzaEtrmdBI 見た目のインパクトはあるし、音声波形らしき入れ墨なのでイレズミとして実際の声の波形を彫り込んだのかと最初思ったのですが、どうもそうではなさそう。これは、Skin Motionというサービスが生成した「波形風のバーコード」で、このサービスのスマートフォンアプリを使って認識させて、サーバ側にアップロードしておいた音楽/音声を再生させているということのようです。 二次元バーコードの刺青で参照先のコンテンツを再生する、という話だとそれほど珍しいわけでもなくて、QRコードのイレズミが5,6年も前のものがいくつも見つかります。 https://www.youtube.com/watch?v=hWQDq4mMMaQ https://www.youtube.com/watch?v=aDhqgZjP_Yk 普通の一次元バーコード刺青となると、それこそスマートフォン以前からありますし。 この手の「実体はインターネット上などにあって、そこをポイントしているだけ」の情報の体への埋め込みは、リスクが高そうな気がしますねえ。サービス提供者が停止したらどうするんだ、とか。イレズミの場合は、皮膚に傷がついたり、シミやシワが増えたりしただけで、読み取りできなくなりそう、というのもありますし。 さらに、このSkin Motion、アプリの登録に39.99ドル、毎年のサービス料も9.99ドル掛かるようです。 背中のイレズミに財宝のありかが隠されている、だと伝奇小説によくありそうな話ですが、毎年お金を払って維持するようなもの、となると刺青を彫るのが普通という文化の人にとっても、賢い選択とは言いにくいのではないかなあ... via

太陽発電だけで国中の電気を支えようとしたとき必要な面積を可視化したインタラクティブな世界地図

Area of Solar Panels Needed to Power a Countryは、世界各国の消費電力を賄うために必要な電気を、もし全部ソーラーパネルで発電しようとしたら、どんな広さになるか、というのを可視化してくれるページです。 下の世界地図から国を選ぶと、その国の地図と、その上に必要なソーラーパネルが占める面積が正方形の集合で表されます。 人口密度が高いのか、電力消費が多いのか。一番効いてるのは日照量の少なさかもしれません。 大きな国はいいですね。 人口が少なかったり、そもそも電気を使わないライフスタイルの国だと、こんな割合でも電気が賄えてしまうんですね。 87%の国は、国土の5%以下の広さで、すべての電力を賄えるそうです。このサイトの調査では日本は8%ということ。山だらけの日本で8%はかなり困難かも。 また、国土すべてにソーラーパネルを敷き詰めても足りないのは、シンガポール、香港、バーレーンの3国だということ。 もちろん、これから先の発電効率の進化もあるので、消費電力が増えすぎないように気を付けていけば、必要な面積は漸減していくことが期待できるのでは。 # 計算に使われたデータ、発電効率等の数字は、リンク先記事の末尾で提示されています。 via Maps

The Waiting Game – 入国収容所の難民を追体験できるブラウザゲーム

ProPublica と ニューヨーク公共ラジオ(WNYC)の制作によるブラウザゲーム The Waiting Game は、アメリカに入国して難民申請を出している人たちの体験をできるゲームです。 まずはプレイヤー選択。選べるのは5人。 エルサルバドルで、家庭内暴力(DV)から逃げてきた母子 バングラデシュで、信仰の異なる相手と結婚していた人 コンゴ民主共和国で、抗議活動に参加した学生 ネパールで差別に遭ったチベット人 国籍のせいでエチオピアからエリトリアに追放された人 ゲームの選択肢は基本的に「続けるか」(Keep going)、「諦めるか」(Give up)の2択しかありません。自国を脱出するまでは匿われている場所でじっと潜伏していなければいけない日々だし、拘置所や米国に移ってからの収容所では、毎日毎日なんの変化もないまま、刑務官らに人扱いされなかったりまずい食事を出されたりがひたすら続きます。 今回選んだ「デモで政府から目をつけられた学生活動家」の場合は、一度拘禁されて拷問を受けた後、親戚の手配でなんとか釈放されるものの、そのあとさらに学生たちへの弾圧が強まる中で偽造パスポートを入手してアメリカへと逃げることになります。 アメリカに着いてから難民収容所に移されてからも、自国で逮捕された時ほどひどい扱いではなくても、手続きも遅々として進まず、自由のない暮らしは続きます。 あまりに毎日の進捗がなく、陰鬱な描写が続くことから、Give upすると、これまで何十日が経過していたか、そしてこの実話の難民が実際に難民認定を受けるまでに何日かかったのか、が表示されます。ゲームならGive upできますが、この待ち続ける生活の中で実際に諦めることができるとしたら、甘んじて逮捕されるとか収容所で狂うとかですかね。 読んでいるだけでも辛いこの体験は、すべて実際に体験してきた難民たちの聞き取りから再構成された内容です。ゲームとして考えると、自由度もなければ嬉しくないイベントばかりのダメなゲームなのかもしれませんが、その自由のなさや辛さこそが、実際に難民の人たちに起こった/起こっている事だ、という意味で、リアルなゲームとも言えます。 共同でこのゲームを制作した WNYC ラジオの関連ニュースはこちら。 via

RTC勉強会第7回 Web2.0 参加

RTC勉強会 『Web2.0』 -ビジネスへのインパクト に参加してきた。

「ちょーちょーちょーいい感じ」の保田氏近江商人JINBLOGの上原氏が主催する勉強会。今回で第7回ということだが参加ははじめて。

技術者向けではない、と念押しされていたが、むしろ技術者以外の人は Web 2.0 喧騒をどう見てるのか興味があって参加した。会場は100人近くの人で埋まり、S:G比 (スーツ:ギーク比。今作った)は 8:2 といったところ。

Feed/Web2.0 について話したのはどこかで見たことのあるこの人。用があるとかで講演後そのまま去られたのが残念。

会場からの質問が、技術系の会合と色合いが違って面白かった。

また、最後の締めにおこなったグループによるディスカッションでも、いろいろと気づき、特にブログネタ方向で、を得ることができた。今回一番記憶に残った話は、RSS が溢れ出るネットになったときに、どうやって自分の RSS を購読させるか、という話で、現実世界での利益をインセンティブとして与えることでそれを実現する、というあたりがスーツ的発想でよかったと思う。それ以外にもアイデアの種的なものをいくつか貰ってくることができた。

名刺交換が苦手なので、会の後の大名刺交換会にはあまり参加できず。しかし前から注目していた芸能証券(発想が面白くて好きだ。芸能に興味ないので自分では遊んでないけど)の人やガ島通信の中の人と話ができたのはよかった。

この記事は移転前の古いURLで公開された時のものです

  • ブックマークが新旧で分散している場合があります。
  • 移転前は現在とは文体が違い「である」調です。(参考)
  • 記事の内容が古くて役に立たなくなっている、という場合にはコメントやツイッターでご指摘いただければ幸いです。最新の状況を調べて新しい記事を書くかもしれません

SSE (Simple Sharing Extensions)発表 – 次世代 RSS となれるか?

via TechCrunch

SSE (Simple Sharing Extensions) とは、一方向の通知を実現する RSS に対して、最低限の拡張によって双方向の同期を実現するもの、ということらしい。

マイクロソフトの CTO 、Ray Ozzie が自身のブログでこの SSE 発表について解説している

このブログ記事によれば、SSE によって、家族間でスケジュールのアップデートを共有することができるようになるという。その際に、プライベートなスケジュール、共有スケジュール、公開されたスケジュールをそれぞれ適切な公開レベルのまま扱うことができる。スケジュールは一例で、アドレス帳の中の共有エントリなどについても同様に、個人アドレス帳アプリケーションの中から共有されているアドレスを更新すると、その更新が共有相手側にも伝えられてシンクロナイズするようなアプリが作れるという。

「あの」マイクロソフトが提案する仕様だが、ライセンスはクリエイティブ・コモンズ、具体的にはこれで、自由に使っても後でマイクロソフトから利用を禁止されたり利用料を請求されたりすることはなさそうなライセンス。

レイ・オジーは、RSS の持つ簡単さとオープンさが RSS を普及させたことを考慮した上で、SSE をできるだけ簡単な仕様に押さえたと書いている。実際に、ここ数週間で、マイクロソフトの複数の製品開発グループが、この SSE のプロトタイプ実装やデモを作成し、それらが相互に働き合うことを確認したそうだ。

また、RSS の父である Dave Winer にも協力を要請し、彼の要求で OPML のほうにもこの SSE を適用できるようにしたとのこと。デイブ自身のブログでも SSE について述べられている。

とりあえず彼らの売り口上を読んで、非常に気になっている。シンクロナイズ用のデータ仕様といえば、SyncML なんてのも前からあるわけだし、はたしてこの SSE のどこがすごい/簡単/普及しそうなのか、仕様書を読んでみるとしよう。

SSE 仕様書のドラフト(バージョン 0.9)はこちら

SSE に関する FAQ はこちら

# 最初みたときに思ったんだが、SSE といっても、Pentium III とかに載ってる、浮動小数点計算を早く処理するアレじゃないよ


追記: いちおう仕様書を読んだ。メモを末尾につける。ほんとに素の RSS を保ったままなので、この拡張情報を入れたとしてもこれまでと同じ RSS として問題なく動く(はず。いいかげんなパーザを使ってるところはダメかも)。その上で、RSS-SSE を解する複数のサイト間で、更新情報をシンクロナイズさせることができるということになりそうだ。

簡単とはいっても、扱う問題がこれ以上簡略化できないので、これをライブラリに落とすのは多少面倒そうだ。マイクロソフトは社内でいろいろ試しているから準備はできているわけだが、各スクリプト言語など向けのライブラリが揃って遊べるようになるのが普及への鍵かと。

カレンダーやアドレスの共有という点で、非公開にするための新たな仕組みがこの拡張の中に含まれているわけではない。RSS の認証については、これまで同様 RSS の下のレイヤで考えないといけない。


サイトA とサイトB が、お互いの SSE フィードを購読しあう。SSE フィードには、更新されたとか削除されたという拡張情報がつくため、各サイトでは相手サイトで行われた変更を取り込んで反映させることができる、ということ。 (仕様書 1.3)

SSE の拡張エレメント(2)

拡張がある場合のトップレベル要素 sx:sharing (2.1)。関連フィードを示す sx:related (2.2)。完全なフィードと更新情報だけのフィード(2.2.1)。外部を指す集約フィード(2.2.2)。更新を伝えるための sx:sync 要素(2.3)。更新時刻を時系列で保持する sx:history 要素(2.4)。更新情報 sx:update 要素(2.5)。

順序情報を気にしない更新と、順序を保つように動かなければならない更新がある (3.1, 3.2)

アイテムの新規生成(4.1)、更新(4.2)の流れ。複数サイトでの同時更新(4.3)と、どの更新を優先させるかのルール(4.4)。

オプション要素 sx:conflict による衝突の解決(オプション。 5)

この記事は移転前の古いURLで公開された時のものです

  • ブックマークが新旧で分散している場合があります。
  • 移転前は現在とは文体が違い「である」調です。(参考)
  • 記事の内容が古くて役に立たなくなっている、という場合にはコメントやツイッターでご指摘いただければ幸いです。最新の状況を調べて新しい記事を書くかもしれません

SSE (Simple Sharing Extensions)発表 – 次世代 RSS となれるか?

via TechCrunch

SSE (Simple Sharing Extensions) とは、一方向の通知を実現する RSS に対して、最低限の拡張によって双方向の同期を実現するもの、ということらしい。

マイクロソフトの CTO 、Ray Ozzie が自身のブログでこの SSE 発表について解説している

このブログ記事によれば、SSE によって、家族間でスケジュールのアップデートを共有することができるようになるという。その際に、プライベートなスケジュール、共有スケジュール、公開されたスケジュールをそれぞれ適切な公開レベルのまま扱うことができる。スケジュールは一例で、アドレス帳の中の共有エントリなどについても同様に、個人アドレス帳アプリケーションの中から共有されているアドレスを更新すると、その更新が共有相手側にも伝えられてシンクロナイズするようなアプリが作れるという。

「あの」マイクロソフトが提案する仕様だが、ライセンスはクリエイティブ・コモンズ、具体的にはこれで、自由に使っても後でマイクロソフトから利用を禁止されたり利用料を請求されたりすることはなさそうなライセンス。

レイ・オジーは、RSS の持つ簡単さとオープンさが RSS を普及させたことを考慮した上で、SSE をできるだけ簡単な仕様に押さえたと書いている。実際に、ここ数週間で、マイクロソフトの複数の製品開発グループが、この SSE のプロトタイプ実装やデモを作成し、それらが相互に働き合うことを確認したそうだ。

また、RSS の父である Dave Winer にも協力を要請し、彼の要求で OPML のほうにもこの SSE を適用できるようにしたとのこと。デイブ自身のブログでも SSE について述べられている。

とりあえず彼らの売り口上を読んで、非常に気になっている。シンクロナイズ用のデータ仕様といえば、SyncML なんてのも前からあるわけだし、はたしてこの SSE のどこがすごい/簡単/普及しそうなのか、仕様書を読んでみるとしよう。

SSE 仕様書のドラフト(バージョン 0.9)はこちら

SSE に関する FAQ はこちら

# 最初みたときに思ったんだが、SSE といっても、Pentium III とかに載ってる、浮動小数点計算を早く処理するアレじゃないよ


追記: いちおう仕様書を読んだ。メモを末尾につける。ほんとに素の RSS を保ったままなので、この拡張情報を入れたとしてもこれまでと同じ RSS として問題なく動く(はず。いいかげんなパーザを使ってるところはダメかも)。その上で、RSS-SSE を解する複数のサイト間で、更新情報をシンクロナイズさせることができるということになりそうだ。

簡単とはいっても、扱う問題がこれ以上簡略化できないので、これをライブラリに落とすのは多少面倒そうだ。マイクロソフトは社内でいろいろ試しているから準備はできているわけだが、各スクリプト言語など向けのライブラリが揃って遊べるようになるのが普及への鍵かと。

カレンダーやアドレスの共有という点で、非公開にするための新たな仕組みがこの拡張の中に含まれているわけではない。RSS の認証については、これまで同様 RSS の下のレイヤで考えないといけない。


サイトA とサイトB が、お互いの SSE フィードを購読しあう。SSE フィードには、更新されたとか削除されたという拡張情報がつくため、各サイトでは相手サイトで行われた変更を取り込んで反映させることができる、ということ。 (仕様書 1.3)

SSE の拡張エレメント(2)

拡張がある場合のトップレベル要素 sx:sharing (2.1)。関連フィードを示す sx:related (2.2)。完全なフィードと更新情報だけのフィード(2.2.1)。外部を指す集約フィード(2.2.2)。更新を伝えるための sx:sync 要素(2.3)。更新時刻を時系列で保持する sx:history 要素(2.4)。更新情報 sx:update 要素(2.5)。

順序情報を気にしない更新と、順序を保つように動かなければならない更新がある (3.1, 3.2)

アイテムの新規生成(4.1)、更新(4.2)の流れ。複数サイトでの同時更新(4.3)と、どの更新を優先させるかのルール(4.4)。

オプション要素 sx:conflict による衝突の解決(オプション。 5)

この記事は移転前の古いURLで公開された時のものです

  • ブックマークが新旧で分散している場合があります。
  • 移転前は現在とは文体が違い「である」調です。(参考)
  • 記事の内容が古くて役に立たなくなっている、という場合にはコメントやツイッターでご指摘いただければ幸いです。最新の状況を調べて新しい記事を書くかもしれません

ポールグラハムの Web2.0

暴れん坊ブロガー ポール・グラハムが Web2.0 について書いてきた。

ポールグラハムというのは、オンラインで書いたエッセイがハッカーと画家という本にもなっている。(たまには Amazon 以外のリンクでと思ったが、検索上位になかなか見つからない。競合他社はもっと SEO に力入れないといかんよなあ) 超辛口の Lisper だ。

彼による Web2.0 とは

  1. たまたま同じ時期に居合わせた Ajax
  2. 民主主義的な集合知
  3. ユーザーにひどい扱いをしない

の 3 つからなるもの。で結局のところ、つきつめればそれは Google がやっていることになる、と。

「del.icio.us や Flickr によるタギングの考えを推し進めて、リンクに使われたテキスト文を活用し、ユーザが他のサイトをどう評価しているかをグラフ理論を使って洗練していけば、ウェブ上の検索を改良することができますよ」、みたいな Web2.0 サービスを考えたなら、それは Google が前からやっていることだった、というオチ。

2004 年に開催された Web2.0 カンファレンスに、Geek などほとんど来てやしなかった(参加費が $2800 だもの)とか。このカンファレンス用に Tim O’Reilly がスーツを買ったとか。そんな話も面白い。あとは Google Maps の技術リーダーも他所から買われてきた人材だった、という情報へのポインタとか。

この記事は移転前の古いURLで公開された時のものです

  • ブックマークが新旧で分散している場合があります。
  • 移転前は現在とは文体が違い「である」調です。(参考)
  • 記事の内容が古くて役に立たなくなっている、という場合にはコメントやツイッターでご指摘いただければ幸いです。最新の状況を調べて新しい記事を書くかもしれません

CNET 検索サービスカンファレンスの海外レポート

CNET Japan Innovation Conference 2005 Autumn 次世代ウェブの検索サービスを探る (長い。。。)の報告がいろいろあがっているが、Search Engine Jounal も人を派遣してたようで、やたら気合の入った現地(東京)レポートがあがっている。

CNET Japan Search Conference Report

マイクロソフトのマーケティング戦略

日本におけるモバイル検索、ローカル検索

ヤフージャパン: ソーシャル検索メディア

アスクジーブス検索と Web 2.0

ブログセッション

グーグル・グローバル: オープンソース、API、ミッション

英語圏に日本の検索市場を紹介しようとしている記事自体が興味深いし、日本語での報告もたくさんあるため、比較して読むのも面白いだろう。特に参加した人からみれば、会場で語られていた内容がそのまま英訳されているわけだし。

# Blog Session のレポートで紹介されていた、ブログサービスとブログ検索によって “an extremely popular” な “Japanese portal”ってどこだと思う?
自分が普段触れていない言語圏で、どのサービスがどれぐらい有力か、現地の人にどれだけ知られて/使われているか、というのを把握するのもたいへんだろうなあ。そのポータルもがんばってるとは思うが、”extremely popular” ってことはないんじゃないかと思いつつ。。。

この記事は移転前の古いURLで公開された時のものです

  • ブックマークが新旧で分散している場合があります。
  • 移転前は現在とは文体が違い「である」調です。(参考)
  • 記事の内容が古くて役に立たなくなっている、という場合にはコメントやツイッターでご指摘いただければ幸いです。最新の状況を調べて新しい記事を書くかもしれません

Google で購読ボタン/リンク

サイドバーに「Google で購読」リンクを追加


Google で購読リンクのジェネレータページはこちら

Google Personalized と Google Reader のいずれかに、指定したフィードを登録するためのボタンとなる。
画像を使わなければ、リンクだけになる。

この記事は移転前の古いURLで公開された時のものです

  • ブックマークが新旧で分散している場合があります。
  • 移転前は現在とは文体が違い「である」調です。(参考)
  • 記事の内容が古くて役に立たなくなっている、という場合にはコメントやツイッターでご指摘いただければ幸いです。最新の状況を調べて新しい記事を書くかもしれません

akky's work blog