非也

国内开源工作流Fire Workflow1.0发布啦！！重新整理了文档、重写了和文档结合使用的demo。
文档：《FireWorkflow工作流原理、设计和应用》
更多资料在官方论坛：
Fire workflow 论坛

Fireflow终于发布啦。虽然离工程应用还有一段距离，但是我还是想放出来让大家看看，听听大家的意见和建议。
Fireflow的特点是模型和engine理论严密，因此可以在设计器中模拟流程的执行。
另外Fireflow的系统设计也还可以的~_^

文档还很欠缺，现在写的都是熬夜熬出来的，错漏之处难免，大家将就一下吧。

如果你发现了问题：请你告诉我一下。

下载地址：[url]http://code.google.com/p/fireflow/[/url]

今天研究发现IE 不能够利用已经缓存在客户端的数据岛数据，对HTC的混存也会发送多余的IF Modified请求，严重影响性能。在微软的网站上有这些Bug的说明，但是好像没有什么好的解决方法。

如果把Fireflow engin当作一个黑箱子，那么Fireflow engine需要关注如下几个方面的接口。

1、客户代码调用engine的接口（启动流程实例，签收任务，完成任务等等）

2、engine与用户管理系统的接口

3、engine与业务表单的接口

4、engine调用外部系统（engine调用外部代码）

5、engine与数据存储子系统的接口（engine与应用系统存储层接口），以及事务的一致性。

6、工作流数据与业务数据之间的接口



如果进一步打开这个“黑箱子”，Fireflow Engine还需要考虑如下问题

1、内核的实现，以及内核与Engine的其它逻辑的交互关系

2..

Fireflow 设计器,Model,Kenel已经初具雏形。
其中Model子系统完成流程定义语言的静态建模，Fireflow流程定义语言（fpdl）是在WfMC的xpdl的基础上进行简化和改进。
kenel子系统是工作流网的执行机，工作流网是一个具有特定约束的Petri Net，Fireflow工作流网具有数学上的严密性和可测试性，可以实现所有的工作流模式。

    应用工作流也有5年多时间了，曾经也写过一个产品。我感觉到目前为止，大多数工作流产品存在如下不足。
    1、工作流理论在数学上存在缺陷：
    WfMC虽然定义了一套复杂的xpdl语言，但是xpdl没有仅仅从业务逻辑的层次描述了一个流程，所以不具备数学的严密性。xpdl语言不能很好解决“工作流网”中的汇聚逻辑，对“冲撞、流程不可达等错误”也不能检测。
    著名的工作流著作《工作流管理——模型方法和系统》中的定义的“工作流网”表达方法也有漏洞。

 &nbs..

在软件开发项目组中，沟通能力、团队精神具体指什么？

沟通能力应该首先是指和同事讨论项目问题、探讨解决方法、确定技术方案的能力。即业务方面的交流能力。

团队精神在业务方面是指积极主动地（必要的情况下创造性地）完成工作，尽可能高地提高自身产出物的质量，不要因为自己的原因使得团队的产出的质量和工期受影响

沟通能力和团队精神另一个方面是指和同事相处的能力，这种相处能力里目的在于维护团队的凝聚力，提升成员之间的相互信任，相互支持；从而大大提高团该队的战斗力。

我觉得如下项目成员一定要清除掉
1、因为工作..

很早以前，大概是02年，我开始关注（不过没有深入研究）openoffice。我觉得openoffice最大的特点是它的文档格式。我认为openoffice的xml格式文档恰好能解决我们目前遇到的将桌面office集成到MIS系统的难题。

目前ODF已经成为标准，而且国内的office厂商也推出了和ODF兼容的国标UOF。所以我觉得现在是时机将桌面office与企业MIS系统集成了。

这种集成应该包括数据的集成和操作界面的集成。希望我们以后不要再通过桌面office起草文档，然后用邮件系统发送出去；收件人把附件另存为本地文件，然后编辑，然后再。。。。

集成之后的图景..

这是java.sun.com网站上的一张关于JDK构成的图片说明。其中每一个方框（例如AWT,String,IDL,JDBC...）表示JDK的一个“技术领域”。

不知道SUN JDK，IBM JDK，BEA JRocket是否在每个领域都遵守相同的规范或者接口？请各位大虾指点一下。

我试验了一下，IBM 的Webphere 5.x,6.x移植到Sun的对应的JDK，启动不成功。

我给初学者写的一个简单的培训PPT，澄清几个基本概念(J2EE，J2SE，J2ME，JDK，JRE...)

理解不正确指出请各位大侠多指教。

    早上一打开CSDN，又看到某款所谓的“业务开发平台”在打广告。我也不想看他到底是什么回事。反正我的结论是：
   
    业务开发平台？狗屁！
   
    免编程业务开发平台？极臭之狗屁！！

    我们总是把宝贵的脑筋花在这个类似“永动机”的所谓的业务平台上。问题是项目的总体成本并不是由开发（编码）决定。相反，这种所谓的开发平台总是影响我们的系统的可维护性，移植性，和扩展性；也常常严重影响性能。“业务开发平台”根本..

   用过EJB2.x的人估计对EJB带来的痛苦记忆犹新。一大堆的接口、一大堆的规定、一大堆的配置，痛苦不堪的调试……。因此，“我们是否需要EJB2”这个答案还是比较显然，那就是我们绝大多数系统不需要，除非你的系统真的是分布式计算，迫不得已需要用EJB2。

   现在EJB3已经出炉了，开发的复杂度确实大大地减少，已经和编写普通Javabean无异，部署也非常方便。那么我们的系统是否需要采用EJB3呢？

   我想用另一个问题来回答这个问题。那就是：我们要EJB3做什么？
  
   通常EJB能..

内容见附件.

《需求说明书》是需求阶段最关键的产出物，我们公司测试部的同事常常抱怨，有的项目的需求说明书看到末尾还是不清楚系统要做什么，无法写出测试用例。我想我们很多人，尤其是工作经验不多的人，对需求说明书要写些什么东西也是糊里糊涂的，即使能够从RUP的教材上搬出来一些名词，也往往不理解其中的内涵。我把我的经验写下来，放在博客上，一方面自我总结，另一方面，希望和大家讨论，共同提高。
 
以前我们学过各种各样的软件工程理论以及具体的操作方法，我也不记得这些书籍或者资料里面是如何讲解需求说明书的写法的。可能是..

    我们常常会听到下面的一些论调。

        30岁以上还在编码的人是没有什么出息的。
        做技术的到了一定的阶段一定要转向做管理。
        做到了技术经理以后就不用编码了，这些工作交给“下面”的人去做。

    在我们公司，这种无知的见解很流行。所以常常是外行领导内行，垃圾领导专家。

    什么是技术？
    我觉得技术当然包括编码；更重..

最近一直在思考Web应用系统的可用性问题。“可用性”对于一个系统非常重要，但是我们已经听的很多了，麻木了，很少人深入研究（至少我们公司是这样）；做系统的时候也很少去考虑。
 
我觉得系统可用性应该包括如下方面：

1、系统稳定
2、系统性能较好，反应迅速
3、界面布局合理，提示、导航简单清晰
4、界面交互性强
我们很多时候关注第1，第2点；当然仅仅这两点已经把很多项目搞得焦头烂额了。这两个可用性问题与系统“后台”设计有很大关系，此处暂且不论。
 
第3第4点也是非常重要，我们却常常轻忽；总是以“..

第一章： 介绍
（version 10, 由 Carlavmott 于2006-10-20日更新）
这一部分是你阅读本手册的基础。你或许认为“我对JavaScript和Web开发已经很熟悉了，可以略过本章”，但是阅读本章后，你可能会发现你知之甚少还需要加强基础知识。
当我们向用户介绍DoJo的时候，我们会碰到两个问题。有一种用户具有丰富的动态网页(DHTML)开发经验，对系统工作的机理具有充分的理解，知道JavaScript能做什么不能做什么。针对这种用户，很难使他们确信Dojo能够对他们有帮助；相反，对于这个领域的初学者，则更容易接受Dojo。但是，初学者的问题在于..

这几天一直被换工作的事情烦心（同一个公司，换到不同的部门），正副部门经理极力挽留，但是我想了想还是换换。做开发作了6年了，有点累；另外觉得自己的技术系统性还不够，新部门的工作应该会轻松一些，正好趁这个机会整理一下自己的知识。
 
工作了这么久，成天都在和电脑打交道，越来越觉得思维变得狭隘了，生活也机械化了，老婆总是批评我没有生活情趣。所以除了整理知识，还想整理一下…………，怎么描述呢，整理一下自己吧。利用这个时间，放松一下心情，多交些朋友，多涨些见识。
 
我发现自己以前积累知识的习惯..