只显示主题贴

最近在学习心理学,忽然发出原来如此。
A REST是什么,这个问题已经在这个帖子里面进行了讨论http://www.javaeye.com/topic/70113 。 这里实际上有个问题,我认为大多数情况下是web的REST基于url的,但是说仅仅REST只支持URL看来还不行,而且至少是可能在非web情况下使用这个风格。这也是一个可以开展的讨论点。 B 基于URL的风格,是我们讨论的重点,毕竟现在已经有这个方面的实际操作。首先我们直接的是这个风格同现在流行的技术的关系。 REST同MVC的关系,这一点已经有所涉及,但是还需要深入进去。 REST同以前的RAILS的关系,这一点还没有开展 ...
  • 进入论坛 Ruby
cmm的原始动机有很多,我今天分析其中的几个。 首先我关注的是cmm希望能够满足组织间能力成熟度的对照评价。 实际上真正被关注的是组件间开发能力的评价,而由于cmm本身的限制,其提供的只能是这个评价的一个参数。而这里其实就有很大的问题。比如评价一个军队的战斗力,不能仅仅是评价其组织的能力,还应该评价其装备和指挥思想以及基础人员的基本素质。而就一个开发团队来说其过程显然是受其使用技术和面向的商业环境以及开发的产品的约束更大,当然过程能力也会有反作用,不过这个反作用不应该是其决定作用的一个因素。一个好的过程自然会让技术得到更多的发挥,也可以更加适应市场环境,同时能够更加针对性的推出产品。不过显然 ...
我不想给大家造成一个我是cmm死敌的印象,因为我从cmm中吸取了很多有益的思想。可以说我对cmm这个标准的态度是全盘否定的,但是对于其背后的很多思想和思维方法是非常支持的。今天我就用一些cmm所使用的思想来对RUP做个手术,让大家同我一起分享我的过程。同时我也做个预报,下次我将使用Alistair Cockburn和Highsmith的方式从头建立一个新开发流程。 任何的过程要素,不管你是要改进也好,还是要新建也好,在cmmi模型中都用术语“required”,“expected”,“informative”加以区分。使用台湾的翻译,required为必要的,expected为期望的,info ...
关于过程,实际上有几个不同的内涵,因此我们必须在任何时候都明确,你现在用的到底是在指哪个。 首先一个经常遇到的是RUP里面的这个过程,其内容实际是在说一套完整的,内包含的、自我定义也就是自我迭代内递归定义的,软件开发方式的框架。也正是由此,才可以看出RUP是一个商业的产品,是一个商业的实践集成,也正是由此才可以反应出其与up的区别。在RUP中不仅仅定义了开发方法,还定义了组织结构,人员构成,人员职责等等。 而CMM中也谈到过程,这个过程则仅仅是说软件开发的方式和开发的方法流程。而CMM的基础概念上就以及明确了人不是这个过程的内含要素,即便现在的CMMI也不能明确指出其支持对于人的定义(有另外一 ...
本来这个星期我该开始讨论软件危机的问题了。但是这几天我忽然发现,ROR这个烫手的东西带给我们不可思议的效率,这个提高的来源究竟是来自何处,是一个目前很少有人讨论过的问题。而如果我们可以搞明白这个原因,我们对于今后技术和方法学发展的方向将有莫大的好处。 而由于我对于这个问题的结论还没有足够的实际例子做证据,因此我就不着急发言了。
  • 进入论坛 Ruby
实际上大家并不知道FDD的agile方法的法律地位是很值得推敲的——至少你看那17个人中间没有Jeff De Luce和Peler Coad(http://www.agilemanifesto.org/)。而且即使是Jon Kern也是在相信agile对于建模的态度是友好的(至少MDA的Steve Mellor也这样认为),而且Together soft可以减小建模和编码之间的断层隔离。当然类似的处境也在Lean方法中出现。不过好在Agile方法系统不是武侠小说中的武林门派,不会有什么座次和正统的争吵。然而即使是现在,依然有人以为FDD是一种黑客方法学——FDD竟然敢自称为一种Processe ...
昨天我和robbin在电话里面谈了一下,又有了很多想法,觉得有必要讨论讨论。 在讨论开始前我说明一下,为什么我会把帖子发在这个版面而不在java版面。 1.我关心的是java将死这个论题的非技术影响,当然我并不排斥其技术影响。 2.我关心的是为什么会在现在这个时间讨论java将死这个论题。 3.我关心的是java将死这个论题对于现实的开发项目极其公司发展的影响。 围绕 http://blog.csdn.net/gigix/archive/2006/09/11/1210180.aspx 在csdn上产生了一场战斗。我想csdn的环境不太适合讨论这么富有刺激性的问题,因为那里很容易发生械斗。 ...
要说RUP,就要先说UP。 UP可以用下面的话来概括——用例驱动、以构架为中心、迭代和增量的开发过程。 acobson在《Object-Oriented Software Engineering : A Use Case Drivern Approach》中给的定义是这样的:当希望改变系统的行为时,重建相对应的参与者和用例模型。整个系统的基础构架将有用户所希望使用系统行为进行的操作来控制。由于控制了所有模型,因此可以根据新需求修改系统。我们向用户询问他们希望改动的地方,也就是用例,并直接找出这些改变在其他模型的什么部分实现。 用例被用来驱动你开发过程中的各种实践,你的需求、设计、测试、部署都是 ...
今天为了监视gigix这个小子,于是发现了下面一段话: 引用嘉宾[主持人]: RUP有没有简化版本,适合中型或者小型项目的?怎么样判断裁减后的RUP,还能体现RUP的精髓? [2004-12-8 15:54:00] 嘉宾[Ivar Jacobson]: 使用RUP要做裁减的时候有几个地方只要稍微留意,可以适合各种不同的公司的要求。包括第一是使用用例,就是你在使用RUP的过程中,用例的使用是非常重要的。用例的使用要从需求一直到测试,用例要能够相连续的使用它,让开发过程更为流畅。第二,一定不能少的就是迭代式开发,能够精确、准确的掌握所开发的原始的目标,迭代式的开发也是相辅相成的。第三,很重要的 ...
ozzzzzz
搜索本博客
最近加入圈子
存档
最新评论