真的是繼 Mobil01之後另一個要少去為妙的地方！
不過，今天看到 皇室御用 - 法國夢特嬌頂級新絲纖維 冬被 團購
心想，一直對家裡的棉被很不滿意，都是老爸老媽給的(硬塞來的 -.-)棉被，然後每一條都有些故事提醒著我們要飲水思源*&^#種種的...即使它們有的已經很硬了、有的根本是春夏被~~其實我只想要蓋得暖蓋得爽的棉被~ 就好了，尤其這款被可以水洗!!看來是可以敗下我人生的第一條(自己掏錢買的)棉被了。
2009年11月28日 星期六
敗了-皇室御用 - 法國夢特嬌頂級新絲纖維冬被
最近常逛486大的敗家網
真的是繼 Mobil01之後另一個要少去為妙的地方！
不過，今天看到 皇室御用 - 法國夢特嬌頂級新絲纖維 冬被 團購
心想，一直對家裡的棉被很不滿意，都是老爸老媽給的(硬塞來的 -.-)棉被，然後每一條都有些故事提醒著我們要飲水思源*&^#種種的...即使它們有的已經很硬了、有的根本是春夏被~~
其實我只想要蓋得暖蓋得爽的棉被~ 就好了，尤其這款被可以水洗!!看來是可以敗下我人生的第一條(自己掏錢買的)棉被了。
真的是繼 Mobil01之後另一個要少去為妙的地方！
不過，今天看到 皇室御用 - 法國夢特嬌頂級新絲纖維 冬被 團購
心想，一直對家裡的棉被很不滿意，都是老爸老媽給的(硬塞來的 -.-)棉被，然後每一條都有些故事提醒著我們要飲水思源*&^#種種的...即使它們有的已經很硬了、有的根本是春夏被~~其實我只想要蓋得暖蓋得爽的棉被~ 就好了，尤其這款被可以水洗!!看來是可以敗下我人生的第一條(自己掏錢買的)棉被了。
2009年11月10日 星期二
Visual Studio從2003到2005的演化
身為還在VS 2003抽不出身的本團隊，在面對VS 2008 的現在，有必要了解齊演進過程，下文詳細載明其演進。
參考來源： 關心: Visual Studio從2003到2005的演化（全文） (在「Google 網頁註解」中檢視)更換 OFFICE 2007 的序號
Office的非正版提示苦惱了我好一陣子，尤其在客戶端 present 時真是太刺眼了！
找到這篇文章，一試果然有用。
(以下全文轉載自 Blog of A Yellow Tiger)
今天灌MSDN的Visio，灌好了就直接啟動。結果，啟動次數被用光了！大家還真是會用啊，好不容易弄到另一組MSDN的產品金鑰，卻不知道要怎麼換產品金鑰。難道，要重灌Visio才能再打一次產品金鑰？
別再相信沒有事實根據的說法了！求助於Google吧，用中文找，找到的都是教破解或是免序號。改用英文找，以"visio 2007 change key"為關鍵字，果然一下就找到了，趕快記下來，下次再遇到同樣的情形就可以參考了：
1. 在Registry裡找到下面的subkey
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\Registration
2. 因為Visio和Office 2007的其他東西分屬於不同的subkey，所以，Registration這個subkey下面會有不只一個長得像{901.......0FF...}的subkey。一一點進去看ProductName，就可以確認Visio是在哪一個subkey之下。
3. 在Visio所在的subkey中，把ProductID和DigitalProductID兩個subkey給刪了。
4. 執行Visio，就會出現輸入產品金鑰的對話框了。輸入新的序號後，就可以進入Visio的畫面並接著成功啟動了。
PS1:用正版還要受罪，真是不太爽啊！
PS2:這方法適用於其他Office 2007的產品。
找到這篇文章，一試果然有用。
(以下全文轉載自 Blog of A Yellow Tiger)
今天灌MSDN的Visio，灌好了就直接啟動。結果，啟動次數被用光了！大家還真是會用啊，好不容易弄到另一組MSDN的產品金鑰，卻不知道要怎麼換產品金鑰。難道，要重灌Visio才能再打一次產品金鑰？
別再相信沒有事實根據的說法了！求助於Google吧，用中文找，找到的都是教破解或是免序號。改用英文找，以"visio 2007 change key"為關鍵字，果然一下就找到了，趕快記下來，下次再遇到同樣的情形就可以參考了：
1. 在Registry裡找到下面的subkey
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\Registration
2. 因為Visio和Office 2007的其他東西分屬於不同的subkey，所以，Registration這個subkey下面會有不只一個長得像{901.......0FF...}的subkey。一一點進去看ProductName，就可以確認Visio是在哪一個subkey之下。
3. 在Visio所在的subkey中，把ProductID和DigitalProductID兩個subkey給刪了。
4. 執行Visio，就會出現輸入產品金鑰的對話框了。輸入新的序號後，就可以進入Visio的畫面並接著成功啟動了。
PS1:用正版還要受罪，真是不太爽啊！
PS2:這方法適用於其他Office 2007的產品。
2009年11月9日 星期一
M$的VSTS(Visual Studio Team System)
以下內容轉載自 Kai's World 微軟的VSTS(Visual Studio Team System)能有多少發揮呢?
最近公司要打算導入VSTS把IT的某個開發Team拿來當白老鼠，基於一些理由我也就需要研究一下VSTS在玩什麼把戲
看完一些他的教學文件跟產品介紹文件，我其實是非常同意他的遠見，他是想做一個系統開發平台，建立一個Team Foundation Server然後不管是開發人員、架構師、測試人員、DBA、Project Manager通通在同一個平台做事，然後他再提供各個專業人員所需要得工具，讓大家協同合作，還有內建的一些軟工的流程可以套用，落實開發流程，進一步自動產生一些有用的報告或是"Real"的報告讓Project Manager真正掌握開發進度。
我想以上是他想要完成的目標，再細部的往下研究一下
VSTS他並非使用UML的語言而是DSL(Domain Specific Language)，他提出的理由是UML太過抽象，是否可以應用在不同的Domain，我們是不是應該因應不同的Domain有不同的語言，所以DSL還有提供讓你定義你自己的DSL，他也提出了一些學術上的論點，找來當初制定UML的人來幫他背書。
我沒用過DSL也沒有裝來畫畫看，所以我無法評論，但是我想很多人會有跟我一樣的想法"搞什麼又要來一個規格之爭嗎"好不容易花時間學會了UML，結果你要我用你自己定義的DSL，我又要花時間學DSL，然後只For你的VSTS，這樣實在是!@#$%^&*(這也是我沒裝來畫畫看的原因)，不知道是不是我有所誤會，說不定是共存，讓想用UML的用UML，想用DSL的用DSL這樣比較make sense如果是強迫中獎這樣我想很多人都很難接受。
接下來分享的部份是我認為比較有價值的部份"軟體工程"
我相信在軟工的世界沒有什麼Best Practice，所以目前才有這麼多派系之分，不同公司、不同文化、不同案子都可能產生公司自己的Best Practice，這次微軟提供了微軟自己的MSF(Microsoft Solutions Framework)你可以用微軟開發軟體的方法論來開發自己的軟體，微軟也號稱這套方法論在微軟內部已經從1994年使用自今(不知道大家覺得微軟的品質如何)這MSF涵蓋了CMMI Level3也讓你對未來Level4、Level5做準備。
如果只是這樣我想大家會問他跟RUP沒什麼兩樣阿
重點來了我覺得最吸引人的有兩點
1.他也讓Agile同時存在，在Anile部分他提供了MSF for Agile Software Development微軟從Motorola找來Agile社群中的David Anderson來操刀，讓兩種方法論都可以在VSTS上使用，但是這還不是最新引人的，最吸引人的是你可以客製化你的流程，他只是提供你最極端的兩個範本，你可以依據自己組織的需要調整你自己的開發流程，微軟也宣稱會繼續update各大學派的方法論範本給大家下載免費使用(當然VSTS是要錢的)。
2.文件管理部份由於VSTS是系統協同合作的，很多報告可以由系統自動產生，讓不愛寫文件的工程師工作量減輕不少(我也不愛寫但是有時又是非寫不可)，再者我之前提到的"Real"，很多人都有經驗明明，你手上的程式只完成30%，但是project schedule是50%，你在report中要寫多少 ? maybe 40%，也或許你認為後面的開發速度會突飛猛進cover現在的delay而填上50%，導致Project manager拿到錯誤的資料，而做出錯誤的評估，你也浪費時間寫出一份讓人有錯誤評估的report。
遇到這狀況，我還寧願不要有這份report，讓工程師專心寫程式。Project Manager透過Project manager的工具連上server，看看目前完成度或是直接選取所需要的資訊。
至於DBA，版本控管，還有測試方面市面上已經有很多工具，大致大同小異就不多做介紹，接下來就是讓市場跟時間來證明他了。
---------------------------------------------------------------------------
鳥毅的Blog:安裝Team Foundation Server SP1 測試環境
VSTS 實驗室: TFS 2008 單一伺服器簡易安裝說明 (在「Google 網頁註解」中檢視)
Visual Studio Team Foundation Server 安裝筆記
最近公司要打算導入VSTS把IT的某個開發Team拿來當白老鼠，基於一些理由我也就需要研究一下VSTS在玩什麼把戲
看完一些他的教學文件跟產品介紹文件，我其實是非常同意他的遠見，他是想做一個系統開發平台，建立一個Team Foundation Server然後不管是開發人員、架構師、測試人員、DBA、Project Manager通通在同一個平台做事，然後他再提供各個專業人員所需要得工具，讓大家協同合作，還有內建的一些軟工的流程可以套用，落實開發流程，進一步自動產生一些有用的報告或是"Real"的報告讓Project Manager真正掌握開發進度。
我想以上是他想要完成的目標，再細部的往下研究一下
VSTS他並非使用UML的語言而是DSL(Domain Specific Language)，他提出的理由是UML太過抽象，是否可以應用在不同的Domain，我們是不是應該因應不同的Domain有不同的語言，所以DSL還有提供讓你定義你自己的DSL，他也提出了一些學術上的論點，找來當初制定UML的人來幫他背書。
我沒用過DSL也沒有裝來畫畫看，所以我無法評論，但是我想很多人會有跟我一樣的想法"搞什麼又要來一個規格之爭嗎"好不容易花時間學會了UML，結果你要我用你自己定義的DSL，我又要花時間學DSL，然後只For你的VSTS，這樣實在是!@#$%^&*(這也是我沒裝來畫畫看的原因)，不知道是不是我有所誤會，說不定是共存，讓想用UML的用UML，想用DSL的用DSL這樣比較make sense如果是強迫中獎這樣我想很多人都很難接受。
接下來分享的部份是我認為比較有價值的部份"軟體工程"
我相信在軟工的世界沒有什麼Best Practice，所以目前才有這麼多派系之分，不同公司、不同文化、不同案子都可能產生公司自己的Best Practice，這次微軟提供了微軟自己的MSF(Microsoft Solutions Framework)你可以用微軟開發軟體的方法論來開發自己的軟體，微軟也號稱這套方法論在微軟內部已經從1994年使用自今(不知道大家覺得微軟的品質如何)這MSF涵蓋了CMMI Level3也讓你對未來Level4、Level5做準備。
如果只是這樣我想大家會問他跟RUP沒什麼兩樣阿
重點來了我覺得最吸引人的有兩點
1.他也讓Agile同時存在，在Anile部分他提供了MSF for Agile Software Development微軟從Motorola找來Agile社群中的David Anderson來操刀，讓兩種方法論都可以在VSTS上使用，但是這還不是最新引人的，最吸引人的是你可以客製化你的流程，他只是提供你最極端的兩個範本，你可以依據自己組織的需要調整你自己的開發流程，微軟也宣稱會繼續update各大學派的方法論範本給大家下載免費使用(當然VSTS是要錢的)。
2.文件管理部份由於VSTS是系統協同合作的，很多報告可以由系統自動產生，讓不愛寫文件的工程師工作量減輕不少(我也不愛寫但是有時又是非寫不可)，再者我之前提到的"Real"，很多人都有經驗明明，你手上的程式只完成30%，但是project schedule是50%，你在report中要寫多少 ? maybe 40%，也或許你認為後面的開發速度會突飛猛進cover現在的delay而填上50%，導致Project manager拿到錯誤的資料，而做出錯誤的評估，你也浪費時間寫出一份讓人有錯誤評估的report。
遇到這狀況，我還寧願不要有這份report，讓工程師專心寫程式。Project Manager透過Project manager的工具連上server，看看目前完成度或是直接選取所需要的資訊。
至於DBA，版本控管，還有測試方面市面上已經有很多工具，大致大同小異就不多做介紹，接下來就是讓市場跟時間來證明他了。
---------------------------------------------------------------------------
TFS 出了名的難裝~ 原本還想使用已經於VM既有的SQL 2008 DB，但似乎狀況更多，到頭來重作一份VM從頭來過，DB改用SQL 2005就順了~
安裝記實：
1.SQL Server Agent需啟動且為自動。
2.SQL Server Browser需啟動且為自動。
(到最後，整個SQL開頭的service都設自動且啟動！除了SQL Server Active Directory Helper外)
3.使用 SQL Server 介面區組態工具啟用遠端 TCP/IP 連接。
4.SQL 2005需上到 SP2。
終於，最後一個問題僅剩硬體需求，CPU需2.2G，就不理它繼續下一步，接下來的過程如同下述說明，建立TFSSERVICE帳戶啟動服務用 and keep Next 直到完成。
5.依個人喜好，可以依照"安裝指南"，安裝"Team Foundation Build"。
6.再安裝"Team Explorer"。
7.安裝Windows SharePoint Services Extensions。
8.安裝TFS SP1。
這樣就全部裝好，接下來就打開 Visual Studio，使用Team總管連結上Server。
(2009/11/24)
裝是裝好了，但要開第一個專案就出問題了!!~ 一直出現錯誤
Error
無法連接到位於 192.168.XX.XX 的指定 SQL Server Reporting Services。
Explanation
[專案建立精靈] 無法連接到位於 192.168.XX.XX 的 SQL Server Reporting Services。此時尚無法判斷連接失敗的原因。由於連接失敗，精靈無法完成建立 SQL Server Reporting Services 網站。
(2009/11/25)
改參考 Huan-Lin 學習筆記 on DotBlogs 中的 Visual Studio Team Foundation Server 安裝筆記重裝整個TFS，這次選用SQL 2005 Ent版，並於SQL裝完上SP3後安裝WSS3.0 with SP2。
怎麼這次是被診斷沒安裝Analysis Service～ 天阿，心裡真是很X。
(2009/11/26)
幾經波折，被Firewall卡了一陣子，最後索性依照 install guid把所有port開啟(NOD32請切到互動過濾模式，不然都不知道它會不會亂濾！)，原先仍一直被診斷沒安裝Analysis Service~ 試著merge TFS install image與sp1後重試還是一樣的訊息，期間改了多次service啟用帳戶，最後是都以TFSSERVICE啟動，後來似乎因為WSS沒啟用所致 -.- ，
終於~~只剩CPU或RAM不符要求，終於可以下一步了...
話說，要繼續TFS安裝時，在WSS一步又被卡了，訊息如下：
Error codes: TF220035 (The URL at the specified location is not a Windows SharePoint Services site) or TF220041 (The specified Windows SharePoint Services site URL is not the default site collection site)
這問題請見TFS 2008 on Windows Server 2008 Installation Problem (TF220035 or TF220041)又過了一關~~ 下一王是
Error 28805 Setup cannot finish the request to the SQL Server 2005 Reporting Service report server. Verify that the report server is installed and running, and that you have sufficient privledges to access it看來是Reporting Service的加密金鑰檔住~直接刪除！！又過了一關~~
挖塞~~已成功安裝~~~~~~(我哭了...)
看來，要開始安裝TFS前，需確認以下四個URL都要有：
http://btf-tfs/
http://localhost/reports/
http://btf-tfs:30736
鳥毅的Blog:安裝Team Foundation Server SP1 測試環境
VSTS 實驗室: TFS 2008 單一伺服器簡易安裝說明 (在「Google 網頁註解」中檢視)
Visual Studio Team Foundation Server 安裝筆記
2009年11月6日 星期五
Introduce UML Class Diagram
(以下原文轉載自 smalltide 's Blog Introduce UML Class Diagram )
對UML的類別圖稍微做些簡介,不討論程式語言相關的部份
純為概念性的簡介
類別圖主要功能是表示物件之間的靜態關係
類別圖由三個部份組成
1.類別名稱 2.成員變數 3.成員函式
成員函式前有符號代表存取權限
類別之間的關係有以下幾種
1.Association(關聯)(knows a)
X知道Y的存在
X可能以pointer(指標)或reference(參考)知道Y的存在
在概念模型階段方向性(箭頭)通常不太有意義可以省略
2.Dependency(相依)(use a)
X相依Y
Y若改變 X可能會受到影響 但X的改變不會影響到Y
X可能有某個functiond可以call Y的function
3.Composition(組合)(has a)
X組合Y
Composition是一種整體完全擁有部分
如車子(X)擁有4個輪子(Y)
當(車子)X消滅時(4個輪子)Y同時也會消滅
4.Aggregation(聚合)
X聚合Y
Aggregation是一種"擁有性"比較弱的關係
如車子(X)裡面有4個人(Y)
當車子(X)消滅時4個人(Y)不會消滅(當然車禍除外!!)
5.Inheritance(繼承)(UML以繼承表示泛型關係)
X繼承Y Z繼承Y 此時Y和(X,Z)之間就存在著泛型關係 Y是共同化(抽象化)X,Z則是特性化(具體化)
如 人(Y) 美國人(X) 台灣人(Z) 日本人(W)
XZW繼承Y 則 Y和XZW就存在泛型關係
對UML的類別圖稍微做些簡介,不討論程式語言相關的部份
純為概念性的簡介
類別圖主要功能是表示物件之間的靜態關係
類別圖由三個部份組成
1.類別名稱 2.成員變數 3.成員函式
成員函式前有符號代表存取權限
類別之間的關係有以下幾種
1.Association(關聯)(knows a)
X知道Y的存在
X可能以pointer(指標)或reference(參考)知道Y的存在
在概念模型階段方向性(箭頭)通常不太有意義可以省略
2.Dependency(相依)(use a)
X相依Y
Y若改變 X可能會受到影響 但X的改變不會影響到Y
X可能有某個functiond可以call Y的function
3.Composition(組合)(has a)
X組合Y
Composition是一種整體完全擁有部分
如車子(X)擁有4個輪子(Y)
當(車子)X消滅時(4個輪子)Y同時也會消滅
4.Aggregation(聚合)
X聚合Y
Aggregation是一種"擁有性"比較弱的關係
如車子(X)裡面有4個人(Y)
當車子(X)消滅時4個人(Y)不會消滅(當然車禍除外!!)
5.Inheritance(繼承)(UML以繼承表示泛型關係)
X繼承Y Z繼承Y 此時Y和(X,Z)之間就存在著泛型關係 Y是共同化(抽象化)X,Z則是特性化(具體化)
如 人(Y) 美國人(X) 台灣人(Z) 日本人(W)
XZW繼承Y 則 Y和XZW就存在泛型關係
2009年11月4日 星期三
flickr大量貼圖的好用工具---Friendly.flickr
挖~真是太讚了~ 身處這個網路的世代，要寫篇文章、回覆些論壇帖子，沒圖幾乎是沒人看；雖然已經付費上 Flickr Pr，但如果只是個放圖的地方，那真是不值得花錢！
發現這個工具，可以將Flickr上的圖轉貼上Blog或其它論壇，詳見
Friendly.flickr原作-搖擺天秤的程式開發日誌
另外有其它人的推薦~~
輕鬆插入 flickr 的相片到部落格 - Friendly.Flickr
《推薦》flickr大量貼圖的好用工具---Friendly.flickr & quickr pickr
二話不說，直接試試啦。
測試貼圖並於 Friendly.flickr 上排版後結果 (以下為轉貼於 Flickr 上的相片)
發現這個工具，可以將Flickr上的圖轉貼上Blog或其它論壇，詳見
Friendly.flickr原作-搖擺天秤的程式開發日誌
另外有其它人的推薦~~
輕鬆插入 flickr 的相片到部落格 - Friendly.Flickr
《推薦》flickr大量貼圖的好用工具---Friendly.flickr & quickr pickr
二話不說，直接試試啦。
測試貼圖並於 Friendly.flickr 上排版後結果 (以下為轉貼於 Flickr 上的相片)
2009年10月30日 星期五
隨身機之王道：MINOLTA TC-1
極米的 隨心所欲－隨身機之王道：MINOLTA TC-1 全世界介紹TC1寫得最好的文章。
MINOLTA投注了該公司最頂尖的開發技術與科技精華完成這台全世界最小的輕便相機，到底有什麼特殊之處?
爬原文吧~~
MINOLTA投注了該公司最頂尖的開發技術與科技精華完成這台全世界最小的輕便相機，到底有什麼特殊之處?
爬原文吧~~
2009年10月23日 星期五
轉貼 - DPP關於銳利度的一點心得分享
(原帖)
一般來講，對人像而言~~機身預設銳利度4就很夠了...
銳利再高鋸齒狀會越來越明顯..結果就是會出現網路上不少銳過頭很不自然的照片
然後將暗處-1 or 重口味-2 ,整張照片會看起來又清楚又但膚色依然保持粉嫩..
不建議加對比..因為對比會將亮處拉更亮,亮處容易爆掉..臉不容易生硬
風景的話DPP銳利頂多用到6,這時鋸齒狀已經快看得出來了
一樣用暗處調整,通常我喜歡-1就很夠 重口味-2
對比的話視情況....通常還是比較偏向以暗處調整和亮處調整分開調
一般來講，對人像而言~~機身預設銳利度4就很夠了...
銳利再高鋸齒狀會越來越明顯..結果就是會出現網路上不少銳過頭很不自然的照片
然後將暗處-1 or 重口味-2 ,整張照片會看起來又清楚又但膚色依然保持粉嫩..
不建議加對比..因為對比會將亮處拉更亮,亮處容易爆掉..臉不容易生硬
風景的話DPP銳利頂多用到6,這時鋸齒狀已經快看得出來了
一樣用暗處調整,通常我喜歡-1就很夠 重口味-2
對比的話視情況....通常還是比較偏向以暗處調整和亮處調整分開調
2009年10月17日 星期六
CANON全時手動對焦鏡頭
基本上有這個功能的鏡頭還滿多的，
依官網的解說，看到有下面這一個 Full Time Manual 的圖示
，就是有此功能，所有使用環形超音波馬達的 EF 鏡頭都有全時手動功能，不限 L 鏡。而既然全時手動功能是超音波馬達（USM）所帶來的功能，那 EF-S 鏡頭也是依有沒有搭載超音波馬達來看有沒有全時手動功能的。
依官網的解說，看到有下面這一個 Full Time Manual 的圖示
，就是有此功能，所有使用環形超音波馬達的 EF 鏡頭都有全時手動功能，不限 L 鏡。而既然全時手動功能是超音波馬達（USM）所帶來的功能，那 EF-S 鏡頭也是依有沒有搭載超音波馬達來看有沒有全時手動功能的。
2009年10月12日 星期一
2009年10月11日 星期日
2009年9月22日 星期二
品一杯好咖~重回手沖咖啡的世界
好長一段時間沒好好沖杯咖啡了~(自從好咖們都不在身邊了...)
不過多虧了艾倫的精心烘培好豆，有印尼曼特寧、巴西山多士、肯亞AA、巴拿馬卡門莊園和衣索比亞耶加雪菲，這下不好好品嚐就真的太對不起自己囉!
誰知遍尋不到我的濾滴器，只好上網購找找了~~ 突然看到這組金光閃閃的機絲
這款濾滴器不需要再買濾紙，非常好清洗，金屬的網子是24K鍍金，跟完美好咖真是絕配~
網子是特殊設計，咖啡液體流動很順暢不會過濾掉咖啡香醇口感的物質只要飲水機有熱水就可以馬上沖一杯，不會塞住，頂多用牙刷稍為刷即可，基本上只要好好用，是用不太壞。
代理商的網站，可以看到更詳盡的內容。有swissgold瑞士製造公司elfo ag的介紹、swissgold產品特色、使用方法，甚至將swissgold與其他的沖煮咖啡器具做比較，網站內容還滿多的，有興趣的人可以慢慢看。
我上網購自 Y拍：北極海咖啡
沒想到它還是在板橋江翠站附近，看來是註定要買的了。
感謝艾倫兄了~
不過多虧了艾倫的精心烘培好豆，有印尼曼特寧、巴西山多士、肯亞AA、巴拿馬卡門莊園和衣索比亞耶加雪菲，這下不好好品嚐就真的太對不起自己囉!
誰知遍尋不到我的濾滴器，只好上網購找找了~~ 突然看到這組金光閃閃的機絲
這款濾滴器不需要再買濾紙，非常好清洗，金屬的網子是24K鍍金，跟完美好咖真是絕配~
網子是特殊設計，咖啡液體流動很順暢不會過濾掉咖啡香醇口感的物質只要飲水機有熱水就可以馬上沖一杯，不會塞住，頂多用牙刷稍為刷即可，基本上只要好好用，是用不太壞。
代理商的網站，可以看到更詳盡的內容。有swissgold瑞士製造公司elfo ag的介紹、swissgold產品特色、使用方法，甚至將swissgold與其他的沖煮咖啡器具做比較，網站內容還滿多的，有興趣的人可以慢慢看。
我上網購自 Y拍：北極海咖啡
沒想到它還是在板橋江翠站附近，看來是註定要買的了。
感謝艾倫兄了~
2009年9月14日 星期一
解析度、畫素與洗照片尺寸
(轉載自 http://www.mobile01.com/topicdetail.php?f=164&t=50944 )
1.解析度：
解析度，慣用單位表示上，以dpi (dot per inch)來顯示，白話一點就是1英吋的長度裡包含了幾個點的個數，
注意啦～這些點是排成一直線的喔！
實質上，就有點像是長度單位裡面又隱藏包含了密度的意義，所以呢...解析度越高，就是1英吋長度內點數越多，也就是我們常說的解析度越高，看起來就越細膩。
舉例說：一條72dpi的線，我們肉眼所看到的這條線，他在每一英吋的長度內，是由72個點所組成，聰明的看官，如你所想：
一條300dpi的線，就是每一英吋的長度內，由300個點所組成。
（注意囉～ 72dpi 與 300dpi ～可是重要數字喔）
2.畫素：
想必大家對〝公分〞這長度單位非常慣用熟悉，然後面積單位〝平方公分〞，
沒錯，畫素其實就有點像是面積的意思。
但它不以平方單位表示，而是以多少畫素來描述。
打各比方說：
例1：
（長度500個點）乘以（長度500個點）＝ 250000個畫素（25萬畫素）
例2：
我們常把螢幕設為：1024*768，此時我們看到的畫素約為78萬6千個畫素，
又因為，螢幕一般解析度為72dpi（或96dpi），所以眼力不太差的話，通常都可看到我們螢幕上的點，
而（寬1024個點）*（高768個點）＝786,432畫素，就構成我們看到的畫面。
註：一般數位相機的CCD（感光元件）拍的數位照片大都為72dpi ←（從ACDSee軟體，可看到這數值）。
註：CCD，比方說，就像是傳統像機的底片。
例3：
一般來說，人的肉眼看圖片，當解析度≧300 dpi 時，就不易察覺我們是在看由一大堆點所組成的圖，也就是說，此時眼睛看到的是：由點組成之非常平滑連續（smoth，continuous）的線，又由線組成之非常平滑連續（smoth，continuous）的面...
簡單講就是〝一張圖〞（既不叫他為〝點〞，也不叫他為〝線〞）。
想必當然，我們一般洗數位照片，就是採用300 dpi 的。
3.洗照片尺寸：
一堆廢話後...大家關心的重點來了...不再贅述，直接舉例說明：
例1.
洗3*5照片＝3英吋*5英吋（採用 300dpi ）
＝（3*300個點）*（5*300個點）＝（3*5*90000）
＝1350000畫素（1百35萬畫素）
同理
例2：
洗4*6照片＝4英吋*6英吋（採用 300dpi ）
＝（4*300個點）*（6*300個點）＝（4*6*90000）
＝ 2160000畫素（2百16萬畫素）
再同理...不贅述了...
洗照片所需畫素：
3*5吋照＝3*5*90000＝1百35萬畫素
4*6吋照＝4*6*90000＝2百16萬畫素...這最常用吧～
5*7吋照＝5*7*90000＝3百15萬畫素
6*8吋照＝6*8*90000＝4百32萬畫素
7*9吋照＝7*9*90000＝5百67萬畫素
1.解析度：
解析度，慣用單位表示上，以dpi (dot per inch)來顯示，白話一點就是1英吋的長度裡包含了幾個點的個數，
注意啦～這些點是排成一直線的喔！
實質上，就有點像是長度單位裡面又隱藏包含了密度的意義，所以呢...解析度越高，就是1英吋長度內點數越多，也就是我們常說的解析度越高，看起來就越細膩。
舉例說：一條72dpi的線，我們肉眼所看到的這條線，他在每一英吋的長度內，是由72個點所組成，聰明的看官，如你所想：
一條300dpi的線，就是每一英吋的長度內，由300個點所組成。
（注意囉～ 72dpi 與 300dpi ～可是重要數字喔）
2.畫素：
想必大家對〝公分〞這長度單位非常慣用熟悉，然後面積單位〝平方公分〞，
沒錯，畫素其實就有點像是面積的意思。
但它不以平方單位表示，而是以多少畫素來描述。
打各比方說：
例1：
（長度500個點）乘以（長度500個點）＝ 250000個畫素（25萬畫素）
例2：
我們常把螢幕設為：1024*768，此時我們看到的畫素約為78萬6千個畫素，
又因為，螢幕一般解析度為72dpi（或96dpi），所以眼力不太差的話，通常都可看到我們螢幕上的點，
而（寬1024個點）*（高768個點）＝786,432畫素，就構成我們看到的畫面。
註：一般數位相機的CCD（感光元件）拍的數位照片大都為72dpi ←（從ACDSee軟體，可看到這數值）。
註：CCD，比方說，就像是傳統像機的底片。
例3：
一般來說，人的肉眼看圖片，當解析度≧300 dpi 時，就不易察覺我們是在看由一大堆點所組成的圖，也就是說，此時眼睛看到的是：由點組成之非常平滑連續（smoth，continuous）的線，又由線組成之非常平滑連續（smoth，continuous）的面...
簡單講就是〝一張圖〞（既不叫他為〝點〞，也不叫他為〝線〞）。
想必當然，我們一般洗數位照片，就是採用300 dpi 的。
3.洗照片尺寸：
一堆廢話後...大家關心的重點來了...不再贅述，直接舉例說明：
例1.
洗3*5照片＝3英吋*5英吋（採用 300dpi ）
＝（3*300個點）*（5*300個點）＝（3*5*90000）
＝1350000畫素（1百35萬畫素）
同理
例2：
洗4*6照片＝4英吋*6英吋（採用 300dpi ）
＝（4*300個點）*（6*300個點）＝（4*6*90000）
＝ 2160000畫素（2百16萬畫素）
再同理...不贅述了...
洗照片所需畫素：
3*5吋照＝3*5*90000＝1百35萬畫素
4*6吋照＝4*6*90000＝2百16萬畫素...這最常用吧～
5*7吋照＝5*7*90000＝3百15萬畫素
6*8吋照＝6*8*90000＝4百32萬畫素
7*9吋照＝7*9*90000＝5百67萬畫素
2009年9月12日 星期六
觀景窗倍率、對焦點分佈
(轉貼自 http://www.wretch.cc/blog/grantliang/)
1. 視野率:
在取景時，透過景觀窗看到的實際畫面．
例如95%視野率，代表你可以看到實際畫面的95%，在其他邊邊角角的地方
是整個被切掉的．這有什麼差別?
差別在於，你抓到了一個完美畫面後，回家一看，發現邊邊怎麼多了隻手啊、腳啊
或者是說，你想拍一個唯美的裸女圖，結果回家一看，發現三點全都入鏡了 (驚喜?)
100%視野率的有：Nikon D300 、Nikon D3 、Sony A900 、Canon 1DsMK3 、Canon 1D MK3 、Nikon D2x
不滿的有：Canon 5D 、Canon 40D 、Nikon D700
2.放大倍率 & 面積：
這純碎是片幅大的屌
片幅越大，他反映出來的觀景窗看起來就越大
放大倍率 = 觀景窗 / 感光元件
反正，要大的，挑全幅機就對了．因為APS機放大倍率再大，始終也是要卡掉，所以反而沒有全幅機來的大
(詳請見全文)
1. 視野率:
在取景時，透過景觀窗看到的實際畫面．
例如95%視野率，代表你可以看到實際畫面的95%，在其他邊邊角角的地方
是整個被切掉的．這有什麼差別?
差別在於，你抓到了一個完美畫面後，回家一看，發現邊邊怎麼多了隻手啊、腳啊
或者是說，你想拍一個唯美的裸女圖，結果回家一看，發現三點全都入鏡了 (驚喜?)
100%視野率的有：Nikon D300 、Nikon D3 、Sony A900 、Canon 1DsMK3 、Canon 1D MK3 、Nikon D2x
不滿的有：Canon 5D 、Canon 40D 、Nikon D700
2.放大倍率 & 面積：
這純碎是片幅大的屌
片幅越大，他反映出來的觀景窗看起來就越大
放大倍率 = 觀景窗 / 感光元件
反正，要大的，挑全幅機就對了．因為APS機放大倍率再大，始終也是要卡掉，所以反而沒有全幅機來的大
(詳請見全文)
2009年8月18日 星期二
面試系統分析設計的好題目
今天終於下定決心update面試考題，看過SAD方面有一篇很好的文章，轉仔原文如下。
(原文轉載自 克明老師Blog 從 Google 書籤看標籤與資料夾的設計觀 ─ 設計篇 )
(原文轉載自 克明老師Blog 從 Google 書籤看標籤與資料夾的設計觀 ─ 設計篇 )
如果我是某大軟體公司的主管，要應徵軟體結構性的設計人員 (偏對技術性，而非需求分析)，一般的職稱是稱之為 系統設計師 (SD, System Designer)，或者號稱為架構師 (Architect)、資深技術人員等。 若他們在履歷表上寫著擅長或懂 "O-O (Object Oriented)" 或 "UML"、結構設計 等，那麼，我不會考他們什麼 UML 語法還是 設計樣式 (Design Pattern) 等等。 那只是 "背書" 而已，一點意義都沒有。 要背書的話，不如直接給個電腦上網，然後要應徵人員展現如何透過 Google 查詢找到如何實做設計樣式的方法還比較實在。
我會提供的考題，必然是針對應徵人員 "自我思考推理" 的能力驗證，答案的正確性完全不重要，重要的是你為什麼是這樣表達設計的，能否自圓其說。 具有獨立思考能力的設計師，這才是人才！
所以，我會提供一個如這樣的考題：
上述的考題是一個 "需求陳述"，應該算是蠻普遍的一般應用常識了。 不過若還是不懂上述的敘述，那麼也可以再佐以範例，來解釋什麼是 書籤、標籤與資料夾的概念。
老實說，我是以為，這類的結構設計應該算是很基礎的了，事實上，答案也比想像得意外簡單。 但是，我也問過好幾個號稱對所謂 設計樣式 很熟悉的資深技術人員，最直接給我的答案就是說： 這不就是 "複合結構 (composite structure)" 樣式的應用嗎？ 不管你說什麼，反正先把設計圖畫出來再說吧。 結果呢，也真的如我所料，表達不出所以然，真的就只是在背書而已。 最大的盲點，就是把 標籤 (Tag) 與 資料夾 (folder) 給關聯在一起，而其實這兩個是一點關係都沒有的；甚至有些還執著在因為 標籤與書籤 的多對多關係，所以又拉出了一個所謂的 "關聯類別 (Association Class)"，卻又說不所以然，越弄越複雜。 因為既然是表達想法，所以類別圖自然是表達 概念 (concept)與概念之間 的關係，而至於那個多對多的關聯類別，是在更細節性的規格設計實做階段再來討論即可，太早論及，反而模糊了要突顯的概念。
表達這類結構性的設計圖，要先找出核心的類別是什麼。 在本例中， "書籤 (bookmark)" 即為本文主體，是最根本的核心類別。 再來當能分別出 標籤 與 資料夾 並沒有關連，而是各自與 書籤 建立關係，那麼，這個設計的表達就可以說對了一大半以上了。 參考的 UML 類別設計如下圖：
我會提供的考題，必然是針對應徵人員 "自我思考推理" 的能力驗證，答案的正確性完全不重要，重要的是你為什麼是這樣表達設計的，能否自圓其說。 具有獨立思考能力的設計師，這才是人才！
所以，我會提供一個如這樣的考題：
Google 書籤 (bookmark)是利用 標籤 (Tag)來作分類的。 一個書籤可以被 "標記" 為一到多個標籤，相對來說，一個標籤可以有一到多個書籤。 另外，標籤是不會含有子標籤 (Sub-Tag) 的。
如果我要改良 Google 書籤的設計，希望能再加上 "資料夾 (folder)" 的管理觀念，也就是說書籤必然會 "放" 在某一個資料夾目錄內 (也只能是唯一)，而某一個資料夾可以擁有一到多個書籤，同時資料夾也能再包含子資料夾 (Sub-folder)。
同樣類似的應用，可以延伸至部落格 (Blog)的本文 (Content)與標籤、目錄 (category)的結構設計。
請你利用 UML 類別圖，來表達出關於 書籤、標籤與資料夾的結構關係，並簡單說明你的設計想法。
上述的考題是一個 "需求陳述"，應該算是蠻普遍的一般應用常識了。 不過若還是不懂上述的敘述，那麼也可以再佐以範例，來解釋什麼是 書籤、標籤與資料夾的概念。
老實說，我是以為，這類的結構設計應該算是很基礎的了，事實上，答案也比想像得意外簡單。 但是，我也問過好幾個號稱對所謂 設計樣式 很熟悉的資深技術人員，最直接給我的答案就是說： 這不就是 "複合結構 (composite structure)" 樣式的應用嗎？ 不管你說什麼，反正先把設計圖畫出來再說吧。 結果呢，也真的如我所料，表達不出所以然，真的就只是在背書而已。 最大的盲點，就是把 標籤 (Tag) 與 資料夾 (folder) 給關聯在一起，而其實這兩個是一點關係都沒有的；甚至有些還執著在因為 標籤與書籤 的多對多關係，所以又拉出了一個所謂的 "關聯類別 (Association Class)"，卻又說不所以然，越弄越複雜。 因為既然是表達想法，所以類別圖自然是表達 概念 (concept)與概念之間 的關係，而至於那個多對多的關聯類別，是在更細節性的規格設計實做階段再來討論即可，太早論及，反而模糊了要突顯的概念。
表達這類結構性的設計圖，要先找出核心的類別是什麼。 在本例中， "書籤 (bookmark)" 即為本文主體，是最根本的核心類別。 再來當能分別出 標籤 與 資料夾 並沒有關連，而是各自與 書籤 建立關係，那麼，這個設計的表達就可以說對了一大半以上了。 參考的 UML 類別設計如下圖：
這張設計圖該如何解讀呢？
先觀察紅色區塊，也就是 書籤 與 標籤 的關係。 從 書籤 的角度來看，它可以被多個 標籤 標記，所以在多重性 (multiplicity)的表達，會是 1..* (一到多)。 再來從 標籤 的角度來看，一個標籤可以有一到多個 書籤，所以也是表達成 1..* 的多重性。圖上在 書籤與標籤 兩端是只使用 * 的符號來表達成 多對多 的關係也沒問題，大概知道意思就可以了。
再來就是觀察藍色區塊這邊，這就是典型的 "複合結構 (composite structure)" 樣式了，它可以呈現出 階層性 (hierarchy) 的樹狀結構關係。 把 書籤與資料夾 的共同特性抽象 (abstract)出來，成為 "Bookmark Entry" 這個抽象類別。 至於有哪些共同的特性呢？ 諸如 add(), remove(), getName() 等這樣的行為都可定義在這個抽象類別內。 而資料夾 (folder)則是 "聚合 (aggregiate)" 了 書籤與資料夾，在 UML 符號是以 空心菱形 來表示。 從 書籤 的角度來看與 資料夾的關係，它必然被包含 (也就是聚合關係)在某一個 資料夾 內，所以在 資料夾 類別這邊的 多重性 是表達為 1；而一個 資料夾 可以有 一到多 個書籤與子資料夾，所以在 "Bookmark Entry" 類別這邊，多重性是表達為 1..* 。
說實在的，即使不會複合結構的表達也沒關係，若能明確地抓出 書籤與資料夾 的關係 (去掉 Bookmark Entry 這個類別)，這就夠了，在這個考題當中，反而要突顯的不會是資料夾的樹狀結構，再次強調，是 書籤、標籤與資料夾 的結構關係。 知道你要表達的焦點何在，這才是關鍵。
再來，又如何知道上述的設計圖是正確的呢？ 那當然就需要驗證了。 不一定非得要寫成程式碼後才能知道設計得正不正確，那太耗時費工了；我強烈建議使用 物件圖 (object diagram)，利用實際的案例，對應所設計的類別，很快就能對比出結構設計的正確性與否了。 物件圖的表達在此就略過不談了，讀者若有興趣，可以利用 UML 工具(如 EA)來練習看看，然後也可以把 Model 檔寄給我，多少我還能協助 Review 驗證的。
※ 延伸參考： o 從 Google 書籤看標籤與資料夾的設計觀 ─ 觀念篇。
先觀察紅色區塊，也就是 書籤 與 標籤 的關係。 從 書籤 的角度來看，它可以被多個 標籤 標記，所以在多重性 (multiplicity)的表達，會是 1..* (一到多)。 再來從 標籤 的角度來看，一個標籤可以有一到多個 書籤，所以也是表達成 1..* 的多重性。圖上在 書籤與標籤 兩端是只使用 * 的符號來表達成 多對多 的關係也沒問題，大概知道意思就可以了。
再來就是觀察藍色區塊這邊，這就是典型的 "複合結構 (composite structure)" 樣式了，它可以呈現出 階層性 (hierarchy) 的樹狀結構關係。 把 書籤與資料夾 的共同特性抽象 (abstract)出來，成為 "Bookmark Entry" 這個抽象類別。 至於有哪些共同的特性呢？ 諸如 add(), remove(), getName() 等這樣的行為都可定義在這個抽象類別內。 而資料夾 (folder)則是 "聚合 (aggregiate)" 了 書籤與資料夾，在 UML 符號是以 空心菱形 來表示。 從 書籤 的角度來看與 資料夾的關係，它必然被包含 (也就是聚合關係)在某一個 資料夾 內，所以在 資料夾 類別這邊的 多重性 是表達為 1；而一個 資料夾 可以有 一到多 個書籤與子資料夾，所以在 "Bookmark Entry" 類別這邊，多重性是表達為 1..* 。
說實在的，即使不會複合結構的表達也沒關係，若能明確地抓出 書籤與資料夾 的關係 (去掉 Bookmark Entry 這個類別)，這就夠了，在這個考題當中，反而要突顯的不會是資料夾的樹狀結構，再次強調，是 書籤、標籤與資料夾 的結構關係。 知道你要表達的焦點何在，這才是關鍵。
再來，又如何知道上述的設計圖是正確的呢？ 那當然就需要驗證了。 不一定非得要寫成程式碼後才能知道設計得正不正確，那太耗時費工了；我強烈建議使用 物件圖 (object diagram)，利用實際的案例，對應所設計的類別，很快就能對比出結構設計的正確性與否了。 物件圖的表達在此就略過不談了，讀者若有興趣，可以利用 UML 工具(如 EA)來練習看看，然後也可以把 Model 檔寄給我，多少我還能協助 Review 驗證的。
※ 延伸參考： o 從 Google 書籤看標籤與資料夾的設計觀 ─ 觀念篇。
2009年8月17日 星期一
Windows XP瘦身
近來頗為disk space所苦，50G的C槽剩2G不到，連要 Update魔獸3.2都沒辦法(需要3.98G)。
安裝 TreeSize Free分析目錄佔用空間，可以自行處理的如 CClean先清一便，system page size改小一點(原開機級配置2048M改為 1024M)，然後關閉系統 休眠功能(release出3G空間)。
進一步分析，發現 \Windows\Installer\ 佔了頗大的容量，查找相關資料：
(以下內容轉載自 愈來愈肥的Windows XP 要做瘦身(Windows Installer實在是很失敗的設計呀) )
用TreeSize Free也發現在C:\WINDOWS\installer底下有超級多沒用的東西....
上網發現....用SmallFrogs寫了Windows Installer UnUsed Files Cleanup Tool這個工具....就可以輕鬆移除了將近1G的空間...
以下是網友鳥毅的心得分享給大家參考....
============================================
作者:鳥毅
來源:http://blog.tenyi.com/2008/04/windows.html
自從2002年用Windows XP到現在，已經不記得重裝過多少次。重灌不止只系統會變快，還會變小，就算是安裝相同的程式。鳥毅一 直很疑惑為什麼會有這種事？最近有兩台Server的C碟也隨著同事的使用爆掉，昨天赫然發現自己在用的XP的C碟也爆了，只剩幾MB。這絕對不是 一般使用者能解決的事情，雖然鳥毅在2003年上過MCSE Part I的課程，也只有學到把%SystemRoot%下$開頭的Windows Update備份檔砍掉，但我全都砍光了呀？於是下載WinDirStat這 個Open Source的工具對目錄分析，原來是%SystemRoot%\installer這個目錄搞的鬼。裏面的東西全砍的話，以後Windows Update別想成功，已安裝的軟體也別想移除了。（唉，Windows Installer實在是很失敗的設計呀！）搜尋一下相關訊息，看到這、這時本來以為無望了，實在有點麻煩。再看到說明 Windows Installer CleanUp 公用程式時露出一線曙光，仔細看看只是修正跳出找不到原來msi視窗的問題，並不是我要的工具。最後，皇天不負苦心人（我找了半小時）終於看到冗餘 Windows Installer 文件的清理，SmallFrogs寫了Windows Installer UnUsed Files Cleanup Tool這個工具。在使用此工具後發現：還有個%SystemRoot%\Installer\$PatchCache$的目錄，會再cache一份這些資料，而WICleanup並不會刪除這個目錄，咱們必須自個兒動手。幹這些事實在很辛苦，而且Windows一天到晚出update，垃圾超級多；用Ubuntu可以apt-get autoclean，為啥windows做不到呢？
安裝 TreeSize Free分析目錄佔用空間，可以自行處理的如 CClean先清一便，system page size改小一點(原開機級配置2048M改為 1024M)，然後關閉系統 休眠功能(release出3G空間)。
進一步分析，發現 \Windows\Installer\ 佔了頗大的容量，查找相關資料：
(以下內容轉載自 愈來愈肥的Windows XP 要做瘦身(Windows Installer實在是很失敗的設計呀) )
用TreeSize Free也發現在C:\WINDOWS\installer底下有超級多沒用的東西....
上網發現....用SmallFrogs寫了Windows Installer UnUsed Files Cleanup Tool這個工具....就可以輕鬆移除了將近1G的空間...
以下是網友鳥毅的心得分享給大家參考....
============================================
作者:鳥毅
來源:http://blog.tenyi.com/2008/04/windows.html
自從2002年用Windows XP到現在，已經不記得重裝過多少次。重灌不止只系統會變快，還會變小，就算是安裝相同的程式。鳥毅一 直很疑惑為什麼會有這種事？最近有兩台Server的C碟也隨著同事的使用爆掉，昨天赫然發現自己在用的XP的C碟也爆了，只剩幾MB。這絕對不是 一般使用者能解決的事情，雖然鳥毅在2003年上過MCSE Part I的課程，也只有學到把%SystemRoot%下$開頭的Windows Update備份檔砍掉，但我全都砍光了呀？於是下載WinDirStat這 個Open Source的工具對目錄分析，原來是%SystemRoot%\installer這個目錄搞的鬼。裏面的東西全砍的話，以後Windows Update別想成功，已安裝的軟體也別想移除了。（唉，Windows Installer實在是很失敗的設計呀！）搜尋一下相關訊息，看到這、這時本來以為無望了，實在有點麻煩。再看到說明 Windows Installer CleanUp 公用程式時露出一線曙光，仔細看看只是修正跳出找不到原來msi視窗的問題，並不是我要的工具。最後，皇天不負苦心人（我找了半小時）終於看到冗餘 Windows Installer 文件的清理，SmallFrogs寫了Windows Installer UnUsed Files Cleanup Tool這個工具。在使用此工具後發現：還有個%SystemRoot%\Installer\$PatchCache$的目錄，會再cache一份這些資料，而WICleanup並不會刪除這個目錄，咱們必須自個兒動手。幹這些事實在很辛苦，而且Windows一天到晚出update，垃圾超級多；用Ubuntu可以apt-get autoclean，為啥windows做不到呢？
2009年8月15日 星期六
資料存取新境界 - LINQ
LINQ - Language-Integrated Query：微軟於Visual Studio 2008版本同步發表的新技術。
這個時代(早在幾年前)的程式開發過程，對於Data的存取、操作議題即已不可分離，甚至成為程式開發過程中的核心，但以往存取各種不同型態的資料來源，如Access、SQL等關聯式資料庫，txt、csv、XML等Flat file，程式執行過程中的memory data...這類都泛稱的「DATA」，各自有其專屬的開關檔、存取、操作方式，一種資料型式就對應一套以上的方法必須學習。LINQ技術的出現，讓人為之眼睛一亮之處，即為對上述窘境的一線曙光，並且LINQ是程式語言層級，在其中崁入自訂函式的應用是再自然不過的事，從此以後，資料的"取得"與"處理"由原本的溝通過程變為整合在一起；姑且不論目前只針對Object(.NET內的)、XML、ADO.NET(SQL、Dataset)的支援 (幾乎足夠了!)，至少，它敢用「Integrated 」這個字，就我對Micro$oft的了解，應是可以期待的。
LINQ的另一層意義，對於我們團隊目前需從 .NET 1.1跨上 .NET 3.5的挑戰來說，它背後蘊含了很多核心概念與技術：匿名型別（Anonymous type）、泛型(Generic) - 尤其泛型介面 IEnumerable、擴展方法 (Extension method)、甚至 Lambda表達式 (Lambda expression)... 等 都需深入了解。
這個時代(早在幾年前)的程式開發過程，對於Data的存取、操作議題即已不可分離，甚至成為程式開發過程中的核心，但以往存取各種不同型態的資料來源，如Access、SQL等關聯式資料庫，txt、csv、XML等Flat file，程式執行過程中的memory data...這類都泛稱的「DATA」，各自有其專屬的開關檔、存取、操作方式，一種資料型式就對應一套以上的方法必須學習。LINQ技術的出現，讓人為之眼睛一亮之處，即為對上述窘境的一線曙光，並且LINQ是程式語言層級，在其中崁入自訂函式的應用是再自然不過的事，從此以後，資料的"取得"與"處理"由原本的溝通過程變為整合在一起；姑且不論目前只針對Object(.NET內的)、XML、ADO.NET(SQL、Dataset)的支援 (幾乎足夠了!)，至少，它敢用「Integrated 」這個字，就我對Micro$oft的了解，應是可以期待的。
LINQ的另一層意義，對於我們團隊目前需從 .NET 1.1跨上 .NET 3.5的挑戰來說，它背後蘊含了很多核心概念與技術：匿名型別（Anonymous type）、泛型(Generic) - 尤其泛型介面 IEnumerable
2009年8月13日 星期四
泛型場合-使用C#
(全篇轉載自 .NET Midway )
自C++以來, Generic(泛型) 始終是我很喜歡的一種機制, 在.NET 2.0終於納入後, 當然也把它實作在我們的系統中. 以自己的使用心得來說, 我覺得, 這個世界因為有Generic而變得更美好~ ha ha.或許一般最常提出的問題就是：為什麼要用Generic? 是的, 沒有Generic也活的好好的, 看不出差別在什麼地方.當我們廣泛的去使用物件繼承關係, 當我們習慣不去考慮彈性問題, 通常會變成大量物件去繼承某一個基底型別時, 而同時不自覺得習慣用該基底型別當作參數傳遞, 函式傳回的型別. 因此我們的程式碼中, 就會出現大量的轉型動作, Boxing動作.而Generic出現的場合正是：1. 針對某一系列的型別進行處理, 特別當是用集合型別來處理時.若系統中有許多ArrayList, 那就該考慮改用List<>之類的泛型集合.2. 若系統必須將一堆ValueType變數以集合型別暫存(像 array, ArrayList), 也可以用泛型來取代, 用以避免Boxing的出現.3. 程式中的集合型別只能處理特別型別時採用例如：某一函式所傳入的參數, 只能是繼承BusinessEntity基底類別時, 我們可以這樣寫..
4. 最佳化程式碼的重複使用.就像System.Collections.Generic.List<>來說, 在經過最佳化之後的集合類別, 可以提供給任何型別來使用, 不必再自行定義多組特別型別的集合.5. 不只是集合.雖然上例提到的多是集合的用法(這也是Generic最好發揮之處), 但無論是interface, method, parameter, delegate..., 只要有需要, Generic都能幫助我們做好該做的事.若再進一步, 讓Generic與Reflection結合在一起, 所產生的威力更是強大. 例如將它們套用在Factory Pattern中, 或是應用在ORM中, 用以產生persistence object.無論如何, 在有Generic的世界, 不去善用它, 就像是自廢武功一樣. 當然, 我們的前提是使用泛型時必須經過良好的物件導向設計, 分析出需要Generic的場合, 而必須避免over design, 將一切都給泛型化.
自C++以來, Generic(泛型) 始終是我很喜歡的一種機制, 在.NET 2.0終於納入後, 當然也把它實作在我們的系統中. 以自己的使用心得來說, 我覺得, 這個世界因為有Generic而變得更美好~ ha ha.或許一般最常提出的問題就是：為什麼要用Generic? 是的, 沒有Generic也活的好好的, 看不出差別在什麼地方.當我們廣泛的去使用物件繼承關係, 當我們習慣不去考慮彈性問題, 通常會變成大量物件去繼承某一個基底型別時, 而同時不自覺得習慣用該基底型別當作參數傳遞, 函式傳回的型別. 因此我們的程式碼中, 就會出現大量的轉型動作, Boxing動作.而Generic出現的場合正是：1. 針對某一系列的型別進行處理, 特別當是用集合型別來處理時.若系統中有許多ArrayList, 那就該考慮改用List<>之類的泛型集合.2. 若系統必須將一堆ValueType變數以集合型別暫存(像 array, ArrayList), 也可以用泛型來取代, 用以避免Boxing的出現.3. 程式中的集合型別只能處理特別型別時採用例如：某一函式所傳入的參數, 只能是繼承BusinessEntity基底類別時, 我們可以這樣寫..
4. 最佳化程式碼的重複使用.就像System.Collections.Generic.List<>來說, 在經過最佳化之後的集合類別, 可以提供給任何型別來使用, 不必再自行定義多組特別型別的集合.5. 不只是集合.雖然上例提到的多是集合的用法(這也是Generic最好發揮之處), 但無論是interface, method, parameter, delegate..., 只要有需要, Generic都能幫助我們做好該做的事.若再進一步, 讓Generic與Reflection結合在一起, 所產生的威力更是強大. 例如將它們套用在Factory Pattern中, 或是應用在ORM中, 用以產生persistence object.無論如何, 在有Generic的世界, 不去善用它, 就像是自廢武功一樣. 當然, 我們的前提是使用泛型時必須經過良好的物件導向設計, 分析出需要Generic的場合, 而必須避免over design, 將一切都給泛型化.
2009年8月12日 星期三
取得重返戰場的第一塊敲門磚~ 考取OMG-Certified UML Professional Fundamental
自從2009/ 6/27、6/28參加 邱郁惠老師開的「OCUP/UML初級認證課程」，算是這10年職涯中真正踏實的進入了系統分析、設計領域，我想，這真的是我要的，短期內我可以不必再左顧PG領域的MCSD、DBA、LINQ、ASP 3.x，右盼PMP~~
2009/7/31 拿到OCUP的認證算是踏出了第一步，看到Prometric上show出的"Congratulation"時，似乎一點感覺也沒有，這應該就代表了真的是第一步，因為，在工作上我一樣無法如法如行雲流水般的將心中的系統分析、設計概念轉化為UML notation(即使已杵在那2個多小時之久了，仍不知如何下手...)。
我想，我缺的是經驗~ 缺少實際參與多樣的case study設計核心中，缺少實際自頭到尾的分析、設計過程，包含對 tool的熟悉、概念的表達...。
訂閱：
文章 (Atom)