TidBITS: Apple News for the Rest of Us  TidBITS#1000/19-Oct-09

ドラムの連打をどうぞ... TidBITS の第 1,000 号です!(私たち自身も驚いています。)Adam が、私たちの今いる場所を見渡して、私たちから見た良い仕事とは何かについて考察する。でも今の栄光に満足している暇はない。Matt Neuburg は特定の Apple イベントを失敗に至らせるバグを彼が発見した経緯を説明し、Rich Mogull は Adobe Reader のセキュリティ脆弱性を避けるために PDF ファイルには Preview を使うことを勧める。さらに、Doug McLean は Apple がゲストアカウントに関係したデータ破壊のバグの存在を認めたことと、Microsoft が Office 2004 のサポートを延長したことを伝えるとともに Gmail の新機能を歓迎する。Adam はまた Find My iPhone (iPhone を探す) 機能を使って安心の度合いを増す方法を説明し、Apple がアプリ内の課金を許すようにした方針変更を伝え、Google Docs に新設された共有フォルダについて概観する。最後にもう一つ、Glenn Fleishman が iPod nano のラジオ機能で Apple が好機を逸してしまった、と考えをめぐらす。今週注目すべきソフトウェアとしては、Acorn 2.1、Nisus Writer Pro 1.4、Phone Amego 1.0.8、Snapz Pro X 2.2.1、Performance Update 1.0、Airfoil 3.4、Cocktail 4.5.2、Evernote for Mac 1.5、Logic Pro 9.0.2、iMovie '09 8.0.5、SuperDuper 2.6.2、それに Carbon Copy Cloner 3.3 がある。

記事:

----------------- 本号の TidBITS のスポンサーは: ------------------

---- 皆さんのスポンサーへのサポートが TidBITS への力となります ----


Apple、ゲストアカウントによるデータ喪失のバグを認める

  文: Doug McLean <[email protected]>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

ゲストアカウントを使用したことでデータが消去されてしまうという、稀にしか起こらないが深刻なバグの存在を、Apple が公式に認めた。ゲストアカウントにログインしている間に、もしもコンピュータがハングアップしたならば、その後通常のアカウントに戻った際に、あなたのユーザーアカウントにあるすべてのファイルやフォルダが消去され、アカウントがデフォルトの設定にリセットされているという可能性がある。あなたのアカウントのパスはまだハードドライブ上に存在しているが、その中にあったものは _すべて_ 消えてしまう。

Apple はこのバグについて報じた CNET の記事 への反応として、「非常に稀な状況の下でのみ起こるこの問題を当社は認識しており、現在修正作業中です」とだけ述べた声明書を発表した。近いうちに Mac OS X 10.6.2 が出されることは十分に考えられるし、このバグの深刻度を考えれば普通よりも早いタイミングで出てくる可能性が高いと思われる。

Apple のサイトでは Account and Login フォーラムに大きなスレッドが三つあって、この記事の執筆時点で閲覧数が 25,000 件以上、投稿も 100 件以上に達している。これらは非常に大きな数だが、必ずしも問題が極端に広範囲に発生していることを意味するわけではない。ただ、発生件数が過剰でないのはこのバグの挙動が一貫していないというより一般的にゲストアカウントがあまり使われていないことによる方が大きいだろう。

現時点では、この問題を再現させるための具体的な手順はまだ明らかではない。詳しい情報のほとんどが討論フォーラムから来たものであるからだ。例えば、ファストユーザスイッチを使えば問題が起こるか、Login ウィンドウからログインすれば問題が起こるか、それとも両方か? また、管理者レベルのアカウントを2つ持っていて、ゲストアカウントにログインしたら、管理者アカウントが両方とも消されてしまうのか? そういった疑問にまだ答は出ていない。

修正が入手可能になるまでの間は、一時的にゲストアカウントを無効にしておくことをお勧めする。Accounts 環境設定パネルでゲストアカウントの設定をする際に、2つの "Allow guests..." チェックボックスのチェックをを両方とも外しておけばよい。これで、偶然に使ってしまうことも防止できるはずだ。

Disable-guest-account

最後にもう一言。このことを教訓に、あらためてバックアップの重要さを再認識しよう。Time Machine によってでも他のバックアッププログラムでもよいが、少なくともあなたのホームフォルダについては常に最新のバックアップを持っているようにしよう。

コメントリンク10642 この記事について | Tweet リンク10642


Microsoft が Office 2004 のサポートを延長

  文: Doug McLean <[email protected]>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

6ヵ月前に、Microsoft は 2009 年 10 月 13 日をもって Microsoft Office 2004 の「メインストリーム・サポート」を打ち切ると発表した。(2009-04-15 の記事“Microsoft Office 2008 12.1.7 および 2004 11.5.4 更新プログラム公開”参照。)ところが今回、五年間続いてきたこのオフィス・プロダクティビティ・スイートに、打ち切り執行の延期が告げられた。Microsoft は、Mac Mojo ブログの中で、サポートを 2012 年 1 月 10 日まで延長すると発表したのだ。

その記事の中で、Microsoft は既に Office 2008 に切り替えているユーザーは多いものの、Visual Basic for Applications (VBA) に依存しているためにまだ 2004 版を必要とする人たちもいると述べた。Office 2008 には VBA サポートがないからだ。来たるべき 2010 リリースの Microsoft Office では VBA のサポートが復活すると見られているので、それを必要とするユーザーのために継続的なクロスプラットフォームのサポートを確保したいのだ、と Microsoft は述べている。

今回の延長により、Office 2004 がその終末を迎える時点では 8 年間近くもサポートが続いた状態になることとなる。今回のことで他の Office 製品についての標準 5 年間のサポートという方針が変わることはないと Microsoft は明言した。

Microsoft がこのサポート延長ですべての Office ユーザーたちを考えてくれたことは嬉しい。ただ、私たちの印象では、Office 2004 の VBA に依存しているユーザーたちの多くは大企業で巨大なクロスプラットフォームのインストールを使っている人たちなのだろうと思う。来たるべき Office の 2010 リリースで 10,000 席のライセンスを売ることこそ、Microsoft が Office 2004 ユーザーたちの気持ちをあと少しつなぎ止めておきたい大きな動機なのだ。

コメントリンク10644 この記事について | Tweet リンク10644


Iアプリ内課金で無料アプリの機能ロック解除が可能に

  文: Adam C. Engst <[email protected]>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

Apple が iPhone ソフトウェア開発者たちに対し、従来は有料のアプリのみに限定されていた In App Purchase (アプリ内課金) 機能が、無料のアプリでも使えるようになったと通知した。これはものすごく大きな変更であって、無料アプリの中でも In App Purchase を使いたいという声に対して Apple が当初「無料アプリは無料のまま」と返答していた態度を 180 度方針転換するものでもある。今後、開発者たちがこの機能を活用するようになり次第、iPhone アプリの世界は二つの重要な点で進化して行くものと思われる。

まず第一に、ごく明らかなことだが、開発者がアプリ(例えばコミック本のリーダー)を無料で配布して、In App Purchase 機能を使って個々のタイトルに課金するということができるようになる。従来は、そのようなアプリは最低でも $0.99 の価格をつけなければ In App Purchase の利用が許されなかった。だからこの変更が実現すればありがたい。とは言っても、これはそれほどワクワクするような変化でもない。コンテンツを毎号購読するのにお金がかかるのなら、最初に入手するリーダーが無料であろうと $0.99 であろうと大した違いはないのではなかろうか。

第二に、こちらが最も重大な点だが、iPhone アプリの開発者たちがアプリの機能制限版を無料で配布しておいて、In App Purchase 機能を使って追加機能のロックを外すということが、ついに可能になる。これで、同じアプリの無料版と有料版を両方作らなければならないという、今ではよく見られるようになったやり方が、ようやく不要なものとなる。

誰もが歓迎することだろう。ユーザーにとっては使用の利便性が増す。なぜなら、無料アプリが気に入ったユーザーは、わざわざ有料版を探したり無料版をそれで置き換えたりする必要がなくなるからだ。その上、App Store で欲しいアプリを探すのもこれからは少し楽になるだろう。なぜなら、無料版・有料版の両方があって混雑に輪をかけるということが減るだろうからだ。開発者にとってもありがたい。なぜなら、同じアプリの二つのバージョンを両方管理しなければならない必要がなくなるからだ。それに、私の予想では、アプリ内部からできることによって無料から有料に移行するユーザーの割合が増えるだろうと思えるからだ。そして最後に、Apple にとっても都合が良い。ユーザーたちがより多くのアプリにお金を出すようになれば、現金収入の面でも顧客の忠実度の面でも進展があるだろうからだ。

レビューやレーティング評価の処理をどうするかについてはいくらか混乱が起きるかもしれない。機能のアンロックを許すアプリではそれが実現すればユーザーの評価が大きく変わるだろうからだ。Apple としては、In App Purchase が実現する前と後とでレーティングやレビューの投稿を区別する必要があるかもしれない。

コメントリンク10651 この記事について | Tweet リンク10651


Gmail、メールのグループ送信でさらなる誤操作防止機能

  文: Doug McLean <[email protected]>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

Google が Gmail にまたもう一つ機能を追加した。不注意で起こす間違いを防止するための機能だ。 Mail Goggles (メールのゴーグル) みたいな楽しさはないが、"Got the wrong Bob?" (メールの宛先は正しいですか?) と名付けられた今回の新機能は、いろいろな人たちを集めたさまざまのグループ宛てにメールを書くことの多い人に人気が出るのではないかと思われる。

この "Got the wrong Bob?" 機能を有効にしておくと、あなたがメッセージの宛先として指定したグループの中にいつもと違う受取人が含まれているとこの機能が判断すれば、警告が出る。あなたがよくメッセージを送るグループを追跡管理することによって、Gmail があなたのために鋭い眼力の友人になってくれる。そして、もしもあなたが似た名前の宛先人を取り違えたら、そのことを警告してくれるのだ。

例えば、あなたがいつもよく会う友人たちを集めた食事を計画していて、あなたの友だちの Mike をそこに招待したいと思ったとしよう。どころがあなたはうっかりと職場の嫌な同僚である Mike の方を宛先に入れてしまったとしよう。すると、Gmail がこれは本当に正しい Mike なのかと尋ねてくる。宛先のアドレスフィールドの下に小さな警告が "Did you mean: X instead of Y" というテキストで表示される。X の名前をクリックすれば自動的に X の電子メールアドレスが "To:" フィールドに挿入され、誤りの宛先アドレスが削除される。

Got-the-wrong-Bob

ただし、このような警告にあまり頼り切ってはいけない。この機能が働くのは3人かそれ以上の人たちに宛てたメッセージのみだ。だから、一人か二人に宛てて書いている場合はやはり自分でしっかり注意を払わなくてはいけない。

"Got the wrong Bob?" 機能は、Gmail に以前からあった機能でグループへの電子メールメッセージに対して誰か忘れている人がいないか確認してくれるものをうまく補完している。こちらの機能は以前 "Suggest more recipients" (宛先入れ忘れ防止) と呼ばれていたが今回 "Don't forget Bob." と改名された。(個人的には "What About Bob?" の方がいいと思うが。)[訳者注: "What About Bob?" は Bill Murray と Richard Dreyfuss 主演のコメディ映画のタイトルで、邦題は「おつむて・ん・て・ん・クリニック」です。]

Suggest-more-recipients

これら2つの機能はいずれも、有効にするためにはまず Gmail アカウントにログインしてから、右上の端にあるビーカーアイコンをクリックして、下の方へスクロールし、"Got the wrong Bob?" (メールの宛先は正しいですか?) あるいは "Don't forget Bob" (宛先入れ忘れ防止) の横にある Enable (有効にする) ラジオボタンをクリックする。(もしもビーカーアイコンが見えなければ、Settings (設定) リンクをクリックしてから Labs リンクをクリックすればよい。)それから、一番下にある Save Changes (変更を保存) ボタンをクリックする。

コメントリンク10649 この記事について | Tweet リンク10649


Google Docs、共有フォルダを追加して共同作業をより手軽に

  文: Adam C. Engst <[email protected]>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

Google が Google Docs をアップデートして、共有フォルダをその機能に加えた。これは Google Docs を使って大量の共同作業をする人たちから要望の多かった機能だ。問題は、Google Docs ではどんな書類もあなたが電子メールアドレスを知っているどんな人とでも、さらにはあなたが作成したグループでも、共有することができるのだが、そういった書類はすべて個々に手で共有の設定をしなければならなかった。現実には、同じ人々との間で多数の書類が何度も何度も共有されているのだから、Google Docs の中でいちいち個々の書類を共有設定しなければならないのは煩わしかった。

今回の新しい共有フォルダ機能では、フォルダを作ってそれを一人またはそれ以上の人たちと共有でき、それ以後にそのフォルダの中へ入れた書類がすべてその人たちにも利用できるようになる。私の知る限り、Google Docs は新たに書類が加えられてもフォルダを共有している人たちに何かの通知をするというようなことはしない。でもおそらく、定期的に同じ人たちと書類の共有をしているのならば、当然ながら既に他の方法でその人たちとのコミュニケーションが確立しているに違いない。

はっきりさせるために言っておくと、Google Docs のこの新しい共有フォルダ機能が扱えるのは、あなたが Google Docs のウェブインターフェイスで作成するか読み込むかしたワードプロセッサ書類、スプレッドシート、あるいはプレゼンテーションのみに限られる。これは、Dropbox (私たちは Take Control 本の原稿のためにこれをよく使っている - 2009-02-03 の記事“Dropbox:ある共同編集者の夢”参照)、SugarSync(2008-08-30 の記事“SugarSync、オンラインの同期に甘味付け”参照) あるいは MobileMe の iDisk などに見られるような汎用のファイル共有方式では ない

この Google Docs の機能は登場したばかりだが(そのため私たちはまだ多くの経験をしているわけではない)既に私は一見しただだけでは見過ごしがちな便利な側面二つに気付いている。それに加えて、改良して欲しい点もいくつかリストに加えている。

Google-Docs-shared-folders

独特な機能 -- まず第一に、Google Docs によるフォルダの実装は Gmail がラベルを実装する方法と似ている。ここでのフォルダは基本的にタグなので、一つの書類が複数のフォルダに同時に存在することができる。(各フォルダに個別にカラーを設定することができるので、Gmail のラベルと同様簡単に見分けられる。)

これは、Mac OS X でのフォルダに慣れた私たちの目には本当に奇妙に映る。Mac OS X ではファイルは(スマートフォルダを別にすれば)一つのフォルダにしか属することができない。けれども、共有に際してはこれが非常に興味深い意味を持つ。なぜなら、同じ書類があなたのいつものワークグループで共有するフォルダにありながら、同時に遠くにいる同僚の一人と共有しているフォルダにも入っていることができるからだ。

このやり方がうまく行くための鍵となる方法が、Google Docs のサイドバーでフォルダの上にコレクションがリストされている、そのコレクションのどれか(All Items, Owned By Me, その他)の中からファイルをドラッグしてフォルダのどれかに入れなければならないことだ。そうすると Google Docs はそのファイルをそのフォルダに割り当てる。そのファイルが既に別のフォルダの中にあった場合でも、そうすれば双方のフォルダの中に現われるようになる。

ところが、もしもフォルダの一つの中でファイルを眺めている際にファイルを一つそのフォルダから別のフォルダへドラッグすれば、Google Docs はその書類を元あったフォルダから削除して新しく移動先のフォルダの中に置く。この点は使い慣れた Mac でのやり方と同じだ。

共有フォルダで見過ごしがちだが知っておくと便利な点のもう一つは、あるフォルダを特定の人かグループと共有しているからといって、そのフォルダの中の書類をさらに別の人と共有してならない理由は何もないということだ。

だから、例えば私は Take Control フォルダを持っていてそれを Tonya と共有している。私たち二人はいつもその中の書類で一緒に作業しているからだ。でも、その中の個別の書類を選んで特定の Take Control 著者とも共有すれば、彼らもそこに何か書き込むことができるようになる。

希望する点のリスト -- Microsoft が T-Mobile Sidekick ユーザーのクラウドベースデータを消去してしまった先週の大事件が示すように(2009-10-11 の記事“Sidekick ユーザーのクラウドデータ、吹き飛ばされる”参照)クラウドに置いてあるデータについてはぜひともローカルなコピーを持っていたい。そのクラウドを運営している会社が何か信じられないようなミスをしてあなたのデータを失ってしまう万一の場合に備えるためだ。

理想的な世界ならば、Google Docs があなたの書類をあなたの Mac 上のフォルダに自動的に同期してくれるだろう。その書き出し・読み込みの機能を使って、ローカルにせよクラウド上にせよ、どちらでも都合の良い方で作業できるようになっていて欲しいものだ。実際、Syncplicity と呼ばれるファイル共有サービスの Macintosh 用ベータ版では、まさにその機能が約束されている。けれども私が使ってみた範囲ではこのベータ版は全く動かなかったし、その後間もなく同社は Mac 版を丸ごと取り下げてしまった。

Google Docs が持っている機能は、Google Gears を経由したオフラインのアクセスだ。これで、インターネットに接続していない時にもすべての書類、スプレッドシート、プレゼンテーションを見ることができ、またワードプロセッサ書類ならば編集することもできる。けれども残念なことに、Snow Leopard を使っている場合、Firefox に Google Gears をインストールすることはできるが、Safari 用のバージョンはまだ Mac OS X 10.6 と互換になっていない。(2008-09-01 の記事“Google Docs を Safari でオフライン利用する方法”参照。)

だから、もしも Google Docs を広範囲に使いこなしたいのならば、Firefox に Google Gears をインストールして、定期的に Firefox で Google Docs にアクセスすることでバックアップ作成の方法とするのがよいだろう。これは、私にとってはちょっと面倒だ。なぜなら、私は Google Docs を Fluid によるサイト特定のブラウザ・インスタンスの中で使う方が好みだからだ。だから、Google Docs は独立のアプリケーションとして動作するので、Firefox の中のタブとしては走らない。

また、Google Docs が共有フォルダを処理する方法にも扱いにくく感じられるところがある。それは、"My folders" と "Folders shared with me" の区別だ。私が Take Control フォルダを作って Tonya もそれを共有しているので、このフォルダは私のところでは "My folders" の中にあり、彼女のところでは "Folders shared with me" の中にある。

このような区別をする必要はないように思える。同じようなフォルダ階層を自分でも持ちたいと思うならば、この区別のせいで混乱に陥ってしまうかもしれない。実際、Tonya は既に彼女自身の Take Control フォルダを持っていたので、私か彼女のどちらかが相手の共有フォルダに譲るために自分のフォルダを削除しなければならないだろう。

この混乱の理由は、Google Docs における書類が、その書類を誰が作成したかに関係なく、共有している相手との間で互いに「ローカル」なものとして見えるのが原則的な考え方だからだ。上記のような二つのタイプのフォルダを区別することによって、Google はそのフォルダが誰の手になるものか(あなた自身なのか、それとも他の人なのか)をあなたに意識させるようにしている。通常の使用ではそれらのフォルダの中にある書類のオーナーが誰であるかが実際上の意味を持つことは少ないのだが。

このように、Google Docs の書類に対するローカル同期の改善とか、フォルダが自分のものか共有したものかの区別が不要だとか、そういう点は私の望みとして挙げることができるものの、Google Docs に共有フォルダが追加されたことは非常に歓迎すべきものだと言える。私たちは、これを使っていくつもりだ。

コメントリンク10646 この記事について | Tweet リンク10646


Adobe Acrobat と Reader の脆弱性から自分自身を守ろう

  文: Rich Mogull <[email protected]>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

2009 年 10 月 13 日、Adobe は Windows、Mac、および Linux プラットフォームの Adobe Acrobat および Adobe Reader 製品の複数のバージョンに対する メジャーなセキュリティアップデートをリリース して、攻撃を受けたシステムをアタッカーが乗っ取る可能性のある欠陥に対処を施した。

Adobe のセキュリティの実績は以前から感心しないところがあったので、私としてはすべての Mac ユーザーに対して、単に Adobe Reader と Acrobat へのパッチを今すぐに施すのみならず、デフォルトの PDF リーダーとしてぜひ Apple の Preview を設定しておくようお勧めしたい。Adobe のデジタル著作権管理保護の施された PDF ファイルにアクセスする必要のある人や、うまく表示できない PDF ファイルに頻繁に遭遇する人でない限り、日々の PDF 閲覧の必要を充たすには Preview で十分以上の働きをするだろう。

PDF ファイルの作成をするために使う商用製品の Adobe Acrobat については、代わりとなる製品を見つけるのは簡単でないが、その一方でこの製品が必要となる機会は一般的にずっと少ないだろう。多くの Mac プログラムガ直接 PDF ファイルを生成することができるし、Mac OS X にはずっと以前から Print ダイアログの中に Save as PDF コマンドがある。これで、あなたが印刷できるものならば何でも PDF にできる。もちろん、マーケティングのプロたちやデザイナー、電子ブックの出版者たちの必要を充たすには足りないかもしれないが、平均的なホームユーザーやオフィスワーカーにはこれで十分だろう。

この最新の脆弱性が影響するプログラムは以下の通り: Adobe Reader 9.1.3 と Acrobat 9.1.3、Windows、Macintosh と Unix 用の Adobe Reader 8.1.6 と Acrobat 8.1.6、それに Windows と Macintosh 用の Adobe Reader 7.1.3 と Acrobat 7.1.3 だ。これらの脆弱性によって、たとえあなたが悪意を持って作られた PDF ファイルを表示させただけでもアタッカーがあなたのコンピュータを乗っ取ってしまう可能性がある。Windows ユーザーについては、今回のパッチがリリースされるよりも以前に既にこの脆弱性への攻撃が出回っていた。(セキュリティ分野で「ゼロデイ脆弱性」と呼ばれるものだ。)

Mac ユーザーが現在攻撃を受けているという証拠を私たちは知らないが、同時に私たちの知る限りアタッカーが Mac をターゲットにするための技術的な障害は何もない。ただ、Windows 上でさえ、アタッカーはあなたに悪意あるファイルを開かせなければならないし、アタックが実際に出回っているといってもそれほど広範囲に行き渡っているわけではない。言い替えれば、Mac ユーザーとしてのあなたが現時点で直面しているリスクはかなり低い。それでも、分別のある人ならばパッチしておくべきだろう。

この脆弱性は、 Adobe Reader 9.2、8.1.7、7.1.4 で、および Adobe Acrobat Pro 9.2、8.1.7、7.1.4 で、それぞれ修正されている。Adobe にはアップデータプログラムもあるが、うまく動かないことも多いので、手動でダウンロードしてアップデートする方が賢明だろう。注意すべきは、中間のアップデートもダウンロードして順々にインストールしなければならない可能性が高いことだ。例えば、Acrobat 8.1.7 アップデートは 8.1.6 の上にしかインストールできず、8.1.5 やそれ以前の上にはインストールできない。

Adobe のセキュリティのレベルから翼が抜け落ちたのはこれが初めてではない。最近の SANS Institute の報告によれば、Acrobat と Reader が重大なゼロデイ脆弱性の影響を受けたのは過去 7 カ月間で今回が少なくとも三回目だという。攻撃は Windows ユーザーをターゲットにしたものであったが、これらの脆弱性には Mac を攻撃できる可能性も同程度にあった。

Adobe のセキュリティページによれば、同社は 2009 年 2 月以来九つの重要なアップデートをリリースし、そのいくつかは Acrobat および Reader 9.x に対する複数の脆弱性をパッチしたものであった。パッチでの苦闘があまりにも多岐にわたったので、Adobe では新たに年四回のパッチスケジュールに切り替えて IT 管理者たちがシステムを最新のセキュリティ修正でアップデートし続けられるようにしたほどだ。

このようにセキュリティの実績が良くないものであったのを見れば、また書類の表示と作成双方で Mac OS X 内蔵の PDF サポートがあることを考えれば、Mac の上でデフォルトの PDF ビューワーとして Reader を使うのはほとんど意味を成さないように思える。また、Acrobat ユーザーは、自分が本当にこのプログラムの追加の機能を必要としているのかどうか自ら問い直してみるべきだろう。

特に、Windows から Mac に切り替えて来た人たちは、ネイティブな Mac ソフトウェアで既に十分必要が充たされるかもしれないことを知らずに Adobe Reader と Acrobat をインストールして使っていることがよくある。例えば、私の家族の一人は Windows から切り替えた際に、習慣で真っ先に Reader をインストールしていた。大部分の書類を見るのには必要がないことを知らなかったからだ。(その後、Preview で表示できない PDF に彼女は一度も出会わなかった。)

確かに例外はある。Preview は保護の付いた PDF ファイルは開けないし、すべての PDF 書類を正しくレンダリングできるとも限らない。年月を経て PDF ファイルフォーマットは非常に複雑なものになってきており、JavaScript のサポートや、Flash コンテンツの埋め込み、その他高度なオプションを含むようになってきた。Acrobat には単に PDF に印刷する以上のはるかに広範なコントロールとコンテンツの機能が含まれている。特に、画像の解像度やフォーマットを管理しなければならない場合にはそれらの機能が重要になる。もちろん、これらの複雑さが Reader と Acrobat にあることこそ、そもそもセキュリティの問題が多数入り込める理由になっているのだ。

Adobe はこれらのセキュリティの問題が同社のビジネスに及ぼすリスクを認識している。今年早く、同社は メジャーなセキュリティ構想を打ち出して、コードの品質と対応の手順とを改善することを目指した。これは高く評価できる姿勢であったが、ソフトウェア開発の持つ複雑性ゆえに、こうした構想が実際にリリースされる製品に具現化されるまでには何年もかかるのが通例だ。

悪意あるファイルを Reader か Acrobat で開かない限りリスクは全くないので、将来問題が起きる可能性を減らすためにあなたにできる最良の手段の一つは(常に最新のパッチを施すこと以外では)Preview をデフォルトのリーダーとして設定しておくことだ。もちろんこれは決して Preview が完璧だと言っているわけではない。けれども、私たちの経験した限りでは、Preview が同じような数のゼロデイ脆弱性や攻撃に直面したことはない。

デフォルトの PDF ビューワーを変更するのは簡単だ。PDF ファイルを一つ、どんなものでもよいので選んで、それを Control-クリック(あるいは右クリック)し、Get Info (情報を見る) を選ぶ。Get Info ウィンドウの Open With (このアプリケーションで開く) 部分で、ポップアップメニューから Preview (プレビュー) を選んでから Change All (すべてを変更) ボタンをクリックすればよい。

あなたが実際に攻撃を受けるリスクは無視できる程度に低いが、Adobe 製品 (Reader、Acrobat、それに Flash) は現在のところクロスプラットフォームの脆弱性の主要な出所の一つなので、それらを常に最新のものにアップデートしておきつつ、使用するのは本当に必要な場合のみに限るようにするのが道理にかなったことと言えるだろう。

コメントリンク10652 この記事について | Tweet リンク10652


(妻の) iPhone を探す

  文: Adam C. Engst <[email protected]>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

断わっておくが、私はプライバシーを非常に大切だと思っている。けれども時と場合によっては、自分が現在どこにいるかの正確な情報を、自分からは何もする必要なしに、誰か他の人に知っていてもらいたいという気持ちが非常に強いこともあるものだ。

iPhone OS 3.0 で Find My iPhone (iPhone を探す) 機能がリリースされたのは私たちにとって最高のタイミングだった。なぜなら、Tonya はこの夏の初めに iPhone を買ったのだが、ちょうどその頃彼女は 100 マイルの AIDS Ride for Life(このあたりで毎年開かれる、募金のためのイベントだ)に向けてトレーニングを始めていたからだ。真夏になって、Tonya はトレーニング量を増やさなければということで、30 から 75 マイル (50 km - 120 km) を 3 時間から 7 時間かけて自転車で走るようになった。(一応紹介しておくと、イベント当日の 2009 年 9 月 12 日、彼女は 100 マイル (160 km) を見事に走り切った。驚くべき成果だ!)

これらのトレーニング走行中、彼女は常に iPhone を自転車のシートパックの中に電源を入れたまま携帯していたが、何か特別のアプリを走らせてみようということはしなかった。休憩して飲み物を飲んだり何か食べたりする際に彼女は時々 Twitter を使って私に直接のメッセージを送ってくれ、これが Boxcar のお陰で自動的に私の iPhone にポップアップした。これで、彼女が具合悪くなったり、怪我をしたり、事故に遭ったりしていないと私は知ることができた。

けれども彼女はそうたびたび休憩するわけではなかった。それに、彼女にしてみればいちいち iPhone を取り出すのが面倒なこともあった。特に雨が降っていたりすればなおさらだ。だから、それほど私は心配していたわけでもなかったのだが、彼女が予定よりも遠くまで走る気になったり、あるいは思ったより長く休憩してしまったりなどの理由で帰りが相当に遅くなってしまったことも何度かあった。

そのような場合、また、特に週末で長い距離を走るような場合には時々、私は彼女の MobileMe アカウントにログインして Find My iPhone (iPhone を探す) 機能を使い、何と、彼女の iPhone を追跡したのだった。こうやって調べるだけで、トレーニングが問題なく進んでいることが手軽にわかり、しかも、電話をかけてトレーニングを邪魔したり彼女が休憩するまで待ったりする必要もなかった。時には、Find My iPhone 機能を使って私が彼女の iPhone 上にメッセージを表示させ、次に休憩した際に見てもらえるようにしたこともあった。

Tonya's-location

(Find My iPhone を使っていて一番イライラするのは、MobileMe にログインしていてもじきにタイムアウトしてしまうことだ。だから、一時間後にもう一度チェックしたければまたログインするしかない。しかも、そのためのウェブインターフェイスが、これまた煩わしい。そしてもう一つイライラするのが、Apple が Find My iPhone ウェブページに iPhone からのアクセスを許さないことだ。だから、家から 55 マイル離れた場所で友人の結婚披露パーティーに出席していた私には彼女の場所を見つけることができなかった。iPhone 以外に私はインターネットにアクセスできるものを持ってきていなかったからだ。あの時も、これが可能だったならばずいぶん助かっていたはずだ。ちょうどその日、彼女は間違った交差点で曲がってしまい、迎えに来て欲しいと言ってきたからだ。幸運にも、その場所には十分なセルサービスがあったので電話が通じた。後日になって、私はこの問題の回避方法を発見したが、それについては 2009-09-30 の記事“iPhone から Find My iPhone を使う”をご覧頂きたい。)

「そんな風に Tonya のプライバシーを侵害するなんてとんでもない!」と怒りに震えて叫び出す人がいそうなのでここで明らかにしておこう。彼女ははっきりと Find My iPhone で自分を追跡してほしいと私に頼み、私が彼女のアカウントにログインできるよう彼女の MobileMe パスワードを教えてくれたのだ。私たちは幸せな結婚生活を送っていて、お互いのコンピュータの中身をしょっちゅう詮索したりはしないものの、相手がすべての内容にフルにアクセスできるという事実にお互い何の不満もない。万一の時のためだ。世の中の夫婦関係でもそういうことが例外ではなく普通の状況になってほしいものだと思う。

Tonya は自転車で田舎の道路を家から長い距離走りながら、もしも携帯電話がほとんど届かないような地域で調子が悪くなったとしても私がきっと見つけられると知ってずっと安心した気持ちでいられた。また、酔っぱらいの射撃とか暴走する改造トラックなど現実の危険に対しても、恐れる気持ちを減らすことができた。もちろん、沼地のモンスターといった漠然とした恐怖もそうだ。

プライバシーを望む気持ちと、いつも誰かに自分の居場所を知っていてほしいと望む気持ちとのこの葛藤には、その人の性別にも関係したところがあるのではないかと思う。私は男なので、遠くに出かける時にも誰かに自分がどこにいるかを知っていてほしいと心配になることはあまりないし、出先で何かが起こることを本気で怖がっているわけでもない。でも、私の知っている女性アスリートの多くは独りでトレーニングする際に自分がどこにいるかを誰かが知っている方がよいと思っているようだし、もしも iPhone を携帯することで連れ合いが遠くから位置を確認することができるなら、それは良いことではないか。

私はもう一歩進めて Apple が Find My iPhone 機能をもう少し開かれたものにするべきだと提案したい。指定した人が Find My iPhone 機能を使えるようにして、その際自分の MobileMe アカウントを全部その人に開放することなくそれができるようにしたらどうだろうか。もちろん、そうした特権はいつでも簡単に停止できるようにしておくべきだし、位置情報を求められる度に、誰が求めてきたのかを含め、そのことを警告するようにすべきかもしれない。

さらにもっと望ましいのは、Apple が Find My iPhone 機能のための iPhone アプリを作って、外出中に信用する人と一緒に手軽に使えるようにしてくれることだろう。結局のところ、家から 30 マイル離れたところにいる Tonya を見つけに出かけなければならないとしたら、私が家を出たあとで彼女の居場所が変わった場合にも簡単にそれがチェックできる方がよいではないか。それに、事故などの恐ろしい状況の場合には、アップデートされた位置情報をどうしても知りたいというのが自然なことだろう。

もう一つ、追加されれば素敵だと思えるのは、ユーザーが指定した時間間隔で iPhone の位置を地図上に表示できる Map My iPhone 機能といったものだ。これも、あなたがアクセスを許した相手だけに提供されるべきものだ。特にニューヨーク州北部の田舎のようにセルサービスが届かなかったり非常に弱かったりする場所の多い地域では、最後に探知できた場所をタイムスタンプ付きで見ることができればずいぶん便利だろう。

このような感じの機能を今すぐに欲しいのなら、AT&T が家族の携帯電話の位置情報を示す FamilyMap サービスを提供している。これは AT&T のすべての携帯電話で使え、iPhone も含まれる。ただし iPhone の GPS 機能を利用することはしないので、セル基地局の三辺測量による不正確な情報に頼ることになる。2台の電話機の位置を示すだけならば月額 $9.99 のサービス料金、5台の電話機ならば月額 $14.99 となる。

コメントリンク10589 この記事について | Tweet リンク10589


Snow Leopard で Apple イベントのバグを追跡

  文: Matt Neuburg <[email protected]>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

どんなメジャーなシステムアップグレードでも、バグが全くないということはあり得ない。けれども、深いところにあるメカニズムで、システム全体としての動作に極めて重要な役割を果たし、しかも長年完璧に働いてきたものの中に破損したところがあるのを見つけたとなれば、これは驚きと言うほかはない。考えてもみよう、Apple は、そのようなメカニズムをいい加減に扱うはずがない。なぜならば、(a) それは決定的に重大であって、(b) 壊れていないもの修理すべからず、だからだ。それなのに、見たところそのような事態が起こってしまったようだ。私が、Apple イベントのバグを一つ発見し、10 月 6 日にそれを Apple に報告した。

Apple イベントとは何か? 私たちに何の関係があるのか? その質問への徹底的な解答(本当に素晴らしい図式も付いている)については私がしばらく前に この話題で執筆したオンラインブックの章を読んで頂きたい。ごく簡単に言えば、Apple イベントとは動作中のいろいろのプロセスが互いにコミュニケーションするために使われるメッセージングのメカニズムだ。Apple イベントこそ、Mac OS X においてアプリケーションをスクリプトで動かすための基盤となっているものだ。これがなければ AppleScript は動かない。(お忘れかもしれないが、私は AppleScript について本を書いたことがある。)アプリケーションに向けて送り出される AppleScript コマンドはすべて、Finder にフォルダの名前を問い合わせるコマンドも、iTunes にアルバムの中のトラックを呼び出させるコマンドも、一つの Apple イベントだ。けれども Apple イベントはそういったことよりもさらにずっと根本的なものだ。Finder で書類のアイコンをアプリケーションのアイコンの上にドロップしてその書類を開くといったような単純なことでさえ、やはり Apple イベントに依存している。

正直言って、私はこのバグを発見した探偵仕事に誇りを持ってはいるものの、実は私にはそれほど深く考える必要もなかったし、このこと全体における私の役割はむしろ受け身の性格の強いものだった。何が起こったのかを順を追って説明しよう。10 月 2 日に、 rb-appscript メーリングリストにある投稿があった。(このメーリングリストが議論するのは rb-appscript、これはスクリプト言語 Ruby と AppleScript のスクリプト可能性との橋渡しをするものだ。)その投稿によれば、その人の書いたスクリプトは iTunes をかなり集中的に働かすものだが、これが Leopard では完璧に動作していたのに Snow Leopard では時々 "Apple event timed out" エラーで停止してしまうのだという。その後 10 月 4 日に、私は AppleScript-Users メーリングリスト でまた別の人が、 その人の スクリプトで(こちらは Microsoft Entourage を動かすものだったが)やはり Leopard では完璧に動作していたのに Snow Leopard では時々 "Apple event timed out" エラーで停止すると言っているのに気付いた。

当初私はたぶん何か外部的な力が、例えば悪いスクリプティング機能追加などがあって、それが何らかの形で物事をうまく行かなくしているのではないか、という程度に考えていた。これは妥当な推測だった。なぜなら、Snow Leopard での 64-bit への移行のために、実際に既存の 32-bit スクリプティング機能追加でいくつかトラブルが起こっていたからだ。

けれどもその rb-appscript ユーザー(彼の名は Nick Forge で、彼はこの物語において非常に大きな役割を果たした功績がある)は、すべてのサードパーティのスクリプティング機能追加をシステムから取り除いた後でさえも問題を再現することができた。その上、彼は非常に短くて、単にループを繰り返して一つの単純なことを何度も何度も実行するだけのシンプルなスクリプトを提供して、これが問題を起こすと思うと言ってきた。そこで私は彼のスクリプトを自分のマシンで試してみた。初めは問題を再現させることができなかったが、それは単に私が十分長い時間このスクリプトを走らせていなかったというだけの理由であったことが分かった。このスクリプトが 20 秒から 30 秒走り続けるようにしてみたところ、私にも彼と同じエラーメッセージが出た。

そこで私の目は開かれた。問題が特定のスクリプト対応アプリケーションによるものでないことは分かっていた。なぜなら、ターゲットが Entourage でも iTunes でも問題が起こったからだ。AppleScript が問題ではないことも分かっていた。なぜなら、rb-appscript は AppleScript ではないからだ。どちらも基盤として Apple イベントのメカニズムを利用しているが、その利用の方法は異なっている。それに、完璧に良好な Apple イベントが、十分な回数だけ繰り返し送られると いつかは エラーに陥るということも私たちには分かっていた。でも、その「いつかは」というのは具体的には何を意味するのだろうか? これを見つけ出すために、私は次のようなスクリプトを書いた:

set i to 0
try
    tell application "Finder"
        repeat -- forever
            set i to i + 1
            count Finder windows
            -- this is the Apple event
        end repeat
    end tell
on error errMsg number errNum
    display dialog i
    error errMsg number errNum
end try

理論的には、このスクリプトは単に永遠に走り続けるはずだ。無害な Apple イベント1個(Finder に現在開いているウィンドウの個数を問い合わせるもの)を繰り返し送り出すだけだ。実際、このスクリプトを Leopard の上で Script Editor で走らせれば、意図通りに永遠に走り続けるので、止めるには Script Editor を強制終了させるしかない。(だから Leopard 上でこれを走らせては いけない。「より安全な」バージョンのスクリプトを、すぐ後でご紹介する。)

けれども、Snow Leopard の上で AppleScript Editor (Script Editor から改名された) で走らせると、およそ 60 秒後に、このスクリプトはフリーズしてさらに1分間ほどそのままになり(あの "Apple event timed out" エラーが起こっているのだ)それからそのエラーを報告する。うまくできているのは、エラーが起きるまでに Apple イベントが何回送り出されたかを、このスクリプトがダイアログを出して報告してくれるところだ。

そして、いよいよここからが「最も面白いところ」だ。大多数の場合、報告された回数は 65000 に近い数字だった。実際、いくつかの場合、それは 65535 に非常に近かった。そして、これは高度に疑惑渦巻く数字だ。なぜなら、この 65535 という数は 2 の 16 乗から 1 を引いた数であって、コンピュータサイエンスにおいて 2 の 16 乗は "short integer" (16-bit 値) のサイズに他ならない。それはまるで、舞台裏の誰かが、 そのスクリプト以外の 何ものかが私たちの Apple イベントの回数を数えていて、16-bit カウンターがリセットされたところで行き詰まっているかのような感じがした。

この時点で、私は「より安全な」バージョンのスクリプトを書いて、それを Apple に送った。それがこれだ:

set i to 0
try
    tell application "Finder"
        repeat -- forever
            with timeout of 5 seconds
                set i to i + 1
                count Finder windows
                if i > 70000 then
                    display dialog "No problem!"
                    return
                end if
            end timeout
        end repeat
    end tell
on error errMsg number errNum
    display dialog i
    error errMsg number errNum
end try

このバージョンが「より安全」である理由は、もしもこれがたまたまイベント数 65535 のリミットを超えた場合には、自分自身で行儀良くストップしてくれるからだ。だから、どうぞあなたもこれを Leopard の上と Snow Leopard の上で両方試してみて、違いをご自分の目で見て頂きたい。このバージョンでもう一つ加えた機能は "with timeout" の行で、これはもしも Apple イベントのエラーが起こった場合にフリーズしている時間を(デフォルトの)60 秒から 5 秒に短縮する。

このスクリプトを Apple に送った後で、私はこれを AppleScript-Users メーリングリストに投稿した。すると、特別に博識な一人のユーザー、Hamish Sanderson(これは偶然ではないが、彼は rb-appscript の著者だ)が、こういう返事を送ってくれた:「舞台裏で数を数えているのは、きっとこいつに違いない。賭けてもいい。return ID のインクリメントだ。」

これで、パズルの最後のピースがぴたりと嵌まった。Hamish の説明はこうだった。あるプロセスが返答を要求する Apple イベントを送り出した場合、返答がいつ返ってくるかは誰にも分からない。そこで、返答が返ってきた時に元の Apple イベントに対応させられるように、何らかの方法が必要となる。だから、Apple イベントを送り出す際には、それに対して return ID を指定する。これは、その Apple イベントを特定するための "short integer" だ。返答には同じ return ID が与えられるので、元の Apple イベントと対応づけることが可能になる。

ところが、自分で独自の return ID を割り当てることはあまり ない。その代わりに、kAutoGenerateReturnID と呼ばれる特別の return ID 値を指定することが多い。その意味するところはシステム自体が return ID をダイナミックにその Apple イベントに割り当てることになるということだ。ならば、システムはどうやってその割り当てをするのか? それは、 最後に 割り当てた return ID に 1 を加えた数にするのだ。こうして、いつか、十分多くの回数 Apple イベントが送り出されれば、その数列の次に来る return ID が 16 進数で FFFF、すなわち 10 進数で 65535 に到達する瞬間がやって来る。符号付きの short integer においては、その値は -1 と等しい。そして、-1 こそは kAutoGenerateReturnID で ある のだ。

この事実が、明らかに、Snow Leopard を混乱させている。それは、1991 年 (Apple イベントが発明された年) 以来、従来のどのシステムをも混乱させることのなかったやり方でだ。Snow Leopard が Apple イベントの return ID として FFFF (つまり -1) を割り当てると、それは return ID を もう一度 増やす指令として解釈される。そこで、その Apple イベントは return ID が -1 として送り出されるのだが、返答が返ってくる際には数列の に来る return ID、つまり 0 となっている。二つの return ID は一致しない! こうして、その返答は元の Apple イベントとの対応づけができない。そこで送り主は返答が 全然 返って こない と思い込み、しばらく待ったあとで、あきらめて "Apple event timed out" エラーを生成するというわけだ。

(私は実証実験として、Apple イベントを繰り返し送り出して、送り出した Apple イベントとその返答との双方の return ID の経過を記録する Cocoa アプリケーションを書いてみたが、これがこのバグに対する上記の説明が正しいことを証明してくれた。)

このバグはマイナーなものに聞こえるかもしれないが、実はこれは非常に重要なものだ。なぜなら、Apple イベントは Mac OS X の舞台裏で起こることのあまりにも多くの点において決定的な役割を果たしているからだ。いずれにしても、このバグは誰のスクリプトをも(それが AppleScript で書かれていようと、rb-appscript であろうと、あるいは Apple イベントを送り出すものならば何でも)壊してきた。背後にいる Apple イベントマネージャはすべての Apple イベントごとに新しい return ID を割り当てるので、遅かれ早かれこの魔法の値 FFFF に行き当たる Apple イベントが現われる。そして、その Apple イベントがどんなものであれそれはエラーに陥るわけで、エラーはごくランダムに起こるように見えるだろう。あなたも、知らないうちにそうしたランダムなエラーがあなたのマシンに起こるのを目撃していたかもしれない。いずれにしても、これはたやすく理解できるバグであって、既に Apple が修正作業中であり Mac OS X 10.6.2 に修正が盛り込まれることを思わせる兆候もある。それがいつ出てくるのかは分からないが。理解が困難なのは、そもそもどうして Apple がこれほど根本的なメカニズムに破損を生じさせてしまったのか、ということだ。

コメントリンク10643 この記事について | Tweet リンク10643


iPod nano、ラジオのインターフェイスと機能で不満だらけ

  文: Glenn Fleishman <[email protected]>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

iPod nano で FM ラジオ放送をチューニングするユーザーインターフェイスはひどい。こう言うと、同僚たちの何人かはびっくりしたようだった。彼らにとって、昔風のラジオダイヤルを模したインターフェイスには何の違和感もなく、期待通りに働く感じがしていたからだ。私がこのインターフェイスのどこをそんなに嫌うのかって? それは、平凡な、良いとは言えないユーザー体験を持ってきて、それで十分だと判断したことが、Apple らしくないからだ。

ラジオの歴史は古色蒼然だ。米国では AM で 80 年、FM で 70 年近くも遡ることができる。ストリーミング放送のインターネットラジオ、ダウンロードできるポッドキャスト、購読・購入できる音楽サービス、オン・デマンドのカスタムラジオ「放送」といったものが隆盛しつつある今日でも、まだ何千万人もの常連の聴取者が地上波のラジオ放送を聴いている。

Apple は元々、iPod に FM ラジオ受信機を埋め込むというアイデアを歯牙にもかけなかった。(AM は、大きなアンテナを必要とするので問題外だ。)そもそも iPod は未来志向のものであって、そこに不格好なアナログ放送を持ち込むなんて Apple の尊厳を損なうもの以外の何物でもないからだ。

けれどもその後、同社は方針を変更して、自社のブランドモデルにサードパーティの FM アドオンを加えることを始めた。そして、2009 年 9 月にリリースされた iPod nano が内蔵の FM チューナーを備えた初めての iPod となった。つまり、今後はもっといろいろの Apple 機器に FM チューナーが見られるようになりそうだ。(ちなみに、同僚の何人かの意見では、この FM チューナーの主な目的はトレーニングジムでエクササイズ室の上に設置されたテレビからジム内オーディオを受信するためではないかという。)

でも、Apple がその最初の進出に際して採用したデザインの選択に、私はすっかり当惑してしまった。Apple の Stan Ng が記者会見で私に語ったところによれば、Apple は何か新しいものを持ってこようと考えていて、そこで FM チューニングを加えたのは、会社としてこの機能にユニークな取り組みができたと判断したからに他ならないという。けれども私には Apple が何か独創的なものを持ってこられたとは思えないし、Apple としてのデザイン標準にかなったものができたとも思わない。そう思う理由を、二つの面から見て行こう。番組プログラミングやストレージオプションの面からと、ラジオ放送チューニングの面から、論じてみよう。その際デジタルラジオについても少しだけ寄り道して触れてみよう。

バッファのアンダーフロー -- この nano で、Apple は直接 iPod の内部に iTunes Tagging ディレクトリを追加した。従来は、そのためにドックとデジタル HD Radio 受信機が必要だったものだ。

けれども、これも別にとりたてて興味深いとか独創的とか言うほどのことでもない。iTunes Tagging は放送された楽曲に iTunes Store 内の購入可能な項目をリンクさせるための Apple 固有の方法だ。これは商売のためのものであって、Apple に関してだけのものだ。もちろん、記憶の補助となるので役に立つという見方もあろう。さっき聴いた曲は何だっけ、というわけだ。現在のところ、Apple が必要とする特定のフォーマット( RT+ つまり RadioText Plus)を使っているのは Clear Channel のみだ。ただ、このデータ提供に対しては非常に大きな興味が寄せられているという話だが。(RT+ は独自規格ではないが、他のオプションよりも多くのメタデータを含んだフォーマッティングを提供する。そのため、聴いた曲を購入可能なものとマッチさせるのがより単純にできる。)

Microsoft は Zune HD 用に別の形のタギングを提供している。こちらの方が、アナログ FM とデジタル FM 双方で曲とアーティスト情報を処理できる点ではるかに優れている。奇妙なことに、Jump2Go という会社が Apple と Microsoft 双方のやり方に情報を提供している放送局に向けてタギングのテクノロジーを供給している。明らかに、Microsoft は Apple のものより的確度は劣るかもしれないがより包括的な方法を採用して曲の情報のマッチングに対処しているのだ。

一時停止が悩みの種 -- iPod nano にはラジオ用の一時停止ボタンもある。これで、最大 15 分前までのオーディオを遡って聴くことができる。この一時停止機能は Sirius がポータブル衛星放送受信機、$169.99 の Stiletto 2 で提供しているものほど役に立つ機能ではない。Stiletto 2 は最大 100 時間分の番組をプログラミングで予約録音でき、それとは別に個別の楽曲も 10 時間分保存可能、さらに現在チューニングされているチャンネルを最大 60 分巻き戻して聴くことができる。

確かに、Stiletto 2 は毎月の料金を払って Sirius を購読しなければならない。(料金は番組のオプションによって $6.99 から $19.99 までだ。)けれどもラジオ放送は単純に無料であって、特定のプロバイダに依存するものではない。毎月の契約が何かの限定理由の一部とはならないはずだ。

Stiletto 2 のサイズは大きめで、ほぼ iPod classic と同じくらいだ。でも、それもやはり問題ではない。8 から 16 GB もストレージ容量があれば、どうして iPod nano が最大 60 分あるいはそれ以上の設定可能なデータをバッファすることができないのか理解に苦しむ。

もう一つ、奇妙にも抜け落ちているのが、iPod nano があとで聴き直すためにプログラミング録音することができない点だ。多くの報道で iPod nano の一時停止機能は「ラジオの TiVo」と形容されたが、TiVo はタイムシフトできる。今録画して、あとで再生できる。単なる一時停止だけではない。

もちろん、予約録音は難しいかもしれない。そのためにはまた新しいインターフェイスを、すでにオーバーフロー気味の iTunes 9 の中に詰め込まなければならないだろうから。でも不可能ではないはずだ。例えば「これこれの指定された放送局の番組を今から 2 時間録音せよ」程度の単純なものならば、十分簡単に iPod nano のスクロールホイールでできるのではないだろうか。

予約録音であろうとなかろうと、とにかく番組の録音ができないというのは、Apple がレコード会社の機嫌をとろうとしている匂いがぷんぷんする。衛星放送ラジオは以前、音楽の録音に関してちょっとした争いを経験しており、その後さまざまの和解が結ばれた。Sirius もライセンス料金を支払っており、そのことが確かに役立った。それに、Stiletto 2 プレイヤーから音楽を書き出すことはできない。

抜けていることばかり -- iPod nano がデジタル FM を録音できないことに私が何も文句を言っていないことにご注意頂きたい。デジタル FM 放送はその認可を受けた米国フォーマットの唯一のオーナーである iBiquity 社によって HD Radio の名前で市場に出ている。Zune HD は、米国のラジオ放送局のおよそ 15 パーセント(これには多くの公共ラジオ局も含まれる)が提供する高音質のデジタル FM 番組を受信できる。

デジタル FM 放送局はより低音質のチャンネルも合わせて放送することができ、多くの放送局が実際そうしている。FCC は現在でも各 FM 放送局の最初の HD Radio チャンネルが必ずアナログ放送のミラーとなっていることを義務づけている。

iPod nano がデジタル FM を扱わない理由は、本体のサイズがあまりにも小さいために HD Radio のチューニングに必要な第一世代のポータブルチップを搭載することがどうしてもできないからだ。それに、HD Radio にデジタルだという側面以外に将来大きな需要が期待できるものがあるかどうかは不透明だ。

シアトルや、大多数の大都市では、すべてのメジャーな商用および公共ラジオ放送局がアナログとデジタルを併用している。けれども、それは依然として全体の中ではほんの一部分だ。

Apple が今後 iPhone、iPod touch、あるいは iPod classic に HD Radio 受信機を組み込む決断をする可能性はある。小さなサイズのフォームファクターの中にデジタルラジオを入れることに Microsoft が成功したのだから、Apple に同じことができることを期待するのは不思議ではないだろう。

ダイヤルトーンが聴こえない -- ここでようやく話は私の iPod nano への不満の一番の要点にたどり着く。確かにタギングは問題だ。一時停止も問題だ。その他問題はいろいろあるだろう。でも、多くの人たちがイライラさせられるのは、そして将来もイライラさせられることになるのは、そんな問題ではない。(それに、そうした問題の一部は将来のラジオ局のアップグレードやファームウェアの変更などで消滅することもあるだろう。)

でも、私がどうしても我慢できないのは、iPod nano でラジオのスイッチを入れた時に、この 2009 年の今、昔通りのアナログチューナーを真似たインターフェイスを使うことがどれだけ馬鹿げたことかと感じさせられることだ。周波数なんて見たくもない。そんなものを気にすることさえ不必要なはずだ。

FCC は周波数をライセンスし、個々のラジオ放送局ごとにコールサインを割り当てる。ほとんどのラジオ放送局は自局のコールサインを低速度のデータとしてアナログ信号の中に埋め込んで送信している。これを Radio Data System (RDS) という。[訳者注: Wikipedia ページにある通り、日本のラジオ放送局では RDS は実施されていません。]

iPod nano は(それに Zune HD も)このデータを探知して、表示できる。データにはアーティストや曲に関する情報や、道路の交通渋滞情報なども含まれていることがある。あなたが周波数でなくどこかの放送局のコールサインをあらかじめ設定してそれを放送局の選択に使った場合、チューニングがその局に合えばそのコールサインが抽出される。

もしもこれが自動車のカーラジオならば、iPod nano のチューニング方法も悪くないだろう。動き回るにはスクロールホイールを使う。中央のボタンを押し続ければメニューが出て、放送局をお気に入りに追加できる。Menu を押せばメニューを使ってお気に入りメニューを呼び出せる。巻き戻しあるいは早送りを押せば次の局にジャンプする。押し続ければダイヤルを上下にスキャンする。

それのどこが不満かって? この国には、いろいろの違ったラジオ市場がある。Apple は、周波数帯の一部をスキャンして受信できる信号と放送局のコールサインをすべて取り込み、米国市場にあるすべての放送局のデータベース(サイズにして 50 KB を超えることはないだろう -- そう、50 キロバイト だ)を利用することができるではないか。(アナログラジオについては同じことが多くの他の国でもできると思われる。)

ほんの一つか二つのラジオ局とコールサインしかないならば、iPod nano としては(たとえそれらが保存されたもの以外の放送局であっても)その土地の放送局マップと共にラジオをロードできるはずだ。そうなれば、提示された放送局マップをあなたがカスタマイズする(聴きたくないと思う局を削除する)こともできるだろう。そして、あなたが iPod nano を持って別の都市に行った時には、iPod nano がそのことを認識して「あなたはどうやらノースカロライナ州の Raleigh にいるようですが、Raleigh の放送局リストをロードしていいですか?」のように問いかけてくれたらどうだろう。合わせて、その放送の内容(カントリー音楽、クラシック、ニュース、公共ラジオ放送、その他)も表示してはどうか。

さらにもう一歩進めることもできるだろう。市場が既知とすれば、もっと他のデータもロードできるかもしれない。例えば、録音中でないならば番組のスケジュール情報の表示はどうだろうか。もっとも、それをするには常時のアップデートが必要となり、Apple の側でたくさんの複雑な調整が必要となるだろうが。けれども現にその情報は商業的に入手可能となっているので、Apple としてはデータの再ライセンスを受けて、数日に一回程度同期の際に少量のデータを iPod nano に送ってアップデートすることができるはずだ。

上級メニューオプションか、あるいはどれかのボタンの長押しなどで、低出力の放送局あるいはリピーター(田舎の地域でよく見られるもの)からの電波を受信するチューナーを出してはどうだろうか。また、スポーツジムの室内受信でもこれは使えるかもしれない。

ここまで述べてきたのは、単に応用に向けた一つのアプローチに過ぎない。私は自分がインターフェイスのデザインが巧みだなどとは思っていない。それは、明らかに Apple の人たちの方が断然優れているだろう。けれども私は一つの質問だけ投げかけたい。どこかの放送局が電波塔から一秒間に何回原子を励起させているかの数字に、誰が興味あるだろうか? 私たちが興味あるのは、放送局の名前(それを知っている場合)か、さもなくば放送内容(局名を知らない場合)ではないのか?

チューン・イン、チューン・アウト -- どこか別の会社なら、そんなことはごく些細な揚げ足取りか、笑って済ませられる苦情に過ぎないだろうし、会社の基盤構造やソフトウェアの能力でははるかに手の及ばない話なのだろう。けれども、Apple ならば話は違う。Apple は、一台の電話機に、複数の出所から届く GPS 風のデータを統合して、それを API 経由で利用できるまでにした会社だ。さらには、休日の午後に、ガムの包みと一緒にビデオカメラをポケットに入れて出かけることも可能にした会社だ。(私は iPod nano のビデオ画質が好きではないが、それでもこのサイズにしては驚くべきものに違いない。)

Apple が何か機能を追加するときは、それはクラス最高のものでなければならない。我々があまりにも慣れ切って、どんなに時間を浪費しているかさえ忘れてしまった、そういうプロセスを徹底的に考え直したようなものでなければならない。Apple は、もう一度ホワイトボードの前に立ち戻って、ラジオのストレージとチューニングのニーズについて考え直して欲しい。

コメントリンク10605 この記事について | Tweet リンク10605


1,000 号の TidBITS:全ては我々の読者のため

  文: Adam C. Engst <[email protected]>
  訳: 亀岡孝仁<takkameoka@kif.biglobe.ne.jp>

これが我々の TidBITS の 1,000 号となる、そして我々もここまで来れたことが信じがたいほどである。Tonya と私が 1990年4月に最初の足元の定まらない出版の第一歩を踏み出してからもう 19 年を超える。しかし我々は今でも元気で、これまでにもまして書きそして出版し続けている。

我々が仲間内で 1,000号には何を書こうか雑談していた時、Matt Neuburg は冗談めかして言った、"何も特に!" 彼の言いたい所は次の様なものである、ここ数年の間に我々は出版の主たる手段を毎週出す号から個別の記事へと移行してきており、記事は公にする準備が出来たそばから TidBITS Web サイトに載せている。

でも、号は存在し続ける;そうでなければ、それが 1,000 号になることはない。我々は、今でも番号をつけた電子メール号を送り出している、そこにはその前の週に Web 上で出版された記事を組み合わせて載せている。それだけでなく、我々 (とりわけ Jeff Carlson, Joe Kissell, そして私) は、週末と月曜終日をかけて個々の記事を再度編集して、物事の最新状況を一番良く反映する様磨きをかけている。そして 我々の四つの版 (テキストと HTML での全テキスト版とそしてテキストと HTML でのお知らせ版) に対する定期購読者はほぼ 31,000 近くおり、他の方法よりも多くの人が TidBITS をメール経由で読んでいる。

しかしながら Web と記事ベースモデルに我々が移行したお陰で、メールは徐々に昔の様には焦点が当たらなくなってきている。当時、我々の Web サイトはメールで送り出した記事の単なるアーカイブでしかなかった。今や、我々のサイトの個々の記事は一般的に数千の人達によって読まれ、そして我々の RSS フィードは毎週 15,000 以上の人達によって読まれる。時折、記事が Daring FireballSlashdotの様な集積サイトにリンクされると、20,000 を超える人によって読まれることになることもある。

この様な大きな数字に夢中になるのも良いが - そして TidBITS のスタッフも間違いなくこれらには注意を払うが - 購読者の数やページビューの数がどの様に収入に変換されるのかを越えてこれらの数字がいったい何を意味するのだろうか我々も考え始めた。例えば、我々も我々の Web サイトに幾つか広告を表示させるのに Google AdSense を使っているが、Web に表示する広告が TidBITS にとって相当の収入源とはなることは無いであろう。例を挙げると、250,000 から 350,000 のページビューに基づいて Google から月に $350 から $450 の間の収入を得るとして、例えこれを倍に出来たとしても一人のスタッフの月給分にもならない。(殆どの TidBITS の固定収入は我々の企業スポンサーから来ているが、これらはあるコミュニティとのつながりの話であって何もページビューの数とは連結していない。)

そうではなくて、TidBITS に関してこれまでもいつも大事であって、そしてインターネットの振舞いが更に無責任になって行くように思えるにつれて我々にとって大事さが増しているのは、我々の読者の質である。他の出版事業で働いている仲間から、読者からの卑劣なコメントや怒り狂ったメールに関する苦情を聞くにつれ、私はその種のドラマと毎日付き合う必要のないことに私の幸運の星に感謝している。

従って、我々が良い仕事をしているかどうか知りたい時は、我々は我々の読者に眼をむけることにしている。自明だとは思うが、生の数字にではない、もし我々が提供したある機能をほんの少しの人しか使っていないとすると、その機能が役に立っていないか或いは我々がその存在を知らせる努力を十分していなかったかのどちらかである。

代わりに、我々は読者とのやり取りの量と質を見ている、そしてその両方を改善出来る方法を探そうとしている。例えば、Glenn と Jeff と私が設計した TidBITS Commenting System は、我々の見るところでは、大成功である。殆どの記事がコメントを受けていて、全く共通な記事だと 10 から 15 のコメントが寄せられる。(これまでに最も多くのコメントが寄せられて記事は - 我々がコメントを受け付けている 30 日間で 91 のコメントが寄せられた - 私の "我々は識字能力絶滅後のテクノロジー時代に突入したか?", 2009-08-18 である)。

もっと良い面を言うと、コメントはしばしば前後関係や更なる詳細を引出し、質問を誘起しその答えが記事の有用性を思いもかけない方にまで延長させ、或いは見直しを必要とする事柄の指摘にまで及ぶ (我々はその様な手抜かりに対応すべく記事を修正した時は必ず他のコメントを残すようにしている)。我々のメール版ではコメントを載せていないが、これは余りに大きくなりすぎて収拾が付かなくなるためで、個々の記事にはコメントの数を示しそれらへのリンクも示しているので是非ご自分でコメントを読みご自分のも残して欲しい。

我々のサイトのコメントの質について私は実際の所驚いてはいない、と言うのも TidBITS Talk でも同じことをずっと見てきたからである。そこでは Apple に関連した話題について衰えることなく会話が続いていて、我々が TidBITS Commenting System を発表した後でも衰えていない。

我々は Take Control電子本シリーズも TidBITS にとっての大事な成功の一つだと見ている。明らかに、Take Control としては売上げが成功の第一指標であり、これらの売上げは台所裏の更新の多くを賄う助けとなり、お陰で TidBITS Web サイトの現代化とそして Take Control Web サイトを手書きコードの自前のオペレーションからユーザーアカウント付き (もうすぐ公開) のデータベース基盤のサイトへの移行が可能となっている。更に電子本は我々の多くの友人の収入への寄与も大きく、彼らが自営の独立ライターとしてやっていく手助けとなっているのは、大変ありがたいことである。

金銭はさておいても、おびただしい数の読者が感謝の気持ちを書き送って来てくれていて、それによって我々もこれらの電子本はその際立った品質に対して多くの人から認められていることを知ることが出来ている。我々の電子本の殆ど全部を買ってくれたり、或いはそれを読んだお陰で Mac をより有効に使える様になった読者を持てている事から、我々も良い仕事していると自覚できている。我々は、電子本に関して定常的に際立って質の高い質問やコメントを見ており、このお陰で我々も人々が何を知る必要があるかを理解し電子本の改定や改善に役立たせることが可能となっている。

まだフォロワーの数は多くは無いが、 TidBITS Twitter アカウント (ヘッドラインや新しい記事へのリンクを実時間でつぶやく) は成長し続けており 1,300 のフォロワーに近づいている。しかし私がそれよりも興味を持つのは TweetDeck で @TidBITS に対する私の検索結果を眺めることである、なぜならば誰かがつぶやき返すとか TidBITS の記事のことに触れそして我々を褒めてくれるとかする時は、その記事はきっと有益であったか或いは興味深いものであったに違いないと思うからである。Twitter では、つぶやき返しは承認の印であると解釈するのが重要である;Twitter は未だ我々にとっては Web トラフィックの主要なソースとはなっていない。O'Reilly Media の代表である Tim O'Reilly が私の "我々は識字能力絶滅後のテクノロジー時代に突入したか?" の記事へリンクするつぶやきを載せた時ですら、私が Twitter にトレースバック出来た限りではほんの少数の人が読んだだけである、理論的に言えば Tim の 975,000 のフォロワーによって見られた にもかかわらずである。

その他の試みはそれ程成功していない。TipBITS は、我々と読者に我々のサイトの右サイドバーにヒントを載せることを許す、我々にヒントを基にした内容を提供する手軽な手段を提供してくれるが、これまでの所読者からの上梓は多くない。そのインターフェースは TidBITS Commenting System よりも多少面倒だとは思うが、真の理由は、独立の項目を公にするのはただコメントを残すのよりも勇気の要ることであるからではないだろうかと思っている。我々も引き続き工夫を重ねるが、もしこれが主としてスタッフが生成したコンテンツしかない場合でも、読者が有用であると思うのであればそれで良いと思っている。

Macworld Communications の前のプレジデント兼 CEO で今は IDG Ventures にいる Colin Crawford が最近 Twitter 経由で私にコメントしてきた、"価値があるのは参加者が熱心なコミュニティである - それがメディア会社が焦点を当てるべき所である。" Colin は長いことメディア業界を見てきそして働いてきた、そして私は彼は正しいと思う。これぞ、なぜ我々の読者がTidBITS Commenting System に飛びついてくれそして - 事業の観点から - 我々の Take Control 電子本がどれだけ良く受け入れられたかを見ることがどれ程満足感を与えてくれるかの理由である。

我々が 2000年までに世界を制覇するというおふざけの目標を見捨ててから (そして明らかに達成出来ていない) しばらくになる、そして TidBITS がインターネット上で、或いは Apple の世界に於いてすら、一番読まれる出版物になると言うのはありそうも無いのは明らかである。なぜならば、我々は全ての細々としたものを採りあげたり或いは注目を集める論争を巻き起こしたりするよりも、最も重要なニュースや製品に焦点を当てる方が好きだからである。

そして何と、私はそれでいいのである。もし TidBITS の経営が Take Control と TidBITS スポンサーで何とかなり我々も高品質の内容を出版し続けられ、その結果我々の読者もより生産性が上がりそして他の TidBITS コミュニティとも建設的に関わり合えるのであれば、私は幸せである。

こんなことを言うのは殆ど考えられないことかもしれないが、次の 1,000 号も元気でやっていけたらと願うものである。これを可能にしてくれた我々の読者に感謝する、そして我々のスポンサー、我々の編集者、我々の翻訳者、そして何らかの方法で TidBITS に貢献してくれた人達、皆さんにも感謝したい。

コメントリンク10653 この記事について | Tweet リンク10653


TidBITS 監視リスト: 注目のソフトウェアアップデート、19-Oct-09

  文: Doug McLean <[email protected]>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

Flying Meat の Acorn 2.1 は、シンプルな画像エディタのメンテナンス・アップデートだ。変更点としては AppleScript のサポート、Hex Color Picker の新設、インターフェイスの刷新、JSTalk サポート、64-bit サポート、raw 画像のサポートなどがある。また、画像に添えてルーラを表示するオプションが追加され、レイヤーを階層グループに分けて整理することができるようになり、スクリーンショットを撮る際に個々のウィンドウをそれぞれ独自のレイヤーに入れることもできるようになった。それから、追加された編集ツールも多数あり、主なものとしては Dodge、Burn、Clone、Smudge、Perspective Transform、Clouds フィルタなどがある。(新規購入 $49.95、アップデート無料、8.1 MB)

Nisus Software の Nisus Writer Pro 1.4 は、次第にパワフルになるこのワードプロセッサの機能追加アップデートだ。この最新バージョンではいくつかの内蔵コマンドが追加され、参照文献マネージャ Bookends に付属のマクロに置き換わって働くようになった。これらのメニュー項目で、書類をスキャンしたり、引用を挿入したり、参照文献を見つけたり、またプログラムを離れずに Bookends に切り替えたりもできるようになった。(新規購入 $79、アップデート無料、151 MB)

Sustainable Softworks の Phone Amego 1.0.8 は、ユーザーが Bluetooth 携帯電話(iPhone を含む)を Mac からコントロールできるソフトウェアのメンテナンス・アップデートだ。この最新バージョンでは Google Voice のログインオプションを改善・拡張し、一つのコンタクト項目の中の複数の電話番号を Call ウィンドウから選べる機能や、Apple USB モデムを使った固定電話のサポート、Call ウィンドウからダイヤル機器を選択できるオプション、かかってきた通話から Google Voice 通話を識別できる機能などを追加している。($20、アップデート無料、1 MB)

Ambrosia Software の Snapz Pro X 2.2.1 は、静止画像およびビデオによりスクリーンキャプチャをする人気のユーティリティのマイナーアップデートだ。このアップデートでは Snow Leopard における日本語文字入力と衝突していたホットキーを修正し、ディスプレイあるいはコンピュータをスリープさせた際にコンソールに現われていた誤った警告に対処し、Mac OS X 10.4 Tiger の走る PowerPC ベース Mac での録画のサポートを復活させた。また、QuickTime ムービーに保存する際のパフォーマンスが改善され、詳細は示されていないがいくつかのマイナーなバグも修正された。($69、アップデート無料、11 MB)

Apple の Performance Update 1.0 は「少数の顧客から報告のあったハードドライブが断続的に一時停止する問題に対処」する。このアップデートは Intel ベースの Mac(大多数はラップトップ機種だが、一部の iMac および Mac mini 機種も含まれる)のためのもので、ソフトウェア・アップデートから、または Apple のサポートダウンロードページから入手できる。インストール手順の説明は Apple のウェブサイトにある。(無料、300 KB)

Rogue Amoeba のAirfoil 3.4 は、ワイヤレスオーディオ配布ツールの大きなアップデートだ。この最新バージョンでは、オーディオサブプロセスを持つアプリケーション(例えば Google Chrome や Dashboard など)で、サブプロセスを一つのグループに組み合わせることによりハイジャック機能を改善した。QuickTime Player、Safari、その他の WebKit アプリケーションでは即時のハイジャックが可能となり、アプリケーションを再起動する必要がなくなった。また、Instant Hijack コンポーネントが改良され、稀にしか起こらないが深刻な Snow Leopard 互換性の問題がいくつか修正された。それから、Griffin Technology の Radio Shark USB ラジオを Airfoil と共に使う人のために Radio Tuner ウィンドウが新設された。($25、アップデート無料、10.1 MB)

Maintain の Cocktail 4.5.2 は、この汎用メンテナンスツールのメンテナンスおよび安定性アップデートだ。この最新バージョンでは多数の問題に対処が施され、例を挙げれば 32-bit Mac で CPU 使用量を大きくしていたバグや、時として Cocktail が誤ってディスクユーティリティとの問題を報告することのあった問題、QuickTime X との互換性の問題、その他詳細不明だが多数のマイナーなバグなどが解決した。($14.95、アップデート無料、2.0 MB)

Evernote の Evernote for Mac 1.5 は、ノート取り・スニペット収集ユーティリティのメンテナンス・アップデートだ。この最新バージョンでは Windows クライアントで作った Ink ノートを見る機能や、ソフトウェア・アップデート経由で Evernote のベータプログラムにアクセスできるオプション、それからフランス語、ドイツ語、イタリア語、スペイン語の各翻訳版が追加された。また、Account Info ウィンドウにあなたの電子メールアドレスが表示されるようになり、いくつかのバグ、例えば Safari ツールバーボタンが他のボタンをツールバーからはじき出してしまった問題や、句読点で囲まれた単語が検索で見つからなかった問題などが修正された。(無料、15.8 MB)

Apple の Logic Pro 9.0.2 は、同社の旗艦レベルのオーディオ録音プログラムへの安定性およびメンテナンス用アップデートだ。主な変更点を挙げれば、MIDI ノートに Flex Marker をスナップして配置できる機能、置き換えモードでのパンチイン録音の正しい動作、I/O プラグインにレイテンシ測定オプションを追加、TDM プラグインの挙動の修正などがある。Logic Pro 9.0.2:リリースノートは Apple のウェブサイトにある。このアップデートはソフトウェア・アップデートから、または Apple のサポートダウンロードページから入手できる。(新規購入 $499、アップデート無料、183 MB)

Apple のiMovie '09 8.0.5 は、iLife '09 のコンポーネントである Apple のビデオ編集プログラムの互換性アップデートだ。最新型の iPod nano を使って撮影したビデオの読み込みサポートを改善したほか、このバージョンでは iFrame のサポートが組み込まれた。iFrame は H.264 ビデオと AAC オーディオ圧縮を採用したビデオフォーマットだ。(今週、iFrame フォーマットで録画する最初のカメラが2機種、Sanyo からデビューした。Sanyo VPC-HD2000A と Sanyo VPC-FH1A だ。)この iFrame で注目すべきなのは、録画したものを iMovie でネイティブに編集できる点だ。広く採用されている AVCHD を使ってメモリやハードディスクに録画されたビデオは、まず AIC (Apple Intermediate Codec) にコード変換しなければ編集できない。iFrame は、こうした編集スタート時の所要時間を減らすとともに、ビデオが占有するディスク容量も減らすと謳っている。iMovie '09 8.0.5 ではまた、再生中に iMovie アプリケーションウインドウのサイズを変更する際の問題も修正している。(アップデート無料、35.56 MB)

Shirt Pocket Software の SuperDuper 2.6.2 は、このバックアップとディスククローン作成ユーティリティにいくつかの新機能や改善を加えたアップデートだ。変更点としてはパフォーマンスの拡張、保存先ボリュームが登場すれば自動的にバックアップを開始する Backup on Connect 機能の新設、新しい Eject After Copy 機能、スパースバンドルディスクイメージのサポートなどがある。変更点のフルリストはプログラムの中から Help > Revision History を選べば読める。このアップデートは Intel ベースと PowerPC ベース双方の Mac をサポートし、Mac OS X 10.4 かそれ以降を要する。(新規購入 $27.95、アップデート無料、2.8 MB)

Bombich Software のCarbon Copy Cloner 3.3 は、この古参のバックアップとディスククローン作成ユーティリティのメンテナンス・アップデートだ。主な変更点としては、HFS+ ファイルシステム圧縮、Snow Leopard での Finder と Disk Utility への互換性改良、複数のファイルを拡張属性を付けてバックアップする際のパフォーマンス改善などがある。また、いくつかの問題点にも対処が施され、主なものとしては "Archive modified and deleted items" オプションを使っている際に目標についての互いに衝突するレポートが消去できないという報告が誤って出ていたバグ、ファイルレベルモードで "Backup everything" のクローン方法を使っている際に Time Machine データベースが含まれてしまったバグ、それにバックアップ作業の最中にディスクが消えた場合にソースやターゲットのメニューがアップデートされなかったバグなどがある。変更点のフルリストは Bombich Software のウェブサイトにある。(無料、3.2 MB)

コメントリンク10645 この記事について | Tweet リンク10645


ExtraBITS、19-Oct-09 版

  文: TidBITS Staff <[email protected]>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

これは必見! Snow Leopard の写真 -- 自然に生息するユキヒョウ (snow leopard) の素晴らしい写真で、写真家 Steve Winter が栄誉ある 2008 年 Wildlife Photographer of the Year 賞に輝いた。目を見晴らせるこの写真は、中央アジアの山岳地帯で 13 カ月にわたって猫たちを追いかけ撮影した努力の結晶だ。(リンク投稿 2009-10-19)

Sidekick 逆転: Microsoft がユーザーデータの大半を回復 -- T-Mobile Sidekick のユーザーには嬉しい知らせだ。一週間の努力の結果、Microsoft は失われたように見えていたコンタクト情報、写真、その他のユーザーデータのうち(すべてとは言えないまでも)大半を回収することができ、これから復旧作業を始めるところだという。また、Microsoft は問題の影響を受けたのがほんの少数のユーザーのみだったと見られるとも述べた。(リンク投稿 2009-10-15)

iPhone、ハイカーを襲った熊の気をそらす -- CIO.com の Tom Kaneshige が語るところによれば、バーモント州の情報セキュリティ最高責任者の Kris Rowley がハイキング中に、一頭の若い熊と遭遇した。他に何も手に持っていなかったので、彼女は熊の気をそらすために iPhone を投げ、無事逃れることができた。さて、その結末は? 彼女は二日後に iPhone を回収したが、どうやら iPhones は耐熊性能は持っていなかったようだ。(リンク投稿 2009-10-13)


TidBITS Talk/19-Oct-09 のホットな話題

  文: Jeff Carlson <[email protected]>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

Time Machine がバックアップを壊す -- Time Machine はハードディスクが一杯になると古いバックアップを消去するが、例外的な状況においてはこれが適切な挙動と言えないこともある。(メッセージ数 23)

AT&T は契約期間が終わると iPhone をアンロックするか? -- AT&T は自動的には iPhone のアンロックを行なわない。AT&T はそうするべきなのか否か、人々がアンロックされた iPhone を欲しがる理由は何か、という議論が起こる。(メッセージ数 14)

デジタルカメラの問題 -- カメラをキーボードの USB ポートに繋ぐと、画像の転送に必要なだけの電力が供給されないことがある。どうすればこの問題が避けられるかを学ぼう。(メッセージ数 19)

Quicken の未来は? -- Intuit がついに Quicken の新バージョンを出すのはいつになるのか、それはどんなものになるのか、そして、オンラインに保存されたデータの安全性についてユーザーにどのような保証がなされるのか? (メッセージ数 5)

Mac の同期でアクセス拒否の問題 -- ある読者の二台のマシンの間での同期が、どうやらアクセス権の問題で妨げられているらしい。これは、アクセス権修復をすれば直るのか? (メッセージ数 4)

iPhoto (8.1) で「統合」のバグ -- iPhoto で複数のイベントを融合させると、ある読者のところでは予想外の挙動が起こる。(メッセージ数 5)

義理の母に贈るべきビデオカメラは? -- 多くの低価格モデルに比べて一段高い機能を持つビデオカメラを購入したいという読者が、意見を求めている。(メッセージ数 3)

Mac Pro 用のオーディオインターフェイス -- 誤って Mac のオーディオ入力ポートを壊してしまった読者が、アルバムのデジタル化のための別方法を探している。関連した話題として、Ion USB ターンテーブル(LP レコードプレイヤー)についての意見も出る。(メッセージ数 5)


tb_badge_trans-jp2

TidBITS は、タイムリーなニュース、洞察溢れる解説、奥の深いレビューを Macintosh とインターネット共同体にお届けする無料の週刊ニュースレターです。ご友人には自由にご転送ください。できれば購読をお薦めください。
非営利、非商用の出版物、Web サイトは、フルクレジットを明記すれば記事を転載または記事へのリンクができます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありません。告示:書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017

©Copyright 2009 TidBITS: 再使用は Creative Commons ライセンスによります。

Valid XHTML 1.0! , Let iCab smile , Another HTML-lint gateway 日本語版最終更新:2009年 10月 28日 水曜日, S. HOSOKAWA