Shao Fan

关于JAVA与软件工程
posts - 31, comments - 71, trackbacks - 0, articles - 4
  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

     摘要: 最近Business 2.0杂志发表了一篇文章,名为"Next net 25",介绍了五类25家新锐网站。它们大多为web2.0网站,它们的发展正体现了当今互联网的动向。有人敏锐地认识到了这篇文章的特别之处,并把它和 94年的状况进行了对比。认为web2.0开始从少数人面前跳上了大众舞台,而目前主流媒体也开始注意并认可这类站点和服务了。  阅读全文

posted @ 2006-03-13 08:13 shaofan 阅读(1693) | 评论 (3)编辑 收藏

本文译自Joel on Software,同时发表在其wiki上。关于作者本人,请看这里。由于Joel对于他人对其作品的转载有较严限制,转载及引用者请参阅其声明:Linking, Quotation, and Reprinting。这是我翻译的第一篇文章,有些地方我也不是很肯定,请多多指正!

(第一稿)


在飞机控制的设计中,糟糕的可用性会致使飞机发生CFIT:可控飞行撞地

可能可用性在你的产品中不是那么关键。如果幸运的话,你在可用性设计中的错误可能只会使人失去四肢,或甚至只是拇指。没什么更糟的了。

事实上,如果极端幸运,那么糟糕的可用性设计除了会使人难受,没有其他后果。用户试着去做一些事情,或者失败,或者挣扎着去用,很直接的后果就是他们会为此感到不悦。在将来的文章里,我会讲讲此事在心理上的原因,但现在,这样说就足够了:使用户不悦的原因,很可能并非完全如你所想。

可用性,确实是一个“好”设计的核心。在将来,我会花很多时间来讲述这个问题。

好消息是:我可以很轻松地教你关于可用性设计的话题。让我们开始吧:

当一件东西能够以被期待的方式运行,那它就是易用的。

就是这样!这就是关于可用性的一切!像Hillel所说,其它的一切都是解说词。

让我们来看一个简单的例子。


哪个更好用:Windows还是Mac?


在为人们设计产品时,有一个假想用户是很有帮助的。所设想的用户越是实际,提供的帮助越大。

我的假想用户就是彼特。

有一天,彼特的朋友,吉娜叫他来帮忙。吉娜有一台Macintosh的iBook,因为她喜欢白色的电脑。当彼特坐下开始试着用吉娜的Macintosh时,他很快就感到有点沮丧了。“我讨厌这些东西,”他说。虽然最后成功地帮吉娜解决了问题,他却觉得高兴不起来。“Macintosh的用户界面真是笨拙至极。”

笨拙?为什么会这样说呢?每个人都知道,Macintosh有着优雅易用的用户界面,对不对?难道它不是那种易用性的范例吗?

好吧。让我们来看看。

在Macintosh上,如果你想改变窗口的大小,你必须拖它的右下角。而在Windows上,在任何一个边上拖动鼠标,都可以改变窗口大小。当彼特帮吉娜时,他试着拖右侧的边来让窗口变宽。结果,整个窗口都跟着动了,而不是他想要的“改变大小”。

在Windows上,当出现一个消息框时,你只要按tab键移动焦点到所需的按钮上,然后按一下空格键就可以按到那个按钮。但在Mac上,空格键不起那样的作用。当彼特得到一个警告,他就试着像他过去六年里下意识的做的那样,按空格键来关掉消息框。第一次,机器没有任何反应,他以为是键盘有问题,于是更大力地又按了一次。结果还是一样。最后他只能用鼠标了。这是另一个小小的挫折。

彼特还习惯用Alt+F4来关闭窗口。在Mac上,这恰恰是用来调整声音音量的。这次,彼特想点击桌面上的IE图标,而这个图标刚好被另一个窗口遮住了一部份。于是他按Alt+F4关闭窗口的同时立即双击图标所在的位置。结果是声音音量变大了,而窗口并未被关掉。而他的双击点在了他想关掉的那个窗口的帮助按钮上,把帮助窗口打开了。好了,他现在需要关闭两个窗口了。

这也是一个小小的挫折吧,但是,这确实让彼特更加郁闷了。这天结束的时候,彼特的脾气很不好。他试着控制那些东西,却都没有反应。空格键和Alt+F4都“不起作用”----就像它们坏了一样。窗口也不听话,连调整大小都不行。真差劲。就算这些想法都是下意识的,这些“失去控制”的细微感受也最终使他感到不快。“我还是喜欢我自己的电脑”,彼特想,“它被我设置的完美无缺,总能按照我想的方式去运行。而这些Mac真是难用。真是让人不爽。如果Apple这些年多花些心思在MacOS上,而不是搞iPod那些那些玩意,他们的操作系统也不会这么糟糕了。”

好了。我们比彼特清楚。他虽然有这些种种感受,但事实上对Mac用户来说,Mac确实很好用。完全可以用任意键来关闭窗口。微软的程序员很可能觉得,让用户拖动任意边都可以调整窗口大小的功能真的很不错。而Apple程序员很可能认为,拖动任意边来移动窗口位置的功能很有创意。

那些盲目信仰某种OS的网站上的关于用户界面的争论,都没有说到点子上。Windows更好,是因为给你更多手段来调整窗口大小。那又怎样?这并不是问题所在。真正的问题是,UI是否以用户预期的方式来响应他们的操作。如果不是,那么用户就会觉得他们无法控制它,并觉得自己会难以达成目的。就是这样了。当一件东西能够以被期待的方式运行,那它就是易用的。你可以把这句话反着纹在你的额头上,这样你在镜子里就可以看到它。

如果你继续关注将来的文章,那么你会发现,我所告诉你的关于可用性设计的一切,都可以追溯到这个简单的法则。如果哪天外星人在你的花园里着陆,把你扔到了名叫Kij8zxwrk的星球,在那里你无法连接到地球的互联网,因为数据包传送到地球所花时间太长导致TCP/IP无法正常工作,那么你所知道的东西也足以让你找到一份相当体面的可用性设计师的工作了。

posted @ 2006-03-10 06:39 shaofan 阅读(1846) | 评论 (5)编辑 收藏

我有一个习惯,每次学门语言,总要自己写个List或Stack并加上Unit Test来试试。这次对Python也不例外。总体感觉有以下几点

1.这是我用过的唯一一个把代码行的缩进也做为语法的语言,就因为不正确的缩进,我的第一个Python程序让我吃尽了苦头。事情是这样的,我运行测试时,报告每次都说"Ran 0 test in 0.000s",找了半天,也找不出为什么只运行了0个测试,一直以为是unittest包的用法有问题,或我的语法有问题,直到花了大半个小时翻书,又对比其他的测试程序以后,才发现,天啊,原来是因为最后一行的缩进多缩了一层,被认为与上一个方法同一个block。

2.虽然在缩进上吃了苦头,但是代码看起来确实相当整洁清楚,感觉比java的动不动一堆大括号相比,实在多了。

3.Python的每个module(可以看作与java的包类似)都可以包含方法和类,而java的所有方法都要写在类里,包里只有类,这点相当不同。

4.因为Python是用c实现的,它的命名比较简单,使用很多缩写,与java的长长一串的命名是很强烈的对比

5.Python是动态类型的语言,变量不需声明类型可以直接使用,虽然方便,但缺点也很明显,那就是变量的类型信息不见了,经常搞不清楚方法的参数要传入什么,返回什么,挺不习惯的。

6.就因为缺少类型信息,Python的文档也没有Java的可读性强。比如java的 String foo(int a)一看就知道传入整形返回字符串,换成Python就变成了 foo(a),只能读文档才能搞清楚了。可能我还没习惯的原因吧,感觉有时文档对它们的类型也说的不太清楚。

总体感觉Python一些风格像C。写起代码来,感觉很快,很清楚,还是很不错的 I love the feeling :)


看看我写的Stack

posted @ 2006-03-09 20:31 shaofan 阅读(1035) | 评论 (0)编辑 收藏

     摘要: 过去的一年,Mustang 没能出来,EJB3刚刚才提交最终草案,Ajax兴起但是五花八门不知道应该用谁,Aspectj 5出来了,但是缺乏惊喜。
或许我们会说,过去的2005,Java界缺乏成绩,但是却毫无疑问,Java遥遥领先于其他语言。从11月的语言排行榜Java遥遥领先,到今年的Java图书销售统计上,Java图书销售总数是C#的2倍,PHP的2.5倍,Perl的4倍,Ruby/Python的9倍.
这足以让我们对2006充满想象。
不过,还是让我们先回顾下2005吧....  阅读全文

posted @ 2006-03-07 09:56 shaofan 阅读(493) | 评论 (0)编辑 收藏

     摘要: 总感觉只会JAVA似乎不够,不记得是哪位先人说的了,一个程序员起码要精通两门语言,所以这些天花了不少时间琢磨python,看了不少网站,查了不少资料,正想着把一些东西写下来,以免日后忘了,也可以和大家分享.先写一些下载安装和学习资源的东东.  阅读全文

posted @ 2006-03-05 09:30 shaofan 阅读(5345) | 评论 (7)编辑 收藏

     摘要: Design by Contract (DbC)的概念已经出现很长时间了,最先是在Eiffel的一个特色,通过DbC来提高软件质量,目前很多语言也都有相应的实现,但是在GOOGLE上搜索中文网页,得到的资源并不是很多.直觉上来说,DbC确实是一个很好的想法,本着拓宽眼界的原则,就简单了解一下吧.  阅读全文

posted @ 2006-03-02 00:55 shaofan 阅读(2053) | 评论 (4)编辑 收藏

        今天试着把大虾写的系统登录模块加到我们现有的模块里来,他写的时候因为有些试验的成分,所以没有按照我们项目的配置来写,也没有按照我们的模块来划分配置,加过来以后重新配置了模块信息,结果居然无法正常运行。显示错误:“cannot retrieve action mapping  。废了九牛二虎之力,都无法解决。web.xml、struts-config、模块配置,一切看起来都无比的正常,但就是运行不了。真搞不清楚是哪里出了问题。还以为搞不定,晚上要加班了,谁知道,踏破铁鞋无觅处,柳暗花明又一村,在google上搜索关键字"action mapping 找不到",第一个链接居然就是问题的答案!(还从来没有只点一次就可以找到问题答案的经验,所以兴奋无比^O^)

        总的来说,问题的原因就在于,struts是在第一次收到对action的请求(注意:不包括jsp的请求)时,提取这个请求的url的路径信息,把相应模块的mapping信息设置到请求中去。如果在进入一个模块时,第一次访问的是一个jsp页面,而在这个jsp页面中提交到该模块的一个action,就会出现找不到action mapping的情况。这就是因为,在进到这个模块时,访问的是jsp,这个模块的任何一个action都没有被访问到,所以struts的ActionServlet还没有来得及把这个模块的mapping设置到请求中,自然找不到该模块的action。

        因此,这就引出一个约定,就是系统中尽量避免对Jsp的直接访问,如果要访问也要通过action来forward。虽然看起来麻烦一点,但是安全性、健壮性都会有所提高。

        关于以上提到的模块mapping的设置原理,具体的文章在这里(不长),值得收藏:

        原文链接:http://202.100.72.44/news/itschool/pro/pro44134.htm

posted @ 2006-03-01 10:44 shaofan 阅读(2048) | 评论 (5)编辑 收藏

     摘要: 介绍了在JSP页面动态生成Javascript树结构的一种实现.原理是利用JSP标签读取数据(从数据库或其他地方),在页面生成Javascript的树的数据结构,然后由Javascript脚本根据这个结构显示出来.  阅读全文

posted @ 2006-02-26 18:47 shaofan 阅读(5777) | 评论 (4)编辑 收藏

     摘要: 1.管理J2EE工程:发布WEB程序,启动/关闭服务器等
2.编辑JSP/HTML/XML:有代码提示,语法着色,错误提示等功能
3.跟踪调试JSP/SERVLET:可设置断点,单步执行,变量/栈/线程跟踪等  阅读全文

posted @ 2006-02-26 18:39 shaofan 阅读(7933) | 评论 (1)编辑 收藏

If the problem was exploring requirements to lead them toward stability, the solution was seen to be prototyping. ... Prototyping and JAD continue to be used to this day, especially when requirements are poorly understood.

Meanwhile, management had to figure out how to deal with reuiqrements instability and the "moving target" problem. ... But eventually management came to realize that, although they could not freeze the requirements, they could insist that changing requirements lead to changing project terms and conditions. "You want new or revised features? Then let's talk about how much time and money that will cost over and above our original estimate." Unfortunately, that led us into the swampland of changing estimates while the project was in progress...

There is an interesting new twist evolving on the requirements instability problem. The extream Programming lightweight methodology calls for a representative of the user community to reside with the software project team during development. ... The questions remain, however, how many user organizations (a) will be willing to give up a first-rate person to such a full-time task, and (b) have one person who can represent all the potentially varying viewpoints of the customers and users?

为了更好得捕获需求,使它们有更好的稳定性,人们开始使用"原型"."原型"和JAD(联合应用开发)在如今仍在被使用着,尤其当需求无法被准确理解的时候.

同时,管理者必需面对和解决需求不稳定,及"移动靶"的问题.最终他们认识到,虽然他们无法冻结需求,但是他们可以坚持"需求变化导致合同条款变更"的想法."如果你想修改项目的功能,那就需要考虑这些修改所需要的时间和资金成本."不幸的是,这致使项目陷入需要重新进行估计的泥沼之中(在项目进行之中进行重新估计会造成哪些问题?).

此时极限编程浮出水面.它要求一个客户代表与开发人员一起,参与软件开发的过程.这可以解决一些问题,然而问题仍然存在,有多少组织(a)愿意放弃一个一线员工,让他全职参与软件开发,(b)能找到一个可以代表所有潜在的,持不同观点的客户和用户的人?(关于这点,个人认为光有客户代表可能还不够,还是要在需求捕获的过程中采用多种有效的手段,起码客户代表要与其他参与需求的客户和用户有一定的一致意见,否则,怎么起到"代表"的作用?)

[GLASS] Facts and Fallacies of Software Engineering, Rober L. Glass, Addison-Wesley,2002

posted @ 2006-02-26 07:22 shaofan 阅读(329) | 评论 (0)编辑 收藏

仅列出标题
共4页: 上一页 1 2 3 4 下一页