09/02/26 23:08:16 NQkQjZmG0
IBM時代の別の上司のレイ・メイズ氏は、Cook氏は確かにあの頃の普通のIBMマンとして少し変わっていたと
いう。「IBMには古いジョークがある。」同社パソコン製造部門幹部のメイズ氏はいう。「『IBMとサボテン
はどう違うのか？ サボテンのとげは"外側"に生えてるのさ。』ティムの性格はその逆だよ。彼は一緒に働い
ている人を本当に楽しくするようなやり方を心得ていたよ。彼は誰よりも機敏で、良い意味で誰よりも積極
だった。誰よりもよく働いていた。」
クック氏は1994年にIBMを去り卸売り会社Intelligent Electoronicsのコンピューター部門に入った。1997年
にIngram Micro社に買収されるまでクック氏はそこの社長になった。それから彼はコンパックに入社した
が、1998年の始めにスティーブ・ジョブズ氏が彼を採用までの６ヶ月間いただけだった。ジョブズは新しい
採用者に自分のオフィスのすぐそばのオフィスを与えた。
今日ではそのオフィスはオーバーンの手回り品と、お気に入りの歌手であるボブ・ディランの写真で飾られ
ている。ボビー・ケネディの写真からはクック氏の別の側面をうかがうことができる。クック氏はもし彼が大
統領になっていたらどうなっていただろうと時折思い悩むことがあると語ったことがある。
「彼はあらゆる階層の人々の心に触れて交わることを知っていた。」彼のことをよく知る人によると、クック
氏は最近そう打ち明けたそうだ。「本当に国民のことが好きな人で大統領にとても近かった人々のひとり
だ。」（クック氏はノースカロライナに住んできたとき共和党員に登録していた。もっと最近ではバラック・
オバマ氏の選挙活動に募金している）
316:Tim Cook
09/02/26 23:09:45 NQkQjZmG0
クック氏はまた、ケネディー氏が「兄の影に立つことに満足して、正しい考えることを実行していた」のを尊
敬しているとも語っている。職業生活のほとんどを、人々の夢と希望を結びつけるたぐいまれな才能を持った
カリスマ指導者の影に覆い隠されている男の口からもれた、なんとも興味深いコメントである。
さてティム・クックがすごいことはわかった。しかし、本当に彼がジョブズ氏の跡を継ぐことはありえるのだ
ろうか？ そして彼じゃなかったとしたら、一体誰だろうか？
アップル社外では、詳しいものもそうでないものもいるが、多くの評論家がクック氏はアップルの次の代表に
なることはないと見ている。「だれもクックをCEOになんかしない」アップルに出入りしている、あるシリコ
ンバレーの投資家はいう。「ばかばかしい。物事を実行するだけの奴なんかいらないよ。素晴らしい製品を作
る人間が必要なんだ。ティムはそれとはちがう。彼は業務の男だ。業務なんてこの会社では外部に委託されて
いるというのに。」
アップルにマイクロプロセッサを提供していた当時Freescale SemiconductorのCEOだったミシェル マイ
アーはそれよりはもっと肯定的な見方だ。「クック氏がジョブズ氏のデザイン的な創造性の代わりになれるか
どうか確信が持てない。」マイアーはいう。「その一方で、それは次のCEOの役目ではないといういうことも
できる。」
マイアー氏はいいところを指摘している。確かにクック氏はデザインとマーケティングの分野で、誰かの助け
が必要になるだろう。履歴書に欠点や弱点のないCEOなんているだろうか。「もしも万が一ティムがアップル
のCEOになったら、彼は自分の弱点を補うことができる違うタイプの人を周りに必要とするでしょう。ちょう
どスティーブがティムで自分の弱みを埋め合わせしているように。」1998年にクック氏をアップルを斡旋し
た人材斡旋会社Heidrick & Strugglesの副議長ジョン・トンプソン氏は語る。
317:Tim Cook
09/02/26 23:12:02 NQkQjZmG0
今日はここまで。もう、だんだん早く終わらないかなという気がしてきた(笑
318:フグ田
09/02/27 01:07:28 ve+1hRmO0
Cook氏マジ乙です。
319:名称未設定
09/02/28 11:24:10 KyK6nIy40
Cook氏、ありがとう。
いつも楽しませて貰ってるよ。
320:名称未設定
09/03/08 00:11:46 pFHNky4/0
tim cookさん乙です。
321:フグ田
09/03/10 02:19:06 IcdQ0vVL0
Cook氏、どこ行ってもうたんや……。
322:名称未設定
09/03/10 12:25:45 yNrru3WLO
VIPPERが運営に喧嘩売って大量にアク禁になってるから巻き添えくってたりして…
323:フグ田
09/03/12 00:15:19 rA8GYKdy0
そろそろ2週間もたちますし次のネタをだそうかと……。
324:フグ田
09/03/14 12:52:22 2UhF7dQ70
じゃ、いきます。
325:フグ田
09/03/14 12:53:27 2UhF7dQ70
長いので数回にわけていきます。
326:フグ田＠ドテ翻訳
09/03/14 12:54:25 2UhF7dQ70
URLﾘﾝｸ(www.wired.com)
語られざるストーリー：どのようにしてiPhoneがワイヤレス産業を吹き飛ばしたのか。
By Fred Vogelstein
2008.01.09
デモはうまくいっていなかった。
まただ。
2006年秋、遅めの朝。ほぼ1年前、スティーブはAppleの約200人のトップエンジ
ニアにiPhoneの制作を命じた。ここにいたっても、Appleの会議室、プロトタイ
プは依然として最悪の状態だった。ただバギーだったのではなく、全力でまっ
たく機能していなかった。かかってきた電話はコンスタントに取りこぼし、フ
ル充電になる前にバッテリーは充電をやめてしまい、データやアプリケーショ
ンはいつも決まって止まって使えなくなってしまった。問題のリストは終わり
がないように見えた。デモが終わると、ジョブズは部屋にいる全員をじっと見
つめこう言った。「我々はまだ製品を持っていない」
その影響はジョブズのいつもの癇癪よりもさらに恐ろしいものだった。このAp
pleの代表がスタッフに怒鳴るのは怖いがいつものことだった。この時の彼が比
較的平穏だったのはさらに恐ろしかった。会議に参加していたある人物はこう
言う。「あの時はAppleで数度目の寒気を覚えたよ」
327:フグ田＠ドテ翻訳
09/03/14 12:55:21 2UhF7dQ70
影響は深刻だった。iPhoneはわずか数ヶ月後に予定されていたMacworldの最大
の呼び物になるはずだった。1997年にAppleに復帰してから、Macworldは彼の最
大の製品発表の場としていたし、Appleウォッチャーたちは新しい劇的な発表を
期待していた。ジョブズはすでにLeopard―Apple OSのニューバージョン―
の遅れを認めていた。iPhoneが間に合わなければ、Macworldは失敗に終わり、
批評家が襲いかかり、Appleの株価は傷を負うだろう。
この4.8オンスのガラスとアルミは携帯電話ビジネスを永遠に変えてしまい、キ
ャリアからパワーを奪い、製造者やデベロッパーや消費者にパワーを与える爆
破装置だ。そしてAT&Tはどう考えた？ 1年半の秘密会合の後、ジョブズはつい
にテレコムの巨人（当時はCingular）のワイヤレス部門からiPhoneのキャリア
になるための条件を取り付けた。5年間の独占契約と引き換えに、AT&Tストアで
のiPhone売り上げのざっと10％、AppleのiTunes収益のほんのわずか、AT&Tはジ
ョブズに類をみないパワーを与えた。彼はAT&Tを丸め込み、新機能「ビジュア
ルボイスメール」を開発し、時間のかかる店内サインアップシステムを再発明
させるため、数百万ドルと数千人時を支出させた。彼はさらにユニークなレベ
ニューシェア協定を説き伏せ、iPhone顧客のAT&T料金をざっとひとりあたり月
額10ドル獲得した。これらの上に、AppleはiPhoneのデザイン、製造、マーケテ
ィングの全コントロールを保持した。ジョブズは、この固定化したワイヤレス
産業の最大のプレイヤーのひとつからよい取引を絞り出すという、考えられな
いことをなしとげた。いま、最後にしなければならないことは締め切りに間に
合わせることだ。
328:フグ田＠ドテ翻訳
09/03/14 12:56:01 2UhF7dQ70
iPhoneのために働いている人々にとって，彼らのキャリアの中で、次の三ヶ月
が最もきつい時間になった。日常的に廊下で罵り合いが勃発した。徹夜のコー
ディングセッションでボロボロになったエンジニアたちは、数日後に再参加す
るためだけに、眠りを取り戻すべく休みをとった。あるプロダクトマネージャ
ーは彼女のオフィスのドアを叩き付けたために、ドアのハンドルが曲がってし
まい、部屋に閉じ込められた。同僚たちは金属バットで強打し、一時間かけて
彼女を救い出した。
しかしMacworldのわずか数週間前、奮闘は終わり、ジョブズはAT&T幹部に見せ
るためのプロトタイプを手にした。2006年12月中旬，彼はワイヤレスのボス、
スタン・シグマンにラスベガスのフォーシーズンズホテルのスイートで面会し、
iPhoneの鮮やかな画面、パワフルなWebブラウザ、魅力のあるインターフェース
を披露した。巨大電話会社に充満している保守的なエンジニアリングの伝統に
どっぷり染まっている口数の少ないテキサス人シグマンは、柄にもなく感情を
むき出しに、iPhoneを「これまで見た中で最良の製品だ」と呼んだ。（これら
の出来事の詳細はある事情通たちによってもたらされた。AppleとAT&Tはこれら
の会合や関係について話そうとしない）
329:フグ田
09/03/14 13:02:41 2UhF7dQ70
連投規制くらったのでつづきはまた。
330:フグ田＠ドテ翻訳
09/03/14 13:03:11 2UhF7dQ70
6ヶ月後の2007年7月29日にiPhoneは発売された。当初、アナリストたちは顧客
が2007年の終わりまでに300万台を先を争って買い、史上最速のスマートフォン
の売り上げになるだろうと推測した。これはほぼ間違いなくAppleのもっとも収
益の高い製品だ。Appleは399ドルのiPhone一台の販売ごとに、推測で80ドルの
利益を得る。また、iPhoneの顧客がAT&Tと二年契約をするごとに240ドルを得る。
一方で40％のiPhone購入者はAT&Tの新規顧客で、ニューヨークやサンフランシ
スコのような都会ではAT&TのデータトラフィックはiPhoneによって三倍になっ
た。
しかしAppleやAT&Tの成功と同様に重要なのは、アメリカの110億ドル携帯電話
産業の構造への根本的な影響だ。数十年間、ワイヤレスキャリアは製造メーカ
ーを農奴のように扱ってきた。ネットワークへのアクセスを影響力にして、ど
の電話が製造され、いくらの値段になり、どのような機能が搭載されるのかを
決定してきた。端末は安くて使い捨ての寄せ餌だと見なされており、契約者を
罠にかけキャリアの独占サービスを使うよう閉じ込めるために大量の奨励金が
つけられる。だが、iPhoneがこのパワーバランスをひっくり返した。たとえ高
価であっても、正しい携帯電話は顧客を獲得し、収益をあげることができると
キャリアは学びつつある。現在、Appleのような契約に追従して、すべての製造
メーカーがキャリアに認められる携帯電話ではなく、顧客に愛される携帯電話
を創りだそうと競っている。Piper Jaffrayの証券アナリストマイケル・オルソ
ンはこう語る。「iPhoneはすでにキャリアと製造メーカーの行動を変えている」
331:フグ田＠ドテ翻訳
09/03/14 13:04:12 2UhF7dQ70
2002年、最初のiPodが発売されて少し後、ジョブズは携帯電話の開発を考え始
めた。彼はアメリカ人たちが別々に携帯電話、ブラックベリーを、そして今や
MP3プレイヤーを苦労して運んでいるのに気づいた。消費者がただひとつのデバ
イスを望むのは自然なことだった。さらに、携帯電話や携帯Eメールデバイスが
さらに多くの機能を抱え込み、ついには音楽プレイヤーとしてのiPodの支配的
地位に挑むようになる将来が見えた。ジョブズは、彼の新しい製品ラインを守
るために、いつかワイヤレスの世界へ挑戦しなければならなくなると理解して
いた。
アイデアがはっきりしているのならば、問題も明らかだ。データネットワーク
は遅く、完全な携帯インターネットデバイスには不十分だった。iPhoneのため
にAppleは完全に新しいOSを創らなければならなかった。iPodのOSは複雑なネッ
トワークやグラフィックを扱うのに十分ではなかったし、OS Xのスケールダウ
ン版では携帯電話のチップには大きすぎた。Appleは強力な競合にも直面するだ
ろうとおもわれた。2003年、携帯電話とPDAとブラックベリーをひとつのおしゃ
れなパッケージにまとめあげたPalm Treo 600に消費者は群がった。この事実は
いわゆる統合デバイスに需要があることを証明し、一方でAppleのエンジニアに
とってはハードルをあげることにもなった。
そしてワイヤレスキャリアだ。ジョブズはキャリアたちが何を製造し、どのよ
うに製造するかを決定し、ハードウェアをユーザーがネットワークに接続する
ためのただの乗り物のように扱うことを理解していた。コントロールフリーク
として知られるジョブズは，連中に―のちにジョブズが「穴」とよぶ連中―
―どうデザインするかを命令させたりはしなかった。
332:フグ田＠ドテ翻訳
09/03/14 13:05:31 2UhF7dQ70
2004年までにAppleのiPodビジネスはかつてないほどより重要かつ攻撃されやす
くなっていた。iPodは同社の収益の16％を占めるが、3G携帯電話が人気を獲得
し、WIFI電話が登場間近で、ストレージの価格が急落し、競合音楽ストアが増
殖する中で、支配的音楽デバイスとしての長期的ポジションは危険にさらされ
ているように見えた。
だからこそあの夏、公式にはAppleフォンを否定する一方で、ジョブズは携帯電
話産業への参入に取り組んでいた。キャリアを出し抜くために彼はMotorolaに
近づいた。簡単な問題に見えた。この端末メーカーは広く人気を得たRAZRをす
でに発売していて、ジョブズはMotorolaの当時のCEO、エド・ザンダーをSun M
icrosystems時代から知っていた。取引の結果、MotorolaとキャリアであるCin
gularが複雑なハードウェアのディティールについて議論している間に、Apple
は音楽ソフトウェアに集中できることになった。
もちろんジョブズの考えではMotorolaはRAZRに値する後継機を製造すると見込
んでいたが、すぐにそうではないことが明らかになった。三社はほとんどあら
ゆることについて政治的取引を行った―どうやって音楽をその携帯電話に入
れるのか、どれだけの音楽が保存できるのか、そして各社の名前がどのように
表示されるのかについてさえ。そして2004年の終わりに最初のプロトタイプが
現れた時、もうひとつ問題があった。そのガジェットは醜かったのだ。
333:フグ田＠ドテ翻訳
09/03/14 13:06:28 2UhF7dQ70
2005年9月、ジョブズは彼独特の自信を持って、ROKRを発表し、こう表現した。
「あなたの携帯電話の中のiPod Shuffle」しかしジョブズは彼の手にしている
ものが失敗作だと知っていたに違いない。消費者はROKRを嫌った。ROKR―直
接音楽をダウンロードできず、たったの100曲しか保存できなかった―はすぐ
にアメリカのワイヤレス産業のすべての問題点の象徴になった。消費者のこと
を後回しにする人々の、利害の衝突と混乱の落とし子だった。Wiredは2005年1
1月号の表紙でこの失望を要約した。「これが未来の電話だっていうのか！？」
ROKRが製造ラインに入りつつあったにもかかわらず、ジョブズは彼自身の電話
を作り上げる必要があると認識し始めていた。2005年2月に彼はMotorola抜きの
パートナーシップについて話し合うためにCingularと会談した。ミッドタウン
のマンハッタンホテルで行われたトップシークレットの会合で、シグマンを含
むCingularの一握りの上級幹部に彼の計画を説明した（2006年12月にAT&TがCi
ngularを買収した際、シグマンはワイヤレス事業のトップにとどまった）。ジ
ョブズはCingularに3つのメッセージを伝えた―Appleは「他のあらゆるもの
より数光年先をいった」本当に革命的ななにかを作り上げるテクノロジーを持
っている。Appleは取引を成立させるために独占協定も考慮に入れていた。しか
しAppleはワイヤレス通信の卸売りを買って、現実のキャリアそのものになる覚
悟もしていた。
334:フグ田＠ドテ翻訳
09/03/14 13:14:57 2UhF7dQ70
ジョブズの自信には理由があった。Appleのハードウェアエンジニアは約一年を
費やしてタブレットPCのためのタッチスクリーンテクノロジーを研究しており、
電話にも似たようなインターフェースを実現できるとジョブズに確信させた。
加えて、ARM11チップのリリースのおかげで、携帯電話はついに、電話と、コン
ピュータと、iPodの機能をまとめたデバイスを動作させるのに十分なほど速く、
高効率になった。また、ワイヤレス通信はAppleが消費者に再販売するのに十分
なほど安くなった。Virginのような企業がすでにそうしているように。
シグマンと彼のチームはすぐにiPhoneのアイデアに魅了された。他のキャリア
と同様に、Cingularの戦略は消費者にWebアクセスのためにもっともっと携帯電
話を使うよう要求することだった。音声ビジネスは色あせつつあった。価格戦
争が利ざやを大幅に削減してしまっていた。約束されたように、iPhoneが音楽
やビデオをダウンロードでき、WiFiの速度でインターネットをサーフィンでき
るのなら、データ通信の顧客を大きく増やすことができる。そしてデータ通信
は音声と違って利幅が大きかった。
335:フグ田＠ドテ翻訳
09/03/14 13:15:53 2UhF7dQ70
それ以上に、Cingularのチームはワイヤレスビジネスモデルは変わらなければ
ならないと認識することができた。キャリアたちはネットワークを貴重なリソ
ースとして、端末を価値のないコモディティとして扱うことにすでに慣れてい
た。この戦略はよく機能した。安い電話の購入に奨励金を支払うことで、キャ
リアは新しい顧客により容易に加入させることができた―顧客を確かな収入
を保証する長期契約に縛り付けることができた。しかし、ワイヤレスアクセス
はもはや贅沢品ではなく、すでに必需品になっていた。キャリアにとって最大
の課題は新規顧客を見つけることではなく、他社から奪うことだった。単純に
安い端末で顧客を買収する方法はもはやうまくいかなかった。シグマンと彼の
チームは他のどのネットワークにも用意されていない、マスト・ハブ・デバイ
スを提供したかった。ジョブズ以上にだれがいい製品をつくりだせる？
Cingularにとって、Appleの野心は興味をそそると同時にイライラさせるものだ
った。iPodのメーカーとの心の通い合う関係は、会社のブランドにセックス・
アピールをもたらすだろう。そしてもしCingularがジョブズを退ければ、他の
キャリアが彼と契約するに違いない―ジョブズは彼のアイデアをきいてくれ
るなら誰でもいいと明確にしていた。だが、どんなキャリアもかつて、誰にも、
ジョブズが望んだ自由とコントロールを与えたことはなかったし、シグマンは
彼の同僚幹部や役員たちにジョブズが提案したような取引を認めるよう説得す
るのは困難だろうと理解していた。
336:名称未設定
09/03/14 14:01:58 U+rK64MPi
連投規制
337:フグ田＠ドテ翻訳
09/03/14 15:49:28 2UhF7dQ70
シグマンは正しかった。交渉は一年以上かかり、シグマンと彼のチームは何度
も多くを与えすぎているのではないかと疑問を感じた。ある時点で、ジョブズ
はVerizonの幹部たちと会ったが、彼らはすぐにジョブズを拒否した。彼らを非
難するのは難しい。何年もの間、キャリアたちは顧客と納入業者に彼らの独占
ネットワークを通してサービスを使い、販売するように仕向けていた。巨大な
コントロールをジョブズに明け渡すことで、Cingularは自慢の―そして高価
な―ネットワークを「土管（dumb pipe）」、コンテンツのソースではなくた
だのコンテンツの水道にしてしまう危険を負った。シグマンのチームはシンプ
ルな賭けをした。コンテンツ取引で失うどのような収益よりも、iPhoneはデー
タトラフィックの急増をもたらすだろう。
ジョブズは取引のよりよい点を待ったりはしなかった。2005年の感謝祭の頃、
最終合意にサインされる8ヶ月前、彼はエンジニアたちにフルスピードで働くよ
う命じた。そしてたとえCingularとの交渉が困難だったとしても、Appleが直面
していたエンジニアリングやデザインの困難に比べればシンプルだった。まず
最初にどのOSを使用するかという疑問があった。2002年以後、Appleフォンのア
イデアが最初に孵化した時、今や理論的にモバイルチップは有名なMacintosh
OSのいくつかのバージョンをサポートすることができる能力を獲得していた。
しかし劇的なストリップダウンと書き換えが必要だった。iPhone OSはたったの
数百メガバイト、ざっとOS Xの10分の1に納まる必要があった。
338:フグ田＠ドテ翻訳
09/03/14 15:50:29 2UhF7dQ70
iPhoneの設計を始める前に、ジョブズと首席幹部たちはどのようにこの問題を
解決するのか決定しなければならなかった。エンジニアたちはすでに携帯電話
での使用のために書き直されているLinuxを注意深く検討した。しかし、ジョブ
ズは他人のソフトウェアを使うことを拒否した。彼らは電話のプロトタイプを
iPod内に構築した。クリックホイールでダイヤルできたが、選択して数字をダ
イヤルすることしかできなかった―ネットをサーフィンすることはできなか
った。そして2006年の初頭、AppleのエンジニアたちはOS XをIntelチップ用に
改訂する数年間の作業を終えつつあったが、AppleはOS XのiPhoneのための書き
換え作業を始めた。
どのOSを使用するかについての話し合いは、Appleの首席幹部全員のうちの少な
くとも一人にとってはありふれたものだった。彼らは携帯電話の世界の込み入
ったことについて議論するにはあまり準備ができていなかった。たとえば、ア
ンテナの設計、高周波、そしてネットワークのシミュレーションだ。iPhoneの
小さなアンテナが十分に、たしかに機能するようにするため、Appleは数百万ド
ルを投じてロボットを使用した特別なテストルームを購入し設置した。iPhone
が必要以上の放射を生まないために、Appleは人の頭部のモデルをつくり―ネ
バネバを使って脳の密度をシミュレートした―効果を測定した。ネットワー
ク上でのiPhoneのパフォーマンスを予測するため、Appleのエンジニアはサーバ
ーサイズで一台あたり数百万ドルの無線周波数シミュレータを十数台購入した。
ジョブズはプロトタイプをポケットに入れて持ち運んでいる際に、iPodの画面
を設計した経験でさえ、iPhoneの画面の設計には役に立たないことがわかった。
傷を最小化するために、タッチスクリーンはiPodのように硬化プラスチック製
ではなく、ガラス製である必要があった。ある消息通によればAppleはざっと1
5億ドルをiPhoneのために費やしたとみられる。
339:フグ田＠ドテ翻訳
09/03/14 15:51:25 2UhF7dQ70
すべての期間、ジョブズは最高の機密性を維持した。内部ではプロジェクトは
Purple 2を略してP2と呼ばれた（廃棄されたiPodフォンがPurple 1と呼ばれた）。
チームはカリフォルニア、クパチーノのAppleキャンパス中に分断さればらまか
れた。Appleの幹部がCingularに行く時はいつも、Appleがこの電話のトランス
ミッタをつくるのに使っていた企業、Infineonの社員として登録した。iPhone
のハードウェアチームとソフトウェアチームでさえ離されていた。ハードウェ
アエンジニアは偽のソフトウェアを載せて回路を設計し、ソフトウェアエンジ
ニアは木の箱に載った基盤を使って開発した。2007年1月のMacworldでジョブズ
がiPhoneを発表した時、プロジェクトに関わっていた30人程度の上級幹部しか
現物を見たことはなかった。
ホサナ（訳注：神を賛美する言葉）、iPhoneはあまりに圧倒的で、その不完全
さを無視してしまいがちだ。599ドルという最初の値段は高すぎた（その後399
ドルに値下げされた）。こ0の電話はAT&TのしょぼいEDGEネットワークを使用し
ている。ユーザーはEメールをサーチできず、ビデオ録画もできない。ブラウザ
はJavaやFlashを使用できない。
だがそんなことは問題ではない。iPhoneはワイヤレス産業のキャリア中心の構
造をこじ開け、消費者、デベロッパー、製造メーカー―そしてあるいはキャ
リア自身にも―巨大な恩恵を解き放った。消費者は使いやすい携帯型コンピ
ュータを手に入れる。そしてPCの登場と同様に、iPhoneは開発の波の火付け役
となりつつあり、それによってiPhoneはさらにパワフルになるだろう。2月には
ジョブズはiPhoneのためにプログラムを書ける人になら誰にでも開発キットを
解放する。
340:フグ田＠ドテ翻訳
09/03/14 15:52:08 2UhF7dQ70
その一方で製造メーカーは数十年に渡ってビジネスをしてきたキャリアたちに
対して新しい交渉力を享受している。AT&Tによって顧客基盤を奪われたキャリ
アたちは先を争って競争力のあるデバイスを探しており、そのためにはいくら
かの権限を受け渡す意思があるようだ。製造メーカーは何を製造するかについ
てより強いコントロールを得ることになるだろう。ユーザー―よくあるひと
りよがりの怪物たちではない―はなにがつくられるかにより強い影響力を得
るだろう。ワイヤレスキャリアが消費者の囲い込み戦略を捨て去るサインを示
し始めていることから、アプリケーション開発者はさらなるチャンスを得るべ
く身構えている。T-MobileとSprintは、インディペンデントな開発者にとって
携帯アプリの開発が容易なOS、GoogleのAndroidのパートナーとしてサインした。
最も頑固なキャリアのひとつ、Verizonは11月にあらゆる互換性のある端末に対
してネットワークを解放すると宣言した。数日後にAT&Tも似た発表をした。最
終的にこの傾向はアプリケーションがどのデバイスでも、どのネットワークで
も動作するという、完全に新しいワイヤレスエクスペリエンスをもたらすだろ
う。やがては、ワイヤレスの世界もすこしインターネットの柔軟さと機能性を
得るだろう。
341:フグ田＠ドテ翻訳
09/03/14 15:53:11 2UhF7dQ70
ワイヤレスネットワークを土管に変えてしまう一方で、消費者、開発者、製造
メーカーにすべての力を与えてしまうというキャリアにとっての悪夢が現実の
ものとなったように見えるかもしれない。しかしさらなるイノベーションを育
てることで、キャリアのネットワークはより価値を得られるかもしれないが、
減ることはない。消費者はより多くの時間をデバイス上で、つまりはネットワ
ーク上で、消費し、より多くの請求書をため込み、全員にとってより多くの収
入を生み出している。AT&Tのマーケティング部長ポール・ロスによればAT&Tは
iPhoneの性能を引き出すような新しい製品やサービス―モバイルバンキング
のような―を探している。「市場を新しい視線で考えている」とロスはいう。
言い換えれば、ワイヤレスキャリアが長い間恐れていた、開発そのものこそが
彼らの必要としていたものだと証明されるのかもしれない。彼らはスティーブ
・ジョブズに示されるまでそれがわからなかったのだ。
342:フグ田＠ドテ翻訳
09/03/14 15:54:23 2UhF7dQ70
以上。age
343:名称未設定
09/03/14 17:47:44 XLk3ou+10
ほんとお疲れ様ですー
344:名称未設定
09/03/15 02:19:38 E1iKJo7j0
ありがとうございました。
345:名称未設定
09/03/15 02:28:33 bWyPaLrP0
乙ですた
読み応えがあったですよ
346:名称未設定
09/03/15 03:12:15 ScWkwZoXi
gj
347:名称未設定
09/03/15 08:23:25 Zv85qXPr0
いつもありがとうございます。
規制にも負けず、神業だね。
348:名称未設定
09/03/15 09:58:04 KCyQA6ur0
乙です
冒頭の部分は過去スレで読んだような気もしますが、こんなに長文だったとは。
349:名称未設定
09/03/15 10:17:38 L7oi2TUtP
乙です
すばらしい
350:名称未設定
09/03/15 10:30:02 qp1d9Prk0
あいかわらず グッジョブ です サンキュー
351:名称未設定
09/03/15 11:17:32 fKQk3YRw0
おつです
…簡単じゃなかったんだねiPhoneも
352:名称未設定
09/03/15 13:30:02 0kehl6Aj0
Newtonの二の舞にならなくて本当によかった。
353:名称未設定
09/03/15 15:38:48 ScWkwZoXi
gj
354:名称未設定
09/03/15 18:45:14 VxRwyill0
これをおねがいします
URLﾘﾝｸ(developer.apple.com)
355:名称未設定
09/03/15 18:53:35 2bths+KY0
>>354
本買うか Cocoa+リファレンス+翻訳 でググれば情報あるよ。
356:名称未設定
09/03/15 22:00:17 +Yh4u0q00
このスレ見てると、元TBSの宮内鎮雄の声が思い出されるな。
357:Tim Cook
09/03/19 14:50:04 X0sgCLk00
アク禁解けました…。フグ田さん乙でした。
358:フグ田
09/03/20 00:47:48 vPC6uNwY0
>>357
やっぱりアク禁だったんすね……。
途中でわりこんですみません。
よければつづきをぜひ。
359:名称未設定
09/03/23 02:06:51 OcKC72Iv0
>>356
URLﾘﾝｸ(jelly.jugem.cc)
360:名称未設定
09/04/12 01:13:28 DR9pzP9L0
保守とか
361:名称未設定
09/04/20 16:42:01 RxnHdwNB0
Get a Mac 新作4本翻訳キボンヌ
362:名称未設定
09/04/27 23:10:02 jDnSwQ+QP
だれか、これ、たのむ
URLﾘﾝｸ(www.smashingmagazine.com)
363:名称未設定
09/04/28 22:13:14 X/xwGXOT0
>>362
このぐらいなら辞書を引きながら自分で読みましょう。
難しい単語ほとんど無いじゃん。
364:名称未設定
09/04/29 15:37:23 hhkex6H50
>>362
英検5級の俺でもわかるぜ。
「大爆笑、破産雑誌がどっと混む2009年4月26日にデザイナーがmacにスイッチする5つの理由。」
365:名称未設定
09/05/01 23:50:45 7a5fbTH70
まブログ記事なのでsageで。
URLﾘﾝｸ(blogs.wsj.com)
ジョブズは設計屋に何をさせるのか。
去年Appleがシリコンバレーのスタートアップ企業、P.A.semiを買収してから
Appleによる半導体チップ設計への興味についての話題があった。だがそれから
多くの半導体チップ設計の優秀な人材を雇用している証拠が出てきており、
それが続いている。そこで問題だ：Appleは彼らに何をさせているのか。
CEOのジョブズの目標の一つは明快だーiPhone、iPodtouch、そして将来の製品のための
パワフルで電力効率が良いチップを作ることだ。Linkedinのサイトの中で最近Appleに
雇用されたものの投稿に拠れば、以前携帯電話のチップメーカー、Texas Instrumentsや
Qualcommなどで働いていたものが多く含まれている。Web上の求人募集や
それらのまとめサイト、indeed.comなどによるAppleの人材募集にも、ハードウェアから
ソフトウェアにまで、省電力化についての記述が多くある。定型文としては、
"iPhoneソフトウェアチームは、iPhone、iPodtouchのために野心的なバッテリー時間の目標を
実現すべく我々を助けてくれる素晴らしいエンジニアを探しています"といった具合だ。
これは驚くほどでもない。iPhoneは発売の2年前から2000万台を売り、そして厳しい競争に
直面しているため、もっとリードしたいと思っている。そしてバッテリー時間は既に
多くのiPhoneユーザの大きな問題になっている、彼らの不満はバッテリーがとても早く
なくなってしまうことであり、特にGPSを使っているときそれが顕著だ。機能の追加や拡張によって
将来負担が増えていくだけである。
他の方向性としては、最近の雇用に基づくならば、グラフィックスとビデオのための低消費電力技術の
ための設計だ、それはスマートフォンや他の製品のなかでアドバンテージを与えるかもしれない。
Appleの計画を良く知るものによればゲーム、そして映画や電子ブックのためにより大きい画面を
備えた新しいデバイスも開発しているという、それらの製品はより良いバッテリー時間で
パワフルなチップも必要になってくるだろう。
366:名称未設定
09/05/01 23:53:47 7a5fbTH70
Appleは最近自前のサイトやindeed.comの求人募集で手書き認識や、将来のカメラ技術の
調査への責任をも受け持つカメラ設計エンジニアなども募集している。最近の雇用の
履歴から判断すると、Appleは具体的なチップ製造の知識についても追加しているようで、
半導体ファウンダリとの提携の管理にも役立つことになるだろう。
またポケットサイズデバイスの省電力のモデルには普通必要とされない高いパフォーマンスの
設計やテストに関する求人の記述もある。ある半導体産業のベテランは、Appleの内部チップは
従来のコンピュータに留まらないとは考えないようにアドバイスする、
"Appleは間違いの達人だからね"と彼は言う。
秋にAppleはIBMからプロセッサのエキスパート、Mark PapermasterをiPod、iPhoneの
ハードウェアエンジニアリングチームのトップとして雇用した。IBMは非競争契約違反として
Papermasterを訴えたが、IBMと和解した後、公的に先週からAppleで働くことになった。
またAppleは去年、Ciscoシステムズで以前上級副社長でありネットワーク管理の製品の専門家で
あったCliff Meltzerをも雇っている。LinkedinでのMeltzerはCPUソフトウェアの
バイスプレジデントと書かれている。
新しい才能の雇用にかかる費用もそうだが、Appleは他企業の文化に慣れた社員をまとめるという
挑戦にも直面している。Appleでは製品に関する締切の厳守は当然のことだが、その状況を知る人に
よれば、P.A.semiのエンジニアはもっとルーズな環境で働いていたようだ。
以前P.A.semiで働いていたあるエンジニアは内部の会議で、休暇中は緊急のメールに
応える必要がない方が好みであることを述べると、Appleの経営陣は、社員は締切を守るため
何でもやってもらうということを明確にした、と会議の参加者は言う。
367:名称未設定
09/05/02 05:42:42 D2jCWqWJ0
ARMベースのベースバンドプロセサを
プロセス縮小してブロック別電力制御入れて
iPod-iPhoneラインに全展開、みたいな感じかな。
368:名称未設定
09/05/02 10:47:36 EI8wipwP0
しかしAppleは何でも自分で開発しようとしちゃう企業だよな。
こういう方法は一人勝ちか一人負けかどっちかしか無い。
369:名称未設定
09/05/02 11:52:01 fcUzAfJU0
それ、どこのソニーの話？
370:名称未設定
09/05/02 17:11:47 i7R0Sb/v0
>>368
Appleが自社の技術だけで開発したものって、何か有るだろうか。
371:名称未設定
09/05/02 22:06:22 bGX0OJel0
>>370
Apple II のハードウェア
372:名称未設定
09/05/02 23:20:01 kgJn7INj0
>>368
何でも、じゃなくて、より良い方法が自分達にできそうなら、じゃないかな最近は
373:名称未設定
09/05/03 00:25:47 ySfKw6CX0
なんでｍａｃ使ってるの？
ｽﾚﾘﾝｸ(mac板:41番)
のｽﾚで貼られてたんだけど、死んだ魚発言等についても話してるらしい
URLﾘﾝｸ(www.playboy.com)
長いので一部でもやってくれれば嬉しいです
374:名称未設定
09/05/03 00:48:45 j3xN9IWh0
>>373
よく「ジョブズは日本人のことを『海岸に打ち上げられた死んだ魚みたいだ』と言った」とかいうコピペを見たけど、
これ読むと日本のメーカーによる対米輸出のことなんだな。
日本メーカーは単なるコピーじゃなくてよりいいものを作ってくるから、こっちも革新し続けてないときついぜっつってる。
375:名称未設定
09/05/23 01:02:37 IaU4vmF50
hosyu
376:名称未設定
09/05/23 01:17:22 cmi7SWBI0
>>368
最近は内部はオープンなUNIXなのに他社ハードで動かせないOS Xとか
内部はオープンなAACやMp3なのにiTunesとしか連動できないiPodとか
内部はオープンなObjectiveCなのにAppStore経由でしか配布できないiPhoneとか
内部はオープン技術使いまくりで外部のI/Fを自社開発で縛り付けて、オープンな技術でクローズドな商品をつくる会社って感じがする。
377:名称未設定
09/05/23 01:29:41 Txlpyf+50
>>376
オープンの意味、分かって書いてる？
378:名称未設定
09/05/23 01:30:46 nAQkABSn0
もしiPhone用のアプリが自由に配布出来ていたら、発売して数ヶ月後から
iPhone用ウィルスが猛威を震ってたかもしれない。
Appleの製品使ってると、面倒くさい事に煩わされなくてホント楽ちん。
379:名称未設定
09/05/23 02:32:47 skF6BHZB0
「ビジネスとして成立するかどうかわからないけど
ともかくOSS支援しながら新しい事業戦略を考えよう」路線で
頑張っていたSunが、最後にはMySQLを手土産にして
Oracle傘下入りした悪夢のような帰結を見るに、
OSSに対するAppleの距離感や舵取りは、昔も今も順当だと思う。
380:名称未設定
09/05/23 09:37:04 cmi7SWBI0
>>378
その理屈が通るならMacOSなんて怖くて使ってられんだろう
>>379
そのOracleもOSSには熱心なんだがね
381:名称未設定
09/05/23 10:02:55 vuDQbHDH0
>>380
> そのOracleもOSSには熱心なんだがね
オラクルとオープンソース
URLﾘﾝｸ(www.oracle.com)
これ↑になんかめぼしいものある？ Zend Core for Oracleなんか
「自社のプロプライエタリ製品用モジュール出してます」だけだし、
EclipseへのコミットメントもORマッピング廻り中心で
結局自社DBとJava開発環境との親和性を確保したかったってのが主目的。
BerkeleyDBとInnoDB（MySQL）は、OSSの競合DBをで囲い込んで
Oracleのエンタープライズ市場の利権を確保したかったから買収したわけで。
先に買収したBerkeleyDBをOracleがどう扱ったかを振り返って見れば、
MySQLをどういう風にしたいのかすぐ理解できるだろ。それがわかっていて、
なお買収カードとして使わざるを得なかったSunは、これまで長年
OSSコミュニティの庇護者として振る舞いながら、事業戦略が欠如したまま
OSSサポートとしてMySQLを手元に置いたせいで、最後には
プロプライエタリ商用DBのトップベンダにOSSの最有力DBを譲り渡すという
コミュニティにとって最悪の決断をしたことになる。
といっても、これはOracleを非難しているわけではないよ。
あなたのいうOracleの「熱心」な取り組みは、明確な戦略に基づいてる。
つまりは、自社の脅威を取り除き、利益を拡大するという目的に
整合的だからこそやってる。その過程で、必要ならコードコミットも
ガンガンする。それが企業とOSSの適正で健全な距離の取り方だ、
ということが、「OSSで儲けられなかったから、最後は一番高く
売れる奴に自分ごと売り飛ばした」Sunの買収劇で明らかになったわけだ。
Appleも同じだよ。WebKitに対しても、UNIX/BSD界に対してもね。
382:名称未設定
09/05/23 10:26:26 nAQkABSn0
>>380
理屈じゃなくて単なる可能性ね。
年間300万台くらいしか売れないMacと違って、二年弱で4,000万台に達しそうな端末の
iPhone OSなんだから、ウィルス作者どもの標的にされても何の不思議もないのに、
AppStoreでダウンロードしたものしかインストール出来ない仕様が効いてると思う。
>>376みたいに、ネガティブな面しか見ないネガ厨氏ね。
383:名称未設定
09/06/20 18:14:52 rpi7n+8e0
保守
384:名称未設定
09/07/23 08:06:55 fE3kRypi0
なぜIEは開発終了したのか
最後のチームメンバーだった人が暴露（と言って
いい内容）してます。「契約が終了したから」ではないことがよく分かります。
URLﾘﾝｸ(slashdot.org)
お願いします
385:名称未設定
09/07/23 21:31:42 qZ2ivkw10
あえて全訳するほどのことでもないと思うので要約だけ。
別に暴露というほどのことはなく、よくあるビジネスの転機としか思えないけどね。
IE5が出た直後、MacIEチームはDVR boxの開発チームに配置転換され、
IEは空いている時間で取り組むことを余儀なくされた。
（完成度の高さから）Mac版のトップWebブラウザとなったことで、
フルタイムのスタッフは必要ないだろうというMicrosoftの判断からだ。
数年後、MSN for Macのベースとなることを目指したOS X専用のIE 6チームが結成されたが、
丁度その頃Appleが自社でWebブラウザを開発しているらしいことが明るみに出た。
いくつか徴候はあったが、何よりもMac IEチームにAppleが仕事のオファーを出していたからだ。
当時MicrosoftのMac BUは公式にMSN for Macにコミットしていたし、
この仕事がなくなることはないだろうと思っていたら、社内ミーティングの結論としては
Appleが自社でWebブラウザを開発するならMicrosoftとしては開発するのは割に合わないとの判断だった。
首位から圧倒的に離されたプラットフォームの、首位から圧倒的に離されたWebブラウザに注力する意味がない、と。
で上層部がAppleに確認したところWebブラウザを開発しているとの回答。
翌週ゲイツに確認後、公式にMac IEチームはシャットダウンされた。
それでもMSN for Macは開発がかなり進んでいたのでリリースしてみたが、
ユーザーの数がデベロッパーの数と同じくらいしかいなかった。
それでMac BUはOfficeに注力することになり、名実ともMac IEチームは死んだ。
後段の、筆者がMicrosoft上層部に掛け合ったくだりに関してはどうでもいいので割愛。
386:名称未設定
09/07/24 00:13:28 97Nl6q+4i
サンクス
すっきりしました
387:名称未設定
09/07/25 16:21:56 ajlgAf460
ありがとうございます～
388:名称未設定
09/08/14 08:44:19 zTQjgv3a0
保守
389:名称未設定
09/08/25 16:48:28 O3HqYPRL0
保守
390:名称未設定
09/08/27 08:02:31 SjL+bMCj0
Get a Mac 新作翻訳希望
391:名称未設定
09/08/27 08:09:46 COvOXgdK0
ほしゅ
392:名称未設定
09/08/27 17:55:53 mqZkBNyf0
>>390適当に
Surprise
Mac:こんにちはマックです
Girl:私は素敵なコンピューターを探しています
M:いいね じゃあPCだね
G:でも私大量のウイルスとか頭痛なしで動くのがいいんだけど
M:まさにＰＣ
G:本当？マックの方が安定してて安全だって・・・
M:嘘さ この世界じゃ誰も信用しちゃいけない
G:じゃあちょっと考えてくる
M:PC買いなよ
G:（退場）
P:戦いはこれからだ！
M:・・・何も言わないけど・・・
Trainer
Mac:こんにちはマックです
PC:こんにちはＰＣです
P:絶好調に戻るためにトレーナーを雇ったんだ
Trainer:黙れ！
T:PC Magはマックのカスタマーサポートが一番って言ってたぞ
T:おまえはなりたくないのか？
P:違うよ！
T:PC Worldはマックが一番信頼できると書いてるぞ
T:置いていかれてるじゃないか！
M:確かに差はあるね
T:顧客満足度がナンバーワンなんだぞ！お前は何だ！
P:僕にもいろいろいい所あるんだけど・・・
T:そうとも！
T:よくやってるぞ・・・マック
M:どうも
P:ぉぃぉぃ
393:名称未設定
09/08/27 17:56:41 mqZkBNyf0
>>390
Top of the Line
Mac:こんにちはマックです
PC:こんにちはＰＣです
Lady:私は素敵なコンピューターを探しています
P:ワオ
P:じゃあ最上級のＰＣを紹介しましょう
L:イカしてる！
L:大きな画面のコンピューターを探してるんです
Gentleman:これ以上の大きさが？
L:それにとっても速いの
G:よく速すぎって言われるよ
L:そして大量のウイルスとか頭痛なしで動くの
G:PCはみんなそういう問題はつきものさ
L:じゃ、じゃあ私マックとつき合おうかな
M:ありがとう
G:考えが変わったら電話をくれ
394:名称未設定
09/08/28 08:11:03 os4gihVq0
乙です。
395:名称未設定
09/09/02 11:24:57 PNhBMBqw0
Mac OS X 10.6 Snow Leopard: the Ars Technica review
URLﾘﾝｸ(arstechnica.com)
この記事の翻訳をお願いします。アップルのサイトや、
IT系サイトのレビューに書かれていない部分があれば。
396:名称未設定
09/09/02 13:42:57 Ap9yN7Ot0
>>395
Mac OS X 10.6、別名 Snow Leopard がリリースされました。
今回、アップルは内部構造を大幅に見直し、美しく軽く仕上がっているようです。
何が新しいのか、何が変わっていないのか、そして、アップグレードする価値があるのかどうかを John Siracusa がアップルの新しい OS に深く読み解きます。
============================
以下、めんどくさいのでこちらをどうぞ。
============================
URLﾘﾝｸ(translate.livedoor.jp)
URLﾘﾝｸ(www.excite-webtl.jp)
URLﾘﾝｸ(honyaku-result.nifty.com)
397:名称未設定
09/09/02 17:16:26 Tsugb4sE0
>>395
・拡張属性に圧縮した実行ファイルを入れることができるように
・Objective-C 2.0がそうだったようにObjective-C 2.1でもランタイムの
一番おいしい所は64bitでないと使えない
・QT7->QT XはOS 9->OS Xのようなもの．過去を決別しつつ徐々に移行する
・アプリがBookmarkという概念でファイル管理をできるようになった
・LLVMへの投資でコンパイラのフロントエンドにClangが選択可能になり
構文解析が高度に，エラー特定が容易く
・GDCなどで使われるblockはMacに付属のどのコンパイラでもビルド可
・GDCはキュー一つあたり256byteしか使わないので経済的
・OpenCLはベクトル演算をそのまま書ける
・解像度非依存はかなり近づいて来ているがまだまだ
・ZFS対応になればTime Machineが効率的になるのにAppleはSnow Leopardでは
やる気はない
398:名称未設定
09/09/02 17:39:50 U9WN/FCo0
>>397
> ・拡張属性に圧縮した実行ファイルを入れることができるように
> ・Objective-C 2.0がそうだったようにObjective-C 2.1でもランタイムの
> 一番おいしい所は64bitでないと使えない
> ・QT7->QT XはOS 9->OS Xのようなもの．過去を決別しつつ徐々に移行する
> ・アプリがBookmarkという概念でファイル管理をできるようになった
> ・LLVMへの投資でコンパイラのフロントエンドにClangが選択可能になり
> 構文解析が高度に，エラー特定が容易く
> ・GDCなどで使われるblockはMacに付属のどのコンパイラでもビルド可
> ・GDCはキュー一つあたり256byteしか使わないので経済的
> ・OpenCLはベクトル演算をそのまま書ける
> ・解像度非依存はかなり近づいて来ているがまだまだ
> ・ZFS対応になればTime Machineが効率的になるのにAppleはSnow Leopardでは
> やる気はない
さっき半分まで読んだが、適切なまとめだ
399:名称未設定
09/09/02 20:34:39 PNhBMBqw0
>>397
乙です。
ありがとう。
400:名称未設定
09/09/02 20:51:03 nYTGztxh0
>>397
>・拡張属性に圧縮した実行ファイルを入れることができるように
リソースフォークにも入れます。
>・アプリがBookmarkという概念でファイル管理をできるようになった
BookmarkというのはAliasをCoreFoundationに移植したもの
401:名称未設定
09/09/02 21:59:48 zV6c89fL0
移植っつーかあらゆるファイル指定子をNS/CFURLに統合した感じ
402:偽の神
09/09/02 23:53:03 6CUq60rj0
>>395
一番面白そうなところを翻訳しました。しかし分量が多すぎる。
URLﾘﾝｸ(arstechnica.com)
インストール
Apple によると、Snow Leopardのインストールは「最大45%」高速になったそうだ。
インストール時間は、速度、内容物、ディスクの断片化の程度、光学ドライブの速度などによって大きく変わる。
インストールというのは一度きりで、恐ろしい事態が起きない限りは特に面白くもない。
ま、Appleがそういうなら、確認する価値がある。
条件をできるだけ同じにするべく、私はLeopardとSnow Leopardの両方をインストールした。
光学ドライブからのランダムなデータアクセスを抑えるため、Snow Leopardの最も重要なインストール最適化のいくつかを無効にしている。
不利な条件にも関わらず、Snow LeopardのインストールはLeopardのそれよりも20%ほど短い時間ですんだ。
Appleのいう「最大45%」には届かなかった（最大、という枕詞を忘れずに）。どちらも、インストールは30分以下だった。
Snow Leopardで驚くのは、Spotlightのインデックス作成が非常に速く完了することだ。
私のテストでは、Snow Leopardは174%も高速だった。5:49 に対して 3:20。
さらに、空のディスクへの新規インストールは標準ではない。
しかし、Spotlightのインデックス作成の待ち時間が短くなったのはいい。
Snow Leopardのパフォーマンスを実感できる最初の体験だ。
403:偽の神
09/09/02 23:53:43 6CUq60rj0
ほかに特筆すべき点として、デフォルトではインストールされないものについてだ。
例えばRosettaは、IntelMacでPowerPCのバイナリを動作可能にする。
オーケーわかった、 PowerPCはもう死んだ。安らかに眠れ。カーテンを引いて天に召されよ。
Appleに限っていえば、PowerPCは蚊帳の外だ。
しかし、デフォルトでRosettaをインストールしない？ キツい表現をするとこれは無謀と言える。
Snow Leopardにアップグレードした後に、長い間放置していたPowerPCアプリケーションを起動したらどうなるだろうか？
驚くと思うが、こうなる：
（スクリーンショット）
Rosetta：自動インストールされる
Disk Inventory X を Snow Leopardで起動しようとした時にこれが現れた。
PowerPCアプリケーションだというのを忘れていたのだ。
「インストール」ボタンをクリックした後、インストールDVDを要求されるだろうと思っていた。
代わりに、Snow Leopardはネットワークに接続し、AppleのサーバからRosettaをダウンロードしてインストールしたのだ。
（スクリーンショット）
Rosetta 自動インストール
Macの再起動も要求されず、 Disk Inventory X はRosettaのインストール完了後にそのまま起動した。
Mac OS X は今までシステムソフトウァアのオンデマンドインストールをあまり使ってこなかったが、Rosettaに関する便宜はとても好ましい。
「インストール」をクリックすると、Mac OS Xに適用可能なソフトを列記した巨大なXMLプロパティリストがダウンロードされる。
Snow Leopard は同様にプリンタードライバもオンデマンドでダウンロード・インストールしてくれる。
インストールDVDを持ち出す手間が省ける。将来はこの技術がもっと広く使われるとありがたい。
404:偽の神
09/09/02 23:55:09 6CUq60rj0
インストールのサイズ
Snow Leopardはディスクを節約する。
Appleは「前のバージョンよりもサイズを半分近く減らした」と言っているが、これは嘘ではない。
クリーンなデフォルトインストール（Spotlightのインデックスも含む）でいうと、Leopardが16.8GBで、Snow Leopardは5.9GBだ。
（ちなみに、この数字はどちらも2進法で計っている。サイドバーをみてね）
ギガバイトの、ほかの名前
Snow Leopard は、ディスクの使用率について上げ底的なトリックを使っている。
Snow LeopardのFinderは1GBを109バイト（10億）としているが、
LeopardのFinder、いや、従来のすべてのFinderは1GBを230バイト（10億7374万1824）としているのだ。
Snow Leopardをインストールした後は、ディスクの容量が突然増えたように見える。
たとえば、私の1TBのハードディスクをLeopardのFinderでみると、931.19 GBと表示される。
Snow Leopardでは、999.86 GBだ。ハードディクのメーカーは、10進法を使っている。
まったく混乱させてくれる。
私は2進法に拘っているとしても、長らく定着していたハードディスクメーカーの表記ルールにAppleが合わせたことを強く非難はできない。
Snow Leopard の減量にはいくつか秘密がある。
ひとつは明らかだ：PowerPCのサポートが無くなったということは、PowerPCの実行コードも無いということ。
Leopard で実行コードをフルに載むと？ 32ビットPowerPC、64ビットPowerPC、 x86、そしてx86_64。
これらアーキテクチャの半分がカットされた。
とはいえ、Leopardでは64ビットのコードを持つアプリケーションはほとんどなかったが。
しかし50%の実行コードの削減は単純に効く。
405:偽の神
09/09/02 23:57:32 6CUq60rj0
もちろん、OSの全ファイルが実行コードという訳ではない。
データファイル、イメージ、オーディオ、ビデオ。
しかし実行コードでないファイルのほとんどに共通することがある：それらはたいてい、圧縮されたファイルフォーマットで保管されている。
PNGs、JPEG、AAC、MPEG-4、そして設定ファイルやプロパティリストは、XMLよりもコンパクトなバイナリ形式がデフォルトになった。
Snow Leopardの圧縮分野では、これらとは別種のファイルが頭角を現している。
ひとつ例を見せよう。Snow Leopardでは、内在する実行ファイルのうち97%が圧縮されているのだ。
どうやって？ これを見てくれ：
% cd Applications/Mail.app/Contents/MacOS
% ls -l Mail
-rwxr-xr-x@ 1 root wheel 0 Jun 18 19:35 Mail
（訳者注：ファイルサイズが0KBとなっている）
え？ ちょ、おま…小さいってレベルじゃねーぞ？ マジで実行ファイルか？ 別の何かか？ 確認しよう。
% file Applications/Mail.app/Contents/MacOS/Mail
Applications/Mail.app/Contents/MacOS/Mail: empty
（訳者注：empty表示に注目）
キター！ 消えてるwww
種明かしをすると、この結果はLeopardからSnow Leopardのディスクを見た時のものだ。
実際、以前のMac OS Xからでは、Snow Leopardで圧縮されているファイルは0バイトに見えてしまう。
（もちろん、Snow Leopardで起動していると、ちゃんと見える）
406:偽の神
09/09/02 23:58:34 6CUq60rj0
じゃ、データはどこに？
上記の出力にある、アクセス権を表す文字列の末尾についた「@」（Leopardで登場した機能）がヒントだ。
Mailの実行ファイルはサイズ0だが、それはいくつかの拡張アトリビュートを持っている：
% xattr -l Applications/Mail.app/Contents/MacOS/Mail
com.apple.ResourceFork:
0000 00 00 01 00 00 2C F5 F2 00 2C F4 F2 00 00 00 32 .....,...,.....2
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
(184,159 lines snipped)
2CF610 63 6D 70 66 00 00 00 0A 00 01 FF FF 00 00 00 00 cmpf............
2CF620 00 00 00 00 ....
com.apple.decmpfs:
0000 66 70 6D 63 04 00 00 00 A0 82 72 00 00 00 00 00 fpmc......r.....
ふぅ、これが全データだ。でも待てよ、リソースフォークに格納されてるの？
8年ほど前、それは推奨しないってことにしたよね？
確かにそう。あなたは、Appleが愛する自慢のファイルシステム、HFS+の追加機能の目撃者になる。
Mac OS Xのあけぼのに、Appleはジャーナリング、シンボリックリンク、ハードリンクを追加した。
Tigerでは、拡張アトリビュートとAccess Control Listを組み込んだ。
Leopardでは、HFS+ はディレクトリのハードリンクをサポートした。
Snow Leopardでは、HFS+ は新しい技を覚えた：per-file compression（ファイル単位の圧縮）。
com.apple.decmpfs アトリビュートの存在が、そのファイルが圧縮されているという最初のヒント。
このアトリビュートは、実際にはSnow Leopardが起動した時にxattrコマンドから見えないようにされる。
しかし、この特別なアトリビュートを解釈しないLeopardからは、丸見えだ。
407:偽の神
09/09/03 00:00:10 6CUq60rj0
Mac OS X 内部をよく知る導師、Amit Singh による hfsdebug。
これのSnow Leopard対応版を使えばより多くの情報が明らかになる。
% hfsdebug /Applications/Mail.app/Contents/MacOS/Mail
...
compression magic = cmpf
compression type = 4 (resource fork has compressed data)
uncompressed size = 7500336 bytes
見ての通り、リソースフォークは確かに圧縮データを保持している。
しかし、なぜリソースフォークなのか？ Appleのいつもの、後方互換性のための賢いやり方だ。
最近の例としては、ディレクトリのハードリンクの見せ方が挙がる。
Leopard以前のバージョンでは、エイリアスに見えるようになっているやつ。
HFS+ の圧縮は過去のシステムには存在していないため、
Snow Leopard以前のシステムでは圧縮データの読み出しや解釈ができないようにしてある。
10.6以前のシステムで稼働しているアプリケーション（またはユーザ）が、圧縮されたファイルを不用意に弄ってしまわないよう、圧縮データを見えないようにしたのだ。
そのような方法で隠されている、もしかすると巨大なファイルを、Snow Leopard以前のシステムは正しくコピーできるのだろうか？
これこそ、リソースフォークを使う理由だ。
ファイルを移動したりコピーしたりする際、FinderはMac固有のメタデータとリソースフォークを正しく扱ってくれる。
Leopardでは、cpとrsyncも同じ動作をしてくれる。
以前のOSからSnow Leopardのディスクを見ると、空っぽで0KBのへんてこなファイルに見えるが、コピーや移動を行ってもデータを失う可能性は低い。
408:偽の神
09/09/03 00:01:37 6CUq60rj0
Appleが圧縮データをこっそり運ぶと決めた場所は、リソースフォークだけではない。
より小さなファイルについて、hfsdebugを使うと：
% hfsdebug /etc/asl.conf
...
compression magic = cmpf
compression type = 3 (xattr has compressed data)
uncompressed size = 860 bytes
この例では、（圧縮してはいるが）拡張アトリビュートにすっぽり格納できるほどデータが小さい。
そして、これが最後のフロンティア：
% hfsdebug /Volumes/Snow Time/Applications/Mail.app/Contents/PkgInfo
...
compression magic = cmpf
compression type = 3 (xattr has inline data)
uncompressed size = 8 bytes
うんうん、拡張アトリビュートに非圧縮なファイルがまるごと格納されているね。
ここで見ているような標準的なPkgInfoファイルは、Classic Mac OS由来のタイプコードとクリエイターコード（各4バイト）を保持しているだけだ。
% xattr -l Applications/Mail.app/Contents/PkgInfo
com.apple.decmpfs:
0000 66 70 6D 63 03 00 00 00 08 00 00 00 00 00 00 00 fpmc............
0010 FF 41 50 50 4C 65 6D 61 6C .APPLemal
「fpmc...」宣言は、この記事の上の方にある com.apple.decmpfs アトリビュートにも出ていたが、数値の末尾に、予想通りのデータが見えている：
タイプコード「APPL」とクリエイターコード「emal」（Mail.app用 - Classic MacOSの伝統どおりの可愛らしさ）。
409:偽の神
09/09/03 00:02:57 cgwMuRiu0
あなたは不思議に思うことだろう。
これがデータ圧縮のすべてだとしたら、8バイトの非圧縮データ + 17バイトの宣言文字列を拡張アトリビュートに格納することが、ディスクスペースをどのぐらい節約するのか？
HFS+がディスク領域を割り当てる方式に、その答えがある。
データフォークあるいはリソースフォークに情報を格納する際、HFS+は複数のアロケーションブロック（デフォルトでは1ブロックあたり4KB）を確保する。
従来の方法では、8バイトを格納するのに最低4096バイトの領域を占有することになる。
拡張アトリビュート用にディスクスペースが割り当てられるときは、このアロケーションブロックのサイズが関与しないのだ；データはもっとタイトに格納される。
結果的に、これら25バイトのデータを拡張アトリビュートに格納することで、4000バイト以上を節約できる。
しかし、圧縮はディスクスペースを節約するだけではない。
I/Oの遅延や帯域の低下によるCPUの動作待ちは、伝統的なテーマだ。
過去数十年間、CPUのパフォーマンスは向上し続けていて、（そしてコンピュータのリソースは有り余るようになった - 最近は特に）それはディスクのパフォーマンス向上にくらべてはるかに大きい。
現代のハードディスクのシークタイムや回転待ちの遅延は、ミリセカンドのクラスにとどまっている。
1ミリセカンドあれば、2GHzのCPUは200万回サイクルをまわせる。
そしてもちろん、実データの転送時間も無視できない。
ところで、OSやハードウェアによる複数段のキャッシュ技術はこれらの遅延をがんばって隠蔽してくれている。
しかしキャッシュが満杯になってしまえば、ディスクに落とし込まねばならない。
圧縮すれば、転送するべきデータ自体が減る。
現在のマルチコアなMacでは、普通の使い方だとCPUのリソースが笑ってしまうぐらい余っている。
ディスクから圧縮データを転送してCPUがメモリに展開する作業、この総時間は、非圧縮データを転送する時間よりも短いのだ。
410:偽の神
09/09/03 00:06:07 6CUq60rj0
転送データ量を減らすことのメリットについて説明したが、ファイルを拡張アトリビュートに格納すると実際に高速化できる。
データの局在性がそれだ。
大きなデータを転送するのにハードディスクが低速になるのは、ハードディスクのヘッドがディスクの別の場所に移動するからだ。
ヘッドの移動開始、停止、狙った場所に正しく静止、ディスクの回転待ち…ヘッド移動のたびにこれらの時間がかかる。
物理的な部品が高速かつ的確に踊る様は驚きだが、限界がある。
一連の動作は、ハードディスクのような回転ストレージにとってはパフォーマンス殺しだ。
HFS+ ボリュームはファイル - メタデータ - のついての全情報をディスクの2つの優先領域に格納する：
カタログファイルには、ファイル情報、アクセス権、所有権、その他諸々など。
アトリビュートファイルには、「named fork」。
HFS+の拡張アトリビュートは、アトリビュートファイル内の named fork という形で提供されている。
ただし、領域を大きく確保できる（ファイルシステムがサポートする上限まで可能）リソースフォークと異なり、HFS+の拡張アトリビュートはアトリビュートファイルに「インラインで」格納される。
そのため、アトリビュートごとの上限は約128バイトになる。
しかし、実データを読み出すのに、ディスクの別の場所にヘッドを移動させなくてもいいわけだ。
ご想像の通り、カタログファイルとアトリビュートファイルがあるディスク領域は頻繁にアクセスされるため、キャッシュされている可能性が高い。
メタデータとデータ本体の両方を含むファイルの格納を、B-tree構造化されているカタログファイルとアトリビュートファイルで完結させるという狙いにより、全体的なパフォーマンスの向上に成功している。
8バイトの領域を25バイトに膨らませていることについてだが、それがデータストレージのアロケーションブロックサイズよりも小さく、また、OSが読み出すべきアトリビュートファイルのB-treeノードに丸ごと格納されているうちは、心配無用だ。
Snow Leopardのディスクスペース節約に大きく貢献している要素は他にもある（例えば、不必要な言語リソースや"designable.nib"ファイルの除去）。
しかしHFS+の圧縮は、技術的に非常に興味をそそられるものだ。
411:偽の神
09/09/03 00:07:10 6CUq60rj0
インストーラの知性
Appleは、インストールプロセスに二つの興味深い仕掛けを施してきた：
Snow Leopardはあなたのアプリケーションの互換性を確認し、非互換であることが確認されているプログラムをインストール対象から外す。
また、インストールが強制停止された場合でも、データを失うことなしに再開できる。
「非互換であることが確認済」のアプリケーションを除外する。
これは間違いなく、2年前にTigerからLeopardにアップグレードしたユーザの一部に起こった「ブルースクリーン」問題への回答だ。
これは非互換性 - 「許可されていない」サードパーティのシステム拡張 (extensions) が引き起こした。
私はこのような手段を実利的なスタンスで見ることにしている。
Appleが、ユーザへの影響を最小限にする現実的なアプローチをとったことを好ましく思う。
もちろん、非互換かもしれないソフトウェアすべてを検知して無効にするのは無理な相談だろう。
最も人気がある、または最も評判がよいリスキーなソフトウェアを検知するのではないだろうか。
あなたが開発者なら、自身のソフトがAppleのブラックリストに載っているかどうか確認するのに便利だ。
インストールの再開機能についてだが、電源トラブルの後でインストールを継続する時、私はこの機能をテストする気力を失っていた。（UPSは持ってる）
インストールのような長時間のプロセスのことを考えると、この手の堅牢性は歓迎だ。とくにラップトップのようなバッテリー駆動のマシンにとっては。
インストールプロセスのこういった改良の背景には、Appleの開発者がOSの各要素を洗練させることに時間をかけたことがある。
インストーラのチームは2年近くの開発サイクルの間、インストーラを満足なものにするというプレッシャーを受けていたのだろう。
そのへんの実状はわからないが、ユーザーはその成果を受け取ることができた。
412:偽の神
09/09/03 00:12:36 cgwMuRiu0
以上です。
実際投稿してみると、分量はそれほどでもなかった…
413:名称未設定
09/09/03 00:16:10 5NUHZWFg0
乙！ 原文の内容も翻訳もナイスだ。
414:名称未設定
09/09/03 00:29:59 /YRICS550
とても面白かったです！
一応、気付いちゃったので僭越ながらも訂正しまする
>>404
109バイト（10億） → 10の9乗（10億）バイト
230バイト（10億7374万1824） → 2の30乗（10億7374万1824）バイト
415:名称未設定
09/09/03 01:40:08 7bPBbvIC0
Blockについての説明も非プログラマーにもわかりやすくて面白かった。
「Cプログラマーたちよ、ようこそ、高階関数の世界へ」。
416:名称未設定
09/09/03 02:02:21 iM87nQgP0
ためになりますた
417:名称未設定
09/09/03 03:13:56 9fcG1i030
>>412
いつもありがとうございます。
じっくり読ませていただきます。
418:名称未設定
09/09/03 22:11:53 jmKMK3mQ0
ありがとう
419:名称未設定
09/09/03 23:26:38 noj8b/tz0
GJ!
420:偽の神
09/09/04 00:19:04 3ES14wfI0
>>395
続いて、Grand Central Dispatchの概要です。
こういう記事の翻訳はスレッドプールとかに詳しい人がやればいいと思いました…
意味がつかめてない箇所があるので、その辺は流してください。
URLﾘﾝｸ(arstechnica.com)
Grand Central Dispatch
並行処理という難問に対するSnow Leopardの答え、それがGrand Central Dispatch (GCD)だ。
QuickTime Xと同じくキャッチーな名前だが、技術を理解しない限りは不明瞭なままだ。
まず、GCDはCocoaの新フレームワークでもないし、特定の用途にのみ発揮される補助技術といったものでもない。
Mac OS Xの下層に焼き込まれたプレーンなCライブラリだ。
（libcに組み込まれていて、ユーザー空間の深層に置かれているlibsystem。その中に。）
あなたのプログラムでGCDを使う時に、新たなライブラリにリンクする必要はない。
ただ単に、#include <dispatch/dispatch.h> すれば即座に動く。
GCDはCライブラリだから、Cを呼び出せる言語ならどれでも使える：Objective-C、C++、Objective-C++ 。
421:偽の神
09/09/04 00:19:52 3ES14wfI0
キューとスレッド
GCDはいくつかのシンプルな要素からなっている。まずキュー（待機列）から始めよう。
GCDにおけるキューとは、そのままの意味だ。タスクはキュー（待機列）の形にされて、FIFO（先着順）で処理されていく。
(First In, First Out の略で、スーパーのレジの列のごとく、列に並んだ順に処理されていく） タスクが振り出されるというのは、タスクがスレッドに割り振られて実際に実行されるということ。
GCDのキューはFIFO（先着順）でタスクをスレッドに割り振っていき、同じキューから発行された様々なタスクが常に並列で実行される。
動画を用意した。
Grand Central Dispatchの、キューの動作
Click to Play
A Grand Central Dispatch queue in action
タスクBが、タスクAより先に完了していることに気づいただろうか。
キューからの振り出しはFIFO（先着順）だが、タスクの完了はそうではない。
また、3つのタスクがキュー化されているが、スレッドは2つしか使われていない。
これがGCDの重要なところだ。
しかしまず、キューの別の面も見てみよう。
永続キューも通常のキューと同じように動作し、同時に複数のタスクが実行されるようになっている。
つまり、永続キューでのタスク完了もまたFIFO（先着順）となる。
永続キューは通常のキューと同じく明示的に生成される。
ただし、各アプリケーションがそれぞれに、メインスレッドで実行されている永続キュー、すなわち「メインキュー」を持っている。
上の動画では、動作していたスレッドが、不必要になると消えていることを見せてくれる。
これらのスレッドはどこから生じ、どこへ行くのだろうか？
GCDは、スレッドのプール（貯水池）を一元管理している。
キューが振り出すタスクがなくなると、スレッドはプールに戻される。
422:偽の神
09/09/04 00:20:40 3ES14wfI0
これはGCDの設計における、極めて重要な側面だ。
驚かれるだろうが、伝統的な手作業管理のスレッドを使ってパフォーマンスを限界まで引き出す時、「いくつスレッドを作るか」というのはかなりの難問なのだ。
少なすぎると、ハードウェアがアイドル状態になってしまう。
多すぎると、使用可能なCPUコアにスレッドを割り振るようなことですら時間を食うようになる。
仕事を、8つの独立した単位に分けるという問題を挙げてみよう。
このソフトが、8コアのマシンで4つのスレッドを生成したなら、スレッド数は多すぎるのか、少なすぎるのか？
これは引っかけ問題！ システムの状態によって答えが異なってくる。
8コアのうち6個が他の仕事で手一杯だとすると、コアの空きは2つ。
そこに4スレッドを生成すると時間を浪費してしまう。
ちょい待ち、6コアを占有しているその仕事が終わったらどうなる？
そうなれば空きは8個だ、しかしスレッドは4つ。コアの半分がアイドル状態になってしまう。
プログラムを実行する時はハードウェアのすべてを使いたいものだが、いくつのスレッドを作るのが正解なのか、プログラマーが知る術はない。
このマシンでコアはいくつ使えるのか？塞がっているコアはいくつなのか？
途中でコアに空きができたとき、プログラムがそれを知るにはどうすれば？
スレッドの最適数については、単一のグローバルな存在が最終決定をくだす。Snow Leopardでは、それはGCDのことだ。
タスクを持つキューが無い時は、プール内のスレッドはゼロのまま。
タスクがキューから振り出されると、GCDは利用可能なハードウェアに応じて複数のスレッドを生成する。
GCDは、システムが持つコアの数や、現在稼働しているスレッドの数を把握している。
キューがスレッドを必要としなくなれば、それらはプールに戻され、タスクを抱えた別のキューにあてがうことができる。
423:偽の神
09/09/04 00:22:04 3ES14wfI0
これは実に最適な企てだ。
Mac OS Xでは、スレッドは比較的に"重い"。
各スレッドはレジスタ値、スタックポインタ、プログラムカウンター、加えてセキュリティの信用性を追跡するカーネルデータ構造、スケジューリングの優先度、保留シグナルとシグナルマスク等々…を管理している。
総計するとスレッドあたり512KB以上のコストがかかる。
各スレッドが持つ実データもあるのだが、それ以前に、1000個のスレッドを生成するとそれだけで500MBものメモリおよびカーネルリソースがコストとしてのしかかってくるわけだ。
スレッドあたり512KBのお荷物と比較すると、GCDのキューはほんの256バイトのコストで済む。
キューは非常に軽く、開発者がキューを大量に用意してもOKだ。
先の動画では、キューが3つのタスクを2つのスレッドに割り振る時、1つのスレッドが2つのタスクを実行した。
スレッドの重さはメモリ量だけではない。スレッドを生成することもまたコストがかかる。
各タスクごとに新しいスレッドを生成するのは最悪のシナリオだ。
GCDは複数のタスクを実行するのに、常時スレッドを使うことができる。これがシステム全体の効率向上を勝ち取った。
プログラマーがスレッドの数を決定する時の問題を覚えているだろうか？
GCDを使えば、まったく気にしなくてもよくなる。
代わりに、理屈では、プログラマーはアルゴリズムの並列性を最良にすることに集中できるようになる。
500の並列タスクを使うのがベストならば、500のGCDキューを用意して仕事をキューに投げ込めばいい。
GCDは、仕事を実行するのにいくつスレッドを生成するのか算定する。
そのうえ、システムの状態変化を考慮して、スレッドの数を動的に調整してくれる。
しかし恐らく最も重要なのは、より多くのCPUコアを持つマシンが出てきても、プログラマーがアプリケーションを変更する必要がまったくないことだ。
ありがとうGCD。意識しなくてもコンピュータの利用可能なリソースをすべて使えるのだ、文字通り最適に！
- 大本の最適な並列作業数は、キューの用意数を決める時にプログラマーによって定義される。
424:偽の神
09/09/04 00:25:13 3ES14wfI0
ちょっと待った、まだある！
GCDキューは、自動判断で複雑に導かれた非循環式のグラフによって、並び替えが行われる。
（実際には、循環式にもできるのだが、そのときの振る舞いは定義されていない。やらないように）
キューの階層化は、中央管理キューの下位セットに内包されたサブシステムからのタスクを流し込んだり、効果的に配列された永続キューを通常キューとして強制セットしたりするのに使われている。
また、キューについては何段階かの優先度が存在し、スレッドに割り振る時の頻度や緊急度を決定する。
キューは一時停止、再開、キャンセルが可能になっている。
キューはグループ化することもができ、グループから発行された全タスクを追跡したり、全タスクをひとつの単位として扱ったりできる。
まとめ。
GCDのキューとスレッドの使用形態はシンプルで、エレガントで、それでいて非常に実用的なアーキテクチャだということだ。
425:偽の神
09/09/04 00:30:00 3ES14wfI0
以上です。
当該ページにある動画を見るのが、一番理解が早いような。
「自動判断で複雑に導かれた非循環式のグラフ」って、Directed acyclic graphのことでした。
WikipediaでDirected acyclic graphを調べると、わかりやすい図が載っています。
426:名称未設定
09/09/04 00:43:43 9HHITkfT0
乙です！
日本語だと非循環有向グラフって言いますね。
427:名称未設定
09/09/04 00:44:52 9HHITkfT0
乙です！
日本語だと非循環有向グラフって言いますね。
428:名称未設定
09/09/04 02:24:42 QE/kFTDt0
第二弾きたーーーーーーーーーーーーーー
お疲れ様です＾＾
429:名称未設定
09/09/04 11:36:49 5BjWoHev0
>>420
> GCDはCライブラリだから、Cを呼び出せる言語ならどれでも使える：Objective-C、C++、Objective-C++ 。
これって微妙だよね。Appleのドキュメントにもこう書いてる所があるけど、
逆にC++では使えないってかいてるドキュメントもあるし。
430:名称未設定
09/09/04 11:54:53 9HHITkfT0
>>429
> > GCDはCライブラリだから、Cを呼び出せる言語ならどれでも使える：Objective-C、C++、Objective-C++ 。
> これって微妙だよね。Appleのドキュメントにもこう書いてる所があるけど、
> 逆にC++では使えないってかいてるドキュメントもあるし。
Clang+LLVMはまだC++未整備だけど、GCDは対応しているように読めたよ。
431:名称未設定
09/09/04 12:10:12 ThyJMHMO0
URLﾘﾝｸ(www.apple.com)
ここにAppleのTVCMがあるんだけど、これ字幕ほしい。
英語のまま見ててもなんとなく、
とても面白い雰囲気が伝わっては来るんだけど、
やっぱ日本語字幕が欲しいなぁ。
432:名称未設定
09/09/04 21:31:10 bA72lOgm0
>>425
乙です。
ありがとう。
433:偽の神
09/09/05 20:58:11 vWN40Vil0
>>395
さて、次はQuickTime Xについて。
URLﾘﾝｸ(arstechnica.com)
QuickTime X
Appleは、LeopardでCベースのQuickTime APIを64ビット化しなかったが、その時ちょっと変なことをした。
同時に、それはとても大きな取引に見えた。
Mac OS Xにおける64ビットへの移行は、既に何年も、いくつかのメジャーアップデートにまたがっている。
QuickTimeがまだ64ビットになっていないことが想像される。
結局、私の簡潔だが悲観的な評価は正しかった：QuickTimeは「Carbon依存」だった。
カーボンのような、由緒あるQuickTime APIが64ビットになることは、永遠にない。
QuickTimeテクノロジーとQuickTimeブランドは確実に64ビットに対応する。
32ビットのみの要素の背後にあるのは、1991年に登場してから18年間使われ続けたCベースのAPIだ。
それはSnow Leopardで64ビットに置きかえられ、QuickTime Xと名付けられた。
QuickTime Xの「X」は、「テン」と発音する。
これは、多くの不気味な相似の手始めにすぎない。以前のMac OS Xのように、QuickTime Xは：
* 旧QuickTimeからの決別を狙っている
* もともと他のプラットフォーム用に開発された技術がベース
* 前バージョンとの透過的な互換性を持つ
* よりよいパフォーマンス、より現代的なアーキテクチャ
* 初リリース時には、重要な機能の多くが欠落している
一気に見ていこう。まず、なぜ過去からの決別が必要なのか？ それは単純に、QuickTimeは古い - 本当に古いから。
1991年の初リリース時に表示された郵便の消印サイズのビデオは、技術の偉業と思われた。
434:偽の神
09/09/05 20:59:02 vWN40Vil0
当時、最速のMacintoshは25MHzのCPUを積んでいた。
右のふざけたグラフが雄弁に物語る。
これまでは、前向きな姿勢だけでよかった。
技術が誕生したときの状況が、最終的に、必然的に、技術の運命を決定する。
これはQuickTimeのような、後方互換性を強く求められる長命なAPIには特に真実味がある。
パーソナルコンピュータでのビデオ内蔵を成功させたQuickTimeが、ここまで長続きしたのは率直にいってすばらしいことだ。
しかし世界は変わる。
Mac OSが協調型マルチタスクやメモリー保護の欠如という泥沼にはまったのと同様、2009年でのQuickTimeは、並列性に関する古びた概念と、設計時に焼き込まれた古びたサブシステム層が足をひっぱっている。
iPhone向けのビデオ用コードが書かれたとき、QuickTimeの最新バージョン7は単純にその要求に対応できなかった。
デスクトップでの長い人生の間にQuickTimeは肥大化し非能率になり、携帯機器（QuickTime1.0がリリースされた当時のMacの6倍のCPU速度を持つが）でモダンなビデオコーデックを扱うのに必要なGPU再生支援を欠いてしまった。
故に、Appleはコンパクトで、モダンで、GPUフレンドリーで、iPhoneのRAMやCPUに優しいビデオ再生エンジンを作った。
うーん。
デスクトップビデオのAPIは歳を取ったので置き換えないといけない。
新鮮で新しく、多少軟弱なハードウェアでも良いパフォーマンスを出せるビデオライブラリ。
Apple「( ﾟ∀ﾟ)ｱﾋｬﾋｬﾋｬﾋｬ」
しかしテクニックは変化する。幸運にも、これがAppleの強みだ。
QuickTime自身は既に3つのCPUアーキテクチャ、3つの異なるOSを経験している。
64ビットへの移行はもうひとつの（劇的ではないにしろ）転換点であり、AppleはQuickTime7と新しいQuickTime Xとの間に境界を設けることにした。
Snow Leopardでは、64ビットアプリケーションが使うQuickTimeはQTKit Objective-C フレームワークだけに制限された。
435:偽の神
09/09/05 21:00:06 vWN40Vil0
QTKit の新秩序
QTKitは新しいものではない：CocoaアプリケーションにQuickTime7のよりネイティブ感のあるインターフェイスを提供するもので、2005年に誕生した。
この抽象的な追加レイヤーが、QuickTime Xの移行の鍵だ。
QTKitは、QuickTime7とQuickTime Xとの間にあるオブジェクト指向の壁を隠蔽する。
従来のQTKitを使用したアプリケーションでは、QTKitの裏側でQuickTime7とQuickTime Xのどちらを使うかが選択されている。
QuickTime Xがより良いものなら、なぜQTKitはそれをすべての場合で使わないのか？ その答え。
Mac OS Xと同じく、初リリースであるQuickTime Xは機能が大きく制限されているから。
QuickTime Xは再生、キャプチャ、書き出しをサポートしているが、一般的なビデオ編集機能をサポートしていない。
また、そのサポートは「現代的な」ビデオフォーマットに限られている - 基本的に、iPod、iPhone、AppleTVで再生可能なものだけ。
他のビデオコーデック、そしてプラグインによるコーデックも忘れていい。QuickTime Xはそれらもサポートしていないから。
QuickTime Xが作業に対応できないケースでは、QuickTime7がその穴を埋める。
ビデオのカット、コピー、ペーストは？ QuickTime 7です。
ムービーから特定のトラックを取り出すには？ QuickTime 7です。
Appleの携帯デバイスが対応していないムービーを再生するには？ QuickTime 7です。
プラグインを使って対応コーデックを増やす場合は？ 読めたと思うけど、QuickTime7です。
ちょい待ち。
・64ビットアプリケーションがQuickTimeを扱う手段がQTKitだけ
・QTKitの背後ではQuickTime7とQuickTime Xの両方がある
・QuickTime7は32ビットのみ
・Mac OS Xは32ビットコードと64ビットコードの両方を実行できる「mixed mode」をサポートしていない
こんな状態で、64ビットのプロセスがQuickTime7を必要とするような作業をするというのは、狂気の沙汰ではないか？
436:偽の神
09/09/05 21:01:11 vWN40Vil0
64ビットのQuickTime Playerを起動して、QuickTime7を必要とするムービーを開いた場合を見てみよう。
Sorenson videoを使っているやつだ。（憶えているかい？ あの古き良き日々を）
よしよし、ちゃんと再生できる。
しかし、アクティビティモニタで「QuickTime」を探すと、このようになっている：
QTKitServer 32-bit process
（スクリーンショット）ずいぶんコソコソしてるねえ：32ビットのQTKitServerプロセス
答えが明らかになった。
QTKitを使った64ビットアプリケーションがQuickTime7（32ビットのみ）のサービスを要求するとき、QTKitは32ビットのQTKitServerプロセスを発生させて、それが実作業や64ビットプロセスとのやり取りを行う。
QuickTime Playerを起動した時にアクティビティモニタを眺めれば、必要に応じてQTKitServerというプロセスが発生しているのを見ることができる。
これらはQTKit frameworkによって、ユーザーに意識させないまま行われる；アプリケーション自身がこの機構を意識する必要はない。
うん、QuickTime7がMac OS Xから完全に消えるには（少なくともAppleは7をQuickTime Classicなどとは呼んでいない）、長い長い時間がかかる。
しかし、前途は明瞭だ。
Mac OS Xの新規リリースごとに、QuickTime Xのサポート領域は広がり、QuickTime7が必要とする数多くの事柄が減少していく。
例えば、Mac OS X10.7では、QuickTime Xはプラグインをサポートするようになると想像している。
10.8では、QuickTime Xはビデオ編集をサポートするだろう。
QTKitのネイティブな表面の下で起こっているあらゆる事柄が、遂には、QuickTime7を必要としなくなる。
437:偽の神
09/09/05 21:03:47 vWN40Vil0
意味するところ
驚かれるだろうが、現在のQuickTime Xの制限は、実はQTKit APIの進化や面白いアドバンテージを浮き彫りにしているのだ。
QTKitがQuickTime Xを使うように直接指示する方法がない - この方針について推察してみよう。
鍵はQTKit APIの概念にある。
1から7までのQuickTimeは、内部ではすべてのメディアリソースを単一の型で扱っている：ムービーオブジェクト。
この型はムービーを構成する個別のトラック、各トラックのサンプルテーブルなど、QuickTimeがメディアを解釈して操作するのに必要な全情報を含んでいる。
良いように思われるだろう、総合的なムービーオブジェクトの構造において、QuickTimeが要求することすべてを理解するまでは。
例えば、QuickTimeでMP3ファイルを再生するとしよう。
QuickTimeはまず、MP3を扱うムービーオブジェクトを生成しなければならない。
不幸なことに、MP3フォーマットはオーディオ構造に関する総合情報を滅多に持っていない。
たいていは、パケットのストリーム（順番付けされたデータ）だけだ。
ムービーオブジェクトを完成させるために、QuickTimeはスキャンおよびオーディオストリーム全体を解析する苦労を強いられる。
QuickTime7および以前のバージョンでは、スキャンと解析をバックグラウンドで逐次実行することで負荷を低減していた。
QuickTime Playerがムービーコントローラにプログレスバーを重ね表示するのを見ることができる。
下の画像は、Leopardで63MBのMP3ポッドキャストをロードしたときの様子だ。
ムービーのタイムラインバーで、グレーの部分がゆっくり右に伸びていく。
（スクリーンショット）QuickTime 7は必要以上に仕事をしている
再生は即座に始めることができる（頭から）とはいえ、一歩引いて考える価値はある。
QuickTimeを扱えるすべてのアプリケーションで、ムービーオブジェクトが生成される：編集、トラックの取り出しや追加、書き出し、名前を付ける… しかし、やりたいことがファイルの再生だけなら？
438:偽の神
09/09/05 21:04:28 vWN40Vil0
QuickTime 7のAPIには、内容に素早くアクセスする機能が欠けているという問題がある。
「ファイルをできるだけ素早く開いて再生できればいいよ」と指示する術がない。
編集または内容を書き出す場合に備えて、ディスクからファイルの全バイトを読み取って構造を確定するために解析する、なんてことしなくていい。
単に開いて再生するだけでいいんだよ。
Snow LeopardのQTKit APIはまさにこの機能を提供する。
事実、QuickTime Xバックエンドが適任な唯一の事柄、それはQuickTime X自身ができないことを一切やらずに、目的のものを再生することだ。
そして、再生した部分以外を扱うときは、QTKitに例外動作を要求する。
このメカニズムは、アプリケーションのメインスレッドにおいて、QuickTime Xが巨大もしくは遠距離にある（例えば、遅いネットワーク越しにある）ムービーファイルを、UIを停止させずに非同期ロードする方法でもある。
QuickTime Xの流れに乗るべき理由は多い。
QuickTime Xがサポートするメディアフォーマットで見ると、Xのほうが7よりも再生負荷が軽い。
（これは、再生だけを行う時に、編集や書き出しのための内部準備をしていないことだけが理由ではない。）
QuickTime XはH.264のGPU再生支援をサポートしているが、初リリースではNVIDIA 9400M GPUをのせたMacだけが対象だ（2009年のiMacの一部モデル、2008年および2009年のMacBookの一部モデル）。
最後に、QuickTime Xは延び延びになっていたColorSyncサポートを実現した。
439:偽の神
09/09/05 21:06:38 vWN40Vil0
The X factor
これはQuickTime Xの長い旅路の始まりにすぎず、そこまで幸先のいいものではない。
QuickTimeエンジンが編集をサポートしていない？ プラグインもない？ こんなのをリリースするなんて、まったくお話しにならない。
しかし、これが近年のAppleのやり方だ：着実かつ周到に進行させる。
Appleは、時間よりも、機能レスでのリリースを選んだ。
QuickTime7が全機能64ビット対応を果たすのかどうか開発者は心配していたが、QuickTimeの重大なコードベースでの難問（そして、腐ったCarbonを追い出すこと）は、当のAppleがもっとも影響を受けている：Final Cut Studio。
これまでは、Final Cut Studioは32ビットにとどまっていた。
QuickTime Xの機能向上にAppleが強い関心を抱いていることを、控えめに指摘しておこう。
とはいえ、Appleが拙速であることを期待してはいけない。
18年間開発されてきたAPIを作り直すなんてのは一晩でできやしない。
Mac OS Xの重要アプリケーションすべてをQTKitオンリーに置き換えるには、数年はかかるだろう。
移行とは愛あればこそ。
440:偽の神
09/09/05 21:09:09 vWN40Vil0
以上です。
最後まで残り続けたレガシーテクノロジーに、遂に改革の手が…という感じでしょうか。
441:名称未設定
09/09/05 21:43:34 uXSLU3wH0
＞偽の神さん
乙です。訳そうと思ってたら先を越されたw
>>433の「同時に、それはとても大きな取引に見えた。」は、
「当時はそれほど大したことでないように思えた」かと。
a great/big deal = so much くらいの意味です。
「QuickTimeがまだ64ビットになっていないことが想像される。」は、
「単にまだQuickTimeが64bit化される順番でなかっただけかもしれない、と考えることもできた」かと。
442:偽の神
09/09/05 23:31:42 vWN40Vil0
>>395
そろそろ力が尽きてきました。
最後は、ファイルシステムAPIの統合。
URLﾘﾝｸ(arstechnica.com)
ファイルシステムAPIの統合
Mac OS Xには、歴史的経緯により、アプリケーションがファイルを参照する方法がいくつもある。
プレーンなパス（例えば、/Users/john/Documents/myfile のような）は、OSの最下層でサポートされている。
シンプルでわかりやすいが、アプリケーションがファイルを追跡する唯一の方法がこれだとすると、あまりいいアイデアではない。
アプリケーションがパス文字列を元にファイルを開いたとして、編集中にユーザーがファイルを移動させてしまったとする。
アプリケーションがファイルの保存を指示された場合、パスだけを頼りにしていると、既存の場所に新規ファイルとして保存されてしまうだろう。
Classic Mac OS では、パスに依存しない、より洗練された内部方式を持っていた。
HFSおよびHFS+でサポートされている、固有のファイルIDを使う方法だ。
Mac OS Xでは、このコンセプトをFSRefというデータ型で実現している。
そして現代、ローカルマシンを越えてファイルを見つけるための表現方法として、URLがデファクトスタンダードになっている。
URLはローカルファイルを参照することもできるが、それはファイルパス方式と同じ欠点がある。
データ型の多様性は、Mac OS XのファイルシステムAPIに反映されている。
ある機能群は引数としてファイルパスを使い、別の機能群はわかりにくいファイル参照を使い、そしてURLを使う機能群もある。
これらのAPIを使うプログラムは、ファイル参照を相互変換するのに多くの時間を浪費することがある。
ファイル情報を取得する際も似たような状況だ。
OSのあらゆる層に、ファイルシステムのメタデータを大量に検索する機能があるが、包括的に使えるものはひとつもない。
ディスク上のあるファイルの情報をすべて得るには、複数のシステムコールを使わねばならないが、それらのファイル参照型はバラバラだ。
443:偽の神
09/09/05 23:32:30 vWN40Vil0
WWDCでAppleが挙げた例がある。
Leopard上のプレビュー.appで、ひとつのファイルを開くときの結果だ：
* FSRef をファイルパスに変換 = 4回
* ファイルパスをFSRefに変換 = 10回
* getattrlist() を25回コール
* stat() または lstat() を8回コール
* open() または close() を4回コール
Snow Leopardでは、Appleは新しく、統合されていて、包括的なファイルシステムAPIを、単一のデータ型を軸に構築した：それはURL。
しかしこれらはURL「オブジェクト」なのだ - NSURLとCFURLで、相互に互換使用できる - そして、FSRefの特性をも備えている。
Appleがこのデータ型に定めた理由は、opaque型であるため機能強化しやすい、それらを使う数多くのAPIがある、など。
URLは、数ある選択肢の中で最も将来が約束されていて、また新しいデータ型やメカニズムに対してほぼ無制限の柔軟性を提供できる体系を持つ。
新しいファイルシステムAPIは、パフォーマンスを引き出すためにメタデータやデータキャッシュをサポートしたopaque URL型 を軸とする。
また、Bookmarkと呼ばれる新しいディスク表現方式も登場する。
（ブラウザのブックマークと混同しないように）これはネットワークに対応しており、Mac OSのエイリアスに取って代わる。
Bookmarkは、あるファイルの中からファイル参照を作成するもっとも強固な方法になる。
また、各Bookmarkに任意のメタデータを付け加えることもできる。
例えば、アプリケーションが、「お気に入りの」ファイルにアプリケーション固有の情報を付加し、それらファイルの永続的なリストを保持し、背後で起こるファイル移動を反映させたいとすると、ブックマークを使うのがベストの選択になる。
444:偽の神
09/09/05 23:34:39 vWN40Vil0
私が長々と述べているのは、ファイルシステムAPIに自発的に興味を持ってもらいたいという訳ではなく、以前のCoreTextの時のように、Mac OS Xがプラットフォームとしてまだまだ若いと言いたいのだ。
7つのメジャーリリースを経てなお、Mac OS Xは3つの鎖から逃れようともがいている：NeXTSTEP、classic Mac OS、そしてBSD Unix。AppleのCore OSチームが、古くて厄介なAPIあるいはデータ型を、新しくモダンなものに容赦なく置き換えてきた様を見ることになるだろう。
変更の成果を受け取れるのはいつの日か？ これら新しいAPIが使われたMacアプリケーションがエンドユーザーの手に来る日。
最も上手に書かれたMacアプリケーションが、すでに望ましい挙動を披露している。
例えば、Leopardのテキストエディットは使用中のファイルが移動されても正しく追跡してくれる。
Document moved dialog
（スクリーンショット）テキストエディット：良識あるMac OS X市民
もちろん、変更の要点は「上手に書かれている」ことだ。
ファイルシステムAPIのシンプル化は、ユーザーフレンドリーな振る舞いを提供するための手間を大きく縮小し、開発者の背中を押してくれることだろう。
パフォーマンスの向上はおまけではあるが、開発者が新しいAPIをアプリケーションに採用する理由をひとつ増やしてくれる。
445:偽の神
09/09/05 23:35:34 vWN40Vil0
以上です。
これで、自分が面白そうと思った箇所は終わりです。
後は別の方におまかせで…
446:名称未設定
09/09/06 00:19:20 /il/FJ/z0
お疲れ様です。
英語が苦手な者にとっては真の神です。
ありがとうございました。
447:名称未設定
09/09/06 02:53:48 BKGE5ywJ0
>>445
乙です。
ありがとう。
448:名称未設定
09/09/06 03:41:05 xpYg1txn0
いつもありがとうです
449:名称未設定
09/09/06 05:54:41 yRMVxmR/0
ありがとうございました。興味深かったです。
450:名称未設定
09/09/06 06:00:57 zEN1Hafm0
読んでて面白い。プログラミングしたくなる。乙です。
451:名称未設定
09/09/06 12:46:27 YqXJBll00
QTスレから飛んできますた。超乙です。
>>433は「切手サイズ」ですね
452:名称未設定
09/09/06 17:33:55 0FiDbphh0
翻訳神はありがたいなあ
453:Finder 1/6
09/09/06 21:23:21 lNuYYQEu0
TigerでFinderの項を訳した者としては、ここでFinderの翻訳を取り上げないわけにはいきますまい。
なんせ初めてCocoa化され、しかも64bitになったFinderですからね。
ということでまいりましょう。
URLﾘﾝｸ(arstechnica.com)
Snow Leopardの最初期のスクリーンショットのリーク画像には、これまでと変わらないFinderのメニューの
「Finderについて...」を選択すると表示される情報ウインドウがあり、それはバージョン10.6と表示されていた。
つまり内容がアップデートされていることが推測できたわけだ。もっと面白いのは、その画像からSnow Leopardの
Finderは64bitアプリケーションであることが判明したことだ。
Mac OS XのFinderはMac OS Xの後方互換性を有するCarbon APIから成る「ドッグフード」アプリケーションとして
産声を上げた。これまで何年間も、Finderは不満や嘲笑のターゲットになっていた。これらの印象の悪さは、しばしば
Carbon vs Cocoaの優位性を論じる平行線の議論にかぶさってきていたものだった。
「FinderがクソなのはCarbonアプリだからさ。Cocoa Finderを出せよ！そしたら悩みの種も消えるからさ」とか。
さて、Snow LeopardのFinderは64bit版だ。そしてご存知の通りCarbonは64bitに移植されなかった。
てなわけで、Snow LeopardではFinderはCocoaなのだ。（実は悩みの種もまだちょっとあるんだけどね）
Cocoa化されるにあたっては、Snow Leopardの公式が適用されている。すなわち、目新しい機能追加はなし、
せいぜい小さなものが1つか2つあるだけというもの。で、新たにCocoa化されたFinderは見た目も動作も
今までのCarbon Finderとほぼ同じだ。Cocoaであることを示す一番のインジケータは、Core Animationによる
遷移効果の適用範囲が広がっていることだ。たとえば、サイドバーありのブラウザウインドウからそれらを折り畳んだ
最もシンプルなビューにしつこく変更しようとしたとき、これまでのように表示がチラつくことはなくなった。
その代わり、サイドバーはゆっくりとスライドしてフェードアウトし、ツールバーはシュリンクする。
すべてが新しいビューに呑み込まれていくのだ。
（訳註：これはFinderウインドウの右上のボタンをクリックしたときの挙動のことを言っているようです）
454:Finder 2/6
09/09/06 21:24:24 lNuYYQEu0
このCore Animationによる遷移効果は、いくつかのケースで一線を越えてしまったにもかかわらず、アプリケーションを
より洗練されたものに、そしてより「Cocoaっぽく」感じさせる。そして、Cocoaの採用により―想像だが、デベロッパに
とってはそうしたくなる衝動に抗いきれないほど―いとも簡単に機能を追加できるようになった。
カラムビューのヘビーユーザーが最も待ち望んでいた機能追加が今回ようやく実装された。すなわち、カラムビューが
ソート可能になったことだ。このソート順の変更はすべてのカラムに同時に適用される。カラムごとにソート可能でないのが
気に入らないが、ソート機能がないよりははるかにマシだ。ソート順の変更はFinderのメニューの「表示」から行える
（各ソートにはそれぞれキーボードショートカットが割り当てられている）。また、カラムビューのウインドウ内の
空白エリアを右クリックしてコンテクストメニューを開き、そこからソート順の変更を行うこともできる。
（スクリーンショット：Finderのカラムのソート順変更）
Snow Leopardではアイコンビューにさえも機能追加が行われている。すべてのアイコンビューウインドウには小さな
スライダーが表示されていて、そこからアイコンのサイズを変更できるのだ。
（スクリーンショット：アイコンビューはスライダー付きに）
これはちょっと変に思えるかもしれない。だって、アイコンのサイズってどれだけ頻繁に変更する？ でもFinderで画像の
プレビューを行おうとした場合、これは理に適っている。こういう役立つケースにおいては、アイコンの最大サイズが
512x512ピクセルに拡大されたことも、さらに理に適っている。
アイコンプレビューそれ自体は、Quick Lookの機能により適合するように機能が拡大されている。たとえば、小さなPDF
アイコンをズームして、下に示すように高解像度のプレビューをスムーズに行うことができる。ページをめくることまで
できるのだ。スペースバーを押せば、更に大きく柔軟性に富むQuick Lookビューに移行できるのだ。とってもスムーズな
エクスペリエンスだね。
（スクリーンショット：PDFファイルのアイコンプレビュー）
455:Finder 3/6
09/09/06 21:25:34 lNuYYQEu0
QuickTimeのプレビューも同様に機能が拡大されている。アイコン上でズームすると、妙な丸いプログレスインジケータの
ついたムービープレイヤーへと早変わりする。Finderのビューの設定における気まぐれな動作に抵抗しつつ、最も有用で
あるところのアイコンビューに移行することを考えると、この奇妙な小さなスライダーは実に有用なものになると思う。
（スクリーンショット：JobsのKeynoteのムービー）
リストビューにも機能追加が行われた。事故か偶然かそれとも？ リストビュー上である行をドラッグしようとしたとき、
行全体がドラッグ可能になった。Leopardではアイコンかタイトルしかドラッグできなかったのだ。選択アイテム数を
増やそうと他のアイテムにまでドラッグ範囲を広げてドラッグすると、カーソルが移動してしまっていたのだ。
この変更は意図的なのか、それとも新しいCocoa Finderにおけるリストビューのコントロールに用いた技術によって
たまたまできた結果なのか、私には分からない。でもいずれにせよd(゜ω゜)bｸﾞｯである。
リストビューにおいてカラムの分割線をダブルクリックすると、当該カラムが適切な幅にリサイズされるようになった。
これは、ほとんどのコラムが最も幅広い箇所に合わせて幅が拡大／縮小するということを意味する。データヘッダはより
冗長性の少ないフォーマットを表示するようにシュリンクする。これはおそらくLeopardでも部分的にはそうなっていた
のだろう。この機能がCocoaによって初めて実現できたことなのか、あるいはSnow Leopardで初めて正しく動作する
ようになったのかは知らないが、いずれにせよ良い方向への変化である。
Finderのブラウザビューを用いた検索機能も、年々多くのユーザーが待ち望んでいた「ちょっとしたこと」を実装する
ことで大きく進化した。Finderウインドウのツールバーから検索を実行する場合に、デフォルトの検索範囲を環境設定から
指定できるようになったのだ。神のご加護があったのかしらん。
（スクリーンショット：Finder 環境設定。マウスオーバーするとオプションが表示される）
456:Finder 4/6
09/09/06 21:26:41 lNuYYQEu0
他にも、長く待ち望まれていて今回実装された機能の拡張がある。デスクトップ環境をより強固なものに感じさせる拡張だ。
その良い例が、「ディスクが使用中のため取り出せない」エラーメッセージの取り扱いの進化だ。このメッセージを見た
ユーザーの次の反応は「わかった。で、何が使用中なの？」だったが、Snow Leopardではようやくその情報が提供される
ようになったのだ。
（スクリーンショット：ターミナルが使用中のためディスクが取り出せないというメッセージ）
（そう、Mac OS Xでは現在のディレクトリでコマンドラインシェルが実行中だとディスクを取り出せないのだ。
頭の良い処理だが、ウザくもある）
「ディスクが使用中」のエラーメッセージを見たときのもう一つ考えられるユーザーの反応は、「そんなのどうでもいい。
今取り出したいんだ！」というものだ。これにもオプションができた。
（スクリーンショット：ディスクの強制排出中の画面）
ふむ。でも一方のダイアログでは取り出しを妨げているアプリケーションの情報が、他方では強制排出のオプションが
見られるのはどうしてだろう。私には謎だが、おそらくはFinderに提供されるコンフリクトの情報に直接関係している
のだろう。（今まで通り、昔ながらの lsof コマンドで原因を推測することもできる）
で、新しいCocoa FinderはCarbon時代のみっともないバグをすべて一掃することができたのだろうか？ 実は完全には
できていない。Cocoa Finderとしては実質バージョン1.0のリリースだし、1.0らしいバグもある。Glen Aspeslaghが
見つけてくれたバグを右に示そう。
お分かりかな？ もしお分かりでなければ、変更日順にソートしていると思われる順番を見てほしい。そう、いにしえの
Finderマジックは完全になくなってはいないのだ。
457:Finder 5/6
09/09/06 21:27:56 lNuYYQEu0
アイコングリッドの操作におけるいくつかのおかしな挙動もまだ残っている。グリッドのスナップが有効なビューにおいて
（あるいはCommandキーを押しながらドラッグしたとき）、アイコン同士がまるでお互いを怖がっているかのように
大きく離れようとする。グリッドスポットを選択しスナップしようとした場合、その近くのアイコンもそうなる。
あたかもこれらのファイル名がある日200文字の長さの名前になって隣のアイコンに重なり合うことをFinderが極端に
恐れているかのように。
この挙動が最悪の状況で現れるケースとしては、Finderの画面右端がデスクトップにマウントされているボリュームの近くに
ある場合が挙げられる。（因みにこれはデフォルトではない。デスクトップ上にディスクを表示させる場合は、Finderの
環境設定でチェックを入れる必要がある）新しくディスクがマウントされると、この症状が出てくるので驚くことが
しばしばである。Finderの画面右端近くにアイコンがある場合、新規にマウントされるディスクはその場所を避けて
表示される。ここでもまた、実際の名前ないしアイコンが重なり合うのをFinderは避けているわけではない。単にいつか
将来的にそういう可能性があるというだけのことであるのに。馬鹿げたことだ。
Finderのレポートカード
全体的には、Snow LeopardのFinderはいくつか本質的な進化を遂げたといえる。64bit Cocoa化、いくつかの役に立つ
新機能、そして洗練が加えられた。わずかにアニメーションの少々過剰な使用と未だに残るややこしいバグが気になるだけだ。
Carbon FinderがSnow Leopard以前の機能構成と洗練度にたどり着くまでどれだけの時間を要したことかと考えると、
今回のCocoa Finderは最初のリリースにもかかわらず、前任者に追いつき追い越しているという意味で、素晴らしい成果を
挙げている。Leopardでは、Carbon vs Cocoa戦争はCarbonはお役御免になったわけではないという点で一息ついていた
のではないだろうか。でも今回Carbonは第一線を退いた。そして勝者がその利を得たわけである。
458:Finder 6/6
09/09/06 21:33:53 lNuYYQEu0
＝＝＝＝ここからは訳註＝＝＝＝
Tigerのときでも感じたのですが、このレビュアーはClassic Mac OSのアイコンビューの相当な愛好者で、
従ってレビュー自体も見てお分かりの通り、彼がアイコンビューでFinderを使うことを前提に書かれています。
TigerやLeopardではAppleがアイコンビューに関して力を入れていないことに
悲憤慷慨しているようなレビューだったのですが、
今回のレビューではQuick Look機能の強化にあわせてアイコンビューも
大幅に機能強化されたことにご満悦という心境が伺えて、訳していて面白かったw
459:名称未設定
09/09/06 23:46:09 0k/u9KNBi
おおー、面白かった。
翻訳ありがとうございます。
460:名称未設定
09/09/07 03:53:22 RIVGHYu80
お疲れ様です。
今後さらなるFinderの進化が期待できそうで嬉しいです。
461:名称未設定
09/09/08 02:08:04 gh1M8NHB0
乙です!GJ!
462:名称未設定
09/09/08 06:43:14 So6s4A3Q0
面白かったです。これ読むまでカラム表示順を変更できることに全く気づいてなかった
463:名称未設定
09/09/09 12:24:00 rFEzAp9s0
カラムの表示順変更自体は10.5でもできるけどね
464:名称未設定
09/09/24 16:02:55 aztTNJAIi
保守
465:名称未設定
09/09/25 14:06:10 J6uDL2Xq0
お願いします。
ファイルのダブルクリックで作成アプリが開かない話。Snow Leopard で Creator 消滅？
URLﾘﾝｸ(www.appleinsider.com)
466:名称未設定
09/09/25 22:48:54 zoRSAVtg0
>>465
その記事ではないけど、どうやら消滅したみたい
>926 名前: 名称未設定 Mail: 投稿日: 2009/09/25(金) 01:09:02 ID: ETIbxH/C0
>>>925
>コレと関係しているのか?
>
>Macでtwitterスレ
>ｽﾚﾘﾝｸ(mac板)
>624 ：名称未設定：2009/09/25(金) 00:28:53 ID:I7pmvyaN0
>>>623
>原因はこれ 雪豹の仕様変更
>URLﾘﾝｸ(d.hatena.ne.jp)
467:名称未設定
09/09/25 23:33:58 JJ1sev790
>>465
Creator廃止の流れは以前から表明して、Appleは代わりに
UTI(Universal Type Identifier)を使う事を推奨している。
たとえばKeyNoteなら com.apple.keynote.key、Excelなら
com.microsoft.excel.xls が既に定義されている。
UTIはEA(Extended Attribute, 拡張属性)としてファイルへ埋め込まれ、
SpotlightはUTIを参照して文書を検索する。
PhotoShopや雪豹は持っていないから断定なんてできないんだけど、
現行版だとUTIが定義されていないから面倒なのであって、
雪豹対応版(あるいはアップデータ)で改善されるんじゃないかと推測。
KeyNoteやExcel/WordのCreatorを削除しても、その文書が
適切なアプリで開けるか確認してみて >>雪豹を飼ってる住人さん達
468:名称未設定
09/09/25 23:37:25 KCTQr30l0
UTIはその名の通りファイルタイプを識別するものであって、開くアプリケーションを指定するものではないよ。
まあ俺はクリエータなんて要らないけど。
469:名称未設定
09/09/26 00:26:33 HWP+9Lyn0
うーん、そうかぁ。じゃ>>476は撤回する。