2007 年 11 月 的封存

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版是無法安裝的,又快到了頭痛的時間了。

32 則迴響

2007年11月Delphi 2007研討會相關檔案

上星期在台灣舉行了四場有關BDE/DBX的研討會,對於需要這次研討會相關檔案的朋友可以在下面的URL下載,謝謝。

 

http://liwei.csdn.net/down/dbx_bde.rar

http://liwei.csdn.net/down/BDEDBXSeminar.ppt

http://liwei.csdn.net/down/BDEDBXDemos.zip

3 則迴響

動動腦,讓您的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-6664MPC,我們當時正開發的一個C++產品大約有50多萬行左右,加上使用的C/C++函式庫(RogueWave)OCX以及Borland C/C++本身的OWL,每次編譯總行數大約是100萬行左右,而每次編譯都需要4個多小時左右,不過其實那時我最喜歡這4個多小時的空檔,因為在沒有版本控制的那個年代,我正好趁這4個多小時看C/C++ JournalC/C++ Report2本雜誌,現在回想那時的日子真是即簡單又充實的年代啊。

有許多朋友抱怨大型C++Builder專案編譯緩慢的問題很久了,本來我想自從C++Builder有了Pre-Compiled Header功能之後應該不會太慢了,因此一直沒有很注意(當然,另外的原因就是我現在沒有做大型C/C++專案開發的工作了),直到前一陣子一位使用C++Builder的好朋友也向我抱怨兼求助的時候,我才開始認真思考和查詢這個問題(抱歉,因為平日的工作很忙,沒有太多的時間做研究)。其實C++Builder的執行效率的問題有許多都是環環相扣的,例如Pre-Compiled
Header
功能可以大幅增加C++Builder專案的編譯效率,也對C++BuilderCode 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存取次數(啊,我不討論增加硬體設備的效果,您大可使用Intel4CPU再加上4GRAM,那樣也許就可以很快,不過我不知道,因為我現在沒錢用這麼高檔的機器),由於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專案的編譯時間就有顯著的改善了,一般來說應該可以增加510倍的編譯速度,使用C++Builder的朋友不妨試試看。

21 則迴響

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也將在明年全面支援UnicodeBDE的架構不但無法面對當今應用程式的需求,也無法充分支援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書籍,我和CodeGear3rdRail 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是動態程式語言,只有RailsWeb專屬架框嗎?


  • 只有RoR使用MVC?

我相信上面的答案都是否定的,OK,那麼到底什麼是RoR別具吸引力的地方? 只有RoR能夠提供高生產力的Web開發嗎? 答案似乎也不儘然是。

因此仔細觀察網上許多喜歡RoR的朋友是因為他們找到了適合他們的『韻律』,RoR靈活而高效的開發能力讓他們找到了他們現在使用的技術無法滿足他們需求的地方。相反的,許多不喜歡RoR的朋友(很多是Java的朋友),可能不是因為他們無法找到RoR的『韻律』,而是他們已經在Java身上找到了目前最適合他們的『韻律』,讓他們怡然自得,那他們當然不再需要使用RoR,淺嘗即可,真正的開發還是回到Java,這讓他們比較安心。

這沒有什麼對與錯,但是學習一個新的技術,程式語言或是架框,開發人員需要的是先靜下來,聽聽和找找這個新的技術,程式語言或是架框的獨特的『韻律』,一旦您找到了適合的節拍,您就會發現覺它的迷人之處,深深為它著迷。

這個發覺讓我的講座有了第一個重要的線索 : RoR的『韻律』。什麼是RoR高效開發? 首先我們得找到正確的『韻律』和『節拍』,我們得問RoR的高效開發到底是什麼意思? 提到高效開發一般人立刻有的概念可能是:

  • 高度的應用程式執行效率

  • 高開發生產力,10倍數的生產力


  • 高效率的團隊開發能力


  • 高度的reuse


  • 等等

等一下,這些概念是對AssemblyCC++C#JavaDelphiPHP還是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的架構了。

See You!

10 則迴響