车东[Blog^2]

腰围2尺1,2,3,4,5,6,7,8寸分别等于是多少厘米/英寸(对照表)

Sat, 27 Jun 2009 18:21:04 +0800

■70厘米 ■2尺1 ●26英寸
■74厘米 ■2尺2 ●28英寸
■76厘米 ■2尺3 ●29英寸
■78厘米 ■2尺35●30英寸
■80厘米 ■2尺4 ●31英寸
■82厘米 ■2尺45●32英寸
■84厘米 ■2尺5 ●33英寸
■86厘米 ■2尺6 ●34英寸
■88厘米 ■2尺65●35英寸
■90厘米 ■2尺7 ●36英寸
■92厘米 ■2尺75●37英寸
■94厘米 ■2尺8 ●38英寸
■96厘米 ■2尺85●39英寸
■98厘米 ■2尺95●40英寸
■100厘米■3尺 ●41英寸
■102厘米■3尺05●42英寸
■104厘米■3尺1 ●43英寸
■106厘米■3尺2 ●44英寸

内容型网站面向搜索引擎蜘蛛和搜索用户的优化

Thu, 25 Jun 2009 08:04:08 +0800

面向机器的抓取优化
1 缺省域名唯一化：缺省foobar.com 设置301跳转到 www.foobar.com 一方面减少搜索引擎页面消重的负担，一方面可以将针对相同内容的反向链接权重汇总。对于缺省使用https访问的网站，如果不跳转（比如以前的支付宝），往往还会有浏览器提示安全证书路径不匹配的问题；另外：在Google Webmaster tools中也有缺省域名的配置；
2 被遗忘的流量：想办法搜集域名解析失败和拼写错误导致的流量流失；曾经启用过的域名，就尽量不要删除，一直保留并设置转向到最新的地址；有渠道取到DNS的这种记录吗？
3 404页面的运营：返回hard 404(返回http header而不是html 404 header)，统计并跟踪带有referer的404日志，修正这些问题；
4 节省HEAD类请求：对于一些蜘蛛（主要是百度蜘蛛），经常使用head请求来检查旧链接的有效性，启示可以针对这些请求做直接返回304处理，以节省服务器的处理资源；
5 永久转向：避免302，转向尽量使用301到最终地址；
6 重视站内搜索：利用搜索做内容之间的关联和发现，每篇文章提供相关文章等功能；而能解析出搜索来源关键词的404访问尤其应该通过站内搜索为用户提供其他可选内容。
7 利用google webmaster tools等跟踪收录和错误抓取问题并及时修正；
8 归档页面URL标准化：虽说搜索引擎声称动态页面和静态页面收录和RANK不受影响，但为了方便管理，最好还是将内容页面尽量标准化成静态地址，并页面中尽量加上唯一化的地址，减少搜索引擎抓到相同内容的不同链接后消重的麻烦，比如各种论坛的内页：

面向用户的内容优化
1 自身主动检查spam，防止大量的镜像内容，搜索引擎对于spam处理不利的站点，往往也只好使用整体降权的方式；
2 避免用户因为使用第三方计数器，JS小功能（比如：样式很炫的用户鼠标指针等）被植入病毒木马，Google会向比较严重的站点的webmaster@信箱发送邮件提醒相关问题，所以这个邮箱一定要创建并定期查看；
3 结构化数据源： RSS、sitemaps归档入口，而最高效率的是利用各种ping接口将最新内容即时发送给搜索引擎（最近百度也都支持相应接口和协议了）；
4 重视标题和meta description在搜索结果页上的可读性： meta description不参与排序，但良好的标题和meta description往往比纯算法提示出来的摘要更接近用户目标，在现有排名位置下，争取吸引用户更多的点击也是一个有效的策略；
5 应有的反向链接的获得：主动加上版权声明；

使用开源软件对IIS应用进行重构

Thu, 30 Apr 2009 14:06:09 +0800

日志统计和各种负载监控：
AWStats
全面统计原始日志，分析浏览器和非浏览器的流量，在很多应用中蜘蛛抓取已经超过了浏览器访问；而搜索引擎的来源也和蜘蛛的遍历有很大的关系；使用Cacti对服务器的各种指标进行监控，对于系统优化重构后的跟踪也有非常直观的表现，页面YSlow得分，甚至Google Webmaster统计都会比较有用；进行重构前先进行一些统计和分析工作，在重构后也便于评估和量化重构的效果。

前端优化： Nginx
对照YSlow进行前端优化的主要是：
实现统一的expires配置：实现客户端的缓存；
解决HTTP压缩：减少文本的传输；
解决日志问题：更方便的增加针对cookie等字段的记录；
通过代理实现实现负载均衡：将原有单机应用通过路径规则分布到后台多台应用服务器上而不用增加域名；
解决URL Rewrite等问题：相比IIS自身，nginx的配置都相对简单；

缓存优化：
静态文件缓存服务器：Varnish
分布式应用缓存： Memcached；

epoll推动web发展：在各种服务中都能看到epoll机制的影子；

而各种平台之间的数据交换尽量使用json XML等格式便于未来跨平台调用；

雅虎统计 chedong.com 读者基于淘宝购物行为的访客网购兴趣分析

Thu, 12 Mar 2009 15:59:26 +0800

2月份雅虎统计推出了一个新功能：访客网购兴趣，估计是基于用户的淘宝用户行为做的分析，数据好像不是每天更新，近期刚更新过。

本网站最适合用户人群：



类型             购买比例    相对平均差异

车载MP3/视听	2.68%	92.8%

数码相机其他配件	2.33%	84.9%

笔记本电脑	3.26%	69.8%

数码摄像机	1.12%	62.3%

GPS配件/车载通讯	7.31%	61.4%

品牌家饰	0.70%	55.6%

GPS	2.07%	54.5%

看来适宜推荐各种IT新设备；
相对其他网站平均的差异 = 是以与平均水平相比/平均水平

最不适宜在本网站投放的10中商品广告：



职业套装/学生校服/工作制服	0.72%	-41.0%

运动装外套	0.51%	-42.0%

热水器/浴霸	0.26%	-42.2%

围巾/丝巾/披肩	0.26%	-42.2%

运动裤/裙	0.27%	-42.6%

胶卷相机	0.27%	-43.8%

女装羽绒服	0.27%	-43.8%

装潢二手/闲置专区	0.27%	-44.9%

文胸套装	0.26%	-46.9%

运动套装	0.34%	-50.7%

装饰画/无框画	0.26%	-52.7%

使用Google analytics的 _trackPageview()对网页进行重新命名统计

Thu, 05 Mar 2009 11:11:10 +0800

这里将一些利用Google analytics _trackPageview()进行URL改写实现别名统计的方案样例整理如下：
1 自定义链接改写（rewrite）：将URL变成可读性更好的地址，例如：

/index.php ==> 部署 pageTracker._trackPageview('/首页');
/photos/sun_rise.html ==> 部署 pageTracker._trackPageview('/相册/日出');

这样就可以在页面基于url的分布统计之外，另外通过页面别名实现另外一套可读性更好的映射统计，解决按目录，按页面类型，

2 对动态参数网页进行别名统计：Google统计会忽略掉动态网页 ? 后面的参数，但将 /?a=1&b=2 在统计中改写变成 /a/1/b/2 后，就可以通过pageTracker._trackPageview("/a/1/b/2") 后不修改URL也能变相统计出来；

3 结合前台js，cookie信息和后台注册信息和后台程序组合逻辑进行扩展统计：用前端脚本或者后台程序动态生成： pageTracker._trackPageview("参数") 实现更复杂的统计别名
例如：
用户注册天数： pageTracker._trackPageview("/user/age/203days")，用于登录用户的注册时间分布；
分析性别分布： pageTracker._trackPageview("/user/sports/male") 分析每个频道的用户性别比例；
记录用户ID： pageTracker._trackPageview("/username/chedong/channel_a") 导出报表后，结合用户数据库信息，获得每个用户在各个频道的行为特点；
区分referer：在同一个页面按referer不同分别进行统计：
pageTracker._trackPageview("/reg/from/partener")
pageTracker._trackPageview("/reg/from/baidu")

4 点出统计：通过onclick事件发出一个虚拟URL统计请求，这个机制可以用于统计flash，下载或点击到外站等无法部署统计代码的目标地址；

另外： Google提供的API大部分是部署时的接口/方法，更关心获得报表输出的批量导出API，据说正在开发中：近期只对Trusted Tester开放，这样就更加方便和其他报表系统/应用集成了；