J++ = Java + ?

[深入的思考] 为什么要采用java这个平台？

从开发项目的类别角度看java平台

基于B/S结构的系统，在这个方向上的竞争是激烈的，有专注于此的LAMP（Linux + Apache + Mysql + Php）;也有刚刚兴起的Rails（Ruby Frameworks）甚至是号称快速开发的ASP.NET;当然了java在这个领域里的MVC框架数都数不完，比如Struts . Webwork等，然而即便是如此，选择java作为开发的理由也是不充分的，因为在这个梯队里java顶多排名最后。

基于C/S结构的系统，在这个方面java显然没有考虑周到，面对VB 、DELPHI、vc这些个如狼似虎的快速开发IDE，JAVA实在是显得异常的淡薄，即使你找到了一个可以匹敌这些个ide的工具，面对第三方的组件又会成为一大障碍，所以java在这个方面又一次的输了。

从java所强调的特性角度看java平台

java的重点是业务逻辑！（我以前也是如此坚信不移）可是谁有能够说别的语言不注重业务逻辑呢，业务逻辑只是一个抽象的概念，java只是依靠ejb提出了业务组件而已，其他的语言在实现业务逻辑的时候也可以包装成POJO的形式，看来这个观点也是失败的。

java强调的是跨平台的优势！这可以理解为初级的、商业的、忽悠人的词汇，面对众多动态语言如Python，在若干平台上的表现，java又如何来强调自己这方面的优势呢？失败

java支持分布式应用的项目！可笑的言论，分布式根本不是值得炫耀的资本，在java之前的c/s项目中何尝不是分布式的应用呢？失败

既然没有了这些个优势，我们看看java到底还剩下些什么？对了其实就是应用服务器！然而看过J2EE WITHOUT EJB的读者肯定知道Spring所希望达到的目的，也就是脱离应用服务器概念上的J2EE体系实现，既然在作者的眼里APPLICATION SERVER只不过是一个忽悠人的词汇，那么任何项目都选择java作为开发的依据显然就是自找苦吃，

那么什么情况下改选择java作为开发的平台呢？
<1> 如果你真的遇到了大型的系统开发任务，恭喜你，你终于可以看到分布式对象、集群的优势了。
<2> 客户是一个java的忠实fans或者是sun、ibm的金牌合作伙伴之类的，选择java是不得已的，但记住并不能证明java是最好的实现方式
<3> 如果你只想关心业务逻辑的实现，对于事务、缓存、查找等服务的实现没有兴趣的话，倒是不妨考虑采用ejb的形式，当然前提是你不愿意在寻找合适的替代品的情况下。
<4> 如果项目迫切的寻找某种框架的支持，选择java就是对的，你有众多优秀的、免费的、可扩展的、天才的框架可以选择，更多的时候你是出于尴尬的境地，因为任何一个都让你心动、而这样的选择往往是最痛苦、和快乐的。

正确的选择
<1>
条件: 如果项目仅仅只是一个小型的网站系统
选择: LAMP、Rails

<2>
条件: 项目规模中等
并且项目的时间比较紧，
项目可以架构在windows的系统之上，
选择: .Net  / Delphi

<3>
条件: 大型的系统，有支持分布式对象、集群的要求；或者SUN / IBM的金牌合作伙伴 ; 想要寻找某种优秀的框架来解决问题
选择: java是不二的选择，可是我想问一下，在现实中你能遇到这样的项目吗？

所以，从实际的角度出发，我们面对的99％可能都是一些符合条件1，2的系统，而选择java实在是得不偿失的。最后以一段Code Complete中的话来作为结束语

每个程序员都有很多的工具，但并不存在任何一个能够适用于所有工作的工具，因地制宜的选择正确工具是成为能有效编程的程序员的关键。

 

作者简介
XincChen是Xtremework公司创始人.a自从.NET推出以来,1他已使用.NET帮助很多行业的用户开发了体现其商业理念的软件产品.aXincChen是.NET和EAI方面的专家,1他与Microsoft和Accenture等多家技术领先的公司合作,1为它们的客户提供了优秀的解决方案.a在工作之余,1他喜欢读书.c写书.c以及静静地休息.aApress出版社的另一本书——《BizTalkc2002cDesigncandcImplementation》——也是出自他的笔下.aXincChen拥有哥伦比亚大学的统计学文科硕士学位,1现居国内,1正在筹建公司在北京的研发中心.a可通过xchen@Xtremework.com和作者取得联系.

个人评论

这本书本来购买时的期望值非常的高，想必是一本细数.NET框架类的图书，结果却大失所望，而这本书也就因为其技术上的薄弱而消弱了其价值的表现力，不过作为一本.NET入门级的图书还是比较的合适，但在CSDN上竟然有四颗半的星的待遇实在不敢恭维。

而且作者的代码显然非常的粗造，竟然连起码的业务级数据校验都没有，在一些功能的分解上也是抹浆糊，可以想象作者并没有深入的思考而仅仅是去实现功能而已，猜想这样的框架很可能是作者对于以前工作的简单抽象而已。

整体上本书除了第一章应用框架介绍 、 第二章应用框架解析比较的出彩，尤其是创造性的提出了业务假设（Business assumption）的概念还比较的有深度，其他的章节只是对于其SAF框架的介绍，但在技术实现上只是对于.NET的若干相关服务的简单包装而已，对于已经在JAVA世界里的人来说,SAF框架其实就是Spring框架在.NET世界的简单实现版本，但相对于Spring的技术实力，作者还需要努力才行，不过作者显然是.NET方面的高手，对于.NET世界提供的杂乱无章的服务特性以及服务的原理非常的清楚，这也难怪在这样的平台上再去"多此一举"的开发另外的框架，无论从技术上还是推广上都非常的难！不过领略一下..NET的秀发也是多少有所收获的 :)

再次强调这本书仅仅只能够算作.NET方面的初级读物，个人评星3.5 ，请朋友们谨慎购买。

wfc是构建在B/S结构上的流程定义工具

具备以下的功能
1> 实现了B/S结构上的工作流定义工具（没有看到同类型的产品）。
2> 流程定义格式与具体的工作流格式相分离，并可以在此基础上实现其他的流程定义工具产品。
3> 采用了Buffalo（XML-RPC的javascript实现）实现与后端Servlet的绑定。
4> 可以对具体的节点进行属性的配置（配置后的数据会被绑定为java的List自动传递到后端）。

目前还需要改进的
1> 修改目前工作流的图标（需要分支、状态、合并这样专业的图标）
2> 解决浏览器的刷新问题。
3> 增加线段的表现形式选项
4> 增加曲线的表现形式，尤其是在多线段的情况下要自动调整为曲线的形式。


目前的WFC已经被Michael Chen（buffalo的作者）收录在其网站上！地址如下
http://demo.amowa.net/wfc

对于buffalo的关注早在作者刚发布的时候就已经开始了，起初不太了解buffalo的作用，然而在具体的工作中寻找基于XML-RPC协议的产品时突然明白了它的价值，不过说简单一点buffalo是实现了基于javascript的对象的序列化以及反序列化工作。

通用类图书

卓越奖: Prefactoring by Ken Pugh (O'Reilly)

生产力奖:
Innovation Happens Elsewhere: Open Source as Business Strategy by Ron Goldman, Richard P. Gabriel (Morgan Kaufmann)
Producing Open Source Software: How to Run a Successful Free Software Project by Karl Fogel (O'Reilly)
The Art of Project Management by Scott Berkun (O'Reilly)

技术类图书

卓越奖:Agile Web Development with Rails by Dave Thomas, David Hansson, Leon Breedt and Mike Clark (Pragmatic Bookshelf)

生产力奖:
Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries by Krzysztof Cwalina and Brad Abrams (Addison-Wesley)
Practical Common Lisp by Peter Seibel (Apress)
Why Programs Fail: A Guide to Systematic Debugging by Andreas Zeller (Morgan Kaufmann)

企业项目管理

卓越奖: WelcomRisk 2.6 (Welcom)

生产力奖:
Corticon Business Rules Management 4.0 (Corticon)
JBoss 2 Portal (JBoss)
Visual Studio Team System 2005 (Microsoft)

数据库引擎和数据工具

卓越奖: Microsoft SQL Server 2005 (Microsoft)

生产力奖:
Berkeley DB 4.4 (Sleepycat Software)
Google Maps API 2005 (Google)
MySQL 5.0 (MySQL)

缺陷跟踪，变更和配置管理

卓越奖: Perforce SCM 2005 (Perforce)

生产力奖:
FogBugz 4.0 (Fog Creek)
Guiffy SureMerge 7.0 (Guiffy Software)
JIRA 3.4 (Atlassian Software)

设计和建模工具

卓越奖:Lattix LDM 2.0 (Lattix)

生产力奖:
Borland Together 2006 for Eclipse (Borland)
Enterprise Architect 6.0 (Sparx Systems)
MindManager Pro 6.0 (Mindjet)

开发环境

卓越奖: Visual Studio Team System 2005 (Microsoft)

生产力奖:
Eclipse SDK 3.1 (Eclipse.org)
IntelliJ IDEA 5.0 (JetBrains)
Komodo 3.5 (ActiveState)

类库、框架和组建

卓越奖: .NET Framework 2.0 (Microsoft)

生产力奖:
Dundas Chart for .NET 5.0 (Dundas Software)
Qt 4.0 (Trolltech)
Spring Framework 1.2.6 (SpringFramework.org)

移动开发工具

卓越奖: Crossfire 5.6 (AppForge)

生产力奖:
Carbide.c++ Express (Nokia)
Flash Lite 2.0 (Adobe)
NetBeans IDE 4.1 (Sun Microsystems)

项目质量管理

卓越奖: Rally 5.6 (Rally Software Development)

生产力奖:
CollabNet Enterprise Edition with Project Dashboard/Task Management 2005 (CollabNet)
QACenter Enterprise Edition 5.1 (Compuware)
TargetProcess Suite 1.4 (TargetProcess)

安全工具

卓越奖: Elemental Compliance System 1.4 (Elemental)

生产力奖:
CodeAssure 2.0 (Secure Software)
DevPartner SecurityChecker 1.0 (Compuware)
Fortify Security Tester 1.0 (Fortify)

测试工具

卓越奖:VMTN Subscription 2005 (VMware)

生产力奖:
Agitator 3.0 (Agitar Software)
AQtime 4.7 (AutomatedQA)
Clover 1.3 (Cenqua)

实用程序

卓越奖:Camtasia Studio 3.0 (TechSmith)

生产力奖:
DevPartner Studio 8 (Compuware)
Fog Creek Copilot 1.2 (Fog Creek Software)
ReSharper 1.5 (JetBrains)

Web开发工具

卓越奖: Rails 1.0 (rubyonrails.org)

生产力奖:
JBoss Application Server 4x (JBoss)
Macromedia Studio 8 2005 (Adobe)
Zend Studio - Enterprise Edition 5.0 (Zend)

名人堂产品获奖者:

?Visual Studio Professional Edition (Microsoft)

感慨
    MS在这次的JOLT中屡获殊荣，深思。。。

很久都不骂人了，可是一不留心又看到了他写了恶心文章，实在是让人愤慨！这位板桥里人的"大名"是从透明的blog上知道的，首先就是感觉这个人的脑子有点问题！不去评论他发布的那个所谓的框架，就看看他写的一些文章就足以知道这个人脑袋非常的混乱，在这样混乱的情况下写出来的文章也就可想而知了，最近这位所谓的"大侠"又开始害人了

你还在用if else吗？－ http://www.jdon.com/artichect/ifelse.htm


面向过程设计和面向对象设计的主要区别是：是否在业务逻辑层使用冗长的if else判断。如果你还在大量使用if else，当然，界面表现层除外，即使你使用Java/C#这样完全面向对象的语言，也只能说明你的思维停留在传统的面向过程语言上。

－我很纳闷了作者怎么可以从是否使用if else来判断一个设计是否符合OO特性呢？我们看到的if else属于语言这个层次的东西，而if else仅仅是完成逻辑判断的语句；如果说作者的这个观点成立的话，java、c#的语言发明者应该早就明白或者预测到if else 的"不OO"的特性，也会考虑到在语言层面删除这样的逻辑判断语句，但事实呢？发明者非但没有删除相反其他语言的发明者也一起发明了if else语句？！难道是大师们错了？

还是以大家熟悉的论坛帖子为例子，如ForumMessage是一个模型，但是实际中帖子分两种性质：主题贴（第一个根贴）和回帖（回以前帖子的帖子），这里有一个朴素的解决方案：
建立一个ForumMessage，然后在ForumMessage加入isTopic这样判断语句，注意，你这里一个简单属性的判断引入，可能导致你的程序其他地方到处存在if else 的判断。

　　如果我们改用另外一种分析实现思路，以对象化概念看待，实际中有主题贴和回帖，就是两种对象，但是这两种对象大部分是一致的，因此，我将ForumMessage设为表达主题贴；然后创建一个继承ForumMessage的子类ForumMessageReply作为回帖，这样，我在程序地方，如Service中，我已经确定这个Model是回帖了，我就直接下溯为ForumMessageReply即可，这个有点类似向Collection放入对象和取出时的强制类型转换。通过这个手段我消灭了以后程序中if else的判断语句出现可能。

－作者在这里似乎列举了一个例子,可是对于帖子和回帖这样简单的问题，只要遵守OO的设计师都会抽象出一个帖子的父类，然而这又能说明什么呢？在具体的业务逻辑中难道你不判断传递过来的对象的类别？（现在主题贴与回帖的处理方法是不同的），同样你无法避免在具体的编码中使用if else的可能？！


最后总结：将if else用在小地方还可以，如简单的数值判断；但是如果按照你的传统习惯思维，在实现业务功能时也使用if else，那么说明你的思维可能需要重塑，你的编程经验越丰富，传统过程思维模式就容易根深蒂固，想靠自己改变很困难；建议接受专业头脑风暴培训。

　用一句话总结：如果你做了不少系统，很久没有使用if else了，那么说明你可能真正进入OO设计的境地了。（这是本人自己发明的实战性的衡量考核标准）。

－显然作者并不是去讨论if else的语言问题，而是为自己的"洗脑培训"打广告！并讲这样的问题上升到设计模式、禅的境界，可谓是煞费苦心呀，没有人说设计模式不好也没有人怀疑禅的境界的高深，但不是作者这样的人靠读一两篇文章或者发布个所谓的"毫无实际意义"的框架就可以领悟到的，还是那句话：长得丑不要紧，不要出来吓人！不过我还要补充一句就是，不懂不要紧，不要乱说免得害人（因为我们都知道泼妇骂街的道理，虽然没文化但确实能够带来眼球效应）。

该死，鼠标瘫痪了！
本来以为是Maxthon的问题（在鼠标单击的时候会关闭一些窗口，并且是随机的？！）还就这样的问题给作者写了一封信？汗。。。经过仔细的寻找原因，原来是自己的鼠标的问题（这个鼠标跟了我快7年了，Logitech最好的滚轴鼠标，要300多块大洋）有点舍不得，又没有办法，该下岗了，一同下岗的也许还有我的键盘（TCL的手感级差！:（ ）

不过为了找原因我倒是废了一番周折，下载和试用了N多的浏览器，也看了很多网上的评论对比文章，现在主流的浏览器主要就是Opera , Firefox, Maxthon , GreenBrowser , MyIE , TheWorld 等，然而在资源的利用率上这些个产品都非常的让人失望，难道就没有一款适合于程序员的胃口的浏览器？！

可喜的是偶发现了GOSURF这款浏览器，在众多的浏览器中它的内存占用率是最低的，而且它的作者似乎在这方面也是煞费苦心，"一味"的强调速度，甚至对于鼠标手这个及其流行的功能的加入也是非常的谨慎，可以看出作者是个很有个性的程序员，值得期待！

如果你和我一样对资源的利用率近乎苛刻，可以考虑这样的一款产品 http://gosurfbrowser.com/?ln=cn

不错的文章
http://www-128.ibm.com/developerworks/cn/java/j-junit4.html

JUnit 是 Java™ 语言事实上的 标准单元测试库。JUnit 4 是该库三年以来最具里程碑意义的一次发布。它的新特性主要是通过采用 Java 5 中的标记（annotation）而不是利用子类、反射或命名机制来识别测试，从而简化测试。在本文中，执着的代码测试人员 Elliotte Harold 以 JUnit 4 为例，详细介绍了如何在自己的工作中使用这个新框架。注意，本文假设读者具有 JUnit 的使用经验。

JUnit 由 Kent Beck 和 Erich Gamma 开发，几乎毫无疑问是迄今所开发的最重要的第三方 Java 库。正如 Martin Fowler 所说，“在软件开发领域，从来就没有如此少的代码起到了如此重要的作用”。JUnit 引导并促进了测试的盛行。由于 JUnit，Java 代码变得更健壮，更可靠，bug 也比以前更少。JUnit（它本身的灵感来自 Smalltalk 的 SUnit）衍生了许多 xUnit 工具，将单元测试的优势应用于各种语言。nUnit (.NET)、pyUnit (Python)、CppUnit (C++)、dUnit (Delphi) 以及其他工具，影响了各种平台和语言上的程序员的测试工作。

然而，JUnit 仅仅是一个工具而已。真正的优势来自于 JUnit 所采用的思想和技术，而不是框架本身。单元测试、测试先行的编程和测试驱动的开发并非都要在 JUnit 中实现，任何比较 GUI 的编程都必须用 Swing 来完成。JUnit 本身的最后一次更新差不多是三年以前了。尽管它被证明比大多数框架更健壮、更持久，但是也发现了 bug；而更重要的是，Java 不断在发展。Java 语言现在支持泛型、枚举、可变长度参数列表和注释，这些特性为可重用的框架设计带来了新的可能。

JUnit 的停滞不前并没有被那些想要废弃它的程序员所打败。挑战者包括 Bill Venners 的 Artima SuiteRunner 以及 Cedric Beust 的 TestNG 等。这些库有一些可圈可点的特性，但是都没有达到 JUnit 的知名度和市场占有份额。它们都没有在诸如 Ant、Maven 或 Eclipse 之类的产品中具有广泛的开箱即用支持。所以 Beck 和 Gamma 着手开发了一个新版本的 JUnit，它利用 Java 5 的新特性（尤其是注释）的优势，使得单元测试比起用最初的 JUnit 来说更加简单。用 Beck 的话来说，“JUnit 4 的主题是通过进一步简化 JUnit，鼓励更多的开发人员编写更多的测试。”JUnit 4 尽管保持了与现有 JUnit 3.8 测试套件的向后兼容，但是它仍然承诺是自 JUnit 1.0 以来 Java 单元测试方面最重大的改进。

注意：该框架的改进是相当前沿的。尽管 JUnit 4 的大轮廓很清晰，但是其细节仍然可以改变。这意味着本文是对 JUnit 4 抢先看，而不是它的最终效果。

http://blog.raylife.com/?p=336

在这个暖暖的午后享受着阳光的温暖的同时，听着CUSCO 的专辑实在是一种享受，我喜欢那种宁静的音乐，因为它带给你的除了纯净还是纯净。。。。

不想被任何的人打扰，城市的喧闹让自己的思想变得复杂，而唯独音乐才能够真正的唤醒你心灵深处的东西，

目前在找工作阶段，参加了一些公司的面试，对于目前的一些公司的面试官我真的要说上两句，比如我去一家"非常著名"（至少在程序界是比较有名气的）的公司去面试，在回答一些无关痛痒的自我介绍后，技术总监突然问我"Struts是如何解决多配置文件的问题的？"，当时就把我给问住了，主要是自己已经很久都没有做项目了，对于Struts也仅仅停留在使用这样的基础上，况且当时接触到的Struts是不支持多配置文件的，所以我只好乱说“将配置文件放在classpath就行了”，显然这样的答案是技术总监不愿意听到的，（想必很多的程序员也会这样认为），可是事情真的就是这样简单吗？

标准答案是：在web.xml中配置ActionServlet的config参数，在经过大脑短暂的思考后我断定我的回答并没有错！

谁说一定要配置这样的参数？那只是ActionServlet的"一厢情愿"，如果有一天Struts不高兴了，将寻找配置文件的策略更改成：从classpath寻找，你认为我说的答案还是错误的吗？

所以我想说这样的面试问题是弱智的，一个人不可能知道所有的一切，对于现在这个社会如此众多的框架产品你怎么可能光靠某个问题就断定一个人的能力呢？

其实如果他可以这样问：你认为配置文件的读取策略可以有多少种?或者如果是你设计Struts你会如何解决多配置文件的问题？这样启发式的询问更会激起面试者的兴趣，难道这些个所谓的技术总监不该反思一下？

当然，不是仅仅一个这样的事件引起了自己点愤怒，而是很多很多的所谓的技术专家的弱智问题，不知道磨灭了多少人的热情！如果你也是遇到了这样的尴尬，索性问他一个自己非常另类的问题－比如"内部类如何访问外部类的对象？"

该死，请不要再问我弱智的问题了

在OSWorkflow中最让人恼火的就是它的接口定义！我会就这些接口的混乱展开一系列的分析，今天先说说Configuration接口

偶继承了它的Configuration接口

import com.company.engine.workflow.store.IWorkFlowStore;
import com.opensymphony.workflow.StoreException;
import com.opensymphony.workflow.config.Configuration;
import com.opensymphony.workflow.spi.WorkflowStore;

public interface IConfiguration extends Configuration
{
 /**
  * @deprecated getIWorkflowStore()
  */
    WorkflowStore getWorkflowStore() throws StoreException;
   
    /**
     * return WorkFlowStore which implements the interface of IWorkFlowStore
     * @return
     * @throws StoreException
     */
    IWorkFlowStore getIWorkflowStore() throws StoreException;
   
}

你可能奇怪我为何要继承它的接口（肯定是Bad smell），原因如下，

IWorkFlowStore 接口定义

import com.opensymphony.workflow.StoreException;
import com.opensymphony.workflow.spi.Step;
import com.opensymphony.workflow.spi.WorkflowEntry;
import com.opensymphony.workflow.spi.WorkflowStore;

public interface IWorkFlowStore extends WorkflowStore
{
 
 public Step createCurrentStep(WorkflowEntry _entry , Step _step) throws StoreException;

}

WorkflowStore接口定义

    /**
     * Persists a step with the given parameters.
     *
     * @param entryId The workflow instance id.
     * @param stepId the ID of the workflow step associated with this new
     *               Step (not to be confused with the step primary key)
     * @param owner the owner of the step
     * @param startDate the start date of the step
     * @param status the status of the step
     * @param previousIds the previous step IDs
     * @return a representation of the workflow step persisted
     */
    public Step createCurrentStep(long entryId, int stepId, String owner, Date startDate, Date dueDate, String status, long[] previousIds) throws StoreException;

看到了吧？

其实我只是希望在createCurrentStep时按照OO的方法执行，而不是传递那些"Bad Smell"的参数，而OSWorkflow中的WorkflowStore是需要Configuration来获取的，此时为了增加一个看似合理的方法，需要分别继承Configuration与WorkflowStore；这还没有完，你需要实现一个Configuration实现！！

import com.company.engine.workflow.store.IWorkFlowStore;
import com.opensymphony.workflow.StoreException;
import com.opensymphony.workflow.config.DefaultConfiguration;
import com.opensymphony.workflow.spi.WorkflowStore;

public class DefaultIConfiguration extends DefaultConfiguration implements IConfiguration
{
 
    public static DefaultIConfiguration INSTANCE = new DefaultIConfiguration();
    private transient IWorkFlowStore store = null;

 /**
  * @deprecated getIWorkflowStore()
  */
 public WorkflowStore getWorkflowStore() throws StoreException
 {
  return null;
 }

 public IWorkFlowStore getIWorkflowStore() throws StoreException
 {
  if (store == null)
  {
   String clazz = getPersistence();

   try
   {
    store = (IWorkFlowStore) Class.forName(clazz).newInstance();
   }
   catch (Exception ex)
   {
    throw new StoreException("Error creating store", ex);
   }

   store.init(getPersistenceArgs());
  }

  return store;
 }

}

总结

1。OSWorkflow与WorkflowStore接口的关系比较的微妙，它需要借助于Configuration接口的实现来获取到实际的WorkflowStore对象。

2。由于这样的一种微妙关系，对WorkflowStore接口的扩展必将连带着需要扩展Configuration接口，而产生这样的"果冻效应"的罪魁祸首就是由于WorkflowStore接口与Configuration接口耦合的太紧。

3。OSWorkflow并没有很好的遵守OO的设计规则，尤其在它的参数传递上，非常的差！