TidBITS: Apple News for the Rest of Us  TidBITS#1147/22-Oct-2012

今週火曜日に予定されている Apple の発表に備えつつ(出てくるのははたして iPad mini か? 超コンパクトな iCar か? それとも床磨きワックスか?)この号ではたくさんの素晴らしい記事をお届けしたい。Adam Engst は来たるべき MacTech Conference 2012 (ディズニーアニメーションスタジオの舞台裏訪問ツアーもある) について伝え、Tonya Engst は Mountain Lion における AirPlay の新機能を掘り下げて解説し、Jeff Carlson は iOS 6 における写真関係の新機能のすべてを概観する。それから Michael Cohen はマニア精神を存分に発揮して、Mac OS X と iOS における Apple Mail が完全に異なった方法で新着電子メールメッセージをあなたに通知すると説明する。さて、明日の火曜日 (2012 年 10 月 23 日) は、ぜひ TidBITS ウェブサイトをチェックして、Apple の発表についての私たちの記事をお読み頂きたい!

記事:

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

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


Apple、2012 年 10 月 23 日のイベントで小型の iPad を発表か?

  文: Jeff Carlson: jeffc@tidbits.com, @jeffcarlson
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

今年の残りももうあとほんの少しとなり、早くもホリデーシーズンが間近に迫ってきた。それはただ、あちこちの店で飾り付けが早め早めに始まっているというだけのことではない。Apple をはじめとする会社も、人々にプレゼントとして大量に買ってもらえるように、それに向いた製品をリリースする必要があるのだ。カレンダーに最後の追い込みをかけた製品が iPhone であった去年とは違い、今年の Apple は既に済んだ iPhone 5 リリースを追いかけるフォローアップとして 2012 年 10 月 23 日にメディアイベントを開くことになっており、そこではおそらく小型になった "iPad mini" が発表されるだろうと期待されている。

image

私たち TidBITS では噂に焦点を絞ることはしない。けれどもここ数週間、新型の iPad 機種に関するひそひそ話はもはや無視できないほどに広がっている。私の予想では、7 インチか 8 インチの iPad で、Amazon の Kindle 各機種や大多数の Android タブレットなどといったデバイスと競合できるようなものが出てくるのではないかと思う。その強みは、軽量のデザインと、Apple によるアプリとメディアのエコシステムだ。他の噂としては、Mac mini の改訂や、ひょっとしたら Retina ディスプレイを搭載した 13 インチ MacBook Pro が出るのではないかという声もある。

火曜日になれば、確かなことが分かるだろう。私は飛行機で旅行してイベントに行き、実際に見てみた印象を報告したいと思っている。他の TidBITS スタッフたちも、さまざまのライブブログをフォローしたり、ニュースが判明し次第記事を書いたりすることになっている。

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


MacTech Conference 2012 が心の扉を開く

  文: Adam C. Engst: ace@tidbits.com, @adamengst
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

もしもあなたが来年のMacTech Conference 2013(2013 年 11 月 6 日から 2013 年 11 月 8 日まで) に参加する許可をもらおうとしているところなら、この記事をあなたの上司に見せてはいけない。端的に言ってしまえば、来年も今年のようなカンファレンスになるのなら、経理課の連中があなたが提出したロサンゼルスへの旅行申請書を偏見の目で見てしまうかもしれない。いや、誤解しないで頂きたいが、もしもあなたが IT 部局にいるか、あるいはあなたが Mac か iOS のソフトウェア開発者なら、このカンファレンスに参加する毎日は、上質の専門的講演や、このコミュニティーの数多くのエキスパートの面々で満ち満ちた素晴らしいものとなるだろう。

今回の MacTech Conference 2012 (2012 年 10 月 17 日から 2012 年 10 月 19 日まで) が、私が参加したことのある他のどのカンファレンスとも違っていたのは、毎夜のエンターテインメントだった。一番注目すべきは、夕食会の後に行なわれた Disney Animation Studios 訪問で、Disney のアニメーション映画がどのように制作されるかについての舞台裏の話が聞けたり、公開予定の映画 "Wreck-It Ralph" のリリース前上映を楽しめたりした。これは出来合いのツアーではなくて、アニメーション制作で働いたり、絵コンテを描いたり、サーバ管理をしたり(会話から漏れ聞いた話では 1000 コアと 5 ペタバイトのディスクストレージがいつも回り続けているのだという!)といった実際の作業をしている人たちが Disney 従業員としてカンファレンス参加者たちのために一夜を割いておしゃべりをしてくれたのだった。写真撮影は禁止されていたし、上映の前には一時的に携帯電話を没収されることになっていたので、私は大人のマナーとして自分の iPhone をホテルに置いたままで出かけた。そう、その夜はずっと、ポケットの中に iPhone の重みを感じられなくてもパニックになる必要はないのだと私はひっきりなしに自分に言い聞かせていたのだった。そうそうそれから、1980 年代のビデオゲームが懐かしく思い出せる人ならば、ぜひとも "Wreck-It Ralph" を観に行くべきだ。たとえ Disney Animation 社の IT ディレクターから紹介の説明を受けられなくとも、間違いなく楽しめるだろう。私の友人 Andy Ihnatko が、その博識なポップカルチャーの記憶を駆使しつつ、その一夜の体験を見事に描き出した記事.を書いている。

二日目の夕食会の後には、よりくだけた催しがあった。カンファレンス参加者たちが皆打ち揃って、散策しつつ丘を登り、Universal City の Jillian's で一夜を楽しんだのだった。この店での私はそれほど社交的ではなく、もっぱら Andy と二人でビリヤードをしたり古いビデオゲーム(素晴らしく抽象化された Space Invaders や、オリジナルのキャビネットでプレイできる Asteroids と Donkey Kong など)を楽しんだりしていた。もっと大きなショウ、例えば Macworld Expo のようなところでは、Andy と一緒に時間を過ごす機会などほとんどないからだ。

でも、講演者たちや参加者たち全員で一緒くたに集まる機会しかなかったなどということはない。今回の MacTech Conference には食事が提供される機会が八回もあって、私は八回ともそれぞれ異なった人たちのグループと一緒の席について、IT における人間関係のスキルの話題から、幼稚園や小学校の教育で iPad に取り組むことの重要さ、世界的な自転車競技やトライアスロンの選手たちの薬物使用の話題まで(Mac ユーザーたちから多趣味さを取れば何も残らない!)さまざまの話を議論し合った。それと同じくらい興味深くて価値あるものとなったのが、セッションの合間に廊下のあちこちで交わした会話だ。

要するに、今はなくなり惜しまれている MacHack や C4 カンファレンス(この両者は開発者たちのみに向けられたものであった)で実現されていたのと同じように、Neil Ticktin 率いる MacTech クルーは驚くべき努力を注ぎ込んで、出席者たちの間にコミュニティーの感覚が醸し出される、そんなイベントを組織することに成功したのだった。

セッション自体については、私はあまり評価する資格がない。私は開発者でもないし、IT 担当者でもないからだ。Ben Levy、Phil Goodman、Steve Leebove という面々が Apple の iPhone Configuration Utility、Apple Configurator、Profile Manager を OS X Server で使う方法を詳しく議論している最中に私が少々うとうとしていたことは白状しよう。でも私は Ben Waldie と Armin Briegel が中心となった IT Labs の議論は心ゆくまで楽しんだ。(彼らは親切にも、私が困っていた問題を解決するために Calendar 用のシンプルな AppleScript スクリプトを手早くこしらえてくれさえした。)また、Andy Ihnatko は開発者たちに向けて、エッジケースを無視することのないようにと強く勧める講演を鮮やかに語り、もしもある iOS アプリの開発者が対象ユーザーとなる人たちのたとえ 1 パーセントでもそれをエッジケースだとして無視したとすればそれは顧客となる可能性のある何百万人もの人々を失うことになるかもしれないと指摘した。真の意味でマニア向けの講演としては、NASA の Jet Propulsion Laboratory (ジェット推進研究所) の Sandy Krasner が、火星上の Curiosity との間で JPL がどのようにコミュニケーションしているのかについてあらゆる種類の技術的な詳細情報を明かしてくれた。私たちの大多数にとってその情報が実際に役に立つことはないかもしれないが、今日の世界の「ロケット科学」[訳者注: 最先端科学のこと]が実際にどんなことを含んでいるのかが垣間見えるという点でとても啓発的であった。そして最後に、私自身が主催したパネルディスカッション "Working with the Press" には Andy と、TUAW の Victor Agreda ならびに Kelly Guimont、9to5Mac の Seth Weintraub という面々が参加して、自らの作ったアプリを報道してもらいたいと思っている開発者たちのために素晴らしいアドバイスを持ち寄った。いつもと同じく、もう少し長い時間話を続けられたらと私は思った。

私は今、帰途の空港の中でこの文章を書いている。私は、ぐったり疲れたと同時に、浮き浮きした気分でいる。なぜなら、カンファレンスの最中のさまざまな会話(それに加えて、カンファレンスの前と後に屈強なる TidBITS 保護者 Michael Cohen と Matt Neuburg を訪問したこと)のお陰で、私の心はどんな TidBITS 記事を書こうか、どんな Take Control 電子ブックを作ろうか、その他私たちがこれから取り組めるかもしれないさまざまのアイデアの中を飛び回り続けているからだ。そう、これこそが、MacTech のようなカンファレンスの本当の価値だと思う。毎日の日課を離れて数日間、賢く興味深い人々と共に何かに没頭すれば、あらゆる種類の心の扉が大きく開かれる。それは、あなたが普段どんなことをして日々を過ごしているかとは関係なしに。

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


Mountain Lion の AirPlay を使う

  文: Tonya Engst: tonya@tidbits.com, @tonyaengst
  訳: 亀岡孝仁<takkameoka@kif.biglobe.ne.jp>

2004 年に Apple が AirTunes を Mac に追加した時、この機能を使って "曲" を iTunes から "空間" を通してあなたのネットワーク上にあるどの AirTunes 対応の機器に送るのも朝飯前になった。とりわけケーブルを使ってステレオシステムに接続した AirPort Express に送るのは最も注目を浴びた。時が変わって、この機能の名前も変わり、2010 年には AirPlay となった。OS X 10.8 Mountain Lion のリリース前の機能に満ち溢れたモードでは、AirPlay はオーディオだけでなく、全スクリーンをより最新の iOS 機器 (iPad 2 とそれ以降、そして iPhone 4S、今やそれに加えて iPhone 5) から、第二そして第三世代の Apple TV 経由で AirPlay Mirroring と呼ばれる機能を使って出力できた。

(機器間でオーディオをワイヤレスにもっと自由度を持って飛ばしたいという人のためには、Rogue Amoeba の Airfoilが、如何なる AirPlay 対応の機器へ、或いは Mac OS X, iOS, Windows, 或いは Android 用の相棒の Airfoil Speakers アプリが走る如何なる機器へもオーディオを送ることが出来る。基本的な詳細については、もう古くはなっているが "Airfoil ホームオーディオをワイヤレスに鳴らす" 10 March 2008 参照)

OS X 10.8 Mountain Lion のリリースと共に、Apple は AirPlay Mirroring を Mac にももたらし、これによりオーディオやビデオを iTunes 以外のソースからも AirPlay 経由で出力することが可能となった。具体的に言うと、今や AirPlay をシステムオーディオのためのあなたのデフォルトの音声出力先とし、そしてフルスクリーンを Apple TV に送ることが可能である。オーディオ出力はどの適合する AirPlay 対応の機器に対しても仕向けることが出来、Apple 自身の AirPort Express や Apple TV に加えてサードパーティのスピーカーシステムも使える。詳細については、この先を読み続けられたし、そして Apple の AirPlay を使うことに関するサポート記事を読むのも忘れない様に。

オーディオをストリームする -- あなたの Mountain Lion Mac からオーディオをストリームするためには、System Preferences の Sound ペインにあるOutput ビューで望みの AirPlay 機器を選択するだけである。あなたの設定をテストするには、Finder で好みの音声ファイルを選択、そして Spacebar を押すと Quick Look 経由で再生が開始される。

image

Sound 選択ペインにいる間に、"Show volume in menu bar" チェックボックスを、もしまだだったら、選択しておいた方が良いかもしれない。何故ならば - 一旦 Sound アイコンが現れれば - それをメニューバーで Option クリックすることで、出力機器 (AirPlay 機器であるかないかに拘わらず) を選択出来る様になるからである。しかしながら、もし一台よりも多く AirPlay 機器を持っている場合、あなたの Sound メニューには最も直近に選ばれた AirPlay 機器しか表示されないことに注意する必要がある。

image

Mac のスクリーンをミラーする -- この機能のお蔭で我が家では、我々の Apple TV/TV コンボを使っての楽しみと効用が加わった。我々はこれをグループ HTML 編集会議、ストレッチ体操のオンラインビデオを見ながらの体操、そして訪ねてきた家族と写真を iPhoto から直接共有することなどに使っている。

(もっと細かいことを言うと、Mac の中には Mountain Lion は走らせられるが AirPlay Mirroring は使えないというものもある。これをやるには、iMac [Mid 2011 かそれ以降], Mac mini [Mid 2011 かそれ以降], MacBook Air [Mid 2011 かそれ以降], 或いは MacBook Pro [Early 2011 かそれ以降] が必要である。)

AirPlay Mirroring を有効にするには、メニューバー上の AirPlay アイコンをクリックしそして Apple TV を選択する。もし AirPlay アイコンが見えなければ、Displays 設定ペインを開いて "Show mirroring options in the menu bar when available" を選択する。一旦ミラーリングを始めれば、Displays 設定ペインの Display ビューには更に多くのミラーリングオプションが見えてくる。それぞれを試してみることで、あなたのミラーリング体験が良くなるかどうかが分かる。

image

昔あった Display メニューバーメニューが無くて不自由? -- Mountain Lion の AirPlay メニューバーメニューは Mac OS X の古いバージョンにあった Displays メニューバーに取って代わった。この変更を気に入らないという人達もいる。何故ならば、この人たちはある種のディスプレイ特性、例えば解像度の様な、をこの便利なメニューから簡単に切り替えられるのを好んだからである。そうでないと、Displays 設定ペインから始めなければならない。幸いにして、Thorsten Karrer からの無料ユーティリティ Display Menu が手助けをしてくれる。私はこれを実際の形で使ったことは無いが、私の二台モニター Mac の設定では基本的に働く。

image

AirPlay の将来 -- AirPlay に注意を払おう - 私は、これはちょっと見で見えるものよりももっと重要なものなのではないかと思う。要は、AirPlay は我々にオーディオとビデオを一つの機器から他へと出力先を変更させてくれる。これは面白い可能性をもたらしてくれるかもしれない、とりわけ、入力方法が追加された時には。ひょっとすると、将来バージョンの AirPlay ではあなたに iPhone のスクリーンと他の対話型ディスプレイを使って自由に動き回れる様にしてくれるかもしれない、この Corning の "A Day Made of Glass" コンセプトビデオ (このリンクで 1:45 過ぎの辺り) に示されている様に。

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


電子メールを Push 通知する Apple Mail は IDLE どころじゃない

  文: Michael E. Cohen: mcohen@tidbits.com
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

私たちのコンピュータの内部ではあまりにもたくさんのことが起こっているので、時としてテクノロジーが魔法のように見えることもある。例えば、新たに電子メールメッセージが到着すれば、通知センターが私の Mac と iPad の両方でそれを知らせてくれる。こういったテクノロジーの魔法はあたりまえのように毎日起こっているので、Joe Kissell が "Take Control of Apple Mail in Mountain Lion" に書き綴った素晴らしく役に立つ文章の編集を担当するよりも以前の私はその魔法の内実についてあまり深く考えたことがなかったが、この本の原稿の欄外に書き込むコメントを使って Joe と私が交わした議論は私にとって非常に啓発的なものとなった。

議論にのぼった点の一つが、OS X 10.8 Mountain Lion の通知センターと、メールに関する通知がどういう仕組みで働くのかという疑問だった。チェック中の原稿で私は彼が Mountain Lion の通知センターが iOS デバイスが使用するものと同じ push サービスに接続するのだと解説しているところを読み、それから返ってきた原稿に付けられたコメントの中で Joe が、Mac 上の Apple Mail が従来のバージョンの Mac OS X では push サービスを利用していなかったし、さらに重要なのは Mountain Lion でも push サービスを利用していないことだと書いているのを見て私は驚いた。それは二重の驚きだった。ちょうど私が彼のコメントを読んでいた最中に、私の Mac (10.7 Lion が走っている) だけでなく、近くに置いてあった iPad からも、同時に新着メールを知らせるサウンドが鳴ったからだ。私の iPad が push サービスを利用していることを私は 知って いた。でもそれならば、私の Mac 上の Apple Mail は何を使って新着メールサウンドを同時に鳴らすことができたのだろうか? もちろん Mac の方では push 電子メール通知ではなかったのかもしれないが、それでも確かに iPad 上の push 電子メール通知と同じ挙動をしているように聞こえた!

少々調べてみて、その疑問に対する答が判明した。Mac OS X の Apple Mail は、IMAP (Internet Message Access Protocol) 仕様の一つのオプション項目である IDLE コマンドを利用しているのだ。この答に私を素早く導いてくれたきっかけは、Mail の Account 環境設定の Advanced パネルにある "Use IDLE command if the server supports it" というオプションだった。私の iCloud 電子メールアカウントについては、このオプションがデフォルトでチェックされていた。

IMAP について背景を少々 -- IMAP は POP (Post Office Protocol) をもう一歩進めたものだ。POP はインターネットの深く暗い昔からずっと電子メールを働かせ続けてきたものであり、それと知って唖然とする人たちも多いけれど、今日でさえも多くの電子メールサービスで使われ続けているものだ。

POP では、やって来るメッセージはメールサーバに届き、その後クライアント(つまりあなたの電子メールプログラム)がサーバから取り込んで、オプションとしてそれをサーバから削除するまではずっとサーバに保管され続ける。このメールサーバは単にそこにあるメッセージを記録するのみで、あなたがそれらのメッセージを実際に読んだかどうか、ダウンロードしたかどうかについては記録をしない。それらをするのは、メールクライアントの仕事だ。その結果として、あなたは自分のメールクライアントを使って POP サーバからメッセージを取り込むことができるけれど、もしもクライアントがメッセージをサーバから削除しなければ、あなたは他のメールクライアント(他のコンピュータの上にあるもの、あるいは別のプログラム)を使っていつでもそれらのメッセージを再び取り込むことができ、そのクライアントの上でそれらのメッセージは完全に新しい未読のメッセージとして取り扱われる。

一方 IMAP では、メールクライアントはサーバに存在するままの状態のメッセージを表示する。クライアントは、そのローカルのデバイス上にそのメッセージをダウンロードしてもしなくてもよい。その点は重要なことではない。重要なのは、クライアントがメッセージを読んだ際に IMAP サーバがそのことを認識するということだ。つまり、あなたが一つのメールクライアントを使って IMAP のメールを読んでから、その後(どんなデバイスやコンピュータの上のものであっても)別のクライアントを使ってあなたのアカウントに接続すれば、あなたが既に読んだメッセージはいつでもそれと分かるのであって、そのことはあなたがどのクライアントを使って読んでいるかに関係がないということだ。あなたが複数のデバイスを使っているのなら、どのメッセージを読んだか、どのメッセージを削除したかがすべてのデバイスで同期されることこそが IMAP の利点だ。例えば、あるメッセージを iPhone で読めば、あとで Mac 上で見てもそのメッセージは既読とマークされている。ここでの議論は意図的に IMAP の表面的なことのみを扱っているに過ぎないが、その先を一言で言えば、より単純な POP プロトコルで許されるものよりはるかに複雑な内容の「会話」を IMAP のメールクライアントとサーバはお互いにやり取りすることができる。

IDLE に戻る -- さて、今述べたことは、電子メール到着の通知の話に何の関係があるのだろうか? 結局のところ、プロトコルが POP であろうと IMAP であろうと、メールクライアントは依然としてメールサーバに接続してメールに関する問い合わせを送信しなければならないのではないか? けれどもそこには一つだけ重要な違いがある。IMAP サーバが IDLE コマンドをサポートしている場合だ。

メールサーバが IDLE コマンドに応答できることをそのメールサーバがメールクライアントに知らせる際 (Apple の iCloud サーバは応答できるが、できないサーバもたくさんある)、クライアントはサーバに対して IDLE コマンドを送ることができ、それに対して次のような結果が返される: サーバはそのクライアントとの間に開いた接続を継続し、それによって、新着メールが届いた際には、サーバが即座にそのことをクライアントに知らせることができる。するとクライアントはユーザーに対して新着メールがあると知らせることができるようになる。(当然ながら、クライアントとサーバが IDLE コマンドを使用する方法についてのここでの説明はほとんど犯罪的なほど過剰に簡略化されている。マニアのみに向いた詳しい説明は RFC 2177 に述べられている。)

そういうわけで、私の Mac が新着メールを知らせてくれたのは、Apple Mail と iCloud サーバとがほとんど常時お互いに連絡を取り合っていたからであった。iCloud サーバが「メールがあるよ」と言えば、Apple Mail が「おお、そいつは嬉しい、じゃあ見せてくれよ」と答える、というわけだ。それに加えて、Mountain Lion においては、Mail が通知センターにその知らせを託すこともできるわけだ。

Push はどうか? -- IMAP の IDLE の歴史は比較的古い。最初に仕様が定められたのは前世紀の末ごろ、iPhone が日の目を見るより十年も前のことであった。IMAP の IDLE では、メールクライアントが走り続けていて、メールサーバとの間に開いたネットワーク接続を保ち続けられることが前提となっている。それは、電源と Ethernet ネットワークに常時接続されている機器については何も問題がないことだけれども、ほんのちっぽけなバッテリの電源で走り、ともすれば非常に高くつくかもしれないセルラーデータネットワークに依存するポケットサイズのデバイスにとってはあまり良い前提とは言えない。そこで登場するのが push だ。

iOS では、同時に走るたくさんのアプリを支えられるほどたっぷりのメモリはないし、いくつものアプリを同時にアクティブにしておけるほどバッテリパワーに余裕はない。けれども、ごく小さなプログラムを半ば目覚めたままにしておき、それらをバックグラウンドで走らせ続けてモバイルネットワークに耳を傾けさせておく程度ならばメモリにもバッテリにも余裕がある。それこそまさに、Apple の push システムが働くやり方だ。

この push を使うことによって、iOS アプリは iOS における小さなバックグラウンドプログラムに対して、そのアプリがネットワークの通知メッセージを待っているということを登録しておき、たとえそのアプリが走っていなくても、そのアプリにあてたメッセージが届けば知らせてもらえるようにしておく。するとその小さなバックグラウンドプログラムは iOS の中でネットワークに耳を澄ませ、流れ込んでくるコミュニケーションを処理し、リクエストに応じてアプリに対して適切な通知を送る。

他方、その反対側にある遠隔のアプリケーション、例えばメールサーバなどは、Apple Push Notification (APN) サーバに登録しておくことができ、そのサーバにトークンを渡してインターネット上のどのデバイスが通知メッセージを受け取ることになっているかを知らせておく。その遠隔アプリケーションからの通知メッセージを iOS デバイスに送るのは、Apple の APN サーバなのだ。

つまり道筋は次のようになる: メールサーバがあなたにあてた新規メールを受け取る。するとメールサーバは通知メッセージとデバイストークンを APN サーバに送信する。すると APN サーバはあなたの iOS デバイス上で走る小さなバックグラウンドプログラムに適切なデータを送信し、その結果としてあなたは新着メールサウンドを聞き、Mail アプリのアイコン上のバッジの数字が変わったのを見、到着したメールの中身の簡潔な要約を読むことができるようになる。(この push システムが送信できる通知の最大量は 256 文字までと決められている。)そこであなたが iOS デバイスで Mail アプリを開くと、ここで初めて Mail アプリが遠隔メールサーバとの間に IMAP 接続をフルに確立して、あなたがメッセージの全文を読むことができるようになる。

(Apple のデバイスが使用することのできる push テクノロジーにはもう一つある。Microsoft の ActiveSync だ。そちら がどんな風に働くかの詳細に興味のある読者は、Microsoft の記事 "Understanding Direct Push" を参照されたい。)

微妙な違い -- これらの二つのシステム、IDLE と push は、それぞれ私の iCloud アカウントに新着メールが届いた際に私の Mac と私の iPad で同時に表示された二つの通知を呼び出してくれた。けれどもこれら二つのシステムの間には、それぞれの挙動に微妙な違いがある。

Mac 上では、新着メールの通知を受けられるのは Apple Mail アプリケーションが動作中のみだ。なぜなら、Mail とメールサーバとの間の会話の結果として通知がなされるからだ。Mail が動作中でなければ、あるいは Mac がスリープ中ならば (かつその際 Mountain Lion の Power Nap 機能が有効になっていないならば)、あなたの Mac が新着メールの到着を知ることはできないので、あなたが通知を受け取ることもない。

それに対して iOS デバイス上では、デバイスの電源が入っていてネットワーク接続が有効になっている限り、いつでも通知を受けることができる。たとえデバイスがスリープ中でも、あの小さなバックグラウンドプログラムは十分に目覚めていて、到着した push 通知を受けることができるからだ。(ちなみに、それだからこそ iOS デバイスで push を無効にしておけばバッテリ寿命を多少伸ばすことができる。あの小さなバックグラウンドプログラムがほとんど電源を食わなくなるからだが、それでも少しは食うことに変わりはない。)

しかしながら、Apple の push システムが提供するのは APN サービスから iOS デバイスに向けて送られる通知のみだ。反対向きのメッセージ送信には対応していない。だから、iOS デバイス上に新着メールを知らせる通知が出て、あなたがそのメールを 別の デバイスで(例えばあなたの Mac で)読んでも、その iOS デバイスがあなたがそれを読んだことを知る方法はなく(従ってそのデバイス上の Mail アプリアイコンのバッジの数字は変化せず)それはあなたがそのデバイスで Mail アプリを開いてその iOS デバイスと遠隔メールサーバとの間に IMAP 接続が確立されるまで変わらない。

それはちょっと変だと思われるなら、あなたの感覚は正しい。Joe Kissell が記事“警告の警戒すべき過剰さ”(2012 年 5 月 13 日) の中でアラートについて指摘した通り、また Messages では現実に大きな問題となってきている通り、現状では複数のデバイスに同時に重複した通知イベントが起こってしまっていることについて Apple は何とかする必要に迫られている。理想的な世界においては、これらの通知システムはどのデバイスが現在使用中かを認識して、それに応じて他のデバイスでは必要に応じてカスケード式に処理するようになるべきだと思う。

そういうわけで、事情は今述べた通りだ。Apple は二つの完全に違った通知システムを使い分けていて、両者は非常に類似した結果を提供している。すべては、あなたが今どのデバイスを使っていたとしても、できる限り早くあなたが新着メールの通知をニャーゴニャーゴという声で受けられるようにするためだ。

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


iOS 6 の写真関係新機能を探訪する

  文: Jeff Carlson: jeffc@tidbits.com, @jeffcarlson
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

去年、私は既に iPhone 4 を持っていたにもかかわらず、iPhone 4S に搭載された大幅に進歩したカメラが、私に新機種を購入させるに十分な動機となった。私の写真の大多数は Nikon D90 DSLR で撮ったものかもしれないが、iPhone は常時持ち歩いているので、それをカメラとして使う機会もたっぷりある。さて今年は、iPhone 5 に搭載された A6 プロセッサとカメラのハードウェアがこのデバイスの写真撮影機能に拡張を施した。ビデオ安定化機能の改善、撮影速度の高速化、低光量下の感度やノイズ低減機能の向上などが提供されている。今のところ、私は iPhone 4S でもまだ使えると思っているので、アップグレードを控えている。(とは言っても、どうなるかは分からないが。)幸いにも、私を含む iPhone 4 や iPhone 4S、あるいはカメラ搭載の iPod touch などを持っている人たちにとって、ハードウェアは以前のままでも iOS 6 のお陰でいろいろと新たな写真関係の改善を享受できる。

パノラマ -- 宣伝文句として「美しい写真が撮れる」だけでは物足りないと考えたのだろう、Apple は iOS 内蔵の Photos (写真) アプリに新機能を一つ追加した。Panorama (パノラマ) 機能だ。一回の撮影を取り込む代わりに、このパノラマ機能はあなたが風景をパンする間に多数の画像を撮影してそれらを一枚の横長の(あるいは縦長の)写真に繋ぎ合わせる。パノラマ機能が動作するのは iPhone 5、iPhone 4S、それに第五世代の iPod touch のみであって、iPad 各機種や、旧モデルの iPhone や iPod touch では動作しない。

例えば、私が iPhone 4S で撮影した通常の写真がこれだ:

image

そして同じ場所で撮影したパノラマ写真がこれだ:

image

パノラマ機能を使うには、Camera (カメラ) アプリを開いて Options ボタンをタップし、それから Panorama ボタンをタップする。iPhone や iPod を縦長に持った状態で、シャッターボタンをタップしながら左から右へとデバイスをパンして行く。見えている矢印は単に回転方向とどの範囲まで撮影済みかの状況とを示すだけでなく、水準線を保ったままでパンするためにも役立つ。

image

あなたが画像を撮影している間に、Camera アプリは風景を分析して順次画像を取り込んで行く。単純に毎秒一回程度ずつ連続的にスナップショットを撮影しているとか、そういう簡単なことではないのだ。あなたが回転する動きが速過ぎたり遅過ぎたり、あるいはデバイスを上や下へ動かす必要があったりした場合には矢印がそれと知らせてくれる。いつでも好きな時にシャッターボタンをタップして撮影を終わらせることができるので、必ずしも水準線の終わりまで動かし続ける必要はない。

image

水準線から少しばかりずれても問題はない。このアプリは画像をトリミングして意味のあるピクセルで画面を埋めようとする。ただし、あなたの頭の周りを蜂が飛び回ったりしてカメラが水準線から大きく外れれば、画像センサーがピクセルを取り込めなかった部分が黒い領域として残ってしまうこともある。

image

この漸次的サンプリングのやり方は、風景全体で露光量に違いがある場合でも見事に処理することができるという点で私は感銘を受けた。これをテストするために、私は太陽に向かう方向を含んだ撮影を意図的に試してみた。パノラマ写真の右側の部分は暗いけれども、センサーが直射日光を浴びている場合ほど完全に暗くはなっていない。

image

撮影したパノラマ写真は、あなたの iCloud フォトストリームに(あなたがその機能を有効に設定していれば)現われる。iOS デバイスで撮影した他の普通の写真と同じことだ。私たちスタッフの一員 Michael Cohen が、素敵なヒントを教えてくれた。iPhoto で、Ken Burns テーマを使ったスライドショーの中でパノラマ写真が表示される際、このアプリケーションはズームイン・アウトをする代わりに、パノラマを左右にパンしながら賢く表示してくれる。

共有フォトストリーム -- iCloud のフォトストリーム機能は「クラウド」というものの動作の方法をデモするための素晴らしい実例となる。iPhone で写真を撮れば、数分もしないうちにその写真があなたの他のデバイス上にも現われるからだ。けれどもフォトストリームは一人のユーザーのための機能に過ぎない。あなたのストリームの中にある画像を出版して他の人たちに見てもらえる手軽な方法はない。もちろん、Apple TV 経由でテレビ画面に写真を表示させて部屋いっぱいの友人たちに見てもらうことはできるけれども。

今回新設された共有フォトストリーム機能は、あなたが選んだ一連の写真を出版して、他の人たちと共有したり、あるいはウェブ上で共有したりできるようにする機能だ。でも、あわてて Flickr 購読の解約に走ったりする前に、一度きちんと共有フォトストリーム機能で何ができるかを知り、現時点での機能の限界を知っておく方が賢明だろう。

Flickr のようなサービスは、あなたがたくさんの写真をコルク板(あるいは掲示板)に貼って、そこを通りかかった人なら誰でも見られるようにしておくようなものだと考えるとよい。例えば、あなたが私の Flickr アカウントのアドレスを知ってさえいれば、私が公開するよう指定しておいた写真をどれでもあなたは見ることができる。

それとは対照的に、共有フォトストリームの方は、写真を何枚かプリントして封筒に入れ、あなたの友人たちの何人かに手渡すようなものだと考えるべきだ。あなたが共有フォトストリームを作成すれば、あなたが選んだ写真だけがあなたの友人たちのデバイスで見られるようになるが、ただしそれは彼らがそういう写真を見たいと確認した場合のみだ。

また、共有フォトストリームを公開設定して、人々にウェブ上で見てもらうようにすることもできる。ただしその際生成されるアドレスはマシンにしか意味のない文字列 ( (例えば http://www.icloud.com/photostream/#A35WXqd93p0tj) となる。奇妙なことに、このようなリンクは Safari では動作しないようだが、Google Chrome、Firefox、それに Camino では動作する。(ただし写真は非常にゆっくりとしか出てこない。)

共有フォトストリームを作成するには、次のようにする:

  1. OS デバイス上の Photos アプリで、Photos または Photo Stream 表示にナビゲートし、Edit ボタンをタップする。

  2. あなたが共有したい写真を(複数個でもよい)タップして選択する。

  3. Share ボタンをタップしてから、Photo Stream ボタンをタップする。

    image

  4. そこで開くダイアログの中で、New Photo Stream オプションをタップする。(このダイアログはあなたが既に最初の共有フォトストリームを作成済みである場合にしか開かないので、初めて作成する場合には直接次のステップ 5 に進む。)

  5. あなたが写真を共有したい相手の人たちの名前を To フィールドの中にタイプするか、または Add (+) ボタンをタップしてからあなたの連絡先リストの中から相手を選ぶかする。ただし共有フォトストリームを作成する際にここに誰も含めなくても構わないので、この To フィールドは空のままにしておいてもよい。(あとで誰かを含めたくなればその時に追加できる。)ちなみに、その相手の人たちがあなたの共有相手に加えたいという申し出を受け入れた場合のことをあらかじめ心積もりしておくとよい。その際、OS X 10.8 Mountain Lion の通知機能が、高々とアラームを鳴り響かせるからだ。(いや、確かに素敵な音色だけれど、それでもやはり初めて聞いた時は心底びっくりした。)このオプションをオフにしておくには、Notifications 環境設定パネルでサイドバー上の Photo Stream 項目を選び、"Play sound when receiving notifications" をオフにすればよい。

  6. Name フィールドでストリームに名前を付ける。

  7. 共有フォトストリームを誰でも見られるようにしたい場合は Public Website オプションを On にしておく。

    image

  8. Next ボタンをタップする。

  9. その次のスクリーンで、オプションとしてコメントを入力することができる。このコメントは、相手の人たちに送られる電子メールに含められる。コメントの文字数は 200 文字までだが、例えば Twitter でコメントを共有する際のような現在文字数カウントが表示されることはない。そして奇妙なことに、コメントはあなたが最後に追加した写真に添付される。最後に Post ボタンをタップすればストリームが出版される。

共有フォトストリームは、Photos アプリの Photo Stream 表示に現われる。

image

当然ながら、この共有フォトストリームの魅力は、あなたの友人たちが持っている iOS 6 対応デバイスや、第三世代 Apple TV でも見られる点だ。だから、私の母が友だちと集まった際に孫の写真を彼女の iPad で皆に見せたいと思えば、iPhoto をいじったり iTunes で同期したり Safari で写真を呼び出したりなどという手間が一切要らない。彼女の iPad に、そのまま写真が現われるからだ。(10.8.2 ユーザーならば iPhoto 9.4 かそれ以降あるいは Aperture 3.4 かそれ以降で写真が現われる。けれども、10.7 Lion の下で iPhoto や Aperture を使っても写真は現われない。)

実際、既存の共有フォトストリームに写真を追加することもいつでもできる。まず画像を選択し、Share ボタンをタップし、Photo Stream を選び、それから追加したいストリームを指定するだけだ。ただし共有は一方向のみであって、あなたが作成したストリームにその購読者がその人の写真を追加することはできない。

しかしながら、iPad の上では,一つインターフェイス上の奇妙な点が気になる。ストリームの詳細情報を変更したい場合、例えば新規の購読者を一人追加したい場合などに、そうするためのすぐ分かる方法が見当たらないのだ。まず Edit ボタンをタップしてから、Shared Photo Stream をタップすればできる。これはどうやら Photos アプリの新しいインターフェイスのしきたりらしい。私は偶然そこに行き着くまではどうしてよいのかさっぱり分からなかった。iPhone や iPod touch の上では、ストリーム名の右側に青い Details ( > ) ボタンが表示されるので分かりやすい。

image

共有フォトストリームにはもう一つ新しい追加機能があって、どうやらこれはあらゆる近代的写真機能に必須のもののように見える。セットを購読している人は誰でも、写真に対してコメントを書き込んだり "like" ボタンを押したりできる。書き込まれたコメントは、Comment ボタンをタップすれば画像の下の部分に重ね書きして表示され、そのセットを購読しているすべての人が読める。

image

その他写真に関する変更点 -- iOS 6 での写真に関する最も大きな変更点はパノラマモードと共有フォトストリームだが、他にもいくつか変更点がある。

予想される通り、Photos アプリの Places 表示は Apple の新しい Maps データおよびインターフェイスを使うようになった。位置座標情報がタグ付けされた写真はすべて地図上にも現われるが、これは地図のデフォルト表示のみであって衛星写真表示やハイブリッド表示ではそうならない。(iPhoto や Aperture は依然として Places 表示に Google の地図情報を利用しているが、次回のメジャー改訂の際には間違いなく Apple のサービスに切り替わるだろう。)

image

以前からずっと人々を悩ませてきた問題点が一つ解消された。Mail アプリの内部で、写真やビデオを送信メッセージの中に挿入できるようになったのだ。従来は、まず Photos アプリに(あるいはそのデバイスの Camera Roll にアクセスできるアプリならば何にでも)ナビゲートしてから写真を選択し、それからそれを Mail に共有させるという手間が必要だった。今回から、Mail アプリでメッセージを作成中に、一秒間押さえ続けることでオプションのツールバーを呼び出せば、ツールバーの上に Insert Photo or Video というオプションが含まれるようになった。

image

ただし、写真家は注意していないと痛い目に遭うかもしれない副作用が生まれてしまった。デジタルカメラから raw フォーマット (例えば .CR2 や .NEF) で写真を(例えば iPad Camera Connection Kit を使って)読み込んである場合に、Mail が取り込むのは低解像度のプレビューのみだ。オリジナルの raw ファイルを電子メールで送信したいと思えば、Photos アプリの方から共有する旧来の方法を使う必要がある。

最後に、私が初めて iPad を使った時以来私を戸惑わせ、いまだに戸惑わせ続けている一つの頭痛の種を報告しておこう。Photos アプリの Slideshow 機能が、不可解にもたった一つの楽曲しか再生できないのだ。Slideshow ボタンをタップすると、Play Music というオプションが表示されるが、その際の選択肢として一つの楽曲を指定して選択することしかできない。考えられる理由としては、スライドショーに音楽を流す機能など誰も実際には使っていないから、あるいは Apple のエンジニアたちがあまりにも忙し過ぎて三分間より長いスライドショーをお互いに見せ合う暇がないから、ということくらいだろうか。

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


ExtraBITS、2012 年 10 月 22 日

  文: TidBITS Staff: editors@tidbits.com
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

今週の ExtraBITS は、Jeopardy に出演するのがどんな気持ちであるかを語った Glenn Fleishman の記事と (残念ながら実際の番組はオンラインにない)、Apple がそのメディア資産を世界のどの地域で販売しているかを概観した興味深い MacStories 記事だ。

全世界のメディアセールスの中で Apple が占めるシェアは? -- 米国内のジャーナリストやアナリストたちは、Apple の成功の大きな要因として同社の全世界的事業展開があることをとかく忘れがちだが、それは実際非常に大きい。MacStories の Graham Spencer が、Apple がそのメディア資産: 音楽、映画、テレビ番組、電子ブック、そしてアプリを、どこで販売しているのかについて注目すべき概観をまとめ上げた。彼はまた同じことを Microsoft、Google、Amazon.com についてもそれぞれ調べ上げて比較をし、Apple が他社に比べて相当大幅な幸先の良いスタートを依然として保っていることを実証している。

コメントリンク: 13342

TidBITS 編集者 Glenn Fleishman が Jeopardy に登場 -- TidBITS の Glenn Fleishman がクイズ番組 Jeopardy に出場し、自らの知力と反射神経を試した!(残念ながらこのテレビ番組はストリーミング配信もされていないし、最初の放送以後再放送の予定もない。)Economist の記事で、Glenn が自らの詰め込み勉強の戦術について語る。

コメントリンク: 13341

コメントリンク: 13341


tb_badge_trans-jp2

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

TidBITS ISSN 1090-7017©Copyright 2012 TidBITS: 再使用はCreative Commons ライセンスによります。

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