其实应该谢谢是如何认识，如何介绍自己，如何让对方觉得你就是那个人……总而言之就是加入的历程，这个可能会更有看点。

你是不是不能通过 https 协议访问 github？随便找一个 repo，复制 https 协议的地址 clone 一个试试。

标题党啊~后半句咋就不说了呢。

#2 楼 @xautjzd 任何能跑 Node 的服务器都可以托管，官方的托管再等一两星期。

#3 楼 @bwlinux 告诉我你用的什么 scheme，我先看看能不能排除一些原因，我也用 7.4

#15 楼 @larryzhao Login Session

#7 楼 @larryzhao 这个其实我之前也回答过了，真相在这里：

这是我的 .zlogin 文件的最后一行，它会追加 .zshrc 的 $PATH 设置（因为它最后执行）。

虽然我没有遇到你说的冲突问题，但是我曾经为 ./bin 的问题大伤脑筋，后来还是看了 rbenv 的那篇文档 才解决的。

#11 楼 @cassiuschen 你说的是包，他说的是 node 版本切换，有差别的。

#2 楼 @waitingaminute 你肯定输错了……

#3 楼 @larryzhao 哦，这才理解你说的。是两个都切换过版本之后 RVM 会报警是吧？

不过你有没有注意我的第一张图，其实最前面的路径不是 RVM，而是我自己定义的 ./bin，有意思的是 RVM 并不会因为我抢占了它的位置而报警呢。

直接 rails g migration add_data_to_p 就好，项目路径下执行即可。

#6 楼 @iBachue 是不是因为 CRUD 的惯例名称是：create read update destory？

$PATH 的结果

$PATH 的设置

nvm 的路径是否在最前面都无所谓，因为只用 node.js 才需要它，除非出现重名的可执行命令，否则不会有什么冲突。

rvm 的加载路径搁在最前面就好了。

你的问题是：为什么 nvm 和 rvm 会抢？我不是很理解这是什么意思。也许你把你相关的设置贴出来会更容易帮助我们理解问题发生的背景。

最佳实践原则肯定是在统一的地方设置 $PATH，而不是把它散落在许许多多配置文件当中。

BTW，rvm 的启动脚本我放在 .zlogin 中，加载的优先级高于 .zshrc。如果是 bash，那就是 .bash_profile > .bashrc。在 rbenv 的 Github Wiki 里有一篇很棒的文章介绍了它们在不同操作系统环境下加载的优先级顺序，或许会对你有帮助。

哪里看不见了？没觉得啊~

#21 楼 @liwei78 恰恰相反，URI 的最主要目的就是资源定位，你描述的清晰简洁无论是对用户还是对机器（搜索引擎等）都是友好的。/p/1 这样的东西并不能直接表示资源是什么，也许是 people？也许 products？好的 URI 设计一定是不需要猜的，这就是为啥提倡 RESTful 的原因之一，当然它不仅仅是表述清晰更重要的是描述了一套构造资源定位地址的模式。

#20 楼 @chairy11 别介意，我就是这么一说，其实别人怎么说我还真的无所谓。

头像、待遇……谢谢。（我觉得大家可能都学会了）

我用第三方的账号登陆创建一个用户并关联起来，但是没有用户名，给用户一个后台（或者直接提示他）补充他想用的用户名。

#15 楼 @chairy11 我赞同你的意思，不过大家最好学会准确用词。如果你说我“这个人很简单”，那么我可以很容易的理解你说的意思，是褒义；但如果你说我“头脑很简单”，那我就觉得你是在小看我，或者说你完全不懂我的思想。

可惜的是那些回帖里好多出现“头脑简单”这类的比喻，所以我只能那样去想了。

你指的前端生成是说 models controllers routes views 等等目录对吧？看不明白你说的 生成方法 没多大区别是什么意思。

不过你要知道，即使用了 Ember.js，你写的还是 JavaScript，这一点并没有发生改变。改变的是什么？组织代码的方式。这一点是所有 MVC 框架的精髓，无论是前端还是后端的框架。

组织代码的方式将决定你写的代码有多么好读懂，多么好修改，多么好扩展……等等等等。所以你想知道是否为了减少 Ajax（假设你说的是执行 Ajax 要写的代码），可以说是的。但这是通过改变代码组织的方式所带来的作用之一，而不是使用 MVC 框架的目的。

如果你的项目不会写太多的 JS 代码，尤其是结构不会很复杂的情况下，也许你用不着像 Ember.js 这样“重”的框架。因为当代码总量比较少，应用逻辑比较简单的情况下，MVC 框架几乎不会对你改善代码有任何帮助。当然了，如果你的应用以后会扩展，会变得越来越复杂，那么从一开始就选用 Ember.js 会是一个比较好的选择（AngularJS 也不错啊，不过它们俩非常不像）。

看那回帖好多人都说 IT 男头脑真的很简单，很好玩……我就想，这是不是有种地球人看待外星生物的感觉……是不是每当别人这么看待你的时候，你的心里其实一万头草泥马飞奔而过，心说：你丫懂个屁~

@count += build.count

这是第一级，进一步简化/优化，楼下接上~

#6 楼 @gene_wu 使用 Vundle 的话，如果你想停留在某插件的特定版本，你可以输入 repository 的 url 地址，配合 branch tag 啥的，你也可以按自己的要求决定是否升级某插件。

这个的好处是，配置一次，永远生效。以后只需要 BundleUpdate 就好了，Vundle 不会越殂代疱的。

不过我觉得没必要这么做，插件的升级一般都是为了解决 Bug 或配合新功能，除非你用老 Vim 一辈子不升级，否则有什么理由拒绝插件升级呢？

第 1，2 两个问题很早，差不多 15 年前；剩下的问题都是最近两年。

#5 楼 @Levan 第一，你到底要用 MacVim 还是 Vim？你看的文章之所以要安装 Vim，是因为作者时常两个换着用，这一点他已经写得很清楚了。所以如果你不需要用 Vim，你可以不装。

第二，没必要用 dupes/vim，因为 Homebrew 已经有了最新的 Vim 7.4。虽然这个版本的源并不是官方的源（Google Code Hosted），但并没有什么不好的地方。所以你一定要装 Vim，那就在装好 Homebrew 之后直接：

$ brew update  # 更新一下 Homebrew
$ brew info vim # 确认一下 Vim 的信息，应该是 7.4.xxx 无误
$ brew install vim

你看的教程写于去年中，都过去一年多了，要与时俱进呀！

附张截图给你，Homebrew 默认的 Vim，我装的就这个。

还有 MacVim 的（对，我和作者一样两个都用，不过我用 Vim 比较多），都是默认的，你用不着 tap 其他的配方：

就是这个啊，改成这个就可以了

url 'https://vim.googlecode.com/hg/', :tag => 'v7-3-617'

这是说，手动修改 Homebrew 的配方（文中用的是 homebrew/dupes）以指定你的 Vim 的源代码来源（url 是 Google Code 的源代码库，这是 Vim 官方的）及版本。

话说回来，Homebrew 默认的 Vim 作者为啥不用？都已经 7.4 了。

这个还真没啥问题……用了一周多，暂时没什么坑。

小学二年级……大概我还在玩泥巴呢！