程式實驗室--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，所以變數名稱當...

開始覺得DOS的批次檔指令真是高深莫測了。 最近想完成個小需求就是要寫一個DOS Batch指令檔，去Linux主機上用FTP模式下載一些檔案下來。 這些檔案的檔名都是以日期編名的，如果是用西元年，那倒也還容易。可是這次的檔名卻是用中華民國的年份。@@ 好吧，西元年算到中華民國年份，充其量用個減法減去1911年就可以得到了。但在DOS的批次檔中要如何寫啊? 首先要取得西元年的日期 在Dos命令列視窗中輸入date /t可以取得目前的日期，但格式化後取得的結果如下，它會多一個星期幾的字串。 但我們並不想要這個星期幾的字串，而且也不想要"/"。所以可以用如下的指令來取得20121003的字串： @echo off REM 產生日期參數 @For /f "tokens=1-3 delims=/ " %%a in ('date /t') do (set date=%%a%%b%%c) @echo %date% pause 執行的結果如下： 上面DOS指令中的For的意思就是將date /t的結果，依delims(分割字元)來區隔，注意這裏設定的分割字元有兩種，一種是"/"，另一種" "，是空格喔。接著它會取分割後的第一到第三個部份，這是tokens=1-3指定的。 並且所分割出來的部份是以%%a開始命名變數，所以這三個分割出來的變數名稱就是%%a、%%b及%%c。 分割完成後就執行do裏面指令的指令 set date=%%a%%b%%c。這樣就可以得到20121003的字串了。 計算民國年 有了西元年月日，接著就是要計算民國年了。前面我們得到的字串其內容為20121003，接著我們想要取得前面四碼。要如何取得前四碼呢?這又是個難題了。後來查了一下，正好看到有人提供一個方式： set tt=%date:~0,4% 原來SET指令還有這種模式可以用來取得字串的某一部份，真是沒想到。後來就查了一下 SET指令的說明 ，才知道真有這種方式。 不過取到了前四碼，那要如何進行數學運算呢?原來也是用SET就可以了： SET /A ChinaYear=%Year%-1 在SET指令中加上/A的參數就是表示...

今天發生了一件奇怪的事，在一台裝了Windows 2008 R2作業系統的伺服器上，新增了一個帳號，並將這個帳號加入到Administrators群組中。理論上用這個帳號登入的使用者，就等於有了管理員的權限，要安裝什麼軟體都是沒問題的才對。 可是當用這組帳號登入後，開啟命令列視窗後，執行了gacutil.exe來安裝.NET開發出來的元件時，卻出現了以下授權不足的錯誤訊息： 一開始以為是什麼UAC功能要關閉，結果關了也是沒效。後來才知道有人說要用管理員的身份來開啟命令列視窗才行。本來以為登入者具有管理員權限就可以了，沒想到在開啟命令列視窗時還要特別用管理員權限開啟才行。 如果不是用管理員權限開啟視窗的話，會發現在視窗上面是沒有管理員的字樣的：