ChrisTorng

MOQ The simplest mocking library for .NET 3.5 and Silverlight with deep C# 3.0 integration 看起來還蠻有趣的，想寫 Mock 的人可以參考一下。

我自己先前也有為了測 Exception 而使用了 lambda expression，覺得 lambda expression 是個全新的寫程式方法，一開始看起來會比較難理解，但有時可以減少很多程式碼...減少程式碼又會讓程式碼較易讀...

標準的測試寫法，在待測函式會丟出預期中的例外時，要使用 [ExpetationException]，但只能一個 TestMethod 測一個例外。我寫的這個功能，是為了在同一個 TestMethod 中可以測試多個會丟出例外的目標函式。

程式碼很短，貼出來供參考:

[TestMethod]
public void TestThrowExceptions()
{
    Foo foo = new Foo();

    try
    {
        foo.ThrowArgumentException();
        Assert.Fail();
    }
    catch (Exception ex)
    {
        if (ex.GetType() != typeof(ArgumentException))
            Assert.Fail();
    }

    try
    {
        foo.ThrowArgumentNullException();
        Assert.Fail();
    }
    catch (ArgumentException ex)
    {
        if (ex.GetType() != typeof(ArgumentNullException))
            Assert.Fail();
    }
}

非常地長...而且重覆的地方很多...但 try/catch 樣式又沒辦法包在共用的子函式中重覆呼叫，因為裡面有 foo.xxx() 會每次都不一樣...這就令我想到: 匿名函式可以上場了...

以下是可以重覆使用的測試函式:

public static void Throws(Type exceptionType, Action action)
{
    if (exceptionType == null)
    {
        throw new ArgumentNullException("exceptionType");
    }

    if (exceptionType != typeof(Exception) && !exceptionType.IsSubclassOf(typeof(Exception)))
    {
        throw new ArgumentException("exceptionType 參數必須為一例外型別。", "exceptionType");
    }

    try
    {
        action();
    }
    catch (Exception actualException)
    {
        if (actualException.GetType() != exceptionType)
        {
            Assert.Fail("預期要丟出例外 {0}，但卻丟出例外 {1}。此例外之內容為: {2}", exceptionType.ToString(), actualException.GetType(), actualException.ToString());
        }

        return;
    }

    Assert.Fail("預期要丟出例外 {0}，但卻完成執行，沒有例外。", exceptionType.ToString());
}  

測試的寫法為:
AssertExtension.Throws(typeof(ArgumentNullException),() => foo.Bar());

public static void Throws<T>(Action action) where T : Exception
{
    try
    {
        action();
    }
    catch (Exception actualException)
    {
        if (actualException.GetType() != typeof(T))
        {
            Assert.Fail("預期要丟出例外 {0}，但卻丟出例外 {1}。此例外之內容為: {2}", typeof(T).ToString(), actualException.GetType(), actualException.ToString());
        }

        return;
    }

    Assert.Fail("預期要丟出例外 {0}，但卻成功完成執行，沒有例外。", typeof(T).ToString());
} 

測試的寫法為:
AssertExtension.Throws<ArgumentNullException>(() => foo.Bar());

因為在原來的寫法，丟入 exceptionType 有可能不是 Exception 類別，因此要在執行時期做檢查。新的寫法，若是不正確的類別，會無法通過編譯...因此就不必做執行期檢查。而且測試的寫法也更精簡一點。

所以連續測試丟出例外的 TestMethod 可能是這樣:
[TestMethod]
public void TestFooToInt()
{
    Foo foo = new Foo();
    AssertExtension.Throws<ArgumentNullException>(() => foo.ToInt(null));
    AssertExtension.Throws<ArgumentOutOfRangeException>(() => foo.ToInt("a"));
    Assert.AreEqual(1, foo.ToInt("1"));
    Assert.AreEqual(-1, foo.ToInt("-1"));
}
這樣就可以在同一個 TestMethod 用很簡單的寫法測會丟出例外的函式了。

一開始寫 MOQ，到後面全部是寫我自己的東西，跟 MOQ 沒什麼關係...

在 ZDNet 中 [網路部落格]瀏覽器只要快就好？我所寫的回應，轉來此處與大家分享。

Chrome 可以搶得到的佔有率，主要應該是 IE 以外的 FF/Opera/Safari 等，因為用 IE 的人還是繼續會用 IE，會想用 FF/Opera/Safari 等其他瀏覽器的人，也才會想試用 Chrome，而可能被它吸引。最該緊張的應該是 FF 吧。

FF 之前才拿到三年的 Google 合約，可見 Google 並沒有想要吃掉 FF，而是希望 FF 繼續侵蝕 IE 市場。

如果真想要搶 IE 的佔有率，最簡單的做法不是遵循標準，而是完全支援 IE 的所有語法...Chrome 沒有這麼做...

Google 自己都講了，它並不在乎 Chrome 的市佔率。它的推出，更重要的任務是逼迫其他瀏覽器的速度也要加快，最好也加上防當、應用程式捷徑等讓一般網站變得像本機應用軟體的特性。所有的瀏覽器速度加快了，執行速度變得跟本機應用程式相當，使用者就會更喜歡使用網路應用程式，而不喜歡自行安裝本機軟體了。

因此，免費開放原始碼的 Chrome 市佔率即使是 0%，只要大家都喜歡使用網站服務，Google 的目的就達到了。Google 想賺的錢是來自線上流量/廣告，而 Google 網站使用 JavaScript 的量又特別大。加速 JavaScript 這個環節，讓網站服務執行速度與本機一樣快，這就是 Google 所要的。

使用者習慣上網處理工作，而不是在本機安裝軟體後，裝置/OS 的重要性就日漸降低，不在乎你用什麼裝置、OS、瀏覽器，反正只要一上網，什麼工作都可以做。不必再搞防毒、備份、一堆 Windows 更新又得重開等麻煩的事情。

IE 為了保住佔有率，也得加把勁加速 JavaScript 及其他部份的執行速度，這也讓自己的 OS 版本變得不重要 (大家就不必再吵需不需要升級 OS 了)，自己打敗自己。這就是 Google 對抗微軟的絕招，Chrome 成功失敗都無所謂，反正 Google 只要專心做第一名的線上服務提供者即可。

Google 更想藉由 Chrome 表達的，是「你們的瀏覽器都太複雜了」，在一堆華而不實的功能上做文章，卻沒有把核心執行速度放在第一位。他想要證明：「你們瀏覽器裡的那一堆功能，我可以全部搬到網路上來做。」

因此， Google 瀏覽器真的只是一個很簡單的窗口，窗口不必做什麼花樣，只要窗外的世界更美好就夠了。

我只好奇一點，Google 瀏覽器為何沒有全螢幕顯示的功能。就是完全蓋住工作列，只用瀏覽器執行日常工作，瀏覽器的 Tab 就可以切換各個「應用程式」，完全取代工作列了...

更甚者， Google OS 也可以推出來，只需要比 Linux 更更簡單的硬體，只有瀏覽器一個功能，一切只要上網都可以解決。(當然我知道這個可能講得太誇張了，但，是否可能是將來的趨勢?)

上線費用太貴? 沒問題，只要你願意看廣告，一切都是免費的。電腦可以送給你，GPhone 也可以送給你。免月租費，免連線費，一切全部免費。所有的活動都由廣告商支付，換個方式講是所有想賣商品給消費者的廠商，將支付一切的線上活動費用，只求你上它的網站進行消費。

微軟已經被逼得要走上相容於標準之路，將來所有網站撰寫者的工作將會更容易，可以寫一套全部都能跑。

還想要撰寫本機軟體嗎? 還想下載、安裝、破解，與莫名奇妙的問題奮鬥、防毒、備份嗎?

還想學各種程式語言與技術嗎? 何不把 HTML/CSS/JavaScript 這一套徹底搞通就好?

越加越多功能的 Windows 還賣得出去嗎? 偏偏那些功能上網就有免費的...
.
.
.
.
.
.
你所要付出的代價，就是隱私。

Google 在隱私這方面是一直受爭議的。是的，廣告要賺錢，第一就是掌握客戶資訊，才能精準行銷。

Google 的策略，資料與軟體都在它的伺服器上，一切上網都能解決，你就是相信它，把你的一切都交給它。它如果關了，你的一切也就沒了。

再來還可以扯到 Live Mesh。Live Mesh 是微軟仍然要讓裝置很重要，讓你所屬的所有裝置，任何現有既成的軟體，都能很輕易地互相同步 (這樣你就不需要依賴線上服務來達成到處皆可取得的特性)，沒有自己所屬裝置時還有 Live Desktop，其上的使用經驗與本機 Vista 完全相同。但這也限制了它的使用族群，基本上只在 Windows 使用者裡。Google 的策略則針對所有使用者，而且管道是大家早都有也用得很習慣的各式瀏覽器 (Google 並沒有期待你要用 Chrome 上網!)，而不是目前還在 Tech Preview 的全新軟體 Live Mesh。依我個人目前看起來，Google 的策略贏面較大。

由 Live Mesh 來看微軟的策略，軟體可以安裝在你的電腦上，資料也可以本機處理，每一個裝置之間自動同步資料也可以完全點對點完成 (目前還不行，將來的版本才行)，根本不會到微軟手上。微軟伺服器只用作當你不在自己的電腦上網時，還有最後一個備用方案。你想放全部資料進去也可以，完全沒有也沒關係，只是有時會不太方便。

企業會比較不願意把資料交給外人管理。但它也不想沒事被逼著簽軟體合約，兩三年就換一版 Windows、Office 或 IE，把本來用得好好的資訊系統給搞砸，又得花額外的人力去處理多餘的問題。

我也在推測，微軟在 Windows 7 之後，何去何從? 我公司內的網站/軟體，到現在連 IE7/Vista 都還沒辦法完全相容，還有可能去買 Windows 8/Office 201x ??????

Windows 8/Office 201x 可能沒人要買了...微軟怎麼辦? 要針對全網路時代，重新發明新的網路 OS??? 那過去一切的優勢都歸 0 了? 但現有優勢也一直在流失中...不做是不是等死?

Google 瀏覽器不會對瀏覽器市場的佔有率分配有多少影響。但它的釋出，將影響所有的瀏覽器，把核心功能做得更快，提高一切線上服務的可用性，降低作業系統與裝置的重要性。

Google 將會大大得利，微軟則會陷入「要不要以自己的線上服務 打自己的本機軟體」的矛盾苦戰。

你要選擇將自己的一切交給一家公司，完全相信它會好好保管你寶貴 (也許其中許多根本就不寶貴，只不過因為免錢，沒必要留的垃圾也全放進去) 的資料，將來有格式轉換時，一定會幫你轉換到最新的平台? 至於資料放在它那兒，它要怎麼運用，就相信它的隱私權說明了，雖然你從來也沒看過裡面寫些什麼...

還是選擇把隱私、資料放在自己的裝置上，自己想辦法維持電腦正常運作，克服一切的麻煩問題，任何的格式轉換、備份也自己包辦?

感謝 Tony 提醒，告知 ChrisTorng 樣式訊息記錄在 Vista 下無法儲存設定的問題，另我也發現刪除對話階段功能亦有問題。慚愧的是，雖然我自己也使用 Vista，但卻從未用過自己的訊息記錄工具。目前我仍不確定問題是 Vista 造成還是 IE7 造成，若有朋友有 XP 已安裝 IE7 可回報一下是否正常。

刪除對話階段之問題目前仍不知如何解決。而儲存設定的問題，追查了一下，遇到兩個問題，一個是檔案路徑分隔字元原本是 "\"，現在變成 "/"。這個問題倒容易解決。另一個問題，不支援中文檔案路徑。目前會遇到的中文檔案路徑，包括「我已接收的檔案」及「記錄」兩者。我試了一下，找不到方法可以正確讀寫中文檔案路徑，只試出來純英文路徑是正常的。因此必須要將訊息記錄移至純英文路徑上才能正確讀寫設定檔。

也就是說，就目前來說，要修正儲存設定的問題，我想到兩個方法：「改程式＋改路徑」與「直接改設定檔」。

方法一：改程式＋改路徑

這個方法可以解決無法儲存設定的問題，適合於常常修改設定的人。
以記事本開啟 ".\ChrisTorngStyle\SettingProcess.xsl"，找到：
function GetCurrentPath()
{
    var Path = decodeURI(location.pathname.substr(1));
    return Path.substring(0, Path.lastIndexOf("\\") + 1);
}
將這段代換成：
function GetCurrentPath()
{
    var Path = decodeURI(location.pathname.substr(1));
    var LastSlashPos = Path.lastIndexOf("\\");
    if (LastSlashPos < 0)
    { LastShashPos = Path.lastIndexOf("/"); }
    return Path.substring(0, LastShashPos + 1);
}
即可修復路徑分隔字元問題。
再來要把訊息記錄路徑上所有非英文字換成英文，在繁體中文版中包括「我已接收的檔案」及「記錄」兩者。可換成英文版的 "My Received Files" 及 "History"。然後在 Windows Live Messenger 中亦需設定新的訊息路徑：「工具 - 選項 - 訊息 - 將我的對話內容儲存在此資料夾」。

方法二：直接改設定檔

如果只需要設為繁體中文，不需要常常改設定值的話，建議用這個比較簡單的方法。
設定檔位於訊息記錄資料夾內 ".\ChrisTorngStyle\CurrentSetting.xsl"，以記事本開啟，將其中的 "Language_en-us.xsl" 代換成 "Language_zh-cht.xsl" 存檔後即可。
所有可用的語言檔名列在 ".\ChrisTorngStyle\AllSetting.xml" 中之 "AllSettings\Languages\Language\File" 段落，可以任選其一。其他 "CurrentSetting.xsl" 中的設定值，只要看得懂一些英文，相信不會太難看懂，如果有需要的話可自行修改，只要小心別動到 9/30/true/false 這些設定值以外的字元即可。