最近读了一本书：《数学的雨伞下》。阅读体验非常好，这本书用浅显的语言，科普了许多深刻的道理。这本书所介绍的知识结构比较类似我挺喜欢的另一本《从一到无穷大》，但讲解更为细致一些，以至于如果事先明白这些知识，甚至会觉得有些冗长。但细细品味，会觉得理解能更深一层。
我在通读完一遍之后，这几天带着儿子精读。重读第一章中“对数之桥”一节时，我思考了一个问题：当年纳皮尔 Napier 到底出于什么动机制作一张高精度对数表，他制表的计算思路是怎样的。书中并没有答案，所以我又在互联网上翻看了当年 Napier 原著 Mirifici Logarithmorum Canonis Descriptio 的介绍，感觉收获颇丰。
最近去了一趟南宁马山县。攀岩一周，身体很累，心里很舒服。这周除了爬石头，什么都没想，脑子全部放空了。
“一款好游戏，胜过两款伟大游戏”…… 这世上最容易做的就是“多”，如果我们不小心，就可能会把三四款游戏都塞进一个游戏里。有时候，决定什么内容不该加到游戏里，比决定什么内容该加进入更加总要。—— 《席德梅尔的回忆录》
这几天，读了本书《席德梅尔的回忆录》：《文明》是在陪产假中诞生的，它一开始更像是《铁路大亨》的延续，一个全球规模的《模拟城市》，一个实时模拟游戏。它开发了很久都没有找到正确的方向，一度项目被搁置。而重新继续这个项目后，经过了搁置期的思考，才试着将其改为回合制游戏。
席德还有款失败的作品《恐龙游戏》，他从 1991 年开始鼓捣这款游戏的原型，到 2000 年第 6 届 E3 展后彻底放弃。一开始几个版本像是恐龙版文明，核心玩法是基因衍化，但随机基因突变并不好玩；其后简化了复杂的规则，却变得很无聊。“好像不是你在玩计算机，而是计算机在玩你。如果游戏要一下子表达太多东西，那简化游戏设计会有帮助；但如果你在一款回合制游戏上投入了足够多的时间，你就会希望能够控制所有有趣的决策”。
回合制走不通，游戏原型转为了即时制。席德之前就有一款成功的即时制游戏《葛底斯堡战役》。但这个《恐龙争霸》却因为恐龙题材难以嫁接足够多的远程武器以至于无法平衡。
然后，这款恐龙游戏又演化成了口袋妖怪，或是更接近恐龙万智牌。平平无奇的“借鉴”让这款游戏毫无新意。卡牌形式很好玩，但是“这些卡牌的互动方式与《万智牌》太像了。如果你能加入自己的想法，那借鉴一点创意是可以的，但我从来不觉得恐龙游戏有足够多的新元素可自证清白。”席德忍受不了这一点，最终彻底放弃了这个项目。
《The New C Standard》 是我很喜欢的一本书。因为这本书，我有幸结识了作者 Derek M Jones 。
在 2018 年的时候，他就写 email 给我介绍了他正在写的一本关于软件工程的书。
这是一本非常特别的书。里面有大量的、从公开渠道获得的关于软件工程方面的数据。作者对这些数据做了统计和分析。我之前从未看过如此全篇基于数据去讨论软件工程领域问题的著作（通常在社会学领域更多一些）。
数据摆在那里，或许不同的人，不同的方法会得到不同的解读。这本书不在于给出结论，而是展示了分析过程。让你来从中发现数据透露出的信息。
当时我就很喜欢这本书，陆陆续续读了一些。
最近，这本书《Evidence-based software engineering —— based on the publicly available data》终于快完成了。我很高兴能分享给大家，有兴趣的同学可以在这里下载电子版。
如果有同学有兴趣公开自己的一些有关软件工程方面的数据，还可以看看这里。
我在翻译《程序员修练之道》第二版时，一开始拿到的版本并不是现在出版的这个。所以在中途更换过一个版本，即最后英文版的最终版。前后两个版本都不是原始 markdown ，而是 pdf 格式的。试过几个 diff 软件都无法很好的比对，只好花了不少时间人肉校对了一遍。
虽然两个版本先后只差了几个月，但是增加，调整的段落非常之多，可见作者维护的非常频繁。我当时特别想一观他们的内部写作仓库。记忆比较深刻的是有一大段谈团队的文字被删掉了。不知道原因。但我觉得挺可惜的，这是我很喜欢的一个段落。为了忠于原著，我也从中译版里删除。
下面记录一下这段废稿：
我翻译的 The Pragmatic Programmer 20th Anniversary Edition 已经摆上了书店的货架。今天收到了出版社快递来的几本样书。纸张挺精良的，对得起这本著作。听朋友说，京东上的预定也陆续到货了。我非常期待各位学友的反馈。
去年几乎是一口气翻译完的。倾注了颇多心血。一边翻译一边和身边的朋友分享，几乎每个读过的人都很喜欢。我希望每个程序员都能读一读这本书。即使你已经读过第一版，也绝对不能放过这个新版。我在翻译过程中一直在做新老版本的对照，能明显感到与时俱进的内容。而且即使是没怎么修订的章节，这次因为读得非常细致，也有很多新的领悟。
限于水平，这次的翻译一定会有差错。希望发现错误的朋友能不吝指教。我会尽力在重刷的时候修正过来。
另外，这次的译本同时拿到了 kindle 上出版的版权（挺不容易的）。kindle 电子版应该会在 2-3 月内上线。不太喜欢囤实体书的同学可以再等等。
勘误见这里： https://github.com/cloudwu/tpp_feedback/
6 月 24 日，kindle 电子版上线。
文本在阐释中烟消云散 —— 尼采《善恶的彼岸》
2019 年 12 月 20 日，我终于用笨拙的中文把《程序员修炼之道》的第二版初步译完。距编辑侠少把英文电子版发送给我已经过去了 70 天。这两个多月里，翻译工作几乎占据了我所有的业余时间，真的很累，但却心甘情愿，并乐得其中。
这个月来，我已经在从事《程序员修炼之道》第二版的翻译。到现在已经超过十万字，几乎是全书的一半了。
很难很累。翻译和阅读是两码事，就算自己理解了，想说清楚也是很难的。何况有些句子理解起来摸棱两可，想理解透彻也不是那么容易的事。毕竟是别人的思想，凡思想都非真理，没有太多对错可言，翻译者只求能准确表达。
不过越是深入，越是觉得自己在做一件伟大的事。这本书一如二十年前的那一版一样，字字珠玑。能给无数程序员引路。有些道理过去讲得不甚透彻的，经过数十年的历练，作者看得更通透了。
比如，有一条过去没有提及的原则，在这一版中放在了重中之重的位置。那就是：ETC 原则，Easier To Change ，易于修改。
The Pragmatic Programmer 这本书居然在上个月出了第二版，离第一版过去已经 20 年了。
十多年前，在我第一次看到这本书时，就相当的喜欢。后来在中文版再刷的时候，应邀写了一篇书评 。一晃又是十年过去，没想到这次因为这本书找上我的是第二版的翻译工作。
我只花了 10 分钟，把 Amazon 上第二版的页面稍微浏览了一遍，就答应了这项工作。如果只是为了赚点外快，我是肯定不会接翻译书的活的。比起《代码大全》那种大部头，这本书可谓短小精悍。不过 300 来页，但我现在业余时间大多交给了家庭，就算只有 30 万字的量，起码也需要几百小时来做。
但这次，我真的希望借翻译的机会，重新精读一遍。而且看目录，第二版修订了许多内容，可以先睹为快了。这些年拒绝了很多出版社写书的邀约，除了时间不太够外，主要还是觉得自己沉淀不够，很难系统总结好自己的思想。孔子也说述而不作，信而好古。其实前人总结的实在是太好了，我想我的能力可以发挥在此也不错：尽自己的理解，把这本经典翻译好。高质量的译本对中文开发社区的贡献会远超过自己写一本不成熟的书。
今天在读《数学也荒唐》时读到分蛋糕问题，想起之前写过一篇 blog 谈房租分配，其实是同一个问题：
当多个人要切分资源时，如何让每个人都满意。
因为每个人对价值判断是不一样的，就租房来说，有人追求性价比；有人追求舒适，对价格不敏感；按某种固定的方案定价就不太公平。
如果是两人合租，最简单的公平方案就是你定价，我来选。A 来提一个自己认为公平的定价方案：例如大房间 1000 ，小房间 800 ；B 来选择住大房间还是小房间。如果 A B 都是理性的，这就是让双方都满意的方案。
但是三人或更多人分配就没有这么简洁的策略。我在前篇 blog 中讨论了这个问题，在回复中，也有同学给了知乎上分蛋糕问题的链接。
过了这些年，今天读书时又看到，感觉有趣，那么再写一次。
最近抽时间在读 Milo Yip 翻译的《游戏引擎架构》。书还没有出版，我应邀给这个译本写序，所以先拿到了电子版，正在加紧读一遍。全书接近 800 页，我已经读了 600 页左右，希望这个周末可以抽时间读完。
这本书是由顽皮狗的主程之一 Jason Gregory 写的，内容很精彩，Milo Yip 翻译的也相当不错。有很多章节我读的很有共鸣，想先挑一点来写写。
由于作者的主要技术背景是 Console game 开发，而 Console 目前内存非常有限，且没有虚拟内存，对内存的管理和使用就非常苛刻。很多 PC 平台上几乎被忽视的问题到了 Console 平台上就需要仔细考虑了。我很有共鸣是因为 10 多年前在开发大话西游时，要求在 64M 内存上跑起来，同样写了好多内存管理相关的代码。
比如栈式内存管理，就是在堆上模拟一个栈，只管分配，然后记住一个标记点一起释放。
又比如双端分配器，自己管理一大块内存，根据需求不同从两端向中间分配，这个还可以配合上面的分配器一起工作。
把对象的生命期绑定在渲染帧上，在一帧渲染完后把当帧的临时内存全部释放；或者做的更复杂一点，做一个乒乓开关，临时内存可以保留到下一帧结束。呵呵，这些以前都写过。
04 年的时候在网易公司内部做个一个比赛，就是在一块固定大小的内存内实现自己的内存管理器。用我们从梦幻西游，以及大话西游的客户端中实际采集来的数据做比赛评分，分别按允许速度和碎片率打分。我自己虽然没有参赛，但当时也写过一份程序拿到了最高分 :) 当时比赛的前三名现在都是网易项目（或离职后是新公司的主程）的主程。
这个国庆假期，我读完了《D程序设计语言》 一书。里面读到了很多有趣的东西，挑一点写出来和大家分享一下。
字符串，数组和关联数组（hash 表）是最重要的三种数据结构，我们几乎可以利用它们模拟出任何更复杂的结构。Lua 就是这么干的，只不过 Lua 把数组和关联数组合并成一个 table 类型了。D 在语言层面对这三种数据结构支持的很好，概念定义非常清晰。这一篇只谈数组和字符串，不涉及 hash 表的部分。
数组可以看成是存放同一类型数据的连续内存。
在 C 语言中，数组和指针虽然是不同的类型，但编译器生成的代码却是相同的，可以说实质上，数组即指针。但将数组隐含有长度信息，即内存的范围。有些数组是固定大小的，在编译器就知道其范围；有些数组需要动态扩展大小，其范围是运行期确定，并可以改变的。无论如何，对数组的随机访问，缺乏边界检查的代码都隐藏着风险。
D 语言是一门期望有高安全性的同时又重视运行性能的语言。它在平衡这个问题上的解决方案很有趣。程序员可以指定一段代码是安全的，还是系统级的，还是是接口安全的。根据不同的标注来插入边界检查代码。在 debug 版中，即使是系统级代码，也会插入类似 assert 的契约检查。
由于 D 语言以 GC 为内存管理核心（且要求所有数据都是位置无关，可移动的），所以管理数组切片 Slice 就变得很简单。不同的Slice 引用同一块内存，不用担心数据生命期问题。扩展数组也可以根据需要重新分配内存，或是在原地扩展。
提到数组扩展，不得不谈一下 D 语言中结构的 postblit 。D 语言中，所有的 class 都是引用语义的，而 struct 是值语义的。C++ 中花了很多年想解决的一个性能问题就是源于 vector 扩展时，数据如何从旧的位置移动新位置的问题。在 stl 的 sgi 实现中，为 POD 结构增加的特化模板来提高复制效率；在 C++11 中又从语言层面增加了右值引用来实现移动语义，来解决反复析构构造对象带来的性能浪费。
而 D 语言中没有那些晦涩的移动构造，拷贝构造概念；它只有 postblit 。也就是数据都应该默认按位复制（blit），然后在 blit 后，再用 postblit 方法去修改新的副本。这种不动源对象，而只在副本上修改的移动钩子技术概念更简单清晰。而且编译器可以自行推导什么时候调用 postblit 才是必要的。这个技术不仅仅用来解决数组的扩展问题，也可以很好的搞定 C++ 中返回值优化问题。
对于固定大小的数组，D (2.0) 是按值类型处理的（动态数组则是引用类型），不同长度的数组是不同的类型，但它们都可以隐式转换（映射）成动态数组。比较短的固定数组做值传递的时候更方便高效，也符合其它基础类型的特征。长数组可以通过 ref 修饰按引用传递。
今天收到人民邮电出版的杨海玲同学寄来的几本书，首先感谢一下。看来短期内是没有那么多精力全部去读了，所以先随便翻翻感兴趣的章节。
在《游戏人工智能编程案例精粹 》 和 《 Windows 游戏编程大师技巧 》 中都分别有一章谈及模糊逻辑。记得前几年我的同事 Soloist 同学曾经研究过一小段时间，给我做过简单介绍，我便仔细把这两章书读了一遍。感觉都是点到为止，所以又翻了一下 Wikipedia 的 Fuzzy Logic 的介绍。午饭时跟做 AI 的同事交流了一下，觉得可以做一点笔记记录理解的部分。
在游戏人工智能编程中举了个实际的例子来说明这个问题：在一个 FPS 游戏中，NPC 有多种武器可供选择，这些武器的威力、射程等有所差异；策划决定根据 NPC 和玩家的距离以及 NPC 武器弹药的余量，两个因素来考虑 NPC 当下应该选择哪一种武器对抗玩家。这个例子不错，不过我有另一个自己的例子：在 MMO 中，NPC 在追击玩家时可能会考虑几个因素：离开他的出生点的距离，以及玩家的实力，或是自己的 HP 量等等。下面我用自己的例子来说明问题。
先甩开模糊逻辑是什么不谈，我们在做 AI 定制的时候会遇到怎样的很难决策的问题呢？
策划往往会定义规则：当 NPC 距离出生点很远时，他们停止攻击玩家并返回出生点。
这里有一个问题，即使是最新手的策划也看得出来，这个规则描述是不严谨的。到底什么叫“很远”。所以通常，需要加一个定义，追击半径，变成“当 NPC 距离出生点超过追击半径时，他们停止攻击玩家并返回出生点”。然后，在策划表格里估计就会多出一个表项：追击半径 40 米 之内的东西。
顺便吐槽：把设计这个规则（追击条件），和填写这个数字（ 40 米追击半径）的工作分开，分别称做系统策划和数值策划，我怎么看都是件极不靠谱的事情。
这个想法是大约一个月以前细化的。类似的想法我在 97 年就有，当时网络并不普及，我为之做了一个单机版的 DOS 小程序。放在 cfido 上传播，以及放在个人网站上，有零星的几个用户。
我设想有这样一个工具，可以辅助我阅读英文小说，或是论文。它不应该是一个简单的词典，我不喜欢在阅读时有过多的交互。我希望作为阅读者，只是单方面的输入信息。那么，一个好的工具应该了解我的熟悉的单词领域，知道那些对我陌生的单词。并且明白，如何解释他们我可以明白其含义。
有时候，我只需要一个简单的中英文词汇对应关系；有时候我需要更多的解释。
一个好的辅助工具，能做到，在我需要简单解释的时候，在生词后面打上括号，写上对应的中文词。并在我尚未遗忘之前，同样的词不再注释。对于复杂的词汇，我希望它能排版在同一页的边侧，我第一感觉它应该在的地方。而不是让我费力的移动一下鼠标选中。
Effective C++ 3rd 的评注版要出版了。我在这本书上花了不少心血。编辑约我最后写一篇序。我新码了点文字，用了点以前 blog 上写的旧文。
今天侠少同学说“现在全文看下来还是有些纠结，反对、支持、再反对，再支持，百转千回的小情绪，读者恐怕会犯晕”。嗯，的确很羞愧的。不应该在这本大牛的书前面发牢骚。打算晚上改稿子。旧稿就贴这里存档吧。
序
今天终于把作业作完了（可能还有地方要返工），Effective C++ 第 3 版读完了，写了几万字的评论。如我给编辑交稿的 email 里所写：
我觉得评注这个工作比翻译难做。作者细节上讲的非常清楚，大部分地方都不觉得有必要再加注解。我想跟这本书反复写了 10 年有关。所以很多页我都没留评注，真的不知道可以写啥。
编辑原想每页中英分列排版，我是不建议这样的。除了少部分评注，针对个别代码段，或关键词。大部分我的文字都是独立成段的。跟具体原文句子关系不大，只跟篇章段落主题有些许联系。
前几天跟孟岩兄 email 交流，我发了一些稿子给他。他觉得关于本书第一篇 Item 1 : View C++ as a federation of languages ，我的评注还是没有讲透。是的，许多观点还是很难表达清楚。
下面选一段贴出来吧。
最近一个多月的业余时间都耗在了《Effective C++ 3rd Edition》这本书上。读的很辛苦，不仅仅是因为这是本英文书。之前答应了博文的编辑帮这本书写评注，将来用于出版。对于要印成白纸黑字的文章，不得不谨慎一些。
我已经有 4 年没有大段时间写 C++ 代码了。中间偶尔有几天写过几千行，其余的 C++ 经验就来至于 google reader 上的阅读。为了读这本书，我又重温了《C++语言的设计和演化》的几个章节。不过整个阅读过程还是不太赏心悦目。
可能还是因为我对 C++ 偏见过多，有如前几年对其的推崇备至。总觉得书里讲的太细，太多观点本是好的，只是局限在了 C++ 语言中。明明是 C++ 的缺陷，却让人绞尽心力的回避那些问题，或是以 C++ 独特的方式回避。在别的语言中不该存在的问题，却成了 C++ 程序员必备的知识。人生苦短，何苦制造问题来解决之。
今天晚上继续读 《Masterminds of Programming》，忍不住又翻译了半章关于 Forth 之父的访谈。我以前读过几篇更早时期关于他的访谈，部分了解他的观点。小时候还特别迷 Forth 。这位神叨叨的老头很有意思。
没看过原来的译本，只是自己按自己的理解翻了第 4 章 Forth 的前一半。我也算对 Forth 很有爱的人吧，也还了解 Forth 里诸如 ITC (Indirected-threaded code) 这种术语到底指的什么，不过还是觉得翻译有点吃力。
对 Forth 同样有爱的同学们姑且看之吧。
《Masterminds of Programming: Conversations with the Creators of Major Programming Languages》是本相当不错的书。博文翻译出版了这本书，中文名叫做《编程之魂》。
书是好书，可惜翻译这本书需要对各种语言的深入研究，看起来译者有点力不从心。出版社打算重新做这本书。受编辑所托，我校对了其中第七章：有关 Lua 的一段。原文读下来拍案叫好。可惜译文许多地方看起来有些词不达意。许多在口语化交流中提到的术语被忽略了做了错误的翻译。有些部分应该是对 lua 理解不够而没能表达清楚。
仔细校对了两段后，我干脆放弃原译本，自己动手翻译了一份（保留了不到 1/4 原来的译文）。虽然个人能力有限，但也算是每句话自己都看明白了再译的。虽说有些地方没有直译，但也算没有夹带私货。
这里贴出一段，希望大家阅读愉快。
前几天被翻出来介绍《The New C Standard》的老帖，貌似被作者看到了。 The changing shape of code in the next decade
看来我的 blog 还是还是有点影响力 :) 好多人都下载了那本书。
Derek Jones 同学提醒我书已经有了新的版本。我已更新了原帖的下载链接。
btw, 机器翻译真是恐怖啊。当然，毕竟这位同学填对了 7 。 :D
一切阅读都是误读
—— 安伯托·艾柯
上次读这本书已经是在五年前。中文版刚出版我就买了一本。那个时候我的工作相对比较清闲，有大量的时间阅读。恰巧我在负责公司的校园招聘以及新员工培训，非常需要一些不错的教材，更早的时候听说过这本书的英文版，但是没能一读，中文版自是不能放过。另外，那年我在写书，记录一些程序员生涯中的心得，对经验的总结都颇有兴趣。
爱不释手，是我第一次读完后的心境。完整的经历了人生中第一个成功的大的软件项目后，我有许多感慨。不少东西知道怎么做对，怎样做不对，但是要一条条写下来，却不知道怎么总结。这本书说出了许多我想说，而不知道该怎么说的道理。
接下来的日子，我在公司做过好几次技术培训，课题都是以这本书中的某个或某几个观点，结合自己的经历展开的。对于信任我的同学，我总是把这本书列在给他们开的书单的第一本。
后来，国内又翻译引进了几本类似的好书。比如《代码大全》，《Unix 编程艺术》。古人云，读书有三上，马上、枕上、厕上。我还真把书买了好几本，床头、办公桌上各置一本，方便睡前、如厕时阅读；手机里放入电子版，上下班路上，偶尔翻阅。这些书的确是值得逐章挑选出来，反复精读的。《程序员修炼之道》却于几年前推荐给新入职的同事，从我的视野里消失了。
这几天，同事把书还了我，加上 周筠老师 发给我电子版，我又重读了一遍。原以为那些嚼烂了的东西，不会再有新味道，但是我错了。
不同的人从不同的角度用不同的方式，阐述相同的道理。其中细微的差异，是需要读者有了许多许多的经历后，才能体会的。比如，在《程序员修炼之道》中花了六页分析 DRY - Don't Repeat Yourself 原则；而在《Unix 编程艺术》中把它称作 SPOT - Single Point of Truth ，大约用了一页半的篇幅。他们真是是想表达完全一致的理念吗？我看未必。所以，作为读者，同样会有许许多多的想法。随着编程经历的越来越多，思考次数的增加，重新和这些前辈的思想相印证，也是一件乐事。
我们以为理解了作者，其实是误解。但我们将再一次理解编程。
今年二月份拿到这本书的电子稿时，还不是现在这个名字。
《程序员的自我修养》这个名字听起来比原来的那个名字感觉好一些，但又让人感觉有点不知所谓。还是副标题直接：《链接、装载与库》。我更愿意接受这样的一个名字，有如那本多年前读过的英文经典：《Linkers & Loaders》。
那段时间很忙，一直到现在都是。书稿我压了很久，直到有一天，博文的朋友说，约个时间和 Fenng 、俞甲子等杭州的程序员碰头聚一下。我连夜开始读书稿。不然，见面了谈起这本书来，说不出所以然多不好意思。
周末开始读一本书，《The New C Standard》。尚未出版，但是电子版可以自由下载。
牛人写的计算机方面的书，我想有两个极端。要么像高爷爷的 TAOCP ，厚厚的几大本，还在待续；要么如 K&R 的 TCPL ，薄薄一本，躺在床上轻松读完。
之前，我从没想过，以 C 语言为主题的书，可以砖头样的一大本，1600+ 页。用 80 克纸双面打印，会厚达 9.2 厘米（作者语）。 不过看过副标题，稍微可以理解：An Economic and Cultural Commentary 。感情上升到经济和文化了。敢用这个词的人绝非泛泛之辈。
一不小心读到凌晨五点，居然 Introduction 的一半还没读完 :( ，也就是说，前 100 页都还没正式谈 C 语言呢。
由于是英文版，阅读速度受到了极大的限制。而行文中大量我不认识的单词和长句，迫使我不断的查字典。就这样还能坚持读下来，只能说，这是一本好书，有趣的书。
好吧，简单说，这是一本对 C 的标准及相关层面的一切注条评论的书。
对于每一个点，都在几个方面展开：将其和 C++ 、其它语言对比；描述一般的实现方法；对其做出评论；给出 Coding Guidelines （编码指引）。
下面，我试着将前面介绍部分选译几段，鉴于原文的行文与我来说有许多艰深之处，恐怕很难译的准确，姑且看之吧。
最近把 Asimov 的《基地》系列中，正传三本看完了。算是补课也好，没有辜负我专门去邮购这些书。买书真是件奢侈的事儿，以前是因为书贵，现在是因为时间和精力。
初翻此书，没有我当年期待的那么好。在那个没有网络的年代，读到这些科幻名著是件很难的事情。Asimov 也被神化了，这里面老爸对此亦有贡献。在我还刚认识几个字，是本书就想拿来读的年龄段，他就向我兴致勃勃的介绍 Verne ，Asimov 。弄的我小时候以为这两个就是世界上最伟大的作家。
不过，把这几本读完后，也不算太糟糕。或许有些翻译质量的不适应，故事还是高潮迭起的。毕竟是数十年前的科幻了，幻想中的科学总有那么一点怪怪的。当我在第一本中看到“电算板”时，心里只有一个念头，这不就是笔记本电脑么？功能好象还抵不上我现在用的 palm 手机 :)
抛开想象中的落伍科技之外（YY 方面自然比不过如今流行的玄幻小说），情节方面的构思还是颇为引人入胜的。即使许多情节的设计以今天的眼光看来不算新鲜。但我们应该考虑到这么多年来，总有新的作者不断仿效加工，才使得我们有了审美疲劳。
总之，向没看过的此书的科幻迷推荐一下。
接着昨天的写。
昨天谈到了对象生命期管理的问题。我们来看操作系统是怎么管理资源的。
对于资源的集合体，操作系统抽象出进程的概念。每个任务可以向系统索取资源，操作系统放在进程的集合内。进程在，资源在；进程死，资源收回。从操作系统看出去，一个个对象都是独立的，不用理会相互的依赖关系，有的只有对象 handle 。收回这些对象的次序是无所谓的，跟发放他们的次序无关。
这里比较重要且特殊的是内存资源，操作系统其实不直接发放物理内存给用户，用户看到的只有虚拟地址空间。真正分配出去的是地址空间。而且空间是按页分配的，到了用户那里，再由用户自行切割使用。
这么看，内存管理的确是最复杂的部分。因为用户通常不能像文件 handle 那样，拿来是什么还回去还是什么。一个简单的引用记数就可以管理的很好。内存资源必须做多层次的管理。或许未来 64 位系统普及后，这个问题会简单很多，但谁叫我们主流应用还是跑在 32 位平台上呢？而且 64 位系统未必不会出现新的问题。我们现在看 64 位系统，估计跟当年在 dos 实模式下写程序时曾经幻想以后随随便便就有 4G 内存用的感觉一样。
除去资源管理，操作系统通常都会抽象出线程这个代码执行流程，加以统一管理。线程本身会作为一种资源放在进程的管理集合中。但是操作系统又需要对所有线程的集合做统一的调度。从这个角度看，仅仅分层归组管理是不够的。
其实不仅是线程，像 socket 这样的资源同样不能简单置于进程的层次之下。一个 tcp 连接是不能简单的在进程结束后直接干脆的抹掉。另外负责网络通讯的核心模块也需要有轮询系统中所有 socket 的能力。
综上看来，对象的生命期管理在同一层次上似乎应该有交叉的两条线。一条是拥有共同的生命期的集合；另一条是同类对象的集合。
先不忙下结论，再谈谈我们现在自己设计的引擎用到的一些管理策略和最近发现的一些不足吧。
这两周过的很混乱，主要是从程序部分脱出来，在写游戏的策划案。没怎么写代码，人有点空虚。策划案都是文字活，脑子里想是一回事，写出来又是回事。还有很多细节似乎是因为没想明白，所以表达不清。还得努力。
今天有个 blog 的读者在 gtalk 上督促俺，很长时间没更新了，不准偷懒，好多人看着呢。我从一开始就没打算为别人写 blog ，自己想到啥就写啥，没在意多少人在看。就这样有一茬没一茬的写着，为自己做一个记录。
今天写这么一篇，倒不全因为有美女鼓励。其实在下午百无聊赖的时候就想敲点什么了，一摸键盘又觉得没想清楚。在 blog 管理界面里已经有好几篇这样的稿子，写完了就那么放着而没有公开。生活若不是为了生存，那么就自然会充斥着胡思乱想，这些年我就这么个状态。偶尔想明白点什么，就写下来。而更多的，来也也快去的也快。
其实最开始想写的还是技术上的东西，大致有两点。
第一个是关于网络对时的，这个问题反反复复折磨我很多年了（去年写过一篇 blog，但相关纠缠着我们项目的问题不仅于此）。当然我不是要在这里向谁寻求答案，所以如果读完这篇 blog 想跟我讨论 NTP 协议或是相关技术细节的朋友，在下就不奉陪了。这也不是个什么复杂不能解决的难题，下面是想写一个衍生问题：
我们现在大多数的软件模型是不考虑时间因素的。我们关心的是输入和输出。各种编程语言也是如此，只见到语言的设计和实现去追求运行时的时间效率，不见从语言上严格定义一段代码的运行时间。当然，绝对时间是不能定义的，它会随着硬件发展而变化。但相对时间理论上可被定义的，可最终还是被人忽略了。我们研究算法，也只探讨时间复杂度而已。当然这跟现在计算机的模型有关系，在现有模型下，一段代码的严格运行时间甚至是不可能精确测度的。
我有一个忘记从哪继承来的观点：无论我们想学什么，都应该从学习他的历史开始。极端点说，无论学什么，都是在学他的历史。
前几天在北京见到了我的小表妹，她刚上初一，人极为聪明。七年前我在北京工作时，她还没有上小学。那个时候我就回答过她许多科普问题。一个五岁的小姑娘的理解能力曾让我感叹不已。
知道小妹妹居然在写 blog 而且文笔不错，觉得挺高兴的。但听说她最近一次考试数学成绩不是特别好，有些令人担忧。我一直认为中学所谓文理分科就是件巨傻的事（似乎现在慢慢的不再分了）。但如果一味的去追求所谓文科上的造诣，怕是会耽误理性思维的发展。在迈入科学的殿堂的门槛上，一步错就能耽误十年啊。
小孩子一开始在学校学习或许更多的是为了比同龄人强，为了完成长辈的期望，为了达到别人设定的目标。但终有一天，长大了的后会发现，学习其实就是因为自己想知道。
所以吃饭的时候，我多说了几句。无论学什么，都要先培养出兴趣。理科的东西老师教起来很枯燥，那么就可以从读他们的历史开始。一段段故事，一个个鲜活的人，就会变得生动。深一层的道理需要慢慢的去体会：无论学什么，都是在学他的历史。以前的人如何考虑这些问题，为何研究这些问题。他们怎样去归纳、总结。他们的思考怎样延伸出去，为什么又有了局限性。后人怎样做出了突破。人性是共通的，人的智力水平也相差无多。按着前人的路，没有太难理解的道理。而课堂上现在的教法，把历史上长长的思考过程压缩，裁减掉所有的错误和累赘，压缩成一条条公式与冷冰冰的推导。背了那些，除了考出完美的答卷，就没太多意义了。
我带她去书店逛了一下午，买了不少书。逛书店这个点子一提出来，小姑娘心中的高兴完全写在了脸上。我想找一本有趣点的数学史的书，没有物色到。最后挑了一本科普的《从一到无穷大》；转到科普的柜台，她居然知道《时间简史》。我想了想还是买了本，但是告诫说，这个年纪读可能还太小，留到高中再看吧。再后来又买了些小说……
写了这么一大段，其实我还是想绕回来写写 软件开发2.0大会 上的故事，以及接下来几天的活动。
作为一个常识，每个程序员在做入门学习时，都会被老师谆谆教导：我们用的编程语言中的随机函数，只能产生出伪随机数。它有它的内在规律，只能作为对显示世界的随机事件的近似模拟。接下来，我们通常会被传授随机种子的概念。以及用物理上更随机的量做种子。比如系统时间、两次敲击键盘的时间间隔、多次移动鼠标的偏移、甚至系统出错的出错信息码等等。
作为游戏数值策划，除了加减乘除，用的最多的数学概念恐怕就是随机数了。有经验的数值策划或许从他的前辈那得知计算机中程序产生的随机数并不太可靠；或者他本身就受过程序方面的训练。如果游戏项目更幸运一点，担当数值策划的他是一个数学爱好者，并读过诸如《计算机程序设计艺术》这样的技术书籍，那么事情会好的多。可惜大多数境遇下，策划们从不深究计算机随机数背后的细节，也不太关心所谓“伪”随机数究竟“伪”到什么程度。
最近几天，有测试人员向我抱怨，我们游戏中某些概率设定总感觉有点怪怪的。似乎跟文档上的不同。
这种抱怨并不少见，许多网络游戏玩家都在抱怨系统生成的随机数不太对劲。善良点的玩家会归咎到自己的 RP 上，阴谋论者则指责系统作弊。运营着的游戏背后，数值策划和程序员们有苦说不出。
有必要科普一些数学常识，也作为我周末读书的一些笔记。
如果人生有一个终极追求的话，我想那是真理。
一个人的时间是有限的，而真理似乎在无限远处，探索真理需要一代代人的努力，我们靠近一点，就可以让下一代人的起步更接近一些。这可能也是我们的前辈所想所作，所以我们需要学习前人留下的知识。避免又从原点出发。
知识不是数据库中的数据，一个 copy 指令就可以复制出去，永不消逝。书是媒介，大脑才是载体。人类的信息输入带宽极其有限，远低于大脑的处理能力（如果你能善用他的话）。浪费带宽这种稀缺资源是让人痛心的，故而我爱读书。
心情平静的时候读，神情气爽；烦闷的时候读，调节心境；闲暇的时候读，消磨时光；繁忙的时候读，释放压力。我有睡前读书的习惯。昨晚，天气不热，但似乎楼上楼下的人家都习惯性的开着空调。窗外滴滴嗒嗒的是冷凝管滴水的声音。突然想起李清照的两句词来：枕上诗书闲处好，门前风景雨来佳。
这次枕边放的是一本：《什么是数学 》。
早听说这是一本好书，也买了很久了。总静不下心读。前次顺着翻了前面几章，权当催眠读物了。枯燥归枯燥，但我绝对承认这本书写的相当不错。相比许多数学读物，他已经非常生动了。知识点一环扣一环，遵循严密的逻辑推理，而不是凭空跳出一个结论让你接受。或是想当然的认为你应该受过专业的数学训练，承认一些公认的定理和规则。
什么是数学？数学表达的是对象与对象间的关系，而不探究对象到底是什么。它在公理的基础上演绎，而不讨论公理本身的真假。数学是美妙的，作为人类思维的表达形式，反映了人们积极进取的意志、缜密周详的推理以及对完美境界的追求。
学习掌握数学，可以极大的帮助我们洞察这个世界。数学是一种思维方式，而绝不是解题训练。
前两天看书的时候看到这道题：三角形 ABC 是一个等腰三角形，顶角 20 度。角 EBC 为 60 度，角 DCB 为 50 度。求角 DEB = ? 度。
由于是躺在床上看书，身边没有笔和纸，脑子里想不清楚，就用手机上的计算器把答案算了出来。当然，用了三角公式。结果是一个整数，这也预示着这道题很可能存在一个初等几何的解法。
一不小心把书翻了一页，看到了答案，觉得乐趣少了很多。当时觉得这是道有趣的题，就记了下来，第二天带到公司。果然，几个同事花了很长时间都没做出来 :) 到第三天才有人找到初等几何的解法。
各位观众，如果还有谁有兴趣可以一试。只需要具备初中（或仅需要小学高年级？）平面几何的知识就够了。
旅游回来后，突然觉得有一大块的时间可以用。就仿佛新启动的进程，一下子可以申请到上 G 的连续地址空间那样；感觉很爽。每天可以只做睡觉和写程序两件事。中间累了尽可以来点放松的小活动，但不会干扰主流程。
自从上次引擎的第三次的设计改动已经冻结下来，似乎只需要向上面添砖加瓦了。既然怎么做应该想好，完成它应该只是时间问题。
另一个附带的项目经过了一年，终于可以看到结束的曙光。虽然行百里路半九十，但毕竟一个半成品的出现还是让人欣喜的。
做这些事情的同时，往日坚持的一些业余活动就很久没有进行了。每周两次的抱石没有去碰，现在力量下降了太多，只能指望过段时间再有个恢复期；琴没弹了，太花时间，不适合现在时间紧张的状态。桥牌没打，三缺一（有时候是缺二）。
不过还是做了不少别的事的。比如读书：
卢梭的这本《论人类不平等的起源和基础》放在床头一年，终于读完了最后一页。我开始有点喜欢这个老头了，过段时间可能还会再买一些他的书看。
《深入解析Windows操作系统：第4版》有着令人畏惧的近千页的厚度；但是其内容对一个 Windows 程序员的重要性，让我已经翻过了十分之一。
还有一些时间，就是打打游戏：
最近想重新补习一下高等数学，起因是这样的：我老觉得自己对这个世界的认识总是很肤浅，这几天晚上都在读爱因斯坦的《相对论的意义》。其实这本书已经在床头放了小半年了，反反复复的翻了几遍。每每觉得看懂了，第二天想跟人讲心得的时候又觉得自己没全弄明白。
高中时看老爸留下来的物理教材学相对论觉得很新鲜，记住了点概念；大学时听老师讲相对论，背了几个公式；毕业这么多年，挖出点兴趣来再看，觉得自己啥都没明白 :( 。小的时候读《时间简史》，号称全书只有一个数学公式 E=mc2 ，读起来就不枯燥；今天再读的时候，就是想弄清楚公式背后的含义，多一点公式也觉得必要了。只是发现自己的数学掌握的实在不好。那么补数学吧 :D
同事 soloist 推荐了张筑生教授的《数学分析新讲》。
也算写了好些 tcp/udp 应用的程序了。断断续续的看了几本关于网络编程的书。这一本跟编程无关的书也当资料般的查过几章。但这几年来，居然没能抽出时间把它精读一遍，想想还真不是我的风格 :D 直到近几天，我才坚持慢慢的读这本书。
前几天在三亚晒太阳，同行的一个同事（游戏部门的技术总监）在读一本英文版关于 AJAX 的书。市场部的同事看到表示不理解。带书出门，似乎是程序员的共性，其实我自己也带了本正在读的《科学精神的形成》，可惜最终也没能拿出来翻。回想起来，似乎已经有很久没有读纯粹的技术书籍了。也就是那种略微枯燥的，讲解具体技术知识点的书。想想啊，作为程序员，这种历练还是不要断的好。
曾经有种流行的说法是，中国人喜欢打麻将，日本人喜爱围棋，而美国人多打桥牌。这类文章 google 一搜一大把。
当然中国人或是韩国人也喜欢下围棋，而日本人也没以前那么爱围棋了。八十年代的时候，似乎在国内校园里也非常流行打桥牌。而桥牌在美国现在还是不是那么那么流行，就不得而知了。所谓国民的特性从所喜爱的游戏中可看出总总之观点，我一直是不置可否的。今天写的跟这些无关。
由于家庭渊源，我个人不喜欢打麻将。但对麻将也没有感情上的厌恶。小时候即没见父母打过，也不曾见过传送中的因为麻将而导致的家破人亡、妻离子散。只觉得麻将无非一种有竞技性质的桌上游戏而已。
我对麻将所知非常有限，规则陆陆续续的了解了许多。大约知道各地的细则不太一样，大体却是相差不大。似乎体育总局定过一个国标麻将 ，我们的 popo 游戏 就是按这个做的，据我所知，喜欢玩这个规则的不多。大家还是按地域各打各的一套。这也是边锋游戏成功的秘诀之一。
那么，在我看来的一个普通游戏，甚至没有统一明确的规则，为何风靡整个华人世界呢？
又是一个长假，由于连着年度旅游，假期比往年更长一些。出去旅游前，就有同事嘲笑，“出去玩还背着那么厚一本书，累不累啊。”我自己知道，书是带回家看的。
这个假期伴随我的是这样一本书——《UNIX 编程艺术》。几个月以前就开始读了。以前是随手翻开中间几页读上一篇；这次，躺在阳台前的躺椅上，舒服的晒着阳光。终于，从头至尾的完成了。
终于把这本书完整的读完了。这本书的后一半远没有前一半读的快。
倒不是说，后面的内容艰涩难理解，或者枯燥无味。仅仅只是因为工作太忙，只能抽出近半个月的时间，每天睡觉前读上几页。也正是这个原因，以前在 wiki 上写的 读书笔记 只有前半本的记录。
诚如书中最后所说，许多程序员在多年工作后，居然一年都不能阅读一本完整的技术图书。我几乎犯了这样的错误。幸运的是，这样一本厚达九百页的好书，最终还是被我耐心的读完了。除了中间几个章节觉得讲的道理过于简单之外，剩下的部分都十分精彩。每每读到一些平时在工作中被讨论过的问题，都让我拍案叫好，我从来没想过这样细节琐碎的东西也会被写到书里。
作者的几乎每一行文字都让我产生了共鸣。从书中，虽然我没有学到新的知识，但是却让我细致的整理了自己的经验。还有一些我原本自己知道正确，却讲不清道理的东西，得以明确的认识。比如关于程序注释，代码风格，不同的软件项目的开发流程等等。正如作者在书中所写一样，我认同他的观点：某些教材中阐述的观点已经被开发实践证明是错误的；而作者如此大胆的以出版文字的形式驳斥那些观点，没有十足的底气是做不到的。
感谢让我们能拥有这样一本好书的所有人。