NBA新赛季开始了
October 30th, 2009
1 comment
虽然没有姚明，但nba还是值得期待的，他们打的篮球好像来自另一个星球。
易建联第一场比赛数据不错，不知场上作用是否也一样出色。
希望今天可以多看几场比赛吧。
Archive
Archive for October, 2009
转载：腾讯凶猛?
October 28th, 2009
No comments
我最欣赏作者关于“快速迭代”和“数据挖掘”的观点。
转自：腾讯凶猛?
本月20号去哈尔滨的飞机上，反复把《中国企业家》杂志的这篇封面文章《腾讯：鲜为人知的”水”凶猛》看了几遍。其中不少细节还是比较有趣的。
关于腾讯的创新点
文章中提及，”QQ邮箱在2008年的400多个创新点中，有近300项是由马化腾本人发现和提出”，也就是说腾讯的创新研究团队加起来也就是100项左右的创新点? 是否可以这样理解：产品部门和 CDC 乃至什么数据挖掘的团队其实也就是算给老板收集材料的，信息归集到马本人这里然后自顶向下发动所谓的创新 ? 在近年来标榜创新的腾讯，这不是什么值得夸耀的成绩。
用户体验，快速迭代
这是马化腾做产品的的金科玉律。一般而言，跟随者或是模仿者如果节奏赶不上领先者，谈超越只能是妄想。而腾讯在产品的研发上，节奏的确是不错。其它分析腾讯的人往往容易忽略这一点。很多人诟病初期发展阶段的模仿策略，现在已非吴下阿蒙。
能够快速迭代的一个前提是产品初期必须简单，腾讯邮件产品的发展恰恰是这样。以大而全的功能为目标反而解决不了用户的核心需求，技术上也没办法做到快节奏的改进。
如果对比马化腾以前的关于产品的讲座笔记，事实上会发现他并没有什么神奇的手段，但是神奇的是他能把这些原则坚持下去，而这是所有竞争对手都做不到的地方。《倚天屠龙记》里面张三丰当着一众武林高手的面教张无忌太极拳剑，也是这样的道理。学到神似，不得精髓是没有用的。
数据挖掘是重武器?
胡说八道。这是把一些常识神化的结果。目前没有哪家把数据挖掘做到那么神通，更多时候不过是用数据来验证某些想法而已，但这不能用以证明很多正确的决策是数据挖掘触发的，数据挖掘起到的作用仅仅是佐证而已。事实上，从报道中，我们没看到数据挖掘到底给腾讯什么样的神奇之力。另外，从文章的报道上来看，受访人是把腾讯几个团队干的活都放到一个”数据挖掘”上了。
很多时候，记者希望找到一个公司更为神秘的地方，所谓的”重武器”，以显得报道更加有料，这篇报道多少有点这样的意思。
当然，文章怎么写是一回事，腾讯技术储备上比较可怕，那是真的。
–EOF–
Related posts
Categories: 业界故事
一个奇迹：皇马输给丙级队阿尔科孔
October 28th, 2009
No comments
北京时间10月28日05:00(西班牙当地时间27日22:00)，2009/10赛季西班牙国王杯第4轮首回合一场焦点战在圣多明戈球场展开争夺，皇家马德里客场0比4惨败于丙级队阿尔科孔。
赛季前信誓旦旦的组织“银河战舰II”，结果输给丙级队，而且净吞四蛋。这个世界真的存在奇迹。
让我们在记录一下这个球队的名字：阿尔科孔。这场胜利都他们兴奋一年的了。
Related posts
Categories: 新闻评论
做地铁记
October 22nd, 2009
4 comments
今天汽车限行，坐地铁上班。
连续四天天气晴好，气温回升，这个季节也不那么让人讨厌了。当然，这也要感谢那些大早上就穿着丝袜挤地铁的姑娘们，你们是这个城市的风景。但你们是真不冷呢，真不冷呢，还是真不冷呢？
坐地铁和开车的感受完全不同，开车像工作，而坐地铁像休息。虽然地铁很快，我走的也很快，但大脑是放松而缓慢的（再次感谢丝袜姑娘们）。开车就不一样了，神经高度紧张，相当于高强度工作。
哪天我也像王征一样，车扔家里，坐地铁上班得了。我忽然明白他为什么那么喜欢地铁了。。
Related posts
给nginx和haproxy负载均衡集群里添加backup服务器
October 21st, 2009
No comments
场景很简单：一个前端负载均衡器（lb），两个应用服务器（s1，s2），一个备用应用服务器（s3）。
希望实现：正常情况下是s1和s2提供服务，但这两个服务器都down掉的时候由备用服务器s3提供服务。
作为负载均衡器的选择，我测试了nginx、haproxy和apache，nginx和haproxy都非常容易就实现了上面的需求，apache也有文档说可以，但没有测试成功。
nginx的配置文件如下（配置文件里是一个工作的app服务器，一个backup）：
upstream mycluster {
server 192.168.1.240:8888;
server 192.168.1.222:8888 backup;
}
haproxy的配置文件如下（配置文件里是一个工作的app服务器，一个backup）：
listen appli4-backup 0.0.0.0:10004
option httpchk
#option httpchk /index.html
option persist
balance roundrobin
server inst1 192.168.1.240:8888 check inter 2000 fall 3
server inst2 192.168.1.222:8888 check inter 2000 fall 3 backup
当然，其实最后我可能haproxy和nginx都不选，而选LVS，如果LVS提供这种支持。有空继续测试LVS。
Related posts
Spring MVC的No parameter specified for @RequestParam异常
October 20th, 2009
No comments
今天测试一个程序发现No parameter specified for @RequestParam argument异常。程序是以annotation的方式使用spring mvc开发的。程序在eclipse开发环境下没有问题，但到了正式环境就出错。
问题的解决：正式环境使用ant编译，给ant的compile命令加上debug=true参数。
原因：ant模式是debug=false，所以编译出来的函数声明里的变量名会改变，例如：public String kill(String pid)编译后成为public String kill(String s1)。
这样spring的绑定参数名就不work了。
Related posts
大风起
October 18th, 2009
No comments
今天大风刮起来了，气温跟着急剧下降。我不是不喜欢刮风，我是不喜欢降温，因为一年中我最不喜欢的季节又要到了。“最不喜欢”的季节？居然不喜欢一个季节，而且是北京最长的那个季节，这和我在“热爱”里面写的一点儿不一样嘛！呵呵，事实如此，人会变的嘛。
Related posts
Categories: 生活随笔
在地坛书市擦肩
October 17th, 2009
1 comment
今天在单位加班，适逢地坛书市开张，便利用中午休息的时间走过去转了一转。权作休息了。
天气很好，不冷不热，阳光明媚蓝天白云。票价五元，也很公道。一切都很好。只是进场之后便被人山人海给扰的一点儿兴致都没了。没看书，只是在里面溜达溜达，散散步，看看阳光下北京的文学女青年们。
路过泰山书画院的展位的时候，他们正在做书画拍卖，我到的时候正好拍的是爱新觉罗某某的一幅字：滚滚长江东逝水，浪花淘尽英雄。。。。简直太有缘了。但是在我犹豫了0.5秒之后，拍卖便结束了。于是我就和这幅字擦肩了。
太过寡断了！
Related posts
Categories: 生活随笔
爽
October 16th, 2009
No comments
有段时间没有工作到这么爽了，在eChineseLearning的最后一段也没有这么爽了。挑战很大、压力很大、很刺激，我喜欢。
每天都忙到没有任何其他时间，我喜欢。
猛干一两个月，希望阳历年之前能有奇迹。
BTW：有技术人才欢迎自荐、推荐，有奖！
Related posts
《硝烟中Scrum和XP》读书笔记
October 15th, 2009
3 comments
昨天写一个新项目的开发过程计划，xinbo向我推荐了《硝烟中的Scrum和XP》（Scrum and XP from Trenches）这本书。开始阅读之后就没有停下来，一口气读完，读的非常开心，所以今天写写读书笔记。并推荐大家阅读，理由有三：
- 可以让人读的非常开心。全书净是下面这样风格的话语：“听起来不错？呵，纯粹扯淡。更糟的是，团队一般都是到了会议结束前才发现他们一直在扯淡，到最后还没把故事看上一遍呢！”
- 非常实际。这本书就是作者在一个4、50个研发人员的团队中1、2年（2005年下半年到2007年初）的时间实践Scrum和XP的总结，所以其中有很多实际的经验、教训、建议，很细节。
好了，下面是读书笔记，同样如果对于XP或者Scrum的基本名词没有概念的，简单Google一下就好了，了解一下名词和概念就好，别读太多理论读物。
“Scrum的强大和令人痛苦之处就在于你不得不根据自己的具体情况来对它进行调整。。。。一年过去了，我们在公司里从上到下都实现了Scrum。我们试过多种团队尺寸（3-12人）、sprint长度（2-6个星期）；定义“完成”的不同方式；不同形式的产品backlog和sprint backlog（Excel、Jira、索引卡）；多种测试策略、演示方式、多个Scrum团队的信息同步方式……。我们还试验了XP实践——各种各样的每日构建，结对编程，测试驱动开发，等等；还试过把XP和Scrum进行结合。”
– 我深信“持续改进”“自我完善”这是任何一个开发过程中最重要的理念。幸运的是Scrum把过程持续改进作为了其执行的一个内在环节。
“产品backlog是Scrum的核心，也是一切的起源。我们叫它故事（story），有时候也叫做backlog条目。我们的故事包括这样一些字段：ID、Name、Importance、Initial Estimate、How to demo、Note。我们曾试过很多字段，但最后发现，只有上面提到的六个字段我们会一直使用下去。”
– 很简单是吧？简单就对了。把那么多功夫花在这些事情干什么，有空编码去好不好！
“Sprint计划会议非常关键，应该算是Scrum中最重要的活动（这当然是我的主观意见）。要是它执行的不好，整个sprint甚至都会被毁掉。”
– 在Scrum开发过程中“项目会”是那么的少，所以我也相信“Sprint计划会”是Scrum中最重要的活动。
“Sprint计划会议会产生一些实实在在的成果：
- sprint目标。
- 团队成员名单（以及他们的投入程度，如果不是100%的话）。
- sprint backlog（即sprint中包括的故事列表）。
- 确定好sprint演示日期。
- 确定好时间地点，供举行每日scrum会议”
– 我认为“确定好Sprint演示日期”这个最刺激，呵呵。
“假如sprint计划会议接近尾声，但仍然没有得出sprint目标或者sprint backlog，这时该怎么办？我们要打断它么？还是再延期一个小时？或者到时间就结束会议，然后明天继续？这种事情会一再发生，尤其是在新团队身上。你会怎么做？我不知道。但我们的做法是什么？嗯……我通常会直接打断会议，中止它。”
“几乎每次sprint计划会议都要确定sprint目标。Sprint目标需要回答这个根本的问题，“我们为什么要进行这个sprint？为什么我们不直接放假算了？””
“在大多数sprint 计划会议上，大家都会讨论产品 backlog中的故事细节。对故事进行估算、重定优先级、进一步确认细节、拆分，等等都会在会议上完成。
我们是怎样实际操作的呢？要想收到好的效果，不妨创建一些索引卡，把它们放到墙上（或一张大桌子上）。”
– 一个Backlog一张纸质卡片，听起来不错，很直观，又让大家获得几个小时离开电脑的时间。
“在sprint演示会议上，团队自豪地演示了一个新特性，但产品负责人却皱起眉头，“呃，看上去不错，但这不是我要的！”发生这种事情可真是糟透了！
怎样才能让产品负责人和团队对故事有同样的理解？或者保证所有的团队成员对每个故事都有同样的理解？嗯，这可没法做到。不过还是有些简单技术，可以识别出最明显的误解。最简单的办法就是确保每个故事的所有字段都被填满”
“注意——我们在实践TDD（测试驱动开发），所以几乎每个故事的第一个任务都是“编写一个失败的测试”，而最后一个任务是“重构”（提高代码的可读性，消除重复）。”
– 我们不做TDD，但把“重构”作为最后一个任务也是不错的哈。
“这有个很复杂的问题：技术故事。或者叫做非功能性条目，或者你想叫它什么都行。例如：安装持续构建服务器、重构DAO 层、升级 Jira”
– 这段太长了，但这个问题太重要，很多技术经理都非常关注，所以还是看原文去吧。在P54
“我们要让整个公司了解我们在做些什么，这件事情至关重要。否则其他人就会发出抱怨，甚或对我们的工作做出臆断。”
– 这段也太重要了！但是也太长，归纳一下就是：一个展示项目信息的网页、sprint开始和结束都群发邮件、将Sprint信息打印出来贴到开发团队墙上。
“我们发现管理sprint backlog最有效的形式——挂在墙上的任务板！
找一面尚未使用或者充满无用信息（如公司logo、陈旧图表或者丑陋的涂鸦）的大墙。清理墙壁（除非不得已才去请求别人许可）。在墙上贴上一张很大很大的纸（至少2×2平方米，大团队需要3×2平方米）。然后这样规划：。。。。。”
– 又是“纸质”的东西，嗯，我喜欢纸质的和写在白板上的。原因嘛，还是它可以让我远离电脑，呵呵。
“嘿，该怎样进行跟踪呢？在这种模型中，如果必须跟踪的话，那我能提供的最佳方式，就是每天给任务板拍一张数码照片。我有时也这样干，但一直没用到这些照片。如果你确实需要跟踪任务进度，任务板这种解决方案可能就不太适合你。
不过我建议你应该试着去评估一下，对sprint进行细节跟踪能带给你多大价值。Sprint完成以后，可以工作的代码已被交付，文档也被check in，那还有谁会真的关心sprint的第5天完成了多少故事呢？又有谁会真的关心“为Deposit编写失败测试”曾经的估算量是多少？”
– 我很同意。一个Sprint只有2、3周的时间，这期间的事情让项目组内部自己搞定吧，外部的人那么不放心干什么。
“在安排座位、布置桌椅这方面，有一件事情怎么强调也不为过。
让团队坐在一起！
说的更清楚一点，我说的是
让团队坐在一起！”
“我们的每日例会跟书中的几乎没啥两样。它们每天都会在同一个地方，同一个时间进行。一般我们都是开站立会议，以防止持续时间超过15分”
– 我也喜欢站着开会，可以活动一下身体。当然，也能远离电脑。
“一定要做Sprint演示。让演示关注于业务层次，不要管技术细节。注意力放在“我们做了什么”，而不是“我们怎么做的”。不要花太多时间准备演示，尤其是不要做花里胡哨的演讲。把那些玩意儿扔一边去，集中精力演示可以实际工作的代码。”
“在有关回顾的种种一切中，最重要的就是确保回顾能够进行。由于某些原因，团队常常都不太愿意做回顾。如果不给他们点温柔的刺激，我们的大多数团队都会跳过回顾。说句实话，我认为回顾是Scrum中第二重要的事件（最重要的是sprint计划会议），因为这是你做改进的最佳时机！”
“Sprint之间的休整。我们会力求保证不在同一天举行sprint回顾和下一个sprint计划会议。”
“在绝大多数层面上组合使用XP与Scrum，我们都已经尝试过了。有些XP实践直接被Scrum解决掉了，可以被视作二者的重叠。如“整体团队”，“坐在一起”，“故事”和“计划游戏”。在这些情况下我们就直接使用了Scrum。
我们近来开始在一个团队中实施结对编程。效果相当好。虽然其他团队大多数还没有进行太多尝试，但在一个团队中使用了几个sprint之后，我已经有了很高的热情去指导其他团队进行试用。”
“测试驱动开发（TDD）阿门！对我来说，它比Scrum和XP还要重要。你可以拿走我的房子、我的电视还有我的狗，但不要试着让我停止使用TDD！”
–嗯，我还真没做过TDD
“学到的一课：如果你深陷手工回归测试的泥潭，打算让它自动化执行，最好还是放弃吧（除非做起来特别简单）。首先还是应该想办法简化手工回归测试。然后再考虑将真正的测试变成自动化执行。”
“我们在实施Scrum的时候，所做的第一件事情就是打乱特定于组件的团队（方式1），创建跨组件的团队（方式2）。它减少了诸如“我们没法完成这个条目，因为我们在等server那帮家伙完成他们的工作”之类的情况发生。不过，要是有很强烈的需求，我们也会临时创建针对特定组件展开工作的团队。”
– 嗯，我也喜欢让一个团队内部搞定尽可能多的事情。跨团队沟通就是麻烦
“每周的全体（嗯，所有参与开发的人）会议。时长15分钟。
什么？15分钟？全体参加？每一个产品所包括的全部团队中的所有人都会参加？这能行么？
是的，能行。只要你（或是其他主持会议的人）严格限定会议的时间不要过长。”
– 开大会，挺好的。信息要在团队中充分共享嘛。
最后总结一下在实施scrum的团队中的会议有哪些：
- Sprint计划会（4小时）
- Sprint日例会（15分钟）
- Sprint演示会（30分钟？）
- Sprint回顾会（1、2小时）
- 研发部周例会（大会）（15分钟）