つくるとき，何も参考にしてはいけない。Web2.0は忘れてよし

Web2.0って何なのでしょうか。

マッシュアップを考えるとき，この問は影のようにいつもついてまわります。

マッシュアップをつくるときの最大のハードルは技術やスキルではありません。Web2.0的な何かです。

Web2.0準拠のウェブアプリケーションとは何か。

考えたって，有名ないくつかのマッシュアップの共通点を探したって，答えはでません。ある定義に沿って開発すれば広くみんなに受け入れられるものでもないし，ましてや，法則なんてありません。答え探しをするのはやめましょう。ノイローゼになります。

Web2.0的な何かなんて，はっきりいって雑音です。あなたの動機と熱情が，インターネット越しに多くのユーザーに届き，共感を呼んだなら，彼らはあなたの成果をブログで紹介してくれたり，あなたが普段読んでいるメディアに掲載されたり，ソーシャルブックマークで「Web2.0」とタグがつけられるでしょう。

結局のところ，あなたは何をしたいのかということです。

開発していく手順の確認

わたしがマッシュアップをつくっていく順序は，いろいろな試行錯誤から下記の手順に落ち着きました。

1. インフラ
2. インターフェース
3. パイプライン

インフラとは，あなたが自分で収集・蓄積したデータベースや各種APIからデータを引き出すための入出力プログラムの作成をいいます。この場合，どちらかというとサーバ側のプログラムを，PHPやPerlのような言語で開発します。

インターフェースとは，あなたがつくろうとしているマッシュアップに最適なインターフェースをつくるために，HTMLやCSSを書く作業のことをいいます。

パイプラインとは，上記で開発したサーバ側の入出力プログラムで取り扱うデータを，インターフェースに表示するためのプログラムのことをいいます。この場合，Ajaxを使いつつ，JavaScriptでサーバ側プログラムから情報を受信するようなプログラムを作成します。

ふつうは，サーバ側からユーザ側に向けて，あるいはその逆の方向に向かって一方向につくっていくのかもしれません。

しかし，

1. サーバ側をつくり，（⁠連載第2回目。今回）
2. ユーザ側をつくり，（⁠連載第3回目）
3. 最後に両方をつなぐ。（⁠連載第4回目）

この順番でつくるといくつかのメリットがあります。

その詳細な理由は，本連載第4回目に，上記３つのステップを俯瞰することで，見えてきますが，まず，初期開発や，のちのちのメンテナンス，機能拡張においても，たりない処理を見極めて，あれこれ小難しく考えずに，サーバ側プログラムに淡々と必要な関数を追加していくだけなので，開発スピードが向上します。

これは，サーバ側プログラムにおいても，ユーザー側インターフェースにおいても，パイプライン部のJavaScriptにおいても，共通していえることです。

また，このような開発手法があとあと効果を発揮しはじめるのは，あなたが続々とマッシュアップをつくりはじめたときです。

もちろん，上記の開発手法は「オブジェクト指向」といわれるものなので，次のマッシュアップ開発のときに実際に新たに記述するコードの量をカットできるわけですが，それ以上に，あなたのマッシュアップ群を相互に紐づけるのが容易になります。このあたりのことは，次のセクションでお話しします。

まずあなたは，あなたのアイデアを形にするための道順を知り，すべを身につけるべきなのです。あなたに足りないこまごまとしたテクニックやセキュリティへの配慮は，いまは必要ありません。そのような細かい配慮がいるようになったとき，検索するなり解説書を1冊買うなり，ピンポイントで検討すればよいのです。

最初にすることは，インフラづくり

さて，サーバ側でするのは，あくまでもプレーンなデータをライト（JSON形式が理想です）に出力して，細かいテクニックはJavaScriptでおこなうということに徹します。

このためのプログラムを，PHPやPerlのようなサーバ側のプログラムで用意します。

というのも，マッシュアップはAjaxという方法でリアルタイムに他サーバと通信をする場合が多いのですが，JavaScriptは自分が属するサーバ内でしか通信をすることができないという制限があるので，このような用途には適しません。

一方，JavaScriptとは異なり，PHPやPerlのようなサーバ側のプログラムにはそのような制約なしに，自分のサーバ内のほかのプログラムや，他サーバのプログラムと通信することができるため，自サーバと他サーバを中継するプログラムをサーバ側で用意することになります。

さて，簡潔にいうと，サーバ側は下記の3ステップを担います。

1. 入力（外部APIであったり，ユーザーのリクエストであったり）
2. 出力するためのデータを加工（HTMLタグをとったり，つけたり，暗号化したり）
3. 出力（HTMLの形やJSONの形で，じかに書き出したりJavaScriptに渡したり）

とはいってもこのとき，サーバ側プログラムを一体のものとは考えずに，いくつかの処理ステップの組み合わせと考えるようにすると，次回以降のマッシュアップの手間が大幅にカットされます。

PHPやPerlのビギナーなら，「⁠オブジェクト指向」というキーワードを耳にしたことがあるでしょう。しかし，オブジェクト指向のことは忘れてください。クラスやメソッド，継承，カプセル化など，いったい何のことを言っているのか理解しようとし始めると，形而上的な世界に入っていくことになります。

そのうえで，下記にプログラム的なステップの目安を示します。

• （a）APIからデータを受け取る「だけ」の処理
• （b）受け取ったデータを分解して，ヘッドラインはヘッドライン，本文は本文，画像は画像というように，連想配列に入れていく「だけ」の処理
• （c）文字列のなかに不適切な文字がないかを確認する「だけ」の処理
• （d）不適切な文字を適切なものに置換する「だけ」の処理
• （e）JSON形式にまとめ直す「だけ」の処理
• （f）JavaScriptに出力する「だけ」の処理

上記のようにそれぞれの処理を細切れにして開発すると，あとで手間がカットできます。たとえば現在のマッシュアップではこれらすべてを使っていますが，今度は，

• （a）APIからデータを受け取る「だけ」の処理
• （e）JSON形式にまとめ直す「だけ」の処理
• （f）JavaScriptに出力する「だけ」の処理

というように，特に処理をせずに，入力されたデータを単純に出力するという，右から左に受け流す処理だけで済むかもしれません。

そのときに，また同じようなプログラムを書くのではなく，以前書いたひとまとまりのプログラムから，（⁠a）（⁠e）（⁠f）の部分だけ持ってきて使うのです。特に，上記で示したようなごくありふれた処理は意識的にばらばらにしていくと，だんだんとプログラム面に使う時間は効率化していくはずです。

だからばらばらにして，必要なときに組み合わせて（マッシュアップして）形作るのです。

さらに，あなたのマッシュアップの発展性についても利点があります。

おそらく，あなたがつくろうとしているマッシュアップは，あなたがほしいと思っているサービスでしょう。

あなたのニーズをかなえてくれるサービスがどこかで扱っているものと思い，検索したけれども見つからず，だから自分でつくろうとしている。

そのような性質のものであるほど，マッシュアップは型破りでユニークなものになっていきます。

つくりたいウェブサービスがあるとします。

つくりたいウェブサービスがあるということは，その実現のために必要なデータが何であるかを把握しているということです。

そのとき，必要なデータがいつもどこかからAPIやRSSフィードとして提供されていればいいのですが，あなたのサービスがユニークであるほど，必要なデータもユニークになっていき，どうせならウェブをクロールして独自にデータを集めたいと思うようになるかもしれません。

あるいは，いまは３つのAPIのマッシュアップで事足りてはいるけれども，あとあとよく考えてみると，もうひとつAPIを足したほうが使い勝手が高まることに気づくかもしれません。

そういうとき，もうひとつのAPIを利用するためにさくっとコピーアンドペーストでサーバ側プログラムをもうひとつ作ればいいのです。