iモード／EZweb／Yahoo!ケータイなどで利用されるケータイブラウザは，極端な言い方をするとPCブラウザやフルブラウザとは「まったくの別物」です。今回はまず，ケータイブラウザ向けWebアプリケーションを開発する際に考慮すべき技術要素の説明を行います。

iモード／EZweb／Yahoo!ケータイなどで利用されるケータイブラウザは，極端な言い方をするとPCブラウザやフルブラウザとは「まったくの別物」です。今回はまず，ケータイブラウザ向けWebアプリケーションを開発する際に考慮すべき技術要素の説明を行います。

Squidを検索する度に最初に表示される画像検索の結果に吹き出しそうになる開発部・システム運用グループの長野です。前回のロングテールな画像配信のその2ということで、実際の画像配信システムについて書かせて頂きます。 ■プロフィール画像の配信について 前回紹介しましたが、mixiにおいてプロフィール写真を設定を設定しているユーザ数は全体の約70%、1,000万人の方が設定をされています。現在配信をしているプロフィール画像のサイズは180×180、76×76、40×40と３サイズあり、合計3,000万以上のファイル数になっています。また、もっともよく使われる76×76のサイズ1,000万件において、1日にアクセスされる画像の数は800万ファイル以上、うち97%が30回以下と非常に広範囲に渡ってアクセスされています。そのため大量の画像を配信できる仕組みが必要になります。 ■配信システムの全体像 プロフィール画像の配信システムの全体像です。 画像の保存の部分から説明していきたいと思います。 ■ストレージ層 edit_photoの画面や携帯メールからプロフィール画像をアップロードすると、アプリケーションサーバから変換（サイズの変更）と転送を行うサーバへ画像が渡されます。画像を変換するライブラリはメモリを多く使うことが多いのでWeb画面とは別のサーバで変換を行っています。 画像を変換を行った後、配信兼ストレージサーバにコピーされます。ストレージサーバはバックアップと負荷分散を目的に2台1組で構成されており、画像のアップロードは必ず2台へ行われます。 どのグループに保存されるのかは、画像のファイル名の番号の剰余によって決まります。もしストレージサーバに障害がおきて保存が出来なかった場合には、ファイル名を変更して別のサーバに保存をします。 実はこの変換の時には180×180のサイズしか作成していません。あとのサイズは配信時にオンザフライで生成しています。これでファイル数を一気に1/3まで減らす事ができます。ディスクIOのコストは画像の変換にかかるCPUのコストよりも高いと考えています。 ■Reverse Proxy層 今度はもっとも外側のサーバです。プロフィール画像へのリクエストはまずこのサーバで受ける事になります。これはmod_proxy(mod_proxy_balancer)とmod_rewriteなどを組み込んだApacheです。 RewriteRule ^/photo/member/([0-9]+/[0-9]+/[0-9]+_[0-9]+)([sm]).jpg$ ￥ balancer://balancer/photo/member/$1$2.jpg [P,L] RewriteRule ^/photo/member/([0-9]+/[0-9]+/[0-9]+_[0-9]+).jpg$ ￥ balancer://director/photo/member/$1.jpg [P,L] 76×76と40×40の画像はbalancerに、180×180の大きな画像はdirectorにそれぞれproxyされます。balancerは次に紹介するSquidサーバになり、directorはSquidサーバ群の下にあるサーバになります。180×180の画像についてはアクセスは比較的少ないのでSquidによるキャッシュ層を通さずに配信しています。 ■Squid層 Squid層は2つのレイヤーに分かれます。Squidによるcacheサーバとそれを分散するbalancerレイヤーの２つです。 最初に紹介しましたが、プロフィール画像は非常に広範囲なURI、1,000万以上の画像にアクセスがあり、これらを高速に配信するためには画像データをメモリに載せる必要があります。Squidにキャッシュさせる画像のサイズのうちの１つ、76×76の容量の平均は約2.7KBになるので、必要なメモリは最低27GB以上のメモリが必要になります。1台のサーバ（最近のメモリの値段から言えば不可能ではないですが)ではメモリが足りないので、キャッシュデータを複数のサーバに分散していく必要があります。そこで利用したのがSquidに備わっているCARP(Cache Array Routing Protocol)という機能です。 *参考資料 carp.txt http://icp.ircach... Cache Array Routing Protocol and Microsoft Proxy Server version 2.0 http://www.micros... CARPはmemcached界隈で話題になるConsistent-Hashingと考え方は似ていて、URIとcacheサーバのhash値を組み合わせてアクセスするサーバを決定します。サーバの追加や障害時の切り離しを行っても大幅なキャッシュの組み替えが発生しないという特徴もあります。詳しく知りたい方は上のURLやsquidディストリビューション中ののsrc/carp.cソースコードを参考にされるといいと思います。 SquidでCARPを利用する場合は、squid.confにおいて、cache_peerにcarpと指定します。Squidの制限としてキャッシュを横に並べるsiblingモードでCARPを利用する事ができないため、Squidが2段構成になります。 http_port 80 vhost vport cache_peer 192.168.1.11 parent 80 0 no-query no-digest carp proxy-only weight=1 cache_peer 192.168.1.12 parent 80 0 no-query no-digest carp proxy-only weight=1 cache_peer 192.168.1.13 parent 80 ...

iPhoneアプリ開発 - 身をもって学んだ9の教訓 iPhoneアプリを公開するうえでの注意事項。

iPhoneアプリ開発 - 身をもって学んだ9の教訓 iPhoneアプリを公開するうえでの注意事項。

SmartDelegate.as as3ライブラリの中で、「なんで存在するの？」とか、「ウンコ」とか、「DisplayObject継承できないから戦力外」とか不遇の扱いを受けまくるProxyクラスの活気的な使い方を考えてみた。 SmartDelegateクラスは内包した複数のオブジェクトに対して、まとめて委譲を行うクラスだ。 var obj1:Object = {name:”Taro”, age:20, sex:”m”}; var obj2:Object = {name:”Jiro”, age:18, sex:”m”}; var obj3:Object = {name:”Mika”, age:15, sex:”f”}; var obj4:Object = {name:”Mari”, age:10, sex:”f”}; var sd:SmartDelegate = new SmartDelegate([obj1, obj2, obj3, obj4]); sd.name = “Tom”; //全員名前がTomになる。 trace( sd.name ); //全員の名前が配列で返ってくる。 trace( sd.toString() ); //全員のtoString()の実行結果が配列で返ってくる。 といった具合に複数の対象のプロパティを同時に操作できる。本来オブジェクトの拡張に使うべきProxyクラスを、Delegateの基点としての用途に特化したところがポイント。 さらに、SmartDelegateクラスは第二引数に filter関数を持つことができる。 var obj1:Object = {name:”Taro”, age:20, sex:”m”}; var obj2:Object = {name:”Jiro”, age:18, sex:”m”}; var obj3:Object = {name:”Mika”, age:15, sex:”f”}; var obj4:Object = {name:”Mari”, age:10, sex:”f”}; var ...

昨日、Buriについて書きました。BuriはOSS（オープンソースソフトウェア）です。escafe.orgというところで公開しています。さて、このescafe.orgですが開店休業状態になってしまっています。今後の処置については私の裁量次第という状態になっているのですが、正直私の中で気持ちが行き詰っています。 escafe.orgはTuigwaaことescafeWebというフラッグシッププロダクトがあり、これに統合する予定で周辺のプロダクトが寄り集まった所帯です。Buriもそのひとつです。なのですが、Tuigwaaは本日正式に開発の停止がメーリングリストに伝えられました。 実は今年の3月にTuigwaaの開発メンバーの皆さんが所属していた会社さんがなくなってしまいました。正確には関連会社さんに吸収されて事業の取捨選択がなされたということです。何はともあれ、一社に集まって会社の日常的な支援を受けて頑張っていたTuigwaaチームの皆さんは散り散りばらばらになってしまいました。今でも最小限のサポートなどは継続してくれていますが、それぞれが別に新しい道へと進み始めたところですから以前のようにパワフルには活動できません。まずは自分の人生を支えられるようになるところからだからです。 OSSというのは一般的にはまだまだボランティア活動というのが大半です。Buriは会社の心臓部ですからBuriの開発者には相当量をBuriに割いてもOKとしていますが、100%ではありません（というかBuriを中心にした周辺もやっているので、Buriそのものだけに専念しているわけではありません）。ほとんどの方の場合、OSS活動というのはNightly Workと呼ばれる状態であるのはいかんともしがたい事実です。 OSS活動に限らず、ボランティアというのはその活動をしている本人が食うに困って飢えているようではどうしようもありません。となると、それなりに財源の裏付けが必要です。一部のお金持ち以外の大抵の人の場合それは会社からの給料ということになります。仮に退職して貯えがあったとしてもその貯金の源泉は何かというと所属していた企業からもらった給料です。 ではその給料の源泉とは一体どこにあるのでしょうか。会社というのは勝手にお金が沸いてくる便利な仕組みがあるのでしょうか。残念ながらそうではなく、売上という形で得られるお客様からのお支払の結果です。売上があるから利益が存在しうるというのは以前にも書いたとおりです。人件費というのは利益から出すのではなく通常は費用として出します。費用とはつまりコストです。ということは、実は非常に乱暴ではありますが、ボランティアのためのコストをお客様に転嫁していると言えなくもないわけです。 これが当期利益の処分の一環としてボランティア活動に寄付をするというのであれば、いわば納税のようなものですから社会還元といえなくもないでしょう。ですが、例えば社内で自分たちの会社のために勉強会をするなどというのは、そこに残業代がつかないからといってボランティアと呼んでいいのかというと正直疑問です。何故かというと、給料が出ているから出来ることであって、仮に売上がゼロであればそのような悠長なことは言ってられないからです。乱暴なことをいえば「そんなことをしている会社には支払いはしない！」とお客様に言われたらどうなるのかということです。 給料が出なければもっと違うことをやらなければならないはずです。ということは、源泉に遡ってみれば、つまりお客様にそういう活動をさせていただいているということになるとも考えられるのです。これはOSS活動でも同じです。かつて私はとあるOSSの活動に協力していた時期もあるのですが、このような指摘が具体的に発生したらどうすればいいのかということに気をもんでいた時期もありました。残念ながら今でも自分の中で結論は出ていませんが、そういった活動とは縁遠くなったので脇に置いてしまっています。 色々と悩みどころはあるわけですが、結局のところその給料は一体何に対して支払われているのかということになるのでしょう。拘束時間に対しての給料である（から残業代がつかないのに会社のために仕事をするのはボランティアである）と主張するならば、恐らくはその人は決して成果主義など言えないわけです。成果で評価するとなれば労働時間の多寡は関係ないからです。これだけの時間を働いたのだから時給分の給料をくれというのは、それはそれでそういう契約であれば別にいいのですけど、ではそれ以外に会社の資源を費やした場合、その扱いはどうするのかということです。 ＃ そもそもドラッカーが指摘したように、社内にプロフィットセンターなど存在しないし ＃ コストセンターしか存在しないのですから、成果とはつまり売上ということになります。 ＃ TOCを持ち出すまでもなく、売上とは組織全体でのスループットなのですから成果の独り占めも ＃ ありえないと考えています。 会社のリソースというのは利益を得るためのものです。利益を得るためには、何はなくとも売上を得なければならず、かつその売上以内にコストを抑えなければなりません。コストを抑えるための活動にもコストがかかるのも、売上を得るためにコストが必要なのも自明です。そして人件費というのもコストの（大きな）一部です。であれば、人件費も含めたコストのすべてはリソースを割いている以上利益を得るために使われるべきもので、でなければそのリソースの所有者（突き詰めれば株主）に対する背信行為と言われても仕方がありません。 ＃ 社会貢献という活動を通じた広告効果というのは脇に置きます。 話をescafe.orgに戻すと、私がescafeで目指していた（いる）ものというのは少しだけ形を変えてギョイゾー！というサービスとして出来上がっています。これはスターロジックという会社の正式な商売ですから全員が（Buriを作るということまで含めて）100%フルコミットです。では、これだけのリソースをボランティア活動に投入できるかというと、今のスタロジには無理です。というか、全社員が100%ボランティア活動をするというのは、それはつまり非営利組織ということであり、そうすると食い扶持は売上からではなく寄付から得ることになります。 そうすると今度は寄付する側にとって、寄付するだけの価値を社会に資する存在足りうるのかということが重要になります。それは結局「私たちの価値を伝える」という点では売上を得るためのマーケティングとやることは同じです。それに非営利であってもコストは得られた収入つまり寄付の範囲で賄えなければ続けていけません。コストセービングはやはり重要であり、ではスタッフの人件費というコストはというと、やはり厳密にならざるを得ません。人件費をもらっておいて他のボランティア活動に身を入れているとなると、これまた恐らくは微妙なのでしょう。 非営利組織のマネジメントは営利企業のそれよりも難しいというのが一般的な考えであり私も強く同感するのですが、その一端はこの「誰の金で食えているのか」という非常に俗な、しかしこれ以上なくシビアな問題のせいでもあるのでしょう。 一方で、お客様として、あるいは寄付する立場として、いずれにせよ身銭を支払う側からすると、何時間働いていようと何をどうしていようと、求めるものに対して自分が感じるところの適切な金額であればいいのであって、そうでなければ買うあるいは寄付することもありません。好きなことをやって食っていきたいというのは、多くの人が求めることでしょう。ですがそのためには、その「好きなこと」にお金を出す価値というものを伝える「必要」があるのです。その議論を避けていながら、ボランティアという美名に隠れて好きなことをやろうとしても、そもそもの自分の生活の基盤となる給料の源泉というものに対して本当に後ろめたさはないですか？ という問いにどう答えるのだろうかと考えるのです。 もちろんこんなことを考える必要もないのかも知れません。少なくとも時間幾らで切り売りされるのが自分の価値であるなら拘束時間だけを気にしていればいいのですから。でも、そうであるならボランティアというのは、それは実は拘束時間外における単なる趣味でしかないのでしょう。であれば社会貢献などとあまり大仰に構えず、好きなことを出来る範囲でだけやるということでいいのかも知れません。ただ、そうであるならそういう人には、あんまり社会とか語ってほしくないなぁとか感じたりもします。 さて、escafe.orgです。今後については私に一任されているのですが、結局のところescafeに関係している会社で、今の時点ではescafe.orgに対してリソースを割く余裕のある会社がスタロジも含めてないというのが実態です。ですからそれぞれの個人レベルの出来る範囲というのでとどまっています。スターロジックという会社は今後ますます自分たちのやりたいことに対して投資をしていくことになります。そうするとescafe.orgをやる強い動機付けがないといけないのですが、やりたかったことがギョイゾー！という形になって実現しているので、頭に浮かんでくるのはギョイゾー！の改良案ばかりという体たらくです。 実は「そもそもソフトウェアって本当に人を幸せにしてるんだろうか？」というような、若干子供じみた迷いもあったりする（お役に立つというのと幸せに貢献するというのは、またちょっと違う気がしています）ので、それこそボランティアという形で何をやっていけばいいんだろうかというと、ビジョンに乏しいのが事実です。 escafeのコンセプトは非常に気に入っています。それを業務システムという切り口で実現するとギョイゾー！だと個人的には考えています。ですので、ちょっと違う方向にビジョンを描くことができれば、是非スタロジのリソースをぶち込みたいと考えてはいます。お客様に頂いたお金の一部をescafeに投じることで、結果的にお客様にご納得いただける、そしてもっとギョイゾー！の価格を上げてくれてもいいよ、と言ってもらえるような、そういう未来図ってどういうものかということを今は考えたいと思っています。 ＃ キーワードは「家族と仕事の接点」のように思ってるんですけど、何とも難しいです。 ＃ ホームマネジメントなんて言葉で描けるものでもないと思うんですよね。 ともあれ、例えばマクドナルドさんの「ハッピーセット1個につき1円がドナルドハウスに」というような、お客様へのコストの転嫁を堂々と言えるような、そういうことをやるのが給料という食い扶持に支えられながらやるボランティアというものの資格なのではないか。非常に個人的な、勝手な思いですが、私はそう考えています。 …一応私は創業者であり筆頭株主ですが、持ち株比率が低いので他のメンバー（＝株主）が結束して反対したら代表取締役を降ろされる立場でもあります。escafeについては、お客様だけでなくみんなが納得できるビジョンを考えるのが今の私の役目だと考えています。一応念のため（笑）。まずはギョイゾー！優先ですね(^^; ぎょいぎょい(^^) 最後に改めて。 escafeに期待してくださっている方々には、今の状況について本当に申し訳なく思っています。ひとえに私の力不足です。深くお詫び申し上げます。ごめんなさい。

米E-MU Systemsは、同社製のオーディオデバイスなどにバンドルされていたサンプリング音源「Proteus VX」v2.0を無償公開した。Windows XPに対応しており、編集部にてWindows Vistaでの動作も確認した。現在、同社のWebサイトからダウンロードできる。なお、ダウンロードには同社のメールマガジンの購読が必要。 「Proteus VX」は、VSTインストゥルメントとして動作するほか、単体での動...[ このサイトへ ] [ ニコニコ風に見る ][ ブックマーク ] はてブ：229 / Livedoor：15 / del.icio.us：15[ タグ ] dtm / music / 音楽 / Software / フリーソフト

Michael Arringtonは2005年から、AJAXを使ってカスタマイズすることのできるホームページスペースのサービスは、Netvibes、PageFlakes、iGoogleなどの大手を含めて群雄割拠の状態にあると書いていた。それぞれ利用者の好みに応じてホームページを飾るたくさんのウィジェットを提供しているが、どれも同じようなサービスを提供して相違点はほとんどなかった。 今週サービスを開始したNestingは、AJAXと基本的なソーシャルネットワークの機能を併せて提供し、似たようなサービスが多いこの分野に一石を投じている。また、Nestingは対象を絞り込むことで差別化も行っている。その対象とは「お母さん」だ。 サイトはパステルや角丸のデザインを多用して、ターゲット層に適応した落ち着いた雰囲気を醸し出している。提供されるウィジェットもよく考えられており、圧倒的であったり雑然とした雰囲気を出すことなく、適切な量の情報を提供している。サービス開始時に利用可能となっているのは天気情報、ニュース、「Memory Manager」と名付けられた写真共有等のウィジェットで、カレンダー機能は来月から提供予定。 本サービスでは画面に見えるウィジェットのほか、「友人」や「グループ」などを利用する簡単なソーシャルネットワークの仕組みも提供している。ソーシャルネットワークからのデータはウィジェットで表示することができる。たとえば子供たちのサッカーチームで「グループ」を作ることができ、試合日程等の情報を自動的にカレンダーウィジェットに表示することができる。現在のところカレンダーにはNesting内の情報のみ表示可能だが、iCalやGoogleカレンダーからのインポート機能も準備中だ。 カスタマイズの自由度の点ではNestingはPageFlakesやiGoogleに遠く及ばない。シンプルさをウリにするNestingでは、さほど多くのウィジェットを使用することはできない。しかしサイトが対象とする「お母さん」たちは、子供たちのサッカースケジュールなどのコンテンツが利用できれば、Diggの記事をインポートできないことやプロスポーツのスコアを表示できないことに不満を感じることもないだろう。Nestingは自身をきちんと認識して役割を果たしている。但しMaya’s MomやCafeMomなど、「お母さん」を対象とする競合サイトも多い。 CrunchBase Information Nesting Information provided by CrunchBase ［原文へ］ （翻訳：Maeda, H） タグ: nesting

キリンホールディングスは8月11日、ビールや発泡酒などがのどを通っていくときの感覚「のどごし」を客観的に測定する方法を開発したと発表した。飲料を口にする際、のどの筋肉が動くタイミングや大きさを電気的に測定し、「のど筋電図」として記録したあと、コンピュータ解析した。

用件を伝えるだけのつもりが、ついつい長話になってしまい、話を終わりにするきっかけが作れない。または、苦手な相手と話さなければならず、なるべく早く切り上げたい、といった経験はないでしょうか？ 今日のアプリ『GottaGo』は、あたかも誰からから電話があったように見せかける、”ニセの着信”、を演出するアプリです。 あらかじめタイマーにセットしておけば、その時間に着信画面・バイブ・着信音が鳴り、誰かから電話があったように装うことができ、話を終わらせたり、その場を離れるきっかけを与えてくれます。 【注意】 実際に電話がかかってくる訳ではなく、そのような演出をしてくれるアプリです。 「Settings」で発信者の情報、着信音などの設定をします。 ”Name”欄には発信者の名前を入れます。日本語には対応していないようなので、電話番号などがよいかもしれません。 ”Vibration”でバイブのオン・オフ、”Ringtones”で着信音の設定をします。 人と会う前に、あらかじめタイマーを設定し、”Gotta Go!”をタップします。 iPhone のホーム画面のような表示に変わりますが、実際は”GottaGo”が走り続けています。画面上部にタイマーの残り時間が秒で表示されます。 時間になると、着信音と、バイブ（オンの場合）が作動し、次のようなニセの着信画面になります。 ”Answer”をタップして電話をとる振りをすることができます。実際には電話に出ずに、話をまとめてその場から立ち去るのがよいかもしれません。 着信画面が英語だったり壁紙を選べないなど、細かな改良してほしい点がみられました。今後のアップデートに期待をしたいと思います。 国内の携帯でも同様の目的のサービスが存在するようなので、このアプリも結構実用的で需要があるのかもしれません。 タイトル GottaGo カテゴリ App Store > エンタテイメント 開発 Windy Studios 対応機種 iPhone / iPod touch (要スピーカ) 価格 230 円 レーティング ★★★★☆

Sometimes you just feel all those menus, panels, VBox, HBox, Grid and so on are so boring. Once a while you'd like to tip-toe into the wild side and see what it looks (or feels) like. Here is something you can do, graffiti on your UI. Here is the place you can do that, Graffiti Creator. An amazing Flash site that allows you create graffiti with a long list of styling tool, for each character. ...

This month’s Tokyo2point0 was held at Nishiazabu Super Deluxe with two sessions. Google: Programming the Cloud After (very) short talk on marketing pitch of Google Cloud usage, Gregor Hohpe from Google Inc. talked on technical/architectual advantages of Google engineering system and external services. It is explained that the characteristics of Google’s services are formed by concentrating on getting “roughly correct”, contrary to strict system such like used for money handling system. Technologies for Google internal ...

可変長引数ではAuto Unboxingが優先される？ - kaisehのブログへのツッコミ。米欄に書こうとしたら長すぎたのでこちらに。 ところが可変長引数の場合は、評価の優先順位が違うみたいです。 次のようにプログラムに書き足すと、 public class Test { static void foo(int arg) { System.out.println("foo: int"); } static void foo(Object arg) { System.out. ...

An article describing one developer's transition from the Flex MVC framework PureMVC to the newer Mate.

Web applications are getting richer and more widespread, but it's unclear which of several competing technologies will power them.

しまねOSS協議会は，2008年8月9日に開催された「オープンソースカンファレンス名古屋2008 Nagoya」（OSC2008 Nagoya)のセッション「CMS（コンテンツ管理システム）大決戦」で「島根CMS」が1位を獲得したと発表した。

〔日本語版編集部：この記事の執筆者はSteve Gillmorです〕 八月のしつこい猛暑のために、世界中が寝ぼけている。Web 2.0の棲み分け社会でぼけているのは、全国ネットワーク局各社が競う夏の番組戦争のハイテク業界バージョンだ。パイロットプロジェクトの失敗、すでに飽きられているバラエティ用に悪あがきのリアリティ番組を試作、またまた脚本家のスト、視聴率がひどすぎるのでテスト期間だけでボツになる新番組などなど、ぼけの見本市がWebの上でも横行する。 しかしDVR（デジタルビデオ録画）がすべてを変えた。DVRの登場によって、特定時期の番組競争や季節ごとの編成更新は無意味になった。その代わり、どの月も“ほやほやの上演初日”だ。良質な視聴者とは、すぐに番組をぽいしない人たち＝その番組のまじめな視聴者としてつかまえることのできる人たちだ。そして視聴者のリアルタイムのリアクションが多ければ多いほど、彼らの注意を引くために無駄な小細工をする必要はなく、広告主に自信をもって番組を売り込める。こういう新しい状況の中では、番組の再放送はもはやヒマな時間帯の穴埋めではない。むしろ、視聴者がいつその番組を見たか。その時間帯にはほかにどんな番組や行事が行われていたか。そういったメタデータが視聴者の意思を明確に示す。そして一定の嗜好性を持つユーザたちの共通の視聴パターンが、貴重な指標になる。 というよりも、テレビや音楽のコンテンツは、もはや、ソフトウェアとは違うものではなくて、ソフトウェアと同じようなものになった。そしてiPhone App Storeのリリースは、これまで二つの全く別のジャンルと思われていた両者が交わるための、新しい重要なプラットホームの出現だ。一部のアプリケーションはおなじみのもので、FacebookやMySpaceのようなソーシャルメディアの拡張版、New York Timesのような出版物、あるいはコンテンツを見るためのコンピュータや装置から音楽や番組を仮想的に制御できるAppleのRemote Controlなどだ。このようなアプリケーションがメディア側から提供される。 しかしコンテンツ・サービスばかりでなく、Jottのような“純粋な”アプリケーションもある。Jottは音声をネットワーク上でテキストに変えてくれるサービスだ。あるいはAnnotator、これはユーザがPDFにマークアップできて、その結果をサーバから再配付できる（MacのPreviewやAdobe Readerで見る）。このようなアプリケーションをダウンロードし、ソフトウェアとして使い、結果をユーザのデスクトップから元のプラットホームへ再びアップロードする。こう言ってよければ、それはソフトウェアとしてのサービスだ。 しかしさらに破壊的なものは、上記の二つの種類の境界がはっきりしないような形で登場する。それは、ユーザ～視聴者の積極参加と従来型のコンテンツをブレンドした新しいメディアだ。PandoraやAOL Radioのようなアプリケーションは、まさに、ソフトウェアが使われる範囲をモバイル空間に拡張するが、これらのアプリケーションの最近の利用データを見るかぎり、なお一層の質の向上のための投資も、そしてさらに新たなチャネル専用にメディアを作るための投資も、完全に是認されるのだ。 では、既存のコンテンツのこういった新しい目的多様化を背景とする第二の波として、これからはどんな番組が登場するのか？ たとえばそれは、携帯向けのリアリティ番組だ。出演者や競技者は現実世界を歩き回り、各人の携帯電話がトランザクション（ありとあらゆるやり取り）の道具になり、製品、イベント、人間等々への関心の有無がすべてその道具で表現される。番組によっては、複数の個人の行動や意思表示がチームのそれとして集積されることもある。その日のニュースやTwitter上のいろんな話題の群、ホワイトハウスを目指す競争などへの反応や質問への答えが、いろんな層的特性（年齢、性、等々）によって分析される。 ていうか、むしろ、ハイパーリアリティ番組という新しい番組が可能になると言ったほうがいい。App Storeが、家庭（従来の一般視聴者）を捨てて仮想コミュニティに侵入したAdsense的ビッグブラザー（番組提供者）のためのゲートウェイだ。装置と帯域の費用を番組が持ち、Appleは同社の電話機製品(iPhone)のビデオの側面を新たなビジネスチャンスとして生かし、コンテンツを作る。コミュニティも積極的に参加し、アプリケーションと電話機製品の両方を使って、番組の分類や編集を手伝う。 それを「対話型ビッグブラザー」と呼ぼう。完成製品をストリーミングを使ってユーザに送り戻すマーケティング活動を通して、放送ネットワークのリーチを生かした有意義なループが出来上がる。App Storeのダウンロードから始まったものが、ネットワーク番組のいわば「ドングル」になり、さらにそれが、その番組の上に浮かび出てくる「個人」たちの市場を作る。サーバ上のDVRを認めた連邦控訴裁判所の判決は、今後上級審で覆されることもあり得る。しかしApp Storeを見るかぎり、この小鬼を瓶に戻すことはもう不可能である。TV-I（TV-Interactive,対話型テレビ）は、もうほとんど私たちの社会の既成事実だ。 [原文へ] （翻訳：hiwa） タグ: Apple, iPhone 【関連記事】 楽曲無制限のiPodなら100ドル一括前払いも「アリ」？ 最初のiPhoneキオスク、シアトルのAppleストアに出現 明日朝10時からここでiPhoneのSDK発表イベントをライブ中継するのでよろしく 新登場のiPhoneアプリケーション一覧 携帯をiPhoneモドキに変えるDIYテクニック集

東京にある世界初のロボットベンチャー企業ZMPは、同社のベストセラーロボットnuvo（ヌーボー）のソースコードを公開する。このヒューマノイド（人型二足歩行ロボット）は2004年に発表されたが、ZMPによれば初めての家庭用ロボットだという。 ロボットのソースコードを公開することにより、ユーザー参加型の研究コミュニティを形成するのがZMPの目的だ。 ターゲットとしているのは大学、企業および個人ユーザーだ。ソースコード公開プログラムのパッケージ価格は257250円で、nuvo本体とソースコード（C++およびC）、電気回路図、３日間の講習（メンテナンス、システム分析など）が含まれる。 関連知財を外部ユーザーに公開することにより次世代ロボット開発を加速するのがZMPの狙いだ。「nuvoソースコード公開プログラム」は限定50台まで発売される。最初のユーザーは東京工科大の教授。 ところで日本人以外のユーザーに対するサポートはどうなるのだろうか。英文サイトが最後に更新されたのは2006年のようだが・・・ Via Tech-On [原文へ] （翻訳：shiro） タグ: CrunchGear 【関連記事】 ［CG］企業戦士のラップトップやケータイは自費で買うべきか ［CG］今度はiPhone 2.0 jailbreakツールのウインドウズ版だ！ ［CG］中国にiPhoneを売り込むためレベニューシェアリングを諦めたアップル ［CG］世紀のハッカーKevin Mitnickが暴露本を書く ［CG］一本とられたおバカなレポーター

ちょっと前、若い人が原因不明の発熱で入院して、診断がつかなかったことがある。 目に見える症状は「発熱」だけだったから、熱源調べたり、血液の培養出したり、 考えて、調べて、「これ」という原因がはっきりしないまま、何日か経った。 その方は、外来でCTを撮られてて、わずかな胸水があったから、フォローの意味でCTが再検された。 夕方のカンファレンスで「原因がはっきりしない人がいる」なんて、その患者さんの画像が供覧されて、 誰かが「肝臓縮んでるよね…」なんて指摘した。 そういう視点で検査データを見直すと、たしかに日を追うごとに肝機能が悪くなっているように見えて、 この時点でうちの施設では白旗上げて、大学にお願いすることになった。 大学では、入院したその日に原因分かって、すぐに治療が始まった。 検査の力 どこの病院にも「スクリーニング採血」という考えかたがあって、入院した患者さんは、 原因にかかわらず「一通り」の採血を受ける。変な病気を見逃したり、あるいは肝炎みたいな 感染症を持っていないかどうか、最初の採血で見当をつける。 大学病院は、「スクリーニング」の範囲が広大で、生化学検査一通り、感染症一通り、 膠原病だとかアレルギー、ありとあらゆる検査を、全ての患者さんについて提出する。 紹介した患者さんは、結局のところ膠原病の初発症状を見ていたみたいで、 大学に入院して、入院時の採血検査を受けて、その日の夕方には答えが出た。 分かってしまえば、あるいは大学流のやりかたをやってさえいれば、研修医でも分かるぐらい、 簡単なことだった。 大きな数に対する態度のこと 医療の業界では「なるべく少ない検査」というのが美徳で、「スクリーニング」みたいな やりかたも、自分が研修医だった頃は邪道と言われて、頭を使う医師になりたかったら、 ああいった真似をしてはいけないんだよ、なんて教わった。 物理学の業界、超ひも理論なんかの入門書を読むと、大きな数に対する態度がずいぶん違う。 あの人達が今問題にしてるのは、理論を統合しようとしていくと、必ずある計算の答えが 無限に発散してしまうことらしくて、「無限じゃない」ことが分かれば、それはもう画期的な発見で、 無限でないことが証明されたその時点で、その理論は力ずくの計算が可能であると 認識されるんだという。 宇宙の深遠見てる人達と比べることが間違いなんだけれど、 検査30種類とか出したら「そんなに出して何をしたいの?馬鹿なの?殺したいの?」とか上級生から 頭叩かれるような業界に長くいると、30種類ぐらい、物理学の人達のこと思えば、ゼロに近似したって いいじゃないかとか思う。 もっと検査出していいような気がする 「70種類」の採血項目出していいなら、たいていの病気が診断できるような気がする。 そもそもほとんどの疾患は、患者さんの症状診れば診断可能で、検査が必要な人というのは、 その時点で「普通のやり方では分からない」という大きな限定条件が付くから、 「70種類の検査」の威力は、通常以上に高くなる。 外注検査のカタログは分厚くて、あれに載ってる検査を全部提出すると、もちろん70種類には 全然足りないんだけれど、検査の大半は、臓器の機能を評価するためのもので、 診断につながる検査は案外少ない。 一般性科学検査と血算、培養と、代表的なウィルス抗体、膠原病の採血一通りに腫瘍マーカー一通り、 採血で証明可能なホルモン検査一式、全部出してもたぶん、まだ70種類には届かない。 「入院したら70種類」をやっていいなら、たぶんたいていの病気はこの時点で診断できるし、 「70種類が全て正常」という情報と、入院した患者さんの症状を組み合わせるだけで、 たぶん残る病名は、かなり絞られてくるはず。 診断学の教科書は分厚くて、知らないといけないことは年を追って増える一方だけれど、 人体の構造だとか、弱点だとか、昔も今も、もちろんほとんど変わらない。 「検査は少なければ少ないほどいい」という態度は、診断学の教科書に書いている病名を見て、 そのあまりの多さに恐れをなした誰かが、「どうせ病名は無限にあるんだから、最初は最小限」なんて、 大きな数に白旗を揚げた名残のように思える。 大きな数を見て、それを「無限である」と考える人と、 「十分に計算可能なぐらい有限」と考える人とでは、たぶん同じ数でも、 見えかたが全く異なってくる。 病気の数は、たぶん今も昔もそんなに変わらないけれど、検査のやりかただとか、 コストだとか、技術が進歩して、今はもう、「70種類」もそれほど無茶じゃなくなっている。 自分たちの学問も、そろそろ「有限」に舵切り直してもいいような気がする。