Category: 軟體新知


Outlook Duplicate Items Remover – http://www.vaita.com/ODIR.asp

Install this if you sync outlook contact & calendar to PDA.

廣告

This is good intro in Chinese about XP programming. Finally there’s more talk in Taiwan about iton a major IT publication.

If you interested in xp, also check out my older post. You should also know about Aglie Programming.
文/李延華 (記者) 2007-09-02

極限編程:訴求擁抱改變、注重溝通與測試,適合小團隊開發的敏捷開發方法論
在軟體開發領域談到「XP」,可不是指Windows XP,而是eXtreme Programming(極限編程)。

落實XP方法論的第一步,是拿起扳手與螺絲起子,拆除辦公室的隔板。因為XP強調的4個價值觀──溝通(Communication)、簡單(Simplicity)、回饋(Feedback)與勇氣(Courage),重點就是希望建立暢通而有效率的溝通管道。

另有12項實務,包括客戶駐廠(On-Site Customer)、系統隱喻(System Metaphor)、程式共享(Collective Ownership)、重構(Refactoring)、搭檔編程(Pair Programming)、編程標準(Coding Standards)簡單設計(Simple Design)、測試先行(Test Before Coding)、通盤規畫(The Planing Game)、小型改版(Small Release)、持續整合(Continuous Integration)、四十工時(Forty-Hour Week)等。

XP的簡單設計與靈活因應需求改變的主張,吸引所有人的目光,不過,我們不能忽略測試驅動(Test Driven)這個重要的原則。「測試」在XP中是必要的條件。

由於需求是不斷改變的,所以XP建議擁抱改變。而測試案例的目的,就是為了因應改變,而建置健全的測試案例將使專案無懼改變。

此外,不是所有的專案都適合XP,它適合2~12人的開發團隊,特別是應用在需求經常改變的領域。管理者、客戶及開發人員對XP而言,都是專案的成員,必須透過充分的溝通與回饋,才能讓每個成員都了解目前的版本能否滿足需求。文⊙李延華

Iteration 往覆式開發方法
早期的開發方式通常是瀑布式(Waterfall),從分析、設計、實作、測試到交付,是一路到底、不可逆的過程,然而這種方法在軟體業卻存有很大的風險。

由於客戶的需求經常改變,而且開發者憑自己的想像所開發的系統,也未必符合客戶的期望,因此許多方法論改採往覆式開發,每次設計、實作、測試與交付都採最小規模的方式。若不符客戶需求的設計,便可即早發現,進而修正。

Feedback 回饋
回饋與往覆是息息相關、互為因果的事件。在XP中,客戶與開發團隊之間的互動決定專案的成敗,客戶的回饋能提供專案後續發展的寶貴訊息。

在12項實務中,「客戶駐廠」也是呼應「回饋」的做法,而這個價值觀點出在XP方法論中客戶對專案的重要性。因為藉由客戶即時的回饋,開發團隊可以盡早了解問題與風險所在,即時修正不符合客戶預期的設計,朝正確的方向發展。

Simplicity 簡單
以瀑布式的開發方式為例,在實作系統之前,必須先做好完整的需求分析與系統設計。而且技術人員為了讓系統保持最大的彈性,往往在架構上預留擴充的空間。

但是XP方法論認為,客戶的需求隨時在改變,而且環境與技術也不斷地更新,所以預留彈性反而是增加包袱,因此建議開發者盡可能保持符合需求的最簡單版本,不要預想未來可能的功能,以控制成本、降低風險。

System Metaphor 系統隱喻
在XP中,每個人同時扮演系統分析師、系統設計師和程式開發者的角色,藉由客戶駐點,面對面溝通的方式,取得第一手的需求,然後直接做給客戶看。

為確保彼此的溝通沒有誤解,因此必須善用隱喻,讓客戶與開發者有共通的語言,利用說故事和打比方的方式,取代冗長而難以理解的文件。比喻的用語可以與IT無關,盡量以易於了解的方式,表達需要的功能。

Pair Programming 搭檔編程
兩個人共同開發一隻程式,一個人在寫程式的時候,另一個人需負責看程式,以檢查是否有出錯或可改進的部分,而且兩人要經常互換角色。

不過,搭檔編程通常是XP各項實務中最難被主管接受的一項,因為從成本與效率的觀點出發,大家各寫各的程式,將有兩倍的工作效率。再加上,管理者不容易確保看程式的人工作的品質,無法得知他是在發呆還是認真檢視程式碼。

Collective Ownership 程式共享
搭檔編程還有進階應用,就是搭檔關係也要經常替換(Switch Pair)。當使用者提出新的需求時,開發者就會被分配與新的對象合作,一起修改其他人合作開發的部分,並加入新的功能。

團隊的每個成員都有機會轉換與不同的對象搭檔,合作開發系統的各個部分,所以所有人也就都有能力修改與維護系統的每個部分,這樣的做法即是「程式共享」。

Continuous Integration 持續整合
在開發期間,當一組搭檔共同完成一個使用案例(User Story),並通過單元測試過後,便可以將程式簽入集中管理的版本控管系統,重新建構一次系統,並諮詢其他搭檔,執行所有測試。採用XP方法論一天內可能建構系統好幾次。

系統整合與測試之後,經由測試執行結果,可以讓開發團隊與駐點的客戶了解系統現階段確實可執行的功能是否符合需求,並掌握開發的進度。

Small Release 小型改版
依照XP的方法論,通常開發團隊是依據Story Card切割工作。每完成一個Story Card,就發行最新、可執行的版本,交由客戶驗收。此即XP所謂的「小型改版」。

客戶如果頻繁地檢視最新版的系統,便可確認專案是否符合期望,然後回饋意見作為開發團隊持續改進的參考。依照XP的要求,開發團隊至少每3周就要重新整合新功能到產品中,發行新版本,交由客戶驗收,並檢視未完成的需求。

Refactoring 重構
重構的意思,是指在不改變程式碼的外部行為的情況之下,修改程式碼,以改善內部的一致性和清晰性。根據XP的方法論,在每個小階段發行以及每個往覆式的周期之後,甚至是每天下班前,都可以執行一次重構。

重構通常是透過開發工具輔助執行,一般不會影響程式執行的結果,但為了確保重構之後,不會改變程式碼的行為及影響功能的正確性,開發團隊必須齊備完善的測試機制。

PDF download: Subversion for Windows 安装指南

this post is an updated version from Huanlin Tsai’s revision 1.41 (http://huanlin.dyndns.org:8080/techshare/articles/2004061303/svn_install.htm)

摘要: 版本控制在軟體工程的領域中隸屬於軟體建構管理(Configuration Management)的範疇,是軟體開發流程當中相當基本且重要的一環,因此版本控制系統可說是開發人員必備的工具之一。本文將介紹一個開放原始碼的版本控制系統:Subversion,說明相關工具的安裝步驟,並且透過實例操作示範如何在Visual Studio .NET 2003裡面對專案進行版本管理。

Subversion 是一個自由/開放源碼的版本控制系統,也就是說 Subversion 管理著隨時間改變的檔案,這些檔案放置在一個中央檔案庫(repository) 中,這個檔案庫,很像一個尋常的檔案伺服器,不過它會記住每一次檔案的變動。這樣你就可以把檔案回復到舊的版本,或是瀏覽檔案的變動歷程,許多人會把版本控制系統想像成某種“時光機器”。

本文目的:

  • 在 Windows 2003 Server 上安裝及設定 Subversion,以便於團隊成員透過 Internet 協同開發軟體專案,並有版本控管功能。
  • 在用戶端安裝 Subversion 的 Client-side 工具:TortoiseSVN,可以整合與檔案總管整合在一起,利用 GUI 方式提供了建立檔案庫、以及匯入、匯出等功能。

本文提供一個簡易的安裝指南,說明在 Windows 環境下安裝 Subversion 伺服器的步驟,以及 TortoiseSVN 用戶端工具的安裝步驟。

1. 簡介

Subversion 是一個版本控制系統,它是根據 CVS(Concurrent Versions System)的功能為基礎來設計,但是改進了一些 CVS 的缺點,例如:在CVS中搬移檔案目錄很不方便,Subverion 則連目錄的異動都納入版本管理;此外,它也增加了其他的功能,例如:不可分割的送交(如同資料庫交易的概念,送交多個檔案時,若有任何一個檔案失敗,則這次送交的所有檔案都不會進入檔案庫中)、支援多種網路協定、一致的檔案差異比對(不管什麼檔案類型,均使用二進位差異比對方式)等等。

由於目前手邊查到的 Subversion 文件,主要都是針對 Unix用戶來撰寫,所以這份文件特地針對 Windows環境下安裝 Subversion 的步驟來說明,希望透過這份文件,能夠幫助你很快的把Subversion安裝起來。

在安裝過程中,會需要輸入一些命令列的指令,本文不會詳細解釋某些指令的用途和意義,因此你除了要熟悉 DOS 的基本指令,還應該隨時查閱 Subversion 的電子書(有中文版),以了解 Subverion 命令列工具的使用方法。圖形化介面雖然方便,但是熟悉命令列工具的使用,才能讓你得到完全的自由。

1.1 基本觀念

如果你缺乏版本控制系統的基本觀念,就算能夠順利安裝好 Subversion,可能安裝完成後就不知道下一步怎麼做了。這裡只簡單的提一點必要的基礎觀念,記住你最終還是得閱讀 Subversion 的官方文件。

1.2 作業環境與軟體版本

以下是本文件使用的作業環境與軟體版本

  • Windows 2003 Server with SP1
  • Apache HTTP Server v2.0.55
  • Subversion v1.2.3
  • TortoiseSVN 1.2.6 build 4786

2. 安裝與建立 Subversion 伺服器

請準備一台穩定的機器,作為 Subversion 的伺服器。

2.1 安裝 Apache HTTP Server

http://httpd.apache.org/ 下載 Apache HTTP Server 2.0 版 for Windows 的安裝程式,我下載的檔案是 apache_2.0.50-win32-x86-no_ssl.msi。

下載之後直接安裝,安裝過程很簡單,就不贅述了,但安裝之前請先檢查你的電腦是否有安裝 IIS,由於 Apache 預設使用 80 port,會跟 IIS 的網站衝突,你必須把 IIS 的 Web 站台關閉,再安裝 Apache HTTP Server。

安裝完成以後,開啟瀏覽器,瀏覽網址 http://localhost/ 看看有沒有出現安裝成功的網頁。

2.2 安裝 Subversion

1. http://subversion.tigris.org/下載最新版的 Subversion,你可以下載 .zip 或者打包好的自動安裝程式,我下載的是檔案svn-1.2.3-setup.exe。

2. 下載後直接安裝,安裝過程都是下一步,沒什麼特別的。在此Windows安裝版增加了Apache modules的選項,必要的環境變數都幫你設定好了。

2.2.1 手動安裝Apache modules

以下步驟敘述手動安裝Apache modules的程序(如果你下載的是 .zip 檔,就要自行設定)。

  1. 把 $SVN_Install/bin/目錄下的 mod_dav_svn.so、 mod_authz_svn.so複製到 $Apache2_Install/modules/目錄下。
  2. 把 $SVN_Install/bin/目錄下所有的dll檔複製到 $Apache2_Install/bin/。
  3. 接著用文書編輯器開啟 Apache HTTP Server 的 httpd.conf(在 /conf/ 目錄下),尋找一堆 LoadModule 指令,先找到以下兩行:
    #LoadModule dav_module modules/mod_dav.so #LoadModule
    dav_fs_module modules/mod_dav_fs.so 把前面dav_svn_module的 ‘#’ 字元刪除,然後把下面幾行文字加到這群 LoadModule
    指令的後面: LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule authz_svn_module
    modules/mod_authz_svn.so
  4. 重新啟動 Apache HTTP Server。
    問題排除: 如果 Apache HTTP Server 無法啟動,請依下列步驟檢查:
    1. 檢查 Subversion 的路徑是否有在系統的%PATH% 環境變數裡面。
    2. 檢查你加入 httpd.conf 裡的項目是否正確,記住 mod_dav_svn.so 和 mod_authz_svn.so必須在其他 mod_dav*.so 模組之後載入。
    3. 檢查你加入的檔案。若dll檔沒有在正確位置,將無法正常啟動。

2.3 設定 Subversion 檔案庫的路徑

現在要設定Apache http.config檔中 SVN URL 路徑與檔案庫實體路徑的對應關係。對應的方式有兩種,分別是 SVNPath 與 SVNParentPath。

2.3.1 SVNPath

SVNPath 適合用來個別指定檔案庫的路徑,語法是:

DAV svn SVNPath /absolute/path/to/repository

其中 “/svn/repos_name" 就是用戶端存取特定檔案庫的 URI(Uniform Resource Indentifier),SVNPath 後面指定的路徑則是檔案庫的絕對路徑,假設我們的檔案庫實際存放的路徑是 d:\svn\MyProject,並且希望用戶端使用 http://myserver/svn/myprj 的 URL 來存取檔案庫,那麼要加入 httpd.conf 的內容就是:

DAV svn SVNPath d:\svn\MyProject

注意 Location 標籤後面的 /svn/myprj 的第一個斜線不可少!

2.3.2 SVNParentPath

如果你的檔案庫都集中放在某個目錄之下,例如:d:\svn,那你就可以使用 SVNParentPath 的方式指定檔案庫的根路徑,例如:

DAV svn SVNParentPath d:\svn

這表示可以讓任何人都可以透過 http://myserver/svn/ 的方式,存取位於 d:\svn 這個目錄以下的所有檔案庫。也就是說,這個設定動作只需要一次,如果使用SVNPath,你必須為各個檔案庫分別指定對應的路徑。

以上兩種設定方式都可以,方便起見,這裡我用 SVNParentPath 來統一指定所有檔案庫的父層 URL 路徑。

將 的設定加到 Apache HTTP Server 的 httpd.conf 檔尾就行了。接著便可以開始建立檔案庫。

2.4 建立Subversion檔案庫

假設我們要把所有的檔案庫都放在 d:\svn 目錄下,現在要建立一個測試用的檔案庫,名稱叫做 repository,指令為:

md d:\svn svnadmin create d:\svn\repository

命令執行完後,檢查看看 d:\svn\repository 目錄底下產生了哪些目錄和檔案。

警告:檔案庫絕對不可以在建立在任何遠端的儲存媒體上,例如:網路磁碟機。

這時候你已經建立了一個檔案庫,你可以先在本機用瀏覽器測試一下,網址輸入http://localhost/svn/repository,看看能不能看到檔案庫的內容,正常的話應該像下圖一樣。

如果以上的測試可以通過,應該就行了。如果你還想要測試一下能不能從檔案庫取出整個工作複本,可以執行下列指令(非必要):

c: cd\temp svn co http://localhost/svn WholeRepos

上述指令會切換到一個暫時的目錄 c:\temp,然後從檔案庫取出整個工作複本。最後一行指令是要 svn.exe 執行 check out 動作(縮寫 co),如果正確的話,應該會顯示 “Checked out revision 0." 的訊息,此時 /svn/
這個檔案庫底下的所有檔案目錄都已經取出,並且複製一份到c:\temp\WholeRepos 目錄下了。

問題排除 : 如果顯示的錯誤訊息是:svn: PROPFIND request failed on ‘/svn/repository’

svn: PROPFIND of ‘/svn/repository’: 405 Method Not Allowed (http://localhost)

請檢查 Apache HTTP Server 的 httpd.conf 檔案裡面的 標籤所定義的位置是否跟你指定的URL
樣式相同,注意一定要完全相同,以上面的例子而言,你的 httpd.conf 的最後面應該會有以下文字:

DAV svn SVNPath 指向檔案庫的絕對路徑

如果顯示的錯誤訊息是: svn: PROPFIND request failed on ‘/svn svn: Could not open the requested SVN filesystem

那表示在 /svn 對應的實體目錄(即 d:/svn)下找不到所指定的目錄。

註:PROPFIND 是給 WebDAV 用的 HTTP method,用來從資源中取得屬性。

測試完畢就可以把 WholeRepos 這個目錄整個刪掉了。

到目前為止,可以確定檔案庫已經建立完成,接下來就可以匯入專案了。

2.4.1 匯入專案

不用急著把你現有的正式專案匯入檔案庫,先建立一個用來測試的專案目錄就好了。我們先在 c:/temp 底下建一個 ProjectA 的專案目錄結構,參考下面的指令:

c:\
md temp
cd\temp
md ProjectA
md ProjectA\trunk
md ProjectA\branches
md ProjectA\tags
svn import . http://localhost/svn
-m “Initial repository layout"

提示: 本文在執行 svn 命令時,都是使用 http 協定的方式,這樣我們可以確知 Subversion 與 Apache HTTP Server 的設定無誤,其他人就可以透過 Internet 存取檔案庫。當然你也可以用其他的協定,例如:file:///,如果使用 file 協定,最後一行指令就變成:

svn import . file:///d:/svn -m “Initial repository layout"

命令執行無誤的話,應會看到如下的畫面:

這時候 ProjectA 這個專案已經匯入檔案庫了,也就是說,其他使用者可以開始存取這個檔案庫的專案取出文件和程式碼了。你可以參考 Subversion 的官方手冊中關於 svn.exe 這個用戶端命令列工具的使用方法,多練習一下取出檔案、加入檔案、以及存入檔案等指令。萬一練習的過程中發生錯誤,或者檔案庫弄亂了,你可以把整個檔案庫的目錄砍掉,回到 2.4 節重新做一遍。

以下會進一步討論檔案庫和專案目錄結構的安排方式,如果你急著想試試看用戶端如何存取 Subversion 檔案庫,可以先跳到2.6 節或第 3 節。

2.5 檔案庫與專案的配置方式

延續前面的範例,如果你再匯入其他專案,例如 ProjectB,那麼整個檔案庫的結構會變成這樣:

/svn/repository/ +– ProjectA/ +– ProjectB/

也就是說 repository 這個檔案庫裡面包含了兩個專案。

如果你希望為每個專案建立一個檔案庫,那麼在 2.4 節中建立檔案庫的指令就變成:

md d:\svn svnadmin create d:\svn\ProjectA
svnadmin create d:\svn\ProjectB

這樣就變成有兩個檔案庫了,檔案庫名稱分別是 ProjectA 與 ProjectB。

提示 : 如果專案之間有共享的檔案,建議把這些相關的專案放進同一個檔案庫;如果專案之間彼此毫無關係,那就採用一個檔案庫放一個專案的方式,這種方式等於專案就是檔案庫。

第一種方式有個比較奇怪的「功能」你應該要知道,就是一個專案的 check in 動作,也會令其他專案的檔案的修訂版次遞增 ,如果這不是你想要的,請選擇第二種方式,即一個檔案庫只存放一個專案。

2.5.1 專案的目錄結構

這裡補充說明一下 ProjectA 的目錄結構。在 ProjectA 專案的根目錄下建立的 trunk、branches、和 tags 這三個目錄是有特別意義的,它們的作用分別是:

  • trunk 目錄用來存份目前專案正在進行開發的程式檔案和文件 (又稱為主線,即 mainline)
  • branches 用來存放主線的各個仍在發展中的分支;
  • tags 則用來存放已經不再變動的分支,也就是其中的檔案不會再修改了。

這是 Subverion 官方手冊建議的目錄結構安排方式,你可以自己決定要不要用這種配置方式,詳細說明請參考官方手冊的第五章,子標題為 “Choosing a Repository Layout"。

提示 : 目錄名稱建議盡量不要用中文名稱,這樣在使用命令列時比較方便,也比較不會有問題。

2.6 使用 Windows 網域帳戶驗證

照著前面的步驟做,你會發現存取檔案庫時都不用輸入帳號密碼,這是因為我們之前的設定沒有啟用身分驗證的功能。但是我們通常不希望所有人都能任意存取你的檔案庫,免得重要資產外洩,或者資料被破壞,因此了解如何加入身分驗證也是必要的。

Serversion 提供了多種驗證使用者身份的方式,這裡只介紹 Windows 身分驗證的方式,這種方式很適合用在開發團隊成員都在區域網路內的情況。請依下列步驟進行:

  1. 取得 SSPI 模組,下載網址為 http://tortoisesvn.tigris.org/mod_auth_sspi.zip
    英文說明在此:http://tortoisesvn.sourceforge.net/node/137
    http://tortoisesvn.sourceforge.net/docs/release/TortoiseSVN_en/ch03.html#tsvn-serversetup-apache-5
  2. 把 zip 裡面的 mod_auth_sspi.so 解壓縮到 modules 目錄下。
  3. 把下面這行加入到 Apache 的 httpd.conf 裡面:LoadModule sspi_auth_module modules/mod_auth_sspi.so
    注意上面加入的這行一定要放在下面這行的前面:LoadModule auth_module modules/mod_auth.so
  4. 修改httpd.conf 的設定如下:
    <Location /svn> DAV
    svn SVNParentPath d:/svn
    AuthType SSPI AuthName “Subversion 檔案庫"
    Require valid-user
    SSPIAuth On
    SSPIAuthoritative On
    SSPIDomain
    SSPIOfferBasic On

    其中 就是你的 Windows 網域控制器的電腦名稱(例如:WIN2KDC),注意兩邊的括號不用保留。如果你的環境沒有網域控制器,就維持原來的就行了。在我的環境下,我發現即使有網域控制器,但是這裡不去設定它,還是能夠正常的驗證使用者身分。
  5. 重新啟動 Apache。

現在開啟瀏覽器,輸入網址 http://127.0.0.1/svn/repository 看看,你預期應該會看到如下的驗證畫面:

若沒有出現這個畫面,而是直接顯示檔案庫內容,怎麼回事?

因為我們現在是使用 Windows 帳戶驗證,你目前已經登入這台機器了,而你要存取的也是本機的資源,換句話說,你的身分已經被驗證過了,所以就不會再要求你輸入帳號跟密碼,這是採用
SSPI 網域驗證的好處。

那麼,如果你的同事 John 的電腦有加入網域,但是他平時都是登入本機,而非登入網域,在存取檔案庫時會不會要求輸入帳號密碼?答案是如果 John 登入他本機的帳號和密碼跟他在網域使用者的帳號密碼完全一樣的話,就無需再輸入密碼;相反的,如果登入本機的使用者帳號和密碼與網域使用者帳號密碼不同,第一次存取時就必須輸入密碼。

你可以在別台機器上,用一個網域裡沒有的使用者帳號去存取 Subverion 檔案庫,如果正確的話,應該就會出現要求輸入帳號密碼的視窗。

以上還只是最基本的設定,如果你希望做些進階的設定,例如允許所有人都可以檢視檔案庫的內容,但是不能修改;或者要加入 SSL 加密機制,建議您參考 [TortoiseSVN 官方文件] 的第三章。

提示 : 啟用身分驗證之後,你會發現用命令列工具 svn.exe 存取檔案庫時,如果是用 http:// 協定,有些子命令(subcommand)執行時會出現 “authorization failed" 的錯誤,這時候你可以在
svn 命令中加入 –username 和 –password 來提供使用者名稱和密碼,例如:

svn co http://myserver/svn/ –username michael –password guesswhat

或者你也可以改用 file:/// 協定。

3. 安裝用戶端:TortoiseSVN

現在你已經有一個可以在http存取Subversion 的伺服器,可以試著在其他電腦上存取檔案庫了。如果你習慣使用命令列工具,那就只要在用戶端電腦上安裝 Subversion 就行了,存取檔案庫都是透過命令列工具(主要是 svn.exe)。這裡要介紹的是一個專門為 Windows 作業系統設計的 Subversion 用戶端:TortoiseSVN(以下簡稱 TSVN)。

3.1 安裝 TortoiseSVN

  1. http://tortoisesvn.tigris.org 下載最新的安裝程式,下載後直接安裝。安裝過程大都是按下一步,只有在問你安裝完成後會要求你重新開機。
  2. http://tortoisesvn.tigris.org 下載繁體中文的語言包(language pack),請注意語言包的版本應該要跟你安裝的 TSVN 版本相同,否則最好不要安裝。語言包裝完之後,用檔案總管在 Windows 桌面上或任何一個資料夾上點一下滑鼠右鍵,選擇 TortoiseSVN -> Settings 以開啟設定視窗,在 “Main" 頁夾中更改 Language 設定為「中文(繁體)」,再按「確定」鈕即可。
  3. 如果你是透過 proxy server 存取 Internet,請在 TSVN 的設定視窗中,切到「網路」頁夾,然後輸入你的 proxy server 相關資訊,否則你將無法存取位於 Internet 上的檔案庫。

安裝完成之後,在任何目錄名稱上點一下滑鼠右鍵都可以看到 TSVN 的功能選項,這也是 TSVN 方便的地方,它不用跟開發工具整合,而是跟作業系統整合在一起,這樣不管你用什麼開發工具,都可以輕鬆的使用 TSVN 來存取檔案庫。

接下來你可以用 TSVN 練習一下存取之前建立好的檔案庫,試著把你現有的專案匯入檔案庫中,並且在用戶端使用 TSVN 執行取出、存入、更新等動作。

TSVN 雖然是用戶端工具,不過它也提供了建立檔案庫、以及匯入、匯出等功能,因此安裝在伺服器端也挺方便的。

4. 結語

按照本文說明的安裝步驟,希望能讓你順利在 Windows 環境下把 Subversion 安裝起來。但是安裝成功以後,真正的工作要才開始,如果你沒有花點時間閱讀 Subversion 的相關文件,在使用版本控制系統的過程中,一定會碰到許多問題。

在正式將你的專案加入 Subversion 檔案庫之前,建議您多考慮一下:

  • 檔案庫的配置方式。究竟要為每一個專案建立一個檔案庫,還是把多個專案放進同一個檔案庫裡?
  • 專案目錄的結構。你要依照官方手冊的方式,在專案的根目錄下建立 trunk、branches、和 tags 嗎?
  • 哪些東西要放進檔案庫裡?

前兩個問題你可以參考 [Subversion電子書第五章] 的建議,再衡量自己的需求來決定。你不見得要依照官方的建議,第一次也許採用最單純的配置方式會比較好,例如:一個檔案庫就只放一個專案,而且只把程式的原始碼 放進檔案庫,也不去分主線支線了,因此專案的目錄結構可以很單純,程式原始碼的根目錄就是專案的根目錄。自己動手做過幾次以後,再去觀察檔案庫的內容,就會比較有感覺了,然後再來考慮自己團隊的需求,自然就能找到最適合自己團隊的配置方式了。

後記

原始發表人:蔡煥麟

延伸閱讀:

Google地圖不再只是Google地圖。

你還是可以查詢Google Maps,找出從這裡到那裡該怎麼走。但何不用Google Maps來標示出辛辛那提的猶太餐廳、都柏林的交通違規攝影機,或美國境內溫泉療養地的所在位置?又何不用它來找尋西雅圖市提供免費上網的咖啡店?或找出你老闆剛買的豪宅位置,以及確切的成交價格?

大多是為了好玩,一群程式設計師正紛紛運用Google Maps程式產生獨特的地圖,再整合其他的資料,例如馬路上的坑洞、賣墨西哥包餅的貨車、看見飛碟甚至謀殺和搶劫案發的地點。

地圖結合實用資訊

結果是Google合成地圖,網際網路上最新型的改裝資料,有的純粹博君一笑,有的則有錢可賺。舉例來說,在Google搜尋引擎鍵入航空公司正式的簡寫和班機編號,查詢結果頁的上方就會顯示FBOweb.com。點閱此連結,即可看到那架飛機用虛擬圖釘標明其位置。此服務也提供飛機的小檔案,列出飛行速度、高度,以及估計這架班機抵達的時刻。

另一項服務,Homepricerecords.com,則視你輸入的地址,把相關的房屋銷售資料與Google地圖結合。(目前該服務只提供舊金山與洛杉磯地區的資料,但該公司承諾,芝加哥和紐約的資料很快就會出爐。)

現在網路上有多少Google合成地圖,無從得知,要推測每天新增多少更不容易。但還是有部落客孜孜不倦地設法追蹤最新的合成地圖情報。安大略省一家軟體公司的會計經理Mike Pegg就是其中之一。數月前,他架設Google Maps Mania部落格,企圖記錄這個網路現象。

Pegg幾乎每天都會列出十幾個網路上新發現的合成地圖,從比較普通的性犯罪者地圖,到令人眼界大開的,像是印度賞鳥地圖等,五花八門。「我幫他們發新聞稿,」Pegg說。

人們這麼做所為何來?脫口而出的回答通常也是實話:因為他們辦得到。Google已發布可產生地圖的軟體,稱為API,全名叫「應用程式設計介面」(application programming interface)。有了這個API,程式設計師即可自製合成地圖,作法是整合其他的資料,像是Craigslist列出的公寓清單,或美國人口普查局公布的人口統計資料。這種程式設計手法稱為AJAX,全稱是Asynchronous JavaScript and XML,本身即為一些程式的混合。

大企業也鼓勵使用

合成地圖在全球資訊網上不算全所未見。音樂家早就用類似手法合成其他歌手的創作。最著名的例子是DJ Danger Mouse去年合成披頭四的「白專輯」(White Album)與Jay-Z的「黑專輯」(Black Album),產生「灰專輯」(Grey Album)。在網路上,Hopstop.com把紐約、波士頓和華盛頓的地下鐵與公車路線資料,拿來與餐廳及娛樂場所的資料庫整合。

新鮮的是,大企業也鼓勵使用者利用這些資訊。網路零售巨人Amazon一直允許企業家從Amazon的資料庫與軟體程式中擷取一部分,自創新的應用程式,例如MusicPlasma,此軟體可用圖形呈現不同音樂創作藝人之間的關聯。(輸入樂團Weezer的名字,就會出現一大堆樂團名,如Nirvana、Nine Inch Nails和Zwan。)該網站最近更名為Liveplasma.com,也打造類似的電影搜尋工具,並提供免費的地圖功能。

加州柏克萊資深程式設計師Jef Poskanzer說:「這一切都迅速發生。就像1990年代一樣,人人都在全球資訊網上創造各式各樣的東西。」他本人已製作出溫泉地圖、巴黎古堡地圖、巴黎以及舊金山一帶的賽艇與大眾運輸系統地圖。

和1990年代不一樣的是,現在的創作更具草根性,因為這麼做輕而易舉。他說:「現在還是需要程式設計師來撰寫類似Google地圖這類程式,但因為你可以到別的網站複製程式碼,所以更簡單了。」

人人都能動手

簡單多了。由網景(Netscape)共同創辦人Marc Andreessen創立的一家公司,就希望進一步推廣民眾自製合成地圖。他成立了Ning.com,可自動產生自製Google合成地圖所需的工具,讓幾乎人人都能自己動手編纂地圖。

一旦你以「開發人員資格」(developer status)登記,該網站就會從你想模仿的網站拷貝其幕後的程式,讓你把它修改成自己的版本。不到五分鐘,你就能架設一個綠豆沙拉餐廳(Mung Bean Salad Restaurant)網站。

Google在開發地圖功能時,就知道自己沒有時間和興趣為興趣天南地北的使用者製作各種專門的地圖。但容許林林總總的合成地圖,符合Google整理世界資訊的策略,因此Google樂得開放這項功能供民眾運用。Google Local產品經理Bret Taylor說,該公司讓網站用符合經濟效益而且技術可行的方式,以地圖形式呈現資料。

Yahoo也開放某些網路服務幕後的API,包括相片儲存網站Flickr、Yahoo Shopping以及 Yahoo Maps的API。就連對自家程式碼保護有加的微軟公司,也對外發布地圖功能的API。但Google Maps風行得最快,而且目前看來吸引最多的開發者為它寫程式。

Taylor說,Google Maps大受歡迎的原因之一,或許是Google允許合成地圖的創造者與Google分享在網站上刊登和銷售廣告的營收。(事實上,在允許使用地圖的同時, Google仍保留未來在網站上刊登廣告的權利。)Taylor說:「這對開發者有利,對Google也有利。」

一群新創業家也踴躍投入這塊市場。去年自史丹福大學商學院畢業的Pete Flint與同窗好友Sami Inkinen共同創立Trulia.com,在Google地圖上標示房地產物件。在中意的住宅區點選某個圖釘,就會顯現一連串登錄的待售房屋,附帶最近成交的房屋及鄰近不動產的比較資訊。

Trulia目前只提供加州五座城市的資料,而且現有的資料稍嫌單薄,因為採用的是報紙、網站等公開可得的資料來源,而不是當地房屋仲介協會有版權的資料庫。Trulia計劃未來增添額外的資訊,例如人口普查資料。

不論是賣廣告或為房屋仲介商聚集人潮,由此已看得出獲利商機。Flint說:「大致而言,我們依循Google模式。這只是焦點更集中的Google搜尋引擎模式。」

不過,Google雖開放業者使用該公司的地圖,但也有其限度。一旦某個合成地圖演變成大規模的商業服務,Google就會要求分享營收。例如,Google的律師就開始與Trulia洽談權利金協議。「目前免費,」Flint說:「我們正善加利用。」

更靈巧的程式開發技術興起,特別是打造互動式瀏覽器應用程式的AJAX大受歡迎,正為消費者應用程式搬上全球資訊網(Web)的風潮推波助瀾。

受此鼓舞,昔日曾被視為不切實際的構想–例如打造線上版的微軟Office替代品–如今紛紛捲土重來。

Google Maps這類網路服務(Web services)的推出,讓使用者感受到顯然比傳統網站優良的使用經驗,也協助打開AJAX的知名度。現在已有數十家新創公司運用AJAX打造網路版的桌上型電腦應用程式,從文書處理器到專案管理軟體,不一而足。

但這些網路應用程式(有時被稱作Web 2.0)不只是在網路上複製微軟Office而已,許多程式聚焦於在網際網路上出版並分享資訊。

AJAX運用JavaScript程式語言及其他Web標準。分析師與創業家說,基本的AJAX技術創始於1990年代,但直到最近–大概在今年2月AJAX一詞誕生後–才引起眾多開發人員與創業家注意到AJAX帶來的新商機。

今年Google採用AJAX,有助於展示網路應用程式的外觀和感覺可媲美桌上型電腦應用程式。網頁瀏覽器廣泛採納網路標準,也說服開發人員相信,AJAX應用程式可在大多數的PC上執行。

Burton Group分析師Richard Monson-Haefel說:「AJAX今年初推出後,許多公司如雨後春筍般在各地成立。這些新創公司大有可為,他們擁有聰明的程式開發人員,能夠利用AJAX,而且不被某些工具軟體商套牢。」

以Macromedia Flash和Flex等多媒體工具打造的互動式網頁已存在多年,這些所謂的豐富(rich)網路應用程式工具仍會繼續支援複雜的任務。相形之下,Monson-Haefel指出,AJAX適用於比較單純的任務,例如在既有的網站上增添互動性。

有能力打造出更好的網站後,以廣告費或會員訂費收入支撐的主機代管服務(hosted services)應運而生。這與傳統桌上型電腦軟體的銷售模式大異其趣;傳統上,消費者必須預先付一筆費用,才能把軟體安裝到單機上使用。

現在,連桌上型電腦軟體業的霸主微軟公司也急起直追,積極進軍網路應用程式服務市場。

微軟已經以軟體服務為中心,把旗下的事業部門重新編組,並在11月推出Live.com服務,包括源自MSN部門的諸多服務,例如Hotmail(未來將更名為Windows Live Mail)。這些服務大多倚賴重新以AJAX翻新後的前端(front end)設計。

AJAX Office?

AJAX的使用率日益普及–加上微軟擁抱網路軟體服務–促使眾人揣測未來線上版的微軟Office替代品可能問世。線上版的生產力應用程式早已有業者提供,但他們現在要做的是把網路通訊(Web-based communication)也納入其中,成為全套服務不可或缺的一環。

例如,Upstartle公司的Writely.com已是線上版的文書處理器。但該系統更大的價值在於讓使用者輕易共同製作並分享網頁。

Upstartle共同創辦人Sam Schillace說:「我們剛推出的四、五個月內,眾人都說我們瘋了。他們說:誰會想用瀏覽器編輯文件?但現在,你看到微軟和Google也跟進。所以,短短六個月內,這已從瘋狂的點子變成想當然爾的共識。」

Google決定指派一部分員工專門投入OpenOffice開放原始碼計畫,已引起外界揣測Google未來會不會提供網路版的生產力套餐軟體服務。

至於微軟,則尚未宣布提供完整線上版Office的計畫。軟體巨人上個月表示,醞釀推出新軟體服務,稱為Office Live,協助小公司追蹤客戶交易或管理聯絡事務。但新服務只會補充Office,不會取而代之。微軟說,Office Live將推出廣告贊助版和會員付費版。

另一家提供線上版Office式應用軟體的是新創公司Silveroffice,產品稱為gOffice。該公司的網站提供文書處理與列印軟體,並計劃不久後推出線上試算表與簡報軟體。創辦人兼執行長Kevin Warnock透露,該公司計劃明年元月推出把文件轉化為Adobe Systems PDF格式的服務。

gOffice應用程式免費提供,以廣告收入支撐。Warnock說,該公司有意對不希望廣告干擾的顧客(特別是企業用戶)提供會員制服務。目前的註冊用戶總數達「五位數字」,但該公司希望能增加到200萬,其中許多可望是美國境外的用戶。

然而,Silveroffice公司的目標並不是取代微軟Office。

Warnock說:「我認為,(gOffice)可以自然而然地與Office套餐軟體長期並存,兩者不必拚得你死我活。」他指出,即使許多PC裡預先安裝微軟的Outlook軟體,使用者仍然在用網頁郵件系統,例如Hotmail或GMail。

他說,採用AJAX與線上供應的模式,讓他員工僅15人的新創公司能自力更生。他說:「 這真的是一種務實的方法,不必籌措資金就能接觸到廣大的民眾。」

企業與消費者

不論是Writely、gOffice、其他架構在全球資訊網上的生產力應用軟體(例如37 Signals的待辦事項與個人資料管理工具) ,或網路版的即時傳訊(IM)應用程式,都以消費者為主要服務對象。但IT主管與分析師說,AJAX式的瀏覽器程式開發方興未艾,就連企業界也將感受到其衝擊。

企業可運用AJAX,為現有的企業網站增添更豐富的互動功能,也可運用以可延伸標示語言(XML)編寫的資料轉移(data transfers)指令來製造大雜膾(mash-up),從各種不同的來源擷取資料。Monson-Haefel舉例說,不動產網站可從學校抓取資料,然後與登錄的房屋物件並列。

電子郵件與行事曆軟體公司Zimbra的技術長Scott Dietzen預期,AJAX可望大大地影響企業對企業(business-to-business )的應用程式。例如,金融服務業和電信業的顧客會要求功能更豐富的使用者介面。Zimbra以企業為導向的產品密集採用AJAX作資料交換,比方說可在行事曆的某一項裡顯示在Google Maps呈現出的開會地點。

企業用戶Iconix Pharmaceuticals用AJAX與General Interface(後來被整合軟體供應商Tibco併購)的工具搭配使用,打造出一種應用程式,讓製藥公司的技術人員能使用龐大的資料庫,以及功能先進的前端系統,用來追蹤人體實驗的藥效。

使用AJAX,讓Iconix得以打造一種複雜的使用者介面,並與多重的資料來源連結。該公司資訊部副總裁Alan Roter說,產品架構在全球資訊網上即可透過網際網路提供,不然就得預先安裝。

他說:「假如不用架構在網路上的UI(使用者介面),我們就得用某種厚重型用戶端,並設置某種主從介面(client-server interface)以及所有必須的配套。架構在全球資訊網上的優點在於無須安裝。那很棒。」

Roter說,Tibco的AJAX工具很靈巧,有助於加速程式開發時間,比用其他語言更快。不過,分析師認為,AJAX工具的成熟度大致而言仍遜於根基穩固的產品。

Monson-Haefel說,目前商用AJAX工具的市場生態系仍未臻成熟。他預期,有朝一日, AJAX終究會成為一種主流的開發技術,就像Adobe旗下的Macromedia工具或微軟的工具。

但Writely的Schillace預測,AJAX日益受歡迎,會造成網頁的互動功能過量。的確,一些企業主管與分析師已開始擔心過度運用AJAX技術可能引起的副作用–網頁徒具高度的互動性,先天上卻設計不良。

Zimbra的Dietzen表示,AJAX不是萬靈丹,諸如複雜的試算表或簡報軟體等應用程式,仍需要用到桌上型電腦的儲存空間。他說:「AJAX的確能需要它的傳統網路應用增色不少,但不是所有的網路應用都需要更豐富的使用者介面。對於適用的網路應用,AJAX顯然是最佳選擇。」

微軟公司26日發布預覽版的新開發者工具,目的在協助企業用戶加速建置客製化的網路應用程式。

軟體巨人發布「社群技術預覽」版模組化工具(modeling tools),昔日代稱「白馬」( Whitehorse),日後會納入微軟為企業應用程式開發者設計的Visual Studio 2005 Team System。

新的模型化工具讓開發者把網路應用程式視覺化,即用複雜的圖形代表軟體元件。微軟首席產品經理Prashant Sridharan說,此概念的用意,是讓開發者更容易洞悉程式內部組合的方式,以增進開發者的生產力並提昇軟體的品質。

「傳統上,模型化工具是通用型的,與基本程式碼的結構少有關聯,」他說:「雖然圖形畫得很漂亮,但對實際動手發展程式的人來說,所知卻有限。」結果造成開發出來的應用程式達不到預期,或功能不盡理想。
模型化就軟體發展而言不是新觀念,但更好的工具和效能更強的電腦,可讓模型化比以往更實用。整體而言,隨著企業費力管理日益複雜的運算系統,對模型化與設計的興趣已增濃。

微軟競爭對手如IBM、Borland Software等,也紛紛投資模型化。Borland周一剛發表自家的模型化工具,稱為Together Architect。產品行銷副總裁Erik Frieberg認為,模型化在軟體發展過程扮演的角色,有如企業資源規劃之於商業預測。

不輕易當掉也不需經常維修的高品質軟體,是企業最重要應用程式必備的要件。市場研究公司Gartner估計,「緊要任務」軟體意外停擺的代價,是平均每小時損失10萬美元。Gartner說,整整40%的應用程式故障,皆因軟體問題而起。

開發者工具供應商面臨的一大顧慮,是如何協助企業用戶備妥新軟體,以便擁抱所謂的服務導向架構(SOA)。分析師說,SOA終會導致更有彈性、品質更好而且費用降低的軟體。舉例來說,SOA可讓電子商務網站執行集合多家商業夥伴共同參與的複雜交易,方法是把多重的網路服務(Web services)結合起來,無須程式設計師一一用手寫的程式碼連結商業夥伴。

發布支援Visual Studio模型化工具的軟體開發工具程式,微軟希望藉此鼓勵合作夥伴和客戶建置客製化的模型元件,以描述適合特定產業和任務用的軟體功能。

微軟預定在2005年中發布各種新版的Visual Studio,以配合大舉整頓微軟的開發者工具事業。新的Visual Studio版本是微軟「軟體工廠」(Software Factories)計畫的第一步,目標是把例行任務自動化,以協助企業加速打造客製化的應用程式。

八大BT軟件介紹

1. BitComet BitComet :

  • 全新高效的網絡內核,快速穩定,高速下載時依然保持很少的CPU占用。
  • 多任務同時下載,並支持對一個Torrent中的文件有選擇的下載。
  • 允許限制上傳速度和下載速度。
  • 動態磁盤緩存技朮,有效減小高速下載上傳對硬盤的損傷。
  • 自動保存下載狀態,續傳無需再次掃描文件,作種子也無需掃描文件。
  • 支持XP防火墻和網絡連接共享,硬件路由器(支持UPnP)的自動端口映射,內網免配置。
  • 可選為沒有下載完畢的文件添加.bc!后綴。
  • 自動檢查版本更新。
  • 支持多Tracker協議。
  • 只需一個監听端口即可滿足所有下載需要。
  • 多語言界面。

官方網站: http://www.bitcomet.com/indexzh.htm

2. 貪婪BT (GreedBT) ABC

  • 3MB的安裝包包含了所有功能,制作發布,多任務,高級設置等
  • 占用內存很少,速度飛快,設置全面。
  • 單窗口多任務同時進行
  • ABC-Tweak工具可以自由更改貪婪BT(ABC)的顯示界面
  • 隊列的優先級系統
  • 支持暫停、繼續、隊列、刪除的操作
  • 最小化到系統任務欄
  • 查看下載的詳細信息
  • 可以進行上傳、下載許多設置
  • 可以為每個任務單獨進行設置
  • 支持從Shad0w’s bittorrent延伸過來的高級設置
  • 支持超級種子模式
  • 可以設置下載完成的文件的動作
  • 可以設置最大任務數
  • 支持提示保存目錄
  • 支持從本地和網絡手工添加torrent文件
  • 支持關聯torrent文件
  • 包含了制作torrent文件的工具

官方網站: http://bt.greedland.net/greedbt.php

3. BitAnarch 1.05a

  • 支援暫停、繼續 操作
  • 最小化到系統任務欄
  • 查看下載的詳細資訊
  • 可以設置下載完成的檔的動作
  • 可以設置最大任務數
  • 支援提示保存目錄
  • 支援從本地和網路手工添加torrent檔
  • 支援關聯torrent檔
  • 支援Muti-Tracker下載

官方網站: http://sourceforge.net/projects/bitanarch/

4.BitSpirit (比特精靈)v2.0 Final BitSpirit

  • 磁盤緩存机制
  • 很高的下載速度
  • 強大的下載管理功能
  • 文件選擇性下載
  • 快速啟動任務,無需等待 :靈活的速度控制
  • 數据壓縮傳送
  • 詳細的運行狀態信息
  • 方便的計划下載
  • 跟IE相集成,輕松下載
  • 監視剪貼板,方便添加任務
  • 完整支持UPNP,ICF
  • 可以與其它下載者聊天
  • 支持HTTP/SOCKS4/5代理

官方網站: http://www.lanspirit.com/bitspirit/index1.htm

5. BitTorrent CVS

  • 佔用記憶體很少,速度飛快:最小化到系統任務欄
  • 查看下載的詳細資訊
  • 可以進行上傳、下載設置
  • 支援提示保存目錄
  • 支援關聯torrent檔

官方網站: http://ei.kefro.st/projects/btclient/

6. Turbo BT

  • 清晰明了,美觀的界面.速度,時間,種子,對等用戶狀態一看就知
  • 中文,英文,繁體中文多語言版.可以動態切換
  • 可以保存系統設置,動態修改設置,取得最佳的下載效果
  • 在運行過程中可以暫停和恢復
  • 非常低的資源占用率. 在高速下載的同時不影響其他軟件的使用
  • 根据普遍的網絡帶寬配置,提供快捷速度設置,設置速度只需要從菜單上選擇一下
  • 下載完成后自動進入種子者模式.且速度降低.在造福其他人的同時,不影響自己的工作娛樂。
  • 提供動態幫助提示顯示在狀態欄,幫助您快速學習軟件的使用
  • 下載完成后自動播放提醒聲音
  • 可以自定義設置端口,在某些網絡中默認端口被封閉的情況下.多任務下載
  • 下載隊列
  • 自動關机

官方網站: http://www.turbobt.com/

7. Azureus

  • 包含了所有下載功能,設置等
  • 佔用記憶體很多,速度一流
  • 支援暫停、繼續、刪除的操作
  • 最小化到系統任務欄
  • 支援提示保存目錄
  • 支援從本地和網路手工添加torrent檔
  • 支援關聯torrent檔
  • 支援Muti-Tracker下載
  • 完美的下載細節

官方網站: http://azureus.sourceforge.net/

8. Shareaza (簡稱:Raza)
是支援 eDonkey、BitTorrent、Gnutella 檔案共享平台的 P2P 用戶端軟體,在國外的評價極高,該軟體公司的目標是打造一個支援各種 P2P 檔案分享平台的用戶端軟體,Shareaza 完全免費,不含間諜軟體、沒有附加廣告軟體。

第2代BT除了不傷Hard Disk外,支援多國語詞,還加入P2P功能(唔怕死Link),第2代BT = BT+WinMX+Media Player,如你想用P2P功能那一定要Connect eDonkey, 好多人都有個問題,就係連唔到去eDonkey, 其實好簡單, 去工具,入面有個setting,入面揀番個eDongkey2000, 再下載番,再揀埋自動連線就可以連到的了!

官方網站: http://www.shareaza.com/

作者: 劉龍龍

開放原始碼來勢洶洶,尤其是Linux,幾乎所有的市場預測資訊都顯示未來數年Linux伺服器市場佔有率會大幅成長;而屆時Linux相關的軟硬體及服務市場總值也達數百億美元。

這些數字當然都是很吸引人的,姑且不去討論市場專家們是如何估算,也不去計較美國市場應佔全球市場多少百分比才恰當等專業知識;在這個看來充滿商機的市場上,資訊相關廠商理當是會賺錢的一方,而付錢(也就是被尊稱為「客戶」)的另一方,為什麼會主動隨著音樂就開始跳起舞來呢?我想嘗試從「企業」類型客戶的角度來談談。

大多數企業類型的客戶都只是資訊產品的使用者,一般都會注重產品功能、是否好用、是否安全等等切身的考慮因素,但是不太會去關心產品內部是如何設計等的技術細節。比較有規模的企業雖然設有MIS部門,通常也都會為了要維持各項資訊通信設備每天的正常運作而忙得不可開交。

因此,我認為,一般企業對開放原始碼的接觸,是很明確地僅止於「應用」的界限。企業不會、也沒有能力像網路上的個人高手(即駭客)一樣去下載、查閱、改寫、維護任何開放原始碼,企業會在某些有利條件下採用內含開放原始碼的應用解決方案,而這些解決方案都是由專業資訊公司提供。

企業資訊化的目的當然是為了提昇競爭力。但是,資訊化必須要有成本;而成本當然是希望越低越好。企業應用開放原始碼會降低成本嗎?開放原始碼支持者說會,微軟說不會,用了反而會增加成本。不管怎樣,因為他們都不是真正的當事(要付錢的)人,考慮因素可能不完全,所以兩邊說的都未必定能採信,自己算算比較踏實,錯了也不要怪別人亂說。

我對開放原始碼應用成本效益比較的看法,可以先拿在西餐廳點餐為例來比喻:到底是要點大廚規劃的建議套餐比較好,還是單點幾項來組合比較好呢?這個問題的答案可能還是要看點餐的人肚子到底有多餓、想吃牛肉還是海鮮、當天菜單內容如何、甚至服務生是否能清楚介紹等等因素的描述之後再判斷,才比較會正確,而且點餐人點完後如果吃得不滿意卻硬要說很好,別人也不便再更正他。

我認為目前企業的開放原始碼應用,就像中國人開始學吃西餐,並不清楚西餐文化及點餐細節,也許需要去嘗試一些錯誤之後或是產生西餐西吃變成西餐中吃的方式,那就正常了。簡言之,成本效益似乎不一定是開放原始碼的主要正面議題,也不必非在數字上評估。

那麼,開放原始碼能帶給企業什麼樣的效益呢?事實上,我已經觀察到幾個不易量化的效益反而是非常明顯,但是好像都被企業主管忽略掉:

合乎時代潮流的效益

開放原始碼是一股潮流,誰都擋不住,年輕同仁更是樂於參與;它並不一定要非是好或非是壞,它就是它,只要與它同在就行。我會建議那些老總級的朋友們,你也不需要叫資訊長寫充滿了技術名詞但又看不太懂的資訊設備擴充計畫,也不見得要財務長準備各種短中長期財務分析報表,只要簡單地吐出「我決定導入開放原始碼」這十個字;我保證「老板英明」的耳語馬上就會在你的企業中迅速流傳開來。

當然,如何導入開放原始碼這件事還是要資訊長去頭大,但是同仁那種「我們已與時代走在一起」的感覺會反應在工作氣氛及實質產出上。或者,把這個訴求放在招募新進人員的廣告文宣上試試看。

平衡供給主動優勢效益
企業一旦開始導入開放原始碼,負責提供資訊服務的廠商們馬上就會產生地殼擠壓效應。最主要的是原有廠商們在過去多年之間所建立牢不可破的組合必須重新整理,因為現在可能有第二建議解決方案,可供選擇了。如果原有廠商願意合理提供更佳的技術、服務、及保障,那繼續採用無妨;如果不願或不能(如產品代理權限不足)合理提供應有的項目以滿足基本需求,那就可以考慮改由有技術能力的廠商以開放原始碼方案取代?,以免越陷越深。我的瞭解是現在市場競爭激烈,供應商除非是客戶趁機獅子大開口,要求的太離譜,做下去真的不敷成本;否則都是將本求利,儘量滿足客戶需求。如此,買方或許就因此能迅速重振 (廠商不一定非是降價以求,而是將原來套牢的繩索打開)主動優勢效益。

分散風險效益

這個效益很容易被接受,因為任何企業都擔心如果把所有的雞蛋都放在一個籃子裡,萬一有差錯其後果是不可彌補的。開放原始碼很自然地會成為第一選擇。我常常跟企業界的朋友們建議,在導入開放原始碼的計畫裡,除了新開發的應用之外,不妨考慮把現有重要系統的備援系統也列進去。

雖然目前企業對開放原始碼的應用模式還不熟悉,經驗觀摩等等資訊也還不足;但是就上述的幾個效益來看,現在開始考慮導入開放原始碼,至少不會使貴公司輸在起跑線上。

http://taiwan.cnet.com/enterprise/technology/0,2000062852,20095473,00.htm

David Berlind‧唐慧文  2005/01/07

全球資訊網上的聯合供稿(Web syndication)技術種類繁多。一如諺語所述的情況:標準最棒的地方在於標準太多了。

若真要把RSS 1.0、RSS 2.0(其實接續的不是RSS 1.0版,而是0.94版)、Atom和其他林林總總沾得上邊的網際網路聯合供稿技術理出個頭緒,恐怕需要做碩士論文級的研究。如果在規格的層次上就有問題、而且沒辦法解決的話(依我之見有些衝突是被新聞界誇大了),那麼我們怎能指望第一線的應用會變得容易上手?本文將討論使用者設法把現有技術湊合著用的情形。

我碰到的一個RSS 2.0問題是,網路出版者通常使用不同的慣例,來刊登以RSS(真簡單聯合供稿)系統傳送的資訊。雖然這種彈性正是RSS 2.0最棒的優點之一,但如此一來,把多重RSS feeds標準化以便匯整呈現的負擔,就轉移到閱聽者這一端。儘管終端使用者應用程式(包括RSS閱讀器在內)通常內含人工智慧,可補救所處理檔案格式紊亂不一的問題(這也意味處理RSS的應用軟體前景相當不錯),但我懷疑RSS會不會也證明軟體商要兌現諾言極為困難 — 他們承諾提供為平常人開發的軟體,讓技術生手只用游標和滑鼠點選和拖曳,也能打造出複雜的、交易性(transactional)、伺服器端的應用。

畢竟,RSS是當今最能展現可延伸標示語言(XML)對普羅大眾有何用處的範例,也象徵大多數人與XML最接近的接觸。基於RSS的人氣日盛,大有可能演變成所有資料(不論結構嚴謹或鬆散)賴以採集的主要方式 — 不論用途僅為瀏覽最新的網誌(Weblog)更新內容、檢索電子郵件(嘿,那不就終結垃圾郵件了嗎?),或是透過複雜的工作流程傳遞交易資料。就此而論,RSS也可能被當作「點選式程式設計」(point-and-click programming)的一大試金石。

為了鼓勵透過ZDNet網誌領域進行線上協同作業,我們已建立一個內部的Wiki。日後或許內容會更豐富,但目前我們的Wiki首頁比較像是共享的書籤陳列室。我倒是建了一個次級網頁,展現出多重使用者系統的威力:在上面可把我所屬工作群組必須追蹤的網誌一覽無遺。我用Twiki標題外掛程式把以RSS為基礎的聯合發稿內容匯整到同一網頁,基本上該網頁相當於在網誌領域的一個角落設立入口網站,以便我們觀察我認為不該遺漏的網誌。我稱之為我們的雷達。

我加入擷取自Robert ScobleJonathan SchwartzTim BrayBob FrankstonSlashdotGroklaw等網誌的內容,不久之後,ZDNet.com副總裁Stephen Howard-Sarin又在這個網頁添加了一些,取自於Dan BricklinJon UdellDan GillmorPhil WindleyDoc Searls等人的網誌。儘管這還稱不上是「點選式伺服器端程式設計」,我認為已十分接近。

但我不滿意這個外掛程式預設的內容擷取格式,以及在網頁上呈現的方式。所以,為牽就我們的需要,我在外掛程式之外添加了一些選擇參數(optional parameters),以確定最後顯示出來的網頁是純文字(為了效能起見),而且只從各種內容來源擷取最新的五則標題。以圖示來呈現這類選擇參數、自動產生編碼,並且把程式碼嵌入網頁,這些正是我期待「點選式程式設計」能夠為我代勞的事,而不是凡事都得用硬碼(hard-coding)方式來做(我目前的作法)。

在Wiki普遍成為政治正確的作法之際,Howard-Sarin也在添加網誌內容時仿效我採用的格式。由於欠缺更簡單易用的工具,他只用剪貼方式把程式碼拷貝過來,然後提供不可或缺的替代品。對一群非專業程式設計者來說,能做到這種地步已經很不錯了吧?短短幾個鐘頭,我們兩人同心協力製作了一個入口網站,提供有意義的資訊,而且會隨每次網頁重新整理更新內容。現在,就等其他ZDNet使用者共襄盛舉,把他們喜愛的、不重複的網路內容丟進這個網頁即可。

可是,還有個問題。有些內容無法正常顯示,害得我耗費比原訂計畫更多的時間。比方說,Jonathan Schwartz網誌裡的每一篇內容,都以異於他人的方式呈現 — 在他以XML為格式的內容中,每一篇不重複的網誌內容(稱為一個item) 都省略連結欄(link field)。大多數的內容,例如擷取自ZDNet的本文,都用連結欄來儲存通用資源識別碼(URI),以直接連上個別的item(就本文為例,指的是一篇新聞報導,而不是網誌裡的一則日誌)。省略掉連結欄,Schwartz依賴GUID (全域唯一性識別碼,讀音「gwid」) 欄附帶的選項(稱為「permalink」),來儲存常駐的連結,以連上個別的網誌文章。這麼做是有道理的,因為要跨越整個網際網路連上某則特定的內容,使用專屬的連結是你所能找到、最獨一無二的方法。或許你能想出別的辦法,但何必花這個腦筋呢?基於此理,幾乎人人都把導向自己每則內容的直接連結存在GUID裡。對許多人來說,這意味在GUID裡找到的資料,與在連結欄(若他們採用的話)裡尋得的資料,是一模一樣的。

這些很重要嗎?嗯,就我而言,我覺得很重要,因為我試著想出一種可輕易重複使用的外掛程式參數組合(用「點選式程式設計」術語會稱之為「物件」,但我要等到親眼目睹才會信以為真) ,來建置我們的入口網頁,而那套組合要能夠用同一方式對待本網頁所觀測的各個內容來源。如果某物件在「普通人用的點選式程式設計」現實世界裡只是偶爾才管用,那麼沒多久,一般人就會棄滑鼠投降。

參照TWiki文件編寫採用連結欄的範例,我開始嘗試用它來提供入口網站使用者一個可回歸原始內容出處的連結。這很合理,不是嗎?然而,一旦連結欄被省略,如同Schwartz網誌的情況,即便我在入口網頁上一一附上連結,也不過是死的連結。為了研究這個問題,我進一步探討RSS的弱點 — 我不認為其他只為體驗網路聯合供稿威力的使用者必須探究得這麼深入。我發現,如果Schwartz的網誌把每則內容專屬的URI存進GUID的話(他是這麼做的),那麼我就可以倚賴GUID的目錄把使用者導回內容的原始出處。就可重複利用的能力而論,我考慮把這種作法全面套用在我們監看的所有內容上。

以下這一段是RSS 2.0的規格範例,由此可說明連結與GUID未必相同,也證明我傾向採取的解決辦法是對的:

「有關<guid>s的一個常見的問題是與<link>s該怎麼區分,不就是同樣的東西嗎?沒錯,在內容系統裡是如此,但在其他的系統就不見得。在某些系統,<link>s是連上網誌篇章的permalink。但在別的系統,每一個<item>是全文的摘要,<link>s指向該文,而<guid>s則是連上該則網誌內容的permalink。不論在什麼情況下,都建議你提供guid,並儘可能讓它以permalink呈現。這麼做可避免匯整器重複擷取相同的item,儘管這些item可能因為有修改過而有所不同。」

以上是專家建議的最佳範例,無疑是大勢所趨,也隱約暴露出許多內容供應系統依循不同慣例的問題。這正是我遭遇的問題。現在,可重複利用性已被判出局,而我甚至還沒開始嘗試用滑鼠作「點選式程式設計」咧。就每一個我加進入口網頁的內容來源而言,現在我會先研究它的XML,再決定該用哪一套參數。

但GUID相對於link的問題,並不是我們面對的唯一挑戰。

有些內容供應feeds,像是Dave Winer的Scripting News,也丟出一個變化球。Winer的網誌文章不附標題。這是個麻煩,因為要建置含20多個出處、一目瞭然的入口網站,我們決定最簡單的作法便是只顯示item的標題,然後附上導向全文的連結(使用前文提到的item連結或GUID,視哪一種比較適用而定)。但是,就Winer的XML來說,能擷取的東西有限。沒標題可選,只能擷取其他三種 — GUID、item的發表日期(pubDate)、或是item(敘述)的全文。但item的全文長度從寥寥數字到堂堂數段不等,沒道理拿它來當作超文字連結(hyperlink)。

如同Schwartz的網誌,Winer的GUID也是連上全文的URI。換言之,能供我們用來當連結的文字只剩下發表日期。顯然Mozilla.org對無標題item的感受和我們一樣。Firefox瀏覽器採用一種稱為Live Bookmarks的功能,用來追蹤RSS feeds;該瀏覽器在碰上無標題item時,為了產生可點選的內容連結選單,也提供發表日期作為連上原文的線索。事實上,在處理規格不一的RSS應用方面,Firefox的表現一級棒,就連碰上在同一網誌裡有的item附標題、有的又不附標題的John Robb頻道時,也能機動應變。把Robb的網誌加入Firefox的Live Bookmark後,產生的選單即顯示出Firefox從每一item就地選材,有的擷取發表日期,有的擷取標題。這印證前文所言,就網路聯合供稿而論,供應端所做的選擇,其衍生的後果一概由閱聽者這端承擔。換句話說,控制權從供應者這方轉移到內容出版者這方。值得注意的是,此現象似乎與全球資訊網的走向背道而馳。(基於Internet Explorer使用者眾多,和許多網站用Firefox無法正常顯示,以後見之明來看,即可驗證供應端總是會順應需求端來作調整。)

同理,再度驗證通常軟體會代使用者做複雜的決定和演算法,Dave Winer的網站內容匯整器也作了令人讚許的貢獻,就是把各式各樣的內容慣例標準化,形成單一介面,再透過該介面把源自不同頻道的文章攙雜在一起,按照匯整器擷取的時間倒序排列。比方說12點15分時,某頻道可能顯示出五則,但其中最早刊出的一則也許不比排在它前面、出自另一頻道的文章來得新。不過,不論是哪一則,都是根據終端使用者所在地的時區來顯示發表時間。網路匯整器可不可能自動判知終端使用者的時區,我不清楚;但就Firefox和Newsgator這類美國境內執行的RSS匯整器而言,是辦得到的。看出未來的成長空間了嗎?

起初,我暗地咒罵Winer竟然不附標題。但一旦開始追蹤Winer的網誌後,我就領悟到這種抉擇自有道理。他的網誌只是意識流似的日誌。人在思考時,會先下標題嗎?不會吧。Winer不會,也無此必要。他和別人的網誌之所以可讀性高,與附標題的新聞報導與眾不同,就是因為網誌就像日記一般。這些網誌有許多篇章是想到什麼就援筆立就,若是作者必須停下來先為每一篇定個標題,可能就跟不上奔馳的思緒。這些是特例。另一人氣鼎盛的網誌,作者是微軟的Robert Scoble,就不管每則篇幅多短,都一律冠上標題。以最近談微軟執行長Steve Ballmer評論蘋果iPod的那一則為例,標題幾乎與全文等長。如果他給網誌文章下的標題少一些,或根本不定標題,或許我們更能深入了解Scoble腦子裡的想法。

為了建置一套可重複利用的參數(以便別人只需剪剪貼貼即可),我不得不緊盯著Winer的內容,我愈是瞪著它瞧,就愈發現自己掙扎於兩種選擇之間的取捨:該用發表日期作為我們TWiki架構入口網站的連結文字呢,還是乾脆把他的全文(儲存在各個item的敘述欄內)下載並顯示在我們的入口網頁呢?畢竟,我們內容顯示的程度僅止於最新的五則,而Winer每天定期刊出五則以上,所以若是列出一串發表日期,除了告知每一則何時刊出以外,提供的資訊聊勝於無。我們真正需要的訊息,是全文的內容為何。碰到Winer這種不附標題的內容,我們唯一的選擇,就是擷取全文(端視外掛程式允許的容量而定)。

事實上,一口氣完整的擷取(包括GUID、敘述、發表日期和某來源提供的其餘材料),逐漸看來是最適合我們入口網站的通用方法。就這麼搞定。我總算可以回頭做我日常的工作了吧?哎,還不行。

誠如Winer告訴我的,那種作法可能也行不通,因為和許多網誌不同,新聞網站通常在每篇報導的敘述欄裡提供摘要,而不是完整的全文。更糟的是,就算也把敘述抓過來,我發現TWiki的標題外掛程式無法處理超文字標示語言(HTML)格式,而網路新聞幾乎清一色都用這種格式編寫。

這個實驗計畫就像舊時卡通裡會漏水的水壩。就在你以為所有的漏洞都堵好了的時候,另一處漏水又泉湧而出。最後我只好許願,但求聰明人發明只要點選一下就可解決問題的辦法,就像軟體開發業者向來承諾的那般。只是,就現在的進步速度來看,我懷疑那可能要再苦等數年。

但本文仍算是一篇談論RSS優點的報導 — 也附帶闡述RSS特有的彈性為什麼會讓企圖在亂中求序的人士(比方說軟體開發者)日子難過。畢竟,混亂本是網際網路的常態。