用于动态图表绘制的API

　　一个很简单但又非常实用的用于动态图表绘制的API：

http://code.google.com/apis/chart/。

　　全部的API调用格式都用一个URI完成，可以设定在<img>标签的src属性中，是一个典型的基于URI驱动的设计：

http://chart.apis.google.com/chart?<p1="">&<p2="">&<pn="">。

例如：

chf=c,lg,0,76A4FB,1,ffffff,0|bg,s,EFEFEF……

　　三个多月前，曾经和Tianle同学也一道研究设计过类似的API，主要用于为Web Dynpro提供动态图片绘制。如果使用过Web Dynpro，那可能会对其图片UI控件无法支持“动态文字叠加”的限制印象深刻吧，我们当时能够解决的是通过基于URI的API来完成各种的图片绘制，包括渐变、倒影、文字定位和样式布局等功能，从一定程度上来弥补Web Dynpro在这方面的不足。后来，由于一个棘手的多国语言字体问题，使得我们无法进一步推进这一API的使用，可谓稍有遗憾。不过，我们已经有打算在合适的时间场合将这一解决方案作为开源项目放出来了。对此有兴趣的朋友，我们可以进一步讨论。

by William Cui 崔伟毅

Office 2.0 战场硝烟弥漫

　　自从在线文档共享平台Adobe Share发布后，被Adobe收购来的BuzzWord也开始向公众开放预览版了。由于是基于Adobe Flex开发的，BuzzWord在用户界面、渲染效果和工作性能等方面无疑具有一定的优势，使用起来更像是传统的桌面版文字处理软件，可以相信Adobe也一定会借助它AIR平台的已有优势在这一新领域进一步发力，尝试做好浏览器和桌面软件的衔接。



　　当然，传统Office老大Microsoft也绝对不会放弃这块在线市场，姗姗来迟地结合它的Live战略推出在线Office套件，因为目前为止还没正式向公众发布，所以还不清楚这个在线协作产品和现有桌面产品的定位以及依赖关系是怎样的，不过可以想象的是一旦大规模发布，必定会是一颗重磅炸弹。

　　接下来，就是知晓度最高的Google Docs了，现在已经具有相对完整的Office三套件：Docs，Spreadsheets和Presentation。但是Google一直没有正面冠之以在线Office软件的名号，只是突出其协同文档、表格和演示工具的特性，可能也是一种产品定位上避免正面竞争的考虑吧，毕竟如果要真正作为桌面Office的替代品，从Ajax技术限制以及用户使用习惯角度来说还是有很大不足的。

　　最后，很值得一提的是来自印度的Zoho在线应用软件套件，这是迄今为止最全面的由一家公司推出的在线工作软件整体解决方案，令人惊讶的是它还提供了托管版的按需CRM、商务应用解决方案还有即时通信、邮件系统、项目管理、会议系统和Wiki等一系列在线工作软件。对于这样一个潜力巨大的新星，可以想象得出它已经被好多这一领域的后进者们看上了，据说Yahoo就是其中一员，不知道像SAP或者Oracle之类的会不会对此也感兴趣呢？

by William Cui 崔伟毅

有关Web技术和Ajax安全的资料分享

　　首先是今年在加拿大举行的第16届The International World Wide Web Conference，大部分papers都可以下载到PDF全文。比较值得一看的有：

• Subspace: Secure Cross-Domain Communication for Web Mashups
• The Complex Dynamics of Collaborative Tagging
• The Two Cultures: Mashing Up Web 2.0 and the Semantic Web

　　该大会明年在北京举行，也可以浏览历次的会议论文：http://www2006.org……

　　另外，与跨域访问和安全验证相关的还有来自Google的“New GData JavaScript library enables full read and write access for your mashups”，据说已经和AuthSub集成好，可以支持用纯JavaScript来完成数据写回的操作，而不再需要额外的服务器端代理包装了：

function logMeIn() {
scope = "http://www.google.com/calendar/feeds";
 var token = google.accounts.user.login(scope);
}

function setupMyService() {
var myService =
new google.gdata.calendar.CalendarService('exampleCo-exampleApp-1');
logMeIn();
return myService;
}

　　最后，关于Ajax的安全问题，记了这句话：“Ajax is not inherently insecure, but ignoring security makes it so”。

by William Cui 崔伟毅

代码分析和漏洞检测

　　在InfoQ上看到了一些关于代码分析的文章，发现了两篇比较有意思而且有完整中文译文的，分别是：

• 代码规范的自动化监管
  　　讲的很不错，印象最深刻的一点是，面对参差不齐的代码质量和编程习惯所带来的巨大挑战，传统的通过事后代码复查来试图纠正已经太晚了，而且会不可避免地导致编码人员的不良心理反应。因此，可能最好的办法就是实施自动化监管，把静态源代码分析和漏洞检测系统与版本构件系统进行整合，从而进行强代码制规范化，既一定程度上避免了垃圾代码进入产品构件系统，也使得编码人员更易于接受并积极改进。
• Google单实例模式检测工具
  　　这个检测是在字节码层面上的，而不是通常的源代码层面。因此，从难度上来说要高不少，而且很难检测完全。相当于要从一堆字节码中检测出某些模式或者特征代码，有点像查病毒软件的原理吧。
  　　至于单例（Singleton）模式的问题与否，我个人认为，如果采用的是松耦合的资源注入方式，那么使用单例并不是问题非常大的；反之，如果控制逻辑和资源状态是混在一起的，相当于一种全局的static容器，那么这无疑增加了测试和理解的复杂性，理论上是不赞成的。大家觉得呢？

　　最后，我也来介绍一个SAP的代码分析工具——JLin ，这个是可以通过简单地配置和构件系统整合在一起，然后生成代码质量报告。其本身是SAP NetWeaver Developer Studio的一个Eclipse插件，内置了一些基本的代码检测规则。在我们的日常开发中，任何Priority 1或者2的代码是不允许被带到产品的consolidate track上去的。虽然检测的范围还是比较有限，但还是在一定程度上起到了监管代码质量的作用。不过，就我的判断，在理论上，JLin的架构是能够支持更为复杂的源代码级或者字节码级的自动化代码审查和强制监管功能的。

by William Cui 崔伟毅

Google Gears，带动离线Web应用的齿轮

　　今天，Google向开发者社区公布了用于支持离线Web应用的Google Gears开源项目，并在其Google Reader产品中首先尝试应用了此技术。

　　记得几个月前我曾在“Offline支持——Web的下一个热点！”一文中分析过离线Web应用的来龙去脉，以及一些尚不清晰的发展方向，譬如离线业务逻辑、数据同步、安全机制等。有兴趣的朋友也不妨一看啦，欢迎评论和交流。

　　从初步的体验和探究来看，正像Google Gears的开发工程师Aaron Boodman和Erik Arvidsson在Gears API Blog上的写的那样，目前的Gears提供的还只是用以支持离线Web应用的最小基本功能集。还有更多的离线Web应用问题和解决方案需要得到广大社区和业界厂商们的支持合作和共同努力，以完成一个能够满足人们需求的基于开放平台标准的解决方案。

　　对于Google Gears的推出，让我们来看看其他离线Web解决方案提供商是如何反应的：

• Adobe的Mike Chambers在其Blog上表示，Apollo的下一个beta版本在离线数据存储方面的选择将会与Gears一样，即包含轻量级的开源SQLite数据库引擎，并且将考虑提供与Gears兼容的API以保证浏览器和桌面离线Web应用的API实现一致性。


• Dojo离线工具包的开发者Brad Neuberg在Ajaxian对其的访问中表示，他已经将Dojo的离线应用框架进行了移植，开始使用Gears作为Dojo离线框架的基础平台，从而与Google在离线Web应用这方面开展进一步的合作。

　　相信用不了多久，我们就能看到开放社区合作的进一步成果了，特别是在离线业务逻辑、数据同步、安全机制等方面。虽然目前的似乎还只是一个本地cache机制，但Gears的长远发展还是很令人看好的，有望真正称为带动离线Web应用的“齿轮”！

　　最后，让我也来贴一张Gears的高层架构图吧，顺便推荐一下来自朋友jeremy的“Google gears 與 flex/apollo 的簡單比較”一文，其中有些关于架构的分析和引申出来的想法还是蛮值得一看的。

by William Cui 崔伟毅

Google将以1亿美元现金收购FeedBurner

　　几周前，在“Google发布Ajax API使得RSS混搭应用更容易”一文中曾提及FeedBurner的RSS资源聚合管理服务，以及对其迟迟未提供类似的Ajax Feed API服务表示疑惑。现在，这个问题不解自答了：Google再次慷慨解囊，即将以1亿美元现金收购FeedBurner。
　　于是，大家不禁要问，收购这样一个RSS资源聚合管理服务提供商对于Google来说意味着什么？此次收购，对于其他竞争者和广大用户又可能意味着什么呢？
　　对于Google来说，这意味着其有进一步机会获得第一手的用户RSS订阅和阅读数据，而且更重要的是这一机会是独家的。因为RSS资源聚合管理服务相当于是一个统一的RSS代理门面（Proxy & Facade），即用户通过唯一不变的URL来订阅和定期获得RSS数据，例如本博的FeedBurner地址：http://feeds.feedburner.com/williamcui，以及Weblog评论的FeedBurner地址：http://feeds.feedburner.com/williamcui/comments。这样，一旦我的Weblog主机名、提供商或者Feed路径发生了改变，则只需在FeedBurner中进行配置即可，使得订阅了RSS的用户可以不受到任何影响，从而保证了订阅者的不流失性。正是由于有了这样一层代理，使得很多的基于RSS的统计分析、管理还有增值服务成为了可能，其中最有商业价值的就是有针对性的RSS广告营销了，并且FeedBurner中的广告可以进一步搜集用户的习惯来进行有效投放广告，而不是纯粹地根据RSS的上下文。单从这一点上来说，Google如果想从中获取投资收益，应该是易如反掌了，1亿美元还是太廉价了一点。
　　而对于其他的领域竞争者来说，情况就要糟糕的很多，不得不承认他们无疑失去了一个可以永久性粘住用户的巨大机会！因为考虑到流失广大订阅用户的巨大风险，FeedBurner的用户肯定不会选择转向其他的RSS资源聚合管理服务提供商。对于这一点，我估计Yahoo、Microsoft还有国内的Baidu、Sina等可能事先并没有预料到事态的严重性，要知道这个和搜索引擎可不一样，不是说换就可以换的，也不是靠技术或用户体验就可以赢得市场的，一旦错过了先机，想要再迎头赶上，可没以前那么容易罗！
　　此外，他们单单和FeedBurner竞争可能已经够呛了，Google还有两个目前市场份额双双占有的产品：Google Blog Search和Google Reader。此次收购势必会进一步强化这个黄金三角的组合价值，可以这样做一个比方，原来的Google Blog Search和Reader扮演的分别是资源探索发现者和资源请求获得者的角色，现在再加上FeedBurner即将扮演的是资源整合发布者的重要角色……由此，绝对可以预言得到一个Feed资源服务方面的强势风暴组合啊！其他厂商的组合产品似乎还没有什么听说，如果有知道的烦请不吝告知，谢谢！
　　最后，再来谈谈Google的这一系列Web资源平台化的战略动作到底对我们大众用户意味着什么呢？我们应该高兴还是担忧呢？高兴的是我们的资源可以更有效地进行整合利用了，担忧的是会不会我们的个人隐私都被Google一览无遗了，会不会有潜在的安全风险呢？或者说更好的做法是否是应该自己来管理、整合利用自己的资源，而不是依托于外界呢？
　　再补充问一句，这一切对于企业用户或者企业软件供应商又意味着什么呢？从某种角度上来说，企业应用在这方面的开发空间也绝对算得上是“蓝海”了！如果你有兴趣，让我们一起进一步讨论讨论吧！

William Cui 崔伟毅

Google发布Ajax API使得RSS混搭应用更容易

　　上周，Google的Ajax API团队新发布了一套实用的Ajax Feed API，使得基于JavaScript的RSS/Atom混搭应用比以往更加容易和直接。
　　和Google的其他众多API服务一样，应用开发者需要为某一网站申请域名一一绑定的API密钥。之后，便可以参照官方的JavaScript样本示例进行快速RSS混搭开发了。
　　可能对更多的Ajax开发者来说，Google的这一服务为他们雪中送炭地解决了一个JavaScript跨域访问“沙盒”安全限制的问题。通常我们如果需要跨域访问文档资料，不得不在服务器端增加一个代理层，通过相对复杂的服务器端程序巧妙地绕开该限制，这样的开发复杂度无疑抬高了RSS混搭应用的门槛，阻碍了普及化发展。
　　然而，由于通过Google Ajax Feed API获取的数据实际上只是Google服务器上的一个缓存（很可能和Google Reader等Feed聚合阅读器使用的是同一份缓存），而并非是最新的、精确的数据，这个多出来的一层在某些有特殊需求的场合下可能会受到一定的制约。
　　当然，将分散各地的Feed资源进行集中整合、过滤、缓存和再造的这一实践和思路，应该并不是Google首创的，著名的FeedBurner就是此类应用的一个较早的、也是较出色的例子，就是不清楚同样是整合了这么多Feed资源，FeedBurner为什么迟迟没有提供出Ajax Feed API之类的服务呢？或者说，大家还不是很清楚有这项服务。
　　另外，据说Microsoft也在上周将其Live Spaces的Feed服务全面扩充、升级，来迎合这一领域不断增长的用户需求。实话说，曾经对Microsoft大气宣传的在Outlook 2007和IE7中对RSS的直接支持一度看好，可惜用了之后才发现实在比较失望。让我们拭目以待，看看Microsoft又如何能够再度力挽狂澜吧！
　　更多的开发相关资料，请参考这篇开发者文档。

William Cui 崔伟毅

Morfik的"Ajax生成器"专利申请和GWT、Web Dynpro

　　近日，澳大利亚的Morfik科技公司向USPTO（美国专利商标局）提交了一个关于“Ajax生成器”的专利申请。该专利申请的名字为“System and method for synthesizing object-oriented high-level code into browser-side JavaScript，相关申请文献已经可以在USPTO网站上查阅，其摘要如下：

A system and method are provided to enable developers of web sites and software applications to code in an object-oriented high-level language that is compiled into a browser-side JavaScript which can be natively interpreted by a browser. This enables developers to program in a high-level language of choice to create browser-side web applications, instead of directly using the target lower-level language JavaScript.

　　进一步阅读，发现这个可能的“发明”是想为B/S开发人员提供了一套系统化的方法来达到以下目的，即把用高层OO语言（类Basic和Pascal，或者类Java和C#语法的）写的代码转化成可以被不同浏览器进行原生解释的JavaScript低层语言，从而简化了直接编写浏览器端JavaScript的复杂性，并在一定程度上降低了Ajax的开发代价。
　　说起“Ajax生成器”，我们可能第一个就会把它和Google的GWT（Google Web Toolkit）开源项目联系起来。GWT是一个开源的Java软件开发框架，用于开发类似于Google Maps和Gmail的Ajax应用程序。开发者可以用Java编程语言开发前台界面，然后用GWT编译器将Java类转换成适合各种浏览器执行的JavaScript与HTML。还有一个基于Eclipse开发插件Googlipse提供了GWT的集成开发环境。尚且还不知道Morfik的这一专利申请会不会和Google的知识产权存在法律上的问题了。就软件专利这一方面话题，我不久前写过一篇Weblog——漫谈“软件专利保护”。
　　此外，尽管SAP的Web Dynpro开发出来的不是严格意义上的Ajax应用程序，而且非SAP的客户或合作伙伴可能对Web Dynpro还不太熟悉，但是就我的实践和横向比较而言，在专业化的基于B/S的企业应用前台开发来说，Web Dynpro无疑大大走在了GWT还其他流行的Web MVC框架前面！这在SAP的Help Portal上有Web Dynpro的架构和开发模型方面的资料可以供研究参考。我也会在以后写一些文章来和大家分享SAP在这些方面的开发方法和实践经验。

William Cui 崔伟毅

Google轻量级"依赖注入"框架Guice 1.0开源发布

　　上周，Google将其内部使用的轻量级“依赖注入”（Dependency Injection）框架Guice 1.0版本在Google Code Project上开源发布了。

　　Guice（发音同juice，即果汁）是针对Java 5以及之后的版本来开发的，大量应用了基于注解（annotations）和泛型（generics）编程特性，使得代码的开发量和重复工作大大减少。

　　初看了一下Guice，觉得值得研究关注一下的地方有：支持任意输入参数的构造器、类成员和方法的依赖注入；灵活的自定义注入范围（scope）和循环依赖；与Spring，Struts的集成支持；面向方面编程（AOP）的类方法拦截器支持等等。

　　先抛开Guice不谈，从我的平时实践经历上来说，Java 5之后带来的特性，诸如泛型、枚举型、新for循环、静态常量import等都用的非常多了，但是annotations这一块用得倒真的不是很多，仅仅限于一些标准的使用，而没有从自定义annotations的角度来尝试一下如何提高开发和配置效率呢。究其原因，也可能是我觉得很多东西大家把development guidelines定下来后，各自遵守应用就行了，但随着重构进行和持续变化，的确有些时候重复地做了一些大同小异的事情，从而导致有些小小的混乱了。因此，接下来倒也是可以考虑来借鉴着做点这方面的小尝试吧。

　　再来说说“依赖注入”，记得很早之前Martin Fowler就写过一篇模式分析的文章，题为“Inversion of Control Containers and the Dependency Injection pattern”，推荐一看。万变不离其宗，这一系列相关的模式以及框架，大都还是围绕着“灵活松耦合”这个核心展开的。这个在我们的日常开发设计过程中的确也是反复地被实践应用着，但大都是手工实现的，基本没有采用那些所谓的轻量级框架（这有主观的，也有客观的原因）。诚然，这样手工的反复实现和改动的确会带来开发效率和清晰性的欠缺，但从另外一方面来讲，其运行时执行和调试的效率也无疑又是比较令人满意的了。最后，还是归结到一个“折衷”的问题，即一个框架是否“适用”或者说有无必要研究借鉴并重新“定制”实现要取决于实际情况。

William Cui 崔伟毅