2010-10-30

Redmine の Wiki に添付したファイルを移動させる

Redmine の Wiki にはファイルを添付する機能がある。ところが、Wiki の名前を変更すると、添付したファイルは消えてしまう。正確には、古い Wiki 名にファイルが紐付けされていて、新しい Wiki 名へと追随しない。

現状、スマートな解決策はない。泥臭いけれど、Wiki を管理している DB を直接いじるしかない。本エントリーでは、MySQL を使っているとして Wiki に添付したファイルを移動させる手順を説明する。

database.yml

使っている database.yml を示す。

/var/lib/redmine$ cat config/database.yml
# MySQL (default setup).  Versions 4.1 and 5.0 are recommended.
#
# Get the fast C bindings:
#   gem install mysql
#   (on OS X: gem install mysql -- --include=/usr/local/lib)
# And be sure to use new-style password hashing:
#   http://dev.mysql.com/doc/refman/5.0/en/old-client.html

production:
  adapter: mysql
  database: redmine
  host: localhost
  username: redmine
  password: foo
  encoding: utf8

adapter は mysql。database や username、password は自分の環境に合った値に設定されたし。

Backup DB

DB を下手にいじって壊してしまってもいけないので、作業前にはバックアップを取っておこう。

/var/lib/redmine$ /usr/bin/mysqldump -u -p | gzip < redmine_`date +%y_%m_%d`.gz 

MySQL をいじる

ここでは実際に「GitWindows」という Wiki ページを「MsysGitInstall」という名前に変更した場合の作業手順を示す。ちなみに、「GitWindows」という Wiki を「MsysGitInstall」にリネームした後、改めて「GitWindows」という Wiki ページを作成してある。やりたかったのは、「GitWindows」という Wiki が大きくなりすぎたので、一部を「MsysGitInstall」という Wiki に切り出す作業。

次のコマンドを実行して、MySQL が管理している Redmine の DB をいじる。オプションとして与える user, password, host は database.yml の値を使う。

/var/lib/redmine$ mysql --user=redmine --password=foo -h localhost redmine

以降、mysql のプロンプトでの操作になる。

まずはどんな DB があるか確認してみやう。

mysql< show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema | 
| redmine            | 
+--------------------+
2 rows in set (0.00 sec)

redmine という DB があるのが確認できる。これから、この DB をいじっていく。

mysql< use redmine;
Database changed

作業 DB を「redmine」に切り替えたら、どんなテーブルがあるか確認しやう。

mysql< show tables;
+-------------------------------------+
| Tables_in_redmine                   |
+-------------------------------------+
| attachments                         | 
| auth_sources                        | 
| boards                              | 
| changes                             | 
| changesets                          | 
| changesets_issues                   | 
| comments                            | 
| custom_fields                       | 
| custom_fields_projects              | 
| custom_fields_trackers              | 
| custom_values                       | 
| documents                           | 
| enabled_modules                     | 
| enumerations                        | 
| groups_users                        | 
| issue_categories                    | 
| issue_relations                     | 
| issue_statuses                      | 
| issues                              | 
| journal_details                     | 
| journals                            | 
| member_roles                        | 
| members                             | 
| messages                            | 
| news                                | 
| open_id_authentication_associations | 
| open_id_authentication_nonces       | 
| plugin_schema_info                  | 
| projects                            | 
| projects_trackers                   | 
| queries                             | 
| repositories                        | 
| roles                               | 
| schema_migrations                   | 
| settings                            | 
| time_entries                        | 
| tokens                              | 
| trackers                            | 
| user_preferences                    | 
| users                               | 
| versions                            | 
| watchers                            | 
| wiki_content_versions               | 
| wiki_contents                       | 
| wiki_pages                          | 
| wiki_redirects                      | 
| wikis                               | 
| workflows                           | 
+-------------------------------------+
48 rows in set (0.01 sec)

この通り、48 のテーブルが見つかった。wiki の一覧を見るには、wiki_pages テーブルを参照する。全てを select すると量が多くて大変になるだらうから、like 演算子等を使って絞り込みをしやう。ここではタイトルに「GIT」が含まれている Wiki を抽出してみる。

mysql< select * from wiki_pages where title like '%GIT%';
+----+---------+----------------+---------------------+-----------+-----------+
| id | wiki_id | title          | created_on          | protected | parent_id |
+----+---------+----------------+---------------------+-----------+-----------+
| 26 |       2 | GitAdmin       | 2009-08-20 11:19:13 |         0 |         3 | 
| 27 |       2 | GitProxy       | 2009-08-20 11:29:46 |         0 |         3 | 
| 28 |       2 | GitCommitLog   | 2009-08-20 11:38:24 |         0 |         3 | 
| 29 |       2 | GitRepo        | 2009-08-20 11:59:23 |         0 |         3 | 
| 30 |       2 | GitIntro       | 2009-08-20 12:03:18 |         0 |         3 | 
| 39 |       2 | GitWindows     | 2009-10-08 11:14:10 |         0 |         3 | 
| 41 |       2 | GitConfig      | 2009-10-21 11:09:13 |         0 |        30 | 
| 45 |       2 | EclipseGit     | 2009-11-05 14:32:43 |         0 |         3 | 
| 46 |       2 | MsysGitInstall | 2009-11-05 17:31:37 |         0 |        39 | 
+----+---------+----------------+---------------------+-----------+-----------+
9 rows in set (0.00 sec)

この通り、9 つの Wiki が見つかった。ここで、移動元の Wiki「GitWindows」の id が 39 であること、移動先の Wiki「MsysGitInstall」の id が 46 であることをメモしておこう。

次は attachments テーブルを見てみたい。ただこのテーブルの構成が分からない。未知のテーブルに出会ったら desc コマンドでテーブルの詳細を確認する。

mysql< desc attachments;
+----------------+--------------+------+-----+---------+----------------+
| Field          | Type         | Null | Key | Default | Extra          |
+----------------+--------------+------+-----+---------+----------------+
| id             | int(11)      | NO   | PRI | NULL    | auto_increment | 
| container_id   | int(11)      | NO   | MUL | 0       |                | 
| container_type | varchar(30)  | NO   |     |         |                | 
| filename       | varchar(255) | NO   |     |         |                | 
| disk_filename  | varchar(255) | NO   |     |         |                | 
| filesize       | int(11)      | NO   |     | 0       |                | 
| content_type   | varchar(255) | YES  |     |         |                | 
| digest         | varchar(40)  | NO   |     |         |                | 
| downloads      | int(11)      | NO   |     | 0       |                | 
| author_id      | int(11)      | NO   | MUL | 0       |                | 
| created_on     | datetime     | YES  | MUL | NULL    |                | 
| description    | varchar(255) | YES  |     | NULL    |                | 
+----------------+--------------+------+-----+---------+----------------+
12 rows in set (0.01 sec)

12 のカラムがあることが分かった。

各々のカラムの役割を見てみたい。そこで適当なファイルを選んで、カラムと値の対応関係を見てみる。

mysql< select * from attachments where filename like 'msysgit%-01.png';
+----+--------------+----------------+------------------------+-------------------------------------+----------+--------------+----------------------------------+-----------+-----------+---------------------+------------------------------------+
| id | container_id | container_type | filename               | disk_filename                       | filesize | content_type | digest                           | downloads | author_id | created_on          | description                        |
+----+--------------+----------------+------------------------+-------------------------------------+----------+--------------+----------------------------------+-----------+-----------+---------------------+------------------------------------+
| 42 |           39 | WikiPage       | msysgit-install-01.png | 091008113037_msysgit-install-01.png |    22520 | image/png    | af7ca8345cb3477b3ee7c59327918779 |         0 |         3 | 2009-10-08 11:30:37 | MsysGit インストール画面 1         | 
+----+--------------+----------------+------------------------+-------------------------------------+----------+--------------+----------------------------------+-----------+-----------+---------------------+------------------------------------+
1 row in set (0.00 sec)

どうやら、添付ファイルの ID が「id」、そのファイルが添付されている Wiki の ID が「container_id」、そして添付ファイル名が「filename」というカラム名で現されているらしい。

移動させたい添付ファイルは「msysgit-install-*.png」なので、こんな SQL 文を書いてみる。

mysql< select id,container_id,filename from attachments where filename like 'msysgit%';
+----+--------------+------------------------+
| id | container_id | filename               |
+----+--------------+------------------------+
| 42 |           39 | msysgit-install-01.png | 
| 43 |           39 | msysgit-install-02.png | 
| 44 |           39 | msysgit-install-03.png | 
| 45 |           39 | msysgit-install-09.png | 
| 46 |           39 | msysgit-install-04.png | 
| 47 |           39 | msysgit-install-05.png | 
| 48 |           39 | msysgit-install-06.png | 
| 49 |           39 | msysgit-install-07.png | 
| 50 |           39 | msysgit-install-08.png | 
| 55 |           39 | msysgit-install-11.png | 
+----+--------------+------------------------+
10 rows in set (0.00 sec)

この通り、添付ファイルは 39 番の Wiki に貼り付いている。これを 46 番の Wiki へ移動させたい。やるべきことは、SQL で container_id の値を変えるだけ。

mysql< update attachments set container_id = 46 where filename like 'msysgit%';
Query OK, 10 rows affected (0.01 sec)
Rows matched: 10  Changed: 10  Warnings: 0

Query は成功したと言っている。実際に成功したか確かめてみやう。

mysql< select id,container_id,filename from attachments where filename like 'msysgit%';
+----+--------------+------------------------+
| id | container_id | filename               |
+----+--------------+------------------------+
| 42 |           46 | msysgit-install-01.png | 
| 43 |           46 | msysgit-install-02.png | 
| 44 |           46 | msysgit-install-03.png | 
| 45 |           46 | msysgit-install-09.png | 
| 46 |           46 | msysgit-install-04.png | 
| 47 |           46 | msysgit-install-05.png | 
| 48 |           46 | msysgit-install-06.png | 
| 49 |           46 | msysgit-install-07.png | 
| 50 |           46 | msysgit-install-08.png | 
| 55 |           46 | msysgit-install-11.png | 
+----+--------------+------------------------+
10 rows in set (0.00 sec)

見事、添付したファイルが 46 番の Wiki に移った。

後は、ウェブ・ブラウザーを開いて Redmine の中で本当に添付ファイルが移動しているか確認しませう。

おしまい。

2010-10-29

ネットカフェ泊まりで生き抜くための 10 のアドバイス

今年も急に寒くなってきた。今年の寒い時期、ネットカフェに連泊していた頃を思い出す。

仕事や研究が忙しくなって帰宅する時間も惜しい時 (しかし、お役所的な理由で職場・大学で寝取まりが出来ない時)、安価に泊まれるネットカフェは重宝する。ビジネス・ホテルより安く、ネットや雑誌といった情報が手元にあるのがメリット。その代わりデメリットも大きい。本エントリーでは、一週 4 連泊をしなくちゃいけない位いハードなネットカフェ宿泊者向けに (自分の経験を踏まえて) 10 のアドバイスを書いてみる。

1. (重要) マスクは必須

ネットカフェの大抵は室温調節をちゃんとやっている。けれど、湿度調節まで行なっているネットカフェはほとんどない。湿度調節がちゃんと為されていないと、喉を痛める。喉を痛めれば風邪をひきやすくなる。ネットカフェはただでさえ体力の消耗が激しいので、長期利用を考えるなら自分で湿度調節する必要がある。

湿度調節で威力を発揮するのが「マスク」。ここでの目的は、ウィルスから身を守ることではなく、鼻や喉に適度な湿度を与えることなので、「ガーゼマスク」が良い。医療用とか、花粉用とか、超立体とか、さういったマスクは要らない。コンビニで売っている一番安い「ガーゼマスク」が良い。

加えて、ちょっとしたドラッグストアで「ガーゼ」を買っておくことをお勧めする。安いガーゼマスクは、中のガーゼがすぐにへたる。ここで新しくマスクを買うのではなく「ガーゼ」を買う。適当な長さに切って使えば良いと思う。ぼくは思いきって一枚全部を使った。一度ガーゼを洗躍すると、すごいフカフカになってマスクのフィット感が向上した。見た目は酷いけど、ネットカフェの中で使うんだから、誰も見ていない。人の目を気にする必要はない。

2. (重要) 分煙・禁煙をチェック

これは嫌煙家向けの項目。

煙草の臭いはとても嫌なもの。出来ることなら、時前にネットでネットカフェの分煙情報を調べておこう。

  1. 建物自体が分煙されている
  2. フロアーで分煙されている
  3. フロアー内に喫煙ルームと禁煙ルームがある
  4. 分煙されていない

上から下に行くほど、状況が悪くなっていく。ネットカフェに分煙の情報がなくても、ネットカフェのフロアー・マップからある程度分煙に関する情報は得られる。

ところで、1 番目に挙げた「建物自体が分煙」されている物件だけど、非常に少ない。ぼくが知る中では、新宿のアプレシオ新宿ハイジア店が、WEST 館と EAST 館に分かれていて、EAST 館が禁煙になっていたと思う。

3. ブランケットを借りる

冬は寒い。いくらエアコンで調節されているといっても、やはり夜は寒い。ほとんどのネットカフェでブランケットを「無料で!」借りられるので、このサービスは是非活用しやう。

4. ジャンバーを前後逆に着る

ブランケットを借りても、そのブランケットをちゃんと被って寝られなければ意味がない。ところが、ブランケットは布団ではないから、起きたらどこかに行ってたということが良くある。そこでブランケットは毛布代わりに使わない。

少し大き目のジャンパーを用意する。ボワになっているのが好ましい。体を締めつけるタイプはダメ。スルリと腕が入って、包み込むタイプが良い。これを前後逆に着る。すると、寝ている間、絶対に脱げることがない。前後を正しく着て前をしめると、そこはちゃんと服になっているので寝巻きのやうな快適さはない。かといって前を開けると寒い。前後逆だと着苦しい。だから少し大き目のジャンパーを選ぶ。

では、ブランケットはどこに使うか? ぼくはマフラー代わりに使った。徹底的に喉を守る。あと、ちょっと枕っぽくなって良い。

5. 専用靴下を用意する

仕事用の靴下は恰好良いけど、寝る時まで履くのはナンセンス。かといって、靴下を脱いで寝られる程ネットカフェの環境は良くない。そこで専用の靴下を用意する。

一番のポイントは、靴下の折れている部分がなるべくストレートなもの。靴下がストレートでないと、血の流れがおさえられて体が休まらない。寝る時だけで良いので、靴下を替えよう。

この手の靴下は「安眠用の靴下」をスーパーで探せば見つかると思う。下のリンク先は一例。

オーガニックコットン おやすみソックス

6. 椅子はリクライリングを選ぶ

フロア席があればフロア席を取ろう。なければ、リクライニング椅子を備えた個室を取る。リクライニング椅子は、なるべく角度を固定できるものが望ましい。

リクライニング席を取っても、席が後ろまで倒れないことがある。これは、ネットカフェが「寝る」ための施設ではないため。ネットを見たりマンガを読んだりするのに、最低限のスペースしか割かれていないのが、ネットカフェの現状。だけど悲観する前に試して欲しいことがある。椅子を動かして、部屋に対して対角線に置く。すると、縦に椅子を置いているよりも若干スペースを広く使える。リクライニング席も一番深くまで倒せるようになる (かもしれない)。

フロア席があっても狭くて足を伸ばせないとか、リクライニング席で角度が固定できない、なんて場合はリクライニング席の床に寝る手段もある。実はスペースだけで言えば、狭いフロア席よりリクライニング席の方が広い (机と椅子を置かなきゃいけないから)。床が綺麗で、何か敷く物がないと使えない方法だけど一度試してみる価値はある。

上に挙げた手段が全て通じないなら、別のネットカフェを探すことも選択肢の一つ。

7. シャワーに入らない

ネットカフェ生活の最初の方はシャワーはイイ。

でも、もし貴方がネットカフェに何週間も泊まっているのならば、それは相当に仕事・研究が大変なのに違いない。もう体力も限界に近いはず。そんな時にシャワーを浴びると、体の疲れがドッと出てくる。溜めてた疲労が最後の体力を奪う。その日、貴方は仕事など満足に出来ないでせう。

ここまで来ると、本当は休みを取るか、病院に行くのが良い。でも、あと数日だけ、あと一週間だけ。それを乗り越えれば、という状況もあると思う。そういう状況なら、シャワーは浴びないこと。

8. マンガを読まない

人間、不思議なもので体力がギリギリでもマンガを読めてしまう。ジャンプがあった。サンデーがあった。今日は月刊マガジンの発売日か。ネットカフェだから誘惑も多い。でもその誘惑は断ち切ろう。

マンガを読むと、なけなしの体力を使ってしまう。翌日の仕事・研究に影響が出るほど疲れていても、マンガは読めてしまう。だからマンガは手に取ってはいけない。

もしマンガを読むのであれば、朝、起きてから読もう。

9. ラジオ体操をする

ネットカフェ生活が続くと、「体」も限界に近づいて来る。でも、逆説的だけど、そんな時だからこそ体力を付けないといけない。体がもたない。そこで体を動かすことをお勧めする。

ぼくはラジオ体操をやった。

何十年も続いているだけあって、ラジオ体操はよく練られている。基本的に体全体を動かすようになっているし、実はその動きもハードな構成になっている。まじめにラジオ体操に取り組めば、息切れするほど。でも、これで一日、体のキレが良くなる。最初は、順番とか間違えたって構わない。とにかくやってみること。

ネットカフェで寝起きすれば、会社に来るのはほぼ一番乗りに近いはずだから、人の目を気にすることはないでせう。どこか適当に広いスペースを見つけて試してみて欲しい。

10. 今、貴方はエベレストに登っている

ネットカフェ生活が続くと苦しい。ネットカフェに泊まり続けることも辛いけど、その原因 (仕事や研究が山場・火の車・〆切ギリギリ) も辛いと思う。ここで「何で自分だけ」とかネガティブに走らない。

エベレストに登頂したことはあるかしらん? ぼくはない。でも、本で読むだけでその大変さの何十分の一かは想像できる。毎日歩き通しで、シャワーはなく、寝場所はテントの中。日々変わる天候。正しいルートから外れた時の焦り。山頂に辿り着けるのかという不安。注意不足は死との隣合わせ。でも、登頂できれば全てが報われる。

そんなプロジェクトに参加していると思えば、ホラ、少しは気が軽くなりませんか?

変な例えだけど、心をポジティブに持っていかないと、ネットカフェ連泊は耐えられない。

あとがき

当たり前過ぎてアドバイスには書かなかったけど、「ナイトパック」は必須ね。

あと、ネットカフェ生活に一区切りがつく段階で休みを取ることを確約させること。この約束を反故にされると、体じゃなくて心が壊れてくるので、必ず守らせること。そのためには、「自分が無理している」ことを周りにある程度周知させておく必要がある。

ネットカフェ生活を続けることは体力の限り出来ることではあるけれど、「体力に限界が来た時のアフターフォロー」を準備しておく政治力を持つのは非常に難しい。これはネットカフェ生活を始める前からの戦いになる。意外と盲点なのでお気を付けあれ。

Gmail に「アーカイブ」したら次のスレッドを開く Labs 機能追加

Gmail Labs に、「アーカイブ」したら次のスレッドを開く機能が追加された。「Auto-advance」という Labs 機能がそれで、機能を ON にするだけで利用可能になる。

今の Gmail はメールをアーカイブすると「Inbox (受信箱)」に戻る仕様。でも、これだと次々とメールを読みたい時に手間が増えてしょうがない。今回の Auto-advance 機能は、この手間を軽減してくれるもの。

実は、デフォールトの Gmail でも ] キーで「アーカイブして次のスレッドを開く」というショートカットが割り当てられている (2007 年 10 月から使えるやうになっている)。

機能比較

] キーと Auto-advance を比べてみると、次の違いがある。

  • ] はアーカイブ前提。Auto-advance は「アーカイブ」「削除」「ミュート」で動作する
  • ] で次のスレッド、[ で前のスレッドに移る。Auto-advance は Settings ページでアーカイブ後に「次のスレッド」「前のスレッド」「受信箱に戻る」を選択する (デフォールトは次のスレッドに移る)

Gmail Blog では、アーカイブだけでなく削除やミュート機能を使う人達にこの Labs 機能は有用だらうと書いている。] のショートカットを憶えていない人にも需要がありそう。小さな手間をなくしてくれる機能だけど、この Labs 機能はデフォールトで ON にする価値があると思う。

2010-10-27

書評サービス「ブック:)ブック」

AMN が書評ポータル・サイト「ブック:)ブック」をリリースした。

AMN はブロガーと企業を繋ぐことを目的とした会社。ぼくも、何度もブロガー向けイベントに参加させてもらった。その AMN が、どうも「本」とブロガーを繋ぐことも始めたらしい。ブック:)ブックの目的を AMN のお知らせサイトから引用してみる。

無数のブログの中から、自分にあった書評ブログや書評を探し出すのは、結構大変な作業です。

書評を手軽に探し出すためのサイトとして、無数にあるブログ上の書評を集約し、注目の書籍を抽出することができるのが書評ポータル「ブックブック」です。

「ブックブック」では、AMNの会員サービスであるブログクラブに登録している会員のブログ記事をクロールし、Twitterの被リンク数や投票数などによって注目度を計算して、注目の書評ブログ記事や、書評ブログ上で注目の書籍を自動的に抽出しています

実際、使ってみて...

ぼくも ブログクラブ に登録している身であるから、自分の書評が出てくるかと検索をしてみた。例えば、クラシック音楽を楽しく紹介している「ゆらこめ」、ピアニスト辞典とも言える「ピアニストガイド」、ネット系の本で言えば「バイラル・ループ」、「フリー <無料> からお金を生みだす新戦略」、「キーボード配列 QWERTY の謎」、「人は意外に合理的」。どれもぼくのエントリーにはヒットしない。「ゆらこめ」と「ピアニストガイド」なんか検索にヒットすらしなかった。書評を集めるのは結構だけれども、クロールのやり方、アルゴリズムに不安を覚える。

ブック:)ブックで良いな、と思ったのは「漫画・アニメ」のカテゴリーがあるところ (カテゴリーを開くと「漫画・アニメ・BL」と「BL」が追加されているのは攻めか??)。個人的には SF、ファンタジー、ライトノベルのカテゴリーも欲しいところ。

あとがき

書評をブログから集めるアイデアは面白い。同じやうなことを「音楽」評でもやれるんじゃないかとアイデアも膨らむ。願うは、「書評」を探し出すアルゴリズムの洗練。

ブック:)ブックには、投票機能とか Twitter 連携機能とか本エントリーでは取り上げなかった機能も多いけど、まずは「書評」の数を増やして欲しい。

JR の回数券を買ってみた

2 週に一度通院している病院が、隣駅にあるので「回数券」を買ってみた (JR 東日本)。

回数券は、新幹線の切符が買える券買機で買えた。購入手順はこんな感じ。

  1. 回数券購入を選択
  2. 出発駅を選択 (デフォールトでは今居る駅が選択されている)
  3. 目的の駅を選択 (駅名を選択)
  4. お金を入金

これで、11 枚分の回数券が発券された。出発駅と目的駅との往復に使える。値段は 1,300 円。隣駅は 130 円なので 1 枚分得した計算になる。

昔は、小さな切符が綴りで出てきたものだったけど、今の回数券は新幹線の乗車券なんかと同じサイズ。綴りになっていないので、「切り離し無効」とかを気にしなくていいかわりに、ちょっと管理が面倒かも。

以下、回数券の注意点。

  • 回数券は Suica で買えない (クレジット・カードかキャッシュのみ)
  • 回数券には有効期限がある (3 か月)

あとがき

通院は二週に一回なので、一か月に 4 〜 6 枚の回数券を使う。その程度だったら、定期券を買うより安い。有効期限があることと、切符をなくしてしまうことに気を付けさえすれば特に問題はなさそう。最近、お財布が厳しいので、少しでも節約、節約。

尚、本エントリーを買くに当たっては、以下のエントリーも参考にした。

2010-10-26

Amazon で水を箱買いした

Amazon で水を買った。サントリーから出ている「南アルプスの天然水」 2L ペットボトル 9 本入り。お値段 989 円。一本当たり 110 円弱。

(お徳用ボックス) サントリー 天然水(南アルプス) 2L×9本

(お徳用ボックス) サントリー 天然水(南アルプス) 2L×9本
(お徳用ボックス) アルカリイオンの水 ペット 2L×6本 (お徳用ボックス) アサヒ 六甲のおいしい水 2.0L×6本 北アルプス穂高の名水 2L*6本 (お徳用ボックス) サントリー 伊右衛門 2L×6本 (お徳用ボックス) 黒松内 水彩の森 2L×6本
by G-Tools

Amazon で買うメリット

ペットボトル入りの水は、どこでも手に入る。スーパー、コンビニ、ディスカウント・ショップ。小さなペットボトルなら自販機でも売っている。ぼくがよく利用するのはコンビニ。車や自転車といった移動手段を持っていないのと、家からの距離が近いのが決め手。2L の「南アルプスの水」か「六甲のおいしい水」を買っていた。一本、179 円。数日で飲みほして、ジャンプやマガジンと一緒に水を買う。それが日常だった。

お徳用の箱入りを買いたくなったのは、休職がきっかけ。

今まで会社に行っている間は、ティーパックにお湯で水分保給していた。金曜日は、自販機のコーヒーを買うのが楽しみだった。自分にご褒美をあげたい時は、コカ・コーラを買っていた。会社に居る時間が短いので、家で飲む水の量は少なかった。

ところが、休職になって、家に居る時間が増えた。当然、飲む水の量も多くなる。一本 179 円という負担は大きい。ディスカウント・ショップまで足を伸ばせば、箱入りの安い水が手に入ることは知っている。コンビニと同じペットボトルが、一本当たり 100 円弱で買える。けれど、うちの周りのディスカウント・ショップは遠い。自転車があればさして苦労もないけれど、歩いて 2L x 6 本 = 12 kg の箱を持って帰るには辛い。

こういう人間にとって Amazon はとても助かる。買った商品を家まで配送してくれるから。買いためたペットボトルが一、二本になったら注文する。すると、箱に入ったペットボトルが届く。お徳用のボックスは、6 本入り、9 本入り、6 本入り x2 箱。色々あるけれど、「重さ」を気にする必要はない。玄関の前まで「運ぶ」のは自分じゃないから。

もちろん、ディスカウント・ショップで買うより少し高い。10 円ちょっと? でもコンビニで買うより、随分安い。車のガソリン代や、自転車を新調するお金や、自分の足で 10 kg を越える箱を持って帰るのと比べてみて欲しい。10 円ちょっとの値段の違いは、十分元を取れる。少くともぼくはそう考える。

ぼくは今回は「南アルプスの天然水」を買ったけど、他にも色々種類があるので、好みのお水をどうぞ。

2010-10-25

Amazon で予約中の激安クラシック BOX を見つけたら即断即決で買うべし

今日、過去記事に追記をしたのだが Amazon で予約中だった商品が値上がりした。その商品はハイフェッツのオリジナル・ジャケット・コレクション全集 (103CD の大ボックス) で、ぼくがエントリーを書いた 10/20 時点では 18,080 円だったのに今日 10/25 時点では 43,163 円となっている。

同じやうなことは過去にもあって、Bernstein Symphony Edition (60CD のボックス) をぼくが 8/26 に予約した時点では 7,303 円だったのに現在は 9,089 円になっている。

Amazon の予約商品は値上がりすることがある

Amazon は予約後に商品の値段が (何らかの理由で) 下がった場合、その下がった値段で発売を確約するサービスを行なっている。これは、Amazon を良く使っている人なら知っている事実だと思うけど、実はその逆もあるというお話。予約後に商品の値段が上がることがある。無論、予約した人間は「最限金額」が保証されているから、予約した時の価格で購入できる。

痛いのは、買おうか買うまいか悩んで予約していなかった人達。価格が上がってから予約しても、前の安い価格では購入できない。

だから、もし、これはと思うクラシック音楽のボックスが「予約中」になっていたら、すぐに予約すること。

Amazon はこの手のクラシック音楽のボックスに対して情報が少ない。それを不安に思う人もあると思う。そういう場合は、HMVTower Records で同様の商品を検索して探してみる。大きなボックスならまず HMVTower Records でも予約が始まっている (ただし、最安値の Amazon ほど安くはない)。彼ら解説を参考にしよう。

2010-10-24

「日本語入力 T-Code のススメ」〜 Google 日本語入力 TechTalk ライトニングトーク

2010-10-23 (土) に、Google が主催する「Google 日本語入力 TechTalk」に参加した。

そして、飛び入りでライトニング・トークをやってきた。5 分ほどのライトニング・トークだったけど、発表資料と質問の答えをエントリーにしておく。

T-Code って何?

T-Code は、いきなり漢字を直接入力する日本語入力。漢字変換の必要がない。

その入力する様はまるで「ルパン三世のタイトル入力」のように見える。

補足説明

ぼくらは英語入力をする時、26 のアルファベットと 10 の数字、あと少しの記号の位置を記憶して入力を行なっている。つまり、「a」という文字を打つには「a」というキーがどこにあるかを憶えていて、その対応関係を思い出して「入力」を行なっている (タッチタイプするほとんどの人は、もう反射の域に達しているでせう)。

キーの数は 40 ちょっと (26 + 10 + 記号が少し)。余分な記号は削って、ここではキーの数は 40 とする。

さて、ここで発想の転換。キーを 2 打うつ組み合わせは、40 x 40 = 1,600。この 1600 の組み合わせ一つ一つに文字 (漢字) を割り当てて、その組み合わせを全部覚えてしまったらいいんじゃないか? これが T-Code。

実際は、ユーザー用領域や特殊キーがあって、割り当てられている漢字は 1200 程。

ぼくはそのうち、約 800 を憶えているが、自分のブログでチェックすると 95% の文字はこの 800 字だけで入力できている。

では残り 5% はどうするか? T-Code は 2 つの方式を用意している。部首合成変換と交ぜ書き変換の二つ。

合成

例えば、「仏」という文字を入力したいとする。

この場合、「jf」と入力してから「イ」と「ム」を入力する。すると「イ」と「ム」が合成されて「仏」という文字になる。

「jf」の 2 ストロークは、部首合成変換を始めるプレフィックス。読みが分からなくても、似た漢字を知っていたら「合成」で漢字を作れてしまうのが利点。

交ぜ書き変換

一つ有名な文章を入力しませう。

記者が汽車で貴社に帰社した

この入力は次のように行なう。

記者がき車 fj でき社 fj に帰社した

「fj」の 2 ストロークで交ぜ書き入力を行なう。注目すべきは、この時、変換候補が一つも現れないこと。例えば、「き車」という入力に対して結果は「汽車」しかないので変換候補は一つも現れない。

「貴社」と「帰社」の場合は少し複雑。普通に「き社」を変換しようとすると、「記者」や「汽車」は変換候補に現れないけれど「貴社」と「帰社」は変換候補に現れる。ユーザーはたった 2 つの候補の中から、自分が入力したい漢字を選ぶ。ただ、幸いなことにぼくは「帰」という漢字を憶えていた。T-Code には、憶えた漢字を「交ぜ書き変換辞書」から削除する機能がある。そこでぼくは「帰」という漢字を辞書から削除した。そういうわけで、「き社」の入力に対して変換候補は一つだけ「貴社」に絞られる。一つだけなので変換候補ウィンドウは現れなかった。

このように、変換候補の数を減らしていけるのが交ぜ書き変換の良いところ。

質問・その他

T-Code を始めたきっかけは?

1998 年頃か? 当時、ぼくは ATOK を使っていた。その頃の ATOK はこんな変換をした (口語モードにしたのに!!)

○○なんだ世

この語尾を修正するのが、たまらなく苦痛だった。そこで出会ったのが SKK だった。

極めるととともに、小指がつった。

他の入力方式を探した。そして T-Code に出会った。

T-Code を選んだ理由は?

T-Code のやうに直接漢字を入力できる方式は T-Code だけではない。他にも数多くある。例えば、ひらがな入力だけは普通と同じにして、余った部分に漢字を割り当てる方式など。そう。誰でも考える。漢字直接入力方式は敷居が高すぎる。

その中にあって、T-Code は一つ異色だった。

T-Code は東京大学理学部情報科学科山田研究室で開発された。新聞のデータを集め単語の出現確率を求めた。(どうやってか知らないけれど) 2 打鍵入力する際の効率表を得た。その 2 つを組み合わせて T-Code の配列は決まった。

元は (新聞社なんかの) コピーライター向けの研究だったという。記者の手書きの原稿を電子データにする職業ね。海外のコピーライターは、仕事に携わる前に 400 時間の研修時間を持つ。ならば、日本でも同じように研修時間を取るべきである。T-Code はそういうプロのための研究であり、入力手法だった。だから、素人が手を出すなんて想定していなかった。ある意味、ストイックな入力方式だった。

そのストイックさに惚れた。

憶えるのは大変ではないか?

Emacs 用の T-Code パッケージには、EELLL という練習用プログラムが付いてくる。

まず、3 単語「の」と「が」と「、」の入力位置が表示され、練習用文章が表示される。これをクリアすると、次のレッスンに進むかと聞かれる。十分、入力位置を憶えたと思ったら次のレッスンに進む。新しい単語 (と古い単語) による練習用文章が現れる。こうやって、まずはひらがなを覚える。

レッスンを続ければ全ての漢字を憶えることができるけど、一まず「ひらがな」まで憶えれば十分。「ひらがな→カタカナ」変換と「交ぜ書き変換」を使って最低限の入力は出来るやうになる。

後は、少しずつ良く使う漢字の位置を憶えていく。漢字の位置を憶えると、交ぜ書き変換辞書から (手動で) 漢字を削除できるので、交ぜ書き変換の変換候補が少なくなって変換効率が上がる。すると、楽しくなってどんどん漢字を憶えたくなる。

T-Code は速いのか?

十分に訓練された人間が、新聞のコピーライトに使う分には最強だと思う。しかし、そんな人間が一体何人いるかしらん?

もう少し現実的に、一般人がコピーライトする場合。対象が新聞なら最速に近いと思う。ただし、対象が小説だと疑問。元データが「新聞」なので、新聞によく現れる「殺(人事件)」「(東)芝」「渋(谷)」といった文字が比較的打ち易い場所に配置されている。一方、新聞では絶対に現れない一人称「僕」は T-Code のコード表に存在すらしない。交ぜ書き変換で入力するしかない。それでも、単語頻度が大きく変わることはないので、十分速いと思う。

更につっこんで、コピーライトの需要はあるのか? ほとんどの人は自分で考えた文章を入力するのに「日本語入力」を使うでせう。その場合、タイピング・スピードだけなら Google 日本語入力を始めとした「日本語変換系」の方が速い。なんせ、どんな漢字を打つか考えないで良いんだから。だけど、そこから、変換候補を選ぶのに時間がかかる。頭も使う。一方、T-Code は入力時に「どの漢字を使うか」も一緒に考えて入力する。これはノートに文字を書くのと同じ感覚。特に T-Code を使い始めると、「日本語をちゃんと正確に入力したい」という誘惑が強くなる。「遇う」と「遭う」は使い分けたい。「会う」と「逢う」も使い分けたい。といった感じ。ここら辺で時間をロスしているやうに思う。

少し話しを極端にして、Google 日本語入力と T-Code を両方「極めた」としませう。この場合、どちらが文章を書くのが早いか? きっとスピードは同じ。入力速度 (手の早さ) よりも、文章を考える時間 (頭の早さ) の方がボトルネックになる。どんなに速く入力できる人間も、自分が考えるより速く入力は出来ない。

話しを戻して、現実的な話。ブログなんかを書くんなら、T-Code より Google 日本語入力の方が速いかもしれない。ただし代償はある。「変換候補を選ぶ」という作業。これはかなり頭を使う。T-Code を使っている時は交ぜ書き変換を使うにしても「変換候補が少なくて楽だな」と感じたことはなかったのだけど、ATOK に戻ったとたん「変換候補を選ぶ」だけでえらく疲れた。一度、T-Code の「直接入力」に慣れると、変換の煩わしさには堪え難い。

まとめると、(ある程度の域に達したことを前提に) 普通に文章を書くのであれば T-Code も Google 日本語入力も大きな差はない。ただし、T-Code の方が「楽」。

入力スピード・蛇足

入力スピードに興味のある方は、日本語入力だけでなく英語配列においても関心があることと思う。そういう方は、安岡氏の「キーボード配列 QWERTY の謎」がお勧め。詳細はレビュー記事をどうぞ。

開発は止まっているか?

T-Code の開発ページはこちら。

Unicode 化されていない Emacs で動く tc-2.3.1 が公開中。

ただ、ここ一、二年忙しくって体を壊した

当てなきゃいけない色んなパッチがあるし、Unicode 版 Emacs で動くかテストもしなくちゃいけない。課題は山積みだけど、もう少しお待ち下さい。

T-Code のローマ字テーブルファイルはまだかっ

ローマ字テーブルはインポート・エクスポートできるみたいなので、t-codeのローマ字テーブルファイルはまだかっ!!

Twitter より引用

えっと。頑張る。

あとがき

今回、Google 日本語入力 TechTalk に申し込んだ時は、まさか自分が LT をすることになるなんて思ってもみなかった。それが場の勢いに乗せられて、飛び入り参加。実は初 LT。

資料の用意もないし、講演は聞かなくちゃいけないし、でも話す内容はまとめなきゃだし。もう大変。そして、たった四行のプレゼン資料が出来上がった。時間配分も計からずに、LT 本番に突入。でも、何かウケが取れてたようなので良かった。時間ピッタリ (?) だったのは奇跡だね。

懇親会では三人の方から質問を受けることができて感無量。

それから、MacBook 用に DVI-D-sub 変換アダプタを買ったなんてエントリーを書いておきながら、持っていかなかった自分を反省。いや、まさか LT するなんて自分ですら知らなかったから。。。ええ、人生何が起きるか分からないので、まさかの準備はしておくべきですね。変換アダプターを貸して下さった方、直接お礼を言う機会がありませんでしたが、ありがとうございます。

2010-10-23

Gmail の連絡先に郵便番号を入れる方法

Gmail の連絡先 (Contacts) には、「郵便番号」を入力する項目がない。これは、Gmail の連絡先がフリガナ対応した時でも改善されなかった。

もちろん、メモ欄 (大きくなって使い易くなったね) や Custom 項目を使って郵便番号を入力するのも良い。でも、郵便番号は住所とセットになっているんだから、できれば「Address」(住所) の項目欄に一緒に入れたい。

(例) 135-0063 東京都江東区有明 3-11-1

でも、郵便番号を一緒に入れると今度は Google Maps へのリンク機能が働かなくなってしまう (ちなみに上の例は東京ビッグサイトの住所)。これはこれで困る。

解決方法

郵便番号は住所の最後に書く。上の例を直すとしたら、かうなる。

(例) 東京都江東区有明 3-11-1, 135-0063

これで Google Maps へのリンクも使えるやうになった。

ちなみに、都道府村や市町村をカンマ区切りにして後ろに持ってくることもできる。

(例 1) 江東区有明 3-11-1, 東京都, 135-0063
(例 2) 有明 3-11-1, 江東区, 東京都, 135-0063

国名は郵便番号の後ろに入れても OK。

(例) 有明 3-11-1, 江東区, 東京都, 135-0063, 日本

カンマを改行に変えても問題なし。

有明 3-11-1
江東区
東京都
135-0063, 日本

あれ? これはどこかで見たことのある書式だねぇ。そう。欧米の住所の書き方と同じ。

1600 Pennsylvania Ave NW
Washington, DC
20500-0004, US

Gmail は最初から欧米書式で郵便番号をサポートしていた、というオチ。この機能は、フリガナがサポートする前から使えていた。

あとがき

Gmail の Address 欄に郵便番号を入れる方法は分かったのだけど、ビルやアパート名を入力する方法が分からない。ビル名を欧米書式で書くと Google Maps へのリンクが使えなくなるし、Google Maps でよくやるやうに住所の後ろに括弧でビル名を書いてもダメ。誰か方法を知ってたら教えて下さい。

iPhone・iPad 用手袋「iTouch Gloves」

Touch Lab さん経由で知ったガジェット。iTouch Gloves。手袋を着けたまま、iPhone, iPad, HTC-03A 等々「静電型タッチパネル」を操作できる優れ物。

iPhone etc. をお持ちの方はご存じの通り、手袋を付けたままタッチパネル操作ができない。というのも、これらのデバイスは「静電型タッチパネル」を利用してるから。「静電型タッチパネル」は「人間の持つ微弱な電気」を感知して、どこをタッチしているか判定している。そこに手袋を付けると、「人間の持つ微弱な電気」が伝わらないものだから、iPhone etc. は何も反応しない。

今まで、この対策を打った手袋はいくつかあった。指先に金属の玉をくっつけたり、iPhone 操作時に指先をパッと出せるようにしたり。。。でも、iTouch Gloves はもっとスマートな方法を取った。特殊な糸を編みこんで、電気を通せるようにしたらしい。

この iTouch Gloves を着けて iPhone を操作している動作が本家ページにある。手袋を着けているとは思えない反応の良さ。どうせなら、YouTube に動画をアップしてくれれば良いのにね。

iTouch Gloves の購入

iTouch Gloves は、3 色 (black, blue, ping) でサイズは一種類のみ。材質はアクリル 95% にポリウレタン 5%。現在のところ、取り扱い店舗は Amazon だけのもよう (順次、増やしていくものと思われる)。

発売日は 11 月上旬を予定。Amazon では現在予約受付中。価格は 1,890 円。Amazon プライム対象商品でないので、Amazon プライムに入ってる人はご注意を。

iTouch Gloves アイタッチグローブ

B0046S9VTS


Amazonで詳しく見る
by G-Tools

2010-10-21

iPhone とツイッターで会社は儲かる (山本 敏行)

AMN のキャンペーンで頂いた一冊。感想エントリーを書いたものと思っていたけれど、どうやら書きそびれていたようなのでここに書く。

iPhoneとツイッターで会社は儲かる (マイコミ新書)
山本 敏行

4839934444
毎日コミュニケーションズ 2010-02-23
売り上げランキング : 6701
Amazonで詳しく見る
by G-Tools

iPhone とツイッターで会社は儲かる

本書の作者は山本敏行氏。EC Studio の社長。EC Studio は、iPhone と Twitter の全社導入を行なったことで注目を浴びた会社。本業は中小企業相手に、経営の IT 化をすること。本書は、EC Studio での事例から iPhone と Twitter を使うことのメリットを説く。また、Twitter の使い方について下心があると (PR 目的とかね) 失敗すると警鐘を鳴らしている。

目次は以下の通り:

  1. ツイッターを会社で導入する目的とは
  2. ツイッターを全社導入して起きたこと
  3. ツイッターのメリット・デメリット
  4. アイフォーンとツイッターが会社にもたらすもの
  5. グーグル・アップスとアイフォーン
  6. コミュニケーションのクラウド化で会社は儲かる

前半が Twitter に重き置いているのに対して、iPhone への重みが軽い。後半はむしろ、Google Apps (Google のグループ・ウェア) やクラウドに話が移っている。目次において iPhone の重みが軽いのは、Twitter が iPhone と一緒に使われてこそ威力を発揮するツールであるからでせう。つまり、前半は Twitter と iPhone の話。後半はクラウドの話だと思えばいい。

読者の対象は誰だらう。Twitter を使いこなしている人ではさそう。書いてあることは、Twitter をやっていて「Twitter 便利だ」と感じることをまとめてあるだけ。ただ、そんな人達も Twitter で何が面白いの? Twitter は何か役に立つの? と問われると言葉に窮する。Twitter の難しいところは、便利と感じこそすれ、体験しないことには伝わらない。そう、とても言語化が難しい。そんな時、この一冊を渡すと良さそう。何といっても、十分に言語化された実例集だから。また、Twitter に興味を持っているけど... という人にもお勧め。

更に踏みこんで、会社の中で使うとどうなる? という問いにも答えられる。Twitter の利点は、プライベートだろうと会社の中だろうとそれほど大きな違いはないから。

「会社が儲かる」なんてのはハッタリ。社員の間でコミュニケーションが円滑に進めば、無駄も減るし、アイデアも沢山生まれる。自然と会社なんて儲かっていく。たまたま、そのツールとして「今」見合っているのが Twitter と iPhone (もしくは Android) ということ。

後半は Twitter の話から免れて、Google Apps とクラウドの話になる。これも社員間のコミュニケーション円滑ツール。上手く使えば、データの保存・検索も簡便になる。必要な情報がスムーズに流れる。更にスマートフォンとの連携が進めば、社外においても仕事ができる。外回りの人間には言うに及ばず、自宅作業や SOHO への応用も可能。

問題は、世にグループ・ウェアは数あれど、そこまで活用しきれていないこと。絵に描いたもちになっているグループウェアの何と多いことか。Google Apps を始めとした「クラウド」系サービスが、iPhone や Android と手を組むことで、この閉塞状態から一歩抜きん出ようというのが本書後半の狙いなんでせう。

本書の読者層

もう一度、誰を本書の読者としているかまとめてみる。

  1. Twitter の面白さを知ってみたいと思っている人
  2. 小回りの効く会社で、社内コミュニケーションを向上させたいと願っている人

全てがこの本の通りに上手くいくかどうか分からないけれど、一つ Twitter ユーザーとして言えることがある。Twitter はメールとも、ウェブページとも、ブログとも違う。全く新しいコミュニケーションのツールだと言うこと。少くともそこら辺が分かって、「Twitter やってみやうかな?」と思ってもらえればこの本の目的は 8 割達成しているんじゃないかな。

Apple イベント「Back to the Mac」開催

Apple のイベント「Back to the Mac」が 2010-10-21 午前 2 時 (日本時間) から開催された。

主な話題は 3 つ。

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

iLife 11

まず最初にお断り。ぼくは iLife の熱心な利用者でないので、理解しきれていないところがある。所々、端しょっているので、ご容赦を。

  • iLife 11 は本日リリース
  • 新しい Mac にはインストール済
  • 単体価格は $49

iLife からは iPhoto, iMovie そして Garageband の新機能を説明した。

iPhoto

Mac の画像管理ソフト。新機能は以下の通り。

  • 新しいフルスクリーン・モード
  • Facebook との連携強化
  • メールで写真を送る機能
  • 新しいスライド・ショー (iPad 風?)
  • Flickr からの写真取り込み
  • フォトブックの作成機能の強化
  • カード作成機能

カード作成では、レタープレス・カード (紙をでこぼこにして模様にするやつね) も作成可能になったとか。

iMovie

Mac の動画作成ツール。動画を自作することのないぼくとしては、使ったことのないアプリなのだけど、今回のバージョン・アップで映画の予告編風な動画作成が可能になったとのこと。詳細は下記の通り。

  • オーディオ編集機能 (音声のセグメントを指定してレベルやフェードなどを調節可能)
  • 顔認識機能 (iPhoto の技術を拡張利用)
  • 15 種類の映画予告編 (Trailer) テーマが追加
  • 動画に写真を挟み込む機能

予告編テーマと写真を動画に入れる機能を組み合わせると、映画の予告編のやうになるという。これは、ちょっと使ってみたい。

Garageband

音楽を作成するアプリ。iMovie と違い、ぼくはこのアプリを一度も開いたことがない。間違いがあったらごめんなさい。新機能は以下の通り。

  • Flex Time (音のタイミングを合わせてくれる)
  • Groove Matching (自動で動作する)
  • ピアノとギターのレッスン (どう使うんだろ?)
  • ギターのアンプとエフェクトが増えた

MacOS X Lion

新 Mac OS X の名称は「Lion (ライオン)」。リリースは 2011 年夏を予定。

MacOS X をベースにして iOS が生まれ新機能が追加されてきた。Lion では、iOS で培われた技術を MacOS X に持ち込むという。

今回はプレビューとして「Mission Control」機能について話してくれた。また、Lion 以前にリリースされる機能 (FaceTime と Mac App Store) の話もあった。

Lion 概略

おそらく 2011 年にもっと詳しい Lion の機能説明イベントがあると思われる。今回発表されるのは、新機能の一部と思ってよいでせう。

  • マルチタッチ・ジェスチャー (画面がタッチパネルになるわけではない)
  • Mission Control (後述)
  • アプリのホーム画面
  • アプリのフルスクリーン化
  • 自動保存機能
  • アプリの自動レジューム機能
Mission Control

Expose, Dashboard, Spaces, フルスクリーン・アプリを統合する機能。下から Dashboard、Expose、フルスクリーン・アプリのサムネイルが並ぶ (Dashboard、フルスクリーン・アプリのサムネイルは各々一行分のスペース。メインは Expose という感じかな?)。フルスクリーン・アプリとホーム、デスクトップの間はお互いに行き来できる。

Mission Control の機能の一部なのかそうでないのか分からないけど、「アプリのホーム画面」機能も追加された。インストールしたアプリを iOS のやうに一覧表示できる。もちろん iPhone 4 みたくフォルダーも作成可能。

Mac App Store

iOS の App Store の Mac 版。Snow Leopard で利用可能。90 日以内にローンチ。利用感は iOS とほとんど同じ。アプリのページには、アプリの説明・スクリーンショト・レビューがつく。主な特徴は以下の通り。

  • 一箇所でアプリの検索ができる
  • フリーのアプリと有料のアプリがある
  • ワン・クリックでダウンロード可能
  • 自動インストール & 自動アップデート
  • アプリは全ての (あなたの) Mac マシンで利用可能

例えば iPhone4 でアプリを一つ買うと、そのアプリは他の iPhone 3G や iPad にもインストール可能になる。これは iOS アプリの良い点の一つ。有料アプリであっても、この原則は変わらない。Mac App Store はそのやり方をそのまま踏襲したものと思われる。複数の Mac マシン (iMac, MacBook [Pro,Air], Mac Mini) を持っていても、どれかの Mac マシンでアプリを購入すると、他のマシンでも使えるやうになる。何気にデスクトップ系 OS では画期的なことを Apple はやってきた!!

FaceTime

iPhone4 でおなじみの FaceTime。ビデオ・チャットができるというあれ。

今まで FaceTime は iPhone4 同士でしか行なうことができなかった。だけどその対象デバイスが広がる。FaceTime が Mac に対応する。iPhone4 から Mac へ。また Mac から iPhone4 へ FaceTime でビデオ・チャットが可能になる。

この FaceTime for Mac 機能は今日から利用可能。

New MacBook Air

スティーブ・ジョブスの One more thing が出た!! 新しい MacBook Air。発売は今日から。しかも、13.3 インチ版と 11.6 インチ版の二機種が発売される。

新しい MacBook Air は HDD を廃し SDD のみ。より薄くなって、最厚部で 0.68 インチ (1.73 cm)、最薄部で 0.11 インチ (0.28 cm)。CPU には Core 2 Duo を採用。GPU は NVIDIA GeForce 320M。メモリーはデフォールトで 2 GB、最大 4 GB。他、802.11n 対応、USB 2.0 ポートが 2 つ (13.3 インチ・モデルのみ?)、FaceTime 用カメラ内蔵、ステレオ・スピーカー、マイク付。

以下、13.3 インチ版と 11.6 インチ版の違いをテーブルにまとめた。

13.3 インチ版11.6 インチ版
価格148,800 円 (1.86GHz, 256GB)
118,800 円 (1.86GHz, 128GB)
108,800 円 (1.4GHz, 128GB)
88,800 円 (1.4GHz, 64GB)
CPU1.86/2.13 GHz1.4/1.6 GHz
SDD128/256 GB64/128 GB
画面1440 x 9001336 x 768
重さ1.32 kg1.06 kg
バッテリー (WiFi)最大 7 時間最大 5 時間
バッテリー (スタンバイ)30 日30 日

あとがき

次の MacOS X が出たら、実家の PC を Mac に代えようと思っていたのだけど、予定が狂った。MacBook Air はとても魅力的で、価格も手が出せそうなので心が揺らぐ。ある程度予想していたこととはいえ、今回のイベントはグッとくるものがあった。あとやっぱり、One more thing があると、楽しさが倍増するね。

2010-10-19

バイラル・ループ (アダム・ペネンバーグ)

AMN のキャンペーンで COURRiER Japon 10 月号と「バイラル・ループ」を献本頂いた。COURRiER Japon の感想は過去エントリーをどうぞ。本エントリーでは、「バイラル・ループ」の感想を書く。

作者 Adam Penenberg

作者のアダム・ペネンバーグとは、一体どんな人だらう。その答えは「訳者あとがき」にあった。映画「ニュースの天才」(Shattered Glass: 2003) をご存じかしらん? その中で「不正」を暴いた人こそ、アダム・ペネンバーグその人だった。

ニュースの天才 [DVD]
ニュースの天才 [DVD]

少し話が逸れるけど、「ニュースの天才」の話をしませう (注: ネタバレを含む)。

「ニュースの天才」は 1998 年に実際に起きた事件を、スター・ウォーズのアナキン・スカイウォーカー役で有名になったヘイデン・クリステンセンが主演で映画化されたノンフィクション映画。

あらすじ

アメリカで最も権威のある政治雑誌とされる「The New Republic」。そのスタッフ・ライターにスティーブン・グラスがいる。彼は何十本ものスクープを連発した。しかしある日、「Forbes」誌の記者が彼の記事に疑惑を抱く。この記事は本当か? 裏付けは正しいのか? 調査、取材、事実関係の整理。彼はついにその記事が捏造であると確信を持つ。そして考察。「果たして捏造はこの一本だけだろうか?」。再び調査、取材、事実関係の整理。。。結論。グラス氏の記事で「捏造」は一本だけではない。フォーブス誌の追求を受けて、ニュー・パブリック誌自身もグラスの記事の自己検証を始める。そしてグラスの書いたスクープのうち 20 本以上が捏造であったことが判明する。

アダム・L・ペネンバーグ

この事件で、グラスの記事に疑惑を抱き調査を行なったフォーブス誌の記者こそが、本書「バイラル・ループ」の作者アダム・L・ペネンバーグ。その調査力と洞察力は半端ない。元が記者なだけあって構成力も素晴らしい。各章が見事に絡み合って、各事例を紹介する構成は思わず引き込まれる。

バイラル・ループ

閑話休題。バイラル・ループの話に戻ろう。

バイラル・ループ あっという間の急成長にはワケがある
アダム・ペネンバーグ 中山 宥

4062162687
講談社 2010-09-25
売り上げランキング : 3813
Amazonで詳しく見る
by G-Tools

Viral Loop (バイラル・ループ)。ウィールス (Virus) が感染するかの様に「あっという間に急成長」することから名付けられた用語。バイラル・ループの理論は簡単。友達が友達を誘う。誘う友人の数と勧誘成功率をかけたものをバイラル係数と呼び、バイラル係数が 1 以上だとバイラル・ループが発生する。

難しいのは、どうやってバイラル係数を 1 以上にするサービスを作り上げるか?

本書は、バイラル係数を 1 以上にしてバイラル・ループを引き起こした「実例」を紹介し、彼らが成功したエピソードを紐解く。この実例の中には、ネットのサービス以外の例も含まれているのだから面白い。バイラル・ループが取り上げた実例は次の通り:

  1. プロローグ: HOT or NOT!
  2. 序章: オバマ大統領の大統領選
  3. 第 1 章: タッパーウェア
  4. 第 2 章: ウェブ・ブラウザー (MosaicNetscape)
  5. 第 3 章: Ning
  6. 第 4 章: Hotmail (現在は Microsoft に買収されて Windows Live メールの一部になった)
  7. 第 5 章: デジタル映画
  8. 第 6 章: メントスとコカ・コーラ
  9. 第 7 章: eBay
  10. 第 8 章: PayPal
  11. 第 9 章: Flickr, MySpace, YouTube
  12. 第 10 章: Bebo (AOL に買収されてサービスは瀕死な SNS)
  13. 第 11 章: Facebook
  14. 第 12 章: Goole Adwords, Google AdSense

いくつか消えてしまったサービスもある。それは買収先が舵取り失敗したからであって、本書は買収されるまでのサクセス・ストーリーをつまびやかにしているのでご安心を。また、本当にバイラル・ループに乗り損ねた例も載せている。「あそこでこのサービスを止めなかったのが敗因だった」との弁を聞けるのも良い。そう、成功例だけで塗りつぶしていないのが本書の特徴の一つと言える。

例えば、第 6 章でメントス社がすぐにバイラル・ループに乗って売り上げを伸ばしたのに対して、コカ・コーラ社の反応が遅れた点などは良い比較例で面白い。

また、各章独立しているものの、前の章の人物が係わる事例を紹介しているのも面白い。一番の例は、第 7 章の eBay と第 8 章の PayPal。2 つのサービスは別々のバイラル・ループを作り上げ、サービスを大きくしていったが、(ご存じの通り) PayPal は eBay に買収される。PayPal 買収劇に、第 7 章で eBay を作り上げたオミダミアが現れないのが面白い。そこには第 7 章で eBay に呼ばれたメグ・ホイットマンが (強敵として) 現れる。

第 1 章のタッパーウェアのように、ネットのない時代でもバイラル・ループが起きていた事例は興味深い。しかし、本書の作者ペネンバーグの筆の上手いところは、第 4 章の Hotmail で投資家のドレイパーが「タッパーウェア」の話を思い出し、Hotmail をバイラル・ループに乗せるアイデアを持ち出すところ。よくこんなことを調べたものだと驚くと同時に、昔のエピソードが絡み合う面白さを楽しめる。

こんな面白さが本書にはちりばめられている。アンドリーセンは第 2 章で Mosaic と Netscape を作った後、第 3 章で Ning を作る。第 8 章で PayPal を作ったレブチンは、(ライバルとして) 第 11 章でスライド社を作る。といった具合。

あとがき

「バイラル・ループ」は三つの点で楽しめる。まず第一にバイラル・ループを理解する上で重要な事例集であり、第二に失敗例も盛り込んだ反面教師。第三にエピソードがすこしずつ他のエピソードに絡むノンフィクションゆえの物語的な面白さ。特に第三の点に関しては、作者アダム・ペネンバーグの腕が鳴っている。

COURRiER Japon 10 月号を読んだ

AMN のキャンペーンで、COURRiER Japon 10 月号と「バイラル・ループ」を献本頂いた。丁度この時期、最も体調を崩していたので、読み終わるのがこんなに遅くなってしまった。遅ればせながら、レビューを書く (バイラル・ループについては次エントリーにて)。

概要

COURRiER Japon は日本の月刊誌。定価 780 円。毎月 25 日発売。

COURRiER Japon

「クーリエ・ジャポン (COURRiER Japon)」、「日本」が「Japan」ではなく「Japon」と表記されていることから分かるやうに英語圏の雑誌ではない。もとになっているのは、フランスの週刊誌「クーリエ・アンテルナショナル (Courrier international)」。クーリエ・ジャポンはこの「クーリエ・アンテルナショナル」と提携して記事を日本向けに翻訳・編集している。また、一部の記事はクーリエ・ジャポン編集部オリジナルの寄稿文だったりする。

「クーリエ・アンテルナショナル」は 1990 年創刊。フランスの国際ニュース週刊誌として有名らしい。同誌の編集方針は世界 1500 を越えるメディアの中から記事を選んで、一つの雑誌として編纂し直すこと。この編纂能力の高さが群を抜いている (日本語版とオリジナル・フランス版でどの程度「編纂」に差があるのか分からないけれど)。

例えば、今回献本してもらった 10 月号の特集は「"知の世界標準" が 1 日で分かる! 最強の講師陣に学ぶ『世界一の集中講義』」だった。その内容は以下の通り:

  • 1 限目 -- 学働心理学ゼミ: 人のやる気を引き出すには「アメとムチ」はもう古い
  • 2 限目 -- 問題解決基礎論: ありとあらゆる問題に共通する「解決への糸口」を教えよう
  • 3 限目 -- 情報技術各論: 「IT 音痴」なんて言い訳が通じる時代はもう終わった
  • 4 限目 -- 神経経済学: 脳内ホルモンを操る企業が SNS 全盛時代を勝ち残る
  • ランチタイム -- 食習慣改善: 米国人の体の大部分はトウモロコシでできている
  • 5 限目 -- 歴史実験学概論: 世界の構造を把握するには歴史を統計的視点で見ればいい
  • 6 限目 -- ゲーム理論入門: 正確なデータさえあれば 90% の確率で未来予測は可能
  • 放課後 -- 教授宅訪問: クルーグマン教授が語る「ノーベル賞までの道」

注目すべきは、この特集が一つの雑誌から転載されたものではないこと。講義ごとに別々の雑誌から記事がピックアップされている。具体的に雑誌名を挙げてみやう: 1 限目はクーリエ・ジャポン自身によるインタビュー記事、2 限目は「ファスト・カンパニー [米]」、3 限目は複数の雑誌からの書評集 (オンライン・メディア・デイリー [米]、ガーディアン [英]、ワイアード [米]、ニューヨーク・タイムズ [米])、4 限目も「ファスト・カンパニー」、ランチタイムは「フィナンシャル・タイムズ [英]」、5 限目は「ニュー・サイエンティスト [英]」、6 限目も「ニュー・サイエンティスト」、そして放課後は「ニューヨーカー [米]」。これら複数の雑誌の記事をまとめて一つの特集としてまとめ直すことは、並大低の編集能力ではない。しかも 6 限目のゲーム理論入門は、原文が三人称で書かれていたところを、特集の統一感を出すために一人称に書き直す手の入れよう (もちろん、内容に改変はない)。

また、一つの記事ごとに作者の著書が紹介され、より深く知りたい人は本が読みたくなるよう構成されている。オリジナルの記事が著書紹介をしていたじゃなくて、おそらく Courrier 編集部が記事に合わせて著書紹介文を書いているんだと思う。

モチベーション3.0 持続する「やる気!」をいかに引き出すか スイッチ! フリー~〈無料〉からお金を生みだす新戦略 みんな集まれ! ネットワークが世界を動かす ネット・バカ インターネットがわたしたちの脳にしていること Delivering Happiness: A Path to Profits, Passion, and Purpose バイラル・ループ あっという間の急成長にはワケがある フード・ルール 人と地球にやさしいシンプルな食習慣64 Natural Experiments of History 銃・病原菌・鉄〈上巻〉―1万3000年にわたる人類史の謎 銃・病原菌・鉄〈下巻〉―1万3000年にわたる人類史の謎 ゲーム理論で不幸な未来が変わる!―21世紀のノストラダムスがついに明かした破綻脱出プログラム

特集を読んでると、続けて本も読みたくなってしまうのは何故かな? 文章の上手さゆえ? 一限目で紹介された「モチベーション 3.0」とか、ランチタイムで紹介された「フード・ルール」なんかはつい Amazon のボタンをポチッと押してしまいそう。4 限目で紹介された「バイラル・ループ」は今回の献本キャンペーンで送られてきたので、次エントリーで感想を書く。

まあ、特集一つとってもこんな具合。世界時事を集めたコーナーは、中東・ヨーロッパ・アフリカ・北中南米と地域分けされて地域の偏りがない。「世界から見た日本」というコーナーも「環球財経 [中]」、「ニューヨーク・タイムズ [米]」、「イズベスチヤ [露]」、「ル・モンド [仏]」と複数の国からの視点をまとめてある (ル・モンドのラーメン特集は日本人として頷けないものがあるけれど ^^;)。

COURRiER Japon の売りは、特集や時事コーナーになるんでせうけど、単発の記事も負けてない。特集と同じ位い面白いと思ったのは「マイル獲得こそわが人生! 嗚呼、僕は『マイレージ中毒』」 (アメリカン航空で年間 5 万マイル飛んだ顧客に与えられるプラチナ・メンバー資格を、3 か月で 1 万マイル飛ぶと得られるエピソードが良かった)。エティケタ・ネグラという雑誌から選ばれた記事で、ナントこの雑誌、ペルーで発刊されている。全く、どれだけ沢山の雑誌を読んでいるのか!! 冒頭でも書いた、「1500 を越えるメディア」が伊達でないことが良く分かる。

「寄せ集め」を寄せ集めと感じさせない。むしろ、寄せ集めることによって、地域・文化の壁を越えている。それでいて、なお、統一感を生んでいる。素晴らしい!!

COURRiER Japon (クーリエ ジャポン) 2010年 10月号 [雑誌]
COURRiER Japon (クーリエ ジャポン) 2010年 10月号 [雑誌]

あとがき

クーリエ・ジャポンには、フィード・リーダーに近いものを感じた。好きなブログをピックアップして、自分専用のニュース・ソースを作る作業は、クーリエの編集部がやっていることに近い。

もちろん、クーリエにはフィード・リーダーのやうな「パーソナライズ」要素がない。それは弱みであり強みでもある。

これはぼくの思いだけれども、フィードリーダーも、ブログの登録数が 100 を越えないうちはパーソナライズ・ニュース・ソースとしての質が高かった。けれど、数が増えるに従って相対的な質が下がっていった。500 を越えると、読むことに追われる日々が始まる。そして、自分のフィード・リーダーがあまりに「自分向けに」パーソナライズドされていることに気がついた。

他に目を向ける必要がある。

でも、既存のメディア (新聞・週刊誌・Google News etc.) は肌に合わなかった。新聞は毎日読まなきゃいけないので、フィードリーダーと併せて読むには量が多すぎるし、ウィットさに欠ける。おまけに国内の記事ばかり。週刊誌では、これと言ったものがない。テーマが偏り過ぎている。ぼくはもっと網羅的なものが欲しい。Google News は最新の記事を追うには良いけれど、週末・月末にさらりと読むには向いていない。

クーリエ・ジャポンは、正にその隙間を埋めてくれる存在のように思う。クーリエはパーソナライズされていない。むしろ世界中に目を向けて情報を集めている。今、ぼくに必要なのはそういうフィードリーダーとクーリエ (のような) 二つの存在なのかもしれない。

2010-10-18

GDD2010 -- Chrome Extension/WebApps のご紹介とアップデート

講演者は北村英志氏。

Google Chrome Extension について

Chrome の Extension はインストールに際して再起動が不要。アップデートも可能。そしてセキュリティーを高くするよう設計されている。

憶えるべきは、次の 3 項目:

  1. Background page (main)

    常に一つ存在している。予め設定しておけば、ドメインを越えて XML Request を出せる。

  2. Content Script

    実際に表示されているウェブページを直接操作する

  3. Send Request

    Background Page と Content Script 間の通信を行なう

この background page と content script の分離が、セキュリティーを高めるポイント。具体的なことは Tech Talk のリンク先に詳しい。

Chrome WebStore

基調講演でも話のあった Chrome WebStore の詳細 (?)。

Chrome WebStore は Chrome Web Apps を取り扱う。Web Apps には二種類ある。一つ目は Hosted App。ウェブ・サービスのこと。つまり、ウェブ・サービス (Gmail とか) をブックマークするのと変わらない。ただし、ブックマークと違う点が 2 つある。一つはインストール (ブックマーク?) に承認が必要なこと。もう一つはパーミッションの設定が可能なこと。HTML5 ではカメラにアクセスしたり、ファイル・システムをいじったりできるので、さういふウェブ・サービスを作ることも可能になってしまう。そこで、「このウェブ・サービスは○○の機能にアクセスしますが宜しいですか」と予めユーザーに確認する機構が設けられている。

Web Apps の二つ目は Packaged App。全てのアプリを crx (Chrome の Extension と同じ拡張子だね) に納めてダウンロードさせる。つまり、ネットワークに繋がっていなくてもローカル動作するウェブ・アプリを提供できる。こちらはちょっと革新的ね。

WebStore の課金方式は 3 つ。

  1. One-Time (初回のみお金を払う)
  2. Subscription (毎月もしくは毎年お金を払う)
  3. Free (フリー)

ローンチの予定は、アメリカで 2010 年後半、日本で 2011 年前半というのが決まっているだけ。

あとがき

Chrome WebStore は HTML5 を使ってウェブ・サービスやアプリを作った時に生じるであろう不都合をなくすために作られるように聞こえる。Google の HTML5 への本気度のやうにも受け取められるけど、不発に終わるかもしれない (使い勝手が悪くてね ;p)。いずれにしても、サービスがローンチしないことにはレビューも何もない。期待している、とだけ書いておこう。

2010-10-17

GDD2010 -- App Engine 開発者コミュニティ「appengine ja night」とフレームワーク「Slim3」の紹介

講演者は佐藤一憲氏とひがやすを氏。佐藤一憲氏は appengine ja night の管理人。ひがやすを氏は Slim3 の開発者。

appengine ja night

「appengine ja night」は、国内の App Engine 開発者が集まり実践的なノウハウを共有するイベント。2009/10 から開始。月一開催。

過去のイベント紹介があったけど、速くて書きとめられず。

slim3

Google App Engine は Big-Table と呼ばれる Key-Value 型の分散型 DB を使っている。今までの RDBMS のノウハウは通用しない。

Google App Engine は「オートスケール」されることが魅力だが、一回のリクエストを 1 秒以内に終わらせないと autoscaling は走らない。

Google App Engine は管理・運用・保守にコストがかからない良いシステムだが、上記のやうに開発にノウハウが必要。そこでフルスタックな MVC フレームワークとして Slim3 が作られた。

Slim3 のメリット
  • Good Paformance (今までの開発は生産性の方が重要だったけど、Cloud ではパフォーマンスの方がコストに直結してくる)
  • Global Transaction (Google App Engine ではトランザクションに制限がある)
  • Active Community (みんな Twitter にいる)

最後に... 本が出ている。

オープンソース徹底活用 Slim3 on Google App Engine for Java
ひが やすを 小川 信一
4798026999

2010-10-16

GDD2010 -- ここちよい Android - おもいやりの UI デザイン

講演者は adamrocker 氏と矢野りん氏。adamrocker 氏は Android におけるフリック入力アプリ「Simeji」の作者。矢野りん氏はソフトウェア・ビジュアル・デザイン担当。

思いやりの UI デザイン

Android というよりも、携帯用アプリ (含む iPhone アプリ) の UI デザイン入門な感じだった。

UX (User Experience) について「思いやり」であると言い、最終的にそれは「不快でない」ことに落ち着くと説く。その実現方法はユーザーが使って「違和感のない」 UI であること。

以下、実演を交えて説明があった。ここにその実演を長々と書くのは非現実的なので、ポイントだけ列挙する。

  • 変化は操作に対して時間・距離的に近くする
  • 脳が処理する時間的余裕を用意する
    • 認識には時間が必要。フリック入力の残像は 150 ミリ秒残すようにしている
  • 自然な動作表現
    • 変更した部分をアニメーションさせる
  • 清潔感を出す (好きになってもらう、を狙うのは難しい)
    • 文字のボリューム感を揃える (ふとっちょは短めに。m の文字は細めに。i は太くそして短めに)
    • ハイコントラスト (色と大きさ) が重要

名言・公式

講演の中で、デザインに関する名言や公式が沢山でてきたのでメモ。詳しいことは調べて下さい。

躍度 (やくど)

生物に不快感を与える評価値

j = da / dt

  • j: 躍度
  • a: 加速度
  • t: 時間
フィッツの法則

T = a + b log_2 ( 1 + D/W )

  • T: 動作を完了するまでの平均時間
  • a: デバイスの開始・停止時間
  • b: デバイスの速度
  • D: 対象物までの距離
  • W: 対象物の幅
ヒックの法則

沢山あると選べない

テスラーの複雑性保存の法則

複雑な処理の総量は普遍 (なので、機械ができることはなるべく機械にやらせる。人間のやることを少くさせる)

Mies van der Rohe

Less is more

God is in the detail

Louis Henry Silivan

Form follows function

2010-10-15

GDD2010 -- プログラミング言語 Go

講演者は鵜飼文敏氏。

プログラミング言語 Go

Go は Google が設計・開発したプログラミング言語。2009-11-10 公開。現在、125 人のコントリビューターがいる。

鵜飼氏は「Go」のことを「ゴー」と伸ばさず、「ゴ」と短く発音していた。

Go の思想

Go の理想は、今の世界に合った言語を作ること。今あるプログラミング言語は大きく分けて 2 つの主流があるので、その良い所どりをした言語を作りたい、とのこと。その主流のプログラミング言語は次の通り:

  • C, C++, Java (コンパイル系言語; 型安全が保証される; 開発の進みが遅い)
  • Perl, Ruby, Python (ライトウェイト言語: 動的言語; 開発の進みが速い)

具体的には

  • 静的型付け・型安全
  • ダック・タイピング
  • 短いコンパイル時間
  • 大規模プログラミング
  • ネットワーク対応
  • マルチコア対応

これらを前提にしたプログラミング言語を作りたいという。まあ、確かに魅力的。

The Go Playground

Go のホームページにはテキスト・ボックスがあって、その場で Go 言語のコンパイルを試せるやうになっている。是非、遊んでみて欲しいとのこと。

お題: 簡単な電卓を作る

簡単なお題と言って、鵜飼氏は 30 分程で電卓を作ってみせた。正直、速すぎてコードが追えなかった。

面白いと思ったのは、Go が多値を返せること。普通の言語だと return 文で返せる値は一つだけ。ところが Go は 2 つの値を返すことが可能。これを使うと、関数の実行に成功したかどうかをスマートに書ける。例えばこんな風に

  line, err := in.ReadBytes('\n')
  if err != nil { break }
  fmt.Println(String(line))

C なんかだと、失敗した時は -1 を返すとか色々ルールがあって、C 言語のマナーに精通しないと分からないコードが出来やすかった。かういふ二値が返ると、さういふ「イディオム」が少なくなって、初心者への敷居が低くなる。良いね。

この他、色々とためになることを教わったけど、示されたコードと一緒に説明しないと伝わらなさそうなので、ポイントだけ列挙するにとどめる。

  • int 型の他に、int8, int16 型などもあり。これらの自動変換は起きない。
  • スライスは配列に使うポインター。長さを変えられる配列?
  • バイトの配列と文字列は全くの別物
  • 文字列は読み込み専用。utf8。中身は byte 列だけど、作り変えられている。
  • interface ではメソッドを受け取れる型を定義する。コーディング時 implements は書かなくて良い。
  • defer, recover, panic は Go 版 try-catch

あとがき

多値が返せるって所で Common Lisp みたい、と思って Go に惚れた。時間があったら、ちゃんと勉強してみたいな。

2010-10-14

GDD2010 -- 基調講演

Google Developer Day 2010 Japan の基調講演は、3 つの話題がメインだった。

  1. Google Chrome & HTML5
  2. Android
  3. Cloud Platform

以下、簡単にメモをまとめる感じで。。。

Google Chrome & HTML5

HTML5 は今までの HTML と違う。今まではウェブ・ページを作るためだけの仕様だったものが、ウェブ・アプリケーションを作る仕様へと進化している。すなわち、今までの HTML では出来なかった

  • ハードウェアとの連携
  • ハードウェア資源の活用

が HTML (及び JavaScript) から可能になる。

HTML5 は W3C という規格団体が作成しているが、そのドラフトを作っているのは Google や Apple, Opera, Mozilla そして Microsoft を始めとした各企業。Google も Google Chrome で先進の HTML5 仕様をどんどんサポートしていく。

HTML5 を使って新しく出来るやうになる技術が簡単に紹介された。

  • 加速度センサーへのアクセス (ノート PC の傾きを加速度センサーを通じて CSS の transform に渡すデモあり)
  • マイクへのアクセス (音声認識デモあり)
  • GeoLocation
  • File System API

DOM のイベント・リスナーにセンサー情報を直接渡せるのは便利そう。

Chrome Web Store

今秋リリースされる Google のサービス。Vector のウェブ・サービス版。

ウェブ・サービスを一か所に集め検索性を向上させる。有償サービスへの課金システムを Google が肩代わりして、サービス提供者の開発費を抑えるとともに、ユーザーにはどのサービスにどれだけお金をかけているか一覧する機能を与えるものと思われる。

詳細は不明。秋のリリースを楽しみにするしかないかな...

Android

Android が世界でどれ位いメジャーになっているかの具体的な数字を教えてくれた (書きとめられず...)。

最後は日本の「日本Androidの会は素晴らしい、と閉じられた。

Cloud Platform

Google App Engine のお話。作る・管理する・スケールするのが楽なシステムです、とのこと。

Google 日本語入力

Google 日本語入力のソースコードは Mozc という名前でオープン・ソース化されている。そして本日、Mac OS 版のソースコードも公開した、とのこと。

オーディオ・オフ会 けろさん邸訪問

最近、Twitter で知り合ったkerberos104さんこと「けろちゃん」さん (以下 けろさん) がオーディオも滅法強いということで、2010-10-10 (日) にお宅を訪問して音を聞いてきた。

けろさんのオーディオ・システム

家へ上がって、アイス・コーヒーを頂きながらオーディオ・システムの説明をしてもらった。説明の間、けろさんはグレン・グールドの弾くバッハのパルティータをかけて下さった。美しい音楽の調べに耳を傾けながらの機器解説。とても心がなごむ。

けろさん邸 ラック

CD システムの概要は以下の通り:

  • CD プレーヤー: Marantz SA8400
  • DAC: Soulnote dc1.0
  • プリ・アンプ: Kryna L502
  • パワー・アンプ: Kryna (Krypton) M502 (真空管アンプ)
  • スピーカー: Kryna HDA35 + muRata ES105A

CD プレーヤー周り以外は Kryna ブランドで固められている。Kryna はマグネシウム系のオーディオ・アクセサリーで有名な日本のブランド。大手のオーディオ屋さんなら、大低あつかいがある。ただし、Kryna ブランド自身が CD プレーヤーからスピーカーまでオーディオ・システム全部を作っていることはあまり知られていない。というのもオーディオ・システムそのものはほとんどの店で扱われていないため。Kryna のオーディオ・システムは、Kryna のショールーム兼ストアである PLUTON で試聴することができる。

ちなみに、パワー・アンプの項に「Krypton」とあるのは、Kryna の前ブランド名が Krypton だったため。けろさんは、M502 を Krypton 時代に買ったそうな (実は、KRIPTON というオーディオ・ブランドが他にある。おそらくそのブランド名との混乱を避けたかったものと推察する)。

試聴タイム

音楽を聴くのは楽しいもの。最初の方はメモを取りながら聞いていたけれど、途中からは音楽に没頭してしまった。

まず最初に、音量を大きくして第一楽章からグールドの弾くバッハのパルティータを。続いて同じ音源を LP で再生してもらった。CD から LP に音源を変えたとたん、音が生き生きしてびっくりした。CD と LP の違いについては後述。

次にぼくの持ってきていた CD でパルティータを聞く。演奏者はギーゼキング。ぼくにとってはお馴染みの CD なのだけど、中域の音の澄み具合が半端ない。大して音量を上げているわけでもないのに、音がフッとぼくの胸の中に納まる感じで飛んで来た。

次はけろさんのターン。Bob James & Earl Klugh のアルバム「One on One」から。これはけろさんのオーディオ・テスト用ソースとのこと。初めて聞く音楽 (しかもジャズ) なので、ついてゆけず。

代わりに、マイケル・ジャクソンの曲を二曲ほどかけさせてもらった。「History」から「Billie Jean」と「Heal the World」。けろさん邸のスピーカーはトールボーイ・タイプ。けろさん曰く、「昔みたいに大きな口径のスピーカー・ユニットを使わなくても十分な低音が出るでしょう」とのこと。確かに低音の量感は申し分ない。ただし、ぼくは大口径でガンガン鳴らしてた時代を知らないので、比較の仕様がない。ぼくに言えるのは、けろさん邸のスピーカーはぼくにとっては十分な低音が出ている、というよりむしろ量感が出すぎているんじゃないかしら? ということ。ぼくの好みは、もう少しスリムな低域・低音。

けろさん邸 スピーカー

ここからノートを取らなくなったので、記憶があいまいになる。確か、「タイタニック」のサントラから Celine Dion の歌う「My Heart Will Go On」を、Julie London のボーカルで「Fly Me to the Moon」を、同じく Julie London のボーカルで「Besame Mucho」を聞いた。どれもボーカルが力強くて沁みた。他にも聞いたかもしれないけれど、忘却の彼方。

最後にルドルフ・ゼルキンと小澤征爾 & ボストン交響楽団によるベートーヴェンのピアノ協奏曲第 5 番「皇帝」を聞いた。ピアノの音がまた素晴らしい。一方で、オーケストラのヴァイオリンの音が伸びていないやうに感じた。

LP と CD

けろさんは CD よりも LP をお好きとのこと。LP プレーヤーにお金をかけるので LP の音が良くなり、LP を沢山購入するからもっと LP プレーヤーの質を上げやうとする。そんな正のスパイラルに入っているやうに見える。そんなけろさんの LP プレーヤーは次の構成になっている

  • LP プレーヤー: Linn LP12 (改: サブシーャーシをニュージーランドの CETECH 製に変更)
  • トーンアーム: EKOS のマグネシウム・アーム
  • カートリッジ: マイソニック・ラボ Eminent (シェル・リード線にはゾノトーン)
  • シート: foQ
  • MC トランス: マイソニック・ラボ Stage302
  • 電源トランス: マシスト・デザイン
  • フォノ・ケーブル: エソテリック
  • フォノ・イコライザー: プリアンプに内蔵

けろさん邸 Linn LP12 改

けろさんは、ただでさえ評価の高い LP プレーヤー Linn LP12 に手を加えて改造してらっしゃる。この説明は、LP プレーヤーを持たないぼくには全く歯が立たないところだけれども、幸運にもけろさん自身がブログのエントリーを書いて下さっている。LP プレーヤーに興味をお持ちの方は、そちらのエントリーをどうぞ。

LP で聞いたディスクは、グールドのパルティータ、「One on One」、「Fly Me to the Moon」、そしてゼルキンと小澤のベートーヴェンのピアノ協奏曲第 5 番。

このうち、グールドのパルティータだけ CD 盤と LP 盤の両方を聞かせて頂いた。音の違いについて、少し書いてみたい。

けろさんがお持ちの LP 盤は国内盤とのことだけれども (普通、国内盤は音が悪い)、CD 盤と比べると、低域がグッと伸びる。ピアノの中域が力強く華やかになる。そして、レコーディングしているその場の空気感がとても良く表現される。この音を聞いてしまうと、CD に戻れなくなるのも分かる気がする。

とはいえ、この CD と LP の比較試聴は不公平な点がある。それは CD プレーヤーが DAC を含めても 30 万円強にしかならないのに比べて、LP プレーヤーはどう低く見積もっても定価で 100 万円を越えること。LP 優利な条件での比較であった。

オーディオ・システムの感想

まず、非常にバランスの良いシステムだと思った。音像が中央に定位し、左右の音のバランスが丁度良い。当たり前のやうに聞こえるけれど、システムが高価になればなるほど、こういうことが難しくなる。現に、ぼくは今、このバランスに苦労している。当たり前のことを当たり前に出来ていることに唸らざるをえない。

音は中域が特に素晴らしく透明感があった。一方で、高域は伸びきらず、低域は量感こそあるものの少しダブついている感じがした。最後に一点。システム全体のスピードが速い点も良かった。

高域の伸びについては、特に「ピアノ協奏曲 第 5 番 皇帝」を聞いていて感じた。原因は、スピーカー周りに空間がないことだと思う。スピーカーが、まるでスタジオ・スピーカーのやうにラックとテレビの間に納まっている。もう少し空間が欲しい。けれど、家の状況を見るに今以上の空間を取ることは不可能さうだった。

低域の量感多過については、ほとんどのソースで感じた。量感が絞られれば、もっとコントラバスなどのピッツィカートやオーケストラの低弦 (チェロやコントラバス) の動きが見えるやうになって楽しくなると思う。ぼくの浅い経験からだと、この手の量感多過はスピーカーが後ろの壁に近過ぎることで起きることが多い。はたして、Kryna HDA35 は後ろにバスレフ・ポートのやうな穴があった。しかし、けろさんによるとそれはバスレフ・ポートではなく単なる空気穴とのこと。う〜ん。理由が分からない。まあ、仮にスピーカーを 30 〜 60 cm 前に出せたとしたら、リスニング・ポイントも同じ位い下げねばならず、非常に不都合が多そう。

一人暮らしならいざ知らず、家族が居るとなると、今のスピーカー位置は変えられそうにない。むしろ、不都合ありながらもベストなスピーカー位置になっているのではないかと思う。何より、高域・低域に (オーディオ的に) 不満があったとしても、音楽的にはほとんど影響を与えないのだから、ゴタゴタ言うより、よくぞここまでシステムを完成させたと感嘆すべきなのだと思う。

ES105A について

音を聞いてどうこう思ったというより、ES105A の置き場所を見て思ったこと。

muRata ES105A は素晴らしいスーパーツィーターだけれども、セッティングを詰めると更に良くなる。

  • ツィーターと同じ軸上に ES105A を持って来る
  • ES105A は安定しているやうに見えるけど、インシュレーターで随分音が変わる
  • スーパーツィーター用のケーブルも変えると変化大!

以上を踏まえた上で、ES105A をバッフル面から少しずつ下げて行く。すると、ピントがピタッと合うポイントが見つかる。そこが ES105A が最大限に威力を発揮する場所。これはスピーカーごとに違うので、自分の耳を信じてトライを繰り返すしかない。

けろさんは、ES105A の後ろ部分にインシュレーターを置き「下向き」になるようセッティングなさっていたが、それは最後の手段と考える方が良いと思う。特に ES105A を後ろに持っていくと「下向き」になった高音が、スピーカー自身に当たって上へ飛んで行ってしまいかねない。それでも ES105A を下向きにするなら、後ろ一点支持ではなく後ろ二点支持をお勧めする。超高域を扱うスピーカーの特性上、目には見えないけどすごく振動しているので、安定に支持する方が良ろしいかと。

御礼

忙しい中、色々と気を回して頂いてけろさんには感謝の念が断えない。

素晴らしい音を聞かせて下さって、ありがとう。あの後、自分のシステムで音を聞いたら驚くほど低域の音が汚くてびっくりした orz (もちろん、再セッティングして少しましになったけど)。

何度も、アイス・コーヒーのコップをひっくり返してごめんなさい。

そして御家族の方々、いきなりお邪魔して申し訳なかったです。

試聴 CD リスト

試聴で使った CD のリスト。一部 LP のものもあったけど、相当する CD を見つけてみた。

  1. Italian Concerto / Partitas Nos 1 & 2
  2. Partitas (Gieseking) 廃盤 (!?) につき画像なし
  3. One on One
  4. ヒストリー
  5. 「タイタニック」オリジナル・サウンドトラック
  6. ジ・エンド・オブ・ザ・ワールド(紙ジャケット仕様)
  7. ラテン・イン・ア・サテン・ムード(紙ジャケット仕様)
  8. Piano Concerto 5 Emperor

Italian Concerto / Partitas Nos 1 & 2 One on One ヒストリー 「タイタニック」オリジナル・サウンドトラック ジ・エンド・オブ・ザ・ワールド(紙ジャケット仕様) ラテン・イン・ア・サテン・ムード(紙ジャケット仕様) Piano Concerto 5 Emperor