蒐集網上分享~
對 EOS 20D機身參數：
對比 -2
銳利度+2
飽和度+1
色調 +0
只拍RAW檔
進DPP調整
DPP3.7.2設定
+RAW影像調整
---暗部調整(1) --> 是-1吧~!!
---銳利度(4)
+進階調整
---亮域雜訊抑制(0) --> 4
色差雜訊抑制 -> 5
這組設定測試過後最耐看
色階自然,銳利度OK.
有調整飽和度所以顏色上會比較討喜.
其他的部分都最接近現場感覺.
測試後發現DPP轉出的JPG(直出、或先TIFF再PhotoCap4轉JPG)整個雪花一片...
研究後發現是"亮域雜訊抑制"的問題 (參 [測試]canon 機身與後製消除雜訊分析 一文)，
後來，改設定
亮域雜訊抑制 -> 4
色差雜訊抑制 -> 5
轉出的JPG終於是適合人看得了~~
2009年12月19日 星期六
2009年12月7日 星期一
無線解決方案 - WDS survey (醞釀實作!)
有在用無線AP的一定都常為訊號不穩、熱當~這類問題所苦，近來適逢家裡網路幾乎掛點的狀況，為何用"幾乎"~!因為開個IE竟然要30秒~首頁是google傳統頁ㄟ~~越想越不對，烏龜重置然後爛SMC AP也power down了，狀況一樣沒改善，原以為SMC爛只影響無線的狀況，沒想到用有線連的PC也一樣，重點是，我的wow也沒法玩了~~這簡直是太嚴重了，看來該下定決心換掉它了。
----------------------------------- 分隔 ----------------------------------------
survey解法，有一款 Ruckus 覆蓋王 似乎不錯，但價格不斐，要 $3xxx ，而且我的狀況是樓中樓，也怕它只是距離遠但穿透性無法合我所用；繼續爬文後，發現另一個 solution - Wireless Distribution System(WDS) ，嗯~這似乎能解決我的問題，而且也能保留往後擴充~
這二篇文章：
----------------------------------- 分隔 ----------------------------------------
survey解法，有一款 Ruckus 覆蓋王 似乎不錯，但價格不斐，要 $3xxx ，而且我的狀況是樓中樓，也怕它只是距離遠但穿透性無法合我所用；繼續爬文後，發現另一個 solution - Wireless Distribution System(WDS) ，嗯~這似乎能解決我的問題，而且也能保留往後擴充~
這二篇文章：
可以好好參考，搭 SparkLAN 速連通訊 WRTR-142 802.11g 無線路由器 $888，加購一根10 dBi天線Y購也只要$690搞定，
看來甚至我不必急者買2臺AP，先買一台+天線，或許連WDS都不必了，等試過再報告了。
另外的選擇： 上網3件事DIR-600實測 (上網+下載+Skype) ，看來D-Link可以考慮。
華碩ASUS WL-520GU 似乎也不錯，配合 華碩WL-520gu刷tomato問題請教 這篇改機。
華碩ASUS WL-520GU 似乎也不錯，配合 華碩WL-520gu刷tomato問題請教 這篇改機。
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的熟悉、概念的表達...。
2009年7月4日 星期六
認真對待我的EOS 20D
近期心底小惡魔又在作祟~ 很哈 EOS 5D Mark II，爬了很多文，果然Mobile01還是少去為妙。
當然，現實問題終要面對，也讓我冷靜了不少，審視自己對攝影的心力投入真的不算多，20D使用到現在有二年了，二顆鏡頭 17-40L與 24-70L 不算差，但我真的有摸透它嗎？ 最慚愧的是都沒有認真的面對會移焦的問題，或許我該花點錢送它去調焦一下才算對得起它~~
這二天回家研究了一下手上 24-70L的移焦狀況(還虧當時有敗入焦點工坊的裂像+井字對焦屏)，先AF後輔以手動調整(這要練直覺!)，尤其是要拍攝一刻都停不下來的小朋友，室內 ISO 800 F2.8 下去對幹~ 還是十分辛苦，看來微弱的內閃+醜醜擴散片多少補上了點速度，M mode快門終於可以放心回到 1/80以上而 ISO也可以下來 400~~
終於，不準焦的狀況大大改善，經過 DPP調AWB、曝光度和銳化，再給PhotoCap轉JPG後有不錯的成果。
可以至我的相簿參觀。
當然，現實問題終要面對，也讓我冷靜了不少，審視自己對攝影的心力投入真的不算多，20D使用到現在有二年了，二顆鏡頭 17-40L與 24-70L 不算差，但我真的有摸透它嗎？ 最慚愧的是都沒有認真的面對會移焦的問題，或許我該花點錢送它去調焦一下才算對得起它~~
這二天回家研究了一下手上 24-70L的移焦狀況(還虧當時有敗入焦點工坊的裂像+井字對焦屏)，先AF後輔以手動調整(這要練直覺!)，尤其是要拍攝一刻都停不下來的小朋友，室內 ISO 800 F2.8 下去對幹~ 還是十分辛苦，看來微弱的內閃+醜醜擴散片多少補上了點速度，M mode快門終於可以放心回到 1/80以上而 ISO也可以下來 400~~
終於，不準焦的狀況大大改善，經過 DPP調AWB、曝光度和銳化，再給PhotoCap轉JPG後有不錯的成果。
可以至我的相簿參觀。
2009年5月4日 星期一
小型相機側背包Jenova TW-3100
找了好久的小包，想一機一鏡帶著出門外型要讚不要別人一看到心裡OS就是「聳聳攝影師」~
連內襯都買好了...
終於，網路上物色到了這一款
連內襯都買好了...
終於，網路上物色到了這一款
有型~~
詳細分享文請見 http://blog.xuite.net/cuteman/blog/13477129
要找個良辰吉時把它迎回家。
2009年4月24日 星期五
NB換購記憶體DDR2 633 4G後的兩三事
有鑑於XP只抓得到3G~3.25G的龜事，基於要彰顯這 $700*2的效益，想辦法揪出那 1G的閒置空間勢在必行~
Survey SUPERCACHE & RAMDISK 二個議題：
關於記憶體的使用方式思考與設定
SuperCache設定心得
Survey SUPERCACHE & RAMDISK 二個議題：
關於記憶體的使用方式思考與設定
SuperCache設定心得
RAM Disk搭配OS開關機
(轉載自 http://id-phatman.spaces.live.com/Blog/cns!CA763CA8DB2378D1!561.entry)
用了gavotte的ramdisk半年了，逐漸琢磨出了一些好的使用方法，順手分享下
在ramdisk的目錄，創建兩個批次處理, ramdiskload.bat 和ramdisksave.bat, 然後點開始/運行，輸入gpedit.msc, 會出來組策略管理器，在“windows settings”下的"scripts(startup/shutdown)"下有"startup"和"shutdown"兩個子項，分別把ramdiskload.bat和ramdisksave.bat載入，然後關閉組策略管理器，這樣windows就會在啟動的時候運行ramdiskload.bat，關閉的時候運行ramdisksave.bat.在ramdisk的目錄，創建兩個批處理, ramdiskload.bat和ramdisksave.bat,然後點開始/運行，輸入gpedit.msc,會出來組策略管理器，在“windows settings”下的"scripts(startup/shutdown )"下有"startup"和"shutdown"兩個子項，分別把ramdiskload.bat和ramdisksave.bat載入，然後關閉組策略管理器，這樣windows就會在啟動的時候運行ramdiskload.bat，關閉的時候運行ramdisksave.bat.
這樣做有什麼好處呢？這樣做有什麼好處呢？
部分朋友主要是用ramdisk把IE cache和TEMP指向ramdisk，其實很多小東東都可以這樣的，比如我就是把Maxthon放到了ramdisk上，比如放到R:\Max部分朋友主要是用ramdisk把IE cache和TEMP指向ramdisk，其實很多小東東都可以這樣的，比如我就是把Maxthon放到了ramdisk上，比如放到R:\Max
這樣在ramdiskload.bat寫入這樣在ramdiskload.bat寫入 代碼代碼
rar.exe x -o+ E:\RamDisk\max.rar r: rar.exe x -o+ E:\RamDisk\max.rar r:
在ramdisksave.bat寫入在ramdisksave.bat寫入 代碼代碼
if Exist E:\RamDisk\max.rar.bak del E:\RamDisk\max.rar.bak if Exist E:\RamDisk\max.rar.bak del E:\RamDisk\max.rar.bak
if Exist E:\RamDisk\max.rar ren E:\RamDisk\max.rar max.rar.bak if Exist E:\RamDisk\max.rar ren E:\RamDisk\max.rar max.rar.bak
rar.exe a -r -m0 E:\RamDisk\max.rar r:\max rar.exe a -r -m0 E:\RamDisk\max.rar r:\max
這樣系統啟動的時候就把Maxthon解壓到ramdisk，關閉的時候就自動保存Maxthon到硬碟這樣系統啟動的時候就把Maxthon解壓到ramdisk，關閉的時候就自動保存Maxthon到硬盤
如果ramdisk夠大，還可以把一些頻繁磁片操作的程式放到ramdisk上，比如我就是把雷電ftpd整個放到ramdisk上，因為雷電的log檔寫入頻繁如果ramdisk夠大，還可以把一些頻繁磁盤操作的程式放到ramdisk上，比如我就是把雷電ftpd整個放到ramdisk上，因為雷電的log文件寫入頻繁
看股票的朋友，如果用的是通達信的版本，也可以全部放到ramdisk上，這樣就不會聽到程式獲取股票資訊的時候哢哢響了看股票的朋友，如果用的是通達信的版本，也可以全部放到ramdisk上，這樣就不會聽到程式獲取股票資訊的時候哢哢響了
最後提醒一句，系統崩潰或別的任何原因系統未進入正常關機流程您存在RAMdisk裏的資料會丟失！最後提醒一句，系統崩潰或別的任何原因係統未進入正常關機流程您存在RAMdisk裡的數據會丟失！
2009年4月23日 星期四
2009年4月7日 星期二
關於架構
（轉載Max 分享的silverlight 文章）
2009年2月7日 星期六
從Silverlight開發架構看到的一些感慨
最近在撰寫Silverlight的文稿(書稿和雜誌稿)、範例、和一些課程教材的時候，
看到Web 開發技術的發展回頭對比台灣的開發環境實在有一些感慨。
先講第一個，話說從頭，有一陣子我介紹了ASP.NET上的MVC，MVC這個
架構是個好的 Pattern，可以幫助開發人員達成建構出有架構、便於更新維護、
便於抽換的應用程式， 問題是這是(只是)一個規範、一個樣式，所謂的規範就
表示，你應該遵循藉以得到一些好 處，但是有趣的是，規範這個東西在台灣
不見得一定會被遵循，老實說我本來以為在全世 界都是這樣，但是根據我的
觀察，在台灣這個狀況比較明顯，反觀我在台灣以外的一些合 作夥伴和團隊，
對於 "規範" 這個事情的嚴謹度和遵守(你也可以說是死板)，超過了我的想像
和期待。 我舉幾個簡單的例子:
1.估時程：我常常看到，為了爭取到某一個案子，在時程評估的時候，
就已經放棄架構了，我們給了客戶一個若要遵循架構就根本不可能達成的
預計完成時間。
2.當進度落後：當進度落後的時候更慘，本來SA,SD花時間想好的架構，
可以因為進度理由一夕之間失效，更有趣的是，這個架構可能是先前花了
兩三個月決定的，但是Developer+PM可以在一天內推翻。
3.當客戶要求不合理：一樣的狀況, 有時候客戶會有一些超越常態或是超越
技術可能性的要求，為了成案，往往PM答應的莫名其妙，而怪的是，
最後還是可以做得出來，天知道這後面隱藏了哪些可怕的東西。
剛講到MVC和所謂的規範，可能很多人對我說的 "規範" 的定義不清楚，
舉個ASP.NET開發人員應該要知道的例子，有幾個我所謂的規範簡單的
具體例子就是：
1.ASP.NET 頁面(.aspx和.aspx.cs 或.aspx.vb)當中，不得有
ConnectionString or SQL 指令。(你應該寫在一個表(不管是資料表或是
對照表)當中，以便於後續維護。(但是，誰敢說自己的.vb或.cs中沒有
SQL指令碼?我看是一堆吧...)
2.ASP.NET程式碼當中不該有商業邏輯，只能有處理UI的Code, 也就是說，
你應該要有一個Business object。
3.超過100行的Method或Sub, Function 應該再切割。
類似像上面這樣的說習慣也好, 說規範也行，是不應該被打破的，但是，
有多少因為時程關係而破壞規範的例子? 多的慘不忍睹。
在連續幾次課程中我被問到MVC之後，我的回答開始變成：如果你(或你的
開發人員)，無法嚴守上面這幾個規範，那就不應該去想ASP.NET MVC，
因為這(MVC)不符合你的需求。
MVC是一個保持(證)系統架構清晰、具有延展性、可抽換性的開發架構，
以降低維護成本 提高重用性，但是如果你的Code是上面這樣的寫法，
那完全不可能接受MVC的規範。
好，回來談Silverlight, 上課時，我很清楚的跟學員介紹了Silverlight RIA
抓取後端資 料庫的方式，大致上如下：
1.撰寫一個Business Object(包含Data Access Class)來抓取資料庫中的資訊，
例如請假資料...(這邊應當是 AP層)
2.利用WCF或WebService撰寫一個Service，來調用剛才寫的
Business Object，這是Service層。
3.在Silverlight應用程式當中，調用遠端的Web Service來存取並顯示資料。
(這邊是展示層)
曾經有幾個學員問到說，怎麼會這麼麻煩呢?
我為什麼不能像以前寫Windows應用程式和Web應用程式時一樣，用一個
SqlDataSource或是"直接"撈DB中的資料呢?
當我聽到這個問題之後大為震驚，這表示
1.原來以前大家都是在處理展示層的UI上，直接抓取後端資料?
2.原來過去大家很少撰寫Business Object或是Service，都是透過ADO.NET
直搗狂龍式的取得DB中的內容?
(不過, 我欣賞學員願意問的求知慾, 只有這樣才能持續成長, 比起在心裡覺得
怪怪的但總是沒問出問題的學員, 他們會進步得較快)
如果是這樣，那怎麼同樣的學員會問MVC的問題呢? 這沒道理啊, MVC的概念
根本不是這樣啊? 原來，學員提到準備要導入MVC開發架構，但是他心裡其實
對MVC還沒個底，並不知道改成MVC之後，比起他現在的開發方式額外要
撰寫很多、很多很多的Class...
真的是 "變得" 比較麻煩嗎？還是其實是過去為了一時的便利, "省去了"
太多太多 本來其實應該要做的工作呢?
我的一個前輩告訴我，先前他對Design Pattren概念雖然很清楚，
但是總是覺得彆扭，和台灣的架構師們討論起來也覺得沒那麼自然，
似乎很難應用。後來有一次，他參與國外的一個開發團隊，發現在這個團隊
當中，有著來自世界各國的優秀成員，在當中討論系統architecture的時候，
在會議中，每個人討論起開發架構，其中Design pattrene觀念似乎是理所當然
的，像喝水一樣，很多的爭辯只會到某人提出應該要用某種Pattern來解決為止
，不會有任何其他的疑問，架構和規範像聖經一樣牢不可破。
我並沒有說(我也沒資格說)怎樣一定比較好，坦白說我以前寫的一些範例也並
不敢說全然依照上面的規範，只是回頭想想覺得有點感慨，當我們在討論RIA
或是Silverlight的時候，好像一直講的都是你的程式可以怎樣炫、可以怎樣讓人
感覺不同、有怎樣的使用者體驗...但是卻忽略了開發架構是一切的根本，
為何我要建議學員考慮把一些ASP.NET的應用程式改以 Silverlight來開發，
原因不是炫、是這樣的開發架構才較為合理。
Silverlight有清楚的展示層、服務層、AP層、DB層的觀念, 除了展示層之外的
東西，都應該是與UI無關的，和過去ASP.NET開發人員習慣(但不應該)把所有
東西綁成一坨混在一起是不一樣的。
我還是這麼說，應該把技術應用在適當的場合，技術本身有延續性，
很多新技術的出現，都是因為要解決過去的一些問題，UI只是其中之一，
除了UI之外，開發架構是一個開發Team的核心競爭力，否則我們的開發團隊
很可能只能持續的從勞力苦工中獲取很低很低很低的毛利，很類似台灣的代工
製造業現在面對的問題，開發團隊中沒有一些累積出可重用的元件其實是一件
很可怕的事情...
從團隊到個人也是，過去的經驗的累積(包含知識、專案、成品、元件)，會是
開發人員與其他開發人員不同之處，我知道每一個開發人員現在其實都很累，
面對專案、面對一些其他有的沒的，但是如果可以，還是建議大家，
多花一點時間在架構上，對於開發人員來說，這應該是只有好處的。
2009年2月7日 星期六
從Silverlight開發架構看到的一些感慨
最近在撰寫Silverlight的文稿(書稿和雜誌稿)、範例、和一些課程教材的時候，
看到Web 開發技術的發展回頭對比台灣的開發環境實在有一些感慨。
先講第一個，話說從頭，有一陣子我介紹了ASP.NET上的MVC，MVC這個
架構是個好的 Pattern，可以幫助開發人員達成建構出有架構、便於更新維護、
便於抽換的應用程式， 問題是這是(只是)一個規範、一個樣式，所謂的規範就
表示，你應該遵循藉以得到一些好 處，但是有趣的是，規範這個東西在台灣
不見得一定會被遵循，老實說我本來以為在全世 界都是這樣，但是根據我的
觀察，在台灣這個狀況比較明顯，反觀我在台灣以外的一些合 作夥伴和團隊，
對於 "規範" 這個事情的嚴謹度和遵守(你也可以說是死板)，超過了我的想像
和期待。 我舉幾個簡單的例子:
1.估時程：我常常看到，為了爭取到某一個案子，在時程評估的時候，
就已經放棄架構了，我們給了客戶一個若要遵循架構就根本不可能達成的
預計完成時間。
2.當進度落後：當進度落後的時候更慘，本來SA,SD花時間想好的架構，
可以因為進度理由一夕之間失效，更有趣的是，這個架構可能是先前花了
兩三個月決定的，但是Developer+PM可以在一天內推翻。
3.當客戶要求不合理：一樣的狀況, 有時候客戶會有一些超越常態或是超越
技術可能性的要求，為了成案，往往PM答應的莫名其妙，而怪的是，
最後還是可以做得出來，天知道這後面隱藏了哪些可怕的東西。
剛講到MVC和所謂的規範，可能很多人對我說的 "規範" 的定義不清楚，
舉個ASP.NET開發人員應該要知道的例子，有幾個我所謂的規範簡單的
具體例子就是：
1.ASP.NET 頁面(.aspx和.aspx.cs 或.aspx.vb)當中，不得有
ConnectionString or SQL 指令。(你應該寫在一個表(不管是資料表或是
對照表)當中，以便於後續維護。(但是，誰敢說自己的.vb或.cs中沒有
SQL指令碼?我看是一堆吧...)
2.ASP.NET程式碼當中不該有商業邏輯，只能有處理UI的Code, 也就是說，
你應該要有一個Business object。
3.超過100行的Method或Sub, Function 應該再切割。
類似像上面這樣的說習慣也好, 說規範也行，是不應該被打破的，但是，
有多少因為時程關係而破壞規範的例子? 多的慘不忍睹。
在連續幾次課程中我被問到MVC之後，我的回答開始變成：如果你(或你的
開發人員)，無法嚴守上面這幾個規範，那就不應該去想ASP.NET MVC，
因為這(MVC)不符合你的需求。
MVC是一個保持(證)系統架構清晰、具有延展性、可抽換性的開發架構，
以降低維護成本 提高重用性，但是如果你的Code是上面這樣的寫法，
那完全不可能接受MVC的規範。
好，回來談Silverlight, 上課時，我很清楚的跟學員介紹了Silverlight RIA
抓取後端資 料庫的方式，大致上如下：
1.撰寫一個Business Object(包含Data Access Class)來抓取資料庫中的資訊，
例如請假資料...(這邊應當是 AP層)
2.利用WCF或WebService撰寫一個Service，來調用剛才寫的
Business Object，這是Service層。
3.在Silverlight應用程式當中，調用遠端的Web Service來存取並顯示資料。
(這邊是展示層)
曾經有幾個學員問到說，怎麼會這麼麻煩呢?
我為什麼不能像以前寫Windows應用程式和Web應用程式時一樣，用一個
SqlDataSource或是"直接"撈DB中的資料呢?
當我聽到這個問題之後大為震驚，這表示
1.原來以前大家都是在處理展示層的UI上，直接抓取後端資料?
2.原來過去大家很少撰寫Business Object或是Service，都是透過ADO.NET
直搗狂龍式的取得DB中的內容?
(不過, 我欣賞學員願意問的求知慾, 只有這樣才能持續成長, 比起在心裡覺得
怪怪的但總是沒問出問題的學員, 他們會進步得較快)
如果是這樣，那怎麼同樣的學員會問MVC的問題呢? 這沒道理啊, MVC的概念
根本不是這樣啊? 原來，學員提到準備要導入MVC開發架構，但是他心裡其實
對MVC還沒個底，並不知道改成MVC之後，比起他現在的開發方式額外要
撰寫很多、很多很多的Class...
真的是 "變得" 比較麻煩嗎？還是其實是過去為了一時的便利, "省去了"
太多太多 本來其實應該要做的工作呢?
我的一個前輩告訴我，先前他對Design Pattren概念雖然很清楚，
但是總是覺得彆扭，和台灣的架構師們討論起來也覺得沒那麼自然，
似乎很難應用。後來有一次，他參與國外的一個開發團隊，發現在這個團隊
當中，有著來自世界各國的優秀成員，在當中討論系統architecture的時候，
在會議中，每個人討論起開發架構，其中Design pattrene觀念似乎是理所當然
的，像喝水一樣，很多的爭辯只會到某人提出應該要用某種Pattern來解決為止
，不會有任何其他的疑問，架構和規範像聖經一樣牢不可破。
我並沒有說(我也沒資格說)怎樣一定比較好，坦白說我以前寫的一些範例也並
不敢說全然依照上面的規範，只是回頭想想覺得有點感慨，當我們在討論RIA
或是Silverlight的時候，好像一直講的都是你的程式可以怎樣炫、可以怎樣讓人
感覺不同、有怎樣的使用者體驗...但是卻忽略了開發架構是一切的根本，
為何我要建議學員考慮把一些ASP.NET的應用程式改以 Silverlight來開發，
原因不是炫、是這樣的開發架構才較為合理。
Silverlight有清楚的展示層、服務層、AP層、DB層的觀念, 除了展示層之外的
東西，都應該是與UI無關的，和過去ASP.NET開發人員習慣(但不應該)把所有
東西綁成一坨混在一起是不一樣的。
我還是這麼說，應該把技術應用在適當的場合，技術本身有延續性，
很多新技術的出現，都是因為要解決過去的一些問題，UI只是其中之一，
除了UI之外，開發架構是一個開發Team的核心競爭力，否則我們的開發團隊
很可能只能持續的從勞力苦工中獲取很低很低很低的毛利，很類似台灣的代工
製造業現在面對的問題，開發團隊中沒有一些累積出可重用的元件其實是一件
很可怕的事情...
從團隊到個人也是，過去的經驗的累積(包含知識、專案、成品、元件)，會是
開發人員與其他開發人員不同之處，我知道每一個開發人員現在其實都很累，
面對專案、面對一些其他有的沒的，但是如果可以，還是建議大家，
多花一點時間在架構上，對於開發人員來說，這應該是只有好處的。
2009年3月25日 星期三
狂賀~中華郵政驗收了~~
就如當初在房仲那邊簽約成交我人生的第一棟房子的當下的情境一樣，心情平靜到沒有什麼喜悅的樣子，好像喝水一樣的平淡無奇，很空~~沒有什麼真實感
不過，話說回來，這真是一件很該開心的事情，至少大家這十六個月來的努力終於有了名份，上頭天一樣高的老闆也終於有笑顏了。
哈哈(乾笑兩聲)~~希望這份喜悅感能維持到這個周末，因為我知道後面還一堆狗屁倒灶的鳥事正領著幾週前就抽到的號碼牌在等我，我也彷彿聽到它正ㄎㄎ的奸笑著：等你很久了~~~~~~~
不過，話說回來，這真是一件很該開心的事情，至少大家這十六個月來的努力終於有了名份，上頭天一樣高的老闆也終於有笑顏了。
哈哈(乾笑兩聲)~~希望這份喜悅感能維持到這個周末，因為我知道後面還一堆狗屁倒灶的鳥事正領著幾週前就抽到的號碼牌在等我，我也彷彿聽到它正ㄎㄎ的奸笑著：等你很久了~~~~~~~
2009年3月17日 星期二
重返戰場
話說在歷經了些許步入「管理」層面的美好憧憬後的現在，我賴以為本的Programming、SD、SA...等的知識、技能多已生鏽、傾頹、或早已煙飛灰散了。
在這間公司，八年的職涯(癌)~~ 回首這段過程，我的心得是：
就讓想做管理的人去管理吧，也讓想寫程式的人去寫程式吧，反正，
這二種人最後都一樣會後悔！
接下來，該重返我的戰場了，但首先，我得先找到一把劍。
淺論資訊系統的分層結構
如何說服老闆採用UML
或許，先考取「OCUP/UML初級認證 」是個起頭。
在這間公司，八年的職涯(癌)~~ 回首這段過程，我的心得是：
就讓想做管理的人去管理吧，也讓想寫程式的人去寫程式吧，反正，
這二種人最後都一樣會後悔！
接下來，該重返我的戰場了，但首先，我得先找到一把劍。
淺論資訊系統的分層結構
如何說服老闆採用UML
或許，先考取「OCUP/UML初級認證 」是個起頭。
2009年3月15日 星期日
責任不能用指派的，只能讓人主動接受它
高效率的團隊往往是能夠自我管理的團隊，而且能夠充分發揮每位成員不同的專長。這樣的團隊會努力爭取挑選成員的權利，而且角色安排也很彈性，可以讓每個人選擇自己想要負責的工作。他們遵循的原則是：「責任不能用指派的；只能讓人主動接受它。」
以上節錄自「軟體工程與Microsoft Visual Studio Team System」一書。
以上節錄自「軟體工程與Microsoft Visual Studio Team System」一書。
2009年3月11日 星期三
首發~~該寫什麼ㄌㄟ~?
先想想要吃什麼午餐吧...
在中華郵政onsite的最大好處，就是這邊的美食多到不知道要怎麼選~!! 鄰永康街旁的絕佳地利，加上這邊因為有中華郵政、中華電信二大公務員集散中心~
這裡的氛圍，那種優閒的意像，著實令人嚮往。
(又離題了)~要吃什麼啊?!~
在中華郵政onsite的最大好處，就是這邊的美食多到不知道要怎麼選~!! 鄰永康街旁的絕佳地利，加上這邊因為有中華郵政、中華電信二大公務員集散中心~
這裡的氛圍，那種優閒的意像，著實令人嚮往。
(又離題了)~要吃什麼啊?!~
訂閱：
文章 (Atom)