RetinaモデルのMacBook Proを触ってきました

銀座のアップルストアにて、Retinaモデルをおさわりしてきた。2.3GHzのモデル。

1. 起動時間

まずはRetinaじゃないのか!!という気もしないではないが、ひとり焦らしプレイとしてまずは起動時間を測った。手動計測。非Retinaの新MacBook Pro(2.3GHz)の37秒に対し、Retinaは13秒。速い!フラッシュストレージの恩恵がそのまま出た感じ。実は新Airもそのくらいだったので、Retinaには10秒を期待していたが、起動時間についてはAirとほぼ同じだった。いろいろおかずをつけても20秒くらいで収まってくれれば嬉しいが、これは買ってみないとなんとも。スリープと復帰は一瞬で、計測する必要性を感じないレベル。これもAir同様。

2. 重さ

次に重さ。13inchとほぼ同じ2kgのRetinaモデルを持ってみた。15inchとしては驚きの軽さ。私のバッグに幅に収まることも確認。13inch持ち歩いてる人なら、同じ感覚で15inchを持ち歩ける。同じ重さだから当たり前だが嬉しい。むかーし2.5kgのPowerBook15inchを持ち歩いてたが、0.5kgでもだいぶ違う。あと、見た目のデカさと持った感触の軽さの「ズレ」が奇妙だ。満タンに入ってると思った牛乳パックを持ち上げたら実は空っぽで意表をつかれた経験を持つ人は世界人口の86%に達するそうだが、アレに近い感覚。

3. Retinaモード

さてRetina。文句なく素晴らしい。iPhoneiPadRetinaで感動できた人は同様に感動できる。iPhoneの326ppiや、iPadの264ppiよりも劣る220ppiなので正直どうかと思っていたが、問題ない。ほんの数分しか見てないにもかかわらず、Retinaモデルの後に見た従来機が、だいぶ貧相に見えるほど。ちなみにMBA 13inchは127ppi、非Retina MBP 15inchは110ppiである。

4. 1920*1200px表示

私を含め巷の「作業スペースマニア」が気になるのがこちら。驚くべきことに「問題なし」だった。イラレを立ち上げて線幅1pxの矩形を描いてみた。アンチエイリアスのかかっていないシャープな矩形が描けた。素晴らしい。いくつか描いてみてもやはり滲みは無い。理論上は、2880*1800pxのディスプレイ解像度を、無理矢理1920*1200pxの作業スペース解像度に変換するわけだから、1pxは1.5pxに拡大されているはず。整数倍ではない拡大ならばアンチエイリアシングが必須のはず。なのになぜ滲まないのか。実際は滲んでいてもドットピッチが精細なため、滲んでいないように見えるのか?しかしシステム環境設定のユニバーサルアクセスで「ズーム機能:入(スムージングOFF)」にして拡大してみても滲みはない(ズーム機能では拡大しつつ作業スペース解像度を「Dot By Dotの整数倍」に変換している可能性はある)。他のUIパーツも問題ないように見えた。とにかく10分ほどいじくりまわした範囲では、1920*1200px表示は十分に実用に耐える印象。UI要素はもちろん小さくなるので、長時間使用したときにどうか。
ともかく、今自宅で使用しているLEDシネマ24インチと同じ作業スペースを持ち運べるのだから、これでめでたくカフェ()でノマド()なクリエイター()になれる。
ただ、「ボケた」という報告もあるので(http://www.macotakara.jp/blog/index.php?ID=16845)、もっと時間をかけて再度確認したい。

5. 2880*1800px表示

まあ分かっていたことだがこれは出来なかった。一般にアップル製品は「Option押しながら何かしてみると良いことがある」ので、ディスプレイ環境設定でやってみたが、良いことは特に起きなかった。ということで正真正銘のDot By Dot表示は確認できず。残念。ただいずれその手のカスタマイズ技は出回ると思われる。

なおRetinaディスプレイのドライバがいい意味で(?)提供されていないブートキャンプ環境下では2880*1800pxの作業スペース解像度を実現できるようだ。ただ、試してみた人によると、やはりUI要素が小さすぎて実用的ではない様子(http://www.asobuoiphone.com/archives/4045153.html)。うん、知ってた。

2012/6/26 追記:MacOS X環境下でも2880*1800px表示ができるサードパーティソフトが早速リリースされている模様。

6. 小ネタいろいろ

a. WebサイトのRetina対応について

アップルのサイトはRetina対応済みの模様。たとえばこのページ(http://www.apple.com/jp/retail/ginza/)のアポスト写真だが、従来機で見ると564*376pxなのに対し、Retinaモデルで見ると倍の長さ「1128*752px」だった。これを半分の564*376pxにぎゅぎゅっと濃縮して表示している。RetinaモデルのSafariはユーザエージェントが異なるのか、ディスプレイ解像度をJavascriptで取得しているのか。なんらかの方法で端末情報を取得して、サーバ側にて画像を出し分けているようだ。

b. MacBookロゴがない

20年以上前のMacintosh ポータブルのころから含めて考えても、これは初の珍事ではなかろうか?ロゴ、欲しい。

c. 電源ボタンがMacBook Air風に

薄さ対策のためだと思われる。アルミボタン欲しかった。。。

d. スリープやバッテリー残量のインジケータがないよ〜

欲しい。。。

最後小さな不満は書きましたが、全般的に文句なしで「買い」。私も実は今日の確認より前に、発表即ポチした。

以下はおまけ。時間のある人はどうぞ。

おまけ1. OSとアプリのRetinaモード対応について

OSとアプリの対応については、アポー謹製アプリは見た限りでは完了しているようだ(2012/6/26 訂正:iWorkアプリのほかいくつかは未対応でした)。その他のアプリは順次となるが、iOSの前例があるので遅滞なく粛々と進むと思われる(ただしAdobe以外)。もちろん非対応でも、従来機と同じ従来の解像度で見えるだけなので、深刻な問題とはならない。Retina対応アプリから切り替えたときに、若干微妙な気分を味わうだけである (´・ω・`)ショボーン とはいっても、アプリ独自のビットマップ画像が少なく、OS提供のUIパーツを多用しているアプリなら、何もしなくてもある程度Retinaモードの恩恵は受けられるだろう。特に文字などはほとんどRetinaモードでの表示となるはずだ。
なお、文字やベクターデータであっても、たとえばイラレの図形や文字のレンダリングはOSで提供されているものではなく独自のレンダリングエンジンを使用しているので、アプリ側の対応待ちとなる。

2012/6/26 追記:2chソースでアレだが、Excelなど未対応アプリでの表示が「従来機と同じ従来の解像度で見えるだけ」ではなく、従来機よりも低クオリティ(ボケてるとかギザギザといった表現)だとする意見もあり。

おまけ2. 妄想版イラレ

Final Cut Pro Xでは、UIパーツはRetinaモード(従来の1pxを4px使って表示)、HDのプレビュー領域ではDot By Dotという荒技を見せている。Appleのサイトによると「ポータブルコンピュータで初めて、一つひとつのピクセルが正確に再現された1080p HDビデオを見ながら、それを編集するためのワークスペースも同時に画面に表示できる」とのことだ。
イラレやフォトショもぜひともこれにならって欲しい(期待薄)。ドキュメントウィンドウ内のみDbDで正確かつ広大なワークスペースを確保し、その他パレットやメニューバー等はRetinaモードで見やすい表示(期待薄)。これならば1920*1200表示にせず、常にRetinaモードで作業完結できる!(期待薄)。現状で外部ディスプレイに頼らず作業しようとすると、広いワークスペースを求めて1920*1200表示にするか、適度な大きさのUI求めてRetinaモードにするかの選択となる。

おまけ3. 「Retina」や「解像度」という言葉について

ディスプレイ解像度に選択の余地がないiPhoneiPadでは問題にならなかったが、RetinaモデルのMacBook Proでは「Retinaディスプレイ」と「Retina」は意識的に分けてつかう必要が出てきそうだ。アップルのサイトやシステム環境設定でも、この二つの用語は明確に分けているように思う。

  • Retina:従来の1pxを縦横各半分に小さく分けて2px*2px=4pxをつかって表示するモードのこと。言うときは「Retina」だと紛らわしいので、「Retinaモード」「Retina表示」などと言えばいいと思う。
  • RetinaディスプレイRetinaモードでの表示が可能なディスプレイのこと。

前者はソフトウェア用語で、後者はハードウェア用語と考えればよい。
また従来機は、1pxのデータは、ディスプレイの1pxを使って表示する(Dot By Dot=DbD)のが常識だったが、Retinaモデルではハードウェア的な「ディスプレイ解像度」と、ソフトウェア的な「作業スペース解像度」は分けて考える必要がある。「作業スペース解像度の長さ2倍(面積4倍)=ディスプレイ解像度」という状態が「Retinaモード」ということになる。Retinaモードじゃない作業スペース解像度(1920*1200表示など)もシステム環境設定から選択可能で、上でも書いたように、実は私的にはこちらの方に興味があった。

MacOS XのMail.appでWindows宛にメールを送ると、添付の画像ファイルが本文に貼り付いてしまう件

これで直りました。

Attachment Tamer
http://lokiware.info/Attachment-Tamer

Mail.appのプラグインの形で提供されていて、インストールするとMail.appの環境設定にAttachmentTamerの設定が現れる。私の場合は、全部デフォルトのままでOKだった。
$14.99のシェアウェアだが、具合がよさそうなのでさっそく購入した。

もう少しくわしく

MacOS X LionのMail.appでは、画像「だけ」を複数添付した場合、画像を本文にインライン表示する(attachment-disposition: inline)。Outlookなど一部のメーラーでは、この指定がなされた場合、HTMLメールとして解釈して表示しようとするため、本文に画像が貼り付くという事象が発生するようだ。こうなるとWindowsOutlookでは、添付ファイルとして保存することも開くこともできなくなる(私の環境はWindows XP SP3のOutlook2007)。

また、画像が1点だけでも、ファイル名に日本語が含まれる場合、拡張子datの意味のわからない添付ファイルとなってしまっていた。これはまた別の理由っぽいけど。

回避するには画像が1点だけならファイル名を英数にする。画像が複数あるなら圧縮してまとめるか、画像以外のファイルを添付するしかなかった。これら諸問題を、Attachment Tamerをインストールすることで、すべて解決できた。

WordPressの「アップロードファイルの最大サイズ」に関するメモ

WordPressでアップロード可能なメディアファイル(画像、動画、サウンド、PDF等)には、容量制限がある。
「制限=100MB」といった設定箇所が1カ所なら何も難しいことはないのだが、複数の設定が関係し合い、最終的な容量制限が決まるためややこしい。なのでちょっと整理してみた。

WordPress 3.2.1で確認。

アップロードファイルの最大サイズの基本ルール

アップロードファイルの最大サイズについては、「メディア>新規追加」で表示される「アップロードファイルの最大サイズ」で確認できる。ここで表示される数値は、以下のルールに基づき決定される。

  • 以下の「」をつけた箇所のうち、もっとも小さな値
  • もし下記2-a「サイトのアップロード容量」で、サイト全体の容量制限が設定されている場合の残り容量が、のいずれの値よりも小さい場合は、その残り容量

1. php.ini(Webサーバのphpの設定ファイル)

  • memory_limit = 66M ; Maximum amount of memory a script may consume ※例では66MB。スクリプトが使用するメモリの上限(下2つの設定値以上である必要がある)
  • post_max_size = 65M ; Maximum size of POST data that PHP will accept. ※例では65MB。PHPが受け取るPOSTデータの上限(アップロードするファイルとフォーム等の入力データ全部合わせての数値。下の設定値以上である必要がある)
  • upload_max_filesize = 64M ; Maximum allowed size for uploaded files. ※例では64MB。ファイルアップロードの上限(あくまでファイルだけ)
  • max_execution_time = 300 ; ※単位は秒。タイムアウトにならない程度に適宜。
  • max_input_time = 300 ; ※単位は秒。タイムアウトにならない程度に適宜。

php.iniを編集できない環境の場合、またはPHP全体の設定を変更したくない場合は、WordPressインストールディレクトリ直下の .htaccess に以下を追記することで変更できる。php.iniと.htaccessでは、値の大小に関わらず後者の設定が優先される。php.ini も .htaccess もいじれない環境の場合は諦めてサーバの設定に従うしかない。

2. WordPressの「ネットワーク管理者>設定>アップロード設定」

  • a. サイトのアップロード容量

    ここにチェックを入れて xxx MB とすると、1ブログ当たりの「アップロードファイルの合計」容量を制限できる。外すと無制限。

    →設定は、各サイトのダッシュボードの「現在の状況」に「保存スペース」という表示欄に反映される。「xx%使用中」など出る。欄自体がなければこの設定がOFFになっているということ。

  • b. アップロードファイルの最大サイズ

    上記設定のすぐ下。1個のアプロードファイルの最大容量を設定する。単位はKB。32MBとかにしたいなら 1024KB * 32 = 32768KB などと設定。

    →設定は、各サイトの「メディア>新規追加」の「アップロードファイルの最大サイズ」に反映される。

容量制限を変更した場合の注意

アップロード可能容量を増やした結果、処理のタイムアウトが頻発することを防ぐために、上記1でも少し触れたが、以下2つのパラメータの設定値を忘れずに確認すること。単位は秒。

  • max_execution_time スクリプトがパーサにより強制終了されるまでに許容される最大の 時間を秒単位で指定 →(アップロードとその他の処理を含め)xx秒経過したらタイムアウトで処理中断する
  • max_input_time スクリプトが POST、GET そしてファイルアップロードなどの入力を パースする最大の時間を、秒単位で指定します。→(アップロードだけで)xx秒経過したらタイムアウトで処理中断する


以上です。

Evernote整理してたらありがたいクオートがいっぱい出てきたので晒す

新年明けましておめでとうございます。
今年もよろしくお願いいたします。

さて、昨年のまとめも今年の抱負も華麗にすっとばしまして表題の件。

かつて本やネットで拾った格言チックなものを集めてた時期があるのだが、このたびそれを発掘したので載せておく。今風に言うと晒しとく。Web2.0風にいうとシェアしとく(よしこれで「Web2.0」という言葉を世界で最後に使ったのはオレ)。

メジャーリーガーからアルファブロガーまで、こんなにたくさんのクオートが一度に読めるのはジャンプだけ!

・・・というほど多くないが(むしろ「集めてた」とか偉そうに言う割に少ないが)子育てからITまでごった煮で、それでは参ります。

思考に気をつけなさいそれはいつか言葉になるから。
言葉に気をつけなさいそれはいつか行動になるから。
行動に気をつけなさいそれはいつか習慣になるから。
習慣に気をつけなさいそれはいつか性格になるから。
性格に気をつけなさいそれはいつか運命になるから。
マザーテレサ

真実はそれゆえに自ずと勝利する。
(インドの国是)

サンスクリット語では satyameva jayate サッティヤメーヴァ・ジャヤテというらしい。よかった「マハーポーシャ」とかじゃなくて。

イデアというのは 複数の問題をいっぺんに解決すること。
任天堂 宮本茂

糸井重里の「ほぼ日」で知った。

不安というのは自分の中だけにあるもの。現実には存在しません。
野茂英雄

部分的に尊敬できる人というのは結構いるが(それでもすごいことだが)野茂は安心して全部を尊敬できる。

愚痴を言うな。愚痴をいうと自分の器を小さくする。
孫正義

ITでお金が欲しいならまずはPVを出せ。
PVが欲しいなら特定の人を呼べ。
特定の人を呼びたいならコンテンツを絞れ。
コ ンテンツが作れないなら更新すれ。
更新できないならネタを探せ。
ネタが見つからないなら見つかるまで今探せ。
今この瞬間探しも調べもしない奴はWEBでお金が欲しいというな。
(「ホームページを作る人のネタ帳」より。 http://e0166.blog89.fc2.com/blog-entry-722.html

記事を書いた人の師匠の言葉だそうです。面白い。

ただ現在において正しいことを行ったらば人として立派なものであると信じておる
(実業家・日本資本主義の父 渋沢栄一

先のインドの国是と通じるものがある。坂の上の雲じゃないけど、明治の日本はこれで身を立てられた幸せな時代。。。なのかな?

人生は5つのボールをジャグリングしているようなものだ。その5つとは、仕事、家族、健康、友達、精神だ。

このうち、仕事のボールだけがゴムで出来ている。落としたとしてもちゃんとあなたのところに同じ強さで戻ってくる。

しかし他の4つは違う。これらはガラスのボールだ。落としてしまえば傷がつくかもしれないし、最悪割れてしまうかもしれない。決して元のままにはならないのだ。

これが現実だ。この現実に向き合って生きていかなくてはならない。
コカ・コーラCEO、Bryan Dyson

ジャグリングて。。。。難易度高!

胸を張って負け犬になれない者は、勝者にもなれない
(米女優ハル・ベリーの母)

ハル・ベリーラジー賞を受賞してしまったとき、この母の教えに従いセレモニーに出席し、尊敬を集めたそうだ。

神は細部に宿る
(建築家 ミース・ファン・デル・ローエ

神が宿ったせいかどうかは知らないが細部まで行き届いているモノはどんなジャンルでも見ててわくわくする。

Less is more.
(建築家 ミース・ファン・デル・ローエ

レスイズモアーーー。レスイズモアだけ気にして神は細部に宿るを気にしないと目も当てられないことになります(実話)。レスイズモアとはなんもしないことじゃないよーーー。この2つを同じ人が言ってるところが味わい深い。

子供が出来たら胸を離すな(乳児期)
胸を離したら手を離すな(幼児期)
手を離したら目を離すな(少年期)
目を離したら心を離すな(思春期〜)
(出展不明 ググる2chまではたどれるがその先が不明)

子離れ、これ大事。

智に偏れば角が立つ。情に棹させば流される。意地を通せば窮屈だ。
夏目漱石草枕」)

リズムがいい。

(インタビュアに「電球の発明では14000回も失敗したそうですが、苦労しましたね」と問われて)私は失敗を14000回繰り返したのではありません。成功しないやり方を14000回、発見し続けただけなんです。
エジソン

たしかに!クライアントにはこんなこと言えないですが。

イデアに詰まると皆で宮崎アニメを見た。そして宮崎アニメにはヒントが必ず有った。
ピクサー ジョン・ラセター

ジョン・ラセターはすごい人。ピクサー映画は「神は細部に宿る」を完璧なまでに実践してるのでクリエイターなら全作品最低3回ずつ見ておきたい。メーキングも面白いよ。

随所で主人公たれ
(禅語 瑞巌和尚)

出展怪しい

神に祈ったか?
(京セラ 稲盛和夫

やるべきことをやりつくしたと思ってもまだやることがあるぞと。

Memento mori メメントモリ(死を想え)
ラテン語の慣用句)

古代ローマでは凱旋将軍の後ろでmemento mori memento moriと唱える人がいて「オイコラちょっと勝ったくらいで調子のんなYO!」と戒めていたそうです。怖!

私は事業のために映画を作っているのではなく、映画を作るために事業をしている
ウォルト・ディズニー

「プロダクトアウト」というと矮小化しすぎだけどその言葉が頭に浮かんだ。

富める人がその富をどんなに自慢していたとしても、彼がその富をどのように使うかがわかるまで彼を褒めてはならない
ソクラテス

子供に伝えたい。

他人と過去は変えられない。自分と未来は変えられる。
高塚猛 同名の書籍タイトル)

まぁこの人自身は間違った方へ「変わって」しまったんですけどね。。。ソクラテスの言葉を送りたい人。

孤独は山になく、街にある。1人の人間にあるのでなく、大勢の人間の『間』にあるのである
三木清「人生論ノート」)

オレ言ったった感が強い格言。

「いじめはなくならん」「いじめは無理矢理なくそうとするんやのうて、必ず起こる事として正面から向き合えばええと思うがどうじゃ」
(ボクシング元世界チャンピオン 竹原慎二

竹原慎二のボコボコ相談室に書いてあって感心した。そうそう、いじめは無くなりません。ゼロを目指すものではなくて、起こったときはきちんと対処するぞという覚悟が大人には必要だと思います。

私の業績の中で最も輝かしいことは、妻を説得して私との結婚に同意させたことである。
ウィンストン・チャーチル

夫婦げんかしてご機嫌取りたかったのかな?

苦しいこともあるだろう 言い度いこともあるだろう 不満なこともあるだろう 腹の立つこともあるだろう 泣き度いこともあるだろう これらをじっとこらえてゆくのが 男の修行である
山本五十六

山本五十六はカッコイイ!

やっている、姿を感謝で見守って、信頼せねば、人は実らず
山本五十六

話し合い、耳を傾け、承認し、任せてやらねば、人は育たず
山本五十六

やってみせ 言って聞かせて させて見せ ほめてやらねば 人は動かじ
山本五十六

製品だ!
スティーブ・ジョブズ

97年倒産寸前のアップルに復帰したジョブズ。社員を前に「何が問題か?」問いかけたあと、答えを叫んで。実際のところマーケティングも営業もマネジメントも全てが問題には違いなかったのだが、製品だと(単純化して)言い切れるところが偉い。

なくしてしまえ
スティーブ・ジョブズ

iPod Shuffleのディスプレイについて。エッジが効いてるとはこういうこと。


以上です。ジョブズのみ最近読んだ伝記本から。

あらためて見直すとなかなか面白い。また来年やろうかな。

「よくわかる日本の教育費」を立ち上げました

子どもの教育費をざっくり試算できるサイトを立ち上げました。HTML5とCSS3をこっそり使ってます。就学前から、小学校、中学校、高校、大学と、子どもが独り立ちするまでに必要なトータルの教育費を、簡単に求めることができます。

よくわかる日本の教育費(EducationalCost.com)

人生の3大支出は「住居費、教育費、老後生活費」といわれていますが、このうち住居費と老後生活費の試算が比較的容易であるのに対し、教育費は私立公立/文系理系/仕送り額など変数が多くて試算が面倒でした。

本サイト「よくわかる日本の教育費」は、子どもの教育費について「だいたいでいいから手っ取り早く知りたい」というニーズに応えるサイトです。

年末もいよいよ押し迫ってきたこの時期に、年賀状も大掃除も子供の世話もせずにいったい何をやってんだという嫁の視線に耐えてやってきましたので、ぜひ見てやってほしいと思います。

IE7以上で利用可能ですが、作者としてはSafariChromeFirefoxOperaなど、角丸、ドロップシャドウに対応したブラウザで見て欲しいなと。そういうわけで、よろしくお願いいたします。

▼スクショ。いずれスマホに最適化したUIも持たせたい。もちろん今でもPC同様には閲覧可能です。
f:id:neriu:20111230014747p:image
よくわかる日本の教育費(EducationalCost.com)

iCloudのバックアップ機能は使えるか?バックアップしてくれるものとしてくれないものをまとめた。

iCloudにはバックアップ機能がある。iOS5対応デバイスiCloudのアカウントを持っていれば、誰でもバックアップ機能を無料で利用できる。バックアップには気を遣いたくない。普段はまったく意識せずにいて、必要なときにだけ「やっててよかった」となるのが理想だ。iCloudはそんな使い方ができるのか、考えてみた。

iCloudバックアップ。これが出来ればオーケー。

  1. 日常のデータ保全
  2. 緊急時の復旧
  3. 買い換え時のデータ移行

2と3は、1ができていれば問題なかろう。というより母艦なしで復旧や移行ができたりと、従来の母艦バックアップ方式よりも、利便性があがっている。私は試したことがまだないが、まあネット上でも「でけたw」という報告を聞くし心配しても始まらないので、ここではまあ良しとしたい(なんだそりゃ)。

問題は1。従来の母艦バックアップ方式と比較して気になる点は「すべてのバックアップを取るわけではない」という点。バックアップを取らないデータについては別途ケアする必要があるのか?そんなのは面倒だ。しかしすべてのバックアップをクラウド上に保存してしまうとストレージやらトラフィックやらが大変なことになることも想像に難くない。そのへんどうなっているのか。

iCloudがバックアップしてくれないもの

iCloudがバックアップしてくれないものはいくつかある。それぞれについてその妥当性を考える。


  1. 音楽、動画

    まず、iTunesで購入した音楽、動画。これはバックアップはしないが、購入情報を元に再ダウンロードできるので問題ない。iCloudストレージの容量制限外でもあるため、どれだけ大量に購入しても大丈夫。

    次に、iTunesで購入していない音楽、動画。自分でCDからリッピングした音楽、ビデオカメラ等他のデバイスで撮影して取り込んだ動画など。これらはマスターデータが母艦にあるはずなので、母艦自体のバックアップがなされていれば問題ない。

    さらに「カメラロールにある写真、ビデオ」はバックアップ対象になる。つまりiPhoneで撮った動画(もちろん写真も)についてはバックアップされるので大丈夫。

    結果として、音楽、動画に関してデータが失われるといったケースは想定しづらい。


  2. カメラロールにない写真、動画

    1の内容と少し重複するが、iPhoto等からiTunes経由で同期していた写真、動画はバックアップされない。しかしこれも前述のとおり、母艦自体のバックアップがしっかりとなされていれば、iCloudでバックアップされなくても問題はない。


  3. メール

    IMAP対応のメールを使用すれば問題なしmac.com、me.com、Gmailソフトバンクのi.softbank.jpなどなど、最近の多くのメールサービスはIMAPに対応している)。


  4. アプリケーション、本(iBooks

    これも1で触れた「iTunesで購入した音楽、動画」と同じ考え方で、アプリケーションや本そのものはバックアップデータに含まれない。AppStoreから再ダウンロードする形をとることで、バックアップ時間と容量の節約に一役買っている。アプリケーション、本の設定や保存データはバックアップされるので、結果として、ゲームのセーブデータや各種設定なども含めて、すべて復元できる。よってこれも問題なし。


  5. ボイスメモ

    どうなんでしょうか?普通に考えれば「アプリケーションの保存データ」ということならバックアップとってくれていそうだが。

iCloudバックアップの留意点

次に留意点をいくつか。


  1. iCloudのストレージ容量

    デフォルトかつ無料の5GBだと足りない場合がある。私は3つのデバイスiPhone×2、iPad)の合計で6.3GBだったが、その場合は追加のストレージを有料で申し込む必要がある。足りないままだとバックアップが完了せずまったく用をなさないので注意が必要だ。ただ母艦か端末のiCloudの設定画面でちゃんとバックアップできてるかは確認できるし、アラートも出るので見落とすことはないと思われる。ちなみにこの設定画面で調べたら6.3GBのうち、5GB以上がiPhoneのカメラロールだった。ということはカメラロールの中身をマメにiPhotoに取り込むなどしてすっきりさせておけば、無料の5GBでも全然いける。またカメラロールのうち静止画については「フォトストリーム」をONにしていれば自動的に母艦と同期できる。動画を撮らないまたは撮ってもマメにケーブル繋いで取り込むよーという人は、iCloudバックアップ対象からカメラロールを外すという手もありだ。私は細かな設定や取り込みが面倒なので「全部入り」バックアップにしている。


  2. 母艦(PC、Mac)のバックアップはしっかりと

    繰り返しになるが、iCloudは「他の場所にマスターデータあるよね」という類のデータはバックアップしない。音楽、カメラロールにない写真・動画、メール、アプリすべてこのポリシーに基づいてバックアップ対象のデータが選別されている。したがって、音楽、映画などの動画、アプリなど、iTunes StoreApp Storeから再ダウンロード可能なものはともかく、自分の母艦に保存しているデータは、そちらはそちらでしっかりバックアップをとる必要がある。

    MacならばTimeMachineでバックアップしておけばよいだろう。私はさらに万全を期すために、TimeMachineのバックアップ先をRAID1に対応した外付けHDDにしている。余談だが、TimeMachineバックアップはホントに素晴らしい。積年のバックアップに対する不安がほぼ無くなった。とにかく「何も気にしなくてもいい」。これに勝る利便性はない。復旧もボリュームまるごとでもできるし、1ファイルだけさくっと復活もできるので、間違って削除や上書きしてしまって困るということがない。


  3. POP3にしか対応していないメールサービスを利用している場合

    POP3メールを使っていて、iPhone/PC/Macで送受信したメールは、それぞれが壊れれば、失われる可能性が高い。IMAPと違って元のデータは(原則として)サーバに保存されないからだ。はやめにIMAPメールに移行するのが最善なのは言うまでもないが、なかなかそうもいかない場合もある。その場合は、POP3で送受信したメールをiCloudで取得したme.comのIMAPメールボックスに移動すればよい。他にGmailなども利用しているのであればそちらでも構わない。

まとめ - iCloudバックアップを使うか否かの判断

以上から、iCloudのバックアップは、必要十分な仕様となっていると言えそうだが、考えてみれば、従来の母艦バックアップも必要十分ではなかったか?iCloudにバックアップするのと母艦にバックアップするのにはどんな違いがあるのかまとめる。


  1. ケーブルレスで勝手にバックアップしてくれる

    ケーブルに繋がなくても、知らないうちに勝手にバックアップしてくれる。今までは母艦に繋ぐとまずバックアップが始まり、データ量が多いときには結構待たされた。キャンセルしないとケーブルを外せないため、急いでいるときには断腸の思い出キャンセルしたものだが、そういうことに気を遣う必要がなくなった。上のTimeMachineのところでも触れたようrに「気にしなくていい」ところが素晴らしい。


  2. 母艦のディスク容量が気になるならiCloudバックアップ

    従来の母艦バックアップ方式だと、母艦上に平気で何十GBものバックアップファイルが作成される。私はMacBookSSD(120GB)にしてからというものこれに悩まされてきた。MacBook Airなどを使っている人も同様の問題を抱えていることだろう。そんな場合にiCloudのバックアップは助かる。


  3. 母艦なしで復元したいならiCloudバックアップ

    WiFi回線があればどこでも復元できるので、出先で緊急事態に見舞われたときは助かりそう(もちろん母艦にしかないデータは復元できない)。


  4. データをクラウド上に保管すること自体のリスクをどう考えるか

    一般的には、個人ユースのMac/PCよりも、しかるべきデータセンター内のiCloudの方が、さまざまな面でリスクは少なそうではある。いくら「TimeMachineでMacのバックアップは完璧」と言ってみたところで、家が災害等に見舞われれば、データを失う可能性は高い。自宅がどうにかなってもデータを守れそうなのは、クラウド上にバックアップしておくメリットのひとつだ。デメリットというのか留意が必要なのは、iCloud自体の情報漏えいや改ざん・不正使用などのトラブル。可能性としては当然ある。もっとも母艦がノーリスクというわけではもちろんないので、双方に相応のリスクが存在することを認識して利用するしかない話である。

そんなわけで、以上のような検討(?)の結果、iCloudのバックアップ機能を利用することにした。iCloudは発表からリリース前後までに色々な情報が飛びかい、国によって対応サービスも異なるなど少し複雑になってしまうかと危惧したが、バックアップに関しては、結局は「おまかせプラン」で大丈夫ということが判明したのでひと安心。

半月ほど経つが、今のところ何も問題はない。バックアップのことを意識したのは、最初に「容量足りねーYO」と怒られたときだけ。バックアップ中に端末動作が重くなるような気配も特に感じられなかったし、万一のときは平然と復旧してくれるのだろうという(昔のApple製品では考えられないような)安心感がある。

MobileMe(というより.Mac)から引き続き利用している、連絡先/カレンダー/ブックマークの同期機能も快適。「Macで編集した情報が一瞬にしてiPhoneiPadに同期されている」というキモさも相変わらずで頼もしい限りだ(その逆も然り)。余談だが、キーチェーン/Dock/ことえり辞書が同期しなくなったのは困る人もいるんじゃないかと思う。。。私も以前は「会社←→自宅1号←→自宅2号」でのヘビーシンクロナイザーだったが今はMacBook1台体制にしたのでなんとか事無きを得た。

シルク・ドゥ・ソレイユ『ZED』に感動し、常設公演を続けて欲しいと願うエントリ。

※このエントリは、2011年11月13日、Twitterに連続ポストした内容を繋げて一部編集したものです。

素晴らしいショーとは裏腹な赤字事業

ZED。たまたま機会があって行って来ました。家族をおいてこっそり一人でリピートしてしまいたいレベル。舞浜エリアのクリエイティブ偏差値高過ぎワロタw

Wikiの記事に深く頷いてしまったので引用します。「演者としての人間を強調」「大道芸、サーカス、オペラとロックの要素をふんだんに取り入れ」「衣装は非常に多彩でそして創造的であり、祝祭の雰囲気を醸し出している」

あとこれに付け加えるなら舞台と照明の素晴らしさ。さらには劇場もそれを堪能できるつくりになっていて、全体として非の打ち所がありませんでした。

現在シルク・ドゥ・ソレイユのレジデントショー(常設公演)は世界4都市9公演。舞浜のZEDもそのひとつで非常に名誉なことだが、残念ながら今年末で終了。以降の予定は未定(!)ちなみに米国以外での常設公演は舞浜のほかには中国マカオのみ。

オリエンタルランドのリリースによると終了の理由はずばり「赤字」。世界有数の可処分所得と、世界ダントツNo1の都市圏人口(3500万人)を抱えて赤字とは・・・。東日本大震災の影響だそうですが。

» オリエンタルランドのリリース(PDF)

シルク・ドゥ・ソレイユ社とオリエンタルランド社のアンバランスな関係

(以下余計な詮索が続きます)事業性無しの判断に至るということは収入が減るか支出が増えるかですが、収入が減るというのはシルク・ドゥ・ソレイユの場合は主に集客減でしょう(昨日は大盛況でしたが)。広告収入、グッズ収入など副収入は集客あってのものです。

支出面では、TDRチケットとのセット売りや各種提携などによるプロモーションコストの増加が考えられます。普通はそれらコストを織り込んだ上でチケット価格を決定するわけですが、当初見込み以上にかかったのだとしたら、それも集客力の低下ということです。

そしてオリエンタルランドシルク・ドゥ・ソレイユ両者の収益配分で折り合いがつかない事態が生じたか。事業環境が変われば双方の力関係も変わります。お互いブランド力の高いコンテンツを抱えてますし、極めて下世話ながら、ありそうな話ではあります。

双方の立場にたつと少し分かる。オリエンタルランド(OLC)からするとシルク・ドゥ・ソレイユCDS)は別になくてもよい。劇場が2170席で1日2公演でも4340人。つまりTDRの圧倒的な集客の前には(残念ながら)雀の涙。

対してCDSにとってOLCの力は不可欠です。現状、舞浜なんかに劇場建設してしまったばかりにOLCに頼らざるを得ない状況だと推測されます。もしこれが都心やお台場あたりのホテルで常設公演を行なっていたら。。。勝手ながら非常に悔やまれます。

つまりはじめからOLCとCDSのタッグは不平等条約だったんじゃないのと。そう思ってWikiを見直すと、やはり常設公演のほとんどがホテル内専用劇場で開催。CDS程度の集客に吊り合うのはホテルだということです。相手がホテルならCDSも対等に交渉できそうです。

唯一米国ディズニーワールドに常設公演があるのは、舞浜と同じ構造です。どうなることやら。

シルク・ドゥ・ソレイユのレジデントショーを都心で見たい!

そろそろ締めます。来年以降まだ不透明ですが、CDSにはOLCと手を切ってもらって是非都内で常設公演を継続して欲しい!ちょうど赤プリの跡地にまた性懲りも無くホテルが建つみたいなのでそこでオケー。計画変更してでもCDSを入れたげてください。お願いします。笑

都心再開発も、昨今の再開発ラッシュとデフレ不況で大変だと推測する。知らんけど。だがCDSなら集客できる!平日2000人、休日4000人の安定集客コンテンツ。。いや、そんなことはどうでもよくって私が打ち合せ帰りに見に行くために(そしてホテルには金を落とさないw)。

最後にこんなの見つけた。読むと、震災は格好の理由扱いで「CDS at 舞浜TDR」の事業構造に問題があったのだと思わざるを得ない。10年の契約が3年で打ち切られるのは、OLC側にそういうオプションがあってそれを行使したということだと思われるが、こんなところもCDSの立場の弱さか。連投失礼しました。おしまい。

» http://ja.wikipedia.org/wiki/シルク・ドゥ・ソレイユ_シアター東京