发散一下,其实用过和正在用 jruby 的人也有一些了,有没有必要建立一个 jruby 节点呢?
尽量小步升级
#7 楼 @quakewang 收到,谢谢啦
政治正确性真是一件很扯的事情
下次杭州 tuesday 的时候分享吧
可惜 code review 那场没参加上
不如大家一起来吐槽吧,我补充一个,监控和报警方面常用一个词——“阈值”,很多人念成“fa 值”,甚至后来有的人真的写成了“阀值”,而汉语词汇中其实没有后者 ref : http://baike.baidu.com/view/648990.htm
#7 楼 @ery 我理解你所说的场景下有两个 project,一个是前台,一个是管理后台。 解决方案要根据规模来定,小规模的时候可以由一个 project 来负责 migration,另外一个仅仅使用,不负责维护数据结构的升级,具体哪个维护 migration 取决于哪个 project 的变更更频繁。
同步 migration 的做法我没接触过,不过感觉是朝着错误的方向上深入下去了
应该提醒的是,此时要注意分拆 model 的业务逻辑,一个常见的误解是前后台共用一套模型,这个很多时候都是错误的,因为前后台对同一个东西的看法可能是截然不同的,如果共用模型,容易人为造成陷阱。实在重复的代码,可以做成对 model 的增强 gem,然后共用(@hooopo 的方案)
当然,上面说的是小规模,当业务变大的时候就必须朝服务化的方向转移了,所以关键还是要把业务分开
杭州,11 点到家
楼主说的对,好吧这次是真心觉得楼主说的对
You are not authorized to access this
这个意思就是还没传完么?
楼主语速可能是有些快,不过就我自己来说,基本上还算听得明白,挺好的
同兴奋,不过你今天马上就买到板子了?
经典画面应该是 @lgn21st 被推倒吧,求好事者抓拍......
你真的很找‘抽’啊......
楼主是哪个公司的?做推荐和搜索的并不多吧