车东[Blog^2]

又到了年终小结的时候了：

chedong.com:
网站大部分流量来源仍然是Google/Baidu。

不过今年的热门主题是：spoolsv和脑筋急转弯，完全是歪打正着。

2006最常用的几个软件和服务基本上和2005年的差不多，更多的是改进和熟悉使用。

在工具栏上增加了2个常用的https服务：GMail和GReader。
GMail:
把 @chedong.com邮件先迁移到了DreamHost（先过滤一部分垃圾邮件），然后转发给GMail。

GReader：
GReader今年的改版回归了树型，速度上大大超越BlogLines。而抓虾很有潜力的是digg功能：RSS阅读和DIGG发掘机制的结合是未来超越单纯的RSS阅读和纯DIGG服务的方向。

上个月底29日的统计发现当天流量超过了2G（平时都是低于1G的）：根据来源IP发现了蜘蛛，信息： Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; QihooBot 1.0)

本月截至昨天的流量统计： QihooBot的流量排在第一，加号后面是蜘蛛robots.txt的请求次数
QihooBot 10035 3.58 G字节 2007年 一月 03日 23:58
Yahoo! Slurp China 4586+33 8.41 M字节 2007年 一月 03日 23:59
Googlebot 4165+21 19.36 M字节 2007年 一月 03日 23:59
Sina Iask Spider 3544+1 16.18 M字节 2007年 一月 03日 15:46
MSNBot 3028+163 39.05 M字节 2007年 一月 03日 23:58
Nutch 2531+3 89.02 M字节 2007年 一月 03日 23:43
Yahoo Slurp 1879+341 9.50 M字节 2007年 一月 03日 23:59
发现Yahoo Slurp对于网站的请求越来越友好了，大量的请求都是304检查文件是否更新过；

正则表达式用了几年了，本以为这个问题很简单：把所有查询关键词中纯英文(包括数字)的滤出来；但是折腾了一下午才总算找到了以下解决方法：
iconv -f gbk -t utf-8 query_list |egrep -e "^[a-z0-9]*$"

1 为什么需要用utf-8： 如果直接对gbk编码的文字进行grep会由于编码中的交叉而滤出很多中文；
2 为什么需要用egrep： egrep=grep -E 就是正则表达式支持扩展字符集，扩展的正则支持用高八位字符；

关键：先将文本强制转换成UTF-8，然后利用egrep。
适用环境：Unix命令行模式下的grep；

有更简单的方法吗：请留言……

如果再建一个blog我会这样规划目录结构。

文章内容：
index.html 首页
tag-archive.html 分类或者基于tag的归档页；
yyyy-mm/index.html 按月归档；
yyyy-mm/dd-####-name.html 内容页；####为文章的编号，以备未来迁移映射需要；
atom.xml ATOM格式feed
index.xml RSS格式feed
tag-rss.xml 按分类的RSS输出

图片等文件：
/yyyy-mm/

总体目录比较扁平而且不会有文件过于集中的问题；

twiki.org今天宣布： TWiki 4.1发布了。今天收到了一个TWiki Advocate（拥护者）的信：鼓励用户去TechCruch论坛发表评论。

Because Wiki technology is "top of mind" in the blogosphere and press,we have the opportunity to dramatically increase awareness for TWiki as an open source alternative. To this end, I have started a thread on Tech Crunch Forums to alert everyone about TWiki and to pose the question, "What will it take for wikis to be officially sanctioned by the IT department?"

I encourage each of you to visit the forum at http://forums.techcrunch.com/forums/thread.jspa?threadID=856&tstart=0 and join the conversation. The more traffic this article gets, the more likely the Tech Crunch staff is to write about TWiki and our community, and the more likely that TWiki will be a hot topic in the blogosphere in general. Every click counts, so please take action right away.

最近连续看了3篇关于做事拖延的原因分析（2篇Solidot的科技文章，1篇桑林的网志），终于明白了原来最容易被蒙蔽的一个理由就是听起来要做一个更完美的解决方案。

假如听到类似的拖延理由而又没有分辨和控制能力的话：往往这就是失败的开始
1 针对这个问题有一个更加完美的解决方案，需要3个月完成；
2 需要从头开发一个专用的系统，这个系统会比以前的更加灵活；
3 需要对所有的数据进行一次地毯式的统计，精度高达4个9，需要2个月时间；
4 今天的时间不多了，留到有空闲时间的时候再将整将本书看完；

这些承诺的成功率和赌徒“下一把把输掉的全部赢回来”几乎是一样的。

解决的方法/策略：
1 事情没有容易和难之分，只有重要与不重要（重要性来自于数据分析）；
2 让拖延者自己订下完成时间：不要允许时间拖延，否则拖延本身就是给懒惰的奖励；
3 没有数字依据的问题：先定性，再定量；
4 对难以评估的陷阱有识别能力和免疫力；

以前介绍过 sort -m <(/bin/zcat /web1/access_log.20070120.gz) <(/bin/zcat /web2/access_log.20070120.gz) 对多台服务器上的日志进行排序合并，但是最近发现有时候cronolog截取日志并不干净，就是说按天截断的时候，还是有可能出现几条跨天的日志记录。March 31 => April 1时候日志排序倒错的可能性还是存在的。

最近才知道知道sort 还有-M模式，是可以对有英文月份的字段进行排序的：
-M An initial string, consisting of any amount of white space, fol-
lowed by three letters abbreviating a month name, is folded to
UPPER case and compared in the order `JAN' < `FEB' < ... <
`DEC.' Invalid names compare low to valid names.

这样就不会在 March => April 的时候出现排序倒错的问题了。

更可靠的一个工具就是logtools中的：clfmerge，合并速度比较快，而且对于日志跨天也没有问题。

 Host                                 Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 60.195.249.1                       0.0%    41    0.3   2.2   0.3  71.5  11.1
 2. 202.99.57.129                      0.0%    41    0.3   0.3   0.2   1.5   0.2
 3. 202.99.57.9                        0.0%    41    0.7  19.9   0.6 189.6  46.8
 4. 221.239.18.133                     0.0%    41    3.2   3.4   3.2   3.7   0.1
 5. 221.239.7.49                       0.0%    41    3.0   2.8   2.7   3.2   0.1
 6. 221.238.222.209                    0.0%    41    2.7  14.2   2.7 131.5  29.9
 7. 202.97.34.225                      0.0%    41   22.7  23.0  22.6  29.0   1.0
 8. 202.97.37.53                       0.0%    41   22.7  34.5  22.6 180.6  37.1
 9. 202.97.33.10                       0.0%    41   23.1  22.9  22.7  23.6   0.2
10. 202.97.33.54                       0.0%    40   24.4  31.6  23.1  44.9   6.0
11. 202.97.4.46                        0.0%    40   58.0  58.3  58.0  60.8   0.4
12. 216.239.47.237                    12.5%    40  188.2 189.2 188.0 204.6   2.8
13. 72.14.239.13                      10.0%    40  191.7 191.8 191.1 193.5   0.5
14. 72.14.233.55                       7.7%    40  192.0 191.4 190.7 192.2   0.4
15. 72.14.233.118                     12.5%    40  242.8 243.1 242.4 244.8   0.6
16. 72.14.236.183                      7.5%    40  243.7 243.5 242.3 250.9   1.6
    72.14.232.113
17. 66.249.94.118                     22.5%    40  242.7 247.9 242.7 255.7   4.5
    72.14.236.13018. eh-in-f99.google 10.0%    40  242.7 243.3 242.6 246.0   0.6

在我订阅的feed中,经常可以看到 links for yyyy-mm-dd 和昨日收藏这样的标题, 都是FeedBurner中合并的作者的del.icio.us和365key收藏. 尤其是在Bloglines和Google Reader/抓虾中订阅了大量的blog以后，浏览都会设置成只看标题, 这时候links for yyyy-mm-dd 和昨日收藏这样的标题对于快速浏览就没有什么信息了。以下是在GReader中每天链接汇总模式和条目列表模式订阅效果对比：