Help Framework

帮助框架

还没有google过,其实想法很简单. 就是一个用来做帮助的一些基础组件.

针对不同的UI方式(swing,web,…)和不同的帮助信息存储(文件,数据库). 可以比较方便的定制自己的帮助系统.方便维护.

会做:
可配置
容易扩展
和一些现有框架的结合
数据导入导出

不会做:
权限/用户控制
显示逻辑

常看的blog

看到有个朋友的签名, 写blog居然也是男人三大俗之一.算了,俗就俗吧,要是大家都不写,那就丫的俗了.

于是想到了常看的一个blog – 我blog故我在.列一下自己经常看的blog,排名分先后:

1.三表哥
也是性情中人,写的东西很直,看得很爽.而且也经得起推敲(如果你实在闲的蛋疼到要去推敲的话).

2.我blog故我在
微软欧洲的哥们,geek之类,经常会看到一些有意思的应用介绍或者工具,也研究sns. 应该算是有共通的兴趣.

3.对牛乱弹琴
keso,互联网相关,新闻,评论…但不知为什么最近半年更新比较慢

4.弥缝
经常有一些 gtd的技巧和文章,很有用

5.lifehacker
看名字就知道了,各种软件工具使用技巧

6.Mr 6
正好也是6,看来Mr6还真不是盖的. 也是关于互联网创业,趋势

7 .方军
互联网,媒体, 商业评论

8.DBA Notes
Oracle DBA专家,经常也有一些有意思的东西.好像是taobao的人.

9.apple4us
为了让自己跟得上点潮流, apple的东西要知道一点

10.袁岳
用咱粗人的话说,有时候觉得有点酸,尤其是经常会”附带小诗一首”.不过也会有一些关于人文方面的游记,评论.选择性阅读.

11.李鹏程
拿中国足球说事
…..其他的要不是不经常更新(比如董路),要不就是太专业,太晦涩 .反正上面这10个是经常看的.

纯粹YY

最近几天特文艺. 开始思考软件业的”后工业时代”,可能是有感于现在的”原始社会阶段”吧. 也就是关于软件,信息的现代化理论.听起来似乎挺吓唬人的.

通常的现代化理论都是把整个社会发展分成:工具时代->农业时代->工业时代->知识时代.现代化被认为是农业向工业社会过渡时开始的,工业时代到知识时代被称为第二次现代化. 在网上看到的资料似乎都没有一个统一的划分.不过倒是看到不少比较有启发性的东西.

  • 如果说第一次现代化是对大自然的征服和掠夺 ,那么第二次现代化就是对大自然的保护和回归.
  • 左脑的工业时代,右脑的后工业时代
  • 战争是社会发展的性

我觉得还有最后应该是信息时代,也就是后工业时代. 因为信息技术使得所有的领域无论工业,农业,个人,生活,科学领域都起到极大的作用.最终所有的事情都转化为信息流和物流.我们每天坐车上班是干什么,还不是到办公室往电脑里敲东西吗?所以”上下班”这个概念逐渐在被优化掉,人与人的沟通也是信息流,同样可以通过网络来达到人际沟通.也许有的人说,那我总不能未来还是和老爸老妈视频电话沟通吧,当然不一定了,如果真的达到了我所期望的那种境况,你可以选择陪在父母旁边坐任何事情,而不是跑到上海工作每天累个半死连电脑都懒得开.

当完全信息化实现时,不会用很长时间的,那时人们有更高效的工作方式,和更多的休闲时间,那么自然就开始”后工业”咯.<-纯粹YY

软件建模三元素

偶然的灵感, 能否以后编程就和写作文一样呢? 这也应该是面向对象的终极目标吧.下面这个是经常出现在教科书上的例子.

Person tom = new Person() – > tom is a Person

Dog trigger = new Dog() -> trigger is a Dog

List<Person> friends = new ArrayList<Person> – > Person have Person friends

Person implements Emotianal,HumanBehave -> Person behave Emotional and surely behave as a human.

interface Emotional{ sadly(); happily();} ->Emotional including sadly and happily doing things.

interface HumanBehave {cry();laugh();call(Person);} -> HumanBehave including cry and laugh and call somebody.

tom.cry().sadly() -> tom is crying sadly

tom.call(ann) -> tom is calling ann

如果以后将软件建模分为过程建模(process modeling)和对象建模(OO modeling),那么就更和谐了.让流程引擎来管理对象的生命周期以及提供上下文环境,对象只是一些功能性的个体.可能是因为最近了解了一些jBPM的东西.其实还应该有规则建模(也就是AOP主要解决的问题).过程,规则,对象这三者是否可以成为”三元素”而统一所有的软件建模领域呢?

有点不明白,为什么java不直接把void这种返回值省略掉,也就是如果没有东西返回就返回this.虽然只是一个很小地方,但真不觉得void有什么用.

例文:

A story about tom and ann (tom,ann,cruger=new Person…)

It’s friday.Raining. (context, initialize , environment)

Tom goes to the cinema, buys a ticket and sit. (tom.goToCinima().buyTicket().sit())

Movie started.(environment changed)

Tom notices a pretty girl beside him.(tom.notice(ann))

Tom fell in love.(tom.fallInLove(ann))

Tom kissed the girl whose name is ann. (tom.kiss(ann))

Tom get kicked ass by cruger who is Ann ‘ boy friend’. (cruger.kickAss(tom))

The end. (process end)

哈哈

实践的一小步-代码质量的一大步

实践的一小步-代码质量的一大步
作者: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 in=”coverage.xml” out=”build/coverage.properties” style=”src/xsl/coverage.xsl” />
</target>

注意:新的覆盖报表只有在覆盖检查通过时才生成.(覆盖率必须要高于前一次的构建)

记得要先执行coverage_report,然后执行coverage_check.实际开发中,你应该加入另一个covertura-report任务来生成HTML的报表.

跟踪改进率
一个附加的好处是你可以通过记录覆盖率数据到一个文件来跟踪改进率.通过echo人物:

<target name=”time”>
<tstamp>
<format property=”date.time” pattern=”yyyy-MM-dd HH:mm”/>
</tstamp>
</target>

<target name=”log” depends=”time”>
<echo file=”${history.txt}” append=”true”>
${date.time};total.line-rate;${total.line-rate}
</echo>
</target>

可量化的结果,看得见的改进
在使用了上述的措施后的一周后,我们的代码覆盖率提升了30%.可喜的是,那些之前不情愿写测试的程序员现在也很自豪地看到项目的覆盖率提升.

敏捷开发的民主精神在于,每一个团队成员都可以为整个团队提出目标 – 通过写单元测试. 没有专制的目标,没有cathcart上校.

你也可以更进一步.把这种增量式改进策略用到其他的地方.

作者Steven Hale,工作与瑞典的Omegapoint AB咨询公司.有超过20年的系统开发经验.