漂在北方的狼

我在公司发起了一个关于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，那就是真的了。

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

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

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

重新温习一遍

关系数据库设计之时是要遵守一定的规则的。尤其是数据库设计范式 现简单介绍1NF（第一范式），2NF（第二范式），3NF（第三范式）和BCNF，另有第四范式和第五范式留到以后再介绍。 在你设计数据库之时，若能符合这几个范式，你就是数据库设计的高手。

第一范式（1NF）：

在关系模式R中的每一个具体关系r中，如果每个属性值 都是不可再分的最小数据单位，则称R是第一范式的关系。

例：如职工号，姓名，电话号码组成一个表（一个人可能有一个办公室电话 和一个家里电话号码）

规范成为1NF有三种方法： 

一是重复存储职工号和姓名。这样，关键字只能是电话号码。 

二是职工号为关键字，电话号码分为单位电话和住宅电话两个属性 

三是职工号为关键字，但强制每条记录只能有一个电话号码。 

以上三个方法，第一种方法最不可取，按实际情况选取后两种情况。

第二范式（2NF）：

如果关系模式R（U，F）中的所有非主属性都完全依赖于任意一个候选关键字，则称关系R 是属于第二范式的。 

例：选课关系 SCI（SNO，CNO，GRADE，CREDIT）其中SNO为学号， CNO为课程号，GRADEGE 为成绩，CREDIT 为学分。 由以上条件，关键字为组合关键字（SNO，CNO） 

在应用中使用以上关系模式有以下问题： 

a.数据冗余，假设同一门课由40个学生选修，学分就 重复40次。 

b.更新异常，若调整了某课程的学分，相应的元组CREDIT值都要更新，有可能会出现同一门课学分不同。 

c.插入异常，如计划开新课，由于没人选修，没有学号关键字，只能等有人选修才能把课程和学分存入。 

d.删除异常，若学生已经结业，从当前数据库删除选修记录。某些门课程新生尚未选修，则此门课程及学分记录无法保存。 

原因：非关键字属性CREDIT仅函数依赖于CNO，也就是CREDIT部分依赖组合关键字（SNO，CNO）而不是完全依赖。 

解决方法：分成两个关系模式 SC1（SNO，CNO，GRADE），C2（CNO，CREDIT）。新关系包括两个关系模式，它们之间通过SC1中的外关键字CNO相联系，需要时再进行自然联接，恢复了原来的关系

第三范式（3NF）：

如果关系模式R（U，F）中的所有非主属性对任何候选关键字都不存在传递信赖，则称关系R是属于第三范式的。 

例：如S1（SNO，SNAME，DNO，DNAME，LOCATION） 各属性分别代表学号，姓名，所在系，系名称，系地址。 

关键字SNO决定各个属性。由于是单个关键字，没有部分依赖的问题，肯定是2NF。但这关系肯定有大量的冗余，有关学生所在的几个属性DNO，DNAME，LOCATION将重复存储，插入，删除和修改时也将产生类似以上例的情况。 

原因：关系中存在传递依赖造成的。即SNO -> DNO。 而DNO -> SNO却不存在，DNO -> LOCATION, 因此关键辽 SNO 对 LOCATION 函数决定是通过传递依赖 SNO -> LOCATION 实现的。也就是说，SNO不直接决定非主属性LOCATION。 

解决目地：每个关系模式中不能留有传递依赖。 

解决方法：分为两个关系 S（SNO，SNAME，DNO），D（DNO，DNAME，LOCATION） 

注意：关系S中不能没有外关键字DNO。否则两个关系之间失去联系。

BCNF：如果关系模式R（U，F）的所有属性（包括主属性和非主属性）都不传递依赖于R的任何候选关键字，那么称关系R是属于BCNF的。或是关系模式R，如果每个决定因素都包含关键字（而不是被关键字所包含），则RCNF的关系模式。 

例：配件管理关系模式 WPE（WNO，PNO，ENO，QNT）分别表仓库号，配件号，职工号，数量。有以下条件 

a.一个仓库有多个职工。 

b.一个职工仅在一个仓库工作。 

c.每个仓库里一种型号的配件由专人负责，但一个人可以管理几种配件。 

d.同一种型号的配件可以分放在几个仓库中。 

分析：由以上得 PNO 不能确定QNT，由组合属性（WNO，PNO）来决定，存在函数依赖（WNO，PNO） -> ENO。由于每个仓库里的一种配件由专人负责，而一个人可以管理几种配件，所以有组合属性（WNO，PNO）才能确定负责人，有（WNO，PNO）-> ENO。因为 一个职工仅在一个仓库工作，有ENO -> WNO。由于每个仓库里的一种配件由专人负责，而一个职工仅在一个仓库工作，有 （ENO，PNO）-> QNT。 

找一下候选关键字，因为（WNO，PNO） -> QNT，（WNO，PNO）-> ENO ，因此 （WNO，PNO）可以决定整个元组，是一个候选关键字。根据ENO->WNO，（ENO，PNO）->QNT，故（ENO，PNO）也能决定整个元组，为另一个候选关键字。属性ENO，WNO，PNO 均为主属性，只有一个非主属性QNT。它对任何一个候选关键字都是完全函数依赖的，并且是直接依赖，所以该关系模式是3NF。 

分析一下主属性。因为ENO->WNO，主属性ENO是WNO的决定因素，但是它本身不是关键字，只是组合关键字的一部分。这就造成主属性WNO对另外一个候选关键字（ENO，PNO）的部 分依赖，因为（ENO，PNO）-> ENO但反过来不成立，而P->WNO，故（ENO，PNO）-> WNO 也是传递依赖。 

虽然没有非主属性对候选关键辽的传递依赖，但存在主属性对候选关键字的传递依赖，同样也会带来麻烦。如一个新职工分配到仓库工作，但暂时处于实习阶段，没有独立负责对某些配件的管理任务。由于缺少关键字的一部分PNO而无法插入到该关系中去。又如某个人改成不管配件了去负责安全，则在删除配件的同时该职工也会被删除。 

解决办法：分成管理EP（ENO，PNO，QNT），关键字是（ENO，PNO）工作EW（ENO，WNO）其关键字是ENO 

缺点：分解后函数依赖的保持性较差。如此例中，由于分解,函数依赖（WNO，PNO）-> ENO 丢失了, 因而对原来的语义有所破坏。没有体现出每个仓库里一种部件由专人负责。有可能出现 一部件由两个人或两个以上的人来同时管理。因此，分解之后的关系模式降低了部分完整性约束。

一个关系分解成多个关系，要使得分解有意义，起码的要求是分解后不丢失原来的信息。这些信息不仅包括数据本身，而且包括由函数依赖所表示的数据之间的相互制约。进行分解的目标是达到更高一级的规范化程度，但是分解的同时必须考虑两个问题：无损联接性和保持函数依赖。有时往往不可能做到既有无损联接性，又完全保持函数依赖。需要根据需要进行权衡。

1NF直到BCNF的四种范式之间有如下关系： 

BCNF包含了3NF包含2NF包含1NF

小结： 

目地：规范化目的是使结构更合理，消除存储异常，使数据冗余尽量小，便于插入、删除和更新 

原则：遵从概念单一化 "一事一地"原则，即一个关系模式描述一个实体或实体间的一种联系。规范的实质就是概念的单一化。 

方法：将关系模式投影分解成两个或两个以上的关系模式。 

要求：分解后的关系模式集合应当与原关系模式"等价"，即经过自然联接可以恢复原关系而不丢失信息，并保持属性间合理的联系。

注意：一个关系模式结这分解可以得到不同关系模式集合，也就是说分解方法不是唯一的。最小冗余的要求必须以分解后的数据库能够表达原来数据库所有信息为前提来实现。其根本目标是节省存储空间，避免数据不一致性，提高对关系的操作效率，同时满足应用需求。实际上，并不一定要求全部模式都达到BCNF不可。有时故意保留部分冗余可能更方便数据查询。尤其对于那些更新频度不高，查询频度极高的数据库系统更是如此。

在关系数据库中，除了函数依赖之外还有多值依赖，联接依赖的问题，从而提出了第四范式，第五范式等更高一级的规范化要求。在此，以后再谈。

各位朋友，你看过后有何感想，其实，任何一本数据库基础理论的书都会讲这些东西，考虑到很多网友是半途出家，来做数据库。特找一本书大抄特抄一把，各位有什么问题，也别问我了，自已去找一本关系数据库理论的书去看吧，说不定，对各位大有帮助。说是说以上是基础理论的东西，请大家想想，你在做数据库设计的时候有没有考虑过遵过以上几个范式呢，有没有在数据库设计做得不好之时，想一想，对比以上所讲，到底是违反了第几个范式呢？ 

我见过的数据库设计，很少有人做到很符合以上几个范式的，一般说来，第一范式大家都可以遵守，完全遵守第二第三范式的人很少了，遵守的人一定就是设计数据库的高手了，BCNF的范式出现机会较少，而且会破坏完整性，你可以在做设计之时不考虑它，当然在ORACLE中可通过触发器解决其缺点。以后我们共同做设计之时，也希望大家遵守以上几个范式。

虽然题目是“面试百问”，但是作为一个软件开发人员，这些问题不是面试的时候考官给你提的问题，而是自己问自己是否能够回答下面的问题？

孔子说：“一日三省吾身”，我们不用一日三省，每天睡觉前想想自己今天一天是否有收获就可以了。

来源：http://www.infoq.com/cn/articles/programmer-interview

英文原文：http://www.noop.nl/2009/01/100-interview-questions-for-software-developers.html

需求

1. 你能给出一些非功能性（或者质量）需求的例子么？
2. 如果客户需要高性能、使用极其方便而又高度安全，你会给他什么建议？
3. 你能给出一些用来描述需求的不同技术么？它们各自适用于什么场景？
4. 需求跟踪是什么意思？什么是向前追溯，什么是向后追溯？
5. 你喜欢用什么工具跟踪需求？
6. 你怎么看待需求变化？它是好是坏？给出你的理由。
7. 你怎样研究需求，发现需求？有哪些资源可以用到？
8. 你怎么给需求制定优先级？有哪些技术？
9. 在需求过程中，用户、客户、开发人员各自的职责是什么？
10. 你怎么对待不完整或是令人费解的需求？

功能设计

1. 在功能设计中有哪些隐喻？给出几个成功的例子。
2. 如果有些功能的执行时间很长，怎么能让用户感觉不到太长的等待？
3. 如果用户必须要在一个很小的区域内，从一个常常的列表中选择多个条目，你会用什么控件？
4. 有哪些方法可以保证数据项的完整？
5. 建立系统原型有哪些技术？
6. 应用程序怎样建立对用户行为的预期？给出一些例子。
7. 如何入手设计一组数量庞大而又复杂的特性，你能举出一些设计思路吗？
8. 有一个列表，其中有10个元素，每个元素都有20个字段可以编辑，你怎样设计这种情况？如果是1000个元素，每个元素有3个字段呢？
9. 用不同的颜色对一段文本中的文字标记高亮，这种做法有什么问题？
10. Web环境和Windows环境各有些什么限制？

技术设计

1. 什么是低耦合和高聚合？封装原则又是什么意思？
2. 在Web应用中，你怎样避免几个人编辑同一段数据所造成的冲突？
3. 你知道设计模式吗？你用过哪些设计模式？在什么场合下用的？
4. 是否了解什么是无状态的业务层？长事务如何与之相适应？
5. 在搭建一个架构，或是技术设计时，你用过几种图？
6. 在N层架构中都有哪些层？它们各自的职责是什么？
7. 有哪些方法可以确保架构中数据的正确和健壮？
8. 面向对象设计和面向组件设计有哪些不同之处？
9. 怎样在数据库中对用户授权、用户配置、权限管理这几项功能建模？
10. 怎样按照等级制度给动物王国（包括各种物种和各自的行为）建模？

程序设计

1. 你怎样保证你的代码可以处理各种错误事件？
2. 解释一下什么是测试驱动开发，举出极限编程中的一些原则。
3. 看别人代码的时候，你最关心什么地方？
4. 什么时候使用抽象类，什么时候使用接口？
5. 除了IDE以外，你还喜欢哪些必不可少的工具？
6. 你怎么保证代码执行速度快，而又不出问题？
7. 什么时候用多态，什么时候用委派？
8. 什么时候使用带有静态成员的类，什么时候使用单例？
9. 你在代码里面怎么提前处理需求的变化？给一些例子。
10. 描述一下实现一段代码的过程，从需求到最终交付。

算法

1. 怎样知道一个数字是不是2的乘方？怎样判断一个数是不是奇数？
2. 怎样找出链表中间的元素？
3. 怎样改变10,000个静态HTML页面中所有电话号码的格式？
4. 举出一个你所用过的递归的例子。
5. 在散列表和排序后的列表中找一个元素，哪个查找速度最快？
6. 不管是书、杂志还是网络，你从中所学到的最后一点算法知识是什么？
7. 怎样把字符串反转？你能不用临时的字符串么？
8. 你愿意用什么类型的语言来编写复杂的算法？
9. 有一个数组，里面是从1到1,000,000的整数，其中有一个数字出现了两次，你怎么找出那个重复的数字？
10. 你知道“旅行商问题（Traveling Salesman Problem）”么？

数据结构

1. 怎样在内存中实现伦敦地铁的结构？
2. 怎样以最有效的方式在数据库中存储颜色值？
3. 队列和堆栈区别是什么？
4. 用堆或者栈存储数据的区别是什么？
5. 怎样在数据库中存储N维向量？
6. 你倾向于用哪种类型的语言编写复杂的数据结构？
7. 21的二进制值是什么？十六制值呢？
8. 不管是书、杂志还是网络，你从中所学到的最后一点数据结构的知识是什么？
9. 怎样在XML文档中存储足球比赛结果（包括队伍和比分）？
10. 有哪些文本格式可以保存Unicode字符？

测试

1. 什么是回归测试？怎样知道新引入的变化没有给现有的功能造成破坏？
2. 如果业务层和数据层之间有依赖关系，你该怎么写单元测试？
3. 你用哪些工具测试代码质量？
4. 在产品部署之后，你最常碰到的是什么类型的问题？
5. 什么是代码覆盖率？有多少种代码覆盖率？
6. 功能测试和探索性测试的区别是什么？你怎么对网站进行测试？
7. 测试套件、测试用例、测试计划，这三者之间的区别是什么？你怎么组织测试？
8. 要对电子商务网站做冒烟测试，你会做哪些类型的测试？
9. 客户在验收测试中会发现不满意的东西，怎样减少这种情况的发生？
10. 你去年在测试和质量保证方面学到了哪些东西？

维护

1. 你用哪些工具在维护阶段对产品进行监控？
2. 要想对一个正在产品环境中被使用的产品进行升级，该注意哪些重要事项？
3. 如果在一个庞大的文件中有错误，而代码又无法逐步跟踪，你怎么找出错误？
4. 你怎样保证代码中的变化不会影响产品的其他部分？
5. 你怎样为产品编写技术文档？
6. 你用过哪些方式保证软件产品容易维护？
7. 怎样在产品运行的环境中进行系统调试？
8. 什么是负载均衡？负载均衡的方式有哪些种？
9. 为什么在应用程序的生命周期中，软件维护费用所占的份额最高？
10. 再造工程（re-engineering）和逆向工程（reverse engineering）的区别是什么？

配置管理

1. 你知道配置管理中基线的含义么？怎样把项目中某个重要的时刻冻结？
2. 你一般会把哪些东西纳入版本控制？
3. 怎样可以保证团队中每个人都知道谁改变了哪些东西？
4. Tag和Branch的区别是什么？在什么情况下该使用tag，什么时候用branch？
5. 怎样管理技术文档——如产品架构文档——的变化？
6. 你用什么工具管理项目中所有数字信息的状态？你最喜欢哪种工具？
7. 如果客户想要对一款已经发布的产品做出变动，你怎么处理？
8. 版本管理和发布管理有什么差异？
9. 对文本文件的变化和二进制文件的变化进行管理，这二者有什么不同？
10. 同时处理多个变更请求，或是同时进行增量开发和维护，这种事情你怎么看待？

项目管理

1. 范围、时间、成本，这三项中哪些是可以由客户控制的？
2. 谁该对项目中所要付出的一切做出估算？谁有权设置最后期限？
3. 减少交付的次数，或是减少每个每个交付中的工作量，你喜欢哪种做法？
4. 你喜欢用哪种图来跟踪项目进度？
5. 迭代和增量的区别在哪里？
6. 试着解释一下风险管理中用到的实践。风险该如何管理？
7. 你喜欢任务分解还是滚动式计划？
8. 你需要哪些东西帮助你判断项目是否符合时间要求，在预算范围内运作？
9. DSDM、Prince2、Scrum，这三者之间有哪些区别？
10. 如果客户想要的东西太多，你在范围和时间上怎样跟他达成一致呢？

这几句写的很好，来自五月天- 《你不是真正的快乐》

这世界笑了 
於是你合群的一起笑了 
当生存是规则 
不是你的选择 
於是你含着眼泪 
飘飘荡荡跌跌撞撞的走着