推文( 3 )
鐵人賽的小筆電，在 12/8（二）就已經收到了，只是這幾天較忙，所以一直到今天才把開箱文PO上來，感謝主辦單位與HP提供這麼豐盛的獎品，真是佛心來著，甘心啊！
關於 hp mini 5101 的詳細規格與評比，請參考 cnet 的評測文章，這邊就不贅述了。
(閱讀全文)
「我的歌唱完了。我的心也閒了。」
這是鹿橋在未央歌的尾聲所提到的。正是鐵人賽走完的心情寫照。（但接近年底了工作量持續增加中）
程式設計在任何時間點都是一個起點，而沒有終點的一條路。
寫程式，是用電腦來解決某些特定的問題，而程式設計的理論與方法，則是為了解決寫程式的「人」的問題。就像管理一樣，我們必須要訂定管理的準則與規範，讓業務的運作得以流暢，達成預期的目標。管理的理論則是幫助我們制定規範，並避免掉可能發生的問題，與帶來實質的效益。（當然多少有些理想化）理論建構的再完整，但執行的還是「人」，實施的對象，也是「人」。人的特質，就是我們不得不考慮與正視的因素了。
當然，這是管理的議題。而管理所需花費的最小成本，就是「自我管理」，也是最有效的管理，我們管理好自己的工作態度，管理好時間的分配，管理好自己負責的範圍，在既定原則與方向指引下，朝一致性的目標前進。 (閱讀全文)
這是鹿橋在未央歌的尾聲所提到的。正是鐵人賽走完的心情寫照。（但接近年底了工作量持續增加中）
程式設計在任何時間點都是一個起點，而沒有終點的一條路。
寫程式，是用電腦來解決某些特定的問題，而程式設計的理論與方法，則是為了解決寫程式的「人」的問題。就像管理一樣，我們必須要訂定管理的準則與規範，讓業務的運作得以流暢，達成預期的目標。管理的理論則是幫助我們制定規範，並避免掉可能發生的問題，與帶來實質的效益。（當然多少有些理想化）理論建構的再完整，但執行的還是「人」，實施的對象，也是「人」。人的特質，就是我們不得不考慮與正視的因素了。
當然，這是管理的議題。而管理所需花費的最小成本，就是「自我管理」，也是最有效的管理，我們管理好自己的工作態度，管理好時間的分配，管理好自己負責的範圍，在既定原則與方向指引下，朝一致性的目標前進。 (閱讀全文)
我們又回到書本上了，今天雖是鐵人賽最後一天，但並不是本系列的終結篇。
（還有一篇，因為人家還想玩大富翁...XD）
程式設計師該有什麼特質？或者說，當程式設計師的人有什麼特質？
特質因人而異，每個人的習慣與成長背景不同，所處環境不同，都會表現出不一樣的特質。
所以我們來談談，程式設計師該有的特質...「宅」（誤）
04 十一月, 2009 08:13
另外一個我比較常的例子是，用 Class 來寫 Table 的對應程式。
（不過應該有這種 Tool 可以幫您將 DB 的 Table 自動產生 Class 程式碼的）
不過因為物件的溝通是靠訊息及 Event 的傳遞，如果欄位太多，則對於物件屬性的存取反而會影響到 Performance（用 Debug Trace 一下就知道是怎麼回事了）。
那就讓我們就進入程式吧！ (閱讀全文)
（不過應該有這種 Tool 可以幫您將 DB 的 Table 自動產生 Class 程式碼的）
不過因為物件的溝通是靠訊息及 Event 的傳遞，如果欄位太多，則對於物件屬性的存取反而會影響到 Performance（用 Debug Trace 一下就知道是怎麼回事了）。
那就讓我們就進入程式吧！ (閱讀全文)
03 十一月, 2009 08:53
在程式的設計過程中，我們常常會需要用到日期的運算，有時候為了做日期的判斷，可能會需要知道每個月的最後一天是什麼時候。
這有很困難嗎？除了二月比較特殊，其他月份不都很固定？
是的，二月確實是很特殊的，因為有閏年。而閏年的算法，您還記得嗎？
以下，我們先來示範一種寫法。（當然像 Java 內建萬年曆 Calendar 這個 Class，已經有提供這個機制） (閱讀全文)
這有很困難嗎？除了二月比較特殊，其他月份不都很固定？
是的，二月確實是很特殊的，因為有閏年。而閏年的算法，您還記得嗎？
以下，我們先來示範一種寫法。（當然像 Java 內建萬年曆 Calendar 這個 Class，已經有提供這個機制） (閱讀全文)
02 十一月, 2009 08:37
在前篇，我們將 Parent Form 實作出來了。接下來，我們要藉由 TimerBaseFormLibrary
來產生應用程式。
這裡沒有很高深的理論架構, 只是運用物件導向中很基本的「繼承」、「多型」等技巧。.Net Framework 內建的 Application log 機制則具備有多樣的選擇, 你可以很容易的將程式執行的過程所產生的訊息紀錄到 log 檔 Application Event 或 XML 檔案等（在 app.config 中設定）
逐步解說：判斷 My.Application.Log 寫入資訊的位置
HOW TO：在 Visual Basic 中記錄例外狀況
但是 Exception Notification 的部份只能透過自己撰寫的方式來達成需 Import System.Net.Mail.SmtpClient & System.Net.Mail.MailMessage 這部份或許微軟應該把他考慮進來, 也透過 Config 的方式來達成。
好了，我們繼續繼承的開發實作吧！ (閱讀全文)
來產生應用程式。
這裡沒有很高深的理論架構, 只是運用物件導向中很基本的「繼承」、「多型」等技巧。.Net Framework 內建的 Application log 機制則具備有多樣的選擇, 你可以很容易的將程式執行的過程所產生的訊息紀錄到 log 檔 Application Event 或 XML 檔案等（在 app.config 中設定）
逐步解說：判斷 My.Application.Log 寫入資訊的位置
HOW TO：在 Visual Basic 中記錄例外狀況
但是 Exception Notification 的部份只能透過自己撰寫的方式來達成需 Import System.Net.Mail.SmtpClient & System.Net.Mail.MailMessage 這部份或許微軟應該把他考慮進來, 也透過 Config 的方式來達成。
好了，我們繼續繼承的開發實作吧！ (閱讀全文)
01 十一月, 2009 10:54
終於，我們要真正開始寫程式了。
這一篇分上下兩集，要介紹的是如何實作 Form 的繼承物件，這是在 2006 年
發表在自己的 Blog 上面的，原文請參考：
http://jamesjantw.blogspot.com/2006/09/net-windows-form.html
茲節錄部分文字，以作為說明
緣起:
之前在 VB6 的時代，常常會撰寫一些排程的程式去執行一些 Backend 的作業（當然你也可以用 OS 的 Schedule 來排程）。每次需要新的作業時都是將程式目錄 Copy 一遍再逐一去改命名，雖然自己已經有一些開發的 Pattern（ini 檔、log 檔、Error 發送 email 通知開發者），開發速度上也很快，但是如果我要讓所有的程式都增加一個新的功能，這樣我得為每一個專案加入這個功能，為數眾多時這可是頗耗時間的。
以前開發 Delphi (3.0) 時，就已經有 Form 繼承的作法了，程式模組可以重複使用，那為什麼同性質的 Form 不可以呢？基於這樣的需求，所以決定第一支程式以 Windows Form 繼承實作做為開端。
思考:
1.哪些功能該擺在 BaseForm 上？Inheritance consideration
2.如何擴充已有的功能？Overrides
3.如何讓同一功能具備多樣性？Overloads
4.應用程式設定檔
5.應用程式記錄檔
6.Exception Notification（通知錯誤訊息 & 出錯行號）
今天我們來練習犁田（誤）。
今天我們拿狐大的例子，來練習犁田（又誤，咳...），練習如何以物件導向的方式來分析與建構出犁田分析系統...XD
算是給接下的繼承實作，暖暖場。
OK，不囉嗦，就給他雷下去。 (閱讀全文)
今天我們拿狐大的例子，來練習犁田（又誤，咳...），練習如何以物件導向的方式來分析與建構出犁田分析系統...XD
算是給接下的繼承實作，暖暖場。
OK，不囉嗦，就給他雷下去。 (閱讀全文)
物件導向設計的方式，強調的是直覺易懂的方式，貼近實際的狀況。所以在命名的時候，多以貼近實際的名稱來做為物件的命名。
當然，如果要討論到 UML，則超出本系列與本人的層級了。更何況，沒有像 Rational Rose 或 ALM（Application Life-Cycle Management）之類的物件導向建構工具，UML 也只是流於紙上作業，或許對分析上有用處，但並沒有享受到整體開發上的好處。（僅個人觀點）
所以，本篇要介紹的，一樣是相當基本的建構步驟。 (閱讀全文)
當然，如果要討論到 UML，則超出本系列與本人的層級了。更何況，沒有像 Rational Rose 或 ALM（Application Life-Cycle Management）之類的物件導向建構工具，UML 也只是流於紙上作業，或許對分析上有用處，但並沒有享受到整體開發上的好處。（僅個人觀點）
所以，本篇要介紹的，一樣是相當基本的建構步驟。 (閱讀全文)
「物件導向」，一看到這個名詞，好像是要進入到神聖的殿堂一般，讓人由不得肅然起敬。
當然在以前 DOS 的年代早期，確實是如此。但是在進入到 Widnows 的時代、網際網路的時代，我們寫的程式，可一點也離不開物件導向啊！
諸如 Windows Form、HTML 的 Document Object Model，一個又一個的物件模型，充斥在我們的程式當中。少了物件的特性，說真的，很難想像程式開發會變成什麼樣子。 (閱讀全文)
當然在以前 DOS 的年代早期，確實是如此。但是在進入到 Widnows 的時代、網際網路的時代，我們寫的程式，可一點也離不開物件導向啊！
諸如 Windows Form、HTML 的 Document Object Model，一個又一個的物件模型，充斥在我們的程式當中。少了物件的特性，說真的，很難想像程式開發會變成什麼樣子。 (閱讀全文)
28 十月, 2009 08:04
Error Handling 或稱作 Exception Handling，都是在幫我們攔截系統 Runtime 錯誤發生時，所產生的錯誤訊息。（或者為特定目的而 Raise Error）
有了他的協助，我們可以在不影響程式運作的同時，將產生的錯誤做追蹤處理，這對除錯來說是相當有幫助的。更有幫助的是，程式不會而當掉無法執行（當然得看發生錯誤的嚴重程度以及是否能夠由程式 Handle） (閱讀全文)
有了他的協助，我們可以在不影響程式運作的同時，將產生的錯誤做追蹤處理，這對除錯來說是相當有幫助的。更有幫助的是，程式不會而當掉無法執行（當然得看發生錯誤的嚴重程度以及是否能夠由程式 Handle） (閱讀全文)
寫程式最討厭的一件事情是什麼？我想大家一定會舉雙手贊成--文件！
文件很多時候不是給程式設計師看的，所以就不能以程式設計師的語言去寫。
這就是傷腦筋的地方！
如果是 API 文件，那麼有很多工具可以使用，如 JavaDoc
量身訂做自己的 JavaDoc 上
量身訂做自己的 JavaDoc 下
配合註解的定義與規範，就可以產生一份極具參考價值的 API 文件。
Visual Source Safe 也可以透過註解中一些特殊的設定，也可以做成一份很有用的說明文件（Sorry 如何製作的文件已經找不到了，現在 .Net 環境則改以 Team Fundation Server 來取代 Visual Source Safe 了） (閱讀全文)
文件很多時候不是給程式設計師看的，所以就不能以程式設計師的語言去寫。
這就是傷腦筋的地方！
如果是 API 文件，那麼有很多工具可以使用，如 JavaDoc
量身訂做自己的 JavaDoc 上
量身訂做自己的 JavaDoc 下
配合註解的定義與規範，就可以產生一份極具參考價值的 API 文件。
Visual Source Safe 也可以透過註解中一些特殊的設定，也可以做成一份很有用的說明文件（Sorry 如何製作的文件已經找不到了，現在 .Net 環境則改以 Team Fundation Server 來取代 Visual Source Safe 了） (閱讀全文)
「好的註解讓你讓天堂，差的註解讓你淚兩行」這是我們看程式時，最佳的心情寫照。
註解的重要性可見一般。只是，什麼時候要註解？註解的內容又要有哪些呢？
我們先來看一下書中舉的一個極端的例子：
如果您看到這種註解，是不是當場傻眼！這樣好像只要閱讀註解就可以知道這個常式在做什麼，很詳細也很清楚！但是這樣到底是寫程式為主還是寫註解為主？
因為我們在閱讀程式的過程中，其實就會了解這段程式所執行的方式，其實是不需要個別去說明的。（這反倒是比較像系統設計文件所撰寫的東西）每次有異動，就會一直累計資料，註解不斷的長大，反倒有點宣賓奪主的味道了。與其這樣，倒不如用 Blog 來記錄開發的過程，查詢也比較方便。
在前面已經介紹了很多程式撰寫時方便閱讀與維護的技巧，程式即是註解，其實就是最高的境界了。但是總是有不足之處，例如是什麼時候修改的？是為了什麼目的修改的？
所以，如果註解能夠扮演著畫龍點睛之妙，則是最佳的模式了。 (閱讀全文)
註解的重要性可見一般。只是，什麼時候要註解？註解的內容又要有哪些呢？
我們先來看一下書中舉的一個極端的例子：
- '*****************************************************************
- '* 常式名稱：CopyString
- '*
- '* 目的：這個常式從來源字串(Source$)複製字串到目的字串(Target$)
- '*
- '* 演算法：首先取得 Source$ 的長度，然後每次複製一個字元到 Target$。
- '* 它使用迴圈索引值當做存取陣列時的索引值來存取 Source$ 與
- '* Target$ 內的資料，並且在複製完一個字元後遞增索引值。
- '*
- '* 輸入資料：Inputs$ 要複製的字串
- '*
- '* 輸出資料：Outpur$ 準備接收複製資料的字串
- '*
- '* 預設條件：無
- '*
- '* 程式修改記錄：無
- '*
- '* 作者：黃小暐
- '* 撰寫日期：10/1/92
- '* 電話：(222) 555-2255
- '*
- '*****************************************************************
因為我們在閱讀程式的過程中，其實就會了解這段程式所執行的方式，其實是不需要個別去說明的。（這反倒是比較像系統設計文件所撰寫的東西）每次有異動，就會一直累計資料，註解不斷的長大，反倒有點宣賓奪主的味道了。與其這樣，倒不如用 Blog 來記錄開發的過程，查詢也比較方便。
在前面已經介紹了很多程式撰寫時方便閱讀與維護的技巧，程式即是註解，其實就是最高的境界了。但是總是有不足之處，例如是什麼時候修改的？是為了什麼目的修改的？
所以，如果註解能夠扮演著畫龍點睛之妙，則是最佳的模式了。 (閱讀全文)
程式人人會寫，各有巧妙不同。好的程式碼外觀，讓人賞心悅目；雜亂無章的程式碼，則讓人望文興嘆，不忍觸賭。
我記得當年在宿舍問一個很會寫程式的同學，寫程式有沒有什麼秘訣？
他說有一個說穿了不值錢，但是很有用的方法，就是先把 Block 建構好。
這是什麼意思？
就是說當我們程式需要用到 ( ，{ 的時候，先將 () 與 {} 建構好，再於其中撰寫程式，這樣就不用怕會遺漏掉，到時候還要檢查半天。從這位同學的身上我學習到，養成好的寫程式習慣，是一件很重要的事情！
所以我們今天就要來談談，程式撰寫的風格。 (閱讀全文)
我記得當年在宿舍問一個很會寫程式的同學，寫程式有沒有什麼秘訣？
他說有一個說穿了不值錢，但是很有用的方法，就是先把 Block 建構好。
這是什麼意思？
就是說當我們程式需要用到 ( ，{ 的時候，先將 () 與 {} 建構好，再於其中撰寫程式，這樣就不用怕會遺漏掉，到時候還要檢查半天。從這位同學的身上我學習到，養成好的寫程式習慣，是一件很重要的事情！
所以我們今天就要來談談，程式撰寫的風格。 (閱讀全文)
