helloworld

helloworld http://helloworld.javaeye.com UTF-8 Copyright 2003-2008, JavaEye.com http://blogs.law.harvard.edu/tech/rss JavaEye - 做最棒的软件开发交流社区 “新手帖”的感受 helloworld 作者: helloworld 链接：http://helloworld.javaeye.com/blog/210756 发表时间: 2008年07月02日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

第一次看到自己在某个论坛的帖子被删，想反正那个帖子没什么内容，都是无意义的争论，删了也好。
看到帖子被评为新手帖，有种被侮辱的感觉，尽管写的是一些很简单的东西，但简单却是经过提炼后的简单。个人并不是OO的新手，早在若干年前，UML刚刚问世的时候，就把它引入到一个400人的IT企业，能是新手吗？更不要说久经沙场了。
我不同意OO丧钟的观点，也不同意什么都是OO的观点，尽管我平常都是用OO编程，但我很清楚什么时候是OO，什么时候只是一个封装而已；我只是把自己的一些想法感触写出来罢了。
我是JavaEye很早的会员，那时候没什么人，那时候这里面的一些人，大多水平很高，也有的很勤恳。尽管不怎么发贴，看贴是很多的。后来没做Java项目了，也时不时来看一下，对论坛是有感情的。现在人多了，有管理了，原来那些人虽然也都还在，但是帖子水平整体下降了，而且无意义的争论多于技术讨论，有个别水平不错的人也陷了进去。
尽管新手帖让人难受，但如果真是民主评分那也罢了，还是孤芳自赏比较好。但如果是个人搞的，就很不是滋味了，像是你当是朋友，或者说你觉得不错，突然....事实证明判断是错的，事实证明已经不是过去的样子了，但愿事实是我胡乱关联（前面删贴的情况），可是我也要有一个答案来帮助情感找到出口。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

]]> Wed, 02 Jul 2008 19:53:49 +0800 http://helloworld.javaeye.com/blog/210756 http://helloworld.javaeye.com/blog/210756 我的OO观 helloworld 作者: helloworld 链接：http://helloworld.javaeye.com/blog/210104 发表时间: 2008年07月01日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

【编程】
OO之于编程，对于编程来说OO带来了两项新的内容：更好的重用和多态性。这方面典型的例子是控件，确实帮了程序员很大的忙，这是结构化没有做到的。而OLE，COM和CORBA则光环多于实用。结构化编程也可以做到重用，但相比较于OO来说很难想象我们常用的UI控件用结构化来重写是怎样的一种情况，而科学计算库用结构化编程实现重用的开销要小。因此结构化编程具有简单清晰的优势，却不能处理复杂的重用。

【设计】
OO之于设计——设计模式，可以说没有OO就不能有所谓设计模式之发展。结构化编程中实际上分析和设计的界限非常的不清晰，模块分解实质是系统分析的产物。而OO使得开发人员有能力设计出好的对象组合（结构视图）及其交互（行为视图）来更好的实现具体的功能。

【分析】
OO之于分析，曾经是早期OO的巨大困惑之一。因为人们所了解的分析就是要将系统进行划分为不同的模块，相当于要将系统的组成结构做出来。这对结构化来说是很自然的。对于OO来讲，把系统分解为Object显然一下子显得太细节，不容易抓住系统的主干。然而引入主题这个概念，使得系统的划分变得非常自然而然。尽管这样，OO之于分析还是有不足之处，个性化多于科学性。

【OO之牵强】
编程现在都已经非常习惯采用面向对象的方式了，但在操作符 .(dot)前面那个是不是真实的对象呢，往往都不会在意了。

1、非对象之对象
非对象之对象指原本没有对象，而是为了对象而造出来的。这种对象太多了，最常见的有为了给一堆方法找的对象，如数学函数库对象，业务对象等等。
2、实体对象
实体对象简单说来对应于数据库表的一条记录（不完全是这样），首先这些对象本身是没有什么的方法；其次这些对象一般属于一个集合，主要的操作是集合类操作。
3、深层对象
现实世界中大多数对象都是深层次对象（即多次继承），在实际应用中往往会压扁了使用。

暂时写这些
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

]]> Tue, 01 Jul 2008 12:07:12 +0800 http://helloworld.javaeye.com/blog/210104 http://helloworld.javaeye.com/blog/210104 第二个抽屉 helloworld 作者: helloworld 链接：http://helloworld.javaeye.com/blog/209481 发表时间: 2008年06月29日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

【闭包】
定义：
（Martin Fowler）
闭包的第一个关键点是闭包是一段代码加上和定义它的环境之间的绑定（they are a block of code plus the bindings to the environment they came from）。这是闭包和函数指针等其它相似技术的不同点。

第二个不同点不是定义形式的不同，但是也同样重要。（The second difference is less of a defined formal difference, but is just as important, if not more so in practice）。

类别：函数
绑定：晚绑定
支持语言：几乎全部
理解：
首先是匿名函数，其次是运行期间有独立的上下文，这个上下文与定义它的环境隐式绑定，第三三，书写方式不同。
语义：一类计算，它不仅根据显式参数求值，同时针对域的相关上下文求值。
可靠性：危险
何时使用：A:如果未隐式绑定上下文，则当匿名函数使用；
B：如果绑定上下文，当“自适应”函数使用，即函数适应不同的实例进行计算求值。但是要将其所适应的上下文明确，个人建议对应的变量命名应该是：函数名+By+上下文名+常量名。
如果把值作为名称的一部分，会遇到当引用的具体常量值发生变化时，会遇到需要重构的情况。所以应该定义出一个常量，比如“工资大于1200”，1200这个值一般来说有个意义。
C:持续求值？？：当应用域变量会根据域的上下文变化时，将变量定义为闭包的引用可以实现每次使用该变量时重新根据上下文进行计算。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

]]> Sun, 29 Jun 2008 17:37:28 +0800 http://helloworld.javaeye.com/blog/209481 http://helloworld.javaeye.com/blog/209481 答复: 软件行业2006年终回顾以及2007展望（一）回顾 helloworld 作者: helloworld 链接：http://helloworld.javaeye.com/blog/209011 发表时间: 2008年06月28日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

无论什么技术真正能留下来的只有足迹，而且只有少数被后人记忆。数据对人类太重要的，所以Orcle无疑握着一张好牌。

所以，我们这些人哪，也就是曾经踩着别人脚印走路的人，脚印消失了，我们也就没了生计。

一朝天子，一朝臣，过去的东西换个面孔还会杀回来的，他是谁呢，在未来10年，是IT的大乱时期，哪怕是个无名小卒，有一天也可能成为上海滩的黑帮老大，没有绝对强大的Microsoft，也没有绝对的对手Java，什么东西都可能生存下来，Microsoft不知道对手是谁，因为谁都可能是潜在的对手。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

]]> Sat, 28 Jun 2008 21:05:00 +0800 http://helloworld.javaeye.com/blog/209011 http://helloworld.javaeye.com/blog/209011 答复: 借势而起, 乘风破浪 -- 软件技术趋势大局观预测 helloworld 作者: helloworld 链接：http://helloworld.javaeye.com/blog/209010 发表时间: 2008年06月28日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

布什说我有航空母舰，我有石油，我还有黄金，哈哈哈，赖我何！查韦斯跳出来说，我有炮塔，我不怕你，我们还有很多盟友，我们一定能打败你。让我们看看盟友中都有谁？哦，有内假得，还有卡死XX，铁杆，他们都有一根很小的炮塔，高呼，全世界炮塔团结起来。再来看看，还有谁，对了，还有普鲸，好厉害，说我们不需要那样的民主。又拍拍布什的肩膀说我们结为战略伙伴，好吗？像这样的还有老胡。

最后，谁赢了。不知道。但是赢的那个一定击沉了航空母舰、获得了石油，赚走了黄金。

团结是个梦，阿拉伯人永远的梦。

乘风破浪会有时，直挂云帆济沧海。祝炮塔们新年快乐，存在就是理由，追求的就是乘风破浪而不是岸边嬉戏
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

]]> Sat, 28 Jun 2008 21:03:17 +0800 http://helloworld.javaeye.com/blog/209010 http://helloworld.javaeye.com/blog/209010 答复: 一个可能比SOA更好的思路 helloworld 作者: helloworld 链接：http://helloworld.javaeye.com/blog/209009 发表时间: 2008年06月28日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

比喻为医生植入人体为人治病的小机器人更为恰当。满足以下几个条件：

1）人体的结构是已知的，但具体的参数不同

2）小机器人具有目的信息和收集信息的能力

3）医生可以根据小机器人收集的信息做相应的改变。

与SOA不同，如果同样比喻成病人，这个病人会说：我有一张表格说明我的各种功能。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

]]> Sat, 28 Jun 2008 21:02:48 +0800 http://helloworld.javaeye.com/blog/209009 http://helloworld.javaeye.com/blog/209009 答复: [讨论]中国的程序员，路在何方？ helloworld 作者: helloworld 链接：http://helloworld.javaeye.com/blog/209006 发表时间: 2008年06月28日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

首先是你需要什么，其次才是怎么做．
一类是想发财的，那一定不能安于现状，胆大才会发，做什么事情都可以，只要不是躺在那里抱怨，没有人会将财富放在你面前．
二类是有家小的，想过着相对舒适的生活，那么，一般的程序员肯定不适合你．小领域内的专家适合你，专攻一门技术，具有丰富的经验和知识．这类人还要有一点点危机感，就是不断了解ＩＴ新格局，悟性好的到了要用的时候再学来得及，悟性不好的就要有一点预先准备了，免得突然被炒了．
三类是有志青年，这些人我最尊敬了，职业即其生活乐趣．

四类就是初出茅庐，什么新鲜学什么，打个下手什么的，碰到名师还会给你点化一下．多年未有成就就显浮躁之气．这群人最多．为什么呢，其实其他行业也一样，成为师傅和专家的毕竟是少数，最多１－２成，气力又比不上年轻的．只好这样的，社会就是这样的．

吃得苦中苦，方为人上人，不为人上人，吃一辈子苦．
写了东西就希望有人看．．．修行没到家
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

]]> Sat, 28 Jun 2008 20:59:49 +0800 http://helloworld.javaeye.com/blog/209006 http://helloworld.javaeye.com/blog/209006 答复: 干掉 Microsoft - 从 Borland 卖掉 CodeGear 想到的 helloworld 作者: helloworld 链接：http://helloworld.javaeye.com/blog/209004 发表时间: 2008年06月28日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

个人从感情上非常讨厌MS，但理性的说，Delphi死得其所，算是功成身退；对于建立Delphi的真正功臣却没有消失，而是加入了一个更大的团队，做更大的是事业。MS是非常了不起的，它一步一步的把IT推向平民化，首先是平民化的操作（Windows），其次是平民化的开发（Visual Studio.net)。使得普通人能够在稍许帮助下开发网站；使得小团队可以开发管理信息系统（WCF，WF）；
不要因为情感而有失公正。楼主对VS的印象还停留在VC6。
微软的对立面有两个，一个是商业的对手，另一个是开源领域，类似贵族和剑客，有意无意的在强调血统。前者和微软一样是立场鲜明的，而剑客却个性分明。社会就是这样组成的，缺了谁都不行。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

]]> Sat, 28 Jun 2008 20:57:36 +0800 http://helloworld.javaeye.com/blog/209004 http://helloworld.javaeye.com/blog/209004 答复: Java程序员应该学习Ruby helloworld 作者: helloworld 链接：http://helloworld.javaeye.com/blog/209003 发表时间: 2008年06月28日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

如果就语言本身来讲，同一类型的语言估计不用一天就可以熟悉新的一种。而语言背后的东西就不一定了。
首先是OO的东西，早期的OO你可以看C++或者更古老的面向对象语言...，那是真正的OO，现在的OO血统已经不再纯净，这里有商业的成分存在，有人先将OO做大了，就像是奥运会项目，从过去到现在庞大了不少。然后是大家来竞争，就像各种专项运动协会，纷纷想将自己列入其中。
其次是针对某些领域的特定解决方案，以前是类库的方式解决，独立于语言之外的，现在也成了语言的一部分，如ActiveRecord。
对于这些，我并不反对，因为它确实帮助了程序员的忙。

学习很多语言，尤其是目前发展得最好的命令式语言，每种都会给你带来启发，因此我同意楼主的观点。但是，要清楚事情的本质是什么，实际上可以用一个三层的抽屉来整理所学语言的特性，当你发现其中1个抽屉最早没东西可以装进去；第二个装不满的抽屉，当你要关上它时，时不时的会冒出一点新东西来；第三个抽屉你会发现已经合不上了，但东西仍就像雪片一样飞来。“不要像维护自己的信仰一样去维护自己的而贬低别人的，那毫无意义，因为这所有的东西都没有专利权”。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

]]> Sat, 28 Jun 2008 20:56:15 +0800 http://helloworld.javaeye.com/blog/209003 http://helloworld.javaeye.com/blog/209003 关于语言与架构（五） helloworld 作者: helloworld 链接：http://helloworld.javaeye.com/blog/208845 发表时间: 2008年06月28日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

还是在这篇里完成吧，尽管几分钟后就是星期六了，明天依然不会轻松啊，为了可爱的Money。

原本是没有想写文的，我一贯的作风是爱凑热闹，看看帖子，有感觉就回回贴。那天看见一个帖子，已经锁定了，但是一个称呼程序员的词汇使我很想发个新贴子，帖子就是这个啦“我眼中的ROR”，在这个帖子里，我左一下，右一下，始终无法说清自己的感觉，而贴友们总是在掰着字词，因此有了整理一下自己思路的想法，也为JavaEye添几个石子。

写文章就是废话太多，我已经坚定决心要在这篇里写完，不知续了，因此短短的说说。这篇从前面说起，就说UI层。

UI对于不同的应用系统有不同的要求，作为项目的决策者之一，首先要考虑的是客户对UI的使用频度，客户的文化层度，计算机体验等等。我遇见过最为严峻的UI设计挑战是要为监狱的犯人设计一个电子商场系统，或者叫网上购物系统。我想除非在那工作过或者呆过的人才会和我有共鸣。第二难的挑战是为一个由农村（不是发达城市的哦）自建的市场设计软件，几乎所有的操作者都没有用过电脑。我们完成了这些挑战，但还是出了一些小状况，客户忽然报告说：系统死机了。等到技术人员过去一看，原来是打开了中文输入法无法输入数字了。

架构对于UI的支持在对UI有要求的系统中是非常重要的，有时候关系到你的成败，而这也是架构开发者需要投入最大量工作的部分之一，因此，很多开源的架构无法对此做到很好的支持。我对最新的类似WPF的UI理念感兴趣，但确实还没有阅读全文。但Delphi的VCL架构是很熟悉的，应该说做业务类应用够了，要更进一步的话，相信玩过IPHONE的人会有感觉了，Windows 7估计也是这个路子。我在帖子里提到VCL貌似在.net中重生了，这个是没有经过确证的。但vs2008也实在是太慢了，我不知道我是否应该配一个梦工厂工作站来支持VS2008。

写到业务层，我不惜抛出一个很丢脸的事情来，前些年，去台湾人的工厂去争取一个项目，用的是Java技术，方案讲解得不错，价格也很有吸引力，然而在第二轮的时候，我出逃了。因为我发现找遍开源社区，我也无法找到可以实现那个工作流的引擎。而我的报价又仅仅是可怜的一些开发劳务费，还不够买weblog最少的lic。没有任何办法，只好退却。架构对于业务层的支持就在于此了，如果仅仅是实现分层，那么要架构何用？很多架构恰恰是这样，不去做好帮助程序员的工作，而是给程序员提出很多的规范，比如要求在这层中再进行细分，分成Event，helper....等等。

对于大部分的MIS系统架构来讲，一个工作流引擎的支持是十分必要的。其它类型的架构则需要一些其他的支持，这里只讲MIS。

有人会讲，有很多开源的工作流引擎还有问题吗，有。首先是这个工作流引擎包含在架构中吗？其次是，这个工作流引擎能够满足你的需要吗？第三，你的团队要多久才能掌握和使用它。它有很好的工具和文档吗？
也许有人讲，自己写一个吧，那我向你竖起大拇指，但是我不会请你来做事，因为我没有财力去做这件事情。

工作流引擎作为MIS类型架构的重要性容易理解，根据业务的不同，我们也许还需要架构在其它一些方面给予支持，包括SOA，包括Job，包括REST，包括Secuity等等。

文章写到这里，也差不多该写完了，有人会建议.net吧，他符合你的要求。是的，我在用，但是它太胖了，以至于我看不见它的脸。有人说ROR吧，我心有余悸的说，在这个架构上工作的人多不多，当我的Ruby程序员辞职时，我需要多少钱从人才市场再找一个，如果是Java程序员的价格，我为何不选择Weblogic呢，那样系统的利润才够我去征用这些杰出的战士啊。

#End Document
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

]]> Sat, 28 Jun 2008 00:34:37 +0800 http://helloworld.javaeye.com/blog/208845 http://helloworld.javaeye.com/blog/208845 关于语言与架构（四） helloworld 作者: helloworld 链接：http://helloworld.javaeye.com/blog/208840 发表时间: 2008年06月27日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

说架构，远不如讨论语言来得有感觉。架构这个词有点别扭，是这几年才说得比较多的一个词语。没有感觉就顺便先说几句。

从问题出发，我们要解决一个应用系统，实现其目标，并不是一件容易的事。这里不再掉书包说以前的方法了，就说眼前的。眼前的架构不管其名称是什么有一点是共同的，那就是多层结构，最普遍的是三层结构。为什么是多层而不是一层或两层，这个是科技发展过来的，说不上什么道理。这好比以前建砖瓦房，现在建框架房一样，将梁和墙分开被事实证明是一个正确的选择。

普通的三层结构，一般分为数据层，业务层和UI，数据层简而言之是是实现数据存取，数据关系，核心就是数据库。对于普通的应用而言，Oracle，DB2和MySql没什么区别，因此在这一层里应该没什么猫尿才对。但恰恰相反，不知道是我理解不深还是没做过什么大系统的缘故，这里有ORM，有JDO，有Active Record（刚刚看过介绍文章），天啦，尿多去了。（全是因为OO建模的关系）

数据层不讨论了，因为我的观点这时候不用说读者也明白了，与其说出来找骂不如保留观点。业务层的内容就多了，有很多人认为一个系统的核心就是这层内容了。我认为这层很重要，系统实际上是RUN在这层上的。但是这个层不是核心，核心是两个，一是数据层和业务层的设计以使既能够满足业务需求，又能够适应需求变化的要求。这话说起来有些拗口，没关系，老外已经把这个总结为“分析模式”了，当我看到这本书的时候，我不是感到激动，而是佩服，佩服He能够把这么宝贵的经验拿出来，而且还整理得这么好。对于这个核心，我要说的是，不是了解或者掌握了OO建模就能够把这件事情干好的，因为按照OO建模的理论，是要将现实世界映射到OO，而映射的结果将会很多，分析模式中提供的方案绝不会是最直观的。这里面充满了技巧和经验。

另一个核心也和需求所反映的逻辑关系无关，另一句拗口的句子，将业务层换成了UI层。那就是切身体会的理解用户的UI操作体验，用一把小刀修修你的数据层。要获得美丽的容颜，仅仅靠化妆品是不够的，适当的修修内功，内外兼收才能培养出绝色美女。

关于应用系统核心的观点有很多人会不同意，管别人怎么想做什么呢，我既然写了出来，我就先占据了主动，不是吗？又要待续了，因为财务的原因，买的房子楼层低，有蚊子了，还是用火点的蚊香可靠些，技术里也有很多像老蚊香一样实实在在的东西，不要丢掉哦！
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

]]> Fri, 27 Jun 2008 23:34:56 +0800 http://helloworld.javaeye.com/blog/208840 http://helloworld.javaeye.com/blog/208840 关于语言与架构（三） helloworld 作者: helloworld 链接：http://helloworld.javaeye.com/blog/208732 发表时间: 2008年06月27日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

对于语言来讲，我讲得实在太少了，一方面是对于具体的语言而言，我很多是浅尝即止，没有很深入的研究，比如Ruby，Python，以及Prolog，等等，这些语言由于没有具体使用，所以谈不上理解。另一方面则是由于气氛的原因，怕引起无意义的争论，不能多讲。

前面谈到语言的具体使用，使用无疑是了解掌握语言最好的方法。比如，有一段时间由于需要，天天泡在“看雪”，熟悉了各种破解工具的使用，并因此将原来只是写在书本里的汇编装进了Head。我们在做这样一些事情的时候，我们仅仅只需要语言的帮助就可以了，我们写一些小程序的时候也是这样。当我们需要面对一个系统时，情况就发生了变化。

很显然，大家都会知道我要说的是“架构”这个词语。早期，在Dos下编程时，我还在热衷于用C语言画出来的按钮哪里要多画一笔以创建阴影，显示立体效果，并乐此不疲的时候，我并不会意识到系统是什么。到了现在，我还很难确切的去描述它，所以用一些感性的语言来说，而且仅仅是说我们常常面对的MIS系统。

时间是系统的一个重要因素，离开了时间这个概念，好像什么都失去意义了。对于系统来讲，时间在很多地方存在，系统第一次和用户见面的时间，系统建设所花的时间，系统存续的时间等等。时间对于开发者来讲，也是非常重要的，就不必多说了。

目标是系统存在的原因，因为要达到某个目标才会去构建系统，人们不会去构建一个比微生物还小或者比恐龙还大的不知道是什么东西的系统，你一定能够给你的系统取一个名字，这比给儿女起名容易多了，因为这个名字即系统的目标。

钱是世界上最大的游戏工具，在系统中自然少不了钱的概念，有了另外的名词：成本和利润。在系统的建设阶段，存续阶段，没有利润的事开发商不会做，没有成本预算的事，业主不会做，难道不是吗。很重要的事情是往往会忽视系统存续阶段的金钱问题，有两种典型：一种类似买了一辆国产车，前期便宜，后期金钱不断；一种是买了进口车，不管便宜还是贵，如果业主后期只愿意出很少的钱来维护，开发商没利润（不是什么技工都能修进口车的），车子实在没办法的时候只好当废铁。

人是系统中不可或缺的部分，这包括创建系统的团队和使用的团队。先说使用的团队：一般评估系统的规模时只从系统的目标入手，看看业务模型的规模，我也这样做过，但现在我看系统的规模首先看使用团队的规模，涉及到多少部门，多少人，多少领导等等是系统决策和定价的必要因素。

至于建设团队来讲，个说个话，有很多书，文章讲了不少了，都有道理，看你怎么应用。我想一个优秀的项目经理总不至于在一个团队中采用清一色的中科大吧，也不至于请中科大的人都来画按钮，团队需要分工，架构因此产生（顺口而已，架构怎么产生的我不知道）。

废话很多，后面再续吧
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

]]> Fri, 27 Jun 2008 16:38:20 +0800 http://helloworld.javaeye.com/blog/208732 http://helloworld.javaeye.com/blog/208732 关于语言与架构（二） helloworld 作者: helloworld 链接：http://helloworld.javaeye.com/blog/208625 发表时间: 2008年06月27日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

谈到同一类型中语言的选择，对很多人来说都是不一样的，这里说说我的观点。

排除掉被迫的，不由自主的选择，这些不由自主的选择有的是团队要求的，有些是客户要求，更多是由平台决定的。排除掉这些因素的作用，就是自己的感受了。

某些思想在语言级的支持是一个很重要的因素，比如说OO的支持。尽管要在语言中应用某种思想，对像C这样的语言也是可以办到的，但在语言级的支持会使得实现变得更加自然。现在不仅仅是OO思想，还有一些谈论得较多的特性在不同的语言有着不同程度的支持，这也是目前对于各种语言争论最多的部分。然而，还有一些很朴素东西被人们忽视，如结构化和并发的思想，这些很早就有的东西，随着OO思想的鼓吹，被很多人所忽视。我在看到Verilog HDL语言的时候，就被这种语言的这两种特性所吸引，印象最深的就是Wire变量和持续赋值的概念。随着OO万能的思想被怀疑，很多朴素的东西成为新的语言特性，如函数语言的一些特性。但这些特性本来朴素的面孔由于激烈的辩论和宣扬，变得光彩夺目，好像反而成了语言的根本。我常常和人说，你知道为什么“常量”作为语言的第一课吗，因为面对的现实世界中常量是如此的重要，所以放在第一课，但是很多人在忽视它的存在，仿佛他的世界只有变量。。

现代语言的一个特点是很多“重量级”的成员往往会有一个库在支持，这些库提供了很多可重用的便捷的调用以完成某些功能。使用这些库时有两种方式，显式调用和隐含调用。显示调用比较容易理解，这里就不解释了。而隐含调用可能是语言和库融为一体的方式如linq。当这些库专注于某个领域时，我们感觉不是在操作计算机这种冷冰冰的硬件，这种体验是非常不错的。然而当语言变得无穷大时，库也变得巨大，这个感觉就不好了，我们不知道我们面对的是一个什么东西，不是你能够在地球上看见的任何一种东西，甚至连恐龙都不是。

我早先使用VI编辑程序，当时用的时候很激动，觉得功能非常强劲。然而自从到了Windows平台，原来熟悉的操作已经不会了。这时候编程工具有点像我以前学的五笔，尽管打得快，但是一段时间不用，忘得也快。那么简单的记事本是不是很好呢，有的时候是的，写几行脚本无疑很方便。

当您面对一个系统开发时，开发工具也成了选择语言的一个考量。没有人会用记事本去开发一个大的系统，开发工具是否足够智能，是否足够简单易用决定您是否能够将主要精力用在解决问题上。VC6的感觉是痛苦的，而VS2008的感觉是美妙的。对于非W平台，很难用一个工具去处理大部分的编程问题，我往往都是多管齐下，写脚本的用Jedit，写XML的用XML编辑器，写工作量的用JaWE，写Java的用E...,我实在是拼不出这许多单词的名字，但我知道就是它，名字不重要。

对于语言来说，我实在讲不出更多的东西了，但我是诚恳的，我以Hello World为网名是因为我们认识每一个语言时，我们和它打招呼的方式都是一样的。尊重每一种语言从Hello World开始。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

]]> Fri, 27 Jun 2008 13:48:30 +0800 http://helloworld.javaeye.com/blog/208625 http://helloworld.javaeye.com/blog/208625 关于语言与架构的观点（一） helloworld 作者: helloworld 链接：http://helloworld.javaeye.com/blog/208589 发表时间: 2008年06月27日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

文章这个提法对于我来说感觉不敢担，所以我的博客里原来看不到文章，只有贴子。

但帖子实在是太长了，而且容易引起一些不必要的“吵架”。决定写一篇文章来系统的描述一下我的一些看法。

语言最初是和物理对应的，为了使人的表达能够被机器所执行，从汇编到C都是和硬件对应的。从C++开始，在语言领域就开始出现一个动词Think in，人们努力想让语言逃出硬件的禁锢，进入思想的领域，至今为止，这个趋势将继续。这有点像人类艺术的发展，从实物写生到抽象艺术，语言开始变得有思想，不同的程序员开始创造出不同的作品，这些作品开始会让人充满感情，会因欣赏而激动，会因观点不同而批评。这些作品再也不能用简单的正确和错误来评判。

Java虚拟机不自觉的开始了语言新的里程碑。虚拟机对语言的意义是，语言开始拥有了属于自己的虚拟硬件，语言可以领先于硬件的发展。这对于语言的本质而言是非常有意义的事情。在这点上，我没有去想所谓一次编程到处使用的意义，也没有去想通用语言引擎的意义。相反，这些被宣传的意义导致了虚拟机的无限膨胀，退化成了函数（对象）库的堆积。

语言被设计用于各种目的，用于指令系统的，用于状态机的，用于系统设计的，用于推理的，用于规则计算的，用于硬件设计的，用于文档处理的，用于构建语言本身的，用于科学计算的，用于人工智能的，用于图像处理的等等，举这么多类型，并不是要显示我的知识多么的广博，只是我能够想得到的，而我所能想到的也只是很小的一部分。思想是独立于语言的，可以被使用在一种或多种语言上，如面向对象和结构化思想可以被用在指令系统，系统设计，硬件设计等语言上以增强语言的表达能力。

对于选择语言来讲，这里是讲在同一类型的语言中选择。语言的基本状态都一样，我们所选择的是什么呢？（待续）
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

]]> Fri, 27 Jun 2008 11:59:57 +0800 http://helloworld.javaeye.com/blog/208589 http://helloworld.javaeye.com/blog/208589 读：分布式系统的角度看REST helloworld 作者: helloworld 链接：http://helloworld.javaeye.com/blog/138755 发表时间: 2007年11月07日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

原帖：http://www.javaeye.com/topic/82227
将REST定义为一种风格，架构的一种风格是合适的。但个人觉得应该有更合适的词语。REST不是一种具体的架构，也不是架构的一种规范，而是一个架构的指导思想或理念。这个思想有两个重要组成：简约和HTTP，前者易用，至于后者则是对Http协议的一个诠释（谁说http只是用来传递网页的），呵呵，好比谁说电话线只能用来打电话。
REST和分布式对象以及分布式个人认为完全不冲突，首先，以前人们考虑分布式时总是一个非常非常沉重的话题，类似的言论还有“电信系统是一个非常严格的系统”等等，这是REST主要要推翻的东西，好比淘宝推翻了“批发价就是大批量购买的价格”之类的东西。REST要革命的是思想，互联网时代开发人员的思想。
在互联网时代，几乎所有的企业都意识到了自己是否互联网企业的重要性，是否互联网企业并不仅仅说有一个主页了事，而是，你的客户，你的供应商，广告商，企业员工等等能否在互联网上很好的协作。呵呵，这是一个更大的分布式应用。对于自己内部的分布应用，我们已经有了很多协议和架构可用，它们是严谨的，安全和差错控制的。对于这个更大的，该怎么办呢。好像没有太多的办法，因为尽管你可以和你的供应商协调接口，但是太多接口了，因此REST作为一种风格出现了：简约+http。
那么，REST和EJB等如何共存呢。即使你是所谓电信的严格应用，到了WEB层面就应该以一种更简单的形式调用——将你的分布式对象wrapper一下，以REST风格发布出来，呵呵。
后话：以前光纤网络没有普及的情况下，网络应用运行在不可靠的连接中，分布式技术是一种重要的解决方案，主要强调可靠性。光纤网普及了，分布式应用很多都改成集中的了，分布式技术转而面向企业EAI，应用服务器从某种程度上来说就是分布式技术的一种转型，作为企业应用的粘合剂。但这是建立在企业内部（或紧密合作伙伴间）。
现在的互联网应用，好比当年的网络应用，连接不可靠，是否也采用当年的思路去解决问题，保证可靠的应用呢？显然，行不同，因为参与者不确定的情况下，很难制定协议。只有一种办法，舍弃。完全背道而驰的思路（所谓革命）。在应用服务器层面粘合，看来也不可能了，那就从浏览器层来粘合。
因此，不能接受REST的人，也是思想比较僵化，不善于开放思想的人；过分崇拜REST的人，是比较盲目的人，一个客观的IT工作者，以尚悟的方式去接触新技术，不要被某种思想或技术所毒害。（我常常称有些人被面向对象给毒害了）
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

]]> Wed, 07 Nov 2007 13:32:19 +0800 http://helloworld.javaeye.com/blog/138755 http://helloworld.javaeye.com/blog/138755