モバゲーのPC対応から思うこと

モバイル 考察

モバゲータウン、PCに進出--iPhoneにも対応 - CNET Japan
以前、周りのメンバー何人かとご飯を食べに行ったときに、モバイルの今後はどうなるかという話題になって、その中で｢モバイルが主でPCが従となる時代が来る可能性もあるのでは｣という発言がありました。
今回PC向けに公開したのは、単純にユーザの層を広げようというより、そういう方向を目指しての意味合いが強いのかもしれません。
携帯電話からの利用でPCと比べて問題となるのは、作曲したり絵を描いたりといったモノを制作することで、この欠点を補うための仕組みとして今回のPC展開が機能していけばまた違った展開が見えるのではないかと思います。
現代だと貧困にあえいでいる人でも携帯電話の利用料金だけはきっちり払っているというパターンは多いですが、だからといって携帯電話しか持っていない人ばかりではなく、大抵は年齢が高くなっていくにつれて会社なり大学なりでPCを使わざるを得なくなります。
インターネットを利用するなかの主は｢読む｣ことで、そういった用途や簡単な情報の発信には携帯電話を、専門的な仕事をするときにはPCを、という切り替えのスムーズなサービスを考えていくことが今後重要になってくるかもしれません。


デザインは携帯電話の画面イメージそのものなことについて、はてブのコメントを読むと賛否両論ありますが、開発中にPCから確認する用のページを今は流用しているのかな？
今はクローズドベータで利用できないので、利用できるユーザの使ってみての感想を聞いてみたいですね。

Mashup Award 4thの協賛企業・団体のAPIの商用利用について調べた

メモ Web API

「http://mashupaward.jp/」が開催されるそうなので、現在身内で行っている勉強会でも何か出してみたいなあと思っています。
そこで気になったのは、提供されているAPIが商用利用が可能なのかということです。
アドセンスの一つでも張ろうかとか、アフィリエイトプログラムと連携して〜みたいなことを考える人は少なくないと思います。

商用・営利目的の定義は曖昧

何をもって商用利用の範囲に含むのかというのは議論の余地があります。
アフィリエイトやアドセンスを入れることは利益を得ることを目的としているので営利目的のように思うのですが、営利目的ではないと判断しているサービスも少なくありません*1。（ex.お問い合わせ・よくある質問 | CMS プラットフォーム Movable Type）
厳密に言うと、コンテストとかに企業が応募するのは宣伝目的の意味合いも強いと思うので、営利目的といえば営利目的になるのかな？

参考


というわけで、APIの場合だと提供している側の判断によると思うのですが、後から「使っちゃ駄目！」といわれることを避けるために、商用・営利目的の利用を禁止しているものは避けておくのも一つのリスク回避手段ではないかと思います。
以下、商用利用可能なものとそうでないもの、及びよくわからなかったものについてまとめました。無償版と有償版があるものは無償版の場合の条件を採用しています。
ざっと見てまとめたものなので間違いもあると思いますので、もしお気づきになりましたらご指摘ください。
以下の情報は7月1日の時点の情報です。

商用可（6）

非商用のみ（15）

不明（12）･･･どちらとも明言されていない、もしくはその記述を見つけられなかったもの

その他（2）

感想

それぞれ、利用規約がおいてなかったり、記述が曖昧だったりで結構大変でした。
明確に「商用・営利目的の利用可能」とかかれていないものは全て不明にしたのですが、禁止事項に商用利用が含まれていなければ商用利用可になるのかな？
APIについても共通したライセンス体系ができると楽でいいのですが・・・。
この辺は、主催者側で各企業に確認を取ってもらって表にまとめてもらえるとうれしいですね。

作業中に気づいたこと

楽天は利用規約の第８条で

３．利用者は、ウェブサービスを使用して利用者ソフトウェアを制作する
にあたり、サイト上のウェブサービスを使用した部分においては、
楽天サイト以外のウェブサイトへのリンクを設置してはならないもの
とします。

楽天ウェブサービス: 楽天ウェブサービス規約 | ご利用ガイド

って書いてあるんですが、マッシュアップするのに結構致命的な気が・・・。

*1:特にアフィリエイト

WicketでURLをStringで取得する方法

Wicket

WicketではWebApplicationを継承したクラスのinitメソッドの中で、PageクラスのURLを指定します。
リンクでこのURLを使いたいときには、BookmarkableLinkのようなLink系のクラスを使えば問題ないにですが、メールの時などURLをStringで取得したいときは結構あると思います。
その場合、WebPageクラスのurlForというメソッドに取得したいページのPageクラスとパラメータを渡してやれば、BookMarkableなURLを取得することができます。

public class IndexPage extends WebPage {
    public IndexPage() {
         String url = urlFor(IndexPage.class, new PageParameters("id=0")).toString();
    }
}

このとき得られるURLは相対的なURLになるので、絶対URLを取得したい場合は以下のように行います。

RequestUtils.toAbsolutePath(url);

また、FormやPanelのようなコンポーネントで実行したい場合は、getPageメソッドでページクラスを取得してからurlForを実行します。

参考

主観が入るところがSBMの面白いところだよね。

考察

｢http://d.hatena.ne.jp/shiroann/20080627/1214495914｣を読んで、エントリの趣旨とはズレてるけど思ったこと。


｢これはひどい｣とかがつくのは比較的ニュースサイトのようなところが多いので余り意識していなかったのですが、個人のブログとかでつくと結構ショックかもしれないなあと思います。また、ネガコメだと参考にもできますが、タグだけだとどうしようもないですよね。


個人的には主観の入ったタグはなるべく入れたくないので、｢これはひどい｣はもちろん｢これはすごい｣や｢参考になる｣*1みたいなタグは使っていないのですが、人気のエントリーなどに載っている記事の内容が一目でわかるという意味ではお世話になっています。
でも、｢これはすごい｣とかついてる記事もモノによってはぜんぜんすごくない記事もあるわけで、SBMの本来の役割であるフォークソノミー的な意味では役に立ってないんですよね。


もともとWebは圧倒的多数のROMによって成り立っているのですが、記事やコメントを書くコストに比べると、制限がある分ブクマのコストは低くなりますので、SBMはそういったROMを浮上させたところがすごいところだと思っています。
制限のある手段なので、言葉から余分な要素を取り除く必要があります。そのため、感情的な言葉なら歯に絹を着せぬものになってしまいます。感情的な言葉はいくつも思いつくのですが、SBMだと性質上既存のタグの枠に当てはめる傾向があるので、ある程度画一的な表現がなされています。*2
感情的タグやコメントが集まった結果、そのブクマの集合が何か一つの意思を持っているように見えることもあります。


こういう感情的なタギングは人間にしかできないわけで、そういうところが面白いなあと思っています。機械が自動でタグ付けするような研究はいくつかあるのですが*3、主観的なタグをつけることはほぼ不可能です。この機械にできないことを、タグというシンプルな表現でたくさんの人が集まってやっているのです。
一部の人しかこういう主観的なタグは使ってないかもしれないけど、読み手の感情の集合を定量的に見ることができる手段は本や新聞のようなメディアへの反応としては存在しなかったものだと思うので、書き手としてどう受け取るべきかは思案するべきところになりそうです。

*1:ブクマしてる時点で参考になってるんじゃないのかな？

*2:そういう意味で最初ニコニコ動画のタグの付け方を見て驚いた

*3:検索エンジンもある種これに分類してもいいかも

WicketのURLをcoolにする

Wicket

WicketのデフォルトのURL

WicketでPageを作ってもデフォルトの設定だと?wicket:bookmarkablePage=%3Arpage.HomePageとか?wicket:interface=:1:1:::みたいなURLになってしまいます。
このままだと全然カッコよくないので、以前「Wicket1.3でのURLマッピング - public static void main」でURLマッピングの方法を一度取り上げました。
その中では、以下のような感じでWebApplicationでURLのマッピングをしました。

import org.apache.wicket.protocol.http.WebApplication;
public class MyApplication extends WebApplication {
	public MyApplication() {
		super();
	}
	public void init() {
		mountBookmarkablePage("/index", IndexPage.class);
	}
	@Override
	public Class getHomePage() {
		return IndexPage.class;
	}
}

しかし、このmountBookmarkablePageを使う方法では、Pageのコンストラクタに引数を持つものやエラー時などではうまくいっていません。また、全部/home/id/1/のようになってしまうのが気に入らない人もいると思います。

mountBookmarkablePageメソッドは何をやっているか？

そこで、WebApplicationのソースを見てみたところ、以下のような処理をメソッド内で行っていました。

public final void mountBookmarkablePage(final String path, final Class bookmarkablePageClass)
{
	mount(new BookmarkablePageRequestTargetUrlCodingStrategy(path, bookmarkablePageClass, null));
}

ここで使われているmountメソッドは、このメソッドの引数に取るIRequestTargetUrlCodingStrategyインターフェースを実装したクラスのインスタンスの種類によって様々なURLの形でマッピングしてくれるようです。


ということで、IRequestTargetUrlCodingStrategyを実装しているクラスを8つ紹介します。
今回使ったWicketのバージョンは1.3.3です。

1. BookmarkablePageRequestTargetUrlCodingStrategy

mountBookmarkablePageの内部で使われているクラスです。
名前のとおりブックマーク可能な普遍のURLを持つので、HTTPのGETでしかアクセスしないページに使うとよいと思います。
引数を持つ場合は、/home/id/1/のような形になります。

2. HybridUrlCodingStrategy

/home.1のようなURLで、最後の数字の部分はアクセスするたびに変化します。
この数字で、セッションの状態を制御してるのかな？

mount(new HybridUrlCodingStrategy("login", LoginPage.class));

サブミットなどでPOSTでアクセスする可能性のあるページに使うことになると思います。
上記のように、URLが変化するのでブックマークされやすいトップページなどでは使わないほうがよいです。
また、サブクラスにIndexedHybridUrlCodingStrategyというものもあり、後述するIndexedParamUrlCodingStrategyの特性を持っています。

3. IndexedParamUrlCodingStrategy

/user/1/のように、パラメータの名前を省略したURLにすることが出来ます。

mount(new IndexedParamUrlCodingStrategy("/user", UserPage.class));

PageクラスのコンストラクタにPageParametersを持たせてやると、getString("0")やgetString("1")とすることでパラメータの値を順番に取得できます。
個人的には、/user/id/1/みたいなURLはダサいと思っているので、こういう指定が出来るのは好ましいですが、順番が重要になるので、間違えないように注意が要ります。

4. MixedParamUrlCodingStrategy

IndexedParamUrlCodingStrategyと似ており、/user/1/のようなURLにすることができます。
違う点は、第三引数で指定したものだけがパラメータ名を省略する対象になるということです。

mount(new MixedParamUrlCodingStrategy("/user", UserPage.class, new String[]{"id"}));

第三引数で指定されていないものは普通のGET時のようになります。
/user/1/?page=1のような形にしたい時に利用します。
個人的にはこれが一番気に入っているのですが、上記の設定時に/user/1/hoge/でアクセスするとエラーページが出てしまう点が気になっています。

5. PackageRequestTargetUrlCodingStrategy

パッケージを指定すると、その中のPageクラスに自動でURLマッピングしてくれます。
WebApplicationのメソッドに実装されており、以下のような感じで利用が出来ます。

mount("/base", PackageName.forPackage(Package.getPackage("example")));

/base/IndexPage/id/1のようにクラス名がURLに利用されます。
毎回設定するのが面倒だったら、これを使うと楽でいいかもしれません。

6. QueryStringUrlCodingStrategy

/search/?q=wicket&page=2のように、普通のGET時のURL表示になります。
検索部分とかではこういうURL表記のほうが好まれる気がします。

7. SharedResourceRequestTargetUrlCodingStrategy

リソースにURLを割り振ってくれるクラスです。
第二引数のResourceReferenceでリソースを指定するようです。

8. URIRequestTargetUrlCodingStrategy

これ自体では何もPageを指定できないようです。
decodeメソッドをオーバーライドして受け取ったパラメータによって適当なRequestTargetを返すという使い方をするようです。
HTMLページ以外のものを返すときに使うのかな？汎用性は高そうだけど、出番はあんまりなさそう？

終わりに

今回紹介したクラスを使えばかなり柔軟なURL設計をすることができます。
個人的にJava系のフレームワークで気になる点として.doとかついたりするところがあったのですが、WicketだとかっこいいURL設計をすることができてよいですね。
また、IRequestTargetUrlCodingStrategyを自分で実装すれば独自のURLパターンを扱うこともできますので、WicketでcoolなURL設計を目指しましょう。

Twitter API制限をお知らせするAPIを作った

twitter Web API

｢[観] Twitter API 仕様書 (勝手に日本語訳シリーズ)｣を読んで、TwitterのAPI制限は1時間に70回だと思っていたのですが、後輩に｢ちゃんと公式ブログ読めよカス｣と怒られたので確認したところ、頻繁に制限は変更されていてそのアナウンスはちゃんとブログで行われていました。
でもいちいちブログに確認しに行くのは面倒くさいので、1時間に何回アクセス可能なのかを返すAPIを作りました。
http://twitter.api.limit.oshira.se/
公式ブログの情報を元に定期的に更新されるので、API制限に悩まれている方は参考にしてください。



追記：
公式APIにAPI制限数を取得するAPIがあるみたいですね。
http://twitter.com/account/rate_limit_status（.xmlか.json）
このAPI自体には利用制限のカウントをしないそうです。Twitはこれを使っているはず。
被ってしまったわけですが、まあ上記のAPIは、本家のAPIが重いよ！って人向けのミラーということでｗ

なぜHTMLの要素のclass名にredやsmallをつけてはならないか

html css メモ

なんとかspotさんで取り上げられていた記事に出てきたHTMLに

<span class="small">hogehoge</span>

という記述がありました。
以前、クラス名にredとか付けていてid:youzakaに注意されたのですが、なぜ駄目なのかということを本質的に理解していなくて今回やっと理解しました。
早い話が、redとかsmallはデザイン上の特徴であって、こんな名前を付けるとデザインと文書構造の分離ができないからです。
HTMLとしては正しいかもしれないですが、本質的には

<font color="red">hogehoge</font>

と書くこととなんら変わりありません。
赤くしたり、小さくしたりするのは何らかの意味があってするはずなので、その意味に沿った名前にするべきです。
最初はredと付けていたものを青くしようと思ったら、cssを変えるだけで変更は可能でも、HTMLはclass="red"のままになってしまい、混乱の元となります。


あと今回のsmallの場合、

<span class="small">って書くくらいならおとなしく<small>って書けばいいのに。Strict DTDにある列記とした要素なのだから。

ヨウザカオオコノハズク on Twitter: "<span class="small">って書くくらいならおとなしく<small>って書けばいいのに。Strict DTDにある列記とした要素なのだから。という話をした。"

とのことです。

参考