在上一篇文章中我介紹了如何使用Tiburon建立一個簡易的以JSON為基礎的分散式架構，在本篇文章中我將繼續討論如何結合原本Delphi/BCB開發人員熟悉的DataSnap架構和JSON架構以便開發出新一代以JSON為基礎的分散式架構，如果您使用過DataSnap，又閱讀了前面數篇文章，那麼這將非常的簡單，畢竟RAD精神就是讓您簡單的就能夠開發出您要的架構，不是嗎?當然如果您想要追根究底的瞭解DataSnap/JSON技術，提供了完整原始程式碼的VCL框架也可以讓您學習到許多的技術。
為了簡單說明起見，我延用『Tiburon遊記3 動手建立一個DataSnap JSON伺服器吧』這篇文章基本的內容來建立分散式DataSnap和JSON架構，請您交互參考本篇和『Tiburon遊記3 動手建立一個DataSnap JSON伺服器吧』文章的內容。
步驟 1 – 建立分散式JSON伺服器
前5步驟是一樣的，接著
6. 選擇File|New|Other，建立Server Module如下:
Server Module的型態是TDSServerModule，讓我們看看它的定義:
{$MethodInfo ON}
TDSServerModule = class(TProviderDataModule)
end;
{$MethodInfo OFF}
果然，TDSServerModule即是資料模組，只是以{$MethodInfo ON}和{$MethodInfo OFF}包圍宣告，因此它的繼承類中宣告的方法將可輸出到用戶端。
7. 在Server Module中拖曳資料庫中的資料表到其中，例如下圖是我把Blackfish SQL中的SEMINARS資料表拖曳到Server Module上:
8. 在Server Module的類別中，我宣告和實作了一個public方法GetSeminars如下:
function TDSServerModule1.GetSeminars : TDataSet;
begin
Self.SEMINARS.Open;
Result := Self.SEMINARS;
end;
由於在DataSnap 4中我可以直接把TDataSet傳遞到用戶端，因此在GetSeminars中我只需要把SEMINARS這個TSQLDataSet物件傳遞回用戶端即可，DataSnap會自動以JSON封裝TDataSet的物件。
9. 在JSON伺服器的TDSServerClass元件的OnGetClass事件中輸出Server Module類別:
procedure TForm10.DSServerClass1GetClass(DSServerClass: TDSServerClass;
var PersistentClass: TPersistentClass);
begin
PersistentClass := TDSServerModule1;
end;
現在編譯並且執行JSON伺服器，接著就可以建立分散式用戶端了。
步驟 2 – 建立分散式用戶端
前3步驟是一樣的，只是TSqlServerMethod元件的ServerMethodName特性連結到TDSServerModule1.GetSeminars方法。
4. 在主表單中加入DataSetProvider元件連結到TSqlServerMethod，這是因為TSqlServerMethod呼叫的TDSServerModule1.GetSeminars方法會回傳一個TDataSet，因此就可以做為資料提供者，DataSetProvider元件就可以以這個回傳的TDataSet做為資料的來源
5. 放入TClientDataSet元件，連結到DataSetProvider元件
從步驟4,5可以看到這和以前使用DataSnap開發用戶端是 樣的，但是現在是連結到JSON伺服器。
6. 最後再放資料感知元件和一個Button元件，在Button元件中撰寫:
procedure TForm11.Button1Click(Sender: TObject);
begin
Self.ClientDataSet1.Active := True;
end;
以開啟並且存取資料。
下圖是我同時執行三個分散式用戶端同時存取一個步驟1開發的JSON伺服器的畫面:
您可以看到用戶端成功的從JSON伺服器取得了資料並且顯示在資料感知元件中。
請注意這個應用系統重要的意義，用戶端不需要再載入各種資料庫驅動程式，只需要DataSnap的用戶端DLL和程式本身就可以從JSON伺服器取得資料，因為現在資料都以JSON格式傳遞，DataSnap 4這種用戶端是真正的thin-client。
使用Tiburon開發JSON架構的分散式應用系統是不是又簡單，又強大呢?如果您需要更多的處理能力，那麼VCL框架中提供了許多相關的JSON處理類別可以讓您呼叫使用，這些進階的主題就留待其他文章來討論了。
Have Fun!
Tiburon遊記3 動手建立一個DataSnap JSON伺服器吧
DataSnap新的JSON分散式架構可以有許多不同的型態，更可以結合資料庫和Web應用程式，不過在一開始讓我們先學習如何建立最簡單的JSON分散式架構，下面是我們即將實作的JSON分散式架構的簡單說明:
1. 建立一個分散式JSON伺服器，在JSON伺服器中提供伺服端的服務方法讓用戶端`可以呼叫使用
2. 建立一個DataSnap用戶端應用程式，藉由TCP + JSON架構呼叫分散式JSON伺服器提供的服務
在步驟1中我們將看到Tiburon新的Reflect功能如何把伺服端的服務方法輸出，而步驟2我們則可以看到Tiburon的DataSnap元件如何在原有的元件中加入可以處理JSON分散式架構的功能。
步驟 1 – 建立分散式JSON伺服器
要建立分散式JSON伺服器非常的簡單，它的步驟如下:
1. 建立一個VCL Form的應用程式
2. 在主表單中加入TDSServer元件，TDSServer元件負責JSON伺服器和用戶端的生命週期管理，並且提供了許多管理的機制。
3. 在主表單中加入TDSTCPServerTransport元件，TDSTCPServerTransport元件使用Indy做為底層TCP通訊元件，TDSTCPServerTransport元件內定上使用211通信埠做為和用戶端連結的通信埠，它並且可以提供通訊池的功能以便有效率的使用伺服器的資源
4. 在主表單中加入TDSServerClass元件，TDSServerClass元件可以把伺服器中的類別輸出給用戶端呼叫，或是把資料模組，遠端資料模組中的方法輸出給用戶端呼叫-。TDSServerClass元件藉由Tiburon新強化的RTTI和Reflect程式單元中的功能以達成這種能力。對於需要輸出服務給用戶端的類別，資料模組或是遠端資料模組，必須使用新的編譯器指令{$MethodInfo ON}和{$MethodInfo OFF}包圍類別宣告。
5. 連結TDSTCPServerTransport元件到TDSServer元件，此時主表單應該看起來如下:
現在在這個範例VCL Form的應用程式專案中加入一個新的程式單元，並且撰寫如下的程式碼:
unit uServerMethod;
interface
uses Sysutils, classes;
type
{$MethodInfo ON}
TServerMethodClass = class(TPersistent)
public
function Hello(const Name: string): string;
end;
{$MethodInfo OFF}
implementation
{ TServerMethodClass }
function TServerMethodClass.Hello(const Name: string): string;
begin
Result := 'Hello ' + Name;
end;
end.
各位可以看到上面宣告了一個TServerMethodClass，它必須從TPersistent類別繼承下來，由於它需要函式Hello到用戶端，因此在TServerMethodClass類別之前和之後使用新的編譯器指令{$MethodInfo ON}和{$MethodInfo OFF}包圍，如此一來Tiburon的編譯器在編譯這個類別時便會產生額外的RTTI資訊。
6. 在TDSServerClass元件的OnGetClass事件處理函式中撰寫如下的程式碼:
procedure TForm6.DSServerClass1GetClass(DSServerClass: TDSServerClass;
var PersistentClass: TPersistentClass);
begin
PersistentClass := TServerMethodClass;
end;
TDSServerClass元件的OnGetClass事件是用戶端向DataSnap JSON伺服器查詢可呼叫的服務類別時被呼叫，由於在這個範例中我們是要輸出TServerMethodClass類別之中的Hello函式，因此在OnGetClass事件處理函式中把參數PersistentClass設定為TServerMethodClass類別。
現在這個分散式JSON伺服器已經完成，編譯它並且執行它，現在我們就擁有了一個不再需要使用COM/COM+的分散式伺服器了，它簡單，方便又快速，接下來我們就可以建立用戶端應用程式來呼叫它提供的服務方法了。
步驟 2 – 建立分散式用戶端
要建立分散式用戶端也非常的簡單，它的步驟如下:
1. 建立一個VCL Form的應用程式
2. 在主表單中加入TSQLConnection元件，在它的Driver特性中選擇使用DataSnap，並且在HostName中輸入分散式JSON伺服器的名稱，由於我們是在相同的機器中執行，因此可以輸入localhost。另外注意它的Port特性值也是內定為211，各位可以參考下面的圖形:
3. 在主表單中加入TSqlServerMethod元件，連結它到步驟1的TSQLConnection元件，此時下拉它的ServerMethodName特性便可以看到許多伺服器輸出的方法，其中有許多方法是和管理有關的，我們以後有機會再說明，在這些輸出的方法中我們可以找到分散式JSON伺服器輸出的TServerMethodClass.Hello，如下圖所示，請選擇TServerMethodClass.Hello。
TSqlServerMethod元件可以讓開發人員在用戶端呼叫遠端分散式JSON伺服器輸出的服務方法。
4. 最後在主表單的Button控制項的OnClick事件處理函式中撰寫如下的程式碼:
01 procedure TForm7.Button1Click(Sender: TObject);
02 begin
03 Self.SqlServerMethod1.ParamByName('Name').Value := Edit1.Text;
04 Self.SqlServerMethod1.ExecuteMethod;
05 Edit2.Text := Self.SqlServerMethod1.ParamByName('ReturnParameter').AsString;
06 end;
請注意在03行中我們設定TSqlServerMethod元件的Param特性中’Name’這個參數的數值，但是’Name’這個參數是從那裡來的? 請回頭看看前面TServerMethodClass.Hello函式的宣告原型，它接受一個參數，它的名稱就是’Name’，因此TSqlServerMethod元件可以分析遠端JSON伺服器輸出的方法，每一個參數的名稱就成為TSqlServerMethod元件的Param特性中的名稱，而當TSqlServerMethod元件呼叫ExecuteMethod方法真正的執行完畢遠端JSON伺服器輸出的方法後，如果遠端JSON伺服器輸出的方法會回傳函式值，接著開發人員可以藉由'ReturnParameter'這個名稱的參數來取得執行的結果，如同上面05行所示。
現在我們執行用戶端，點選按鈕就可以看到遠端JSON伺服器輸出的方法果然正確回傳了執行結果。
使用簡單的Delphi Reflect功能
Tiburon強化了RTTI並且提供了簡易的Reflect程式單元可以讓JSON伺服器輸出服務到用戶端，我們也可以利用這個功能來驗證一下。
首先我建立一個新的VCL應用程式，在專案中建立兩個額外的類別，一個類別使用新的編譯器指令{$MethodInfo ON}和{$MethodInfo OFF}包圍:
unit uServerMethod;
interface
uses Sysutils, classes;
type
{$MethodInfo ON}
TServerMethodClass = class(TPersistent)
public
function SayHello(const Name: string): string;
function GetReflectMessage : String;
procedure ReflectMe;
private
FData : String;
end;
{$MethodInfo OFF}
另外一個則否:
unit u沒有MethodInfo的程式單元;
interface
uses Sysutils, classes;
type
TServerMethodWithoutMethodInfoClass = class(TPersistent)
public
function SayHello(const Name: string): string;
function GetReflectMessage : String;
procedure ReflectMe;
private
FData : String;
end;
各位可以看到Tiburon支援了Unicode之後連程式單元的名稱都可以使用中文命名。
接著我在主表單中加入參考ObjAuto程式單元，並且使用下面的程式碼就可以取得類別方法的資訊:
procedure TForm7.btn有MethodInfo的按鈕Click(Sender: TObject);
var
aClassObj : TServerMethodClass;
mdArray : TMethodInfoArray;
iCount: Integer;
begin
aClassObj := TServerMethodClass.Create;
try
mdArray := ObjAuto.GetMethods(aClassObj.ClassType);
for iCount := 0 to Length(mdArray) - 1 do
begin
ListBox1.Items.Add(mdArray[iCount].Name);
end;
finally
aClassObj.Free;
end;
end;
procedure TForm7.Button2Click(Sender: TObject);
var
aClassObj : TServerMethodWithoutMethodInfoClass;
mdArray : TMethodInfoArray;
iCount: Integer;
begin
aClassObj := TServerMethodWithoutMethodInfoClass.Create;
try
mdArray := ObjAuto.GetMethods(aClassObj.ClassType);
for iCount := 0 to Length(mdArray) - 1 do
begin
ListBox1.Items.Add(mdArray[iCount].Name);
end;
finally
aClassObj.Free;
end;
end;
ObjAuto.GetMethods可以取得類別方法的資訊，如果類別沒有使用新的編譯器指令{$MethodInfo ON}和{$MethodInfo OFF}包圍，那麼就無法產生足夠的RTTI資訊，因此用戶端將無法存取(看到)類別中的方法。現在執行這個範例VCL應用程式，我們可以看到左邊的ListBox可以顯示TServerMethodClass類別中的方法，而右邊的ListBox則無法顯示TServerMethodWithoutMethodInfoClass類別中的方法。
下圖是我使用TCP Viewer觀查前面分散式JSON伺服器和分散式用戶端之間訊息的結果，我們可以看到它們之間的確是使用JSON格式在傳遞訊息。
Tiburon的分散式JSON架構除了可以輸出伺服器的服務之外，也可以結合資料庫實現真正的Thin-Client，離線資料架構型態的應用系統，這些都基於Delphi開發人員原本就熟悉的DataSnap架構，我很快的會寫一小篇文章展示它是多麼的容易而且又是使用我們熟悉的DataSnap元件。
Have Fun!
Tiburon遊記2 DataSnap和JSON
什麼是JSON，我想我不必多說，因為Internet上一堆有關JSON的說明各位可以自行搜尋，簡單的說JSON是一種資料傳遞的格式，流行於JavaScript和Ajax的世界。OK，那麼JSON和DataSnap又有什麼關係? 當DataSnap應用於分散式架構時不是使用COM/COM+嗎?Tiburon的DataSnap為什麼要使用JSON呢?
其實這些問題在我第一次知道DataSnap使用JSON時也立刻出現在我腦中，不過一經思索很多問題的答案就立刻浮現了出來而且也立刻延伸出了許多其他的想法，知道為什麼嗎? 因為在我觀察任何技術時我還是喜歡馬上看看站在這個技術後面的人的背景以及這個技術代表的趨勢，現在讓我還原一下當初我腦中思考的過程。
還記得Steve嗎?它現在是Delphi/C++Builder在資料存取技術方面的架構師，我以前也寫過有關Steve的文章，其中敘述了Steve是來自Java的背景，因此在VCL架框中屬於Steve小團隊開發的程式碼中我都可以感覺到些許Java的味道，特別是在一些架構方面更是清楚的透露了Steve的背景。既然我們瞭解了Steve的背景，那麼當Steve在面臨負責DataSnap的研發方向時你覺得Steve會怎麼做?
因此讓我們試著分解前面的數個問題，:
|
問題 |
種類 |
答案&方向 |
|
當DataSnap應用於分散式架構時不是使用COM/COM+嗎 |
這是屬於分散式架構訊息傳遞層的問題。OK，想想看，當COM/COM+不再是主流時，DataSnap如果仍然使用COM/COM+那麼將會愈來愈封閉。 |
找出一種跨平台和主流的分散式通訊協定和訊息傳遞格式，TCP + JSON肯定是最好的選擇之一。 |
|
DataSnap為什麼要使用JSON呢 |
這是屬於策略的問題，DataSnap使用了JSON之後可以開啟什麼樣的機會之門? 簡單，Delphi/BCB可以立刻和所有使用JSON技術的軟體整合在一起。 |
DataSnap使用JSON做為分散式架構訊息的格式後，不但可以脫離COM/COM+的限制，又可以結合跨平台(Win64也可以使用)，也可以和Java，Ajax，.NET整合，讓Delphi可以立刻融入Web上主流訊息格式的世界。 |
|
JSON和DataSnap又有什麼關係 |
這是屬於實作的問題，Delphi/BCB在提供分散式架構時可以使用JSON做為訊息封裝的格式嗎? |
當然可以，JSON雖然來自Java/JavaScript的世界，但也只是一種訊息封裝的格式而已，JSON簡單又快速，實作也不難。 |
所以現在很清楚了，Delphi/BCB的DataSnap採用TCP + JSON之後不但提供了更具彈性的分散式架構，而且由於JSON的簡潔，因此在傳遞速度上將會非常的理想，
使用JSON另外一個好處是JSON也定義了傳遞物件的格式，這非常的有趣，因為DataSnap中的DataSet，Delta等都是物件，那麼不是都可以使用JSON來傳遞嗎? 再者遠端物件的方法也可以當成物件來看待，那麼再進一步也許再藉由Delphi/BCB原有的RTTI那麼是不是可以做到像Java的RMI(Remote Method Invocation)呢，我想當時Steve心中一定是這樣想的。如果能夠這樣做到的話，那麼代表Delphi/BCB的用戶端就可以像Java一樣在用戶端呼叫遠端的伺服器服務，再藉由DataSnap原本豐富的DataSet/Delta等處理資料的功能，那麼這將比Java的RMI強太多了。
這樣的思路的確發人省思，因為如此一來不但發展出了DataSnap新的分散式架構，允許Delphi/BCB用戶端不必使用COM/COM+就可以呼叫遠端服務，而且使用JSON之後Delphi/BCB可以立刻整合於Java，Ajax和.NET。
不過要這樣做仍然需要克服2個最大的技術問題，那就是:
1 原本的DataSnap分散式架構使用COM/COM+，用戶端的TClientDataSet等元件是藉由IAppServer介面和遠端的Remote資料模組溝通，因此如果新的DataSnap使用TCP + JSON，那麼舊的DataSnap應用程式怎麼辦?
2. Delphi/BCB原本的RTTI提供的資訊不夠豐富，而Delphi/BCB又沒有像Java/.NET那樣的Reflection API，因此用戶端無法擷取足夠的遠端方法的MetaData進而組合正確方法原型以呼叫遠端的服務方法。
第一個問題不難解決，舊的DataSnap仍然會存在於Tiburon之中(也就是說仍然可以使用COM/COM+)，問題只是在如何通透的讓舊的DataSnap架構能夠使用JSON，其實這個關鍵只是IAppServer介面，因此我們只需要使用Adapter設計樣例就可以簡單的解決，那就是讓DataSnap用戶端連結到新的元件，這個元件同樣實作了IAppServer介面，這可以讓DataSnap用戶端以為仍然是連結到以前的Remote資料模組，但事實上已經是連結到使用TCP + JSON新架構的元件了(就是稍後我們會討論的TDSServer和TDSServerClass元件)。
第二個問題則需要新的編譯器技術，在原本的RTTI中產生足夠的Metadata可以讓DataSnap用戶端呼叫遠端方法，這就是Tiburon新的編譯器指令{$MethodInfo ON}和{$MethodInfo OFF}的目的。
OK，瞭解這些基本的思路和想法之後，下次就讓我們看看如何在Tiburon中使用TCP + JSON建立一個新的分散式應用程式，同時我們也會觸及到JSON是出現在這個新的分散式架構的那個地方，Have Fun!
Tiburon遊記1
看來在CodeGear併入了Embarcardero之後，整個公司的文化似乎瞬間活潑了起來，雖然CodeGear尚未正式宣佈Tiburon的發行日期，但是在CodeGear的部落格中卻出現了大量討論Tiburon的文章，這在以前Borland的時代是不可能發生的，我還記得前幾年我還在Borland工作時，有幾次在部落格中不小心提及了尚未推出的Delphi/C++Builder時就會被老外叮的滿頭包，更別說是像現在CodeGear公開的在部落格中討論尚未推出的Tiburon的各種新功能了，CodeGear似乎已經慢慢的走出Borland時代保守到不行的風格了。
這次的Tiburon應該算是CodeGear對於Delphi Win32以及C++Builder Win32從Delphi 7/C++Builder 5以來最大幅度的進步，Tiburon在每一個領域都有都重大的功能和進步，其中許多新的功能都已經在CodeGear的部落格中有被提及，我在下面的表格中做了大概的整理:
|
領域 |
新功能 |
|
Delphi編譯器 |
Delphi Win32和Delphi.NET同時支援泛型程式設計能力， Anonymous方法， |
|
Delphi核心 |
完整的Unicode支援能力，全新且相容的RTL，泛型 Container |
|
VCL |
全新的Ribbon控制項，更多的全新VCL元件並且擴充原有VCL元件的功能 |
|
資料庫 |
Unicode驅動程式，新的DataSnap技術，支援JSON的分散式架構 |
|
COM/COM+ |
RIDL，所有原先的COM/COM+功能皆已加入Tiburon並且支援最新的COM+標準 |
除了上述的功能之外，Tiburon還提供了新的專案管理員，功能更多的除錯器，新的Class Explorer新的DUnit和DBUnit讓Delphi開發人員能夠更有效率的使用TDD。
這次Tiburon對於C/C++的支援也將和Delphi同步推出，再也不落後給Delphi，而且Tiburon新增的C/C++功能絕不遜色於Tiburon For Delphi，事實上這次Tiburon For C/C++進度的幅步似乎比Delphi還好，看來新的C/C++Builder的產品經理雄心是非常的大，下面的表格大致列出了Tiburon For C/C++主要的功能:
|
領域 |
新功能 |
|
C/C++編譯器 |
開始支援Cpp0x，更好的最佳化能力 |
|
C++Builder核心 |
完整的Unicode支援能力，全新且相容的RTL以及和Delphi類別更好的相容性 |
|
VCL |
全新的Ribbon控制項，更多的全新VCL元件並且擴充原有VCL元件的功能 |
|
資料庫 |
Unicode驅動程式，新的DataSnap技術，支援JSON的分散式架構 |
|
COM/COM+ |
RIDL，所有原先的COM/COM+功能皆已加入Tiburon並且支援最新的COM+標準 |
|
建模 |
雙向的Together for C/C++，讓C++Builder正式成為最好的UML建模工具 |
|
全新的Pre-compiler header精靈 |
可大幅加快Tiburon編譯C/C++程式碼的速度，可比C++Builder 2007最高提昇3倍的速度 |
|
C/C++編輯器 |
支援Cpp0x的語法 |
|
主流C/C++函式庫 |
Dinkumware STL，Boost 1.35，Ace, Tao, Loki |
當然，Tiburon For C/C++也有新的專案管理員，新的除錯器等，就像Delphi一樣。
例如下圖是Tiburon For C/C++有關建立COM/COM+的精靈，熟悉Delphi 7/C++Builder 5的朋友應該可以看到所有的COM/DCOM/COM+精靈都回到Tiburon中了，而且Tiburon支援最新的COM/COM+標準。
而下圖則是Tiburon For C/C++全新的Pre-compiler header精靈，它能夠分析開發人員的C/C++專案中的原始程式並且建立新的Pre-compiled header，讓中/大型的C/C++Builder專案的編譯速度大幅加快。
Tiburon這個版本不但實用而且提供了最先進的Win32開發能力，如果您目前還需要進行Win32的開發，那麼您的確應該好好考慮Tiburon，雖然目前Tiburon還在Beta，但是它非常的穩定，在最近的幾個Beta版中我並沒有沒有碰到任何的問題。
Tiburon提供了許多的新功能，但是我對其中的JSON分散式架構非常的有興趣，因為Steve自從RAD Studio 2007以來就是最有創意和開發能力的領導人之一，在下次的文章中讓我們看看什麼是JSON分散式架構，它和原有的DataSnap架構又有什麼關係。
Have Fun!
CodeGear推出3rdRail 1.2
看看3rdRail 1.2除了修正臭蟲之外，也增加了一些新的功能，例如除了在3rdRail 1.1中加入支援RESTful的Rails Resource精靈之外，3rdRail 1.2又增加了Rails View精靈，如下所示:
此外3rdRail 1.2為Ruby和Rails程式碼提供了更完善的"Quick Fix"功能，可以幫助開發人員自動檢查Ruby和Rails程式碼並且提供快速自動修復的能力。而原本出現在3rdRail 1.1中的新功能Open Associate在1.2中也再次的強化了，3rdRail 1.2不但可幫助開發人員追蹤MVC元素相關的實體，更可以追蹤相關的測試和執行分派實體，讓開發人員可以更快的以MVC實體為核心，根據其他相關的實體或是執行流程路徑來追蹤。例如下圖顯示了3rdRail 1.2擴充了原本3rdRail 1.1中的Open Associate，再加入了Open Test Associate以及Open Dispatch Associate的功能，
下圖更顯示了3rdRail 1.1可以快速過濾開發人員鎖定的Associate:
除了上述的功能之外，3rdRail 1.2還有其他的強化，如果您是一位RoR的開發人員，千萬不要錯過目前最先進的RoR開發工具，CodeGear在網站上提供了3rdRail 1.2的試用版，有興趣的朋友可以在下面的URL找到。
http://cc.codegear.com/free/3rdrail
Have Fun!
多年前的預言!
『當神殿易主之際，便是Diablo重新降臨之時』。
工作這麼多年來，有幾個軟體始終是自己的最愛，也認為這些軟體在PC界中是歷久不衰的經典，例如Borland C++ 3.0/3.1，Diablo和Delphi 1。我也始終記得第1次使用Borland C++ 3.0/3.1的愛不釋手，第1次使用Delphi的震撼不已，以及無日無夜打著Diablo和Diablo II的日子，即使到了現在我也不時的再次玩著Diablo II過過癮，因為Diablo III在經過了這麼多年的等待仍然無聲無息，也不時感嘆為什麼這個經典遊戲就後繼無人了，正如經典的Delphi始終命運多舛一樣。
但這一切的不確定似乎即將煙消雲散，因為預言似乎即將實現，
『當神殿易主之際，便是Diablo重新降臨之時』
就在Delphi的新主易位不到1天之後，Diablo III也終於出現在世人的眼前，真是太棒了，光是用想的似乎我就立刻年輕了10幾歲，我又可以回到多年前白天用Delphi晚上打Diablo的日子了，還有什麼比這個更幸福的呢? 趕快存錢等著買Diablo III吧。
http://www.codegear.com/
http://www.blizzard.com/diablo3/
Borland終於售出CodeGear
今日Borland正式宣佈把CodeGear售出給資料庫管理工具領導廠商Embarcadero，Borland 終於結束在開發工具市場競逐霸主的時代，也但願CodeGear脫離Borland之後能夠發展的更好，一個輝煌的時代終於結束了。
http://www.borland.com/us/company/news/codegear_sale_announce.html
5Q和5冬的分別
盼著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界不見得是缺點，只要能夠轉化為儘早找出更好的解決方法就好啦。
從CodeGear的3rdRail獲得今年第18屆Jolt Awards大獎說起
在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雖然產品愈做愈好，但行銷似乎仍然像以前一樣，令人咳咳咳…
還記得”Algorithm+Data=Program”嗎?
對於我這個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是以如下的結構來實作:
|
參考數值 |
長度 |
資料(以位元組計算) |
|
-8 |
-4 |
0 |
那麼只要未來的Delphi/C++Builder先定義UniCode結構:
|
代碼頁 |
參考數值 |
長度 |
資料(以位元組計算) |
|
-12 |
-8 |
-4 |
0 |
再定義:
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”也是歷久彌新啊!
寒冷的上海&有趣的Together/MDA教育訓練
上個星期剛從上海完成了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的角度來看，特定平台，特定語言和特定架框並不是那麼的重要的。
所以這雖然我的臉頰凍傷了，但心中卻充滿了技術的火熱喜悅。
CodeGear正快速建立動態程式語言開發工具產品線
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第二版本的功能。
不過我的困擾是面對這麼多不同的開發工具和技術，那夠時間學習和使用啊，我可不想得上資訊焦慮症或是憂慮症，看來還是打打魔獸比較快樂一點。
12/11，12/13台北，新竹3rdRail產品技術發表會
CodeGear發佈3rdRail之後只要我有時間每天都會玩一玩，因為RoR真的很好玩，3rdRail又是目前最好用的RoR開發工具，事實上每次玩3rdRail就會讓我想換NB，因為我每次都玩的很開心因此總是想讓機器跑的更快，以便在有限的時間內能夠多玩一點。
由於RoR是開源程式碼，因此CodeGear雖然已經發佈3rdRail了有一段時間但卻沒有採用和其他開發工具慣例宣傳方式，也就是說CodeGear並沒有進行3rdRail的產品發表會，而是在國外採用參加Rails Conference以及參加當地RoR使用者俱樂部的方式來宣傳3rdRail，因此3rdRail連在亞太區也沒有進行任何的產品發表會。不過我在愈加瞭解RoR和3rdRail之後覺得這樣太可惜了，因為在台灣目前瞭解和使用RoR的朋友似乎仍然不夠多，但是RoR真是一個好東西，好玩生產力又高，而3rdRail也真是一個很棒的產品，不介紹給台灣的朋友實在太可惜了。因此在幾經努力之下，我建議CodeGear考慮在台灣先做1，2場活動看看反映如何(我現在已經不代表CodeGear，因此只是透過關係建議)，好不容易CodeGear總算答應在台北和新竹進行2場RoR和3rdRail的產品技術發表會，讓台灣成為亞太區中唯一有機會正式發表RoR/3rdRail，希望這次的研討會能夠吸引RoR的愛好者以及使用各種開發工具的朋友一起來看看RoR的技術以及3rdRail令人著迷的地方，回味一下開發的樂趣，享受一個美好的午後時光吧。
RAD Studio 2007 11月更新版
RAD Studio 2007推出代表CodeGear在開發工具方面進入了新的發展模式，這怎麼說呢? 例如從RAD Studio 2007開始CodeGear在線上輔助方面採取了不定時更新的方法，讓線上輔助能夠儘快的能夠滿足開發人員對於以往線上輔助的不滿。另外在開發工具本身的更新方面RAD Studio也沒有停頓下來，在Update 3之後CodeGear即將在11月底左右推出11月的更新版，這個版本除了修正臭蟲之外，也在效率和使用資源方面進行了非常多的改善，例如現在我就使用了11月更新版的Beta在做開發以及日常例行的工作，在連續工作了10多個小時之後，11月更新版不但仍然非常穩定，記憶體的使用量也比以前少而且非常的穩定，沒有持續大量增加的跡象，RAD Studio 2007 11月更新版已經讓我感覺是非常安全強固的工作環境了，也期待11月正式版早日推出，而我唯一的麻煩就是11月正式版出來之後，我又要重新安裝RAD Studio 2007了，因為我使用的Beta版實在太多，而11月更新版是需要安裝在正式版或是正式Update版之上，像我使用的in-line beta版是無法安裝的，又快到了頭痛的時間了。
2007年11月Delphi 2007研討會相關檔案
上星期在台灣舉行了四場有關BDE/DBX的研討會，對於需要這次研討會相關檔案的朋友可以在下面的URL下載，謝謝。
http://liwei.csdn.net/down/dbx_bde.rar
動動腦，讓您的C++Builder編譯速度快上好幾倍
前一陣子有一些C++Builder的朋友向我抱怨他們的C++Builder專案編譯的時間很久，特別是當專案很大時，編譯的時間需要非常久。這些C++Builder問我CodeGear為什麼不把C++Builder的編譯速度做的快一點，為什麼C++Builder編譯的速度這麼慢呢?
其實每當有人向我提起這個問題時我就想起10多年前我還在使用Borland C/C++ 3.0/3.1的時期，那時我們R&D最高檔的機器是一台Compaq 486-66，64M的PC，我們當時正開發的一個C++產品大約有50多萬行左右，加上使用的C/C++函式庫(RogueWave)，OCX以及Borland C/C++本身的OWL，每次編譯總行數大約是100萬行左右，而每次編譯都需要4個多小時左右，不過其實那時我最喜歡這4個多小時的空檔，因為在沒有版本控制的那個年代，我正好趁這4個多小時看C/C++ Journal和C/C++ Report這2本雜誌，現在回想那時的日子真是即簡單又充實的年代啊。
有許多朋友抱怨大型C++Builder專案編譯緩慢的問題很久了，本來我想自從C++Builder有了Pre-Compiled Header功能之後應該不會太慢了，因此一直沒有很注意(當然，另外的原因就是我現在沒有做大型C/C++專案開發的工作了)，直到前一陣子一位使用C++Builder的好朋友也向我抱怨兼求助的時候，我才開始認真思考和查詢這個問題(抱歉，因為平日的工作很忙，沒有太多的時間做研究)。其實C++Builder的執行效率的問題有許多都是環環相扣的，例如Pre-Compiled Header功能可以大幅增加C++Builder專案的編譯效率，也對C++Builder的Code Insight有很大的影響，對C++Builder 2006之後的重構功能也有很大的影響，對於使用TDD開發C/C++也有巨大的影響，因此正確使用Pre-Compiled Header功能是很重要的。那麼為什麼許多C++Builder的開發人員都會抱怨專案編譯緩慢並且C++Builder產生的Pre-Compiled Header也會很多，很大呢? OK，如果您發現您的C++Builder專案產生很多的Pre-Compiled Header檔案而且檔案很大的話，那麼就可能是您沒有正確使用Pre-Compiled Header的徵兆。在說明如何正確使用Pre-Compiled Header功能之前，讓我們動下腦筋想想怎麼樣才能夠讓C++Builder的專案能夠編譯得很快呢?
傳統上要讓C++Builder專案的編譯速度增加，第一個就是想辦法減少C++Builder專案的I/O存取次數(啊，我不討論增加硬體設備的效果，您大可使用Intel的4核CPU再加上4G的RAM，那樣也許就可以很快，不過我不知道，因為我現在沒錢用這麼高檔的機器)，由於C++同時使用了表頭檔(.H, .HPP)以及C++主體檔(.CC，.CPP)，因此理論上來說C/C++編譯器需要多一次的I/O存取，當表頭檔或是C++主體檔本身很大時，I/O存取的負擔就大了。另外由於一個C++主體檔需要#include許多其他表頭檔，因此如果C++專案本身沒有規劃好的話，那麼編譯一個大型的C++Builder專案就需要許多無謂的I/O存取，這當然就開始減緩專案編譯的速度了，因此Pre-Compiled Header功能就是希望能夠有效的減少無謂的I/O存取，進一步快儲編譯資訊，如此一來就可以增加Code Insight/重構和TDD的開發速度。
這聽起來很棒，但是為什麼有些朋友的C++Builder專案卻無法受惠於Pre-Compiled Header功能? 我搜尋了C++Builder了有關Pre-Compiled Header的說明:
Precompiled header files can be shared between the source files of your project only if the #include directives before #pragma hdrstop are identical. Therefore, you get the best compiler performance if you include common header files of your project before the #pragma hdrstop, and specific ones after it. Make sure the #include directives before the #pragma hdrstop are identical in all the source files, or that there are only very few variations.
在其中我們可以看到關鍵的一點，但卻是C++Builder開發人員都忽略的，那就是C++Builder文件中說明的很清楚，使用Pre-Compiled Header功能時所有在#pragma hdrstop之前宣告的#include檔案的順序都需要是完全一樣的，否則您就會產生巨大又無用的Pre-Compiled Header，甚至是許多的Pre-Compiled Header檔案，如此一來不但無法受惠於Pre-Compiled Header功能，反而讓您的C++Builder專案編譯的更緩慢。
例如許多的C++開發人員在撰寫不同的CPP主體檔時會在A.CPP中撰寫如下的程式碼:
#include <vcl.h>
#include "First.h"
#include "second.h"
#include "third.h"
…
#include "last.h"
#pragma hdrstop
接著可能在H.CPP中又不經心撰寫了下面的程式碼:
#include <vcl.h>
#pragma hdrstop
#include "First.h"
#include "third.h"
#include "second.h"
…
#include "last.h"
#pragma hdrstop
請注意，由於這位開發人員在不同的CPP主體檔於#pragma hdrstop前使用了不同次序的表頭檔，因此破壞了Pre-Compiled Header中的資訊，讓Pre-Compiled Header中的資訊體積變大而且大幅的降低了專案的編譯速度。
另外一個CPP的話經常會犯的錯誤就是在表頭檔中使用了不一致的資料結構或是函式雛型，這些程式碼如果也是宣告在表頭檔中並且在#pragma hdrstop前，那麼也會破壞Pre-Compiled Header中的資訊。例如下面的看似一樣的程式碼卻對Pre-Compiled Header有很大的影響:
void Foo(int iCount = 0);
void Foo1(void);
void Foo(int iCount);
void Foo1();
因此C++Builder的朋友應該查查專案中定義在#pragma hdrstop前的#include檔案，一個比較好的方案是把C++Builder專案中需要快儲在Pre-Compiled Header中的資訊統一定義在一個全域的專案表頭檔中，例如MyProjectHeaders.pch，然後只在每一個CPP主體檔中只需要在#pragma hdrstop之前#include MyProjectHeaders.pch即可:
#include <vcl.h>
#include “MyProjectHeaders.pch”
#pragma hdrstop
#include "First.h"
#include "second.h"
如此一來就可以大幅減少前面敘述的狀況，那麼對於大型的C++Builder專案的編譯時間就有顯著的改善了，一般來說應該可以增加5到10倍的編譯速度，使用C++Builder的朋友不妨試試看。
CSDN, Dr-Dobbs 2007軟體開發2.0大會 : RoR高效開發技術講座
我還是沒有得到休假，面對每天回不完的信，回答不完的問題，做不完的事，我突然很厭倦目前的生活，這麼秋高氣爽的日子應該是一年中放鬆的日子，多多接觸大自然，讓每天緊盯電腦到快脫窗的雙眼也能得到喘息的空間才對，相反的現在每天似乎都被困在一個無形的IT房間中，似乎總是無法走出去。這讓我想起『無敵天神(Bruce Almighty)』中的橋段，即使金凱利擁有了如上帝的神通也回不完所有的Email，可見現代Email的威力，一笑。
10月底從上海回台灣之後就開始準備2個重要的技術研討會，分別是11月下旬的Delphi 2007技術研討會以及讓我壓力更重的11月底CSDN, Dr-Dobbs 2007軟體開發2.0大會。在這次的Delphi 2007技術研討會中將討論許多朋友關心的BDE昇級的問題，由於BDE已經不再發展而且就Delphi/C++Builder來說，DBX4才是現在和未來資料存取的主要技術，而且面對明年Delphi Unicode版本的推出，DBX4也將在明年全面支援Unicode，BDE的架構不但無法面對當今應用程式的需求，也無法充分支援Unicode，因此對於許多仍然在使用BDE的朋友來說昇級到DBX4似乎是迫在眉睫的工作了，因此在這次的Delphi 2007技術研討會中就將說明BDE昇級到DBX4的一些相關技術的內容。
至於11月底CSDN, Dr. Dobbs 2007軟體開發2.0大會，我將討論如何進行RoR(Ruby On Rails)的高效率開發。其實會有這個研討會主要是因為好幾個月前我和蔣濤先生在MSN上的一次對話，那時我已經在研究RoR有段時間了，蔣先生在MSN上和我談話時知道了這點之後就問我願不願意就RoR開發做一個技術講座? 我當時也沒有想太多就隨口回說沒有問題啊，後來才知道這一回覆的結果就是在這麼重要的技術研討會上要進行一個『RoR高效開發』主題的技術講座。這讓我立刻感覺到了龐大的無形壓力，因為CSDN, Dr-Dobbs 2007軟體開發2.0大會參加者眾多，軟體開發高手雲集，每個技術講座的主講人也都是大中華區知名的技術高手，這次CSDN/Dr. Dobbs也邀請了許多國外的技術專家共聚一堂，甚至連iTHome都告訴我台灣也有許多技術高手要組團到北京參加這個盛會。本來我想，反正這次已經逃不掉了，那麼兵來將擋，做個45分鐘的技術講座也還應該撐的過去，反正我做技術講座也都習慣的像喝水一樣(不過現在愈來愈老，連喝水都會被嗆到啊)，沒有想到CSDN最後告訴我，我的研討會場次是90分鐘。什麼? 我幾乎快從椅子上跌了下來，90分鐘? 這那ㄎㄚ好? 後來我和好友Tom提起了這件事，我問他90分鐘這麼長要說些什麼才過的去啊，呵呵沒想到Tom簡單的回了我一句:『 大哥，你只要把說話的速度放慢成和一般人一樣，那你準備的內容可以講2個鐘頭都不只』。哇勒，Tom還真瞭解我一上台說話的速度就慢不下來，不過我還沒有可以講2個鐘頭的內容啊。
為了這個『RoR高效開發』技術講座我可真是過的不安穩，開始積極的備戰了起來，因為做為主講人我必須準備充實的90分鐘的內容，問題是要怎麼準備呢? 我開始思考了起來，開始思考我的講座的內容主軸，不過思考(佈局)是很花時間的，因此在思考之餘我開始閱讀大量的RoR書籍，我和CodeGear的3rdRail R&D小組接觸，希望知道他們如何學習，使用RoR以及對於RoR的看法，我也使用Google搜尋網上使用RoR的朋友對於RoR的看法和心得。出呼我意料之外的是，原本我是想為我的講座進行準備的工作，沒有想到這個準備的過程是如此的有趣，許多我觀察到的事情又觸發了我更多的想法以及對於RoR的認知。例如我在網上看到許多人喜歡RoR的生產力，也看到許多人批評RoR，這些批評通常集中在:
- Ruby語言不夠嚴謹(不像Java?)
- 質疑Rails能夠支撐大型應用嗎?
- 質疑RoR太靈活(這也是問題?)
- 質疑RoR只有MVC(真的需要那些多的設計樣例嗎?)
- 認為RoR的語法非常醜陋
- 質疑RoR的執行效率
- 為什麼企業不會接受RoR?
等等。
每當我看到不喜歡RoR或是批評RoR的文章時我都喜歡繼續追蹤下去，因為我想知道除了作者撰寫的文字之外，我更想知道筆者的背景，那通常會是主要的原因，因為多數人在學習，評估新的技術時都會以自己目前的狀況和背景來判斷。如果各位細心的話，或是像我這樣神經質的喜歡追蹤(因為除錯的單步追蹤成了習慣了嗎?)，那麼我們幾乎可以輕易的找出為什麼有些人喜歡RoR，有些人卻不能接受，簡單的說就是因為『學習的韻律』或是『使用的韻律』因素。
在說明什麼是『學習的韻律』或是『使用的韻律』之前，讓我們試著回答下面的問題:
- RoR能夠做到的事情是其他程式語言/架框無法做到的嗎?
- 只有RoR能夠進行快速Web/Web 2.0的開發嗎?
- 只有Ruby是動態程式語言，只有Rails是Web專屬架框嗎?
- 只有RoR使用MVC嗎?
我相信上面的答案都是否定的，OK，那麼到底什麼是RoR別具吸引力的地方? 只有RoR能夠提供高生產力的Web開發嗎? 答案似乎也不儘然是。
因此仔細觀察網上許多喜歡RoR的朋友是因為他們找到了適合他們的『韻律』，RoR靈活而高效的開發能力讓他們找到了他們現在使用的技術無法滿足他們需求的地方。相反的，許多不喜歡RoR的朋友(很多是Java的朋友)，可能不是因為他們無法找到RoR的『韻律』，而是他們已經在Java身上找到了目前最適合他們的『韻律』，讓他們怡然自得，那他們當然不再需要使用RoR，淺嘗即可，真正的開發還是回到Java，這讓他們比較安心。
這沒有什麼對與錯，但是學習一個新的技術，程式語言或是架框，開發人員需要的是先靜下來，聽聽和找找這個新的技術，程式語言或是架框的獨特的『韻律』，一旦您找到了適合的節拍，您就會發現覺它的迷人之處，深深為它著迷。
這個發覺讓我的講座有了第一個重要的線索 : RoR的『韻律』。什麼是RoR高效開發? 首先我們得找到正確的『韻律』和『節拍』，我們得問RoR的高效開發到底是什麼意思? 提到高效開發一般人立刻有的概念可能是:
- 高度的應用程式執行效率
- 高開發生產力，10倍數的生產力
- 高效率的團隊開發能力
- 高度的reuse
- 等等
等一下，這些概念是對Assembly，C，C++，C#，Java，Delphi，PHP還是RoR的高效開發定義? 還是適合所有程式語言的高效開發定義? 因為上述的一些概念對於不同的程式語言可能是彼此衝突的。那麼再問一次，RoR的高效開發到底是什麼意思?
其實回答這個問題一點都不難，如果您接受RoR的話，那麼請您回想是RoR的那一點讓您感動或是激動，興奮，而讓您決定使用RoR進行開發的地方? 從那裡開始搜尋您的RoR的『韻律』，您自然就會開始接近RoR的高效開發了。
因此 : 『回到原點』是我學習新技術，程式語言或是架框的另外一個方法。
現在我們有了『回到原點』，再從原點出發開始搜尋『RoR韻律』，一段時間之後，當您愈來愈瞭解RoR，您可能就會發現RoR的高效開發之道了。
因此我決定這次的RoR高效開發技術講座就將以這個主軸為討論重點，希望藉由這次的技術講座來幫助有興趣的朋友尋找RoR的高效開發之道，尋找適合您自己的『RoR開發韻律』，因為RoR高效開發之道不是只有一條路，不是只有TDD+MVC+Editor，而是瞭解RoR帶來的構思以及我們如何觀察RoR應用程式的發展趨勢。
歡迎所有有興趣的朋友一起來參加，更歡迎您來分享您獨特的『RoR韻律』。對於一個像我這樣在C++/Delphi/Java/C#打滾這麼多年的老骨頭來說，也歡迎這些背景的朋友來看看RoR的發展，他山之石可以攻錯，RoR一定有非常有趣的地方，否則RoR不會這麼快速的影響許多其他的程式語言，也讓許多的架框學習RoR的架構了。
浙公网安备 33010602011771号