TidBITS#1069/28-Mar-2011 TidBITS#1069/28-Mar-2011Mac OS X 10.6.7 にご用心！ フォント関係の問題があるので、人によってはアップデートを控えるか、10.6.6 にダウングレードしなければならないこともある。Adam が詳細を説明する。また今週号では、Google Books 和解案を裁判所が棄却した問題について Glenn Fleishman が解説し、iOS 4.3.1 のリリースについてお知らせするとともに、Adam が Guy Kawasaki の最近の著書をレビューする。Jeff Carlson の新刊 "Take Control of Media on Your iPad, Second Edition" のお知らせもある。それから、Gmail への切り替えを物語る Adam のシリーズ記事第二部もお見逃しなく。今週注目すべきソフトウェアリリースは、LogMeIn Ignition 2.0.264、Things 1.4.5、Skype 5.1.0.914、NoteBook 3.0.9、PDFpen and PDFpenPro 5.2.2、Aperture 3.1.2、MarsEdit 3.2、Firefox 4、Sparrow 1.1、それに Skitch 1.0.4 だ。
記事:
----------------- 本号の TidBITS のスポンサーは: ------------------
---- 皆さんのスポンサーへのサポートが TidBITS への力となります ----
文： Adam C. Engst <[email protected]>
訳： 柳下 知昭 <tyagishi@gmail.com>
iOS 4.3 がリリースされて 16 日しか経っていないが、その時間は、アップルにとっていくつかのやっかいな不具合を特定し、iOS 4.3 互換の全ての iOS デバイス向けの迅速なiOS 4.3.1 アップデートで修正するのに十分な時間だった。
なかでも注目すべきで、このような早急なリリースの間違いない理由は、iOS 4.3.1 が、いくつかのセルラーネットワークにアクティベートし接続することに関する不具合を解決することである。これらの不具合と iOS 4.3.1 のリリース日から、iPad 2 の世界向けリリースと一致するようにスケジュールされたということも考えられる。
さらに、iOS 4.3.1 の修正は、第 4 世代の iPod touch でたまに発生するグラフィックの不具合についても修正するし、Apple Digital AV アダプタで接続した一部のテレビでの画像のちらつきを解決し、一部のエンタープライズ Web サービスで起きる認証に関する問題も解決する。
iOS 4.3 と同様に 4.3.1 は、iPad と iPad 2, iPhone 3GS と GSM iPhone 4(Versizon Wireless の iPhone 4 ではない）, 第 3 第 4 世代の iPod touchと互換性がある。このアップデートは、iTunes 経由でのみ提供されている。ダウンロードサイズは、500 - 600MB くらいであり、もし高速インターネット接続でないならば、いくらかの時間を予定しておいて欲しい。
コメントリンク12079 この記事について | Tweet リンク12079
文： Adam C. Engst <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
Mac OS X 10.6 Snow Leopard に対する何回かのマイナーなリリースが進むにつれて対処の施されるバグが個別的なものばかりになって行くに従い、アップデートが新たな問題を導入してしまう可能性にはとかく無頓着になりがちだ。ところが、先週の Mac OS X 10.6.7 リリース (2011 年 3 月 21 日) で、まさにそれが起こってしまった。このリリースには、多数の修正点の中の一つとして、フォント処理に関係したセキュリティ脆弱性の修正が含まれていた。
手短にいうと、ある特定のタイプのフォントが使われた場合、10.6.7 におけるフォントのレンダリングが壊れてしまう。特に、Word や Pages をはじめとするいくつかのプログラムで、特定のフォントを使って印刷しようとするとエラーになるという報告がユーザーたちから寄せられている。また、PDF 書類を作成しようとした場合に、その書類に OpenType PostScript フォントが用いられていると問題が起こるという報告もある。（これらの PDF ファイルは Preview でならば正しく動作するが、Adobe Reader や Adobe Acrobat では Mac でも Windows でも問題を起こすという。）さらに、Flash Professional で開発中にフォントの問題が起こったという報告さえも目にしたことがある。とはいえ、このバグはフォントのレンダリングで Mac OS X のメカニズムに依存するすべての Mac アプリケーションに影響を与えるはずだ。InDesign などのように独自のレンダリングエンジンを持つものは影響を受けない。
私が調べたところによれば、問題は PDF の中で使用される個々のフォントにはそのグリフ（具体的な字形）がどのようにエンコードされているかについての記述が含まれているのだが、10.6.7 における変更の結果、PDF に不正なエンコード定義が付くようになってしまったことにある。Mac OS X はプリントスプールのフォーマットとして PDF を使っているので、その結果として問題が PDF ファイルにも、また印刷ジョブにも発生することになる。オーサリングツールの Flash Professional はプラットフォームのフォントレンダリングに依存して動作するので、その点がトラブルの原因だろうと説明がつく。
PDF が Preview では正しく動作するのに他のプログラムではそうならない理由について言えば、それは Preview が PDF 仕様のすべてに注意を払っていないことの副作用だ。（例えば、Preview は色空間も無視するので、その結果として Adobe Reader や Acrobat Professional の中では色の表示がおかしくなるような構造欠陥を持つ PDF でも問題が回避される。）ただし注意しなければならないのは、10.6.7 の上で OpenType PostScript フォントを使って作成した PDF ファイルが、この問題を永久に保ち続けることだ。将来にわたって、そのファイルには問題が起きる可能性がある。
問題があるのは、どうやら OpenType PostScript フォントのみのようだ。電子ブック "Take Control of Fonts in Snow Leopard" で Sharon Zardetto が説明しているように、OpenType はフォントテクノロジーというよりもフォントフォーマットであって、Adobe と Microsoft によって作られたものだ。この OpenType 規格では PostScript と TrueType 双方のフォント記述がサポートされており、OpenType PostScript フォントは一般的に拡張子 .otf を、OpenType TrueType フォントは一般的に拡張子 .ttf または .ttc を持っている。（時として、後方互換性のために TrueType フォントでも .otf を用いることがある。）特定のフォントが OpenType PostScript であるかどうかを調べる手軽な方法としては、Font Book で (プレビュー > フォント情報を表示 を選び)「種類」フィールドを見ればよい。（スクリーンショットに示されている Myriad Pro は、今回トラブルに遭った人々からの報告でしばしば名前が挙がっている。）
最も手軽な回避方法は、当然ながら違うフォントで OpenType PostScript でないものを使うことだが、例えば仕事場でフォント要件として指定されている場合（あるいは単純にその特定のフォントを使いたい場合）にはその回避方法が可能でないこともあるだろう。それが無理な場合は、どうやら唯一の解決策は DVD から Mac OS X 10.6 Snow Leopard を再インストールして、その後で Mac OS X v10.6.6 統合アップデートを適用することで問題発生直前のバージョンの Snow Leopard に戻すことしかないと思われる。
そしてもちろん、もしもあなたが仕事上 OpenType PostScript フォントを使うことが必須であって、あなたがまだ 10.6.7 にアップデートしていないのならば、Apple がこの状況を解決してくれるまでアップデートせずに待つことをお勧めする。修正はたやすいはずだが、実現するまでにどのくらい時間がかかるかは何とも言えない。
［訳者注： Mac OS X に付属の「ヒラギノ」フォントは OpenType なのですが、Mac OS X 10.6.7 では 10.6.7 対応バージョンのヒラギノ OpenType フォントに変わっているようです。］
コメントリンク12078 この記事について | Tweet リンク12078
文： Glenn Fleishman <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
Google が著作権で保護された書籍を許可なくスキャンすることを巡って著者たちや出版者たちの団体と Google との間で争われていた裁判で、提起されていた和解案を判事が退けた。（2008 年 10 月 29 日の記事“著者たち、出版業界が Google Book Search と和解合意”参照。）この却下により、より限定された取り決めに向かうことが考えられ、すべての創造的な者たちの権利が保護される方向に進むかもしれない。
いったいなぜこれが問題となるのか？ それは、もしもこの和解案が承認されていたならば、それは Google にとって、著者たちや出版者たちから訴訟を起こされる心配がなくなる一方で、同時に膨大な量の書籍に関する権利を認められる、という他に類のない立場が与えられる結果となっていただろうからだ。他のどんな会社も、Amazon、Apple、Microsoft であろうと、今はまだ存在していない会社であろうと、これと同じ条件を付与されることはあり得ない。
この和解案はまた、著作権で保護されているけれどもその著作権者を見つけることが困難であるような作品についても、それをスキャンして販売する権利を Google に与えることになっていた。さらに、電子的形式の作品について交渉の余地のない価格を設定できる権利者たちの共同事業体（実際にはカルテル）を設立することも定めていた。
これらすべてのことにより、Google には永久に電子ブックを管理できる立場が与えられたであろう。アクセスを制限し、価格を高く保ち、このシステムに加わろうとしない出版者たちや著者たちを締め出していただろう。
Google は、図書館や大学にも、例えば在籍学生数数千人あたり一台、ないしは一部門あたり一台の「ターミナル」といったように、極めて制限されたアクセスしか無料では許さないであろう。図書館や大学で無料のアクセスができるという点は人類の知識へのアクセスの花盛りとして盛んに称賛されてきた一方、その利用に関する制限については触れられることが稀だった。
私はこの問題について 2009 年 9 月 7 日の記事 "Google Books Settlement Hits Snags" に詳しく書いた。その中で私は、著作権登録機関や外国の出版者も含む多くの団体から挙げられた三つの主要な異論に触れた。そのうち二点が、今回の判事による拒否裁定の要約書面でも触れられている。仮にこの和解案が承認されたとすれば、として、判事 Denny Chin は次のように述べた：
「...著作権保有者の許可なしに書籍全体を利用できるという重大な権利を Google に付与することになる。実際、ASA (修正和解案) によれば Google に競合他社よりも大幅な優位性が与えられ、著作権で保護された作品を許可なく大規模にコピーできるようになる一方で、この訴訟で提示されたものを遥かに超えた範囲まで請求権の放棄を規定することになる。」
もう一つの主要な論点は、外国の出版者が一切この和解案に関与していないにもかかわらず彼らの作品に影響を与えてしまうことだ。この点は、裁定全文書面の中で Chin も触れている。
Chin は、この訴訟の解決に向けてドアをもっと狭く開けておく方法を選んだ。彼は次のように書いている：
「異議申し立ての中で挙げられた懸念の多くは、もしもこの ASA において 'opt-out' による合意を 'opt-in' による合意によって置き換えれば改善されるはずのものと考えられる。」
（この裁定を 詳細かつ分かりやすく要約したものが The Laboratorium サイトで読める。これはニューヨーク法科大学院の教授が運営しているサイトで、ここには裁定書の PDF へのリンクもある。彼や彼の学生たちによる著作のいくつかが判事の文章の中でも引用されている。）
Google にとっては、opt-in のやり方はとうてい望ましいものとは言い難い。なぜなら、その場合は許可を得たくとも連絡のつかない著者たちや出版者たちによる膨大な数の作品に、同社がアクセスすることができなくなるからだ。Library of Congress や Registrar of Copyrights は、いわゆる孤児となった作品（著作権者不明書籍）の問題を解決するための提案として、著作権者の所在が分からなかった場合に Google のような団体が合法的にその作品を利用できる手順を作ることを提起している。ちょっと皮肉なことだが、この提案は議会で審議が中断している。Google Books 訴訟がまだ進行中だから、というのが理由だ。今回裁定が出たことにより、審議が再開するかもしれない。
何千何百万冊という書籍が検索可能な電子版として利用可能となれば膨大な公共の利益があるということに有効な反論の余地はない。あえて演壇の上に進み出てそれをしようと申し出た唯一の組織として、Google は称賛を受ける資格がある。しかしながら、この和解案は、Google に特権的な門番の立場を与えてその分野の他のすべての競合他社を排除してしまうことにより、また著者たちと出版者たちが価格を設定できるカルテルを作り出すことにより、双方の意味でその公共の利益を切り落としてしまうものとなっていた。
そういうわけで、Chin 判事の裁定は良い判断と言える。創造的な作品に対して何が起こるかの決定を、無関係なサードパーティの手にではなく、その作品を作り出した人の手に戻すものだからだ。願わくは、関係する当事者たちが、これまでに到達した合意点を共通の基盤として、新たなる和解案を目指して努力し、個人の作品に個別のコントロールが保たれる一方で公共の領域をさらに押し広げることのできる、そのような道を切り開いて欲しいものだ。
コメントリンク12070 この記事について | Tweet リンク12070
文： Michael E. Cohen <[email protected]>
訳： 亀岡孝仁<takkameoka@kif.biglobe.ne.jp>
初期の iPad 或いは新しい iPad 2 のいずれの所有者でも、Jeff Carlson の新しい "Take Control of Media on Your iPad, Second Edition" で Apple の魔法のタブレットの楽しみを更に増やすことが可能となる。
最近数か月の間 Apple やその他の会社からリリースされた最新の iPad ハードウェアとソフトウェア、iOS 4.3 を含む、をカバーするため大幅に改訂された "Take Control of Media on Your iPad, Second Edition" は、iPad 所有者に iPad メディア管理のヒント、裏ワザ、手法を包括的に提供しており、更に多くの iPad のメディアに関連した疑問にも答えている。例えば、この電子本の仮想の表紙間に答えがある質問には：
デジタルメディア全般そしてとりわけデジタル写真学に関する Jeff の広範囲にわたる知識のお蔭で、この本は Apple のタブレットの多くのメディア機能の探索を楽しめ、そして実用に役立つものにしている。
"Take Control of Media on Your iPad, Second Edition" は、PDF フォーマットで $15 で入手可で、購入後は、EPUB フォーマットにもあなたの Take Control アカウントから iPad 上で直接アクセス出来るようになる。これは、新しい iPad を買ったばかりでそれが自分のデジタルメディアエコシステムにどの様に適合するのか知りたいという人、そして既に iPad の 9.7-inch スクリーンの輝きに何か月も浴してきた人のどちらにも必須のガイドブックである。
コメントリンク12076 この記事について | Tweet リンク12076
文： Adam C. Engst <[email protected]>
訳： 亀岡孝仁<takkameoka@kif.biglobe.ne.jp>
"良い奴は最後にゴールするものだ" と言ったと野球監督の Leo Durocher はしばしば引用されてきた。そして確かに態度、不機嫌さ、そして全般的な不品行と言ったものが注意を引くのには間違いない方法であるあるように見える、それがインターネット上であれ現実の世界であれ。
しかし注目が必ずしも望んだ結果と同じにはならない、そして前の Apple 伝道者である Guy Kawasaki ("The Macintosh Way"、"Rules for Revolutionaries" 等々多くの著作がある) は彼の最新著書 "Enchantment: The Art of Changing Hearts, Minds, and Actions (魅了：心、気持ち、そして行動を変える方法)" で、自分の欲しいものをただ手に入れるだけでなく、他の人にも自発的なそして永続する変化をもたらすより良い方法があるのではないかと問題提起している。
このより良い方法とは、勿論のこと、彼らを魅了することであり、そしてこの言葉は Kawasaki の用途に当てはめるには多少拡張されている感じがするが、この本は次の様に繰り返し強調している：目的は、人々をあなたの理念を信じたり或いはあなたの製品を買うように仕向けることではなく、彼らを真の信者そして確信の顧客へと変身させることである。他の多くのビジネス本やマーケティング本では目的が手段を正当化しているように見えることが多いけれど、この "Enchantment" ではそうではない。
結婚での魅了することの役割についてのユーモラスな挿話を除いては、"Enchantment" はビジネスの世界に焦点を当てている：仕事と生活の展望という巨大な原野を横断し、そしてあなたがボスを持った部下、部下を持ったボス、売り上げを増やそうとしているマーケッティング担当、新製品を世に出そうとしている起業家、或いはボランティアを集めようとしている地域のまとめ役であるかどうかに関係なく、魅了するやり方を説明している。
この本は 12 章から成り立っており、それぞれの章は幾つかの短いセクションを含んでいる。"Enchantment" は、さっと目を通しそして速読し易いが、順を追って一度目を通すことを、魅了を形成するのに必須である好ましさと信用性、個人的資質に関する最初の方の章を見逃さないためにもお勧めしたい。次に来る 4 章は、抵抗に備え、対抗し、克服すること、そして魅力を長続きさせることに関するものである - これらの章はこの本の核であり、あなたの目標を成功裏にそして永続的に達成するのを手助けすることに焦点を当てている。
"Enchantment" は、あなたが成し遂げようとしているのは本当に _何_ なのかの問題は意図的に避けていて、あなたが "何か偉大なことをする" そして偉大な理念とは何か深く、理知的で、完結した、力を与える、そして優雅なものであると単に示唆しているに過ぎない。勿論、あなたは Apple 製品はこの定義にあてはまると思うかもしれないし、Kawasaki は偉大な製品の他の説明用事例を挙げているが、ここは私がもっと説明が欲しいと思った所の一つである。とりわけ偉大さをそぐ要素をどう扱うかについての助言が欲しかった。例えば、あなたの製品が偉大さの定義を満たすためには用意できない更なる資源の投入が必要な場合はどうするのか？完結するにはあなたの手が届かない他の製品に依存しなければならない場合はどうするのか？製品を売るのではなく非営利団体への寄付を募ろうとしている場合はどうなのか？これらの問題に対して Kawasaki は解を持っている、或いは考えてみるか出来るのは間違いないと思うので、いつか彼のブログでこれらについて取り上げてほしいと思う。
いずれにしても、準備をするそして対抗することに関する助言は素晴らしい、そしてビジネス本にしょっちゅう目を通す人は多くのものは前にも見たことがあると感じられるかもしれないが、一か所に集められているというのは助けになる。私は、TidBITS や Take Control のために新しいサービスを導入する時にこれらの章を読み返してみようと思っている。
初めの方の章はどうしても多少一般的になってしまっているが、次の数章はより具体的で、プッシュ技術 (プレゼンテーション、メール、そして Twitter) とプル技術 (Web サイトとブログ、更に Facebook, LinkedIn, そして YouTube) を使う方法を提案している。これらの章は長くはないし、例えば、素晴らしいプレゼンテーションをするフルコースの解を提供しているわけでもないが、だからと言って提言されていること全てをやらない言い訳にはならない。
Kawasaki は彼自身の助言を守り "Enchantment" の書評用の本を送って書評を依頼しているのを見るのは面白い；私は、彼が辿っていたセクションへのページ参照のついた彼のメールに書き込みをしたい気にほぼなった。(明らかに、彼の書評依頼は機能した。つまり私も彼と彼の本にその気になるだけ魅了されたに違いない。彼は最後に一章を割いて、魅了、説得、そして影響が巧みに操作的に使われた時、それに抵抗する方法に触れている；私はこの忠告を更に強調する必要はないだろうと感じた。)
最後の二つの章は、もしあなたがボスならあなたの部下をどうやって魅了するか、そしてもしあなたが部下なら、どうやってあなたのボスを魅了するかについての助言を提供している。他の本であれば、これらの章で扱われている方法はお互いを帳消しにする問題が出る場合もあるのではないかと思われるが、魅了の究極の目的を考えれば、あなたはきっと管理職も部下も両方とも Kawasaki の助言に耳を傾けてくれたら素晴らしいと感ずるであろう。
これが "Enchantment" が与える全般的な印象である。人生は、誰もが幸せでそして誰もが繁栄している時の方が真により良いと言えるが、何時でも可能であるとは言えない、でも我々全ての人が目指すことが出来る何かであることは間違いない。
約 200 ページでかなりの数の写真もあり、"Enchantment" は学術書ではない、そして意図的に主題の表面をさっと触れているだけだが、明快な例と逸話でその主張を支えている。これはあなたに考えることを始めさせるが、最終的には、あなたが成功するか失敗するかは、あなたが何を考えそして何をするかによるもので、本に書いてある何かのチェックリストを辿った故ではない。
最後まで読み通すことを忘れないで欲しい。そうすれば、目次の最初の Easter Egg の引用や、もっとその後にくるカバーストーリーも見逃さないで済む。
"Enchantment" の定価は $26.95 だが、現時点では幾つかのフォーマットでこれよりずっと安い値段で Amazon.com から入手できる。これについてはもっと詳しく Guy Kawasaki のサイトでも読めるし、Firepole Marketing にある Kawasaki との長時間のインタビューも読む価値がある。
コメントリンク12050 この記事について | Tweet リンク12050
文： Adam C. Engst <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
初めて Gmail を試す決断をして以来（記事“禅と Gmail 技術、第一部： なぜ私は切り替えたか”参照）私は自分が電子メールから何を得たいのかをじっくりと考えてきた。そのためにはかなりの自己分析が必要であった。なぜなら、私は通常、階層的なファイリングシステムを好む整理整頓好きの人間だからだ。私にとって Finder の中で Spotlight が役に立ったことはない。自分のファイルがどこに保存されているか、私はすべて熟知しているからだ。そして、私が Eudora を使っていた時代には、何百個ものメールボックスを注意深く整理区分けすることで、いつでも何かを探そうと思えば相応しい場所を見るだけで済んでいた。
けれども悪いことに、私が Eudora で使ってきた検索条件保存の戦略はうまく行かなくなってきていた。（2004 年 12 月 20 日の記事“Eudara の新しい使い方”参照。）問題は、フィルタにかからないメッセージをファイリングしたり、何らかの方法で処理を後回しにしたメッセージにマーク付けしたりするのに必要な作業があまりにも多くなったことだった。この、マーク付けしたメッセージというのが問題の核心で、Eudora の時代は Act On のラベル付けをするのは言わば死の接吻、つまりまず間違いなく私の目に二度と触れない結果となってしまっていた。しばらくの間、私はその種のメッセージに未読のマークを付けて、毎日私の目に触れるようにしていたが、そのうちにそれらも結局無視するようになってしまった。その上、保存された検索条件 "Unread Mail" の検索結果に多数のメールが並んでしまうことで、新着のメッセージを扱うのがますます厄介になった。
いろいろ考えた結果、禅のアプローチを選ぶことに決めた。つまり、電子メールを川と見て、流れ行く一つ一つのメッセージに施す作業をできる限り少なくすることを目標としたのだ。それを目指す私の旅路の最初の一歩が、ラベルとフィルタを設定することによりメールの管理の大部分を自動化することだった。
ラベルは検索である -- ラベルは、Gmail の持つ最もパワフルかつ最も巧妙な特徴の一つだ。Gmail のラベルを伝統的な電子メールプログラムにおけるフォルダのようなものだと考える人は多いが、その考え方は二つの重要なポイントを見逃している：
Gmail の中では一つのメッセージに 複数の ラベルを割り当てることができる。他方、伝統的な電子メールプログラムの中では一つのメッセージはたった 一つの フォルダの中にしか存在することができない。この事実の結果として、伝統的な電子メールプログラムではすべてのメッセージが 必ず どれかのフォルダに入らなければならないが、Gmail ではそんなことはない。一つのメッセージに何のラベルも付かないということもあり得る。（その場合、そのメッセージは All Mail (すべてのメール) コレクションにのみ登場する。）
Gmail におけるラベルは、検索の中で利用できるほんのちっぽけなメタデータのビットに過ぎない。従って、本質的には、ラベルは保存検索条件なのであって、つまりは単なるショートカットなのだ。あるメーリングリストからのメッセージすべてを判別するためにフィルタ（これもまたただの検索だ）が使えたならば、それらのメッセージにラベルを適用することもできる。これは過去に遡ってすることも可能だ。けれども必ずしもそれをする必要はないかもしれない。なぜなら、あとで手動で検索をすればメッセージの同じセットがいつでも見つけられるからだ。
これら二つのポイントを深く考えてみれば、伝統的な電子メールプログラムにおいて必要であったファイリング作業のほとんどが Gmail では時間の無駄遣いに過ぎなくなることが理解できるだろう。従来のプログラムの中では、メッセージはどこかに属していなければならないのだから、常にファイル分けが必要となる。また、検索は速度も十分でなく機能も限られているので互いに関係するメッセージを素早く集めてコレクションを作ることもできない。けれども、Gmail においてはいずれも問題にならない。
対照的に、Gmail でラベルを作る必要が生じる理由は以下の三つだけだ：
互いにあまり共通点のないメッセージ同士を集めたい場合。例えば、さまざまのウェブ商店からの領収書に私は手動で Order Receipts ラベルを付けている。これで、クレジットカードの請求書と照合したり、過去にどのベンダーを使ったかをチェックしたりするのに利用できる。私がいつもひいきにしているいくつかのベンダー，例えば iTunes Store や Amazon などについてはフィルタを使って自動的にそのラベルを割り当てるようにしているが、たいていの領収書は届いた際に目で見てそれと分かるのでラベルが簡単に付けられる。
一連のメッセージを手軽に検索で見つけ出して一つのグループとしてアクセスできるようにし、さらに オプションとして それらを丸ごと Inbox (受信トレイ) から削除できるようにしておきたい、という場合。典型的な実例はメーリングリストだ。一つのメーリングリストからのメッセージは一緒にまとめて読みたいことが多いけれど、必ずしもすべてのメーリングリストがそうだというわけではない。伝統的な電子メールプログラムでは、フィルタ分けされたメーリングリストのメッセージと他の未読のメールとを一緒に表示させるまでにかなりの手間をかける必要があった。Gmail では、Skip Inbox フィルタアクションを使ってメーリングリストのメッセージを分離することになる。
Inbox の中にある特定のメッセージにマーク付けして一目で分かるようにしておきたい場合。例えば、そのメッセージがメーリングリストあてのものであって自分だけに送られてものではないことを表示させておきたい場合。
これで、作られるラベルの種類の個数は以前に持っていたメールボックスの個数に比べてあまり減ることもないのではないかと思えるかもしれないが、私の経験上、実際ラベルの種類はかなり少なくなる。ことに、私はプロジェクトに結び付けたラベルを作ることはめったにない。なぜなら、その種のメッセージは送信者あるいはリストのアドレスを検索すれば見つけられることが確信できるからだ。
例を挙げよう。私は Peachpit から出している自分の著書 iPhoto Visual QuickStart Guide に関係したメッセージを追跡するためにラベルを作ることも可能だったのだが、それは基本的に Peachpit 社にいる同業者たちから届いたメッセージを集めることに他ならず、それらはすべて peachpit.com または pearson.com の電子メールアドレスからのものか、または私が名前を知っている索引作製担当者からのものだった。だから、そういうメッセージすべてにラベルを付けてもあまり意味はない。一つのグループにまとめる必要もないし、仮にそういう必要が生じたとしても、検索をすれば全く同じ結果が得られる。
だからと言って、他の人たちもプロジェクトに結び付けたラベルを作る必要がないというわけではない。Gmail はもちろんそういうこともできる。ただ、その場合は他の電子メールプログラムより秀でているわけではないと言っているだけだ。そういうメッセージを集める作業は、フィルタによって（例えばクライアントのドメイン名で判定する）さらに手動のラベル付けによって（そのプロジェクトに関する仲間からのメッセージに付ける）しなければならない。
ラベルが検索に比べて少しだけ優っている点が一つある。それは、メッセージ数のカウントだ。理由は分からないが、Gmail の検索結果では結果の概略の件数しか表示されない。けれども指定したラベルを持つメッセージの件数としては厳密な数が表示される。
時によって、私はラベルを使う代わりに Quick Link の方を使うこともある。これは、左のサイドバーの中にリンクを並べることのできる Gmail Labs ウィジェットだ。Gmail Labs についてはシリーズ記事の次の回で解説するが、私が Quick Link を特に気に入っている理由は、これを使えばメッセージの特定のグループへの素早いアクセスが、ラベルを作成 せずに できるようになるからだ。ラベルと全く同様、Quick Link もやはり保存検索条件に過ぎず、検索可能なものなら何でもカプセル化して作成できる。ただし、Quick Link では見つかったメッセージに何のメタデータも付与されない。例えば、私が使っている Quick Link の一つは、TidBITS Talk または私たちの内部のプレスリリース用メーリングリストあてのメッセージであって迷惑メールと判定されたものを集めていて、私はこれを誤判定の特定のために利用している。
フィルタは検索である -- Gmail は、フィルタが検索であるという概念を強く表には出していない。それはすべての電子メールプログラムの動作のしかたであるからだ。けれどもこれは非常に重要な点なので、ここで改めて強調しておきたい。
フィルタによって、特定の基準に合致するメッセージを検索することができる。特定のアドレスからのもの、Subject 行の中に特定の語句を含むもの、などの基準が使える。いったんメッセージがそのフィルタにかかると、フィルタはそのメッセージに対して何らかのアクションを施すことができる。中でも最も重要なアクションが、ラベルを付けることだ。
具体的に言えば、フィルタは From, To, および Subject 行の中で、またメッセージ本文の中で、テキストを探すことができる。ただ、残念なことに Gmail ではそれ以外のヘッダ行、例えば Content-Type や X-Sender などの内容を検索することができない。メッセージ本文の検索については、特定の単語を含み、かつ別の特定の単語を含まない、そういうメッセージを探すこともできる。ただし grep (正規表現) 検索や単語の一部分の検索の機能はない。また、添付ファイルに基づいてメッセージにフィルタをかけることもできる。
いったん基準の設定が済めば、メッセージに以下のようなアクションを実行するよう指定できる：
受信トレイをスキップする (アーカイブする): これは、ただそのメッセージから Inbox ラベルを除去するだけだ。私は、あまり重要でないメーリングリストからのメッセージを受信トレイに入れないようにするためにこのアクションを大いに活用している。
既読にする: メッセージが既読か未読かという区別は私にとって重要なことなので、私は唯一私自身がメーリングリストあてに出したメッセージにのみこのアクションを使っている。（ほとんどの場合、そのようなメッセージを私が見ることはない。なぜなら、Gmail は通常あなたがリストあてに出したメッセージを表示しないからだ。それは、あなたから到着したメッセージは既にその会話の中に保存されている送信済みのメッセージと重複しているから、というのが理由だ。たいていの場合これは歓迎すべきことだが、テストやトラブルシューティングの際には困ったことになるときがある。）
スターを付ける: Gmail のスターは Apple Mail のフラグと同等のもので、単純にオン・オフでメッセージをマークする。私は何らかの対処を必要とするメッセージに対して手でスターを付けるようにしているので、フィルタではこれを使っていない。
ラベルを付ける: ラベルを付けるのは最も一般的なフィルタの応用のしかただ。実際、私のフィルタで、ラベル付けを しない ものは一つか二つしかない。
転送する: 自動的にメールの送信をするフィルタアクションは、細心の注意をもって扱う必要がある。そのような機能を必要とする人ならば使えばよいが、とんでもない結果に陥りやすいことは覚悟しておくべきだ。
削除する: 私がこのフィルタアクションを使うとすれば、大きなメールアーカイブをクリーンアップするような場合のみだろう。いつも自動的に消去したいメッセージを受け取っていたのだとしたら、私ならば何か他の方法を使って止めることを考えたい。
迷惑メールにしない: メーリングリストの中には、迷惑メールと非常に紛らわしいものもある。そのような場合、このオプションを使えば Gmail が正当なリストのメッセージを誤って迷惑メールと仕分けすることがなくなる。私の場合、このオプションを使ったためにリストのメッセージのいくつかを迷惑メールと手で指定する必要があるけれど、正当なメッセージが誤判定されてしまうよりはまだましだ。
返信定型文を送信: このアクションは Gmail Labs により提供されるものだが、これもやはり細心の注意をもって扱うべきだと私は思う。定型文返信を間違った人たちに送信してしまうことが簡単にできてしまうからだ。
常に重要マークを付ける: このアクションは、Gmail に新設の Priority Inbox 機能に対してそのメッセージが重要だと指定する。私はこのアクションを使ったことがない。何かが重要ならば私は自分で Gmail に指定したいと思うし、また Priority Inbox 機能は過去の行動を学習することもできるからだ。
重要マークを付けない: これも Priority Inbox 機能についてのアクションだが、フィルタの立場からはこちらの方がより重要だ。なぜなら、他のフィルタ条件によって仕分けされたメッセージ（例えば自動送信のメッセージや、メーリングリストからのメッセージなど）が決して Priority Inbox に登場しないようにできるからだ。
Gmail のフィルタ機能は伝統的な電子メールプログラムのフィルタ機能に比べて限られたことしかできない。けれどもそれは驚くほどのことではない。なぜなら、ウェブ上のメッセージに施すことのできる操作の種類が限られているからだ。例えば、AppleScript を実行することもできない。（それがしたければ、Macintosh の電子メールプログラムから IMAP 経由であなたの Gmail メッセージにアクセスする必要があるが、それは完全に可能なことだ。）
でも、Gmail のフィルタに関するインターフェイスが本当に素晴らしいのは、あなたが今作成しつつあるフィルタをあなたの現在持っている電子メールに即座に適用して結果を表示する（フィルタ テスト ボタンを使う）ことができ、さらにそのフィルタを既存のメッセージだけでなく将来のメッセージにも適用できるオプションもある（フィルタ作成の最後の画面で「このフィルタを下記の X 件のスレッドにも適用する」チェックボックスを使う）ことだ。これはものすごく大きな利点だ。なぜなら、例えばあるメーリングリストが気に入らなくなれば、フィルタを一回限り使うだけで、そのメーリングリストに属するすべてのメッセージを見つけて消去することが可能になるからだ。
Inbox Zero は忘れよう -- ラベルとフィルタの動作のしかたを理解していただいたところで、私からそれらの使い方の提案をさせていただきたい。主たる利用法は、到着するメッセージの流れを管理して、あなたの Inbox (受信トレイ) に登場するものの数を、到着し次第あなたがすぐに見る必要のあるもののみに減らすためのものだ。
私が自分の Inbox で定めた目標は、そこに到着したものはすべて読んで、返信の必要があるものには返信し、私が自分の手で判別する必要のあるごく少数のメッセージにはラベルを付ける、ということだ。私は毎日何百通もの電子メールメッセージを受け取るので、重要でないメーリングリストやその他の自動化メッセージ（例えば Twitter のフォロー通知や、Netflix のショッピング速報など、Automated Messages ラベルが付くものすべて）はフィルタ分けにより私の Inbox に入らないようにしておく必要がある。それらのフィルタではそれぞれ適切なラベルを付けてから「受信トレイをスキップする」のオプションを使っている。
でも、重要なメーリングリスト、例えば TidBITS スタッフ用のリストや Take Control 著者用のリストなどについては、メッセージが Inbox に登場して欲しい。これらのリストで交わされるメッセージは私だけにあてて送られるメッセージと同等に重要だし、個人あてのものより重要度が高いことさえ多い。それらのメーリングリストごとにラベルを付けるフィルタでは、「受信トレイをスキップする」オプションを使わず、リストから届いたメッセージにはすべてリストのラベルと Inbox ラベルが両方とも付くことになる。
最後に、当然ながら、世界中のいろいろな人たちから直接私に送られてくるメッセージがある。これらをフィルタ分けできる効率的な方法は存在しないし、もちろん事後に私がそれらをラベル付けすることは可能だけれど、私は電子メールに対して禅のアプローチをすると決めた以上、そういう手間はかけたくない。ここ一年以上使ってきて私が気付いた単純な事実は、その種の恣意的なコレクションは未だに一度も必要となったことはなく、私が必要とするメッセージは検索によっていつでも見つけられるということだ。
鋭い目をした読者の皆さんは、結局私のメールの大多数が Inbox に残ってしまう、いや正確に言えば Inbox ラベルを持ち続ける、ということにお気付きだろう。そう、別の言葉で言い替えれば、Inbox Zero は忘れるべきなのだ。私は現在 Inbox ラベルの付いたメッセージを 40,000 通ほど持っている。でも，お分かりだろうか、それは私の実際の使用には何の影響も与えない。なぜなら、Inbox というのは単なる一つのラベルに過ぎないからだ。だから、そのラベルの付いた個々のメッセージにわざわざもう一つずつアクションを施して削除しなければならない必然性など何もない。このことは、過ぎし時代の電子メールプログラムの挙動を再現したいと思っている多くの人たちにとってはきっと気に障るだろう。そこで Google は Archive (アーカイブ) ボタンを追加して、これをクリックすれば Inbox ラベルが取り除かれるようにした。このボタンがするのはそれだけのことだ。だからして、それは完全に不必要な作業だ。なぜなら、Inbox に触らずそのままにしても何の不利益にもならないからだ。
私はメッセージを手でファイル分けすることがほとんどないばかりか、メッセージを削除することすらほとんどしない。Gmail は、迷惑メールとマークされたメッセージを 30 日後に自動的に削除するが、それ以外で私が削除するものといえば、テスト用のメッセージ（TidBITS の号配布、Take Control の注文書、TidBITS コメントシステムからの通知文など）であって、もはや残す必要はないけれども将来の検索を混乱させかねないようなものだけだ。
そんなやり方は正気とは思えない、未読のメッセージが大量の他のものの中に埋もれて分からなくなってしまうだろう、ことに、Gmail は日付以外の順序でメッセージを並べ替えることができないのだから、とお思いかもしれない。でも、実際のところ、このやり方がうまく行く理由が二つある。その一つは "is:unread is:inbox" による検索で、もう一つは Google が新たに登場させた Priority Inbox (優先トレイ) 機能だ。
"is:unread is:inbox" 検索をすれば、Inbox ラベルが付いていて未読であるメッセージがすべて表示される。これにより、いつでも私はそれらのメッセージのみに集中することができる。そして、さきほど触れた Quick Link ウィジェットを覚えておられるだろうか？ 私はこの "is:unread is:inbox" 検索をカプセル化して Unread Inbox という名前の Quick Link とし、さらにそれを私の受信トレイのデフォルト表示に設定したのだ。
Gmail に Priority Inbox 機能が装備されるより以前、私はこの検索に大きく依存していた。けれども今は、Priority Inbox がまだ稼動し始めたばかりだった頃に Priority Inbox と私の双方ともが見逃してしまっていたメッセージを見つけ出すためだけにこの検索を使っている。
救いの手は Priority Inbox -- Priority Inbox (優先トレイ) は、比較的新しい Gmail の機能だ。これも、Gmail が電子メールの概念を考え直しているやり方の実例の一つだ。皆さんはたぶん迷惑メールフィルタがメッセージを分析してメッセージが迷惑メールかどうかを判断し、その際にあなたが以前に他のどんなメッセージを迷惑メールとマーク付けしたかを判断の基盤に置いていることをご存じだろう。Priority Inbox も、同じようなやり方で動作する。ただ、迷惑メールを判定する代わりに、あなたにとって重要なメッセージを判定するのだ。
どうやってそれをするのか？ Gmail は、初めのうちは何が重要で何がそうでないかを推測に基づいて切り分ける。そして、その後あなたが使いながらそれに修正を加えて行くのだ。驚くほど短い期間内に、きっとあなたは最も大切なメッセージが優先トレイに登場して、それ以外のメッセージは Gmail ウィンドウの一番下にある「その他のメール」という部分にリストされるようになっていることに気付かされるだろう。いったいなぜ Gmail が重要と判断したのかを疑問に思ったら、そのメッセージが重要だと示している小さな黄色いアイコンの上にポインタをかざしてみれば、または、そのメッセージを開いているならば「詳細を表示」リンクをクリックすれば、重要な理由が表示される。
この Priority Inbox はかなり順応性が高い。実際、最大４つのセクションが提供され、そのうち最初の３つのセクションはカスタマイズ可能だ。カスタマイズ可能なセクションそれぞれで、Gmail がその部分に表示する対象を、重要な未読メール、重要、未読、スター付き、のいずれかから選べるし、あるいは Gmail に一つのラベルの内容をそのセクションに表示させることもできる。これら４つのセクションのいずれでも、最大何個のメッセージを表示するかが設定できる。
私は Priority Inbox の各セクションを次のように設定している。最初のセクションは重要な未読メールを表示し、第二のセクションはスター付き（あとで対処する必要のあるもの）を、第三のセクションは私の Press Releases ラベルの付いたもの（参照の必要があるけれども、受信トレイを取り散らかして欲しくないもの）を、最後のセクションはその他のメールを、それぞれ表示する。実際私はこの「その他のメール」セクションで普段かなりの時間を費やしている。重要と判断されなかった新着メッセージはここに登場するのだし、また重要なメールも私がいったん読み終わればここに移動するのだから。
私がこの Priority Inbox に実現して欲しいと希望するのは、過去に私がラベル付けしたメッセージに基づいて Gmail が自動的にメッセージをラベル付けしてくれる機能だ。もしそれが実現すれば、Gmail に学習させることによって特定の話題やプロジェクトに関するメッセージを集め、時間の経過に伴って自動的にそれぞれのグループに追加されるようにできることだろう。
私が今の段落を書いていたすぐ後に、Google は新たな Gmail Labs 機能を導入した。その名も Smart Labels (スマートラベル)、これはおおよそ私が希望したことを実現すると約束している。残念なことに、Smart Labels が割り当てることのできるのは、あらかじめ決められた三つのラベル、Bulk, Forums, Notifications のみだ。私の使いたいフィルタは私の用途のために作ったものなので、もっとずっと具体的な設定になっている。もしもあなたが Gmail を使い始めたばかりならば、Smart Labels をしばらく使ってみて、現在の機能で十分使えるかどうか試してみるのもよいのではなかろうか。
私の電子メールフローチャート -- まとめてみると、私が電子メールを使うやり方は以下のようなものだ。メッセージが Gmail に届く。まずフィルタによって、メーリングリストから到着したメッセージや、その他いくつかの種類の予測可能なタイプのメッセージに対し、ラベルが付けられる。重要なメーリングリストからのメッセージには、すぐ私の目に留まるように Inbox ラベルも付く。それ以外のメーリングリストからのものには Inbox ラベルが付かない。以上のことはすべて、私が一切気付きもしないうちに起こる。（この点が、ひっきりなしにメールをチェックしたりフィルタの状態やら何やらを表示していた伝統的なメールプログラムと違うところだ。）
メールを読み始めるために、私はまず自分の Gmail ウィンドウの一番上を見る。そこには、優先トレイの「重要な未読メール」セクションが、最も新しいメッセージをリストしている。私はその最初の未読メッセージをクリックしてそれを読む。そこから、私がそのメッセージに対してすることは以下の七通りのうちのどれかだ。（私が最も頻繁にするものから順に並べてみよう。）
何もしない。単に、そのメッセージやその添付ファイルに含まれている情報を自分の中に取り込むだけ。一つ、Gmail で素敵なことがある。よくあるタイプの添付ファイルの多くをオンラインで読むことができ、ダウンロードして別のプログラムで開いたりする必要がない。Eudora を使っていた時代、私のハードディスクにどれほど数多くの多種多様な添付ファイルが散らかっていたか、あなたには想像もつかないだろう。
メッセージに返信する。共通の Subject 行を持つメッセージを Gmail は常にひとまとめにするので、返信のメッセージが元のメッセージと並んで保存される。そのため、会話のスレッドを辿るのが簡単にできる。私はこの機能に大いに依存している。
そのメッセージを未読とマークする。時々、そのメッセージをまだ読んでいないふりをしたくなることがある。約束の時間に遅れそうになっている時にそれを目にしたとか、夜遅くなってきちんとした返信ができるほど考えがまとまらないとかいう場合だ。あるいは、私は時々 iPhone で電子メールを読むことがあるが（iPhone のモバイル Gmail クライアントはなかなかよく出来ているけれど、iPhone のどうしようもないテキスト入力機能を埋め合わせできるほどではない）その場合はきちんとした返信を要するメッセージをいったん未読とマークしておくことが多い。
返信をしていようといまいと、そのメッセージにスターを付ける。私の場合、このスターというマーカーは「このメッセージの内容に関して本当に何かしなければならないので、理論的にはあとでこれを見つけられるように印を付けておく」という意味だ。でも現実的には、このスターも私の新たな死の接吻と化している。時々はこのセクションを見てスターの付いたメッセージに何かをすることもあるけれど、そんな場合でも実はその問題を私自身既に処理済みであったり、時間の経過とともにもはや無意味なものとなっていたりすることも多い。そういうわけだ。
手動でラベルを付ける。注文の受領書や、その他のメッセージで、フィルタで自動的にラベルが付けられなかったものの場合だ。やはりこれも、ほんの時たまにしかしない。たいていは不必要な作業だからだ。
「迷惑メールを報告」ボタンをクリックする。その迷惑メールメッセージが、Postini のサーバ側フィルタリングと Gmail 独自の非常に高性能なスパムフィルタの両方ともをすり抜けてきた場合だ。Postini は現在 Google の所有となっているが、それがスパムフィルタリングにどう影響しているのか私は知らない。
そのメッセージを削除する。私はごくたまにしかこれをしない。それも、削除するのはテスト用のメッセージのみだ。私は、受信トレイからメッセージを取り除くために Gmail の Archive (アーカイブ) オプションを使うことは決してしない。受信トレイからメッセージをクリアすることが楽しいゲームでなくなった以上、そんなことをしても何の利益にもならないからだ。
「迷惑メールを報告」ボタンと「削除」ボタンは、Inbox ラベルを取り除いた上にそれぞれ Spam と Trash のラベルを付けるので、これらのメッセージは完全に表示から消え失せる。（もはや、検索にかからなくなるからだ。）そして私はもう一度未読メッセージのリストへと戻る。今読んでいるメッセージを未読とマークした場合も、同じようにメッセージリストに戻る。いずれも道理にかなったことだ。
それ以外のアクションすべて、返信、スター付け、ラベル付け、それに何もしなかった場合も、私はキーボードショートカット (k キー) を押して次のメッセージに移る。そのメッセージで、今述べてきたシンプルな手順をもう一度辿るわけだ。大多数のメッセージで、私が決断しなければならないのはそのメッセージを読んでいないふりをするかどうか、それから返信の必要があるかどうかだけだ。そしてごく少数の状況で、後日何らかの方法で対処する必要があるのでそのメッセージをマークしておこうとか、さらなるラベル付けが必要かどうかとかを考える。
時折、私は Unread Inbox の Quick Link を使ってすべての未読メッセージを（重要度に関係なく）私の受信トレイに表示させる。ちょっとした手間だが、これは役に立つ。なぜなら、「その他のメール」リストは日付順に並んでいるので、ともするとあまり重要でない未読のメッセージが読まれないままリストの一番下の枠外に出てしまい、こうやって時折チェックしてやらないと永久に私の目に留まらないかもしれないからだ。
読んだり返信したりすることについては以上で全部だ。新規のメッセージを作成するのもやはり簡単だが、こちらはもともとすべての手順があまりにも単純なので Gmail としても伝統的な電子メールプログラムがしてきたことを改善する余地があまり見当たらない。誰かの名前の最初の数文字をタイプし始めると素晴らしく優秀な自動補完が働くし、あなたがその人に送信したことのある頻度に応じて並べられた候補のリストも表示される。それからもちろん、宛名の間違いを予防するための便利な拡張機能が Gmail Labs に用意されている。そこで、次の回の記事 "Zen and the Art of Gmail, Part 3: Gmail Labs" ではこの Gmail Labs を取り上げよう。その後最終回の記事 "Zen and the Art of Gmail, Part 3: Gmail Labs" では、Gmail をブラウザの外に取り出してくれる Mac アプリケーション、Mailplane について見てみよう。
コメントリンク12037 この記事について | Tweet リンク12037
文： TidBITS Staff <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
LogMeIn Ignition 2.0.264 -- 私たちは通常 TidBITS 監視リストの対象を Mac 用ソフトウェアに限っているが、 LogMeIn Ignition の 2.0.264 リリースはその Mac との統合のしかたにおいて紹介する価値がある。 この iOS 用遠隔スクリーンコントロールアプリのアップデートでは、多様な能力の数々に遠隔ファイルブラウズ機能が加わった。LogMeIn では無料のアカウントに登録する必要があり、その上でコントロール対象としたい Mac あるいは Windows システムに無料または有料のソフトウェアをインストールする。今回 Ignition のアップデートにより、ファイル一覧をブラウズして、ファイルをあなたの機器にコピーし、(iOS がサポートするフォーマットならば) 機器上でファイルを読み、印刷することもできる。また、このアプリを使ってあなたの LogMeIn アカウントに登録された二台のコンピュータの間でファイルを転送することもできる。(新規購入 $29.95、無料アップデート、9.8 MB)
LogMeIn Ignition 2.0.264 へのコメントリンク:
Things 1.4.5 -- Cultured Code の人たちが、Things 1.4.5 をリリースして自らの to-do リストから項目を一つ消すことができた。このタスク管理ユーティリティの新機能は、Things URI スキームのサポートだ。従来これは Things iOS アプリにしか装備されていなかった。また、Task Modification Date が AppleScript で利用できるようになった。修正されたバグも多数あり、主なものとしては同期の後に項目の順序が勝手に変わってしまっていた問題、検索結果の中で項目を完了とマーク付けすると Inbox に移ってしまった問題、タスクやプロジェクトをグループ分けしたり並べ替えたりする際の問題、繰り返し起こるタスクに関係したさまざまの問題、Mac OS X 10.4 でのクラッシュなどがある。(新規購入 $49.95、無料アップデート、8.0 MB)
Skype 5.1.0.914 -- voice-over-IP 電話アプリケーション Skype のバージョン 5.1.0.914 では、なくなってしまっていた機能が一つ復活した。グループ通話の際に現在話している人の名前がハイライト表示される機能だ。また、ダイヤルパッドで最近通話した番号を選択できる機能も今回のリリースに盛り込まれた。さらに、Skype によれば、ビデオカメラの探知の問題などマイナーなバグもいくつか修正されているという。(無料、20.2 MB)
NoteBook 3.0.9 -- Circus Ponies が NoteBook 3.0.9 をリリースした。このノート取りおよびテキスト収集ユーティリティのアップデートでは、多数の問題点が修正された。別ウィンドウで開いているページを持つ notebook を保存した際にクラッシュするバグや、iCal 同期に関係したクラッシュなどだ。その他、テキスト選択に関する問題点、Spotlight 読み込みでの問題、形状の変更をやり直しした場合の問題点、いくつかの細かなメモリリーク、持続するフラグでの問題、Find パネルでの欠陥、などのバグも修正された。(新規購入 $49.95、無料アップデート、無料の試用版あり)
PDFpen と PDFpenPro 5.2.2 -- Smile が PDFpen と PDFpenPro のバージョン 5.2.2 をリリースし、スキャンしたファイルの行き先を選択できる機能が追加された。OCR に関係してハングしてしまう問題など、非常に多数のバグ修正も施されている。日本語のヘルプテキストもフルに装備された。(新規購入 $59.95、無料アップデート、アップグレード $25、41 MB)
Aperture 3.1.2 -- iPhoto から Aperture へ切り替えようかと考慮中の写真家の方々に朗報だ。Apple が、Aperture 3.1.2 をリリースした。全体的な安定性とパフォーマンスを改善したことに加え、このアップデートでは写真を iPhoto から読み込む際の数多くの問題点に対処を施している。そのうち少なくとも一つは Aperture のクラッシュを引き起こすことのある問題であった。その他にも読み込みに関する数多くの問題点が修正されている。さらに、参照イメージや、ライブラリ間での切り替えに関するバグ、ブラシを使用する際のハング、Retouch でのクラッシュ、XMP Sidecar ファイルでの互換性の問題なども修正された。当然ながら、Mac App Store で購入した人は、このソフトウェアのアップデートも同じストア経由でしなければならない。(Mac App Store では $79.99、無料アップデート、Mac App Store からは 578 MB、Apple のウェブサイトからの独立アップデータは 297.63 MB)
MarsEdit 3.2 -- Red Sweater Software のブログ作成ツール MarsEdit がバージョン 3.2 に到達し、いくつかの新機能をお披露目した。継続的語数カウントが投稿ステータスバーに表示されるようになり、WordPress タグの処理が改善され、不正な形式の XML や「不正な文字」がソフトウェアをつまずかせることがなくなった。メディアブラウザや、自動保存機能のパフォーマンスも向上した。バグ修正も多数あり、Convert Line Breaks での問題、画像を添付した際にフォーマットが崩れる問題、Paste HTML Source の信頼性の問題などが解決した。クラッシュの問題もいくつか解消された。(新規購入 $39.95、無料アップデート、6.2 MB)
Firefox 4 -- Mozilla が Firefox 4をリリースした。このアップグレードでは、ユーザーインターフェイスを完全に刷新するとともに、Gecko 2.0 エンジンを基盤として動作するようになった。Mozilla によれば、その結果として JavaScript の実行速度が前バージョンのブラウザより最大 6 倍になり、HTML5 や CSS3 のサポートも大幅に改善されたという。Firefox は今回から Do Not Track ヘッダをサポートし、Firefox Sync を標準装備し、Google の WebM 動画形式に対応し、プラグインのクラッシュをより良く処理できるようになった。かなり長いリリースノートが Mozilla のウェブサイトにある。(無料、26.8 MB)
Sparrow 1.1 -- iOS に触発された電子メールソフトウェア Sparrow がバージョン 1.1 にアップデートされた。今回のバージョンから、Sparrow は以前よりずっと多くのタイプの電子メールアカウントをサポートするようになった。Gmail に加えて、このソフトウェアを MobileMe、Yahoo!、AOL、それから任意の IMAP アカウントで使えるようになった。また、Gmail においては優先トレイ、未読セクション表示、アカウントごとの署名、より豊かなメッセージを作成するためのフォーマットバーなどのサポートも新設された。Sparrow ではマルチタッチのジェスチャー、コンタクト先グループ、Gravatar のサポートもされるようになった。さらに、バグも二十件ほど修正された。(Mac App Store からは $9.99、無料アップデート、無料の lite 版もあり、10.2 MB)
Skitch 1.0.4 -- スクリーンショットをシェアする諸君は盛大に祝福を唱和しよう。（早口で五回言えればお見事。） Skitch がバージョン 1.0.4 になった。最も重要な新機能は、このソフトウェアの使用のために skitch.com アカウントを作る必要がなくなったことだ。その他の改善点としては Welcome スクリーンの簡略化、一部の 10.6.6 ユーザーに起こっていたクラッシュの修正などがある。(無料、6.5 MB)
文： TidBITS Staff <[email protected]>
訳： Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
いくつか重要なカンファレンスの日程が発表になり、Apple 社重役の重要人物が退職し、Apple が iTunes 経由で日本での救援活動への寄付ができるようにし、電話の通話というものが以前ほどの役割を担わなくなったと考察する New York Times の記事も紹介する。読み応えあり！
WWDC 2011、サンフランシスコで 6 月 6 日から 10 日まで -- Apple が、同社の 2011 Worldwide Developer Conference が 6 月 6 日から 10 日までサンフランシスコの Moscone West で開催されると発表した。カンファレンスパスの価格は $1,599 だが、発売当日に売り切れてしまったのでもう入手できない。
MacTech Conference 2011 は LA で 11 月 2 日から 4 日まで -- WWDC は主として開発者たちを狙っていて Apple との意思疎通を提供するためのものだが、独立独歩の行き方に興味ある人は 2011 MacTech Conference の方を検討してみるべきだろう。こちらは 11 月 2 日から 4 日までロサンゼルスで開催される。ホテルをベースとした MacTech Conference は二つのトラックを提供する。一つは IT 関係の話題に焦点を置くもの、もう一つは Mac と iOS でのソフトウェア開発に関するものだ。カンファレンスの登録料金は $999 だが、枚数限定の早期購入ならば $799 となる。
Bertrand Serlet が Apple を退社 -- Apple の Mac Software Engineering 担当上席副社長 Bertrand Serlet が Apple を去ることとなった。後任は現在 Mac Software Engineering 担当副社長である Craig Federighi が務める。Federighi も Serlet 同様に元 NeXT の社員であったが、最近の二年間は Mac OS ソフトウェアエンジニアリングのグループを率いる仕事をしていた。Serlet は、「Craig は過去二年間に Mac OS チームを率いて素晴らしい業績をあげてきた。Lion は素晴らしいリリースであり、移行はシームレスに進むはずだ」と述べている。
電話の通話というものは消え去るのか？ -- New York Times に載ったこの記事には私たちも共感した。私たちの場合、スタッフ同士の通話はあらかじめスケジュール予約する（たいてい通話は Skype でする）のが常だし、その場で必要になった通話さえもまずは iChat で確認してからだ。いきなりかかってくる電話の通話もたいていあらかじめ caller ID (発信者番号通知) で確認できるし、そうでないもののほとんどは何かのセールスの電話だ。私たちも、この記事の言っていることに賛成だ。電話の通話は、相手の予定を尊重しつつ対応をお願いすべきものであって、理由も分からずに何もかも打ち捨てることを要求すべきものではない。
日本の救援活動に iTunes 経由で寄付を -- 日本における救援活動に手を差し伸べやすいようにするために、Apple は iTunes Store に寄付を受け付けるページを設けた。ここに寄せられた寄付の 100 パーセントが直接 American Red Cross (米国赤十字社) に送られる。
TidBITS は、タイムリーなニュース、洞察溢れる解説、奥の深いレビューを Macintosh とインターネット共同体にお届けする無料の週刊ニュースレターです。ご友人には自由にご転送ください。できれば購読をお薦めください。
非営利、非商用の出版物、Web サイトは、フルクレジットを明記すれば記事を転載または記事へのリンクができます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありません。告示：書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017
©Copyright 2011 TidBITS: 再使用はCreative Commons ライセンスによります。
, 
日本語版最終更新：2011年 4月 3日 日曜日, S. HOSOKAWA