1. 从卖家出逃说起……

众所周知，在过去的一两年中，淘宝经历了一个大卖家集体出逃的时期。当时，淘宝长期以来所表现出的善变和趋利，让众多大卖家心里始终是十五个吊桶打水——七上八下，不知道哪天自己就成了某个政策调整的牺牲品。在大卖家看来，必须得要多筑几个窟，才能避免随时可能发生的倾覆之灾。于是，以“柠檬绿茶”为首的一批大卖家，都开始自建B2C门户之路。后话就不在这里说了，且回到正题上来。

这些问题的起因，是卖家对淘宝信任感的丧失。在这一点上，淘宝过去的善变无常和诸多潜规则，确实有失一个大平台的风度。因此，为了挽回卖家的信任，淘宝开始效仿华为，制定企业自己的宪法，这就是后来的“刘庄项目”。从制度上给卖家一个清晰可期的保障和承诺，无疑对重塑卖家信任有着非常重要的意义。

然而，博得了卖家的信任，就能长久的留住大卖家了么？不然！

2. 谁主沉浮？

卖家成长到了一定阶段后，必然希望能自己掌控更多的因素。淘宝作为一个平台，必须兼顾各方的利益，尤其是确保中小卖家的成长通道，这就势必会对大卖家产生一个不可避免和制约。虽然平台有着这样一些无法摆脱的根本原则，但同时也有着一些独立B2C网站难以具备的价值。商家通常都是以利益为最高原则的，所以，只要我们合理的控制前者，充分的强化后者，那么在去与留的岔路口，相信大卖家自己也会作出明智的选择。

在很多人看来，商户平台的建设是淘宝留住大卖家的核心手段。但事实上，商户平台所做的东西，却并非前面所说的平台价值所在。当然，这并非否定商户平台在大淘宝中的价值，恰恰相反，他们所做的东西，都是淘宝服务卖家的根基，是吸引卖家，尤其是大卖家加入淘宝所不可或缺的必要工作。这些工作，从卖家的角度来看，其实都并非“无法取代”的。独立网店的页面设计可以远超“店铺装修”的所能达到的效果；大商家长期使用的进销存系统，也远比淘宝提供的后台更易用；企业自己的数据分析团队，远比淘宝现阶段的数据报表更专业……

3. 平台之“网”

真正无法被取代的，必然是一个平台所独有的，无法被复制的核心价值。就像腾讯之所以能独霸中国互联网的半壁江山，正是依靠QQ无法被复制的核心价值——用户的好友圈子。对大淘宝而言，这个核心价值就体现在“买家关系”上。说的具体一点，包括信用、口碑、回头率等一系列衔接买卖家关系的要素。可以想象，离开了淘宝，卖家所积累的信用将从零开始；离开了淘宝，卖家所打造的口碑只能在常客眼中得到一点点保留；离开了淘宝，买家回头率只能重新依靠促销和服务一步步培养……

但今天的淘宝，其实还远无法达到上面所希望的效果。因为我们的信用体系，正在渐渐丧失他的公信力和价值；我们还没有一个可以帮助卖家打造百年老店的口碑机制；我们也缺乏一个为卖家体现类似线下店铺回头率的游戏规则。只有我们下大力气去强化和运营这些维系买卖家关系的核心要素，才能真正引导卖家群体参与其中，一起编织这个比蛛丝更坚固和更富韧性的买家关系之网，最终实现像Apple那样，让用户（卖家）甘愿在这个平台上“作茧自缚”。

第一阶段：网购市场的圈地时期

在网购诞生的初期，C2C市场可以说是一个冒险者的乐园。大部分在这个时期接触并开始网购的人，都能回想起那种“提心吊胆”的网购感受。那个时候，市场其实还很单纯，并没有多少投机的商家，尤其是在淘宝推出“担保交易”的背景下。

初期的C2C市场，需要的是高速的、爆发性的增长，网购相关的机制设计都围绕着这个中心展开，评价也不例外。“好中差评”机制虽然从现在的眼光来看，有着种种内在的缺陷，但在当时的历史条件下，它所强调的“量”的积累价值和对“好评率”的追求，承载了拉动和助推网购高速发展的关键作用。

第二阶段：爆发式增长后的巩固时期

当C2C网购经历了初期的爆发式增长后，市场规模已变得日渐庞大。这个时候，必然会出现各种各样的市场秩序搅局者。“好中差评”的方式，也开始逐渐暴露出其负面的问题：

• 首先，其过度的透明性，加上中差评有机会被改为好评，导致买家评价基本是“被劫持”，很难体现其客观性。最终也造成了大部分情况下，好评率的参考意义基本丧失。
• 其次，它所强调的“量”，直接引发了卖家成长的马太效应，这就是为什么不少新入的卖家甘冒被封店的风险，也不惜血本去刷信用。因为买信用就像买官一样，都是一次破费就可以长期坐收渔利的买卖。
• 最后，被严重扭曲的“好评率”，成了一个套在卖家脖子上，永远无法摆脱的枷锁，尤其是当淘宝在中期开放“中差评改好评”的规则后。“恶评攻击”、“职业差评师”，这些在卖家如履薄冰般维系“100%好评率”的心态下催生出的毒瘤，成了中小卖家成长之路上挥之不去的阴影。

在这个时期，我们需要一个相对更为理性与务实的评价机制，既能兼顾市场中大小卖家的公平竞争，又能有效评估卖家的服务质量和商品情况。在这样的历史背景下，百度有啊加入C2C网购的战场后，首先效仿了eBay的“Detailed Seller Rating（DSR）”机制。它让买家针对几个预设的维度打分，然后汇总所有买家的单次评分进行统计平均，得出商品及店铺在这些维度下的得分。这个机制后来也被淘宝、拍拍等其它C2C平台吸纳。它相对于“好中差评”的主要进步在于：不对双方绝对透明的评价过程、可上可下的浮动分值、适度隐藏的算法细节。它和核心在于将好中差评的累积式分数转变为浮动的百分制分数，从而使中小卖家的信用比拼门槛大幅度降低，并鼓励卖家提升商品质量和服务水平。

第三阶段：网购开始逐渐打入主流人群的购物渠道

当网购已经成为主流人群欣然接受并乐于使用的购物方式后，C2C相对于B2C，承受了更大的压力和考验。B2C凭借标准化的商品、承诺化的服务 和 完善的售后体系，开始显现出比C2C更明显的优势。这个时期，C2C想要生存下来，除了依靠B2C尚难涉足的非标准化商品外，必须花大力气整顿市场秩序。只有规范了市场，才能缩小在消费者心目中与B2C的品质差距。因此，评价在此时必须承担起真正依靠消费者的力量约束卖家并鞭策其提升服务和产品质量的重任。

DSR所带来的改变是显而易见的，它在一定程度上削弱了好中差评的影响力，并在一段时期内起到了很好的市场自发规范的效果。不过实施不久后，其隐含的问题也渐渐开始显现。

• 首先是它的百分制（或淘宝的5分制），对于广大消费者来说，存在着不确定的尺度理解差异。按照淘宝官方的引导文字，4分代表一个满意的交易，而5分则意味着“超出期望”。但实际上，受过去好中差评思维的惯性影响，绝大部分买家在作出DSR评价时，只要没有明显的不满，都习惯性的直接打5分。这就是为什么大家看到的DSR得分几乎都集中在4.7-4.9之间，虚高的分值基本起不到区分卖家的作用。
• 其次，这种纯粹数值化的评分，虽然也区分了一定的维度，但却仍旧没有很好的发挥出评价作为买家对卖家交易行为和商品状况的反馈作用。拿很多卖家的话来说，“我看到自己店铺DSR中服务的分值比别人低，但我已经很尽力了，不知道他们到底哪里比我做的好”。虽然耐心的卖家可以去细致的翻阅对比买家作出的文字评论，但面对动辄一个月数千单的竞争对手，恐怕要聘请一个专业的分析团队才能胜任了……
• 最后，数值化的评分，加上笼统的维度，让用户在表达评价意图时觉得很乏力，感觉自己的评价可能很难真正影响那些大卖家，在一定程度上打击了买家的评价主动性。你说写点文字评论吧，又太容易沉下去了，很难唤起其他买家的注意。

由此看来，DSR并没有很好的胜任它在C2C目前发展阶段作为评价机制所应起到的制约作用，我们迫切需要一个能解决上述问题的评价机制。在这里，且容我暂且跳过现阶段的解决方案，让我们先来展望一下C2C发展的下一阶段，需要什么样的评价机制。

第四阶段：成熟的网购市场，已成为人们主要购物方式

假定在一个已经相对成熟的C2C网购市场，我们可以期望95%以上的卖家都能很好的遵守这个市场的正常秩序，普通消费者在网购时通常都能得到满意的商品和服务。那么在这样一个背景下，评价机制的主要意义已经不再是规范和约束市场秩序了。那么它的价值应该如何得以更好的体现呢？让我们先来看看消费者的诉求。

就像人类社会的发展一样，在温饱问题尚未得到根本解决的时候，大家只想着吃上一顿饱饭，睡上一晚暖觉；当吃饱了，穿暖了，人们就会开始追求各种物质和精神上的享受，于是诞生了多元化的第三产业。网购也是一个道理，当市场秩序还在塑造和规范的过程中时，大部分消费者都担心的是会不会上当受骗，会不会在快递过程中损坏，会不会享受不到售后服务；而当这些担忧基本都已不复存在时，他们就会开始追求更高层次、更丰富的需求了。比如买护肤品希望得到“针对性推荐”、小件商品的“同城当日达”、特殊网络服务的“全程指导”…… 这就对卖家的多样化、定制化经营创造了土壤。从这个时期开始，C2C顶住了来自B2C持续的强力竞争后，其最大的核心竞争力终于开始崭露头角——那就是“个性化服务”。

因此，评价机制在这个时期的核心价值，就体现在帮助买卖双方就个性化服务的需求和提供牵线搭桥。一方面，引导有个性化经营思路的卖家打出自己的店铺特色，积累起独特的口碑；另一方面，帮助有个性化服务诉求的消费者准确的找到能满足其需求的店铺，提升客户满意度；最后，通过交易与评价，使双方就服务质量进行交流反馈，从而推动卖家进一步提升服务质量，打造更坚实的口碑。

当Guice和OSGi框架碰撞到一起时，就会遇到一些观念上的矛盾：OSGi的动态生命周期在Guice本身的静态绑定下无法发挥其应有的作用，而Dynamic Service也无法方便的与Guice对接。好在开源社区已经有人意识到这些问题，并为两者搭起了一座鹊桥，这个项目就是“Peaberry”。

这两天在捣腾Peaberry时，发现它的设计主要是针对静态绑定，在与Guice的JIT注入一起用时，却还差那么一两块砖，于是自己把它给砌上了，顺便分享出来与大家交流一下。

按照Peaberry的用户手册，静态绑定一个DS服务的写法是在Module.configure()中使用：（以LogService接口为例）

如果转为JIT注入，则必须提供一个相应的Provider类。虽然Peaberry.service(…).single()返回的正是一个Provider，但鉴于Java注解只能用字面类（Literal Class），所以这里需要包装一下。我的办法是定义一个抽象的公共Provider，用反射去识别派生类的具体泛型类型：

具体使用JitProvider的接口以如下形式声明：

这样，所有使用Foo服务的Bundle都完全实现了即需即用，不必再像过去那样在每一个用到该服务的Bundle的Activator中事先进行一遍Peaberry繁琐的bind配置。经此精简优化，Peaberry的易用性得到了明显的提升，使用起来也更加直觉化了。

如果你所连接的VPN网络本身是与Internet连通的，而且DNS也可解析外网的网址，由于AnyConnect会将VPN网络适配器的优先级提升到最高，因此远端的DNS配置会取代本地网络（例如家里的宽带网络）。如果你的本地网络和远程网络是同一接入线路，倒还感觉不到这之中的差别。但如果其中一个是电信线路，另一个是联通（网通）线路，你就会遇到一个很悲惨的状况：本地网络访问国内主要网站的速度会显著降低，因为DNS对大型网站CDN的解析结果是和你现有路由完全不同的线路，想象一下在你的联通（网通）宽带下访问电信线路的网站，那种感觉……

为了解决这个问题，我先后尝试了在注册表里静态调整适配器优先级、修改VPN适配器DNS配置等多种办法，但AnyConnect在每次连接时强制重置适配器配置和优先级的极端手段让我的大部分努力都付之东流。要不是公司网络只支持它家的VPN客户端，我真不想再看到这样一个流氓软件……

不得己，只好祭出最后的杀手锏，用批处理写了一个动态监视和修正DNS配置的脚本，放到任务计划中去自动执行。（眼看我的任务计划中已经塞了越来越多这类fix脚本，也只能留下一声叹息了……）废话不多说，直接上脚本：

anyconnect_vpn_dns_fix.bat

@echo off
set dns=127.0.0.1
:loop
netsh interface ip show dnsservers name="Cisco AnyConnect VPN Client Connection" | find "Cisco" > nul
if errorlevel 1 goto sleep

netsh interface ip show dnsservers name="Cisco AnyConnect VPN Client Connection" | find "%dns%" > nul
if errorlevel 1 goto fix

goto sleep

:fix
echo New Cisco AnyConnect VPN connection detected, apply the DNS fix...
netsh interface ip add dnsservers name="Cisco AnyConnect VPN Client Connection" address=%dns% index=1 validate=yes
goto sleep

:sleep
rem Sleep 10 seconds
ping -n 10 127.0.0.1 > nul
goto loop

在将这个脚本丢进任务计划之前，还有几点需要补充说明：

• 请将第二行的“127.0.0.1”改为你实际的宽带DNS服务器地址，比如路由器地址。
• 这个脚本需要提升的UAC权限，因此务必在计划任务中设置“使用最高权限运行”
• 为了消除丑陋的命令提示符窗口，建议使用hstart.exe来启动它，用“/wait /noconsole”参数

用了这个脚本后，你可能会面临一个新的问题——VPN所连网域的内部域名无法正常解析了，而是跳到ISP的“网址智能纠错”页面中去了。这其实并不是上述脚本本身的问题，因为主DNS（即宽带DNS）无法解析的域名，本应传递给次DNS（VPN DNS），但却不幸遭遇了又一个典型“中国特色”互联网的变态产物——DNS劫持。对于这个问题的解决之道，请关注我的下一篇Blog：《中国特色互联网的生存法则——DNS免疫篇》

我已经在这篇文章中涵盖了我关于这款相机中各种模式的思索。我甚至今天还更新过那篇文章，根据一个读者在邮件中的建议，增加了关于电影模式相关的部分。

不过，在那篇文章中，我涵盖了几乎所有的东西，并在我的学习和掌握过程中不断的附加补充，因此读起来可能会比较难跟上其中的逻辑。所以，我在这里再用简洁的方式介绍一下F70EXR的拍摄技术。

第一件事情：先调低一两档你的液晶屏亮度，这样通常可以让图像看起来像比较真实。但你还是经常需要通过回放中的缩放以确认关键局部的曝光程度，因为富士相机的固件没有提供这方面的辅助。

保持在以下3种主拍摄模式间用拨盘切换：

1. 在一般用途下用“程序自动曝光（P）”模式
· 图像尺寸设置为“M（500万像素）”。（译者注：选择1000万像素时，相机将使用更强的去噪处理，通常反而降低了画质）
· ISO设置为“自动 1600”。如果不需要拍摄人物，你可以尝试用“自动 800”甚至“自动 400”。但需要小心：连续拍摄时，应恰当的选择快门速度，以确保总体看来较高的拍摄成功率。
· 设置动态范围为“DR400”。

2. 在强烈的阳关下，使用“EXR – 高动态范围”模式
· 图像尺寸已经自动为你设置为“M”。（译者注：“EXR – 高动态范围”模式通过牺牲一半的像素换取更高的动态对比度）
· 设置动态范围为“DR800”，这是应对强烈阳光的关键。
· ISO虽然只能从三种“自动”中选择，但无论你选哪一种都不重要，因为这时相机实际上始终使用的是“ISO 200”。

3. 在演唱会或者为了获得特殊效果、长时间曝光、精细曝光时，使用“手动模式（M）”
· 图像尺寸设置为“M”。
· 设置适当的ISO。
· 设置光圈为最大，除非在正午拍摄或者需要放慢快门。
· 如果需要的话，设置一下快门。
· 对于演唱会，我喜欢用1/100s左右的快门速度，以捕捉乐队的动作。

下面说一下富士提供的几种胶片模拟模式。如果你希望自己进行后期处理，那么选择“标准模式（Provia）”。

尝试“柔和模式（Astia）”当你需要较为柔化的效果。但要小心，它的色调曲线比“标准模式（Provia）”更平直，所以在强烈的阳光下有损失细部色彩过渡的风险。

如果画面看起来让人昏昏欲睡，那么可以尝试“鲜艳模式（Velvia）”。但它的色调曲线更加陡直，会导致高亮照射及阴影遮挡下的部分完全丧失细节。这种模式可能对拍摄柔和多云天气下的鲜花比较有用。

学习和掌握使用“曝光补偿”，这对于取得良好的曝光效果至关重要。测量元件不可能有你那么聪明，不要总是简单的把一切参数都交给相机自动设置。建议阅读 约翰·肖 的《自然摄影野外指南》（译者注：中文全文翻译）和 布莱恩·彼得森 的《懂得曝光》（译者注：电驴上可以找到英文扫描版），这些将帮助你更透彻的理解曝光。另外还有Lumous Landscape上的《正确曝光》一文。

曝光补偿的一些技巧：

· 在夜晚拍摄灯光时，设置曝光补偿为“-1EV”。周围的黑暗会影响光线测量，从而导致画面中的一 切都被过度曝光，通常“-1EV”可以挽救你希望拍摄的灯光。但还是记得要在回放模式下放大察看，如果仍然感 觉有过度曝光，可以将曝光补偿设置到“-2EV”。

在一般的室外拍摄时，都设置为“-1/3EV”。一点点的曝光不足总好过在阳光下的显著过度曝光。在特别强烈的阳光下，我经常设置为“-2/3EV”。我那些正午在圣安东尼奥拍摄的照片大部分时候都是这样设置的。

不断试拍并在液晶屏上放大以确认是否有过度曝光造成的细节损失。

曝光补偿的奥妙就是如此~

2010.3.28 补充：一个叫格雷森的人曾在电子邮件中与我交流，为他只会简单按下快门的妻子找到一组最适合这个相机的普适参数，我作出了上面这些建议，并补充了一句：如果你真的不想折腾“曝光补偿”，那么我建议始终保持“-1/3EV”的设置。这将稍稍增加一点对强光的抵御和略微丰富一点色彩的饱和度。这是你在不想根据光线强弱调整曝光补偿的情况下最适宜的选择。

其它特殊模式。“强化主体对焦”：如果你喜欢的话，可以尝试，但我发现它很少奏效，即使成功，当它也明显影响了主体的边缘。“强化弱光拍摄”：这个我喜欢，因为它可以让你在手持条件下的微距拍摄获得更清晰的画面和更丰富的细节，只要你能真的稳稳握住相机，就像绷紧了手臂在抵抗什么那样。

其它的场景模式对我不是太有用，除了“文字模式”让我取得了一些满意的效果。在“文字模式”下，似乎对比度和清晰度都得到了充分的提升，使文本看起来更加清晰锐利。它同时也假定文字的背景一定是白色的，并依此调整白平衡。我也是在2010.3.28的最后一次更新中才发现这个聪明的招数。

请记住：本文中的设置适用于任何EXR系列相机，包括F70EXR，F80EXR，Z700EXR，F200EXR和S200EXR。

结合Google Wave API的Proxying-for，我们也可以自己实现匿名式交互，或者与其它身份系统集成（比如OpenID）。有时间的话，我会尝试做一个OpenID Proxy的Sample。

前不久，我在淘宝上买了一个50元左右的计量插座，可以监测即时功率、分时段用电量（最近1小时、1天、1月），最大功率2200W，夜光显示也很实用。适合用来评估家里各种用电设备的耗电情况，尤其是电脑。以下是初步测量的一些个人数据，供参考：

冰箱：运转功率70w，平均每天耗电0.6度
电脑（包括显示器）：200-230w，节能（显示器待机、华硕 EPU-6激活） 130w，待机（S3） 4w，关机 2w
音箱：空载 18w，关闭 18w（说明这个开关纯粹只是个mute……）
无线路由器（D-Link DIR-615）：6w
ADSL Modem：3.5w
电视机（老20吋）：约 50w，关机 2w
电热毯：66w
（待补完）

从收集的数据来看，和我原本的预期有些出入。总结下来：

· 冬天的主要耗电大户还是空调和电热水器。
· 冰箱虽然也不省电，但不如我想象的那么耗。
· 电脑的功率中，显示器占据了大约1/3（可能因为24″更耗电吧……），所以尽可能在系统的电源设置中包含“关闭显示器”。
· 音箱关机不关机的耗电量没差别，所以平时务必要断开电源。

另外，再提供一些节能的实用技巧：

· 调低显示器亮度，可显著节能（对笔记本尤其适用）
· 如果你的主机有节能功能（如华硕的EPU），请将其置为自动节能状态（空闲时，功耗可下降5-15W）。
· 通宵下载时，请配合实用DShutdown软件，自动在下载完成或网络拥塞时关机。（通过网卡流量监测）
· 热水器、加湿器等使用频率较高的用电器，可以考虑配备一个定时插座（机械式/数字式），合理节能。
· 冰箱冷藏室一般下层较上层更冷，所以合理放置冷藏的物品，可以不必将冰箱温度调的很低。
· 电脑周边最好在关机后也一并切断电源。如果有关闭插排电源的习惯最好，没有习惯的话，可以考虑用这种“智能插排”。

那么，在这样一个变革到来之前的暗夜，如何开发一款可跨UI体系的Symbian应用呢？这并非没有可能，但有着诸多的限制。如果你的应用能满足这些限制的话，那么完全可以成为真正意义上的跨UI体系的Symbian应用。

以我在2004年开发的FontRouter为例，它可以堪称一款具有代表意义的跨UI体系应用。从2004年到现在，它只发布过两个版本体系，一个适用于Symbian OS的6、7、8版本，另一个则适用于现今的Symbian OS 9.x，却可以用于目前所有已知的Symbian机型，包括最早期的Nokia 9210到最新的N97。之所以仍然出现了两个版本体系，并不是为不同的UI体系。做Symbian开发有一定时日的朋友应该都明白其中的原委，简而言之，Symbian OS 9是一个全新架构的OS版本，它甚至忍痛抛弃了对此前OS版本应用接口的二进制兼容性。因此，没有任何应用可以同时兼容Symbian OS 9前后的手机。由于FontRouter只使用到Open Font System接口，这是属于OS体系内的部分，与UI体系无关，因此无论是S60还是UIQ的手机，都可以无障碍的使用它。FontRouter最后一个版本发布时，S60 v5还未推出，但它却能很自然的兼容新的UI体系。对与即将到来的采用QT UI的Symbian^3，不出意外的话，也完全能够正常使用FontRouter。以前很多朋友问及为什么不给FontRouter编写一个配置程序，答案很简单，因为我希望继续保持它“无UI设计”的魅力！:)

当然，FontRouter只是一个很极端的例子，毕竟大部分称得上应用的程序，都不可避免的要与用户进行交互。那么如何才能实现包含用户交互的跨UI体系的应用呢？

对于开发者而言，有一个简单易行的办法，就是使用“Console API”，比如调用printf()和scanf()实现简单的交互。但这毕竟也不能作为一个应用的正式UI，那如何才能实现真正意义上的跨UI体系用户交互呢？

仍旧拿一个典型的例子来说明，比如一款“短信过滤软件”。这个应用有两个主要的用户交互：

（1）编辑过滤规则和行为
（2）让用户查看过滤的短信

对于第一个交互，我们可以采用这样的方式：软件安装时，事先在手机的联系人中创建一个分组——“短信黑名单”，并在其中创建一个示例联系人“XX商城”，其“电话号码”一栏即需要过滤的短信发送源号码。这样就直接利用了手机内置功能的UI为我们的应用提供了支撑。这样的设计不仅避免了引入应用UI，还能起到与手机操作习惯无缝集成的效果。比如用户收到一个新的垃圾短信，需要过滤发送源时，只需要直接从短信界面中创建一个联系人，并将其添加至“短信黑名单”分组即可，而不必像很多现有的短信过滤软件那样繁琐：进入到该应用中，创建一条规则，还得把短信源号码复制过来。而如果希望按字词过滤，则可以创建一个包含“备注”字段的联系人，并在该字段中填入希望过滤的字词。

同样的，第二个用户交互也可以很轻松的借助手机内置功能的UI。被黑名单过滤的短信可以直接移入一个特定的短信文件夹，比如“过滤的短信”。这样用户可以方便的直接从熟悉的短信界面中查看这些过滤的短信，而不必去学习和适应第三方应用的界面，其实也从一定角度改善了用户体验。

当然，直接借用内置功能的UI对新用户而言也有一个了解的过程，他很可能因为找不到这个新安装的应用图标而陷入困惑中。那么，我们其实可以采取一个简单方式引导用户，那就是在用户的短信收件箱中直接放入一条新彩信，包含一个简短而图文并茂的“快速入门”（最好在用户从收件箱删除该彩信后，再为用户在短信文件夹中保存一个备份）。这样，整个用户体验就完整无缺了~

或许你还是会坚持说，“短信过滤软件这个例子仍然无法代表更普遍的应用场景”，那么接下来我们再探讨一些更为通用的跨UI体系交互的手段：

（1）借助类短信的方式实现问答式交互。很典型的例子是移动运营商的短信服务号（比如10086），你可以通过发送约定的语法（以及可能的后续多次回复）到该服务号码完成功能的定制和修改等操作。应用程序也可以借鉴这种思路实现一个简单的配置交互，唯一不同的是，用户只需把该短信保存在草稿中，应用就可以提取该信息并通过在收件箱创建新信息完成问答式交互了。

（2）Widget方式。这应该是最有潜力的一种跨UI体系交互方式，但考虑到目前Widget并未被广泛支持且标准尚未统一，所以可能适用的机型并不算多（以Nokia新机型为主），也就失去了起跨UI体系的意义。

（3）借助Web UI。应用中集成一个微型的Web/WAP Server后台服务（可以直接采用Nokia Labs发布的Mobile Web Server），并在安装时创建一个应用入口的书签，提供基于XHTML/WML的UI。毕竟大部分的手机都含有基本的Web/WAP浏览器，所以理论上的通用性还是不错的。但并不是所有机型的浏览器都可以像Nokia那样方便的进入（待机界面长按“0”键），所以易用性上仍有些许障碍。

更多的思路和看法，欢迎各位前来发表你的见解！

“Google Buzz是Twitter杀手！”

这是大多数媒体最喜欢的炒作方式，又一个Killer App出现了，于是编辑们都兴奋了，又可以赚足眼球了。事实上，Google Buzz和Twitter总体来看并不是一个层面上的应用，还构不成真正意义上的Killer。一些冷静的分析还是看的比较清楚，Google Buzz其实主要针对的是FriendFeed，因为它们都是聚合平台，让不同源头的信息聚合在一起。Buzz相对于FriendFeed的最大进步在于，它除了聚合信息之外，还创造性的利用Social Graph来聚合人际关系。

当然，Google Buzz除了聚合功能外，自身也充当了一个简单的信息源，可以在Buzz上发表富媒体信息。但事实上，你有自己充分的选择权，完全可以保持原有的习惯，在WordPress上写Blog，在Twitter上唠叨几句，这些信息最终都会自动被汇总到Buzz中来。

“我们不需要又一个社交网络”

当你迫不及待的跑来Buzz上兴奋的吼了几句后，才意识到它和Twitter也没多少差，反而在这里找不到Twitter上那种“振臂一呼，Follower百应”的成就感了。没过多久，你就会逐渐淡忘掉Buzz。这是因为，你把Buzz当成了一个和Twitter、Facebook、MySpace一样的社交网络。“又一个新的SNS，我不得不又一次花费时间从头建立我的关系网络。”其实这不奇怪，不光是你，连Microsoft也这么认为。

本质上，Buzz并不想打造一个新的社交网络，恰恰相反，它的目的是推进一系列开放标准，使用户不必在各个SNS维护一个又一个彼此独立的关系网络，使人际关系得以重用和汇聚，进而构造起一个去中心化的Social Graph，不依附于某一个特定的SNS。

Buzz倡导运用XHTML Friends Network (XFN) 和 Friend of a Friend (FOAF) 挖掘和汇聚用户既有的关系网，实现SNS间的互操作性。如果各个开放SNS都能响应这一号召的话，那么将来我们就再也不用担心自己的人际关系被锁死在某个SNS中，甚至还可以借助新的SNS发现原有SNS中漏掉的好友。

“Buzz让信息的回复和评论更加破碎了”

这一点确实是目前不争的事实，因为无论你从Twitter往Buzz同步也好，还是打算反过来从Buzz发布到Twitter，你都得面对一个问题，回复和评论的不同步。你很可能因为只在Twitter上读消息而遗漏了Buzz里别人的评论，或许在习惯了Buzz后，又冷落了Twitter上的Followers。在Web应用越来越多的引入“聚合（Aggregation）”功能后，这个问题逐渐凸显出来。Google Buzz现在没有解决这个问题，但这只是因为目前的Buzz还尚不完整。Buzz的API文档中有一节“Coming Soon”，其中提到了Buzz未来对这一问题的解决之道——Salmon。

之所以现在没有推出Salmon支持，我猜想，一方面是由于这个规范尚处在Draft阶段，另一方面它无法从Google单方面实现，因为信息源和聚合者都必须遵从Salmon协议，才能完整的实现评论同步。这个事情倘若让任何一家其它互联网公司来推，可能都收效甚微，但由Google Buzz倡导，其影响力就不可同日而语了。因此，Google在完成Salmon的支持前，先放出Roadmap来，让大家都意识到Google开放的心态和坚定的决心，这样Salmon才有机会得到广泛的认可和支持。

所以，就如同Wave对大多数人来说也不过尔尔，只有当你透过API去洞察其背后所希望表达的真正意图后，才能深刻理解Google每一款产品的前瞻和愿景。在大多数人被Buzz的优雅与便捷所打动时，我更看重的是它将对整个SNS生态圈所产生的深远影响，和它在推动开放和标准化上的显著贡献。

Monday, 25th of January.

揭秘搜索引擎关键字过滤背后的实时审查系统 http://gfwrev.blogspot.com/2010/01/blog-post.html

淘宝电器城在走一个危险的模式，它通过集中展现抹杀店铺的个体品牌和特色服务，最终将竞争引向赤裸裸的价格战。淘宝上那些靠口碑经营所积累的店铺品牌，可能就此毁于一旦。

Tuesday, 26th of January.

Google Reader的新特性，Feed for any page: http://googlereader.blogspot.com/2010/01/follow-changes-to-any-website.html

看完了朋友推荐的《网瘾战争》，作为一个曾经的魔兽玩家，我能深切体会到这种对现实社会近乎绝望的悲愤呐喊。那一刻，我感动的忍不住落泪了……

Wednesday, 27th of January.

在Blog上有人留言说“我最近在重玩台服的軒網 那個轩网·异眼我找很久也找不到 請問可以給我嗎?” 一个网游能在关服数年后仍然拥有忠实的玩家，我想也只有轩辕剑网络版和WoW能做到吧……

RT @oasisfeng 网上看到有人说，研究增强Java的 Hot Swap就是一个dead end。难道最近苦无进展的我，也要陷进这个死胡同了……？//再感慨一下两个月前的感慨。当你以为攀上了顶峰时，却只看到一条被迷雾吞没的险道通往更高处……

不过我在攀登这座无尽之峰的山路中，沿途也收获了很多东西，一些将来无论踏足平川还是穿越激流时都能用得上的经验。

Thursday, 28th of January.

iPad大失所望，看来不用贱卖我的eBook了。

看来Google对自家Public DNS的短处也看的很清楚，并且在积极推动改善。 http://googlecode.blogspot.com/2010/01/proposal-to-extend-dns-protocol.html

原来Google App Engine已经悄悄支持泛域解析了！在GAE中配置域名，并在Apps里添加应用URL为*，然后修改DNS配置，加一个*的CNAME指向ghs.l.google.com.就可以使用任意二级域名访问GAE应用了。

目前真正可用的Google官方ghs只剩最后的一个幸存者了，如果你从某些渠道获得所谓的ghs IP，请务必小心，这些很可能只是一个反向代理（存在一定的安全隐患）。验明真身的方法是ping -a 这个IP，看域名是否隶属于1e100.net

Friday, 29th of January.

在新开张的Chromium-HTML5论坛上询问了Chrome支持Offline标准的计划，得到的答复是“It’s planned for Chrome 5. I think it’s going to ship in the next dev channel as well.”

估计差不多正好那时候可以完成tb.ly的HTML5离线功能的重构。

Saturday, 30th of January.

tb.ly开始测试二级域名跳转功能，淘宝店铺二级域名无需申请即可直接享受tb.ly同名二级域名。例如，输入nokia.tb.ly即可直接跳转至nokia.taobao.com。后续将推出基于店铺二级域名的店内商品专享短网址~

有别于tb.ly采用php编写的核心部分，目前的二级域名支持是用Google App Engine实现的，关于其中的实现细节以及GAE和php混搭的经验，我准备写一篇Blog来分享。

写完了这篇《在Google App Engine中使用泛域二级域名》，该吃饭去了。 http://blog.oasisfeng.com/2010/01/30/use-wildcard-domains-in-google-appengine/

http://www.squish.net/dnscheck/ 是我迄今为止见过的最为强大的DNS分析、检测工具。全路径解析跟踪对与诊断DNS记录的故障非常有帮助。

Sunday, 31st of January.

tb.ly为你提供超便捷的淘宝搜索：只需在浏览器地址栏输入“tb.ly?搜索关键字”即可带你直达搜索结果！现在就试试看： tb.ly?诺基亚E71

阔别十余年后，我又再次从浙江图书馆借来了这两本第一推动丛书中的《夸克与美洲豹》和《宇宙的琴弦》。抚摸着泛黄的书页，又想起初中时每天放学后在书店蹭书读的我，双腿站的发麻了都浑然不觉。

当年正是这套《第一推动丛书》让我一头扎进了科学的殿堂。前两个系列中的经典，我省吃俭用只买了《时间之箭》和《皇帝新脑》，其它很多本都是在书店蹭着读完的。后来许久没有关注，现在才知原来2004年又出了第三套。

Google开始在Docs和Sites服务中驱逐IE6！卸掉包袱，轻装上阵，只有做过前端的开发人员才能真切体会到Google这一决定背后的痛楚。http://is.gd/7pEQt

好消息呀~ Google Apps Script终于开放给标准版用户了！现在免费用户也可以用Server-Side JavaScript给Google Docs编写高度自由的扩展功能了！真是让人不禁浮想联翩~ http://is.gd/7pGBA

第一个想到的就是给我们的小饭桌账本(Google Spreadsheet)增加一个欠费提醒功能。哈哈哈~

Google Maps新版S60客户端的地标同步功能太方便了！今晚去普罗旺斯吃饭时就事先star了一下地标，从浙图出来直接打开Maps就找到地儿了~ 终于不用再很傻逼的从Google Maps里导出地标为Nokia格式，再传入手机了。

我现在用Live日历作为Google Calendar的桌面端呈现（这个还真有点讽刺……），不知各位推友是否有更方便易用的客户端推荐呢？