车东[Blog^2]

“我不是塑料袋”是一个很有趣的设计创意： I'm not a plastic bag

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

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

按此阅读全文 "[AD] “我不是一个塑料袋” 博客大巴环保袋设计大赛 一等奖为MacBook Air + 5000￥" »

尝试：
启用了PHP memcache_set()函数中的 MEMCACHE_COMPRESSED压缩选项，而memcache_get()可以在后续读取过程中自动对压缩的缓存对象进行解压缩。

效果：
测试了一下，对于博客大巴目前的应用来说，启用压缩后，相同的容量（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%的传输性能消耗所得会大于文件压缩带来的性能损耗；

按此阅读全文 "启用MEMCACHE_COMPRESSED压缩，“扩容”MemCached" »

HTTP 1.1的规范建议所有的请求输出都包含Vary Header，目的是针对对前端缓存服务器，增加针对Vary制定的各种Header类型进行不同的缓存处理，在浏览器规格复杂的情况下，不利于缓存的命中，所以要在被缓存的服务器上设置：

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

按此阅读全文 "利用Header机制隐掉Vary，提高mod_cache缓存的命中率" »

纯技术人员工种，需要撰写代码，这确实是个体力活，所以我们需要您比较年轻。但我们一样需要您有至少一年的网站开发的工作经验（学生时代自己摆弄建站亦可），曾经独立开发过某个项目（或者是主要成员）。 我们需要您有在LAMP平台上纯熟的工作经验，可以基于SVN和其他开发人员进行协同开发，能够直接投入到独立开发工作之中。 如果您曾经开发过/Hack过Blog系统，那是会得到加分的。技术能力当然很重要，但我们更看重您的学习和钻研能力。

简历请寄到：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操作；

按此阅读全文 "[博客大巴招聘] PHP程序员，工作地点在上海 欢迎应届毕业生" »

上海互联网同行经常能有一些很务实交流，比如：VeryCD向博客大巴介绍过Google的免费企业邮箱的注册方法和CDN服务商， 而同客齐集的交流中我向王建硕请教过：微软是如何量化开发人员的工作饱和度，评估开发人员的工作效率并鼓励开发者按时完成任务的？从后来通过对BugFree这套系统的使用交流中了解了一些考核机制在任务跟踪系统中影响这些因素的方法。

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

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

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

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

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

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

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

按此阅读全文 "BugFree的使用：开发过程的量化统计工具" »

“找到任何事，沟通所有人”，一直是用户上网最基本的2个需求。找到任何事皆本上是由通用搜索引擎解决了，很多新出现的社交网络都在努力成为“沟通所有人”这样的一个中心。和传统的邮件/IM等服务不同，新出现的很多社交网络服务都越来越像一个开放的订阅中心演变，在这里可以看到你关心的朋友最新消息：谁发起了什么活动；谁推荐了有趣的视频，谁写了blog等等；所以先上邮箱收邮件，后到facebook看看最近有什么通知已经成为了很多美国大学生习惯的一部分；而在这个服务中，首页dashboard是最重要的入口，以下是一些此类服务的首页dashboard截图：
facebook的dashboard： 支持的应用很多，如果联系人都相互认识就能找到每天必看的理由；

spaces.live.com的dashboard： 只有Live系列服务的更新

PLAXO：最近推出了pulse服务，包含群组等服务，plaxo最早是作为邮箱联系人管理服务商出现的；

这些社交网络平台的一些特点：
1 都有基于电子邮箱/IM的导入联系人的功能： 可以充分利用原有在邮箱服务和IM中积累的社交联系，而且传播速度更快；
2 大部分都支持基于RSS/API应用的内容导入入口，这样可以方便的将用户在其他平台上积累的内容导入过来；

a34dbdcad88bffd951d272c49ab730a2 for blogbus

按此阅读全文 "各种社交网站的入口dashboard比较" »

Putty是最常用的远程登录工具和加密代理访问工具等，管理很多台服务器的时就有很多登录配置，当换机器的时候就成了一个问题。今天系统管理员告诉我了一招，在Windows的命令行下运行：

REG EXPORT HKEY_CURRENT_USER\Software\SimonTatham SESSION.REG

按此阅读全文 "PuTTY使用笔记：登录设置的批量备份导出/导入" »

很多个人的创业公司都是使用免费的GoogleMail作为员工邮箱（现在已经可以直接免费申请，不用邀请了）；稍微大一些的，则可以自己的公司邮件系统托管在了Google的企业应用套件平台上： 免费版就包括了支持数百帐号的6G邮箱（含邮件列表），在线日历，现在文档共享等功能，而且邮箱的帐号是可以绑定GTalk IM服务的。最常见的问题是如何申请： 从中文界面到了第二步填写信息的时候，总是会提示你选择的国家（中国）"Google 企业应用套件目前不支持该国家/地区的域名。"

这里有个问题： 最重要的是要通过美国的代理服务器访问；
1 申请的域名必须是.com域名的邮箱：如果有.cn com.cn域名需要申请，可以先申请一个.com域名的，然后设置另外的.cn .com.cn域名为相应的.com域名的别名即可；
2 申请的国家填写美国： 注册页面是有IP对应国家的校验的，所以要通过美国的代理服务器填写注册页面才能提交通过；

3 电话号码填写一个合法的美国电话号码：555 222-2222；

注册后：
1 会有域名拥有者校验：
在网站根域名的目录下，上传一个带有校验码的googlehostedservice.html文件；
2 域名MX记录修改等，基本上按照提示修改即可

ASPMX.L.GOOGLE.COM. 10
ALT1.ASPMX.L.GOOGLE.COM. 20
ALT2.ASPMX.L.GOOGLE.COM. 30
ASPMX2.GOOGLEMAIL.COM. 40
ASPMX3.GOOGLEMAIL.COM. 50
ASPMX4.GOOGLEMAIL.COM. 60
ASPMX5.GOOGLEMAIL.COM. 70

在博客大巴具体使用下来的优缺点附后……

按此阅读全文 "免费企业邮箱： Google企业邮箱的申请" »

今天收到一封垃圾邮件：但是在GMail中居然直接就显示了邮件中的图片。我手工标记垃圾邮件后很奇怪：为什么GMail对一封垃圾邮件未经就允许显示图片了呢？

后来看了邮件的信息发现： 这个垃圾制造者的发信人写的地址是我的邮箱地址。利用了GMail等很多邮箱的可信任邮件地址的机制，每个人的可信任发件人列表都不一样，但邮箱主人自己很有可能给自己发过邮件（比如用于备份照片之类的）。所以声称发信人是你自己的时候：就有很大概率是可以显示图片，于是图片请求就被发出了，同时发送给spammer服务的还有你的浏览器信息，来源地址（mail.google.com）等；

最近看到了一些关于Google Account的潜在XSS风险的报道，其实任何一家的服务，安全风险都是存在的，关键的问题是当你对一个服务或者帐号产生很大依赖的时候，进行一次丢失密码的演习还是非常有必要的。Google account可以通过邮箱安全问题和备用邮箱找回忘记的密码，但是被盗的确就比较麻烦了。

按此阅读全文 "邮箱中显示图片的显示安全风险： 自己的信箱地址不可以信任" »

下午参加了UCDChina上海书友会的活动，也谈到了图片服务的防盗链问题。Hanson发过一篇牢骚： 门户网站的blog服务大部分都是禁止其他网站引用上传图片的，而最近国内专业的图片管理网站又拍也限制了图片的外链访问。从图片的hosting网站来说： 由于存储设备和存储机制的改进，图片存储一般不是太高的成本。主要的成本在于带宽：而很多盗链（寄生）网站经常利用免费服务存储一些色情图片，这些内容的流量非常大，如果不及时控制的话，非常容易形成破窗效应从而导致免费服务的成本失控。 同样是个人图片管理网站： FlickR是如何对图片流量进行成本控制的呢？

技术保障：
1 有基于用户帐号的月度流量控制。免费用户一个日历月的流量以前是有上限的20G（现在没了），上传文件的空间上限是20M（现在是100M）；
2 FlickR的缺省供免费用户共享的图片大部分是较小幅面的缩略图：幅面一般在400像素以下，文件大小只有几k到几十k；收费用户才可以从外站引用原幅面的图；
3 用户帐户注册是要有邮箱校验的激活机制，防止自动/机器大量注册免费帐号；

用户协议上：
1 如果发现免费用户使用非原创内容，flickr是有理由删除内容并停用帐号的；
2 Flickr在对外共享图片的时候： 是要求加上链接指向原图（在FlickR上的）地址的，并且为图片插入很多Blog系统提供的API支持；

按此阅读全文 "FlickR如何控制外站的引用（图片盗链）" »