语源科技BlogJava-傻瓜纯洁思想里的沙子

上班咯！！

哈迪尤 — Sun, 08 Oct 2006 02:27:00 GMT

         十一长假过完了，昨天挤火车也累得够呛，用一句流行的生存语言描述“累得像狗一样”。
         今天看了林锐的一篇文章，感觉讲的很好，简直是精华，可惜是ppt，不能完全展示，从里面摘录一些话出来勉励自己：

青年白领阶层小康了吗

u 改革开放20年之后，中国基本上解决了全民的温饱问题。现在国家提出了“全民奔小康”的奋斗目标。所谓“小康”是指全国人均年收入达到1000美元。你千万不要觉得“全民奔小康”这个目标很容易实现。要知道中国有13亿人口，大约有10亿人在拖小康的后腿啊。所以发达地区至少要有10倍于落后地区的经济能力，才能抵消落后地区的负担。

据大致估计，上海、北京等发达城市的软件白领平均年薪为10万元左右。如果进一步细分的话，年薪5万元左右的称为灰领，年薪20万元以上的称为金领。

u对于生活在上海、北京、深圳等发达城市的人而言，如果他的年收入只有1000美元的话，那么他就是赤贫阶层了。面对高昂的房价和不低的物价，年薪10万元左右的人也许有胆量谈小康。所以大部分白领人士将和农民一样，不得不为小康而长期奋斗。

软件白领的现状

u 尽管软件白领是令社会大众羡慕的阶层，但是男士们成家立业的艰辛程度丝毫不亚于农民和蓝领。这是因为他们所负的压力远远超过了经济收入。

– “月光王子”的潇洒日子是短暂的。

u 家的三大构成要素是“男主人、女主人、房子”。根据中国的传统习俗，买房子这个重任主要由男士来挑，女士的主要本事将用在有房子之后治理这个家。

–工作才两三年的小伙子全靠自己的积蓄难以支付“房子的20－30％首付”。在亲人和朋友们的帮助下，好不容易买了房子，接下去每月都要还银行贷款。

–当他的工资扣除税收、缴掉各种保险金、还银行住房贷款之后，顿时所剩无几。这时如果再让他肩负家庭的生活费用，他就不再是白领了。我已经多次听到一些小伙子们恨恨地说：自从买了房子后，我就活得像个民工，开始为家庭的温饱而奋斗。

– 这就是目前普通软件白领的生活写照，如果他不能在事业上有大的跃进，生活的压力将逐渐磨灭他的斗志，后半生就平淡如水。

u 大多数人并不甘心平庸，所以他不停地奋斗，不停地承受更多的压力，这种“死循环”程序在读大学的时候就已经编写好了。

u 《读者》曾经刊登了一篇文章叫“中国的男人为什么不浪漫？”，估计是悠闲女人写的。其实不必写那么长的文章，一句话就可以解答：因为他太累了。

软件白领的常规职业发展

u 在外界看来，做个程序员是蛮光彩的。但是我们自己切勿轻易满足，软件行业还有许多比编程更有价值的工作。

– 有个朝鲜官员第一次到中国参观学习，感叹万分…

u 软件白领的常规职业发展大致可分三个阶段：

– 第一阶段，做个职业程序员，主要工作是编程、测试和维护，领导让他干啥就干啥。

– 第二阶段，成为项目经理或同等级别的技术负责人，从事项目管理、需求分析、系统设计之类的工作，带领一批程序员干活。

– 第三阶段，成为机构（企业或者事业部）的领导，成天琢磨怎样让机构赚更多的钱，决定产品的发展战略，然后让别人去开发产品。

u 软件白领处于第一阶段为合格，处于第二阶段为良好，处于第三阶段为优秀。比较合适的年龄分别为25岁左右、30岁左右、35岁左右。第一阶段比较容易实现，第二阶段需要一定程度的努力，第三阶段则靠奋斗了。

什么是强势知识

u 在解释什么是强势知识之前，我们先举例说明它的反义词——垃圾知识。

– 《读者》有一篇文章说，国内有个杜甫研究专家在国际上拥有一项独一无二的研究成果，他用了19年时间研究证明杜甫是吃牛肉死的，因此成为权威。

– 人们总以为研究杜甫是为了让人们更好地欣赏高雅的诗词，没想到有人执著到用19年时间研究杜甫是吃什么死的。这个研究成果不是学问，它对人类社会毫无价值，称之为垃圾知识最恰当不过了。

u世界上的知识无穷无尽，没有人能够学得完。然而人的寿命却是有限的，对于世上的绝大多数人而言，学习知识的目的是为了使自己、家庭、乃至社会变得更加美好。我们听惯了“知识就是力量，知识就是金钱”的格言，殊不知劣质的知识就是垃圾。万一我们花了大半辈子时间学习或制造垃圾知识，那人生岂不可悲！

u知识的价值可以用创造出来的社会财富（包括物质财富和精神财富）来衡量。所谓强势知识就是“能够最快地为社会创造最多财富的知识”。我们应当在短暂的、富有生命活力的时间里学习和应用强势知识，而不是垃圾知识。

把事业建筑在强势知识之上

u 由于人的精力和特长都有局限，所以人们常说“有所为而有所不为”。同理，我们应当“有所学而有所不学”。一般地，人们应当根据自己的兴趣、毅力、悟性（天赋），发掘适合自己的强势知识，并把事业建筑在强势知识之上。

u 要好好分析自己究竟对什么感兴趣。当然，你感兴趣的东西未必都能学得好，更未必成为你的事业。在读书的时候换专业，工作的时候改行都是很正常的事情，年轻人切勿过多地受正统教育观念的束缚。我并不推崇“干一行爱一行”这样的口号，因为爱和不爱都是发自内心的，无需听从口号。我更不赞同在事业上“择一而终”，因为这可能使生命失去色彩。人是易变的，只要朝着更加适合你的方向改变，就叫“与时俱进”。

–林锐的学习经历和工作经历…。回顾十多年的读书和工作生涯，我不断地改变兴趣，常常在付出努力之后再放弃，得失参半。我并不后悔，因为这是一个积极的探索过程，没有放弃就不能轻装前进。尽管目前自己干得不错，几年之后我仍然会放弃，继续探索新的兴趣，掌握更多的强势知识

为事业而学习

u 如果你生活在竞争激烈的社会里，特别是在IT行业，事业将毫无疑问成为男人的重心。尽管事业成功并不见得就使你幸福，但是事业却是幸福的基础。如果男人在事业上无所建树，那么他十有八九活得很失败。

u一般地讲，除了运气之外，你所掌握的强势知识决定了事业状况。不论是在学校里还是在企业里，都要懂得为了事业而学习

– 根据事业的目标，确定对应的强势知识结构，有目的有步骤地学习这些强势知识。（在大学里所学的仅仅是专业基础知识而已，只够让你成为工匠挣口饭吃，不要以为自己是个本科生、硕士生或者博士生就翘尾巴。）

–学好基础知识。把事业比喻为高层建筑，那么基础知识就相当于地基。 ……虽然我们强调基础知识的重要性，但是也不能过度地推崇，基础应该与事业目标匹配起来，要考虑机会成本。

–读书时扬长补短，工作时扬长避短。……“补短”是指补习你不擅长的知识，因为这些知识对你的事业也非常重要，并不能因为你不擅长就可以甩掉它，如果不补短的话，短处将常常拖你的后腿。 ……人们工作的目的是为了创造效益，要给企业和自己多多赚钱，而不是单纯为了提高自己的知识水平。所以在工作的时候一定要“扬长避短”。

– 不仅要学习新知识，还要向错误和失败学习，形成学习的良性循环。我们从小学读到大学毕业，一直都在学习新知识，一直信奉“好好学习，天天向上”。然而我们不能把眼光仅仅盯在新知识上，不管是生活还是工作，人们都应该向错误和失败学习，目的是让我们在短暂的健康年华中少犯错误、少失败，多做几件正确的、对社会有贡献的事情

还有一些就是怎么提高管理能力，表达能力和人格魅力方面也谈到了很多，先贴出这些吧。慢慢消化一下，当然有些观点还是有自己的考虑和想法。

哈迪尤 2006-10-08 10:27 发表评论

1.3 Knowledge Representation

哈迪尤 — Sun, 08 Oct 2006 02:13:00 GMT

                                                                             Knowledge Representation

   1.3.1 Production Rules
           规则或Production Rules在Drools里由规则成立时处理动作(LHS)和规则不成立时处理动作(RHS)两部分和其它下面一些而外的属性组成。
               。salience
               。agenda-group
               。auto-focus
               。activation-group
               。no-loop
               。duration

rule “<name>”
    <attribute> <value>
    when
        <LHS>
    then
        <RHS>
end

      LHS由规则的名称和逻辑组合条件组成。下面则是符合规则条件下要执行的指定的动作。中间属性列用来约束初始数据。
      Drools现在支持的逻辑条件有：
      。“and”
      。“or”
      。“not”
      。“exists”
      "forall"和"accumulate"在不久也会加入。下面的字段约束是容许的
      。Literal Constraint                 (字符串约束)
      。Bound Variable Constraint   (变量范围约束)
      。Return Value                        (范围值约束)
      。Predicate                              (断言)

          下面的语言指导介绍更详细的关于它们的消息
          Working Memory在匹配初始数据或修改数据后的时候根据LHS 的条件，把所有匹配的规则激活。一旦规则被激活放入Agenda 里就
   有可能会被按照执行顺序调用规则RHS的动作。LHS和RHS的关系就下面语句关系一样：

if ( <LHS> ){
<RHS>
}

       尽管“if”在像“if-else if...else”中是执行语句的一部分，规则使用“when”的语义确定规则是否被激活，则规则LHS被匹配。规则
   像    “package”一样关联到命名空间。其它的规则引擎叫这个叫规则集合(Rule Set)。命名空间(Package)可以声明imports其它Package，
   全局变量，函数和规则。

package com.sample

import java.util.List
import com.sample.Cheese

global List cheeses

function void exampleFunction(Cheese cheese) {
    System.out.println( cheese );
}

rule “A Cheesey Rule”
    when
        cheese : Cheese( type == "stilton" )
    then
        exampleFunction( cheese );
        cheeses.add( cheese );
end

上面的例子使用一列单独的字符串变量约束的规则来匹配Cheese 。

rule "Cheddar Cheese"
    when
        Cheese( type == "cheddar" )
    then
        System.out.println( "cheddar" );
end

这个例子和下面是相同的：

public void cheddarCheese(Cheese cheese) {
    if ( cheese.getType().equals("cheddar") {
        System.out.println( "cheddar" );
    }
}

规则引擎完全把业务规则和数据分离。改变Working Memory里的初始数据时候，规则不像方法和函数一样可以被直调用。规则引擎可以向java一样声明做什么而不是怎么做。

First Order Logic

哈迪尤 2006-10-08 10:13 发表评论

1.2 为什么要使用规则引擎

哈迪尤 — Sun, 08 Oct 2006 02:13:00 GMT

         下面的问题经常被问到：
               1。什么时候使用规则引擎。
               2。规则引擎比“if...else...”语句有什么样的优势。
               3。为什么使用规则引擎来代替动态脚本框架，比如Beanshell。

    1.2.1 总结使用规则引擎的优点
                 声明式编程
                  规则引擎容许你“应该做什么”而不是“怎么做”
               这个优点的关键点在于对于很难的问题也容易表述解决方案，应而可以很容易检测解决方法(比阅读代码简单).
               规则引擎解决很难很难问题的能力很强，只要解决方法能够描述怎么做就行(对于AI神经网络系统或则人的想法就不容易咯)
               把业务规则和数据分开
                        数据在业务领域对象里，逻辑在业务规则里。这个打破了OO数据和逻辑不分离的基本规则(这个优势取决你看问题的观点)，这样的结果可以很容易维护业务规则，在业务层规则里适应未来的业务改变。
               运行速度快，性能可度量
               Drools' Reteoo 派生于Rete 和Leaps 算法，根据你的业务数据对象提供非常快速的规则匹配。当你的数据不做经常任何改变时，运行更有效率(规则引擎会记住以前的模式匹配)。
               集中知识
                一旦使用并运行规则引擎，就创建了知识仓储。这个意味着对于业务方针的单点入口。更理想情况是规则更容易读，业务服务可以文档化。
               工具集成
               eclipse的工具提供编辑和管理rules和直接的反馈，认证，内容协助。监控和调试工具也处于可用状态。
               日志清晰
               规则引擎有效的提供“解析说明”能够记录规则引擎做了些什么
               易理解的规则
               为业务领域问题创建创建领域模型，业务规则则可以用很自然的语言描叙，这样设计者可以拿很容易理解的规则给没有技术基础业务领域专家()

哈迪尤 2006-10-08 10:13 发表评论

第一章规则引擎

哈迪尤 — Thu, 10 Aug 2006 15:52:00 GMT

规则引擎

      1。什么叫规则引擎

          I 来源和背景
                  人工智能是集中研究使计算机像人类一样来想问题用现实中自然来描述问题的宽广的研究领域，列于规则，决策树和专家系统等。AI在知识表示时关心多少知识需要被记录和维护。专家系统把知识逻辑整理成规则放入用于推理的知识库中来表示为学习（我们使用基于知识库中推理来得到结论）。知识管理系统和基于知识库的专家系统被考虑用于人工智能，在这个过程中我们称为学习引擎。EMYCIN是专家系统中第一个用来处理跟外界交互的模块（Shell），一个用于医学诊断的专家系统。成熟的专家系统从系统里剥离出里剥离出用于跟外界交互的逻辑模块。Drools是一个基于规则处理来实现专家系统的规则引擎产品。
                 规则产品这个术语是一个语法中正式的叫法，还可以简单的描述成：用无限的规则集合通过匹配一个处理流程逻辑来定义一个有限的逻辑规则。
                 商业规则管理系统为商业用户提供规则引擎系统的规则管理，部署，协作和分析的用户工具。商业规则的前景是快速的演化成专门为企业提供服务的正式学科。
                  规则引擎可以被只要使用规则的任何一个系统使用。一个简单的认证和根据结果动态表示的系统通过规则引擎来处理数据得到结果被Malcolm Chisholm 在“How to Build a Business Rules Engine (2004）”书上作为一个例子。这本书事实上关于通过用vb代码来控制不同的认证规则来建立或更改数据库中的表和验证登陆数据。当非常有效和有用的一些话题，没有觉察到与规则引擎微妙的不同点，作者希望找出隐藏的一些秘密来改善Drools引擎。jBPM 使用决策点中的表达式和代理来控制工作流中的流程。在每个决策点评估一个规则来决定采用那个处理动作，这个也属于规则引擎。虽然一个规则产品系统属于规则引擎或专家系统的一种，像上面提及的通过编程表达式来确定规则不属于专家系统。
                  一个规则系统产品完全的关注知识表现和简明的定制的执行逻辑。规则产品系统的思考是一个接口引擎用来度量很大数量的规则和事实。接口引擎匹配事实，数据和依靠已有的规则，或则直接调用已有的案例或仅仅规则集来推断出执行动作的结论。规则产品库一般由两部分组成，第一部分是条件执行逻辑。

匹配新的或则依靠已有的规则的处理过程叫模式匹配，同样它也是通过接口引擎执行。用于模式匹配的算法的接口引擎包括：

Linear

Rete

Treat

Leaps
Drools 实现Rete和Leaps算法，Leaps 是经过试验证明的，尽管它还非常新。Drools 's Rate被为是Rete算法的一个面向对象的Java实现。市面上还有其他几种经过增强的Rete的商业Rete算法引擎，例如：RetePlus 和Rete III 。Rete III不像原始的Rete算法一样，它是完全商业化的产品，并不公开算法的重要细节。提出“为什么Drools不使用Rete III 算法”是非常无趣的。更多的详细内容请参阅<< Production Matching for Large Learning Systems (Rete/UL)">>(1995) by Robert B. Doorenbos。
                 将多个规则( Rules) 存储在Production Memory里，初始数据(facts的)接口引擎输入到Working Memory（工作内存区）。Working Memory里的初始数据(Facts)是可以更改和替换的。一个系统里有一定数量的rules 和 facts，并且根据rules判断的出相同的结果，则可以说这些 rules是冲突的(执行规则冲突)。Agenda管理使用多次规则匹配规则冲突策略来确定执行命令。

                                                                Figure 1.1. ABasic Rete network
                  一个规则引擎系统的的接口引擎应该是声明式的，并且能够根据声明的事实来执行。它被称为Truth Maintence。执行的动作的逻辑关系是确定好的，当根据逻辑关系推论出action的状态值为真便执行动作。如果不符合条件则不执行动作。下面“真实的政客”就是Truth Maintence的一个例子。当政客存在时候，总是只有确保希望存在条件下才执行动作。

规则引擎有两种推理方式。Forward Chaining （推理）和Backward Chaining（归纳法）。实现两种算法的规则引擎称为混合型规则系统。理解两种方式操作上的不同是理解不同的规则引擎的优点。Forward chaing是数据驱动的，当把数据放入working memory 得到一个或多个执行结果。当有多个多个规则匹配时候，就用使用Agenda执行定义好的动作，直到全部执行完成。Drools 属于Forward Chaining 推理引擎。

Backward chaining 是根据假设目标来驱动的。开始后试图不断找到符合的结论，如果不能找到符合的规则时候，则设定下一个子假设来帮助当前的假设来找到符合的规则，这样重复不断查找，直到找完全部的结论或者没有子假设时候才停止。Backward Chaining 的规则引擎的例子是Prolog 。Drools将在下一个发行版加入 Backward Chaining。

哈迪尤 2006-08-10 23:52 发表评论

CMPP-SGIP协议设计与实现

哈迪尤 — Wed, 09 Aug 2006 03:37:00 GMT

在同事那里找到一篇好文章，来源于网上，但现在找不到连接了，作者如果不同意转载，请留言删除文章！

移动梦网和联通在信都是构建在有中国特色的短信网关部件基础上的，亚信为中国移动设计的CMPP协议规范，中国联通的SGIP规范都是为这个短信网关提供的互联网接口标准，可以看出二者都是借鉴GSM SMPP协议的两种简化版。

CMPP提供了基于TCP的长连接接口和短连接接口标准，SGIP提供了基于TCP和HTTP/TCP的短连接接口标准。CMPP中的短信网关为TCP服务器，通过接收SP发起的TCP连接来发送MT/MO/Report/Resp等消息。SGIP中发送MT/MTResp时是短信网关为TCP服务器，发送MO/MOResp/Report/ReportResp时短信网关作为TCP客户端。

从CMPP协议的文字内容来看，目前所有的短信网关的设计和实现都不标准。这是很有中国特色的，中国人不擅长搞统一的技术标准和规范，任何两个系统之间无论什么接口私下定义一下，就成了。西方人做研究搞技术，涉及到两个对象（包括人）打交道的，就定义一大堆标准和规范，约束各方。大家严格地遵守规范，如果有异议，就有人提议修改标准。很少私下去违反约定的标准来实现某个系统。在通信领域，好不容易出了个协议标准，居然连设计这个标准的厂家也不遵守。中国的法律成千万，遵纪守法的意识折腾那么多年还是上不来。

短连接的标准很简单，建立连接后，发送包，接收响应，发送接受，几个来回，关闭连接就成了。长连接标准需要有链路检测的维持机制（其实这个思想来自不可靠的链路通信，如在数据报基础上保障可靠传输的sync机制）、超时重传和差错重传机制、保障有序的传输机制、重复抛弃（duplication removal）机制、流量控制的滑动窗口(Sliding Window)机制。

CMPP协议文字内容中，每个建立起来的TCP长连接，既可以发送MT的Submit消息，也可以从网关侧发送MO的Deliver/StatusReport消息，每个连接的作用都是同等的。而在实现网关时，为这个问题出了很多个实现方法：亚信网关只允许一个TCP链接来发送MO消息，可以有多个连接来发送MT消息，区分MT链接和MO链接的方法是依据开始发送Connect时的协议版本号，为0是MT，为1是MO。巨搞笑！我真服了亚信那帮人！自己搞的标准，自己不遵守，作为中国的第一大电信集成商，不知道拿什么到Nasdaq上市的。亚信网关还好，什么阴私克、东软的网关，稀奇古怪的东西就更多了。让人怀疑，这不仅仅是技术素养问题了。

反正这么烂的玩意，有些运营商也用，唉，运营商的技术人员素质更差。我到现在都没有弄懂，运营商反复强调他们网关的接受短消息速度是最大每秒10条？要让所有的SP那里限制发送速度。这个数据，不知道他们是怎么得出的？这种政式的命令，让我无数次骂那个作出这么荒谬要求的**的祖宗。你网关处理速度慢，这是一个典型的技术问题，你那边服务器忙不过来，你协议里定义的滑动窗口机制是干吗用的？就是专门用来解决流量控制目的用的。有谁听说过，美国国防部弄出TCP协议后，服务器那边接收不过来，要求客户端限定死，每秒钟最多只能发送多少个数据包没有？这些运营商的技术素养，离国际化的大型企业差的太远太远，还到处臭摆自己500强，真是丢中国人的脸！

最后的结局是各个SP的开发人员，不断地开发好几家网关的接口，就跟求爷爷似的，听着这几个网关供应商和运营商那帮弱智的训斥。

设计CMPP协议模块，需要考虑如下几个需求：
（1）可以人为配置的多个TCP连接，来发送和接受消息（移动最多可允许一个SP建立15个连接）。系统初启时，自动地启动指定个数的连接。运行过程中，任意一个连接崩溃时，自动恢复。
（2）类似心跳消息的长连接维持机制，为每个连接，在最后一个消息的处理结束前，重新启动一个60秒的定时器。如果期间有消息来往，停止定时器，处理完消息后，继续启动定时器。如果60秒超时，重新启动定时器，连续三次超时，关闭这个链接，重新启动建立过程。
（3）超时重发和差错重传。超时重发的原理是发送每个MT消息后，启动一个60秒的定时器，等待网关返回应答。如果超时，继续发送，连续3次都超时都没有应答，关闭连接，启动链路恢复过程。并将这条消息保存到回收队列中，千万别抛弃。差错重传是接受到错误的应答，并且这个错误是由对等通信双方的协议层产生的，那么重新发送这条消息。
（4）滑动窗口机制。可以实现流量控制和有效的负载均衡。滑动窗口大小为16条消息。采用异步方式，一次发送16条消息，并等待应答，每成功一个应答，窗口缩小，然后再从缓存取一个发送，填满窗口。准确的说，CMPP协议中定义的滑动窗口概念不准确，应该叫缩放窗口。因为它并没有实现序列控制问题，只是起到流量控制和异步高效快速发送的目的。相对于Stop-Wait机制来说的。
（5）重复丢弃机制。如果接受到的MO消息是一条重复的，就丢弃这条消息，不能将这条MO消息交给上层。如何判断是重复的呢？通过每条消息的序列号。当然如果网关不维持这个序列号的唯一性和有序性，你只能干瞪眼。
（6）上接口缓存和回收队列。从上层接受短消息，保存到缓存里，这个缓存不要做的太大，超过一定量时，让上层发送短消息接口阻塞。而将缓存技术单独用一个模块来实现。回收队列是储存每个链路崩溃时，处于滑动窗口中等待应答的消息。
（7）有序控制机制。是保障先来的消息，先发送出去，后来的后发，严格地保障先后顺序。是通过序列号和滑动窗口来保障的。实际应用中，倒是不那么严格地关注顺序发送问题。

以上7点是这个协议模块的核心问题。如果，一个CMPP协议模块没有解决这些问题，那是一个残缺不全的实现，上不了桌面的东西。

哈迪尤 2006-08-09 11:37 发表评论

公司大门坏了

哈迪尤 — Tue, 08 Aug 2006 05:14:00 GMT

今天起来晚了，早上一路狂奔，在楼下庆幸刚好赶到，来到楼上，哇塞，楼道上怎么这么多人，还都是熟人，刚要问怎么回事，
看到公司大门还是紧闭的。门坏了，天啦，是不是昨天被小偷搞坏的哦。好几个人加上开锁师傅搞了两个小时还是没打开，刚以为今
天暂时放假时，门被搞开了一点点，可以钻个小个人咯，但是那还是没有用了，我们那漂亮的人事部经理一声令下“谁钻过去。。”
，不是吧，全钻过去，经理的话还没完，已经有人就过去了，领导的话永远是很有效的，经理接着说了“开后门”。天啦，我来了这
么久了才晓得公司还有个后门，呵呵，穿过八楼在返回七楼的后门，感觉大部队在长征一样，呵呵。
坐在电脑旁，已经10：30了，看了一下规则引擎，觉得挺有趣，但很多资料是英文。我产生一个翻译一下它的用户手册的想法，从今天开始吧！

哈迪尤 2006-08-08 13:14 发表评论

庆祝我的blog开通

哈迪尤 — Fri, 14 Jul 2006 07:50:00 GMT

      blog已经很泛滥咯，但是还没到泛滥成灾，再怎么泛滥也是自己的空间，谁管你列。

      爱怎么搞就怎么得，自己快乐最重要，记录自己的所有，技术，生活，工作，情感。

哈迪尤 2006-07-14 15:50 发表评论