没有提交的修改当然不会被 reset 回去了啊，因为你是新建的文件，git 都没有纪录过的，怎么帮你 reset 呢？你不想要这些文件就直接 rm 删掉就好了啊。

什么玩意儿！

#7 楼 @ice_bb 就这张吧……还真不好说是妹子还是汉子……

#8 楼 @swachian @realwol 这跟 rails 没关系，只要用 javascript 的地方就不提倡这样写。所以 LZ，即使你一定要逆流而行，也别觉得“我只是没遵守 rails 的习惯罢了”。

#6 楼 @realwol 暴露过多的全局变量肯定是错误的做法。

另外你说官网上没说这个？上图：

对了，补充一句，如果说有什么值得遵守的规则的话，那就是避免使用过多的颜色，除了黑/白系（包括其灰度级）其他的色彩在一个页面里不要超过 3 个，并且只有一个是允许大面积出现的（主色调），另外一个和它色相接近用于辅助，最后一个和它色相对调用于对比。

这是最保守也是最稳妥的方案，辅助和对比亮色也不是必要的，越简单越不容易犯错。

#10 楼 @bhuztez 坦白讲，没有万能公式。合理或不合理取决于很多因素，比如说你作品的主题呀，涉及的文化背景啊，意图表达的功能啊，涉众的综合风格倾向啊之类的。

具体来说，假设你有颜色 A 和 B，这是确定的且不能更改的，然后你需要一个用来搭配的颜色 C。如果没有任何前提条件，那就像我在之前回复的第一张图里所示，找一个万能中间色最稳妥了，无论是做对比还是平衡还是互补都能起到作用。

但是如果有前提条件，比如说 A 和 B 都是辅助色，目标 C 是用来做主色调的，那么这个时候就要考虑我最开始提到的那些因素了。通常来说，主色调都是偏向于较高饱和度 和/或 较高亮度的，这是为了抓眼球，但也不排除作品本身的风格不适合，所以很难下个定论。

假设只是一般性作品，需要考虑的因素不多，那么就从色环里找一个 分离互补 / 三元 / 相似 配色，然后单独调整辅助色的饱和度和亮度，把主色衬起来即可。关于 分离互补 / 三元 / 相似，我放几张示例图：（主色为某绿色的情况下）

就是这样，色彩搭配是很讲究功能性的，而功能性又是由很多背景条件来约束的，所以不存在万能公式一说。

释一下：这一张是以 LZ 给定的两个基色去选的一个中间色，调整一下饱和度和亮度即可得到 light blue

这一张则是以 LZ 给定的绿色作为基色，用标准的色环寻找的另外两个色

配色这种事情，算法或规则什么的只是确保你不要用了不合理的色彩搭配，但是对于正确的色彩搭配则没有什么定式，在不犯错的前提下大胆尝试吧，逐渐提高自己的色彩敏感度，以后就不需要辅助工具了。

再给补一张以 LZ 给定紫色为基色的标准色环图

#4 楼 @zealinux multi level selection form...

#6 楼 @yuan_yp 别生气，开个玩笑，好习惯慢慢养成，加油

你目前的错误和上传无关啊，paginates_per 应该是一个分页的方法吧？

#2 楼 @chechaoyang 就直说伸手党完了呗

这是惯例啊，以文件系统为例，假设你当前就在 / 路径下，那么你输入 cd somepath 和输入 cd /somepath 得到的结果是一样的。Rails 的惯例也是如此，因为默认的就是 / ，不过最好写清楚，也就是所谓的“显示定义”，这样可以保证任何人都看得明白，不至于产生类似你这样的误解。

自某版本开始（大概是 2.0，记不太清楚了），Capybara 不再支持除 Feature Spec 以外的测试里使用其内置 DSL，而你这个很明显是 Request Test，所以会报 undefined method 'visit'。

如果你要跟着书来联系，那就使用和书里一样的版本，这就是我提醒你 Capybara 版本的意思。

注意一下 Capybara 的版本

这不是在 IDE 里面吗？追一下看看咯

PostgreSQL 的 role 不对，如果是 Mac 系统，默认的 role 是你的系统用户名，去改配置文件。

个人看法不一定正确：

Feature Test 是测试一个完整的功能的，而且是偏向于从用户交互的角度来描述。往往是从用户的输入开始，到反馈给用户的输出结束，隐藏中间的，特别是系统内部的处理过程。

按照我个人的习惯，楼主给出的例子我觉得就不是太合适，输入是好的，因为操作的目标都是 UI 的元素，但是输出却是系统内部的，实际上用户并不知道也不会关心 change(Topic, :count).by(1) 这一步。

更恰当的测试应该是检查 UI 上能够反映出计数加 1 的地方，比如说某处显示的帖子总数之类的。我感觉 Feature Test 比较接近于常说的验收测试，这从 RSpec 和 Capybara 在前一段进行重构当中可以明显体现出来（Capybara 不再推荐用于除 Feature Test 以外的测试）

Request Test 则是去除了和 UI 相关的部分，测试的目的是为了覆盖从用户发起请求到系统响应结果的全过程（单一功能的），这期间会包含 controller 的部分是很正常的，但是粒度不必很细，而且也会包含其他的部分，比如 routes，有的时候还会涉及外部服务

Controller Test 就是测试只和 controller 内部处理逻辑相关的单元测试，往往不一定是按照具体的功能划分测试的范围，而是按照方法的调用次序或彼此之间的依赖关系。

如果把各种测试平行来看的话，真的会觉得不好区分，所以个人看法是重点理解不同测试所关注的层级不同，因此测试时的范围、代入上下文，操作对象、期望值等等也就各有不同。从开发者的角度来看，很多测试可能说的是一会儿事，但却是从不同角度或不同粒度来进行的描述，所以如果你觉得重复了，要么尝试从不同的角度来看待你要测试的东西，要么暂且放下，等有了核实的“视角”之后再来。

单纯追求测试覆盖率指标是没有太大必要的，对于设计和实现良好的应用程序来说，测试能覆盖比较关键或比较复杂容易出错的业务逻辑就可以了，毕竟测试不是万能的，有的时候问题往往出现在非代码层面，比如说业务分析错了，或者系统设计得不够好，这个时候你的测试覆盖率再高也无济于事。从这个角度来看，假如你无法从个角度和层级来描述清楚你要测试的东西，那很可能你需要倒退回设计阶段仔细考虑清楚自己有没有把这个“东西”想清楚了。

#2 楼 @jiyinyiyong 恕我直言，你的问题就是想太多。

Responsive Design

#6 楼 @cqcn1991 你是不是已经付过费的老用户？貌似这个打折只给新注册用户用的。

#4 楼 @jjzxcc 我很好奇，那在你的屏幕上，顶部是个啥呢？还是说你全屏了 ST2? 还是 ST2 inactive，然后你想直接点击菜单？

#10 楼 @skandhas 是的是的，还好我需要做的都是固定节日，谢谢~

#7 楼 @bhuztez ok，我大致明白了，谢谢。

#4 楼 @skandhas 也就是说，当用户点击某天的时候，我用算法将其转换成农历，然后用这个农历日期去数据库里查对应的节日，而这个节日是我预先手动输入到数据库里的，对吧？

#3 楼 @bhuztez sorry，我不是伸手党，你说的这个我当然查了，我也知道了阴/阳历相互转换的算法，但是我的问题明显不是针对这个……我是想知道对于那种没有现成历法记载的纪念日，我要怎么把它搞进手机的日历里？自己写什么数据格式吗？

#1 楼 @bhuztez 什么历法？能详细点吗？比方说如果现在请你做一个如图一样的应用，你会怎么下手？从哪里获得数据？怎么转换？

#10 楼 @lufeihaidao 对啊，就是看他们在论坛上说的。你知道，参加这个课程的人有很多是第一次接触命令行的，什么 vim, emacs, nano...对他们来说几乎没有区别，相比而言自然还是 nano 更可用一些。这也不奇怪，毕竟这不是一门纯技术的课程。

#6 楼 @Teddy 你不用 emacs 也不拦着你啊，呵呵……我看第一次作业好多人都是 nano 写的。

心疼啥，金属机身就是这样的，摸着热才说明散热正常啊。