本文同步自游戲人生

現在有些年輕人的心態比較浮躁，大致總結以下『四點表現』：

1. 眼高過頂；

2. 垂手過膝；

3. 期望值高；

4. 積極性低。

深層次的客觀原因大致是『四個沒有』：

1. 沒有吃過苦；

2. 沒有干過活；

3. 沒有說過話；

4. 沒有當過家。

一般都具有『四個特征』：

1. 獨生子女；

2. 畢業新人；

3. 沉默寡言；

4. 半瓶開水。

---------------------------------

1. 你想要什么？

參考：一個有影響力的人。（@李開復）

2. 那是否是你想要的？

參考：你的眼光有多遠，決定了你能走多遠。（@Fox）

3. 你需要做什么？

參考：高筑墻，廣積糧，緩稱王。（朱元璋）

4. 你還需要做什么？

參考：平和的心態，進取的態度，堅定的目標，不懈的努力。（@Fox）

5. 你是否做到了？

參考：沒有，但我一直在努力。（@Fox）

本文同步自游戲人生

-----------------------讀書-----------------------

想讀《UNIX Network Programming》很久了，只是這種愿望一直沒有特別強烈。用的筆記本換了之后強迫自己只是裝了cygwin，沒有安裝VS，平時寫些代碼就只能在cygwin下用gcc了。最近對UNIX環境編程和網絡基礎比較感興趣，于是讀這本書終于提上了議事日程，可是大多數書店都沒有這本書了。

工作之后，對于自己喜歡的書，就很少會去看電子版，覺得還是捧卷在手的感覺舒服一些，想怎么看怎么看，享受拿筆在上面寫寫畫畫的感覺。因此對于想讀但買不到的書，第一反應是等待。在翻電腦上面一些資料的時候才反應過來我已經很久沒有down過電子書了，結果就從網上down了很多想讀(豆瓣)的書，forgive me, Richard Stevens and anybody.

-----------------------動手-----------------------

之前只是在Windows下用過ACE，因為ACE提供了VS各種版本的解決方案，編譯過程比較簡單。這次放在cygwin下編譯的時候，因為環境變量設置問題，并不是非常順利，參照了源碼目錄下的ACE-INSTALL.html的描述才將問題解決。現在將過程給出來，僅供google到這里的同學參考：

友情提示：我目前對于cygwin和UNIX類系統的了解停留在知其然（還是在google之后）的水平。

1. 增加環境變量

o 修改/etc/profile文件讀寫屬性：

$ chmod 777 /etc/profile

cygwin下的環境變量可以在該文件中配置，由于該文件默認具有寫保護屬性，因此需要修改使之可寫，修改完成之后應該記得對其進行寫保護：

$ chmod 555 /etc/profile

o 打開profile文件（本人使用emacs進行編輯，讀者也可以使用vi、vim等，在此不再贅述）：

$ emacs /etc/profile

o 往profile中修改和添加環境變量：

將以下五行添加到文件中，ACE_ROOT為ACE源碼目錄，本文用到的目錄是/usr/share/ace：

ACE_ROOT=/usr/share/ace
export ACE_ROOT

LD_LIBRARY_PATH=$ACE_ROOT/ace:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH

# export PATH=$ACE_ROOT/ace:$PATH

這個操作等同于在VS下修改庫文件目錄，我是直接修改了PATH變量的：

PATH=/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:$ACE_ROOT/ace:$PATH

o 執行/etc/profile

$ /etc/profile

執行修改后有可能需要重啟cygwin，可使用下面的命令查看ACE_ROOT設置是否正確：

$ echo $ACE_ROOT

2. 創建若干文件：

o 在$ACE_ROOT/ace 文件夾中創建名為 config.h 的文件，并加入以下內容后保存關閉：

#include "ace/config-cygwin32.h"

o 在$ACE_ROOT/include/makeinclude 文件夾中創建名為 platform_macros.GNU 的文件，并加入以下內容保存關閉：

include $(ACE_ROOT)/include/makeinclude/platform_cygwin32.GNU

3. 編譯ACE：

$ cd $ACE_ROOT/ace
$ make

大概會花掉十幾分鐘時間吧。

4. 測試ACE：

$ cd $ACE_ROOT/tests
$ make

大概又會花掉十幾分鐘時間吧。

接下來就可以使用perl腳本完成所有測試，我沒有使用過perl，臨時安裝了一下。

$ perl run_test.pl

這個腳本在我一位同事的機器上跑了很久（十幾分鐘 or 幾十分鐘？），不幸的是，Windows竟然拋出了一個內存讀寫錯誤，更加不幸的是，我現在沒有能力去確定。

結果周末后面的時間又花在熟悉EMacs上了，還沒有看ACE的代碼，只有下周才能看了。

-----------------------結束-----------------------

這種小學生的東西拿出來講確實是很難為情的，然而，于我現在卻又算是極大的一個收獲。真等我熟悉了其中的很多內容，又未必會再有耐心說了。所以還是記錄一下，既是鼓勵，也是督促。

晚上睡覺之前翻了一下《ACE程序員指南：網絡與系統編程的實用設計模式》，發現里面2.3節也講到了怎么安裝。

在一個稍微上規模（怎么也有幾十個類吧）的C++程序中，繼承和組合的使用比比皆是。雖然GoF提出了OOD的兩個原則，第二個謂之『優先使用對象組合，而不是繼承』，但這絕不意味著不使用繼承，正因如此，第一個原則才是『針對接口編程，而不是針對實現編程』，這兩個原則清楚的表達了軟件工程中『低耦合』的思想。

模板方法（Template Method）的意圖正是『定義一個操作中的算法的框架，而將一些步驟延遲到子類中』。

注意，這里有個關鍵詞『一些』，既然是『一些』，就意味著父類的的接口中已經實現了『一些』步驟，否則，父類便只提供了抽象接口。

這一情況是我們在編碼時時常遇到的，父類實現了部分算法中的通用行為，子類根據自己的需求可對其進行必要擴充。

class CBase
{
public:
    // Default done
    virtual void Operation(void)
    {
        ...
    }
};

class CDerive :
    public CBase
{
public:
    virtual void Operation(void)
    {
        switch( ... )
        {
        case A: ...
        case B: ...
        case c: ...
        default:
            CBase::Operation();
        }
    }
};

因為對父類的不了解或是對子類的太了解，你以為CDerive::Operation()做了足夠多，不需要CBase::Operation()，但實際上仍然需要的情況總在發生。

換一種方式，把Operation()作為模板方法，把DoOperation()作為可擴展的接口提供給子類實現：

class CBase
{
public:
    void SetFocus(void) { ... }
    void ResetFocus(void) { ... }
    // Call by user
    void Operation(void)
    {
        SetFocus();
        DoOperation();
        ResetFocus();
    }
    // Default done
    virtual void DoOperation(void) = 0;
};

class CDerive :
    public CBase
{
public:
    virtual void DoOperation(void)
    {
        ...
    }
};

模板方法只是提供了一個簡單的封裝技巧，當然不是所有的虛接口都這么寫:)。

更多內容請移步我的個人主頁。

VS2005下使用VC，部分斷點無效，顯示『當前不會命中斷點。還沒有為該文檔加載任何符號』。

試過以下一些方法：

1、無效斷點所在的項目和啟動項目的設置：項目->屬性->配置屬性->C/C++->常規->調試信息格式，這里不能為『禁用』；

2、項目->屬性->配置屬性->鏈接器->調試->生成調試信息，這里設為『是』；

3、C/C++->優化->優化選擇『禁用』；

4、刪除解決方案下的.ncb文件；

5、工具->選項->調試->『要求源文件與原始版本完成匹配』去掉勾；

6、最后在上述設置的情況下，重新編譯整個解決方案；

7、回過頭來，發現原來是一段不會被執行到的代碼……

本文最早發布于我的個人主頁

一般的RPG游戲中，玩家角色、NPC、物品、場景等一般都具有為數眾多的各種屬性，使用C++編碼時，很容易考慮設計成為大量的成員變量和相應的存取函數：

乍一看，非常清晰明了。在一個稍顯復雜的項目中，想記住、甚至找到每一個屬性是非常難的，況且除了屬性，還有大量的邏輯處理，甚至是不同項目間的數據交互，比如將屬性的數據庫存取。這么做的缺點大致有這么幾點：

1. 屬性沒有明確分門別類，尤其在多人協作、多模塊編寫時，往往上面一批、下面一批，甚至有重復屬性、廢棄屬性，難于管理和把握；

2. 對于數據庫存取，需要寫單獨的存取接口，而且一旦屬性有增減、修改，存取接口要隨之修改；

3. 通過接口函數進行簡單的屬性存取面臨大量的堆棧保存，即使使用內聯或宏定義，也是治標不治本。

針對上述問題，我的思路也比較簡單：對基本類型數據進行二次封裝。

private:
    tagDBAttrs    m_DBAttrs;
    string        m_strA;
    CObject*      m_pObjB;
    CShape*       m_pShapeC;
    ...
}; 

之所以提到基本類型數據，主要緣于基本類型構成的結構可以通過sizeof運算符直接確定，而像類對象等組合類型，其深拷貝、賦值、操作及賦值等邏輯則較為復雜，一般無法統一處理。

以上面的tagDBAttrs為例，對于基本類型數據處理具有非常大的優勢，尤其在數據整體存取時，此外，增減基本類型屬性也比較簡單，而且不需要重寫Get/Set接口，同時方便了對屬性的分門別類處理。

此處順便談談關于開發中的一些雜的體會。

對于工作不久的同學而言，拿到一個任務有可能出現以下兩種情況：

1. 以快速開發為重，前期進展較快，在小型模塊開發中順風順水，但在面對復雜任務時，因為對前期設計重視不足，后期會不斷調整代碼，甚至在基本功能開發結束后，因為邏輯架構問題，導致bug隱患較多較深，容易陷入泥沼，痛苦掙扎；

2. 隨時隨處追求代碼結構的優美和執行效率的優化，精益求精，往往在前期設計上花費過多的心思，以達到較合理的邏輯結構，甚至拖延整個項目的開發進度，這種同學一般說來，代碼質量較高，后期bug較少。

其實，上面說的就是我自己，我剛開始工作的時候，上面給我一個編寫獨立工具的任務，當時急于表現，缺乏項目實戰經驗，為編碼而編碼，邏輯結構不注重擴展性，設計不合理，在進行到后期時，面對出現的新需求無法應對，導致最后推到重來。

后來，慢慢接受了注重前期設計的觀念，更因為自己的完美情結和代碼潔癖，不僅經常調整自己編碼中不優美的片段，甚至越俎代庖去修改其他同事的代碼，追求處處的高效，耗費大量時間精力，難以自拔。

在任何一個項目中，都有輕重主次之分，也就是所謂的『8020原則』，關于『8020原則』怎么理解都行，我的理解就是，每個項目中的效率瓶頸是20%的核心代碼，80%的時間和工作重心應該放到這20%的核心代碼上。放到一個小的模塊中也是這樣，應該確定工作重心，在開發進度的限制下，對核心代碼精益求精，對非效率瓶頸可以適當減少側重。

對于新人，最難的就是從整體的高度確定20%的工作重心，這主要依賴于自身素質的提高和開發經驗的積累。而對需求深入細致的分析和對邏輯精益求精的設計本身可以訓練一個人分析問題、解決問題的能力。

總結一下的話，也正是我們項目組歷來所倡導和堅持的：

1. 精益求精；

不知道Singleton算不算用的最多的，平時用的時候，往往都是直接敲下面一段：

State模式對應到C++的多態特性。

State模式適用較廣，這兒給出比較常見易懂的三種情況：

1. 當怪物在面對不同職業和特性的玩家時對應不同的AI處理和技能釋放：

或者使用分支結構：

閱讀全文

因站點遷移。請訂閱本博的朋友將RSS修改為http://feeds.feedburner.com/yulefox

個人主頁地址：http://www.yulefox.com

之所以要寫這個東西，是因為由最近發生的騰訊競業禁止案發散思維了。借機反思一下員工對企業認同的源與流。

之所以要寫Google，Google是我的夢，正像我當初在一份簡歷中寫道的：

Game is my interest, so I like developing my game; Google is my life, so I love enjoying my life.

我的工作、學習、生活離不開Google：My indispensable tools: Gmail, G.cn, Code, iGoogle, Picasa, Reader, Talk, Notebook, Map, Calendar, Documents, Google Pinyin, Chrome, etc.

不煽情了，坊間流傳的最多的就是富有傳奇色彩的Google的工作環境和待遇，下圖可以說明很多問題了：

閱讀全文……

現在每天的工作主要是為了滿足項目需求和進度而不停的思考、敲鍵盤。有時候也確實需要抽點時間來思考思考那些看上去用不到的一些東西，又想起了Fibonacci數。

之前曾經三次寫過Fibonacci數：2007年4月的我的Fibonacci數列，2007年12月的也說說級數求和(1+2+3…N)和其他，2008年5月的動態規劃算法，但給出的都不是非常優的算法。

上次回去把同學借的《編程之美》偷過來還沒怎么看，晚上翻了一下，看到有講Fibonacci數，想起來Knuth的The Art of Computer Programming Vol.1也講過，覺得有必要對Fibonacci數做個了斷。

誠如Knuth在The Art of Computer Programming Vol.1所述，Fibonacci是中世紀以來歐洲最偉大的數學家，他關于al-Khwarizmi的研究催生了算法（algorithm）一詞。

閱讀全文

看到這些，我又激動了，數學之美，不正是美在這些地方嗎？我們不是要做數學家，但這并不妨礙我們站在門口向里張望……