秋葉に棲む

(以下、自分ソース満載というか自分の周りのことだけです、話半分に見てください)
さて、モバイルで重要なのは以下のような項目だと思います。

・通信エリア
・速度
・料金
・端末(OS、ハード面)
・電源
・アプリケーション

エリアはローミングや二代目端末などに頼る場合もありますがそこそこ問題なし、現在厳しい所(料金問題含む)も近い将来解決されそうな勢いですし、公衆無線LANという代替手段も安く普及してきています。
速度もHSDPAが普及しだして動画を楽しむにも問題がなくなってきていますし、料金は定額制が普通になりつつあります。

端末やアプリは正直微妙ですが「iPod touch」のようなものも出てきています(日本では通話できないのがアレですが、その内良いものがでてくる予感はします)
それにE-mobileの新しい端末(S11HT)もSIMロックフリーらしい(未確認情報)ということでちょっとづつですが、状況は良くなってきているのが実感できます。
それとどうやらPDAやスマートフォンでデスクトップPCやノートPCと同一のOSが動く時代も近いようだ。まあ、Windowsというのが気にかかるが、実際それが便利なのだから仕方が無い。

話題がそれるけど、E-mobileの音声端末の料金体系がパンフを見る限りでは意味不明なのです、これは公取とか入るんではなかろうか?まあ、そのうち解決するでしょう。E-mobileの音声端末のプランをようやく理解した、どうやら2つのプランがあるということらしい。それでもなんだか微妙なE-Mobileです。この先競争に負けて駄目になる可能性もありますが、どうなるにせよよいカンフル剤になっているのは間違いない気がする。もちろんちゃんと続いてほしいですよ、E-Mobileには期待しています(閑話休題)

電源はバッテリーの大容量化、端末の消費電力の削減等の努力はされてきていますが、ノートPCだとそれでも3、4時間、ネット繋いで動画を見ていれば1時間持たない感じです。
この分野では燃料電池に期待していたのですが、燃料電池に関する製品はまったくといっていいほど出てきませんね。どうなっているのでしょうか?個人的には後は電源問題だけがネックなのですが。

2007年には燃料電池が実用化される(燃料電池元年とまでいわれていたようで)、という話があったみたいです。にもかかわらず実用的な製品は出ていませんね。

2003年当たりにはノートPC用のデモ機が出ている(ITメディアの記事より)ようです、すでにそこから4,5年たっています。状況が変わっていてしかるべきですが・・・

最近の記事はと探してみて出てきたのが以下の記事でした。

燃料電池パソコンの現状は? 東芝に聞く(All Abouｔより)

これでも2007年2月の記事ですね。トピックとしては

・航空会社により制限がかかる可能性もあるが、世界的には機内持ち込みが可能になった。
・カートリッジの規格の標準化がうまくいっていない。
・小型化をどこまですればいいか、ユーザーのニーズを確認中。
　(小型化すると出力を確保するのが課題になってきますしね、まあ個人的にはバッテリーは外付けでいいんで多少大きくてもかまわないんですが)
・価格は未定。まあ、普及すれば下がるでしょう。
　(まあ、最初は高いのはしょうがないですね)
・安全性の確保は規格を定めそれに準拠するようにしている。
・使用済みカートリッジをどうするか、はっきりしていない。

といったところでしょうか。まだまだ課題は多いようです。最後の締めで「数年後の～」という言葉があります。数年後か・・・orz

一応もっと新しい記事はないかなと探してみると先月の記事がありました。
(対象が携帯などの小電力の機器のようですが)

あとはコストとソケット規格──小型・高出力化進むモバイル向け燃料電池(ITメディアより)

先の課題がどの程度解決したかは読み取れませんが、一年たってもまだ製品化の目処は立っていないようですね。もう少し高出力のものでは言わずものがなか・・・まだまだ先は長いようです。

なんだか他の技術の進歩にくらべてかなり遅い気もしますが、5年もやっていて実用化の目処が立っていないということは相当難しいのですね。劇的な「何か」がないと進まないのかもしれません。なんにしても研究者の方がんばってください。本当に期待してます。

P・S
誰かこの分野で詳しい人がいたらコメント等くれるとうれしいです。

前回はAPIの呼び出し方までを解析。今回は結果を解析してみます。(公開するの忘れてた、かなり間が開いてしまった・・・)

手っ取り早く、結果を取得してみます。これと比較しながら見ていきます。
以下のURLをアドレスバーに直接打ち込んで結果を取得。ソースを開いて保存してください。

http://socialgraph.apis.google.com/lookup?q=kevinmarks.com&fme=1&edi=1&edo=1&callback=ShowLinks

結果が横長なので適当に改行します。面倒なのでとりあえず「,」で全部改行。改行したくないところ(関係を表す部分)まで改行されますが、まずは繰り返し部分を適当に数個だけ残して削除したあと手動で戻す。
さらにAPI Documentのこのあたりを参考にしながら見やすい形に整形。結果以下のような感じになりました。括弧の対応を間違っているかもしれない・・・まあ、大目に見てください。

"canonical_mapping":{"kevinmarks.com":"http://kevinmarks.com/"},
"nodes":{
	"http://epeus.blogspot.com/":{
		"attributes":{"url":"http://epeus.blogspot.com/"},
		"claimed_nodes":[
			"http://kevinmarks.com/",
			"http://kevinmarks.myopenid.com/",
			"http://twitter.com/kevinmarks",
			"http://www.flickr.com/photos/kevinmarks/",										"http://www.google.com/reader/shared/03474483732051894197",
		http://www.google.com/s2/sharing/stuff?user\u003d109581870574956225297"
		],
		"unverified_claiming_nodes":["http://technorati.com/people/technorati/kevinmarks"],
		"nodes_referenced":{
			"http://allied.blogspot.com/":{"types":["colleague","friend"]},
			"http://bgbg.blogspot.com/":{"types":["colleague","friend","met"]},
		},
		"nodes_referenced_by":{
			"http://elroyjetson.org/":{"types":["colleague"]},
		}
	},
	"http://kevinmarks.com/":{略},
中略
	"http://www.google.com/s2/sharing/stuff?user\u003d109581870574956225297":{略}
},

わかりにくいので階層だけ示すと以下のようになります。ここに無いのは階層ごとのパラメータなので別途。
1.canonical_mapping
2.nodes
3. attributes
4. claimed_nodes
5. unverified_claiming_nodes
6. nodes_referenced
7. types
8. nodes_referenced_by
9. types

それぞれについて軽く解説。
1.調査対象
パラメータ「ｑ」に渡した値をキーとして調査したサイトのURLが入っています。
このサイトのリンク情報(rel=”me”になっているもの)やメタ情報から2の調査情報一覧の基点となるURLを取得してるようです。

2.調査情報一覧(ノード一覧)
1から取得した自分のサイトのURL情報と他サイトの関係情報一覧。複数あり、サンプルサイトだと三つあります。
実際には以下のような記述を拾っているようです(http://kevinmarks.com/のHTMLソースより抜粋)

<a href=”http://epeus.blogspot.com/” rel=”me”>Blog</a>

これがXFNというもののようです。XHTMLで使用する記述形式です。
ということはHTML4やHTML5では対応できないのでしょうか?XHTMLは正直普及しているとはいえないと思うので気になるところです。
この形式以外にもFoaFという方式の記述もあれば拾ってくれるようです。FoaFはRSSの兄弟みたいなものらしく、交友関係を記述する仕組みだそうです。こちらの方が汎用性はありそうですね。。正直リンクにいちいち記述する方式が普及するとは思えませんし。
FoaFを登録データから自動生成させる等すればSNSの仕組みを提供するWebアプリケーション(ブログパーツ?)やプラグインが容易にできるかもしれません。まあ、それだと登録データをどこにどうも持つかが問題になりそうですが。
通常のHTMLの場合はこちらを使うのかもしれません。

詳細は4以降を参照。基点となるURLがキーとなっています。

3.ノードのサイトの情報
ノードのサイトのメインのURLやプロフィーイル情報のURL、RSSのURL他最大で6つの情報。
ノードのURLのページを走査してMETA情報等から取得してると思われます。まあ、おまけ情報ですね。
友達リストを出力する際に画像等を取得するのに使う必要があるかもしれません。

4.そのノードからたどれる自分のサイト
5.4以外のそのノードからたどれるサイト

(4,5に関してはいまいち理解度が低い、また後で調査)

6.そのノードのサイトからリンクを貼っているサイト
ここからが実際の関係を表す情報です。複数あり。おそらくFoaFでも記述できる情報かと。

7.6のリンクの貼り方(実際の関係)
friend(友達)ほか多数。こちらを参照。sweetheartとかあるｗ

8.そのノードのサイトへリンクを貼っているサイト
6.の逆パターンですね。

9.8のリンクの貼り方
7と同じ。

長くなってしまった。疲れたので実際の処理を見るのは次回に回します。まあ、ここまでわかればそれなりのプログラマならあとは自由に料理できると思います。

なにか指摘や疑問あればコメントでどうぞ。