Go

經過四年的各地輾轉，終於到了畢業時就計划去的地方，北京這幾年去過，哈爾濱，大慶，大連，福州,為什麼沒有去北京的原因就是感覺城市太大，我個人的心很亂，稍微環境有些嘈雜就會影響心情，所以不願意到北京，不過現在沒有辦法，至少北京的個人發展好一些。到了北京感覺太大了，在臨時住所上一趟公司，感覺在哈爾濱回趟家那麼遠，很耽誤時間，第一個任務是認可貴點，也得在公司附近租個房子 

　　接觸編程有三個年頭了吧,從ASP到C#,後來又開始學習JAVA,　ASP和C#都算不上精通吧,說實話也不知道什麼樣是精通,呵呵.　　終於開始學習JAVA了,先手忙腳亂的做了個項目,連LIST　MAP　都用的不熟....　　前些天鼻子做了個小手術,　有得有失嘛,上天讓我的鼻子出了問題,覺得過意不去了.於是派了幾個要好的師兄出現,給我指明了下一步學習的方向.　　　鼻子還要定期去複查,　期未考也快到了,　設計模式才開始學習,　JAVA的基礎不能不看.....　　嘿嘿,開動嘍!!!

假設我們在測試一個電子郵件地址的網頁輸入框，下面是相關的需求描述：當該文字框輸入一個“電子郵件”以後，點擊儲存按鈕，如果輸入的是正確的電子郵件地址，則轉入下一頁，否則提示一個訊息框，顯示“你輸入的不是合格的電子郵件，請重新輸入”。點擊“確認”按鈕以後，焦點回落在電子郵件地址輸入框裡，並且游標放在文字框最後一個文字後面。沒有選中文字。原來的輸入文字內容不變。那麼我們應該測試多少？1. 對話方塊顯示的訊息是否要測試？2. 對話方塊的確定按鈕點擊是否要測試？3. 對話方塊的關閉按鈕點擊是否要測試？4.

        本來並不想寫著篇，因為英文維基上的zobrist hashing詞條已經夠詳實了。後來發現自己的論文上有圖文並茂的一節介紹zobrist雜湊，想是為湊字數與圖片寫的，貼出來倒也方便：        Zobrist 雜湊是一種專門針對棋類遊戲而提出來的編碼方式,以其發明者 Albert L.Zobrist 的名字命名。Zobrist

昨天終於練了一次百米跑，整個程式在5：30分終於Build完畢，立刻拉起同事向火車站跑去，火車在5：56開，跟出租車司機講明情況後，師傅一句“座好了吧”，車就沖了出去，到了火車站一直衝到檢票口，行李檢查什麼的全都省了，檢票員非要檢票，可是手累得直抖，終於上車了，還好，沒有趕不上火車，這是我一個最大的毛病，也許很多程式員都有這個毛病，有我媳婦的話就是“糞堵腚門子”才能完成事，雖然早就用Project做好了計劃，但是每次總是不準確，還好趕上了火車，直接後果就是同事吃了兩碗即食麵才吃飽。金州火車站依舊

       先來看下silverlight1.0的架構（圖片來源MSDN）：這1.0的時候主要由各部分來組成silverlight.從上面的圖可以看到，silverlight1.0的時候，最上面的plugin 的主要作用是轉化xaml檔案，和js互動已經處理download等等，給下面的核心庫去使用，而最下的multi-core rendering engine

    軟體工程課老師讓我們選一本教材，分別是《代碼大全》、《快速軟體開發》、《移山之道》 。作為初入茅廬的人，對三本書沒有先驗知識的情況下，對比了這三本書，最後選擇了《移山之道》。· 為什麼我選擇《移山之道》？   1. 《移山之道》名字讀起來霸氣外漏，所有人很喜歡物超所值，尤其是中國人，看著名字，好像是講方法的，”道”是個很高深的問題，淺可達到方法，深可達到哲學。加上老師推薦，這本書應該不會差，所以首先名字吸引 了我。   2. 看著厚厚的《代碼大全》，裡面教你如何寫代碼，如代碼布局、注釋、

文章目錄 0.參考文獻3. 相關說明：

.net平台內建了對Web Service的支援，包括Web Service的構建和使用。與其它開發平台不同，使用.net平台，你不需要其他的工具或者SDK就可以完成Web Service的開發了。.net Framework本身就全面支援Web Service，包括伺服器端的要求處理常式和對用戶端發送和接受SOAP訊息的支援。下來我們就一步一步的用Microsoft Visual Studio .net 2005（後面簡稱VS.Net 2005）建立和使用一個簡單的Web Service。2.

一

前幾天幫人做了個小軟體，發給使用者後，過了天便收到軟體運行出錯訊息.當時真納悶，在本機測試回合正常的.錯誤資訊如下 ：找不到方法 ”System.StringSystem.Windows.Forms.OpenFileDialog.get_SafeFileName()"。。具體資訊開啟原始碼...找到到了OpenFileDialog.SafeFileName這句測試,發現正常然後查看MSDN,發現 --------------------------------版本資訊.NET

前面我們曾經講過《你的項目統計這些資料嗎？》，這裡我們在補充一些內容。1. bug原因分類    bug產生的原因只有一種，那就是代碼編寫錯誤，沒有什麼設計錯誤還是需求錯誤之類的荒謬分析。如果牽強的分類會發生什麼情況，程式員為了減輕自己的責任，將問題盡量的歸結為：     設計不充分 —— 設計人員的問題     需求不明確 —— 需求分析人員的問題     測試案例不足 ——

        為了實現UCT演算法，需要在記憶體中構建一棵博弈樹，博弈樹的每個節點是博弈過程中的一個局面。        一個顯而易見的方法是——構建樹形的資料結構，每個節點儲存3類資訊：1）該節點所代表的局面。2）局面資訊（當前收益值與被嘗試次數）。3）子節點的索引。        出於以下兩個考慮，我並沒有用這個方法。        1）儘可能地減少記憶體佔用。       

        畢業也有兩個月了，寫這篇文章算是紀念我的畢設——圍棋博弈程式的設計與實現。選了這個找抽的課題作為畢設，一度不知該如何?，還好萬能的微博讓我得知了現代電腦圍棋的核心演算法——UCT演算法。而蒙特卡羅局面評估演算法是UCT演算法的基礎。本文作為本系列第一篇文章，先介紹蒙特卡羅局面評估演算法。        電腦圍棋博弈問題的一大痛點在於難以設計簡單有效局面評估演算法。傳統的圍棋程式主要採用影響函數等專家知識進行局面評估，由於圍棋的專家知識難以抽象出來（想想厚味，薄味，氣合等詞……），

        UCT演算法算是介紹完了，以後主要講實踐。        由於在物件導向的程式設計語言中，本人只會C++和Objective-C（以後也許會寫一些iOS開發相關的博文），出於效能的考慮，選擇C++是必然的。記得當初開題答辯時，一老師問道，既然考慮效能，為什麼不用C，而用C++？對於這種明知故問無厘頭的問題，我只能回答：機器碼效能更好。後來才知道陳志行老師的”手談“是用彙編寫的……        本篇還是談談棋盤的資料結構吧！（這裡就不談整個程式的架構了，因為本來就設計得不好） 

        上一篇介紹了蒙特卡羅局面評估演算法，怎樣用這個演算法實現圍棋博弈程式呢？最容易想到的方法是，對於一個給定的局面，用蒙特卡羅局面評估演算法來評估每一個可下點後的局面，由此選取最佳著手點。這是可行的，但有沒有可以最佳化的地方呢？        假設你是CPU，你知道圍棋規則，但不知道更高層次的圍棋知識，只會類比隨機對局，面對茫茫棋盤，你將如何選擇？你會逐個點類比對局1萬次，最後通過比較評估值大小來選擇最優點，還是。。。        先撇開圍棋，介紹個“多臂匪徒問題”，問題描述如下：

        我們已經知道UCB演算法能夠更快地找到靠譜的著手點，續上一篇的問，能不能再最佳化？       

　　有了棋串的資料結構後，落子就變得很高效了，接下來要產生隨機棋步。　　以9x9棋盤為例，直接產生0~80的隨機數進行類比會很低效，因為它們並不都是合法落子點——有3類落子點是非法的：1. 非空點 2. 劫爭點 3. 自殺點。　　自然想在類比過程中增量維護這3類點集，前兩類很容易維護，痛點在於自殺點的增量維護。　　著手寫自殺點的維護後，才發現問題出乎意料的複雜。我先寫了個IsSuiside函數，通過試下作為最終的裁決，而這又涉及到對象的拷貝，太過昂貴。於是想盡量少用，通過位元運算來判定多數情況。

　　這幾天把圍棋A.I.最後的部分寫好了，9路小棋盤上看上去運行得還不錯，更名為FoolGo。先講一下UCT博弈樹的實現。　　鑒於FoolGo的MC類比速度和棋盤對象的大小，如果直接用樹結構實現，用不了幾分鐘，我的MBP的4G記憶體就會被棋盤擠爆。所以要通過置換表實現博弈樹。　　雜湊演算法當然是zobrist雜湊。如果雜湊值的類型是uint32_t的話，不同棋局雜湊衝突的機率就是1 /

Maybe it's just my mood. It probably is. I receive a lot of email about job positions. In fact, I receive a lot of calls, too. Almost always both  voicemail and the email is deleted before I even reach the end. This one struck me especially