本文是谷歌（Google）网络分析大师AvinashKaushik在“测量的威力”系列讲座中的第一讲。在当前的经济环境下，这一系列讲座将介绍如何使你的网络营销获得成功。

这是SmashingMagazine对2008年顶尖Web设计师做的两句话访谈的第二部分。SmashingMagazine访谈的这些Web设计师多是自由职业者，他们热爱Web设计并在这个行业如鱼得水。这是访谈的第二部分。

 

一、 只复制一个表结构，不复制数据

 

 

 

...

关键字：十三个奇妙WinRAR另类技巧　　1.拒绝利用WinRAR捆绑的恶意程序　　随着人们安全意识的提高，木马、硬盘炸弹等恶意程序的生存越来越成为问题，于是那些居心叵测的家伙绞尽脑汁又想出许多办法来伪装自己，利用WinRAR自解压程序捆绑恶意程序就是其中的手段之一。　　该如何判断自解压程序是否含有恶意程序呢?只要能发现自释放文件里面隐藏有多个文件，特别是多个可执行文件，就可以判定其中含有恶意程序。用鼠标右击WinRAR自释放文件，在弹出菜单中选择“属性”，在“属性”对话框中你会发现较之普通的EXE文件多出两个标签，分别是：“档案文件”和“注释”(如图1)，单击“注释”标签，看其中的注释内容，你就会发现里面含有哪些文件了，这样就可以做到心中有数，这是识别用WinRAR捆绑恶意程序文件的最好方法。　　再告诉大家一个防范方法，遇到自解压程序不要直接运行，而是选择右键菜单中的“用WinRAR打开”，这样你就会发现该文件中到底有什么了。　　2.妙用WinRAR清洁桌面　　我们在使用Windows的过程中，桌面上免不了要增加这样那样的链接，有时为了图方便，我们就干脆把某个文件或者文件夹放到了桌面上，时间一长，整个桌面就变得“花花绿绿”的，让人眼花缭乱。其实，我们只要用WinRAR就能够轻轻松松的制作出一个“桌面清

单元测试是敏捷软件开发的一个重要组成部分。这种方法最初由KentBeck引入，现在已经深入人心在很多企业系统中使用。单元测试可以帮助开发人员降低漏洞数量，减少花费在调试上的时间，有助于开发更健壮更稳定的软件。在本篇文章中我们将介绍软件工程师都可以使用的12个单元测试技巧，适用于任何编程语言和编程环境。1、使用单元测试降低风险新手可能会问“为什么我应该编写测试代码？”的确，很多人会这样想：测试工作不是应该由进行验收工作的测试人员来完成吗？这种想法在现代软件工程学中已经没有立足之地。软件团队的目标是开发高质量的软件。无论是个人用户，还是企业用户，已经无法接受上世纪80年代和90年代充满漏洞的软件。现在你可以使用丰富的类库资源、Web服务和支持重构及单元测试的综合开发环境，在软件中再出现漏洞就没有任何借口可找了。单元测试背后的思想是，为每一个软件单元、模块和构建创建一个测试代码。单元测试让软件持续测试变得很简单；与手动测试不同，你可以轻松的重复执行单元测试。随着你的软件规模变大，单元测试部分也随之变大。每一个测试都是系统正常运行的保障。代码中存在漏洞就意味着软件具有潜在风险。通过利用一系列单元测试，开发者可以大大降低漏洞的数量，降低未经实际

在JUnit测试中，通常作为POJO的JavaBean都是一组简单的getter/setter方法，需要测试的不是这些Bean本身，而是对Bean的属性设置后，测试业务方法是否正常工作，例如，一个注册用户的类方法voidregister(Accountaccount)，需要对传入的AccountBean做初始化设置，然后，根据业务规则决定register方法是否应该执行成功或者抛出IllegalArgumentException。倘若按照常规的Unit测试，需要考虑用户输入的许多种组合，在testXxx()方法中编写模拟用户输入的代码是冗长而繁琐的，不如直接通过Swing窗口手动设置Bean的属性，然后再执行业务方法，这样，虽然引入了输入界面，需要人工干预测试过程，却大大简化了编写测试用例的麻烦。在TCK测试中，对许多UI组件的测试正是采用这种半自动的方法，因为只有测试人员本身才能看到UI测试的结果正确与否，计算机很难判断一个类似fillRect()的方法到底有没有在屏幕上正确绘制出来。基于这种思想，为了测试许多种不同输入的组合，我们决定编写一个能根据Bean的属性自动生成输入窗口的小工具，以便在Unit测试过程中，能够由测试人员手动设定Bean的属性和期望的结果，然后，继续测试。为了实现这个目的，我们设计了一个小工具，它能够实现：1．根据传入的Bean自动为每个publics

简介MRD-“市场需求文档”，是产品经理或者产品市场经理编写的一个产品的说明需求的文档。这些文档用于计划一个新产品或修正一个已有的产品，是被工程师团队开发产品时使用。在硅谷的一些软件公司，MRD仅仅覆盖high-level的功能。在这种情况下，产品经理通过创建了另一个文档-通常指的是PRD（产品需求文档）来定义更加详细的产品需求。在本文中，我用术语“MRD”泛指所有那些由产品管理和/或产品市场团队创建的，为工程师团队传达产品需求为目的的文档。MRD-“市场需求文档”，是产品经理或者产品市场经理编写的一个产品的说明需求的文档。这些文档用于计划一个新产品或修正一个已有的产品，是被工程师团队开发产品时使用。在硅谷的一些软件公司，MRD仅仅覆盖high-level的功能。在这种情况下，产品经理通过创建了另一个文档-通常指的是PRD（产品需求文档）来定义更加详细的产品需求。在本文中，我用术语“MRD”泛指所有那些由产品管理和/或产品市场团队创建的，为工程师团队传达产品需求为目的的文档。写好MRD的10种技巧（第一部分）1、从用户角度的编写从用户角度编写需求内容。使用“用例(UseCase)”和“用户角色（UserPersonas）”来达到这个。考虑用以下两种方法来详细说明你们公司正在开发的SFA（salesforceautomati

关键字：程序员测试技巧如果要写JUnit测试代码，应该从哪里开始呢？本书的第一部分为有效的使用JUnit设计和测试Java代码奠定了基础。一旦你能理解这部分介绍的技巧，并能熟练地在实际工作中应用它们，你就会永远使用下去——因为所有的测试，其实都可以分解为后面几章中将要介绍的一个或者几个技巧。问题在于，你如何在工程级的特定Java应用的代码和类结构中，认出这些简单的小模式。因此，在对付大的问题之前，让我们首先处理这些小问题。到第1部分结束的时候，你将学习到60多个重要的JUnit技巧，它们涵盖了测试的各个方面：编写、组织、创建和执行测试，还有如何维护测试数据以及如何汇报测试结果。第2、第3部分的技巧经常会用到第1部分介绍过的技巧，因此请做好随时回头查阅的准备。很快，你就会对这部分介绍的技巧非常熟悉。本章主要内容：■有关程序员测试的介绍■JUnit入门■JUnit的一些经验之谈■什么时候使用测试而不是调试我们痛恨调试程序。你抬头看看墙上的钟，发现已经很晚了，因为今天晚上还有一堆的错误需要纠正。现在已经到了“编码与纠正”阶段的纠正部分了，并且这个阶段已经持续了三个月。到了这个时候，你可能几乎已经忘记你们家是什么样的了。你现在比以前任何时候都熟悉的是办公室的四面墙

关键字：浮点数技巧陷阱--------------------------------------------------------------------------------虽然几乎每种处理器和编程语言都支持浮点运算，但大多数程序员很少注意它。这容易理解—我们中大多数很少需要使用非整数类型。除了科学计算和偶尔的计时测试或基准测试程序，其它情况下几乎都用不着它。同样，大多数开发人员也容易忽略java.math.BigDecimal所提供的任意精度的小数—大多数应用程序不使用它们。然而，在以整数为主的程序中有时确实会出人意料地需要表示非整型数据。例如，JDBC使用BigDecimal作为SQLDECIMAL列的首选互换格式。IEEE浮点Java语言支持两种基本的浮点类型：float和double，以及与它们对应的包装类Float和Double。它们都依据IEEE754标准，该标准为32位浮点和64位双精度浮点二进制小数定义了二进制标准。IEEE754用科学记数法以底数为2的小数来表示浮点数。IEEE浮点数用1位表示数字的符号，用8位来表示指数，用23位来表示尾数，即小数部分。作为有符号整数的指数可以有正负之分。小数部分用二进制（底数2）小数来表示，这意味着最高位对应着值?(2-1)，第二位对应着?(2-2)，依此类推。对于双精度浮点数，用11位表示指数，52

【CSDN编译】你在写代码之前会认真构思，然后小心翼翼地写，一遍又一遍地检查……最后当你运行的时候，你还是无法避免地发现了错误。可能是语法错误，可能是声明变量错误，可能是调用函数错误……无论怎样，都需要你一遍遍地调试。接下来我将告诉你五个提高调试能力的技巧。在正式开始之前，我先不厌其烦地解释两个词汇。第一个是“语法”：语言的规则。举例来说，pritf("HelloWorld")是错误的，正确的是printf("HelloWorld")；如果使用“for”循环：for(inti=0;i<10;i ;"HelloWorld")这也是不对的。第二个是“语义”：编程的逻辑。如果你有个数量为100的数组，for(inti=0;i<=100;i )就会产生语义错误。语义错误比语法错误更难于解决，因为语义错误不像语法错误那么明显。现在来说五个技巧：1.理解代码理解代码是五个技巧中最重要的，而且说到容易做到难。经常有程序员找我寻求帮助，然后他们面对一大堆代码不知所云。如果你不能彻底地理解你的代码，谈何找错误呢？2.休息休息如果你在一段代码中翻来覆去地寻找一个错误，个把小时过去了却仍无果……去休息休息！喝杯水，浏览浏览你最喜欢的博客，或者跑步……任何可以让你远离那段代码的活动。休息给你大脑再次寻找代码错误的机会，而且有时候会有莫名地灵感。