• #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 😄

  • 赞一个!

  • 发布 / 订阅模式 at 2015年03月31日

    发布订阅模式的使用原因是:实际上是将发布方的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)从现实和自然语言的视角来看,类是因为相似事物的属性,而混杂随意的概念集合。和编程中的严格的数学约束虽然有相通的地方,实际上则是貌合神离。

Email:liu_sihao@163.com Skype:liusihaocn QQ:370685149 我的wiki:http://whitecrow.github.io/