多谢捧场，估计一周一更

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

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

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

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

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

#7 楼 @ladrift 哇，可以啊，不过对水平有要求，简历也可以发到邮箱哟：[email protected]

#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。

补充一下。

1）从数学概念上来看。类是一种限制，或者说一种集合。

它定义了两个要素：一个是允许取值的集合，一个是允许参与的运算。例如 int 类型在 Java 中既定义了介于 -2 的 31 次方和 2 的 31 次方 – 1 之间的整数集合，也隐式限制了该集合上的整数所能进行的运算。

如果我们需要将 2.add(2) 的结果得到“22”，则需要将它转换为另一个 String 类。

从这个意义上来说，类型本身对类型行为就存在约束。因此 Linus 说：“Bad programmers worry about the code. Good programmers worry about data structures and their relationships.”。

2）以 OOP 的视角来看，code 即类的 method，data structures and their relationships 即类的 attributes，类的耦合关系。 从类的实例化，多态，继承、组合等各种类的关系来看类，都有一翻解释，话题太大。

3）从现实和自然语言的视角来看，类是因为相似事物的属性，而混杂随意的概念集合。和编程中的严格的数学约束虽然有相通的地方，实际上则是貌合神离。

虽然不打算加入（已经有工作），但是还是情不自禁地帮顶一个！！实在太赞，LS 说得是，令人心驰神往。

四大魔道编程天王：王垠，田春，胡正，李杀。2333333

青龙田春，白虎王垠，朱雀李杀，玄武胡正。

而且都是玩 Lisp 的。

#51 楼 @jeremy16601 我劝你好好说话！！！我谈谈自己的学习态度，你有不同的态度就亮出来，有不同的意见提意见。评论技术无非各抒己见，难道因为怕被说装逼就不分享不评论不表达，呵呵呵。

一大早看见这种评论真是恶心，很多人离开技术论坛论坛就是受不了这种语气，导致论坛越来越水。

#5 楼 @chunlea 这个建议真的挺不错。

借 LZ 的地方想问问，不知道哪里有比较好的 PG 方面的论坛或较为深入&高效的学习/实践资料？中国公开的技术论坛在这一块资料太少了，ITPUB 甚至连 PG 的板块都没有。

#39 楼 @zhang_soledad 你说得对，后面几条不适用于新手。

#3 楼 @dotcomXY 非常感谢，这些论文 list 对我的帮助真的很大

#34 楼 @bugmenot 我既分享过大条道理，也分享过自身熟悉领域的经验（http://ruby-china.org/topics/17423 http://ruby-china.org/topics/19349）。后者固然在技术论坛比较政治正确，但抽象的或总结性的思考，我相信也是有人需要的。

#31 楼 @bugmenot 我不知道你为什么做出这样的猜测，也许是帖子里的语气让你不舒服。也无意指责你的猜测。我很奇怪帖子中只有三四个人在和我讨论文中的主要观点，而其他人在纠结于不影响论点的例子当中的细节。

只是希望下次回帖的时候能够做一点换位思考，我为什么发这个帖子，我想要讨论和分享什么。

P.S. 这四册书中，第三本和第四本没看完，因为剩下的部分并不是我需要的知识，如果这让你觉得获得了安慰，我无话可说。

#1 楼 @dotcomXY 我一直很好奇学术圈对于 complex software systems 的研究。哈哈，如果方便的话还请帮忙问问 bill：不知道有什么可以借鉴到工业界当中的地方？如果读相关论文的话，从哪些论文开始读作为入门比较好？非常感谢 :D

非常精彩，补充一下，还有 ORM 对象缓存：http://robbinfan.com/blog/38/orm-cache-sumup 和缓存服务器缓存（比如 Varnish http://www.360doc.com/content/10/1026/11/737570_64093653.shtml）。

不过后者是位于 Nginx 上层，并不在 LZ 的三个层次里面。

#3 楼 @hooopo 词语有歧义，已改正为“能力”。

#1 楼 @bhuztez 词语有歧义，已改正为“能力”。

#28 楼 @aptx4869 好吧，我的具体例子不完善，说道具体细节可辩论的太多了。几年前 MonogoDB 是怎么宣传的你可能不了解。不多说了，免得争吵。

#25 楼 @yukihiro_matz 眼一花，还以为你是 Matz 真人。。。。

#3 楼 @apprentice 不是的呀。:P

#1 楼 @apprentice http://www.yangzhiping.com/tech/ruby-machine-learning.html

#43 楼 我发现我的很多想法和 @mjf429 类似。"看代码看数据的组织形式"，Linus 也说过同样的话“bad programmers worry about the code. good programmers worry about data structures and their relationships.“请问你有博客吗？我非常想去看看。