原本標記內容的 HTML 語法我並沒有禁止使用，以方便幫助我測試的朋友們貼上一些例如 YouTube 或 BuubleShare 等 widget，來豐富各地點標記的內容。但今日新增的訪客標記功能一旦開放，HTML 語法很可能成為系統安全上的一個漏洞，讓有心人士貼上 JavaScript 或嵌入隱藏式的 iframe 產生 cross-site-scripting (XSS) 的攻擊行為。
因此，目前暫時取消了在標記內容支援 HTML 語法，凡是在角括號 < >內的文字都會被自動忽略不顯示。至於 YouTube 和其他常見的 widget，例如 flickr 和 flash 等，未來可能會以其他特定語法格式來替換。譬如：[[YouTube∣nwXUuA8gSRU]] 或 [[BubbleShare∣175572.9c17866b383]]。
2008年10月25日
新增功能：免註冊立即建立訪客標記
今日新增了一個功能，允許訪客毋需註冊帳號，就能夠立即在地圖上新增標記。訪客新增的標記如同正常的地點標記一般，可以編輯名稱、位置、說明內容和圖示，但僅在建立標記時的瀏覽器未關閉前有效（以cookie認證)，若訪客關閉了瀏覽器，這個標記的內容就再也無法編輯了。
這個訪客建立的標記，在資料庫結構中與正常的地點標記是分離的，以維繫原用戶資料的隱私問題，且這種標記的永久連結語法也和地點標記不同，以 m. 為開頭。
要建立此類訪客標記，只能在首頁或其他訪客標記的地圖上才行，進入到某個站台後的地圖，僅能允許該站台的登入用戶新增站台內的地點標記。
目前並未考慮到網站用戶新增的訪客標記如何納歸至站台地點標記的問題，按照設計概念，採用訪客標記的目的在於臨時測試、滿足好奇，網站用戶既然已經有了帳號，可以隨意新建站台與增加地點標記，沒有理由回頭使用訪客標記。況且，既然訪客標記是利用短暫cookie來認證，技術上也很難知悉哪個訪客標記是由誰來建立的。
這個訪客標記的功能暫時沒有任何存取限制，不過有記錄訪客標記最後一次的存取時間，未來如果訪客標記資料量過大（會這樣嗎？），也許考慮將一段時間沒有存取的標記從資料庫中刪除。
這個訪客建立的標記，在資料庫結構中與正常的地點標記是分離的，以維繫原用戶資料的隱私問題，且這種標記的永久連結語法也和地點標記不同，以 m. 為開頭。
要建立此類訪客標記，只能在首頁或其他訪客標記的地圖上才行，進入到某個站台後的地圖，僅能允許該站台的登入用戶新增站台內的地點標記。
目前並未考慮到網站用戶新增的訪客標記如何納歸至站台地點標記的問題，按照設計概念，採用訪客標記的目的在於臨時測試、滿足好奇，網站用戶既然已經有了帳號，可以隨意新建站台與增加地點標記，沒有理由回頭使用訪客標記。況且，既然訪客標記是利用短暫cookie來認證，技術上也很難知悉哪個訪客標記是由誰來建立的。
這個訪客標記的功能暫時沒有任何存取限制，不過有記錄訪客標記最後一次的存取時間，未來如果訪客標記資料量過大（會這樣嗎？），也許考慮將一段時間沒有存取的標記從資料庫中刪除。
2008年10月19日
轉不轉型，大有干係
TWW 完工至今已經近一個月了，朋友們幫忙測試的狀況老實說，很不好。畢竟大家都是礙於情面上來幫忙點點標記，貼貼圖片，沒有大量操作和持久應用，就找不到系統的重大問題，和功能上應該改進的關鍵點。這時，原本將 TWW 定位和 DWW 一樣的「半封閉社群網站」這個基本的網站定型，便不時產生信心動搖，而開始重新省思這樣的定型究竟是否妥當。是否讓一般訪客非常容易地註冊帳號，甚至提供不須註冊的免費服務，讓訪客立即快速產生僅含單一地圖標記的連結，供交換資訊使用。這種免註冊的服務僅在當前頁面 cookie 可以修改內容，關閉瀏覽器或超過1 個小時以後就不能再編輯，除非註冊帳號並將此免費的頁面轉換為「站台」，才能繼續延伸使用。
第二點，TWW 推出以後我才發現 Google MyMaps 既有服務的完善度實在難以與之匹敵，若不提供一個市場區隔更多，或更有趣的網路服務，很難要求一般用戶棄捨原先 MyMaps 簡單易用的界面，和幾乎人人都有的 Google/GMail Account，另外註冊帳號使用一個不完全熟悉的操作界面。所以該不該僅僅拘泥於「地圖標記」這樣一個沒有特色的原則上，實在值得好好考慮。要提供些什麼功能呢？Blog？Album？Embedded Widget？
第三點，TWW 與 Google MyMaps 最大的差異在於 TWW 能夠在地點標記上提供大量的參考資訊和「遊記」這個類似於 Blog 文章的功能。且 TWW 既然屬於「地圖類資訊網站」，就不免與「旅遊 Blog」扯上關係。旅遊 Blog 需要些什麼元素？(1) 拜現代數位相機方便之賜，旅途中拍攝的照片量一定不少，如何與既有照片網站結合，例如 flickr 和 picasaweb，卻又不能與其既有的地圖標記功能雷同，這點需要有智慧地好好策劃，以借用既有網站的功能卻又得要儘量避免與之競爭； (2) 既然 Blog 這個通俗的功能免不了，那麼 Blog 該有的元素，例如回應／迴響 (comments)、引用 (track-back)、分類／標籤 (category/tagging)，是不是都必須陸續出現在 TWW 當中呢？
我想，上述的轉型和新功能，都可能無預警地突然出現在接下來這一個月當中。只是在開發程式之前，想清楚究竟該往哪裡發展，或許比花時間做了一堆白工後又修正路線要來得睿智點。
第二點，TWW 推出以後我才發現 Google MyMaps 既有服務的完善度實在難以與之匹敵，若不提供一個市場區隔更多，或更有趣的網路服務，很難要求一般用戶棄捨原先 MyMaps 簡單易用的界面，和幾乎人人都有的 Google/GMail Account，另外註冊帳號使用一個不完全熟悉的操作界面。所以該不該僅僅拘泥於「地圖標記」這樣一個沒有特色的原則上，實在值得好好考慮。要提供些什麼功能呢？Blog？Album？Embedded Widget？
第三點，TWW 與 Google MyMaps 最大的差異在於 TWW 能夠在地點標記上提供大量的參考資訊和「遊記」這個類似於 Blog 文章的功能。且 TWW 既然屬於「地圖類資訊網站」，就不免與「旅遊 Blog」扯上關係。旅遊 Blog 需要些什麼元素？(1) 拜現代數位相機方便之賜，旅途中拍攝的照片量一定不少，如何與既有照片網站結合，例如 flickr 和 picasaweb，卻又不能與其既有的地圖標記功能雷同，這點需要有智慧地好好策劃，以借用既有網站的功能卻又得要儘量避免與之競爭； (2) 既然 Blog 這個通俗的功能免不了，那麼 Blog 該有的元素，例如回應／迴響 (comments)、引用 (track-back)、分類／標籤 (category/tagging)，是不是都必須陸續出現在 TWW 當中呢？
我想，上述的轉型和新功能，都可能無預警地突然出現在接下來這一個月當中。只是在開發程式之前，想清楚究竟該往哪裡發展，或許比花時間做了一堆白工後又修正路線要來得睿智點。
2008年10月13日
Google MyMaps 與 ThereWeWere 的最大差異
今晚花了點時間好好地把玩了 Google Map 提供的 MyMaps 功能，赫然發現，原來在 MyMaps 的地圖標記裡面，是沒辦法設定放大標記的描述框的。這代表，在標準的 Google Map 地點標記描述框大小當中，沒辦法塞入比較大尺寸的照片，和更多的內容。
TWW 這方面的設計就比較有彈性了，不僅允許使用者將描述內容局部擷取當作點選地點標記後立刻顯現的簡述內容，還能夠放大地點標記的描述框至地圖 90% 大小，來觀看更多的內容，和相關的遊記。
揣測 Google MyMap 之所以要如此限制，主要是因為這些由使用者貢獻的內容允許一般用戶在附近地點搜尋，若是無限制地讓使用者在單一地點標記中貼入過多資訊，不僅可能造成搜尋者無法 focus 在地點標記資訊上（會被其他附加資訊吸引注意），還可能被「洗螢幕」讓這原本該是公共使用的地圖遭到有心者濫用。
另外，由 Google Earth 儲存的 .KMZ 檔案也能匯入到 MyMaps 這個功能，應該也可以考慮添加至 TWW 當中，如此就可以讓習慣使用 Google Earth 記錄旅遊行程的朋友，快速將既有的資訊匯入。
最後，因為使用 Google Earth 的地點標記，這才發現原來我花了一個晚上辛苦地取得 Google Maps 當中的圖示網址，其實在 Google Earth 一眼看盡，而且還有更多的選擇可供使用哩。真是囧啊啊～
TWW 這方面的設計就比較有彈性了，不僅允許使用者將描述內容局部擷取當作點選地點標記後立刻顯現的簡述內容，還能夠放大地點標記的描述框至地圖 90% 大小，來觀看更多的內容，和相關的遊記。
揣測 Google MyMap 之所以要如此限制，主要是因為這些由使用者貢獻的內容允許一般用戶在附近地點搜尋，若是無限制地讓使用者在單一地點標記中貼入過多資訊，不僅可能造成搜尋者無法 focus 在地點標記資訊上（會被其他附加資訊吸引注意），還可能被「洗螢幕」讓這原本該是公共使用的地圖遭到有心者濫用。
另外，由 Google Earth 儲存的 .KMZ 檔案也能匯入到 MyMaps 這個功能，應該也可以考慮添加至 TWW 當中，如此就可以讓習慣使用 Google Earth 記錄旅遊行程的朋友，快速將既有的資訊匯入。
最後，因為使用 Google Earth 的地點標記，這才發現原來我花了一個晚上辛苦地取得 Google Maps 當中的圖示網址，其實在 Google Earth 一眼看盡，而且還有更多的選擇可供使用哩。真是囧啊啊～
2008年10月11日
插入連結與圖片的文字語法
在入口標記或地點標記的說明文字欄位內，如果想要插入圖片或連結，不需要懂得 HTML 語法也可以喔！
1. 插入圖片
直接輸入圖片網址即可，但圖片網址必須以 http:// 開頭，且以 .jpg .gif .png 等副檔名結尾。
2. 插入內部連結
放大顯示入口標記或地點標記的描述框，可以在標題下方查詢得知該標記的標記代碼。
輸入 [[標記代碼]] 或 [[標記代碼∣顯示文字]]，系統會幫你自動將這種語法轉換成在地圖上移動至該標記的程式語法。
3. 插入外部連結
輸入 [[連結網址]] 或 [[連結網址∣顯示文字]]，系統會幫你自動將這種語法轉換成外部連結的 HTML 語法。
4. 插入內含連結的圖片
目前發現可以利用連結和圖片自動轉換語法，做出比較有意思的應用，例如：
[[http://therewewere.takol.tw∣ http://therewewere.takol.tw/images/pictures/vacation-travel.jpg]]
不過這種語法目前還有個地方頗奇怪，在"∣"字元後方的圖片網址，必須保留一個空白字元，否則會無法轉換。（此點留作待改善事項）
(上述介紹可參考：編輯內容)
1. 插入圖片
直接輸入圖片網址即可，但圖片網址必須以 http:// 開頭，且以 .jpg .gif .png 等副檔名結尾。
2. 插入內部連結
放大顯示入口標記或地點標記的描述框，可以在標題下方查詢得知該標記的標記代碼。
輸入 [[標記代碼]] 或 [[標記代碼∣顯示文字]]，系統會幫你自動將這種語法轉換成在地圖上移動至該標記的程式語法。
3. 插入外部連結
輸入 [[連結網址]] 或 [[連結網址∣顯示文字]]，系統會幫你自動將這種語法轉換成外部連結的 HTML 語法。
4. 插入內含連結的圖片
目前發現可以利用連結和圖片自動轉換語法，做出比較有意思的應用，例如：
[[http://therewewere.takol.tw∣ http://therewewere.takol.tw/images/pictures/vacation-travel.jpg]]
不過這種語法目前還有個地方頗奇怪，在"∣"字元後方的圖片網址，必須保留一個空白字元，否則會無法轉換。（此點留作待改善事項）
(上述介紹可參考：編輯內容)
2008年10月3日
新增 Google Map 圖示
目前標記可選用的圖示，包括有預設的 PNG 圖示 17 組、Google Earth 內建圖示 176 組，最近又剛新增了 Google Map 內建圖示 91 組，共計 284 個圖示，應該足夠使用了。
未來還會允許使用者上傳圖檔或以外部連結來當作自建圖示。上傳圖檔當然會幫忙縮圖，以防止檔案尺寸過大和駭客藉由圖檔塞入惡意病毒的危險。外部連結可能就不會調整大小，這樣在地圖上看到大大小小的圖片，感覺起來應該也挺有意思的才是。
這次尋找 Google Map 內建圖示，說來有點工人智慧實在很丟臉，竟然是利用反覆設定 MyMaps 圖示來尋找連結位置。花了一番苦心，這組圖示果然比起 Google Earth 的圖示更加美觀且容易辨識。
未來還會允許使用者上傳圖檔或以外部連結來當作自建圖示。上傳圖檔當然會幫忙縮圖，以防止檔案尺寸過大和駭客藉由圖檔塞入惡意病毒的危險。外部連結可能就不會調整大小，這樣在地圖上看到大大小小的圖片，感覺起來應該也挺有意思的才是。
這次尋找 Google Map 內建圖示，說來有點工人智慧實在很丟臉，竟然是利用反覆設定 MyMaps 圖示來尋找連結位置。花了一番苦心，這組圖示果然比起 Google Earth 的圖示更加美觀且容易辨識。
2008年9月30日
Competition
封閉發表後才知道，原來 Google Map 在四月份就已經發表了 MyMaps 的功能。真是一個囧到不行啊，每次都這樣！
在這篇文章裡有介紹，原來類似的服務已經有多家供應商了。先記錄下來，等有空的時候再來好好爬文一番。不過今天稍微試用了一下 Google MyMaps 的服務，幸好他所謂的「意見」只能針對地圖來回應，不能發表在標記上面。呼～這大概是 TWW 和 Google MyMaps 唯一的差異所在了吧。
另外有關照片上傳的部份，PicasaWeb 早就提供了幫照片加上地圖標記的功能，只是我到今天才知道，只要在 Google MyMaps 裡面打開 Picasa網路相簿的 layer，就能夠看到所有在附近標記地點的照片。這個功能也要好好給他來研究一下。
在這篇文章裡有介紹，原來類似的服務已經有多家供應商了。先記錄下來，等有空的時候再來好好爬文一番。不過今天稍微試用了一下 Google MyMaps 的服務，幸好他所謂的「意見」只能針對地圖來回應，不能發表在標記上面。呼～這大概是 TWW 和 Google MyMaps 唯一的差異所在了吧。
另外有關照片上傳的部份，PicasaWeb 早就提供了幫照片加上地圖標記的功能，只是我到今天才知道，只要在 Google MyMaps 裡面打開 Picasa網路相簿的 layer，就能夠看到所有在附近標記地點的照片。這個功能也要好好給他來研究一下。
第一次封閉測試開跑
儘管仍有些功能尚未完竣，但忙碌了三個禮拜，實在不想要繼續漫無目的地等待下去。於是在自己小有人氣的部落格上公開發表文章，徵求「愛旅遊的猴子們」一同來參與封閉測試。
封閉測試的帳號註冊有兩條路徑。第一是經由我設立的〈試驗場〉站台新增成員身分，寄發邀請函後據以註冊。第二是寫信到therewewere@takol.tw 申請註冊帳號，信中註明您慣用的登入帳號即可，我會產生一組隨機密碼給你，請自行登入後修改密碼。
TWW 的帳戶只有登入帳號這一個欄位是不可變動的，其他資訊包括顯示名稱、Email 等都是可以隨時變更設定的，這點究竟好不好，仍有待觀察。不過我覺得 TWW 不是個完全公開社團網站，所以就算個人顯示名稱或站台名稱有重複，應該也沒啥大關係才是。
封閉測試的帳號註冊有兩條路徑。第一是經由我設立的〈試驗場〉站台新增成員身分，寄發邀請函後據以註冊。第二是寫信到therewewere@takol.tw 申請註冊帳號，信中註明您慣用的登入帳號即可，我會產生一組隨機密碼給你，請自行登入後修改密碼。
TWW 的帳戶只有登入帳號這一個欄位是不可變動的，其他資訊包括顯示名稱、Email 等都是可以隨時變更設定的，這點究竟好不好，仍有待觀察。不過我覺得 TWW 不是個完全公開社團網站，所以就算個人顯示名稱或站台名稱有重複，應該也沒啥大關係才是。
2008年9月28日
使用者註冊功能完成
今天處在颱風來襲的平靜當中，一整天除了兒子跑來找我玩耍的交際應酬外，都窩在電腦前面趕工寫 TWW 程式。成果還算不錯，依照原先計畫地將使用者註冊的功能大致上完成了初版。
這次寄發邀請信函的 SMTP server，依舊是借用 Gmail 的服務。與以前幾個網站類似應用的差異點在於，我終於搞清楚了若是利用 Google Application 計畫的 mail account 登入 SMTP，username 須得要填入完整的 email address，而不像利用 Gmail account 來寄信時只填入 username 即可。
在寫註冊認證這段程式時，比較困擾的地方在於一些往返的訊息傳遞，由於得要透過網頁上的 Javascript，所以不能採取我們平常慣用 flash 來顯現。不過繞了個彎，自己想辦法用很醜的方式仍舊解決了需求，只是自己看了就很不酥胡，等以後想要 optimize 系統的時候再說吧。
目前完成的使用者註冊功能包括有：
這次寄發邀請信函的 SMTP server，依舊是借用 Gmail 的服務。與以前幾個網站類似應用的差異點在於，我終於搞清楚了若是利用 Google Application 計畫的 mail account 登入 SMTP，username 須得要填入完整的 email address，而不像利用 Gmail account 來寄信時只填入 username 即可。
在寫註冊認證這段程式時，比較困擾的地方在於一些往返的訊息傳遞，由於得要透過網頁上的 Javascript，所以不能採取我們平常慣用 flash 來顯現。不過繞了個彎，自己想辦法用很醜的方式仍舊解決了需求，只是自己看了就很不酥胡，等以後想要 optimize 系統的時候再說吧。
目前完成的使用者註冊功能包括有：
- 站台內可以新增其他成員身分
- 可以寄出邀請函
- 收到邀請函者，可以點擊郵件內連結開啟註冊頁面
- 註冊時可以選擇 (1) 登入原有帳號 (2) 已經登入者可以直接加入站台 (3) 註冊新帳號
這些功能應該暫時足夠了。接下來要傷腦筋的是測試，可能得要開始找朋友幫忙扮猴子了。
2008年9月25日
模仿 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 網頁服務的幾個要素：
這當中也曾碰到 IE6 相容性測試的問題，為了 PNG transparent 的這個討厭的 issue，害我浪費了好多時間來找最合適的答案。後來索性不理會 ugly PNG under IE6，遵照先前決議，趕緊把主要功能完成，丟出來讓朋友試玩看看大家反應再說。反正意見先驅者多半使用的是 FF/Safari，即便我大膽宣稱 "IE6 Forbidden Here!!" 大概也不會有什麼人持反對意見吧。
目前剩下的主要功能還有建立通訊錄、邀請朋友參加、認證與註冊這幾個曾經在其他專案做過，只要抄過來用就可以完成的模組，預計至遲到這週日，ThereWeWere 應該就可以正式推出 Beta 1 release 了。
這個 Signle form 的版面設計，雖然寬度可以隨著視窗大小自動調整，但高度部份受限於底圖和邊框設計不能自動縮放，使得一些使用大尺寸螢幕的朋友反應意見覺得這樣不妥。思索了片刻，開啟 Google Map 網頁察看他是怎麼一種設計概念，隨後醒悟了所謂 SPA 網頁服務的幾個要素：
- 將服務的主要元素設計成可以隨著視窗尺寸而縮放
- 把你認為最有廣告效果的元素儘量固定在頁面上
- 輔助性資訊可以縮放，不需要佔用寶貴的版面
- 色系簡明扼要，能夠用來分隔不同分類的資訊最好
這當中也曾碰到 IE6 相容性測試的問題，為了 PNG transparent 的這個討厭的 issue，害我浪費了好多時間來找最合適的答案。後來索性不理會 ugly PNG under IE6，遵照先前決議，趕緊把主要功能完成，丟出來讓朋友試玩看看大家反應再說。反正意見先驅者多半使用的是 FF/Safari，即便我大膽宣稱 "IE6 Forbidden Here!!" 大概也不會有什麼人持反對意見吧。
目前剩下的主要功能還有建立通訊錄、邀請朋友參加、認證與註冊這幾個曾經在其他專案做過，只要抄過來用就可以完成的模組，預計至遲到這週日，ThereWeWere 應該就可以正式推出 Beta 1 release 了。
2008年9月20日
完成使用者登入與編輯標記功能
今日的主要開發進度，在於調教地點標記的資料編輯功能。
編輯標記
目前已經提供線上編輯標記的位置、高度、名稱、說明等欄位，也可以選擇要顯示的小圖示。標記的內容編輯完成後，Google Map 會在不重新整理頁面的前提下立即更新地點標記的顯示資訊。
新增標記
可以在目前地圖中心位置新增一個標記，與編輯標記的功能相同，都可以編輯欄位和選擇圖示。
使用者
今日另增加了使用者登入登出等基本權限管理的功能，當使用者登入狀態改變時，不需要重新整理頁面，而是能夠直接改變頁面上各元件的顯示狀態。
搜尋最佳化 SEO
至今需要重新整理頁面，主要是涉及到 entry 的問題。包括網站服務的入口頁、各站台的入口頁、各地點標記的永久連結等三個層次，都是可以利用輸入網址直接跳入目標地。原先在網頁上是不需要顯示各入口頁的主要介紹內容，而是當使用者要求察看時以 AJAX 方式動態擷取說明文字，但考慮到網頁 SEO 的成效，或許會在網頁上，將各入口頁的說明內容以隱藏方式揭露但不顯示。
不過似乎聽說過 Google 對於網頁上不顯示的內容，不會將之列入搜尋關鍵字的範圍!? 這點仍有待查證，無論如何，網頁內容 SEO 仍然會是在服務開始之初就列入考慮的重要因子。
編輯標記
目前已經提供線上編輯標記的位置、高度、名稱、說明等欄位，也可以選擇要顯示的小圖示。標記的內容編輯完成後，Google Map 會在不重新整理頁面的前提下立即更新地點標記的顯示資訊。
新增標記
可以在目前地圖中心位置新增一個標記，與編輯標記的功能相同，都可以編輯欄位和選擇圖示。
使用者
今日另增加了使用者登入登出等基本權限管理的功能，當使用者登入狀態改變時，不需要重新整理頁面，而是能夠直接改變頁面上各元件的顯示狀態。
搜尋最佳化 SEO
至今需要重新整理頁面，主要是涉及到 entry 的問題。包括網站服務的入口頁、各站台的入口頁、各地點標記的永久連結等三個層次，都是可以利用輸入網址直接跳入目標地。原先在網頁上是不需要顯示各入口頁的主要介紹內容，而是當使用者要求察看時以 AJAX 方式動態擷取說明文字，但考慮到網頁 SEO 的成效，或許會在網頁上，將各入口頁的說明內容以隱藏方式揭露但不顯示。
不過似乎聽說過 Google 對於網頁上不顯示的內容，不會將之列入搜尋關鍵字的範圍!? 這點仍有待查證，無論如何，網頁內容 SEO 仍然會是在服務開始之初就列入考慮的重要因子。
2008年9月18日
雛形漸成
今晚將編輯站台和標記的功能完成一個雛形後，基本上 TWW 日後的功能設計已經可以看得到、摸得到了。
大幅利用 AJAX 的方式，讓編輯資訊後的 submit 不用換頁，直接生效變更地圖上的資訊。會決定要如此進行，一方面是為了符合 SPA 的精神，二方面也是實在不敢領教 Google Map 重新載入的龜慢速度。
同時，配合編輯的做法，現在開始所有前端讀取的資訊，全都利用 AJAX 動態取得。好處是編輯資訊完成後不用重整頁面，壞處是平常開啟資訊的速度會相對較慢。
目前影響效能最鉅的是動態載入地圖可見範圍標記的這段 code，應該加上一些防止重複呼叫的 flag 才是。當系統正要載入標記資訊時，又有新 event 發生，必須遮蔽動作，但開啟「再更新」的flag，等待原先載入標記資訊事件完成後，如果有這個「再更新」flag，則得要再做一次。如此可以避免在更新過程當中，因為滑鼠拖動或捲動地圖，導致瞬間湧入十數個甚至數十個可以忽略的事件請求。
今天也修正了 icon 的 model，讓站台和標記物件不單是可以選擇系統預設的圖示，也可以上傳自己圖示，或者選用 Google Earth Icon ( 可以參考 這個網站 )。雖然這部份功能尚未實現，但應該也不難完成。
大幅利用 AJAX 的方式，讓編輯資訊後的 submit 不用換頁，直接生效變更地圖上的資訊。會決定要如此進行，一方面是為了符合 SPA 的精神，二方面也是實在不敢領教 Google Map 重新載入的龜慢速度。
同時，配合編輯的做法，現在開始所有前端讀取的資訊，全都利用 AJAX 動態取得。好處是編輯資訊完成後不用重整頁面，壞處是平常開啟資訊的速度會相對較慢。
目前影響效能最鉅的是動態載入地圖可見範圍標記的這段 code，應該加上一些防止重複呼叫的 flag 才是。當系統正要載入標記資訊時，又有新 event 發生，必須遮蔽動作，但開啟「再更新」的flag，等待原先載入標記資訊事件完成後，如果有這個「再更新」flag，則得要再做一次。如此可以避免在更新過程當中，因為滑鼠拖動或捲動地圖，導致瞬間湧入十數個甚至數十個可以忽略的事件請求。
今天也修正了 icon 的 model，讓站台和標記物件不單是可以選擇系統預設的圖示，也可以上傳自己圖示，或者選用 Google Earth Icon ( 可以參考 這個網站 )。雖然這部份功能尚未實現，但應該也不難完成。
2008年9月17日
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 又是一場大亂，那麼這幾天打謎系統紊亂的情況，可能又得要重演一遍。
從上周開始的第一階段研發，其著重點在於搞清楚 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 又是一場大亂，那麼這幾天打謎系統紊亂的情況，可能又得要重演一遍。
2008年9月13日
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，只是一邊做一邊構思而已。這真不是個開發軟體的好習慣，但卻是最彈性，最方便省思，最容易調整的做法。
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，只是一邊做一邊構思而已。這真不是個開發軟體的好習慣，但卻是最彈性，最方便省思，最容易調整的做法。
2008年9月11日
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，都沒有發生過類似的問題。或許是其他地方出錯所致吧，仍有待檢查和測試來澄清。
開發時的主要測試平台是 Firefox，原因是加掛的 Firebug 實在很方便，尤其這種 AJAX application 有一堆的 DOM 元件，前端網頁上看不到，也很難 trace/debug 資訊，這時候唯有 Firebug 才能協助開發者確認網頁內的 DOM 元件的確依照計畫變動數值，或 bind event handler。
可是，今天猛然發現，似乎有個常用的超連結寫法 <a href="#" onclick="xxx()">xxx</a> 這種東西，竟然在 IE 裡面發生了點狀況，網頁真的會重整網址到同一個 anchor:# 去。怪怪，心想不應當如此，寫了這麼久 IE 底下的 JS，都沒有發生過類似的問題。或許是其他地方出錯所致吧，仍有待檢查和測試來澄清。
2008年9月10日
避免 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 標記外，也要動態檢查刪除地圖以外看不到的標記。
訂閱：
文章 (Atom)