MaoYang-有話要說

敏捷開發(Agile Development)實戰經驗分享會

2009-10-19T11:34:00.002+08:00

工商廣告時間, 我們公司於10/24號邀請了同人與柯仁傑來分享敏捷開發的實戰經驗, 詳細報名請參考http://cb.esast.com/cb/wiki/9402這個研討會的緣由, 是看到了ITHome專訪同人的一篇報導, 裡面有談到同人Agile專案管理的經驗,剛好公司也有計劃邀請具有軟體專案管理相關經驗的講師來分享真實的業界經驗, 不再紙上談兵, 在一次通達人的網友聚會, 我當面跟同人提出這個邀請, 同人當下就答應了,並介紹了柯仁傑給我們認識, 所以這次的研討會我本身也相當期待, Agile Development的書買了, 但是總覺的跟實務有一段距離. 這是算是相當難得的機會同時可以聽到Scrum與XP(extreme programming)的經驗, 有興趣的網友, 歡迎來參加與討論!

GanttProject+CodeBeamer==專案規劃與追蹤

2009-10-16T16:43:00.003+08:00

大約4年前, 我曾經去修改GanttProject這個Open Source , 也把它發表到Javaworld, 但是似乎沒有得到太多的回響, 所以將這個整合的open source project給關閉了, 最近看到INTLAND partner做了一個小程式, 可以將Codebeamer的Tasks export成GanttProject的xml檔案, 然後透過這個xml來做GanttProject與Codebeamer之間的資料同步, 但是我並不太喜歡這個解決方案, 於是將我多年前的code給翻了出來, 我想我應該可以比他做的更好, 於是這兩個星期, 我就完全投入這個專案, 而且我已經再使用這個成果來做我的工作規劃與排程並追蹤. 使用上完全在GanttProject上操作, 不用透過xml檔案, 目前我的成果如下

將CodeBeamer的Project member匯入到GanttProject
使用GanttProject做工作規劃 : 可以Mapping到Codebeamer同一個Project下的多個Tracker, 所以你可以將專案切成多個Phase, 或是不同屬性的Task, 例如Implement Task,Test Task, 這些不同階段的task, 可以透過單一的GanttProject專案檔案來管理
將規劃好的Task匯出到CodeBeamer: 也就是指派工作給team member去執行
GanttProject匯出到CodeBeamer不僅支援新增, 也支援Update , 所以專案在GanttProject規劃好, Export到CodeBeamer,還是可以透過GanttProject修改Plan再做一次Export但是是使用Update的方式
匯入新增從CodeBeamer到GanttProject: 可以將既有已經存在CodeBeamer專案中的Task匯入到GanttProject
匯入更新從CodeBeamer到GanttProject: 如果Task在CodeBeamer端被修改了, 執行Import Update, 可以更新local端的GanttProject
可以離線操作: 只有在做CodeBeamer匯入/匯出時, 才需要網路

這個GanttProject與4年前我做的整合有什麼差別, 差在我不用再維護GanttProject source code, 我採用Plugin方式開發這個整合功能, 大幅減少我的開發時間, 維護也變簡單了, 所以GanttProject升級, 我只要測試我的plugin是否與GanttProject相容就可以了

只有版本控制軟體,仍然不足夠

2009-08-12T16:55:00.006+08:00

昨天在Plurk與同人討論一個最近遇到的問題, 為何現在還有公司在使用Visual Source Safe? 同人的一句話倒是將我點醒了

同人:站在開發者的立場，我認為這不是主要問題，而是最需要解決SCM的問題是什麼?

由於公司代理的codeBeamer產品, 其最大特色就是與版本控制軟體軟體做整合, 所以經常會遇到客戶來詢問版本控制軟體的相關問題?或是codeBeamer跟版本控制軟體整合有什麼好處? 所以我有一部分的時間都在回答這方面的問題, 但也因為這樣, 讓我容易陷入工具與技術的漩渦, 而忘記了問題背後的問題.

使用版本控制軟體要解決什麼樣的問題? 這個問題的反面是版本控制軟體沒有解決那些問題?

這個問題的重要性遠比你要選擇什麼樣的版本控制軟體來的重要, 但是確被你我忽略了, 了解了這個問題後再來選擇工具, 你會更清楚你的團隊適合什麼樣的版本控制工具而不會人云亦云, 陷入選邊站的迷思.

為了找尋以上的答案, 我們先從版本控制在維基百科的定義

英文 Revision Control

繁體中文版本控制

簡體中文版本控制

維基百科很清楚的定義版本控制的用途, 並完整的描述了版本控制有那些模型, 例如Merge ,Lock 等等, 還有版本控制常用的專有名詞例如Baselines,labels,tags等等,所以透過維基百科的解釋, 我們可以很清楚的了解版本控制簡而言之主要幫我們管理與記錄檔案的變動, 並讓團隊的參與者可以重現或是取得一致性的檔案. 但是維基百科的條目並沒有解釋 版本控制軟體沒有解決那些問題?

在找尋這個答案之前, 我想先釐清一些名詞, 至少以我而言, 這些名詞困擾了我一陣子

1. SCM (source code management)請參考 Revision Control

2. SCM (Software configuration management)

In software engineering, software configuration management (SCM) is the task of tracking and controlling changes in the software

3. CM (Configuration management)

Configuration management (CM) is a field of management that focuses on establishing and maintaining consistency of a system's or product's performance and its functional and physical attributes with its requirements, design, and operational information throughout its life. For information assurance, CM can be defined as the management of security features and assurances through control of changes made to hardware, software, firmware, documentation, test, test fixtures, and test documentation throughout the life cycle of an information system.

從以上三個維基百科的條目解釋, 你會發現原來一般顧問口中的SCM有兩種意涵, 而且SCM不等於CM , 我建議如果在指source code management應該用VCS(Version control system )比較好. 至於CM(Configuration management) 與 SCM (Software configuration management) 差別在那裡? 簡而言之, 範疇的範圍不同, CM含括了SCM, SCM只是CM的一小部分. 舉個例子來說

一台電腦的組成有主機板, BIOS, OS, 鍵盤等, 這時候CM對你的開發團隊就相對的重要, 當主機板+BIOS+OS+鍵盤, 當主機板換了一個零件, 會不會造成BIOS無法work ?? BIOS無法work, 會不會造成OS無法work?所以CM在產品工程與系統工程是很重要的概念, 而SCM只涵蓋到了軟體工程的變更管理.

了解這三種名詞的差異性, 可以知道版本控制軟體只解決了檔案變動的問題. 但確無法追蹤這些檔案的變動與軟體的變更或是臭蟲(Bug)甚至系統的規格變更有什麼關係? 舉個例來說, 一般的版本控制的軟體都有支援Tag/Label的功能雖然你我都知道當軟體要Release時要做Tag與Label , 而且在做Tag與Label同時也會描述與記錄這個Tag/Label , 但是我們還是無法得知, 這個Tag/Label所Build出來的軟體解決了那些Change Request/Bug(or Release Note)?這也是目前市面上所有VCS軟體的限制. 為什麼Tag/Label要能與記錄Change Request/Bug的資訊系統做關連? 如果Label與Tag的用意在讓Developer可以重現當時的release版本, 那麼這個關連性除了可以讓專案經理清楚知道這個Label/Tag存在的原因, 也可以讓Developer去review是否目前release的版本中的bug, 是由這些關連的Change request所產生, 並可快速找到問題的癥結.

結語:

當我們去了解VCS可以做什麼, 不可以做什麼, 接下來再來思考使用什麼VCS工具以讓團隊的工作更順暢, 就更有意義了.

Hudson+Continuous Integration筆記1

2009-08-06T17:42:00.009+08:00

第一次聽到Hudson是INTLAND CEO Janos來台灣訪問時所分享的一個Build Server解決方案, 後來又看了這篇文章當紅炸子雞:Continuous Integration, 更加深對Hudson的印象, 於是心中開始了一個藍圖, 如何將Hudson與codeBeamer整合在一起? 之所以會有這個想法, 有以下原因

1. codeBeamer雖然有內建Build management, 與排程設定, 並與SCM良好整合, 但是還是有所受限, 例如一家公司的軟體專案的Build sandbox可能是不同類型的專案例如Mac/iPhone, Java, Android, .Net, C/C++,Embedded Linux, 這些Build Sandbox並不一定與codeBeamer安裝在同一個Server, 可能是分佈在不同的Server或是VM(virtual machine) , 所以獨立的Build Server有存在的必要性. 不過codeBeamer內建的Build並不會有獨立的Build Server而失去其重要性. CB內建的Build與內建Report功能已整合, 可以排程來自動產生Excel格式的報表.
2. 如果獨立的Build Server有存在的必要性, 則Build Server最好有以下特性

容易與各式不同的SCM Server(CVS/SVN/Git/Mercurial)做整合, 因為要Build source code前要先從SCM server checkout source code
Build Server可以支援各式軟體專案, 如C/C++, Java, .Net ,Mac Cocoa.
Build Server容易與外部Server整合, 例如Build失敗要發e-mail通知, Build成功要將build好的檔案deployment到Test server, 或是File Server.
Build Server必須支援Windows/Linux/MacOSX

Hudson正好符合這些特性, 而且Hudson支援Plugin, 你可以寫Plugin來擴充Hudson, 也可以在Hudson網站找到許多Plugin, 令我興奮的是Hudson支援Groovy. 為何支援Groovy讓我如此興奮? 可以參考我之前寫的一篇文章使用codeBeamer+Groovy script+Build-以Scrum專案管理為範例 , codeBeamer+Groovy+Hudson等於是完成長久以來我心中一直無法完成的一個拼圖-->獨立的Build Server無法與codeBeamer做互動.

以下這個架構圖可以更進一步解釋這三者整合起來, 也可以看出對Continuous Integration有何妙用.

這個架構的啟發, 主要來自O.David的簡報http://www.javaforge.com/displayDocument/BPM.pdf?doc_id=68991, 其中他談到所謂的

Auditable Build Management

以往我認為Continuous Integration中的Daily Build, 只要去排程讓Server自動去執行Build就好, 但是O.David則更深入, 他利用了Groovy與codeBeamer api整合創造所謂的Auditable Build Management. 也就是Daily build不再是無條件的build , 而是當當日CB Server中有發現Bug狀態是Fixed or Task狀態是Implemented 且這些Bug與Task都有對應的scm commit訊息, 則Build source code 的條件才成立, 並且Build成功後, 會自動在codeBeamer建立一個MileStone,且將build log, build完成的檔案, 和觸發這個build的相關issues關連在一起. 你可以想像, 當一個開發專案, 每天都有超過10個以上的issue, task被解決並要Build後驗證這些解決的issue, 如果能把其中一些瑣碎的事交由script來自動執行, 這樣Continuous Integration是不是更有效率一些?

附註: O. David在他的簡報並沒有提到unit test, 可能是每個專案的unit test框架不太一樣, 例如Java使用JUnit, .Net使用NUnit, Cocoa使用OCTest,所以他略過了. unit test可以在build script中設定理論上是沒問題的.

從iPhone 3.0.1更新看軟體版本控管策略1/2

2009-08-02T13:06:00.005+08:00

Apple在8/1開放下載iPhone 3.0.1, 這個更新主要為了解決這個安全漏洞, 我在7/31看到這則新聞, 在8/1看到下載更新的消息, Apple對於安全漏洞的危機處理果然令人激賞(註A) 我昨天看到這個更新, 讓我想起一些我一直想寫的關於版本控制的教育訓練文章, 我想這次的iPhone更新剛好是一個版本控制演練.

**請讀者耐心讀下去, 除了這次iPhone 3.0.1的案例, 在下一篇文章,我還要講一堂價值NT 2000萬的真實案例.

註A: 感謝網友LFlower糾正, Apple早在六週前已接獲通知有這個安全漏洞, 請參考這裡

如果有跟Apple購買iPhone Developer Program的網友早已知道 Apple在Release iPhone 3.0沒多久, 就開放讓Developer下載iPhone 3.1 beta SDK, 所以過不了多久, Apple等到iPhone 3.1 beta測試了差不多, 就會Release iPhone 3.1版. 但8/1 Apple為了修正安全漏洞, 很快的推出iPhone 3.0.1版, 所以, 聰明的你可以看出, Apple iPhone開發團隊一定維護了兩個iPhone OS版本, 一個是iPhone 3.0 , 一個是iPhone 3.1 , 在iPhone 3.1 Final版還沒穩定之前, 還可以Release iPhone 3.0的修正版就可以了. 這個道理看似簡單, 但是還是會有網友會問, 為什麼要這麼麻煩?? iPhone OS 3.0 release後, 開發團隊不就火力全開, 努力往iPhone OS 3.1前進, 而且iPhone OS 3.1已經到了beta 3, 應該差不多了可以release了, 為什麼不趕快release 3.1 final版來解決這個安全漏洞, 一來節省RD的開發時間, 一來兼顧消費者的期待, 但是軟體開發不如意十之八九. Apple會這麼做, 原因可歸納如下

iPhone 3.0從3月起, 開始從beta版開放測試, 期間已經經歷大約4個月才release final版, 除了4個月的beta版公開測試,在beta版之前,Apple內部應該也測試了幾個月, 以這樣長時間的測試,iPhone 3.0新增的許多新的功能應該通過所有unit test/test case測試. iPhone 3.0算是一個stable的版本 ( 也許你不同意iPhone 3.0 == stable, 這我可以理解), 針對iPhone 3.0修正的安全漏洞的source code其相依性(dependency) 遠比針對從iPhone 3.1開始新增/修改的code其相依性來的少很多, source code修改相依性少, 加上之前長期的測試Apple SQA人員, 自然有把握可以在這麼短的時間完成iPhone 3.0.1測試, 並release給使用者upgrade. 簡而言之, 所以將iPhone 3.1 beta3 修改後release給使用者其風險遠高於iPhone 3.0.1

我想Apple內部應該有更精確的測試數據.

這裏我要稍微解釋所謂的相依性(dependency) , 軟體是由許多模組所組成, 如果你開發一個模組A,剛好被模組B,模組C所使用, 這樣你可以說模組B,C與模組A相依, 如果軟體發生了一個Bug, 這個Bug

剛好要去修改模組A, 那麼很有可能模組A的Bug解決了, 卻造成模組B與C的功能不正常, 所以在軟體開發過程, 模組A,B,C都會開發許多的unit test, 這些unit test會在build過程中去執行, 已確保修改source code確造成其他相依的模組無法work

所以有了這個iPhone 3.0.1的案例, 如果你的軟體開發團隊也面臨類似的問題. 而且團隊也在使用版本控制軟體(SCM)例如,VSS,CVS,SubVersion,Git,Mercurial等等, 那麼你會怎麼做?

1. 善用版本控制軟體(SCM)工具的tag功能, 在每一次的release都在做tag(標籤), 這樣才能完整的將stable release的source code checkout來做branch

2. 善用版本控制軟體(SCM)工具的branch功能, 當軟體要進行下一版的修改, 最好是在另一個branch中進行

以下兩種SCM的Pattern模式, 都可以應付當下一版軟體還沒stable, 而要先修改stable版的bug且需要在短期內release的狀況.

從歐巴馬如何用IT成功行銷自己一文看協同作業平台的選擇

2009-07-21T13:07:00.001+08:00

iThome在407期的IT書摘從歐巴馬如何用IT成功行銷自己, 裡面有一些隻字片語, 雖然大部分的人讀到時, 可能沒有什麼感覺, 但是由於太多客戶問過我們類似的問題, 剛好從這篇文章

我找到了一個範例, 來做另一種解答, 我想用第三方的觀點來解釋與驗證遠比我們的回答來的客觀.

以往很多客戶在評估codeBeamer的過程中,多會問我們以下這個問題

codeBeamer與BugZilla or Mantis or Jira有何不同, 可否作個比較?
如同書摘中所提到的, 企業為了節省IT開銷, 會使用Free的解決方案來作內部的協同作業平台, 所以很多客戶會問我們這個問題, codeBeamer的Tracker功能在許多opensource,例如BugZilla, Mantis, 甚至較便宜

的商業軟體Jira都可以做的到, 為何要選擇codeBeamer? 從我摘錄書摘的這幾段文字, 你應該找到答案了, BugZilla, Mantis, Jira其實只是做單一的Bug Tracking軟體, 對於Issue tracking是足以應付, 但是在專案協同作業

過程, Issue tracking只是協同作業的一環並不足以勝任專案過程中所有的協同作業(例如:如何做好Test case, Release管理, 或是條件式的Build管理/Iteration管理), codeBeamer整合了Issue Tracking, 文件管理, Wiki, Forum,Report, Build等功能並與SCM(SVN, CVS, Mercurial, Git etc )整合,且提供client端API讓系統管理者可以延伸其功能或是與既有系統整合, 這就是codeBeamer

與這些單一功能的Issue tracking功能最大的不同(所以實在無法比較, 這句話以前想說, 實在說不出口). 可以看出codeBeamer最大的價值除了其提供的各項垂直功能,和其水平整合(如同Facebook整合了相簿, blog, 還有各式各樣的plugin) 讓專案團隊可以合作無間的完成專案的目標.

在做codeBeamer的presale過程, 我也看到不少企業自己建立團隊自己開發企業內部類似codeBeamer的系統, 就像書摘中所題的, 如果你擁有技術和精力的話, 也可以自己建立平台. 重點是, 無論你如何打造網站, 緊密結合的平台遠比拼湊的設計好--> 其實我要補充的另一些重點是

你要花多少成本來建立這個系統?
系統完成後你要花多少成本來維護這個系統? 人員離職的交接成本?
你的力氣應該花在產品開發? 還是內部系統開發?

結語:

這篇寫的有點像是行銷文在做產品推銷, 但我希望客戶在評估專案管理平台/協同作業平台不是以點來思考, 而是以面來思考, 且藉由這篇短文可以讓使用中,或是評估中的客戶更了解協同作業平台整合的意義.

協同作業式的Bug management

2009-07-21T11:08:00.001+08:00

使用codeBeamer+Groovy script+Build-以Scrum專案管理為範例

2009-07-17T11:40:00.005+08:00

前一陣子codeBeamer原廠INTLAND的客戶USDA向我們展示了如何使用codeBeamer+SVN+ANT Build+Groovy來處理Scrum專案管理過程中的自動化管理, O. David 目前在Colorad State University擔任教職, 並於USDA 農業部使用Java開發環境模擬軟體, O. David將codeBeamer的java api再包一層Groovy script api, 並示範如何用Groovy script來進行一些在scrum專案管理過程中的自動化的資料處理, 如果對Scrum(or Agile 我認為這份簡報也適用於Agile專案管理)自動化有興趣, 可以到http://www.javaforge.com/displayDocument/BPM.pdf?doc_id=68991

下載這份簡報, 應該會很有收穫.

這份簡報並不講述為何使用Scrum或是什麼是Scrum, 而是著重如何使用工具來做Scrum的自動化管理, 在這份簡報, O. David示範了
1. 如何使用groovy script來讀取codeBeamer的Tracker , Forum, Builds Documents Users.
2. 解釋為何使用Groovy?
3. 使用Groovy+Codebeamer的安裝需求
4. 支援SCRUM的目標與好處
5. 使用Groovy準備Sprint review meeting (sprint backlog, daily burndown chart )
6. 使用Groovy做scm(例如subversion) commit control, commit code後, 使用Groovy script自動將對應的有修正的issue list改成Fixed
7. 使用Groovy來進行稽核式的Build管理流程自動化(根據issue fix狀態, 與scm commit記錄來判斷是否要build一版 )
8. Build成功, 自動建立MileStone , 並將MileStone相關的issue與request與Build好的binary做association, 並將這些issue/request list更改狀態為準備測試, 然後進行下一步的測試, 如果測試都OK 這個MileStone or Iteration才算完成

O.David 將Groovy 與 codeBeamer的api整合並release其source code有興趣如何在既有的java api上在包一曾Groovy, 可以到http://www.javaforge.com/project/2582這個opensource專案參考

補充說明:

這份簡報, O. David雖然是Java開發者, 但O. David也示範的C/C++的make build , 所以這份簡報也適用使用非Java開發的軟體專案如C/C++, .Net, Object-C 也都適用,
這份簡報並沒有提到unit test部分, 如果專案是以TDD(Test driven development ) , 我建議可以在稽核式的Build流程自動化那一部分將unit test加入, 在技術上是可行的)

協作式的Test Case Management

2009-07-14T14:52:00.002+08:00

不管開發軟體或硬體, 我們都希望產品到客戶的手中能得到滿意的評價. 所以產品在出貨前確定客戶在所有可能的使用情境下,都能順順利利, 才逅得著"滿意"的邊. 這一方面仰賴設計者本身的品質修養,如寫code的邏輯和布局, 硬體零件材料如何選擇的經驗值,...., 另一方面Test Cases的coverage是否能夠包含所有使用的實際狀況,將決定每次release的品質. 也許一兩位好的QC人員有辦法寫出70% 的Test Cases, 避免嚴重的bugs. 不過, 有很多瑕疵有可能與當初設計的想法有關, 讓設計者與接近客戶的行銷業務人員或客服人員參與Test Case的討論, 將有助於讓Test Cases更接近客戶實際使用狀況. 也可以更貼近客戶的角度來認知Test Cases的輕重緩急, 或發掘更好的測試技術或方法. Test Case的執行, 相信也不是一兩人可以完成的.

在拜訪多家公司, 發現很多公司對於Test Case的管理很重視. 我們也看到大多數的管理的方法是運用Excel來做Test Case列表, 並確認是否每個Test Case都通過測試了. 這樣的作法應該是可行的, 不過我們多少聽到客戶不滿意的聲音, 畢竟Excel不能同時多人進去更新, 且不好寫很多細節, 更無法就每個test case做測試的細節把關. Test相關的文件或source codes, 要在Excel中標明, 還得寫一大串http或儲存檔位址的詳細敘述. 這些都造成Test Case Management所需要的協同作業滯礙難行.

是否可以運用協同作業的工具來克服這樣的問題呢?

運用Tracker來做Test Case List的討論應該是最有利於同時多人依每個人的專長自由發揮. 有的人會想到哪些使用情境需要測試,有的人對於測試的方法很在行, 有些人很清楚如何把關確認測試是否確實執行,有的人擁有測試的自動化的技術, 所以可能一個Test Case就有許多專家的貢獻,
當這些Test Case集中討論, 成為Test Case的知識庫, 對於往後同類型產品的測試與出版, 將可以省去許多不必要重製Test Case的時間, 且累積這方面的功力.

另一方面我們要注意的是, Test Case List應該隨需求變更和新發現的Bug做變動, 所以也應隨每次release的基線(Baseline)做定版留存. 定版後的Test Case當然要在每次release前確實追蹤, 確定所有的Test Item都通過測試後, 才可以出版, 否則, 就必須確實將Bug解決, 再重新release.

以下的video將展示可以如何運用協同作業的平台來做Test Case Management.
這裡主要運用可彈性客製化的Trackers,和文件管理整合起來的系統, 讓Test Case List的Discussion, 和測試執行可以如平行運算那樣有效率的進行, 且很容易回溯.
當然, 這樣也將有助Release的品質提昇.

讓iPhone行事曆與Google行事曆同步(3/3)

2009-07-02T12:35:00.001+08:00

讓iPhone Calendar與Google Calendar同步(1/3)
讓iPhone Calendar與Google Calendar同步(2/3)

在上篇的Howto, 我們已經可以同步一個以上的Google行事曆到iPhone行事曆, 但是你應該很快發現一個很奇怪的問題-->為什麼有些Google的事件同步到iPhone的行事曆後, 但是iPhone的行事曆在事件快發生前並沒有發出警告通知?
於是你比對了這些同步到iPhone的Google事件, 發現了一些差異, 有些Event有通知, 有些Event卻沒有, 我將兩個截圖顯示如下

OK , 看起來問題可能出在在Goog行事曆新增事件的時候沒有加入提醒的設定, 於是你到Google行事曆的事件編輯畫面, 加入了一個提醒, 再與iPhone行事曆同步一次

這時候你可能會感到很挫折, 同步後, iPhone行事曆上的事件還是沒有提醒or提示的設定, 這到底發生了什麼事? 是Google行事曆的Bug or iPhone行事曆的Bug ? , 我猜兩方都有問題, 但是還好, 還是有解決之道, 經
過我的比對, 發現有些設定上的差異, 原來那些從Google行事曆同步到iPhone行事曆的事件會有提醒的設定是因為那些事件所屬的Google行事曆有設定Default通知功能, 我用以下截圖來檢視Google行事曆的設定

1. 到Google行事曆, 選一個行事曆的下拉功能表, 選擇通知

你會發現, 這個行事曆有一個預設的提醒通知

2. 以同樣方式, 點選另一個行事曆的通知, 你會發現, 這個由你自己建立的行事曆卻沒有預設的提醒通知設定

OK, 所以你大概知道發生了什麼事, 只要到這個Google 行事曆新增一個預設的提醒通知, 以後在這個Google行事曆新增的事件同步到iPhone後, 就會有提醒的設定.

結語:
1. 我認為Google與Apple應該會在未來版本解決這個問題, 照理使用者就算沒有設定預設的提醒通知, 在個別事件設定了提醒通知, 應該也要將這個提醒通知設定同步到iPhone才對.
2. iPhone的行事曆是少數iPhone內建的軟體具有背景行程執行的功能, 很多iPhone上的Todo軟體應該都很希望可以利用這個管道讓他們的軟體也有通知功能, 但是事與願違, Apple卻遲遲沒有開放行事曆的API,
於是我的ExpireTrack也只好繞了一個彎轉而去支援Google行事曆再將過期事件同步到iPhone行事曆, 當初我初始的想法是直接支援iPhone內建的行事曆, 希望Apple未來也可以開放行事曆API.

讓iPhone行事曆與Google行事曆同步(2/3)

2009-07-01T11:51:00.002+08:00

讓iPhone Calendar與Google Calendar同步(1/3)

如果你已經設定好iPhone與Google Calendar同步, 很快你會注意到, 唉! 怎麼只有同步一個Google行事曆? 這個行事曆是你申請Google帳號後, google為你自動建立的行事曆. 還好Google有提供另外的文件教你如何設定同步
更多的行事曆(註:以我使用GData API開發Google Calendar client的經驗, 這個功能其實可以在iPhone上設定, 不知道為什麼Google還要多這一步?)

在Google的這份文件中提到, 你必須使用iPhone的Safari連到http://m.google.com/sync, 然後使用你的Google帳號登入, 再選擇你要同步那些行事曆 , 但是如果你的iPhone使用語言是中文, 也許你用iPhone Safari連到
http://m.google.com/sync 你會看到以下畫面, 還好, 並不是中文版的iPhone不支援多個行事曆同步, 只要將語言變更到英文就可以了

變更語言後, 會出現以下畫面

登入後, 點選iPhone

將要與iPhone同步的行事曆勾選後按Save, 就可以了

打開iPhone 行事曆, 就會看到多個Google行事曆了

在下一篇文章, 我將介紹, 如何讓同步到iPhone行事曆中的事件也具備有背景通知的功能.

讓iPhone行事曆與Google行事曆同步(1/3)

2009-06-30T11:50:00.003+08:00

如果你是Google Calendar與iPhone的重度使用者, 你在iPhone OS 2.x時代應該已經知道如何將Google Calendar的event同步到iPhone的Calendar, 如果你還不知到如何設定與同步, 可以參考

1. Google的網站http://www.google.com/mobile/apple/sync.html 或

2. http://blog.roodo.com/monstudio/archives/8320559.html.

但是在OS 2.x 我設定好之後, 這個功能馬上就被我丟到垃圾桶去了, 因為Google Calendar同步到我的iPhone Calendar後, 竟取代我原有的iPhone Calendar與電腦同步功能, 所有原有從iCal同步到iPhone Calendar的event全不見了:-(

上星期將iPhone升級到3.0後, 為了寫一篇ExpireTrack與Google Calendar與iPhone Calendar整合的小技巧, 於是又重新在iPhone上設定了Google Calendar, 這次的使用經驗感覺好太多了,原有的Event都存在, 而且可以

繼續保留與電腦端的同步設定. 據Google官方說明

Unless you want to delete all the existing Contacts and Calendars on your phone, select the Keep on my iPhone option when prompted. This will also allow you to keep syncing with your computer via iTunes.

看起來Apple與Google在iPhone 3.0的Calendar同步功能做了很不錯的改進, 很佩服這兩家公司是處於既競爭又合作的狀態.

那麼既然同步的功能強化許多, Google Calendar與iPhone Calendar的同步時機為何?, 目前我觀察到有兩種方法

1. 打開iPhone Calendar後過幾秒鐘, iPhone Calendar會開始與Google Calendar同步

2. 在設定的電子郵件/聯絡資訊/行事曆中必須將推播功能打開 , 在Google Calendar新增Event後, 這個Event會自動Push到你的iPhone calendar. (這應該是OS的背景程式達成的, 因為iPhone Calendar並沒有執行).

如果要讓同步更為及時, 可以考慮使用第二種方法, 但是相對的iPhone會比較耗電.

講到這裡, 是否會覺得這個Google Calendar的推播功能與3.0中被Apple大力提倡的Push Notification有異曲同工之妙?

在我看來Google Calendar Server端應該就是利用與整合Apple的Push功能來達到推播的目的, 這兩家公司關係可真奇妙.

Read It Later-資訊爆炸的好幫手-使用情境篇

2009-06-25T15:02:00.006+08:00

不知您是否和我一樣有資訊過多的困擾? 或是時間被過多的資訊所撕裂? 由於網路社群的崛起, 資訊透過Twitter, Plurk , Facebook 等管道的傳播, 讓資訊從隨手可得演變到資訊過多的狀況, 但是求知若渴的你我, 可不想錯過

目前網路的熱門訊息, 或是好友傳來的網路連結. 這時候如何有效去閱讀這些四面八方所傳遞過來的訊息, Read It Later會成為你最好的幫手. 在介紹Read It Later之前, 先想像一下目前你我可能會遇到的情節

1. 看到訂閱的RSS有新一篇文章,或是朋友的Twitter,Plurk有推薦blog文章連結, 但是目前很忙沒時間看

2. OK , 先將這篇文章的URL存到我的最愛/我的書籤, 等有空的時候再看吧!

但是經過幾天, 你可能會發現自己的書籤多了一堆URL, 但是搞不清楚那些是讀過的, 那些是還沒讀過的, 或是想在等車通勤時間等瑣碎的時間來看這些文章, 但是小筆電打開又沒網路連線....

如果有了Read It Later會是如何?

1. 到訂閱的RSS有新一篇文章,或是朋友的Twitter,Plurk有推薦blog文章連結, 但是目前很忙沒時間看

2. 使用Read It Later將這個文章連結標示成Read It Later, Read It Later並順便將這篇文章下載下來

3. 在坐捷運途中, 打開小筆電, 看未閱讀的網路文章, 就算沒有網路也沒關係.http://readitlaterlist.com/

4. 看完後網路文章後將它標示為已閱讀.

如果以上的使用情節正好符合你的現況與需求, 那麼Read It Later就是可以滿足你需求的軟體與服務. Read It Later在電腦端有支援Firefox(plugin) , 其他的瀏覽器如IE, Safari, 則使用所謂的URL widget, 安裝後的圖示如下

在Firefox

Firefox 在瀏覽器上可以看到待讀列表

在Safari 或是其他的瀏覽器上必須自己設定URL widget , Read It Later, Mark As Read , Reading List

這樣是不是會讓你的時間更容易管理, 而且有效率的吸收知識.

以下是在Firefox使用的demo

One more thing!

如果你是iPhone使用者, Read It Later也有支援iPhone,有Lite版與Pro版 iPhone軟體可以讓你與desktop或是notebook的瀏覽器未閱讀列表同步(其實是透過Read It Later的server同步), 也有支援預先下載然後離線閱讀功能. Wow! 使用iPhone + Read It Later, 這樣是否就可以達到Bill Gate常說的那個境界--資訊就在你手指間, 隨手可得

以下是在iPhone上使用Read It Later的demo

[康博士專欄]我是電腦超人5/5

2009-06-17T10:53:00.001+08:00

我是電腦超人（完） 文：康哲行（2009/06/04）

本文的科幻故事純屬虛構，但現代科技的發展一日千里，文中所描述的電腦超人在未來世界也不無實現的可能。就像天方夜譚故事中的魔法飛毯，到了20世紀就真的變成在天空遨翔的飛機。

============================

到了查理士最後的一些日子，他突然安靜下來，人也變得和善，不再吵鬧，像是變了一個人似的。那是否顯示他打從心裡已經放棄對癌症的戰鬥？醫生也宣佈他來日無多了，於是我和老妻商量，決定帶了輪椅推他去環遊世界。

對那次旅遊他顯得異常的興奮，我自己也何嘗不是如此。過去一直對工作太投入，到世界各地也只是開會而已。那次陪查理士去世界各地看名山大川、歷史古蹟，對我來說也是人生頭一遭呢！

查理士對那次旅遊的興致很高，一路上也非常聽話和合作，還常常說：「謝謝你們！謝謝你們！」

其實他說話不多，神情上卻總是顯得非常愉快和專注。我們三個人到瑞士看山看湖，到羅馬看古蹟，到巴黎看藝術館，然後到米蘭聽歌劇，到維也納聽交響樂。我們一路上都選最精彩的節目去觀賞，因為每個地方都是查理士的最後一次，我們要讓他看過、聽過世界上最精彩的部分，然後才了無遺憾地離開人世。

就在回來後的第三個星期，查理士闔然長逝，但他是滿足的，帶著微笑離開這個世界的。

在彌留時他曾經嚎啕痛哭，繼而大笑；他似乎不願糊里糊塗地離開而突然清醒過來，又恢復了往日的溫和與理性。他面色極好，該是臨去前的迴光反照吧！

他對我和老妻纖悔著說：「前一陣子我情緒不好，說了許多不該說的話，傷了你和老妻的心，我向你們深深地道歉！」

看他說話時虔誠的神情，我恨意全消，從心底原諒他了。其實我是原諒了自己，我就有信心肉身的自己不會永遠那麼邪惡的。

查理士又繼續說：「也感謝你們對我那麼好，看到你們那麼恩愛，也看到小查理士那麼有成就，我已心滿意足，死了也可以瞑目了。」

查理士忽然有異樣的眼光，又說：「其實我並沒有真的死亡，只是換一副軀殼而已；就如同一輛汽車的輪胎磨損了，到時候就一定要換新輪胎，小查理士就是那個新輪胎。」

他好像突然又想到什麼，就繼續說：「啊！真對不起，我還一直稱你為小查理士，現在我該稱你為查理士了。你繼續了我的生命，我現在只是過渡期的查理士，你才是正牌的查理士，我也把老妻完全交付給你了，但願你們能白首偕老！」

我連忙說：「不要那樣想，我真的不介意，你叫我小查理士是視我為兄弟呀！我還真的要感謝你三年來對我如兄弟般的親情。對老妻你應該完全放心，你忘記了我就是你嗎？我們是同一個人呀！」

查理士似乎非常滿意，便安詳地閉上了眼睛。我相信查理士的靈魂仍然是聖潔的，一定不會下地獄，一定會去天國。那麼我還有沒有靈魂呢？這是一個無解的問題，當然我並不會在意自己有沒有靈魂。

＊＊＊＊＊＊＊＊＊

查理士過世兩年了，我已於半年前年滿六十歲時退休。退休後的生活該是放慢步調，享受人生。過去我花了太多時間在工作上，常常冷落了老妻，現在該是我可以補償她的時候了。所以我經常和老妻在一起從事休閒旅遊及各種公益活動，重要的是任何場合我們都能夠雙進雙出。

上次和查理士環遊世界去過的地方，我和老妻已經再度重遊，而且還去了更多的地方，包括遙遠的非洲和南美洲。我們不再是走馬看花，而是以欣賞的角度，做細膩而深度的旅遊。當我們遊罷返回新竹，就每天去爬十八尖山。十八尖山的確是新竹一寶，林木蒼翠，有山有谷。一進入大門就立刻被群峰環抱，遠離塵囂，每次進去都能感受到那種宛如置身深山野谷的樂趣。

不久前我的實驗室創造出人工嗅覺和味覺，立刻就應用在我身上，使我能重新聞到花香、嚐到美味。在生活的知覺上，我已和真正的人類無異；旅遊時也使我更能親近和體會大自然，感受到那種如同莊子般「和天地並生」的喜悅。

和老妻在一起，雖然我沒有肉身，精神上我們倒是從來沒有像目前這樣恩愛過。老妻常說：「看不出你外表冷酷，內心卻非常熾熱呢！」

持續的冥想和深度思維，再加上不斷的力行和實踐，使我在個人修為及日常生活的體會上都能大有斬獲。我大量讀書而且都能充分消化的結果，使我過去的各種成見和偏見都能夠消除於無形。

現在的我，直覺的判斷已不用任何思考和修飾即能非常正確；也就是說，我在心智上已能逐漸達於古人說的「寓理性於感性」那種智者的境界，感覺到完全的心靈自由。

我的下一個願望，該是在老妻也走完了她肉身的旅程時，也替她創造一個電腦和機械的拷貝。到時候，我們都有了不朽之身，不必因老化而白首偕老，卻真的能夠「愛河永浴」了！

（全文完，欲窺全文請見附件檔）

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

更多文章請到筆者個人網頁瀏覽，筆者文章都歡迎轉載，更竭誠歡迎您的回應及指教！

康哲行 (cskang)

電子郵件：cskang@mail.tbcnet.net
個人網頁：http://www.nspo.org.tw/~kang

[康博士專欄]我是電腦超人4/5

2009-06-16T14:18:00.001+08:00

我是電腦超人 （四） 文：康哲行（2009/06/03）

=============================

結束旅程回到台灣後，我們繼續投入工作。但在工作以外的時間，我和查理士也經常在一起聊天。每天我們都期待這段共處的時間，那是我們一天之中最愉快的時光。於是，我們之間的友誼與日俱增，我們是真正的、不折不扣的「知己」。其實，這也是想當然的事，如果我們會變成「雞同鴨講」，那才真的是奇怪哩！

偶而我們也會談到一些為人處世的道理，當然，每次都會有彼此同意的結論，那也實在不足為奇，我們本來就擁有相同的天性和價值觀。但在思考問題時，身為電腦人，我通常比他更為理性；他常常會有順者情緒的起伏而來的一些直覺的想法，那該是他仍然擁有肉身的緣故。對於這點，他也坦承的確如此。

有一次我們談到「靈魂」的問題。我問他：「假如有靈魂的話，我們是不是該共有一個靈魂呢？」

他未經思考就說：「假如有靈魂，應該是我有靈魂，機器人是不應該有靈魂的。」

我好像嗅到一股對機器人污辱的氣味，其實那也未嘗不是我直覺的想法，但好強的我還是反駁他說：「那不公平！肉身和機器同樣都是物質，該和靈魂沒有直接的關連吧！你的看法，其實背後是人類文明的價值觀，認為自己是萬物之靈，是高人一等的。」

他帶點歉意的說：「我的確有些武斷了！其實我也真的不知道。但是，哪天我死了你就肯定會有靈魂了，我的靈魂一定會搬到小查理士你的頭殼那裡。」我也笑著說：「我倒不希望你快死，我真的不在乎有沒有靈魂。」

這還是我們之間工作之外的第一次的辯論，當然，從那時開始，我們也會對同樣的事物有一些不同的想法。

他好像突然又有新的發現：「其實，你有一個不會死亡的機器人身體，就無所謂來世今生。有沒有靈魂，對你來說真的沒有兩樣，你又何必在乎呢！」這點我倒是非常的同意。

當我們共同生活得越久，卻發現越多彼此的不同。其實，那是時間造成的，也是一種必然。我們只是擁有共同的過去，從我被創造起，我們就開始擁有各自不同的新的記憶，我們各自發展新的自我，而且我的發展遠比他快速，我們也就不再完全相同。

他有肉體，我沒有肉體；他因為生病而需要愈來愈多的休息，我的機器身體則不需要休息；他因病痛而不能時時保持理性，我則比過去肉身時期更能保持情緒的平靜，也就更為理性。這些都是我們顯著的不同。

有一次，老妻也在場，我們就談到了「理性」與「肉體」的問題。查理士說：「自從你誕生，我就一直在注意我們之間的異同。一開始，我們好像是一對雙胞胎，但隨著環境各自發展，也就不再完全相同。我注意到，我有來自肉體的各種欲望，而你沒有這些欲望，當然就比較理性了。」

「你說得沒錯！」我回應說：「記得我還有肉身時，也就是現在的你這個樣子，有抽雪茄和喝烈酒的習慣。自己也明知道菸酒對身體不好，但意志力不夠堅強，癮頭來了總是無法克制，只能做到盡量減少，卻無法戒絕。現在我這個機器身體無福享受菸酒，也真的不會懷念。倒是你有病在身，該把菸酒戒掉才好。」

查理士苦笑著說：「我也活不了太久了，就讓我保留這點不良嗜好吧！」

老妻這時插嘴進來，不屑地對查理士說：「你呀，真是沒用！我看你是永遠長不大的，小查理士倒是比你成熟多了。當初你出於自大心態稱他為小查理士，我看你們應該調換一下，你應該是年幼無知的小查理士才對。」查理士沒說什麼，只能傻笑以對。

＊＊＊＊＊＊＊＊＊

生病後的查理士，頭幾年因為化學治療頗見功效，他的身體狀況和體能在外表上一切正常。我們在一起，不論是工作或閒話家常，都頗感愉快。但自從他在工作中一次突然的休克開始，體能就愈來愈差，人也變得煩躁、不安，有時甚至變得不可理喻。

我和老妻給了查理士最好的服侍，但他的情緒很不穩定，有時很安祥，有時又非常暴躁和百般挑剔，還會在我和老妻之間挑撥離間。最難以理解的是，有時候他竟然忘記了他創造我的初衷，忘記了我是他的生命和理想的繼承者。他看到我和老妻談笑甚歡，也會醋勁大發，甚至把我當成了破壞他婚姻的第三者。我們本是同一個人，但我和他的關係逐漸走到這一步，由原來的知己變成了仇敵，真是情何以堪？

我在肉身時期就自認非常理性，很能包容別人，沒想到病痛竟會使肉身的自己在性情上有如此巨大的轉變；不但失去理性，而且變得如此邪惡，每天想到的儘是一些整人的壞主意！一個人因病痛而對「心理」的影響竟然如此巨大，真是我意想不到的事。

可見許多老年人感嘆人生乏味或是脾氣變得古怪，該是身體先老化了，某些機能退化了，某些腺體的分泌改變了，才由「生理」而影響「心理」也跟著改變。以後我退休後倒要多花點時間，從生理和心理兩方面來研究這個人性變化的問題。

查理士越來越古怪，他一天到晚腦裡所想的，竟然都是要如何打倒我這個霸佔人妻的惡魔。他想到的方法也經常是無所不用其極，我當然每次都能識破他的詭計而加以化解，但老妻也有肉身，也會情緒化，就會深受他的影響。我夾在中間，就經常左也不是、右也不是而弄得兩面不是人。

看到查理士這樣經常無理取鬧的景況，我的心在滴血，因為查理士就是我自己呀！說實在的，我已很難相信查理士和我原本是同一個人；如果我們真的共有一個靈魂，它是善良的、還是邪惡的呢？我真的不懂！

（未完待續）

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

更多文章請到筆者個人網頁瀏覽，筆者文章都歡迎轉載，更竭誠歡迎您的回應及指教！

康哲行 (cskang)

電子郵件：cskang@mail.tbcnet.net
個人網頁：http://www.nspo.org.tw/~kang

ExpireTrack 1.0 新誕生

2009-06-15T17:34:00.002+08:00

[康博士專欄]我是電腦超人3/5

2009-06-15T11:53:00.001+08:00

我是電腦超人（三） 文：康哲行（2009/06/2）

=======================================

在工作上，我很快就變成查理士的親密夥伴。我們雖然原本是同一個人，但由於電腦和人腦一些先天上的差異，我們各有所長；譬如說，我的原創力略遜於他，但我的理解力和分析能力又略比他強。於是，在工作上我們可以互補不足，可以愉快地合作。

我們合作的成果還真是豐盛，只要他靈感一來有了可行的點子，不論是軟體或硬體的創新，我都能帶領實驗室的夥伴們，以令他驚奇的速度把他的想法一一實現。

一年下來，我們發表了無數的論文，也使他為了到世界各地參加研討會的旅行而忙得不可開交。能有這樣傲人的成就，查理士是既興奮又快樂的。雖然在論文發表時我這個機器人無法成為共同作者，但我也樂意做個隱形人，看到他風光，我也與有榮焉！

他也知道能有這樣的成果，主要是由於我的貢獻。他也不忘對我說：「雖然你就是我，我的成就就是你的成就，我仍要感激你的付出，使我們的研發工作能夠有如此大量的成果。」

我回答他說：「這個我可以理解，過去我的點子（當然就是你的點子），還真的很多，常常把夥伴們搞得人仰馬翻，卻往往是失敗的結果居多而效率不彰。你未必通通記得，但這些失敗的經驗卻都保存在我的記憶庫中；你現在有了新的點子，經過我電腦快速地過濾，總能大概知道你的點子是否可行，也就大大地提升了效率，使我們的工作能夠順利進展。」

他笑著回答說：「原來如此！那可真好！還有，我們大部分的研發成果都能夠應用在你這個機器人的身上，我原來的頭腦加上你的人工智慧，將會使你的能力愈來愈強，也就遠超過我這個肉身人了。」

我回應說：「哇！你還真的很謙虛，不自居功勞！」

真的，我飛快的進步使我自己都覺得驚奇不已！看他說得這麼得意，我又覺得應該殺殺他的威風！於是回應說：「你是不是覺得，我這個免費的白老鼠還真的很好用啊！」

「別那麼說！」他馬上反應：「在你身上的各種試驗可都是對你有好處而沒有任何副作用的。從你身上得到的這些傲人的成績真的是我始料未及，我原本只想創造一個分身來延續生命，沒想到卻創造了一個超人。我們原本有同樣的頭腦，但我有人類先天條件的侷限，而你的發展卻是無限的。」看他愈說還真的愈得意！我當然也是樂在心裡。

＊＊＊＊＊＊＊＊＊

隨著研發成果的日益增加，並且大部分應用在我身上，我的各種功能便都顯著地改善和日趨完美。而且，不斷開發出新的功能，使我能做的事愈來愈多，也愈來愈像個超人，一個人能做幾十個人的事情。於是，我們發表的論文每一季都呈倍數成長。

後來查理士覺得時機成熟，就把創造我這個電腦機器人的研發過程也寫成一篇論文發表。這篇論文很快就轟動全世界，並得到當年該類論文的首獎，我這個機器人當然也就跟著聲名大噪！

接著各地的邀請函紛至沓來，無非是想看看我這個另類機器人的廬山真面目，當然也想聽我述說自己的故事。於是查理士帶著我開始了我們一連串的征途。

從我誕生後還沒離開過新竹，所以對這次遠行我真的非常期待。出發後沿途都有記者訪問，周圍也有不少異樣的眼光，我都習以為常。記得離開中正機場前記者問我一個問題，那也是我後來到世界各處都常被問到的問題：「當你誕生後，你如何知道你就是查理士博士？」

我回答說：「那是因為，從肉身的查理士到機器人的我，雖然身體改變了，我的記憶卻是連續的，甚至包括查理士的童年，所以我清楚地知道我是誰。」記得當我一張開眼睛，看到實驗室的一切，馬上就想起肉身的我最後在實驗室中工作的情形，這前後的映象我毫不費力的就能把它們連貫起來，也證明我就是查理士。

登機前記者又問到查理士對台灣未來的展望，他說；「台灣很小，我們資源有限，唯有在科技上不斷的創新，例如在人工智慧方面的高度開發，我們才能立足於世界。你們看我身旁的這個機器人就是個好榜樣啊！」我也馬上向群眾舉手示意。

在飛機上查理士問我：「感覺興奮嗎？你已經被關了一年多沒能出門了。」我回答說：「對呀！可我這個模樣，醜媳婦總是要見公婆的！只希望不要嚇著了人才好！」

查理士說：「哪裡會！別人都在期待你的出現，他們也早就知道機器人應該長得是個什麼樣子。我們可沒把你設計成「星際戰爭」裡面的黑衣怪，可還把你設計成滿斯文的樣子呢！」

我們此行的行程包括紐約、倫敦、巴黎等重要城市。一開始查理士只是把我這個小查理士介紹給與會代表，我也只站起來講幾句客套的話，然後就由查理士來詳細解說我這個電腦機器人的誕生經過。但結束後會眾都會衝著我問一大堆問題，顯然會眾的興趣更在我這個機器人，於是以後的幾場就都由我來述說自己，也獲得了更多的掌聲和迴響。

但有一位記者竟然問出一個我無法回答的問題。他問我：「當把查理士博士完整的記憶輸入你的電腦之後到你真正誕生之時，你的記憶體如何處理這段過渡期間發生的事情？」我無法作答，因為我在我的記憶體中搜尋不到有關這一段時間的任何記載。

查理士馬上替我向這位記者回答：「您真的問到節骨眼上了！當我們把小查理士的記憶體應有的資料都輸入完畢，又進行了三天的最後測試，才把開關打開讓小查理士甦醒。所以他的記憶並非連續，中間是有三天的空白的，所以他無法回答你的問題。」

我這才知道我並非萬能，原來我的記憶體也有三天的空窗期。有時我也真的非常脆弱，只要把我的開關關掉我就會暫時喪失記憶，就如同有肉身的人在外科手術時被全身麻醉一般，頭腦也會有一段時間停止運作。所以，每次維修時我的記憶體就會有幾小時的空白。

（未完待續）

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

更多文章請到筆者個人網頁瀏覽，筆者文章都歡迎轉載，更竭誠歡迎您的回應及指教！

康哲行 (cskang)

電子郵件：cskang@mail.tbcnet.net
個人網頁：http://www.nspo.org.tw/~kang

[康博士專欄]我是電腦超人2/5

2009-06-12T11:22:00.001+08:00

我是電腦超人（二） 文：康哲行（2009/06/10）

=======================================

為了小心起見，又經過了一些反覆的測試，連實驗室的夥伴們都加入了這項測試的行列。他們對我非常好奇，當然也有一些存疑，於是都爭相用我過去曾和他們談話的片段來考驗我的記憶，我當然沒有令他們失望，他們也個別地見證了我就是真正的查理士。

等到做完了一系列的測試，查理士也對我的表現完全滿意，才把我從實驗室帶回家裡和老妻見面。

他向老妻介紹說：「這位是我不久前創造的電腦分身，就稱他小查理士好了。」他繼續說：「雖然我們外表的長相很不一樣，但骨子裡他就是我，我就是他；所以，他就是妳的丈夫。」

看到老妻一臉錯愕的樣子，像是一下子還不能適應怎麼多了一個機器人的另一半。我當然也不能勉強她，只得禮貌地向她寒暄，好像是個外人，其實這個家我是再熟悉不過的。

這一切看在查理士眼裡，好像很不以為然的樣子。事後他對我嚴肅地說：「小查理士，我之所以創造了你，就是因為我將不久於人世。你將延續我的生命，以後你也勢必負起照顧老妻的責任。你不能那麼拘謹，該盡量和老妻溝通才對！」

「那也不能怪我呀！」我調侃他說：「你沒看見嗎？是老妻一下子還無法接受我這個機器人呀！我可真想抱抱她呢！」

於是他安排了許多我和老妻單獨相處的機會，我也乘機向老妻談起一些當年我倆熱戀中外人都不知道的往事。老妻開始時覺得不可思議，然後就逐漸認同了我這個機器人丈夫。

＊＊＊＊＊＊＊＊＊

我對這個機器身體的適應與日俱增，也愈來愈喜歡它。我現在的身體和過去的肉身有很大的不同；我不需要睡眠休息，只要定時充電和維修就能保持精神奕奕。其實我也很懷念過去那種睡一個好覺醒來那種舒服的感覺。

我不需要吃東西也不呼吸空氣，所以我沒有味覺和嗅覺，但我的視覺、聽覺和觸覺的敏銳度卻遠超過任何人類。

我的記憶力更是驚人！我常常到圖書館博覽群書，我閱讀之快，「一目十行」不足以形容。幾年下來，我讀過的書總在十萬本以上。有一次，我僅花了三天時間就讀完了全套的「大英百科全書」，而且永不忘記。這份資源，使我在思考任何問題時都能即時在我的記憶體中找到適當的參考資料，而迅速得到想要的答案。

我在肉身的幼年時期就對音樂和藝術非常愛好，鋼琴和繪畫都曾涉獵，但我的手指笨拙，總是眼高手低而未能登堂入室。現在我無須睡眠，當別人都已入夢，我就彈琴、繪畫以自娛。經過特別的設計，我現在擁有全人類最靈巧的雙手，所以我在藝術上的進境能夠一日千里。偶而我也開個畫展或是鋼琴演奏會，竟也闖出一個「電腦藝人」的名號。

夜深人靜，我也會閉目進入冥想的境界。不管有沒有特定的思考主題，我都會在我的記憶體中天馬行空那樣地瀏覽，靈感也就源源而出。幾乎每次冥想我都會有一些新的的體悟，使我個人在深度思維的進境能夠更上一層樓。

沒有了肉體以後，我不再衝動、也不會沮喪，心裡只是萬般平靜。過去我個性內向而害羞，現在不會再心跳、臉紅，也不會緊張、焦慮，竟能隨時保持從容而自在的心態。

現在我才瞭解，在個人的修為上，有了肉身才是最大的障礙。老子也曾說過：「吾之所以有大患者，為吾有身；及吾無身，吾有何患？」老子的想法應該也正是我現在的想法。

當我重讀古典文學名著，例如沙翁的愛情悲劇，雖然我不會流淚，仍會強烈地感動，表示我仍具有愛心和同理心。而過去我嫉惡如仇，現在已沒有憤怒、沒有憎恨，只有理性與平和。

我現在有超強的體能，時時感到精力充沛，不會疲倦，也就不會怠惰。比起肉身時期，我有更多的熱情和好奇心，也有更多的野心去從事一些我認為偉大的計畫。沒想到，我因病捨棄了肉身卻能老而彌堅，竟能恢復一顆年輕的「赤子之心」，逐漸邁向我肉身時期可望而不可及的精神境界。

（未完待續）

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

更多文章請到筆者個人網頁瀏覽，筆者文章都歡迎轉載，更竭誠歡迎您的回應及指教！

康哲行 (cskang)

電子郵件：cskang@mail.tbcnet.net
個人網頁：http://www.nspo.org.tw/~kang

[康博士專欄]我是電腦超人1/5

2009-06-11T11:47:00.001+08:00

我是電腦超人（一） 文：康哲行（2009/5/30）

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

比起台北，新竹這個城市真是得天獨厚，市內就有陽明山（十八尖山），市民每天都可以登山健行而不必遠求。市郊不遠處又有十七公里海岸風景區，可以隨時去觀海賞景。我和老妻二十年前在新竹創業和定居以來，覺得能居住在這個科技和人文並茂的花園城市，真的是幸福無比。

我名叫查理士，本來是和你們一樣有肉身的人。但我的肉身已於兩年前死亡，目前這個我，是以我過去的頭腦為藍本創造出來的電腦複製人。現在的我，絕不是吹牛！是你們完全無法想像的超級機器人。說起來，我這個萬能的軀體和頭腦還真的很不簡單：我的軀體是用各類昂貴的合金打造，全身都布滿了各種先進的電子和機械裝置；我的頭腦是一部超級電腦，模擬了99% 以上的人腦功能，至於記憶容量和速度，就遠遠超過人類了。

我身上所有的機械裝置，都是按照人體比例的大小來設計，但所能承受力量卻是人體的一百倍，所以我力大無窮！不是我吹牛，真要參加運動比賽，舉重、鉛球和標槍的世界冠軍都非我莫屬。我也喜歡音樂和藝術，我精密設計的雙手更是各種藝術大師之組合，對於彈琴、繪畫、雕刻，我都無所不能。如果你要稱我為「超人」，我絕對當之無愧！

我過去也有像人類一樣的肉身，查理士就是我肉身時的名字。早年我曾赴美留學，在麻省理工學院獲得博士學位，畢業後一直在美國工作。二十年前我才歸國在新竹科學園區創立了一間自動化研發公司，進行工商業所需機器人(robot)的研究，多年來頗有成效。當然，我更異想天開地想要研發一個前所未有的，具有一切人腦功能，但比人類更聰明的電腦機器人。

沒想到偶然的機緣，使這個創造成果發生在我自己身上。我是查理士在世時，以他個人的頭腦為藍本所一手創造出來的機器人。我具有他頭腦的完整拷貝；也就是說，雖然我有金屬的軀殼，我的確不折不扣是他頭腦的複製人。

＊＊＊＊＊＊＊＊＊

說來話長，我本是一個專攻人工智慧的電腦學家，不幸於事業顛峰的五十三歲得了致命的癌症。我自知餘生無多，於是有了一個奇想：如果我能創造一個自己的拷貝，擁有我全部的記憶及各種個性因子，我就可以在肉身死亡之前重現於人世。於是我日以繼夜的研究、突破，終於在實驗室中創造出目前這個電腦人的我。

當我這個電腦人誕生的一剎那，我睜開了眼睛，好像是睡了一大覺醒來，只是身體各處的感覺都很奇怪。我伸手一看，發現那是一隻金屬的手臂，再摸摸自己的身體，我才驚覺我已變成一個機器人。哇！我嘔盡心血的創作真的成功了！

我慢慢起立站直了身子，看到實驗室裡我所熟悉的一切。看到我日常工作的座位和工作台，看到實驗室的每個夥伴，也看到我自己，那個肉身的查理士。只見他一副驚喜的樣子，激動得趕快過來緊握著我的手問說：「你是查理士嗎？」

「當然是呀！」我回答他說。於是，我們就像兄弟般地擁抱在一起。他又說：「很高興看到你的誕生，而且發現你能看、能聽、會講話、能夠行動；最重要的，還曉得自己是誰，我們這項研發的第一步算是成功了！」

「恭喜你的研發成功！」我接著回答他說：「其實那也是我的成功呀！我更有幸親身體驗了這個過程的一切，那可是具有肉身的你無法辦得到的，所以我比你更高興啊！」

看他有點脹然的樣子，似乎我才是整個研發案的主角而不是他。當然，這不能怪他，雖然他認為我和他完全相同，在他的理解中，我仍然只是他的分身，我們仍是獨立的個體。但對我來說，除了我們一個有肉身、一個是機器外，其實我們完全是同一個人；因為查理士直到創造我為止的一切，都活生生地存在於我的記憶體之中。所以，我清清楚楚地瞭解查理士就是我本人。而查理士必須倚靠一些測驗來證明我就是他。

於是，查理士對我做了一連串的測驗。首先，他驗證了我的電子、機械和知覺功能都屬正常；然後就考驗我的記憶，包括印證一些兒時的往事及一些只有我和他才知道的特殊事件。於是他問我說：「還記得那次好像是六歲時差點被公車碾死的經驗嗎？」

我回答他說：「當然記得，那是小時候最難忘的一次記憶。那次的感覺好像公車的輪胎都已碰到了後腳跟，真的是非常嚇人！」

他顯得非常興奮，就接著說：「對呀！你說得沒錯，正是那種感覺，雖然那應該是一種錯覺。後來一連三年都做著那個恐怖的夢！還多次從夢中嚇醒，真是可怕！」

「沒錯！」我繼續說：「有一次嚇醒時叫得太大聲還驚動了母親過來替我摸頭壓驚。」

他有點詫異的表情，就說：「好像有那麼回事，但細節有些模糊了！」

就像這樣，我們共同追憶了許多其他的童年趣事，但他常常會有記憶模糊的地方，而我卻能如數家珍般地說出當時的每一個細節，也常常令他驚訝不已。當然，這就是電腦和人腦的差別；我的記憶體中包含了許多查裡士腦中不容易回憶起的深層記憶。年代久遠了人腦會記憶模糊，我這個電腦卻不會，沒有深層與淺層記憶的區別。任何東西只要存在於我的記憶體中，就能毫不費力地於瞬間取出，也永遠不會忘記。

例如，和我同時畢業的小學同學，查裡士只記得大約三分之一的名字，我卻全部記得，能夠清楚地把他們的名字一一說出，好像那次畢業典禮就是昨天的事。

這一切的測驗都證明他的創造物是完全成功的，無論是查理士和我的記憶、經驗、甚至連各種想法和對事物的反應都完全一致。至於我有遠超過他的記憶能力及不會忘記任何東西這一點，倒是他從來沒有想到過的。

他非常興奮地對我說：「你是如此的完美，比我想像的還要更好！」他想了一下，接著又說：「雖然我們都是查理士，總要有個區別，我就叫你小查理士好了，也方便大家對你有個稱呼。」

（未完待續）

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

更多文章請到筆者個人網頁瀏覽，筆者文章都歡迎轉載，更竭誠歡迎您的回應及指教！

康哲行 (cskang)

電子郵件：cskang@mail.tbcnet.net
個人網頁：http://www.nspo.org.tw/~kang

Smart.fm+iPhone == 最佳的語言學習機

2009-06-11T06:58:00.001+08:00

自從開始學習日文, 我對於電腦的語言輔助學習軟體就一直非常有興趣, 從使用Anki來記日文單字, 到利用iKnow讓背單字更好玩, iKnow之前在網站宣稱可以將複習完的單字課程轉換成
podcast , 並讓使用者訂閱同步到iTunes ,與iPod/iPod touch/iPhone , 這個功能我當時有試出來, 但是只有聲音確看不到文字, 因此對於這個podcast功能總覺的不是那麼實用, 畢竟在聽
單字與例句的發音同時, 如果有文字的對照會對語言的學習比較沒那麼有恐懼感, 等熟悉了, 在直接來訓練聽力就可以了, 這樣在語言學習過程會比較有趣一些. 前一陣子, mobile01一群網友
看了我之前寫了一篇youtube轉podcast的howto, 開始分享了許多podcast的link , 這讓我重新對podcast有了不同的想法, 原來網路的影音串流礙於頻寬還不是那麼成熟, 利用訂閱的方式來下載影音的需求
還是存在的, 我試過使用iPhone 3G直接看YouTube , 也許你不相信, 我的頭會發暈, 我懷疑是電磁波造成的, 但是對於收文字訊息的e-mail覺得還ok , 我對通訊與電磁波沒有研究, 但以物理角度, 傳輸大量的資料需要較多的能量, 這定律應該是不變的, 3G的電磁波強度是否會隨著網路的資料傳輸量而變化, 這是我一直懷疑的, 如果有學過通訊的網友, 還煩請幫我解惑.

回到我提到的podcast , podcast的好處就是在使用Notebook or Desktop上網時, 預先將Video or Audio下載下來, 然後再sync到ipod/iPod touch/iPhone , 這樣做有一個好處, 不用讓手機隨時上網去抓取Video/Audio來看, 這也免除了我頭暈之苦:-). 有一陣子, 隨著3G, WiMax等高速無線網路的發表, 我對podcast的發展是有疑慮的, 所以並沒有花太多時間去注意podcast的應用, 但是看到mobile01網友的熱烈討論, 又開始整理我的iTunes中訂閱的podcast, 其中我發現了之前訂閱過的iKnow, 我想起了iKnow的podcast+單字例句的服務如果可以真的在iPhone上顯示, 這真的是非常好的語言學習應用, 於是我又試了一遍, 這次的單字與例句總算可以顯示出來, 這樣總算可以解決無法邊聽日文單字例句發音, 邊看單字與例句的文字與翻譯的問題. 這個podcast語言學習應用對於iPhone而言絕對是殺手級應用. iPhone不只是iPhone而且是一台絕佳的語言學習機.

以下是我在iTunes與iPhone上所看的畫面

同步到iPhone後的使用畫面

smart.fm的podcast使用howto 可以參考這裡

附帶一提, Smart.fm對於台灣可能有點陌生, Smart.fm 是日本公司, 但是它的網路介面確以英文為主要語言, 看起來Smart.fm的企圖心是針對全球的語言學習市場, 從這個網站的創意與應用, 可以看到Web 2.0的應用延伸的手機的一個典範, 希望我寫這篇文章能激起你對Web服務與手機整合的想像力並開發出許多殺手級應用.

版本控制圖解指引

2009-06-01T10:51:00.007+08:00

以下為之前翻的"DVC(Distributed Version Control)圖解說明"所refer的說明Version Control的文章, 此也採用圖解說明,清楚且容易了解,徵得作者的同意,在此將他的文章翻譯如下:

A Visual Guide to Version Control (版本控制說明)

原文:BetterExplained http://betterexplained.com/articles/a-visual-guide-to-version-control/

版本控制(又稱Revision Control或Source Control) 讓您隨時追蹤檔案的內容變動. 為什麼你要關心這檔事? 這樣當你搞砸時可以很簡單的回復前一工作版本.

你也許自己編造了版本控制系統, 卻沒發現你在用如下"天才"的檔案名稱. 你有這樣的檔案嗎? (但願..你沒有完全和下面相同的.....)

KalidAzadResumeOct2006.doc
KalidAzadResumeMar2007.doc
instacalc-logo3.png
instacalc-logo4.png
logo-old.png

這就是為何我們都用“Save As”. 你想要新檔不會將舊檔蓋掉. 這是常發生的問題, 解決方法經常像這樣:

做個single backup copy (Document.old.txt).
如果我們夠聰明, 我們加個version number或date: Document_V1.txt, DocumentMarch2007.txt
我們甚至會用shared folder, 這樣其他人可以不用e-mail傳檔即可看到或編輯檔案. 希望他們記得重取檔案名再存回去.

所以呢...為什麼我們需要Version Control System (VCS)?

運用分享的folder/naming system對於典型的專案或一次完成的論文還可以. 可是對於軟體開發的專案呢? 沒有什麼機會行得通的...
你可以想像在分享的檔案夾中的Windows source code像“Windows2007-Latest-UPDATED!!”給大家來編輯嗎? 那麼每位程式設計師只會在各自的子檔案夾工作? 不可能這麼做的.

大型的, 同時多人參與編輯, 快速變更的專案需要一個版本控制系統(Version Control System )- “file database”的專業說法, 來追蹤所有變更以避免混亂. 一個好的版本控制系統(VCS)應可滿足以下需求:

Backup and Restore(備份與復原). 檔案在編輯時被儲存, 你可以跳回之前的每一時刻所編輯的版本. 如你需要回溯到2007年2月23日的檔案...沒問題.
Synchronization(同步). 讓大家分享檔案且隨時可取得最新的版本.
Short-term undo(短期的版本回復). 隨意玩弄檔案或搞砸時? (你就是有可能如此, 不是嗎?). 就把所做的變更扔掉吧, 並回到貯存庫(repository)中所知的"好"版本.
Long-term undo(長期的版本回復). 有時我們真的搞得太糟了. 假設你是在一年前做了這個不良的更改,產生了bug. 這系統應能幫你跳到那個版本, 並了解當時做了什麼變動.
Track Changes(追蹤變動). 當更新檔案時, 你可以留下為何變更的紀錄(此要存在VCS,不是在檔案裡). 這樣可以容易的看出這個檔案隨著時間的演進與原因.
Track Ownership(追蹤負責人). VCS可以標出每個變更的人名,已示負責.
Sandboxing(沙盒), 或自我的保險. 正在做大幅的變動嗎? 你可以暫時到獨立的區域做此變動, 測試, 將問題解開, 然後才將你的變動上呈(check in)回去.
Branching and merging(分支與合併). 更大的沙盒(sandbox). 你可將你的程式碼拷貝一份branch(分支)到獨立的區域做修改, 並獨立追蹤在上面的變更. 過些時候, 再將你的工作成果合併到主要共同開發的區域.

分享的folders雖然快又簡單, 但無法做到這些功能

學習相關用語

大多數的版本控制系統(version control systems)牽涉以下的觀念, 有可能用詞有點不同.

基本設定

Repository (repo)貯存庫: 儲存檔案的資料庫.
Server（伺服器): 貯存庫所在的電腦.
Client（終端機): 與貯存庫連線的電腦.
Working Set/Working Copy（工作組或備份): 你終端機上的檔案目錄,與你工作編輯變更的地方.
Trunk/Main(主開發線): 在repo裡存放程式碼的主要地方. 將程式碼想像為一個族譜(family tree)--"trunk"即為主支.

基本動作

Add(新增): 將一個檔案第一次放進貯存庫(repository), 也就是說開始用版本控制來追蹤此檔案
Revision(修訂版): 一個檔案位於哪個版本 (v1, v2, v3, etc.).
Head(頭版): 存在貯存庫(repository)的最近版本.
Check out(簽出): 從貯存庫(repository)下載一個檔案.
Check in(簽入): 如檔案內容變動時,將檔案上載到貯存庫(repository). 此檔案將獲得新的版本號碼, 別人將可"check out"最近的版本.
Checkin Message(簽入說明): 說明做了什麼變動的簡短訊息.
Changelog/History(變更歷史紀錄): 從一個檔案成立起所經歷的所有變更列表.
Update/Sync(更新/同步): 將你終端機的檔案與貯存庫的最近資訊做同步. 此可讓您擷取到所有最新的檔案.
Revert(回復): 拋棄你終端機上的變更並叫出貯存庫中最近的檔案.

進階動作

Branch(分支): 製作分開的檔案/檔案夾備份以便獨立運作(解bug, 測試等等). Branch可說是動詞(branch the code)也可說是名詞(which branch is it in?).
Diff(差異分析)/Change(變更)/Delta(差分): 找出兩的檔案的差異. 可幫忙看出版本間的變動內容.
Merge/Patch（合併/補釘): 將一個檔案的變更運用到另一個, 使其為最新內容. 譬如, 你可以合併一個branch到另一個做功能的整合. （在Microsoft, 此稱為 Reverse Integrate and Forward Integrate)
Conflict(衝突): 當一個檔案的變更與其他變更發生衝突時, 兩者無法同時採用而必須暫緩實施.
Resolve(解決): 解決變更的衝突問題並簽入(check in)正確版本
Locking(上鎖): “掌控” 某檔案至你解鎖(unlock)此檔案其他人才能編輯此檔. 有的版本控制系統有這樣的功能以避免同一檔案中變更的衝突.
Breaking the lock(強力解鎖): 強迫解鎖某一個檔案以便編輯. 這個功能也許在某人把哪個檔案鎖起來後度假去了(或當Halo 3遊戲發行那天"請病假").
Check out for edit(簽出編輯): 簽出(Checking out)一檔案的“可編輯”版本. 有些版本控制系統原始設定即有可編輯的檔案,有的需要清楚的指令.

典型的劇情可發展如下:
Alice 新增(add)一個檔案(list.txt)到貯存庫(repository). 她將此檔案簽出(checks out),做了些變動(把 “milk”放到列表中),然後將此簽入(check in), 同時寫簽入的說明 (”加入需要的項目.”). 隔天早上, Bob 更新(updates) 他終端機的工作組, 看到最新list.txt的版本, 此含有“milk”. 他可以瀏覽changelog或diff 看到Alice在前一天加了 “milk” .

視覺化案例

在此故意給您高階的說明:大多的教學指引都給你一堆文字指令. 讓我們走過高階的觀念,不在syntax打轉( Subversion手冊永遠都在那裡, 不用擔心). 有時去試探到底有什麼可能性總是不錯的. always there, don’t worry). Sometimes it’s nice to see what’s possible.

Checkins(簽入)

最簡單的情境是簽入一個檔案(list.txt)且花時間去修改它.

每次我們簽入一個檔案的新版(new version), 我們將拿到一個新修訂版(new revision-每個revision的內容含多個檔案at different version) (r1, r2, r3, etc.). 在Subversion你將會做:

svn add list.txt
(modify the file)
svn ci list.txt -m "Changed the list"

此 -m 旗標(flag) 使用來做此checkin的訊號.

Checkouts(簽出)與Editing(編輯)

實作上, 你有可能不是一直簽入檔案. 你應該是 check out(簽出), edit(編輯) 再 check in(簽入). 這樣的周期看起來如下:

如果你不喜歡你做的變更, 想重頭來的話, 你可以revert（回復) 到前一版本再重新來過(或就此停止). 當簽出時, 原始設定讓你取得最近的修訂版(revision). 如果你想要的話, 你可以指定所要的修訂版(revision). 在Subversion, 執行:

svn co list.txt (get latest version)
...edit file...
svn revert list.txt (throw away changes)

svn co -r2 list.txt (check out particular version)

Diffs(差異)

主開發線(trunk)有檔案變更的歷史紀錄. Diffs是你編輯(editing)的變更內容 : 想像你可以 “剝下” 他們然後將他們放入一個檔案:

例如, 從 r1 到 r2, 我們加入eggs (+Eggs). 想像剝出紅標然後將其放入r1, 以變成r2.
又如要從 r2到 r3, 我們加入 Juice (+Juice). 由 r3 到 r4, 我們去掉 Juice 並加入 Soup (-Juice, +Soup).

大多數的版本控制系統 儲存 diffs 而非所有檔案的內容. 如此可以省磁碟空間: 4個revisions並非指有 4個copies; 我們有1個copy和4個小小的diffs. 很簡潔, 是吧?

在SVN, 我們如下做兩個修訂版(revisions)的diff(差異):

svn diff -r3:4 list.txt

Diffs幫助我們看到變更內容(”你如何再次修正bug?”) 甚至用到一個branch和其他的比較.
加碼問題: r1 到 r4的差異(diff)是?

+Eggs
+Soup

請注意“Juice”甚至完全沒出現 — 若直接從 r1 跳到 r4 根部不需要此變更, 因為 Juice 被Soup蓋掉了.

Branching(分支)

Branches讓我們拷貝程式碼到一個獨立的檔案夾隨意修改運用:

譬如, 我們可以開一個branch來實驗新想法: 瘋狂的事情像加入Rice和 Eggo waffles. 要看你用的是什麼版本控制系統,有的系統在你開branch時會變動revision的號碼. 好了, 現在我們有一個branch, 我們可以變更我們的程式碼並實驗我們的怪怪想法. ("嗯..waffles? 我不知道老闆會怎麼想. 打賭用Rice應該安全才對) 由於我們是在分立的branch上行事, 我們可以獨立修改或測試, 看看這些修改會不會傷害其他的部份. 且在branch裡的修改都有版本控管的歷史紀錄.

在Subversion,你可以很簡單地將一個目錄做個copy另取名字, 就可以開一個branch了.

svn copy http://path/to/trunk http://path/to/branch

如此branching不是個太艱深的觀念: 假裝你已拷貝你的程式碼到另一個目錄. 你有可能已將學校的專案的程式碼做了branch, 確保你有一個安全的環境嘗試失敗版本以便如果搞砸了可以回復沒問題的版本.

Merging(合併)

Branching聽起來很簡單,對吧? 不過, 不見得喔 — 解決如何將一個branch的變更合併到另一個可以說很傷腦筋.

讓我們假設要將 “Rice” 從我們實驗性的branch併入主線(mainline). 我們要如何做呢? 做 r6 和 r7的差異分析(diff)然後將差異併到主線?

錯錯錯. 我們只想取用在branch上做的變動. 意思是我們做 r5和r6的diff, 然後將diff送到主開發線 (main trunk):

如果你做r6 和 r7的差異分析, 我們將漏掉 “Bread” (譯者註:因為r6和r7的diff將為-Bread, +Rice, 將這個diff加到r7, r8將少了Bread),而"Bread"應該在主開發線上. 這是精巧之處 — 想像從實驗性branch“剝出”的變更(+Rice)並加進去主線. 主線上也許有別的變更, 如此做就沒問題了-我們只是插入Rice功能.

在Subversion, merging(合併)和diffing(差異分析)非常相近. 請在主線上, 執行以下指令 :

svn merge -r5:6 http://path/to/branch

此在實驗性的branch上所做的指令diffs r5-r6並將此diff加到目前所在. 不幸地, Subversion並沒有簡單的方法來追蹤已做過那些merges(合併),如果你不小心, 有可能會重併同樣的變更. merge tracking為SVN改善計畫中的功能, 目前我們勸你做好變更記錄,提醒自己"r5-r6變動已合併到主開發線了". (譯者註:SVN1.5開始有merge tracking）

Conflicts(衝突)

多半VCS(版本控制系統)可以自動合併一個檔案不同地方的變更. 當有些變更顯然無法黏合時衝突就出現了: Joe想要去掉eggs以cheese替代(-eggs, +cheese), 而Sue 想要以hot dog 替代eggs(-eggs, +hot dog).

此時競賽產生: 若 Joe 先簽入(check in), 系統可自然接受此變更 (而後Sue就無法做她要的變更了).

當變更的地方相同且有像這樣的衝突時, VCS將可能呈報衝突訊息(conflict)而不讓你簽入(check in)— 此時如果你是Sue, 你可以決定是否要簽入(check in)一個解決(resolves)兩難的新版本. 處理方法可為:

Re-apply your changes. 先同步到最近的版本(r4)然後再到此最新版做你要的變更: 到此已經有cheese的列表加入hot dog.
Override their changes with yours. 將最新的版本(r4)簽出(check out),將你的版本內容拷貝過去 , 再簽入(check in). 結果, 這將把cheese換成hot dog.

雖然衝突不會常常發生, 但蠻惱人的. 通常我採用先同步到最近版本再將我的變更加進去.

Tagging(標籤)

誰曾想過版本控制系統竟然有Web 2.0的觀念? 很多系統讓你在任一想要的revision貼標籤tag(label)以方便參考. 如此你可以說參考"“Release 1.0″而不用指出在系統內特有的建置號碼(build number):

在Subversion, tags跟 branches編輯方法類似,只要你想要做即可執行; 此功能存在乃為了清楚之後所有版本的發展, 所以你可以完全清楚看出在 version 1.0的發佈版本中內容為何. 且你將有個票根,就這了, 沒別的方法.

(in trunk)
svn copy http://path/to/revision http://path/to/tag

實作的案例: 管理Windows開發程式

我們猜想Windows開發可運用其自己的分享檔案夾來管理它的開發程式, 不過事實並非如此. 那麼, 它是如何做的呢?

有個主開發線, 此處存有穩定建置的Windows.
每一組(Networking, User Interface, Media Player, etc.) 有他們自己的branch發展他們各自的功能. 這些branch為正在開發中且較主線不穩定的發展內容.

你在新功能的branch開發,然後用“Reverse Integrate (RI)” 併回主線. 之後, 你 “Forward Integrate"且從主線拿到最近的變更併入你的branch:

假設我們在 Media Player 10 和 IE 6. Media Player 團隊在他們的branch做了version 11. 當其完成並通過測試, 產生從10到11的patch, 此被主線採用 (就像 “Rice” 的例子, 不過複雜些 ). 此為reverse integration, 從branch到trunk. IE團隊也可同樣執行.

之後, Media Player 團隊可以取得其他團隊最近更新的程式碼, 如IE的. 如此, Media Player forward integrates 並從主線獲得最近的patches整合回他們的branch. 這有點像之前的例子去拉主線的"Bread"到實驗性的branch, 但, 也是比較複雜.

所以這就是所謂的RI和FI. 哼哼, 這樣的安排可以讓變更先在branches互相協調, 也同時讓新的程式碼不干擾主線的穩定度. 酷吧 ?

事實上, 可以有很多層次的branches和sub-branches, 配合品管度量來決定你何時要做RI. 不過要知道: branches幫助您處理複雜度. 現在你知道一個大型的軟體專案基本上是如何組織了吧.

Key Takeaways(重點提示)

我的目標是分享有關版本控管系統的高階想法. 以下為基礎要點: :

Use version control. 認真告訴你,這是個好東西,就算你不是寫OS那麼大的東西. 就算單人用也值得.
Take it slow. 我也是現在才開始為我的專案了解如何做branch和merge. 才開始要運用這樣的功能來管理. 如果你的專案還小, branch和merge可能不是個問題. 維護大專案的人應該對branches和patches的追蹤很有經驗了.
Keep Learning. 可以參考很多指引: SVN, CVS, RCS, Git, Perforce 或更多你正在使用的系統資料. 重要的是把觀念搞清楚並意識到每個系統有它自己的行話和哲理. 也建議參考Eric Sink的 detailed version control guide.

以上是基礎資料 — 隨著時間我將分享我從做my projects學到的東西. 現在你已了解一般的版本控制系統(VCS),也可以看看 an illustrated guide to distributed version control （DVCS分散式版本控制系統圖解說明).

DVCS(Distributed Version Control System)介紹

2009-05-25T18:04:00.010+08:00

最近看到一篇相關DVCS(Distributed Version Control System)的文章, 深入淺出, 徵得作者的同意, 在此將他的文章翻譯如下:

Distributed Version Control 分散式的版本控制 (圖解)說明

原文：BetterExplained http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/

傳統的版本控制輔助檔案的備份,追蹤與同步. 分散式的版本控制讓變更的分享簡單容易. 如果你做的對, 你可以魚與熊掌兼得: 不費力的合併(Simple Merging)同時可集中做版本發佈(centralized releases).

要分散式的嗎? 一般的版本控制到底發生什麼問題?

沒有問題 — 如果你想快速回憶的話請參考 a visual guide to version control . 當然, 有些人可能會嘲笑你還在用"古老"的系統. 但在我看來仍然是OK的: 對於任何專案來說有用版本控制系統(VCS: Version Control System)總是正向的一步. 集中的版本控制系統在1970年代出現, 當初程式設計者有了精簡型終端機(thin clients)但同時也欣羨又大又貴又快速的"big iron" mainframes（誰能不被當時風行的大小通吃8bits到1 byte的機器吸引呢?)

集中管理是簡單的概念, 很自然是第一步想到的：讓每個人到同一個地方簽入簽出, 就像集中到某個圖書館的書本上註記一樣.

如此的做法對於備份(backup),復原(undo)和同步(synchronization)行得通, 不過對變更的合併(merging)與分支(branching)卻不太行. 當專案成長時, 通常會想將功能切割, 獨立開發與測試, 再逐步將變更併入主開發線. 實際做時, 分支就很麻煩, 新的功能可能要做龐大的簽入(checkin), 如果中間有任何差錯, 變更變得很難管理也很難做問題排解. 當然, 集中控管的系統也總有"可能"做合併(merging), 但並不容易: 你需要親自確實追蹤合併的動作與內容, 以避免同樣的變更被做兩次. 分散式的版本控制系統讓分支(branching)與合併(merging)無痛執行, 因為這是此類系統的長處.

一些圖解(Diagrams), 請看...

別的教學多是嚴肅的文字指令(text commands), 在此提供您視覺化的說明. 讓你回想一下運用典型集中控管的貯存庫(repository) 的狀況:

每個人與主開發線同步也將資料簽入主開發線: Sue加入soup, Joe加入juice, Eve加入eggs. Sue的變更必須先簽入主開發線材會被其他人看到. 的確, 理論上, Sue可以另開一個新的分支(branch)讓其他人在她的分支上測試, 可是在一般的版本控制系統(VCS)如此做很麻煩.

Distributed Version Control Systems (DVCS)

依分散式(distributed)模式, 每位開發者有他們自己的貯存庫(repository). Sue的變動存在她個人端的貯存庫(repository),她可以決定是否要跟Joe或Eve分享:

不過是否有可能造成像無頭的圓環一樣循環呢? 不會的, 如果想要的話, 每個人可以將他的變動推(push)給同一個貯存庫(repository), 存疑地, 就像上述集中的模式一般. 此人為的貯存庫(franken-repo)包含了Sue, Joe和Eve的變動.

我希望分散式版本控制DVC(distributed version control)可以有不同的名稱, 如 “獨立的(independent)”, “聯合的(federated)” 或 “點對點的(peer-to-peer)”. 此字 “distributed”讓人聯想到分布式運算, 工作被分派給一群機器(如尋找外星智慧訊號的 SETI@home {可參考SETI@home台灣網站} 或做蛋白質摺疊分析Protein folding).

而DVCS並不像Seti@home: 每一端(node)是各自獨立的且是否分享由各端自我決定(在Seti, 你必須回覆你的結果)

5分鐘說明主要觀念

此給你基本概念; 如果你有興趣, 可參考相關patch theory的說明書 .

核心概念

集中式版本控制聚焦於同步(synchronizing),追溯(tracking), 和備份(backing up)檔案.

分散式版本控制聚焦於變動分享(sharing changes); 每一變更有其全域唯一辨識碼(guid-global unique id)或unique id.

記錄(Recording)/下載(Downloading)以及採用(applying)一個變更被視為分別的步驟 (在集中式系統, 此三者同時發生).

分散式系統沒有強制的架構. 你可以建立"中央管理"區或讓個人保持各自端運作.

新術語

推(push): 將變更送給其他的貯存庫(repository) (應該需要其他repository擁有者的允許)

拉(pull): 從另一貯存庫(repository)抓資料

關鍵優勢

每人都有其本端的沙盒(local sandbox). 你可以在自己的工作機修改或回覆前版, 不需要大量的簽入(checkins). 你自己的工作記錄都累積存在自己的repository.

可離線工作. 你只有當你想分享變更時才需要上線. 否則你可隨你高興一直在自己的工作機上獨立作業, 簽入(check in)或復原(undo), 沒有所謂"伺服器"當掉或在飛機上的問題.

速度很快. 差異(diff), 上呈碼(commit)與回覆(revert)都在本端即可完成. 沒有因網路或伺服器不穩而必須用一年前開發版本的問題.

可妥善做變動的處理. DVCS針對分享的變更做建置. 每個變更都有其獨一無二的辨識碼(guids)以方便追蹤.

分支(Branching)與合併(merging)很容易. 因為每一開發人員"有自己的分支", 每一分享的變動就像交換整合. 但guids讓自動組合變更與避免重複動作簡單容易.

較少的管理. DVCS很容易執行; 沒有所謂的“總在運作的”伺服器軟體需要安裝. 此外, DVCS也不太需要你去"加"新的使用者; 你只是去撿選你想從那裡拉(pull)資料的URLs. 這樣可以避免大型專案中令人頭痛的政治性問題.

關鍵劣勢

仍需要備份. 有個說法是你的“備份”就是其他人有你變更資料的終端機資訊. 我無法認同—如果這些其他人終端機資料並沒有採用你所有的變更呢? 或是當你變更的時候他們都不在線上? 用DVCS, 你仍希望可以有台機器讓你push所有的變更到他那裡保存“以防萬一”. (在Subversion, 你有一台隨時待命的機器做主要的資料貯存庫, 建議您在DVCS也做一樣的事).

沒有所謂的“最近的版本”存在. 如果沒有集中地, 你無法馬上知道是否要到Sue, Joe或Eve那取得最近變更的版本(version). 再者, 一個中央集中地才可幫助大家清晰知道最近的"穩定版本"為何.

沒有真正的修訂版號碼(revision numbers). 每一貯存庫有依變更做出的修訂版號碼. 和傳統的貯存庫不同的方法,人們依變更的修訂號碼做溝通: "請問你有變更號碼 fa33e7b? " (記住, 這ID是一個不好看的guid總體唯一辨識碼). 還好, 你可以用有意義的名字貼標你發佈的版本.

Mercurial 快速上手(Quickstart)

Mercurial速度很快,是個簡易的DVCS. 暱稱是hg, 就像水銀(Mercury)元素一樣.

一旦Mercurial已開始其目錄(Directory), 看起來將如下:

你將有:

一個工作中的考本(working copy). 你正在編輯的檔案群.

一個貯存庫(repository). 一個目錄(Mercurial的.hg)包含所有的補釘(patches)以及資料背景(metadata:comments, guids, dates, etc.). 因為沒有集中的伺服器, 所以這些資料都放在你這裡.

在我們的分散式案例, Sue, Joe和Eve有他們各自的貯存庫(repository), 儲存他們不相干的修訂版歷史資料(revision histories).

理解更新(Updates)與合併(Merging)

在研究DVCS時有幾項讓我有些混淆. 第一, 有幾步將造成更新(updates)

Getting(取)變更到貯存庫：pushing(推) 或 pulling(拉)

Applying(採用)變更到檔案中：update(更新) 或 merge(合併)

Saving(儲存)新版：commit(上呈)

第二, 依據變更, 你可以update或merge:

當無模糊地帶時,Updates發生. 譬如, 我將變更拉到一直以來都是你在編輯的檔案. 因沒有重疊的變更,檔案將跳到最近的修訂版(revision).

當我們的變更發生衝突時,就有必要Merges合併. 如果我們兩個都去編輯檔案,最後會變成兩個"分支", 類似平行宇宙(alternate universes-多種假設同時發展的各個故事)的樣子. 有個我修改的世界, 也有個你修改的世界. 在此例, 我們可能想要合併成一個單一的宇宙.

我仍在整理DVCS到底可多容易的產生分支與摺疊分支:

在此案,因為 (+Soup) 和 (+Juice) 為同一個母項(parent-僅一個 “Milk”的列表)的變更, 有必要做合併(merge). 經過Joe合併檔案後, Sue可以做一般的 “pull和update” 即可獲得Joe已合併的結果. 她不需要親自做合併的動作. .

在Mercuril, 你可如下執行:

是的, “pull-merge-commit” 周期蠻長的. 幸運地, Mercurial有整合多指令(commands)為單一的捷徑. 雖說看起來好像蠻複雜的, 但仍比在Subversion手動合併(merge)簡單多了.

大多數的merges是自動完成的. 當發生衝突時, 一般可以很快被解決. Mercurial持續追蹤每一變更的 parent/child關係(我們的合併列表有兩個母項parents), 與"heads(最新版)"或每一分支的最近變動. 在merge前我們有兩個heads;之後, 一個.

組織一分散式專案(Distributed Project)

此為一種組織方式:

Sue, Joe和Eve將變更加入一共同的分支. 他們可以跟任一人交易patches來做"buddy builds（兄弟建置)"：嘿老兄, 請問要試試這些patches嗎? 在推給實驗分支(experimental branch)前,我需要看看此是否可行.

然後, 經維護守門員在看過,將實驗分支的變更拉到穩定的分支(stable branch), 此有最近的版本. 分散式的版本控制系統(DCVS)幫助每一變更獨立進行, 但也提供集中系統所有的"single source(單一來源)". 有多種開發的模式可用, 如"pull only",此只有維護守門員決定是否要從別人拿取變更資料, Linux的開發採用此種,或"shared push", 此和集中管理的系統作業模式很類似. DVCS讓您彈性選擇要採用哪種方法來維護您的專案.

練習和嚴厲批評以臻至善

我是DVCS新手,但很高興分享我目前已瞭解的. 我覺得SVN很好用, 但覺得去了解如何可以讓merge簡單容易也有趣. 我的建議是你可以從Subversion起步, 感受一下什麼是team collaboration(團隊協同作業),再實驗分散式的模式. 如果你適當的籌劃, DVCS可以達到集中控管系統的效果, 你也同時可享有簡易merge的好處.

線上資源

Mercurial 有超優的說明. 如果在Windows上, 你有可能需要 diffing/merging software 或 TortoiseMerge (如果你已安裝TortoiseSVN ).
Darcs 有很詳細的 wikibook (有一些相關變更的數學理論).

Git 由Linus Torvalds創造. 以下為他相關DVCS有趣的演說 ;如果你在用集中管理的系統, 準備被訓一頓吧:

從Linus演說影片節錄:

“How many have done a branch and merged it? How many of you enjoyed it?”

“When you do a merge, you plan ahead for a week, then set aside a day to do it.”

“Some people have 5, 10, 15 branches”. One branch is experimental. One branch is maintenance, etc.

“CVS — you don’t commit. You make changes without committing. You never commit until it passes a giant test suite. People make 1-liner changes, knowing it can’t possibly break.”

所以呢.... 祝好運囉, 密切注意聖戰狀況...

兒時的夢想-機器人

2009-04-11T12:24:00.003+08:00

上星期掃完墓帶了我的外甥育葦去台中的市民大道看發明展, 最主要是去帶他去看迷你機器人, 他在車上問我一個問題, 我差點答不出來, 他問我

舅舅! 為什麼你跟我一樣喜歡機器人?

我想了好久, 一時不知如何回答, 我跟他說, 我在學校就是學機械自動控制的, 我還會控制機器人, 他看了我一眼, 一臉不太相信的神情, 好像我在唬弄他, 所以我想拿一張照片出來, 以後他看了我的Blog會發現他的舅舅不是在唬他的:-)

這張照片, 是我在盟立自動化最後一天, 圖中的機器人夾爪與機構的設計與組裝, 還有機器人的動作程式, 我都有參與到, 算是從機械業畢業的紀念照:-) 我希望育葦看到這篇Blog已經是10年後或是20年後, 至少在他認真追求過他的夢想後再來看我走過的路, 也許他會走的比我更好也不一定..

喜歡機器人應該是從念小學時代的一部卡通-無敵鐵金剛說起吧! 很奇怪, 我小時候對於機器人也是超迷的, 但是那個年代不像現在有變形金剛, 有鋼鐵人, 這麼炫的電影, 那時候對無敵鐵金剛迷到房間的牆壁上, 都是我手繪的無敵鐵金剛的造型, 我努力回想兒時的夢想, 也許是受到南宮博士的啟發, 我在國小三年級的一篇作文-我的志願寫著, 我長大要成為科學家, 為人類的生活的進步而努力, 我只記得這幾句, 因為當時老師覺得我這篇作文寫的非常好, 念出來給全班的同學分享, 當時我坐在下面聽有點驕傲, 但是心裏卻有點空虛.

做機械自動化, 其實回想起來是很迷人的一件事, 當你看到你所設計的機構, 按照你的構想而動作時, 那會是很大的成就感, 跟寫程式或是軟體的樂趣很相似, 但是機械設計不像軟體設計, 驗證與測試是最難的, 寫軟體有整合式的開發環境可以馬上做測試. 但是機械設計圖稿發包出去到零件組裝, 這中間可能要隔幾週, 等將零件一件一件組裝起來測試後, 才能驗證設計的東西是否真的可行, 如果不行, 那會是一件很頭痛的一件事, 如果稍作修改, 加個墊圈, 或是改個螺絲孔位置, 這算是小事, 但是機構在真正客戶端運作時, 沒有考慮到生產環境, 造成機構無法運作, 整組機械就要等著被拆解的命運. 我曾經參與一件自動化案, 計畫主持人太過自信, 沒有去客戶生產線將所有周遭的物品與位置量測好, 結果設計好幾個月的機構進到客戶工廠, 當場大塊肢解, 做大幅度的變更後才結案, 下場很慘.

所以我記得當時設計圖畫好時, 必須先交給課長-->經理, 審圖後才將設計圖發包給零件製作廠商製作. 就算是製作回來, 或多或少還是要修改, 我進入軟體業後, 真的有來審核我的source code的只有William, 還有Eric , 這件事一直到我去帶專案, 才發現source code的審核, 比起機械設計審核, 難上很多, UML雖然將coding給視覺化, 但最終還是要審核工程師的code, 才能確保軟體的品質或是降低軟體的維護成本. 機械設計除了其設計是看的見, 摸的著, 而且機械發展了許多標準, 例如
機械製圖有所謂的CNS國家標準, 還有機械設計中許多零組件也都很標準化. 軟體業變化太快了, 一下子C, C++, Windows SDK, Java , .Net etc. 技術經理如果技術一直沒跟上來, 如何做source code review ?

後來我離開了盟立, 為何要放棄自己10多年的專長(3+1+2+4)? 這件事說來話長, 最主要的原因應該是我看不到我可以預期的未來, 我當時也曾想要進一步去考研究所, 繼續研究自動控制, 但是當年1995, Windows從3.1邁入了Windows 95, 網際網路開始風行, 報紙攤開, 電視廣告, 幾乎都有網路如何改變人類生活的消息與新聞, 資訊業當時的願景給我帶來相當大的想像空間, 就這樣,我成為機械自動化產業的逃兵, 也一頭栽進了軟體資訊產業, 一直到現在, 鶩然回首, 竟然已經在資訊界待了14年.

比爾蓋茲曾經說過, 做自己喜歡的事.

所以無論是做機械, 或是軟體, 或是任何的工作, 都要喜歡它, 投入它, 而不是一時的熱度, 這是我希望我的外甥們看到我的blog, 能帶給你們最大的啟發!

我的Kindle 2支援中文顯示了

2009-04-05T02:19:00.001+08:00

DSCN2419，原由 mao-yang 上載。

使用了這位Hacker的Unicode Font patch http://www.blogkindle.com/2009/04/unicode-fonts-for-kindle-2-v01/

終於讓我的Kindle 2也可以顯示中文了, 我將中文存成Text檔, 存到Kindle 2的documents目錄, Kindle 2的Reader似乎可以直接開純文字檔, 而且顯示中文字型沒有問題, 字型可以放大, 縮小, 可以寫註解, 做Book mark, 但是無法畫線, 但是這樣算是很滿意了

Kindle2 支援Unicode?

2009-04-03T17:09:00.001+08:00

看到這個消息 , 心裡有點振奮, 看起來讓Kindle2支援中文字型, 並非遙不可及的事, 但是就算Kindle支援了中文字型, 國內的出版業準備好了嗎?