分类目录归档：无责任乱评

Borland要把开发工具部给卖了

发表评论
    这两天对Delphi社区影响大的无疑就是这个消息了。现在的我已经成功的转到JAVA开发下面了，Delphi对我来说更多的是业余时消遣的玩具。对Delphi的一些新动向虽然也会去了解，却也不是很感兴趣。最近Dephi的发展主要都是放在.net和IDE的扩展上。但我只只用Delphi的win32开发，至于IDE方面，我已经被D7的IDE虐习惯了。在安上Moldermaker和cnpack之后感觉还不错。
    尽管如此，Borland出售开发工具部门还是一件大事，毕竟玩了这么多年的Delphi，而且现在还在用Borland的JBuilder。
    即使没了Jbuilder我们还可以使用eclipse，JAVA还会发展，但Delphi？相对其他开发语言来说Delphi应该说是封闭的，Delphi一直都是在Borland的掌控中发展。没了Borland谁来支持Delphi。
    就我看来Delphi的前景是暗淡的。Delphi的优势主要体现在传统的win32环境中的RAD开发。但就目前的情况来看win32的开发已经开始走下坡路了。实际上现在的Delphi开发人员就已经流失的很厉害了，比如我。在.net开发方面。delphi可以使用vcl来开发。vcl固然是个很优秀的东西，但毕竟已经是个老古董了。现在的.net的设计已经很完善，完全没必要多此一举的封装一下。
    borland的工具开发部门谁买？
    windows平台卖给MS？怎么可能。MS自己有完备的.net和win32开发工具，再买这个也多余。买过来消灭竞争对手？只有打不过的时候才会这么做。现在Borland都这样了已经犯不着用这一着了。
    JAVA平台卖给IBM。尽管我不得不承认JBuilder是个很不错的东西。但我想IBM还是不太可能会要。IBM是个精明的商人。IBM用开源模式成功的将eclipse推向了java开发工具的巅峰，将jbuilder给做了。jbuilder IBM就是买过来也没什么用。买来送给开源组织？怎么可能。我倒是挺希望SUN吧Jbuilder给买过去。虽然sun是java标准的制定者，但sun的IDE就一直没有流行起来，以前是jbuilder，现在是eclipse。netbean和jbuilder都是基于swing的。如果sun能将jbuilder中的优势整合到netbean中应该能出现个不错的东西出来。对我这样一个对eclipse颇有微词的人来说，我还是很希望能出现个这么样的东西的。
    不管怎么说，还是希望Borland给自己的开发工具们找个好买家吧。

Ruby vs Java? and appfuse

发表评论

    《新技术倍出 谁最可能挑战Java开发优势》，感觉挺恶俗的一个名字。不过既然要圈钱就得制造点事端，制造点热点。一个东西不管好不好，有人理就是好事。

    JAVA，为什么又是JAVA不是PHP、ASP。因为JAVA红，俗话说人红事多。现在的新人为了吸引眼球总得拉个大腕作幌子，就象前一阵子天涯上的猫人。JAVA，因为JAVA红。

    又是Ruby，又在CSDN上看到关于Ruby的帖子。我一直都承认我对脚本语言是存在偏见的，而且固执己见。

    Ruby可能流行吗？可能。 Ruby能挑战Java吗？表示怀疑。

    JAVA其实可以更简单，JAVA目前的这个局面更多的是因为厂商利益。在Ruby开始威胁到JAVA的时候，JAVA可以变得简单起来。而且在提供方便性将在一定程度的限制功能。有时候，一个东西完善的过程，也是一个复杂化的过程。我觉得Ruby应当是这样的一个东西。最重要的一点，Ruby的定位和JAVA不一样。JAVA定位相对比较高一些。要抢底盘也是抢PHP的，JAVA受到的威胁相对要小一些。

    又想到了APPFUSE。APPFUSE一个不错的集成框架。而且自身带的代码生成器使用也很方便。只要写完VO并为VO写上XDoclet的标注后，直接运行ant命令就可以自动完成数据库的部署并将包括表示层的所有相关代码生成。完全一站式的代码生成。

    既然APPFUSE如此完美为什么没有广泛的流行起来？

    Appfuse基于脚本的代码生成，对细节封装得不够（或者说隐藏吧）。虽然完全按照Appfuse的预定流程来作很方便，可以实现对开发细节的隐藏，但在大多数情况下大家都需要对框架进行扩展来实现自己的需求。既然要扩展，你就必须要了解框架的具体实现细节，而appfuse使用的技术N多。如果要熟悉还是得花些时间的。

    说到这里可能很多人要说到JAVA的复杂性了。对，JAVA很复杂，但同样也可以很简单。虽然技术多，但并不不代表你要了解的东西要很多。技术是用来简化开发的，如果一个新技术的出现反而使开发复杂化了，那这个技术是不值得采用的。在appfuse中采用的新技术都是有其价值的。appfuse缺的是文档。不光是appfuse的文档，还有appfuse所采用的技术的相关文档。这些文档不需要很复杂，只要那么一两页纸告诉框架的使用者这些技术是用来作什么的。对于这些技术只介绍必要部分，暂时用不着的都不用讲，尽量简化（隐藏）框架的复杂性。

    appfuse中大量的使用了ant脚本来实现自动化。但也正是由于过于依赖这些脚本，导致框架和IDE的结合不是很好。到目前我还不是很清楚怎么用IDE对appfuse进行调试。虽然这很可能是因为我对appfuse的研究不够，但对于一个以方便为目的的框架，不应该将和IDE的整合交给框架的使用者去作。

    还有就是appfuse的那个权限系统实在是让人有些不爽。不同系统对权限系统的要求都不一样。权限系统这一块本该是可以灵活配置的，可以很方便的从系统中移除，自己实现。但appfuse的权限系统和框架绑这么紧，要分出去多少还得话些时间。

    说了这么多appfuse的“坏话”，不过还是希望appfuse能快速成熟起来。对appfuse来说功能不是问题，最大的问题是人性化，JAVA也是这样。

 

PS：最近看到appfuse有个代码生成器的子项目appfuse generator。用Velocity替代xdoclet作为模版生成引擎。刚开始研究，还不清楚和appfuse里面集成的代码生成器相比有什么优势。

新版本的appfuse集成了一个缓存系统，有时间可以研究一下。