讲完直接去吃饭了
#60 楼 @tency https://github.com/mperham/sidekiq/blob/2fc1d81cc9691c9232a088f1410c5a27fae5e11f/lib/sidekiq/extensions/generic_proxy.rb#L19
如果用 proxy 的话就会有 yaml。。。go-worker 好像不能处理吧?
学习了,之前公司在实际过程中也发现 sidekiq 占用 cpu 过高,负载比较大的情况
部分同意观点,主要还是 sidekiq 和 rails 业务代码相关联,带了很多不必要的库,而且 go 的并发性能有很大提升
但是用 go 重写推送部分的业务逻辑的话,整体的性能也会有所提高吧?对业务代码进行改造,会不会也在一定程度上提高了 worker 的性能呢?也就是大概多少比例是语言本身的优势,哪些是业务简化,代码优化带来的提升?
还有个问题,这个改造的成本会有点高吧?比如之前用 sidekiq 的 proxy 写的代码必须转换成全部都是传递数据的形似,比如 ruby-china 社区的源码就大量采用了 dalayed 这种写法,会把 ruby 的调用转成 yaml 序列化,go 用来做 worker 的话这块就完全没法用了吧?
https://github.com/lujiajing1126/ember-example
很久之前写的东西,一个 demo,部分用了 emberscript
ember 中文社区的 demo 也开源了吧,叫做 intimi
React 这些我觉得应该不能和 Ember 放在一块吧 这些都是对前端 UI/Component 模块化的实践和探索,包括 Mozilla 在内很多公司都在做这块 Ember 属于重量级的 MVC 解决方案 Yeoman+Bower+Grunt 在 13 年就很流行了。。个人感觉应该不能算高手级别吧=。=算是终于成为主流
= =来水一水
这样搞真的好嘛。。。