doodleのシステム構築
マッシュアップサイトだそうですが、どんなWeb APIを使っていますか
使っているのは次のAPIです。
| 機能 | Web API |
| 地図全般 | Google Maps API |
| 最寄り駅のレーダー | SimpleAPI vol.2 - 最寄り駅Webサービス＆最寄り駅モバイル地図 |
| えきdoodle | HeartRails Express | 路線／駅名／最寄駅データサービス |
| めしdoodle | 価格.com WEBサービス 食べログ.com レストラン情報取得API、ホットペッパー Webサービス |
| やどdoodle | 価格.com WEBサービス yoyaQ.comホテルプラン情報取得API |
| PCでの位置特定 | PlaceEngine |
| 住所などの逆ジオコーディング | invgeocoder |
その他、図書館蔵書検索で東京都のOPAC、WILLCOMの駐車場検索、APIではないですが位置の表現でLocaPointなどを使用しています。
どんなプログラミング言語で構成されているんですか
いわゆるLAPP環境（Linux、Apache、PostgreSQL、PHP）で動いています。オープンソースの処理系には以前からこだわりがありまして、業務サイトでさえも、ずっとその組み合わせで作ることが多かったので、今回もそうしました。
まだそれほどトラフィックは無いので、レンタルサーバ1契約だけで動いていますが、今後ユーザが増え、スケールアウトも視野に入れられるくらい成長したらいいな、なんて思ってます。PHPはやりたいことが手軽にすぐできるので、何でも作れる大切な道具ともいえますね。
開発期間について教えてください
doodleと決まってからリリースまでは約1ヵ月ぐらいです。その後、Mash up Award 2ndを知り、そのためにマッシュアップ先を増やしていったのが1ヶ月くらいなので、合計2ヶ月程度かと思います。確かにdoodleの前身は、1年以上かけて作っていましたが、新しく挑戦した技術やコード量から言えば、リリースまでの短期間のほうが断然内容が濃かったですね。
ケータイ全キャリア対応、多くのAPIへのマッシュアップ対応、POPメール連携対応、Exif連携、ケータイ動画対応、Wii対応、Googleマップのクロスブラウザ対策などなど、初期βリリースまではdoodleのことばかり考えて、それこそ寝てる間も夢の中でコーディングしているような状態でした。やってみてわかることも多く、例えばDoCoMoやauは画像送信に使うフォームアップロードさえできないという事実など、初めて知る事だらけで大変でした。とはいえ、今にして思い返せば、忙しいながらもとても充実した2ヶ月間だった気がしています。
悩まされた4キャリア対応、クロスブラウザ対応
特に苦労された点はどこですか
手元にはWILLCOMしかなかったので、しばらくはWebで検索した仕様をもとに想像で作成していました。しかしそれだけでは限界があります。社内のメンバーがDoCoMoとSoftBankを持っていたので私はauを買い、4つそろったところで実際に動作確認したんですが、あまりの挙動の違いに愕然としましたね（笑）。
仕様の違いを簡単にまとめるだけでも以下のようになるんですが、「PCとモバイルの違い」「モバイルでも4キャリアごとの違い」と、とにかくその差違を吸収するのが大変でした。
| キャリア | 測地系 | 座標値 | 変数形式 | 端末固有情報 | 格納方法 |
| DoCoMo | 世界測地系（GPS） | 度分秒 | 分離型 | 都度取得 | UserAgent埋込 |
| au | 世界測地系（GPS） | 度(選択可) | 分離型 | 常時取得 | 独自環境変数 |
| SoftBank | 世界測地系（GPS） | 度分秒 | 一体型 | 常時取得 | UserAgent埋込 |
| WILLCOM | 日本測地系（基地局） | 度分秒 | 一体型 | 都度取得 | 独自変数（GET） |
クロスブラウザ対応も大変だったと聞きました
IEとGoogleマップとの相性を克服するためだけに2週間かかりました。特にIEは仕様が公開されてないし、エラーのトラッキングも全くできないのです。この件は私のブログにも書いてあるのですが、「IE Google Maps アクセスできません」などのキーワードが未だに私のブログ訪問者検索ワード第2位になるぐらいですから、多くの方が苦労しているのかもしれません。
今のところ経験的にわかっているのは、IEはonloadで呼びだすとうまくいくことが多いこと、つまりレンダリングの順番の問題だと思うんです。IE以外はJavaScriptがどこにあっても（プリコンパイルするのか、そのままインタープリートするのかは精査してませんが）、素直に滝の流れに沿うんです。しかしながらonloadでの実行タイミングは「ページが読み込まれた後」ですから、どこでGoogleマップのインスタンスを生成しているのか、また実際にレンダリングする変数の位置によって不安定になってしまう。それにonloadで関数呼びしていると変数のスコープの問題も無視できなくなる。そこにAjax通信も絡む。どんどん複雑化してスパゲティコードになっていってしまうんです。
今ではきちんと動いているので一安心です。ただ、今後Safariなども出てくるでしょうから、また検証が大変になるかもしれません。
マッシュアップする上でCGI×Ajaxの連携技術問題
マッシュアッププログラミングならではのコツはあるのでしょうか
従来のいわゆるCGIによる処理は、自分のあずかり知るサーバ側ですべての処理が行われますので、エラーのトレースも比較的見えやすいんですね。ところが、Ajaxとなると実行タイミングもさることながら、クライアント側で処理されるため、エラーのトレースが格段に難しくなります。もはやテキストエディタ一本での開発では限界を感じ始めるようになりますが、まだ頑張っています。
最近ではFirefoxの拡張機能でもFirebugなどいいツールが多くそろってきているので、メインでFirefoxを使っています。ちなみに弊社のみんなの拡張機能（Minkaku）というサービスで、便利な拡張機能がたくさん見つかるのでぜひ利用してみてください。
下のコードは簡単なサンプルなんですが、もともとプログラムってpro（前もって）－gram（書かれたもの）というのが原義だそうです。その意味から行けば、AjaxをCGI側で書くということは、それらの処理も事前に想定して「さらに前もって書く」ということを意味するんですね。いわゆるPre-Programingとでも言うのでしょうか。
「ダブルクオートとシングルクオートのエスケープ」「PHPの変数とJavaScriptの変数」が混在した一見複雑怪奇なCGIとAjaxのアルゴリズムが連携して綺麗に動いたときには、従来のCGIだけの処理では味わえなかった達成感のようなものを、開発者なら誰もがきっと味わえるはずです。この境界線こそがWeb 1.0とWeb 2.0の処理系での違いのような気がしています。
<?php if($hoge=="*"){ //←PHPの変数 print("<script language=\”JavaScript\”>"); print("if(hoge==\"*\"){ //←JavaScriptの変数 document.write('<form><select name=\"hoge\"> <option value=\”'+dlat[“.$i.”]+'\”>hoge</select>') }"); // ↑JavaScriptの変数をPHPの変数で作っている //=================================================Web1.0→2.0境界線?! var httpObj = GXmlHttp.create(); httpObj.open("GET",getstation,true); httpObj.onreadystatechange = function() { if (httpObj.readyState == 4 && httpObj.status == 200) { //↑ここでステータスを取るのに実行されるのは外側のSend() hoge(); } } httpObj.send(null); //←ここで実行
