天使やカイザーと呼ばれて

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

我ながらびっくりした。

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

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

Posted:: 05.05.2010
Category:: OpenSocial

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はないの？」といった不明瞭な点は、この仕様に基づいて明確に定義され直すことでしょう。

Posted:: 02.19.2010
Category:: OpenSocial

足首負傷？

昨夜は雨が降っていて、そのときに行った居酒屋の入口付近はとても滑りやすい状態でした。居酒屋ではもちろん楽しんだんだけど、終電に乗らないといけなかったので、急いで駅に向かいました。

で、何が起きたのか。。。？

その入口で滑って、足首を捻った。。。すんごい痛みが走りました。

いま、僕は歩けません。左の足首は腫れています。なんてことだ。

骨だけは折れてませんように。。。

Posted:: 02.11.2010
Category:: Etc

package-info.javaをコンパイルするために

Javaにおいて、パッケージにいくつかのアノテーションを指定することができます。これをするために、パッケージ定義のみを持つpackage-info.javaファイルを作成する必要があります。例えば、以下のような感じです。

/**
 * This package includes ... classes.
 * @author Yoichiro Tanaka
 */
package jp.eisbahn.foo.bar;

このpackage-info.javaファイルは、コンパイルすることができます。しかし、上記のケースでは、このファイルは不幸にもコンパイルされないでしょう。その理由は、それが実行時に必要とはjavacコマンドが判断しないからです。それ故に、もしpackage-info.classファイルが欲しい場合は、RUNTIME値を持つ何らかのアノテーションを配置する必要があります。

/**
 * This package includes ... classes.
 * @author Yoichiro Tanaka
 */
@RuntimeAnnotation
package jp.eisbahn.foo.bar;

import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Retention;

@Retention(RetentionPolicy.RUNTIME)
@interface RuntimeAnnotation {}

同じファイルの中で、RetentionPolicyクラスのRUNTIME属性を持つアノテーションを定義できます。そのアノテーションをパッケージに追加することで、そのパッケージは実行時に必要とされることになります。その結果として、そのファイルはjavacコマンドによってコンパイルされるでしょう。

Posted:: 01.07.2010
Category:: Java

PluginやFeatureのファイルを自由に配置する

基本的に、もしアップデートサイトにPluginやFeatureのJarファイルを配置したい場合、Eclipseアップデートサイトにて定義されたルールに従う必要があります。そのルールとは、site.xmlファイルを作成し、PluginのJarファイルを「plugins」という名前のサブディレクトリに置き、そしてFeatureのJarファイルを「features」という名前のサブディレクトリに置くことです。ユーザがこのアップデートサイトにアクセスしてプラグインをインストールする際に、EclipseはこのルールによってこれらのJarファイルを見つけることができます。

しかし、もしアップデートサイトを作りたいとき、何らかの理由でこれらのサブディレクトリを作れないかもしれません。そのとき、あなたは自由にこれらのファイルを配置したいと考えるでしょう。

このケースの場合、site.xmlファイル内で<archive>タグを使用することができます。このタグの指定により、PluginのJarファイルを任意の場所に配置することができるようになります。もちろん、FeatureのJarファイルは、URLを記述することによって場所を指定できるので、任意の場所に配置することが可能です。

...

Featureが「jp.eisbahn.foo」という名前のPluginを持っているとき、Eclipseは「plugins」という名前のサブディレクトリからそのPluginを探そうとするでしょう。そのとき、PluginのJarファイルのパスは、「plugins/jp.eisbahn.foo_1.0.0.jar」となります（バージョン番号が1.0.0の例）。そして、<archive>タグを使うことで、そのパスを任意のURLに置き換えることができます。上記の例では、そのパスは「http://www.eisbahn.jp/any/foo-plugin.jar」に置き換えられています。

このテクニックは、OSDEのアップデートサイトで使用されました。そのsite.xmlファイルは以下となります。

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

Posted:: 01.04.2010
Category:: Eclipse

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をインストールしてください。

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

Posted:: 01.03.2010
Category:: OpenSocial

後編も公開されました

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

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

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

Posted:: 01.02.2010
Category:: OpenSocial

2010年のソーシャルWeb

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

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

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

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

Posted:: 01.01.2010
Category:: OpenSocial

2009を振り返って

2009年があと少しで終わります。今年を振り返ると、いろいろと動きがありました。その中でも大きなこととしては、「転職」「書籍出版」「OSDE」です。

最も大きな変化は、やはり転職です。まさか自分が某大手SNSサイト(とぼかす必要もないか)に入社するとは全く思ってなかったですが、大きなSNSのプラットフォーム化に関われて良かったなと。それはそれはいろいろとありましたが、自分でも貴重な経験をさせてもらってると思ってます。もちろん、プラットフォームは公開するだけでなく、いろんな意味でそれを維持していくことが大事であり、大変なことです。来年からが勝負です。

その転職のちょっと前の2月に、OpenSocial本の出版を無事迎えられたことも大きな出来事でした。自分の本を出せるとは、これも数年前までは思いもしなかったことです。今ではOpenSocialをベースにしたアプリケーションが日本の多くの開発者によって開発されていますが、ちょっとでもそれに貢献できたのなら嬉しいですね。

ずっとOSDEの開発は一人でやってきたけど、今年からメンバーが増えたことも大きな事件です。今では、僕よりもアクティブに開発をしてくれています。やはり自分で作ったものを評価してくれるのはとても嬉しいことです。OSDEは既に僕一人のものではなくなったので、責任感を持ってちゃんと進化させていかなければなりません。今年以上にOSDEは来年開発を進めたいと思っています。

このOSDEのメンバー追加のおかげで、英語でのコミュニケーションの機会は非常に増えました。メールはもちろん、コードレビュー、仕様調整など、OSDEのプロジェクトサイト上では英語が公用語です。そして、メンバーが10月の終わりに来日し、僕とOSDEに関する打ち合わせを実施しました。通訳はなく、英語でなんとかOSDEのロードマップ作りをこなした経験は、僕にとってすごい経験になっています。なんとかなるもんだなぁ、と。

これら以外にも、Google Developer Dayの基調講演でのプレゼンや執筆活動なども、今年の充実感の元となっています。とにかく、今年はいろいろと動きがあり、充実した楽しい内容でした。そして、いろいろな人にお世話になった年でもありました。

来年は、いろいろな施策を自分から仕掛けていき、いろいろな波を起こしていきたいですね。

では、引き続き来年もよろしくお願いいたします！