#5 楼 @chairy11 开始入场而已...

#2 楼 @kepaning :plus1:

#26 楼 @gazeldx RubyMotion 是建立在 LLVM 上的，和 ObjC Swift 一样最后会编译成 LLVM 字节码，所以类库是完全互通的，而且 RubyMotion 的工具链还有包管理非常优秀，比 XCode 和 CocoaPods 要好很多，上周六北京 Ruby 聚会有做过这方面的分享

支持哦！

#42 楼 @wangping 是电子门票啦，在 19wu 的我的订单里，可以看到签到码 我写一个帖子来说这个事情吧

#40 楼 @ginchenorlee 3W 咖啡有其他活动了，改在 Black Jack 咖啡，正文啦

#32 楼 @diguage #33 楼 @PengEdy 改到黑杰克咖啡在银科大厦

#34 楼 @iamzhangdabei 都已经说出去了。。。没事 rubyconf 前还可以去那聚

#30 楼 @PengEdy 要改，3W 这周被占了，不过改的话地址也在附近

#8 楼 @fengkuok 是嘛？我去查查后台

就要交卷了哎...

#1 楼 @chairy11 还在筹备中，快了

:plus1:

例子感觉不太好，不过自己也想不到更好的了，create_order_contact可以自己定义成业务逻辑方法，这样就可以避免使用回调了，并且程序并不会变得冗余。 个人认为回调应该处理和业务逻辑无关的东西，比如刷新冗余字段、添加操作记录之类，否则考虑什么时候会触发回调本身就是灾难。

在模型里声明模型间关联就代表这些类有耦合了，增加 Service 层改变不了这点，但是如果一个业务涉及两个不耦合的模型或者涉及到外部系统，可以增加 Service 层，这样两个模型和 Service 单向依赖，结构更美观点。

话说，最近在实践把模型里的代码（声明、原子的业务逻辑）按作用拆分到不同的 module 当中，然后 mixin 进来，模型类本身仅包含类似create_order_contact的业务逻辑，如果业务逻辑众多其实还可以把业务逻辑按域分离到 module 当中

#34 楼 @Tony612 第二天就是在创业街上的各种交流活动了，或者在咖啡馆坐着聊聊天之类，觉得差不多了就可以回去啦

#31 楼 @wangping 邮件给我啦 [email protected]

加油

原理是减少对象创建内存分配次数，套路还是很标准的

还有一个提交值得学习 https://github.com/rails/rails/pull/17173

#18 楼 @luikore :plus1:

#16 楼 @fsword 唔...

购票了，不过因为工作和组织北京这边大会的缘故没能参加 看 Twitter 上的讯息感到没有参加很是遗憾啊

公司在我家旁边 - -

#10 楼 @cisolarix 可以报名试试呀，其实是希望有一定的 Ruby 基础，毕竟动手实现 AR 还是需要一些基础知识，这样才能专注于思想的

#11 楼 @liuhui998 交流的会有滴~

#8 楼 @liuhui998 恩 这个责任在我，没有很好的去宣传大会

#6 楼 @cisolarix 在 http://rubyconfchina.org/#schedule 目前只准备好了两场，另外两场十一后会更新完毕

#4 楼 @chunlea 还是有场地的，如果能解决安装、版权之类问题的话，还可以组织

#14 楼 @badboy 那你还不过来参会 - -

#12 楼 @suffering 我感觉那课的精髓在于和作者的交流，单纯的实现框架（只实现核心 DSL，不考虑性能）并不是很难

http://owningrails.com/ 也在讲同样的事情，不过是在线课程，讲师是 Thin 的作者 @xdite 有推荐 http://wp.xdite.net/?p=2407