leadscloud

谢邀。

看了一下几个高票答案，讲的都是故事，都很感人，我就不催泪了，不过我需要对这些故事做一个理论补充——男人的温柔是不可能独立存在的。

So easy，如果一个男人拥有的只是温柔，体贴和任劳任怨，就像是你备胎中最听话的那一位一样。他会因为你的QQ签名改成了“下雨了，心情不好”而打20个电话给你只为给你讲个笑话；他会在你生理期的时候每天给你发短信叫你别着凉and多喝水；他会在你忙到不得不挂掉他电话之首写一封亲笔信来表达他对你的思念。

如果他只会这些，他不上进，也没有野心，更没有钱，也不会去思考如何赚钱，他有大把的时间，但是他却选择了花在游戏和牵挂你身上。作为女人，你还会喜欢他么？我相信大部分人的答案都是否定的。如果有人就是喜欢这一类男人，那我想说大学里面有很多，很多。

只有当男人有了足够的能力，社会地位或是财富之后，他的温柔具备杀伤力，我是男人，也是过来人，我知道一点：学习温柔是不需要成本的。换句话说，这玩意基本上不用学都会。一个大老粗也懂得应该对心爱的女人好一点，迁就一点，忍让一点。这在我们童年时期就已经被长辈教育过无数次了。他们总是告诉我们，男孩子要让着女孩子。

所以男人的温柔并不值钱。只有当这个男人足够强大之后，他的温柔才值钱。因为当一个男人飞黄腾达之后，他的心态会随之膨胀，他会目中无人，他会觉得他有钱有地位所以身边的人都应该围绕着他转。

很早之前的某一天，本来是要去外地看女朋友，但我犯懒了，那一刻我突然觉得我这么累的在工作，你作为我的女人怎么就不能多为我考虑一下，怎么就不能主动来看我？于是我找了一个理由说临时有工作上的事情去不了了，如果可以的话，不如你过来看我。结果她说，那下个月吧，你有工作就去。听到这句话的时候我生气了，狠狠的生气了。我觉得这女人真的太二，太不懂我。和她分手很久之后，我突然想明白了，二的是我，我已经被越来越高的社会地位冲昏了头脑，我没有做到一个男朋友的分内之事。更别提什么温柔了。我膨胀的太厉害，我失去了为他人思考的能力。我觉得这样下去要完蛋。也就是那时候我突然明白了清华的校训——厚德载物。

人都是这样，越强大越自傲。这是非常恐怖的，所以傲慢被定为七宗罪之首。同样的例子时时刻刻都在发生，就像是昨天在盐Club的前排会场里，我看到某个大V毫不留情的拒绝了一个粉丝的合影要求，甚至没有一句解释。甚是心寒。

相反的我看到有很多很强大也很温柔的男人例如马英九，李嘉诚，和《这个杀手不太冷》中的leon。无一不是拥有了强大的能力之后还能够保持一颗善良而谦和内心。我觉得这就是一个男人的温柔。

当然还有那些网络小说，女人的A片，有哪一个男主角不是家财万贯，武功高强，有勇有谋，帅的一逼？按照他们的人物设定基本可以坐拥天下，傲视众生甚至是扭曲时空。但无独有偶的他们哪一个在女主角面前不是谦谦君子，温润如玉的呢。如果这些男主角身上少了强大或是温柔中的任何一项，女人拿什么来高潮？

——————————

我不希望有些朋友带着偏见来看待这个问题，或是拿出现在的男朋友做比较。请不要说类似“不会呀，你看我现在的男朋友虽然没钱，但是他对我好呀”这样的话。那是因为你们在机缘巧合下走到了一起，你开始在这段感情和这个男人身上投资，无论是时间精力还是金钱，时间越长，你投资的就越多，也就越难以抽身。这就像是人们总是会试图维护自己的立场和想法一样，即使你知道那是不对的。

我更加不希望一些男性同胞误解我在嘲讽，也请不要自我矮化。那不是我的本意。我只是想说出事实，然后我们一起加油。

知乎原文：http://www.zhihu.com/question/23853217

初出茅庐的你带着仍残留墨香的毕业证书踏上工作岗位，马上就被书上没写的规则和各种繁杂的日常事务来了个下马威。这样的故事实在是司空见惯，编程工作也不例外。

没有几个学生能 100% 为自己的第一份真正的工作做好准备。如果你不想成为其中之一，请学学以下这 10 项无需手把手指导就能学会的基本技能：

1、版本控制系统（VCS）

VCS 也许是计算机课程最大的疏漏。这些课程光记得教如何写代码，但却往往忘记教学生如何去管理代码。每一个程序员都应该懂得利用 Git 或 Subversion 有效地创建 repository（仓库），编辑与提交代码，进行分支与合并，了解项目工作流。

2、学会写作

身为程序员要写的不只有代码。你还要写项目的发布说明，给版本控制写提交消息，在系统里面写漏洞报告。这些和许多地方都需要清晰有效的文字交流—但这个技能计算机科学却很少强调。

3、正则表达式

正则表达式本身就是一门语言，每一个现代程序员都要擅长。每一门现代语言都支持正则表达式或者有相关标准库。如果代码需要校验某字符串是否含有 5 个字符、1 个破折号和 1 个数字，你应该马上就能写出 /^[A-Z]{5}-\d$/。

4、库的使用

现在已经是 2014 年，所以没人需要用正则表达式从 URL 析取主机名了。因为每一门现代编程语言都有执行常用功能的标准库。

程序员需要明白，那些经过开发、测试和调试的代码通常要比自己重新写的代码更好。更重要的是，无需编写的代码实现起来要快得多。

5、SQL

很多人的 SQL 都是在工作中学会的。数据库怎么会是选修课呢？有不用数据库的吗？

把数据存进平面文件的时代已经结束了。一切东西都要进出数据库，而 SQL 则是存取数据的语言。这是一门说明性语言，不是程序语言，所以用它来解决问题时需要新的思考方式。每一个程序员都应该了解数据库标准化基础，能够执行 SELECT（及 INNER、OUTER JOIN）、INSERT、UPDATE 和 DELETE。

6、会用IDE、编辑器及CLI工具

只懂用锯子的木匠永远也无法出师，所以计算机专业毕业的人只懂 Notepad 或 pico 令人惊诧。编程工具帮助操纵代码及其他数据，令程序员生活变得容易。所以每一个程序员都应该知道命令行、shell 脚本、find、grep 及 sed 的使用。

7、调试

每一个程序员都应该知道利用交互式调试器或在代码中点缀一些输出语句来调试程序。通过逐步求精来跟踪问题的能力实在是太重要了。

8、防错性编程

错误总是难免的，哪怕是明星程序员也不例外。失控是世界的常态，出错毫不奇怪。防错性编程正是理解了这个事实。如果东西不会不出错，我们就不会检查文件打开成功与否，不会检查客户 ID 是否合法数字，不用测试代码是否允许正确。

程序员需要知道，编译器告警是有用的工具，可让我们生活得更舒适，而不是要避而远之的麻烦事。每一个程序员都应该知道为什么每一个 PHP 程序都要这样开头：

set_error_reporting(E_ALL)

每一个 Perl 程序都要写上这些语句：

use strict; use warnings;

9、团队协作

很少编程工作会让你自己一个人完成，如果你经常这么做，智力会受损，表现会变弱。你的代码必须与别人的交互或者混合。再有才的程序员，如果无法与别人协作，都会给项目造成负面影响，并迅速成为组织的负担。

10、利用现有代码

在学校的时候，每一次作业都是一个新项目。但现实世界不是这样的。对于刚工作的人来说，所接到的第一项任务往往是修改代码漏洞。然后，再在现有代码库的基础上为现有系统增加一个小功能。设计新代码那是几个月后的事情，如果幸运的话。

[本文编译自：blog.newrelic.com]

原文： http://www.36kr.com/p/212678.html?ref=related

mysql 的一般登陆方式是这样的

1

mysql -u $MYSQL_ROOT -p $MYSQL_PASS -h 192.168.10.1

但是，你有两个方式可以使用无密码提示的登陆，一个是修改/etc/my.cnf文件，一个是修改~/.my.conf 文件。

1

$ vi ~/.my.cnf

1
2
3
4

[client]
user=alice
password=alice_passwd
host=192.168.10.1

如果是修改my.cnf文件，把它加到文件末尾就行了。你可以直接使用

1

mysql -u root

登陆，不会再提示密码错误。但如果你仍然使用

1

mysql -u root -p

的方式，它还是会提示你输入密码的。

确保文件是只读的

1

$ chmod 0600 ~/.my.cnf

这样设置以后，你每次使用命令mysql就可以不要密码了，自动进入mysql中。

一些刚刚走出校门的大学毕业生很难找到工作。其他人则接受了他们觉得大材小用的工作。与此同时，学生债务已经突破1万亿美元大关。

这足以引发一波关于大学教育是否仍然值得的问题。

一组新的收入统计数据非常清楚地回答了这些问题：是的，大学值得上，而且差别还不是一丁点。尽管许多年轻的大学毕业生面临种种困境，但一个四年制学位或许从来没有比现在更有价值。

华盛顿经济政策研究所(Economic Policy Institute)根据劳工部统计数据所做的最新分析显示，大学毕业生和其他人的薪酬差距在去年达到历史最高。2013年，有四年制大学学位的美国人的平均时薪比没有学位的美国人足足高了98%。五年前、10年前和上世纪80年代初的薪酬差距分别是89%、85%和64%。

这种趋势并没有任何必然性。如果大学毕业生的人数超过经济需要，薪酬差距就会缩小。这种差距的最近一次增长尤为显著，因为它是在大学毕业生数量增长（其部分原因是，许多人在“大衰退”期间重返学校深造）之后出现的。薪酬差距仍然继续增长这一事实意味着，美国培养的大学生依然不够用。

“目前的大学毕业生太少了，”麻省理工学院(MIT)经济学家大卫·奥特尔(David Autor)说。“准备上大学的人也太少了。”奥特尔并未参与经济政策研究所的分析。

强调这些不足是非常重要的，因为如今的公开讨论（新闻媒体对此担有一定责任）通常聚焦于一个无可否认的事实：一个学士学位并不能确保成功。当然不能。没有什么东西能确保成功，特别是经过15年令人失望的经济增长和日益严重的不平等之后。

几乎可以肯定是，当专家和记者花费这么多时间谈论教育的局限性时，他们其实是在劝阻一些青少年不要上大学，成年人不要重返学校攻读学位。（与此同时，这些专家和记者正在送自己的子女上大学，而且经常为应该上哪所大学而困扰。）由于担心不划算而决定不上大学，是一个人在2014年有可能做出的最缺乏经济理性的决策之一。

受到热烈讨论的上大学成本也无法改变这个事实。根据奥特尔上周四发表于《科学》杂志(Science)的一篇论文，大学学位的真实成本大约是负50万美元。这是正确的：从长远来看，大学教育比免费还便宜。不上大学将使你损失大约50万美元。

奥特尔这篇论文以经济学家克里斯托弗·艾利(Christopher Avery)和莎拉·特纳(Sarah Turner)的研究成果为基础。它首先通过计算大学学杂费的真实成本得出一个数字，随后用大学毕业生和高中毕业生的终生收入差距减去这个金额。剔除通货膨胀和货币时间价值因素后，上大学的净成本为负50万美元，几乎是30年前的两倍。

这样计算肯定是不太精确的，因为它没有控制大学毕业生和非大学毕业生预先存在的差异，即无论上不上大学都会存在的差异。然而，还有一些研究在比较了其他方面类似的大学毕业生和非大学毕业生之后，也发现大学教育能够带来丰厚回报。

与此类似，经济政策研究所的新数据还显示，上大学的好处不仅仅属于通常会继续攻读研究生学位的名牌大学毕业生。只拥有学士学位的人和无学位人群的工资差距也在不断上升。

但引人注目的是，上过大学但未获得学士学位的人（这一群体还包括社区大学毕业生）的工资溢价并没有上涨。高经济回报属于那些有四年制大学学位的人。这些回报突显了减少大学辍学率的重要性——在《纽约时报杂志》(Times Magazine)最近一篇文章中，保罗·塔夫(Paul Tough)描述了得克萨斯大学(University of Texas)为减少辍学率所做的努力。

但你肯定听说有不少大学生负债累累，而且还找不到工作，这些令人震惊的故事又该如何解释呢？

这些轶事可能是真的，但传统思维往往夸大了这个问题。办理贷款的四年制大学毕业生人均负债约2.5万美元，与上大学的经济收益相比，这笔钱显得微乎其微。（扣除通胀因素后，我自己的学生债务几乎等同于这个数字。）拥有学士学位的25至34岁年轻人在4月份的失业率仅仅3%而已。

我发现经济政策研究所的数据特别耐人寻味。原因是，这家左翼研究机构特意强调，教育并非所有经济问题的解决方案。这也是很重要的。如同几乎所有其他人一样，大学毕业生也正在遭受经济增长乏力，增长收益不成比例地流向最富裕家庭等现象的负面影响。

过去10年，大学毕业生的平均时薪仅上涨了1%，到大约32.60美元。薪酬差距增大的主要原因是，其他人的平均工资下降了——下降5%，降至大约16.50美元。“在我看来，整体现状是，几乎所有人的工资都没有增长，无论他或她从事何种工作，”该研究所所长劳伦斯·米舍尔(Lawrence Mishel)对我说。“工资的增长趋势在2002年就基本停止了。”

从整个国家的角度来看，教育只能解决美国经济的部分问题。我们还需要找到其他方式来提升生活水平——更不用说我们需要设法为没有大学学位的人提供好工作。

但从几乎任何个体的角度来看，上大学是一个无需动脑就可以做出的决定。这是迈入中产阶级乃至更富裕阶层的最可靠的入场券。质疑大学教育价值的人往往是那些明知道自己的孩子将来会上大学的人。

就在几十年前，高中还被视为教育的前沿。有些人甚至认为，鼓励出身卑微的美国人花费四年光阴上高中是一种浪费。到了今天，每个人都应该接受13年学校教育这种观点显然是不容置疑的。

但大约13年的教育没有什么神奇之处。随着经济在技术层面变得更加复杂，人们需要接受教育的时间将会上升。在某个时点，15年或17年教育将成为一个更有意义的普遍目标。

这个时点，其实已经到来。

在本地开发的插件如果没有上传到firefox的在线扩展里面，你需要设置一个自动更新，如果有更新，安装你插件的用户便可以自动更新。
http://www.borngeek.com/firefox/automatic-firefox-extension-updates/ 这篇文章，详细介绍了如何设置自动更新。

关于调试：

在about:config里，将extensions.logging值设为true，并关闭firefox
在命令行下运行firefox -console，这样启动时，控制台会有extension的log输出。
从命令行界面可以看到一些提示信息，根据这些信息，你可以更好的知道自己的插件为什么不能更新。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

function getHostname(url){
	var a = document.createElement('a');
	a.href = url;
	return a.hostname;
}

function GetTopDomain(host){
  if(host.indexOf("http") > -1)
  	host = getHostname(host);
  var index = host.lastIndexOf('.'), last = 4;
  while (index > 0 && index >= last - 4){
    last = index;
    index = host.lastIndexOf('.', last - 1);
  }
  var domain = host.substring(index + 1);    
  return domain.length > 6 ? domain : host;
}

引方法只能针对部分域名，对于 xxxx.com.cn xxxx.co.in xxxxx.com xxx.in 都是可以识别的，但如果域名长度小于tld， 比如 xxx.com.cn 这样的就无法判断出来。

原文：http://www.ruanyifeng.com/blog/2006/11/the_logic_of_collective_action_public_goods_and_the_theory_of_groups.html

这几天，我就在看这本书。它是制度经济学领域的名著，出版于1965年，作者奥尔森（Mancur Olson，1932－1998）是马里兰大学的教授，已经去世了。

它问了一个很简单的问题：人们什么会组成集团？

传统的看法是，因为人们有共同利益，所以组成集团后，便于采取行动维护共同利益。

但是奥尔森回答说，不是这样。

人们之所以会加入集团，是因为集团本质上提供了一种集体性的公共商品（public good），也就是说，如果不加入，就享受不到特殊利益。比如，在西方某些企业只雇佣工会成员，所以只有加入工会，才能到该企业就业。再比如，只有加入美国医疗协会，才能在美国行医。

因此，奥尔森说，本质上集团的存在是一种”搭便车”行为（free ride）。只有当一个集团能够提供排他性的个人收益时，这个集团才能存在下去。

从这一点出发，可以得到两点推论。

（1）如果当一个集团为其成员提供的收益在下降，那么这个集团很可能就会走向衰弱。

（2）由于集团提供的是所有成员都可以享受的公共品，所以大集团的成员维护集团公共利益的动机会弱于小集团的成员，因为在大集团中，个人的贡献越大，他可以享受到的回报就越少。

[参考链接]

1. Wikpedia：Mancur Olson

2. Wikipedia：The Logic of Collective Action

（一）

上面这张图是统计学中很常见的一个图形，一般将它称为二八定律。它是１９世纪末２０世纪初意大利经济学家帕累托发现的，因为也被叫做”帕累托定律”。这个定律的内容是： >

在任何一组东西中，最重要的只占其中一小部分，约２０％，其余８０％尽管是多数，却是次要的。

在图形上看就是，20%的样本点占据了曲线下80%的面积，其余80%的样本点形成了一个只占20%面积的长尾巴。

这种现象在日常生活中非常常见，比如，20%的人占有的全社会80%的财富；商店80%的营业额是20%的商品产生的；你的英语单词量是10000个，但你经常使用的，不过只是其中的2000个单词。

（二）

2004年，_Wired_杂志的编辑Chris Anderson发表了一篇文章，在”二八定律”的基础上提出了”长尾理论”。

虽然都是基于同样的统计图形，但是”长尾理论”与”二八定律”的涵义截然相反。”长尾理论”提出： >

80%次要用户的那根”长尾巴”是很重要的。

“长尾理论”主要用来解释，像Amazon那样的网上书店为什么能够成功。这个理论提出，访问者能够在Amazon的网站上找到各种各样的书，因此这根长尾巴可以转变为销售量，而在实体书店中是没有办法找到这么多书的。所以，Amazon可以将潜在市场转变为销售量。

（三）

下面就是一个有趣的问题： >

作为一个个人，你是愿意处在那重要的20%的”少数”之中，还是愿意处在那根80%的”长尾巴”之中？

好消息是，根据”长尾理论”，在信息时代，个性化需求更容易得到满足，所以在”长尾巴”之中有更大的机会发展你的个性。

坏消息是，根据”二八定律”，”长尾”部分和”主干”部分的差异会非常明显，而且会越来越明显。

让我们来考虑搜索引擎的例子：市场上有许多搜索引擎，但是80%以上的市场份额是被两三家主导公司占领的，比如Google和Yahoo!，这是”二八定律”。那么其他众多小型搜索引擎应该怎么办？”长尾理论”的建议是，如果你没有办法做得比Google和Yahoo!更出色，那么就应该盯住那根”长尾巴”，注重满足用户的个性化需求。

同样道理，走好人生的道路，其实也只有两种方法：一是专业化，二是成为本领域中最优秀的。

（完）

[参考链接]

1. Wikipedia: The Long Tail

2. Wikipedia: Pareto principle

原文：http://www.ruanyifeng.com/blog/2006/10/pareto_principle_and_the_long_tail.html

昨天，我说我想推荐二部电影。

一部是故事片《Gran Torino》,另一部就是今天想说的纪录片《Religulous》，中文名为《宗教的荒谬》。

如果你去查词典，里面是没有Religulous这个词的。它是由主持人比尔·马赫(Bill Maher)创造出来的，意为religious(宗教)和ridiculous(荒谬)的合成。比尔·马赫就是想探讨下面这个问题： >

为什么有人相信那些荒诞的宗教传说？

据说，世界是由上帝创造出来的，圣母玛丽亚生下耶稣的时候还是处女，人死后灵魂会升入天堂……这些东西真的有人相信，而且是很多人相信。比尔·马赫走遍美国，采访不同的信徒，请他们解释为什么。这就是纪录片《Religulous》的主要内容。

它的可看性非常强，根据wikipedia的资料，该片是去年美国票房最高的纪录片(2008年10月上映)，在历史上所有纪录片中排名第7位。如果你想了解美国社会中的宗教状况，这部纪录片是必看的。

==========================

下面，我想谈谈我的感想。

我觉得，从思想层面看，这部作品的价值并不大。

因为，我认为比尔·马赫将宗教和宗教传说混为一谈了。宗教传说是荒唐的，但是宗教本身是有其合理性的。你不能因为”创世纪”的传说是荒唐的，就推定基督教也是荒唐的。宗教传说不等于宗教精神和宗教情怀。很多人相信宗教，不是因为相信上帝创造了一切，而是因为他们需要精神的安慰和寄托。

《圣经》是不是真的，与基督教应不应该存在，完全就是两回事。《Religulous》犯的错误就是，好像相信基督教就等于相信《圣经》中的每一句话。所以，我觉得这个片子不是很深刻，批判深度不够，最多只是社会风俗的记录而已。

========================

但是，比尔·马赫在片中说了一段很精彩的话，这才是我今天真正想说的东西： >

My big thing is I don’t know.

我的问题是我不相信。

That is What I preach. I preach the gospel of I don’t know!

这就是我要传播的东西。我所散布的福音，就是我不相信！

I mean that’s what I’m here promoting–doubt. That is my product. The other guys are selling certainty, not me.

我就是在推销怀疑！这就是我的产品。其他人出售的是让你相信，我出售的是让你怀疑。

我觉得这段话说得好极了！

怀疑是一切科学的起点。因为只有你怀疑了，你才不会盲从；只有你不盲从了，你才不会犯前人的错误；只有你不犯前人的错误，你才会做出新的东西；只有做出新的东西，你才能创造一个更美好的世界。

我的网志其实就是在做这件事：我在推销怀疑！

这个网志的一个目的，就是我想示范，独立思考是可以做到的，而且一点都不难。我不在乎别人认为我说的是对是错，我只希望你看了我的文章以后，自己也开始独立思考，开始用理性批判的精神进行怀疑。因为怀疑现行的秩序，这正是通往民主与科学的唯一道路。

我始终认为，中国人最落后的地方，就是思想太落后。大多数中国人的思想境界，还停留在封建时代。如果思想没有实现现代化，专制和愚昧就永远在这块土地上有市场。如果我们要建立一个民主和科学的新中国，那么第一步就是要改造人们的思想。而改造思想的第一步，就是传播怀疑。

如果大多数人不相信别人告诉他们的话，学会用自己的大脑，判断眼前发生的一切。凡事先想一想为什么，学会用不同来源的信息比对真伪，学会用逻辑的法则判断不同主张的合理性。那么，谎言就会无法生存，专制的基础就会动摇，中国发生变革的时刻，也就到来了。

[延伸阅读]

* 如何变得有思想？

（完）

原文： http://www.ruanyifeng.com/blog/2009/02/value_of_doubt.html

百度FEX上的一篇文章，感觉很不错。

引言

前阵子在w3ctech的走进名企 - 百度前端 FEX 专场上曾“夸下海口”说听完讲座后七天就可以打造自己的前端性能监控系统，既然说出去了也不能食言。从前一篇文章前端数据之美相信大家对前端数据有了一定的了解，下面就针对其中的性能数据及其监控进行详细阐述。

开始行动

本文中的性能主要指 web 页面加载性能，对性能还不了解？不用担心，接下来的“每一天”跟我一起进入前端性能的世界。

Day 1 为什么要监控性能？

“If you cannot measure it, you cannot improve it” ———— William Thomson

这是一个最基本的问题，为什么要关注和监控前端性能？对于公司来说，性能在一定程度上与利益直接相关。国外有很多这方面的调研数据：

数据来源：http://www.slideshare.net/bitcurrent/impact-of-web-latency-on-conversion-rates http://stevesouders.com/docs/jsdayit-20110511.pptx

为什么性能会影响公司的收益呢？根本原因还是在于性能影响了用户体验。加载的延迟、操作的卡顿等都会影响用户的使用体验。尤其是移动端，用户对页面响应延迟和连接中断的容忍度很低。想象一下你拿着手机打开一个网页想看到某个信息却加载半天的心情，你很可能选择直接离开换一个网页。谷歌也将页面加载速度作为 SEO 的一个权重，页面加载速度对用户体验和 SEO 的影响的调研有很多。

尽管性能很重要，开发迭代过程中难免会有所忽视，性能会伴随产品的迭代而有所衰减。特别在移动端，网络一直是一个很大的瓶颈，而页面却越来越大，功能越来越复杂。并没有简单的几条黄金规则就可以搞定性能优化工作，我们需要一套性能监控系统持续监控、评估、预警页面性能状况、发现瓶颈，指导优化工作的进行。

Day 2 有什么可用的工具？

工欲善其事必先利其器

页面性能的评估与监控有很多成熟优秀的工具，合理利用已有工具能达到事半功倍的效果。下面简单介绍几个常用的工具：

Page Speed

Page Speed 是谷歌开发的分析和优化网页的工具，可以作为浏览器插件使用。工具基于一系列优化规则对网站进行检测，对于未通过的规则会给出详细的建议。与此类似的工具还有 Yslow 等，推荐使用gtmetrix网站同时查看多个分析工具的结果，如下图所示：

WebPagetest

WebPageTest 是一款非常优秀的网页前端性能测试工具,已开源。可以使用在线版，也可以自己搭建。国内也有利用 WebPagetest 搭建的性能测试平台，推荐使用阿里测 (以下示例使用阿里测进行测试)。

使用 WebPagetest，你可以详细掌握网站加载过程中的瀑布流、性能得分、元素分布、视图分析等数据。其中比较直观的视图分析功能可以直接看到页面加载各个阶段的截屏:

注: 整个测试结果请点击此处

上图直观地展现了浏览类网站两个重要的时间点：白屏时间和首屏时间，即用户多久能在页面中看到内容，以及多久首屏渲染完成(包含图片等元素加载完成)。这两个时间点直接决定了用户需要等待多久才能看到自己想看到的信息。谷歌优化建议中也提到减少非首屏使用的 css 及 JS,尽快让首屏呈现。

PhantomJS

PhantomJS轻松地将监控带入了自动化的行列。Phantom JS 是一个服务器端的 JavaScript API 的 WebKit，基于它可以轻松实现 web 自动化测试。PhantomJS 需要一定编程工作，但也更灵活。官方文档中已经有一个完整的获取网页加载 har 文件的示例，具体说明可以查看此文档，国内也有不少关于此工具的介绍。另外新浪@貘吃馍香开发的类似工具berserkJS也挺不错，还贴心的提供了首屏统计的功能，具体文章可以查看此处。

Day 3 开始线上真实用户性能监控

取其所长，避其所短

到此肯定有同学问，既然有这么多优秀的工具，为什么要监控线上用户真实访问性能呢？

我们发现，工具模拟测试会在一定程度上与真实情况偏离，有时无法反映性能的波动情况。另外除了白屏首屏之类的基础指标，产品线同样关注产品相关的指标，例如广告可见、搜索可用、签到可用等，这些功能直接与页面 JS 加载相关,通过工具较难模拟。

为了持续监控不同网络环境下用户访问情况与页面各功能可用状况，我们选择在页面中植入 JS 来监控线上真实用户访问性能，同时利用已有的分析工具作为辅助，形成一套完整多元的数据监控体系，为产品线的评估与优化提供可靠的数据。

关于不同监控方式的简单对比可以查看下表：

Day 4 如何采集性能数据？

监控用户的痛点

线上监控哪些指标呢？如何更好地反映用户感知？

对于用户来说他感觉到的为什么页面打不开、为什么按钮点击不了、为什么图片显示这么慢。而对于工程师来说，可能关注的是 DNS 查询、TCP 连接、服务响应等浏览器加载过程指标。我们根据用户的痛点，将浏览器加载过程抽取出四个关键指标，即白屏时间、首屏时间、用户可操作、总下载时间(定义可见上篇文章)。这些指标是如何统计的呢？

确定统计起点

我们需要在用户输入 URL 或者点击链接的时候就开始统计，因为这样才能衡量用户的等待时间。如果你的用户高端浏览器占比很高，那么可以直接使用Navigation Timing接口来获取统计起点以及加载过程中的各个阶段耗时。另外也可以通过 cookie 记录时间戳的方式来统计，需要注意的是 Cookie 方式只能统计到站内跳转的数据。

统计白屏时间

白屏时间是用户首次看到内容的时间，也叫做首次渲染时间，chrome 高版本有 firstPaintTime 接口来获取这个耗时，但大部分浏览器并不支持，必须想其他办法来监测。仔细观察 WebPagetest 视图分析发现，白屏时间出现在头部外链资源加载完附近，因为浏览器只有加载并解析完头部资源才会真正渲染页面。基于此我们可以通过获取头部资源加载完的时刻来近似统计白屏时间。尽管并不精确，但却考虑了影响白屏的主要因素：首字节时间和头部资源加载时间。

如何统计头部资源加载呢？我们发现头部内嵌的 JS 通常需等待前面的 JS\CSS 加载完才会执行，是不是可以在浏览器 head 内底部加一句 JS 统计头部资源加载结束点呢？可以通过一个简单的示例进行测试：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<!DOCTYPE HTML>
<html>
    <head>
        <meta charset="UTF-8"/>
    <script>
      var start_time = +new Date; //测试时间起点，实际统计起点为 DNS 查询
    </script>
    <!-- 3s 后这个 js 才会返回 -->
    <script src="script.php"></script>  
    <script>
      var end_time = +new Date; //时间终点
      var headtime = end_time - start_time; //头部资源加载时间    
      console.log(headtime);
    </script>
    </head> 
    <body>     
    <p>在头部资源加载完之前页面将是白屏</p>
    <p>script.php 被模拟设置 3s 后返回，head 底部内嵌 JS 等待前面 js 返回后才执行</p>
    <p>script.php 替换成一个执行长时间循环的 js 效果也一样</p>  
    </body>
</html>

经测试发现，统计的头部加载时间正好跟头部资源下载时间相近，而且换成一个执行时间很长的 JS 也会等到 JS 执行完才统计。说明此方法是可行的(具体原因可查看浏览器渲染原理及 JS 单线程相关介绍)。

统计首屏时间

首屏时间的统计比较复杂，因为涉及图片等多种元素及异步渲染等方式。观察加载视图可发现，影响首屏的主要因素的图片的加载。通过统计首屏内图片的加载时间便可以获取首屏渲染完成的时间。统计流程如下：

首屏位置调用 API 开始统计 -> 绑定首屏内所有图片的 load 事件 -> 页面加载完后判断图片是否在首屏内，找出加载最慢的一张 -> 首屏时间

这是同步加载情况下的简单统计逻辑，另外需要注意的几点：

• 页面存在 iframe 的情况下也需要判断加载时间
• gif 图片在 IE 上可能重复触发 load 事件需排除
• 异步渲染的情况下应在异步获取数据插入之后再计算首屏
• css 重要背景图片可以通过 JS 请求图片 url 来统计(浏览器不会重复加载)
• 没有图片则以统计 JS 执行时间为首屏，即认为文字出现时间

统计用户可操作和总下载

用户可操作默认可以统计domready时间，因为通常会在这时候绑定事件操作。对于使用了模块化异步加载的 JS 可以在代码中去主动标记重要 JS 的加载时间，这也是产品指标的统计方式。

总下载时间默认可以统计onload时间，这样可以统计同步加载的资源全部加载完的耗时。如果页面中存在很多异步渲染，可以将异步渲染全部完成的时间作为总下载时间。

网络指标

网络类型判断

对于移动端来说，网络是页面加载速度最大的影响因素，需要根据不同的网络来采取相应的优化措施，例如对于 2G 用户采用简版等。但 web 上没有接口获取用户的网络类型。为了获取用户网络类型，可以通过测速的方式来判断不同 IP 段对应的网络。测速例如比较经典的有 facebook 的方案。经过测速后的分析，用户的加载速率有明显的分布区间，如下图所示：

各个分布区间正好对应不同的网络类型，经过与客户端的辅助测试，成功率可以在 95%以上。有了这个 IP 库对应的速率数据，就可以在分析用户数据时根据 IP 来判断用户网络类型。

网络耗时统计

网络耗时数据可以借助前面提到 Navigation Timing 接口获取，与之类似的还有Resource Timing,可以获取页面所有静态资源的加载耗时。通过此接口可以轻松获取 DNS、TCP、首字节、html 传输等耗时，Navigation Timing 的接口示意图如下所示：

以上重点介绍了数据采集部分，这也是系统中最关键的一部分，只有保证数据能真实反映用户感知，才能对症下药提升用户体验。数据采集完之后我们可以在页面加载完之后统一上报，如示例：

1

http://xxx.baidu.com/tj.gif?dns=100&ct=210&st=300&tt=703&c_dnslookup=0&c_connecting=0&c_waiting=296&c_receiving=403&c_fetch_dns=0&c_nav_dns=75&c_nav_fetch=75&drt=1423&drt_end=1436&lt=3410&c_nfpt=619&nav_type=0&redirect_count=0&_screen=1366*768|1366*728&product_id=10&page_id=200&_t=1399822334414

Day 5 如何分析性能数据？

让数据会说话

而数据分析过程，如前一篇文章所述，可以从多个维度去分析数据。大数据处理需要借助 hadoop、Hive 等方式，而对于普通站点则任意一种后端语言处理即可。

均值与分布

均值与分布是数据处理中最常见的两种方式。因为它能直观的表示指标的趋势与分布状况，方便进行评估、瓶颈发现与告警。处理过程中应去除异常值，例如明显超过阈值的脏数据等。

耗时的评估中，有很多这方面的研究数据。例如有人提出三个基本的时间范围：

• 0.1秒 : 0.1 秒是用户感知的最小粒度，在这个时间范围内完成的操作被认为是流畅没有延迟的
• 1.0秒 : 1.0 秒内完成的响应认为不会干扰用户的思维流。尽管用户能感觉到延迟，但 0.1 秒 -1.0 秒内完成的操作并不需要给出明显 loading 提示
• 10秒 : 达到 10 秒用户将无法保持注意力，很可能选择离开做其他事情

我们根据业界的一些调研，结合不同指标的特点，制定了指标的分布评估区间。如下图所示：

评估区间的制定方便我们了解当前性能状况，同时对性能趋势波动做出反应。

多维分析

为了方便挖掘性能可能的瓶颈，需要从多维的角度对数据进行分析。例如移动端最重要的维度就是网络，数据处理上除了总体数据，还需要根据网络类型对数据进行分析。常见的维度还有系统、浏览器、地域运营商等。我们还可以根据自身产品的特点来确定一些维度，例如页面长度分布、简版炫版等。

需要注意的是维度并不是越多越好，需要根据产品的特点及终端来确定。维度是为了方便查找性能瓶颈。

小插曲 ：之前从微博中看到有人评价说想做监控但是公司没有日志服务器。并不需要单独的日志服务器,只要能把统计的这个请求访问日志保存下来即可。如果网站自己的独立服务器都没有还有解决办法，在百度开发者中心新建一个应用，写一个简单的 Web 服务将接收到的统计数据解析存到百度云免费的数据库中，然后每天再用 Mysql 处理下当天的数据即可，对于普通站点的抽样性能数据应该没问题。请叫我雷锋。

Day 6 如何利用监控数据解决问题？

发现瓶颈，对症下药

对于图表制作，比较出名的有Highcharts，百度开发的Echarts也很不错。不管使用什么工具，最关键的一点就是让报表能突出重点，直观明了。

制作报表前多问几个如何让人直观看到目前状况和可能存在的问题，哪些地方可以加强，哪些可以去掉，使用是否习惯等。

有了能反映用户感知的真实世界、并且细分到各个业务功能，有详细的网络等辅助数据，我们在解决前端性能上便更加得心应手。监控系统已经对线上访问状况有了连续的反馈，根据现有评估与瓶颈选择对应方案进行优化，最后根据反馈进行调整，相信性能优化不再是个难题。

如何选择优化方案呢？这又是一个比较大的话题了，好在已经有很多经验可以借鉴。附录中就整理了部分性能的学习资料，可以根据需要阅读学习。

Day 7 总结

通过以上“几天”的努力，我们可以搭建一个小而美的前端性能监控系统。但这仅仅是开始，前端数据有很多挖掘的价值。性能优化也是一门需要认真学习的课程，为了打造流畅的使用体验，为了让用户更加满意，赶紧搭建起自己的前端数据平台吧!

该文写在w3ctech的走进名企 - 百度前端 FEX 专场之后，分享时的 PPT 在这里，视频在这里。

华丽非分割线 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

福利——前端性能学习资料整理

性能准则 ★★★★★

• 雅虎性能军规、中文文章
• 谷歌性能优化文章 推荐

分析工具 ★★★

入门

• pageSpeed 基于谷歌性能准则的检测，可浏览器安装插件运行
• Yslow 基于雅虎性能准则的检测工具，可浏览器安装插件运行
• pageCheck 百度内部开发，指标齐全，支持自动运行

进阶

• webPageTest 查看页面加载瀑布流等数据，进阶必备工具
• Chrome 开发者工具 功能强大，值得学习
• PhantomJS 功能强大的分析工具，高手必备瑞士军刀
• JsPerf JS 执行性能分析网站，谁用谁知道

浏览器与 Html 标准 ★★

入门

• 浏览器缓存机制
• Navigation Timing、Resource Timing 相关文章请谷歌，必备知识
• DNS 解析过程原理
• 高性能浏览器网络翻译系列

进阶

• SPDY 协议 基于此的 Http2.0 协议即将发布
• 浏览器渲染原理 比较难懂，但是非常经典
• Chrome 实现原理学习指南 多益大牛的总结

开发实战 ★★★★

通用

• 高性能 JavaScript
• writing-fast-memory-efficient-javascript
• Understanding and Solving Internet Explorer Leak Patterns
• 模块化加载 FIS、SeaJS。FIS 有完善的静态资源管理和优化方案，推荐。
• 前端性能优化最佳实践

动画与渲染

• requestAnimationFrame
• 16ms 的优化
• css、JS不要引起 Repaint & Reflow

移动端开发

• Improving the Performance of your HTML5 App
• Steve Souders
• Creating High-Performance Mobile Websites
• HTML5 Techniques for Optimizing Mobile Performance
• 移动 web 站点优化指南

性能监控 ★★★★

• 监控指标选取
• Complete Web Monitoring - Web Performance at eMetrics
• berserkJS 建立前端性能监控平台
• NY Web Perf Meetup: Peeling the Web Performance Onion

相关会议 ★★★

• velocity 业内最出名的国际会议之一
• Google I/O
• Qcon

推荐博客 ★★★

• web performance today
• perfplanet
• stevesouders.com
• site-performance-and-optimization

作者：zhangtao (http://weibo.com/u/1733215473) - 学无止境