这篇读书笔记的主要内容是在家里用ipad上输入的，感觉输入还是比较吃力呀。

本书的副标题是Build More Responsive Apps with Less Code， 关键词是异步、响应式，主要是对如何书写异步js代码提供一些指导意见，描述js的异步特性，回调代码的书写，还介绍了PubSub、Promises等通用模式。 最后介绍了worker多线程模型，js异步加载等内容。书的页数可谓少得可怜，内容还算比较实在， 提供了大量的开源库实现供读者参考，对于框架选型的话倒是可以参考一下。

js事件

主要是了解事件背后的本质。提供了象setTimeout document.onready都是事件的典型案例。 因为js基本都是单线程模型，所以事件的触发和代码的执行有时候并不一致，而是有些时间差。即使是setTimeout(fn,0)这样的代码。 这样的逻辑也不是立即执行的。它的执行模型大概是这样的(在ipad上手绘的)。

任何回调方法的执行都是需要按队列顺序来执行。如果当前代码没有执行完,就不会执行其他回调方法。 因此理解js的异步处理模型非常重要，代码应该尽快执行完毕，避免阻塞其他代码的执行。

哪些是异步逻辑

主要是一些io操作。例如

1. ajax调用
2. webkit里边的console.log
3. dom操作，浏览器可能会延迟的效果出现
4. Node服务端里边比比皆是

当然还有些是时间片操作。例如

1. setTimeout或setInterval
2. node的process.nextTick
3. html5提供的requestAnimationFrame等特性

异步逻辑注意

如果使用回调方法进行异步处理，就不要在后面的代码中按同步的逻辑来考虑。
异步回调方法中用到的对象也应该先定义，避免由于缓存等造成奇怪的问题。
可以使用web worker api或异步调用来生成缓存数据。
避免超过两层的回调方法。

处理错误

使用异步调用时，stack trace可能会不全
使用异步调用时，try-catch可能会失效
使用err来作为回调方法的参数，或者区分success和error的回调方法
处理uncaught异常，可以使用:

# Broswer
window.onerror = function(err){
}

# Node 
process.on('uncaughtException', function(err){
})

流程控制

回调方法太多，流程控制变得异常困难，很容易造成错误，应该避免超过两层的回调方法。 比较常用的办法有PubSub、Promises等解决方案/模式。

PubSub

就是publish/subscribe,发布订阅，常见的监听器模式。通常是把回调方法组织为带名字的事件，模拟事件触发。例如

1. Node的EventEmitter
2. Backbone的Event模型
3. jQuery的自定义事件

需要注意的是，PubSub模式的逻辑不一定是异步的。 如果trigger是同步逻辑，应该注意避免在回调方法中再次trigger某个事件而造成死循环， 例如jQuery就可能出现这个问题，而像backbone在值没有变化时不再触发change事件，也提供了slient的选项。而Ember之类是采用setTimeout的方式 加入队列进行处理的方式，就是采用了异步的方式。

Promises

书中主要使用了jquery做例子，显示了deferred的用法，对callback的用法有个比较。 熟悉jquery的童鞋通过Deferred的用法就有个大体的印象了。我个人的感觉就是，Promises模型是对PubSub常用功能的抽象， 有点规范的意思，事实上也的确有commonjs的Promises/A规范。

介绍了promises和deferred的区别，deferred是promises一个子集，它不能自己控制状态变更，需要有由其他事件出触发。 对于node来说，现在是采用回调方法的方式，要采用deferred方式，主要做些改变。例如：

deferredCallback = function(deferred) {
  return function(err) {
    if (err) {
      deferred.reject(err);
    } else {
      deferred.resolve(Array.prototype.slice.call(arguments, 1));
    };
  };
}

var fileReading = new $.Deferred();
fs.readFile(filename, 'utf8', deferredCallback(fileReading));

Async.js

介绍了async.js的用法，用来解决异步处理中的流程控制问题，例如iterator的问题。包括串行和并行的控制。 这个库还提供了更加复杂的并发性控制。具体的用法还是看官方的介绍吧。还提供了另外一个库step的介绍

Worker

提供worker的功能，在浏览器上worker还是有一些受限制的地方，例如不能涉及DOM。 而在node上，可以用cluster来支持类似worker的功能。

异步加载js

主要探讨了几种方案，如在head加载，缺点是页面显示太慢。在body末尾加载，问题是还是要等js结束还能让事件生效，并且同样需要顺序加载。 解决方案有defer/async和ajax加载等方案。

对于比较现代的浏览器，支持defer关键字用于异步js加载，还有async关键字，区别是后者不会顺序加载，先加载完先处理。 async在有些插件化的js时async可能可以用到，其他就很难用到，因为很多js都是存在依赖的关系。

当然，还有一些介绍了自定义的异步加载方案，如html5对象有onready事件,还有ajax加载方式。 不过业界已经有些比较成熟的异步加载库了，如yepnope

最后还介绍了一些异步加载的其他方案，例如增强的语法来支持异步逻辑。这种预编译的方式，我感觉不如在coffeescript上增加关键字的预处理方式， 类似coffeescript的class关键字。另外还介绍js1.7关于异步逻辑的新特性:Generator。

这是前两天在家里用手机敲的文字记录，小小的总结，希望对写作信心不足的童鞋有所帮助。

写博客，不需要太在意写作技巧，文学性的问题，只需要把事情描述出来就可以了。 假如有个场景是水龙头漏水，写下来的是什么偷税漏税，积少成多的东西，那是文学。不需要想得那么远，能赶紧把事情描述好，赶紧修理好就行了。 单纯的记录，本身已经很难能可贵了，但很多时候我们连这个都做不到。

我以前写过很多博文，里边有很多是流水账的记录方式，有个基本的格式: 今天发生什么了，我觉得怎么样，假如这样的话会怎那样。基本是想到什么就敲什么，很简单吧。 我觉得这个方法的好处是培养写作的信心，因为这样比较容易出内容嘛。坚持写，写得越久越容易有信心写下去。

虽然读者对象很重要，但是一开始也没有多少读者，所以不需要太在意读者是谁，把自己当成唯一的读者就好了， 对自己负责，不求内容精妙，但求格式工整，不是火星文。字数多少不在意，能写多少就写多少。

一开始很难写出什么内容，只要坚持写就行了，慢慢就会写好了。 经常回顾，多看看自己写的内容，对比别人写的内容，找到差距，有针对性的提高写作技巧，例如多模仿。

如果有可能，为自己的博客做一下分享推广，让别人参与讨论，可以增强自己写作的信心，也可能得到很多的灵感，在以后写的更好。 推广的方式可以考虑rss订阅，邮件分享，微博等。

博客系统尽量找简单点的，以前我使用blogspot就是因为界面比较简洁，还有像Svbtle/Obtvse这样的简约风格博客平台 像wordpress之类的系统，适合喜欢折腾的人:) 最近比较流行的是像github page和jekyll这样的静态页面生成方式，还是比较适合it人的, 我现在也是使用这套系统。

最后，马上动手，enjoy it!

春运临近，浏览器抢票软件也变得流行，没回来那几天就看到新闻说:12306 抢票版插件拖垮 Github 服务器 ，没想到回来之后就发现github page不能用了，正确的说应该是github的子域名都不能用了，看来是贴倒部和宫刑部的新春贺礼来的。

抢票插件和github什么关系

抢票插件引用了github上的一个js文件，但github有个安全检测，当访问比较频繁的时候就会直接返回403 forbidden。 然后作者没多想就在插件里加了个重试机制。如果返回的是403就每5秒重试一次，并且是永久重试，结果github认为你访问的更频繁了于是一直返回403。 可想而知这就成了死循环，使用插件的用户一多，对github而言就产生DDOS了。 换句话说，这是github的一种安全机制而已，抢票插件和github基本没什么关系，有关部门的做法更是弱智得不行呀。:)

轻功之ssh

以前用过free gate这种东西，不过不大稳定，而且感觉风险比较高。呵呵，你懂的。
ssh使用帮助,跟人感觉用ssh命令行配合chrome插件是最方便的。
免费ssh代理,速度还不错，不过不是特别稳定。
Nutz福利之轻功,应该不错,不过我还没用上。

刚读到这本书的时候，有种相见恨晚的感觉。不同于一般的时间管理类书籍，无病呻吟式的洗脑不见了，例子也少了强加因果关系的痕迹，有些观点印象比较深，值得一读。下面是一些比较有感觉的部分，和大家分享一下。

欲望

人希望欲望尽快得到满足。这是人性，所以衍生了速成，不劳而获，学习浮于表面这些浮躁的社会现象。在这之前，我真的没有意识到这是人性本质的的一种表现，对于有些新同事急于求成的想法，甚至是自己，也经常有难以理解的感觉。没能理解到这点，就很难说感同身受了。

成功学

虽然我也读过一些成功人士的经验之谈，我向来对成功学理论不大感冒，因为多读几本就会发现，他们经常夸大某一方面对结果的影响，很多例子也很牵强，再加上环境的不同，这些经历基本是不可复制的。李老师在书中也反复强调，要警惕成功学，要有自己的独立思考。独立思考，成熟心智，管理自我，才是书中强调的思想。

时间管理

读书，除了希望能找到不同的观点，还希望能有些支持这些观点的可操作性方案。其实关于时间管理方面的著作，我也知道一些，例如使用TODO，GTD等工具，番茄工作法。 李老师也有类似的一些做法，例如代办列表，下一阶段代办列表，每日事项回顾。关于每天晚上回顾做了那些事，这个在其他书上没有特别指出，不过李老师提到的回顾发现没什么可以写的尴尬，我也经常遇到。让我产生这些做法不可靠的感觉，后来才发现，这个和代办事项的优先级与难度有关。自己经常会倾向于先完成熟悉的，简单的，感兴趣的，而不是重要的，困难的。这样即使看上去完成很多东西，回顾的时候发现没什么可以值得一提的事情。

计划

计划不如变化快，但我们还是需要计划的。关于计划，我发现自己经常高估自己的能力，这个需要多考虑意外，给自己心理估计时间多加一段时间，并且把计划细分，对于不熟悉不感兴趣的事情，更应该如此，把时间分为多个时间片，不断接近目标。书中关于这部分的内容和番茄工作法的理论有交叉，个人感觉番茄工作的理论更详细和有针对性些吧！

有趣言语

李老师常说的一句话是，相信我，你并不孤单。并引用了正态分布的理论，使得这句话特别的深刻。整本书妙语连珠，读起来比较轻松。

Wunderlist是一个TODO管理工具，支持多种客户端的同步，在多个客户端中的界面风格不会差别很大，实用性、可操作性都相当不错。 关于这类TODO工具的具体使用，我就不再长篇累牍了。这里主要结合wundeler，讲讲自己对TODO管理的经验教训。

首先，要焦距于你需要处理的事情，而不是你使用的工具。无论使用怎样的工具，都应该把焦点放在TODO事项上。 有些人喜欢玩弄软件的新功能，我也经常迷恋于寻找软件的功能而忽略事情的本身，导致浪费在使用软件上的时间太多。 所以使用TODO工具，关键是TODO事项是否能够有计划的进行。

其次，工具尽量要简单实用，在使用某个工具的时候，有时候感觉功能有所缺失，所以有些人可能会尝试不同的工具或者在多个工具换来换去， 试图寻找那完美的工具。说实在，这个成本太高了，多关注待处理的问题本身吧，多反向思考:真的需要这个功能么?频繁使用么? 就wunderlist来说，我也感觉缺少些功能，例如结合日历功能，有时候同步会有些问题。不过这些都不影响我使用关键功能，也让我能够 焦距于TODO本身。

最后，说说我使用wunderlist的方式吧。一般来说，我会在某天当做一个周期的开始，把我能够想到的TODO事项记录上去，不区分轻重缓急， 也不考虑工作量和时间因素，也不管是工作、生活还是学习的范畴。总之有多少就写多少，如果事项比较大并且有些明显的分割点，我也会拆分成多个TODO。 然后开始对任务进行挑选，得到需要处理的事情列表，如果列表太长，会把某些重要和紧急的进行加星。这样就可以让关注的事情就在一定的范围之内。 从这部分列表中挑选事项，集中精神逐项处理。周而复始，这样让每天都可以看到成果，激发自己的动力。

ps: 我不是什么GTD专家，仅供参考。不过wunderlist真的是不错的TODO工具，推荐使用。