赵翔鹏的Blog Xiangpeng's Thinkpad

由无数细节组成的系统

计算机科学总是讲abstraction。这是源自数学的思维。formal methods可以说把这个发挥到了极致。但实际系统并不是这样。不要说构建Windows这样的庞然大物，就只是要写一个实用的小软件，就会遇到无数的细节。performance，security，scalability，debugging……除了functionality之外，有无数的事情要考虑。

传统的formal methods注重functionality也没错，因为在某些情形下（比如算法领域）functionality的正确性已经够难了。但这却不是软件工程中的主要问题。

我们能做的，就是尽量挣扎着把细节包装起来。比如，工程师做出一个个框架，分出若干个层次。框架可以帮助我们，但框架并不能解决一切问题，因为好的程序员必须了解各种细节。最近读一个基于ATL/WTL的真正的product code，发现这一年来看的n本书都没白看。比如，不懂C++内存布局，不懂各种calling convention，compiler的差异，就不能理解COM的设计（btw，强烈推荐《COM本质论》的第一章）。

researcher也自有办法。因为很多细节是正交的。在TASE'09上听到Zhong Shao做的invited talk，分不同的aspect去验证汇编代码的不同性质，这个是正确的思路，而且我觉得可以做更多的东西出来。以前做business process的security验证，这个也可以归到这个思路，不过high level的东西比较虚，做起来虽然不难但并不容易很深入。而Shao对汇编和机器本身建模，比如对interrupt handling建模，这个就很有新意，且竞争者较少——很多数学系出身做formal methods的人，都不太懂系统底层。

是的，跟C++和汇编相比，写Java很容易。不过事情一旦很容易，于工业上看，就不值钱了；于学术上看，就没啥好研究的了。所以，重视各种细节吧。

初学SOA总结

昨天才意识到，以前虽然看了不少web service的东西，却没有认真的看过SOA，至多是了解一些报纸杂志上的吹嘘而已。今天花了半天时间Google了一下SOA，写个小总结如下。

SOA是一种松散的体系架构。跟管道的、分层的、黑板式的体系结构相比，SOA更松散，它的模块（组件）只是一些service，然后可以任意的组合拼接
以获得新功能来满足新需求，如用BPEL。我觉得这更接近component的核心思想，即只要接口相符，组件是可以任意拼接的；因此SOA是非常
flexible的，具有更好的复用性和伸缩性。

不用说，flexibility是非常好的，“把公司转型为随需应变企业”，
满足各种不同需求，听起来多么诱惑啊～～但正因SOA非常flexible，它也增加了service的接口设计和组合的难度——不像管道结构在设计时只
要考虑两个组件之间怎么连接就可以了，在设计service时必需仔细考虑通用性，可复用性，等等。但跟可获得的好处相比起来，我想这个设计的代价就微不
足道了。JavaOne2004有篇文章Using SOA and J2EE to Ease Integration and Customization While Reducing Overall Implementation and Customization Costs，看题目就知道，SOA其实已经是企业实现customization的最捷径了。

SOA的另一个意义是保护已有投资，因为service只是对原有系统的封装，所以可以降低成本，但也同样可以起到消除信息孤岛和实现EAI(enterprise application integration)的作用。我觉得企业实现“随需应变”是SOA最终的目标，而EAI是实现目标的第一步。根据目前国内现状，我想EAI就已经很能满足大部分传统企业的需要了。

在Internet /
Intranet环境下，SOA比其他架构更适合：因为服务是基于XML的，从而解决了格式不兼容的问题；服务一般是无状态的，而且可以通过服务发现的形
式寻找合适的服务，从而可以降低系统的耦合度（提高可伸缩性），降低出错概率（因为调用都是异步的）；……暂时只想到这几点，肯定还有别的优缺点值得讨论
吧。

问题：

服务是无状态的，但是有些时候组件里是有protocol，有状态的，比如哲学家进餐问题。BPEL，WS-CDL是否可以完全解决这个问题？或者说，为了保证基于Web的服务的易维护和易复用，我们是否必需放弃“状态”这一很有用的特征？

企业是否应该把服务发布给外部？发布服务会不会削弱企业的竞争力？卖书的公司把查询书价的service暴露出来之后，就造就了douban这样的网站，
从而导致卖书的公司要给douban交广告费。这要求不同公司之间的分工更细，单个公司必需把核心竞争力的东西做的更强才行。

自动服务发现真的能行吗？本质上，给定一个需求，寻找满足需求的组件是一个精化关系判定，这要求对需求（契约）的精确描述及实现自动的精化判定，而这二者都是非常难以做到的。

据说SOA可以更容易管理，但是现有的WS-Security, WS-Policy还是比较原始的，未必能满足需求。这方面倒是可以继续做一些研究。

最后，为什么在国内wikipedia还不能访问？不是说解封了吗？郁闷啊……

tag的tag?

现在的tag包含了多种信息。以delicious为例，很多人在收藏一个网页时，会标记article, blog, programming,
ruby, ajax, tutorial等等。这里的几个tag有些是关于内容的，如ruby, ajax,
tutorial；有些是关于类别的，如article，blog。但tag本身只是一个单词而已，没有任何信息来描述tag。

那么，能不能给tag加上tag呢？如“content”，“category”等等。其实收藏者的名字就是一个带tag的tag；系统会自动把这个信息作特殊的处理。

其实我这个想法跟RDF也差不多。在semantic web中，“苹果是红色的”可以表示为apple ---(color)---> red，这里的color表示red之于apple的关系，亦即tag之tag。

一直以来人们都说semantic web太难实现，roadmap太大之类。但是我们仅仅借用其中的一个很弱的概念，如tag，就已经掀起了一场“web2.0”风暴。所以说，机会还是很多的……

Update:
ontology以前的想法是把什么都标准化，由某个标准组织制订一套ontology大家用。但这显然是不现实的，因为领域太多了，更新的速度也太快
了。我想标准组织能做的和要做的就是一层层的meta data下去之后的最底层的工作，如RDF语言标准，本体之本体之类的东西吧。

软件开发：怎样满足所有人的需求

想写出完美的软件，满足所有人的需求？好像不可能……因为每个人的需求都是不同的。但是用过firefox，emacs，eclipse之后，忽然觉得这也是可以部分做到的。解决方法就是可定制化，插件化。

但是！初学者是不管你的系统有多么可扩展的，比如我第一次下载firfox时，根本不知道还可以装“extension"，还以为就是一个模仿IE的产品
呢。第一次用oracle之类注重功能而不考虑入门用户上手速度的软件，也是有点痛苦的。相比之下，vs.net的特色就是入门快，虽然用到细节之处就开
始发现问题多多……

不妨总结一下：1. beginner希望界面简单，容易上手；2. power user希望更多的功能，更多的插件。

按照这个原则，emacs违反了1. 这也解释了为什么网上有很多“预配置”好的emacs，比如easyemacs，"latex专用emacs"等等。

同样按照这个原则，为什么windows“好用”？因为它有大量的application可以用。对第一次使用linux的一般用户而言，常见的问题是：
有qq吗？有word吗？（什么？只有这么难看的gaim？只有这么难用的open
office？）还好，linux也在改进。windows以前的缺陷是高端服务器应用太差，不过，windows也在改进嘛～

如果windows和linux都有无数的application可以用，那时候才要看谁的内核更强了……在此之前，作这个比较常常是没有意义的。

Windows的成功除了因为有大量的application可以用外，m$开发了很多成功的典型应用也是很重要的，如office等。相比之下symbian的讨厌之处在于nokia总等着第三
方来写应用，默认的录像机程序竟然设成只能录1分钟，还只能录图像没有声音，吓走了很多初级用户。ipod，mac的成功也在于apple把最常用的功能都做的非常好用。

并不是每个人都有能力安装配置新的插件、应用；即使有能力，也未必有时间。预配置也是很重要的，不仅有利于吸引初级用户，也有利于高级用户迅速理解该系统
的能力究竟如何。为什么我们需要linux发行版，而不是下载所有的linux源代码自己编译？因此，可定制性和易用性的平衡一定要把握好，才能吸引更多的用户。（其实我也承认，完美的软件是不存在的……）

Update:
unix下的命令行小工具也是一种比较好的满足各种不同需求的方式，用户只要用脚本语言把他们连接起来就可以了。vba也是满足各种特殊定制需求的一个解
决办法。从这个意义上说，web service，soa也是一个很好的可扩展架构，用bpel就可以把web
service粘在一起，满足一种需求。再前卫一点的是http://www.ning.com。

Update:
想了想，其实插件就是一种组件，准确的说插件就是基于黑板体系结构的组件，插件之间一般是没有互相的交互的。相比之下命令行工具、web
service就灵活得多，用户可以自己写一个connector把不同的组件连接起来。总而言之，组件技术还是非常实用的。

解释计算机体系结构的搞笑图片

图片来自http://www.xtrj.org/，这其实是个不错的网站，虽然界面土了一点。

什么是MOF(Meta Object Facility)

UML是用于表示模型的语言。UML Metamodel是表示UML的语言。那什么是表示UML Metamodel的语言？就是MOF了。

一个例子：XMI(XML Metadata Interchange) （天哪，这些缩写就够难理解了，没想到这些缩写的全称也还是让人无法理解……）

人们因为讨厌太多不同的语言细节，想统一的表达对模型的看法，所以使用UML作为交流、沟通的工具。于是产生了很多UML工具。于是，出现了一个新问题：
不同的UML工具保存的UML文件格式各不相同，比如Rose的格式跟Magic
Draw就不同。何不再"U"一下，把这些格式统一呢？所以就有了XMI这个统一的描述UML的XML规范。XMI is a way to save
UML models in XML, but more general than that. 反过来想一想，UML can be
regarded as an XML DTD to which UML models must conform。

model, meta-model, meta-meta model, meta-meta-meta model... 还好，通过xml schema，XML算是自定义的，这样就不会再出现下一层"meta"了！

XMI总结：XMI是一个基于MOF的语言。XMI shows how to save any MOF-based metamodel in XML.

发现一个有趣的事，我喜欢在blog上写些我不熟悉的东西；比如其实没学几天的B方法，还不太会用的pvs，刚刚接触不久的javascript，
emacs……其实，当我写下“什么是XXX”作为blog标题的时候，我其实是在说“我昨天还不懂XXX，今天看了几篇文章，懂了一点了”。

但是我真正熟稔于心的东西，像Model
checking，像好歹学过一个学期的Z，反而懒得写成blog了。。。因为很熟悉，反倒觉得写下来也只是重复，而起不到总结提高的效果。也因而失去了交流的机会……以后要稍微改变一下～

Famous software theory in a lab(转载)

今天在未名上看到的好文，经典。很郁闷的发现我也快变成这样了。中国的科研啊……

标  题: famous software theory in a lab(zz)
发信站: 北大未名站 (2005年01月26日19:58:33 星期三), 转信

假设有个人口渴了想找个东西喝水，于是软件工程师去跟他接触，得出结论，他需
要做一个容器盛水喝。“需要一个可以装水来喝的容器”，就是需求。需求是可变
的，因为有的无厘头工程师会让这人直接对着水龙头喝。

平白无故要弄个容器让人无所适从，于是google，发现商朝有人做过鼎，后来唐朝
又有人造过夜光杯……这些是大牛的作品，还留下了一些竹简纸帛让人瞻仰，我们
不能搞这么复杂，再加上以前实验室还做过饭碗，技术多少有点相通，于是发现做
个杯子似乎不是那么难，只要加个把就OK了。这些找来的资料后来被放到论文里，
变成了“研究背景”。附加的那个把，就是“创新点”。

啊，做个杯子。功能很简单，结果一开始做出的是个带把的饭碗，老板们称之为“
原型系统”。

带把饭碗的好处是用它也基本上能喝水了，但是喝的时候总感觉不爽，不是饭碗里
有瑕疵就是把子粘得不牢靠，于是老板又吆喝人开始改造这个饭碗，几个研究生拿
着很先进的锉子和高档胶水对饭碗修修补补。总有人一不小心把饭碗锉了一个洞出
来，漏水没关系，马上会有胶水加补丁贴上去，然后再交给实验室不善于锉杯子的
师妹们来装水喝做测试，喝起来水里一股胶水味……于是又开始添加清新剂，结果
又导致蚂蚁喜欢上了这个杯子……虽然总会有源源不断的问题冒出来，但是毕竟每
，证明我们的工作没有白费。

于是饭碗最后变成了一个打满补丁的杯子，外面裹上一层花衣裳就可以拿出去给那
个人喝水了，不幸的是，那个人基本上已经快要渴死了。这无外乎是每个项目的结
局，或者运气更好一点，在那个人渴死之前，杯子送到了他手里，他连水带蚂蚁一
起喝了下去，这时候软件工程师开始想：或许这个时候应该来一次”refactor“了
，但也仅仅是想一想而已，谁也不会去做。