传统的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很容易。不过事情一旦很容易，于工业上看，就不值钱了；于学术上看，就没啥好研究的了。所以，重视各种细节吧。

Scrum的运行方式又很多种，很多公司应用起来也会有些自己的改变，一个简单的Scrum Meeting包含3个要点：

1. 从上一次Scrum到现在你做了什么
2. 从现在到下一次Scrum你要做什么
3. 有什么问题无法解决的

一般如果大家坐在一起，那么每个人都说一下，可能也需要比较长的时间，不适合每天进行，但是如果通过一个多人协同交流系统(比如IRC)来进行，那 么就会迅速很多，多人可以同时发言，发言之后可以查看其他人的发言，效率大幅度提高。一般20人团队，只要没有重大问题，那么3到5分钟的时间就可以进行 完毕，非常适合在每天进行。那么有人会问，这样的几分钟的一个小流程能解决什么问题呢？对于没有亲身经历的人可能不太容易理解。可以这样说，每天的这短短 几分钟时间就能是每天的8小时的工作效率提高一大步的。为什么这样说呢，因为，虽然每个人只有3句发言，但是这3句话要说明，上一个工作周期都作了什么， 下一个工作周期要做什么，因为每天进行，所以大家很容易回忆起来你上次的报告是怎么说得，所以也就很容易的印证，你这次报告的已完成工作跟上次的要进行工 作是否匹配，也很容易知道，你的每个工作周期的工作量是否合适，我想每个人都一样，如果你自己都觉得你的这个工作周期的工作量不太够的话，那么你也一定会 认为别人都这样觉得，这是一个非常强烈的心里暗示，如果你这个工作周期的工作非常繁重，完成的状况非常好，那么你也就会非常的理直气壮了。所以因为每天的 这短短的几分钟处使你在整个工作周期都要集中经历，提高工作效率，这样每天的工作完成情况非常良好，那么也就不会产生无故的加班行为，那样你就有更多的个 人时间来进行你的个人事务，所以大家的工作效率都会非常的高，企业的整个项目进程也会相应的非常高效。这样企业也就可以赚取更多的利润，也就可以回报给员 工更多的利益。

所以我非常的不理解有些老板特别的喜欢看到员工坐在办公桌前超时工作(加班)，感觉他好像榨取了更多的员工的价值一样。可是这样带来的必然是正常的 工作时间的效率低下，所以我对某些自以为很了不起的，标榜着自己的加班文化的企业很是不屑，明明可以在短时间之内完成的工作也要拖到下班再加班，可能还不 能完成。这样有什么意义呢。曾经有人跟我说过，在他的公司，如果你工作效率很高，反而得不到老板的赏识，因为老板认为你做的快说明工作没有难度，只有做得 慢了才说明难度大，才会受到重视，真不知道这是什么逻辑。

所以轻量级的迭代流程就显得非常重要了，可以在不浪费大量会议时间的情况下，对过往的流程进行快速的复查，发现问题，找到解决的办法。是提高工作效率的非常有效的手段。

就我个人而言，我是非常的反感加班的，即便有加班费我也宁愿准时回家吃饭、睡觉。

所以每天五分钟的scrum带给你的是什么呢？是高效的工作效率，更多的和家人在一起的时间。对企业来说，就是高效的完成项目进度，员工更快乐的工作，单位时间创造更多的价值。

Scrum还有其他的一些特征，比如30天一个迭代周期的“冲刺”，小于7人的小团队，以及”站着开会“的要求（为了保证Scrum meeting在15分钟内结束）。可以参考这一篇短文”什么是Scrum“，或者看看这本电子书“Scrum Checklists中文版”。

其实不止是软件项目管理，我觉得做research也可以采用类似的思路。 以前听人说过外国某两个教授效率极高，paper出的很快，很向往；问及原因，很简单：因为他们两人天天坐在一起讨论。问题是，为什么学校里每周见面的讨论班制度运作的效率不高呢？团队不够小是一个原因，导师的时间有限也是一个原因。但根据我的经验，每周跟导师见一次面很容易导致平时工作不是特别紧张，每次讨论之前一天效率很高，讨论过后效率又会降低。我猜想如果用Scrum这种短会的策略，是否能提高效率呢？比如，每两天在MSN上讨论一次，汇报内容不超过两句话？

比较容易想到的是“钢笔必须能写字，写出的笔划要连贯”。但是再考虑一下，其实还有很多问题，比如：

• 能在不同的纸上写吗？能在墙上写吗？笔尖朝上，倒着拿还能写出字吗？
• 能在不同的环境下写吗？水里？沙漠？低温？太空？
• 笔的形状是否适合手握？（想像一件用砂纸做的T恤……）
• 要用多大的力气才能写出字来？
• 长期放着不用，墨水会不会堵住？
• 加一次墨水能用多长时间？
• 笔上的标签有没有错别字？是否考虑了globalization，不同国家、不同文化？logo会不会让某种人反感？
• 笔容易折断吗？如果折断了，飞出来的东西会不会伤到人？
• 把笔放到嘴里咬会不会有危险？小孩总会乱吃东西。
• ……

其实还能写出更多条测试要求来。总之，测试还是很有学问的。Quality永远都比Quantity重要，安装到用户机器上的软件宁愿少一些feature，也要保证质量。

另外，除了著名的Pentium浮点运算错误，NASA的航天器单位换算出错等经典案例外，在课上又了解到一条：SQL Slammer病毒，2002年的一个SQL Server漏洞导致世界上大部分Internet都挂了，连ATM都取不出钱了。（因为中国当时在过春节，所以没受多大影响。）

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呢？如“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语言标准，本体之本体之类的东西吧。

但是！初学者是不管你的系统有多么可扩展的，比如我第一次下载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把不同的组件连接起来。总而言之，组件技术还是非常实用的。

一个例子：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(zz)
发信站: 北大未名站 (2005年01月26日19:58:33 星期三), 转信

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

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

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

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

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