摘要:这个post要表达的东西是非常基本而且简单的，但我已经反复考虑了数月之久。这里的程序指的是个人/家用桌面程序，非所谓的“企业级应用”。 几周前我在整理我家里电脑的相册时，PC和Laptop之间的相册不同步，COPY来COPY去实在是太繁琐了。而我在公司的另一台Laptop也带回家后，这变成了一个更麻烦的问题。解决这个问题的办法是找个文件夹同步软件。 在另外一个方面，假如我在父母住处也想看看我的相册怎么办呢？答案是我最好创建一个网上相册，比如Windows Live的Gallery服务，Google的Picasa相册，或者是其他网上大量的网络相册服务。而这里的问题是，网络太慢了，桌面程序点一下Page Dn就能翻一个相片，网上有时候要一分钟。 我的电子邮件也有着类似的问题。如果使用Outlook收邮件的话，收下来后服务器上就没了，这意味着我不能在另外一台电脑上再去查看这个邮件。对于工作邮件这可能不是个问题，但个人邮箱却没有办法。于是很多人选择了全部基于Web界面处理个人邮件，比如Gmail和Live Mail。 但更为理想的状况是，我可以用Outlook收发邮件，用Word编辑邮件，同时邮件在服务器上总是保存着副本（这可以设置Outlook下载邮件后不删除服务端邮件，但邮箱容量往往都很小，不能长期这么做，现有邮件系统也不把这种需求当作典型应用）。邮件服务器上不但保存一个一个邮件，还有我设置的邮件分类，还有已读/未读状态值，甚至Outlook的Flag和Task等。这样无论我在哪里打开Outlook，都是一样的体验。 我现在使用Google的Picasa相册已经有了部分的这种能力，它同时有桌面和Web版本，我曾对它寄予完全的希望，用来管理我所有的相片。但如果不是我孤陋寡闻，显然Google并没有考虑到这个方面，因为Picasa桌面端只能向Web端上传图片却不能下载。。。而更进一步的设计则应该是具有本地文件和Web数据库同步的功能。 Windows Live的Favorites似乎有着一模一样的问题，它允许你从IE的Favorites导入到Web端，但却没有反向同步的能力。。。但它相比Picasa的优点是，客观上它是支持导出的，但是只是导出到一个HTM文件让你下载而已。。。而不是自动“装”到IE收藏夹所在的文件夹内。 微软的Share Point Service加上Office则是个更接近理想的组合： 数据保存在服务端的数据库里，你在任意网络可连通的地方都可打开 Office一系列桌面软件安装于客户端，可以用这些软件来打开修改文档 这个组合在我看来已经接近完美了，但唯一的问题是在离线状态文档就不可访问了。我们需要文件在硬盘上的Cache。当然，SPS/WSS主要还是针对企业应用的，这个问题不大，网络速度一般也不会成为问题，数M的Word文件在数秒内就能传输完成。但如果Office System在客户端再加个“Share Point Client”维护硬盘Cache的话，那就更棒了。 这里的Model是相当简单的： 数据（Online，公共服务器维护，受安全措施保护）↑↓缓存（Offline，程序自动维护）↑↓程序（Offline，自维护或者IT管理员维护） 作为可选项，公共服务器上可以支持Web版的数据查看和一些简单操作 — 如果有必要的话。 至于Google的在线版本的Word和Excel，则根本是误入歧途（我不是作为一个MS MVP下这个结论的）。Google的选择是把程序和数据统统放在服务端，这大概是大部分对Google这些服务心存怀疑态度的人的最根本出发点。Web程序最终是不可打败桌面程序的，就算有下一代的DHTML可以做到和现有桌面程序一样的用户体验（比如Word般丰富的文本编辑器），他仍然需要硬盘的Cache。且不说这是个相当大的假设，更不用说微软的WPF加Expression套件在Rich Client方面已经再次走在了前面。也许五年后网络速度和连通性又有了非常大（速度*=100，连通性100%，网络延迟100ms内）的提高，硬盘Cache无足轻重，那基于浏览器的应用还面临着最后一个问题，那就是它们必定受限于浏览器安全沙箱模型，可触及的数据和可做的动作都是受限的。 Google的Picasa软件离这个目标则只有一步之遥。但令人匪夷所思的是，他们为什么不在Gmail这样的产品上也应用类似的策略呢？Gmail Notifier都做出来了，再进一步吧。Gmail的Web界面编辑器确实“还算不错”，但也只是相对于其它Web编辑器而言而已，距离Outlook等桌面软件差太远了。 除了这些用户关注的数据，其它程序本身使用的数据也可放在网上。比如说配置文件。极端一点，想象一下把整个Windows注册表都同步到网上的情形（当然硬件相关的配置信息就不用了），至少你能节约大量重装系统的时间（装系统很快，但装软件配置软件很慢）。Q3ACN（一个游戏网站）曾提供过保存Quake3游戏CFG文件的服务，大受欢迎，因为这样我们Quaker随便去哪个网吧都能以自己的CFG文件配置游戏系统，提高作战水平。要是id Soft直接把这个功能植入游戏，再在公司的Server上提供数据库接口，那就更完美了。（这是个坏例子，不打Quake游戏的朋友可能很难理解这一点。。。） 最后，关于SaaS（Software as a Service），这也是一个很好的切入点，虽然这个和SaaS只有一丁点关系。。。程序除了使用更好的加密算法防止盗版（比如微软的SPP），还可结合Internet。让程序的一部分功能依赖于Internet上的Server，可以非常轻松的获得非常好的保护。破解的Xbox360能玩单机游戏，却不能玩联网游戏，这就是个良证。把程序所需的配置数据放在互联网上，也是实现这个目的的途径之一。是不是合适，这是另外一个问题，这里的假设是你希望保护好你的软件并为你带来利润，而不是一个FOSS偏执狂。 刚才Kaneboy提示，Office 2007的Groove已经具备了我所需要的"Share Point Client"的功能，当然它的feature还不止这些，呵呵。updating...[阅读全文]

摘要: 思归和我翻译的《.NET企业服务框架》一书终于面世了，在这里可以看到相关的介绍和购买信息（第二书店上也有）。 目录 | 译者序 | 前言 | 作者序 这是一本介绍.NET Enterprise Service的书，做企业开发的开发者，一定能在这本书里找到你想要的东西。这里有3个章节的在线版本。 我还新建了一个Google Group，有任何关于这本书的问题都欢迎来这里讨论： .NET企业服务框架 Browse Archives at groups.google.com 最后，这本书本来预期是今年上半年上市的（我春节就交稿了），但由于各种各样的原因居然拖到了现在。对一直关注这本书的朋友们说一声SORRY！...[阅读全文]

摘要:--- 写在Vista RTM之日的流水帐 今年7月我转到了新公司，新部门，从头开始建设新的开发团队。作为一个理想主义者，原来打算直接上TFS（Team Foundation Server）的。。。不过对于这么小的Team，TFS太贵了点，有浪费之嫌。而现有的正版资源是，Windows 2003 STD，Office 2003 PRO，和Visual Studio 2005 STD。于是乎，我打算用WSS（Windows Sharepoint Service，Windows 2003的一个免费组件）做项目门户、共享文档、文档（with版本）管理等，用VSS 8.0做配置管理（有了VS或者Office的License后VSS就是免费的），再开一个File Server来放工具、软件等等。 但Bug管理的问题却一直没想好怎么办。原来在Infosys用的是Excel + RADAR，显然不能用；再之前是Clear Quest，还是太贵。Test Director和Silk Test之类的我也不想买。。。于是乎，在网上看各种免费Bug管理工具的评价和测试报告，最终圈定在了这三个（分先后）：BugFree、Mantis，和BugZilla。BugFree是一个微软员工写的，据说贯彻了微软Bug管理的核心思想。。。不过我觉得它的数据统计和报表的功能不尽如人意。而Mantis和BugZilla都是老牌的开源Bug管理工具了，但对我来说他们的安装和配置实在是太恼人了，在我还没有开始尝试使用他们之前，就放弃了（准确的说是，我只能用用online的demo）。而BugFree的代码更不能让人放心，似乎有绝对路径/相对路径的错误，安装过程还得自己去改它代码，搞死人啊。此外，它们似乎也都是使用内建的帐户管理系统，而我希望它能和AD集成。 在以前的公司里，我们常常用Bug管理工具管Task，而其实反过来也问题不大。想想我们究竟关注Bug管理工具的什么功能？除了基本的纪录每个Bug的各种属性信息以外，还需要支持方便的查询，邮件通知，还有统计报表，等等。对于开发/测试者来说，要能方便的纪录Bug信息，管理Bug生命周期；而对管理者来说，需要准确的统计数据以支持决策。Bug管理和Task管理在某种程度上是相当类似的，WSS的Task List的自定义能力又正好非常的强（没装过WSS的赶快装一个看看吧，WSS 3.0都快出来了），那么为什么一定要找一个专门为Bug管理定制的软件呢？我打算开始在项目里面尝试使用Task List管理Bug。就算还没能100%满足要求，但自定义的Task List可以作为一个起点，要知道WSS是支持二次开发的。如果你愿意，基于WSS搞一个集成了需求管理、缺陷管理等等的Product Studio出来也不是不可能。。。 ----- 看到Alex的回复，重新考虑了下，可能Discussion List确实比Task List更适于做Bug Tracker。。。...[阅读全文]