程式實驗室--ProgLab

原文來自於Dr. Dobb's的 Scrum != Agile Agile是一種文化，表示組織可以在短時間內(二週)內就有個新版本給客戶端使用，並得到回饋。回饋的內容會再轉化成下一次的Agile流程。 Scrum是一種程序 XP是所有12種實作(Practices)，缺一不可

在Ubuntu 13.04版本出來後，試著在VirtualBox 4.2.x版本用虛擬機器的方式來安裝使用，沒想到安裝完後，執行起來真是超慢的。 想說是不是我的電腦太舊的，換了一台4核，Core-i5 1G獨顯，8G DDR3的NB，試了也是一樣的結果。 查了一下資料，好像是 需要安裝額外的套件，或將某些功能關閉 。可是雖然是可以快一點，但顯示上則是怪怪的，時常黑黑的一片。 看來似乎是Virtual Box的問題，好像目前仍待解決。但Virtual Box也有說明，像Ubuntu 13.04的版本看來是需要「真的GPU」而不能用模擬的。看來只能真的拿一台來安裝了，不能再用Virtual Box這種模擬器了。 不過也有人則是 改回使用原本的介面GNOME ，或這也是種方式。

有同事問到怎麼寫出來的.NET 程式放到64bit的Windows 2008 R2上執行時，怎麼還是執行成32bit模式呢? 會是因為我們都是在32bit開發及編譯造成它只能用32 bit模式執行嗎? 理論上在.NET編譯時都是預設為Any CPU的，也就是會依執行的環境來選擇是執行成32或64 bit模式。 可是不知怎麼地，VS2010在新增一個專案時，它的CPU就預設成用32bit模式。這應該也不是因為我們是在32 bit的環境下開發造成它預設選32 bit(x86)模式。因為就算我在一台64 bit的作業系統環境下建立新的專案，它還是預設選x86模式。 所以我們必須手動切換成Any CPU才行． 切換成Any CPU後編譯的可執行檔放到64 bit的環境中執行時，就會自動切換成64 bit來執行了。

在開始使用Entity Framework後，一切的ORM都是用.NET Entity Framework來自動產生的。 查詢資料庫的方式也改用了LINQ的語法。例如要查詢某資料表某欄位是否為某等定字串時，可以用如下的語法： var result = from myRow in myTable where myRow.Name == "MyFirstName" select myRow; 但神奇的是，某一天這段語法失靈了。就算資料庫中有符合條件的資料也無法被篩選出來。 如果將語法改為使用StartWith()的方式，則可以正常地找出所要的資料。 var result = from myRow in myTable where myRow.Name.StartWith("MyFirstName") select myRow; 此時開始懷疑是不是資料庫裏那個欄位的資料後面是有空白字元的。這個資料欄位一開始時是以ncahr()的方式開立的，在輸入一些資料後，因為設計上的調整，所以改為使用nvarchar()的型別。 於是就用SQL指令去查了一下資料欄位的字串長度是不是含有空白字元，使用的SQL語法如下： select Name, LEN(Name) as NameLength from myTable 由顯示的結果來看，資料欄裏字串的長度也沒錯啊，看來是沒有包含空白字元。但使用LINQ的語法就是無法用==的方式來查詢所要的資料。 後來想說去查一下SQL的 LEN() 函式的定義，看看是否有特別的部份。哇，原來函式的定義如下，是不包含尾部的空白字元的耶。那如果要查看原始字串長度要用哪個函式呢? Returns the number of characters of the specified string expression, excluding trailing blanks. 原來要查到真正的原始字串長度的話，要用 DATALENGTH() 才行。 一查之下才知道，原來原本用ncahr()改為nvarchar()後，原先輸入的字串資料還是保留了原本後面的空白字元。 如果要修改資料的話，可以用以下的SQL指令： update myName = RTRIM(my

最早最早以前，一開始接觸程式設計時，就是在用Visual C++ 5.0 + MFC寫Windows程式。所以一開始的程式變數的命名規則都是學MFC裏的命名方式，也就是所謂 匈牙利命名法 。 匈牙利命名法倒是也沒什麼問題，我想他的起源應該是因為以前的C編譯器是不支援在編譯時檢查參數型別的，所以特別要在變數的前面加上型別的資訊，以便程式設計人員可以在編寫程式碼的時候就能夠有機會在第一時間查覺出所引用的變數型別上有出入，而不用等到程式真正編譯好執行時才發現錯誤。 而目前的程式語言及編譯器都已經能在編譯程式碼時就幫忙檢查引用的參數型別了，於是這種命名方式隨著時代的演進，應該是可以不用採用這種方式來命名了才對。 就開發程式設段時間以來，目前最常用到的就是兩種命名方式，一種是Pascal Case，另一種是Camel Case。 Pascal Case 變數的命名首字母是大寫，後續單字的第一個字母也都是大寫，例如TestSample。 Camel Case 有分成兩種，一種是Upper Camel Case，基本上就跟Pascal Case一樣。另一種是Lower Camel Case，變數的首字母是小寫，後續單字的第一個字母則都是大寫。例如testSample。 基本上這樣的方式也沒有誰好誰壞，只要有個規則，大家一致就好。 不過個人認為，如果是無型別檢查的環境下，變數的名稱(或一些需要命名的名稱)我習慣會加上型別的資訊。 例如在使用資料庫時，要為資料表及檢視表命名時，習慣上會加上tbl及vw的字首。用來識別這是資料表還是檢視表。 因為有些語法在檢視表上應該是不適用的，例如INSERT、UPDATE、DELETE這類的語法。檢視表只適合用來下SELECT的查詢語法。為了在使用時就能識別出是資料表或檢視表，個人覺得還是加上識別字比較好。 在C#或C++中我們可以宣告一個列舉，例如： public enum ServerStatusEnum { READY, IDLE } 在使用這種列舉型別來定義變數時，就可以： public ServerStatusEnum ServerStatus = ServerStatusEnum.IDLE; 因為我們想要的就是定義一個Server的Status，所以變數名稱當