漂在北方的狼

在我们使用XML Schema描述数据模型的时候，XSD提供了很多的强大的功能，比如对数据内容的Restriction（约束）功能。

Restrictions是用来限制（或者说定义）Element或Attribute可接受值的。而对于Element的Restrictions通常又称为Facets。
下面通过一些常见的约束例子来说明Restrictions的用法和语法。

数值型范围限制

该约束定义age元素的值是整形而且值要在0到120之间。

枚举限制

这里约束了car的值是string，而且只能为“Audi”、“Golf”和“BMW”中的一个。
可以使用另一种写法：

<xs:element name="car" type="carType"/>
<xs:simpleType name="carType">
<xs:restriction base="xs:string">
<xs:enumeration value="Audi"/>
<xs:enumeration value="Golf"/>
<xs:enumeration value="BMW"/>
</xs:restriction>
</xs:simpleType>

这种写法的好处是，上面的Restriction不是定义在Element中的，可以被其他的Element很方便的调用。

使用正则表达式（RegularExpression）约束

这里<xs:pattern>的value属性的值是一个正则表达式正则表达式的语法则不再本文介绍的范围。使用RegularExpression你可以规定任何格式的string约束。

空格字符（Whitespace Characters）约束

<xs:element name="address">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:whiteSpace value="preserve"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

以上例子对address中的所有空格字符进行保留。关键是value="preserve"。XML语法本来就是保留空格的。
当值为“replace”时
XML processer会用空间来代替所有的空格字符。
当值为“collapse”时
会将连续的空格合并成一个。

长度约束

以上例子限定了password元素的长度为8。当然也可以使用 <xs:minLength value="?"/>和<xs:maxLength value="?"/>来限定最长最短值。

更多的内容请看http://www.w3schools.com/schema/schema_elements_ref.asp

周六的时候参加了douban组织的2009年北京Python用户组（BPUG）第3次聚会的活动。具体的活动信息大家可以移步到这儿查看。感谢douban，感谢组织者xyb，感谢三位主讲人梁冰，王云鹏，黄冬。

想进入参加活动名单还不是很容易的，一共才有30个人的名额，好多同学报了名也遗憾的没有参加。

这次活动有三个话题，基本上都是架构方面的话题，与python没有太多的关系，这样的主题我很喜欢（因为python我基本不懂），在三位主讲人的分享下，收获颇多，也不枉费我来回4个小时，60多公里的路程。

当你的系统进入一个高并发，高负载的时候，你的架构设计就不能仅仅只是某一门语言的问题。你需要了解和深入很多领域的知识，比如操作系统，网络协议，多种语言的组合和对比（在不同场合使用最适应本场合的语言），硬件系统。只有这样，你才能设计出来一个合乎需求的系统。所以，对于一个架构师（或者想要成为架构师的同学）来说，需要学习的东西还是很多的。

有些话题由于某些原因不方便参加者宣传和传播，我也就不在blog上做文字的记载，就把我在当天回家的路上整理的mind生成图片放到blog中，如果有感兴趣的同学，可以查看图片。

另外：附上这次聚会中的一些照片，更多的照片请点击这儿

同事老焦最近的项目中碰到一个JSON与Java Object之间转换的性能问题。

上网查了一下，果然我们现在使用的JSON-Lib这个框架的性能是公认的差，可能之前一直没有意识到这个问题，只是觉得这个Lib用的挺顺手的，所以一直在用它。这里有两篇文章对现在的三种JSON转换的框架的性能有一个比较具体的分析（《Java: JSON Parser Performance》、《JVM性能调优记录》）。

我们试了上面的另外两种框架，但是都不能达到我们的需求，关键是对我们自定义的Object转换会有问题，需要我们提供扩展的方案才行。

正在头疼中，海龙给我们推荐了google-gson这个有google提供的JSON框架。我在pom.xml中加上google-gson的依赖，写了几个测试用例测试了一下，条件是任意多个java对象数据集合转换成JSON字符串。在同样的条件下，google-gson性能比JSON-Lib提高了两倍以上，特别是在对一个很大的、有冗余的Object做转换时性能更是能提高3-4倍。而且，API使用也很方便，一个gson.toJSON(obj)就可以完成转换的操作。

在这里特地给大家推荐一下google-gson。

我在公司发起了一个关于REST的系列分享，现在已经进行到第二期了。主要关注于RESTFul应用的开发，基本上会从RESTFul的概念入手，慢慢深入的讨论如何在项目中如何开发RESTFul的应用、如何更好的理解RESTFul的理念。

这两期的分享主题分别是《什么是REST风格应用》，《使用JSR311规范快速构建REST应用》。基本上每次的分享时间都有两个小时左右。虽然我会把每次分享的PPT都会给大家，但是毕竟PPT只是一个简单的大纲而已，更多的内容还是在大家互相讨论交流中。

REST系列分享活动简介如下：
    这个活动是由程序员自动发起，非官方的身份决定我们不会有太多的资源来支持活动，希望大家能够在完成（安排好）手头的工作之后来加入活动。
    同时，可能由于时间的关系，我们允许分享人可以不准备ppt，但是要保证可以通过别的方式（如白板）来将你要分享的内容表达清楚。
    我们希望通过我们的分享和交流能够让大家对REST有更深入的了解，毕竟REST也是一个很庞大的话题，不是一次两次的培训和分享能够说明的。
    我们欢迎有自己的想法，有疑问，习惯质疑，喜欢分享的程序员加入活动中来。
    在活动中有任何的疑问和反对意见都可以随时提出来。

下面是我之前分享内容的ppt。

我们在Windows下使用Maven来编译项目的时候，经常会发现Maven给出这样的提示：[WARNING] Using platform encoding (GBK actually) to copy filtered resources, i.e. build is platform dependent!

当你看见这样的提示的时候，你就要小心你项目中资源文件的中文会出现乱码的现象了。你可能会有疑问，我的文件的格式是UTF-8的，文件编码也是UTF-8的，为什么还会出现中文乱码的问题呢?

其实原因Maven已经告诉你了。由于我们使用的Windows默认是GBK编码的，那用GBK的编码重新读写UTF-8的文件，那肯定是会出现乱码的。

那么我们怎么样才能解决这个问题呢？其实很简单，只需要在相应的项目的pom.xml中加上一个Maven插件就可以了。

<plugin>
       <groupId>org.apache.maven.plugins</groupId>
       <artifactId>maven-resources-plugin</artifactId>
            <configuration>
                 <encoding>UTF-8</encoding>
              </configuration>
</plugin>

现在所有常用的操作系统基本上都是在Unix的基础上衍生（最少是借鉴）出来的，而且基本上大学的操作系统的课程也是拿Unix系统来讲解的。在这里我转载了Unix的设计哲学和思路，一起学习参考。

原文地址：http://cgfundamentalism.spaces.live.com/Blog/cns!A938DB4347919AD9!406.entry

（节选自 《Unix 编程艺术》）

Unix哲学中更多的内容不是这些先哲们口头表述出来的，而是由他们所作的一切和Unix本身所作出的榜样体现出来的。从整体上来说，可以概括为以下几点：

1. 模块原则：使用简洁的接口拼合简单的部件。
2. 清晰原则：清晰胜于机巧。
3. 组合原则：设计时考虑拼接组合。
4. 分离原则：策略同机制分离，接口同引擎分离。
5. 简洁原则：设计要简洁，复杂度能低则低。
6. 吝啬原则：除非确无他法，不要编写庞大的程序。
7. 透明性原则：设计要可见，以便审查和调试。
8. 健壮原则：健壮源于透明与简洁。
9. 表示原则：把知识叠入数据以求逻辑质朴而健壮。
10.通俗原则：接口设计避免标新立异。
11.缄默原则：如果一个程序没什么好说的，就沉默。
12.补救原则：出现异常时，马上退出并给出足够错误信息。
13.经济原则：宁花机器一分，不花程序员一秒。
14.生成原则：避免手工hack，尽量编写程序去生成程序。

这两天看了一个这样的文章《软件工程师的十个“不职业”行为》，是陈尚义老师整理分享的。看完之后，抚心自问，自己还是比较职业的软件工程师。

现在将这十条不职业的行为摘录下来，时刻提醒自己。

行为一：对外交付半成品。

行为二：不遵守标准和规范。

行为三：不积极帮助他人。

行为四：版权意识不敏感。（这点要注意）

行为五：对待计划不严肃。

行为六：公事私事想混淆。

行为七：不注意更新自己。

行为八：不主动与人沟通。

行为九：不遵守职场规则。

行为十：不够诚实和正直

原文地址:http://www.programmer.com.cn/1041/

其实我们都是从菜鸟成长起来的，感谢在这个过程中给予我们帮助的人！

下面的文字转自: http://www.ideawu.net/blog/?p=428

最近, 网上盛传一个笑话, 一般名字叫做"围观不会设置Java User-Agent的菜鸟". 讲的是国外一个用Java开发Web爬虫获取网页
的菜鸟, 不知道怎么设置自己虫子的User-Agent字段, 该字段可以告诉Web服务器, 对方用的是什么工具或者软件. 这个笑话中的事情确有
其事, 见下面URL:

https://groups.google.com/group/comp.lang.java/browse_thread/thread/6923c024ed392c85

这个帖子(邮件)的发贴人使用的邮箱后缀是cs.stanford.edu, 他是斯坦福大学的学生. 发贴的时间是1996年1月, 使用的Java
是1.0beta2. 当时, Web爬虫技术应该是非常稀有的技术, Java/1.0beta2的HTTP相关库也应该非常难用. 现在看来, 那
时的人, 那时的技术, 都像是婴儿. 所以, 这看起来像个笑话.

但是, "笑话"的笑点在这里吗? 我相信, 大家在看到这个所谓的笑话时, 可能会心里或者面上露出笑, 但应该是感悟的笑, 自嘲的笑, 无奈的
笑, 思索的笑...肯定不会有快乐的笑. 为什么? 因为发贴的人是Larray Page, 是Google公司的创始人之一. 他创造了全球许多
技术人员的上帝, 他创造了巨大的财富, 他创造了技术和商业神话. 可是, 他曾经做过的事, 使用的技术, 开发出的产品, 遇到的无法逾越的问
题, 向人讨教时的心情, 和我们那么接近, 甚至对我们大部分技术人员简直是小菜一碟. 在每一个人心中, 这都是一个历史笑话, 让我们思考技术的
本质.

我把这封邮件引用在这里, 做个留念:

   I have a web robot which is a Java app. I need to be able to set
the User-Agent field in the HTTP header in order to be a good net
citizen (so people know who is accessing their server). Anyone have
any ideas?

   Right now, Java sends a request that includes something like:

   User-Agent: Java/1.0beta2

   I'd rather not rewrite all the HTTP stuff myself. I tried just
searching in the JDK for the Java/1.0beta2 figuring I could just
change the string, but I couldn't find it. Perhaps it is stored as a
unicode string?

   An easy method of setting the User-Agent field should probably be
added to Java, so people can properly identify their programs.

   Thanks, Larry Page

Kseniya Simonova，乌克兰人，80后的沙画艺术家。

人美，画更美。下面两个沙画作品是她在《乌克兰达人》这个选秀节目中的表演。每个作品都讲述了一个故事。

比赛中的表演令现场观众看她作画居然会为之泪下。她的沙画艺术是对艺术与灵魂的诠释，看她作画的过程，能够让人感觉身心得到净化和升华，难以想象这竟然是在一场选秀节目中的表演。

这个作品讲述的是德国二战期间侵略乌克兰历史。最后她写的字意思是“永远和你们在一起”。 结尾部分的背景音乐是“nothing else matters”。

这个作品表达了宇宙、人生、亲情。孩子从出生到变成画家，出名后和父母很少联系，老母亲只能在电视里看着儿子的身影，最后孤独的死去。 

Kseniya Simonova在录像最后用俄语写了：“Don't be late...; 别晚了...”，意思是要赶紧和家人联系，等到家人都走了就晚了。

原文地址：漫天风

培养员工的主动性和敬业精神可以从几大方面入手：

1、 最基本的是创造一个积极的，宽松的，自组织的工作环境和氛围。在这个环境中，倡导学习型团队文化。

2、 积极建设阶梯型、多样化的人才团队。一个团队如果能形成良好的人才梯队，不仅仅有利于团队形成强大的竞争力，而且一定程度上能激发不同成员的主动性和积极性。

3、 完善的角色和明确的工作职责。一个团队，如果缺乏某个特定的角色，不仅仅在这个特定领域中会成为团队的短板，而且往往需要团队Leader去弥补或救火，这样会成为团队发展的瓶颈，这个是限制员工发挥主动性的重要因素。

4、 合理的授权。团队领导应该成为教练，并从中帮助团队各个角色更好的协作，更好的发挥每个人的优势。授权是一门管理艺术，信任每个员工，并给他们充分的权力，有助于提升员工的主动性和敬业精神。

5、 激励。当团队的目标达成时，当某个员工表现突出时，适当的激励将会使团队焕发激情，同时也是对每个员工的一种肯定和鼓励。善于使用激励的领导，将会让他的员工充满积极主动性。

好久没有听齐秦的歌了，突然这首歌在耳边响起，把我的思绪带回到了02年刚来北京的时候。正如在这首歌中齐秦慢慢的唱道：

我在异乡的夜半醒来
看着完全陌生的窗外
没有一盏熟悉的灯可以打开
原来习惯是那么难改

只为了和你再见一面
我会不分昼夜的想念

《想念》这首歌是收录在齐秦的1997年《丝路》这张专辑中，由袁惟仁（小胖）创作。

今天给大家分享了一下，在实现社区积分系统时使用设计模式的思路，同时也分享了一下我们怎么样去选择设计模式。

谢谢大家的支持和讨论。

在这里把刚才分享的Strategy、State、Chain of Responsibility的不同的地方概括说明一下：

Strategy:主要应用于在一次操作中存在着多种算法的选择。

State：主要应用于在同一事物状态转换的描述。

Chain of Responsiblity：主要用于对某一次操作有一系列可选择的处理。

大乔小乔在《消失的光年》中唱道：“每个人是每个人的过客，每个人是每个人的思念。眼中的日月星辰，消失在心中的光年”。每次听到小乔用稚嫩的童音来唱这首歌，心中都有莫名的惆怅，可能这个就是他们的目的，用代表纯真的童音来唱出成年人的感伤。

不过，我这里并不是想来做一个文艺青年来感伤时间的流逝，而是想感谢我生命中的每一个过客。在茫茫人海中能够擦肩而过也是一种缘分，更何况这些在我的生命中陪伴我走过某一段时间的人呢？

转眼来到北京已经7年多了，其中也更换了多个工作，也经历过自己创业，也笑过，也哭过，有沮丧过，也有欣喜过。我的这些变化，身边的走过的这些同事朋友们都一一见证过。我真心的感谢你们，陪伴我成长。

想想，这些年里面，几乎每个公司都有一个或多个人对我影响挺大。

罗涛先生，谢谢你给我在北京第一份工作，让我能够留在这个实现梦想城市。

米长泊（米哥），谢谢你让我学会怎样与人沟通，学会怎样对不正常的要求说不，同时也包容了我在工作中犯下的错误。这段时间，我也把北京的交通也摸熟了。

魏一才先生，谢谢你给我一个反面的案例，教育我千万千万不要成为你这样的人，千万千万不要和你一样在一个虚假的环境里面把自己给废掉。

郭家清（郭工），谢谢你让我看到一个人放下已拥有的所有，向自己的梦想的目标坚定的前行的勇气，并实现自己的梦想，拿到了CCIE的Cisco的最高认证。谢谢您对我的鼓励，让我勇敢的追求梦想前行。

林宇泽（小林），虽然你比我大，但是已经习惯叫你小林，想想这样叫你，应该让你更年轻一些，所以你就接受吧。谢谢你帮我进入了互联网这个领域。

田玉林，很想念当时咱们一帮人共同创业的时光，想到最后由于资金的问题，大家各自解散时，作为领头人的你流下的泪水。过了这么些年，这个情景经常会在我脑海中浮现。这几年过去，大家都应该提高了不少了吧。希望还有机会能够一起合作。

郭应寿老师，谢谢您带我进入了一个全新的境界，让我知道原来软件开发是这样有意思的一个工作。谢谢您对这个行业有了全新的认识，让我愿意为之付出一生的时间。

通过这次沟通分享，大家达成这样的共识。
1.使用trunk，branches，tags的方式来管理Subversion的版本。
2.使用分层的方式来拆分技术团队，分为REST层以及前端表现层。
3.使用maven来管理项目的生命周期。

这次的分享，很高兴得到大家的认可，感觉心中的憋着的一股气泻下去不少。

  希望以后能够越来越好！

google的spider爬的真是快啊，我上篇blog刚刚写了半个小时左右，就已经能够在google上搜索到这篇文章了（有图为证）。而baidu、sogou等搜索引擎估计要再等段时间才能进入他们的索引了。

想起在friendfeed中看到的一句话：google有8000个工程师，baidu有8000个营销人员，作为聪明的使用者，你会选择哪个作为默认的搜索引擎？

早些时候在yeeyan上看到了一篇介绍Google Reader采用PubSubHubbub协议让人们更快的看到你订阅的blog更新和更快的把你分享的信息发布到订阅者的更新内容中。

那什么是PubSubHubbub协议呢？简单来说PubSubHubbub是一个实时信息流的协议。PubSubHubbub通过全新的技术采集特定的信息，可以极大的缩短feed从发布到被客户端发现之间的时间。

下面是Google自己的对PubSubHubbub简单介绍的PPT

来源：http://cocre.com/?p=1178

Internet近20年的技术演变，不知道未来的Internet技术会发展到怎么样？

有人说思乡实际上就是对家乡美食的思念，是胃决定脑子（情绪）。其实总的来说是对环境的适应，每当人们来到一个新的陌生的环境中，人们都会对以前熟悉的环境产生思念的情绪，食物只是一种具体的体现。当你慢慢的适应了新的环境后，那这个新的环境也会成为你记忆的一部分了，也成为你思念的地方。

来北京已经7年了，还记得刚来的时候满地的找湖北的小吃，如热干面、豆腐脑、豆皮等等，但是每每让我失望。只好在每次回家的时候，就狠狠的吃一顿，以满足自己对这些食物的思念。后来时间长了，适应了北京，慢慢也就淡了，尤其是现在有痛风这个毛病，好多东西都不能吃了（可惜我家小毛跟着我受苦了）。

最近听了一首歌，很有感觉，很应现在的景。也是一个湖北人写的。

达达乐队的《南方》

南方
词:彭坦
曲:彭坦
编曲:达达
我住在北方/难得这些天许多雨水
夜晚听见窗外的雨声/让我想起了南方
想起从前呆在南方/许多那里的气息
许多那里的颜色/不知觉心已经轻轻飞起
我第一次恋爱在那里/不知她现在怎么样
我家门前的湖边/这时谁还在流连
时间过得飞快/转眼这些已成回忆
每天都有新的问题/不知何时又会再忆起
南方 
那里总是很潮湿/那里总是很松软
那里总是很多琐碎事/那里总是红和蓝
就这样一天天浪漫/就这样一天天感叹
没有什么是最重要/日子随着阴晴变幻
时间过得飞快/转眼这些已成回忆
每天都有新的问题/不知何时又会再忆起
时间过得飞快/转眼这些已成回忆
每天都有新的问题/不知何时又会再忆起
南方

其实半调子也不错！

半调子
词/曲：徐寅
——自闭症的小孩

演唱：徐若瑄 

半调子的世界 是秋天的 
半调子的童年 是有缺陷的 
半调子的朋友 是少之又少的 
半调子的路 是孤独的 
半调子的歌 是便宜卖的 
半调子最爱的 都是别人最恨的 
半调子的内心 是空虚的 
半调子的夜晚 さぴしい

半调子的歌 半调子的歌 
半调子的歌 半调子的歌 
半调子的歌 半调子的歌 
半调子的歌 半调子的歌 


半调子是不经意 就抄袭别人作品的 
半调子他 真的不是有心的 
半调子都是 不敢多说话的 
半调子其实是 很想上进的 
半调子的外表 是挺有那么一回事儿的 
半调子的Sense 是很脆弱的 
半调子有时 是很有感觉的 
可那感觉 通常也都是别人的 


半调子的颜色 是温柔的 
半调子的爱情 是含羞草型的 
半调子的女人 也是半调子的 
半调子的内涵 是1/4的 

半调子的歌 半调子的歌 
半调子的歌 半调子的歌 
半调子的歌 半调子的歌 
半调子的歌 半调子的歌
半调子的歌 半调子的歌
半调子的歌 oh

半调子的歌 半调子的歌
半调子的歌 半调子的歌
半调子的歌 歌……

org.w3c.dom.Document是sun推出的Java API for XML Parsing (JAXP) 接口包中包含的一个类。

我们一般会用它来表现一个xml文件，然后通过DOM来直接对这个xml进行操作。

那我们怎么通过Jersey直接返回Document呢？是向下面那样吗？

@GET
@Produces("application/xml")
public Document get() { ... return doc; };

那只能返回下面的结果

org.apache.xerces.internal.dom.DeferredDocumentImpl, and MIME
media type, application/xml, was not found

那怎样才是正确的呢？

@GET
@Produces("application/xml")
public DOMSource get() {
   Document d = ..
   return new DOMSource(d);
}

有兴趣的同学可以试试。

      《我们同属一个世界》是1985年1月28日在美国洛杉矶“生存援助音乐会”中的大会主题歌。
       1985年，非洲的埃塞俄比亚、苏丹、毛里塔尼亚等国严重干旱，粮食短缺，成百万人死于饥荒。据估计，非洲有一亿五千万人受到饥饿的威胁。消息传来， 引起世界各国人民的关注，纷纷伸出援助之手，救援饥饿的非洲人民。其中最引人注目的是在英国和美国举行的由民间发起的“生存援助音乐会”。1985年1月 28日，在洛杉矶举行了规模空前的援助非洲的大义演，在场的歌星和工作人员手挽手同声高唱这首大会的主题歌《我们同属一个世界》( We are the World )，感人涕下。

       这首主题歌是西方摇滚巨星迈克尔·杰克逊和莱昂内尔·里奇连夜赶写出来的。这首歌制成磁带分寄给美国几十名歌星时附上迈克尔·杰克逊写的一段话：“如 果将来你们的后代问起，他们的爸爸妈妈为人类面临饥荒做了些什么?你们可以骄傲地回答他们，你们做了应做的贡献。”这首歌推出后，很快响遍全球，几天内唱 片销售突破100万张，收入的5000万美元全部用于救援非洲灾民。演出的当天晚上，美国著名影星简·方达主持了这次实况转播的电视节目。她最后说道： “这不只是个群星灿烂的夜晚，而且是流行音乐史上一个更高尚的时刻，它表明，流行音乐在过去的几年里所产生的歌星们，对这个世界所具有的责任感……”

       半年后，7月13日，美国歌星迈克尔·杰克逊在美国费城肯尼迪体育场举行救援非洲灾民音乐会。与此同时，鲍勃·吉尔多夫在英国伦敦温布利体育场也举行 另一场有几十名著名歌星参加的救援音乐会。这两场音乐会，通过卫星向世界上140多个国家现场直播，演出达16个小时，收看观众多达20亿人，募集救济款 8500万美元，在世界上传为佳话。杰克逊、鲍勃、里奇等人以及参加义演的歌星们的行动，受到人们的尊敬。

      迈克尔·杰克逊和莱昂内尔·里奇凭借此歌曲在1985年为非洲捐款8500万美元。同时也开创了多位歌星共同演绎公益歌曲MV的先河。次年杰克逊同里奇因创作了We are the wolrd而两人同时获得格莱美大奖。

      也正是we are the world在世界引起轰动后罗大佑才写的《明天会更好》，而就是因为《明天会更好》在中国大江南北唱红后郭峰才写的《让世界充满爱》，并由108位歌手演绎。

一个较正式的Apache Maven定义：Maven是一个项目管理工具，它包含了一个项目对象模型 (Project Object Model)，一组标准集合，一个项目生命周期(Project Lifecycle)，一个依赖管理系统(Dependency Management System)，和用来运行定义在生命周期阶段(phase)中插件(plugin)目标(goal)的逻辑。

       rar文件是在windows下面常用的压缩文件形式，因为合作的关系，我们经常会在合作伙伴的手中接到rar文件。由于平台的原因，我们没有winrar这个应用程序来解压。那怎么办呢？ 我们都知道在linux下有一个unrar命令来解压rar文件。在Debian的软件库中有这样一个软件包：unrar-free。我们可以通过apt-get install unrar-free来安装这个软件。

       但是安装完后依然会有一些问题，那就是有些rar文件我们可以正常的解压，但是有些rar文件我们依然不能正常的解压了。我尝试过很多办法，比如以为是字符集的问题，尝试通过iconv来进行转码等等。依然是不行，后来一查unrar的版本，居然是0.0.1这么底的版本，尝试升级，发现已经是最新的版本了。看来不是软件版本的问题了，应该是软件本身的问题。我于是到winrar的官网上看看有没有linux的版本。在donwload页果然看到了linux版本的下载。

       将rarlinux.tar.gz解压后，就可以直接使用里面的rar、unrar、rar_static命令了。

        前几天听到了“花儿”乐团解散的消息，心里有些小小的感慨。

        曾经记得“花儿”刚刚出道的时候，大家都对这个年轻的乐队有很高的期望，而且他们出了几张不错的专辑，如《草莓声明》、《幸福的旁边》。

        不过近几年的“花儿”却经常以一种恶搞、抄袭者的身份出现在媒体上。虽然他们的歌曲也上了彩铃的排行榜，应该也是取得了不菲的收益，但是却离我心目中唱着朋克的“花儿”越来越远了。毕竟坚持自己的梦想一直走下去是很难很难的事情。

        可能他们有他们的追求，但是我已经不再听他们的歌了。

        送上我个人认为他们最好的一首《泡沫》，给所有有梦想的人。

歌词：

我点燃那盏灯火
向远方凝望着
空气都打开了
记忆随风散落
幻想美好的时刻
没有完美结果
红色夕阳下落
黯淡的云朵
憧憬你飘浮的泡沫
光映出灿烂的颜色
可却没有照到我
全世界的雨打到我
我的梦早已湿透了
瞬间被淹没

top:

* A: PID        = Process Id
* E: USER       = User Name
* H: PR         = Priority
* I: NI         = Nice value
* O: VIRT       = Virtual Image (kb)
* Q: RES        = Resident size (kb)
* T: SHR        = Shared Mem size (kb)
* W: S          = Process Status
* K: %CPU       = CPU usage
* N: %MEM       = Memory usage (RES)
* M: TIME+      = CPU Time, hundredths
b: PPID       = Parent Process Pid
c: RUSER      = Real user name
d: UID        = User Id
f: GROUP      = Group Name
g: TTY        = Controlling Tty
j: P          = Last used cpu (SMP)
p: SWAP       = Swapped size (kb)
l: TIME       = CPU Time
r: CODE       = Code size (kb)
s: DATA       = Data+Stack size (kb)
u: nFLT       = Page Fault count
v: nDRT       = Dirty Pages count
y: WCHAN      = Sleeping in Function
z: Flags      = Task Flags <sched.h>
* X: COMMAND    = Command name/line

Flags field:
0×00000001  PF_ALIGNWARN
0×00000002  PF_STARTING
0×00000004  PF_EXITING
0×00000040  PF_FORKNOEXEC
0×00000100  PF_SUPERPRIV
0×00000200  PF_DUMPCORE
0×00000400  PF_SIGNALED
0×00000800  PF_MEMALLOC
0×00002000  PF_FREE_PAGES (2.5)
0×00008000  debug flag (2.5)
0×00024000  special threads (2.5)
0×001D0000  special states (2.5)
0×00100000  PF_USEDFPU (thru 2.4)

进程的优先级和nice级别
进程优先级是一个决定进程被CPU执行优先顺序的参数，内核会根据需要调整这个值。Nice值是一个对优先权的限制。进程优先级的值不能低于nice值。（nice值越低优先级越高）
进程优先级是无法去手动改变的，只有通过改变nice值去间接的调整进程优先级。如果一个进程运行的太慢了，你可以通过指定一个较低的nice值去为它分 配更多的CPU资源。当然，这意味着其他的一些进程将被分配更少的CPU资源，运行更慢一些。Linux支持nice值的范围是19（低优先级）到 -20（高优先级），默认的值是0。如果需要改变一个进程的nice值为负数（高优先级），必须使用su命令登陆到root用户。下面是一些调整nice 值的命令示例，
以nice值-5开始程序xyz
#nice –n -5 xyz

改变已经运行的程序的nice值
#renice level pid

将pid为2500的进程的nice值改为10
#renice 10 2500

vmstat:

·process（procs）
r：等待运行时间的进程数量
b：处在不可中断睡眠状态的进程
w：被交换出去但是仍然可以运行的进程，这个值是计算出来的
·memoryswpd：虚拟内存的数量
free：空闲内存的数量
buff：用做缓冲区的内存数量
·swap
si：从硬盘交换来的数量
so：交换到硬盘去的数量
·IO
bi：向一个块设备输出的块数量
bo：从一个块设备接受的块数量
·system
in：每秒发生的中断数量， 包括时钟
cs：每秒发生的context switches的数量
·cpu(整个cpu运行时间的百分比)
us：非内核代码运行的时间（用户时间，包括nice时间）
sy：内核代码运行的时间（系统时间）
id：空闲时间，在Linux 2.5.41之前的内核版本中，这个值包括I/O等待时间；
wa：等待I/O操作的时间，在Linux 2.5.41之前的内核版本中这个值为0

iostat:

%user：user level（应用）的CPU占用率情况
%nice：加入nice优先级的user level的CPU占用率情况
%sys：system level（内核）的CPU占用情况
%idle：空闲的CPU资源情况

Device：块设备名
Tps：设备每秒进行传输的数量（每秒的I/O请求）。多个单独的I/O请求可以被组成一个传输操作，因为一个传输操作可以是不同的容量。
Blk_read/s, Blk_wrtn/s：该设备每秒读写的块的数量。块可能为不同的容量。
Blk_read, Blk_wrtn：自系统启动以来读写的块设备的总量。

块可能为不同的容量。块的大小一般为1024、2048、4048byte。可通过tune2fs或dumpe2fs获得：
# tune2fs -l /dev/hda1|grep ‘Block size’
Block size:               4096
# dumpe2fs -h /dev/hda1|grep ‘Block size’
dumpe2fs 1.35 (28-Feb-2004)
Block size:               4096

下面的命令用来查看系统正在运行的东西。
# top	 			# 显示当前CPU处理的信息
# mpstat 1	 		# 显示处理器相关的静态信息
# vmstat 2 			# 显示虚拟内存状态
# iostat 2 			# 显示I/O 信息
# systat -vmstat 1 		# BSD：汇总信息状态信息
# systat -tcp 1 		# BSD：显示TCP状态
# systat -netstat 1 		# BSD：活动的网络连接
# systat -ifstat 1 		# BSD：网络流量状态
# systat -iostat 1 		# BSD：CPU和硬盘的吞吐
# tail -n 500 /var/log/messages # 最后500条内核、系统消息
# tail /var/log/warn 		# 系统的警告信息
相应的命令在sysstat软件包中。

　　这首歌收录在薛岳的《生老病死》专辑中，他唱出的不是面临死亡的颓废和恐惧，而是生命最后的激情与绽放，带着一丝不舍，一丝留恋，又有那几多不屈服。录制这张唱片时，他已经备受肝病的折磨，不借 助外力支撑几乎难以直立，可正是这张燃尽他生命的专辑，唱出了他对生的热爱，让那最后一刻如烟花般绚烂，即便只这一瞬，但只要有人看见过，那美好就永留心 间。
　　
　　一个坚持音乐梦想的人，一个大器晚成的音乐人，一个乐途坎坷的音乐人，一个英年早逝的音乐人。
　　
　　80后的我们知晓薛岳的并不多，因为他在上个世纪九十年代，在当时对摇滚还很淡然地台湾，为了他的音乐梦想，他离开了舞台，离开了他的歌迷。
　　
　　关于薛岳的生平，我并不想说很多，感兴趣的人google一下就能搜到，这首带给我心灵震撼的歌，每每听起，总能让人振奋，沉思，明白生命的路到底该怎么走......

关于这首歌的背景资料：

《如果还有明天》的原唱是薛岳，一个七八十年代的“台湾摇滚之父”，在他三十多岁时，被证实癌症末期。他的好友兼音乐人刘伟仁得知薛岳患有癌症后， 就作了这首《如果还有明天》送给他。但最终薛岳还是在他36岁的时候离开了这个世界。面对命运的安排，现实的无奈，一个面临死亡的人唱出来的感觉不是颓废 不是悲痛，而是将剩余的生命激情挥洒以及最终的告白，或许更多的还有他的不舍和他不服命运安排的一种抵抗。信乐团和刘伟仁、薛岳并不是同时代的人。信乐团 在他们的《感谢自选辑》专辑中把《如果还有明天》作为第一首主打歌，就是想表达对摇滚前辈薛岳的致敬。信的极富穿透力的嗓音，薛岳的高吭，还有柯有伦的最 后那一段震撼的RAP，透过现代科技，完成了3人的时空合唱！

创作者：刘伟仁的版本

原唱：薛岳的版本

最好的翻唱：信的版本

如果还有明天
你想怎样装扮你的脸
如果没有明天
怎么说再见
我们都有看不开的时候
总有冷落自己的举动
但是我要把握每次感动
如果还有明天
如果真的还能够有明天
是否能把事情都做完
是否一切也将云消烟散
如果没有明天
要怎么说再见
给我 给我
你要什么样的改变
是不是明天看不到我
我那张哭笑不得 哭笑不得的脸
啦... ... ...
你有什么感觉
要怎么说再见
再见 再见

        在谈论session机制的时候，常常听到这样一种误解“只要关闭浏览器，session就消失了”。

       其实可以想象一下银行卡的例子，除非用户主动对银行提出销卡，否则银行绝对不会轻易删除用户的资料。对session来说也是一样的，除非程序通知服务器删除一个session，否则服务器会一直保留，程序一般都是在用户做log off的时候发个指令去删除session。

        然而浏览器从来不会主动在关闭之前通知服务器它将要关闭，因此服务器根本不会有机会知道浏览器已经关闭，之所以会有这种错觉，是大部分session机制都使用会话cookie来保存session id，而关闭浏览器后这个session id就消失了，再次连接服务器时也就无法找到原来的session。如果服务器设置的cookie被保存到硬盘上，或者使用某种手段改写浏览器发出的 HTTP请求头，把原来的session id发送给服务器，则再次打开浏览器仍然能够找到原来的session。

       恰恰是由于关闭浏览器不会导致session被删除，迫使服务器为seesion设置了一个失效时间，当距离客户端上一次使用session的时间超过这个失效时间时，服务器就可以认为客户端已经停止了活动，才会把session删除以节省存储空间。

       Session机制说明：

       session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。

       当程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否已包含了一个session标识 - 称为session id，如果已包含一个session id则说明以前已经为此客户端创建过session，服务器就按照session id把这个session检索出来使用（如果检索不到，可能会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保存。

       保存这个session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器。一般这个cookie的名字都是类似于 SEEESIONID，而。比如tomcat对于web应用程序生成的 cookie，JSESSIONID=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764，它的名字就是JSESSIONID。

       由于cookie可以被人为的禁止，必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器。经常被使用的一种技术叫做URL重写，另一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。

近来读了一篇《怎样成为优秀的软件模型设计者》的文章，感触颇深。仔细对比分析，发现原来我自己和周围的软件开发人员平常的一些自认为对的做法，有很多是有问题的。

1.人远比技术重要

你 开发软件是为了供别人使用，没有人使用的软件只是没有意义的数据的集合而已。许多在软件方面很有成就的行家在他们事业的初期却表现平平，因为他们那时候将 主要精力都集中在技术上。显然，构件（components），EJB（EnterpriseJavaBeans）和代理（agent）是很有趣的东西。 但是对于用户来说，如果你设计的软件很难使用或者不能满足他们的需求，后台用再好的技术也于事无补。多花点时间到软件需求和设计一个使用户能很容易理解的 界面上。从微软操作系统和OFFICE套件在市场上的成功可以得到对这个问题的最佳解释。

2.理解你要实现的东西

好的软件设计人员把大多数时间花费在建立系统模型上，偶尔写一些源代码，但那只不过是为了验证设计过程中所遇到的问题。这将使他们的设计方案更加可行。有效的系统分析和架构是减少后期错误或复杂实现的必要保证。

3.谦虚是必须的品格

你 不可能知道一切，你甚至要很努力才能获得足够用的知识。软件开发是一项复杂而艰巨的工作，因为软件开发所用到的工具和技术是在不断更新的。而且，一个人也 不可能了解软件开发的所有过程。在日常生活中你每天接触到的新鲜事物可能不会太多。但是对于从事软件开发的人来说，每天可以学习很多新东西（如果愿意的 话）。目空一切、自满自足的人是不可能成为一个优秀的软件架构师的。

4.需求就是需求

如 果你没有任何需求，你就不要动手开发任何软件。成功的软件取决于时间（在用户要求的时间内完成）、预算和是否满足用户的需求。如果你不能确切知道用户需要 的是什么，或者软件的需求定义，那么你的工程注定会失败。我们进行的很多需求分析，实际上是想当然的认为用户的需求和自己认为的应该是一样的。

5.需求其实很少改变，改变的是你对需求的理解

需求分析需要一丝不苟、精确的完成,而设计的时候反而可以发挥创造力和想象力。

如果需求经常改动，很可能是你没有作好需求分析，并不是需求真的改变了。

你可以抱怨用户不能告诉你他们想得到什么，但是不要忘记，收集需求信息是你的工作。

需求真正改变的情况很少，但是没有做好需求分析工作的理由却很多。

6.经常阅读

在这个每日都在发生变化的产业中，你不可能在已取得的成就上陶醉太久。

每个月至少读2、3本专业杂志或者1本专业书籍。保持不落伍需要付出很多的时间和金钱，但会使你成为一个很有实力的竞争者。这一条在我周围能够真正实现的人很少。

7.降低软件模块间的耦合度

高耦合度的系统是很难维护的。一处的修改引起另一处甚至更多处的变动。

你可以通过以下方法降低程序的耦合度：隐藏实现细节，强制构件接口定义，不使用公用数据结构，不让应用程序直接操作数据库。

耦合度低的软件可以很容易被重用、维护和扩充。

8.提高软件的内聚性

如果一个软件的模块只实现一个功能，那么该模块具有高内聚性。高内聚性的软件更容易维护和改进。

判断一个模块是否有高的内聚性，看一看你是否能够用一个简单的句子描述它的功能就行了。如果你用了一段话或者你需要使用类似“和”、“或”等连词，则说明你需要将该模块细化。

只有高内聚性的模块才可能被重用。

9.考虑软件的移植性

移植是软件开发中一项具体而又实际的工作，不要相信某些软件工具的广告宣传。

即使仅仅对软件进行常规升级，也要把这看得和向另一个操作系统或数据库移植一样重要。

当你使用了某个操作系统的特性，如它的进程间通信(IPC)策略，或用某数据库专有语言写了存储过程。你的软件和那个特定的产品结合度就已经很高了。

好的软件设计者把那些特有的实现细节打包隐藏起来，所以，当那些特性该变的时候，你仅仅需要更新那个包就可以了。这些说到容易做到很难，没有扎实的基本功是很难成功的。

10.接受变化

这是一句老话了：唯一不变的只有变化。

通过在建模期间考虑这些假设的情况，你就有可能开发出足够强壮且容易维护的软件。设计强壮的软件是你最基本的目标。

11.不要低估对软件规模的需求

Internet带给我们的最大的教训是你必须在软件开发的最初阶段就考虑软件规模的可扩充性。

今天只有100人的部门使用的应用程序，明天可能会被有好几万人的组织使用，下月，通过因特网可能会有几百万人使用它。

在软件设计的初期，根据在用例模型中定义的必须支持的基本事务处理，确定软件的基本功能。然后，在建造系统的时候再逐步加入比较常用的功能。

在设计的开始考虑软件的规模需求，避免在用户群突然增大的情况下，重写软件。同时也不能只因为考虑未知的用户量而花费太大的成本。需求分析是平衡控制的依据。

12.性能仅仅是很多设计因素之一

关注软件设计中的一个重要因素--性能，这好象也是用户最关心的事情。一个性能不佳的软件将不可避免被重写。

但 是你的设计还必须具有可靠性，可用性，便携性和可扩展性。你应该在工程开始就应该定义并区分好这些因素，以便在工作中恰当使用。性能可以是，也可以不是优 先级最高的因素，我的观点是，给每个设计因素应有的考虑。花哨的、运行快速但是不能解决用户问题的系统，是不会得到用户的满意的。

13.管理接口

应该在开发阶段的早期就定义软件模块之间的接口。这有助于开发人员全面理解软件的设计结构并取得一致意见，让各模块开发小组相对独立的工作。一旦模块的接口确定之后模块怎样实现就不是很重要了。

从根本上说，如果你不能够定义你的模块“从外部看上去会是什么样子”，你肯定也不清楚模块内要实现什么。

14.走近路需要更长的时间

在软件开发中没有捷径可以走。

缩短你的在需求分析上花的时间，结果只能是开发出来的软件不能满足用户的需求，必须被重写。

在软件建模上每节省一周，在将来的编码阶段可能会多花几周时间，因为你在全面思考之前就动手写程序。

你为了节省一天的测试时间而漏掉了一个bug，在将来的维护阶段，可能需要花几周甚至几个月的时间去修复。与其如此，还不如重新安排一下项目计划。

避免走捷径，只做一次但要做对。

15.证明你的设计在实践中可行

在设计的时候应当先建立一个技术原型，或者称为“端到端”原型。以证明你的设计是能够工作的。

你应该在开发工作的早期做这些事情，因为，如果软件的设计方案是不可行的，在编码实现阶段无论采取什么措施都于事无补。技术原型将证明你的设计的可行性，从而，你的设计将更容易获得支持。

16.应用已知的模式

目前，我们有大量现成的分析和设计模式以及问题的解决方案可以使用。

一般来说，好的模型设计和开发人员，都会避免重新设计已经成熟的并被广泛应用的东西。

17.研究每个模型的长处和弱点

目 前有很多种类的模型可以使用,如下图所示。用例捕获的是系统行为需求，数据模型则描述支持一个系统运行所需要的数据构成。你可能会试图在用例中加入实际数 据描述，但是，这对开发者不是非常有用。同样，数据模型对描述软件需求来说是无用的。每个模型在你建模过程中有其相应的位置，但是，你需要明白在什么地 方，什么时候使用它们。

18.在现有任务中应用多个模型

当你收集需求的时候，考虑使用样例模型，用户界面模型和领域级的类模型。

当你设计软件的时候，应该考虑制作类模型，顺序图、状态图、协作图和最终的软件实际物理模型。

程序设计人员应该慢慢意识到，仅仅使用一个模型而实现的软件要么不能够很好地满足用户的需求，要么很难扩展。

19.带工具的傻瓜还是傻瓜

使 用一个很优秀的CASE工具并不能使你成为一个建模专家，只能使你成为一个优秀CASE工具的使用者。成为一个优秀的建模专家需要多年的积累，不会是一周 针对某个价值几千美元工具的培训。一个优秀的CASE工具是很重要，但你必须学习使用它，并能够使用它设计它支持的模型。现在的编程工具越来越容易上手， 有不少的人已经不去加强对基础知识的学习，这是很危险的。

20.理解完整的过程

好的设计人员应该理解整个软件过程，尽管他们可能不是精通全部实现细节。

软件开发是一个很复杂的过程，除了编程、建模、测试等你擅长工作外，还有很多工作要做。好的设计者需要考虑全局。必须从长远考虑如何使软件满足用户需要，如何提供维护和技术支持等。

21.常做测试，早做测试

如 果测试对你的软件来说是无所谓的，那么你的软件多半也没什么必要被开发出来。建立一个技术原型供技术评审使用，以检验你的软件模型。在软件生命周期中，越 晚发现的错误越难修改，修改成本越昂贵。尽可能早的做测试是很值得的。测试工作一贯是得不到重视的，即便你天天挂在嘴上，但是请看看你的行动。黑盒测试将 压力给了测试人员，实际上很多的无用测试的根源应该从白盒测试中查找，这是软件开发人员的问题。

22.把你的工作归档

不值得归档的工作往往也不值得做。归档你的设想，以及根据设想做出的决定；归档软件模型中很重要但不很明显的部分。给每个模型一些概要描述以使别人很快明白模型所表达的内容。

23.技术会变，基本原理不会

如 果有人说“使用某种开发语言、某个工具或某某技术，我们就不需要再做需求分析，建模，编码或测试”。不要相信，这只说明他还缺乏经验。抛开技术和人的因 素，实际上软件开发的基本原理自20世纪70年代以来就没有改变过。你必须还定义需求，建模，编码，测试，配置，面对风险，发布产品，管理工作人员等等。

软件建模技术是需要多年的实际工作才能完全掌握的。好在我们可以从以上的建议开始，完善自己的软件开发经验。

要想成为优秀的软件架构师或软件开发人员，必须要有一个端正的态度，如果只是想依靠这个所谓的名份做幌子、混日子。我劝你还是不要踏入这个行业，以免误人误己。

作者简介：晏高明，中原油田地质录井处信息管理中心工作，2006年获国家级“系统分析员”认证资格证书。原文地址：http://www.zylj.com/Article_Show.asp?ArticleID=1184

原文地址：

http://blog.china.alibaba.com/blog/ethinker/article/b0-i6854277.html

平平淡淡才是真，大多数情况下，这七个字往往用在宽慰别人和自我安慰的时候。当激情不再，当新鲜淡去，当矛盾骤起，当琐事重复，当无力改变，当心力交瘁。 人们需要平复自己，需要接受现实，需要告诫自己“知足吧”，需要让理性捆住理想“换一个也未必更好”。这个时候，说出“平平淡淡才是真”这七个字听上去有 些无奈，有些落寞。自然也有不少人从平淡中获得感动，从平淡中学会珍惜，相伴长久。

但这并不是我所理解的“平平淡淡才是真”，我的理解很简单，所谓“平平淡淡才是真”，就是说，不平淡的基本上都是假的。人的本性是追求不平淡的，追求新鲜的，刺激的，能够刺激体内激素分泌的，但是这类情感就像兴奋剂和毒品，带给人的体验往往是虚幻的。美好的，但不真实。

试想这样两种情况，这实际上是我们经常能够看到的对浪漫情境的描述：

1、他彩票中了大奖，带着她去了浪漫之都法国（或者巴塞罗那，怎么浪漫怎么来），一起在塞纳河边散步，一起在游船吹风，在一个浪漫之夜，他向她求婚，她幸福地接受。

2、那一天，他跟她吵了架，他本来想提出分手的，她吵闹，痛哭，跑走。。。，他接到电话，她出了车祸，摔断了腿，他一直守护在她床边，她醒来后，他说“嫁给我吧”，她留下了幸福的眼泪。

中 大奖和摔断腿这样的事情不常发生，但是一旦发生，这样的情境是很容易产生的。如果真的是如此，这两种情况下的两对男女大多数情况下并不会幸福。为什么呢？ 因为不平淡，因为人在大喜和大悲的时候体现出的情感不是常态的，而两个人长久要能够在一起相处，需要的是那种常态下的本质上的契合。大喜和大悲的情况下， 人所有产生的感动都不是来自于常态的本心，而是来自于其他的因素，比如物质和环境的美妙，比如怜悯，比如责任，比如凄美和浪漫的感觉。而这些其实都是不真 实的，它真实存在，但是却未必发自本心。

所以，平平淡淡才是真，讲的是那种即使在油盐酱醋扫地洗碗吃饭睡觉吵闹争执这样的琐事中，你依旧能够有很强烈的幸福感和舒适感，依旧感觉comfortable，那就是真的了。

这里再补充一点，对于不同的人，常态是不一样的。所谓常态就是这个人生命特质中最经常出现的状态，以及最不可或缺的状态。对于一个木纳的人，可能一次浪漫的举动很难得，对于一个诗人，可能随时灵感迸发。所以，看一个人，要看他生命本质中最本质的那个状态。

刺激，浪漫，极致，唯美，心有灵犀，都是奢侈品，消耗得多了，付出的是生命的成本。这些东西如同美丽的花，平淡中悉心浇灌，养分够了，自然时间会沉淀出美 丽，一季开一次，谢了下季再开，足够了。指望天天鲜花满堂，那么你只能去花店买，买来的花，即使美，那美的生命也不属于你。

以上所说，非单指男女感情，朋友，同事，合作者，但凡需要建立在长期交往的关系，都是这个道理。