抢楼 给老大助阵！

7 排支持！

#36 楼 @Pitt 我记得你一直在写 node 的呀？

#37 楼 @jiyinyiyong 你再看看 nodejs 底层依赖 libev，他的设计目标就是实现类似 iocp 的模型

#37 楼 @jiyinyiyong 我记得曾经有个 benchmark，node 在 win 下的性能比 linux 下还要强一些，原因就是 m$亲自贡献了基于 iocp 的异步 io 实现....linux 流行的 epoll 和 iocp 比起来弱爆了...m$支持 node 主要是因为 win azure

#39 楼 @liliang13 有青年旅馆吧 @hooopo @ichord 他们应该会去 这方面开销是肯定的啦...也没办法 好好学习 将来挣大钱哈

#30 楼 @bhuztez +1

#35 楼 @ichord 也涉及大小，摆放呀什么的...还涉及到摆放白金赞助商的 logo 这个对于专业设计师来说不是难事，但对于我这还没涉足过的人来说，会很花费精力

#25 楼 @jiyinyiyong jquery 都是 m$赞助的呀，还有 nodejs

话说刚才无意发现了这货 http://reactive-extensions.github.io/RxJS/ 搞 js 的同学们有研究么？据说是 m$的人搞出来的

#18 楼 @lgn21st jing.js 嘛 11 月 8-9 不过他们好像只定了个会场

#13 楼 @zj0713001 #14 楼 @jarorwar #15 楼 @goinaction 哈哈 看来可以面基了

#10 楼 @zj0713001 北三环哪...我现在住太阳宫，或者北四环惠新东桥那

#7 楼 @zj0713001 没问题！

#6 楼 @iBachue 确实是愿意买票的人早就买好票了，但后者不一定，往届虽然在上海，但是像北京我们还是一起去了二十多人，其他地区也是的把，精力我想不是最重要的。

我想长三角的朋友们都知晓而且信任 @lgn21st ，这段时光，他一直在给我讲过去组织四次大会的心路历程，可以得到一个结论，组织大会需要各位的信任，我现在深感信任这件事情不是靠发几个帖子、聊聊天或者 qq 群里解答问题（话说我在几个很大的 Ruby 群里知名度更高些～ @hysios 是不？）就获得了，这是一个长期过程。包括我自己在内，也还不清楚我能把大会做到如何地步？能不能保持水准？能不能让大家感到值回票价？当然，这问题我的答复是，尽最大努力，但是他人能否相信我的决心，需要结果和长期积累来认同

另一方面北京在 Ruby-China 上仅有 312 个注册用户，目前咱们已有 1w+ 的用户了，可以说北京的成员占总体比例极小，但是北京 Rubyier 不比长三角、深圳地区少，像我过去在 CSDN 的同事，他们居然都没有听说过 Ruby-China，这让我挺意外的。Ruby-China 是活动主要的宣传推广平台，但是这种情况下，信息没能够传达到他们那里。

#3 楼 @goinaction 帮助宣传 ruby-china 和 RubyConf 啦！非常感谢！ 另外，咱们北京 ruby 社区要承担场务工作的事情哇，如果有可能，大家一起来做～ 具体的 我正和文洋他们聊

#1 楼 @krazy 帮忙向公司，同事宣传 ruby-china 和 RubyConfChina 吧，@sundevilyang 会组织 ruby 聚会的时候商量志愿者工作的事情～

不折腾...

#33 楼 @liwei78 香山。。。我原来家就在那 鸟不生蛋啊。。。

#24 楼 @hooopo 贵毛。。周边汉庭如家都有 - -

#22 楼 @sundevilyang 嗯

#24 楼 @hooopo 别啊...我搬回太阳宫住了...十号线太阳宫站边上

#18 楼 @lgn21st 其实口味上说，全聚德还是不错的，不过就是搞的高端大气上档次让屌丝接受不能 - - 性价比不高。。。

@pongyo @lgn21st 主要是全聚德这些年感觉坑老外和硬盘赚头比较大，所以不好好搞了... 托有个美食频道记者亲戚的福，原来隔段时间都能拿几只全聚德吃的说...还不错的

#12 楼 @luikore 或者吃剩的荷叶饼，用滴下来的油烧热煎熟，拌上甜面酱...

#12 楼 @luikore 现在还可以选择，把没肉的骨头加上孜然辣椒面炒，然后上桌吃的

#7 楼 @hpyhacking 就是大会之前接讲师到酒店

#7 楼 @TsingHan 不是 比如 a 设置 1 分钟监听 b 设置 1 分钟监听 c 设置 2 分钟监听 那就是有一个全局的 1 分钟间隔的 job 一个全局的 2 分钟间隔的 job

1 分钟间隔的 job 触发后 发现 a、b 是一分钟触发，遂执行 2 分钟间隔的 job 触发后 发现 c 是他管的....执行之

这样就不涉及动态改 cron 了 如果请求数量大，那就把这些 job 当触发器用，开新的线程、进程去处理 防止阻塞

@linjunpop

这么想呢，给每种频率分别开定时任务的 worker，间隔为他的频率，然后触发之后，从数据库里取相应频率的 task，然后处理

好处是简单，你不需要给每个 task 单独设置 crontab，如果 task 数量巨大的话，你可以先取出所有的 task 然后再分发到子 worker 处理，感觉也不是很复杂