如果你用 homebrew 安装管理的 git，那就好办多了啊，brew update; brew upgrade git

#2 楼 @yangxing_star 醒了就没有压力了？如果不是，那醉那么会儿又有什么意义？不过是自欺欺人罢了。除非一直醉。

#4 楼 @ruby_sky 你说的那是园艺工作者，他们是修剪师胜于栽培师。比如说农场里种植经济作物的园丁可不会为了整齐美观好看而去减去突出的枝，倒是有可能会因为某些枝干遮挡住了大部分的阳光而把它们修剪一下——是修剪，不是根除。

#11 楼 @chucai ……你贴错了选项吧？这个选项实在是和 vim 没啥关系。倒是有一个 Vintage 的插件在 ST 下开启之后可以支持一些基本的 Vim 操作。

你是对的，听老大的，老大错了，也会改的，并且以后，对你另眼相看的，哈哈……

Agree.

从来都是用最原生的方式写 view，顶多换个语法……糖吃多了不好。

#8 楼 @chucai 不明白，把 line_ending 改成 unix 怎么就结合了二者的优点了？

看到这才反应过来原来 LZ 是手敲四个空格啊？我还以为都用 softtab 来着……

#3 楼 @zjtxlly 你把 Rails 的源码拉下来，在里面一搜就知道了：https://github.com/rails/rails/blob/dbc6ce3d6f2580df41fee4f4a663f5a81943de20/railties/lib/rails/generators/rails/app/templates/Gemfile

呃，出错信息不是已经解释了吗？请看：rvm help autolibs，不能太依赖 wiki 哦，wiki 做个参考知道该做什么，具体的细节还应该以官方文档为准。

#27 楼 @aptx4869 我想你忽略了一个很重要的前提，那就是你假设所有看文章的人都像你一样明白这背后的道理，这恰恰是我们撰写这个系列的目的。你明白就能代表其他人也明白吗？

关于 CoffeeScript 的问题，我们就没有打算谈及 CoffeeScript，我们只是在讨论 ECMAScript 里的特性，无关于用什么方法写。我当然知道使用 CoffeeScript 有诸多好处，我也知道 CoffeeScript 现在大受欢迎，但是你应该明白 ECMAScript 是标准，但 CoffeeScript 不是，我不可能在这样的一篇文章里对大家说：别问我上述哪些问题的答案是什么，一句话——用 CoffeeScript。

我说的是严格模式自身，你说的是 CoffeeScript 可以避免严格模式所带来的坑，这其实根本就是两个话题。你所推荐的 CoffeeScript 可以作为一个很好地补充，或者说进阶阅读，但不能直接替代开发者对于严格模式的学习和理解过程。CoffeeScript 就像一个黑盒，帮助大家把这些问题隐藏起来，像你这样知道其所以然的当然觉得大题小做，但还是那句话：你明白不代表大家都明白。

或许你所在的团队人人都用 CoffeeScript，这当然是好事，但还有太多同行企业的程序员们（后端出身）连基本的 JavaScript 都写不好。尽管 CoffeeScript 很好，可是你极力推荐人家却未必愿意或者能够接受。更不要说还有多少项目存活在 <= IE9 的环境下，你知道升级浏览器之后要处理多少 Legacy Code 吗？

我写的的确不好，我正在反思和修改中，但并不是你说的这些原因。Anyway, thanks for your feedback.

#21 楼 @aptx4869 那你应该看看我正经的那篇，"use strict" 并非只是这么简单。

#16 楼 @blackanger 好吧，可能蠢字难听了点。不过在我看来，贪比蠢差劲~

#9 楼 @liwei78 OK，我明白你的意思，我也是有点放纵过头了，谢谢。

我回过头去重新读一下，和之前那篇相比，改写的这一篇的确在 JavaScript 的历史上扯得太多了，迟迟未能进入严格模式的正题，看来还是驾驭不足啊——得改。

#7 楼 @bhuztez 这么说也是……我也挺纠结的。原本第一篇是想讲一下关于严格模式的话题。为什么要 "use strict";？怎样使用它？它是怎样工作的？在现实中，特别是在较大规模的项目中如何正确的实施严格模式？

实际上严格模式的使用还是挺简单的，但是很多 JavaScript 程序员不喜欢用，或者说没有养成习惯去用它；而另一方面，这些 JavaScript 程序员又对一些新特性十分喜爱，迫不及待地要在自己的代码中去使用——然后，问题就来了：你如何确保自己尝试的新特性是可靠的？是能够满足项目开发所针对的目标客户端环境的？

本来严格模式的目的就是帮助程序员确保这一点，然而会用和善用严格模式却需要程序员对它的来历要有一定的了解。之前也提到过这个系列所涉及的每一个话题都是“对不求甚解者无爱的”，也就是说并非完全针对菜鸟和伸手党而撰写的保姆帖子。因此，你要讲的透，又要讲的简单而不枯燥，这的确有些难度。

请问大家，本篇中出现的这些名字会让大家感觉压力山大吗？如果会的话，那我要看看是不是还得阉割一些了。

#3 楼 @luikore 另外也从这些曝光和宣传中吸取了经验和教训，不断磨练着自己的专业技能……

#5 楼 @liwei78 你说的正是我担心的，发展情节从另一个侧面来看就是会引入一些不必要的描述。增加趣味性和保持简练是一对很难平衡的矛盾呀。我还是得小心不要扯太远，谢谢。

#3 楼 @liwei78 所以？你的感觉是可以接受，就是角色不够丰富？

让我想一句话：不是骗子太聪明，而是受骗的人太蠢……（不是说楼主，泛指受害者）

前段时间看了个报道，说魔都对于伪冒银行，公安等机构电话骗取钱财等行为曝光和宣传的力度不可谓不大，但是受害者的数量却一直在持续增长。

这意味着什么？

#1 楼 @Blues 是的，讲 JavaScript。我明白你的意思，因为改写的这个只有半篇，没能把正经那篇全部改完，我是来看看喜欢严肃风格的和轻松风格的，哪一种更容易让人接受。

另外，不用担心干货的问题，这只是第一集，纯属热身，没有去探讨技术细节的打算。

#21 楼 @dume2007 dreaming...

#13 楼 @raven 用表格……这是王道

优雅降级呗，谁说兼容 IE6 就得放弃 CSS3 了？

RSpec 可以帮助我们从不同的层级来编写测试代码，这其中 feature spec 是非常接近于验收测试的一层，而验收测试的要点就是（尽量）不牵扯底层的逻辑，（尽量）模拟用户的交互来涵盖一系列的系统内部的实现。换言之，在观察 feature spec 用例的时候，应当看不到明显的底层代码（无论这个底层的层级有多低，view -> controller -> model ...）

之所以加了“尽量”两个字，是因为在现实情况中完全不去碰底层的业务逻辑也比较困难。好比你这个例子，要想测试“用户在访问 "/photos" 路径的时候能看到 "photos" 的名字，那么至少也得先创建一些 "photos"。所以一开始你去 create_list 是没有错的。

问题在于后面两个部分，我们分开说：

visit photos_path 可以改成 visit '/photos'——如果你的 routes 是这么映射的话——因为验收测试往往是给非开发人员，比如专职的测试人员，甚至是上司或客户看的（在这个层面上，Cucumber 的语法更合适一些）。对这些人来说，他们很可能不懂 Rails，他们也不关心 photos_path 到底是什么。在他们的大脑中，对于这个测试的理解是这样的：

假设目前系统内有 3 张相片，那么当用户访问”/photos" URI 的时候，应该能看到这 3 张相片的名字。

因此，visit '/photos' 更加清楚，更加明确。在 feature spec 这个层级上，测试并不关心像 '/photos' 这样的路径在底层是如何映射的，这就是（尽量）不牵扯底层的逻辑，或者说不暴露底层的实现细节。

再看第二个部分：

photos_list.each do |photo|
  expect(page).to have_content photo.name
end

可以写成（我假设了 FactoryGirl 里相片的名字）：

expect(page).to have_content 'Photo 1'
expect(page).to have_content 'Photo 2'
expect(page).to have_content 'Photo 3'

你没看错哦，就是这么直白的写法。如果你觉得不够优雅可以 ['Photo 1', 'Photo 2', 'Photo3'].each { |name| expect(page).to have_content name } 这样包装一下，不过测试代码更偏向于简单直接，适当的 repeat 完全可以接受。再说这个用例本来的目的就是为了证明访问 '/photos' 时可以看到这三个名字，所以这么写完全没错。

最后，你可以把最开始的那句，也就是 let!(photo_list) 提取出去。变成一个助手方法也好，或者放在 background （an alias for :before）也好，而且你无须创建 photo_list 这个变量，因为在用例里根本用不到。这样一来，用例本身就完全不依赖底层的代码逻辑了，输入是访问 URI，输出是页面上的字符，业务逻辑都在黑盒里，用户完全不关心，也不会注意到。

Feature spec 是 RSpec + Capybara 提供的最高层级的测试，也是抽象程度最高的一级（Capybara 为什么要求开发者不要继续使用在 request spec？因为 request spec 还是有点“底层”了，而 Capybara 的目的是操作/查询用户界面上的元素，因此还需要向高抽象一层，于是才出现了 feature spec。）。若是践行测试驱动开发的理论，那么应该先从这一层开始，然后更随其失败的提示，随着细节的逐步深入，再用更深更细的测试去覆盖系统中不同层面的代码和业务逻辑。

#2 楼 @dddd1919 中文是这样的，一般来说我不写纯中文的应用，也就是说我不把中文直接写在 views 里或 helpers 里。因为 Rails 提供的 I18n 相当简单，所以哪怕我的应用只有中文版，我在开发的时候也是做一个英文版，然后用 I18n 的方式变成中文版上线。

好处？测试的时候我完全不关心页面上显示的到底是中文还是英文，而是直接用 I18n.t(key) 的方式去获取页面上的文字，根据 locale 的设定，无论任何语言都是通过的。

参与开源项目并没有什么特定的“加入方法”，一般都会被称作是“向开源项目贡献代码”。最简单的方式就是写代码然后提交，被采纳之后你就等于“加入”了这个开源项目了。不过有点规模的或是组织良好的开源项目一般不会随意接受提交的代码，除了代码本身的质量以外，还要看你是否遵循了开发者的一些约定。这些约定通常都和代码风格，提交流程，测试，文档等细节有关，你可以通过查看 README 或是 CONTRIBUTION 文档来得知细节。

总而言之，没有什么放之四海而皆准的方法可以照搬，选择一个你感兴趣的项目，之后还是多和项目的领导人及其他成员多多沟通吧。

find("option[value='rock']")

这个会找到你的第一个 option，或者直接找 text 也行：

find "Rock"

担心找重了，就善用 within，比如：

within "#obj_category" do
  find "Rock"
end

#2 楼 @Victor 我去……要不是你 @ 我，我都把这篇东西忘了……刚上去一看没想到这么多人喜欢呢。其实我还没写完，真有点不好意思。等手头的项目抽身出来就补完吧，汗~

反正每次操作系统升级都会有类似的抱怨，过一阵子都会烟消云散……