「OpenSocialのアーキテクチャ」スライドを公開します

去る11月11日にリクルートメディアテクノロジーラボの「カフェ」でTokyo GTUG(Google Technology User Group) #4のイベントが開催されました。テーマはOpenSocialで、今回は「OpenSocialのアーキテクチャ」というテーマで講演させて頂きましたので、スライドを公開します。

OpenSocialのアーキテクチャ

View more documents from Eiji Kitamura.

OpenSocial Hackathon in 会津

9月18日に会津大学で行われる会津ITサマーフォーラムで講演することになりました。僕のセッションでは「OpenSocialのアーキテクチャ」というマニアックなネタをお話をさせて頂く予定です。 また、せっかくの会津なのでMashup Awards5のキャラバンも兼ねて、翌19日にOpenSocial Hackathonも開催することになりました。 OpenSocial入門を執筆されたmixiの田中洋一郎さんやMTLの川崎有亮さんも参加されます。地元の方は滅多にない機会だと思いますので、ぜひご参加ください。 詳細と参加フォームはこちら: OpenSocial Hackathon in 会津

Snow LeopardにMySQLをインストールする

Mac OS XをSnow LeopardにしたらPHPが5.3になってて、PartuzaやShindigを使うのにentropyを入れなくても済んで、とても素敵です。

しかし同環境でMySQLを使うのに、ちょっとごにょごにょしなければならなかったのでメモを残しておきます。(2009年9月現在の情報です)

MySQLをダウンロード

MySQLのバイナリをこちらからダウンロードします。このページの下の方にあるMac OS X(package format)の中から、(Snow Leopardは10.6ですが)Mac OS 10.5(x86_64)を選びます。

MySQLをインストール

インストールはGUIでできます。環境設定項目とスタートアップアイテムもインストールしちゃいます。パスも切っておきましょう。

~/.bash_profileを作るか、既にあれば下記を追記します。

PATH=$PATH:/usr/local/mysql/bin
export PATH

さらに

> source ~/.bash_profile

とかやれば、即時反映できます。

ごにょごにょする

ここからがポイント。

>  cd /usr/local/mysql
>  sudo ./script/mysql_install_db

そんで

>  sudo cp /etc/php.ini.default /etc/php/ini
>  sudo vim /etc/php.ini

とかやって、

mysqli.default_socket = /var/mysql/mysql.sock

の部分を

mysqli.default_socket = /tmp/mysql.sock

に書き換えます。

これで、MySQLを立ち上げ直せば、オッケー。環境設定からMySQLをスタートすれば、PHPでMySQLが使えるようになったはず。

追記

ちなみにこの設定はPartuzaの動作を確認したのみですので、他のことをやる場合はもう少しいじる必要があると思います。

個人名刺作りました

プライベートのブログに書いてた内容ですが、ぜひ紹介したいのでこちらにも。

勉強会などによく行くようになって、前々から個人名刺が欲しいとずっと思ってました。かといってよくある小さいサイズのはヤだし、名刺を作ってくれるサービスはたくさんあるのでなかなか手を付けられず・・・そんな時に見つけた記事がこれ。

ブロガー名刺、送料込みで１０００円じゃすと！

デザインにこだわりたかったし、値段も安かったのでこれは！と思い、早速申し込みました。

フルカラー100枚ながら1300円、加えて何度でもデザインをやり直してくれるという太っ腹ぶり。お言葉に甘え、仕上がりまで1ヶ月程度を要しましたが、ついに完成しました。

ブロガー名刺という話でしたが、最近勉強会で会う人などにはTwitterが最も通じやすいので、Twitterをメインにし、OpenSocial関係はおまけ。肩書きはSocialWeb Japanにしました。もちろんブログのURLも入れて。

というわけで、仕上がりには満足してます。まだ嫁にしか渡してません。早く誰かもらって！

この値段でこの仕上がり、前川企画印刷さんに大感謝です！みなさんもどうぞ！

Shindigのコミッターになりました

「ウェブはソーシャルであるべきだ」。これは今の会社に
入社した2005年くらいからずっと訴えてきたことです。ソーシャルグラフをプラットフォーム化することで実現できることがたくさんあります。まずはポータルサイト全体をソーシャル化することを目標にし、作り上げたのがgooホームでした。

将来の構想はその時点で既にあって、いずれはポータル外のサイトとも接続して、インターネット全体がソーシャルグラフで繋がることをイメージしていました。そんな時に登場したのがFacebookです。

Facebookがやろうとしていたことは、SNSの中にサービスを取り込むという、僕の考えとは真逆でしたが、結果的にやろうとしていたことは似たようなもので、先に実現されたことにくやしい思いをました。そしてOpenSocialが登場します。

OpenSocialは仕様を民主的に決めて行くオープンなスタイルでした。オープン性のメリットは計り知れません。2つ以上のシステムを繋ぐのに、仕様から作るよりも、既に決まり事があれば話が早いのは火を見るよりも明らかです。技術的工夫もさることながら、コミュニケーションコストは大幅に削減できます。

さらに、オープンな仕様であればそれを使ったプロダクトが生まれやすくもなります。OpenSocial周りでも既に、よういちろうさんのOpenSocial Development EnvironmentやOpenSocial Client Library、OAuth関連ライブラリ、そして僕の作ったOpenSocial Signed Request Libraryなど、様々なオープンソースプロダクトが生まれ、後発の生産性を上げています。

そんなOpenSocial関連プロダクトの中心となるのが、OpenSocialコンテナのリファレンス実装であるShindigです。

僕がOpenSocialの既存仕様を学ぶ上で紐解いたのものこのShindigでした。当時はまだ日本でほとんど手をつけている人がいなかったため、API Expertとして声をかけて頂いたのも、Shindigに関する情報をこのブログで公開していたためです。

その後実際にgooホームでディプロイするに辺り、様々なパッチを書き、Shindigの開発チーム提供してきました。(もちろん、OpenSocialの仕様自体にも口を出してきましたが。)そうこうしているうちに、1年半ほどが経過し・・・

このたび、Shindigのコミッターになりました。

PHP版ShindigのメインコミッターであるChris Chabot氏とは、PHP版の最初のコミット前から連絡を取り、昨年のGoogle IOでも直接お会いし、その後もメッセンジャーで話したりしてきましたが、そのChrisにShindigのコミッターに推薦して頂いたのです。

Apache Software Foundationでコミッターになるには、既存コミッターの投票が必要らしいのですが、これまでの貢献を認めてもらい、承認して頂きました。

PHP版Shindigは今や、全世界述べ5億人(!)が26以上のSNSで使っているといいます。にも関わらずフィードバックされていたパッチはそれほど多くなく、自分がやってきたことは貴重だったようです。

本来僕にとってOpenSocialというのは理想のSocialWebを実現するための道具に過ぎないのですが、少なくとも日本では実質的なデファクトであり、mixiやgooホームで使われているShindigというプロダクトは、その根幹を支えるものです。

今後はShindigのコミッターとしても、日本のSocialWebを作り上げ、支えて行ければと思います。

(たぶん)世界初！OAuthを使ったOpenSocial向けTwitterクライアント「ガジェツイ！」を公開しました

gooホームのOAuth機能公開に合わせ、TwitterのOAuthを使ったガジェット「ガジェツイ！」(英語名GadgeTweetr)をリリースしました。ガジェットながらに、そんじょそこらのTwitterクライアントよりもシンプルかつ高機能で使いやすいものに仕上がったと思いますのでご紹介します。

※ガジェツイ！のロゴフォントには「ついってる」を利用させて頂きました。

主な機能

• OAuthログイン機能


• タブ機能


• 返信元表示機能


• 検索機能


• マルチアカウントに対応

OAuthログイン機能

OAuthに対応していますので、IDとパスワードを直接gooホームに入力する必要はありません。「ログイン」ボタンクリックで、twitter.comドメインの画面が開くので、ユーザーは安心してログインすることができます。

タブ機能

タブで様々な種類のステータスを並べて表示するタイプのTwitterクライアントです。Timeline、Mentions、Direct Message、Favoritesなど、一通りの表示に対応しています。

返信元表示機能

ステータスが返信の場合は「返信元」をクリックすることで会話を辿って行くことができます。

検索機能

フリーワード検索にも対応しています。

マルチアカウントに対応

ガジェットはいくつでも追加でき、それぞれに違うアカウントを指定することができます。

その他の機能

3つのビュー

home、profile、canvasそれぞれのビューに対応しています。homeではTimelineとMentionsが、profileでは当該ユーザーのステータスが、canvasではTimeline、Mentions、Direct Message、Favoritesがそれぞれデフォルトで開きます。

自動リンク機能

外部URLはもちろん、@によるID指定、そして#によるハッシュタグの指定を検知してリンク化します。URLの場合が別ウィンドウを開きますが、@と#の場合は新しいタブを作ってステータス一覧を表示します。

ReTweet機能

気に入ったつぶやきはこのアイコンをクリックすることで、いわゆる「ReTweet」することができます。もちろん、コメントを追記することができます。

プロフィール表示機能

アイコンクリックでフォロワー数や投稿数などのプロフィール情報を表示することができます。

フォロー、アンフォロー機能

プロフィール表示からそのままフォローしたり、既にフォローしている場合はアンフォローすることができます。

まとめ

せっかくOpenSocial上に作ったTwitterクライアントということで、ならではのソーシャル機能を準備していたのですが、残念ながら今回の発表には間に合いませんでした(実装でき次第公開します)。

とはいえ、gooホームのOAuthを体験してもらうためだけに作り始めたにも関わらず、シンプルかつ高機能なものに仕上がりました。ぜひガジェツイ！をお試しください。

OpenSocial Signed Requestライブラリ(PHP)をベータ公開

OpenSocialのSigned Requestは、ガジェットからの外部通信リクエストに署名を付けることで、パラメータの内容が改ざんされていないかを検証可能にする仕組みです。一般に2-legged OAuthやSigned Request、OAuth Consumer Requestという名前はすべて同じ、これを表しています。

実装自体は全く難しくないものなのですが、お手軽なライブラリがあまり出回っていないようなので、作ってみました。まずはベータとして公開します。

特徴

Google CodeにあるOAuthのライブラリを利用しています。公開鍵はorkut、Google、Friendster、hi5、hyves、Netlog、そしてgooホームとmixiのものを同梱しています。

使い方

Google Codeからチェックアウトしてください。

svn checkout http://opensocial-signed-request-php-library.googlecode.com/svn/trunk/ opensocial-signed-request-php-library-read-only

中身はサンプルガジェット(SignedRequest.xml)とサンプルのサーバーサイド実装(example.php)、そしてライブラリです。

サンプルのサーバーサイド実装を見て頂くのが一番早いですが、使い方はシンプル。ガジェットのURLを引数にしてSignedRequestValidatorをnewし、validate_requestメソッドを呼ぶだけ。署名の検証に失敗した場合は、勝手に401を返します。署名の検証に成功した場合のコードは、その後に続けて書けばOKです。

参考

僕の知る限り、他の言語でSigned Requestを検証するコードやライブラリを公開されている方も何人かいらっしゃいます。

• Google AppEngine Python版 Django上で動作するgaeoauth
• Google AppEngine Python版で動作するコード
• Apacheモジュールレベルで動作するmod_auth_opensocial

まとめ

ベータ公開ではありますが、動作上の問題はないと思います。ただ、そのままのコードではGoogleからのリクエストもmixiからのリクエストもガジェットURLが合えば通してしまうため、任意に指定できるようにした方がいいかなど、フィードバックをもらって判断したいところと感じています。

※ちなみに、oauth_body_hashには未対応です。

というわけで、ぜひお試しください。

WP_Multilingual復活

Wordpress2.8にアップグレードしてから使えなくなっていたWP_Multilingualという多言語を実現するプラグインですが、開発者のご好意でα版を頂き、復活しました。

今の所目立った問題もなく稼働しています。

以前であれば必要だったFCKEditorも不要になったため、Wordpressのきれいなインターフェースのまま入力できるようになっていたり、言語スイッチャがウィジェット化されていたりと、単に使えるようになっただけでなく、欠点だと思っていた部分もカバーされていて非常に良いです。日本語のローカライゼーションがなかったので、早速翻訳して言語ファイルを提供しておきました。

Wordpress使いで多言語対応をご検討の方は、ぜひお試しください。

おばかアプリ選手権に出場してきました

ひょんなことから自分の作品でもないのに「おばかアプリ選手権」に狩り出されたので、せっかくだから出場してきました。場所はお台場のTOKYO CULTURE CULTUREという所。

発表したのは話題沸騰！weboo氏の「チャンネー」ガジェットです。

チャンネーはOpenSocialを使ったソーシャルアプリです。次々と表示されるチャンネー2枚の写真から好きな方を選んで行くとあなた好みの髪型が見つかる、という趣旨です。決まった髪型は取り置きすることもできます。友達のお気に入りの髪型が見れたり、お気に入りがアクティビティストリームに反映されたりする点がソーシャルアプリって感じです。

まあ、開発に当たって僕はいっさい何もしてないんですがね。

本番ではありがちなトラブル発生で、gooホームサンドボックスを使ってデモする予定が、mixiアプリを使うことになり、weboo氏が仕込んできてくれた色々なものの見せ場がなくて、ちょっと残念なことになってしまいました。

でも同じ「チームお色気」で出場したおっぱいエンジニアがpuniTouchと絶妙なトークで挽回してくれたので、結果オーライ。

非常にユニークなイベントで楽しかったです。次回は自分の作品で出場できたらいいなあ。

レポートはこちらをご覧下さい。動画もあります。

Google Developer Day 2009の動画が公開されました

先日行われたGoogle Developer Day 2009の動画が公開されてます。基調講演に一瞬と、パネルディスカッションに登壇した動画もありますので、よろしければご覧下さい。

基調講演 vol.4 OpenSocial

OpenSocial パネルディスカッション

あしあと帳ガジェット更新

昨日SocialWeb Blogで紹介して頂いたあしあとガジェットですが、早速多数のフィードバックを頂いています。その中から、2点の改善を行いましたのでご紹介します。

あしあとの表示件数を設定

[sourcecode language="javascript"]<br />{ id: 'div-1231298385220',<br /> 'view-params': {<br /> 'maxDisplay': '15'<br /> },<br /> url:'http://gadgets.agektmr.com/Footprints/friendconnect.xml',<br /> site: '00268510882932422418'<br />},<br />[/sourcecode]

あしあとは有無を言わさず10件表示する作りになっていましたが、HTMLに埋め込むコードの中に設定値を書き込むことで、変更できるようにしました。view-paramsを追加してmaxDisplayで表示したいあしあと数を指定してください。3から20の範囲で指定することができます。

スキンを設定

[sourcecode language="javascript"]<br />var skin = {};<br />skin['BORDER_COLOR'] = '#cccccc';<br />skin['ENDCAP_BG_COLOR'] = '#e0ecff';<br />skin['ENDCAP_TEXT_COLOR'] = '#000000';<br />skin['ENDCAP_LINK_COLOR'] = '#0000cc';<br />skin['ALTERNATE_BG_COLOR'] = '#ffffff';<br />skin['CONTENT_BG_COLOR'] = '#ffffff';<br />skin['CONTENT_LINK_COLOR'] = '#0000cc';<br />skin['CONTENT_TEXT_COLOR'] = '#333333';<br />skin['CONTENT_SECONDARY_LINK_COLOR'] = '#7777cc';<br />skin['CONTENT_SECONDARY_TEXT_COLOR'] = '#666666';<br />skin['CONTENT_HEADLINE_COLOR'] = '#000000';<br />[/sourcecode]

デザインの一部として色を変更できるようにしました。GFCサイトからコピーした時点で含まれているskinの値を変更することで対応できます。実際に有効な値は下記の通り：

BG_COLOR: 全体の背景色 FONT_COLOR: フォント色 CONTENT_HEADLINE_COLOR: ヘッダ文字色 ENDCAP_TEXT_COLOR: フッタ文字色 ALTERNATE_BG_COLOR: あしあと背景色

あしあとガジェットがSocialWeb Blogに掲載

ずいぶん前ですが、Google FriendConnect向けにあしあとガジェットというのを作りました。

知り合いとか、たまたまこのブログを見た人に細々と使って頂いていたのですが、先日FriendConnectのガジェットディレクトリーが出来たのを機に、せっかくだからと掲載してもらったのがコチラ。

で、その後Googleの方から「とても素晴らしいガジェットなので「お勧め(featured)」に加えるから、是非ブログ記事を書いて欲しい」(若干脚色)との依頼を頂き、書いたのがこちらのブログ

Social Web Blog: See who's visiting to your site with Footprints gadget

という訳で、掲載して頂きました。

実はこのガジェット、日本語にも対応していて、以前は動いていたのですが、GFCでSocial barが使えるようになった辺りから英語オンリーになっていたので、そのことについて聞いてみたところ、近々国際化対応する予定との返事を頂きました。なので「Footprints gadget」は「あしあとガジェット」として使えるようになるかもしれません。

Google FriendConnectの導入は割と簡単です。この記事を見た方は是非、ご自身のブログにあしあとガジェットとGoogle FriendConnectを導入してみてくださいね。

インタビュー掲載

先日Googleの及川さん、石原さんと一緒にインタビューを受けました。

OpenSocialアプリ、開発者にとっての魅力（1/2）－＠IT

gooホームの方向性やドキュメント、OpenSocialコミュニティやShindigへのコントリビュートについてなどお話しさせて頂きました :)

ぜひご一読ください。

mixiアプリのガジェットXMLを覗き見るブックマークレット

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

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

Peep mixi Appli XML

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

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

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

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

ガジェットのレンダリング速度を向上するPreload

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

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

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

1. コンテナSNSのレンダリング


2. ガジェットサーバーがガジェットをレンダリング


3. ブラウザ上でガジェットのJavaScriptが初期化


4. 外部サイトのRSSを取得するためのAjaxリクエストをガジェットサーバーに送信


5. ガジェットサーバーが外部サーバーにリクエストを送信(キャッシュがあればスキップ)


6. ガジェットサーバーはレスポンスをブラウザに戻す


7. ブラウザ上でガジェットのJavaScriptがレスポンス内容を元に記事一覧をレンダリング

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

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

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

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

Preloadは文字通り、レンダリングに先立ってロードしておいてくれる機能です。使い方は簡単で、/Module/ModulePrefs/Preload@hrefに呼び出したい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/Preload@hrefの内容に__UP_****__といった形でUserPrefsの内容を含めることができます。これは残念ながらmixiアプリでは使えない技ですね。

[sourcecode language="javascript"][/sourcecode]

Signed Requestが使える

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

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

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

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

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

まとめ

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

Google Developer Day 2009

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にご参加下さい。

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

最近「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ガジェット開発もある程度のレベルに達してきたら、この辺りの理解をしっかりやっておくことが重要だと思います。

mixiアプリが公開 / はてぶチェッカーをリリース

 ついに、ようやく、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に移籍したことだし、今後改善していってもらいますか・・・。

OpenSocial Hackathon開催します

gooホームサンドボックス立ち上げと丁度タイミングが合ったこともあり、gooとOpenSocial Japanコミュニティ、リクルートメディアテクノロジーラボ共同開催で、OpenSocial Hackathonを開催することになりました。

Hackathon(ハッカソン)とは、Hack(ハック)とMarathon(マラソン)を組み合わせた造語で、参加者をグループに分け、その場で実際にコーディングを行いながらソフトウェアを作りあげていくものです。

これまでにもGoogleを中心に数回開催されていましたが、今回はgooホームサンドボックスをコンテナにしてやってみようというものです。

---

主催： gooホーム、リクルート　メディアテクノロジーラボ、OpenSocial-Japanコミュニティ
日時： 2009年4月24日（金） 10:00〜18:00　（開場：09:30）
場所： リクルート　メディアテクノロジーラボ
人数： 35名
条件：

• OpenSocialに興味がある方


• JavaScriptでのプログラミング経験がある方


• OpenSocialガジェットの開発経験のある方
  (下記チュートリアルを行うとスムーズに理解することができます)
  http://code.google.com/intl/ja/apis/opensocial/articles/tutorial/tutorial-0.8.html


• ノートパソコンの持参が可能な方

※ 参加者の方は4月14日に事前ミーティングも行いますので、ご参加ください。
日時： 2009年4月14日（火） 18:30〜20:30　（開場：18:00）
場所： リクルート　メディアテクノロジーラボ
内容： Hackathonでのチーム分け等の手続き、アイディアの意見交換

---

参加をご希望の方は、下記2つのサイトにて登録を行ってください。

http://atnd.org/events/472

http://groups.google.com/group/opensocial-hackathon-0424
↑こちらに記載してある詳細をよくお読みください。

 

当日はOpenSocial入門を執筆されたよういちろうさん、川崎有亮さん、Googleの方、そしてもちろん僕もチューターとして参加します。

OpenSocialに興味がおありの方は、ぜひご参加ください！

 

gooホームサンドボックス公開

3月26日、gooホームでOpenSocial対応に向けたサンドボックス環境を提供開始しました。

主な機能は下記の通り：

• 基本的API(People、AppData、Activity)


• homeビュー、canvasビュー、profileビューに対応


• ユーザー属性情報ごとのプライバシー対応


• requestCreateActivity、requestPermission、requestSendMessage、requestShareApp等の口コミ機能をすべて網羅


• gooホーム絵文字フィーチャー


• opensocial-jqueryフィーチャー

日本語であることはもちろんですが、仕様のカバー率という意味では、初めてOpenSocialに触れる方にとって、既存のどのコンテナより理想的な環境と自負しております。

また、ドキュメントはかなり力を入れて書きました。パーミッション周り等はなかなかちゃんと書いてあるドキュメントがないため、参考になると思います。ぜひご一読ください。

goo Developer's Kitchenディベロッパードキュメント

 

 

サンドボックスへの登録はこちらから

goo Developer's Kitchen

Google FriendConnectについてgihyo.jpに寄稿しました

content-rewite機能で外部ファイルのキャッシュを制御する

先日のキャッシュに関する記事でPHP版Shindigではcontent-rewrite機能が使えないと書いたのですが、1.0.xの段階で、既に実装されているようです。

content-rewrite機能はOpenSocial0.9で提案された機能ではありますが、0.8や0.7でも実行できそうです。

使い方はこんな感じ。

[code lang="xml"]
<Optional feature="content-rewrite">
<Param name="expires">86400</Param>
<Param name="include-url"></Param>
<Param name="exclude-url">excluded</Param>
<Param name="exclude-url">moreexcluded</Param>
<Param name="minify-css">true</Param>
<Param name="minify-js">true</Param>
<Param name="minify-html">true</Param>
</Optional>
[/code]

• expires: キャッシュの有効期限を秒で指定。デフォルトは86400秒(24時間)。


• include-url: キャッシュしたい外部コンテンツのURLを指定。"*"アクタリスクが使える。".gif"などとすると、前後にアスタリスクがあるものと想定される。繰り返し可。


• exclude-url: キャッシュしたくない外部コンテンツのURLを指定。適用方法はinclude-urlと同じ。


• minify-css: CSSファイルの内容を圧縮してキャッシュするかどうかを"true"または"false"で指定。デフォルトは"true"


• minify-js: JSファイルの内容を圧縮してキャッシュするかどうかを"true"または"false"で指定。デフォルトは"true"


• minify-html: HTMLファイルの内容を圧縮してキャッシュするかどうかを"true"または"false"で指定。デフォルトは"true"

exclude-urlがinclude-urlよりも優先される。"*"はすべてのURLを指定。詳細な動作はコンテナ依存。

これで、開発がもう少し楽になりますね

OpenSocialパネルディスカッション

来る2月12日、13日に目黒雅叙園にてDeveloper Summit 2009が開催されます。

中でも、12日17:40からOpenSocialパネルディスカッション 2009年、OpenSocial普及元年に「これから」を大予言にご注目。

最近「OpenSocial入門」を執筆された田中洋一郎さん、リクルートの川崎有亮さん、mixiから小山浩之さん、Googleの石原直樹さん、白石俊平さん、矢野りんさんに加え、僕もパネラーとして登壇することになりました。

今年はいよいよmixiやgoo、OpenPNEなど、日本でも複数のOpenSocial環境が利用できるようになるいわば元年です。OpenSocialが今後ウェブにとってどういう役割を果たして行くのか議論する予定です。ご興味のある方はぜひ、ご参加ください。

参加の申し込みはこちらから。

OpenSocialガジェット開発で注意すべきキャッシュ機能

先日の記事でShindigが持つOpenSocialアーキテクチャの強力なキャッシュ機能について触れました。Shindigには大きく4種類のキャッシュが存在しています。

• ガジェットXMLのキャッシュ


• makeRequestでアクセスされる外部APIのキャッシュ


• featureを固めたJavaScriptのキャッシュ


• JavaScript、CSS、imgなどHTMLからリンクされたリソースのキャッシュ

ガジェットXMLのキャッシュ

OpenSocialガジェットを開発し始めて最初につまずくのがこのガジェットXMLのキャッシュでしょう。ガジェットXML上で変更を行っても、それが実際のガジェット表示上に反映されない場合は、まずガジェットXMLがキャッシュされていることを疑いましょう。

ガジェットXML上でJavaScriptコードを修正しつつサンドボックス環境で動作確認しながら開発したい場合は、URLのquery部分にnocache=1を加えることで、キャッシュが無効化されます。これで開発がだいぶ楽になるはずです。(コンテナによってはURLの末尾が途中からhash(#以降)になっている場合があるので、気をつけてください。)

なお、iGoogleのサンドボックスではMy Gadgetsでキャッシュを無効にできたり、hi5ではサンドボックスなら特に何もしなくてもキャッシュが無効だったりといった特徴もあります。

makeRequestでアクセスされる外部APIのキャッシュ

makeRequestを使って外部のリソースにGETでアクセスした場合、これもキャッシュされます。例えばRSSを取得するような場合、更新頻度の低いものであれば相手方サーバーの負荷を少しでも軽減することができます。

これを回避したい場合は、makeRequestのopt_paramsにgadgets.io.ProxyUrlRequestParamters.REFRESH_INTERVALというパラメータを追加し、0に設定してください。これで、キャッシュされなくなります。

featureを固めたJavaScriptのキャッシュ

OpenSocialでは、ガジェットXMLにRequire@featureを加えることで、様々な機能が利用できるという仕様があります。このfeatureは、ガジェット内に表示されるHTMLにJavaScriptを追加することで機能を実現していますが、Shindigではここでも軽量化/効率化を図っています。featureのJavaScriptは、レンダリング時に難読化した上で全てをひとつに繋げて、キャッシュされます。

一般ユーザー/ガジェットディベロッパーがこれを意識する必要はほぼありませんが、頭の片隅にいれておきましょう。

JavaScript、CSS、imgなどHTMLからリンクされたリソースのキャッシュ

コンテナによっては(orkut, iGoogle, hi5等、今のところJava版のShindigを使っているサービス)、ガジェットXML内で指定された外部のJavaScript、CSS、imgが、レンダリング時にキャッシュされます。レンダリングされたガジェットのHTMLを見ると、キャッシュされた外部リソースのURLのpath部分の最後にconcatが付いていることから、キャッシュされていることが分かると思います。

この機能はContent Rewriteと呼ばれるのですが、OpenSocialバージョン0.9からは正式な機能として取り込まれますが、現段階ではShindig Java版独自の機能です。0.9では、ガジェットXMLの設定でどのファイルタイプをリライトするのか、JavaScriptなら圧縮するか、キャッシュする場合の有効期限はどれくらいか、などを指定できるようになります。

さて、このキャッシュは実運用時に各ファイルの置かれているサーバーの負荷を軽くすることが目的ですが、開発時にはコードの修正が即座に反映されず、効率を下げてしまうこともあるでしょう。これを回避するには、下記をXMLに追加します。

[sourcecode language='xml']


[/sourcecode]

コンテナによってはサポートしない場合がありますので注意してください。

ところで、PHP版 Shindigの場合はこの機能がありません。つまり、もしガジェットが例えば、あなたのサーバーに用意したファイルを指しているとしたら、ガジェットのレンダリングの度にリクエストが発生するため、開発には便利な反面、本番環境で大量にアクセスが来た場合サーバーに負荷がかかってしまいます。これを回避するため、キャッシュ機能をうまく利用する、というテクニックもあります。

http://opensocial-container/gadgets/proxy?url=http://devlog.agektmr.com/image.gifのように、ドメインに"/gadgets/proxy?url="を付けて、意図的にShindigのプロキシを入れてしまいましょう。(concatと異なり、難読化や圧縮はされません。)

追記(2009/2/3)

上記に関して、コメント欄でmainyaさんから、getProxyUrlを使ったやり方を教えていただきました。

[sourcecode language='javascript']
var params = {'REFRESH_INTERVAL' : 3600*24*7};
var url = 'http://example.com/img/logo.jpg';
try{
url = gadgets.io.getProxyUrl(url, params);
}catch(e){}
[/sourcecode]

このやり方でURLを取得すれば、コンテナに依存しない方法でキャッシュを意図的に効かせた参照を行うことができるようになります。(MySpaceでは使えないのでtry/catchした方がよいそうです)

 

SocialWeb勉強会 vol.1を開催しました

1月23日に株式会社DeNAオフィスにて、SocialWeb勉強会 vol.1を開催しました。参加者は50名で、キャンセル待ちも出るほどの盛況ぶり。ソーシャルウェブの注目度の高まりを感じる勉強会となりました。

僕からのプレゼンテーションは、主催としてコミュニティの今後の方向性を示すと共に、現在の海外サービスで示されている方向性および、実際にメインプレイヤーたちがどういう形でソーシャルウェブ化に取り組んでいるかという状況を紹介しました。多くの内容は既にこのブログで紹介してきたものでしたが、いいまとめになったのではないかと思います。

スライドはSlideShareにアップしましたので、掲載しておきます。フォントが変わってしまって少々見づらい部分もあるかもしれませんが、ダウンロードもできますのでぜひご覧ください。

[slideshare id=948379&doc=socialweb-vol1-1232769487727464-3&w=425]

他にもよういちろうさんにOpenSocial導入のためのプレゼンテーション、id:ZIGOROuさんによる2009年のOpenIDの動向を紹介するプレゼンをしていただきました。詳しい内容は追ってこちらのページにアップされることと思います。ぜひチェックしてみてください。

最後に、会場を提供してくださったDeNAと、お手伝いしてくださったDeNA社員の皆様にお礼申し上げたいです。ありがとうございました。

追記：神部さんの飛び入り参加によるPaypal + OpenPNEのプレゼンについて書くのを忘れていました。僕のプレゼンの中でも触れた課金によるマネタイズにも絡む、実に興味深いお話でした。

再追記：PowerPointをPDFに変換してからSlideShareに再アップしたら、きれいに表示されるようになりました。

OpenSocial(Shindig)のサーバーアーキテクチャ

OpenSocialと関わるには

• コンテナになる


• ガジェットを開発する


• RESTを使ったクライアントサービスを作る

といった選択肢が考えられますが、そのいずれを選択するにしても、アーキテクチャについて知っておくことはとても重要です。特にガジェットを開発するに当たっては、アーキテクチャを知っていることでより開発しやすい場面が多々あります。

そこで今回は、OpenSocialに対応するコンテナのほとんどで利用されているオープンソースのリファレンス実装、Shindigのアーキテクチャについて解説したいと思います。

ガジェットとSNSの関係

iGoogle(既にShindigが利用されている)ではどうやって第三者の作ったガジェットを表示しているかご存知でしたか？実は、別ドメイン(iGoogleならgmodules.com)上にレンダリングしたガジェットを、iframe内に表示しているのです。

理由は、同ドメイン上に第三者の書いたJavaScriptを置くことは、セキュリティ上危険だからです。詳しくは以前Cajaについて解説した記事がありますので、そちらをご覧ください。

APIはどこにあるか

OpenSocialにはPeople, Group, Activity, Persistentの4つのソーシャルなAPIが用意されていますが、それぞれRESTfulによるJSON, XML, AtomPub形式と、RPCによるJSON形式が用意されています。ShindigのJavaScript APIでは、この中でもRPCによるJSON形式が使用されています。

先ほど2つのドメインについて説明しましたが、JavaScriptのAPIということはAjaxなので、当然同じドメインということで、エンドポイントはShindigのドメイン上に存在します。

ガジェット表示の流れ

基本的な構造が分かったところで、実際にガジェットを表示するまでの流れを見てみましょう。

どのガジェットを表示するのか

ガジェットを表示するためには、まずガジェットを表示したいというユーザーの意思が必要です。これはiGoogleであれば、ガジェットディレクトリから好きなガジェットを選び、自分のページを表示する、というサービス側での作業によって行われます。表示したいガジェットが分かったところで、サービス側もガジェットを表示するためのiframeを表示する必要があるため、ガジェットに関する情報を収集します。これはShindigのmetadata APIを使って行われます。

metadataの取得

metadata APIのリクエストを取得したShindigは、キャッシュを参照します。キャッシュにガジェットの情報が残っていない場合は、サービスからのリクエストに基づいてガジェットXMLを取得し、解析します。

iframeのレンダリング

ガジェットに関する情報を取得したサービスは、ガジェットを表示するためiframeをレンダリングします。これにより、iframe内にガジェットを表示するためのリクエストがブラウザからShindigに投げられます。

基本的にガジェットXMLに記述されたContentsの内容はそのまま表示されますが：

• 指定されたガジェットのfeature(tabやminimessageなど、ガジェットが持つ機能セット)のJavaScriptがHTMLに追記される。


• 設定によってはJavaScript、CSS、画像などのあらゆる外部コンテンツがShindig上にキャッシュして呼び出される。

という点は覚えておいて損はないでしょう。

これでガジェットの表示は完了です。Firebugなどを使ってAPIを試してみれば、Shindigにリクエストが飛んでいることが分かると思います。

外部サーバーを使うAPI

外部サーバーを使う際、JavaScript APIとしてgadgets.io.makeRequestが使用されます。コンテンツタイプとしてFEEDを選択すると、RSSやRDF、Atomを共通のフォーマットで返してくれたり、JSONを選択すると、データが返ってきた時点ですぐにJSONオブジェクトとして扱えるようになっています。

また、セキュリティ面でもいくつかの選択肢が用意されています。

• 通常のリクエスト


• Signed Request


• OAuth

通常のリクエストは、特に認証等のかかっていないAPIに対して行われるものです。Signed Requestとは、OAuth Consumer Requestを指しており、これを利用することで、外部サーバーはガジェットからのリクエストのみを扱うことができるようになります。OAuthはOAuth Coreを指しており、外部サーバーはガジェットからのリクエストであることだけでなく、誰からのリクエストなのかをセキュアなクレデンシャルで認証した上で扱うことができるようになります。

OAuthについてはこの辺りかこの辺りを参考にしてください。

ここで注意しなければならないのが、すべてShindigのproxyを介して行われるということです。先ほど書いた通り、ここでもGETリクエストには強力なキャッシュ機能が利用されるため、若干注意が必要な場合があります。キャッシュについては次回以降まとめて記事にしたいと思います。

Multilingualize your Wordpress blog with WP_Multilingual!

Been wanting to make this blog multilingual for a while, I just found a good plugin to do it.

WP_Multilingual is a multilangual plugin for Wordpress. It's not an auto-translator, you have to post in each languages but, those languages will be tied to the single entry and viewer's preferred language is automatically detected using request header. This was an ideal functionality I've been looking for.

Just one problem, Dean't FCKEditor doesn't seem to work quite well on japanese which you must install along with WP_Multilingual. ghh

Anyway, it looks ok just to internationalize. I'll look for solution about editor.

Footprint gadget for your FriendConnect

I developed FriendIntroducer as an experiment and was trying to understand how FriendConnect is different from ordinaly OpenSocial implementation. So this time, I've tried to develop a gadget which you can find FriendConnect interesting, Footprints. You know the idea if you've tried MyBlogLog before.

What is Footprints?

Footprints is a gadget to track visitor of you blog. Look at the gadget on bottom left. If you're not joined or signed in, do it to check what it does.



As you could imagine, this gadget records visitor and its time. When viewed by others, timestamp will be displayed how long ago, you've visited. Also, you can remove your own footprint if you want. The xml is located at:

http://devlab.agektmr.com/OpenSocial/FriendConnect/Footprints.xml

http://gadgets.agektmr.com/Footprints/friendconnect.xml

Feel free to take it and use it on your blog.

Google FriendConnect対応ガジェットが完成

FriendConnectのメンバーが友達を紹介し合う文章が書けるFriend Introducerというガジェットを公開しました。このブログの画面左側に表示していますので、メンバーになってくれている方はぜひ、遊んでみてください。(なっていない方はメンバーになって遊んでください！)

FriendIntroducerとは

主に3つのビューが存在します。1つはブログ上で表示されるprofileビュー。



FriendConnectメンバーの紹介文を最大5件表示します。ページングが可能で、それぞれのメンバーに書かれた紹介文がランダムで表示されます。

メンバーのサムネイル画像をクリックするとdetailビュー(OpenSocial的なビューではないですけどね)に切り替わります。(※誤解を招きそうなので修正。detailビューは僕が勝手にそう呼んでいるだけで、OpenSocial的にはprofileビューです。)



一人に対して複数の人が紹介文を書いている場合がありますので、detailビューでは、その人に関する紹介文をすべて閲覧することができます。

ガジェット上部のボタンをクリックするとcanvasビューに切り替わります。



canvasビューでは、ログインユーザーの友達の紹介文を書くことができます。友達がいない方は、同じFriendConnect上の誰かを友達に加えてください。

FriendIntroducerをブログに貼付けるには

まずはこちらでFriendConnectに登録してください。サイト登録済みの状態で・・・



Social gadgetsをクリックします。



一番下にあるCustom gadgetリンクをクリックします。



Gadget URLをhttp://devlab.agektmr.com/OpenSocial/FriendConnect/FriendIntroducer.xmlとしてください。

ガジェットの横幅を調整し、Generate CodeをクリックするとHTMLコードが出力されますので、これをブログ等に貼付けます。

所感

以前のエントリにも書きましたが、FriendConnectガジェット作成のミソは：

• OWNERはブログという仮想人格


• requestNavigateToでcanvasビューとprofileビューを行き来できる


• canvasビューのバックグラウンドは、サイト作成時に取り込んだcanvas.htmlをいじることで変更可能

といったところでしょうか。

今のところOpenSocialにコミュニティ的な考えはないのですが、FriendConnectはちょっとひねったコミュニティ的な応用、と思うと分かりやすいかもしれません。

また、FriendConnectの面白いところは、複数のSNSからインポートした友達リストをマージして利用できることです。例えば僕はorkut、Google、Plaxo、Twitterをインポートしていますが、同じブログに登録している人がこれらのSNS上で友達であれば、FriendConnect上でも友達になります。

いつかGoogleがiGoogleをSNS化する際、これらの友達リストがそのまま利用できるようになるかもしれませんね。