Firefoxの今日の僕が開いているタブ

我ながらびっくりした。

左から「mixi Developer Center」「DeNA Developer’s site」「GREE Developer Center」。

大きな市場になったものだ。。。

Versioned Core Gadget Features

“opensocial”や”minimessage”など、OpenSocialアプリケーション内で利用したいFeatureは、Require要素やOptional要素にて宣言します。その際に「どのバージョンのFeatureを利用したいか」といった記述方法は、今までかなり曖昧でした。明確にバージョン番号を指定できるように、Versioned Core Gadget Features仕様がOpenSocial 1.0にて追加されます。

以下、仕様の概要文です。

Gadget XMLファイルのまたは要素として使われるOpenSocial featuresは、名前の一部としてバージョン番号を伴って定義されていました(“opensocial-0.7″, “opensocial-0.8″など)。

これは、後方互換を壊すことなしに、あるバージョンから次のバージョンへ、それらを進めさせ、そしてGadgetにそれらが要求するAPIのバージョンを明確に宣言させることを可能にします。

この慣例は、OpenSocial仕様によって説明される全てのFeatureのために定義されるバージョンにおいて、および上で明確なバージョン属性として正式なものとされるべきです。

特殊なケースとして、コアなGadget仕様のフォーマットおよびレンダリング処理は、Gadgetの要求する仕様の指定バージョンにおいて、ルート要素における属性を使ってバージョニングされるべきです。

具体的には、Gadget XMLファイルの書式として以下の2点が追加となります。

  • Moduleルート要素へのspecificationVersion属性の追加
  • RequireおよびOptional要素へのversion属性の追加

例えば、以下のような記述になります。


  
    
  
  ...
  

specificationVersionおよびversion属性がそれぞれ省略された場合には、1.0が指定されたと見なされます。各属性値は、

MajorVersion.MinorVersion.PatchVersion

というように、ピリオド区切りで3つの数値を並べることができます。PatchVersionおよびMinorVersionはそれぞれ省略可能です。上記の例では、specificationVersionとしてPatchVersionが省略されています。この各項目についての考え方は、一般的なバージョニングの考え方と同じです。

この仕様に基づき、OpenSocial 1.0仕様が公開されるタイミングにおいて、gadgets名前空間に属するFeature群は、基本的に全て1.0.0となります。

「opensocialは”opensocial-0.8″といったバージョン番号があるのに、osapiはないの?」といった不明瞭な点は、この仕様に基づいて明確に定義され直すことでしょう。

OSDE 0.7.0 Candidate 1をリリースしました

OSDE 0.7.0 Candidate 1をリリースしました。このリリースでは、以下の機能追加を行っています。

  • Jettyのポート番号を変更するための設定 (Issue 104).
  • レイテンシ削減ツール – Evaluator for web performance (Issue 127).
  • レイテンシ削減ツール – JS Compiler (Issue 180).
  • iGoogle上でのガジェット管理/削除 (Issue 155).
  • HasAppフィルタのサポートと、アプリケーションの情報や管理をするっためのApplicationビューの提供 (Issue 106).
  • いくつかのバグフィックス

以下の候補版向けのアップデートサイトを使って、このバージョンをインストールすることができます。
http://opensocial-development-environment.googlecode.com/svn/update-site-candidate/site.xml

バージョン0.7.0から、フィーチャーやプラグインの名前が「com.googlecode.osde」に変更されています。もし0.5.0やそれよりも古いバージョンを使用している場合は、自動で0.7.0にアップデートすることはできません。古いバージョンをアンインストールしてから、0.7.0 Candidate 1をインストールしてください。

このバージョンをテストしていただき、何か問題があれば気軽にフィードバックをください。

後編も公開されました

「2010年のソーシャルWeb」後編も公開されました。

2010年のソーシャルWeb (後編)
http://gihyo.jp/dev/column/newyear/2010/socialweb-prospect-02

広告といくつかの標準仕様に言及しています。

2010年のソーシャルWeb

あけまして、おめでとうございます!2010年も、よろしくお願いいたします!

というわけで、今年のソーシャルWebがどうなっていくのか、昨年末に考えてみました。gihyo.jpに掲載されていますので、ぜひお読みください。

2010年のソーシャルWeb(前編)
http://gihyo.jp/dev/column/newyear/2010/socialweb-prospect-01

後編は、2日の10時頃に公開される予定です。

OSDE v0.5.0 stable1がリリースされました!

OSDE Ver. 0.5.0 Stableをリリースしました!OSDEのアップデートサイトを使って、簡単に更新をすることができます。

http://opensocial-development-environment.googlecode.com/svn/update-site/site.xml

このバージョンにより、開発しているガジェットをiGoogleにてプレビューおよび配布することが可能となります。この機能は、台北にいるAlbertと数人のメンバーによって開発されました。おめでとうと言いたいと共に、日々の助けと開発作業に対して感謝しています! :) もしiGoogleガジェットを開発したいときには、OSDEは内部で持つShindigサーバと、iGoogleのプロダクションサーバの両方で動作確認をすることができます。

私たちは、多くの改善や新機能の開発を続けます。もしロードマップを知りたいときは、以下のページをご覧ください。

http://code.google.com/p/opensocial-development-environment/wiki/Roadmap

ぜひ、コーディングを楽しんでください!

ライフサイクルイベント提供開始!

mixi Platformにて、待望の「ライフサイクルイベント」の提供が開始されています。

[ライフサイクルイベントについて - mixi Developer Center]
http://developer.mixi.co.jp/appli/pc/lets_enjoy_making_mixiapp/lifecycle_event

これは、例えばユーザがmixiアプリをインストールしたとき、もしくはmixiアプリをアンインストールしたときに、外部サーバにそのことを通知してくれる仕組みです。元々はHi5で独自実装された機能が、OpenSocial 0.8.1の時に標準仕様として取り込まれたものとなります。

[v0.8からライフサイクルイベントを受け取れるようになります - OpenSocial-Japan]
http://groups.google.co.jp/group/opensocial-japan/browse_thread/thread/baa5590cd35b58da/ba87c004d87508b6?lnk=gst&q=Lifecycle#ba87c004d87508b6

mixi Platformでは、event.addappおよびevent.rempveappに対応しています。これによって、開発したmixiアプリのインストールとアンインストールの状況を開発者が把握することができるようになります。つまり、

  • ユーザの利用状況の把握
  • 使わなくなったユーザに関する情報のゴミ掃除

などが実現可能となります。

これらに加えて、event.addappの際には、「誰から招待を受けてmixiアプリの利用を始めたか」という情報も受け取れるようになります。今まで多くのmixiアプリでは、招待時に選択されたユーザ一覧と招待したユーザを覚えておいて、インセンティブを与えるようなことをしていたかと思います。

しかし、実際には「誰からの招待を受けてインストールしたか」を開発者は把握することができず、例えば同時に2ユーザから同じアプリの招待を受けていた際には、どちらからの招待を受けたのか判断することができませんでした。

event.addappの際に、mixi_invite_fromパラメータが付与されていた際には、そのユーザからの招待を受けてインストールを行ったことがわかります。これにより、インセンティブを与える対象ユーザを厳密に特定することができるようになった、ということができるのです。

mixi側の負荷や外部サーバへの多量リクエスト送信をさけるために、リアルタイムに通知を行うのではなく、一定時間ごとにリクエストをまとめて通知を行うようになっています。よって、mixiアプリをインストールした瞬間にインセンティブを与えることが可能、というわけではありませんので、注意が必要です。

ライフサイクルイベントは、PC向けアプリ、モバイル向けアプリ共に通知されます。この機能をうまく使った、さらに素敵なアプリケーションが登場するのを楽しみにしています!

mixiにてClassmates APIが登場しました

先週、mixi Platformに新しいAPIが追加されました。Classmates API、同級生というソーシャルグラフをmixiアプリで扱うことを可能にするAPIです。

[Classmates API、メッセージ送信APIの提供開始について]
http://developer.mixi.co.jp/news/2009112701

Classmates APIはmixi独自のAPIとなりますので、mixiアプリでのみ使用可能です。PC向けAPI、モバイル向けAPIの両方が同時にリリースされています。モバイル向けのAPIはパートナー向けの限定情報となりますが、できることはPC向けのAPIと同じです。

今までのmixiアプリで利用可能なソーシャルグラフは、マイミクのみでした。しかし、先週リリースされたmixi同級生というサービスにより、ユーザは母校を登録し、同じ母校のユーザを見つけることができるようになりました。つまり、同級生というソーシャルグラフが新たに加わったことになります。Classmates APIは、この同級生ソーシャルグラフを扱うためのAPIです。

ただし、マイミクを扱うことを可能にするPerson & Friends APIと比べて、Classmates APIは以下の点でちょっと特殊です。

  • 学校情報を取得することはできない
  • 同級生のユーザ一覧を直接取得することはできない

例えば、ユーザが登録している学校の名前などを取得することはできず、その代わりに学校を特定するための文字列(学校トークン)の一覧がAPIを使って取得されます。mixiアプリの開発者は、ユーザが登録した学校の学校トークンを外部サーバのDBに格納します。ユーザが同じ学校を登録していれば、同じ学校トークンがAPIで得られますので、外部サーバのDBに蓄積していくことで、同級生ソーシャルグラフがDB内で育っていきます。同級生ユーザ一覧をAPIで得ることができないので、外部サーバのDBに蓄積していくことが必要となります。

あとは、そのソーシャルグラフを活用して、同級生ならではの機能を、開発するmixiアプリにてユーザに提供すれば良い、ということです。

すでにClassmates APIを使ったアプリがいくつかあります。mixi同級生サービスによる学校登録が進めば進むほど、Classmates APIの利用価値も今後あがっていきますので、素敵なmixiアプリが次々と登場するのを期待しています。

mixiアプリの開発に、ぜひチャレンジしてみてください!

LinkedInのAPI公開

ビジネス向けSNSで有名なLinkedInが、外部サイトとの連携のためのAPIを公開しています。

[LinkedIn Developer Network]
http://developer.linkedin.com/index.jspa

LinkedInといえば、OpenSocialの登場時点で賛同を表明しているSNSですので、標準仕様への意識も高いと期待してました。しかも、OpenSocial Enterpriseという点では、最近OpenSocial対応したJIRAと並んで、中心となっていくのかな、と思ってました。

SNSが扱うユーザ情報の取り扱いや表現形式は、すでにPortable Contactsがあります。OpenSocialのPerson & Friends API(RESTful Protocol)がこれに該当します。

[Portable Contacts]
http://www.portablecontacts.net/

今回LinkedInが公開したAPIの中に、ユーザ情報を取り扱うためのProfile APIがあります。また、取得したい項目をどう指定するかは、LinkedIn APIではField Selectorsというドキュメントにまとめられています。

[Profile API]
http://developer.linkedin.com/docs/DOC-1002

[Field Selectors]
http://developer.linkedin.com/docs/DOC-1014

これを見る限り、Portable Contactsとは違う仕様になっているようです。例えば、ユーザの指定方法が、”/people/{guid}/@self”が”/people/id={guid}”だったり、取得項目の指定に関しては、fieldsパラメータではなく、括弧を使った記述が求められます。URLに”(“や”)”が入るのを初めて見た気がします。

認証認可に関してはOAuthが適用されているようです。サポート範囲は、3-legged OAuthのみで、OAuthパラメータはリクエストヘッダにて指定のみ対応、というのが現状の内容です。

何でOpenSocialじゃないの?と疑問に思った人が他にもいて、LinkedInの中の人が返事をしています。

[Relationship between LinkedIn API and OpenSocial.]
http://developer.linkedin.com/message/1278

「確かにOpenSocialはLinkedInのUI上で動作するアプリケーションの構築に使用できるAPIではあるけど、Portable Contactsなどを含めたRESTful APIとかあるし、それだけじゃないんだけどなぁ」と思うんだけど、どうなんでしょうか。

OpenSocial 2周年!

2007年11月に発表されたOpenSocialですが、今日で2周年を迎えました!

OSDEは無事OpenSocial 0.9対応を遂げ、日本国内でもSNSなどでOpenSocial対応が次々登場してきています。OpenSocialは技術的なトレンドという面だけでなく、それをベースとしたOpenSocialアプリケーションを多くのユーザが利用し楽しむ、つまり実用段階にすでに入っていると言えるでしょう。
OpenSocialは1.0の仕様策定に向けて、着々と進化しています。今後も皆さん注目です!

Get Adobe Flash playerPlugin by wpburn.com wordpress themes