去年から試験実装やデモなど行なっていた、WebからのTV連携（PCで検索した YouTube ビデオをDLNA対応テレビに飛ばして表示する）ですが、勤め先(NTTコミュニケーションズ)から試験サービスとして正式に公開しました!!やったーーー :D 名前は、ベタですが "Device Orchestration on Chrome Packaged Apps v2"。 試験公開するに辺り、機能は一点集中型で行こうかなと。で、同僚のsakkuruさん（最近、HTML5とか勉強会のレポートとか書かれています）と「どんな感じにしよっか」と相談。で、 「TVってダラダラ見れるのがいいとこだよねー」 ってことで、YouTubeで検索した結果がエンドレスでTVに流れ続けるというものにしました ;-)。 最新の Chrome Packaged Apps v2 で動いていて、その機能を使って、DLNAの各種

Chrome Apps v2's socket api Chrome の Web appsが manifest v2 に変わり、その機能、特に Packaged Apps が大幅に変わっています。 What Are Packaged Apps? その中で僕が特に注目しているのが、socket api。ChromeのPackaged Appsから、生のソケットコーディングが出来るようになります。 この socket api ですが、これまで tcp ソケットでサーバーを立てることができなかった(listenとかacceptのメソッドが無かった)のですが、昨日 Google API Expert MTGで 吉川さんから、「昨晩Chromiumで実装されたみたい」との情報が。ということで、早速簡単なWebサーバーを動かしてみました・・・というのが今日のEntryです。(執筆時点では、すでに、ca

昨日、一昨日と幕張で開催されたW3CのWorkshopに参加しました。内容は、Web技術をデジタルサイネージにも適用していこうというもので、僕のほうからは「WebIntentsなどのAPIを利用して、サイネージとスマフォとかを連携すると面白いんじゃない？」といった提案をさせてもらいました（毎度のことながら、自分の英語力の無さに反省しきりなわけですが・・・）。 で、このWorkshopの際、W3C の Michael Smithさんに興味深い動きを教えていただいたので、今日はその紹介をします。 System Applications Working Group 最近、System Applications という Working Group が立ち上がったそうで、そのcharterページ後半に取り扱おうとしているAPIが書いてあるのですが、これが凄い！！ 一部ピックアップすると Power

昨日、Webkit & Opera/HTML5勉強会で紹介したwebsocket&MeCabによる「坊ちゃん」への自動ルビ（ふりがな）振りデモですが、よくよく考えたら「pipelineってことは、解析リクエストの結果が返るのを待ってたらダメじゃん」ってことで、こちらのデモをwebsocket pipelineに替えてみました。 すなわち、文単位の解析依頼をとにかく送りつづけて（解析結果が返ってくるのを待たずに）、どれぐらい高速化するか見てみようというわけです。そもそも、websocketは、好き勝手に送受信できるプロトコルなので、pipeline処理にはうってつけだよね！ってことで。 あと、テキストマイニングと言えば、「やっぱり基本はわかちでしょ」ということで、websocket pipelineを使ったわかち書きのサンプルも作って見ました。 コードは、http://code.google

今日のブログのお題は、SPDY。Webサービスを「とにかく速くしよう！！」ということで、Google が提唱したプロトコルです。既にChromeでは、このSPDYが実装されており、サーチやGMailなど Google が提供する殆どのサービスで既に利用されています。 最近では、FireFoxへのインプリが始まったり、HTTP/2.0検討のベースとなるなど何かと話題のWeb最新技術です。 SPDYがWebを早くする仕組み SPDYは、現状のWebが抱える問題 ”HTTPは遅い!!" を解決するものです。HTTP が "遅い" 原因は色々ありますが、中でも最も大きいのは Request and Response の制限です。このため、SPDY では一本の HTTPS セッションの中で複数の HTTP セッションを多重化するといったことを行い高速化を実現しています。 Request & Resp

新年明けましておめでとうございます。本年も宜しくお願いします。 さて、今年最初のPOSTは、僕が今一番興味を持っているAPIの "Web Intents" について取り上げます。 この、"Web Intents"は、Androidの "Intent" に非常に良く似た仕組みで、異なるWebアプリケーションを自由に連携することを可能とするAPIです。Webサイトの不足機能に対し、他のWebアプリの機能を利用することが可能になるため、スピーディーなWebアプリの開発を実現してくれます。利用するユーザーにとっても、手慣れたWebアプリを利用できるメリットが有ります。 このAPIの更に興味深いところは、 Device機能の利用 デバイス内の固有の機能（カメラや、住所録など）をブラウザから利用する。 Web of things スマートフォンやテレビなどのマルチデバイス連携サービスをWebで実現する

前回のエントリーに引き続き、今回も Web Intents に関するポストです。今回は、「なぜ、Web Intents が Web でのマルチデバイス連携サービスを実現するにあたり、重要な API となるのか？」について説明します。なお、Web Intents の基本と使い方については、前回のエントリーを参照下さい。 Device APIs の最新動向 Web Intents とマルチデバイスとの関係に入る前に、Device APIs の最新動向について触れたいと思います。 スマートフォンなどの Device のネイティブ機能を Web から利用する API について、 W3C では、主に Device APIs Working Group で仕様化が進められています。例えば、住所録情報を取得する "Contacts API" や、カメラを起動し、撮影した写真画像を取得する "HTML M

WebSocket が、12月12日についにRFCになりました（RFC6455)。テキスト転送だけでなく、バイナリー転送もサポートされ、コネクションをキープするための ping/pongなどコントロールフレームも定義されました。rfcになる過程で様々なバージョンと、その実装系が出ていますので、そこのネゴシエーションの仕組みが入っていたり、以前は割と自由に使えそうだった subprotocolが、IANAにレジストレーションが必要になったりと、なかなかしっかりしたプロトコルに仕上がっている印象です。 さて、今年最後となる、今日のポストでは、このWebSocketにより、今後のWebはどうなっていくのかについて、僕が最近感じている妄想を書き連ねてみます。 WebSocketとは、いったい何なのか？ さて、WebSocketとは、いったい何なのでしょうか？この問に対して、一般的には、 WebでP