安德魯的部落格

  1. [設計案例] 清除Cache物件 #1. 問題與作法

    每次心裡有什麼好點子想寫出來時，第一關就卡在想不出個好標題… 想來想去的標題，怎麼看就是既不顯眼又不聳動… 果然是個老實的工程師性格 =_= … 這次要講的，是 .NET HttpRuntime 裡提供的 Cache 物件的操作心得。這個東西我想不用我多作介紹，大家都用到爛掉了吧? 不過好用歸好用，有個老問題其實一直困擾著我很久了…

    “我該怎麼手動的把某個物件從 cache 裡移除?”

    老實說，這問題蠻沒水準的… 老叫別人要翻 MSDN，我自己怎麼沒翻? 不不… 容我花點篇幅先說明一下問題。Cache物件，是個典型的 Dictionary 型態的應用 (雖然它沒有 implement interface: IDictionary… ), 透過 key 就可以拿到 cached item. 要從 cache 裡移除某個 item, 簡單的很，只要用 Remove 這個 method, 一行就搞定了:

    從 key 移除指定的 cache item

    HttpRuntime.Cache.Remove("cache-key");

    別小看這一行，實作起來障礙還不少。首先，你得額外去記著 cache key 的值。當你要移除的 cache item 有多個的時後，或是移除的 items 之間的關係有點複雜時，這些 code 就不怎麼漂亮了。下一個問題是:

    “我該如何得知所有存在 Cache 內的 keys 有那些?”

    這個問題單純的多，那些把 intelligent sense 當購物網站的人 (平常不看文件，只會按下 . 然後挑個順眼 method 來用的人)，可能這次就碰壁了… Cache 物件不像一般的 Dictionary 一樣，有提供 Keys 這樣的 property … 它藏在 GetEnumerator 這 method 內，它會把所有的 keys 給巡一遍，你需要所有的 keys 的話，可以這樣用:

    跑過 cache 裡每一個 key

    foreach (string key in HttpRuntime.Cache) { 
    // … 
}

    不過這樣的風險也是蠻高的，誰曉得你拿到 key 後的下一秒，這個 cache item 還在不在 cache 內?

    本文正式開始! 哈哈，前面那一段只是廢話 + 碎碎唸，現在才是正題。前面想表達的只是，因為 cache 的不確定性 (資料隨時都會被 remove), 操作起來變的要格外小心, 即使它用起來像一般的 Dictionary 一樣。

    我舉個案例，來說明我應用 cache 的情況。假如我想實作一個簡單的 web browser, 透過網路下載資源是很慢的動作，每種 browser 都會有某種程度的 cache 機制。我們就拿 Cache 物件替代 IE 的 “temporary internet files” 目錄吧。這時很簡單，只要用 URL 當作 KEY，下載的 content 就當物件塞進去就好…

    不過事情沒那麼簡單。如果程式運作了一陣子，我想提供使用者手動清除 “部份” cache 的功能的話，那該怎麼辦? 我舉幾種情況:

    1. 從 cache 裡刪除所有從某個特定網站 (如: columns.chicken-house.net) 下載的資料
    2. 從 cache 裡刪除所有特定類型的資料 (如: content-type 為 image/jpeg 的圖檔)
    3. 從 cache 裡刪除所有透過特定 protocol (如: https) 下載的資料

    這樣的要求應該不算過份吧? 用前面提到的兩種作法，你會想哭吧 XD .. 用這些基礎，你大概只能選這幾種作法 (各位網友有好作法也記得提供一下):

    1. 自己另外管理所有下載過的 URL, 用盡各種適合的資料結構，讓你可以順利的挑出這些 match 的 key, 然後移除它。

      缺點: 都作這麼多，你乾脆自己重寫個 cache 機制好了… 何況時間一久，你管理的 key, 那些對應的資料搞不好老早就通通從 cache 裡清掉了…

    2. 聰明一點，用 regular expression … 從 GetEnumerator( ) 一筆一筆過濾出要移除的 URL, 然後清掉它…

      缺點: 這作法只會檢查還留在 cache 內的 URL，不過這樣的 cache 隨便也有成千上萬個，每次都要 looping 掃一次實在不怎麼好看… 有違處女座有潔癖的個性…

    這些方法 code 寫起來實在不怎麼漂亮，我就不寫 sample code 了，請各位自行想像一下寫起來的樣子。抱歉，如果你用的正好是上面的作法… 那請多包含… :D 這些都是 workable 的作法，但是看起來就是沒什麼設計感；程式可以動，不過就效能、簡潔、可讀性、美感來看，就是覺的不夠精緻 @@。跟朋友討論到這個問題時，我想到一個爛主意…

    “用蠢方法，這些 cache item 先分好類，每一類去關聯一個檔案，設 CacheDependency … 要清掉時去 touch 一下這個檔案，一整組的物件就會自動被清出 cache 了…。”

    老實說，我覺的這是個既聰明又愚蠢的作法。聰明的是它很漂亮的解決我要如何移除某一群 item 的問題…，愚蠢的是這種單純程式內可以解決的事，竟然要繞到外面不必要的 file system I/O 動作… 而這通常是最慢的…

    –

    咳，寫太晚，實際的程式碼明天待續…

    2009/12/19 設計案例: 清除 Cache 物件 .NET ASP.NET C# MSDN Tips 技術隨筆 物件導向

  2. 終於突破單日 100km 了! (台北-大溪)

    有嘗試過的朋友就知道，單日腳踏車破百，雖然不算太難，不過也不輕鬆。騎到後來會有那種撞牆期的感覺.. XD

    今天就拼了，再度挑戰這個里程碑，騎到大溪然後再繞回來…

    image

    起點：從家裡出發 (關渡)，終點：大溪。來回預估應該有 90 ~ 95km 左右，不過看起來是不夠，那就繞點路唄 :P

    image

    [5.6km] 先到關渡水岸公園，然後接腳踏車道…

    image

    [7.0 km] 經過關渡大橋

    image

    [11km] 五股溼地… 上回來的時候沒這些大片的水，那時都是泥土

    image

    [19.3km] 大漢溪左岸，快到城林橋了。

    image

    (上回的舊照片) 剛過城林橋..

    image

    [27km] 轉眼間已經到鶯歌了..

    image

    [28km] (上回舊照片) 鶯歌陶瓷博物館，經過了好幾次，可是都沒進去過 @_@

    image

    [28.3 km] 三鶯大橋下，鶯歌到大溪的自行車道 (2009/07 才通車)

    image

    過了三鶯大橋後，腳踏車道的風景就完全不一樣了 (Y)

    image

    過了個閘門，原來水都被關在這裡，難怪一路上大漢溪都沒什麼水…

    image

    真棒的風景，我喜歡這種有有山有水的 (Y)

    image

    離開溪邊，到大溪的這段路變成鄉間小逕，兩旁都是韭菜田及稻田…

    image

    [41.2km] 到大溪橋了 (這次沒照照片，拿上次的照片充數… :P)

    看看碼錶，才 41.2km, 騎回家大概連 90 都不到，更別提破百了，真是失算 @@ 看看時間還夠，回程就繞去三峽老街逛逛好了。

    image

    雖然公司有好幾個人住三峽，不過每個都不知道那家有名的牛角麵包是那一家… 只會跟我講我上次買錯家了 XD…

    看來還是 GOOGLE + 路人比較可靠，這次就找到了… 是在條不起眼的巷子裡，一家叫 [福美軒] 的麵包店.. 一堆人等著麵包出爐，排隊排到店外面… 足足排了一小時才買到 =_=，一個 20 元，每人限購 30 個…

    image

    在回程的路上拿了兩個出來吃，果然好吃 (Y)

    image

    柑園橋旁的XX公園 (抱歉，名字忘記了)，有一片草地，前面的是蓮花池… 不過季節不對，看不到蓮花 @@ 那堆綠綠的是布袋蓮，可不是草地… 踩下去是會掉下去的

    image

    [85km] 華江橋上照的..

    image

    最後回到家，最後一個巷子口看了一下碼錶，98.5km…. @@

    單日破百的行程怎麼可以敗在這最後這區區 1.5km ? 於是就繞了點路，去附近的腳踏車店打個氣，然後再回家… 正好 100.29 km! 哇哈哈，單日破百的成就達成!

    2009/11/23 腳踏車 腳踏車

  3. [設計案例] 生命遊戲 #6, 抽像化 (Abstraction)

    原定 #4 就提到的 “抽像化”，竟然被我連拖兩期，拖到 #6 才提到它… 人老了果然比較囉唆… 在前面的幾篇，重點都在如何 “具體” 的描述 “生命遊戲” 裡的細胞。不過現在要把這程式擴大到能容納各種不同的生物，先作好抽像化的工作是必要的…。

    一般物件導向所指的 “抽像化”，是指你對某些事物的一般概念。比如有人問你:

    “你會開車嗎?”

    你腦袋裡想的應該是一般印像中的車子，有方向盤，排檔打下去，油門踩了就會前進，煞車踩了就會停下來…，這就是你對 “車子” 的抽像化。你不會去管車子是什麼牌的，什麼顏色，是二門跑車，或是休旅車之類的細節… 而你 “會” 開的車，也不會因為這些細節，有太大的不同。

    這樣的抽像化概念，套用到考駕照這件事來說，你只要知道方向盤，油門等等的用法，同時也練習過，能正確的控制教練車，通過測驗，監理所就會發張駕照給你，證明你會開一般的車子。就算是在你學會開車後十年才上市發表的新車也是一樣。

    看起來沒什麼了不起的描述，在電腦的世界裡可不是這麼一回事。Microsoft Word 1.0 想要順利開啟 Microsoft Word 6.0 的檔案，大概想都不用想，因為 1.0 版設計之初，有太多 6.0 版的變化是無法事先預料的，自然無法設計出能正確操作的程式，這現像在電腦的世界很正常。不過如果你兩年前考到的駕照，碰到兩年後的新車你就不會開了，甚至監理所還要求你重考張新的架照… 那這駕照等於一點用都沒有。中間的差別，就在於駕駛者對於開車的認知，跟實際的車子，中間是隔著一層 “抽像化” 的概念，而只要能掌握這抽像化的定義，就能順利操作未來的車種。

    因此物件技術不斷的想要模擬這樣的關係，就發展出繼承這樣的方式，來表達這個概念。先用一個類別 (base class) 或是介面 (interface) 來表達這個 “抽像化” 的概念，而不表達細節。其它要跟它互動的程式，只能透過這個抽像化型別來溝通，而其它的細節或實作，則被藏在裡面，或是衍生類別。中間的故事我就不再多說了，再說我就直接去寫 OOP 的書好了 =_=，有興趣可以參考這本經典 [世紀末軟體革命]，有復刻版喔。套用到我們的 “生命遊戲” 裡，要定義的就是 “世界” 如何跟 “生命” 互動? 之間的關係是什麼? 另外就是 “生命” 有各種不同的型態，所有的 “生命” 型態是否都能順利的在同一個 “世界” 裡生存?

    先試著用簡單文字來描述吧。在我們的定義裡，世界是個 M * N 的棋盤，每一格都能放一個生物。每個生物有自己的狀態 (生/死)，也會隨著時間與環境的不同，讓生物的狀態產生變化。畫成 UML 的 class diagram, 大概就像這樣 (手邊沒工具，用 power point 大概畫一下… Orz):

    image

    我們在撰寫程式時，就必需思考題目中講到的生物各種特性，那些是所有的生命共有的特色? 這部份要把它定義在 Life … 另一部份是某種細胞特有的，則要放在衍生類別 Cell 裡。而世界必需要能跟生命作適當的互動，讓生命的進行能繼續下去。這樣的架構好處是，未來如果有第二種 Cell 或是其它的生物，只要是從 Life 繼承下來，都能很順利的在 World 裡活著，因為物件導向技術的 “抽像化” 概念，保證這樣程式的可行性。

    好，我們就以需要跟 World 接觸跟互動的部份為主，把原程式的 Cell 抽離出來，放到它的上層類別 Life 裡。這也是物件技術裡常提到的 “generalization” (一般化)，越一般的特性要越往上層類別移動，而越往下就是 “specialization” (特殊化)，底層的類別要去實作特殊的部份，或是特有的細節。

    先把原程式作好調整吧。原 Cell 的程式碼，部份被搬移到 Life, 同時這兩個類別有了繼承關係，如下:

    ClassDiagram1

    Life 的部份，定義了所有 Life 都該表達出來的特性，也就是我們對於 Life 的認知，都應該描述在裡面，像是 Life 活在 World (CurrentWorld) 裡，會有它的座標 (PosX, PosY), 也會有它在這個棋盤內顯示的方式 (DisplayText) 等。而跟 World 互動的方面，Life 則透過 GetNextWorldTask( ) 來讓 World 來讓 Life 驅動它生命的進行。

    在 World 的這邊，不管是那種 Life 衍生類別的物件，一律都當成 Life 的 “抽像概念” 來操作。這樣的優點，在還不曉得未來這世界到底還有多少種不同的 Life 會在裡面生活時，主要程式就能開發了。未來 Life 可以一直擴充，衍生出多種不同的 Life 子類別，而 Life / World 之間的互動及規範，則可以完全不用修正。

    接下來就要讓這遊戲的規則，變的更真實一點了。實際的情況下，應該是我們已經知道會有那些不同的生物，經過歸納 (一般化及特殊化) 之後，可以設計出我們需要的類別架構。不過實際寫起程式來可沒這麼好命 (就像 USER 永遠不會一次給你完整確定的需求一樣)，很多時後你得去 “猜” 或是 “假設”，因此跟本沒有 “一般化” 這回事，你得預先去猜測未來要應付什麼問題，而在細節都還不清楚時就先定義出上層類別。

    我們開始來試看看，我們定義的夠不夠抽像吧! 如果助教看你這麼快就把生命遊戲的作業交出來，覺的很沒面子，想把題目變難一點，加上有病毒感染的情況。於是原題目的四條規則追加一條，變成這樣:

    1. 孤單死亡：如果細胞的鄰居小於一個，則該細胞在下一次狀態將死亡。
    2. 擁擠死亡：如果細胞的鄰居在四個以上，則該細胞在下一次狀態將死亡。
    3. 穩定：如果細胞的鄰居為二個或三個，則下一次狀態為穩定存活。
    4. 復活：如果某位置原無細胞存活，而該位置的鄰居為三個，則該位置將復活一細胞。
    5. 感染：正常的細胞有 ( 1 + 受感染的鄰居數量 x5 )% 的機率受到病毒感染。已感染的細胞在 3 次狀態改變後會痊癒。受感染的狀況下，有 10% 的機率會死亡。

    我們的程式該怎麼配合它改變? (對，機車的 USER 就都是這樣臨時修改規格…) 先來看看執行的結果，畫面上已經分的出來活著的 Cell 跟受感染的 Cell … 除了看到 Cell 活著與死亡的變化之外，也看的到病毒擴散的狀況是怎麼樣。執行的畫面如下:

    image

    圖例: ◎受感染的細胞，●活著的正常細胞，○死亡的細胞

    接著，來看看改版後的程式碼:

    public bool IsInfected
{
    get
    {
        return this.InfectedCount > 0;
    }
}
private int InfectedCount = 0;
public override string DisplayText
{
    get
    {
        if (this.IsAlive == true) return "●";
        else if (this.IsInfected == true) return "◎";
        else return "○";
    }
}
protected override IEnumerable<TimeSpan> WholeLife()
{
    yield return TimeSpan.FromMilliseconds(_rnd.Next(800, 1200));
    for (int index = 0; index < int.MaxValue; index++)
    {
        int livesCount = 0;
        int infectsCount = 0;
        foreach (Cell item in this.FindNeighbors())
        {
            if (item.IsAlive == true) livesCount++;
            if (item.IsInfected == true) infectsCount++;
        }
        bool? value = _table[this.IsAlive ? 1 : 0, livesCount];
        if (value.HasValue == true)
        {
            this.IsAlive = value.Value;
        }
        if (this.IsInfected == true)
        {
            this.InfectedCount--;
            if (this.InProbability(10) == true) this.IsAlive = false;
        }
        else
        {
            if (this.InProbability(1 + infectsCount * 5) == true) this.InfectedCount = 3;
        }
        yield return TimeSpan.FromMilliseconds(_rnd.Next(800, 1200));
    }
    this.Dispose();
    yield break;
}

    細節我就不多介紹了。這裡的重點是經過抽像化的動作後，把 Life / Cell 之間的邏輯做明確的劃分。World 的類別程式碼完全沒有出現任何有關 Cell 的 Code, 只有出現 Life 而已。除了在主程式 GameHost 有這麼一段，明確的把 Cell 建立起來，把它放進 World:

    static void Main(string[] args)
{
    int worldSizeX = 30;
    int worldSizeY = 30;
    World realworld = new World(worldSizeX, worldSizeY);
    Random _rnd = new Random();
    for (int x = 0; x < worldSizeX; x++) {
        for (int y = 0; y < worldSizeY; y++) {
            Cell item = new Cell();
            realworld.PutOn(item, x, y);
        }
    }            
    // ...

}

    這樣的作法，其實已經引含了 “動態聯結” 的特性了。在開發主程式的階段 (指 World / Life 這兩個主要的 class), 都還沒有 Cell 的相關細節，而事後執行的程式碼卻可以依照 Cell 裡的邏輯來執行。這代表了我們不需要改主程式的設計，就能不斷的加入新的規責，甚至是新的生物進來一起運作。

    如何? 物件技術的 “抽像化” 能力，的確很有效的解決了這樣的變化需求。下一篇會沿用一樣的架構，但是執行的範例會完全不一樣 (這次不用細胞了，直接用草原上的生態: 草、羊、虎) 的生命及規則，來套進這個框架，看看它能怎麼模擬出一個新的生態系統。

    這樣的架構可以應付未來未知的變化，只要你的抽像化概念不變的前題下都沒問題。這種保留彈性，卻又不用在 design time 去多做不必要的實作，才是物件技術強大的地方。我舉個反例，很多剛入行的軟體工程師，你給他一個需求，他會想太多… 一個簡單的輸入 1 + 1 要顯示 2 的結果，他會這麼想:

    USER 需不需要列印啊? 我先把這需求放進去好了，然後加個 config 預設關掉它，以免以後需要我還得大改程式…

    只能算 1 + 1? 如果以後 USER 要算 3 * 5 怎麼辦? 好吧，我把 + 用一個 mode 來代表好了，以後 USER 需要括充為支援 +-/ 就不用大改程式了…*

    …

    碰到這些狀況，我只能誇獎這位年青有為的程式設計師一句話:

    “你很認真… 辛苦了…”

    不過我心裡會苦笑… 只不過要你寫個 1 + 1 = 2，搞這麼一大包? 多作考慮，預留未來可能需要的功能，不是件壞事。不過既然是未知的需求，你又如何保證你能夠正確的 “預知” ，然後進一步 “預留” ? 何況這些多做的需求，未來真正會用上的有多少? 用不到的話，只是開發成本的浪費，及讓你的架構複雜性提高，維護的困難增加而已。物件技術真的解決的了這種問題嗎? 下一篇的目標，我們會定在不修改 World / Life 的設計為前題，把生命遊戲的模擬內容換成草原的生態模擬。敬請期待續集 :D

    2009/10/03 系列文章: 生命遊戲 C# Tips 技術隨筆 物件導向 系列文章: 生命遊戲

  4. 電腦時鐘越來越慢...

    最近這兩個禮拜，很扯… 我的手機時鐘越來越不準，竟然每天會晚個幾分鐘，不到兩個禮拜，竟然跟正常時間比起來已經差了廿分鐘…

    天那，這什麼時代了，一個五十塊的電子錶都比我這隻五為數價位 (幾年前的價位啦 =_=) 的手機準時… 怪的是，白天再公司又是準的 !? 越看越怪，難不成這時代，連看個時鐘都得先 DEBUG 一番… 今天就花了點心思追一下問題 @@

    首先，原來慢的不是我的手機，而是我家裡的 PC，因為手機插上 USB 充電 + SYNC，會順便對時，就這樣誤差越來越大了。不過 PC 不是都會上網對時嘛? 後來就再繼續追下去…

    繼續追下去，家裡 PC 是跟家裡的 SERVER (domain controller) 對時的… 原來時間慢的是家裡的 SERVER… 不過問題還是一樣啊! 現在一直都連上網的 SERVER 怎麼可能會這樣?

    因為每次重灌，一堆帳號就要重建，很麻煩，所以上個月重灌 SERVER時，就順手在 VM 裡裝了台 SERVER，當作 Active Directory 的 domain controller (Guest OS)… 而 SERVER 本身 (Host OS) 才是拿來做 NAT / RRAS / FILE SERVER 等服務…

    這樣的架構，機車的地方就在於: Hyper-V 本身 VM 會跟 Host 做 time sync … 而 Host 有加入 AD, Host 又會跟 Guest 同步時間，Hyper 又替 Guest 跟 Host 同步時間… 每次誤差一點，幾週下來就變這樣了 @@ 害我的手機莫名奇妙就晚了快半小時…

    image

    果然，這選項移除後，就一切正常了 @@，頂多就讓 DC 脫褲子放屁，到外面的 server 去對時吧… 嗯，這年頭，真的什麼怪事都會發生… 還好這次有抓到問題，哈哈… 這篇就給跟我一樣宅的人參考吧 :D

    2009/09/29 Tips 技術隨筆

  5. [設計案例] 生命遊戲 #5, 中場休息

    在繼續下去之前，先來講一下，我希望讓這個 “生命遊戲” 程式，發展到什麼程度吧。其實前面四篇都還只是基礎入門，跟準備動作而已，接下來才開始會有些有趣的。

    我希望這系列文章寫完後，這個程式要能扮演一個真正可運作的 Matrix … 沒錯，就是像電影駭客任務裡的母體一樣，這個程式會變成 Matrix 的主要架構，而各式各樣的 “生物” 可以在這個虛擬世界裡生活。為了讓它真的跑的動，所以前幾篇提到的效能問題，執行緒問題，就不能不考慮。為了讓這個虛擬世界能更擬真一點，它至少要是個依時間驅動的模式，而不是像 “生命遊戲” 最早定義的回合制，因此這個問題也要在基本架構裡解決掉。

    這些 “生物” 那裡來? 當然是大家來開發 :D 最終目標是要把這 Matrix 建起來，讓各位的生物可以放進來互相較勁一番… 因此先替這些程式 (生物) 抽像化，定義好它跟世界，及跟其它生物之間互動的規格 (就是下篇 “抽像化 / 多型” 要說的) 就是必要的工作之一了。替生命定義好抽像化介面之後，就可以開始衍生出各種不同的生命型態，一起加入這個虛擬世界，因此繼承、多型的技術就派上用場了。

    生命是會演化的，當世界上真的演化出一種新的生命型態時，整個世界可以 “安裝” 好新的生命型態，然後全部存檔，重新啟動嗎? 當然不行… 因此如何 “動態” 的加入新的生命型態，如何不停止 GameHost 的前提下，由新的 Assembly 載入 Class (再下篇要說明的 “動態載入”)，也是必需克服的技術之一。

    這幾個階段及目標，就是我這一系列文章想要做到的。聽起來好像很有趣，可是卻又沒什麼實際的用途… Orz, 沒辦法，我就是喜歡寫這類要動點腦筋的程式，即使畫面一點都不炫也沒關係… 平常工作就不大有機會寫這種程式了，加上現在又只剩一張嘴…。

    如果順利的發展，我倒是有個打算，這個 GameHost 成形之後，我打算定些基本的規則，比如土地上會有一定的機率及規則，長出草 (食物) 來。而這世界有各種不同的生物 (EX: 羊)，需要靠這世界上的資源維持生命。到時大家可以把自己創造的 “羊” 一起放到這個世界內，看看執行了一陣子之後，誰設計的 “品種” 比較好，最後可以一代一代的繁衍下來…。

    想的很美好，不過我不像 darkthread 可以替最後優勝的造物者提供獎品.. Orz.. 未來的設計藍圖就先規劃到這裡。在繼續下去之前，我把程式重新整理了一下，有興趣的人可以下載回去。這份程式碼跟 #4 的功能結構是一樣的，只不過整個架構都作過重整，變數等命名也調整過了，是為了往後說明相關物件技術時，不會被這些從 #1 ~ #4 改的支離破碎的程式碼干擾…

    嗯，講了一堆廢話，結論就是: 敬請期待續集 :D 哈哈…

    下載重整過的程式碼:

    BLOG #5.zip

    2009/09/24 系列文章: 生命遊戲 .NET 技術隨筆 有的沒的 物件導向 系列文章: 生命遊戲

Facebook Pages