Richard

WPF中的MVVM模式
                                               周银辉

"设计模式"这样的话题似乎快被园子里的兄弟们写透了, 从简单的工厂到 MVC, MVP.  而关于MVVM似乎谈论得相对少些, 今天简单地说说. 值得声明的是: 这里仅仅谈论得是自己对别人发明的东西的一些理解, 可能有所偏误, 望理解. 另外, 搜索了一下,园子里 "clingingboy" 和 "高阳"大哥也谈到了这个模式, 大家不妨参考一下.
在阅读以下内容以前,建议你对这些内容有所了解: WPF, MVC, MVP, MVVM. 关于MVVM语法层面的内容请参考这里: http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

1, 前提
可以说MVVM是专为WPF打造的模式, 也可以说MVVM仅仅是MVC的一个变种, 但无论如何, 就实践而言, 如果你或你的团队没有使用"Binding"的习惯, 那么研究MVVM就没有多大意义.
另外,个人觉得, 使用Command以及打造一种合理的简化的方式去使用Command也与使用Binding一样重要.

2, 诞生
为了解决现实世界中的问题,我们需要将现实世界中的事物加以抽象, 然后得到了Domain Object, 无论贫血的还是富血的, 我们都可以简单地把他们归结为"由现实世界抽象出来的模型", 也就是我们的model, 也就M-V-VM中的"M".
但其无法与我们的用户进行交互, 所以, 我们需要为其创建一个界面(视图, View), 该视图可以与用户输入设备进行交互, 这很棒, 但问题是如何将View与我们的model关联起来? Binding便可以发挥作用了, 比如视图上的某一个文本框中的文本和Model中的"用户名"关联起来, 用户便可以通过操作该文本框来访问和修改Model的"用户名"了.
这是极其简单的情况, 但实际编程时我们发现, Model中的属性(与方法)往往不那么容易与View中的界面控件关联起来, 比如, "类型不匹配": 界面控件所需要的类型与模型中属性提高的类型不匹配. "需要额外操作": 模型中的数据需要经过一些额外的处理才能传给视图,反之亦然.  此时, 我们意识到View似乎需要一个"Helper"类来处理一些额外工作.
这个helper所包含的代码可以放在除了Model外的很多地方(我们现在不考虑贫血富血之类的争论), 比如View中, 记得自己刚学习窗体程序开发时就是这么干的, 将绝大多数处理逻辑放在那个所谓的CodeBehind中. 后来,正如大家在各种设计模式书籍中所看到的一样,为了将View和Model剥离开来,实现view可替换(比如你可以讲自己精心设计的软件同时运行于窗体程序,Web甚至Mobile上), 便有了MVC. 有了MVC以后似乎就开始滋生M-V-XXX之类的争论与变种模型, 比如MVP以及这里的MVVM,甚至MVP也有着Supervising Controller与Presentation Model两种方式. 但主要围绕两个问题,一是model与view之间的关系, 完全隔离的?单向的还是双向的? 二是这个"XXX"需要完成哪些功能,简单流程调度?复杂规则处理? OK,这些争论都没有关系, 是否采用某种模式取决于你的开发所处的环境(比如语言特性,框架特性)以及你的业务特性以及所面临的主要变化点等等.
但与MVC,MVP所不同的是,MVVM的引入不仅仅是技术上的原因(解除耦合应对变化等老生常谈),另外一个很大原因是:软件团队开发方式的改变.如果你做过一段时间的WPF项目开发的话,你可能会有比较明显的感觉:在View层打造上,如何分配程序员和美工的工作.在继续阅读之前,大家可以看看我以前的一篇文章"在UI Designer与Developer之间". 以前我们团队采用的便是"集成模式", 我便兼职了其中的"Integrator"角色.这还不错.但说实在的,这仅仅是一个在特殊情况下不得已而为之的暂时方案,所以我们付出了很大的努力开始转向"收割模式"了,要转向这个模式,至少需要两个基本条件:
(1)你拥有能够熟练运用Blend等工具能为程序员输出XAML的美工, 他专注于纯粹的UI/UE, 另外他还必须具有一定的"程序员"思维.以便输出的东西能很好地作为程序的一部分而运转起来,而不是仅仅"看上去"是那样的.
(2)你需要能够脱离View层但仍能编写出高质量代码的程序员.
幸运的是, 我们在努力创造条件1,并取得了很好的效果.(你可以招一个具有Flash脚本编写经验的并且有极大的学习热情的美工人员, 并对他进行Blend的相关培训). 而MVVM模式为我们实现第二个条件提供了极大的便利. 为什么MVC/MVP模式不行而MVVM可以呢? 很简单, 在MVC和MVP模式中, View层都具有很多代码逻辑, 开发View层的是程序员, 虽然UI/UE团队会做很多工作, 但这个层的"实现者"仍然是程序员. 在以前的开发中,其工作得很好, 而在WPF开发中程序员对View层的展现显得力不从心了,美工(指符合上面条件1的美工)虽然很擅长, 但他会说"可惜我不会程序".于是, 我们需要一种方式将View层的代码逻辑抽取出来,并View层很纯粹以便完全让美工去打造它.相应地, 需要将View层的相应逻辑抽取到一个代码层上,以便让程序员专注在这里.
回想一下, 我们只所以要在View(Xaml)背后写一些代码(C#), 无非是想传递一些数据以及传递数据时的数据的处理或在用户与界面控件进行交互时执行一些操作, 最简单的例子是在MVC中当界面发生交互时View去调用Controler中的某个方法, 以便将该操作的相应"指示"传递到"后台"去. 在以前的技术中, 这样的"衔接性"的代码是必须的. 而在WPF中, 则可以通过另外的技术来进行层与层之间的"衔接", 这就是"Binding" 和"Command", 以及稍后我们会提到的"AttachBehavior". 通过Binding, 我们可以实现数据的传递; 通过Command, 我们可以实现操作的调用.(AttachBehavior的作用稍后再谈). Binding和Command是可以写在XAML中的, 这样看来XAML后面对于的CS文件可以被完全抛弃或不予理会了. 这样的XAML文件正是美工所需要的. 而这些对于Binding以及Command的定义描述以及其他相关信息的代码应该放在那里呢, 当然不是View, 更不是Model, 是"ViewModel". ViewModel是为这个View所量身定制的, 它包含了Binding是所需的相关信息,比如Converter以及为View的Binding提供DataContext, 它包含了Command的定义以便View层可以直接使用, 另外,它还是一个变种的Controler, 它得负责业务流程的调度.
于是, 便有了这副图, 然后, 正如"时势造英雄"所言, MVVM就诞生了.

3, ViewModel 与 单元测试
如果你是一名正在使用MVVM模式打造软件的程序员, 那么我劝你尽快忘掉View. 你所面对的是这样一个模式"UnitTest-ViewModel-Model"(这并非一个模式, 仅仅是我为阐述观点而暂时如此表述的).
记得曾经有一个Model-View-AbstractView模式, 而MVVM中的VM实际也是一个AbstractView: the abstraction of view. 它是一个抽象的View, 具有一个View的灵魂,而不具备相应的可视化控件而已. 所以对于程序员而已, 打造这样一个抽象的VM就可以认为是完成View层的打造了.而当美工完成无数控件组成的实际的View后, 我们就可以用Binding和Command这样的黏合剂将这个抽象的View和实际的View黏合在一起了.
那么在黏合之前, 我们怎么知道自己的VM是否正常工作呢? 单元测试!
在说明对于ViewModel进行单元测试的重要性之前, 送给大家一句话: "View and Unit Test are just two different types of ViewModel consumers" (Josh Smith). 如果我们将ViewModel看作生产者, 那么View和Unit Test都是具有同等地位的消费者而已. 并且UnitTest相比于View而言具备更大的消费能力. 或者你可以简单的认为View也仅仅是一种不太推荐的测试方式而已. 所以要实施好这个模式, 那么对ViewModel的单元测试就是必须的了,并且这个测试要不依赖于任何UI控件. (那么不是不对应ViewModel的开发是不是就应该通过测试来驱动了?TDD?)

4, AttachBehavior
一般情况下利用Command, Binding, AttachProperty等WPF特性, View和ViewModel之间能配合工作得很好.  假设我们有一个Button, 当该Button被点击的时候我们要完成一些操作, 很简单, 将该操作封装成一个Command并绑定到该Button上就可以了, 但如果我们要在Button被Load的时候执行另外一些操作呢?  由于Button没有直接被Load事件所触发的Command, 所以不能使用Command了. 不能直接将Load事件处理器写在Button所在的Xaml所对应的CS文件里, 这和我们刚才对MVVM的设计是相矛盾的. 一个不太好的方案是继承一下Button, 并撰写一个由Load所触发的Command, 这可行, 但明显不好. 正如一个控件没有某个属性并且在不继承的情况下而采用AttachProperty一样, 我们可以采用AttachBehavior. AttachBehavior不是WPF特性, 它仅仅是一个最佳实践, 一个Pattern. 关于AttachBehavior语法如何书写, 请参考 : http://www.codeproject.com/KB/WPF/AttachedBehaviors.aspx

最近在学习WPF，看了周银辉的博客深有感触，摘录如下：

 

谈谈我理解的WPF团队模型——在UI Designer与Developer之间
                           周银辉

1，旧的模式已经不再适用

首先看看如果我们将旧的（.net3.o之前）模式直接引入到WPF中将是如何工作的。无论采用什么样的沟通方式，我们需要Developer和UI Designer之间对软件的功能达成共识，然后我们可以得到当前界面的大体Layout，OK，这个被验证和确定以后，UI Designer会细化他的工作，提出一些她的一些新观念，软件UI风格，然后细化出一张张的效果图（利用PhotoShop，PowerPoint等等)。接下来，Developer所要做的事情是：“照葫芦画瓢”，照着UI Designer的效果图，再Blend中将其模拟出来，以便形成可供程序使用的XAML。我们可以将这个过程称之为Translate（将效果图（PNG，Jpg）翻译成XAML）。

这所带来的问题：

(1)UI Designer的大部分“产出”的丢失，我们知道UI Designer除了告诉我们UI应该是怎样来展现以外，其设计过程中的大部分作品被抛弃掉了（比如设计了很长时间才做得很漂亮得一个按钮图片），这是由于其产出不能直接用到我们的Project中（我们要得是XAML而不是PNG,Jpg）。到最后UI Designer那边好像仅仅给我们提供了很多idea，而没有实质性的东西输出给我们以便用于我们的的Project.

(2)Developer这边“费力不讨好”。所谓“费力”指的是就大多数Developer而言本身就不擅长绘图（即便您有Blend这类傻瓜式的工具），所以你很难得再Blend中将美工那边提供的图形完全模拟出来，所以，Designer那边有意见了，您将人家美丽的艺术品转化得一团糟糕了。即便某某很牛，模拟出来了。仍然“不讨好”，因为这是重复劳动，Developer再Blend中做得这部分工作事实上美工再Photoshop（或其它）中已经做过一次了。

一个可能得疑问是：为什么不让UI Designer们再Expression Blend或Expression Design中工作呢？先说在Expression Blend中工作，除了培训成本（我想这个培训成本应该是相当高的）以外，就大多数UI Design团队而言面临的最严重的问题是：他们没有软件开发的观念和知识，无法将他们融和到开发流程中来，如果他们负责Blend这块的话，他们的一举一动将直接影响软件的性能和功能。比如他们不会按照Developer的观念来合理组织资源，他们不会考虑XAML代码对性能的影响，没有模块话的观念，不会顾忌软件的可维护性，稳定性。他们只会关心“这样的界面简直太漂亮太好用啦”。那么结果可想而知。再说Expression Design，事实上这是可行的，如果老板愿意出这部分培训费用和培训时间以及UI Designer乐于使用新工具的话。

2，新的模式有那些？

新的模式有好几种，这取决于团队中成员的技能和职责，但我比较推荐的有两种。

(1)集成模式

从WPF角度看，团队中除了UI Designer和Developer以外，我们再引入一个新的角色Integrator。首先看看他们各自的职责：UI Designer的职责保持不变，但我们稍稍改变一下她的“输出”，其除了输出各种idea，布局图，效果图等等之外，其还将为我们输出其它所有的图形（比如一个漂亮的按钮），但是以XAML的形式（这会用到一些插件或小工具，你可以在这里找到http://www.cnblogs.com/zhouyinhui/archive/2007/12/08/987928.html）。请注意，其输出的是一些松散的XAML零部件，仅仅描述了图形，没有Style，Template，Trigger，Resource等概念。这样UI Designer既不会改变惯有的工作方式，又可以专注与图形和用户体验。而Developer的职责也保持不变，其专注于后台逻辑，但放弃对界面的所有权，其是C＃（或其它）的拥有者。而Integrator将致力于他们两者之间的结合，其负责将从UI Designer那里得到的松散的XAML按照软件开发者的观念在Blend中组合成真正的项目中的零部件，比如其将负责Template，Style，Animation以及界面的模块化，资源的组织，考虑其可维护性，稳定性，对性能的影响等等，其是XAML与Blend的拥有者。

这有一些明显的好处：

(i)                  没让成员做不擅长的事。在旧模式中，让Developer在Blend中绘制出艺术品或者让UI Designer按照开发者的观念来管理Blend端显然是强人所难，并且这也会分散他们的精力甚至带来抱怨。但目前的模式将这些负担转移出去了。

(ii)                避免了重复劳动。旧模式中，Developer来“翻译”UI Designer的成果的劳动是重复和痛苦的。而当前模式中图形的XAML直接来自于UI Designer。我们需要做的仅仅是整合。

(iii)               避免了实际“翻译”出来的UI与设计时的UI的不一致。两者差距有多大完全取决于Developer的“翻译”能力，但往往效果时不理想的，以至于UI Designer觉得自己的艺术品被扭曲了。

(iv)              有人专注于Blend端，那么软件的表现层端质量将更高，更容易维护。

(2)收割模式

从WPF角度来看，这个模式中只有两个角色: UI Designer与Developer。这个模式对UI Designer的要求较高，其需要能熟练使用Blend来创造一些成品供Developer“收割”。比如我们需要一个漂亮的按钮，那么UI Desinger直接输出给我们该按钮的Style。其甚至可以输出其它更复杂的东西，比如UserControl（不可能是CustomControl，因为他们不会写程序逻辑，除非和Developer合作）。他们的工作是在解决方案中的某个辅助项目中完成了，而负责软件的真正表现的Blend端由Developer来负责，因为这里需要考虑很多软件开发的东西。

该模式同样拥有集成模式的各种好处并且与集成模式相比，UI Designer更加融入到了项目开发过程中，但对UI Designer的要求较高。

其它一些建议：合理地整合Blend端，如果发现XAML文件过大就模块化。保持UI项目始终能用Blend打开，否则将导致团队中某些角色出局或工作起来很麻烦。别让界面和逻辑耦合在一起，如果发现逻辑对界面元素引用过多，那么可能在Binding，Trigger，Resource等方面做得不够好。另外，相比之下，我更推荐第一种模式，我在这种模式下工作了不短时间，Integrator是我的职责之一。

 

1. 更加全面地用Google搜索的最好方式是点击高级搜索。
2. 它可以让你搜索更加精准的词组，“所有词组”或者是适当的搜索框里输入词组的某一个特定关键词。
3. 在高级搜索里你依然可以自定义在一张页面上展示多少个搜索结果，你所寻找的信息语言和文件格式。
4. “搜索以下网站或网域”可以让你通过输入一个顶级域名（如.co.uk）来限定搜索结果。
5. 你也可以点击“日期、使用权限、数字范围和更多”的链接以获取更高级的功能。（Google中文直接分条在页面展示。）
6. 保存设置，这些高级功能大多也可以在Google首页的搜索框中通过命令行参数来实现
7. Google的主要搜索可以无形地用布尔结构“AND”来结合。你当输入smoke fire - 它表示寻找smoke AND fire.
8. 要让Google搜索Smoke 或者fire，只需要输入smoke OR fire.
9. 你也可以用 | 来代替OR。如：smoke | fire.
10. 像AND 和 OR 这样的布尔结构对大小写非常敏感。他们必须是全部大写。
11. 搜索专有名词，然后输入用括号括住的一个或者几个关键词。比如water (smoke OR fire)
12. 寻找短语，可以把它们放在引号里。比如："there’s no smoke without fire"。
13. 同义搜索来寻找那些类似的信息，只须在你的关键词臆加一根波浪线，比如：~eggplant.
14. 用减号来排除关键词，如：new pram -ebay  可以让搜索结果排除来自Ebay的婴儿车信息。
15. 像 I, and, then ,if 这类普通词语是要被Google 忽略的。他们被称作停滞词语。
16. 而加号却可以让这些停滞词语给包含进来，比如：fish +and chips.
17. 如果一个停滞词语被包含在那些作为短语的引用标记中间的句子中时，这些词语是被Google允许的。
18. 你也可以要求Google进行简省搜索，试一下：Christopher Columbus discovered *
19. 用数字范围功能来搜索数字范围。例如：搜索价位在300英到500英磅之间的索尼电视可以用以下字串：Sony TV £300..£500。
20. 通过高级搜索Google认可13种主要文件格式，其中包括Office, Lotus, PostScript, Shockwave Flash 和text。
21. 搜索这些文件只需直接使用修饰符 filetype:[文件扩展名]。例如：soccer filetype:pdf.
22. 要排除整个文件格式，只需使用以前我们排除关键词时使用的相同布尔句法：橄榄球 -filetype:doc
23. 事实上，只要你的语法正确，你可以混合使用任何布尔搜索运算符。举个例子便是："sausage and mash" -onions filetype:doc
24. Google也有很多功能强大却隐藏着的搜索参数，例如“intitle” 仅仅只会搜索网页标题（titles）.你可以用这个例子试一试：intitle:网页设计
25. 如果你只是寻找文件而不是网页，只需用index of 代替intitle:参数。它可以帮助你寻找网络和FTP目录。
26. inurl这个修饰语只会搜索网页的网址，不妨用这个例子试一试 inurl:spices
27. 通过 inurl:vien/view.shtml 你可以找到在线的网络摄像头。
28. inanchor这个修饰语非常特别，它仅仅只会寻找那些作为超链接的文本。
29. 想知道有多少链接指向一个网站。可以试试这个语法：link:网址 - 比如link:www.mozilla.org
30. 同样的，你也可以通过 related:修饰语来找到Google认为相似的内容。比如: related:www.microsoft.com
31. info:site_name 这个修饰语可以返回关于某特定页面的信息。
32. 同样的，在普通搜索后点击"相似网页"可以链接到Google认为相似的页面结果。
33. 如果只想搜索某一个风址里的内容，可能用site: 来实现，比如说search tips site:www.techradar.com.
34. 上述技巧通过像www.dmoz.org这样的目录网站并动态地生成网址。
35. 也可直接进入Google Directory这样的人工挑选出来的数量有限的数据库网站，网址是www.direcory.google.com。
36. intitle和inurl这样的布尔运算符像OR一样在Google Directory中同样适用。
37. 当你用Google图片搜索时，用site:的修饰语可以只搜索某一个网站内的图片，比如 dvd recorder site:www.amazon.co.uk。
38. 同样的，用"site:.com"只会返回带有.com域名后缀网站里的结果。
39. Google新闻（news.google.com）有他自己的布尔运算符。例如“intext” 只会从一条新闻的主体内容里查询结果。
40. 在Google新闻里如果你用“source:”这个运算符，你可以得到特定的新闻存档。比如：heather mills source:daily_mail
41. 通过"location:"过滤器你可以等到特定国家的新闻，比如 location:uk
42. 同样的Google博客搜索（blogsearch.google.com）也有它自己的句法。你可以搜索某篇日志的标题，比如 "inblogtitle:<keword>"
43. Google的普通搜索也可以确实也可以得到精确的结果，不如用"movie:<name of film>" 来寻找电影评论。
44. “film:”修饰语效果也一样。
45. 在搜索框里输入上映时间，Google会提示你提交你的邮编，然后Google就会告诉你什么时候什么地方将会有好戏上演。
46. 如果想要一个专门的电影搜索页面，可以去www.google.co.uk/movies
47. 如果你圈选了“记住地点”后，下次你查询电影放映时间只需要输入电影名字就够了。
48. Google确实在电影方面的搜索上下了些功夫。比如在搜索框中输入“director:<电影名>”你将得到什么结果？你肯定猜到了吧。
49. 如果想得到演员名单，如需输入“cast:name_of_film”
50. 在乐队名、歌曲名或者专辑名前加上“music:”可以得到相关的音乐信息和评论。
51. 如果你在搜索框里输入“weather London”便可以得到伦敦最近四天完整的天气预报。
52. Google也内置了词典，在搜索框里用"define:the_word"试试。
53. Goolge保存了网站过去的内容。你可以直接搜索某个页面在Google服务器里的缓存，相关句法是“keyword cache:site_url”
54. 相应的，直接在搜索框里输入“cache:site_url”可以直接进入缓存页面。
55. 如果你手边没有计算器，只要记住Google同样内置了这么一个功能。输入“12*15”然后点击搜索试试。
56. Google的内置计算器不但可以转换尺寸还可以理解自然语言。搜索一下“14 stones in kilos”
57. 汇率转换也同样适用，试试“200 pounds in euros”
58. 如果你知道某货币的代码，将得到更加可靠的结果，例如"200 GBR in EUR"
59. 温度呢？Google也没有放过，输入“98 f to c”便可以把华氏转换为摄氏。
60. 想知道Google到底有多聪明呢？输入“2476 in roman numerals”然后点击“搜索”就知道了。
61. 你也可以保存你的Google使用习惯偏好，只需要在www.google.com/account上注册一个帐号便可。
62. 一旦有了Google帐号，不旦可以免费获得一个Gmail帐号，最主要的是可以畅通无阻地遨游于Google的世界。
63. 登陆你的Google帐户，通过“iGoogle”你还可以个性化你的Google主页。
64. 在“iGoogle”上点击”Add a Tab”来添加多个内容模块，Google会根据你添加的甩有模块来自适应整个页面。
65. “iGoogle”允许你为主页更换模板，点击”Select Theme”便可改变现有的默认主题。
66. 有一些”iGoogle”主题会随着时间的改变而改变，比如”Sweet Dreams”就是一个随着白天到夜晚的更迭而改变的一款主题。
67. 点击”Try something new” 下面的”More” 就可以看到一个更加完整的Google网站列表和一些新的功能。
68. “Custom Search”帮助你为你自己的网站建立一个Google牌的搜索引擎。
69. 另外，那张列表还忘掉了一个很有用的服务“Personalised Search”，不过你可以通过访问www.google.com/psearch来使用它。（一个保存你搜索记录的服务——译者注）
70. 这个页面列出了你最近的搜索，并按特定分类来区分他们，点击”pause” 就可以阻止Google记录你的搜索历史。
71. 点击”Trends”可以看到你最访问的网站，你最搜索最多的条目以及最常点击的链接。
72. 个性化搜索同样包括了一个书签服务，它帮助你在线保存书签并可以在任何地方获取他们。
73. 更方便的是，你可以在”iGoogle”上添加一个书签模块来添加或访问它们。
74. 你知道你还可以搜索Google返回的结果么？滑到搜索结果页面底部便可以找到那链接。
75. 在你的查询后面附加你的邮编便可以搜索本地信息。
76. 找地图？只需要在搜索关键词后面多写一个”map”，比如“Leeds map”
77. Google搜索图片（这里指直接在Google首页而不是Google Map页面，译者注）非常简单，只要你在关键词后而多写个“image”，你就会在搜索结果的顶部看到相关的图片结果。
78. 神奇的是Google图片搜索可以识别人脸，在浏览器地址栏搜索结果页面网址后面添加“&imgtype=face” 确定后Google会过滤掉所有不是人的图片。
79. 想关注股市行情？只需要在”stock:”后面填上公司的股票代码便可以得到从Google财经返回的结果。
80. 在Google的搜索框中输入航空公司或者航班号可以获得相关的航班信息。
81. 现在几点了？在地点前面加上“time”可以得到任务地方的时间。
82. 你也许已经注意到了在输入关键词时Google会交替提示你的拼写，那内置的拼写检查在起作用。
83. 你可以在关键词前加上”spell:”来直接调用Google的拼写检查功能。
84. 点击”I’m Feeling Lucky” （手气不错）可以直接访问关键词搜索第一个结果的网页。
85. 输入基于统计的查询关键词，比如population of Britain，在结果顶部Google会告诉你它的答案。
86. 如果你看到的搜索有非英文结果，点击”Translate this Page” 可以看到由Google帮你翻译的英文内容。
87. 你也可以搜索国外网站的内容，点击语言工具，然后选择你想要Google帮你翻译查询的国家。
88. 语言工具的另一个特色是可以帮你翻译一些可自由剪贴的文本字块。
89. 这里也有一个区域，你可以直接输入网址，并让Google翻译成你想要的语言。
90. 在“语言工具”链接上面你可以看到一个“使用偏好”的链接，这是一个包含了一些私密设置的页面。
91. 你可以明确地告诉Google你希望返回结果的语言，可根据你的喜好进行多选。
92. Google的安全搜索可以保护你免受色情内容的侵犯。你可以选择性的让过滤系统更加严格或者把它完全地关闭。
93. 在使用偏好里，你可以改变Google搜索单页显示结果的结果数，默认为10.
94. 你也可以设置为在新窗口打开Google的搜索结果。
95. 想知道他人在搜索的内容或者提高你自己网站的Pagerank值（Google自行开发的网页质量等级排名评估算法，Pagerank值越高的网页在搜索结果里越靠前，译者注）？去www.google.com/zeitgeist看看。
96. 另一个强大的实验性功能可以在www.google.com/trends找到，你可以知道哪些是热门搜索条目。
97. 在Google趋势搜索框里输入以逗号间隔的多个关键词，可以对比他们的搜索表现。
98. 想用克林贡语搜索？去www.google.com/intl/xx-klingon就可以了。
99. 也许你提线木偶里的瑞典厨师是你的榜样？点击www.google.com/intl/xx-bork看看。
100. 在搜索框里输入“answer to life, the universe and everything”，你肯定会被结果吓一跳。
101. Google还可以告诉你独角兽有多少只角，（够搞笑吧）。输入“number of horns on a unicorn”看看。

 

 

一路通

星期天下午从水果市场回家，远远地看到花卉园前面有些堵。又按惯性思考了一下：花卉园前面由于公交车站次多，很多公交车无法进站停车，只能停在公交站台附近的马路上，经常造成汽车缓行，一般情况下，慢慢开过2、3分钟就可以了。因此，没有改道，仍然向花卉园方向开，结果，平时4、5分钟的车程，足足走了近30分钟，才到红旗河沟转盘。汽车开过去才知道，有两块路段在开挖，难怪这么堵。

回家后第一件事情就是打开电脑，登上一路通的网站。看看那个路段是否堵塞？果然，一路通网站上那一路段的显示颜色为红色，我让计算机开着，是不是看看，一直持续到晚上8点钟，那个路段都飘红。

平时不管他们说得怎么天花乱坠，总有些担心：这玩意儿播报是否准确！而这方面又很难进行全面验证，从这次经历来看，虽然塞车让人感到不爽，至少一路通多少还是给了点信心。

周末的中午，和陈波、罗再谦、康涛在陶然古镇吃火锅。很自然的谈到了一路通。凭着半山，远眺高新区的建设工地一片繁忙，再看到几个创业青年的意气风发，大有“王侯将相，宁有种乎”的感触！

不能不说IT是一个神奇的产业，它造就了多少一夜崛起的神话，且不说丁磊、王志东、张朝阳等互联网的第一批掘金人。仅看近几年，从陈天桥借服务器、借带宽开始，到盛大的NASDA上市，直至中国首富，不过短短2年；开心网、土豆网等一系统服务的快速崛起无不印证着这一规律，而这些崛起的企业都有一个共同点：从草根开始。他们后面没有什么显赫的支撑，仅有的只是创业团队“王侯将相，宁有种乎”的胆气、智气和毅气。

江山倍有才人出，一代新人换旧人。祝愿和祝福陈波他们。

前两天的媒体对一路通（http://www.16tone.com/）是一路凯歌高唱，谈“畅通重庆”的助力者有之，谈“不同于传统的GPS导航”者亦有之。好像有了一路通，重庆就不再堵车了，司机上路就再也不烦心了似的。

实则不然，到底对重庆的交通状况的改善有多大帮助，要看有多少的使用者。点至公司所谓的“交通主动诱导系统”的关键在于用户知道并且要用。所谓的主动诱导只不过是比交通广播电台FM95.5的定时播报的播报频率要高些，非主要路段的拥堵情况播报的要全面一些。猛一听这个概念觉得很震撼，实则噱头的意味更重一些。而且交通路况的变化是瞬息万变的，等看完网站，再开车出发，在路上行进这一段时间过去，也许看网站时拥堵的路段已经疏通，而不堵的地方恰恰发生状况堵塞起来了。

真正的服务应该以内功练起，真正去分析客户的习惯，开发方便使用的功能，给客户实实在在的带来价值。与其关注媒体高调弹唱，不如实实在在的加强内功，以提高用户体验为主。目前的网站体验度不好，用户使用不方便，这些都是存在的问题，包括手机上的软件只支持诺基亚的部分手机，这些都有待提高。

帮点至写博客的第二天提批评意见似乎有点不合时宜，但这两天媒体的高调弹唱太多，说点反面意见，也算是另类的一种帮助吧。

。

 

     摘要: 2009年5月19日，对陈波他们来说应该是一个难忘的日子。经过几百天的艰辛，“一路通”网站http://www.16tone.com/终于开始正式上线了。18号的时候，陈波给我电话，请帮忙写点东西，主要是为了增加一些反向链接。我也没有多想就答应了，当天就在博客上面写了星期六去昆明的一个经历，很简略，在博客园的评论上，有人还指出这是个软文。 19号晚上，陈波又给我打电话，请我...  阅读全文

     摘要: 星期六要去昆明，11点的飞机。9点半从家里出发，一般情况下到重庆国际机场只需用20分钟，心想时间还是绰绰有余的。出门前登上了一路通（http://www.16tone.com）的网站,目前这个网站只支持重庆地区主城的路况播报。一看，机场高速上在尖山路段居然堵车，我想了想，觉得不太可能，周末机场高速怎么可能堵呢！还是开车走机场高速。开到尖山，傻了，居然真的堵了，后悔呀，该相信一路通的播报呀。心急如焚...  阅读全文