近來看了二篇Delphi的技術文章，Delphi 在Script 不缺席 和 Delphi 寫DLL需注意的事項 這二篇文章，第一篇提供了一些Delphi的支援訊息，第二篇則提供了作者的實作經驗。有興趣的人可以參考一下。
筆者一般寫的都是BPL，DLL比較少做，不過以前曾經用DELPHI5寫過MRP的DLL展算程式，看到DLL不能用ADO Connection，心中覺得納悶，那我是如何解決?於是回頭去看了一下以前寫的程式，發現我是用BDE做的。這下尷尬了，BDE已經進入末期了，不知客戶還有沒有在用這個程式是不是要重新改寫。
也許對DLL也要再花點時間研究、測試了。
2015年5月29日 星期五
2015年5月27日 星期三
2015年5月26日 星期二
DELPHI程式人員在那裡
在參加XE8發表會時，現場有人提出要去那邊找DELPHI工程師。我在客戶那邊也常被問到可否介紹DELPHI工程師。因緣際會有機會到中部一家科技大學和一位教DELPHI的老師見面，談一些合作的可能性。也因此有機會瞭解一下DELPHI新鮮人的近況。
第一個消息是，第一名DELPHI優秀的三年級同學已經被訂走了。所以如果要找DELPHI不錯的新鮮人要一年前就預定了，看樣子要挖角的成本應該也不低。該名學生專攻目前最HOT的APP通訊推播，看他問老師的問題，在實作上應該有一定涉入程度才是。
我們需要的DELPHI新鮮人是要做新的程式應用，還是接手我們已開發維護的系統?會不會就算有DELPHI新人加入，他們也要在新領域發揮，而不是在我們的ERP資料庫打轉?在資訊業，應該不像公家機關或是傳統行業要靠經驗取勝。資訊的範圍太大了，不同的領域都可以養活一票人，新人不一定要承接我們的工作往上爬。
第二個消息是DELPHI程式設計師的養成率是10%。以一年一百個學生來算，可用的DELPHI學生只有10個，真正進入到DELPHI發展的應該不到10個，這個數字應該無法滿足市場的人才需求吧。所以需要DELPHI程式人員的主管們，如果你想讓自己的新人訓練輕鬆一點，有空到學校拉一下人吧，只靠104恐怕只能怨嘆難找人了。
優秀的人總是少數。如果沒有能力教優秀的人才，對他們不但是一種傷害，也留不住這些優秀的程式人員。在學校和老師們談這些學生，和學生談一下他們對程式世界的看法、他們手上目前程式工作的現況，有一個深刻的感覺。程式能力的高下決定你能吸引什麼樣的人。優秀的程式人員對解決程式問題的沈迷，就像鯊魚見血一樣。能用你在程式上的知識去解決他的問題，才能吸引他進入你的公司。
技術是一切的根本，大家努力吧。
第一個消息是，第一名DELPHI優秀的三年級同學已經被訂走了。所以如果要找DELPHI不錯的新鮮人要一年前就預定了，看樣子要挖角的成本應該也不低。該名學生專攻目前最HOT的APP通訊推播，看他問老師的問題，在實作上應該有一定涉入程度才是。
我們需要的DELPHI新鮮人是要做新的程式應用，還是接手我們已開發維護的系統?會不會就算有DELPHI新人加入，他們也要在新領域發揮，而不是在我們的ERP資料庫打轉?在資訊業，應該不像公家機關或是傳統行業要靠經驗取勝。資訊的範圍太大了，不同的領域都可以養活一票人，新人不一定要承接我們的工作往上爬。
第二個消息是DELPHI程式設計師的養成率是10%。以一年一百個學生來算，可用的DELPHI學生只有10個，真正進入到DELPHI發展的應該不到10個，這個數字應該無法滿足市場的人才需求吧。所以需要DELPHI程式人員的主管們，如果你想讓自己的新人訓練輕鬆一點，有空到學校拉一下人吧，只靠104恐怕只能怨嘆難找人了。
優秀的人總是少數。如果沒有能力教優秀的人才，對他們不但是一種傷害，也留不住這些優秀的程式人員。在學校和老師們談這些學生，和學生談一下他們對程式世界的看法、他們手上目前程式工作的現況，有一個深刻的感覺。程式能力的高下決定你能吸引什麼樣的人。優秀的程式人員對解決程式問題的沈迷，就像鯊魚見血一樣。能用你在程式上的知識去解決他的問題，才能吸引他進入你的公司。
技術是一切的根本，大家努力吧。
2015年5月25日 星期一
2015年5月15日 星期五
DELPHI上WEB辛苦談
當初要把Delphi上WEB是一個【選項】，不是個【必然】。可以選擇C# 或是 Java。幾經考慮之後，還是利用Delphi上WEB，但幾個問題橫在眼前：
1.
Delphi本身不能直接橋接IIS，只能使用ISAPI，但這技術似乎過時。
2.
Delphi是Native語言，無記憶體自動回收架構。
3.
Delphi是Native語言，要Compile之後才能分發。
左思右想之後，只有取巧利用C#當IIS與Delphi橋接口，將來自Browser需求利用C#轉呼叫由Delphi 做成的COM SERVER。C#負責Session 管理，Delphi提供服務。如此一來，就輕易解決上WEB的架構。
【無記憶體自動回收架構】這問題在傳統上是相當嚴重，因為Server 需長期運行，如果有記憶體遺漏，很快就會造成Server死當。後來，幾經折騰COM SERVER改成Single Instance之後，這問題就不嚴重了。因為，每個使用者都是獨立，反而系統更穩定。
【要Compile之後才能分發】這問題會帶來版本及分發安全的問題，不過，後來實作一個系統分發之後，這問題變成小問題。
2015年5月8日 星期五
Delphi COM 的再認識
在發展delphi 上WEB的過程，由於整個專案是利用DOT NET 呼叫Delphi 的COM Server。因此，很自然就研究起Delphi 的COM架構。不過，也遭遇了幾個困難：
1. COM+ 跟 COM的註冊是截然不同。
2. COM的 TYPE LIBRARY 如何繼承。
3. COM的 Instance 的選擇。
由於透過IIS呼叫，一定要是COM+的註冊方式，但Delphi 內建的 COM註冊程式只支援COM，不支援COM+，因此，專案的一開始，單單這問題就搞了快一個月。
由於希望每個專案能有自己的COM SERVER，最終是一台電腦可獨立運行多個專案，但問題是，每個專案都是由模板專案產生，但TYPE LIBRARY要不同。如此一來必須是繼承，才能達到目標，但第一次摸索delphi 的TYPE LIBRARY繼承要花了一點時間，不過，也因此感受到delphi在這方面支援不錯。
基於過往的使用經驗，很自然選擇ciMultiInstance(Delphi Create COM 中的一個選項)。 但問題來了，delphi 的MultiInstance 是要自己實作，這問題找了資料之後很快就突破了，真正問題在上線之後。
再經過一年左右奮戰終將專案完成，懷著戰戰兢兢的心情既期待又怕受傷害的心情，測式上線。剛開始無異狀，因上線人數不多，但人數一多COM SERVER會死當。這下心情跌到谷底。因為，這種Run time 的錯誤特別難抓。想想這問題不僅底層須解決，讓問題更複雜是：客戶買了這產品回去，還會自行加工。那如何避免Server如何死當，不僅底層程式碼必須注意，客戶也要有足夠的知識避免，那這教育訓練成本未免太高了，於是思索如何讓每個Server 都是獨立不會互相干擾，當成是研發的方向，而且就算Coding 不到位也無妨，果然一試之後，COM Server 再也不當，甚至比NET 研發更穩當。
PS: 不過，獨立的COM SERVER研發也帶來別的挑戰。不過，這不是本次文章的主題，故不在此深述。
1. COM+ 跟 COM的註冊是截然不同。
2. COM的 TYPE LIBRARY 如何繼承。
3. COM的 Instance 的選擇。
由於透過IIS呼叫，一定要是COM+的註冊方式，但Delphi 內建的 COM註冊程式只支援COM，不支援COM+，因此，專案的一開始，單單這問題就搞了快一個月。
由於希望每個專案能有自己的COM SERVER，最終是一台電腦可獨立運行多個專案，但問題是，每個專案都是由模板專案產生，但TYPE LIBRARY要不同。如此一來必須是繼承，才能達到目標，但第一次摸索delphi 的TYPE LIBRARY繼承要花了一點時間，不過，也因此感受到delphi在這方面支援不錯。
基於過往的使用經驗，很自然選擇ciMultiInstance(Delphi Create COM 中的一個選項)。 但問題來了，delphi 的MultiInstance 是要自己實作，這問題找了資料之後很快就突破了，真正問題在上線之後。
再經過一年左右奮戰終將專案完成，懷著戰戰兢兢的心情既期待又怕受傷害的心情，測式上線。剛開始無異狀，因上線人數不多，但人數一多COM SERVER會死當。這下心情跌到谷底。因為，這種Run time 的錯誤特別難抓。想想這問題不僅底層須解決，讓問題更複雜是：客戶買了這產品回去，還會自行加工。那如何避免Server如何死當，不僅底層程式碼必須注意，客戶也要有足夠的知識避免，那這教育訓練成本未免太高了，於是思索如何讓每個Server 都是獨立不會互相干擾，當成是研發的方向，而且就算Coding 不到位也無妨，果然一試之後，COM Server 再也不當，甚至比NET 研發更穩當。
PS: 不過，獨立的COM SERVER研發也帶來別的挑戰。不過，這不是本次文章的主題，故不在此深述。
2015年5月7日 星期四
2015年5月DELPHI XE8發表會感想
昨天去參加捷康XE8發表會，會中李維大師說明了許多XE8的新功能，特別是在IOT(Internet of Things)的部分。XE8為了讓開發者方便作業，除了貼心的加了新元件外。也為設計環境做了許多方便性的改善，讓程式人員可以快速方便的完成程式設計。
在整場會議中，李大師解說了一些DELPHI底層的工作，其實這才是一個開發系統的重點。這些在外面看不到，不起眼的地方，其實就是整個系統運作的關鍵。通常我們都是設一設元件屬性，在事件寫一些程式去做元件的變動和處理。但是這些元件是如何運作的，就比較少人去瞭解了。當元件達不到我們的目標時，我們就會覺得元件功能不足，但是往往是我們沒有瞭解元件，不瞭解這些元件的設計初衷。誤用或是不知如何去善用這些元件來達成我們的目標。
以前學程式設計時，總是學語法，學結構，才開始寫自己的程式。不過昨天上課後，對學程式這件事有了不同的看法。電腦世界的變化太快了，以前可以用幾個語法來解決的程式，現在是要用一大堆的元件才能完成目標。用元件來組合程式是很快，站在別人的程式上架構系統也很省力。但是如何去理解別人設計的元件，反而成為最重要的核心工作了，這些都是要花時間才能打下根基，讓自己的工作更順利。
另外還有一件事應該說一下，以前學程式，不會就問前輩，因為電腦就是處理計算問題，有BUG也好解決。現在元件不但多，而且深入的領域都不同，特別是IOT都有和硬體做溝通，很多程式都和藍芽有關。所以現在學程式，要先GOOGLE一下自己的問題，整理思考，並在DELPHI試過之後，才能提出比較好的問題。對要解題教導你的前輩而言，這也是一種尊重。
急著想解決問題是人的常態，但未經思考的問題，往往只是顯示自己不成熟。
在整場會議中，李大師解說了一些DELPHI底層的工作，其實這才是一個開發系統的重點。這些在外面看不到，不起眼的地方，其實就是整個系統運作的關鍵。通常我們都是設一設元件屬性，在事件寫一些程式去做元件的變動和處理。但是這些元件是如何運作的，就比較少人去瞭解了。當元件達不到我們的目標時，我們就會覺得元件功能不足，但是往往是我們沒有瞭解元件，不瞭解這些元件的設計初衷。誤用或是不知如何去善用這些元件來達成我們的目標。
以前學程式設計時，總是學語法，學結構，才開始寫自己的程式。不過昨天上課後，對學程式這件事有了不同的看法。電腦世界的變化太快了，以前可以用幾個語法來解決的程式，現在是要用一大堆的元件才能完成目標。用元件來組合程式是很快，站在別人的程式上架構系統也很省力。但是如何去理解別人設計的元件，反而成為最重要的核心工作了，這些都是要花時間才能打下根基，讓自己的工作更順利。
另外還有一件事應該說一下，以前學程式，不會就問前輩，因為電腦就是處理計算問題，有BUG也好解決。現在元件不但多，而且深入的領域都不同，特別是IOT都有和硬體做溝通，很多程式都和藍芽有關。所以現在學程式，要先GOOGLE一下自己的問題，整理思考，並在DELPHI試過之後，才能提出比較好的問題。對要解題教導你的前輩而言，這也是一種尊重。
急著想解決問題是人的常態，但未經思考的問題，往往只是顯示自己不成熟。
訂閱：
文章 (Atom)