很不好意思，我只回复了两份，别的都还没有动键盘回复。一是周末在打游戏（平时实在没空），二是需要和同事讨论一下才有结论。我们工作室 11 号放假，10 号晚上办公室就没人了。也就这两天会比较所有的简历吧。

嗯，已收到的简历我都看完了（真是花了不少时间呢），明天会发给工作室其他写程序的同事看。我想若安排面试，就是年后的事情了。我们大约在 21 号正式上班。

请原谅我这个周末的懈怠。接下来我会尽力回复 email 的。

游戏时间大约在 50 小时左右，没看任何攻略，没有炼级，没有改武器，基本一路冲到底的。就是几个 boss 稍微难一点，retry 了几次，大体上对于熟练 RPG 玩家没什么难度。

然后接着就是回头做 64 个冥碑任务（现在完成了 20 多个，其中只做了一个 A 级的比较难），开传送点等等。我估计把盘走完，还需要至少五十小时吧。

这次剧情依旧不错，我比较喜欢，但不是最好。（FF 10 和 FF 7 我更喜欢一点）我的日文水平是入门级里的入门，理所当然的，好多地方没看明白。只能连蒙带猜了。生日那天，居然传出官方消息说是五月要出中文版，这算是今年的生日礼物吧 :D 一定会买来再玩一次的。

角色里三个 mm 都不错，任挑一个我都喜欢。不过感觉这次有点恶趣味。虽然没明白做百合向的，我想有几个镜头也是故意做的满邪恶了 :D

我们这里工作室，需要招聘两名程序员。在未来至少一年的工作是：专职制作维护 3d engine 中的模型编辑器和场景编辑器。（每个一人维护）

要求：

1. 熟悉 C 语言，或 C++ 。至少有一门动态语言的经验，lua 最好，python 或其它也可以。

2. 能够全心制作编辑器（至少一年），最好有相关经验（非必须）。

3. 有 3d 方面编程经验优先，但不是必须。需要有学习 3d 编程的兴趣和动力。

4. 有任意一款 GUI 框架编程经验者优先。（例如 QT ）

待遇方面，不会太高，但也不算低。所以特别牛的同学就免了，可能满足不了你的要求。就算愿意，我也心里不舒服。

完全抱着从头学习的想法的同学也需要考虑一下。我们还是需要有一点点经验的，不可能花半年时间慢慢培养到可以开始动手干活。（经验指：可以独立编写 GUI 程序）

有兴趣的同学可以给我发 email 附上简单的简历。

今天晚上就碰到这么一个诡异的问题，我觉得是我太久没摸 C++ 了，对那些奇怪的语法细则已经不那么熟悉了。有知道的同学给我解惑一下吧。

事情的起因是，我想安装一个 perl 模块唤作 Syntax::Highlight::Universal 。

本来用 CPAN 安装很方便的，直接 install 即可。

可是在我的机器上，make 死活通不过。我就仔细研究了一下编译出错信息。又读了一下源代码，自己感觉没错。纠结了半天，仔细模仿出错的地方写了一小段程序测试。

翻了几页杂志，回想到当年最终幻想X 出的时候的惊艳。当时看到公司里有同事在玩，也是周末。第二天去去买了台 PS2 和游戏。之后，我就成了这个系列的死忠（之前我也玩过七和八，但是都没有十给我的震撼）。后来我补上了五和六，并且把七和八重玩了；再之后就是 XI 和 XII ，以及 X 和 VII 的外传。

很久没玩游戏了，想想真是忙呢。又或者是长大了？但是，我得承认，我心里那点感觉又回来了。星期天一起床，吃完饭就直接去了附近的游戏店。价钱很黑，但是我急着想要。不到五分钟就拿下了 FF13 连 PS3 的套装。

别的银行我也用过几家，也骂过。比如农行早几年取款难。每个季度我都去转工资，每次要排 3 小时的队。后来花了 100 办了网上银行，居然跨行转帐最长等了我一周。后来工资转发到招行，总算解决了问题。愤然去消户，跑了两趟银行，交通费花了几十，手续费花了十块（补交年费，还有把卡弄坏的挂失费等等）。

我们都知道，层次分明的代码最容易维护。你可以轻易的换掉某个层次上的某个模块，而不用担心对整个系统造成很大的副作用。

层次不清的设计中，最糟糕的一种是模块循环依赖。即，分不清两个模块谁在上，谁在下。这个时候，最容易牵扯不清，其结果往往是把两者看做一体去维护算了。这里面还涉及一些初始化次序等繁杂的细节。

其次，就是越层的模块联系。当模块 A 是模块 B 的上层，而模块 B 又是模块 C 的上层，这个时候，让模块 C 对模块 A 可见，在模块 A 中有对 C 导出接口的直接调用，对于清晰的设计是很忌讳的一件事。虽然，我们很难完全避免这个问题，去让 A 对 C 的调用完全通过 B 。但通常应尽力为之。（注：以后写书的话，我争取补充一些实际的例子来说明）不过，对语言不原生支持的数据类型，以及基础设施，但却有必要创造出来给系统用的。可以有些例外。比如内存管理，log 管理，字符串（C 语言用原始库函数管理比较麻烦）等等，我们可能以基础模块的形式提供。但却可能被不同层次的模块直接使用。但，上到一定层次后，还是需要去隐藏它们的。

下面来一点更实际的分析。

模块化是最高原则之一（在 《Unix 编程艺术》一书中， Unix 哲学第一条即：模块原则），我们就当考虑如何简洁明快的使用 C 语言实现模块化。

除开 C/C++ ，在其它现在流行的开发语言中，缺少标准化的模块管理机制是很难想象的。但这也是 C 语言本身的设计哲学决定的：把尽可能多的可能性留给程序员。根据实际的系统，实际的需要去定制自己需要的东西。

对于巨型的系统（比如 Windows 这样的操作系统），一般会考虑使用一种二进制级的模块化方案。由模块自己提供元信息，或是使用统一的管理方案（比如注册表）。稍小一点的系统（我们通常开发接触到的），则会考虑轻量一些的源码级方案。

1. 工作真的很忙，很难脱开身。我觉得我在某种程度上陷进去了。需要花点时间整理规划一下。然后把工作的事情处理好。让它可以顺利做下去。不光是技术上要解决的问题，也不光是管理问题，也不光是团队合作的问题，也不光是项目开发运作的问题。反正很多很多，确实有很多麻烦。我要尽力做好。

2. 觉得上一本没写好，是因为还是太仓促了。即使是已经写的那点东西，也积累不够。写书的经验也太少。我倒不怕有错误被人骂，是怕自己回头不满意。

3. 如果再写，肯定只抓着很少的问题谈。但是具体写什么，还没全想好。积累是有了点，真能够拿出来写写的不多。毕竟，写书和写 blog 瞎扯还是不一样的。

孟岩建议我先在 blog 上列的大纲，然后随便写点。让同学们给意见，再逐步修改成书。我也有此想法，觉得不错。不过一开始，恐怕我连大纲都列不出来，就想到哪写到哪，随便写点东西吧。过段时间再把零碎想法串起来，作为正式列提纲的参考。

由于最近几年用的主要开发语言是 C 和 lua 。那么也打算以此为基础写。假定读者至少有不错的 C 语言基础了。我真正想谈的是，如何把一个软件很好的构建起来。到底需要做些什么。（从实现层面看）怎样才是好的软件。

那么有一个重点问题，也是老问题，怎样才是好的设计。

中午 12 点 50 到的，一看，好家伙，买票的人排了一层从楼梯都排到楼下了。周六下午场都卖完了。正打算去吃个饭再来排队的。结果一黄牛过来，说要不要 13 点的。我一看表正好 12 点 55 。100 快一张成交。

不错，就是没吃中饭，爆米花充饥。

电影不错，iMax 3D 感觉是不一样。屏幕大，才有足够的纵深。坐的位置估计也满重要。反正我坐在中间靠后一点，感觉正好。

这部片子啊，就是看效果了。情节就那样了，但是设定很严谨。适合我们这样做游戏的人看。

看来我的 blog 还是还是有点影响力 :) 好多人都下载了那本书。

Derek Jones 同学提醒我书已经有了新的版本。我已更新了原帖的下载链接。

btw, 机器翻译真是恐怖啊。当然，毕竟这位同学填对了 7 。 :D

做 LuaJIT 的牛人 Mike Pall 对 bit 库没有采用他做好的现成方案那可是相当的不客气。

不过，欢呼雀跃的人还是比较多的。每次 lua 升级个小版本，改动都非常大。对成熟项目，不给你伤点筋骨，那就不是 lua 三巨头的风格了。当然，对于时不时重写代码的我，欣赏这种风格 ;) 我喜欢更健康的 lua 语言。

嗯，无论如何，lua 的源代码是非常值得阅读的。

话说那本书，我自己是不太满意的。04 年写的时候，基本只能总结 03 年之前的一些东西，还差许多火候。写完之后，我给自己打了 70 分，慢慢的，觉得有 60 分就不错了。勉强及格吧。

这个光源模块设计要解决的问题在于：

GPU 的处理能力，目前看来比较有限，不可能实时处理无限数量的光源。所以，当你的场景里设置了许多的光源时，必须可以拣选出最可能影响被渲染物体的光源信息，把这个信息交给驱动去处理。

之前在杭州赛区赢了几个项目的预赛，拿到入场卷，所以门票就免了。最后以至于票多出来都没人要了。

赛场是在一个 LOFT 里，上面透风。同去的 A 同学的女朋友一直叫冷，我觉得还好，把外套借出去了。没想到感冒了，差点失声。估计另一个原因是我讲太多话了。

我在第一场现代艺术预赛里拿了５人组的第２。没得到第一纯粹是被一个不会玩的 mm 害了。然后去参加电力公司的复赛。由于时间太长，只好放弃了现代艺术的后续赛程。一开始有点可惜，后来听 A 同学讲述了半决赛经历后，我认为我们都没戏争夺冠军的。