<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>MoDoFo.println(" &#187; 翻译</title>
	<atom:link href="http://zhangv.com/archives/tag/%e7%bf%bb%e8%af%91/feed" rel="self" type="application/rss+xml" />
	<link>http://zhangv.com</link>
	<description>Life for Idea - forever young</description>
	<lastBuildDate>Wed, 01 Sep 2010 10:44:18 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>[翻译]API设计黄金法则</title>
		<link>http://zhangv.com/archives/1544</link>
		<comments>http://zhangv.com/archives/1544#comments</comments>
		<pubDate>Mon, 02 Aug 2010 06:21:02 +0000</pubDate>
		<dc:creator>zhangv</dc:creator>
				<category><![CDATA[技术(Tech)]]></category>
		<category><![CDATA[API]]></category>
		<category><![CDATA[程序员]]></category>
		<category><![CDATA[翻译]]></category>
		<category><![CDATA[设计]]></category>

		<guid isPermaLink="false">http://zhangv.com/archives/1544</guid>
		<description><![CDATA[API设计黄金法则
原文: http://programmer.97things.oreilly.com/wiki/index.php/The_Golden_Rule_of_API_Design
API的设计通常是一项艰巨的任务,尤其当设计的API非常庞大时. 如果你设计的API将会有成百上千的用户时,你要考虑今后应该如何扩展来避免不小心把客户端的代码搞挂. 除此之外,你还要考虑用户在使用API的过程中对你的影响.如果你的API类使用它内部的一个方法时,你要记得 - 用户可以通过子类复写(override)他,而这,可能会是灾难性的. 你将不能修改那些方法,因为用户已经这样使用它们了. 你今后的内部实现将无可避免的由你的用户来决定,而不再是你.
API程序员有各种各样的方法来解决这个问题,但最简单的还是禁止用户修改API.如果你用的是Java你可能会把所有的类都声明为final,如果用C#,则声明所有的方法为sealed.无论用什么语言,你都可以通过单例(singleton)或者静态工厂方法来避免用户复写代码,或者不当的扩展和使用你的代码.这些听起来很有道理,但,真是这样吗?
在过去的10年,我们渐渐意识到单元测试是一种非常非常重要的实践,但这一实践却并没有完全被整个行业所认可. 显而易见的是,大多数情况下,为一个未经测试的类编写测试用例时总是很难.你会发现使用了API的代码和API耦合的就像是上了强力胶一样.没有办法去模拟API类的行为,进而容易的测试API和你的代码之间的交互.
经过一段时间后也许会有改善,但只有我们在开始设计API时就考虑到测试问题.不幸的是,这可能需要你(API的设计者)多花一点时间 - 不仅测试自己的代码,还要考虑用户如何测试他们的代码. 这里就引出了伟大的"API设计黄金法则": 仅仅给API写测试用例是不够的;你还要为使用API的代码写单元测试.只有这样做了,你才会在第一时间体会用户在使用你的API时进行测试时的种种问题.
让API易于测试的方法有很多.static,final和sealed并不见得是不合理的,他们有相应的使用场景.但意识到测试问题是很重要的,最好的办法就是自己去感受.一旦你这样做了,你将更加胜任各种设计挑战.
By Michael Feathers

	Tags: API, 程序员, 翻译, 设计
]]></description>
		<wfw:commentRss>http://zhangv.com/archives/1544/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>规划你的WebAPI &#8211; 安全</title>
		<link>http://zhangv.com/archives/1233</link>
		<comments>http://zhangv.com/archives/1233#comments</comments>
		<pubDate>Fri, 28 Aug 2009 02:56:02 +0000</pubDate>
		<dc:creator>zhangv</dc:creator>
				<category><![CDATA[技术(Tech)]]></category>
		<category><![CDATA[翻译]]></category>
		<category><![CDATA[openAPI]]></category>
		<category><![CDATA[REST]]></category>
		<category><![CDATA[security]]></category>
		<category><![CDATA[SOAP]]></category>

		<guid isPermaLink="false">http://zhangv.com/archives/1233</guid>
		<description><![CDATA[


  

译自“Professional Web APIs with PHP: eBay,Google, PayPal, Amazon, FedEx, Plus Web Feeds” (chapter 12)

你一定听过这样一句话“失败的计划是必定失败（Fail to plan, and you plan to fail.”对WebAPI来说，在开始一切工作之前的规划尤为重要，因为他不仅会影响到实现难度，同时会让那些使用API的开发者痛苦不堪。



通常来说，引入额外的安全层次会更好的保护你的API，但是同时需要很好的平衡这种设计对易用性的影响。时刻记得，安全即是保护你的数据，也是确保开发者的调用过程完整（通常是用“token”）。
完全开放的API
在一个完全没有安全验证机制的开放API里，首先会有一个来自外界的请求，然后系统会尝试完成并响应这个请求。
优点:

最小的使用障碍 – 既没有加密页没有验证机制，任何人都可以访问你的API。
更容易的创建分布式应用 – 登录帐户或者程序员，只要他们使用了你的API，那么程序可以分布到任何地方,而你根本无需考虑他们在哪里调用。
省心 – 如果你没有管理用户账户和开发密钥，那就可以花更多的时间在开发API本身。

缺点:

缺少控制 – 任何人在任何地方都可以调用API，尽管这是web服务的目标，但可能会在潮水般的请求涌来时失去控制。如果这些请求只是来自一部机器，还可以借助防火墙来搞定，但是如果分布很广，处理起来就会很痛苦。
没有加密 – 所有请求端和服务端的请求和响应都是对任何人都可见的。
无法接触到开发者 – 因为API的调用不存在注册过程，也就无法联络到相应的开发者。而你可以通过注册机制建立一个与开发者的一个很好的联系。比如，告知他的应用正在被误用，API有新的改动，征求改进建议等等。
误用 – 很不幸，总有一些人会利用这一点去做一些不好的事，即便你觉得这个可能性很小。

因为这些问题，完全开放的API只适用于用来请求信息，而不是发布信息 – 也就是请求的信息资源产生过程不会占用太多CPU资源。一个很恰当的例子是国家天气服务API，它只接受信息请求，并且这些请求可以全天候的缓存在服务器上。如果是需要发布信息，那么相应的验证机制要被用来识别请求者，当请求需要消耗大量CPU时，远端程序需要被识别出来，从而对发来的请求进行过滤和控制。
HTTP 验证
通过HTTP头包含中验证信息，基于Base64编码，实际上并没有加密，没有信息安全可言。
优点：

简单 — 因为验证信息是在HTTP头里，所以可以被路由器和网关处理。从而可以用硬件过滤和筛查客户端请求。从应用的角度来看，验证实际上是发生在服务器端，因此设计服务器时应该考虑到高性能和高并发的开发和测试。
对应用来说透明     -&#160; 因为是web服务器来处理验证，你可以完全不需要考虑用户登录问题。当然这只适用于请求那些于特定用户无关的信息（每个用户使用相同的请求得到相同的信息）。
易于编码 — 添加一个额外的HTTP头信息对大多数编程语言来说都不在话下。It is also    [...]]]></description>
		<wfw:commentRss>http://zhangv.com/archives/1233/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>ChromeOS是什么[翻译]</title>
		<link>http://zhangv.com/archives/1167</link>
		<comments>http://zhangv.com/archives/1167#comments</comments>
		<pubDate>Tue, 28 Jul 2009 02:08:55 +0000</pubDate>
		<dc:creator>zhangv</dc:creator>
				<category><![CDATA[技术(Tech)]]></category>
		<category><![CDATA[ChromeOS]]></category>
		<category><![CDATA[翻译]]></category>
		<category><![CDATA[google]]></category>

		<guid isPermaLink="false">http://zhangv.com/archives/1167</guid>
		<description><![CDATA[原文：http://www.tech-no-media.com/2009/07/what-chromeos-is-not.html
很多人都对ChromeOS兴奋不已，很明显有些博客言过其实。也许是该总结一下到底google的新OS是（不是）什么了。
ChromeOS是：1.是linux：如果你认为Moblin(REF)是linux内核，clutter window manager也是linux的话。那么ChromeOS以及他还没有命名的轻量级窗口管理器也是linux。如同其他linux版本一样，ChromeOS也会开源，我们可能看到其他基于ChromeOS的版本 - 正如Ubuntu基于Debian一样。
2.是为上网本设计的操作系统：有一件事可以确定，ChromeOS会根据上网本的使用模式而专门优化，这和第一台EEE PC上的Xandros OS或 gOS类似：本地预装一部分应用程序，其他应用则基于云上。最主要的不同在于：google Gears使得云应用变得更易用，用户体验更好。如果你看一下google ChromeOS的合作伙伴，你会注意到他们大多在上网本市场有着很好的表现。
3.是基于ARM的：再看一眼合作伙伴，其中有Qualcomm,Freescale和德州电器，没有Intel！这三家是ARM芯片制造商同时对ChromeOS可以很好的运行在基于ARM的芯片上有很大的兴趣。对x86的兼容性会帮助ChromeOS占有更多的市场，但是大多数预装ChromeOS的机器会是基于ARM的。
4.会在货架上出售：对，ChromeOS的目标就是帮助出售便宜的上网电脑（用户只有上网机会为google创造价值）。在摆放时应避免和PC放到一起，造成消费者的混淆。
5.对linux来说是件好事：linux最大的问题是他的市场份额。因为linux只能代表2%的市场，很多软件，游戏和硬件商会忽略它，因为市场实在是太小了，不愿意将产品或者驱动移植到linux上。作为平衡，linux社区起到很大的作用，很多驱动，应用软件是由程序员自己开发的。但有一个问题，很多流行的游戏是由游戏工作室设计的，驱动应该是在硬件发布之前而不是之后开发的。如果基于linux的平台 - ChromeOS能够得到更多的市场份额，对整个linux社区都是一件好事 - 可以获得更好的商用软件供应商和硬件厂商的支持。
ChromeOS不是：1.并不完全依靠“云”：即便google没有使用Gnome或者KDE，她仍然可能会移植大多数的linux应用程序到ChromeOS，那么最终将有一整套完整的应用生态环境出现。尽管可能需要等上几年。因为Google gears的支持，类似google doc这样的web应用可以在离线状态下运行，所以本地应用程序可能是不需要的。
2.不是微软杀手：尽管为ChromeOS编写本地应用程序是可能的，但是ChromeOS最主要的目标是web接入。这意味着一开始可能只有很少的商用软件支持。因此，大多数人还是想要Windows作为他们的PC平台。ChromeOS可能只能在上网本制造商方面威胁到微软，但微软并没有在这方面赚钱，所以也就不大可能会引起大的对抗。
3.还没有准备好：google预期第一台装备ChromeOS的设备在2010年下半年诞生，尽管第一个beta版已经available。当ChromeOS上市的时候，Windows7和其他诸如Moblin和Jolicloud的linux操作系统将和它同台竞争。


	Tags: ChromeOS, 翻译, google
]]></description>
		<wfw:commentRss>http://zhangv.com/archives/1167/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>REST API vs. SOAP API</title>
		<link>http://zhangv.com/archives/1067</link>
		<comments>http://zhangv.com/archives/1067#comments</comments>
		<pubDate>Sun, 07 Jun 2009 02:45:00 +0000</pubDate>
		<dc:creator>zhangv</dc:creator>
				<category><![CDATA[技术(Tech)]]></category>
		<category><![CDATA[翻译]]></category>
		<category><![CDATA[openAPI]]></category>
		<category><![CDATA[REST]]></category>
		<category><![CDATA[SOAP]]></category>

		<guid isPermaLink="false">http://zhangv.com/archives/1067</guid>
		<description><![CDATA[译自“Professional Web APIs with PHP: eBay,
Google, PayPal, Amazon, FedEx, Plus Web Feeds”
REST API当处理REST请求时，因为信息是通过GET，所以，信息在传输过程中会进行URL编码(URL-encoded)；当需要进一步处理时，首先要进行解码（唯一例外是用户名和密码）。不同的请求类型应该使用不同的endpoints(URLs)；如果要以单独的脚本程序来处理所有的请求，你可以让所有的请求都指向同一个endpoint，或者配置web服务器来映射许多endpoints到同一个脚本。我建议用后一种方式；它符合规范同时允许你以后在不需要影响外部接口的情况下做修改。
允许程序员使用web接口来请求API - 在调试程序时将变得非常有用；程序员可以快速的判断问题源于请求本身还是代码。你可以提供给程序员的调试工具越多，你的网站也就越容易开发。
SOAP APIs当处理SOAP请求时，首先要检查请求是否符合WSDL指定的格式。如果你使用诸如NuSOAP的工具，他可以帮你做到这一点。事实上，大多数SOAP API使用一个框架来处理许多低级的工作。 SOAP API使用单一endpoint接收所有请求（作为一个通用规则，一些大的API会根据功能来拆分到不同的endpoint），因此，或者是你有一个很大的脚本文件，或者是在每个功能点都调用很多required()方法。
允许程序员在使用web接口时可以粘贴整个请求文档到一个表单，然后发送到你的服务器。从直接的经验来看，有这样一个工具对程序员调试程序时是非常有用的。提供脚本或者函数从而让程序员可以手动创建请求对那些没有使用SOAP框架的程序员是很有帮助的。

	Tags: 翻译, openAPI, REST, SOAP
]]></description>
		<wfw:commentRss>http://zhangv.com/archives/1067/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>apache-derby连接jdbc连接url的解析</title>
		<link>http://zhangv.com/archives/475</link>
		<comments>http://zhangv.com/archives/475#comments</comments>
		<pubDate>Tue, 02 Sep 2008 03:14:18 +0000</pubDate>
		<dc:creator>zhangv</dc:creator>
				<category><![CDATA[技术(Tech)]]></category>
		<category><![CDATA[翻译]]></category>
		<category><![CDATA[derby]]></category>
		<category><![CDATA[数据库]]></category>

		<guid isPermaLink="false">http://zhangv.com/archives/475</guid>
		<description><![CDATA[来自http://db.apache.org/derby/docs/10.4/devguide/devguide-single.htm。我这里只是翻译一下，其实最关键要搞清楚的就是系统文件夹（通常是C:/databases)和类路径（从类路径开始或者从jar文件中开始查找）的区别。
jdbc:derby:db1
•打开系统文件夹中的db1
jdbc:derby:london/sales
•打开数据库lodon/sales，london位于系统文件夹下，sales是london的子目录
jdbc:derby:/reference/phrases/french
•打开数据库 /reference/phrases/french。 unix下，就是从根目录开始的路径。windows下则是C:\reference\phrases\french（如果当前驱动器是C.如果一个包含数据库的jar文件在用户的类路径下，则这个路径是jar文件内的路径。
jdbc:derby:a:/demo/sample
•打开驱动器A中的数据库，路径是\demo\sample
jdbc:derby:c:/databases/salesdb jdbc:derby:salesdb
•这两个连接到相同的数据库 - salesdb.在windows下derby默认的系统路径是C:\databases.
jdbc:derby:support/bugsdb;create=true
•在系统路径下创建一个新的数据库 - support/bugsdb。如果不存在，则自动产生相应的文件夹。
jdbc:derby:sample;shutdown=true
•关闭sample数据库。（如果没有启用验证，则不需要提供用户密码）
jdbc:derby:/myDB
•以只读方式连接myDB（位于类路径下）
jdbc:derby:classpath:/myDB
•同样以只读方式连接myDB数据库。使用classpath的原因是，路径下可能存在和数据库同名的文件夹。
jdbc:derby:jar:(C:/dbs.jar)products/boiledfood
•访问只读数据库boiledfood， 位于C:dbs.jar中的products文件夹。
jdbc:derby:directory:myDB
•访问myDB（位于系统文件夹）。使用directory是类路径下可能存在同名文件夹（myDB)

	Tags: 翻译, derby, 数据库
]]></description>
		<wfw:commentRss>http://zhangv.com/archives/475/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>OO设计原则</title>
		<link>http://zhangv.com/archives/439</link>
		<comments>http://zhangv.com/archives/439#comments</comments>
		<pubDate>Wed, 06 Aug 2008 09:15:08 +0000</pubDate>
		<dc:creator>zhangv</dc:creator>
				<category><![CDATA[技术(Tech)]]></category>
		<category><![CDATA[翻译]]></category>
		<category><![CDATA[design]]></category>
		<category><![CDATA[OO]]></category>
		<category><![CDATA[SCEA]]></category>

		<guid isPermaLink="false">http://zhangv.com/?p=439</guid>
		<description><![CDATA[抖胆翻译一下scea study guide里的第一章的OO设计原则.纪录一下.
开闭原则
类应该被扩展,而不是被修改
Liskov替换原则
子类可以替换父类
依赖注入原则
依赖于抽象,而不是实现
接口分离原则
接口应该分开,避免单一通用的接口
合成重用原则
尽量用多态聚合代替继承
最少知识原则
操作知道尽可能少的当前类中的对象(自身,参数,类中的其他实例对象)
发布重用等效原则
细粒度的重用相当于细粒度的版本发布
包依赖:
共同关闭原则
一同变更的类应放在一起
公用重用原则
如果类不会一起被重用,就不应该放到一起.
非循环依赖原则
包之间不可以有循环依赖
依赖不变原则
依赖不应该经常变化
抽象不变原则
抽象包不应该经常变化

	Tags: 翻译, design, OO, SCEA
]]></description>
		<wfw:commentRss>http://zhangv.com/archives/439/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Javablog » How MIDlet Signing is Killing J2ME</title>
		<link>http://zhangv.com/archives/155</link>
		<comments>http://zhangv.com/archives/155#comments</comments>
		<pubDate>Tue, 11 Mar 2008 12:54:32 +0000</pubDate>
		<dc:creator>zhangv</dc:creator>
				<category><![CDATA[技术(Tech)]]></category>
		<category><![CDATA[翻译]]></category>
		<category><![CDATA[j2me]]></category>
		<category><![CDATA[Java]]></category>

		<guid isPermaLink="false">http://218.22.170.60/zhangv/wordpress/?p=321</guid>
		<description><![CDATA[Javablog » How MIDlet Signing is Killing J2ME
TODO: 翻译

	Tags: 翻译, j2me, Java
]]></description>
		<wfw:commentRss>http://zhangv.com/archives/155/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>实践的一小步-代码质量的一大步</title>
		<link>http://zhangv.com/archives/133</link>
		<comments>http://zhangv.com/archives/133#comments</comments>
		<pubDate>Mon, 18 Feb 2008 07:20:41 +0000</pubDate>
		<dc:creator>zhangv</dc:creator>
				<category><![CDATA[技术(Tech)]]></category>
		<category><![CDATA[agile]]></category>
		<category><![CDATA[翻译]]></category>
		<category><![CDATA[软件开发]]></category>

		<guid isPermaLink="false">http://218.22.170.60/zhangv/wordpress/?p=181</guid>
		<description><![CDATA[实践的一小步-代码质量的一大步
作者:Steven Hale December 14, 2007
翻译:ZhangV 2008-2-18
原文出自:DevX.com
原文链接:http://www.devx.com/Java/Article/36231/0/page/1
假设持续整合是你开发过程中很重要的一部,你也很想把代码覆盖检查并入你的自动构建过程.但是如何设定覆盖率目标呢?经验丰富的代码覆盖支持者会建议你75%,85%甚至100%.
通过对项目中的代码分析,我意识到需要设定比上述数据低得多的目标.我不想成为团队中的Cathcart上校(Josef Heller的小说&#60;&#60;第22条军规&#62;&#62;中的人物,因为每当部下已经达到当前的飞行任务次数时,他就会设定更高的任务次数,虽然Yossarian不断地完成飞行任务,但却似乎永远都无法完成这个总在变化的次数,小说中最后Yossarian开小差逃到瑞典-译者).
我选择增量改进的策略而不是专制的设定更高的目标.为了成功的执行这个策略,每次构建都必须达到比之前构建更高的覆盖率.通过每次一小步的提升,来最终提升代码质量.
以下介绍如何使用Cobertura和Apache Ant来实现这个增量改进.
单元测试,代码覆盖,持续整合
这三个概念已经被广泛的接受为最佳实践.事实上,大多数程序员知道他们必须要单元测试.如果你还不知道,让我来引用Google研发总监Peter Norvig的名言:
"如果你觉得不需要写单元测试,把所有原因写下来到一张纸上.仔细的揣摩这张纸.然后,扔掉这张纸开始写单元测试."
但是谁来测试测试人员呢? 也就是说,你怎么来确认你写了足够的测试呢?这些是非常宝贵的信息,因为那些没有被测试覆盖到的代码正是最耗费你经历的地方.一个解决办法是使用代码覆盖工具,它们会告诉你有被测试代码的百分比,然后加入一个代码覆盖检查到你的持续构建过程.如果你的覆盖检查不通过,那么构建也该被认定为失败.
在我的增量改进策略中,我选择Cobertura是因为她4个定义完整而简单的ant任务扩展.其中之一 cobertura-check,当代码覆盖率没有达到要求是会认定构建失败.例如下面这个例子,当覆盖率小于80%时,Ant会认为构建是失败的:
&#60;target name="coverage_check"&#62;
&#60;cobertura-check totallinerate="80"/&#62;
&#60;/target name="coverage_check"&#62;
但是,你可以使用之前的覆盖率来作为当前检查的标准.通过几个Cobertura的任务以及两个核心的ant任务,你就可以达到这个目标.而不需要担心是否应该考量 代码行率(line rate),分支率(branch rate)或者其他的覆盖数据.你的目标是改进,而不是一个绝对的硬性指标.
创建一个XML格式的代码覆盖报表
创建好ant任务后,你可以加入增量覆盖率检查到你的构建脚本中,第一步是用cobertura-report任务创建一个覆盖率报表:
&#60;cobertura-report format="xml"/&#62;
下面是一个生成的报表:
&#60;?xml version="1.0"?&#62;
&#60;!DOCTYPE coverage SYSTEM "http://cobertura.sourceforge.net/xml/coverage-02.dtd"&#62;
&#60;coverage line-rate="0.43612334801762115" branch-rate="0.48344370860927155" version="1.8" timestamp="1181043899853"&#62;
&#60;sources&#62;
&#60;source&#62;./src/java&#60;/source&#62;
&#60;/sources&#62;
&#60;packages&#62;
...
&#60;/packages&#62;
&#60;/coverage&#62;
确保你把这个文件保存安全的地方(或者放到你的版本控制系统),因为之后你会用到他们.
从报表中得到覆盖率数据
一开始你可能会用Ant的XmlProperty任务来直接获取代码行率(line rate).但是这种做法有几个问题:
1.Cobertura的行率(line-rate)是十进制小鼠,但是cobertura-check是用整数形式的百分率
2.在一个实际的项目里,coverage.xml可能会很大,使用XmlProperty可能会造成内存不足的错误
我建议使用Ant的XSLT任务来获取你所需要的数据
&#60;xslt in="coverage.xml" out="build/coverage.properties" style="src/xsl/coverage.xsl" /&#62;
这个简单的xsl模板生成仅仅包含你所需要的数据的属性文件:
&#60;xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"  version="1.0"&#62;
&#60;xsl:output method="text" omit-xml-declaration="yes"/&#62;
&#60;xsl:template match="coverage"&#62;
total.line-rate=
&#60;xsl:value-of select="floor(@line-rate*100)"/&#62;
&#60;/xsl:template&#62;
&#60;/xsl:stylesheet&#62;
注意方法:floor(@line-rate*100), 会把行率转成一个整数,生成的coverage.properties文件只有一行:
total.line-rate=44
这个属性文件仅仅是一个临时的文件,构建之后你可以把它清理掉.
使用Ant的property任务读入这个属性文件中唯一的值total.line-rate:
&#60;property file="build/coverage.properties" /&#62;
然后你可以把之前的"80"替换为新的Ant属性值:
&#60;cobertura-check totallinerate="${total.line-rate}"/&#62;
完整的例子
最终的build.xml应该是这样(其他的任务省略掉):
&#60;target name="coverage_check" depends="check_against_previous_rate"&#62;
&#60;antcall target="coverage_report"/&#62;
&#60;/target&#62;
&#60;target name="coverage_report"&#62;
&#60;cobertura-report format="xml" destdir="." /&#62;
&#60;/target&#62;
&#60;target name="check_against_previous_rate" depends="coverage_xml_to_properties"&#62;
&#60;property file="build/coverage.properties" /&#62;
&#60;cobertura-check totallinerate="${coverage.line-rate}" /&#62;
&#60;/target&#62;
&#60;target name="coverage_xml_to_properties"&#62;
&#60;xslt [...]]]></description>
		<wfw:commentRss>http://zhangv.com/archives/133/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>看板在行动(Kanban in Action)</title>
		<link>http://zhangv.com/archives/49</link>
		<comments>http://zhangv.com/archives/49#comments</comments>
		<pubDate>Mon, 26 Nov 2007 06:47:20 +0000</pubDate>
		<dc:creator>zhangv</dc:creator>
				<category><![CDATA[技术(Tech)]]></category>
		<category><![CDATA[看板]]></category>
		<category><![CDATA[翻译]]></category>
		<category><![CDATA[软件工程]]></category>

		<guid isPermaLink="false">http://218.22.170.60/zhangv/wordpress/?p=55</guid>
		<description><![CDATA[作者:DavidAnderson 原文
翻译:ZhangV 2007-11-26
之前，在讨论我在corbis所使用的软件工程管理方法时 ，我曾提到引入看板系统来维持项目运行。因为它的引入，我们现在每个月平均发布两个新的版本。然而，这些并没有使用传统的敏捷开发方法如两周迭代（two week iteration)或快速迭代（sprint)。而是用看板系统来管理变更请求（CR-Change Request）。当CR被完成时，它被设在准备发布状态，并在每周三被发布。
尽管我们让没有用Visual Studio的开发人员使用了outlook的teamlook客户端联入Team Foundation Server跟踪所有CR，但基本上的日常工作，我们都是使用白板作为看板来跟踪所有CR，把Post-It当作看板卡。
我们的支持过程是由一组常见的软件工程资源驱动的，没有一个专职的支持维护团队。通过设置看板，我们可以向管理层保证 - 我们正在履行我们的承诺，我们使用了一定的资源来进行支持活动，而不需要特别指出是谁在负责。
每天早会上所有团队成员会围绕看板来进行当天的工作安排，讨论进度和当前存在的问题。达伦戴维斯，作为项目经理，会主持会议，并分析每张卡片并与其他成员讨论。每张卡上写着CR的标题以及ID，及负责人的名字。每个负责人有责任根据当前CR的进行阶段移动相应CR的卡片。达伦利用每天的早会来保证Team Foundation Server上的数据和看板是同步的。该看板系统基本上是自我组织(self organizing)，但整个团队每天都会验证它的有效性。
一些关键概念。红星 - 这个任务已经严重超时的，超过28个工作日服务水平协议（ SLA），通过该系统。这使"迟到"的项目能够自我加速，不需直接管理干预。粉红色卡表示这个CR在Team Foundation Server里还是open的。这些粉红色卡包含了描述信息和在Team Foundation Server里的ID 。还有一些其他类型的卡片：黄色-客户提出（customer-valued)的CR;蓝色-客户提出（和要求）的BUG;绿色-IT维护项，如：的sql 2005的升级;橙色-新增（或额外）的BUG;粉红-issue。
看板限制卡片最多只能有20张，分为不同阶段，系统的分析，开发，测试，构建/合并，部署。此外，我们也允许有3个bug可以放在任何地方。这样可以有效地利用闲散资源。当人手不够的时候，我们会减少这个数量，或者干脆不要。此外，还有两个维护项，这让我们能解决固定分配一些资源到大大系统维护和升级，例如API版本升级，与平台的升级。 如net2.0或sql server 2005 。
看板赋予我们三个成功要素：

减少“进行中(work-in-progress)”， （讽刺的是，这些事情本身会限制工作的完成）
量入而出（如果有新的CR，首先看看板上有没有足够的空间）
确定优先顺序

我们每周和公司的技术总监开会讨论，决定任务的优先等级。他们从后台日志中拿出新的CR并考虑怎么把他们配置到看板上。这迫使他们思考哪些是最重要的事情。看板强迫他们给出优先等级。
看板还把我们从定时迭代的压迫（constraints of time-boxed iterations)中解放出来。尽管我们现在每两个星期发布一个新版本，大的任务可以在系统中最多可以存在60天。那些对于“一（两）周迭代”来说太大的任务同样可以放到看板里，而不需要特殊对待。
最后，看板解放了我们，我们不再把每个迭代都当作一个小型的项目而投入过多的管理成本它基本上是自行组织和管理，除非有特殊情况出现，如需要加快请求或因环境或系统的维修问题变更发布时间。
technorati的标签：敏捷，朱+安德森，精益生产，看板，软件+工程
顺便问一下customer-valued怎么翻译？
最后修改：2009-8-12

	Tags: 看板, 翻译, 软件工程
]]></description>
		<wfw:commentRss>http://zhangv.com/archives/49/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>写商业计划书之前要做的10件事</title>
		<link>http://zhangv.com/archives/33</link>
		<comments>http://zhangv.com/archives/33#comments</comments>
		<pubDate>Sat, 10 Nov 2007 16:29:45 +0000</pubDate>
		<dc:creator>zhangv</dc:creator>
				<category><![CDATA[非技术(non-tech)]]></category>
		<category><![CDATA[翻译]]></category>
		<category><![CDATA[创业]]></category>

		<guid isPermaLink="false">http://218.22.170.60/zhangv/wordpress/?p=24</guid>
		<description><![CDATA[翻译-写商业计划书之前要做的10件事
 原文
撰写计划书之前最好研究一下计划书应该包含哪些部分.
1.研究所有相关章节
开始写之前,确定你已经理解必要的章节,不同章节的目的和计划书的目标. Business Plan  Pro(r)
2005之类的软件会帮助你确保不会漏掉任何章节.但如果你选择自己写,可以参考这两个网站:www.bplans.co.uk和www.businessplanhelp.co.uk,他们会帮助你全面了解每个必要的组成部分,写出令人信服的商业计划.
2.决定法律结构
尽管大多数的企业关注于"创意"或者"想法" --  这是可以理解的,但是日常执行和后勤也是不可忽视的.例如,在做贸易的时候,你要决定是单一供货商,合伙制还是有限公司.决定之前,列出当地的会计师和业务关系或者通过网站(www.startups.co.uk)研究不同选择的特点.类似的,诸如了解你的增值税义务(原文:VAT  obligation),注册商标或公司名,以及起草员工合同都需要被考虑到.
3.掌握数据
无论你是否喜欢统计数据,深入地了解会影响到你业务的数据是你成功至关重要的因素,尤其是在计划阶段.开始阶段了解以下这些非常重要:
.你的启动成本
.你的盈亏平衡点
.你的资金需求
.你的之后几个月的现金流预测
免费的计算器可以帮助你计算这些数据.强烈建议你通过一个基本会计打包(原文:basic  account package)建立你的业务.QuickBooks(r)
(www.intuit.co.uk) 或 Sage(r) (www.sage.co.uk)会提供这样的服务.
4.获取行业分析数据
尽管你拥有独一无二的地方,但是仍然有很多与你相似的公司存在,作一些市场调研会帮助你更好的了解你的目标市场.
所有的公司被英国政府使用标准工业划分系统(SIC)分为不同的类别;先找到你所在的类别并找到你的SIC编码.这会帮你搜索到你竞争对手和其他业界参与者的有关资料.然后通过类似Cobweb
(www.cobwebinfo.com)的数据源寻找更多的数据资料.Cobweb提供大量的商业档案资料.这会让你获得外部的视角来分析业界其他类似公司.
5.研究市场
当准备投放广告时,不如先使用www.overture.com的关键字助手看看哪些与你的业务或服务有关的关键字被搜索的最多.这会帮助你有效的投放广告或确定一个URL或者使用搜索引擎优化来优化你的网站.你也可以通过输入这些关键字到搜索引擎来找到你的竞争对手.
6.慎重评估需求水平
与估计成本不同,最难预测的事情是你的产品或提供的服务的需求水平.通常的规则是保守地估计可能的需求和使用相似取代方法.
即便是一个新的独一无二的创意也应该用相似取代来估计,而不是凭空编造数据或说自己没有可以比较的数据.一个经典例子,最近伦敦旅游发展项目的昙花一现.一个最主要的问题就是游客的数量远远低于预先估计的数量,因此入不敷出.如果负责人事先研究过英国最主要的吸引游客的地方,他们就会找到潜在游客的上限数量.由于估计的游客数量高过这个上限,这个疯狂的优化假设造成最终的失败  -- 成本和收益远不成比例.
7.进入市场策略
由于竞争的激烈,企业家要慎重选择如何进入市场或如果打动客户的芳心.大多数新的公司会考虑为他们的新品牌采用多渠道进入的策略,但是这样做不仅仅成本巨大,而且比单一渠道昂贵许多.互联网营销是一个很吸引人的策略,因为营销成本容易跟踪.此外,找到当前相似市场的供应商所处的位置也可以告诉我们哪些市场活动是最有效的.当然,这些是建立在正确的数据上的.
8.雇用合适的人
除了财务方面的估计,执行力强并可以信赖的人是潜在投资者要研究的.无论企业家和创建人的技能水平如何,他常常是需要协助的.尽管很多非核心的活动是可以外包的,某些部门,例如销售,还是需要随时关注的.你应该列出所有的必要技能,把他们放到模型里定价,发现缺口并合适的候选人.
9.定义并明确客户获得的好处
许多企业家无法清楚的说出他们的所做的事能够带来的好处.因此,"电梯行销"这个词被引入到现代词汇来解决这个问题.--所谓的电梯行销是,你的创意,以及支持他的商业模型,公司方案,市场策略和竞争手段需要你在一段电梯升降的过程中表达出来.
这个简单的方法目的是让企业家用心地思考在描述他的产品或服务时如何使用语言的艺术.同时也是提醒他们要以客户为中心并确保他们集中精力描述这些"好处".
10.找一个导师
许多的创业者会妄想他们的创意会被别人偷走,并在开始前表现的很不理性.通常,创意都是严密的保护并且只在知己讨论.但是这些"知己"(一般是家人或朋友)  通常很难提出足够具有挑战性的问题因为一来他们不愿意冒犯你,二来他们缺少相关的经验或足够的判断力去严格地分析这个新的风险.正因如此,有重大缺陷的创意可以在还没有“关键时候掉链子”的时候被及时纠正，从而可以正常地发展。强烈建议创业者在早期找一个独立的导师帮你审视你的创意。这些人可以帮你在向投资人或者银行展示之前“敲打”你的创意。最后，形成鲜明对比的是，一些创业者觉得投入越多越好，他们参加每一个商业计划竞赛来获得独立的反馈而不是获奖。

	Tags: 翻译, 创业
]]></description>
		<wfw:commentRss>http://zhangv.com/archives/33/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
