做 SOHO，您是打算做自己的产品呢，还是做开发咨询 + 外包？

扒站利器啊……

#2 楼 @lgn21st 呵呵，道理一致。我更喜爱纸和笔的原因是喜欢那种触感以及各种材质/颜色。不过的确，在工作中白板和笔也常用，都不错！

笔和纸是跨越一切平台的原型设计工具，而且是最好的，没有例外。

Airline 需要 Powerline 的那种打补丁字体吗？我在 Mac 上，装完就是好的，似乎不需要吧？另外我试了下用打补丁字体，也没问题。

• 注册页面弹出的窗口太窄，输入电子邮件看不到全部
• 横过来的瀑布流？！（Chrome Canary）
• 如果系统的目的在于帮助我发现感兴趣的话题，而流推的消息又是由全部用户使用“喜欢”和“不喜欢”干涉的，那么如何保证我的兴趣不会被其他人的动作影响？换句话说，如果一万个人喜欢篮球，一千个人喜欢足球，那岂不是篮球肯定胜过足球在流中的地位？

#45 楼 @kgen 我本来就想说一句：喷脏话不好。你们看看是谁跳出来大喊“别不让人说话”，不就明白了吗？

#20 楼 @hooopo 但人家放出的开源代码大部分开始有测试的呀，现场的视频里或许在开玩笑也不一定，要么就是说前端不怎么写测试？

#30 楼 @xhj6

关于 $ -> 能不能用

你上面给出的两个方法已经是可行的了，我不知道你转到 Rails4 的项目是什么时候，但早在去年 11 月初，我看过 Railscasts #390 之后就用过这两种方式。没错，中间也遇到过一些小问题，但是跟踪一下 Issues 都得以顺利解决。

两个小时的时间，你放弃了。我不确定这算是谁的问题，你？还是 Turbolinks？

另外，JS 是一种很灵活的语言（当然，坑更多），jQuery 也是如此。记不清从哪个版本开始了，使用 .on 方法的 delegated selector 配合 Turbolinks 也能解决事件注册的问题，你可以把：

jQuery ->  # prefer jQuery to just $ personally
  $('#something').click ->
    $(this).doSomething

变成：

$(document).on 'click', '#something', ->
  $(this).doSomething

这比写 jQuery -> 更好。WHY？看 http://railscasts.com/episodes/390-turbolinks 以及 http://api.jquery.com/on/#direct-and-delegated-events

所以总结如下：$ -> 能不能写了？如果你指的是字面意义的 $ ->，的确需要做出改变；但在满足功能的前提下，改动会不会变得很糟糕？那要看你怎么写。语言的作用是选择恰当的表达方式，而不是把嚼了一千次的梗继续当成宝。

在现代 Javascript 中，注册自定义事件是非常正常的事情，jQuery 说你可以写 $ -> 并不代表就不能用别的方法，即使是简单的 $(document).on 'page:load', -> 也没有什么可指责的。

如果你就是较真于能不能只写 $ - >这四个字母，那我只好认输，因为的确不可能比这个更少了。不过这会不会是一个问题，那还得看人。

顺便回答一下你之前某楼的提出的问题，就是说重新加载 css 和 js 的时机问题。事实上你自己也指出了在哪些状况下不使用 Turbolinks 会更合适，所以你可以使用 data-no-turbolink 来有选择的禁用 Turbolinks。

我对 Turbolinks 的看法：

1、如果是小项目，可以使用它；并根据情况有选择的使用，包括怎么写 Javascript，怎么局部禁用 Turbolinks 等等；不用怕折腾，小项目无所谓的；

2、当 PJAX 真正准备好了之后（这不是 PJAX 一个人的责任），Turbolinks 也就没太大意义了，因为根本上它违背了“把更多东西放在客户端去处理”的大趋势，这就是我为啥说它是“临时过渡性方案”的原因；

3、如果是大项目，也就是说 JS 会写的比较多，使用的插件也比较多，项目结构也比较复杂等等……请使用 JS MVC；现今较成熟的 JS MVC 框架基本上都会有针对 PushState 的解决方案，或者干脆先用 Pound Links 对付吧。

关于“态度”

我就是一个认真的人，这无可改变，而且我从未试图去改变别人，我说话的风格向来是：如果 xxx 会更好，对吗？

不要以自己的思维方式来理解别人

我从未试图去理解爱说某些字眼的那种习惯，在生活当中我也经常骂人，但是我有两个原则：

1. 不骂创造性工作，即是它还不够好
2. 不在公开场合骂，因为我在乎影响——对我的影响，以及我对其他的人影响

这就好比我是阿森纳的球迷，我对这个夏天俱乐部的转会动作非常不满，私下里我没有少骂过，但我从不会在论坛或是其他工作场合出口成“脏”，而且我会劝说那些已经这样做的枪迷们。尽管我知道这可能无济于事，但网络给了你“自由开火”的权利，相应的你也应该自觉承担起“清理战场”的责任。

所以对我来说，这无关于我能不能理解那些人——我当然能！然而尽己所能去平衡这个环境，去传播“怎样做可能会更好”对我而言意义更大。

有个东西有人喷，然后又有人不准喷

谁不准喷了？我么？我怎么不知道我有这么大的能力和影响力了？这是不是“受迫害妄想症”的一种症状呢？我还是那句话，我的风格向来是“如果 xxx 会更好，对吗？”即使是我很讨厌的话，我也经常用疑问句来去表达我的质疑，为什么呢？因为疑问句给出的是 options 而不是 commands。你永远有选择的权利，所以请不要说谁谁“不准”喷，因为这根本就是一种“臆测”，毫无事实根据。

思想有冲突才有进步，一味和谐有什么意思呢？

又见和谐论！我不知道在你眼中的“和谐”是什么意思，是不是“一言堂”，“只准州官放火，不准百姓点灯”，“让你说你才能说，打死也得说；不让你说你不能说，打死也不能说”等等之类的呢？

反正我是搞不懂的，每一次我跟别人说：骂人不好，表达自己的观点总有更合适的方式。总会有人跳出来跟我讲：一味“和谐”有什么意思？

那么，我是不是可以理解为：如果你不说脏字，就不能表达出你追求进步的决心和力度呢？

如果真是这样，那咱们以后每次讨论事情的时候不带脏字不允许开口，好吗？

Attitude is on option, you can choose a way or even better.

#11 楼 @happypeter 我可以确认这小道消息是错的。

https://github.com/github/

github 开源的项目都在这儿，不写测试的极少。

#2 楼 @aptx4869 嗯，我的确没试过，也没注意 LZ 要求 Rails4，抱歉了。

#19 楼 @xhj6 因为我一开始说的就是态度，是你在回避态度的问题。从头到尾看下来，我从未说过 Turbolinks 不能批评，我说的是什么有点文化的人都能明白。

你强调 Turbolinks 不能解决你的需求，付出的代价让你觉得不值得。那么我认为对你而言可能是合理的，然而你的需求能代表所有人的需求吗？Rails 每前进一步都只是为了解决你，或者以你为代表的一群人的需求吗？

看起来你也应该是比较了解前端的人了，推此及彼，请问 verdor prefix 这样的东西解决了怎样的问题？满足了怎样的需求？付出了怎样的代价？

如果把 pjax 看做是像 web 标准这样的一个目标，Turbolinks 就好比是 verdor prefix 这样的过渡方案，它完美吗？绝不！它能解决问题吗？可以！它有代价吗？不小！它能满足需求吗？It depends。

它是屎吗？

$ -> 这样的语法 Turbolinks 不让你用？你是认真的吗？你确定？

在现实中我也只会考虑给态度 ok 的人“涨工资”，讨论技术细节也一定会在态度 ok 的前提和环境下进行，否则我宁可把人拽出去吃个饭谈谈心先。

有这样四种人：

1. 有德有才——绝对加钱涨工资，不用你开口要；
2. 有德无才——留下没有坏处，涨不涨工资看进步；
3. 无德无才——淘汰，没说的；
4. 无德有才——这是最可怕的，有多远离多远；

还好，这是网络。

#10 楼 @as181920 其实这问题挺简单的，turbolink 是否干扰你开发了？你是否真的特别赶时间？这俩问题回答了，就知道用不用了。

在我看来，Turbolinks 是一个阶段性的折中方案，或许 DHH 的力推让人觉得他似乎是把“未来的赌注”全压在这上面了——也许——我个人不相信他会这么短视。

Turbolinks 想要在目前这个阶段利用 server-side 的能力来弥补 pjax 在应对跨浏览器兼容性问题上的困境——这不是 pjax 的错误，也并非是想要取 pjax 而代之。因为 pjax 是 client-side 技术，这两者之间原本就没有一较高下的必要。

鉴于使用 Rails 的开发者数量庞大，而他们之中能够轻松掌控前端的数量却又不多——要知道，Javascript 有大部分的工作都用在和浏览器斗争上了——所以 Turbolinks 对于大多数开发者来说是一个代价相对较低的过渡方案。

然而使用 Turbolinks 的确会有一些 gotcha 需要开发者去注意，这也是 Rails 历来的传统和理念：注意一些“约定”。约定未必会成为标准，但却是向标准前进的一步努力，这种过程也是开发届的习俗。比如说 web 标准历经“磨难”的过程，最常见的像 vendor prefix，不也一样被开发者们一边用一边骂？但事实却是，不这么做就不能取得进展。很多东西你指望一步到位，那是一种理想，而不是现实。

如果 pjax 已经足够健壮了，DHH 吃饱了撑的非要给自己找不痛快？事实上，作为一个后端的开发框架，Rails 算是最关注前端，对前端最友好的一个了吧？也许它的一些决定并不能讨好所有的人，但是它让关注前端的后端工程师越来越多，帮助这些后端工程师更少障碍的了解和掌握前端技术的努力却远远要比”讨好所有人“更有价值的多！

世人的浅见啊，少一些浮躁，多一些探索，该多好？不禁想起前日看的小说了一句话：“众口悠悠之中，江郎或有才尽之时；不过在嘲笑于他之前，众生之中又有多少‘江郎’横空出世？”

Turbolinks 当然不算完美，但说它是“屎”也未免太自大了，就算它是“屎”那它也是培育技术和思想进步的“肥料”，总要比随地乱喷的那种有价值的多。

最后，喜欢关注细节的，不妨看看 Yehuda 的一篇积极中肯的评论吧：https://plus.google.com/106300407679257154689/posts/A65agXRynUn

#12 楼 @xhj6 无意在这里讨论什么技术细节，各种方面的评论网上到处都是。我说的是那种不断追求和进取的精神和态度（尽管也有可能是错的，谁能保证永远是对的？）哪一种技术没有被喷过？它们之中有死的，也有活的，但无论如何人们记住的是什么？是喷？还是……？

无论怎么喷，DHH 已经成就了自己，虽然不代表他永远不会犯错，但更不能证明只要喷他（以及他代表那种进取和追求的精神）就能让自己更高明。讨论技术细节怎么说不可以，一定要用某些词才能证明自己的分量不成？

据说艾迪生在确定灯丝的材料之前尝试了上千次？如果在当今这个信息发达的时代，那他岂不是也需要被喷一千次？

我们应该追求被别人“喷”，而不是去“喷”别人，因为在旁人眼里，二者高下立见。

# 1st, In Gemfile:
gem 'compass-rails'

# 2nd, In CLI:
$ compass init rails

就不明白了，技术细节还没有搞懂呢吧就在这里喷屎……当年 AJAX 出世的时候岂不也是一堆屎？或许论及影响力和重要性尚不能相提并论，但毕竟是进步，是创造。人类追求进步的信念和动作，有成功也有失败，也从来没有百分之百的完美，但无论如何，尽享别人创造的人也没有丝毫立场可以大放厥词吧？

如果你现在做个新项目，请习惯使用 expect，RSpec 3 将会移除 should 语法。

#8 楼 @as181920 这些问题若是扯起来就长篇大论去了，我建议三件事情吧：

第一、读一读 The RSpec Book 的书，里面有一部分对于测试驱动开发理念的讲述，特别是 BDD 特点讲述挺好的，比我说的专业；

第二、推荐你看看 Gary Bernhardt 的 DAS 系列视频：https://www.destroyallsoftware.com/screencasts，此人使用 RSpec 作为日常使用的测试框架，但是他很少讲 BDD（不是不讲这个理念，而是不怎么讲这个词），因为在他看来，无论是 BDD 还是传统的 TDD，事实上都应该是 TDD——测试 驱动 开发，重要的不是“测试方法论”而是“驱动”，BDD 只是一种驱动方式，它的“视角”和传统的 TDD 有区别。

第三、找两个规模差不多，质量都比较好的项目，一个用 MiniTest，一个用 RSpec，你亲自去比较一下，体会一下作者在写测试的时候大概是一种什么思路，是什么“视角”。

对于你的瞎猜，我是比较同意的，如果你让别人来看你写的测试，RSpec 会比 MiniTest 更易读和更易理解（前提是看的人对两种框架都不了解，或者了解的程度差不多）

最后，Capybara 是很好的，然而以前在 RSpec 里的用法并不够 BDD，比如说以前 Capybara 可以用在 Integration Test 里，但这个并不太贴 BDD 的理念。所以后来 RSpec 和 Capybara 联手做了 Feature Spec，这个东西就是一个 Cucumber 的简洁的替代品，也是从这个时候开始 RSpec 才真正的践行了 BDD 的精髓，即 outside-in。在以前，outside-in 的最外层只有 Cucumber 实现的比较好，RSpec 的 request spec 则是用“程序员”的语法来描述“用户”的行为。当然，这一点在今天得到了比较好的处理，喜欢 RSpec 的人终于可以不依赖 Cucumber 了（当然一起用也可以）

纠正一句话，不是“涉及页面行为的测试”，而是“涉及应用行为的测试”，因为用户使用你的应用也不一定所有的交互都是在页面上完成的。

举个例子：

我们在 request spec 的时代，这样写请求：

get root_path

现在在 feature spec 里，配合 capybara 这样写：

visit "/"

实际上二者是等价的，你看 Capybara 的 API 里有讲到这一点。但这并不仅仅是写法上的区别，也不单纯是为了用 DSL 套上一层壳，更重要的是，当你写 feature spec 的时候，visit "/" 这样的 API 将驱动你以用户的角度来观察你的应用行为，你脑子里的描述是：

当用户在浏览器里访问我应用的顶层 URL 的时候

而不是：

当浏览器向 root_path 发出 GET 请求的时候

这种理念上的切换会更有助于设身处地的为用户着想，为应用的“行为”而不是“内部实现”着想，这是非常“讨好”开发者的一种举措。

再者，同样的这个例子，你让一个外人（比如项目的客户或直接用户）来看，哪一个他更容易看懂和理解？这是显而易见的。

或许有些程序员会对这一点貌似“换汤不换药”的差别嗤之以鼻，但这就是我说的 Developer 和 Programmer 的区别。RSpec 并不是要阻止你去写程序化的测试代码，它是一种完善，它提供另一种途径，仅此而已。

#2 楼 @michael_roshen

谁说 Rails 的模块不能单独拿出来用呢？而且 ORM 层也不只有 Rails 一家实现的好吧？ https://www.ruby-toolbox.com/categories/orm

#3 楼 @as181920 场景实际上处处都在，BDD 和 TDD 的差别关键不在于方法（很多方法都是共通的），而是在于理念，或者更通俗的说是“视角”，也就是你如何看待被测试的项目的。

我个人的观点是 BDD 是从 TDD 延伸出来的更具针对性的、特化的测试理念，所以 BDD 本身也可以完成传统的 TDD 的功能（RSpec 写 TDD 没什么问题啊）。这种理念的特征就是它更加关注代码的“行为”胜于关注代码的“内部逻辑”。

我们用 TDD 测试类和方法的时候，往往不太关心方法与方法之间或类与类（模块与模块）之间的交互（这是一种行为，它比方法的内部实现关注的层面略高一些），只需要保证内部返回结果符合预期就可以了，传统的 TDD 倾向于分离，避免耦合带来的复杂性和干扰。

但是 BDD 则更关注于系统内部模块之间（甚至是和外部接口之间）的交互过程，以 RSpec + Capybara 为代表的 DSL 的应用更有助于开发者描述这些行为，而且是从“应用”的角度而不是“内部实现”的角度。这一点和项目的规模并没有直接的关系，小项目往往也会有比较复杂的交互行为和业务逻辑。

当然了，RSpec 本身也可以覆盖系统由外向内的各种层级，但测试目标的粒度逐渐缩小的时候，它的使用方法也越来越接近传统的 TDD，所以用 RSpec 配合 MiniTest 也是一种选择（如果你更喜欢 MiniTest 简洁的风格）。

我的水平有限，也不知道讲清楚这个意思了没……总之，我的感受是，当我使用 MiniTest 这类测试框架的时候，我更偏向于程序员的角色；而使用 RSpec 的时候，则偏向于应用的设计者或是使用者，而 RSpec 在“由外向内”层层深入的时候，我的角色也逐渐从“设计/使用者”向“代码编写者”过渡，这种感觉非常自然舒服。

RSpec 为什么会很受欢迎，我想这是因为在国外，Developer 和 Programmer 是两种不同的概念，尽管他们做的事情有很大部分的重合之处，而 RSpec 很好地满足了 Developer 的进阶需求，是的他们能够从“产品”，而不仅仅是“代码”的角度来描述、设计、实现目标应用。

不知道具体情况如何，如果是我的话，我的第一反应是重新规划数据库，规划的时候就想好如何安排旧的数据库的数据。接着写个独立的脚本（不搀和进 Rails）把旧数据读出来、整理好、写进新数据库。旧的数据库应该不会变化表结构吧？所以以后有增加的数据就复用这个脚本好了。

不过这么一来，新项目的模型肯定是要做相应的修改了，因为就没打算把旧模型拿进来直接用，感觉很不爽。

vim 有不少插件能做这种事情，比如 tpope 的 vim-rails + vim-surround

slim（或者 haml）最起码的好处就是不用写 <%= %> 了。。

@person 保存的时候，貌似有一个属性给的值是数字，但是数据库里该字段要求存储字符串，但在模型的代码中应该是缺少了 Implicit Conversion（隐式转换），于是报错……以上都是不负责任猜测 - -

#6 楼 @luikore 每种语言收入的平均值在最低和最高之间相差越 20%，貌似也算合理吧？

研究了半天……才发现自己一直在用 Canary，都到 v31 了，我说怎么没看出扁平化呢！现在弄个 Chrome 来看看啥样了。

为啥不继续 DAS？我觉得就挺好呀~

在中国工作的国际友人吗？顶一下！

#7 楼 @cool8shen 你打错字了吧，active，不是 actiive

#8 楼 @zhurongwell Chrome 的 PDF 预览自带下载功能，用户基本上都知道吧？

Rails4 默认的 session_store 是 :cookie_store，以前用的 ActiveRecord Session Store 被抽取成单独的 Gem 了，所以你需要在 Gemfile 里加上：

gem 'activerecord-session_store', github: 'rails/activerecord-session_store'

之后，可以这样生成：$ rails g active_record:session_migration

另外，你应该修改 config/initializers/session_store.rb，变成：

YourApp::Application.config.session_store :active_record_store`

嗯，应该是这样了……其实用 :cookie_store 也可以。