Pages

2009-02-28

CEC 3300R を修理に出した

約一年前に買った CEC の CD プレーヤーの調子がおかしい。特定の CD で音飛びがしてしまう。

一、二枚なら気にしない。手持ちの CD は 3 千枚ほどあるので... そういふこともある。

でも、Karajan The Complete EMI Recordings - Opera & Vocal (72 CD) の多くで音飛びがした時はまいった。他の CD プレーヤーだと OK。CD ディスクと CD プレーヤーの相性っぽい。

それで、CEC の試聴会があった時に営業さんに聞いた所、サポート・センターに送ってくれれば対処するとのこと。まだ一年保証の範囲内なので、お願いすることにした。

元気になって戻ってくれると嬉しいな。

Denon DVD-3930

CEC CD3300R を修理に出したので、CD プレーヤーがしょぼくなった。それを見かねて、友達が CD プレーヤー (というか DVD プレーヤー) を貸してくれた。

Denon の DVD-3930。

DVDビデオプレーヤー DVD-3930-SP

CEC CD3300R に比べて、定価が倍近くするプレーヤー。流石に CEC よりきめの細やかな音が出る。

なんだけど、音楽が楽しくない ^^;。低音が強すぎる気がする。どうも、ぼくは Denon の音は苦手。。。

2009-02-24

「なぜ地球は平らなのか?」に答える NTT の nazeqa (なぜか) 検索

NTT の R&D フォーラムで、「『なぜ』に答える質問応答システム」というブースが面白かった。

R&D フォーラムでは、NTT の最新の研究を紹介している。この「なぜに答える〜」システムも、その研究開発の一つ。システム名は「nazeqa (なぜか)」。名称がこじゃれてて、いい。こういうの大好き。

NTT は最新の研究成果を、gooラボで公開している。でも、この「nazeqa」はまだサービス・インしていない。簡単にだけれども、この幻の検索システムを紹介しませう。

nazeqa

「nazeqa」は、自然言語検索の一つ。ユーザーが入力した「なぜ (Why)」の質問文に答えを返してくれる。

仕組みは簡単。

  • 「理由」を現す文章パターンを予め用意しておく。

これだけ。例えば「〜から○○」という風に書かれていたら、「○○の理由は〜」なのだろう、といったパターンを用意しておく。そして、パターンにそって文章をインデックス化しておく。難しいのは、このパターン集を人力で作るところと、ランキング付けを行なうアルゴリズムをブラッシュアップさせることでせう。後者に関しても、色んな質問をしては、検索結果を確認し、アルゴリズムの修正をかけているとのこと。

デモでは、ニュースのテキストを大量に読み込ませて、インデックスを作成していた。「質問」は、NTT 側が予め用意したものが用意されていた。例えば、「蛍はなぜ光るの?」とか、そんなの。回答は、ちゃんと答えているものもあれば (大体、上位 3 つに正解が出ていた)、「なぜ (How)」の答えを返しているものもあった。これは、日本語が「なぜ」を「Why」の質問と「How」の質問の両方で使っちゃう、って問題もあるんだと思う。逆を返せば、「Why」だけじゃなくて「How」も検索するシステムが、ちょっとした応用で出来てしまいそう。

さて、nazeqa のデモでは、自然言語での検索ボックスも用意されていた。NTT の用意している質問は信用ができないので (失礼!)、自分で質問を考えてみた。それも、一寸いじわるなやつを。

Q: なぜ地球は平らなのか?

嘘を聞いてみた。「何故」の検索で困るのは、答えにならない答えを返されることだからね。

答えが出ないとか、間違った答えが出てくることを期待してた。

A: 生活実感としては、地球は平らであるから、古代の人々が「大地は平らだ」と信じたのは別に迷信でも何でもなく、ごく自然なことだった。

意外! まともな答えが返って来た。正直、同じ質問をされて、この答えを返せる自信がぼくにはない。

少しでも早く、nazeqa がサービス・インすることを願っちゃう :)

Git でリモート・リポジトリーのタグを削除する

自分用メモ。git でリモート・リポジトリー origin にタグを送る方法。

$ git tag TAG_NEMA
$ git push --tags origin

タグを付け間違えちゃった。NAME を NEMA とタイポ。タグを付け直す。

$ git tag -d TAG_NEMA
$ git push origin :refs/tags/TAG_NEMA

まず、ローカルのタグを削除。その後、リモート・リポジトリーのタグを「空」のタグで上書きする形で削除してやる。あとは、新しいタグを付けてあげればいい。

$ git tag TAG_NAME
$ git push --tags origin

2009-02-23

NTT R&D フォーラムに参加した

予告通り、2009-02-19 (木) に NTT R&D フォーラムに参加した。

R&D フォーラムは、NTT 関連企業の人達に NTT 内の研究開発を紹介するイベント。2 日間 (2/19,20) に渡って朝から夕方まで開催されている。CEATEC のやうに、一般の人でも入場料を払えば見られる、ってものじゃない。そこに、ブロガーとして参加しよう、といふのが今回のイベント。もちろん、今年が初めての試み。

ぼくらブロガーは、14:00 に会場集合。そして、約一時間のレクチャー (挨拶・フォーラム概要・2 つの研究紹介)。その後、自由時間。最後にレクチャー・ルームに戻って、アンケートを書いてお終い。

NTT な人達は背広・スーツ。ブロガー御一行は私服。なんか浮いて見えたのは、気のせい。。。じゃないよね ^^;

閑話休題。

展示会場は 3 会場。「サービス/ネットワークを支える基盤技術」、「未来を拓く革新技術」、そして「NGN 時代のサービス展開」。この内、ぼくは「NGN〜」の会場だけ見て回った。というのは、「NGN〜」にネットがらみの展示が多かったから。前者 2 つはデバイスとかネットワークとかハードウェアとかの話っぽかったのでパス。というか、見て回る時間がなかった。

興味を持ったのは 4 つ。

  • 地理文書検索 Geo-IR。。。地名情報とテキスト検索の融合。iPhone でも見られるようにして下さい。
  • エモーショナル・サーチ。。。感情のインデックス化。映画を例に。触ってみたかったけど、時間が取れず (;_;)
  • 「なぜ」に答える質問応答システム。。。後で書く。
  • ライフログ。。。NTT も取り組んでるのね。もしかしたら、Web3.0 ってライフログなのかも。

もう少し、ゆっくり見る時間が取れたら嬉しかったな。2 時間ぽっちじゃ見て回れない。

人は意外に合理的 -- 新しい経済学で日常生活を読み解く (Tim Harford)

「人は意外に合理的」を読み終えた。副題「新しい経済学で日常生活を読み解く」。原題「The Logic of Life: Uncovering the New Economics of Everything」。作者はティム・ハーフォード (Tim Harford)。出版社はランダムハウス講談社。ページ数 368。ハードカバー。定価 1,890 円。

本書は、AMN とランダムハウス講談社がブロガー向けに「限定プレゼント」していたもので、運良く抽選に当たって手に入れた。2008-11-20 頃のこと。それから遅々と読み進めて、ようやく今日読了。3 か月もかかった。

感想を一行で書くなら、「読むのが大変だったけど、面白かった」。

人は意外に合理的 新しい経済学で日常生活を読み解く

「人は意外に合理的」は経済学の本。でも、専門書じゃあない。一見不合理に思える事柄を、「経済学」の研究がこんな風に謎解きをしてますよぉ、って噛み砕いて紹介してくれる。

読み始めると少し難しく感じるかもしれない。内容が内容なだけにね。取っつきが悪い。世の中って、シンプルを組み合わせたら複雑になっちゃいました、ってことが多い。この本は、「複雑なように見えて、実は〜」って話の進め方をするものだから、最初の敷居が高くなっちゃう。逆を言えば、最初を読み切れば後は面白く読み進められる。

個人的に面白かったのは、第 2 章「ラスベガス」。ポーカーとゲーム理論のお話 (この章で出てくるテキサス・ホールデム・ポーカーの説明は、life@aka: 007 カジノ・ロワイヤルで使われたポーカー・ゲーム「テキサス・ホールデン」をどうぞ)。ポーカーで行なう「ブラフ (はったり)」は合理的と言う。以下、ゲーム理論を作ったノイマン氏の言葉:

「ブラフする動機として考えられる要因は二つある。一つは (実際には) 弱い手を強い手であるという (見せかけの) 印象を与えることであり、もう一つは (実際には) 強い手を弱い手であるという (見せかけの) 印象を与えることである」

ゲーム理論だけ説明されると学術書になっちゃう。つまんないよね。でもプロは「ゲーム理論を知らずに」、ゲーム理論の結果に辿り着いている。そう言って、ワールドシリーズ・オブ・ポーカーの 1972 年の決勝とか、1988 年の最後の手、とかを紹介してくれる。俄然、面白くなる。

この語り口。話の進め方。それが本書の魅力。

あとがき

「経験を積むと、人は合理的な判断を下すやうになる。」

実は「離婚が増えた」のも、「CEO が給料をもらいすぎる」のも、「差別が発生する」のも、「都市に住みたがる」のも、全部「合理的」な判断があってのこと。かなり目から鱗な本だった。

2009-02-18

Git remote repository と Branch

Git のリモート・リポジトリーでブランチを操作する方法についてメモ。

リモート・リポジトリーに新しくブランチを作成する

リモート・リポジトリー foo に新ブランチ bar を作る方法。git push コマンドを使う。

$ git branch
  master
* bar
$ git push foo bar

カレント・ブランチの名前を git push に渡すと、リモート・リポジトリーに同じ名前のブランチが新しく作られる。

ブランチの名前を変えたい場合? 「ローカル・ブランチ名:リモート・ブランチ名」の書式でブランチを指定する。例えば、上の例で (bar ではなく) hoge ブランチをリモートに作る場合はかうなる。

$ git push foo bar:hoge

この「bar:hoge」の部分を refspec と呼ぶそうな。

リモート・リポジトリーのブランチを削除する

リモート・リポジトリーのブランチ bar を消してみる。これには、先程の refspec で「ローカル・ブランチ名」を空にして git-push する。

$ git push foo :bar

全部のブランチを push するのは面倒

ローカル・リポジトリーの全部のブランチをリモート・リポジトリーに送る場合、もう少し楽な手がある。

$ git push --all

--all オプションを付けると、全部のブランチがリモート側に送られる。

あとがき

リモート・リポジトリーのブランチ名をリネームするには、どうすればいいんだろ。一回消して別名で git-push するしかないのかな?

2009-02-17

chpasswd -- passwd を shell script で使うためのコマンド

昨日、passwd コマンドをバッチ処理させる方法として、expect コマンドを紹介した。

そしたら、rok さんがコメントで「chpasswd」コマンドを教えて下さった。Thanks, rok さん。

chpasswd コマンド

chpasswd コマンドは、標準入力から「ユーザー名とパスワード」の一覧を受け取って、パスワードを一括設定する。ユーザー名とパスワードは、一行ごとに「username:password」の書式で書く。

例えば、こんな風に使う。

$ cat my-passwd.txt
foo:passwd-foo
bar:passwd-bar
hoge:fuga
umi:yama
$ cat my-passwd.txt > chpasswd

ちなみに、chpasswd は DES という方式で暗号化しているらしい。一方、passwd は MD5 でパスワード化している。MD5 の方が良さそう。chpasswd も MD5 の方式で暗号化する場合は、/etc/login.defs に次の行を加える。

MD5_CRYPT_ENAB yes

rok さんによると、Debian 系のコマンドとのこと。

2009-02-16

Expect コマンドで passwd 変更

Unix でパスワード変更するには、passwd コマンドを使う。

ところが、この passwd コマンドは対話式なのでシェル・スクリプトの中に埋め込むのが難しい。Linux の管理者として、複数のユーザー・アカウントを発行したり変更する時に、これは少々まずい。100 人もの passwd 変更を対話式に入力するのは、Unix 使いのすることじゃない。

expect

この手の対話式スクリプトを shell script 的に対処するために、expect コマンドってのがある。対話文字列にマッチしたら、予め用意したコマンドを送り込んでくれる。

例えば、passwd コマンドなら、こんな対話になる。

$ sudo LANG=C passwd foobar
Enter new UNIX password:
Retype new UNIX password:

最初の「Enter」に反応してパスワードを、次の「Retype」に反応して確認用パスワードを送るには、こんなスクリプトを書く。

#!/bin/sh

user=$1
password="foo"
passwd="passwd"

expect -c "
spawn $passwd $user
expect Enter\ ;  send $password; send \r
expect Retype\ ; send $password; send \r;
expect eof exit 0
"

最後の「expect eof exit 0」ってのを忘れてて、ハマった。

コメントのアドバイスに従って、Expect コマンドで passwd 変更 (補足) というエントリーを書きました。どうぞ、補足記事も参照して下さい。

このスクリクトを例えば auto-passwd とか名前を付けたら、コマンド・プロンプトから呼ぶ。

$ for i in foo bar hogehoge...; do sudo auto-passwd $i; done

ユーザー・リストはファイルで与える方が楽でせうね。

Git で archive を作る

Git かわいいよ、Git。

Git 管理しているアプリを tar ball で公開する時のお話。普通、make distclean && make して全コンパイルが通ることを確認したら、もう一回 make distclean して tar ball 作成用のコマンドを実行するよね? それとも、export して tar に固めるかな?

Git だと、tar ball を作成するためのコマンドが用意されてる。git-archive がそれ。

$ git archive --format=tar --prefix=foo-0.1.0/ HEAD | gzip > foo-0.1.0.tar.gz

format の引数には、tar と zip が使える。デフォールトは tar とのこと。「HEAD」を指定すると、カレント・ブランチの最新版を tar してくれる。ここに TAG を指定することも可能。

アーカイブされたデータは、標準出力に吐き出されることに注意。お蔭で、gzip や bzip2 コマンドに渡せるんだけど、ZIP アーカイブする人には馴染みが薄いんじゃないかな。

$ git archive --format=zip --prefix=bar-0.1/ release-0.1 > bar-0.1.zip

git-archive は、余計なゴミ・ファイルとかを収録しないし、一発で archive できるので便利。おすすめ。

2009-02-13

gooラボ ネットの未来プロジェクト「R&Dフォーラム」ブロガーツアーに参加する

先日参加した goo ラボのブロガー・イベント第 2 弾が、2009-02-19 (木) に開かれる。題して「NTT R&D フォーラム・ブロガー・ツアー」。

  • 日時: 2009-02-19 (木) 14:00-17:00
  • 場所: NTT 武蔵野研究開発センター
  • 費用: 無料

NTT の R&D フォーラムに、ブロガーが招かれるのは初めてとのこと。NTT は、ハードウェアからネットまで巾広く研究しているはずだから、ぼくがどれ程理解できるか (というか興味を持てるか) 分からない。楽しみな反面、少し不安。ドキドキ。

ref

ViV laboratory「evanui signature」試聴会に参加する

2/14,15 に、ViV laboratory のスピーカー「evanui signature」の試聴会が開かれる。

2/15 (日) の予約が取れたので、行ってこようと思う。

  • 日時: 2009-02-15 (日) 15:00-17:00
  • 場所: カンタービレ (東京都町田市南成瀬 7-15-7 ザ・ガーデンハウス 105)
  • 費用: 無料

実を言うと、2009-02-11 (水) に下見がてら会場のカンタービレに顔を出した。

試聴会に使われる「evanui signatue」は、既にお店に入っていて、音を出していたので聴かせてもらった。写真を見ても分かる通り、かなりいびつな形をしている。スピーカー・ユニットは 8 cm のフルレンジ・ユニット 1 つだけ。8 cm のスピーカー・ユニットというと、スピーカーの中ではかなり小さい。これで低音が出るのかしらん? と思っていたら、随分しっかりした低音が出ていた。音の感じは、Quad の ESL スピーカーに近い。スピードが早くてキビキビ。むしろ、ESL にはない力強さがあった。

その時のシステムは、SOULNOTE の sc1.0 (トランスポート) と dc1.0 (DAC)、ma1.0 (プリメイン・アンプ) という構成。ベートーヴェンの交響曲はオーケストラの迫力が出ていた。アイネ・クライネ・ナハトムジークは、弦の響きがとても良かった。ショパンの練習曲は、低音の鳴りっぷりこそ (ぼくの持ってる) Bosendorfer と比べて不満に思ってしまったけど、タッチの感触が見える感じで良かった。去年のインターナショナル・オーディオ・ショーでほんの少し聞いた GIYA G1 (600 万位いのスピーカー?) に近い感じがした。

2/11 の訪問は、全くの思い付きで、自分の試聴用 CD を持たずにお店に行ってしまった。日曜日は、少し気合いを入れて試聴会に望みたい。

あ、ちなみに「evanui signature」のお値段は、ペアで 420 万円とのこと。

2009-02-12

5000 はてブ

当ブログ (clmemo@aka) のはてブ獲得数が 5000 の大台に乗った。2009-02-12 現在、5007 はてブ。

で。何時、5000 はてブになったのか分かってない。

2007-02-04 に「あと 9 はてブで 5000 はてブ達成」と Twitter している。なので、ここ一週間のうちに 5000 はてブになったんだとは思う。もう少し目を皿にして、はてブ数をチェックしておけばよかった。最近は、はてブされることも少なくなっていたので、ちょっと油断した。残念。

ともあれ、5000 はてブ。これも、clmemo@aka を読んで下さる読者のおかげ。ありがとうございます。

ぼくの興味のおもむくまま、これからもブログを続けていくので、どうぞよろしく。目指すは 一万はてブ!

「goo ラボ ネットの未来プロジェクト」ブロガー・ミーティングに参加した

エントリーを書くのが遅れてしまったけれども、先週、「goo ラボ ネットの未来プロジェクト」ブロガー・ミーティングに参加して来た。

お題は「レコメンデーション」。会場は、タワー・レコード渋谷店 地下一階の「STAGE ONE」 (タワレコ渋谷には何度も行ってるけど、地下に降りるのは初めて!)。

レコメンデーションは、「おすすめ」なんて訳される。一番身近なのは、周りの人の口コミ情報。ネット界隈で有名なのは、Amazon の「おすすめの商品」。

ぼくは、てっきり「goo ラボ」が提供している「レコメンデーション機能」のお話になるんだと思ってた。でも違った。舞台に上がったのは、「goo ラボ」の代表が 2 人。「タワー・レコード渋谷店」の代表が 2 人。前者はネット側の代表。後者は実店舗側の代表。「レコメンデーション」にネットの中と外で係わっている人達を呼んで、何か面白いことは出来ないかな? なんて対談をするイベントだった。この対談を進行するのが、イベント主催者 AMN の徳力さん。

goo ラボの人のお話は、予想の範囲内。「昔は年齢・性別といったスペックで括ってマーケティングを行なっていたけれど、最近はユーザーが多様化してしまった。だから、個人々々に絞ったマーケティング (レコメンデーション) の重要度も上がってる」という主旨の話が印象的だった。

一方、タワレコの人達の話は、予想外に面白かった (まず、タワレコの中の人が登場するなんて思ってもいなかったからね)。

  • ポップは、全部、手作り
  • ポップを付けると売れる。でも、具体的な数値はない。「ポップ無し」と「ポップ有り」を両方一緒に試せないから。感覚的には売れているんだけど...
  • 「最高傑作」という言葉は使わない (最後の切り札として、取っておく)
  • どの試聴ブースのどの CD がよく聞かれているか、常に気にかけている
  • 「良いと思われる CD を発掘するコツは?」(徳力さん)。「勘です」(タワレコの人)。

対談を聞いてて、機械的なレコメンデーションの仕組みは出来つつあるけれど、既存の (タワレコなんかがやってる) プロのレコメンデーションをネットと融合させる仕組みはないなぁ、と思った。

CD ショップ限定で言いうと、ぼくは HMV の店舗よりタワレコの方が好き。HMV は、ぼくの好きなクラシック CD の売り場が、どんどん小さくなってる。タワレコはまだクラシックに力を入れている。タワレコの中だと、ぼくは渋谷より新宿の方が好き。何でかな? 上手く説明できない。

あと、ネットだとタワレコより HMV の方が好き。理由は、レコメンデーション・ページへのリンクが時系列に並んでいるから。何か月に一回、HMV のレコメンデーションを眺めて、気に入ったボックスを買う。これが、ぼくの CD 購入のスタイル。タワレコのサイトは、ページがごちゃごちゃしていて、買う気が起きない。

2009-02-07

Symbolic Link がヘン

シンボリック・リンクは、Windows で言うところのショートカット、Mac で言うところのエイリアス。ファイル「A」のシンボリック・リンク「B」を作ると、A を編集した結果が B にも反映されるし、B を編集した結果が A にも反映される。

そこで、人のシンボリック・リンクを作ってみた。

片方の人が手を挙げると、もう片方の人も同じように手を挙げる。と思ったんだけど、そうならない。

何がいけないんだらう、と悩んでいたら目が覚めた。

結論。人のシンボリック・リンクは作れない。

Google Latitude の iGoogle ガジェットが使えない時の対策

先日、Google Latitude がスタートした。Google Laditude は、iGoogle 用のガジェットと携帯電話からアクセスすることができる。

ところが、iGoogle Gadget でこんなエラーが出てしまうことがあるという。

The Latitude iGoogle gadget is not currently available for your location :(

訳: Latitude 用の iGoogle gadget は、現在、貴方の場所 (国) ではサポートされておりません。

このトラブルの解決策を、yukotan さんが教えてくれた。コピペになってしまうけど、一応、お知らせしませう。

  1. Google にアクセス
  2. 「表示設定」をクリック
  3. 「表示言語の設定」で「英語」を選択して「保存」
  4. iGoogle にアクセスする

以上。もしかしたら、ブラウザーの再起動が必要かもしれないとのこと。

ref

2009-02-05

Google Latitude スタート

Google Latitude という新サービスが始まった。

これは、友達の現在地を Google Maps 上に表示するサービス。もちろん、自分の現在地を友達に教えることも出来る。

対応デバイス

対応しているデバイスは、Google Gadget と携帯電話。Google Gadget では、PC 上で友達の位場所を確認することができる。入手先は以下から。

対応している携帯電話は、下記の通り。google.com/latitude にアクセスすればいいらしい。

  • Android
  • Blackberry
  • S60
  • Winmo
  • iPhone (coming soon)

残念なことに、iPhone は「coming soon (もうちょっと待ってね)」とのこと。

使用感

とりあえず、Gadget 版を試してみた (ぼくが持ってる iPhone は、まだ未対応だからね)。以下、ガジェット版の使い勝手。

まず、Gmail のコンタクトから「友達」を設定する。相手が承認すると (?)、友達が地図上に現れる。

自分の現在地は、3 つの設定方法が用意されている。

  1. Detect your location (GPS 情報を Gears 経由で Google Latitude に反映させる。自動アップデート)
  2. Set your location (マニュアルで地図に現在地を設定する。虚偽申告も可能!? GPS の付いてないノート・パソコンで重宝しそう)
  3. Hide your location (隠れることも可能)

Google Latitude

更に「友達」ごとに設定も出来る。まず「友達」のアイコンをクリック。吹き出しが現れるので、その中から「view profile」をクリックする。すると、「Send an email」「Remove fried」というリンクに続いて、「Sharing options」が現れる。

  1. Share best available location (どこにいるかを詳しく表示)
  2. Share only city level location (どこの都市にいるかを表示)
  3. Hide location from this friend (この友達には、どこに居るか見せない)

都市レベルで、大まかな場所しか教えない機能があるのは嬉しいね。

あとがき

「都市レベル」の場所通知機能が、日本人のニーズに合いそう。普段は「都市レベル」の場所通知にしておいて、イベントや待ち合わせの時だけ、「友達」に詳しい場所を教える、なんて使い方が出来るもの。

「現在地」と IM (メール) の組み合わせも魅力的。さういふサービスは、Google Latitude が初めてじゃないけれど、今まで見事にポシャってた。一部の地域で盛り上がっても、他の地域じゃユーザーを獲得できないことが多くて、世界へと利用範囲が広がらなかったのが原因と聞く。国境のないインターネットと、「場所」に縛られるローカル・サービスの溝を埋めることが、スタートアップのベンチャーには難しいんでせう。その点、Google は違う。というのも、多くのユーザーを持っている上で、ローカル系サービスをスタートさせるから。

デバイスの対応状況にも依ると思うけど、Google Latitude は Twitter と同じ位いインパクトのあるサービスになると思う。

Gmail に「Move to」ボタン

Gmail のメニューに「Move to」ボタンが追加された。アナウンスが Gmail Blog になくて、何故か Official Google Enterprise Blog が詳しいといふ不思議。

Gamil - Move to

見た目はスクリーン・ショットの通り。「Move to」ってボタンが「Labels」ボタンの隣に現れた。「Labels」ボタンとの違いが、よく分からない orz。

「Move to」も「Labels」もやってることは「ラベルを付ける」作業に他ならない。一応、特徴をまとめてみた。

Move to

  • ラベルを付けたら、自動で「inbox」に戻る
  • 同時に複数のラベルを付けることは出来ない
  • 「Spam」「Trash」ラベルを付けることも出来る
  • ラベルを剥すことは出来ない
  • キーボード・ショートカットは「v」 (Move の v)

Labels

  • ラベルを付けても、自動で「inbox」に戻らない
  • チェックボックス・タイプ (複数のラベルを同時に付けられる)
  • ラベルを剥すことも出来る
  • キーボード・ショートカットは「l」 (Labels の l)

あとがき

「Move to」を付けると、ラベルを付けて、すぐにアーカイブする (「inbox」に戻る) のはいいかもしれない。でも、ぼくはラベルを付けたら「]」キーでアーカイブして次のメールを見るので、トータルの手間はかわらない。う〜ん、邪魔なだけという気もする。Greasemonkey でも書こうかな。

あ、あと「Move to」でも「Labels」でもラベルの補完入力が出来るやうになった。これは便利。

2009-02-04

Gmail Tasks for iPhone リリース

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 だと、思い付いた時に書き込めて、何気ない隙間時間にチェックできるのがいい。

Repo を使う --- Manifest ファイルの書き方

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 リポジトリーを、一括で管理する。

流れ

  1. Manifest ファイル (default.xml) を書く
  2. Manifest ファイルを git で管理する (公開リポジトリー)
  3. 作業用ディレクトリーを作成
  4. repo init (Manifest リポジトリーを git clone & repo コマンド実体をダウンロード)
  5. repo sync (各リポジトリーの git clone)

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 ディレクトリーの中にある。

  • .repo/repo/docs/manifest-format.txt

せっかくなので、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>
]>

Manifest ファイルの書式

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 できるのかな? ダメなのかな? こんど試してみやう。

2009-02-03

Repo って何だろ? -- 複数 git リポジトリーのためのツール

Google が repo というツールをリリースしている。これは、Google が開発している Android プロジェクトのためのツールなのだけど、Android 専用のツールといふわけでもなさそうなので、少し調べてみた。

Repo って何だろ?

repo は、git を補完するツール。

repo の仕事は主に 2 つ。1 つは、「複数の git レポジトリー」を管理すること。もう 1 つは、git のレポジトリーを取って来たり、レビュー・サーバーに変更点を送ったりということ (特に複数レポレトリーをサポートしている点がミソ)。

何が嬉しいの?

普通、バージョン管理ソフトは、一つのリポジトリーで一つのプロジェクトを管理する。開発規模が小さなうちは、これでいい。問題は開発規模が大きくなった時。もっと言えば、複数のプロジェクトが出来るた時。

例えば、複数のアプリを別々のリポジトリーで管理している時とか、(git 管理の) オープン・ソース・プロジェクト (ex. ライブラリー) を使っている時なんかがそう。こんな時、Subversion だったら svn:externals を使う。svn:externals は、メインのリポジトリーに「外部 (external)」のリポジトリーを追加するけど、repo は違う。最初から「複数のリポジトリー」を管理できるよう設計されている。

Repo がどう動くのか、まずは Android で試してみませう

repo のインストール

まずは、repo をインストールする。

$ curl http://android.git.kernel.org/repo >~/bin/repo
$ chmod a+x ~/bin/repo

Working Directory を使る。

作業用のディレクトリーを作る。名前は何でもいい。

$ mkdir working-directory-name
$ cd working-directory-name

準備

最初に、repo init コマンドを実行する。

$ repo init -u git://android.git.kernel.org/platform/manifest.git

このコマンドがやることは 2 つ。

  1. repo コマンドの実体 (Python スクリプト) をダウンロードする
  2. Manifest ファイルを取得する。

実は、repo コマンド自身は sh script で、中で python script を走らせている。で、git を操作するための「本体」部分を、init コマンド実行時にダウンロードしている。

Manifest ファイルは、repo の設定ファイル。以下の内容が書いてある。

  • どこの git リポジトリーから clone するか?
  • どのブランチを取って来るか?
  • 取って来たリポジトリーを、どういう風に配置するか?

Repo sync -- Git Clone in Repo

Manifest を取得したら、repo sync コマンドを実行する。

$ repo sync

このコマンドは、初めて実行する時は git clone と同じことをする。つまり、リモート・リポジトリーを取って来る。二度目以降は、git pull と同じことをする。

Repo start

初めて repo sync した直後は、ブランチが出来ていない。なので、repo start コマンドでブランチを作ってあげる。

$ repo start master --all

repo の説明では「トピック・ブランチ」という用語が使われている。これは、(開発とかコードネームとかの)「トピック」をベースにブランチ名を付けるという考え方。git の世界でも使われる。

repo start コマンドを使わずに、git-branch コマンドで各々のリポジトリーごとにブランチを作ってもかまわない。

あとがき

repo を使うと、複数の git レポジトリーを扱うことが出来るやうになる。複数のリポジトリーを管理していると、clone/pull/branch まわりで混乱してくるので、その部分を肩代りするために「repo」が作られたんだと思う。

ただ、ぼくも repo を見始めたばかりなので、分からないことも多い。例えば

  • repo sync で取得したローカル・リポジトリーを、更に git clone でコピーできない。最近試してみたら、何か普通に通った。ブランチを作ってあげる必要はあったけど。
  • repo でリモート・リポジトリーに push する方法が分からない。

ここら辺は、エントリーを書きながら勉強していこうと思う (誰か教えて!)。次回は、manifest ファイルの書き方!!

2009-02-02

「gooラボ ネットの未来プロジェクト」ブロガー・ミーティングに参加申込した

goo ラボの「ネットの未来プロジェクト」ブロガー・ミーティングに参加申込をした。

概略は下記の通り。

  • 日時: 2009-02-05 (木) 19:00-22:00
  • 会場: タワー・レコード渋谷店 B1「STAGE ONE」
  • 会費: 無料

内容は、「レコメンデーション」とのこと。レコメンデーションといへば、Amazon のおススメ商品なんかが頭に浮かぶ。実は、「goo ラボ」も「レコメンデーション」を研究しているのだとか。ニーズに合ったレコメンデーションをしてくれるのなら、大助かりなのだけど。さてさて、どんなお話しが聞けるのか。楽しみ。