非天's profile简单一点,放松一点!PhotosBlogLists Tools Help

简单一点,放松一点!

非天 李

活着,像牲口一样的活下去
October 14

社会生活中的著名法则(zt)-

社会生活中的著名法则
【摘要】社会生活中的著名法则
一、 马太效应
二、 手表定理
三、 不值得定律
四、 彼得原理
五、 零和游戏原理
六、 华盛顿合作规律
七、 酒与污水定律
八、 水桶定律
九、 蘑菇管理
十、 奥卡姆剃刀定律
十一、 二八法则
十二、 钱的问题

一、马太效应
《新约•马太福音》中有这样一个故事,一个国王远行前,交给三个仆人每人一锭银子,吩咐他们:“你们去做生意,等我回来时,再来见我。”国王回来时,第一个仆人说:“主人,你交给我们的一锭银子,我已赚了10锭。”于是国王奖励他10座城邑。第二个仆人报告说:“主人,你给我的一锭银子,我已赚了5锭。”于是国王例奖励了他5座城邑。第三个仆人报告说:“主人,你给我的一锭银子,我一直包在手巾里存着,我怕丢失,一直没有拿出来。”于是国王命令将第三个仆人的一锭银子也赏给第一个仆人,并且说:“凡是少的,就连他所有的也要夺过来。凡是多的,还要给他,叫他多多益善。”这就是马太效应。看看我们周围,就可以发现许多马太效应的例子。朋友多的人会借助频繁的交往得到更多的朋友;缺少朋友的人会一直孤独下去。金钱方面更是如此,即使投资回报率相同,一个比别人投资多10倍的人,收益也多10倍。

这是个赢家通吃的社会,善用马太效应,赢家就是你。
  对企业经营发展而言,马太效应则告诉我们,要想在某一个领域保持优势,就必须在此领域迅速做大。当你成为某个领域的领头羊的时候,即使投资回报率相同,你也能更轻易的获得比弱小的同行更大的收益。而若没有实力迅速在某个领域做大,就要不停地寻找新的发展领域,才能保证获得较好的回报。

  二、手表定理

手表定理是指一个人有一只表时,可以知道现在是几点钟,而当他同时拥有两只表时却无法确定。两只表并不能告诉一个人更准确的时间,反而会让看表的人失去对准确时间的信心。你要做的就是选择其中较信赖的一只,尽力校准它,并以此作为你的标准,听从它的指引行事。记住尼采的话:“兄弟,如果你是幸运的,你只需有一种道德而不要贪多,这样,你过桥更容易些。”

如果每个人都“选择你所爱,爱你所选择”,无论成败都可以心安理得。然而,困扰很多人的是:他们被“两只表”弄得无所事事,心身交瘁,不知自己该信仰哪一个,还有人在环境、他人的压力下,违心选择了自己并不喜欢的道路,为此而郁郁终生,即使取得了受人瞩目的成就,也体会不到成功的快乐。
  手表定理在企业经营管理方面给我们一种非常直观的启发,就是对同一个人或同一个组织的管理不能同时采用两种不同的方法,不能同时设置两个不同的目标。甚至每一个人不能由两个人来同时指挥,否则将使这个企业或这个人无所适从。手表定理所指的另一层含义在于每个人都不能同时挑选两种不同的价值观,否则,你的行为将陷于混乱。

  三、不值得定律

不值得定律最直观的表述是:不值得做的事情,就不值得做好,这个定律似乎再简单不过了,但它的重要性却时时被人们疏忘。不值得定律反映出人们的一种心理,一个人如果从事的是一份自认为不值得做的事情,往往会保持冷嘲热讽,敷衍了事的态度。不仅成功率小,而且即使成功,也不会觉得有多大的成就感。
  哪些事值得做呢?一般而言,这取决于三个因素。
  1、价值观。关于价值观我们已经谈了很多,只有符合我们价值观的事,我们才会满怀热情去做。
  2、个性和气质。一个人如果做一份与他的个性气质完全背离的工作,他是很难做好的,如一个好交往的人成了档案员,或一个害羞者不得不每天和不同的人打交道。
  3、现实的处境。同样一份工作,在不同的处境下去做,给我们的感受也是不同的。例如,在一家大公司,如果你最初做的是打杂跑腿的工作,你很可能认为是不值得的,可是,一旦你被提升为领班或部门经理,你就不会这样认为了。
  总结一下,值得做的工作是:符合我们的价值观,适合我们的个性与气质,并能让我们看到期望。如果你的工作不具备这三个因素,你就要考虑换一个更合适的工作,并努力做好它。
  因此,对个人来说,应在多种可供选择的奋斗目标及价值观中挑选一种,然后为之而奋斗。“选择你所爱的,爱你所选择的”,才可能激发我们的奋斗毅力,也才可以心安理得。而对一个企业或组织来说,则要很好地分析员工的性格特性,合理分配工作,如让成就欲较强的职工单独或牵头来完成具有一定风险和难度的工作,并在其完成时给予定时的肯定和赞扬;让依附欲较强的职工更多地参加到某个团体中共同工作;让权力欲较强的职工担任一个与之能力相适应的主管。同时要加强员工对企业目标的认同感,让员工感觉到自己所做的工作是值得的,这样才能激发职工的热情。

  四、彼得原理

彼得原理是美国学者劳伦斯•彼得在对组织中人员晋升的相关现象研究后得出的一个结论;在各种组织中,由于习惯于对在某个等级上称职的人员进行晋升提拔,因而雇员总是趋向于晋升到其不称职的地位。彼得原理有时也被称为“向上爬”原理。这种现象在现实生活中无处不在:一名称职的教授被提升为大学校长后无法胜任;一个优秀的运动员被提升为主管体育的官员,而无所作为。

  对一个组织而言,一旦组织中的相当部分人员被推到了其不称职的级别,就会造成组织的人浮于事,效率低下,导致平庸者出人头地,发展停滞。因此,这就要求改变单纯的“根据贡献决定晋升”的企业员工晋升机制,不能因某个人在某一个岗位级别上干得很出色,就推断此人一定能够胜任更高一级的职务。要建立科学、合理的人员选聘机制,客观评价每一位职工的能力和水平,将职工安排到其可以胜任的岗位。不要把岗位晋升当成对职工的主要奖励方式,应建立更有效的奖励机制,更多地以加薪、休假等方式作为奖励手段。有时将一名职工晋升到一个其无法很好发挥才能的岗位,不仅不是对职工的奖励,反而使职工无法很好发挥才能,也给企业带来损失。

  对个人而言,虽然我们每个人都期待着不停地升职,但不要将往上爬作为自己的惟一动力。与其在一个无法完全胜任的岗位勉力支撑、无所适从,还不如找一个自己能游刃有余的岗位好好发挥自己的专长。

  五、零和游戏原理

当你看到两位对弈者时,你就可以说他们正在玩“零和游戏”。因为在大多数情况下,总会有一个赢,一个输,如果我们把获胜计算为得1分,而输棋为-1分,那么,这两人得分之和就是:1+(-1)=0。

  这正是“零和游戏”的基本内容:游戏者有输有赢,一方所赢正是另一方所输,游戏的总成绩永远是零。

  零和游戏原理之所以广受关注,主要是因为人们发现在社会的方方面面都能发现与“零和游戏”类似的局面,胜利者的光荣后面往往隐藏着失败者的辛酸和苦涩。从个人到国家,从政治到经济,似乎无不验证了世界正是一个巨大的“零和游戏”场。这种理论认为,世界是一个封闭的系统,财富、资源、机遇都是有限的,个别人、个别地区和个别国家财富的增加必然意味着对其他人、其他地区和国家的掠夺,这是一个“邪恶进化论”式的弱肉强食的世界。

  但20世纪人类在经历了两次世界大战,经济的高速增长、科技进步、全球化以及日益严重的环境污染之后,“零和游戏”观念正逐渐被“双赢”观念所取代。人们开始认识到“利己”不一定要建立在“损人”的基础上。通过有效合作,皆大欢喜的结局是可能出现的。但从“零和游戏”走向“双赢”,要求各方要有真诚合作的精神和勇气,在合作中不要耍小聪明,不要总想占别人的小便宜,要遵守游戏规则,否则“双赢”的局面就不可能出现,最终吃亏的还是自己。

  六、华盛顿合作规律。

华盛顿合作规律说的是:一个人敷衍了事,两个人互相推诿,三个人则永无成事之日。多少有点类似于我们“三个和尚”的故事。人与人的合作不是人力的简单相加,而是要复杂和微妙得多。在人与人的合作中,假定每个人的能力都为1,那么10个人的合作结果就有时比10大得多,有时甚至比1还要小。因为人不是静止的动物,而更像方向各异的能量,相推动时自然事半功倍,相互抵触时则一事无成。我们传统的管理理论中,对合作研究得并不多,最直观的反映就是,目前的大多数管理制度和行业都是致力于减少人力的无谓消耗,而非利用组织提高人的效能。换言之,不妨说管理的主要目的不是让每个人做到最好,而是避免内耗过多。21世纪将是一个合作的时代,值得庆幸的是,越来越多的人已经认识到真诚合作的重要性,正在努力学习合作。

  邦尼人力定律:一个人一分钟可以挖一个洞,六十个人一秒种却挖不了一个洞。
  合作是一个问题,如何合作也是一个问题。

  七、酒与污水定律

酒与污水定律是指,如果把一匙酒倒进一桶污水中,你得到的是一桶污水;如果把一匙污水倒进一桶酒中,你得到的还是一桶污水。几乎在任何组织里,都存在几个难弄的人物,他们存在的目的似乎就是为了把事情搞糟。他们到处搬弄是非,传播流言、破坏组织内部的和谐。最糟糕的是,他们像果箱里的烂苹果,如果你不及时处理,它会迅速传染,把果箱里其它苹果也弄烂,“烂苹果”的可怕之处在于它那惊人的破坏力。一个正直能干的人进入一个混乱的部门可能会被吞没,而一个人无德无才者能很快将一个高效的部门变成一盘散沙。组织系统往往是脆弱的,是建立在相互理解、妥协和容忍的基础上的,它很容易被侵害、被毒化。破坏者能力非凡的另一个重要原因在于,破坏总比建设容易。一个能工巧匠花费时日精心制作的陶瓷器,一头驴子一秒钟就能毁坏掉。如果拥有再多的能工巧匠,也不会有多少像样的工作成果。如果你的组织里有这样的一头驴子,你应该马上把它清除掉;如果你无力这样做,你就应该把它拴起来。

  八、水桶定律

水桶定律是讲,一只水桶能装多少水,完全取决于它最短的那块木板。这就是说任何一个组织都可能面临的一个共同问题,即构成组织的各个部分往往决定了整个组织的水平。

  构成组织的各个部分往往是优劣不齐的,而劣质部分往往又决定整个组织的水平。

  “水桶定律”与“酒与污水定律”不同,后者讨论的是组织中的破坏力量,而“最短的木板”却是组织中有用的一个部分,只不过比其它部分差一些,你不能把它们当成烂苹果扔掉。强弱只是相对而言的,无法消除。问题在于你容忍这种弱点到什么程度。如果它严重到成为阻碍工作的瓶颈,就不得不有所动作。

   如果你在一个组织中,你应该:
   1、确保你不是最薄弱的部分;
   2、避免或减少这一薄弱环节对你成功的影响;
   3、如果不幸,你正处在这一环节中,你还可以采取有效的方法改进,或者转职去谋另一份工作。

  九、蘑菇管理

蘑菇管理是许多组织对待初出茅庐者的一种管理方法,初学者被置于阴暗的角落(不受重视的部门,或打杂跑腿的工作),浇上一头大粪(无端的批评、指责、代人受过),任其自生自灭(得不到必要的指导和提携)。相信很多人都有这样一段“蘑菇”的经历,但这不一定是什么坏事,尤其是当一切都刚刚开始的时候,当上几天“蘑菇”,能够消除我们很多不切实际的幻想,让我们更加接近现实,看问题也更加实际,而对一个组织而言,一般地新进的人员都是一视同仁,从起薪到工作都不会有大的差别。无论你是多么优秀的人才,在刚开始的时候都只能从最简单的事情做起,“蘑菇”的经历对于成长中的年轻人来说,就像蚕茧,是羽化前必须经历的一步。所以,如何高效率地走过生命中的这一段,从中尽可能吸取经验,成熟起来,并树立良好的值得信赖的个人形象,是每个刚入社会的年轻人必须面对的课题。
  十、奥卡姆剃刀定律

如果你认为只有焦头烂额、忙忙碌碌地工作才可能取得成功,那么,你错了。

  事情总是朝着复杂的方向发展,复杂会造成浪费,而效能则来自于单纯。在你做过的事情中可能绝大部分是毫无意义的,真正有效的活动只是其中的一小部分,而它们通常隐含于繁杂的事物中。找到关键的部分,去掉多余的活动,成功并不那么复杂。

  奥卡姆剃刀:如无发要,勿增实体。

  12世纪,英国奥卡姆的威廉对无休无止的关于“共相”、“本质”之类的争吵感到厌倦,主张唯名论,只承认确实存在的东西,认为那些空洞无物的普遍性要领都是无用的累赘,应当被无情地“剃除”。他主张,“如无必要,勿增实体。”这就是常说的“奥卡姆剃刀”。这把剃刀曾使很多人感到威胁,被认为是异端邪说,威廉本人也受到伤害。然而,这并未损害这把刀的锋利,相反,经过数百年越来越快,并早已超越了原来狭窄的领域而具有广泛的、丰富的、深刻的意义。

  奥卡姆剃刀定律在企业管理中可进一步深化为简单与复杂定律:把事情变复杂很简单,把事情变简单很复杂。这个定律要求,我们在处理事情时,要把握事情的主要实质,把握主流,解决最根本的问题。尤其要顺应自然,不要把事情人为地复杂化,这样才能把事情处理好。

  十一、二八法则

你所完成的工作里80%的成果,来自于你20%的付出;而80%的付出,只换来20%的成果

  十二、钱的问题

  当某人告诉你:“不是钱,而是原则问题”时,十有就是钱的问题。

  照一般的说法,金钱是价值的尺度,交换的媒介,财富的贮藏。但是这种说法忽略了它的另一面,它令人陶醉、令人疯狂、令人激动的一面,也撇开了爱钱的心理不谈。马克思说,金钱是“人情的离心力”,就是指这一方面而言。

  关于金钱的本质、作用和功过,从古到今,人们已经留下了无数精辟深刻的格言和妙语。我们常会看到,人们为钱而兴奋,努力赚钱,用财富的画面挑逗自己。金钱对世界的秩序以及我们的生活产生的影响是巨大的、广泛的,这种影响有时是潜在的,我们往往意识不到它的作用如此巨大,然而奇妙的是:它完全是人类自己创造的。致富的驱动力并不是起源于生物学上的需要,动物生活中也找不到任何相同的现象。它不能顺应基本的目标,不能满足根本的需求 -的确,“致富”的定义就是获得超过自己需要的东西。然而这个看起来漫无目标的驱动力却是人类最强大的力量,人类为金钱而互相伤害,远超过其他原因。

joel spolsky给计算机系学生七点建议中的一条(zt)

毕业前学会写作

如果Linus Torvalds不懂如何布道的话,Linux会成功吗? 正象每一个黑客,Linus精通写作,他知道如何准确地在email和邮件讨论组中使用书面英语表达自己的思想,所以他能够从全世界召集大量志愿者为Linux工作。

你听说过最近风靡全世界的极限编程(Extreme Programming)吗? 即使你不懂什么是极限编程,你至少听说过这个词。为什么?因为宣传极限编程的人都是天才的作者和演说家。

就看看你身边的那些小型的软件开发组织吧,最有权力和影响力的人是那些可以用自信,准确,舒适的英语交流的人。好吧,我承认这些人也许言过其实,但是你无可奈何。

一个合格的程序员和一个伟大的程序员的区别不在于知道多少种编程语言,不在于他们是喜欢Python或者Java,而是在于他们是否擅长表达。他们能够说服,所以他们获得权力。他们能够写清楚明白的评论和接口文档,所以他们使得别人不用重写,而可以重用他们的代码,否则他们的代码就是毫无用处的。他们也能够写出清晰的用户手册,于是最终用户可以理解他们的代码是做什么用的,明白了他们的工作的价值。sourceforge埋葬着许多精美的代码,这些已死的代码无人使用,因为代码的作者很少写(或者根本不写)用户手册。

我不会雇佣一个不懂写作的程序员。如果你擅长写,你就很容易找到工作,紧接着你就会被要求写技术规格文档,这意味着你已经被管理层注意到了。

大学里有一些课程,要求你做很多的写作练习,不要犹豫,赶快参加这些课程。不要错过任何要求你每周或者每天练习写作的课程。

给自己建立一个网络日志(weblog)。在上面写的越多,你会写地越容易。写地越容易,你就写地越多,这是一个正向地循环激励。

November 07

vs2003,安装程序检测到另一个程序要求计算机重新启动...

vs2003,安装程序检测到另一个程序要求计算机重新启动...
2006年10月31日 星期二 下午 01:55

今天一个朋友在新买的Dell640M上安装Visual Studio .Net 2003,结果出现提示:“安装程序检测到另一个程序要求计算机重新启动.必须重新启动计算机后才能安装visual studio.net系统必备.系统重新启动后,你需要重新启动安装程序.单击"确定"重新启动,单击"取消"退出安装程序。”,折腾了一下午,重新启动了N次计算机,死活安装不上,而且找不到源头。怎么办?Google一下吧,得到答案如下:

在注册表删除HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\pendingfilerenameoperations

原来是朋友之前安装Acrobat后立即联机更新,更新程序要求重新启动后继续安装,中止了它,结果就成了上面这个样子。

特此提醒需要在同一台机器上使用Acrobat和Visual Studio .Net 2003的朋友注意。

July 28

DFW的技术规划

DemoFramework(DFW)
主要参考springside。但是融入后会逐步消化改进。
 
DB:My sql 5.1
 
devtools:wtp1.5+myeclipse5m2+一堆乱七八糟的插件。
 
管理工具:jabber,jira,confluence,discuz!
 
JDK: JDK5.0
应该说,这个还是挺有技术风险的。因为websphere6.1不支持。他们用自己的ibm jdk1.4.2,挺让人头痛的。将来试试Retrotranslator是否可行。
JaveEE Framework: Spring2
 
 
ORM Framework: hibernate 3
 
 
MVC Framework:webwork2.2.2
 
 
Web Service: Xfire
 
 
规则引擎: JBossRules3
可以用来做提醒的规则
 
JMS: ActiveMQ+Jencks+Lingo
用来做短消息 
 
Search Engine: Compass+Lucene
搞几个快速查询用
 
Workflow: JBpm
 考虑用来描述业务流程。
 
其它功能需求:
 
 
打印:可能直接用js+html
 
 
portlet:陈志强说webwork里面就有可用。
 
 
通用查询组件:选择张伟做的or自己从头开发。
 
 
ajax:没有想好,应该是DWR吧
 
 
报表:没有想好,也许可以趁机摸一下BIRT。
 
 电子表单:现在没有好的解决方案,infopath和xform都缺胳膊少腿
 
 
 
July 02

MzTreeView 1.0 开发文档(zt)

MzTreeView 1.0 开发文档
文档
开发文档: http://www.meizz.com/Web/Article.asp?id=436
控件下载: http://www.meizz.com/Web/Download/MzTreeView10.rar
应用示例: http://www.meizz.com/Web/Demo/MzTreeView10.htm
说明
MzTreeView 1.0 是数据一次性加载,客户端节点异步展示的WEB脚本树。MzTreeView 1.0 的理论节点数设计上限为十万节点,在节点数三万的情况下页面打开时间小于 3 秒。无限层次无限节点的数的层级组成方式:id parentId。即每个节点除本身的节点id之外还有它的父层节点id,通过这种方式就可以组合成无限层级的树了。

在 MzTreeView 里都有一个虚的根节点,其ID为0,用户可见的根节点其父节点ID皆为0

MzTreeView 1.0在数据库库表里的字段名称:
字段名 字段的具体说明
id 节点ID(不可为0,可以是数字或字符)
parentId 本节点的父节点ID(若本节点已为根节点,此处填0)
text 节点的显示文本(一般不允许为空,不过有一种情况例外,即根节点,若根节点文本为空,这个根节点将不会在页面里显示)
hint 节点的说明注解
icon 节点的图标,MzTreeView 1.0允许每个节点拥有不同的图标(对应的名字在类里的icons和iconsExpand定义)
data 节点挂的数据,格式是 param=value&param=value&... url里?后的那串字符串格式,
url 每个节点允许拥有不同的链接,它为空或者为#时,树里这个节点的链接,点击将无反应
target 每个节点的链接允许在不同的target里打开,为空时取类里的默认值
method 点击该链接时所想触发的脚本语句
特注:每个字段值中不可有冒号: 不可以换行 引号酌情考虑应不与节点字符串的引号相冲突

设计模式
为了达到能够在浏览器中快速打开多节点树的页面,我做了很多的优化与创新,下面我将详细解说几项最重要的部分:

  • 数据一次性加载 首先我要说的就是数据的一次性加载。在目前的 B/S 架构开发中对于多节点多层次的树,特别是树节点量超过两千的情况下,几乎都是采取数据异步加载来达到目的,即用户需要展开某个节点时,再从服务器端加载下级子节点的数据,数据异步加载最为经典的例子就是 MSDN 网站左边的目录树了。异步加载的优点在于可以扩充到无限级无限节点树,树的数据来源可以多样化(数据库或XML文件)等,但是它的缺点也是非常多的:设计模式比数据一次性加载要复杂得多,要考虑到 Browser/Server 之间的应答,要判断子节点是否含有孙节点,后台数据源的层级关系模型等。对网络传输的信赖性太大,每个节点的展开都需要连一次 Server,只要在取某节点数据时网络出现问题,就会导致该节点及其以下的子节点加载失败。而采取数据一次加载的模式只要一次加载成功,服务器就可以不用管它了,服务器压力减轻,脚本设计则完全独立,对整棵树节点的检索可以在客户端完成,节点展开响应速度快等等优势,因此在节点数不多的情况下数据一次性加载更有优势,那么这个节点数不多不多到底多少节点量为平衡点呢?就 ASP.net 里带的那个 TreeView 来说,在一两千节点以下一次性加载比较具有优势,而 MzTreeView 1.0 在节点量三万至五万以非常具有优势。

  • 节点信息的压缩传输 在浏览器里显示的树结构其实都是一个个 HTML 元素组合起来的,在 WEB 页面里的树都是根据树节点的信息组合成一串的 HTML 元素列来显示,这一步从节点信息到 HTML 的转化可以在两个地方生成:一个是在服务器端,一个是在客户端。在服务器端生成的优点在于不须考虑客户端的浏览器的兼容性,节点信息的可控性非常强,但是它的缺点也是非常大的:加重服务器的负担,增加网络传输量。在服务器端直接生成树节点的 HTML 给服务器带来的压力是显而易见的,也是非常巨大的,估计只要有几十个并发连接就能让服务器暂时停止响应了。这种直接在服务器生成树的做法在实际运用环境中也有人使用,不过本人非常不赞成这种做法。当然也有人直接将树生成为一个静态文件放在服务器端,这种做法对于树节点相对固定不变的情况还是非常有利的,只需要生成一次,以后就不需要再生成了,服务器的压力也非常小,但它的弊病在于可变化性太小,比如说不同的权限能看到的树节点的不同这种情况,用这种生成静态树放在服务器端的做就没有办法解决,且不管是服务器端动态计算还是直接生成静态树文件放在服务器端都有一个避免不了的问题就是网络传输量巨大。可以计算一下,一个树点所需要的HTML字符量大约300到600字节之间。即含有一千节点的树的网页大小就有300K到600K,给网络造成的压力是非常巨大的,所以MzTreeView 1.0采用了节点信息的压缩传输,大至一千节点的总传输量在30K左右,这可以差了一个数量级呀。本树将每个节点所必要的信息组合成一个字符串序列,传递到客户端,然后在客户端再用客户端脚本对这些信息进行分析,再生成一个个的节点HTML,这也符合了WEB的分散计算的原理,当然服务器端可以有选择性输出部分节点,这样又做到节点的灵活多变性。

  • 传输的节点信息的可扩展性 服务器端将节点的必要信息组合成一个字符串序列传递到客户端,然后客户端再用脚本对这个字符串序列进行分析,生成树的节点,那么这个字符串序列对整个树的生成的效率就有重要的影响了。我也参照过很多组串传输的例子,在一般的做法当中大多采用函数的参数方式传递。比如说定义一个函数 funName(p1, p2, p3, ...),然后服务器组串的时候就按位置给定数据。这种组串的弊病是非常大的,首先就是位置绝对错不得,只要有一个位置数据出错,这个节点的信息就乱了,对于那些在函数里已经定义的但节点里没有的信息也得用空字符串补上,诸如:(p1, "", p3, p4, "", "", ""),且万一这种组串的对应分析函数发生了变化,那么这种串就算是废了,得重新定义服务器端的字符串位置序列了,可以说这种组串的方式可扩展性极差。
        节点信息组串传输的另一种常用模式就是XML。XML以它的无限可扩展性已惭有代替HTML称霸WEB的味道了。XML最大的优点就在于它的无限可扩展性,可以用任意的TagName名,可以有任意的Attribute名,节点与子节点已经有层级的关系,用XML来做WEB树的数据源其实是最理想的,MSDN的资源目录树就是采用XML作为传递的字符串,它唯一的不足之处就是不是所有浏览器都能很好地支持它,特别是在一些低版本的浏览器中,所以我只好忍痛割爱没有启用XML作为中间的传媒。那么是不是有可能结合XML的扩展性对第一种组串的方式进行改进呢?当我愁眉不展的时候,HTML里的STYLE样式表写法跳入我眼,样式的写法是"param1: value1; param2: value3; ...",哈哈,这不是现成地给我指明了路吗?这种写法拥有XML的可扩展性,位置顺序的随意性,又是传统的长字符串,正合我意也!服务器给定这种数据源字符串,我不光可以在TreeView里用它,还可以直接做Outlook Bar,下拉式层级菜单,右键层级菜单的数据源,豁然开朗也!我写了一个函数专门解析这种文本:getAttribute()。

  • 客户端节点数据的存储方式及快速检索 现在数据源准备好了,数据传输也已做到最大优化了,下面就是客户端的脚本解析了,而这一步也正是树生成的效率瓶颈所在。由于我没有采用XML做为数据源,所以我这里就不讨论XML+XSL和XMLDOM的模式,而只考虑HTML+DOM模式了。在HTML+DOM模式下客户端存储的方式有很多种,我就曾经看到过一种直接将字符串输出在多行文本框<textarea>里的,但归究起来最常用的方式就是用一个数组来存放节点信息,不过就算是用数组也是种类多多,比如说数组里套数组,节点通过记录父节点在数组里的索引号表示层级的等等,说到数组存放树节点模式,我推荐阿信写的那棵树。在服务器端组织好脚本及节点字符串,客户端浏览器加载这个页面的时候顺序执行其里面的脚本,将一个个节点做最初步的解析,然后再一个个地ADD到数组中去。这种流程看起来似乎没有什么问题,在很多的传统C/S结构编程中也就这种模式,但是随着节点数的增多,这种流程在B/S里的缺点就出现了:脚本的执行效率不如强语言高!我做过测试,在5000节点的数据量时这一步操作将耗时1秒钟,也许你认为这1秒钟不算长,哪里有5000这么多节点的树?但对于一个程序员来说,严谨是第一位的,若存在优化的可能性,情况出现的可能性,我们就得将它考虑到。那么有没有可能再进一步优化呢?当然有,否则我就用不着这么大费口舌在这里讲了。既然在脚本里执行 for 循环插入数组效率不高那我不用循环,且考虑到在数组里这么多节点中搜索我想要的某几个节点,还得用循环,所以我干脆就不再用数组来存放树节点了,那用什么呢?说到这里我得插几句题外话,客户端脚本也可以写一些类,虽说写出来的类没有强语言那么好,继承性不好等,但脚本终究还是可以写出一些简单的类的。类可以定义属性,也可以定义方法,并且访问属性的时候可以通过属性名下标直接访问到属性值,关于脚本里如何写类,大家可以参考我在JavaScript和VBScript里对这方面的详细说明。呵呵,说了这么多的题外话,不过相信大家也猜到了,新的节点存储方式就是类的属性自定义扩展方式。这种存储方式随着页面的打开,页面里的脚本被执行,类的属性值不需要做任何添加的动作就直接写到内存当中,比数组模式少去了ADD操作,这一步从字符串到内存的时间就是页面打开的时间,我测试了一下,5000节点的树用这种方式打开,只需0.1秒呀,与数组模式速度整整差了一个数量级呀!且这种模式还有一种好处,在几千个节点里要找到目标节点,只需要知道节点对应的属性名,一步就可以直接找到。
        客户端树节点存储模式说清楚了,那节点的快速检索也就清楚了。已知节点名即在类里的属性名的话,一步就找到了该节点,不过为了配合下一节的异步展示,我的检索就没有这么简单了。试想在几千或者几万个节点里要快速地找出符合条件的几十个节点,这一步的耗时可想而知了,首先就得排除for循环法,for循环的效率在数组模式里大家就看到了,这一步操作特别在总节点数多的情况下就能让使用者等疯掉,显然得另想办法。于是我想到了正则表达式里的字符串模式匹配match(),我将所有的节点名(即类的属性名)join()成一个大字符串,然后再用正则表达式匹配,一步就找出了想要的节点了。经测试,在三万节点里找30个节点对象耗时小于0.1秒!

  • 异步展示 再来讲一下节点字符串被解析之后转化成HTML元素的这一步操作。上面已经有过一个计算,表达1000节点的树的HTML字符量就有300K-600K之多,且这一步只能一个节点一个节点慢慢地生成,没有什么取巧的办法,想快点也只能是减小单个节点的HTML元素量罢,不过最快也得1-3秒每千节点呀,这也是没有法子的事,谁叫DOM的效率不高呢!总得想个什么法子吧,否则象5000节点量的树让使用者等上个半分钟一分钟的,谁也受不了呀!因此我想出异步展示这招:页面加载时并不立即生成所有节点的HTML元素,而是用户展开多少节点就生成多少节点,节点的生成发生在用户展开这个节点的时候。使用者在页面打开的时候并不会立即把所有的节点都一次全部展开,而是一级级地往下展开的,就象你查看windows注册表一样,想看哪级才会去展开哪一级,这样我就只需要在你展开那级的时候把这一级的节点转化成HTML即可,每次转化的节点只有几十分甚至只有几个而已,消除了使用者的等待时间。经过上面这几个环节,终于一棵实用性,效率,扩展性俱佳的WEB TreeView出世了。

  • 采用文字竖线 每个浏览器随着使用客户的不同,而总会产生不同的设置,其中有一项就是客户端设置每次访问都检查网页新版本,即客户端不缓存。这个设置对一般的应用来说问题不会很大,但是对于使用图片作为竖线的树来说随着节点总数的增多,图片的使用量也就跟着巨量增加,可能会使用几千甚至几万个小图片,每张图片是都很小,但量一大的话,将会严重影响树的快速展示,因此针对这种情况就得换一种模式来展现了,那就是文字竖线,用文字加样式就可以解决这个问题。我加了一个变量:MzTreeView.wordLine(布尔型,默认值为false),当网速过慢或者没有使用本地缓存时这个属性会自动设置成 true 而以文字代替图片完成竖线(注:Opera 浏览器不支持文字竖线模式),当然你也可以一开始就强行设置值为 true,这样树就会始终用文字竖线了。
属性
MzTreeView 类的一些属性:
属性名 类型 属性的具体说明
MzTreeView.nodes 集合 服务器端给树指定数据源时数据存放的对象,具体存放格式如:
MzTreeViewHandle.nodes["parentId_nodeId"] = "text: nodeText; icon: nodeIcon; url: nodeURL; ...";
MzTreeView.url 地址字符串 可读写,树缺省的URL,默认值是 #
MzTreeView.target 目标框架名 可读写,树缺省的链接target,默认值是 _self
MzTreeView.name 字符 只读,树的实例名,同树实例化时作为参数传入(大小写敏感):
var Tree = new MzTreeView("Tree");
MzTreeView.currentNode 树节点 只读,树当前得到焦点的节点对象
MzTreeView.icons 集合 树所使用的所有图标存放
MzTreeView.iconsExpand 集合 树里展开状态的图标存放
MzTreeView.colors 集合 树里使用到的几个颜色存放

MzTreeView 在客户端的节点所拥有的属性:
属性名 属性的具体说明
node.id 数字文本,节点的ID
node.parentId 数字文本,节点对应的父节点ID
node.text 文本,节点的显示文本
node.hint 文本,节点的注释说明
node.icon 文本,节点对应的图标
node.path 文本,节点在树里的绝对路径:0_1_10_34
node.url 文本,该节点的 URL
node.target 文本,该节点链接的目标框架名
node.data 文本,该节点所挂载的数据
node.method 文本,该节点的点击对应处理语句
node.parentNode 对象,节点的父节点对象
node.childNodes 数组,包含节点下所有子节点的数组
node.sourceIndex 文本,服务器给予的数据里对象的 parentId_nodeId 的组合字符串
node.hasChild 布尔值,指该节点是否有子节点
node.isLoad 布尔值,本节点的子节点数据是否已经在客户端初始化
node.isExpand 布尔值,节点的展开状态
方法
MzTreeView 类的一些方法:
方法名 方法的具体说明
MzTreeView.toString() 类的默认初始运行
MzTreeView.buildNode(id) 将该节点的所有下级子节点转换成 HTML 并在网页上体现出来
MzTreeView.nodeToHTML(node, AtEnd) 将 node 转换成 HTML
MzTreeView.load(id) 从数据源里加载当前节点下的所有子节点
MzTreeView.nodeInit(sourceIndex, parentId) 节点的信息初始,从数据源到客户端完整节点的转化
MzTreeView.focus(id) 聚集到某个节点上
MzTreeView.expand(id[, sureExpand]) 展开节点(包含下级子节点数据的加载初始化)
MzTreeView.setIconPath(path) 给节点图片设置正确的路径
MzTreeView.nodeClick(id) 节点链接点击时同时被触发的点击事件处理方法
MzTreeView.upperNode() 跳转到当前聚集节点的父级节点
MzTreeView.lowerNode() 跳转到当前聚集节点的子级节点
MzTreeView.pervNode() 跳转到当前聚集节点的上一节点
MzTreeView.nextNode() 跳转到当前聚集节点的下一节点
MzTreeView.expandAll() 展开所有的树点,在总节点量大于500时这步操作将会比较耗时

示例
<script language="JavaScript"
  src="http://www.meizz.com/Web/Plugs/MzTreeView10.js"></script>
<base href="http://www.meizz.com/Web/">
<style>
A.MzTreeview
{
  font-size: 9pt;
  padding-left: 3px;
}
</style>
<script language="JavaScript">
  var tree = new MzTreeView("tree");

  tree.icons["property"] = "property.gif";
  tree.icons["css"] = "collection.gif";
  tree.icons["book"]  = "book.gif";
  tree.iconsExpand["book"] = "bookopen.gif"; //展开时对应的图片

  tree.setIconPath("http://www.meizz.com/Icons/TreeView/"); //可用相对路径

  tree.nodes["0_1"] = "text:WEB 编程";
  tree.nodes["1_100"] = "text:代码示例; data:id=100"; 
  tree.nodes["1_200"] = "text:梅花雪脚本控件集; data:id=200";
  tree.nodes["1_310"] = "text:CSS; icon:css; data:id=310"; 
  tree.nodes["1_320"] = "text:DHTML; data:id=320"; 
  tree.nodes["1_300"] = "text:HTML; data:id=300"; 
  tree.nodes["1_400"] = "text:JavaScript; icon:book; data:id=400";
  tree.nodes["320_322"] = "text:属性; icon: property; data:id=322"; 
  tree.nodes["320_323"] = "text:方法; data:id=323"; 
  tree.nodes["320_324"] = "text:事件; icon:event; data:id=324"; 
  tree.nodes["320_325"] = "text:集合; data:id=325"; 
  tree.nodes["400_407"] = "text:对象; data:id=407"; 
  tree.nodes["400_406"] = "text:方法; data:id=406"; 
  tree.nodes["400_408"] = "text:运算符; data:id=408"; 
  tree.nodes["400_409"] = "text:属性; data:id=409"; 
  tree.nodes["407_1140"] = "text:Date; url:Article.asp; data:id=140";
  tree.nodes["406_1127"] = "text:toString; url:Article.asp; data:id=127";
  tree.nodes["408_1239"] = "text:||; url:Article.asp; data:id=239";
  tree.nodes["409_1163"] = "text:E;  url:Article.asp; data:id=163";

  tree.setURL("Catalog.asp");
  tree.setTarget("MzMain");
  document.write(tree.toString());    //亦可用 obj.innerHTML = tree.toString();
</script>
  
June 11

The JACOB Project: A JAva-COM Bridge

The JACOB Project: A JAva-COM Bridge

Now you can call COM Automation from any Win32 Java VM using JNI

What Is JACOB?

JACOB is a JAVA-COM Bridge that allows you to call COM Automation components from Java. It uses JNI to make native calls into the COM and Win32 libraries. The JACOB project started in 1999 and is being actively used by thousands of developers worldwide. As an open-source project, it has benefitted from the combined experience of these users, many of whom have made modifications to the code and submitted them back for inclusion in the project.

http://sourceforge.net/projects/jacob-project/

June 10

eclipse 中 Subversion 切换 帐号登陆 (zt)

在刚刚使用svn 的时候遇到了点麻烦
研究解决之 发文 提醒各为 少走写弯路

我用的eclipse 的svn 插件

最初的时候下代码的时候 使用easyjf 这个帐号 点了 保存用户名和密码

后来申请到自己的帐号
就出现了切换不过去了的问题 郁闷了2天

我试了 废弃 重新定位
甚至 我把eclipse 整个删除了

都不行
现象是一新建 资源库  不用用户名和密码 就登陆进去了 登陆进去后没有任何权限

四处询问 如何解决 WilliamRaym 一句话(可能不在eclipse文件夹里存了登陆信息) 提醒我
最后终于在
C:\Documents and Settings\sagitta\Application Data\Subversion\auth\svn.simple

这里找了到  进去修改用户名密码  
然后一切正常了  

发文 提醒各位 少走些弯路
 
Photo 1 of 36