BlogLines的Lines指的就说标题行吧？文章的标题非常重要，是用户从大量信息中进行过滤的首要来源。最好还是让订阅用户少点击一次比较好. FeedBurner和FeedSky都支持直接显示地址,文欣, zheng 改改吧？
相关文章|Related Articles
Feeds
3114 items (0 unread) in 19 feeds
«
Expand/Collapse
车东
-
喜欢 links for yyyy-mm-dd 和昨日收藏 这样的标题吗？
» 车东在我订阅的feed中,经常可以看到 links for yyyy-mm-dd 和昨日收藏这样的标题, 都是FeedBurner中合并的作者的del.icio.us和365key收藏. 尤其是在Bloglines和Google Reader/抓虾中订阅了大量的blog以后，浏览都会设置成只看标题, 这时候links for yyyy-mm-dd 和昨日收藏这样的标题对于快速浏览就没有什么信息了。以下是在GReader中每天链接汇总模式和条目列表模式订阅效果对比：
BlogLines的Lines指的就说标题行吧？文章的标题非常重要，是用户从大量信息中进行过滤的首要来源。最好还是让订阅用户少点击一次比较好. FeedBurner和FeedSky都支持直接显示地址,文欣, zheng 改改吧？
-
MTR和WinMTR
» 车东Linux上很多好工具要解决的问题（需求）可能别人多年前就也遇到过了，但别人不告诉我的话我就根本不知道它存在。第一次知道MTR还是在几年前和其他公司的工程师沟通XML接口速度问题的时候学到的，当时对方发来这样一个报表：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从搜索前端服务器到Google的XML接口之间的路由，和各个路由点的响应时间（包括最短，最长，平均）及丢包率一目了然。 利用报表中的提示搜索了一下，发现了mtr这个工具，以前需要多个ping和traceroute 命令实现的统计，用mtr集成在了一起。 WinMTR就是MTR工具的Windows窗口客户端，非常适合Windows用户做路由跟踪。 下载地址：winmtr.sourceforge.net 另外从统计中可以发现：中国的服务器IP地址很少能做出反相解析，但国外的服务器就比较规范。 这个是到yahoo.com的mtr统计：My traceroute [v0.71] chedong (0.0.0.0) Sat Jan 20 17:07:20 2007 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 60.195.249.1 0.0% 48 0.6 1.6 0.3 49.4 7.1 2. 202.99.57.141 0.0% 48 0.3 0.6 0.2 3.1 0.7 3. 202.99.57.13 0.0% 48 21.5 16.1 0.6 169.5 40.5 4. 221.239.18.125 0.0% 48 2.8 3.0 2.6 8.2 0.8 5. 221.239.7.49 0.0% 48 2.7 2.5 2.3 3.0 0.2 6. 221.238.222.213 0.0% 48 2.4 13.0 2.4 138.4 30.4 7. 202.97.34.225 0.0% 47 22.7 23.8 22.2 85.4 9.2 8. 202.97.37.53 0.0% 47 22.6 31.6 22.3 190.2 29.9 9. 202.97.33.90 0.0% 47 22.6 22.5 22.2 23.1 0.2 10. p16-1-1-2.r21.mlpsca01.us.bb.gin. 8.5% 47 166.3 167.1 165.7 188.0 3.8 11. xe-0-2-0.r21.plalca01.us.bb.gin.n 13.0% 47 169.2 169.9 168.6 190.7 4.0 12. xe-0-2-0.r20.plalca01.us.bb.gin.n 26.1% 47 265.7 268.5 260.4 299.8 7.0 13. so7-0-0-2488M.ar2.PAO2.gblx.net 19.1% 47 170.4 173.3 169.9 249.0 13.7 14. yahoo-1.ar2.PAO2.gblx.net 10.6% 47 179.1 183.0 178.8 286.6 16.7 yahoo-2.ar2.PAO2.gblx.net 15. ge-4-0-0-p440.msr1.scd.yahoo.com 6.5% 47 179.2 180.1 178.9 191.3 1.9 ge-3-0-0-p240.msr1.scd.yahoo.com ge-3-0-0-p251.msr2.scd.yahoo.com ge-4-0-0-p451.msr2.scd.yahoo.com ge-3-0-0-p250.msr2.scd.yahoo.com ge-4-0-0-p441.msr1.scd.yahoo.com ge-4-0-0-p450.msr2.scd.yahoo.com ge-3-0-0-p241.msr1.scd.yahoo.com 16. ten-2-3-bas1.scd.yahoo.com 8.5% 47 184.1 182.5 178.8 215.7 7.4 ten-1-3-bas2.scd.yahoo.com ten-2-3-bas2.scd.yahoo.com ten-1-3-bas1.scd.yahoo.com 17. w2.rc.vip.scd.yahoo.com 12.8% 47 179.5 179.7 179.0 180.8 0.5相关文章|Related Articles
-
多个服务器日志的排序合并
» 车东以前介绍过 sort -m 上的日志进行排序合并，但是最近发现有时候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' April 的时候出现排序倒错的问题了。 更可靠的一个工具就是logtools中的：clfmerge，合并速度比较快，而且对于日志跨天也没有问题。 当然，还有一个思路：就是将在多台服务器上的日志实时udp发送到1台（或多台）集中的日志服务器上，这样就省略了排序合并的步骤。并且适合后台快速分发到其他服务器上进行统计。相关文章|Related Articles
-
最佳拖延时间借口：更完美
» 车东最近连续看了3篇关于做事拖延的原因分析（2篇Solidot的科技文章，1篇桑林的网志），终于明白了原来最容易被蒙蔽的一个理由就是听起来要做一个更完美的解决方案。 假如听到类似的拖延理由而又没有分辨和控制能力的话：往往这就是失败的开始 1 针对这个问题有一个更加完美的解决方案，需要3个月完成； 2 需要从头开发一个专用的系统，这个系统会比以前的更加灵活； 3 需要对所有的数据进行一次地毯式的统计，精度高达4个9，需要2个月时间； 4 今天的时间不多了，留到有空闲时间的时候再将整将本书看完； 这些承诺的成功率和赌徒“下一把把输掉的全部赢回来”几乎是一样的。 解决的方法/策略： 1 事情没有容易和难之分，只有重要与不重要（重要性来自于数据分析）； 2 让拖延者自己订下完成时间：不要允许时间拖延，否则拖延本身就是给懒惰的奖励； 3 没有数字依据的问题：先定性，再定量； 4 对难以评估的陷阱有识别能力和免疫力；科学家发现了拖延法则 matrix 写道 "Science Daily报道Calgary大学教授Piers Steel（这位博士可能也许大概是拖延研究领域的权威）在《心理学报告》（Psychological Bulletin）上发表了一篇论文，标题为The Nature of Procrastination: A Meta-Analytic and Theoretical Review of Quintessential Self-Regulatory Failure。这项研究总结出几条让人吃惊的结论： 大多数人的新年许愿注定是失败的，大多数自助指南是完全错误的，它们认为完美主义是做事拖延的根源（为了把事情做的更完美，在时间上就...）拖延（Procrastination）可以用一个简单的数学方程式来解释。" 这项研究整整花了十年时间，但是没有迹象显示在研究开始之前它经过了多数次拖延。文章指出：" 从本质上而言，拖延者对自己缺乏信心，对自己事实上能完成的任务的期待并不高。完美主义者并不是不会犯错，完美主义者也会拖延，但是他们对拖延的过程表现的十分焦虑。" 勿以事易而为之 一段时间来体味着的“人生经验”是：勿以事易而为之。：） 也许有很多人和我一样，在处理工作和其它事务时，常常会列一下需要做的事情，然后选择容易的先做。这似乎是顺理成章的，因为这样能比较快地看到结果，而且显得比较有效率。 但是，我发现这些“容易”的事情并不见得容易结束，它们会源源不断引出其它事情。而列表里那些比较困难的，往往也是更重要的事情，因此被一再推后，总是遗憾地“没时间”做。 用自我约束的最后期限战胜拖延的陋习 "很多人常常面临这样的情况：本来手头有一大堆工作要做却故意拖延，上网去看看新浪的娱乐或者浏览热门贴的评论，要么干脆写日志。我们拖延重要的事情，像吸毒那样同时带有的负罪感和快感。这种拖延的吸引力在心理学上称之为hyperbolic time discounting（连续时间折扣），拖延的奖励相比浪费的是不对称的。换句话说拖延本身就是一种奖励。一位MIT的教授发现他如果让学生自己制定作业的最终期限(deadlines)，学生自己会抵制拖延。当然一个问题是学生设置的最终期限是宽裕的，有弹性而非最佳。多数有拖拉习惯的人的经验是提早开始工作。"
相关文章|Related Articles
-
twiki 4.1发布
» 车东twiki.org今天宣布： TWiki 4.1发布了。今天收到了一个TWiki Advocate（拥护者）的信：鼓励用户去TechCruch论坛发表评论。
关于TWiki 4.1： TWiki团队在1月17日在加州圣何赛宣布：TWiki 4.1发布。 TWiki目前由一个虚拟开源开发团队维护，目前共 26,700成员，4,000多代码开发者维护者和2百万企业用户。今天发布的4.1版的代码代号为Edinburgh（爱丁堡 TWiki一直使用首都名称做为版本开发代号，4.0版本为达喀尔，3.0版本为开罗）, TWiki 4.1的主要目的是让知识工作者能更方便的创建协同应用：包括数字表单计算功能，动态表格输出，幻灯片演示和Web 2.0的用户界面，并且完全免费。 TWiki做为企业内部关键服务在Google,摩托罗拉, SUN，雅虎有广泛的应用。更多信息请参考： [twiki.org] 我个人的使用经验：TWiki做为内部应用，还是非常强大的。但是做为公开的网站发布工具，由于性能问题（也是考虑到企业应用的权限等需求）：恐怕不是最好的选择。TWiki无法承受超过10个的并发访问，经常会由于个别蜘蛛的抓取导致系统负载很高。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 [forums.techcrunch.com] 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.
相关文章|Related Articles
-
Blog的目录结构优化
» 车东如果再建一个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/ 总体目录比较扁平而且不会有文件过于集中的问题； 这样规划的好处在于： 1 分布：文章/图片等文件能够按时间，按月分布在yyyy-mm目录下，不会因为几年的积累下来所有的文章都积累在archives/目录下。按一年发表300篇文章，加上图片，同目录下很快就会文件过多而不便管理；很难想像Jeremy：截至目前已经写了2355篇了（根据Monthly的归档数字），都在archives/008346.html 这样的目录下，目录浏览会很慢的； 2 导航： 所有文章所在目录也有缺省index.html页面，Google工具栏有个向上目录查找按钮。有了index.html就不会出现404找不到页面了；相关文章|Related Articles
-
如何通过正则表达式区分中英文
» 车东正则表达式用了几年了，本以为这个问题很简单：把所有查询关键词中纯英文(包括数字)的滤出来；但是折腾了一下午才总算找到了以下解决方法： 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； 有更简单的方法吗：请留言…… 尝试一： 为了解决滤出字母数字查询词，先是直接grep "^[A-Za-z0-9]+$"，但是总是滤出大量的中文 尝试二： 后来无意中发现使用egrep "^[a-z0-9]+$" 可以大大减少中文的量，推断关键词是GBK格式的，GBK和英文编码含有大量交叉； 尝试三： 在网上找到很多文档都是转载：使用 [x00-xFF] 这样的正则表达式，但是没有说明，其应用的环境是在javascript这样的环境中，js已经是将字符转换成unicode来处理了，这种环境在另外的开发环境中可能就不适用了 2007-02-18 卢亮的文章：对XML 进行 parse 时的Invalid Unicode character (0x0) 分析有更详细的阐释。字符编码方案是从一个或多个编码字符集到一个或多个固定宽度代码单元序列的映射。最常用的代码单元是字节，但是 16 位或 32 位整数也可用于内部处理。UTF-32、UTF-16 和 UTF-8 是 Unicode 标准的编码字符集的字符编码方案。 UTF-32 即将每一个 Unicode 代码点表示为相同值的 32 位整数。很明显，它是内部处理最方便的表达方式，但是，如果作为一般字符串表达方式，则要消耗更多的内存。 UTF-16 使用一个或两个未分配的 16 位代码单元的序列对 Unicode 代码点进行编码。值 U+0000 至 U+FFFF 编码为一个相同值的 16 位单元。增补字符编码为两个代码单元，第一个单元来自于高代理范围（U+D800 至 U+DBFF），第二个单元来自于低代理范围（U+DC00 至 U+DFFF）。这在概念上可能看起来类似于多字节编码，但是其中有一个重要区别：值 U+D800 至 U+DFFF 保留用于 UTF-16；没有这些值分配字符作为代码点。这意味着，对于一个字符串中的每个单独的代码单元，软件可以识别是否该代码单元表示某个单单元字符，或者是否该代码单元是某个双单元字符的第一个或第二单元。这相当于某些传统的多字节字符编码来说是一个显著的改进，在传统的多字节字符编码中，字节值 0x41 既可能表示字母“A”，也可能是一个双字节字符的第二个字节。 UTF-8 使用一至四个字节的序列对编码 Unicode 代码点进行编码。U+0000 至 U+007F 使用一个字节编码，U+0080 至 U+07FF 使用两个字节，U+0800 至 U+FFFF 使用三个字节，而 U+10000 至 U+10FFFF 使用四个字节。UTF-8 设计原理为：字节值 0x00 至 0x7F 始终表示代码点 U+0000 至 U+007F（Basic Latin 字符子集，它对应 ASCII 字符集）。这些字节值永远不会表示其他代码点，这一特性使 UTF-8 可以很方便地在软件中将特殊的含义赋予某些 ASCII 字符。
相关文章|Related Articles
-
流量统计：QihooBot来过
» 车东上个月底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检查文件是否更新过； 很多spider都喜欢说自己是微软的IE，其实没有必要。 正确的robots样例：都是有spider的说明页信息的。 Mozilla/5.0 (compatible; Yahoo! Slurp China; [misc.yahoo.com.cn] Mozilla/5.0 (compatible; Googlebot/2.1; [www.google.com] 更规范一些： 加上操作系统的名称 Mozilla/5.0 (compatible; SpiderName; System Name; [www.example.com] 这样便于awstats统计系统无法来源客户端的统计操作系统比例，目前我的服务器上是超过10%没有操作系统信息的，基本上就是RSS阅读器和各种蜘蛛的流量。相关文章|Related Articles
-
年终小结：2006
» 车东又到了年终小结的时候了： chedong.com: 网站大部分流量来源仍然是Google/Baidu。
不过今年的热门主题是：spoolsv和脑筋急转弯，完全是歪打正着。
2006最常用的几个软件和服务基本上和2005年的差不多，更多的是改进和熟悉使用。
在工具栏上增加了2个常用 [https服务：GMail和GReader。] GMail:
把 @chedong.com邮件先迁移到了DreamHost（先过滤一部分垃圾邮件），然后转发给GMail。
GReader：
GReader今年的改版回归了树型，速度上大大超越BlogLines。而抓虾很有潜力的是digg功能：RSS阅读和DIGG发掘机制的结合是未来超越单纯的RSS阅读和纯DIGG服务的方向。
BLOG发布平台MT：
MT经过几次升级后：仍然是我最主要的blog发布工具。了更多的spam问题和更多的spam解决方案，去年将一些文档计划的迁移到TWIKI的方案也由于性能问题而落空：twiki做为内部使用还是很好的，但是不适合对外的内容发布。
链接收藏：del.icio.us
图片收藏：FlickR
内容聚合：Lilina（缓存加速版）
日志统计分析：
对AWStats进行了不少定义改进：主要针对中国市场的搜索引擎和蜘蛛等定义。
Analytics：只是对部分页面进行了的少量取样统计，主要是获得需要JS获得的浏览器信息统计；
sort/uniq/egrep等工具的组合；
客户端软件：
尽量使用开源软件和免费软件。PieTTY（PuTTY的一个中文字符集修正版）和VIM（尽量不去碰UltraEdit，以避免产生倚赖）。FireFox2（若干插件）和FreeMind等已经成为使用习惯。
TOP
RSS
Atom
Powered by Gregarius
Design by eDWARD
© 2008 京ICP备6047014
Last Update: Sun 07 Sep 2008 08:35:43 PM HKT