多谢捧场，估计一周一更

#19 楼 @gwotzehsing 需要一个 request 队列来解决这个磁盘瓶颈的问题。

并且监控队列的长度和 “清 request” 的速度，观察系统的性能压力。

队列多了以后，平衡队列的数量来保证 CPU 的利用率。之后通过调度器来控制队列的依赖顺序及优先级，最后通过限制每个队列的长度，来控制延迟和吞吐量之间的关系。

IO 优化都是这么一套玩法，应该没啥。

#5 楼 @linsk 哈哈哈哈哈哈多谢！

#7 楼 @ladrift 哇，可以啊，不过对水平有要求，简历也可以发到邮箱哟：liusihao@quantmi.com

#2 楼 @heliang7 之前在循礼门，招人后会搬去光谷广场或广埠屯

所谓人才市场，由微观宏观两块组成。 1）宏观上是市场供需，供大于需要求要多高就能提多高，比如投行业和咨询业，其实实际工作并没有那么难；需求大于供给的时候，LZ 这样刚入门的水平已经够用了，而在成都的 Ruby 圈，我相信是后者。

2）微观上是招聘者的具体需求，我一个朋友，前端水平可能和 LZ 差不多，但一个很不错的企业要了他。为什么？因为他们公司有专职前端，只要求后端水平到达一定程度就够了。这时候针对应聘公司及同类公司的业务介绍、套瓷公司员工就能得出他们当前项目的具体需求，差什么补什么即可，然后你一上来就能做，还是拿的实习工资，公司岂会不要你，并不需要像楼里面的朋友们要求那么严格和全面。

这两点是人才市场的基本规律，楼主如果理解了，相信以小搏大不是难事。求职，本质上也是个经济学问题，供需越接近完美的平衡就越成功——找到最需要自己又最能发挥自己价值的地方；毕竟每个人都有他的局限之处，并非所有团队都那么求全责备。

补充下，JS 以前非内建的继承和模拟类的方法，https://ruby-china.org/topics/17423

赞一个！

发布订阅模式的使用原因是：实际上是将发布方的 callback 逻辑抽离出来，单独作为一个 Service Object（即订阅端）。逻辑的信息量并没有变，但将这部分信息量分化出来以降低复杂度。

这里的 ClientListener，其实是一个总 callback 类，而到底需要 callback 哪一个，则由 ClientListener 方法决定，而非发布方决定。

#6 楼 @Rei 赞，Show 本身就和 ActiveRecord 之类的类天然有耦合性，在这里类的主要作用变异为了组织信息，而非组织数据。与 OOP 中类的概念天然背道而驰。

P.S. 组织信息所用的类必须是 singleton class。