Godaddy .com renewal coupon

It is getting harder and harder to find a Godaddy .com renewal coupon with big discount, I mean, over 30% off.

Today I had spent 2 hours searching in vain, and was thinking I had to use some voucher with only 20% off for order over $50. The code is not specific for .com renewal, but general for all Godaddy products. It means all Godaddy products can be marked at least 20% off, and it is a sales technique which I do not like. So I do not regard 20% off as a REAL discount. Anyway, it is off topic.

At last minute, I came across a .com renewal coupon 35REN414. The person who revealed this coupon said it was 35% off. Actually I got 40% off when I used it today. Since I never got such a big discount on .com renewal before (the biggest I had got was 33% off), I immediately decided to use code to renew .com domains to a maximum length.

Longer registration period, better SEO result. And domain renewal price is rising. So it is a good investment, I think.

Use long established business for your hosting

前段时间用了一个名不见经传的公司的 VPS 产品。当时看它性能不错才切换过去,但是它操作极不规范,到期前不催续费,我想主动续费都没有链接可以让我续。突然有一天,它意识到有未收账款,也不通知我付款,就停了我的帐号。然后我付款,重新开通服务。中间中断了大约半天的服务,让我损失惨重——那天以后来自 Google 和 Facebook 的流量突然就下降了。这也让我百思不得其解:

  1. 我知道一个网站的 uptime 是很重要的指标,但是,好像影响过头了?以致我怀疑流量下降不是 uptime 的问题,但转折点就在宕机的那一天,是巧合吗?
  2. Google 和 Facebook 使用同样的算法?

总之,不正规的公司是绝对不敢用了。离开之前,我自己清空数据,以下一行命令删除 MySQL 里所有的数据库,抄来的,很方便。

mysql -uroot -pPASS -e "show databases" | grep -v Database | grep -v mysql| grep -v information_schema| grep -v test | gawk '{print "drop database " $1 ";"}' | mysql -uroot -pPASS

BT Infinity speed tests

这两天专注于测试 BT Infinity 访问国内外的网速,有了一个总结性呈辞。

我发现三个较好的测试网站是:

  1. http://myspeedmeter.net/:它是众多带宽测速网站中唯一能测到我的 BT Infinite 满速(下行 76Mbps,上行 19Mbps)的网站。但这个测试结果只能在连接它的伦敦服务器时能达到,连接它在世界各地其他区域的服务器时仍有较大差距,可能瓶颈在海底光缆上。

    BT Infinity speed test result on Myspeedmeter
    BT Infinity speed test result on Myspeedmeter
  2. http://openspeedtest.com/:它用的是纯 HTML5 做测试,没有用到 Flash 或 Java。在你的各种插件都已崩溃或临近崩溃的浏览器里(当然要足够新版),或在手机上不想安装 app 就直接测试,都是很好的选择。但如前所述,它无法测得我的满速,可能我的带宽比它服务器的带宽还强。

    BT Infinity speed test result on Openspeedtest
    BT Infinity speed test result on Openspeedtest
  3. http://sh.189.cn/support/netreport/:它是中国电信搞的网速测试。如果在中国,对连接国外速度没有信心,也可以先测测国内的速度吧。当然我亲测的话,也是不可能满速的。

    BT Infinity speed test result on China Telecom
    BT Infinity speed test result on China Telecom

至于其他两个名气更响的英国宽带网速测试网站,在我这里不推荐。

  1. http://speedtest.btwholesale.com/:它是 BT 公司嫡出的测试工具,但在测试 BT Infinite 时却无法象 myspeedmeter 那样获得满速的结果。

    BT Infinity speed test result on BT Wholesale
    BT Infinity speed test result on BT Wholesale
  2. http://www.broadbandspeedchecker.co.uk/:它在 Google 搜索 broadband speed test 时排名第一,自己也号称 “THE UK’s No.1 Broadband Speed Test”,也是我在 ADSL 时代用得最多的测网速的工具,但它也是无法满速,在 VDSL 时代中没有与时俱进。

    BT Infinity speed test result on Broadbandspeedchecker
    BT Infinity speed test result on Broadbandspeedchecker

Publish on blog or social network?

International social media icons
International social media icons

博客出现在 web 2.0 时代,社交网站算 web 后2.0 时代吧(web 3.0 概念不清,我不好拿来用)。

博客和社交网站的界限模糊,有很多交集,比如博客发展到微博就归入了社交网站。但我这里说的博客,指的是用自主建站的方式,比如用 WordPress  搭建的博客,其他非博客类的 CMS,也可以归入博客范畴;而社交网站,指的是依托第三方的社交平台,通过开设帐号,发布消息。

社交网站诞生多年,我的使用态度一直不积极。我相对较早使用 QQ ,但 QQ 空间至今没有开通;我也没有新浪微博、腾讯微博,更不要说什么人人网之类的;微信也是开通不足半年,还是被没有微信就活不下去的朋友逼着开通的;我也没有 Linkedin,因为它排不上前三;Facebook, Twitter 虽不缺账号,但也懒于维护;唯一用得比较多的 G+,那也是因为我是 Google 的粉丝,Google 想要在社交网站有所建树,我友情支持。

我通常对新生事物都是积极尝新的,为什么不喜欢社交网站?我也不懂自己,勉强找了两点理由:

  1. 大部分人在社交网站发的贴没有深度,无非是“今天的大餐好好吃”、“我在公车上看到有人打架”,这些内容当时有人围观,过了一周、一月或一年,没人会关心你那时吃了什么、看了什么,连你自己也记不起来。
  2. 转贴太方便,个个都是新闻发言人,很多都是以讹传讹,即使是真实的也没有出处可循。转来转去,互联网信息急剧膨胀,原创比例急剧萎缩。

但从商业角度看,不占领社交网站,就会失去和潜在用户联系的机会。怎么合理安排时间和精力维护这么多的社交网站?我草拟了一套方案:

  • 博客为主,社交网站为辅。就是说一定要有自己的博客,然后在时间和精力有盈余时,兼顾尽可能多的社交网站。
  • 内容只发布在博客上,社交网站只转其标题和链接。在内容有错别字或需要更新时,只要更新博客一处即可。虽然有很多工具可以自动同步多个社交网站的内容发布,但是我还没发现一款工具能做同步更新。如果要手动更新各个社交网站,工作量是很大的。而且是重复劳动,我最痛恨。把原创内容直接发布在社交网站上,从 SEO 角度看,是在给他人做嫁衣。
  • 博客要做一些社交网站做不到的事,比如说文章的分类整理、参数查询等等,方便用户记住你的博客,而不仅是你的社交网站的账号。当然你也可以放些广告,赚取额外收益,而在社交网站上这部分收益就不会归你了。
  • 博客要装有分享插件。服务端的分享插件在你发布新贴时,同步标题和链接到你的多个社交网站的账号;客户端的分享插件让用户在浏览帖子时,分享到他常用的社交网站的账号。WordPress 的社交插件有不少,但面面俱到、用起来得心应手的,我还没找到。你若有,别忘了分享给我。
Chinese social media icons
Chinese social media icons

Manage gallery image with customised URL in Magento

Magento 后台对产品图片的管理操作非常简单,直接在浏览器里从本地上传,然后指定哪个作大图(image)、哪个作小图(small image)、哪个作缩略图(thumbnail)。这种傻瓜式的操作有三大缺点:

  • 不适合大批量图片的管理;
  • 图片上传后图片的存放位置乱序,不方便远程文件管理。(abc.jpg 上传后被存放在 /media/catalog/product/a/b/abc.jpg。如果之前已经有同名文件,新上传的文件自动更名为abc_1.jpg, abc_2.jpg,以此类推。)
  • 搜索引擎会从图片的 URL 里获取图片的部分信息,杂乱的 URL 不利于图片 SEO。

我认为最理想的图片管理模式是:在本地按产品分类分级维护一个图片库,用 FTP 上传到服务器,在 Magento 后台可以浏览这些文件(对 Magento 来说是本地文件),然后为某个产品选定它的大图、小图和缩略图。这样 Magento 里保存的图片位置信息就保持了自定义的产品分类信息。

Magento 的自动缩放图功能很好用,但自动缩放图生成的文件 URL 又臭又长,肯定不利于 SEO,而且服务器硬盘上留下一大堆乱序规则生成的文件夹,实在难看(有种屋子没打扫的感觉)。鉴于一个优质的电子商务网站本应该对整站的图片大小有统一的规范,不妨在本地制作好小图和缩略图,不依赖 Magento 的自动缩放图功能。

好多年前我就想做个 Magento module 来优化 Magento 的图片管理,但事务繁忙,也不知道什么时候能静下心写代码。与其让听众苦等我的 module,不如我介绍一下 Magento 数据库中 gallery 的结构,让大家懂得直接操作数据库去搭 product 和 local images 之间的桥。

首先做两个准备工作。

一是查好每个产品的 ID 备用。如果人可以 SKU 识别产品,那就准备一张 SKU – ID 的一一对应表;如果人可以 product name 识别产品,那就准备一张 product name – ID 的一一对应表。

二是把每个产品的大图、小图和缩略图命名得有意义,比如是大图是 product-name-1.jpg, product-name-2.jpg, product-name-3.jpg,小图是 product-name-s.jpg,缩略图是 product-name-t.jpg(因为 small 和 thumbnail 不是产品的关键字,所以没必要拼写完整,用自己人能看明白的代号就可以)。FTP 上传图片至 /media/catalog/product/category-name/sub-category-name/SKU/,一个产品的图片归在一个文件夹下。

现在开始正式操作数据库。操作涉及到 4 个产品属性(attribute)和 4 张表(table)。

4 个产品属性:image, small_image, thumbnail, media_gallery.

4 张表:magento_eav_attribute, magento_catalog_product_entity_media_gallery, magento_catalog_product_entity_media_gallery_value, magento_catalog_product_entity_varchar.

第一步:在 magento_eav_attribute 中查出 4 个产品属性的 attribute_id。在我碰到的 Magento 早期版本中,4 个产品属性的 attribute_id 分别是:

  • image: 70
  • small_image: 71
  • thumbnail: 72
  • media_gallery: 73

在最新的 1.7.0.0 中,4 个产品属性的 attribute_id 分别是:

  • image: 85
  • small_image: 86
  • thumbnail: 87
  • media_gallery: 88

当然可以顺便看一下 product 的 entity_type_id,不出意外的话,这应该是 4。后面会用到。

第二步:在 magento_catalog_product_entity_media_gallery 插入记录。一张图片就是一条记录,插入记录就是定义产品和图片之间一对多的关系。

Insert record to magento_catalog_product_entity_media_gallery
Insert record to magento_catalog_product_entity_media_gallery

magento_catalog_product_entity_media_gallery 中各 column 的意义是:

  • value_id:记录 ID,可以留空让数据库自动生成。
  • attribute_id:media_gallery 的 attribute_id。
  • entity_id:产品 ID。
  • value:文件存放位置信息(略去 /media/catalog/product 部分)。
Gallery records for one product
Gallery records for one product

做完这两步就可以在 Magento 后台 Manage Products 的 Images 那一页上看到属于这产品的图片。后面几步可以移至 Magento 后台完成。我继续介绍如何直接操作数据库,是让大家知道如何用数据库的导入功能去批量处理。

第三步:在 magento_catalog_product_entity_media_gallery_value 插入记录。这等效于在 Magento 后台为每个图片在各个商店设定 Label, Sort Order, Exclude 值。

如果只有一个商店,一条 magento_catalog_product_entity_media_gallery 记录就对应一条 magento_catalog_product_entity_media_gallery_value 记录。

如果有多个商店,default store_id 就是 0,先按一条 magento_catalog_product_entity_media_gallery 记录对应一条 magento_catalog_product_entity_media_gallery_value 插入记录。假设另有两个商店,store_id 分别是 1 和 2,store_id 1 沿用 store_id 0 的 default 值,store_id 2 则使用一组不同的 label/position/disable 值。这样,不需要为 store_id 1 多插入一条记录,因为 Magento 的 Website/Storegroup/Storeview 的规则是没有额外记录就是使用 default value。只需要为 store_id 2 多插入一条记录,这条记录优先于 default value,但只为 store_id 2 而生效。

magento_catalog_product_entity_media_gallery_value 中各 column 的意义是:

  • value_id:匹配 magento_catalog_product_entity_media_gallery 的记录 ID。
  • store_id:商店 ID。
  • label:图片说明。
  • position:图片排序。
  • disabled:0 就是不 Exclude,1 就是 Exclude。
Insert record to magento_catalog_product_entity_media_gallery_value
Insert record to magento_catalog_product_entity_media_gallery_value
Disable (Exclude) small image and thumbnail
Disable (Exclude) small image and thumbnail

第四步:在 magento_catalog_product_entity_varchar 插入记录。这等效于在 Magento 后台为每个产品在各个商店设定哪个是默认大图(大图可以有多张,只有一张是默认的)、哪个是小图、哪个是缩略图。

magento_catalog_product_entity_varchar 中各 column 的意义是:

  • value_id:记录 ID,可以留空让数据库自动生成。
  • entity_type_id:不出意外的话,应该填 4。
  • attribute_id:image/small_image/thumbnail 的 attribute_id。
  • store_id:商店 ID。
  • entity_id:产品 ID。
  • value:文件存放位置信息(略去 /media/catalog/product 部分)
Insert record to magento_catalog_product_entity_varchar
Insert record to magento_catalog_product_entity_varchar

假设以前用 Magento 后台上传过产品图片,删除了,保存产品,这时,服务器硬盘上的图片不会随之删除,数据库里的 image/small_image/thumbnail 记录也不会随之删除(只是 value column 的值被 NULL 代替)。这也是我不喜欢用 Magento 后台来管理产品图片的一个原因。

Duplicate record error
Duplicate record error

这些 NULL 值的记录会导致插入不成功,因为 magento_catalog_product_entity_vartype 有规定 entity_id, attribute_id, store_id 三值组的唯一性。不让插的话编辑原记录。

Search by attribute_id and entity_id
Search by attribute_id and entity_id
Search result by attribute_id and entity_id
Search result by attribute_id and entity_id

或者,把原有的 image/small_image/thumbnail 记录全删了,再插。

Search by attribute_id
Search by attribute_id
Search result by attribute_id
Search result by attribute_id

这四步做完后,Magento 前后台就显示了指定的图片。

Magento GUI manage products images
Magento GUI manage products images
Magento store front product page
Magento store front product page

这时 Magento 的自动缩放图功能仍在生效,需要修改模板让 Magento 直接使用指定的大图、小图和缩略图,这里不再多述。

What is web 2.0?

Web 2.0 这个名词都出来好多年了。它还是新鲜名词的时候,我买了本书 Web 2.0 strategy guide,太深奥,扔在那里没看。还已有人嚷嚷着 web 3.0,我现在再来讨论“什么是 Web 2.0”似乎有点过时。

迟了这么多年谈这个,跟我不是搞理论的有关。我倒不是说理论不重要,恰恰相反,理论很重要。我总结不出理论,只能关心我要怎么做才能 web 2.0。当然了,名词也不重要,2.0、3.0 当然就更不重要了,就说怎么做一个好网站吧。

话题的起因是今天看到一个论坛帖:几月几日某地到某地回程空车,找想搭车的。那个论坛纯属杂谈,突然冒出这个让我有点想笑,转念一想其实没什么好笑的——我22号要去 Heathrow 接老婆,也可以找搭车出程的。但我不屑于在那论坛上发帖,一是不看好那坛的人气,二是都 web 2.0 了,肯定有更好的办法。于是调查了一下,果然有,叫 liftshare。

唉,我怎么早先没想到呢?几年的独自上下班本来也可以 share 的嘛。唉,这年头只有想不到,没有做不到的。唉,题外话。

玩了一下 liftshare,感觉还不错。只是它在路线、时间的匹配上不是那么智能,毕竟 liftshare 的算法不是 IBM Watson,我提醒自己。liftshare 到底干了什么呢?它的卖点就是提供一种匹配互补行程的功能,网站不做任何内容,内容是行程,而行程都是用户提供的。

联想到 YouTube,网站也不做内容,内容是 video,而 video 都是用户上传的。而且,不上传 video 的用户也可以参与做一些既是内容又不是内容、半内容半功能的东西,比如说 playlist。YouTube 有成千上百的有关 jeopardy Watson 的 video,良莠不齐,我看了 Watson 的三天比赛 6 段 video,是不同的人上传的 。我留意了一下,还没有一个人完整上传过这 6 段视频。所以我把它们组织成一个 playlist,方便我介绍给朋友们看。YouTube 在其中干了什么?要说它什么都没干也可以,因为 video 不是它的,playlist 也不是它的,要说它什么都干也可以,因为没有它用户什么也干不了。这就是 web 2.0。

联想到 SEO,“Content is the King” 被奉为经典,做了内容还不够,还要做原创内容,搞得象我这样的人疲于奔命。其实搜索引擎鼓吹内容的重要性是带有很强的功利性,因为它不做内容,再没人做内容的话,它还靠什么吃饭啊。搜索引擎就像我排 playlist,排得好就有人看,排得不好就没人看,但归根结底要有内容可排,这就是 web 2.0。

Ecommerce 网站目前沦落为内容网站,内容就是产品。内容网站和搜索引擎之间的关系就好比作家和评论家,理论上家家是平等的,事实上平均水平的评论家比平均水平的作家更吃香。在内容网站和搜索引擎的博弈中,通常也是搜索引擎占主导地位,搞得内容网站整天揣摩搜索引擎的心思。例外也有,除非 ecommerce 网站卖一个全球独家产品,还要是热门产品,这下轮到搜索引擎揣摩了。但这种情况太少了。

换位思考一下,同是网站,凭什么 ecommerce 网站就是作家,搜索引擎就是评论家?凭的是 web 2.0?可 ecommerce 网站毕竟还是要卖产品的,内容不能不做,那就考虑一下兼做 web 2.0。产品比较单一怎么办?比如外卖店就几个炒菜怎么做 web 2.0(最近在外卖店搭伙,想到的就是炒菜了)?

我天方夜谭了一下炒菜 2.0 的思路:

让吃客公布 eatlist,让他们介绍 eatlist 推荐场合,比如情人节、工作日赶场,让别的吃客可以 add eatlist to cart,评选本周/本月/本年最受欢迎 eatlist,奖励 eatlist 原创作者 Android 3.0 手机一部,让他明年用手机点餐。

Learned something basic

今天又长知识了。

首先,最简单的,更正了长久以来的想当然,php 下 explode(‘,’, ”) != array(),而是得到长度为 1 的数组,key 是数值 0,value 是空字符串。天哪,我有多少个程序是基于 explode(‘,’, ”) == array() 写下去的,这下影响大了,得好好查一查。

其次,发现一个不晓得是 sshfs 的 bug 还是 gedit 的 bug。复制错误的过程是:用 Nautilus 或 Dolphin 打开 sshfs 挂载的目录,右击创建一个新文件。文件创建是成功的,属性是 774,用 gedit 打开它却无法保存,提示是没有写权限;但用 kwrite 编辑保存一切正常;用 gedit 再编辑 kwrite 编辑过的文件又能保存。或者,在右击创建一个新文件后,执行一次 chmod 774 filename,也能用 gedit 编辑保存了。

再次,发现在 IE6 下,用 javascript 增大元素的尺寸(比如 jQuery widget 化,增加 border,增加 padding,等),会增大父元素的尺寸。哪怕父元素已用 css 静态赋以宽度值,宽度也会被改变,这是某些精心布局在标准浏览器下很好看,到了 IE6 就面目全非的一大原因。万恶的 IE6 啊,当然从另一方面,说明精心布局仍不够“精心”。为 IE6 布局好比极限运动,挑战好心情的极限;如果看到下属多花一倍时间 fix for IE6,挑战的也是老板的心理极限。

然后,发现 jQuery gallery 里有两个 themes (Humanity, Vader) 的参数不太正常,多了 tr 参数,不知道怎么多出来的,删了似乎没影响。

最后,如果父元素包含所有的子元素都是 float:left 或 float right 的话,不做特殊操作,父元素是没有高度的。父元素的后续元素用一个 clear:both 就能站到该站的位置,但如要为父元素本身画一个边框就稍有难度。最早我用的办法是在这个元素所有的子元素之后增加一个隐形的<div style=”height:0; clear:both;”></div>,但这个硬生生加进去的元素改变了 DOM 结构,破坏了语义,不够 SEO。在 Magento 里学到了另一个方法 :after { clear:both; },如 .clearer 的示例,但要为低版本的 IE 专门写 clear after fix。我维护一份自己的 style.css,override Magento 原版的 style.css。我觉得这个任务就很“繁重”,如果再来一份自己的 style-ie.css,override Magento 原版的 style-ie.css,就为 clear after fix?总觉得小题大作。今天发现一个 clear after all floating children 的 neat solution,就是在父元素上设定 style=”overflow:auto; zoom:1″。overflow 让父元素调整到应有的高度,zoom 也是必须的,否则 IE6…,唉!

最后的最后,发现 z-index 值在 IE6 下被重置的简单通用的 fix。这个问题的来源是若干个 position 后的元素,给它们设定 z-index,IE6 下根本不按设定值 layout,而且还摸不到规律。比如下拉菜单,有时被其他东西给压住。fix 是赋予下拉菜单 z-index 时,赋予父元素(整个菜单)更高的 z-index。

Establish a protocol of post tags

尽管在 WordPress 里新增一个 post tag 是件很容易的事情,但我不想每次想到一个 tag 就增一个,上千个 posts 就有几千个 tag,搞得 posts 之间的 tag 联系很松散。所以,我很久不新增 tag 了,写完 post 就在已有的 tags 里挑一个或几个 tags 出来。

时代在发展,新生事物不断出现,如果我老用几年前敲定的 tags 而不与时俱进,blog 就显得 out 了,也不利于芳草苑在新新名词方面的排名。比如,刚才一篇,想用 chrome,结果发现有 firefox 而没有 chrome,只好暂时 tag 一个 firefox,等我整理好一份 tag waiting list 再更新 post tags。

初步想删 office, outlook 等,因为 windows 已经 out 了,我也没在 office, outlook 主题上浸淫许久,这类 posts 干脆合并一个 microsoft 或 windows software 得了。

初步想增加 android, html5, css3, jquery, 因为它们或是日渐热门,或是已经热门,我三天两头都会讲到这类主题。现在统称为 google, html, css, javascript 似乎对它们不公平。

Magento theme improvements from 1.3 to 1.4

There are loads of improvements in the newest version of Magento themes. I just list some from my point of view. I observed these changes when I started using Magento 1.4 three days ago, but they may exist in the late version of 1.3.x.x already for long.

Everyone knows we should separate presentation from content. Magento does it very well since its first public version. Magento 1.4 just makes separation even better. A theme is about presentation, usually made of two parts, app/design and skin. Compared with skin, app/design part is somehow closer to content. Magento 1.4 themes remove layouts and templates from app/design, which means they are fully rely on css to present different themes. Base/default theme is an exception, but it is a fall-back theme.

In 2-column or 3-column page templates, main column code comes before left/right column. I think it hugely helps SEO. I first saw this kind layout in a Zen-Cart template. Maybe Magento was inspired by it. Under template/page, one-column.phtml was deleted, which saves confusion with 1column.phtml.

The header logo is no longer displayed as a background image, which is a minor change but makes big improvement.

I spent 3 days to re-write my theme to be compliant with Magento 1.4 but I love these changes.

My third DNS server down for a month

今年初,我退掉了 godaddy vps,把原来 godaddy vps 担当的辅助 DNS 角色转给了 1&1 server,却忘了开 1&1 server firewall port (硬件防火墙那道关)。

今天才发现这台辅助 DNS 在过去的一个月根本无法执行 DNS 解析(因为我设置了三台 DNS,挂了一台没引起警觉)。难怪最近 webceo 给我的评分只有 5 分上下,google 的排名也有下降。

赶紧打开防火墙,希望分数能上去。