其实 minitest 就已经满足了这个拆分条件。不与 Ruby 的版本发布周期相绑定 (当然人家一开始就不在标准库里..).

看末尾几条讨论，问题似乎出在发布形式上：是发布成特殊的，无法删除的 gem, 还是发布成普通的 gem. 以及 gem 源码要不要提交进 ruby 的 source tree 等等。对我们用户而言好像没什么可担忧的... 反正我们自行启用新 gem 的时候能覆盖标准库的就好。

Minitest::Spec 用户表示还是喜欢 minitest. 哦对了，RSpec 3.0 据说要开始推 expect() 的语法（默认只启用 expect 语法，should 语法需要手动配置启用），感觉更加 verbose.

再有一个决定性的因素是速度：在我个人习惯的 TDD cycle 里，“只运行一个测试文件”是最常出现的用例。从按下编辑器快捷键到看到测试结果这个过程中，对速度影响最大的环节其实是测试框架本身的加载速度（用 $ time 看一下发现基本都是 system 时间）。这时 Minitest 大优。

前几天刚好也装了 Debian 7.0 用来测试。印象中当时手懒就没给 root 账户设密码，然后安装程序很亲切自动地把我的帐号加到 sudoers 文件里。

#10 楼 @ChanceDoor 论坛支持 markdown 格式：http://daringfireball.net/projects/markdown/syntax#list

个人觉得值得一提的两个细节：

• 用 bundle gem foo -t 生成新 gem 的 skeleton.
• Rubygems 是怎样修改 $: 的; gem 作者自己不要去碰 $:. gem 代码中何时应当用 require, 何时用 require_relative (这个其实我也拿不准，趁机求教 www).

Rubygems 的降级文档：http://rubygems.rubyforge.org/rubygems-update/UPGRADING_rdoc.html

#20 楼 @chairy11 问题在于，JS 的这个语言特性本来就不是很容易说清楚的... 和其他语言的高级语言特性一样，要给出些许实例才好理解。 #4 楼 的例子为了说明问题稍微精简了一点，对于彻底的新人而言理解起来估计还是有压力 (吧).

考虑过。但是电脑不怎么轻便~ 普通的 14 寸。懒得带出去 - -. 况且以前自己在咖啡馆看书也总觉得不自在/不习惯。

#6 楼 @jjym 看提交历史, Vim 的活跃维护者似乎只有 Bram 一个人。这次准备改进 Python Binding, 看公告里也说是因为有贡献者提交 patch 的缘故。如果我们希望见到 Ruby Binding 改善，恐怕只能靠自己了 = =

#1 楼 @ugoa 第一点中所说的"工程文件夹"我不清楚是怎样的需求。能具体描述下用例么？

第二点，查找文件我用的是 Command-T 支持模糊匹配。不知道是否适合你的使用习惯。我个人觉得这个算是 Life changing 级的 Vim 插件。也有人喜欢用 CtrlP 不过我没有试过。

第三点，我用的是 Ag + ack.vim. 此前用的是 :vimgrep 命令也还凑合。这是从 :vimgrep 切换到 ack.vim 时的配置变更：https://github.com/5long/dotfiles/commit/add5f0b#diff-1

不过如果懒得折腾，直接用 Sublime Text 也没什么不好的~

回到你下载编译安装时用 make install 安装的源码目录，执行 make uninstall 试试。

#15 楼 @evil850209 不建议这么做。当你 cd 进入一个陌生的目录里，再不小心打错命令，而打出来的命令恰好是当前目录下的一个有害的可执行文件，就会出问题。当然这种情况出现的可能性也并不高。

我的建议是，找到这段代码的原始作者，麻烦他把脚本改成 source ./B.sh 的形式。

更正：发现自己机器上原来是有 dash 的。dash 里写 source ./B.sh 依然不管用。dash 的版本是 0.5.7

需要用 source ./B.sh

man bash 里的解释是：如果第一个参数不带 /, 就会从 $PATH 里面找 (类似于找可执行文件的逻辑). 带有 / 的话才会认为是相对/绝对路径。完整的解释可以看 man bash 测试环境是 Bash 4.2.045

需要指出的是，在 Ubuntu 上，/bin/sh 实际是软链接到 /bin/dash 的。CentOS 上是软链接到 /bin/bash 的。dash 是 POSIX shell 的实现，功能不如 Bash 丰富。但在 source 的逻辑上貌似没区别。

最近写过的最难懂的代码：Vim errorformat

#16 楼 @gene_wu Mod4 + Enter 每次会新起一个 terminal 进程。"呼出"这种需求可能用这个会更合适些：http://awesome.naquadah.org/wiki/Run_or_raise

Travis 的 web 界面：https://github.com/travis-ci/travis-web.

不过不清楚 LZ 所说的"小型 Web 应用"是什么概念...

我们没在用，最主要的原因是分支模型不匹配。

团队旧有的习惯是 web app 项目每天 release 至少一次，release 之前就上 staging 测试。即使人为地区分出 develop / master / release 这么多长线分支，彼此间的代码也往往是很快就同步一致了。当你只有一个长线分支需要考虑的时候，问题本身就简单得多。

最终我们采用的流程是：中央仓库只有一个 master 分支，各个开发者从自己的 fork 上发起 pull request，code review 通过就 merge。不约定 branch 名字，也不限定每次 PR 提交的内容，只要 code review 时满意，其它的都无所谓。

花点时间多调研下，选择适合自己的才好。虽然 Git Flow 在博客圈声音很大，对于有些项目确实也很合适，但我们最终还是没去用。Srsly，“开始写代码之前先得按照分类去建 branch”这件事让我觉得实在是浑身不爽。

不对，看上去是 markdown 根本没能被格式化输出 - -

Tip: 配合这个插件，最好装上vim-ruby. 并且按照文件名设置 compiler:

" 在 ~/.vimrc 里
BufNewFile,BufRead *_spec.rb compiler rspec

我一般不写注释... 能用代码表达清楚的绝不写注释。需要写文档才能说清的绝不用注释凑合。

Python is much more selfish.

开发与测试环境可以考虑使用 foreman

生产环境建议用更加成熟的服务管理工具。比如 runit, 或者 Ubuntu 的 upstart

用专业词汇来说应该是为了实现 per-instance polymorphism.

错误信息的意思是数据库 "test" 不存在。

psql 登录时如果不加 -d 指定想使用的数据库，默认会去打开与登录用户名相同的数据库。

所以用 createdb test 或者其它什么方法创建一个 test 数据库，或者每次加 -d <dbname> 就行了

#4 楼 @zzWinD 你所描述的行为我记得应该叫做静态类型。lz 的疑问是"对不同类型的值操作时是否会被自动/隐式转换".

Ruby 是动态类型 + 强类型 PHP 是动态类型 + 弱类型 Java 是静态类型 + 强类型

不过后半句我还是赞同的，在元编程 (可以重载运算符) 的环境里，类型转换是有可能隐式发生的。

参考：http://en.wikipedia.org/wiki/Type_system

Ruby 是强类型的语言。这里只能自己手动转换类型/用元编程的方式劫持 Integer#== 来转换，不过我感觉还是用显式转换来准确表意好些。

#11 楼 @sevk 不兼容的地方还是有一点，但很少，见 Release Notes 里的这部分

#16 楼 @pepsin 我刚才用 rvm reinstall 2.0.0 --verify-downloads 1 结果 gem --version 输出的还是 1.8.24. 可能是因为我的系统没有 pre-built binary ruby, 而是从源码编译的？不过还好，自己升级一下也不难。