最近发现的这个问题也是游戏客户端特有的，它很能说明用于游戏服务器的skynet和用于客户端的ltask在实现侧重点上的不同。
引擎渲染出来的汉字比标称的像素高度矮了不少，想渲染100像素高的汉字，结果只有70+像素左右。我们之前测试使用的中文字体（Windows自带默认字体）没有这个问题。
昨天做内部晋升评审时听到候选人介绍他即将开始的一个项目。大致是我们公司从韩国买过来一个游戏（有全部源码）打算自己运营。该游戏服务器全部用C++编写，使用SQLServer做数据库。我们这个项目，除了需要根据市场做二次开发外，还希望把SQLServer迁移到MySQL上。成本是最主要的原因，如果可以迁移成功，成本将减半甚至更多。该成本差异主要在SQLServer的使用执照费用，以及同等任务所需要的云成本。
我在反复确认了这项工作是否真的有做的价值（从SQLServer改为MySQL）后，讨论了一下具体实施方案。
移植的难点在于该项目大量使用了SQLServer的存储过程。几乎所有的业务逻辑都是人肉写在SQLServer的存储过程中的，大约有20万行。虽然SQLServer的存储过程和MySQL的差异不是特别大，但再靠人一点点重写成本上也不划算。
其实我不是很在意代码的版式，比如到底用空格缩进还是Tab；花括号应该放在行末还是另起一行；以及，当需要用多个单词命名的时候，是用下划线分割还是驼峰。自己写的时候，自然有个习惯，但是项目中如果有多人参与，我也不在意大家各用各的。
毕竟是外在的东西，对代码结构没什么影响。甚至不太影响可读性。反而不同的风格容易区分出作者，阅读的时候更容易追溯到人，甚至比在git上看blame还方便一点。
最近在做新引擎UI模块的工作。汉字字体纹理需要占比较大的一张贴图，考虑到这张贴图只需要用一个通道就够了，所以我决定使用压缩贴图。在手机设备上，GL_COMPRESSED_R11_EAC是一个不错的选择。
EAC是Ericsson提出的对单通道贴图的压缩方案，现已进入OpenGL的官方标准。它通常会结合ETC2一起使用。ETC2负责RGB部分，EAC负责Alpha通道。偶尔也可以单独使用。它会将每个像素解码为[0,2047]的整数，有11bits的精度，故而被称为R11_EAC。不过，我阅读文档后发现，其实有效精度是8bits，一般也是从8bits的原始数据中编码得到的。压缩后，每4*4=16个像素会被编码为64bits，压缩比2:1。用于字体纹理的话，可以节省一半的显存空间。
我期望在产品上线后，可以用的上至少32核的机器。这样，让多核平摊计算负荷就比较重要。单机承载的人数可以不高，但不希望玩家卡在一起特定的操作上。
这里强调的是单机上的并发，而把跑在不同机器的进程会分开考虑。所以，尽量利用共享内存以及单机锁来解决信息交换和状态同步问题。
随之我实现了一个改进方案。一开始就初始化好若干LuaThread，在不同的OSThread中使用独立的Stack空间操作。因为我们的框架只会启动有限的OS线程来跑更多的LuaState，这样做是可行且线程安全的。不过还是有一点小问题。如果用户向LuaState压入并不存在的key(string类型)，修改Lua中stringpool的操作又有线程安全问题了。当然，这个问题还可以用更为复杂的方法规避（比如再给每个线程配置一个独立的state做string合法性校验）。
最近一口气招了5个程序员,在他们没有到岗之前，我不想把自己过多陷入游戏实现的细节上面。所以，除了维护一些前面的代码，陆续发现和修复一些bug外，我计划再完善一些基础设施的设计。这些基础模块暂时可以没有，如果实现好了又可以直接加入现有系统。这样比较利于后面的工作划分。
其中之一是服务器组播的模块。
项目的进展比较缓慢、主要是解决一些琐碎的技术问题，客户端的比较多，服务器这边就是节前的一些bug修改和功能完善。大部分工作都不是我自己在做。由于感到人手不足，小规模私下的做了一点点招聘工作。也算物色到一两个同学可以过来一起干的。好久没做招聘工作了，都不知道怎么开始谈。唉，我们这里条件不算好，要求还多，都不好意思开口。
可写的东西其实也不少。今天挑一点来记录一下。
我的规划大约是这样的：
核心部分仅仅实现了结构化数据在内存中的表达。但储存在内存中的数据还不能直接使用。CAPI虽然实现好了，但性能比较低。我实现的是无锁的数据结构，采用单向链表保存。检索一项属性值都是O(n)的复杂度。这显然是不能在项目中直接使用的。为了提供性能，需要再做一层cache。在Lua虚拟机中，用hash表映射。使得读写数据的速度都降低到O(1)。因为我自己对Lua比较熟悉，所以这步Lua的薄封装还是我自己完成的。实测下来，和原生的Lua表访问差距不到一个数量级(3,4倍左右)，是可以接受的范围。比常规IPC通讯要快的多，也没有异步通讯的负担。以后编写逻辑代码的时候稍微注意一点就好了。
需要额外开发的工作是，要定义一个数据描述的小语言。类似C语言的结构定义。在数据储存中，我没有实现无格式信息的字典类型。map的key都是在结构定义中预先定义好的，内存中存放的是编号。这一是因为实现简单，而是可以实现成无锁的数据结构。再就是数据结构也能严谨一些，减少typo（可以立刻检查到）。
这个想法是大约一个月以前细化的。类似的想法我在97年就有，当时网络并不普及，我为之做了一个单机版的DOS小程序。放在cfido上传播，以及放在个人网站上，有零星的几个用户。
我设想有这样一个工具，可以辅助我阅读英文小说，或是论文。它不应该是一个简单的词典，我不喜欢在阅读时有过多的交互。我希望作为阅读者，只是单方面的输入信息。那么，一个好的工具应该了解我的熟悉的单词领域，知道那些对我陌生的单词。并且明白，如何解释他们我可以明白其含义。
有时候，我只需要一个简单的中英文词汇对应关系；有时候我需要更多的解释。
一个好的辅助工具，能做到，在我需要简单解释的时候，在生词后面打上括号，写上对应的中文词。并在我尚未遗忘之前，同样的词不再注释。对于复杂的词汇，我希望它能排版在同一页的边侧，我第一感觉它应该在的地方。而不是让我费力的移动一下鼠标选中。
这是款我个人比较喜欢的偏计算类的游戏。玩家需要安排5个回合的工厂生产计划。购买机器、扩建仓库、发电。玩家需要支付电力成本，如果人手不够，需要雇佣临时工。偶尔，会因为场地不够扩建厂房。但是游戏只有固定5个回合。结束后，看谁赚到的钱多。当然，固定资产是不折现的。
本文的标题只是一个猜想，并不是我坚信的观点。事实上，我这几年自觉学到的重要东西之一，就是如何在开发过程中分工，如何信任队友开发的组件，如何组织许多人做同一个项目。
可是，如果这是一个骗局呢？那也未尝不是一种可能。
这个世界上我们需要做的软件可能没有太多真正庞大到需要很多人合作才做的出来。需要配置产品经理，需要设计人员，需要前端开发，后端开发等等。
更多时候，你需要很多人一起来完成仅仅是因为别人都这样在做。或者是，你缺乏某方面的专业知识，需要属于这个领域的人。又或者是有些工作很枯燥，你需要一个只是打工的人来帮你完成这些枯燥的你不想干的部分。也可能是你的老板觉得你进度太慢，觉得必须想办法加快进度，他觉得增加人手或许可以……
今天晚上18:00准点去一楼食堂吃饭，结果队伍排到了门口还打了个圈。花了20多分钟才领到口粮，回头一看，队伍并没有减短。看着前后都有同学抱着PSP狩猎MHP3，我有点后悔没把PSP带下来了。
从这几天的经历来看，我们公司食堂的处理能力应该是够的。从17:30到18:45基本能处理完600号人的进食问题。也不能完全怪发放食物的带宽不够，经过一个月的观察，这部分可以优化的余地不大。而且我认为优化的意义也不大。
继续前几天的话题。做梦幻西游服务器优化的事情。以往的代码，定期存盘的工作分两个步骤，把VM里的动态数据序列化，然后把序列化后的数据写盘。这两个步骤，序列化工作并没有独立在单独线程/进程里做，而是放在主线程的。IO部分则在一个独立进程中。
序列化任务是个繁琐的过程。非常耗时（相对于MMORPG这个需要对用户请求快速反应的环境）。当玩家同时在线人数升高时，一个简便的优化方法是把整个序列化任务分步完成，分摊到多个心跳内。这里虽然有一些数据一致性问题，但也有不同的手段解决。
但是，在线人数达到一定后，序列化过程依然会对系统性能造成较大影响。在做定期存盘时，玩家的输入反应速度明显变大。表现得是游戏服务器周期性的卡。为了缓解这一点，我希望改造系统，把序列化任务分离到独立进程去做。
方法倒是很简单，在定期存盘一刻，调用fork，然后在子进程中慢慢的做序列化工作。（可以考虑使用nice）做完后，再把数据交到IO进程写盘。不过鉴于我们前期设计的问题，具体实现中，我需要通过共享内存把序列化结果交还父进程，由父进程送去IO进程。
因为fork会产生一个内存快照，所以甚至没有数据一致性问题。这应该是一个网络游戏用到的常见模式。
可问题就出在于，经过历史变迁，我们的服务器已经使用了多线程，这使得fork子进程的做法变的不那么可靠，需要自己推敲一下。
在历史工程上修补是件麻烦的事情。
IO负荷过重最终怎样影响到游戏服务的性能，这个暂时不过于深入探讨。我这两天主要是分析以有的系统结构，并想一下改进方案。
梦幻西游在去年出了个新版本，在这个版本中，采用了3d技术渲染人物。我参加过部分的技术讨论。总的来说，对于公司的关键产品，是以稳定性为第一。所以不希望对程序做大改动。最好以独立扩充的模块为主。所以最终采用的技术是用3d技术渲染成图片，再依靠旧的程序框架跑起来。
采用3d渲染，主要是为了解决人物换装时的图片资源组合爆炸问题。当然还有更绚的特效等。
最近，梦幻西游的项目经理提出，新的版本性能依旧有些问题。当老的版本可以同时打开5个客户端时，新的版本只能开两个。允许用户同时开多个客户端，对梦幻西游这款产品非常重要。我最近几天就开始着力解决这个优化问题。
既然好多朋友感兴趣，我就继续写写我对IM服务的看法。
我认为，任何支持XMPP协议的IM，都可以利用XMPP的s2s服务做出一个独立于所有IM提供商的独立的群服务出来。
我想这个形式应该是这样的：
用户只需要加一个叫群号@groupchat.foobar的好友。由groupchat.foobar服务器提供XMPPs2s的协议。服务器指派一个机器人管理这个指定群。然后由这个聊天机器人来负责转发信息就好了。
这有点像wow做团队DKP工具一样。
可以设计一个人阅读方便的文本协议，不通过特定的client来解析，就能模拟出很好的用户体验的群聊服务。如果配上特定的client，用户体验会更好。
关键在于，这个服务可以做的很开放，不限制是由什么IM来使用。只要你用的IM服务支持XMPP即可。把qq群转移到这个上面也不会是太难的事情。而且这个群聊服务（groupchat.foobar）谁都可以做，并可以共存。技术牛的可以不限制群的人数，承载能力差的可以限制用户。有能力的可以提供web界面的聊天记录备查。
IM协议只有到了互联互通那天，才能更好的激发程序员们的创造力，给用户更好的IM体验。
我一直认为，做一家大的互联网企业是应该有更高的追求的。所以我喜爱google，他们以让信息被更高效的获取为己任。而作为中国IM最大提供商的qq呢？我想，更方便的让中国互联网用户相互联络应该是他们最高的追求吧。但是，qq没有这个意识，这是让我最为失望的地方。
美术同学给我们的游戏做了段片头视频，正要加到产品中去时，才发现我们的引擎居然没有提供视频播放的功能。我想这个东西开源库一大堆，那做起来还不是小菜一碟。可没想到还是折腾了一整天才搞定。
这个工作和前段实现的zipfs有相似之处，所以做起来也很快。不过前面没仔细测试。今天比较闲，就设计了几组复杂的测试数据，感觉覆盖了各种边界情况。一测试果然发现了Bug。
这个Bug有点启发意义，所以在解决掉之后，决定记录一下。
我们的项目的Windows版本是用MinGW开发的。当程序在Windows下挂掉后，固然可以用gdb调试，看到调用栈。但有些时候还是不够方便。
比如说今天，我们写的模型编辑器发到广州美术同事使用时，就出了问题。3d程序在不同显卡环境下的确容易出故障，异地调试程序非常困难。这个时候，多么想看看调用栈啊。
今天检查svn仓库，发现又有同学没按规定提交包含汉字的代码。我们规律，所有源文件中包含的汉字必须使用UTF-8编码方式，而不能使用GBK。
总这么人工检查也不是个事。所以我想写一个svn的钩子，在提交前检查。在仓库的hooks/pre-commit.teml加一行检查脚本应该就可以了。
拿到机器后，很是一阵折腾，把Linux下驱动装好。果然可以查询到Opengl2.0，不过支持的不算太多，或者说我们的程序没有彻底的测试，有些写的不规范的地方，不是那么顺利的可以跑起来。还需要慢慢改。
Windows下是彻底看不见Opengl了。有点不甘心。
一切阅读都是误读
爱不释手，是我第一次读完后的心境。完整的经历了人生中第一个成功的大的软件项目后，我有许多感慨。不少东西知道怎么做对，怎样做不对，但是要一条条写下来，却不知道怎么总结。这本书说出了许多我想说，而不知道该怎么说的道理。
接下来的日子，我在公司做过好几次技术培训，课题都是以这本书中的某个或某几个观点，结合自己的经历展开的。对于信任我的同学，我总是把这本书列在给他们开的书单的第一本。
不同的人从不同的角度用不同的方式，阐述相同的道理。其中细微的差异，是需要读者有了许多许多的经历后，才能体会的。比如，在《程序员修炼之道》中花了六页分析DRY-Don'tRepeatYourself原则；而在《Unix编程艺术》中把它称作SPOT-SinglePointofTruth，大约用了一页半的篇幅。他们真是是想表达完全一致的理念吗？我看未必。所以，作为读者，同样会有许许多多的想法。随着编程经历的越来越多，思考次数的增加，重新和这些前辈的思想相印证，也是一件乐事。
我们以为理解了作者，其实是误解。但我们将再一次理解编程。
这不是个新问题了。前两月开始，自从我的一台Ubuntu机器某次更新内核到2.6.28-13后，就无法正确引导。而只能引导旧的2.6.28-11。
这两天内核又升级到2.6.28-14问题依旧。
启动时显示：
Error13:Invalidorunsupportedexecutableformat
这两天完成一个新需求，需要维护以前一个同事写的代码。
要在以前设计的接口基础上增加新功能，我觉得是件非常违背我的美学的事情。如果就这么干下去，我会做噩梦的。所以一咬牙决定重构。好在是比较底层的代码，只有中间层调用这些接口，和上层无关。
大约删除了2000多行代码，重写加上新实现的功能，用了900行左右。接口数量，加上新加的接口，总数减少到原来的一半。
另外修改了调用这些接口的大约30个源文件。昨天晚上完成的时候已经是一点，似乎都眼冒金星了，才把整个工程编译通过。
今天战战兢兢的测试两天闷头赶出来的战果，上午居然一点问题都没有，让我心虚的很。下午找到一个bug，稍微安心了点。晚上解决掉提交了。终于舒心了许多。
《TheElementsofProgrammingStyle》是一本很古老的书。尽管Fortran我们不太使用，尽管新奇的语言层出不穷，但这些，30年的岁月依旧无法掩盖其中的真知灼见。
英文版的google一下到处有，云风试着摘译几条。
周末。
玩了一下ActionScript。因为感觉做一些简单的需要长连接的互联网应用，flash是一个不错的选择。在大多数情况下，比要求用户安装一个客户端要人性。（当然，和要求用户为浏览器安装一个莫名其妙的ActiveX控件相比，让用户自己决定是否下载独立客户端要友好的多）
因为，虽然Flash大多数情况下作为一个浏览器插件（在Windows下是一个ActiveX控件）的形式存在，但其安全性比之许多绿霸之流的流氓软件还是值得信任的。
今年二月份拿到这本书的电子稿时，还不是现在这个名字。
《程序员的自我修养》这个名字听起来比原来的那个名字感觉好一些，但又让人感觉有点不知所谓。还是副标题直接：《链接、装载与库》。我更愿意接受这样的一个名字，有如那本多年前读过的英文经典：《Linkers&Loaders》。
办公室里我有两台桌面机，一台装的Windows，另一台装的freeBSD和Ubuntu双系统。上班的时候，两台机器我都开着，跑freeBSD的时候比较多。
在freeBSD下，我很少进X。主要是写服务器程序，或者是用来ssh到别的服务器上做管理。纯文本模式很清爽，速度很快，让人心情愉快。
唯一的烦恼是，有时候屏幕上有那么几个汉字显示不出来。有时是代码里的中文注释（所以我本人虽然英文极滥，也坚持用英文写注释），有时是别的机器上的一些文件名。
以前有同学向我推荐zhcon，类似以前dos下的中文系统。可这个玩意性能极低。用它我还不如直接用X呢。
周末，我花了两个小时写了个小程序，算是自己的解决方案。
我问自己，我目前的首要原则是什么？
其实想说的，那篇里都有人说了。如果非要说首要，我也认可最多人认可的：
KISS-KeepItSimpleStupid
不过对DRY-Don’tRepeatYourself我反而认为是次要的，当然是在和KISS相冲突的时候。
如果换一句和KISS原则相当分量的话，我会说：不要用愚蠢的方法做事。很矛盾？RepeatYourself往往代表了一些愚蠢的方案，且并不simple，至少会付出更多的体力。我想，KISS的最后一个S指的是大智若愚的愚，而自做聪明则是另一种愚蠢。
在KISS的大原则下，我想其实可以分出一些细节的东西，也是别人都提过的：
今天想把项目用的Makefile整理一下，主要是让.o.a等等这些中间文件生成到独立目录中去。做这项工作的过程中，发现了一些有趣的问题。
当然最头痛的要属路径名的斜杠转换问题，这里暂时不提。为了描述方便，暂且不考虑windows平台。
GNUMake对反斜杠的处理很恶心。用常规方法，你很难弄出单个反斜杠出来。
比如直接写SLASH=\是不可以的，因为\被用来连接下一行的。
而你用SLASH=\\会生成两个反斜杠，而不是一个。
这个问题在BSDMake里没有，但在GNUMake里是个很让人头痛的问题，尤其是你需要做多平台的时候。
虽然Windows下，大多数时候，路径名中使用\\等同于\。但有的时候也会出些小问题，尤其在做很复杂的模式匹配的时候。
今天我下决心搞清楚这个问题怎么解决，最终google到了方法。
由于这次需要部署多个网络接入点，解决网通、电信、教育网互联的问题。我申请了各个网络的多台机器。新申请的机器是跑的debian/linux，而不是我们开发时用的freebsd。一个以前在freebsd上跑的正常的程序，放在linux出了问题，一开始让我很不解。
仔细查看后，发现bug出在一个recv调用上。用gdbattach到锁死的进程中，确认果然是一处recv调用没有返回。
Windows早期默认支持的中文编码方案是GBK，它是对早期GB2312的一个扩展。后来国家又发布了GB18030标准，扩展了GBK，增加了一些Unicode里才有的汉字，这样就可以做到和Unicode字符集做完全的映射了。
而后来Unicode逐渐成为标准，几乎所有的系统处理多国语言时，都把Unicode做为默认设置了。Unicode有两套编码集，UCS-2和UCS-4，后者是对前者的补充，虽说字面说写的4，但实际上只用到了3个字节不到。
Windows的内部其实是用的UCS-2标准，并用UTF-16来实现。而非Windows系统大多采用了UTF-8。UTF-8在很多情况下更有优势，首先它不需要考虑大头小头的问题，其次，数据损坏的时候，不会有半个汉字的问题。并且UTF-8可以完整的表达UCS-4而不需要有额外的付出。
不过，UTF-8的设计明显是用英文为主的西方人搞出来的东西。对于中文一点都不环保。所有汉字和中文标点都需要3个字节才能表达。而少量欧洲字母可以用2字节表达，英文的ASCII符号则可以只用单字节。
我不指责这个设计，因为兼容ASCII是UTF-8的最大优势。其它，则是KISS原则下的产物。
不过，若是内部使用的话，如果你介意这1/3的储存空间的浪费的话，是不是有改进的余地呢？下面我们来讨论这个问题。
后来细想，这里面可以做的东西还有许多。玩家会因为多一个信息通道，而更轻松的去玩那些需要长期驻留的游戏。游戏厂商也可以多一个挽留玩家的渠道，甚至用来宣传新游戏或游戏的增值服务，等等。好处不再列举。
其实、绑定IM帐号和绑定手机号本质上区别不大。只不过，IM帐号几乎是零费用，又不像SMS，控制权掌控在移动手里。IM更适合做双向交流（SMS的双向交流不那么方便，而且对用户和游戏运营商都有经济负担）。独立提供一个Game2IM的服务供众多游戏运营商使用也是个有趣的主意。和SMS一样，只要给出一个简单接口让游戏运营商调用，把游戏网络和IM网络互联就可以了。
实现这个想法有两个方案。其一是制作各种IM的机器人，通过机器人和用户IM沟通。这个方案技术门槛稍低，有许多现成的机器人可以使用。缺点是，受IM提供商的限制（比如好友数量限制）。无法使用机器人的签名针对性的向用户传递特有的消息。除非你为每个游戏用户定制一个机器人，但那样，每个机器人都需要单独一个连接，对资源消耗过大。
第二个方案就是使用已有的IM互通方案，自己提供一个特有的Game-IM网络，跟已有的IM网络互通。比较流行的IM互通协议用基于SIP的SIMPLE和起源于Jabber的XMPP。
主题是关于：用C/C++构建的系统，在内存管理这个层面，如何促进系统的健壮性和性能。session的题目最终被命名为：高性能健壮系统中的内存管理。有点绕口。
最近想在子项目中试一下darcs，替代原来的svn。只是尝试一下。
之前都是在本地玩darcs的，没遇到多少问题。今天找了台freebsd的机器，做了一个集中的仓库。没想到遇到许多麻烦。
从freebsd或linux上远程操作这个仓库都没有多少问题，问题出在windows上。windows版的darcs在提交文件时，一旦patch过大，就很容易失败。弄了一天才把问题弄明白。
这个想法其实是以前用googledesktop时明白的，gds和google很多桌面软件都用浏览器做配置界面。其实就是自己做了个简易的webserver而已。我也不需要太多，支持GET即可。仅监听本地端口，本质上没碰网络。windows都不会弹安全警告。整个代码用C写的，才200来行。
做成了lua的一个模块，require进来即可用，很方便:)再用上点ajax技术，操作感也不错呢。
最近做游戏数值有点头大。也研究了一些游戏的设定，有点心得。举个很小的例子来谈谈：
wow里的护甲对物理伤害吸收是乘一个百分比的，其公式为：
min(护甲/(护甲+400+85*敌人等级),0.75)
怎样理解这样一个公式的内在含义？为什么会设置成这样？
鉴于迁移版本控制系统的工作量比较大（主要是培训成本），这几天我们工作室重新调整了下各自对svn仓库的管理权限，理了下以后的开发管理流程。最终决定继续把svn用下去（至少到项目第一阶段完成），希望比以前用的更好。
但出于个人兴趣，我继续考察了几个分布式VCS/SCM，并装了其中几个玩。个人直觉Darcs最好。不过从流行度讲，或许Mercurial更佳。
他写的算是有理有据了。
不过这篇blog成文于2006年8月，离现在已有些年头，在这个讯息万变的今天，每个活跃的开源软件都会不断的发展，大家姑且看之。至于我的个人意见，只是出于直觉，没什么可参考性。
我最早接触的SCM工具是vss，但是没用几天（换工作到网易后）就迁移到了cvs。我自己大约用了一年后，公司集体从cvs迁移到了svn。领导这次大迁徙的大大说，svn是一个更好的cvs（确实是这样吗？据说有争议，但至少我感觉在多文件版本控制上svn比cvs方便，因为cvs无法保证多个文件同时提交的原子性）。
前几年，有人跟我争论过到底vss的加锁模式好，还是cvs的合并模式好。我觉得答案是不言而喻的，懒得争论。虽然在某些特殊环境上，我们偶尔需要加锁模式协同工作，但对于程序员的协作来说，无疑我们需要并行的工作。
我们在若干年前曾经淘汰过一次加锁的协作编码方式，而到了今天，是时候再做一些改变了。或许，分布式的版本控制工具才是未来的发展方向。我想，总有一天，cvs/svn这类集中式版本控制工具会被淘汰掉的。
说说我的困扰吧，可能很多开发小组也遇到过。
这三篇论文我都有所耳闻，GFS的论文应该出来最早，前几年就有同事发过英文版的给我看过。MapReduce耳边经常有人跟我提起。BigTable听的比较少一点，但也知道大概是咋回事。
三篇论文中译本都没读过（更别说英文版我会仔细学习了）。我便躺在床上，捧着手机，细细品读。
还在大四的时候，曾经跟sina游戏制作论坛的人赌气，自己实现了一个jpegdecoder。大约是99年底的事情吧。
一直以来，我们的新引擎一直以跨平台为设计目标。这倒不是说，我们有多重视非Windows平台的用户。只是我觉得，一个好的设计一定是很容易做到平台无关的。对于做跨平台开发这件事情，公司里支持的人寥寥。光老丁都几次三番劝我不要把精力花在无谓的地方。
唉，怎么说呢。写了这么多年程序，我一直把编写代码和设计软件作为一件很有趣的事情在做。所以我并不认为我做的一切是一种工作，它是我的玩具。早就不需要担心后半辈子的生活问题，所以没有人可以阻止我做想做的事情，更何况我认为良好的设计造就优秀的产品。今天看似多花的精力，日后慢慢的会给出回报。
回想当年做西游的客户端，我固执的把内存的占用量控制在64M左右，让低配置的机器也可以流畅的运行。为了达到这一点，当年多花了好多的精力。做内存中的精灵压缩，做地图的动态加载，做图象数据的cache和主动交换，改动许多我认为会更多占用内存的数据结构，阻止美术的一切可能过于消耗内存的设计。
这些在我离开西游的开发后的这么多年里，配合硬件的发展，往日做的那些，得以让后来的不断扩展玩法和美术资源可以稳定的进行。后期的开发维护人员可以用足够的东西来“浪费”。前期的种种约束和正是为了后期的无拘束扩展，直到这些项目顺利的走完生命期。
我希望几年之后，依旧有人感谢我当下做过的努力。
最近一年半做的主要项目是跨平台的。但是只是说说，还没真的去试着在别的平台上run起来。因为我们做的是二进制复用，目标模块文件是自定义格式，所以也不太在乎编译器。原计划是在Windows下开发，用VC编译的。
所以，我的跨平台目标就定在了win32、freebsd、linux和macosx。当然，目前我的测试环境只有win32和freebsd，这几天就在把这两个搞定。