张磊的blog

更换域名半月后情况

距离把blogkid.cn更换到blogkid.net已经有半个月了。我觉得这是一个很好的观察搜索引擎收录速度的机会，所以写一篇文章通报一些数据。

搜索引擎方面，由于Google提供了“change of address”的功能，所以在更换域名当天即有20多个blogkid.net下的页面被收录。截至写这篇文章时，Google收录了4680个blogkid.net下面的网页，留在blogkid.cn的只有1970个。

可以与之对比的是子宁的blog，在6月7号，由zining.blogkid.cn更换到了zining.net。50天以后，通过Google查询，原域名依然有777个网页，新域名只收录了170页。可以看出，采用Google网站管理员工具中的“change of address”功能，确实可以加速新网站的收录，因为这是明确地告诉了Google，你的域名发生了改变。

相比之下，百度就慢很多。虽然我使用了301跳转，但百度迄今为止只收录了blogkid.net首页。不知多久才会有首页之外的页面出现在索引中。至于搜狗啥的，就不拿来比了。

流量方面，来自百度的流量跌至更换域名前的1/3，来自Google的流量没啥变化（连续7天的统计数据进行比较）。

开放目录方面，DMOZ已经更新了信息，把blogkid.cn换成了blogkid.net，同时也更新了blog的描述信息。可以在这个页面看到。

更换域名这种事，总是非常繁琐。如非必要，少折腾为妙。

好多好多现支持订阅

距离上一次给好多好多增加功能已经有一个月。一个月来，淘宝发布了TOP；阿里妈妈原有接口进行了调整；Twitter也被封了。这些或多或少影响到了好多好多，但也一一解决了。

现在，可以在任何一个RSS阅读器中，订阅好多好多的最新讯息，我把它称为“好多好多画报”；也可以follow @haoduohaoduo，每个早晨都会看到当天更新的最热商品。

好多好多没有基于TOP的API进行开发，而采用了阿里妈妈开放的一套查询API。我不止一次想把好多好多迁移到TOP平台上，但都放弃了。TOP不仅使用很繁琐，而且还是个半成品，在沙箱环境下依然有各种各样的问题。

附上好多好多画报的订阅地址：http://haoduohaoduo.com/index.xml

莫让数字证书绑架了电子支付

昨天上午在手机上把玩支付宝的客户端，尝试给同事付一笔钱。耐心输入许多信息后，被告知，“数字证书用户暂不能支付”。不禁哑然，“手机在线支付，随时随地体验电子商务交易的快乐”，如果你装了数字证书，恭喜你，你没法体验了。

写文章前我专门查阅了一下数字证书的定义，在百度百科和Wikipedia都有，百度百科的词条更详细些。如今的支付宝和财付通都引入了数字证书这个东西。财付通的也许是用户太少，没有见到什么讨论。但支付宝的数字证书用户可真没少吃苦。我在IE7和IE8中导入证书都遇到了奇怪错误，大辉也专门针对IE8写过文章。

更严重的是，如今数字证书的作用范围仅限于Windows+IE，这让Windows+Firefox，Linux+Firefox甚至MacOS+Safari这些搭配都玩不转了。一起玩不转的还有手机版，如果两年后Google的Chrome OS——这个以Web为中心的OS流行起来（我知道它也是基于Linux），哪怕安全控件已经开发了一箩筐，数字证书，依然是绕不过的坎。

不如回头想想，数字证书是否安全？有多安全？是否有替代的解决办法？答案也并不复杂，不如考虑一个被广泛使用的“手机锁”（也被叫做“手机动态口令”等）。当绑定手机后，在进行一些重要操作时，网站会随机发送一段验证码到用户的手机，用户必须输入此验证码才可以继续操作。这个办法看起来土鳖，但已经非常保险。要知道，招商银行的支付网关，如今也支持这种方式的支付。一家在互联网方面做得最出色的银行（没有之一），选择了这样的策略，多少值得我们思考。

有人会说，数字证书技术如何先进，采用的RSA加密如何优越，高精尖就一定合适？或者说，那些把Linux玩得风生水起的Geek，有多少人会需要数字证书这样的东西来保证它们的安全？分享一个“古老的”小故事，我想大家都看过：

联合利华引进了一条香皂包装生产线，结果发现这条生产线有个缺陷：常常会有盒子里没装入香皂。总不能把空盒子卖给顾客啊，他们只得请了一个学自动化的博士后设计一个方案来分拣空的香皂盒。博士后拉起了一个十几人的科研攻关小组，综合采用了机械、微电子、自动化、X射线探测等技术，花了几十万，成功解决了问题。每当生产线上有空香皂盒通过，两旁的探测器会检测到，并且驱动一只机械手把空皂盒推走。

中国南方有个乡镇企业也买了同样的生产线，老板发现这个问题后大为发火，找了个小工来说:你他妈给老子把这个搞定，不然你给老子爬出去。小工很快想出了办法：他在生产线旁边放了台风扇猛吹，空皂盒自然会被吹走。

已经上马数字证书的第三方支付公司，应该是骑虎难下了。还没有上当的公司，可以仔细考量一下。复杂的做法，并不是把事情变简单的唯一途径。

PS：本人是百付宝的员工，文中观点仅代表个人非客观意见。

PS2：支付志这篇文章里引用的图片，和我的手机一样，都是台版的S1 。

UPDATE： 本周，腾讯公司推出了基于Firefox的数字证书。不知道alipay会不会跟进。拭目以待。 -2009.9.20

blog域名迁移之搜索引擎相关

前一篇：blog域名迁移之迁移wordpress

如果说前一篇是和wordpress关系密切的，那这篇文章基本和blog关系不大了。换言之，任何内容为主的网站更换域名，都可以参考下这篇文章的内容。如果我写得还有什么遗漏，欢迎大家补充。

1、通知Google

与搜索引擎相关的内容，最重要的是301跳转，这一点昨天已经提到。但是Google还提供了进一步的服务，我们有必要利用好。

首先登录到Google Webmaster，到原来域名的页面（我的是blogkid.cn）。可以看到如下菜单项：

Google提供了一个“Change of address”的功能，也就是说，如果域名发生了改变，可以在此处告诉Google。当然，更换后的域名，也需要添加到Google Webmaster并通过验证。

在“Change of address”里，我选择将www.blogkid.cn更换到www.blogkid.net。保存以后，会有如下结果：

实际上，配置301跳转只是一种被动的办法，搜索引擎在相当长的一段时间后（之前Google的承诺是6到8周）才会更新域名。而在Google Webmaster提交则非常主动。我在更换域名当天提交了这些信息，在下午就发现Google已经收录了将近30个来自blogkid.net的网址。

2、更改开放目录中的信息

这里主要说DMOZ吧，别的开放目录应该也差不多。之前的blogkid.cn被DMOZ收录了，但更换域名之后就需要更新信息。DMOZ提供了这样一个表单用于更新信息：

提交之后，还需等待编辑员审核通过。DMOZ中的信息相当重要，不仅Google、Yahoo!在使用，Alexa和国内的百度也都会引用其中的信息。很有必要保持信息最新。

3、来自Google的提示

在Google提供的”Change of address”页面左下角，有一些相关的文档，其中一篇Moving your site谈到了一些需要注意的细节，值得一读。其大意可归纳为：

1. 将迁移域名与网站的redesign分开，使用户可以平滑过渡。
2. 使用301跳转，并且不要把所有请求都定向到一个页面。举例来说，在用户访问blogkid.cn/archives/2046.html这个地址时，要将其定向到blogkid.net/archives/2046.html，而不是全都指向blogkid.net。
3. 检查自己网站的内链和外部给出的链接。最好能通知其他网站把链接指向新的域名。如果这很难做到，也需要参照第二条，使用301跳转到新的地址。
4. 最好将旧的域名保留至少180天，以使Google可以更新索引（这里对别的搜索引擎应该也一样）。

总地来说，和搜索引擎打交道，是一件长期的事。在等待搜索引擎、开放目录更新的同时，也有必要行动起来，把任何可以修改的地方的旧地址更换为新地址，比如Twitter、Flickr、LinkedIn甚至是Google的Profile；如果使用了feedsky或是feedburner，记得也更改一下feed源地址，免得哪天突然就看不到自己写的文章了。

最后打个广告，加了我链接的朋友们，如不介意，请拨冗修改链接地址为www.blogkid.net吧。多谢了。

blog域名迁移之迁移wordpress

更换域名更多时候是体力活儿，但是用法得当，可以省力不少。所以我打算写几篇文章，写写自己迁移域名（从blogkid.cn到blogkid.net）的全程。先写迁移wordpress。

迁移wordpress主要涉及到3步：

1、数据备份

如果服务器上装有phpmyadmin，可以直接导出一下。使用shell的朋友，可以用如下命令来备份数据：

mysqldump  -u dbuser -pdbpass -h  dbhost  dbname | gzip > backup.sql.gz

把相应位置的dbuser, dbpass, dbhost和dbname替换为数据库用户名、密码、数据库服务器以及要备份的库名。最后得到的backup.sql.gz，就是一份完整备份。

插一句，我把备份的文件解压一看，居然有12M之巨。如果10%是有效内容的话，我这4年已经写了1.2M字节，相当于60万汉字了。

2、配置Web服务器

在这里需要牢记一点：使用301跳转，而不要用默认的302（refer）。

配置Web服务器的目的是，将访问原有域名的请求引导到新的域名。301跳转是永久重定向，而302跳转是暂时重定向。前者对搜索引擎更为友好。

以我从blogkid.cn迁移到blogkid.net为例，在nginx中做如下配置：

server {
listen   80;
server_name  blogkid.cn blogkid.net www.blogkid.cn;
rewrite ^/(.*) http://www.blogkid.net/$1 permanent;
}

server{
listen  80;
server_name  www.blogkid.net;
……
}

第一段的配置是将blogkid.cn，blogkid.net以及www.blogkid.cn的请求都重定向到www.blogkid.net下面。而第二段是用www.blogkid.net替换原有的www.blogkid.cn，其他部分不用改变。注意到在使用rewrite时，加入了permanent关键字，可以使nginx发送301重定向。

如果使用apache，配置也类似，在rewrite时可加入参数R=301。

保存之后重启web服务器，使配置生效。

3、修改数据库

这也是对wordpress进行迁移的最后一步。需要注意，在完成第二步之后，wordpress会暂时无法打开，原因大家可以自己考虑一下。如果觉得不太好，把这一步提到前面也可以。或者可以先修改好配置文件，等第三步完成了再重启web服务器。

修改数据库主要修改3部分，语句可以在phpmyadmin或者mysql命令行中进行，整理自此处。

（1）修改站点地址、主页地址：

UPDATE wp_options SET option_value = replace(option_value, ‘http://www.old-domain.com’, ‘http://www.new-domain.com’) WHERE option_name = ‘home’ OR option_name = ’siteurl’;

（2）修改文章中内部链接以及附件地址：

UPDATE wp_posts SET post_content = replace(post_content, ‘http://www.old-domain.com’, ‘http://www.new-domain.com’);

（3）更新文章永久链接：

UPDATE wp_posts SET guid = replace(guid, ‘http://www.old-domain.com’,’http://www.new-domain.com’);

这三板斧一过，wordpress的迁移已经完成了。之后就从新域名打开网站，看看是否还有什么地方遗漏未能改掉。

BTW，如果原来域名有备案的话，可以在页面底部去掉。更换域名以后，就失效喽。

下一篇，将写写如何通知搜索引擎。

cn再见

今天终于下决心，把原来的blogkid.cn迁移到blogkid.net。一个原因是blogkid.cn需要每年找代理去续费，转入转出太难；另一个原因是，我不喜欢自己的域名被一帮无耻的人监管。其实，在网站被迫漂洋过海之时，我该把域名一起换了的。

迁移的操作很容易，我花了不到半小时就全部搞定了，我之后会把操作的过程，以及一些需要注意的细节写出来。但现在需要朋友们帮忙：加了我友情链接的朋友们，要是有空，麻烦把原来到blogkid.cn的改成blogkid.net吧。多谢啦。

拜拜，以后也不会再用.cn域名了。

管窥Paypal Adaptive Payments

本周Paypal的“开放API”也算是火了一把；Paypal一直都有开放的API，但今次泄露出来的，确实有所不同。描述这个Adaptive Payments的文档可以在techcrunch的文章中找到。

这两天仔细看了一下该文档。在Paypal将要推出的Adaptive Payments中，描述的内容是如下三种支付业务（示例图片就不引用了，请大家自己去看文档）：

Simple payments：Paypal上已有的、传统的支付方式，把钱从一个账户支付到另一个账户。

Parallel payments：把钱从一个Paypal账户同时支付到多个Paypal账户。也就是说，A可以通过API同时向B和C付钱。例如，我有一个购物网站，可以让用户付钱时把10%给我，剩下90%给我的供货商。

Chained payments：把钱从一个Paypal账户A支付到另一个Paypal账户B，B留下一部分，再将余下的支付到账户C、D、E……顾名思义，称为chained payments。再引用上面购物网站的例子，可能需要将收入的5%给销售人员，之后将剩下的95%，供我和供货商分账。

这份长达63页的文档，用于陈述这些payments的概念、可能的应用场景、扣费规则、以及api细节。仔细想一下上面的三种业务不难发现，在simple payments的基础上很容易包装出parallel payments；而有了simple payments + parallel payments，就是一个山寨版的chained payments了。Paypal这么做的苦心，还是在于将业务前置，让API的使用者无需操心利益分配、资金结算、打款退款的细节。

也有人说Paypal是感受到了Amazon FPS的压力，于是特地跑去看了一下FPS。一进去就看到这么一句：

Amazon Flexible Payments Service^TM (Amazon FPS) is the first payments service designed from the ground up for developers.

联想到Paypal祭出了x.com，标题是“/* GEEK OUT WITH US */”，让我觉得，Paypal和Amazon，可能都受Apple App Store的刺激了 。如果能有国内的互联网公司关注国内的Geek，那就太好了。