TidBITS: Apple News for the Rest of Us  TidBITS#770/14-Mar-05

データベースってみんな同じようなものだ、とお思いだろうか? いやいやとんでもない。今週号は、Adam が Panorama V を使っての彼の実体験を語る。これは、必要になった時にいつでもそれに応じて新機能が追加できるという、珍しいタイプのデータベースだ。その他の記事では、Jeff Carlson が三つの新しい電子ブックの登場を紹介し、Glenn Fleishman は RAM の増設を安価に済ませるために Mac mini を開いてみる。また、Take Control 電子ブックの抄録版へのリンクを紹介し、業務上の秘密の漏洩に関して機密情報を召喚する権利を Apple に認める決定を裁判所が下したことをお伝えする。

記事:

Copyright 2005 TidBITS: Reuse governed by Creative Commons license
<http://www.tidbits.com/terms/> Contact: <[email protected]>


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


MailBITS/14-Mar-05

Apple が召喚要求に勝訴 -- 情報の漏洩を封じ込めたいという Apple の追求の手に、新たな動きがあった。サンタクララ郡高等裁判所の判事 James Kleinberg が先週の金曜日、O'Grady の PowerPage サイトに対し、秘匿されている情報源を開示するようにと命じ、その情報が「盗品」であると断じた。判事は同時に、今回の裁定は Apple 社が PowerPage の ISP である Nfox から情報を召喚する権利についてのことに限られるのであって、より広範に解釈されるべきものではないと注意深く付け加えた。また、判事は「公共の利益」(the public interest)(健康・安全・福祉などに対する危険を告げ知らせる人たちによってもたらされるもの)と「興味津々の一般人」(the interested public)(ニュースサイトやファンサイトなどのウェブサイトによってもたらされるもの)とは違うものだ、と強調した。この判決の全文は The Mac Observer サイトからダウンロードできる。Jason O'Grady はこの判決を不服として上訴すると述べている。[ACE](永田)

<http://www.macobserver.com/article/2005/03/11.8.shtml>


曲がってくれれば、楽しい。折れてしまえば...

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

私の眉の上には玉の汗が... いやいや、汗の流れる川が出来ていた。いったい、何でこいつは、くそ、開いてくれないんだ!

ご推察どおり。私は、新しく買った Mac mini に RAM を増設しようとしていたのだ。(貧弱きわまりない 256 MB という内蔵 RAM から)1 GB へのアップグレードが $425 という Apple の値札に呆れた私は、汎用の RAM を $200 で買った。私はまた Other World Computing で公開している非常に明瞭なビデオを見て、mini のケースをパテ用ナイフを使ってこじ開ける方法を学んでおいた。

<http://eshop.macsales.com/tech_center/index.cfm?page=Video/directory.html>

どうやら私は楽天的に過ぎたようだった。私はいそいそとナイフを手に持ち、こじ開ける作業を始めた。でもその音たるや、私の心臓を縮み上がらせるに充分なものだった。私はプラスチック製のツメをじっと見つめながら、独り言を繰り返した。「きっとこいつじゃないんだ、誰が何と言っても」と。

でも私は頑張った。私はケースの下部にちょっと切り込みを入れてしまったが、その部分をあっちへ引っ張ったりこっちへ押し開いたり、船に索具を取り付けては崩れ落ち、夜更けに大木が倒れる悪夢のような、恐怖に満ちた音を聞きながら。さんざん苦闘した末に、ついにケースはその重荷を解き放ち、私はその目にも美しい内部にアクセスを許された。巨大なあこや貝との格闘の末、私は真珠を掴み出すことができたのだ。

いやいや。私は 256 MB のメモリモジュールを掴み出した。それから新しい 1 GB のモジュールを差し込んだ。それからケースを元通り閉めた。閉める方は、タッパーウェアのケースの蓋を閉めるのよりも、ちょっとだけ感じが悪い程度のものだった。そして、このカワイイ奴に電源を入れた。

貝殻閉じればもう安心、ちゃんと起動した。


上げ潮の電子本

文: Jeff Carlson <[email protected]>
訳: 亀岡孝仁 <takkameoka@earthlink.net>

Adam は "Macintosh エコシステム" について、そして一つのシステムを構成する企業と製品が共通の利益のために一般的にどの様に共同作業をしているかについて語るのが好きである。例えば、Mac OS X に足りない所が見つかった時、ソフトウェアデベロッパーはその問題に対処するユーティリティを作成する。多くの場合、同じ事をするプログラムがいくつか出されるが、それぞれが独自のアプローチを持っている。過多とも言える程ある断片情報キーパーは良い例である (大抵のものは Matt Neuburg がレビューしている)。私は数年前は、この様なノートを取りそして整理するソフトウェアがあることにすらあまり注意を払わなかったが、今では、どれが私の働くスタイルに合っている機能を提供しているか調べている状況である。

<http://db.tidbits.com/getbits.acgi?tbart=05237>(日本語)Macworld Expo SF '99 と Macintosh 生態系
<http://db.tidbits.com/getbits.acgi?tbser=1196>
(日本語)
WebArranger は Web よりも使える
復活: Helix の逆襲
それはキーパー(Idea Keeper だ、それは)
" Boswell:テキスト保管庫
断片情報キーパーをあと3つ
Tinderbox でハートに火を点けて
デジタル下駄箱: iData Pro X 1.0.5
NoteTaker でテイク・ノオト
Hog Bay Notebook でグイッと行こう
DEVONthink は考える、あなたのために
よく使い込んだ NoteBook
TAO は上げ相場

そしてもう一方では、同じ様な効果が電子本にも当てはまる兆しが見えてきた。TidBITS Electronic Publishing が Take Control シリーズの電子本を始めてから (私自身、その内三冊の編集に携わった)、私は Mac の how-to ものを電子出版の形でリリースしている他の出版社にも注意を払うようになった。より多くの書名が出現するにつれ、このカテゴリー全体の信頼性も利便性も向上する - "潮が上げてくれば全てのビットも動き出す" という所であろう。

<http://www.tidbits.com/takecontrol/>(日本語)Take Control Ebooks: あなたの知りたいことがすぐわかる

もし Mac の how-to 本の蔵書を増やすためもっと多くの出版元をお探しなら (そして私は印刷本を出版して生計の足しにしているので、伝統的な出版元もこの区分けに入れさせて貰った)、最近本をリリースした出版社は下記のようにいくつかある。

MyMac.com の Scroll Down Books -- 私は時々 MyMac.com の人達は自分たちの扱っている本や商品の全てを調べる時間をどうやって作っているのだろうかと思うことがある。そして今度はその盛り沢山のお皿に Scroll Down Books の発刊を加えた。これまでの所 PDF フォーマットで $5 の本を二冊リリースしている:Neale Monks による "Buying Used Macs" (176 頁) と、Chris Seibold による "iMovie - On the Cheap," (95 頁) である。(Seibold の本が扱っているのは iMovie 4 であって iMovie HD ではないが、この二つのバージョンはそう大きくは違っていないので - HD 映像を編集できる機能は脇に置けば - 全ての情報は生きている。そうではあっても Seibold がアップデートに取り掛かっていたとしても驚くには値しない。我々も含めて iMovie の本を出した人達は皆そうしているからである。) どちらの本も安いのだが、望むらくはそれぞれの本のダウンロード出来るサンプルがあって欲しいところである。そうすれば興味のある人はその内容と書き方のスタイルを事前に見ることが出来るというものである。

<http://www.mymac.com/ebooks.php>

Fix a Troubled Mac -- 電子出版の長所の一つは、ソフトウェアやハードウェアの進化に合わせて電子本をアップデートするスピードとそのやり易さにある。Fix a Troubled Mac は $15 の 222 頁の PDF で著者は "dirtymouse" (本名は書くには難しすぎる?) であるが、間違いなく電子本の柔軟性を有効に活用している。この本は Mac OS 9 と Mac OS X に関するトラブルシュート情報を収納しており、写真や図をふんだんに使っているので、問題を絞り込んで直すまでのしばしば頭の痛くなるプロセスをナビゲートしやすくしている。4.1 MB のサンプルを Apple の Web サイトからダウンロード出来る。

<http://fixa.troubledmac.com/>
<http://www.apple.com/downloads/macosx/system_disk_utilities/fixatroubledmac.html>

SpiderWorks -- もう一つの電子出版の長所は規模の経済にある。印刷出版社が一冊の本を出そうとする時には、最低数千冊の初版本を印刷する費用を負担するのだが、これはこれらの本を売ることでその投資は回収できるであろうという期待のもとでのことである。しかしもし出版社が、初版本の最低量を売り切れないと判断したり、或いは初版本を印刷するに必要な資金が手元にないというような場合はどうなるのであろうか?出版の歴史には、出版社が、その理由は何であれ、投資をしないと決めたために日の目を見なかった良い本がゴロゴロしている。

新しい電子本の出版社である SpiderWorks は、このギャップを埋めるためもう絶版となった本の改版を電子本で出している。(新刊本もある。)Danny Goodman の AppleScript Handbook の最後の版は 1995年に出版されたのだが、SpiderWorks は現在 Mac OS X 用にアップデートされたその第三版を $15 の PDF (388 頁) として出版している。更に同じ様に Mac OS X 用にアップデートされた Dave Mark の Learn C on the Macintosh ($15, PDF, 292 頁) も帰ってくる。新刊本としては David Hill の Cocoa Game Programming ($10, PDF, 152 頁) と Ben Waldie の AppleScripting the Finder ($10, PDF, 107 頁) がある。それぞれの本の全目次と内容の抜粋を含んだサンプルがダウンロード出来る。

<http://www.spiderworks.com/>

他の出版社が単に従来の本を PDF で出すだけに留まらず、リンク、ブックマーク、そしてオンスクリーンで読むのに適したレイアウト等の機能を追加して電子本をリリースしているのを見れるのは素晴らしいことである。例えば、SpiderWorks の電子本は全て、たいていの Mac の横型スクリーンには適した配置に思える 2 コラム型のレイアウト機能も有していて、更に印刷するときには 8.5 x 11 インチの紙に横向きに印刷してくれる。


Panorama の眺めを必要とする時

文: Adam C. Engst <[email protected]>
訳: Mark Nagata <nagata@kurims.kyoto-u.ac.jp>
訳: 羽鳥公士郎 <hatori@ousaan.com>

あなたが初めてデータベースをセットアップする時、そのデータベースの将来すべてにわたってあなたがそこからどういうことを得ようとするのか、正確に把握していることができるだろうか? それどころか、来月にあなたがそのデータベースで何をすることになるのかさえ、わかっているのだろうか? おそらく大まかな考えはお持ちだろうが、もしもあなたが過去にデータベースを作った経験がおありなら、あるいは現在コンサルタントと協力して作業中とおっしゃるなら、きっとあなたはしっかりと時間をかけて、あなたのデータ構造やレポート、その他をどういうものにすべきか、あらかじめ検討しておきたいと思っておられるだろう。そういう労力をかけることは、たいていの場合それだけの価値がある。なぜなら、多くのデータベースプログラムでは、後になって全体的な構成を作り替えるのが難しいからだ。

2003 年になるまでの私は、もう長年のあいだ自分の手でカスタムデータベースを作ったことなどなかった。TidBITS に関するデータベースはすべて Geoff Duncan がセットアップしてくれていたし、それ以外の私のデータベース関係の作業は専門のプログラム、例えば Now Contact(私たちの共有アドレス帳)や Eudora(電子メールのアーカイブ)などがうまくこなしてくれていた。これらのプログラムはそれぞれデザインされた目的についての作業は見事に処理してくれたが、それぞれの守備範囲を超えることはできなかった。そうこうするうちに私たちは 2003 年の終わりになって Take Control 電子ブックを始めた。この時、注文を処理したり、著者たちへの支払明細を作成したりするためにデータベースが必要となるということがはっきりしていた。もちろん印税支払のための専用のデータベースプログラムがあるということはわかっていたが、そういうものが私たちの受け取る eSellerate からの生データにそのまま対応しているはずもなかったし、また、そのデータベースが何をすべきかもまだ見えていない段階では、高い料金を払ってコンサルタントに何かを作らせる気も起こらなかった。

ビュー形式を選択する -- しばらく考えた結果、私は印税支払のデータベースを ProVUE Development 社の Panorama で作ることに決めた。これはパワフルだが奇妙な点も多いデータベースプログラムで、Macintosh 用のデータベースとしては最も歴史の古いものの一つだった。私が最後に Panorama を使ったのは 1992 年に遡るので、これについてのプログラミングの知識はとうにすっかり忘れてしまっていた。私が覚えていたのは Panorama が RAM ベースのアーキテクチャを採用していたために検索の実行が非常に速かったということで、これは他のたいていのデータベースでは検索対象のフィールドを索引付けしていてかつ検索内容も比較的単純なものでない限り、通常あり得ない速度だった。(Panorama の検索は単語の中途に含まれているテキストを検索することも、音声的にテキストを検索することも、フィールドを他のフィールドと比較して検索することも、また任意の定型文を使って検索することもできる。)それから私の選択において決定的だったのが Panorama の Data Sheet だ。これはスプレッドシート的なデータのビュー形式で、データベースのプロではない人たちの(大多数とまでは言わずとも)多くがデータのビジュアル化方式として好むような方法にマッチしている。この表形式のビジュアル化こそ、Microsoft Excel がデータベース処理の作業機能をそれほど装備していないという事実にもかかわらず、現実にシンプルなデータベースの多くが Excel で作られていることの理由なのだ。

<http://www.provue.com/>

これら二つの事実、つまりどんなフィールドでも高速で検索できることと、表形式のビューを持つ Data Sheet がどちらも私にとって重要であった理由は、データベースが一年後にどんなものになるのか、私自身さっぱり見当がつかないようなプロジェクトに取り組もうとしていることを、私が自覚していたからだった。自分自身が何を望むことになるのかが予想できないだけでなく、何が重要になるのだろうかとゆっくりと思い巡らす時間的余裕もなければ、私にとって必要でないタスクを実行してくれるようなデータベースを作るために多くの時間を振り分けることもできなかった。私にわかっていたのは、それぞれの著者たちに二冊ずつくらいの本の印税について、毎月の支払明細を、eSellerate から毎日送られてくるタブ区切りのテキストファイルによるデータに基づいて計算しなければならない、ということだった。けれどもその時点では、著者によっては一人で何冊もの本を書くようになること、編集者たちや翻訳者たちにも支払わなければならないこと(その人たちのうちには著者でもある人たちがいること)それに一つの本を数人の著者が担当している場合印税を分け合わなければならないこと、などの事実もほとんど予想できていなかった。その上、私がこのデータベースを書き始めた時点では、どんなデータが入力されることになるのかもあまり判明していなかった。個々の本を対象として、あるいはいくつかの本のバンドルを対象として、またはすべての注文を対象として、それぞれ別々のタイプのクーポンを発行することになるとは予想していなかったし、実際に注文が入るようになるまでは、アフィリエイトによる調整をどのようにすべきかも、全く見当がついていなかった。要するに、私は目隠しをしたまま高速で低空飛行をしていた。そんな私がデータをうまくかき分けて飛ぶためには、高度に操縦性能の良い飛行機が必要だった。つまり、Panorama だ。

ズーム・イン -- Panorama の動作のしかたについて、ここですべてを説明しようとは思わない。パワフルであると同時に深いものだし、私自身その能力のほんの表面だけをかじった程度に過ぎないだろうから。ただ、ここで私が述べておきたいのは、私が入力されてくるデータを理解してそこから必要な結果を抽出することを可能にしてくれた、そのために重要だった機能のいくつかについてだ。毎月、私が何を必要としているかが少しずつ見えてくるに従って、私はそれに応じて少しずつデータベースを拡張していった。

さきほど述べたように、Panorama におけるスプレッドシート風の Data Sheet は素晴らしいものだ。Panorama にデータを入力したりデータを一覧したりするために、あらかじめ何のレイアウトを作る必要もない。その理由は単純で、Data Sheet においてはすべてのフィールドのすべてのレコードが見えていて編集もできるからだ。もちろん、特定のフィールドに焦点を合わせるためとか、レポートの印刷をするためなどにレイアウトを作成することはできるし、私も後日そういうものを作るようになった。それでも、私はその後もほとんどの作業を Data Sheet の中でし続けた。なぜなら、これは私のデータを一覧するのに適した、本当に素晴らしい表形式のビューだからだ。というわけで、毎月私は Unix の cat プログラムを使って eSellerate から電子メールで毎日届いていたレポートを一月分すべてまとめあげ、BBEdit を使ってそれぞれのカラムヘッダのレコードを削除し、それからそのテキストファイルを Panorama に読み込ませた。なんて面倒な、とお思いだろうか? 私は Panorama の作者の Jim Rea とチャットをする機会があったのでこのことについて話してみた。すると彼はあるプロシージャの骨格を送ってくれた。このプロシージャというのは Panorama 用語で、そのままのインターフェイスではできないことを自動化して実行するために自分で書ける小さなプログラムだ。彼が送ってくれたプロシージャは、指定されたフォルダをチェックしてその内容のファイルをすべて読み込み、その際自動的にカラムヘッダのレコードを削除してくれるというものだった。これで、早くも私の作業がぐっと楽になった。(そうそう、同種のヒントを共有できる場として、Panorama ユーザーたちのメーリングリストも提供されている。)

<http://www.provue.com/support.html>

この Data Sheet はスプレッドシート風に見えるだけでなく、実際の動作もスプレッドシートと同様だ。最初の数カ月間、まだクーポンもアフィリエイトも無くて事態が複雑化していなかった頃は、私が Panorama のインターフェイスにあるコマンドを使って数字を生成させ、それをさらに Tonya が Excel で整形して実際の支払明細書を作る、という手順をとっていた。Data Sheet の中では、カラムの順序(カラムがフィールドに相当し、行がレコードに相当する)を並べ替えたり、一つあるいは複数個の検索基準にマッチするレコードだけを表示させたり、さらに最も重要なこととしては、レコードをフィールド内容によってグループ分けしたりできる。このグループ分けは、いくつものレコードを集めて Panorama が「サマリーレコード」と呼ぶものにまとめあげることができるので非常に便利だ。サマリーレコードは、普通のレコードと同じタイプのデータを持つことができる実際のレコードではあるが、ただこれは一時的なものだ。例えば数式計算をして出た結果を小計として一時的に保管するために使えるが、そのグループ分けによる作業が終わったら、サマリーは削除する。基本的にこれらのサマリーは階層的なアウトラインを成していて、それぞれのグループ分けされたフィールドごとにアウトラインのレベルが対応し、このアウトラインの中でどのレベルでも独立に、個別に一覧することができる。この機能はなかなか便利なことがわかった。なぜなら、どんな検索条件を与えても、それについてレコードをグループ分けして小計が計算され、そうやってできたいろいろの小計の数字たちが一覧できるとともに、それぞれのグループを展開表示して、そこに属するレコードをすべて一覧し、その小計がどのようにして集められたのかが一目でわかるようになるからだ。

実例で説明を付けた方がわかりやすいだろう。現在私たちはかなり多数の本を追跡しなければならない。そして、支払明細を作成中に、その月のうちにどの本が何冊売れたのかについて、私のデータベースの数字と eSellerate の支払レポートの数字とが食い違っているのを、私はしばしば経験することがある。そんな時、私は検索をかけて表示されるレコードをその月に売れた本についてのもののみに限定させてみる。それから、データベースを Title フィールドについてグループ分けし、個々の本についてのサマリーレコードを作る。それから、Quantity フィールドで、Math メニューの Total コマンドを使ってその月その本が何冊売れたのかを計算する。最後に、アウトラインレベルを切り替えて小計と総合計(これは Total コマンドを使えば自動的に生成される)のみが表示されるようにする。以上のステップを踏めば、何千もあったレコードがおよそ 20 ほどのレコードになり、私の数字と eSellerate の数字を比較するのも簡単にできる。小計が食い違っているのを発見したならば、その本についてのサマリーレコードを展開表示させ、元のデータを眺めれば、たいていの場合すぐに原因が判明する。これはごく単純な実例だが、現実に私が使っている実例であり、私は、自分のデータと、自分が実行させている計算の結果すべてについて、頻繁にこの基本テクニックを使って理解を保ち続けるようにしている。

自動化 -- 当然のことだが、これらのコマンドがすべて Panorama のインターフェイスから直接利用できるからといって、いつもそうしなければならないわけではない。Panorama にはフル機能のプログラミング言語が付いており、ローカルおよびグローバルの変数も、ループ関係のコマンドなども完備している。同じ動作をいつもいつも繰り返すような場合、きっとそれはプロシージャの出番となる。私が初めのうち作っていたプロシージャはごく単純なものばかりだった。データを選択してグループ分けし、そのグループ内のレコードで計算を実行する、というだけのものだった。

私が書いたプロシージャの中で最も重要だったものは、個々の本の個々の売り上げに対していろいろな人々が得るお金の額を計算し、それぞれを私が作った新しいフィールドに入れる、というものだ。概念的にはごくシンプルだ。単位価格に冊数を掛け算し、そこから手数料を引き算し、クーポンによる割引額を計算し、アフィリエイト料も引き、出てきた小計の額を著者、編集者、出版者、それから翻訳者がいればそれぞれに分配する、というだけのことだ。実際問題としてもこれはシンプルなことだった。いや、シンプルだったのはゴタゴタとたくさんのクーポンコードが登場してきて、そのうちあるものは特定の本だけに適用され(それでいてそれと同時に合わせて注文された他の本のレコードにも記載されざるを得ず)またあるものは注文された本すべてに適用され、その上それぞれのクーポンコードごとに別々の割引率あるいは割引額が決まっている、という事態になってきた頃までだったかもしれない。

こうした複雑な「もしそのレコードがこのクーポンを持っていたならばこの計算を実行する」というタイプのコードを次々に付け加えていった結果、支払額計算用の私のプロシージャは次第に醜いものに変貌していった。その上に毎月新たなクーポンを追加しなければならない作業も、次第に面倒な、間違いの危険をはらむものとなっていった。そういう事態に直面した私は、Panorama の一段高い次のレベルに進むべき時が来たのだ、と気付かされたのだった。それが、リレーショナル関係の機能だ。

データベースをリンクする -- Panorama は、当初はフラットなカード型データベースであったが、その長い進化の過程のどこかで、ProVUE が、ルックアップによってデータベースをリンクする機能をつけ加えた。ルックアップというのは、プロシージャの中に含めることのできる命令文で、ほかのデータベースの中に入り込み、適切なレコードを見つけ、そのレコードの中から必要なデータを抽出する。データが手に入れば、それを計算に使ったり、データベースに挿入したり、好きなように扱うことができる。

私が最初にデータベースをリンクしようとしたのは、書名と著者名とを結びつける方法を探していたときだ。eSellerate は、私たちに送る生データの中に著者名を含める方法を見出せなかったのだ。書名が「Take Control of Upgrading to Panther」となっているものをすべて見つけて Author フィールドに「Joe Kissell」と書き込むプロシージャを書くという方法もあるが、それでは、新しい本が出るたびにプロシージャを修正しなければならない。もっとも効果的な方法は、Books データベースを作り、そこに Title、Author、Editor、Translator のフィールドを含め、ある本の著者(または編集者や翻訳者)を知る必要があるときは、この Books データベースに探しにゆくことだ。Books データベースに新しい本のデータを加えることは、プロシージャを毎月修正することに比べれば、ずっと簡単だし、間違いも少ない。

私が今月手がけていた機能拡張については、このことが特に当てはまる。私は、さまざまなクーポンコードのすべてを追跡する Coupons データベースを新しく作ったのだ。これで、それぞれの割引率や割引額、いつ何のために発行されたのかといった情報を管理するようにした。まだコードが書きあがってはいないのだが、基本的な考え方としては、Orders データベースの中のレコードのうち、クーポンを含むものすべてについて、Coupons データベースを参照し、割引が適用されるべきかどうかを決定し、そのクーポンについてもたらされた情報に基づいて計算をする。私たちはこれまでに 50 種類のクーポンを発行したから、このやり方が論理的で間違いのない方法であることはすぐに分かった。Coupons データベースの使い道はすでに1つ見つかっている。私がPanorama の Text Export Wizard を1分ほどいじるだけで、クーポンコードとその説明とを HTML テーブルに書き出すことができ、それを内部 wiki でほかの著者たちと共有することができた。この Text Export Wizard は、ProVUEが制作し Panorama に同梱した数々の便利なユーティリティー詰め合わせの中の1つに過ぎない。

システムを複数のデータベースに分割することのもう1つの利点は、システムを拡大する余地が生まれるということだ。現在のところ、著者、編集者、翻訳者の印税を計算するときには、誰もが同じ割合を受け取ることにしている。しかし、これが同じでなくなる状況というのは十分想像できるし、もしそうなれば、Books データベースにフィールドを追加して、その本に貢献した人がそれぞれどれだけの割合を受け取るべきかを記入することは比較的簡単だ。うれしいことに、Panorama では、そのときが来てから考えても問題はない。取り越し苦労をする必要はないのだ。

レイアウトとレポート -- 多くのデータベースとは異なり、私たちのシステムでは、手動でデータを入力するということはほとんどない。あるとしても(そのほとんどは、団体購入による直接販売などのようなものだ)、独立したSpecial Sales データベースの Data Sheet で直接行うことができる。しかし、私たちが Peachpit Press と協同で「Take Control of Panther」の印刷版を出版したので、彼らが送ってくる明細を見てデータを入力しなければならないだけでなく、入力されたレコードを分割して、印刷された版に含まれるそれぞれの本の著者たちのあいだで収益を適切に分けられるようにしなければならないという状況になってしまった。そのために、私はレイアウトを作った。レイアウトというのは、基本的にはフィールドとラベルを含むフォームで、そこにデータを入力することができる。そして、入力されたデータを、ほかの特別販売用フォーマットと整合性が取れるように分割するプロシージャを書いて、そのプロシージャをクリックできるボタンに割り当てた。こうすれば、印刷版のようなバンドルを入力しなければならなくなったとき、数字を入力して、当てはまるバンドルをメニューから選び、Split Bundle ボタンを押せば、それが分割される。要するに、私はレイアウトを、データを入力するインターフェースとして使うだけでなく、入力されたデータを必要な形式に変換するための方法としても使っている。このように、レイアウトは、データを私から保護する(私がデータを間違えて変更してしまうのを防ぐ)と同時に、私をデータから保護する(不必要なフィールドを隠してくれる)。そして、私が、自分が正しい操作をしたかどうか心配になったときは、Data Sheet をチェックして、隠されたデータがすべて正しいことを簡単に確認できる。

レイアウトの使い道といってすぐに思いつくのは、もちろん、印刷用のレポートを生成することだ。これは、Panorama の機能の中でももっとも強力で、もっともトリッキーな部分だ。というのも、この機能はグループ分けによって作られたサマリーレコードに深く依存しているのだ(サマリーレコードは小計を得る方法であり、レポートにはたいてい小計が含まれるものだ)。Panoramaは、この機能をレポートの「タイル」という概念の下に扱う。タイルには、特定のフィールドからの情報を表示するボックスを置くことができる。タイルはそれぞれのサマリーレベルと関連付けられていて(というのも、多数のレポートでさまざまな小計や合計が必要になるだろうから)、それがページ上でどのように表示されるのかということについては、さまざまなオプションが用意されている。Panorama には完全なグラフィック編集環境も備わっていて、ボックスや線やテキストや画像をレポートに加えることができる。これは往年のMacDraw を思い起こさせ、私をいらつかせることといえば、フィールドの長さを予測できないときなど、見た目のよいレポートを作るのにしばしば時間がかかりすぎることだ。それでも私は、この機能を使って、それぞれの本ごとに売り上げを時系列で表示し、同時にそれぞれの著者、編集者、翻訳者に対する印税を月ごとに表示するレポートを作ることができた。

間抜けなインターフェースと使い勝手 -- 私は Panorama が完璧だなどと言うつもりは毛頭ない。そのインターフェースは、何年にもわたってさまざまな姿の Mac OS の下で進化した結果、癖があって、奇妙なというのに限りなく近い。たとえば、Panorama の Preview ウインドウ(レポートをプレビューするのに使う)を Command-W で閉じることができない。また、次のページに移動するには(前のページに移動することはできない)左上の隅にあるごく小さなページボタンをクリックしなければならない。スクロールアローを変形したようなものにした方が分かりやすいだろう。プロシージャやレイアウトを新しいウインドウで開く(最前面のウインドウを書き換えるのではなく)には、修飾キーを押していなければならない。細かなことにもつまずかされる。たとえば、ダイアログを閉じようとして Escape キーを押したとき、Print や Save As といったシステムレベルのダイアログではうまくいくが、Panorama 固有のダイアログは閉じてくれない。さらに悪いことに、Panomara のダイアログにテキストフィールドがあったら、Escape キーを押すとそのフィールドに文字が1つタイプされる。また、Data Sheet は素晴らしい一方、注意深く使う必要がある。うっかり Return を押してしまったり、最後に表示されるレコードを越えてスクロールしてしまうというような簡単なことで、新しいレコードが追加されてしまうのだ。また、フィールドの内容を編集していると勘違いして、うっかり Delete キーを押してしまうと、レコードが削除されるのだが、幸いなことに、その場合 Panorama が確認のメッセージを表示してくれる。

総合計 -- 間抜けな使い勝手を置くとすれば、Panorama のもっとも特異で魅力的な側面は、あなたが必要とするものが何かを知るにつれ、またPanorama そのものの使い方を学ぶにつれ、時間をかけてその機能を利用できるようになるということだ。私はデータベースの専門家ではないが、私が何年もにわたって使ってきたほかのデータベースは、データベースの働きを大幅に変えようと思ったときに、これほど柔軟かつ寛容であったためしがない。もしもあなたが、自分自身とともに成長するようなデータベースをお探しなら、Panorama に試乗してみる価値はある。無料の評価版は完全な機能を備えているが、データベースに 250 以上のレコードが含まれるようになると、印刷したり保存したりするたびにちょっとしたゲームをするように求められる。

<http://www.provue.com/panoramatestdrive.html>

Panorama V は Mac OS 9 と Mac OS X の両方でネイティブに動く。3,000ページ以上もある PDF の説明書が含まれており、フル機能の開発版は 300 ドルだ(ランタイム版を 130 ドルで購入することもできる)。


Take Control ニュース/14-Mar-05

文: Adam C. Engst <[email protected]>
訳: 笠原正純<panhead@draconia.jp>

Take Control 電子ブックに関する話題を広げる手段として、私たちは他の出版社にいる友人たちと協力しながら、何冊かの電子ブックについて抜粋を出版することにした。みなさんは既に、全ての電子ブックについて、何を扱っているのかどんな読み心地なのかを確認するための無償サンプルをダウンロードできるようになっている。けれども今回の抜粋版では、特定のセクションについての全ての文章とスクリーンショットが含まれている。

<http://www.tidbits.com/takecontrol/>(日本語)Take Control Ebooks: あなたの知りたいことがすぐわかる
<http://www.tidbits.com/takecontrol/news/>

Take Control of Sharing Files in Panther 抜粋 -- もし、あなたがより安全でより柔軟な設定が可能な Mac OS X 上の FTP サーバに興味があり、Glenn Fleishman の "Take Control of Sharing Files in Panther" 電子ブックを持っていないなら、O'Reilly の MacDevCenter に目を向けていただきたい。私たちは Glenn の人気ある電子ブックの最新版からの抜粋をそこに置いている。抜粋で、Glenn は Mac OS X に組み込まれている FTP サーバの代わりに PureFTPd をインストールし設定する方法を説明している。匿名の FTP アクセスを可能にする方法、そのマシン上に Mac OS X のログインアカウントを持っていない FTP ユーザを作る方法、等々もだ。

<http://www.macdevcenter.com/pub/a/mac/2005/03/04/ftp.html>
<http://www.tidbits.com/takecontrol/panther/sharing.html>

Take Control of Mac OS X Backups 抜粋 -- Joe Kissell の "Take Control of Mac OS X Backups" はこの数ヶ月におけるベストセラー電子ブックだ。こんなに多くの人たちが良いバックアップによってデータを守ろうとしているというのは素晴らしいことだ。もし、あなたがまだ Joe の電子ブックを買っていないのなら、Macworld のウェブサイトにある 2 つのパートを抜粋したものを読むといいだろう。パート 1 では、Joe はバックアップ戦略を練るところからアドバイスする。彼は、複製とアーカイブの違い(そして、なぜ両方が必要なのか)を説明し、なぜ同期化ユーティリティがバックアップに向いていないのかについて論じる。その後、パート 2 では、どれくらいの頻度でバックアップすべきかについて語り、小さなネットワークのバックアップの違いを確認し、彼のお勧めの方法を紹介する。

<http://www.macworld.com/2005/02/features/takecontrolexcerpt1/>
<http://www.macworld.com/2005/02/features/takecontrolexcerpt2/>
<http://www.tidbits.com/takecontrol/backup-macosx.html>


TidBITS Talk/14-Mar-05 のホットな話題

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

各話題の下の2つ目のリンクは私たちの Web Crossing サーバでの討論に繋がる。こちらの方がずっと高速のはずだ。

Mac 用の良い道路地図ソフトウェアは? -- Windows 用の Microsoft Streets & Trips に匹敵するような、Mac 用の道路地図ソフトウェアを作っている会社はあるのだろうか? Route 66 か、あるいはいろいろなオンラインの地図リソース、というのが答かもしれない。(メッセージ数 2)

<http://db.tidbits.com/getbits.acgi?tlkthrd=2504>
<http://emperor.tidbits.com/TidBITS/Talk/362>

Apple、FireWire、そして USB -- Apple は USB 2.0 ケーブルを使うようになった新しい iPod に FireWire ケーブルを付属させることを止めてしまったが、どちらのフォーマットが優れているのかという、熱気に満ちた議論が巻き起こった。特に、1990 年代に Apple で FireWire の技術主任を務めていた Michael Teener からの長い投稿は注目に値する。(メッセージ数 22)

<http://db.tidbits.com/getbits.acgi?tlkthrd=2505>
<http://emperor.tidbits.com/TidBITS/Talk/363>

2本指で真っ暗な所で PowerBook を落とす -- 最新の PowerBook 機種における新機能について書いた先週号の Glenn Fleishman の記事では緊急モーションセンサーを使ったハックに触れたが、このテクノロジーを利用したゲームもある。(メッセージ数 2)

<http://db.tidbits.com/getbits.acgi?tlkthrd=2506>
<http://emperor.tidbits.com/TidBITS/Talk/364>

自動スクロールユーティリティ -- 速読のできる人が長いウェブページ(あるいはその他の書類)を読み進めるような場合に、自動スクロールさせる方法はあるのだろうか? いくつかの提案が、議論のリングの中に投げ込まれた。(メッセージ数 3)

<http://db.tidbits.com/getbits.acgi?tlkthrd=2507>
<http://emperor.tidbits.com/TidBITS/Talk/365>

Mac OS X ウィンドウの挙動 -- Mac OS X デフォルトのウィンドウ挙動について書いた Jeff Carlson の記事は、どちらの方法が「正しい」か「間違っている」かという、熱い議論を引き起こした。また、ウィンドウをまとめて前面に持ってくる代替方法もいくつか紹介された。(メッセージ数 29)

<http://db.tidbits.com/getbits.acgi?tlkthrd=2508>
<http://emperor.tidbits.com/TidBITS/Talk/367>

ドメイン名の買い占め -- 一連のドメイン名を買い置きしてそのまま利用せずに死蔵している会社に対して、何か対抗策はあるのだろうか? そもそも、これは実際に問題なのだろうか? (メッセージ数 24)

<http://db.tidbits.com/getbits.acgi?tlkthrd=2509>
<http://emperor.tidbits.com/TidBITS/Talk/368>

QuickerTek アンテナでうまく行った -- PowerBook G4 Titanium の受信範囲を改善しようとして成功した読者がいる。(メッセージ数 1)

<http://db.tidbits.com/getbits.acgi?tlkthrd=2510>
<http://emperor.tidbits.com/TidBITS/Talk/369>

DRM とコピーについて -- フランスやその他の国々では、多くの製品(例えば iPod)の価格に割増が加算されていて、実際上これは人々が著作権の伴ったものを盗むようになるからということが前提となっている。そもそも、このようなタイプの前倒し課税には効力があるのだろうか? (メッセージ数 9)

<http://db.tidbits.com/getbits.acgi?tlkthrd=2511>
<http://emperor.tidbits.com/TidBITS/Talk/370>

シェアウェアをめぐる用語について -- 大会社がその製品(例えば Adobe Photoshop)の試用版を提供して支払いもダウンロードもオンラインで済ませるようになってきた現在、「シェアウェア」という用語は既に本来の意味を失っているのではないか? (メッセージ数 2)

<http://db.tidbits.com/getbits.acgi?tlkthrd=2512>
<http://emperor.tidbits.com/TidBITS/Talk/371>


tb_badge_trans-jp2

非営利、非商用の出版物およびウェブサイトは、フルクレジットを明記すれば記事を転載またはウェブページにリンクすることが できます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありませ ん。書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017

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