Tinyfool的开发日记(blog)

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

这期活动搞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开发专区。

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

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

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

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

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

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

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

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

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

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

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

这里说的重复内容问题不是指的由非法转帖造成的重复内容，而是由于很多CMS设计不好，或者有些网站利用链接参数跟踪用户行为（我们的一个咨询客户这方面就很严重，造成的结果是收录率极低，搜索量自然也极低），造成的在同一个网站同一个内容有多个链接的问题。
据说有些人的Google reader在看这篇Blog的时候会自动跳转，所以我取消了直接嵌入的演示文稿，要看请点击下面的链接：
http://docs.google.com/Presentation?id=afdfdfhqkrd8_108hp3vctf8

重要更新：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年前期，他们迁移到一个内存索引架构，索引服务器（）可以直接和前端服务器沟通。
  
• 索引按文档分割而不是按词分割。

最近和当前

• 从头开始内部设计：机架设计，Pc级主板，Linux，内部软件（GFS，BigTable，等等）
• 用MapReduce架构来构建索引
  
• 2004年他们迁移到一个层级系统来处理索引，这个系统构建在基于GFS的索引之上（现在只有“根级服务器”处理来自Web服务器的请求）
  
• 快速索引更新
• 2007年他们加入超级根服务器，跟所有的垂直信息索引服务器通讯，构建全能搜索（Universal Search）服务。

Google如何实验排序的改变
目标: 要易于通过实验验证。

1. 从一个新的排名思想开始
   
2. 用MapReduce，BigTable等快速生成实验所需数据
   
3. 离线运行，并在（1）人工指定的不同类型的查询 （2） 在随机的查询，上看与现有排名算法的差异（不考虑延迟）
   
4. 重复…
   
5. 在一个小的随机的访问样本中实验（要考虑延迟！）
   
6. 重新实现/调节实现，重新计算数据，要令计算全部数据的时间可行，并把所有需要的其他的数据加入到索引
   

未来的挑战

• 跨语言检索 - 质量和架构可伸缩性
• 检索隐私的，半公开的，共享的以及完全公开的文档
  
• 自动构建高效的满足不同需求的信息检索系统
  

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

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

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

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

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

之前有不少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 Maps API的初学者向我请教他们按照最简单例子写的程序为什么不能正常的运行。

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

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

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

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

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

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

遇到问题的时候：

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

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

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

technorati tags: log, 调试, 重构

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



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

technorati tags: dom, sax, xml

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

最近更新的文章有：

• 如何在Google Maps API中使用谷歌地图的数据
• 地图盈利之道──Google Maps API中的Adsense

翻译的文章有：

• [翻译]对GoogleBar的介绍
• [翻译]呼叫所有的PHP/MySQL开发者：这里有给你们的例子代码

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

technorati tags: google maps api

上周六，也就是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