一篇文章存成一个巨大的文件,总共大约有一亿个单词,要找出里面重复次数最多的。怎么做?
Hadoop 是一把威力巨大的榔头,在使用过 Hadoop 之后,看着任何东西都想把它给 map reduce 了。有一个关于 Jeff Dean 的小笑话,说在睡不着觉的时候,一般人是数羊,Jeff Dean 是 map reduce 他的羊群。所以,我的办法是,把这个文件拆分成若干个小文件,在 map 过程用 hash 算法保证相同的单词落入一个文件(这点很重要),计算单词出现次数,在 reduce 过程取得重复次数最多的单词来。
但是,真有必要这样啰嗦吗?
只有一亿个单词,简单估算一下,一个字母占据两个字节,假设单词平均长度 5,即便
[……]阅读全文





最近在看一本书,叫做 
今天是来武汉的第四天。有机会来华科招聘毕业生,是一件很有趣也很有价值的事情。有一些是很有意思的见闻,更多的是锻炼以及收获。大学里面有很多优秀的人才,有一些人的错过则颇为可惜。请那些勤奋、有天赋而且有抱负的学生保持热情,至少我可以明确地感受到,人才的价值。互联网公司为了招聘到优秀的人才,倾注了非常多的精力。以我们为例,这一次来华科的招聘团队 7、8 个人里面,大部分都折腾得非常疲惫,每天也没什么时间吃午饭,晚上还要讨论结果、审阅简历,回酒店倒头就睡。但是很多非常有潜质的工程师,往往还持有其他互联网企业的 offer,这其中对人才的竞争是非常激烈的。
在系统设计阶段考虑全面很难,有许多人倾向于把整个设计分成若干阶段,在迭代中完成整个设计,这本身是非常好的,但是,就如同 “先做出来,以后再优化” 这样的经典谎言一样,本身并无错,只是许多程序员都不习惯于真正的迭代设计和迭代优化。举例来说,有一个日益复杂的类,每个人都修改一点点,一直到最后都没有人愿意去做重构,大家的心态都是一样的:“我只修改了一点点,为什么要我去动那么大的刀,于我没有任何好处”。我不在这里谈论这一问题的解决办法,我倒是想说,在开始阶段考虑清楚问题在多数情况下还是很有好处的,设计考虑得越是清楚,在后续阶段代码可以承受越多的变更而不腐朽。
很多非计算机相关专业的学生想投身软件行业,甚至相当程序员。不少学生在担心自己专业不对
首先,Jeff Dean 是谁?
最初我是在公司内部的 broadcast 上面听到有 principal 介绍到它的,和 AspectJ 归在一起。看了几个例子之后觉得有点意思,就去
我忽然很好奇,想知道其他软件工程师的生活是什么样的?人永远都没有活在别人心中的形象那么绚烂,生活中总有无数烂事烦事需要处理,但是每个人都有自己享受生活的方式。逛了逛了各式技术博客和论坛,我发现大家似乎都太严肃了,太谦逊了,太学术了。做软件本来是一件很有意思的事情,但是这些帖子和文章无非就包括这么几种:
项目中有一个对实时响应性比较高的服务,引入了 Memcached 以减少延迟和减少数据库压力。但是期间遇到了一些问题,这里记录一些调优细节。 
这篇文章,算是理清和记录了一些我一直以来想说的话。在昨天的课程上,我们谈论目标、生活方式和工作,特别地,有一个具体问题——“ 五年后的你会是怎样的?” 其实我很好奇其他人的想法都是如何的,起码于我来说,这是一个很有趣的问题。