Tender Surrender

今回はOpenSocialでネット上にあまり情報のないPreloadについて、解説してみます。

ガジェットレンダリングの流れ

単純にRSSを表示するガジェットを例に説明します。あるコンテナSNS上でこのガジェットを表示する場合、下記のような手順を踏みます。

  1. コンテナSNSのレンダリング
  2. ガジェットサーバーがガジェットをレンダリング
  3. ブラウザ上でガジェットのJavaScriptが初期化
  4. 外部サイトのRSSを取得するためのAjaxリクエストをガジェットサーバーに送信
  5. ガジェットサーバーが外部サーバーにリクエストを送信(キャッシュがあればスキップ)
  6. ガジェットサーバーはレスポンスをブラウザに戻す
  7. ブラウザ上でガジェットのJavaScriptがレスポンス内容を元に記事一覧をレンダリング

ざっとこんな感じになります。

OpenSocialコンテナの動きを理解していない人には若干分かりづらいかもしれません。この辺りの記事を参考にしてください。

さて、この一連の動きを効率化することで、全体の体感レンダリング速度を速くする方法があります。それが今回ご紹介するPreloadです。

ガジェットのレンダリングを高速化するPreload

Preloadは文字通り、レンダリングに先立ってロードしておいてくれる機能です。使い方は簡単で、/Module/ModulePrefs/[email protected]に呼び出したいURLを記述します。これで、先ほどのレンダリングの挙動が下記のように変わります。

  1. コンテナSNSのレンダリング
  2. ガジェットサーバーがPreloadで指定された外部サーバーにリクエストを送信(キャッシュがあればスキップ)
  3. ガジェットサーバーがガジェットをレンダリング
  4. ブラウザ上でガジェットがJavaScriptを初期化
  5. 外部サイトのRSSを取得するためのAjaxリクエストをブラウザ上で処理
  6. ブラウザ上でガジェットのJavaScriptがレスポンス内容を元に記事一覧をレンダリング

図にしてみると一目瞭然ですが、通信部分のオーバーヘッドを削減できています。こりゃ便利。

仕組みは単純で、ガジェットがプリフェッチした外部コンテンツを埋め込んだソースコードをブラウザに渡し、makeRequest時にプリフェッチした内容が存在すれば実際のAjaxリクエストを行わずに応答を返してしまう、というものです。

Preload利用時の注意点

Preloadはとても便利な反面、扱いにくい性質のものでもあります。以下を理解して、ポイントを絞って使う必要があります。

キャッシュの有効期限をコントロールできない

結構致命的なのがこれです。キャッシュの有効期限をコントロールできないと、デフォルト(24時間が多い)のキャッシュ期限が適用されます。これを回避できるケースとしては、ユーザーが任意の動作でmakeRequestを行うため、その時にキャッシュの有効期限をクリアできる場合が挙げられます。逆に言うと、RSSを表示するだけでユーザーは任意に更新できない、でも更新頻度は1時間程度、というようなガジェットには向いていません。

ContentTypeを指定できない

通常makeRequestを行う場合、ContentTypeをDOM, FEED, JSON, TEXTから選択することが出来ます。特にFEEDに関しては、RSS/RDF/Atomを丸めてJsonで返してくれるため、慣れた人には便利な形式です,

しかしこの挙動は、明示的にContentTypeとしてFEEDを指定し、ガジェットサーバーが外部コンテンツを取得した際に特別な処理を行うことで実現されているため、ContentTypeを指定できないPreloadでは、これを行うことはできません。RSS等をPreloadしたい場合は、DOMを選択してパースするしかありません。

UserPrefsの内容を反映することが出来る

/Module/ModulePrefs/[email protected]の内容に__UP_****\__といった形でUserPrefsの内容を含めることができます。これは残念ながらmixiアプリでは使えない技ですね。

<Preload href="http://example.com/example.php?id=__UP_userpref__" />

Signed Requestが使える

/Module/ModulePrefs/[email protected]に”signed”を指定することで、署名リクエストが行えます。これの利点は、ガジェット側でビューアーのIDを指定しなくても、サーバーが署名と一緒に送ってくれるため、上記のUserPrefsのケースのように、URLを工夫する必要がない点です。

コードを変える必要はない

PreloadはガジェットXMLにメタデータを追加するだけですので、基本的にJavaScriptのコードをいじる必要はありません。もちろん、キャッシュを気にしたりするといじった方がよい場合もありますけどね。

Preloadはいくつでも指定できる

実はPreloadはいくつでも指定できます。これまでに挙げた条件をクリアしているのであれば、思い切って使ってみましょう。

まとめ

今回は存在が地味なのであまり注目されていないけど、うまく使えば非常に便利なPreload機能を紹介しました。うまいこと使いこなして、一流OpenSocialerを目指しましょう。

Read on...

OpenSocialといえばmixiアプリ、いやむしろmixiアプリってそういえばOpenSocial?という感じの空気をひしひしと感じてますが、皆さんいかがお過ごしでしょうか。

今日はそんなmixiアプリの中身を覗き見るブックマークレットをご紹介します。

Peep mixi Appli XML

これを読んでるであろう人に詳しい説明は不要なので、簡単に書きます。

上記リンクをブラウザのブックマークに保存してください。mixiアプリの画面を開いてそのブックマークをクリックすると、ガジェットXMLのソースページが開きます。SafariとFirefoxで動作確認済みです。

これで、ガジェットがどんな風にできているのか、気軽に覗き見ることができますね。

※そういえばgooホームもOpenSocialです。

Read on...

6月9日にパシフィコ横浜にてGoogle Developer Dayが開催されました。
僕は基調講演に一瞬と、OpenSocial Panel Discussionのセッションに登壇させて頂きました。

基調講演デモ

基調講演では、先日一般ユーザー向けにも公開したgooホームのOpenSocialを使って、goo地図ガジェットとフォトビューアーガジェットがPhotomemoのガジェットに連動して動く、というソーシャルウェブ・ポータルというコンセプトを打ち出したgooホームならではのデモをお披露目しました。基調講演では言いそびれてしまったのですが、このアイディアは元々、先日行われたHackathonでディベロッパーの1チームが見せてくれたものを元にしています。

実装としては、OpenSocialに含まれるpubsubというフィーチャーを使っています。pubsubは、任意に作成されたチャンネルに対してオブジェクトをpublishすると、同じチャンネルをsubscribeしているガジェットのコールバック関数が呼ばれオブジェクトが届く、というかなり単純な仕組みです。pubsubについては、近いうちにgoo Developer’s Kitchenの方にもドキュメントを追加します。

また、今回のデモを行うため、PhotomemoチームにPhotomemoガジェットとフォトビューアーガジェットを開発して頂きました。ご協力ありがとうございました。

OpenSocial Panel Discussion

もうひとつ参加させて頂いたのがPanel Discussionでした。今回は先日のデブサミでもご一緒させて頂いたリクルートの川崎さんに加え、mixiの川岸さん、そしてGoogleの及川さんとのディスカッションになりました。

内容については、OpenSocialというよりはSocialWebを広い観点で捉え、その中で現状使えるOpenSocialというピース、およびこれから広がっていくSocialWebの世界に関して。僕の中でもmixiアプリとgooホームガジェットの目指す所がまるっきり違うことに気付いたのは割と最近なので、その辺りが分かりやすく伝わるようにお話しさせて頂きました。

まとめ

Panel Discussionの場でも言いましたが、日本のSocialWebという世界観にまだまだ伸びしろがあると感じています。海外に比べると実名が好まれなかったり、最大のSNSがクローズドだったりと、海外のそれを単純に輸入できないことは十分理解していますが、必ず近いうちに求めらる技術になっていくと思います。

共感された方はぜひ、SocialWeb Japanにご参加下さい。

Read on...

最近「OpenSocialでOwnner毎 or Owner*アプリ毎の永続化方法 オプション」辺りでOpenSocialのパーミッションに関する疑問がいくつか挙っていたので、どういう場合にどのデータにアクセスできるのか、ついでに、FriendConnectにおけるパーミッションモデルについてもまとめてみます。

まずは最低限の知識としてビューアー(VIEWER)/オーナー(OWNER)という考え方と、基本情報/個人情報を押さえておきましょう。

ビューアーとオーナー

ガジェットは貼られる場所によって呼び方が異なり、これをビュー(view)と呼びます。OpenSocialでは標準的にhomeビュー、profileビュー、canvasビューが用意されています。ここを参考にしてください。

ご覧いただくと分かると思いますが、homeビューのガジェットは自分が見るマイページに貼られる前提で,profileビューは他人が見るプロフィールページに貼られる前提になっています。では,「自分が見る」「他人が見る」は何を意味するのでしょう?

OpenSocialガジェットには所有者/オーナー(OWNER)という考え方があります。オーナーとは,ガジェットをページに貼付けたページの持ち主を指しています。反対に,ガジェットを見る人を閲覧者/ビューアー(VIEWER)と呼びます。

つまり,homeビューで「自分が見る」が意味するのは,オーナーでありビューアー。逆に,profileビューで「他人が見る」が意味するのは,ページを見ているビューアーと,ページの持ち主のオーナーです。もちろん,プロフィールページをオーナー自身が見ているケースでは,オーナーとビューアーは同一人物になります。canvasビューでも同様。

基本情報と個人情報

OpenSocialではプロフィール情報は大きく2つに分けられます。
goo Social Platformではこれを基本情報(id, profileUrl, thumbnailUrl, nickname)と個人情報(その他のプロフィール)と分けて呼んでいます。詳細はこちらをご覧いただいた方が早いと思います。

基本情報は、必要最低限の情報で、個人情報はさらに詳細で重要性の高いものと思ってください。

基本ルール

これらを踏まえて、各種情報をやり取りする際に必要となるのが下記の基本ルールになります。

  • 個人情報を取得する場合、対象となるユーザー(オブジェクト)が同じガジェットをインストールしていること
  • オブジェクトが友達の場合、ガジェットをインストールしていなくても基本情報のみ取得可能
  • 更新・削除はビューアーが自分のデータを操作する場合のみ可能

 

ミソは、

  • 友達でもガジェットをインストールしていない人の個人情報は取得できない
  • 友達じゃなくてもガジェットをインストールしていれば個人情報が取得できる

ところ。

 

「なぜそんなに面倒なの?」「なんでガジェットインストールしてないと個人情報取れないの?」と思われる方も多いかと思いますが、理由はずばり、「プライバシーの保護」です。

  • 個人情報はコンテナがユーザーから取得したものである
  • 個人情報保護法では、収集した個人情報を事前に通告した目的外に利用してはならない
  • 個人情報はコンテナが取得したものであり、第三者に譲渡や開示する(ディベロッパーがガジェット上で利用する)場合はユーザーがそれを理解している必要である
  • ユーザーは誰が自分の個人情報を取得したかを把握できる必要がある
  • ディベロッパーは受け取った個人情報を外部に流出させることも、売り渡すことも、理論的には可能である
  • ネット上にパブリックになっている情報でも、受動的に(スクレイピング等)渡す場合と、能動的に(API経由)渡す場合では、法的意味が異なる(そういう意味では、mixiのようなクローズなSNSでも、gooホームのようなオープンなSNSでも扱いは変わらない)
  • ディベロッパーが故意または事故で個人情報を漏らす等した場合、責任はもちろんディベロッパー側にあるが、情報を提供したコンテナは、ディベロッパーとの連絡を確実に取れる手段を用意しておく必要がある

 

若干複雑ですが、こんな理由で、本人が意図して利用していないガジェットに対しては、基本的に個人情報を渡さない方向に倒されている、という訳です。これはgooホームだけの話ではなく、まだ明示されてはいませんが、mixiも含め、今後登場するであろうOpenSocialコンテナすべてで似たような実装になると思います。

なお、基本ルールに対する特別ルールについては複雑になるのでここでは説明しません。興味のある方はこちらをご覧下さい。

FriendConnectのパーミッションモデル

さて、ここまで一般的なOpenSocialについて解説してきた訳ですが、FriendConnectにおけるガジェットのパーミッションについてここで考えてみましょう。

通常のSNS上のOpenSocialでは、ガジェットをインストールしているかどうかで個人情報を提供するか否かを決定していましたが、FriendConnectではちょっと事情が違います。それは、ガジェットのオーナーが人間ではなく、サイトである、という考え方に基づいている、という点です。

こちらの記事をご覧いただければ分かると思いますが、

Ownerはサイト。そういえば、FriendConnectガジェットを入れた時点では、自動的に自分がメンバーになったりはしていませんでした。Ownerは貼付けたサイトという仮想人格が担うようです。

サイトという仮想人格、というところがミソです。つまり、FriendConnectでは、ユーザーがオーナーになることはあり得ないのです。そのため、先に解説した一般的OpenSocialのパーミッションモデルをそのまま適用することはできません。

 

では、FriendConnectではどういう場合に個人情報を取得できるのでしょうか?

現実的には、私の把握している限り、まだFriendConnect上で基本情報以上の情報(個人情報)を取得することはできないので、必ずしも正しいとは言えないのですが、「そのサイトに参加しているか否か」がパーミッションを得るための条件のようです。

言い換えると FriendConnectの基本ルール:

  • 個人情報を取得する場合、対象となるユーザー(オブジェクト)がガジェットを動かそうとしているサイトに登録していること
  • オブジェクトが同じサイトに登録していれば、個人情報も含め取得可能(実際は取得できないので想像)
  • 更新・削除はビューアーが自分のデータを操作する場合のみ可能

となります。一般的OpenSocialの基本ルールと並べて比べてみると、違いが分かると思います。

 

まとめ

今回は、先日のHackathonでも多数の質問が出たパーミッションモデルの話を解説してみました。開発者にとっては面倒なだけですが、コンテナやユーザーにとっては、プライバシーを守るためにとても重要なことです。

OpenSocialガジェット開発もある程度のレベルに達してきたら、この辺りの理解をしっかりやっておくことが重要だと思います。

Read on...

 ついに、ようやく、mixiによるOpenSocial実装、mixiアプリが一般ディベロッパーにも公開されました。

個人の皆さまでもソーシャルアプリケーションの開発が可能に。「mixiアプリ」オープンβ版公開!

なんといっても1500万を超えるユーザーを抱えるmixiというプラットフォームに、誰でもガジェットを提供して一般ユーザーに使ってもらえるというのは魅力だと思います。OpenSocialを支持する者としては、ついにその時が来たか、という印象です。同時に、各所での盛り上がりを見るにつけ、羨ましい限り。

てことで、よういちろう氏と一緒にgihyo.jpで連載しているこちらの記事

http://gihyo.jp/dev/serial/01/opensocial/

でサンプルとして使っているはてブチェッカーガジェットを早速公開しました。

http://platform001.mixi.jp/view_appli.pl?id=682

 

 

gooホームで作ったガジェットですが、これをmixiアプリに対応させる上で気づいた点がいくつか・・・。

  • 現在の利用規約、ディベロッパー登録の方法だけでガジェットが原因で発生する法的問題をカバーする方法はちゃんと考えられているのか?
  • ガジェットを経由して個人情報を外部に流すことは理論的に可能だが、今の利用規約で一般ユーザーはそれを許容しているのか?
  • APIの不具合が散見、というかかなり見られる。
  • OpenSocialの拡張仕様がOpenSocialのスタイルを無視している。(opensocial.PersonFieldとか)

仕様周りは、よういちろう氏もmixiに移籍したことだし、今後改善していってもらいますか・・・。

Read on...