TidBITS#1016/01-Mar-2010 TidBITS#1016/01-Mar-2010iPhone にはマルチタスクのサポートがもっと必要か？ それはその通りだ。だが、この「マルチタスク」という言葉は iPhone においては具体的に何を意味するのだろうか？ Adam がこの話題を掘り下げて探究する。今週号ではまた Aperture 3.0.1 のリリース、マルチプラットフォームの企業においてかなりの程度に Mac がサポートされているという調査結果、YouTube やその他の Google サービスが非常に古いウェブブラウザのサポートをやめることなどを考察する。Jeff Carlson は Apple Mail で自動補完が誤ったアドレスを入れてしまう問題をどうやって予防したか説明し、Matt Neuburg はパスワード管理用ウェブサイト Clipperz を使ってみた喜びを語る。今週注目すべきソフトウェアリリースは Digital Camera Raw Compatibility Update 3.1、PDFpen 4.6 と PDFpenPro 4.6、Keyboard Maestro 4.1、それに Camino 2.0.2 だ。
記事:
----------------- 本号の TidBITS のスポンサーは: ------------------
---- 皆さんのスポンサーへのサポートが TidBITS への力となります ----
文： Jeff Carlson <[email protected]>
訳： 亀岡孝仁<takkameoka@kif.biglobe.ne.jp>
Apple は Aperture 3.0.1 をリリースした。同社によるとこのプロ仕様の写真管理ツールの新しいバージョンに関する報告されている重要問題を修正したとしている。どんな新しいソフトウェアリリースでもいったんその試験プールから外のシステムに曝されると多かれ少なかれ問題に遭遇するものだが、私は多くの写真家、TidBITS の読者、そして他の同僚から、Aperture 3 はその出荷が早すぎた様に見えるという話を聞いた。(私も今月初めにリリースされた後少しいじってみたことがあり - "Apple、 Aperture 3 をリリース" 9 February 2010 参照 - そして完璧なクラッシュを一回と動きの悪さも経験したが、それが判断に影響する程ではなかった。)
バージョン 3.0.1 に対するリリースノートを見ると、このアップデートは全体的な信頼性を向上そして以前のバージョンからのアップグレードと写真を iPhoto からそしてカメラから直接インポートすることに焦点を当てている。"かなり手の入れられた写真を処理する時" のメモリー使用も改善され、そして新しい Faces と Places 機能にも改善が施されているが、どうもこれら全てがユーザーにとっては問題の引火点だったようである。
他の変更には、複数の画像或いはコンタクトシートを印刷、外部エディタを使って写真を編集、Definition と Straighten 修正が適用された写真を表示、ネットワークボリュームにある Aperture ライブラリにアクセスする時、等々の問題の修正も含まれている。このアップデートは Software Update 経由か独立の 29.41 MB ダウンロードとして入手可である。
コメントリンク11038 この記事について | Tweet リンク11038
文： Adam C. Engst <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
さかんに iPhone ばかりがもてはやされるこの時代だが、Mac がまだまだ順調だというニュースを聞くのは嬉しいことだ。今回紹介する最新の統計データは、 Enterprise Desktop Alliance (EDA) の発表したものだ。ここは、企業向けソフトウェアの会社が集まった企業連合（コンソーシアム）で、マルチプラットフォームの企業の必要に焦点を定めている。EDA がつい最近まとめたアンケート調査によれば、大規模なマルチプラットフォームの組織で働く 322 人の IT 管理者のうち 66 パーセントが、今後一年間に自分のサイトで Mac の台数が増加すると予測している。（公正を期すために言えば、この数字は昨年の調査結果より少し下がっている。昨年は回答者の 74 パーセントが増加を予想し、73 パーセントが実際に増加をみたと答えた。）Mac を選んだ主たる理由として挙げられた中に意外なものはなかった： ユーザーの嗜好、生産性の向上、技術サポートの容易さなどだ。
また、この調査にはマルチプラットフォーム企業の IT 管理者が直面する大きな問題は何かという質問も含まれていた。回答者全体の 79 パーセントで「かなり」か「極めて」を占めていた上位二つが、オペレーティングシステム間のファイル共有と、セキュリティだった。その後に僅差で続いたのが、クライアント管理、Active Directory 統合、クロスプラットフォームでのヘルプデスクや知識ベースのサポートだった。興味深いことに、企業内での Mac と PC の等価性は 2009 年には回答者の 81 パーセントにしか重要でなく、2008 年の 94 パーセントよりも下がった。
この調査がどのように行なわれたか、その他にどのような結果が出たかなどが知りたければ、詳細を記した PDF ファイルがダウンロードできる。
もしもあなたがマルチプラットフォームの企業で働いておられるなら、どうぞコメントにて、あなたのところでは Mac が以前より重視されているかそうでないか、大きな問題点は何か、などについて教えて頂きたい。
コメントリンク11037 この記事について | Tweet リンク11037
文： Glenn Fleishman <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
Google の YouTube は今後の機能アップグレードのサポート対象からいくつかの古いブラウザを外すという。特記すべきは Windows 用の Internet Explorer 6 が外れることだ。けれども読者の Mike Lemon が見つけ出し私たちに警告を伝えてくれたところによると、Mac OS X 10.3.9 Panther 用 Firefox の最終リリース、バージョン 2.0.0.20 もサポート対象から外れる。また、 Panther で動く Safari の最終バージョン、Safari 1.3.2 もやはり今後の開発のためには古過ぎるという。
YouTube が FAQ ページで説明するところ によると、サポート対象から外れると言ってもそうした古いブラウザでビデオが再生できなくなるというわけではない。そうではなくて、今後加えられる新機能がこれらの非常に古いブラウザで働くようには作られないということだ。YouTube は Firefox 3.0+、Chrome 4.0+、Internet Explorer 7.0+、Opera (バージョンは明記されていない)、Safari 3.0+ をフルにサポートするという。
もしも Panther ユーザーが将来の YouTube の改善機能にアクセスしたいと思えば、私の知る限り選択肢は一つしかない。Opera 10 だ。これは引き続き Intel ベースと PowerPC ベース双方の Mac に互換だ。
いずれ Panther ユーザーたちには行き詰まりとなる日が来るかもしれないが、Mac OS X 10.4 Tiger ユーザーたちは、まだまだ最新版の Firefox (3.6) にも Safari 3.2.3 にも、また他のブラウザにもアクセスできる。（Firefox、Camino、その他のブラウザで使われるコードベースを管理している Mozilla Foundation が 2010 年 2 月 8 日に出した声明によれば、Firefox 3.7 で使われることになるレンダリングエンジンでは Tiger のサポートが外れるとのことだ。）
YouTube は 2009 年の中ごろから、古いブラウザを使うユーザーに対する警告をメッセージとして挟み込んで、クリックしてそのメッセージを閉じなければビデオが観られないようにし始めた。このメッセージは２週間に一回現われるように設定されていた。（クッキーに依存することで繰り返し表示されるのを防いでいたという。）私がこのことを知ったのは今回が初めてで、インターネット上にこれに関する説明はほとんど出ていないようだ。
Google はまた、2010 年 3 月 1 日をもって Google Apps が古いブラウザのサポートをやめるとも発表した。Google はまず Google Docs と Google Sites でサポート対象を減らしたが、今後同じことが他の Google サービスにも広がってゆくことは間違いないだろう。
正直言って、私たちはこれらの古いブラウザに対して Google がとった態度に諸手を挙げて賛成したい。特に Internet Explorer 6 については大賛成だ。TidBITS ウェブサイトがこれまで Internet Explorer 6 でうまくレンダリングされたことは一度もない。その理由は、このブラウザに基本的なウェブ規格のサポートがあまりにも欠け過ぎているからだ。私たちには、この非常に古い、しかも Apple プラットフォーム用でもないブラウザのために、膨大な時間と労力を割く余裕がなかった。今も Mac OS X 10.3 Panther を使っている人たちが機能の欠如を見るようになるのはちょっと残念だが、やはりそうした古いブラウザにはウェブ開発者たちが近代的なウェブサイトを提供するために必要とする機能が備わっていないのだ。
コメントリンク11033 この記事について | Tweet リンク11033
文： Jeff Carlson <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
さっき私は Adam Engst から、私のアドレスブックが「おかしくなって、[email protected] あてのはずのメールが [email protected] あてになってしまっている」という知らせを受け取った。私はそんな間違いをするはずがないと思った。何しろ、その "sponsors" アドレス（これは Adam が私たちのスポンサー各社や広告主になってくれそうな会社との連絡を優先的に扱うために使用しているアドレスだ）は、私の Address Book データベースにさえ載っていないからだ。
実際の犯人は、Apple Mail の Previous Recipients (宛先の履歴) リストだった。最近宛先に使った電子メールアドレスがここに保存されて、あなたが宛先フィールドに誰かの名前またはアドレスをタイプし始めた際、それを自動補完するために使われる。今回のケースでは、Adam が [email protected] を使って出したメッセージを私は最近受け取ったことがあり、それがこのリストに追加されていた。そして、私が彼に送信すべきメッセージを書いていて、宛先フィールドに "Adam" とタイプしたとき、Mail は勝手にその項目を "Adam Engst, [email protected]" と自動補完してしまったのだ。私は高速でタイプしていたので、宛先の次の人の名前に移る前にこの誤りに気付くことができなかった。こうして、戸惑った Adam が返信をよこすことになった。
この問題を回避するためには、Previous Recipients (宛先の履歴) リストからアドレスを削除すればよい。そうするには方法が二つある：
この削除機能は、誰かの情報をタイプミスしてしまった場合に、そのアドレスの誤りが将来自動補完によって繰り返されることのないように、それを削除するために作られたものだ。
けれども、これでは問題がただ一時的に修正されただけだ。今後 Adam がまた sponsors アドレスからのメールの宛先に私を含めれば、またそのアドレスが私の宛先の履歴リストに追加されてしまうことになる。
それに、変なところは他にもあった。私は、Adam の通常のアドレスがこのリストの先頭に来たらいいのにと思う。このアドレスこそ、私が他のどのアドレスよりも頻繁に使うものだからだ。でも、実際はそうなっていなかった。その代わりに、sponsors アドレスの方が先頭に来ていた。その理由は、こちらのアドレスに対応した名前が "Adam Engst" であって、一方私の Address Book データベースにある項目は "Adam C. Engst" だったからだ。どうやら、ミドルネームの無い名前はミドルネームの付いた名前よりもこのリストの名前順では先に並ぶようだ。これを見て、私は今回の問題を（一時的にでなく）永続的に解決する方法を思い付いた。
この sponsors アドレスをリストから削除するのはやめて、その代わりにその項目で Add to Address Book (アドレスブックに追加) を選んだ。（これは、さきほど述べた二つの方法のどちらを使ってもできる。）それから、アドレスブックの中でその項目の名前を "TidBITS Sponsorship Program" に変更した。（今後決して誤ってここに踏み込まないようにするためだ。）これで、Adam の通常のアドレスがリストの最初に来るようになった。"Adam" とタイプして自動補完させ、コンマか、右矢印か、あるいは Tab キーか、どれかを押してそれを固定し、そのまま次へ進んでも、メールが間違った宛先に送られることはないと、これで安心していられるようになった。
コメントリンク11032 この記事について | Tweet リンク11032
文：
Matt Neuburg <[email protected]>
訳： 亀岡孝仁<takkameoka@kif.biglobe.ne.jp>
安全のために、私は入力しなければならない Web フォーム全てで異なる、無作為に生成されたパスワードを使うことにしている。私はこれらのパスワードのどれも知らないので、パスワード保存アプリケーションを使ってパスワードを保護そして保存している。しかしこのやり方は、極めて安全だが (誰かが我が家に忍び込みこのパスワードキーパーが開いている間に私の頭を殴りつけたりしない限りは)、私自身のコンピュータに向かって座っている時しか働かない。それではどの様にしたらどの コンピュータからでも安全にそして確実にこれらのパスワードにアクセスできるのか？
Clipperzに入るのである。
私が最初に Clipperz のことを聞いたのは IT Conversations ポッドキャストであった、そして私のその場での反応は "どうして誰もこのことをもっと早く私に教えてくれなかったのか？" であった。Clipperz は Web アプリケーションである、そうブラウザでそこまでたどり着く；これで、あなたが必要なその時にあなたのオンラインパスワードに対してアクセス出来る、つまりあなたがオンラインにある時なら何時でも。あなたが clipperz.com Web サイトに到着した時、あなたのユーザー名とマスターパスフレーズを入力する；この組み合わせの推測しやすさがこの一連の作業の中で一番の弱点であるので、長いそしてあまり自然でないパスフレーズを使うべきである。しかしながら、このパスフレーズ自身はログインの最中に clipperz.com には送られことは ない。実際の所、clipperz.com はあなたのユーザー名、あなたのマスターパスフレーズ、或いはあなたのパスワードのどれをも知らない！
どうしてそんなことがあり得るのか？実は、clipperz.com は "ゼロ知識ベータベース" と呼ばれるものなのである。何も平文では保存されない、全てが暗号化されており、そして clipperz.com は鍵を持っていない。保存されたデータは全て暗号化されている；Clipperz との通信も暗号化されている (これは SSL を使って送信されるので、二重に暗号化されているとも言える)。全ての暗号化と復号化は あなたの 手元で行われる - ブラウザの中で。これは近代のコンピュータの速度と JavaScript の実装のお陰で可能になった (JavaScript データは Web ページを変える時失われてしまうので、Clipperz は AJAX を使ってあなたを同じページにとめて置きながらスクリーンをリフレッシュする)。更に、最も弱点と思われる部分、すなわち最初のパスワードに基づいた認証作業も、Secure Remote Password (SRP) を使う、それ自体ゼロ知識であり (clipperz.com はあなたのユーザー名とパスフレーズから派生する公開鍵しか知らない)、そしてパスワードに基づいた認証で期待できるだけの安全さを有している。多分、多分あなたがインターネット上で行うパスワードベースの他の如何なる 認証よりもずっと安全であろう。最後に、全ての Clipperz のコードはオープンソースである - と言うのも、多分あなたは良くご存知だと思うが、秘密によるセキュリティは最悪のセキュリティであるからである。
このスクリーンショットはあなたが一旦ログインした後の簡単なインターフェースを示している。それはまがいもない情報の "ローロデックス" となっている。左側にはあなたの "カード" の名前が並んでいる；一つのカードの名前をクリックするとその "フィールド" が現れる。私はこれを人に見られても平気だ。何故ならばパスワードのフィールドは常に六つ星で表されるからである。これをコピーして (スクリーンショットに表示されている Control-C ではなく Command-C を使って) Web フォームのパスワードのフィールドに貼り付けるのである、これは勿論そのページは別のウィンドウで開かれているという想定の上でだが。(もし共有のマシンを使っている場合は、後で他のもの何かをクリップボードにコピーしておくように、これはあなたのパスワードを平文で残さないために必要である。) あなたはそのパスワードを "解読" してそれを平文で表示することも出来る；これは敵のスパイがあなたの背後に座っていない限り安全である。
当然のことながら、オンラインパスワードはこの様なやり方で安全に保存できる唯一の データではない。クレジットカード情報やその他何でもオンラインでいる間に必要となるものを保存できる。カードのフィールドはカスタマイズ出来るので、そのデータに適したやり方で表示するようカードを設定できる。
もう一つの気の利いた機能に "ワンタイムパスワード" を設定できるというのもある。これらは clipperz.com に対するログインパスフレーズで、使われた途端それは消去される。スパイ小説の読者なら誰でも知っている様に、ワンタイムパッドは暗号化で一番安全な方法である。もし公共の場にいる場合でも、あなたのワンタイムパスワードの一つを使える；たとえスパイがあなたの背後にいてキーボード上のあなたの指の動きを覚えられたとしても、それはもう使い物にはならない。
更におまけを一つ。私は暗号化も復号化もブラウザの中で起こると言った；私はまた clipperz.com に保存されるデータもまた暗号化されていると言った。と言うことは、もしあなたがそのデータを clipperz.com から あなたの マシンに保存したとしてもセキュリティで失われるものはない。そして Clipperz はそれをあなたにやらせてくれる。あなたは、その暗号化されたデータと全ての JavaScript を含んだ (極めて大きい) Web ページをダウンロード出来る。あなたのブラウザでそのページを開けば、まさに clipperz.com と話しているのと同じようである - あなたはあなたのユーザー名とパスフレーズでログインしなければならないが - clipperz.com と話している わけではない；あなたはオフラインで作業をしているのである。つまり、このダウンロードした Web ページは、私のパスワード保管アプリケーションが前にやっていたこと全てをやってくれているのである！唯一違うのは編集が出来ないことである；あなたが作業しているのは読み取り専用のデータなのである。どうです、良いと思いませんか？
Clipperz は完全とはいえない。スクランブルされたパスワードをコピーする作業はいつもうまく行くとは言えない - しかし Clipperz の人達は新しい Web インターフェースに取り組んでいて、現時点では "ガンマ" と呼ばれているが、この問題は解決される。幾つかの作業のためのインターフェースは、例えばテキストファイルからインポートして複数のカードに入力する、かなり分かり難い (私は成功したが、それもかなりの実験をした後での話である)。そして、全体的なインターフェースは iPhone 上ではぎこちない；Web インターフェースにはモバイルバージョンもあるが、これは私には使い物にならない。最後に、楽しみな機能で "直接ログイン" と呼ばれるものがあり、その場合リンクをクリックすると自動的に、あなたの側では何もそれ以上のことをすることなしに、目的の Web サイトのログインページに行き、あなたのユーザー名とパスワードを入力、そしてそのフォームを提出する；しかしながら、これは全ての Web サイトで働くわけではない、そしてこの直接ログインを編集するインターフェースはぎこちないと殆ど無いとの中間である (これもまた新しい "ガンマ" インターフェースではうまく解決されている)。
屁理屈は別にして、私は Clipperz は私の毎日の Web 生活で大いに役立っている。それはあなたのオンラインパスワードにオンラインで如何なるコンピュータを使っているかに拘わらずアクセスさせてくれる。そして無料であり、オープンソースであり、安全かつ確実であり、独創的であり、そして何といってもカッコいい。これ以上何を望めると言うのか？まあ、物は一つ、試してみては如何ですか、そうすればどうして誰も今までこのことをもっと早く教えてくれなかったのかと思うようになること請け合いである。
コメントリンク11034 この記事について | Tweet リンク11034
文： Adam C. Engst <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
iPhone OS についてずっと聞こえ続けている不満の声は、Apple がマルチタスクを認めていないことだ。1988 年に System 5 が初めて MultiFinder を加えて以来、マルチタスクは Mac OS に必須の要素だった。Apple の態度はバックグラウンドでアプリを走らせるとパフォーマンスの面でもバッテリ寿命の面でも損なわれるところが多いというものだったが、iPhone OS 3.0 に至り、Apple は push 通知を追加した。マルチタスクを望む人々の願いの一部は（決して全部ではないが）この push 通知で対処されたのだった。
大体においては、iPhone OS 3.0 のリリースと push 通知の実現とによって、マルチタスク機能への要求の声は、ぼんやりしたうなり声へとトーンを下げてしまったようだった。もちろんそれを望む気持ちが消えたわけではなかったが、論争が行き詰まりになったという気持ちが大勢を占めていた。
ところが、iPad の発表で、すべてがひっくり返った。なぜなら、iPad はより高速な CPU (ただしどのくらい速いかはまだ発表されていない) と 10 時間のバッテリ寿命 (これに対して iPhone の場合は 5 から 9 時間と言われる)、それから 1024×768 のスクリーン解像度 (iPhone や iPod touch の解像度 480×320 よりもはるかに広々としている) を持つからだ。バッテリ寿命が長いことで、複数のアプリが走ればバッテリ寿命に悪影響が出るという Apple の懸念は弱まるし、スクリーンが大きくなることでアプリとアプリを横に並べて走らせる可能性が出てくる。
より一般的に言えば、iPhone はごく短い、焦点の絞られた作業を狙ったものであり、それに対して iPad はむしろ長時間の、より一般的な作業で複数のアプリを使うようなものに適していると言える。私たちが Mac で慣れ親しんでいる状況により近いわけだ。iPad を使って Mobile Safari の中で文章を読み、そのテキストの一部をコピーして Pages 書類に持って行き、そうやって作った書類を Mail で同僚に送る、といったことも容易に想像できる。確かにその通りのことを現行の iPhone OS ですることも可能だが、このような実例を考えるだけでも、将来は複数の iPad アプリを同時に動作させる必要がさまざまな形で出てくることが示唆されると言えるだろう。
その上、Apple の長期プランには iPhone OS ベースの機器にさらに大型のものが含まれるだろうという私の提案（2010 年 1 月 28 日の記事“iPhone 開発者ライセンスがさらなる新デバイスを示唆？”参照）がもしも正しい線に乗っているのなら、そこではマルチタスクこそが鍵となるはずだ。一度に一つしかアプリケーションを走らせられないとしたら、大スクリーン Mac の使用がどんな感じかと想像することさえ難しくなる。
でも、iPhone OS がマルチタスクをサポートするべきだと私たちが言うとき、その言葉はいったい何を意味しているのだろうか？ 私たちが自分の望む物をもっと注意深く定義しさえすれば、Apple に対して iPhone OS 4.0 あるいはそれ以降でサポートするよう要請する際にも、いろいろのことがすっきりするだろう。
Push 通知 -- 最もシンプルな形でのマルチタスク処理は、既に Apple から開発者たちが利用できるように提供されているもの、すなわち push 通知だ。本質的には、システムレベルで走る push 通知サービスに対して各アプリケーションが登録をしておき、通知すべき情報が到着すれば iPhone OS がその通知をあたかもそのアプリケーションから来たものであるかのように表示する。
情報の通知は、人々がマルチタスクにより得たいと思う最も重要なものの一つだ。通知しようとしているアプリが現在アクティブに使用されていない時でもプログラムがユーザーにイベントを知らせることができて欲しいわけだ。Mac でなら、iCal について考えてみればよい。あなたが今どんなプログラムを使用中だったとしても、イベントの警告がその上にポップアップするようになって欲しいだろう。そうなるためには、何か別のプロセスがバックグラウンドで目を配り続けていて、必要となれば最前面のアプリケーションを遮って出てきてくれるようになっていなければならない。
マルチタスクを考える上で、push 通知には一つ問題がある。push 通知は常に、何かクラウドベースのサービス、例えば AIM や Twitter といったものから来る外部の変更に対する反応としてしか実行できない。これは、バックグラウンドのアプリが独自に何かの変更を通知する実例にはなっていないのだ。もちろん iPhone OS でもそういうことは可能だ。例えばカレンダーや、タイマーのアラームなどが、特定の時刻にスケジュールされた内部的な通知を出すということも考えられる。けれども Apple は、この種の機能を（私の知る限り）開発者たちには一切開放していない。そうなれば素敵だろうし、またそれを追加するのも難しくはないと思うのだが。
バックグラウンドの状況アップデート -- マルチタスク処理に関して私たちが考えることがもう一つある。それは、バックグラウンドで遠隔の状況をアップデートすることだ。これも、現在 iPhone OS で実行可能だが、Apple のアプリにしか許されていない。Mail、Contacts、Calendar の環境設定スクリーンで Fetch New Data を Push に設定しておけば、新しい電子メールメッセージが到着したり、コンタクトやカレンダーの情報が変わったりするとそれらが自動的に表示される。だから、いちいち Contacts や Calendar で最新の変更がないかどうか調べるために手動で更新する必要がない。ただし Mail では、push 設定のないアカウントについては手動で新規メッセージをチェックする（あるいはタイマーが次のメールチェックをするまで待つ）必要がある。（もちろん、同期を iTunes 経由のみにすることによってカレンダーやコンタクトのアップデートを手動プロセスにすることもできる。）
Apple のアプリならばバックグラウンドにいながらデータを取り寄せることにより状況表示を常に最新に保つことができるが、Apple はその機能を開発者たちに開放していない。例えば Twitter アプリや、RSS ニュースリーダーなどは、バックグラウンドで状況アップデートができるようになれば恩恵を受けるところがあるだろうに。
ただ、私としては Twitter や RSS の類いのものについてのスケジュールされたアップデートと、常時続くバックグラウンド実行（これについては後で議論する）とを区別しておきたい。Twitter クライアントや RSS ニュースリーダーが毎秒チェックするようになって欲しいという人はいないだろう。なぜなら、更新の度に古いメッセージもすべて持ち込まれるかもしれないからだ。一方、インスタントメッセージングのアプリの場合は、メッセージの届くタイミングが悪ければ（そしてサーバがクライアントに対し状況保持を行なわなかったならば）完全にメッセージを見逃してしまうこともあり得る。だから、チャットアプリや GPS トラッキングアプリは常時走り続けたい。なぜなら、その種のアプリはスケジュールによるアップデートでは十分高速かつ情報を完備した状態で動作することができないからだ。
どうやら、スケジュールによってバックグラウンド状況をアップデートする方法ならば、Apple が開発者たちに開放することもあり得るように思われる。Apple 自身のいくつかのアプリが既にしているのと同じ方式だ。それぞれのアプリが iPhone OS に登録し、iPhone OS がデータをどの程度頻繁に取り寄せたかの仲立ちとなるのだ。これならば、それほど難しいこととも思えないし、それほどバッテリ寿命に影響を与えるとも思えない。
アプリケーション間のコミュニケーション -- Mac では、いろいろなアプリケーションが幅広い種類の方法でお互いにやり取りし合うことに、私たちはもう慣れ切っている。例えば、Entourage でダブルクリックした URL が Firefox に送られたり、Twitterrific が Growl に依頼して通知を表示させたり、iTunes コントローラが現在再生中の楽曲を表示したり、さらには Finder が BBEdit に命じて書類を開かせたりということもある。
これらの挙動のいくつかは iPhone でも利用できる。例えば電子メールの中にある URL を Safari で辿ったり、写真の付いた電子メールメッセージを作成したり、Maps の中に住所を表示させたりといった具合だ。けれども大体において、アプリが命じて何かをさせられる相手は Apple のアプリに限られる。そうでない例の主なもので、私の iPhone で動いているのは Boxcar だ。これは tweet 通知への反応としてさまざまの Twitter アプリを開くことができる。ただ、Boxcar の機能は非常に限定されている。Twitter アプリを開くことはできるが、そのアプリを何か便利な方法でコントロールするということができない。例えば、特定のその tweet を表示させることもできない。
その理由は、現在アプリが他のアプリとコミュニケーションできる主な方法が URL を通してのものであって、そのチャンネルの幅広さが、一つのアプリの持つ URL ハンドラ API がどれだけ堅牢であるか、またどれだけ他のアプリの開発者たちがそれと同じものを用いているかに依存するからだ。でも、このアプローチには限界がある。なぜなら、すべての情報が一つの URL の中に完全に含まれている必要があるからだ。また、これは一方向のみの情報伝達で、それを受け取ったアプリが情報を返すということができない。その上、現時点の iPhone OS においてはファイルがすべて個々のアプリのみのものなので、アプリがファイル参照情報を他のアプリに送るということすらもできない。
将来のバージョンの iPhone OS ではこの URL の処理が拡張されて、ファイル参照情報を共有空間にある書類に送ったり、ひょっとしたら送り元のアプリに対して別の URL を送り返したりということができるようになるかもしれない。双方のアプリがアクティブである必要なしにそのようなコミュニケーションが実現されれば、バッテリ寿命やパフォーマンスにそれほど悪影響を与えることはないだろうし、現在のようにユーザーが手でアプリからアプリへと行ったり来たりするより使い勝手が良くなるかもしれない。それでもやはり、Mac OS 内蔵の Apple Event システムでアプリケーションたちが相互にコミュニケーションするやり方に比べれば、まだまだ不格好なものと言わざるを得ない。
けれども、Apple Event は相手のアプリケーションが動作中でなければ働かない。だから、同様のシステムを iPhone OS で考えるのは非常に難しいことになるだろう。ことに、CPU や RAM のリソースが格段に少ないことを考えればなおさらだ。だから、私にはこれが近い将来に実現するとは考えにくい。
もちろん、アプリからアプリへ任意のデータを持ち運ぶ別の方法として、コピーとペーストを使うこともできる。これは、最近になって iPhone OS に追加された。コピーとペーストを使えば多くの問題が解決するが、問題はこれが完全にユーザーの操作に依存するものであることだ。その点が、URL による方法や Mac での Apple Event による方法と大きく違っている。
状況保存を伴う手早いタスク切り替え -- Mac OS に初めてマルチタスクの兆候が垣間見えたのは、Andy Hertzfeld の Switcher (1985 年) の登場によってだった。このアプリケーションは、二つのアプリケーションが同時に走ることをほとんど可能なところまで近づけた。ただ、内部の動作としては、これは単に二つのアプリケーションを切り替える際に片方を終了してもう片方を起動するということをせずに済ませるようにしただけだった。その後 Switcher は System 5 の MultiFinder に取って代わられ、その後 System 7 に至ってオペレーティングシステムの標準的な構成要素となった。
iPhone OS で、私たちは逆の道を辿ることとなった。つまり、まず (Home ボタンを押して) 一つのアプリの使用を中止し、それから (ホームスクリーンでアイコンをタップして) 別のアプリを起動させなければならない。このようになったのには主に二つの理由がある。ユーザー体験の一貫性のためと、同時に二つのアプリを走らせておくのに必要な RAM と CPU の要件を除くためだ。幸いにも、終了・起動は一般的に素早くできる。だからこそ Apple は今までのところこれで済ませることができているのだろう。
それでも、ひっきりなしにホームスクリーンに戻されるのはやはり気に障る。（特に私のように多数のアプリを収納するために何枚ものホームスクリーンを使っている場合はそうなる。）Apple は暗黙のうちにこの苦情を受け入れてくれたようで、ショートカットのアクションを提供している。つまり、Home ボタンを二度押しすれば、最初のホームスクリーンを表示するか、検索スクリーンを表示するか、Phone Favorites スクリーンを表示するか、Camera アプリを開くか、それとも iPod アプリを開くか、いずれかを設定できる。さらに、ドックに四つのアプリを表示できるようにし、すべてのホームスクリーンで常に見えているようにしているという事実を見ても、ユーザーたちがいくつか特定のアプリの間で他より手軽に移動したいと思っていることを Apple が認識しているのだとわかる。
私としては、手早いタスクの切り替えの必要を満たすために、二つの変更を施す必要があると提案したい。第一に、iPhone OS にはユーザーの選んだアプリや最近使ったアプリの間をもっと高速に切り替えられる方法が必要だ。Home ボタンの二度押しあるいは三度押しで、ショートカットスクリーンを表示してはどうか。第二に、iPhone OS も、個々のアプリも、もっとユーザーの現況を保存する努力をする必要がある。起動し直すごとに最初からやり直さなければならないのは困る。これは不可能ではないはずだ。私たちの TidBITS News アプリでは既にそれが実現している。アプリを離れた時にある記事を読んでいたなら、次に起動した際にはちゃんとそこが開くのだ。一つの方法としては、iPhone OS が各アプリの状況を自動的に「フリーズ」させて（開発者たちがそれを希望すればの話だが）余分な仕事をせずに済むようにしてくれてもいいのではないか。
これら二つの提案のいずれも、アプリが同時に動いていることを必要としない。だから、これらは Apple が将来のバージョンの iPhone OS で考慮する種類のことであるはずだ。
同時実行 -- さて、ここから問題の本当の核心に入る。真の意味の同時実行について考えてみよう。でも、ここにも実際のシナリオは二つ考えられる。バックグラウンドで走る必要のある iPod などのアプリが、インターフェイスの中では目に見える場所を必要としない（あるいはほとんど必要としない）場合と、複数のアプリが、iPad の上で同時に並んで動作できるという将来の可能性だ。
明らかに、この第一のシナリオは iPhone OS で実現可能だ。なぜなら、現に iPod アプリがそう挙動しているからだ。だから、Pandora 音楽アプリや GPS トラッカーアプリなど、他のアプリにもそれができるようになることはあり得るはずだ。
ここがまさに、バックグラウンドでアプリを走ることを許せばパフォーマンスとバッテリ寿命に悪影響があるという Apple の主張について考えてみるべきポイントだ。例として、あなたが iPhone でゲームをプレイしていて、それが CPU サイクルのほとんどすべてを独占していたとしよう。そこで何か他のアプリ、例えば iPod のようなものを走らせても、バッテリ寿命には影響しない。なぜなら、既にすべての CPU サイクルが使用中なので、もしもゲームのせいで一時間でバッテリが切れてしまうとすれば、そのゲームに iPod を追加してもバッテリの保つ時間はほとんど短くならないだろう。
けれども、もしもあなたがゲームをしているのではなく、その時使っているアプリが比較的少ししか CPU サイクルを使っていなかったとすれば、その場合は iPod のような他のプロセスを加えることで全体の CPU 使用量が増え、バッテリの減りが速くなるのは間違いない。それはもちろん理想的とは言えないが、それでもこれはユーザーの選択に任せるべき種類のことのように思える。これは、Apple が新しいデータを頻繁に取り寄せればそれだけバッテリの減りが速くなると警告しているのと同じことだろう。
それより深刻なのはパフォーマンスに関する問題だ。例として、あなたが車の助手席に乗っていて、ゲームをしたいと思ったとしよう。と同時に、iPod をバックグラウンドで聴き、GPS アプリを使って現在位置と速度を追跡し、さらには新しいメッセージが Mail に push されるようにしたいと思ったとしよう。すると、iPhone の CPU はこれらすべてのアプリの間で共有されなければならない。そして、もしもその共有があまりうまく行かなければ、ゲームのパフォーマンスが受け入れ難いレベルにまで下がってしまうかもしれない。前面のタスクの反応性を保ちながらバックグラウンドのタスクにどれだけの CPU 時間を与えるかを調整することは、どんなオペレーティングシステムにおいても黒魔術だ。それに、そこでは iPhone の CPU がそもそもそれに耐え得るものであることが前提となっている。それは単純に複数のアプリのロードの下では前面のアプリの反応性を保てるだけのパワーを持たないのかもしれない。そしてそれこそ、私の直感では、Apple にとって鬼門なのだと思う。iPhone OS の直接処理インターフェイスを生かしている魔法は、それがあまりにも反応性が良くて自然に感じられることだ。もしもそこに時間差やひっかかりが紛れ込めば、たちまちそのイリュージョンが消え去ってしまうかもしれない。
こうして、私の見るところ Apple がバックグラウンドのアプリを許容できる唯一の方法は、バックグラウンドでアプリが使用できる CPU サイクル部分を制限できる何らかのやり方を見つけることだ。つまり、アプリは何か他のことが進行中ならば時々しかサイクルを受けられないようにするのだ。これは想像不能なことではないが、どう見ても難しい問題であり、Apple がすぐに解決できるようなことではないと思う。
さらに深刻な問題が、RAM の制限に関係したところにあるかもしれない。Apple は個々の iPhone OS 機器にどれだけの RAM が装備されるかについてほとんど語ろうとしないが、RAM 要件を Apple がコントロールできないようなアプリを複数個同時に走らせられるほど十分でないことは大いにあり得る。バックグラウンドのアプリにどれだけの CPU 時間を分け与えるかを調整するのは難しいかもしれないが、それでも実行は可能だ。物理的 RAM を使わずに、仮想メモリに大きく依存すれば（ことに比較的低速のフラッシュメモリの上では）パフォーマンスが大幅に落ちるかもしれない。
同時実行の第二のシナリオは、より推測に基づくものになるが、答を出すのはこちらの方が易しいかもしれない。iPad のスクリーンは大きいので、クラシックな iPhone を二つ（ひょっとすれば四つでも）同時に表示するのも十分可能だ。iPad 対応のアプリでさえも、解像度に依存しないように作られていれば、あるいはスクリーンの一部で共有して使う場合には iPhone サイズの表示に切り替えられるようになっていれば、二つを横に並べて、同時に両方がアクティブにできると考えるのは自然なことだろう。それに、もしも iPad の A4 プロセッサが十分高速で、RAM も十分にあれば、ひょっとしたらその考えを実現できるだけのリソースがあるかもしれない。
ここで、Mac の世界に話を移してみよう。そこでは、二つのアプリケーションが同時に見えているのはごくごく普通のことだからだ。（デュアルディスプレイの環境で仕事をするのが好きな私たちにしてみれば、そうでないことの方があり得ない。）私はいつも、Mailplane で電子メールのメッセージを書きながら、あるいは BBEdit で記事の文章を執筆しながら、同時にウェブページを参照したりしている。また、もしも誰かから電子メールが届いて Macworld Expo でのミーティングの予定を聞いてきたら、そのメッセージもそれに対する返信も見えるようにしたままで BusyCal の中にカレンダーを開いて見ることができる。これはとても大きなことで、いちいち Command-Tab を使って切り替えをしなければならなかった場合に比べて私の生産性はずっと上がる。だから、iPhone OS 機器の上で同じ仕事をしようと思えば、さらにずっと悪いことになる。まず Mail を終了、それから Calendar を起動、その中でスケジュールを調べて、Calendar を終了、その後で Mail を起動、また最初からさっきのメッセージを探して、それに返信、その時までさっき調べたスケジュールの時刻を覚えていなければならないのだから。
iPad の上で複数のアプリを並べて走らせることは Apple にとって無理難題に見えるだろうが（私には iPhoto の写真比較方法にちょっと似たインターフェイスが想像できる）iPad を Mac の代わりに使いたい人、それを複数のアプリにあるデータが同時に目で見てわかることを要するような仕事に使いたい人にとって、それはこの上なくありがたいことなのだ。
このシナリオが、前のシナリオ（複数のアプリが実行中だけれども前面のもの以外はインターフェイス空間を占めない）よりも優れている点は、複数のアプリを並べて使う場合、片方がアクティブな間は必ずしももう片方のアプリが処理を続ける必要はないことだ。私が電子メールに返信を書いている間、カレンダーは基本的にその場でフリーズした状態でもかまわない。そして、次の月に進むために私がカレンダーをタップした時に、今度は電子メールがフリーズして私がタップして戻るまでそのままそこに残る。このようにすればパフォーマンスの問題は解決するだろう。なぜなら、どんな時でも実際に CPU サイクルを使用しているのはたった一つのアプリだけだからだ。
すべてをまとめると -- 現時点での状況をまとめてみよう。私たちは「iPhone はマルチタスクを持つべきだ」という主張をいくつかの構成要素に分割した。その中には今日 Apple のアプリのみで実現されているものもいくつかあり、純粋に推測に過ぎないものもいくつかある。
いつもと同様、Apple にフィードバックの声を届ける最良の（そして唯一の）方法は、Product Feedback ページだ。まだこのページには iPad の項目がないが、iPhone か iPod touch で、あなたがお持ちのものの方の項目に、あなたの希望を書き込むのがよいと思う。
そしてもちろん、どうぞこの記事のコメント欄にも、あなたのご感想を！
コメントリンク10989 この記事について | Tweet リンク10989
文： TidBITS Staff <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
デジタルカメラ RAW 互換性アップデート 3.1 -- カメラの各メーカーが raw 画像（センサーが記録した通りのデータを圧縮も最適化も加えずに保存するもの）を撮影できるカメラの新機種をリリースする際、それぞれの用いる raw フォーマットは個々に少しずつ（しかも困った具合に）異なっていて、しかも独自仕様のフォーマットになっている。Apple は、システムレベルでそれらのカメラのサポートを組み込んでおり、いつも多数のアップデートを一まとめにした形で出している。最近リリースされたデジタルカメラ RAW 互換性アップデート 3.1 もそうだ。今回のアップデートは以下のカメラのサポートを追加する： Hasselblad H3DII-50、Leica M9、Leica X1、Olympus E-P1、Olympus E-P2、Panasonic Lumix DMC-GF1、Pentax K-7、Pentax K-x、Sony Alpha DSLR-A500、Sony Alpha DSLR-A550、Sony Alpha DSLR-A850。(アップデート無料、6.77 MB)
Digital Camera Raw Compatibility Update 3.1 へのコメントリンク:
PDFpen 4.6 と PDFpenPro 4.6 -- SmileOnMyMac の PDF 編集ユーティリティ PDFpen と PDFpenPro の最新バージョンにはごく簡潔なリリースノートしか付いていないが、少なくとも一つ重要な改善が含まれている。いずれも、OCR のサポート対象に新たに 11 の言語が加わった。ドイツ語、フランス語、スペイン語、イタリア語、ポルトガル語、カタロニア語、オランダ語、スウェーデン語、フィンランド語、デンマーク語、それにノルウェー語だ。また今回のアップデートでは多数のマイナーなバグ修正や改善が施されているとのことだが、具体的な説明はない。(新規購入 $49.95/$99.95、アップデート無料、45.9 MB/46.1 MB)
PDFpen 4.6 and PDFpenPro 4.6 へのコメントリンク:
Keyboard Maestro 4.1 -- Stairways Software が、人気のマクロユーティリティ Keyboard Maestro に大きなアップデートをリリースした。バージョン 4.1 では改善されたマニュアル、アプリ内チュートリアル、それにマクログループの有効化とターゲット化に関する Help セクションなどを、すべてプログラム内部からサポートする機能が拡張された。また、プログラムのメニューも改善され、いくつかのコマンドを追加するとともに、新設の Select Menu エディターでユーザーが現在あるどのメニュー項目も選べるようになった。それから、名前による、またはトリガーによる、マクロを対象とした検索ができるようになり、Typed String トリガーの挙動が微調整され、Google 検索をキャンセルするとプログラムのウィンドウに戻るようになった。(新規購入 $36、アップデート無料、8.8 MB)
Keyboard Maestro 4.1 へのコメントリンク:
Camino 2.0.2 -- The Camino Project が、Mac 専用、Gecko ベースのウェブブラウザ Camino のマイナーなアップデートをリリースし、プログラム内部で Mozilla の Gecko レンダリングエンジンをバージョン 1.9.0.18 にアップデートすることによっていくつかのセキュリティおよび安定性の問題に対処した。また、Command-矢印キーで好きなメニュー項目を選べるようにユーザーが再割り当てをすることができるようになり、Flash をブロックするコードが Flashblock 1.5.12 にアップグレードされ、Google の Safe Browsing 情報ページがノルウェー語で読めるようになり、広告ブロック機能が改善され、ガンマ設定が 1.8 以外になっているディスプレイでも Bookmark Bar のカラーが正確に表示されるようになった。(無料、15.8 MB)
文： TidBITS Staff <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
今週私たちがウェブ探訪をして見つけた記事はさまざまの話題のものだった。Apple が iMac のディスプレイに問題があることを認め、Macworld Expo と Google Buzz についてさらなる議論があり、Apple が iTunes の 100 億曲目カウントダウンで当選者を発表し、iPad が初出荷時の売れ行きで iPhone より人気を博すると示唆した調査結果があり、Apple が外部納入業者との関係について発表をし、Mac で最も初期のソフトウェア開発者の一人が過去を振り返り、Wal-Mart が Vudu ビデオサービスを買収した。
Apple、iMac ディスプレイの問題を Gizmodo に認める -- Gizmodo に対する声明の中で、Apple は最新の iMac 機種に起こっている厄介なディスプレイの問題点の存在を公式に認めた。主に 27 インチモデルに発生しているこれらの問題では黄色の変色やスクリーンのちらつきなどの症状がある。この声明の中で Apple は「ディスプレイがちらついたり黄色っぽくなったりするこれらの問題の原因に対処することができたので、iMac に問題が起こっている顧客の方々には AppleCare にご連絡頂きたい」と述べた。問題への対処に同社はあまりにも時間をかけ過ぎたが、遅くても何もしないよりはましだ。
Adam、Tech Night Owl で Macworld Expo と Google Buzz 問題を語る -- Tech Night Owl Live ポッドキャストで、Adam がホストの Gene Steinberg とともに Macworld Expo の成功について語り合う。その後、話題は Google Buzz で Google が誤りを犯したプライバシーの問題へと移る。
iTunes Storeの楽曲販売件数、100億曲を突破 -- Apple が iTunes 100 億曲目カウントダウンの当選者を発表した。幸運な iTunes ショッパーはジョージア州 Woodstock 在住の Louie Sulcer で、Johnny Cash の "Guess Things Happen That Way" を購入した彼には $10,000 の iTunes ギフトカードが贈呈された。iTunes で現在売れ行き上位に並ぶのが最近のポップやヒップホップのシングルばかりであるにもかかわらずこのような懐かしのオールディーズ楽曲が当選したことは驚きかもしれないが、これこそまさに iTunes Store が幅広いファン層やさまざまの嗜好に応えていることを示すものではなかろうか。
iPad 初出荷時売れ行きは初代の iPhone をしのぐ？ -- iPad については懐疑的意見も私たちの耳に届いていたが、All Things Digital の記事によれば RBC/ChangeWave によるアンケート調査で 13 パーセントの人たちが iPad をたぶん買うだろうと答えたという。これに対して初代 iPhone 発売の前に行なわれた同種のアンケート調査では買うと答えた人が 9 パーセントだった。この違いには、iPad の入門機で $499 という価格が影響していると考えられる。
Apple、「サプライヤーの責任」レポートを発表 -- Apple は毎年何千万台という機器を販売しており、同社に製品を納入する外部のサプライヤーや、そうした会社で働く人たちの労働条件などがますます注目の焦点となるようになってきた。そこで Apple は 2010 Supplier Responsibility Progress Report (サプライヤー責任 2010 年進捗報告書) を発表し、Apple がこれらのサプライヤーに要求する内容、これらの会社の監査結果、コンプライアンスの欠如に対しどのように Apple が対処するか、といったことの概要を説明した。当然ながらこれは Apple に良い印象を与えることになるが、他方でこれは Apple がいかにして善き企業責務を果たそうとしているかの指標ともなる。
Macintosh の過去と未来を Jim Rea と共に -- Jim Rea の書いた ProVUE Panorama は、Macintosh が 1984 年に初登場した時点で最初に市場に出る用意のできていたアプリケーションの一つだった。そして、今もなお順調に活躍している。Jim が Macworld Expo の会場でそうした初期の時代を回想する様を、そして来たるべき Panorama 6 について少しだけほのめかしてくれるのを、TUAW の紹介する２つの短い YouTube ビデオを通してあなたの目と耳で確かめよう。食べ物はないけれど、まるで Jim と一緒に昼食を楽しんでいるような気分にさせられる。
Wal-Mart が Vudu を買収 -- New York Times の記事が、Wal-Mart による Vudu の買収を報じた。同社のオンライン映画サービス Vudu は多くの HDTV (高精細度テレビ）や Blu-ray プレイヤーに組み込まれている。今回の合意の詳細はまだ発表されていないが、明らかなのは Wal-Mart が DVD 売り上げの先細りを睨みつつメディア流通の将来を囲い込もうとしていることだ。
TidBITS は、タイムリーなニュース、洞察溢れる解説、奥の深いレビューを Macintosh とインターネット共同体にお届けする無料の週刊ニュースレターです。ご友人には自由にご転送ください。できれば購読をお薦めください。
非営利、非商用の出版物、Web サイトは、フルクレジットを明記すれば記事を転載または記事へのリンクができます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありません。告示：書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017
©Copyright 2010 TidBITS: 再使用は Creative Commons ライセンスによります。
, 
日本語版最終更新：2011年 1月 8日 土曜日, S. HOSOKAWA