Mac関連ﾈﾀをそれはもう凄まじい勢いで翻訳するｽﾚ7

http://www.roughlydrafted.com/2008/06/14/cocoa-for-windows-flash-killer-sproutcore/

Cocoa for Windows + Flash killer = SproutCore


いつもの読者であれば覚えているだろうか、AppleがSafari for Windowsをリリースしたとき
私は、Cocoaの知名度と採用を広げるためにWindowsにCocoaの開発モデルを移植するのではないか
と書いたことを。

また去年、AdobeのFlash/Air(さらに、Microsoftの真似っこSilverlightもだが)を
潰すためのAppleの奮闘をおおまかに書いた、それは批評家がiPhoneにFlashが
搭載されてないことが致命的なものであり、すぐにでもFlashを移植したほうがいい、
するべきだ、いやするだろうと述べていた時だ。

Flashに対してのAppleのair発表攻撃とWindowsへCocoaを振りまくことが実際に
関連づけられてることがわかれば、サプライズではないだろうか。
(訳注　air発表攻撃ってのはApple's air supply attackって書いてたからmac book air発表に
adobeのairと名前を被らせたという意味なのかなーと思うんだが、間違ってたらすまん)

更なるサプライズ

AppleがWindowsプラットフォームへQuicktime、iTunes、Safariに続き
更なるアプリケーションのセットを出すとなればまた驚きだろう。
現在出しているアプリケーションと同じように新しいアプリケーションも何百万もの新しいユーザに
MacOSXのインターフェースを持っていくことになる。
その上、多くの観客の前にCocoaスタイルの開発をも押し進めることになるのだ、
新しいアプリケーションを作るために使っているフレームワークを提供しているのだから。

他のサプライズもある、これらのアプリケーションはLinux上でもクロスプラットフォームで
動くことになる。Appleはそれをどうやってやるのかって?　そうだ1997年に試みられた
他のOSでも動くクロスプラットフォームのYellow Boxランタイムの発表は無くなったではないか。

そうではないのだ、Adobeが使わせようとしているFlash/Flex/Air、MicrosoftのSilverlight、
SunのJavaのような、いわゆる"リッチインターネットアプリケーション(RIA)"をAppleは開発者に
Webブラウザの中に作れるようにするためにCocoaにみがきをかけているのだ。

アールアイエー　行方フメー（ラッパーっぽく

Adobe、Microsoft、Sun、その他のRIAツールキットのベンダーは、90年代中期の
クライアント版Javaの熱狂、あるいは90年代後期のシンクライアントへの強い興味を
繰り返すようなRIAの興奮を生み出そうとマーケティングの努力をしている、
だが実際のところRIAは世界を席巻してはいない。
とはいえ、Flash、Silverlight、その他のツールや彼らの必須となるランタイムプラグインは
RIA開発のプラットフォーム独占になることが出来ると彼らが考える未来に向けて作られている。

だが今日、ほとんどの有名なリッチウェブアプリの多くは、Maps、Reader、Docs、Sheetsを
開発している企業、Googleからのものだ。Googleのリッチウェブアプリは
Flash、Silverlight、Javaなどを必要とすらせずにMicrosoftのオフィスソフトに
戦いを挑んでいる。Googleは単純にオープンなWeb標準を使っている：HTML、
Javascript、そしてCSSだ。業界を先導するGoogleのリッチウェブアプリが
プロプライエタリなプラグインを使わないようにしてるのであれば、Flashや類似技術に
頼るべき理由があるのだろうか。

Googleのいつものパートナー、Appleも考えていることは同じようだ、不必要なFlashを全て
取り除き、HTML、Javascript、CSSという同じWeb標準で全てを構築している。

オープンツール開発に力を貸す

全てのWebデベロッパは、FlashやSilverlightのような、プロプライエタリなWebっぽい
プラットフォームに隷属するより、自由でオープンなソリューションに群がるはずだと
考える人もいるかもしれない。結局一度その実行環境に依存してしまえば、能力はAdobeや
Microsoftの上に成り立つことになり、彼らのツールを改良していく競争の重圧によって
枯渇していくことになるに違いない、独占への臨海を到達した後に変化が無くなった
WindowsとInternetExplorerのように、ということだ。

また、もちろんそうなればPCメーカーは自由でオープンなLinuxを受け入れると考える人も
いる、だが両方ともにそうなることはほぼないだろう、それも多くは同じ理由による。
両方の場合での問題はオープンなWeb標準は直接的には誰もリッチにはしてないということだ。
誰もそれを持ってないし、Linuxでもない、それらを改善へ向かわせる開発努力をさせる
ビジネスモデルも出来ていない、誰も直接的にはやっていないのだ、
Linuxに関連したサービスを売って利益を稼ごうとするRedhatやIBMのように
間接的に行ったり、二次的な戦略のことを考えていなければ。

この二次的な戦略というものが、GoogleとAppleが同様にオープンなWebを強く
好む理由を説明することになる、それは近視眼的な開発者が単に多くの労力をなさずに
当面の目標を為すことができるとして盲目的にFlashやSilverlightによって束縛されるのとは
対照的なものだ。

>>197
>Apple's air supply attack

「酸素ボンベに攻撃」＝「空気を奪う」「窒息させる」という意味だよ。
iPhoneにFlashを積まない事でAppleはAdobeの重要な呼吸穴を塞いでみせた、と。

GoogleとAppleがオープンなWebを好む理由

GoogleはWeb開発の標準仕様のツールに投資している、なぜならオープンなインターネットが
欲しいからだ；GoogleはオープンなWebが必要なのだ、なぜならAdobeやMicrosoftが
プロプライエタリなFlashやSilverlightのプラグインによってオープンなWebを侵すことで、
Webの中をオープンなHTMLの代わりに不透明なバイナリに変えられてしまっては、
競争が出来ず、広告を売ることが出来ないからだ。

Appleは広告屋ではない、だがハードウェア屋だ。WebがFlashやSilverlightを必要とすれば
AdobeやMicrosoftはMac(やLinux)のような他のプラットホームを故意に殺すことも、
単にそれらのプラットフォームはそれら自身が不適当なものだとして動かなくなるリスクが
あるとして不十分なものにすることも可能なのだ。現にAdobeはMac用のFlashの提供
(そしてWindows以外のあらゆるプラットフォーム)でその一部の機能を無効にしたことで
証明しているし、MicrosoftによってWindows以外のものはなにもかも破壊してきたことは
歴史的に見れば語るまでも無いだろう。

それによって、GoogleとAppleは偶然に一致した異なった関心によって団結することになる、
GoogleはWebがオープンであることを欲している、なぜなら広告を売ることが出来るから、
AppleはWebがオープンである必要がある、なぜなら常にいつもどおりにWebをブラウジング
するハードウェアを売ることが出来るから。
現在2つの会社は目標を達成するために独自に動いている、互いを補うことも多い。

>>201
おお、ありがとう。

というわけで誤訳等指摘あればよろしく。

GoogleのAPIはまだまだ

Googleはオフラインストレージを使用したリッチウェブアプリの拡充のためのメカニズムとして
Google Gearsを発表した。だがGoogleAPI開発の体験は、Maps、Gmailといったような
Webサービスへアクセスするには限定的なものとなっている。Google Gears、Androidや
その他の重要な新しいプラットフォームのAPIを提供するための労力は未だ確立されていない。

例として、Android SDKを提供するGoogleの進行は、2007年11月に発表されてから、
リリースサイクルと洗練さ、そして2008年2月の発表から磨き上げられている
AppleのiPhone SDKによって影を薄くさせられている。

Googleの他の問題は、大きい献身的なユーザベースがないことだ。Googleは多くのコードを
コミュニティに寄付しているが、それは必ずしもコミュニティがそれを使うことを意味していない。

AppleのAPI

対照的に、Appleは長年マーケットで証明され、業界の中で競争してきた中で広く採用された
とても強力で熟成した開発ツールとプラットフォームフレームワークを持っている。

AppleはMacによって最初のメインストリームになったグラフィカルなプラットフォームである。
そのモデルは結果的にはMicrosoftのWindowsの基礎として利用され、90年代初期に
Coplandの失敗によってAppleは人気を失うとともに、Windowsは人気になった。

NeXTを作るために80年代後期にAppleを去った従業員は、最初のメインストリームになる
オブジェクト指向のプラットフォームフレームワークを作った、開発の参考としてパクられたり
使用したいと業界が切望する標準を再び確立したのだ。

Apple、IBMのTaligent、SunのJava、Microsoftの失敗したCairoも全ては、人目を引くクライアントが
既に使用していたNeXTが持っていたものを出そうとしただけなのだ。

今日はここまで。
どうでもいい話といえばそうなので、読むほどのことでもないかもしれません。
上での通り誤訳指摘等あればよろしく。大して英語得意でもないので。

乙でした、とても興味深く読ませていただきました。
ありがとうございます。

>>206
乙!長文チャレンジ凄いです。
とても興味深い記事を紹介して頂いてThxです。続き楽しみにしてます

乙です。ワクワク話いいですね。
続きもよろしくお願いします。

面白かったです！
続きwktkしてます！

乙です。タイムスケールがあまりに壮大すぎていつの話だかわからなくなるほどw

水を差すわけじゃないですし、訳者さんは大乙ですが
RoughlyDraftedの言うことはあまり真に受けない方が…

>>212
真に受けてるってほどでもないです。えー？って思う文面も多いし。
まあ真に受けるかどうかは個人判断で。

AppleのAPIの哲学

オールドAppleの遺物が1996年NeXTを買収し、Mac OS Xに取りかかった後は、
AppleはそのデスクトップAPIを以下に注力するというユニークな哲学のもとに開発、
改良を行ってきた；

・機能を容易に
・不必要なAPIの開発はやめ
・改良のために繰り返せ
・量より質

APIの質と洗練さをAppleが強調することで、ずさんなコードと不十分な計画によって
引き起こされる大きな昔の痛々しい問題へ戻ってしまうことを防ぎつつ、
この10年Microsoftより早く移行を進めることが出来た。
それによって今度は90年代中盤のCoplandの失敗に伴うAPI開発のAppleの評判を取り戻した。

デスクトッププラットフォームには多くの開発者がいるものの、Appleは過去のまま
休むことはない。iPhoneにおいてAppleはデスクトップのCocoa APIを直接移植はしなかった、
しかし完全に新しいセットという事情と新しく始める機会を考え、いかに動かすべきかを
再構成、再考する機会を与えた。Appleのドキュメント"iPhone Getting Started Docs"から
SproutCoreブログが引用している。

"最大の違いの一つはUIKitクラス宣言を通したプロパティの幅広い使用である。プロパティは
10.5で導入されたもので、AppKitフレームワークの多くのクラスの新設に伴っている。
AppKitの中の同じgetterやsetterの単純な真似ではなく、UIKitはクラスインターフェースを
簡潔化するための方法としてプロパティを採用している。プロパティについての情報は、
Objective-C 2.0のプロパティの項を。"

CocoaフレーバーでオープンなWeb

AppleはCocoaライクな開発を現在Mac OS XやiPhoneの外の広い範囲に向けて推している、
Webだ。Appleは既に去年秋に発表した.Mac Web ギャラリーで、普通のデスクトップアプリに
結びついた直接的な操作とオフライン状態の機能を持ったリッチウェブアプリを提供する
能力を示している。これを行うために様々なJavaScriptフレームワークのツールがテストされ、
その後AppleはSproutCoreへリソースを置いた。

これはAppleがWeb標準を使うことで独自のリッチウェブアプリを進めることを
可能にするだけでなく、MITライセンス下において、Cocoaらしいクロスプラットフォームの
JavaScriptフレームワーク、SproutCoreを共有することでもあった。
この共有はRIAの位置へFlashのオープンな代替物を提供することを可能にするだろう。
SproutCoreは広告をアニメーションさせたりナビゲーションアプレットのためのFlashの使用と
競合するものではない、しかし完全に高度な操作を可能にするアプリケーションを展開するのなら、
AdobeのFlashベースのAIRプラットフォームをターゲットにすることになる。

WWDCの最大の発表の一つはiPhone、そしてクロスプラットフォーム化されるよう調整された
.Macの新ブランド、Mobile Meであった。AppleはWebカレンダーとコンタクトを追加し、
MailとFinderをモデルにしたiDiskを変更した。Mobile Meのギャラリーコンポーネントは
現在の.MacのWebギャラリーを更新したものだ、そしてそれはSproutCoreの早期バージョンを
使用して構築されている。

Charlesさん家のSproutCore

SproutCore JavaScript フレームワークはAppleも開発したが、オリジナルはMailroomという
オンラインe-mailマネージャを作るためにCharles Jolleyによって開発された。
Appleは.Macチームの一員としてJolleyを雇い、共同で彼のフレームワークを急速に
改善させていった。

SproutCoreはメニュー、ツールバー、ドラッグアンドドロップのサポート、
ローカライゼーションを使ったWebのための本物のアプリケーションを構築することを
簡単にするだけではなく、バインディング、キーバリューオブザービング、ビューコントロールを
持ったRails（もちろんCocoaも）のような完全なモデルービューーコントローラアプリケーションの
スタックも提供する。またJavaScriptの最新機能、遅延バインディング、クロージャ、ラムダ関数にも
触れている。また開発者はドキュメント生成やフィクスチャー、ユニットテストのツールを
ありがたく思うだろう。

Cocoaの強みをSproutCoreに根付かせる綺麗なMVC哲学のその重要な部分はバインディングだ、
プロパティ値の変化が自動的にいつでも伝わるようなJavaScriptを書くことが出来る。
バインディングによって、高度な一貫性を持った挙動を備えたかなり複雑なアプリケーションを
とても少ない"接着剤"コードで作ることが可能になる。

え? Webアプリ?

SproutCoreはMac OS Xのデスクトップアプリのようなルックアンドフィールの
Webアプリを展開するための軽いCocoaのようなものだ。WWDCで、ピクサーの
Michael B Johnsonはランチタイムプレゼンテーションで、64ビットアドレッシング、
マルチスレッディング、あと他のデスクトップだけの機能を必要としないなら、
Webでアプリを作るのを当然だと指摘している。

だが、Webアプリはしょぼくないか? 歴史的には確かにそうだ、
特に全てのサーバの応答がページロードを要求する時代もあった。Ajax技術の開発が、
現在のバックグラウンドでサーバから非同期でデータを出力することが可能になり、
それを助けることになった。ドラッグアンドドロップ機能を備えるFlickrのような最新の
Ajax Webサイトや、GoogleのAjaxの使用でさらにデスクトップライクにはなったが、
使いやすいインターフェースではまだ遅れている部分も多い。

SproutCoreはそれを前進させる；ブラウザによるローカルでのリッチな操作を保ちつつ
オフラインでの機能をサポートすることで、さらにデスクトップアプリのような挙動を持たせ、
ユーザが好まない連続的なHTMLページの読み込み等を減らすことを可能にする。
デスクトップアプリのように見える、Mac OS Xのデスクトップアプリにようにも出来る。

SproutCoreフレームワークはWebデベロッパの多くの問題をも解決する。
Safari、Firefox、IE6/7のクロスプラットフォームで動かすためのブラウザ互換性の問題にも
備えている。最新のブラウザの装飾的なCSS機能の能力も簡単に使えるようになっている。

フロントエンドからWebObjects、WebDAVへ

SproutCoreはシンクライアントの分野にも進出する、つまりアプリケーションは
全てバックエンドサーバから実行されるため、全てのクライアントにインストール、
管理をする必要が無いのだ。

シンクライアントの難しい部分は、Webのような機能的に小さいプラットフォームでの
弱さゆえに、一般的に最低レベルの機能が提供されていたことだ。SproutCoreはこれを
解決する、最新のWebブラウザの機能によって、クライアントのWebアプリは高機能になり、
十分に洗練されることになるからだ。

SproutCoreのWebアプリは、パワーとクライアントサーバ処理の力を持ったWebサービスの
柔軟性を組み合わせたものだ、Appleはこれを新しいモデル、"Webクライアントーサーバ"と
発言している。Mobile Meの中で新しいWebアプリはWebObjectsとWebDAVサーバによる
Webサービスと結びついている、だがPHPや、XML、JSONオブジェクトにデータをつけることで
他のあらゆるサーバとつなげてSproutCore Webアプリを誰でも作ることが出来る。

Yellow Boxの外

もしYellow Box、つまりCocoa for Windowsを待っているのであれば、待つのを辞めて
コードを書き始めた方が良い。SproutCoreはLeopardのCocoaの価値をWebに持っていく、
JavaScriptをデスクトップの機能の多くの自由な組み込みサポートを持った高機能な
アプリケーションプラットフォームにさせるものだ。

オープンなWeb標準を元にすることとそれ自身をオープンソースにすることの意味は、
SproutCoreによってプラグインやベンダーに頼らずにクロスプラットフォームな開発を
可能にするということだ。

Web標準でありつづけることは、昔のYellow Boxの重大な問題、Windowsの
下位レイヤーの互換性や、一部のCocoaの新機能の相似についての
心配をすることをせずに、AppleやコミュニティにとってSproutCoreを
前進させていくことを簡単にしてくれるだろう。またSproutCoreは、
新しいランタイムレイヤーによって開く未知のセキュリティホールへの心配を
防ぐように、良く知られたセキュリティコンテキストの中で動くようになっている。

AppleのSaaS

これはある興味深い可能性が出てくる。Appleは既に消費者向けの
"Software as a Service"市場において.Macで静かなリードをしている；
Google、Yahoo、そしてMSNはオンラインのメール、写真、その他アプリケーションに
広告を配信するモデルを作っている、Appleは実際に.Macのサービスを
販売することで、かなりユニークなものになっている。本当はAppleがしてることを誰もが
したいのだ。

Mobile Meは.Macの目標を変えたもので、iPhoneユーザに、そしてさらに大勢に広げ、
WindowsユーザにMac OS Xのアプリケーションを押し進めようとするものだ。
将来Appleは間違いなくMobile Meに新しいアプリケーションを追加するだろう。
Mac、そしてWindowsユーザの両方にiWorkのSproutCoreバージョンでオンラインオフィスの
競争へ参加するだろうか。Webを介したファイル共有やVNCスクリーンシェアリングを可能にした
Back to My Macの拡張はどうだろう。

そして、サードパーティはどうか。Mobile Meプラットフォームに入りたい企業の
開発者も確かにいるだろう。AppleはサードパーティのWebアプリのホスティングを考えるべきだ、
サービスの一部としてバンドルするか(そうすればMobile Meの価値も上がる)、あるいは
少しのお金を払うことで使えるようにすることが出来る追加アプリでもいい。
想像してほしい、iPhoneと同様のダイレクトなWebアクセスと同期を可能にする
QuickBookのMobile Meバージョンを。

Web Apps Store

Webデベロッパは、彼らのサービスを売ることがほぼ不可能であることは
よくわかることだろう、だがAppleはモバイルソフトウェアで同様の問題を解決するように
この問題も解決出来る。Mobile MeでiPhone App Storeの同じものを提供することによって
iTunesの拡張のように動くWebアプリとWebサービスの成長しうるサブスクリプション型の
市場を作ることができるだろう。事実、AppleはiTunesにWebKitのビューを追加出来るし、
幅広いユーザにMobile Meアプリを表示することが可能になる、iTunesがいいのは
支払いのためだ。

もちろん、AppleはWebアプリを売るためにiTunesのインフラを必要としていない、
Safari for Windowsもあるし、FirefoxやIEでも動くからだ。もしApp Storeが面白いと
思ってるなら、Mobile Meの中のマーケットも実際にますます面白くなるべきだろう。

高い回転率の無料サービスとしてFacebook上にFlash風のアプレットを提供することで
大騒ぎするような利益が無く注目度の高い市場の中、おそらく本物のアプリケーションと
Webサービスを有料サービスとして記録的な利益を生み出させている忠誠心のあるユーザに
提供するAppleの能力はさらに注意を引くことになるだろう。


突っ込みどころはまあいろいろとあると思いますが、とりあえず終わり。

　　∧__∧
　 (´･ω･`)　　乙です！
　 (つ旦と)
　 `ｕ-ｕ´

乙です。面白かった。
今日のCNETに載っているFirefox 3の記事でも、Web標準＝FlashやSilverlight排除っていう
意味にも取れる部分があったから、実はそういう考え方が浸透してきているのかもね。

保守

ttp://www.matasano.com/log/1069/apple-ships-suids-with-applescript-dictionaries-hilarity-ensues/

乙です。本当にここのせめぎ合いはどうなるですかねー

乙っすね。

MobileMeのデモを見れば誰もが認識できるでしょ、
SproutCoreの可能性、ウェブアプリが新たな段階を迎えたのを。

MobileMe版のiWorkというのは確かに良い考えだし、
Appleも、Googleに対抗する手段としても考えてるだろうね。