道，深藏不露，难以理解。
Archive for the ‘杂类’ Category.
这段时间花了很多时间在修改BUG上。有一些BUG可以看得出是以前的人在实现时仓促留下的。有时我们自己在巨大的时间压力之下也很容易会留下这种“缺陷”（可能当时还不是BUG），但是自己心里很清楚，这个地方在以后极容易出BUG。
实现功能往往是最容易的，保持代码的“干净”，架构的“纯洁”才是不容易做到的。
想想在一个版本反复的被测试打回，已经Delay了多日后，当修改一个BUG时，明明需要对架构进行一次重构，增加一个抽象。可又有多少人还会这样“大动干戈”，或者就把已有的代码COPY一下，再改一改就算了。越是在发版本的前夕，越是容易埋下“地雷”，留下隐患。所以我总是最担心最后改BUG那个阶段。
最近需要在产品中用到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的工具定位了一下很快找到了原因。
自己哪怕写好玩的代码，如果可以，最好也搞一个版本控制工具把它受控了。(除非你写的是hello world那么简单的，那就没必要了)。一个是方便备份，保存。另一个很重要的原因是可以回溯。在写代码时，有时你会心血来潮的发现现有的方案不好，于是“呯呯碰碰”一阵大改，最后发现还不如原来，这时如果没有版本控制工具，那就只能哭了。
我现在一般自己写点什么代码，一定是先搭版本控制环境，先把代码受控。然后列个开发计划，一小步一小步的多设点里程碑(其实也就是能编译，到这步要完成的功能都能用)。一量到达某个里程碑了，就在源码主干上打TAB并标明相应的里程碑。开始大的重构前，也打上TAG，如果效果不理想，随时可以回退。
原始发布日期：2007年08月28日 星期二 22:41
Subtitle adjustor version 1.1
修正了两个BUG，一个是在整秒时写出时间会出错。另一个是不能打开文件名中含有中文的文件BUG。
原始发布日期：2007年08月12日 星期日 18:06
我比较喜欢从用emule下西片看，一般是下下来了，再到网上找字幕(E文水平不行)。最郁闷的是有时下的片子不是很热门，关下载就花了很长的时间(最长试过几个月的)，结果下下来了还找不到适合的字幕，气坏人。
原始发布日期：2007年06月5日 星期二 22:24
因为有网友要求提供中文版。但我又不想同时维护两套代码。所以就索性按照我自己写的文章(http://lunatic.bokee.com/6153138.html)中的方法实现了多国语言动态支持。只是抽取文字资源，和修改UI部分支持UNICODE比较想象中还要乏味和麻烦的多。
相应的源码和更新列表，我全部列在了原来的文章(http://lunatic.bokee.com/6073835.html)中，便于跟踪管理。
原始发布日期：2007年03月11日 星期日 15:09
FMC中的CMemoryState 类。
这个类非常有用，它可以给当前内存照个快照，并可以将内存快照进行比对。如果你想确认程序在某个时段中分配的内存全部被正确的释放，那可以在这个时段开始时照个快照，结束后再照一个。如果这个两个快照不一样，说明这个时段中有内存泄漏了。
原始发布日期：2007年03月10日 星期六 16:06
该软件的目的及作用请参见（http://lunatic.bokee.com/6153131.html）
软件的执行程序和源代码（http://lunatic.bokee.com/6153138.html）
执行程序解压后只有一个可执行文件（纯绿色天然软件），最好是将这个文件单独置于一个目录中，第一次运行后，它会自己生成配置文件和相应的目录。