《编程语言教程书该怎么写: 向K&R学习！》
http://www.cn-cuckoo.com/2011/06/05/lax-language-tutorials-2450.html
这文章说的太对啦。
有人说 Jeremy Keith 的《JavaScript DOM 编程艺术》和《Bulletproof Ajax》写的太简单太薄，是坑钱用的。简单就不要看嘛，人家不是写给你看的；我这种非计算机科班专业的看着就很对胃口，它打开了我的兴趣。而现在学习 python，就是在 shell 敲代码，把 shell 敲穿了也不知道有什么用，验证书中例子吗？现在市面上大部分的编程语言书，都是写给已经掌握了一本语言想学其他语言者用的，简明教程就是简明语法。真正零起点的人掌握那么多语法有什么用，看着看着就困了。
21岁英国小伙环球旅行，途中写了《JavaScript Web Applications》和《CoffeeScript》，最后入职 Twitter 做前端开发的工作。看了这篇游记，眼泪夺眶而出……
· 花了10个月的时间做世界环游，途经非洲，东南亚，澳洲，中南美洲里的17个国家和地区。这次旅行的主题就是冲浪和摄影。
· 出席在香港，日本，美国和伦敦举行的会议。
· 启程时给O’Reilly出版公司写了一本书，书名叫做《JavaScript Web Applications》。
· 另外写了一本关于CoffeeScript的书，很快就会由O’Reilly公司出版。
· 写了大量的开源库，例如Spine, Spine.Mobile, GFX, 和 Juggernaut。
· 筹划了一个创业公司的框架。
· 出席伦敦2011FOWA会议。
· 最后，我在Twitter公司找到了一份工作。
《旅行，写作，编程》
http://www.aqee.net/traveling-writing-programming/
《JavaScript Web Applications》中文版
http://ued.taobao.com/blog/2012/02/03/jswebapps/
facebook使用chunk技术让页面分块输出成很多JS段，这样做的好处就是服务器和客户端可以并行进行处理，不用等服务器全部处理完毕，客户端才进行处理。
举个博客园首页的列子，博客园首页分为下面几块(“推荐博客排行”,”首页随笔列表”,”最新新闻”…)
我们一般对该http请求处理如下：
- 浏览器发送http请求；
- 服务器处理请求(从缓存读取前50个推荐博客，从数据库读取”首页随笔列表”,从数据库读取”最新新闻”)，生成首页的html代码；
- 服务器发送html代码给客户端；
- 浏览器接收到响应，处理html。(下载css,js,image,执行js等等)
可以看出传统的http请求4个过程中，每个过程都必须等待前1个过程完成后才能执行，这样就存在很大的资源浪费。
facebook的对该http请求的处理如下：
- 浏览器发送http请求；
- 服务器处理请求；
- 从缓存读取前50个推荐博客,生成”推荐博客”的js代码段，flush输出该代码段；
- 服务器继续读取”首页随笔列表”，并生成输入js代码段；
- 服务器继续读取”最新新闻”，并生成输入js代码段。
- 浏览器接收到js代码段，下载该代码段所需的js和css。插入html代码。
在这个处理流程中，最大的特点就是2,3是并行进行处理的，服务器处理完一部分数据就把已经处理好的数据交给浏览器进行呈现处理，自己再继续处理其他的数据。
原文链接：
《名站技术分析 — facebook奇特的页面加载技术》
————————————
相关博文：
《为什么Facebook比以前快2倍》
随着用户的增多,几乎所有网站都会面临一个问题：网站速度变慢，用户体验变得不好。Facebook已经有超过5亿的用户，其用户增长速度令人震惊，但是人们从来没有发现Facebook变慢，相反，它正变得越来越快！Facebook 为什么能越来越快？
罗伯特 约翰逊（Robert Johnson）是Facebook的项目总监，他说：在工程师团队对Facebook代码进行了重写和深入优化之后，网站的速度以前快了2倍。
1.Facebook花了多久才让它变快2倍的呢？
罗伯特 约翰逊：我们对网站进行的大幅度的”改革”，这的确使网站速度得到很大的提升。工程师团队花了大概一个月来规划这个项目，具体的实施过程则花费了6个月。
2.在这次的重写行动中，你们在技术上做了什么大的改进？
罗伯特 约翰逊:我们队源代码做了比较多的优化和重写：
1、把用户请求之后的内容生成、网络传输和网页渲染的时间重叠起来;
2、把相应的功能代码放进一个在页面初始化时需要用到的Javascript核心功能文件中;
这个项目叫做”BigPipe“，只要当客户端的浏览器准备好了,我们的服务器就会以最快的速度以流的形式传送内容，当我们的服务器还在产生数据的时候，客户端的浏览器就已经开始下载静态内容和渲染页面最重要的部分了，我们把几部分的时间重叠了起来，使用户感觉更快。这个新的JavaScript库叫做”Primer“.
除了服务器端的大项目之外，我们还对所有的文件都进行了”瘦身”，让一切变得更小更轻，比如我们进行了CSS图片合并(CSS Sprites).
3.Facebook是否鼓励开发员大胆尝试和创新呢？
罗伯特 约翰逊:也许这是这个项目最棘手的部分之一。对于Facebook来说,开发速度是最重要的指标之一，我们不希望看到任何会使开发速度慢下来的事情。我们既要让开发人员尽可能容易的完成任务,又要使网站代码尽可能得到优化，所以我们制造了一些辅助开发工具，它们能使鱼和熊掌兼得。比如Primer，让它使Facebook运行得更快和让它易于集成和不容易被误用是同等重要的。
我们监测一切可能会影响程序性能的因素，并开发相应的工具，在程序正式放出之前检查代码。
这很重要，一旦代码出现问题，系统就会自动提醒开发人员，而不是靠开发人员自己去检查那些问题。这样开发人员就可以不断地创新，只要在出现一些比较特殊问题的时候，开发人口才需要停下来解决那些问题。
原文： oreilly 译文：http://cnnet.us/taobao/facebook-faster/ 转载请保留出处
200
请求已成功，请求所希望的响应头或数据体将随此响应返回。
一句话总结：服务器成功返回网页301
被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个URI之一。如果可能，拥有连结编辑功能的客户端应当自动把请求的地址修改为从伺服器反馈回来的地址。除非额外指定，否则这个响应也是可缓存的。
新的永久性的URI应当在响应的Location域中返回。除非这是一个HEAD请求，否则响应的实体中应当包含指向新的URI的超连结及简短说明。
如果这不是一个GET或者HEAD请求，因此浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。注意：对于某些使用HTTP/1.0协议的浏览器，当它们发送的POST请求得到了一个301响应的话，接下来的重定向请求将会变成GET方式。
一句话总结：网址永久性重定向302
请求的资源现在临时从不同的URI响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。新的临时性的URI应当在响应的Location域中返回。除非这是一个HEAD请求，否则响应的实体中应当包含指向新的URI的超连结及简短说明。
一句话总结：网址临时性重定向401
当前请求需要用户验证。该响应必须包含一个适用于被请求资源的WWW-Authenticate信息头用以询问用户信息。客户端可以重复提交一个包含恰当的Authorization头信息的请求。如果当前请求已经包含了Authorization证书，那么401响应代表着伺服器验证已经拒绝了那些证书。如果401响应包含了与前一个响应相同的身份验证询问，且浏览器已经至少尝试了一次验证，那么浏览器应当向用户展示响应中包含的实体信息，因为这个实体信息中可能包含了相关诊断信息。
一句话总结：未授权—未授权客户机访问数据403
伺服器已经理解请求，但是拒绝执行它。与401响应不同的是，身份验证并不能提供任何帮助，而且这个请求也不应该被重复提交。如果这不是一个HEAD请求，而且伺服器希望能够讲清楚为何请求不能被执行，那么就应该在实体内描述拒绝的原因。当然伺服器也可以返回一个404响应，假如它不希望让客户端获得任何信息。
一句话总结：服务器拒绝请求404
请求失败，请求所希望得到的资源未被在伺服器上发现。没有信息能够告诉用户这个状况到底是暂时的还是永久的。假如伺服器知道情况的话，应当使用410状态码来告知旧资源因为某些内部的配置机制问题，已经永久的不可用，而且没有任何可以跳转的地址。 404这个状态码被广泛应用于当伺服器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下。
一句话总结：404表示临时性，410表示永久性413
伺服器拒绝处理当前请求，因为该请求提交的实体数据大小超过了伺服器愿意或者能够处理的范围。此种情况下，伺服器可以关闭连接以免客户端继续发送此请求。
一句话总结：数据量过大，服务器拒绝500
伺服器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。一般来说，这个问题都会在服务器的程序码出错时出现。
一句话总结：服务器遇到错误，无法完成请求