集中/聚眾/集眾開發

一直從事軟體開發工作, 其中不論參與產業, 各類技術, 團隊規模, 時間長短, 雖有各有不同, 皆是解決客戶問題為主, 也都是專案的型態 … 而專案執行方式也各有不同, 從古早到近年流行的, 或多或少都參與過。總的來說, 都是由外而內的驅使著開發者, 必須針對客戶的需求做處理, 做回應。

從剛開始是廠商, 標準, 或方法的傳聲筒, 到現在能夠提出各式各樣的嘴砲意見。這是 … 馬齒徒長!!??

由外而內的改變, 雖然邊拉距邊有進展, 但聽說真正的成長是由內而外。因此, 開始思考在執行專案時, 發生衝突到最後調和的事件。嗯, 這篇不是談技術, 因為技術最好的歸宿就是被消滅; 也不是談業務, 因世代更迭的業務, 總是來來去去。目標是整理一下開發大環境的差別, 及相關的影響。最後歸納為, 開發者正經歷集中開發(Central), 聚眾開發(Clustered), 與集眾開發(Crowded)的不同世代。

把紅點視為一開發單位, 紅點散落位置區分了不同的方式:

• 集中開發: 紅點集中在一起, 為共同目標而努力。
• 聚眾開發: 紅點聚落各有長處, 分工聚落各有發揮, 但聚落合作才能完成目標。
• 集眾開發: 當群體進展到某個程度, 個別單位縱使降低對資源的要求, 還是能達成目標。

從硬體, 軟體, Java 舉例來說:

• 硬體: 古早到現在 IBM 的角色, 毋庸置疑; 台灣著名的就是電腦組件聚落; 蘋果則近年來讓電腦取代寵物的地位方面功績卓著。
• 軟體: Oracle 專長打造資料的家; MS 建立的聚落嚴有許多 … 作業系統, 企業應用, 遊戲; SF 雖然漸漸被取代, 但卻是讓大眾發表分享源碼, 方便交流的起點。
• Java: Sun 早先前集中資源打造出跨世紀的 JVM, JDK; Apache 以 Web, Services 甚至雲端著名, 近來常做撫養托孤業務; Hadoop 是 Apache 其中一個聚落, 但更能表現集眾開發, 為此獨立出來。

先看 Apache 與 Sourceforge, A 和 S 都是開放源碼的重鎮, 但 A 是會員制, S 則隨開隨用。Apache 能到頂層(top level)的專案, 幾乎都可視為一個聚落, 聚集著對專案有興趣的公司或個人。開始先在論壇, 事例追蹤上參與, 被認同後才賦予擔負工作的身份。A 要去瞭解, 要去參與, 而 S 只要名稱不同, 很快就能開個專案, 我還是我。在早期 S 能聚集的是本身具備吸引力的專案, A 透過組織方式更能推動發展。

發展到一個階段, 開發不只著重開發者的角色。以社群類處理的使用者數量來說, 是早先集中式商業公司嘗試以高規格軟硬解決而失敗的題目。流行的方式是將問題分解, 個別強化, 捨棄不需要的部份, 組合成因應需求的系統。例如, 連線數量(MINA), 訊息處理(Camel), 計算能力(Hadoop), 資料存取(Cassandra), 內容管理(Jackrabbit), … 全部都可以分解, 組合, 不需要一個全能的應用伺服器(Application Server)。

更重要的是, 個別專案都經過不斷使用的驗證, 也持續被使用。例如: A 賣場, F 聯誼社, G 廣告商參與的 Hadoop, Cassandra, … 要集中資源或指定聚落開發類似的功能, 都難以負荷。但從滿足大眾市場, 回頭灌溉成的專案, 就能因此受惠。

所以集眾開發必須加上, 個別經營大眾的觀點:

在以上前題成立的狀況, 個別開發也成為可能:

回頭看過去執行專案使用新技術, 會不斷被勸阻, 因為總是增加風險。但最後化險為夷, 是這些新技術總是進展到一個難以預估的地步, 不論是功能或穩定方面, 這些都不是古早開源專案可以想像的。唔, 大約十年前。最後的結果 … 除了組員肯定, 也被客戶讚許(多次廠商競賽, 都協助客戶拔得頭籌) :-)

那些都是隨波逐流的好處, 卻也可能遇到 … 使用協力的專案被腰斬, 功能不如預期, 整合障礙, …。竊認為是技術問題, 調和正正負負的項次, 就不在這裡細細討論。

最後記下一個開放問題: Scrum 方法用在何種開發情境(集中, 聚眾, 集眾)合宜?

OFBiz Go

App 很紅, 主要在行動設備上, 上下游都很火紅。要談的 App 是現在不太紅的 Ent App (Enterprise Applications), 或是說已經紅過了, 但仍然是每個公司, 組織都會用到的。

App 多是產品, 而 Ent App 是種社會(Social), 俗名是江湖, 充滿交流與妥協, 大多以專案形式進行。就算從產品開始, 後面也會帶專案, 常見區分出軟體, 硬體, 開發, 維護, … 各個階段。

由於 Ent App 牽涉層面通常既廣又深, 以技術角度來看, 擴散方式(銷售, 安裝)一直沒太大改變。現在雖然服務導向, 雲端喊得震天嘎響, 但除了網路基礎服務(信件,檔案), Web應用或特殊應用, 要把 Ent App 放上去, 應該還有些東西要準備好。用雲端的榜樣電與水比擬, 水除了自來水, 還有各式來源; 電除了公共設施, 也有可移動型的, 或私人備援。因此資料的移動能力要具備, 否則還是有些不足。

開放源碼讓技術普及, 加上硬體設備的大幅提升, 過去得詳加規劃, 才能執行的 Ent App, 現在只要在雲端或筆電開個 VM (虛擬機器) 就行開工。再者, 小公司不需要 24 小時運轉的系統, 功能有的話, 需要時再開啟。甚至中型單位, 只要合宜的環境及配套規劃, 也能朝這方面努力。

首先, 要面對的問題是 … 怎麼去開始?

在 OFBiz 下載頁面中, 寫明只要有 JDK(Java 1.6 SDK), 下載 zip 後解開壓縮檔, 執行指令就可以開始。

似乎還算容易?

但每個平台準備 JDK 其實都不太一樣, 更不用說如果發生衝突的話要怎麼辦, 例如在 Linux 上用 OpenJDK。這些說明字句雖少, 看起來簡單, 毫無疑問是寫給工程人員看的。再加上 Ent App 的社會屬性是有機成長, 如果要修改, 要調整, 按照慣例就得靠自學, 或找人助拳。

以整個過程來看, 愈到後面, 障礙愈高, 的確是不太容易推動。

之前在一種應用源碼管理的實作討論過 可短小, 可長久, 可分享 的客製化方式。路雖然通了一小段, 但想想, 比原來 OFBiz 官方的安裝方式還要複雜, 素人要開始, 會有不小的障礙。

因此做了 OFBiz Go 用一個步驟完成 所有 繁瑣的準備工作。

準備工作有:

1. 下載必須的 JDK, Python, Subversion, Mercurial 以及相關工具(patch, diff, cURL, 或 Wget), Windows 要再加 MinGW。
2. 安裝妥上面這些東西, 做好設定 … 例如系統變數, Mercurial 的設定, 與 virtualenv 的環境。

當然如果機器上已經有的軟體項目, 就略過不下載, 也不安裝。

寫上一篇的時候, 略過這些步驟。對熟悉這些工具的人, 早就備妥; 但不熟悉的人, 繁瑣且容易漏東漏西的過程, 反而造成困擾。即使自己做, 將這些裝到 Linux, 也碰上不少問題。

想做個 VM 來用, 但每次要把數 GB 的東西搬來搬去, 還得搬進雲裡頭, 舉重若輕恐怕也不太容易辦到。

在支援 Windows 前提下, 也考慮 Puppet, Chef, 或老牌 CFEngine 這類 組態管理 工具。但即便輕如 CFEngine 都必須做額外的安裝設定, 所以這工具還是留給 應用系統, 做為其中的組件。

剩下可用的大概就是系統腳本語言(Shell Script)。

OFBiz Go 是先在 OS X 上寫個 .sh 做完上述工作。然後找到 Windows 2008 用 Powershell 寫個 .ps1。最後用 VMWare 開啟 Ubuntu 11.10, 原本認為 OS X 小改就可以用, 但還是改了不少。

比較特別是 Powershell 挺有 Power 的 … 要正確合法下載 JDK, 需使用者同意。Powershell 可控制 IE 瀏覽器帶出正確下載網頁, 當使用者點選同意後, 繼續腳本的工作。

目前在 OS X 10.6, Windows 2008R2 / 7, 還有 Ubuntu 11.10 測試過。OS X 可能會不太行, 因為環境不乾淨。;-)

只要腳本的下載, 安裝, 驗證的工作做完, 就可和 應用程式源碼溝通。把繁瑣的過程, 劃分成兩個階段, 方便入門者, 也方便自己。

由於大部份工具和 Python 相關(Fabric, MQ), 下週三(2011/12/21) 晚上 19:30 在新竹的 PyHUG 會描述 配置方式 與 應用客製 兩階段的安排, 及運作細節。除了 Ent App, 很多類似的狀況, 也可用相同方式處理。歡迎參加, 和我們一起討論。