TidBITS#1145/08-Oct-2012 TidBITS#1145/08-Oct-2012今週は意見記事が中心となる。Glenn Fleishman は Apple の新しい Maps アプリについて New York Times が掲載した極めて厄介な記事に対する批判を述べ、また App.net が値下げしたニュースも伝える。次に Steve McCabe が自らパイロットの帽子をかぶり、時代遅れの FAA 規制つまり民間航空便の機内でポータブル電子機器の使用が制限されていることについて分析する。そして Matt Neuburg は iOS 6 における開発者レベルの新機能を概観しつつ、それらの機能が遠からず iOS アプリが私たちのためにできる事柄に反映されることになると論ずる。今週注目すべきソフトウェアリリースは、Things 2.1、Sandvox 2.6.7、Hazel 3.0.13、Airfoil 4.7.4、Adobe Lightroom 4.2、OS X Mountain Lion 10.8.2 Supplemental Update、Mac OS X Lion 10.7.5 Supplemental Update、それに iPhoto 9.4.1 だ。
記事:
----------------- 本号の TidBITS のスポンサーは: ------------------
---- 皆さんのスポンサーへのサポートが TidBITS への力となります ----
文： Glenn Fleishman: [email protected], @glennf 訳： 亀岡孝仁<takkameoka@kif.biglobe.ne.jp>
私が "新ソーシャルネットワーク App.net、チャットと広告の上を目指す" (28 August 2012) で取り上げた App.net は未だ開発途上にあるが、初期の頃の注目を集めた後でも、興味は衰えていない。このサービスは Twitter と肩を並べるべく機能を追加し続けているし (メッセージを "お気に入り" にする様な)、独自のオプションも提供している (非 App.net ソースにリンクしたポストの様な、他のソーシャルネットワークでも Web ページでも良い)。そんなオフサービスのリンクなど許すのは、ユーザーが他のものを見るために一旦離れても気にしないサービスしかないではないかとの疑義もあるかもしれない。
App.net は、ほぼ 20,000 の有料加入者を確保したが、これには一般から資金を集めた立ち上げ時代の参加者も含まれる。先週、このサービスは料金を年額 $50 から 年額 $36 へと下げ (前払いの場合) そして既存のメンバーの有効期限を数か月延長した。更に、全額前払いしなくとも毎月 $5 で月単位で試行をしたい人のためのプランも追加した。
このサービスはまた 開発者に報いる最初の取り組みも発表した。2012年 10月から、App.net は毎月少なくとも $20,000 を脇に取っておいて、App.net プログラムまたはサービスを積極的に活用しているソフトウェアメーカーに分配するという。毎月、メンバーは調査を受けとり、使用した個々のアプリまたはサービスの有用性について、無視するか或いはどれ程 "価値があったか" のスライダーを動かして意思表示するかのオプションが与えられる。これは使用パターンや他のデータと一緒にされる。開発者はこのプログラムに参加する選択が与えられるが、それでソフトウェア或いはサイトが課金をしたり或いはその他の方法で金儲けをすることを禁じられることは無い。
App.net と働く成熟性を増しているアプリケーションの数も増え続けている。現在 iOS アプリも幾つか出ている；私もそのうち三つを試してみた (有料)。目に付くのは、Tapbots がリリースした Netbotで、これは人気の Tweetbot クライアントの App.net バージョンである。iPhone/iPod touch と iPad 版が別個に用意されており、それぞれ $4.99 である。内蔵されたツールの一つを使うと、あなたの App.net フォローリストを iOS 内で登録されたあなたの Twitter アカウント上でフォローしているものと比較させてくれる。私の場合、Twitter 上で私がフォローする人々の 15% が App.net アカウントを持っていることが分かった - 1000 アカウントのうちおよそ 150 である。(私がフォローするアカウントの多くは RSS の様なもの、通知、或いは他の稀にしかアップデートされないオートボットである。)
Netbot は iOS 内蔵の機能を使って Twitter へのクロスポストも許してくれる。Twitter はその様なクロスポストを (今のところ) 排除していないが、その API は Tweetbot が Twitter メッセージにアクセスし、それから Netbot 或いは他の方法経由で App.net にポストすることを許さないであろう。私はクロスポストをするつもりはない；私は App.net の進化に注目しているので、これら二つのサービスは別々のままにしておくであろう。
コメントリンク13315 この記事について | Tweet リンク13315
文： Glenn Fleishman: [email protected], @glennf
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
New York Times の "Common Sense" コラムに載った James Stewart の記事 "Apple's Maps and Jobs's Shadow" を読み始めて、私は記事の最初の二つの段落が Steve Jobs から Tim Cook への Apple の移行期について微妙な点をうまく捉えていると感じ、同社がこの 12 ヵ月間に財政的に成功を収めたことと、将来に向けて同社が直面する課題について、正しい論調を展開していると思った。それから三つ目の段落に読み進むやいなや、とたんに記事は悪い方に転落し始めた。
筆者 Stewart は、ソフトウェアアプリケーションである Maps アプリと、その基盤を成す地図データや Apple がそこに組み込んだ運転道案内のアルゴリズムとを、完全に混同している。どうやら彼は、競争力のあるマッピングおよびナビゲーション用のプログラムが 2009 年以来世に出回っていることを十分には理解していないようだ。彼はまた、もう一年も前に下された決断、その実施に Jobs も関与していた電子ブックの価格決定の話を挟み込んで、それがまるで Cook に責任があるかのような話の進め方をしている。いや、Cook には責任がないと言っているのかもしれないが、よく分からない。（最初に登場して以後、Stewart の記事はいくつかの場所でアップデートされたが、元記事に追記された訂正文に触れられているのはそのうち一つのアップデートのみだ。これらのアップデートによりいくつかの議論はますます混乱してしまったが、それらの点についても以下でできるだけ触れてみたい。）
まず初めに、Stewart は次のように書いている：「Apple は Google の地図を自社独自仕様のマッピングアプリケーションで置き換えるという決断について十分に説明をしていない。」それは違う。Maps アプリは、その最初の登場の時からずっと、常に Apple が書いたアプリであった。Google はデータを提供してきただけだ。Apple が変更したのは、データおよび道案内のプロバイダを従来の Google を止めて独自にライセンスしたいくつかの情報源へと切り替えたに過ぎない。アプリ自体に表示された情報によれば、情報源として TomTom や Waze といった会社の名前が挙がっている。彼はまた、iPhone 5 でこの入れ替えが起こり、iOS 6 を走らせることが可能な他の iPhone 機種では起こらないと言っているようだが、旧モデルのオーナーは（少なくとも今のところは）iOS 5 のままにして古い Maps アプリを Google のデータで使い続けることができる。[アップデート： Stewart の記事はその後書き換えられて「自社独自仕様のマッピングアプリケーション」という部分を削除し、iOS 6 にも触れるようになった。]
彼は次のように続ける：「Apple が iPhone で独自のマッピングテクノロジーを使うようになったことは、いわゆる抱き合わせ販売、時にはバンドル販売と呼ばれるものの、典型的ケースと思われる。」それから彼は、iPhone 5 を購入すれば Maps アプリを使用することが必須となる、などと主張する。もしもそんなことが事実ならば、iPhone がサードパーティのアプリを全く許さないということになってしまい、iPhone 発売の初日当日から大問題となっていただろう。新しい iPhone 4 または 4S を今日購入すればやはり iOS 6 と新しい Maps アプリが付属しているが、理論的にはそれらの機種は iOS 5 にダウングレードすることも可能だろう。[アップデート： その後記事は書き換えられて、iPhone 5 に限定した部分の記述は削除された。ある読者がコメントに寄せてくれた情報によれば、iPhone 4 や 4S をダウングレードするのはほぼ不可能に近いとのことだ。]
Stewart はこのことを、1990 年代末から 2000 年代初めにかけての Microsoft と Netscape (およびその他の会社) との戦いに結び付けようとする。そこで彼は Microsoft が自社独自のウェブブラウザを「Netscape を除外するために」バンドルしたと筆を進める。けれども彼のその主張も、その後に続く議論も、あの長年にわたった法律的および広報活動の争いに存在した数多くの微妙な要点が彼のアナロジーに矛盾しているという事実には目を塞いでいる。
まず第一に、Internet Explorer がデザインされたのは Windows に不可欠の要素となるべきものとしてであって（その後年を経てその意味はますます大きくなった）ActiveX など独自仕様のテクノロジーを使ったためにサードパーティのウェブブラウザが同じ仕様体験を提供するのは不可能となった。確かに Maps アプリを iOS から削除することはできないし、このアプリは Siri と統合されてロックされたスクリーンからも動作できるのは事実だが、だからと言ってそれが他のアプリに比べてものすごく大きな利点だとは言えない。
第二に、Microsoft は Windows に変更を加えて Internet Explorer と同じように動くウェブブラウザをサードパーティが書くのを難しくし、技術的リソースの提供やサポートを提供するのを拒んだというのはよく言われることだが、iOS でサードパーティの開発者用ツールがリリースされて以来、Apple について同じことを言うことはできない。一般的に言って、Apple は毎回のリリースごとに、従来 Apple 専用の機能であったものに対してより多くのアクセスを開発者たちに与えるようになってきている。例えば、一定範囲内のバックグラウンドタスクを追加するといったようなことだ。（確かに、iOS の中で特権的な位置を占めているアプリもいくつかあるし、時として Apple が競合するアプリを App Store で拒否することがあるのは事実だが。）
第三に、Stewart は「Microsoft が結局 Windows ユーザーたちにそれぞれ独自のウェブブラウザを指定できるようにすることに同意した」結果として状況は解決したと主張しているが、その主張は完全な誤りだ。ヨーロッパのみにおいて、Microsoft はユーザーたちに多くのブラウザの中から好きなものを選ぶことのできる一種の「投票権」を提供することを義務付けられた。米国でも、世界のその他の地域の大部分でも、そのような非バンドル化が義務付けられたことはない。[アップデート： 改訂後の記事では、今引用した理由付けの部分が全部削除され、新たな見かけ倒しの議論がその代わりに挿入された。]
実際に起こったことが何かと言えば、サードパーティのウェブブラウザがそれぞれ改善されて、パフォーマンスの面でも品質の面でも競合できるレベルに達したというだけだ。とりわけ、ウェブ標準に準拠するようデザインされたサイトについては、そのことがはっきりと言えた。その間、Microsoft は大いなる方向転換をして、新バージョンを出す度に Internet Explorer が毎回毎回いかに標準に準拠するようになってきたかを大袈裟に語る（かつそれを証明する）ために何年も費やしてきた。
iOS にサードパーティのアプリが導入された時点以後、私の知る限り Apple は一度もマッピング用ソフトウェアの配布を制限したことはない。現在その種のプログラムは数十種類も入手可能で、その多くはメジャーな独立の GPS メーカーが作っているもので、無料のものも有料のものもある。 MapQuest アプリは Google Maps と競合する AOL の一部門が出しているが、もう何年も App Store にあって、無料であると同時に使っていてとても楽しい。過去三年間に私はこれらのナビゲーションアプリを 15 個以上レビューしたが、そのうちのいくつかは現行の Maps アプリに比べても、また Android オペレーティングシステムで走る Google のマッピングアプリに比べても優れている。（Google も同様に Android で他のマップアプリもサポートしている。）
Stewart は Maps アプリにいくつも問題があると指摘しているが、そのことは正しい。彼はそこで、もしも Jobs ならばこの Maps アプリの背後にあるデータの品質について Cook がしたほど素早くかつ深々と謝罪を述べただろうかと思案する。（問題はデータにあるのであってアプリ自体にあるのではない。アプリ自体は素敵で十分うまく動作している。）どうやら彼は、MobileMe を巡って Jobs がどのように振る舞ったかをすっかり忘れているようだ。同じように忘れているベテランのテクノロジーレポーターたちもいるようだが、Jobs は MobileMe の状況について公式に謝罪するとともに彼に電子メールを送ったユーザーたちにも電子メールの謝罪を送り、部門の責任者を解雇し、何ヵ月もかけてすべてを正常に戻したのだった。
Stewart は Jobs について次のように話を続ける：「彼は iPhone 4 のアンテナに関する苦情を聞いた後にも（謝罪するという）その考え方そのものに抵抗を見せたことは周知の通りだ。」でもあの際は、もっと状況が複雑だった。明らかに Jobs は比較的些細な状況が正当な均衡を超えて誇張されていると感じていた。とりわけ、携帯電話の大多数に同様の問題が存在して、マニュアルにそのことが記載されていることも多かったのだから。確かに Jobs は "sorry" (すみません) という言葉を口にはしなかったけれども、同社は早くも Verizon モデルの iPhone 4 の時点でアンテナのデザインをやり直し、数ヵ月間にわたって無料のバンパーやケースを配り、その状態でその機種を何百万台も販売したのだった。その後問題が騒ぎにならなくなった理由はただ一つ、それが圧倒的大多数のユーザーに一貫して発生する問題ではなかったからだ。もしそうでなければ、大多数のユーザーが電話機を返品するか、口コミの情報の故に買わなくなるかするようになっていたはずだ。
コラム記事のこの決定的な個所で Stewart は、iPhone 5 リリースの前に誰が Maps アプリを書いたのかを間違え、すべての iOS 6 ユーザーが Maps アプリを使えることに気付かず、その上他にも多数のマッピングアプリがずっと以前から利用できたという事実にも目を背けようとしているように見える。彼はここで iOS が世界的にはスマートフォン市場の占有率では下位に甘んじていると指摘してから、最後に Cook がユーザーたちに対して「代替製品」を試してみるよう勧めたことに触れるけれども、そうした代替の地図プログラムは無料のものも有料のものもあって iOS に内蔵のものと同等あるいはより良く働くものたちであるという点には触れていない。その点は、iOS 6 が登場する以前から事実であった。
次に Stewart は、Walter Isaacson の書いた Steve Jobs の伝記から引用した iBookstore と価格決定の話という、無関係な議論を持ち出している。でも、この記事は Jobs の偉大な手から離れた Apple を将来に向けて導く際に Tim Cook が直面する問題についての議論ではなかったのか？ なのに、Stewart はお構いなしに Department of Justice (米国司法省) の起こした訴訟や（書籍販売社を含む）出版各社との和解に反対する人たちの意見も全く無視している。反対する人たちは、その和解は電子ブック市場における Amazon の独占を確立する結果となり、おそらくは将来司法省自身を新たな独占禁止裁判を起こさざるを得ない立場に追い込むだろうと考えている。
Stewart は専門家の言葉として「歴史的に見れば、Apple はこれまで独占禁止の問題にあまり気を配ってきたとは言えなかった」と引用している。歴史的に見て、Apple が独占禁止の状況に直面したことはなかったので、その言葉に言う「問題」がここで何を指しているのかを特定するのは難しい。
Stewart は記事の結びに、Tim Cook が Maps アプリについて謝罪したことを称賛している。（でも、それが Jobs のやり方に反するものだと彼はついさっき自分で批判したばかりではなかったのか？）その上で、独占禁止訴訟は早晩解決するはずだと述べている。おやおや、またもや彼は方向転換だ。（ひょっとして彼は Maps データを使って執筆してるんじゃないか？）どうやら彼はもう一度エコシステムに対する無知を証明したいらしい。彼は Cook が過去への決別として「Google やその他の地図アプリケーションを iPhone ユーザーたちが容易に入手できるようにする」べきだと言う。けれども現在の市場の状況はまさにその通りのものだ。（ただし Google はまだ独自の Maps アプリを iOS 用に開発していないとのことだが。）Cook の謝罪声明が発表されて以後、Apple は代替製品を App Store の中で特に目立たせて扱っている。
いつもならば分別あるしっかりした記事を書く経済記者で、以前から私も敬服する文章を書いてきた人物の手から、これほど混乱したコラム記事が書かれるとは、いったいどうしたことだろうか。Maps アプリとそのデータを混同した上に、競合するアプリたちの歴史や入手可能性などの知識もない (New York Times のテクノロジー記者たちに尋ねれば済むことだろうに)、そんな状態で記事を書けばその結果はただ虚報を広めるだけではないか。もちろん、Apple が時期尚早の段階で Maps アプリをリリースしたことについては批判すべき点がたくさんある。けれどもこのコラム記事は、そこに何ら価値あるものを寄与していない。
コメントリンク13322 この記事について | Tweet リンク13322
文： Steve McCabe: [email protected]
訳： 亀岡孝仁<takkameoka@kif.biglobe.ne.jp>
あなたが飛行機の上での電子機器に関わる規制や要件について最新事情を理解しようとして、少々混乱してしまったとしても無理はない。私は近頃では飛ぶよりも物理を教えることにより多くの時間を費やしているが、これに挑戦してみようと思う。
長年に亘って、その規則は極めて単純であった：如何なる個人の弟子機器も 10, 000 フィート以下の高度では使ってはいけないというものである。この高度で機長は通常 "シートベルト着用" のサインを消し、そして大抵この頃までには飛行機は大空港の周りでの混雑した空域からは離れている。
しかし最近の American Airlines からのニュースは、この規制に反しているかの様に見える。先月、American は同社の Boeing 777 フライトでは紙のフライトマニュアルや進路図は徐々に iPad で置き換えていくと発表した。2011 年の終わりには、American のパイロット達は フライトのある局面では iPad を電子フライト鞄として使い始めた；しかしこの新しい展開では iPad は全フライト中、ゲートを離れる所から駐機まで、コックピットで使われることになる。
しかしながら、American Airlines の乗客達の方は、離陸前から 10,000 フィートに達するまで自分達の電子機器を切ったままにしておかなければならない；離陸と着陸の間は、乗客は全ての電子機器の電源を切っておかねばならないという規則はそのまま生きている - これには携帯電話、ラップトップ、Kindle に iPod、そして American Airlines の 777 のパイロット達が使っていて、乗客達には離着陸時には使うなと言っている iPad さえも含まれる。
では、U.S. Federal Aviation Administration (FAA) は何故この規則を適用し続けるのか？ American Airlines が実証して見せた様に、もしコックピット内での iPad が - 理論的には干渉する可能性のある航空電子機器から数インチしか離れていない所で、飛行安全には何らの害も及ぼさないというのであれば、では一体全体、同じものが客室内の乗客の手にある時にはどうして使ってはいけないのか？ その答えは、個人用電子機器に関する FAA の規則が単にテックの暗黒時代からの名残であるからの様に見える - Federal Aviation Regulations (FAR) の Part 91 は全ての個人用電子機器の使用を禁じている。例外も幾つか定められている：携帯音声録音機、補聴器、心臓ペースメーカー (これが入っているのは大変結構) そして電気カミソリである。確かに広範囲なリストではあるが、全く時代遅れで (携帯音声録音機？ 今時？) そしてとうの昔に見直しされているべきものである。一旦見直しが済めば、この分野では世界中が FAA の動きに従う様なので、恐らくデファクトの国際標準もまた緩和されるであろう。
この FAR はフライトの運営者に - 商業フライトの場合、航空会社 - 彼らが安全であると定めた如何なる機器の使用も認めているが、FAA は 10,000 フィート以下での電子機器の使用を禁じるガイドラインを出している。という訳で、FAA は 28 August 2012 に コメントの求め (request for comments) を出したが、ずっと前になされていてしかるべきものである。
間違いなくこれらの規則は再検討を要する。近代の電子機器は電磁波放出に関して U.S. Federal Communications Commission (FCC) 規則に適合することが求められているし、近隣の機器からの干渉にも対処できるはずである - もし私の iPhone がある程度の漂遊電波に対処できるのであれば、何百億円もする Boeing ジェットが扱えないわけがなかろうと思う。
U.S. Transportation Security Administration (TSA) は明らかに、携帯電子機器がフライト安全に対する重大な危険因子とは見做していない。米国空域に入る乗客は空港のセキュリティゲートより先にほんの少量以上の液体を持ち込むことを禁じられているが、乗客の一人が Angry Birds で遊び始めたために飛行機が空から墜落する危険性があるとして FAA が恐れる携帯電子機器には手を振って通してくれる。もしこれらの機器が実際に安全を脅かすものであれば、これらを機上に持ち込むことを許してくれるであろうか？
同様に、自分自身にこれを問うてみて欲しい - もしあなたの iPhone が本当にあなたの飛行機を落とす可能性を持っているなら、あなたの客室乗務員はあなたに単にそれを切るようにお願いし、そしてあなたはそれに従ってくれたと信じることで満足するであろうか？ 実際には、多くの乗客は従っていない - YouTube 上でこの Auckland への着陸の様な離陸と着陸のビデオに対して簡単な調査をしただけでも、極めて多くの飛行機が背景であらゆる種類の電子機器が走ったまま毎日着陸していることがうかがえる。
我々旅人は、携帯電子機器が実際に事故の原因となることを示唆する証拠は無いと思っている。もし有るのであれば、我々の電子機器を使うことはフライトの如何なる段階においても、単に離着陸の間だけではなく、固く禁じられるであろう。FAA 自身の このことに関するファクトシートには、私が iPad を切らなければならないのは、フライトクルーはとりわけ一生懸命に集中しているので、彼らを邪魔しない様にするためだとある：
"より低い高度では、コックピットのクルーは到着と出発の重要な責務に集中しているので、如何なる干渉の可能性も安全上の問題となり得る。"
同じファクトシートにはまた、FCC は 800 MHz セルフォンの使用を地上施設との干渉の可能性があるとして禁じていると書いてある - 干渉が確認されているわけでもないし、そして飛行中の電子機器との干渉でもない。それに、最も近代的な電子機器は何らかの形の "フライトモード" を持っていて、iPhone の場合は "機内モード" であるが、これにすると全ての無線送信は不能とされるがその他の機能全ての使用が許される。
繰り返すが、明らかに、この規則は日常的に軽視されてきているが、問題は起きていないことに思いを走らせるべきである。もっと論議を進めると、何マイルも上空にあるセルフォンは多数のセルフォンタワーと見通し内アクセスを持つことが出来、地上にいる時通信可能な場合の何倍もの数となる、そのためセルネットワークは混乱してしまう可能性はある。だとすると、我々は恐らくセルフォンの使用を、高いビルの中、丘の上、或いは同様の事態が起こり得る如何なる場所でも、禁じるべきである。しかし、そうはしない、機内規則がそれ程厳密に強要されないのと同じ理由から - 明らかに実際の影響は殆どなく、そしてフライトの安全に対する危険の証拠もない。それに、これが問題だとしたら、FAA はこれは安全問題だと主張する代わりにセルキャリアを非難すると思いませんか？
また iPod や iPhone そして同類のものが 10,000 フィートまでは切られていなければならないという要件は、興味深い予期せぬ結果を招くということも気に留めて置く価値がある。飛行機がこの高度を通り過ぎる時、最大で数百台にも及ぶ機器が同時にオンとなる可能性がある - 何百台もの機器の電源が同時に入れられると、恐らくかなりの電磁波のサージが放出されると思われるが、電磁波干渉が墜落に関係あるとされたことは未だ一件もない。事実、FAA 自身も、不承不承ではあるが、機内電子機器が事故の原因となったことを示す証拠は無いことを認めている：New York Times は FAA のスポークスマンが "機上でこの種の機器からの事故として報告されたものはこれまで一件もない" と語ったと報じている。
ということで、問題は電子工学に特定された話ではなく、もっと広範囲な機械的なものなのかもしれない。強い乱気流に巻き込まれ "シートベルト着用" のサインが点灯された時、iPad が、理論的には、乗客の手から投げ出され殺人凶器となることは可能である。もっとも物理の法則はこの論議に全面的には賛同してはいない - この様な討議に出てくる乱気流の種類はどちらかというと、水平方向ではなく垂直方向であることが多いので、その場合 iPad は無害である。ではこの様な論点から電子機器を禁止するとしたら、他の重たい物体はどうであろうか、例えば本などは？ フライト上での本を禁止したりしたらこれは乗客から大いなる怒りを買うことは疑いの余地はないであろう - 通路での暴動は避けられまい。そして再び、FAA がこれを問題だと言っているのではなく、要は電子機器が航空電子機器と干渉するのを防ぐための法規制が存在するということなのである。
私が 2011年の 12月に Radio New Zealand の Nine To Noon 番組 iでこれについて話した時、この話題は私がこの番組で話した他のどのテーマよりも多く聴取者からのメールを生成した。心配したパイロットからも多くのコメントを貰った、曰く、もし現在禁ずるものがありそして墜落もないのであれば、そのままにしておくのが一番ではないかと。しかし、一人の商業パイロットとしてそして物理の教師として、更に長年に亘り数えきれない程多くの電子機器の熱心なユーザーとして、私は、これはその有用性 (仮にあったとして) よりも長生きしてしまった規則であると強く信じている。望むらくは、FAA の一般からの意見提供への誘い が、"携帯音声録音機" を最新技術だと示唆している時代遅れの規則の近代化につながって欲しい。
[Steve McCabe は英国生まれの Mac コンサルタント、テック作家、そして教師であり、現在は、技術とは最も無縁の理由から New Zealand に住んでいる。彼は New Zealand での彼の冒険について書き、そして テックについてブログしている。Steve の最初の小説 "Crash Landing" は、操縦を習っていた時の彼の経験にそれとなく基づいており - 教えたりコンピュータに向かったりしていない時、Steve は複数エンジンの計器飛行が許される商業パイロットでもある - 現在そのペーパーバック版が出ている。]
コメントリンク13256 この記事について | Tweet リンク13256
文： Matt Neuburg: [email protected]
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
休暇で月の裏側に旅行していた人でない限り皆さんご存じだろうが、Apple は先々週たくさんのハードウェアとソフトウェアをリリースし、iOS 6 もその中にあった。地球に戻ってからまだ iOS 6 をインストールしていない人は間違いなくお気付きだろうが、お持ちの iOS デバイスが（よほど古いものでない限り）さまざまのアイコンにバッジを付けたりその他いろいろの方法で、あなたにシステムソフトウェアをアップグレードさせるべく注意を惹こうと試みつつある。それと同時に、数多くのアプリが既に iOS 6 との互換性を組み込んで改訂されており、この流れはしばらくの間そのまま続くと考えてよいだろう。世の中、興奮のしっぱなしというわけだ。
けれども 私にとって 新しい iOS リリースで興奮すべき部分は、目に見えるシステムレベルの変更とか、内蔵アプリとかいったものではない。iPad にようやく時計がついたって？ まあそろそろついてもいい頃だよね。(ふふん) フォトストリームがカスタマイズできるようになったって？ どうでもいいさ。Facebook 統合だって？ ああもううんざりだ。Siri がアプリを起動できる？ そんなこととっくにできているべきだったね。ああそうそう、Apple が Google Mobile Maps を放り出すことで落ち目になりたいという気になったとしたって、そんなこと私は別に構わない。
私にとって、iOS の面白さとは、そのためのプログラミングをすることにある。iOS は、プログラミングをするための素晴らしいプラットフォームだ。だからこそ私はそのための本 ("?Programming iOS 5") を書いたのだった。新しい iOS リリースがある度に私の興味を惹くのは、それによって開発者たちにどんなことができるようになるかという点だ。そして、そのことは皆さんの興味をも惹くべきものだ。なぜなら、開発者たちに何ができるかが変われば、開発者たちが自分のアプリを書く際に、また自分のアプリに iOS 6 の機能を取り込むべく書き換える際に、そこに何が組み込まれるかが変わってくるからだ。そしてそれこそが、結局、あなた の目に触れるもの、あなたがアプリを使ってできること、に影響を与えるのだから。
ほぼ一年前（2012 年 10 月 17 日の記事“iOS 5 は開発者に、そしてあなたに、どう影響するか”参照）私は当時新しくリリースされた iOS 5 のいくつかの側面について開発者の観点から説明した記事を書き、それらの側面によってユーザーたちが iOS デバイスのスクリーン上に見るものにどのような影響が及ぶかについて、いくつか予想を述べた。（それらは結局驚くほどに正確で的を得ていたことが分かった。）今回のこの記事では、同じことを iOS 6 に対して試みてみたいと思う。前回の記事と同じく、ここで述べることであなたが自分で推論できないことは何もない。私の情報源は、その大部分が Apple 自身によるリリースノートなのだから。
カーテンの裏にいる男は気にするな -- 変更のうちその影響が最も広範囲に及ぶものは、エンドユーザーからはずっと離れた上流に、つまり開発者たちが使用するツールの領域に施されたものだ。
例えば Objective-C を見てみよう。これは iOS の Cocoa 流の世界におけるネイティブなプログラミング言語だが、いくつかエレガントなショートカットが今回装備された。そのいずれも驚天動地の変更という訳ではない。確かに、前の記事で私が触れた ARC (automatic reference counting) ほど根本的に革新的なものではないし、あなたが Objective-C のプログラマーでないのならばあなたにとって何の意味もない。だから、ここでは技術的詳細に深入りすることはしないが、どうか私を信用して欲しい。これらの変更は確かに小さなものではあるけれど、Objective-C を合理化しようとする Apple の計画の一翼を担っているのであって（つまり、これほど古くて極めて複雑な基盤構造を持つものであってもさらなる合理化が 可能だ ということも意味している）開発者たちにとっては大いなる意味を持つものなのだ。それは単純に次のように言い表わすことができる： 開発者たちは以前ほど大量のコードを書く必要がなくなるので、エンドユーザーにとって大事なもの、つまりそのアプリの実際的な機能性のデザインのために、より多くの時間と労力を振り向けることができるようになる。
iOS プログラマーたちが作業をする環境である Xcode もバージョン 4.5 へと進化して、こちらもまた開発者たちにとっては目標を達成するための労力が全般的に減り、以前ほどフラストレーションを溜め時間を費やして苦労する必要がなくなった。ただ、あなた にはそんなことは知る由もないのだが。例として storyboard を見てみよう。これは開発者たちがアプリの各「シーン」の間の関係性や移行のし方をグラフィカルに記述できる方法として Xcode 4.2 で導入されたものだ。（「シーン」とは、大まかに言って現在スクリーンを占めているインターフェイスを全体として考えたもののことだ。）確かに便利に聞こえるが、実際 storyboard の当初の実装は中途半端なものであった。例えば 私の iOS 5 プログラミングの本の中で、私はシンプルでアニメーションもない「モーダル表示」の移行をデザインするために storyboard を使うのは同じことを storyboard を 使わずに するよりも もっと 手間がかかると指摘した。その理由は storyboard のインターフェイスに「アニメーションなし」を指定する手段が提供されておらず、そのモーダル表示からアニメーションを呼び出した表示へ戻る手段もなかったからだ。けれども Xcode 4.5 ではそれらを含むいくつもの制限が storyboard から取り除かれ、storyboard がより使う気の起こるものとなった。
Xcode 4.5 と iOS 6 に盛り込まれたもう一つの新しいインターフェイスデザイン機能が "constraint" の導入だ。これは、各インターフェイス要素がそれを囲むインターフェイスがサイズを変えた場合にどのようにして自動的に移動したりサイズを変えたりすべきかを指定するための新たな手段となる。インターフェイスの再配置というのは iOS 開発者たちにとっていつも困難な課題であった。ユーザーがデバイスを回転させてインターフェイスもそれに合わせて回った際に、いつでもすぐにインターフェイスが自身を再配置しなければならないからだ。インターフェイスの自動再配置を記述するための初期の API は、シンプルなインターフェイスに対してはうまく働いたけれども、複数のインターフェイス要素の間の複雑なレイアウトを再配置しようと思えば追加のコーディングを手で施すか、または（こちらの方が可能性が高かったが）複雑なレイアウトを丸々あきらめてごくシンプルなインターフェイスに留まるかする必要があった。
デスクトップの開発者向けには、既に Mac OS X 10.7 Lion で constraint が提供され始めていた。あなたも知らず知らずにそれが働いているところを目撃しているかもしれない。例えば、10.7 Lion や 10.8 Mountain Lion の Apple Mail で、左側のメールボックスリストの横幅を広くしたり狭くしたりするとツールバー上の Delete ボタンが自動的に左右にスライドするのを観察できるだろう。この constraint 機能が導入される以前には、この種の効果は事実上不可能であった。ツールバー上のレイアウトはメインウィンドウのインターフェイスとは別の世界であって、それぞれ独自のルールに従っていたからだ。けれどもこの constraint 機能のお陰で、事実上何のコードも書く必要なしにこのような挙動が実現できるようになった。Xcode の中で直接デザインできるからだ。そして今、iOS 6 にも constraint が実装されたことにより、iPhone や iPad のユーザーたちも、インターフェイスのレイアウトに同様の洗練さが増すことを期待できるようになった。
孤独なフレームワークたちよ、彼らはどこに属するのか？ -- iOS 6 はさまざまの特化されたフレームワークについてもいくつか追加や変更を盛り込んだ。そのお陰で、いくつか特定の種類のアプリの開発者はそれらの利点を生かせるようになるだろう。
新しい地図アーキテクチャーによって、いろいろのアプリが以前よりも簡単に Maps アプリとやり取りできるようになる。そのアプリ独自の地図を表示する代わりに、アプリが Maps アプリに命じて特定の場所の地図を表示させることができる。その上、アプリが交差点ごとの道案内をできるための API も新設され、そのようなアプリがその情報を他のアプリ（例えば Maps アプリ）と共有することもできるようになるので、双方のアプリが同じ道案内を表示できる。
新しい Passbook アプリ（2012 年 9 月 20 日の記事“Passbook の本当の価値はまだ先（恐らく）”参照）は、パスを管理するライブラリとして機能する。（一般的にパスとは金品に換えられるチケットやトークンのことだ。）ベンダーたちは電子メールまたはブラウザを通じてパスを提供できる。いろいろなアプリも、Passbook とやり取りすることによって、パスを作成したり削除したりその他管理することができる。iOS 5 の Twitter フレームワークはどんなアプリにも tweet の送信ができるようにしたが、同様の機能が Facebook や Weibo にも拡張された。また、アプリが Reminders アプリとやり取りすることもできるようになった。これらの拡張されたパワーを利用するさまざまのアプリが登場してくることが，今後期待できるだろう。また、Game Center や、アプリ内購入物の配送にも改善がみられることだろう。
それからまた、iOS 6 の走る iOS デバイスでは、さまざまのアプリがあなたの各種の情報ライブラリにアクセスする際に用心深さを増していることにも気付かされるだろう。私はずっと以前から悲しいほど皮肉なことだと思っていたが、「サンドボックス化」されたとされる iOS の世界において、アプリがユーザーの写真ライブラリにある写真を表示しようとするためには、ユーザーの明示的な承認を得なければならない。それは、その画像が GPS 座標を含んでいるかもしれず、GPS 座標とは尊くも侵すべからざる位置情報なのだから、というあやふやな根拠によるものだ。ところがどんなアプリも、ユーザーの知らないところで、あなたの連絡先情報のライブラリは完全に自由勝手に処理することができてしまう。そこにあるすべての電子メールアドレスをウクライナにあるサーバに中継することも自由だし、すべての電話番号をピッツァ配達サービスを呼び出す番号に変えることも、あるいはバッサリとすべてのデータを消去してしまうこともできる。けれども iOS 6 では、アプリがライブラリに初めてアクセスを試みた際にユーザーに通知が出されるようになり、位置情報サービスで従来そうであったように、すべてユーザーが自由にそのアクセスを許可したり拒否したりできるようになる。
箱いっぱいのおもちゃ -- ここは、私に欲張りで身勝手な子供になってプレゼントの包装紙を破りちぎっているような気にさせるところだ。ツールボックスにピカピカの新しい変更点がいくつも施され、開発者たちが楽しく遊べるよう Apple が与えてくれたインターフェイスウィジェットのレパートリーも増えた。ねえ Apple さん、今年のプレゼントは何を持って来てくれたの？？
アプリのインターフェイスに最も大きなインパクトを与えるであろうメジャーな新ウィジェットは、collection view だ。この collection view というのは、テーブル（図表）表示に筋力強化を施したようなものだ。テーブル表示にはいくつものセルがスクロールするカラムとして表示されるが、これはリストを表示する必要のある多くのマスター/詳細表示のアプリに一般的に見られるものだ。Settings、Mail、Music などがお馴染みの実例だろう。これに対して collection view は、上下にスクロールするたった一つのスクロールするカラムという制約を破り、データの行を左右にスクロールしたり、複数のカラムを持つテーブルを作ったり、情報が縦横のグリッドに沿って並んだりといったことが、たちまち実現できるようになると期待できる。
その種のことは従来も不可能ではなかったけれど、プログラマーの手でそのようなものを構築するのはかなり難しい仕事であった。とりわけ、情報が多数の行や列をなして並ぶように表示したい場合には困難だった。あらかじめ表示すべきグリッドを形作っておいてそれをユーザーがスクロールできる広大な表示にするなどということはどうやってもできなかったし、そんなことを無理にすればデバイスのメモリ不足に陥ってしまい、アプリがすぐに終了させられてしまうのが落ちだった。その代わりに、一度に一画面分ずつで作業をして、必要に応じて（つまりスクリーン上に表示されたものをユーザーがスクロールしようとする度に）データをロードし表示される分だけを形作る（そしてユーザーの目に触れなくなった部分はその都度メモリを解放する）という風にする必要があった。
テーブル表示では、プログラマーのために動的なメモリ管理が自動的になされる。だからこそ、テーブルは非常に長くなることが可能なのだ。けれどもその一方で、表示できるのは上下にスクロールするたった一つのカラムに限られている。左右にスクロールできるテーブルや（Photos アプリにあるような）スクロール可能なグリッドが欲しいプログラマーは、相当量の努力と創意工夫を注ぎ込めば一回限りのものとして作り上げることは可能かもしれない。でもそれは決して簡単なことではなく、とりわけデータの量がどんなものでも構わないようにそういうインターフェイスを作り上げた例はあまり見られなかったし、無理に作られたものも挙動がかなりぎこちなくなることがあった。けれども collection view は、こういった概念すべてを一般化することによって、簡単に取り扱えるものとし、効率的に実装してみせた。
その上、この collection view はレイアウトという概念を一般化してみせた。それにより、データを表現する線は普通のものである必要がなくなった。直線である必要すらないのだ！ Apple の WWDC 2012 ビデオにデモされているのは、collection view を利用して Cover Flow View を実装しているところだ。Mac OS X の Finder あるいは iTunes で見られるように、スクリーン上でスクロールしながら項目たちが歪められたりサイズを変えたりして登場する。そのビデオには、collection view を使って多数の写真を円弧に沿って並べて表示するところまで示されている。だから、今後 iOS 6 アプリの中で、非常に興味深いインターフェイスの基盤として collection view が使われることを期待してよいはずだ。
iOS 6 におけるウィジェットのその他の変更点の大多数は、iOS が既にしていることを合理化し運用を厳密化するために働く。それらは「新機能」というよりも、むしろ「まったく明らかなことであってずっと以前からしていなかったのが不思議なほど」と言える類いのことだ。例えば、iOS は Mail や iBooks で見られるようにテキストを複数の書式で描く方法を心得ているけれども、そのようなテキストを開発者たちがラベル、ボタンのタイトル、インターフェイス上にある編集可能テキストフィールドなどで使うことはできなかった。けれどもこれからはそれができる。デスクトップで利用できる各種の描画エフェクトも iOS で可能となる。例えば、画像のカラーを簡単に反転できるし、興味深いタイル張りパターンも増えるし、画像のトランジションを実行することもできる。ページ表示のコントローラはあからさまな「ページめくり」アニメーションを使わずにページを単純にスライドさせることもできる。多彩なカラーとカスタマイズ機能は iOS 5 で始まった（この点は私の前の記事でも触れた）が、これがさらに多くの基本的ウィジェットで使えるようになる。スイッチが単なる"ON" と "OFF" 以外の切替も（ようやく！）できるようになる。その他、ちょっと奇抜な見栄えのステッパーなど、他にもいろいろある。
目で見て違いが分からないような変更点も数多くあるが、それらは開発者たちにとっては大きな意味を持つ。例えば、ユーザーがデバイスを回転させた際に特定の表示がそれに応じて回転するかどうかについて開発者が指定する方法を Apple は変更している。あなたは知らないだろうが、これをするための古いアーキテクチャーは困難で融通の利かないものであった。けれども開発者たちはもちろんそれと知っていて、今回の変更を大歓迎することだろう。同じように、テーブル表示ではユーザーがセルをタップした際にそれをハイライト表示するかどうかを以前より簡単に開発者がコントロールできるようになったし、セクションのヘッダやフッタの管理もより効率的になった。さらにもっと内部の奥深くでは、iOS がクールなコレクションクラス (例えば NSMapTable など) を OS X から取り込むことができるようになったが、これはプログラマーのみが気に入ることのできることであり、実際プログラマーたちは大いに気に入っている。
進化する魔法 -- これらのインターフェイスの魔法を、iOS デバイスのエンドユーザーたちが単純にあたりまえのことだと受け入れてしまうのは簡単だ。デバイスはとにかく動くのだし、大多数のユーザーはそれがどのように動いているのかなど気にもしないだろう。けれども私が iOS アプリのインターフェイスと挙動を目にする際、私が常に反射的にとる行動はそのアプリが内部的に どのように 働いているのかを推測し、その魔法が どのように 達成されているのかを考えることだ。iOS の動作方法を開発者の観点から知れば知るほど、その魔法は さらに 印象の度を深めるのであって、決してその反対ではない。
iOS SDK つまりアプリをプログラミングするための開発者用ツールボックスは、最初の登場時点 (当時は iPhone SDK という名前であった) から既に革命的であり、Mac OS X の Cocoa をもとに、小さいスクリーンと遅いプロセッサ、少ないメモリ、何をするかの命令にユーザーの指先しか使えないことなどの限界を持つデバイスの上で使えるように、独創的な再考察を注ぎ込んだものであった。それ以来、施されたいろいろの変更はその大多数が漸進的なものであった。確かに、iOS は成長してきた。（だからこそ、私の本の第二版は初版に比べて 200 ページも長くなったのだ。）けれどもその中心にあったのは、毎回のリリースの度に iOS がよりクリーンに、より明快に、よりフレキシブルに、そしてより賢明なる構築へと、進化してきたことだった。ブロックとか ARC とかいったプログラミング言語の機能により、Objective-C はよりエレガントで、退屈な仕事の必要の少ないものになった。カスタム表示コントローラの封入や表示アピアランスのプロキシなどインターフェイスウィジェットの管理ツールにより、以前よりもクリーンかつ信頼性のある効率的なやり方で、従来は先見の明のあるプログラマーやデザイナーのみが危うげなハックを駆使して達成できたことを皆が実現できるようになった。
iOS 6 もその点は同じだ。あたかも木の幹が伸びるように、iOS 5 から成長を遂げた。以前より背も高く、枝の数も多くなったが、真に重要なのはその根がより深く、よりしっかりしたものとなったことだ。私の本の中で、私が機能の欠落や首尾一貫しないところ、Apple の論理的思考の中の欠陥個所などに対して苦情を述べている文章の多くは、もはや削除してもいい。iOS 6 の新機能とは何かって？ それは、開発者たちを幸せにしていることだ。そして長い目で見れば、彼らの作ったアプリがパイプラインをくぐって現われてくるに従って、それらのアプリが あなたを幸せにしてくれることになる。
コメントリンク13296 この記事について | Tweet リンク13296
文： TidBITS Staff: [email protected]
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
Things 2.1 -- Cultured Code が Things 2.1 をリリースした。同社のタスク管理アプリにおいて、OS X のリマインダーとの統合を改善してどのタイプのリマインダーを表示するかについてより多くのコントロールができるようにしている。このメンテナンスリリースではまた Daily Review リストの中の項目とやり取りするとキーボードショートカットが働かなくなることのあった問題を修正するとともに、プロジェクトに割り当てられた Today 項目を Today リストの一番上へドラッグするとプロジェクトの割り当てが消えてしまった問題も解消し、繰り返すプロジェクトにある項目が検索結果に含まれるようにし、Entourage 2008 電子メールメッセージへのリンクに（以前 Things 1.5 for the Mac で処理されていたように）電子メールの件名を表示するようにした。(Cultured Code からも Mac App Store からも新規購入 $49.99、無料アップデート、17.2 MB、 リリースノート)
Sandvox 2.6.7 -- Karelia が Sandvox 2.6.7 をリリースした。このウェブ出版ツールに、数多くのバグ修正を施したメンテナンスリリースだ。主な修正点は、出版の最中に起こっていたクラッシュの修正、リンクの処理に関するいくつかの問題点の解消、ホストの構成によってファイルが繰り返しアップロードされ続けることのあった問題の修正、時間が経つとタイプ入力が遅くなる問題の修正などだ。さらに、今回のリリースでは一つのページの上に複数個の Twitter オブジェクトを置けるようになった。(Karelia からも Mac App Store からも新規購入 $79.99、無料アップデート、29.6 MB、リリースノート)
Hazel 3.0.13 -- Noodlesoft が同社のファイルクリーンアップユーティリティ Hazelをバージョン 3.0.13 にアップデートし、コマンドラインに入力する際の隠れたデフォルトとして通知を通知センターへ移す "IgnoreGrowl" を追加した。このリリースではまたカスタムトークンを同じパターンの内部でドラッグした後でそのトークンが何度も繰り返し改名されてしまう問題を解消し、コマンド "Run rules on folder contents" が添付されたディスクの上にも利くようにし、Sort into Subfolder パターンの中で "other" 属性を使った際に起こったクラッシュを修正している。(新規購入 $25、無料アップデート、6.2 MB、リリースノート)
Airfoil 4.7.4 -- Rogue Amoeba が Airfoil 4.7.4 をリリースした。今回は Android 用の Airfoil Speakers (最近 公開ベータ版としてリリースされたもの) へのサポートを提供した。このネットワークオーディオストリーミングアプリは Apple TV (iOS 5.1 かそれ以降の走るもの) から Airfoil Speakers へ送られたオーディオへの対応も改善するとともに、環境設定で "Show Airfoil Only in the Menu Bar" を選択した際に起こったクラッシュを修正している。(新規購入 $25、TidBITS 会員には 15 パーセント割引あり、無料アップデート、9.1 MB、リリースノート)
Adobe Lightroom 4.2 -- Adobe が Lightroom 4.2 をリリースし、このプロフェッショナル用写真カタログ・編集アプリケーションに数多くの修正を施した。今回のアップデートでは積み重ねた写真が Grid 表示と Filmstrip の双方で隠されていたのを修正し、Facebook にビデオを出版する際の問題点を解消し、Lightroom の写真が Photoshop Elements の中で JPEG として編集できるようにし、Title および Caption の各フィールドで改行文字を入力すると Flickr へのアップロードが無効になってしまった問題を修正している。このリリースではまた 22 の新機種のカメラ（ただし Nikon D600 に対しては予備的サポートのみ）と 43 の新しいレンズへのサポートも追加している。(新規購入 $149、無料アップデート、407 MB、リリースノート)
Adobe Lightroom 4.2 へのコメントリンク:
OS X Mountain Lion 10.8.2 Supplemental Update -- Apple が OS X Mountain Lion 10.8.2 Supplemental Update をリリースした。新しいバージョン番号を要するほどには大きいものでないいくつかの個別の問題点に対処した、小さなアップデートだ。具体的には、特定の日本語文字が Mail で誤った表示になる問題を修正し、DVD Player がクラッシュする問題を修正し、ペアレンタルコントロールを有効にした場合にも Safari がセキュアなウェブサイトにアクセスできるようにし、64 GB を超える RAM を搭載したシステムが起動できなかった問題を修正している。(無料、26.65 MB、Mac App Store からも直接ダウンロードでも入手可能)
OS X Mountain Lion 10.8.2 Supplemental Update へのコメントリンク:
Mac OS X Lion 10.7.5 Supplemental Update -- Apple が Mac OS X Lion 10.7.5 Supplemental Update をリリースした。最近リリースされた Mac OS X 10.7.5 Lion に対する追加アップデートで、非常に小さいため独自のバージョン番号を与えるほどでもなかったものだ。このアップデートではたった二件の問題のみが解消されている。一つは Time Machine バックアップに非常に長い時間がかかることのあった問題、もう一つは開発者 ID で署名されたアプリケーションのいくつかが起動できなかった問題だ。これまで 10.7.5 をインストールしたことのなかった人はこの追加アップデートを気にする必要はない。最新のビルドの Lion 10.7.5 (11G63) には上記の二件の修正が既に組み込まれているからだ。(無料、2 MB)
Mac OS X Lion 10.7.5 Supplemental Update へのコメントリンク:
iPhoto 9.4.1 -- Apple が iPhoto 9.4.1 をリリースし、iTunes 経由での写真の iOS デバイス同期を改善するとともに、Facebook アルバムから同期した写真をダウンロードして表示する際の問題を修正した。このアップデートではそれ以外に二件の特定のクラッシュも修正している。一つは Export コマンドを使用中のクラッシュ、もう一つは複数のブック、カード、カレンダーをアップグレードしている際のクラッシュだ。iPhoto 9.4.1 が OS X Mountain Lion 10.8.2 または Lion 10.7.5 を要するようになったことにも注意しよう。(Mac App Store から新規購入 $14.99、ソフトウェア・アップデートまたは Mac App Store から無料アップデート、Apple のサポートページからの直接ダウンロードは 757.62 MB)
TidBITS は、タイムリーなニュース、洞察溢れる解説、奥の深いレビューを Macintosh とインターネット共同体にお届けする無料の週刊ニュースレターです。ご友人には自由にご転送ください。できれば購読をお薦めください。
非営利、非商用の出版物、Web サイトは、フルクレジットを明記すれば記事を転載または記事へのリンクができます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありません。
告示：書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。
TidBITS ISSN 1090-7017©Copyright 2012 TidBITS: 再使用はCreative Commons ライセンスによります。
, 
日本語版最終更新：2012年 10月 16日 火曜日, S. HOSOKAWA