是否已落后于时代 我讨厌UNIX的十大理由
2005.12.15  来自：IT168　
    1971年，《UNIX时代系统分享》第一版刚刚出版。这个简单的操作系统允许多个用户来使用一个低端的微型机，马上就变得非常受欢迎起来，很大程度上是因为资源代码可以被大学自由使用，这诞生了伴随着学习UNIX而成长的一代人。

　　比起开发他们自己的操作系统，许多的公司被授权允许使用UNIX的源代码并制造出他们自己的派生系统来在他们自己的硬件上运行。最后，UNIX取代成为了最商业化的操作系统。

　　在上个年代，UNIX的自由复制版本和派生版本开始接管保守派UNIX系统的地位。在源代码方面，这些版本已经很少使用了，如果有任何使用的话，那也是它们最早版本的故事了；但是在设计和原理方面，有很大程度上仍然能够追溯到最初的根基。

　　UNIX有很多的长处，但是和其他的设计一样，它开始显现出跟不上时代的问题了。这篇文章里所列出的观点问题并不是所有UNIX系统都有的，有些会有多一些的问题，有的会少一些。

　　1． 所有的一切都必须是一个文件（除非它不是）

　　所有的一切在UNIX系统里面都必须是一个文件。当然，除了那些不是文件的东西以外，比如说网络套接字。这被广泛看作是一个UNIX的定义之一。什么是在UNIX里的一个文件？就是一段字节。没有任何类型的信息是编码的，所以你想要理解一个文件内容的唯一方法就是已经知道它是关于什么的。

　　文件的暗喻性在UNIX里面已经变得越来越明显了：

　　物理磁盘是文件——这些文件有固定的大小，但是你能够在磁盘上寻找任何一个点；

　　串行端口是文件——这些文件能够读写，但是寻找一个串行端口是没有意义的；

　　一般的文件也同样是文件——并且这些文件能被连续和随机地读取，甚至是改变文件大小。当然，给了一个文件名的程序并不可能知道是个大概什么类型的操作在这个文件上，你只有去试一个操作，然后看看会不会失败。在好的UNIX惯例里，这样的一些操作，比如像一个NFS-shared文件，都显示的是正在工作，但实际上在后台就失败了。

　　经常举的一个有UNIX优点的例子是：你能够把程序和设备直接连接起来，并且它们可以工作，并不需要为设备界面来进行特别的设计。这在一方面来说是完全正确的。在一个只能进行线性文本打印的打印机上的书写是和在一个文本终端机或是在一个文本文件上的书写是完全一样的。尽管如此，现在更多的人趋向于使用除了单一文本以外的一些东西。如果我有一个程序能够输出一个图像，我能不能就直接把这个图像发送到终端机上并且让它显示出来呢？我能不能用同样的方法再把它发给打印机呢？当然，如果我有一个X版本的服务器，并且能够支持X版本的打印机外设，那么答案会是可能的。但是如果我没有，那么我只能把它用X绘画调用的方式发到屏幕上，以PostScript语言（一种图解类程序设计语言）的形式发给打印机，然后以一个连续的字节流发给一个文件。当我不得不去弄懂另外一端的设备时，这些设备有同一个界面根本就不是一件好事——实际上对于我来说，这只是又多了一个更高的抽象层罢了。

    2 所有的一切都必须是一个文本

　　在文件里的所有一切都是一个字节流。对于文本来说这没什么关系。当然，如果每个人都生活在美国并且永远都只需要使用7（比特）位的美国信息交换标准码，那么对于文本来说是没什么关系的。不幸的是，还有人生活在其他的地方或者是使用其他不同字符集的设备。所有的用不同代码的人们需要某些机制来解释他们所使用的字符集的意义。

　　这个假设是：所有的一切应该都是文本，涵盖在UNIX设计中。除了在极少数几个案例中，指令是用来产生或期望产生文本的。与另外一个UNIX设计原则——把所有的一切都放到同一个命令行解释器（shell）里，即使它是属于一个共享库——来相比，这是一个更加奇怪的设计。一个聪明的方法应该是：命令产生标准的二进制数据，并且由那个命令行解释器来把它显示出来，如果它是准备被显示出来的话。

　　我们来想想ls命令，这是一个能列出某个目录下内容的命令。如果你想要把这些内容以“区分字母大小写”为顺序整理排列出来，你需要把输出通过管道放到排序命令中来。现在想象一下你要把输出以文件的大小为顺序排列出来。你可以用ls来显示出这些文件的大小，然后让排序命令以文件大小行为顺序进行排序。这是可以的，但是接下来所有的文件大小都只是以字节来显示了（或者有些时候是以分配单元来显示，通常是512个字节为单位，取决于你UNIX的变量）。这种方式并不是那么友好，所以你让ls把所有的输出再换成友好的形式——用字节、千字节、兆字节等等来表示。不幸地是，排序命令并不懂得1MB是比6KB要大的，所以它就把所有的顺序都很蠢地弄乱了。或者是另一种方法：如果ls把输出作为一个有标题的定义，把它们以加上文件名字、类型的竖行显示出来，你让sort把这个竖行以文件“大小”来排列，最后你还需要让你的命令行解释器把这个“大小”翻译成为一个人类能懂的形式。

    3． 没有智能修正（Introspection）

　　UNIX的命令行被看作是它最有价值的资产之一。我喜欢一个命令行的原理概念，我认为UNIX的命令行解释器会是最不可能让它完美工作的执行之一（但是我认为UNIX的命令行解释器并不能够完美实现这个理论）。

　　任何使用过zsh的人都会对它所提供的那些难以置信的自动完成功能很熟悉。对于很多的程序来说，它能够自动完成命令行的选项。当你使用secure copy（安全复制）程序时，它甚至能够在其他的机器上构建一个远程命令行解释器并自动命名文件名。但是当我们来观察它是怎样来工作的时候，可能会带给每一个人恶梦。对每一个程序（或者每一个程序组，如果你真的是很幸运的话），都会建立一个解析器来扫描从程序中输出的帮助并创建那个自动完成清单。当你添加的新程序并没有制造出一个帮助屏幕，或者是制造出一个不同格式的时候，zsh就卡住不能运行了。

　　这样来考虑，现在在每一个目标，包括程序中，都有一个假设系统来支持简单的智能修正方法。在这个系统里，命令行解释器会询问那些有良好定义界面的应用软件去获得一个可用选项的清单。它同样能够限制输入文件的类型和其他有用的数据。在一个理想的系统里，这个信息将会被放在很精确的位置，因此用户能够以他自己的语言进入到命令行选项里。

　　在很多情况下智能修正都是很有用的。在Mac OS操作系统上，潜在的文件系统支持在文件上最基本智能修正的形式——你能够获得一个32比特的文件类型。这并不理想，但是它至少允许做出某种意义上的智能决策，来决定使用哪一个应用软件来打开文件。把这个能力更提高一步来说，每个文件类型应该有一个文件结构上的“机械部分”的描述来和它一起。这样以后，一个文字处理程序就能够从另一个系统中扫描到一个文件，并且用这个信息把它很轻松地翻译成它原有的形式——至少，它能够提取出单一文本并且可能进行某种基础的格式化。

    4.     X11：几乎是一个图形用户界面

　　X11是用来在屏幕上显示像素的一种机制。除此以外，它支持一些非常基础的窗口功能。如果你想要显示诸如按钮或是滚动条一类的东西，你需要一个更高层的工具包。

　　对X11本身来说，这并不是一个坏主意。添加额外的抽象层只会导致轻微的性能降低，但是这使得编码需要更多的维护。首要的问题是我们并没有一个为X11配置的标准工具包——或者说，有那么几个，但是它们在应用的时候却是非常难做出与你需要的那些按钮或是滑行条一类东西相同的基础外表和感觉的。当然，缺少一系列关于人性化界面的指导丛书也是对X11没有什么帮助的。

　　X11最主要的问题就是网络透明性。X11的设计要求之一就是它允许远程显示。不幸的事，这是在一个很低的层面上的远程显示。所有的X11确实是远程显示了——在连接中所有的另一端的逻辑冗余都显示了出来。如果你是在一个快速的本地连接中，对这个差别不会有太大感觉。如果你是在另一端慢速的或是高等待时间的连接中，你的感觉就会很不好受了。

　　在X11变得很受欢迎的时候，另一个系统也被开发出来了。NeWS是在PostScrip语言的基础上开发出来的。对于开发者来说，开发这个系统的最明显的优势原因在于：在PostScrip的输出形式下，你能够给打印机发送一个与发送在屏幕上完全一样的输出。第二个优势为：它能够在连接到屏幕的机器上运行UI分量。如果你摁了一个按钮，足够的逻辑能够在本地为这个按钮的启动做出反应，并向服务器发送相应的活动。

　　在X11模式上，按钮的点击被发送给机器去运行相关的应用程序，这要求必须把在动作序列中的每一帧都发送给屏幕。如果这个感觉不好，可以考虑以文本的方式再来感觉一下——每一次你输入一个字符，每个字符会被传输到服务器处理响应之后，再返回输出屏幕进行显示。现在来想象一下你所在的网络是以200ms（的等待时间连接在一个服务器上……

　　所以开发NeWS的主意是很好的，以至于它一直不断的被改进。现在网络的最新专门术语“AJAX”是同一个概念下的另一个实现方式。浏览器处理用户界面响应，而后台服务器则异步处理应用逻辑。甚至在这个之前，Java applets程序就在做着同样的事情——在Java中绘制用户界面和处理用户请求，与远程服务器交互而由其处理剩余应用逻辑。

    5． 标准的输入，标准的输出

　　在UNIX的命令行里，你能够使用管道来把程序连接起来。这对于简单工作流程来说是很好的。但它缺少灵活性，原因在于机制已经习惯于执行它了。最原先的是程序读出输入然后写出输出。在交互式的电脑上，拥有两条输出流会变得更加有益——一条是用来输出预期内容，另一条用来输出错误信息。如今在一个UNIX系统里，每一个单一的输入流都有两个输出流。

　　这个限制意味着一些命令就不能被一个UNIX的命令行来执行。考虑一下一个过滤器把一个多元化的电影片段信号分离为视频流和音频流。最多你能够把视频流发送为标准的输出，把音频流发送为标准的错误输出，但是接下来你就没有办法来再把输出中的错误报告出来了。

　　还有更糟的是，这些输出流都是单向性的。这就意味着两个过滤器之间是不可能互相协作的。在理想上的是，源过滤器应该能够发出不同输出格式的一个选择列表，然后目的过滤器能够根据这个列表选择一种适合的形式。但是在一个UNIX的命令行中，这个却需要由使用者来预先完成。一旦过滤器开始运行，就根本没有办法来改变输出的格式——例如在有很少网络带宽可以利用的情况下需要减小比特率。

6． 同步系统调用

　　在UNIX系统里，每一次你做系统调用，你不得不把它交换到内核空间里面去——一个相关的昂贵操作。你只能等待直到内核程序完成了操作后再继续下一步骤。在一些情况下，内核只是复制了你的参数然后留到以后再处理。考虑一下书写一些字节到一个字节流里面的情况吧。在UNIX系统里，你将要使用调用函数来系统调用。这将会切换到内核空间，拷贝字符缓冲，之后再进行处理。如果你幸运的话，不一会儿你就能得到一个关于“书写成功（或是失败）”的提示。

　　如果你要写很多的数据，你不得不停止做一大堆的系统调入并花上很多时间来让你的CPU在特许模式和非特许模式之间转换。如果你是在一个SMP系统里，因为现在这种情况越来越普通了，你就必须等待直到所有种类的核心同步代码开始运行后才能做事。

　　在一个例如QNX的微核系统里，系统的调入是不同步的。也就是说你能够让它们在一个用户空间缓冲器区里面等待，然后在你的CPU时间片后再把它们全部转换到核心空间里，核心程序再来打断正在进行的处理。这个方法让SMP系统升级了不少，并且提供了一个在单一处理器系统里以减少模式转换时间的需求来大力推进命令的执行。

    7． 单行道系统调用

　　虽然NetLink API解决了Linux里的部分问题，但是把数据提出核心却是很难的。没有任何的标准机制来让UNIX核心在一个UNIX程序里调入一个功能。事实上，从核心里要发送比1比特大的信息到用户空间程序里是非常困难的。那个1比特是一个信号、一个旗帜来说明有事请发生了。要举例子的话就是一个不同步的I/O请求。理想上来说，当你的I/O操作已经完成的时候你会得到一些提示。在UNIX里面，你会收到一个信号。这个信号告诉你一个不同步的I/O操作已经发生了，但是并不指出是哪一个操作——然后你就只有通过轮流询问所有的操作来找出到底是什么。

　　缺少这个机制就很大程度上增加了核心内需要做的事情。这是一个UNIX的公理，那就是政策和机制必须是分开的。但是在UNIX核心内提供一个机制和在外部提供一个政策是很难的，因为核心并不能够通知“用户空间代表”什么样的政策决定是必需的。关于解决这个问题，标准的UNIX工作区的方式是让一个程序来发起一个系统调入，然后阻挡它，直到核心能够表达出什么，再在晚一些的时候把这个调入返回来。

　　值得注意的是，这个并没有被应用到UNIX类的微核系统中来，例如GNU HURD或是Mach系统。这些系统使用一个非常简单的核心，并提供一个简单的界面给硬件和信息传递设备，然后运行所有的一切，但是就是除了在用户空间里。因此在这些系统里，核心代表了很多到用户空间的服务器，它需要一个机制来发送信息，并且这个机制要适用于所有用户空间的程序。

    8． C语言：跨平台PDP汇编程序

　　C语言是用来帮助UNIX变得更轻便的。它是被设计来为PDP-11制造好的代码，并且非常近似于展现出UNIX机制的能力。在C语言里没有共发性的支持，比如说，在一个很现代的语言里，例如Erlang，原语存在于语言中是为了在它们中间制造不同的执行线和发送信息。在当买两台计算机要比买一台速度快两倍的计算机便宜得多的今天，这是非常重要的。

　　C语言同样缺少一些在现代语言里应有的功能特性。其中最明显的一项就是缺少对信息串的支持。缺少对阵列的范围测试是另一个例子——这是要对UNIX软件中的大部分安全漏洞负责任的一个缺陷。其他为一些安全漏洞负责任的C语言的另一个方面是：C语言里面的整数有一个固定的大小——如果你想要储存某个太大的东西时，这个东西将会溢出。不幸地是，这个溢出并不那么好处理。在Smalltalk里面，溢出会被开发者很显而易见地发现并抓住，并且通过增加整数的大小就可以解决了。在其他的一些低级语言里，这个任务将产生一个错误并由程序来处理。在C语言里，它是被安静地忽视了。那么在C语言里无法改变的最小的整数是有多大呢？这个取决于整个的执行。

　　接下来，我们该说说可悲的、不适当的C语言预处理程序了。C语言里的预处理程序是由非常简单的记号来替代的——它代码的底层结构并没有概念。这个步骤局限性的一个很好例子就是当你试图在这个语言上添加控制结构的时候。对Smalltalk来说这是微不足道的——在Smalltalk里面的代码块能够像自变量一样被传递，所以许多信息的调入能够成为一个控制命题。在LISP里面，预处理程序能够被使用来编码设计模式，大大地减少了所需要的代码数量。C语言只能够处理内联功能类的相等物。

　　但是C语言的真正问题在于：它是UNIX系统的标准语言。所有的系统调入和共用库都显露了C语言的功能，因为C语言是一个最小公分母——C语言实在是太低等了。C语言是在当程序上的范例刚刚获得接受时被设计出来的，当真正的程序员使用汇编语言和结构编程只是作为大学学术界所关心的事的时候设计出来的。如果你想在UNIX中做出一个面向对象的库，要么你就用它所用的语言暴露出来——强迫其他开发者选择和你所使用的一样的语言——要么你来为C语言写一个笨重的补丁。都不是什么好的解决方案啊！

     9． 小的工具，但是并不小的库

　　C语言的原理是用一个小的工具来做好一件事情。一个小的工具和一个小的库的区别是双重的：

　　一个小的工具会有大一些的开销，它自己的处理需要所有相关的成本；

　　一个小的工具灵活性会差一些。另一个程序利用它能够调用它（可能和一些命令行的自变量一起），然后它只能够被标准的输入所控制。这是非常不灵活的，并且会导致很多问题。

　　最常引用的就是UNIX的mv命令。UNIX的设计者们决定了设定命令行解释器，而不是应用程序，应该为展开的通配符做出反应。这就是说这个程序被调用了将没有办法知道是否自变量是原始的一个文件清单或是一个通配符。假设命令行显示为以下这样的：

　　mv *.exe *.bin

　　如果UNIX为通配符的展开提供了一个库，而不是为设定命令行解释器去做这件事，那么mv命令会知道你已经收到了两个自变量，并且你想要把所有扩展名为.exe的文件全都重新命名为扩展名为.bin的文件。但是在UNIX里面就不是这种情况了。那个mv命令接到了一个文件清单后会试图用在清单里的最后一个文件的名字来重新命名所有的文件。

    10． 必须遵循的带内触发标准（In-Band Signaling）

　　任何一个通讯工程师都会告诉你带内触发是一个很糟糕的主意。但是在UNIX里面，它经常是唯一的一种做事方法。UNIX在元数据概念方面似乎有一个很大的原理缺陷。UNIX文件系统甚至不包括一个单一比特来表示一个文件是隐藏的。所代替的是，UNIX使用一个点（.）在一个文件名的前面来表示这是个隐藏文件。当Mac OS来使用32比特的文件类型代码时，DOS类的系统使用一个三字符的文件扩展名来定义文件的类型，而UNIX则把文件类型埋藏到了文件名里面。

　　带内发信号载UNIX内是随处可见。所有的一切都是一个文件，所以所有的一切都是一个字节流。当其他的系统允许其他的元数据来和文件结合在一起时，UNIX只是把所有的一切作为长长的字节流。这导致了控制结构和数据被混合在一起，因为把应用程序连接在一起、或是把它和其他设备连接在一起的方式是一个假的文件。

　　是U(NIX)退休的时候了

　　UNIX在它的时代是一个非常好的操作系统。它在相关的低端微机上有很好的表现，并且提供了一些以前只能够在大型主机上才能运用的功能。对于一个PDP-11来说，它是一个完美的选择。现代的操作系统都基于同样的设计原理，但是却因为要把这个系统安装在一个比口袋计算器还要小的机器上所做出的妥协而受到了严重的威胁。

HR声音：应届毕业生，我对你“非常不满”
2005.12.02  来自：Donews  
 
 
       最近毕业生招聘的专场，开始在全国“铺开”。
     我很少直接去毕业生专场招人。今天广东的一个综合场，是我第一次参加的毕业生现场招聘会。
     今天我是以多重身份，参与这个招聘会的：作为公司的人力资源总监，我希望为公司招到一批合适的储备人才；作为一个职业规划研究者，我要深入一线接触准备投身社会就业大军——应届生的特点；作为广东省劳动学会、人力资源管理协会的理事，我想藉此了解毕业生的就业状态、以及他们的所想所思。
     到了招聘场，我感到的不是一种兴奋，而是一种压抑。这是我任职人力资源总监以来的第5年，而5年来，中国的毕业生整整翻了5倍，06年将超过360万。进场的时间还没到，售票点外已经排起了多条百米“人带”。这时，我的心中不禁掠过一丝淡淡的伤感。很多年以前，我也曾经这样在茫茫人龙中，带着满怀的期待排队，每天只能排到3、5个队伍中，去投3、5份简历，而后开始了更加漫长的心里等待……而现在，人龙的规模远远超越我作为毕业生的那个时候。现在是更多的人可以读大学了，但我无法分清，眼前的这种景象，该是用壮观来形容，还是用悲壮来形容，无法说清，这究竟是好事还是坏事。
      我做了一些统计，也思考了一些细节。
大学生自提的薪酬水平大致如下：
研究生：全部都是说“4000元以上”。
本科生：2000－3500元。
大专生：基本都是提2000以下。
      其中，技术类的（如WEB开发），相对偏高，在3000－3500之间。
     这些数据，除了研究生略有下降，其它比去年偏高（去年我是在5月份以后，才陆续通知一些人到公司面试）。一方面也许现在是刚刚开始，大家把握不到竞争线的准绳，另一方面，我希望是因为就业市场在转暖（但是看不到这种迹象）。
而其中，有不少细节值得一提。
     一般情况下，我接过简历的时候，不会问也不会看应聘者是来自那个学校（我从不以学校论学生）。但是当他们回答薪酬要求的时候，却的确体现了一种差别。今天主要都是来自广东学校的学生，本科线上，暨南大学、华师大、华工、华农提的要求都比较高，要求在2500元以上；而普通一点的院校，则提2500元以下；专科线上，则有一个特殊的群体，就是所谓“非正规院校”，比如什么技工类学校、民办学校。他们提的要求，全部都是在1200元以下——问了一轮之后，我就开始对号入座的猜他们是来自那个学校，然后对照简历，我发现几乎达到“问价格则知学校”的地步。敢情是学校给了他们一个“宏观指导”？有几个技工类的大专生，都是说800元，我问他们是不是都是同学，他们说“是”。“为什么你提这个数字呢？”，他们说：“因为我们老师说，我们现在的竞争力大概就是800元”。这种对学生“批量生产，统一价格”的指导方针，令我为他们感到悲哀。老师的这一句“指导”，足以给全面摧残他们3年来的系统教育和信心，也足以毁灭这个学校——不可否认，他们中的不少人，的确市场上是按照这个价格去招聘的（特别是销售）。但是，学生不是纯粹的产品，每个人都是独一无二的，怎么可以做这种统一的指导呢？为什么不会有个别人更加有自信的提出1000、1500？我今天感受到的“好学校”和“差学校”的差别，最大和最根本的差别在于学生自信心的差别。我偶尔被邀去学校做讲座的时候，我经常会对学生说一句话：“你优秀，是因为你认为自己优秀。”学生的自我意想，自我心理定位，会永远的影响他一生。如果我是校长，我会发给这个认为自己的学生值800块的老师400块的工资，但是我不是给他4张纸币，我会换成400个1元的硬币，然后一个个往他脑袋上砸，直到他清醒过来，或者被硬币埋葬。因为他摧残了一批学生。
      今天的面试，我给每个人的时间，不会超过5分钟。
      有一个人我只和他谈了3分钟，留下他的简历，他后面的同学用一种没有希望的眼神看着他，说：“这么快？”
      我说：“你会更快。如果你不假思索的用两句话描述你的优点，我就招你，1分钟”。可惜他断断续续，说了一大堆——显然他心理的“谱”，是他彩排好的自我介绍，我“打乱”了他的部署。
     有一个学生，本来我觉得不错，她只用一页的简历，就表达了她的优势和特点，当我决定招她的时候，习惯的问下学期还有没课并看简历，却看不到她的学校名字，“为什么没写学校名？”，“因为……我的学校不怎么样……”。我还是问了她的学校，然后拿起笔，在她的简历中帮她写下她的母校，然后在她眼前竖起简历：“有没写错？”
“没有。”
      我今天对所有留下的简历，只是做一个动作（在认为特别适合的，打钩）。这是我唯一写字的简历，我不知道她明不明白，我是在告诉她什么。她的做法让我大打折扣。
      如果我是负责教育的，我有一把足够大的铁锤，我会抡起来把所有的中国学校都砸掉，因为现在不会有一个学校敢站出来说：我们学校是“教做人的”——全部都是“教书”的。
     当然，也有些学生非常善于销售自我，比如，有个应聘网页设计的学生，因为他做的东西都是在学校的内部网，没法把作品展现给我看，他和我说：“我把作品放到一个叫职友集（www.jobui.com）上，你可以看。”还有一个应聘文案助理的，也是将她的文章传到自己的BLOG上。晚上我回去打开他们的主页，觉得他们放在网上的内容很充实，比如应聘文案助理的学生，上面有很多她的随笔作品，我看到她不错的写作思路和思维水平，我决定明天通知这两个人上班。他们都是来自那些被人看成“差学校”的学生，但是，他们善于利用多种途径，来表达他们的优势。比如善于利用“职友集”、BLOG这种新的免费工具，的确成为他们赢得我的信任的关键。   
     总结今天的感受，我认为：未毕业，先失业，不是因为没有工作机会提供，而是就业能力结构失衡；就业难的关键，也不是因为毕业生多，教育水平下降，而是自我认知的能力模糊，就业信心和自我价值期望的下降。天之骄子的高傲姿态消失，是好事，但取而代之的不是平衡心、平常心，而是一种自卑、浮躁和茫然。
     你可以认为我摆谱、摆资格，但是，作为毕业生，我相信你还是愿意听听一个5年人力资源总监、有过1万人次面试经历的人力资源工作者，对你的如下“不满”：
 
     不要递给我花里胡俏的简历，给我一点简洁（不是简单）而能突出你自己的表达——面对成千上万的求职者，你真的以为HR会去看你那封100个人有99个差不多的求职信、和装订得像书本一样的简历模板内容吗？
      不要对我说太多的自我介绍，我不敢说3、5分钟我就准确判断了你，但是30秒之内我就定格了你的第一印象；我之所以很快结束你的面试，是因为你的后面排队的人真是太多，我也曾经作为毕业生这样苦苦的等待，我只是为了给更多的人一个和你一样平等的机会，而后我会挑选请你到我办公室复试；你认为我给你的时间太少，而流露出失望（自己是不是没被看中了？）眼神的那一刹那，你就丢失了再次获得复试的机会。我永远坚持：你的信心就是我的希望。你的岗位机会不是我给你的，而是你自己争取的。
     不要一副“只要你招我我什么都肯做”的姿态，这样给我一种“卖身”的感觉，我请你是因为你会为公司创造价值，所以不是你“求”职，而是我“请”你。这不是叫你抬到姿态，而只是希望你抬起胸膛。
     不要对我拒绝收你的简历，报以晦气的脸色或失望的情绪。我不接收你的简历，不是你不行，而是不适合我的公司；我不接收你的简历，不是不给你机会；而是不想给你根本不存在的期待（如果我收了，你会等待着我通知你）；不是我不给你面子，而是我不想浪费你和你父母的血汗钱——尽管每一份简历只有1、2元，但是我没有任何理由，去浪费属于你的1分1厘，何况你还是一个纯消费者；我是在帮你节约，让你能够将它投给属于你的机会。我从不想当我拿不了那么多简历回公司的时候，把你的希望孤伶伶的留在招聘场地里；我更不希望，当招聘会结束以后，你的简历会在冷清的场地，像其它被丢下的简历一样，雪花般漫天飞舞，任人践踏——我决不加入这样的行列，而宁可以拒收给你打击（你也必须开始懂得直面这样的打击），因为你熬了多少个夜晚做出来的那个简历，代表的就是你，上面写着你的价值，和你的尊严。我始终认为，任何人都可以狠狠的批判教育制度，但是绝对不可以否定你的价值，更不可以践踏你的尊严！
     不要不敢说出和写下你毕业的学校，无论她是如何的差，你是从那里走出来的，因为我绝对不会要这样的人：看到他父母的时候，因为他们的背景不好而不敢认他们；或者有一天离开我的公司，去到一个更大的公司面试的时候，不好意思说我是来自一个不是500强的公司。对公司来说，你的价值和价值观，决定了一切。英雄莫问出处，如果你是一个狗熊，哪怕你从天堂走出来，也还是狗熊。
     不要给我罗列一大堆你的学习成绩和从事的所谓实习（因为很多毕业生也曾经到我这里来兜一圈，参观一下，盖个章名曰“实习”），你只需要挑选一件特别的事情，要点式地说明过程和结果，让我知道你是怎样做事的。
     不要不敢用眼睛看着我，你不敢瞧我的时候我也瞧不起你。
     不要在回答“你的薪酬要求”的时候，多了那么多废话。我不想听每个人都重复着“因为我是毕业生，没有社会经验，所以如果公司觉得这个要求太……我也可以……”，我的钱也许也是刚刚从人民银行印出来的，但是它们不会因为还没有被流通转手，而减损它的价值。其实我不在乎你说的是5000，还是1500，我在乎的是你说出一个数字的那种语气、眼神。我尊重每个人都有自估劳动力价值的权利（但公司自有它的薪酬制度，不会特殊对待你），但我喜欢干脆利落的同事，干脆利落是一种自信，是一种做事风格，也是一种做人态度。我会固执的认为：你说出这个数字前后带了多少个字符，就表示你做事有多拖泥带水；或者你的自我认识和自信是多么摇摆不定。
     人生简短，价值无限，告诉人家你是独一无二的，你就是你，你成就你。

什么是.NET？
    .NET是一个开发平台，它定义了一种公用语言子集（Common Language Subset, CLS），这是一种为符合其规范的语言与类库之间提供无缝集成的混合语。.NET统一了编程类库，提供了对下一代网络通信标准，可扩展标记语言（XML）的完全支持，是应用程序的开发变得更容易、更简单。Microsoft .NET计划实现手写和语音识别的功能，增加对各种用户终端的支持能力。.NET与Windows平台紧密集成，从广义上可以称其为一个运行库。简而言之，.NET是一种面向网络、支持各种用户终端的开发平台环境。


.NET的核心组件
1。一组用于创建互联网操作系统的构件块，其中包括Passport.NET（用于用户认证）以及用于文件存储的服务、用户首选项管理、日历管理以及众多的其他任务。
2。构建和管理新一代服务的基本结构和工具，包括Visual Studio.NET、.NET企业服务器、.NET Framework和Windows.NET。
3。能够启用新型智能互联网设备的.NET设备软件。
4。.NET用户体验。


Framework——框架，是开发人员对编程语言命令全集的称呼。.NET框架的意义就在于只用统一的命令集支持任何的编程语言。.NET框架是.NET平台的基础架构，其强大功能来自于公共语言运行时（Common Language Runtime, CLR）环境和类库。CLR和类库（包括Windows Forms, ADO.NET和 ASP.NET）紧密结合在一起，提供了不同系统之间交叉与综合的解决方案和服务。.NET框架创造了一个完全可操控的、完全的和特性丰富的应用执行环境。


C#概述：它将快速的应用开发和对底层平台所有功能的访问紧密结合；它与 Web标准完全同步，并且与现存应用方便地集成；它允许程序员在需要时使用底层代码。


C#特点：
1。简洁的语法，特别是相对于C++来说。
2。精心地面向对象设计。装箱（boxing）/拆箱（unboxing）；单继承；.NET虚拟对象系统（Virtual Object System, VOS）。
3。与Web紧密结合。SOAP；Web服务框架；直接将XML数据映射成结构。
4。完全的安全性与错误性处理。.NET运行库提供了代码访问安全性，它允许管理员和用户根据代码的ID来配置安全等级。.NET平台提供的垃圾收集器（Garbage Collection, GC）将负责资源的释放与对象撤消时的内存清理工作。
5。版本处理技术。
6。灵活性和兼容性。delegates；通过接口继承实现多继承；公共语言规范（Common Language Specification, CLS）；元数据（Metadata）。


.NET包括四个组成部分：
1。VOS类型系统。其支持了.NET的跨语言集成特性。对于过程性语言，它描述了值的类型并指定了类型的所有值必须遵守的规则；在面向对象的语言方面，它统一了不同编程语言的对象模型。每一个对象在VOS中都被唯一标识以与其他对象相区别。
2。元数据。其是对VOS中类型的描述。在编译程序将源代码转换成中间代码时，它自动生成，并与编译后的源代码共同包在二进制代码中。程序使用的类型描述与其自身绑定在一起。在CLR定位与装载类型时，系统通过读取并解析元数据来获得应用程序中的类型信息，JIT编译器获得加载的类型信息后，将中间语言代码翻译成为本地代码，在此基础上根据程序或用户要求建立类型的实例。以上保证了类型的安全性。
3。公用语言规范（Common Language Specification）。如果一个类库遵守CLS，那么同样遵守CLS规范的其它编程语言将能够使用它的外部可见项。
4。虚拟执行系统（Virtual Execution System, VES）。它是VOS的实现，它用来驱动运行环境。元数据的生成与使用、公共语言规范的满足性检查以及应用程序执行过程中的内存管理均由它来完成。具体功能：装入中间代码；使用JIT将中间代码转换为本地代码；装入元数据；代码管理服务——包括垃圾收集器和异常处理；定制与调试服务；线程和环境管理。

模式定义元素和属性，就像DTD所做的那样。将一个类型与元素或属性相联系则可定义内容。类型可以是XML Schema规范中内置的，如整数，也可以是自己构造的，如telephoneNumber或properNoun。


一个例子：
说明：该文档的主元素是schema元素。title被赋予一个xsd：string类型。Body元素将其mixed属性置为true，意味Body元素具有混合内容：文本和元素；其只有一种元素ingredient，最少0个，最多无穷。


DTD中element元素定义：
元素的内容可以是简单的也可以是复杂的。复杂的类型包含其他元素，简单类型则不然。如果类型是预置的，那么对元素element使用属性type。如果它是自己在别处定义过的一个类型，那么可以用同样方式引用它。否则，可以为该元素立即定义一个类型，使用simpleType；如果它可能包含子元素，则使用complexType。Unique、key和keyref类似于数据库里的作用。如元素的内容必须是唯一的，即元素的值用做检索的索引关键字，或该值必须出现在另一个定义为关键字的元素中。

自定义类型示例：电话号码类型（telephoneNumber）

 

内容原型：
1。字母和数字，例<xsd:pattern value="hello" />，该元素的内容必须是hello。
2。a|b|c，恰好匹配a、b或c之一；a、b、c可以用任何原型替代。
3。(a)，与a相同，可以使用括号分组。
4。句号（.），匹配所有除新行符（\n）或回车符（\r）以外的任何单个字符。如b.y匹配boy等。
5。a？，匹配a或什么也不匹配。原型wine?d匹配wind和wined。原型(dis)?comfort匹配comfort 或discomfort。
6。a*，匹配0个或多个a。
7。a+，匹配1个或多个a。
8。a{2，5}，匹配2-5个a。也可以是a{2，}，匹配两个或以上的a；a{5}，匹配5个a。
9。[w-z]，匹配单个字符w、x、y或z；[0-9]，匹配一个一位数。
10。[^aeiouy0-9]，匹配除与[aeiouy0-9]匹配以外的任何串。
11。\r,\n,\t，字符序列分别匹配回车符（&#13;）、新行符（&#10;）和跳格符（&#8;）。


当想在XML中创建从一个文档到另一个文档的超文本链接有两种方法：
1。调用XHTML名域并使用HTML链接。例如，
    <html xmlns:h="http://www.w3.org/TR/xhtml">
      <h:a href="ok.html">this works.</h:a>
    </html>
2。XML Linking Language(XLink)。例如，
    <p xmlns:xlink="http://www.w3.org/1999/xlink">
      <a xlink:type="simple" xlink:href="ok.xml">this works, too.</a>
    </p>


XLink特点：
1。与不止两个端点链接。可以使用XLink创建连接不止两点的链接。
2。多向链接。对HTML，链接有一个锚和一个目标，文档中一般不存在指向当前web页面的任何迹象。你可    以使用XLink创建双向链接。
3。可以使用外部链接集文档。
4。注解链接。

三类模式：
1。W3C XML-Schema规范，其分为三部分：
    a) XML Schema Part 0: Primer(www.w3.org/TR/xmlschema-0);
    b) XML Schema Part 1: Structures(www.w3.org/TR/xmlschema-1)，它定义XML模式的基本语法;
    c) XML Schema Part 2: Datatypes(www.w3.org/TR/xmlschema-1)，它定义指出元素和属性数据类型的工具。
2。Microsoft XML模式，称为XML Data Reduced (XDR)，可使用工具将其转换为W3C XML。
3。RELAX模式（XML的正规语言描述），日本国家标准。


XSD(XML Structure Definitions, XML结构定义)

XML模式（Infoset）：通过提供对结构和内容的约束，XML模式定义一类XML文档。使用模式指出文档中允许哪些元素、它们可能有哪些元素、它们可能包含什么。XML模式类似于DTD，但它还能指定元素的文本内容。


XML模式对XML实体一无所知。不能在XML模式中说明实体，不能指定在哪里使用实体。


DTD指出元素的有效性，而XML模式则指出元素、XML名域和类型化数据（如整数、日期和串）的有效性。
    1。文本内容。XML模式可以指定任何环境中允许哪些文本，而不只是DTD中的是否允许文本（#PCDATA）。
    2。类型化数据。除了指出必须出现文本内容外，还可规定它必须符合某种类型，如整数、日期或大写字母序列。这对用XML使用关系数据库的应用特别重要。
    3。文本原型。可以使用数据必须匹配的原型（严格地说，Perl类正规表达式）。例如，加拿大邮政编码必须包含用空格分隔的两个字母数字组（M6E 3J5）。
    4。复杂的内容模型。
    5。导出类型。
    6。文档资料。XML模式可以在documentation元素中存放关于个别元素的文档资料或作者姓名之类元数据的标准地址。
    7。名域。XML模式更好地支持混合多个名域的元素或使用缺省名域。


一个DTD和一个对应的模式（菜谱）。
DTD:
<!ELEMENT recipe (title,body)>
<!ATTLIST recipe page #CDATA #REQUIRED>
<!ELEMENT title (#PCDATA|indexItem)*>
<!-- * An indexItem appears at least once in every title * -->
<!ELEMENT indexItem (#PCDATA)*>
<!ELEMENT body (#PCDATA)*>

模式：
<element name="recipe">
    <complexType content="elementOnly">
        <element ref="title" />
        <element ref="body" />
        <attribute
            name="page"
            type="integer"
            use="required"
        />
    </complexType>
</element>
<element name="title">
    <type content="mixed">
        <annotation>
            <documentation>
            The recipe title always contains at least one indexItem; They are printed in Caps/small-caps in the 1782 edition of  the book.
            </documentation>
        </annotation>
    </type>
</element>
<element name="indexItem" type="string" />
<element name="body" type="string" />


连接模式与XML文档：可使用在W3C发布的一个名域中定义的两个属性之一。
1。<recipe
        xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
        xsi:schemaLocation="recipe.schema"
      >
      ......
      </recipe>
2。<recipe
        xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
        xsi:nonamespaceschemaLocation="recipe.schema"
      >
      ......
      </recipe>
地址可以多个，用空格分开即可。


XML名域是一种“限定”一组元素和属性的方法。它是在一个文档中混合来自多个DTD的元素或多组名字并声明哪些元素和属性来自哪组名字的一条途径。使用名域说明将一个URI引用与一个或多个XML元素联系在一起，作为一个前缀将它们相互区分开。如果两个元素同名但URI前缀不同，那么它们是不同元素。

XML名域的3个主要用途：混合词汇、混合文档片段及确定保留名。

各领域的参照DTD：
1。MIL38784B（CALS）  军事规范：技术文档。
2。ATA Spec 2100  航空器构架/引擎文档（Airframe/Engine Documentation）。
3。SAE J2008  交通服务信息（Vehicle Service Information）文档规范；有些也用于其他服务信息。
4。HL7  保健7级（Health Level7）；医疗界用于计划和诊断。
5。SIF  学校交互操作框架（Schools Interoperability Framework）；在K-12学校软件互操作环境中定义交换对象。基于SPEED/Express数据结构。
6。TCIF  电信行业论坛（Telecommunications Industry Forum）标准；定义构成数据表的主要结构。
7。TEI  文本编码倡议（Text Encoding Initiative）是文档的面向书籍的结构，具有支持软件文档的其他特征。
8。DocBook  软件文档规范；有些也用于硬件。
9。ISO 12083  电子文稿标准（Electronic Manuscript Standard）；用于期刊、文章、丛书和书籍。


数据建模，或称文档分析、数据分析：观察现有的数据，了解数据各部分之间的关系，建立这些关系的模型或图形表示。
    1。使用结构图。可以使用一个XML DTD或更新的XML模式来描述XML设计。前者是利用XML从SGML继承下来的语法规则创建；后者的意图是描述DTD包含的同一信息，但使用XML本身的语法。使用结构图表达数据的创建和数据流时，要采用一种清晰的语法来表示以后将转换为最终XML设计的结构和关系。例如，必须有办法表示一个元素由子元素构成，也必须能表达元素可能出现多少次及其元素或子元素可有可无还是必不可少。元素、子元素及其关系图有时称为内容模型。以图形方式创建和分析内容模型或结构图的流行工具是XML Authority。
    2。使用参照DTD、模式和词汇。当着手自己的数据设计时，一开始要考察现有数据模型来判断你希望在XML中标注的数据类型是否已经存在一个好的基础，或参照模型。从一个参照DTD或行业模式着手可以利用别人完成的设计、开发、测试和文档资料。需要依据文档样本和功能要求，删减和新增元素。XML词汇是一个XML标注集，因为良构XML不要求完备的DTD或模式，所以XML词汇也许不过是一组标注定义罢了。可以将设计中的标注名建立在该定义基础上。
    3。模拟现有数据库。Oracle 8i和Microsoft SQL Server 2000都有允许有经验的数据库管理员将现有数据库中的表、记录和域结构转换成良构XML的例行程序。如SQL Server中的“select * from tableName for XML auto”。


基于内容的模型和基于结构的模型。例如，假设要为由以下章节构成的服务手册建立模型：
    引言    操作    电子部件    机械部件    液压部件    故障诊断    线路图
1。按内容的模型 
    <!ELEMENT serviceManual (introduction,operation,electricParts,mechanicalParts,hydraulicParts,troubleshooting,wiring)>
2。按结构的模型 
    <!ELEMENT serviceManual (section+)>


刚性模型与柔性模型
1。<!ELEMENT serviceManual (introduction?,operation?,electricParts?,mechanicalParts?,hydraulicParts?,troubleshooting?,wiring?)>
2。<!ELEMENT serviceManual (Introduction,(operation|electricParts|mechanicalParts|hydraulicparts|troubleshooting|wiring)*)>


DTD高级结构模型例子：HTML，ISO 12083文章，SAE J2008
<!ELEMENT HTML (Head,Body)>
<!ELEMENT Article (front,body,appmat?,back?)>
<!ELEMENT J2008 (ListofSIEs,ServInfoPool?,OEMInfo?,Paths?)>


XML控制内容的原因：
1。强加一组指导原则以帮助人们创建文档。
2。消除出乎意料的因素以简化文档的后续处理。当以可预测的方式构造信息时，软件可能更简单，因此更可靠、更便宜。