Life for Idea – forever young
平庸的经理老是提心吊胆，害怕放手就会失控，而伟大的经理知道本质上人是不可管理的；成功管理的本质是使每个人朝着同一个方向努力，然后使他们热情高涨，高涨到即使是经理也无法阻挡他们前进的步伐。
健康公司公认的亲和力建设策略要素：
-质量崇拜
-提供许多富含成就感的机会（我的翻译）
-建立精英意识
-允许和鼓励异端
-保持和保护成功的团队
-提供战略而不是战术指导
在最好的团队中，不同的人提供临时的领导，负责他们特别有实力的领域。没有人永远是领导，否则团队的互动关系可能就会瓦解。
一个团队结构应该是网络而不是阶层。
《人件》chapter23
-
Powered by MoFire
没有什么引用的话.
<<人件>>chapter19
通过将"精英意识"灌输到团队,培养团队的独特性 - 在专业领域上的更胜一筹.当这种文化建立起来时候,人员流动就不再重要了. - 这是书中的意思,但我觉得,当人员流动会渐渐让团队文化流失,可能比普通团队慢一点,但一定会流失的.
怎样保持呢?
在团队成员来说,当激情不在的时候,可能也就没有动力去与众不同了.所以激情是最主要的动力源.作为团队的老板(他们不属于团队)也许更多的是启发式的教化和放权,让他们去乱搞!!
大M方法论试图把思考集中起来，由大方法论的作者做出所有有意义的决定，而不是那些执行者。那些采纳大方法论的人认为大方法论有一长串的好处，包括标准化，文件同一性，管理控制，艺术级的技术。其隐含的框架很简单很粗糙：项目人员不够聪明，不能进行思考。
《人件》chapter17 自愈系统
-显然大方法论是反人件的，认为人是愚蠢的。某种程度的精英主义和过度的控制欲，大多时候我们看到这种笨重的，闭门造车的行为，如果不加反抗或躲闪，就会变为一颗螺丝钉，成为＂大师杰作＂的牺牲品。
-当我们看到一个公司大多数人都在重复着自己的时候，那么一定是大方法论在作怪。找到他，打破他。或者赶紧闪人。这样的系统是无法自愈的。
Powered by MoFire
再次想给netbeans一个机会代替eclipse.
在耗费了2个小时以后,最终还是又一次放弃了.NB的本意很好,通过各种bestpractice和模板来帮助开发,简化开发.但毕竟技术这种东西可以被各种各样的人用的千奇百怪,如果都是一个样子反倒让人感觉不对劲.
比如我想要把以前写的一个MIDlet项目导入,但是找了半天找不到怎么运行.只因为我以前的实践方法和NB的不一样??或者是我太笨没找到方法吧.
再试过其他的一些功能以后,我觉得还是算了吧.NB更像是sun的一帮自以为是的工程师拿出来给卖给所有java程序员的吧.但因为做了太多事,反而让我觉得很不爽,还有一个问题是NB生成的模板和代码并非很吸引人,但是却限制别人定制和修改.这就让那些想要使用某些功能的人无法抉择.NB给你的选择是要么什么都别用,用么就全用.让我觉得是一种强迫式的推销.
所以,我还是会使用eclipse,虽然eclipse可能会让我写更多的代码.NB给我的启示是,多写代码未尝不是坏事,至少我很清楚,而且可以改进;代码写的少,未必是件好事,因为我什么都不能做.
netbeans仍然sucks!!
已经有很多类似的模式，其实就是优惠券批发，这里主要强调的是易操作性-可以商家自助完成优惠券发布，发布商主要是网站自助完成优惠券渠道申请，中间的平台做到统计和监控以及防滥用。
Powered by MoFire
熵就是平庸或相同，越增加熵，就越没有产生活力或进行工作的潜力。在公司，熵被看作一种在态度，相貌和思维过程方面的统一性。
最成功的经理应该是这样一种人，他动摇公司的熵，引进合适的，即使是与公司标准有出入的人，让他们成为他们自己。
--《人件》chapter 14
-降低熵，以保持有活力的团队气氛。应该就是引入不稳定性(而不是"颠覆性")
-这种从热力学角度的分析也许可以解释为什么当在一个公司待久了会产生依赖感(因为自身已经变为稳定性的一部分)。以及当进入一个新团队时所面对的不适应-这种不适应通常引致两种情况：1被影响2影响之(貌似是废话)，也许公司和团队要适当引入后一种人。
Powered by MoFire
环境造成的创造性方面的惩罚是潜在的。因为创造性的损失是不容易注意到的。创造力减少的影响是一个日积月累的过程。公司越没有生产力，人们就越没有激情的火花，只会机械的工作，最优秀的人便会离开。
-《人件》chapter12
Powered by MoFire
用来Java_ME_platform_SDK_3.0中自带的几个模拟器居然发现无法模拟相机,而这个是在wtk2.5里一个很寻常的功能.为什么同样的一个东西升级之后变得更差呢???
最郁闷的是wtk2.5的模拟器在win7中无法打开.win7提示无法兼容配色方案.郁闷!!
jdepend使用起来还是比较容易的,但是report分析,以及背后的一些事情还是要弄明白的.否则report就真的成了只是report而没有任何实际价值.
使用jdepend的目的
分析包的依赖情况是否满足面向对象的依赖原则.其实面向对象,设计模式变出那么多花样最后无非就是要解决依赖的问题.但很多情况下,我们用了技巧却忘了为什么用,最后便的为了技巧而技巧,为了设计而设计,而忽略了最终目的.
也许这种感觉只有在深刻的体会过"混乱"之后才能理解吧.
如何分析jdepend的report
Abstractness - 抽象度,该包中抽象类所占的比例
Afferent coupling(Ca) - 被依赖度,有的翻译成传入耦合.我觉得传入耦合不是很清楚,很容易让人理解反了.指依赖该包的其他包的总数. 这个值越高说明他应该要么是公用包,要么是抽象(接口)包
Efferent coupling(Ce) - 依从度,有的翻译是传出耦合.指该包依赖于其他包的个数.通常越高表明依赖其他包越严重,如果这个包不是实现包,并不意味着ce就越大越好.依从度应该在一个合理的范围.同时依从的包应该是stable的.
Instability(I) - 不稳定性.公式 ce/(ce+ca).即依从度在所有依赖中的比例.还比较好理解,如果是完全抽象包(ca=N,ce=0),I=0,如果是完全具体实现包(ca=0,ce=N),I=1.
Distance - 指该包和理想情况的最大差距.这个有点绕.举个例子,如果一个包的A=1,也就是完全抽象的.那么他的I应该是=0的,但如果不是(也即是他还要依赖其他更抽象的包).那么distance=Instability-0(理想值).而如果一个包的A=0,即该包完全是实现,那么他的I应该是1,那么distance = 1(理想值)-Instability
而如果0<A<1,那么就不知道他的I的理想值是什么了.这个时候理想值应该是A,distance=|A+I-1|.
