搬家

今天公司搬家，恰逢格美离境，余孽尚在，雨下个不停，给搬迁工作带来了不少麻烦。上午我和杨煦、陈拓琳前往科技局做项目答辩，晚上我还要回深圳看望女友...

真是繁忙的一天啊。

捕捉事件并传递处理的过程

今天和叶振华讨论了一下他在XLIB_D（脚本支撑库）中关于捕捉并处理事件的过程，和我最早的版本（简单事件捕捉）不同，他引入了子事件的概念，因此组成了一个事件树，如下：

                [战斗情况变化]
                      |
           /----------+----------\
           [战斗结束] [新一轮战斗]
                |
      /---------+----------\
    [攻击方胜利] [防守方胜利]

如果脚本捕捉[攻击方胜利]事件，[战斗结束]事件，那么当系统遇到了具体的[防守方胜利]事件，则将发生[战斗结束]事件（其中传递的参数说明了这是防守防守方胜利），因为没有捕捉子事件，所以就传递给父事件。那么，如果在处理[攻击方胜利]事件时，还希望执行[战斗结束]事件中的一些代码呢？我认为只要在[攻击方胜利]的脚本中的合适位置简单的调用[战斗结束]事件的处理脚本就可以了。

感觉这个思路是很不错的，虽然支撑系统复杂了许多，但是的确有利于脚本简单轻易的捕捉它所关心的事件并安插处理代码，在新项目中可以继承这个思路，只要重构一下实现代码就可以了。

如果单条记录小，数据库的性能能否提高？

记录小速度快是显然的，但是我要讨论的并不是泛例，而是具体的日志系统。

游戏运行中会产生大量的日志，为了便于管理，日志越详细越好，但是日志量太大，又会影响数据库的性能，所以有必要在两者之间达成一个最佳结合点。

问道一个服务器每天产生近千万条的日志（已经过滤了一部分不重要的日志），当服务器日志超过四千万条时数据库的性能会有比较明显的下降，所以数据库大概只能记录最近三天的用户日志。但是我需要记录更长的时间，比如7天甚至一个月。

服务器的硬件配置已经足够好了，只能从软件角度考虑解决方案。

可以做的事情是，把日志记录的字符串字段转为整数类型，以此减小记录的长度。这样做肯定可以减少数据库的大小，但是能不能带来更好地性能？也就是记录超过四千万条以后，能不能对性能没有什么太大的影响？如果对性能没有明显帮助，那么磁盘空间本身并不值得珍惜。

日志系统主要是进行插入操作，我认为插入记录本身所需要的时间不应该受到已有记录数量的限制（简单的申请PAGE就可以了，申请PAGE的时间显然不应该随着库变大而有什么明显变化），关键时间是花在索引上了。如果记录的索引变小，那么B树变小，相同的内存缓存可以保留更多的B树节点，这样可以使得查找、建立索引的时间变少。但是，如果记录比原先缩小一倍的话，也许B树的I/O操作仅仅多了一次，如果是这样，小记录能获得明显的效率提升么？

需要测试才能有结果。

竞争与服务质量

今天在天涯上看到一帖，如下：

『IT视界』 [大话IT]神舟电脑，你对得起我的血汗钱吗？

作者：程序员or民工 提交日期：2006-7-9 15:30:00

我两年前买了个神舟P203C笔记本，当时是这样想的：1，我从来都只买国货；2，我没有多少钱（告诫兄弟们，没钱别玩笔记本，丢人）；3，神州一年包换！！！
刚买没有多久(两个月吧)，鼠标开始忽悠我了，不听使唤了，必须重起电脑才行！汗！！！我当时忙赶项目，也就没有去管它了。快到一年的时候，键盘上的"{"不能使用了，不停的自动按键，我是程序员呢，这个键不能用怎么行？于是我和他们的售后联系，叫我周一送修(他们的维修站是双休的，周六、日维修站没有人！！！)。
星期一我一大早就赶到他们的售后服务部，他们说是我人为损坏，我操！！！换键盘要200元！我换个毛啊，他妈的外接键盘都不能用，我操！！！没有办法，我认了，回到公司，写了个程序，用低级键盘钩子把"{"建换到"F9"键，将就着用了。
可是今天键盘上的"-"键又不能用了(也是不停的自动按键)！！！我操！！！
神舟，你他们别提什么民族工业了，你就是垃圾！！！以后大家别买神舟！！！

--------------------------------------------------------------------------------------------------------------------------------
对神舟并无什么评价，毕竟没有打过交道。不过某些设备供应商无法保障售后服务这类事情是常有听闻，遇到的人也不少。

那么，如何提高售后服务？改善商家经营理念？提高监管力度？这一切当然有作用，但是我想：某类产品（不论是软件抑或硬件）在当前的质量条件下（也就是该产品供应商的质量保障体系的成果），故障率符合统计学上的分布，不妨架设为p（单位产品故障率）。维修一个故障的平均成本如果为c（这个成本可能包括客服人员，技术支持，配件更换，物流），那么保证解决单位产品故障的成本则为c*p。

所以，如果需要提供优质的售后服务，前提就是必须在销售中考虑这个成本即c*p，如果基于市场竞争的原因从而在销售定价时无视c*p，结果就是不可能提供优质的售后服务。

简单说来，优质的服务并不能单纯的通过竞争获得，竞争是一种淘汰手段而非优化手段，如果市场导向为低廉的成本，那么竞争将导致最低价格者生存，这点恰恰和优质服务相反；如果市场导向为其他因素，那么则会淘汰最不符合相应因素的选手。

或曰：如果供应商不提供好的服务，那么就会被购买者所拒绝，最终被淘汰、逐出市场，那么剩下的不就是服务质量较高的吗？我不同意这样的分析方法，因为这里面有太多的推论，而且有许多尚未验证的假设（如不提供好服务就会被消费者拒绝），事实上，如果主流消费者更青睐低价，那么，试图提供好的服务的供应商一开始就死亡了，因为它的高价本身就是和市场选择背道而驰的。

诚信也是相同的道理，如果竞争环境决定道德沦丧的人可以获得更大的利益，那么必然迫使越来越多的人丢弃道德。教育可以改善诚信缺失的问题，但是我认为教育的目的并不是赋予所有人自律的诚信之心（历代王朝不正是这样做的么？），而是赋予大部分人鄙夷缺乏诚信者的意识，也就是说，去改变这个环境的竞争规则。

回到刚才的话题，企业在一个价格竞争的市场中需要生存，则需要降低成本，降低成本的方法之一就是加大质量保证的投入，看起来成本提高了，实际上，质量提高以后将会降低p，从而降低c*p，找到曲线的驻点，就是最佳的质量成本投入点。不要丢弃质量保证，也不要盲目的在质量上进行无限制的投入。

文王何以王天下

想必初中生都可以回答这个问题：纣王失道寡助，文王反之。事实上书本上从来都是这么说的，这是一个简易的泛理论的答案。

史书上有言：文王实施各种良政，如“有亡荒阅”，低税政策，开放山林湖泊，废除酷刑，最终团结了周内部的各种力量，影响了其他方国和商王朝直接统治下的部分贵族和平民，最终商益弱，周益强，于是乃有天下。

然而，真是这么简单么？

即使是一个公司，小到只有几十人，如果你为员工着想，不去做其他公司那些令员工厌烦的事情，是不是就能团结一致，专心向上，最终脱颖而出呢？当然不见得，至少我这里就可为佐证。为何如此？要知道即便是至亲之人如父母、子女、兄弟，为你尽心着想，也可能落得一身埋怨，抗拒重重。比如小时候家长督促你做作业，你心中厌烦之极，只恨父母未经自己允许就强迫自己来这人世间。

又比如项目中，你苛求细节，想把项目做的尽善尽美，有人觉得你吹毛求疵；你培训辅导，希望大家能够迅速成长，以便作出更好的作品，有人觉得你自以为是；你调和矛盾，避免激化，以便彼此能够精诚合作，减少内耗，有人觉得你是非不分，赏罚不明。便有一颗赤心，又有何用？或曰，你水平太差，手腕太少，所以众戚不服，诚然！

所以说来，文王能王天下，岂是一句简单的“得道多助”能概括的来的？多助固然需要诚心（道），也需要各种方法（术），方法并非纸面上简单描述可说得清楚的，毕竟时势，人物皆不相同，哪有定理可循？若有，天下文王多矣。

又出现了刷钱的BUG

早晨还在睡梦中，就听空空找徐超，有玩家举报有人刷钱，当时就是心中一凉，不过料想着急也是无用，于是该干什么还干什么，继续睡觉。

中午起来，徐超确认了刷钱BUG的存在，行为日志中记录某个角色流出数亿游戏币，没有找到什么端倪。我再查阅了行为日志，异常日志，登录日志，确认了不是通过回档，任务执行故障造成的刷钱，唯一能够入手的地方只有监视玩家的指令，然而为了赶进度，服务器端的录像功能迟迟未做，这个时候只有抓瞎。

在屋子里来回走了三圈，下定决心，先补功能，再查问题。打电话找到王呈，叶振华，下午跑到公司接头，正商议实施方案时，空空打电话过来，说那个玩家飘上线来，在线监听发现他似乎在完成了某个任务后，然后卖出东西金钱就会突然飚升。我想想觉的这样似乎不可能，毕竟卖出道具和任务并没有任何关联，于是让空空想办法截一下图，看看是什么任务。挂了电话，继续讨论，还没说上三分钟，空空又打电话来，说查到玩家买入一个道具，再卖出9727个道具，于是就获得了相应的金钱。

听到这里，我觉得简直就是不可思议 - 不可思议的并非会不会有这样的BUG，而是 - 且先不表，我翻到卖出道具的代码仔细看看，果然，卖出不可叠加的道具没有判断数量，而是简单的析构道具，然后按照客户端发送过来的数量计算金钱...... @(#*!@#&(!&@#

总之，这是问道亘古以来就有的BUG，而且服务器端到客户端的通讯数据一直都是明文，没有刻意加密，使用WPE甚至是FPE都可以轻松的利用这个BUG，但是似乎开放服务一年来，这个问题从来没有泛滥。我想，唯一能解释的是：发现这个BUG的那些人耐心极好，直到今天，才跳出了一个愣头青。

问题侥幸被秒杀了，但是服务器端的录像究竟做还是不做，当然要做，而且要尽快做好 - 有寒号鸟为先例。

任何一个BUG都永远不会是最后一个BUG。

也许是个值得纪念的日子?

虽然blog热门了很久，但是我从来不曾打算涉足这个新（可能已经过时了）领域，我对新事物总是缺乏兴趣，除非有足够的理由。

然而，这段时间有了一个充分的理由让我去接受blog。在经历了一段艰难的寻觅软件技术人才的过程后，陈拓琳说写blog可能会结交更多志同道合之士。基于这么一个功利的目的，我开始尝试blog。

看过几个ISP提供的blog的空间，都让我无法决定落脚，要么觉得网站可能某一天会蒸发，要么就是界面花哨让我觉得难以使用，直到今天无意中从天涯看到百度提供的空间，它让我没有挑剔的理由，百度做的很不错。

ps：这是最早发布在baidu空间的，后来搬迁到了blogspot。