IT : 是工作還是嗜好?

今日Borland正式宣佈把CodeGear售出給資料庫管理工具領導廠商Embarcadero，Borland 終於結束在開發工具市場競逐霸主的時代，也但願CodeGear脫離Borland之後能夠發展的更好，一個輝煌的時代終於結束了。

http://www.borland.com/us/company/news/codegear_sale_announce.html

盼著Q5出來已經很久了，在昨天看到Q5的照片之後大為欣賞，在決定努力存錢之際，立刻就call了我一個也喜歡Q5的sales朋友，告訴他Q5出來了趕快存錢。沒有想到這位老友聽我要他努力存錢的話之後居然告訴我『Q5算什麼, 存錢存5Q就能買Q5，至於技術人員嘛，哼哼，大概至少要存5冬吧』。ㄨㄚ ㄌㄟ 技術人員至少要存5冬? 那等我存夠了之後下一代的Q5都出來了，而這位老兄到時連買第6代Q5的錢都存夠了，Sales v.s. 技術人員是5Q和5冬的分別嗎? ㄨㄚ ㄌㄟ 那我也要做Sales啦。

記得以前上大學時，在修有關電腦程式方面的課程時，曾有許多老師都說要當程式設計師需要需要的條件，其中之一就是要有耐心，因為程式設計師需要在終端機面前一坐是是好幾個小時細心的工作，那些皮癢又沒耐心的人是無法或是不適合做這個行業的。看著當時老師斜視著我說這些話的表情，我心只想著完了又要進五當山修煉了，打從我白目的第一次邊吃東西邊進電腦室打作業就被這位老師當成眼中釘了，因為當時的電腦可是名貴的不得了，不但不可以在電腦室喧嘩，打keyboard更需要小心翼翼的不要把電腦打壞了，當然更別說是在電腦室吃吃喝喝了，因為當時據說在電腦室吃東西電腦會壞掉喔。

老實說我從來不是耐心很好的人，8,9年前當Java興起時我就不耐Java當時的龜速，常在當時的電腦面前咬牙切齒的想為什麼要使用這麼緩慢的東西，更早以前在我大二時C語言剛被人們學習，對於當時沒有C語言除錯器，只有C語言編譯器和C語言連結器的時代，除錯時都需要在程式碼中插入print/printf來檢驗數值，也常常不耐煩的想把keyboard砸壞，現在回想這些經歷也不禁莞爾，雖然自己沒什麼耐心但卻進入這行有這麼多年了。為什麼會提到這些事情呢?這都得從前年底，去年初開始學習RoR說起。

當時在初學了RoR之後立刻被RoR的快速學習和開發能力所震撼，接著便是把大部份的時間投入了RoR的世界，享受著好久沒有再回味過的技術愉悅之感，在學習RoR的過程中也使用了不同的IDE，從RadRails到NetBeans，但我當時就有一個迷惑，那就是雖然Ruby和Rails是如此的好用，在測試方面也整合了TDD，但為什麼就是沒有一個好用的除錯器?當時的Ruby除錯器不是很難用就是慢的跟烏龜一樣(DLTK的Ruby除錯器)，有的Ruby除錯器甚至是2者的結合，當然更別說想要有一個好用的RoR除錯器了，我當時的迷惑是難到RoR的開發人員都不會寫出臭蟲嗎? 如果RoR的開發人員也像其他程式語言的開發人員一樣是『人』，只是藉由RoR擁有了較高的生產力和較大的愉悅感，那麼理當也會寫出臭蟲，最多是寫出的臭蟲少一點罷了，但也需要好用的除錯器才能夠減少除錯的時間啊。這個迷惑在我閱讀了愈來愈多的Ruby/Rails相關書籍之後有了比較明確的答案，因為在許多的Ruby/Rails書籍中原來除錯彷彿回到了以前C的年代，是在命令列中擷取出應用程式中類似的程式碼片斷的語法來觀察錯誤，或是在RoR的View中使用一些控制項來顯示相關的數值以便檢查，wow，這樣的方式讓我不耐煩的感覺又出來了，RoR的生產力是高，但除錯力太低，還是沒有到達到我理想的境界，當時我就想找一個RoR IDE能夠提供高效率的RoR除錯能力，但即使是後來CodeGear的3rdRail 1.0亦沒有包含一個堪用的Ruby除錯器(3rdRail也是使用DLTK的Ruby除錯器)，更別說RoR除錯器了，因此我又點想砸keyboard了，因為我不想再使用古早的方式來臭蟲，我的不耐煩只想讓我儘快找到一個好用的RoR除錯器。

就是這種不耐煩讓我更期待3rdRail 1.1，因為3rdRail的R&D團隊本身也苦於RoR的除錯，因此3rdRail 1.1最重要的開發目標就是提供一個快速的RoR專屬除錯器，因此當3rdRail 1.1正式釋出之後我就迫不及待的使用新的RoR除錯器來測試(好啦，我承認在3rdRail 1.1 beta時我就已經在使用了)，果然3rdRail 1.1的RoR除錯器好用得讓我感動不已，RoR結合3rdRail的RoR的除錯器才是RoR攻無不克的利器嘛。3rdRail 1.1的RoR除錯器不但快速得像其他程式語言的除錯器一樣，讓RoR的開發人員在除錯時不再像播放慢速電影一樣，更重要的是3rdRail 1.1的RoR除錯器提供了豐富的資訊，讓RoR的開發人員不但可以檢視所有的變數，更重要的是連HTTP的所有請求/回覆資訊也都可以一覽無遺，讓使用RoR開發Web應用程式時實在太好用了。

3rdRail 1.1的RoR除錯器不但可以讓RoR的開發人員在RoR程式碼中任意設定中斷點來除錯，3rdRail 1.1的RoR除錯器也能夠結合其他技術來除錯RoR應用程式，例如下面的畫面是我最近在閱讀『Flexible Rails』這本討論結合Flex 3和Rails的技術以開發RIA(Rich Internet Application)應用程式的書籍時，我甚至可以在操作以Flex 3製作的GUI時觸發以RoR撰寫的應用程式邏輯的畫面，在畫面的右上方中我可以使用3rdRail 1.1的RoR除錯器來檢視由Flex 3 GUI元件傳遞來的HTTP請求所有的內容，並且在3rdRail 1.1的RoR除錯器中繼續除錯以RoR撰寫的應用程式邏輯，3rdRail 1.1的RoR除錯器能力讓開發人員在結合這兩種強大的Web技術時變得輕而易舉，再也不是一件苦差事，我也不需要像『Flexible Rails』這本書中使用的原始又費時的方式來除錯Flex 3+RoR的RIA應用程式了，3rdRail 1.1讓我在閱讀『Flexible Rails』這本書時快樂不已。

由Flex 3製作的GUI

在3rdRail 1.1的RoR除錯器中除錯Flex 3 + RoR應用程式

如果您也還在苦苦尋找RoR的除錯器，我強烈的建議您試試3rdRail 1.1的RoR除錯器。當然3rdRail 1.1除了強大的RoR除錯器之外，也是第一個整合了Rails 2.0.2以及Ruby 1.8/1.9的IDE，成為學習/使用Ruby 1.8/1.9/Rails 2最好的IDE，我個人也是推薦的啦。

Flex 3 + RoR應用程式使用了Ruby 1.8.6和Rails 2.0.2

所以我個人是覺得耐性不好在IT界不見得是缺點，只要能夠轉化為儘早找出更好的解決方法就好啦。

在2008年3月6號Dr. Dobb's正式宣佈CodeGear的3rdRail取得了今年在RoR IDE方面的Jolt Awards大獎，證明了去年我還是CodeGear員工時就一直看好3rdRail這個產品的眼光。話說自從前年開始迷上RoR之後我就一直在找尋好用的RoR整合發展環境，因為那時Borland/CodeGear本身並沒有RoR的IDE，在使用了包括了RadRails，NetBeans等RoR的IDE之後，雖然覺得比起使用命令列+UltraEdit的生產力高，但總覺得和CodeGear的IDE有些差距與不習慣。不過自從CodeGear決定開發一個全新的RoR IDE之後我就立刻加入了這個產品的Beta過程，當3rdRail逐漸成熟之後很快的就追上了其他較早推出的RoR IDE而且逐漸的青出於藍，當3rdRail 1.0正式推出之前，我個人覺得3rdRail 1.0已經是一個相當好的產品，我唯一還想要的就是一個好用又快速的現代RoR除錯器，但即使3rdRail 1.0最終沒有包含專屬的RoR除錯器，但我個人認為就『產品本身』來說3rdRail已經擁有成功的本錢，但我不知道CodeGear在銷售和市場面將如何成功的推動3rdRail。

果不其然，在3rdRail 1.0發表之後CodeGear採取的銷售/市場模式令我失望，因為CodeGear居然不準備為3rdRail進行產品發表和技術研討會，當時我心中想這麼好的產品在不做任何活動的情形下注定將是叫好不叫座的結果，於是去年我大力爭取CodeGear一定要在大中華區為3rdRail做產品發表以及技術研討會，即使大中華區不做，至少也要在台灣做，後來CodeGear APAC區勉強同意讓台灣做2場3rdRail產品發表，那就是分別在台北和新竹僅有的2場3rdRail的活動。當時台北/新竹2場的3rdRail活動吸引了將近130人參加，更重要的是其中有許多參加人員從來不是CodeGear的客戶，這讓我非常的滿意，原本當時計劃在2008年第1季繼續往中南部發表3rdRail並且從台北開始舉辦3rdRail+RoR的技術研討會，可惜事情變化的太快，這些計劃使終沒有實現，讓我扼腕不已，這麼一個好的產品就這麼…。如今3rdRail 1.0不但獲得了Jolt Awards大獎，CodeGear也宣佈了正式推出3rdRail 1.1版，不但加入了專屬的RoR除錯器而且執行速度是DLTK的Ruby除錯器的4倍，3rdRail 1.1也支援Rails 2.0和Rails的重構等強大的功能，這讓3rdRail 1.1成為當今開發Rails 2.0應用程式最好的IDE。

另外一個CodeGear的好產品就是即將推出的Delphi For PHP 2.0，Delphi For PHP 2.0的進步令我大感驚訝，雖然我現在主要已經使用3rdRail進行Web的開發工作，但Delphi For PHP 2.0的功能是如此飛躍的進步，幾乎和3rdRail 1.1各佔鰲頭，只是一個是使用Ruby而另外一個是使用PHP，因此Delphi For PHP 2.0又讓我花了一些時間使用並且研究它。

那麼Delphi For PHP 2.0提供了什麼好功能給PHP的開發人員呢?嗯我個人認為最重要的是Delphi For PHP 2.0的IDE工作速度有著顯著的提升，這個讓PHP開發人員在Delphi For PHP 2.0中進行視覺化的圖形使用者介面設計時終於有了和Delphi/C++Builder等一樣的速度，另外Delphi For PHP 2.0提供了視覺化樣版設計能力，讓PHP開發人員終於擁有了像ASP.NET等類似的視覺化設計功能，這是非常cool的功能，也應該是許多PHP開發人員長久以來想要的功能。

此外Delphi For PHP 2.0也充分的支援UTF-8等編碼機制，完整的解決了中文工作環境的問題，Delphi For PHP 2.0也擁有了更好的除錯器，整合了PHP Profiler讓PHP開發人員可以進行效率調整，提供Sync Edit和Code Formatter的編輯器，也支援Zend框架並且封裝了數個Zend VCL元件讓PHP開發人員可以直接使用拖曳的方式使用Zend架框中的功能，wow，其中直接支援Zend框架讓Delphi For PHP+Zend架框幾乎擁有和3rdRail+RoR一樣強大，方便的MVC開發能力，這是讓我從3rdRail+RoR回來鑑賞Delphi For PHP 2.0和PHP技術最重要的原因。

從3rdRail和Delphi For PHP 2.0可以看出CodeGear真的繼承了原始Borland的精神，因為3rdRail和Delphi For PHP 2.0都是由極小的團隊就開發出來的優秀產品，例如3rdRail的核心R&D團隊不到5個人，但是做出來的產品卻可以打敗其他由數十人組成開發的RoR IDE，可見3rdRail團隊效率之高，只是CodeGear雖然產品愈做愈好，但行銷似乎仍然像以前一樣，令人咳咳咳…

對於我這個5年級學習資訊科學的人來說，Nicklaus Wirth是不能忘記的偉大軟體科學家，Nicklaus Wirth的”Algorithm+Data=Program”這本資料結構的書籍是我大二時在台大圖書館中最常苦讀的書籍(呵呵，當然是因為要應付考試啦)。Nicklaus Wirth發明的Pascal程式語言深深的影響了資訊界長達數10年之久，然而隨著最近10年物件導向程式語言成為資訊界程式語言的主流後，要不是Borland/CodeGear的Delphi與時併進並且為Pascal加入最先進的物件導向的功能，Pascal也不可能在今日仍然是非常流行的程式語言之一(http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)。Nicklaus Wirth的偉大貢獻最終讓他獲得了Turing Award，算是實至名歸了。

為什麼我要在篇文章中再提到Nicklaus Wirth呢?因為隨著Delphi Unicode的版本的逼近，最近更讓我回想起Nicklaus Wirth的”Algorithm+Data=Program”這句話說的真好。最近幾年由於物件導向的流行，因此大部份的開發人員使用了類別，物件，元件等技術封裝運算法則和資料，讓用戶端不必瞭解內部實作的技術，這聽起來和看起來都很棒，但是開發人員如何在內部藉由實作運算法則來處理資料卻仍然可能撰寫使用了非常糟糕的程式碼，有句成語『金絮其外，敗絮其內』可能蠻適切的能夠形容這種情形。例如許多開發人員可能分不清楚什麼是encoding的意義，也分不清楚Length和sizeof的意義，在許多的情形下也分不清楚陣列中位元組和元素的分別。當然，會造成這些問題的原因是因為大多數的開發人員是從原生程式語言開始寫程式碼，在我們學習BBC的第一步腦中就充滿了位元，位元組，字元的觀念，而從C/C++背景來的開發人員更習於使用指標運算來加速資料存取的速度並且節省程式碼的撰寫。如果你會問腦中有這些觀念或是使用指標存取有什麼問題呢?那麼我們至少可以列出下面的數個問題:

•   開發人員必須知道++, --等使用在字元指標，整數指標和陣列指標的不同

•   Windows OS有16位元，32位元和64位元，資料型態在這些OS中的大小一樣嗎?

例如下面是一些Delphi程式碼，您可以明確的說出它們的意義或是運算結果是什麼嗎?

sdata := 'IT : 是工作還是嗜好?';

iLen := Sizeof(sdata);

iLen := Length(sdata);

而如果我使用下面的程式碼存取出的又是什麼結果呢?

sdata := 'IT : 是工作還是嗜好?';

for iIndex := 1 to Length(sdata) do

begin

  ListBox1.Items.Add(sdata[iIndex]);

end;

啊，如果您很認真的思考上面的話，我很抱歉，我故意耍了一個小手段，因為我沒有告訴您sdata的資料型態是什麼，sdata可以是string，也可以是widestring，也可以是AnsiString，不同的資料型態在目前的Delphi中會有不同的結果。例如AnsiString/String是使用reference counting的方式來處理字串資料(faster)，而WideString則否(copy on write, slower)。此外使用陣列存取AnsiString/String和WideString的結果也不同。

正是由於OS平台的不同，資料型態的不同，開發人員使用的程式碼不同，讓程式碼中夾雜了許多不具移植性，甚至是可能發生錯誤的程式碼，因此我才說在即使是在物件導向程式技術盛行的今日，別忘了Nicklaus Wirth的公式:

Algorithm+Data=Program

中的Data仍然是整個應用程式中佔有一半的因素，我個人認為Java和.NET的好處之一是除了程式碼深具移植性之外，Java和.NET平台也讓Data具備了通透性，讓開發人員不再容易寫出可能的錯誤程式碼。Java/.NET虛擬平台讓開發人員享受到資料通透性的好處，那麼原生Windows開發人員也可以嗎?這個意思是說原生Windows開發人員可以在使用指標或是陣列索引的同時又能夠享受到資料通透性的好處嗎? 答案在於編譯器和框架的發展如何!

以Delphi和C++Builder來說，隨著VCL框架可同時執行於Win16，Win32和Win64，再隨著Delphi/C++Builder Unicode的版本即將提供資料通透性的能力，再加上Delphi下一版的編譯器中內含helper函式和資料自動轉換的能力，下一版的Delphi/C++Builder將同時提供Java/.NET虛擬平台最大的2項優勢:

程式碼+資料的跨平台通透性

而且加入Java/.NET虛擬平台沒有的優點:

快速的原生執行速度

因此在以前的Delphi/C++Builder版本中AnsiString/String是以如下的結構來實作:

那麼只要未來的Delphi/C++Builder先定義UniCode結構:

再定義:

type
  string = UnicodeString

那麼就可以通透的把string自動改為Unicode資料型態並且可以執行在Win32/Win64平台之中，開發人員也只需要修改最少的程式碼，也就是和處理Data運算有關的程式碼，那麼從此之後開發人員的應用程式就有了資料通透性了。

一旦如此，當您使用:

sdata := 'IT : 是工作還是嗜好?';

for iIndex := 1 to Length(sdata) do

begin

  ListBox1.Items.Add(sdata[iIndex]);

end;

程式碼來存取資料時，就不會是讓人看不懂的:

而是正確的:

因為資料擁有了通透性，開發人員再不需記住繁瑣的不同的資料型態使用不同的存取方式程式碼了。

未來的Delphi/C++Builder版本再次讓Delphi/C++Builder的開發人員進入了新的世代，當VCL框架/編譯器提供了程式碼+資料的跨平台通透性之後，就為Delphi/C++Builder奠定了未來平行/多核開發的基礎。

”Algorithm+Data=Program”也是歷久彌新啊!

上個星期剛從上海完成了HP的Together/MDA教育訓練，回到台北之後雖然台北也開始冷了起來，但和上星期的上海比較起來，反而覺得台北好溫暖。其實上星期上海溫度最冷時也不過是零下2,3度，和我最冷在北京遇到零下10度比起來絕對溫度還差了好幾度，只是上星期上海又下雨，浦東的風又大，因此感覺特別冷，這次居然讓我凍成了紅面關公，臉被風吹得又紅又腫，摸著自己的臉也疼痛不已，看來這次是真的凍傷了。

這次在上海一個多星期主要是為了給HP進行Together和MDA/DDA的課程，在出發之前說實在的心情蠻低落的，因為我已經記不得上次教授Together和MDA/DDA的課程是多久以前的事情了。以前在Borland時曾經為客戶上過各種不同的課程，後來Borland成立了PSO之後就上得比較少了，因為課程後來就由PSO的同事負責，只不過偶而被客戶特別點名時還是得披掛上陣。由於我已經太久沒有上過超過3天以上的課程，因此這次出發上海之前我都不知道要如何熬過這麼多天的訓練，尤其是這次的課程內容比較深入，壓力也比較大，不過由於以前也上過多次的Together課程，因此也覺得有有些乏味，一直重覆講述相同的課程是是當初我不想做Borland PSO的重要原因。

1月15日早晨我迎著少少的雪花往HP在雲橋路的訓練教室出發，心中仍然不知如何度過這看起來漫長的一天。在課程開始之後，一如我預期的一般是緩慢而讓我有點乏味的步調，不過在我和學員之間慢慢熟悉起來之後氣氛開始慢慢的活潑起來，我立刻發現參加的學員是擁有豐富的開發經驗，因為當他們開始詢問問題時我便開始瞭解學員的背景和實力，因此我決定在一開始使用較為快速的步驟講述基本的觀念和UML，但是把多出的時間留下來討論實際的開發經驗和問題上。以前在Borland教授Together的課程時大都是根據Borland的講義內容，但隨著這些年各種軟體技術的出現和進步，也讓我對於課程的內容有了更為深入自己的看法，因此在這次的Together/MDA教育訓練中，當我講述如何以實際的範例從分析模型，到需求設計，再到設計模型，部署模型，再討論MDA/DDA的內容，結合OCL/QVT 把設計模型，部署模型從CIM，PIM最終映射成PSM的過程中，雖然是以Java技術為主要的討論內容，但我也以ROR，ECO，設計樣例，DSL，分析樣例和實務的設計來輔佐課程的內容，讓我在一個星期的時間中講(玩)得非常盡興，我想參加的學員也應該很有收穫(我希望啦)。

這次的課程讓我跳出了固定課程內容的範疇，能夠輔以目前最新，最流行的各種技術和知識來講述Together/MDA的內容並且展示各種MDA/DDA規範是如何實作在目前各種軟體產品，架框和語言中也讓我也受益匪淺，『教學相長』是我這次去上海最大的收穫，雖然HP參加的學員是幾乎90%以上是使用Java，但我相信能夠看看其他語言，架框的精髓是非常有幫助的，而且就模型和CIM/PIM的角度來看，特定平台，特定語言和特定架框並不是那麼的重要的。

所以這雖然我的臉頰凍傷了，但心中卻充滿了技術的火熱喜悅。

2007年CodeGear陸續發表了Delphi for PHP 1.0以及RoR的專門開發工具3rdRail 1.0，正式進入動態程式語言的開發工具領域，在這兩個動態程式語言開發工具發表之後立刻獲得了很不錯的評價和回饋。當然我知道有許多人在觀望CodeGear是否是真的想要好好發展動態程式語言的開發工具，畢竟CodeGear是一間不大的公司，而且許多人對於後期Borland在開發工具一些的作為也都非常的感冒，不過我不討論CG的銷售和市場策略，因為我現在不代表CG了，我只討論產品和技術方面的問題。

在昨天我Post了『12/11，12/13台北，新竹3rdRail產品技術發表』一文之後立刻得知了3rdRail 1.01發佈的消息，因此我立刻啟動我的3rdRail，並且在3rdRail IDE中利用Update Manager更新到了1.01版，依據CG的說法這個更新版本主要是修改1.0的臭蟲並且增加執行效率。在Update Manager更新完成之後，我立刻重新啟動3rdRail 1.01，結果發現真的比1.0快上一些，使用上更舒服了，特別是在使用Dependencies View和Code Insight時，1.01明顯比1.0快上許多，現在我更期待3rdRail的下一個更新版了，以目前CG在RoR開發工具的表現來看，CG的3rsRail團隊是非常認真的。

在Delphi For PHP方面也有更好的消息，Delphi For PHP 1.0在數個更新之後，CG立刻開始了Delphi For PHP第二版本的開發工作，從第二版本想實作的功能來看，Delphi For PHP的雄心非常的堅強，對於使用PHP的開發人員來說應該是非常具有吸引力的，Delphi For PHP第二版也應該會讓還在對Delphi For PHP觀望的朋友放心，因為Delphi For PHP將會是PHP開發工具中最強勁的競爭對手之一，也許等消息更明確之後我們可以詳細的談談Delphi For PHP第二版本的功能。

不過我的困擾是面對這麼多不同的開發工具和技術，那夠時間學習和使用啊，我可不想得上資訊焦慮症或是憂慮症，看來還是打打魔獸比較快樂一點。