其实我说的不是这个意思，我想起了高中时候的一件事。

我上课一向不太认真听讲，而老师往往喜欢考他在课上讲过的东西，所以常常出现某个题目全班只有我一个人做错的情况。这种情况往往令老师哭笑不得，因为考第一的人干这种事情，实在是十分令人痛恨的，会坚决动摇其他人认真听课的决心。

某次英语课，老师讲，poor这个单词啊，要注意了，它的名词形式很特别，叫做poverty，我当时没听，结果就考了，我写poorness。老师讲卷子，说注意啦，我们有些同学呢，上课不认真听讲，我不是说了么，是poverty，不是poorness。结果我又没听。

下次又考，我又写poorness，可怜这次只有我这么写了，老师大怒，徐飞你怎么回事，这个我讲了2次了！我战战兢兢，汗不敢出。

结果这老师不死心，他还考，我也真不争气，我硬是没记住咋写的，不过我记住不是poorness了，于是咬了半天笔杆子，决定写了一个poorlessness……

结果，咳，不说了，总之老师崩溃了，这种学生都能让他碰到，一定很郁闷。

再说说另外一个，某语文老师，他考错别字，县和具，问里面分别有几横，我不记得啊，结果老师讲了，说县是2横，具是3横啊，下次考，我竟然又错了。老师暴怒，说哪有你这样的，你给我记好了！

接着还考，嘿，这老师很阴，因为是手写蜡纸做的卷子么，他故意把那字写错了，说这个是不是错别字？我一想，你都写出来了，怎么会错呢，于是一选选了个别的，于是，他所教的每个班都知道有我这么一号顽劣之人了。

现在回头想想，我这人怎么这样，换我自己教，一定也很生气。希望将来我要是有了儿子，他能够有所改进。

星期六去上海宜家转了一圈。

早上4：30就起床，吃了几个鸡蛋，然后打车出发，5：40到达总统府，等待了二十分钟，开始开车。一路上也没什么特别的，就一直走一直走。

10点的时候，到了宜家，正好他们开门，里面人好多啊，我比较怕人多的地方，每次到了这样的地方，就会莫名其妙地烦恼，而且暴怒，要很努力地控制自己的情绪才能平静下来，真是一件很讨厌的事情。

说实话，里面还是有不少东西很让我满意的，不过这次最惨的事情就是忘记带银行卡了，所以导致什么都没买成，晕啊。

唉，没法啊，只好随便转转了，中午就在那个餐厅吃饭，我的天，人真叫一个多啊，先排队，排了好一会，然后出来找座位，找了好多好多地方，就是找不到，耐心啊，最后当然是终于吃到饭了～

下午继续逛，精神已经非常不好了，逛了一会就出去发呆，外面很热，坐到车子里面去等，没开空调，用手机上QQ群聊天，看space，发觉我的space还是没几个人顶，失败啊，为啥我越认真写的东西，看的人越少呢。

不一会大家都陆续回来了，不管怎样都买了些东西，好像空手的就只有我们了，某人不停地抱怨，说唉呀都怪你，白来了啊，我说是啊是啊，白来了。

星期天去房子看了下，上次的问题完全没整改，找了装修的负责人来看，他说没问题，这些都是小事，下次来的时候一定看不见了，关键是得赶紧把空调热水器油烟机先装起来，不然以后弄坏了水电之类的，不太好处理。

貌似有道理，然后我们就直奔苏宁去买电器，一个奥克斯空调，一个海尔热水器，一个美的油烟机，下周来装。赠送了一堆菜刀啊，铲子啊，勺子之类的，好像比较有用。

顺便看了一下电视机，发现现在的电视机怎么这么便宜了，考虑是不是买一个液晶显示器，然后弄个台式机回来用，装电视卡来看电视？这个不着急，以后再说了。

另外报告一个凄惨的事情，我手机由于聊QQ过度，左功能键和摇杆的向上和确定这三个键不太灵了，要使劲按才行，这才多久啊，我现在穷得没钱换手机啊，我的天，至少撑到明年我缓过来吧。

数据的组织其实是一件很有趣的事情。

基本的数据结构，在各种书里面都有讲到，比如数组啊，堆栈啊，散列啊，集合啊，树啊，这些都很常用，并且由它们构成了很多接近实用的东西。我来说说我对文档对象模型的理解吧。

文档对象模型，所谓的Document Object Model，提供的是一套完整的对于层次化数据的封装，它的内部实现还是基于树的，描述了整个文档的组织结构，提供了一系列的属性和方法用于访问特定元素。

我不太清楚DOM的内部实现，想试图通过我的理解，用我希望的方式，从无到有地实现它。

就拿一个XML来说吧，它的结构是树的形状，这是没有疑问的，那么数据的存储也应当是层次化的，每一个节点保持了自身的父节点的一个引用parentNode，同时对它的直接子节点保持着有序的引用childNodes，这应该是一个双向链表关系。于是，我们很容易地就把这个树构造出来了。

现在我们来考虑一个问题，节点是有属性的，比如说name属性，也会有唯一的标识id，如果我想要给外界提供这样的方法，比如说getElementById，可以通过给定的id来获取对应节点的引用，或者说，我要提供getElementsByName，用过给定名字来获取满足条件的节点引用的一个集合，这一步要如何去做？

很自然的一个想法是遍历树，遍历树的一个非常自然的想法又是递归，逐次去向下寻找，这个办法好不好呢？我觉得是不好的，因为在元素很多的情况下，递归层次多了之后，会导致栈溢出，而且这个效率不敢保证。我的想法，是在根节点的层次，另外保持一个引用集合，这个集合保持了所有节点的引用，查找的时候从这个集合去找。

很显然这需要开辟额外的内存空间，但是查找的时候，同级查找效率必然要比递归高，属于典型的空间换时间方法，在应用软件的场合，内存开销一般不是首要考虑的，而是要节约CPU，所以这种做法是值得使用的。

这个做法，也带来了一些麻烦，那就是维护整个树的时候，需要同步更新这个顶层节点集合。再从另外一个角度讲，如果要求对每个节点，都提供查询它所有子节点的操作，那是不是每一个节点都需要保持它的所有子节点的一个引用呢？

这么一来，内存开销可就大了，用个例子算一下看看，假设有一个树，每个非叶子节点都有2个子节点，典型的1248结构，这种叫做什么？完全二叉树吗？我忘记了。记得的人提醒一下。

如果每个节点都需要保持自己父节点和直接子节点的引用，那么总的引用的个数就是：2＋2×3＋4×3＋8×1＝28，如果需要除了保持自身父节点和直接子节点的引用，还需要保持所有子节点的引用，那总的引用的个数就是：28＋14＋2×6＋4×2＝62，如果把树的层次加大，那么上层节点所需要保持的引用个数就多得惊人了。

假如我来设计这个东西，那我绝对不会在每一个节点上保存它所有子节点的引用。不但如此，设想一下如果保存了这些引用，那最底层的叶子节点发生变化之后，它的所有父系节点都必须跟着更新引用，当树的层次比较深，而且叶子节点操作频繁的时候，是相当恐怖的。既然这样，那就只在根节点上保存所有节点引用就可以了吧。

好，解决了这个问题之后，来看下另外一个东西：一个节点如何访问到它的兄弟节点。很显然它已经不用保持兄弟节点的引用了，因为它有父节点的引用，从父节点查询到所有子节点，除去自身，就得到了兄弟节点的集合了，对吧。这里我有一个疑问，节点自身，是否需要存放它在父节点中的序号？

这是什么意思呢，某一个节点，我要获取它的nextSibling，这一步如何做到？哦，就去查询到它父节点的子节点有序集合，然后挨个找，当发现自己之后，下一个就是nextSibling了，对吗？对确实很对，不过考虑一下如果，这个节点的兄弟节点非常非常多，比如说100000个，而它自身是第99999个，那是不是做这次循环会非常傻？假设节点上保存了序号，就是说它知道自己是父节点的子节点中的第99999个，index=99999了，那我是不是可以用parentNode.children[index+1]这种方式来直接获取nextSibling呢？

这个我不知道了，应该也是需要权衡的。嗯，整个DOM的建立，其实并不复杂，关键的就是数据如何组织，很大程度上，是空间跟时间综合考虑之后进行的取舍。

另外这个XPath也很有意思，它提供的是从上而下按照路径的访问，这就要求访问的时候对于文档的结构必须非常明了。

i+++++i+++++i+++++i++技术人员与非技术人员分隔线++i+++++i+++++i+++++i

现在开始用生动形象的语言复述一遍：还是拿军队做比方，假设整个DOM结构就是一个集团军的组织结构，很明显这个组织结构是树的形状的，最顶层是司令部，下面是军部、师部，一直到士兵。每个单位都是必然知道它从属于哪个单位的，又必然是知道它领导了哪几个单位的（假如有的话）。

现在我考虑的问题是，我到集团军的司令部，向他们查询所有名字叫做“张三”的士兵，如果他们经常面临这样的查询，那最好的方法并不是联系各军部，叫他们把各自的叫做“张三”的士兵的情况上报，而如果这样，他们也是必然一级一级从下面汇总上来的，这个过程太慢了。那司令部就需要保持一份名单：本集团军所有人员名单。这样我可以直接在这里查到所有名字叫做“张三”的士兵，而不需要经过那个繁琐的过程。

但是我怎么确保司令部的这个名单是确定无误的，没有出现士兵退伍了没有在这里注销，或者有新的叫做“张三”的士兵入伍了，却没有登记到这份名单上来呢？那就要建立严格的制度，底层每次有任何人员变动，都必须上报。

我考虑的另外一个问题就是，既然集团军司令部有了自己所有下属人员名单，那么各军部，师部之类的，是否也需要拥有自己的所有下属人员名单呢？在实际情况中，这当然并无不可，但是考虑到在计算机中，所有信息的存储都是需要空间的，而且更新是一个很烦恼的事情，这样，每个士兵的情况变动，就必须从连排一直更新到司令部了，这太繁琐了，还是直接上报一下司令部备案算了。

我刚才说到的另外一个问题就是，某个单位，是否需要知道自己是在上级单位中的序号，假设有一个8连，按照现在三三编制，它显然是3营第2个连队，但是如果不是三三编制，而是一个上级单位都可以有若干个下属单位呢，它是否需要每次去上级单位找一下当前的配属部队列表，然后数一下自己是第几个？另外一种方式就是，上级单位如果又加入了新的下级部队，它对现有的下级部队进行重新排序，然后把序号告诉他们，让他们自己去记住。这也是可以的。这样，我问某连长：你是你所在营的下一个连队是哪个？他去问他上级的时候，就不必把所有兄弟连队都查出来，然后一个一个数了，而是可以直接问：第三个连队是哪个连？（假设他知道自己是第二个连队的话）当然，如果从现实生活中来看，这样也是非常傻的，呵呵，比方而已。

那么这个XPath相当于什么呢，就好比说，我跟司令讲，叫第2军第3师第4团的所有营长过来跟开会，然后他就直接按照这个路径去找人了，这当然要求我对整个编制结构非常熟悉才能做到。

另外有一个问题，你问某士兵，你的编制序列是什么？他说，某军某师某团某营某连某排某班。那现在把他这个团及其下属人员都直接调走了，去别的师了，不告诉他的话，他是不会知道的。对人来讲当然很简单，召集全团开个会，通知一下这个事情就可以了，对程序来说，就挺麻烦的，得遍历刷新一次，所以子节点是不宜保存他自身从根节点开始的全路径的，动态查询比较适宜。

总而言之，DOM树的效率，关键在两个地方的取舍，1是多保存数据，查询的时候可以减少时间，但是更新的时候会比较麻烦，效率也低，2是只保存必要数据，这样不容易出错，查询的时候要耗一些时间。两者是矛盾的，就看使用的时候更在乎什么了。

昨天这晚上，实在太恐怖了，打雷闪电啊，照理说对我也没啥影响，可是我忘记关窗子了，这就太痛苦了。 一个惊雷把我弄醒，然后我很是考虑去关个窗子的，一条闪电华丽地从窗外飘过，我随即打消了这个念头，不敢冒险啊… 然后就一直哗啦啦，轰隆隆，多么可爱的一个夜晚。早上起来我不敢开电脑，用手机发一个，立此存证~

上个星期六去收了房子，一大早就去了，等了半天，约好的几个人还不到，后来终于来了，然后开始办手续。

验房子的人开始一家一家验，我们是第6个，验一个房子要好久好久，也发现好多问题啊，有一个邻居，我晕啊，他家卫生间的布局，那叫一个强，要是萨达姆躲这里，估计布什亲自来都搞不定。里面那么多那么的拐角，竟然还不是规则图形，虽然比我的卫生间大，但是看来感觉还没我的好。

然后什么墙上没刷好啊，地板鼓起来啊，等等等等，看得心里发凉啊，好容易到了中午，开始验我的小屋了，咳，问题好像也不少。地板是不平的，门不太好开，猫眼是坏的，卫生间下水道不通，总之，很无语……不过整个房间的通风和采光还不错，这些鬼问题整改了之后，应该可以凑合住住了。

嗯，就这样啊，等待整改结束，然后去买几个家具回来，晾晾之后就搬进去。虽然屋子小，但是毕竟是自己的，赫赫，好哎。

工作调动的事情，貌似就这么确定了，要开始干新的活，等待ing，战斗吧！！！

再说说对于微软流程引擎的研究情况，发现了一个东东叫做WorkflowMarkupSerializer，原来它也是可以从标记语言转换到流程定义的，有了这个那就太好了，就意味着，也可以用脚本语言实现对它的web化建模，然后上传到服务端用WorkflowCompiler来编译成动态链接库，进行调用。也就是说，整个流程从创建到运行，是可以脱离vs.net这个开发环境的，那真不错。