其實這個主題不純然是Javascript，瀏覽器也是一個重要角色。這樣的分散應用是很鬆散的啦...不過在解決一些問題上還是很有用的。
用瀏覽器做分散運算？
之前在找Map-Reduce相關的資料時，看到了這篇文章：

http://www.igvita.com/2009/03/03/collaborative-map-reduce-in-the-browser/

一般在做Map-Reduce時，會把資料Map到許多機器做平行處理來加快運算，這樣的架構通常是在遠端配合特定的伺服器與網路設備來處理運算。作者的想法是把資料Map到使用者的瀏覽器，利用Javascript做運算，然後再丟回伺服器做Reduce。除了提出這樣的概念，作者也寫了簡單的Ruby程式碼做概念驗證。

不過如果是比較time critical的運算（像google在做的搜尋運算），我想也很難依賴這樣難掌握的運算資源來運作吧？當時是這樣想的。這篇文章在網路上引起廣大的迴響，當然質疑很多...作者根據這些迴響又寫了一篇文章：

http://www.igvita.com/2009/03/07/collaborative-swarm-computing-notes/

檢視了幾種運作方法的可能性，作者思考了一下：「我可以大膽的說，這是Swarm Computing嗎？」（關於swarm的概念，可以參考http://en.wikipedia.org/wiki/Swarm_intelligence，但是我覺得這通常是指一群非專用的client可以自由進入參與運算的機制，只要越多人參與運算，系統就可以獲得更多資源來提高運算速度）

分散式測試實作
沒想到沒隔多久，John Resig宣稱他在進行的testswarm計畫開始公測。雖然也叫做swarm，但是Resig用這個方法是為了要解決傳統測試無法解決的問題：http://ejohn.org/blog/javascript-testing-does-not-scale/。

他提出的問題點是：跨瀏覽器的Javascript開發與測試是「無法延展」的，這需要從開發流程說起。以jQuery為例子，他為了包含各種狀況大概建立了十個TestSuite，這些TestSuite通常都會透過test runner頁面在瀏覽器來執行。開發者在異動commit前後都必須跑完所有測試套件來測試是否有錯誤以及是否解決了問題，這時問題就來了。他們有方法做自動化的測試，但是如果要求在各家OS、各家瀏覽器的各個版本上面都跑一遍測試，這樣測試的工程就...非常巨大，很難靠一台機器一個人完成。OS種類 x 瀏覽器種類 x 瀏覽器版本的數量就夠大了，還要可以應付新出現的瀏覽器及版本...但是不這樣進行測試的話又無法保證瀏覽器的相容性。

他提出的解決方式是把測試套件、測試OS/瀏覽器與版本等depencency移到外部，透過一個叫做testswarm的測試系統做整合。實際測試是靠參與者使用瀏覽器進入testswarm系統來做的，而且只要進入系統之後，它就可以指派任何測試工作給參與者的瀏覽器執行。透過這樣的系統與分工，就可以把測試套件與瀏覽器/系統的的依賴性解耦。而且只要越多人進入系統，系統做測試的速度就越快。

http://testswarm.com/

testswarm的程式碼可以從github上面取得，主要是用php與javascript開發出來的，並且有一些perl的程式範例可以修改來從SCM系統取得修改的程式來新增測試工作。目前程式還頗陽春，我下載安裝的時候，還需要稍微修改程式。另外，為了可以偵測各個test runner的執行結果，還需要調整test suite中的程式，加入/js/inject.js來取得測試的狀態。在testswarm.com上面跑的測試看起來很順暢，不過我拿最新版的jsunit來測試還是發現有些問題，主要是jsunit的test runner預設他自己的程式是放在window.top，但是testswarm需要把他放進一個iframe來跑...這樣test runner就無法正確執行。

不過如果這些程式成熟穩定後，testswarm.com應該有機會成為不錯的服務，每個人都可以進去提供自己的瀏覽器資源來幫助別人做測試，自己的test suite也可丟上去測試，取得非常廣大的測試資源，其中包涵了幾乎所有的作業系統與瀏覽器版本。另外在商業模式上，也可以考慮多放一些社交功能，類似github。其實它目前是有一個測試執行排行榜的區塊，不過這樣看起來還是頗陽春的...不知道有沒有更多的好方法來吸引人群來參與testswarm？

持續整合與testswarm的展望
testswarm雖說目標是一個支援持續整合的測試工具，不過目前的支援不算很完整，但是它至少把洞很大一塊補好了。先從持續整合的流程來看，與testswarm結合的話我想會像這樣：

1. 開發者上傳異動後的程式到 SCM
2. 持續整合伺服器從 SCM 取回異動後的程式
3. 持續整合伺服器啟動測試 - 向testswarm註冊新的測試工作
4. 持續整合伺服器從testswarm取回測試結果
5. 持續整合伺服器將測試結果通知相關開發者

與testswarm相關的流程大概在3,4這兩個部份，2,3這兩個部份，需要手寫script完成，testswarm沒有提供直接的程式支援（沒有提供API讓這部份的工作可以透過程式自動化執行）。在3的部份，似乎還沒有一個與測試系統以及平台無關的測試報告產出，讓持續整合伺服器可以繼續之後的流程。

總之，testswarm還需要加把勁，不過以一個swarm來說，這算是非常實際的應用了。有空可以去瞧瞧，看他在瀏覽器裡面執行測試還蠻有趣的。