TidBITS: Apple News for the Rest of Us  TidBITS#842/14-Aug-06

Steve Jobs は先週の Worldwide Developer Conference で Mac OS X 10.5 Leopard のプレビューをしたが、まだまだ秘密の機能があるという彼の言葉が私たちの好奇心をそそった。そこで今週は、来年になって Leopard が出荷された時にカーテンの陰から飛び出て欲しいと私たちが願う機能や修正点など、私たちの「お願いリスト」をまとめてみることにした。また今週号では Matt Neuburg が、Microsoft が Microsoft Office for Macintosh の次期バージョンで Visual Basic を廃止するとしたことについて検討し、それから Adam が共同編集プログラムについてさらに考察を加えるとともに、最新の iPod ソフトウェアアップデートを施した彼の iPod nano が再生中にス、ス、スキップするようになったことを報告する。また、今年度の Apple Design Awards の受賞者たちを紹介し、lynda.com の Online Training Library が当たる DealBITS 抽選についてお知らせする。

記事:


Copyright 2005 TidBITS: Reuse governed by Creative Commons license
<http://www.tidbits.com/terms/> Contact: <editors@tidbits.com>


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


アップデート後の iPod nano がスキップ

文: Adam C. Engst <ace@tidbits.com>
訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

もっと早くこれを書こうと思いつつ延び延びになってしまったが、でも私がこのことを思い出すのは車に乗っていて、私たちの iPod nano でポッドキャストや音楽を聞く時だけなのだ。一番最近の iPod アップデート、つまり iPod Updater 2006-06-28 を施して以来、私たちの iPod nano は頻繁に(車に乗る度に少なくとも一回ずつは)1 秒から 2 秒程度の乱れた再生状態が混じるようになってしまった。他にもう一人の人も TidBITS Talk でこのことを報告している。ただ、この問題が広く行き渡ったものなのかどうかは明らかではない。この iPod Updater 2006-06-28 には iPod nano Software 1.2 が含まれ、Nike+iPod のサポート(および明記されていないその他のバグ修正)が追加されているので、もしもあなたが アップル - Nike+iPod(詳しくはiPod を掴んで走り出せ を参照)をお使いではないならば、この iPod アップデートはしばらく施さずに様子を見ておく方がいいのではないかと思う。Apple はこの問題を認識しており、現在間違いなく修正に取り組んでいるはずだ。

もしもあなたがこの問題に相当苦しめられているのなら、その前の iPod nano Software 1.1.1 に復旧させることもできる。/Applications/Utilities フォルダの中を見れば、iPod Software Updater フォルダがある。その中に、古い iPod アップデータもある。私は、一番新しい方から二番目の、iPod Updater 2006-03-23 を起動させて、Restore ボタンをクリックした。(注意すべきなのはこれをすると iPod の内容がすべて消去されてしまうことだ。だから、この復旧を実行するのはいずれにしてもあなたがすべてを Mac からロードさせている場合に限られる。)これで、復旧が実行された。音楽やポッドキャストを iPod nano の中へコピーする前に、iTunes は私にあの悪いアップデートをインストールするようにと勧めてきた。もちろん私はそれに異議を唱えたので、すべてはうまく行った。その後私はテストのためにもう一度あの悪いアップデートをインストールしてみたが、乱れた再生の問題はやはり再び起こった。そこで私はもう一度初めからやり直して iPod nano Software 1.1.1 に戻した。ちょうどわが家にも Nike+iPod Sport Kit が届いたところなので、これをテストする気になったら、もう一度この問題に取り組んでみたいと思う。


DealBITS 抽選: lynda.com の Online Training Library

文: Adam C. Engst <ace@tidbits.com>
訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

ソフトウェアを習うベストの方法は、人それぞれだ。自分で気ままにプログラムを使ってみるのが一番という人もいれば、例えば私たちの Take Control 電子ブックのどれかのような、何か参考書を読むのがよいという人もいる。また教室で教わるのが一番という人も多い。けれどもここにもう一つ新たなトレーニングの方法が、それも最近ますます人気上昇中の方法がある。インターネットを通じたビデオトレーニングだ。この分野でおそらく最もよく知られた会社は、少なくとも Mac ユーザーにとって興味のある話題を提供するものの中で最も知られているのは、Lynda Weinman が 1995 年に創設した lynda.com だ。lynda.com はおよそ 250 のトレーニングプログラムを持っており、その多くは Macintosh ソフトウェアを扱っていて、ベストセラーの本や電子ブックなどを書いてきたのと同じ面々の著者たちによって作られたものばかりだ。だから、もしもあなたがオンラインのビデオトレーニングに興味があるなら、ぜひ lynda.com's Online Training Library でトピック一覧を眺めてみて頂きたい。すべてのタイトルに無料のサンプルが付いているので、あなたの仕事に役立つものなのかどうか試してみることができる。

今週の DealBITS 抽選では、lynda.com の Online Training Library の一年間 premium 購読($375 相当)を1本、賞品にする。幸運が足りずに当選から漏れた応募者には、Online Training Library 購読の大幅な割引価格の資格が贈られるので、ぜひ奮って下記リンクの DealBITS ページで応募して頂きたい。寄せられた情報のすべては TidBITS プライバシー規約 の下で扱われる。どうかご自分のスパムフィルターに注意されたい。当選したかどうかをお知らせする私のアドレスからのメールを、あなたに受け取って頂くのだから。また、もしもあなたがこの抽選を紹介して下さった方が当選すれば、紹介に対するお礼としてあなたの手にも同じ賞品が届くことになるのもお忘れなく。

[訳注: 応募期間は 11:59 PM PDT, 20-Aug-2006 まで、つまり日本時間で 8 月 21 日(月曜日)の午後 4 時頃までとなっています。]


Visual Basic プロセッサ戦争のまきぞえに

文: Matt Neuburg <matt@tidbits.com>
訳: 亀岡孝仁 <takkameoka@bellsouth.net>

先週の Microsoft の Macintosh Business Unit (MacBU) からの Virtual PC for Mac の継続中止と、将来の Microsoft Office for Mac では Visual Basic マクロのサポートはしないと言う発表は野火のような噂に火をつけたが、何時もの様に、こういう時には冷静な心構えこそが何よりも強い味方となる。

Virtual PC はどう見ても中途半端と言わざるを得なかった。せいぜい REALbasic で書かれたクロスプラットフォームのアプリケーションをゆっくりと試してみるのに十分な程度であって、とてもまともな Windows ベースの仕事をするためのものではなかった。個人的には、私は別にこれが無くなってどうと言うことではない。むしろ Intel ベースの Mac を買いそして Parallels Desktop を走らせるのが待ち遠しい。そうすれば Dragon Naturally Speaking をついに試せるからである。

Visual Basic に関して言えば、このニュースは私には殆ど全部良い話の様に見える。Office の Mac 版での Visual Basic のサポートは常に気難しいハックであったし (どれぐらい気難しいかについては Erik Schwiebert のブログRick Schaut の とを参照して欲しい)、とても Windows 版と較べられるようのものではなかった;これが廃止になるというのは、むしろ解放につながるといえる。

ここでの真のメッセージは、Mac Office がついに完全に Xcode に移行したということである。ということは、Office の universal binary 化も夢物語ではなく現実に近づいたという事を意味する。言ってみれば、MacBU はラクダを針の穴に通すことに成功したのである;この過程でそのこぶの一つが取れてしまった (Visual Basic のサポート) という事実もその成果を損なうものではない。それに、考えてみれば Visual Basic が走れない Microsoft Office なら、マクロウィルスに感染した Word 書類を受け取るという危険性から来る、今日多くの人の Mac に存在している最大のセキュリティホールを閉じてくれるではないか。最後に、Office の自動化は AppleScript でもやれるのである。このサポートは Office 2004 で実に素晴らしくなったのだが、背後にある Visual Basic という足かせが無くなり AppleScript コマンドがどう形成されねばならないかを命令されることが無くなれば、更に良くなるというものであろう。

それでも Windows ユーザーに協力するために Visual Basic への対応が必要となる場合はどうすればいいのか?私の想像では、Office 2004 (もしすでに Intel への移行が完了しているのであれば、Rosetta の下で) を使い続けるのであろう;それでその後の Office の改善のいくつかが使えなくなるというのはお気の毒ではあるが、それを苦痛と呼ぶのは強すぎるというものである。

今の私に見えていないのは、Excel のユーザーがカスタムの機能をどうやって書くのか (マクロを使わずに) ということである。例え Excel が AppleScript を呼び込めたとしても AppleScript の計算式はとてもそこまで及ばない。そうであれば、MacBU はこの問題に目をつぶって Excel をかたわものにしてしまうか、それとも全く革新的な解を考えつくかしなければならない。時間が経てばわかる話である。


Apple Design Award 2006 の受賞者たち

文: Jeff Carlson <jeffc@tidbits.com>
訳: 羽鳥公士郎 <hatori@ousaan.com>

Apple の Worldwide Developer Conference(WWDC)は、毎年恒例の Apple Design Award 受賞者発表で、今年の幕を閉じた。受賞者が手に入れたのは、名声と、Mac 開発者としての信用、そして、触れると明かりのつく立方体のスペシャルトロフィーだ。(この奇跡の照明はどのように実現されているのだろうか。2004 年度学生プロジェクト賞の受賞者たちは、普通の人たちと同じように単純にこれを分解しようとは考えなかった。彼らは、 CT スキャナを使って内部をのぞき、そしてもちろん、立体再現模型を作成した!)

今年の受賞者の皆さん、おめでとう。そして読者の皆さんには、彼らのウェブサイトを訪れ、彼らが選ばれた理由を感じ取っていただくことをお勧めする。


共同編集プログラムについてさらに考える

文: Adam C. Engst <ace@tidbits.com>
訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

2006 年 7 月 24 日号の TidBITS に私が書いた記事 Mac 開発者求む: 共同編集プログラム開発されたし に皆さんから寄せて頂いたたくさんのメールやコメントに、まず感謝を申し上げたい。私の記事に頂いたコメントや、Jason Snell が post on Macworld.comに出したポスト もあり、私たちは、提起された共同編集プログラムが欲しくてたまらないというユーザーたちとも、またそれを書くことを考えてもよいという何人かの開発者たちとも、いろいろと話し合いを続けてきた。だからといってもうこれ以上開発者は要らないなどとは言っていない。人数が多ければ多いほど、楽しいに違いない。それにもしも誰かがオープンソースのプロジェクトを開始するということになれば、間違いなく追加の人手は大歓迎となるだろう。しかしながら、誤解や思い違いも一つ二つあるようなので、ここで私たちはそこのところを明確にしておきたい。

SubEthaEdit とリアルタイムのツール -- まず第一に、大勢の方々から、The Coding Monkeys の SubEthaEdit を検討してみたかという質問を頂いた。その答はイエスでありノーでもある。私たちは SubEthaEdit についてよく知っているし時折使ったこともあるが、これは次のような二つの理由から、私たちが考えているようなタイプのグループ共同作業には全く不向きだ。

さきほど述べたように、私たちはグループで一つの記事に取り組む時にはいつも SubEthaEdit を使っている。例えば、先週号で WWDC での発表についての記事を書いた時もそうだった。私たちは SubEthaEdit を動かして、皆が共有の書類の中に文章を書き込んだ。(少なくとも、編集をした。同じ書類に他の人がものを書いているのが見えるのは、非常に気が散るものだという人もいるからだ。)皆が記事のそれぞれの部分を書くように分担したのだ。そして今週も、この次の Leopard 欲しい物リストの記事を SubEthaEdit で書いた。これも、大勢の人たちがそれぞれ小さな分量ずつを分担して書いたからだ。

保存の問題については、私たちはその書類を作った人がオートセーブのユーティリティを走らせるという対策を試しているところだ。現在、GoldfishSoft の $20 のシェアウェア、SaveMe を使ってみている。どうやらこれはうまく目的に適っているようだ。(ただ、デモ版の状態では 30 回セーブを実行するとタイムアウトになってしまうので、長時間続けて使った時にうまくいくのかどうかは何とも言えない。)それからこれも付け加えておきたいが、現在のバージョンの SubEthaEdit 自体ももう無料ではない。無料版の SubEthaEdit と現バージョンの SubEthaEdit 2.5 の間にはかなり大きな変更が施されていて、しかもそれらの変更は共同作業ツールとしての機能というよりもテキストエディタとしての能力に関するものが中心だ。幸いにも、今でもまだ 古いバージョンの SubEthaEdit は無料でダウンロードできるようになっている。

何人かの人たちから、AquaMinds の NoteShare を推す声も挙がった。けれどもこれもやはりリアルタイムのツールだ。ただし、一つの共有ノートブックは同時には一人ずつの人しか編集ができないようにチェックが追加されている。そのお陰で同時に複数のセットで変更を追跡する必要はなくなるが、一方では協同編集をしているチームが一つのノートブックにつき一つずつの書類しか持てないということも意味している。そのノートブックの中にたくさん書類があっても、一人の人が他の人すべてをそれらの書類全部からロックアウトしなければならないことになるからだ。NoteShare はまだバージョン 1.0 の製品で、一見して明らかにそうとわかるが、今後いろいろと使い勝手のある方向に進化しそうだ。AquaMinds から出されたコメントでも、将来のバージョンでは一つのノートブックに同時に複数の編集者を許容したり、バージョン管理の機能も盛り込んだりして行きたいと述べられていたから。

テキスト生成が目的、出版ではない -- 第二に、私たちの提起した GroupEdit が出版プロセスのどの段階に位置するのかを正しく理解していない人たちも多かった。プロフェッショナルの出版環境では、テキストはまず著者によって書かれ、一人あるいは数人の編集者によって編集されコメントを付けられてから、著者のところに戻り、それから第一編集者に戻され、その後コピーエディタ・校正者のところに行き、そしてそれらが全部済んだ最後の段階になって初めて、印刷出版用ソフトウェアやウェブコンテンツ管理システムなどに送られることになるのだ。

多くのインターネット出版の現場では、中でもウェブログや wiki のようなアプローチを使う場合には、協同作業がこの処理の最後の段階に来ることもある。ウェブログの項目がコメントやリンクを集めるのはそれがポストされた後だし、また wiki の項目が修正を受けることができるようになるのは本来それが出版された後になってからだ。これは、ウェブログというものがもともと個人的な出版というパラダイムから進化したものであり、また wiki の方は長らくグループ指向を持っていたものの、例えば Wikipedia のような公開の wiki における項目はそれが作られたその瞬間から公共の協同作業に供されているのであって、公式に「出版」されるというような段階を経ないからだ。

というわけで、私たちが GroupEdit に求めているものは、出版よりも以前のプロセスをサポートしてくれるツール、一般の人たちが最後の結果を見るよりもはるかに前の段階の話だ。私たちはソーセージを欲しがっているのではなくて、ソーセージに詰める材料を欲しがっているのだ。そしてまさに、人の手と人の手の間を行き来しつつ、より良く書かれ、より良く編集され、十分に校正を経たものを目指して練り上げて行く様はソーセージを作る作業と同じことだ。それは必ずしも見た目に華やかなものでもなく、たいていの出版者ならば読者の目には触れさせたくないと思うようなものだ。私は Wikipedia にそれほど深く関与したことがある訳ではないが、私の印象では論争の焦点となるような Wikipedia 項目を作り出す際にはこのソーセージ作りの作業がかなりの程度、人目に晒されてしまう。Wikipedia ならばそれでよいのかもしれないが、たいていの出版者はそれを避けたいと思うものだ。

私がこういうことを長々と語ってきたのは、例えばウェブログ用のユーティリティや wiki、さらには Macromedia Contribute のようなプログラムといったようなウェブ出版をするためのツールでは私たちの目的に見合ったものを提供することができないということの、どちらかと言えば基本的な理由を説明してみたいと思ったからだ。そうしたツールはどれもこれも、出版プロセスの最後の段階をサポートするために工夫が凝らされており、草稿段階の書類が著者の手と何人もの編集者たちの手との間で素早く何度も行き来するような、初期の段階のことは考慮されていない。(この行き来は高速であればあるほど望ましい。ただし、現状のツールはまだまだ高速の移行をひどく妨げるようなものばかりだが。)

私たちの必要を満たす目的に現在一番近いところにあるプログラムは、たぶん Adobe InCopy だと思う。これは InDesign と統合されて、何人ものライターたちが InDesign のレイアウトのために使うテキストをよりスムーズに作業できるように作られている。この InCopy は私たちの望む基本的機能の多くを備えているようだが、根本的な問題はこれが元来 InDesign との統合のために作られていてライターたちとデザイナーたちの協同作業を意図しており、ライターたちと編集者たちとの協同作業は意識されていないという点だ。その上一本あたり $250 という値段では、私たちにしろ Macworld にしろ、そうそう気軽にフリーランスのライターたちに配ることができるようなものではない。

RFP に立ち戻る -- そこで、私はやはり皆さんにもう一度私たちの RFP(提案依頼書)を QuickTopic Document Review で読んでみて頂ければとお勧めしたい。そして、この提案依頼にさらに改良を加えたり拡張をしたりできるような積極的なコメントを寄せて頂ければ、またそのようなプロジェクトに興味を持つかもしれない Macintosh ソフトウェア開発者、さらにはこの RFP に概略を説明した機能が加われば何か恩恵を得るところがあるようなコードを持っている Macintosh ソフトウェア開発者がいればそういう人にも、このことを知らせて頂けるならば嬉しく思う。これまでのところ、この RFP が誘発したコメントや議論は非常に得るところも多く、まさに私たちがそうあって欲しいと望んだ状態だ。今後もぜひこの対話を続けて、その結果として GroupEdit に沿った線で何か具体的な開発がスタートするようになればと願っている。


Leopard 欲しい物リスト

文: TidBITS Staff <editors@tidbits.com>
訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
訳: 羽鳥公士郎 <hatori@ousaan.com>

先週の Worldwide Developer Conference のキーノートで、壇上で Mac OS X 10.5 Leopard について紹介しつつ、Steve Jobs ははっきりと、Leopard にはもっとたくさんの「トップ・シークレット」の機能が備わることになると言っていた。そこで私たちは考えてみた。これまでのバージョンの Mac OS X で Apple が何をしてきたかを思い出し、Leopard について発表されたものを考えれば、あとは何が残っているだろうか、と。Mac OS X をさらに改良するとすれば、まずどこに着目すべきか? 私たちスタッフはしばらく議論した結果、以下のようなリストをまとめあげた。(Leopard について Jobs が具体的に何を話したか、もっと詳しいことに興味のある人は、最近二回の MacNotables ポッドキャストをお聞き頂きたい。一つは Dan Frakes、Ted Landau、Bob LeVitus、それに Andy Ihnatko と一緒の パネルディスカッション で、もう一つは Adam 一人がゲストの番組 だ。)

走れ、走れ、もっと速く! -- あからさまに言ってしまえば、Mac OS X は全般的なユーザー体感としてまだまだ遅すぎる。問題点をハードウェアで補強すればある程度はカバーできるが、例えば Finder で作業をしたり、あるいはたくさんの異なったアプリケーションの間で切り替えたりする際には、やはり余計な一時停止が多すぎる。例の「死の回るピザ」も結構起こるので、ただ作業を続けるというだけのために無理にアプリケーションを切り替えて気を散らされるということもある。ただ、そのカラフルな輪が出たとしてもそれが必ずしもできるだけ早く再起動を余儀なくされるという訳ではないことが多くなったのはありがたいことだが。私たちとしては、ぜひとも Leopard では相当の努力を注ぎ込んで、十分新しいハードウェアを持つ Mac ユーザーたちならば誰もが違いを感じることができるような、そういう肝心な部分でのパフォーマンスの改善を図ってもらいたいと思う。新機能があるのは素晴らしいことだし、新バージョンに値札が付いているのに見合うだけのものを盛り込む必要があることは十分承知しているが、それでも既に備わっているものに微調整を加えて改善を施すことは、ただ単に日常的な活動に勢いを与えてくれるだけでなく、将来の改訂を見晴らす際にも大きな意味を持つことになるだろう。

もっと賢い Finder -- Finder について言えば、噂では Apple が Leopard のために Finder を改良中だということだし、私たちも皆それぞれお気に入りの不満を持っていて、パフォーマンスの改善以外にもこことここに対処の手が加えられたらいいのにと皆が思っていることだろう。今でも、新しいファイルが現われても Finder がそれに気付かないことがあって、どうひいき目に見てもこれは混乱させられることに違いない。それから、複数個のファイルを名前の一致するファイルが存在する場所へとコピーする時に出る警告の文章は、一個のファイルを同一名のファイルがある場所へコピーした場合に出るのと同様にどちらが新しいファイルなのかの情報を表示するように直すことが、やはり是非とも必要だ。その他の苦情としては、ファイル名の拡張辞を変更する際のデフォルトボタン(拡張辞を変更しようとしているのなら、ほとんどの場合その変更を意図的にしているのだから、そちらがデフォルトとなるべきだ)とか、ファイルを複製した後に Finder がオリジナルの方を選択してしまう(普通すぐその後はコピーの方で作業を続けるだろう)という問題、フォルダを改名した際に勝手にスクロールして見えないところに行ってしまうこと、それにコンテクストメニュ−の オリジナルを表示 項目のコマンドが必ずしもそのエイリアスのオリジナルファイルを表示しない(表示できることがあるのだろうか)という問題もある。Apple は、せめて Cocoatech の Path Finder でもよく見て、今述べたような、あるいはその他の、こまごまとした Finder の使用感の問題点を解決するヒントなどを学習してくれたらいいのに、とさえ思う。

もっと賢い認証法 -- あなたは、どれくらい頻繁に管理者パスワードを要求されることがあるだろうか? たぶん私たちほど頻繁ではないかもしれないが、きっとあなたはその度に、次に何が起こるかをこれっぽっちも考えもせずに、気楽にパスワードをタイプしているのではないだろうか。(私たちだって、たいていの場合そうなのだ!)だから Leopard では、こういう認証の要求がどれほど頻繁に出るかに関して、もっとしっかりした考慮が加えられればと思う。もっと要求の回数を減らすようにすれば、ユーザーたちももっと注意を払うようになるだろう。また、認証を要求するやり方についても考慮が欲しい。もっとわかりやすいものにしようという配慮があればと思う。一つの可能性として、セキュリティのレベルという概念を作るのはどうだろうか。それぞれのレベルごとに違ったタイプの認証要求が出るようにして、高いセキュリティレベルほどユーザーの側からより複雑なアクションが必要になるようにするのだ。そうなれば、例えば Applications フォルダにアプリケーションをインストールするだけのインストーラは比較的シンプルな認証だけでよく、その一方でインストーラがカーネル拡張をインストールすることも必要ならば、そのために要求する認証をもっと複雑なものにするのだ。(その際、インストーラが何をしようとしているかの情報も、ユーザーに詳しく知らせるよう義務づけることもできるわけだ。)

サービス管理 -- サービスが便利に使えてありがたいことは認めるが、あからさまに言ってしまえば、全体の状況は大混乱以外の何物でもない。どんなアプリケーションでもサービスを登録できるので、サービス メニュ−は正気とは思えないほどの数のサービスでごちゃごちゃになってしまう。その上、その多くが勝手にキーボードショートカットを乗っ取ったり、意味を理解するのが不可能だったりする。Leopard では、ユーザーのために何らかの方法で、どのサービスが使用可能かを管理し、キーボードショートカットをコントロールし、個々のサービスが実際にどんな機能を提供するのかがわかるような手段を提供して欲しいと思う。このことはつまり、開発者たちの側ではそれぞれのアプリケーションにメタデータを追加してサービスの内容を記述しなければならないということを意味しているが、ユーザーの側でも自分で説明を書き込めるような、そんな方法も提供すべきだろう。また、アプリケーションメニュ−の中の階層的 サービス メニュ−という、アクセスも面倒でほとんどのユーザーがその存在さえ気付かないようなものに頼るのではなく、もっと他のメカニズムを通じてサービスが利用できるようにして欲しい。例えば、いくつかのサービスだけをお気に入りとして登録して、それらだけがメニュ−バーの専用独立の サービス メニュ−(アイコンとして出るのはどうだろうか)でアクセスできるようになったら、と想像してみよう。(Peter Maurer のシェアウェア、 Service Scrubber は当座の方法としては良くできている。ただ、この種のオペレーティングシステムレベルのコントロールはやはり Apple によって提供されるべきものだろう。)

ホットキー管理 -- Mac OS X でキーボードショートカットを定義する方法は数多くある。アプリケーションの中でハードコード定義ができるし、アプリケーション独自にカスタマイズすることも、サービスが独自に定義することも、iKey、Keyboard Maestro、それに QuicKeys のような自動化ユーティリティや、LaunchBar や DragThing のようなランチャーが定義することもある。その上、Mac OS X 自身の キーボードとマウス 環境設定パネルでさえも定義できる。これだけたくさんの可能性があれば、一つのキーボードショートカットが何をするのだったか思い出すだけでも不可能に近いだろうし、時にはいくつかのキーボードショートカットが動かなくなって理由がさっぱりわからないということも起こる。Leopard では、ぜひ キーボードとマウス 環境設定パネルにすべての登録されたキーボードショートカットの中央管理センターとしての役割を持たせることで、この混乱状況をできる限り合理的な方向に向けるべきだ。

アクティブなセキュリティエージェント -- 時折、何らかのソフトウェアがデータを勝手にどこか自分の基地局に送っていたり、こっそりと入力マネージャをインストールしていたり、あるいはその他一般的に何かやるべきことでないことをしている、といったようなことが Mac の世界でも猛烈な大騒ぎになることがある。もちろん、Objective Development の Little Snitch とか、Open Door Networks の DoorStop のようなファイヤウォールとか、Sustainable Softworks の IPNetSentryX などのようなソフトウェアが立派な働きをしているのは認めるが、Leopard にはぜひアクティブなセキュリティエージェントを装備して、使用の標準的なパターンのプロファイルを組み上げるとともに、そのパターンから逸脱したり、疑わしいと知られているような挙動をしたりする何かがあれば、ユーザーに警告するようにして欲しい。Mac は長らくの間、高度にセキュアであるという定評を獲得してきた。けれども、その中でもあまり評判の良くない要素に注意を集中させれば、きっと脆弱性が見えてくるに違いないと考えることこそが安全への近道なのだし、ほんの少しの予防策が大きな救いとなることもあるものだ。

シームレスなネットワーク利用 -- このことについては要点を的確に指摘するのがちょっと難しいが、私の感じではネットワークベースのリソース、例えばファイルサーバやプリンタなどを使うのはまだ厄介な点が多すぎる。遅い、あるいは接続できないネットワークリソースを相手に作業する時には例の回る死のピザがしょっちゅう現われるし、もちろんそういうことがある程度避けられないのは疑いのないところだが、Leopard においてネットワーク使用がもっとシームレスになれば素晴らしいと思う。おそらくそのためには、不使用の時にもバックグラウンドでネットワーク接続をチェックして、要求があった時に確実に利用できるようににしておくとか、あるいはサーバへの接続が途切れた際に 2 分も待たずにすぐにエラーメッセージを提供するとかいうことが必要だろう。あるいはひょっとしたら、何らかの形の状況表示を提供して、ユーザーがそれを見てネットワークリソースが本当に利用可能かどうかを判断し、繋がらない接続を無理に試してみる必要がないようにするのが良いのかもしれない。いずれにしても、この分野で Leopard の挙動がどのように改良されるべきかは、Apple 社内でこれを読んでおられる読者の方々への宿題としておこう。

より良い複数モニタ認識 -- 私たち TidBITS スタッフの多くは、旅行に出ている時でない限り二台のモニタを使っている。つまり、デスクトップコンピュータではモニタを二台接続し、ラップトップでは第二モニタを追加することで、ワークスペースを最大限にしているのだ。けれども、Apple の Dock を使おうとするとフラストレーションが溜まることがある。これは、シングルモニタ上に表示された Dock の論理的位置が、二台のディスプレイではうまく良い位置に嵌まってくれるとは限らないからだ。Marcel Bresink のフリーウェア TinkerTool を使って Dock を画面の上の部分に位置させることもできるが、もしも Leopard で Dock が任意のディスプレイの任意の縁に置けるようになれば嬉しい。もちろんこれは複数モニタが存在している場合の話だ。もう一つ、複数モニタのファンが喜ぶと思われるオプションは、同じメニュ−バーを両方のスクリーンに表示できるようになれば、ということだ。そうすれば、ウィンドウがどのスクリーンに表示されていても、常に現在のウィンドウの上の方にメニュ−バーがあることになるだろうから。

メニューバーのアイコン管理 -- ほとんどのユーザのメニューバーの右端には、多くのアイコンが並んでいるだろう。これらの中には、システム環境設定パネルで設定するものもあれば、アプリケーションの環境設定で設定するものもあり、さらには Script メニューアイコンのように、アイコンをメニューに追加したり削除したりするための視覚的なインタフェースが見当たらないものもある。アイコンをメニューバーから Command-ドラッグして削除できるものもあれば、できないものもある。(Spotlight をメニューバーから決して使わないという人なら、これが前者の部類であったらよいのにと願っていることだろう。)これらのことを考えてみれば、Leopard では、メニューバーアイコンを追加したり削除したりするための方法を標準化し集中化したらよいと思う。複数の方法があっても問題ないが、必要のないアイコンすべてを1か所で削除できればうれしい。

拡張可能な環境設定マネージャ -- Mac OS 9 には「環境設定マネージャ」が内蔵されていて、ラップトップを別の場所へ動かしたときに、多数の設定を一度に切り替えることができた。Mac OS X 10.4 Tiger では、アップルメニューの「場所」サブメニューで場所の設定を変更すると、ネットワークの設定だけしか変更されない。これは第一歩としてはよいが、Mac OS 9 の環境設定マネージャと異なり、場所によって変更したいほかの設定には効果がない。例えばデフォルトのプリンタ、SMTP サーバ、時間帯、音量、省エネルギー設定などだ。 Location X と呼ばれるサードパーティ製品が、これらの機能のほとんどを実現しているが、Mac OS X 内蔵の「場所」機能が Mac OS 9 に比べてはるかに劣ったままだということについては、言い訳の余地はない。

お願いついでに、もうひとつ。場所を選ぶという仕事も、代わりに Mac がやってくれないものだろうか。例えば、自宅の AirPort 無線ネットワークに接続するとすぐに場所の設定がすべて有効になったり、あるいは T-Mobile などの公衆 Wi-Fi ネットワークに接続すると Mac OS X のファイアウォール設定が強化されたりするというのはどうだろう。(Location X にはこの機能もあって、AutoLocate と呼ばれている。)そもそもコンピュータというのは、ばかばかしい仕事を自動化するためのものじゃないか?

Dashboard の外でウィジェット -- Dashboard のおかげで多くの作業が簡単になったが、問題はこれがモーダルだということだ。つまり、Dashboard に切り替え、作業をこなし、その後で再び通常の作業環境に切り替える必要がある。計算機のような単純なツールをとっても、Dashboard の計算機から結果をコピーアンドペーストするには、アプリケーションフォルダにある独立版と比べて、より多くの手順(そしてより多くの時間)を必要とする。これのどこが便利なのだろうか。そこで、どんなウィジェットでも、Mac OS X のDashboard「レイヤー」に切り替えることなしに、それ自体で使えるようになればよいと思う。そうなればユーザビリティが大幅に向上するだろう。これは Amnesty Widget Browser ですでに実現されているが、ウィジェットの使い勝手を向上するのに追加の出費が必要なくなってもよいはずだ。

起動項目マネージャ -- Apple の Mac OS 9 機能拡張マネージャの時代はとうに過ぎ去ったが、機能拡張マネージャや起動項目マネージャの必要性がなくなったわけではない。システム全体の起動項目があり、アカウントごとのログイン項目があり、インプットマネージャがあり、カーネル機能拡張があり、そのほか知る人ぞ知るものがあるという具合なので、かたぎの人間にとって、どの Apple 製でないコードがいつ読み込まれるのか、正確に知るのはほとんど不可能だ。パフォーマンスを改善したり、問題を解決したり、セキュリティを強化したりできるように、Leopard には、ユーザが明示的に起動しなくても実行されるようなあらゆるタイプのサードパーティ製コードを管理するための、統一されたインタフェースがあればよいと思う。

ハードディスクを賢く使う -- Time Machine が長期間にわたってデータのスナップショットを多数保存するということになれば、これからの Mac のハードディスクはすぐに一杯になってしまうだろう。Mac OS X は、スワップファイルや不可視のキャッシュファイルを生成するために、大量の空き領域を必要とするから、記憶装置の取り扱いについて、気の利いた改善を3点望みたい。

第1は動的な再パーティション化だ。この機能はすでに存在しているが、平均的なユーザには使うのが難しすぎる。Apple の Boot Camp アシスタント は、Windows が使用する新規パーティションをハードディスク上に作成するが、そのときにはハードディスクを初期化するなど既存のデータを危険にさらす必要がない。Boot Camp の使用を止めようと思えば、このユーティリティがパーティションを消去し、ドライブを元の状態に戻してくれる。Mac のパーティションについて同じことができるようなインタフェースがディスクユーティリティにあってもよいはずだし、その機能を使って、必要なときにパーティションの大きさを変更できてもよいはずだ。コマンドラインのハッキングでこれを実現する方法がいくつか知られているし、サードパーティ製ユーティリティにも動的再パーティション化を実現するものがある(ただし遅くて使いづらいが)。Leopard では、この操作が高速かつ簡単になればよいと思う。また、動的パーティション化では、すべてのデータをディスク上の1つの領域にまとめ、残りの領域を1つながりの大きな空き領域とするのだから、デフラグ機能もおまけについてくる。

2つ目に改善してほしいものとしては、ディスクの空き領域がなくなりそうになったときに事前に警告してくれるシステムがある。Mac OS X が警告ダイアログを表示するときにはすでに、様々なよからぬことが起こりはじめている。パフォーマンスが低下したり、光学ディスクが焼けなくなったり(ディスクイメージを作成するための領域が足りなくなるためだが、この問題は Roxio の Toast では非常にうまく回避されている)する。最悪の事態としては、アプリケーションやシステムアップデートのインストーラを走らせることができても、インストーラが終了した後でマシンの再起動ができなくなることもある。ディスクユーティリティやほかのバックグラウンドで動いているプロセスが、ハードディスクの空き領域が健全であるかどうか監視してくれればよいと思う。また、すばらしい Disk Inventory X に似たような、何が空き領域を食いつぶしているのか明らかにしてくれるユーティリティを、Apple が作るというのも悪いことではない。

そして最後に、ゴミ箱についても、もう少し機能追加を望みたい。Finder メニューの「ゴミ箱を空にする」項目が階層化されて、どのボリュームのゴミ箱に捨てられたファイルを消去するのか選択できればよいと思う。例えば、デスクトップに USB フラッシュドライブがマウントされているときに、Tiger で「ゴミ箱を空にする」を選ぶと、起動ボリュームのゴミ箱も同時に空になってしまう。これは好ましいことではない。もう1つのアイディアとしては、ディスクスペースが必要になったときにファイルが自動的に消去されるよう、パラメータを設定するという機能も考えられる。例えば、3か月以上ゴミ箱に入っている QuickTime ファイルから消去するといった具合だ。おそらくは、Time Machine のファイル消去履歴機能によって、しばらく前に不注意でゴミ箱に入れてしまい、自動的に消えてしまったファイルも、さかのぼって救出することができるだろう。

Mail と Safari の認定プラグインアーキテクチャ -- 多くの開発者が Mailや Safari 用のプラグインや機能拡張を作成し、有用な機能を追加したり、足りないインタフェースを補ったりしている。問題は、両プログラムについて、Apple が公式にプラグインアーキテクチャを提供していないということだ。プラグインのためのドキュメント化された API もなければ、開発者へのサポートもないので、開発者が機能を追加しようとすれば、試行錯誤に頼るほかなく、クラッシュを引き起こしたりほかのアプリケーションの挙動がおかしくなったりという危険を冒すことになる( Input Manager は悪魔の業か? 参照)。Apple は、Internet Plug-Ins(これは Safari など WebKit を利用しているアプリケーションに新しいコンテントタイプを追加するものだ)を追加するフレームワークは提供しているが、必要とされているのは、Firefox やThunderbird にあるものと同じような、本格的な機能拡張 API だ。

Mail でニックネーム -- Mail の「宛先の履歴」リストには、電子メールを送ったことのある相手がすべて、再び連絡する予定のない人も含め、記録されている。その結果、メッセージの宛先を入力するときに自動補完機能を使うと、誤って違う宛先を入力してしまう可能性がある。リストを手動で切り詰めることもできるが、これは面倒だ。「宛先の履歴」を完全に使用停止して、その代わり(Eudora のように)よく使う宛先には短いニックネームを手動で割り当てられる機能があるとよいと思う。

ファイルレベル・フォルダレベル・ボリュームレベルの簡単な暗号化 --FileVault はどうしようもなくお粗末だ。Apple が初期のバージョンにあったバグをすべて修正したと仮定しても、ホームフォルダ全体を暗号化するという考え方そのものに問題がある。ほとんどのホームフォルダにおいては、写真やムービー、音楽といったデータが大容量を占めており、それを暗号化するなどということを気に掛けるユーザはほとんどいない。加えて、FileVault は舞台裏でスパースディスクイメージファイルを利用しているため、バックアップの設定をするときは、そのファイルを明示的に無視し、ディスクイメージがマウントされているあいだにその中身だけを見るように設定しなければならない(さもないと、電子メールを1通受け取っただけでも、数ギガバイトのディスクイメージファイル全体をバックアップしなければならないという羽目になる)。こんなに鈍い刃物など、使い物にならない。Leopard において、FileVault の基になっている技術を個々のファイルやフォルダに適用して、本当に暗号化する必要のあるデータだけを暗号化できるようにすることが、簡単にできるはずだ。少し手を加えれば、ディスク全体を暗号化することも可能だろう。これは USB フラッシュドライブや iPod など、機密データを書き込んで持ち運ぶ可能性のある着脱可能な記憶装置に理想的だ。


TidBITS Talk/14-Aug-06 のホットな話題

文: TidBITS Staff <editors@tidbits.com>
訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>

1984 -- Apple の有名な“1984”コマーシャルにちなんだ Lego のセットが PodBrix から限定販売で登場したが... もう売り切れてしまった。 3 メッセージ

TidBITS を Avantgo で -- TidBITS 出版を新システムに移行させるに伴い、モバイル PDA 版は当初含まれていなかったが、今はちゃんと稼動している。 8 メッセージ

VOIP でエコーの問題も -- Voice-over-IP の音声通話で(例えば Skype で)エコーが起こって困るという人は、いったい何が起こっているかの説明をこちらでどうぞ。3メッセージ

TidBITS で番号付き URL を使うことについて -- 先週号から号のフォーマットの仕方を少し変えた。リンクにすべて通し番号を付けて、対応する URL を見やすくするためだ。この変更について、読者たちが意見を述べる。9 メッセージ

Apple がスリープ方法を変えた -- 新しい Mac ではスリープ中のインジケータライトの動作方法が以前と違ったものになっている。3 メッセージ

車内口述 > ワードプロセッサ -- 運転中に文章を口述しておいて、それを後でワードプロセッサに流し込んで使うにはどうすればよいか、ある読者が教えを受ける。2 メッセージ


tb_badge_trans-jp2 _ Take Control Take Control 電子ブック日本語版好評発売中

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

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

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