推文( 2 )
今天上站來一看，上一篇PO文都是去年聖誕節的事了
真是一年容易又一年啊
為何今天想上站來呢？
是想分享一個程式給大家，是什麼程式呢？
不是別的，就是賓果遊戲券產生器
雖然尾牙的時間已過（今年還是得到不錯的獎品與獎金 $_$），不過春節聯歡也是OK的啦！
(閱讀全文)
24 十二月, 2009 11:28
13 十二月, 2009 12:00
個人參賽網址 http://www.vision2020.tw/index.php?pg=upaste&act=let_us_meet_detail&id=67
麻煩眾親好友、認識的不認識的、路過的、喝茶的.....啊，大家有空幫忙推一下溜！
(閱讀全文)鐵人賽的小筆電，在 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） (閱讀全文)
Plurk*噗浪
  | |||
