ファイルメーカーで商用ウェブサイトを構築する
第1回　メルマガからウェブサイトへ　ZDNet実践編（4/4）

前のページ

ZDNetデザインリニューアル

　すべてのチャンネルが同じデザインスキームを使うようになる。これは、デザイン上の統一感だけではなく、制作システム上も非常にありがたいことです。HTMLのモジュールを共通化することにより、開発期間を短縮でき、デザインの変更があった場合でも、そのモジュールを変更するだけで、同じシステムを使っているすべてのチャンネルが対応できます。

　また、1つのチャンネルに追加された機能は、すぐにほかのチャンネルで利用できるようになります。ZDNet Macは、実験的な機能をほかのチャンネルに先駆けて実装しており、それをほかのチャンネルでも使うことが可能になりました。もちろん、逆のこともできます。

　さて、リニューアルと口でいうのは簡単ですが、決めるべきこと、やるべきことは非常に多いのです。

• デザインコンセプトを決める
• ファイル名、URLのパターンを統一化する (過去のいろいろなチャンネルを比較すると、いくつものパターンにわかれているのに気付くでしょう)
• インデックスのパターンを決める
• タイトルやアブストラクト (記事のサマリー、概要) 、メタタグなどの要素決め
• 本文をHTMLに変換するときのルール統一
• 各チャンネル独自ルールのうち、どれを生かし、どれを廃するか

　これらは自分たちだけで決められるわけではなく、それぞれのチャンネルの編集者との話し合いになります。また、全社的な話し合いをして決めなければならない事項もあります。ただ、こちらも編集者であり、了解している事項もまた多いため、ある程度予想で決めうちしたうえで提案することができました。これは、時間の節約につながります。

　このため、このプロセスはきわめて短期間に終えることができました。デザインパーツのラフがあがった段階で、HTMLのそれぞれのパーツのモジュールをファイルメーカーのスクリプトでつくり、担当者にラフのスクリプトで生成したページを見せて確認することもできました。

　このシステムづくりと並行して、私が担当している複数のチャンネルのリニューアルも図らなければなりませんでした。そうです。このデザインリニューアルと同時に、MacWIRE-DとMacWIREを統合し、ZDNet Macに変えるという仕事もあったのです。さらにもうひとつ。ZDNet Downloadsを縮小化し、ZDNet Productsの中に組み込み、ZDNet Productsのデザインをリニューアルという大きな作業もあります。ZDNet Productsの制作システムはほかのチャンネルとはまったく別であり、こちらは完全にこちらのコントロール下で行っています。ニュース的な記事とは違い、こちらは最初からデータベースとしての形があって、それを、多数のインデックスとともに見せていくというつくりです。作り替えるスクリプトは膨大なもので、かなりの時間を割いて作業を完了しました。

　もうひとつ、新規サブチャンネルの立ち上げも並行して行っていました。ZDNet Reviewのスタートです。PC系のレビューを専門に行うチャンネルとして、やはり5月にスタートさせました。これは新しい制作システム上で行いましたが、デザインに相当手を入れなければならず、テキストのHTML化の部分で困難を強いられました。ほかのニュース記事とは違い、図表が入り、テキストの装飾性も高いものにする必要があります。ここはなんとか、AppleScriptを使ったJedit4コントロールで乗り切りました。ほかのチャンネル用とは違うテキスト→HTML変換ルーチンを作ったのです。

　このルーチンが適用されるのはHTMLファイルのうち、本文テキストの部分だけなのですが、ZDNN、モバイル、ブロードバンドが使っているのが、ファイルメーカーの内部コマンドだけを使ったモジュール、MacはJeditをAppleScriptで制御したもの。ZDNet Productsは、それの改良・カスタマイズ版です。合計3つのモジュールを使っています。これは、ある意味、過渡的なもので、最終的にHTMLの埋め込みタグのルールが統一されれば、それに決めうちでもよかったのですが、日々拡張しているため、この部分はいまでもどんどん膨らんでいます。

　共通化している部分もあれば、独自モジュールを使っている部分もある。そういうキメラ性を許容しているところが、ファイルメーカーを使ったシステムのすばらしいところで、要するに、「現在の業態に合わせる」ということが可能なのです。そのあたりの事情については、次回「なぜファイルメーカーでなければなかったのか」で解説することにします。

もう1つの制作システムの登場

　実は、当初動いていた制作システムに限界があるということで、別のUNIXベースのシステム開発が、システム部門で動いていました。少人数でこつこつやっていたこともあり、開発完了に時間がかかることが判明したために、急きょ、ファイルメーカーの制作システムをあいだにかませて、あとでデータベースを統一化しようということになったのです。

　このあたりの経緯はいろいろあるのですが、最終的に次のように決まりました。

• ファイルメーカーシステムは、UNIXベースのシステムですべてを置き換えることができる時点まで続ける
• そのあいだ、相互のデータベースの同期を行う

　つまり、ファイルメーカーのシステムは「実用的なつなぎ」として使い、別のシステムに移行したときには、フロントエンドとして使う可能性がある、ということになりました。バックエンドのデータベースはOracleを使うことになり、記事のアップなどはウェブブラウザベースでcgiで行うことになっても、データベースブラウザとしての役割はそのまま使うことができるのです。また、そのUNIXシステムの完成は、いつになるかわかりません。ぼくらがファイルメーカーで作ってきた3年間のノウハウをPerlもしくはPHPで移植しなければならないので、それなりに大変なのです。しかし、そこはモジュール化されたUNIXプログラムの世界。ファイルメーカーからは、開発された、一部のプログラムを利用することもできるのです。

　記事のHTMLデータをステージングサーバにFTPして、それを複数の本サーバに配付する作業は、syncコマンドを使ったプログラム化されていますが、システム担当の新しい社内プログラマーが、これにウェブのフロントエンドを作り、ファイルメーカーがHTMLファイルをFTPし終わると、このプログラムに引数を渡すことができるようになりました。これまでは、telnetやsshを使って、このサーバにログインしてAppleScriptでターミナルを制御して、コマンドを発行していたのですが、これが、より簡単で安全なプログラムに置き換えられました。これまでは、FTPソフトやtelnetソフトを使っていたところが、単なるブラウザで置き換え可能になったのです。これは大きな進化です。

ファイル名やディレクトリ名を引数として渡すことにより、このようなcgiを外部アプリケーションとして使うことができる

　このように、基幹システム側が改善されれば、それにキャッチアップした接続スクリプトをすぐさまファイルメーカーに追加することで、さらに使いやすくなるのです。ファイルメーカーとOracleのデータ同期も、現在はODBCもXMLも使わない、単なるFTPと取込みcgiで実現していますが、FileMaker Pro 6で実装されたXMLを使えば、さらに簡単に、両方のデータベースの整合性をとることができるようになるはずです。

　当初は、「エンドユーザーが勝手にやっている」と見られていたファイルメーカーが、いまではバックエンドと見事に緊密に動いています。そこに、このデータベースソフトウェアが単にデータベースだけではなく、ソリューションを作り出す「ツール」である証が見えてきます。

　では、次回は具体的に、ファイルメーカーのどこがよかったのかを、検証していきたいと思います。

[松尾公也, ITmedia ]

Copyright © ITmedia, Inc. All Rights Reserved.

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