MongoDB权威指南(第2版) (4)

  • 第111页
    capped collection适用于日志记录等场景。 它的插入速度是比较快的 不过一旦创建,无法再更改大小。要想更改只能删除重建
  • 第109页
    capped collection是固定大小的集合 当数据超出时,它会删除最旧的数据来存储新数据
  • 第108页
    如果有选择的话,先填充数据再加索引微快于先加索引再填充数据
  • 第104页
    Mongodb的唯一索引是空值敏感的,即多个空值出现在同一个唯一索引中也不行。 但是可以加sparse选项解决这一问题

Linux多线程服务端编程 (2)

  • 第20页
    析构所在的线程 对象的析构是同步的,当最后一个指向x的shared_ptr离开其作用域的时候,x会同时在同一个线程析构。这个线程不一定是对象诞生的线程。 如作者所述,这个特性是双刃剑,用得不好的话在关键...
  • 第20页
    析构动作在创建时被捕获 这是一个非常有用的特性,这意味着: 虚析构不再是必需的 shared_ptr<void>可以持有任何对象,而且能够安全地释放。 shared_ptr对象可以安全地跨越模块边界,比如从d...

人月神话 (21) 更多

  • 第177页
    能够使我们认识到自己不足和容易犯错的——上帝所赐予的谦卑。 谦卑,是一个人的美好品德!
  • 第162页
    读到这里,越来越感觉和两天前接触到的敏捷开发的概念有些相像了。 或许我觉得它们相像是因为增量开发模型和敏捷开发中的及早交付可运行版本的意思有些共同点。当然它们之间还是有不同的,敏捷开发面对的主...
  • 第123页
    就我的经验而言,在系统工作中所遇到的大多数困难是组织结构上的一些失误征兆。试图为这些现实建模,建立同等复杂的程序,实际上是隐藏,而不是解决这些杂乱无章的情况。 对此我并没有经验,但是工作是在解决问题...
  • 第104页
    软件的复杂度是必要属性,不是次要因素。 说实话这句话并不是十分理解,只知道按照作者的意思,数学和物理学之所以能够取得较大的进展,原因在于它们能够把复杂度忽略掉去思考问题,而在软件这个领域,如果你把复...
  • 第90页
    项目经理必须停止对这些日期的怀疑,而将重点放在使其更加精确上、以便得到没有偏见的估计,而不是那些合乎心意的乐观估计或者自我保护的保守估计。 项目经理不能随意地基层人员下达自己的目标,而要在参考...
  • 第88页
    减少角色的冲突。首先老板必须区别行动信息和状态信息。他必须规范自己,不对项目经理可以解决的问题做出反应,并且决不在检查状态报告的时候做安排。我曾经认识一个老板,他总是在状态报告的第一个段落结束之前,拿...
  • 第65页
    因此,管理上的问题不再是“是否构建一个试验性的系统,然后抛弃它?”你必须这样做。现在的问题是“是否预先计划抛弃原型的开发,或者是否将该原型发布给用户?”从这个角度看待问题,答案更加清晰。 这么样来想...
  • 第49页
    实践是最好的老师,但是,如果不能从中学习,再多的实践也没有用。 这句话很有道理!
  • 第44页
    卡内基-梅隆大学的D.L.Parnas提出了更彻底的解决方法1。他认为,编程人员仅了解自己负责的部分,而不是整个系统的开发细节时,工作效率最高。 这个观点不知道是不是正确的,我个人的看法和他是有些相同的。..
  • 第38页
    显然,对于存有疑问的实现人员,应鼓励他们打电话询问相应的结构师,而不是一边自行猜测一边工作,这是一项很基本的措施。 如果带着猜疑做工作,一方面由于存在猜疑,效率可能不高。另一方面如果实现人员的..
  • 第35页
    一句古老的格言警告说:“决不要携带两个时钟出海,带一个或三个。”同样的原则也适用于形式化和记叙性定义。 必须有一个标准!
  • 第24页
    对于非常大型的项目,将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。 设计方法、体系结构这些东西,应该是统一比高效更重要的。 如果不统一,即使那个部分设计得比较高...
  • 第17页
    这种进退两难的境地是非常残酷的。对于效率和概念的完整性来说,最好由少数干练的人员来设计和开发,而对于大型系统,则需要大量的人手,以使产品能在时间上满足要求。如何调和这两方面的矛盾呢? 这个很有道...
  • 第16页
    实际上,绝大多数大型编程系统的经验显示出,一拥而上的开发方法是高成本的、速度缓慢的、不充分的,开发出的是无法在概念上进行集成的产品。 这个确实有感受。我们在TOT13培训的时候有一个活动叫做取水活动...
  • 第15页
    简单、武断地重复一下Brooks法则: 向进度落后的项目中增加人手,只会使进度更加落后。(Adding manpower to a late software project makes it later) 虽然这么说,可是真到了紧急的时候,如果不够镇定的话,..
  • 第10页
    对于软件任务的进度安排,以下是我使用了很多年的经验法则: 1/3计划 1/6编码 1/4构件测试和早期系统测试 1/4系统测试,所有的构件已完成 原来测试竟然能够占到进度安排的一半,哇! 以前自己做程序的时候,...
  • 第8页
    第二个谬误的思考方式是在估计和进度安排中使用的工作量单位:人月。 以及 因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。 这个问题之前...
  • 第8页
    然而大型的编程工作,或多或少包含了很多任务,某些任务间还具有前后的次序,从而一切正常的概率变得非常小,甚至接近于无。 由此可见我们的乐观是多么盲目的呀
  • 第7页
    我们的乐观主义并不应该是理所应当的。 有道理!
  • 第7页
    所以系统编程的进度安排背后的第一个假设是:一切都将运作良好,每一项任务仅花费它所“应该”花费的时间。 这个确实是的,我在计划东西的时候也一般是用乐观的态度去假设所有的事情都会正常地进行,不会有什么事...
  • 第6页
    在众多软件项目中,缺乏合理的时间进度是造成项目滞后的最主要原因,它比其他所有因素加起来的影响还大。 在此之前我还一直没有认识到合理的时间进度对于一个软件项目是如此的重要