See the World from a Bit

冷眼看世事，热屁向粪青

2006-10-29T12:27:00.001+08:00

1，评公务员长工资现象。我不是官员，也不是公务员，但是我觉得，在任何一个社会里，官员过体面的生活都是天经地义的吧。一个过着体面生活的官员，和一个薪奉菲薄的官员，那一个更能专心公事呢？

2，台湾问题。我不是台湾人，也和台湾没有任何关系，只是不知道为什么有这么多人叫嚣着打台湾，欺软怕硬，这大概也是阿Q精神之一。假如台湾和日本一样强大的话，他们还会这样叫嚣吗？恐怕要改为“抵制台货”了吧。

3，股市。任何一个人进入股市，都是为了赚钱。做长线就是为了支援国家，为了国民经济吗？既然大家都是为了赚钱，那就不应该骂人家投机，应该骂的是那些制定规则和管理市场的人，是那些放过应该惩罚的人的人。

冷眼看世事，热屁向粪青

2006-10-29T12:27:00.000+08:00

CSDN关注的焦点

2006-10-14T23:11:00.000+08:00

CSDN是我经常上的一个网站，毕竟是国内唯一一个专注于IT业与IT从业者的网站。经过多年的接触，我发现CSDN的发展轨迹和《南方周末》是一样的，越来越水，越来越官样化了。以下是鄙人总结出来的CSDN的关注焦点：

第一，是各IT公司的HR丑闻，以及各种HR评论，这是最上镜新闻，跟贴也最多。这种新闻大家都很关注，贴出来本无可厚非，无奈评论无深度，一般是公司声明，当事人控诉，和大众评论。大众评论就不要说了，搞不清中国为什么有这么多头脑简单情绪激动的爱国者。

各个大型IT公司的市场活动，这类是第二火的消息。这类新闻基本属于各大公司的免费广告，告诉人们该公司新产品的一些特性，而且是极其夸张性的描述。

排名第三的，是各个“名人”来华访问的专题，这个本也无可厚非，但不幸的也是报道无深度。想把一个大师级人物最有深度的言论挖出来，唯一的办法是找个和他颇为旗鼓相当的人来一番对话，无奈蜀中无大将，此地没有出类拔萃的世界级技术人才。

第四，从国外论坛翻译过来的帖子，这个是CSDN为广大中国IT从业者做的唯一有价值的工作。希望能保持较快的跟踪速度和较高的翻译质量。我们也只能期望这点了。

最后是从CSDN blog里摘出来的帖子，不知道为什么，多数是绣花枕头：题目很吸引人，内容不超过200字的居多。举今日的“头条”为例：

题目：IT行业趋势前沿:SOA和开源

目前,最为重要的IT行业趋势的前沿，第一是面向服务的体系结构（SOA），这套不断成熟的企业计算模型能够协助IT行业更为敏捷、高效的应对不断变化的业务需求；第二是开放源软件发展趋势，目前开源软件领域正在以较快的速度成长，并且获得了企业业务层面的广泛认可。

据Gartner预测，到2010年，全球排名前2000强的IT组织将会在其80%的基础设施为主的软件投资中使用开源产品。SOA与开放源软件的优点相结合将会为客户带来巨大的价值，它们不仅可以降低客户的IT成本，同时还能大大提高客户业务的灵活性。

把这样的东西拿来做头条，不知道是不是编辑吃了脏东西了。由于我在CSDN blog上看到的多数不过涂鸦之作，我倒想对那些写blog的大虾们说两句，就当写日记吧，是否也要专心致志花点心思去写？个人功力不可强求，可总要有点专业精神吧。

互联网革命

2006-10-14T21:34:00.000+08:00

我相信Web 2.0会让互联网走出寒冬，春天不远了，但是离盛夏还有一段距离。

理由之一是，我可以亲身感受到互联网和我们个人的生活贴的更近了。这种感受不是来自那些为了获取风险投资商们青睐而挖空心思想出各种小技巧的Web 2.0网站们，而是来自我们在日常生活中为了更加惬意和舒适而求助于Internet的感受。例子如：我不再通过翻烹饪书来学习做饭，Google可以帮我发现一道菜肴的最佳做法。或者，我家的洗衣机坏了，我上到Google，搜到小天鹅驻京办事处的电话，联系到维修师傅，OK。又或，当我要去北京的某个地方办事时，最佳的方法也是借助网络，Google一下公交车行路线，电子地图，等等。这个理由背后的意思在于，我可以容忍查询过程的复杂，也可以容忍电子地图速度的缓慢，令我们离不开网络的根本原因在于网络上的内容：有我们日常生活必备的信息。随着这些信息越积越多，网络也变的越来越必不可少。而技术的提高，仅仅是为我们提供了“锦上添花”的事情。

However，Internet上基础传输技术远不完善，内容也还没有到“极大丰富”的地步，革命尚未成功，同志仍需努力。互联网仍是那么的不可靠，以至于我们使用网上银行的时候总是怀着一种战战兢兢的心情；网络流媒体传输质量仍旧是那么的差，以至于我们只能在现有条件下欣赏低质量的视频短片。从本质上说，我们在今日的Internet上仍旧要以文字和二维图片作为信息的主要载体，这与上个实际的报纸和杂志没有“革命性”的进步。我们可以通过Internet来完成Business上的事情，这也越来越成为一种趋势，但是还未成熟。从这个意义上来看，俺们公司倡导的SOA是一个符合历史和时代潮流的东西。

其实我的研究兴趣，一直在所谓的“企业应用架构”领域徘徊，虽然至今没有亲身参与到一项大型的企业应用实践中去，可以算是“纸上谈兵”吧。从最早的制造业领域的CIMS，MRP/MRPII，到CRM，SCM，以至于现在美国流行的BPM。我能明白这条主线是怎样一步步发展下来的。而今天的SOA，实际上是要为SCM/BPM这些看起来形而上的空中楼阁打造一片坚实的基础。可以想象，如果每个企业都把自己内部外部的信息资源封装成基于Internet的服务，那么以这些服务为基础来构造企业内部的动态业务流程，再把这些流程与企业外部接轨，从而构造出具有社会性的动态供应链，这是多么漂亮的架构！而通过Web 2.0风靡的那些技术可以在这些正经八百的业务流程之外打造人与人沟通的纽带。每个人把他的思想/发现贡献到网络上，交给大家来使用，评判，那时，他的价值真正体现在他的发现和思想是不是真正的为其他人带来好处。这是人类社会的真谛啊！

那时，我们可以尽情享受网络所带来的乐趣了。

SOA Launched...

2006-10-11T21:38:00.000+08:00

10月11日上午，公司举行了SOA Launching活动，照例是大片式的广告宣传片，零食，饮料，蛋糕，和公司一贯的自卖自夸型幻灯片. 有时觉得这东西就跟“三个代表”，“八荣八耻”之类的宣传一样，听着挺好，就是让我等小老百姓摸不着边。当初郭士那执政的时候提出了E-Business，电子商务不幸成为IT界最鼓的泡沫；Sam上台，先是提出了个business on demand，无奈这概念太泛了，不好宣传；于是改成了SOA，终于有了点E-business的遗风.

10月13日下午，听了一下毛新生的经验介绍会。除了钦佩老毛的presentation能力之外，他说的一点令我感触很深，就是不要在IBM这样的大公司里lost yourself。具体说来，不要把个人的兴趣和研究方向完全绑定在公司的发展轨迹上，要为自己刻画出明晰的发展路线，深入研究，并用你的技术洞察力和行业经验去说服公司采用你研究和思考的结果，而不是完全按照公司即定的发展路线走下去。即使你的结果最后被市场投了反对票，也不会认为你在IBM的职业发展带来太大的影响。

Carol Jones谈Web 2.0的文章

2006-10-08T22:44:00.000+08:00

Carol Jones是WPLC 的资深架构师之一，今年晋升为Fellow。05曾经访问过CDL一次，那时被时介绍为Mother of WebSphere Portal；从developer works的文章上可以看出现在她的兴趣已经更多转移到Web 2.0 and Social network上了。从她的blog上，可以发现social network, collabration software方面的一系列文章, and many interesting comments from them...

Activity based computing

For quite a while now we've been working on activity-based Computing. This is about organizing work in terms of the activities that people do, rather than the tools they use. If the focus is on the work instead of the tools, it is possible to make semi-structured work patterns more productive than they currently are. Today we try our best to use team rooms, but we're not always disciplined enough to post everything there. Or, at the other extreme, we all have a lot of stuff scattered throughout our e-mail, on the file system, etc. with no organization at all. Sure, you can use search tools to find it, but it really shouldn't be the case that people have to work so hard at finding and organizing information.

If we expand the discussion beyond "things", it gets even worse when you consider work that involves a formal process or a very structured application. In a lot of transaction systems, the transaction is sometimes just a small part of the work. There might be a signficant amount of preparation that takes place beforehand, involving very loose steps. Think about the last time your department ordered hardware: somebody probably went around collecting up everyone's requirements, maybe in a spreadsheet or on paper, or maybe they wrote a quick-and-dirty application of some kind. Only after this was consolidated did the real ordering take place.
An activity is the collection of materials, communications, and processes that emerge when people work together. Examples might be driving a sales process to close, preparing for an important meeting, or writing a report for a client. At Lotusphere 2006, we show a lot about the Activity Dashboard we're working on, plus many new research projects that have spawned from the main product development work.

Basically what you can do with the Activities Dashboard is post links to things that you're working with. You don't actually need to visit the dashboard to do this, because the service integrates easily with a wide range of applications and tools. For example, while you're in your browser, you can click a bookmarklet to post the page you're currently looking at, into the Activity server. It's a similar story from your Notes client or Word, or other places.
This works because we use very lightweight integration methods. Data flows in and out over standard protocols/markups, with the most important ones being Atom and the Atom Publishing Protocol. Basically this means that you can post anything that has a URL associated with it -- which means just about anything these days. You can extend it to work with your tools, not just the ones we thought of.

I use Activites for work like writing papers, studying emerging technologies, and just plain-old document sharing. It's a nice simple way to share things, and it works beautifully in small groups. We have some activities that involve very large groups as well. Where is this is really going is more ambitious than my simple use cases though. We can take activities and distill patterns out of them, so that pattern is repeatable. A good example might be the steps that you go through when you hire a new employee. These steps are structured, but not necessarily rigidly structured. You need to talk to people, make sure you have funding, interview candidates, process HR paperwork, get equipment, etc. But some of the steps can be done out of order, and the exact details might change from time to time. They are familar enough that you don't need a fancy application to do it, but infrequent enough that you might not remember every step. An activity template is perfect for a situation like that.

Social Bookmarking

Like many other people, I've gotten hooked on social bookmarking, including del.icio.us and an IBM research project called Dogear. If you haven't gotten hooked, it's hard to understand what the attraction is. Basically there are links installed in your IE or Firefox browser, so that as you're reading an interesting web page, you can click "remember this" to save it to the bookmark server. When you save it, you get a chance to assign some tags describing what page is about. There are many other popular tagging systems, such as Flickr. There's nothing earth-shattering about tagging (or some would call it "categorizing"). So why does it work?I think it works because it is so quick and painless, and more importantly, there's a good payoff for your efforts. The payoff is that you can see what links other people saved that match your tags. I've found lots of useful resources this way, plus lots of interesting reading. That's all the incentive I need to stick with it. Sure beats using the browser bookmarks or searching over and over again.

You can also share your links easily, by making a feed available to others.

This tagging idea will prove to be applicable to many other areas, such as organizing documents or email or calendar entries. Today's systems tend to be the informal "folksonomy" type, but tags could be suggested from a corporate taxonomy or some other organizing principle. The key to making them work is to keep the effort low for the user, and to give some reasonable payback for their efforts.

AJAX

Lately a lot of our developers have been examining AJAX and how best to use it. In certain IBM products, we've used AJAX extensively (although it didn't have a name way back then).

AJAX is a technique that is best applied when users have high speed connections and very modern browsers. There are lots of benefits, but also some pitfalls to look out for.

In case you've been under a rock, AJAX stands for Asynchronous JavaScript and XML; it is a description of programming techniques being used in certain rich, highly responsive web applications (like Google Maps), with great success.

Like most things, have a better chance of success if you don't get too carried away. Let's see what the pitfalls are, letter by letter.

If your emphasis is on the J then you might wind up with too much Javascript. Large amounts of code can make pages slow to load, which defeats the whole purpose of using AJAX in the first place. Javascript can also be fragile because of subtle differences among browsers versions and across platforms.

If your emphasis is on the A, then you might have too many asynchronous calls. This changes the stress points on your server, and you'll want to make sure that the latency of these calls doesn't exceed the download time of the data itself. Again, that would defeat the whole purpose of choosing this approach in the first place. If you have only tested with localhost and nearby servers, you could be in trouble when you deploy.

If your emphasis is on the X, then you'll wind up parsing lots of XML, which could be slow.

There are ways to deal with each of these issues, including caching and prefetching data, or downloading Javascript in the background.

Now on the plus side: the clear advantage of AJAX is that you can make the UI very responsive, because much of the page is loaded and operational while more data is being retrieved in the background.

Another advantage is that you can avoid downloading data redundantly, because you aren't loading the whole page again on every user interaction. .

A more subtle advantage is that you could cut memory use in the server side of your application. Traditionally, lots of web applications cache data on the server, because they want the data to be close at hand during the user's entire session. Caching on the server is necessary if the whole page is reloaded many times. But if the data is cached in the browser, then you can change your approach on the server side, and improve the overall scalability of the application.

Google Web Toolkit真的至关重要?

2006-10-03T00:53:00.000+08:00

Google Web Toolkit 已经吸引了全世界无数web程序员的眼球，因为它承诺能够使AJAX Web开发变得简单。但是，它到底有多大的优势?而且，更为重要的是，我们有多需要它呢?

这是一个否认的声音——首先，作为一个开发人员和框架架构师，我发现Google Web Toolkit (GWT)非常得迷人。它是那些非常有才能的人才能做出来的相当棒的软件。但是，问题是:在企业软件开发的领域中，这种吸引力的作用好像并不大。我的意思是，量身定制的软件中包含着成百上千个用例，而这些用例之间存在着极其复杂的交互业务和GUI逻辑。这种软件对于大多数程序员来说非常重要，因为工作中会牵涉到。而且这种软件也是我下面要探讨的Web应用程序开发的类型。

首先，我们来总结一下GWT为(Java)Web 开发团体所带来的创新，有以下几点:

一个使用Java.lang API实现的从Java到Javascript的编译器——虽然这个想法很棒，但是，这确实不能算是创新。因为，至少有一个以上的方案(J2S)已经提供了与此类似的特性，实际上，还提供了更先进的JavaScript生成特性。

一个窗口组件库，能够在不使用HTML的情况下构建用户界面(UI)。这有些类似于Dojo中具备的功能，并且与J2S/RIA几乎相同。除此之外，还有一些服务器端的框架也能够提供相同的功能(如Echo2、wingS)

一个在HTTP协议上的远程过程调用(RPC)的实现，它能够通过DWR在其他协议上实现。

一个允许在Java中调试应用程序的容器。实际上，J2S确实不需要这个功能，因为它能够解释SWT/RCP代码，并且作为桌面应用程序自动运行。

在项目开始时，脚本是受到了Ruby on Rails的启发(至少是类似的)。

因此，Google主要是陷入了这个严重的问题:重新实现所有这些可利用的项目。当然，你可以争辩说，他们实现得更好、用起来更加方便、使代码更加文档化(这通常是一个项目成功与失败的关键)。但是，他们既然够像重新实现无数的其他项目，那为什么不重新实现Eclipse项目呢?而且，他们为什么不利用丰富客户端平台(RCP)或者丰富互联网应用程序(RIA)堆栈呢?

关于这个问题，我的回答非常简单——Google希望解决他们自己的问题。为了理解GWT，我们首先需要理解Google创建它的动机。Google是不做商业软件的——他们做桌面软件，然后把它们放到web上(如GMail、Base、Spreadsheet、Calendar等)。这些软件所包含的用例相对较少，而用例通常都是很复杂的并且需要响应的。

　　Google需要一种开发新的web应用程序的方式，这种方式应该是:
　　1. 高度响应的
　　2. 迅速开发的
　　3. 迷人的

　　其中，第二个目标的障碍是:如果要在web上达到高度响应，那么，你必须采用很多快速解决方案，而且更糟糕的是，你需要针对不同的浏览器采用不同的快速解决方案。正是这个问题使AJAX应用程序的开发成本远远高于普通应用程序的。

　　针对这个问题，一个显著的解决方案是:把这些快速解决方案封装起来，放到简洁的界面背后。还有一个不很显著的解决方案是:使用大量的集成开发环境(IDE)和调试器，把快速解决方案封装到静态类型语言中，然后，尽量避免在应用程序中同时使用JavaScript。因此，GWT是解决快速开发AJAX类桌面应用程序的最佳方案，并且，GWT能够运行在主流的浏览器上而仅需要相当少的测试。

　　但是，剩下的开发人员应该怎么办呢(尤其是那些编写大型商业应用程序的开发人员)?我的观点是:如果GWT不是100%纯粹基于JavaScript的话，那么它将是一种非常棒的视图技术。关于HTML和JavaScript的问题是:目前，至少有4种大型的不兼容的平台实现机制。我们正在讨论的就是:一种能够配套四种虚拟机的语言，同时它能够与事后制定的标准松散耦合——James Gosling的恶梦实现了。

　　Web在商业应用程序中能够得到如此广泛的使用，其中一个主要原因就是:它是建立在Java承诺一次编程处处运行的基础上的(因为web平台比Java简单得多，而且对客户端环境的依赖较少)。而且web也能够给我们提供这些可能的特性:易于混搭、整合、重新设计等等。但是，JavaScript却使这个承诺变得毫无意义，因为在浏览器中存在着:
　　对于脚本规模的限制
　　对于脚本存储消耗的限制
　　对于脚本运行时间的限制
　　交叉域的访问限制
　　非常多其他类型的限制，程序缺陷和不兼容性，这些都在折磨着web程序员

　　所有的这些意味着你只能封装这么多——迟早一些“有毅力”的bug会死灰复燃，或者，使用标准工具包的话，你可能完成更多工作，而现在，你还需要采用JavaScript快速解决方案。实际上，我几乎能够确保:在所有规模足够大并且复杂的应用程序中，这种现象很快就会出现(我的意思是像内存溢出这样的bug，它们几乎不可能在平台中被调试出来)。确实，对于应用程序而言，HTML和HTTP从来都是没有意义的，它们的作用是用于在科学家之间分享信息的。不久，动态DOM、CSS、XML以及其他缩略语所代表的技术将运用到这些应用程序中来，虽然它们能够适合，但是，并不匹配——你可以用，但是无法走得很远。

　　现在，结束对AJAX的讨论，我们切换到应用程序本身上来。一个典型的大型企业应用程序有着各种不同的用户界面需求，而不仅仅是一个典型的桌面界面。在商业应用程序的图形用户界面(GUI)中，有许多大而复杂的工作流，但是，只是一小部分这样的工作流是需要达到高度响应的(典型地，某些查询或者搜索)。而且，通过使用HTML并且添加一些独立于浏览器的JavaScript，这些需求是很容易满足的。实际上，如果我们对商业用户的需求进行调查的话，就能够了解到他们所需要的软件是:
　　满足他们需要
　　能够快速开发、价格合理
　　不要与单独的开发商或者合作者绑定
　　易于与其他软件整合

　　通过以上分析，能够找到给商业世界带来这些的软件，并不是那些没有使用AJAX的软件。在web框架中，首先需要满足的是高度响应和整合——可能这就是为什么Struts如此流行的一个原因(运用Struts的主要过程是解决大量的遗留代码)。而且AJAX，如果有什么区别的话，那就是:加大整合难度、降低生产力。

　　但是，这就意味着我将永远宣传简单的web应用程序么?当然，不是!我只是认为:基于IE来模拟桌面，这是商业客户端所无法承受的。如果已经做好了一个通用的丰富的GUI平台，那么，我将成为第一个进行试验的人。使Eclipse 丰富客户端平台(RCP)更加完美或者在Adobe Flash上编译Java应用程序(至少是稳定的平台)，甚至可能将Avalon运行在Linux上。仅仅给我一些任务——让我以此来编写Java代码、并且带来的困扰比web应用程序少，我就能够无障碍地工作了。

　　因此，在未来的几年内，Google Web Toolkit至关重要么?我肯定希望是不，因为这将意味着，我们必须在本质上具有破坏性的平台上来构建下一代的应用程序。而且，不论我是否有偏见，在21世纪的前十年内，我非常希望能够看到更好的平台发布。

SVG Graph on Web Browser

2006-10-01T18:41:00.000+08:00

This is my first AJAX program, a collabrative graphic editor based on SVG. I found SVG is extremly cool for Internet based graph sharing. Here the graphic is composed of vector data, instead of bitmap. This helps to easily share the editing process across Internet.

It can find great oppotunity on remote education, Web conferences, and virtual white-board applications. I wrote this program with AJAX in the client side, and Tomcat 5.5 in the server side. I'd like to using DOJO, and Ruby on Rails in the future...

Ruby On Rails

2006-10-01T12:00:00.000+08:00

对于计算机，我其实是一个实用主义者。意思是，我不会像我的某些朋友那样，对Open source，Linux,和 command line tools怀着强烈而近乎偏执的热爱。我更倾向于非计算机专业人士的特点，喜欢好用，方便，省事的操作系统和应用程序，而且至今对Linux没有什么经验。所以让我对Ruby on Rails产生兴趣的，不是Ruby on Rails本身，而是RADRails这个IDE.

总是有人低估IDE的作用，摆弄自己的Emacs之类的复杂编辑工具，我不是。举个例子，象object pascal这样的语言，我相信，如果没有Delphi这样好的IDE，是不会有太多人感兴趣的。Ruby on Rails也一样，如果没有好的IDE支持，很难有革命性的突破。所以当我看到RADRails这样的rails工具，有眼前一亮的感觉。怎么亮起来的呢？

首先，Rails所标榜的结构清晰，配置简单，在IDE上，一目了然。IDE可以把项目的整体结构展示给开发者，这是一个很大的优点。

其次，Rails天然就需要集成数据库操作。而IDE可以把数据库的整体状态一并展示给开发者：表的结构，表内的数据，表间的关系，等等。

第三，Rails集成了测试环境WebBrick服务器，通过IDE，发布和测试程序很方便。

这样就会“眼前一亮”吗？有人会说，你提到的这些东西， J2EE IDE都具备，而且做的也非常出色。我不想卷入J2EE和RoR之口水战，我相信“存在即合理”这个道理，每一种驾构应该都自有其生存之道，遇到具体的项目实践时，择其善者而用之是最好的。我想说的是，RoR配上一个剪裁合适的IDE，实在是Web项目开发者的福音，对开发者体贴之至。

所以，不要因为Windows Vista作出很眩的UI效果来就对其他事物失去信心。我相信Vista仅仅对Microsoft而言是一场革命，但是想用这样一个东西来对付整个计算机世界，还是心有余而力不足的。

回忆我读过的计算机书籍

2006-09-30T22:59:00.000+08:00

《Delphi 4.0从入门到精通》是大二时读到的第一本编程著作。当我的同窗日日白天逃课睡觉夜里打红警的年代里，我不想这样白白度过味同嚼蜡的大学生活，因此到书店去随便挑了本编程方面的书，就是这本了。靠这本书后来还弄了个Borland认证讲师的头衔，不过一共只讲过两天的课程，而且效果并不是很好~~~

《Visual C++技术内幕》可以算读过的第一本有点技术含量的书。大三时一直学到讲COM之前的那一章，而且基本上例子都敲了一遍。

《Servlet编程指南》让我学会了Server端程序设计。这本书其实写的很好，作者是满有Java编程经验的，成书是在JAVA诞生的第三个年头，1999年。

回想起来，形而上的著作往往起不了多大作用。《设计模式》很早以前拜读过，现在基本上记不起来几个模式了，但是让我悟到了OO的本质，用抽象的方式来驱动具体的行为。N Nillson写的那本AI入门教材也是我曾经精读过的一本书，当年去新东方GRE班时，一个人晚上借宿在清华14楼里看完的。现在对新东方的回忆，只有老罗的笑话和晚上读AI的感受了。

《精通EJB》。我在大四时弄过CORBA，所以EJB当时对我来说，就是一个简化版的分布式对象基础平台，真没想到它会成为编网站的主流；也没想到它在成为主流之后，因为过于烦琐而成为众矢之的。

《Contributing to Eclipse》。04年初读的英文原版，开始读这本书的动机基本上是为了进IBM做敲门砖。不想真的读出了一些感触来，以至于把这本书上所有的例子都实验了一遍，而且还意尤未尽的编写了一个XML编辑器。当时读书的时候还没有注意作者，现在反来看看，作者是Eric Gamma和Kent Beck ，一个设计模式的先驱，一个XP的导师。这本书的特点是“新瓶装新酒”，新瓶是Eclipse plugin,新酒是TDD。用Eclipse作为工具来讲解TDD的实践精髓，是颇具匠心的。（我的个人看法，其实Eric Gamma不应该呆在Rational当STSM，而应该站出来领导一些创新性的open source project。）

《AJAX In Action》在读中，领略到WEB 2.0的一些思想，不错。

Web 2.0背景下Portal的思考

2006-09-30T22:58:00.000+08:00

Portal思想，中文翻译成“门户”，曾经是B/S领域中独树一帜的思想，在90年代中期在学术界达到研究高峰，并开始为大公司竟相追捧而出现了多种实现产品。如今的 Portal，处在多种专利的包围下，处在JSR 168/286/WSRP等多个标准的规范下，已经成了大公司手里的摇钱树。如果有人问什么是企业Portal，技术角度的回答是这样的：Portal是一种基于Web的企业集成解决方案，用Portlet作为基本的构造元素。每个Portlet负责 Web页面上的一个模块，有自己的状态；Portlet之间可以互相通信；开发者可以根据JSR 168规范来开发一个J2EE Portlet。的确这是目前大多数Portal产品和open source项目的实现方式。但是，这其实陷入了一个误区，可以说，Portal思想被Portal的主流实现给局限住了。

要说明这个局限，首先想一想，到底Portal思想是什么？我想可以用两个字来概括：一是门户，二是集成。门户的意思，就是把来自很多信息源的信息用统一和方便的方式来访问。这种方式需要为每一个信息源定植一个视图（还包含控制器，用来控制用户与视图间的交互），同时提供一种聚合能力把这些视图组合成一个完整的Web页面展示给最终用户。这样一来，用户可以在一个页面里面享受到来自多个信息源的信息，并与之交互，这为用户提供了极大的便利，但是还不够；因为信息源之间还可能存在着可以自动完成的交互，不必假手于用户。这就需要集成。集成的本质就是不同的信息源之间的交互。为了支持这种交互显然需要很多手段：例如不同信息源对用户的认证信息很可能是不同的，这需要Portal提供”单点登录“的机制，根据Portal上用户的认证信息来自动的匹配信息源的认证信息，并提供给信息源。另一个例子是消息机制，Portal可以把一个信息源的请求封装成消息Publish到别的信息源上，引起该信息源的某种行为。可以发现，其实Portal的这两个思想其实和Web 2.0没有什么矛盾之处，甚至可以说，Web 2.0为Portal思想的实现提供了更多，更丰富，也更方便的解决途径。事实上，和Web 2.0相矛盾的，不是Portal的思想，而是Portal目前的实现机制；是JSR 168/286/WSRP 这些现成规范构造下的Portlet，是几大IT公司年销售额数十亿美元的主流Portal产品。那么，从发展的眼光看，构造适合于Web 2.0的Portal产品，不仅是一个可以躺在床上想出来的趋势，而且很可能是一个可以赚到大把美刀的商机。

接下来的问题是：Web 2.0的Portal是一个什么样子？我很喜欢的一个网站是NetVibes (http://www.netvibes.com)，读者可以体验一下。其特点简单来说，也是通过很多个Web Module来构成整个页面。但是每一个Web Module的构造比Portlet要简单的多。可以是一些java script和servlet构成的简单结构，加上有限的配置文件，servlet通过某种远程调用方式连接到信息源。也可以仅仅是一个配置文件，含有信息源的URL。在第一次装载的时候从服务器拿到页面的结构信息，然后每个Module异步的装载自己的信息。这并不是一个完全实现Portal思想的Web 2.0网站，但是我们可以从这里找到Portal思想的影子。

Firefox中的canvas标记

2006-09-30T22:56:00.000+08:00

昨天在家里拨了一次电话会议，效果很好，感谢CRL的SMILE系统。主讲者是Dog Wilson，Lotus DE，让我对“协作”有了一些基本的“理论知识”；同时隐约感到XUL Runner成为一个新的焦点。

上一篇文章基于以前对XUL RUNNER的认识，已经有点问题了。今天看到了Mozilla已经支持的一个新的标记，就是

XUL Runner 的反思

2006-09-30T22:55:00.000+08:00

几年以前可能很少有人想到Java-script现在能成为端上席面的大餐了，那时我还煞有介事买了那本著名的《精通EJB》拿来啃，觉得越是深奥的东西将来越有前途。而现在是“简单化”的时代，用编程的方法做UI已经逐渐落后，而基于XML描述式的方法逐渐成为主流，Semi-rich client成为了大公司竟相研究的热点问题。

在热点之中有一个本来应该很有潜力的技术，就是 Mozilla的XUL Runner。XUL Runner被设计成一种可以支持“轻量级”UI的平台，所谓轻量，是和那些用Native widget来构造UI的技术，如Eclipse的SWT，以及SUN的AWT相对应的。不用系统提供的widget，那就自己画。Swing/Draw2D都属于这样的技术。用XUL Runner来画widget应该是驾轻就熟的事情，因为它天然就具有了渲染HTML的能力，自然也能扩展一下渲染其他的东西，比如X-Form, SVG, MathML，都是Mozilla网站上声明支持的东西。除了画静态的UI，还应该具有一些动态特性，XUL Runner天然含有Java script引擎，在XML里面嵌入脚本语言，用脚本来动态修改DOM树，从而实现动态特征。

有了这样一个天然支持HTML/XUL和java script的基础平台，如果加上一些可扩展特性，比如集成JAVA，C++既有程序的能力，不就是一个很好的桌面应用基础平台吗？而XUL Runner也的确提供了这样的东西，就是XPCOM。最大的问题就是XPCOM实在太难学，而且是以C++为基础的。如果想用JAVA，实际上还要通过一个JNI写的Bridge程序来完成。

那么，想要让XPCOM好用起来，就需要在这个JAVA-XPCOM bridge上面再做一个IOC的封装，让人们可以通过XML来对对象进行实力化，但是这就又回到了Java低性能的老路上了。当我们操作一个UI对象时，实际的工作是先有一个Java 反射的动作，然后是JNI调用到XPCOM，XPCOM再调到Gekeo，Gekeo最终调用Win32 GDI函数来工作。这样下来弄不好比ECLIPSE还慢。

到底有什么办法让我们既有软件工程化的享受，又有性能上的舒适？这应该是Architect要面对的大问题了。

Portal面临的挑战

2006-09-30T22:52:00.000+08:00

AJAX技术的出现使portal技术面临着巨大的挑战：

和AJAX技术的旨趣类似，portal技术也希望Web页面变的更像传统好用的C/S模式应用界面。通过在server端进行一些独特的处理技术，portal页面看起来像一个个小窗口，每一个小窗口相互独立，也可以彼此合作。在server端每一个小窗口由一个portlet提供，通过复杂的聚合技术把portlet输出的内容聚合成一个完整的portal页面。显然，聚合技术是portal的核心技术。然而聚合带来的问题是：一个portlet的刷新请求需要整个页面所有的portlet都进行刷新；而大部分portlet的状态其实并没有发生改变。这使得portal的性能受到很大的质疑。

AJAX带来一种新的思想：可以在浏览器端完成聚合操作。可以看看Netvibes (www.netvibes.com)和GOOGLE IG(www.google.com/ig)的效果。这种技术的要点是：server端比portal简单的多，仅负责维护若干类似portlet的Web module以及用户选择的页面设置信息。把页面上Module聚合的工作用数千行java script写到页面里，在运行时由客户端浏览器来完成。

这种效果比传统的portal要好的多，带来一种 Module独立刷新的效果。我看到很多人在讨论portal技术与AJAX的结合，但是AJAX实际上已经让整个portal技术的存在带来挑战。

挑战之一是实施成本问题,主流的商业Portal服务器(IBM WebSphere Portal, SUN Portal, Microsoft SharePoint, BEA Portal)一般都是很贵的,项目预算当在7-8位数(硬件,软件,业务系统开发和培训服务), 一般的项目不敢问津. 开源产品,(包括Liferay, Pluto, JBoss Portal),需要二次开发的成本很高,而且缺少很多高级功能(典型如Inter-Portlet Communication,以及 WSRP支持),导致总体的成本仍然很高. 相比之下,采用AJAX方案就便宜的多,需要的仅仅是一个普通的Web Server. 只需要有人在IOC容器基础上做一个AJAX客户端聚合的Framework. (这会是一个商机?)

挑战之二是性能问题. Portal在Servlet之前作了一个统一的聚合器, 聚合器在一个浏览器请求之前需要页面上的所有portlet的render request返回, 而Portlet的处理时间是参差不齐的.这样,即使在WebSphere Portal 6推出并行render之后, 页面也要等待处理最慢的portlet返回之后再返回. 曾经有人提出使用IFrame的解决方案,就是把处理慢的portlet 放到一个IFrame里,这样可以让Portal页面先带着大多数Portlet返回. 但是AJAX可以作到每一个类似portlet的模块异步请求, 独立刷新. 显然更好,更彻底.

05年时我们曾经的一个idea是,把每一个portlet封装为一个web service服务点, (WSRP已经可以作到这一点), 然后改进聚合器,让聚合器首先把页面的框架和js返回,然后每一个portlet通过AJAX请求异步拿到自己的内容. 这里涉及到一个关键问题是URL改写.

现在我发现其实这种框架完全没有必要仅仅套在portal上, portal为了进行页面聚合而对JSP上的所有内部URL作了死规定,让外界无法对单独的portlet进行请求;而现在世道又反了,那何必再用Portal呢,JSP/Servlet都是可以独立接受请求的东西. 只需要有一个比较好的AJAX框架,再加上一个好用的Web 模块管理server,就完全可以制作出一个和portal技术相当,而性能又优于portal的技术来.(缺点可能是对移动设备的支持比不上portal,因为移动设备的浏览器对XMLHTTP是不支持的.)

也许AJAX将是Portal的终结者.

论倚天屠龙记中继承人问题

2006-09-30T22:51:00.000+08:00

在金庸先生的笔下，武当派是一个比较典型的正派代表，具有正宗的儒家传统和封建家族管理特色。“掌门人继承问题”在本书中不是矛盾集中处，也没有太多的文字篇幅。然而从作者笔下旁敲侧击的文字中推想一下，还是很有意思的。从这里,可以看到很多中国传统儒家文化中带有的虚伪色彩.

我们先从门派管理的角度来分析一下几个核心人物，首先看张三丰。张老是无当派的创始人，是具有全江湖影响的一代宗师，精神领袖，自然在派内具有无人能及的地位，然而他在门派管理上显然不是内行，有点类似SUN的戈斯林。我们在书中看到他经常一个人呆在某间舍内闭关研究武学，一闭就是数月，自然不会去处理派内的内政外交方面的琐事。即使在张老百年寿诞上，形格势禁，剑拔弩张，武当有倾刻间全派覆灭之险的时刻，张老还是坐在大厅中和一众宾客谈笑风生，大事全在张四和宋大做主，而全然不和张老商量。而张四和宋大决策之时，完全是一副架空主帅的作风。（金庸在这一场面的处理上显然是不到位的）所以张老在武当，名为掌门人，实则被架空，大权不在握。因此，张老在掌门人继承权的问题上，分量是要打折扣的。

次看宋远桥，宋大，是掌门人的绝对主力候选人。第一点，张老自己没有子嗣，因此宋部（宋及其子青书）就是张老的嫡长一房，从儒家传统来看，立嫡立长都是合乎宗法，天经地义的事情。第二点，宋的技术水平在派内是数一数二的，从金庸的描述来看，仅有愈二，愈三，张五可以与之相比，后二人一残一伤，可以除外，只有愈二，我们一会再谈。第三点，宋长期以来已经掌握了派内实际的行政，外交，和财政大权。然而宋大的致命缺点，是在派内似乎并不服众。我们举几个例子：

其一，愈二在接张五回山的途中，曾经和张五似开玩笑的说了这样的话，大意是有一次和师父谈话之际，张老有将衣钵传给张五的意思。这件事想起来意味深长，这次谈话的时机发生在张五远在海外，大家都认为他已死的时候，显然张老也只是从回忆张五的角度来说的，以张老的心机可能不会料想到这件事在弟子们心中造成的影响，随便说说而已。但是事实上在弟子们心中肯定是一枚炸弹，至少在一定程度上表明张老对宋大行事作风的不认同。这就使立储问题产生一些不确定因素。

其二，在张五到得山上的描写中，我们发现张四在武当很多事物的处理中起了决定性作用，而在众人心中的影响力要高于宋大。在张五上山之际,看到作者对张四的评价是足智多谋,颇似梁山的吴用,而技术水平也不弱.尤其在处理寿诞危机中筹划曲直，深孚众望。

其三，在兄弟情谊上，宋大显得不很合群。比如张五刚进山门，发现宋大正在为两个镖局调节争端，几个师弟就对这种行为表示出不满的声音，至少普遍认为宋大的这种做法不太妥当。在张五自杀，众人哗然之际，我们看金庸的描写，一众兄弟伏在张五身上大哭，惟有宋大，忙着招呼众人，待到外人走光，方才来到张五身旁，眼眶带泪而已。

这样，我们可以想象，张三丰百年之后，武当实以处在分崩离析的边缘。如果宋大即位，兄弟们貌合神离，必定不服。如果宋大不即位，那么宋大本人必定成为不稳定因素,从其子宋青书背叛师门的事来看,相比宋大本人也不是省油的灯.

从EJB饱受抨击想到的

2006-09-30T22:50:00.000+08:00

以前我听不止一个人对Entity Bean抱以否定的态度,而J2EE development without EJB...在这本书里,至少有一半的篇章对EJB抱以强烈的抨击和讽刺.讽刺的焦点集中在:
1. 架构过分复杂.
2.提供了不必要的远程调用机制.
3.偏离了OO的设计原则
4.Entity Bean只是一个数据库映象层,不能提供真正的ORM功能.

作者在书中告诉人们:实践是检验真理的唯一标准.而架构师想象出来的完美架构往往不是程序员真正想要的,和合适的东西. 由此我想到IBM制造出来的众多架构,Activity centered, Composite application, ESB,..., 会不会也有这种"空中楼阁"的成分? 这可能也是IBM Workplace叫好不叫座的原因之一吧. 比如Workplace系列应用都有一个共通的特点,就是支持离线应用.一个例子是邮箱,可以白天在公司里收信,晚上回家离线阅读. 把这种模式推而广之,就形成了离线应用的模式. 可以把以前部署在server上的web应用,portlet application完全搬到client端,在本地搭一个嵌入式数据库.离线时可以用浏览器连接本地的web app,而online时完成数据库同步. 想法很好,但是不知道有什么具体的业务(除了邮箱)会有这种需求. 看了看新闻发现Microsoft 也在支持这种东西....

来自without EJB中对架构师的批判是很激烈的.这种批判来自信仰XP哲学的程序员对传统程序设计思想的挑战. 但是我有如下感觉:XP哲学基于的经验,大都来源于XP作者们的对精巧的小型项目的实践.但是现实生活中的确存在着需要2000-3000程序员合作完成的,渗透着极其复杂的思想,因而需要很多架构在里面的项目. TDD是个好东西,但是它里面没有告诉我怎么把一个project拆成部件,让一个200人的team去分别完成每个部件,然后集成. 我们只能依赖传统的OOP和架构师的努力. 我看到作者在书里暗示着他对Rational Rose的态度,我觉得这种态度是有失偏颇的.送一句老罗语录: 年轻人,总是把创作的冲动当成创作的才能...

程序员为什么跳槽

2006-09-30T22:48:00.000+08:00

程序员频繁跳槽似乎成了一个不可避免的现象。很多网站请来所谓的职业分析人士，人力资源管理者座谈，分析；看了看，多数属于小儿科，很少有真正从一个程序员的角度和眼光去看问题的。我认为，一个程序员跳槽根本的原因，主要是公司团队问题，其次是公司企业文化问题。很多人只看到了薪金问题这个表象，事实是，薪金问题根源于公司领导者对基层团队建设以及企业文化的掌控上。

一个公司可以有很好的愿景，理念，和技术思想，这些都很好，但是这些好东西最终还是要和销售收入联系起来，在营业额快速增长的基础上逐步实现这些好东西，这不仅需要一个好的决策层，更需要一个好的执行层。中国的所谓“高科技创业者”建立起来的小公司们，多数是“海归”顶着某某名校的金字招牌回国创业，吸引投资者（主要是地方政府，他们是中国的风险投资商，可能也是地球上最笨，最容易受骗的投资者）大量注资，然后建立起来的小公司。其实我对“海归”真正的能力一直抱怀疑的态度，这些人在国内多数从大二开始混专业课，拿出80%的时间来准备TOEFL，GRE/GMAT；在国外呆上四五年，混个PhD或者MBA出来，资质肯定不怎么样，很难找到体面的工作，所以回国。于是，一群“满不懂”的投资者加上一群“假行家”的管理者，构成了公司的管理层。小公司一般有1-2年的创业期，这个时期内可以靠创业基金生存而不考虑营业额和利润。可以说，如果没有来自大公司的技术力量的加盟，这样的管理层实际上缺乏运营正规软件企业的能力。在这些处于生存期的，还不是很正规的软件企业中，具有凝聚力的团队就成了他们能否度过生存期的关键。

现实生活中，我看到也经历过这样的团队：缺乏正规的软件工程建设经验和意识，缺乏资深的技术领导者，技术负责人缺乏经验，等等。这些问题都是团队致命的缺陷。这些问题导致程序员对团队失去信息,失去动力,最后只好跳槽。

其次，公司的企业文化问题。对比一下欧美企业和日韩华资企业，文化差异是很大的。我觉得从文化的角度来看，在欧美企业工作感觉比较民主，自由；而亚洲企业的感觉多数是专制，压抑。显然这和企业领导者的民族特质有很大的关系.对技术人员不够重视,不够关怀,也是导致程序员跳槽的一个因素. 一个人到一家公司,他一定希望和这家公司一起成长.当他发现公司的成长不能满足他自身的成长需求,或者公司阻碍他的成长,就应该是跳槽的时候了.

基于open source的咨询业

2006-09-30T22:47:00.000+08:00

今天终于买了那本经典之作《J2EE Development without EJB》，读到26页，就忍不住要写点东西了。书真不错，是我看到的比较少有的佳作，而且JavaEye翻译的也很到位，不枉我经常光顾他们的论坛。第26页的内容让我想到了一种商机，基于open source开发工具的服务，我感觉这是一种国内软件业企业非常需要的业务。

Rod Johnson（他竟然是一个音乐学博士，惊奇ing）告诉我们，在J2EE without EJB的时代，仅仅依靠众多open source project所提供的功能已经完全能够开发企业级应用了。这对于中小软件企业绝对是一个福音，显然，一旦省略了购买J2EE应用服务器产品的费用，开发和实施的成本可以降低很多。但是这样做对于应用软件提供商又是一种挑战：在开发周期紧张的前提下，用很短的时间把基于open source的开发环境，运行环境（应用服务器），测试环境和软件配置管理工具（CVS，SVN，Bugzilla等等）及时部署到位，在这些环境都是基于open source，而开发团队新手又比较多的条件下，对项目经理是一个极大的挑战。以我加入IBM之前的公司工作的经验，我感觉这样实施下来困难是不小的。测试组和开发组的连动，Build team的建立，都需要不小的力量。实施之后需要把实施经验，工作流程积累成文档，也需要专门的努力。这样，就需要一种针对软件公司内部建设的咨询业，为软件公司提供针对基于open source开发过程的咨询服务。

建立这样一个咨询公司，需要这样两种人：咨询师和技术专家。首先咨询师走访客户，根据客户的项目特点，团队架构帮助客户制定一份详尽的实施计划，包括团队的构建（开发，测试，软件配置管理），每个团队所使用的开发工具的确定和实施，并制定日常工作流程。然后，根据项目特点，咨询师选择合适的技术专家帮助客户建立一个和项目尽量接近的应用模板，咨询公司应该尽量积累这样的应用模板以便用尽量快的速度帮助客户建立这样的模板。模板包括：值得学习的应用程序代码，配置脚本，build脚本，和各级测试用例。在项目进行过程中，咨询公司可以提供技术咨询，比如编写复杂的配置脚本等等。咨询公司的任务应该仅局限于软件开发过程和支持工具，而不去干涉业务。这样双方就没有任何特殊利益上的冲突了。

当open source成熟并且得到多数公司接受之后，这会不会是我们的一个归宿？