来自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)
抖胆翻译一下scea study guide里的第一章的OO设计原则.纪录一下.
开闭原则
类应该被扩展,而不是被修改
Liskov替换原则
子类可以替换父类
依赖注入原则
依赖于抽象,而不是实现
接口分离原则
接口应该分开,避免单一通用的接口
合成重用原则
尽量用多态聚合代替继承
最少知识原则
操作知道尽可能少的当前类中的对象(自身,参数,类中的其他实例对象)
发布重用等效原则
细粒度的重用相当于细粒度的版本发布
包依赖:
共同关闭原则
一同变更的类应放在一起
公用重用原则
如果类不会一起被重用,就不应该放到一起.
非循环依赖原则
包之间不可以有循环依赖
依赖不变原则
依赖不应该经常变化
抽象不变原则
抽象包不应该经常变化
Javablog » How MIDlet Signing is Killing J2ME
TODO: 翻译
Continue reading about Javablog » How MIDlet Signing is Killing J2ME
实践的一小步-代码质量的一大步
作者: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的小说<<第22条军规>>中的人物,因为每当部下已经达到当前的飞行任务次数时,他就会设定更高的任务次数,虽然Yossarian不断地完成飞行任务,但却似乎永远都无法完成这个总在变化的次数,小说中最后Yossarian开小差逃到瑞典-译者).
我选择增量改进的策略而不是专制的设定更高的目标.为了成功的执行这个策略,每次构建都必须达到比之前构建更高的覆盖率.通过每次一小步的提升,来最终提升代码质量.
以下介绍如何使用Cobertura和Apache Ant来实现这个增量改进.
单元测试,代码覆盖,持续整合
这三个概念已经被广泛的接受为最佳实践.事实上,大多数程序员知道他们必须要单元测试.如果你还不知道,让我来引用Google研发总监Peter Norvig的名言:
“如果你觉得不需要写单元测试,把所有原因写下来到一张纸上.仔细的揣摩这张纸.然后,扔掉这张纸开始写单元测试.”
但是谁来测试测试人员呢? 也就是说,你怎么来确认你写了足够的测试呢?这些是非常宝贵的信息,因为那些没有被测试覆盖到的代码正是最耗费你经历的地方.一个解决办法是使用代码覆盖工具,它们会告诉你有被测试代码的百分比,然后加入一个代码覆盖检查到你的持续构建过程.如果你的覆盖检查不通过,那么构建也该被认定为失败.
在我的增量改进策略中,我选择Cobertura是因为她4个定义完整而简单的ant任务扩展.其中之一 cobertura-check,当代码覆盖率没有达到要求是会认定构建失败.例如下面这个例子,当覆盖率小于80%时,Ant会认为构建是失败的:
<target name=”coverage_check”>
<cobertura-check totallinerate=”80″/>
</target name=”coverage_check”>
但是,你可以使用之前的覆盖率来作为当前检查的标准.通过几个Cobertura的任务以及两个核心的ant任务,你就可以达到这个目标.而不需要担心是否应该考量 代码行率(line rate),分支率(branch rate)或者其他的覆盖数据.你的目标是改进,而不是一个绝对的硬性指标.
创建一个XML格式的代码覆盖报表
创建好ant任务后,你可以加入增量覆盖率检查到你的构建脚本中,第一步是用cobertura-report任务创建一个覆盖率报表:
<cobertura-report format=”xml”/>
下面是一个生成的报表:
<?xml version=”1.0″?>
<!DOCTYPE coverage SYSTEM “http://cobertura.sourceforge.net/xml/coverage-02.dtd”>
<coverage line-rate=”0.43612334801762115″ branch-rate=”0.48344370860927155″ version=”1.8″ timestamp=”1181043899853″>
<sources>
<source>./src/java</source>
</sources>
<packages>
…
</packages>
</coverage>
确保你把这个文件保存安全的地方(或者放到你的版本控制系统),因为之后你会用到他们.
从报表中得到覆盖率数据
一开始你可能会用Ant的XmlProperty任务来直接获取代码行率(line rate).但是这种做法有几个问题:
1.Cobertura的行率(line-rate)是十进制小鼠,但是cobertura-check是用整数形式的百分率
2.在一个实际的项目里,coverage.xml可能会很大,使用XmlProperty可能会造成内存不足的错误
我建议使用Ant的XSLT任务来获取你所需要的数据
<xslt in=”coverage.xml” out=”build/coverage.properties” style=”src/xsl/coverage.xsl” />
这个简单的xsl模板生成仅仅包含你所需要的数据的属性文件:
<xsl:stylesheet xmlns:xsl=”http://www.w3.org/1999/XSL/Transform” version=”1.0″>
<xsl:output method=”text” omit-xml-declaration=”yes”/>
<xsl:template match=”coverage”>
total.line-rate=
<xsl:value-of select=”floor(@line-rate*100)”/>
</xsl:template>
</xsl:stylesheet>
注意方法:floor(@line-rate*100), 会把行率转成一个整数,生成的coverage.properties文件只有一行:
total.line-rate=44
这个属性文件仅仅是一个临时的文件,构建之后你可以把它清理掉.
使用Ant的property任务读入这个属性文件中唯一的值total.line-rate:
<property file=”build/coverage.properties” />
然后你可以把之前的”80″替换为新的Ant属性值:
<cobertura-check totallinerate=”${total.line-rate}”/>
完整的例子
最终的build.xml应该是这样(其他的任务省略掉):
<target name=”coverage_check” depends=”check_against_previous_rate”>
<antcall target=”coverage_report”/>
</target>
<target name=”coverage_report”>
<cobertura-report format=”xml” destdir=”.” />
</target>
<target name=”check_against_previous_rate” depends=”coverage_xml_to_properties”>
<property file=”build/coverage.properties” />
<cobertura-check totallinerate=”${coverage.line-rate}” />
</target>
<target name=”coverage_xml_to_properties”>
<xslt […]
作者: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，首先看看板上有没有足够的空间） ;和确定优先顺序。我们每周和公司的技术总监（vice president-应该是负责人，而不是副总裁 - 译者）开会讨论，决定任务的优先等级。他们从后台日志中拿出新的CR并考虑怎么把他们配置到看板上。这迫使他们思考一下一个，两个，或三个最重要的事情。看板强迫他们给出优先等级。
该看板系统，也把我们从定时迭代的压迫（constraints of time-boxed iterations)中解放出来。尽管我们现在每两个星期发布一个新的版本，大的负责的任务可以在系统中最多可以存在60天。那些对于“一（两）周迭代”来说太大的任务同样可以放到看板里而不需要特殊的关照。
最后，看板解放了我们，我们不再把每个迭代都当作一个小型的项目而投入过多的管理成本它基本上是自行组织和管理，除非有特殊情况出现，如需要加快请求或因环境或系统的维修问题变更发布时间。
technorati的标签：敏捷，朱+安德森，精益生产，看板，软件+工程
顺便问一下customer-valued怎么翻译？
翻译-写商业计划书之前要做的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.找一个导师
许多的创业者会妄想他们的创意会被别人偷走,并在开始前表现的很不理性.通常,创意都是严密的保护并且只在知己讨论.但是这些”知己”(一般是家人或朋友) 通常很难提出足够具有挑战性的问题因为一来他们不愿意冒犯你,二来他们缺少相关的经验或足够的判断力去严格地分析这个新的风险.正因如此,有重大缺陷的创意可以在还没有“关键时候掉链子”的时候被及时纠正，从而可以正常地发展。强烈建议创业者在早期找一个独立的导师帮你审视你的创意。这些人可以帮你在向投资人或者银行展示之前“敲打”你的创意。最后，形成鲜明对比的是，一些创业者觉得投入越多越好，他们参加每一个商业计划竞赛来获得独立的反馈而不是获奖。
(最初发布在JavaResearch.org,现在整理好放到自己的地方.)
作者:Narayanan A.R. June 15, 2005
翻译:ZhangV 2005-06-28
原文出自:DevX.com
原文链接:http://www.devx.com/Java/Article/28422/0/page/1
首先你要明确的一点,AOP和OOP是两种不同的认识事物的角度,并不是说有了AOP就不要用OOP.AOP所关注的是传统OOP不能优雅解决的问 题.(程序员通常都是完美主义者,当解决某个问题不优雅的时候,那就意味着不完美.)下面将就一个简单的例子来说明他们到底如何的不同.
作为一个使用OOP多年的人来说,当我听说AOP可以解决一些OOP一直都不能优雅地解决的问题时,我觉得应该去探个究竟了.对两种技术的比较最能给我们实际应用提供见解.这里我设计了一个例子:一个OOP应用,其中某些方面适合使用AOP.
本文展示了一个简单的例子.一开始介绍了问题域,然后分别给出传统OOP的解决方法与结合了AOP解决方法.后者使用了 JDK5.0,JUnit,和 AspectWerkz.最后我会说明如何编写代码.读完本文后,我希望你能知道AOP到底是什么,用来解决什么样的问题.
问题域描述
一个软件公司雇佣一个程序员,指定给他一个业务部门并要求他随时向经理报告.当团队成员完成他们的目标时,经理会给他们相应的奖金.公司所需要的方案必须能够增加一个新的雇员并给当前的员工增加奖金.为了方便,我们用CSV文件存储数据.
图1 解决方案模型
类Manager(经理)继承自类Employee,包含一个额外的属性,Managing Project.一个部门可能包含很多员工.多个部门构成了公司.暂不考虑公司这样的一个类,因为它在问题域之外.
解决方案设计
以下流程图描述了解决方案设计.
图2 对象之间的交互(增加一个新的员工,指派给他一个部门和经理)
出于简单的考虑,本文只关注必需的细节.你也可以深入代码得到你想要的其他信息.
下载
EmployeeServiceTestCase, 一个JUnit测试用例,模拟一个最终用户,创建新员工记录,指派部门和经理.它获取所有可用的部门和经理数据并显示在图形界面上.为了实例化域对象 BusinessUnit和Manager,获得的记录将传递给工厂类.之后,通过给EmployeeService传递一个引用来创建一个 Employee对象.这个服务类使用EmployeeFactory创建对象,并把这个对象传给EmployeeRepository 来进行持久化操作.
应用程序中需要面向哪些”Aspect”
到目前为止,对模型和设计的讨论还限于一个较抽象的层面.现在,我转向这个应用的其他方面 - 这对理解AOP的价值至关重要.
操作所需的资源
<pre lang=”java”>
public static Set findAllBusinessUnits() throws RepositoryException {
Set businessUnits = new HashSet();
try {
FileReader businessUnitFile = null;
BufferedReader bufferedBusinessUnitFile = null;
try {
businessUnitFile = new FileReader(FILE_NAME);
bufferedBusinessUnitFile = new BufferedReader(businessUnitFile);
String businessUnitRecord;
while((businessUnitRecord = bufferedBusinessUnitFile.readLine()) != null) {
BusinessUnit businessUnit = BusinessUnitFactory.createBusinessUnit(businessUnitRecord);
businessUnits.add(businessUnit);
}
} finally {
if(bufferedBusinessUnitFile != […]