必须在IIS中启用32位应该程序才可以正常使用

无论是哪种开发模式，软件的开发过程都可以归结为：人、工具和过程这三个因素，三者的有机结合才能更高效的完成任务。有人会说：《敏捷宣言》四条主旨精神的第一条就是“个体和交互重于过程和工具”，工具还有那么重要吗？回答是肯定的，工具很重要，这条主旨所提到的是“重于”而不是不要。为了支持敏捷开发，Visual Studio 2010（以下简称为VS 2010）应用程序生命周期管理中引入了MSF for Agile Software Development v5.0过程模板，用于辅助敏捷团队在实际工程中进行敏捷实践，它支持Scrum敏捷开发过程框架。本文将从工具角度出发， 介绍Visual Studio 2010如何帮助测试人员更胜任敏捷项目中的测试工作。对于工具与人的关系而言，好的工具应该是将人从重复和机械的劳动中解脱出来，让人有更多的精力和时间花在有创造性地劳动上，而由工具去完成将繁琐和冗余的事务性操作；而对于工具和过程的关系，工具是过程能够得到确实落实和准确执行的基石，很多时候我们总是依赖于人去执行某个过程或者流程要求，但人的执行往往带有一定不稳定性和主观性，而工具则可以帮助我们准确客观的执行。

团队有效协作的基石——Team Foundation Server

敏捷开发强调人与人之间的有效沟通和紧密的团队协作。对于测试团队和测试人员而言，首先应该需要考虑的是：如何让测试工作更有效的集成整个敏捷开发的活动中去？而不是将测试工作仅作为一个“附件”或者可有可无的副产品。当然，这会受到团队组织形式和开发过程的限制，例如：采用功能小组模型的团队，所有角色成员（PM、开发人员、测试人员）隶属于同一个功能团队，客观上其沟通就更为方便；而对于采用纵向按职能划分团队的公司而言，测试和开发在隶属关系上是分开的，相对在沟通上障碍就会更多些。无论是哪种组织形式，好的工具能帮助促进和统一各个角色间的信息互通和共享，而不是要让他们彼此之间更为孤立、工作在各自的一亩三分地（Silo）中。Team Foundation Server 2010（以下简称为TFS 2010）就是这样的工具，作为整个团队协作的核心，它统一了团队不同角色信息、实现了信息之间的有效互联互通、彼此之间的共享和关联，例如：TFS 2010定义6种默认的工作项类型，如下图所示。

图1：TFS 2010定义6种默认的工作项类型

其中，Test Case和 Shared Steps是2010专门为测试新加入的。不要小看这些工作项，它们之间有着丰富的关联关系，这种关系背后所代表是角色之间的关系。对于测试而言，它将测试和团队紧密的结合在一起。例如：Test Case工作项用来详细定义和管理测试用例，它还可以和User Story相关联，也就是将测试和用户需求进行了关联，用户可以从需求追溯到覆盖的它的测试用例，这背后体现的是测试人员和需求人员/PM的协作；Test Case还可以与Bug关联，通过这种关联可以挖掘出哪些 Bug被测试用例覆盖，哪些还没有，这种关联体现了测试人员与开发人员的写作，如果是自动化测试用例，则体现了手工测试人员和自动化工程师的协作；Bug还可以可以和签入集（Change-set）关联，可以找到为了修复Bug，开发人员修改过哪些产品代码，这体现了测试人员和开发的关联。

敏捷开发频繁的迭代和较短的迭代周期，对项目管理的精确性、透明性和可见性都提出了更高的要求， 尤其对于那些项目复杂和人员较多的团队。Task是另一个重要的工作项类型，它用于管理开发过过程中的所有任务项，包括：开发、测试以及需求等任务，统一管理开发中的所有任务，统一计算项目的开销和剩余工作量等。例如，项目的燃尽图就是由它产生出来的。现在，人们虽然在理论和概念上已经非常认同软件测试的在工程中的重要地位，但在具体实际操作中，测试却仍然被看作是低于开发和需求分析等的“二等公民”。当然这是由于多方面的综合因素造成的，从管理技术角度讲，这是由于测试工作本身缺乏可度量性和可见性，从导致了测试工作的透明性的缺失，团队往往看不到测试工作的进度和所带来的成果，从而意识不到测试的真正作用。对于测试人员自身而言，缺乏可度量性也让自己无法对工作进度准确把握，进而失去了对自己工作的目标感和认同感。将测试工作同其他工作一样的用Task工作项管理起来，增加了它的可度量性和可见性。将测试工作和其它任务一起统筹，时刻确保测试被作为整体中的一部分进行考虑，所有的测试任务都被作为Task工作项记录下来，例如：编写测试计划、设计测试用例、自动化测试用例等等，每项任务都有三个默认时间估计数据需要填写，它们是：Original Estimate、Remaining和Completed，分别代表了任务的预估时间、剩余工作量和完成工作量。

为了增强敏捷过程的透明性和可见性，TFS 2010定义了很多的报表和仪表板（Dashboard），它们会自动生成各种报表，以可见的方式描述敏捷项目的健康状况，这其中就有很多反映测试工作的报表，如下面所示。Stories Overview展示了用户故事的进展情况，包括了每个用户故事的测试用例覆盖数量和执行结果，以及相应的Bug数量；Test Dashboard显示了测试用例的状态，包括正在设计的用例以及设计完毕可以执行的用例数量，现实当前Bug的状况，包括未被修复和以修复Bug的数量。

图2：Stories Overview展示了用户故事的进展情况

图3：Test Dashboard显示了测试用例的状态

集成测试环境——Microsoft Test Manager

在过去的十几年中，为了适应了软件项目的复杂度和规模的不断膨胀，软件开发工具和框架得到了长足的发展，而测试工具则始终是块短板 ，特别是对于那些需要手工完成的测试任务而言，进展就更为缓慢，例如：现在很多团队仍然使用Word或者Excel这样“原始”工具来管理测试用例。通过对业界的调查和分析，我们发现70%的软件测试工作仍然是通过手工或者简单的脚本来完成的，在测试团队中不具备编程能力和仅有基本脚本编写能力的测试人员仍然是测试的主力。

要让你的项目敏捷起来，对于那些仍以手工测试为主的团队而言是一个非常大的挑战，如何提高手工测试工作的效率将是实现敏捷的成败关键。在VS 2010中，微软首次为测试人员设计了一款专用的集成测试环境，称为微软测试管理器2010（Microsoft Test Manager 2010，以下简称为MTM）。之所以称之为集成测试环境，是因为MTM的功能涵盖了测试计划、测试用例、手动测试用例的执行和录制回放、自动测试用例执行、创建信息丰富的Bug、验证Bug、以及与测试实验室管理相关的对策是自动化相关的功能等。下图展示的是MTM测试计划的操作界面，它以树形的层次结构来组织测试用例。

图4：MTM测试计划的操作界面

《敏捷序言》强调：“可工作的软件重于完备的文档”，那么是不是意味着敏捷测试也不需要测试计划呢？当然不是。敏捷的本质是要去除软件过程所有造成时间浪费地方，不需要的是那些动辄就几十或上百页的文档。敏捷对文档要求是要简明扼要，一两页列出测试要点计划还是必须的，较短迭代周期（1-4周）也不可能要求文档面面俱到。敏捷需要更快的对功能进行验证，是不是不需要编写测试用例直接根据用户故事或者功能需求进行探索性测试就可以了？当然也不是。功能需求和用户故事勾画出的是一棵大树躯干和主要枝杈，而那测试用例则不但要准确描述出躯干和主枝，还要描述出细小的枝杈和绿叶的正确位置。从某种意义上讲，测试用例在敏捷中的作用和地位应该更为加强，它扮演着详细功能文档的角色。功能需求和设计文档可以简单，但测试用例可不是这样，相反我认为敏捷对测试用例的设计和管理要求更高。

每个迭代周期，团队都会专注于实现不同的产品功能，用户故事虽然描述了功能的内容，但并不足以覆盖所有相关的内容。很多由用户故事展开和关联的功能一般在文档中会体现出来，需要测试人员在早期围绕着用户故事测试展开需求文档测试（需求评审），已明确那些未严格定义出来的内容，以测试用例的形式明确和记录下来。由1个简单用户故事就有可能扩展为1+N用户可能执行的执行片段，也就我们测试用例。当你有M个用故事，需要Ｍ个迭代周期来完成产品，那么就会有 ( M + N₁ + N_{2 …} + N_M) 个测试用例，不把它们落实到笔头上，很容易就会丢失一些重要的测试细节。此外，在敏捷方法中需求变化比较快，随着多个迭代的深入，文档的变化往往赶不上产品功能的变化，这时唯一能够赶上这个变化的只有测试用例，应为只有它准确地反映了产品的变化，否则测试用例就是无法通过的。

图5：测试用例

在MTM 中，测试用例被分类至各个测试用例集，结构十分清晰。测试用例只是逻辑上从属于某个测试用例集，并没有物理从属关系，即一个测试用例可以同时被分在多个测试用例集内，比如某个测试用例性质上是一个性能测试，但是由于该用户故事的诉求就是性能改进，我们也就很自然得可以将其作为该用户故事的验收测试，此时我们就可以将此测试用例添加到验收测试和性能测试两个测试用例集中；另一个例子是给每个用户故事都定义了不少测试，这些测试用例都应该能在用户故事测试用例集下找到，但是这些测试既可能是手动测试也可能是自动化测试用例，所以它们又会被本别归类至这两个测试用例集。在这种逻辑分类的支持下，我们可以很容易的根据需要指定运行测试集中一部分测试用例。比如，我们可以定义一个签入测试的测试用例集，挑选最基本的若干个测试置入其中，这样在每次签入前通过运行这个测试用例集就能帮助我们确保签入的代码不至于破坏最基本的功能，即保证了版本随时可运行可测试，这无疑为测试带来了更多的方便。具体如何创建测试用例集的结构，团队可以根据自己项目的特点，灵活运用此功能，制定分类规则以提高工作的效率。

很多测试团队仍然在使用Word或者是Excel管理测试用例，有些是使用专门的测试用例管理工具，使用独立的数据库来存储测试用例信息。MTM相对于这些工具的优点在于，它的所有数据都是存储在TFS上，测试用例使用的是Test Case工作项。由于同存储在TFS 上，所以可以轻松的实现与其它数据项的关联，例如：在上一部分我们介绍的不同类型工作项之间关联，此外还可以把Test Case与代码关联，即将测试用例与自动化测试代码关联。这样在MTM中，也可以直接管理和运行自动化测试用例，使MTM兼具了管理手工测试用例和自动化测试用例的能力。

探索性测试（Exploratory Testing）是测试人员在对被测试系统的功能进行不断了解和学习的过程中进行测试，包括：设计测试用例、执行测试、以及汇报测试结果。与传统的测试相比，它不需要事先定义好的齐备的测试文档，更强调测试人员在对系统不断地学习中，边了解边测试，它在很大程度上给测试人员更多地自由和想象空间，充分发挥他们的创造力，在不断地学习中找到测试的灵感和快乐。这种测试的灵感和快乐对于组建和培养一支热爱测试的团队是非常非常重要，它会让测试人员觉得自己不是执行重复测试劳动机器，而是一个有着创造力和灵光的团队成员。MTM也支持探索测试功能，用户可以使用MTM创建一个仅有一个测试步骤的测试用例，然后执行它，Test Runner工具会辅助执行手动测试。它会记录下所有用户的操作，一旦发现有Bug时候，可以直接选择‘Create exploratory bug’直接创建一个Bug。

图6：创建一个Bug

Bug是测试工作最重要的产出之一，也是测试和开发人员之间重要接触点。每个提交的Bug都应该详细记录下如何重现（reproduce）的步骤，这是衡量Bug质量的重要因素之一。因为不可重现的Bug是没有意义的，只会耽误开发人员和项目经理的时间。偶尔出现不可重现的Bug还是可以理解的，但如果经常出现，那就会引来开发人员的抱怨和不满，久而久之会造成开发和测试之间的不信任。 好的Bug应该是有清晰和详细的重现步骤，期望的结果和实际得到结果，并提供尽可能多的信息，例如：出现问题的产品版本编号、语言、操作系统的版本以及日志信息等。大多数情况下，用文字进行描述的内容就可以了，但如果能配上一张问题现场截图，或者对于更为复杂的Bug，配上一段小的录像，这样的Bug会给开发人员快速诊断和修复产品问题带来很大帮助，大大提升测试和开发人员之间的协作效率，避免了不可重现Bug在开发和测试之间推来推去的“Bug乒乓”现象。然而要收工创建这样一个信息丰富的Bug，是需要很多时间的。MTM提供了这样的功能为帮助测试人员创建这样高质量Bug，它实现了多种诊断数据适配器（Diagnostic Data Adapters），在测试确认Bug的过程中，这些适配器会在后台运行收集大量的数据，包括：执行操作、系统配置、IntelliTrace已经操作过程的录像等，当测试人员要创建一个Bug时，这些信息会被自动添加的Bug中，如下图所示，测试仅需填写很少的内容就可以创建好一个信息丰富的Bug。

图7：信息丰富的Bug

实现自动化测试用例——自动化测试用例框架

随着需求的不断变化和迭代的深入，代码库不可避免的会有频繁的签入和签出，此时测试人员一项很重要的任务就是要预防回归问题发生。执行手工测试用例可以帮助我们预防及和发现回归问题，但是它的执行效率太低，无法胜任频繁执行的要求。这时就我们需要考虑采用自动化测试用例完成这项工作。决定是否采用自动化测试是有很多因素决定，其中很重要的一条就是自动测试的收益，下面的公式从概念上解释了如何来计算这个收益，当收益值大于1的时候，实施自动化测试就是合算的；否则，就是不合算的。

图1：计算收益公式

这其中，开发和维护自动测试的成本是影响这个收益的重要因素，为此VS 2010提供了一整套的解决方案，帮助测试团队减少这部分成本，这包括前面我们所提到的测试计划和用力管理工具，以及后面将会要介绍的生成和实验室管理。此外，Visual Studio 提供了多种测试工程模板，帮助测试人员开发自动化的测试用例，如下图所示。

图2：Visual Studio提供的多种测试模板

这些测试工程模板可以帮助测试自动化工程师，在Visual Studio 集成开发环境中创建和管理单元测试、功能测试、Web性能测试、负载测试等等一系列的自动化测试用例。这其中，编码的UI测试（Coded UI Test，以下简称为CUIT）是首次出现，是VS 2010测试部分一大亮点。测试人员可以通过它使用C#或者 VB.NET语言编写自动化测试用例，从用户界面层驱动Web、Winform或者是WPF的应用。CUIT为测试用例的自动化提供了一个框架、API和可扩展的接口，测试人员可以很轻松地开发出所要的自动化测试用例。其实CUIT背后的测试自动化实现技术对大家并不陌生，下面列出针对Web、WinForm和WPF应用的测试技术基础。对每种技术的支持采用的是插件的形式实现的，VS 2010包括了如下的三种插件：

• Document Object Model（DOM）插件 : IE 7/8 HTML/AJAX
• User Interface Automation（UIA）插件 : WPF
• Microsoft Active Accessibility（MSAA）插件 : Winform，Win32和MFC 。MSAA插件是默认选项，用来支持出其它两者之外的任何应用。

CUIT 现在支持主要的微软平台，详细的内容可以参见MSDN : Supported Configuration and Platforms for Coded UI Tests and Action Recordings。对于那些尚不支持的平台或者UI控件，CUIT提供了很好的扩展机制，允许大家针对自己的特殊应用进行扩充，下图就是CUIT框架的体系结构图 。

图3：CUIT框架的体系结构

开发自动化测试用例对于有效预防回归问题的出现时非常必要，在实际应用中应该特别注意它的合理比例关系和灵活的策略，包括：自动化用例和手工用例的比例、UI和非UI测试用例的比例关系。自动化测试用例、执行、分析和维护它们都是需要一定投入的，对于敏捷项目而言时间资源的紧缺尤为突出，所以在任何时候团队都要根据自身的资源，有选择性进行测试用例的自动化，通常情况下应该优先自动化那些高优先级的测试用例。

对于UI和非UI的自动化测试用例而言，应该是以非UI 的单元测试和功能测试为主，UI测试未必要的补充。基于UI自动化测试用例有它独特优点，例如：它从真实用户角度出发进行测试，即涵盖了界面层、逻辑层和数据层，自动化人员不需要了解被测试应用的代码实现细节等；但是相对于非UI测试它也有着先天的不足，包括：执行速度相对比较慢、易受干扰不稳定等。所以在自动化过程中，能用非UI测试覆盖的功能尽可能采用非UI的测试覆盖，如：API单元测试等，UI测试用例只用来实现最基本用户故事的验收测试（Acceptance Test）。

早测试和经常测试——封闭签入和滚动生成

敏捷开发中最可怕的事情莫过于在迭代最后一两天进行测试，结果发现了严重功能缺陷或者回归缺陷，导致不能按计划发布给用户试用。要想彻底解决这样的问题，一方面要在迭代开发阶段测试人员就要参与进来，从客户的角度出发对功能需求和设计文档进行文档测试，即文档评审。测试人员和开发还有项目经理一起从源头上保障将要实现的功能是用户想要的。另一方面就是要在迭代的早期就开始就开始测试，特别前几个迭代已经实现好的自动化测试用例，尽早的执行它们可以有效地避免回归问题的出现。在TFS 2010上专门提供封闭签入（Gated Check-in）、滚动生成（Rolling Builds）和持续集成（Continuous Integration）等功能，帮助敏捷团队实现早测试和经常测试。这其中封闭签入和滚动生成是对敏捷团队比较实用的功能。

图4：选择签入方式

封闭签入是TFS 2010提供的一种新的代码签入方式，在配置这项功能后，当用户要签入任何代码时，系统会先将用户本地要签入的代码打包成一个搁置集（shelve-set），然后提交到服务器端，TFS生成（Build）服务先从TFS源代码控制器中同步项目的最新代码，再将提交的代码与之进行自动合并，然后进行编译，如果编译成功，则执行配置的自动化测试用例，如果测试用例全部通过则代码会被自动签入到代码库中，否则返回错误信息给用户，代码是不会进入到代码库。表面上看是与产品测试没有直接关系，但实际上它和测试以及最终产品质量的密不可分。因为代码签入是整个开发过程中发生最为频繁的操作，每次签入代码的质量直接影响着日常的开发活动。对于绝大多数的开发团队来说，check in代码前不仅要保证编译通过，同时还要最大限度的保证新代码不会破坏已有的功能，也就是要执行测试用例去验证。Gated Check-in中提到的“Build成功”，实际上包含两部分内容：编译成功和测试用例执行成功，有了它作为保护代码库的第一道屏障，就可以保证它在任何适合都是可编译，并且达到一定质量标准的。

滚动生成是在VS 2008种就有的功能，当TFS检测到在它所监控的范围内有任何新的代码变化被签入后，它就启动对最新的代码库进行生成验证，该验证包括编译和运行指定的自动化测试用例。之所以称之为“滚动”，因为它是在一个生成验证操作完成后再去探测有没有新的签入发生，对这期间发生的所有新签入进行新的生成验证。这里需要再强调一下滚动生成的重要意义：它看似只是一个自动生成代码的功能，但实际上起着协调整个开发团队、时刻监控代码库质量、以及尽早暴露产品问题的作用。因为滚动生成时刻都在不停的运转着，对于任何代码签入它都保持着警觉，会去自动验证编译是否成功，自动化测试用例是否都能通过。它就像一个不知疲倦的“代码守护者”一样监控着代码库，第一时间发现其中的任何问题，将问题通知给整个团队，从而避免了问题的积累和拖延。这非常符合敏捷开发中“今日问题今日解决，不要拖到以后”的原则，它帮你最早的发现问题、报告问题，开发团队则应该建立制度要及时响应滚动生成所报告的问题，把它作为Priority 为0或1的高优先级问题去对待和解决。

封闭签入和滚动生成都是来保护代码库的正确性和产品质量，它们是否在功能上重复反而让我们不敏捷了呢？其实两者并不重复，只是各有侧重，将它们搭配使用才会发挥其最大效能。封闭签入是在代码进入代码库之前进行验证，签入提交者一般希望竟快知道结果，以便决定下一步的工作，所以封闭签入的时间（编译和运行测试用例）不要太长（10-20分钟）。这也就决定了我们加入的测试用例不能太多，只添加那些高优先级的测试用例，保证主要的用户故事不被破坏。滚动生成是在代码签入后在后台执行的，由于不存在着与用户的交互等待，所以它执行时间可以更长（几个小时），可以为它加入更多的测试用例，从而全面验证代码库的质量，一旦有任何问题它可以及时通知团队进行修复，这种验证是在几个小时或者每天都在发生的，保证了敏捷对频繁测试的。

完整的自动化测试解决方案——实验室管理

在谈到软件自动化测试的时候，很多人会误以为实现了自动化测试用例就是自动化测试，其实不然，自动化测试仅是测试自动化的一个重要步骤，绝对不等同于自动化测试。一个完整的自动化测试应该包括：构建、部署、执行测试用例、分析测试结果并作出结论。在前面的自动测试的收益公式中，我们可以看到减少自动测试的维护成本，是提高自动测试收益的重要因素之一。VS 2010的实验室管理（Lab Management）与测试用例管理、生成管理、源代码控制、工作项管理等功能相结合，为自动化测试提供了这样一个完整的解决方案，目标就是要降低了自动测试的运营和非维护成本，下面这张图展示了实验室环境的系统构架图。

图5：实验室环境的系统构架图

实验室管理功能充分利用了微软的虚拟化技术，包括：Hyper-V和 System Center Virtual Machine Manager （SCVMM），快速创建干净的虚拟测试环境并进行产品生成和部署，然后执行指定的测试用例集，将结果以报表的形式呈现出来，方便对此产品质量进行分析，如下图所示：

图6：虚拟测试环境

图7：测试结果

同时，利用虚拟技术的环境快照功能，对于那些难于复现或者环境相关的Bug，利用虚拟环境的快照技术，可以为开发人员准确的复现Bug出现的环境，从而能够快速的进行诊断和及时修复。

总结

Visual Studio 2010作为Visual Studio系列中一个非常重要的版本，为测试人员和团队提供了一整套解决方案，包括：测试计划和用例管理、创建自动化测试用例、测试用例的自动执行、以及实验室管理等。这些功能强调了测试作为整个软件过程的重要角色的作用，促进了测试人员与其它角色的有效沟通与协作，非常适合于敏捷团队使用来完成测试工作。

然后解压缩至X:\Program Files\Common Files\Adobe\即可，最后的文件目录是这样子的：

X:\Program Files\Common Files\Adobe\APE\3.1，该文件夹下有四个dll文件。
重启ZS，搞定。

• Webgrind
• Xdebug
• Gubed PHP Debugger
• DBG
• PHP_Debug
• PHP_Dyn
• MacGDBp
  

测试和优化工具

• PHPUnit
• SimpleTest
• Selenium
• PHP_CodeSniffer
• dBug
• PHP Profile Class
  

文档工具

• phpDocumentor
• PHP DOX
  

安全工具

• Securimage ：验证码工具。
• Scavenger
• PHP-IDS
• Pixy ：代码检查工具。

图形处理

• PHP/SWF Charts
• pChart - a chart-drawing PHP library
• WideImage
• MagickWand For PHP
  

代码优化

• PHP_Beautifier
• PHPCodeBeautifier
• GeSHi - Generic Syntax Highlighter
  

版本控制系统

• Phing
• xinc
  

有用的拓展，使用工具和类

• SimplePie ：PHP RSS 解析程序
• HTML Purifier ：可以用来移除所有恶意代码(XSS)，而且还能确保你的页面遵循W3C的标准规范。
• TCPDF ：一个用于快速生成PDF文件的PHP5函数包。
• htmlSQL ：一个是你可以方便的对HTML和XML内容方便的使用类似SQL语句进行检索的PHP类。
• The Greatest PHP Snippet File Ever (Using Quicktext for Notepad++)
• Creole ：用PHP5编写， 是一个基于真正意义的OO的层，API接口以JDBC为基础。
• PHPLinq ：用SQL语法操作PHP数组。
• PHPMathPublisher：作者是一位法国中学数学老师。
• phpMyAdmin ：可以通过互联网在线控制和操作MySQL。
• PHPExcel ：相当强大的MS Office Excel 文档生成类库。
• Phormer :一个轻量级，强大的PHP在线相册。
• xajax PHP Class Library :一个开源的PHP 类库，用来构建WEB上的Ajax 程序。
• PHP User Class ：用户管理。
• PHP-GTK ：为了证明PHP是一种远远超越网络应用程序的有效的工具而开发的。使用PHP-GTK你可以建立独立的GUI（用户图形界面）应用程序。
  

在线工具和资源

• Minify! ：使用 PHP5 开发的用于合并压缩 js/css 文件的应用程序。合并压缩之后的结果可通过 HTTP gzip/deflate 及一些相关头，优化客户端缓存。
• HTTP_StaticMerger：自动“合并”CSS和JavaScript文件。
• PHP Object Generator ：一个开源的PHP代码生成器。它能够为你的PHP4/PHP5应用程序生成简洁和可测试的面向对象代码。
• gotAPI/PHP
• koders :开放源代码搜索。
• PECL ：含有PHP 开发组提供的不同扩展库的信息。
  

浏览器中的工具（Firefox插件）

• FirePHP ：是基于Firebug的一个扩展，可以用来在Firebug的console中方便的输出php的调试信息又不影响php程序的正常运行。
• phpLangEditor ：是一个用来翻译各种PHP变数的工具.
• PHP Lookup :是一个内置的搜索栏，以帮助您快速查找引用的PHP语法。
• PHP Manual Search ：一个方便的搜索栏，从您的Web浏览器中搜索官方PHP文档。
  

大局观就是向前看一步

记者：就开发者的三个层面（程序员、项目经理、CTO）来说，您怎么理解大局观？

于晶纯：对于大局观的含义，我是这样理解的：很多时候，对于处在不同岗位的程序员、项目经理或者 CTO，如果总以固定的视角看待问题，就容易为日常事务所羁绊，难以在基础之上更进一步。倘若能立足于更高点，以别人的角度审视问题，就能获得全方位的视角，总揽全局。因此，我认为大局观实际上就是向前看一步。

以程序员来说，他们的任务是负责编写程序。再向前看一步，就是要从管理者的角度看待问题，从这一点出发，不仅要求把程序写正确，还要尽量清晰，能让管理者明白自己的意图。

对于项目经理，他们的首要任务是把正在进行的项目完成好。向前看一步就要求他们能够时时了解自己负责的项目处在公司的哪个位置，为何要在这个阶段进行，完成项目以后又希望取得怎样的结果。对项目经理的需求不仅仅是把产品做好，还要能在正确的时间把产品做对。产品再好，投入的精力再多，假使没有在正确的时间投入市场，都是无济于事。

从 CTO 的角度来讲，意味着他的工作是围绕着与技术相关的产品所进行的运营和研发。向前看一步就需要站在CEO 的位置，从整个市场的角度看待问题。因为 CTO 的职责需要他能够帮助 CEO 规划产品的方向，从而为公司带来利润。这一点对 CTO 来说尤为重要，因为仅仅以他所在角度看来微不足道的小麻烦，也有可能会成为影响公司整体运营的大问题。常常站在 CEO 的角度，能够帮助他在日常事务中做出正确的决策或者发现看似细微实则致命的问题。无论公司大小，我建议每位CTO 都学习一些基础会计知识，只有如此，才能够讲 CEO 的语言。

面对复杂形势，具备大局观方能洞若观火

记者：在您的职场生涯中，先后换过无数老板，哪个老板的“大局观”给你留下深刻的印象？

于晶纯：我在 DoubleClick 工作9年，先后与11位老板共事，其中最后一个老板 Greg——DoubleClick的 CIO，给我留下的印象最为深刻。那是在2005年，公司正陷入了产品进度落后的泥潭。为了解决这个难题，公司高层希望采用敏捷开发的办法。然而当时的情况是，偌大一个公司，600多人的技术团队，完全没有敏捷开发的经验。一旦失败，公司必将面临更大的风险。因此，多数人建议先用一个小团队实验，如果方案可行，再逐步推广到全公司；如果失败，对公司的整体影响也不是很大。

然而 Greg 则坚持让所有人从一开始就采用敏捷开发。他的观点是：首先，若要在最短时间内见到成效，就需要全体成员相互信任，一同努力。因为我们的时间紧迫，即使这个小团队成效显著，对公司整体来说也收效甚微。其次，由于团队间存在依赖性，一支团队也还需要来自其他方面的支持，如果其他团队不采用敏捷开发，这仅有的一支团队也必然受到严重制约，进度必然缓慢。再次，他觉得如果认定一件事，就应该全力以赴去做，稍一犹豫，整体计划或许就会延后半年以上，而市场是不等人的。

当时我们听到这些话也是将信将疑，然而接下来事实证明了 Greg 的观点完全正确。我们在敏捷开发的推进上速度飞快，而且由于声势浩大，成为全公司的焦点，进而得到 CEO 的支持。有了最高层的支持，全公司的其他事务也围绕着我们敏捷开发的步调随之转变，从侧面上也推动了我们敏捷开发的进程。

记者：您觉得从 Greg 身上学到了什么？

于晶纯：这件事让我从 Greg 身上看到：如果认定要做，就要把它做得轰轰烈烈，不能患得患失；还有，要讲究配合。这也就要求策略的制定者要站在更高的角度看待问题，只有向前一步，站在 CEO 的位置上，才能明白这些措施并非心血来潮、铤而走险。

以大局观看待职业的选择

记者：您在 DoubleClick 工作时，曾只用两个星期便完成了 DART 平台的关键字预测功能，并赢得了 Lycos 价值百万美金的订单，请问您是如何做到这一点的？

于晶纯：其实我并不认为自己是一名有多么了不起的程序员，我觉得每个人只要有信心、敢于面对挑战都能做得到。唯一的不同可能在于挑战来临之前，我自己的工作完成得非常认真，每一个角落都没放过。所以，当机会到来的时候，我只不过是伸手去抓住而已。

每个清早，睁开眼睛，想到上班，我就会笑，我的先生也觉得奇怪。为什么会这样兴奋呢？因为我爱这份工作，这份热爱使我在每时每刻都努力做到最好。

之所以有信心能在两周内完成这项复杂的工作，是因为我对整个系统特别了解。我心里明白，这件事我做得到，只是会很辛苦。如果没有对工作的热爱，就无法做到了解系统的每个细微之处，自然也不会有信心完成艰巨的任务。

记者：您放弃高额的分红离开 DoubleClick ，创立 FreeWheel，请问主导您整个职业发展生涯“大局”的核心价值是什么？

于晶纯：对我来说，职业正确的标准在于是否学到了新的知识，是否接受了新的挑战。如果仍在重复自己以前做过的事情，原地踏步，实际上对我来说并没有任何意义。回顾自己的职业生涯，我觉得没有白白浪费这许多年的时光，衡量浪费的一个标准便是我是否学到了新内容，是否完成了之前不敢想象的事业。我从程序员一路走到 CTO，虽然大多数时间都在 DoubleClick，然而对我来说几乎等同于每两年就换了一次工作。我意识到，假如我随着DoubleClick 进入 Google，两年以后我仍会是一名团队管理者，也许这个团队的成员会增加许多，但作为管理者，我每天的事务并不会有太大不同。

然而，创办一家新公司，却让我站在了全新的高度。虽然管理的职员减少，但挑战大大增加。此外，作为公司CTO，作为公司的合伙创始人，不单单需要考虑如何将产品开发出来，还要思索如何让产品在市场中得到认可，乃至创立一个全新的品牌，对于 CTO来说，实际上也是向前看一步。这些挑战都是 Google 无法给予的，因为站在 Google 舞台上的表演无非是锦上添花。两年之后，我们所有的成功都证明了当时那个“不可思议”的决定，对于我个人来说是一个多么正确的选择。

从程序员到管理者的成长历程

记者：当您首次从普通程序员晋升为团队管理者，您觉得所面临的最大变化是什么？

于晶纯：从普通程序员成长为团队的管理者是技术人员常常会面临的重大转型。对于技术人员和管理者来说，衡量他们是否成功的标准相差很多。作为技术人员，如果大家看到任何事情都由一人完成，这便是他最大的成功；然而作为团队领袖，要和他的团队一起进步——使稚嫩的成员逐渐成熟，让所有人各尽所能、扬长避短，通过分工合作，最终使每件任务都能高效率地完成。

记者：记得当您刚接手DoubleClick 的芝加哥研发中心的团队时，开始团队成员普遍对您抱着不信任、质疑的态度。在那样的情况下，对于团队管理，首先需要解决哪些问题？

于晶纯：起初那里的员工们对我并不友好，然而最终我实现了彼此的团结一致。之所以能做到这点，首先在于我为团队成员描绘一个大家认同的前景，使得所有成员有了共同努力的方向。其次，就是我尽可能地去了解每一个人，只有如此，才能和成员之间建立情感的纽带。尽管我并不编写代码，但我会阅读每位成员所写的代码，并和每位成员聊天。

培养管理者的大局观，实践和生活是老师

记者：您曾经培养了无数IT管理者，您是如何向他们灌输“大局观”的理念的？

于晶纯：任何理念都不只是口头一说，我带团队的一个主要特色就是寻找做实事的人才，并且通过言传身教来感染他。因为任何观念的传达都不能仅凭几次会议就能实现，而是要靠实践一点一滴积累起来。通过一次次手把手地教，一回回参与集体讨论。尽管很辛苦，但只有如此实践才能真正将大局观传达给每一位同事，并使他们理解和接受。为什么许多人读过管理著作却成不了好的管理者呢？原因就在其中。

另外，对于一个管理者，不能因为仅仅具备高学历就高枕无忧，因为无数的管理经验都来源于身边的点滴。“三人行，必有我师”也是这个道理。通过观察身边的人和事，不仅要留意好的一面，努力学习。还要看到不好的一面，因为旁人失败的经历往往会告诉我们如何避免同样的错误。其实生活就是我们的老师。

（本文来自《程序员》杂志10年01期）

社交网的一个显著特点是支持巨大用户数，例如Facebook支持超过3亿的用户，其数据中心运行着超过万台的服务器，为遍布全球的用户提供信息通讯服务。另外，任何两个社交网用户都可能交互，也就是必须支持任何两个数据库用户的数据关联操作。这对于服务端的数据库管理提出了极大的挑战。

关系数据库与NoSQL 数据库

关系数据库使用者遵循一些数据库范式，这些范式是数据库设计中的一系列原理和技术，目的是为了减少数据库中数据冗余和增进数据的一致性。结构化查询语言SQL大量使用多表连接操作，SQL的通用性可以为使用者带来很多方便。

随着越来越多大规模工作负荷应用的发行，对可伸缩性的需求，可能会变得非常迅速和无比庞大。

关系数据库的确能伸缩自如，但通常只能在单台服务器节点上进行。例如采用表分区技术，一个表格可以由多个物理文件组成，虽然表格的容量增大了，但该表格仍然只能由一数据库引擎管理；另外增加一物理文件时，表格Schema得做改动，也就是还不能支持动态扩容。

一旦单节点的能力抵达上限，就得通过多服务器节点来扩展来分发负载。这时关系数据库的复杂性就开始影响其潜在的扩展规模了。RDBMS支持分区视图（Partition View） 技术，也就是支持联邦数据库（Federated Database）（如图1）。一个分区视图可以由多个分布在不同数据库节点服务器上的表格组合而成，数据库用户看到的只是该视图，不必关心物理表格。通过数据水平分割技术，分区视图把负载分担到多个数据库节点服务器上。扩容时，该方法除了需改动视图定义外，分区视图成为分布式数据库系统的中心，存在单点故障问题。另外，跨数据库节点之间多表格间连接操作的支持出现极大困难。

图1 IBM联邦数据库的体系结构

当试图扩展数据库系统到成百上千个节点时，将导致不堪复杂性之重负，这一特点使得RDBMS在大型分布式系统平台市场里的生存能力被大幅削减。

为了能向客户提供一个伸缩自如的空间存放应用数据，供应商实际上只有一种真正的选择——实现一种新型的专注于可扩展性的数据库系统，而牺牲掉关系数据库所带来的其他好处。NoSQL是非关系型数据存储的广义定义，它打破了长久以来关系型数据库与ACID理论大一统的局面。NoSQL数据存储不需要固定的表结构，通常也不存在连接操作，在超大型数据存取上具备关系型数据库无法比拟的性能优势。该术语在2009 年初得到了广泛认同，其中Key-Value数据模型是解决大型数据库系统扩充问题的一种可行的解决方案。

Berkeley DB Key-Value数据模型

Berkeley DB是一种支持Key-Value数据模型的嵌入式数据库存储引擎。它不支持Client/Server网络访问方式，程序通过进程内的API访问数据库，不支持SQL或者其他数据库查询语言，不支持表结构和数据列。访问数据库的程序自主决定数据如何储存在记录里，一条记录由一个称为键（Key）的数据块和一个称为值（Value）的数据块组成。Berkeley DB不对记录里的数据进行任何包装。应用程序可通过回调函数来定义不同键之间的大小关系，记录和它的键都可以达到4GB的长度。尽管架构简单，Berkeley DB却支持很多高级的数据库特性，比如ACID 数据库事务处理、细粒度锁、 XA接口、热备份以及同步复制。Berkley DB为不同用户提供多种功能集（Feature Set）：支持单个写线程的数据存储（Data Store）；支持多并发写线程的并发数据存储（Concurrent Data Store）；支持ACID和灾难恢复的事务数据存储（Transactional Data Store）；通过复制支持容错的高可靠数据存储（High Availability）。

关系数据库系统由存储引擎和关系引擎两个独立部分组成。存储引擎负责记录存储、索引和事务处理，关系引擎负责基于存储引擎提供的服务，分析SQL、制定查询执行计划等。Berkeley DB是一种存储引擎。例如MySQL数据库可采用MyISAM、InnoDB、Berkeley DB等存储引擎，如图2所示。

图2 MySQL使用的不同的存储引擎

Berkeley DB支持平衡树（BTree）、哈希（Hash）、队列（Queue）和记录（Record）等数据集存储和索引方式，还支持根据Key-Value中的Key创建集群索引（Clustered Index）。这样记录集的物理次序就根据Key值大小来排列。如果要查询结果记录集的键值为给定的一个范围，该特性对于支持这种类型的快速查询起了很大作用。Berkeley DB的一个Key-Value记录集称为一个数据库，会存储在一个单独文件中。Berkeley DB通过创建辅助数据库（Secondary Database），允许对记录集建立非集群索引（Non-Clustered Index）。非集群索引适用于快速查询结果为一条记录，该记录的键值为给定的一个值。例如社交网用户数据集：

User <UID, First_Name, Last_Name, Icon, E-mail>

如果以UID作为主数据库的键，其他字段作为主数据库的值，可再创建一个辅助数据库，以E-mail作为辅助数据库的键，辅助数据库的值为E-mail所对应的UID，也就是指向主数据库记录的指针。若在一个Key-Value数据库查询，一般可根据查询条件创建成一个键值，引擎返回一个游标（Cursor），该游标指向等于或大于该键值的结果数据集。

不难看出Berkeley DB使用的索引技术与SQL Server、Oracle等高端数据库系统是一样的。RDBMS中经常使用的表格连接操作，在Berkeley DB 中不再支持，需要应用程序去实现两个数据集的连接操作。这是Key-Value数据模型与关系数据模型典型的区别。

Berkeley DB 除了作为MySQL的存储引擎之外，还应用在OpenLDAP、MemCache等知名软件。

与Berkeley DB类似的数据库引擎还有Tokyo Cabinet/ Tyrant等。

社交网数据库系统Cassandra

以Facebook用户数据集为例，不可能把3亿条数据集存放在同一个表格、文件或由同一台计算机处理，这要求系统能支持数据分区，把数据集分割在多台节点计算机中，每台计算机分担一部分负载，当用户增加到一定程度时，系统能允许加入新的节点计算机，并且尽可能地减少数据迁移。

2007年10月30日，Amazon的CTO Werner Vogels发表了一篇文章，讨论了一种基于Key-Value数据模型的存储系统Dynamo。该系统支撑了不少Amazon的面向电子商务等关键性应用，它采用的存储引擎是 Berkeley DB 事务数据存储（Transactional Data Store）。Dynamo系统主要为存储1M左右甚至更小的内容，如购物车、推荐列表等。Dynamo设计上有下面一些特点。

• 通过数据分区复制来支持高可靠性与高可伸缩性。
• 始终可写。
• 一致性与写入速度的折中，不要求同步写入所有副本。
• 对称，完全去中心化，人工管理工作很小。

Cassandra DB最初由Facebook开发，后来转变成为开源项目。它是一个为网络社交云计算设计的数据库，主要特点是它不再是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务，对Cassandra 的一个写操作会被复制到其他节点上去，对Cassandra的读操作也会被路由到某个节点上面去读取。对于Cassandra群集来说，扩展性能是比较简单的事情，只管在群集里面添加节点就可以了。

Cassandra的用户包括Facebook、Twitter和Digg等。Digg工程副总裁John Quinn说：“Cassandra采用完全分散的模式，每个节点都一样，不会出现单点故障。它的容错率也非常高，数据可以被复制到数据中心的多个节点中。它还非常具有弹性，随着新设备的加入，其读写吞吐量将呈线性增加。”

Cassandra以Amazon专有的完全分布式的 Dynamo为基础，结合了Google BigTable基于列族（Column Family）的数据模型。P2P去中心化的存储。很多方面都可以称之为Dynamo 2.0。

图3为Cassandra、Dynamo、Key-Value之间的关系及在社交网上的应用。箭头表示依赖关系。

图3 Cassandra、Dynamo、Key-Value关系图

分布式存储系统Dynamo

Dynamo采用Consistent Hashing算法来实现数据分区。

Consistent Hashing基本原理是：首先求出服务器节点的哈希值，并将其配置到0～2^32的圆上。然后用同样的方法求出存储数据的键的哈希值，并映射到圆上。再从数据映射到的位置开始顺时针查找，将数据保存到找到的第一个服务器上。如果超过2^32仍然找不到服务器，就会保存到第一台服务器上。如图4所示。

图4 数据分割到4个节点数据库

如果添加一台服务器。只有在圆上，增加服务器的地点逆时针方向的第一台服务器上的部分数据需要迁移到新的节点数据库。如图5所示。

图5 添加Node5后需要迁移的数据

数据分区后，数据块被复制到N个节点上。复制时因为更新产生的一致性问题的维护采取类似拜占庭容错Quorum协议（Byzantine Fault-tolerance Quorum）的机制以及去中心化的复制同步协议。当一个存储节点被认为是拜占庭节点时，它的行为可能任意偏移，表现在：拒绝响应请求、发送错误消息、存储错误信息。Quorum协议中除了N之外还有两个关键参数：R与W。R代表一次成功的读取操作中最小参与节点数量，W代表一次成功的写操作中最小参与节点数量。R和W直接影响性能、一致性。R 和 W 值过小则影响一致性，过大则影响效率，这两个值要平衡。如果W设置为1，则一个实例中只要有一个节点可写就写成功，不会影响写效率；如果R设置为1，只要有一个节点可读，就读成功，不会影响读效率。

Facebook数据库查询语言：FQL

Facebook为开发者提供一套和SQL风格一致的数据库查询语言，称为Facebook Query Language （FQL）。FQL是一种基于列的数据查询语言。提供丰富的条件查询，甚至包括子查询。

例如，以下FQL查询已安装Facebook应用程序的用户$app_user的好友ID集合：

SELECT uid FROM user WHERE is_app_user = 1 AND uid IN （SELECT uid2 FROM friend WHERE uid1 = $app_user）

与SQL重要区别是FQL不支持：

• 多表连接：JOIN操作
• 分组： GROUP BY操作
• 排序：ORDER BY操作

随着技术发展，一部分基于列结构的NoSQL数据库开始支持分租、排序等复杂数据统计分析功能。

举例：查询好友信息

Facebook应用程序从以下两个数据集中查找一用户的好友数据集信息：

User <UID,First_Name, Last_Name, Icon>

Friend_List <UID, Friend_UID>

注Friend_UID是一指向User（UID）的外键。RDBMS应用程序可使用数据集连接操作实现：

SELECT f.UID, u.Friend_UID, u.First_Name, u.Last_Name, u.Icon

FROM Friend_List f, User u

WHERE f.Friend_UID = u.UID AND

f.UID=@Input_UID

在社交网数据库系统中，由于User数据分布在多台服务器中，其连接操作和外键约束实际上不能支持。

在Facebook中查找一用户的好友信息，得分A、B两步操作实现：

A步

SELECT Friend_UID

INTO @Out_Record_Set

FROM Friend_List f

WHERE f.UID=@Input_UID

B步

FOR EACH （Friend_UID in @Out_Record_Set）

SELECT u.Friend_UID, u.First_Name, u.Last_Name, u.Icon

FROM User u

WHERE u.UID = Friend_UID

No-SQL: Not Only SQL

对于那些关系复杂的数据处理和分析统计，SQL值得花钱。但当数据库结构非常简单时，SQL可能没有太大用处。如果能用普通文件存储代替数据库系统的话，优选普通文件存储。

对于社交网，能够不受限制的扩展比更丰富的功能更加重要。建立大规模社交网成本的压力让很多社交网开发人员努力去寻找更高性价比的解决方案。研究表明基于普通廉价硬件的分布式存储解决方案比现在的高端数据库更加可靠。支持SQL的RDBMS不能解决所有问题的时候，NoSQL不是简单的No SQL，其本质是Non-Relational，这时候NoSQL也就成为Not Only SQL。

（本文来自《程序员》杂志10年07期）

对经济学新人来说，不管论文写几十页，除了倒霉的匿名审稿人之外，没人会花超过五分钟去读。那么合理的写作策略就是最大程度的节省读者的阅读时间，最有效的传递信息。具体而言，我力图达到以下目标：

1. 如果读者只有十秒钟，他也应该清楚地知道我干了什么，主要结果是什么，用了什么数据，贡献在哪里。
2. 如果读者有三十秒，他应该在得知以上信息的基础上，知道我是这么论证的，并且能够快速在三四十页的论文中准确地找到他想读的内容。
3. 如果读者有一分钟，他应该能知道80%的论文内容，并且觉得似乎应该多花两分钟再看看。
4. 如果读者有三分钟，他应该能准确地知道我在讨论的这件事的来龙去脉，准确地知道我的方法我的假设。如果我是一个推销员的话，我必须做到在三分钟内把最重要的卖点都说清楚了，说好了，至于读者买不买，那是另一回事了。
5. 如果读者是匿名审稿人，必须花几十分钟读论文的话，那我要做到最小化他的阅读负担，别把他老人家惹毛了。

如何达到以上目标呢？我总结的心得散见于各位大牛给年轻人的写作建议中，我只是把它们换成我的方式再表达出来。这些建议都宝贵，我读过不少于十遍，写作的时候更是隔三岔五拿出来对照一番，每次都有收获。Mankiew收集的建议在这里， Blattman收集了另一些在这里。

一、如果读者只有十秒，他只会读ABSTRACT. 这个东西极端重要，首先它是论文的第一段，读者这时候注意力还集中着，脑子还转着。一般而言，读者在读完三段以后注意力就散的差不多了，所以头三板斧（段）很重要。其次它一般也是论文的最后一段，读者读完这段才决定是不是往下看，大部分时候就不继续看了。
所以ABSTRACT要把所有重要的内容表述出来，不能超过150字。对empirical的论文来说，这段要包括研究的问题，使用的数据，identification，和所有重要的估计结果，带数字的。
有一回我把ABSTRACT写到150字了，觉得巨满意，简洁得不行，简直不能再多删一个字。后来去投稿，学报要求必须在100字以内，而且是网络提交，网页的对话框是设定好的，一超过100字就变红字，那是相当吝啬. 没办法，再重写。删啊删的，硬是砍掉了50多字，居然也没觉得损失什么内容。可见曾经自鸣得意的简介，如果再使劲儿逼一下，还是有三分之一多的水分。
要投出去的论文，不管是学报也好，JMP也好，应该尽量没有因为写作而造成的水分。

二、如果读者有30秒，他会在看完ABSTRACT之后迅速浏览论文的章节结构，这时候章节的标题怎么写就很重要了。
原则是：章节的标题要传递信息，除了Introduction和Conclusions之外，所有的标题都应该有内容。
比如，如果一个章节叫“Data”， 那就没有内容。如果叫“Data: CPS 1990-2000”，这就是有内容。或者删掉“data”这个词，直接用数据名称做标题，别担心，傻子也会知道那是数据名称，干嘛还非得写”DATA”这个词儿呢？
再比如写作估计结果时，如果那部分标题就叫”Results”， 那就没内容，或者叫“Effects of X on Y”,也没有内容。有内容的写法大概类似于“Higher X, Higher Y”。就像做slides的标题一样，每个标题都直陈了结果。
标题要用几个字来传递具体的信息，所以浏览一遍标题之后，读者就应该具体的知道更多的信息，并且能够准确的找到他感兴趣的内容在哪里，然后读下去。
如果标题仅仅是“data”，“Specifications”， “Identification”之类的单词，那就没有内容，那就是逼着读者往细了看。没人愿意被逼着往细了看，所以人家干脆不看。

三、如果读者有一分钟，他应该能读完这篇论文每一段的第一句话。每一段的第一句话都要“管用”，如果读者只读第一句话的话，我必须保证他不会错过最重要的内容。

具体操作上有三点：1）第一句坚决不是铺垫，然后第二句用什么HOWEVER转回来。又不是玩儿躲猫猫，没什么好转来转去的。第一句就是直接表达本段的意思，本段的其他内容都是细节，没有多于第一句所陈述的内容；2）第一句一定要短，不得不用从句的话，不用多于一个的从句，否则就没意思了；3）单句不成段。论文不是小说，更不是现代诗一路回车。
基本上读者能在一分钟内浏览完了每一个第一句，我论文80%的内容他就应该知道了，想再读的话，去读INTRODUCTION吧。

四、如果读者有三分钟的话，INTRODUCTION就是他要读的全部了。
这个相对简单多了，因为三分钟差不多能读一千字，周旋的余地能大很多。怎么写INTRODUCTION的经验之谈有很多，我不重复。我个人认为重要的方法有：1）不超过三页；2）文献尽量放在脚注中，第一不占地方，第二不阻隔遣词造句，一会儿一个括号一会儿一个人名的，看着和狗皮膏药似的，难看；3）先写要解释的现象本身，再写怎么解释的，最后谈贡献；4）不要出现类似“it is important”的字眼，一件事儿重要与否不取决于你自己说“这是重要的”，直接说事儿，让读者自己判断重要不重要。只有底气不足或者没话可说的人，才隔三岔五就来一句”it is important”，吆喝卖大力丸似的。

五、如果读者是审稿人，真的需要花几十分钟细读的话，写得好点儿，短点儿，短点儿，短点儿，短点儿，再短点儿。
我不相信这世上有“客观存在的真理”，不管你做的是物理化学还是社会科学，都不过是看问题的角度和论述的技巧。哈佛经济系给研究生的“第二写作定理”就是：你的论文质量只取决于你是怎么写的。再牛逼的想法，写砸了就是砸了，没救。（“第一写作定理”是：你的论文多半得不了诺贝尔奖。）

最让我受益的写作建议来自Deirdre McCloskey教授：写完每一句之后都紧接着问一个“SO WHAT?!”（那有如何呢？），然后往下接，如果接不下去，刚写完那句根本就没有存在的必要，删掉。

最后一条我觉得非常有用的写论文建议来自David Romer教授，可以用五个短语概括：Just Write! Just Write! Just Write! Just Write! Just Write!

啥也别干，就是写，论文是写出来的，不是想出来的。

中国的需求对日本走出衰退起到了促进作用。日本状况给世界经济带来了风险。关于这一点，怎么说都不夸张。日本巨额的债务会产生多米诺骨牌效应，逐渐波及到全世界。在中国有力的帮助下，危险似乎已经过去。中国全球化给美国带来了很多影响。最明显的是，中国成为美国商品最大的市场。可口可乐早就完成了那个看上去像是神话的目标：卖10亿瓶可口可乐;曾经嘲笑中国梦的通用在中国卖了很多的别克汽车，在困难时期，中国带来的利润占通用利润的很大一部分;中国联想购买IBM个人电脑业务，挽救了这个垂死部门的工作岗位。中国提供更低价的生活必需品给美国人的生活水平做出了很大的贡献，尤其是对我们不是那么富裕的居民而言。有迹象表明由于能够购买中国低价的出口货物，低收入美国人的生活水平可能提高了5%到10%。

中国金融体系的不合理意味着中国建造了垂死企业，导致巨大的生产力过剩。近些年来，中国财政政策上的反复无常导致过度建造，对铁、铝、水泥和其他原材料产生了巨大的需求。日本人和现在的中国人看上去似乎会买下世界上所有的东西，但是当你看到他们的财政状况的潜在问题时，你会发现一个黑洞。日本人在90年代陷入了这样一个黑洞，至今还在努力地爬出来。中国人很多年后仍将会为目前这种无节制的狂热的购买行为感到心痛。

目前，中国的经济正面临着巨大的挑战。中国的银行是我们所知道的世界上最糟糕的银行。中国每一代，都有相当于美国规模的人口从农村涌入城市。每年，都有1200-1300万新工人加入就业大军。在制造业，生产力对就业的影响比我们国家要严重得多。到2020年，中国人口老龄化会使工作人口与不工作人口的比率成为世界上最糟糕的，比日本更甚。如果没有特效的新政策的话，中国的经济在那个时期就会狠狠地撞墙。到2020年，以我们的标准来看，它会是一个非常穷的国家。

大多数中国人缺乏诚信和社会责任感。中国人不了解他们作为社会个体应该对国家和社会所承担的责任和义务。普通中国人通常只关心他们的家庭和亲属，中国的文化是建立在家族血缘关系上而不是建立在一个理性的社会基础之上。中国人只在乎他们直系亲属的福址，对与自己毫不相关的人所遭受的苦难则视而不见。毫无疑问，这种以血缘关系为基础的道德观势必导致自私，冷酷，这种自私和冷酷已经成为阻碍中国社会向前发展的最关键因素。

中国从来就没有成为一个法制社会，因为大多数中国人的思维方式与守法行为格格不入。中国人老想走捷径。他们不明白这样一个事实：即成就来自于与努力工作和牺牲。中国人倾向于索取而不给予。他们需要明白一个道理：生活的真谛不在于你你索取多少而在于你能给予社会和你的人类同胞多少。

大多数中国人没有学过什么是体面和尊敬的生活意义。中国人普遍不懂得如何为了个人和社会的福址去进行富有成效的生活。潜意识里，中国人视他们的生活目的就是抬高自己从而获得别人的认知。这样一来，一个人就会对"保有面子"这样微不足道欲望感到满足。"面子"是中国人心理最基本的组成部分，它已经成为了中国人难以克服的障碍，阻碍中国人接受真理并尝试富有意义的生活。这个应受谴责的习性使得中国人生来就具有无情和自私的特点，它已成为中国落后的主要原因。

大多数中国人没有勇气追求他们认为正确的事情。大多数人缺乏从错误中筛选正确事物的能力，因为他们的思想被贪婪所占据。就算少数人有能力筛选出正确的事情，他们也往往缺乏勇气把真理化为实践。

大多数中国人习惯接受廉价和免费的事物，他们总是梦想奇迹或者好运，因为他们不愿意付出努力，他们总想不劳而获。很少有中国人明白一个事实，就是威望和成就是通过一步步努力的工作和牺牲实现的，不付出就没有所得。简单来说，如果是为了谋生，那一个人只有去索取;但如果是为了生活，一个人必须要去奉献。

由于在贫穷的环境下生长并且缺少应有的教育，大多数中国人不懂得优雅的举止和基本的礼貌。他们中的大多数人着装笨拙粗鄙却不感到害羞。他们在青少年时所受的教育就是如何说谎并从别人那里索取，而不是去与别人去分享自己的所有。

中国是一个物产丰富的国家，但无限制生育政策所带来恶果使得中国成为了无限廉价劳动力的输出国。这些输出也包括那些受过教育的劳力输出，除了他们的教育水平，实则和其他一般苦力没有本质上的区别。

中国大规模生产的便宜产品降低了输入这些产品的地区的商业信用度。由于技术落后，管理失败，中国制造的单位能耗要比发达国家如日本，美国高出很多。因此，随着出口额的增加，中国在扩大生产的同时丧失着宝贵的能源。同时，这种行为也严重的污染了环境，使中国逐渐变为全世界最不适宜人类居住的国家。

目前中国正在遭受着资本主义社会两大邪恶的折磨，即环境的破坏与人性的丧失。由于人天生贪婪的本性，可以毫无保留的接受资本主义的阴暗面即无止境的追求利润，忽视人的尊严。中国人对西方的技术与产品狂热追求却对西方管理文化所强调的坦率，直接，诚实这些品质漠不关心。

由于中国文化不鼓励敢于冒险这种优良品质，所以中国人极力避免冒险，他们也不想寻求机会来改善自己的生活。中国人对于生活的平衡性和意义性并不感兴趣，相反他们更执迷于对物质的索取，这点上要远远胜于西方人。大多数中国人发现他们不懂得"精神灵性"，"自由信仰"以及"心智健康"这样的概念，因为他们的思想尚不能达到一个生命（补：即肉体和灵性的并存）存在的更高层次。他们的思想还停留在专注于动物本能对性和食物那点贪婪可怜的欲望上。

在中国人的眼中，受教育不是为了寻求真理或者改善生活质量，而只是身份和显赫地位的象征和标志。中国的知识分子从别人那里得到尊敬并不是因为他们为了别人的幸福做过什么，而只是因为他们获得占有了相当的知识。事实上，他们中的大多数只不过是一群仅仅通晓考试却从不关心真理和道德的食客。

中国的教育体系很大程度上已经成为一种失败和耻辱。它已经不能够服务于教育本应所服务的对象：社会。这个教育体系不能提供给社会许多有用的个体。它只是制造出一群投机分子，他们渴望能够受益于社会所提供的好处却毫不关心回报。

中国可以培养出大批的高级技能人才，但却很少可以培养出合格的可以独立主持的管理级专家。服务于一个公司或者社会，光有技术是不够的;还需要有勇气，胆量，正直和诚实的领导才能，这恰恰是大多数中国人所缺少的品性。正如亚瑟。史密斯，一位着名的西方传教士一个世纪前所指出的，中国人最缺乏的不是智慧，而是勇气和正直的纯正品性。这个评价，虽然历经百年，如今依旧准确诊断出中国综合症的病因。

大多数中国毕业生对选择出国并为外国工作不会感到内疚。事实上，他们首先欠下了中国人民在教育上为他们所做出的牺牲。随着传统文化价值观的破坏和逐步衰弱，大多数的中国人，包括受过教育的人都徘徊在精神和内心世界的路口，像迷失的孩子一样不知何去何从。

再次声明：我转载这篇文章并不表示我赞成其中的观点，欢迎讨论，但谢绝人身攻击！

去年我写了一篇ASP.NET MVC 1.0的教程，发表在博客和一本书里。这篇教程捋了一遍创建一个叫做“NerdDinner”的简单程序的过程，这个程序方便人们在线组织、主办和参加餐会。可以在这里参阅我原先的ASP.NET V1 NerdDinner教程。新书ASP.NET MVC 2高级编程也包含了更新过的教程。

这篇NerdDinner教程原先使用的是“数据库优先”的方式，也就是预先定义好数据库结构，然后使用Visual Stduio设计器创建LINQ to SQL或LINQ to Entities等模型对象来做映射。

下面我将演示如何用EF 4的“代码优先”的方式来创建NerdDinner的模型层和数据库结构，然后使用ASP.NET MVC创建一个增删改查程序。

我们将一步一步地创建这个程序，本文的最后有完整示例代码的下载链接。

第一步：新建一个空的ASP.NET MVC 2程序

我们从在Visual Studio 2010新建一个ASP.NET MVC 2项目开始，选择文件 -> 新项目并使用“ASP .NET MVC 2空 Web 应用程序”项目模板就行了。

这样就会新建一个空的ASP.NET MVC 2工程，里面没有什么控制器、模型和视图。

下一步我们将定义NerdDinner“模型”——表示程序中数据的对象，以及包含验证机制和业务规则等的逻辑。模型是基于MVC程序的“心脏”，实际上掌控了程序的行为。我们将使用EF 4新的“代码优先”方式来创建这个模型层。

第二步：创建模型

现在假设我们尚未创建数据库，从头开始创建NerdDinner程序。

我们不需要从数据库开始

当使用代码优先的开发流程时，我们不需要从先创建数据库或者定义数据库结构来开始程序开发。而可以从定义最适合我们程序的模型对象的标准.NET类开始——免除在里面混杂数据持久化逻辑的烦恼。

创建模型类型

NerdDinner是一个小程序，所需要的数据存储非常简单。我们希望能定义和存储代表人们可参加的事件——“Dinners（餐会）”。我们还希望能够定义和存储参加餐会的人员——“RSVP”，用来跟踪有兴趣参加特定餐会的人。

让我们来创建两个类（Dinner和RSVP）来表现这个概念。在我们的ASP.NET MVC项目中添加两个类——“Dinner”和“RSVP”就可以了：

上面的“Dinner”和“RSVP”模型类就是“简单CLR对象”（即POCO）。它们不需要继承什么基类或者实现什么接口，而且里面定义的属性都是标准的.NET数据类型。里面没有添加数据持久化属性和操作数据的代码。

不需要在定义模型类时将他们绑定到特定的数据库、数据库API和数据库结构的功能的确很好，很强大——而且也让我们有了更弹性的数据访问方式。这样我们就能专注于程序和业务需求上，而不用过多考虑持久化的实现方式。另外，它还为我们提供了更换数据库结构或者存储实现方式的弹性空间—不需要重写模型对象或者与它们交互的代码。

创建Context类来处理数据持久化

我们已经定义了两个POCO模型类，现在让我们创建一个类来处理在数据库获取或保存Dinner和RSVP实例的工作。

我们将这个类命名为“NerdDinners”。它继承于DbContext基类，并且定义了两个公开属性——一个用来公开Dinner对象集合，另外一个公开RSVP对象集合：

上面用到的DbContext和DbSet类是EF 4代码优先函数库自带的。你需要添加对System.Data.Entity.CTP程序集的引用，它位于目录\Program Files\Microsoft ADO.NET Entity Framework Feature CTP4\Binaries中。另外在“NerdDinners”类型定义文件中，你需要添加“using System.Data.Entity”命名空间的引用。

这就是所有我们需要编写的代码了

上面三个类就是为我们NerdDinner程序实现一个基本的模型和数据持久层所需要的所有代码了。我们不需要配置额外的数据库结构影射信息，不需要运行任何工具，不需要编写什么XML文件，不需要用什么设计器来使用我们的类在数据库中获取、更新和存储数据。

基于惯例的持久化影射

不需要写什么额外代码，不需要创建什么XML文件，不需要运行什么工具来在数据库中映射我们的模型类。你可能会问，这可能吗？

默认情况下，EF代码优先库支持一个“惯例高于配置”的方式，它使用常见的映射习惯，从而避免显式地做任何配置。如果你想使用自定义的数据库映射规则的话，可以复写这些惯例。但如果你使用惯例的话，你会发现你自己需要写的代码真的很少，在不需要添加额外的代码和配置的前提下，90%的常见情况都可以正常工作。

在上面我们的例子当中，NerdDinner Context类默认会将“Dinners”和“RSVPs”属性映射为数据库的“Dinners”和“RSVPs”数据表。“Dinners”表里每一行都被映射成“Dinner”类型的一个实例。当然啦，“RSVPs”表里每一行都被映射成“RSVP”类型的一个实例。“Dinner”和“RSVP”类型里的属性也就随之被映射成“Dinners”和“RSVPs”表里的列。

EF支持的其它的惯例包括通过常见命名模式自动识别主键和外键（例如：根据Dinner类里的ID或者DinnerID属性推断出主键）。EF还灵巧地支持在两个模型间绑定相联关系的惯例。这里有一篇EF团队的博客讲解了所支持的默认惯例的工作方式。

使用我们模型的代码示例

前面我们创建的三个类包含了所有实现NerdDinner模型和数据持久化的所有代码。现在我们来看一些代码示例，看看如何使用这些类来执行常见的数据库操作：

使用LINQ表达式执行查询

用下面的LINQ查询表达式从数据库中获取数据。下图使用了LINQ表达式来获取所有将要举行的餐会：

我们在写LINQ表达式的时候也可以利用Dinners和RSVPs存在的关系。留意下图“where”子句过滤出参加人数大于0的餐会的方式：

要注意的是上面的查询的“where”子句（即只获取至少有一人参加的餐会）是在服务器端执行的——使执行查询和加载的数据量更为高效。

获取一个实例

我们可以使用LINQ的Single()函数，加上Lamda查询来获取Dinner的一个实例，如下面的代码所示：

或者，我们也可以利用EF“代码优先”函数库提供的Find()函数，根据ID来加载一个实例：

举办新餐会

下面的代码演示了如何创建一个新的Dinner实例并把它添加到数据库中。所有我们需要做的工作就是“new”一个Dinner对象，设置它的属性，最后把它加到NerdDinner Context对象的Dinners属性中。NerdDinner Context类支持 “工作单元”的模式，即你可以在Context中添加多个模型，然后调用“SaveChanges()”以事务的方式保存所有的数据库变动。

更新餐会信息

下面的代码演示了获取一个Dinner实例，更新其中一个属性，然后将改动保存到数据库的过程：

第三步：创建使用我们的模型的ASP.NET MVC控制器

现在来看看使用模型的更完整的场景，使用一个控制器类型来公布即将到来的餐会列表，并允许用户添加新的餐会：

右键单击“Controllers”文件夹，然后选择“添加->控制器”菜单项，我们把新的控制器命名为“HomeController”。

接着添加三个“动作函数”用来处理前面使用EF“代码优先”函数库创建的NerdDinners模型：

.

“Index”动作函数加载并显示即将到来的餐会列表。

而“Create”动作函数允许用户发布新的餐会。第一个“Create”函数用来处理用户访问/HOME/Create页面时，处理“HTTP GET” 的场景，以及发一个“New Dinner”表单让用户填写。而第二个“Create”函数用来处理跟那个表单关联起来的“HTTP POST”场景—将新餐会信息保存到数据库中。如果有任何验证错误，它会重新显示表单并加上相应的错误消息。

给我们的控制器加上视图

下一步将是给项目里加两个“视图模板”——一个给“Index”，另外一个给“Create”。

把鼠标放在控制器里的Index函数里，就可以在项目中为它添加一个视图了，然后单击右键在菜单中选择“添加视图”，弹出“添加视图”对话框。我们将创建一个强类型视图，然后给它传入一个包含“Dinner”模型对象的IEnumerable列表：

单击“添加”后，Visual Studio会创建一个/Views/Home/Index.aspx文件。再添加以下这些代码——为餐会信息生成一个<ul>列表，然后显示创建餐会的链接：

把光标放在控制器的Create函数来在项目中添加“Create”视图，单击右键菜单里的“添加视图”命令。在“添加视图”对话框中，我们还是指定创建一个强类型视图，然后传给它一个Dinner对象。另外还说明了我们希望使用“Create”模板搭个框架：

单击“添加”后，Visual Studio会创建一个/Views/Home/Create.aspx文件，里面有一个包含了为“Dinner”对象生成的HTML <form>表单的草案。我们做一点点的调整，并删掉了为DinnerID属性生成的input元素。最终的视图模板如下所示：

迄今为止，我们已经写好了网站里实现列出餐会清单和创建餐会信息的控制器和视图的所有代码。

第四步: 数据库

代码已经写好了。现在让我们来运行程序。

但数据库呢？

我们现在还没有数据库呢——其实到目前为止也没有必要，因为我们“代码优先”的开发流程并不要求数据库来定义和使用我们的模型类。

但当我们实际运行我们的应用程序时，我们要存储Dinner和 RSVP对象的。我们可以用下面的两种方式之一去创建数据库：

1. 使用数据库工具（如SQL Management Studio或 Visual Studio）去手动创建和定义数据库结构；

2. 使用EF代码优先类库根据我们定义好的模型自动创建和生成数据库结构。

第二种方式非常酷，而且我们要把它用在我们的NerdDinner程序中。

配置数据库连接字符串

在开始前，我们要设置好指向将要创建的数据库的连接字符串。我们把数据库连接字符串“NerdDinners”添加到应用程序的web.config文件中，如下所示：

在默认情况下，当你用EF的代码优先类库创建一个DbContext类的时候，它会自动查找和Context类名匹配的连接字符串。因为我们将Context类命名为“NerdDinners”，所以，当ASP.NET应用程序初始化它的时候，默认会找到前面添加好的“NerdDinners”数据库连接字符串。

使用 SQL CE 4

EF 代码优先类库可以支持多个不同的数据库——包括 SQL Server、 SQL Express和 MySQL。

两个星期前，我写了一篇在ASP.NET中使用嵌入式SQL CE 4 数据库引擎的博客。SQL CE 4 是一个轻量级的基于文件的数据库，安装简便，且可以嵌入在ASP.NET应用程序中。它支持低成本的宿主环境，又能够轻松地迁移到SQL Server 数据库当中。

在定义（和重新定义） 你的数据模型层的前期阶段，SQL CE可以是一个很不错的选择——另外，只要你想，还可以快速地创建和重新创建数据库。在开发NerdDinner应用程序时，我们将以SQL CE 4 作为数据库。后面，我们可以选择更改连接字符串去将产品部署到SQL Express或者SQL Server上——无需修改任何一行代码。

我前面设置的数据库连接字符串，指定了NerdDinners.sdf 数据库文件，并使用SQL CE 4 数据库驱动程序。要使它正常工作，你还需要安装SQL CE 4——安装它可以通过标准的SQL CE安装程序或WebMatrix（已内置SQL CE）。SQL CE 4 很小，只要几秒钟就可以安装好。

重要事项：上面的连接字符串中，我们指定将NerdDinners.sdf 文件创建在\DataDirectory\ 文件夹下——在 ASP.NET应用程序中对应的就是其根目录下的\App_Data\文件夹。默认情况下，新建"空 ASP.NET MVC Web 应用程序"项目模板不会创建此目录。所以你需要显式在项目中创建此文件夹（右键单击该项目并选择"添加 ASP.NET 文件夹-> Add_Data->"菜单项）。

自动创建数据库结构（Schema）

EF 代码优先类库支持自动地从数据模型类生成数据库结构和数据库的能力——免除用户必须手动去执行这些步骤。

如果您的连接字符串指定的SQL CE 或 SQL Express 数据库文件在磁盘中不存在，默认就会发生。你根本不需要执行任何手动步骤。

要看到效果，我们可以按 F5 键运行我们的NerdDinner应用程序。它会启动浏览器，并访问我们应用程序的根目录"/"。你应该可以看到下面所示的画面：

访问应用程序的根目录会调用到HomeController.Index()这个函数——它会实例化并查询我们的NerdDinners context类，来从数据库获取即将举办的餐会列表。因为我们在连接字符串中指定的NerdDinners.sdf数据库文件并不存在，所以EF 代码优先类库将自动地为我们创建该数据库。它会根据NerdDinners context类，推断出数据库结构，最后生成数据库。

你可以通过在Visual Studio解决方案管理器上点击“显示所有文件”图标，然后点击“刷新”按钮，展开App_Data文件夹查看那个自动生成的SQL CE数据库文件。

将来我们会发布一个VS 2010的升级包，你将能在“服务器资源管理器”上打开、编辑SQL CE 4数据库（就跟你现在编辑SQL 数据库一样）。这样，你就可以很容易地看到（或许做点调整）数据库结构和数据内容了。到了那时，你也可以在WebMatrix中使用数据库工具去查看SQL CE 4数据库文件的内容。

我们还没有给NerdDinners数据类指定任何自定义的数据持久化映射规则——所以EF 代码优先类库将会根据默认的命名规范作为映射规则自动生成数据库。但是如果我们指定了任何自定义的映射规的话，EF 代码优先类库将会遵守这些规则，生成与它们匹配的数据库。

让我们回顾一下，这里是我们先前定义的两个POCO数据模型类和NerdDinners Context类：

下面是我们运行应用程序后，根据上述模型类自动创建的数据库中的两个表。

“Dinners”表的定义如下图所示。其中，列名和它的数据类型和Dinner类中定义的属性是完全对应的。DinnerID列被自动的设置成了该表的主键和唯一标识列。

“RSVPs”表的定义如下图所示。该表的列名和它的数据类型和我们在RSVP类中定义的属性也是一致的。其中，RsvpID列被设置成了该表的主键和唯一标识列。

在Dinners表和RSVPs表之间，一个一对多的主键/外键关系也同时被创建起来了。EF 代码优先类库自动建立了这种关联，因为Dinner类中有一个类型为ICollection<RSVP>的RSVPs属性，同时，RSVP类中也有一个Dinner的属性。

为数据库填充餐会信息

现在，让我们来新建一些餐会信息并将它们写入数据库。我们可以通过点击我们首页中的“Create New Dinner”链接来跳转到“新建”页面。

当我们点击“Create”按钮时，新餐会将被保存到数据库。我们可以重复数次来新建多个不同的餐会。每条我们新建的餐会都将会保存在数据库中，并会被显示在首页的“Upcoming Dinners”（即将举办的餐会）列表中。

第五步：更改数据模型

随着我们应用程序开发的推进，我们将继续改进和重构我们的模型。EF 代码优先类库包括一些很好的开发功能，这使我们在开发数据库时更容易协调某些改进。

给Dinner（餐会）模型添加一个新的属性

让我们对我们的Dinner类做一个简单的修改，更具体的说，我们将给Dinner类添加一个新的“Country”属性。

做完改动，让我们在Virtual Studio中按下F5按钮，重新编译并运行应用程序。将会看到下面的这些错误信息：

这些错误信息之所以出现，是因为我们修改了Dinner类的结构定义，我们的模型对象现在已经不再和数据库中自动创建的Dinners表一致了。

当EF自动地为你创建数据库时，默认地会增加一个“EdmMetadata”表，这个表用来记录自动创建数据库时使用的模型对象的形状。

当EF发现你修改过模型对象，并且和之前自动创建的数据库不再同步时，就会出现上面的错误消息。

重新同步数据模型类到数据库

我们有很多同步模型对像和数据库的方式：

• 我们可以手动地更新数据库中的结构（Schema）让它们保持一致。
• 我们也可以先删除数据库文件，然后重新运行应用程序，让EF自动重新创建数据库。
• 我们也可以开启EF 代码优先功能，当数据模型发生任何改变时能够自动更新数据库 。

下面，让我们在NerdDinner应用程序中看看如何使用最后一种的自动更新的方式。

当模型对象发生变化时重新创建数据库（RecreateDatabaseIfModelChanges）功能

在EF 代码优先类库的CTP 4版本中包括了一个非常有用的开发时（development-time）功能，它允许你在任意时刻修改数据模型类，自动重建数据库。当你开启这项功能的时候，EF能够识别用来创建数据库的类模型在何时被改动，何时可以重建你的数据库以匹配新的模型类——你不需要做任何手工操作。

这项功能在你刚开发一个应用程序时特别实用，因为它为你快速地重构你的模型代码带来了很大的自由度和灵活性——你根本不用去手动地保持数据库结构的同步。它特别适合SQL CE，因为SQL CE是一个基于文件的数据库而且可以随时在运行时删除和创建。这使得开发流程变得不可思议的流畅。

启用这项功能最简单的方法就是在Global.asax类中的Application_Start()事件处理函数中加上Database.SetInitializer()方法的调用。

这个调用告诉EF当数据模型发生任何变化时，重建NerdDinners.sdf数据库以匹配NerdDinners类。现在当我们重新运行应用程序的时候，再也不会出现提示说类模型和数据库不匹配的错误信息了。反而，EF会自动重建数据库以匹配新的数据模型类，我们的应用程序会正常运行：

为自动创建的数据库产生初始化的数据

在上面的截图上，你可能已经注意到我们之前添加的餐会数据在重建数据库之后就丢失了。这是因为根据模型变化自动重建数据库的功能并不适用于实际场合，此时你想将已经存在的数据从一个数据库移植到另外一个数据库中。相反，它是被设计用来适用于开发场合，我们需要数据库结构能快速地自动更新——而不是通过手动地或指定移植规则来实现。

注意：我们另外正在做的工作，用来提供更好的数据移植服务，支持这种适用于产品数据和数据库结构的版本管理。但我们想这和前面讲的前期开发时（development-time）功能是不同的场景。这种数据移植的功能现在还不会在这个星期的CTP上发布。

其实，EF已经为我们提供了可选的 “种子” 功能，用以在创建或者重建数据库时产生默认或测试数据。我觉得这个功能真的很实用，因为这样一来，在我重构一个数据模型后，马上就可运行应用程序去测试—不用重新手动地输入一堆的测试数据。

我们可以通过实现一个如下所示的“NerdDinnersIntializer”类，将这些“种子”数据到加入到数据库当中。我这里用它创建两个“示例餐会”并把它们加入到数据库中。

然后，我们可以在Global.asax加入Database.Initializer()方法以在启动时使用这个“NerdDinnersInitializer”类。

现在任何时候我们更新NerdDinner模型类，数据库文件都会被删除和重建以匹配我们的模型类，同时，两条默认餐会数据也会被添加到数据库中用以测试。

方便重构

上述的功能使我们非常容易地在开发时改进和重构代码——不需要用到任何工具和脚本去手动地保持数据库结构和代码的同步。

由于我们的模型类、LINQ表达式和“种子”测试数据都是强类型，所以我们也可以很快速地用Visual Studio的重构工具自动在代码文件中应用所有更改。

第六步: 加入验证规则

我们已经创建了一个简单但很好的数据服务应用程序。

但是，这里还是有一个问题，那就是我们还没有任何地方做数据验证以确保我们填入的数据库中的数据都是正确的。让我们来搞定它。

用DataAnnotations实现数据验证

在基于ASP.NET MVC的应用程序中，通常加入验证规则的地方最好是数据模型。这样，可以只在一个地方进行维护，同时也使强制任何与它交互的Controller和View的遵循它。在ASP.NET MVC中，你可以通过很多种机制去实现数据验证，它可以很灵活地支持你想要使用的任何验证机制。

ASP.NET MVC 2内置支持使用.NET类库中System.ComponentModel.DataAnnotations的验证规则库—你可以显式地在模型类中通过验证特性（Attribute）来使用验证规则。你可以在我之前发表的博客中了解这项功能的更多信息。我们将把这种方式的优势应用到我们的NerdDinner应用程序中的输入数据验证上面来。

让我们回过头，将一些数据验证的特性加入到我们之前定义好的Dinner类的属性当中去。（注意：我们同时要加入“using System.ComponentModel.DataAnnotations”命名空间。）

[Required] 验证指明这个属性的数据是必须指定的（非空的）。[StringLength] 指定了该属性允许输入的最大字符串长度。[RegularExpression] 验证指定了用以验证输入匹配的正则表达式（这里我们用以验证邮件地址）。

每一个验证特性都支持“ErrorMessage”属性，这使得我们可以指定验证失败时显示的错误消息。你既可以通过硬编码的方式（像上面一样）指定，也可以通过让它从一个资源文件里取得—可以很容易地实现本地化。

引入一些CSS和JavaScript文件

最后一步，我们将回到Create.aspx视图模板中，加入<link>引用Site.css文件到项目中，同时也加入两个<script>元素引用两个JavaScript文件。我们还在<form>元素呈现之前加入一行代码来调用Html.EnableClientValidation()方法。

这些改动将会确保那些验证错误信息以正确的样式显示出来（让它们更惹眼），而且这些数据模型的验证规则会同时应用在客户端和服务器端。

运行应用程序

让我们重新运行应用程序并尝试注册一个新的餐会。让我们先按一下还没有填写数据时的"创建"按钮。现在我们会发现模型中的验证错误消息在浏览器中已经显示出来：

由于我们在ASP.NET MVC中启用了客户端验证（即我们上面所写的代码中的一行)，我们的错误消息将会实时更新：

注意上面，当我们给”Title”输入的字符串长度大于20的时候，验证错误信息改变的方式。这是因为我们为Dinner.Title设置的验证[StringLength]特性指明了最大允许的长度是20。而当我们开始在“HostedBy”文本框中输入字符串时，错误信息从“[Requred]”（要求你输入电子邮件地址）变成了“[RegularExpression]”（它告诉我们没有输入一个有效的电子邮件地址）。

这些验证规则在浏览器中（通过 JavaScript）和服务器上（即使有人试图绕过JavaScript 验证，也能保护数据的输入有效性）都有效——不用我们对Controller类作任何更改。这种将规则在我们的模型类内指定一次就可以被应用到处任何地方的能力是极其强大的——将使我们能够以一种非常清楚的方式继续改进我们的程序。

你可以通过这里了解更详细的有关这些 ASP.NET MVC 2 模型验证功能和它们的工作方式。

下载

点击这里下载和运行我们在这篇博客里实现的NerdDinnerReloaded示例。你需要安装了VS 2010 (或者免费的Visual Web Developer 2010 Express) 。

重要提示：你必须在你的机子上下载和安装SQL CE 4后才能运行上面的示例程序。你可以从这里下载EF 代码优先类库。这两个下载都不会对你的机器有太大的影响。

1、WSF/PHP【WSO2 Web Services Framework for PHP】 是WSO2.ORG提供的专门针对PHP调用Web Service的一个优秀框架，使用非常简单；但是WSO2不仅仅提供针对PHP的ws框架，而且还对其他很多中语言提供开发框架，比如基于Spring、Perl、Ruby……，除此之外还提供很多其他框架和培训服务，具体可查询wso2.org和wso2.com；
2、WSF/PHP模块的安装需要很多其他的支持包，在windows下面体现为一些dll文件，主要包括Libxml2、iconv、Openssl、zlib，而不仅仅是Libxml2【GNOME XML Library】；安装过程中需要将这些依赖dll全部都集中到wsf_c/lib/目录中；这些依赖包可以到http://www.zlatkovic.com/pub/libxml/下载，下载完成之后对各压缩包解压，dll文件一般位于/bin/目录中；
3、WSF所依赖的这些dll文件一定需要copy到/windows/system32/中才行，否则加载模块不成功；这点和官方文档中说的直接将wsf_c/lib/加入到path中即可是不一致的；当然这点可能有其他方式可以解决，因为我不精通PHP，但是和一些同事沟通过，但没结果；
4、验证是否正常加载了WSF模块，只用php -m命令查看列表是不够的，即时WSF模块没有加载成功，但是php.ini中设置了WSF模块，那php -m的列表中也会包括WSF；最保险的做法是查看服务器日志比如Apache；
5、在申明WSSecurityToken实例的时候，参数receiverCertificate是用来加密Soap消息的，而不是用来验证服务端返回的签名信息的，所以若只是需要签名，那该参数无需设置；WSF/PHP目前还没有提供验证服务端返回的签名信息功能的；
6、WSF/PHP调用WS时默认使用SOAP 1.2协议，这可能会对某些服务端ws调用时出错，若需要设置使用SOAP版本，则可以在申请WSClient实例时设置参数"useSOAP" => "1.1"实现

五术六艺诸子百家之说，都能称为“国学”，所以，国学又称为“中国学”、汉学。

《四库全书》分经、史、子、集四部分，又称“四库”。部下有类，类下有属。全书共4部44类66属。经部收录儒家“十三经”及相关著作；史部收录史书；子部收录诸子百家著作和类书；集部收录诗文词总集和专集等。《四库全书》的分类法是中国古代最具代表性的图书分类法之一。

　　1．经 部：《易经》、《尚书》、《诗经》、《周礼》、《仪礼》、《礼记》、《大学》、《中庸》、《孟子》、《论语》、《孝经》、《尔雅》、《春秋左传》、《春秋公羊传》、《春秋谷梁传》。

　　2．史 部：《史记》、《汉书》、《晋书》、《宋书》、 《梁书》、《陈书》、 《魏书》、《周书》、《隋书》、《南史》、《北史》、《宋史》、《辽史》、 《金史》、《元史》、《明史》、《史通》、《战国策》、《后汉书》、《三国志》 、《南齐书》、《北齐书》、《旧唐书》、《新唐书》、《列女传》、《越绝书》、 《水经注》、《岛夷志略》、《旧代史》、《新五代史》、《吴越春秋》、《风俗通义》、《华阳国志》、《建康实录》、《贞观政要》、《资治通鉴》、《天工开物》、《东周列国志》。

　　3．子 部

　　儒家：《道德经》、《荀子》、《说苑》、《帝范》、《政训》、《潜书》、 《新序》、《盐铁论》、《潜夫论》、《近思录、》、《郁离子》、《传习录》 《呻吟语》、《孔子家语》、《温公家范》、《袁氏世范》。

　　兵家：《孙子兵法》、《吴子》、《司马法》、《尉缭子》、《孙膑兵法》、《六韬》、《三略》、《握奇经》、《素书》 、《将苑》、《李卫公问对》、《虎钤经》、《守城录》、《练兵实纪》、《纪效新书》、《何博士备论》。

　　法家：《管子》、《商君书》、《韩非子》、《齐民要术》、《农桑辑要》。

　　医家：《黄帝内经》、《神农本草经》、《黄帝八十一难经》、《洗冤集录》。

数理天文类 ：《周髀算经》 。

杂家：《山海经》。

小说：《西游记》、《水浒传》、《三国演义》、《醒世恒言》、《喻世明言》、《警世通言》、《拍案惊奇》、《二刻拍案惊奇》、《封神演义》、《红楼梦》、《儒林外史》。

　  4．集 部：《楚辞》、《诗品》、《曲品》、《南戏》、《花间集》、《柳永词》、《晏殊词》、《东坡词》、《秦观词》、《放翁词》、《姜夔词》、《楚辞》、《乐府诗集》、《历代辞赋选》、《汉代诗选》、《魏晋诗选》、《南朝诗选》、《全唐诗》、《唐诗三百首》、 《唐五代词选》、《唐宋名家词选》、《千家诗》、《全宋词》、《全宋诗》、《金元明清诗选》、《全元曲》、《明清词选、《文选》、《古文观止》、《李太白集》、《杜工部集》、《韩昌黎集》、《柳河东集》、《白香山集》、《东坡全集》、《文心雕龙》、《沧浪诗话》、《诗品》、《六一诗话》。

http://219.143.225.7/
http://211.94.161.70/
http://202.108.212.210/
http://202.108.212.211/

这里简单的对比一下OpenDNS,GoogleDNS,NortonDNS的速度吧。

OpenDNS:208.67.222.222,208.67.220.220
GoogleDNS:8.8.8.8,8.8.4.4
NortonDNS:198.153.192.1,198.153.194.1

OpenDNS:最短 = 218ms，最长 = 302ms，平均 = 251ms
GoogleDNS:最短 = 112ms，最长 = 216ms，平均 = 143ms
NortonDNS:最短 = 109ms，最长 = 200ms，平均 = 139ms

启动Web Access：service vmware-webAccess start

以工作中某项目的安全改善过程为例，分享了常用网站安全性的典型问题和解决对策，希望对网站开发者有借鉴意义。

有过网站开发经验的朋友都知道网站安全是构建网站时必须要考虑的一个因素，网站安全的重点在于服务器的安全配置管理以及程序脚本的完善性。值得注意的是，如果服务器的账号和权限由于管理不善而泄露了，即使技术上网站系统再安全，也不可避免会受到攻击。

在笔者曾经参与过的一个项目中，客户方邀请了专业的第三方安全测试公司进行了安全性的全面检测，同时也针对性地进行了安全性的改善，特别是在应用程序方面。此文将分享改善过程中的几个典型问题的分析和解决对策，包括SQL注入攻击、跨站点脚本攻击、验证码绕过等，希望能够为大家在改善网站安全方面的工作提供参考，并采取相应的防范措施。

项目背景

该项目使用的技术和平台：

OS：Windows 2008 Server, Enterprise Edition 64-bit

Database：Microsoft SQL 2005 Server, Standard Edition

WebServer：IIS7.0

开发平台：.NET Framework 2.0

考虑到网站安全的跨平台和通用性，文中讨论时仅提供对应策略不使用实际代码，这里所有的项目网站用到的域名统一用example.com代替。

改善之前

第三方专业安全测试公司进行测试，其中的重点问题列表如下：

问题1：易受到SQL注入攻击

风险：攻击者可以通过应用程序发送数据库命令，这些命令将被服务器执行。这可以用来对数据库进行完全控制。这些SQL注入漏洞可以通过在其中一个区域插入“and 7 = 7 -”或“and 8 = 9 -”，并比较结果进行判断。

分析：SQL注入攻击是由于服务器对参数检查不够，而导致攻击者借此获得敏感信息。因此，需要使用参数化查询以确保攻击者无法操作数据库的SQL查询语句。例如，如果应用程序要求输入名称，那它应该只接受字母字符、空格和撇号，而不接受任何其他字符。也就是说，在应用程序中的所有输入域实施服务器端白名单技术。特别是所有用于SQL语句的输入域，需要空格的都应该用引号括起来。

改善：在程序中所有可接受外部参数的地方进行逐一识别，以过滤危险字符。如在全局函数中定义“禁止字符串列表”，该表中列出所要过滤出的SQL攻击代码可能包含的字符串。

and |exec |insert |select |delete |update |count | * |chr |mid |master |truncate |char |declare |<|>|’|(|)|{|}

//当然可以根据网站的特点完善和修改本列表

接下来做如下处理：

问题2：易受到跨站点脚本攻击

风险：此漏洞可以被用来获取身份验证Cookie，攻击管理员账户，或使应用程序的用户攻击其他服务器和系统。该漏洞可以通过在某区域中插入“<script>alert(‘23389950’);</script>”来判断。

分析：这也需要在本网站的所有输入域实施服务器端白名单技术。如果需要特殊字符，应该转换为更安全的形式。如适用于各种语言的HTML转码：

• &应转换为 &；
• “应转换为”；
• ‘应转换为&39；
• >应转换为>；
• <应转换为<。

改善：除了这些标准的HTML转码之外，对于可疑字符串也要进行强化检查和转化，并进一步执行以下操作：（1）对各页面的输入参数进行强化检查；（2）对原来只在客户端判断的参数，在服务器端进一步强化检查;（3）最终提供了全局的转码和过滤的函数。当然这需要在性能和扩展性以及安全性方面的平衡综合考虑。

问题3：非安全的CrossDomain.XML文件

风险：为解决Flash/Flex系统中的跨域问题，提出了crossdomain.xml跨域策略文件。虽然可以解决跨域问题，但是也带来了恶意攻击的风险，如果该策略文件里允许访问任何域，就可能允许发起对网络服务器的跨站点请求伪造和跨站点脚本攻击。比如，不安全Flash应用程序可能会访问本地数据和用户保存的网页记录，甚至传播病毒和恶意代码。

分析：考虑如何确保只对提供安全资源的可信域开放允许。

改善：经过调查，发现在程序目录下的crossdomain.xml文件里的配置如下：

<?xml version=”1.0″?>

<!DOCTYPE cross-domain-policy SYSTEM ”http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd”>

<cross-domain-policy>

<allow-access-from domain=”*” />

</cross-domain-policy>

文件中的allow-access-from 实体设置为星号设置为允许任何域访问，将其修改为 <allow-access-from domain=”*.example.com” />，表示只允许本域访问，该问题就解决了。

问题4：Flash参数AllowScript-Access 已设置为always

风险：当AllowScriptAccess为always时，表明嵌入的第三方Flash文件可以执行代码。攻击者此时就可以利用该缺陷嵌入任意第三方Flash文件而执行恶意
代码。

分析：AllowScriptAccess参数可以是“always”、”sameDomain”或“never”。三个可选值中，“always” 表示Flash文件可以与其嵌入到的 HTML 页进行通信，即使该Flash文件来自不同于HTML页的域也可以。当参数为“sameDomain”时，仅当Flash文件与其嵌入到的HTML页来自相同的域时，该Flash文件才能与该HTML页进行通信，此值是AllowScriptAccess 的默认值。而当AllowScriptAccess为 “never”时，Flash文件将无法与任何HTML页进行通信。

因此需要将AllowScriptAccess参数设置为“sameDomain”，可以防止一个域中的Flash文件访问另一个域的 HTML 页内的脚本。

改善

<param

name=”allowScriptAccess” value=”always” />

改为

<param

name=”allowScriptAccess” value=“sameDomain” />

问题5：网站后台管理通过不安全链接实施

风险：管理访问没有强制实施SSL，这可能允许攻击者监视并修改用户和服务器之间的发送的包括账户凭据在内的所有数据。如果攻击者通过代理或者路由软件拦截服务器和管理员间的通信，敏感数据可能被截获，进而管理员账户可能会受到危害。

分析：管理访问没有强制实施SSL，为防止数据拦截，管理访问应该强制执行HTTPS (SSL3.0)。

改善：运维对服务器进行了配置调整，单独配置支持了SSL3.0访问管理后台。

问题6：验证环节可以被绕过

风险：用户发布信息时，虽然有页面的验证码防止自动恶意发布，但仍可能被绕过进行自动提交。绕过的方式之一是使用过滤和识别软件，之二是可以利用Cookie或Session信息绕过验证码。

分析：图像失真机制本身不是特别强，可以很容易地使用公开的过滤和识别软件来识别。生成的图片也是可以预测的，因为使用的字符集很简单（只是数字），建议实现一个更强大的验证码系统。

Cookie或session信息处理有漏洞导致验证码被绕过, 确保每一个链接只能取得唯一的验证码，并确保每个请求产生并需要一个新的验证码。

改善：根据需要增加验证码的复杂度，而不只是单数字。

经过分析发现是因为验证码被存入了Session里，而开发人员忘记在提交之后清空Session中的验证码的值，导致验证码在过期时间内一直可用，从而可能被利用多次提交。因此在提交后追加了及时清空验证码的操作。

问题7：泄露敏感信息

风险：此信息只能用于协助利用其他漏洞，并不能直接用来破坏应用程序。网站的robots.txt文件里可以获得敏感目录的信息，这可能允许攻击者获得有关应用程序内部的其他信息，这些信息可能被用来攻击其他漏洞。

分析：robots.txt不应在提供管理界面的信息。如果robots.txt文件暴露了Web站点结构，则需要将敏感内容移至隔离位置，以避免搜索引擎机器人搜索到此内容。

改善：当然robots.txt要根据SEO的要求来处理，但也要同样注意安全性。如：disallow:/testadmin/，其中testadmin为管理后台，就被暴露了。可以根据实际情况是否必要决定删除robots.txt文件或者把敏感目录单独配置禁止搜索引擎搜索。

其他问题汇总

除此以外，还有很多其他危害性相对较低的问题，分析如下。

问题：可能通过登录页面枚举出用户名，因为根据账户是否存在的错误信息是不同的。

对策：修改错误信息使之不带有提示性，如“您输入的邮箱或密码不对!” 并且超过一定次数则对该IP进行锁定。

问题：检测到可能泄露敏感信息或被恶意利用的冗余文件，如测试文件、bak文件、临时文件。

对策：除去服务器中的相应文件。

问题：发现潜在机密信息，如名为order的文件很容易被联想到用户订单。

对策：避免在文件名中含有完整的敏感词汇或不要在容易猜测到的文件中保存敏感信息，或者限制对它们的访问。

问题：发现内部信息泄露。

对策：除去代码中漏删的内部IP地址，内部组织，人员相关信息等。

共性原因分析

在发现的问题中，71%是与应用程序相关的安全性问题。可以修改应用程序相关的安全性问题，因为它们是由应用程序代码中的缺陷造成的。29%是基础结构和平台安全性问题，可以由系统或网络管理员来修订“基础结构和平台安全性问题”，因为这些安全性问题是由第三方产品中的错误配置或缺陷造成的。

综合主要的原因包括但不限于以下三个方面。

程序方面

• 未对用户输入正确执行危险字符清理；
• Cookie和Session使用时安全性考虑不足；
• HTML注释中或Hidden form包含敏感信息；
• 提供给用户的错误信息包含敏感信息；
• 程序员在 Web 页面上的调试信息等没有及时删除。
• Web 应用程序编程或配置不安全；

配置方面

• 在Web目录中留下的冗余文件没有及时清理；
• Web服务器或应用程序服务器是以不安全的方式配置的。
• 安全规范文档不够完善，开发人员的培训不足；
• 开发人员的安全相关经验和安全意识不足。

对于这些问题的解决方法-——技术之外

对于安全问题本身的解决可能只能case by case ，但为了预防更多潜在问题的引入，技术之外方面的改善也不容忽视：

1. 对于开发人员在项目初期即进行安全开发的培训，强化安全意识。

2. 建立用于共享安全经验的平台，将经验形成Checklist作为安全指南文档。

3. 将成熟的代码成果提炼出公共安全模块以备后用。

本次改善之后总结出一些常用基本安全原则供大家参考，见“非官方不完整网站开发安全原则”。

作者简介：晁晓娟，目前在互联网公司负责项目管理。InfoQ中文站SOA社区编辑，有多年的Web开发管理经验，关注项目管理、架构和产品。

.NET Framework 自从 2002 年发展至今，已经历了好几个版本，1.0, 1.1, 2.0, 3.0, 3.5 等不同的版本更替，.NET Framework 的Redistributable Package也愈来愈大，到了 .NET Framework 3.5 SP1 时已经膨胀到 231MB，除非软件本身就很大，不然对于 .NET 软件的Redistribute是相当不利的，除非客户端本身就有安装 .NET Framework，否则几乎都要夹带一个 .NET Framework 的Redistributable Package，如果只是一个小小的应用程序文件 (几十或几百KB) 还要夹一个那 大的 .NET Framework Redistributable Package，大概很多开发人员都会觉得麻烦，就算开发人员接受，但在企业网络的 IT 管理人员就不一定会接受了 … 所以 .NET Framework 的减肥一直都是 .NET 开发人员的愿望与期待，而 .NET Framework Client Profile 就是微软针对这个需要的主要响应。既然 .NET 应用程序不一定会用到所有的 .NET Class Library，那微软就将 .NET Framework 部份不常用的功能由主函数库中抽离出来，让Redistributable Package可以缩小，有利于重新发布应用程序。

.NET Framework Client Profile 在 .NET 3.5 时首次和开发人员见面，但是碍于它只能利用 ClickOnce 部署方式安装，因此使用它的开发人员不多，且也有许多人反应希望将 .NET Framework Client Profile 能够利用光盘或其他储存媒体转散布，微软从善如流，将 .NET Framework 4.0 的 Client Profile 改成Redistributable Package。

The .NET Framework 4 Client Profile 包含下列功能：

• Common Language Runtime (CLR)
• ClickOnce
• Windows Forms
• Windows Presentation Foundation (WPF)
• Windows Communication Foundation (WCF)
• Entity Framework
• Windows Workflow Foundation
• 语音
• XSLT 支援
• LINQ to SQL
• Entity Framework 与 WCF Data Services 执行期设计函式库
• Managed Extensibility Framework (MEF)
• 动态型别
• 并列程序设计功能，例如 Task Parallel Library (TPL), Parallel LINQ (PLINQ), and Coordination Data Structures (CDS)
• 除错客户端应用程序

下列功能不包含，要另外安装 .NET Framework 4.0 的完整版本：

• ASP.NET
• 进阶 Windows Communication Foundation (WCF) 功能
• .NET Framework Data Provider for Oracle
• 编译用 MSBuild
• Visual Studio 2010 的项目中，下列应用程序会默认使用 .NET Framework 4.0 Client Profile，若要使用完整的 .NET Framework 功能，则要自行到项目属性中设定 target framework 至 .NET Framework 4.0：
• Windows Projects (C# and Visual Basic)
• Windows Presentation Foundation
• WPF Application
• WPF Browser Application
• WPF Custom Control Library
• WPF User Control Library
• Windows Forms
• Windows Forms Application
• Windows Forms Control Library
• Console Application
• Empty Project
• Window Service
• Visual F#
• F# Application
• F# Tutorial
• Workflow (C# and Visual Basic)
• Activity Designer Library
• Activity Library
• Workflow Console Application
• Windows Communication Foundation
• WCF Service Library
• Office 2007 and Office 2010
• All projects target the .NET Framework 4 Client Profile

而 .NET Framework 4.0 Client Profile 与原有的 .NET Framework 3.5 Client Profile 不同的地方有：

• 3.5 版本的 Client Profile 只能使用在 Web (ClickOnce)，4.0 版本则因为具有Redistributable Package，所以可同时适用于本机或 Web 安装。
• 3.5 版本只支持 x86 的 Windows XP SP2/SP3，4.0 版本则支持除了 IA64 以外，.NET Framework 4 支持的所有平台。
• 3.5 版本的 Client Profile 与 .NET Framework 3.5 是分开的版本，4.0 版则为 .NET Framework 4.0 完整功能的子集。
• 3.5 版本会受 Windows Update 的影响自动升级到 .NET Framework 3.5，4.0 版则可以在不需要完整 .NET Framework 4.0 下自行运作，也可以分开提供服务。

不过也因为如此，当在 Visual Studio 2010 建立新项目时，如果发现 [添加引用] 中没有列出原本应该列出的组件时，可以先检查是否是项目的 target framework 设成了 .NET 4.0 Client Profile (例如 System.Web.dll 就不在 .NET 4.0 Client Profile 套件中)。

吸引和培养第一流的人才，给他们架设一个足以充分发挥其才能的空间，并保护其智慧成果。

这条定律在之前的文章中我已谈过。大体上，IT=IQ+IP，这条定律展示了微软中国研发集团在两个层面的努力。一是为员工构建一个充满引力的创新磁场，让他们同才华横溢的同事们一道，在一个充满机遇与激励的环境下分享彼此的灵感和激情。奋发、进取、和谐、舒适的空间，将淋漓尽致地释放出每个人的潜能，使他们感觉到“英雄自有用武之地”。二是创造机会，让他们有机会参与到核心技术和产品的研发中，激扬其智慧。未来，微软中国研发集团将不断输入资金、领袖及人才，输出一项项对微软公司、对中国用户、对全球IT产业影响巨大的创新成果。

2. E=MC2

吸纳一大批有卓越潜质的人才（M），同时缔造一个过程（C2）——一个完全释放人才潜质的过程。在此过程中，先进的管理方式、富于感染力的企业文化将在个人、群体之间产生一系列正面的连锁反应，从而最大程度地激发出微软中国研发集团的动能（E）。

磁场理论可以解释为何天才的周围很少有庸人——优秀的人物总是像强磁场一样时刻吸引着与他们志同道合的英才。经过多年的积累，当前研发集团形成了金字塔型的人才结构。位于金字塔顶端的员工约占20%，他们大多在微软总部或其他跨国公司的研发机构从事过多年的技术和产品创新，能力超凡，经验丰厚，甚至因成就卓越而享誉国际，形成了人才的品牌效应。这不仅是简单的“志向”上的吸引，更是职业生涯的加速器。在其引导下，新员工将很快成长为谙熟大型软件研发流程的“高手”。

对一个快速成长的研发组织，人才间的“惺惺相惜”固然是吸引和培养人才的渠道，但系统的“360度培养战略”更加重要。在这方面，微软中国研发集团投入了巨大的资源与精力，希望让每个员工在这里都能最大限度地发挥自己的潜能。目前集团内部正在进行的培训项目有100多项，涵盖研究与开发的各个领域，其中我们特地从总部引进了“卓越软件工程”部门（Engineering Excellence Group），通过丰富的培训项目提高我们工程师的实践技能，提升我们工程进展的效率和产品开发的质量。我们正在为每一个职位建立职业发展模型（Career Stage Profile），帮助我们的每一个员工在不同的阶段制定和实施职业发展规划。而名为“Maco  Polo”的轮岗计划，则是邀请雷德蒙德总部的资深技术专家来中国工作一段时间，“传道、授业、解惑”。此外，我们还有面向每个员工的“Mentorship”制度，通过经验丰富的员工来担任“导师”，为我们培养了一批又一批的后起之秀，这对我们未来的成功至关重要。

此外，还要为人才提供潜能爆发的环境、过程及必要的“刺激”。微软中国研发集团内开放、自由、平等的氛围，是一个能让研发人员安心去做“可以记一辈子的大事”的地方。同时，在集团各机构工作也需时刻面对压力和挑战，因为团队之间已形成了你追我赶、不甘人后的进取氛围。

3. ΔV • ΔP≥α

鼓励创新，允许失败。创新而不因循。

“粒子的动量与位置这两个变量的乘积大于某个常数”——海森堡测不准原理是量子力学中最重要的理论之一。微软中国研发集团将“测不准理论”引入到管理和文化中。ΔV和ΔP两个变量分别代表研发集团项目目标的准确度和风险度，所得出的乘积便是机构或团队发展的速度。

在确定发展目标和评估研究课题时，微软中国研发集团旗下不同职能的机构就会根据其自身的业务特点而在发展速度与风险度之间权衡一个最佳点。比如在研究院，我们强调“鼓励创新、允许失败”。选择课题时，我们鼓励员工去开掘那种难度极大、风险莫测，但可能给公司、给用户带来巨大利益的项目，因为投入大、风险大，成功后的影响也大。而对于产品开发部门，则更倾向于风险相对较小的项目。当然，无论是企业确定发展方向，还是研究机构评估技术课题，都应该把握一些基本原则，即确保项目是有用的、一流的、主流的、相关的。

微软中国研发集团希望旗下各机构能够在一种“创新而不因循”的机制之下不断健康发展，创造全新的技术和产品成果，最终孵化出深刻影响公司未来及全球用户体验的产品，向全世界展现中国的创新智慧。

4. 1+1≥3

有关企业的内部交流及合作，我认为，只有在1+1≥3（或者说“多赢”）的前提下，才是有价值和有必要的。

微软中国研发集团是由本土高校培养的中国精英、海外归国华人学者及外籍技术专家构成的“多国军团”，而在创新实践时，研发集团员工又与微软雷德蒙德总部产品部的同事以及分布于其他国家的微软员工沟通协作，造就了研发集团独有的内部合作环境。我们强调“融中外、弃劣扬优”，让不同文化背景下成长起来的微软中国研发集团员工都能够互信无疑、合作无间。

另一方面，微软中国研发集团的诞生，标志着微软在华研发资源的完全整合。随着一个由基础研究、技术和产品孵化、产品开发和战略合作所组成的、前所未有的完整研发创新产业链的形成，今后，集团旗下各职能机构之间的合作必然会越来越多样、越来越广泛、越来越深入。在这种趋势下，“1+1≥3”理所当然地成为了合作的一大必要前提。我们希望微软中国研发集团旗下各机构在将创新灵感转化为技术成果、将技术成果转化为实际产品的整个流程中能够坚持“多赢”（对合作各方、对用户、对产业）的理念，从而使每一次合作都可释放出最大化的能量、创造出多元化的价值。

5. △S>0（封闭系统，自发过程）

我们希望构建一个开放的、共赢的IT产业生态圈（Ecosystem），和全球范围内（特别是中国）的学术界、企业界合作伙伴协力创新，共同分享资源、经验与成果。

1850年，德国物理学家鲁道夫•克劳修斯（Rudolf Clausius）提出“热力学第二定律”的定性表述；15年后，他又首次引入了“熵”的概念。作为19世纪最伟大的科学发现之一，热力学第二定律说明：随着时间无限推移，封闭系统中的状态逐渐倾向于无秩序，熵趋于无限大，有规律而可用的能量趋于无限小，最终归于熵寂死的混沌。

IT企业也是这样。在全球技术共享化的今天，任何可能导致闭塞和封锁的举动都会让企业或机构无法辨识未来的机遇或危机，延缓前进的步伐。“零和”的自私心态只能让一个企业走向没落。因此，微软中国研发集团致力于构建一个开放的IT产业生态圈，令我们的研发人员总能在第一时间了解到其所在领域内的最新创新成果，开拓眼界、增强学术素养，以加速他们的成长。另一方面，微软中国研发集团旗下各机构还将积极与中国、亚太乃至国际范围内的IT产业同仁协力创新，共同分享资源、经验与成果。例如，向有需要的国内外企业提供技术授权；帮助合作伙伴寻找商业机遇，向他们移植微软的创新流程，培训富于研发经验、谙熟流程管理的员工等。

合作共赢是微软中国研发集团的重要发展战略。我们成立了战略合作部，通过技术授权、软件外包、人才培养等方式，把与中国信息产业的合作进一步向纵深推广。此外，在业务重点上，除移动与嵌入式技术、数字娱乐、互联网服务及服务器与工具四大领域之外，我们更把面向中国这一新兴市场的产品开发作为发展方向，希望能够通过与中国信息产业的紧密合作，真正的“在中国创造，为中国创造”。

IT产业的技术更新速度极其迅速，对于微软中国研发集团，秉持共赢思路、追求与所在区域产业的共同繁荣也就意味着更多的生机、更多的可能，无论对管理、经营还是文化来说都是一样的。

在微软中国研发集团独有的管理与文化氛围之中，我们正与每位员工一道，共同为早日实现成为“微软全球技术研究和产品开发的核心研发基地”的目标而携手努力。

作者简介：

张亚勤， 现任微软公司全球资深副总裁、微软（中国） 研发集团主席、微软（ 中国） 有限公司董事长， 负责微软公司在亚太地区的研发、技术战略和业务。

转载个网上的解决方法：

1、复制一个非WIN7系统下的.NET 2.0的文件，这个文件位置在“C:\Windows\Microsoft.NET\Framework\v2.0.50727\Microsoft.NET\Framework\v2.0.50727\System.dll ”，嫌麻烦的可以直接附件，将这个文件放到桌面备用。
点击这里下载文件

2、建立“C:\Program Files\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\Lib”这个目录，然后把刚才的system.dll复制进来。

3、 修改VpxClient.exe.config文件，在最后的</configuration>之前，加上以下内容

<runtime>
<developmentMode developerInstallation=”true”/>
</runtime>

Jack Milunsky将常见的延迟归为以下几类：

• 项目批准过程——开发人员坐等项目得到批准，由此造成时间和金钱的浪费。
• 等待需求的正确优先级——这样工作才能开始推进。
• 等待可用的资源——这常常标志着组织需要反省自己是不是承接了太多工作。
• 变更批准流程——该流程本身就是浪费。如果发生次数太多，就该考虑缩短sprint长度了。
• 在制品增加——在制品越多，开发人员要想将代码发布到生产环境，要等待的时间也就越长。
• 客户签收验收测试时的延迟——不仅在这方面，还包括让客户解决需求问题、提供演示反馈等方面。

Jack提到：在sprint之间也有很多延迟。团队应该认真投入精力，识别并根除这些延迟。他建议：

必须保证backlog得到正确的“看护”。要有一个高效的产品负责人，他能理解市场和客户。你还需要写得很好的用户故事。要尽早从开发人员那里得到估算，这样产品负责人才能在规划会议之前做出决策。这都是为了“防‘延迟’于未然”，保证在所有的转换点上，工作都能得到顺利交接。把这个端到端的过程勾画出来，识别出各个转换点上的延迟，这样做很有价值。

Wouter Baars也提出了IT项目延迟最主要的几个原因，其中包括：

• 画蛇添足——团队花费太多时间去增强客户没有要求的功能。
• 忽略质量控制——时间压力有时会让程序员或项目团队有意跳过测试过程。相对其减少的延迟，这常常会导致更多延迟。
• 同时开发多个项目——任务切换会招致更多问题，而不是解决问题。
• “一劳永逸”症状——试图将一种现有的解决方案用在任何新问题上。
• 平庸的人员素质——人员在技术或流程方面的能力不足会导致多个层面的延迟。
• 客户无法实现承诺——当客户无法在他们必须参与的工作中及时响应时，项目会陷于停滞。
• 客户和开发人员之间的关系紧张——如果项目进展不顺利，“不和谐”会导致更多延迟。这会破坏彼此之间的信任感，影响工作气氛。

Robert Neri提出另一个造成延迟的有趣原因，他指出：企业中敏捷实施的差异可能导致延迟。他提到：

我们常常遇到这种情况：支持部门无法做到项目sprint那么快的速度，因此会造成敏捷项目延迟。类似地，非敏捷项目难以和敏捷项目整合。

因此，如果你的敏捷项目延迟了，看看是不是由于上面这些常见的原因。一旦你识别出了根源，赶紧想办法解决才是明智之道。这会去除项目中最大的一个浪费。

（From InfoQ）

许多食客在吃火锅时，往往追求鲜美嫩滑而将食材稍稍一涮就吃，这种饮食习惯很不卫生。较好的方式是，先将肉类、鱼类、海鲜下锅，煮到五、六分熟时再放蔬菜，锅开后再煮半分钟左右，才开始享受美味。

目前国内的畜禽、蔬菜等在生产和运输环节存在诸多不安全因素，摆上餐桌的生鲜食品往往含有病原微生物、寄生虫卵或农药残留，如果一涮即吃，有害微生物侵入人体、导致呕吐、腹泻、头痛、高烧等疾病的风险很大。为了健康，还是牺牲口感，把食物涮熟透再吃吧。

还要注意的是，蔬菜如果长时间在火锅里煮，其营养成分维生素和氨基酸等容易遭到破坏，还会失去应有的鲜味。因此，如何使火锅菜肴既保持原有风味、又不失营养，还达到卫生要求，掌握火锅“火候”可不是容易的事情。

火锅桌上，畜禽内脏类食品比较常见，这种饮食习惯也不利于健康。伴随着农药、化肥、添加剂等化学物质在食品生产、加工中的应用，动物内脏作为代谢器官所含的病原微生物和药物残留量最高，往往成为这类有害物质的“过滤器”和“贮存器”，尤其是肝肺。此外，畜禽内脏、海鲜、牛羊肉、蘑菇等食材由于含有大量嘌呤类物质，容易造成尿酸在血液中沉积，引起冬季“痛风”。

最好的办法是，吃火锅时，注意荤素搭配，多吃些蔬菜、豆腐、白莲等维生素含量高的食物，不仅能够消油化腻，还能清凉、去火、解毒，是人体调补的“良药”。
由于动物内脏、肉类、海鲜等食材所含的嘌呤类物质在汤中能够充分溶解，过量饮用老汤容易造成嘌呤沉积，经肝脏代谢成尿酸，使肾功能减退、排泄受阻，诱发或加重痛风。所以吃火锅时应多喝水，以利尿酸的排出。

喜欢喝汤的朋友也要趁早，时间涮得越久，汤中所含的有害残留物，如亚硝酸盐的含量就越高，由此患病的可能性就越大。不过如果是使用了现在国际上比较流行的酵母抽提物YE作为火锅的调味料就不一样了，不但味道更鲜美，而且煮多久也不会产生亚硝酸盐。

每年入冬后，“一热当三鲜”的火锅文化正当道，口腔疾病患者的数量也会比其他季节多出15%以上。 通常，火锅浓汤的温度可达到120℃，如果取出即吃，很容易烫伤口腔、舌部、食道或胃黏膜。患有口腔黏膜白斑、扁平苔藓等口疾的人，复发机更会高出数倍，严重时还会诱发食道癌。

此外，常吃烫食，还会破坏舌面味觉系统，降低赏味机能，长此以往还会影响食欲，诱发牙齿和上消化道疾病。因此，牢记“心急吃不了热豆腐”的老话吧，食物凉一凉再吃更健康!

羊肉和醋不要共食。羊肉火热，益气补虚，宜与凉性或甘平性菜品搭配;醋则含有蛋白质、糖、维生素、醋酸及多种有机酸，其性酸温，消肿活血，应与寒性食物配合。

喝白酒时不宜吃牛肉，因为牛肉甘温，补气助火;白酒大温，与牛肉搭配则如火上浇油，容易引起牙龈发炎。

涮萝卜不要吃木耳，二者一起食用会导致皮炎;土豆是火锅中很受欢迎的蔬菜，但如果搭配香蕉作为餐后水果，可能会导致面部生斑。

菠菜中含有草酸，会妨碍食物中钙、铁的吸收，最好不要长时间和其他食物一起涮，略焯一下就可以了。

不要贪图凉快喝啤酒。因为火锅汤中的嘌呤物质在体内会转化为尿酸，而啤酒则会把尿酸推到人体关节或软组织，导致痛风，严重时还会引起肾结石和尿毒症等并发症的发生。此外，冷热交互的食用方式，也容易使肠胃道受损。

患有糖尿病、高血压、高血脂的病人要少吃虾饺、肉丸等油脂含量大的食物;肾病、高血压患者则要少饮火锅热汤;有胃肠疾病的人，应注意厚味调味料(如沙茶酱、辣椒酱等)的刺激性。

如果对某一种或几种技术非常感兴趣，并且能够持续钻研，经过一定时期的积累，你可以逐渐成长为专家级程序员。专家级程序员对于所掌握的专业技术的熟练程度非一般程序员能及，各类常见编程问题在他们手中都能迎刃而解，可以说这类专家“越老越值钱”但是这类专家也有一定的风险性：随着经验的增加和年龄的增长，这些人的工资会越来越高，当公司改变技术路线而不再需要专家级程序员所掌握的专业技术时，或者想降低做事的成本，他们就可能面临失业或者另找工作的局面。

资深培训专家也是个不错的发展方向。成为培训专家，不仅需要深厚的技术功底，同时还要具备优秀的沟通和表达能力，因为他们的主要工作不再是研发某种技术，而是传播技术知识。这条路很宽，有一些优秀的技术培训师除了担任本职工作，还会兼职到大学里讲课。虽然培训专家的技术可能达不到专家程序员的水平，但是工作内容相对更为丰富，接触的人也更多。

成为公司的技术总监是很多程序员的梦想。这条路线是从初级程序员成长为高级程序员之后，以做项目为工作重点，进而发展成项目经理、开发经理，最终成为技术总监甚至公司副总裁。这些程序员走的是技术管理路线，从做项目开始，逐渐积累管理经验，然后成长为优秀的技术管理者。技术总监在公司甚至技术界的影响力非同一般，对于那些有志于成为公司领导层的程序员，是个很大的诱惑。但是权力大、管的人多，就意味着更大的压力，技术总监不仅要保持对新技术的敏感，还要抽出精力做管理。比起成为纯技术专家，这条路也许更为艰难。

还有一些程序员职业发展的终点是总架构师、总设计师。这类程序员的兴趣，不是某种特定的技术，而是偏重对软件产品或者软件应用项目的设计。如果将软件项目开发团队比作一个乐队，那么程序员就相当于一名乐手（比如小提琴手、长笛手等），他们负责将自己的乐器演奏好；项目经理是乐队指挥，负责指挥和协调这个乐队的配合；架构师则相当于作曲家。从入门的架构师开始，逐渐成为资深架构师乃至总架构师。如同历史上伟大的作曲家，杰出的架构师能够在各种软件中谱写出旋律优美的“曲子”。

另外一些程序员心怀创业的理想，等到自己有了一定的技术积累，再掌握一些市场需求以及管理方法，他们会开始创业之路。一旦成功，这类人的影响力会非常大，像Google和雅虎的创始人，都是技术创业的成功典范。但是这条路也是最艰辛的，有句话叫做“不当家不知柴米贵”不亲自创业的人也很难体会它的艰辛。创业涉及方方面面，稍有差池就会功亏一篑，投身创业的程序员并不少，但是真正能成功的少之又少。踏上这条路不仅需要过人的勇气和魄力，更需要坚韧不拔的毅力，以及深度的商业智慧，再加上市场机会，才能够赢到最后。

很多程序员会走上技术支持路线，进而发展成为精通业务的技术和行业咨询专家。这类程序员会在成为高级程序员之后加入销售团队，直接面对客户，负责技术层面的问题。如果对某一行业（比如银行、电信）非常熟悉，久而久之，就成为精通这个行业技术的专家；如果对于某一类解决方案（比如ERP、CRM、SCM）非常擅长，就可以发展成为跨行业的技术专家。

还有一部分程序员会成为IT专栏作家和自由职业者。这些人通常对写作比较感兴趣，文字表达能力也不错，他们会将自己从事技术工作的内容或心得写出来，然后发表文章赚取稿费。只要对技术足够精通，这类人是很受杂志欢迎的。在北美还有一种自由职业者叫做合同工，就是不定期的承接项目，在项目开始前签订协议，项目完成后结束合作。虽然这种职业目前在中国还不太多，但是其自由性对于很多程序员来讲，也非常有吸引力。

上文提及的若干条路，程序员可以根据自己的兴趣进行选择，但是一般来说，无论走哪条路，都有一个前提条件：从初级程序员进阶为高级程序员。因为在这之前，你甚至没有选择的机会。从初级进阶到高级，通常需要2~5年的时间，因个人素质而异。大家都说，程序员要耐得住寂寞和枯燥，年轻的程序员更要克服浮躁的心态。在职业生涯的起步阶段，很多人总会摸不着头脑，这时一定要静下心来，多向资深程序员求教，慢慢熟悉技术、熟悉开发流程和行业。有时你会感觉掉进了一个知识海洋，身边全是陌生的事物，很难抓住。所以就更要四处探路，逐渐寻找到方向，在寻找中进步。

成功进阶为高级程序员，也并不意味着前途一片光明。如果说从初级到高级需要的是学习，那么从高级到专家，需要的是不断地尝试和坚持。比起前一个阶段，这个过程更为漫长，通常需要5~8年。在这期间，因为有了之前的积累，并且已经取得一定的成就，人会更加自信，同时也会更加彷徨，有一个问题会时常盘旋在脑中：将来的路到底要怎么走？这时就可以利用自己所积累的资源，多做一些尝试，尝试不同角色、不同的项目，与不同的客户打交道，时间长了，自然会找到最适合自己的发展方向。

总结起来，初级程序员和高级程序员时期，都属于职业生涯发展的第一阶段，我们可以称之为黄金时期。这阶段程序员的年龄在20~35岁之间，因为年轻，所以更善于学习，而且体力充沛，很多走过这个阶段的程序员有过通宵工作的经历。在这个时期，你有大把的时间学习提高，为将来的事业打下坚实的基础。而一旦超过了30岁，无论从体力还是精神上，都会有所改变，从30~40岁是转型时期。这时的程序员（很多人已经不再编程）已经明确了自己的发展方向，并且向着目标努力，让自己有所建树。40~60岁是专家时期，至此，一名优秀的程序员会彻底实现“破茧成蝶”的愿望，成长为专家。

程序员的职业很精彩，同时也很艰苦。享受高工资，掌握最新的技术，有可能成为创业成功的富豪，甚至有机会改变人类的生活方式（例如互联网浏览器的开发、电子商务的应用、手机短信等）这就是别人眼中程序员的生活，也许正因此，每年都会有很多新人加入这个庞大的队伍，体验向往已久的精彩生活。但是大多数人却忽略了光鲜背后的艰辛，高工资的代价是工作强度高，学习新技术的代价是工作压力大，成为富豪的代价是心力交瘁，而若想改变人类的生活方式，那就要耐得住日复一日的枯燥和寂寞。酸甜苦辣都要自己品尝，程序员的发展道路有很多条，就看你怎么选。

IBM 软件集团大中华区总架构师  寇卫东
《程序员》杂志0811期

2.      SDemo 我个人比较喜欢用这个工具，可以将操作录成EXE文件，并回放出来。这样就避免了那些偶尔才出现的Bug

• Log on B
• Configure
• Log out
• Log on A
• Test

2. 初级自动化人员（直接把手工case转成自动化）

• Set autologon B
• Set autorun
• Record test status: 0
• Logout
• Check status

if(status==0)
{
Configure
Set autologon A
Record test status:1
Logout
}

if(status==1)
{
Test
}

这个级别的人，需要懂得脚本编程，需要懂得系统设置，autologon and autorun。

3. 有一定经验的自动化人员（改变手工测试case以利于自动化的更简单，可靠的实现）

• 不需要log out and log on

• 利用Windows命令Runas

• 用高级语言调用Runas

• 利用重定向来输入Password

这个级别的人，需要懂得高级语言，重定向，Windows系统命令Runas

4. 中级自动化人员（具有更丰富的开发经验，可以用程序代替UI和系统命令）

• 不需要Runas命令
• 利用.NET的Process对象
• 用B的身份生成一个Process来进行配置工作

这个级别的人，要比较熟悉高级语言，比较熟悉高级语言的类库，懂得操作系统的内核基本概念

5. 高级自动化人员（精通高级语言，精通操作系统内核）

• 不需要多生成一个进程
• 用本线程impersonate用户B
• 利用.NET WindowsIdentity 对象
• 必须要调用Windows API，LogonUser

这个级别的人，要精通C/C++和Java，C#等高级语言，精通Windows内核的知识和Windows API

从以上的例子可以看到，针对同一个test case，不同的测试人员，从手工到高级自动化，由于自己知识面的原因，会设计出非常不同的case出来。越高级的自动化越灵活，稳定，可靠，也更需要掌握更多的开发和内核的知识。因此，我们看到很多人在强烈的否定自动化，你先看看他到底在哪个层次中。越下边层次的自动化人员，由于技术的原因，碰到的问题会越多，能解决的问题却越少，因此对自动化的抱怨也就越大了。这些都是可以理解的，不过以此来否定自动化，我觉得还是不太应该，毕竟自己技术还不过关。

• 通用搜索
  • Google 不用我多说了把
  • 百度 我一般比较少用，更多是用百度知道
• 知识搜索
  • 中文维基百科
  • 百度知道 百度推出的知识问答，因为时间相对较早（当然是指国内），所以内容和活跃程度相对较高
  • 天涯问答 天涯和谷歌（注意不是Google）合作推出的问答社区，貌似在愚人节还推销了一把，弄了个“谷歌人肉搜索”出来，有点猫扑的味道……
• 电视节目预告搜索
  • 电视猫
  • 搜视网
• 单词搜索
  • Dict 这个是英译英的词典，数据库很多，也比较专业
  • iCiba 爱词霸，不用说了吧，金山词霸的在线版，iCiba的社区还是不错的，里边有很多有用的文章
• 交通搜索
  • 丁丁地图
  • 谷歌交通搜索 用的是MapABC的地图数据，只有行车路线搜索，大家没有车的就别去浪费时间了
  • Microsoft Live Search交通
  • MapABC地图搜索
  • 搜狗地图 这个我用的就更少了，他们家的东西我只用搜狗拼音，还得装的时候很小心:(
  • 城市吧 特色是有想Google Map的实景地图，没事的时候玩一下还可以，但是拍摄的地点比较少，而且对网速有一定要求
• 旅游搜索
  • 游多多 这个我还是比较常去的，想出去玩的时候，或者没事的时候上去看看别人的游记还是挺好的
  • 搜驴网 上边能搜的东西挺多，图像、酒店、线路、机票和交通都可以搜
  • 途牛 这个里边资料也挺多，没事的时候翻翻，或者自助游的也可以到上边取点经
• 美食搜索
  • 大众点评网
  • 咕嘟妈咪 貌似也有很多人用这个，不过我还是习惯去哪儿吃饭以前看一下点评网
  • keko食谱搜索 做饭的同志可以来这个上边看看食谱，非常的全，而且有各个食谱的营养，也是很细，我估计看时间长了，可以去考营养师……
• 商户搜索
  • 索迪斯卡
  • 斯马特卡
• 影评搜索
  • 电影网 两个电影点评网站，我就不说什么了，我不经常看这些
  • 非非
• 折扣搜索
  • 导购网
  • 折扣网 除了上边这个网站外，这个只是用来参考
• 图标搜索
  • Free Icons 这三个网站没什么好说，下载图标的
  • Iconshock
  • 桌面美化
• 公司搜索
  • IT速查 公司评论速查，很热闹的上边，找工作的可以看看，没事的人也可以看看自己公司在别人心目中是什么样子吧
  • Findgs 这个是比较新的一个，具体我到没怎么用，反正上边有些信息，没事可以看看
• 编程方面
  • P/Invoke定义搜索 如果你想在VB或者C#还有其它的语言里边调用Window API，你会怎么做？肯定首先需要声明它们的定义，这个网站就可以搜索相应的API在各个语言中的定义形式，不用自己去转数据类型和定义各种宏了
  • Regular搜索 知道正则表达式是什么东西的，都知道这个网站是做什么的
• 心理测试
  可以看到下边的其实是一个系列的网站，各种各样的心理测试题，不要当真哦
  • 性格签 破解你的性格密码
  • 知识签 这个世界你知道多少
  • 知己签 你的好友知道你多少
  • 相貌签 别人眼中的你
• 其它搜索
  • 微软对联搜索 微软亚洲工程院的对联程序，挺好玩的
  • 剧本搜索 顾名思义，找剧本的，公司年会的时候还是用得到的
  • KeyXL快捷键搜索 这个嘛，它所收纳的快捷键比你想象的还要多一百倍
  • 铁流网火车时刻表 查火车时刻表的，当然了你也可以用极品列车时刻表
  • 豆瓣书评 大名鼎鼎的豆瓣，去找你喜欢的书吧
  • 问天网天气预报 中央气象局权威预报，可以看5天的预报
  • 小游戏搜索 非常多的Flash小游戏，无聊的时候打发一下时间吧
  • 射手网字幕搜索 在网上下载到比较新的大片，又没有字幕怎么办？总不至于删了再重新找一个下吧。来这里找找吧，9成的新片都可以在这里找到字幕（注意字幕和你下载的电影的压缩版本要对应）
  • 八文网文档搜索 写论文的朋友可以上去看看，有很多文本格式的资料，真的很多

在39码中，六个“字母”是一个数字。他们看起来是：

0 = 00-110
1 = 10-001
2 = 01-001
3 = 11-000
4 = 00-101
5 = 10-100
6 = 01-100
7 = 00-011
8 = 10-010
9 = 01-010

另外，每一个正规的39码的开头有一个星号（*）。

* = 0-0110

结尾会根据不同的编码系列有不同，39码系列通常会使用星号结尾。

具备 P3P 能力的浏览器具有一些可供您选择的默认选项。 或者您也可以通过回答问题的方式（例如您愿意分享哪些数据、愿意接受哪些类型的 Cookie 文件）自定义您的设置。 当您在 Web 浏览时，这个软件会判断您的隐私权偏好选项是否与网站的数据收集做法匹配。

具备 P3P 能力的浏览器会特别注意 Cookie。 Cookie 是留存在您计算机硬盘上的一段文本，它可以让 Web 应用程序以个体方式对您响应。 通过收集和记忆您的偏好选项信息，Web 应用程序可以根据您的需求、喜欢什么、不喜欢什么等来修改它的运作模式。 使用具备 P3P 能力的浏览器，您可以选择是否接受各种类型的 Cookie，例如阶段性（暂时性）、永久性、在指定的网域之内或之外（第三方），以及有没有特殊的 ”P3P 精简政策” (P3P compact policy) 文件。 精简 P3P 政策描述了给定 Cookie 的属性。

对于上面的只是， Internet Explorer 就体现在本文第一张图上对浏览器隐私的设置上。以及进一步的设置中，图四中，我们选中站点，摘要按钮就可以用了，点击摘要按钮可以看到隐私策略调整窗口。
从技术上看，P3P包括了两个组件：一个放在服务器端；另外一个放在客户端，形成一个用户代理。当用户登陆网站的时候，服务器端的组件根据网站的要求，会自动生成XML语言形式的用户个人处理策略，这就像是贴在商店橱窗外的公众告示，而客户端的组件就将这个“公众告示”提供给用户。

上面例子中隐私策略中 CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR 的意思是啥。
Fiddler可以方便的知道，在Fiddler 中我们可以看到如下信息：

Response sets a cookie:
    Set-Cookie: ghj=aaaa_2009/11/27 15:55:56_http://a.net/WebApp_P3P/a_setcookie.aspx; domain=.a.net; expires=Fri, 11-Dec-2009 07:55:56 GMT; path=/

P3P Header is present:
    CP="CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR"

Compact Policy token is present. A trailing "o" means opt-out, a trailing "i" means opt-in.

CURa
Information is used to complete the activity for which it was provided.

ADMa
Information may be used for the technical support of the Web site and its computer system.

DEVa
Information may be used to enhance, evaluate, or otherwise review the site, service, product, or market.

PSAo
Information may be used to create or build a record of a particular individual or computer that is tied to a pseudonymous identifier, without tying identified data (such as name, address, phone number, or email address) to the record. This profile will be used to determine the habits, interests, or other characteristics of individuals for purpose of research, analysis and reporting, but it will not be used to attempt to identify specific individuals.

PSDo
Information may be used to create or build a record of a particular individual or computer that is tied to a pseudonymous identifier, without tying identified data (such as name, address, phone number, or email address) to the record. This profile will be used to determine the habits, interests, or other characteristics of individuals to make a decision that directly affects that individual, but it will not be used to attempt to identify specific individuals.

OUR
We share information with ourselves and/or entities acting as our agents or entities for whom we are acting as an agent.

BUS
Info is retained under a service provider"s stated business practices. Sites MUST have a retention policy that establishes a destruction time table. The retention policy MUST be included in or linked from the site"s human-readable privacy policy.

UNI
Non-financial identifiers, excluding government-issued identifiers, issued for purposes of consistently identifying or recognizing the individual. These include identifiers issued by a Web site or service.

PUR
Information actively generated by the purchase of a product or service, including information about the method of payment.

INT
Data actively generated from or reflecting explicit interactions with a service provider through its site -- such as queries to a search engine, or logs of account activity.

DEM
Data about an individual"s characteristics -- such as gender, age, and income.

STA
Mechanisms for maintaining a stateful session with a user or automatically recognizing users who have visited a particular site or accessed particular content previously -- such as HTTP cookies.

PRE
Data about an individual"s likes and dislikes -- such as favorite color or musical tastes.

COM
Information about the computer system that the individual is using to access the network -- such as the IP number, domain name, browser type or operating system.

NAV
Data passively generated by browsing the Web site -- such as which pages are visited, and how long users stay on each page.

OTC
Other types of data not captured by the above definitions.

NOI
Web Site does not collected identified data.

DSP
The privacy policy contains DISPUTES elements.

COR
Errors or wrongful actions arising in connection with the privacy policy will be remedied by the service.

Validate at: http://www.w3.org/P3P/validator.html
Learn more at: http://www.fiddler2.com/redir/?id=p3pinfo

P3P这个Http头的写法有很多组合，自己写很痛苦，通过下面这个连接 http://www.w3.org/P3P/details.html 您可以找到一些P3P策略生成器软件包。（虽然如果在Google上搜索，您会发现更多搜索结果，但提供免费使用的好象只有IBM的P3P策略编辑器IBM"s P3P Policy Editor。）

注意：

Visual Studio 自带的开发站点（ASP.NET Development Server）是不支持这个功能的，它会报错误：This operation requires IIS integrated pipeline mode. 

参考资料：

用P3P解决第三方cookie存取的问题
http://www.javaeye.com/topic/94336

IBM P3P Policy Editor
http://www.alphaworks.ibm.com/tech/p3peditor

How to configure IIS to use Platform for Privacy Preferences (P3P)
http://support.microsoft.com/kb/324013/en-us

How to Deploy P3P Privacy Policies on Your Web Site
http://msdn.microsoft.com/en-us/library/ms537341(VS.85).aspx

Add a Custom HTTP Response Header (IIS 7)
http://technet.microsoft.com/en-us/library/cc753133(WS.10).aspx

私有参数选择平台——P3P（关于Cookies）
http://www.yxl.cn/Info/20060302,212041,5095.html

使用P3P
http://welcome.hp.com/country/cn/zh/privacy/p3p_popup.html

用P3P header解决iframe跨域访问cookie/session
http://blog.csdn.net/Hashxu/archive/2009/01/02/3684402.aspx

利用P3P跨域传COOKIE
http://hi.baidu.com/thinkinginlamp/blog/item/5e2a02084f1dafd163d9865f.html

使用p3p解决Iframe中cookie跨域问题
http://blog.ntsky.com/p3p-iframe-cookie.html

通过设置P3P头来实现跨域访问COOKIE
http://blog.c114.net/html/38/193738-35549.html

P3P
http://www.hudong.com/wiki/p3p

Cookie, iframe 与 P3P 的那点事儿
http://www.dbanotes.net/web/cookie_p3p.html

Firefox Help:  Firefox"s Cookie Options
http://mozilla.gunnars.net/firefox_help_firefox_cookie_tutorial.html

ie session丢失 ie中iframe丢失问题
http://wangzi6hao.javaeye.com/blog/531524

欧拉先是分析了在选择技术方案和物理架构中的几个常见问题，以来解决如何提高开发效率，使平台具有高性能、高负载性的问题：

开发语言和数据库：我个人觉的最关键是你和你的团队最擅长的开发语言和数据库是哪个，古语有云：“工欲善其事,必先利其器！”，趁手的开发语言和数据库有助于事半功倍。试想如果你选择了一个并不很熟悉的语言，也许这个语言和数据库在基础性能上的确比你掌握的语言好，但是在研发过程中学习曲线肯定长。

成熟框架还是自己实现：我个人的一些经验是，尽量使用开源的成熟框架，因为平台研发初期使用成熟的开源框架，能提高开发效率，并且在质量上有保证。我曾经接手过一个平台的改版，框架是前面开发人员自己写的，里面的一些设计思想不是很成熟，导致平台在负载增高后性能很差，整改起来很麻烦。

除此之外，Web Server/DB Server/Cache Server的选择也是很重要的一点，欧拉认为这一部分一定要使用具有前瞻性、易配置、能监控和维护的产品，并提出几个选型的标准：丰富和深入的配置选项、基于高并发模型、支持负载均衡和请求分发、高效的缓存机制、实时的状态监控机制等。而对于操作系统的选择，则要稳定安全、易管理和维护、易监控等。对于物理架构，即服务器的搭建方式，欧拉同样认为前瞻性是非常重要的：

平台初期的话，我想大部分访问量都不高，Web Server/DB server/Cache Server放在一台服务器上都没问题。但是自己心里最好能预估一下这个平台会发展到什么样的规模，在做架构设计的时候，按照事先预估的来决定怎么做物理架构，并为以后的架构升级做准备。说到这里，想到前百度架构师雷鸣说过的一句话，当你的会员数达到目前的5倍或10倍的时候，架构就要升级。

在实质性的研发过程中，需要注意的是平台网站研发的模式和传统IT项目研发的不同，以前是开发过程中要和客户、需求人员等打交道，而现在关注的是产品设计。对于平台网站研发项目的管理，欧拉推荐使用敏捷开发方法，通过设立短的发布周期进行迭代开发，并使用JIRA等成熟的项目管理系统进行管理等。对于团队研发需要注意的地方，欧拉总结如下：

• 合适的开发工具；
• 如何控制代码质量；
• （根据）需要引入新框架；
• 知识总结和培训。

对网站研发过程中的架构优化、存储和搜索等关键点，欧拉也分享了自己的经验，比如对于网站速度慢，而却又不知如何下手的问题，欧拉提出的解决方案是：

我的经验是从数据开始，从最外围开始画圈，找到源头。先从外围开始收集日志，比如access_log访问日志或sql_log数据库操作日志，找出访问最多的10条日志和执行时间最长的10条日志，然后根据日志去反查到底是什么引起的操作，然后一条条的解决。如果解决不了，那么就考虑重构。

在文章的最后，欧拉来分享了一些他认为有价值的资料，比如新型的大型BBS架构（Squid+Nginx）、Nginx图片服务器的架构方案、校内相册发展过程及核心技术分析爆料、架构设计贵在务实、大型网站架构不得不考虑的10个问题等。

摘自：http://www.infoq.com/cn/news/2009/10/how-to-design-platform-websites

从语法范畴上来讲，“FUCK”使用灵活，可以用作多种形态。它既可以被用作及物动词（Mary fucked John.玛丽上了约翰）又可以被用作不及物动词（John was fucked by Mary.约翰被玛丽上了）。它可以用作行为动词(John really gives a fuck.约翰对这事儿真他妈的上心), 被动式动词(Mary really doesn't give a fuck.玛丽根本就不在乎。)。用作副词（Mary is fucking interested in John.玛丽简直被约翰迷疯了），或者做名词（Mary is a terrific fuck.玛丽真他妈的撩人）。它还可以做形容词（Mary is fucking beautiful.玛丽太她娘的美了）或者感叹词（Fuck! I'm late for my date with Mary靠！跟玛丽约会我又迟到了。）它甚至可以用作连词（John is ugly, fuck, he's also stupid.约翰长的丑还他妈的那么蠢）。如你所见，很少有单词像“Fuck”这么神通广大。
除了语法的灵活性多样性，这个带有浓厚性色彩的单词还可以用来描述许多其他情形。

1）       惊讶—你丫在这儿干吗呢？（“What the fuck are you doing here?”）
2）       欺诈—我他妈的被卖车的给骗了！（ “I got fucked by the car dealer.” ）
3）       辞职—去他的吧。（“Oh, fuck it!” ）
4）       麻烦—这回我完蛋了。（ “I guess I'm fucked now.” ）
5）       挑衅—CAO！（“FUCK YOU!” ）
6）       厌恶—我靠！（“Fuck me.” ）
7）       困惑—这他妈的到底…?（ “What the fuck...?” ）
8）       困难—我真不明白这倒霉生意！（ “I don't understand this fucking business!” ）
9）       绝望—又他妈的…..（ “Fucked again....” ）
10）     开心—我他妈的太高兴了。（ “I fucking couldn't be happier.” ）
11）     沮丧—这他娘的到底怎么回事？（“What the fuck is going on here?” ）
12）     迷路—我们他妈的到底在哪儿呢？（ “Where the fuck are we?” ）
13）     怀疑—真他妈的难以置信。（“UN-FUCKING-BELIEVABLE!” ）
14）     报复—小心我揍死你！（ “Up your fucking ass!” ）
15）     拒绝—我他妈的才不干呢。（ “I didn't fucking do it.” ）
16）     茫然—我他妈的什么都知道！（“I know fuck-all about it.” ）
17）     冷漠—到底是他妈的谁搞成这样的？（ “Who really gives a fuck, anyhow?” ）
18）     问候—你他妈的最近怎么样啊？（“How the fuck are ya?” ）
19）     疑惑—你他妈的到底谁啊？（ “Who the fuck are you?” ）
20）     惊恐—我们快点儿离开这倒霉地方吧。（“Let's get the fuck out of here.” ）
21）     方位—滚一边去！（ “Fuck off.” ）
22）     敬畏—你他妈的到底是怎么做到的？（ “How the fuck did you do that?” ）

它可以做来描述器官—“他就是一混蛋。”（“He's a fucking asshole.” ）可以用在
时间中—“都他妈的5点半了。”（“It's five fucking thirty.”）
也可以用于职场—“这倒霉活儿我到底要怎么干啊？”（ “How did I wind up with this fucking job?” ）可以家事—“个王八羔子”（ “Motherfucker.” ），也可以国
事—“克林顿去死吧！”（ “Fuck Clinton!” ）
历史上，众多名人也对它爱不释口：
那到底是他们的什么玩意儿？（“What the fuck was that?” ）-广岛市长
这些死印度人是什么哪里来的？（“Where did all these fucking Indians come from?” ）—卡斯特将军
这他妈的不是真枪吧，哈？（“That's not a real fucking gun, is it?”）—约翰列侬
他妈的谁能查出真相？（“Who's gonna fucking find out?” )—理查德尼克松
为什么那个倒霉苹果打到我了？(“Why the fuck did that apple hit me?” )—艾萨克·牛顿
靠，脑袋掉了碗大个疤！(“Heads are going to fucking roll.”)—玛丽安托瓦内特
我真该用那张倒霉地图。(“I could have used a fucking map.”)—尤利西斯
这些水都他娘的从哪里来的？(“Where the fuck is all this water coming from?” )
—泰坦尼克号船长
有没有哪个白痴能明白的？(“Any fucking idiot could understand that.” )—艾伯特爱因斯坦
这简直太他妈的像她了！(“It DOES SO fucking look like her!” )—毕加索
行了，我明白了…他奶奶的我们得筑道高墙来防御他们。(“Okay, I know... we'll build this BIG fucking wall to keep them out.”)—秦始皇
我简直不相信那是我说的。(“I can't believe I just fucking said that.” )—帕特里克亨利
小人都他妈的不得好死！(“Fucking backstabbers!” )—凯撒大帝
你想要天花板上的东西？(“You want what on the fucking ceiling?”) —米开朗基罗
吹箫而已，没他妈的干别的。（“Fellatio is not fucking!”） -- 比尔克林顿
送皮萨的死哪儿去了？（“Where is that fucking pizza guy?”）—猫王
为什么？因为就他妈的在那儿（“Why? Because its fucking there!” ）—艾德蒙·希拉里
我觉得不可能下雨。（“I don't suppose its gonna fucking rain?” ）—圣女贞德
我的屁股都他妈的被扎烂了。（“Scattered fucking showers my ass.” ）—诺亚
这次游行就像我脑袋上那个倒霉的枪眼儿一样重要。（“I need this parade like I need a fucking hole in my head.” ）—约翰肯尼迪
我他妈的到底怎么才能上天堂？（“What are the fucking chances I'm going to heaven?” ）—阿道夫希特勒
喂，你们的头巾都他妈的哪儿去了？（“Hey, where the fuck are your turbans?” ）—哥伦布对“印第安人”说

1. 拷贝TFS光盘文件到本地文件夹下
2. 下载TFS SP1并解压
3. 在cmd中执行如下命令行，将TFS和SP1合并为一个安装文件
   msiexec /a "AT"vs_setup.msi /p " TFS90sp1-KB949786.msp TARGETDIR=<自定义文件夹>
4. 打开文件夹，运行setup.exe

因为SP1中有针对SQL SERVER 2008的补丁，TFS可以正常安装了。

第一，使用Header方法设置消息头Cache-control
header('Cache-control: private, must-revalidate');  //支持页面回跳
第二，使用session_cache_limiter方法 
//注意要写在session_start方法之前
session_cache_limiter('private, must-revalidate');

补充：
Cache-Control消息头域说明
Cache-Control指定请求和响应遵循的缓存机制。在请求消息或响应消息中设置Cache-Control并不会修改另一个消息处理过程中的缓存处理过程。请求时的缓存指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if- cached，响应消息中的指令包括public、private、no-cache、no-store、no-transform、must- revalidate、proxy-revalidate、max-age。各个消息中的指令含义如下：

    Public指示响应可被任何缓存区缓存。

    Private指示对于单个用户的整个或部分响应消息，不能被共享缓存处理。这允许服务器仅仅描述当用户的部分响应消息，此响应消息对于其他用户的请求无效。

    no-cache指示请求或响应消息不能缓存

    no-store用于防止重要的信息被无意的发布。在请求消息中发送将使得请求和响应消息都不使用缓存。

    max-age指示客户机可以接收生存期不大于指定时间（以秒为单位）的响应。

    min-fresh指示客户机可以接收响应时间小于当前时间加上指定时间的响应。

    max-stale指示客户机可以接收超出超时期间的响应消息。如果指定max-stale消息的值，那么客户机可以接收超出超时期指定值之内的响应消息。

关于表单刷新

问：为什么我在点击浏览器的后退按钮后，所有字段的信息都被清空了？

答：这是由于你在你的表单提交页面中使用了 session_start 函数。该函数会强制当前页面不被缓存。解决办法为，在你的 Session_start 函数后加入 header("Cache-control: private"); 注意在本行之前你的PHP程序不能有任何输出。

补充：还有基于session的解决方法，在session_start前加上
引用:
session_cache_limiter('nocache');// 清空表单
session_cache_limiter('private'); //不清空表单，只在session生效期间
session_cache_limiter('public'); //不清空表单，如同没使用session一般

可以在session_start();前加上 session_cache_limiter("private,max-age=10800");