michaelwang1978

其实，这个应用是个简单得不能再简单的JavaScript应用，只不过被冠以了AJAX这个今年2月份才诞生的名词以后忽然热了起来。AJAX这一个单词，居然可以把一堆98年就开始用的技术推到前台来，成为当今在特定的圈子里最热的词汇，倒是一个典型的tipping point（临界点）的案例。就像99年Netcenter用的RSS终于在2002年开始被从blogger捡起来，并在2005年焕发了青春。

这些用Javascript+XMLHTTPRequest的做法给我们提供了一个很广阔的空间，可以有很多的想象。比如，在任何静态的页面里面，只要加入这段代码也就可以拥有这个功能了。

<script language=Javascript src="http://home.wangjianshuo.com/scripts/php/markit.php">
</script>

把鼠标放在上面还可以知道是从哪个IP在什么时间批注的。值得注意的是，这只是一个最简单的SAJAX应用，如果把它应用于地图，以及应用于多个网站之间的联合，会有更让人惊讶的结果出来。估计，以后客齐集的后台的管理系统将会是最早使用这些简单但是有效的思想的地方。

注：那些红线，只是在Word里面随手画的。
注二：没有经过测试，FireFox下面什么样子不晓得，放在其他页面怎么样也不晓得。。

我们期待自己成为一个优秀的软件模型设计者，但是，要怎样做，又从哪里开始呢？ 

　　将下列原则应用到你的软件工程中，你会获得立杆见影的成果。 

　　1. 人远比技术重要 

　　你开发软件是为了供别人使用，没有人使用的软件只是没有意义的数据的集合而已。许多在软件方面很有成就的行家在他们事业的初期却表现平平，因为他们那时侯将主要精力都集中在技术上。显然，构件（components），EJB（Enterprise Java Beans）和代理（agent）是很有趣的东西。但是对于用户来说，如果你设计的软件很难使用或者不能满足他们的需求，后台用再好的技术也于事无补。多花点时间到软件需求和设计一个使用户能很容易理解的界面上。 
　
　　2. 理解你要实现的东西 

　　好的软件设计人员把大多数时间花费在建立系统模型上，偶尔写一些源代码，但那只不过是为了验证设计过程中所遇到的问题。这将使他们的设计方案更加可行。 

　　3. 谦虚是必须的品格 

　　你不可能知道一切，你甚至要很努力才能获得足够用的知识。软件开发是一项复杂而艰巨的工作，因为软件开发所用到的工具和技术是在不断更新的。而且，一个人也不可能了解软件开发的所有过程。在日常生活中你每天接触到的新鲜事物可能不会太多。但是对于从事软件开发的人来说，每天可以学习很多新东西（如果愿意的话）。 

　　4. 需求就是需求 

　　如果你没有任何需求，你就不要动手开发任何软件。成功的软件取决于时间（在用户要求的时间内完成）、预算和是否满足用户的需求。如果你不能确切知道用户需要的是什么，或者软件的需求定义，那么你的工程注定会失败。 

　　5. 需求其实很少改变，改变的是你对需求的理解 

　　Object ToolSmiths公司（www.objecttoolsmiths.com）的Doug Smith常喜欢说：“分析是一门科学，设计是一门艺术”。他的意思是说在众多的“正确”分析模型中只存在一个最“正确”分析模型可以完全满足解决某个具体问题的需要（我理解的意思是需求分析需要一丝不苟、精确的完成,而设计的时候反而可以发挥创造力和想象力 - 译者注）。 

　　如果需求经常改动，很可能是你没有作好需求分析，并不是需求真的改变了。 

　　你可以抱怨用户不能告诉你他们想得到什么，但是不要忘记，收集需求信息是你工作。 

　　你可以说是新来的开发人员把事情搞得一团糟，但是，你应该确定在工程的第一天就告诉他们应该做什么和怎样去做。 

　　如果你觉得公司不让你与用户充分接触，那只能说明公司的管理层并不是真正支持你的项目。 

　　你可以抱怨公司有关软件工程的管理制度不合理，但你必须了解大多同行公司是怎么做的。 

　　你可以借口说你们的竞争对手的成功是因为他们有了一个新的理念，但是为什么你没先想到呢？ 

　　需求真正改变的情况很少，但是没有做好需求分析工作的理由却很多。 

　　6. 经常阅读 

　　在这个每日都在发生变化的产业中，你不可能在已取得的成就上陶醉太久。 

　　每个月至少读2、3本专业杂志或者1本专业书籍。保持不落伍需要付出很多的时间和金钱，但会使你成为一个很有实力的竞争者。 

　　7. 降低软件模块间的耦合度 

　　高耦合度的系统是很难维护的。一处的修改引起另一处甚至更多处的变动。 

　　你可以通过以下方法降低程序的耦合度：隐藏实现细节，强制构件接口定义，不使用公用数据结构，不让应用程序直接操作数据库（我的经验法则是：当应用程序员在写SQL代码的时候，你的程序的耦合度就已经很高了）。 

　　耦合度低的软件可以很容易被重用、维护和扩充。 

　　8. 提高软件的内聚性 

　　如果一个软件的模块只实现一个功能，那么该模块具有高内聚性。高内聚性的软件更容易维护和改进。 

　　判断一个模块是否有高的内聚性，看一看你是否能够用一个简单的句子描述它的功能就行了。如果你用了一段话或者你需要使用类似“和”、“或”等连词，则说明你需要将该模块细化。 

　　只有高内聚性的模块才可能被重用。 

　　9. 考虑软件的移植性 

　　移植是软件开发中一项具体而又实际的工作，不要相信某些软件工具的广告宣传（比如java 的宣传口号write once run many ? 译者注）。 

　　即使仅仅对软件进行常规升级，也要把这看得和向另一个操作系统或数据库移植一样重要。 

　　记得从16位Windows移植到32位windows的“乐趣”吗 ？当你使用了某个操作系统的特性，如它的进程间通信(IPC)策略，或用某数据库专有语言写了存储过程。你的软件和那个特定的产品结合度就已经很高了。 

　　好的软件设计者把那些特有的实现细节打包隐藏起来，所以，当那些特性该变的时候，你的仅仅需要更新那个包就可以了。 

　　10. 接受变化 

　　这是一句老话了：唯一不变的只有变化。 

　　你应该将所有系统将可能发生的变化以及潜在需求记录下来,以便将来能够实现（参见“Architecting for Change”，Thinking Objectively, May 1999） 

　　通过在建模期间考虑这些假设的情况，你就有可能开发出足够强壮且容易维护的软件。设计强壮的软件是你最基本的目标。 

　　11. 不要低估对软件规模的需求 

　　Internet 带给我们的最大的教训是你必须在软件开发的最初阶段就考虑软件规模的可扩充性。 

　　今天只有100人的部门使用的应用程序，明天可能会被有好几万人的组织使用，下月，通过因特网可能会有几百万人使用它。 

　　在软件设计的初期，根据在用例模型中定义的必须支持的基本事务处理，确定软件的基本功能。然后，在建造系统的时候再逐步加入比较常用的功能。 

　　在设计的开始考虑软件的规模需求，避免在用户群突然增大的情况下，重写软件。 

　　12. 性能仅仅是很多设计因素之一 

　　关注软件设计中的一个重要因素--性能，这好象也是用户最关心的事情。一个性能不佳的软件将不可避免被重写。 

　　但是你的设计还必须具有可靠性，可用性，便携性和可扩展性。你应该在工程开始就应该定义并区分好这些因素，以便在工作中恰当使用。性能可以是，也可以不是优先级最高的因素，我的观点是，给每个设计因素应有的考虑。 

　　13. 管理接口 

　　“UML User Guide”（Grady Booch，Ivar Jacobson和Jim Rumbaugh ,Addison Wesley, 1999）中指出，你应该在开发阶段的早期就定义软件模块之间的接口。 

　　这有助于你的开发人员全面理解软件的设计结构并取得一致意见，让各模块开发小组相对独立的工作。一旦模块的接口确定之后，模块怎样实现就不是很重要了。 

　　从根本上说，如果你不能够定义你的模块“从外部看上去会是什么样子”，你肯定也不清楚模块内要实现什么。 

　　14. 走近路需要更长的时间 

　　在软件开发中没有捷径可以走。 

　　缩短你的在需求分析上花的时间，结果只能是开发出来的软件不能满足用户的需求，必须被重写。 

　　在软件建模上每节省一周，在将来的编码阶段可能会多花几周时间，因为你在全面思考之前就动手写程序。 

　　你为了节省一天的测试时间而漏掉了一个bug，在将来的维护阶段，可能需要花几周甚至几个月的时间去修复。与其如此，还不如重新安排一下项目计划。 

　　避免走捷径，只做一次但要做对（do it once by doing it right）。 

　　15. 别信赖任何人 

　　产品和服务销售公司不是你的朋友，你的大部分员工和高层管理人员也不是。 

　　大部分产品供应商希望把你牢牢绑在他们的产品上，可能是操作系统，数据库或者某个开发工具。 

　　大部分的顾问和承包商只关心你的钱并不是你的工程（停止向他们付款，看一看他们会在周围呆多长时间）。 

　　大部分程序员认为他们自己比其他人更优秀，他们可能抛弃你设计的模型而用自己认为更好的。 

　　只有良好的沟通才能解决这些问题。 

　　要明确的是，不要只依靠一家产品或服务提供商，即使你的公司（或组织）已经在建模、文档和过程等方面向那个公司投入了很多钱。 

　　16. 证明你的设计在实践中可行 

　　在设计的时候应当先建立一个技术原型， 或者称为“端到端”原型。以证明你的设计是能够工作的。 

　　你应该在开发工作的早期做这些事情，因为，如果软件的设计方案是不可行的，在编码实现阶段无论采取什么措施都于事无补。技术原型将证明你的设计的可行性，从而，你的设计将更容易获得支持。 

　　17. 应用已知的模式 

　　目前，我们有大量现成的分析和设计模式以及问题的解决方案可以使用。 

　　一般来说，好的模型设计和开发人员，都会避免重新设计已经成熟的并被广泛应用的东西。 
http://www.ambysoft.com/processPatternsPage.html 收藏了许多开发模式的信息。 

　　18. 研究每个模型的长处和弱点 

　　目前有很多种类的模型可以使用,如下图所示。用例捕获的是系统行为需求，数据模型则描述支持一个系统运行所需要的数据构成。你可能会试图在用例中加入实际数据描述，但是，这对开发者不是非常有用。同样，数据模型对描述软件需求来说是无用的。每个模型在你建模过程中有其相应的位置，但是，你需要明白在什么地方，什么时候使用它们。 

　　19. 在现有任务中应用多个模型 

　　当你收集需求的时候，考虑使用用例模型，用户界面模型和领域级的类模型。 

　　当你设计软件的时候，应该考虑制作类模型，顺序图、状态图、协作图和最终的软件实际物理模型。 

　　程序设计人员应该慢慢意识到，仅仅使用一个模型而实现的软件要么不能够很好地满足用户的需求，要么很难扩展。 

　　20. 教育你的听众 

　　你花了很大力气建立一个很成熟的系统模型，而你的听众却不能理解它们，甚至更糟－连为什么要先建立模型都不知道。那么你的工作是毫无意义的。 

　　教给你开发人员基本的建模知识；否则，他们会只看看你画的漂亮图表，然后继续编写不规范的程序。 

　　另外， 你还需要告诉你的用户一些需求建模的基础知识。给他们解释你的用例(uses case)和用户界面模型，以使他们能够明白你要表达地东西。当每个人都能使用一个通用的设计语言的时候（比如UML-译者注），你的团队才能实现真正的合作。 

　　21. 带工具的傻瓜还是傻瓜 

　　你给我CAD/CAM工具，请我设计一座桥。但是，如果那座桥建成的话，我肯定不想当第一个从桥上过的人，因为我对建筑一窍不通。 

　　使用一个很优秀的CASE工具并不能使你成为一个建模专家，只能使你成为一个优秀CASE工具的使用者。成为一个优秀的建模专家需要多年的积累，不会是一周针对某个价值几千美元工具的培训。一个优秀的CASE工具是很重要，但你必须学习使用它，并能够使用它设计它支持的模型。 

　　22. 理解完整的过程 

　　好的设计人员应该理解整个软件过程，尽管他们可能不是精通全部实现细节。 

　　软件开发是一个很复杂的过程，还记得《object-oriented software process》第36页的内容吗？除了编程、建模、测试等你擅长工作外，还有很多工作要做。 

　　好的设计者需要考虑全局。必须从长远考虑如何使软件满足用户需要，如何提供维护和技术支持等。 

　　23. 常做测试，早做测试 

　　如果测试对你的软件来说是无所谓的，那么你的软件多半也没什么必要被开发出来。 

　　建立一个技术原型供技术评审使用，以检验你的软件模型。 

　　在软件生命周期中，越晚发现的错误越难修改，修改成本越昂贵。尽可能早的做测试是很值得的。 

　　24. 把你的工作归档 

　　不值得归档的工作往往也不值得做。归档你的设想，以及根据设想做出的决定；归档软件模型中很重要但不很明显的部分。 给每个模型一些概要描述以使别人很快明白模型所表达的内容。 

　　25. 技术会变，基本原理不会 

　　如果有人说“使用某种开发语言、某个工具或某某技术，我们就不需要再做需求分析，建模，编码或测试”。不要相信，这只说明他还缺乏经验。抛开技术和人的因素，实际上软件开发的基本原理自20世纪70年代以来就没有改变过。你必须还定义需求，建模，编码，测试，配置，面对风险，发布产品，管理工作人员等等。 

　　软件建模技术是需要多年的实际工作才能完全掌握的。好在你可以从我的建议开始，完善你们自己的软件开发经验。 

　　以鸡汤开始，加入自己的蔬菜。然后，开始享受你自己的丰盛晚餐吧

现在到eclipse网站可以下到中文包了！
    有两个，分别是：NLpack1-eclipse-SDK-3.1.1a-win32.zip和NLpack1_FeatureOverlay-eclipse-SDK-3.1.1.zip。
    后者是前者的补充。
   
    在我的机子上，这两个中文包只适合eclipse3.1.1版本，3.1版本都不适合，但网上有人说可以用，就不得而知了。eclipse3.1.1版本已经出了一段时日了，但一直都没有使用过，今天是试用了一下，Lomboz还可以用，但de.strutsbox_20050804就不能用了。
    不过，装上lomboz，NLpack1_FeatureOverlay-eclipse-SDK-3.1.1.zip就不怎么起作用了。

    myeclipseME-4.0GA_E3.1ManualInstall版在这个版本下面也不能使用。

    eclipse3.1.1在功能上与3.1版没什么区别，但对插件兼容就不敢恭维了。

   

开放源代码协会通过Linux软件开发公司Ximian开始了一个旨在将微软.Net平台移植到Linux上来的项目。这个叫做Mono工程的项目包括创建一个开发平台允许人们为基于Linux和基于Windows系统的.Net开发应用程序。据Ximian公司的首席技术官员Miguel de Icaza说Mono项目的起因是GNOME社团特别是Ximain公司对于一个改进的开发工具的需要。

但是Mono项目的影响确是更加深远的，因为这些开发工具是基于CLI（通用语言架构）和微软提交给欧洲计算机制造协会（ECMA）的C＃实现标准的。如果Mono能够完成基于这些标准创建一套Linux开发工具集的目标的话，开发者将能够编写同时在Windows和Linux上运行的.Net程序，这些程序甚至还可能在其它非Windows的操作系统上运行，比方Unix。

除了实际的开发过程，Mono项目的工具必须在开放源代码社团的内部完成而不能违反微软的知识产权专利－－这实际上意味着开发者们必须基于标准重新构造这些工具而不能查看微软的任何源代码。

Mono项目包括三个核心的部分：一个C＃语言的编译器，一个CLI和一个类库。 CLI是包含了类加载器的虚拟机，实时的编译器，和一个运行时环境的垃圾收集器。CLI这个组件将允许用C＃编写的应用程序能够在象Linux这样的非Windows操作系统上运行。这与Java世界中Java虚拟机能够让一个应用程序在不同的操作系统上运行是类似的。

Mono项目的类库能够让应用程序完成核心的诸如XML处理，文件输入输出，和连接网络之类的任务。它将会和微软的CLI兼容（与微软在.Net framework中发布的东西紧密的配套），还有一点就是将由开放源代码团体编写的额外的类库也将和CLI兼容。

Ximian公司的de Icaza希望在年底到达项目的一个里程碑，这时编译器将能够编译类库了。图形用户界面组件－－创建GUI程序所需的类库－－将在明年中完成。

“我们在这个方面工作的原因是希望升级我们的开发平台来创建我们的Evolution桌面应用程序，”de Icazo说。Evolution是Ximian公司的电子邮件客户端及个人和工作组信息管理程序。“当我们看见.Net framework的时候，我们觉得这些就是我们将用来开发我们下一代产品要使用的工具，”他说。

Ximian并不将Mono和它自己看作是给Linux开发者一种途径在可用的开发工具方面赶上Windows。其实，Linux开发者将更喜欢用他们目前使用的工具来编写的编译应用程序。Ximian　将另一个开放源代码项目，SharpDevelop看作是用来提供与微软Visual Studio .Net类似的集成开发环境的一种途径。

通过以开放源代码的方式开发Mono，这个项目包含了许多对开发过程拥有广泛兴趣的人们。虽然Ximian可能希望找一些改进的开发工具来加速它的应用程序的开发过程，但其它的开发者可能是希望找到能够让他们在Windows上编写程序然后在Linux系统上运行它们的开发工具。

其中的一个大问题是如何避免微软的知识产权保护。“我们避免知识产权保护的方法是坚持非研究性的主题并使用现有的技术实现其功能，”de Icaza说。例如，Mono JIT编译器没有使用任何先进的JIT编译器技术。相反Mono的版本是基于老的JIT技术的。

De Icaza还声称Mono必须“着眼大处”还不仅仅是去年ECMA规定了些什么。也就是说，Ximian计划参与标准的制定过程并创建类库来提高.Net framework的薄弱之处，比方说电子邮件管理。

据Giga Information Group的副分析师Stacey Quandt称，微软不太可能支持Mono因为其授权是与GNU　通用公众证书为C＃的授权和GNU　弱公众证书为类库和运行库的授权联系在一起的。

但即使微软不支持Mono，Mono的存在也证实了微软对于.Net能够移植到其它平台的声明是正确的。

Quandt说面向更广泛的开发团体是Mono面临的另一个挑战。例如IBM和Sun都在Java上花费了巨额的投资，自然也就很难容忍竞争行为。