前言

今天我想思维跳跃一下，讲讲包管理器，这是一个相当有趣的话题。因为程序员年复一年的写程序，大多是为了娱乐他人，好吧，有的人管那叫创造价值，有的人叫养家糊口。其实没所谓了，本质上来说大部分程序员并不是自己程序的受害者，所以你知道为什么这个世界上有那么多烂程序了吧。让我们回来，聚焦在那些极少的程序员写给自己的程序，除了编译器，版本控制工具以外还有一种非常非常重要，那就是包管理器。

你知道的这个世界上真正了解编译器的人据说坐不满一间教室。我想了解包管理器得人也多不到哪去。首先我们要看看今天要出场讨论的一些候选人。

• apt 具有超级牛力Debian系猛男
• yum 为Redhat延寿20年的黄狗
• homebrew Mac下的青年才俊
• rubygems Ruby下的魔法大师
• npm Node.js的超级保镖
• elpa Emacs的小宝宝

我今天要忽略一些内容，很可能引起某些人的不满。比如像Perl，Python，PHP，Haskell，Lua，R都有一些类似的设施，所以就不一一讨论了。明眼人也许看出来了，六个男嘉宾可以分为两组。一组是系统级别的（system-level），一组是应用级别的（application-level）。维基百科基本上对系统级别的包管理器做了一些介绍，应用级别的仅仅是列举了几个，并没有详细的介绍。但我认为包管理器都是完成类似的工作所以放到一起来讨论。

验证

从单个包的角度来说，一定要确保其来源，否则会轻易受到中间人攻击。所以一般的包管理器都具备简单的验证环节。常见的手法是MD5校验，或者其他Hash校验，homebrew提供的大部分安装包都是用这样的方式校验的。较为严格的应做签名验证，apt和yum都有相应的机制来验证软件包是否来自可信的源。综合来讲Hash的方式加密强度较低，而且严格说来这种校验只应作为下载的完整性检查，并属于授信操作。

依赖性

可以说包管理器解决最为重要的问题就是依赖性关系的问题。我相信在没有yum的RedHat中世纪，大家需要参考n多资料才能正确编译内核。那个时候他们是真心羡慕Debian的。在elpa出现之前，配置一个贴心的emacs环境简直就被视为高手的验证标准。依赖性关系其实并不像看上去的那样容易解决。很多年来make为了解决编译依赖性关系遭受不少的冷嘲热讽。尤其是这种依赖性关系比较松散的时候，看上去就不那么好解决。A依赖于B的3.2.1以上但不超过3.3的版本，这种有时候行有时候不行的条件判断构成了一个非常复杂的逻辑关系。但包管理器必须处理好这个关系，知道哪些依赖条件没有得到满足。依赖性关系的管理是一个生态系统的核心价值。Perl有了CPAN所以带来了一个非常美好的世界，甚至有人说CPAN比Perl的语法更吸引他。依赖性可以让程序员不那么纠结去手工寻找所需要的包，而这个过程可能是相当费时，步骤非常繁琐，而且极容易出错的。对，就好比不使用make工具来编译内核，不是不可能，但阿汤哥会做一些更有利于世界和平的事情。依赖性带来的好处就是开包即用，开袋即食，完全不必担心由于依赖性造成的破损。我猜测由于包管理器提供了一个可信的，可重复的，健壮的依赖性管理，每年程序员节省下来更多时间用于创造新的垃圾代码。

多版本

传统上的包管理器的互斥关系管理有点粗放，apt和yum在处理升级之类的问题时基本就是粗暴地将老的版本替换掉。当然这样设计是比较简单的，可是我们的系统并不美好，经常会有一些遗留软件需要老版本的库。而且从实践的角度来讲这也是一个不太难解决的问题，很多人的机器上都有各种版本的软件，所以后来设计的包管理器就注意了这方面的改进，比如homebrew和rubygems都可以支持同一个软件的多个版本，相互不影响，用户可以随意指定使用软件的版本。多版本是松散型依赖关系必然会出现的特性，也是简单粗暴转向优雅设计的拐点。一个随之而来的问题就是清理不用的版本。这是原来简单粗暴方式比较好解决的一个问题。将原来的是非判断变成了一个寻求最优解的优化问题了。

相对独立的环境

有的时候我们希望严格限制程序的运行环境，但由于包管理器为了便于升级和追新设定了比较宽松的限定条件，使得构建相同的运行环境在相当长的一段时间都是一个非常困难的任务。随着云计算的兴起，基础设施代码化这种思潮逐渐深入实践，诸如bundler这样精巧的工具诞生了。环境配置再也没有手工操作了，而且可以确保所有系统完全一样，简直帅呆了。如果你不觉得帅，那你定没有半夜被狗血电话叫起来去修复线上bug，结果发现这是某个库包与开发者的环境不一样导致的。相对独立的环境在开发者之间也非常重要，任何差异都可能导致惨痛的教训，真金白银的教训啊。相信越来越多的开发者会在云端部署自己的应用，构建相同的环境今后会成为开发者的基本要求的。

发布

有的包管理工具还提供非常便利的构建工具，可以快速构建自己的软件包，并将其发布。开发者可以随时贡献自己的智慧。rubygems就是这样的典型。homebrew可以本地构建一个配方，然后发起pull request，一旦获准别人就能使用了。这个对于未来的开发模式非常重要。Node.js社区的蓬勃发展就是很好的例证。实践证明降低参与者的参与成本特别有利于大家为社区做贡献。

源码还是二进制

我倾向于homebrew的源码编译方式，虽然有点慢，遭到一些诟病，不过我觉得看着代码打补丁，编译是我的个人乐趣。

传输问题

考虑到中国网络的多样性问题，在此我讨论四个方面：网速测试，断点续传，多点传输，下载调度。无疑elpa在这几方面做得奇差无比，简直就是各个方面的反面教材。yum提供插件可以检测最快的镜像源，apt做得也还可以。但都不能同时从多个源下载同一个包，有时候我们还是很需要迅雷或者BT的功能的。断点续传不用多说了，算是一个基本功能。同时开启多少个并发就不能智能点么，非得一个或者n个，就不能自动调节么。

甚至我觉得包管理器应该构建于BT或者电驴之上。

关于源

私自搭建一个源应得到鼓励，应该几乎没有成本地加入到整个全球分布式的系统中，源之间的同步应该也是开箱即用的。这方面做得最好的我认为是全球的公钥分发系统，BT和eDonkey次之。

结语

生态系统无论对一门语言还是对一个系统来说都是非常重要的，人们不会凭着一门语言良好的语法就蜂拥而至的。良好的生态系统为他们提供可靠而丰富的工具链，库包，最佳实践。而位于生态系统核心的正式管理依赖性关系的包管理器。本人杂乱地讲述了对各种包管理器一些思考，希望能“抛砖引砖拍”！

昨天公司内部发了一个邮件让做一个调查。考虑到这个调查系统是我们自己开发
的，而且我还没有使用过，便兴致勃勃地开始一段特别苦恼的旅程。

我不断地问自己问题：一个在线调查系统的目的是什么。在我备受煎熬，不得不
依靠自己强大的内心才完成了这次调查之后。我极其郁闷地将开发同学和产品同
学召集起来，将问题抛给了他们：“请用一句话回答：在一个被调查者眼中怎样才
算是一个好的调查网站呢？”

“需要有其他选项，不想被限定在某几个选项中。”

“易于学习，便于掌握，好操作。”

“引导用户说出自己真实的想法。”

“⋯⋯”

我深深地叹了口气，摇了摇头。我对这些一点儿都不着边际的话并不感到意外，
但我依然抑制不住自己失望。我提示大家：“你们猜我在做调查的时候是一种什么
样心情和想法？”所有人都有点愣住了，似乎从来没考虑过这个问题。

“做这个调查时，我唯一的想法就是：怎么TMD还没做完？！”

很多人笑了，看来这种经历并不是专属于我个人的。还有的人提示我说：“哦，这
个还算简单的呢！”

我继续问道：

“谁会来我们的网站接受调查？他们的目的是什么？我们的产品给他

们带来了怎样的价值？”

所有的人都静下来了。我一点一点的展开：

要知道我们其实做了一个非常操蛋的网站。因为所有来我们这里的用户都非常讨
厌我们的产品，没有，绝对没有任何一个被调查者会喜欢我们网站。因为他们不
是调查公司施以利诱骗来的，就是受人所托，或者是被要求（被逼也说不定）必
须完成调查。没有人是自愿的。他们从我们的产品不能获得一丁点儿价值。他们
想要的是什么？无非是尽早结束，这样调查公司骗来的用户就能获得那些虚无缥
缈的积分，受人所托的就能对别人有个交代，强迫完成的也总算能交差了事。

“一个用户无法获得价值，一分钟也不想多呆的网站肯定是个非常操蛋的网站了吧。
我们唯一能做的就是让其少操蛋一点，配合用户最快速地完成调查。好吧，这就
是用户眼中好得调查网站的标准：最快速地配合用户完成调查。”

所以，交互上要实行最简原则：

一个狗屁单选题绝对不要让用户再确认一次，对于单选题来说“下一题”的这个按
钮也完全没有必要。少一次点击对于程序员来说似乎是一个“死不了人”的问题，
但对于单选效率则会提高100%，这是别的优化望尘莫及的。有反对意见的同学可
以参考google首页，这是一个跳出率极高，粘滞时间超短的页面，难道我们的页
面不应该这样么。

扩大点击范围，整个选项都应该是可以点击的，而不仅仅只是有个选项框可以点
击，极力减少用户在操作过程中的鼠标滑动。邀请选择的暗示要足够强烈。

根本不需要后退(或者“上一题”)按钮，用户一心想往下进行，根本没有心思后退。
如果需要后退的话，那一定是某处逻辑设计失误(比如互斥条件)。如果是这样的
话，一定要立即解决逻辑设计的问题。后退这个按钮掩盖的都是肮脏的浪费。

支持键盘操作。要知道，虽然答题的人不想答题，但经常答题的人群确是非常稳
定的，一旦他发现键盘可用，则会兴奋起来，对于职业答题者非常必要的。

尽量避免让用户录入文字。“其他”就足够了。

尽量将问卷一次加载到前台，由相应的javascript来完成前台逻辑校验
(backbone.js就是不错的技术方案)。
后记

我听说了很多关于调查问卷的奇闻轶事。

有的客户要求做的调查有100多道题目。我不知道制作题目的人是不是仅仅是为了
完成任务。100多道题目太多了。人类的注意力集中时间大概只有20分钟左右，所
以必须在这之前完成所有调查。否则用户会倾向于敷衍，或者欺骗调查系统。

有的客户要求题目的逻辑异常复杂。你做到最后几个题目时不让你继续，除非你
把之前的20道题目都改成他们认为合理的取值范围内。我也是玩过有偿点差的人，
后来放弃了。全因为这些调查不仅是对你智商的侮辱，也是对你耐心和体力的双
重考验。这就是特别典型的逻辑互斥设计缺陷。

有的客户要求当用户对某个题目分数比较异常时给出理由。理个屁啊？会有人看
么？？既然然人家选，就不要问人家为什么。所有选项间的继续进行难度应该是
一样的。人为造成的交互难度不一致会使得用户倾向于选择交互容易的选项。所
以客户看到了他们想要看到的结果，问题是那TMD还做什么市场调查啊？

有的客户设计了特别变态的逻辑题目，让用户完成一张我们都认为连阿汤哥都无
法完成的表格。拜托，用户要是都能做完，阿汤哥不就失业了。调查表格的设计
前提就是填写者没有义务填写。一个直接推论就是填写调查表格时，用户不需要
借助辅助思考或者计算h。我真的不知道，调查表的设计者学没学过《市场调查》
之类的课程。有没有老师认真地告诉他们，其实填表的都是大爷。

好了，就权当娱乐了。

现在说JavaScript大红大紫估计大家不会有什么反对意见吧。如今学习
JavaScript不但是一种非常保险的策略，甚至是必要的生存之道。不过这门语言
就和他的难兄难弟HTML一样承载了太多本不应该它们来做的事情。发展速度的过
快造成了原有设计上的缺陷被极不合理地放大了，以至于业界大牛Douglas
Crockford出手教人如何正确地利用那些还不错的特性，避免陷入令人恼火的陷阱。

问题的关键是人都是不靠谱的，再怎么教，再怎么强调，再怎么小心，
JavaScript那些罪恶的灵魂依然会渗入你项目的骨髓当中去。似乎是有
JavaScirpt的地方就有那种挥之不去的阴魂，即便使用了JSLint，也是疲于奔命。
CoffeeScript也许是这种噩梦的终结者，它继承了JavaScript好得部分，但也限
制了一些过于随意的地方。看似CoffeeScript是一门全新风格的JavaScript语言，
或者说是Ruby风格的JavaScript，但也没有必要大惊小怪。还是SICP中的那句
话:"解释器(编译器)也是一个程序"。与其为一门语言做些修修补补的操作，不如
另立门户。貌似C++走的就是这样一条路，历史总是很相似啊。CoffeeScript的一
个比较有意思的地方在于编译生成的正是JavaScript，这样就非常好地解决了与
现有系统兼容和集成的问题。OK,你可以放心大胆地用这个新技术，他对你的老板
是透明的，因为他只能看见工作的JavaScript，并不能看见你的源码。当计算机
技术发展到了今天，有趣的事情终于发生了，你以为看见的是源代码，其实不是。

无独有偶，CSS方面也有类似的方案SCSS(SASS)，来解决CSS不支持变量，继承等
问题。巧合的是这两个方案都将作为Ruby on Rails近期即将发布的3.1版本的默
认方案。世界变了，你拿的武器变了么?

最近在写一些ruby程序，自然了，要做一些测试什么的，RSpec无疑是一个非常好的帮手。但是很多人都以为RSpec是用来测试Rails程序的，其实RSpec不止局限于Rails程序，它是一个非常通用的测试框架，不过网上大部分例子都是围绕Rails的，所以给大家带来了一些误解。最近呢，RSpec发布了新版本，2.n，目前已经到了2.3。发布了大版本自然有很多改进，少不了也有许多令人不愉快的变化，尤其是对第三方的不思进取的其他工具的兼容性上就有些问题了。

首先是RSpec和aotutest结合，这个是使用RSpec的第一步，当然并不是所有人都会这么告诉你，但是基本上保留秘密的那些人就是这么用的。RSpec 2需要配置一个./autotest/discover.rb:

Autotest.add_discovery { "rspec2" }

你可以自己写一个，也可以让RSpec自己生成

rspec --configure autotest

效果是一样一样的。这样便可以使用RSpec了，无痛而且高效。

第二，我们要搞一个rr集成到RSpec中去，至于rr是什么，以及为什么要rr，这里简单说一下。rr是一个通用的Test Double框架，这里可能有点不太好懂，因为就算是自认为很了解Unit Test的人也未必真的知道这个词。不过好多童鞋已经知道了RSpec的mock，或者stub了，简单的来说：rr能够提供更好地mock和stub。更好意味着可以更加方便地解耦我们要测试的目标模块，这样意味着能够更细粒度的定位问题，从而获得更加有效的测试效果。

rr集成到RSpec，貌似也不是很难，不过这里要注意，RSpec的整体命名空间有所变化，现在都是以RSpec开头了，原来的那种以Spec开头的会得到警告信息。

RSpec.configure do |config|
  config.mock_with :rr
end

但是这里会稍微有个问题，autotest的时候，在一些情况下autotest不会加载这个spec_helper.rb文件，或者是加载的顺序有些问题，就会导致一些rr方法不能使用。处理办法就是在spec文件前面加入

require "spec_helper"

目前我还没有找到更好的方法，不过估计以后的ZenTest会处理好这个问题吧。或者是启动ruby解释器的时候加入-r这样的参数。

第三个，就是将Rcov结合进去了，做法也比较简单，但是要注意使用RSpec 2的命名。

require "rspec/core/rake_task"
 
RSpec::Core::RakeTask.new :cov do |task|
  sh 'rm -rf ./coverage/*'
  task.rspec_path = "rspec"
  task.rcov = true
  task.rcov_opts = %w{--exclude spec,rubygems}
  task.ruby_opts = %w{-rrubygems}
end

不过这个并不像想像的那么顺利，rcov调用这些例子的时候没有加载RSpec库，真是不幸，所以我们可爱的spec文件一般都会额外多加两行

require "rspec"
require "spec_helper"

这样基本能暂时解决目前的所有不适，可以轻松享用RSpec的好处。

另外我要说的就是，这些修修补补的工作本来不应该存在，这几个工具在今后应该考虑整合一下，友好地集成，毕竟像我这样愿意花时间配置的人不太多。尤其是Rcov，对RSpec2的支持显得有点跟不上了。

话说怎么备份本身就是一个非常值得深入探讨的问题。能把数据放置到别的地方，而后再拿回来使用，看似很简单，但实际应用中却是非常令人恼火的一件事儿。因为实际运行中，所有的数据都是流动的，以刻舟求剑的方式来作数据的备份和恢复就很不靠谱了。但同时，任何应用于生产环境的数据存储方案首先要考虑的就是备份融灾问题。可能你的机房里不会有大象，但是说不定会有老鼠呢。可能你的操作人员不小心拉错了闸。这些事情貌似都不太可能发生。但是以我的实际经验来看，如果你没有备份的话，倒霉的事儿发生的几率就会成几何级数增长。也就是说备份了就备份了，要是不备份，倒霉的事儿总会发生在你头上。所以还是小心一些。另外说一句，备份是非常不符合精益思想的，起码原生态的简单备份有着明显的浪费，而且若是做不好监控的话，出故障的几率并不低，所以千万不要觉得备份就万事大吉，仅仅是运维的第一步而已。

有两种比较简单的备份方法（直接copy数据库文件，mongodump），不太能单独在生产环境中使用。比较建议的做法是构建Master-Slave，在Slave上做些备份，slavedelay是个非常有用参数，要是不想搞得很麻烦，就可以设置几个不同的slavedelay值的slave，这样就可以应对很多情况了。有人问了，如果有些延时，那么岂不是会丢失一些数据。说对了。首先备份并不能保证完全不丢失数据，任何地球上已知的方法都不能保障这一点。其次，备份数据也要考虑备份的目的。其实并不是所有情况都是要回复到最新的数据的，想一想有人用大量垃圾数据填充你的数据库你怎么办。应对这样的情况就不能简单地恢复到最新的备份了是吧。

在slave上，可以定期地加锁，备份，然后解锁。总之了，要在slave展开热备份的一切操作，甚至为备份建立专门的slave。比如视觉中国的图片存储方案中的备份就是这么做的。