道，深藏不露，难以理解。
Archive for the ‘技术类’ Category.
这段时间花了很多时间在修改BUG上。有一些BUG可以看得出是以前的人在实现时仓促留下的。有时我们自己在巨大的时间压力之下也很容易会留下这种“缺陷”（可能当时还不是BUG），但是自己心里很清楚，这个地方在以后极容易出BUG。
实现功能往往是最容易的，保持代码的“干净”，架构的“纯洁”才是不容易做到的。
想想在一个版本反复的被测试打回，已经Delay了多日后，当修改一个BUG时，明明需要对架构进行一次重构，增加一个抽象。可又有多少人还会这样“大动干戈”，或者就把已有的代码COPY一下，再改一改就算了。越是在发版本的前夕，越是容易埋下“地雷”，留下隐患。所以我总是最担心最后改BUG那个阶段。
如果需要在用户改变窗口大小时进行限制。比如限制窗口的最小尺寸/最大尺寸，应该处理窗口的WM_GETMINMAXINFO消息。具体的使用方法请参考MSDN。
如果在改变大小时要实现特殊的逻辑，比如像VIM编辑器，在改变窗口的高度时总是以行高为单位，以避免窗口会出现半行文字。这个可以处理窗口的WM_WINDOWPOSCHANGING消息。这个事件在真正改变窗口大小之前发送，修改其中LPWINDOWPOS中的cy和cx值就可以限制窗口大小。
上面的这些处理千万不要放在WM_SIZE中，虽然也可以实现但会导致窗口出现闪烁。
如果还需要知道用户是通过拖动窗口哪个边界来改变窗口的大小。比如说如果当前窗口只显示了一个大图的一小部分，如果用户拖动窗口上边框来改变窗口的大小，这时应保持窗口下部显示内容相对不变，同样如果用户拖动窗口的左边框来改变窗口的大小，应该保持窗口右边的显示区域不变。不过我发现大多数软件都没有处理这个逻辑，比如PhotoShop。它总是保持显示内容左上角的位置不变，这样如果中在显示大图的一部分时拖动窗口的左边框、上边框或是左上角，整个显示的内容会抖动很不爽。
在改变大小时要感知用户是拖动了窗口的哪个边框来改变大小的，可以处理窗口的WM_SIZING消息，该消息的wParam参数指明了窗口的哪一条边或哪一角的位置改变了。（注意：WM_SIZING只在用户交互式的改变窗口大小时才触发，一些间接的改变大小的行为：如窗口复原，平铺窗口，只会触发WM_WINDOWPOSCHANGING。）
最近需要在产品中用到windows平台的管道通讯机制，因此对管道进行了一番考察，将相关的信息记录如下（只记录要点，如何使用的代码请看MSDN上的例子）：
管道是windows平台下的一种RPC机制，不但支持同机器的，也支持跨机器的访问。总之一句话，linux下的管道机制，直观好用，功能强大。windows的管道使用相对复杂，有一些“出乎意料”的地方。
这里对各种时间值的格式和相互转换做了个总结。非常有用，转一下做个记号。
原文（http://blogs.msdn.com/b/oldnewthing/archive/2003/09/05/54806.aspx）。
前两天下了份chrome的源代想编译来看看。根据它的构建指引先要把VS2005升级到SP1。如是花了一下午替机器上的VS2005打了SP1，中途因开的东西太多，磁盘空间不够，失败了两次，第三次才打成功。
第二天要调一个服务器程序上的bug，如是我在本机build了一个服务器程序，上传到外网一跑，崩了。偶滴个神，最最可怕的事情发生了。
赶快查原因，因为没怎么动代码，我用debug的工具定位了一下很快找到了原因。
促使程序员对架构和设计进行思考
这样的编码规范就很少见了，呵呵。其实这些内容是不是应该放在编码规范当中也是有争议的。不过我个人认为，不但应该放在编码规范中，而且应该是编码规范中最重要的部分。编码规范的本质和作用是什么，就是让代码更具弹性，更具可维护性。而架构设计对这个方面的影响力是最大的，没有理由不在编码规范中进行说明和规定。如果说命名规范或是其他的某种具体实践方法是“地方法规”，那么设计原则就是“宪法”。“宪法”决定了整个国家的法律框架。
如果不能在设计原则上达成统一和一致，即便是大家严格的遵守上述两个层面的编码规范，写出来的代码也极有可能是“貌合神离”。
好的编码习惯一定要尽早的养成，就象小孩要从小养成良好的生活习惯一样。好的生活学习习惯会对小孩的一生产生巨大的影响，编码规范对于开发人员和开发团队来说，效果也一样。因此对于一个开发团队来说，在一开始就确立一个好的编码规范，并且所有人都严格执行，比什么都重要。等到发现代码杂乱无章，无法很好的理解各自的代码时，再来推行一个编码规范就晚了，要么矫正的成本太高，要么就很难真正的推行下去。
那么一个什么样的编码规范才算是一个好的编码规范呢？一个好的编码规范应该包含有哪些内容，有哪些特点呢？
有时为了快速的把代码的架子搭起来，并编译通过。会把一些负责具体实现细节的方法先空置。整个代码能编译通过后，再一边调试一边把那些空方法“填”好。
我一般是在这类空方法中加一个注释进行标注， 并让方法直接返回一个错误值。比如返回指针的方法就让它返回NULL，返回BOOL值的方法就让它返回false。有时还会在方法里放一个失败的断言，比如：
BOOL some_function()
{
//PK Not implement yet
assert(false);
return FALSE;
}
自己哪怕写好玩的代码，如果可以，最好也搞一个版本控制工具把它受控了。(除非你写的是hello world那么简单的，那就没必要了)。一个是方便备份，保存。另一个很重要的原因是可以回溯。在写代码时，有时你会心血来潮的发现现有的方案不好，于是“呯呯碰碰”一阵大改，最后发现还不如原来，这时如果没有版本控制工具，那就只能哭了。
我现在一般自己写点什么代码，一定是先搭版本控制环境，先把代码受控。然后列个开发计划，一小步一小步的多设点里程碑(其实也就是能编译，到这步要完成的功能都能用)。一量到达某个里程碑了，就在源码主干上打TAB并标明相应的里程碑。开始大的重构前，也打上TAG，如果效果不理想，随时可以回退。
最后总结一下，要用ACE_CDR类来处理网络数据编解码，首先修改ACE的config.h文件。加上以下行，并重新编译。
#define ACE_ENABLE_SWAP_ON_WRITE #define ACE_LACKS_CDR_ALIGNMENT #define ACE_CDR_IGNORE_ALIGNMENT