林健的BLOG

　　看到黄博士的 Milestone 心得，我作为有三个月经验的用户也来扯几句吧。
　　国行。我是国行控，就和某些人是水果粉一样。不做亏心事，不用多解释。如今的国行不再像前几年那样有明显的硬件阉割，只是出于众所周知的原因没有预装 Google Mobile Services。这倒不是大碍，GMS 的安装包很容易得到，Google 的多数应用也可以从美版的 Android Market 免费下载（后文会讲）。国行 Milestone（准确的说法是 XT702）的优点之一在于预装了单机版全国地图导航软件，这在没有网络的环境下还是比较有用的。国内地图软件厂商的现状令人不满：只敢做 OEM 或捆绑，不肯做零售，于是非国行用户只能去找盗版了。当然，国行也把国内软件的一些糟粕带了进来，XT702 预装的某金融软件就有注册时自动吸费的陷阱。既是国行，为保证服务，我就暂不取得 root 了。要折腾，有智器 V5，XT702 还是拿来当生产工具而非劳动对象吧。
　　全键盘。全键盘的最大好处是便于使用终端。在多次外出作业时，XT702 都为我远程操作实验室服务器提供了便利。用好全键盘，就要多看说明书，不仅看中文版的，还要看看针对美（Droid）、加、英、港等各地市场版本的。它们内容并不完全相同，有些小诀窍只在特定的版本中出现。具体到键盘方面，[Menu] 和 [Search] 组合的快捷键、某些键长按或双击的功能等，都可以在说明书上找到。当然，Android 诞生许久，这些通用的快捷键早已有网民总结成文，懒得翻说明书就去搜索一下。不过也有些键盘诀窍是说明书中没有提及的，例如用 [Shift]+[Alt] 的组合键输入特殊符号，在使用终端时会用到。不过也别太一根筋，实在不会用实体键盘输入某个符号就用虚拟键盘吧。与键盘相关的自然是输入法了，无论是用实体键盘还是虚拟键盘，我都明显发觉五笔字型建立的是手指动作与汉字语义之间的映射，换到手机上来，效率立即下降，不如使用九键的拼音或笔划。
　　Android Market。国行当然需要手动安装 Android Market。Android Market 针对不同的国家，提供的应用范围有所不同，在中国大陆看不到 Kindle 等优秀的免费应用和所有的收费应用。有一些 faker 软件可以把机器伪装成美版，可那需要 root 权限。对于没有取得 root 的机器，最简单的办法就是插入一张国外的 SIM 卡。经实验，使用 AT&T 的 SIM 卡（无论服务是否可用）再连接 Wi-Fi 便可以下载或购买面向美国市场的应用，这种卡淘宝上很多，估计不少水果粉手上也有。如果要使用国内信用卡支付，可以把 Google Chechout 的信用卡所在地填为香港。资本家为了赚钱总会睁一只眼闭一只眼，像在 Kindle for Android 中购买（哪怕是免费的）电子书时，Amazon 也会“善意”地提醒用户去哪个网址把运送地址修改为支持该服务的国家。
　　最后说一点关系不太大的：隐私。前不久有人爆出了 UC 浏览器涉嫌侵犯用户隐私的问题，引发了不少人对 UC 产品，乃至是所有国产应用的不信任。事实上我对这件事并不十分在意。因为只要你使用手机，无论是否是智能机，都不可避免地存在隐私泄露的可能性。首先是运营商，它保存着你的所有通信记录，加之现今有关部门已要求手机实名登记，这使得运营商分析用户关系与用户行为易如反掌。中国移动并不避讳这个事实，听过他们在 Hadoop in China 上的报告就知道。这也是他们大搞飞信“QQ 化”、力推 139 社区的天然优势，不少已上线的应用充分证明了这一点。要想防止个人信息和人际关系泄露，除非停用手机。再者是运营商推广使用的 STK 卡，他们不但可以在其中写入程序，还可以对其进行“空中升级”。同学的一张动感地带 STK 卡不知开了什么业务，从某日起不断自动外发信息。这可不是手机中毒，因为即使把卡插到另一部非智能手机中还是照发不误；而他的手机插别人的卡则无妨。保不准下一步运营商会让 STK 卡做什么事。我猜可能是在手机上模仿 QQ、360 的“弹窗广告”：目前移动和联通的 STK 卡开机都有欢迎语，为什么不能用它来做“弹窗”呢？第三就是所谓的可信的服务提供商。有人给出过 Google、Yahoo!、Skype、Microsoft 等公司服务的“可信度”、“安全性”排名，我不以为然。从技术上说，成熟的商业服务的安全性不相上下；而他们作为竞争中的大佬，无所谓谁处于什么道德制高点。不要因为一两个案例下定论，还不就是半斤八两吗？我可以列举 Google 的若干罪状，但我依旧使用 Android 上的 GMS，这是“云时代”早期不得不做出的权衡。

注意：以下论断仅针对目前阶段（2009年7月4日）观察到的 Windows Live 和 Google 服务而言，只代表用户可见的现象，不说明其实现的本质；只说明现状，不代表未来可能的变化。

1. 有关使用非 Hotmail 邮箱注册 Windows Live ID 或使用非 Gmail 邮箱注册 Google Account

1.1.M. 使用原有（非 Hotmail）邮箱注册的 Windows Live ID 与在 Windows Live 网站通过注册 hotmail.com / live.com / live.cn / msn.com 等邮箱得到的 Windows Live ID 的使用范围基本相同，可以直接使用 Messenger、SkyDrive、Spaces、Photos 等服务，只是没有 Hotmail 邮箱（注意：微软启动 Live 战略以后，“Hotmail”的概念泛指一切 Windows Live 邮箱，不限于“hotmail.com”后缀的）。可以认为，通过注册 Hotmail 邮箱得到的 Windows Live ID 只是比用自己原有的邮箱注册的多得到了一个免费邮箱。如果用原有邮箱的 Windows Live ID 登录 Hotmail，会被告知需要开通 Hotmail。

1.1.G. 使用原有（非 Gmail）邮箱注册的 Google Account 与通过注册 gmail.com 邮箱得到的 Google Account 的使用范围基本相同，可以直接使用 Calendar、Documents、Reader、Groups 等服务，只是没有 Gmail 邮箱和 Gtalk 即时通信功能。如果用原有邮箱的 Google Account 登录 Gmail 或 Gtalk，会被告知需要开通 Gmail。

1.2.M. 在已登录原有邮箱注册的 Windows Live ID 后，根据提示开通 Hotmail，相当于重新注册了一个全新的 Windows Live ID，新账号可以使用所有 Windows Live 服务。这个 Windows Live ID 与原先的那个没有任何关联，可以分别独立使用。二者的 Messenger、SkyDrive、Spaces、Photos 等数据独立、互不干扰。

1.2.G. 在已登录原有邮箱注册的 Google Account 后，根据提示开通 Gmail，相当于在原有账号基础上增加了 Gmail 和 Gtalk 服务。这时账户的主 Email 地址自动修改为新的 Gmail 邮箱，原来的邮箱则变成了本账号的关联邮箱。关联邮箱可以同 Gmail 邮箱等价地登录 Google 的各项服务；在部分服务（如 Groups）中，可以使用关联邮箱作为自己的联系方式。但一旦注册了 Gmail，在 Google 的多数服务中就会用 Gmail 邮箱作为用户身份的唯一对外标识。在此之前用户创建的数据不受影响，只是账户名称变了。用户可以解除关联邮箱，解除之后旧数据不会丢失。但需要注意，如果解除关联邮箱之后重新手动关联，部分服务（如 Groups）无法使用新的关联邮箱。

2. 有关 Windows Live Admin Center 和 Google Apps 服务

2.1.M. 在 Windows Live Admin Center 使用自己的域名开通服务，旗下用户得到的服务与在 Windows Live 网站通过注册 Hotmail 邮箱得到的 Windows Live 服务完全一致。自己域名的邮箱就是 Windows Live ID，邮箱后台也是由 Hotmail 提供支持的，名称也叫“Hotmail”。这相当于在 Windows Live 原有的 hotmail.com、live.com、live.cn、msn.com 等域基础上，增加了用户自定义的一个域。

2.1.G. 在 Google Apps 使用自己的域名开通服务，旗下用户得到的服务与一般的 Google Account（无论使用原有邮箱或注册 Gmail）并不相同。自己域名的邮箱并不是可以登录 Google 各项服务的 Google Account，而是仅仅能登录本域的一个账号。Google Apps 相当于为企业、学校等用户群体提供一个适于内部使用的、相对独立于 Google 公共服务平台的“小 Google 服务平台”。在这个小平台中，提供有限的几项服务，如 Mail、Calendar、Documents、Sites、Gtalk 等，不包括 Reader、Groups 等。这些服务体现“内部”特色，在逻辑上与 Google 公共服务平台隔离，例如 Mail 被命名为“[你的域名] Mail”而非“Gmail”；但这并不影响域内用户与其它 Google 用户（包括其它域下的 Google Apps 用户）进行有限的互通，例如可以与跨域的 Gtalk 联系人聊天、共享 Documents 上的文档等。

2.2.M. 通过 Windows Live Admin Center 得到的自己域名的 Windows Live ID 与使用默认域名的 Windows Live ID 处于平行位置，功能等价，没有带来新问题。

2.2.G. 通过 Google Apps 得到的自己域名的账户并不是 Google Account，因此如果用户需要使用完整的 Google 服务，需要另外注册 Google Account。如果用户使用基于 Google Apps 的自己域名的邮箱注册 Google Account，可能带来一些微妙的问题：

2.2.G.1. 总体上说，这与 1.1.G、1.2.G 节所述的“使用原有（非 Gmail）邮箱注册的 Google Account”相似。

2.2.G.2. 对于 Documents 服务，用户分别拥有“Google 公共服务平台”和“本域服务平台”上的两套版本，分别在不同的界面使用不同的密码登录，数据独立。如果注册了 Gmail，则 Gmail（Mail）、Gtalk 服务也类似地维持两套版本。

2.2.G.3. 对于 Calendar、Sites 服务，本质上也有两套版本。如果没有注册 Gmail，则会因账户重名问题只能在优先注册的平台上使用，第二套版本无法启用；如果注册了 Gmail，则可以保证两个平台上拥有不同的账户名称，两套版本可以并存，数据独立。

2.2.G.4. 对于 Reader、Groups 等“本域服务平台”没有提供的服务，可以在“Google 公共服务平台”上使用，不存在多版本问题。

3. 总结及对创建个人 Windows Live / Google 统一账号的建议

3.1. Windows Live 对非原生邮箱账号的处理比 Google 更简单、更易于理解一些，区别一在能否直接使用即时通信工具，二在注册原生邮箱之后对原有账号的影响。我们可以通过单独注册 Gmail 邮箱的方法让 Google 实现类似 Windows Live 的“双账号”行为，但不能在 Windows Live 中为非原生邮箱账号添加额外的 Hotmail。

3.2. Windows Live Admin Center 与 Google Apps 是两个定位有所不同的产品，Windows Live Admin Center 强调用户域与 Windows Live 平台的相对统一，而 Google Apps 强调用户所属组织的独立性。它们的功能行为满足了不同类别用户的需求。

3.3. 对于企业、学校等有特殊需求的用户，或者仅偏好于 Windows Live / Google 一方的用户，以及对账号不在意或不愿公开的用户，不在本文讨论范畴之内。

3.4. 对于追求“使用并公开统一账号，访问 Windows Live / Google 服务”的用户，建议方案为：通过注册 Gmail 邮箱得到 Google Account，享受所有 Google 服务；然后使用这个邮箱注册 Windows Live ID，享受 Hotmail 之外的所有 Windows Live 服务。因为对外统一接口是 Gmail 邮箱，所以 Windows Live 上的联系人可以直接联系到用户，无须经过 Hotmail 邮箱。相反地，如果首先通过注册 Hotmail 邮箱得到 Windows Live ID，再用此邮箱注册 Google Account，则无法使用 Gmail 与 Gtalk。如果用户不在意 Gtalk，则此方案也可行；否则此方案不佳，因为如果用户在此基础上注册了 Gmail 或 Gtalk，多数 Google 服务中的用户账号会变化，不符合“统一账号”要求。

3.5. 对于追求“使用并公开统一的个性化（自己域名的）账号，访问 Windows Live / Google 服务”的用户，没有像上面那样完美的方案。建议的两种方案为：

3.5.1. 使用 Windows Live Admin Center 开通自己域名的邮箱，即可享用所有 Windows Live 功能。使用这个邮箱在 Google 注册账号，即可使用 Gmail、Gtalk 以外的几乎所有 Google 服务。如果用户不在意 Gtalk，则到此为止。如果用户在此基础上注册了 Gmail 或 Gtalk，多数 Google 服务中的用户账号会变化，不符合“统一账号”要求。不过用户也可以在 Google 之外使用自己的服务器搭建 Jabber 服务，与自己的域名绑定，现实与 Gtalk 的互通，但这提升了实现成本和技术难度。

3.5.2. 使用 Google Apps 开通自己域名的邮箱，即可享用部分 Google 服务（关键是有 Mail 和 Gtalk）；然后使用这个邮箱注册 Windows Live ID，享受 Hotmail 之外的所有 Windows Live 服务。再使用这个邮箱注册 Google Account，享受其它 Google 服务。注意不要开通 Gmail，原因同上，且此举是无法恢复原状的！此方案的缺点在于 2.2.G 节所述的部分服务双版本共存或双版本冲突的问题，使用时需要格外注意，防止混淆。

3.6 对于新启用统一账号的用户，3.4、3.5 节提出的方案可以在一定程度上满意其需求。但对于已经在不同平台上使用了不同账号的用户，迁移到新的统一账号上来却是不方便的。主要的问题是用户数据无法同步迁移。目前 Windows Live 和 Google 提供的关联邮箱功能，主要解决的只是多账号登录问题，没有太关注内容同步，这也许是它们下一步有必要努力的方向。

附录A. 我个人的统一账号迁移方案：基于 3.5.2 节方案，前两个步骤相同，但没有注册新的 Google Account 和 Gmail。访问 Google 服务仍然使用原来的 gmail.com 账号。主要的考虑是：

A.1. 我原来在 Windows Live 上使用的服务以个人存储为主、人际交流为辅，内容易迁移；即使不迁移也无妨，因为大多是自己使用，不对外公开交流。因此这个账号可以停止维护，只增加必要的邮件监控或转发。

A.2. 我原来在 Google 上使用的服务以人际交流为主（如 Reader 和 Documents 上的共享、Groups 中的群组和帖子），如果迁移，对个人和其他联系人都有一定的时间和劳动成本。

A.3. 我关注的统一接口的三个要件是 Email / MSN / Gtalk，这一方案满足了此要求。缺陷只是在访问 Google 服务的时候没有使用统一的账号，但这并不影响对外公开的接口。且 Google 双平台 cookie 独立，方便同时登录 Google Account 和 Google Apps 账号，互不干扰。

　　我启用了新的、统一的 Email/MSN/Gtalk 账号：
　　
　　麻烦朋友们在 IM 或地址簿中加入这个新的账号。
　
　　启用这个新账号，出于以下考虑：
　　1．原 MSN 账号基于“.cn”域名，存在潜在的安全风险。
　　2．原 Gtalk 账号名称过长，不便他人记忆。
　　3．原“@gmail.com”邮箱存在一定的受阻风险。
　　4．我原先对外公开的 Email 较多较杂，不便统一处理邮件。
　
　　新账号的技术方案：
　　使用 Google Apps 建立自定义域名的邮箱（基于 Gmail 系统）和 IM（即 Gtalk）服务；使用这个邮箱注册 Live ID，即可开通 MSN 服务。
　　顺便说一下，原来的“@linjian.cn”的邮箱和 IM 使用的是微软的 Admin Center 服务。与 Google Apps 类似，它提供了基于 Hotmail 的邮箱和基于 MSN 的 IM 服务。但 Google 不允许使用 Gmail 和 Google Apps 账号以外的 Email 地址作为 Gtalk 账号（虽然可以使用第三方 Email 注册 Gtalk 别名，但别名只能用于登录，在好友处显示的仍是一个“@gmail.com”结尾的、不能收发邮件的 jabber 名称。而且这一特征只能在英文版 Gtalk 上使用，中文版 Gtalk 和多数第三方客户端不支持）。
　
　　新账号的优点：
　　1．Email/MSN/Gtalk 统一的入口地址，便于发布和记忆。
　　2．公开单一的邮箱，处理与朋友往来的邮件，减少管理邮件的时间开销。当然，处理工作业务、重要数据的邮箱并不统一到这里，还是要用独立的。
　　3．安全。使用自己的域名，可修改 MX、SVR 等记录，不受制于服务提供商。即使 Gmail 相关域名被劫持，自定义域名的邮件收发也不受影响。即使 Google 相关的 IP 被过滤，我也可以在不改变账号的前提下更换邮箱服务器和 jabber 服务器，通信不受影响。自己的域名被劫持相比 Google、Live 被“肃整”的概率要小一点。
　
　　新账号的缺点：
　　1．Google Apps 账号不能使用完整的 Google 服务，它可以访问 Calendar、Docs 等，但不能登录 Reader、Groups 等。所以我仍然需要使用原 Gmail 账号登录上述服务。不过这对面向他人的“统一入口地址”影响不大，只是自己麻烦点；好在 Gmail 和 Google Apps 的 cookie 是独立的，可以同时登录互不干扰。
　　2．联系人批量转移是个麻烦事，好在 MSN 和 Gtalk 都可以批量导入导出纯文本的联系人列表。需要各位联系人确认一下我的添加请求。
　
　　备注：
　　目前正在使用“@linjian.cn”的 Live ID 的朋友请不要担心，只要没有不可抗拒的因素，我不会停止对 linjian.cn 域名的支付和维护；只要微软的 Admin Center 服务继续免费提供，我就不会停止使用 linjian.cn 上的 Live 服务。除了对个人姓名域名的保护性注册因素之外，我们也必须认识到：虽然目前放在美国的域名比放在国内的域名（尤其是“.cn”）要保险一些，但美国毕竟是我们的潜在对手。万一中美关系有大事变，不排除中国人在美国的域名受到威胁的情况。所以，“.cn”域名可以认为是一种战备资源，适当的时候可以显示其价值。

　　首先声明，我不是搜索引擎方面的专家，以下内容仅仅是实验结果和推测。
　　多语种搜索引擎的设计实现中，会遇到一个问题：多语同文。例如英语之外，还有多种语言使用拉丁字母；俄语之外，也有其它语言使用西里尔字母；汉字不仅在中文中出现，也在日文和韩文中使用；中文还区分简体繁体，字形与其使用地域有一定关联。如果输入一个关键字，这个关键字在使用相同字符体系的不同地区、不同语言中恰好都是合法的词汇，那么应该返回哪种语言的结果集呢？
　　很多搜索引擎都有区域和语言设置，区域选项决定结果集的地域相关性，语言选项决定界面显示或结果集限定的语种。对相当一部分国家来说，区域决定语言。不同搜索引擎对区域和语言设置的敏感程度不同。别的字符体系我没有实验过，但就中文来说，新上线的bing和google还是有一些区别的。我实验的关键字包括但不限于：

简繁日不同形：　价格（價格、価格）、开发（開發、開発）、广东（廣東、広東）；
简繁同形：　　　你好、健康、公路、使用、叫做、智能、孩子、人民；
简日同形：　　　日本、大阪、社会、福祉；
繁日同形：　　　東京、幹線、講師、情報。

　　在google美国，无论搜索简体字还是繁体字，google都会在内部做简繁转换。尽管简繁搜索结果有所不同，但简体的结果中往往也包括了一些繁体页面，反之亦然。如果搜索日文汉字，则结果均为日文网页，不会转换成简体字或繁体字进行相应中文网页检索。在google中国大陆和台湾省的入口，也会执行这项转换。但在google日本，一切汉字均被当作日文汉字处理，结果集以日文为主。如果搜索一些在中文中使用、在日文中不使用的汉字，也会出现一些中文结果。而在google其它地区的入口，如英国、韩国，不执行简繁转换，结果集与输入字形一致。
　　在bing美国，如果搜索简、繁、日不同形的汉字，则会返回相应地区、相应字符集的结果，系统并不进行简繁转换。但如果输入简繁同形、简日同形或繁日同形的汉字，bing好像是会执行一个智能判读，只返回它认为正确的字符集对应的结果集。这个返回结果有时就令人诧异了，例如简繁同形的“你好、健康、公路、使用”返回的大多是港台的页面，而“叫做、智能、孩子、人民”返回的则大多是大陆的页面；简日同形的“日本、大阪、社会、福祉”和繁日同形的“東京、幹線、講師、情報”返回的全都是日本的页面。这严重影响中文用户的使用，所以针对美国市场的bing并不适合直接做中文检索。
　　但bing针对中国大陆、台湾省和日本的入口则综合考虑了区域与语言的因素，返回的内容多是与本地区相关的，不会像美国站那样瞎猜。在中国大陆站输入繁体字或日文汉字，bing会提示用户：想搜索的是不是相应的简体字，或者直接把简体字的结果返回；但在台湾和日本站没有做字形转换。
　　对于汉字多语同文问题，什么样的结果才能最好地满足用户的需求呢？在语言策略上，google也许在尽力保持不同地区搜索结果的一致性，同时也针对特殊的地区执行特殊的语言处理策略（例如在日本，要将所有汉字看作日文汉字；在中国，要处理简体繁体问题），这也许是google追求的技术完美主义抑或是“不作恶”的体现。而bing综合考虑了关键字、区域设置和语言设置，返回与用户所在区域相关、使用指定语言书写的网页，这应该是符合大众用户需求的。在区域策略上，google的默认搜索选项总是搜索全球网页而不是特定地区的网页；而bing默认与特定的区域绑定（在bing的“首选项”中可以体现），本地结果优先呈现，这可能也是二者市场定位的差别。而对于大众以外的需求，搜索引擎的默认策略则不一定能够方便地满足。例如中国用户也常常使用美国版google.com（可以将界面语言设置为中文）取代google.cn，来避免结果被“依法”过滤。而美国版bing即使加上“language:zh_chs”参数，搜索排序效果也明显没有中国版bing好，这应该和它本地化的定位是相关的，鱼和熊掌不可兼得。
　　之所以多语同文会带来这些问题，可能就是因为查询语义和目标语义之间隔了两个语言层：查询语言和目标语言，而这两层之间存在着多对多的映射。Semantic Web和Linked Data在解决语义关联问题的同时，应该也可以解决多语同文的问题。但像Linked Data这样基于人工或半自动化的方法补充元数据及其关联是不是一个好的思路呢？语义的描述和识别究竟应该是人的任务还是应该交给机器来做？如何划分技术提供者、文档作者和文档读者的责任域？这是改进web、创建新的网络文档模型过程中需要考虑的。

　　我不知道用mashup这个词是否合适，也许有歧义吧。我这里指的是将已有的网络或本地应用无缝地整合（不编程或只写很少的程序），来实现一些有趣的应用。
　　先说几个简单的例子：我们可以用Gmail的POP3接收+过滤器+139邮箱的短信通知，实现对任意POP3邮箱来信的短信通知；使用Linux shell脚本+libfetion/Google日历/python-xmpp实现对选课人数或火车票信息的实时追踪；使用freetalk+schema脚本+X10协议实现用IM控制电器；还有基于twitter+GroupTweet+IM机器人的跨协议IM群聊等等。
　　mashup的实现模式大致可以用下图说明。对于普通用户，Gmail、Google日历、twitter等通用网络工具常常充当了邮件、IM和短信之间的网关，帮助用户实现简单的信息整合。从这里也可以看出，twitter之所以成功，很重要的一个原因是它开放了简单通用的API，允许第三方充分发挥想像来mashup它，同时鼓励第三方开放接口给“第四方”mashup。对于有开发能力的用户，运行于服务器端的脚本可以最大程度地满足各式各样的mashup需求，特别是Google App Engine等服务的推出，大大降低了提供小规模公众web服务的成本。再geek一点的朋友，有可能加入一些外设，利用网络控制或监控计算机以外的实体。但编程这件事在提升应用价值的同时，减少了mashup本身的乐趣。在简单的mashup与编程的mashup之间折衷的，就是把mashup作为一种专门的服务。例如Yahoo Pipes，它以RSS为主要的接口，允许用户使用图形化的编程方式组合各类网络资源，加以计算、过滤，最终生成用户所需的RSS输出。这类服务权衡了mashup的技术门槛与灵活性，可能是将来web应用发展的一个方向。

　　以前觉得很cool的一些mashup应用，现在看上去也有点太保守、太沉稳了，我好久没有见到什么新奇的创意了。我在想，有什么创意可以基于现有的架构但突破现有的框框？就像AJAX/web 2.0那样，开拓一片不算新也不算旧的小领域。大家也想想吧！