Sunburst

不过没有直接支持 Rubymine 的，有 IntelliJ IDEA 的版本，Jetbrains 官网上可以搜到，你需要自定义适合 Rubymine 使用。

另外，可以看看这里：http://devnet.jetbrains.com/docs/DOC-1154

Rubymine 5 支持 TextMate 的 bundles，所以你也可以选择用 sunburst for textmate bundle, 然后 mapping 到 Rubymine 就可以。

这里找：http://wiki.macromates.com/Themes/UserSubmittedThemes

#4 楼 @diguage 当然要纠结了，版本变化以后，很多方法都有新的构造和使用方法。比如说你在文中写到 .live 方法，实际上到 1.8 的时候，jQuery 就已经把 .bind .live等方法封装到统一的接口 .on 方法里去了。既然你说的是最佳实践，那当然应该与时俱进咯，否则算什么“最佳实践”你说是吧？

晕……jQuery 1.6 版本

可以，加吧

#10 楼 @yeyong14 呃……怪我说晚了啊？

做开发做了四年还不知道“是否结合实战要好点”？Rails Guide 已经通读过一遍就已经能做很多很多事情了，直接动手写就是了。

rvm pkg install... 已经被废除了，现在 rvm 使用了更智能的方法

首先，升级你的 rvm $ rvm get head

然后，运行 $ rvm autolibs enable，接着运行 $ rvm requirements

这时候，rvm 会自动检测需要的依赖并执行安装，你会看到结果

最后，安装或升级你的 ruby $rvm reinstall all

纯支持~

#7 楼 @heimirror 不客气，也别介意，授人以鱼不如授人以渔，总要学会自己寻找答案的，都得迈出这一步。

#5 楼 @heimirror github...

#3 楼 @heimirror 去看 Issues，如果你很好奇原因的话

export rvmsudo_secure_path=1

这就是提示。

另外，不一定会管用（it depends a lot...），还可以试一下：rvm get head，再看结果。

rvm 的更新很频繁，经常会有很多新的 issues，记得经常查看它的近况。

#20 楼 @zfree ridiculous

#2 楼 @dave OK，是我的错，我没有注意你写的是 responsive web design，我的意思是 Responsive Design 是一种设计理念，web 还没有兴起的时候就已经有它了，现在流行的 rwd 也是在它的基础上的一种延续。

不过你的解释依然很牵强，如果你强调

但前提是在不改变 HTML 结构，改变 CSS @media来完成。

那么你引用扎克伯格的那句话又有什么意义呢？HTML5 和 CSS 的 @media 有什么直接关系吗？既然你对 RWD 的定义就是不改变 HTML 结构，而改变 CSS @media，那你索性直接说 don't abuse to use @media 就完了呗。所以不是我的理解有偏差，而是你的理解狭窄了些。你知不知道用 js 也可以实施 RWD 的？（只不过没有今天的 @media 这么简单）以前 CSS 做不到的时候，很多设计师就是依赖 js 做 RWD，那时候就是以检测客户端然后直接修改 DOM，谁说“不能改变 HTML 结构”了？

看了文章觉得不知所云，有一种“为赋新词强说愁”的感觉。RD 是一种设计理念，旨在不同的视域内提供不同的内容，包括排版、尺寸、内容多少、呈现方式等等。的确有些类型的应用不适合 RD，但并不是 RD 不适合，而是那些应用不适合某些视域。

Basecamp 就是一个 PM 类的应用，尽管移动端做的是 Native App，但同样应用了 RD 的设计理念；假使 37signals 不得不做 web app 或 hybrid app，RD 的理念一样适合并没什么区别。

文中引 FB CEO 的那句话更是莫名其妙，这句话和 RD 之间又有什么直接的关系呢？

我觉得此文的错误就是没有真正理解 RD 作为一种设计理念和其他技术架构之间的区别。RD 不是 HTML5，也不是 CSS3，更不是 jQuery Mobile 或是 zepto 之类的库或框架，RD 可以是上述的所有东西——它们只不过是提供了可以实践 RD 理念的一种工具而已，也可以不是以上的任何东西，早期@media 技术尚未推广的时候，有人就尝试过类似的做法。

不是因为这些工具的诞生才促成了 RD 的风行，而是 RD 先出现才促成了这些工具和技术从各个方面去支持它。

WS 认不出你自己装的 Node 环境，话说设置里面是可以单独添加 Node.js 作为 lib 的，还能够下载源码包作为调试用。

#5 楼 @pityonline 呵呵，谢谢，我知道了。

#4 楼 @cod7ce 你都找到设置了，看一下快捷键也不是很难吧，在 keyboard 里有，我每次都把那些从来不用的快捷键先关掉并删除，所以真心不记得默认是啥，相信很多人都这么做。

#2 楼 @luikore 是是是，我弱智了，shame on me...

#1 楼 @blacktulip 啊！shit！！！我一直在尝试单引号，还在纳闷：我没记错啊……

谢谢谢谢~

#2 楼 @lufeihaidao 不客气，解决了就好，maybe 我了解的也不透彻，我只是觉得可能有这方面的原因。

打开 http://ruby-china.org/topics 看最下面的 节点 列表，node 就是 节点，用来做分类的。

我觉得可能是这样：

1. git clone 可以不用密码，至少证明了 ssh-key 验证这一步你做了。请留意下 git clone 之后的地址，你使用的是 https or ssh or git 协议？如果你试一下 https 协议，若也会问你要账户名和密码，那么请看第二步：

2. 你没有做 password-caching，根据你的截图，vbundle 是通过 https 协议去访问 git repo 的（就是问你要密码的那个），你的本地没有 password-caching，所以会问你要

第二步里的链接已经告诉你该如何做了，试试看是否可以。

#12 楼 @swordray 很新鲜的说法，不太清楚，wikiphdia 没有提到这一点，倒是我在文末贴的那篇博客说的很清楚：CSRF is NOT XSS

CSRF 是 跨站请求伪装，作用方式在 HTTP Request 范围内，当然了伪造请求这件事情可以发生在脚本之中，所以我觉得你说的有一定道理，算是 XSS 的一种。

#2 楼 @sundevilyang 非常讨厌那种部分文字反白（淡黄），点击就会 tweet 的部分：

1. 对于没翻墙的人就是废物；
2. 复制其中的文字特别麻烦，选择其中的文字更是麻烦。

看最后一句，最后一句解决完了更新一下 homebrew，再然后看看 CLI Tools 是不是有新版了，另外把 rvm 本地的 cache clean 掉。一般就是这些问题。

#1 楼 @robbin 我赞同原文里所描述的种种事实，但我觉得没必要提什么“去 Rails 化”的说法，特别不应该在前面加一个“社区”。

我认为“社区”的意义分两个层面：第一，是让处于食物链高端的人们有一个交流、进取、突破、创新的场所。这一点应该是所有社区的终极目标之一，然而这一点针对的恰恰是少数人；第二，是让所有的初学者、入门者、感兴趣的人能够体会到社区的各种好处，比如资料丰富，帮助方式多，热情洋溢等等，这个在少数人看来有点浪费精力和时间，但是如果从整个社群来看，你今天为这群人的付出就像是在为这个社区造血。不为他们做点什么的话，将来有一天高端的那一群人将失去伙伴，越来越孤独，将不再有后来者你追我赶，兴兴向荣。

Rails 的性能从来都不是其骄傲的本钱，这一点好多人都说过，好多人都证明过，但你无法否认它对促进新手接触和学习 Ruby 所起到的决定性作用。不管多少言论和人群在说 Rails 的种种缺点，DHH 一个 15 分钟 Blog，就能让一大群初学者趋之若鹜，兴致昂扬。

为什么？因为两个层次的人目标不一致，追求不一致。当你走过这条路的时候，回过头来你会指出哪里走得不好，哪里走了弯路，或者当初选择哪个会更好。可问题是，你若没有走过，你今天能得出这种结论吗？Rails 提供的已然是走这条路的最佳方案（但不是最优方案，因为最优方案对于初学者往往意味着技术难度，理解能力等方面的门槛）。或许有朝一日，会出现一个性能甩出 Rails 一千条大街，又兼具 Rails 其他种种优点的框架，到那一天不用任何人说，Rails 自然会淡出舞台。

说到趋势，移动的确是趋势，Full stack 的框架过渡到 Web service 的框架也是趋势，然而社区的伟大之处就在其包容性，Ruby 社区从来没有分过 Mobile 化的，No-Full stack 化的，或是 Less-Rails 化的社区，无论什么趋势还是经典都可以有立足之地，容身之所，这不是很好吗？难道一定要为了走得更远的人迎合趋势，就要打出把过去的路变窄甚至封闭的旗号吗？

这不禁让我想起了曾经轰轰烈烈的 Web Standards 的争论，没人说过 WS 不对或者不好，也没人否认它是趋势，但任何人，哪怕是 W3C 这样的庞大组织也无法阻止用户或是其他开发者选择用什么浏览器或者工具。其实没必要这么做，如果你认为某样东西或者某种趋势是好的，你只需要正面宣传，大力推广，努力为其贡献产品和工具，自然就会有人跟随而上；反过来看，凡是举一个必要削一个的，即使本意没错，出发点很好，也会遭致很多人的反感和抵触，并非明智之举。

这篇原文，给 Ruby 社区的一部分人看是非常非常好的，很有启发意义和带头作用，可是对另外一部分（基数很大）却有可能费力而不讨好，我只能说文章是好文章，道理是好道理，可惜不能代表“社区”，或许换一种做法会更有效，比如像 DHH 等人那样做一个积极的推动者。原文后面介绍了其他几个 Ruby 的框架，Sinatra 还提供了一个模板，这就是很积极的举措，只可惜标题太冲了，我估计很多年轻人看了标题就准备开喷了，那些真正有干货的部分能不能坚持读完都让人存疑啊！

#8 楼 @chuanjiabao 哦，英文下是都输出的，那我还真不清楚，我只是猜测罢了，因为我向来都是直接开始 I18n，很少直接工作在英语的语言环境下。因为我觉得 I18n 的测试都 OK 的话，英文也不会有什么问题。也正因为如此，我都是直接对单独的每一条验证进行测试的，我所谓的更细的粒度就是说的这个，因为我一开始就这么做，所以没觉得有什么不应该。不过你这么一说，那应该是 FG 没有测试其在多语言环境下的兼容性，或许你可以提交一个 Issue 给他们呢。

#6 楼 @chuanjiabao 那就是了，你这个算是一个新需求，be_valid 方法只是告诉你是不是 valid，而不负责具体的 error.message，rails 显示最终的错误上页面的时候还有额外的工作，不是一个 be_valid 就可以全部覆盖的，它只是一个验证触发机制。所以你要这么改也没有问题，我只是觉得如果有必要去测试更细粒度的部分，就不应该回避写更细测试的过程，否则的话测试本身是具有一定“欺骗性”的，因为你获得的信息依赖的不是测试代码本身，而是你的 hack。我想 FG 的开发者应该不会不知道这一点，现在的结果应该是权衡之后的选择。