分类： 系统运维
2010-11-06 22:44:20
今天终于把作业作完了（可能还有地方要返工），Effective C++ 第 3 版读完了，写了几万字的评论。如我给编辑交稿的 email 里所写：
我觉得评注这个工作比翻译难做。作者细节上讲的非常清楚，大部分地方都不觉得有必要再加注解。我想跟这本书反复写了 10 年有关。所以很多页我都没留评注，真的不知道可以写啥。
编辑原想每页中英分列排版，我是不建议这样的。除了少部分评注，针对个别代码段，或关键词。大部分我的文字都是独立成段的。跟具体原文句子关系不大，只跟篇章段落主题有些许联系。
前几天跟孟岩兄 email 交流，我发了一些稿子给他。他觉得关于本书第一篇 Item 1 : View C++ as a federation of languages ，我的评注还是没有讲透。是的，许多观点还是很难表达清楚。
下面选一段贴出来吧。
最近一个多月的业余时间都耗在了《》这本书上。读的很辛苦，不仅仅是因为这是本英文书。之前答应了博文的编辑帮这本书写评注，将来用于出版。对于要印成白纸黑字的文章，不得不谨慎一些。
我已经有 4 年没有大段时间写 C++ 代码了。中间偶尔有几天写过几千行，其余的 C++ 经验就来至于 google reader 上的阅读。为了读这本书，我又重温了《》的几个章节。不过整个阅读过程还是不太赏心悦目。
可能还是因为我对 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》的老帖，貌似被作者看到了。
看来我的 blog 还是还是有点影响力 :) 好多人都下载了那本书。
同学提醒我书已经有了新的版本。我已更新了原帖的下载链接。
btw, 机器翻译真是恐怖啊。当然，毕竟这位同学填对了 7 。 :D
一切阅读都是误读
—— 安伯托·艾柯
上次读这本书已经是在五年前。中文版刚出版我就买了一本。那个时候我的工作相对比较清闲，有大量的时间阅读。恰巧我在负责公司的校园招聘以及新员工培训，非常需要一些不错的教材，更早的时候听说过这本书的英文版，但是没能一读，中文版自是不能放过。另外，那年我在写书，记录一些程序员生涯中的心得，对经验的总结都颇有兴趣。
爱不释手，是我第一次读完后的心境。完整的经历了人生中第一个成功的大的软件项目后，我有许多感慨。不少东西知道怎么做对，怎样做不对，但是要一条条写下来，却不知道怎么总结。这本书说出了许多我想说，而不知道该怎么说的道理。
接下来的日子，我在公司做过好几次技术培训，课题都是以这本书中的某个或某几个观点，结合自己的经历展开的。对于信任我的同学，我总是把这本书列在给他们开的书单的第一本。
后来，国内又翻译引进了几本类似的好书。比如《代码大全》，《Unix 编程艺术》。古人云，读书有三上，马上、枕上、厕上。我还真把书买了好几本，床头、办公桌上各置一本，方便睡前、如厕时阅读；手机里放入电子版，上下班路上，偶尔翻阅。这些书的确是值得逐章挑选出来，反复精读的。《程序员修炼之道》却于几年前推荐给新入职的同事，从我的视野里消失了。
这几天，同事把书还了我，加上 周筠老师 发给我电子版，我又重读了一遍。原以为那些嚼烂了的东西，不会再有新味道，但是我错了。
不同的人从不同的角度用不同的方式，阐述相同的道理。其中细微的差异，是需要读者有了许多许多的经历后，才能体会的。比如，在《程序员修炼之道》中花了六页分析 DRY - Don't Repeat Yourself 原则；而在《Unix 编程艺术》中把它称作 SPOT - Single Point of Truth ，大约用了一页半的篇幅。他们真是是想表达完全一致的理念吗？我看未必。所以，作为读者，同样会有许许多多的想法。随着编程经历的越来越多，思考次数的增加，重新和这些前辈的思想相印证，也是一件乐事。
我们以为理解了作者，其实是误解。但我们将再一次理解编程。
今年二月份拿到这本书的电子稿时，还不是现在这个名字。
《程序员的自我修养》这个名字听起来比原来的那个名字感觉好一些，但又让人感觉有点不知所谓。还是副标题直接：《链接、装载与库》。我更愿意接受这样的一个名字，有如那本多年前读过的英文经典：《Linkers & Loaders》。
那段时间很忙，一直到现在都是。书稿我压了很久，直到有一天，博文的朋友说，约个时间和 Fenng 、俞甲子等杭州的程序员碰头聚一下。我连夜开始读书稿。不然，见面了谈起这本书来，说不出所以然多不好意思。
周末开始读一本书，《》。尚未出版，但是电子版可以自由下载。
牛人写的计算机方面的书，我想有两个极端。要么像高爷爷的 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 而且文笔不错，觉得挺高兴的。但听说她最近一次考试数学成绩不是特别好，有些令人担忧。我一直认为中学所谓文理分科就是件巨傻的事（似乎现在慢慢的不再分了）。但如果一味的去追求所谓文科上的造诣，怕是会耽误理性思维的发展。在迈入科学的殿堂的门槛上，一步错就能耽误十年啊。
小孩子一开始在学校学习或许更多的是为了比同龄人强，为了完成长辈的期望，为了达到别人设定的目标。但终有一天，长大了的后会发现，学习其实就是因为自己想知道。
所以吃饭的时候，我多说了几句。无论学什么，都要先培养出兴趣。理科的东西老师教起来很枯燥，那么就可以从读他们的历史开始。一段段故事，一个个鲜活的人，就会变得生动。深一层的道理需要慢慢的去体会：无论学什么，都是在学他的历史。以前的人如何考虑这些问题，为何研究这些问题。他们怎样去归纳、总结。他们的思考怎样延伸出去，为什么又有了局限性。后人怎样做出了突破。人性是共通的，人的智力水平也相差无多。按着前人的路，没有太难理解的道理。而课堂上现在的教法，把历史上长长的思考过程压缩，裁减掉所有的错误和累赘，压缩成一条条公式与冷冰冰的推导。背了那些，除了考出完美的答卷，就没太多意义了。
我带她去书店逛了一下午，买了不少书。逛书店这个点子一提出来，小姑娘心中的高兴完全写在了脸上。我想找一本有趣点的数学史的书，没有物色到。最后挑了一本科普的《》；转到科普的柜台，她居然知道《时间简史》。我想了想还是买了本，但是告诫说，这个年纪读可能还太小，留到高中再看吧。再后来又买了些小说……
写了这么一大段，其实我还是想绕回来写写 上的故事，以及接下来几天的活动。
作为一个常识，每个程序员在做入门学习时，都会被老师谆谆教导：我们用的编程语言中的随机函数，只能产生出伪随机数。它有它的内在规律，只能作为对显示世界的随机事件的近似模拟。接下来，我们通常会被传授随机种子的概念。以及用物理上更随机的量做种子。比如系统时间、两次敲击键盘的时间间隔、多次移动鼠标的偏移、甚至系统出错的出错信息码等等。
作为游戏数值策划，除了加减乘除，用的最多的数学概念恐怕就是随机数了。有经验的数值策划或许从他的前辈那得知计算机中程序产生的随机数并不太可靠；或者他本身就受过程序方面的训练。如果游戏项目更幸运一点，担当数值策划的他是一个数学爱好者，并读过诸如《》这样的技术书籍，那么事情会好的多。可惜大多数境遇下，策划们从不深究计算机随机数背后的细节，也不太关心所谓“伪”随机数究竟“伪”到什么程度。
最近几天，有测试人员向我抱怨，我们游戏中某些概率设定总感觉有点怪怪的。似乎跟文档上的不同。
这种抱怨并不少见，许多网络游戏玩家都在抱怨系统生成的随机数不太对劲。善良点的玩家会归咎到自己的 RP 上，阴谋论者则指责系统作弊。运营着的游戏背后，数值策划和程序员们有苦说不出。
有必要科普一些数学常识，也作为我周末读书的一些笔记。
如果人生有一个终极追求的话，我想那是真理。
一个人的时间是有限的，而真理似乎在无限远处，探索真理需要一代代人的努力，我们靠近一点，就可以让下一代人的起步更接近一些。这可能也是我们的前辈所想所作，所以我们需要学习前人留下的知识。避免又从原点出发。
知识不是数据库中的数据，一个 copy 指令就可以复制出去，永不消逝。书是媒介，大脑才是载体。人类的信息输入带宽极其有限，远低于大脑的处理能力（如果你能善用他的话）。浪费带宽这种稀缺资源是让人痛心的，故而我爱读书。
心情平静的时候读，神情气爽；烦闷的时候读，调节心境；闲暇的时候读，消磨时光；繁忙的时候读，释放压力。我有睡前读书的习惯。昨晚，天气不热，但似乎楼上楼下的人家都习惯性的开着空调。窗外滴滴嗒嗒的是冷凝管滴水的声音。突然想起李清照的两句词来：枕上诗书闲处好，门前风景雨来佳。
这次枕边放的是一本：《 》。
早听说这是一本好书，也买了很久了。总静不下心读。前次顺着翻了前面几章，权当催眠读物了。枯燥归枯燥，但我绝对承认这本书写的相当不错。相比许多数学读物，他已经非常生动了。知识点一环扣一环，遵循严密的逻辑推理，而不是凭空跳出一个结论让你接受。或是想当然的认为你应该受过专业的数学训练，承认一些公认的定理和规则。
什么是数学？数学表达的是对象与对象间的关系，而不探究对象到底是什么。它在公理的基础上演绎，而不讨论公理本身的真假。数学是美妙的，作为人类思维的表达形式，反映了人们积极进取的意志、缜密周详的推理以及对完美境界的追求。
学习掌握数学，可以极大的帮助我们洞察这个世界。数学是一种思维方式，而绝不是解题训练。
前两天看书的时候看到这道题：三角形 ABC 是一个等腰三角形，顶角 20 度。角 EBC 为 60 度，角 DCB 为 50 度。求角 DEB = ? 度。
由于是躺在床上看书，身边没有笔和纸，脑子里想不清楚，就用手机上的计算器把答案算了出来。当然，用了三角公式。结果是一个整数，这也预示着这道题很可能存在一个初等几何的解法。
一不小心把书翻了一页，看到了答案，觉得乐趣少了很多。当时觉得这是道有趣的题，就记了下来，第二天带到公司。果然，几个同事花了很长时间都没做出来 :) 到第三天才有人找到初等几何的解法。
各位观众，如果还有谁有兴趣可以一试。只需要具备初中（或仅需要小学高年级？）平面几何的知识就够了。
旅游回来后，突然觉得有一大块的时间可以用。就仿佛新启动的进程，一下子可以申请到上 G 的连续地址空间那样；感觉很爽。每天可以只做睡觉和写程序两件事。中间累了尽可以来点放松的小活动，但不会干扰主流程。
自从上次引擎的第三次的设计改动已经冻结下来，似乎只需要向上面添砖加瓦了。既然怎么做应该想好，完成它应该只是时间问题。
另一个附带的项目经过了一年，终于可以看到结束的曙光。虽然行百里路半九十，但毕竟一个半成品的出现还是让人欣喜的。
做这些事情的同时，往日坚持的一些业余活动就很久没有进行了。每周两次的抱石没有去碰，现在力量下降了太多，只能指望过段时间再有个恢复期；琴没弹了，太花时间，不适合现在时间紧张的状态。桥牌没打，三缺一（有时候是缺二）。
不过还是做了不少别的事的。比如读书：
卢梭的这本《》放在床头一年，终于读完了最后一页。我开始有点喜欢这个老头了，过段时间可能还会再买一些他的书看。
《》有着令人畏惧的近千页的厚度；但是其内容对一个 Windows 程序员的重要性，让我已经翻过了十分之一。
还有一些时间，就是打打游戏：
最近想重新补习一下高等数学，起因是这样的：我老觉得自己对这个世界的认识总是很肤浅，这几天晚上都在读爱因斯坦的《》。其实这本书已经在床头放了小半年了，反反复复的翻了几遍。每每觉得看懂了，第二天想跟人讲心得的时候又觉得自己没全弄明白。
高中时看老爸留下来的物理教材学相对论觉得很新鲜，记住了点概念；大学时听老师讲相对论，背了几个公式；毕业这么多年，挖出点兴趣来再看，觉得自己啥都没明白 :( 。小的时候读《时间简史》，号称全书只有一个数学公式 E=mc2 ，读起来就不枯燥；今天再读的时候，就是想弄清楚公式背后的含义，多一点公式也觉得必要了。只是发现自己的数学掌握的实在不好。那么补数学吧 :D
同事 soloist 推荐了张筑生教授的《数学分析新讲》。
也算写了好些 tcp/udp 应用的程序了。断断续续的看了几本关于网络编程的书。这一本跟编程无关的书也当资料般的查过几章。但这几年来，居然没能抽出时间把它精读一遍，想想还真不是我的风格 :D 直到近几天，我才坚持慢慢的读这本书。
前几天在三亚晒太阳，同行的一个同事（游戏部门的技术总监）在读一本英文版关于 AJAX 的书。市场部的同事看到表示不理解。带书出门，似乎是程序员的共性，其实我自己也带了本正在读的《》，可惜最终也没能拿出来翻。回想起来，似乎已经有很久没有读纯粹的技术书籍了。也就是那种略微枯燥的，讲解具体技术知识点的书。想想啊，作为程序员，这种历练还是不要断的好。
曾经有种流行的说法是，中国人喜欢打麻将，日本人喜爱围棋，而美国人多打桥牌。这类文章 google 一搜一大把。
当然中国人或是韩国人也喜欢下围棋，而日本人也没以前那么爱围棋了。八十年代的时候，似乎在国内校园里也非常流行打桥牌。而桥牌在美国现在还是不是那么那么流行，就不得而知了。所谓国民的特性从所喜爱的游戏中可看出总总之观点，我一直是不置可否的。今天写的跟这些无关。
由于家庭渊源，我个人不喜欢打麻将。但对麻将也没有感情上的厌恶。小时候即没见父母打过，也不曾见过传送中的因为麻将而导致的家破人亡、妻离子散。只觉得麻将无非一种有竞技性质的桌上游戏而已。
我对麻将所知非常有限，规则陆陆续续的了解了许多。大约知道各地的细则不太一样，大体却是相差不大。似乎体育总局定过一个 ，我们的 就是按这个做的，据我所知，喜欢玩这个规则的不多。大家还是按地域各打各的一套。这也是边锋游戏成功的秘诀之一。
那么，在我看来的一个普通游戏，甚至没有统一明确的规则，为何风靡整个华人世界呢？
又是一个长假，由于连着年度旅游，假期比往年更长一些。出去旅游前，就有同事嘲笑，“出去玩还背着那么厚一本书，累不累啊。”我自己知道，书是带回家看的。
这个假期伴随我的是这样一本书——《UNIX 编程艺术》。几个月以前就开始读了。以前是随手翻开中间几页读上一篇；这次，躺在阳台前的躺椅上，舒服的晒着阳光。终于，从头至尾的完成了。
终于把这本书完整的读完了。这本书的后一半远没有前一半读的快。
倒不是说，后面的内容艰涩难理解，或者枯燥无味。仅仅只是因为工作太忙，只能抽出近半个月的时间，每天睡觉前读上几页。也正是这个原因，以前在 wiki 上写的 读书笔记 只有前半本的记录。
诚如书中最后所说，许多程序员在多年工作后，居然一年都不能阅读一本完整的技术图书。我几乎犯了这样的错误。幸运的是，这样一本厚达九百页的好书，最终还是被我耐心的读完了。除了中间几个章节觉得讲的道理过于简单之外，剩下的部分都十分精彩。每每读到一些平时在工作中被讨论过的问题，都让我拍案叫好，我从来没想过这样细节琐碎的东西也会被写到书里。
作者的几乎每一行文字都让我产生了共鸣。从书中，虽然我没有学到新的知识，但是却让我细致的整理了自己的经验。还有一些我原本自己知道正确，却讲不清道理的东西，得以明确的认识。比如关于程序注释，代码风格，不同的软件项目的开发流程等等。正如作者在书中所写一样，我认同他的观点：某些教材中阐述的观点已经被开发实践证明是错误的；而作者如此大胆的以出版文字的形式驳斥那些观点，没有十足的底气是做不到的。
感谢让我们能拥有这样一本好书的所有人。