2008年4月11日
这方面的文章网络上一搜一大堆。偶也不引用了。
偶的感觉是python的安装和组件安装乱七八糟。ruby的安装和插件安装感觉比较爽。其理念是学习linux的port和apt的包管理思路。
昨天准备离职了。
其实在这家公司里面，项目leader对我很不错，时间也是比较宽松的。给了我很多的机会学习。甚至曾经我有整整一个星期的时间去完整的学习ruby。对此我还是非常感激的。不过因为项目的原因以及各种管理上的不如意，我感觉自己始终不开心。
索性这次终于解放，于是我想先静下心来，思考一下人生未来的路。顺便学习一下我所喜爱的ruby和python。上次学习ruby已经是几个月以前的事情了，学完以后基本上没有得到什么使用的机会到现在基本上忘记了。这次一并将python也学了，并比较列出。
几乎所有的语言，都包含以下几个部分
1，数据类型 ————被处理的
一般包括数字，字符串，可能还包括布尔类型；复杂数据类型；对oo的语言还要包括对象等。
2，对数据的处理 ————语法部分，
a，操作符和表达式
b，条件判断语句
c，循环语句
d，跳转语句
f，异常处理
3，代码的组织
a，文件的组织
b，函数
c，对象
4，类库
a，标准输出入库
b，文件库
等
以上前三个部分，是一个语言基础的部分。但是对一个语言深入的了解，还必须结合这个语言的背景，哲学理念，才可以达到比较深刻的地步。是以我们对python和ruby的学习将从这个地方开始。
我曾是个技术粉丝
但是多年的开发经验，使得我对技术的本质认识的越来越清楚。至少对企业软件开发人员来说，纯粹的技术coding是没有多少价值的。如同建筑行业一样，真正有价值的东西在设计阶段已经完成了。
和传统建筑行业开发不同，软件开发行业不光是技术设计，还包括业务的设计。业务和技术掺杂在一起，构成了软件开发的复杂性。
在业务上，在技术上，尤其是在技术和业务的鸿沟之间，存在了太多太多因素。使得我们本来对相对简单的软件开发不敢抱有那么大的乐观。更何况真正一个成功的项目还需要市场，客户等等各个方面。
作为一个软件开发人员，真的应该放弃软件自大的心态，客观的去看待软件开发技术在整个软件开发工程中的位置和地位。以一种推动企业发展，推动项目发展和成功的心态和目的去看待整个项目。就明白了软件开发的真正意义和任务。也就能更好的完成自己的工作，甚至可以改变项目的成败。
所以成败不由技术，成败由你我的视野和努力。
最近公司项目经理派我研究工作流并考虑在项目中使用。很有一些心得。工作流应用我将之分为狭义工作流和广义工作流。对狭义工作流而言，你可以将之理解为在工作流设计器里画画节点以及方向箭头，设置好就节点数据，动作就差不多了。（具体可以参见jbpm的websale这个demo)。
广义的工作流是对服务之间的整合。核心问题是业务节点和工作流节点之间的映射，以及业务数据和工作流数据之间的映射，和普通工作流一样还有流程判断等等服务。实现了这些，各个业务模块之间的数据就可以通过服务，以定好的方式（进行方向控制和格式转化）在各个节点之间流通，达到了服务整合的目的。
IBM为ESB定义了四个必备的功能:“路由器”——根据信息内容，在不同应用和服务之间进行信息传输和路由;“转换器”——进行应用之间的通信协议转换;“翻译机”——进行应用之间的消息格式转换;“收发室”——处理来自不同渠道的业务事件(同步传输，异步传输，发布/订阅等方式)。
其中“路由器”和“收发室”都是针对服务的重用而设计的，而“转换器”和“翻译机”则专门用来解决异构的通信问题。
针对重用和异构这两个难题，倪晓兵认为ESB提供了两个核心的功能，服务的管理和数据的转换。
我们DEC项目的目标就是建立一个全能服务仓库（暂时我在DEC设计人员zy哪里得到的信息），而服务之间如何路由，如何转换，语义的协调都没有考虑，而后者却是成败的关键。
最关键的语义翻译这一点，就现在的技术上来说还不能做到（需要很高的机器智能才能达到使得不同的系统的业务词汇可以正确的映射，更何况是在所有的系统之间进行映射，同时应用在企业级的应用环境中）
也许真的有这样的幻想，但是真的能够做到这一步么？我深深的怀疑。就目前的技术手段，如果要达到数据映射的高度正确性，必须由人不同系统之间需要协调的数据进行语义确认方能进行有效的映射。
当考虑到还必须做到ESB系统对其接入的所有的服务数据的语义都这样做时。我怀疑真的需要做到协调所有的服务么？
也许ESB的应用范围就是在公司内部或者有限范围内的整合目标明确的业务节点之间业务的整合。