根据昨天留下来的思路 ，我今天做了个 web server 。只用于给本地程序做配置界面用。
这个想法其实是以前用 google desktop 时明白的，gds 和 google 很多桌面软件都用浏览器做配置界面。其实就是自己做了个简易的 web server 而已。我也不需要太多，支持 GET 即可。仅监听本地端口，本质上没碰网络。windows 都不会弹安全警告。整个代码用 C 写的，才 200 来行。
做成了 lua 的一个模块，require 进来即可用，很方便 :) 再用上点 ajax 技术，操作感也不错呢。
最近做游戏数值有点头大。也研究了一些游戏的设定，有点心得。举个很小的例子来谈谈：
wow 里的护甲对物理伤害吸收是乘一个百分比的，其公式为：
min (护甲/(护甲 + 400 + 85 * 敌人等级) , 0.75)
怎样理解这样一个公式的内在含义？为什么会设置成这样？
自己的代码若出了问题，大多数情况我会重写。只要模块划分清楚，设计做好。重写的部分都不会太多。但是别人的代码出问题的话，很多情况下，就只能硬着头皮耐心找了。这就是我这几天的境遇。
前几天我们一个系统更新升级，在公网上一直不太稳定。这次产品上线有点仓促，不过也是内部测试过的。一直没碰到什么大问题，而在公网上情况毕竟复杂的多了，而且排错的压力也比较大，毕竟为玩家服务的程序，公布后就不能随便停掉收回来。这就依赖热更新，在运行期间查错了。
先说昨天晚上让我弄了一通宵的 bug ，留个记录，对以后可能出现类似的问题起点警示。
鉴于迁移版本控制系统的工作量比较大（主要是培训成本），这几天我们工作室重新调整了下各自对 svn 仓库的管理权限，理了下以后的开发管理流程。最终决定继续把 svn 用下去（至少到项目第一阶段完成），希望比以前用的更好。
但出于个人兴趣，我继续考察了几个分布式 VCS/SCM ，并装了其中几个玩。个人直觉 Darcs 最好。不过从流行度讲，或许 Mercurial 更佳。
虽然近期网上似乎支持 Mercurial 的最多（包括乌龟版也做的最全面），但我还是找到一篇文章支持我的直觉。
Whose Distributed VCS Is The Most Distributed?
他写的算是有理有据了。
不过这篇 blog 成文于 2006 年 8 月，离现在已有些年头，在这个讯息万变的今天，每个活跃的开源软件都会不断的发展，大家姑且看之。至于我的个人意见，只是出于直觉，没什么可参考性。
我最早接触的 SCM 工具是 vss ，但是没用几天（换工作到网易后）就迁移到了 cvs 。我自己大约用了一年后，公司集体从 cvs 迁移到了 svn 。领导这次大迁徙的大大说， svn 是一个更好的 cvs （确实是这样吗？据说有争议，但至少我感觉在多文件版本控制上 svn 比 cvs 方便，因为 cvs 无法保证多个文件同时提交的原子性）。
前几年，有人跟我争论过到底 vss 的加锁模式好，还是 cvs 的合并模式好。我觉得答案是不言而喻的，懒得争论。虽然在某些特殊环境上，我们偶尔需要加锁模式协同工作，但对于程序员的协作来说，无疑我们需要并行的工作。
我们在若干年前曾经淘汰过一次加锁的协作编码方式，而到了今天，是时候再做一些改变了。或许，分布式的版本控制工具才是未来的发展方向。我想，总有一天，cvs/svn 这类集中式版本控制工具会被淘汰掉的。
说说我的困扰吧，可能很多开发小组也遇到过。
我们禁止提交不能编译通过的代码，尽量不提交不能测试通过的代码。结果，对于很复杂的模块，有人几乎一个月都没提交过一次。他总是觉得程序还不太成熟，但几经修改的代码其实从来没有作版本控制。
有些模块由两个人合作编写，关系非常紧凑。有时候需要在两人之间交换一些代码，为了方便，大家通过代码仓库中转，结果在仓库中留下许多未完成的版本。
代码被用笔记本带回家，结果在家完成的部分无处可以提交。（为了安全，我们的代码仓库不能从外网访问）
某人写了一个模块，总是有 bug 没有修改完，而不敢提交。这个时候，另一个人希望协助他找问题，却没有合适的途径 share 那段完成了一半的模块。跑过去 XP 一下么？天哪，为什么我们这里每个人用的编辑器都不一样，还都爱用些特别个性的配色方案呢？
我们尝试过一些 work around 的解决方法，比如在本地自己创建仓库。托 TortoiseSVN 的福，这件事在 Windows 下做起来还是很简单的。可终归是多个仓库的管理，用的人始终感觉麻烦，而没有贯彻下去。
今天有同事问我，分布式版本控制工具到底跟我们现在在用的系统有什么区别。我想了一下回答说：它的本质就是在原有工具的基础上增加了一种方便的仓库合并功能。（哈，我接触这类东西时间不长，大家就当我胡说）
周末在家赖床，把玩我的 treo 手机，从 google reader 上看到 myan 大大新近介绍 google 的三篇论文的中译版。
（插一句，google reader 的手机版做的相当不错，很烂的手机都可以方便的使用，界面简洁，节省 GPRS 流量，强烈推荐）
这三篇论文我都有所耳闻，GFS 的论文应该出来最早，前几年就有同事发过英文版的给我看过。MapReduce 耳边经常有人跟我提起。BigTable 听的比较少一点，但也知道大概是咋回事。
三篇论文中译本都没读过（更别说英文版我会仔细学习了）。我便躺在床上，捧着手机，细细品读。
还在大四的时候，曾经跟 sina 游戏制作论坛的人赌气，自己实现了一个 jpeg decoder 。大约是 99 年底的事情吧。
当时查阅了许多资料，才把 decode 程序完成，同时写了一篇 JPEG 简易文档 。蒙网友厚爱，这么多年来不断转载，也总有人写信询问细节。今天收到一封不同的 email ，质疑我写的这篇非原创，乃一篇译文，却未在文中提及。
说来惭愧，当初的确查阅了不少英文资料，所以这篇文档也起源于其中一篇。怪当年年少无知，没有在文中注明。今日重读 CRYX's note about the JPEG decoding algorithm ，时隔多年，恍如隔世。当初动笔的时候，不知如何组织，照搬了这篇的结构，并且 copy 了其中的图表和公式。一开始只想粗略翻译一下，后来自己写写程序的时候发现许多细节不明之处，又查阅了许多别的资料（已经想不起来了，无法一一注明），陆续补充进文档。后来又有诸网友指教，经历了数次修订。
前几年修订的时候，也曾想过注明参考文献。皆因时间久远，无法找回原始资料，不能如愿。今天特更新注明，以尊重原作者。
ps. 如今的中文图书市场较之当年已大为改善，关于 jpeg 的专著已有翻译图书《JPEG2000图像压缩基础、标准和实践》出版，对其有兴趣者可以一读。
一直以来，我们的新引擎一直以跨平台为设计目标。这倒不是说，我们有多重视非 Windows 平台的用户。只是我觉得，一个好的设计一定是很容易做到平台无关的。对于做跨平台开发这件事情，公司里支持的人寥寥。光老丁都几次三番劝我不要把精力花在无谓的地方。
唉，怎么说呢。写了这么多年程序，我一直把编写代码和设计软件作为一件很有趣的事情在做。所以我并不认为我做的一切是一种工作，它是我的玩具。早就不需要担心后半辈子的生活问题，所以没有人可以阻止我做想做的事情，更何况我认为良好的设计造就优秀的产品。今天看似多花的精力，日后慢慢的会给出回报。
回想当年做西游的客户端，我固执的把内存的占用量控制在 64M 左右，让低配置的机器也可以流畅的运行。为了达到这一点，当年多花了好多的精力。做内存中的精灵压缩，做地图的动态加载，做图象数据的 cache 和主动交换，改动许多我认为会更多占用内存的数据结构，阻止美术的一切可能过于消耗内存的设计。
这些在我离开西游的开发后的这么多年里，配合硬件的发展，往日做的那些，得以让后来的不断扩展玩法和美术资源可以稳定的进行。后期的开发维护人员可以用足够的东西来“浪费”。前期的种种约束和正是为了后期的无拘束扩展，直到这些项目顺利的走完生命期。
我希望几年之后，依旧有人感谢我当下做过的努力。
最近一年半做的主要项目是跨平台的。但是只是说说，还没真的去试着在别的平台上 run 起来。因为我们做的是二进制复用，目标模块文件是自定义格式，所以也不太在乎编译器。原计划是在 Windows 下开发，用 VC 编译的。
最近几天真正开始做跨平台了，想来想去，还是改用 gcc 的好 。废弃 VC 倒不是因为它不好，而是想买一台 Mac mini 放在家里用用 :D 一直家里都没买电脑，我也不用笔记本，回家就是打游戏和睡觉。到时候有了机器，在 Mac OS 上自然是没有 VC 用了。
所以，我的跨平台目标就定在了 win32 、freebsd 、linux 和 macosx 。当然，目前我的测试环境只有 win32 和 freebsd ，这几天就在把这两个搞定。