
车东@FlickR posted a photo:
来源: stat.qwest.net/resources.html
最近在找 [HTTP服务监控的系统和软件,IPTONIC的报价是每个监控页:] 2500¥/ 月 (3个城市) 其实各种监控服务、软件已经非常多了: 报表生成一般都不是太大问题。
1 最初步的:自己写个专门记 [HTTP相应时间下载速度脚本,将服务器的详细相应时间记录成日志。] 然后定期同步到cacti服务器上去生成报表。
2 做一个页面分析脚本,将其中的LINK全部下载,送给下载速度脚本,实现一个页面所有元素的统计;
3 将这套脚本送到多个城市,形成监控网络;
另外有: internetsupervision.com/ 免费3个月的,提供了一个URL检查工具,从世界是个城市(包括北京)检查到一个URL的相应时间。

车东@FlickR posted a photo:
www.spokeo.com 上导入你的MSN gTalk和雅虎邮箱联系人后,就有了这个列表。有用其他SN服务的占全部联系人的一半左右(隐去了用户名和邮箱,不过从使用的服务多少来看,就知道这个人是不是那种新服务的尝鲜者了)。而其中用MSN和FlickR的最多; 联系人少还可以,联系人多了以后spokeo非常慢;
纯技术人员工种,需要撰写代码,这确实是个体力活,所以我们需要您比较年轻。但我们一样需要您有至少一年的网站开发的工作经验(学生时代自己摆弄建站亦可),曾经独立开发过某个项目(或者是主要成员)。 我们需要您有在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操作;
上海互联网同行经常能有一些很务实交流,比如:VeryCD向博客大巴介绍过Google的免费企业邮箱的注册方法和CDN服务商, 而同客齐集的交流中我向王建硕请教过:微软是如何量化开发人员的工作饱和度,评估开发人员的工作效率并鼓励开发者按时完成任务的?从后来通过对BugFree这套系统的使用交流中了解了一些考核机制在任务跟踪系统中影响这些因素的方法。
如果说GTD是一个人的目标管理,那么任务跟踪系统就是帮助实现团队的目标管理: 而且一件事情同时被多个人跟踪,还是非常有助于减少任务的被跟“丢”几率的,一个任务的角色有任务的创建者(甲方)和任务执行者(乙方)两个角色; 而开发团队一般会有3个角色来进行任务的跟踪,项目的发起者(产品经理),项目的执行者(开发人员),项目的确认(测试人员),而一个任务按照进行中,完成确认,关闭这几个状态,也有发起时间(创建者),解决时间(执行者),完成确认时间(创建者)这几个关键时间点, 利用这几个时间因素结合创建人,创建原因等因素,通过BugFree的查询生成器可以完成很丰富的开发过程指标统计甚至完成一些初步的KPI考核指标统计;
开发人员的工作饱和度
就是简单的任务量累计,按照每个需求的预算时间进行累加,比较开发人员的工作时间;
任务的平均关闭时间
总工作时间 ÷ 关闭的任务数,用于评估开发人员的工作效率;
1 开发人员不要将手边积累过多的任务,从而让大量的任务处于等待状态;
2 开发人员会要求需求人员尽量将任务分解: 不要有超过2天的任务,便于及时的确认进展;
3 开发人员完成任务后主动告知需求人员,尽快确认完成并关闭任务;
项目响应速度
项目无更新时间不得超过一定时间(比如: 24小时) ,就是统计:项目状态不等于关闭, 最后更新时间相比现在大于24小时的任务,每天统计:被发现就要发出警告相应项目的执行者; 即使项目没有完成,也要通过编辑项目向项目的发起者进行反馈,避免任务被长期无响应状态;
为此: 项目的开发者还需要遵循以下规则;
1 跟踪系统本身只是用于备忘和时间的统计,任务完成还是需要同事间直接(最好是面对面的)交流;
2 项目的执行方不能关闭任务,只能由创建者关闭;
3 执行者另外需要其他开发人员帮助的时候,需要开启新的任务作为咨询;
4 任务类型只计算新增需求,旧需求的错误修正,不计算为工作时间;
设计以上的规则的目的是:
开发者:作为任务的执行者在任务启动后应及时的解决并要求创建者关闭任务,开发者会尽可能多和任务的创建者沟通,尽可能在项目进入任务跟踪前将项目的需求细化并在完成后及时提交测试并关闭,从而达到满足工作工作饱和度的同时,减少单项目完成时间指标;
需求人员:细化需求合理估算工时避免返工,因为项目的执行者是不用对项目需求的合理性负责的,按时开发完毕后因为需求设计错误为开发者计入工作时间,让需求的提出者(产品经理)成为项目风险的承担者,从而避免产品经理即无责任也无权利的状态;
此外: 什么指标可以体现开发者除了完成任务本身外还在不断找新方法提高效率呢?

车东@FlickR posted a photo:
去年12月份GReader推出了GTalk好友的GReader推荐功能:
googlereader.blogspot.com/2007/12/reader-and-talk-are-fri...
今天好像在在中文版中也混杂了,只是左边的工具栏里没有单独的入口列出;

车东@FlickR posted a photo:
从内容统计上看,大致分布如下:一个很好的Geek应用分布统计
1/3是TWitter
1/5是del.icio.us收藏
1/5是blog发布
1/6是GReader订阅分享