開發 JavaScript 利器 - Prototype

最近為了開發 AJAX 網站，需要找一套支援 AJAX 的程式庫，想到了前一陣子發現的 script.aculo.us 這套 JavaScript 程式庫。script.aculo.us 裡面提供了很多令人讚嘆的 JavaScript 視覺特效，而其是架構在 Prototype 這套 JavaScript 框架上。其實要使用 AJAX 功能，只需要 Prototype 即可。再動手寫幾個測試程式之後，發現 Prototype 實在太好用了，尤其是有 Prototype 的 Swiss Army Knife 之稱的 $() 函式，令人覺得非常神奇。

當然，作為一個 programmer 不能只是感到神奇而罷休，便開始追蹤 Prototype 的程式碼。在追蹤之後才發現，原來 JavaScript 可不是我原本想像的那樣而已，JavaScript 也決不簡單。在 Prototype 原始碼中看到了很多高段的 JavaScript 技巧，不得不佩服作者的巧思，令我獲益良多。如果能看懂 Prototype 原始碼，我敢說你的 JavaScript 功力已經是很不得了了。

Prototype 已經變成我開發網頁的必備良藥之一，改天有空開始再來玩玩 script.aculo.us、Rico 或 YUI 等等其他 JavaSctipt 程式庫。

平安夜的無聊小發現

大家大概知道，從前一陣子開始，Gmail 的容量成長開始加速，預計明年達到 6 GB 以上。剛剛無聊粗略計算了一下，發現 Gmail 的容量在美國時間平安夜當天 (約中午) 會剛好成長到 6000 MB。不知道是不是 Google 故意設計的？ :)

台灣辦公室中常聽到念錯的英文單字

在台灣辦公室中，尤其在科技業的，說話時老喜歡夾雜一些英文單字。對於某些外來的專有名詞，直接唸原文會比較直接，避免誤會。但是對於動詞，除非有特殊情況，我個人認為還是盡量使用中文。習慣一旦養成，要改談何容易，但最起碼發音要正確。如果很愛「ㄌㄠ\」英文卻又發音不正確，不是很糗嗎？對於英文非母語的我們，要發音非常標準是有點強人所難啦，但至少要正確吧。

底下舉幾個常被念錯英文單字 (有些字念錯意思可是差了十萬八千里呢)：

1. file 唸成 fire 。
   例：麻煩你把 fire 傳給我。(不禁讓我想到 Prometheus 普羅米修斯)
   
2. email 唸成 emare (依媚兒)。
   例：給我你的依媚兒。
3. cancel 唸成 cancer。
   例：這個 case 最後被 cancer 了。(怎麼會扯到癌症)
   
4. standard 字尾 dard 應該要發的是 spider 的音，而非 radar 的音。
5. implement 唸成 impriment。
6. exit。

類似 l 與 r 的音不分的情況不勝枚舉，這可能是亞洲國家英文的通病吧。只要把這兩個音分辨清楚，我想英文發音就算是前進一大步了。

註：聲音檔取自 The Free Dictionary

Google's Android SDK Now Available

Google 上星期才公佈了 Open Handset Alliance，今天隨即開放 Android SDK 下載，讓開發者在 Android 上創造手機應用程式。想當然爾，軟體開發平台充分利用到 open source 的資源：Linux 2.6, Java, Eclipse, WebKit, SQLite 等等。同時也使用較寬鬆的 Apache License，讓參與的硬體廠商得以保護其智財。目前公布的 SDK 算是個「搶鮮版」，Google 在廣納開發社群意見後也會不斷地發佈更新版本。

為了刺激全世界的開發者共襄盛舉，Google 更大手筆端出高達千萬美金的獎金，舉辦 Android Developer Challenge。想必此舉一定讓全世界的高手摩拳擦掌，躍躍欲試。第一輪入選的五十名，每位可以得到 $25,000 美金，第二輪則選出二十名，其中十位可得 $100,000 美金，另外十位可得 $275,000 美金。而這應該只是第一階段而已，因為上述獎金只佔總獎金的一半 (五百萬美金)，沒意外的話還會有第二階段的比賽。看到這樣的獎項，真的令人很心動啊！

Android 的介紹：

(看到這段影片第一個反應是：Sergey Brin 的頭髮怎麼了！？)

六福村之旅

星期六是公司舉辦的 Family Day，地點在六福村主題樂園。上一次到六福村已經是六年前的事了，還記得那天是 2001 年的國慶日，所以印象比較深刻。現在六福村對我來說已經沒有多大的吸引力了，我對於人工式的樂園沒多大興趣，也不樂衷刺激的遊樂設施。老實說，去玩那些刺激的遊樂設施，心裡多少會毛毛的。人說越老越怕死，一點都不假。不過相較於男生，女生似乎比較喜歡這種刺激的遊樂設施。不知道是不是不懂的害怕，還是喜歡享受尖叫的快感？這天六福村主題樂園的重點項目「笑傲飛鷹」與「大怒神」因風強所以暫停開放，現場抱怨聲連連，我倒是鬆了一口氣。

以往到六福村總是忽略它還有一個野生動物園 (曾幾何時，野生動物園是六福村的招牌項目)，總認為要玩到遊樂設施才算是值回票價，不過這次的六福村之行有了新的體會。常被忽略的野生動物園，才是這次讓我們覺得值回票價的項目。參觀野生動物園有兩條路線，一個是搭乘蒸汽小火車環繞動物園區，另一個是搭乘猛獸遊園巴士。聽說蒸汽小火車 (當然不是用真的蒸汽火車頭) 是前不久才規劃好的，遊客可以近距離觀賞較溫和的動物。跟台北動物園相比，雖然六福村野生動物園的動物種類不多，但是動物們的活動空間比較大，也比較自由，在這裡的動物應該會比較快樂吧！下次如果有機會到六福村一遊，建議可以去逛逛野生動物園。

PHP vs. Ruby on Rails

因為工作的需要，必須在有限的時間內開發一個網站。這個網站需要具備使用者帳戶管理與認證的功能，並管理使用者上傳的資料，故與資料庫之間的關係密切。我也希望這個網站能盡量運用到 open source 的力量，所以基本的軟體平台將會以 Linux + Apache + MySQL 為主。網站開發工具方面，目前有三個選項：

1. 純 PHP (不使用 PHP framework)
   
2. CakePHP (或其他 PHP framework)
3. Ruby on Rails (RoR)

就我自己以往的 web development 經驗來說，我大多只是利用 PHP 寫一些網頁小工具，最多就是開發規模不大的小網站。對於開發一個中型的網站來說，只使用純 PHP 開發是相當辛苦的，除了人力有限之外，未來還要面臨維護與後續擴充的問題。因此，我需要一個 framework，而現在的問題就是該選擇 PHP 的 framework (目前以 CakePHP 為首選) 或是目前當紅的 Ruby on Rails？對我來說，這兩者各有優劣：(我必須再強調，這是根據我個人情況來說 :)

CakePHP 的優點

1. 我比較熟悉 PHP 語言
2. PHP 豐富的資源 (容易整合許多現有 PHP 的 open source 計畫)
3. 成熟度高，品質已被廣為驗證 (許多之名網站都是用 PHP 打造的)
4. 執行效率快 (相較之下，Ruby is slow!)

Ruby on Rails 的優點

1. Ruby 語言優勢 (如 OO)，以及學習新語言的樂趣。
2. 可能是明日之星 (迅速崛起，目前很火紅的 framework)
3. Rails framework 肇始者 (比較忠於原味？)
4. Ruby 社群團結，只有一個 RoR (相對之下，PHP 選擇太多，容易缺乏向心力)
   

學習新語言固然很有趣，但總是需要時間才可以達到某種深度。雖然 CakePHP 可算是 RoR clone，但並非 clone 就會比較遜色。有時候非但不會比較遜色，反而能夠截長補短。CakePHP 以成熟的 PHP 技術為基礎，廣納 Rails 的設計哲學與精神 (MVC, ActiveRecord, 等等)，應該具備相當的實力才是。Ruby 面臨到的最大問題之一就是效率，效率問題牽扯到的層面很廣，包含根本的基礎語言本身。David Heinemeier Hansson (RoR 之父) 也不穢言，為了解決效率問題，曾經將一段 Ruby 的程式法以 C 改寫。Twitter 可能是目前以 RoR 開發的網站中的最大者，其開發者也為 RoR 效率問題所苦。

以此來看，CakePHP 似乎是比較符合我的需求。

Google's OpenSocial

最近 Google Code 上最大的消息就是 OpenSocial 了。這幾天在 Google 相關的 blog 上都是她的蹤影，例如這裡、這裡還有這裡，另外還有Mr.6 的文章值得一看。OpenSocial 計畫企圖提供一個跨網站的 social network platform ("a set of common APIs for building social applications across the web")，串連當下眾多社群網站，包括： MySpace, Engage.com, Friendster, hi5, Hyves, imeem, LinkedIn, Ning, Oracle, orkut, Plaxo, Salesforce.com, Six Apart, Tianji, Viadeo, XING 等等。

簡單的說，OpenSocial 主要目標有二：

1. 讓使用 OpenSocial API 開發的應用程式 (gadgets/plug-ins, ...) 得以突破社群網站的籓籬，執行在任何社群網站上。
   
2. 只要支援 OpenSocial SPI，任何網站都可以當 host，讓這些豐富的應用程式執行其上。

如果將來 OpenSocial 大行其道， 社群網站之間的幾乎就沒有什麼隔閡了。也就是說，想用某特定社群網站來綁住會員的作法也越來越難了， 未來將會更重視在內容的創意上面。Google 出招果然了得，是否能夠帶來社群網站的美麗新世界呢？

Google Maps API 卡死，CPU 負載飆高

最近為了某種特殊的應用，必須透過 Google Maps API 在 Google Maps 上展現行動軌跡圖。軌跡圖繪製的方式是用 polyline 的方式，連接數百點，甚至數千點。該程式在 IE6 與 Firefox 2.x 皆可正常執行，但是在 Firefox 3 alpha、Opera 或 Safari 等瀏覽器上時，執行到一半便會卡死不動，CPU 負載飆高到 9x%。深入追蹤的結果，發現程式會死在 GMap2.panTo 或 GMap2.setCenter 之類移動地圖的函式，狀似進入無限迴圈。而且在這幾個瀏覽器上執行都是死在同個地方，看起來很像跟座標資料有關，但我實在很難相信事實會是如此。

程式卡死在 Google Maps API 函式裡的情況，看起來不大好搞。上網搜尋一下相關討論，發現也有一些人發生類似的問題，雖然沒有找到什麼明確的解決方案，不過大概可以歸納出問題是出現在處理 polyline (GPolyline) 上。偶然之間，看到有人提到 API 版本不同所引發的其他問題，靈機一動便試著替換不同的 API 版本試看看。最後，我把原來預設的 v=2 換成 v=2.x，便神奇地解決了這個問題。而 v=2 與 v=2.x 有什麼差別呢？根據 Google Maps API 官方文件：

• v=2 (default) 是使用預設的 API 版本。
• v=2.x (latest) 是使用最新的 API 版本，加入新功能與 bugfix，但可能沒有 v=2 來得穩定。
  
• v=2.s (stable) 是使用最穩定的 API 版本，但功能可能比較陽春。

看來 Google 也有發現處理 polyline 上的瑕疵，在 v=2.x 版上解決了這個問題。事實上，Google Maps 在處理 polyline 上並沒有那麼單純。為了能快速繪製 polyline，Google Maps 使用了不少方法輔助，甚至在伺服器端有一些輔助的設計。細節我就沒有研究了，等有空或有需要的時候再說吧！

Google Maps API 的版本有實際的數字代碼，而且更新的速度也很快。目前 v=2 代表 2.91a，v=2.x 為 2.92，而 v=2.s 為 2.73。Google Maps API 並沒有提供取得版本資訊的方法，有興趣的想知道確切版本，可以參考 Mapki 這個網站。如果非得要在程式中動態判斷版本，底下這一段 PHP 程式碼可以提供給你參考：

function get_gmaps_api_version($url) {
  if (preg_match('/mapfiles\/([\d\w]+)\/maps2/',
                 file_get_contents($url), $m))
      return "2." . $m[1];
  return "N/A";
}

其中輸入的 $url 是 script URL：

• v=2 → http://maps.google.com/maps?file=api&v=2
  
• v=2.x → http://maps.google.com/maps?file=api&v=2.x
  
• v=2.s → http://maps.google.com/maps?file=api&v=2.s