在 ziz 的时候，cto 的技术选型不合理，对使用技术缺乏必要的了解，采用了旧和大而笨重的中间件。因为 tcelery 的核心开发者不再维护代码，所以需要重新选择更加合适的技术方案。
原版的 tcelery 有几点问题：
- 对于redis的backend，存在race condition的情况，具体要参考下对应的git仓库的issue
- 对于超时的处理，如果worker跑这个任务运行的运行时间超过规定时间，客户端的连接就会卡死
- 代码时间有点旧了，作者mher也没有继续维护和做codereview的工作后来认识了一个提交 pull request 的童鞋，因为作者没有维护采纳修改的缘故，他做了一版新的工具，totoro。现在的项目就是基于这个来开发的。
ps: segmentfault 有专门一个问题来讨论这个 bug 的，也可以去看看解决方案（其实是我自问自答啦）。
因为项目的需要，看了不少 react 的资料，整理出来。
接触 web 最开始的时候，是做重构，那个时候便想着一定要学下网页设计，于是就找了下面这本书。
作者是一个叫 jason Beaird 的外国友人写的，非常的薄，但胜在把一些纲领都列了出来。
创业者要做的事儿，说简单也简单，说不容易也不容易：
那些常常审视自己思考质量的人，都会很认真地定义自己所使用的概念：
再进一步，其实总共可以问两个问题：
正确的方法论可能是这样：
很多的时候，就是这样，所谓的 “平和” 只不过是认真思考的结果。
所以说，说服他人的终极技巧，是这样的：
种下种子，坚决不提结论，让他自己想。
接触编程的那段启蒙的日子，有玩过 gentoo，一个给你材料让你自由发挥的小玩物，不过后来折腾不起，逐渐就放掉了。
笔记里面还有之前整理的一些资料，都放出来吧～
zdlive 是我大四实习的一家公司，当时在那边负责前端模块，写了蛮多的笔记，现在整理出来～=）
相比起后台的优化，前台的优化一般都会被忽视，但其实在用户发起一个页面请求，到页面最终展现给用户，前端所占的比重是非常大的。看了《高性能网站建设指南》，还有《构建高性能 Web 站点》的部分章节，针对 zdlive 的页面，可以做如下优化尝试。
优化的指导方针共有 13 条，结合 zdlive 讲。
一般我们的网页会有如下三种，图片、css 文件、js 文件和 html 文件。当用户在输入输入网址的时候，浏览器会向服务端发起一个 http 请求。当这个 html 文件被下载到客户端之后，其他的组件才开始下载，我们以 zdlive.com 为例。
可以看到，所有的组件下载，都是等到第一个文件载入完毕后再发起的，而这里的每一项都是代表着一个 http 请求。
对于一个页面来说，多个 http 头并没有什么关系，但对于响应速度和稳定性要求高的，比如 zdlive 的首页，尤其是 gprs 这样坑爹的网络下，多个 http 头，意味着速度慢，请求失败的几率会很大，页面显示不完整等等问题。
那我们要做的就是减少 http 请求了。
方法有如下几种：
对于我们的首页来说，这种做法还需要实际测试下。
坏处是 Base64 位压缩以后，图片的大小会变大。但结合服务端的 gzip 压缩，减少客户端的 8 个请求，还是可以尝试下的。
对于一个文件来说，通常会有多个脚本文件和样式文件，分开是模块管理的需要，但有时候也可以结合在一起，合并下载。但这个单个文件大小，和多个 http 请求头之间的怎么去权衡，我还不是很清楚。 ## 使用内容分发网络 内容分发网络的意思是说，假设我们公司现在有多台服务器，一些专门用来跑应用支持，一些专门用来给用户下载文件的，比如 img 文件、mp3 文件等等。而这里，内容分发网络就是指这些用来下载的服务器了。只是，他们现在都在北京这个地方，如果这些被用户用来下载文件的服务器能部署在全国各地，那对于用户来说，更近的服务器，就意味着更短的相应时间和更快的下载速度。
拿 douban 的豆瓣 FM 来说，当我发起访问的时候，实际上我听的歌曲并不是在北京那边的服务器给过来的，倒是从广州这边的服务器下载的。
具体测试，可以用下抓包工具查看 ip 地址信息，海富推荐用 fiddler2。
继续阅读研究测试开发相关资料做的一些总结，备用～
献给那些喜欢阅读和创造的读者～=）
