RSS 2.0 Feed
2005-04 Entries
摘要:想像如果我们可以用设计Web页面的方式去设计Windows(Linux、Unix,任何你可以想像到的图形化操作系统)界面那会是什么样子的?我们将可以统一界面设计,我们可以将可以跨平台设计界面。 我们都知道Web就是这样做的,为了让全世界的人能够在不同的地方不同的操作系统下看到同样的界面,W3C推出了一系列的标准:HTML、CSS、DOM等等,如果一个Web浏览器完全符合标准的话那么我们在世界的每一个角落看到的网页将都是相同的。同样Java下的Swing也有同样的目标,为不同的平台提供同样的界面与设计方式。但是它们都有一个很大的缺点(或不足),那就是它们的设计方式还不够好,没有将界面设计的要领规划分类、使界面的设计成为一种很漫长的过程。什么意思呢?让我们来看看,做界面的需求不外乎以下几大类: 元素:界面上可以有的界面元素,如Button、TextBox、图片、文字等。 排版:界面元素的位置以及元素间位置的关系。 样式:元素的大小、颜色等装饰性的特性。 文化:多国语言、语言间差异性的处理等。 文件模型:将界面通过一个模型来展现,通过文件模型与UI脚本可以动态地定义界面。 UI脚本:用来控制文件模型好实现一些动态效果,如动画等。 现在的问题是HTML、Swing、System.Windows.Forms等(对Avalon不是很熟悉,略微看了一下,不是特别强)都没有将这几种需求分开处理,而是混合在了一起,这样设计出来的界面就很死板,再想改界面的时候就会发现很麻烦。但是注意现在W3C已经开始推荐XHTML+CSS来实现界面设计了,也就是说,它将元素与样式分隔开了,但是排版与元素还没有完全分隔开,还是需要DIV元素来做排版,而且由于XHTML的性质没有做到文化处理。 现在想像一下,如果我们可以使用一种类似XHTML 1.1的基于XML的语言来定义界面元素,用类似CSS的语言来定义样式,用自创的方便排版的语言来定义排版信息,再用资源文件+自定义文化语言来定义文化的话我们能实现什么效果呢?答案当然是所有我们上面所谈过的了,统一的、跨平台的、支持多国语言的、动态的、样式可替换的(不仅仅是皮肤的功能)并且可多次转换(因为基于XML)的界面定义。Cool, no? 当然这些都只是一些构想,实现它们需要相当的时间,而且也需要一定推广,不过我相信有朝一日当W3C等标准化组织推出相关标准后这一切就都会变成可能了。目前,我们还是可以利用一部分概念小面积的改善我们项目中的UI设计体验!...[阅读全文]

posted @ | Feedback (2) | Filed Under [ Designs ]

摘要:最近因为工作需要写了个将NUnit的XML结果输出转成报表的动态模板,我制作的样式虽然不太好看不过倒瞒实用的,有兴趣的朋友也可以去下载DCG来生成自己的报表哦! 下面是报表的示例。 D:\Visual Studio Projects\PWF-Framework\Framework\bin\Debug-UnitTests\PWF.Framework.exe 用例数量 27 失败个数 0 没运行个数 1 日期 2005-4-15 9:38 准备人 Seth Yuan ConditionSyntaxTest 描述 测试条件表达式的语法 结果 成功 所用时间 0.15625 描述 已运行 结果 所用时间 一个有变量的表达式$fe > 3 and faLse <> true 是 成功 0.063 一个Not变量表达式not $_fe 是 成功 0.000 有括号的复杂一点的表达式((true and false = false or false = not true)>= false) < true 是 成功 0.016 更为复杂的表达式(("a"<>"A")>=("123"<"456") or (123>345)) and (($_v=true) or (1<=2)) and not (false) 是 成功 0.000 多重括号表达式not (true and (false or (true and (false or (true and (false or not ($_v<>true))))))) 是 成功 0.016 FlowCompilerTest 描述 测试流程编译器的正确性。 结果 成功 所用时间 1.65625 描述 已运行 结果 所用时间 测试对流程定义对象的代码生成,生成期间无异常便通过。 是 成功 0.906 模拟一个请假流程的定义,然后试图编译,看是否编译出错,不出错既是通过。 是 成功 0.719 FlowDefinitionTest 描述 测试流程定义对象的准确性 结果 成功 所用时间 1.375 描述 已运行 结果 所用时间 测试签核节点的At属性为空时的处理,应抛出异常。 是 成功 0.000 测试条件逻辑块对象的ConditionExpression属性为空时的处理,应抛出异常。 是 成功 0.000 测试签核条件对象的ConditionExpression属性为空时的处理,应抛出异常。 是 成功 0.000 测试ExternalProgramCallLB对象的ExePath属性为空时的处理,应抛出异常。 是 成功 0.016 测试流程定义对象的序列化 是 成功 1.063 又一个更复杂的序列化测试 是 成功 0.016 测试流程定义对象名字有非法字符串时的处理(空格),应抛出异常。 是 成功 0.000 测试流程定义对象名字有非法字符串时的处理(特殊字符),应抛出异常。 是 成功 0.016 测试流程定义对象为空时的处理,应抛出异常。 是 成功 0.000 测试流程节点对象的条件属性为空时的处理,应抛出异常。 是 成功 0.000 测试流程节点对象的唯一名字为空时的处理,应抛出异常。 是 成功 0.000 测试FlowPropertyChangeLB对象的PropName属性为空时的处理,应抛出异常。 是 成功 0.016 测试FlowPropertyChangeLB对象的PropValue属性为空时的处理,应抛出异常。 是 成功 0.000 测试FlowStateChangeLB对象的Description属性为空时的处理,应抛出异常。 是 成功 0.016 测试流程定义对象的唯一名字为空时的处理,应抛出异常。 是 成功 0.016 测试JumpToNodeLB对象的Node属性为空时的处理,应抛出异常。 是 成功 0.000 测试JumpToNodeLB对象的PrevNode属性为空时的处理,应抛出异常。 是 成功 0.000 测试Param对象的Value属性为空时的处理,应抛出异常。 是 成功 0.000 测试流程属性对象的初始值为空时的处理,应抛出异常。 是 成功 0.000 测试流程属性对象的名字为空时的处理,应抛出异常。 是 成功 0.000 测试流程属性对象的类型为空时的处理,应抛出异常。 否 下面是相关的两个模板文件的内容: UnitTestReport.dt <%@ Template Name="" Language="C#" %><%@ Assembly Location="system.xml.dll" %><%@ Import Namespace="System.Xml" %><%@ Parameter Name="title" DataType="String" %><%@ Parameter Name="preparedBy" DataType="String" %><%@ Parameter Name="reportFileName" DataType="String" %> <%if (reportFileName == null || reportFileName.Length == 0) {   throw new ArgumentNullException("reportFileName");} XmlDocument doc = new XmlDocument();doc.Load(reportFileName);%><html>   <head>      <title><%=title%></title>   </head>   <body>      <TABLE cellSpacing="0" cellPadding="1" width="90%" align="center" border="0">        <!--DWLayoutTable-->         <TR>            <TD height="50" colspan="2" valign="top">           ......[阅读全文]

posted @ | Feedback (3) | Filed Under [ Techniques ]

摘要:Hi All, 我是Cavingdeep,也就是从前的Kefroth,可能有人认识我,没错,我改名字了。^_^博客堂专注于技术,希望不仅仅是.NET,因为我还有很多其他方面的技术可以分享哦!我的主Blog在CSDN上,欢迎交流!...[阅读全文]

posted @ | Feedback (12) |

摘要:XP作为一种还算年轻的软件研发的方法论目前应该可以说开始普及了。作为一个软件研发人员,我非常赞同XP理念,XP的理念中充满了使项目成功的关键思想,而这些思想不仅仅是技术上的,而是很大一部分是管理与沟通方面的。XP集成了许多最佳实践,而这些串连后的最佳实践使整个项目又变的有趣起来,这其中也包括了XP开发人员特有的积极向上的态度与责任心。这里我想向大家描述一下我个人的XP实践感受…… 下面我分别写一下我对XP中其中12种最佳实践的感受: 现场客户(On-Site Customer)。客户的需求不是一成不变的,往往在需求收集阶段事情总是很抽象,就连客户自己都不知道他们具体要什么,他们只是提供一个轮廓,要我们双方共同去构造理想中的产品。但是我们,包括客户都不可能预测说我们现在定下来的需求就是真正的一成不变的需求,总是有千万个理由会促使需求的变动,也就是说需求的变动是必不可免的,它不是单纯的可以人为控制的。那现在的问题是,但需求变动时,我们有能力迎接(适应)它吗?现在XP提出了几种最佳实践来迎接需求的变动,而其中一种既是On-Site Customer,通过客户在整个项目中的不断参与我们可以保证我们所作的一切都真正是客户想要的,而我们不会浪费时间与精力在不需要的功能上。这是按时交货,交好货的一种关键做法。注意这个最佳实践要求的并不是客户每天8小时的参与项目,而是但我们需要客户解答某些需求疑问时,客户能及时的提出意见,给出反馈! 小发行版(Small releases)。上面提到了需要客户能及时给出反馈,那么及时得到反馈的一种好的做法就是提供给客户软件的预览版,毕竟没有实物客户很难提出他们对我们正在做的项目的看法。XP要求小发行版正是这个用意,通过快速的小的迭代开发得到很多的小版本,然后将这些小版本拿给用户体验,收集反馈,再根据用户的反馈继续下一个小版本的迭代开发,这是一个良性循环,保证了项目不走歪路,保证了客户对我们正在做什么没有偏见,同时也保障了项目的质量,因为直接参与测试的同时也有我们的客户。 简单的设计(Simple Design)。上面讲的是从需求的角度出发的,现在让我们来看看开发流程方面。我们都知道设计是好的,而事物总是保持越简单越好,那么为什么不选择简单的设计呢?通过简单的设计我们可以快速的理解与开发。但是但靠简单的设计往往不是很有作用,很快我们就发现以往的设计已经不再有弹性,很快就不能满足我们的需要了。这里就是体现XP精华概念的时候了,XP中有极限一词,也就是说不管是做什么,都要做到极限。简单的设计也不例外,同样也要不断的迭代,通过在简单的设计上重构出另一种简单的设计来不断改变设计与设计质量,会让你在不知不觉间作出与超级设计大师一样优质的设计。(当然,如果你真的很糟糕,那么即使XP再好我想也帮不了你了) 规划策略(Planning Game)。既然简单的设计有助于快速的进展那么不断的规划也一定会帮助到项目的方方面面。很难说架构师做好的架构就一定不会在后期改变,既然需求都很有可能有大改变,那么架构与整体项目规划也不是一成不变的。这是XP的核心,XP告诉你如何迎接变化,如何在快速变化的今天作出最优质的产品,真正满足客户的需求。 系统隐喻(System Metaphor)。说实话,我也是刚刚开始真正了解XP,所以对这个实践还不太了解,所以这里就不谈了,免得败坏XP的名声!^_^ 重构(Refactoring)。我想很少有人在这个年代没有听到过重构吧?上面所讲的很多方面都是基于这个思想的。既然设计是好的,那么我们能不能快速的、小步的迭代设计呢?能不能通过不断的改善已有的代码来使它们更健壮呢?目前的项目大多数都会在维护一段时间后变的僵硬,代码越来越难以维护,有时不得不写一些自己都认为很难看的代码来维护新增或修改的功能,而正是这样的动作导致了下一次维护时的困难,使代码陷于了恶性循环,使的项目的维护成本越来越高,最后不得不放弃维护而重新开发。XP提出了迭代的重构方案,它使我们每一次都先重构再在重构好的代码的基础上再做修改,这使得我们每次都不用花太多的精力去完成对代码的维护而又与此同时提高了代码的简易度、健壮度。 结对编程(Pair?Programming)。既然对设计、对代码的评审是好的,那么为什么不随时评审呢?通过评审,我们可以用多个人的脑袋想问题,寻找解决方案,无疑这要比只用一个脑袋要好的多,毕竟人多力量大嘛,曾经也有教育家做过试验,证明了在群组讨论学习的环境下学生学到的知识更深刻,理解的更透彻,思想也更活跃。软件开发又何尝不是如此呢?我不完全赞成“结对”,但是我赞成有问题就问,不管什么样的问题,不管什么样的同事,只要你有疑问,那么你就可以向大家提出来,看看每个人的想法,这会使你最终得到一个当前最好的解决方案。 集体所有权(Collective Ownership)。在上个实践中其实已经提到了这个集体所有权的概念,既然你有问题就可以问,别人又都参与你给你他们认为的可能性答案,那么是不是反过来但别人有问题的时候你也要主动参与提出自己的看法呢?这种把多个大脑运作在一起的模式就是XP中集体所有权的概念了,在这里没有个人的殊荣,只有团体与团体的共同目标。注意这里就是XP的特点了,XP是以人为本,XP坚信人与人之间的作用要比单纯的依靠技术要更重要的多。毕竟只有最后依靠到人心上,项目才可能获得最后的成功。而作为一名XP开发人员也意味着你的个人休养与风格。 编码规范(Code Standards)。代码在XP中被看作一项非常重要的在开发人员之间沟通的工具。毕竟软件反映了开发者的心智,开发人员的思想变为一行行代码被写在程序中,这是一门艺术。但艺术也要有人去欣赏,如果每个人都看不懂其他人的艺术,那么怎么进行沟通呢?集体所有权让我们每个人都可以去改进其他人的代码,那么如果没有统一的编码规范将不是一件容易的事了。 一周40小时(40-Hour Week)。XP不主张加班加点,这只能是当有某些环节出问题的前兆。XP在每次快速的迭代中都很明确下一次迭代要做什么,XP有很高的可控性。 测试(Testing)。测试是XP的核心部分,是XP重要的环节,也正是处于这种原因,我将两种测试放在了最后面介绍,不是因为它们不重要,而相反是因为它们太重要了!测试其根本目的是为了保证质量,告诉我们所作的一切没有白做,它的确可行。XP中的自动化测试(常指简单有效的单元测试)是非常关键的,它有多重目的。其中一个很重要的目的就是给予我们开发人员信心,试想每次系统变动后运行自动化测试时看到一排路灯亮着是那么畅快的一件事啊!XP主张先测试后编码,每次的测试用例都能够反映出最确切的需求,测试亦是设计的一部分。其中的奥妙真的是只有真正用过才能体会得到。 持续集成(Continuous Integration)。这是另一种保证质量的测试手段,通过反复快速的集成我们可以及早发现软件中的隐患,同时持续集成也可以提供给我们多个小版本(Small Releases)以便客户的反馈。这个概念比较像微软提出的每日编译,只是XP并没有规定必须每日执行一次,XP反而主张每几个小时甚至每几分钟集成一次,总之就是当有较大变动时就及时集成给出反馈,这一点也能够充分的体现出XP极限编程中的极限来! 好了,以上是我个人在对XP有了一定充分的了解后所得出的结论,供给大家参考,我个人及其欣赏XP勇于创新的概念以及其在项目中的实际运用。虽然Kent Beck不主张将XP中的最佳实践剪裁掉使用(他主张将XP就像其概念一样统统发挥到极限,每一样都用的淋漓尽致),但是我个人还是同意每个组织根据其特性考虑去掉或消弱某部分实践来真正将XP运用起来,而不是只停留在大家都评论却没人敢去做的现象中。...[阅读全文]

posted @ | Feedback (30) | Filed Under [ Methodologies ]