此次我不是塑料袋：环保袋设计大赛活动的奖品为：
评委会奖(1名)：MacBook Air + 5000元现金
( 歌手Yael Naim的那首《New Soul》你每天在电梯中都会听到多次吧？ )
独树一帜奖(2名)：价值5000元以上的尼康D60单反相机1台 + 5000元现金
不拘一格奖(2名)：价值2000元以上的多普达S1手机1台 + 5000元现金

* 奖品涉及到的个人所得税由获奖人自理
* 所有参加投票的网友均有机会抽取100名参与奖： BlogBus明信片一套*50套 触动传媒提供小礼品*50个

效果：
测试了一下，对于博客大巴目前的应用来说，启用压缩后，相同的容量（2G）存储的对象数量增加了约一倍，缓存命中率从50%左右，提高到了60%左右。进一步提高命中率硬件投入还是必须的，又增加了2倍的内存后终于做到了缓存命中率提高到90%；

前提0： 内存缓存有用，且命中率值得提升；
从60%提高到90%，还是从90%提高到95%，要看hit后的性能能够提升是否值得；

前提1：MemCached已经用满
先用memcached-tool查看一下memcached的容量统计，看memcached是不是已经用满了。如果充分运行时MemCached的空间尚未用满，启用一下压缩是没有意义的； 而且：发现没有用满的MemCached，最好减少相应MemCached的容量，空余出更多内存给其他服务做缓存；

前提2： 压缩率
缓存的数据的确有大于几百字节的，如果都是小于100字节的键值对，压缩可能反而带来膨胀。由于缓存对象的大小在Memcached中都是按照固定大小分块存储的，最小也要88 B。所以对于过小数据带来的压缩膨胀并不是太大的问题；

前台应用的CPU损耗：
对数据的额外压缩CPU损耗远远低于缓存命中率提升减少后台数据库访问带来的性能提升，和http的gzip/deflate压缩类似，压缩后数据一般为原数据大小的30%左右，节省了70%的传输性能消耗所得会大于文件压缩带来的性能损耗；

Header unset Vary

问题是这样被发现的：最近使用Apache 2.2的内存缓存mod_mem_cache机制进行后台静态文件加速。但是总是发现几乎是只代理而不缓存，而内存缓存模式又没有统计工具查看缓存内容和命中率。转为用mod_disk_cache后，前端缓存目录空间增加非常快，以至于经常需要删除文件，而删除文件的I/O损失超过了直接访问后台访问的加速所得。后台明明只有几M模板图片和CSS文件，为什么缓存空间上G而且命中率那么低呢？查看了一下缓存目录下的文件，Apache的前端磁盘缓存就会根据浏览器除了针对内容的.data文件和.header文件外还有一个.vary目录，而这个vary目录下又会按照顶级的cache规则再mapping出2级目录来，目录节点个数过多造成磁盘空间的浪费：

a/b/Jqyw8OvBIlgaef7Zb8lQ.data
a/b/Jqyw8OvBIlgaef7Zb8lQ.header
a/b/Jqyw8OvBIlgaef7Zb8lQ.header.vary/a/b

IE : Accept-Encoding: gzip, deflate
Firefox: Accept-Encoding: gzip,deflate

另外一个配置优化是不要启用后台的Expires Header；

ExpiresActive off

记录一个调试缓存缓存用命令行看Header输出的方法：
用curl -I 查看HTTP头信息；
查看缓存后输出结果：
curl -I http://www.example.com/foo.bar
查看缓存前的服务器输出：
curl -I -H "Host: www.example.com" http://ip.address.of.example/foo.bar

[chedong]$ curl -I -H "Host: public.blogbus.com" http://192.168.1.17/rss/xianguo.png
HTTP/1.1 200 OK
Date: Sat, 12 Apr 2008 07:09:51 GMT
Server: Apache
Last-Modified: Mon, 28 Jan 2008 03:34:55 GMT
Accept-Ranges: bytes
Content-Length: 1353
Content-Type: image/png

[chedong]$ curl -I http://public.blogbus.com/rss/xianguo.png
HTTP/1.1 200 OK
Date: Sat, 12 Apr 2008 07:10:01 GMT
Server: Apache/2.2.8 (Unix)
Last-Modified: Mon, 28 Jan 2008 03:34:55 GMT
Accept-Ranges: bytes
Content-Length: 1353
Cache-Control: max-age=20736000
Expires: Mon, 08 Dec 2008 06:27:41 GMT
Node: B01-AD-01
Age: 2540
Content-Type: image/png

简历请寄到：job@blogbus.com，最好附上以前项目的主要项目开发经历：使用的软件包/框架/类库等； 以及你对加入博客大巴十大要求的理解；面试时间一般是每周四下午，公司的具体地址是：上海市徐汇区龙华路2577号5号楼。

如果你在实习：可以考虑以下这个题目（一个月内学习并完成）
一个每天十万级访问的RSS阅读器（每秒2处理完成个请求）；
用户数量1万人，每人平均有20个RSS（每个人有5-100个RSS） FEED（总计有10万个不同RSS，想办法从google blogsearch上搜集一下）；
更新频度：所有FEED平均每天至少2次，其中热门FEED每小时同步一次（占5%）；
估算一下存储量，访问速度和RSS解析（SimplePie）的容错问题等。

基于LAMP平台+MemCached ，目前我们的PHP开发编辑器是： Komodo Edit 服务器端直接用vim编辑；
版本控制是Subversion/SVN和Windows客户端 TortoiseSVN
Windows下的远程登录是PuTTY

大部分操作都是在Linux命令行下操作，所以awk / perl/ grep之类的需要能够熟练到代替简单的过滤排序等SQL操作；

如果说GTD是一个人的目标管理，那么任务跟踪系统就是帮助实现团队的目标管理： 而且一件事情同时被多个人跟踪，还是非常有助于减少任务的被跟“丢”几率的，一个任务的角色有任务的创建者（甲方）和任务执行者（乙方）两个角色； 而开发团队一般会有3个角色来进行任务的跟踪，项目的发起者（产品经理），项目的执行者（开发人员），项目的确认（测试人员），而一个任务按照进行中，完成确认，关闭这几个状态，也有发起时间（创建者），解决时间（执行者），完成确认时间（创建者）这几个关键时间点， 利用这几个时间因素结合创建人，创建原因等因素，通过BugFree的查询生成器可以完成很丰富的开发过程指标统计甚至完成一些初步的KPI考核指标统计；

开发人员的工作饱和度
就是简单的任务量累计，按照每个需求的预算时间进行累加，比较开发人员的工作时间；

任务的平均关闭时间
总工作时间 ÷ 关闭的任务数，用于评估开发人员的工作效率；
1 开发人员不要将手边积累过多的任务，从而让大量的任务处于等待状态；
2 开发人员会要求需求人员尽量将任务分解： 不要有超过2天的任务，便于及时的确认进展；
3 开发人员完成任务后主动告知需求人员，尽快确认完成并关闭任务；

项目响应速度
项目无更新时间不得超过一定时间（比如： 24小时） ，就是统计：项目状态不等于关闭， 最后更新时间相比现在大于24小时的任务，每天统计：被发现就要发出警告相应项目的执行者； 即使项目没有完成，也要通过编辑项目向项目的发起者进行反馈，避免任务被长期无响应状态；

为此： 项目的开发者还需要遵循以下规则；
1 跟踪系统本身只是用于备忘和时间的统计，任务完成还是需要同事间直接（最好是面对面的）交流；
2 项目的执行方不能关闭任务，只能由创建者关闭；
3 执行者另外需要其他开发人员帮助的时候，需要开启新的任务作为咨询；
4 任务类型只计算新增需求，旧需求的错误修正，不计算为工作时间；

设计以上的规则的目的是：
开发者：作为任务的执行者在任务启动后应及时的解决并要求创建者关闭任务，开发者会尽可能多和任务的创建者沟通，尽可能在项目进入任务跟踪前将项目的需求细化并在完成后及时提交测试并关闭，从而达到满足工作工作饱和度的同时，减少单项目完成时间指标；
需求人员：细化需求合理估算工时避免返工，因为项目的执行者是不用对项目需求的合理性负责的，按时开发完毕后因为需求设计错误为开发者计入工作时间，让需求的提出者（产品经理）成为项目风险的承担者，从而避免产品经理即无责任也无权利的状态；

此外： 什么指标可以体现开发者除了完成任务本身外还在不断找新方法提高效率呢？