哦没看到你已经在编译了，如果编译出问题我也不知道怎么弄了，试多几个编译器吧。。其实 1.9 语法对 2.0 变化不大，也就少了个 keyword arguments，建议别折腾了

支持一下，不过我没 windows，建议源码发 github 看看

rubyinstaller 装不了的，2.0 开始就不行，印象中是 gcc 依赖了新版本的 dll，你如果重新用 xp 下的编译器进行编译就可以

因为跨公司去搞这些是很麻烦的，rails 应该是有全职开发者的，如果不能进入内部讨论的圈子，你做个 pr 三个月才合/不合也是颇为正常的事

https://ruby-china.org/topics/37815

变量不可变只是假象，你进程 id 指向的那个东西不还是可变的

我并没有把 id 放到 url 中，account 只是个虚拟的单数资源，本体是 current_user。

既然你已经意识到了资源取用是要先鉴权的，那么假如你用/addresses/1 取用一个地址，而地址根本没有和 user 关联，你要怎么鉴权？head 404 unless @address.credit_card.user_id == current_user.id ？如果是多对多关联你是不是还要把所有查出来然后对集合 find？如果业务逻辑需要操作多对多关联，你要怎么确定操作哪个？

知道每一级资源的 id，在链条上有多对多关联的时候是必须的，在仅有一对多关联的时候是推荐的。

嵌套资源的依赖是一层层的，你不可能直接拉到最后的，举个例子：

#你永远应该
current_user.credit_cards.find(params[:id])
#而不应该
CreditCard.find(params[:id])

#假如你的url是 /account/credit_cards/1/addresses，你应该这么取用
current_user.credit_cards.find(params[:credit_card_id]).addresses

嵌套资源一般而言是每层都要取出来的，因为你拿到一个 address 没有办法知道他是不是 current_user 拥有的，除非把 credit_card 也查出来。

https://ruby-china.org/topics/29972

block 和缩进有关，事实上你写 promise 写得多，就会发现一个函数拿两个匿名函数是很扯的。所以 ruby 里干脆只让方法带一个匿名函数，就是 block。

要骚操作完全可以

break if str[v.tap{v += 1}] != 3

当然 confuse 的程度是一样的

列表解构是有的，倒是 hash 解构没有

已收，谢谢。

联系方式是？我的 Order ID 是 289645。

我对介词“在”的理解有问题？

“在这周”指的是这周内，而不是这周前。同理，“在大会开始前一个星期”指1.week.before(beginning_of_conference)...beginning_of_conference。

现在就是开会前一个星期，为什么不允许退票？

挺好的，其实这个比 1.8 那个好不少，1.8 的块就很迷，函数签名就很合理

我是用 workbench 自带的格式化。。懒得折腾

nmatrix 印象中老是遇到 segfault。。

其实还有个 rubynumo https://github.com/ruby-numo ，不过这个矩阵库实际用的时候跑得很慢，可能是我的用法不对

@Rei @hooopo

但是 schema 本来就是 db dump 出来的，永远反映的是 db 现在的状态，假如开发环境别的分支有 migration，在当前分支 commit 之后这个 wip 的 migration 就会合到 master 上....

我认为 schema 的正确性是没法保证的，如果常常要从头 init 整个环境，我觉得合并 migration 才是唯一能用的方案。

开发停止两年了🌚

这就叫闭包作用域，不是必要最好不要生造名词……

不如看 whitequark 的 parser 或者 seattlerb 的 ruby_parser，ripper 的比较低级

其实就 https://github.com/leandromoreira/redlock-rb 就好，比数据库的锁灵活

问题是你的 picture 是怎么来的。。Picture.all.map{|x| x.imageable}？这样也是不会带 published 的啊，还是不清楚要怎么重现

说说你的查询语句是怎么写的，Product.published.map{|x| x.picutres.map{|x| x.imageable}} 这样？

所以说参考 slc 做一个嘛，反正注入关联要干的活 slc 里都写了

scope 是关联上的 scope？看不出你写的 scope 和关联有什么关系，一开始我以为是 default_scope，后来发现关联是会忽视 default_scope 的。。

你那样改写关联，会导致 includes 无效等杂七杂八的问题，用||=缓存的话，也要有相应失效的机制

有干这个的 gem https://github.com/hooopo/second_level_cache

不过带 where 条件的关联，用 slc 可能会导致关联没法正确过期，要留意一下或者你参照 slc 的思路自己弄一个

7102 年了，还不支持 linux 输入中文。