Mercurial 的 Windows 使用者應該要注意 \r 的問題

目前常見的作業系統有 Solaris, Ubuntu Linux, Fedora Linux, FreeBSD, XXX Linux, YYY BSD, Mac OS X 及 Windows ，而這些系統中，除了 Windows 的換行符號是用 \r\n 外，其他的都是用 \n 。

所以當 Windows 使用者將他們的程式碼上傳至版本控制器時，換行符號會以 \r\n 為主，然後我們其他使用 Mac OS X 及 Ubuntu Linux 的人，在上傳程式碼時，又可能會將換行符號換成 \n ，那麼在作版本比對的時候，只差 \r 的資料行也秀出來了，這實在不利於比對效率。不過這一點， NetBeans 倒是聰明地將只差 \r 及空白的資料行作忽略。

但話說回來，有時候，我們是在遠端 ssh 連線下，作設定檔或是程式碼的比對，這時候，如果出現一堆 ^M 符號也是挻困惱的。

所以這時候，就要請 Windows 使用者多作一個設定，讓他們在 push 檔案時，能自動將 \r 移除。

如果你安裝的是 TortoiseHg ，那麼請到你的安裝目錄下找一個 Mercurial.ini 的檔案，把它打開，加入下列內容：

[extensions]

hgext.win32text=

[encode]
** = cleverencode:

[decode]
** = cleverdecode:

[patch]
eol = crlf

[hooks]
pretxncommit.crlf = python:hgext.win32text.forbidcrlf

一般而言， extensions, encode, decode 區塊是預設就有的，只是需要移除註解，而 patch, hooks 則是自行增加。

這樣以後在作 push 時， hg 會事先把 \r 移除才送出去。

專案程式碼不得不兩線並進時， Mercurial 的簡單因應策略為何?

最近，我們的系統要作二周的使用者教育訓練，且接受他們的回饋意見，而系統功能離真正的完工還有一段小距離，因為他們可能會提出一些新的想法，若可行性高的話，我們也會把功能實作上去。

而這種「兩線並進」的程式碼維護該如何處理? 因為我們使用的是分散式版本控制器，所以這策略可分簡單及進階方法兩種，當然啦，進階方法必定有優點比簡單方法多一點，要不然，大家都用簡單方法不就得了。

首先，我們要先了解為什麼會有「兩線並進」的現象發生。

在作系統展示及教育訓練的時候，有可能會面臨到第一次出現的 bug ，因為這時候所輸入的資料、操作流程會因使用者的真實需求而與我們開發者在測試階段有所不同，造成我們會有 debug 的需求。但在這二周之間，除了去作教育訓練的人外，其他沒去的開發者會繼續作其他功能的設計，那系統程式碼也會有因新增功能而產生的修改。

那如果兩者所新增、修改的程式碼都在同一個儲存庫中，那是不是一定會發生開發者寫的新功能變成教育訓練時的新 bug 呢! 我相信會的。

所以這時候，一定要用兩線各自獨立運作的方式，才會避免雙方互挖牆腳。

首先介紹簡單方法：

在展示主機上，先作 hg clone ，得到一個 xxx 專案資料夾，然後再作一次 hg clone xxx xxx-bugfix 。這時候，我們使用 xxx-bugfix 來作系統展示之用，如果有 bug 的話，也直接修改在這個 xxx-bugfix 專案中，並把這些修改 push 回到 xxx 之中，而在 xxx 之中，我們則是作新功能(從伺服器 pull -u 來的)及 fixed bug 的合併。合併後再整個 push 回程式碼伺服器上。這樣一來，訓練者所作的 bug fix 也可以讓開發者獲得，而開發者寫的新功能不會影響訓練者使用的展示系統。

以上方法的確可以滿足「兩線並進」的需求，然而它有一些麻煩的事要處理，當訓練者在作 bug fix 時，他要不是在展示主機上直接修改，要不然就是把展示主機的 xxx-bugfix 抓回自己的電腦來處理，改回後，再放回展示主機，這造成了另一個問題，如果訓練者有兩個以上，而他們同時要作 bug fix 呢! 又回到 copy 的時光了，要不然就是在展示主機上再搞一個程式碼伺服器讓 xxx-bugfix 可以變成多人合作的 debug 專案。

Mercurial 的分散式架構讓「兩線並進策略」變得非常簡單，但如果只用了這一招，這有點小看了 Mercurial 的強大。

下節我將介紹使用 branch, merge 指令實現「兩線並進策略」。

莫明奇妙的 _ 網域名稱錯誤： 只發生在 IE 上

嚴格地說，這也不是 IE 的錯， IE 只是遵守規範而已。但是因為 Firefox 的容錯能力，讓我們一時以為是 IE 太爛了。

問題是這樣的：

我學弟使用 Windows 加 apache 配置一個測試網站給業主使用時，一直面臨 IE 不能登入，但 Firefox 卻正常的問題，而該網站在 django development server 運作時，卻又沒有問題。他搞了非常久，大概有一個月吧!

我幫他 debug 時，一開始，我就把問題縮小在 IE 瀏覽這 apache 上的測試網站時，它不會紀錄 Cookies，沒用 Cookies ，那怎麼保持認證連線呢! 只是那時候，我也是找不出為什麼那該死的 IE 就是沒法使用 Cookies ，而優秀的 Firefox 就可以呢! 然後，我使用了 Ubuntu Linux 配置這個測試網站結果發現它可以讓 IE 正常運作，所以我們當時只能歸納這問題，一定是他的 XP 出了狀況。

結果前兩天，他要把測試網站放到業主的機器上去 run 時，還是出了相同的問題，然而這次不一樣的是那個機器有兩個 django-based site ，但一個正常，一個不正常。這就有點說不過去了。

於是，這次我請教了 Google 大神，問它： django cookie session problem ie ，而它回我： http://code.djangoproject.com/ticket/7264#comment:3。

這原來是 _ 的錯，因為學弟習慣將測試網址設成 test_XXX.YYY.ZZZ ，而我習慣設成 XXXtest.YYY.ZZZ ，因為我知道在買網址時只可以買英數字加連字詞(-)的，所以我不會在網域名稱中放入 _ ，也就是這個習慣讓我在 Ubuntu Linux 中架的測試網站是可以讓 IE 正常使用，但學弟架在 Windows 上的測試網址卻包含了 _ ，讓 IE 勇於拒絕他的要求了。

這同時也解釋了為什麼在 django development server 運作時， IE 可以正常的現象，因為它會使用 http://127.0.0.1:8000/ 作瀏覽網址。

哈哈，真不曉得該怪 IE ，還是得怪 Firefox 呢! 不過，話說回來，要是早點問 Google 大神，這問題就不會拖一個月了。

今天(2009-11-19)我騎了 20 km 以及跑了 5 km

自行車練習是在一條 2 公里的迴圈道路上騎 10 次完成的，它有 1 公里的 3 % 上昇坡道。而路跑部份則是一條多半上坡的單向道路，確實坡度未紀錄。

自行車花的時間是 57 分(+59 / -58 s); 路跑則是 32分(+59 / -58 s)。

為什麼計時誤差這麼大呢? 因為今天我是臨時起意作這件事的，所以我身上只帶 Palm treo 650 。

先記下來，將來好作進度程度的比較，以及定下明確的訓練目標。

多買了一本書： 「Companion to The Triathlete's Training Bible」

這次所購買的鐵人三項相關書籍中，有包含「Companion to The Triathlete's Training Bible」及「The Triathlete's Training Bible third edition」二本 Joe Friel 寫的書。而這本書「Companion to The Triathlete's Training Bible」在 Amazon 網頁的 Frequently Bought Together 區塊也清楚地表明大家都會和 Going Long 一起買，且就書名來看，你當然會覺得它一定和「The Triathlete's Training Bible third edition」這本書是一對的。

然而不是。

「Companion to The Triathlete's Training Bible」這本書和第二版的「The Triathlete's Training Bible」才是一對的，是作者要讓已買過第二版的人，可以不用多花錢去買第三版，只要買「Companion to The Triathlete's Training Bible」這本書即可。

由此看得出來 Amazon 真的只會賣書，它不懂書呀! 我已在 Customer Review 留了言，提醒大家。

雖然 B&N 也在 Customers who bought this also bought 區塊秀出大家都會和第三版的三鐵訓練聖經一起買，然而這多半是顧客自己的錯，因為 B&N 在編輯者檢視中已明確跟大家說：

From the Publisher

If you use the second edition of The Triathlete's Training Bible to guide your training, there's good news: This Companion will quickly bring you up to speed with the most important advances in the sport.

唉~害我多花了 9.95 + 4.99 / 7 + 4.99 元美金。不知誰買的是第二版的 The Triathlete's Training Bible ，我便宜半價再加上國內郵寄運費也就是 280 元台幣賣給你吧!

真是運氣呀! 群創併奇美，我反而將是群創的股東了。

引自： 群創與奇美電宣布合併 換股比例 1：2.05 群創為存續公司(http://tw.stock.yahoo.com/news_content/url/d/a/091114/2/1rlke.html)

之前我本來就要買群創，到不是我多看好它，而是它是台灣 50 的成員之一，本來我連它跟面板有關係都不曉得，後來知道了，卻也覺得為難，因為友達、奇美也都是台灣 50 的成員，這麼一來，我都投資的話，面板業在我的投資比例上就有些偏高，就像之前台灣 50 也有一堆 DRAM 股一樣。

後來在某個買股的時間點上，我選擇了 43 元的華碩，而沒選擇 36 元的群創，因為我的資金有限一次只能買一支股票，而且還是買零股呢! 結果下次要買時，群創就漲上去了，那我就不想買了，反正我的口袋名單還很長，以後再說吧! 就這樣一直等，等我買了奇美電後，還是沒買它。

但是現在好啦! 群創併奇美，我的口袋名單少一個面板業的公司。而且換算回來，我大約是在 36.8 元買到 487 股的群創，距離我當初要用 36 元買 500 股差不多啦! 真是運氣呀!

已通過博士資格考

2009 年 10 月中旬，依據中興大學土木工程學系博士學位候選人資格考核相關辦法, 我考了三門科目： 營建作業研究特論、環境系統分析、期貨與選擇權。我們系所的規定是這樣的，在修習完規定的 24 學分後，也就是 8 門三學分的課，可以任選不同老師的課程，總共三門課來考試，而我所修的 8 門課如下(依修課時間)：

• 土木系： 營建作業研究特論、營建決策支援系統
• 資工系： 資料挖掘、高等資料挖掘
• 資管系： 軟體品質保證
• 企管系： 動態競爭策略
• 環工系： 環境系統分析
• 財金系： 期貨與選擇權

只有兩門課是我的指導教授開的，也是惟二的土木系所課程，其他的科目都是到外系去修，會有這個現象乃是中興土木營管組只有一名老師，而營管組的屬性又與結構、大地、測量、水利等組相當不同，以所應用的數學科目來說，別的組常用到微積分、工程數學，而我們卻比較常用離散數學、作業研究，但統計學則是大家偶爾都會用到。

所以，我所挑選的三門課中，有二門一定會是外系的，其中一門是環工系，另一門是財金系，挑環工系老師的「環境系統分析」，別人不覺得突兀，畢竟大家都還是工學院的，而且在早期，中興的土木、環工是在一起的，後來才分家。但當我跟別人說我要考「期貨與選擇權」時，都會覺得這是件風馬牛不相及的事，是我特立獨行去修了這門課，還拿它來考資格考。

就讓我說說：「為什麼土木系營建管理組的學生會去修期貨與選擇權吧!」

「營建管理學科」是一種高度混合的應用科學，其定義是在營建相關領域探就其管理方法，而營建相關領域在應用對象上包含了營建專案、營建工地、營建相關公司(營造廠、建築師、建設公司、顧問公司、建經公司、PCM及業主管理單位)、營建事務主管機關(內政部營建署、公共工程委員會)等，而在管理方法分類上，一般可依管理學科領域分為產、銷、人、資、財。

• 產： 營建專案的工期、品質、成本管理…
• 銷： 預售屋、成屋銷售、客戶關係管理…
• 人： 工地人員、公司成員管理、公司間溝通介面管理…
• 資： 日報表資訊、施工管理網路化，營建事務決策支援系統，專案生命周期管理系統…
• 財： 專案可行性評估、預算編列、成本分析、價格預測…

以應用的管理技術來說，我只提出中興營管常用的幾個：

1. CPM、LSM 應用在專案排程上，這是屬於「產」的領域
2. 鋼筋揀料、裁切最佳化，這也是屬於「產」的領域
3. 最佳化方法決定塔吊位置、吊送任務排程，這是屬於「產」的領域
4. 電腦模擬施工流程，這是屬於「產」的領域
5. 日報表及施工管理網路化，這是屬於「資」的領域
6. 工程常見缺失關聯分析，這是屬於「資」的領域
7. 工程相關法律案例搜尋，這是屬於「資」的領域
8. 灰色理論應用於營建物價指數預測，這是屬於「財」的領域
9. 住宅附加價值對消費者之購買決策影響，這是屬於「銷」的領域

其他更詳細的應用方法，各位可參考我的指導教授所指導的論文得知。由此可見，我們中興營管組的專業領域是在「生產管理」及「資訊管理」上，而「財務管理」、「行銷管理」只佔了一小部份，「人資管理」則完全不踫。

原本我只是對「期貨與選擇權」有點興趣，但這不足以讓我決定去修一門課，畢竟我們老師也不是將重心放在「財務管理」上，直到 2008 年初發生了一件非常有趣的事： 營造公會上街頭遊行。

其原因是在營建物價的快速飆漲，致使廠商與公家機關所簽定之合約價格，不足以讓廠商可以完成施工。而爭議是在過去公家機關並不喜歡與廠商簽定物價調整條款，它們將市場價格波動的風險完全交由廠商自行負擔。

所謂市場價格風險有兩種情況，一、物價下跌，合約價格一樣，廠商可得額外利潤; 二、物價上漲，合約價格不變，廠商擔負額外成本。

所以當發生物價快速飆漲現象時，多數營造廠將面臨資本風險，就像期貨保證金過少，在市場價格急速波動下，被期貨商強制平倉，而這平倉對營造廠而言就是倒閉。因為營造廠們苦不堪言，加上當時又要選舉了，它們也就選擇上街抗議，希望政府給個「公道」。

但是站在「公家機關」的角色上來說，過去物價下跌致使廠商有超額利潤時，廠商也沒有把多出來的錢拿出來樂善好施一下，為什麼在物價上漲時，機關就得當冤大頭出這筆錢呢!甚或某些機關與廠商簽約中，即明定「物價波動風險由廠商自行負擔」，那現在又跑來吵，那如果真的給了這筆錢，絕對會被告「圖利廠商」。

這個問題給了我一個啟示： 工程契約即是期貨合約，而物價調整條款則是一個買權加上一個賣權。

我們以農產品期貨作例子，一口 100 頭美國活牛要求在 12 月的第三個星期三交割，其交易價格為 50 萬美金。其合約意義是指，買方現在就以 50 萬美金訂下了在 12 月的第三個星期三出現的 100 頭美國活牛; 而賣方則是在 12 月的第三個星期三把這 100 頭活牛交付給買方，並收款 50 萬美金。如果到了 12 月的第三個星期三時，當時市場上的 100 頭活牛價格是 51 萬美金，則代表買方帳面獲利 1 萬，而賣方帳面虧損 1 萬。另外在合約的詳細內容中，會明定這 100 頭活牛的品質檢測方法，如：重量、外觀、是否帶有病毒…等。

現在我們來看看一份工程合約內容有什麼：

1. 工程期限(交割日期)
2. 工程總價(期貨價格)
3. 驗收方法(品質檢測)
4. 其他…，如：保固責任、付款方式

除第 4 點外，一份工程合約是不是與一個農產品期貨合約類似。對機關而言，它就是一個期貨買方，它要求期貨賣方須在指定日期交與一工程產品(可能是橋梁、道路、大樓、晶圓廠…等)，而合約上會指明產品品質檢測方法(如橋梁強度、長度、路面平整度…等)，最後驗明無誤後，以工程總價支付給期貨賣方(也就是營造廠)。

所以一份沒有「物調條款」的工程契約它就類似一份期貨合約。而「物調條款」是什麼? 它通常是這樣規定的，若物價價格超過合約價的 1.05 倍時，機關須付出超過的部份，但當物價價格低於合約價的 0.95 倍時，廠商須扣減超過部份。也就是說一個 1 億的工程，當物價達到 1.2 億時，機關要多給廠商 1500 萬; 而當物價下跌至 7000 萬時，廠商所請款的總額只能夠是 7500 萬。

這 1.05 倍合約價格即是買權的履約價，而 0.95 倍合約價格則是賣權的履約價。當一份工程合約內簽有物調條款時，即代表機關是期貨買方、買權賣方及賣權買方; 而營造廠則是期貨賣方、買權買方及賣權賣方。

說到這裡，是不是覺得營建管理學生修「期貨與選擇權」是一件非常平常的事了。

那麼我將在下節(未完成)說明如何用「選擇權」來解決物調爭議。