Tinyfool的开发日记(blog)

为自己设定一个极限是愚蠢的行为

Thu, 26 Jun 2008 01:51:52 +0800

最近一段日子的深夜或者凌晨，我总是在美剧的陪伴下仔细阅读和翻译《Google文件系统》的论文。翻译我做得不够完美，甚至谈不上好，但是这份工作带来的巨大的得道般的满足感一直支撑着我，让我不觉得疲倦。这本是我觉得自己不可能读懂的文档，但是真正深入的时候，我发现阅读它令我很快乐。

倒推10个月，在我和霍炬创办银杏技术咨询之前，我一直认为自己的性格不适合创业。但是现在我们用10个月良好的收入状况和日益增长的口碑，证明了我的论断是错误的。

再倒推到我的大学时代，我曾经认为自己会永远仅是一个VB高手。事实上后来，我轻松的学会了Asp，用它在大学赢了一个网站设计比赛，轻松学会BCB用它找了我职业生涯的前两个工作，轻松学会了Vc开发了365kit的outook插件，等等。而VB几乎已经7-8年没怎么用过了。

甚至，在某次刻骨铭心的恋爱失败后，6年中我以为自己会孤独一生，但我现在还是找到了相信可以步入结婚殿堂的人。

每次回想到这些，还有其他的一些另我自己唏嘘的往事，发现原来阻碍自己进步的，往往不是自己的能力和机遇，而是自己给自己设置的极限，而是自己以为的自己可以做到的最高点。

记得好像是李卫公同志哪篇blog提过龟兔佯谬，话说是只有学了极限才能最好的理解这个问题的实质。其实，这个有问题有个思维逻辑上面的解决方法，那就是你把过程抛弃，直接看N秒后，按速度×时间，很容易算出兔子一定在乌龟前面。

那么中间是怎么超越的呢，可以给出的一个简单的答案是，如果你太关心怎么超越的细节，你可能就真的很难超越了。So，把对手先隐去，跑吧！

所以，最好的对手是自己，最好的目标是无限远处……

technorati tags: 极限, 目标

[广告]雅虎寻找搜索竞价的福尔摩斯--竞价防作弊分析工程师

Thu, 26 Jun 2008 01:50:10 +0800

昨天跟车东还有一班雅虎搜索的高手们见了个面，聊了聊，他们正在努力与竞价广告中的作弊者作斗争，需要福尔摩斯的加盟，如何，你有兴趣么？

-------------

(现在是广告时间)

如果你对海量数据有较强的分析处理能力，能够透过数据发现一些潜在的问题；
如果你有超强的逻辑推理能力，能够敏锐的寻找到支持你论据的特征值，还原案发现场；
如果你对 SEO 或者点击器有一定的了解，做过这方面的探索研究或者是实践；
如果你曾经是一名站长，厌倦了江湖争斗，希望成为网络秩序的捍卫者...

那么你就是我们最合适的人选，我们诚邀你加盟我们(雅虎中国)的竞价防作弊Team，还我们的客户一个明亮纯洁的广告投放空间。

如果你不具备以上的条件，只要你有一颗正直的心，同时有希望成长为一个经验丰富的网络安全卫士的决心和勇气。当你具备以下技能后，你仍然可以加入我们的队伍。

1. 1 年以上工作经验。
2. 半年以上 Linux 使用经验。
3. 开发语言：Perl/PHP/Shell，熟练掌握其中至少1种。
4. 了解 HTML/JavaCcript 网站制作技术，具有网站制作、开发经验。
5. 有过海量(百万以上)数据统计、分析经验更佳。
6. 有一定的沟通能力，具有协同工作经验。

来吧！惩恶扬善，维护世界和平的重任就落在你的肩上了!

此时此刻，非你莫属!
感兴趣的朋友给车东发电子邮件吧:

technorati tags: yahoo, 广告

对lucene进行了一番性能测试

Thu, 26 Jun 2008 01:49:18 +0800

首先，我模仿lucene的Demo写了一个MakeIndex程序，其中也有类似Demo中的FileDocument类，分词采用的是IK_CAnalyzer 1.4。

然后，我对IndexWriter的合并因子对索引速度的影响进行了测试，同时我也测试了内存索引和硬盘索引的速度差别。测试文档为两份，3838个文件和11500个文件。数据如下：

结论如下：

在需索引文件数不大的情况下，合并因子对性能影响并不大。至少在万级水平，较大的合并因子才会对性能带来显著改进。这与我对合并因子的理解基本上一致。

内存索引在某些情况下居然会比硬盘索引慢，可能的原因是：1、内存在堆内频繁分配释放，浪费时间；2、本地文件读取在这次测试中耗时最多，索引时间较少，故而结果受到本地文件读取速度影响较大，所以测试时间颠簸超过了内存和硬盘的速度差。

总之可以证明硬盘索引效率很高跟内存效率差异不大。内存如果作为缓冲，而且尺寸选择得当应该会大幅提高效率，时间不足，就不做更细节的测试了。

接下来，我进行了不同索引方式（是否保存被索引的全文文本在索引中）的性能测试，测试文件是我收藏的中文小说的纯文本文件，经过分割和复制，有183888个，总尺寸为1207M，测试结果如下：

结论如下：

最快的是不保存耗时2930113/1000/60=48.8分钟，最慢的是4030653/1000/60=67.3分钟，效率还是另人满意的。压缩保存的时间开销完全可以接受，带来的膨胀率也完全可以接受。应该是最佳的选择。

以上程序，在我的MacBook上面开发，第一个测试在我的MacBook进行，Mac book的jdk版本为1.5，很稳定。第二个在我们的linux服务器上进行。Linux服务器原安装的是jdk 1.6，程序频繁无故锁死，找不到原因。后换为jdk 1.43，程序很稳定运行下去了。

我的估计是jdk 1.6还不够稳定，霍炬估计是程序中有跟jdk 1.6不兼容的部分，存疑与此。

update:在服务器安装了jdk 1.5也会频繁发生锁死，看来出现的问题可能跟1.5以后的机制改变有关，继续存疑。

technorati tags: lucene, 压缩, 合并因子, 索引

程序员的成长从开窍开始系列一、如何摆脱低级错误的困扰

Thu, 26 Jun 2008 01:48:19 +0800

原文：程序员的成长从开窍开始系列一、如何摆脱低级错误的困扰

最近，有两位Google Maps API的初学者向我请教他们按照最简单例子写的程序为什么不能正常的运行。

其中一位用GTalk跟我交流，我仔细了看了他的代码，没看出问题，把代码保存在本地，打开Firefox的错误控制台，用Firefox打开他的页面。出错的那一行被清晰的显示出来，我再仔细端详那句话，原来有两个应该是英文逗号的地方，写上了中文逗号。

另一位，在我的论坛跟我交流他的Google Maps API中遇到的问题，我看他代码的时候也没有马上发现问题。然而，同样在用Firefox打开后，问题很明显的找到了，原来是一个方法openInfoWindow被他写成OpenInfoWindow了。

在我帮助别人解决的程序调试问题中，这是非常常见的。人人都可能打出中文逗号，人人都可能把大小写写错。但是在我帮助他们解决问题以后，他们总是感慨的说，谢谢我解决了这个问题，这个问题困扰了他们几个小时，甚至是几天。

这其实并不是只有初学者才会遇到的问题，我还帮助过些有非常丰富经验的工程师解决问题，有时候问题仅仅出自某个参数没有传递进来，或者是拼接字符串的时候少些了一个冒号，或者是拼接地址的时候漏掉了http:。我甚至帮助一些人调试一些我根本不懂的语言的程序，因为多半出现的问题，都和语言特性无关，不是程序员写错了字符，就是写错了逻辑，或者是错误理解了一个函数。

出问题是正常的，写程序是一个复杂的边思考边打字的过程，笔误和一时糊涂都是难以避免的。程序员一般把这种问题叫做低级问题，因为这类问题跟你的智商完全无关，任何人都可能犯。

但是，问题在于，有时候即使是很优秀的程序员，也会被一个低级错误困扰，可能会几天都解决不了。所以，关键在于，如何找到问题。

遇到问题的时候：

不要怨天怨地。出了问题，当然有可能是系统的bug，API的问题，但是那些几率往往比你犯低级错误的几率要低多了，先从自己身上找原因，是不是自己写错了。
要掌握工具。最低限度你要会写Log，最好是Log和调试器结合。好的工具可以大大的提高效率。以前有人跟我说，Dll不能调试，我发现可以；有人说多线程不能调试，我发现可以；有人说COM不能调试，我发现可以；有人说 IE插件不能调试，我发现可以；有人说OE插件不能调试，我发现也可以。当然，你确实会遇到不能调试的时候，当年我们做东芝芯片的嵌入程序，一个组都没有一个仿真器和调试器，但是至少可以用Log嘛，无非是麻烦点。
分析问题要有逻辑。遇到问题可以先把所有的可能性都列出来，然后一个一个分析，肯定能找到原因的。
要学会隔离问题。问题涉及到的代码越多，越难以理解，问题越难以解决。遇到这样的情况，可以利用Log或者调试器，一行代码一行代码的给它们洗清嫌疑，这样很快你就可以找到出问题的地方。如果代码特别长，程序特别复杂，可以用二分法来做，效率很高。
千万不要懒惰，不要事事求别人。一次复杂的调试过程就像一部侦探剧，如果你有非常好的逻辑性，那这部剧的主角就是福尔摩斯，剧情一定非常精彩。我说这个是有巨大风险的，说真的我帮人调东西挺上瘾的，很有意思。但是我还是要告诉大家，一次高难度的调试之后，你的满足感绝对不亚于写了一个伟大的程序。

要想不遇到问题，写代码的时候：

要对写出来的代码负责。我很佩服那些写代码写100行都不执行一次的高手，如果他们最后不被低级错误困扰的话我就更加的佩服了。我写程序几乎是写一行两行就要执行一次，每句话我都要确保执行效果跟我的预期一致。没错这样写的时候可能慢一些，但是调试的时候很轻松，我可以很简单的确定哪些代码绝对没有问题。所以我写代码整体速度比一般人高。很多人学习新东西的时候喜欢把例子抄一遍，运行一下，改改，再运行。我喜欢一句一句的抄例子，抄一句两句执行一次，这样可以把例子透彻的理解，而且很难会遇到出现了问题找不到原因的时候。
函数体功能块不要过长。我认为我的智商并不高，我很难接受一个程序的一个函数体或者一个功能块超越3屏（当然逻辑真的有那么复杂除外，你会发现越是简单的逻辑越是容易被人写的冗长）。很多人对面向对象耳熟能详，对封装继承看起来驾轻就熟。但是动不动就写出来个函数体超长的程序。这就像写本书从头到尾不点句号一样，会累死读者的。自己看的时候，估计也会被累的喘不过来气。这是我对基础教育的微词所在，他们连教会学生写函数都没教会，虽然表面上他们连面向对象这么高深的东西都教。
缩进要对。这点很重要，虽然大部分语言不是像Python那样用缩进来决定逻辑块的位置，但是人看到缩进的时候，总是会以为这些缩进位置跟逻辑相关。尤其是在有大量的ifelse或者for循环等等的嵌套逻辑的时候，如果缩进错了，可能会直接让人把程序的逻辑读错。所以我拿到别人的代码，第一件事情就是整理缩进。我见过一些比较优秀的页面工程师，他们会在div结束的位置用注释写上这个div的id，这样层级关系就一目了然了。
不断重构。随着程序的不断修改，有些部分会不断的增长，原来看着清晰的架构可能因为问题的复杂而慢慢模糊，也可能被修正bug的权宜之计弄的面目全非。不信你找一个经过多次修改的程序看看，是不是满目疮痍，是不是都很难认出是你自己的作品了。这在多人参与的项目中更加严重，每个人有不同的代码风格，经过多次杂交后，你肯定认不出你的代码是骡子是马，还是四不像了。随着程序的慢慢成长，原来有些函数体会慢慢膨胀，需要拆分；有些原来简单的功能块四处都需要，应该被提炼成函数或者方法，等等。现在不重构，未来等到代码复杂到无法控制的时候，重构的工作就会变得更加困难。我见过最强的案例是，一个几千行的电子辞典配套联机软件，经过无数次的改版，变成了一个几乎无法维护的主窗体的cpp有1万8千行的怪物。最后经过复杂的重构，才变成一个出新版本只需要新增一个驱动程序的可以维护的几千行的程序。这个故事详见：一个具体项目的重构（一），一个具体项目的重构（二），一个具体项目的重构（三）。

technorati tags: log, 调试, 重构

我最近关于Google Maps API的几篇文章

Thu, 26 Jun 2008 01:47:24 +0800

最近，因为做了一个讲座，感受到了大家对Google Maps API的热情，我又开始比较勤奋的更新我Google Maps Api中文非官方Blog，希望给对Google Maps API感兴趣的朋友更多帮助。

最近更新的文章有：

翻译的文章有：

也欢迎大家订阅Google Maps Api中文非官方Blog，订阅地址是http://feeds.feedburner.com/GoogleMapsApiblog。

technorati tags: google maps api

[搜索引擎友好之路]搜索引擎优化常见问题与回答

Thu, 26 Jun 2008 01:46:32 +0800

[搜索引擎友好之路]是我准备写的一本书，现在大部分网站都有丰富的内容，但是他们为了得到流量去尝试那些搜索引擎作弊方法，往往是一时得到好处，最后被搜索引擎屏蔽。我们倡导的与搜索引擎友好的优化方式就是试图更好的展现你的内容，达到网站和搜索引擎共赢的局面。下面的问题是一次去给客户做培训后，客户提出的问题和我们的回答。

1、程序生成很多的静态内容链接自己，算不算作弊？

一个行为算不算作弊，主要是度的问题。生成很多垃圾的静态内容（采集来的，胡乱生成的），只要达到一定的量，一般是会被判定为内容重复或者作弊的，可能会被降低权重或者删除索引。实际上我们知道现在很多网站自己的内容很丰富，把自己的内容展现好了，就会带来很多好处，不需要去胡乱采集。

2、flash对网站收录的影响

flash本身没有任何不好的影响。而常见的错误的行为是对flash的滥用。
比如，整站全部用flash，设计者或者唯界面论者可能会这么做。其实这样并不好，第一是速度往往会很慢，而且有可能会长时间等待；第二是干扰用户习惯，很多人打着提高用户感受的旗号去滥用flash，那样做出来的作品，如果说欣赏或者只是试用往往还不错，长期使用用户往往忍受不了；第三是整站所有的内容无法被搜索引擎收录。
还有很常见的滥用是内容页面很丰富，但是首页只有一个flash而没有任何文本链接可以帮助用户进入下一级页面。这类问题往往出现在一些大公司的网站中。虽然确实很美观，但是问题也很多。第一也是速度，网民多数没有耐心，看到一个长长的loading条就会迅速离开；第二，如果用户不安装flash插件，就无法看到首页，从而无法进入本无需flash的内容页；第三，搜索引擎无法穿过首页去访问后面的页面。所以我们会发现很多公司的网站pagerank很高，但是内容页面完全没有pagerank。所以在搜索引擎搜索产品名字，往往是第三方的网站排在前面。这类网站最好在下端放一个二级栏目的导航条，至少也要放一个“点击这里跳过flash直接进入内容”的链接。

3、no script有用么？

当然有用。现在很多网站喜欢用Javascript特殊效果或者Ajax，这本身没并不是问题。但是，如果用Javascript来显示网站的导航，就有两个问题，第一，对于不打开Javascript的用户，他们无法进入网站的内部；第二，搜索引擎往往无法收录Javascript展现的链接。no script可以解决这个问题。包含在 noscript标记内的代码会在不打开Javascript的用户的浏览器上面展现，搜索引擎也可以从中获取导航信息。
但是，最好的选择还是，导航本身使用标准HTML代码，导航的特殊效果用css和Javascript实现。以后我们会有专门的文章阐述Ajax网站如何进行搜索引擎优化。

4、更新频率应该多高才适合？

更新频率理论上当然是越快越好，但是并不推荐没有内容胡乱更新。现在大部分网站的内容都很丰富，更新频率已经足够了。

5、js生成的更新，能不能被收录？

跟Javascript有关的问题，答案其实都一样，用Javascript生成的链接，大部分搜索引擎的爬虫不会去抓取，自然也就不会被收录了。

6、不愿和外部网站交换链接会有什么影响？

不愿意交换链接自然对Pagerank有不好的影响。但是如果你的内容确实好，自然会有用户主动链接你的页面，这样你的PageRank自然会得到提高。

7、抓外站新闻对SEO有用么？

用处不大，抓外站新闻得到的内容实际上都是所谓的重复内容，价值并不高。

8、和外站交换链接，放什么位置重要么？

重要，当然是Pagerank越高的页面越好，位置越前越好。

9、大型网站会给其他网站做链接么？要多少钱？

交换链接一般是双赢，所以只要你的网站质量达到一定水平，交换链接并不难。一般不要钱，要钱的反而需要警惕，这是搜索引擎禁止的行为。

10、在网站中，同一级的页面，是PageRank越高，抓取频率越高么？

对，Pagerank、整站信用级别和页面更新频率共同影响抓取频率，所以Pagerank越高抓取频率越高。

11、Robot.txt对SEO有什么影响？

Robot.txt很有价值，但是一般被站长低估和误解。很多人认为只有防止搜索引擎技术抓取的时候才有用。但是实际上正确使用Robot.txt对 SEO很有好处，比如重复内容用不同形式表现是经常需要的，而这种情况很容易被搜索引擎判定为重复内容堆砌。正确利用Robot可以引导搜索引擎只收录首选内容这样就不会有作弊嫌疑了。（参见：google网站管理员blog的文章“巧妙地处理内容重复”）
除了处理重复外，Yahoo允许你在Robot.txt文件里面用Crawl-delay:参数设定抓取频率（参看：如何控制Yahoo! Slurp蜘蛛的抓取频度）。Sitemap协议支持你在Robot.txt文件里填写Sitemap参数（参看：Specifying the Sitemap location in your robots.txt file）。

12、二级域名能有多大的好处？

好处不大，如果用户喜欢的话，就用吧。

13、用户页面的url，用文字还是数字好？

如果用户名不允许中文，那么文字比较好，虽然汉字也可以用在url中，但是总是有些浏览器的支持不够好。如果用户名允许中文，就用数字吧。基本上这不是一个很重要的选择，虽然搜索引擎技术也会把url里面的文字当作可被查询的内容。

14、flash meta data对SEO有何影响？

未来可能很重要，但是现在应该还没有多少搜索引擎支持这项技术。

15、爬虫有没有关于Ajax的抓取计划？

Googlebot也就是Google的标准蜘蛛，是不支持Javascript的。但是Mediapartners-Google也就是Google Adsense的爬虫，实际上是支持Javascript的。这也就是说技术层面考虑支持Javascript并不是一个问题。但是限于效率和任务优先级的考虑，Google暂时还没打算让标准蜘蛛Googlebot支持Javascript。
百度的爬虫支持一部分Javascript，但是由于技术和效率的限制，相信百度也不能抓取100%的Javascript内容。

16、在js代码中放url有用么？

答案显而易见，没用。

Virushuo对本文亦有贡献

technorati tags: flash, Javascript, noscript, Pagerank, Robot.txt, seo, 搜索引擎优化, 搜索引擎友好

php和.net中的Md5函数如何兼容

Thu, 26 Jun 2008 01:45:23 +0800

最近在做一个php和.net共同组成的项目，接收.net部分传送过来的一个经md5过的数据，我惊奇的发现，居然和php进行md5的结果不同，这是为啥呢？

.net端程序是这么写的：

System.Text.ASCIIEncoding encoding=new System.Text.ASCIIEncoding();
byte[] bytesSrc = encoding.GetBytes("xutf");
System.Security.Cryptography.MD5 md5 = new System.Security.Cryptography.MD5CryptoServiceProvider();
byte[] result = md5.ComputeHash(bytesSrc);
string keyMd5=Convert.ToBase64String(result);

输入的"xutf"，得出的结果是"5j1NYFDLhM9dc/XOfRwkyg=="。

php端程序是这么写的：

$keymd5=base64_encode(md5("xutf"));

同样输入"xutf"，得出来的结果却是"ZTYzZDRkNjA1MGNiODRjZjVkNzNmNWNlN2QxYzI0Y2E="。

这样下去，程序没法写了，同样的操作为什么结果不同呢？

原来php的md5函数输出的结果是转换成16位表示的md5结果，而.net的md5.ComputeHash方法输出的结果是原始的md5结果。（注：php5的md5函数string md5 ( string str [, bool raw_output] )开始支持输出原始结果，参数raw_output只支持php5，但是我在使用php4）

如果想让php的结果等同于.net的结果，那么需要对md5函数的结果进行16进制字符串到标准字符串的转换。
那么php程序应改为：

$md5hex=md5("xutf");
$len=strlen($md5hex)/2;
$md5raw="";
for($i=0;$i<$len;$i++) { $md5raw=$md5raw . chr(hexdec(substr($md5hex,$i*2,2))); } $keyMd5=base64_encode($md5raw);

如果想让.net的结果等同于php的结果，那么需要把md5.ComputeHash方法输出的结果转换成16进制字符串，那么.net程序应该改为：

System.Text.ASCIIEncoding encoding=new System.Text.ASCIIEncoding();
byte[] bytesSrc = encoding.GetBytes("xutf");
System.Security.Cryptography.MD5 md5 = new System.Security.Cryptography.MD5CryptoServiceProvider();
byte[] result = md5.ComputeHash(bytesSrc);

StringBuilder sb = new StringBuilder();
for (int i = 0; i < result.Length; i++)
sb.AppendFormat("{0:x2}", result[i]);
string s1=sb.ToString();
byte[] bytesmd5 = encoding.GetBytes(s1);
string keymd5=Convert.ToBase64String(bytesmd5);

technorati tags: dotnet, md5, php

对Java处理XML性能的比较（DOM和SAX）

Thu, 26 Jun 2008 01:44:40 +0800

测试数据是结构很简单的一个20M的XML文档，里面的数据来自我的一个项目。测试程序很简单，就是读取这个XML文件，把里面的链接写入到一个文本文件。然后把数据原样重复了一遍，然后又测试了一次，下面是测试结果。

方法	数据大小	内存峰值	CPU峰值	耗时
SAX	20M	20M	30%	142秒
DOM	20M	152M	100%	171秒
SAX	40M	20M	30%	290秒
DOM	40M	345M	100%	376秒

表1 SAX和DOM的性能比较

结论：SAX的内存消耗稳定，CPU占用率低，耗时短，大数据量XML的简单处理一定首选SAX。DOM的性能受到内存的严重影响，内存消耗受到数据量的影响，大数据量XML的读处理最好不要用DOM。

technorati tags: dom, sax, xml

DreamHost值得推荐吗？我看不值得！

Thu, 26 Jun 2008 01:42:29 +0800

之前有不少Blog用了DreamHost，还做了推荐，我的Blog一直在国外，所以也就没有凑热闹。

所以，头些日子听说DreamHost摆了一个大乌龙的时候，我自然可以幸灾乐祸一番。上次的乌龙不清楚的朋友，可以看看这篇文章《DreamHost 大乌龙事件及众生相》。大概过程就是DreamHost的联合创始人乔希·琼斯在对2007年欠费用户催缴时，写错了程序的参数，把2007写成了2008，这样本来不需要付款的无数用户就自动被扣了11个月的租用费，这是个 7,500,000 美元，甚至引发了些用户对网络服务自动扣款是否安全的讨论。

这当然是无心之失，虽然对很多客户损失重大（可能会造成一些客户信用卡透支），但是我认为还是可以原谅的，因为总归不是故意的，成熟商业社会里，只要生意还做得下去，估计没人会白痴到故意提前扣款，那么多用户，与其提前扣款赚一笔跑路，自然不如老老实实的服务客户，争取让客户多享受几年服务。

问题是这样的，头两天有个朋友告诉我他的blog被Google清出索引有些日子了，他怀疑是Google认为他的链接太多了。

我看了看链接其实不算多，而且也没有任何明显的作弊的迹象，这位哥们人品虽然谈不上值得称道，但是多半也是不会作弊的。

那么帮他申请个Google Sitemap，看看他的网站到底出了什么问题吧。谁知道，一确认，才发现GoogleBot报警说，无法访问他的网站，错误号是403。

网站访问毫无问题，那么看来这个403是专门针对GoogleBot的，你不让人家抓你，人家凭什么索引你呢，呵呵。

问问哥们，他说自己没做过任何的设置，那么多半就是空间服务商干的了。哥们说，他在用DreamHost，在Google一搜“dreamhost 403 googlebot”，马上就找到了两篇文章《Errors with .htaccess : Site Down with 403 Forbidden Errors》和《Is Dreamhost support stupid or am i missing something?》。

一看才知道，果然是DreamHost干的，他们刻意在一些客户的根目录的.htaccess文件中加入

<limit>
order allow,deny
deny from 66.249
</limit>

服务器有过多的GoogleBot访问造成压力，临时做些解决方案，暂时封锁GoogleBot倒是不稀奇的。但是，一来，做这个操作完全不通知客户，太不负责任；二来，我那哥们的blog已经很久不能被Google访问了，看来DreamHost的如意算盘是如果客户不知道，就这么一辈子节省流量，反正客户发现Google不收录，多半以为自己有什么操作过分了，或者直接以为Google抽风了。

So，DreamHost的行为是故意的，而且完全不考虑客户的利益和感受，十分卑鄙，值得鄙视，不值得推荐。另外，DreamHost中国人用得极多，容易被GFW，也不值得被推荐。

technorati tags: DreamHost, google, htaccess

Google、微软还是好耶的黑色幽默？

Thu, 26 Jun 2008 01:41:09 +0800

刚才要下载Mac版本的Mysql，所以去Google搜索Mysql，不过突然搜索结果右边的广告吸引了我。微软买了Mysql这个关键字，还要在广告里跟IBM的数据产品叫板多好玩啊。

可是，我点了之后，居然只看到一条错误信息：
Database not found!totaldb=0 dbname[1]=

我靠，难道是跟IBM比谁更幽默么？那估计微软要赢了。仔细一看地址是
http://mccannafa7.allyes.cn/main/adfclick?db=mccannafa7&bid=12680,6073,50&cid=6371,289,1&sid=12210&show=ignore&url=http://www.microsoft.com/china/sql/prodinfo/compare/default.mspx

原来问题出在好耶身上，微软的地址 http://www.microsoft.com/china/sql/prodinfo/compare/default.mspx 其实可以访问。

只是在宣传数据库的广告上，广告系统的数据库崩溃了，总让我觉得很有点黑色幽默。这更说明了数据库的重要性，不过好耶的数据库用的是谁家的，我还真是不太清楚，哈哈。

technorati tags: google, 好耶, 微软

Java网络服务如何能长时间稳定运行呢？

Thu, 26 Jun 2008 01:39:14 +0800

今天，把Code里面的e.printStackTrace全部用自己的log函数替换掉了，因为貌似System.out.println很浪费时间，而且大量的异常输出到控制台会降低程序的稳定性。

我们的项目里面需要一个webserver，但是我实在对Jsp+Tomcat的性能不放心，自己写了一个非常精简的webserver。性能我很满意，用ab进行测试，速度可以跟同台服务器上lighttpd静态文件的速度媲美。

在每日访问量10万以内的情况下，服务两个星期左右会产生一次锁死，kill也无法关闭进程。只有利用kill -9才能关闭进程。说实话，这种锁死频率倒还可以接受。然而在每日访问量峰值达到20万的时候，高峰日可能会有2-3次的锁死，这让我很挠头。我想了很多办法，还是没有明显的改善。

今天去掉了e.printStackTrace，希望明天webserver的稳定性可以提高。

有对这方面经验丰富的朋友么？请告诉我Java网络服务如何能长时间稳定运行呢？谢谢！

technorati tags: java, log, printStackTrace, System.out.println, webserver

错误信息org.xml.sax.SAXParseException:Parser has reached the entity expansion limit "64,000" set by the Application.啥意思？

Thu, 26 Jun 2008 01:38:01 +0800

最近一个处理非常大的XML的程序遭遇了如下的异常：

org.xml.sax.SAXParseException:Parser has reached the entity expansion limit "64,000" set by the Application.

查了查，原来是在单个xml文件中实体引用超过了默认值64000个。你用dom和sax解析XML都可能会遇到这个问题，这印证了我的猜测，java的dom是用sax来实现的。

解决方法很简单，运行Java的时候，加上参数-DentityExpansionLimit=xxxxx，你也可以在代码中解析XML前，用代码设置这个参数System.setProperty("entityExpansionLimit", "xxxxx");。xxxxx代表设定的单文件实体引用数最大值。

--------

那么这个xxxxx该怎么选择呢？

其实也很简单，选择你认为可能出现的最大值就好了，比你的文件里面的实体数多，自然就没问题了。

--------

那么如果你想知道某个文件里面有多少个实体引用该怎么办呢（放心我肯定不建议你去数）？

对，也很简单，首先我们知道实体引用都是“&"开头“;”结尾，所以我们可以用如下命令来计算：

grep -c "&.*;" yourfile.xml

其实，&在xml里表示为&的形式，所以，一个合法的xml内，有多少&就有多少实体引用，so，上面的命令效率更高的版本是：

grep -c "&" yourfile.xml

--------

为什么会对最大的实体引用数做出限制呢？这点我有些疑惑，难道要为解析实体引用准备缓存空间？但是做出来自动增长的缓存也不是不可能的啊。DentityExpansionLimit参数的问题是，如果要处理无法预期大小的xml文件怎么办？你设置为100万，xml文件里面有200万个实体引用，你有办法么？

technorati tags: DentityExpansionLimit, dom, Javascript, java异常, sax, SAXParseException, xml

CSDN 2007英雄大会印象

Thu, 26 Jun 2008 01:36:59 +0800

早晨8点多，我就出门坐300路从双井出发，只奔遥远的中关村方向而去。不是去上班（我和霍炬开的公司，我们都不坐班，平时在家或者各大小有无线网络覆盖的咖啡厅办公），不是去见客户，而是去参加CSDN 2007英雄大会。虽然我每天即使最晚8点半也起来了，但是，已经至少有半年，我没有在早晨11点之前离开过家了。

会场在原来的天鸿科园，我在那里参加过很多IT方面的会议，几乎每次三楼的主会场人数至少都要超员一倍左右。而这次CSDN的英雄大会，主会场站着的人并不多。我想，程序员是多么散漫的人们啊，即使被称做了英雄，大家还是那么的不积极。

然而最后我发现我错了，所有其他我参加的那些会议，虽然开幕的时候人山人海，但是两个演讲后，会场就会空置大半。但是这次CSDN的英雄大会，从9点半开幕，到下午结束，人始终是那么多。我想这能说明这个会凝聚力很大。

凝聚力很大，一方面当然是要称赞CSDN这个活动搞的好啊；而另外一方面，就要批评CSDN同类活动搞的少了。很多朋友即使神交，网聊很久，没有这样的会往往也难得一见。这也就怪不得程序员们逮到了这种机会就三五成群神聊起来了。

这样的活动，按我的想法，一个月搞一次都嫌少，呵呵。

technorati tags: csdn, 英雄大会

CSDN上我的专访

Thu, 26 Jun 2008 01:36:40 +0800

专访郝培强：两周精通Python的技术达人
http://news.csdn.net/n/20070614/105339.html

题目比较狂，呵呵，下面骂声一篇，还好我脸皮厚，也不觉得什么。

technorati tags: csdn, tinydust, tinyfool, 郝培强