jazzmutant社が開発したLemurというマルチタッチスクリーンが凄すぎる件について。
とりあえず、梅酒吹いたのでなにはともあれビデオ見れ。(注、ウチのFFでは落ちたのでIE推奨)。
ビデオを見る限り、YouTubeで一斉を風靡したCrazy Multi-Input Touch Screenと同じように見えるけど、大きな違いが2点。それは、こいつが市販されてるってことと、付属ソフトウェアでUIをカスタマイズできるってこと。
ついでにデータの出力プロトコルがOSC(次世代MIDIみたいの)なので、Java・・・というかprocessingやmax mspで簡単に読みとれるんですぜ!? FlashOSCとか使えばおそらくFlashでも使えます。ヤバイって絶対ヤバイよコレ。
ちなみにお値段はおよそ3228万円。
もうちょっと安ければ個人輸入するんだけど・・・
via v3ga
SUNとリクルートが共同でWEB2.0マッシュアップコンテストを開催。
コンテストの勝者はもれなくマウスが30個もらえます。おまけで約20万4700ルピー(2006年6月5日為替レート)もついてきます)。
賞金はどうでもいいんですが、提供されるAPIがムッサ面白げ。FlashでやるにしてもAjaxでやるにしても楽しい実験ができそうなメモ。
カーセンサーラボAPIは、カーセンサーラボ(http://www.carsensorlab.net/)がもつ中古車物件情報及び自動車のカタログ情報を、開発者の皆様に提供するAPIです。
じゃらん宿表示APIは、じゃらんnet(http://www.jalan.net/)で検索・予約を行うことができる、日本全国約13,500軒の宿・ホテル情報をXML形式で返すAPIです。
Smatch APIは、Smatch(http://www.smatch.jp/)で公開中の不動産物件情報(新築マンション・中古マンション・新築一戸建て・中古一戸建て・土地)の概要およびSmatchブログ/相談室コンテンツをRSS形式で返すAPIです。
フロム・エー ナビ(http://froma.yahoo.co.jp/)に掲載中のバイト情報(バイト内容、時給、各種メリット、緯度・経度など)をXML形式で返すAPIです。
なんか全てのAPIが、ぜひぜひ「Google MAPS」を使ってくださいという無言の主張をしているので、MAPを素で使ったら負けかなと思ってる。
PHP5のSimpleXMLが、rss内に不正な文字列があるとパースエラーを起こしてしまうのだけど、ついに対処法を編み出した。
というか朝思いつきでやったら動いたwwwww
$xmlStr = mb_convert_encoding($xmlStr, "SJIS", "UTF-8"); //一度sjisにする
$xmlStr = mb_convert_encoding($xmlStr, "UTF-8", "SJIS"); //またutf8に戻す
mb_convert_encodingスゴス。
その議論の範囲を超えて敵を作り出したり、恨みを買うリスクも高い。
自分を駒の1つとして、
神の視点 > 他の論者 > 議論の対象
×: 神の立場から読者に語りかける。
〇: 読者に神の座から俯瞰する手段を提供する。
「僕は神の視点からモノを見れるんですよ」という匂いを如何に消すか。
ようやくなんか解ったような気もするけど、気のせいかもしれないし、そもそも実践できるようにならなきゃ意味なし。
一応見れますが、現在更新不能状態です。
坂本さんのお力で復帰したハテチューですが、再び不正なUTF8の魔の手がせまってきました。
Input is not proper UTF-8, indicate encoding ! Bytes: 0x9A 0xE3 0×83 0xAB in
犯人はこのブックマーク。はてなの出力がショボイのか、PHPという言語がショボイのかはわかりませんが、すくなくとも僕がショボイのは確実です。
UTF8にマッチする正規表現
UTF-8 の文字にマッチする正規表現
UTF-8 vs. ISO-10646
グーグル超先生のお力で色々と資料みつけたり、正規表現辞典 を買ってみたりしたのですが、じゃあ実際にperlのコードをどうphpに適用するかというと、まったくもって謎です。
HATENA-TUBEで使っている、jQueryというjsフレームワークが楽しすぎる件について。
jQueryは、ちょっとダーティだけどスゴイお手軽に、色々なことができるステキライブラリっす。小さい実験でのプロダクティビティはもうprototype.jsの100倍ぐらいスゴイっす。
色々実験中なのでそのメモ。
ユーザーインターフェースでは、例外処理の為に通常処理にタスクを増やしてしまうと、かえって大多数のユーザーに迷惑をかけてしまいますよ、というお話。
ソシオメディアの中の人のインターフェースのお話はいつも面白い。
「WEB2.0的サービスはなぜみな同じビジュアルデザインを採用しているのだろう」ということを、HATENA-TUBEを作ってるときにずっと考えてた。
全く同じビジュアルがこれほどまでに採用されるのは、単なる流行というだけでは説明できない。何か必然的な理由があるのではないか?という気がしてならなかったからだ。
自分的にこの現象には2つの理由が考えられるのではないかと思い至った。
仮説の一つは、画一されたビジュアルデザインは、WEB2.0がエンジニアリング主導で行われていることに起因するのではないか、ということだ。
僕は半分デザイナ、半分コーダの物凄い中途半端なポジションにいる。そんな自分の個人的な印象では、90%以上のエンジニア(プログラマ)は必要にかられないかぎりイノベーションを行わない、というかイノベーションに挑戦することを無意識的に避ける傾向があるように思える。ほとんどのエンジニアは、通常は0から新しい概念を構築するよりも、模倣の上にチューンナップやスペックアップを行い、バージョンアップさせていくことを好む。
だから、WEB2.0というイメージが確立しているスキンがあり、それが必要用件を満たしているならば、デザインをそのまま100%採用するということは十分考えられる。外見に工夫をこらすよりも行うべきことがあるからだ。
この典型的な例がFlickr→LivedoorPicksなどだと考えられる。
もう1つは、WEB2.0という概念そのものが実体を伴っていない、あるいはサービスの開発サイド、ビジネスサイドの両側がWEB2.0というものの本質に対して明確なイメージ、あるいは共通認識を持ってないのではないか?という仮説だ。