码农从Python开始.pdf
http://www.100md.com
2020年3月12日
 |
| 第1页 |
 |
| 第10页 |
 |
| 第19页 |
 |
| 第26页 |
 |
| 第42页 |
 |
| 第83页 |
参见附件(10871KB，129页)。
码农从Python开始是作者罗晨写的关于python的书籍，主要对python这门编程语言做了基础又详细的介绍，学习python就应该以程序员的统计思维进行练习。
码农从Python开始内容提要
Python到底为什么要叫做Python(蟒蛇)呢？Python的发明人Guido van Rossum说，那是因为他需要一个简短、独特，还略带有神秘感的名字。(刚巧那时他正在看一个70年代的BBC喜剧秀，叫做“巨蟒剧团的飞翔马戏团”。) Python作为一门编程语言，可能最欠缺的就是“神秘感”了。它可以是“好玩的(Playful Programming)”，也可以是“好学的”(Python甚至可以用来教授给小学生)。完全不懂编程的人可以把Python作为自己的第一门编程语言，但是，这并不意味着它不够强大。
码农从Python开始作者简介
本期的码农人物罗晨，虽然不是Python程序员，但是他身体力行地实践了“简单”这件事。他以前端工程师为目标，成功地成为了一名在农场务农的独立开发者。崇尚简约的Markdown编辑器Mou，就是他的作品之一。希望他的生活经历，会给你一个新的角度和一些不同的启示。让我们从一成不变的生活中找到一些新鲜元素吧!学一门新的语言，教一个朋友学会编程，或者为你的家人编写点什么。可能，就从Python开始。
码农从Python开始目录
专题：从Python开始
PPP是什么？好玩的Python编程!
为什么要用Python实现机器学习算法?
第一个孩子的出生时间研究：程序员的统计思维练习
和孩子一起做一只电子宠物吧!
从Python3的bytes/str之别学编码Unicode
如何构造团队Python开发环境
人物
罗晨：梦想照进现实，一个独立开发者的田园诗
读《码农》吐吐槽还能赚银子!
如何教编程，当你面对一双渴望的眼睛
鲜阅
未来的编程语言究竟是什么样?
八++
Puppet——Luke Kanies的钢铁侠
出版的未来
时代可以来得更快
书榜
大家都在读什么?
成书手记
ACM-ICPC冠军谈《挑战程序设计竞赛》及相关算法书
社区动态
乐译开放书：Python for Software Design
图灵访谈：对话Peter Harrington
听书计划：《程序员的思维修炼》
社区介绍
码农从Python开始截图
书名：码农·从Python开始(第7期)
作者：图灵社区出品
本书由北京图灵文化发展有限公司发行数字版。版权所有，侵权必
究。
您购买的图灵电子书仅供您个人使用，未经授权，不得以任何方式复制
和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐
号等维权措施，并可能追究法律责任。目录
编者的话
专题：从Python开始
PPP是什么？好玩的Python编程!
为什么要用Python实现机器学习算法？
第一个孩子的出生时间研究：程序员的统计思维练习
和孩子一起做一只电子宠物吧!
从Python 3的bytesstr之别学编码Unicode
如何构造团队Python开发环境
人物
罗晨：梦想照进现实，一个独立开发者的田园诗
读《码农》 吐吐槽 还能赚银子!
践行
如何教编程，当你面对一双渴望的眼睛
鲜阅
未来的编程语言究竟是什么样？
八++
Puppet——Luke Kanies 的钢铁侠
出版的未来
电子书时代可以来得更快
书榜
大家都在读什么？
成书手记
ACM-ICPC冠军谈《挑战程序设计竞赛》及相关算法书
社区动态
乐译开放书：Python for Software Design
图灵访谈：对话Peter Harrington
听书计划：《程序员的思维修炼》
社区介绍
封底
编者的话
从Python开始
编者 李盼
对于一种编程语言来说，最重要的就是名字了。没有好名字的语言是
无论如何也无法成功的。我最近发明了一个非常棒的名字，现在正在
找那个合适的语言。
——Donald Knuth(高德纳)
Python 到底为什么要叫做Python(蟒蛇)呢？ Python的发明人 Guido
van Rossum说，那是因为他需要一个简短、独特，还略带有神秘感的名
字。(刚巧那时他正在看一个70年代的BBC喜剧秀，叫做“巨蟒剧团的
飞翔马戏团”。)Python作为一门编程语言，可能最欠缺的就是“神秘
感”了。它可以是“好玩的(Playful Programming)”，也可以是“好学
的”(Python甚至可以用来教授给小学生)。完全不懂编程的人可以把
Python作为自己的第一门编程语言，但是，这并不意味着它不够强大。
对于懂得Python的人来说，Pythonic是一种编程风格。它崇尚优雅、明
确、简单，“如果能用同一种方法来做一件事情，为什么要变来变去
呢？”正是这种最大程度简化自身的思想让科学界张开双臂欢迎
Python，甚至称它为“科学的语言”。NumPy、SciPy、Matplotlib可以让
Python程序员编写科学计算程序。众多Pythonist也可以借此开启更加有趣的学习旅程：数据统计、机器学习、计算机科学，甚至自然科学。
简单会激发出更强大的创造力吗？本期的码农人物罗晨，虽然不是
Python程序员，但是他身体力行地实践了“简单”这件事。他以前端工程
师为目标，成功地成为了一名在农场务农的独立开发 者。崇尚简约的
Markdown编辑器Mou，就是他的作品之一。希望他的生活经历，会给
你一个新的角度和一些不同的启示。
让我们从一成不变的生活中找到一些新鲜元素吧!学一门新的语言，教
一个朋友学会编程，或者为你的家人编写点什么。可能，就从Python开
始。专题：从Python开始PPP是什么？好玩的Python编程!
作者 Magnus Lie Hetland
挪威科技大学计算机科学专业副教授。最近在研究相似性搜索和度量
索引。著有《Python基础教程》、《Python算法》等。业余时间做兼
职演员。经常收到黑客关于切磋技术的邮件，从不回复。
译者司维
个人认为Python的强大功能之一，就是它让编程变得好玩——至少对我
来说是这样。只有感到编程是有趣的时候，才容易富有成效。Python最
有意思的地方之一就是它能让你的工作变得非常富有成效。这是个良性
循环，在生活中，这种循环可不多。
好玩的编程(Playful Programming)是我发明的词，是极限编程
(Extreme Programming，亦称XP)的非极限版本。XP的大多数点子我
都喜欢，但是我太懒了，不能完全遵守它的原则。所以现在挑了一些要
点出来，将它们与Python程序开发的自然方式组合起来。
程序设计的柔术
各位听说过柔术吗？这是一种日本武术，它和它衍生出来的柔道以及合
气道一样，都注重反应的灵敏性，或者说“弯而不断”。比赛时，不应该
试图使用预先设计好的移动蒙骗对手，而要顺其自然，以对手的动作还
治其身。这种方式(在理论上讲)可以击败比你高大、强壮和诡谲的对
手。那么怎样将柔术应用到程序设计中呢？关键在于“柔”字，也就是灵活
性。在编程遇到麻烦的时候(总会遇到的)，就不应该固守于原来的设
计和想法，而要灵活变通，以柔克刚。要准备好去应对和适应变化。不
要将没有预料到的事件看做让人沮丧的意外，而要将它们作为探索新的
选择和可能性的起点。
要说的是，当大家坐下并计划应该如何组织程序的时候，对于这个具体
的程序，你还没有任何的经验。怎么可能会有经验？毕竟它还不存在
呢。在实现功能的时候，会逐渐地学到对原始设计有用的新知识。不应
该无视一路走来所吸取的教训，而应该将它们用于软件的重新设计(或
者重构)中。这不是说应该像无头苍蝇一样，马上就开始着手工作——
而是说应该为改变而做好准备，并且接受“最初的设计会需要改进”这样
一个概念。就像以前一位作家说的“撰写即重写”。
灵活性的实现包括许多方面，下面是其中的两个：
原型设计。Python最棒的功能之一就是可以快速地编写程序。编写
原型程序是更充分地了解问题的一种很好的方法。
配置。灵活性有很多种存在形式。配置的目的就是让程序某部分的
改变更简单，对于你和用户来说都是这样。第三点是自动化测试。如果希望轻松改变程序的话，那么自动化测试绝
对是必不可少的。使用原地测试，就能保证你的程序在进行修改后还能
工作。原型设计和配置都会在下面的几节中讨论。
原型设计
一般来说，如果对于Python的某个地方不明白的话，那么尝试一下就好
了。首先，不需要进行多方面的预处理——比如编译或者链接，而这是
其他很多语言所必需的。可以直接运行你的代码。不止如此——还能在
交互式解释器里面逐个地运行，扫清每个角落，直到自己完全明白了它
的工作方式。
这类探索工作并不只限于语言特性和内建函数。当然，这对于了解类似
iter这样的函数的工作方式很有用，但更重要的是轻松地为你准备编写
的程序创建原型的能力，看看它是怎么工作的。
注意 在所谈及问题的背景中，原型(prototype)这个词意味着实验
性的实现，即实现最终程序主要功能的大概模型(mock-up)，但是
在以后的阶段可以完全重写或不重写原有程序。一般来说开始的原型
最后都会被改写成实用的程序。
在将一些思想融入到程序的结构中后(比如需要哪些类和函数)，建议
实现一个简单的版本，这个版本的功能可能非常有限。实现了一个可运
行的程序后，就能发现这个过程是多么简单。然后可以增加特性、改变
不喜欢的地方，等等。也可以看看它是如何工作的，而不是纸上谈兵画
画图表而已。
还能在任何程序设计语言中使用原型设计，但是Python的强大之处就在
于编写一个模型只需要很少的投入，而不用大动干戈。如果发现的设计
并不像预期的一样好用，就可以扔掉原型从头再来。这个过程可能要花
上几个小时、一天或者两天。如果用C++编程的话，要把某部分组织好
运行起来的话可能需要更多的精力，而否决原型也会成为一个重要的决
定。固守一个版本，也就失去了灵活性——注定被早先的决定禁锢住，而在真正实现程序的时候所获得的实际经验，可能会证实重写程序的决
定是错误的。
每个项目都会分为两个阶段的实现。第一个实现只是个摸索性质的试
验，在这个阶段会拼凑出一个能解决问题(或者是问题的一部分)的程序，以便了解所需要的组件和优秀解决方案的需求。能随时看到程序的
所有纰漏，是学习编程的最好一课。利用新学到的知识，会对第一次实
现的程序以更加正式的方式进行重建。当然，大家应该按自己的想法再
改进代码，甚至开始第三次的实现。一般来说，从头开始设计所花费的
时间并没有大家想得那么多。如果已经彻底想通了程序的实用性的话，那么敲代码的时间应该不会太长。
对代码重写说不
尽管这里推荐大家使用原型，但在任何时候对于从头开始重写项目给
出一些警告也是事出有因，尤其是对于原型下了很大功夫的时候。就
多方面来讲，还是推荐大家对原型进行重构和修改，将其完善为功能
性更好的系统。一个常见问题就是“第二系统综合症”。你希望第二个
版本变得更好，结果却永远无法完成。
而“持续重写综合征”也是文学界的术语，主要表现为对程序进行一些
无用的修改，程序员可能会一次又一次地从头开始重新设计。从某些
方面来看，适可而止可能是最佳策略——能工作足矣。
然后“代码疲劳”现象就出现了。程序员会厌烦代码。使用了很长时间
之后，就会觉得代码丑陋得不堪入目。很遗憾，由于需要迁就很多特
殊情况，代码会变得笨重，其中还有大量不同格式的错误处理代码。
但这些都是新版本中必须要重新引入的，而且要耗费你的大量精力
(不是以调试的形式)来首先实现。
换句话说，如果认为原型程序能完善为可以工作的系统，那不管怎么
说都要坚持下去，而不是推倒重来。下面的几章里面，程序的开发被
明确分为两个版本：原型和最终版本。这么做既是为了清晰，也是为
了强调编写第一版软件的时候所获得的经验和洞察力。在现实世界
中，以原型和“重构自身”作为最终系统的指导思想还是很靠谱的。
对于从头开始的可怕之处，请参见Joel Spolsky的文章“Things You
Should Never Do，Part 1”(你永不该做的事，第一部分)(可以在他
的网站http:joelonsoftware.com上找到)。根据Spolsky的说法，从头
写代码是任何软件公司都会犯下的最糟糕的决策性错误。
配置抽象的重要原则：一种更加简单的在程序中引入抽象的方法：从代码中
提取符号化常量(symbolic constant)。
提取常量
前面所说的常量(constant)指的是内建的字面量，例如数字、字符串
和列表。在程序中这些常量不用重复编写，放置在全局变量中即可。虽
然之前的章节讨论过使用全局变量的坏处，但是这种坏处一般只有在全
局变量被改变的时候才会体现出来，因为程序员可能难以追踪哪段代码
引起了哪个改变。我不会处理这些变量，在使用时把它们当做常量(也
就是术语符号化常量)就可以了。为了标识变量是作为符号化常量对待
的，可以使用特殊的命名规则——名字只用大写字母，并且用下划线分
隔每个单词。
先来看个例子。在计算圆面积和周长的程序中，每次需要π值的时候都
得写一遍3.14。那么如果后来需要更精确的值，比如3.14159时，又怎么
办呢？估计就得搜索整个代码，然后用新的值替换旧的。这么做不难，而且很多优秀的文本编辑器还能自动替换。但是如果开始用的值是3怎
么办？总不能把所有与3匹配的数字都替换成3.14159吧？当然不能。处
理这个问题更好的方法是用下面这行代码开始程序：PI = 3.14，然后使
用名字PI替代数字本身。这样一来如果在以后要更精确的值时，改动这
一行就可以了。记住这一点：所写的常量(比如数字42或者字符
串“Hello, world!”)出现次数多于一次的时候，就应该考虑将它放入全
局变量中。
注意 事实上，π的值可以在math模块中找到，使用math.pi即可：
>> from math import pi
>> pi
3.1415926535897931
这一点看起来很容易理解——没问题。真正的目的在下面：配置文件。
配置文件
为自己使用方便提取常量是一码事，还要考虑有些常量是要公开给用户
的。比如用户不喜欢GUI程序的背景色，你就应该允许他们换另外一种
颜色。或者可以让用户在启动那好玩的游戏时，看到他们自己设定的问候语，抑或是可以在刚刚实现的浏览器中更改默认启动页。
这里不是将这些配置变量放在模块的开头，而是将它们放在单独的文件
中。实现这个功能的最简单方法就是为配置创建单独的模块。例如，如
果PI在模块文件config.py中设定，你可以(在主程序内)这样做：
from config import PI
如果用户想改变PI的值，那么他就只要修改config.py就行，而不用看完
所有代码。
警告 使用配置文件具有两面性。一方面，配置功能很有用，但对整
个项目使用集中、共享的变量库会让项目的模块性下降、整体性上
升。一定要确保没有破坏抽象(比如封装)规则。
另外一种方法是使用标准库模块ConfigParser，它的作用是对配置文件
使用适当的标准格式。它接受标准的Python赋值语法，比如如下形式：
greeting = 'Hello, world!'
(这样语句会在的字符串中加上两个多余的双引号)另外一种在很多程
序中使用的配置格式如下：
greeting: Hello, world!
需要使用[files]或者[colors]这样的数据头将配置文件划分为几个区段
(section)。名称可以随意设定，但是需要将它们用方括号括起来。代
码清单1是一个简单的配置文件示例，使用它的程序如代码清单2所示。
有关ConfigParser模块特性的更多信息，可以查阅库文档。
代码清单1 简单的配置文件
[numbers]
pi: 3.1415926535897931
[messages]`
greeting: Welcome to the area calculation program!
question: Please enter the radius:
result_message: The area is代码清单2 使用ConfigParser的程序 from ConfigParser import
ConfigParser
CONFIGFILE = python.txt
config = ConfigParser
读取配置文件：
config.read(CONFIGFILE)
打印初始的问候语：
要查看的区段是'messages'
print config.get('messages', 'greeting')
使用配置文件的一个问题读取半径：
radius = input(config.get('messages', 'question') + ' ')
打印配置文件中的结果信息。
以逗号结束，以在同一行显示：
print config.get('messages', 'result_message'), getfloat将config值转换为float类型：
print config.getfloat('numbers', 'pi') radius2
对于接下来几个项目的配置不再赘述，但是建议读者让自己的程序具有
高配置性。这样一来，用户就可以按照自己的习惯使用程序，使用时也
会心情愉悦。毕竟使用软件过程中最大的挫折之一就是不能让软件按自
己想要的方式工作。
《Python基础教程(第2版)》前几章都在介绍最基本的程序设计理
念，例如极限编程、面向对象程序设计，对于没有多少开发经验或者准备以Python进行编程入门的新手来说，这些章节则是不容错过的。作者
对Python语言的各个方面的剖析准确而到位，各部分会花上不同篇幅确
保读者理解而又不会浪费时间。本书最后的10个项目都是难得的练手机
会——这也是本书不同于其他Python教程的特色之一。这10个项目基本
覆盖了前面章节所提到的各种知识点，同时又不乏趣味性和实用性。本
文摘自《Python基础教程(第2版)》。为什么要用Python实现机器学习算法？
作者 Peter Harrington
拥有电气工程学士和硕士学位，他曾经在美国加州和中国的英特尔公
司工作7年。Peter拥有5项美国专利，在三种学术期刊上发表过文章。
他现在是Zillabyte公司的首席科学家，在加入该公司之前，他曾担任2
年的机器学习软件顾问。Peter在业余时间还参加编程竞赛和建造3D
打印机。
译者曲亚东
在写作《机器学习实战》时，我为什么要选择Python作为实现机器学习
算法的编程语言呢？其原因主要可以归纳为以下三条：(1) Python的语
法清晰；(2) 易于操作纯文本文件；(3) 使用广泛，存在大量的开发文
档。
可执行伪代码
Python具有清晰的语法结构，大家也把它称作可执行伪代码
(executable pseudo-code)。默认安装的Python开发环境已经附带了很
多高级数据类型，如列表、元组、字典、集合、队列等，无需进一步编
程就可以使用这些数据类型的操作。使用这些数据类型使得实现抽象的
数学概念非常简单。此外，读者还可以使用自己熟悉的编程风格，如面
向对象编程、面向过程编程、或者函数式编程。不熟悉Python的读者可
以参阅附录A，该附录详细介绍了Python语言、Python使用的数据类型
以及安装指南。Python语言处理和操作文本文件非常简单，非常易于处理非数值型数
据。Python语言提供了丰富的正则表达式函数以及很多访问Web页面的
函数库，使得从HTML中提取数据变得非常简单直观。
Python比较流行
Python语言使用广泛，代码范例也很多，便于读者快速学习和掌握。此
外，在开发实际应用程序时，也可以利用丰富的模块库缩短开发周期。
在科学和金融领域，Python语言得到了广泛应用。SciPy和NumPy等许
多科学函数库都实现了向量和矩阵操作，这些函数库增加了代码的可读
性，学过线性代数的人都可以看懂代码的实际功能。另外，科学函数库
SciPy和NumPy使用底层语言(C和Fortran)编写，提高了相关应用程序
的计算性能。
Python的科学工具可以与绘图工具Matplotlib协同工作。Matplotlib可以
绘制2D、3D图形，也可以处理科学研究中经常使用到的图形。
Python开发环境还提供了交互式shell环境，允许用户开发程序时查看和
检测程序内容。
Python开发环境将来还会集成Pylab模块，它将NumPy、SciPy和
Matplotlib合并为一个开发环境。在本文写作时，Pylab还没有并入
Python环境，但是不远的将来我们肯定可以在Python开发环境找到它。
Python语言的特色
诸如MATLAB和Mathematica等高级程序语言也允许用户执行矩阵操
作，MATLAB甚至还有许多内嵌的特征可以轻松地构造机器学习应
用，而且MATLAB的运算速度也很快。然而MATLAB的不足之处是软
件费用太高，单个软件授权就要花费数千美元。虽然也有适合
MATLAB的第三方插件，但是没有一个有影响力的大型开源项目。
Java和C等强类型程序设计语言也有矩阵数学库，然而对于这些程序设
计语言来说，最大的问题是即使完成简单的操作也要编写大量的代码。
程序员首先需要定义变量的类型，对于Java来说，每次封装属性时还需
要实现getter和setter方法。另外还要记着实现子类，即使并不想使用子类，也必须实现子类方法。为了完成一个简单的工作，我们必须花费大
量时间编写了很多无用冗长的代码。Python语言则与Java和C完全不
同，它清晰简练，而且易于理解，即使不是编程人员也能够理解程序的
含义，而Java和C对于非编程人员则像天书一样难于理解。
所有人在小学二年级已经学会了写作，然而大多数人必须从事其他更
重要的工作。
——鲍比·奈特
也许某一天，我们可以在这句话中将“写作”替代为“编写代码”，虽然有
些人对于编写代码很感兴趣，但是对于大多数人来说，编程仅是完成其
他任务的工具而已。Python语言是高级编程语言，我们可以花费更多的
时间处理数据的内在含义，而无须花费太多精力解决计算机如何得到数
据结果。Python语言使得我们很容易表达自己的目的。
Python语言的缺点
Python语言唯一的不足是性能问题。Python程序运行的效率不如Java或
者C代码高，但是我们可以使用Python调用C编译的代码。这样，我们就
可以同时利用C和Python的优点，逐步地开发机器学习应用程序。我们
可以首先使用Python编写实验程序，如果进一步想要在产品中实现机器
学习，转换成C代码也不困难。如果程序是按照模块化原则组织的，我
们可以先构造可运行的Python程序，然后再逐步使用C代码替换核心代
码以改进程序的性能。C++ Boost库就适合完成这个任务，其他类似于
Cython和PyPy的工具也可以编写强类型的Python代码，改进一般Python
程序的性能。
如果程序的算法或者思想有缺陷，则无论程序的性能如何，都无法得到
正确的结果。如果解决问题的思想存在问题，那么单纯通过提高程序的
运行效率，扩展用户规模都无法解决这个核心问题。从这个角度来看，Python快速实现系统的优势就更加明显了，我们可以快速地检验算法或
者思想是否正确，如果需要，再进一步优化代码。
《机器学习实战》在amazon.com的机器学习品类中排名16，数据挖掘品
类中排名24。作者Peter Harrington是英特尔前任工程师，拥有5项美国专
利权，曾在学术刊物上发表过多篇文章。本书共四部分，讲述监督学习
和无监督学习，涉及k近邻算法、决策树、朴素贝叶斯算法、支持向量
机、AdaBoost算法、k均值、分类回归树等十几种算法，讲述每种算法
时都配有具体示例。本文摘自《机器学习实战》。第一个孩子的出生时间研究：程序员的统计思维
练习
作者 Allen Downey
Allen B. Downey是富兰克林欧林工程学院的计算机科学副教授，曾执
教于韦尔斯利学院、科尔比学院和加州大学伯克利分校。他先后获麻
省理工学院计算机科学硕士学位和加州大学伯克利分校计算机科学博
士学位。Downey已出版十余本技术书，内容涉及Java、Python、C++、概率统计等。他是自由书籍的倡导者，也是Google公司前客座
科学家。他的最新Think系列书还有Think Complexity, Think Python
等。
译者 张剑锋、陈钢
如果在Google上搜索这个问题，你会看到大量的相关讨论。有些人说确
实如此，也有人说这没根据，还有人持完全相反的观点：第一个孩子会
在预产期之前出生。
在这类讨论中，人们会用各种数据来证明自己的说法，常见的例子如
下。
“我有两个朋友最近都刚生了第一个孩子，两个宝宝的出生时间都比
预产期晚了差不多两周。”
“我的第一个孩子晚了两周才出生，我想我的第二个孩子会提前两
周。”
“我觉得这没道理，因为我姐姐是我妈妈的第一个孩子，她就提前出生了，我的几个表姐也一样。”
诸如此类的传闻称为经验之谈(anecdotal evidence)，因为它们基于非
公开发表的数据，而且通常是个人感受。在非正式场合，这类说辞没问
题，所以这里并不是说上述观点不对。问题在于，我们需要更有说服力
的证据和更可靠的结论。但这些经验之谈显然做不到这一点，原因如
下。
观察的数量太少
第一胎宝宝的妊娠期比较长，但这种差异可能在自然波动范围内。
这种情况下，我们需要比较大量孕妇的妊娠期数据才能判断这种差
异是否真的存在。
选择偏差
第一胎宝宝出生比较晚的父母会更有兴趣加入这样的讨论。这种对
数据进行选择的过程就会导致结果不准确。
确认偏差
相信这种说法的人会提供支持示例，而怀疑这种说法的人则会引用
反例。
不准确
传闻通常都是个人的经历，在记忆、表述和复述等方面都会不准
确。
那么，更好的做法是什么呢？
统计方法
为了解决上述经验之谈的种种不足，我们会运用以下统计学手段。
收集数据
使用大型全国性调查的数据，这些数据是为得出美国人口方面可靠
的统计推断而专门收集的。描述性统计
计算能总结数据的统计量，并评测各种数据可视化的方法。
探索性数据分析
寻找模式、差异和其他能解答我们问题的特征。同时，我们会检查
不一致性，并确认其局限性。
假设检验
在发现明显的影响时(比如两个族群间的差异)，我们需要评判这
种影响是否真实，也就是说是否是因为随机因素造成的。
估计
我们会用样本数据推断全部人口的特征。
通过这些步骤，绕过各种陷阱，我们就能得到更加合理也更可能正确的
结论。
全国家庭成长调查
美国疾病控制与预防中心(CDC)从1973年开始推行全国家庭成长调查
(NSFG)，目的是收集(美国)“家庭的生活、婚姻状况、生育、避孕
和男女健康信息。调查的结果用于……制定健康服务和健康教育计划，以及对家庭、生育和健康的统计研究”。1
1 参见 http:cdc.govnchsnsfg.htm。
我们会利用调查收集的数据来研究诸如“第一个小孩是否出生得较晚”之
类的问题。为了有效使用这些数据，我们需要理解这个调查是怎么设计
的。
NSFG是一个横断面研究(cross-sectional study)，意思就是它的数据是
一群人在某个时间点的情况。另一种常见方法是纵贯研究(longitudinal
study)，就是在一段时间内反复观察同一群人。
NSFG已经进行了7次，每次称为一个周期(cycle)。我们会使用来自Cycle 6的数据，这些数据是在2002年1月到2003年3月间收集的。
NSFG的目的是得到关于人口情况的一些结论，调查对象是15到44岁的
美国人。
参与调查的人称为被调查者(respondent)，一组被调查者就称为队列
(cohort)。通常，横断面研究意味着具有代表性，即目标人群中的每
一个人都有同等的几率参与调查。当然，实际很难实现这种理想状况，但执行调查的人会尽可能地做到这一点。
NSFG不具有代表性，而是有意进行了过采样(oversample)。设计者
所调查的西班牙裔、非裔美国人和青少年的比例都高于他们在美国人口
中的比例。过采样这些人群是为了确保其中的被调查者数量够大，从而
得到有效的统计推断。
当然，过采样增大了根据调查结果推断全体人口结论的难度。稍候我们
会继续讨论这一点。
习题1
尽管NSFG已经进行了7次，但它并不是纵贯研究。阅读维基百科页面关
于横断面研究和纵向研究可以弄清楚原因。
习题2
这个练习需要从NSFG下载数据。
1. 打开http:thinkstats.comnsfg.html，阅读数据的使用协议，然后点
击“I accept these terms”(假设你确实同意)。
2. 下载2002FemResp.dat.gz和2002FemPreg.dat.gz两个文件。前者是被
调查者文件，每一行代表一个被调查者，总共7643个女性被调查
者。后者是各个被调查者的怀孕情况。
3. 调查的在线资料地址：http:www.icpsr.umich.edunsfg6。浏览左侧
导航栏中调查的各部分，大致了解一下其中的内容。还可以
在http:www.cdc.govnchsdatansfgnsfg_2002_questionnaires.htm上
阅读调查问卷的内容。4. 配套网站提供了处理NSFG数据文件的代码。从
http:thinkstats.comsurvey.py下载，然后在放置数据文件的目录中
运行。程序会读取数据文件，然后会显示每个文件的行数：
Number of respondents 7643
Number of pregnancies 13593
5. 浏览一下代码，大致了解一下其功能。下一节会详细介绍。
表和记录
诗人、哲学家Steve Martin曾说：
“Oeuf”就是egg，“chapeau”就是hat。好像所有的东西在法语中都跟在
英语中的叫法不一样。
跟法语一样，数据库程序员的语言也跟我们的日常语言稍有不同。因为
我们要谈到数据库，所以有必要学习一些专业术语。
被调查者文件中的每一行都表示一个被调查者。这行信息称为一条记录
(record)，组成记录的变量称为字段(field)，若干记录的集合就组
成了一个表(table)。
看一下survey.py中的代码，就会看到Record和Table这两个类的定义，前
者是代表记录的对象，后者则是表示表的对象。
Record有两个子类，分别是Respondent和Pregnancy，两者分别是被调查
者和怀孕的记录。目前这些类暂时还是空的，其中还没有用于初始化其
属性的init方法。我们会用Table.MakeRecord方法将一行文本转换成一个
Record对象。
Table也有两个子类Respondents和Pregnancies。这两个类的init方法设置
了数据文件的默认名称和要创建的记录的类型。每个Table对象都有一
个records属性，是一个Record对象的列表。
每个Table的GetFields方法返回一个指定记录字段的元组(tuple)列表，这些字段就是Record对象的属性。
例如，下面是Pregnancies.GetFields：def GetFields(self):
return [
('caseid', 1, 12, int),('prglength', 275, 276, int),('outcome', 277, 277, int),('birthord', 278, 279, int),('finalwgt', 423, 440, float),]
第一个元组的意思从第1列到第12列是caseid字段，且类型为整数。每个
元组包含如下信息。
field
保存该字段的属性的名称。大部分情况下，我使用NSFG编码手册
中的名称，全部用小写。
start
该字段的起始列编号。例如，caseid的起始编号是1。可以在NSFG
编码手册中查询这些编号：http:www.icpsr.umich.edunsfg6。
end
该字段的结束列编号。例如，caseid的结束列编号是12。跟Python
中不一样，这里的结束列也是该字段的一部分。
转换函数
将字符串转换成其他类型的函数。可以用内置的函数，比如int和
float，也可以使用用户自定义的函数。如果转换失败，属性的值就
会是字符串'NA'。如果某个字段不需要转换，可以使用identity函数
或是str函数。
从pregnancy记录中可以得到以下变量。
caseid
被调查者的整数ID。prglength
怀孕周期，单位是周。
outcome
怀孕结果的整数代码。代码1表示活婴。
birthord
正常出生的婴儿的顺序。例如，第一胎婴儿的编号是1。如果没有
正常出生，该字段为空。
finalwgt
被调查者的统计权重。这是一个浮点值，表示这名被调查者所代表
的人群在美国总人口中的比例。过采样人群的权重偏低。
如果你仔细阅读编码手册，就会发现这些变量大部分都经过了重编
码(recode)，也就是说这并不是调查所采集的原始数据，而是根
据原始数据计算出来的。
例如，第一胎活婴的prglength在原始数据中有变量wksgest(妊娠周数)
时就等于该变量的值，否则就会用mosgest 4.33(妊娠月数乘以每个月
的平均周数)估计出来。
重编码通常遵循数据一致性和准确性原则。除非有特别原因一定要使用
原始数据，否则就应该直接使用重编码后的数据。
你可能还发现了Pregnancies有Recode方法，用来做一些其他的检查和重
编码工作。
习题3
在这个练习中，我们会编写一个程序来看看Pregnancies表中的数据。
1. 在survey.py和数据文件的目录中创建一个first.py文件，然后将下面
的代码输入或复制到文件中：
import surveytable = survey.Pregnancies
table.ReadRecords
print 'Number of pregnancies', len(table.records)
结果应该是13 593条怀孕记录。
2. 编写一个循环遍历表(table)，计算其中活婴的数量。查阅临床结
果(outcome)的文档，确认你的结果跟文档中的总结一致。
3. 修改这个循环，将活婴的记录分成两组：一组是第一胎出生；另一
组是其他情况。再看一些出生顺序(birthord)的文档，看看你的
结果跟文档中的结果是否一致。
在处理新的数据集时，这种检查对于发现数据中的错误和不一致
性、检查程序中的错误以及检验对字段编码方式的理解是否正确等
都是很有用的。
4. 分别计算第一胎宝宝和其他宝宝的平均怀孕周期(单位是周)。两
组之间有差异吗？差异有多大？
从http:thinkstats.comfirst.py可下载这个练习的答案。
显著性
在前面的练习中，我们比较了第一胎宝宝和其他宝宝的妊娠期。如果一
切顺利，读者会发现第一胎宝宝的出生时间比其他宝宝的出生时间平均
晚13个小时。
类似这样的差异称为直观效应(apparent effect)，意思就是似乎发生了
有意思的事情，但还不确定。我们还需要考虑以下问题。
如果两组的均值不一样，其他汇总统计量如何，比如中值和方差？
我们能更精确地描述它们之间的差异吗？
有没有可能这两组实际上是一样的，而我们所观察到的这种差异只
是随机产生的？如果是，那这个结论就不是统计显著的。
这种直观效应有没有可能是因为选择偏差或是实验设置中的错误导
致的？如果是，那么这种直观效应就是人为的，也就是我们意外创
造的，而并非发现了事实。习题4
学习统计学的最好方法就是从一个自己感兴趣的项目开始。有没有“第
一胎宝宝出生较晚”这类吸引你的问题来研究？
思考自己感兴趣的问题，例如传统观念、有争议的话题或是有社会影响
的问题，看看你能否将这些问题转换成统计学问题。
寻找能解决该问题的数据。国外政府是很好的数据来源，因为公共研究
的数据通常都是免费的2。另一个查找数据的好去处是Wolfram Alpha，其中收集了很多经过验证的高质量的数据集，网址
是http:wolframalpha.com。Wolfram Alpha的搜索结果是有版权限制
的，在使用之前应该阅读一下协议。
2 在撰写这段内容的时候，英国某法院规定“信息自由法案”(Freedom of Information Act)也适
用于科学研究数据。
Google和其他的一些搜索引擎也能帮你寻找数据，但网络上各种资源的
质量高低不一，判断起来不容易。
如果发现已经有人回答了你的问题，要仔细看看回答是否合理。数据和
分析中的缺陷可能会导致结论不可靠。如果是这样，你应该采用不同的
方法来分析数据，或者是寻找其他更好的数据来源。
如果已发表的论文回答了你的问题，那就应该能弄到原始数据，很多作
者都会在网上提供。但如果数据涉及个人隐私，最好联系一下作者，告
诉他你要如何使用数据，或是接受特定的使用协议。坚持到底!
《统计思维：程序员数学之概率统计》是一本以全新视角讲解概率统计
的入门图书。抛开经典的数学分析，Downey手把手教你用编程理解统
计学。概率、分布、假设检验、贝叶斯估计、相关性等，每个主题都充
满趣味性，经编程解释后变得更为清晰易懂。
本书研究数据主要来源于美国全国家庭成长调查(NSFG)与行为风险
因素监测系统(BRFSS)，数据源及解决方案的相关代码全部开放，具
体章节列出了大量学习和进阶资料，方便读者参考。本文选自《统计思
维：程序员数学之概率统计》。和孩子一起做一只电子宠物吧!
作者 Warren Sande, Carter Sande
Warren(父亲)毕业于加拿大里贾那大学电气工程系。一直在面向计
算机初学者教授软件基础课程，编写过大量广受欢迎的技术文档。
Carter——Warren之子，一个聪明、热情、好奇心强、喜欢思考问题
的小男孩，热爱计算机，喜欢弹钢琴和玩超级玛丽。很小的时候就开
始跟着父亲玩编程。
译者 苏金国我们将要建立一个简化了的电子宠物程序，正如前面所说的一样，这是
一种仿真。你可以购买电子宠物玩具(比如有一个小屏幕的钥匙链)，下载电子宠物软件，还有一些网站(如 Neopets 和 Webkinz)，就采用
了电子宠物的形式。当然，所有这些也都是仿真。它们会模仿一些真实
动物的行为，会饿，会感到孤单，会觉得累。要让它们快乐健康，你必
须给它们喂食，和它们玩，还要带它们看病。
我们的电子宠物会简单得多，与你购买或下载的电子宠物相比没有那么
真实，因为我只是想让你有一些基本认识，而且我不希望代码太过复
杂。不过你可以在这个简化版本的基础上，根据你的想法进行扩展或改
进。
我们的程序要具备以下特性。
对这个宠物可以有 4 种活动：给它喂食、带它散步、和它玩或者带
它看病。可以监测这个宠物的 3 种统计信息：饥饿感、快乐度和健康度。
宠物可以醒着或者睡觉。
饥饿感会随时间增加。可以通过喂食减少饥饿感。
宠物睡觉时饥饿感的增加会减慢。
如果宠物在睡觉，你做任何活动都会让它醒过来。
如果宠物太饿了，它的快乐度会减少。
如果宠物实在太饿了，它的健康度会减少。
带宠物散步会同时增加它的快乐度和健康度。
与宠物玩会让它的快乐度增加。
带宠物看病会让它的健康度增加。
宠物有 6 个不同的图片：
一个睡觉的图片；
一个醒着但什么也不做的图片；
一个散步的图片；
一个玩耍的图片；一个进食的图片；
一个看病的图片。
图片可以使用一些简单的动画。后面几节我们将看到如何把所有这些整
合在一起构成一个程序。
GUI
Carter 和我为我们的电子宠物程序创建了一个 PythonCard GUI。其中有
一些按钮用来完成活动，还有一些计量器显示重要的统计信息。另外还
留有一个位置显示宠物的图片(宠物正在做什么)。看起来就像右图这
样：
对应活动的按钮是一种 ImageButton 类型的 PythonCard 组件。利用这种
组件可以创建带图片的按钮，而不只是文本。各个计量器的组件类型是
Gauge。主图片是一个 Image 组件。标签是 StaticText 组件。
你可以使用 PythonCard 资源编辑器创建这样的 GUI。
算法要为电子宠物程序写代码，需要更明确地了解宠物的行为。以下是我们
要使用的算法。
我们把宠物的一“天”分为 60 个部分，每一部分称为一个“滴答”。
每个滴答的实际时间是 5 秒钟，所以宠物的“一天”就是我们实际时
间的 5 分钟。
宠物在 48 个滴答中都醒着，然后它想睡 12 个滴答。你可以把它叫
醒，不过这样会让它很不高兴!
饥饿感、快乐度和健康度的范围都是 0 到 8。
醒着时，饥饿感每个滴答会增加 1 个单位，快乐度每 2 个滴答减少
1 个单位(除非在散步或者玩)。
睡觉时，饥饿感每 3 个滴答增加 1 个单位。
进食时，饥饿感每个滴答减少 1 个单位。
玩时，快乐度每个滴答增加 1 个单位。
散步时，快乐度和健康度每 2 个滴答增加 1 个单位。
看病时，健康度每个滴答增加 1 个单位。
如果饥饿感达到 7，健康度每 2 个滴答减少 1 个单位。
如果饥饿感达到 8，健康度每个滴答减少 1 个单位。
如果睡觉时被叫醒，快乐度减少 4 个单位。
如果程序不在运行，宠物可能醒着(什么也不做)，也可能在睡
觉。
程序重启时，我们会统计过去了多少滴答，并对应过去的每个滴答
更新统计信息。
看起来好像规则很多，不过编写代码其实很容易。实际上，你可能还想
增加更多的行为，让它更加有趣。稍后就会给出代码(还会做一些解释)。
简单动画
并不总是需要 Pygame 才能完成动画。我们可以在 PythonCard 中通过使
用定时器完成简单的动画。定时器每隔一段时间会创建一个事件。可以
编写一个事件处理器，在定时器到时间时让某个事情发生。这就类似于
为一个用户动作编写事件处理器，比如说点击一个按钮，只不过定时器
事件是由程序(而不是用户)生成的。
我们的电子宠物 GUI 将使用两个定时器：一个用于动画，另一个用于
滴答。动画每半秒(0.5 秒)更新一次，滴答每 5 秒发生一次。
动画定时器时间到时，我们会所显示宠物的图像。每个活动(进食、玩
等)都有自己的一组图像来实现动画，每组图像将存储在一个列表中。
动画会循环显示这个列表中的所有图像。程序将根据正在进行的活动来
确定使用哪个列表。
试一试，再试一试
这个程序中还要使用一个新内容，这称为 try-except 块。
如果程序要做一件事情，而且这个事情有可能导致错误，那么最好提供
一种办法来收集错误消息并进行处理，而不是让程序直接停止。这可以
利用 try-except 块来做到。
例如，如果想打开一个文件，但是这个文件并不存在，你就会得到一条
错误消息。如果你没有处理这个错误，程序会在这里停止。不过，也许
你想让用户重新输入文件名(没准她只是敲错了)。利用 try-except
块，你可以获取到错误信息并继续执行。
对于打开文件的例子，try-except 块如下所示：
try:
file = open(somefile.txt, r)
except:
print Couldn't open the file. Do you want to reenter the filename?
你想尝试的部分(可能导致一个错误)要放在 try 块中。在这个例子中就是尝试打开一个文件。如果可以打开文件而不会导致错误，就会跳过
except 部分。
如果 try 块中的代码确实导致一个错误，就会运行 except 块中的代码
except 块中的代码告诉程序一旦出现错误该做些什么。你可以这样来
考虑：
try:
做这件事 ( 不做其他事情...)
except:
如果有错误，就做这件事
try-except 语句是 Python 处理错误所采用的方法，这通常称为错误处
理(error handling)。错误处理允许你编写可能出错的代码(甚至是很
严重的错误，倘若没有错误处理，这些错误在正常情况下甚至会让你的
程序停止)，使程序仍能继续运行。我们不打算在这本文里更详细地讨
论错误处理，不过我希望你能了解一些基础知识，因为在电子宠物代码
中就会看到错误处理。
下面来看这个代码，见代码清单。这里的说明已经对大部分工作做了解
释。这个代码有点长，所以如果你不想自己键入，也可以从这个网站
(www.helloworldbook.com)下载。PythonCard 资源文件和所有图片也
都已经提供。试着运行这个程序，然后再看代码，确保你能理解它是如
何工作的。
代码清单 VirtualPet.pysleeptest 函数使用了一个 PythonCard 对话框，不过稍做了调整。你可
能记得，PythonCard 要基于另一个名为 wxPython 的 Python 模块。正是
因为这个原因，安装 PythonCard 时要安装 wxPython。有时可以使用特
殊的 wxPython 参数来改变 PythonCard 的行为。在这里，我们改变了标
准 PythonCard 消息框，如右图所示。
我们把它变成一个有感叹号的对话框，还有 Yes 和 No 按钮，就像右图
这样。
即使你不能完全读懂这个代码也不用担心。如果你希望学习更多有关
PythonCard 和 wxPython 的内容，可以先看看 PythonCard 网
站：http:pythoncard.sourceforge.net。
在本文中，我们只是稍稍了解了计算机仿真的一点皮毛，知道了模拟真
实世界中一些方面的基本思想，比如重力和时间。实际上，计算机仿真
在科学、工程、医药和很多其他领域都得到了广泛使用。其中很多仿真
非常复杂，即使用最快的超级计算机运行也需要花费几天甚至几个星
期。不过钥匙链上的小电子宠物也是一种仿真，有时最简单的仿真也是最有意思的。
动手试一试
为电子宠物 GUI 增加一个 Pause 按钮。这会让宠物的时间停止，不论程
序是否在运行。(提示：这说明可能需要在 pickle 文件中保存“暂停”状
态。)
《与孩子一起学编程》一本老少咸宜的编程入门奇书!一册在手，你完
全可以带着自己的孩子，跟随Sande父子组合在轻松的氛围中熟悉那些
编程概念，如内存、循环、输入和输出、数据结构和图形用户界面等。
这些知识一点儿也不高深，听起来备感亲切，书中言语幽默风趣而不失
真义，让学习过程充满乐趣。细心的作者还配上了孩子们都喜欢的可爱
漫画和经过运行测试的程序示例，教你用最易编写和最易理解的Python
语言，写出你梦想中的游戏程序。本文选自《与孩子一起学编程》。从Python 3的bytesstr之别学编码Unicode
作者 Eli Bendersky, Steve Ferg
Eli Bendersky开发软件长达15年之久。在2008年开始使用Python,并且
是这门语言的主要贡献者之一。他使用过很多语言，但是最爱的还是
C和Python，业余时间爱好编程。他的博客http:eli.thegreenplace.net
Steve Ferg是一位程序员和系统分析师，同时他还是康奈尔大学哲学
系的博士。他的博客https:pythonconquerstheuniverse.wordpress.com
译者 李琳骁
译著有《编程大师访谈录》、《编程人生》等。现正在翻译Coding
Interview(程序员面试题解密)。
引子：bytesstr之别
Python 3最重要的新特性大概要算是对文本和二进制数据作了更为清晰
的区分。文本总是Unicode，由str类型表示，二进制数据则由bytes类型
表示。Python 3不会以任意隐式的方式混用str和bytes，正是这使得两者
的区分特别清晰。你不能拼接字符串和字节包，也无法在字节包里搜索
字符串(反之亦然)，也不能将字符串传入参数为字节包的函数(反之
亦然)。这是件好事。
不管怎样，字符串和字节包之间的界线是必然的，下面的图解非常重
要，务请牢记于心：字符串可以编码成字节包，而字节包可以解码成字符串。
>>> '�20'.encode('utf-8')
b'\xe2\x82\xac20'
>>> b'\xe2\x82\xac20'.decode('utf-8')
'�20'
这个问题要这么来看：字符串是文本的抽象表示。字符串由字符组成，字符则是与任何特定二进制表示无关的抽象实体。在操作字符串时，我
们生活在幸福的无知之中。我们可以对字符串进行分割和分片，可以拼
接和搜索字符串。我们并不关心它们内部是怎么表示的，字符串里的每
个字符要用几个字节保存。只有在将字符串编码成字节包(例如，为了
在信道上发送它们)或从字节包解码字符串(反向操作)时，我们才会
开始关注这点。
传入encode和decode的参数是编码(或codec)。编码是一种用二进
制数据表示抽象字符的方式。目前有很多种编码。上面给出的UTF-8是
其中一种，下面是另一种：
>>> '�20'.encode('iso-8859-15')
b'\xa420'
>>> b'\xa420'.decode('iso-8859-15')
'�20'
编码是这个转换过程中至关重要的一部分。离了编码，bytes对
象b'\xa420'只是一堆比特位而已。编码赋予其含义。采用不同的编
码，这堆比特位的含义就会大不同：
>>> b'\xa420'.decode('windows-1255')
'?20'
据说百分之八十的金钱损失皆因使用错误的编码导致，因此务必小心谨慎。
什么是编码？
基本概念很简单。首先，我们从一段信息即消息说起，消息以人类可以
理解、易懂的表示存在。我打算将这种表示称为“明文”(plain text)。
对于说英语的人，纸张上打印的或屏幕上显示的英文单词都算作明文。
其次，(原因稍候再述)我们需要能将明文表示的消息转成另外某种表
示(不妨称之为“编码文本”，encoded text)，我们还需要能将编码
文本转回成明文。从明文到编码文本的转换称为“编码”，从编码文本又
转回成明文则为“解码”。
这个过程有三点很重要。
第一点是在编码或解码过程中不得丢失任何信息。我们必须能做到来回
传递消息，从明文到编码文本，然后又从编码文本回到明文，取得的明
文跟我们一开始拥有的完全一样。举例来说，这正是为什么我们无法用
一种自然语言(俄语、汉语、法语、纳瓦霍语等)来编码另一种自然语
言(英语、印地语、斯瓦西里语等)。自然语言之间的映射关系太过松
散，无法保证一条信息能在来回的转换中不失真。
要求来回转换不失真，也就意味着明文和编码文本之间的映射必须又紧
密又精确。这就引出了第二点。
为确保明文和编码文本之间的映射非常紧密，也即，为了能非常精确地
规定编码和解码过程是怎么回事，我们必须非常精确地规定明文的表示
是什么样的。
例如，假定我们的明文是这样的：英美字母表的26个大写字母，加上空
格，及3个标点符号：句点(句号)、问号和短划线(连字符)。这就
形成了30个字符的明文字母表。需要数字时，我们可以直接拼写出来，比如：six thousand seven hundred forty-three(六千七百四十三)。另一方面，我们可能希望明文是这样的：26个大写字母，26个小写字
母，10个数字，空格符，及十几种标点符号，包括句点、逗号、双引
号、左括号、右括号等等。于是我们又得到一张75个字符的明文字母
表。
一旦精确地规定了消息的明文表示是什么样的，比如上面的30个字符的
字母表，也许是75个字符的字母表中有限的字符序列，我们就可以设计
一套系统(编码，code)，能对用这张字母表写成的明文消息进行可靠
的编码和解码。这类系统最简单的一种是明文字母表里的每个字符在编
码文本中有一个且只有一个对应的表示。举个大家都熟悉的摩尔斯电码
的例子，其中明文“SOS”对应的编码文本为... --- ...。
当然，在现实生活中，明文字母表中字符的选择受到编码文本上技术限
制的影响。假定存储编码消息有如下几种技术可供选择：一种技术支持
256个字符的编码字母表，另一种技术只支持128个编码字符，第三种技
术只支持64个编码字符。如果我们清楚自己可以使用支持更大编码文本
字母表的技术，我们自然而然就能将明文字母表扩展得比以往大得多。
反之亦然。如果确定明文字母表一定要非常大，我们就会明白必须找到
或设计一种能存储大量编码字符的技术。
这就引出了下面的话题，Unicode。
Unicode
Unicode的设计初衷是成为一套系统，可以存储现存所有人类语言的所
有明文字符的编码表示。英语、法语、西班牙语、希腊语、阿拉伯语、印地语、汉语和亚述语(楔形文字)等。
这些字符数量庞大。
因此，Unicode计划的首要任务就是把所有这些字符罗列出来，数个
数。这就是Unicode的前半部分，通用字符集(Universal Character
Set)。(真正谈及Unicode时，不要把明文字符叫做“字符”，称之为“码
点”(code points)。)
完成前面的工作后，你还得想出一种技术，以储存全部对应的编码文本
字符。(用Unicode的话来说，编码文本字符被称作“码值”(codevalues)。)
实际上，Unicode定义了不止一种方法，将码点映射到码值。这些方法
都有自己的名字。其中部分名字以“UTF”开头，其他以“UCS”开头：
UTF-8、UTF-16、UTF-32、UCS-2、UCS-4等等。命名规范是“UTF-<码
值的比特数>”和“UCS-<码值的字节数>”。有些方法(如UCS-4和UTF-
32)功能相若。参看维基百科Unicode相关页面。
关于这些方法最重要的一点是，有些方法是定长编码，有些则是变长编
码。基本思想是定长编码都很长，如UCS-4和UTF-32都有4字节(32比
特)长，长到足以hold住未来可期的最大码值。
相比而言，变长编码则设计成简短但可扩展。例如，UTF-8可以使用少
至8比特(1字节)来储存Latin和ASCII码点。不过，它还有一种“接下一
个字节”机制，以便在必要时(有可能用来表示中文字符)可以使用2个
字节甚或4个字节。对于西方国家的程序员，这就意味着UTF-8既高效
又灵活，UTF-8之所以成为交换Unicode文本事实上的标准编码，原因正
在于此。
总之，不存在所谓单一的Unicode编码系统或方法，而是有好几种编码
方法；打算跟别人交换文本时，你需要明确指定自己采用了哪种编码方
法。
比如，是不是这样：
或者这样：
或者其他编码方法。
这又回到我前面提过的话题。为什么要用Unicode来编码？
前文提到：
首先，我们从一条信息即消息说起，消息以人类可以理解、易懂的表
示存在。
其次，(原因稍候再述)我们需要能将明文表示的消息转成另外某种
表示(不妨称之为“编码文本”)，我们还需要能将编码文本转回成明
文。从明文到编码文本的转换称为“编码”，从编码文本又转回成明文
则为“解码”。
好的。现在是时候探讨这些原因了。为什么我们会想着将明文表示的消
息转换成另一种表示呢？
一个原因当然是我们想要保密。我们想通过加密(encrypting)和解密
(decrypting)来隐藏消息的明文，基本上编码和解码的算法要求保密
和不扩散。
不过，这是个截然不同的主题。眼下，我们对保密不感兴趣；身为
Python程序员，我们感兴趣的是Unicode。因此：
身为Python程序员，为什么我会需要能将明文消息转换成某种编码表
示……比如UTF-8之类的Unicode表示？
假定你正舒舒服服地坐在电脑前，用你最喜欢的文本编辑器，用
Python(特别是用Python 3+)编写标准的Hello World程序。你的整个程
序只有下面这一行代码。
print(Hello, world!)
这里的“Hello, world!”就是明文。你在屏幕上看得见它。你可以阅读，明白它的含义。它就是一字符串，你可以对它执行字符串类型的标准操
作，比如截取一个子串(切片)。
不过现在假定你准备将这个字符串“Hello, world!”放到一个文件中，并
将该文件保存到硬盘上。也许你打算将这个文件发送给朋友。
这意味着你必须将那可怜瘦小的字符串逐出Python程序中温暖、和睦、安全的家，那里它就以明文字符的形式存在。你必须把它推入文件系统
那阴冷、没有人情味的外部世界。那里它不会以字符的形式存在，只有
1和0，一堆杂乱的点点滴滴，充电和未充电的微粒。而这意味着原本幸
福瘦小的明文字符串必须以1和0的某种特定配置来表示，这样一来，有
人想要获取那组1和0，将它转换回可读的明文，完全可以办到。
将明文转换成1和0的特定配置的过程就是编码的过程。为了将字符串写
入文件中，你必须采用某种编码系统(比如UTF-8)对字符串进行编
码。要从文件中取回字符串，你又必须读入文件，对这组1和0进行解
码，转回成明文。
从文件读写字符串时需要对它进行编码和解码并不是新鲜事，这不是
Python 3对Unicode的新支持引入的额外负担。其实你一直在做这件事。
不过就是不怎么明显而已。较早版本的Python采用ASCII编码方案。因
为在那些久远的年代，也只有ASCII这种编码方案，你不需要指定自己
想要读写ASCII编码的文件。Python直接假定文件默认就采用ASCII，自
动进行编码和界面。但是，无论你是否意识到这点，无论何时，只要你
的程序从文件读写字符串，Python都会在幕后忙碌，为你完成编码和解
码工作。
综上，这就是为什么身为Python程序员的你需要能将文本编码成UTF-
8(或其他某种编码：UTF-16、ASCII等)，或将UTF-8转回到文本。你
需要将字符串编码成一组1和0，这样才能将这些1和0放进文件，然后将
文件发送给其他人。
什么是明文？
前面提到编码解码过程有三点需要注意，我探讨了前面两点。下面是
第三点。
明文和编码文本之间的差别是相对的，且依赖语境。
作为程序员，我们会把书面文本当作明文。但也要从其他角度分析事
物。例如，我们可以把口头文本看作明文，而书面文本看作编码文本。
从这个角度来看，书面语是编码过的口语。世界上有很多种不同的编
码，将口语编码成书面语。举例来说，有古埃及象形文字、玛雅象形文
字、拉丁字母、希腊字母、阿拉伯文、中国的表意文字，还有非常平滑
的天城文(Devanagari)，即使是简写体也呈锋利尖锐的楔形。这些都是口语词的书写编码。正如英国政治哲学家托马斯·霍布斯(Thomas
Hobbes)所言，它们都是“我们也许赖以记住我们思想的记号”。
这又提醒我们，在不同的语境中，即使言语本身——语言——也可能被
看作是一种编码形式。在大部分早期现代哲学中(想想霍布斯和洛
克)，言语(或语言)基本上被认为是思想和理念的编码。当我将我的
想法编码成语言说出口并对你说的时候，沟通就发生了。你听到我言语
的声音，将其解码成想法。当我经由语言成功地将自己心里的想法传递
到你心里的时候，我们的沟通也就成功了。由于我的言语，你心里的想
法跟我心里的达成一致时，你便理解了我。(参看Ian Hacking的Why
Does Language Matter to Philosophy?)
最后，注意在其他语境中，“明文”甚至不是文本。明文是声波的(比如
音乐)，可以编码成mp3文件。明文是图像的，可以编码为gif、png或
jpg文件。明文是电影的，可以编码成wmv文件。不一而足。
编码和解码无所不在。
英文原文：The bytesstr dichotomy in Python 3
Unicode for dummies — Encoding如何构造团队Python开发环境
作者 BePROUD公司资深工程师
BePROUD是一家专注于Python开发的公司，因云集了众多行业精英
而闻名于日本国内。
译者 盛荣
曾就职于爱立信中国，长期从事通信、IT设备的研发、测试等相关工
作。喜爱脚本语言，特别是Python。希望将Python等脚本语言更好地
应用于自动化测试等领域之中。
在个人开发环境中，可以根据自己的喜好进行源代码管理，一些想法以
及信息也可以自行记录。
那么由多人共同开发一个项目又是怎样的情形呢？首先，开发的成果需
要在团队成员中共享。其次，测试开发成果的测试环境也需要统一建
立。接着，开发的方法与信息也要在团队成员中共享。可见团队成员之
间的沟通必不可少。那么，如何使团队开发高效进行？如何构建团队开发环境？本文就这些
问题的相关方法和有用的工具进行介绍。
在公共服务器上建立用户·设置权限
首先，我们介绍一下在团队公共服务器上建立用户并设置权限的操作步
骤。
用户与用户组的建立
建立开发团队的用户和用户组。在开发时使用的服务器上运行着各种各
样的应用程序，如果都使用root用户的话，在安全性上会存在很大隐
患，我们也不期望那样。在公共服务器上，建议使用普通用户权限运行
开发程序。
首先建立一个开发用户组。然后如下所示，采用root权限和groupadd命
令，建立名为dev的用户组。
sudo groupadd dev
接着建立用户。使用adduser命令，创建bpbook用户组，并在命令行中
使用--ingroup选项将其添加到之前建立的dev用户组中。
sudo adduser bpbook --ingroup dev
这样一来就在系统中建立了一个名为bpbook的用户。如果要删除用
户，可以直接使用userdel命令进行删除。
sudo userdel –r bpbook
Sudoers
普通用户有时会需要使用超级用户(root)的权限去执行一些命令。这
时可以通过etcsudoers文件中的设定给予普通用户执行特定root命令的
权限。接下来，我们通过编辑该文件，赋予之前建立的bpbook用户一定
的权限。编辑sudoer文件需要执行visudo命令。
sudo visudo上面命令执行后，将会打开etcsudoers文件。下面是通过etcsudoers文
件赋予bpbook用户权限的一段样例：
%dev ALL=(ALL) ALL
bpbook ALL=(ALL) ALL
上面的设定含义就是赋予dev用户组以及下面的用户bpbook使用sudo命
令的权限。第一行是赋予用户组，第二行是赋予用户权限，连在一起表
示赋予二者可以执行root权限的所有命令。
sudoers文件的权限配置格式如下所示：
%用户组名 主机名=(权限)命令
用户名 主机名=(权限)命令
virtualenv
当多数人共同开发项目时，不能因为某个组员添加了某个库或者变更某
个版本，而影响整个团队的开发环境。在使用Python开发时，推荐使用
virtualenv。因为使用了virtualenv，能使开发环境的变更(如安装新的库
或者版本升级)仅仅对行为者本身的开发环境有效。因此，我们必须有
效使用virtualenv构建多人开发环境。
任务管理系统
为推进团队开发的顺利进行，首要任务就是能够准确把握每个开发任务
的负责人及其开发进度的状况信息，并加以梳理。在这里，管理任务就
需要用到任务管理系统(Issue Tracking System :ITS)。
ITS是在开发过程中创建任务、追踪状态、管理任务的系统。Trac和
Redmine是以ticket为单位进行任务管理的系统。使用ITS时，不仅可以
管理任务，还经常作为创建ticket信息并录入工作任务的入口。
ITS中会根据不同情况给创建的ticket分配不同的状态(如新建、进行
中、解决、已验证、关闭、保留等)、给予不同的优先级属性(紧急、高、普通、低)、维护责任人信息、列出完成期限，还可以查询上述所
有信息。因此，对于整个项目状况的把握是非常有利的。同时，将开发进行任务分割，通过ticket的形式分配给项目组成员，这
也是一种项目开发的手段，称作ticket驱动开发。由于同Agile开发有着
很好的匹配关系，因此我们也将其投入到最近的开发中进行使用。
版本管理系统
在团队开发的过程中，需要有一个地方集中管理每位成员开发的代码成
果。另外，随着开发的不断推进，也会产生各种各样的BUG，在这个时
候，为了了解BUG是在什么时候混进来的，需要能对开发的代码进行历
史追踪。
于此，版本控制管理系统(Version Control System：VCS)就能发挥作
用了。版本管理系统，如其名字所示，是管理源代码及其变更历史的系
统。VCS主要代表Subversion这样集中型的管理工具，和Mercurial、Git
这样的分布式版本管理工具。本文使用的是Mercurial。
Mercurial与Trac联动绑定
将ITS与VCS进行系统绑定，就可以使得项目中ticket和源代码变更过程
更加清晰。本节对Mercurial和Trac的系统绑定方法进行说明。Trac与
Mercurial进行系统绑定需要安装Trac的mercurial-plugin插件。而
mercurial-plugin插件由Subversion进行管理，所以首先需要安装
Subversion。
sudo aptitude install subversion
Subversion安装完毕之后，就可以下载Trac的mercurial-plugin插件了1 。
1 其实这是svn checkout的命令，而不是单纯意义的下载。——译者注
svn co http:svn.edgewall.comrepostracplugins0.12mercurial-plugin
下载完成后就可以安装该插件了。
cd mercurial-plugin
python setup.py install
mercurial-plugin插件安装完成之后，需要通过编辑trac.ini文件2绑定Mercurial和Trac。首先，添加使mercurial-plugin插件生效的componentes
段，如下所示：
[components]
tracext.hg. = enabled
2 该文件是在trac建立的工程conf目录下，如homeeronshebpbookconf。——译者注
接着指定代码库的类型和代码库的目录。在trac段中的repository_type指
定表示Mercurial的hg，在repository_dir中指定代码库的路径(本例中
是varhgbpbook)
[trac]
repository_type = hg
repository_dir = varhgbpbook
经过以上设定，就可以使Trac与Mercurial绑定，Mercurial中的更新日志
也会反应在Trac中。
小结
本文介绍了团队开发的环境构建，给出了公共服务器上的用户与用户组
建立并设置权限的操作流程，以及ITS、VCS等在团队开发中适用的各
种工具。
灵活运用Mercurial、Trac这类工具，使开发成果可以在团队成员中共
享，这将会大大推进团队开发的效率。另一方面，Skype、DropBox、Google Docs等工具的使用，又可以建立通过网络进行沟通并共享开发
信息与数据的桥梁，使得开发可以随时随地进行，大幅降低了差旅和通
信的成本。
团队开发中复杂的情形有很多。只有灵活运用各种工具，提高效率，才
能取得一定成果。使用各类工具提高开发效率无疑是一种乐趣，大家也
可以尝试将本文介绍的工具投入到各自的团队开发项目中使用一下哦。
《Python开发实战》来自于真正的开发现场，由BePROUD公司的资深
员工执笔，凝结了老牌程序员在日常工作中积累的开发经验，是一本难
得的好书。本文选自《Python开发实战》人物罗晨：梦想照进现实，一个独立开发者的田园诗他种有机蔬菜、他搞全景摄影、他自己设计制作硬件产品，他还是个
程序员，并以此为生。罗晨，他是Markdown编辑器Mou的作者，他
就是一位生活在农场上的独立开发者。提起我们这个时代的码农们，人们联想到最多的是“加班”、”赶进度“、“不健康的生活方式”……好
像这些是和编程密不可分的衍生品。然而，在罗晨身上我们看到另外
一种可能性，我们可以，活出自己想要的现实
MouStand——让梦想变成现实
我十分喜欢 Mou 的 logo，这个形状是想象出来的，之前它在现实中
并不存在。但是我把它变成了现实。
为什么要自己做一个 Markdown 编辑器?
我刚开始知道 Markdown 这个语言，就觉得挺有意思，想找一个
Markdown 的编辑器。当时有两个收费的编辑器。其中一个中文支持不
太好，老跳，一打中文的时候那个键上下跳。另外一个预览界面和编辑界面是分开的。要想预览就得点一下预览的命令，不能同时显示。我想
要左边编辑右边预览，这样就可以实时预览，一边编辑，一边显示的，可是没有。那没办法，市面上没有只能自己做。然后我就做了。
Mou 的同步滚动还不精确。因为我这个是按照左右两个窗口的长度，百
分比来算。同步比较难做。如果要精确匹配只能按元素。比如左边是二
级标题，第一个二级标题对右边的二级标题，这样来算定位才准。但是
我现在还不知道怎么做。
你很喜欢这个 Mou 的这个 logo?
是的，Mou 现在的 logo 是方迟设计的，我非常喜欢。第一个版本的
logo 是我画的，但画的不好。后来在丁一的介绍下能够有幸请到方迟为
Mou 重新设计 logo。我当时的要求就是简洁，突出 M。我觉得他设计
的非常棒，这种造型是方迟想象出来的，之前现实中并没有这种形状的
物体。我非常喜欢这个造型，以至于我想把它变成实物。但设计 logo
和把它变成实物是两码事。当初设计 logo 的时候并没有考虑到要做成
实物。
Mou 最初(第一个公开测试版 Mou 0.6.0)的 logo，2011 年 9 月，罗晨
设计：
Mou 0.6.4 的 logo，2011 年 10 月，方迟设计：Mou 0.7.2 的 logo，2012 年 8 月，方迟设计改进，沿用至今：
既然关于 MouStand 这个实物所有的一切都是你自己设计的，那就从包
装讲起吧。
包装我考虑过纸盒，但是不太结实。瓦楞纸是柔性的，柔性的一压就压
坏了，怎么办？现在快递都比较暴力，所以我们需要刚性的包装。这个
木制包装盒是指接结构。它有一个优点就是稳固、特别结实，可以保证
长途的运输当中里面的东西不受损害。材料当然是越轻越好，轻点可以
省邮费，但是不能太轻，因为还要考虑到强度。当时我就考虑两种材
料，一种是桐木，非常轻。第二种是松木。但是桐木要是这个厚度不结
实。一踩上去就碎了。松木的踩上去没什么问题。
发货的时候木盒的外面还要套一个瓦楞纸箱的，刚柔并济，多一层保
护。你看上盖只采用这两根木条，而这边没有。这是为什么呢？这个刚好可
以扣住，如果这边再加两根木条，就扣不住了，会顶住 MouStand 上边
这两个腿，就需要把这个盒子再高一点，那样就浪费材料了。考虑到强
度、也考虑到节省材料。尺寸都是匹配的，为的是最大限度的节省材
料。
包装上的标签也是我自己设计。我的风格是属于简洁素雅的风格。大面
积留白，上面一条是黑底白字，其余是白底黑字。盖子里面的标签注明
它的详细规格。每个 MouStand 重 36 克(一个 Color Packs 套装包含 4个 MouStand，木盒重 200 克。但是有误差，误差我故意写的大一些。
比如木头里面有水分，水干了之后会变轻，湿度大还有可能变重。
这些东西加起来，再加外面套一个纸箱超不过 500 克。为什么 500 克？
因为发货我采用邮政，EMS 是按 500 克来算，500 克以内是一个价格，501 克又加钱就不划算了，所以保证 500 克以内。
再说说产品本身。
我去年用银子，锤子凿出来一个比这个小的形状。用银子敲成银丝。再
折一下。也是用锤子敲一下，折三次成这样，比这个小。
去年(2012 年 7 月)用银子凿出来的 Mou 的 logo：
再回到 MouStand，开始时，我想做 logo 那种颜色，但是调不出来。这
个加工步骤是这样的，先把一块平面的铝板切割成平面形状，切割好以
后，再把边角进行手工打磨，因为机器打磨好之后有毛刺。打磨好之
后，第二步进行折弯，把平面的图形折三次，然后就成形了。变成一个
基本的形状之后，在进行喷砂处理，使表面形成一种喷砂的效果。说白
了这个喷砂就是用喷枪喷细砂。用细砂粒撞击它的表面，撞出无数的小
坑，就形成了喷砂效果。喷砂的功效一个是美观。另外，折弯了之会有压痕(折弯痕)，喷砂可以把痕迹减弱。这还有第四步，阳极氧化处
理。喷完砂之后表面都是铝，进行阳极氧化，使表面生成一层三氧化二
铝。三氧化二铝很硬，莫氏硬度达到8。像蓝宝石、红宝石、磨刀石主
要成分都是三氧化二铝。氧化成三氧化二铝是对它表面进行一种保护。
现在的效果就很硬，不容易划伤。也比较光滑。
然后再进行染色。你看到的这个颜色实际上不是油漆，而是墨水。氧化
后，三氧化二铝的结构是透明的孔状结构，用墨水一染的话就渗透进
去。最后一步进行封孔，用开水煮，把颜料封在里面。(颜料)已经渗
透进去了，比油漆要好用。MacBook 表面也是这种工艺，只不过那种喷
砂喷得比较细。我们这个喷砂颗粒大一些。颗粒大是因为受到加工工艺
的限制，工艺达不到那么高。另外，折弯的时候，痕迹很明显，如果用
细砂喷痕迹非常明显，掩盖不掉，所以只能用中等颗粒的，刚好把折痕
掩盖掉。折的时候机器有两个尖一压，每个折弯处都有一条道，现在不
容易看出来，是用喷砂给处理掉了。这一块还有脚垫(绒布贴)，对下
面进行保护。
刚才问到后面的孔是干什么的？最后的阳极氧化要把工件作为电极浸到
溶液里。这个是导电的，必须有个触点，所以在这开了个孔，让这个地
方一直导电。进到溶液里氧化，一通电，表面生成氧化膜。刚开始做样品的时候没有开这个孔，是在这两个位置(M上面的两个
尖)夹着的。夹着的时候表面出现夹痕，夹痕非常难看。所以正式生产
的时候就在后面开了个孔，让它把夹痕隐藏到里面，更美观一点。
MouStand 尺寸为什么这么定？
尺寸还有角度，要兼顾(iPhone 和 iPad)水平模式和垂直模式，都能
放。这个水平放置没问题，竖着放也没问题。两种模式都支持的情况
下，保证它体积最小，就找到这么一个平衡，再大了浪费。这个造型可
以两边放。这边放一个，比如两个人，你在这边玩手机，我在这边玩这
个。两个腿之间的间距也是考虑过的，如果间距再大点儿手机竖着放就
拖不住了，漏下去了。原型设计的时候，我是用纸做的，用的是一百五十克卡纸。承重没法
测，只是测角度，用 iPad 比划这把角度估计出来，看什么角度倒不
了。前面脚的长度，参考一下 iPhone、iPad 的厚度，长一点，这样就翻
不过去。
MouStand 的原型是用纸做的：
具体加工是怎么完成的?我是把设计图纸做好，然后加工工艺确定，再联系代工厂。这个木盒是
山东曹县代工。做了两百个，还是好说歹说人家才给做。这个属于限量
生产，不像人家大工厂批量生产，那样成本非常低。铝合金加工是在广
州。标签还有木头玩具的纸盒是我自己买的打印纸，打印机、切纸机，完全是自己做。木头玩具纸盒上的图形和图解是我用 Silo 建模软件建出模型，截图后再
导入 Illustrator 里描出来线框图，包装也是我自己做的。这个是三根木
条。这是附赠的玩具。这个玩具是现有的，我只不过弄了一个包装。这
个玩具叫孔明锁，据说在孔明的时候就有了。
木头玩具包装盒上的图形是先用 Silo 建模，再用 Illustrator 描出来的：这个贴纸也是我自己做的。想贴哪就贴在哪。你把后面的那层纸撕下
来。这个像 GitHub 学习，GitHub 不是也是有一个 shop，也卖贴纸的、卖杯子，它也是以它的 logo 发展的周边产品，我这也是以 logo 发展的
周边产品。你的网站做的挺好看的，简洁漂亮。
就是几张截图往上一堆。刚开始学摄影的时候学过 Photoshop，这都是
之前积累的基础，这些知识全用上。做 MouStand 网店，要摄影，把产
品拍下来，怎么拍好看，弄个摄影小棚子，布好灯光、角度、支架弄
好，拍好，再调调亮度。把照片弄的好一点。拍照片大概弄了两天。
你定价是怎么定的？卖了多少了？
价格就是成本加上跑腿的路费，从我住的农场到邮局来回骑自行车要
20 公里。这个我定的是每一个二十九刀。按这个价格来算。参考了一
下国外市场 iPad 支架的价格。一般三十刀，我的是二十九刀。只不过
我们是四个一起卖，两个一起卖，就显得比较贵。其实一个拿出来，二
十九刀，在国外来说是很正常的一个价格。但是木盒只有两百个，太多
了木盒太占地方，家里也放不下。
彩色一百套，黑白的一百套，一共两百套。现在卖了二三十套。都卖了
也挣不了多少钱。主要是自己做着玩，有这个乐趣。我面向的客户主要
是国外的，国内的少。要是弄个淘宝店铺，我感觉有点麻烦。国内目前
卖了八套。
以后还想继续做实物硬件吗？
不想再做实物的东西，麻烦。因为做一套东西考虑的东西太多了，方方
面面都要考虑。还要存货还要发货。做软件多省事。玩过去就过了。玩
过就不好玩了。
误入歧途才能发现桃花源
我想做点工具，为我以后前端工程师的职业做好铺垫，但是写到最后
发现写软件已经有收入了，可以不找工作了。
你在哪上的大学？
我大学上的太原科技大学。我是 2005 开始， 2009 年毕业的。当时学的
是通信工程，我以为自己会感兴趣，其实没有。现在这个专业毕业的有一半都不是做本专业工作的。有的人做通信搞信号基站，要不就是楼道
里面安个无线网。我觉得不好玩，所以后来就玩起了全景摄影。
我在你的网站上能看见一个叫 86vt 的网页，里面有你们大学的地图和
很多地点的全景照片，感觉就像自己在校园里面行走一样。
86vt 是我做的我们学校的(全景摄影)虚拟校园网站。我考大学之前，看这个学校网站挺烂的，只有两三张图片，觉得很破。入了学以后觉得
还挺漂亮的，是学校网站没有体现出来，后来我就想用一种方法把学校
风格体现出来。我们学校虚拟校园 86vt 是上学的时候完成的一个项
目。
这个项目实际上一个月就做完了。但是前期准备学知识学的时间比较
长。我 2007 年开始学全景摄影方面的知识，学完之后 2008 年 4 月份才
开始做这个项目。这里面有三十多个场景。拍的时候都要选人少的时
候，人多了图片拼接的比较难处理，全景不是拍一张就完了，是拍很多
张拼起来才能形成一张。如果你是走动的，在这拍了一张，又跑到那了，那张拍上你了，那就半截半截的。
这个全景摄影具体怎么拍？
我用的 8 毫米鱼眼镜头，云台、三脚架。云台就是保证旋转的节点精
确，没有视差，才好拼接。云台上面有刻度。现在好一点儿的云台都是
带锁的。比如 90 度一个锁，这么一转响一下，九十度到了，非常方
便。现在我要拍那样一幅照片的话只要半分钟左右。需要拍四张，九十
度拍一张就行。拍完之后回去拼接。比较细的处理一个拼接照片要一个
小时。要是做个大概，几分钟就好了。
你从什么时候开始写代码的？
在学校的时候搞摄影，要把照片放在网上，然后开始研究网络相关的知
识。网页、空间、域名。因为刚开始想把照片放到网上，才接触到互联
网知识(技术方面)。如果我不摄影，可能我就接触不到互联网(技术
方面)。
有个学长(舒文亮)，比我大一级，还没毕业就在雅虎上班了。我们觉
得他很厉害。我做这个 86vt 网站的时候，也向他请教了不少问题，那
个时候他就是我的偶像。他当时已经是前端工程师了，也是转了好几
圈，然后又回到前端，他现在在阿里巴巴带团队。我当时就想，我也想
像他那样厉害，我也要学这个，我也要当前端工程师!实际上在大学我
对互联网还不怎么了解，毕业以后想找这么一个工作怎么办？那就学
呗。学只能在家学，等什么时候把前端工程师相关的知识学完之后，再
找个前端的工作做。所以毕了业之后要选择找工作还是回家待着，我就
想回家待着，家里也支持，在家就在家吧，也不指着我工作。
然后你就在家学习前端知识？
毕业后回到家先开始学的 HTML，CSS 和 JavaScript。学了几个月后做
出了 resizeMyBrowser，接着又在 resizeMyBrowser 的基础上做了个
Safari 浏览器插件 Resize。
之后又了解到前端优化方面的知识，通过压缩 CSS，JavaScript 等文件
能够提高页面初次下载速度，我就想找个好用的压缩工具，当时都是命令行的，就是在 Mac 平台都是命令行的工具。我觉得太麻烦，想要一
个图形界面，但是市面上没有。没办法只能选择自己做。从那个时候开
始学 Objective-C，想着做一个 YUI Compressor 的图形界面，方便批压
缩 CSS、JS 文件。于是做了我的第一个 Mac 应用 Smaller。
再后来了解到 Markdown，又写了 Mou。
其实我做的这些个工具基本上都是跟前端工程师这个职业相关的。实际
上作为一个前端工程师需要做这些工作，用这些工具可以提高我的工作
效率，我想做点这些工具，为我以后前端工程师的职业做好铺垫。工作
的时候效率会高一点。
可是写到最后发现写软件已经有收入了，找前端工程师的工作不是必要
的了。我是从摄影转到学 Web 的知识，想成为 Web 前端工程师，却在
学习 Web 前端方面知识的过程中不知不觉的转成了开发软件。上次在
QCon 认识个一淘的朋友(葛灿辉)，他说我更像一个产品经理，不像
程序员。
你现在应该可以找到前端的工作了吧。
其实已经有很多公司找过我了，Mac 软件开发方面的居多，Web 前端也
有。有一个德国的公司 Wunderlist，邀我去做 Objective-C 开发。但是我
家人都在这，出国太麻烦了。阿里的 Mac 开发团队邀请过我两次，只是第一次的时候还没有去工作的打算，第二次的时候我正打算做硬件，做这个支架，也抽不开身。现在也暂时还没有去公司工作的打算，在家
自由惯了，去公司会不太习惯吧。还有腾讯也邀请过，做前端工程师。
他们说我网站设计的好，其实我觉得做的很简单，就是几张截图而已。
你能有这样的思路，做出现在这些产品和你有充足的闲暇时间有关系
吧？
肯定有关系。我在软件开发前期的时候非常苦恼。有时候一个问题连着
一两个星期没有思路，就整天在那想，睡觉的时候还想，一天到晚不停
地想，那才能想出来。可能在公司没有那么多的时间想了。
我做的很多东西都是以玩为主。可能跟小时候经常拆东西有关。我父母
给我比较大的自由。上学学习方面不会逼着我。但是我自己知道学。考
高中、大学，报志愿的时候他们也不会干涉，都是我自己决定。他们相
信我。
你现在生活在农场上吗？在家都干些什么？
在家比较闲，闲着没事。软件开发前期比较忙，后期就是维护了。维护
每天回回邮件，客户支持。实在闲着没事了做做新功能，不像前期那么
紧。
我家在天津汉沽区附近的汉沽农场，那个地方属于河北，是河北省在天
津的飞地。说是农场，实际上就是很多农村连在一块。这块地是在天津
市境内，但是属于河北省管。
我现在每天早上就在园子后面浇浇地，种种菜。就在我家房后面那么一
块。我种了十颗人参就活了五颗。还种了一颗蓝莓树，蓝莓属于灌木，很矮，就像周围马路边的灌木，上面结小小的蓝莓果。我都是在淘宝上
买的种子。我经常会给葱们，还有蓝莓喷点儿水，不打药，纯天然绿色
食品。闲的没事儿我会打打沙袋，锻炼身体。邮局离我家10公里，每次骑车去
邮局发货(Moustand)往返就要两个小时。途中，会经过乡间小路，天
气好的时候，景色还是不错的。你以后有什么打算？
在家待着腻了，再去工作，找份工作，体验一下上班的感觉，我还没上
过班呢，不知道上班什么感觉。读《码农》 吐吐槽 还能赚银子!活动规则：在吐槽贴中留言，选出任何一期中你最喜欢的文章和最不喜
欢的文章，即可获得图灵社区银子 2 两!凡吐槽吐得掷地有声者，加赠
银子 3 两(共 5 两)!(怎样使用银子兑换图书)
活动时间：本活动长期有效。践行如何教编程，当你面对一双渴望的眼睛
作者 Philip Guo
斯坦福大学计算机科学博士。研究领域主要涉及人机交互、在线教
育、软件工程等。他在2010年自己构建了一个基于自由网络的编程学
习工具叫做Online Python Tutor(pythontutor.com)，目前已有超过20万
人使用了这个工具。
过去的一年中，许多计算机专业的教授和教育专家都写了关于 MOOC如何扩大计算机教育服务的规模，使得成千上万的学生都能享受到。而
我想从另外一个角度，说一说我是如何在9个月的时间里向1位学生教授
计算机编程的。
2011年7月到2012年3月之间，我给Brian Goler教授基本的编程知识；他
是旧金山湾区一位有经验的企业家，在市场、销售和产品开发等方面都
有广泛的经验。Brian之前没有编程经验，但在几个月的时间里，他就
做出了SwearBuy，一个让人们对喜爱的产品发表评论的免费 web应用程
序。更重要的是，Brian获得了自学的能力，能够接下来自己搜寻、学
习更高阶的技术内容。我的主要贡献，是指导他克服一些通常会打击初
学者的障碍。
背景
Brian通过我的个人网站上知道了我，因为里边有几篇计算机科学教育
的文章。下面摘录他在 2011年7月给我发的第一封邮件里的一段内容：
我们没见过面，但我想试试看能否从您这儿得到些建议。
我在网上搜寻能帮我学习编程的导师的时候发现了你的网站。更准确
地说，我在上一门计算机课程，我希望找一个导师，每周能当面辅导
我1-2 次，每次1小时左右。
我正在上MIT的OCW6.00课程。尽管OCW和其他的在线课程都很
棒，但我觉得如果有个人可以请教、还能检查我的作业，并给与反
馈，那我的进度应该会更快些，对概念的理解也会更深入。
您在MIT和Stanford都待过，应该认识一些合适的人吧？或者，可以
给我推荐下去哪儿找合适的人？当然，我会向辅导的人付钱的。
因为那会儿我刚好不忙，于是我就亲自辅导Brian。我们第一次的一小
时会面是在他家，第二次是在附近的一家咖啡馆。之后我去参加某个学
术会议，于是第三次的辅导我们就通过Skype在线视频电话进行。我们
用了Skype的屏幕共享功能，这样在聊天的时候我就能同时看到他的电
脑屏幕。这种形式非常适合辅导，于是我们决定接下来的所有辅导都通
过Skype进行。我只当面辅导过Brian两次，而我们的Skype视频通话时
长高达 50 小时(大约 40 次)。在Skype上的在线辅导进行的如此顺畅，我们都感到很惊喜。这甚至比
我们当面聊天更有效，那样还会受困于嘈杂的咖啡厅和狭小的笔记本电
脑屏幕。借助Skype的屏幕共享功能，我能在我自己的公寓里边舒服地
看到Brian的电脑屏幕，并且与他实时互动。如果我需要画些草图来说
明，那我只需要共享屏幕，然后用绘图板来画就行了。(Salman Khan
就是用类似的办法教他的表弟，于是就有了现在知名的可汗学院教育视
频。)
基于项目的学习
Brian的目标是学习基本的编程技巧，提高自己；而不是要获得一份程
序员的工作，或是成为一名研究人员。在见我之前，Brian已经通过上
MIT开放课程中的“计算机科学与编程基础”，自学了几周 Python 编程。
开始的几次辅导中，我们通过课程讲义和作业，复习了基本的编程概
念。
然而，我很快就意识到，仅仅通过学院式的课程资料来学习，无法让
Brian 足够投入，尤其考虑到他已经大学毕业20年这个现实。他看起来
并不满足于只学习一些计算机学科的术语、做一些针对大学生的数学相
关的小练习。
因此，我决定教Brian成为一个实用主义的业余程序员，而不是一个饱
学的计算机科学专家。我鼓励他想出一个给自己或朋友用、自己也愿意
做的软件。相应地，我将指导他完成这个软件项目。这个想法如此简
单，但效果却异常好。
Brian提出了一些idea，并最终决定实现其中的一个，也就是后来的
SwearBuy。在接下来的9个月里，他每周都投入十几个小时的时间编写
SwearBuy，常常干到深夜。我们每周都有一到两次的Skype辅导，每次
持续一到两个小时。辅导中的大部分时间，我都用来回答Brian的问
题，帮他调试bug，有时还跟他结对编程，一起写点儿代码。我每次讲
的时间都只有几分钟。除了能让他的注意力高度集中外，这种基于问答
的形式对我来说也很不错，因为我几乎不必花时间提前做什么准备。
基于项目的学习十分高效，因为Brian十分重视他自己的第一个项目。
他的学习被需求牵着走，而不是一些预先设置好的的学术课程。因为他
对Swearbuy的热情非常高，所以常常会想出很多新功能的点子。为了实现这些功能，他必然要学习一些新的编程技术。因此，我的角色就变成
了：
评估他想实现的功能的可行性，如果需要的话，指导他完成一个简
单版本；
挑选最适合他需要的编程工具、风格以及技巧；
给他找到合适的自学资料(比如代码示例、博客、在线教程、书
等)；
在他努力理解和应用自学的内容时，回答他的疑问。
编程实现一个任务，常常有几十种甚至上百种方式；这种选择的多样
性常常让初学者手足无措。因为选择太多，他们反而不知从何入手。
我要做的，主要就是帮他将选择范围缩小到一个可控的范畴，适合他各
个阶段的学习；然后让他去自学，遇到问题时我再解答他的疑问。
我十多年的编程和教授编程的经验，使得我在每个需要选择的点上，都
能将选择范围缩小到我认为最适合Brian学习的程度。比如，我选择让
他用最基本的编程语言(比如 Python，JavaScript，SQL)功能来“从
头”搭建 SwearBuy，而不是在已有的一些复杂的 web 应用开发框架上开
始。尽管为此 Brian 不得不写更多的代码来“从头”(这个词儿可能有些
不准确，因为不可能完全从零开始)开始实现期望的功能，但他通过这
个过程，能够深入到内部原理，深入理解各个部分是如何组合到一起
的。
Brian的项目是我们Skype会话的绝好的基础，因为我能将自己要教授的
新概念融入到他想实现的新功能中去。哪怕更多的课后练习所发挥的作
用，也比不上一个属于学生自己的的应用程序。
在挣扎中学习
在我们每次1-2小时的Skype辅导开始前，Brian通常会编程10-15个小
时，所以他总是用大量急切的问题要问，有很多新写的代码需要我帮他
来调试和优化。如果我只是给他讲课，而不基于任何背景，那他不可能
消化的这么彻底，很可能只是点点头，然后说“嗯，好吧，好像是这么
回事儿……不错，然后呢？”相反，因为他在每次辅导之前，都一直在
和具体的代码相关的问题纠缠——甚至经常因此而受挫和沮丧——所以
每当我给他解释清楚了什么之前看起来好像不可逾越的问题时，他的反应往往是“哇哦!现在我算是彻底明白了!”。他的喜悦和释然每次都那
么明显。我觉得对消化知识来说，没有比这更好的方式了：先花上几
个小时努力解决问题，不断积累心中烦躁的情绪，然后再接受导师的
指导。
为了减少Brian的痛苦，我帮他搭建了开发环境，做了一些乏味的工
作，因为这些东西不会直接促进他的学习。我希望他把精力花费在编程
和搭SwearBuy上，而不要浪费时间做些不相关的事情，比如搭建服务器
或是版本控制系统。(当然了，如果他的目标是成为一个系统管理员，那我尽可以让他去纠结那些细节。)
有很多时髦的书、在线教程以及直播节目，都宣称能让你在7天或是3周
时间里学会编程(或者别的什么技能)。很明显，你不可能在几周里就
掌握一门新技能，而且我觉得也没几个人真的相信。这些“快速获取技
能”计划的真正问题在于，他们忽视了可持续性。这些课程就好像减肥
食谱一样，可能会让你马上减掉 10 磅体重，但却无法让你保持住，除
非你真正地养成了好的习惯。类似的，除非你不断努力很多年，否则也
无法精通编程；为了激励自己不断努力，你必须是在做自己有热情的事
情。努力挣扎可不是什么有趣的事儿，如果没有适当的激励，太容易早
早地放弃了。
当Brian意识到他不再需要我的辅导时，我知道我成功了。尽管他也承
认要成为一名技艺精湛的程序员，自己还需要努力好几年，但他已经知
道在现有的水平下，如何努力才能到达那个高度。在过去的九个月里，他学到了足够多的东西，能够支持他继续自学下去。我给了他足够的方
法和智慧来继续自学，而不是填鸭式地应付一个学生，我感到很自豪。
最后的思考
在我们的辅导结束之后，Brian反映说，尽管他受益于这种“通过做来学
习”的方法，但他仍然认为，将基于项目的学习和传统的计算机课程学
习结合起来，有很大的价值。在构建SwearBuy的过程中，他经常通过
Google、阅读技术博客、从StackOverflow上拷贝代码等方式，来临时解
决自己的问题。结果，他发现自己经常得出并非最优的方案，而且用的
东西自己都无法完全理解。Brian的一些巨大的进步，来自于他从项目
中抽身出来，转而去看书或听课时学到的新的概念，然后想着如何将其
用到SwearBuy中。自从我们2012年3月结束最后一次的辅导以来，我6个月没有收到Brian
的消息了。最近他给我发的电子邮件中提到，他刚刚写了个Python脚
本，帮自己给个人股票投资建立模型：“对这个脚本我感到很自豪，因
为这是我做的第一个实用的自用工具。我过去一直都在评估股票投资项
目，一直想模拟各种场景；一开始我用的是Excel，但后来终于发现
Python才是做这件事儿的不二之选。”
我很喜欢这封邮件，因为它展示了编程技能的作用，让原本无聊且困难
的任务能够轻松完成。我希望每个学习编程的人都能有迈过那道坎儿的
时刻，从那以后就不仅是为学校或公司的活儿而编程，而更多的是为自
己而编程。
我还想说一遍那句老话，积极性意味着一切。Brian的积极性来自自己
的项目，所以实际上他是自学的。我要做的仅仅是定期指导一下他，帮
他最有效地进步，让他的努力变为有效的学习。
我的这些经验如何才能推广到教授大批的自我激励的程度远不及Brian
的学生的教学实践中去？我摸索出的这些技巧如何能不再局限于一对一
的辅导这种形式？我也不知道。我只知道，如果你能让学生产生真正的
积极性，帮他们移除学习中一些不必要的障碍，而且在适当的时候拉他
们一把，那么实际上他们就完全可以自学。
英文原文：Teaching Programming To A Highly Motivated Beginner
译者 张重骐
北邮人。学过设计，技术在学；前产品设计师，现任开发工程师。热
爱美好，努力成为创造美好的人。图灵社区ID: zhongqi鲜阅未来的编程语言究竟是什么样？
作者 松本行弘
Ruby语言发明者，亦是亚洲首屈一指的编程语言发明者。现兼任网络
应用通信研究所(NaCl)研究员、乐天技术研究所研究员、Heroku首
席架构师等。昵称“Matz”。讨厌东京，喜欢温泉。
译者 周子恒
IT、编程爱好者，技术宅，初中时曾在NOI(国家信息学奥赛)天津
赛区获一等奖，大学毕业后曾任IT咨询顾问，精通英语和日语，译著
有《30天自制操作系统》、《大数据的冲击》、《Android应用开发
入门》。
从过去编程语言的历史中，我们可以看出编程语言是在不断试错的过程
中发展起来的。有很多编程语言已经消亡，仅仅在历史中留下了它们的
名字，但其中所包含的思想，却被后来的 语言以不同的形式吸取和借
鉴。
例如，SNOBOL 的字符串处理功能，可以说是现代脚本语言基本功能
的祖先。此外，20世 纪70年代由美国麻省理工学院(MIT)开发的一种
名为CLU
1的语言中迭代器(Iterator)的概念，也被Ruby以代码块
(Block)的形式继承了下来。
1 CLU 是由MIT的芭芭拉? 利斯科夫(Barbara Liskov，1939— )所开发的语言，利斯科夫于
2008 年获得图灵奖。(原书注)
从编程语言的进化过程来看，一个显著的关键词就是“抽象化”。抽象化就是提供一个抽象的概念，使用者即便不具备关于其内部详细情况的知
识，也能够对其进行运用。由于不必了解其内部的情况，因此也被称
为“黑箱化”。
一些古老的编程语言，例如BASIC 就没有实现充分的抽象化。虽然它提
供了用于过程共享的子程序这个概念，但是子程序只能通过编号来调
用，而且不能传递参数。由于“赋予名称”是抽象化的重要部分，所以说
它的抽象化是不充分的。近代的编程语言中，都可以为一系列过程(程
序)赋予相应的名称。
然而，仅仅将过程进行抽象化还远远不够。几乎所有的过程都需要进行
一定的输入输出操作，而并不是与数据无关的。因此，在下一个阶段
中，对数据进行黑箱化就显得非常重要。刚才我们提到的CLU，就是数
据抽象化出现早期的一种语言。
在数据抽象化的延长线上，就自然而然产生了面向对象编程的概念。所
谓对象，就是抽象化的数据本身，因此面向对象和数据抽象化之间仅仅
隔了薄薄的一张纸。在现在的21 世纪编程语言中，面向对象已经是常
识了，最近几乎所有的语言都或多或少地提供了面向对象的能力。 当
然，其中也有一些语言故意不提供对面向对象的支持2。
2 例如，下一节中将要介绍的由保罗 ? 格雷厄姆所设计的Arc 语言，就(至少在其内置功能中)
不支持面向对象，据保罗说，是有意这样设计的。(原书注)
随着抽象化的不断深入，程序员即便不去关心内部的详细情况，也可以
编写出程序。人类一次所能掌握的概念数量是有限的，有说法称，大部
分人一次只能驾驭7±2个左右的概念。这样一来，如果能够让问题的处
理方式更加抽象，也就可以解决更复杂的问题。
受摩尔定律的影响，社会对于软件也提出了越来越高的要求。人类社会
越来越依赖计算机，因此就需要开发出更多更可靠、更便宜的软件。
在讲述软件开发的一本名著《人月神话》中，作者弗雷德里克·布鲁克
斯写道：3 无论使用什么编程语言，生产一条基本语句所需要的工数几
乎是一定的。
3 《人月神话——软件项目管理之道》(The Mythical Man-Month: Essays on Software
Engineering)首次出版于1975年，并于1995 年进行了扩充和再版。弗雷德里克。布鲁克斯
(Frederick P. Brooks, Jr.，1931— )是美国的软件工程师，曾主持开发了IBM的OS360操作系统，于1999年获得图灵奖。
也就是说，如果要描述同样的算法，A语言需要1000行，B语言只需要
10行的话，只要采用B语言生产效率就可以提高100倍。
可能有人会觉得“这太扯了吧”。打个比方，用Java和Ruby描述同样的算
法，语句行数相差2倍多也不稀奇，如果是汇编语言和Ruby相比的话，也许能产生100倍甚至1000倍的差距。
能产生这样的生产效率差异，正是抽象化的力量。抽象度高的编程语言
不必描述详细过程，从而可以用简短的代码达到目的。和抽象化程度的
差异相比，变量名称、有没有指定数据类型之类的都只能算是误差级别
的差异而已。
100年后的编程语言
从编程语言的进化这个视角来看，其实最近并没有什么大的动作。现在
使用最广泛的编程语言几乎都是10 多年前出现的，即便是比较新的Java
和Ruby 也是诞生于20 世纪90 年代后半，距离现在也已经是15年之前的
事了。也许可以说，现在正是编程语言进化的好时机吧。
最近，受到CPU多核化等因素的影响，Erlang4这种并行处理语言受到了
不少关注。不过Erlang早在1987年就诞生了，也并不是什么新东西，有
点失望呀。
4 Erlang是由瑞典电信公司爱立信(Ericsson)旗下计算机科学研究室所开发的一种编程语言，发布于1987年，并于1998 年实现开源。
那么，未来的编程语言究竟会变成什么样呢？
美国风险投资家、Lisp 启蒙家、作家保罗·格雷厄姆在其《一百年后的
编程语言》5一文中想象了100 年后可能会出现的编程语言，并提议将他
的观点应用到现在的编程语言中。
5 保罗 ? 格雷厄姆(Paul Graham，1964— )是美国风险投资家、计算机科学作家。《一百年
后的编程语言》(The Hundred-Year Language)一文收录于保罗 ? 格雷厄姆的文集《黑客与画
家》一书中，人民邮电出版社2011年4月出版，阮一峰译。
他主张，100年后的编程语言进化的主线，应该以少量公理为基础的“拥
有最小最简洁核心的语言”。在现有编程语言中，最具有这一特征的莫
过于他最喜欢的Lisp了。所以说，他的主张实际上就是说，Lisp才是100
年后编程语言的进化方向。
唔，像我这样的小人物要跟他叫板好像也挺不自量力的，不过我还是认
为，对于未来，应该基于从过去到现在的变化方向，并在其延长线上做
出预测。当然，将来也许会发生一些无法预料的状况，从而大幅扭转之
前的前进方向，不过这样的事情从定义来说本来就是无法预测的，你非
要预测它，本质上也是毫无意义的。
作为一个编程语言御宅族，通过反观过去半个世纪以来编程语言的进化
方向，我认为编程语言绝对不会按照保罗·格雷厄姆所说，向着“小而干
净”的方向来进化。现在的编程语言，无论是功能上还是语法上都已经
不是那样单纯了，虽然也曾经有人努力尝试将这些语言变得更小更简
单，但包括保罗·格雷厄姆自己所设计的Arc
6在内，都决不能算是成功
的尝试。
6 Arc 语言是Lisp 的方言之一，由保罗 ? 格雷厄姆与罗伯特 ? 泰潘? 莫里斯(Robert Tappan
Morris，1965— )共同设计，于2008 年首次发布。
在我看来，编程语言的进化动机，不是工具和语言本身的简化，而是将
通过这些工具和语言所得到的结果(解决方案)更简洁地表达出来。近
半个世纪以来，编程语言不断提供愈发高度的抽象化特性，也正是为了
达到这个目的。因此我们可以很自然地认为，这种趋势在将来也应该会
继续保持。基于上述观点，如果要我来预测100 年后编程语言的样子，我认为应该
会是下面三种情况的其中之一：
1. 变化不大。编程语言的写法从20 世纪80 年代开始就几乎没有什么
进化，今后即便出现新的写法，也只是现有写法的变形而已。(从
发展上来看，是比较悲观的未来)
2. 使用编程语言来编程这个行为本身不存在了。人类可以通过和计算
机对话(大概是用自然语言)来查询和处理信息。(类似《星际迷
航》中的世界，对于编程语言家来说是比较失落的未来)
3. 发明了采用更高抽象度写法的编程语言。这种语言在现在很难想
象，不过应该是比现在更加强调What，而对于如何解决问题的How
部分的细节，则不再需要人类去过问。(难以预测的未来)
当然，上面的预测也只不过仅仅是预测而已，有可能与未来的实际情况
大相径庭，或者说，与实际大相径庭的可能性比较大吧。不过话说回
来，100 年后我也已经不在这个世上了，这不是白操心嘛。
20年后的编程语言
通过对100年后的预测，我们明白了“预测100 年后的事情是非常困难
的”。想想看，100年前连飞机还没有民用化呢，100年后我已经可以坐
在飞机上舒舒服服地写这篇稿子了，这足以说明，要想象社会的变化是
相当困难的。
那么，更近一点的未来又怎么样呢？比如说20 年后。20 年前，日本刚
刚改年号为平成7，现在和那个时候相比，印象中社会应该没有发生非
常极端的变化。计算机的性能等方面确实有了长足的进步，不过发展趋
势还是连续的，并非无法预测。对于20 年后的未来，我想应该可以根
据现在的发展趋势来做出判断。
7 除了公元纪年外，日本人还普遍习惯使用年号纪年。和中国封建王朝时期一样，年号一般是
随天皇的更换而进行更迭。1989 年，明仁天皇即位，改年号为平成，因此 2012 年是平成 24
年。在平成之前的上一个年号是昭和。
个人认为，这么短的时间内，编程语言本身应该不会发生多大的变化。
实际上，现在使用的很多语言，在20 年前就已经存在的。因此我预
计，20 年后的语言，应该是在分布处理(多台计算机协作处理)和并
行处理(多个CPU 协作处理)功能上进行强化，使得开发者不需要特别花心思就能够使用这些功能。
之所以要关注分布处理和并行处理，是因为今后个人也可以通过云计算
的形式使用到比现在更多的计算机，而随着每台计算机的CPU 多核化，就相当于安装了更多的CPU，这些情形都是很容易想象的。
不过，我认为现在的线程、RPC(Remote Procedure Call，远程过程调
用)等显式地使用分布处理和并行处理的形式，早晚会遇到瓶颈。当核
心数量超过数千个的时候，显式指定就变得毫无意义了，调试起来也会
变得非常痛苦。我期待在20 年后，能够出现突破这种局限的技术，即
无需显式操作就可以实现分布处理和并行处理。
学生们的想象
几年前，我曾经在母校筑波大学开展过一次关于编程语言的集中讲座。
在讲座中我给学生们出了“想象一下20年后的编程语言”这样一个题目，并在讲座最后一天提交报告。很有意思的是，大多数学生并没有做出我
上面所说的关于分布处理和并行处理之类的技术性预测，而是提出了诸
如“让编程变得更简单的语言”、“希望用自然语言来控制计算机”之类的
想象。通过这些答案，似乎可以看出他们平常为了完成编程作业而被折
磨得何等痛苦。
不过，这样的答案中，也许也蕴含着真理。近年来，编程语言似乎越来
越难以脱离IDE(Integrated Development Environment，集成开发环境)
而单独拿出来说了。对于Ruby也总有人问“没有IDE吗？”之类的问题，当然，好消息是最近Eclipse 和NetBeans 已经支持Ruby了。
有点跑题了。总之，未来的编程语言可能不会像过去的编程语言那样，让语言本身单独存在，而是和编辑器、调试器、性能分析器等开发工具
相互配合，以达到提高整体生产效率的目的。话说，那不就是 Smalltalk
吗8？
8 Smalltalk 正是一种考虑了“与编辑器、调试器、性能分析器等开发工具相互配合”而设计的语
言。过去它并不能算是成功的，但随着技术的进步，其理念获得了越来越多的用武之地，或许
真能卷土重来也未可知。
唔，历史是否会重演呢？
《代码的未来》是 Ruby 之父松本行弘的又一力作。作者对云计算、大
数据时代下的各种编程语言以及相关技术进行了剖析，并对编程语言的
未来发展趋势做出预测，内容涉及Go、VoltDB、node.js、CoffeeScript、Dart、MongoDB、摩尔定律、多核、NoSQL 等当今备受
关注的话题。八++Puppet——Luke Kanies 的钢铁侠
作者 余兴超
前新浪云计算系统开发工程师，现在UnitedStack负责Devops相关事
务。热衷于开源社区，常用ID Newptone，中文译作牛皮糖。他和他
的小伙伴们(一只猫和一只兔子)现居住在北京城某一安静的角落。图
灵社区ID:牛皮糖
Puppet对于做DevOps的同学来说，是个非常熟悉的名字，但仍有人还不
了解它。那么我先来简单介绍一下：Puppet是由Puppetlabs公司开发的系
统管理框架和工具集，被用于IT服务的自动化管理。由于良好的声明式语言和易于扩展的框架设计以及可重用可共享的模块，使得Google、Cisco、Twitter、RedHat、New York Stock Exchange等众多公司和机构在
其数据中心的自动化管理中用到了Puppet。半年一度的PuppetConf大会
也跻身于重要技术会议之列。AWS的CloudFormation文档中有一段关于
Puppet的介绍，其开头是这么说的: Puppet has become the de facto
industry standard for IT automation。
同时，Puppet在OpenStack中也发挥着重要的作用：OpenStack-ci社区将
其用于OpenStack wiki系统,持续集成系统等等的运维管理；此外社区的
puppet-openstack项目用于完成OpenStack服务的自动化部署和管理，目
前已经在stackforge中托管并通过OpenStack的Gerrit系统来管理代码提
交；此外，Cisco,RedHat,Miriantis等多家公司的OpenStack发行版或部署
工具中均使用到了puppet-openstack。目前，Puppet在UnitedStack的日常
运维管理和产品的自动化部署中也起到了重要作用。
好了，刚刚还不了解Puppet的读者们现在已经知道Puppet是一个牛逼哄
哄的自动化运维管理工具。可能有人已经下完了软件包跃跃欲试了，先
别急，有关Puppet的使用资料在网上可以搜到一大堆，官方的文档也详
细到了“令人发指”。关于Puppet的使用经验分享和各种特性的深入探讨
以及如何使用Puppet管理OpenStack部署的方案分析，哦，都不在本文的
讨论范围之内。
本文的重点是八卦一下Puppet为什么可以这么成功。同时，为避免引起
非Puppet程序员感官上的不适，我屏蔽了各种代码级别的展示和对细节
的探讨。
Luke Kanies的技术之路
故事要从Luke Kanies，这位twitter昵称与Puppet的服务器端进程名同名
的哥们说起，在很久很久以前...成长：苦逼的学生时代
在1992年的时候，Luke进入诺思兰学院成为了一名化学专业的学生，这
是一所位于威斯康辛州的小学校，全美排名在178左右徘徊。
小伙子很争气只呆了一年就跑到了大名鼎鼎的里德学院，成为了乔布斯
的校友。不过倒霉的是里德学院被评为全美十大苦逼学校之一，6年毕
业率仅为75%，也就是有14的同学拿不到毕业证。有别于很多文理学院
自由选课的模式，里德的大一学生必须完成规定的人文必修课程，学习
希腊及罗马的古典文化。这门课程已经有超过50年的历史，里德动用了
学校最为强大的师资力量来为学生奠定文化基础。这还没完呢，之后学
生还必须在四个拓展领域选课：文学、哲学、宗教、艺术方面;历史、社科、心理学方面;自然科学方面;还有数学、逻辑、语言学或外语。大
三学生必须通过专业测试，大四学生则必须完成专题毕业论文才能毕
业。毕业论文并不可怕，可怕的是里德学院的毕业论文的学时是一年，所以有想出国留学的同学，请密切关注另外九所大学的名字…
该来的还是会来的，1996年，Luke大四了。要想顺利毕业的话，他必须
得修完这长达一年的论文项目，这意味着在这一年内他必须要动手设计
和实现，并用实验数据证明，最终组织成论文来完成课题。Luke的论文
题目是Site-directed Mutagenesis in Soy Cytosolic Ascorbate Peroxidase，我推敲了半天，中文翻译大致是：大豆抗坏血酸盐过氧化物酶胞质的定
点诱变。
打工：漂泊和积累万幸的是，我们不用去研究一口气都念不完名字的论文。扯远了，Luke
毕业后没去找一份和化学相关的工作而是去了Cypersite当起了Mac系统
管理员。在Cypersite的日子里，Luke使用AppleScript干着行MacOS的管
理工作，不过干了不到一年还没转正的时候，他便跑路了。
因为在97年的12月份，他在Metro One Telecommunications找到了一份系
统管理员的活儿。Metro One Telecommunications当年可是纳斯达克上市
公司，主要业务是提供电话号码查询服务。在其巅峰时，公司在全美拥
有7000名雇员，然而在2009年初，在售完最后一部分的经营业务后，该
公司还剩余3人。瞄了一眼Metro One今天的股价：0.01美元。通信行业
早已是昨日黄花了，吴军博士已经在《浪潮之巅》中将这些历史描述得
尽致淋漓。
又扯远了，在Metro One的1年零9个月里，Luke的主要工作是管理分散
在全美的30个呼叫中心，包括了呼叫中心计算设备的部署和设置，外加
从总部对其进行不间断的维护。看到这里，我突然想到某家startup的创
始人之前在电信部门做过相同的工作，后来他去做了一个很炫的可视化
部署工具，我猜测通信行业的部署工作充满了重复的机械劳动，有一种
自动化的强烈需求。这里提一下，provision曾是电信行业中的一个术
语，专指安装通信设备前的准备工作，而在devops中常说提起的bare-
metal provision是指在计算机上安装操作系统或者hypervisor的过程。
在1999年，Luke离开了这家电话公司，在BlueStar担任系统工程师，BlueStar是一家卖解决方案的经销商，主营业务有：RFID, Auto ID, POS,Mobility products。Luke主要负责一家DSL ISP服务器端基础架构的设计
和实现。他构建了一套自动化且可集中管理的系统，并负责基础架构项
目的持续开发以及实施和维护。
Luke在“蓝翔”干了还没到两年，又跑去了卡特彼勒融资服务公司担任顾
问，提供系统自动化管理相关的咨询。我查了下，卡特彼勒公司位列世
界500强，成立于1925年，是世界上最大的工程机械和矿山设备生产厂
家、燃气发动机和工业用燃气轮机生产厂家之一，也是世界上最大的柴
油机厂家之一。我在网上没有查到Luke在这段时间具体干了些什么，只
能感叹Luke作为一个系统管理员是怎么混进一个高帅富的融资公司担任
顾问的。
创业伊始：对轮子的修修补补在卡特彼勒待了两年后，Luke开始单飞，找人合伙创建了Reductive
Consulting(2010年改名为Puppetlabs)，头衔是独立顾问，专门从事
Unix基础设施自动化相关的咨询。他着手研究当前开源的系统管理和监
控工具如CFEngine,ISconf,Nagios等等，并且通过二次开发把这些工具联
结成一套满足客户需求的解决方案。这是一个重要的阶段，Luke开始将
积累多年的经验和思考转变为对工具的改写，这期间他的主要工作包括
重写了CFEngine的解析器和开发了ISConf3，这对后来的Puppet开发工
作产生了重要影响。
CFEngine简介
首先，来说一下大名鼎鼎的CFEngine，这是一款出生于1993年的老牌
系统配置管理工具，CFEngine的作者Mark Burgess希望可以使简单的
管理任务自动化，使困难的任务变得较容易。它的核心理念是使系统
从任何状态都能收敛到一种理想状态。
这样的工具对当时还在使用零零散散的脚本来管理机器的系统管理员
来说简直就是冬天的棉袄，夏天的雪糕，黑暗中的灯泡，饥饿中的面
包。之后，CFEngine自然而然地成为了系统配置管理工具中的标杆。
CFEngine有两种工作模式：既可以使用standalone模式即通过cfagent
来完成单台服务器的配置管理工作，也可以通过CS架构(cfservd和
cfagent)来管理整个集群的配置管理的分发工作。
CFEngine的工作方式是基于脚本分发：在配置文件中有一个参数称为
shellcommands，用于配置要执行的命令或脚本，actionsequence则用
于设置shellcommands的执行顺序。
再来看看CFEngine的版本更新：1993年，CFEngine1发布；1998年，CFEngine2发布，而十年后，直到2008年，CFEngine3姗姗来迟，第三
版发生了巨大改变，可以通过使用DSL来定义系统状态，以至于其不
能再兼容旧版本CFEngine2的配置语言。本文谈到CFEnigne时，是指
CFEngine2。
ISconf简介ISconf则是另外一款配置管理工具，它的核心理念是系统的最终状态
是一致的，即使被管理的机器是关机状态，当它们完成启动之后，相
关命令就会被执行，到达一致的状态。同时整个系统无需中心节点，命令可以在任何一台节点上执行并复制到所有节点上。ISconf总共经
历了4代的演化。ISconf1和2是由shell脚本编写，Luke在2002年的时候
开发和设计了ISconf3，并使用Perl在2的基础上进行了重写。ISconf3
有三个核心特性：
确定性的执行顺序
执行中有失败时立即退出
状态维护
从上面的特性来看，是一个挺酷的产品。Luke在02年的时候完成了开
发，并在03年的LISA(Large Installation Systems Administration)会议
上发表一篇名为'ISconf: Theory, Practice, and Beyond'的paper，谈到了
ISconf的特性，开发ISconf中获得的经验和教训，以及和CFengine的
集成，分析ISconf 3的适用场景等等。不过ISconf社区在介绍ISconf3
的历史时对Luke的论文颇有微词，你可以在ISconf的官网读到这篇文
章。不过，ISconf止步于第四版，最后的版本发布时间停留在06年8月
13日，原因未知。
自造轮子
随着Luke的梦想越来越大，这些工具集也变得越来越庞大。而此时对这
些现有的开源工具的修修补补已经不能满足他的需求了。最终，他意识
到只有他自己，才能去创造自己想要的工具。作为一个多年的运维人
员，他深深感受到了苦逼的系统管理员们需要有一个崭新的工具来使得
他们的工作更高效，更便捷。因此，他开始考虑去开发一个新工具，首
先这个工具是为系统管理员而设计的。那么怎么才能称为得上是为系统
管理员设计的呢？
先来简单思考一下系统管理员对于配置管理工具的主要需求：学习成本
低，开发高效，跨平台，代码可复用，安全，可扩展性高等等。
最好的情况就是系统管理员只需关心某个服务或者软件包的状态，例如
我希望部署一个Apache Web服务器，我只关心Apache的包是已安装的
状态，服务是运行的状态，而不要让我去操心这个Apache包是装在Ubuntu下的还是Redhat下，然后到底是要执行yum install还是apt-get
install，然后还要操心这个apache进程到底是用init还是upstart管理的。
此外，还有如何对依赖关系进行处理。先前的配置管理工具都是关注在
如何去完成每一项互相独立的工作，例如配置Apache服务就是一段shell
脚本而已，而没有去考虑它们之间是存在关联的，例如当Apache的配置
文件发生变更时，是应该重启Apache服务来使之生效，而重启Apache服
务的前提是系统已经安装了Apache。
这对于当时占据主流的以分发shellperl脚本的配置管理软件来说，简直
是天方夜谭。不过Luke就是这么设想的，他在构思Puppet的设计时，就
希望将系统抽象成资源：采用面向对象的概念，将每个资源类型组成为
一组属性的集合，每个属性都有相应的行为，并将资源类型和属性构造
成类，最终使用这些属性来使得资源到达期望的状态，而不是用资源本
身来完成这些工作。同时，将所有资源的依赖关系构建成一张有向图，通过这种依赖描述，系统管理员们可以实现复杂的业务逻辑的管理。
越想越兴奋，于是Luke开始动手coding了。Puppet的第一个原型写于04
年夏天，但他并没有把此事放在最重要的位置上。于是在9月份的时
候，Luke居然跑去了BladeLogic担任产品设计，这是一家专门做商业配
置管理软件的公司，它的产品在当时已经取得了成功，然而Luke发现
BladeLogic的品味仅仅是想卖软件给大公司而不是立志为系统管理员设
计伟大的工具。在05年的2月份，Luke下决心继续搞Puppet的开发工
作。于是，在BladeLogic呆够了7个月后，Luke选择了离开。BladeLogic
也终于如愿以偿：被BMC收购了，当然这是后话。
艰难抉择:开发语言和设计哲学
随后Luke回到了Reductive Consulting，也就是PuppetLabs 的前身，开始
了Puppet的全职开发。不过他遇到了一个棘手的技术问题：身为一个Perl程序员，Luke痛苦地
发现，Perl居然无法处理那些Puppet类之间的关系。那时Python被认为
是系统开发的最佳选择，但是Luke同学接受不了的不是Python的缩进问
题，而是print是一个语句而不是函数，len是一个函数而不是方法的事
实，让他感觉“眼睛在流血”。这时候，有个朋友告诉他Ruby很酷，于是
他在尝试了4个小时后，就写出了一个功能原型，从此不可自拔。不过
他也有点担心，因为在当时Ruby还属于非主流，因为ROR(Rails on
Ruby)都还没有出生，不过鉴于他的体验，觉得使用Ruby的开发效率
非常高，因此他决定冒一次险。
在这个问题解决之后，Luke又面临另外一个难题：虽然在此之前他已经
写了不少的小工具，积攒了丰富的经验，不过这些工具没有一个的代码
量是超过1万行的。这也意味着在设计Puppet的架构的过程中，肯定得
摔不少的坑。因此，Luke在开发Puppet的过程中始终要求自己和开发团
队遵守两个指导思想：首先设计尽可能地做到简洁，程序的可用性总是
高于新特性；此外Puppet首先是个框架其次才是一个应用。在解决了语
言选型和设计哲学的问题后，Luke开始潜心于Puppet的开发。
然后呢
然后就没有然后了，随着Puppet的发布和版本的快速迭代，以及社区的
火热发展，Puppet自然而然地就发展成了今天的模样。本来是要开始深入技术细节展开介绍，但是应广大群众要求保持纯八卦风格的呼声，下
半部分在内部审批时被惨无人道地砍掉。对于Puppet和Luke的介绍到此
告一段落，咱们再来八一下群众们喜闻乐见的热点事件。
投资风云
事情源于两年前，VMWare作为PuppetLabs的6家投资公司之一，向
Puppetlabs投了850万美刀。在今年的2月份，VMWare宣布提高对
PuppetLabs的投资：3000万。此外，VMware负责云架构和管理的执行
副总裁Raghu Raghuram将进入Puppet Labs董事会。
这从资本市场的角度说明了Luke和Puppet的成功，叫好又叫座。但是也
引发了人们的担忧：一些人认为Puppet的独立性是非常重要的，理由是
DevOps的成功非常依赖于这个组织选择什么样的工具用于企业基础设
施管理，PuppetLabs作为IT自动化管理领域里的领头羊，然而VMware
对Puppet存在强大的话语权，目前PuppetLabs花了很大的精力在Puppet
企业版本的开发上(Puppet PE)，用于和VMWare vCloud Automation
Center等产品的集成。这并不是一件好事，可能会使得社区版本和商业
版本产生巨大的差距，甚至可能会发生Oracle和MySQL那样的故事。
再看看VMWare的老对手Amazon的反应，即使Amazon在开头提及的文
档里承认Puppet是事实上的行业标准，但考虑到它的老朋友VMWare手
握对Puppetlabs 23的投资，在其新推出的OpsWork服务中清一色地使用
了Chef用于系统的配置管理，这是诞生于Puppet之后的另外一款开源的
配置管理工具。
再来听听其他人的声音。Matt Asay与Luke是多年的好友，在Lukes与
Andrew Shafer创立Puppet Labs后，Matt 曾经提出了许多商业化建议，包
括进行融资，但Luke更希望公司保持独立。Matt淡定地回答记者：如果
你了解Luke Kanies这个家伙，你就知道保持独立对于他而言是无比重要
的事。他在田纳西州长大，不是那种出卖灵魂的人。Luke在IM上和Matt表达了自己的看法：“向云端转换的趋势将给下一代
系统平台管理工具带来无限的机会，对VMware如此，对PuppetLabs亦
是如此。即便PuppetLabs被VMware掌控，但这些系统仍构建在开源的
基础上，并赋予它们一定的自治权。Puppet拥有活跃的开源生态圈，就
像OpenStack一样，是对投资很好的补充。”
最后谈谈我的看法，首先Puppet天生就是开源血统，其社区非常活跃，而且从2.7开始变为更为友好的Apache许可证(之前是严格的GPL)。因
此，即使发生像MySQL那样的事情，照样会有另一家MariaDB出现，更
何况还有后起之秀Chef在一旁虎视眈眈，VMWare理应不会下这步昏
棋。同时，对于指责Puppet只关注于与VMware产品的集成是有失偏颇
的，虽然最近PE的动静很大，但是PuppetLabs也花费了很大的精力投入
到Puppet-Openstack社区中，在之后的Puppet系列博文中会对此进行阐
述。所以，我并不担心Puppet是否会成为下一个MySQL。我们学到了什么？
在前面洋洋洒洒的一堆八卦中，我简单地谈了一些关于Luke和Puppet的
故事。每个人可能都会从中看到不同的东西。对我而言，Puppet之所以
能取得成功，我认为有：
做自己最擅长的事：Luke拥有丰富的运维经验和配置管理工具的开发经
验，在此基础上去开发Puppet是获得成功的基础之一；
取其精华：在调研同类工具和产品时，Luke不只看到了其中的不足，还
吸收了它们的优点；
志存高远：Luke开发Puppet时候的动机是为系统管理员提供最棒的CMS
工具，而不仅为了挣钱，被收购，上市。动机越单纯，成功的概率越
大；敢想敢做：现在去挑选手机，我们几乎不会去考虑手机是不是触摸
屏的而是去看屏幕有多大，PPI多高，因为手机是触摸屏这是理所当然
的，然而在iPhone之前，触摸屏手机还是很稀有的东西，大家都在往功
能更多的方向越走越远；同样，现在在使用Puppet时，会觉得使用声明
式配置语言是理所当然的事情，殊不知在Puppet诞生的同时代中，都是
清一色的命令式或者过程式的配置语言。
免责声明
本文的所有情节来自本人花费一周的夜生活时间，阅读了各式各样的博
客，新闻，评论，代码，勉强拼凑而成，若有与实际不符之处，请一笑
而过。出版的未来电子书时代可以来得更快
作者 董苗苗
图灵策划编辑。关注IT人文、前端技术。关注数字出版和新媒体。希
望自己能够持续积累和提高。
国内环境下的电子书和纸质书关系的争论和探讨已经持续很久了，作为
出版行业刚入门四年的小字辈，我不敢造次，不过还是很想谈谈自己的
想法。
我把阅读性图书大致地定义为轻阅读和重阅读两类。小说、杂志、漫画
等是轻阅读，教材、科技书、专业书等为重阅读。由于传统习惯，重阅
读可能还是比较偏向纸质书，尤其是很多人喜欢在书上写写画画，但是
由于移动智能终端的普及，轻阅读的电子书的发展不可小觑。
我身边有前辈说，纸质书完了，电子书会完全替代纸质书!我完全同意这个观点。不过在这之后的几年中，在中国，恐怕是不会实现的。除非
——
电子书销量想共赢？各种阅读软件之间能够实现阅读兼容才
好
我以前是坚定的纸质书拥护者，2013年初我自己也转投电子书阵营，原
因很简单，塞班”死”了，我换了一台将近5寸的安卓智能手机，从此我
真切地感受到了电子书的优势，开始走上寻觅“最佳”阅读体验的道路。
可是哪里有最佳呀，各有各的优势，可用户(比如我)是那么地挑剔，那么地较真，甚至是那么地不讲道理，就想找个最好的阅读软件，怎么
办？让产品经理去抓头皮吧!
现在有那么多电商和数不清的各种阅读应用，却不完全兼容？!
(这里暂且不提“免费电子书”)
明明喜欢这家电子书商的排版风格，却没有自己喜欢的书？
为什么同一本书每家的价格差那么多？
为什么刚买完就降价了，玩呐？
在一家买的电子书，明明是正版，可别的阅读软件就是用不了，有
的价格还“不菲”，真真不如直接趁打折的时候买纸质书的好!
各家都想保护自己阅读软件的用户使用占有量，保证自己的市场营销占
有量。可用户真的不是拦截得住的，电子书商不是要变身铜墙铁壁，而
且要变成一张黏糊糊的网，具有优质的用户体验才是得到了真正的铁饭
碗。
要知道——
用户都是顽固派，喜欢一个，习惯一个，就不想换阅读软件了。
用户都是懒汉，就希望买一次正版电子书，换谁家的浏览器都能
看，不需要转换来转换去。
用户都是贪心鬼，尽管一次也许只会买一本书，但是要求“商城”里
提供的电子书种类堪比图书馆。
用户都是贪小便宜的人，同样的书，差不多的排版，必然选择最便
宜的。爱书的人买书不会抠门，但是省下的钱多买几本，这才是正
道。
用户都不是傻人，每家价格定得天差地别，有的还动辄减价，那我谁家的都不买，“我等着!”
如此，我给做软件开发的朋友出个主意：做一个图书比价软件。功能包
括：
1. 搜索书名，立即出现几家电子书商的价格对比(也可以进行纸质书
价格对比，纸质书、电子书价格对比)。
2. 显示和该书有关的营销活动。用户可以直接找到最划算的途径购买
电子书。相信很多用户就是这么做的，不过前文说过了用户都是懒
汉，自然有人代劳，或者一劳永逸才好。
3. 书评、打分、互动、相关信息等其他扩展功能。
如此一来，价格只会趋同，大打价格战，全是输家呀!那大家拼的是什
么？如果这个问题回答不出来，白白称为“电商”了。拼的是用户体验
呀!文案编辑、美编排版、线上线下活动、作者读者的互动。
有的人问了，长此以往，那不就是又趋同了吗？我就是想在当今社会独
树一帜!您在开玩笑吗？地球上哪个行业、哪个商业模式是独树一帜
的？想要常开常艳，拼的就是优质的用户体验，持续的服务，耐久的行
业追逐力，以及决定性的创新能力了。创新是加分题，都想加分，可先
不要丢分才行。
(未完)下文提示：
电子书时代可以来得更快(二)
电子书价格战损人不利己，价还得是出版方定
电子书时代可以来得更快(三)
重阅读也要投靠电子书？完美实现“电子书图书笔记”功能才行书榜大家都在读什么？
挑战程序设计竞赛(第2版)
作者：秋叶拓哉 岩田阳一 北川宜稔
译者：巫泽俊 庄俊元 李津羽
书号：978-7-115-32010-0
图灵社区推荐：
世界顶级程序设计高手的经验总结，ACM-ICPC全球总冠军巫泽俊主
译，日本ACM-ICPC参赛者人手一册。
本书对程序设计竞赛中的基础算法和经典问题进行了汇总，分为准备
篇、初级篇、中级篇与高级篇4章。作者结合自己丰富的参赛经验，对
严格筛选的110 多道各类试题进行了由浅入深、由易及难的细致讲解，并介绍了许多实用技巧。每章后附有习题，供读者练习，巩固所学。
机器学习实战
作者：Peter Harrington
译者：李锐 李鹏 曲亚东 王斌
书号：978-7-115-31795-7
图灵社区推荐：
全书通过精心编排的实例，切入日常工作任务，摒弃学术化语言，利用
高效的可复用Python代码来阐释如何处理统计数据，进行数据分析及可
视化。通过各种实例，读者可从中学会机器学习的核心算法，并能将其
运用于一些策略性任务中，如分类、预测、推荐。
图解TCPIP(第5版)
作者：竹下隆史 村山公保 荒井透 苅田幸雄
译者：乌尼日其其格
书号：978-7-115-31897-8
图灵社区推荐：
这是一本图文并茂的网络管理技术书籍，旨在让广大读者理解TCPIP的
基本知识、掌握TCPIP的基本技能。本书引导读者了解和掌握TCPIP，营造一个安全的、使用放心的网络环境。
推荐系统
作者：Dietmar Jannach， Markus Zanker， Alexander Felfernig， Gerhard
Friedrich
译者：蒋凡
书号：978-7-115-31069-9
图灵社区推荐：
本书全面阐述了开发最新水平推荐系统的方法，其中呈现了许多经典算
法，并讨论了如何衡量推荐系统的有效性。书中内容包括基本概念和最
新进展两部分。此外，本书还包含大量的图、表和示例，有助于读者对
于知识的理解和把握。
Cocos2d-x高级开发教程：制作自己的
《捕鱼达人》
作者：火烈鸟网络科技
书号：978-7-115-31796-4
图灵社区推荐：
代码的未来
作者：松本行弘
译者：周自恒
书号：978-7-115-31751-3
图灵社区推荐：
贴心设计：打造高可用性的移动产品
作者：Jakob Nielsen, Raluca Budiu
译者：牛化成
书号：978-7-115-31879-4
图灵社区推荐：
大数据的冲击
作者：城田真琴
译者：周自恒
书号：978-7-115-31787-2
图灵社区推荐：
JavaScript异步编程：设计快速响应的网
络应用
作者：Trevor Burnham
译者：许青松
书号：978-7-115-31657-8
图灵社区推荐：
Objective-C高级编程：iOS与OS X多线
程和内存管理
作者：Kazuki Sakamoto, Tomohiko
Furumoto
译者：黎华
书号：978-7-115-31809-1
图灵社区推荐：成书手记ACM-ICPC冠军谈《挑战程序设计竞赛》及相关
算法书
作者巫泽俊
浙江大学2010届数学系本科生，2013届计算机硕士生。曾代表浙江大
学获得2009年ACM-ICPC World Finals第6名，2011年ACM-ICPC
World Finals冠军。在线比赛中常用watashi和rejudge等id。
前几天，秋叶拓哉(iwi)、岩田阳一(wata)和北川宜稔
(kita_masa)所著，我(watashi)、庄俊元(navi)和李津羽
(itsuhane)翻译的《挑战程序设计竞赛》，终于通过人民邮电出版社
正式出版了。可喜可贺，可喜可贺。这里我主要想说一下自己为什么要
翻译和推荐本书，还有对程序设计竞赛学习资料的一些看法。也附带一
些对译者序和第1章的补充说明。
在译者序中我也略谈到了自己翻译此书的动机。和很多读者一样，最开
始当然是奔着作者的名头去的，三位作者不但是国际知名的选手，而且
TopCoder的最高rating加起来都破9k了。顶尖实力的作者往往可以站在
更高的高度指点江山，也就更可能写出一本好书。随后就是读到书中的
内容了，书中的绝大多数东西，我大概都在过去四五年时间的摸爬滚打
中，逐步通过各种书籍、网络、道听途说、解题经验和总结体会掌握
了。不过还是有一些耳目一新的内容，其中有一两个问题还是通过邮件
得到了原作者的解答，涨了知识。但仍有一种相见恨晚的感觉，假如自
己早两年读到此书，想必能少费不少劲。从我个人的经历和对周围同学
的了解来看，这是一本非常值得引进和推荐的书。
当然，在此之前国内已经出版有不少算法竞赛相关的书籍了，很多人想必希望知道这本书有什么特别之处。算法竞赛相关的书籍大致有两类，一类是算法和数学类的书籍，比如各种数据结构教材、离散数学教材、《算法导论》、《具体数学》等，一类是专门针对算法竞赛的书籍，其
中的代表就是刘汝佳所著的几本书，而《算法艺术与信息学竞赛》(黑
书)又是其中的代表。作者之一的iwi在MSRA实习期间也得知了黑书的
大名。
首先，个人觉得这些书籍大致可以分为两类：教科书和工具书。诸如
《数据结构与算法分析》(DSAA)之类的书可以作为教科书的代表，而诸如《计算机程序设计艺术》(大名鼎鼎的TAOCP)则毫无疑问是
工具书的代表。大致地说，前者简单易懂，适于学习，后者高深全面，适于参考。二者并没有明显的分界线，很多时候全凭主观，因人而异。
比如说，看懂了，这就是教科书，看懂目录了，这就是工具书。当然，和数学沾边越多的书，总是越难啃的，所以就难度而言，这类书籍和编
程语言类书籍自然是没有可比性。
许多书都作为程序设计竞赛的学习资料被反复推荐，但事实上，我们大
概可以仿照《最常被程序员们谎称读过的计算机书籍》写一篇《最常被
ACMer们谎称读过的书籍》的吐槽文。里头有一句话很重要，所以我再
抄一遍：“如果你自己没有读过这些计算机书籍，请不要推荐给别人”。
当然，像《算法导论》这样的书个人觉得还是值得一读的，多数的章节
并不难，可以当作教科书，后面的一些内容可以作为工具书需要时再参
考，里面很多东西讲得很细，容易做到真正的理解吸收，比如从自动机
引出KMP，等等。而TAOCP则无疑是最常躺枪的装逼神器。有一天，我在同学的桌上看到一本TAOCP第一卷，打开一看很黄很暴力，我赶
紧就把它盖上了。TAOCP很厉害，看exponentiation by squaring能引用到
它，看permanent也能引用到它，连看数え上げお姉さん都能引用到
它。读完TAOCP那必须能变得超厉害了，可那得是能读完啊，读不完
说啥都白搭。所以推荐学习资料不能光看书好不好，还得看对目标人群
合不合适。而一本好的教科书，不应该是尽可能体现作者有多牛，而是
要能够尽可能简单地帮助读者变得更牛。如果看完了，懂的还是懂，不
懂的还是不懂，那是没有意义的。
按照这个分类标准，个人觉得《挑战程序设计竞赛》是一本很好的教科
书。它非常适合作为有志参加程 ......
作者：图灵社区出品
本书由北京图灵文化发展有限公司发行数字版。版权所有，侵权必
究。
您购买的图灵电子书仅供您个人使用，未经授权，不得以任何方式复制
和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐
号等维权措施，并可能追究法律责任。目录
编者的话
专题：从Python开始
PPP是什么？好玩的Python编程!
为什么要用Python实现机器学习算法？
第一个孩子的出生时间研究：程序员的统计思维练习
和孩子一起做一只电子宠物吧!
从Python 3的bytesstr之别学编码Unicode
如何构造团队Python开发环境
人物
罗晨：梦想照进现实，一个独立开发者的田园诗
读《码农》 吐吐槽 还能赚银子!
践行
如何教编程，当你面对一双渴望的眼睛
鲜阅
未来的编程语言究竟是什么样？
八++
Puppet——Luke Kanies 的钢铁侠
出版的未来
电子书时代可以来得更快
书榜
大家都在读什么？
成书手记
ACM-ICPC冠军谈《挑战程序设计竞赛》及相关算法书
社区动态
乐译开放书：Python for Software Design
图灵访谈：对话Peter Harrington
听书计划：《程序员的思维修炼》
社区介绍
封底
编者的话
从Python开始
编者 李盼
对于一种编程语言来说，最重要的就是名字了。没有好名字的语言是
无论如何也无法成功的。我最近发明了一个非常棒的名字，现在正在
找那个合适的语言。
——Donald Knuth(高德纳)
Python 到底为什么要叫做Python(蟒蛇)呢？ Python的发明人 Guido
van Rossum说，那是因为他需要一个简短、独特，还略带有神秘感的名
字。(刚巧那时他正在看一个70年代的BBC喜剧秀，叫做“巨蟒剧团的
飞翔马戏团”。)Python作为一门编程语言，可能最欠缺的就是“神秘
感”了。它可以是“好玩的(Playful Programming)”，也可以是“好学
的”(Python甚至可以用来教授给小学生)。完全不懂编程的人可以把
Python作为自己的第一门编程语言，但是，这并不意味着它不够强大。
对于懂得Python的人来说，Pythonic是一种编程风格。它崇尚优雅、明
确、简单，“如果能用同一种方法来做一件事情，为什么要变来变去
呢？”正是这种最大程度简化自身的思想让科学界张开双臂欢迎
Python，甚至称它为“科学的语言”。NumPy、SciPy、Matplotlib可以让
Python程序员编写科学计算程序。众多Pythonist也可以借此开启更加有趣的学习旅程：数据统计、机器学习、计算机科学，甚至自然科学。
简单会激发出更强大的创造力吗？本期的码农人物罗晨，虽然不是
Python程序员，但是他身体力行地实践了“简单”这件事。他以前端工程
师为目标，成功地成为了一名在农场务农的独立开发 者。崇尚简约的
Markdown编辑器Mou，就是他的作品之一。希望他的生活经历，会给
你一个新的角度和一些不同的启示。
让我们从一成不变的生活中找到一些新鲜元素吧!学一门新的语言，教
一个朋友学会编程，或者为你的家人编写点什么。可能，就从Python开
始。专题：从Python开始PPP是什么？好玩的Python编程!
作者 Magnus Lie Hetland
挪威科技大学计算机科学专业副教授。最近在研究相似性搜索和度量
索引。著有《Python基础教程》、《Python算法》等。业余时间做兼
职演员。经常收到黑客关于切磋技术的邮件，从不回复。
译者司维
个人认为Python的强大功能之一，就是它让编程变得好玩——至少对我
来说是这样。只有感到编程是有趣的时候，才容易富有成效。Python最
有意思的地方之一就是它能让你的工作变得非常富有成效。这是个良性
循环，在生活中，这种循环可不多。
好玩的编程(Playful Programming)是我发明的词，是极限编程
(Extreme Programming，亦称XP)的非极限版本。XP的大多数点子我
都喜欢，但是我太懒了，不能完全遵守它的原则。所以现在挑了一些要
点出来，将它们与Python程序开发的自然方式组合起来。
程序设计的柔术
各位听说过柔术吗？这是一种日本武术，它和它衍生出来的柔道以及合
气道一样，都注重反应的灵敏性，或者说“弯而不断”。比赛时，不应该
试图使用预先设计好的移动蒙骗对手，而要顺其自然，以对手的动作还
治其身。这种方式(在理论上讲)可以击败比你高大、强壮和诡谲的对
手。那么怎样将柔术应用到程序设计中呢？关键在于“柔”字，也就是灵活
性。在编程遇到麻烦的时候(总会遇到的)，就不应该固守于原来的设
计和想法，而要灵活变通，以柔克刚。要准备好去应对和适应变化。不
要将没有预料到的事件看做让人沮丧的意外，而要将它们作为探索新的
选择和可能性的起点。
要说的是，当大家坐下并计划应该如何组织程序的时候，对于这个具体
的程序，你还没有任何的经验。怎么可能会有经验？毕竟它还不存在
呢。在实现功能的时候，会逐渐地学到对原始设计有用的新知识。不应
该无视一路走来所吸取的教训，而应该将它们用于软件的重新设计(或
者重构)中。这不是说应该像无头苍蝇一样，马上就开始着手工作——
而是说应该为改变而做好准备，并且接受“最初的设计会需要改进”这样
一个概念。就像以前一位作家说的“撰写即重写”。
灵活性的实现包括许多方面，下面是其中的两个：
原型设计。Python最棒的功能之一就是可以快速地编写程序。编写
原型程序是更充分地了解问题的一种很好的方法。
配置。灵活性有很多种存在形式。配置的目的就是让程序某部分的
改变更简单，对于你和用户来说都是这样。第三点是自动化测试。如果希望轻松改变程序的话，那么自动化测试绝
对是必不可少的。使用原地测试，就能保证你的程序在进行修改后还能
工作。原型设计和配置都会在下面的几节中讨论。
原型设计
一般来说，如果对于Python的某个地方不明白的话，那么尝试一下就好
了。首先，不需要进行多方面的预处理——比如编译或者链接，而这是
其他很多语言所必需的。可以直接运行你的代码。不止如此——还能在
交互式解释器里面逐个地运行，扫清每个角落，直到自己完全明白了它
的工作方式。
这类探索工作并不只限于语言特性和内建函数。当然，这对于了解类似
iter这样的函数的工作方式很有用，但更重要的是轻松地为你准备编写
的程序创建原型的能力，看看它是怎么工作的。
注意 在所谈及问题的背景中，原型(prototype)这个词意味着实验
性的实现，即实现最终程序主要功能的大概模型(mock-up)，但是
在以后的阶段可以完全重写或不重写原有程序。一般来说开始的原型
最后都会被改写成实用的程序。
在将一些思想融入到程序的结构中后(比如需要哪些类和函数)，建议
实现一个简单的版本，这个版本的功能可能非常有限。实现了一个可运
行的程序后，就能发现这个过程是多么简单。然后可以增加特性、改变
不喜欢的地方，等等。也可以看看它是如何工作的，而不是纸上谈兵画
画图表而已。
还能在任何程序设计语言中使用原型设计，但是Python的强大之处就在
于编写一个模型只需要很少的投入，而不用大动干戈。如果发现的设计
并不像预期的一样好用，就可以扔掉原型从头再来。这个过程可能要花
上几个小时、一天或者两天。如果用C++编程的话，要把某部分组织好
运行起来的话可能需要更多的精力，而否决原型也会成为一个重要的决
定。固守一个版本，也就失去了灵活性——注定被早先的决定禁锢住，而在真正实现程序的时候所获得的实际经验，可能会证实重写程序的决
定是错误的。
每个项目都会分为两个阶段的实现。第一个实现只是个摸索性质的试
验，在这个阶段会拼凑出一个能解决问题(或者是问题的一部分)的程序，以便了解所需要的组件和优秀解决方案的需求。能随时看到程序的
所有纰漏，是学习编程的最好一课。利用新学到的知识，会对第一次实
现的程序以更加正式的方式进行重建。当然，大家应该按自己的想法再
改进代码，甚至开始第三次的实现。一般来说，从头开始设计所花费的
时间并没有大家想得那么多。如果已经彻底想通了程序的实用性的话，那么敲代码的时间应该不会太长。
对代码重写说不
尽管这里推荐大家使用原型，但在任何时候对于从头开始重写项目给
出一些警告也是事出有因，尤其是对于原型下了很大功夫的时候。就
多方面来讲，还是推荐大家对原型进行重构和修改，将其完善为功能
性更好的系统。一个常见问题就是“第二系统综合症”。你希望第二个
版本变得更好，结果却永远无法完成。
而“持续重写综合征”也是文学界的术语，主要表现为对程序进行一些
无用的修改，程序员可能会一次又一次地从头开始重新设计。从某些
方面来看，适可而止可能是最佳策略——能工作足矣。
然后“代码疲劳”现象就出现了。程序员会厌烦代码。使用了很长时间
之后，就会觉得代码丑陋得不堪入目。很遗憾，由于需要迁就很多特
殊情况，代码会变得笨重，其中还有大量不同格式的错误处理代码。
但这些都是新版本中必须要重新引入的，而且要耗费你的大量精力
(不是以调试的形式)来首先实现。
换句话说，如果认为原型程序能完善为可以工作的系统，那不管怎么
说都要坚持下去，而不是推倒重来。下面的几章里面，程序的开发被
明确分为两个版本：原型和最终版本。这么做既是为了清晰，也是为
了强调编写第一版软件的时候所获得的经验和洞察力。在现实世界
中，以原型和“重构自身”作为最终系统的指导思想还是很靠谱的。
对于从头开始的可怕之处，请参见Joel Spolsky的文章“Things You
Should Never Do，Part 1”(你永不该做的事，第一部分)(可以在他
的网站http:joelonsoftware.com上找到)。根据Spolsky的说法，从头
写代码是任何软件公司都会犯下的最糟糕的决策性错误。
配置抽象的重要原则：一种更加简单的在程序中引入抽象的方法：从代码中
提取符号化常量(symbolic constant)。
提取常量
前面所说的常量(constant)指的是内建的字面量，例如数字、字符串
和列表。在程序中这些常量不用重复编写，放置在全局变量中即可。虽
然之前的章节讨论过使用全局变量的坏处，但是这种坏处一般只有在全
局变量被改变的时候才会体现出来，因为程序员可能难以追踪哪段代码
引起了哪个改变。我不会处理这些变量，在使用时把它们当做常量(也
就是术语符号化常量)就可以了。为了标识变量是作为符号化常量对待
的，可以使用特殊的命名规则——名字只用大写字母，并且用下划线分
隔每个单词。
先来看个例子。在计算圆面积和周长的程序中，每次需要π值的时候都
得写一遍3.14。那么如果后来需要更精确的值，比如3.14159时，又怎么
办呢？估计就得搜索整个代码，然后用新的值替换旧的。这么做不难，而且很多优秀的文本编辑器还能自动替换。但是如果开始用的值是3怎
么办？总不能把所有与3匹配的数字都替换成3.14159吧？当然不能。处
理这个问题更好的方法是用下面这行代码开始程序：PI = 3.14，然后使
用名字PI替代数字本身。这样一来如果在以后要更精确的值时，改动这
一行就可以了。记住这一点：所写的常量(比如数字42或者字符
串“Hello, world!”)出现次数多于一次的时候，就应该考虑将它放入全
局变量中。
注意 事实上，π的值可以在math模块中找到，使用math.pi即可：
>> from math import pi
>> pi
3.1415926535897931
这一点看起来很容易理解——没问题。真正的目的在下面：配置文件。
配置文件
为自己使用方便提取常量是一码事，还要考虑有些常量是要公开给用户
的。比如用户不喜欢GUI程序的背景色，你就应该允许他们换另外一种
颜色。或者可以让用户在启动那好玩的游戏时，看到他们自己设定的问候语，抑或是可以在刚刚实现的浏览器中更改默认启动页。
这里不是将这些配置变量放在模块的开头，而是将它们放在单独的文件
中。实现这个功能的最简单方法就是为配置创建单独的模块。例如，如
果PI在模块文件config.py中设定，你可以(在主程序内)这样做：
from config import PI
如果用户想改变PI的值，那么他就只要修改config.py就行，而不用看完
所有代码。
警告 使用配置文件具有两面性。一方面，配置功能很有用，但对整
个项目使用集中、共享的变量库会让项目的模块性下降、整体性上
升。一定要确保没有破坏抽象(比如封装)规则。
另外一种方法是使用标准库模块ConfigParser，它的作用是对配置文件
使用适当的标准格式。它接受标准的Python赋值语法，比如如下形式：
greeting = 'Hello, world!'
(这样语句会在的字符串中加上两个多余的双引号)另外一种在很多程
序中使用的配置格式如下：
greeting: Hello, world!
需要使用[files]或者[colors]这样的数据头将配置文件划分为几个区段
(section)。名称可以随意设定，但是需要将它们用方括号括起来。代
码清单1是一个简单的配置文件示例，使用它的程序如代码清单2所示。
有关ConfigParser模块特性的更多信息，可以查阅库文档。
代码清单1 简单的配置文件
[numbers]
pi: 3.1415926535897931
[messages]`
greeting: Welcome to the area calculation program!
question: Please enter the radius:
result_message: The area is代码清单2 使用ConfigParser的程序 from ConfigParser import
ConfigParser
CONFIGFILE = python.txt
config = ConfigParser
读取配置文件：
config.read(CONFIGFILE)
打印初始的问候语：
要查看的区段是'messages'
print config.get('messages', 'greeting')
使用配置文件的一个问题读取半径：
radius = input(config.get('messages', 'question') + ' ')
打印配置文件中的结果信息。
以逗号结束，以在同一行显示：
print config.get('messages', 'result_message'), getfloat将config值转换为float类型：
print config.getfloat('numbers', 'pi') radius2
对于接下来几个项目的配置不再赘述，但是建议读者让自己的程序具有
高配置性。这样一来，用户就可以按照自己的习惯使用程序，使用时也
会心情愉悦。毕竟使用软件过程中最大的挫折之一就是不能让软件按自
己想要的方式工作。
《Python基础教程(第2版)》前几章都在介绍最基本的程序设计理
念，例如极限编程、面向对象程序设计，对于没有多少开发经验或者准备以Python进行编程入门的新手来说，这些章节则是不容错过的。作者
对Python语言的各个方面的剖析准确而到位，各部分会花上不同篇幅确
保读者理解而又不会浪费时间。本书最后的10个项目都是难得的练手机
会——这也是本书不同于其他Python教程的特色之一。这10个项目基本
覆盖了前面章节所提到的各种知识点，同时又不乏趣味性和实用性。本
文摘自《Python基础教程(第2版)》。为什么要用Python实现机器学习算法？
作者 Peter Harrington
拥有电气工程学士和硕士学位，他曾经在美国加州和中国的英特尔公
司工作7年。Peter拥有5项美国专利，在三种学术期刊上发表过文章。
他现在是Zillabyte公司的首席科学家，在加入该公司之前，他曾担任2
年的机器学习软件顾问。Peter在业余时间还参加编程竞赛和建造3D
打印机。
译者曲亚东
在写作《机器学习实战》时，我为什么要选择Python作为实现机器学习
算法的编程语言呢？其原因主要可以归纳为以下三条：(1) Python的语
法清晰；(2) 易于操作纯文本文件；(3) 使用广泛，存在大量的开发文
档。
可执行伪代码
Python具有清晰的语法结构，大家也把它称作可执行伪代码
(executable pseudo-code)。默认安装的Python开发环境已经附带了很
多高级数据类型，如列表、元组、字典、集合、队列等，无需进一步编
程就可以使用这些数据类型的操作。使用这些数据类型使得实现抽象的
数学概念非常简单。此外，读者还可以使用自己熟悉的编程风格，如面
向对象编程、面向过程编程、或者函数式编程。不熟悉Python的读者可
以参阅附录A，该附录详细介绍了Python语言、Python使用的数据类型
以及安装指南。Python语言处理和操作文本文件非常简单，非常易于处理非数值型数
据。Python语言提供了丰富的正则表达式函数以及很多访问Web页面的
函数库，使得从HTML中提取数据变得非常简单直观。
Python比较流行
Python语言使用广泛，代码范例也很多，便于读者快速学习和掌握。此
外，在开发实际应用程序时，也可以利用丰富的模块库缩短开发周期。
在科学和金融领域，Python语言得到了广泛应用。SciPy和NumPy等许
多科学函数库都实现了向量和矩阵操作，这些函数库增加了代码的可读
性，学过线性代数的人都可以看懂代码的实际功能。另外，科学函数库
SciPy和NumPy使用底层语言(C和Fortran)编写，提高了相关应用程序
的计算性能。
Python的科学工具可以与绘图工具Matplotlib协同工作。Matplotlib可以
绘制2D、3D图形，也可以处理科学研究中经常使用到的图形。
Python开发环境还提供了交互式shell环境，允许用户开发程序时查看和
检测程序内容。
Python开发环境将来还会集成Pylab模块，它将NumPy、SciPy和
Matplotlib合并为一个开发环境。在本文写作时，Pylab还没有并入
Python环境，但是不远的将来我们肯定可以在Python开发环境找到它。
Python语言的特色
诸如MATLAB和Mathematica等高级程序语言也允许用户执行矩阵操
作，MATLAB甚至还有许多内嵌的特征可以轻松地构造机器学习应
用，而且MATLAB的运算速度也很快。然而MATLAB的不足之处是软
件费用太高，单个软件授权就要花费数千美元。虽然也有适合
MATLAB的第三方插件，但是没有一个有影响力的大型开源项目。
Java和C等强类型程序设计语言也有矩阵数学库，然而对于这些程序设
计语言来说，最大的问题是即使完成简单的操作也要编写大量的代码。
程序员首先需要定义变量的类型，对于Java来说，每次封装属性时还需
要实现getter和setter方法。另外还要记着实现子类，即使并不想使用子类，也必须实现子类方法。为了完成一个简单的工作，我们必须花费大
量时间编写了很多无用冗长的代码。Python语言则与Java和C完全不
同，它清晰简练，而且易于理解，即使不是编程人员也能够理解程序的
含义，而Java和C对于非编程人员则像天书一样难于理解。
所有人在小学二年级已经学会了写作，然而大多数人必须从事其他更
重要的工作。
——鲍比·奈特
也许某一天，我们可以在这句话中将“写作”替代为“编写代码”，虽然有
些人对于编写代码很感兴趣，但是对于大多数人来说，编程仅是完成其
他任务的工具而已。Python语言是高级编程语言，我们可以花费更多的
时间处理数据的内在含义，而无须花费太多精力解决计算机如何得到数
据结果。Python语言使得我们很容易表达自己的目的。
Python语言的缺点
Python语言唯一的不足是性能问题。Python程序运行的效率不如Java或
者C代码高，但是我们可以使用Python调用C编译的代码。这样，我们就
可以同时利用C和Python的优点，逐步地开发机器学习应用程序。我们
可以首先使用Python编写实验程序，如果进一步想要在产品中实现机器
学习，转换成C代码也不困难。如果程序是按照模块化原则组织的，我
们可以先构造可运行的Python程序，然后再逐步使用C代码替换核心代
码以改进程序的性能。C++ Boost库就适合完成这个任务，其他类似于
Cython和PyPy的工具也可以编写强类型的Python代码，改进一般Python
程序的性能。
如果程序的算法或者思想有缺陷，则无论程序的性能如何，都无法得到
正确的结果。如果解决问题的思想存在问题，那么单纯通过提高程序的
运行效率，扩展用户规模都无法解决这个核心问题。从这个角度来看，Python快速实现系统的优势就更加明显了，我们可以快速地检验算法或
者思想是否正确，如果需要，再进一步优化代码。
《机器学习实战》在amazon.com的机器学习品类中排名16，数据挖掘品
类中排名24。作者Peter Harrington是英特尔前任工程师，拥有5项美国专
利权，曾在学术刊物上发表过多篇文章。本书共四部分，讲述监督学习
和无监督学习，涉及k近邻算法、决策树、朴素贝叶斯算法、支持向量
机、AdaBoost算法、k均值、分类回归树等十几种算法，讲述每种算法
时都配有具体示例。本文摘自《机器学习实战》。第一个孩子的出生时间研究：程序员的统计思维
练习
作者 Allen Downey
Allen B. Downey是富兰克林欧林工程学院的计算机科学副教授，曾执
教于韦尔斯利学院、科尔比学院和加州大学伯克利分校。他先后获麻
省理工学院计算机科学硕士学位和加州大学伯克利分校计算机科学博
士学位。Downey已出版十余本技术书，内容涉及Java、Python、C++、概率统计等。他是自由书籍的倡导者，也是Google公司前客座
科学家。他的最新Think系列书还有Think Complexity, Think Python
等。
译者 张剑锋、陈钢
如果在Google上搜索这个问题，你会看到大量的相关讨论。有些人说确
实如此，也有人说这没根据，还有人持完全相反的观点：第一个孩子会
在预产期之前出生。
在这类讨论中，人们会用各种数据来证明自己的说法，常见的例子如
下。
“我有两个朋友最近都刚生了第一个孩子，两个宝宝的出生时间都比
预产期晚了差不多两周。”
“我的第一个孩子晚了两周才出生，我想我的第二个孩子会提前两
周。”
“我觉得这没道理，因为我姐姐是我妈妈的第一个孩子，她就提前出生了，我的几个表姐也一样。”
诸如此类的传闻称为经验之谈(anecdotal evidence)，因为它们基于非
公开发表的数据，而且通常是个人感受。在非正式场合，这类说辞没问
题，所以这里并不是说上述观点不对。问题在于，我们需要更有说服力
的证据和更可靠的结论。但这些经验之谈显然做不到这一点，原因如
下。
观察的数量太少
第一胎宝宝的妊娠期比较长，但这种差异可能在自然波动范围内。
这种情况下，我们需要比较大量孕妇的妊娠期数据才能判断这种差
异是否真的存在。
选择偏差
第一胎宝宝出生比较晚的父母会更有兴趣加入这样的讨论。这种对
数据进行选择的过程就会导致结果不准确。
确认偏差
相信这种说法的人会提供支持示例，而怀疑这种说法的人则会引用
反例。
不准确
传闻通常都是个人的经历，在记忆、表述和复述等方面都会不准
确。
那么，更好的做法是什么呢？
统计方法
为了解决上述经验之谈的种种不足，我们会运用以下统计学手段。
收集数据
使用大型全国性调查的数据，这些数据是为得出美国人口方面可靠
的统计推断而专门收集的。描述性统计
计算能总结数据的统计量，并评测各种数据可视化的方法。
探索性数据分析
寻找模式、差异和其他能解答我们问题的特征。同时，我们会检查
不一致性，并确认其局限性。
假设检验
在发现明显的影响时(比如两个族群间的差异)，我们需要评判这
种影响是否真实，也就是说是否是因为随机因素造成的。
估计
我们会用样本数据推断全部人口的特征。
通过这些步骤，绕过各种陷阱，我们就能得到更加合理也更可能正确的
结论。
全国家庭成长调查
美国疾病控制与预防中心(CDC)从1973年开始推行全国家庭成长调查
(NSFG)，目的是收集(美国)“家庭的生活、婚姻状况、生育、避孕
和男女健康信息。调查的结果用于……制定健康服务和健康教育计划，以及对家庭、生育和健康的统计研究”。1
1 参见 http:cdc.govnchsnsfg.htm。
我们会利用调查收集的数据来研究诸如“第一个小孩是否出生得较晚”之
类的问题。为了有效使用这些数据，我们需要理解这个调查是怎么设计
的。
NSFG是一个横断面研究(cross-sectional study)，意思就是它的数据是
一群人在某个时间点的情况。另一种常见方法是纵贯研究(longitudinal
study)，就是在一段时间内反复观察同一群人。
NSFG已经进行了7次，每次称为一个周期(cycle)。我们会使用来自Cycle 6的数据，这些数据是在2002年1月到2003年3月间收集的。
NSFG的目的是得到关于人口情况的一些结论，调查对象是15到44岁的
美国人。
参与调查的人称为被调查者(respondent)，一组被调查者就称为队列
(cohort)。通常，横断面研究意味着具有代表性，即目标人群中的每
一个人都有同等的几率参与调查。当然，实际很难实现这种理想状况，但执行调查的人会尽可能地做到这一点。
NSFG不具有代表性，而是有意进行了过采样(oversample)。设计者
所调查的西班牙裔、非裔美国人和青少年的比例都高于他们在美国人口
中的比例。过采样这些人群是为了确保其中的被调查者数量够大，从而
得到有效的统计推断。
当然，过采样增大了根据调查结果推断全体人口结论的难度。稍候我们
会继续讨论这一点。
习题1
尽管NSFG已经进行了7次，但它并不是纵贯研究。阅读维基百科页面关
于横断面研究和纵向研究可以弄清楚原因。
习题2
这个练习需要从NSFG下载数据。
1. 打开http:thinkstats.comnsfg.html，阅读数据的使用协议，然后点
击“I accept these terms”(假设你确实同意)。
2. 下载2002FemResp.dat.gz和2002FemPreg.dat.gz两个文件。前者是被
调查者文件，每一行代表一个被调查者，总共7643个女性被调查
者。后者是各个被调查者的怀孕情况。
3. 调查的在线资料地址：http:www.icpsr.umich.edunsfg6。浏览左侧
导航栏中调查的各部分，大致了解一下其中的内容。还可以
在http:www.cdc.govnchsdatansfgnsfg_2002_questionnaires.htm上
阅读调查问卷的内容。4. 配套网站提供了处理NSFG数据文件的代码。从
http:thinkstats.comsurvey.py下载，然后在放置数据文件的目录中
运行。程序会读取数据文件，然后会显示每个文件的行数：
Number of respondents 7643
Number of pregnancies 13593
5. 浏览一下代码，大致了解一下其功能。下一节会详细介绍。
表和记录
诗人、哲学家Steve Martin曾说：
“Oeuf”就是egg，“chapeau”就是hat。好像所有的东西在法语中都跟在
英语中的叫法不一样。
跟法语一样，数据库程序员的语言也跟我们的日常语言稍有不同。因为
我们要谈到数据库，所以有必要学习一些专业术语。
被调查者文件中的每一行都表示一个被调查者。这行信息称为一条记录
(record)，组成记录的变量称为字段(field)，若干记录的集合就组
成了一个表(table)。
看一下survey.py中的代码，就会看到Record和Table这两个类的定义，前
者是代表记录的对象，后者则是表示表的对象。
Record有两个子类，分别是Respondent和Pregnancy，两者分别是被调查
者和怀孕的记录。目前这些类暂时还是空的，其中还没有用于初始化其
属性的init方法。我们会用Table.MakeRecord方法将一行文本转换成一个
Record对象。
Table也有两个子类Respondents和Pregnancies。这两个类的init方法设置
了数据文件的默认名称和要创建的记录的类型。每个Table对象都有一
个records属性，是一个Record对象的列表。
每个Table的GetFields方法返回一个指定记录字段的元组(tuple)列表，这些字段就是Record对象的属性。
例如，下面是Pregnancies.GetFields：def GetFields(self):
return [
('caseid', 1, 12, int),('prglength', 275, 276, int),('outcome', 277, 277, int),('birthord', 278, 279, int),('finalwgt', 423, 440, float),]
第一个元组的意思从第1列到第12列是caseid字段，且类型为整数。每个
元组包含如下信息。
field
保存该字段的属性的名称。大部分情况下，我使用NSFG编码手册
中的名称，全部用小写。
start
该字段的起始列编号。例如，caseid的起始编号是1。可以在NSFG
编码手册中查询这些编号：http:www.icpsr.umich.edunsfg6。
end
该字段的结束列编号。例如，caseid的结束列编号是12。跟Python
中不一样，这里的结束列也是该字段的一部分。
转换函数
将字符串转换成其他类型的函数。可以用内置的函数，比如int和
float，也可以使用用户自定义的函数。如果转换失败，属性的值就
会是字符串'NA'。如果某个字段不需要转换，可以使用identity函数
或是str函数。
从pregnancy记录中可以得到以下变量。
caseid
被调查者的整数ID。prglength
怀孕周期，单位是周。
outcome
怀孕结果的整数代码。代码1表示活婴。
birthord
正常出生的婴儿的顺序。例如，第一胎婴儿的编号是1。如果没有
正常出生，该字段为空。
finalwgt
被调查者的统计权重。这是一个浮点值，表示这名被调查者所代表
的人群在美国总人口中的比例。过采样人群的权重偏低。
如果你仔细阅读编码手册，就会发现这些变量大部分都经过了重编
码(recode)，也就是说这并不是调查所采集的原始数据，而是根
据原始数据计算出来的。
例如，第一胎活婴的prglength在原始数据中有变量wksgest(妊娠周数)
时就等于该变量的值，否则就会用mosgest 4.33(妊娠月数乘以每个月
的平均周数)估计出来。
重编码通常遵循数据一致性和准确性原则。除非有特别原因一定要使用
原始数据，否则就应该直接使用重编码后的数据。
你可能还发现了Pregnancies有Recode方法，用来做一些其他的检查和重
编码工作。
习题3
在这个练习中，我们会编写一个程序来看看Pregnancies表中的数据。
1. 在survey.py和数据文件的目录中创建一个first.py文件，然后将下面
的代码输入或复制到文件中：
import surveytable = survey.Pregnancies
table.ReadRecords
print 'Number of pregnancies', len(table.records)
结果应该是13 593条怀孕记录。
2. 编写一个循环遍历表(table)，计算其中活婴的数量。查阅临床结
果(outcome)的文档，确认你的结果跟文档中的总结一致。
3. 修改这个循环，将活婴的记录分成两组：一组是第一胎出生；另一
组是其他情况。再看一些出生顺序(birthord)的文档，看看你的
结果跟文档中的结果是否一致。
在处理新的数据集时，这种检查对于发现数据中的错误和不一致
性、检查程序中的错误以及检验对字段编码方式的理解是否正确等
都是很有用的。
4. 分别计算第一胎宝宝和其他宝宝的平均怀孕周期(单位是周)。两
组之间有差异吗？差异有多大？
从http:thinkstats.comfirst.py可下载这个练习的答案。
显著性
在前面的练习中，我们比较了第一胎宝宝和其他宝宝的妊娠期。如果一
切顺利，读者会发现第一胎宝宝的出生时间比其他宝宝的出生时间平均
晚13个小时。
类似这样的差异称为直观效应(apparent effect)，意思就是似乎发生了
有意思的事情，但还不确定。我们还需要考虑以下问题。
如果两组的均值不一样，其他汇总统计量如何，比如中值和方差？
我们能更精确地描述它们之间的差异吗？
有没有可能这两组实际上是一样的，而我们所观察到的这种差异只
是随机产生的？如果是，那这个结论就不是统计显著的。
这种直观效应有没有可能是因为选择偏差或是实验设置中的错误导
致的？如果是，那么这种直观效应就是人为的，也就是我们意外创
造的，而并非发现了事实。习题4
学习统计学的最好方法就是从一个自己感兴趣的项目开始。有没有“第
一胎宝宝出生较晚”这类吸引你的问题来研究？
思考自己感兴趣的问题，例如传统观念、有争议的话题或是有社会影响
的问题，看看你能否将这些问题转换成统计学问题。
寻找能解决该问题的数据。国外政府是很好的数据来源，因为公共研究
的数据通常都是免费的2。另一个查找数据的好去处是Wolfram Alpha，其中收集了很多经过验证的高质量的数据集，网址
是http:wolframalpha.com。Wolfram Alpha的搜索结果是有版权限制
的，在使用之前应该阅读一下协议。
2 在撰写这段内容的时候，英国某法院规定“信息自由法案”(Freedom of Information Act)也适
用于科学研究数据。
Google和其他的一些搜索引擎也能帮你寻找数据，但网络上各种资源的
质量高低不一，判断起来不容易。
如果发现已经有人回答了你的问题，要仔细看看回答是否合理。数据和
分析中的缺陷可能会导致结论不可靠。如果是这样，你应该采用不同的
方法来分析数据，或者是寻找其他更好的数据来源。
如果已发表的论文回答了你的问题，那就应该能弄到原始数据，很多作
者都会在网上提供。但如果数据涉及个人隐私，最好联系一下作者，告
诉他你要如何使用数据，或是接受特定的使用协议。坚持到底!
《统计思维：程序员数学之概率统计》是一本以全新视角讲解概率统计
的入门图书。抛开经典的数学分析，Downey手把手教你用编程理解统
计学。概率、分布、假设检验、贝叶斯估计、相关性等，每个主题都充
满趣味性，经编程解释后变得更为清晰易懂。
本书研究数据主要来源于美国全国家庭成长调查(NSFG)与行为风险
因素监测系统(BRFSS)，数据源及解决方案的相关代码全部开放，具
体章节列出了大量学习和进阶资料，方便读者参考。本文选自《统计思
维：程序员数学之概率统计》。和孩子一起做一只电子宠物吧!
作者 Warren Sande, Carter Sande
Warren(父亲)毕业于加拿大里贾那大学电气工程系。一直在面向计
算机初学者教授软件基础课程，编写过大量广受欢迎的技术文档。
Carter——Warren之子，一个聪明、热情、好奇心强、喜欢思考问题
的小男孩，热爱计算机，喜欢弹钢琴和玩超级玛丽。很小的时候就开
始跟着父亲玩编程。
译者 苏金国我们将要建立一个简化了的电子宠物程序，正如前面所说的一样，这是
一种仿真。你可以购买电子宠物玩具(比如有一个小屏幕的钥匙链)，下载电子宠物软件，还有一些网站(如 Neopets 和 Webkinz)，就采用
了电子宠物的形式。当然，所有这些也都是仿真。它们会模仿一些真实
动物的行为，会饿，会感到孤单，会觉得累。要让它们快乐健康，你必
须给它们喂食，和它们玩，还要带它们看病。
我们的电子宠物会简单得多，与你购买或下载的电子宠物相比没有那么
真实，因为我只是想让你有一些基本认识，而且我不希望代码太过复
杂。不过你可以在这个简化版本的基础上，根据你的想法进行扩展或改
进。
我们的程序要具备以下特性。
对这个宠物可以有 4 种活动：给它喂食、带它散步、和它玩或者带
它看病。可以监测这个宠物的 3 种统计信息：饥饿感、快乐度和健康度。
宠物可以醒着或者睡觉。
饥饿感会随时间增加。可以通过喂食减少饥饿感。
宠物睡觉时饥饿感的增加会减慢。
如果宠物在睡觉，你做任何活动都会让它醒过来。
如果宠物太饿了，它的快乐度会减少。
如果宠物实在太饿了，它的健康度会减少。
带宠物散步会同时增加它的快乐度和健康度。
与宠物玩会让它的快乐度增加。
带宠物看病会让它的健康度增加。
宠物有 6 个不同的图片：
一个睡觉的图片；
一个醒着但什么也不做的图片；
一个散步的图片；
一个玩耍的图片；一个进食的图片；
一个看病的图片。
图片可以使用一些简单的动画。后面几节我们将看到如何把所有这些整
合在一起构成一个程序。
GUI
Carter 和我为我们的电子宠物程序创建了一个 PythonCard GUI。其中有
一些按钮用来完成活动，还有一些计量器显示重要的统计信息。另外还
留有一个位置显示宠物的图片(宠物正在做什么)。看起来就像右图这
样：
对应活动的按钮是一种 ImageButton 类型的 PythonCard 组件。利用这种
组件可以创建带图片的按钮，而不只是文本。各个计量器的组件类型是
Gauge。主图片是一个 Image 组件。标签是 StaticText 组件。
你可以使用 PythonCard 资源编辑器创建这样的 GUI。
算法要为电子宠物程序写代码，需要更明确地了解宠物的行为。以下是我们
要使用的算法。
我们把宠物的一“天”分为 60 个部分，每一部分称为一个“滴答”。
每个滴答的实际时间是 5 秒钟，所以宠物的“一天”就是我们实际时
间的 5 分钟。
宠物在 48 个滴答中都醒着，然后它想睡 12 个滴答。你可以把它叫
醒，不过这样会让它很不高兴!
饥饿感、快乐度和健康度的范围都是 0 到 8。
醒着时，饥饿感每个滴答会增加 1 个单位，快乐度每 2 个滴答减少
1 个单位(除非在散步或者玩)。
睡觉时，饥饿感每 3 个滴答增加 1 个单位。
进食时，饥饿感每个滴答减少 1 个单位。
玩时，快乐度每个滴答增加 1 个单位。
散步时，快乐度和健康度每 2 个滴答增加 1 个单位。
看病时，健康度每个滴答增加 1 个单位。
如果饥饿感达到 7，健康度每 2 个滴答减少 1 个单位。
如果饥饿感达到 8，健康度每个滴答减少 1 个单位。
如果睡觉时被叫醒，快乐度减少 4 个单位。
如果程序不在运行，宠物可能醒着(什么也不做)，也可能在睡
觉。
程序重启时，我们会统计过去了多少滴答，并对应过去的每个滴答
更新统计信息。
看起来好像规则很多，不过编写代码其实很容易。实际上，你可能还想
增加更多的行为，让它更加有趣。稍后就会给出代码(还会做一些解释)。
简单动画
并不总是需要 Pygame 才能完成动画。我们可以在 PythonCard 中通过使
用定时器完成简单的动画。定时器每隔一段时间会创建一个事件。可以
编写一个事件处理器，在定时器到时间时让某个事情发生。这就类似于
为一个用户动作编写事件处理器，比如说点击一个按钮，只不过定时器
事件是由程序(而不是用户)生成的。
我们的电子宠物 GUI 将使用两个定时器：一个用于动画，另一个用于
滴答。动画每半秒(0.5 秒)更新一次，滴答每 5 秒发生一次。
动画定时器时间到时，我们会所显示宠物的图像。每个活动(进食、玩
等)都有自己的一组图像来实现动画，每组图像将存储在一个列表中。
动画会循环显示这个列表中的所有图像。程序将根据正在进行的活动来
确定使用哪个列表。
试一试，再试一试
这个程序中还要使用一个新内容，这称为 try-except 块。
如果程序要做一件事情，而且这个事情有可能导致错误，那么最好提供
一种办法来收集错误消息并进行处理，而不是让程序直接停止。这可以
利用 try-except 块来做到。
例如，如果想打开一个文件，但是这个文件并不存在，你就会得到一条
错误消息。如果你没有处理这个错误，程序会在这里停止。不过，也许
你想让用户重新输入文件名(没准她只是敲错了)。利用 try-except
块，你可以获取到错误信息并继续执行。
对于打开文件的例子，try-except 块如下所示：
try:
file = open(somefile.txt, r)
except:
print Couldn't open the file. Do you want to reenter the filename?
你想尝试的部分(可能导致一个错误)要放在 try 块中。在这个例子中就是尝试打开一个文件。如果可以打开文件而不会导致错误，就会跳过
except 部分。
如果 try 块中的代码确实导致一个错误，就会运行 except 块中的代码
except 块中的代码告诉程序一旦出现错误该做些什么。你可以这样来
考虑：
try:
做这件事 ( 不做其他事情...)
except:
如果有错误，就做这件事
try-except 语句是 Python 处理错误所采用的方法，这通常称为错误处
理(error handling)。错误处理允许你编写可能出错的代码(甚至是很
严重的错误，倘若没有错误处理，这些错误在正常情况下甚至会让你的
程序停止)，使程序仍能继续运行。我们不打算在这本文里更详细地讨
论错误处理，不过我希望你能了解一些基础知识，因为在电子宠物代码
中就会看到错误处理。
下面来看这个代码，见代码清单。这里的说明已经对大部分工作做了解
释。这个代码有点长，所以如果你不想自己键入，也可以从这个网站
(www.helloworldbook.com)下载。PythonCard 资源文件和所有图片也
都已经提供。试着运行这个程序，然后再看代码，确保你能理解它是如
何工作的。
代码清单 VirtualPet.pysleeptest 函数使用了一个 PythonCard 对话框，不过稍做了调整。你可
能记得，PythonCard 要基于另一个名为 wxPython 的 Python 模块。正是
因为这个原因，安装 PythonCard 时要安装 wxPython。有时可以使用特
殊的 wxPython 参数来改变 PythonCard 的行为。在这里，我们改变了标
准 PythonCard 消息框，如右图所示。
我们把它变成一个有感叹号的对话框，还有 Yes 和 No 按钮，就像右图
这样。
即使你不能完全读懂这个代码也不用担心。如果你希望学习更多有关
PythonCard 和 wxPython 的内容，可以先看看 PythonCard 网
站：http:pythoncard.sourceforge.net。
在本文中，我们只是稍稍了解了计算机仿真的一点皮毛，知道了模拟真
实世界中一些方面的基本思想，比如重力和时间。实际上，计算机仿真
在科学、工程、医药和很多其他领域都得到了广泛使用。其中很多仿真
非常复杂，即使用最快的超级计算机运行也需要花费几天甚至几个星
期。不过钥匙链上的小电子宠物也是一种仿真，有时最简单的仿真也是最有意思的。
动手试一试
为电子宠物 GUI 增加一个 Pause 按钮。这会让宠物的时间停止，不论程
序是否在运行。(提示：这说明可能需要在 pickle 文件中保存“暂停”状
态。)
《与孩子一起学编程》一本老少咸宜的编程入门奇书!一册在手，你完
全可以带着自己的孩子，跟随Sande父子组合在轻松的氛围中熟悉那些
编程概念，如内存、循环、输入和输出、数据结构和图形用户界面等。
这些知识一点儿也不高深，听起来备感亲切，书中言语幽默风趣而不失
真义，让学习过程充满乐趣。细心的作者还配上了孩子们都喜欢的可爱
漫画和经过运行测试的程序示例，教你用最易编写和最易理解的Python
语言，写出你梦想中的游戏程序。本文选自《与孩子一起学编程》。从Python 3的bytesstr之别学编码Unicode
作者 Eli Bendersky, Steve Ferg
Eli Bendersky开发软件长达15年之久。在2008年开始使用Python,并且
是这门语言的主要贡献者之一。他使用过很多语言，但是最爱的还是
C和Python，业余时间爱好编程。他的博客http:eli.thegreenplace.net
Steve Ferg是一位程序员和系统分析师，同时他还是康奈尔大学哲学
系的博士。他的博客https:pythonconquerstheuniverse.wordpress.com
译者 李琳骁
译著有《编程大师访谈录》、《编程人生》等。现正在翻译Coding
Interview(程序员面试题解密)。
引子：bytesstr之别
Python 3最重要的新特性大概要算是对文本和二进制数据作了更为清晰
的区分。文本总是Unicode，由str类型表示，二进制数据则由bytes类型
表示。Python 3不会以任意隐式的方式混用str和bytes，正是这使得两者
的区分特别清晰。你不能拼接字符串和字节包，也无法在字节包里搜索
字符串(反之亦然)，也不能将字符串传入参数为字节包的函数(反之
亦然)。这是件好事。
不管怎样，字符串和字节包之间的界线是必然的，下面的图解非常重
要，务请牢记于心：字符串可以编码成字节包，而字节包可以解码成字符串。
>>> '�20'.encode('utf-8')
b'\xe2\x82\xac20'
>>> b'\xe2\x82\xac20'.decode('utf-8')
'�20'
这个问题要这么来看：字符串是文本的抽象表示。字符串由字符组成，字符则是与任何特定二进制表示无关的抽象实体。在操作字符串时，我
们生活在幸福的无知之中。我们可以对字符串进行分割和分片，可以拼
接和搜索字符串。我们并不关心它们内部是怎么表示的，字符串里的每
个字符要用几个字节保存。只有在将字符串编码成字节包(例如，为了
在信道上发送它们)或从字节包解码字符串(反向操作)时，我们才会
开始关注这点。
传入encode和decode的参数是编码(或codec)。编码是一种用二进
制数据表示抽象字符的方式。目前有很多种编码。上面给出的UTF-8是
其中一种，下面是另一种：
>>> '�20'.encode('iso-8859-15')
b'\xa420'
>>> b'\xa420'.decode('iso-8859-15')
'�20'
编码是这个转换过程中至关重要的一部分。离了编码，bytes对
象b'\xa420'只是一堆比特位而已。编码赋予其含义。采用不同的编
码，这堆比特位的含义就会大不同：
>>> b'\xa420'.decode('windows-1255')
'?20'
据说百分之八十的金钱损失皆因使用错误的编码导致，因此务必小心谨慎。
什么是编码？
基本概念很简单。首先，我们从一段信息即消息说起，消息以人类可以
理解、易懂的表示存在。我打算将这种表示称为“明文”(plain text)。
对于说英语的人，纸张上打印的或屏幕上显示的英文单词都算作明文。
其次，(原因稍候再述)我们需要能将明文表示的消息转成另外某种表
示(不妨称之为“编码文本”，encoded text)，我们还需要能将编码
文本转回成明文。从明文到编码文本的转换称为“编码”，从编码文本又
转回成明文则为“解码”。
这个过程有三点很重要。
第一点是在编码或解码过程中不得丢失任何信息。我们必须能做到来回
传递消息，从明文到编码文本，然后又从编码文本回到明文，取得的明
文跟我们一开始拥有的完全一样。举例来说，这正是为什么我们无法用
一种自然语言(俄语、汉语、法语、纳瓦霍语等)来编码另一种自然语
言(英语、印地语、斯瓦西里语等)。自然语言之间的映射关系太过松
散，无法保证一条信息能在来回的转换中不失真。
要求来回转换不失真，也就意味着明文和编码文本之间的映射必须又紧
密又精确。这就引出了第二点。
为确保明文和编码文本之间的映射非常紧密，也即，为了能非常精确地
规定编码和解码过程是怎么回事，我们必须非常精确地规定明文的表示
是什么样的。
例如，假定我们的明文是这样的：英美字母表的26个大写字母，加上空
格，及3个标点符号：句点(句号)、问号和短划线(连字符)。这就
形成了30个字符的明文字母表。需要数字时，我们可以直接拼写出来，比如：six thousand seven hundred forty-three(六千七百四十三)。另一方面，我们可能希望明文是这样的：26个大写字母，26个小写字
母，10个数字，空格符，及十几种标点符号，包括句点、逗号、双引
号、左括号、右括号等等。于是我们又得到一张75个字符的明文字母
表。
一旦精确地规定了消息的明文表示是什么样的，比如上面的30个字符的
字母表，也许是75个字符的字母表中有限的字符序列，我们就可以设计
一套系统(编码，code)，能对用这张字母表写成的明文消息进行可靠
的编码和解码。这类系统最简单的一种是明文字母表里的每个字符在编
码文本中有一个且只有一个对应的表示。举个大家都熟悉的摩尔斯电码
的例子，其中明文“SOS”对应的编码文本为... --- ...。
当然，在现实生活中，明文字母表中字符的选择受到编码文本上技术限
制的影响。假定存储编码消息有如下几种技术可供选择：一种技术支持
256个字符的编码字母表，另一种技术只支持128个编码字符，第三种技
术只支持64个编码字符。如果我们清楚自己可以使用支持更大编码文本
字母表的技术，我们自然而然就能将明文字母表扩展得比以往大得多。
反之亦然。如果确定明文字母表一定要非常大，我们就会明白必须找到
或设计一种能存储大量编码字符的技术。
这就引出了下面的话题，Unicode。
Unicode
Unicode的设计初衷是成为一套系统，可以存储现存所有人类语言的所
有明文字符的编码表示。英语、法语、西班牙语、希腊语、阿拉伯语、印地语、汉语和亚述语(楔形文字)等。
这些字符数量庞大。
因此，Unicode计划的首要任务就是把所有这些字符罗列出来，数个
数。这就是Unicode的前半部分，通用字符集(Universal Character
Set)。(真正谈及Unicode时，不要把明文字符叫做“字符”，称之为“码
点”(code points)。)
完成前面的工作后，你还得想出一种技术，以储存全部对应的编码文本
字符。(用Unicode的话来说，编码文本字符被称作“码值”(codevalues)。)
实际上，Unicode定义了不止一种方法，将码点映射到码值。这些方法
都有自己的名字。其中部分名字以“UTF”开头，其他以“UCS”开头：
UTF-8、UTF-16、UTF-32、UCS-2、UCS-4等等。命名规范是“UTF-<码
值的比特数>”和“UCS-<码值的字节数>”。有些方法(如UCS-4和UTF-
32)功能相若。参看维基百科Unicode相关页面。
关于这些方法最重要的一点是，有些方法是定长编码，有些则是变长编
码。基本思想是定长编码都很长，如UCS-4和UTF-32都有4字节(32比
特)长，长到足以hold住未来可期的最大码值。
相比而言，变长编码则设计成简短但可扩展。例如，UTF-8可以使用少
至8比特(1字节)来储存Latin和ASCII码点。不过，它还有一种“接下一
个字节”机制，以便在必要时(有可能用来表示中文字符)可以使用2个
字节甚或4个字节。对于西方国家的程序员，这就意味着UTF-8既高效
又灵活，UTF-8之所以成为交换Unicode文本事实上的标准编码，原因正
在于此。
总之，不存在所谓单一的Unicode编码系统或方法，而是有好几种编码
方法；打算跟别人交换文本时，你需要明确指定自己采用了哪种编码方
法。
比如，是不是这样：
或者这样：
或者其他编码方法。
这又回到我前面提过的话题。为什么要用Unicode来编码？
前文提到：
首先，我们从一条信息即消息说起，消息以人类可以理解、易懂的表
示存在。
其次，(原因稍候再述)我们需要能将明文表示的消息转成另外某种
表示(不妨称之为“编码文本”)，我们还需要能将编码文本转回成明
文。从明文到编码文本的转换称为“编码”，从编码文本又转回成明文
则为“解码”。
好的。现在是时候探讨这些原因了。为什么我们会想着将明文表示的消
息转换成另一种表示呢？
一个原因当然是我们想要保密。我们想通过加密(encrypting)和解密
(decrypting)来隐藏消息的明文，基本上编码和解码的算法要求保密
和不扩散。
不过，这是个截然不同的主题。眼下，我们对保密不感兴趣；身为
Python程序员，我们感兴趣的是Unicode。因此：
身为Python程序员，为什么我会需要能将明文消息转换成某种编码表
示……比如UTF-8之类的Unicode表示？
假定你正舒舒服服地坐在电脑前，用你最喜欢的文本编辑器，用
Python(特别是用Python 3+)编写标准的Hello World程序。你的整个程
序只有下面这一行代码。
print(Hello, world!)
这里的“Hello, world!”就是明文。你在屏幕上看得见它。你可以阅读，明白它的含义。它就是一字符串，你可以对它执行字符串类型的标准操
作，比如截取一个子串(切片)。
不过现在假定你准备将这个字符串“Hello, world!”放到一个文件中，并
将该文件保存到硬盘上。也许你打算将这个文件发送给朋友。
这意味着你必须将那可怜瘦小的字符串逐出Python程序中温暖、和睦、安全的家，那里它就以明文字符的形式存在。你必须把它推入文件系统
那阴冷、没有人情味的外部世界。那里它不会以字符的形式存在，只有
1和0，一堆杂乱的点点滴滴，充电和未充电的微粒。而这意味着原本幸
福瘦小的明文字符串必须以1和0的某种特定配置来表示，这样一来，有
人想要获取那组1和0，将它转换回可读的明文，完全可以办到。
将明文转换成1和0的特定配置的过程就是编码的过程。为了将字符串写
入文件中，你必须采用某种编码系统(比如UTF-8)对字符串进行编
码。要从文件中取回字符串，你又必须读入文件，对这组1和0进行解
码，转回成明文。
从文件读写字符串时需要对它进行编码和解码并不是新鲜事，这不是
Python 3对Unicode的新支持引入的额外负担。其实你一直在做这件事。
不过就是不怎么明显而已。较早版本的Python采用ASCII编码方案。因
为在那些久远的年代，也只有ASCII这种编码方案，你不需要指定自己
想要读写ASCII编码的文件。Python直接假定文件默认就采用ASCII，自
动进行编码和界面。但是，无论你是否意识到这点，无论何时，只要你
的程序从文件读写字符串，Python都会在幕后忙碌，为你完成编码和解
码工作。
综上，这就是为什么身为Python程序员的你需要能将文本编码成UTF-
8(或其他某种编码：UTF-16、ASCII等)，或将UTF-8转回到文本。你
需要将字符串编码成一组1和0，这样才能将这些1和0放进文件，然后将
文件发送给其他人。
什么是明文？
前面提到编码解码过程有三点需要注意，我探讨了前面两点。下面是
第三点。
明文和编码文本之间的差别是相对的，且依赖语境。
作为程序员，我们会把书面文本当作明文。但也要从其他角度分析事
物。例如，我们可以把口头文本看作明文，而书面文本看作编码文本。
从这个角度来看，书面语是编码过的口语。世界上有很多种不同的编
码，将口语编码成书面语。举例来说，有古埃及象形文字、玛雅象形文
字、拉丁字母、希腊字母、阿拉伯文、中国的表意文字，还有非常平滑
的天城文(Devanagari)，即使是简写体也呈锋利尖锐的楔形。这些都是口语词的书写编码。正如英国政治哲学家托马斯·霍布斯(Thomas
Hobbes)所言，它们都是“我们也许赖以记住我们思想的记号”。
这又提醒我们，在不同的语境中，即使言语本身——语言——也可能被
看作是一种编码形式。在大部分早期现代哲学中(想想霍布斯和洛
克)，言语(或语言)基本上被认为是思想和理念的编码。当我将我的
想法编码成语言说出口并对你说的时候，沟通就发生了。你听到我言语
的声音，将其解码成想法。当我经由语言成功地将自己心里的想法传递
到你心里的时候，我们的沟通也就成功了。由于我的言语，你心里的想
法跟我心里的达成一致时，你便理解了我。(参看Ian Hacking的Why
Does Language Matter to Philosophy?)
最后，注意在其他语境中，“明文”甚至不是文本。明文是声波的(比如
音乐)，可以编码成mp3文件。明文是图像的，可以编码为gif、png或
jpg文件。明文是电影的，可以编码成wmv文件。不一而足。
编码和解码无所不在。
英文原文：The bytesstr dichotomy in Python 3
Unicode for dummies — Encoding如何构造团队Python开发环境
作者 BePROUD公司资深工程师
BePROUD是一家专注于Python开发的公司，因云集了众多行业精英
而闻名于日本国内。
译者 盛荣
曾就职于爱立信中国，长期从事通信、IT设备的研发、测试等相关工
作。喜爱脚本语言，特别是Python。希望将Python等脚本语言更好地
应用于自动化测试等领域之中。
在个人开发环境中，可以根据自己的喜好进行源代码管理，一些想法以
及信息也可以自行记录。
那么由多人共同开发一个项目又是怎样的情形呢？首先，开发的成果需
要在团队成员中共享。其次，测试开发成果的测试环境也需要统一建
立。接着，开发的方法与信息也要在团队成员中共享。可见团队成员之
间的沟通必不可少。那么，如何使团队开发高效进行？如何构建团队开发环境？本文就这些
问题的相关方法和有用的工具进行介绍。
在公共服务器上建立用户·设置权限
首先，我们介绍一下在团队公共服务器上建立用户并设置权限的操作步
骤。
用户与用户组的建立
建立开发团队的用户和用户组。在开发时使用的服务器上运行着各种各
样的应用程序，如果都使用root用户的话，在安全性上会存在很大隐
患，我们也不期望那样。在公共服务器上，建议使用普通用户权限运行
开发程序。
首先建立一个开发用户组。然后如下所示，采用root权限和groupadd命
令，建立名为dev的用户组。
sudo groupadd dev
接着建立用户。使用adduser命令，创建bpbook用户组，并在命令行中
使用--ingroup选项将其添加到之前建立的dev用户组中。
sudo adduser bpbook --ingroup dev
这样一来就在系统中建立了一个名为bpbook的用户。如果要删除用
户，可以直接使用userdel命令进行删除。
sudo userdel –r bpbook
Sudoers
普通用户有时会需要使用超级用户(root)的权限去执行一些命令。这
时可以通过etcsudoers文件中的设定给予普通用户执行特定root命令的
权限。接下来，我们通过编辑该文件，赋予之前建立的bpbook用户一定
的权限。编辑sudoer文件需要执行visudo命令。
sudo visudo上面命令执行后，将会打开etcsudoers文件。下面是通过etcsudoers文
件赋予bpbook用户权限的一段样例：
%dev ALL=(ALL) ALL
bpbook ALL=(ALL) ALL
上面的设定含义就是赋予dev用户组以及下面的用户bpbook使用sudo命
令的权限。第一行是赋予用户组，第二行是赋予用户权限，连在一起表
示赋予二者可以执行root权限的所有命令。
sudoers文件的权限配置格式如下所示：
%用户组名 主机名=(权限)命令
用户名 主机名=(权限)命令
virtualenv
当多数人共同开发项目时，不能因为某个组员添加了某个库或者变更某
个版本，而影响整个团队的开发环境。在使用Python开发时，推荐使用
virtualenv。因为使用了virtualenv，能使开发环境的变更(如安装新的库
或者版本升级)仅仅对行为者本身的开发环境有效。因此，我们必须有
效使用virtualenv构建多人开发环境。
任务管理系统
为推进团队开发的顺利进行，首要任务就是能够准确把握每个开发任务
的负责人及其开发进度的状况信息，并加以梳理。在这里，管理任务就
需要用到任务管理系统(Issue Tracking System :ITS)。
ITS是在开发过程中创建任务、追踪状态、管理任务的系统。Trac和
Redmine是以ticket为单位进行任务管理的系统。使用ITS时，不仅可以
管理任务，还经常作为创建ticket信息并录入工作任务的入口。
ITS中会根据不同情况给创建的ticket分配不同的状态(如新建、进行
中、解决、已验证、关闭、保留等)、给予不同的优先级属性(紧急、高、普通、低)、维护责任人信息、列出完成期限，还可以查询上述所
有信息。因此，对于整个项目状况的把握是非常有利的。同时，将开发进行任务分割，通过ticket的形式分配给项目组成员，这
也是一种项目开发的手段，称作ticket驱动开发。由于同Agile开发有着
很好的匹配关系，因此我们也将其投入到最近的开发中进行使用。
版本管理系统
在团队开发的过程中，需要有一个地方集中管理每位成员开发的代码成
果。另外，随着开发的不断推进，也会产生各种各样的BUG，在这个时
候，为了了解BUG是在什么时候混进来的，需要能对开发的代码进行历
史追踪。
于此，版本控制管理系统(Version Control System：VCS)就能发挥作
用了。版本管理系统，如其名字所示，是管理源代码及其变更历史的系
统。VCS主要代表Subversion这样集中型的管理工具，和Mercurial、Git
这样的分布式版本管理工具。本文使用的是Mercurial。
Mercurial与Trac联动绑定
将ITS与VCS进行系统绑定，就可以使得项目中ticket和源代码变更过程
更加清晰。本节对Mercurial和Trac的系统绑定方法进行说明。Trac与
Mercurial进行系统绑定需要安装Trac的mercurial-plugin插件。而
mercurial-plugin插件由Subversion进行管理，所以首先需要安装
Subversion。
sudo aptitude install subversion
Subversion安装完毕之后，就可以下载Trac的mercurial-plugin插件了1 。
1 其实这是svn checkout的命令，而不是单纯意义的下载。——译者注
svn co http:svn.edgewall.comrepostracplugins0.12mercurial-plugin
下载完成后就可以安装该插件了。
cd mercurial-plugin
python setup.py install
mercurial-plugin插件安装完成之后，需要通过编辑trac.ini文件2绑定Mercurial和Trac。首先，添加使mercurial-plugin插件生效的componentes
段，如下所示：
[components]
tracext.hg. = enabled
2 该文件是在trac建立的工程conf目录下，如homeeronshebpbookconf。——译者注
接着指定代码库的类型和代码库的目录。在trac段中的repository_type指
定表示Mercurial的hg，在repository_dir中指定代码库的路径(本例中
是varhgbpbook)
[trac]
repository_type = hg
repository_dir = varhgbpbook
经过以上设定，就可以使Trac与Mercurial绑定，Mercurial中的更新日志
也会反应在Trac中。
小结
本文介绍了团队开发的环境构建，给出了公共服务器上的用户与用户组
建立并设置权限的操作流程，以及ITS、VCS等在团队开发中适用的各
种工具。
灵活运用Mercurial、Trac这类工具，使开发成果可以在团队成员中共
享，这将会大大推进团队开发的效率。另一方面，Skype、DropBox、Google Docs等工具的使用，又可以建立通过网络进行沟通并共享开发
信息与数据的桥梁，使得开发可以随时随地进行，大幅降低了差旅和通
信的成本。
团队开发中复杂的情形有很多。只有灵活运用各种工具，提高效率，才
能取得一定成果。使用各类工具提高开发效率无疑是一种乐趣，大家也
可以尝试将本文介绍的工具投入到各自的团队开发项目中使用一下哦。
《Python开发实战》来自于真正的开发现场，由BePROUD公司的资深
员工执笔，凝结了老牌程序员在日常工作中积累的开发经验，是一本难
得的好书。本文选自《Python开发实战》人物罗晨：梦想照进现实，一个独立开发者的田园诗他种有机蔬菜、他搞全景摄影、他自己设计制作硬件产品，他还是个
程序员，并以此为生。罗晨，他是Markdown编辑器Mou的作者，他
就是一位生活在农场上的独立开发者。提起我们这个时代的码农们，人们联想到最多的是“加班”、”赶进度“、“不健康的生活方式”……好
像这些是和编程密不可分的衍生品。然而，在罗晨身上我们看到另外
一种可能性，我们可以，活出自己想要的现实
MouStand——让梦想变成现实
我十分喜欢 Mou 的 logo，这个形状是想象出来的，之前它在现实中
并不存在。但是我把它变成了现实。
为什么要自己做一个 Markdown 编辑器?
我刚开始知道 Markdown 这个语言，就觉得挺有意思，想找一个
Markdown 的编辑器。当时有两个收费的编辑器。其中一个中文支持不
太好，老跳，一打中文的时候那个键上下跳。另外一个预览界面和编辑界面是分开的。要想预览就得点一下预览的命令，不能同时显示。我想
要左边编辑右边预览，这样就可以实时预览，一边编辑，一边显示的，可是没有。那没办法，市面上没有只能自己做。然后我就做了。
Mou 的同步滚动还不精确。因为我这个是按照左右两个窗口的长度，百
分比来算。同步比较难做。如果要精确匹配只能按元素。比如左边是二
级标题，第一个二级标题对右边的二级标题，这样来算定位才准。但是
我现在还不知道怎么做。
你很喜欢这个 Mou 的这个 logo?
是的，Mou 现在的 logo 是方迟设计的，我非常喜欢。第一个版本的
logo 是我画的，但画的不好。后来在丁一的介绍下能够有幸请到方迟为
Mou 重新设计 logo。我当时的要求就是简洁，突出 M。我觉得他设计
的非常棒，这种造型是方迟想象出来的，之前现实中并没有这种形状的
物体。我非常喜欢这个造型，以至于我想把它变成实物。但设计 logo
和把它变成实物是两码事。当初设计 logo 的时候并没有考虑到要做成
实物。
Mou 最初(第一个公开测试版 Mou 0.6.0)的 logo，2011 年 9 月，罗晨
设计：
Mou 0.6.4 的 logo，2011 年 10 月，方迟设计：Mou 0.7.2 的 logo，2012 年 8 月，方迟设计改进，沿用至今：
既然关于 MouStand 这个实物所有的一切都是你自己设计的，那就从包
装讲起吧。
包装我考虑过纸盒，但是不太结实。瓦楞纸是柔性的，柔性的一压就压
坏了，怎么办？现在快递都比较暴力，所以我们需要刚性的包装。这个
木制包装盒是指接结构。它有一个优点就是稳固、特别结实，可以保证
长途的运输当中里面的东西不受损害。材料当然是越轻越好，轻点可以
省邮费，但是不能太轻，因为还要考虑到强度。当时我就考虑两种材
料，一种是桐木，非常轻。第二种是松木。但是桐木要是这个厚度不结
实。一踩上去就碎了。松木的踩上去没什么问题。
发货的时候木盒的外面还要套一个瓦楞纸箱的，刚柔并济，多一层保
护。你看上盖只采用这两根木条，而这边没有。这是为什么呢？这个刚好可
以扣住，如果这边再加两根木条，就扣不住了，会顶住 MouStand 上边
这两个腿，就需要把这个盒子再高一点，那样就浪费材料了。考虑到强
度、也考虑到节省材料。尺寸都是匹配的，为的是最大限度的节省材
料。
包装上的标签也是我自己设计。我的风格是属于简洁素雅的风格。大面
积留白，上面一条是黑底白字，其余是白底黑字。盖子里面的标签注明
它的详细规格。每个 MouStand 重 36 克(一个 Color Packs 套装包含 4个 MouStand，木盒重 200 克。但是有误差，误差我故意写的大一些。
比如木头里面有水分，水干了之后会变轻，湿度大还有可能变重。
这些东西加起来，再加外面套一个纸箱超不过 500 克。为什么 500 克？
因为发货我采用邮政，EMS 是按 500 克来算，500 克以内是一个价格，501 克又加钱就不划算了，所以保证 500 克以内。
再说说产品本身。
我去年用银子，锤子凿出来一个比这个小的形状。用银子敲成银丝。再
折一下。也是用锤子敲一下，折三次成这样，比这个小。
去年(2012 年 7 月)用银子凿出来的 Mou 的 logo：
再回到 MouStand，开始时，我想做 logo 那种颜色，但是调不出来。这
个加工步骤是这样的，先把一块平面的铝板切割成平面形状，切割好以
后，再把边角进行手工打磨，因为机器打磨好之后有毛刺。打磨好之
后，第二步进行折弯，把平面的图形折三次，然后就成形了。变成一个
基本的形状之后，在进行喷砂处理，使表面形成一种喷砂的效果。说白
了这个喷砂就是用喷枪喷细砂。用细砂粒撞击它的表面，撞出无数的小
坑，就形成了喷砂效果。喷砂的功效一个是美观。另外，折弯了之会有压痕(折弯痕)，喷砂可以把痕迹减弱。这还有第四步，阳极氧化处
理。喷完砂之后表面都是铝，进行阳极氧化，使表面生成一层三氧化二
铝。三氧化二铝很硬，莫氏硬度达到8。像蓝宝石、红宝石、磨刀石主
要成分都是三氧化二铝。氧化成三氧化二铝是对它表面进行一种保护。
现在的效果就很硬，不容易划伤。也比较光滑。
然后再进行染色。你看到的这个颜色实际上不是油漆，而是墨水。氧化
后，三氧化二铝的结构是透明的孔状结构，用墨水一染的话就渗透进
去。最后一步进行封孔，用开水煮，把颜料封在里面。(颜料)已经渗
透进去了，比油漆要好用。MacBook 表面也是这种工艺，只不过那种喷
砂喷得比较细。我们这个喷砂颗粒大一些。颗粒大是因为受到加工工艺
的限制，工艺达不到那么高。另外，折弯的时候，痕迹很明显，如果用
细砂喷痕迹非常明显，掩盖不掉，所以只能用中等颗粒的，刚好把折痕
掩盖掉。折的时候机器有两个尖一压，每个折弯处都有一条道，现在不
容易看出来，是用喷砂给处理掉了。这一块还有脚垫(绒布贴)，对下
面进行保护。
刚才问到后面的孔是干什么的？最后的阳极氧化要把工件作为电极浸到
溶液里。这个是导电的，必须有个触点，所以在这开了个孔，让这个地
方一直导电。进到溶液里氧化，一通电，表面生成氧化膜。刚开始做样品的时候没有开这个孔，是在这两个位置(M上面的两个
尖)夹着的。夹着的时候表面出现夹痕，夹痕非常难看。所以正式生产
的时候就在后面开了个孔，让它把夹痕隐藏到里面，更美观一点。
MouStand 尺寸为什么这么定？
尺寸还有角度，要兼顾(iPhone 和 iPad)水平模式和垂直模式，都能
放。这个水平放置没问题，竖着放也没问题。两种模式都支持的情况
下，保证它体积最小，就找到这么一个平衡，再大了浪费。这个造型可
以两边放。这边放一个，比如两个人，你在这边玩手机，我在这边玩这
个。两个腿之间的间距也是考虑过的，如果间距再大点儿手机竖着放就
拖不住了，漏下去了。原型设计的时候，我是用纸做的，用的是一百五十克卡纸。承重没法
测，只是测角度，用 iPad 比划这把角度估计出来，看什么角度倒不
了。前面脚的长度，参考一下 iPhone、iPad 的厚度，长一点，这样就翻
不过去。
MouStand 的原型是用纸做的：
具体加工是怎么完成的?我是把设计图纸做好，然后加工工艺确定，再联系代工厂。这个木盒是
山东曹县代工。做了两百个，还是好说歹说人家才给做。这个属于限量
生产，不像人家大工厂批量生产，那样成本非常低。铝合金加工是在广
州。标签还有木头玩具的纸盒是我自己买的打印纸，打印机、切纸机，完全是自己做。木头玩具纸盒上的图形和图解是我用 Silo 建模软件建出模型，截图后再
导入 Illustrator 里描出来线框图，包装也是我自己做的。这个是三根木
条。这是附赠的玩具。这个玩具是现有的，我只不过弄了一个包装。这
个玩具叫孔明锁，据说在孔明的时候就有了。
木头玩具包装盒上的图形是先用 Silo 建模，再用 Illustrator 描出来的：这个贴纸也是我自己做的。想贴哪就贴在哪。你把后面的那层纸撕下
来。这个像 GitHub 学习，GitHub 不是也是有一个 shop，也卖贴纸的、卖杯子，它也是以它的 logo 发展的周边产品，我这也是以 logo 发展的
周边产品。你的网站做的挺好看的，简洁漂亮。
就是几张截图往上一堆。刚开始学摄影的时候学过 Photoshop，这都是
之前积累的基础，这些知识全用上。做 MouStand 网店，要摄影，把产
品拍下来，怎么拍好看，弄个摄影小棚子，布好灯光、角度、支架弄
好，拍好，再调调亮度。把照片弄的好一点。拍照片大概弄了两天。
你定价是怎么定的？卖了多少了？
价格就是成本加上跑腿的路费，从我住的农场到邮局来回骑自行车要
20 公里。这个我定的是每一个二十九刀。按这个价格来算。参考了一
下国外市场 iPad 支架的价格。一般三十刀，我的是二十九刀。只不过
我们是四个一起卖，两个一起卖，就显得比较贵。其实一个拿出来，二
十九刀，在国外来说是很正常的一个价格。但是木盒只有两百个，太多
了木盒太占地方，家里也放不下。
彩色一百套，黑白的一百套，一共两百套。现在卖了二三十套。都卖了
也挣不了多少钱。主要是自己做着玩，有这个乐趣。我面向的客户主要
是国外的，国内的少。要是弄个淘宝店铺，我感觉有点麻烦。国内目前
卖了八套。
以后还想继续做实物硬件吗？
不想再做实物的东西，麻烦。因为做一套东西考虑的东西太多了，方方
面面都要考虑。还要存货还要发货。做软件多省事。玩过去就过了。玩
过就不好玩了。
误入歧途才能发现桃花源
我想做点工具，为我以后前端工程师的职业做好铺垫，但是写到最后
发现写软件已经有收入了，可以不找工作了。
你在哪上的大学？
我大学上的太原科技大学。我是 2005 开始， 2009 年毕业的。当时学的
是通信工程，我以为自己会感兴趣，其实没有。现在这个专业毕业的有一半都不是做本专业工作的。有的人做通信搞信号基站，要不就是楼道
里面安个无线网。我觉得不好玩，所以后来就玩起了全景摄影。
我在你的网站上能看见一个叫 86vt 的网页，里面有你们大学的地图和
很多地点的全景照片，感觉就像自己在校园里面行走一样。
86vt 是我做的我们学校的(全景摄影)虚拟校园网站。我考大学之前，看这个学校网站挺烂的，只有两三张图片，觉得很破。入了学以后觉得
还挺漂亮的，是学校网站没有体现出来，后来我就想用一种方法把学校
风格体现出来。我们学校虚拟校园 86vt 是上学的时候完成的一个项
目。
这个项目实际上一个月就做完了。但是前期准备学知识学的时间比较
长。我 2007 年开始学全景摄影方面的知识，学完之后 2008 年 4 月份才
开始做这个项目。这里面有三十多个场景。拍的时候都要选人少的时
候，人多了图片拼接的比较难处理，全景不是拍一张就完了，是拍很多
张拼起来才能形成一张。如果你是走动的，在这拍了一张，又跑到那了，那张拍上你了，那就半截半截的。
这个全景摄影具体怎么拍？
我用的 8 毫米鱼眼镜头，云台、三脚架。云台就是保证旋转的节点精
确，没有视差，才好拼接。云台上面有刻度。现在好一点儿的云台都是
带锁的。比如 90 度一个锁，这么一转响一下，九十度到了，非常方
便。现在我要拍那样一幅照片的话只要半分钟左右。需要拍四张，九十
度拍一张就行。拍完之后回去拼接。比较细的处理一个拼接照片要一个
小时。要是做个大概，几分钟就好了。
你从什么时候开始写代码的？
在学校的时候搞摄影，要把照片放在网上，然后开始研究网络相关的知
识。网页、空间、域名。因为刚开始想把照片放到网上，才接触到互联
网知识(技术方面)。如果我不摄影，可能我就接触不到互联网(技术
方面)。
有个学长(舒文亮)，比我大一级，还没毕业就在雅虎上班了。我们觉
得他很厉害。我做这个 86vt 网站的时候，也向他请教了不少问题，那
个时候他就是我的偶像。他当时已经是前端工程师了，也是转了好几
圈，然后又回到前端，他现在在阿里巴巴带团队。我当时就想，我也想
像他那样厉害，我也要学这个，我也要当前端工程师!实际上在大学我
对互联网还不怎么了解，毕业以后想找这么一个工作怎么办？那就学
呗。学只能在家学，等什么时候把前端工程师相关的知识学完之后，再
找个前端的工作做。所以毕了业之后要选择找工作还是回家待着，我就
想回家待着，家里也支持，在家就在家吧，也不指着我工作。
然后你就在家学习前端知识？
毕业后回到家先开始学的 HTML，CSS 和 JavaScript。学了几个月后做
出了 resizeMyBrowser，接着又在 resizeMyBrowser 的基础上做了个
Safari 浏览器插件 Resize。
之后又了解到前端优化方面的知识，通过压缩 CSS，JavaScript 等文件
能够提高页面初次下载速度，我就想找个好用的压缩工具，当时都是命令行的，就是在 Mac 平台都是命令行的工具。我觉得太麻烦，想要一
个图形界面，但是市面上没有。没办法只能选择自己做。从那个时候开
始学 Objective-C，想着做一个 YUI Compressor 的图形界面，方便批压
缩 CSS、JS 文件。于是做了我的第一个 Mac 应用 Smaller。
再后来了解到 Markdown，又写了 Mou。
其实我做的这些个工具基本上都是跟前端工程师这个职业相关的。实际
上作为一个前端工程师需要做这些工作，用这些工具可以提高我的工作
效率，我想做点这些工具，为我以后前端工程师的职业做好铺垫。工作
的时候效率会高一点。
可是写到最后发现写软件已经有收入了，找前端工程师的工作不是必要
的了。我是从摄影转到学 Web 的知识，想成为 Web 前端工程师，却在
学习 Web 前端方面知识的过程中不知不觉的转成了开发软件。上次在
QCon 认识个一淘的朋友(葛灿辉)，他说我更像一个产品经理，不像
程序员。
你现在应该可以找到前端的工作了吧。
其实已经有很多公司找过我了，Mac 软件开发方面的居多，Web 前端也
有。有一个德国的公司 Wunderlist，邀我去做 Objective-C 开发。但是我
家人都在这，出国太麻烦了。阿里的 Mac 开发团队邀请过我两次，只是第一次的时候还没有去工作的打算，第二次的时候我正打算做硬件，做这个支架，也抽不开身。现在也暂时还没有去公司工作的打算，在家
自由惯了，去公司会不太习惯吧。还有腾讯也邀请过，做前端工程师。
他们说我网站设计的好，其实我觉得做的很简单，就是几张截图而已。
你能有这样的思路，做出现在这些产品和你有充足的闲暇时间有关系
吧？
肯定有关系。我在软件开发前期的时候非常苦恼。有时候一个问题连着
一两个星期没有思路，就整天在那想，睡觉的时候还想，一天到晚不停
地想，那才能想出来。可能在公司没有那么多的时间想了。
我做的很多东西都是以玩为主。可能跟小时候经常拆东西有关。我父母
给我比较大的自由。上学学习方面不会逼着我。但是我自己知道学。考
高中、大学，报志愿的时候他们也不会干涉，都是我自己决定。他们相
信我。
你现在生活在农场上吗？在家都干些什么？
在家比较闲，闲着没事。软件开发前期比较忙，后期就是维护了。维护
每天回回邮件，客户支持。实在闲着没事了做做新功能，不像前期那么
紧。
我家在天津汉沽区附近的汉沽农场，那个地方属于河北，是河北省在天
津的飞地。说是农场，实际上就是很多农村连在一块。这块地是在天津
市境内，但是属于河北省管。
我现在每天早上就在园子后面浇浇地，种种菜。就在我家房后面那么一
块。我种了十颗人参就活了五颗。还种了一颗蓝莓树，蓝莓属于灌木，很矮，就像周围马路边的灌木，上面结小小的蓝莓果。我都是在淘宝上
买的种子。我经常会给葱们，还有蓝莓喷点儿水，不打药，纯天然绿色
食品。闲的没事儿我会打打沙袋，锻炼身体。邮局离我家10公里，每次骑车去
邮局发货(Moustand)往返就要两个小时。途中，会经过乡间小路，天
气好的时候，景色还是不错的。你以后有什么打算？
在家待着腻了，再去工作，找份工作，体验一下上班的感觉，我还没上
过班呢，不知道上班什么感觉。读《码农》 吐吐槽 还能赚银子!活动规则：在吐槽贴中留言，选出任何一期中你最喜欢的文章和最不喜
欢的文章，即可获得图灵社区银子 2 两!凡吐槽吐得掷地有声者，加赠
银子 3 两(共 5 两)!(怎样使用银子兑换图书)
活动时间：本活动长期有效。践行如何教编程，当你面对一双渴望的眼睛
作者 Philip Guo
斯坦福大学计算机科学博士。研究领域主要涉及人机交互、在线教
育、软件工程等。他在2010年自己构建了一个基于自由网络的编程学
习工具叫做Online Python Tutor(pythontutor.com)，目前已有超过20万
人使用了这个工具。
过去的一年中，许多计算机专业的教授和教育专家都写了关于 MOOC如何扩大计算机教育服务的规模，使得成千上万的学生都能享受到。而
我想从另外一个角度，说一说我是如何在9个月的时间里向1位学生教授
计算机编程的。
2011年7月到2012年3月之间，我给Brian Goler教授基本的编程知识；他
是旧金山湾区一位有经验的企业家，在市场、销售和产品开发等方面都
有广泛的经验。Brian之前没有编程经验，但在几个月的时间里，他就
做出了SwearBuy，一个让人们对喜爱的产品发表评论的免费 web应用程
序。更重要的是，Brian获得了自学的能力，能够接下来自己搜寻、学
习更高阶的技术内容。我的主要贡献，是指导他克服一些通常会打击初
学者的障碍。
背景
Brian通过我的个人网站上知道了我，因为里边有几篇计算机科学教育
的文章。下面摘录他在 2011年7月给我发的第一封邮件里的一段内容：
我们没见过面，但我想试试看能否从您这儿得到些建议。
我在网上搜寻能帮我学习编程的导师的时候发现了你的网站。更准确
地说，我在上一门计算机课程，我希望找一个导师，每周能当面辅导
我1-2 次，每次1小时左右。
我正在上MIT的OCW6.00课程。尽管OCW和其他的在线课程都很
棒，但我觉得如果有个人可以请教、还能检查我的作业，并给与反
馈，那我的进度应该会更快些，对概念的理解也会更深入。
您在MIT和Stanford都待过，应该认识一些合适的人吧？或者，可以
给我推荐下去哪儿找合适的人？当然，我会向辅导的人付钱的。
因为那会儿我刚好不忙，于是我就亲自辅导Brian。我们第一次的一小
时会面是在他家，第二次是在附近的一家咖啡馆。之后我去参加某个学
术会议，于是第三次的辅导我们就通过Skype在线视频电话进行。我们
用了Skype的屏幕共享功能，这样在聊天的时候我就能同时看到他的电
脑屏幕。这种形式非常适合辅导，于是我们决定接下来的所有辅导都通
过Skype进行。我只当面辅导过Brian两次，而我们的Skype视频通话时
长高达 50 小时(大约 40 次)。在Skype上的在线辅导进行的如此顺畅，我们都感到很惊喜。这甚至比
我们当面聊天更有效，那样还会受困于嘈杂的咖啡厅和狭小的笔记本电
脑屏幕。借助Skype的屏幕共享功能，我能在我自己的公寓里边舒服地
看到Brian的电脑屏幕，并且与他实时互动。如果我需要画些草图来说
明，那我只需要共享屏幕，然后用绘图板来画就行了。(Salman Khan
就是用类似的办法教他的表弟，于是就有了现在知名的可汗学院教育视
频。)
基于项目的学习
Brian的目标是学习基本的编程技巧，提高自己；而不是要获得一份程
序员的工作，或是成为一名研究人员。在见我之前，Brian已经通过上
MIT开放课程中的“计算机科学与编程基础”，自学了几周 Python 编程。
开始的几次辅导中，我们通过课程讲义和作业，复习了基本的编程概
念。
然而，我很快就意识到，仅仅通过学院式的课程资料来学习，无法让
Brian 足够投入，尤其考虑到他已经大学毕业20年这个现实。他看起来
并不满足于只学习一些计算机学科的术语、做一些针对大学生的数学相
关的小练习。
因此，我决定教Brian成为一个实用主义的业余程序员，而不是一个饱
学的计算机科学专家。我鼓励他想出一个给自己或朋友用、自己也愿意
做的软件。相应地，我将指导他完成这个软件项目。这个想法如此简
单，但效果却异常好。
Brian提出了一些idea，并最终决定实现其中的一个，也就是后来的
SwearBuy。在接下来的9个月里，他每周都投入十几个小时的时间编写
SwearBuy，常常干到深夜。我们每周都有一到两次的Skype辅导，每次
持续一到两个小时。辅导中的大部分时间，我都用来回答Brian的问
题，帮他调试bug，有时还跟他结对编程，一起写点儿代码。我每次讲
的时间都只有几分钟。除了能让他的注意力高度集中外，这种基于问答
的形式对我来说也很不错，因为我几乎不必花时间提前做什么准备。
基于项目的学习十分高效，因为Brian十分重视他自己的第一个项目。
他的学习被需求牵着走，而不是一些预先设置好的的学术课程。因为他
对Swearbuy的热情非常高，所以常常会想出很多新功能的点子。为了实现这些功能，他必然要学习一些新的编程技术。因此，我的角色就变成
了：
评估他想实现的功能的可行性，如果需要的话，指导他完成一个简
单版本；
挑选最适合他需要的编程工具、风格以及技巧；
给他找到合适的自学资料(比如代码示例、博客、在线教程、书
等)；
在他努力理解和应用自学的内容时，回答他的疑问。
编程实现一个任务，常常有几十种甚至上百种方式；这种选择的多样
性常常让初学者手足无措。因为选择太多，他们反而不知从何入手。
我要做的，主要就是帮他将选择范围缩小到一个可控的范畴，适合他各
个阶段的学习；然后让他去自学，遇到问题时我再解答他的疑问。
我十多年的编程和教授编程的经验，使得我在每个需要选择的点上，都
能将选择范围缩小到我认为最适合Brian学习的程度。比如，我选择让
他用最基本的编程语言(比如 Python，JavaScript，SQL)功能来“从
头”搭建 SwearBuy，而不是在已有的一些复杂的 web 应用开发框架上开
始。尽管为此 Brian 不得不写更多的代码来“从头”(这个词儿可能有些
不准确，因为不可能完全从零开始)开始实现期望的功能，但他通过这
个过程，能够深入到内部原理，深入理解各个部分是如何组合到一起
的。
Brian的项目是我们Skype会话的绝好的基础，因为我能将自己要教授的
新概念融入到他想实现的新功能中去。哪怕更多的课后练习所发挥的作
用，也比不上一个属于学生自己的的应用程序。
在挣扎中学习
在我们每次1-2小时的Skype辅导开始前，Brian通常会编程10-15个小
时，所以他总是用大量急切的问题要问，有很多新写的代码需要我帮他
来调试和优化。如果我只是给他讲课，而不基于任何背景，那他不可能
消化的这么彻底，很可能只是点点头，然后说“嗯，好吧，好像是这么
回事儿……不错，然后呢？”相反，因为他在每次辅导之前，都一直在
和具体的代码相关的问题纠缠——甚至经常因此而受挫和沮丧——所以
每当我给他解释清楚了什么之前看起来好像不可逾越的问题时，他的反应往往是“哇哦!现在我算是彻底明白了!”。他的喜悦和释然每次都那
么明显。我觉得对消化知识来说，没有比这更好的方式了：先花上几
个小时努力解决问题，不断积累心中烦躁的情绪，然后再接受导师的
指导。
为了减少Brian的痛苦，我帮他搭建了开发环境，做了一些乏味的工
作，因为这些东西不会直接促进他的学习。我希望他把精力花费在编程
和搭SwearBuy上，而不要浪费时间做些不相关的事情，比如搭建服务器
或是版本控制系统。(当然了，如果他的目标是成为一个系统管理员，那我尽可以让他去纠结那些细节。)
有很多时髦的书、在线教程以及直播节目，都宣称能让你在7天或是3周
时间里学会编程(或者别的什么技能)。很明显，你不可能在几周里就
掌握一门新技能，而且我觉得也没几个人真的相信。这些“快速获取技
能”计划的真正问题在于，他们忽视了可持续性。这些课程就好像减肥
食谱一样，可能会让你马上减掉 10 磅体重，但却无法让你保持住，除
非你真正地养成了好的习惯。类似的，除非你不断努力很多年，否则也
无法精通编程；为了激励自己不断努力，你必须是在做自己有热情的事
情。努力挣扎可不是什么有趣的事儿，如果没有适当的激励，太容易早
早地放弃了。
当Brian意识到他不再需要我的辅导时，我知道我成功了。尽管他也承
认要成为一名技艺精湛的程序员，自己还需要努力好几年，但他已经知
道在现有的水平下，如何努力才能到达那个高度。在过去的九个月里，他学到了足够多的东西，能够支持他继续自学下去。我给了他足够的方
法和智慧来继续自学，而不是填鸭式地应付一个学生，我感到很自豪。
最后的思考
在我们的辅导结束之后，Brian反映说，尽管他受益于这种“通过做来学
习”的方法，但他仍然认为，将基于项目的学习和传统的计算机课程学
习结合起来，有很大的价值。在构建SwearBuy的过程中，他经常通过
Google、阅读技术博客、从StackOverflow上拷贝代码等方式，来临时解
决自己的问题。结果，他发现自己经常得出并非最优的方案，而且用的
东西自己都无法完全理解。Brian的一些巨大的进步，来自于他从项目
中抽身出来，转而去看书或听课时学到的新的概念，然后想着如何将其
用到SwearBuy中。自从我们2012年3月结束最后一次的辅导以来，我6个月没有收到Brian
的消息了。最近他给我发的电子邮件中提到，他刚刚写了个Python脚
本，帮自己给个人股票投资建立模型：“对这个脚本我感到很自豪，因
为这是我做的第一个实用的自用工具。我过去一直都在评估股票投资项
目，一直想模拟各种场景；一开始我用的是Excel，但后来终于发现
Python才是做这件事儿的不二之选。”
我很喜欢这封邮件，因为它展示了编程技能的作用，让原本无聊且困难
的任务能够轻松完成。我希望每个学习编程的人都能有迈过那道坎儿的
时刻，从那以后就不仅是为学校或公司的活儿而编程，而更多的是为自
己而编程。
我还想说一遍那句老话，积极性意味着一切。Brian的积极性来自自己
的项目，所以实际上他是自学的。我要做的仅仅是定期指导一下他，帮
他最有效地进步，让他的努力变为有效的学习。
我的这些经验如何才能推广到教授大批的自我激励的程度远不及Brian
的学生的教学实践中去？我摸索出的这些技巧如何能不再局限于一对一
的辅导这种形式？我也不知道。我只知道，如果你能让学生产生真正的
积极性，帮他们移除学习中一些不必要的障碍，而且在适当的时候拉他
们一把，那么实际上他们就完全可以自学。
英文原文：Teaching Programming To A Highly Motivated Beginner
译者 张重骐
北邮人。学过设计，技术在学；前产品设计师，现任开发工程师。热
爱美好，努力成为创造美好的人。图灵社区ID: zhongqi鲜阅未来的编程语言究竟是什么样？
作者 松本行弘
Ruby语言发明者，亦是亚洲首屈一指的编程语言发明者。现兼任网络
应用通信研究所(NaCl)研究员、乐天技术研究所研究员、Heroku首
席架构师等。昵称“Matz”。讨厌东京，喜欢温泉。
译者 周子恒
IT、编程爱好者，技术宅，初中时曾在NOI(国家信息学奥赛)天津
赛区获一等奖，大学毕业后曾任IT咨询顾问，精通英语和日语，译著
有《30天自制操作系统》、《大数据的冲击》、《Android应用开发
入门》。
从过去编程语言的历史中，我们可以看出编程语言是在不断试错的过程
中发展起来的。有很多编程语言已经消亡，仅仅在历史中留下了它们的
名字，但其中所包含的思想，却被后来的 语言以不同的形式吸取和借
鉴。
例如，SNOBOL 的字符串处理功能，可以说是现代脚本语言基本功能
的祖先。此外，20世 纪70年代由美国麻省理工学院(MIT)开发的一种
名为CLU
1的语言中迭代器(Iterator)的概念，也被Ruby以代码块
(Block)的形式继承了下来。
1 CLU 是由MIT的芭芭拉? 利斯科夫(Barbara Liskov，1939— )所开发的语言，利斯科夫于
2008 年获得图灵奖。(原书注)
从编程语言的进化过程来看，一个显著的关键词就是“抽象化”。抽象化就是提供一个抽象的概念，使用者即便不具备关于其内部详细情况的知
识，也能够对其进行运用。由于不必了解其内部的情况，因此也被称
为“黑箱化”。
一些古老的编程语言，例如BASIC 就没有实现充分的抽象化。虽然它提
供了用于过程共享的子程序这个概念，但是子程序只能通过编号来调
用，而且不能传递参数。由于“赋予名称”是抽象化的重要部分，所以说
它的抽象化是不充分的。近代的编程语言中，都可以为一系列过程(程
序)赋予相应的名称。
然而，仅仅将过程进行抽象化还远远不够。几乎所有的过程都需要进行
一定的输入输出操作，而并不是与数据无关的。因此，在下一个阶段
中，对数据进行黑箱化就显得非常重要。刚才我们提到的CLU，就是数
据抽象化出现早期的一种语言。
在数据抽象化的延长线上，就自然而然产生了面向对象编程的概念。所
谓对象，就是抽象化的数据本身，因此面向对象和数据抽象化之间仅仅
隔了薄薄的一张纸。在现在的21 世纪编程语言中，面向对象已经是常
识了，最近几乎所有的语言都或多或少地提供了面向对象的能力。 当
然，其中也有一些语言故意不提供对面向对象的支持2。
2 例如，下一节中将要介绍的由保罗 ? 格雷厄姆所设计的Arc 语言，就(至少在其内置功能中)
不支持面向对象，据保罗说，是有意这样设计的。(原书注)
随着抽象化的不断深入，程序员即便不去关心内部的详细情况，也可以
编写出程序。人类一次所能掌握的概念数量是有限的，有说法称，大部
分人一次只能驾驭7±2个左右的概念。这样一来，如果能够让问题的处
理方式更加抽象，也就可以解决更复杂的问题。
受摩尔定律的影响，社会对于软件也提出了越来越高的要求。人类社会
越来越依赖计算机，因此就需要开发出更多更可靠、更便宜的软件。
在讲述软件开发的一本名著《人月神话》中，作者弗雷德里克·布鲁克
斯写道：3 无论使用什么编程语言，生产一条基本语句所需要的工数几
乎是一定的。
3 《人月神话——软件项目管理之道》(The Mythical Man-Month: Essays on Software
Engineering)首次出版于1975年，并于1995 年进行了扩充和再版。弗雷德里克。布鲁克斯
(Frederick P. Brooks, Jr.，1931— )是美国的软件工程师，曾主持开发了IBM的OS360操作系统，于1999年获得图灵奖。
也就是说，如果要描述同样的算法，A语言需要1000行，B语言只需要
10行的话，只要采用B语言生产效率就可以提高100倍。
可能有人会觉得“这太扯了吧”。打个比方，用Java和Ruby描述同样的算
法，语句行数相差2倍多也不稀奇，如果是汇编语言和Ruby相比的话，也许能产生100倍甚至1000倍的差距。
能产生这样的生产效率差异，正是抽象化的力量。抽象度高的编程语言
不必描述详细过程，从而可以用简短的代码达到目的。和抽象化程度的
差异相比，变量名称、有没有指定数据类型之类的都只能算是误差级别
的差异而已。
100年后的编程语言
从编程语言的进化这个视角来看，其实最近并没有什么大的动作。现在
使用最广泛的编程语言几乎都是10 多年前出现的，即便是比较新的Java
和Ruby 也是诞生于20 世纪90 年代后半，距离现在也已经是15年之前的
事了。也许可以说，现在正是编程语言进化的好时机吧。
最近，受到CPU多核化等因素的影响，Erlang4这种并行处理语言受到了
不少关注。不过Erlang早在1987年就诞生了，也并不是什么新东西，有
点失望呀。
4 Erlang是由瑞典电信公司爱立信(Ericsson)旗下计算机科学研究室所开发的一种编程语言，发布于1987年，并于1998 年实现开源。
那么，未来的编程语言究竟会变成什么样呢？
美国风险投资家、Lisp 启蒙家、作家保罗·格雷厄姆在其《一百年后的
编程语言》5一文中想象了100 年后可能会出现的编程语言，并提议将他
的观点应用到现在的编程语言中。
5 保罗 ? 格雷厄姆(Paul Graham，1964— )是美国风险投资家、计算机科学作家。《一百年
后的编程语言》(The Hundred-Year Language)一文收录于保罗 ? 格雷厄姆的文集《黑客与画
家》一书中，人民邮电出版社2011年4月出版，阮一峰译。
他主张，100年后的编程语言进化的主线，应该以少量公理为基础的“拥
有最小最简洁核心的语言”。在现有编程语言中，最具有这一特征的莫
过于他最喜欢的Lisp了。所以说，他的主张实际上就是说，Lisp才是100
年后编程语言的进化方向。
唔，像我这样的小人物要跟他叫板好像也挺不自量力的，不过我还是认
为，对于未来，应该基于从过去到现在的变化方向，并在其延长线上做
出预测。当然，将来也许会发生一些无法预料的状况，从而大幅扭转之
前的前进方向，不过这样的事情从定义来说本来就是无法预测的，你非
要预测它，本质上也是毫无意义的。
作为一个编程语言御宅族，通过反观过去半个世纪以来编程语言的进化
方向，我认为编程语言绝对不会按照保罗·格雷厄姆所说，向着“小而干
净”的方向来进化。现在的编程语言，无论是功能上还是语法上都已经
不是那样单纯了，虽然也曾经有人努力尝试将这些语言变得更小更简
单，但包括保罗·格雷厄姆自己所设计的Arc
6在内，都决不能算是成功
的尝试。
6 Arc 语言是Lisp 的方言之一，由保罗 ? 格雷厄姆与罗伯特 ? 泰潘? 莫里斯(Robert Tappan
Morris，1965— )共同设计，于2008 年首次发布。
在我看来，编程语言的进化动机，不是工具和语言本身的简化，而是将
通过这些工具和语言所得到的结果(解决方案)更简洁地表达出来。近
半个世纪以来，编程语言不断提供愈发高度的抽象化特性，也正是为了
达到这个目的。因此我们可以很自然地认为，这种趋势在将来也应该会
继续保持。基于上述观点，如果要我来预测100 年后编程语言的样子，我认为应该
会是下面三种情况的其中之一：
1. 变化不大。编程语言的写法从20 世纪80 年代开始就几乎没有什么
进化，今后即便出现新的写法，也只是现有写法的变形而已。(从
发展上来看，是比较悲观的未来)
2. 使用编程语言来编程这个行为本身不存在了。人类可以通过和计算
机对话(大概是用自然语言)来查询和处理信息。(类似《星际迷
航》中的世界，对于编程语言家来说是比较失落的未来)
3. 发明了采用更高抽象度写法的编程语言。这种语言在现在很难想
象，不过应该是比现在更加强调What，而对于如何解决问题的How
部分的细节，则不再需要人类去过问。(难以预测的未来)
当然，上面的预测也只不过仅仅是预测而已，有可能与未来的实际情况
大相径庭，或者说，与实际大相径庭的可能性比较大吧。不过话说回
来，100 年后我也已经不在这个世上了，这不是白操心嘛。
20年后的编程语言
通过对100年后的预测，我们明白了“预测100 年后的事情是非常困难
的”。想想看，100年前连飞机还没有民用化呢，100年后我已经可以坐
在飞机上舒舒服服地写这篇稿子了，这足以说明，要想象社会的变化是
相当困难的。
那么，更近一点的未来又怎么样呢？比如说20 年后。20 年前，日本刚
刚改年号为平成7，现在和那个时候相比，印象中社会应该没有发生非
常极端的变化。计算机的性能等方面确实有了长足的进步，不过发展趋
势还是连续的，并非无法预测。对于20 年后的未来，我想应该可以根
据现在的发展趋势来做出判断。
7 除了公元纪年外，日本人还普遍习惯使用年号纪年。和中国封建王朝时期一样，年号一般是
随天皇的更换而进行更迭。1989 年，明仁天皇即位，改年号为平成，因此 2012 年是平成 24
年。在平成之前的上一个年号是昭和。
个人认为，这么短的时间内，编程语言本身应该不会发生多大的变化。
实际上，现在使用的很多语言，在20 年前就已经存在的。因此我预
计，20 年后的语言，应该是在分布处理(多台计算机协作处理)和并
行处理(多个CPU 协作处理)功能上进行强化，使得开发者不需要特别花心思就能够使用这些功能。
之所以要关注分布处理和并行处理，是因为今后个人也可以通过云计算
的形式使用到比现在更多的计算机，而随着每台计算机的CPU 多核化，就相当于安装了更多的CPU，这些情形都是很容易想象的。
不过，我认为现在的线程、RPC(Remote Procedure Call，远程过程调
用)等显式地使用分布处理和并行处理的形式，早晚会遇到瓶颈。当核
心数量超过数千个的时候，显式指定就变得毫无意义了，调试起来也会
变得非常痛苦。我期待在20 年后，能够出现突破这种局限的技术，即
无需显式操作就可以实现分布处理和并行处理。
学生们的想象
几年前，我曾经在母校筑波大学开展过一次关于编程语言的集中讲座。
在讲座中我给学生们出了“想象一下20年后的编程语言”这样一个题目，并在讲座最后一天提交报告。很有意思的是，大多数学生并没有做出我
上面所说的关于分布处理和并行处理之类的技术性预测，而是提出了诸
如“让编程变得更简单的语言”、“希望用自然语言来控制计算机”之类的
想象。通过这些答案，似乎可以看出他们平常为了完成编程作业而被折
磨得何等痛苦。
不过，这样的答案中，也许也蕴含着真理。近年来，编程语言似乎越来
越难以脱离IDE(Integrated Development Environment，集成开发环境)
而单独拿出来说了。对于Ruby也总有人问“没有IDE吗？”之类的问题，当然，好消息是最近Eclipse 和NetBeans 已经支持Ruby了。
有点跑题了。总之，未来的编程语言可能不会像过去的编程语言那样，让语言本身单独存在，而是和编辑器、调试器、性能分析器等开发工具
相互配合，以达到提高整体生产效率的目的。话说，那不就是 Smalltalk
吗8？
8 Smalltalk 正是一种考虑了“与编辑器、调试器、性能分析器等开发工具相互配合”而设计的语
言。过去它并不能算是成功的，但随着技术的进步，其理念获得了越来越多的用武之地，或许
真能卷土重来也未可知。
唔，历史是否会重演呢？
《代码的未来》是 Ruby 之父松本行弘的又一力作。作者对云计算、大
数据时代下的各种编程语言以及相关技术进行了剖析，并对编程语言的
未来发展趋势做出预测，内容涉及Go、VoltDB、node.js、CoffeeScript、Dart、MongoDB、摩尔定律、多核、NoSQL 等当今备受
关注的话题。八++Puppet——Luke Kanies 的钢铁侠
作者 余兴超
前新浪云计算系统开发工程师，现在UnitedStack负责Devops相关事
务。热衷于开源社区，常用ID Newptone，中文译作牛皮糖。他和他
的小伙伴们(一只猫和一只兔子)现居住在北京城某一安静的角落。图
灵社区ID:牛皮糖
Puppet对于做DevOps的同学来说，是个非常熟悉的名字，但仍有人还不
了解它。那么我先来简单介绍一下：Puppet是由Puppetlabs公司开发的系
统管理框架和工具集，被用于IT服务的自动化管理。由于良好的声明式语言和易于扩展的框架设计以及可重用可共享的模块，使得Google、Cisco、Twitter、RedHat、New York Stock Exchange等众多公司和机构在
其数据中心的自动化管理中用到了Puppet。半年一度的PuppetConf大会
也跻身于重要技术会议之列。AWS的CloudFormation文档中有一段关于
Puppet的介绍，其开头是这么说的: Puppet has become the de facto
industry standard for IT automation。
同时，Puppet在OpenStack中也发挥着重要的作用：OpenStack-ci社区将
其用于OpenStack wiki系统,持续集成系统等等的运维管理；此外社区的
puppet-openstack项目用于完成OpenStack服务的自动化部署和管理，目
前已经在stackforge中托管并通过OpenStack的Gerrit系统来管理代码提
交；此外，Cisco,RedHat,Miriantis等多家公司的OpenStack发行版或部署
工具中均使用到了puppet-openstack。目前，Puppet在UnitedStack的日常
运维管理和产品的自动化部署中也起到了重要作用。
好了，刚刚还不了解Puppet的读者们现在已经知道Puppet是一个牛逼哄
哄的自动化运维管理工具。可能有人已经下完了软件包跃跃欲试了，先
别急，有关Puppet的使用资料在网上可以搜到一大堆，官方的文档也详
细到了“令人发指”。关于Puppet的使用经验分享和各种特性的深入探讨
以及如何使用Puppet管理OpenStack部署的方案分析，哦，都不在本文的
讨论范围之内。
本文的重点是八卦一下Puppet为什么可以这么成功。同时，为避免引起
非Puppet程序员感官上的不适，我屏蔽了各种代码级别的展示和对细节
的探讨。
Luke Kanies的技术之路
故事要从Luke Kanies，这位twitter昵称与Puppet的服务器端进程名同名
的哥们说起，在很久很久以前...成长：苦逼的学生时代
在1992年的时候，Luke进入诺思兰学院成为了一名化学专业的学生，这
是一所位于威斯康辛州的小学校，全美排名在178左右徘徊。
小伙子很争气只呆了一年就跑到了大名鼎鼎的里德学院，成为了乔布斯
的校友。不过倒霉的是里德学院被评为全美十大苦逼学校之一，6年毕
业率仅为75%，也就是有14的同学拿不到毕业证。有别于很多文理学院
自由选课的模式，里德的大一学生必须完成规定的人文必修课程，学习
希腊及罗马的古典文化。这门课程已经有超过50年的历史，里德动用了
学校最为强大的师资力量来为学生奠定文化基础。这还没完呢，之后学
生还必须在四个拓展领域选课：文学、哲学、宗教、艺术方面;历史、社科、心理学方面;自然科学方面;还有数学、逻辑、语言学或外语。大
三学生必须通过专业测试，大四学生则必须完成专题毕业论文才能毕
业。毕业论文并不可怕，可怕的是里德学院的毕业论文的学时是一年，所以有想出国留学的同学，请密切关注另外九所大学的名字…
该来的还是会来的，1996年，Luke大四了。要想顺利毕业的话，他必须
得修完这长达一年的论文项目，这意味着在这一年内他必须要动手设计
和实现，并用实验数据证明，最终组织成论文来完成课题。Luke的论文
题目是Site-directed Mutagenesis in Soy Cytosolic Ascorbate Peroxidase，我推敲了半天，中文翻译大致是：大豆抗坏血酸盐过氧化物酶胞质的定
点诱变。
打工：漂泊和积累万幸的是，我们不用去研究一口气都念不完名字的论文。扯远了，Luke
毕业后没去找一份和化学相关的工作而是去了Cypersite当起了Mac系统
管理员。在Cypersite的日子里，Luke使用AppleScript干着行MacOS的管
理工作，不过干了不到一年还没转正的时候，他便跑路了。
因为在97年的12月份，他在Metro One Telecommunications找到了一份系
统管理员的活儿。Metro One Telecommunications当年可是纳斯达克上市
公司，主要业务是提供电话号码查询服务。在其巅峰时，公司在全美拥
有7000名雇员，然而在2009年初，在售完最后一部分的经营业务后，该
公司还剩余3人。瞄了一眼Metro One今天的股价：0.01美元。通信行业
早已是昨日黄花了，吴军博士已经在《浪潮之巅》中将这些历史描述得
尽致淋漓。
又扯远了，在Metro One的1年零9个月里，Luke的主要工作是管理分散
在全美的30个呼叫中心，包括了呼叫中心计算设备的部署和设置，外加
从总部对其进行不间断的维护。看到这里，我突然想到某家startup的创
始人之前在电信部门做过相同的工作，后来他去做了一个很炫的可视化
部署工具，我猜测通信行业的部署工作充满了重复的机械劳动，有一种
自动化的强烈需求。这里提一下，provision曾是电信行业中的一个术
语，专指安装通信设备前的准备工作，而在devops中常说提起的bare-
metal provision是指在计算机上安装操作系统或者hypervisor的过程。
在1999年，Luke离开了这家电话公司，在BlueStar担任系统工程师，BlueStar是一家卖解决方案的经销商，主营业务有：RFID, Auto ID, POS,Mobility products。Luke主要负责一家DSL ISP服务器端基础架构的设计
和实现。他构建了一套自动化且可集中管理的系统，并负责基础架构项
目的持续开发以及实施和维护。
Luke在“蓝翔”干了还没到两年，又跑去了卡特彼勒融资服务公司担任顾
问，提供系统自动化管理相关的咨询。我查了下，卡特彼勒公司位列世
界500强，成立于1925年，是世界上最大的工程机械和矿山设备生产厂
家、燃气发动机和工业用燃气轮机生产厂家之一，也是世界上最大的柴
油机厂家之一。我在网上没有查到Luke在这段时间具体干了些什么，只
能感叹Luke作为一个系统管理员是怎么混进一个高帅富的融资公司担任
顾问的。
创业伊始：对轮子的修修补补在卡特彼勒待了两年后，Luke开始单飞，找人合伙创建了Reductive
Consulting(2010年改名为Puppetlabs)，头衔是独立顾问，专门从事
Unix基础设施自动化相关的咨询。他着手研究当前开源的系统管理和监
控工具如CFEngine,ISconf,Nagios等等，并且通过二次开发把这些工具联
结成一套满足客户需求的解决方案。这是一个重要的阶段，Luke开始将
积累多年的经验和思考转变为对工具的改写，这期间他的主要工作包括
重写了CFEngine的解析器和开发了ISConf3，这对后来的Puppet开发工
作产生了重要影响。
CFEngine简介
首先，来说一下大名鼎鼎的CFEngine，这是一款出生于1993年的老牌
系统配置管理工具，CFEngine的作者Mark Burgess希望可以使简单的
管理任务自动化，使困难的任务变得较容易。它的核心理念是使系统
从任何状态都能收敛到一种理想状态。
这样的工具对当时还在使用零零散散的脚本来管理机器的系统管理员
来说简直就是冬天的棉袄，夏天的雪糕，黑暗中的灯泡，饥饿中的面
包。之后，CFEngine自然而然地成为了系统配置管理工具中的标杆。
CFEngine有两种工作模式：既可以使用standalone模式即通过cfagent
来完成单台服务器的配置管理工作，也可以通过CS架构(cfservd和
cfagent)来管理整个集群的配置管理的分发工作。
CFEngine的工作方式是基于脚本分发：在配置文件中有一个参数称为
shellcommands，用于配置要执行的命令或脚本，actionsequence则用
于设置shellcommands的执行顺序。
再来看看CFEngine的版本更新：1993年，CFEngine1发布；1998年，CFEngine2发布，而十年后，直到2008年，CFEngine3姗姗来迟，第三
版发生了巨大改变，可以通过使用DSL来定义系统状态，以至于其不
能再兼容旧版本CFEngine2的配置语言。本文谈到CFEnigne时，是指
CFEngine2。
ISconf简介ISconf则是另外一款配置管理工具，它的核心理念是系统的最终状态
是一致的，即使被管理的机器是关机状态，当它们完成启动之后，相
关命令就会被执行，到达一致的状态。同时整个系统无需中心节点，命令可以在任何一台节点上执行并复制到所有节点上。ISconf总共经
历了4代的演化。ISconf1和2是由shell脚本编写，Luke在2002年的时候
开发和设计了ISconf3，并使用Perl在2的基础上进行了重写。ISconf3
有三个核心特性：
确定性的执行顺序
执行中有失败时立即退出
状态维护
从上面的特性来看，是一个挺酷的产品。Luke在02年的时候完成了开
发，并在03年的LISA(Large Installation Systems Administration)会议
上发表一篇名为'ISconf: Theory, Practice, and Beyond'的paper，谈到了
ISconf的特性，开发ISconf中获得的经验和教训，以及和CFengine的
集成，分析ISconf 3的适用场景等等。不过ISconf社区在介绍ISconf3
的历史时对Luke的论文颇有微词，你可以在ISconf的官网读到这篇文
章。不过，ISconf止步于第四版，最后的版本发布时间停留在06年8月
13日，原因未知。
自造轮子
随着Luke的梦想越来越大，这些工具集也变得越来越庞大。而此时对这
些现有的开源工具的修修补补已经不能满足他的需求了。最终，他意识
到只有他自己，才能去创造自己想要的工具。作为一个多年的运维人
员，他深深感受到了苦逼的系统管理员们需要有一个崭新的工具来使得
他们的工作更高效，更便捷。因此，他开始考虑去开发一个新工具，首
先这个工具是为系统管理员而设计的。那么怎么才能称为得上是为系统
管理员设计的呢？
先来简单思考一下系统管理员对于配置管理工具的主要需求：学习成本
低，开发高效，跨平台，代码可复用，安全，可扩展性高等等。
最好的情况就是系统管理员只需关心某个服务或者软件包的状态，例如
我希望部署一个Apache Web服务器，我只关心Apache的包是已安装的
状态，服务是运行的状态，而不要让我去操心这个Apache包是装在Ubuntu下的还是Redhat下，然后到底是要执行yum install还是apt-get
install，然后还要操心这个apache进程到底是用init还是upstart管理的。
此外，还有如何对依赖关系进行处理。先前的配置管理工具都是关注在
如何去完成每一项互相独立的工作，例如配置Apache服务就是一段shell
脚本而已，而没有去考虑它们之间是存在关联的，例如当Apache的配置
文件发生变更时，是应该重启Apache服务来使之生效，而重启Apache服
务的前提是系统已经安装了Apache。
这对于当时占据主流的以分发shellperl脚本的配置管理软件来说，简直
是天方夜谭。不过Luke就是这么设想的，他在构思Puppet的设计时，就
希望将系统抽象成资源：采用面向对象的概念，将每个资源类型组成为
一组属性的集合，每个属性都有相应的行为，并将资源类型和属性构造
成类，最终使用这些属性来使得资源到达期望的状态，而不是用资源本
身来完成这些工作。同时，将所有资源的依赖关系构建成一张有向图，通过这种依赖描述，系统管理员们可以实现复杂的业务逻辑的管理。
越想越兴奋，于是Luke开始动手coding了。Puppet的第一个原型写于04
年夏天，但他并没有把此事放在最重要的位置上。于是在9月份的时
候，Luke居然跑去了BladeLogic担任产品设计，这是一家专门做商业配
置管理软件的公司，它的产品在当时已经取得了成功，然而Luke发现
BladeLogic的品味仅仅是想卖软件给大公司而不是立志为系统管理员设
计伟大的工具。在05年的2月份，Luke下决心继续搞Puppet的开发工
作。于是，在BladeLogic呆够了7个月后，Luke选择了离开。BladeLogic
也终于如愿以偿：被BMC收购了，当然这是后话。
艰难抉择:开发语言和设计哲学
随后Luke回到了Reductive Consulting，也就是PuppetLabs 的前身，开始
了Puppet的全职开发。不过他遇到了一个棘手的技术问题：身为一个Perl程序员，Luke痛苦地
发现，Perl居然无法处理那些Puppet类之间的关系。那时Python被认为
是系统开发的最佳选择，但是Luke同学接受不了的不是Python的缩进问
题，而是print是一个语句而不是函数，len是一个函数而不是方法的事
实，让他感觉“眼睛在流血”。这时候，有个朋友告诉他Ruby很酷，于是
他在尝试了4个小时后，就写出了一个功能原型，从此不可自拔。不过
他也有点担心，因为在当时Ruby还属于非主流，因为ROR(Rails on
Ruby)都还没有出生，不过鉴于他的体验，觉得使用Ruby的开发效率
非常高，因此他决定冒一次险。
在这个问题解决之后，Luke又面临另外一个难题：虽然在此之前他已经
写了不少的小工具，积攒了丰富的经验，不过这些工具没有一个的代码
量是超过1万行的。这也意味着在设计Puppet的架构的过程中，肯定得
摔不少的坑。因此，Luke在开发Puppet的过程中始终要求自己和开发团
队遵守两个指导思想：首先设计尽可能地做到简洁，程序的可用性总是
高于新特性；此外Puppet首先是个框架其次才是一个应用。在解决了语
言选型和设计哲学的问题后，Luke开始潜心于Puppet的开发。
然后呢
然后就没有然后了，随着Puppet的发布和版本的快速迭代，以及社区的
火热发展，Puppet自然而然地就发展成了今天的模样。本来是要开始深入技术细节展开介绍，但是应广大群众要求保持纯八卦风格的呼声，下
半部分在内部审批时被惨无人道地砍掉。对于Puppet和Luke的介绍到此
告一段落，咱们再来八一下群众们喜闻乐见的热点事件。
投资风云
事情源于两年前，VMWare作为PuppetLabs的6家投资公司之一，向
Puppetlabs投了850万美刀。在今年的2月份，VMWare宣布提高对
PuppetLabs的投资：3000万。此外，VMware负责云架构和管理的执行
副总裁Raghu Raghuram将进入Puppet Labs董事会。
这从资本市场的角度说明了Luke和Puppet的成功，叫好又叫座。但是也
引发了人们的担忧：一些人认为Puppet的独立性是非常重要的，理由是
DevOps的成功非常依赖于这个组织选择什么样的工具用于企业基础设
施管理，PuppetLabs作为IT自动化管理领域里的领头羊，然而VMware
对Puppet存在强大的话语权，目前PuppetLabs花了很大的精力在Puppet
企业版本的开发上(Puppet PE)，用于和VMWare vCloud Automation
Center等产品的集成。这并不是一件好事，可能会使得社区版本和商业
版本产生巨大的差距，甚至可能会发生Oracle和MySQL那样的故事。
再看看VMWare的老对手Amazon的反应，即使Amazon在开头提及的文
档里承认Puppet是事实上的行业标准，但考虑到它的老朋友VMWare手
握对Puppetlabs 23的投资，在其新推出的OpsWork服务中清一色地使用
了Chef用于系统的配置管理，这是诞生于Puppet之后的另外一款开源的
配置管理工具。
再来听听其他人的声音。Matt Asay与Luke是多年的好友，在Lukes与
Andrew Shafer创立Puppet Labs后，Matt 曾经提出了许多商业化建议，包
括进行融资，但Luke更希望公司保持独立。Matt淡定地回答记者：如果
你了解Luke Kanies这个家伙，你就知道保持独立对于他而言是无比重要
的事。他在田纳西州长大，不是那种出卖灵魂的人。Luke在IM上和Matt表达了自己的看法：“向云端转换的趋势将给下一代
系统平台管理工具带来无限的机会，对VMware如此，对PuppetLabs亦
是如此。即便PuppetLabs被VMware掌控，但这些系统仍构建在开源的
基础上，并赋予它们一定的自治权。Puppet拥有活跃的开源生态圈，就
像OpenStack一样，是对投资很好的补充。”
最后谈谈我的看法，首先Puppet天生就是开源血统，其社区非常活跃，而且从2.7开始变为更为友好的Apache许可证(之前是严格的GPL)。因
此，即使发生像MySQL那样的事情，照样会有另一家MariaDB出现，更
何况还有后起之秀Chef在一旁虎视眈眈，VMWare理应不会下这步昏
棋。同时，对于指责Puppet只关注于与VMware产品的集成是有失偏颇
的，虽然最近PE的动静很大，但是PuppetLabs也花费了很大的精力投入
到Puppet-Openstack社区中，在之后的Puppet系列博文中会对此进行阐
述。所以，我并不担心Puppet是否会成为下一个MySQL。我们学到了什么？
在前面洋洋洒洒的一堆八卦中，我简单地谈了一些关于Luke和Puppet的
故事。每个人可能都会从中看到不同的东西。对我而言，Puppet之所以
能取得成功，我认为有：
做自己最擅长的事：Luke拥有丰富的运维经验和配置管理工具的开发经
验，在此基础上去开发Puppet是获得成功的基础之一；
取其精华：在调研同类工具和产品时，Luke不只看到了其中的不足，还
吸收了它们的优点；
志存高远：Luke开发Puppet时候的动机是为系统管理员提供最棒的CMS
工具，而不仅为了挣钱，被收购，上市。动机越单纯，成功的概率越
大；敢想敢做：现在去挑选手机，我们几乎不会去考虑手机是不是触摸
屏的而是去看屏幕有多大，PPI多高，因为手机是触摸屏这是理所当然
的，然而在iPhone之前，触摸屏手机还是很稀有的东西，大家都在往功
能更多的方向越走越远；同样，现在在使用Puppet时，会觉得使用声明
式配置语言是理所当然的事情，殊不知在Puppet诞生的同时代中，都是
清一色的命令式或者过程式的配置语言。
免责声明
本文的所有情节来自本人花费一周的夜生活时间，阅读了各式各样的博
客，新闻，评论，代码，勉强拼凑而成，若有与实际不符之处，请一笑
而过。出版的未来电子书时代可以来得更快
作者 董苗苗
图灵策划编辑。关注IT人文、前端技术。关注数字出版和新媒体。希
望自己能够持续积累和提高。
国内环境下的电子书和纸质书关系的争论和探讨已经持续很久了，作为
出版行业刚入门四年的小字辈，我不敢造次，不过还是很想谈谈自己的
想法。
我把阅读性图书大致地定义为轻阅读和重阅读两类。小说、杂志、漫画
等是轻阅读，教材、科技书、专业书等为重阅读。由于传统习惯，重阅
读可能还是比较偏向纸质书，尤其是很多人喜欢在书上写写画画，但是
由于移动智能终端的普及，轻阅读的电子书的发展不可小觑。
我身边有前辈说，纸质书完了，电子书会完全替代纸质书!我完全同意这个观点。不过在这之后的几年中，在中国，恐怕是不会实现的。除非
——
电子书销量想共赢？各种阅读软件之间能够实现阅读兼容才
好
我以前是坚定的纸质书拥护者，2013年初我自己也转投电子书阵营，原
因很简单，塞班”死”了，我换了一台将近5寸的安卓智能手机，从此我
真切地感受到了电子书的优势，开始走上寻觅“最佳”阅读体验的道路。
可是哪里有最佳呀，各有各的优势，可用户(比如我)是那么地挑剔，那么地较真，甚至是那么地不讲道理，就想找个最好的阅读软件，怎么
办？让产品经理去抓头皮吧!
现在有那么多电商和数不清的各种阅读应用，却不完全兼容？!
(这里暂且不提“免费电子书”)
明明喜欢这家电子书商的排版风格，却没有自己喜欢的书？
为什么同一本书每家的价格差那么多？
为什么刚买完就降价了，玩呐？
在一家买的电子书，明明是正版，可别的阅读软件就是用不了，有
的价格还“不菲”，真真不如直接趁打折的时候买纸质书的好!
各家都想保护自己阅读软件的用户使用占有量，保证自己的市场营销占
有量。可用户真的不是拦截得住的，电子书商不是要变身铜墙铁壁，而
且要变成一张黏糊糊的网，具有优质的用户体验才是得到了真正的铁饭
碗。
要知道——
用户都是顽固派，喜欢一个，习惯一个，就不想换阅读软件了。
用户都是懒汉，就希望买一次正版电子书，换谁家的浏览器都能
看，不需要转换来转换去。
用户都是贪心鬼，尽管一次也许只会买一本书，但是要求“商城”里
提供的电子书种类堪比图书馆。
用户都是贪小便宜的人，同样的书，差不多的排版，必然选择最便
宜的。爱书的人买书不会抠门，但是省下的钱多买几本，这才是正
道。
用户都不是傻人，每家价格定得天差地别，有的还动辄减价，那我谁家的都不买，“我等着!”
如此，我给做软件开发的朋友出个主意：做一个图书比价软件。功能包
括：
1. 搜索书名，立即出现几家电子书商的价格对比(也可以进行纸质书
价格对比，纸质书、电子书价格对比)。
2. 显示和该书有关的营销活动。用户可以直接找到最划算的途径购买
电子书。相信很多用户就是这么做的，不过前文说过了用户都是懒
汉，自然有人代劳，或者一劳永逸才好。
3. 书评、打分、互动、相关信息等其他扩展功能。
如此一来，价格只会趋同，大打价格战，全是输家呀!那大家拼的是什
么？如果这个问题回答不出来，白白称为“电商”了。拼的是用户体验
呀!文案编辑、美编排版、线上线下活动、作者读者的互动。
有的人问了，长此以往，那不就是又趋同了吗？我就是想在当今社会独
树一帜!您在开玩笑吗？地球上哪个行业、哪个商业模式是独树一帜
的？想要常开常艳，拼的就是优质的用户体验，持续的服务，耐久的行
业追逐力，以及决定性的创新能力了。创新是加分题，都想加分，可先
不要丢分才行。
(未完)下文提示：
电子书时代可以来得更快(二)
电子书价格战损人不利己，价还得是出版方定
电子书时代可以来得更快(三)
重阅读也要投靠电子书？完美实现“电子书图书笔记”功能才行书榜大家都在读什么？
挑战程序设计竞赛(第2版)
作者：秋叶拓哉 岩田阳一 北川宜稔
译者：巫泽俊 庄俊元 李津羽
书号：978-7-115-32010-0
图灵社区推荐：
世界顶级程序设计高手的经验总结，ACM-ICPC全球总冠军巫泽俊主
译，日本ACM-ICPC参赛者人手一册。
本书对程序设计竞赛中的基础算法和经典问题进行了汇总，分为准备
篇、初级篇、中级篇与高级篇4章。作者结合自己丰富的参赛经验，对
严格筛选的110 多道各类试题进行了由浅入深、由易及难的细致讲解，并介绍了许多实用技巧。每章后附有习题，供读者练习，巩固所学。
机器学习实战
作者：Peter Harrington
译者：李锐 李鹏 曲亚东 王斌
书号：978-7-115-31795-7
图灵社区推荐：
全书通过精心编排的实例，切入日常工作任务，摒弃学术化语言，利用
高效的可复用Python代码来阐释如何处理统计数据，进行数据分析及可
视化。通过各种实例，读者可从中学会机器学习的核心算法，并能将其
运用于一些策略性任务中，如分类、预测、推荐。
图解TCPIP(第5版)
作者：竹下隆史 村山公保 荒井透 苅田幸雄
译者：乌尼日其其格
书号：978-7-115-31897-8
图灵社区推荐：
这是一本图文并茂的网络管理技术书籍，旨在让广大读者理解TCPIP的
基本知识、掌握TCPIP的基本技能。本书引导读者了解和掌握TCPIP，营造一个安全的、使用放心的网络环境。
推荐系统
作者：Dietmar Jannach， Markus Zanker， Alexander Felfernig， Gerhard
Friedrich
译者：蒋凡
书号：978-7-115-31069-9
图灵社区推荐：
本书全面阐述了开发最新水平推荐系统的方法，其中呈现了许多经典算
法，并讨论了如何衡量推荐系统的有效性。书中内容包括基本概念和最
新进展两部分。此外，本书还包含大量的图、表和示例，有助于读者对
于知识的理解和把握。
Cocos2d-x高级开发教程：制作自己的
《捕鱼达人》
作者：火烈鸟网络科技
书号：978-7-115-31796-4
图灵社区推荐：
代码的未来
作者：松本行弘
译者：周自恒
书号：978-7-115-31751-3
图灵社区推荐：
贴心设计：打造高可用性的移动产品
作者：Jakob Nielsen, Raluca Budiu
译者：牛化成
书号：978-7-115-31879-4
图灵社区推荐：
大数据的冲击
作者：城田真琴
译者：周自恒
书号：978-7-115-31787-2
图灵社区推荐：
JavaScript异步编程：设计快速响应的网
络应用
作者：Trevor Burnham
译者：许青松
书号：978-7-115-31657-8
图灵社区推荐：
Objective-C高级编程：iOS与OS X多线
程和内存管理
作者：Kazuki Sakamoto, Tomohiko
Furumoto
译者：黎华
书号：978-7-115-31809-1
图灵社区推荐：成书手记ACM-ICPC冠军谈《挑战程序设计竞赛》及相关
算法书
作者巫泽俊
浙江大学2010届数学系本科生，2013届计算机硕士生。曾代表浙江大
学获得2009年ACM-ICPC World Finals第6名，2011年ACM-ICPC
World Finals冠军。在线比赛中常用watashi和rejudge等id。
前几天，秋叶拓哉(iwi)、岩田阳一(wata)和北川宜稔
(kita_masa)所著，我(watashi)、庄俊元(navi)和李津羽
(itsuhane)翻译的《挑战程序设计竞赛》，终于通过人民邮电出版社
正式出版了。可喜可贺，可喜可贺。这里我主要想说一下自己为什么要
翻译和推荐本书，还有对程序设计竞赛学习资料的一些看法。也附带一
些对译者序和第1章的补充说明。
在译者序中我也略谈到了自己翻译此书的动机。和很多读者一样，最开
始当然是奔着作者的名头去的，三位作者不但是国际知名的选手，而且
TopCoder的最高rating加起来都破9k了。顶尖实力的作者往往可以站在
更高的高度指点江山，也就更可能写出一本好书。随后就是读到书中的
内容了，书中的绝大多数东西，我大概都在过去四五年时间的摸爬滚打
中，逐步通过各种书籍、网络、道听途说、解题经验和总结体会掌握
了。不过还是有一些耳目一新的内容，其中有一两个问题还是通过邮件
得到了原作者的解答，涨了知识。但仍有一种相见恨晚的感觉，假如自
己早两年读到此书，想必能少费不少劲。从我个人的经历和对周围同学
的了解来看，这是一本非常值得引进和推荐的书。
当然，在此之前国内已经出版有不少算法竞赛相关的书籍了，很多人想必希望知道这本书有什么特别之处。算法竞赛相关的书籍大致有两类，一类是算法和数学类的书籍，比如各种数据结构教材、离散数学教材、《算法导论》、《具体数学》等，一类是专门针对算法竞赛的书籍，其
中的代表就是刘汝佳所著的几本书，而《算法艺术与信息学竞赛》(黑
书)又是其中的代表。作者之一的iwi在MSRA实习期间也得知了黑书的
大名。
首先，个人觉得这些书籍大致可以分为两类：教科书和工具书。诸如
《数据结构与算法分析》(DSAA)之类的书可以作为教科书的代表，而诸如《计算机程序设计艺术》(大名鼎鼎的TAOCP)则毫无疑问是
工具书的代表。大致地说，前者简单易懂，适于学习，后者高深全面，适于参考。二者并没有明显的分界线，很多时候全凭主观，因人而异。
比如说，看懂了，这就是教科书，看懂目录了，这就是工具书。当然，和数学沾边越多的书，总是越难啃的，所以就难度而言，这类书籍和编
程语言类书籍自然是没有可比性。
许多书都作为程序设计竞赛的学习资料被反复推荐，但事实上，我们大
概可以仿照《最常被程序员们谎称读过的计算机书籍》写一篇《最常被
ACMer们谎称读过的书籍》的吐槽文。里头有一句话很重要，所以我再
抄一遍：“如果你自己没有读过这些计算机书籍，请不要推荐给别人”。
当然，像《算法导论》这样的书个人觉得还是值得一读的，多数的章节
并不难，可以当作教科书，后面的一些内容可以作为工具书需要时再参
考，里面很多东西讲得很细，容易做到真正的理解吸收，比如从自动机
引出KMP，等等。而TAOCP则无疑是最常躺枪的装逼神器。有一天，我在同学的桌上看到一本TAOCP第一卷，打开一看很黄很暴力，我赶
紧就把它盖上了。TAOCP很厉害，看exponentiation by squaring能引用到
它，看permanent也能引用到它，连看数え上げお姉さん都能引用到
它。读完TAOCP那必须能变得超厉害了，可那得是能读完啊，读不完
说啥都白搭。所以推荐学习资料不能光看书好不好，还得看对目标人群
合不合适。而一本好的教科书，不应该是尽可能体现作者有多牛，而是
要能够尽可能简单地帮助读者变得更牛。如果看完了，懂的还是懂，不
懂的还是不懂，那是没有意义的。
按照这个分类标准，个人觉得《挑战程序设计竞赛》是一本很好的教科
书。它非常适合作为有志参加程 ......
您现在查看是摘要介绍页， 详见PDF附件(10871KB，129页)。