@5long @nowherekai @lyb124553153 谢谢回复,遵循规范可以避免踩坑
我们新的接口已经拆了。
目前还没有权限控制,不过是一个切入点,可能会存在权限不一样的场景。
我和他讨论了可能的问题:
可拓展性变差,如果后续新增和编辑的逻辑变化了,可能会导致两种完全不一样的逻辑混合在一个接口里。
但是这个理由他不太接受。
在论坛里不是吐槽,是想大家帮忙想想这么实践不好的地方,或者告诉我,“这种情况就是很正常的,我们公司也是这样”。
刚发现他之前提交的代码,新增/更新/删除是同一个 url,名称直接就是 handleXXX,请求参数里有一个 type,感觉 type 来区分具体操作类型
话说我之前也见过别的组也有这样的接口,调用的时候没觉得奇怪,可是自己的工程里出现这种风格的代码,还是觉得怪怪的。
可以的啊,Ruby 上手还是挺快的。
Ruby China 的技术氛围非常棒
感谢这类科普文章,赞!
@theblock24block 嗯,我也看到了说法说 AOP 在 Ruby 里实现起来比较简单。
@zouyu 是说 before_action 只能作用在 action 上,AOP 可以做得更细致一些么,比如 method 上?
#5 楼 @flemon1986 似乎File.read
和File.open
两种不同的读取方式,会影响占用的内存不同
我注意到这篇文章中前面几个方法都是File.read
,最后一个占用内存小的是使用了File.open
,似乎这里会有影响。
#1 楼 @easonlovewan 这个是说 CSV 的,感觉文件越大,似乎确实内存会出问题。
我刚翻到一篇博客说这个事情的,是使用 Enumerator 的lazy
方法来避免。
我看到的也是框框 ubuntu 14.04
http://www.pataliebre.net/howto-make-nginx-decompress-a-gzipped-request.html#.V-yKcnV97CJ
查到一篇文章,似乎 nginx 没有开箱即用的方案
谢谢 我昨天在 rails 层已经能够正常解压出来了,中间件那条路一直没走通,在 Controller 层做的解压。
但是如果部署到线上,还是想在 nginx 层做。
想请问下是使用 nginx 的 gunzip 功能么?
#4 楼 @jasl 开发环境没有 nginx,所以就计划写个 Rack 中间件做了。
暂时是这么写的,好像还是没啥效果:
class CompressedRequests
def initialize(app)
@app = app
end
def method_handled?(env)
!!(env['REQUEST_METHOD'] =~ /(POST|PUT)/)
end
def encoding_handled?(env)
['gzip', 'deflate'].include? env['HTTP_CONTENT_ENCODING']
end
def call(env)
if method_handled?(env) && encoding_handled?(env)
extracted = decode(env['rack.input'], env['HTTP_CONTENT_ENCODING'])
env.delete('HTTP_CONTENT_ENCODING')
env['CONTENT_LENGTH'] = extracted.length
env['rack.input'] = StringIO.new(extracted)
end
status, headers, response = @app.call(env)
return [status, headers, response]
end
def decode(input, content_encoding)
case content_encoding
when 'gzip' then Zlib::GzipReader.new(input).read
when 'deflate' then Zlib::Inflate.inflate(input.read)
end
end
end
gzip 压缩的应该是一些图片,我看到网上的一些压缩方式都是content-type "gzip/json"
Ctrl + C