有經營過網拍賣場者優先錄用

江亙松 理財周刊提供
2008 / 09 / 24 星期三 16:33
我最近在擔任一位扶輪社社友的行銷執行顧問，替他們公司銷售超氧酵素，雖然產品的品質與效果都不錯，但是畢竟是新包裝的不知名產品，所以在市場上詢問度與指名度並不高。

為了在建立知名度的同時能建立口碑效益，所以我選擇「以時間換取市場空間」的行銷策略，透過雅虎拍賣的方式，將原本一盒20包的產品拆成5包一組的體驗組，以1元結標外加99元運費的方式銷售，並且會進一步針對這些索取體驗組的使用者做採訪，贈送願意做正面評價的被採訪者一整盒價值NT$1,500的超氧酵素。

您覺得這樣的方式很簡單嗎？策略上不難，但如果您沒有自己操作過雅虎拍賣，千萬別以為很簡單，因為有很多結標、付款、對帳、出貨、評價、後續聯絡的問題，考驗著每一個希望利用網路拍賣來做行銷的賣家。

想到這個問題就不禁讓我預見將來，當我要把這個超氧酵素的網拍銷售模式建立起來，總是要移轉給我這位社友的公司繼續經營下去，他們公司目前看起來人力已經很吃緊，幾位業務與行政人員都已經忙得不可開交，所以勢必要請另外一位新員工來負責這個網拍行銷的業務，如果連我這個不怕網路、不怕行銷的管理顧問都必須謹慎小心，才能一個人處理一個產品的網拍，那這位新人一定被期望可以很快的上手接任這些工作。

「請註明您是否會使用網拍」，這個備註事項也許在將來的求才資訊中會經常被強調出來，或者是寫成「有經營過網拍賣場者優先錄用」，如果愈來愈多企業喜歡使用網拍來銷售產品，那我相信這件事情應該會發生。

學生最喜歡問的問題就是「我應該準備什麼才可以在將來求職的時候脫穎而出」，我每次的回答都是「請你用僅剩的在學期間，致力於經營一個每天有一萬次瀏覽人數的部落格」，而且我還會備註說明「如果你的部落格每天有這麼多人瀏覽你還找不到工作，請你畢業之後立刻到我的公司，我一定給你工作」。

剛開始有電腦的時候，懂得安裝電腦的工程師一定有工作，後來到了有網路的時候，懂得寫網站的工程師也不用怕失業，因為就理性的老闆的角度來看，一位國外碩士的薪水不應該比一個網拍評價1000點以上的賣家來得值錢。

行銷智慧：因應時代需求，青年朋友們多學學網拍與部落格經營吧。

Chinese Article about eXtreme Programming

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的方法論，在每個小階段發行以及每個往覆式的周期之後，甚至是每天下班前，都可以執行一次重構。

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

Subversion for Windows 安裝指南

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

後記

原始發表人：蔡煥麟

延伸閱讀：

• 蔡煥麟 .NET Magazine更新版：http://www.netmag.com.tw/member/netmag_article/N051204703.pdf


• Subversion電子書：http://svnbook.red-bean.com/
  (繁體中文版：http://svn.ntcu.net/svnbook/)


• TortoiseSVN 官方文件。http://tortoisesvn.tigris.org/docs.html#DocDir
• Subvision Wiki：http://svn.ntcu.net/kwiki/
• OpenFoundry SVN使用手冊：http://rt.openfoundry.org/Foundry/Help/4-02.html#sec3

SCM: Good beginner intro in Chinese, by Jedi

版本控制系統不祇可以幫助妳追蹤修訂手上的工作進度，讓妳在千鈞一髮之際還能拾回過往辛苦的結晶，甚至能夠讓妳跟其他人協同工作、合作無間。

一般人聽到「版本控制系統 (Version Control System, VCS) 」或者「修訂版控制系統 (Revision Control System, RCS) 」，總會覺得那是寫程式的怪物們纔會去用的東西、祇有程式碼纔會被放在那樣的環境裡開發。然而隨著資訊量持續增加，每個人在日常生活中必須要掌握、處理的的資訊也越來越繁雜，不管是為了做專題、報告、寫論文乃至於翻譯等，祇要是長時間持續產出的工作，也都逐漸需要有版本管理系統的協助，纔能夠事半功倍了。.....

產品應該賣多少錢

公司產品的售價標籤上，到底要填上什麼數字？這是企業經營中最關鍵的問題之一。許多研究證明，消費者的購買決定常是不理性的。在一個經典研究中，大多數的消費者表示，在購買十五美元的計算機時，若能省下五美元，他們願意多走二十分鐘的路，到比較遠的商店去買。但是如果是購買一二五美元的外套，大多數人卻不願意為了省五美元，多走二十分鐘的路。

提出行為經濟理論，獲得諾貝爾獎的芝加哥大學商學院教授賽勒（Richard Thaler），在接受公司雜誌（Inc.）訪問時解釋，消費者的購買決定很片斷，常會受到情境影響。因此一樣是五美元，一樣是二十分鐘，消費者卻因為省下的金額佔商品總價的比例高低，而做出不同的決定。在計算機的例子中，如果公司減價五美元，能夠吸引更多的顧客；但是在外套的例子中，減價五美元卻無法奏效。

賽勒教授表示，在不同的情境中，影響消費者要不要購買的最大因素是，他們是否相信價格合理。消費者對價格的期望，也扮演了一大角色。賽勒曾做過一個研究，在炙熱的海灘，一個人想要買一瓶冰啤酒。如果是在海灘附近的小雜貨店購買，受訪者平均願意支付一點五美元；如果是在海灘旁的豪華渡假飯店的酒吧購買，平均提高至二點七美元。情境與期望讓冰啤酒價格漲了八成，消費者預期在飯店酒吧需要付更多錢，因此願意付更多錢。

既然產品的定價是否合理，受到消費者主觀認知的影響，哈佛大學專研定價的行銷學教授高爾立（John Gourville）指出，公司在訂價時，應該問的第一個問題是，「一個了解產品真正價值的理性顧客，願意花多少錢購買產品？」產品的價格，結合產品真正的價值，及公司把這個價值溝通給消費者的成功程度。

密西根大學商學院院長杜蘭（Robert Dolan）提醒，許多公司採用了錯誤的訂價法。有些公司訂價時，以產品的成本為基礎，再加上一定比例的利潤為定價，例如成本加上二○％的利潤，但是，為什麼是二○％，四○％不是更好嗎？

有些公司根據對手的價格，訂出一樣或略低的價格，但是公司怎麼知道對手的訂價正確？此外，如果公司訂出比對手更低的價格，可能會引發價格戰，拉低公司的利潤。另外，有些公司則是根據顧客的意見訂價，但是大多數的顧客，當然希望價格越低越好。

學者指出，訂價時一定要考慮成本、對手以及顧客，然而只以其中一個為訂價基礎，都是犯下了大錯誤。一個產品的正確價格，應該以一件事為標準，那就是這個產品所提供的價值。

老闆最討厭的10種爛個性

老闆最討厭的10種爛個性：

1. 不能化繁為簡
2. 爭功諉過
3. 不能勇於任事
4. 不能擁抱變革
5. 拍馬屁與抓耙仔
6. 只會授權，不會用人
7. 太聽話
8. 不誠信
9. 孤芳自賞，沒有利潤觀
10. 不能利他

年假剛結束，正是準備衝刺、蓄勢待發的時候。要成為職場搶手的人才，哪些態度該追求，哪些又是老闆眼中最討厭的爛個性？《Cheers》雜誌特地走訪各行各業的CEO，與他們深談在管理、帶人上的最大難題，歸納出你不可不知道的「阻礙升遷的10個小人」。

從管理階層的角度來看這10個「上班族之惡」，目的並不在膨脹企業主特殊的用人喜惡。事實上，接受採訪的CEO，莫不都是以過來人的智慧，對白領階級的思考盲點提出深刻反省。每一點都呼應著職場生態的變遷，還有企業對人才的期望。

分析他們的「最惡」，有幾點發現：

從「績效」競爭到「心」的競爭
首先，能力的競爭已經成為基本門檻，而且專業不足，可以透過各種工具、訓練補強。但如同104人力銀行董事長楊基寬特別強調的：「心的能力無法量化」。態度、人格、價值觀這些內蘊又難以靠外力改變的特質，如今更深深左右企業主對人才的取捨。

為什麼「心」的因素如此重要？因為企業普遍發現，白領成長鈍化的瓶頸，愈來愈少落在知識技能上，「影響力」才是關鍵。

從「獲得職位」到「贏得尊敬」
沒有影響力，光靠單打獨鬥，個人很難持續擴大對組織的價值，更不要說順利晉升為管理的角色。然而，影響力卻未必直接跟權力畫上等號。聯強國際總裁暨執行長杜書伍即指出：「公司可以給一個人職位，但不能給他來自同仁的尊敬。」

更進一步，「能力強只是正面的加分；但性格上的缺點帶給別人的負面印象，卻會產生很大的減分效應，」杜書伍分析。態度對個人的殺傷力遠超過能力。

不過，很多上班族之所以會出現負面心態徵候群，正是因為實力不夠，心中又有不安全感作祟。兩相交互作用的結果，反而讓自己成為主管眼中的「最惡」。

從「消極」抗拒到「主動」出擊
上班族要克服這些惡狀，唯有主動出擊，從能力、態度雙管齊下，建立自己的優勢，才能徹底擺脫負面循環。

今天的白領，確實面臨比以往更嚴厲的工作挑戰。透過10位CEO的心得分享，猶如提供一面明鏡，為上班族照出自我惕厲、趨吉避凶的方向。

Book: Word 排版藝術

I have not yet meet anyone who can honestly claim that he/she can master everything in MS Word; however us knowledge workers have been use it so often that we should know better (regardless you like Word or not, as long you use it).

Word processing is definitely a under-minded, but most-to-have basic skill. This book 《Word 排版藝術》(in traditional Chinese) is worth the money to put on the shelf. For experienced users, the book describes those more advanced skills you might already know. By having the book, those skills become a "sure thing". You become a true professional who know how to use the software in a professional way (To be honest, I am sure you will pick up some tips that you did not know before).

For those who is yet a powered user, this is a must read book. From secretary, proposal writer, engineer, or book writer, as long you need to word-processing, I am sure you will learn the more then needed skill and for sure it will pay back some other days.

In short, unless you will never use M$ Word, study on and get serious with what you're doing in document production.

網站互動技術的進展

CNET授權採用NYTimes文章：James Fallows‧郭文興譯　　2005/05/26

每個上網的人一定都有過這種讓人喪氣的類似經驗。

上星期我在美國明州阿坡里市，由於飛機誤點而要多等三個小時，這還不是讓人喪氣的地方。真正令人喪氣的，是我想用手提電腦連上機場提供的無線網路。要連上這個無線網路，必須要在螢幕上填寫一個註冊表單，要填上姓名、住址、電話、電子郵件、信用卡訊息，以及在網路上要使用的名稱。

我按下「送出」鍵──兩秒以後系統回應說已經有人使用這個使用者名稱，可能是其他人用了，也或許是自己上次來過這個鬼地方可是我忘了。但因為表單的所有欄位又變成空白，我必須把整個填過的表單重填一次，然後祈禱下次我選的名字可以用。

這種不便在某種程度上反映了網頁設計的怠惰與未完成。多年前程式設計者就已經知道要使用
「系統快取」或「系統暫存」功能。輸入的資訊裡面，除了那些造成問題的欄位之外，比如我選的使用者名稱，與需要保護的欄位，比如密碼或信用卡號等等之外，都應該要存到快取跟暫存裡面。不使用這種快取功能，而草率製造的網頁，數量多到令人沮喪。你一定也碰過這種要改任何輸入文字時需要整個重來的網頁。

但是在機場遇到的這個小問題，讓人聯想到使用網頁的基本概念。一直以來，網頁的使用都是網際網路的最大限制之一，但已經有很不錯的跡象顯示目前的狀況將要改變。

網站的互動功能，可以說是一種古早時代冗長流程的現代快速版本。舉例來說，如果你到公家機關或銀行辦事，你填好一張表格拿給職員或出納，最終會得到一些回應。這就是目前大多數網站的工作方式。你在網頁上輸入資料，借由按下「輸入」或「繼續」，或是按下某個連結，將資料送給遠端的電腦。最後電腦會回傳一些資訊。所送回的網頁往往像是你從職員那裡拿回的表格一樣是靜態的。如果你想要更多其他資訊-比如新的搜尋結果，或在其他日期的其他航班-你就必須要送出另一個要求，等待另一個回應。

這些浪費的時間雖然並非真的很多。但在只有幾項資料要改變，就必須要重傳整頁資料的這種情況下，的確會消磨使用者上網的動力。這種問答式的流程會讓人想到古早時期，將資料送到大型工作站等待其處理的情形。在目前的網站上，至少有一半以上放在「購物籃」裡的商品從未結帳。原因之一便是傳統的網站結帳流程十分累贅麻煩。

最近這三個月來，一些現存的相關技術，給予了網站全新感受，因而造成網路上一些騷動。要看看這些騷動所為何來，最簡單的辦法就是上Google Maps去看看。

在網站maps.google.com上，你可以看到美國境內任何一處的衛星照片。然後你可以按住地圖，往東邊或西邊捲動，也可以使用左右鍵達到同樣效果。大多數的地圖程式裡，當你捲動範圍超出原來地圖邊界時，就必須要暫停等待網站傳回該區域的資料。但如果使用Google的地圖程式，你可以持續向東或向西捲動，可以超出任何範圍，也可以在任何地點縮放。雖然該地圖的精密度依地點而異，但使用的經驗讓使用者感覺像是在登入時就已經收到所有地圖一樣的流暢。
當然該網站並不可能真的如此做。這個系統其實使用了兩個基本的技巧，讓他看起來像是你在電腦上擁有所有的地圖資訊。第一個技巧是非同步的資料更新-就是在系統等待你送出新的要求時，會將你可能要求的資料都先預存至你的電腦，比方目前地圖的邊緣部份。另一個技巧就是選擇性的更新資料，系統只更改跟目前資料不同的部分，而不是重新讀取整個網頁。

以這兩個技術作為主體，然後再與其他元件整合的網頁設計方法，在二月時，被顧問公司Adaptive Path的Jesse James Garrett命名為Ajax技術。然而該名稱本身就有極大的爭議。雖然該名稱在三月的華爾街日報上就已眾所皆知。但軟體公司Macromedia的副總David Mendels表示應該要叫「Rich Internet Applications」(多樣化網際網路應用)，而Google的專案管理總監Georges Hank認為應該要叫「Rich Web Application」。微軟平台策略部的總經理Charles Fitzgerald則表示，這樣一個聰明的工程師早已使用多年的工具，並不需要一個特定的名稱。不管名稱為何，所有相關的軟體陣營似乎都同意兩件事。

第一件事就是，「較多樣化的」網站可以提供更加滿意的使用經驗，不只限於給線上購物使用。Macromedia公司提供類似於Ajax的Flash技術，該公司的副總Mendels舉了幾個實例，比如油漆公司Serwin-Williams的網站，使用者在網頁上調出顏料的各種色調，看看這些顏料塗到他們房子的門窗上面後看起來如何。

總而言之，他強調使用這些「較多樣化的」網站的感受，會變得愈來愈像在你自己的電腦上面執行程式一樣。舉例來說，Gmail，也就是Google的電子郵件服務，現在可以執行更多複雜的郵件編輯功能，而購物網站也可以在使用者更新資料時，立即重新計算總價跟運送的費用，就好像電腦裡的試算表一樣。這個技術的關鍵就在於網頁會自動的更新，而且只有特定的部分會改變。而對在機場的我來說，若網頁使用了該種技術，便可以在我嘗試使用者名稱時立即顯示該名稱是被允許或拒絕，而不會影響到螢幕上其他欄位的資料。

大家所同意的另一點，就是瀏覽器市場的差異性──Internet Explorer，Firefox，Opera跟其他的瀏覽器，讓設置一個可以在每種瀏覽器上運作的「多樣化」工具難上加難。而Mendels認為解答就是他們公司可以在任何平台上執行的Flash技術。而微軟的Fitzgerald則表示解答是被包含在下一版視窗Longhorn的一組執行工具Avalon裡面。接下來一定會有愈來愈多關於這種競爭──不管是使用者方面或是公司方面的競爭──的新聞報導。

最後則是關於Google空照圖的相關資訊。上個月我提到有小部分的美國國土照片反常的模糊。模糊的地方並不是美國中情區的總部（中情區總部的照片清楚到可以看到停車場車輛的顏色）。也不是堤防或是電廠等等神秘的區域。地圖的有些地方比較清楚，有些地方比較模糊，是因為衛星照片的品質會依地點而有所不同。

而美國白宮與兩棟相鄰建築的屋頂，的確被使用影像軟體Photoshop處理過，以隱藏保護系統的所在位置。而州議會大廈的外觀也經過模糊處理，但整個輪廓還是相當清楚。但是如果你想看看真正的偽裝長什麼樣子，可以將華盛頓特區的Observatory Circle部分放大，那是副總統Dick Cheney的住所。

千金難買早知道 - 台灣7-ELEVEN創新行銷學

多年前的某一天，一家7-ELEVEN在營業時間快結束時，因鐵捲門故障而無法順利打烊，只好繼續營業，萬萬沒有想到夜間的生意反而特別好，自此7-ELEVEN決定將營業時間改為24小時營業，終年不打烊。

7-ELEVEN由一個小小的意外，成就另一個新的商業模式，若沒有鐵捲門故障事件，也許到現在都還是11點打烊。

喜歡在一成不變的生活中來點不同的刺激嗎？有時候需要冒一點風險，試著以不同的方法去完成同樣的一件事，可能會產生迥然不同的結果。若結果不能改變，至少在經歷的過程中會有新的體會。

你每天是如何去上班的？試著開發新的交通路線，也許會意外的發現某些景象，比如發覺一家新奇的商店或某條更便捷的路線，類似的事不妨多多嘗試。

改變從小事出發，是因為小事所要承受的風險較低，能放鬆心情去做，從中慢慢培養更多的彈性，久而久之，你會驚覺自己比過去靈活許多。這是個很重要的練習，因為社會變化太快，我們需要因應許多意想不到的挑戰，而應戰的基本之道就是拓展個人的彈性。

有時生活上意外的改變會帶來意外的收穫，所謂無心插柳柳成蔭，就如同7-ELEVEN的故事一般，當天值班的那位店長可能會覺得自己很倒楣，無法準時下班，這件事卻對整個7-ELEVEN的營運有很大的突破。

「千金難買早知道」，就是因為無法預知，所以當困難、挑戰迎面而來時，一般人自然會選擇閃避。若在平常多練習擴展自己的舒適圈、增加自己的彈性，相對的，抗拒心就會減少許多，取而代之的是想出因應對策。這是一種化被動為主動的思考模式，當練習愈多時，個人的適應力就愈來愈強，解決問題的能力也會愈來愈進步，對自信心的增強很有幫助。

Seymour Cray, Technical Wizards Behind the Supercomputer -> 超級電腦幕後英雄

Seymour R. Cray, a computer industry pioneer and the father of the supercomputer, posed with the Cray 3 supercomputer at Cray Computer Corp. company headquarters in 1994.

對程式設計人員來說，希穆爾克雷(Seymour Cray)是一位巨人。克雷極少發表演說，1976年他在科羅拉多州的國家大氣研究中心對程式設計人員發表演說，並同意演說結束後答覆詢問。只見會後整個會場突然沈寂下來，克雷在講台上站了好幾分鐘，等待程式人員提問，但沒有人發問。等到克雷離去以後，大氣研究中心電腦部負責人責備在場的程式人員：「為什麼沒有舉手發問？」經過一陣令人不安的沈默，一位程式師終於回答：「要你對上帝說話，你敢嗎？」

超級電腦的發明對於電腦的發展歷史來說，是一項重大的里程碑。本書敘述超級電腦的發明人克雷及他的工作小組，如何在電腦工業發展的初期，突破科學上的限制，與公司的官僚體系抗衡，進而奠定資訊時代的基石。

Cray-1, Cray's first supercomputer. Introduced in 1976, this system had a peak performance of 133 megaflops. The first system was installed at Los Alamos National Laboratory.

Cray Y-MP8DIntroduced in 1988, this system was key to breaking the one gigaflop performance barrier. It has traditionally been the standard by which other supercomputers are compared.

The Supermen : The Story of Seymour Cray and the Technical Wizards Behind the Supercomputer
by Charles J. Murray

Hardcover: 232 pages
Publisher: Wiley (January, 1997)
ISBN: 0471048852

Editorial Reviews

Amazon.com
The story of supercomputing is only partially about technology. More than anything, it's about the gifted, brilliant, and often eccentric individuals who knew how to use that technology in new ways to do amazing things. Perhaps the most amazing of the bunch was Seymour Cray, the bureaucracy-intolerant genius with the barnstorming mind whose name has become synonymous with supercomputers. Charles Murray gives us an insightful and often thrilling and sometimes amusing look into how Cray and his genius companions took computers to new heights and humbled companies like Control Data and IBM....

Chinese Edition: 超級電腦幕後英雄
作者：
Charles J. Murray/著
譯者： 譚天
出版社： 遠流
初版日期：1999年01月01日

Mingster Reviews: Fun to read, recommended.

Related Links

1. Smart Computing Encyclopedia
   
2. Cray Computer FAQ
   
3. Cray-Cyber.org
   

The Art of Project Management

The Art of Project Management（中譯本《專案管理之美學》）是作者Scott Berkun根據多年的經驗，以平鋪直敘的方式敘述他的經驗。其中多數屬實務經驗，如lesson learned、以及依據實務經驗所發展出的專案管理的信念和理論。

Scott的工作經驗多數來自於IT界。Scott在Microsoft工作近十年，領導團隊開發軟體專案，如Internet Explorer瀏覽器、Windows作業系統、及MSN服務。Scott 也常受邀在各公開及學院發表演說、提供諮詢顧問服務，是實戰的人物。

要讓一件事情有條不紊地邁向成功，重點不在專業知識、技術、或理論，而是在project management。本書是這些寶貴經驗的知識總整理，內容包括領導團隊的技巧、引導團隊集思廣益的方法、組織專案、管理進度、應付政治、以讓專案平順等務實的技巧。

專案管理應是通識。大至蓋台北101、開發新款汽車、創業，小至規畫一個成功的home party，專案管理知識皆可派上用場。本書提供很大的價值，建議直接閱讀本書的英文版。

Book Review: 微笑禿鷹

垃圾可以變黃金，麻雀有望成鳳凰，只要被專業創投相中，瀕臨關門大吉的公司，也可以轉化為成功的上市公司。

微笑禿鷹以故事方式敘述作者在創投界的經驗，以及與許多創投同業往來的過程。情節生動，高潮迭起，非常有趣。

The Mythical Man-Month (人月神話)

by Frederick P. Brooks (Paperback)
Addison-Wesley Professional; 1st edition (August 2, 1995)

Editorial Reviews

Amazon.com
The classic book on the human elements of software engineering. Software tools and development environments may have changed in the 21 years since the first edition of this book, but the peculiarly nonlinear economies of scale in collaborative work and the nature of individuals and groups has not changed an epsilon. If you write code or depend upon those who do, get this book as soon as possible -- from Amazon.com Books, your library, or anyone else. You (and/or your colleagues) will be forever grateful. Very Highest Recommendation.

From Book News, Inc.
The 20th anniversary edition of this classic collection of essays on software engineering and managing complex projects includes revised material, and new chapters condensing the author's original propositions and his views 20 years later, plus a reprint of his 1986 paper "No Silver Bullet," and his recent comments on that essay. Brooks' central argument is that large programming projects suffer different management problems from small ones due to the division of labor, and that conceptual integrity of the product is critical. Annotation copyright Book News, Inc. Portland, Or.

軟體業永遠的神話

軟體工程堪稱變化最快速的行業，過去幾十年來，我們看盡各種軟體神話如驚濤駭浪襲捲而來，轉瞬間就被另一波浪濤殲滅無蹤影。在這樣的景況裡，若有什麼事物是可以歷久仍彌新，那就不僅僅是異數，而是神話，值得你駐足瞻仰了。

《人月神話》就是這樣一本書。原是佛瑞德‧布魯克斯為開發IBM史無前例的巨型軟體系統「OS/360」所寫的專案總結報告，1975年出版迄今，近30年來幾已成為程式設計工作者人手一冊的必讀經典。時至今日，大型複雜軟體的開發與應用，更加緊密地牽動各個層面，也益發彰顯此書的價值，特別是對所有工作環節涉及程式設計這一領域的人，如專案經理，甚至連IT產業的領導者如摩托羅拉對這本書也大力推崇。

簡而言之，《人月神話》談的是軟體開發專案管理的所有方方面面的問題。3個人4個月的工作絕不等於12個人1個月的工作（這也是本書書名的由來），那為什麼進度落後時大家還是直覺反應加人呢？

既然布魯克斯在1975年就已經討論了克服時間壓力和團隊合作之間矛盾的有效方法，為什麼今天產品開發中屢屢延期交付仍是常態呢？

既然布魯克斯早就提醒過我們要注意軟體發展中普遍存在和頻繁出現的目標捨棄、功能調整、預算緊縮等變數，為什麼在專案計畫階段大家還保持樂觀，蔑視一切潛在的風險呢？（文/桑加米卓）

建置成功網站的關鍵因素

就像名片，網站已成為企業必備的配備。在您投入金錢與時間前，您了解如何建置成功的網站嗎? 如果你要建置一個成功的，能長時間保持運作的企業網站，請慎重考慮下列問題。
1. 為什麼要建置它？
明暸企業目標以及網站需求。從目標和需求著手，找出何種的資訊對你的客戶(網站瀏覽者)有幫助。了解你對網站設計及網站內容之願景及構想。經由此分析，你能更有效的規劃需求、預算，並製造出滿意的網站。

2. 你對成功網站的定義
建置一個網站，就像辦一本雜誌，從定位開始，到版型、內容、團隊必須顧到品質、預算、成敗控管，但不像雜誌印刷出版就沒事了，對網站而言，日後更新維護是更重要的，因此網站的規劃團隊一開始就要做出正確的網站定位、選擇最好的網站建置軟體、並籌畫建置的人才及日後維護的方式，甚至是要從使用者角度出發，了解使用者想要的資訊、點選的習慣、預期看到什麼頁面， 要有明確的設計讓使用者節省更多的精神、時間，網站瀏覽介面要友善化，後端維護要相對簡單化。
問主事者[1]這個問題：若您第一次瀏覽新網站，您希望留下何種印象？
[1] 主事者通常為此專案的利益關係人及決策者，如企業主或行銷部門主管。

3. 建置的目的到底為何?
依據定義製作出需求，您將可清楚的分析出建置的目的。
例如，在製作行銷策略時，如果你知道客戶要的是什麼，那麼你就可以做更好的服務以滿足他們的需求。之於網站建置，如果你有預設瀏覽的族群，你就可定義網站的訴求目標、清楚勾勒出建置的目的及效應。這將導引您做出更好的決策，真正利用網站提供更佳的服務。

4. 成本考量
很多的客戶有對架設網站有不同的看法，以為將很多的資料放上去就好了，但經驗告訴我們簡單的網頁設計不止可以降低您的預算也可以讓網站的訪客快速找到他們想要的資料。

5. 是否一定以價錢的原因來選擇網頁設計公司？
網頁設計的產業是一個很速成的產業，充滿了很多不專業的公司，一個人一台電腦就能做網頁設計，他們的設計費通常很便宜，但並不能提供完整的服務。選擇一個真正專業且有經驗的網站建置團隊會比純粹比價重要的多。

6. 如何選擇一個好的團隊?
依據您定義出的需求，您可分析出網站建置團隊應具備的職能素養。

一般具有專業且有經驗的網站建置團隊，應須有下列表現：

比重	標準
0-05	網頁設計公司自已網站的品質
0-30 0-20 0-10	他們作品網站的品質 你相信的人給的參考意見 作品網站跟你想要網站的相似程度(設計上、製作上或功能上
0-50 0-20	有能力提出策略與投入的方式 整體設計力、整體技術力 轉發包特殊工作(攝影、程式設計、配音等)能力
0-30	為現在或未來瀏覽器設計網站的能力
0-10	吸引人潮入站的能力
0-30	技術能力：例如，自已能不能寫perl或其它伺服器端的scripts 壓縮技術、Shockwave動畫、Flash等技術
0-30	領導者在其它媒體是資深設計師
0-30	對專案的整體熱忱
0-50	希望跟他們共事的程度

精確的企劃，造就完美的網站

對大部份企業而言，網站不可能企劃幾個月、建置幾個月、再聘用專職人員維護。因此，前置作業的規劃，精確找出網站的訴求及範疇、謹慎的專案計畫、在每個階段做評估，皆為成功又符合預算的網站專案執行要點。

Book Review: 老大老二老三

本書是作者的二本舊作及一本新作修訂合集而成的。

This book is a must have. It describes the 3 mixed positions using history as example, very fun to read yet it packs with a bag full of political knowledge.

Debug by 蔡學鏞

以下轉載自 Debug本文作者：蔡學鏞張貼日期：05/16/2002

Debug
吃燒餅不免會掉芝麻，寫程式不免會有 bug。再怎麼高明的程式員，也不敢保證寫出來的程式不會有 bug。當發現程式有誤，bug 隱身其中時，就是 debugger 出動的時候了。越是高明的程式員，越是能夠靈巧地使用 debugger，讓 bug 無所遁形。

Debug 的過程分成兩個步驟：
1. 找到 bug 所在地
2. 修正 bug

事實上，真正困難的地方在第一點，如果你能找到 bug 所在地，應該就知道怎麼修正 bug 了。本文章簡單地介紹 debugger 的用法，希望你再次遇到 bug 時，能夠不慌不忙地把這些技巧派上用場。

調整步伐
最不花腦筋的 debug 方式就是：逐行執行，每執行一行程式碼就暫停，立刻觀察這一行的執行結果是否如你所預期，沒問題的話就繼續執行下一行。

當你在逐行執行的時候，如果遇到了 method invocation（函式呼叫），你可以選擇要跳進此 method 或者不跳進此 method。欲跳進此 method，就使用 step in；欲一口氣執行完此 method，就使用 step over。至於要不要跳進去，你可以有自己的考量。一般來說，如果你認定該 method 應該不會有問題時，你就使用 step over，否則使用 step in。

如果已經在某 method 內，但是認為此 method 後面的程式碼不會有 bug，你可以透過 step out 來往上跳，跳離開這個 method。

在 debug 的時候，前進的步伐很重要，step over、step in、step out 三者必須好好搭配使用，才不會「自亂陣腳」。

控制疏密
光靠上面三種 step 方式，要找到 bug，就如同海底撈針一樣，並不容易。你還需要 breakpoint（中斷點）的輔助。

你應該先透過經驗來判斷，bug 最有可能出現在哪些地方。然後在這些地方的前後分別設定 breakpoint。為了加快 debug 的速度，我們經常同時在程式中設定多個中斷點。

在 debug 模式下執行程式時，遇到中斷點，程式就會暫停，我們可以利用這個機會檢視目前的執行結果是否符合預期，如果有差池的話，就表示剛才執行過的程式碼有問題，你已經找到了 bug 的區域，立刻停止此次的 debug 執行模式。接著再重來一次，繼續縮小範圍。當範圍已經很小時，可以改用 step 的方式來找 bug。

分析觀察
不管是導因於 breakpoint 或 step，程式在 debug 模式下暫停時，我們都需要「觀察」（watch）程式目前的狀態（state），據以判斷方才的執行過程有無錯誤。程式狀態其實就是資料的集合，所以我們的「觀察」對象就是程式中的變數值。Debug 工具可以讓我們很方便地觀察程式中各個變數的值，有些 debug 工具還可以讓我們輸入由變數組成的計算式（expression），輸出計算結果以方便我們觀察。

某些 debugger 甚至具有修改變數值的功能，可以讓你在程式暫停時，修改程式狀態，然後繼續執行。

理清頭緒

對於多執行緒（multi-thread）程式，debugger 依然能進行上述的 step、breakpoint、watch。通常 debugger 會在 watch 視窗中以樹狀結構區分出執行緒，然後才個別列出各個執行緒的區域變數，以免混淆。

為了因應撰寫 client/server 程式的需求，有些 debug 工具甚至可以同時幫助多個 process 進行除錯。

隔空抓藥
「捎來藥丸的，可是白鬍子的老公公？」我們姑且相信這個妖婦的確具備隔空抓藥的本事，但提到這樣的本事，許多 debugger 也不遑多讓。越來越多的 debugger 開始支援 remote debugging，讓程式員可以在一部 PC 上，debug 另一部 PC 上的程式。

以 Java 來說，早期 VisualCafe 就提供了自己專屬的 remote agent，來達到 remote debugging 的功能。現在，Sun 的 JVM 都支援 JVMDI（Java VM Debug Interface）以及 JDWP（Java Debug Wire Protocol），所以想設計出一個能隔空抓藥的標準 remote debugger 也不難，主流的 Java 開發工具也開始支援 remote debugging。

de 程式中的 bug，也 de 生活中的 bug

我們除了 de 程式中的 bug，也要 de 生活中的 bug（竊聽器也被稱做 bug）。中國大陸國家主席江澤民的波音 747-300R 座機被裝滿 bug，美鳳姊姊的座車和手機內也被裝了 bug。越是重要的人，周遭的 bug 就會越多，越是需要常常進行 debug。

如果無法確定生活中毫無 bug，請各位務必要做最壞的打算，試圖干擾任何可能存在的 bug，作法很簡單，例如：放大電視機音量、關燈，都很有效。那也就是為什麼，我向親近好友坦承「關燈版」的男主角其實就是我，至今仍然沒有人相信的緣故。