2008 年 04 月 的封存

5Q和5冬的分別

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

廣告

7 則迴響

『無耐心是缺點,不適合做開發人員』,ㄨㄚ ㄌㄟ,是嗎?

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

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

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

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

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

http://blufiles.storage.live.com/y1pzGurgrznJM3mGTM0NuLpaofRan3X7BPHjS01yFzIbynJeoe44QX2xxb7mlO0jw0fQfngheIR3UU由Flex 3製作的GUI

http://blufiles.storage.live.com/y1pzGurgrznJM1wyR-v6L3Jl09ysSXuQxLB3F7YUQIT54T8BdV9Oain4Phb5dwl4W-oecGBD_FkeJs

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


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

 http://blufiles.storage.live.com/y1pzGurgrznJM2MspnkWTrV2u4Zj-M37-vlvcmk2UdpgGpW3_vhhwEqSHXSi-Sn0drif-AmULwOvzs

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

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

60 則迴響

從CodeGear的3rdRail獲得今年第18屆Jolt Awards大獎說起

200836Dr. Dobb’s正式宣佈CodeGear3rdRail取得了今年在RoR IDE方面的Jolt Awards大獎,證明了去年我還是CodeGear員工時就一直看好3rdRail這個產品的眼光。話說自從前年開始迷上RoR之後我就一直在找尋好用的RoR整合發展環境,因為那時Borland/CodeGear本身並沒有RoRIDE,在使用了包括了RadRailsNetBeansRoRIDE之後,雖然覺得比起使用命令列+UltraEdit的生產力高,但總覺得和CodeGearIDE有些差距與不習慣。不過自從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區勉強同意讓台灣做23rdRail產品發表,那就是分別在台北和新竹僅有的23rdRail的活動。當時台北/新竹2場的3rdRail活動吸引了將近130人參加,更重要的是其中有許多參加人員從來不是CodeGear的客戶,這讓我非常的滿意,原本當時計劃在2008年第1季繼續往中南部發表3rdRail並且從台北開始舉辦3rdRail+RoR的技術研討會,可惜事情變化的太快,這些計劃使終沒有實現,讓我扼腕不已,這麼一個好的產品就這麼。如今3rdRail 1.0不但獲得了Jolt Awards大獎,CodeGear也宣佈了正式推出3rdRail 1.1版,不但加入了專屬的RoR除錯器而且執行速度是DLTKRuby除錯器的4倍,3rdRail 1.1也支援Rails 2.0Rails的重構等強大的功能,這讓3rdRail 1.1成為當今開發Rails 2.0應用程式最好的IDE

另外一個CodeGear的好產品就是即將推出的Delphi For PHP 2.0Delphi 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.0IDE工作速度有著顯著的提升,這個讓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 ProfilerPHP開發人員可以進行效率調整,提供Sync EditCode Formatter的編輯器,也支援Zend框架並且封裝了數個Zend VCL元件讓PHP開發人員可以直接使用拖曳的方式使用Zend架框中的功能,wow,其中直接支援Zend框架讓Delphi For PHP+Zend架框幾乎擁有和3rdRail+RoR一樣強大,方便的MVC開發能力,這是讓我從3rdRail+RoR回來鑑賞Delphi For PHP 2.0PHP技術最重要的原因。

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

7 則迴響

還記得”Algorithm+Data=Program”嗎?

對於我這個5年級學習資訊科學的人來說,Nicklaus Wirth是不能忘記的偉大軟體科學家,Nicklaus Wirth”Algorithm+Data=Program”這本資料結構的書籍是我大二時在台大圖書館中最常苦讀的書籍(呵呵,當然是因為要應付考試啦)Nicklaus Wirth發明的Pascal程式語言深深的影響了資訊界長達數10年之久,然而隨著最近10年物件導向程式語言成為資訊界程式語言的主流後,要不是Borland/CodeGearDelphi與時併進並且為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的意義,也分不清楚Lengthsizeof的意義,在許多的情形下也分不清楚陣列中位元組和元素的分別。當然,會造成這些問題的原因是因為大多數的開發人員是從原生程式語言開始寫程式碼,在我們學習BBC的第一步腦中就充滿了位元,位元組,字元的觀念,而從C/C++背景來的開發人員更習於使用指標運算來加速資料存取的速度並且節省程式碼的撰寫。如果你會問腦中有這些觀念或是使用指標存取有什麼問題呢?那麼我們至少可以列出下面的數個問題:

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

  •   Windows OS16位元,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/StringWideString的結果也不同。

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

Algorithm+Data=Program

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

DelphiC++Builder來說,隨著VCL框架可同時執行於Win16Win32Win64,再隨著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;

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

http://tkfiles.storage.live.com/y1pzGurgrznJM1D5MAG5tzbV1aqIkgUwqNdP-XSSVXjwIHm6iEOwdz_4gZrKRYWUvMAKnX2CBNPKSQ

而是正確的:

http://tkfiles.storage.live.com/y1pzGurgrznJM2umVusiRSdu6vJS6CBBWNa5oedJ7MxOCqzkQP9OSKRflFhZuPETWTXP2kXTc1s2_E

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

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

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

32 則迴響