def build_calculator(attr)
->(m, item){ m + item.send(attr).to_i }
end
item_list.reduce(0, &build_calculator(:a1))
item_list.reduce(0, &build_calculator(:a2))
item_list.reduce(0, &build_calculator(:a3))
item_list.reduce(0, &build_calculator(:a4))
item_list.reduce(0, &build_calculator(:a5))
这样就正确了,并且简洁了许多
#79 楼 @springles 它这个搜索是 js 实现的,你自己改造下吧
#77 楼 @springles 使用浏览器自带的文本搜索,Meta + F 键
#17 楼 @fresh_fish 像 QA 一样测试
#14 楼 @hooopo 我给个例子吧,首先不要把 proc 或者 lambda 看成方法 (虽然 proc, lambda 可以像方法一样调用),proc 和 lambda 是一种数据,容易理解的场景是构造一个方法,调用此方法返回一个 proc 或者 lambda, 然后再将这个返回的 proc 或者 lambda 作为参数传给其他方法使用。
我有一个 item_list = [item1, item2, item3, item4, ....], item1, item2, ... 都是 Item 类的实例,Item 有 a1, a2, a3, a4, a5 5 个属性,我现在需要统计 item_list 中 a1 的和,a2 的和,a3 的和,a4 的和,a5 的和,常规做法是,
item_list.reduce(0) {|m, item| m + item.a1.to_i}
item_list.reduce(0) {|m, item| m + item.a2.to_i }
item_list.reduce(0) {|m, item| m + item.a3.to_i }
item_list.reduce(0) {|m, item| m + item.a4.to_i }
item_list.reduce(0) {|m, item| m + item.a5.to_i }
如果运用 lambda, 我们可以这样做,
def build_calculator(item, attr)
->(m, item){ m + item.send(attr).to_i }
end
item_list.reduce(0, &build_calculator(item, :a1))
item_list.reduce(0, &build_calculator(item, :a2))
item_list.reduce(0, &build_calculator(item, :a3))
item_list.reduce(0, &build_calculator(item, :a4))
item_list.reduce(0, &build_calculator(item, :a5))
我这个例子比较简单,体现不出 lambda 的优势,如果 reduce 的过程比较复杂,使用 lambda 就可能有优势了。
这三个还算不上毒瘤,在 Rails 社区中奉为圣旨的 TDD, 滥竽充数的测试才是大毒瘤
#71 楼 @mingle5566 哈哈,谢谢
#70 楼 @wangyuehong 我个人还是认为使用 markdown 写文档好些,一方面 markdown 对人类很友好,容易学习,另一方面 api 文档不单是文字,还有代码,图片等内容,使用 markdown 可以很容易添加这些内容
#64 楼 @flowerwrong 打个比方,甲和乙是父子关系,甲开了一个健身馆 a, 甲去健身馆 a 锻炼减了 10 斤肉,你不能认为乙减了 10 斤肉,甲减的 10 斤肉和乙没有任何关系,当然乙也可使用甲的健身馆 a 锻炼,也可减 10 斤肉。
#59 楼 @reyesyang api-pagination 这个东西不错 , 我收获也很多
#57 楼 @join 我上一家公司曾经遇到这样一个事故,好几台部署了某个 java 服务的服务器经常内存耗尽导致服务崩溃,开始以为是 rails 导致的因为上面也部署了一些 rails 应用,并且大家习惯上认为 rails 性能低下,所以都去检查 rails 是不是出问题了,后来发现是 java 导致的,事故的原因听其他同事讲是每来一个请求,java 都开一个线程去处理这个请求,但是这个请求后面有些写的很复杂很低效的 sql, 然后这个请求就一直耗着,线程一直挂着,内存也得不到释放,理论上只要机器支持,java 这个并发量可以做到很大,但是在这种情况下,这种所谓的数据上光鲜的大并发不但没有什么用还是有危害的,因为此时并发越多,挂住的线程越多,就会越快把服务器的内存搞光。我看了你提供的链接,说实话我认为这种温室里的性能测试没有什么价值。
另外我们自己做基于 eventmachine+rack 的 api framework 能轻易的达到每秒上千的并发
我很好奇你们是如何测试的,如果在真实的生产环境下你们测试能达到上千的并发,我觉的很了不起,如果你能提供代码 (可以把涉及商业机密的代码去掉) 或者写篇文章介绍下就更好了。
#46 楼 @feng88724 使用 jbuilder 模板,主要基于以下三点考虑:
经典的 MVC 模式,即 Model-View-Controller;
json.jbuilder 和 html.erb, html.haml 一样作为 view 层
零代价使用 rails 提供的丰富的 helper 方法;
json.jbuilder 模板有所见即所得的作用,虽然代码可能会有点冗余,但是易于人类阅读;
比如:
json.user do
json.(@user, :id, :email, :name, :activated, :admin, :created_at, :updated_at)
end
和需要生成的 json 数据结构是一致的
{
"user":{
"id":1,
"email":"[email protected]",
"name":"test-user-00",
"activated":"2015-05-02T07:47:14.697Z",
"admin":false,
"created_at":"2015-05-02T07:47:14.708Z",
"updated_at":"2015-05-02T07:47:14.708Z"
}
}
#35 楼 @flowerwrong 对你写的 spec 代码做了一些修改:
require 'spec_helper'
require 'awesome_print'
RSpec.describe Api::V1::UsersController, type: :controller do
+ render_views
end
加了一个 render_views
, 这样 response.body 就不为空串了。
和请求头加不加 Authorization 没有关系。
render_views
的问题你可以参考 https://www.bountysource.com/issues/9210089-rails-test-log-says-my-templates-were-rendered-when-they-actually-weren-t
#35 楼 @flowerwrong 没有,晚点试下你的代码
#16 楼 @flingfox63 以后有机会还是试试用 Rails 写 API,其实写 API 和平时开发 web 是一样的,没有必要再引入其他的框架去单独写 API,另外 Rails 的路由非常棒,通过路由你能够了解一个复杂项目的脉络。
#13 楼 @lithium4010 避免生成重复的 authentication_token
#6 楼 @chanshunli 同学有啥问题发我邮箱哈,[email protected]
9:30 - 21:00 * 6 你这个是招合伙人吧
形成一个真正的可动态创建角色与资源的系统
@lyfi2003 对这点存在疑问,从你目前提供的代码来看,如果增加新的权限,还是需要在 Resource 里手动添加权限,而不是直接从数据库里读取权限。