• 多谢捧场,估计一周一更

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

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