2008年11月23日星期日

Chinese Blogger Conference 2008

上个周末请了两天年假,回广州参加网志年会顺便回家。

第一天去到会场,就见到了LEMONedhidecloud,然后拿到了我的fail whale tee。接下来的session……其实我不知道session讲什么,我想大多数人都跟我一样不关心session讲什么,大家只是找个机会来聚会而已。中午跟Elliot Ng一起吃了午餐,并且拿了一件CNReviews的tee。下午的session也是不知道讲了什么,然后就是自助晚餐了和Punch Party了。

自助晚餐吃的是点心,虾饺和牛肉丸都不错,但是鸡翅就很难吃。接着Punch Party正是开始,第一位上台的是Carol,介绍什么是Punch Party。所谓的Punch Party,就是每位speaker有7分钟的时间,大概就是20个slide每个slide讲20秒的时间再多一点。当晚的Punch Party做得非常perfect,每一个人讲的话题都十分之吸引人,做到了Punch Party所强调的punch效果——让人感觉耳目一新。Carol作为第一个speaker,把全场的气氛都调动起来了。中间有介绍大陆吃喝玩乐之行有多艰险的工头坚,还有介绍胖卡如何把宅男配送到乡下的。最后一位导演先生,表演了7分钟的无声演讲——开头只说了一句,“由于接下来的内容都很晦涩,所以自动进行静音处理”,接着做了7分钟演讲的动作与口型,幻灯片翻了几页,但是没说过一个字。对于所有参加Punch Party的人来说,这样的结尾实在是太impressive了!

Punch Party的好处显而易见,能够在最短的时间内让你了解到一些你可能永远都接触不到的知识,同时给你无限的震撼感。不过我觉得Punch Party对speaker的要求也挺高,否则也不容易做好。而且作为organizer,一场Punch Party必须组合不同类型的speaker。

第二天的session稍微有趣一些,不过依然没怎么听,莫非年会的习俗就是把重点放在晚上?下午年会结束后大家就跟着Issac Mao到“友鸡会”吃了火锅,然后到北风的凸凹酒吧去聊天。我也不知道最后大家是什么时候才回家的,我快到凌晨时已经想睡觉了,于是就回家了。

2008年11月13日星期四

Live Mesh vs MobileMe

最近在用Live Mesh在多台计算机上同步文件,而之前一直用MobileMe同步联系人、日程等信息外加系统备份,真希望把这两个服务的好处叠加起来。

Live Mesh的好处是可以指定任何一个目录进行同步,而非指定一个同步目录然后要同步的东西必须放在里面,这方面就比MobileMe要好。而且Live Mesh的自动同步客户端同时兼容Windows和Mac,而MobileMe仅仅支持Mac同步。Live Mesh唯一不足就是没有版本控制,不过我想要是有版本控制占用的网络空间和流量开销就成倍增加了。

MobileMe给我印象最深刻的是,我重装了我的MacBook后一登录MobileMe帐号就帮我把整个System Preferences给恢复了。当然,联系人和日程信息也都恢复了,这是现在Live Mesh完全没覆盖到的功能。另外对iPhone的push服务也做得很好,更新什么信息都在Mac上进行就可以了,根本不用管它什么时候同步到iPhone上。

我觉得最好就是把这两种服务结合到一起,一个帐号一个服务就把这些都覆盖了,当然我不介意付费。在TechED MVP Dinner上,我和一位做Azure的Microsoft员工聊了一下,说最好Windows上的程序都遵守Vista的规范,把代码和数据分开存放,也就是数据都放到C:\ProgramData下面,这样Windows也就如同Linux一样能够轻松备份纯数据了。接着只要把数据同步到cloud上面,例如说是Azure上层的Live Mesh,重装机器后就能够把数据重新同步回来了,只要再装上应用程序就一切恢复原装了。

2008年11月10日星期一

开始翻译 Adobe AIR in Action

Prototype and Scriptaculous的翻译已经是一年前的事情了,翻译了半年,休息了大半年,现在继续接受翻译的工作。仍然是图灵引进的书,仍然是Manning的In Action系列,这次的是Adobe AIR in Action

其实AIR出来之前我就想去学习,很多很多技术都如此,不过翻译算是一个很好的学习过程,因为它逼着你认认真真把一本书读懂。这次着手翻译Adobe AIR in Action,我想半年后我也会熟悉AIR相关的技术。虽然我一直以来都对Flash和Flex没什么深入了解,但我希望这些知识反过来也能用到Silverlight开发上,结合两派的模式从而进化出一种更好的实践方法。

另外我还介绍了身边的朋友去翻译Practical Prototype and Script.aculolus。Manning即将发布Silverlight 2 in Action,如果图灵引进这本书的话,我也去看看是否能够参与翻译。

2008年11月5日星期三

以服务器端为中心的 ASP.NET AJAX 模式 (Part 2 - Control)

在上一篇文章当中,也就是《以服务器端为中心的 ASP.NET AJAX 模式 (Part 1 - Behavior)》,我们探讨了较为易用的Behavior模式。之所以说它较为易用,是因为它不涉及和原有Page处理流程的交互,即使访问网络也是访问独立的Web Service(包括Page上的[WebMethod]),因此和Page处理流程的设计绝对是正交的。但有时候我们需要的就是与Page处理流程的交互,这时我们不得不使用与服务器端逻辑紧耦合的Control了,这正是本次文章要讨论的内容。

在基本的 ASP.NET AJAX框架下,我们有三种方法来做基于Control的Ajax操作,它们分别是UpdatePanel、ICallbackEventHandler 和IScriptControl,下面我们就分别看看它们的特点和使用场景。

UpdatePanel

UpdatePanel 是与服务器端逻辑进行交互的多种方案中最易用的一个,甚至就不能称之为交互——你根本就不需要触及任何客户端逻辑。一个服务器端操作,经过 UpdatePanel的“劫持”,变成了一个客户端操作,而这个客户端操作又直接调用对应的服务器端操作,就这么简单。

如果用UpdatePanel来做一个带分支的选择对话框,那应该如何设计?思路可别跑到客户端的confirm方法上去,那可太绕了,或者说太不 ASP.NET AJAX了。用UpdatePanel,就应该坚持它的理念,一切客户端操作都是幻象,所有操作其实都是在服务器端进行的,包括选择对话框。要按 ASP.NET的思路来做,我会做一个选择对话框控件,它的实质可能是一个浮动层模拟的对话框,这属于实现细节,我们不用太关注。重点是,这个选择对话框的分支逻辑是完全在服务器端进行的,Async PostBack之后服务器端根据提交回来的数据决定如何触发事件。这样做整个分支选择的逻辑就是内嵌在Page处理流程当中的,不需要通过 Cookies或者Session来做数据的中转媒介,避免了Page处理流程与更大作用域中的数据的紧耦合。

UpdatePanel 适用于逻辑完全在服务器端的开发,并且我建议使用UpdatePanel时也就把所有逻辑放在服务器端,不要去写一些混合服务器端逻辑与客户端逻辑的代码。有人会说,你看老赵就很喜欢去动那个 Sys.Net.WebRequestExecutor来改变UpdatePanel的行为啊,但其实这属于分层设计思想中的一部分,他去动那个东西改变的也就是一个分层内的逻辑,只要层与层之间的接口不变,具体实现是可以按需设计的。但如果你用了UpdatePanel,同时又用Cookies或者 Session来传值,这就跨越了n个层,增加了不少耦合度。

ICallbackEventHandler

关于ICallbackEventHandler,我已经说过无数次了,重点还是你必须用Page处理流程来思考,只要你理解了Page处理流程,你就明白为什么ICallbackEventHandler在.NET Framework 2.0 Beta2中只有一个方法,而到了RTM要分拆成两个方法。具体可以参考《ASP.NET 2.0 ClientScript Callback》,我就不再重复了。

如果用 ICallbackEventHandler实现一个带分支的选择对话框,又如何做?和使用UpdatePanel的做法类似,我还是会做一个选择对话框控件,并且这个控件继承自ICallbackEventHandler。为这个控件编写JavaScript并实现 ICallbackEventHandler接口时,我会确保JavaScript对Callback给出正确的调用参数,并在接口方法的实现中接收这些参数然后触发正确的事件,就这么简单。和UpdatePanel一样,不要偏离了ICallbackEventHandler的设计思想,它的处理流程必须是合并到Page处理流程中的,你的控件也就必须这样设计。

至于在什么情况下选择 ICallbackEventHandler?如果你有一个轻量级的Ajax操作,但使用UpdatePanel更新整个区域的HTML开销很大的话,那么你可以考虑使用ICallbackEventHandler。当然,前提是你懂得控件开发和JavaScript。

IScriptControl

这是最复杂的解决方案了,你需要实现一个Control的两个副本——一个服务器端的,一个客户端的。有一部分逻辑,是要在客户端和服务器端重复实现两次的,而另外一部分逻辑,只需要在客户端或服务器端之中的一个实现一次。IScriptControl的经典例子,当然是ASP.NET AJAX自带的Timer控件。它的计时器是纯粹的客户端逻辑,然而Tick事件却在服务器端触发,Async PostBack成为了两者之间的桥梁。当然,就Control本身而言,它并不在乎PostBack是不是异步的,Tick事件只因PostBack而触发。

如果用IScriptControl来实现带分支的选择对话框,那将会和 ICallbackEventHandler的版本十分相似,唯一不同的地方就是它在客户端的逻辑会被封装为一个Sys.UI.Control的派生类,而ICallbackEventHandler的客户端逻辑往往是不封装的。这样的好处显而易见,那就是代码更容易维护了,并且客户端的Control可以同样可以加入事件支持,并提供和服务器端一样的代码分支事件。要知道在CTP阶段的Timer控件,其客户端版本Sys.Timer(而非RTM的 Sys.UI._Timer)是拥有tick事件的,和服务器端的Tick事件对应,只不过RTM取消了此项功能,因为ASP.NET AJAX 1.0的侧重点完全就是服务器端功能,客户端功能都被砍掉了。

什么情况下选用IScriptControl?如果你认为你的客户端逻辑应该封装为Sys.UI.Control的派生类,那就选择IScriptControl吧。

小结

我们分别讨论了三种通过Control实现Ajax调用的方案,并且一再强调了设计必须基于Page处理流程,不要在此流程之外增加不必要的复杂度和耦合度。值得一提的是,有很多人质疑为什么要在Web上提供这样一个支持分支的选择对话框功能,我的看法是这样的:既然客户端软件的流程会有此功能,那么 Web应用也有此功能就实在是太正常了,你删除blog post的时候问你一下是否确认删除,难道会有人觉得这个功能是设计错误?可能不同的只是表现形式而已,到底是confirm还是弹出层,甚至是一个专用的过渡页面。然而从用户体验的角度来说,这其实并不是最优的方案,多数时候用户删除就是确认删除,并不需要再问一次是否确认之类的愚蠢问题,但开发人员觉得用户错手删除的后果应当由用户自己承担,所以就做了这样一个对话框来推卸责任。真正好的用户体验是不需要确认的删除,但用户一定能够恢复,最好是按一下 Ctrl+Z就可以了,然而对于开发人员来说还是有很多操作是无法做到可恢复的,这时候除了显示对话框也没有更好的解决方案了。

最后,如果你喜欢我的文章,可以通过订阅feed来及时获得更新:

2008年11月4日星期二

软件安装时到底是否应该让用户选择路径

周末和Google UX Team的Junyu聊天,说到Google现在统一使用Google Installer安装软件了,点一下Web上面的链接就自动开始下载安装并运行,开头我还以为是Microsoft的ClickOnce呢。由于安装过程是全自动的,就如同Microsoft的ClickOnce和Adobe的AIR一样,所以是不允许用户选择安装路径的。

到底不让用户选择安装目标好不好?我们认为用户分为三个层次:
  1. 入门用户 - 购买的是品牌机,可能就一个C:和一个用于一键恢复的D:。这时候有什么好选择的呢?当然是不选择最好了。
  2. 熟练用户 - 经受过文件难以搜索或者忘记及时备份误删文件的种种磨难,学会了分门别类存放文件,自己有计划地把硬盘分成C:, D:, E:, F:四个盘。这时候你不满足他分类存放文件的习惯,他就会觉得很不爽了。
  3. 高级用户 - 经过无数次备份与重装后又在返璞归真,只用一个C:,安装时多数选项都直接next,不选择安装路径。
当然,这个分类主要是针对Windows用户,因为Windows的成长过程就是典型的“问题少年”——不停地向用户抛出各种问题,这个你选什么啊,那个你选什么啊。对于Linux和Mac用户来说,大家早已习惯了安装时一路next到底。Linux命令行安装甚至不用next,只是本地编译的话有时候需要yes一下。

事实上,我认为给用户那么多选择是没必要的,文件的搜索与备份应该通过其它手段来改进,而不是让用户手动归档。要求用户理解文件系统,就如同要求调用者理解API实现方式一样,其实是很不合理的。

对于现在的品牌机而言,只有一个C:,培养Windows用户好像Mac用户那样,什么都装到一个盘里面,这才是正确的发展道路。Mac有Spotlight,Windows Vista现在也有不错的磁盘索引与搜索系统,将来实现了WinFS或许能做得更好。

现在Windows缺的是一套好用的备份与迁移方案,问题来源于Windows软件都没有规范地把可执行代码与数据分离存放,所以没有一种统一的模式来备份软件数据。如果Windows上面的软件能够按照Vista的指引,把数据都存储到C:\ProgramData,那么接下来的事情就容易多了。况且我之前也说过了,这也是UAC的意义所在,有助于提高Windows的安全性。