当ブログ (clmemo@aka) のはてブ獲得数が 5000 の大台に乗った。2009-02-12 現在、5007 はてブ。
で。何時、5000 はてブになったのか分かってない。
2007-02-04 に「あと 9 はてブで 5000 はてブ達成」と Twitter している。なので、ここ一週間のうちに 5000 はてブになったんだとは思う。もう少し目を皿にして、はてブ数をチェックしておけばよかった。最近は、はてブされることも少なくなっていたので、ちょっと油断した。残念。
ともあれ、5000 はてブ。これも、clmemo@aka を読んで下さる読者のおかげ。ありがとうございます。
ぼくの興味のおもむくまま、これからもブログを続けていくので、どうぞよろしく。目指すは 一万はてブ!
エントリーを書くのが遅れてしまったけれども、先週、「goo ラボ ネットの未来プロジェクト」ブロガー・ミーティングに参加して来た。
お題は「レコメンデーション」。会場は、タワー・レコード渋谷店 地下一階の「STAGE ONE」 (タワレコ渋谷には何度も行ってるけど、地下に降りるのは初めて!)。
レコメンデーションは、「おすすめ」なんて訳される。一番身近なのは、周りの人の口コミ情報。ネット界隈で有名なのは、Amazon の「おすすめの商品」。
ぼくは、てっきり「goo ラボ」が提供している「レコメンデーション機能」のお話になるんだと思ってた。でも違った。舞台に上がったのは、「goo ラボ」の代表が 2 人。「タワー・レコード渋谷店」の代表が 2 人。前者はネット側の代表。後者は実店舗側の代表。「レコメンデーション」にネットの中と外で係わっている人達を呼んで、何か面白いことは出来ないかな? なんて対談をするイベントだった。この対談を進行するのが、イベント主催者 AMN の徳力さん。
goo ラボの人のお話は、予想の範囲内。「昔は年齢・性別といったスペックで括ってマーケティングを行なっていたけれど、最近はユーザーが多様化してしまった。だから、個人々々に絞ったマーケティング (レコメンデーション) の重要度も上がってる」という主旨の話が印象的だった。
一方、タワレコの人達の話は、予想外に面白かった (まず、タワレコの中の人が登場するなんて思ってもいなかったからね)。
対談を聞いてて、機械的なレコメンデーションの仕組みは出来つつあるけれど、既存の (タワレコなんかがやってる) プロのレコメンデーションをネットと融合させる仕組みはないなぁ、と思った。
CD ショップ限定で言いうと、ぼくは HMV の店舗よりタワレコの方が好き。HMV は、ぼくの好きなクラシック CD の売り場が、どんどん小さくなってる。タワレコはまだクラシックに力を入れている。タワレコの中だと、ぼくは渋谷より新宿の方が好き。何でかな? 上手く説明できない。
あと、ネットだとタワレコより HMV の方が好き。理由は、レコメンデーション・ページへのリンクが時系列に並んでいるから。何か月に一回、HMV のレコメンデーションを眺めて、気に入ったボックスを買う。これが、ぼくの CD 購入のスタイル。タワレコのサイトは、ページがごちゃごちゃしていて、買う気が起きない。
シンボリック・リンクは、Windows で言うところのショートカット、Mac で言うところのエイリアス。ファイル「A」のシンボリック・リンク「B」を作ると、A を編集した結果が B にも反映されるし、B を編集した結果が A にも反映される。
そこで、人のシンボリック・リンクを作ってみた。
片方の人が手を挙げると、もう片方の人も同じように手を挙げる。と思ったんだけど、そうならない。
何がいけないんだらう、と悩んでいたら目が覚めた。
結論。人のシンボリック・リンクは作れない。
先日、Google Latitude がスタートした。Google Laditude は、iGoogle 用のガジェットと携帯電話からアクセスすることができる。
ところが、iGoogle Gadget でこんなエラーが出てしまうことがあるという。
The Latitude iGoogle gadget is not currently available for your location :(
訳: Latitude 用の iGoogle gadget は、現在、貴方の場所 (国) ではサポートされておりません。
このトラブルの解決策を、yukotan さんが教えてくれた。コピペになってしまうけど、一応、お知らせしませう。
以上。もしかしたら、ブラウザーの再起動が必要かもしれないとのこと。
Google Latitude という新サービスが始まった。
これは、友達の現在地を Google Maps 上に表示するサービス。もちろん、自分の現在地を友達に教えることも出来る。
対応しているデバイスは、Google Gadget と携帯電話。Google Gadget では、PC 上で友達の位場所を確認することができる。入手先は以下から。
対応している携帯電話は、下記の通り。google.com/latitude にアクセスすればいいらしい。
残念なことに、iPhone は「coming soon (もうちょっと待ってね)」とのこと。
とりあえず、Gadget 版を試してみた (ぼくが持ってる iPhone は、まだ未対応だからね)。以下、ガジェット版の使い勝手。
まず、Gmail のコンタクトから「友達」を設定する。相手が承認すると (?)、友達が地図上に現れる。
自分の現在地は、3 つの設定方法が用意されている。
更に「友達」ごとに設定も出来る。まず「友達」のアイコンをクリック。吹き出しが現れるので、その中から「view profile」をクリックする。すると、「Send an email」「Remove fried」というリンクに続いて、「Sharing options」が現れる。
都市レベルで、大まかな場所しか教えない機能があるのは嬉しいね。
「都市レベル」の場所通知機能が、日本人のニーズに合いそう。普段は「都市レベル」の場所通知にしておいて、イベントや待ち合わせの時だけ、「友達」に詳しい場所を教える、なんて使い方が出来るもの。
「現在地」と IM (メール) の組み合わせも魅力的。さういふサービスは、Google Latitude が初めてじゃないけれど、今まで見事にポシャってた。一部の地域で盛り上がっても、他の地域じゃユーザーを獲得できないことが多くて、世界へと利用範囲が広がらなかったのが原因と聞く。国境のないインターネットと、「場所」に縛られるローカル・サービスの溝を埋めることが、スタートアップのベンチャーには難しいんでせう。その点、Google は違う。というのも、多くのユーザーを持っている上で、ローカル系サービスをスタートさせるから。
デバイスの対応状況にも依ると思うけど、Google Latitude は Twitter と同じ位いインパクトのあるサービスになると思う。
Gmail のメニューに「Move to」ボタンが追加された。アナウンスが Gmail Blog になくて、何故か Official Google Enterprise Blog が詳しいといふ不思議。
見た目はスクリーン・ショットの通り。「Move to」ってボタンが「Labels」ボタンの隣に現れた。「Labels」ボタンとの違いが、よく分からない orz。
「Move to」も「Labels」もやってることは「ラベルを付ける」作業に他ならない。一応、特徴をまとめてみた。
「Move to」を付けると、ラベルを付けて、すぐにアーカイブする (「inbox」に戻る) のはいいかもしれない。でも、ぼくはラベルを付けたら「]」キーでアーカイブして次のメールを見るので、トータルの手間はかわらない。う〜ん、邪魔なだけという気もする。Greasemonkey でも書こうかな。
あ、あと「Move to」でも「Labels」でもラベルの補完入力が出来るやうになった。これは便利。
Gmail Tasks が iPhone からアクセスできるやうになった。
iPhone から使うには、以下の URL にアクセスする。ブックマークしておくと便利。ぼくはホーム画面に追加してしまった (Gmail Tasks 専用のアイコンも用意されてる!)
ちなみに Gmail Tasks は Labs の機能なので、使うためには「Settings > Labs」から「Tasks」を「Enable」にする必要がある。
どこでも持ち運ぶ iPhone と「備忘録 (ToDo)」がセットになって、こんなに便利なことはない。ぼくは Remember the Milk (オンライン ToDo サービスの雄) のユーザーだけど、Remember the Milk の iPhone アプリがなんちゃって無料アプリ (実質有料アプリ) なので、最近は利用頻度が減っていた。備忘録は「機能」よりも「いつでもどこでもアクセスできる」ってことの方が重要なんじゃないかな? と思う。
追記: 早速、Gmail Tasks が役に立った。会社にスターバックス・タンブラーを持って行こうとして忘れてばかりいたのだけど、Gmail Tasks のおかげで思い出せた。iPhone だと、思い付いた時に書き込めて、何気ない隙間時間にチェックできるのがいい。
「clmemo@aka: Repo って何だろ? -- 複数 git リポジトリーのためのツール」の続き。Repo を自分用のプロジェクトで使ってみる。言い換えると、複数の git リポジトリー管理に repo を使うお話。
Repo を使うためには、管理したい「複数の git リポジトリー」がどこにあるかを repo コマンドに教えないといけない。そのファイルが Manifest ファイルになる。簡単な Manifest ファイルを書いたので、それをサンプルに説明をしていきませう。
サンプルの Manifest を github で公開した。名前は gm-manifest.git。
ソース・コード (default.xml) は次の通り。
<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<remote name="github"
fetch="git://github.com/"
review="at-aka.blogspot.com" />
<default revision="master"
remote="github" />
<project path=".welcome"
name="ataka/gm-manifest"
remote="github">
<copyfile src="README" dest="README" />
</project>
<project path="greader-sbm"
name="ataka/greader-sbm" remote="github" />
<project path="greader-show-original"
name="ataka/greader-show-original" remote="github" />
</manifest>
ぼくが管理している 2 つの Greasemonkey スクリプトの git リポジトリーを、一括で管理する。
repo は、Manifest ファイルが git で公開されていることを前提にしている。ここで言う「公開」は、「他の人に公開している」という意味ではなくて、「bare リポジトリー」であることを指している。
作業的にはかうなる。
$ mkdir gm-manifest && cd gm-manifest # 作業用ディレクトリーを作成 $ vi default.xml # Manifest ファイルを書く $ vi README # README ファイルを書いておくと親切かもね $ git init # git 管理開始 $ git add . $ git commit -m 'first commit'
Manifest ファイルを書いて git 管理を開始したら、公開用リポジトリー (bare リポジトリー) を作る。ローカルに作ってもいいし、github なんかのリポジトリー・ホスティング・サーバーにアップしてもいい。ここでは、github にアップしてみる。
# Github で Manifest 用のプロジェクト (ここでは gm-manifest.git) を作る # 以下、Github へのアップロード作業 $ git config user.email masayuki.ataka+gravatar@gmail.com $ git remote add origin git@github.com:ataka/gm-manifest.git # アカウントは自分のアカウントを使ってね $ git push origin master
Manifest リポジトリーを公開したら、repo init で Manifest リポジトリーを指定する。
$ mkdir working-dir && cd working-dir # 作業用ディレクトリーに移動 $ repo init -u git://github.com/ataka/gm-manifest.git repo init -u git://github.com/ataka/gm-manifest.git Getting repo ... from git://android.git.kernel.org/tools/repo.git remote: Counting objects: 269, done. remote: Compressing objects: 100% (124/124), done. remote: Total 269 (delta 136), reused 262 (delta 132) Receiving objects: 100% (269/269), 153.23 KiB | 77 KiB/s, done. Resolving deltas: 100% (136/136), done. From git://android.git.kernel.org/tools/repo * [new branch] for-gerrit2 -> origin/for-gerrit2 (略) From git://android.git.kernel.org/tools/repo * [new tag] v1.0 -> v1.0 (略) Getting manifest ... from git://github.com/ataka/gm-manifest.git remote: Counting objects: 7, done. remote: Compressing objects: 100% (7/7), done. remote: Total 7 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (7/7), done. From git://github.com/ataka/gm-manifest * [new branch] master -> origin/master Branch default set up to track remote branch refs/remotes/origin/master. Switched to a new branch "default" Your Name [ataka]: Your Email [masayuki.ataka@gmail.com]: repo initialized in /home/ataka/program/2009/working-dir
repo init はまず最初に、repo コマンドの本体 (Python スクリプト) をダウンロードして、.repo/repo ディレクトリー内に格納する (repo init コマンド実行直後のログがそれ)。いきなり android.git.kernel.org にアクセスして驚くかもしれないけど、それは repo 本体を取って来ているだけなので心配しなくていい。
続いて repo init は、Manifest リポジトリーを取得し .repo/manifests ディレクトリーに保存する。また、.repo/manifests/default.xml は .repo/manifest.xml にシンボリック・リンクが張られる。
repo sync コマンドを実行すると、ダウンロードした Manifest ファイルに従って、レポジトリーの clone が始まる。
$ repo sync Initializing project ataka/gm-manifest ... remote: Counting objects: 7, done. remote: Compressing objects: 100% (7/7), done. remote: Total 7 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (7/7), done. From git://github.com/ataka/gm-manifest * [new branch] master -> github/master Initializing project ataka/greader-sbm ... remote: Counting objects: 7, done. remote: Compressing objects: 100% (6/6), done. remote: Total 7 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (7/7), done. From git://github.com/ataka/greader-sbm * [new branch] master -> github/master Initializing project ataka/greader-show-original ... remote: Counting objects: 7, done. remote: Compressing objects: 100% (6/6), done. remote: Total 7 (delta 2), reused 0 (delta 0) Unpacking objects: 100% (7/7), done. From git://github.com/ataka/greader-show-original * [new branch] master -> github/master
Repo 用の Manifest ファイルの説明は、Android のページに載っていない (ぼくが見つけていないだけかもしれないけれど ^^;)。
Manifest ファイルの唯一の資料は、.repo ディレクトリーの中にある。
せっかくなので、manifest-format.txt の中にある DTD を転載しておきませう。
<!DOCTYPE manifest [
<!ELEMENT manifest (remote*,
default?,
remove-project*,
project*,
add-remote*)>
<!ELEMENT remote (EMPTY)>
<!ATTLIST remote name ID #REQUIRED>
<!ATTLIST remote fetch CDATA #REQUIRED>
<!ATTLIST remote review CDATA #IMPLIED>
<!ATTLIST remote project-name CDATA #IMPLIED>
<!ELEMENT default (EMPTY)>
<!ATTLIST default remote IDREF #IMPLIED>
<!ATTLIST default revision CDATA #IMPLIED>
<!ELEMENT project (remote*)>
<!ATTLIST project name CDATA #REQUIRED>
<!ATTLIST project path CDATA #IMPLIED>
<!ATTLIST project remote IDREF #IMPLIED>
<!ATTLIST project revision CDATA #IMPLIED>
<!ELEMENT add-remote (EMPTY)>
<!ATTLIST add-remote to-project ID #REQUIRED>
<!ATTLIST add-remote name ID #REQUIRED>
<!ATTLIST add-remote fetch CDATA #REQUIRED>
<!ATTLIST add-remote review CDATA #IMPLIED>
<!ATTLIST add-remote project-name CDATA #IMPLIED>
<!ELEMENT remove-project (EMPTY)>
<!ATTLIST remove-project name CDATA #REQUIRED>
]>
default.xml (manifest.xml) の書式は次のやうになる。
<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<remote name="github"
fetch="git://github.com/" />
<default revision="master"
remote="github" />
<project path="greader-sbm"
name="ataka/greader-sbm" remote="github" />
<project path="greader-show-original"
name="ataka/greader-show-original" remote="github" />
</manifest>
まず、remote 要素で「name」と「fetch」属性を指定する。「name」で指定した名前は、後で project 要素の中でも使われるし、git リポジトリーの「remote」名としても使われる。「fetch」は、git リポジトリーの URL のうち、共通するパスを書いておく。
default 要素では、デフォールト設定を書く。後で説明する project 要素で、属性を省略した時、この default 要素で設定した値が使われる。「revision」属性は、デフォールトで使うブランチ名。普通は master でいいと思う。「remote」属性は、デフォールトで使う「remote」の名前。
project 要素は、manifest ファイルの肝。ここに、リポジトリーの設定を書く。「remote」属性には remote 要素の「name」を指定する。「name」属性は、git リポジトリーの URL (の末尾) を書く。git リポジトリーの URL は、次のような形に分離されることになる。
${remote_fetch}/${project_name}.git
project 要素の「path」属性は、リポジトリーを展開する場所を指定する。path 属性を上手く使えば、こっちのリポジトリーは lib ディレクトリーの下、あっちのリポジトリーは doc ディレクトリーの下、という風にディレクトリー構造を作れる。path 属性はオプションなので省略も OK。省略した場合は、「name」属性と同じ名前のディレクトリーがトップに出来る。
さて、ここまで書いてきて、上のサンプル manifest が、もう少しシンプルに書けることに気付いた ^^;
<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<remote name="github"
fetch="git://github.com/ataka" />
<default revision="master"
remote="github" />
<project name="greader-sbm" />
<project name="greader-show-original" />
</manifest>
うん、シンプルになった。
git push にあたるコマンド、repo upload について調べると、次のような説明がある。
Attribute `review`: Hostname of the Gerrit server where reviews are uploaded to by `repo upload`. This attribute is optional; if not specified then `repo upload` will not function.
upload 先が Gerrit (Android 専用のレビュー・サーバー) になっている。これはどういふことかしらん。う〜ん、ssh や git なサーバーに push できるのかな? ダメなのかな? こんど試してみやう。
Google が repo というツールをリリースしている。これは、Google が開発している Android プロジェクトのためのツールなのだけど、Android 専用のツールといふわけでもなさそうなので、少し調べてみた。
repo は、git を補完するツール。
repo の仕事は主に 2 つ。1 つは、「複数の git レポジトリー」を管理すること。もう 1 つは、git のレポジトリーを取って来たり、レビュー・サーバーに変更点を送ったりということ (特に複数レポレトリーをサポートしている点がミソ)。
普通、バージョン管理ソフトは、一つのリポジトリーで一つのプロジェクトを管理する。開発規模が小さなうちは、これでいい。問題は開発規模が大きくなった時。もっと言えば、複数のプロジェクトが出来るた時。
例えば、複数のアプリを別々のリポジトリーで管理している時とか、(git 管理の) オープン・ソース・プロジェクト (ex. ライブラリー) を使っている時なんかがそう。こんな時、Subversion だったら svn:externals を使う。svn:externals は、メインのリポジトリーに「外部 (external)」のリポジトリーを追加するけど、repo は違う。最初から「複数のリポジトリー」を管理できるよう設計されている。
Repo がどう動くのか、まずは Android で試してみませう
まずは、repo をインストールする。
$ curl http://android.git.kernel.org/repo >~/bin/repo $ chmod a+x ~/bin/repo
作業用のディレクトリーを作る。名前は何でもいい。
$ mkdir working-directory-name $ cd working-directory-name
最初に、repo init コマンドを実行する。
$ repo init -u git://android.git.kernel.org/platform/manifest.git
このコマンドがやることは 2 つ。
実は、repo コマンド自身は sh script で、中で python script を走らせている。で、git を操作するための「本体」部分を、init コマンド実行時にダウンロードしている。
Manifest ファイルは、repo の設定ファイル。以下の内容が書いてある。
Manifest を取得したら、repo sync コマンドを実行する。
$ repo sync
このコマンドは、初めて実行する時は git clone と同じことをする。つまり、リモート・リポジトリーを取って来る。二度目以降は、git pull と同じことをする。
初めて repo sync した直後は、ブランチが出来ていない。なので、repo start コマンドでブランチを作ってあげる。
$ repo start master --all
repo の説明では「トピック・ブランチ」という用語が使われている。これは、(開発とかコードネームとかの)「トピック」をベースにブランチ名を付けるという考え方。git の世界でも使われる。
repo start コマンドを使わずに、git-branch コマンドで各々のリポジトリーごとにブランチを作ってもかまわない。
repo を使うと、複数の git レポジトリーを扱うことが出来るやうになる。複数のリポジトリーを管理していると、clone/pull/branch まわりで混乱してくるので、その部分を肩代りするために「repo」が作られたんだと思う。
ただ、ぼくも repo を見始めたばかりなので、分からないことも多い。例えば
ここら辺は、エントリーを書きながら勉強していこうと思う (誰か教えて!)。次回は、manifest ファイルの書き方!!
goo ラボの「ネットの未来プロジェクト」ブロガー・ミーティングに参加申込をした。
概略は下記の通り。
内容は、「レコメンデーション」とのこと。レコメンデーションといへば、Amazon のおススメ商品なんかが頭に浮かぶ。実は、「goo ラボ」も「レコメンデーション」を研究しているのだとか。ニーズに合ったレコメンデーションをしてくれるのなら、大助かりなのだけど。さてさて、どんなお話しが聞けるのか。楽しみ。