TidBITS: Apple News for the Rest of Us  TidBITS#1064/21-Feb-2011

一つのテーマのある週もあれば、今週のように記事の内容に共通性のない週もある。まず、コンサルタント向けの MacTech Boot Camp カンファレンスに新たに四つの追加開催地が発表されたことをお伝えする。次に、Jeff Carlson が MacBook Pro オーナー必携のユーティリティ gfxCardStatus について書き、Glenn Fleishman が 2D コード用のアプリケーション QuickMark の Mac 版を概観する。さらに、私たちは最近 TidBITS News iOS アプリのバージョン 1.4 をリリースしたが、Matt Neuburg がその主要な新機能を取り上げてアプリにマルチタスキング機能を追加することが見た目ほど簡単でない理由を説明する。また、Adam は間もなく起こる舞台裏の変更(電子メール版の TidBITS に新しい From アドレスが使われること)をお知らせするとともに、その背景にあるマニア好みの技術的詳細に分け入る。最後に、Jeff Porten が .nxt カンファレンスからの報告記事として新たなトップレベルのドメイン名について語る。問題は、いまだにこんなことを気にする人がいるのかどうか、ということだ。今週注目すべきソフトウェアリリースは、Skitch 1.0.3、Digital Camera Raw Compatibility Update 3.6、Evernote 2.0.4、CopyPaste Pro 3.0、1Password 3.5.7、iWeb 3.0.3、それに Adobe Acrobat/Reader 10.0.1 だ。

記事:

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

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


MacTech Boot Camp が四都市を開催地に追加

  文: Adam C. Engst <[email protected]>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

先月サンフランシスコで開催された MacTech Boot Camp は成功裏に終わったようで、一日のみ開催のこのカンファレンスの入場券は売り切れ、出席者たちも講演者たちも、一様に肯定的な声を挙げていた。(ただし、どうやら会場には鬼軍曹もいなかったし、腕立て伏せを命令されることもなかったようだ。)[訳者注: ブートキャンプ (Boot Camp) とは米軍海兵隊の新兵訓練プログラムのことで、転じて一般の短期集中トレーニング講座などにも使われます。]その成功をもとに、MacTech は今回、追加の Boot Camp カンファレンスをコンサルタントやサポート担当技術者のために全米各地で開催すると発表した。新たに発表されたイベントは次の通りだ:

こうして新たに別の場所、別の日程で追加開催されることは、最初の MacTech Boot Camp とそれに引き続いた Macworld 2011 のためこの 1 月にサンフランシスコに旅することのできなかった人たちにとって歓迎すべきニュースだろう。

MacTech はそれぞれのカンファレンスごとにセッションの議長の名前を発表した。これら四つのカンファレンスは全く同一のセッションが並ぶわけではないが、互いにおおまかに言えば 類似のテーマをカバーしており、扱われる主要な題材としては、クライアント処理、電話サポートのテクニック、遠隔サポート、バックアップシステム、Mac 上の Windows、ネットワーキングの基礎とトラブルシューティング、自己マーケティング、扱いにくい問題に対する解決法を探す情報源、などがある。

一日のみ開催のカンファレンスの入場券は $495 で、早期登録すれば特別価格の $295 となる。

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


QuickMark が、2D コードを Mac へ持ってくる

  文: Glenn Fleishman <[email protected]>
  訳: 柳下 知昭 <tyagishi@gmail.com>

URL やアドレスカード、位置情報、プレーンテキストの情報を持つ2 次元タグを、新しい QuickMark のリリースによってMac OS X 環境でも簡単に解読することができるようになった。$2.99 の QuickMark は、標準 2D コード(QR コードと Data Matrix)と、独自の Quick Code フォーマットとを読むことができる。これらのコードは、新聞・雑誌・広告・小売りされているグッズなどで、見られることが次第に増えてきている。(複数のデバイスをまたいで URL を転送して記事を続けて読むことができるように、我々も TidBITS の記事の最後に QR コードを付けている;"タグよ、君は 2D になった!" 2009 年 10 月 1 日 参照のこと)

Image

QuickMark と同名の Mac プログラムは、Mac App Store 経由でリリースされていて、3 つの機能がある。(内蔵された iSight、FaceTime もしくはサードパーティの)カメラを使用することで、2D タグを認識して、アクションを実行することができる。このことには、URL をブラウザで開いたり、電話や SMS を送信するために Skype に切り替えたり、Google Maps を使用して位置を表示するためにブラウザに切り替えたりすることを含んでいる。入力したテキストから、読み取ることができる任意 2D コードを生成することができる。最後の機能として、スキャンするウィンドウにイメージをドラッグしたりメニューからイメージを選択したりすれば、QuickMark がイメージに含まれる 2D タグを解読する。この Mac App は、書籍についている ISBN のような1D のバーコードを読み取ることはできない。

image

QuickMark の $0.99 の iOS アプリ を iPhone で2D コードを読み取ったり生成したりするために非常に快適に、何度か使用してきた。これらのコードは、日本では 10 年近く前から携帯電話会社や携帯電話機メーカ、広告会社、出版社が協力して広く使用されている。それらがとうとう米国にもやってきた:店のウィンドウに目立つように陳列されているのを見ない日や、新聞や雑誌の広告でそれらを見ない日、訪れたウェブサイト上でそれを見ない日は、1 日たりともない。昨日、郵便で受け取ったちらしにさえコードはあった。(この iOS アプリは1D のコードも読むことができる。)

残念なことに、Mac 版は開発者が Max OS X を熟知していないことを露呈してしまっている。2D タグを生成するためのテキストフィールドにペーストすることができないし、ついでに言うと、コピーやペーストも全くできない。テキストを入力することやブラウザのアドレスバーからドラッグしてくることはできる。しかし、これらの制約を修正することは簡単なはずだし、ユーザーからのフィードバックがQuickMark が修正をすることに役立つと思う。

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


フィルタのチェックをどうぞ: TidBITS 号の From アドレスを変更

  文: Adam C. Engst <[email protected]>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

TidBITS ウェブサイトに出される私たちの記事を集めた、毎週の号を配布するための無料のメーリングリストを購読しておられる皆さんに、お知らせがある。メーリングリスト管理上のことなのだが、私たちが電子メールを発送する方法で一点変更される個所があるのでご注意申し上げたい。次週の TidBITS #1065 以降、私たちが号を電子メールで発送する際の電子メールヘッダが若干変わる。これは私たちの予定にはなかった変更だが、新しくなった私たちのシステムで電子メールのバウンス処理をするために必要となったことだ。

この事前警告を私が書いている理由は、もしもあなたがお使いの電子メールソフトウェアのスパムフィルタで [email protected] から届いた電子メールをホワイトリストに入れているのならば、私たちのドメインにある別のアドレスから届くことになる来週の号が、スパムとマークされる可能性があるからだ。もしも来週 TidBITS の号が到着しなければ、おそらくそれが理由だろう。その場合、お使いのスパムフィルタを調べてみて頂きたい。また、もしもあなたが TidBITS の号を別のメールボックスに自動的に移動させるため電子メールの From 行に [email protected] が含まれることをチェックするルールを利用している場合は、その部分にも変更を加える必要がある。余計なお手間を取らせまして、申し訳ありません!

理想の世界においては、私たちが適切な変更を加えるだけですべてがうまく行き、皆さんの側では何もする必要が生じないことだろう。けれども、いわゆる「マーフィーの法則」が今も生き残っているのだとすれば、どうか皆さんの側でも以下のことを知っておいて頂きたい。

来週号の TidBITS は、いずれのバージョンについても、その From 行が従来の [email protected] から、新しい [email protected] に変わる。つまり、新しい From 行は次のようになる:

From: TidBITS Editors <[email protected]>

この [email protected] というアドレスを、特定の送信者からのメッセージをホワイトリスト(自動的に正当なメッセージとして受け入れるもの)に入れるようになっているスパムフィルタへと追加することができる。けれども、TidBITS の号をフィルタ分けして別のメールボックスへ自動的に移動させるようにするためには、もっと良い方法がある。そちらの目的のためには、私は List-Id ヘッダに依存したルールを使うことをお勧めする。私たちのメーリングリストでは、TidBITS の個々のバージョンごとに別々のヘッダが使われる。メッセージで「すべてのヘッダを表示」すれば、あなたがどのバージョンを受け取っているのかが分かる。

List-Id: TidBITS Text Issue List <text.issue.tidbits.com>
List-Id: TidBITS HTML Issue List <html.issue.tidbits.com>
List-Id: TidBITS Text Announcement List <text.announce.tidbits.com>
List-Id: TidBITS HTML Announcement List <html.announce.tidbits.com>

Reply-To 行も変わる -- 来週変わるもう一つのことは、各号のヘッダの中の Reply-To アドレスだ。新しいアドレスは人の目に見える形では登場しない。その代わりに、いろいろの異なった目的ごとに私たちへ連絡する最も良い方法を説明した自動返信メッセージが生成されてあなたに送られるようになる。

何のために自動返信をするのか? 実のところ、私たちへ連絡できる異なった手段は多数あって、そのうちどの方法が最も適切なのかは、状況によるからだ。例えば、記事のどれかにコメントをしたい場合には、私たちあてに電子メールを送るのではなく、その記事自体にコメントを残して頂きたい。また、本当に遠慮深い方は、それぞれの記事の筆者の名前欄のすぐ横にあるリンクを使えば、いつでも直接筆者に電子メールを送ることができる。あるいは Twitter を使って連絡する(私たちの Contact Info ページにスタッフの詳細情報がまとめてある)ことも可能だ。

もしも私たちのウェブサイトあるいは電子メールの号に何か問題があれば、まずは TidBITS Get Satisfaction サイトに質問を投稿して頂ければありがたい。それならば私たちも返答を公開することができ、同じような問題に遭遇した他の人たちの役にも立てるかもしれない。もしもその問題が私が緊急に知るべきものだと思われれば、Twitter で私に呼びかけて頂きたい。

他方、あなたの購読アカウントに関する質問については、何かの援助ができるためには私たちがあなたの電子メールアドレスを知る必要があるので、公開の討論の場である Get Satisfaction サイトよりも、個人的な電子メールによる通信の方が適している。(この点は Take Control 電子ブックについても同じことが言える。一般的な質問や提案は Take Control Get Satisfaction サイトに書き込んで頂きたいが、個々のアカウントに関する質問は、個人的な電子メールで送って頂きたい。)

それから、特定の TidBITS 記事とは無関係な、あるいは TidBITS 自体とも無関係な、何か技術的質問があれば、おそらく私たちの TidBITS Talk 討論リストに投稿するのが一番良い方法だろう。ただし、激しく押し寄せ続けるスパムをブロックするため、現在 TidBITS Talk に投稿できるのは購読者のみに限らせて頂いている。

背後にいるのは MTA -- 次に述べたいことは非常に個別的な話題だが、これに関する状況に驚かされたこともあるので、ここに私たちが気付いたことを書き留めておきたい。これが、同じような問題に遭遇した人たちのお役に立てればと思う。(MTA (Mail Transfer Agent, メール配達エージェント) とは何のことか知らない、メールサーバの動作の仕組みなど知りたくもない、と思われる方は、以下の部分をお読み頂くには及ばない。)

以前、私たちが Web Crossing を使用していた頃は、Web Crossing がメーリングリスト用ソフトウェア(つまり送信すべき実際のメッセージを生成する部分)と、メール配達エージェントつまり MTA の、双方の働きを兼ねていた。そのため、一人で二役をこなしていた Web Crossing が、個々のメッセージのヘッダをカスタマイズすることによってバウンスして来るメールを識別して処理することができていた。具体的には、Web Crossing では次のようなカスタマイズされた Return-Path ヘッダを追加することができた:

Return-Path: <[email protected]>

重要なのは、そのヘッダにあるアドレスが、From 行のアドレスとは別のものであったことだ:

From: "TidBITS Editors" <[email protected]>

ところが問題は、Return-Path ヘッダを挿入できるのは MTA のみであるという事実だ。私たちの新しい自前の TidBITS Publishing System はメーリングリスト用ソフトウェアとしてのみ挙動し、発送すべきメッセージを sendmail に(ライブラリ経由で)手渡して、その後 sendmail が Return-Path ヘッダを自動的に、そのメッセージの From ヘッダに基づいて生成して挿入することになる。こうして、Return-Path と From の双方ともに [email protected] と記載される。もちろん、sendmail の設定を変えて別の Return-Path ヘッダを挿入するようにするということもあり得るのだろうが、私たちが sendmail を TidBITS Publishing System と接続させるために使っているライブラリではどうやらそれができないようなのだ。

私たちはずっと以前から From アドレスに [email protected] を使っていて、今回の新しいシステムでも当初はそのままにしていたので、新しいシステムが動き出したとたんに、バウンスで戻って来るメールが Errors-To ヘッダで指定されたアドレスでなく [email protected] に届くようになったのを見て私たちはちょっとショックを受けた。その後分かったのは、Return-Path は標準規格であるが Errors-To は必ずしもそうではなく、場合によって働くことはあるけれどもいたる所で常に働くわけではないということだった。

いずれにしても、解決法は単純だと思う。バウンスして戻って来たメールを私たちが適切に受信して処理できるアドレスが Return-Path に複製されて付けられるように、From 行にそのアドレスを設定しておけばよいのだ。ただ、きっと以前から多くの人たちが [email protected] というアドレスをホワイトリストに入れたりそれに基づいてフィルタを作用させたりしているだろうということに思い至ったので、こうしてこの記事を書いて、そのアドレスが新しいものに変わることをお知らせしているわけだ。これでお分かり頂けただろうか?

以上でお知らせは終わりだ。では、いつも通りの TidBITS 号にお戻り頂こう。

[訳者注: この記事の内容は、英語版の TidBITS の電子メール購読についての話です。TidBITS 日本語版の電子メール配布は、これと類似の、しかし別名のメーリングリストList-Id: TidBITS Japanese <tidbits-jp.tidbits.com>を使っています。]

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


MacBook Pro の電池寿命を gfxCardStatus で伸ばす

  文: Jeff Carlson <[email protected]>
  訳: 亀岡孝仁<takkameoka@kif.biglobe.ne.jp>

私はほぼ三年毎に私の MacBook Pro を新しいモデルと入れ替える。このサイクルだと各々のモデルを十分に使い込むことが出来るが、途中のモデルに現れた機能にいきなり飛び込むことにもなる。

去年、新しい MacBook Pro (2.66 GHz Intel Core i7 プロセッサ搭載) を買った時もびっくりの誕生祝のようであった:格段に良くなった電池寿命、全幅のマルチタッチのトラックパッドジェスチャー、アルミのユニボディ構造 (自分でも驚いているのだがこれが一番気に入った機能の一つである - 前のモデルに比べればものすごくしっかりした感じがする)、そして高精細度の LED スクリーンが売りである。

更にこのラップトップには二枚のグラフィックスカードが含まれている (GPU, graphics processing unit と称される):組込みの Intel HD Graphics と独立した Nvidia GeForce GT 330M である。前者は低消費電力を目的に設計されていて、結果として電池寿命も改善される。一方後者は必要な時にグラフィックスの処理能力を提供するために投入される。

初期の dual-GPU MacBook Pro は、Energy Saver 設定ペインでどちらのグラフィックスモードを使うのかを指定し、そして一旦ログアウトし再度自分のアカウントにログバックする必要があった。2010年中期モデルからは、この切り替えは自動的になされる:グラフィクスパワーがより必要とされるアプリケーションが起動されると独立の Nvidia GPU に火が入るというわけである。そうでない時は、組込みの Intel GPU が電池の電力を浪費することなくグラフィックスを提供する。(この自動切り替えを設定ペインでオフにすることも可能で、その場合は Nvidia チップは火が入ったままとなる。)

私は自分の机から離れて仕事をする時は、電池寿命を最大限伸ばして使いたい。当然のことながら、Photoshop, iPhoto, 或いは iMovie と言った GPU バカ食いのアプリは閉じるようにしているが、私の MacBook Pro が既に組込みの GPU に切り替えているのかどうかを簡単に知ることは出来ない。

どちらの GPU が動いているのかを知るには、System Profiler アプリケーションを開いて (Apple メニューから Option を押して System Profiler を選択する)、サイドバーの Hardware の下にある Graphics/Displays アイテムをクリックし、そして Intel 或いは Nvidia のビデオカードを選択する。現在使用中のものは Main Display: Yes の表示を含んでいる。

image

そこで、私はまず最初から明らかなアプリケーションを閉じ、System Profiler に戻り、Command-R を押してデータを更新し、それから "Main Display: Yes" が Intel GPU に現れるかどうかを見てみる。これをやっていると、Mac OS 8 でスタートアップエクステンション間の不整合を探さねばならなかった時代に戻されたような感じがする。

しかしながら、Nvidia GPU は、伝統的にはグラフィックス食いとは思われない様なアプリケーションによっても起動されることが分かった。例を挙げると、大抵の Twitter クライアント、そして筋金入りの Fetch (ひょっとすると進行を示す走る犬のアニメのせい?) までもがそうなのである。勿論、Nvidia GPU を使っている時でも私の古いラップトップよりはこのマシンでは電池の持ちはずっと良いのは確かであるが、だからと言って低消費電力の組込みグラフィックスの恩恵を受けたくないというわけではない。

最初、私は Cody Krieger の無料の gfxCardStatus 2.0 をインストールしたのだが、これはどちらの GPU が動いているかを示すメニューバーアイコンを追加してくれるからであった:単純な "i" が Intel (或いは "integrated") を "n" が Nvidia を示す。これだけでも多くの時間とイライラを節約できた。

しかしすぐに、そのアイコンをクリックすると gfxCardStatus は親切にも、どのアプリケーションがこの独立の GPU が動くように強制しているのかも暴いてくれることに気付いた。それは Dependencies の下にリストされる。

Image

このユーティリティは単にレポートするだけに留まらない。MacBook Pro が単に組込みの Intel グラフィックスだけを使うのか、個別の Nvidia グラフィックスだけを使うのか、或いは動的な切り替えのままにするのかを強制する設定が、メニューの中のオプションの一つを選択するだけで可能になる。

アプリケーションの中には、独立から組込み GPU への実時間での切り替えにうまく反応しないものも存在する。例えば、BusyCal は Intel だけのモードに強制されると月の間で動く能力を失ってしまう。しかしながら、これも BusyCal を終了し再起動してやればこの問題は解決される (その理由は、このソフトウェアは MacBook や Mac mini のような組込みグラフィックスしか持たないコンピュータとも働かなければならないからである)。

gfxCardStatus 2.0 は December 2010 にリリースされたのだが、有用な新機能が追加された:電池で動作しているのか AC 電源で動作しているのかによって GPU を切り替えることが出来る。旅先で仕事をしていて電池寿命を最大限使いたい時など、組込みグラフィックスを自動的に強要することも可能になる。この機能は、デフォルトでは不能にされている、それは切り替えがうまくいかないアップスでの問題を回避するためである。

image

私は、組込みと独立のグラフィックスを走らせることに関する違いについて実際に計測したことは無いが、Mac OS X のメニューバーアイテムで知ることが出来る電池の残量見込みを見ていると、電池で走らせていて依存型のアプリケーションを全て終了した場合明らかに伸びる (一時間程度まで)。

gfxCardStatus は最近の次の MacBook Pro モデルで働く:

gfxCardStatus は極めて狭い隙間を埋める商品であることには間違いないが、これはあなたの MacBook Pro の充電エネルギーから最大の時間を引き出す優雅で、有用な方法である。

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


TidBITS News アプリ 1.4 でバックグラウンドオーディオが可能に

  文: Matt Neuburg <[email protected]>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

私たちは、 TidBITS News iOS アプリの新バージョン (1.4) をリリースしたばかりだ。今回はバグ修正が二件(いずれも皆さんの目にはあまり留まらないもののはずだ)と、新機能が一つ加わっている。この新機能はちょっと微妙なものだが、何人ものユーザーから希望が寄せられていたことであり、これが実現したことによって嬉しく思う人たちはきっと多いだろう。まずは、この新機能について説明して行こう。これはオーディオに関係したことで、TidBITS News アプリと他のアプリとの相互作用に関するものだ。

ご存じかもしれないが、この TidBITS News アプリでは私たちの記事の朗読を録音したオーディオ版を再生することができる。(これは、ポッドキャストとして iTunes で購読できるものと同一のオーディオ版だ。)TidBITS News は独自にオーディオを再生する機能を持つので、他にバックグラウンドのオーディオがあった場合にどうするかをシステムが判断できるようにするため "audio session policy" を宣言しておかなければならない。これは、マルチタスキングが実現されるより以前の iOS 3.x の下でさえ必要とされたことだ。なぜなら、iPod アプリ(機器によっては Music アプリとも呼ばれる)が、そのシステムでもバックグラウンド音楽の再生ができたからだ。

TidBITS News は、独自にオーディオを再生するだけなので、またこれは元来 iOS 3.x 用に書かれたものであったので、その audio session policy は非常に素朴な方法でなされた。つまり、このアプリを起動する際にすべての他のバックグラウンドオーディオを中断するようにしたのだ。確かに、それは理想的なやり方とは言えなかった。なぜなら、あなたが大好きな曲を iPod アプリで聴いている最中にもしもあなたが私たちのアプリを起動させれば、たとえあなたが一切録音記事の朗読を聴くつもりが無かったとしても、必ず音楽が中断されてしまうからだ。明らかに、録音された記事を聴こうとした場合にのみ audio session policy が実行に移されるようにしておいた方が望ましいだろう。私たちはこの問題に気付いていた(とりわけ、このアプリの何人ものユーザーから、この問題を指摘する意見が届いていたのだから)けれども、当時はすぐに取り組まなければならないほど優先度の高い問題ではなかった。

しかしながら、iOS 4 の登場によって、audio session policy を指定するための新たな方法が導入されるとともに、他のアプリ(例えば Pandora など)が続々とバックグラウンドのオーディオを再生する機能を備えるようになった。つまり、明らかにこれは状況を正すべき時が到来したことを意味していた。いくつか実験を重ねた結果、私たちのアプリの audio session policy を、あなたが記事の録音を聴き始める時点で変更し、録音を聴き終えた時点で元に戻すようにすることが実際に可能だと分かった。事実、それをするために二つの異なった方法が存在していた:

こうして、完璧に動作するけれどもユーザーが同時に二つのものを聴きにくくなってしまうかもしれないという選択肢と、中途半端にしか動作しない選択肢との間で、選ばざるを得ないことになってしまった。私たちは、後者を選んだ。記事の録音は長時間にわたることもあり、重要な内容のこともあるので、実際のところ「ダッキング」はふさわしい解決法とは思えなかったからだ。これがもしも例えばナビゲーションアプリから次の交差点の接近を知らせる短いオーディオ警告を出すようなものだったとしたら、「ダッキング」が理想的な解決法となっていただろうが。それに事実、既存のバックグラウンドオーディオが中断後に確実に再開できないという問題もそれほど深刻なものとは言えなかった。なぜなら、マルチタスキングの世界においては、ユーザーが手動で問題を是正することがそれほど難しくないからだ。

そういうわけで、これが、誰の目にも分かる TidBITS News 1.4 の新機能だ。あなたがこのアプリに入っても、それまで再生中であったオーディオは、そのまま続けられる。もしもあなたが私たちの記事のどれかを録音したものを聴こうと思えば、それを聴き始める際に既存のバックグラウンドオーディオが中断させられ、もしもあなたが信じられないほど幸運なら、記事の録音を聴き終えた時点でそれがまた再開するだろう。けれども、もしも再開しなくても、ただ iOS 4 のマルチタスキング機能を使って、手で再開させればよいだけだ。次のようにすれば手軽にそれができる:

  1. Home ボタンを二度押しして、アプリ切替のインターフェイスを出す。
  2. アプリ切替部分を右へスワイプする。すると左側に隠れていたものが出てくるが、そこにサウンドコントロールのボタンもある。
  3. 再生/一時停止のボタンをタップして、バックグラウンドオーディオを再開させる。
  4. TidBITS News のインターフェイスの中のどこかをタップすれば、アプリ切替のインターフェイスが消える。

ユーザーの立場から言えば、この新機能に関して気付くことは以上ですべてだろう。けれども開発者の立場から言えば、このような変更を達成するのは極めて困難なことであった。手を付けてみて分かったことだが、私たちの従来の audio session policy は単に気に障るものであったのみならず、マルチタスキングの到来のおかげで実際壊れていた。私たちは起動時にサウンドをオフにしていたのだが、ユーザーが私たちのアプリからいったん離れてからまた戻って来た際にはサウンドをオフにして いなかった。だから、ユーザーが私たちの厄介な audio session policy を叩き壊してしまうことも実際に可能となっていた。これはまさに、遡ること何ヵ月も前、iOS 4 とマルチタスキングが初めて登場した際に私が記事で指摘したことであった。(2010 年 6 月 23 日の記事“高速アプリ切り替えとは何か?”参照。)つまり、自分の書いたアプリがただ単にマルチタスキングに参加できるようにするだけならば、何でもないことだ。それにはただ現行バージョンの Xcode を使ってアプリをコンパイルし直すだけでよい。でも、自分のアプリがマルチタスキングの下で 正しく挙動する ようにするのは難しい。

厄介なのは、自分のアプリがマルチタスキングし始めたとたんに、それまではうまく行っていたことが、次々にわが耳のまわりでがらがらと崩れ落ち始めることだ。その理由は、マルチタスキングのおかげで、ユーザーがそのアプリを離れたりまた戻って来たりできる新たな方法が多数導入されたからだ。マルチタスキングの登場以前には、TidBITS News に到達する方法はただ一つ、つまりそれを起動することしかなかった。また、それを離れる方法もただ一つ、つまりそれを終了させることだけだった。だから、私たちのアプリを起動するとバックグラウンドのサウンドが止まってしまうのは確かに困ったことではあったけれど、少なくともマルチタスキングの無い世界においては明確で決定的な事実であった。ところが、マルチタスキングの下では、ユーザーがさまざまに変わったことをすることが可能になる。別のアプリに切り替えてからまた私たちのアプリに戻って来たり、アプリ切替のインターフェイスを呼び出しておいてまたすぐに私たちのアプリに戻ったり、その他いろいろのことができる。結局判明したのは、自分の作ったアプリが必ずそのようなすべての可能性に積極的に対処しなければならず、そのためにはあらゆる場合に対してそれぞれに応じた audio session policy をきちんと定めておかなければならない、ということだった。でも、TidBITS News アプリにはそれができていなかった。

そしてそれこそ、実際、今回私たちが audio session policy を変更した理由だ。私たちの真の動機は、バックグラウンドで音楽を聴いているユーザーたちに親切にしたいということではなかった。(結局のところ、私たちの記事を読んでくださるなら、しっかりそれに専念して読んで頂きたい!)私たちがそれをしたのは、そのままでは audio session policy が正しく働いていないという事実を発見したからだ。実際、今回私たちの audio session policy とその挙動を変更したことは、マルチタスキングという多頭の怪物に直面した以上、このアプリの動作をそれと統合させなければならないという、非常に緊急の変更要請に応えようとする私たちの努力の一環に過ぎなかった。

Apple の出している書類のどこを見回しても、「おーい君たち、もしも君のアプリがマルチタスキングの使用に踏み切るなら、注意しろよ! 陥りやすいポイントの一覧表をここに書いておくからね、サウンドの問題もその一つだよ」などと書いたものはどこにもない。でもそういう説明はぜひ必要だ。私たちの場合、マルチタスキングは私たちの audio session policy を壊してしまったけれど、当初私たちはそれに気付きもしなかった。世の注目を集めているあの Apple の App Store 認可過程でさえ、一言もこの事実を私たちに警告してくれなかった。おそらく、このことはピンからキリまであらゆるアプリに当てはまることだろう。おそらく多くのアプリが、iOS 4 SDK 用にリンクを付け直して再コンパイルしただけで、場合によってはそこに終了時保存に変わるバックグラウンド時の状態保存程度のことを追加しただけで、自分がマルチタスキングに対応したと 思い込んで いるのだろう。けれども、マルチタスキングというのはそれよりもずっとずっと複雑なものだ。それなのに、安全なるマルチタスキング市民となるための易しい手段を Apple は未だに提供していないし、どうすればそうなれるかを発見できる手助けもしていない。

そうそう、今回のリリースでは他に二件のバグ修正があったのだが、その内容は何かというと、一つは、単なる古き良きタイプのうっかりミスだった。私たちの記事の中にある画像が、iPhone ではきれいに見えていても、サイズの大きな iPad のスクリーンで見ると正しいサイズで表示できていなかった。これは、アプリを iPad でネイティブに走るよう変換した際(2011 年 1 月 4 日の記事“TidBITS News アプリが iPad 用にアップデート”参照)に見落としてしまった点だった。もう一つは、メモリ不足の状況下でよく分からない理由で表示がおかしくなることのある問題に対して対策を施したことだ。運が良ければ、あなたがそのような問題に遭遇することはないかもしれない。(私たちスタッフは誰も経験していなかったので、その問題に気付いていなかった。)でも事実を言えば、この問題が本当に解消されたわけではない。完全に解消されるには、私たちがこのアプリのコードを完全に切り分けて、すべてを一から書き直す日が来るまで待たなければならないかもしれない。

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


新しいトップレベルドメイン、これって気にすべきものか?

  文: Jeff Porten <[email protected]>
訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

次なるインターネットの大改革が近づきつつある。その通り。今後二年くらいの間に、現状の例えば britneyspears.com のようなおそろしく難しい URL を覚えるよう強制されることはなくなり、代わりにそれよりずっと易しいウェブサイトの名前、例えば britneyspears.music などが使えるようになる。

あんまり大改革のようには聞こえないって? そう、私もあなたと同意見だ。でも、そうは思わない人たちもいて、その人たちにとっては何もかもが大きく変わるのだ。

すべての邪悪の根源 -- 私は .nxt カンファレンスの尻尾をつかまえた。これは、新しいジェネリックトップレベルドメイン (gTLD) をめぐる「インターネットのランドラッシュ (土地取り争奪戦)」に参加したいと願っている企業のためのイベントだ。トップレベルドメイン (TLD) とは、URL にあるドメイン名の中で最後のドットの後に来る部分、例えば "com"、"net"、"org" といったものだ。(おそらく、この三つがあなたのこれまでのウェブサーフィンの経験上最も多かっただろう。)この TLD は三種類に分類される。国別コードのトップレベルドメイン、ジェネリックトップレベルドメイン、それと残りいくつかの技術的ないし実験的なトップレベルドメインだ。その中でジェネリックトップレベルドメインは米国発祥のものであって、1990 年代中頃に商用目的のインターネットが動き出すまでの時代は、米国内に限られていた。米国以外でドメインを得たい者は、国別コードの TLD に依存するしかなかった。

その結果として、現在もまだ残る歴史的不均衡が生まれた。米国内にある大手のチョコレートメーカーは http://www.hersheys.com/ で見つかるが、英国の大手の製菓会社は http://www.cadbury.co.uk/ という形に依存しなければならない。眼力のある読者ならば、".com" の中に特にアメリカが内在しているわけでないことにお気付きだろう。アメリカの URL のトップレベルが、国全体でなく、アメリカの中にある団体を集めたカテゴリーとなったことを、私たちは当然のように受け取っている。その後、.com は世界中のあらゆる企業を対象にしたデフォルトのドメイン名となり、さらにその後、自分のウェブサイトが「普通の」アドレスを持つようにしたいと思えば(必ずしも商用でなくとも)基本的に誰でもこれが使えるようになった。

ここでちょっと空想をめぐらせて、もしも突然世界中の誰もが声を揃えて自分の電話番号を 6 で始まるものにしたい、そうでない番号は駄目だ、と要求したとすればどんな馬鹿げたことになるか、想像してみよう。インターネットでは基本的にそれが起こっているのだ。最近十年以内のどんなブラウザでも(ただし統合検索バーが装備されているものを除く)何でも好きな単語を入力したとして、もしもサイトが見つからなければ、きっとそのブラウザは自動的にその単語の後に .com を追加してそれがあなたの見たかったサイトかどうか示してくるだろう。

この点はずっと以前から多くの評者たちから指摘を受けてきた。ほんのちょっぴり奇妙だと指摘する人から、これは世界の諸国に対する米国覇権による攻撃の一形態だと評する人までいた。ここではアメリカの団体が Animal Farm[訳者注: ジョージ・オーウェルの小説、邦題は「動物農場」]で言うところの「同輩中の首席」となり、その上、ドメイン名システムに長らく巣食ってきたアクセント付き文字が名前に使えない問題がさらにそれに輪をかけた、というのだ。英語に登場しない文字の使用に関する問題はこれまでに部分的に解決した(TLD についてはまだ解決したとは言えない)が、より大きな問題、つまり世界中の指向が .com という空間に集中している問題は、未だに未解決問題の帳簿に載ったままだ。

いやつまり、もしもそれが本当に問題ならばの話だ。

あなたのドメインのご主人は -- ドメイン名の作成と管理は、Internet Corporation for Assigned Names and Numbers (ICANN) が担当している。この非営利団体は、世界中の政府、技術的団体、それからすべてのインターネット市民のために、いわば国連のような役割を果たそうと努めている。この団体の組織構成は非常に単純明快で、下の図表に示されるようになっている。

image

私はよく ICANN を冗談の種にする。そして多くの場合、ICANN はまさしく冗談とされるに値するものだ。けれども考えてみれば、ICANN がしなければならないことと比較すれば上の図表もそれほど複雑なものとは言えない。誰かが、www.apple.com を 69.192.205.15 に読み替えるシステムを管理する仕事をしなければならない。その誰かとは、定義に従えば、グローバルな支持者層だ。そしてこれもほぼ定義通り、グローバルな支持者層とは、必ずしも意見の一致をみるものではない。例えば言論の自由とか、誰がインターネットへのアクセスと出版を許されるかとか、そういった点でグローバルに意見がまとまることはない。

ICANN には、.com 問題を解決するという仕事があった。そして、彼らがそのためにした方策が、gTLD の開放だ。どんな団体でも、gTLD の獲得を申請することができる。それは基本的に .com と同等のものを要求することを意味していて、そこからその団体は自分のサーバ(と銀行口座)が処理できる限り任意の個数のドメインをそのトップレベルドメインに割り当てることが可能となる。既に 100 を超える数のグループが申請を済ませたと言われ、2011 年 10 月に全リストが公表されればさらに多くの申請が寄せられると思われる。

もしもあなたが既に自分の .com ドメインを持っているならば、あなたがすべきことは手近のオンライン登録所へ行き、およそ十ドルほどの手数料を納め、過去の歴史上誰も思い付いたことのなかった名前を選べばよい。もしもあなたが自分独自の gTLD を作りたいと思うならば、手続きはもう少し複雑なことになる。まずは $185,000 (日本円で 1,500 万円以上) の出願料を支払う。そう、これはあくまでも申し込むための料金だ。それでも申し込みを却下されることはあり得る。gTLD は、すべて ICANN によって承認されなければならず、彼らは彼らの作ったガイドラインに沿った gTLD を求めている。例えば既存のコミュニティーやグローバルなブランドの名前と結び付いていなければならない、などの決まりがある。詳しくは New gTLD Applicant Guidebook Version 2 を参照されたい。これは来月に最終版と入れ替わることになっている。

このような料金と出願プロセスにした背景には、インターネットドメイン名が誰でも参加できる混乱状態となることを防ごうという動機がある。もしもどんな単語でも自由に gTLD となれるとしたら、それはまさに、例えて言えば米国内の電話番号を 10 桁から 30 桁までの好きな数に設定できるようなものだ。

だからこそ、私たちは今回 .nxt カンファレンスに集まったのだ。100 人ほどの人たちが一つの部屋に集まり、インターネットについて議論し、まるで今が 1999 年であるかのように盛り上がった。自分で独自の gTLD を持って、そのドメイン名がとてもホットなインターネットアドレスとなるようにすれば、そこにショップを作りたいと思う企業や人々のために、あなたが料金を設定することができるようになる。あるいは、もっと共同体主義の志向の強い人なら、あなたの gTLD を使ってそこに集まる人々のコミュニティーを育むこともできるだろう。

後者のカテゴリーに属するドメインとしてよく議論の引き合いに出されるものが三つある。中でも、.music の所有者となった人ならば、その人の携帯電話が鳴り出すと、それは陽気なメロディーで、何の話し合いの場であったとしてもその人に向かって「すごいブランド力だね!」という大声がかかるだろう。でも、残りの二つのドメインを見れば、この問題がどれほど複雑かがすぐに見て取れる。.gay と .green だ。.green gTLD を自分のものにしてしまえば、たちまちそこに集まって来る多くの応募者たちに対して文字通り "green" という名前を授け与える権限を持った団体が出現することとなる。

他方、.gay ドメインの方には、間違いなくかなり多くの国々からそれに反対する声が挙がるだろう。ゲイの人々は表に出るべきでない、彼らが互いに話し合うことが許されるなんてとんでもない、という態度に出てくるだろう。そして、そのドメインが正式に発足した後も、そのようなサイトをそうした国々がすべて一挙に締め出すことのできる、手軽な方法を提供することになるだろう。

これはゴールドラッシュか、それとも金のごとく見える偽物か? -- 今回のカンファレンスでの論調は、コロンビアの国別コードでもある .co という TLD の所有者 Juan Diego Calle (.CO Internet S.A.S. . の CEO) が行なったプレゼンテーションの中に的確に凝縮されていた。彼の意見では(また彼のマーケティング資料にも述べられているが).com というのは「ミスタイプ」であり、歴史的にも法人 (corporation) という単語の省略形としては "Co." が世界的に定着していて、それを正しく取り戻しただけだという。けれどもマーケティングの点は別にしても、彼の論調で際立っていたのは、なぜ彼が gTLD 空間の拡張を推し進めたいのかという理由だった。それは、市場が新しいドメイン名で埋め尽くされるようになるまでの間は、誰も .com を超えるものがあるとは気付かないだろう、という点だ。

その場にいたほぼ全員が、この新しい gTLD がビジネス上の新たなブームを作り出すだろうという点で一致していた。.nxt カンファレンスのウェブサイトで大々的に掲げられている、ランドラッシュ (土地取り争奪戦) だ。彼らは皆、そのための詳細を議論するためにそこに集まっていた。そしてその議論から浮かび上がったのは、gTLD の登録を運営するための詳細の中には極めて困難な問題が控えていることがあり、この空間でプレイをしようとする人たちの多くが失敗に見舞われ、ごく一部の人たちのみが次代のインターネット億万長者となるだろうという考えにほとんど疑いの余地はない、という共通認識だった。

まさにそこが、私がむしろ疑念を感じるところであり、私が冷めた気持ちでいる理由だ。これらすべての話には一つ大きな問題がある。そしてその問題は、たった一つの単語で要約できる。それは、今やあまりにもいたる所にあって、誰もわざわざその後に .com を付けたりしなくなったもの、Google だ。

この、.com こそインターネットの Nob Hill[訳者注: サンフランシスコのいわゆる「上層階級」地区]であるという考え方は、その昔、インターネット住民のごく一部を成すテクノロジーに強い人々が URL を暗記するのが普通であった時代に遡る。けれども今日、平均的なインターネットユーザーたちは、探している会社名をただ単に Google に放り込む方が普通だ。そして、URL を暗記したりなどせず、必要がある度に何度でも繰り返し Google を使う。これをどこで聞いたかどこに書いてあったのかちょっと思い出せないが、世の中の人は Google のホームページに行くために Google 検索バーの中に Google と書き込んで Google する のが決して珍しくないという話だ。そういう人たちにとっては、到着したサイトが google.com であろうと、goo.gl であろうと、あるいは letmeGooglethatforyou.com であろうと、どうでもいいことだ。彼らにとって意味があるのは検索なのだから。[編集者注: 私の父は今や経験豊富なインターネット飛行士だが、1990 年代に初めて彼がオンラインを経験した頃は URL を入力するロケーションバーさえなく、そもそも URL というものが存在していることすら知らなかったそうだ。彼は、ホームページとして Alta Vista を使っていた。-Glenn]

その一方で、部屋一杯の人々の前で Calle は彼の初期のマーケティングの成果を、あえて彼の言葉を引用すると「私たちはデジタルオーガズムを作り出したのです」と述べ、部屋一杯の人々は大笑いして拍手喝采した。そう、その種の人を酔わせる清涼飲料を、私も飲んだ記憶がある。あれは、私が 1990 年代にインターネット起業家であった時代だ。そういうわけで、今回のミーティングに対する私の印象は、実際に何かが始まろうとして いる というものだった。それは、いくつかの会社が集まって何か新しいものを作り出し、それをお互いに売り買いし始めようとする、ビジネス上の一つのニッチ (隙間市場) だ。なぜなら、部外者たちがやって来て仲間に加わることはあまりないだろうからだ。アドレスや、ブランド設定は、とても重要なことだ。でも、ただ「正しい URL」というだけで商売になるような時代はもう過ぎたのだと思う。

けれども、そこには一つだけ大きな但し書きがある。

次なる本物は -- ものごとを 2011 年の観点から判断して、私たちは NASDAQ の崩壊も大不況も乗り越えてきたのだし、1990 年代の自分たちはちょっと狂っていたのだと切り捨てるのは容易い。けれども、私たちが毎日使うテクノロジーの多くがその時代に築かれた、あるいは発明されたものだという事実を忘れてはならない。たとえ、そのテクノロジーを私たちに売りつけた人たちが、それを市場にもたらそうと努力しつつ自らは無一文となった人たちとは違っていたとしても。

私は、以前に jeffporten.com ドメインを購入した時の、自分の思考過程を思い出す。私は昔ながらのインターネットユーザーなので、TLD が実際に何かを意味していた時代を覚えている。その昔は、.net を得るためには実際に何かのネットワークを運営していなければならず、.org を得るためには実際に非営利団体を持っていなければならなかった。その後、登録はオープンになり、以上三つの TLD がすべて誰の手にも届くようになった。

そうだとしても、私は自分の個人的ドメインに jeffporten.com を使うべきかどうか、しばらく時間をかけて考えた。確かに、私は自分でビジネスを運営している。でもそのビジネスの名前は "Jeff Porten" ではない。私はそのビジネスにおけるエンジンに過ぎない。私はこう考えた。このドメイン名は、やはり自由市場における私の役割を示すよりも、私という人間自身を示したものであるべきだ。そう考えれば .org とか .net とかは、ますます場違いとなる。では、jeffporten.info はどうだろうか? あるいは、個人用の「公式」TLD を使った jeffporten.name はどうか?

当然のことだが、私は jeffporten.com を選んだ。なぜか? だって、いったい誰が .name なんて使うだろうか?(それに、私が自分のウェブサイトの中にも書いている通り「jeffporten.info ではなおさらうぬぼれて見えるから」だ。)でも、そうすることによって私は、さっきからかいの種にしたばかりの Nob Hill 理論に、自らを巻き込んでしまった。自分の名前を冠した .com を持つことには、ある種の名声の感覚が 確かに 伴う。Greenberg という人物 が、自分の名前を冠したドメイン名が不動産業者によって先に取られてしまったことを話題にしているのを見てもそれは分かる。

そこで思い出すのがまたもう一つのテクノロジーの歴史だ。20 世紀にずっと遡って、国中に市外局番が割り当てられていた時代には、最新テクノロジーの一つとして「回転ダイヤル式電話機」というものがあった。電話番号を「ダイヤル」する際、実際にダイヤルを回したものだ。9 をダイヤルするには 1 をダイヤルするのに比べておよそ 9 倍の時間がかかった。あまり知られていないことだが、これはつまり「より良い」市外局番があったということだ。例えば、ニューヨークの Manhattan には 212 という市外局番が割り当てられたが、それはこれが最も速くダイヤルできるからだった。だから、市外局番を見ればアメリカの主要都市の重要度がどう見られているかのおおよそのランク付けが分かる。Manhattan は 212、Los Angeles は 213、Chicago は 312 だ。(ちなみに New Jersey 北部は 908 だ。)

時代を下って 20 世紀の末に移ると、私たちはアドレス指定の問題に直面し始める。市外局番の後の電話番号は 1 や 0 で始まることができないので、一つの市外局番に対しておよそ 8 百万個の番号が利用できる。まるでキャンディーを配るかのように気前良くファクス機にも携帯電話にも電話番号を割り当てた結果、これはもはやそれほど十分な数でないことが分かってきた。今や、ニューヨーク市内だけでも五つの異なった市外局番が Wikipedia に挙げられている。もはや新しい 212 番号を配ることができない、つまり既に持っている人たちの手から市外局番を奪い取らなければならない日がやって来たのを目にして、人々はこの仮想の不動産を確保し続けるために必死に戦ったのだ。

今は 21 世紀だ。私はついさっき Atlanta の市外局番 404 を持つ友人に Skype したばかりだが、彼は折り返し私の Washington DC の市外局番 202 あてにテキストメッセージを送ってきた。でも、私たちは今二人ともサンフランシスコ市内にいるのだ。私たちのどちらも、自分の市外局番が示す場所にはいない。今や私たちのような人はいたる所にいるので、市外局番が地理的場所に割り当てられている意味はあまりない。(それに、市外通話の料金も、私が子供の頃ほど心配の種にはならない。)

私が思うに、.com にまつわる標準性の感覚の現状は、いずれ 212 の優位性と同じ道を辿るのではなかろうか。そして、あの日 .nxt カンファレンスの部屋にいた起業家たちの一人が、きっと新たなる標準、つまり次代の仮想 Nob Hill を作り出してくれるということも、十分に考えられる。でも、gTLD で使うための完璧な単語を選び出すだけでそれができるとは私には思えないし、卓越したマーケティングとか、そういったお決まりのビジネス手段で実現するとも思えない。実際のところ、どんな風にそれが起こり得るのか、私にも見当がつかない。

それでもなお、それは 必ず 起こる。だから、あの人たちが自分こそそれができるのだと信じていても、必ずしも全員が狂っているというわけではないのかもしれない。

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


TidBITS 監視リスト: 注目のアップデート、2011 年 2 月 21 日

  文: TidBITS Staff <[email protected]>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

Skitch 1.0.3 -- スクリーンショット編集用ソフトウェア Skitchがバージョン 1.0.3 にアップデートされた。さまざまのバグが修正されたが、主なものとしては、キー組み合わせを押した際に意図しないアップロードを引き起こしていた問題や、ファイルを Skitch にドラッグした際の誤った挙動が修正され、一部の新機種の Mac で起こっていたクラッシュも解消された。Skitch サービスの無料ユーザーは今回から新たに三つの画像処理オプション、Rotate、Flip、Fonts にアクセスできるようになった。(無料、6.3 MB)

Skitch 1.0.3 へのコメントリンク:

Digital Camera Raw Compatibility Update 3.6 -- Apple の最新のデジタルカメラ RAW 互換性アップデート 3.6で、Aperture 3 と iPhoto '11 のサポートが新たに六つのカメラを追加して拡張され、四つのカメラで画像の処理に関する問題が修正された。新たにサポート追加されたカメラは Canon EOS Rebel T3/1100D/Kiss X50、Canon EOS Rebel T3i/600D/Kiss X5、Olympus E-5、Panasonic Lumix DMC-FZ100、Pentax K-r、それに Pentax K-5 だ。今回のアップデートで画像処理が改善されたカメラは Nikon D7000、Nikon Coolpix P7000、Panasonic Lumix DMC-GF1、それに Panasonic Lumix DMC-GH2 だ。このアップデートはソフトウェア・アップデートから、あるいは Apple Support Downloads ページからも入手できる。Apple は、サポート対象のカメラのフルリストも公開している。(無料、6.45 MB)

Digital Camera Raw Compatibility Update 3.6 へのコメントリンク:

Evernote 2.0.4 -- 記憶保存用ソフトウェア Evernote がバージョン 2.0.4 にアップデートされた。今回の新バージョンでは PDF の処理を改善し、大サイズの PDF をロードする待ち時間の問題を防止するとともに、PDF をこのプログラムの外へ楽にドラッグできるようにした。また、このアップデートには開発者の言う「多数のバグ修正」も含まれている。(無料、15.9 MB)

Evernote 2.0.4 へのコメントリンク:

CopyPaste Pro 3.0 -- Plum Amazing は、同社の複数クリップボードユーティリティ CopyPaste Pro を「あなたのクリップボードのための Time Machine」と形容している。バージョン 3.0 での新機能はクリップアーカイブの検索で、これによりどのクリップの中からでも何でも見つけ出せるようになる。また、このソフトウェアのずっと古いバージョンに存在していた Clip Revolver 機能が復活した。さらに、クリップ内容からの電子メールアドレス抽出機能が改善され、CopyPaste の全般的挙動のコントロールを拡張する環境設定項目がいくつか新設された。(新規購入 $30、無料アップデート、4.3 MB)

CopyPaste Pro 3.0 へのコメントリンク:

1Password 3.5.7 -- Agile Web Solutions が、 1Password をバージョン 3.5.7 にした。最も注目すべき変更点として、このソフトウェアはメインウィンドウを閉じた際に自動終了しなくなった。また、添付ファイルを追加した後に出る成功メッセージや、Dropbox 同期のセットアップ手順簡略化、パスワード強度報告機能の改善なども新機能だ。さらに、入力の自動修正や、クレジットカード情報の自動記入なども改善された。加えて今回のリリースでは、このソフトウェアと Google Chrome との互換性が大幅に拡張され、Firefox 4 と Safari に関するマイナーな修正もある。(新規購入 $39.95、無料アップデート、19.7 MB)

1Password 3.5.7 へのコメントリンク:

iWeb 3.0.3 -- Apple が iWeb をバージョン 3.0.3 にアップデートした。iLife '11 の取り巻き連中のうち、iDVD でない 方のやつだ。今回のアップデートでは一部の Mac で iSight Movie ウィジェットを使う際の問題点に対処し、FTP 経由で iWeb サイトを公開する際の問題を修正している。Apple はまたこのアップデートが「Mac OS X との互換性を改善」したと述べている。たぶんそれは良いことなのだろう。何しろ、iWeb が走るのは唯一そのオペレーティングシステムだけなのだから。(iLife '11 の一部としての購入は $49、無料アップデート、177.12 MB)

iWeb 3.0.3 へのコメントリンク:

Adobe Acrobat/Reader 10.0.1 -- Adobe が、同社の PDF オーサリングおよび読み出しツール、 Acrobat および Reader にそれぞれアップデートをリリースした。今回の新バージョンでは、それぞれ重大なセキュリティ脆弱性に対処するとともに、全般的な安定性を改善している。また、Reader のアップデートでは Protected Modeを改善するとともに、QTP、Flash、SCCM のサポートにも改善を施している。(無料アップデート、サイズはいろいろ)

Adobe Acrobat/Reader 10.0.1 へのコメントリンク:

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


ExtraBITS、2011 年 2 月 21 日

  文: TidBITS Staff <[email protected]>
  訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

今週はリンクを二つだけ手早く紹介したい。Glenn が Readability について The Economist に書いた記事と、Lex Friedman が自分のバックアップ戦略について書いた Macworld 記事だ。

Readability サービスが読者と出版者双方を助ける -- Readability が、与えられたウェブページからその余分な要素を削ぎ落としたバージョンを生成してアーカイブ保存し、ウェブアカウントを使ってあとで読めるようにする、という Instapaper に似た購読サービスを追加した。Glenn Fleishman が The Economist に、読者のために作られたこのサービスが実は出版者の利益にもなるという論説記事を寄稿した。

コメントリンク: 11973

Lex Friedman のバックアッププラン -- Macworld で、Lex Friedman が彼自身の Mac のデータを安全に保つためのバックアップ戦略と、彼がそのやり方を選ぶ動機となった妄想症について詳しく語る。要約すれば、Time Machine に加えて、SuperDuper によるブート可能クローンを用意し、さらに CrashPlan によるオフサイトのバックアップと、その上に Dropbox、そのまた上に Google Docs だ。今言ったと思うが、データ喪失に対する妄想症は非常に役に立つ。

コメントリンク: 11972

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


tb_badge_trans-jp2

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

©Copyright 2011 TidBITS: 再使用はCreative Commons ライセンスによります。

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