Tinyfool的开发日记(blog)

beta技术沙龙第四期[iPhone开发入门]我的总结

2009-06-03T14:25:00.004+08:00

beta技术沙龙虽然一月才搞一期，但是转眼间也搞了有4期了。每次我都没有写过总结，这点总被火炬和余晟老师诟病。本来为了表示我的清白，我准备别人主讲的活动我不总结，自己主讲的活动就也不总结（看，我还是天才吧，给自己的懒惰找的借口多冠冕）。但是，算了，人总是偶尔要勤快一点的。

我和Robinlu在等待开始

这期活动搞iPhone OS开发入门，主要原因是在最近的一个多月来，很多朋友都在问我一些iPhone OS开发相关的技术问题，还有很多朋友询问我iPhone OS开发难度到底如何。很多人对这个越来越火的平台非常感兴趣，但是对iPhone OS开发到底是什么样子，却没有感性的认识；有些朋友虽然已经开始进行iPhone OS开发，但是总是被一些或大或小的问题弄的焦头烂额。在我开始进入iPhone OS开发领域近一年的这个时候，我觉得有必要给朋友们介绍一下，这到底是怎么一回事。

我的朋友Robinlu是比我技术高得多的高手，他的Blog就介绍过iPhone OS开发中内存管理需要注意的事项。

我们对iPhone OS开发都有兴趣和一些经验，所以合作了这次活动的演讲，我来负责前面简要的介绍这个平台，开发工具，开发流程等等。他来讲主要的设计模式，注意事项以及技术难点。

现场的气氛很好，朋友们没有因为我的迟到而生气，令我很感动，谢谢大家。Robinlu觉得我们两个人的演讲都稍微简单了一点，但是非常活跃的问答环节，解决了这一问题。在问答环节中，iPhone和gPhone的比较，对平台的看法，对跨平台的看法，对内存和性能的看法等等等等，很多有深度的问题，给我们的演讲做了最好的补充。可惜问答没有被记录和整理，不然就会是一篇非常好的FAQ了（这个争取在以后的活动中改善）。

所有说来没来的兄弟们，没来是你们的损失；所有本来就不知道这次活动的朋友们，呵呵，记得follow我们beta沙龙的官方推特@betasalon，活动的通知会发布在那里。

最后大家可以在这里在线查看我和Robinlu的keynotes。

顺便公布我翻译的4篇iPhone开发入门的文章，点击代码中国iPhone OS开发专区。

我的搜索历史就像我的作息时间表

2009-05-21T10:54:00.002+08:00

刚才打开Google搜索历史看了一眼，发现Hourly search activity（按小时统计的搜索行为）简直可以说就是我的作息时间表。建议以后Hourly search activity作为个人病例的一部分，几点起床，几点睡觉，几点吃饭，简直是一目了然。

beta技术沙龙第四期[iPhone开发入门]活动预告

2009-05-14T16:48:00.005+08:00

UPDATE:最新消息，人邮图灵的主编刘江老师资助本活动5本图灵出版的《iPhone开发基础教程》（这本书很经典），我们将在活动的结束的时候抽奖，每个参加活动的朋友都有机会。感谢图灵和刘江老师。

时间：5月24日14点30分开始
地点：奇遇花园咖啡馆（点击查看详细地址）

主题：iPhone开发入门 & iPhone开发中的内存管理和性能优化

主讲人：郝培强（银杏）、陆亦斌（iPhone应用程序iChm开发者,财帮子网站共同创始人）

简介：本次活动介绍iPhone开发的入门知识和开发工具简介，帮您从新手快速进入iPhone开发领域，我们也邀请了经验丰富的iPhone开发者分享他们的开发经验和思想，探讨关于内存管理和性能优化等高级话题。

参与人员：最大的前提是技术出身，第二个要求是写blog。积极参加现场沙龙聊天；如有可能对话题通过blog保持跟进关注。http://club.blogbeta.com/ 网上报名或直接现身沙龙，参与免费，点单另付。

关于沙龙：blogbeta技术沙龙由一群技术人员发起并参与，旨在以技术的视角看待社会、互联网和未来，以务实精神深化交流，促进创新。

[PHP]发布一个小代码“静态文件的Rss生成器”

2009-05-06T23:00:00.013+08:00

最近做了一些Web开发，对PHP的了解开始加深，才发现自己以前写的PHP程序确实可以用，但是PHP很多有用和有意思的特性，我却完全不了解。

正如去年看到大鱼儿写的《习惯成自然》，吓了我一跳，我也一直以为纯PHP文件以<?php开头以?>结尾是个好习惯，谁知道实际上好的习惯是文件结尾最好不要有?>。又比如以前我一直是一个用英文句号（.）的高手，多复杂的字符串都是用英文句号来拼接的，看到$xxx="this is a $test";的时候还会以为人家写错了呢。

所以，我在做Web开发之余，开始翻译PHP的手册，每翻一章都发现自己知道的东西更多了，很有意思。这当然是一件非常重复发明轮子的蠢事，但是翻译是我学习英文资料的最好办法，所以就翻吧。然后，当我想把我翻译的进度弄到我的微尘程序员网站首页时，遇到了点麻烦，我怎么把这些一直在变的静态文件的最新进度同步上去呢？所以就有了这个简单的代码，“静态文件的Rss生成器”。

代码的逻辑很简单，使用ls -t获得以更新时间顺序排列的文件名，然后用head取前几个文件。然后，获取文件的标题和时间，生成xml。整个操作在我的本地很快，不过在我的虚拟主机上很慢，所以，实际使用中，我定时一个小时生成一次静态的XML。

代码的文本格式版本，请点击这里。

也欢迎对翻译进度感兴趣的朋友们订阅以本代码生成PHP中文手册翻译进度的RSS。

To所有人

2009-04-01T11:05:00.002+08:00

今年的2月，毫无意外的我30岁了；3月3日我的女儿诞生了；前两天我对老婆说，我离40岁还有10年，应该还能做出点什么。

但是不管你做出了多么伟大的事情，没有happy ending，只要你还活者，人生就是无尽的旅程。面对你以为的伟大成就，人们只会微笑，拍下你的肩膀，鼓励你继续前行。何况你还什么都没有做出来呢，所以，继续前行吧…

Jeff Dean 在WSDM 2009上面的演讲 Keynote 和视频终于出来了

2009-03-16T13:22:00.005+08:00

从2月17日到昨天，将近一个月我终于等到了Jeff Dean的演讲Keynote和视频。昨天我一整天把整个英文版的Pdf翻译成了中文，放在了Google Doc给大家分享。

前面我翻译了Geeking with Greg写的Jeff Dean keynote at WSDM 2009，以及Michael Bendersky听该演讲的笔记，他们虽然写的都很好，但是原汁原味的Keynote显然有更多有价值的信息在里面。昨天一天我的翻译工作都是在非常愉快的心情下度过的，一种得道般的快乐始终伴随着我。以前对Google架构的猜测有些得到了证实，有些则证明是完全猜错了。比如我一直以为Google的索引是按照词来切分的，但是这次Jeff Dean的Keynote讲得很清楚，按文档和按词切分的利弊，以及Google为什么选择按照文档来切分。所以，每个关心Google核心技术的朋友，我建议你们好好看看这个 Keynote。

因为有人抱怨在我的blog内嵌入Keynote会造成google reader的窗口跳转，所以我把嵌入的Keynote取消了，请大家点击下面的地址：

中文版Keynote观看地址为：http://docs.google.com/Presentation?id=afdfdfhqkrd8_1098qht7ggj

英文版Keynote下载地址为：http://research.google.com/people/jeff/WSDM09-keynote.pdf

视频观看地址为：http://videolectures.net/wsdm09_dean_cblirs/

Google核心技术为：GFS / MapReduce / Bigtable ，再加上这个Keynote基本上就算齐了。

[SEO]如何解决重复内容问题-Google Yahoo MS的回答

2009-02-26T13:56:00.005+08:00

这里说的重复内容问题不是指的由非法转帖造成的重复内容，而是由于很多CMS设计不好，或者有些网站利用链接参数跟踪用户行为（我们的一个咨询客户这方面就很严重，造成的结果是收录率极低，搜索量自然也极低），造成的在同一个网站同一个内容有多个链接的问题。

这种问题长期得不到重视，因为网站主和技术人员往往意识不到这对他们会带来什么样的恶果。简单的说：

搜索引擎不知道哪一个是权威的页面，所以可能会把你不希望的页面给用户展现出来。或者在同一个关键字下，你自己的网站的不同页面竞争排名。
用户看到搜索结果的时候会看到省略重复内容的提示，影响网站的形象。
搜索引擎对权威页面判断的准确性并不高，很有可能以为两个重复的页面是不重复的，甚至因为你的重复页面问题过于严重，反而把没有重复的页面判定为重复。

最好的解决办法就是规范地生成地址。如果CMS很难修改，或者确实有必要给同样的内容不同的地址的时候，那么最好是用Http持久301转向把不权威的地址转到权威的地址。

但是如果你的虚拟主机功能有限，或者你在你的服务器上权限有限，你很可能无法使用Http持久301转向功能。所以现在Google，Yahoo，微软三家联合推出来了权威链接属性Canonical，你只需要在页面加一个link标记，然后设定它的Canonical属性，上面三家搜索引擎就会知道你所指定的权威页面是什么。

Matt Cutts，Google的著名Blogger，为了Canonical属性，做了一个演示文稿，我翻译了送给大家，如下：

据说有些人的Google reader在看这篇Blog的时候会自动跳转，所以我取消了直接嵌入的演示文稿，要看请点击下面的链接：
http://docs.google.com/Presentation?id=afdfdfhqkrd8_108hp3vctf8

Google大牛Jeff Dean在WSDM（ACM的Web搜索和数据挖掘研讨会）2009上面的演讲

2009-02-19T11:18:00.020+08:00

重要更新：Jeff Dean的Keynote文件和视频已经发布，请移步查看

昨天看到好像是大辉共享的， Geeking with Greg写的Jeff Dean keynote at WSDM 2009。现在Jeff Dean的Keynote文件和视频貌似都还没公开放出来，所以我把Geeking with Greg的文章翻译如下，方便有兴趣的同学了解一下。Jeff Dean是何许人也呢？呵呵，他就是Google Mapreduce架构的发明者，那篇尽人皆知论文的第一作者。WSDM又是何物呢？WSDM是美国计算机协会ACM组织的Web搜索和数据挖掘研讨会。Jeff Dean在WSDM2009上面演讲的题目是Challenges in Building Large-Scale Information Retrieval Systems（构建大规模信息检索系统中的挑战），演讲介绍了Google从1999年到2009年，数据量，用户查询次数，以及相应架构的变化。

下面是简要译文：

Google Fellow Jeff Dean在最近的WEDM 2009会议上做了一个非常精彩的演讲，包含了一些我从来没有听说过的关于Google的轶闻。给我最深印象的是，这十年间Google对性能细节的关注，以及他们敏捷的开发模式。

Jeff给出了从1999年到2009年Google如何成长的几个例子。他们现在拥有1千倍的查询次数。他们现在拥有1千倍的处理能力（机器数量乘以他们的速度）。而且他们把更新的延迟降低了1万倍，送过去需要数月才能监测到一个Web页面的变化，到现在几分钟即可更新页面的搜索结果。

最后这一点非常令人印象深刻。Google现在可以非常迅速地监测到很多Web页面的变化，计算这个页面的近似静态排名，并把索引的更新发布出去。对许多页面来说，搜索结果可以在页面变化数分钟后更新。要做到这点需要解决几个困难的问题--重复抓取的频率和重要度，PageRank的快速近似计算，一个允许快速更新索引的架构--看来这些问题他们都解决了。

他们的性能改进也令人惊讶，现在显示每个页面的时间是200ms以下。Jeff提到从几年前起，现在绝大多数的索引是完全保存在内存中的。也就是说现在每个查询不是由几十个机器，而是由上千个机器处理的，Jeff说这是值得的，这令每个搜索者可以立即就看到搜索结果。

Google对细节的注意是可圈可点的。Jeff描述了他们这些年创造和使用过的几种索引压缩技术。他讲到他们如何最后决定了一种格式，4×3的位置信息有序地组合在一起（By Tiny:原文是a format that grouped four delta of positions together in order，这句我不确定翻译的准确性，因为我没有看明白），这样就可以把压缩过程中需要的移位操作次数降到最低。Jeff说道，他们总是很注意他们的数据在磁盘上的组织方式，把他们需要快速流读取的数据总是放置在硬盘的外圈，而冷门数据，或者短读取的数据放在磁盘的内圈。他们为没有校验的内存写自己的错误恢复软件。他们写了自己的硬盘规划器。他们不断地修改Linux内核去满足他们的需求。我们先是设计自己的没有外壳的服务器，然后切换到现成的标准的服务器，现在他们又转向设计自己的没有外壳的定制服务器了。

Google的敏捷同样令人难忘。Jeff说10年间，他们已经进行过7次主要的架构升级。这些变化通常牵扯到完全不同的索引格式，或者全新的存储系统例如GFS和BigTable。在一些切换中，他们甚至做到了，在新的数据中心运行着新的代码，旧的数据中心运行这旧的代码，并在这些数据中心间切换用户的访问。每天，搜索用户持续地接受用户体现方面细微的变化，测试新的代码。Google的切换安静而快速，用户不会注意到任何变化。

原始的计算能力的地位已经摇摇欲坠了--现在可以用数千个机器为一个请求服务--虽然这一切看起来那么不可思议。Jeff说，Google机器翻译模型翻译一个句子的时候，会对一个数T的模型进行上百万词的查找。他接着说，Google的目标是不管你使用什么语言，让你可以读懂任何语言描述的任何信息。这需要的运算量难以计算，看起来这么巨大的运算量可能令所有其他人都只能战战兢兢的呼喊Google（Tiny:原文The amount of processing required is difficult to fathom, yet it seems the kind of computational mountain that might cause others to falter calls out to Googlers.，说不好这句）。

------云时代的分割线------

Geeking with Greg还提到了，Michael Bendersky听该演讲的笔记，下面也大略翻译如下：

1999年到 - 2009年规模的变化

100倍文档数
10000倍查询数（这里Geeking with Greg和Michael Bendersky的数据有出入）
更新速度快了1万倍
查询延迟从小于1秒到大于0.2秒，快了5倍

10倍增长的时候设计的搜索引擎，100倍增长时重新了系统。然后，他粗略描述了从90年代后期开始抓取和索引发生的变化。下面是一些要点。

90年代后期

批量抓取系统，抓到“足够”的页面后停止。
批量索引和Unix工具协同工作。减少了机器失效和数据不一致性。
原始的97索引格式就是简单的字节对齐的系统，包含编码的字段和词频信息。这需要大量的磁盘访问。

之后不久

迁移到新的基于块的变长索引格式，附带高频词跳表。这令索引尺寸小了30%，而且解码更快。
加入结果和文档摘要的缓存服务器。
2001年前期，他们迁移到一个内存索引架构，索引服务器（）可以直接和前端服务器沟通。
索引按文档分割而不是按词分割。

{资料} 顶级期刊《Machine Learning》 1986-2007 全部论文的合集

2008-12-29T20:50:00.003+08:00

今天，pongba发现了这个非常好的资料，并在他的论坛共享出来。
地址是：
http://gigapedia.org/items/62699/machine-learning--1986---2007--collection-of-journals--springer-

不过这个下载地址有点麻烦，需要你注册gigapedia.org才能看到下载链接，然后还要去ifile-it网站才能开始真正的下载。所以，我下载了一份，在电驴共享出来，欢迎大家使用电驴来下载。

地址是：
ed2k://|file|ml.zip|512062790|3E9F4EEF83BD6996FA2CE1A9BC026B2B|/

欢迎下载也欢迎一起做源，现在下载速度很一般，不过只要做源的人多很快就会快起来的。

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

2008-04-26T02:16:00.005+08:00

刚才要下载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, 好耶, 微软

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

2008-03-15T21:11:00.005+08:00

之前有不少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

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

2007-12-28T01:40:00.001+08:00

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

最近，有两位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, 调试, 重构

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

2007-12-22T18:30:00.001+08:00

测试数据是结构很简单的一个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

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

2007-11-12T03:50:00.001+08:00

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

最近更新的文章有：

翻译的文章有：

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

technorati tags: google maps api

10月27日Google Maps API讲座PPT下载

2007-11-02T10:14:00.001+08:00

上周六，也就是10月27日，应CSDN之邀做了一个Google Maps API的简单讲座。讲得很粗，一方面是我的准备有点仓促（最近对Hadoop/Mapreduce太着迷，一天到晚的在研究），一方面是我对下面听众的JavaScript应用水平不甚了解，再有一方面，我觉得Google Maps API实际上太简单，而且概念少，代码多，讲座的形式不太好交流（下面的听众都说看不请投影的代码，这我可怎么办）。

但是还是承蒙很多听众的厚爱，写信跟我索要讲座的ppt，我本无藏私之念，只是总是觉得自己的东西写得太粗陋进不得高人的法眼，所以没有把ZMap开源。这次讲座，我把ZMap的核心代码全盘拖出，心中释然，丑已经丢了，就不畏惧开源了，这个事情总算可以放到议事日程里了。但是，诚心请求直接扒ZMap的JavaScript代码的朋友们，注意把我的Google统计代码去掉，这多让人啼笑皆非啊。

ppt的下载地址为：http://www.zmap.org/temp/ppt.zip

technorati tags: csdn, google maps api, ppt, zmap

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

2007-10-07T05:19:00.001+08:00

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

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

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

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

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

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

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

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

technorati tags: 极限, 目标

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

2007-08-16T02:13:00.001+08:00

最近一个处理非常大的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

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

2007-07-27T02:23:00.001+08:00

今天，把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

正式发布Google混搭编辑器(Google Mashup Editor)中文文档

2007-07-23T11:28:00.001+08:00

查看地址： Google混搭编辑器(Google Mashup Editor)中文文档

Google混搭编辑器(Google Mashup Editor)是一套用来开发混搭应用的Web开发工具，它是一套函数库，也是一个IDE。不管你的应用本身多复杂，用了多高深的技术，值得庆幸的的是我们有Rss/ATOM，利用他们我们可以举重若轻的把不同公司，不同利益集团的产品粘合在一起，创造新的视角，新的应用模式。这就是Google混搭编辑器(Google Mashup Editor)的意义。

为了便于国内的开发者使用Google混搭编辑器(Google Mashup Editor)，我在学习过程中制作了这个中文文档，完全翻译了产品概述和入门指南两个部分，因为这两个部分可以让你充分了解Google混搭编辑器(Google Mashup Editor)的思想和用法。标签参考文档、操作数据、过滤数据、事件处理以及JavaScript API，留待日后慢慢翻译完善。

之前，我还翻译了Google Maps API的文档，地址在Google Maps API中文同步文档。欢迎有兴趣的朋友查看。

今后的翻译计划是 Google AJAX Search API文档和 Google AJAX Feed API。

technorati tags: ajax, document, feed, maps, Mashup, search

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

2007-07-15T18:34:00.001+08:00

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

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, 搜索引擎优化, 搜索引擎友好

在CSDN与David Intersimone同志的合影

2007-06-17T21:18:00.001+08:00

technorati tags: borland, codegear, csdn, David, Intersimone, tinyfool

CSDN上我的专访

2007-06-15T09:31:00.001+08:00

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

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

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

CSDN举行的David I见面会(borland->code gear)

2007-06-01T15:20:00.001+08:00

我提的问题是：
1、在我看来Borland曾经的危机，主要来自于产品过渡绑定于Windows平台，而这个平台的控制者也在做开发工具生意。请问Code Gear认同这个观点么？
2、基于前面的看法，我认为Code Gear想要发展壮大，应该努力让自己的产品不在依赖于单一平台。而且刚才David I谈到了两点，Code Gear百分之百关注开发者，以及Code Gear开始关注web开发者。基于这个观点，我认为Code Gear更需要努力扩展到更多的平台。因为Php的开发者/Ruby on rails开发者中非Windows平台的开发者比例都是比较高的。我个人就是一个例子，自从把个人主要技术方向转移到Web方向后，立刻就买了一个MacBook。请问David I怎么看这点？

他的回答太长了，我记不住，所以等到Csdn出了新闻稿，我再贴出来。
大意是：
1、他不认为Borland曾经有了一场危机，只是Borland准备更加关注企业级应用，项目生命周期管理，而成立Code Gear是为了关注于开发者的需求。
2、太长了，实在记不住。

technorati tags: borland, code gear, csdn, David

4月24日优酷星期二活动主题：虚拟现实技术在web 3D上的应用

2007-04-24T00:51:00.000+08:00

貌似比较有意思，有兴趣的朋友可以考虑参加，地点和联系方式如下：

shell脚本批量更改文件扩展名(unix/linux/bsd)

2007-04-13T05:15:00.001+08:00

此例为把.htm改为.html(红色部分为原扩展名和现扩展名)

for i in *.htm; do mv $i ${i%%\.*}.html; done

#todo 先记录于此，有时间的时候再具体解释是怎么写出来的。

technorati tags: bsd, linux, shell, unix