ファイルメーカーで商用ウェブサイトを構築する
第2回　なぜファイルメーカーでなければならなかったのか？（3/3）

前のページ

AppleScript：外部アプリケーションの制御

　Interarchyは、Anarchie時代から、AppleScriptへの対応を果たしており、このApple標準スクリプトを使えば、FTPでput (アップロード) するファイル場所の指定、アップロード先のURLを組み込んだスクリプトを発行することができるのです。

"tell application ""Interarchy""" & "¶" &
　"activate" & "¶" &
　"store file """ & 記事URL & """" &
　" url ""ftp://destination.zdnet.co.jp"" path ""/zdnet/" & FTPディレクトリ & """" &
　" user ""ユーザー名"" password ""パスワード"" with binary" & "¶" &
"end tell" & "¶" &

　これは、AppleScriptを計算フィールドに入れた例ですが、このように、必要な情報を組み込んだAppleScriptを使い、対応アプリケーションをコントロールすることができます。AppleScriptは簡単は簡単なのですが、それですべてをコントロールするよりも、主な部分はファイルメーカーのスクリプトで組み、ワンポイントでAppleScriptを使うほうが作りやすいので、私はそのようにしています。

　この制作システムでは、実に多くのAppleScriptを使っています。画像ファイルを放り込む共有ボリュームの特定のフォルダを開くためにFinderを、画像ファイルのサムネールファイルを作るためにGraphicConverterを、記事をアップしたことをZDNet内のメーリングリストに知らせるためにUVJ Mailer、OMEを、作成したファイルをプレビューするためにInternet Explorer/Netscapeを、AppleScriptでコントロールしています。また、本文テキストに、ルールに従ってHTMLタグを埋め込む作業には、Jedit4を使っています。このあたりの役割分担については、次回以降の連載で詳述します。

　このように、足りない部分はプラグインやAppleScriptでどんどん補っていけるところが、このファイルメーカーProのすばらしいところです。ファイルメーカーのスクリプトは、ほかのデータベースソフトのスクリプトと比べて、かなり敷居が低く、使いやすいので、これら外部ツールの力を借りるにしても、いったん作ったモジュールを再利用すれば、その後はファイルメーカーのスクリプトのサブモジュールとして扱えば、楽に作業できます。

クロスプラットフォーム

　このAppleScriptを多用したシステムは、簡便な半面、クロスプラットフォーム環境においては「壁」となります。Macだけを使ったシステムが普通の会社で受け入れられるのはとても難しいのです。では、Windowsプラットフォームにおいて、AppleScriptライクな機能を用意するには、どうすればいいのか？　この部分は、プロセスの開始と終了を検知できるソフトウェアを別途用意しなくてはなりません（もちろん、一言で片付くような事ではありませんが）。

　また、プラグインに関しては、ほとんどのファイルメーカーProのプラグインが、MacintoshとWindowsの両方に対応しているので、スクリプトはほとんど改変なしですみます。

　なによりも、ファイルメーカーProを使うだけならば、MacとWindowsが機能的な格差なしに使えます。現に、ZDNet内のファイルメーカー利用者数は、Windowsがやや多いのですが、それぞれが同じようなインタフェースで利用できています。ZDNetではまだ実現していませんが、ファイルメーカーのWebコンパニオン機能を使えば、ウェブブラウザをインタフェースにして利用することも可能です。ZDNetのシステムは、外部アプリケーションを多用するため、Webコンパニオンの利用は難しいのですが、たいていのソリューションは、ウェブインタフェースで十分かもしれません。その場合、利用できるクライアントは、「実用的なブラウザがあるマシンすべて」ということになります。

　また、iモード、Palmといった携帯デバイスとの連携においても、ファイルメーカーは充実しています。ZDNetのシステムではまだ実装していませんが、将来は、Palmに関連記事を取り込んで取材にでかけたり、iモードから更新したりということが可能になるかもしれません。

　クロスプラットフォームなのは、クライアントだけではありません。サーバの対応も充実しました。これまでは、Windows NT、Mac OS 9だったサーバの選択肢が、ファイルメーカー Server 5.5からは、Mac OS X、Linuxが加わり、堅牢でコストパフォーマンスの高いサーバを簡単に構築することができるようになりました。

簡単に、堅牢なサーバを立てられる

　ファイルメーカー Serverをたてるのは簡単です。ZDNetでは、ユーザー数に応じ、最初はMac OS、次にWindows NTサーバ、そして現在はLinuxでファイルメーカー Serverを走らせています。

　ファイルメーカー Serverのセットアップは、クライアントソフトと同じく、非常に簡単で、ファイルメーカーでは5分間でセットアップ可能としているとおりです。実際、あまり設定項目もないですし。

　データベースファイルのバックアップなどは管理者が自分のマシンから設定可能で、起動した後はほとんどメンテナンスの必要はありません。リレーションで追加したい新しいデータベースも、簡単にサーバにホストできます。スピードとコストの点では、Linuxを使ったサーバは特に優秀です。また、ファイルメーカーが原因でサーバが落ちることは、これまでに経験してません。

　また、これらのサーバをスケールアップするためのパスが用意されているのは重要なポイントです。ウェブ公開を行うときに、サーバの負荷を分散するためには、ファイルメーカーPro Unlimitedが、開発環境を強化するには、ファイルメーカー Developerがあります。特に、ファイルメーカーのソリューションを開発するならば、ファイルメーカーDeveloperは必須です。

ミニマムの初期投資

　前回述べたように、ZDNetのファイルメーカーによる制作システムは、実にこじんまりと始まりました。最初はファイルメーカーProを1本とJeditだけです。まずは自分で使うだけのシステムをつくり、複数で使うようになったら、自分のファイルメーカーProを公開し、別のユーザーからアクセス可能にしました。次に、AppleShare IPサーバが動作しているマシンにファイルメーカー Serverを導入し、AppleShareと同居させ、ユーザー数が増えてきたらWindows NTサーバへと鞍替えしました。ですから、初期投資はごくわずかですみます。ある程度の形ができるまでは自分のファイルメーカーProで検証しながら開発し、複数のユーザーで使うようになったらファイルメーカー Serverを導入すればよいのです。

　ファイルメーカーを使ったシステム構築の場合、最も節約できるのは、「時間」です。開発にかかる期間はOracle、Accessを使った場合よりもかなり短いものになると、ファイルメーカーのあるデベロッパーの方が話していました。ZDNetの事例でも、開発のスペックが決まってから最終的にできあがるための期間が非常に短いことが採用のポイントになったのです。

　結局、ZDNetの社内システムの場合、クライアントソフト、プラグイン、外部アプリケーション、サーバソフトを合わせてもせいぜい100万円を超える程度。サーバのLinuxマシンにしても、20万円弱のもの。これで十分に運用できています。うーん、とても安上がりなシステムです。

　それと、なんといっても自分たちで開発をしたことにより、大幅にコストを削減したことはいうまでもありません。このシステム、外注して同じ機能を持つものを作ったとすれば、少なくとも数百万円はかかるでしょう。そして、機能を追加したり修正したりするたびにお金が飛んでいくはずです。このシステムは、最終目標としているシステムが開発されるまでのいわば「ブリッジ」にあたるわけですが、それでも実際に首尾よく運用されており、こうした実績の積み重ねが、ひいては最終目標としているシステムの開発コスト削減にも貢献するはずです。また、実際に記事のデータベースは保持され、Oracleデータベースにバックアップされていっているので、その貢献度は非常に高いと考えています。実は、このバックアップの部分も、今後、XMLを使った、より効率的なものに変更していく予定で、それもファイルメーカーならば、可能なのです。

　たった1本のファイルメーカーProからこんなのができてしまうなんて、すごくスケーラビリティのあるソフトです、実際。

[松尾公也, ITmedia ]

Copyright © ITmedia, Inc. All Rights Reserved.

前のページ | 3/3 | 最初のページ