自由行

2009-11-25

防御性设计

Filed under: 知识, 程序员 — Tags: — thomas @ 10:57

除0错误是一个典型的错误类型,也是程序设计时需要处理的问题。下面就介绍一个真实项目的例子。

在HB109R1 Camera项目中,时不时会出现除0错误,导致系统崩溃。后来经过分析发现,在图像缩放裁剪函数中对于尺寸参与了除法运算,如果传递进来的参数,长或宽为0,必然会导致除0错误。

解决这个问题的思路就是避免传递带0的参数,但是作为调用方,可能是嫌麻烦,几乎不做参数检查,结果传递的尺寸中有0,这就会导致除0了,系统也就必然会崩溃。

既然明确了原因,那么我们可以采取一个简单的防御设计。

TBool ValidateSize(TSize aSize);
TBool ValidateSize(TSize aSize)
{
	if (aSize.iWidth * aSize.iHeight == 0)
	{
		return EFalse;
	}

	return ETrue;
}

注意!只要有长或者宽有一个为0,则为无效参数。

在除法运算之前检查参数,如果检查失败,则跳过除法或返回。但是对于有返回值函数的就必须,有一个默认的返回值。当然这个返回值肯定不是调用者期望,不过这正好给调用者一个提醒,他传递了错误的参数。

2009-09-13

敏捷软件开发之旅(1)-一个重要的里程碑

Filed under: Projects Log, 程序员, 精益软件开发之旅 — thomas @ 23:03

v1.5.0是XqCap4的一个标签(svn tags) ,这个标签的软件实现手机拍照软件的核心功能。

作为手机拍照软件,主要的功能包括:
图片的拍摄、存储、查看;
视频的录制、存储、回放;
拍摄参数的设置,如:图片的尺寸,清晰度,曝光度等;
录制参数的设置,如:视频的尺寸(QCIF, QVGA, VGA…),编码格式等;
其中核心的功能是图片的拍摄、存储,视频的录制、存储,其次是图片的浏览、视频的回放;

在v1.5.0中除视频的回放没有实现,其它的已经实现了,当然只支持少量的参数设置。尽管最终目标还有一段距离,不过拍照和录视频的功能都实现了,而这些是需要和底层服务、驱动打交道的,比较困难,而其它的功能开发与一般的应用一致,难度就低很多了。解决了困难的问题,在演进中提炼和完善了架构设计,剩下的开发工作更有把握。可以说现在的状态是一个分水岭。如果说前面是一段上坡路,后面就是走下坡的路了,将会轻松很多。

从时间跨度上看,2009.08.22~2009.09.13,除08.29给人咨询移动应用开发的事情,精力主要花在开发上。在这23天中提交了82次代码,平均每天4次。每天晚上大概三个小时,4个周末全天10小时左右,共15*3 + 8*10 = 125小时,由于白天在公司也是开发,所以每天的开发时间将近12小时,确实比较累。

这中间对架构进行三次修改,这些修改对于敏捷软件开发来说是非常重要的,这也是笔者这次敏捷软件开发实践的初衷。架构如何演进出来而不是在最初就确定,是一个区别于非敏捷的重要特征,其中的一些细节问题留待后续文章叙述。

2009-07-29

[转]四十年软件工程故事

Filed under: 程序员, 转载 — thomas @ 12:19

2008.09.22  来自:CSDN   潘加宇

2008年5月14~16日,在德国迷人的小镇Garmisch,举办了软件工程四十年纪念会 议,Peter Naur、Brian Randell、M. Douglas McIlroy、Albert Endres、Luigi Dadda等40年前软件工程会议的关键人物重聚旧地。

40年前的1968年,正是在此地举行的NATO(北约)科技委员会会议上,“软件工程”作为正式的术语被确定下来,标志着一个新学科的开始。 Peter Naur和Brian Randell主编的会议报告中这样写道:“我们特意选择‘软件工程’这个颇具争议性的词,是为了暗示这样一种意见:软件的生产有必要建立在某些理论基础 和实践指导之上——在工程学的某些成效卓著的分支中,这些理论基础和实践指导早已成为了一种传统。”

软件工程这个学科还很年轻,Peter Naur和Brian Randell今天依然健在。作为著名的编程语言归约BNF范式中的N,Peter Naur因设计和定义了ALGOL 60而在2005年获得图灵奖。因IBM System360的工作于1999年获得图灵奖的Fred Brooks在《人月神话》的结尾比较了化学工程和软件工程。他认为:软件系统可能是人类所创造的最错综复杂的事物,软件工程还很年轻,需要继续探索和尝 试。

这四十年的过程就是探索和尝试的过程,让我们来细细品味其中的科学精神之美。

软件工程是什么

软件工程的定义有很多版本,比较权威的是IEEE给出的定义:(1)将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护,即,将工程应用于软件。(2)在(1)中所述方法的研究。

所以,软件工程远没有想象中那么高大神秘,它研究的就是我们日常开发软件的工作方式。“程序员”这三个字本就属于软件工程的范围。

关于软件工程和计算机科学的区别,Fred Brooks说:A scientist builds in order to learn; an engineer learns in order to build. 更详细的可以看看David Parnas的“Software Engineering Programs Are Not Computer Science Programs”和Steve McConnell所著“Professional Software Development”的第4章。或者对照一下图灵奖获得者:软件工程领域的David Parnas、Frederick P. Brooks和计算机科学领域的Donald E. Knuth、《程序员》上期介绍的YAO。

软件是为人开发的,软件是由人开发的。正是因为人的心理难以捉摸,人的大脑处理复杂性时速度和容量的局限,我们才需要过程来规范人的行为,需要方法 来帮助人脑面对复杂性,需要工具来贯彻这些过程和方法。所以,软件工程的知识体系分为以下几层。我们按照这个金字塔结构,逐层回顾四十年来的历史。

过程

一开始,软件团队是没有过程的,甚至没有团队概念。没有需求规格说明,没有设计,程序员在大脑中直接将代码思考出来,拼凑到一起,交给客户使用。客 户如果有要求,再修改代码,如此反复。这种“编码-修改”做法对于小程序可以应付,当程序规模变得复杂时,付出的代价就很大了。

瀑布

“软件工程”概念的提出,促进了需求、分析、设计、实现、维护等软件生命周期概念的成熟。瀑布模型是最早的软件过程模型,从名字“瀑布”可以看出, 通常人们认为瀑布模型中的各个步骤是一条线完成的。实际上在Winston W. Royce1970年的经典论文“Managing the Development of Large Software Systems”中有反馈的过程(见图3),作者本人也并不提倡以顺序模型作为团队的过程模型,另外,Royce并没有在论文中把他的过程模型叫做“瀑 布”,只是后来其他人这么叫了。很多团队使用时是按照线性的方式使用的,这是一种误解。

这里要提一下,瀑布模型的提出者Winston W. Royce(已于1995年去世)有时被简写为W. Royce,所以经常会引起误会,把他当成Walker Royce,后者是软件项目管理专家,曾任Rational软件公司副总裁,著有《Software Project Management: A Unified Framework》一书。

增量和迭代

使用瀑布模型,可以运行的产品很迟才能看到,这就潜伏了巨大的风险:很可能,集成之日也就是爆炸之日。为了提早获得可以运行的版本,可以先实现一些功能,再实现一些功能……每个增量交付一个可以运行的版本。

增量开发显著降低了风险,而且还因可运行产品的出现大大提升了士气。最有名的实践应该是Microsoft在1989年就开始使用的Daily Build(每日构建),被称为项目的“心跳”。当然,增量开发不一定意味着每日构建,如Fred Brooks所述,Bell Northern Research是“每周构建”。

增量经常和迭代连在一起说,不过两者是有区别的。增量是逐块建造的概念,迭代是反复求精的概念。二者不一定要绑在一起使用,但很明显,结合这两种方 式是一种有效的做法。现在很多过程所说的迭代开发,默认的意思就是增量&迭代。Jeff Patton最近用两幅图表达了增量和迭代(http://www.agileproductdesign.com/blog/dont_know_what_i_want.html)。

统一过程

1987年,Ivar Jacobson离开Eric-sson,成立了Objective Systems公司。他吸纳了增量迭代的思想,开发出Objectory过程,并且把过程当软件卖,价格卖到25000美元一份,以至于Ivar Jacobson不想在Addison-Wesley等出版社出书公开他的方法,因为卖一本书才得到3美元。1991年,Ericsson收购了该公司, 并更名为Objectory AB(北欧出大师,所以我们常在软件开发的书籍和文章中看到××AB等文字,AB是瑞典语Altiebolag的缩写,意思是“公司”),Ivar Jacobson又回到了Ericsson。

1995年,Rational从Ericsson收购了Objectory,Ivar Jacobson开始和Grady Booch、James Rumbaugh一起开发UML。Philippe Kruchten则负责把Objectory过程和Rational公司多年的积累Rational Approach融合在一起,开发出了“Rational Unified Process”以及4+1视图模型。RUP的中心思想是:用例驱动、架构为中心、迭代和增量。虽然是一个商业产品,但详尽的内容和灵活的组织,使得 RUP成为软件团队中流传最广的软件过程模型,也成为团队学习软件工程和实施过程改进的重要资料。

Ivar Jacobson在IBM收购后离开了Rational。2005年,他发布了Essential Unified Process(EssUP)将之描述为“超轻和超敏捷的”RUP,并且提出了过程定义(PD)和过程(P)的观点,他认为统一过程是一个过程定义 (PD),不是过程(P),团队不能看着别人的P好,就想着拿来就用,必须要找到自己的点。

2007年,Ivar Jacobson的新观点是“过程够了,实践吧(Enough of Processes: Let’s Do Practices)”。
Doug Rosenberg和Kendall Scott的ICONIX过程借鉴了Ivar Jacobson和统一过程的思想,而且以其小巧易懂,受到不少开发人员的欢迎。

敏捷运动

敏捷运动在20世纪90年代中期兴起,当时敏捷过程被称为“轻量”过程。2001年,Kent Beck、Alistair Cockburn、Ward Cunningham、Martin Fowler、Jim Highsmith、Ron Jeffries、Jon Kern、Robert C. Martin、Steve Mellor、Ken Schwaber等人聚集在犹他州的Snowbird,决定把“敏捷”作为新的过程家族的名称,并提出以下宣言:

随后,敏捷联盟成立,这是一个致力于传播敏捷过程的非营利组织。敏捷联盟每年召开敏捷大会,今年已经是第6年。

关于敏捷过程,比较全面的介绍文章是Martin Fowler的“The New Methodology”。每隔一段时间,Fowler会随着形势的变化更新此文。该文2005年12月版本列出的各种流行敏捷过程包括:极限编程 (XP)、Scrum、Crystal、上下文驱动测试(Context Driven Testing)、精益开发(Lean Development)、统一过程(Unified Process)。

极限编程(XP)是敏捷过程的代表。1996年,Kent Beck为了挽救Chrysler Comprehensive Compensation (C3)项目而创建了XP过程,虽然Chrysler最终取消了该项目,但是Ron Jeffries和Ward Cunningham等人参与到了XP的工作中。1999年,Kent Beck出版了“Extreme Programming Explained: Embrace Change”一书。XP一代相当于程序员的宣言,受到了程序员的热烈欢迎。2004年,该书第2版出版,Kent Beck说自己几乎完全重写了整本书,书中关于程序员是宇宙中心的内容少了很多,更多的是谈程序员和编程工作必须处于业务环境中,他们需要成为正常商业世 界中的一部分。

过程评估和CMM

从1968年开始,Watts S. Humphrey是IBM负责软件部门的副总裁。1986年,Watts S. Humphrey离开IBM后,加入了SEI(卡内基?梅隆大学软件工程研究所),开始开发CMM(Capability Maturity Model,能力成熟度模型)。CMM一开始的目的是为军方制定一个好用的评估承包商的标准,因为SEI本来就是军方资助的机构。

1989年,在《Managing the Soft-ware Process》一书中,Humphrey描述了CMM。CMM可以看作是一个软件过程元模型,定义软件组织达到一定能力成熟度所需的关键过程域(KPA)。
20世纪90年代中期,CMM开始在世界范围内流传开来,成为一些政府采纳的评估软件组织的标准,政府甚至对通过评估的软件组织加以资助。在这种激励下, 想获得政府订单或者政府资助的软件组织纷纷力争通过CMM评估。目前,通过CMM/CMMI评估的组织数量前三位国家是:美国、印度和中国。

方法

在20世纪60年代,程序员随意地编写代码。虽然当时已经出现了FORTRAN等高级语言,但程序员把代码写在一起,代码中使用GOTO语句来跳转,使得程序的内部结构像“意大利面”,整个程序又像一块铁板,无法单独抽取其中一部分复用。

功能分解

1968年,Edsger W. Dijkstra发表《Go To Statement Considered Harmful》,认为GOTO语句是有害的,应该把程序划分成多个子单元,每个子单元只做一件事,当重复的语句集合出现时,只需要调用相应子单元(函 数)。这相当于封装和复用了共同的行为。

数据流

当软件的规模不断变大,大到不能一下子映射到代码级别时,就需要更大颗粒的分析设计方法。20世纪70年代,数据流法出现了,有三种流行的流 派:DeMarco方法(1978)、Gane/Sarsen方法(1979)以及Yourdon/Constantine方法(1979)。

数据流法把系统看作数据的加工机,数据流进去,经过加工,变成新的数据流出来。从最顶层开始(因为此时系统看作是一个整体,所以表达的就是功能需求),一层一层向下求精,一直求精到泡泡所代表的加工成为可以编码的动作。

实体/关系

20世纪70年代末,关系数据库开始变得流行。Peter Chen(陈品山)在1976提出实体关系(ER)模型,用实体和关系映射现实中的事物和概念。该模型提供了数据的图形视角,并能轻松转换为关系数据库模 型。分析员很快认识到,ER模型可以用来表达大型软件的数据库设计,更宏观地把握业务,而且还有助于分析员和用户交流。

数据流法结合实体关系法,曾经是比较流行的开发软件的方法。这种做法的一个问题是数据和行为是分离的,行为可以随意读写数据。另一个问题是分析和设计之间表达不一致,使得从设计回溯到分析相当困难。这正是面向对象分析设计所要改进的。

面向对象

Alan Kay说“面向对象”这个词是他在1967年首先使用的(http://www.purl.org/stefan_ram/pub /doc_kay_oop_en),但人们普遍认为,1967年由挪威的Ole-Johan Dahl和Kristen Nygaard设计的Simula-67是第一门面向对象语言,它是作为ALGOL的一个超集出现的。虽然Simula没有后继版本,但这个语言对后来的 许多面向对象语言的设计者产生了很大的影响,80年代初,Alan Kay在Palo Alto研发的Smalltalk语言被广泛使用(Kent Beck就是Smalltalk的拥护者),掀起了一场“面向对象运动”,许多面向对象语言随之诞生。Grady Booch在他的最新著作“Object-Oriented Analysis and Design with Applications”第3版中归纳。

面向对象的思想就是:假设系统由“对象”这样一种东西构成,对象封装了结构和行为。这种思考方式和人类的认知相当贴近,更有利于人脑去把握问题的复杂性。分类是人类认知的一种基本技能,分类哲学的讨论可以追溯到柏拉图的《政治家》和亚里士多德的《范畴》。

结构化分析设计和面向对象编程之间不能很好地过渡,到1980年代后期,不同的方法学家开始提出自己的面向对象分析设计方法学。这些方法学主要 有:Booch、Shlaer/Mellor、Wirfs-Brock责任驱动设计、Coad/Yourdon、Rumbaugh OMT、Jacobson OOSE。

UML

这种百花齐放的局面带来了一个问题:各方法学有自己的一套概念、定义、标记符号和术语,但总的来说大同小异。这些细微的差异通常会造成混乱,使开发人员无从选择,也妨碍了面向对象分析设计的推广。
1994年,在Rational工作的Rumbaugh和Booch开始合并OMT和Booch方法。随后,Jacobson带着他的OOSE方法学也加 入了Rational公司,一同参与这项工作。他们三个人被称为“三友”(three amigo)。这项工作造成了很大的冲击,因为在此之前,各种方法学的拥护者觉得没有必要放弃自己已经采用的表示法,而接受统一的表示法。

1996年,三友开始与James Odell、Peter Coad、David Harel等来自其他公司的方法学家合作,吸纳了他们的成果精华。1997年9月,所有建议被合并成一套建议书提交给OMG。1997年11月,UML被 OMG全体成员一致通过,并采纳为标准。UML诞生时,Martin Fowler就作了如下预测:

你应该使用UML吗?一个字:是!旧的面向对象符号正在快速地消逝。它们还会残留在UML稳固前出版的书上面,但新的书、文章等等将会全部以UML 作为符号。如果你正在使用旧的符号,你就应该在1998年间转换到UML。如果你正要开始使用建模符号,你就该直接学习UML。

时间过去10年了,事实正是如此。以UML为契机,掀起了一股普及软件工程的热潮,比起UML出现之前,软件工程的书籍出现了爆炸性的增长。制定 UML标准的角色(OMG)、根据标准开发工具的角色(UML工具厂商)、使用UML工具开发软件的角色(开发人员)这三种角色的剥离,也导致建模工具数 量和种类出现了爆炸性的增长。

现在,UML已经被ISO吸纳为标准,UML1.4.2即ISO/IEC 19501,UML2.1.2即ISO/IEC 19505。

模式运动

1979年,Christopher Alexander开始使用“模式”来描述建筑的构造方法。1987年,Kent Beck和Ward Cunningham尝试把这种思路应用到软件开发中,并在OOPSLA大会上发表了自己的看法。一直到1994年10月,被称为四人帮(GoF)的 Erich Gamma, Richard Helm, Ralph Johnson和John Vlissides所写的《设计模式》上市(此书是1995年的版权,看来国内外出版业差不多,我们可以在2007年12月买到2008年1月第1版的 书),模式的概念才流行起来。此书到2007年为止共重印36次,被翻译成13种其他语言,而且有不计其数的兄弟书籍诞生出来,“言必称模式”成为一种时 髦,可谓影响深远。

现在,除了最常提到的GoF的23种设计模式之外,不断有各种各样的模式提出来,包括分析模式、架构模式、过程模式、组织模式、实现模式、反模式……

工具

很长一段时间内,软件开发工具指的就是代码工具,而且编辑、调试、编译是分离的。后来慢慢出现了IDE(集成开发环境),各大工具厂商更是在IDE市场激战。这方面的故事,大家可以看李维的《Borland传奇》。

在软件工程工具如分析设计、过程管理等工具方面,却是一片空白。一直到1982年,Nastec公司开发出了DesignAid,该工具提供绘制系 统设计图和建立数据字典的功能。到了1990年代,随着方法学繁荣和图形界面的普及,才出现了大量的设计工具,典型的代表是Rational Rose和Popkin System Architect。

最初的设计工具以独立的产品存在,而且只是提供了画图的功能,然后慢慢有了代码正向逆向工程。开发人员在设计工具里建好模型,再通过一个转换器在代 码环境生成代码。设计工具的一个变种是成为代码环境的插件(Rational XDE,Together for VS.net等),直接在代码环境中创建设计模型,和代码高效同步。

接下来的趋势是设计工具和生命周期其他工具集成。2002年10月,Borland收购了当时UML工具厂商中的老二Togethersoft,这 成为了导火索。之后,IBM、Telelogic、Borland等大厂商通过并购和放弃,打造出了新的品类——应用生命周期管理(ALM)工具。微软的 工具Visual Studio Team System也在朝ALM工具方向进化。图12列出了三家ALM厂商一些产品的对比。

现在,Rational和Telelogic都已经被IBM收入旗下,但Sparx Systems、NoMagic、Gentleware等中小厂商纷纷加入到这个市场中,竞争依然激烈。我们来看看代表性厂商Rational的历史,也可以从一个侧面了解工具的发展。

结语

1999年,我创建了UMLChina,从那时开始关注软件工程各方面的进展。到现在为止,我已经上门为超过100个软件开发团队提供需求和设计技 能(根据我们上面的分类,这属于“方法”层面)服务。我发现一个有趣的现象,在开始服务之前的商议过程中,很多开发团队(不是每个团队)或多或少都会有人 (不是每个人)或明或暗地表达出这样的观点:自己团队的难处与众不同,奇特的困难降临在他们身上,偏偏别人得以幸免。

尽管UMLChina一直强调自己的服务是“聚焦最后一公里”,坚信每一个开发团队都会在细节上和其他团队有所不同,而且也应该有所不同。但很多时候,我还是感觉到,开发团队还是高估了自己的“个性”,低估了“共性”。

最核心的共性问题,仍然是质量——能最大化获取利润的质量。它无非是两条路:增加收入——如何把东西更好地“卖”出去(给客户,给领导……);减少 成本——如何用可复用的要素(组件、过程……)降低制造的成本。这些正是软件工程的不同分支(需求工程、架构设计、过程改进……)要研究的。四十年来的研 究成果,肯定会有一些适合您的团队。这些成果是先行者们从自己或别人的血泪中提炼出来的,我们没有必要再重复挥洒血泪了。

潘加宇,UMLChina首席专家,潜心研究和实践UML/UP相关技术的应用。

2009-07-18

搜索你自己

Filed under: 程序员, 随笔 — thomas @ 23:37

今天看到一篇关于社交网站的报道,提到了个人隐私信息的保护问题。晚间觉得无事,便用自己的姓名搜索了一番。

谷歌的结果:(为了保护隐私信息略去姓名,大家可以自己尝试一下)
Results 1 – 10 of 10 Chinese (Simplified) pages for “xxx“. (0.05 seconds)

百度的结果:
百度一下,找到相关网页7篇,用时0.016秒

结果发现,几年前在某网站上传了一些代码。当初上传本省是为了方便网友下载,结果那个网站实行“配额制”,也就是说需要上传才能下载,可是又会有几个人愿意或者方便的传代码上去交换呢?于是除了有26次下载外,只是“沉睡”在某个网站的服务器硬盘盘中。

最初传到51files网站的内容,不到一年就失效了,估计网站已经不复存在了。如今笔者自己开设个人网站,想当初花了数个夜晚编写的代码,尽管功能不多,也属不易。那就放在自己的网站上吧,共网友下载、学习。

[相关链接]

ARP协议浅析(4):回顾

http://liuxk.net/blog/?p=155

2009-06-04

项目手记(3)-”不期而遇”

Filed under: Projects Log — thomas @ 23:46

Late evening, To be Eidted.

2009-05-27

使用命令重定向操作符 (Redirection Operators)

Filed under: 程序员, 随笔 — thomas @ 23:17

使用命令重定向操作符 (Redirection Operators)

摘自<Windows帮助和支持中心>
Microsoft Windows 图形

使用命令重定向操作符 (Redirection Operators)

可以使用重定向操作符将命令输入和输出数据流从默认位置重定向到不同的位置。输入或输出数据流的位置即为句柄

下表列出了可用于将命令输入和输出数据流进行重定向的操作符。

重定向操作符 说明
> 将命令输出写入到文件或设备(例如打印机)中,而不是写在命令提示符窗口中。
< 从文件中而不是从键盘中读入命令输入。
>> 将命令输出添加到文件末尾而不删除文件中的信息。
>& 将一个句柄的输出写入到另一个句柄的输入中。
<& 从一个句柄读取输入并将其写入到另一个句柄输出中。
| 从一个命令中读取输出并将其写入另一个命令的输入中。也称作管道。

默认情况下,可以从键盘将命令输入(即 STDIN 句柄)发送到 Cmd.exe,然后由 Cmd.exe 将命令输出(即 STDOUT 句柄)发送到命令提示符窗口。

下表将列出可用的句柄。

句柄 句柄的数字代号 说明
STDIN 0 键盘输入
STDOUT 1 输出到命令提示符窗口
STDERR 2 错误输出到命令提示符窗口
UNDEFINED 3-9 这些句柄由应用程序和各个具体工具单独定义。

数字 0 到 9 代表前 10 个句柄。可以使用命令 Cmd.exe 运行程序并将前 10 个句柄中的任何一个重定向到该程序。要指定想使用的句柄,可在重定向操作符前面键入该句柄的数字。如果未定义句柄,则默认的 < 重定向输入操作符是 0,而默认的 > 重定向输出操作符是 1。键入 > 或 < 操作符之后,必须指定要读取或写入数据的位置。可以指定文件名或另一个现有的句柄。

要指定重定向到现有句柄,请使用与 (&) 字符,后面接要重定向的句柄号(例如 &句柄#)。例如,下面的命令可以将句柄 2(即 STDERR)重定向到句柄 1(即 STDOUT):

1<&2

复制句柄

重定向操作符 & 可以将输出或输入从一个句柄复制到另一个指定的句柄。例如,要将 dir 输出发送到 File.txt 并将错误输出发送到 File.txt,请键入:

dir>c:\file.txt 2>&1

复制句柄时,可以复制该句柄原状态的所有特性。例如,如果一个句柄具有只读访问的属性,则该句柄的所有副本都具有只读访问属性。不能将一个具有只读访问属性的句柄复制为另一个具有只写访问属性的句柄。

重定向命令输出 (<)

要从键盘或设备重定向命令输出,请使用 < 操作符。例如,要从 File.txt 得到 sort 命令的命令输入,请键入:

sort<file.txt

File.txt 的内容将以字母顺序列表的方式显示在命令提示符窗口中。

< 操作符可以打开具有只读访问的指定文件名。所以,不能使用该操作符向文件中写入信息。例如,如果以 <&2 启动程序,则所有试图读取句柄 0 的操作都将失败,因为句柄 2 最初是以只读访问打开的。

注意

  • 0 是 < 重定向输入操作符 > 的默认句柄。

重定向命令输出 (>)

几乎所有的命令都将输出发送到命令提示符窗口。即使将输出发送到驱动器或打印机的命令也会在命令提示符窗口显示消息和提示。

要将命令输出从命令提示符窗口重定向到文件或设备,请使用 > 操作符。可以在许多命令中使用该操作符。例如,要将 dir 输出重定向到 Dirlist.txt,请键入:

dir>dirlist.txt

如果 Dirlist.txt 不存在,Cmd.exe 将创建该文件。如果 Dirlist.txt 存在,Cmd.exe 将使用 dir 命令的输出替换文件中的信息。

要运行 netsh routing dump 命令,然后将命令输出发送到 Route.cfg,请键入:

netsh routing dump>c:\route.cfg

> 操作符可以打开具有只写访问属性的指定文件。所以,不能使用该操作符读取文件。例如,如果使用重定向 >&0 启动程序,则所有试图写入句柄 1 的操作都将失败,因为句柄 0 最初是以只读访问大开的。

注意

  • 1 是 > 重定向输出操作符的默认句柄。

使用 <& 操作符重定向输入和复制

要使用重定向输入操作符 <&,指定的文件必须已经存在。如果输入文件存在,Cmd.exe 将以只读方式打开该文件,然后将文件中作为输入的字符发送到此命令(如同从键盘输入一样)。如果指定了句柄,Cmd.exe 将指定的句柄复制到系统现有的句柄中。

例如,要以句柄 0 输入读取(即 STDIN)的方式打开 File.txt,请键入:

<file.txt

要打开 File.txt,并在内容分类后将输出发送到命令提示符窗口(即 STDOUT),请键入:

sort<file.txt

要查找 File.txt,然后将句柄 1(即 STDOUT)和句柄 2(即 STDERR)重定向到 Search.txt,请键入:

findfile file.txt>search.txt 2<&1

要以句柄 0 输入读取(即 STDIN)的方式复制用户定义句柄 3,请键入:

<&3

使用 >& 操作符重定向输出和复制

如果将输出重定向到文件且指定了现有的文件名,Cmd.exe 将以只写方式打开文件并覆盖该文件内容。如果指定了句柄,Cmd.exe 将文件复制到现有句柄中。

要将用户定义句柄 3 复制到句柄 1,请键入:

>&3

要将包括句柄 2(即 STDERR)的所有输出从 ipconfig 命令重定向到句柄 1(即 STDOUT),然后将输出重定向到 Output.log,请键入:

ipconfig.exe>>output.log 2>&1

使用 >> 重定向操作符追加输出

要从命令中将输出添加到文件末尾而不丢失文件中已存在的任何信息,请使用两个连续的大于号(即 >>)。例如,下面的命令可以将由 dir 命令生成的目录列表追加到 Dirlist.txt 文件:

dir>>dirlist.txt

要将 netstat 命令的输出追加到 Tcpinfo.txt 的末尾,请键入:

netstat>>tcpinfo.txt

使用管道操作符 (|)

管道操作符 (|) 可以提取一个命令的输出(默认情况下是 STDOUT),然后将其导入另一个命令的输入中(默认情况下是 STDIN)。例如,下面的命令将对目录分类:

dir | sort

在本例中,将同时启动两个命令,但随后 sort 命令会暂停,直到它接收到 dir 命令的输出为止。sort 命令使用 dir 命令的输出作为输入,然后将输出发送到句柄 1(即 STDOUT)。

合并带重定向操作符的命令

可以通过合并带有其它命令和文件名的筛选器命令创建自定义命令。例如,可以使用以下命令存储包含“LOG”字符串的文件名:

dir /b | find “LOG” > loglist.txt

dir 命令的输出通过 find 筛选器命令发送。包含字符串 “LOG” 的文件名作为文件名列表(例如,NetshConfig.log、Logdat.svd 和 Mylog.bat)存储在文件 Loglist.txt 中。

要在相同命令中使用多个筛选器,请使用管道 (|) 分隔筛选器。例如,下面的命令将搜索 C 盘上的每个目录以查找包含 “LOG” 字符串的文件名,并且在命令提示符窗口中每次显示一屏:

dir c:\ /s /b | find “LOG” | more

利用管道 (|) 可以将 Cmd.exe 导向为通过 find 筛选器命令发送 dir 命令输出。find 命令只选择包含字符串 “LOG” 的文件名。more 命令可以显示由 find 命令选择的文件名(在命令提示符窗口中每次显示一屏)。有关筛选器命令的详细信息,请参阅筛选器命令

2009-05-26

项目手记(2)-用户界面与数据分离

Filed under: Projects Log — thomas @ 00:20

谋未定,不动。虽然很想着手写代码,但是却又不知如何写,难免有些无奈。

工作之余开始考虑,昨天似乎是很清晰的分析,竟然变得模糊起来。这也怪自己,当时分析了主要功能点,和实现的顺序,不过没有用笔记录下来。今天经过一天的忙碌,把原先的记忆冲淡了。只能老老实实的再做一次分析。首先要考虑与界面有关的功能,比如与外部应用的交互,应用内部的功能相对应切换等。

对于应用来说,界面与数据分离是很大的挑战。而对于s60应用而言,利用现成的AppUi/View/Container/Controls框架来规划架构比较合适。

做一下简单罗列:

1. 安排多少个View;

2. 每个View里有哪些Container;

3. 如何加载Control,支持半透明效果;

4. 用户事件处理;

做了一些尝试后发现,还是从大的层次确定,也就是先确定AppUi,然后确定View,再确定View中的Container和之下的控件。调整了几次后得到类的层次和对象的归属关系。

值得说明的是,Avkon的View并不是直接的UI类。因为它不能直接接受用户输入,也不直接绘制窗口,但它可以作为容器,拥有Container,而AppUi将事件派发给Container,它继承自CCoeControl。与View对立的概念是Mode或者说是数据,所谓用户界面与数据分离,主要是View和Mode的分离,给出一个清晰的界限。

2009-05-25

项目手记(1)-框架分离

Filed under: Projects Log — thomas @ 00:50

在S60v5.0上进行框架分离,析出AppUi, View, Container三个UI类别。

1. S60v5.0的模拟器比起SEMC内部SDK中的要快很多,大约20s能够启动完成;所以在S60上析出框架,最后在目标SDK上验证,这样就能节省大量时间;

2. svn的目录整理甚是繁琐,尤其是目录,文件名的更改,涉及的项目文件,头文件包含也必须要改;

3. 实例类需要调用框架类的虚函数,框架包含了一部分设计决策;

2007-05-05

基于Socket的应用的程序流程的备忘

Filed under: 程序员 — thomas @ 01:32

借用别人的流程图来提醒自己在网络应用编程的时候,设计好的程序流程。这个流程图,在网络上被多次引用,笔者很难找到出处,故无法说明。
该图是面向连接的套接字的基本流程,这张图非常值得我们借鉴。

Socket应用流程图

2007-04-05

程序设计之道

Filed under: 思想, 程序员, 转载 — thomas @ 22:56

程序设计之道

THE DAO OF PROGRAMMING                                                 Geoffrey James

程序设计之道 冼镜光

微电脑时代9697

程序设计之道1

第一部 寂静虚无篇2

1.1 2

1.2 2

1.3 2

1.4 2

第二部 古之大师篇2

2.1 2

2.2 3

2.3 3

第三部 设计篇3

3.1 3

3.2 3

3.3 4

3.4 4

第四部 写作篇4

4.1 4

4.2 4

4.3 5

4.4 5

第五部 维护篇5

5.1 5

5.2 5

5.3 6

5.4 6

第六部 管理篇6

6.1 6

6.2 6

6.3 6

6.4 7

七部 公司智慧篇7

7.1 7

7.2 7

7.3 7

7.4 8

第八部 硬件与软件篇8

8.1 8

8.2 8

8.3 8

8.4 9

第九部 尾声9

第一部 寂静虚无篇

大师如是说:“学会从程序抓虫子之后,就可以毕业了”。

1.1

寂静虚无中有奥秘,不动不静,乃程序之源,吾无以名之,故称之为程序设计之道。若道至大,则操作系统至大;

若操作系统至大,编译程序亦然;

若编译程序至大,则应用程序亦复如是,是故使用人大悦,世有和谐存焉。

1.2

程序设计之道无远弗届,虽晨曦微风而返。

道生机器语言,机器语言生组译程序。

组译程序生编译程序,于是万余语言存焉。

各语言有其目的,均表达软件之阴阳;其在道中亦各得其所。

但若能避免,就不要用COBOL写程序。

1.3

太初有道,道生时空,故时空乃程序设计之阴阳。

程序员不悟道则时空永不敷使用,悟道者恒有充份时空完成目标。

1.4

上智程序员闻道而行之,中智程序员闻道而求之,下智程序员闻道而笑之。

若无笑声则无道矣。

至高之声难以听闻。

前进就是后退之路;大智总是晚成;每一个完美的程序仍有BUG

道在所有知识之外。

第二部 古之大师篇

大师如是说:”三日不写程序则生命无趣。

2.1

古程序员神秘而深奥,无以度量其思维,仅能描述其表象。

像狐狸涉水般地小心;像战场老兵般地警觉;像未经琢磨的木头般地璞拙;

像洞中深潭地不透明。

谁能指出他们心灵中的秘密?

答案全在道中。

2.2

大师Turing曾经梦到他是一部计算机,醒后道:

“不知是我Turing做梦变成机器,还是一部机器做梦变成我Turing。”

一家大计算机公司的程序员参加软件会议后,向他的经理报告说:“你知道其它计算机公司有什么程序员吗?他们不修边幅,头发长而邋遢,衣服既旧且皱,他们破坏了气氛,而且我简报时老是制造噪音。”

经理说:“我根本就不应该派你参加会议,这些程序员超然物外,他们把生命看成无稽,意外的结合。他们往来而无藩篱,为他们的程序而活,为什们他们一定要受社会积习的约束?

他们生活在道中。”

2.3

生手问大师:“有一个程序员从不设计,测试程序,写作文献,但了解他的人都认为他是世间最好的程序员。为什么?”

大师曰:“这个程序员已充份悟道,他超越了设计的需要;系统垮了不会生气,而无条件接受这个世界。他超越了文献的需要,他不再计较是否有人看他的程序。

他也超越了测试的需要,他的每一个程序都圆满无缺,清澈,优雅,目的自明。

是的,他已悟道,登堂入室。

第三部 设计篇

大师说:“到测试程序时再回头修改设计就太迟了。”

3.1

曾经有人在参观计算机展时,每天进门时都向警卫说:“我是的妙贼,偷东西的技巧已臻化境,先告诉你,我绝不会放过这次展览。”

这段话刺激到警卫,因为展览场有好几百万元价值的仪器,所以老是盯着他,不过却只看到这个人一个摊位接着一个摊位看,哼着小曲而已。

在这个人出门的时候,警卫把他带到一旁搜身,但却找不到什么。

第二天这个人又来了,而且教训警卫说:”昨天我收获不错,不过今天会更佳。”

所以警卫就更加注意他了,但是仍然没有结果。

最后一天警卫终于忍不住好奇心,问那个人:”贼大师,我给您弄得寝食难安,您是否以教我,究竟偷了些什么?”

这个人笑笑,说:“我偷的是概念。”

3.2

从前有一位大师专写没有结构化的程序,一个生手模仿他,也开始写没有结构化的程序。当这位生手要求大师评量进展时,大师却批评他写作没有结构化的程序。

大师说:“对大师适用的不一定适合生手,在能超越结构化之前,必须先悟道。”

3.3

某长官问程序员:”设计会计系统与操作系统,那一个比较简单?”

程序员说:”操作系统。”

长官发出不相信的惊呼:“很显然的,会计系统不如操作系统复杂”,他说。

“不!”程序员回答,“在设计会计系统时,程序员是各种不同主意的人之间的桥梁,这些主意不外乎:系统要如何作业?报表型式如何? 要如何迎合税法?。。。等等。

反过来,操作系统却不受外界表象的限制;在设计操作系统时,程序员寻求人与机器间最纯的和谐,这就是为什么操作系统容易设计。”

长官点头微笑,称是:“但是那一个容易侦错?”

程序员没有回答。

3.4

经理去见大师,并且告诉他一套新应用程序文件的需求规格,问道:“如果我给你五个程序员,要多久才能设计好这个系统?”

大师很快回答:“一年。”

“但是我们需要马上用这个系统!如果我给你十个程序员,那要多久?”经理说。

大师皱眉说:”这要两年。”

“如果我给你一百个程序员呢?”

大师耸耸肩:“这个系统根本作不出来了。”

第四部 写作篇

大师如是说:“写作良好的程序本身自成天堂,写得差的程序本身就是地狱”。

4.1

程序要轻灵,子程序像一串珍珠。程序的精神与意图应始终如一,不多不少;

没有多余的循环,也没有额外的变量,既不缺少结构,也不过分笨重。

程序应该追随“最低惊讶定律”,这是什么?

简单得很,使用人对程序的反应是惊讶的机会要愈低愈好。

程序不管再复杂,应该以一个整体相互作用;他应该用内部逻辑,而不是外在的表象来指导作业。

如果程序不满足这些要求,就会杂乱而易生混淆,唯一的补救就是重新写过。

4.2

生手问大师:“我有一个程序,有时候作得很好,有时候却不行;我一直遵行程序设计的规律,但是却把我弄得很困扰,其理安在?”

大师答曰:”因为不悟道才会如此,只有笨蛋才会期望他的同侪有合理的行为,而你却对人类生产的机器有所期望?!计算器只模拟了决定论,只有道才十全十美。

程序设计的准则还是暂时性的,只有道才会进入永恒。所以,你在开窍前要先思索道。”

“但我要如何才能知道已经开窍了呢?”生手问。

大师回答:“从此以后,你的程序都能正确执行。”

4.3

大师对弟子说:“不论软件之为大为小,道在所有软件中。”

“桌上型计算器有道吗?”弟子问。

“有!”大师答。

“电动玩具程序中有道吗?”弟子续问。

“也有!”大师说。

“那个人计算机的DOS 中有道吗?”

大师咳一下,轻轻挪动了位置,“下课”,他说。

4.4

皇太子的程序员正在写作软件,指尖在键盘上飞舞,程序顺畅无误的编译完成,执行起来像阵微风轻拂而完美的结束。

“了不起!”,太子叹曰:“你的技巧无懈可击。”

“技巧?”程序员从终端机上转过头说,“我所信从的是道,道超越任何技巧!”

我开始学写程序时,在我眼前所见是混成一片的程序;三年后,不再见到这一大片程序了,我学会使用子程序;现在,眼前一片空灵,什么都没有了,所有东西都进入无型式的一片静寂;所有感觉都不必作用。

我的精神可以依直觉而不必依照任何计划行事,换言之,我的程序自己写作自己。

当然,有时会有困难的问题;我看着他们到来,我降低自己的速度,静静的看,改一列程序之后困难就会烟消云散;我再重新静静坐着欣赏工作的欢乐。我闭上双眼一会儿,然后关机。”

皇太子说:“我的所有程序员都那么聪明睿智吗?”

第五部 维护篇

大师如是说:”虽然程序只有三列,但总有一天需要维护。”

5.1

常用的门不必上油。

急流不会淤塞。

声音与思想不能在真空中传递。

不用的软件会生锈。

这就是至大的奥秘。

5.2

经理问程序员究竟要多久才能把手上的程序写完。“明天”,程序员很快的回答。

经理说:“我想你不太踏实;真的要多久?”

程序员想了一会儿:“我希望在程序中加上一些东西,这至少要两周。”程序员终于说:“时间还是短了一些”,经理坚持说:“如果你能简单的告诉我什么时后能写完我才会满意。”

程序员同意这一点。

几年后经理退休了,在欢送餐会上发现那个程序员伏在终端机上睡着了,因为他写程序写了整夜。

5.3

一个生手被分派去写一个单纯的财务软件。

这个生手狂热地工做了几天,但是当大师看他的成品时,却发现这个程序中包含一个荧光幕编修程序,一组一般性的绘图程序,一个人工智能界面,但却没有什么与财务方面有关。

大师就问他,这个生手却变得很激动:“不要那么没耐心,”他说,“我最终会把财务

部份加上去。”

5.4

好农夫会忽视他种的谷子吗?

好老师会忽略他最差的学生吗?

好父亲会容许他的孩子挨饿吗?

好程序员会拒绝维护自己的程序吗?

第六部 管理篇

大师如是说:“程序员要多,经理要少,生产力就会增加。”

6.1

经理有开不完的会的话,程序员就会写电玩;主计部门想到利润,发展经费就会被删减;高级科学家谈到蓝蓝青天,那么青天一定会有浮云飞过。

当然,这不是程序设计之道。

当经理许下承诺,程序员就不理会电玩;当主计部门有长程规划,就会回复和谐与秩序;当高级科学家处理手上的问题,问题很快就会解决。

这才是程序设计之道。

6.2

为什么程序员没有生产力?因为他们的时间都花在开会上头。

为什么程序员难以驾御?因为管理阶层干预太多。

为什么程序员一个接一个辞职?因为他们精力耗光了。

在不良管理下工作,程序员不会觉得他的工作有价值。

6.3

某个经理快被炒鱿鱼了,但是他底下的一个程序员写了一个叫好又叫座的程序;

当然,这位经理因而保住了饭碗。

经理打算给这位程序员一点奖励,但他拒绝接受,并且说:“因为我觉得这是个有

趣的概念,才会写这个程序,所以我不希望有奖励。”

经理听了之后说:“这个程序员虽然职位不高,但却充份了解做为一个职员的责任,

让我们把他升成崇高的管理顾问吧!”

在告诉程序员时,他再度拒绝,说:“我之存在是因为可以写程序,如果升了我,

那除了浪费每一个人的时间外而成不了事。我可以走了吗?我还得写程序。”

6.4

经理告诉程序员们说:“下面是你们的工作时间: 早上九点来上班,下午五点钟下班。”

所有程序员都很生气,有几个马上辞职。

于是经理说:”好吧!这样好了,只要能够如期完工,工作时间由你们自定。”程序员现在满意了,每天中午开始工作,直到第二天早上。

第七部 公司智慧篇

大师如是说:“你可以对主管示范一个程序,但无法让他通晓计算机。”

7.1

生手问大师:“遥远东方有一个叫‘公司总部 ’的伟大树状结构,上面满满地标上了些副总裁,会计长等的图案”。它发出大量的备忘录,每张上面都写了‘收文!’,‘发文!’没有人知道是什么意义。每年 都会把新的名字加到新的分枝上,但似乎全都徒劳无功。为什么这样一个不自然的组织还能继续存在?”

大师回答说:“你已经体认到这个庞大的结构,而被它不合理的目的困扰。”

不过你能不从它无休止的回旋而得到乐趣吗?能够不欣赏深藏在枝叶底端毫无困难的程序设计吗?为什么要被他的无用而困扰呢。”

7.2

东方海上有大鱼曰鲲,鲲能变成双翼遮天的大鹏。当大鹏飞越陆地时带来一道公司总部的讯息,这道讯息正好掉在一群程序员中央,然后大鹏折起双翼乘风而归。

生手程序员瞪眼望着大鹏,因为他们不认得;

中智程序员忧大鹏的来临,因为他们害怕它带来的讯息;

只有大师才能继续坐在终端机前工作,因为他不知大鹏的来去。

7.3

象牙塔的魔术师带着他的最新发明去见大师,他推了一个大黑盒子走进大师的办公室,大师正在静静的等着。

“这是一套整合性,分布式,一般用途的工作站”,魔术师如是说,“还有一套专属的

操作系统,第六代语言,多项最先进的使用人界面,再加上人体工学的设计,这花了我的助手们好几百人年才造出来的,不是很了不起吗?”

大师抬了下眼珠子,“的确了不起。”大师说。

魔术师继续说:“公司总部已经下令每个人都要用这台工作站做发展新软件的基石,您同意吗?”

“当然。”大师答道:“我马上会把它放到信息中心去。”于是魔术师高高兴兴的回到象牙塔去。

几天后,一个生手在大师的办公室里团团转,说:“我找不到新程序的报表,您知道会在那儿吗?”

“当然”,大师答道,“报表就堆在信息中心里头的基石上!”

7.4

大师可以毫无忧虑的从这个程序转入另一个程序,管理上的改变伤不到他;

纵使计划中止了,也不会被炒鱿鱼。为什么?因为他充满了道。

第八部 硬件与软件篇

大师如是说:“没有风,草不会动,没有软件,硬件就是废物。”

8.1

生手问大师:“我知道一家计算机公司比其它的大得多,高高在上就像巨人之比侏儒;它的任一部都可以单独成为一个企业。为什么会这样?”

大师回答:“你为什么问这个笨问题?这家公 司就是因为它大才会这么大。如果它只知道硬件,没有人会买它;如果只生产软件,没有人会用它;如果只维护系统,人家会把它看成修理员;但是因为他把所有的 合在一起,人们就把它当神一样看待了。它根本无需竞争,因为赢来不费吹灰之力。”

8.2

大师有一天经过一个生手旁边,发现生手迷上一台手掌型的电玩,“对不起”,大师说,“我可以看看它吗?”

生手停下来,并且把这台机器交给大师。大师说:“我看到这台机器玩起来有三个层次:

初级,中级,高级;不过这种机器通常都有另一个层次的说法,使机器赢不了人类,而人类也胜不了机器。”

“啊!大师”,生手说:“这个奇妙的开关在那里?”

大师把机器摔到地上,用脚把它踏烂。

突然地,生手开窍了。

8.3

从前有一位微电脑的程序员对一位来拜访他的大型计算机程序员说:“你看,在我这儿多好!我有我自己的操作系统与案储存设备,我不必与任何人共享任何计算机资源;软件本身自给自足,而且容易使用。为什么你不辞掉目前的工作来加入我们?”

于是大型计算机的程序员就对他的朋友解释:“大型计算机就像古之圣哲般的稳稳坐落在信息中心中央,磁盘一个接一个蔚为奇观,软件像钻石般地有多种面目,像古森林般的浓密茂盛。各个程序像一片急流般地涌入系统,而这就是我在那儿工作的乐趣。”

听了这段话之后,微电脑程序员静默无声;但是这两个人却结为好友,至死不渝。

8.4

HardwareSoftware走在路上,Software说:“你是阴我是阳,如果我们能一条心,一定会成大名赚大钱。”所以,他们就联合在一起而想征服世界。

走了一段路之后,碰到Firmware,穿得破破烂烂,拿着根拐杖,并且对他们说:

“道在阴阳之(个人建议改为‘),寂静不动如古井之不生波澜;

道不求名,故无人知晓其存在;

道不逐利,因它圆满无缺。

道超乎时空之外。”

HardwareSoftware听了之后倍感惭愧而打道回家。

第九部 尾声

大师如是说:”这是下课的时候了!”

Older Posts »

Powered by WordPress