不要怕，好东西说服大家用啊。

直接 html, 要改的时候收维护费。

比 PHP 慢一点完全可能，但慢到你能够感觉到似乎不太可能，毕竟这种纯粹内存里的操作都是非常快的。

贴代码、运行时间和数据量吧。

我只想说，你要考虑得太多就啥事也做不成。

前端和后端的验证完全是两回事，后端永远不能相信前端。前端验证的重点不是阻止非法操作，而是提供出错的友好界面，不论错误信息来自前端还是后端。后端验证阻止任何不符合要求的行为。

@luffycn Google is your friend http://www.freshbooks.com/addons/rightsignature

一个个 attributes 比较实际上测的是 schema，你不需要每个测试都测 schema 啊。

比如你要测某个 action 是否返回特定用户，查看 id 就够了，这样测试也很容易读。测修改用户名的 action, id 和用户名就可以了。

@Victor 太客气了，可不敢当什么汇报，大家都是交流讨论 :) 我觉得你的总结很精彩，学到了很多。另外，关于管理的问题，确实分散了不好找，有一个土办法就是尽量写全名，而且名字尽量长一点点和特殊，类似于asn_twiiter.location, 这样 ROP(Regex Oriented Progamming) 就好用啦 :)

@posebear1990 这是 CSS 的惯例，无区别加载。

你可以用 media query 把所有的 nav_m 内容包裹起来再正常打包。按惯例写，不要 hack。

这个是个很快的题，我觉得不需要弄得这么复杂，有些 over engineering 的感觉。你的元编程太元了，其实不太好懂，后续维护不那么容易。而且 Codewar 貌似是不能写 class, module 的，这个答案本地可以过，网上过不了。

我想出题目不仅是考察你写代码的能力，更多的是看你的思路，看你的代码风格能否融入团队。如果一个简单问题需要很 fancy 的方法来解决，可能这个答案也不是出题的人所喜的。

可以有多个屏，但只有一个脑....

@nightire 就是因为场景多，所以应该有抽象。一般都用库，要么自己写简单抽象。楼主的场景是处理服务端数据这一块的业务代码，在这里如果你需要写这个就说明抽象不够，代码重复的可能性高。这些 low level API 当然必须知道，但知道并不意味着你必须要写进代码中。

@hooopo 非常感谢！

楼主能否介绍几本相关的书学习。

传输都是文本，前台也需要 parse 的。

自己到 chrome 的控制台试一下就知道了。

JSON.parse('{ "label" : "Chrome" , "data" : "2" }')

另外，前台一般都不需要碰触这么 low level 的事情。就算是 jquery 都可以完美处理。你如果需要写 JOSN.parse，说明你的代码肯定有问题。

那个 Rubype 在每个 method 下面都加那么一行，看着就醉了，还真不如直接写 Java。

就你的具体问题来说：

wft这个方法确实可以加一点说明，因为 float 非常规。但是，与其写成无意义的参数名wft(A, B)加说明，不如直接写成wft(foo_string, bar_float), 这样不用任何说明别人都能看懂。

关于process(id)，如果这个方法是你写的，而你估计有可能出现 id 为 string 的情况，你应该在方法的首行加一个保护， id = id.to_i。如果基本没有这个可能则不用麻烦。

如果这个方法是别人的，直接传送 Fixnum，无须顾虑。参数写了 id 就已经表明了作者的意图是接受 integer。如果不是，你可以去批评他。

@dandananddada 是的，不过在你做出了可接受的改变后就应该做一个 commit。

git reset --hard

长知识了。多谢！

多图可以，稍改一下前后台，前台表单提交 array 后台再一个个地处理就可以了。

不过我不建议你这么做。实现容易，但错误处理要多费相当的功夫，包括前后台。而且数据多了更容易出错。

最简单的方法是每个 file_upload 一个 form, 然后简单的 jquery 监听 file_upload 改变就立即提交，后台回复 js, 前台更新 dom, 报错或者显示成功。效果和多图提交也没什么区别。用户也没有阻塞，可以继续上传新的图片。Gmail 的附件上传就是类似的 UI。

如果你前端功夫好那就随心所欲了，单个就单个，非要多个也可以多个，都无所谓。但我认为单个上传还是要好些，处理错误容易，UI 体验更好。

@Victor 好，鼓励多尝试 :plus1:

最简单就直接在 Controller 里面了。如果逻辑不多，Controller 也是最好的。

EmailService.send_welcome_email(@user) if @user.save
render @user

@Victor 你不需要和我解释 pub/sub 模式是怎么回事，基本的 pattern 没人不懂。你是看着这个好，没吃过苦头。要想分开责任，直接在 Controller 或者 Service Object 里面呼叫 EmailService 就可以了，单线程里面弄这么复杂是自找麻烦。

@Victor 打 log，各种分析都是非常合适的用途。但欢迎邮件这些是不合适的，原因就在于你说的不属于核心功能，所以你不需要把所有的过程都加在一个请求里面，比如 UsersController#create。你看着代码是分散了，但实际上他们都是在一个进程，一个请求里面实现的。

编造和发出邮件需要时间，这些本来不需要加在#create 里面的。处理邮件过程中可能会出错，那么#create 可能还要想着怎么处理错误，这些本来也是不需要它关心的。

还有一个问题就是调试。本来 Rails 都是直来直去的代码，很好调试，但加入 Observer pattern 调试起来就比较麻烦。

我们处理邮件是用 RM，其他 Sidekiq, delayed_job 也都很合适，这些异步的才是真正的不关心。

@taojay315 进了 model, controller 的正常代码就不能算是非功能性的了。性能之类是确实非常有用，我们用过 sql.active_record 做索引的比较，这个又准又方便。

@taojay315 这种情况确实很多，但我觉得用 RabittMQ 或者 Sidekiq 或类似真正的异步方案才合适。同一个请求里面还有很多收听消息的，太复杂了。我觉得这应该也是 Rails 放弃 Observer pattern 的原因之一。

我个人是不太喜欢在同步代码中引入这些不必要的复杂性。在 Javascript 里面写消息非常自然，但在 Ruby 里面还是直接呼叫比较好理解和调试。

OrderChargeLogic 的职责就是协调，和其他 Class 互动就是它的工作。好比程序员负责写他那部分的代码是他的职责，但项目经理就这个管管，那个看看，都是在做自己的工作。

网站就是网站，多花些时间在 responsive 上面要好过做不伦不类的 jquery mobile app。