MINOLTA投注了該公司最頂尖的開發技術與科技精華完成這台全世界最小的輕便相機，到底有什麼特殊之處?
爬原文吧~~
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的核心競爭力，否則我們的開發團隊
很可能只能持續的從勞力苦工中獲取很低很低很低的毛利，很類似台灣的代工
製造業現在面對的問題，開發團隊中沒有一些累積出可重用的元件其實是一件
很可怕的事情...
從團隊到個人也是，過去的經驗的累積(包含知識、專案、成品、元件)，會是
開發人員與其他開發人員不同之處，我知道每一個開發人員現在其實都很累，
面對專案、面對一些其他有的沒的，但是如果可以，還是建議大家，
多花一點時間在架構上，對於開發人員來說，這應該是只有好處的。
訂閱：
文章 (Atom)