@ghosTM55 期待你的召唤 +1

话说 最近发生什么了，好多都被强了。

@neversion 就是 打开类，添加 或 覆盖 你想要的方法。具体还是看你的需求了

感觉 T800 很难在 ruby-china 上 招到 ruby 程序员了， 要不你们去 python、php 社区试试....

@neversion 一般做法是: 添加 代码 config/initailizers/xxxx.rb 进行修改 gem 一些行为，实现定制。

Nice

当你想 跟踪一个代码的 调用过程的时候，我的思路是

1, binding.pry

2、pry-backtrace 显示调用流程

3、查看 User 的 method_name 的源码位置

User.method(:method_name).source_location

4、查看 User 的 method_name 的源码

puts User.method(:method_name).source

@ane cat /etc/bashrc

source /home/andy/.bashrc

看看/etc/bashrc 有没有 上面那一行，没有就加上，不用添加两次的。

@ane 你 source ~/.bashrc 了没有

将下面一行添加到.bashrc 就 ok 了 export RUBYOPT="-U -Ku -E utf-8:utf-8"

咱们的回复 有点偏离 lz 的本意了，不过既然说到这了，咱们就继续说说 CookieStore 的一个弊端：

如果使用 CookieStore，那么用户对应的 session cookie 就存到客户端，这个时候 也就与服务器无关了，也就是说你即使 logout 了，通过 copy 这个 cookie 还是可以访问 server 的。这个文章有个演示

那么怎么让客户端 cookie 失效呢

解决方法：

1、用户 主动 修改密码，让之前的 cookie 失效.(但是 试想用户主动 修改密码的 频率 实在太低) 2、修改 secret_key, 是所有的 cookie 都失效 (代价太大了，应该直接不用这个方案)

回到 lz 的 共享的 session 的问题：#14 楼 huacnlee 给出了一个大众的方案。

恩 走位很风骚...鉴定完毕

#34 楼，只是一个 建议而已，看你。

@lgn21st 题外话，对评论 按钮 的频率是否 应该做个限制。 比如 我有时候 手快了 多点了一下。就多发了一条评论。

对于 2.Nginx 缓存的 'A. 动态请求静态文件化' 其实可以直接用 Rails 自带的 caches_page(Rails4 已将抽成 gem 了)。效果是一样。@quakewang 你觉得呢？

建议：对于 3 整页缓存 标题 应该改成 action 缓存。因为整页缓存 是 caches_page 的说法

刚才试了一下 Rack::Deflater

siege -t30s -c 10 'http://127.0.0.1'​

                                     使用后              不是使用
Transactions:                 187 hits            242 hits
Availability:                   100.00 %           100.00 %
Elapsed time:                29.03 secs         29.18 secs
Data transferred:           0.39 MB            1.17 MB
Response time:             1.01 secs          0.69 secs
Transaction rate:           6.44 trans/sec   8.29 trans/sec
Throughput:                   0.01 MB/sec      0.04 MB/sec
Concurrency:                    6.51                 5.69
Successful transactions:     187              242
Failed transactions:            0                    0
Longest transaction:          9.16              4.67
Shortest transaction:         0.09              0.09

发现压缩比例 在 77% 左右。

#14 楼 说的差不多。复杂的查询 建立一个trie tree进行，不复杂的话 直接数据库 就 ok，前端这边可以 autocomplete。

膜拜...

先点收藏，然后 点喜欢， 然后来评论， 然后慢慢品味。 话说 很喜欢 这种接地气的 分享。

@Kabie 汗！！写错了....

@Kabie , @larrylv 可以参见#10 楼 在我机器上测的结果，和你的差别挺大的 可能是每个机器的配置不一样的缘故。

确实 nice!!

#12 楼 @larrylv 在给你一个赞。

@larrylv 第一次见 这中写法，能大致讲讲么？ def fast "foo" "bar" end

刚才看了一下，有几个小疑问 1、String#gsub versus String#sub 其实没有可比性 gsub 是全局替换，sub 只替换第一个，应用场景不一样，所以没有可比性。 2、疑问 为什么直接赋值 更快呢？ 我的理解是 a,b = 1, 2 会产生一个新的 array[1, 2]，然后在赋值给 a, b；所以为慢一点。@larrylv 你说呢？

Parallel versus sequential assignment

def slow
  a, b = 1, 2
end

def fast
  a = 1
  b = 2
end

3、 Explicit versus implicit String concatenation

def slow "foo" + "bar" end

def fast "foo" "bar" end

可以尝试其他的比较

require 'benchmark/ips'
def slow
    "foo" + "bar"
end

def fast
    "foo" "bar"
end

def append
  "foo" << "bar"
end

def another
  "%s%s" %["foo", "bar"]
end

Benchmark.ips do |x|
  x.report("slow") { slow { 1 + 1 } }
  x.report("fast") { fast { 1 + 1 } }
  x.report("append") { fast { 1 + 1 } }
  x.report("another") { fast { 1 + 1 } }
end

测试结果如下

Calculating -------------------------------------
                slow     37185 i/100ms
                fast     72146 i/100ms
              append     71189 i/100ms
             another     71661 i/100ms
-------------------------------------------------
                slow  1477945.1 (±10.8%) i/s -    7325445 in   5.012391s
                fast  3086600.4 (±7.8%) i/s -   15367098 in   5.012460s
              append  3086374.5 (±9.1%) i/s -   15305635 in   5.007838s
             another  3038806.7 (±9.9%) i/s -   15048810 in   5.010956s

发现'another'的的效率最高，而且最安全

先赞一下，在拜读!!

鞭屁入里 呀 呵呵

mark 学习了！！