Competition

封閉發表後才知道，原來 Google Map 在四月份就已經發表了 MyMaps 的功能。真是一個囧到不行啊，每次都這樣！

在這篇文章裡有介紹，原來類似的服務已經有多家供應商了。先記錄下來，等有空的時候再來好好爬文一番。不過今天稍微試用了一下 Google MyMaps 的服務，幸好他所謂的「意見」只能針對地圖來回應，不能發表在標記上面。呼～這大概是 TWW 和 Google MyMaps 唯一的差異所在了吧。

另外有關照片上傳的部份，PicasaWeb 早就提供了幫照片加上地圖標記的功能，只是我到今天才知道，只要在 Google MyMaps 裡面打開 Picasa網路相簿的 layer，就能夠看到所有在附近標記地點的照片。這個功能也要好好給他來研究一下。

第一次封閉測試開跑

儘管仍有些功能尚未完竣，但忙碌了三個禮拜，實在不想要繼續漫無目的地等待下去。於是在自己小有人氣的部落格上公開發表文章，徵求「愛旅遊的猴子們」一同來參與封閉測試。

封閉測試的帳號註冊有兩條路徑。第一是經由我設立的〈試驗場〉站台新增成員身分，寄發邀請函後據以註冊。第二是寫信到therewewere@takol.tw 申請註冊帳號，信中註明您慣用的登入帳號即可，我會產生一組隨機密碼給你，請自行登入後修改密碼。

TWW 的帳戶只有登入帳號這一個欄位是不可變動的，其他資訊包括顯示名稱、Email 等都是可以隨時變更設定的，這點究竟好不好，仍有待觀察。不過我覺得 TWW 不是個完全公開社團網站，所以就算個人顯示名稱或站台名稱有重複，應該也沒啥大關係才是。

使用者註冊功能完成

今天處在颱風來襲的平靜當中，一整天除了兒子跑來找我玩耍的交際應酬外，都窩在電腦前面趕工寫 TWW 程式。成果還算不錯，依照原先計畫地將使用者註冊的功能大致上完成了初版。

這次寄發邀請信函的 SMTP server，依舊是借用 Gmail 的服務。與以前幾個網站類似應用的差異點在於，我終於搞清楚了若是利用 Google Application 計畫的 mail account 登入 SMTP，username 須得要填入完整的 email address，而不像利用 Gmail account 來寄信時只填入 username 即可。

在寫註冊認證這段程式時，比較困擾的地方在於一些往返的訊息傳遞，由於得要透過網頁上的 Javascript，所以不能採取我們平常慣用 flash 來顯現。不過繞了個彎，自己想辦法用很醜的方式仍舊解決了需求，只是自己看了就很不酥胡，等以後想要 optimize 系統的時候再說吧。

目前完成的使用者註冊功能包括有：

1. 站台內可以新增其他成員身分
2. 可以寄出邀請函
3. 收到邀請函者，可以點擊郵件內連結開啟註冊頁面
4. 註冊時可以選擇 (1) 登入原有帳號 (2) 已經登入者可以直接加入站台 (3) 註冊新帳號

這些功能應該暫時足夠了。接下來要傷腦筋的是測試，可能得要開始找朋友幫忙扮猴子了。

模仿 Google Map 網站風格

雖說一開始就決定要以 SPA 的架構來設計 ThereWeWere 這個網站 ，但網站外觀和風格始終沒有個定調。開始建置網站的第一週前幾天，迅速以慣常使用的 Liquid width 3 columns style 設計出網頁模板，自我省視覺得有許多欄位似乎沒有顯示的必要。隨即調整成 Liquid width 2 columns style ，卻也不見得好到哪裡去。然後大幅度地更新至 Liquid width single form，同時將所有要顯示的支援訊息，都嵌入至 Google Map 元件內部，只保留少許必須要固定顯示的資訊，譬如使用者登入訊息等，保留在頁面上。

這個 Signle form 的版面設計，雖然寬度可以隨著視窗大小自動調整，但高度部份受限於底圖和邊框設計不能自動縮放，使得一些使用大尺寸螢幕的朋友反應意見覺得這樣不妥。思索了片刻，開啟 Google Map 網頁察看他是怎麼一種設計概念，隨後醒悟了所謂 SPA 網頁服務的幾個要素：

1. 將服務的主要元素設計成可以隨著視窗尺寸而縮放
2. 把你認為最有廣告效果的元素儘量固定在頁面上
3. 輔助性資訊可以縮放，不需要佔用寶貴的版面
4. 色系簡明扼要，能夠用來分隔不同分類的資訊最好

於是利用三個晚上的時間，重新構築了一個模仿 Google Map 網站風格的模板，然後微調修正了一些使用者控制的 Javascript。目前看來除了在 Google Chrome/Firefox/Opera 上面會有些 Windows & element initialize size 導致地圖元件顯示標記方塊稍有偏移的問題外（只要重新縮放瀏覽器即可修正），大致上看來還挺 User friendly。
這當中也曾碰到 IE6 相容性測試的問題，為了 PNG transparent 的這個討厭的 issue，害我浪費了好多時間來找最合適的答案。後來索性不理會 ugly PNG under IE6，遵照先前決議，趕緊把主要功能完成，丟出來讓朋友試玩看看大家反應再說。反正意見先驅者多半使用的是 FF/Safari，即便我大膽宣稱 "IE6 Forbidden Here!!" 大概也不會有什麼人持反對意見吧。
目前剩下的主要功能還有建立通訊錄、邀請朋友參加、認證與註冊這幾個曾經在其他專案做過，只要抄過來用就可以完成的模組，預計至遲到這週日，ThereWeWere 應該就可以正式推出 Beta 1 release 了。

完成使用者登入與編輯標記功能

今日的主要開發進度，在於調教地點標記的資料編輯功能。

編輯標記
目前已經提供線上編輯標記的位置、高度、名稱、說明等欄位，也可以選擇要顯示的小圖示。標記的內容編輯完成後，Google Map 會在不重新整理頁面的前提下立即更新地點標記的顯示資訊。

新增標記
可以在目前地圖中心位置新增一個標記，與編輯標記的功能相同，都可以編輯欄位和選擇圖示。

使用者
今日另增加了使用者登入登出等基本權限管理的功能，當使用者登入狀態改變時，不需要重新整理頁面，而是能夠直接改變頁面上各元件的顯示狀態。

搜尋最佳化 SEO
至今需要重新整理頁面，主要是涉及到 entry 的問題。包括網站服務的入口頁、各站台的入口頁、各地點標記的永久連結等三個層次，都是可以利用輸入網址直接跳入目標地。原先在網頁上是不需要顯示各入口頁的主要介紹內容，而是當使用者要求察看時以 AJAX 方式動態擷取說明文字，但考慮到網頁 SEO 的成效，或許會在網頁上，將各入口頁的說明內容以隱藏方式揭露但不顯示。

不過似乎聽說過 Google 對於網頁上不顯示的內容，不會將之列入搜尋關鍵字的範圍!? 這點仍有待查證，無論如何，網頁內容 SEO 仍然會是在服務開始之初就列入考慮的重要因子。

雛形漸成

今晚將編輯站台和標記的功能完成一個雛形後，基本上 TWW 日後的功能設計已經可以看得到、摸得到了。

大幅利用 AJAX 的方式，讓編輯資訊後的 submit 不用換頁，直接生效變更地圖上的資訊。會決定要如此進行，一方面是為了符合 SPA 的精神，二方面也是實在不敢領教 Google Map 重新載入的龜慢速度。

同時，配合編輯的做法，現在開始所有前端讀取的資訊，全都利用 AJAX 動態取得。好處是編輯資訊完成後不用重整頁面，壞處是平常開啟資訊的速度會相對較慢。

目前影響效能最鉅的是動態載入地圖可見範圍標記的這段 code，應該加上一些防止重複呼叫的 flag 才是。當系統正要載入標記資訊時，又有新 event 發生，必須遮蔽動作，但開啟「再更新」的flag，等待原先載入標記資訊事件完成後，如果有這個「再更新」flag，則得要再做一次。如此可以避免在更新過程當中，因為滑鼠拖動或捲動地圖，導致瞬間湧入十數個甚至數十個可以忽略的事件請求。

今天也修正了 icon 的 model，讓站台和標記物件不單是可以選擇系統預設的圖示，也可以上傳自己圖示，或者選用 Google Earth Icon ( 可以參考 這個網站 )。雖然這部份功能尚未實現，但應該也不難完成。

Dynamic Subdomain 與 Routing Rule

這兩天的開發有點遲滯。

從上周開始的第一階段研發，其著重點在於搞清楚 Google Map API 的應用與實作練習，作出來的網頁系統，是完全不管資料結構和使用者界面的那種快速打謎 (dummy) 成品。等到利用打謎系統當作基準，探討出未來網頁服務架構和功能需求時，打謎系統就顯得不夠理想，而開始要徹底翻修了。

其中，更改最多的就是 controller 和 routing rule 這兩部份。聽起來變動不多，但因為當初打謎系統的 Javascript 部份是 hard code 一些 AJAX request URI，所以只要改變了連結位置，就得要從頭檢查哪些 function 有應用到，哪些呼叫傳值有改變，稍一不慎沒有注意到差異，XmlHttpRequest 就是跑不出預期的回應結果。

這種 debug 過程非常傷心傷肝傷腎傷腦，所以只要遇到死迴圈問題無解，我就會暫時先停下開發的腳步，回頭和我兒子玩耍半天。若是還有一絲保留體力，可能等兒子上床睡覺以後會繼續奮戰，不過多半時候白天努力上班與下班陪伴兒子遊戲，耗損去我百分之九十九的資源，於是只得將 TWW 擱置一旁，無暇顧及。

今晚好好地修整了一下打謎系統，將一些功能恢復到修改 routing rule 先前的狀態，於是又能夠繼續開發下去了。


今天新找到的課題是： Dynamic DNS + VirtualHost + Subdomain

(1) Dynamic DNS
動態的 DNS Server 在我以前常用的 Windows 2000 Server 內附的 DNS Service 不支援，所以一直無緣嘗試。現在使用的 Windows Server 2003 與付費註冊的 http://name.com/ 提供的 DNS management 工具，都支援動態 DNS 設定。只要將主機名稱設置為 * ，然後指向到 IP 位置，便可以提供動態 DNS 的服務。

(2) VirtualHost
這個部份比較麻煩，暫時還沒克服。我的 Apache 是利用 VirtualHost 加上 Reverse Proxy，來搾乾那台主機的每一分硬體資源，在一台電腦裡塞入十幾個網站。如果要讓 Apache VirtualHost 支援 Dynamic Domain Name，可能得要利用 CanonialName 方式，或 mod_vhost_alias 方式來解。不過別人的解法都是以 DocumentRoot 這種 mod_rewrite 為考量出發點，似乎和我的 Reverse Proxy 不太符合。股溝了一個小時，暫且擱下，等有空或問到高手後再來想辦法。

(3) Subdomain
在 Rails 裡面要解析 subdomain 相對之下就很簡單了，只要利用 request.subdomains[0] 就能夠得到子網域的內容，放在 application.rb 當中的 before_filter 來預解析，就能夠得到存取要求中子網站代號。

三個步驟當中，最重要的環節 Apache 沒打通，一切都白搭。現在最擔心的是，如果未來 Apache 這部份搞通了，會造成整個 Routing Rule 又是一場大亂，那麼這幾天打謎系統紊亂的情況，可能又得要重演一遍。

SPA 的網頁外觀

SPA (Single-Page Application) 的特點是，利用 AJAX 的非同步互動機制，使得網站使用者的操作行為不用反覆下載整個網頁原始碼，而僅需針對有需要更新的內容元素與主機互動。

ThereWeWere 從一開始就設定採用 Google Map API 來開發，若是仍遵循舊有網站應用程式的思惟與架構，每個 hit/click 均導向至不同網頁，如此將完全享受不到 Google Map API 帶來的 mash-up 好處，而僅是將 Map 當作類似圖片一樣的一個 Applet，殊為可惜。


今日開發的成果，在功能部份沒有增加太多，反倒花了不少時間在重新調整網頁 Layout 部份。不單是修改了 Visual Design，還因應新的網頁外觀將 render partial 的架構給完全調整過來，順便把一些分散在各頁的 Javascript 蒐集起來，調整呼叫參數，讓 JS 也能夠讓各頁重複利用，減少各網頁下載頻寬。

計畫中，地圖的左手邊放置的是一些和「顯示」相關的控制按鈕，右手邊放置的是一些和「延伸機制」相關的控制按鈕。部份按鈕點擊後會顯示替代視窗，壓覆在地圖畫面之上，部份按鈕的功能則直接利用 Google Map 的 GInfoWindow 來進行顯示。

老實說，目前對於整個 ThereWeWere 的功能還沒有個完整的 guide line，只是一邊做一邊構思而已。這真不是個開發軟體的好習慣，但卻是最彈性，最方便省思，最容易調整的做法。

IE 的怪問題

這兩天努力地開發，已經可以漸漸達到 SPA (Single-Page Application) 的預期目標。除了點選站台時需要更換網址，希望在站台內各個旅遊地點的切換或資訊編輯，都能夠利用 AJAX 來達成。當然，為了便利搜尋與轉寄，各個旅遊地點的主頁仍然可以保留其永久連結網址，但若以站台當作 entry point 時，理論上不需要反覆載入網頁。

開發時的主要測試平台是 Firefox，原因是加掛的 Firebug 實在很方便，尤其這種 AJAX application 有一堆的 DOM 元件，前端網頁上看不到，也很難 trace/debug 資訊，這時候唯有 Firebug 才能協助開發者確認網頁內的 DOM 元件的確依照計畫變動數值，或 bind event handler。

可是，今天猛然發現，似乎有個常用的超連結寫法 <a href="#" onclick="xxx()">xxx</a> 這種東西，竟然在 IE 裡面發生了點狀況，網頁真的會重整網址到同一個 anchor:# 去。怪怪，心想不應當如此，寫了這麼久 IE 底下的 JS，都沒有發生過類似的問題。或許是其他地方出錯所致吧，仍有待檢查和測試來澄清。

避免 Memory Exceed 的問題

Google Map API 很方便，可以在極短的時間內，搞出一個看來頗為有趣的網頁內容。但其中有一些技術上的問題，可能在開發之初就得要納入開發計畫當中。

(1) GUnload 的應用

GMap2.GUnload() 函數用以釋放所有GMap2物件宣告使用的資源，以傳統網頁元件而言，因為使用到的 Javascript 物件沒有這麼誇張，所以根本不需要特別考慮釋放資源的問題，直接關閉網頁或瀏覽器即可。但根據這兩天的觀察，GMap2物件的確非常吃系統資源，經常導致IE耗費記憶體過大，作業系統不穩定。

建議還是能夠在 document.body.onunload 指定使用 GUnload() 函式，釋放系統資源，避免上述的問題。

(2) Markers 標記陣列

在地圖上，隨著位置更動事件，動態增列了許多 Markers 來標記地點，這些 Markers 都以一個 Javascript Hash 陣列來儲放。遇到要增列標記時，先檢查是否存在 Hash 陣列裡，然後添加。但如果這個陣列不清理，儘管陣列元素資料不多，仍會導致陣列持續耗費系統資源。

建議當地圖位置更動時，除了動態增列 Markers 標記外，也要動態檢查刪除地圖以外看不到的標記。

我們正在開發階段

ThereWeWere 從 2008年9月7日開始發想，目前正在開發階段。為了讓朋友們瞭解並同時能夠參與我們開發過程中所有思考的方向、研究的心得，特別開設這個 Blog，當作開發團隊與各位朋友的溝通管道。