Pages

2008-09-27

Google Toolbar for Firefox 5 リリース

Firefox 向け Google Toolbar の最新版バージョン 5 がリリースされた。

目玉は 4 つ。

  1. Google Gadgets をサポートしたカスタム・ボタン
  2. Toolbar 設定の同期
  3. Google Notebook 機能
  4. Autofill 機能

では一つずつ見て行きませう。

Google Gadgets をサポートしたカスタム・ボタン

Google Gadgets もカスタム・ボタンとして登録できるやうになった。Google Gadgets をカスタム・ボタンとして登録すると、カスタム・ボタンにプルダウン・メニュー (用の三角のマーク) が付く。このプルダウンをクリックすると、Gadget がめでたく現れる。

Google Toolbar - Custom Button for Google News

スクーン・ショットは「News」のカスタム・ボタンの例。このニュース・カスタム・ボタンは、普通にボタンをクリックする「Google News」の検索を実行し、プルダウン・メニューを開くと「Google News」のトップページが読める仕組みになっている。つまり、カスタム・ボタンとガジェットの良いとこどりをしたカスタム・ボタン。

今の所、ガジェットをカスタム・ボタンにしても「検索」機能が使えなかったりする。例えば、Google Calendar ガジェットをカスタム・ボタンに登録しても、そのボタンを押して自分の Google Calendar の検索はできなかった。

でも、おそらく Google News のやうに、「検索」機能もガジェット機能も両方備える「ボタン」が増えることは想像にかたくない。

どんな時でも、ツールバーからアクセスできる「ガジェット」は使い勝手がいい。バージョン 5 で、一番の機能だと思う。

カスタム・ボタンの追加は以下のページからできる。

Toolbar 設定の同期

Google Toolbar の設定を、他のマシンの Firefox と同期できるやうになった。設定は Google アカウントごとに Google のサーバーに保存される。保存される設定は以下の通り:

  • デフォールトの検索エンジンを何にするか etc.
  • Google カスタム・ボタン
  • オート・フィルの設定

複数のマシンを持っている人向け。設定の同期が一発になるんでイイ。

設定を同期するには、Google Toolbar 上の緑色のアイコンをクリックする。アイコンの色と形は、こちらのヘルプを読まれたし。

Google Notebook 機能

Google Notebook Addon の機能が、事実上 Google Toolbar に吸収された。

Autofill 機能

プロフィール入力を自動で行なってくれる機能。

オート・フィル機能自体はバージョン 3 からあったと記憶しているけれど、日本語版では使えなかった。バージョン 5 になって、日本語でも使えるやうになった。

この機能を使うと、会員登録とかオンライン・ショッピングの配送先入力なんかで、自動的に必要事項を入力してくれる。ユーザーは、予め Google Toolbar にプロフィール情報を入力しておく。自動入力されるのは次の項目。

  • 名前 (姓と名)
  • メール・アドレス
  • 会社名
  • 住所
  • 電話番号
  • クレジット番号

プロフィールは複数作成可能 (Toolbar 5 の新機能!)。例えば、自宅用と会社用、英語用、ハンドル・ネーム A 用なんて風に使い分けることも可能。

日本語のプロフィール入力画面を、どれだけ正確に Google Toolbar が認識してくれるかは分からない ^^;

蛇足

あと一つ、「ウェブ履歴」の検索ボタンが追加された。

あとがき

全体的に、Google Toolbar for Fx ver.5 は使い勝手の向上部分が大きい。オススメ。

Blogger の記事ページにコメント投稿フォームを追加する

「Blogger のコメント投稿フォームを、個別エントリー内に作る方法 (いわゆる inline comment)」を説明する。

ちなみに Blogger のデフォールト設定では、コメント投稿専用のページがあって、個別エントリーからそのコメント投稿専用ページへのリンクが張られている。デフォールト設定の困ったところは、「コメント投稿ページ」へのリンクを見つけられない読者は、コメントを投稿できないこと。ひどい時は「コメントはどうやってするんですか?」というメールが送られてくるなんて都市伝説もある。

設定方法

この機能は Blogger in Draft から利用可能になる。設定方法は以下の通り。

  1. Blogger in draft にアクセス
  2. 「設定 > コメント」を開く
  3. 「プレースメントからのコメント」で「下記の投稿を埋め込みました」にチェックを入れる

以上。

設定画面の日本語がひどいのは見ない方向で。

ちなみに、英語だと「プレースメントからのコメント」は「Comment Form Placement」、「下記の投稿を埋め込みました」は「Embedded below post」。前者は「Comment Form」を「Comment From」と間違えて訳したのかしらん? ちとおそまつすぎる。ぼくだったら「コメント・フォームの設置場所」「記事/エントリーの下」と訳すかな。

メールでのコメント追跡機能

2008-09-23、メールでのコメント追跡機能が inline comment に追加された。これは、記事にコメントがあるとメールでお知らせしてくれる機能。この機能を使うとコメントの返事があった時に、メールでお知らせしてくれるので便利。古いコメント形式だと昔からあったけど、inline comment 機能では使えなくなっていた。

使い方は簡単で、コメント投稿フォームの横にある「Subscribe」というリンクをクリックするだけ。すると、以降そのエントリーにコメントが入る度にお知らせメールが飛ぶ。

あとがき

2008 年 6 月の終わり。inline comment 機能が Blogger in Draft に追加された。

インライン・コメント機能をオンにすると、メールでのコメント追跡機能が使えなくなったので、ぼくはこの機能を見送っていた。

ようやく最近、この不具合も改善されたので、clmemo@aka もインライン・コメント機能をオンにした。clmemo@aka ではインライン・コメント機能に言及してなかったので、ついでにエントリーにしてみた次第。

2008-09-26

Shibuya.lisp -- Lisp ユーザーのコミュニティ

Shibuya.lisp なる Lisp ユーザー (開発者?) 向けのコミュニティーが起ち上がった。

Lisp とその派生言語の楽しさと素晴らしさを伝えるために

Shibuya.lisp より引用

対象は Lisp をベースとした言語。すなわち、Common Lisp と Scheme。そして、Arc, Clojure, Emacs Lisp, etc...。

コミュニティー・メンバーになった

ぼくは Emacs Lisp でプログラムの道に入った。C や Ruby や JavaScript をいじりつつも、自分は (Emacs)Lisper だと思っている。

でも、生粋の Lisper とは名乗れない。名乗りたいと思って、何度も Scheme や Common Lisp に手を出した。そのたびに挫折した。教科書程度のプログラミングから先に進めていない。

気がつくと、Emacs Lisp も最近あまりいじってない。

一念発起。一つ上を目指すために、Shibuya.lisp のメンバー登録をした。

メンバー登録

Shibuya.lisp のメンバーになる方法は簡単。

こちらの Google グループに参加するだけ :p

あとがき

10/13 には、第一回のテクニカル・トークが開かれる。第一回は既に満員ということだけど、少しずつこの手のイベントにも参加して真の Lisper に近づきたい。

ref

2008-09-25

Blogger in draft の Export 機能のバグが修正された

Blogger in draft の Import/Export 機能のバグが 2 つ修正された。

  1. Import で予約投稿記事にもかかわらず、すぐに公開してしまうバグを修正した
  2. Export でコメントが欠けてしまうバグを修正した

特に Export 側のバグについては、当ブログにもコメントを寄せてもらっていて悩ましく思っていた。

うちでは何度試しても尻切れトンボ(ローカルに保存したファイルの尻の方が途中で切れてタグも閉じてない)で諦めました。

clmemo@aka: Blogger in Draft の Import/Export 機能 より引用

おそらく、このバグ修正で尻切れはなくなるんじゃないかと思う。

ちなみに、ぼくが試したところ、9/19 の時に発生していた尻切れ状態は改善されていた。9/19 の export 分は 6.3 MB で、9/25 (修正後) の export 分は 9.6 MB だった。ただ、9.6 MB となるとエディターで開いても激重。まともに export されたテキストを読めていない。ちと自信なし。

ref

Apple 超コンパクト USB 電源アダプタ交換プログラム

iPhone で使ってる USB 電源アダプターにリコールのお知らせが出た (2008-09-20 頃?)。エントリーにするのが遅れたけれど、人事じゃないのであえて書く。

不具合の詳細は、公式ページから引用しませう:

アップルでは、特定の状況下において Apple 超コンパクト USB 電源アダプタのプラグ部分(金属製の差し込み部分)が外れて電源コンセント内に残り、それによって感電の原因となる可能性があることを確認いたしました。販売済み製品のごく一部にこの問題が発生したとの報告がありましたが、それによって人体に危害がおよんだという報告は現時点では入っておりません。

Apple 超コンパクト USB 電源アダプタ交換プログラム より引用

交換は無料。対象国は、日本を含め米国、カナダ、メキシコ、中南米諸国とのこと。USB 電源アダプタは利用を控えることが推奨されている。

交換方法

交換方法は二つ用意されている。

  1. ウェブから申し込み。10/10 以降に交換品を発送。
  2. 10/10 以降に直営店へ持ち込み。

ぼくは直営店に持ち込もうと思ってる。何だかんだで、ここ一年、Apple Store には行っていないから。

2008 東京 インターナショナル・オーディオショウに行きます

2008-10-03 (金) に、有給取ってインターナショナル・オーディオショウに行って来る。

目的は、今年の冬に購入予定の CD プレーヤーの情報を手に入れること。今のところ、スウェーデンの Bladelius (代理店:ノア) やノルウェーの Hegel (代理店:エレクトリ)、日本の CEC と Soulnote に興味がある。ここら辺の情報を仕入れつつ、未知の good な CD プレーヤーと出会えることを期待。あとは純粋に色んなメーカーの音を楽しむつもり。

インターナショナル・オーディオショウは一年に一回、有楽町で開かれている。入場は無料なので、よければ皆さんも足を運んでみてはいかがでせう。

2008-09-24

Emacs で Rej ファイルを処理する人への 10 ステップ

Patch を当てたら、Reject ファイルが出来てしまった。プログラミングではよくある光景。プログラマーは、人力で Reject (拒絶された) 部分を修正する必要がある。この時の作業を楽にする Tips を、Emacs 使い向けにまとめてみた。

とりあえず、次のやうなシチュエーションを想定している。

Situation

ある日、実験用のコードを書きたくなった A 氏は、rev1 の時点のソース・コードをコピーして開発を行なった。実験コードは完成したけれど、その間にもオリジナルの開発は進んでいた。そこで A 氏は experimental コードの最新版と rev1 のコードの差分を取って開発チームに送り付けた。開発チームは送られたパッチを適用して、ほとんどの変更分は反映されたものの、いくつか競合 (Conflict) が発生した。開発チームは、Rej ファイルをもとに競合を解消する必要がある。

絵にすると、こんな感じ:

(experimental)      o--o--o
                   /       \
(original) -o--o--O--o--o---X
                (rev1)     (Conflict!)

A 氏は patch を取る際、次のコマンドを使ったとする:

$ diff -uNr rev1 experimental > a.patch

開発チームは、次のコマンドでパッチを適用した:

$ cd original
$ patch -p1 < ../a.patch

diff

Rej ファイルのサンプル

例えば下記の hello.c ファイルに

#include <stdio.h>

int main(void)
{
  printf("Hello, world\n");
  return 0;
}

次の patch をあてると...

diff -uNr rev1/hello.c experimental/hello.c
--- rev1/hello.c 2008-09-21 17:56:48.000000000 +0900
+++ experimental/hello.c 2008-09-21 17:57:20.000000000 +0900
@@ -2,6 +2,6 @@
 
 int main(void)
 {
-  printf("Hello, world");
+  printf("Hello, world and you.");
   return 0;
 }

次の Rej ファイルが出来上がる。

***************
*** 2,7 ****
  
  int main(void)
  {
-   printf("Hello, world");
    return 0;
  }
--- 2,7 ----
  
  int main(void)
  {
+   printf("Hello, world and you.");
    return 0;
  }

目次 -- Rej ファイル対処の流れ

  1. Reject ファイルのリストを作る
  2. Rej ファイルを開く
  3. Rej ファイル専用のモード
  4. Rej ファイルとローカル・ファイルのカーソル位置を同期させる
  5. 行頭の + 記号を削る
  6. Rej ファイルとローカル・ファイルの比較
  7. この変数は使われているのか? と調べてみる
  8. タグ・ジャンプ
  9. 変更の巻き戻し
  10. 3 way Merge

Reject ファイルのリストを作る

まず、Conflict (競合) が起きたファイルのリストを作る。言い換えると、Rejct ファイルのリストを作る。

ここで、find コマンドを活用する。リストの一覧は rej-list.txt といふ名前で保存しませう。

$ cd original
$ find . -name "*.rej" -print > rej-list.txt

*.rej はダブル・クォーテーションで囲むこと。

Rej ファイルを開く

rej-list.txt を開くと、次のやうに Rej ファイルの一覧が出来ている。

./doc/html/index.html.rej
./src/ui/foo.c.rej
...

開きたいファイルの上にカーソルを持っていって、次のコマンドを実行する。

M-x ffap

すると、そのファイルを開くかどうか聞いてくる。RET キーを押すと Rej ファイルが開かれる。ちなみに ffap は、find-file-at-point の略。

長ったらしいパスを入力する必要がないので、手間も省けるし間違いも減る。

rej-list.txt Tips

ぼくが、rej-list.txt を使う時の Tips を紹介しませう。

  • ファイルの先頭から、一つずつ ffap で Rej ファイルを開く。
  • 修正を後回しにするファイルは、rej-list.txt の末尾に移動させる。
  • 修正を終えたファイルは、行頭にスペースを一つ加える。
  • 全く修正を加えなかった場合は、行頭に ! を付ける。
  • 修正分が大きくて、自分の修正に自信がない場合は、行頭に @ を付けるdu

Tips 適用の結果は次のやうになる。

 ./src/foo/bar/fixed.c.rej
 ./src/foo/bar/finished.c.rej
!./src/foo/hoge/no-change.c.rej
@./src/foo/huga/big-change.c.rej
 ./src/foo/huga/done.c.rej             < ここまで修正した
./src/foo/huga/undone.c.rej
./src/unfinished/foo.c.rej
...
./src/foo/bar/later.c.rej

Rej ファイルの数が 100 を越えたりしてくると、この Tips は便利。どの Rej ファイル分まで対処したかが一目で分かる。

Rej ファイル専用のモード

Rej ファイルを開くと、Emacs は Diff-mode というモードに入る。これは、Diff ファイル (パッチ/差分とも呼ぶ) 専用のモード。Rej ファイルの実体は、差分ファイルなので、Diff-mode は Rej ファイル用のモードとも言える。

Diff モードのコマンド

Diff モードで覚えておきたいコマンドを紹介しませう。

C-c C-c
ローカル・ファイルの対応部分を開く
C-c C-s
パッチを分割 (split) する
C-c C-a
パッチを適用する
M-n
次の Reject 部分へ
M-p
前の Reject 部分へ
C-c C-u
Reject ファイルを Unified diff 形式に変換する
C-c C-d
Reject ファイルを Context diff 形式 (デフォールト) に変換する

ffap で Rej ファイルを開いたら、C-c C-c でローカル・ファイルをオープン & 概当部分へジャンプするとスムーズに作業が進められる。

C-c C-s で conflict している部分とさうでない部分を分割し、conflict していない部分に対して C-c C-a すると、作業効率が上がる。

Context と Unified

Rej ファイルは Context diff 形式で出力される。C-c C-u で Unified diff 形式にすると幸せになる。

サンプルは以下の通り。まずは Context diff の出力。

***************
*** 2,7 ****
  
  int main(void)
  {
-   printf("Hello, world");
    return 0;
  }
--- 2,7 ----
  
  int main(void)
  {
+   printf("Hello, world and you.");
    return 0;
  }

そして、こちらが Unified diff 形式。

@@ -2,6 +2,6 @@
 
 int main(void)
 {
-  printf("Hello, world");
+  printf("Hello, world and you.");
   return 0;
 }

Rej ファイルとローカル・ファイルのカーソル位置を同期させる

更に Rej ファイル内 C-c C-f とする。すると、Rej ファイルのカーソル位置とローカル・ファイルのカーソル位置が同期するやうになる。C-c C-c で概当場所にジャンプするより、こちらの方が断然楽!

C-c C-f
next-error-follow-minor-mode をトグルする

ただし、Rej ファイルの行番号があさっての方向を指していると (変更点が多すぎると、時々さういふことがある)、ちゃんとカーソル位置が同期しない。この場合は、C-c C-f で next-error-follow-minor-mode をオフにして、C-c C-c と Emacs の Search を使う方がいい。

ケース・バイ・ケースで使い分けられたし。

行頭の + 記号を削る

Rej ファイルから、コードをコピーしたとする。すると、行頭の + 記号を削らないといけない。この作業には、短形削除コマンドが有効。

短形削除コマンドとは、範囲指定の始まりと終わりを「四角形の対角線」に見たてて、その四角形部分だけ削除するコマンド。

例えば、次のやうなコードがあった場合を考えてみやう。

hogehoge
+ foo
+ bar
+ null
+ ...
hugahuga

下のスクリーン・ショットのやうに範囲を指定する (範囲指定の始まりは「foo の 0 カラム目」で、終わりは「...」の 1 カラム目)。

Emacs - rectangle region

そして、C-x r k を実行。すると、行頭の + 記号が削除される。

C-x r k
kill-rectangle (短形削除コマンド) を実行する

Rej ファイルとローカル・ファイルの比較

Rej ファイルが出来るシチュエーションの一つに、experimental での変更分を original でも既に行なっていた、というものがある。この場合、既に変更してある所に同じ変更を加えやうとして、patch コマンドは混乱し Rej ファイルを作り出す。

プログラマーは、Rej ファイルの中身と original が同じことを確認したら、何も変更を加えず Rej ファイルを閉じればいい。

問題は確認する方法。もしかしたら、1 行だけ違うかもしれない。もしかしたら、マスク一箇所分だけ違うかもしれない。もしかしたら演算子 1 個分だけ... 目で確認するのは、愚直に過ぎる。

ediff-windows-linewise を使う

こんな感じに色付してくれると、変更場所が (あるなら) 分かって嬉しい。

Emacs - ediff-windows-linewise

スクリーン・ショットでは、rsvg の行が足りないことが見て取れる。

ediff-windows-linewise の使い方
  1. ウィンドウを分割して、片方に rej ファイル、もう片方にローカル・ファイルを表示させる。
  2. お互いのウィンドウが同じ部分を表示するようにする (ex. next-error-follow-minor-mode を使って同じ部分を表示し、更に比較したい行で C-u 0 C-l, C-x o, C-u 0 C-l を実行する)
  3. C-u M-x ediff-windows-linewise を実行する

この変数は使われているのか? と調べてみる

カレント・ディレクトリー以下のファイルに対して、grep をかけたい場合、次のコマンドが便利。

M-x grep-find
カレント・ディレクトリー以下のコマンドに grep をかける

このコマンドを実行すると、ミニバッファーが次のやうになる。

Run find (like this): find . -type f -print0 | xargs -0 -e grep -nH -e 

この行末に grep にかけたいキーワードを入力して RET を押すと、検索が実行される。

やっていることは、find + xargs + grep のワンライナーを呼び出しているだけ。ユーザーは、この長くて複雑なワンライナーを覚える (打ち込む) 必要がないのがメリット。

カレント・ディレクトリーじゃなくて、一つ上のディレクトリー以下の全てのファイルを検索したい場合は、find . の部分を find ../ に変えればいい。

パッチを当ててそっくりな名前の変数や関数が現れたら、変数名や関数名が変更されたのかもと疑ってみるといい。で、本当に変更されたかどうかを調べるのに、同じ変数名・関数名を使ってるソース部分を見る手がある。grep-find は、こんな時に役に立つ。

タグ・ジャンプ

上と同じことを、タグ・ジャンプを使って検索することもできる。ここでいうタグは、検索用のインデックスのこと。デメリットはタグ作成に時間がかかる点。メリットは検索時間が早い点。

タグ・ジャンプの詳細については、過去記事をどうぞ。

変更の巻き戻し

Rej ファイルの対処をしていたら、わけが分からなくなることがある。そんな時に備えて、対処を始める前のファイルのバックアップを取っておきませう。

もしも、バージョン管理システムを使っているなら、パッチを当てた時点で一度 checkin することをオススメする。さうしておけば、次のコマンド一つで Rej ファイル対処分をキャンセルすることができる。

C-x v u
Revert (変更の巻き戻し) を行なう。RCS, CVS, Subversion といったバージョン管理システムで使える

3 way Merge

Rej ファイルも複雑になると、どこをどう直せばよいか分からなくなる。もしも (好運なことに)、オリジナルのファイル (rev1) と実験用のファイル (experimental) が手元にあるなら、3 way merge を試してみるとよいかもしれない。

おさらい。今、rev1 から派生した experimental なコードをローカルの original にマージしやうとしている。

(experimental)      o--o--o
                   /       \
(original) -o--o--O--o--o---X
                (rev1)     (Conflict!)

この場合、3 way マージは次のコマンドで行なう。

  1. M-x ediff-merge-with-ancestor
  2. 「File A to merge」の入力を促されるので「original/hello.c」と入力
  3. 「File B to merge」の入力を促されるので「experimental/hello.c」と入力
  4. 「Ancestor file」の入力を促されるので「rev1/hello.c」と入力

すると、スクリーン・ショットのやうな画面が現れる。

Emacs - ediff-merge-with-ancestor

画面は三分割されている。上段左側が A ウィンドウ。original な hello.c が表示されている。上段右側が B ウィンドウ。experimental な hello.c が表示されている。下段は、マージ用のウィンドウ。diff3 の出力結果が出力されている。

「a」キーで A ウィンドウの内容が、「b」キーで B ウィンドウの内容がマージ用ウィンドウにコピペされる。(今回の例のやうに) 両方の変更を取り込みたい場合は、直接マージ用ウィンドウの概当部分を編集する。

あとがき

理想を言えば、ちゃんとしたバージョン管理を使って、3 way merge を実行して conflict を修正する。よく分からない点は、experimental なり original のリビジョン・ログを読んで、どういう趣旨の変更かを理解してマージする。ということが出来るといい (darcs などは、かなり進んだマージが出来ると聞く)。

残念なことに、パッチだけしか存在しないとか、パッチだけしか提供されないとか、パッチだけが送り付けられた、という不幸もある。そんな場合に限って、Rej ファイルの数が 100 を越えたり、越えなかったり。

この記事が、そんな不幸と出会った人達の一助になれば嬉しい。

2008-09-19

「Wire Free Gadgets Network」ブロガーミーティングに参加申込した

AMN のブロガー・ミーティング「Wire Free Gadgets Network」に参加申込をした。

概要は以下の通り。

  • 日時: 2008-09-29 19:30-21:30
  • 場所: 汐留ビルディング
  • 定員: 30 人
  • 協賛: NTT コミュニケーションズ

NTT コミュニケーションズの「未来のサービスを考える」プロジェクト・チケームが提供している「Wire Free Gadgets Network」に関するセミナー。

「Wire Free Gadgets Network」は、様々なコンテンツを、ネットワークに自然につながったモノ同士(たとえばカメラとフォトフレーム、カメラとTVなど)で簡単に受け渡しすることを目指している新しいプラットフォームのコンセプトモデルです。 今回のブロガーミーティングでは、この「Wire Free Gadgets Network」の目指すビジョンから、その特徴や技術的な背景、そして実際にこの仕組みを 活用したアプリケーション例等を紹介頂き、皆さんと一緒にモノとネットワークが連動する未来のコミュニケーションの形や可能性について考えてみたいと思います。

9月29日(月)「Wire Free Gadgets Network」ブロガーミーティングのお知らせ|ブログ|Agile Media Network より引用

この手のセミナーに参加するのはひさしぶり。一か月ぶりじゃないかしらん。

でも、定員 30 人で応募者が多いと抽選になるとのこと。まだセミナーに行けるかどうかは分からない。最近、この手の「抽選」のからんだセミナーには落選し続けているので、今回もダメかも。運が良ければ、会場でお会いしまょう。

Blogger in Draft の Import/Export 機能

Blogger in draft に、Blogger の Export/Import 機能が追加されている (追加されたのは 6 月末)。

特徴

Export 機能の特徴は以下の通り。

  • 出力形式は Atom (XML)
  • ファイル名は blog-MM-DD-YYYY.xml。例えば今日 Export したなら blog-09-18-2008.xml になる
  • 対象は全てのエントリーと全てのコメント
  • 画像の Export はサポートしていない

面白いのは、Export された xml ファイルの中に、ブログの記事は入っていないこと。ブログの記事本文はあくまで Blogger のサーバーの中にある。xml ファイルの中には、「何月何日に○○さんが書いたエントリーをこの順番で入れなさい」という情報がズラズラと書かれている。極端な話、Export されているのは「記事本文へのリンク集」といってもよいでせう。

そんなわけで、Blogger がデータを Import するというのは、元々 Blogger サーバーの中にある本文データに目次を与えるような作業になる。二つのブログを統合するというのも、目次部分を並べ替えて結合しているだけ。記事本文は何一つ移動もコピーもしていない。大量のデータを扱う Blogger (というか Google) らしいやり方だね。

こんな仕様だから、Blogger 以外で Export したブログ・データ (例えば MovableType) を Blogger に Import するのは難しさう。

Import/Export のやり方

Blogger in draft にアクセスして、「設定」から「基本」タブをクリック。一番上に「ブログをインポート (Import blog)」「ブログをエクスポート (Export blog)」というリンクがあるので、それをクリックする。それだけ。

写真付き解説はクリボウさんのエントリーをどうぞ。

あとがき

この機能が追加された時、Export と聞いて「ブログのバックアップが簡単に取れるのねぇ」と思ってた。で、忙がしくてエントリーにもしなかった。

昨日、clmemo@aka: Blogger のバックアップを取る方法にコメントが入って、Export 機能でバックアップ取る方法もあったのにエントリーにしなくて悪いことしたな... と反省。で、記事を書くために少し調べてみたら、何とバックアップには適さない、といふことが分かった。びっくり。

もし、この事を知ってたら 6 月の時点でエントリーにしていたでせうね :p

申し訳ないです。Export されたファイルの中には、記事本文も入っておりました。当ブログの Export ファイルは 6 MB になって、これをエディターで開いたところ、カーソル移動や検索が激重になりました。そのせいで、ファイルの末尾を見ようとしているのに先頭部分だけしか表示されていなかったようです。結果、6 MB の Export ファイルの中には本文が入っていないと勘違いしてしまいました。ご指摘して下さった、Hit さん。ありがとうございます。

Gmail Labs に添付忘れチェッカー (と Mark as read ボタン)

Gmail Labs に、二つの機能が追加された。一つは添付ファイルを付け忘れた時にその旨をお知らせしてくれる機能。もう一つは「Mark as read」ボタンを表示する機能 (「Mark as read」は本来「More Actions」プルダウン・メニューの中に収納されている)。

Forgotten Attachment Detector

メール本文中に「メールを添付したよ」系のテキストがあると、添付ファイルが付いていることを確認。メール送信時に添付ファイルが付いてなければ、添付し忘れとしてユーザーに警告してくれる。

「メールを添付したよ」系のテキストは、現在英語のみに対応。更に Google Operating System によると

The attachment detector couldn't recognize patterns like "I attached a file", "Check the attached file", but it worked when using: "I've attached..." and "I have attached".

(訳) 添付し忘れチェッカーは、「I attached a file」や「Check the attached file」といったパターンはチェックしてくれない。「I've attached...」や「I have attached」ならチェックしてくれた。

Gmail's Forgotten Attachment Detector より引用

とのこと。

また、IDEA*IDEA さんは

いろいろ試してみましたが「attached」「file」という単語が両方現れたときに警告してくれるようです。

とっても恥ずかしい「添付忘れ」を防止するGmailの新機能『Forgotten Attachment Detector』 | IDEA*IDEA より引用

と書いているけれど、「I attached a file」ではチェックしてくれなかった。おそらく「file」はチェック項目ではない。

代わりに「I have attached email」ではチェックしてくれた。(Google Operating System さんが言う通り) have attached でチェックしているんだと思う。ここら辺のパターン認識は (日本語サポートも含めて)、Google さんに頑張って欲しい。

Mark as read

「More Actions」プルダウン・メニューの中に入ってる「Mark as Read」を、ボタンにしてプルダウン・メニューの外に出してしまう機能。Mark という人が作ったらしい。小ジャレが利いてて面白いね。

個人的には、これを良い機会と思って「Mark as Read」のショートカットを覚えることをオススメする。だって、ボタンが一つ増えなければ、それだけ画面がスッキリするから。ショートカットは次の通り。

  • Shift + i: Mark as Read (既読にする)
  • Shift + u: Mark as Unread (未読にする)

ref

2008-09-18

Gmail Labs -- チャット/ラベルを右サイドに持って来る

Gmail の左サイドバーにあるコンテンツを右サイドに持ってる機能が Google Labs に追加された。

右に持っていけるコンテンツは二種類。

  1. Right-side chat: Chat (Google Talk) のコンタクトを右サイドに持っていく
  2. Right-side label: Label 一覧を右サイドに持っていく

なお、これらの LABS 機能は、「Navbar drag and drop」と一緒には使えない。ただし、先に「Navbar drag and drop」で位置を移動しておいて「Navbar drag and drop」を機能 OFF にすると、移動した場所は覚えていてくれるっぽい。

あとがき

コンタクト・リストとラベル一覧は、下に長いボックスになる。両方を一遍に見渡すことは難しい。今回の拡張は、その不都合を補ってくれる。横長にブラウザーのウィンドウを開いている人には、ありがたいんじゃないかな。

個人的には、右サイドに移したボックスを隠す時の動きが今まで通りなのが不満。Google Reader のサイド・バーのやうに「横に」隠れて欲しかった。

PS. Attachment Detector のレビューもしなくっちゃ。

Git Introduction in ザリガニが見ていた...。

バージョン管理ツール Git は難しい。分散型 (のバージョン管理ツール) ということだけが、その難しさの原因ではない。おそらく、設計思想のレベルで他のシステム (例えば GNU Arch, darcs, bazaar) と違うのだと思う。

こういったツールを触る時は、質のよいチュートリアルがあると嬉しい (Git のユーザー・マニュアルやチュートリアルは、初心者には難し過ぎる!)。

Alice と Bob になりきって!

ザリガニが見ていた...。」というブログで 4 回に渡って連載された git のチュートリアルが秀逸!

Alice と Bob が二人で共同開発をするといふシナリオで、git のコマンド群を紹介している。これを読むと、git の基本的な使い方 (init, add, commit, log) から、ブランチの作り方、pull を使った共同開発のやり方、そしてベア・リポジトリ (公開用リポジトリー) と push の使い方が身に付く。

  1. アリスとボブになりきってgitをちゃんと理解したい! - ザリガニが見ていた...。
  2. アリスとボブのコラボレーション、gitをちゃんと理解したい! - ザリガニが見ていた...。
  3. アリスとボブのサーバー、git pushをちゃんと理解したい! - ザリガニが見ていた...。
  4. アリスがチャレンジなコードを書く時、git branchをちゃんと理解したい! - ザリガニが見ていた...。

何が良いって、実際のサンプル・コードがあるところ。シナリオにリアル感が増す。読んでて、そうそう、こんな時ってあるよ、git でどうするの? と思える。このサンプル・コードの見せ方が、多過ぎず少なすぎない。これはセンスだと思う。

最初に読む Git の教材としてイチオシ!

あとがき

一点不満がある。「ザリガニが見ていた」が概要フィードしか公開していないこと。これだけ良い記事を書くのだから、Google Reader に登録したい。新しい記事をフォローしたい。なのだけど、全文表示されないので困っちゃう。

ref

2008-09-17

Picasa Web Albums Assistant -- Mac で Picasa Web Albums のアルバムをダウンロードする その 2

2007-12-04 に、Mac で Picasa Web Albums のアルバムをダウンロードする方法について書いた。というのも、Windows/Linux 版の Picasa にはアルバムの一括ダウンロード機能があるのに、Mac には Picasa そのものが提供されていないため。前の記事で紹介した方法は、Firefox のアドオン DownThemAll! と Greasemonkey を併用するやり方だった。

先日、このエントリーにコメントをもらった。「MacOS X 10.4 と Firefox 3 で試したけれど、サムネイル画像しかダウンロードできない」という。ぼくも試してみたら、その通りだった。Picasa Web Albums 側で何か変更があったんだと思う。

Picasa Web Albums Assistant

別の方法として Picasa Web Albums Assistant を紹介しませう。これは Java のプログラム。ぼくは Mac でテストしたけれど、Windows や Linux でも動くと思う。

ダウンロードして起動

ダウンロード・ページから最新 0.3.1 (PWA0_3_1.zip) をダウンロードする。

ダウンロードしたら、zip ファイルを解凍。

フォルダー「PWA0_3_1」の中に入ってる「PWA3.jar」をダブル・クリックすると Picasa Web Albums Assistant が起動する

アルバムのダウンロード方法は、パブリックなアルバムとプライベート (Unlisted) なアルバムで手順が違う。順に追って説明しませう。

パブリック・アルバムのダウンロード

  1. PWA3.jar を起動
  2. 使用許諾書 (要は自己責任で使ってねって書いてある) に「はい」と答える
  3. 「Get Users Public Albums」ボタンをクリック
  4. 「Enter a Picasa Webalbums user ID」と聞かれるので、ユーザー名を入力する。ユーザー名は普通、Picasa Web Albums の URL にこんな形で入ってる「http://picasaweb.google.com/ユーザー名/」
  5. ユーザーが持ってるパブリック・アルバム一覧が表示されるので、アルバムを選択して「Select」ボタンを押す
  6. 写真一覧が表示されるので、ダウンロードしたい画像を選んで「Downloa Selected」ボタンを押す。デフォールトでは、アルバムの写真全部がチェックされている。
  7. ダウンロード先の指定を行なう。ここが一番のハマリどころ。「ファイル」にダウンロード先のフォルダーを指定。その下のドロップダウン・メニューに親フォルダーを指定する。スクリーン・ショットは、「ピクチャ」フォルダーの中の「Egypt」フォルダーに画像をダウンロードしようとしている。なので「ファイル」には「Egypt」を、その下のドロップダウン・メニューには「ピクチャ」を指定している。新規にフォルダーを作成した場合など、「親フォルダー」を指定すべき所が (作成したばかりの) 「新規フォルダー」になってしまうので注意。
  8. ダウンロードが始まる。

PWA - Start PWA - Enter User ID PWA - Select an Album PWA - Select Photos PWA - Select Download Dir

プライベート・アルバムのダウンロード

  1. PWA3.jar を起動
  2. 使用許諾書 (要は自己責任で使ってねって書いてある) に「はい」と答える
  3. 「Get Photos From Invitation URL」ボタンをクリック
  4. 「Please copy and paste athe url from your invitation e-mail」と言われる。招待メールからウェブ・アルバムの URL をコピーして入力する。既にウェブ・ブラウザーでウェブ・アルバムを開いているなら右サイド・バーから「Link to this ablum」をクリックして現れる URL をコピペする。
  5. 後はパブリック・アルバムの手順 6. と同じ。

PWA - Enter Invatation URL

2008-09-13

Gmail Labs に 3 つの新機能 その 2

と、このエントリーを書くためにウェブを見てたら、Gmail は更に 3 つの機能を追加したとのこと。そちらについては、また後日。

clmemo@aka: Gmail Labs に 3 つの新機能 より引用

昨日のエントリーに書いた通り、Gmail Labs が続けざまに新機能を投入した。

今回の新機能は、「返信」に関わるものばかり。数は 3 つ。

  • Quote selected text
  • Default 'Reply to all'
  • Vacation time

Gmail Labs の解説・設定方法は過去記事をどうぞ。

Quote selected text

マウスで範囲指定したテキストだけを引用してくれる機能。長いメールで、一部分だけ引用して返事を書きたい時などに便利。

注意点は以下の 3 つ。

  • キーボード・ショートカット r を使うこと。「返信」ボタンでは (マウスで範囲指定していても) 全文引用になってしまう。
  • 複数範囲指定できない。Firefox だと Ctrl キーを押しながらだと複数のテキスト範囲を選択できるけど、その機能とは上手く動いてくれない。
  • Chrome と Safari では、この機能はまだ動かないとのこと。サポートは二、三週間後か?

Default 'Reply to all'

メールの宛先が自分だけではない時に、メール右上にある返信ボタンがデフォールトで「全員に返信」になる機能。グループでメールのやり取りをしている時に便利かも。

ちなみに、キーボード・ショートカットには、この機能は適用されない。これは二種類ある返信用ショートカットを使い分けろといふことなのでせう。

r
From に返信
R (Shift + r)
  • 全員に返信
  • Vacation time

    Gmail には、自動的に不在お知らせメールを返信する機能がある。名前を「Vacation responder」。名前の通り、夏休みなんかで長期不在になる時に設定をする。ただ、この機能、不在期間が終わった時、自分の手で機能 OFF にしないといけない制限があった。なので、夏休みを終えて (ボケた頭で) この機能を OFF にし忘れていると、変なことになってしまう。

    Vacation time は、この不在機能に終了期限を付けられる機能。カレンダーから休みの開始日と終了日を予め指定できる。

    2008-09-12

    Gmail Labs に 3 つの新機能

    Gmail Labs に 3 つの新機能が追加された (ref. Official Gmail Blog: New in Labs: 3 experiments with labels)。

    1. Navbar drag and drop
    2. Custom Label Colors
    3. Go to label

    Gmail Labs については過去記事をどうぞ。

    Navbar drag and drop

    Gmail 左サイドにあるボックスをドラッグ & ドロップで移動できる機能。移動できるのは以下の項目。

    Quick Links の位置も移動できるやうになったのが嬉しい。

    Custom Label Colors

    Gmail では、ラベルの色を変えることができる。その数 24 色。

    この機能をオンにすると、ラベルに付けられる色の数が 64 に増える。また、フォントの色と背景色に別々に色を設定できるやうになる。

    Gmail - Label Colors

    Go to label

    ラベル専用の検索ボックスをポップアップさせる機能。キーボード・ショートカット g l で使えるやうになる。

    Gmail - Go to Label

    Google Suggest 機能を搭載していて、キーワードの補完入力もしてくれる。また、自分で作ったラベルの他に「All mail」「Spam」「Chat」「Starred」といった、Gmail が元々持っているラベルにも対応。

    残念なことに、Superstar には対応していない。

    あとがき

    と、このエントリーを書くためにウェブを見てたら、Gmail は更に 3 つの機能を追加したとのこと。そちらについては、また後日。

    早すぎて、追いつけないよ (;_;)

    Soul Note dc 1.0

    今回はオーディオのお話。オーディオの世界は奥が深く、ぼくも理解してないことが多々あるので軽めに突っ込む。

    F's Garage さんのブログで、こんな話があった。

    例えば、オーディオメーカーはHDDにキャッシュするCDプレイヤーを売るってのは?

    F's Garage:オーディオマニア脳を逆手に取れ! より引用

    HDD ではないけれど、メモリーにキャッシュする DAC がある。それが Soul Note という新興ブランドの dc 1.0。定価 252,000 円。

    CD トランスポートと DAC

    DAC の説明をしませう。

    CD プレーヤーは、大きく分けると二つのパーツに分けることができる。一つがトランスポート、もう一つが DAC。

    トランスポートは、CD を読んでデジタル・データを取り出すパート。

    DAC は Digital to Analog Converter の略で、トランスポートから受け取ったデジタル情報をアナログ情報に変換するパート。

    ちなみに、DAC から出力されたアナログ情報は、アンプで増幅され、スピーカーで「音」になる。

    閑話休題。量販店で見かける CD プレーヤーは、このトランスポートと DAC がセットになっている。ただ、お金を出すと、トランスポートの機能しか持たない高級品。DAC 機能しか持たない高級品が出てくる。また、普段は CD プレーヤー (トランスポートと DAC の一体型) として使えるけれど、自分の DAC を使わず専用の DAC に出力を回せる機器もある。ぼくの使ってる CEC CD3300R は正にそれ。

    といふわけで、Soul Note の dc 1.0 は DAC 専用機といふ位置付けの商品。

    dc 1.0 について

    dc 1.0 の説明をカタログから引用する。

    つながれるトランスポート、プレーヤーの性能にかかわりなく、常に音源に忠実な高精度の D/A 変換を行うため、独自の非同期型ジッターレス Digital Audio レシーバーを開発。

    メモリー回路にデータを一時的に蓄えることで送り側とのクロック差分を吸収し、PLL を完全に排除、自身のクリスタルで生成された高品質なマスタークロックによりジッターのないピュアなデータを DAC IC に送ります。

    太字は @aka。

    この方式なら、CD トランスポート部分を変えても音は変わらないやうに思う。で、そのことを開発者の鈴木氏に直接聞いてみた。すると、これだけやってもトランスポートによって音が変わるといふ。その要因は沢山あるそうで、一例として、CD トランスポートの電源管理がちゃんとできていない場合を挙げておられた。つまり、回路内部でちゃんとアースが出来ていないと、それが CD から取り出した後のデータに影響を与えてしまう、というのがぼくの理解 (だけど難しくてよく覚えていない ^^;)。

    そういふわけで、オーディオは奥が深い。

    あとがき

    この dc 1.0。年末に買う CD プレーヤーの候補にも入ってたりする。今、第三候補くらい。はてさて、どうなることやら。

    2008-09-11

    Git で他の人と共同開発する

    過去記事

    git で個人プロジェクトは管理できているとする。

    ストーリー

    Bob が wonderland プロジェクトを開発している。貴方 (Alice) は Bob さんのプロジェクトを手伝う。

    開発作業はかうなる。Alice は自分のリポジトリーに Bob のリポジトリーをコピーする。Bob 側で変更があったら、変更分を自分のリポジトリーに取り入れる (Subversion で言う所の svn update)。Alice が変更を加えたら、Bob に自分の変更分を取り入れてもらう (この作業は Bob が行なう)。Alice が Bob 側に変更分を投げつけることは (今回は) やらない。

    Bob のリポジトリーは /home/bob/wonderland にあるとする。Alice は /home/alice/wonderland。

    Pull を使う方法

    まずは、リポジトリーのコピー。

    $ cd ~
    $ git clone /home/bob/wonderland
    

    開発作業はいつも通り。

    $ cd wonderland
    $ vi foo.txt
    $ git status            ; 変更分をファイル単位で確認
    $ git diff              ; 変更分をコード単位で確認
    $ git commit -a         ; 変更分をコミット
    $ git log               ; ログを見る
    

    Bob の変更分を取り込む

    $ git pull
    
    Bob が Alice の変更分を取り込む

    Alice はメールか何かで変更をしたことを Bob に伝える。Bob は次のやうにして Alice の変更分を取り込む。

    $ whoami
    bob
    $ cd ~/wonderland
    $ git pull /home/alice/wonderland
    

    Fetch を使う方法

    pull を使う方法だと Bob の変更分だけ見たい時に困る。例えば Bob が危険な変更をここ 3 日間かけて行なっている。その変更分を取り込むのは時期尚早だけど、どう変更しているかは見ていたい。そういう時。

    これは Fetch を使う。

    $ whoami
    alice
    $ cd ~/wonderland
    $ git remote add bob /home/bob/wonderland
    $ git fetch bob
    From /home/bob/wonderland
     * [new branch]      master     -> bob/master
    

    出来たブランチ名は bob/master。ブランチを確認してみませう。

    $ git branch
    * master
    

    自分のブランチに bob/master は出来ていない。

    リモートのブランチを覗いてみる。

    $ git branch -r
      bob/master
      origin/HEAD
      origin/master
    

    bob/master が見つかった。

    変更分の取得・参照

    Alice は bob が変更を加えたという情報を入手した。さあ、変更分を見てみたい。まずは最新の Alice のリポジトリーを取ってくる。

    $ git fetch
    

    そしたら変更点を見てみましょ。

    $ git log -p master..bob/master
    

    Alice の最新ソース・コード一式が見たいなら、checkout する。

    $ git checkout remotes/bob/master
    

    この時、貴方 (Alice) は bob のリポジトリーを見ているだけなことに注意。編集とかしても反映されない。またこの状態で git fetch しても checkout したソース・コードには反映されない。一旦 master に戻って、もう一度 bob/master を checkout する必要がある。どうやら、これはあくまでスナップショットを見ているだけらしい。

    マージする

    Bob のリポジトリーが安定したとの話を聞いた。Alice は自分のリポジトリーに Bob の変更分を加える決意をする。

    マージの方法は簡単。

    $ git merge bob/master
    Updating 8ed0b02..1939699
    Fast forward
     foo.txt |   36 ++++++++++++++++++++++++++++++++++++
     1 files changed, 36 insertions(+), 0 deletions(-)
    

    もしくは pull を使う方法もある。

    $ git pull . remotes/bob/master
    

    ディレクトリーにだけ実行属性を付けたい

    Unix にて。ディレクトリー foo 以下の全てのファイルを誰にでも読めるやうにしたい。

    ファイルを「誰でも読める」やうにするには、chmode を次のやうに使う。

    $ chmod o+r foo.txt
    

    o (other:全員) に r (read:読み込み属性) を与える。

    ディレクトリー下、全てのファイルに適用するには -R (再帰) オプションを使う。

    $ chmod -R o+r foo/
    

    ただし、ディレクトリーには「読み込み属性 (r)」の他に「実行属性 (x)」もないと、ディレクトリー以下を読めないという制限がある。つまり、上のコマンドを実行しただけでは、foo/bar 以下は読めないかもしれないといふこと。ディレクトリーに実行属性も与えたい。かうしてみやう。

    $ chmod -R o+rx foo/
    

    今度は普通のファイルにも実行属性を付与してしまう。

    やりたいことは、2 つ。

    1. 全てのファイルとディレクトリーに読み込み属性を与える
    2. ディレクトリーにだけ実行属性を与える

    find を使う方法

    find の type オプションでディレクトリー (d) を指定する方法。

    $ chmod -R o+r foo/
    $ find foo/ -type d -exec chmod o+x {} \;
    

    find と xargs を使う方法

    find の -exec が苦手な人に。。。

    $ chmod -R o+r foo/
    $ find foo/ -type d | xargs chmod o+x
    

    chmod の X を使う

    実行属性を x (小文字) でなく X (大文字) で与える。

    $ chmod -R o+rX foo/
    

    X は、ディレクトリーに対しては x と同じ。ファイルに対しては、実行属性を持つものにだけ実行属性を付与する。

    $ ls foo.txt         ; foo.txt は x を一つも持たない
    -rw-r--r-- 1 ataka 0 2008-09-12 foo.txt
    $ chmod o+X foo.txt
    $ ls foo.txt         ; o+X しても何も変わらない
    -rw-r--r-- 1 ataka 0 2008-09-12 foo.txt
    $ chmod 654 foo.txt
    $ ls foo.txt         ; group に x を与える
    -rw-r-xr-- 1 ataka 0 2008-09-12 foo.txt
    $ chmod o+X foo.txt
    $ ls foo.txt         ; どこかに x があると、o+X で x が付く
    -rw-r-xr-x 1 ataka 0 2008-09-12 foo.txt
    

    X は意図しないファイルにも実行属性を与えることがあるので、ケース・バイ・ケースでお使いあれ。

    ref

    2008-09-10

    Greasemetal リリース -- Google Chrome 版 Greasemonkey

    Google Ghrome 版の Greasemonkey がリリースされた。作者はサイボウズ・ラボの奥一穂氏。

    ご存じの通り、Google Chrome では拡張機能 (アドオン機能) がまだない。なので Greasemetal は exe ファイルとして公開されている。

    使い方

    Greasemetal アプリを起動すると、Greasemetal が自動的に Google Chrome を開く。後は普段通り Chrome を使うだけ。

    ユーザーとしては、今まで Google Chrome のデスクトップ・アイコンをダブル・クリックしてブラウザーを起ち上げていたのが、Greasemetal のデスクトップ・アイコンに変わるだけ。

    Greasemetal のインストール

    上記ページの「Using Greasemetal」セクションから、GreasemetalInstaller.exe をダウンロード。

    ダブル・クリックするとインストール画面が起動するので、次へ次へと進んでく。

    以上。

    Userscripts のインストール

    Userscripts には Greasemonkey のスクリプトがそのまま使える。使いたい Userscript をダウンロードして、「マイ ドキュメント」下の「userjs」というフォルダーに入れてやる。これでお終い。

    Userscripts を入れたら、ブラウザーの再起動なしでスクリプトが使用可能になる!

    Userscripts は Userscripts.org で沢山公開されている。

    バージョン 0.1 の制限

    • Userscript を管理する UI がない (Userscript を一時的に無効にするには、その Userscript を userjs の外に出す。「ユーザースクリプトを実行するページ」は直接 Userscript をいじって変更する)
    • GM_* 関数はサポートしていない (GM_* 関数を使っている Userscript は須く動かない)

    Technical Info

    技術的な話は、奥さんの英語ブログに書いてある。

    大ざっぱに言うとかうなるらしい。Greasemetal の実体はウェブのプロキシ・サーバー Automation Proxy。Google Chrome は、このプロキシ経由でウェブ・ページを GET する。プロキシは Userscript の「適用サイト」にマッチしたら、その Userscript をダウンロードするようページに <script> 要素を追加して Chrome に渡す。Chrome はページに埋め込まれた script 要素から Userscript を実行する。ほら! Chrome 版 Greasemonkey が出来てしまった。

    ※間違ってたら、ご指摘下さい

    Repository

    Subversion リポジトリーも公開中。

    svn checkout http://kazuho.31tools.com/svn/chromemonkey/trunk/ chromemonkey
    

    あとがき

    これは熱いアプリが出て来た。脱帽! これからの開発にも期待大。

    SimplifyMedia を Ubuntu 8.04 にインストールする

    PC を音楽サーバーにするサービス兼アプリ Simplify Media。とても楽しい。Windows 版の他、Mac 版・Linux 版のアプリが出ていることも嬉しい。

    ただし、このアプリ。Win/Mac 版はインストールが容易なのだけど、Linux 版だけ作業が必要。といふわけで、インストール方法をメモしておく。ちなみにぼくの環境は Ubuntu 8.04。

    Simplify Media の準備

    インストール方法は、パッケージ内の README ファイルに書いてある。ただし英語。

    まずは Linux 用ダウンロード・サイトから simplifymedia.tar.gz をダウンロード。ダウンロードが終わったら、適当な場所に展開。

    $ tar xzvf ~/download/simplifymedia.tar.gz
    

    Simplify Media の設定方法には二種類ある。

    一つは GUI ベースの Standard 設定。これは、アプリを起動後に「オプション設定」からアカウント、パスワード、共有ディレクトリーを指定する。

    もう一つは CUI ベースの Server 設定。コマンド・ラインから simplify media を起動。起動時にオプション引数で、アカウント、パスワード、共有ディレクトリーを指定する。

    Standard 設定

    $ cd simplifymedia
    $ ./SimplifyMedia
    

    起動したら、アカウント (スクリーン・ネーム) とパスワードを入力。どのディレクトリーの音楽を共有するのか設定するのを忘れないやうに。

    Server 設定

    $ cd simplifymedia
    ./simplifyserver.sh -n スクリーン・ネーム -l コンピューターの名前 -p パスワード -s /home/music1:/home/music2
    

    例えば、スクリーン・ネームが ataka で、コンピューター名が linux-aka、音楽を /home/ataka/music 以下に保存している場合は、次のやうにする。

    ./simplifyserver.sh -n ataka -l linux-aka -p *** -s /home/ataka/music
    

    Rhythmbox の準備

    Rhythmbox が入ってなかったら、インストール。

    $ sudo apt-get install rhythmbox
    

    Rhythmbox 用のプラグインをインストール

    $ cd simplifymedia/rhythmbox_Ubuntu_8_04
    $ ./install_rhythmbox_daap.sh
    

    必要に応じて codec もインストールしておきませう。

    $ sudo apt-get install gstreamer0.10-plugins-base gstreamer0.10-plugins-good gstreamer0.10-plugins-ugly gstreamer0.10-plugins-bad gstreamer0.10-plugins-ugly-multiverse gstreamer0.10-plugins-bad-multiverse gstreamer0.10-ffmpeg gstreamer0.10-fluendo-mp3
    

    Apple「Let's Rock」イベントのまとめ

    寝すごした。起きたら 3 時だった。それから PC の前に座って、サイト探して、Steve Jobs のスピーチ終わってた。

    とりあえず速報サイトに書いてあることを、自分用にまとめ。

    新製品: イヤホン

    アップデート: iTunes (ver.8), iPod nano (4G), iPod Touch (2G), iPhone firmware (ver.2.1)

    iTunes 8

    iTunes 8 リリースとのこと。まだ、ぼくのマシンでは最新版をダウンロードできない。

    • NBC のテレビ番組を HD 画質で販売。1 つ 2.99 ドル。
    • 新機能 Genius: iTunes 版 Last.fm ラジオ。購入履歴、音楽ライブラリー情報、再生履歴等から、好みのプレイリストを作成してくれる。Amazon のおすすめみたいに、曲のおすすめもしてくれるのかな?

    iPod Classic

    アップデート

    • 容量 120 GB
    • 値段 249 ドル

    iPod nano

    新 iPod nano (第 4 世代) 発表

    • Gizmode などでリークしていたものと同じ
    • iPod 史上最薄。アルミデザイン。ディスプレイは曲面ガラス。
    • 2 軸加速度センサー。縦横を認識 (横に倒すと、画面も横に切り替わる)。
    • ボイス・レコーダー付。
    • プレイリスト自動作成「Genius」塔載。
    • シャッフル機能 (本体を振るとシャッフル)
    • バッテリーは音楽 24 時間、ビデオ 4 時間。
    • 色は 9 色 (シルバー・グレイ・パープル・ブルー・グリーン・イエロー・オレンジ・レッド・ピンク)
    • 8 GB, 149 ドル
    • 16 GB, 199 ドル (本日発売?)

    イヤホン・アクセサリー

    新しいアクセサリー発売。iPhone のイヤホンに似ている。

    • ケーブルの途中にリモコン。
    • マイク付。
    • ボリューム・コントロールと再生/一時停止
    • ダブル・クリックで次の曲。トリプル・クリックで前の曲。
    • 79 ドル、10 月発売

    iPod Touch

    新 iPod Touch (第 2 世代) 発表。

    • Gizmode でリークしたデザイン。
    • ボリューム・ボタン追加
    • スピーカー追加
    • Nike+ 塔載 (靴にセンサーを入れると、走行距離や消費カロリーを iPod に無線で伝える?)
    • プレイリスト自動作成「Genius」塔載。
    • バッテリーは音楽 36 時間、ビデオ 6 時間。
    • 8 GB, 229 ドル
    • 16 GB, 299 ドル
    • 32 GB, 399 ドル (全て本日発売)

    iPhone

    iPhone 2.1 アップデート! 基本、バグ修正のみ。

    • 通話が切れにくくなった
    • バッテリー駆動時間が改善された
    • バックアップが速くなった。
    • パフォーマンスも向上
    • 13 日の土曜日 (アメリカは 12 日の金曜日) からダウンロード開始。無料。

    あとがき

    大きなびっくりはなかった。でも、リーク記事がなかったら、もう少し楽しめたんじゃないかと思う。最近、Apple の情報はリークが多くて、びっくり感が薄い。リーク情報が多いのは、Apple 側のコントロールがしにくくなってるのもあると思うけど、取材側のパワーが前より強くなったのが主因な気がする。

    2008-09-09

    Ruby で子プロセス

    Ruby でコマンドを呼び出したい。子プロセスを作りたい。組み込み関数 system の使い方。

    system(command)
    

    コマンド一つで済む場合は簡単。

    引数を取る場合は、コロンで区切る。

    system(program, arg1, arg2,...)
    

    ARG1 以降は省略可能。ARG1 以降を省略する場合は、一番最初の例と同じになる。

    以下、落ち穂拾い

    • コマンドの終了ステータスが 0 ならば、true を返す
    • そうでなければ false を返す
    • 終了ステータスは $? で参照できる

    サンプル

    ファイルの中身を一行ずつコマンドに渡す場合は、こんなコードになるかな。

    #!/usr/bin/env ruby
    
    require 'fileutils.rb'
    
    # Usege:
    # foo.rb sample.txt /old/dir/
    
    filename = ARGV[0]
    old_dir = ARGV[1]
    
    File::open(filename){|file|
      file.each {|path|
        path.chomp!
        old = old_dir + path
        new_dir = File.dirname(path) + "/"
    
        FileUtils.mkdir_p(new_dir) unless FileTest.exist?(new_dir)
        system("cp", old, new_dir)
      }
    }
    

    かなり適当だけど、旧ディレクトリーの中にあるファイルを新ディレクトリーにコピーするコマンド。旧ディレクトリーからコピーし忘れたファイルがあった時に使えるかな。

    あとがき

    system 関数には、コマンドの引数をカンマで区切って渡す。それなのに、(shell で渡すやうに) スペースで区切って渡そうとして、エラーが出た。

    system("program #{arg1} #{arg2}");
    

    一時間近くハマったので、自戒の意味を込めてエントリーにする。

    最初のタイトルは「Ruby でシステム・コール」でした。はてブで、これはシステム・コールではないと教えてもらいました orz

    2008-09-08

    Google Analytics が Google Chrome を認識 -- 自サイトの統計を取ってみた

    Google Analytics がブラウザー・タイプとして Google Chrome を認識するやうになった。

    Google Chrome のリリースが 2008-09-03 で、上記エントリーが 2008-09-04。ほとんど間を合けずサポートした感じ。

    さて、このニュースを受けて各ブログがブラウザー・シェアを報告している。お目当ては Google Chrome がどれ程のシェアを取ったか? といふところ。

    各サイトのブラウザー・シェア

    まずは TechCrunch。

    Clickyが引き続き追跡しているChromeの利用状況は、対象の4万5000サイトで2~3%の範囲にある。TechCrunch読者のChrome利用率はずっと高い。火曜日以来6.23%で、これはTechCrunch読者のブラウザーの中で、Firefox、IE、Safariに続く第4位だ。

    TechCrunch Japanese アーカイブ » Google AnalyticsがChromeを追跡開始。当サイトでのシェアは6.23% より引用

    続いて Polar Bear Blog さん。

    Chrome は6.45%で、Safari に次いで第4位。TechCrunch と同じような結果になっています。

    中略

    最もシェアを落としたのは IE。少なくとも Polar Bear Blog では、Chrome は IE からシェアを奪っている、という結果になっています。

    POLAR BEAR BLOG: Chrome、シェアを IE から奪う(このブログに限り) より引用

    もう一つ。Going My Way さん。

    日本時間で、 9/3 から利用できましたので、それ以降現在までの状況です。
    Internet Explorer → 41.08%
    Firefox → 37.93%
    Google Chrome → 9.25%
    Safari → 8.23%
    Opera → 2.5%

    Going My Way: Google Chrome が出てからのブラウザーの利用状況内訳 より引用

    clmemo@aka のブラウザー・シェア

    まずは2006-12 の調査結果。1 位 Firefox (49.48%)、2 位 IE (38.47%)、3 位 Opera (4.97%)、4 位 Safari (3.77%)。

    続いて、Google Chrome リリース前の金曜日。2008-08-29 のデータ。

    Browser Share on 2008-08-29

    1 位 IE (43.16%)、2 位 Firefox (42.28%)、3 位 Safari (10.63%)、4 位 Opera (1.77%)。シェアの一位と二位に差はほとんどない。2006-12 のデータと比べると、何気に IE のシェアが増えて、Firefox のシェアが減った。このブログから技術的な話題が減ったことを暗に指しているのかしらん ^^;。Safari のシェアは倍以上に躍進。MacBook を買って Apple ネタが増えたことと無関係ではないでせう。Opera の落ち込みはひどい。

    最後に、Google Chrome リリース後のデータ。データ収録日は 2008-09-05。上のデータの一週間後。曜日によるデータのばらつきは最小限になってるはず。

    Browser Share on 2008-09-05

    1 位 Firefox (42.44%)、2 位 IE (39.15%)、3 位 Chrome (8.91%)、4 位 Safari (5.33%)、5 位 Opera (2.71%)。Chrome は 9% 弱のシェアを占めて 3 位。シェアを奪われたのは IE と Safari だった。Firefox のシェアは変わらず。

    あとがき

    IE のシェアを Chrome が奪ったのは、他のブログさんのレポートと同じ。てっきり Firefox のシェアが落ちるものと思っていたので、意外。

    忘れてなければ、一か月後と Linux/Mac 版 Chrome が出た後にもブラウザー・シェアを調べてみたい。

    2008-09-06

    Amazon が iPhone に対応した

    Amazon が、iPhone (含む iPod Touch) 用に最適化された。iPhone の Safari アプリでアクセスすると、自動的に iPhone 用のページが開かれる。

    スクリーン・ショット

    サイトの横幅が Safari にフィット。検索ボックスも大きくなって、クリックしやすくなった。

    Amazon for iPhone 1

    検索結果も iPhone に最適化されていて、見やすい。

    Amazon for iPhone 2

    「カートに入れる」ボタンも大きくなって、押しやすくなった。必要最小限の情報が表示されるのも嬉しい。

    Amazon for iPhone 3

    上の続き。カスタマー・レビューのタイトルをクリックすると、レビューが読める。スクリーン・ショットは、レビューを開いたところ。

    Amazon for iPhone 4

    iPhone - i.softbank.jp の設定方法

    iPhone のデフォールト・メール i.softbank.jp は設定が面倒。設定方法の解説は、ソフトバンクのマニュアル より「iPhone - iPod touch ラボ」さんの記事が詳しい。

    自分用の覚え書きを兼ねて、簡単にまとめとく。

    設定方法

    仮メール・アドレスとパスワードの保存
    1. SMS アプリを起動
    2. 「157」のメッセージを開く
    3. アカウント情報の「ログイン ID」と「パスワード」をメモ帳に書き写す
    4. SMS アプリを閉じる
    My SoftBank にログイン
    1. Safari アプリを起動
    2. ブックマークを開く (ブラウザー下の「本」のアイコンをクリック)
    3. 「My SoftBank」をクリック (My SoftBank のページが開く)
    4. 黄色の @ マークをクリック (ログイン画面が開く)
    5. メモしておいた「ログイン ID」と「パスワード」を入力して、ログイン
    メール・アドレスとパスワードを変更
    1. 「メールアドレス変更」をクリック
    2. 「新しいメールアドレス」に好きなメアドを入力する
    3. 同様に「パスワード変更」を行なう
    4. Safari アプリを閉じる
    メール・アプリにアカウント登録
    1. 設定アプリを起動
    2. 「メール/連絡先/カレンダー > アカウントを追加」を選択
    3. 「その他」をクリック
    4. 「名前」はご自由に。
    5. アドレスに新しく設定したメール・アドレス (@i.softbank.jp を含めて)」を入力
    6. パスワードに新しく設定したパスワードを入力
    7. メールサーバーとの交信が始まる。「SSL で接続できません」とメッセージが (2 回?) 表示される。どちらも「はい」を押す
    8. 以上。

    あとがき

    本当に自分用のメモになっちゃった。

    ちなみに、ぼくは設定しただけで全く i.softbank.jp を使ってない。携帯も Gmail アカウントで一本化した。PC でメールを確認する時、どちらのアカウントにあるメールか分からなくなるのは困るから。それと、Gmail で十分に携帯メールとしてぼくの役には立つから。

    iPhone でスクリーン・ショットを撮る方法

    iPhone でスクリーン・ショットを撮る方法。ついつい忘れてしまうのでメモ。

    1. 電源ボタンを押しながら
    2. ホーム・ボタンを押す

    画面が一瞬ホワイト・アウトする。これで、画面のスクリーン・ショットが撮れている。撮ったスクリーン・ショットは「写真」アプリの「カメラロール」の中に保存されてる。

    経路検索とスクリーン・ショット

    ぼくは DoCoMo SH902i 時代に、経路検索の結果を「画面メモ」に撮っていた。スクリーン・ショットを使えば、同じことが可能になる (一画面分の情報しか保存できないけれど)。

    例えば iPhone のアプリ「駅探」。アプリを閉じると、検索結果が消えてしまう。もう一度同じ結果を見直したい時は、履歴機能を使う。「駅探」の履歴機能は、検索条件を覚えていて再検索をかけるというもの。なので、地下鉄に乗ってたりして圏外になると、「もう一度同じ結果」を見ることができない。

    そこで、経路検索したらとりあえず結果をスクリーン・ショットに撮っておく (iPhone の容量は大きいので、バンバン撮ってもさほど困らない)。検索結果を見直したくなったら、撮った写真を見る。これなら、iPhone が圏外になっても大丈夫。

    2008-09-05

    Git Quick Start

    バージョン管理システム Git にも手を出してみる。Git は Linux のカーネルをバージョン管理するために作られた。大規模なソース・コード管理が出来るとのこと。

    主な情報元は下記。

    インストール

    Ubuntu では git-core を入れる (「git」は Gnu Interactive Tools なので注意)。

    $ sudo apt-get install git-core
    

    準備

    メアドと名前を登録。

    $ git config --global user.name "Masayuki Ataka"
    $ git config --global user.email your.email.address@gmail.com
    

    コマンドのヘルプ

    コマンド git init のヘルプの出し方。2 通りある。

    $ man git-init
    $ git help init
    

    後者の方が Subversion 使いにはしっくり来るかな。

    Init

    レポジトリーの作成。

    $ mkdir project.foo
    $ cd project.foo
    $ git init
    Initialized empty Git repository in .git/
    

    ファイルの登録

    とりあえず、README だけ登録。

    $ touch README
    $ git add .
    $ git status
    # On branch master
    #
    # Initial commit
    #
    # Changes to be committed:
    #   (use "git rm --cached <file>..." to unstage)
    #
    #       new file: README
    #
    $ git commit -a -m "Add README file"
    

    git status で、コミット前の情報が分かる。けど、デフォールトの表示は Subversion や Bazaar 使いからすると馴染みにくい。

    ログ

    $ git log
    

    デフォールトで viewer を使って起動する。

    修正してコミット

    README に「Hello, World」を追加してコミット。追加前には status を実行。diff で差分を取ってチェックしておきませう。

    $ vi README
    $ git status
    # On branch master
    # Changed but not updated:
    #   (use "git add <file>..." to update what will be committed)
    #
    #       modified:   README
    #
    no changes added to commit (use "git add" and/or "git commit -a")
    $ git diff
    diff --git a/README b/README
    index e69de29..ebb98ea 100644
    --- a/README
    +++ b/README
    @@ -0,0 +1,2 @@
    +Hello, World.
    +
    $ git commit -a -m "Add Hello, World"
    Created commit 7c156ae: Add Hello, World
     1 files changed, 2 insertions(+), 0 deletions(-)
    

    今日はここまで。

    Pre 要素に横スクロール・バーを付けた

    当方のブログ、今まで pre 要素で横に長〜いテキストを書くと右端がサイドバーに隠れて見えなくっていた。例えば、ソース・コードをそのままコピペした時とか、長いワンライナーを書いた時にそんなことが起きていた。

    今日、改善策を入れた。

    CSS で一行だけ。

    div.quote, pre.sample {
      margin: 0 0 1em 20px;
      padding: 5px 0 5px 10px;
      overflow: auto;
    }
    

    overflow というのがそれ。行をはみ出す (overflow する) 時に、自動で横スクロール・バーを出してくれる。

    これで、少しはブログを見易くなったんじゃないかと思う。今まで、ご不便かけててごめんなさい。

    Firefox のタブはマウス・ホイールでスクロールできる

    Firefox でタブを開き過ぎると、タブが一画面に納まり切らなくなる。納まらないタブは、左右に隠される。

    Firefox - scroll tabs

    隠れたタブを表示させるには、タブ列の上でマウス・ホイールをくるくる回す。すると、隠れてたタブがスルスルとスクロールして現れる。

    この他に

    • タブ列の両端にある三角矢印をクリックする
    • タブ列右端のプルダウン・メニューを使う

    という方法もある。どちらもマウスを大きく動かさないといけないので、使い勝手は悪い。

    あとがき

    マウス・ホイールを使うやり方は、今日気付いた ^^;

    Linux 版 Google Chrome のソースコ一ド

    2008-09-03、Google Chrome が公開された。リリースされたのは、Windows 版のみ。Mac / Linux 版はリリースされなかった。これらは現在、開発中とのアナウンスあり。

    さて、ソース・コードだけは Mac 版も Linux 版も公開されている。

    上記 Instruction ページをちゃんと読むと、ソースをコンパイルしてもブラウザー「Chrome」が作られないことが分かる。

    じゃあ、あのソースは何なのか。答え。いくつかのモジュールがコンパイルされて、そのユニット・テストが走る。それだけ。Linux/Mac 版のソース・コードは、サグラダ・ファミリアのやうに未完成のまま公開されている。

    ドキュメントに目を通さずに、とにかくコンパイルしたらバグありありのブラウザーが出来るでせう。ドキュメントはコンパイルが終わったら精読しやう。なんて不埓な考えを持っていると、コンパイル終了後、Chrome の実行ファイルはどこ〜? なんて探し回る羽目になる。そして、ドキュメントを読み直して、がっくりと肩を落とす。

    コンパイルするなら...

    上に書いてあるやうなおバカをやってしまったのだけど、せっかくなのでコンパイルの手順だけ書いておく。ほとんど Build Instructions の訳だけど、よければどうぞ。

    ちなみに、ぼくの環境は Ubuntu Linux 8.04。Google の Linux 用テスト環境も Ubuntu 8 (Hardy Heron) の変種とのこと。

    準備

    必要なソフトウェアは以下の通り。

    • Subversion >= 1.4
    • pkg-config >= 0.20
    • Python >= 2.4
    • Perl >= 5.x
    • gcc/g++ >= 4.2
    • bison >= 2.3
    • flex >= 2.5.34
    • gperf >= 3.0.3
    • libnss3-dev >= 3.12

    以下のコマンドで、これらのパッケージを全てインストールすることが出来る (Ubuntu 8.04 のパッケージは、上のバージョン条件を全て満たしている)。

    $ sudo apt-get install subversion pkg-config python perl g++ bison flex gperf libnss3-dev
    

    $CHROMIUM_ROOT

    build ディレクトリーを $CHROMIUM_ROOT と呼ぶことにする。

    depot_tools の入手

    $ cd $CHROMIUM_ROOT
    $ svn co http://src.chromium.org/svn/trunk/depot_tools/linux depot_tools
    

    tar ball も公開されてるけど、欠けてるファイルがあるそうな (tar ball を使う場合は Subversion 1.5 が必要になるとのこと)

    depot_tools の解説もどぞ。

    Chromium の Check out (スナップ・ショット編)

    現在、暫定的な処置として、ソースのスナップ・ショットを公開している。そちらをダウンロードして欲しいとのこと。おそらく一斉にアクセスされて、過負荷になることを恐れているんでせう。

    といふわけで、スナップショットのダウンロード。

    ダウンロードしたら展開。

    $ cd $CHROMIUM_ROOT
    $ tar xzvf ~/download/chromium.tgz
    $ mv chromium/src ./
    

    Chromium の Check out (gclient 編)

    スナップショットを使わない場合、次の操作を行なう。

    $ export LANG=C
    $ ./depot_tools/gclient config http://src.chromium.org/svn/trunk/src
    checking out latest depot_tools...
    $ ./depot_tools/gclient sync
    (update が実行される...)
    

    環境変数 LANG を C に設定するのは、gclient のためのおまじない。

    コンパイル

    コンパイルは 30 分もかからない。

    $ cd $CHROMIUM_ROOT/src/chrome
    $ time ../third_party/scons/scons.py Hammer
    ...
    ...
    ../third_party/scons/scons.py Hammer  508.97s user 53.07s system 165% cpu 5:38.90 total
    

    おまじないの解除を忘れずに。

    $ export LANG=ja_JP.UTF-8
    

    動かしてみる

    実行ファイル (ユニット・テスト) は、$CHROMIUM_ROOT/src/chrome/Hammer に出来る。base_unittests と net_unittests を実行してみませう。

    2008-09-04

    Picasa3 (beta) リリース

    Google の写真管理ソフト Picasa のバージョン 3 (beta) がリリースされた。リリースされたのは、Windows 英語版のみ。日本語版のリリースは (まだ) ない。また、Linux 版もまだ見当たらない。時間がなくてほとんど触れていないので、とりあえず簡単な紹介だけ。

    ダウンロードはこちらから。

    上のページにアクセスしても何故か、Picasa 2.7 のページに飛ばされてしまう場合は直リンクでダウンロードをどぞ。

    今回の新機能での一番のウリは、顔認識できるようになったこと。顔の写っている写真だけピックアップするボタンが付いた。ただし、Picasa Web Albums がやってるように、写真から同じ人を自動認識して名前を付けることは出来ない (みたい)。

    この他、Picasa Web Albums と Picasa の同期機能、動画作成機能、ウォーターマーク (すかし) 追加機能、等々新機能も豊富。

    あと、「Multiple word tags」という機能も追加されたけど、日本語では動かなかった。残念。

    2008-09-03

    Google Chrome にあって Firefox にないもの (もしくは Firefox にあって Chrome にないもの)

    Google のオープンソース・ウェブブラウザー Google Chrome がリリースされた。バージョンは 0.2.14927。Apple WebKit をベースにしている。ダウンロードはこちらから。

    リリースのエントリーはこちら。

    Google Chrome

    ぼくは Firefox 使いなので、Firefox との比較で Google Chrome の新機能を書いて行きませう。

    Google Chrome にあって、Firefox にないもの

    1. スピード・ダイヤル機能。。。新しいタブを開くと、よく使うページがサムネイル表示される。Opera の機能とそっくり。違いは、Opera はサムネイルで表示するページをユーザーが指定するけど、Google Chrome はブラウザーが自動的に設定してくれるところ。
    2. Gears。。。Google の Gears がデフォールト・インストール
    3. ショートカット作成機能。。。Gears の機能の一つ。ウェブ・ページへのショートカット・リンクを Windows のデスクトップ上に (ショートカット・アイコンとして) 作成できる。ウェブ・ブラウザーを開いてブックマークをクリック、といふ 2 手間が 1 つになって便利。Firefox でも同じような事が出来るとのコメントを頂きました [thanks]。Firefox と Chrome を比べると、デスクトップ・アイコンにサイトの Favicon が使われる。「デスクトップ」だけでなく「スタート・メニュー」や「クイック起動バー」への追加も同時に行なえる。という二点でしょうか。
    4. シークレット・モード。。。履歴や検索履歴を残さないモード。ブラウザーを閉じると Cookie も削除される。ブックマークとダウンロードしたファイルは残る。秘密 (?) の調査をする時にどうぞ。
    5. タブの新機能。。。タブをブラウザーの外にドラッグすると新ウィンドウ。ウィンドウ間でタブの移動も可能。「このページから開いたすべてのタブを閉じる」機能。

    Firefox にあって Google Chrome にないもの

    1. MacOS X 版。。。ない。現在、開発中。ただし、自作は可能?公開されているソースでは、一部モジュールのコンパイルまでしか出来ない。自作はまだ無理
    2. Linux 版。。。ない。現在、開発中。ただし、自作は可能?同上
    3. メニュー・バー。。。メニュー・バーに入ってたものは、アドレス・バー右隣の「ファイル」アイコンに集約された。アイコンをクリックすると、ドロップダウンでメニューに入ってたものが表示される。なお、「ツール」「オプション」系のメニュー項目は、「ファイル」アイコン隣の「スパナ」アイコンに集約されている。
    4. 検索ボックス。。。アドレス・バーが検索ボックスの代わりになる。「検索結果を別のタブで開く」といふ設定はない (のかな?)。
    5. 拡張機能 (Addons)。。。ない。つまり、Greasemonkey も動かない。Google Toolbar も、Make Link も、FontinizeTab も。けっこう痛い。

    あとがき

    Google Chrome は、ページの読み込みや JavaScript の処理が Firefox 3.0 より早く感じる。見た目や使い勝手も、Google らしいシンプルさが前面に出ていて気もちいい。細かな所に手が届いている。開発用の ウェブ・インスペクターはかなりの高機能。

    バージョン 0.2 としては、十分な出来ではないかと思う。

    ただ、愛用の Addons が使えなくなるのは厳しい。ぼくは Greasemonkey なしでは生きられないし、FaviconizeTab なしのタブ地獄には住みたくない。Google Toolbar が提供する Google Bookmark との連携や簡易英和辞書機能もないと嫌だし、カスタム・ボタンで検索エンジンも複数使い分けたい。

    しばらく、Google Chrome と Firefox は両刀使いでやっていこうかと思ふ。