做報告都少不了PowerPoint這套簡報軟體，雖然它本身有內建一些簡報的背景範本，但樣式不多，很容易與其他同學或同事用到一樣的ppt簡報背景，找了幾個不錯的PowerPoint 背景免費下載站：
1. http://office.microsoft.com/en-us/templates/CT101172721033.aspx
2. http://www.brainybetty.com/
3. http://www.presentationhelper.co.uk/free_powerpoint_template.htm
4. http://www.presentationpoint.com/powerpoint-templates/index.htm
5. http://inzones.com/free-templates.htm
6. http://www.indezine.com/powerpoint/templates/freetemplates.html
7. http://www.presentersresource.com/
8. http://jc-schools.net/tutorials/PPT-games/
9. http://www.mastertemplates.com/powerpoint-templates.htm
10. http://www.ebibleteacher.com/backgrnd.html
11. http://www.templateswise.com/
12. http://www.freeppttemplates.com/
2010年8月18日 星期三
2010年7月29日 星期四
CANON 對焦系統
對焦sensor是兩兩成對 也就說兩個senser組成一個對焦單元
sensor排列方式有水平 有垂直排列
水平排列的sensor 對物體是垂直線最敏感 對物體是水平線會無法對焦
同理 垂直排列的sensor 對物體是水平線最敏感 對物體是垂直線會無法對焦
十字型就是有兩對(4個) sensor 分別是水平排列及垂直排列 所以不管物體是水平線 或垂直線都會有相對應的對焦sensor可以感應對焦 對焦成功機率相對提高
對焦精度不同於以上的概念 canon 對於對焦精度區分成兩種
一種是一般精度 另一種是高精度
一般精度 :只要主體影像落在景深內就算對焦完成
高精度:需要落在1/3 景深內才算對焦成功
所以高精準度的那一對sensor 與一般精準度的sensor不一樣 ,需要更多的光線才能發揮作用, 這需鏡頭支援, 也就是需要大光圈的鏡頭, 需要F2.8以上(含),例如 24-70mm F2.8,135mm F2.0 ,50mm F1.4 , 85mm F1.2
一般精準度sensor 對焦時對光量需求沒有那麼高 所以F5.6以上的鏡頭都可以對焦,幾乎所有原廠鏡頭都包含
如果最大光圈是 F8的鏡頭會發生什麼事 ? 有可能無法自動對焦 這種情形只好改為手動對焦 以上報告
註:對焦時鏡頭光圈都是全開的 直到按下快門時才會縮到設定的光圈
強者解說請參考
那我的20D~~~看來都是一字的吧(淚)~~
sensor排列方式有水平 有垂直排列
水平排列的sensor 對物體是垂直線最敏感 對物體是水平線會無法對焦
同理 垂直排列的sensor 對物體是水平線最敏感 對物體是垂直線會無法對焦
十字型就是有兩對(4個) sensor 分別是水平排列及垂直排列 所以不管物體是水平線 或垂直線都會有相對應的對焦sensor可以感應對焦 對焦成功機率相對提高
對焦精度不同於以上的概念 canon 對於對焦精度區分成兩種
一種是一般精度 另一種是高精度
一般精度 :只要主體影像落在景深內就算對焦完成
高精度:需要落在1/3 景深內才算對焦成功
所以高精準度的那一對sensor 與一般精準度的sensor不一樣 ,需要更多的光線才能發揮作用, 這需鏡頭支援, 也就是需要大光圈的鏡頭, 需要F2.8以上(含),例如 24-70mm F2.8,135mm F2.0 ,50mm F1.4 , 85mm F1.2
一般精準度sensor 對焦時對光量需求沒有那麼高 所以F5.6以上的鏡頭都可以對焦,幾乎所有原廠鏡頭都包含
如果最大光圈是 F8的鏡頭會發生什麼事 ? 有可能無法自動對焦 這種情形只好改為手動對焦 以上報告
註:對焦時鏡頭光圈都是全開的 直到按下快門時才會縮到設定的光圈
強者解說請參考
那我的20D~~~看來都是一字的吧(淚)~~
2010年7月16日 星期五
我在盯者你~ YN-468閃燈
跟Allen兄商借神燈580EX，自此終於了解：好鏡可以緩緩，閃燈不能不敗的道理。
近來M01火紅的永諾YN閃燈，參考文章：
[分享]超平(便宜)燈 永諾YN-460
閃光指數直逼原廠神燈--超值外閃 永諾YN-460 II
[開箱]便宜手動閃燈 永諾YN-460 II
永諾Yongnuo YN467 PK 原廠神燈Canon 550EX
YN-468 永諾閃燈開箱
嗯～$2950連三位小朋友都不用的價錢，可以弄一之回來玩玩了。
永諾閃燈比較如下：
好用、取代檔案總管免費、免安裝工具：MDIE
免費好用又不用安裝~ 想不到為何不裝來用用~~~
原文請參 http://playpcesor.blogspot.com/2007/06/mdie.html
下載網址 http://www.badongo.com/file/8273387
試了一下，馬上幫我舒緩工具列爆炸的情況，
原本每每都得維持開啟 4~5個以上的檔案總管數量。
右鍵拖曳可直接上層、下層目錄，可上一頁、下一頁~~有驚豔到！
(這些M$都沒想到？)
原文請參 http://playpcesor.blogspot.com/2007/06/mdie.html
下載網址 http://www.badongo.com/file/8273387
試了一下，馬上幫我舒緩工具列爆炸的情況，
原本每每都得維持開啟 4~5個以上的檔案總管數量。
右鍵拖曳可直接上層、下層目錄，可上一頁、下一頁~~有驚豔到！
(這些M$都沒想到？)
2010年7月15日 星期四
調校SQL效能
好久沒搞SQL資料庫了，這篇文章蠻受用，為免消失，轉載於此。
(原文轉載自 http://www.wretch.cc/blog/hcu16b/10264132 )
有些程式員在撰寫前端的應用程式時，會透過各種 OOP 語言將存取資料庫的 SQL 陳述式串接起來，卻忽略了 SQL 語法的效能問題。版工曾聽過某半導體大廠的新進程式員，所兜出來的一段 PL/SQL 跑了好幾分鐘還跑不完；想當然爾，即使他前端的 AJAX 用得再漂亮，程式效能頂多也只是差強人意而已。以下是版工整理出的一些簡單心得，讓長年鑽究 ASP.NET / JSP / AJAX 等前端應用程式，卻無暇研究 SQL 語法的程式員，避免踩到一些 SQL 的效能地雷。
1、資料庫設計與規劃
‧ Primary Key 欄位的長度儘量小，能用 small integer 就不要用 integer。例如員工資料表，若能用員工編號當主鍵，就不要用身分證字號。
‧ 一般欄位亦同。若該資料表要存放的資料不會超過 3 萬筆，用 small integer 即可，不必用 integer。
‧ 文字資料欄位若長度固定，如：身分證字號，就不要用 varchar 或 nvarchar，應該用 char 或 nchar。
‧ 文字資料欄位若長度不固定，如：地址，則應該用 varchar 或 nvarchar。除了可節省儲存空間外，存取磁碟時也會較有效率。
‧ 設計欄位時，若其值可有可無，最好也給一個預設值，並設成「不允許 NULL」(一般欄位預設為「允許 NULL」)。因為 SQL Server 在存放和查詢有 NULL 的資料表時，會花費額外的運算動作 [2]。
‧ 若一個資料表的欄位過多，應垂直切割成兩個以上的資料表，並用同名的 Primary Key 一對多連結起來，如：Northwind 的 Orders、Order Details 資料表。以避免在存取資料時，以叢集索引掃描時會載入過多的資料，或修改資料時造成互相鎖定或鎖定過久。
------------------------------
2、適當地建立索引
‧ 記得自行幫 Foreign Key 欄位建立索引，即使是很少被 JOIN 的資料表亦然。
‧ 替常被查詢或排序的欄位建立索引，如：常被當作 WHERE 子句條件的欄位。
‧ 用來建立索引的欄位，長度不宜過長，不要用超過 20 個位元組的欄位，如：地址。
‧ 不要替內容重複性高的欄位建立索引，如：性別；反之，若重複性低的欄位則適合建立索引，如：姓名。
‧ 不要替使用率低的欄位建立索引。
‧ 不宜替過多欄位建立索引，否則反而會影響到新增、修改、刪除的效能，尤其是以線上交易 (OLTP) 為主的網站資料庫。
‧ 若資料表存放的資料很少，就不必刻意建立索引。否則可能資料庫沿著索引樹狀結構去搜尋索引中的資料，反而比掃描整個資料表還慢。
‧ 若查詢時符合條件的資料很多，則透過「非叢集索引」搜尋的效能，可能反而不如整個資料表逐筆掃描。
‧ 建立「叢集索引」的欄位選擇至為重要，會影響到整個索引結構的效能。要用來建立「叢集索引」的欄位，務必選擇「整數」型別 (鍵值會較小)、唯一、不可為 NULL。
------------------------------
3、適當地使用索引
‧ 有些書籍會提到，使用 LIKE、% 做模糊查詢時，即使您已替某個欄位建立索引 (如下方例子的 CustomerID)，但以常數字元開頭才會使用到索引，若以萬用字元 (%) 開頭則不會使用索引，如下所示：
USE Northwind;
GO
SELECT * FROM Orders WHERE CustomerID LIKE 'D%'; --使用索引
SELECT * FROM Orders WHERE CustomerID LIKE '%D'; --不使用索引
執行完成後按 Ctrl+L，可檢閱如下圖的「執行計畫」。
圖 1 可看出「查詢最佳化程式」有使用到索引做搜尋
圖 2 在此的叢集索引掃描，並未直接使用索引，效能上幾乎只等於掃描整個資料表
但經版工反覆測試，這種語法是否會使用到索引，抑或會逐筆掃描，並非絕對的。仍要看所下的查詢關鍵字，以及欄位內儲存的資料內容而定。但對於儲存資料筆數龐大的資料表，最好還是少用 LIKE 做模糊查詢。
‧ 以下的運算子會造成「負向查詢」，常會讓「查詢最佳化程式」無法有效地使用索引，最好能用其他運算子和語法改寫 (經版工測試，並非有負向運算子，就絕對無法使用索引)：
NOT 、 != 、 <> 、 !> 、 !< 、 NOT EXISTS 、 NOT IN 、 NOT LIKE
‧ 避免讓 WHERE 子句中的欄位，去做字串串接或數字運算，否則可能導致「查詢最佳化程式」無法直接使用索引，而改採叢集索引掃描 (經版工測試並非絕對)。
‧ 資料表中的資料，會依照「叢集索引」欄位的順序存放，因此當您下 BETWEEN、GROUP BY、ORDER BY 時若有包含「叢集索引」欄位，由於資料已在資料表中排序好，因此可提升查詢速度。
‧ 若使用「複合索引」，要注意索引順序上的第一個欄位，才適合當作過濾條件。
------------------------------
4、避免在 WHERE 子句中對欄位使用函數
對欄位使用函數，也等於對欄位做運算或串接的動作，一樣可能會讓「查詢最佳化程式」無法有效地使用索引。但真正對效能影響最重大的，是當您的資料表內若有 10 萬筆資料，則在查詢時就需要呼叫函數 10 萬次，這點才是真正的效能殺手。程式員應注意，在系統開發初期可能感覺不出差異，但當系統上線且資料持續累積後，這些語法細節所造成的效能問題就會逐步浮現。
SELECT * FROM Orders WHERE DATEPART(yyyy, OrderDate) = 1996 AND DATEPART(mm, OrderDate)=7
可改成
SELECT * FROM Orders WHERE OrderDate BETWEEN '19960701' AND '19960731'
SELECT * FROM Orders WHERE SUBSTRING(CustomerID, 1, 1) = 'D'
可改成
SELECT * FROM Orders WHERE CustomerID LIKE 'D%'
注意當您在下 UPDATE、DELETE 陳述式時，若有採用 WHERE 子句，也應符合上述原則。
------------------------------
5、AND 與 OR 的使用
在 AND 運算中，「只要有一個」條件有用到索引 (如下方的 CustomerID)，即可大幅提升查詢速度，如下圖 3 所示：
SELECT * FROM Orders WHERE CustomerID='VINET' AND Freight=32.3800 --使用索引，會出現下圖 3 的畫面
SELECT * FROM Orders WHERE Freight=32.3800 --不使用索引，會出現上圖 2 的畫面
圖 3
但在 OR 運算中，則要「所有的」條件都有可用的索引，才能使用索引來提升查詢速度。因此 OR 運算子的使用必須特別小心。
若您將上方 AND 的範例，邏輯運算子改成 OR 的話，如下所示：
SELECT * FROM Orders WHERE CustomerID='VINET' OR Freight=32.3800
由於無法有效地使用索引，也會出現圖 2 的畫面。
在使用 OR 運算子時，只要有一個條件 (欄位) 沒有可用的索引，則其他所有的條件 (欄位) 都有索引也沒用，只能如圖 2 般，把整個資料表或整個叢集索引都掃描過，以逐筆比對是否有符合條件的資料。
據網路上文件的說法 [1]，上述的 OR 運算陳述式，我們還可用 UNION 聯集適當地改善，如下：
SELECT * FROM Orders WHERE CustomerID='VINET'
UNION
SELECT * FROM Orders WHERE Freight=32.3800
此時您再按 Ctrl+L 檢閱「執行計畫」，會發現上半段的查詢會使用索引，但下半段仍用叢集索引掃描，對效能不無小補。
------------------------------
6、適當地使用子查詢
相較於「子查詢 (Subquery)」，若能用 JOIN 完成的查詢，一般會比較建議使用後者。原因除了 JOIN 的語法較容易理解外，在多數的情況下，JOIN 的效能也會比子查詢較佳；但這並非絕對，也有的情況可能剛好相反。
我們知道子查詢可分為「獨立子查詢」和「關聯子查詢」兩種，前者指子查詢的內容可單獨執行，後者則無法單獨執行，亦即外層查詢的「每一次」查詢動作都需要引用內層查詢的資料，或內層查詢的「每一次」查詢動作都需要參考外層查詢的資料。
以下我們看一個比較極端的例子 [2]。若我們希望所有查詢出來的資料，都能另外給一個自動編號，版工我在之前的文章「用 SQL Server 2005 新增的 ROW_NUMBER 函數撰寫 GridView 分頁」中有介紹過，可用 SQL Server 2005 中新增的 ROW_NUMBER 函數輕易地達成，且 ROW_NUMBER 函數還能再加上「分群 (PARTITION BY)」等功能，而且執行效能極佳。
圖 4 將 Orders 資料表的 830 筆資料都撈出來，並在右側給一組自動編號
現在我們要如上圖 4 般，將 Northwind 中 Orders 資料表的 830 筆資料都撈出來，並自動給一組編號，若用 ROW_NUMBER 函數的寫法如下所示，而且效能極佳，只要 2 ms (毫秒)，亦即千分之二秒。
SET STATISTICS TIME ON
SELECT OrderID, ROW_NUMBER() OVER(ORDER BY OrderID) AS 編號
FROM dbo.Orders
但如果是在舊版的 SQL Server 2000 中，我們可能得用以下的「子查詢」寫法：
SET STATISTICS TIME ON
SELECT OrderID,
(SELECT COUNT(*) FROM dbo.Orders AS 內圈
WHERE 內圈.OrderID <= 外圈.OrderID) AS 編號
FROM dbo.Orders AS 外圈
ORDER BY 編號
但這種舊寫法，會像先前所提到的，外層查詢的「每一次」查詢動作都需要引用內層查詢的資料。以上方例子而言，外層查詢的每一筆資料，都要等內層查詢「掃描整個資料表」並作比對和計數，因此 830 筆資料每一筆都要重複掃描整個資料表 830 次，所耗用的時間也因此爆增至 170 ms。
若您用相同的寫法，去查詢 AdventureWorks 資料庫中，有 31,465 筆資料的 Sales.SalesOrderHeader 資料表，用 ROW_NUMBER 函數要 677 ms，還不到 1 秒鐘；但用子查詢的話，居然要高達 225,735 ms，將近快 4 分鐘的時間。
雖然這是較極端的範例，但由此可知子查詢的撰寫，在使用上不可不慎，尤其是「關聯子查詢」。程式員在程式開發初期、資料量還很少時感受不到此種 SQL 語法的重大陷阱；但等到系統上線幾個月或一兩年後，可能就會有反應遲緩的現象。
------------------------------
7、其他查詢技巧
‧ DISTINCT、ORDER BY 語法，會讓資料庫做額外的計算。此外聯集的使用，若沒有要剔除重複資料的需求，使用 UNION ALL 會比 UNION 更佳，因為後者會加入類似 DISTINCT 的演算法。
‧ 在 SQL Server 2005 版本中，存取資料庫物件時，最好明確指定該物件的「結構描述 (Schema)」，也就是使用兩節式名稱。否則若呼叫者的預設 Schema 不是 dbo，則 SQL Server 在執行時，會先尋找該使用者預設 Schema 所搭配的物件，找不到的話才會轉而使用預設的 dbo，會多耗費尋找的時間。例如若要執行一個叫做 dbo.mySP1 的 Stored Procedure，應使用以下的兩節式名稱：
EXEC dbo.mySP1
------------------------------
8、儘可能用 Stored Procedure 取代前端應用程式直接存取資料表
Stored Procedure 除了經過事先編譯、效能較好以外，亦可節省 SQL 陳述式傳遞的頻寬，也方便商業邏輯的重複使用。再搭配自訂函數和 View 的使用，將來若要修改資料表結構、重新切割或反正規化時亦較方便。
------------------------------
9、儘可能在資料來源層，就先過濾資料
使用 SELECT 語法時，儘量避免傳回所有的資料至前端而不設定 WHERE 等過濾條件。雖然 ASP.NET 中 SqlDataSource、ObjectDataSource 控制項的 FilterExpression 可再做篩選，GridView 控制項的 SortExpression 可再做排序，但會多消耗掉資料庫的系統資源、Web server 的記憶體和網路頻寬。最好還是在資料庫和資料來源層，就先用 SQL 條件式篩選出所要的資料。
------------------------------
結論：
本文的觀念，不管是寫 SQL statement、Stored Procedure、自訂函數或 View 皆然。本文只是挑出程式員較容易犯的 SQL 語法效能問題，以期能在短時間瀏覽過本文後，在寫 ADO.NET 程式時能修正以往隨興的 SQL 撰寫習慣。文中提到的幾點，只不過是 SQL 語法效能議題的入門篇。後續有時間的話，版工會再補充在本帖的回應留言，或另開新主題。
(原文轉載自 http://www.wretch.cc/blog/hcu16b/10264132 )
有些程式員在撰寫前端的應用程式時，會透過各種 OOP 語言將存取資料庫的 SQL 陳述式串接起來，卻忽略了 SQL 語法的效能問題。版工曾聽過某半導體大廠的新進程式員，所兜出來的一段 PL/SQL 跑了好幾分鐘還跑不完；想當然爾，即使他前端的 AJAX 用得再漂亮，程式效能頂多也只是差強人意而已。以下是版工整理出的一些簡單心得，讓長年鑽究 ASP.NET / JSP / AJAX 等前端應用程式，卻無暇研究 SQL 語法的程式員，避免踩到一些 SQL 的效能地雷。
1、資料庫設計與規劃
‧ Primary Key 欄位的長度儘量小，能用 small integer 就不要用 integer。例如員工資料表，若能用員工編號當主鍵，就不要用身分證字號。
‧ 一般欄位亦同。若該資料表要存放的資料不會超過 3 萬筆，用 small integer 即可，不必用 integer。
‧ 文字資料欄位若長度固定，如：身分證字號，就不要用 varchar 或 nvarchar，應該用 char 或 nchar。
‧ 文字資料欄位若長度不固定，如：地址，則應該用 varchar 或 nvarchar。除了可節省儲存空間外，存取磁碟時也會較有效率。
‧ 設計欄位時，若其值可有可無，最好也給一個預設值，並設成「不允許 NULL」(一般欄位預設為「允許 NULL」)。因為 SQL Server 在存放和查詢有 NULL 的資料表時，會花費額外的運算動作 [2]。
‧ 若一個資料表的欄位過多，應垂直切割成兩個以上的資料表，並用同名的 Primary Key 一對多連結起來，如：Northwind 的 Orders、Order Details 資料表。以避免在存取資料時，以叢集索引掃描時會載入過多的資料，或修改資料時造成互相鎖定或鎖定過久。
------------------------------
2、適當地建立索引
‧ 記得自行幫 Foreign Key 欄位建立索引，即使是很少被 JOIN 的資料表亦然。
‧ 替常被查詢或排序的欄位建立索引，如：常被當作 WHERE 子句條件的欄位。
‧ 用來建立索引的欄位，長度不宜過長，不要用超過 20 個位元組的欄位，如：地址。
‧ 不要替內容重複性高的欄位建立索引，如：性別；反之，若重複性低的欄位則適合建立索引，如：姓名。
‧ 不要替使用率低的欄位建立索引。
‧ 不宜替過多欄位建立索引，否則反而會影響到新增、修改、刪除的效能，尤其是以線上交易 (OLTP) 為主的網站資料庫。
‧ 若資料表存放的資料很少，就不必刻意建立索引。否則可能資料庫沿著索引樹狀結構去搜尋索引中的資料，反而比掃描整個資料表還慢。
‧ 若查詢時符合條件的資料很多，則透過「非叢集索引」搜尋的效能，可能反而不如整個資料表逐筆掃描。
‧ 建立「叢集索引」的欄位選擇至為重要，會影響到整個索引結構的效能。要用來建立「叢集索引」的欄位，務必選擇「整數」型別 (鍵值會較小)、唯一、不可為 NULL。
------------------------------
3、適當地使用索引
‧ 有些書籍會提到，使用 LIKE、% 做模糊查詢時，即使您已替某個欄位建立索引 (如下方例子的 CustomerID)，但以常數字元開頭才會使用到索引，若以萬用字元 (%) 開頭則不會使用索引，如下所示：
USE Northwind;
GO
SELECT * FROM Orders WHERE CustomerID LIKE 'D%'; --使用索引
SELECT * FROM Orders WHERE CustomerID LIKE '%D'; --不使用索引
執行完成後按 Ctrl+L，可檢閱如下圖的「執行計畫」。
圖 1 可看出「查詢最佳化程式」有使用到索引做搜尋
圖 2 在此的叢集索引掃描，並未直接使用索引，效能上幾乎只等於掃描整個資料表
但經版工反覆測試，這種語法是否會使用到索引，抑或會逐筆掃描，並非絕對的。仍要看所下的查詢關鍵字，以及欄位內儲存的資料內容而定。但對於儲存資料筆數龐大的資料表，最好還是少用 LIKE 做模糊查詢。
‧ 以下的運算子會造成「負向查詢」，常會讓「查詢最佳化程式」無法有效地使用索引，最好能用其他運算子和語法改寫 (經版工測試，並非有負向運算子，就絕對無法使用索引)：
NOT 、 != 、 <> 、 !> 、 !< 、 NOT EXISTS 、 NOT IN 、 NOT LIKE
‧ 避免讓 WHERE 子句中的欄位，去做字串串接或數字運算，否則可能導致「查詢最佳化程式」無法直接使用索引，而改採叢集索引掃描 (經版工測試並非絕對)。
‧ 資料表中的資料，會依照「叢集索引」欄位的順序存放，因此當您下 BETWEEN、GROUP BY、ORDER BY 時若有包含「叢集索引」欄位，由於資料已在資料表中排序好，因此可提升查詢速度。
‧ 若使用「複合索引」，要注意索引順序上的第一個欄位，才適合當作過濾條件。
------------------------------
4、避免在 WHERE 子句中對欄位使用函數
對欄位使用函數，也等於對欄位做運算或串接的動作，一樣可能會讓「查詢最佳化程式」無法有效地使用索引。但真正對效能影響最重大的，是當您的資料表內若有 10 萬筆資料，則在查詢時就需要呼叫函數 10 萬次，這點才是真正的效能殺手。程式員應注意，在系統開發初期可能感覺不出差異，但當系統上線且資料持續累積後，這些語法細節所造成的效能問題就會逐步浮現。
SELECT * FROM Orders WHERE DATEPART(yyyy, OrderDate) = 1996 AND DATEPART(mm, OrderDate)=7
可改成
SELECT * FROM Orders WHERE OrderDate BETWEEN '19960701' AND '19960731'
SELECT * FROM Orders WHERE SUBSTRING(CustomerID, 1, 1) = 'D'
可改成
SELECT * FROM Orders WHERE CustomerID LIKE 'D%'
注意當您在下 UPDATE、DELETE 陳述式時，若有採用 WHERE 子句，也應符合上述原則。
------------------------------
5、AND 與 OR 的使用
在 AND 運算中，「只要有一個」條件有用到索引 (如下方的 CustomerID)，即可大幅提升查詢速度，如下圖 3 所示：
SELECT * FROM Orders WHERE CustomerID='VINET' AND Freight=32.3800 --使用索引，會出現下圖 3 的畫面
SELECT * FROM Orders WHERE Freight=32.3800 --不使用索引，會出現上圖 2 的畫面
圖 3
但在 OR 運算中，則要「所有的」條件都有可用的索引，才能使用索引來提升查詢速度。因此 OR 運算子的使用必須特別小心。
若您將上方 AND 的範例，邏輯運算子改成 OR 的話，如下所示：
SELECT * FROM Orders WHERE CustomerID='VINET' OR Freight=32.3800
由於無法有效地使用索引，也會出現圖 2 的畫面。
在使用 OR 運算子時，只要有一個條件 (欄位) 沒有可用的索引，則其他所有的條件 (欄位) 都有索引也沒用，只能如圖 2 般，把整個資料表或整個叢集索引都掃描過，以逐筆比對是否有符合條件的資料。
據網路上文件的說法 [1]，上述的 OR 運算陳述式，我們還可用 UNION 聯集適當地改善，如下：
SELECT * FROM Orders WHERE CustomerID='VINET'
UNION
SELECT * FROM Orders WHERE Freight=32.3800
此時您再按 Ctrl+L 檢閱「執行計畫」，會發現上半段的查詢會使用索引，但下半段仍用叢集索引掃描，對效能不無小補。
------------------------------
6、適當地使用子查詢
相較於「子查詢 (Subquery)」，若能用 JOIN 完成的查詢，一般會比較建議使用後者。原因除了 JOIN 的語法較容易理解外，在多數的情況下，JOIN 的效能也會比子查詢較佳；但這並非絕對，也有的情況可能剛好相反。
我們知道子查詢可分為「獨立子查詢」和「關聯子查詢」兩種，前者指子查詢的內容可單獨執行，後者則無法單獨執行，亦即外層查詢的「每一次」查詢動作都需要引用內層查詢的資料，或內層查詢的「每一次」查詢動作都需要參考外層查詢的資料。
以下我們看一個比較極端的例子 [2]。若我們希望所有查詢出來的資料，都能另外給一個自動編號，版工我在之前的文章「用 SQL Server 2005 新增的 ROW_NUMBER 函數撰寫 GridView 分頁」中有介紹過，可用 SQL Server 2005 中新增的 ROW_NUMBER 函數輕易地達成，且 ROW_NUMBER 函數還能再加上「分群 (PARTITION BY)」等功能，而且執行效能極佳。
圖 4 將 Orders 資料表的 830 筆資料都撈出來，並在右側給一組自動編號
現在我們要如上圖 4 般，將 Northwind 中 Orders 資料表的 830 筆資料都撈出來，並自動給一組編號，若用 ROW_NUMBER 函數的寫法如下所示，而且效能極佳，只要 2 ms (毫秒)，亦即千分之二秒。
SET STATISTICS TIME ON
SELECT OrderID, ROW_NUMBER() OVER(ORDER BY OrderID) AS 編號
FROM dbo.Orders
但如果是在舊版的 SQL Server 2000 中，我們可能得用以下的「子查詢」寫法：
SET STATISTICS TIME ON
SELECT OrderID,
(SELECT COUNT(*) FROM dbo.Orders AS 內圈
WHERE 內圈.OrderID <= 外圈.OrderID) AS 編號
FROM dbo.Orders AS 外圈
ORDER BY 編號
但這種舊寫法，會像先前所提到的，外層查詢的「每一次」查詢動作都需要引用內層查詢的資料。以上方例子而言，外層查詢的每一筆資料，都要等內層查詢「掃描整個資料表」並作比對和計數，因此 830 筆資料每一筆都要重複掃描整個資料表 830 次，所耗用的時間也因此爆增至 170 ms。
若您用相同的寫法，去查詢 AdventureWorks 資料庫中，有 31,465 筆資料的 Sales.SalesOrderHeader 資料表，用 ROW_NUMBER 函數要 677 ms，還不到 1 秒鐘；但用子查詢的話，居然要高達 225,735 ms，將近快 4 分鐘的時間。
雖然這是較極端的範例，但由此可知子查詢的撰寫，在使用上不可不慎，尤其是「關聯子查詢」。程式員在程式開發初期、資料量還很少時感受不到此種 SQL 語法的重大陷阱；但等到系統上線幾個月或一兩年後，可能就會有反應遲緩的現象。
------------------------------
7、其他查詢技巧
‧ DISTINCT、ORDER BY 語法，會讓資料庫做額外的計算。此外聯集的使用，若沒有要剔除重複資料的需求，使用 UNION ALL 會比 UNION 更佳，因為後者會加入類似 DISTINCT 的演算法。
‧ 在 SQL Server 2005 版本中，存取資料庫物件時，最好明確指定該物件的「結構描述 (Schema)」，也就是使用兩節式名稱。否則若呼叫者的預設 Schema 不是 dbo，則 SQL Server 在執行時，會先尋找該使用者預設 Schema 所搭配的物件，找不到的話才會轉而使用預設的 dbo，會多耗費尋找的時間。例如若要執行一個叫做 dbo.mySP1 的 Stored Procedure，應使用以下的兩節式名稱：
EXEC dbo.mySP1
------------------------------
8、儘可能用 Stored Procedure 取代前端應用程式直接存取資料表
Stored Procedure 除了經過事先編譯、效能較好以外，亦可節省 SQL 陳述式傳遞的頻寬，也方便商業邏輯的重複使用。再搭配自訂函數和 View 的使用，將來若要修改資料表結構、重新切割或反正規化時亦較方便。
------------------------------
9、儘可能在資料來源層，就先過濾資料
使用 SELECT 語法時，儘量避免傳回所有的資料至前端而不設定 WHERE 等過濾條件。雖然 ASP.NET 中 SqlDataSource、ObjectDataSource 控制項的 FilterExpression 可再做篩選，GridView 控制項的 SortExpression 可再做排序，但會多消耗掉資料庫的系統資源、Web server 的記憶體和網路頻寬。最好還是在資料庫和資料來源層，就先用 SQL 條件式篩選出所要的資料。
------------------------------
結論：
本文的觀念，不管是寫 SQL statement、Stored Procedure、自訂函數或 View 皆然。本文只是挑出程式員較容易犯的 SQL 語法效能問題，以期能在短時間瀏覽過本文後，在寫 ADO.NET 程式時能修正以往隨興的 SQL 撰寫習慣。文中提到的幾點，只不過是 SQL 語法效能議題的入門篇。後續有時間的話，版工會再補充在本帖的回應留言，或另開新主題。
2010年7月6日 星期二
2010年5月11日 星期二
最佳化 Visual Studio 2008 執行速度
(感謝Allen分享)
●關閉起始頁
工具 -> 選項 環境 -> 啟動，改變 啟動時 的屬性為 顯示空白環境
●關閉歡迎畫面
在 Microsoft Visual Studio 2008 的捷徑上按滑鼠右鍵，選 內容
在 目標 的最後，加上參數 /nosplash
●關閉動畫
工具 -> 選項 -> 環境，把 動畫環境工具 取消
●關閉追蹤修訂
工具 -> 選項 -> 文字編輯器 追蹤修訂 取消
●關閉 ToolboxPopulate
工具 -> 選項 -> Windows Form 設計 -> 工具箱，把 Auto ToolboxPopulate 設定為 False
將專案建置的元件自動加入工具箱的功能關閉
剛剛按照網頁上的說明，將設定一一改變，果真啟動 Visual Studio 2008 快了許多！
●關閉起始頁
工具 -> 選項 環境 -> 啟動，改變 啟動時 的屬性為 顯示空白環境
●關閉歡迎畫面
在 Microsoft Visual Studio 2008 的捷徑上按滑鼠右鍵，選 內容
在 目標 的最後，加上參數 /nosplash
●關閉動畫
工具 -> 選項 -> 環境，把 動畫環境工具 取消
●關閉追蹤修訂
工具 -> 選項 -> 文字編輯器 追蹤修訂 取消
●關閉 ToolboxPopulate
工具 -> 選項 -> Windows Form 設計 -> 工具箱，把 Auto ToolboxPopulate 設定為 False
將專案建置的元件自動加入工具箱的功能關閉
剛剛按照網頁上的說明，將設定一一改變，果真啟動 Visual Studio 2008 快了許多！
VM 參考資料
感謝Tyler 2月分享：
這裡簡單找了一些vm的資料供大家參考目前VM主機是安裝VMware Server 1.0(free)
最新版是2.0(free)，且支援64bit guest os
有一種說法是Microsft Hyper-V的效能比VMWare Server好，不曉得真實性如何
而且灌Windows Server 2008是免不了的
另外市面上效能最佳的vm應該是VMware ESX，但對週邊的支援差，現在也有免費精簡版叫VMware ESXi 它比較特別的是不需安裝作業系統，因此guest os非常的原生(所謂的半虛擬化)，所以效能會很好
VMWare Server 2.0
https://www.vmware.com/products/server/overview.html
Microsoft Hyper-V Server
http://www.microsoft.com/hyper-v-server/en/us/default.aspx
VMware ESXi導入
http://applepig.idv.tw/archives/919
效能比較(2007年的資料)
http://blog.nonestyle.net/2007/03/vmware-virtual-pc-parallels-virtualbox.html
VMware ESX/ESXi/Server效能比較
http://www.vixual.net/blog/archives/543
虛擬機之家
http://www.xuniji.com/
2010年3月1日 星期一
錄音好物 - OLYMPUS WS-500M
幾年前MP3正夯時，曾因需要錄音並能當MP3隨身聽買了1G的產品，但錄音效果實在差強人意，而且一年前它也早壽終正寢。
近日因為上課需要錄音，上網survey了一下錄音筆，竟發現有人談到～見 懇請大大推薦錄音筆 一文，另外，[開箱] OLYMPUS WS-500M 也值得一讀，搭配下載韌體更新，可直接錄製MP3。
沒想到這好物只能從美國代購取得，從沒天頂的拍賣場花了 $3050大洋還直奔五股自取(還迷路繞到泰山去了...)；
今天上課錄製的心得是~好得不得了啊，上了9小時的課，用掉1顆AAA (4號)電池，還不錯哩，音樂MP3聽起來的效果也很讚，有SRS也可以設BASS，按鍵配置蠻順手的，不用看書明書也能馬上上手，還有SLOW、FAST語言學習功能，都是很實用的功能，唯一可以挑剔的，應該就是美感的問題了，塑膠味頗重，果然是美國老粗的style（跟SONY日本美型派的真差得遠），但對我而言，無損對它的讚賞。
近日因為上課需要錄音，上網survey了一下錄音筆，竟發現有人談到～見 懇請大大推薦錄音筆 一文，另外，[開箱] OLYMPUS WS-500M 也值得一讀，搭配下載韌體更新，可直接錄製MP3。
沒想到這好物只能從美國代購取得，從沒天頂的拍賣場花了 $3050大洋還直奔五股自取(還迷路繞到泰山去了...)；今天上課錄製的心得是~好得不得了啊，上了9小時的課，用掉1顆AAA (4號)電池，還不錯哩，音樂MP3聽起來的效果也很讚，有SRS也可以設BASS，按鍵配置蠻順手的，不用看書明書也能馬上上手，還有SLOW、FAST語言學習功能，都是很實用的功能，唯一可以挑剔的，應該就是美感的問題了，塑膠味頗重，果然是美國老粗的style（跟SONY日本美型派的真差得遠），但對我而言，無損對它的讚賞。
2010年1月11日 星期一
2010年1月4日 星期一
2009年12月19日 星期六
CANON EOS 20D 參數與 DPP 最適調整
蒐集網上分享~
對 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終於是適合人看得了~~
對 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月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 上的相片)
訂閱：
文章 (Atom)