路宁(luning)的博客

Install Io language on Ubuntu 11.10 (Oneiric Ocelot)

Sat, 22 Oct 2011 22:11:00 +0800

Following the offical instruction to install Io language on Ubuntu 11.10 is confirmed to be problematic. I spent several hours to get Io installed successfully on my Ubuntu 11.10. Below shows how I get it all through.

I basically followed the off...

收藏到：Del.icio.us

流行管理体系的8个基本要素 - 彼得.圣吉

Thu, 17 Feb 2011 13:42:00 +0800

1. 依赖测量考评的管理

关注短期业绩考核指标
无形指标被忽视（真正重要的东西你只能测量到3% - 爱德华.戴明）

2. 以服从为基调的文化

靠取悦老板来出人头地
靠恐惧气氛管理

3. 围绕结果的管理

管理层制定目标
人们被迫承担完成管理层目标的责任

4. “正确答案”对比“错误答案”

重视解决技术问题
忽视发散性的系统问题

5. 同质化

多样性被视为问题，需要解决掉
用肤浅的协议来抑制冲突

6. 可预测性和可操作性

管理就是控制
“管理的神圣三角”是计划、组织和控制

7. 过度竞争与互不信任

人与人的竞争是实现所要求业绩的必要条件
没有人们的相互竞争就没有创新（我们已经被竞争出卖了。-爱德华.戴明）

8. 整体的缺失

基于被肢解后的目标和团队进行管理，碎片化
局部的创新不能得到广泛传播

收藏到：Del.icio.us

我的2010

Wed, 09 Feb 2011 15:04:00 +0800

年后第一天上班，大部分人都还没到，没一点工作气氛，突然想记录一下自己过去的一年。

离开ThoughtWorks到智联招聘

3月初我离开了记载着我无数欢乐与热情的ThoughtWorks，离开了这个让我脱胎换骨的公司，来到了智联招聘。促使我最终下定决心的是和智联招聘赵总的一次沟通，他没有技术背景，却有很棒的技术管理直觉，他对公司变革的的决心和具体想法深深感染了我，我为能参与这场变革而感觉兴奋不已。

在智联奋战5个月最终遭遇高层地震

在随后的几个月中，我和引见我认识赵总的平川大哥并肩作战，为公司技术体系的各个部门带来了很多积极的变化，其中有很多故事，进展比预想的也要顺利些。这一切都是在公司业务和技术体系变革的大背景下进行的，变革的过程有个特点，就是“人事变动先行 ”，这如催化剂般加速了变革，但也埋下了更为深层的矛盾。7月末的一个周五，矛盾以最为激烈的形式爆发出来，最终，赵总及其他几位O和副总裁被董事会开除，第二周，我也被开除了。

这是一段难得的经历。我体会到：在资本面前，CEO也不好使 。

找工作

终于失业了......，听马波说他在失业的几个月中，把历史、哲学、经济和心理学等书看了个遍，十分羡慕。本想可以如法泡制享受一阵子的，可是老婆比我急多了，每天监督找工作的进展，搞的我只能从命。联系一遍身边的猎头和朋友，发发简历，其实也就没什么可做的了。最后在百度和一家咨询公司间选择，我的状态实在不适合长期出差，百度的平台足够大，就确定百度了。

在百度

9月8号到了百度，开始了新工作。我的工作就是要带来变化，这比较依赖于平台和环境。百度的平台足够大，干久了也不会乏味。在开发方式和项目管理方法上还没有定型，没有像IBM或微软一样撼动不了的“文化”，没有框框架架，这点很难得。大家都很年轻、聪明、乐于尝试，加上有飞哥和部门内姐妹兄弟的大力支持，在这里的工作很开心。

社区活动中的贡献

在Beijing Open Party上主持了题为《在持续运营的网站团队中实施敏捷》的讨论
在AgileDay上贡献了《软件开发中的精益管理思维》演讲
在Agile Tour北京站上贡献了《你需要改变的10个思维习惯》演讲
在Agile Tour青岛站上贡献了《10 Advices Lean Brings to Agile》演讲

读了那些书

《Crucial Confrontations: Tools for Resolving broken promises, violated expectations, and bad behavior》
《Behind Closed Doors: Secrets of Great Management》
《第五项修炼》(重读了一遍新版的)
《麦肯锡方法》
《高效程序员的45个习惯》
《构建高性能Web站点》
《Manage to Learn》
《思维导图》
《How to Be a GREAT Coach - 24 Lessons for Turning on the Productivity of Every Employee》
《Learning to See》
《Manage It!: Your Guide to Modern, Pragmatic Project Management》

买车：英朗GT 1.6T时尚运动版

从有想法到车到手只用了1个星期时间，想想都后怕。12月初的一个周末，一个高中同学开车到我家玩，我也试着开了2公里，觉得挺容易，于是就有了买车的想法，再加上治堵新政要出台，就更着急买了。每天晚上看论坛，第二个周末就出手了。

收藏到：Del.icio.us

一个QA口述的故事

Mon, 31 Jan 2011 13:11:00 +0800

有一个新入职的Dev，每次开发完一个功能后就叫上QA到自己的机器上来测试，并不像大多数Dev一样发起正式的提测流程。

他这么做一方面是因为担心自己开发的质量差，正式提测后的Bug被记录下来，影响他的KPI表现。另一方面是正式提测如果有问题还要打回来，来回走流程费劲。

QA起初积极配合，但后来发现这么做对自己很不利，无法在领导那里体现自己的工作。因为QA是根据Dev的提测计划制定自己的测试计划，QA经理主要根据测试计划及执行情况来了解手下人的工作。不仅如此，这样做还会影响自己的一项KPI：漏测率。漏测率是指上线后发现的Bug数除以总Bug数，如果记录的Bug基数少了，漏测率极易上升。

QA反应过来这个问题后就不再配合了。Dev嫌QA变默唧了，QA 反过来嫌Dev懒，让他正式提测。两边合作不愉快，就开始找“流程”帮忙，沟通少了，一切走邮件，走流程。

Dev 感觉QA 让他名下的Bug多了，搞得自己在Dev经理面前很没面子，和QA说话时自然没什么好语气。QA 心里也不顺，本来没多大的事，搞得默默唧唧的。

最终的解决办法是，走流程，你在系统里提测，我才测试，有问题记录Bug，依赖Bug跟踪系统......

哈哈，有意思吧。你能说这个Dev或QA不够好吗？不是。

不管出于什么动机，他们确实发现了一个更高效的合作方式，但却被“流行的组织结构”，“僵化的KPI”，和“万能的流程”无情地打击了......

收藏到：Del.icio.us

一次有趣的周例会

Wed, 03 Nov 2010 11:33:00 +0800

同事参加了一个项目组周例会，回来把经过讲给大家听，我感觉很有意思，于是强迫她写了下来，以便日后回味。

背景：
公司重点新产品，正在开发第一个版本。RD(开发)、QA和PM(产品经理，做需求分析)各自是一个团队，有自己的头，PM是项目总负责人。项目的沟通计划大致为：
* 各角色负责人每周一在一起开一次例会
* 各角色负责人每天会有一次站立会议，各角色负责人反馈各自的进度，并将会议精神传达个项目成员。

周一例会就要开始了
PM在即时聊天工具上催大家赶紧来开会，虽然会议定在了5点开始，但等大部分人来齐了以后，时间
已经指向5点20，这时PM宣布会议开始。

PM ：开发负责人请说一下上周开发的进度。

RD ：好的，麻烦你打开一下我的周报。（看着投影上的周报开始念）上周完成了菜单的编码，XX代码的移植，确认XX开发方案$%$#^%^$%^$%^（整整说了10个任务），下周计划做：XXX逻辑处理，XXX详细设计文档￥%￥#%￥#%，分别是由XX负责，...（又说了5个任务）。

PM ：（听完很晕...）那开发觉得有什么风险吗？

RD ：嗯，有啊，任务延期了。

PM ：延了多少？

RD ：呃，还不好说。

PM ：（不知该说什么...）那好吧。（转向测试负责人）QA那边说一下测试的进度吧。

QA ：这周RD提测了一个版本，有不少质量问题，希望RD尽快解决，否则我们无法继续测试。另外我们完成了XXX任务，%……￥%……%￥……%￥。下周计划#￥#@￥#@￥，另外我还有一个重要事情，得先走一步，你们慢慢开。

QA负责人离开了会议室，PM接着汇报了需求进度，同样是任务汇总型的汇报。期间突然有人提到按照这样的计划12月底发布风险很大。

PM老大 ：谁说是12月底发布啊，我们跟老板汇报的是11月底，这个时间点不能变。

PM ：（急了）不是啊，我们上次讨论是12月底啊，我们项目组都是以这个目标在开展的。

PM老大 ：我从来没说过是12月底。

PM ：我发邮件提到过12月底的计划啊，邮件里说得很清楚，你没看到吗？

PM老大 ：没看到，什么时候发的？不管怎么样，11月底的目标是不能变的，否则会对明年的整个规划有很大的影响。

PM ：那怎么办，我现在把RD的老大叫过来吧，看看他怎么说？

PM通过即时聊天工具把RD老大叫过来了。

PM ：（看着RD老大）我们的计划现在变了，要提前，你们能给我多少人？明年的版本你能保证完成吗？

RD老大 ：这个计划我已经说了，12月底都是我们强压的计划了，大家已经在加班了，不能再压缩了，你问问测试那边可以压缩不。明年的规划你们都没出来，要做什么我都不知道，我怎么能说我是否能完成？

PM ：那我尽快把明年的规划给你，你考虑RD人手的问题。

PM老大 ：那尽快评估11月底的目标可以达成不？

RD老大 ：什么时候变成11月底了啊，我不知道啊？

（时间已经指向晚上7点，PK还在继续。。。。。）

收藏到：Del.icio.us

你是改革派吗？

Fri, 17 Sep 2010 22:26:11 +0800

越来越觉得，改革或改进是一种性格和习惯，很大程度上是跟着人走的，与工作性质无关。

看看下面那些话恰当地描述了你，进而认识一下自己骨子里是不是个改革派。

面对新的选择，依赖经验，判断是否可行。
对维持现状有一种内在的忧虑，对工作中的障碍耿耿于怀。
想着未来的机遇，并受机遇的鼓动。
对资料求之若渴，动手前要确保有实事和数据证明其可行性。
习惯于被时间检验的，现有的机制和做事方法。
常常有些灵感，如磁石般抓住了我，让我骚动不安。
只要理论上可行，就想试试看会有什么结果。

上面2、3、6和7是对改革派的描述，1、4和5就不是那么改革派了，如果只选择1、4、5就可能属于保守派了。

描述保守者的关键词：过去，经验，时间检验，传统，事实，能感觉到的，没有废话，实际上，事实上

描述改革者的关键词：未来，创新，思考，富有想像力，障碍，可能性，灵活性，灵感，本能，理论上的

收藏到：Del.icio.us

如何成为一名优秀的教练

Tue, 14 Sep 2010 13:07:51 +0800

刚看过一本老书《How to Be a GREAT Coach - 24 Lessons for Turning on the Productivity of Every Employee》，把其中的观点亮出来学习学习。

教练是对管理者的另一种提法，有效的管理者通过辅导员工实现自身价值来达成管理目标。

与其	不如
做一个老板	做一个教练老板说，教练听；老板解决问题，教练防止问题发生；老板发号施令，教练给与员工挑战；老板说服员工，教练和他们一起工作；老板指责，教练担当。
要求员工	赋予他们动机需要成就，追求知识，渴望贡献
自己做决定	问问他们的意见听他们说。认真对待他们的想法。如果决定影响他们，提前和他们确认。员工的想法是你的资源。
达到完美	承认你的失误承认，修正，从中学习。
保护你的隐私	开放自己欢迎员工的打扰，别离他们太远。倾听，认真考虑，并鼓励每个人的想法。
发号施令	做一个称职的倾听者确定听懂了，用自己的话重复一遍，再给与反馈。如果认为员工说的不对，清晰地说出你的想法。
要知道所有答案	问个好问题 “我们是否要雇用一个自由编辑提高出版物质量？”就不如“为了编辑好出版物，我们应做些什么？”好。问题要简洁、有重点，最好是开放性的，没有答案陷阱。
隐藏矛盾	欢迎抱怨用真诚的感谢回应批评，注意你的肢体语言。探询并发现真正的问题。
办大型讲座	一对一辅导 Coach从不会发生在讲座中。最有效的辅导和激励是一对一，面对面，永远别抬高嗓门。
用华丽词汇	注意你的语言选择能建立联系而非增加壁垒的词汇。用已知的去解释未知的，避免陈词滥调，不冒犯别人。
教导别人遵守	庆祝不同意见你能鼓励、教育和引导员工，但不能真正控制他们。不要尝试控制，连念头都不该有。没出问题，就不要fix，出问题了，让他们fix，如果他们fix不了，和他们一起fix。
让自己变得不可或缺	授权一个个独立的员工 “我的人干什么事前都要问我”，这是你吗？如果是，说明你在做每个人的工作。雇用员工因其独立，而非服从。培养独立的环境 - 提供知识、信息，尤其是信任。授权并接受其结果。
保留自己的判断	及时做决定是时间做些决定了，只能有一个仲裁者，就是你。你不需要知道所有事情，不需要确定无疑，甚至不需要说服自己这是正确的。快速决定的失败率并不比犹豫不定的决定高。
自己提供所有答案	和员工一起解决问题聚焦到一个方案前收集尽量多的可能性。把点子和提出点子的人分开看待，讨论计划，而非人品。抵制让提出想法的人去执行的冲动，别忘了你是鼓励创新的。
别做那个坏人	私下传达难以被接受的消息提供原因。谈论行为，不质疑动机。提供建议。
别发疯	别带着气愤情绪做事平静下来。除非你可以来处理了，否则不要行动。作正确的事，不要随性而为。气愤，如果不加控制，比导致气愤的错误更具危害性。
把它写下来	避免备忘录狂热症与其打印文档分发，不如发个Email，张贴到Wiki上，或者干脆忘记这回事。确保要传达的消息值得大家花费宝贵时间，提供简洁的标题方便大家过滤。
消灭会议	管理会议必要的时候才开会。做好计划，提前传播议题和必要信息。说半个小时，就半个小时。
期望他们知道	培训他们他们还没有掌握，除非他们可以在没有你帮助时自己完成。
送他们进地狱	强调正面信息避免用“总是”，“从来没有”这类夸张词汇。无须使用委婉说法。向前看，强调期望的产出，避免陷入指责游戏。
钱说了算	奖励你期望的行为奖励要源于行为并进一步鼓励它，可以在学习的时间，工作满足感，独立性等方面想些点子。机制公平。确保所有人了解规则。
不要过度表扬	提供积极的反馈承认个体的贡献，提供具体的实例，还要真诚。
做个啦啦队长	做员工的拥护者为员工利益争取，宣传你的员工。不要和员工抢功，不要将指责转移到他们身上，让他们看起来体面些。
确保有个正确的开始	只要开始就好不要过度分析，先试一试，让想法流动起来。不要过度评估。别停下来。

收藏到：Del.icio.us

编写Story的一周，预示了项目的不祥未来

Sun, 13 Jun 2010 21:42:44 +0800

我最近Lead一个QuickStart，第三周编写Story，这一周就像是整个项目的缩影，它让我看到了项目的未来：屈服于压力，不尊重实际的速度，迷信业务的承诺，轻信自己的判断，后期加班，项目延期。

我和一个BA想用一周时间（本周有7个工作日）把Story都做出来，并制定交付计划。之所以是一周，是因为第二周要做汇报。开始比较乐观，认为Story可以很快产出。

周一：
只做了30个Story，比预期的少了近一半，但一想只花了半天做Story，以后应可以补回来。

周二：
做了28个，远少于预期，因为今天又有别的事，不能全力做Story，也许明天会好些。

周三：
做了34个，今天多了些，但感觉Story的总量会比预期多不少。我们反思了一下，业务（客户）的支持不足是最大问题。心想，如果业务一直在身边，写起Story肯定神速。于是争取了一下，业务承诺每天10点至少支持我们2小时。

周四：
业务如约来支持我们，但主要是Review做好的Story，没写新的。下午业务开会，还是我们自己写Story，今天完成40个。

周五：
业务没有来，因为他每天都工作到凌晨3点，虽然承诺10点到公司，但11点还在自家床上呢。看来只能加班适应他的时间了。今天做了33个。

周六：
我们11点多才到公司，就是准备晚上陪业务加班。加上加班的2个多小时，共写了42个，并没有预期的50～60个那么多，原因是“软柿子”都被我们捏过了，剩下的都是复杂的需求了。

周日：
一早我和老大分析了一下，决定推迟汇报的日期。业务那哥们今天大部分时间都在支持我们，但由于剩下的都是复杂的逻辑，今天只做了40多个。

一周回顾：
一开始根据汇报的时间点做了乐观的估计。3天后有了实际的“速度”，但迫于压力没有据此调整预期，因为还梦想着业务会支持我们并大大提高生产率。后来发现业务近两天不可能提供全面支持，于是决定加班。之后又发现即使业务支持了，速度也未必明显提高。最后决定延期交付。

哈哈，整个过程俨然就是将来项目的缩影，该犯的错误是一定要犯地！

收藏到：Del.icio.us

试用了一下Team Foundation Server中的版本管理功能

Tue, 27 Apr 2010 17:00:54 +0800

    今天在Visual Studio 2010内试用了一下Team Foundation Server中的版本管理功能，总的感觉是“痛苦”，其实真想找找它的优点，可能是时间花的不够，确实没找到。要声明一下，这个感觉完全取决于你以前用的是什么版本管理工具以及你有多依赖版本管理工具。

    我大部分的项目使用SVN或GIT，曾经有一个项目在客户那里用 ClearCase，大学涉世未深的时候也用过VSS。我在项目中是较强地依赖版本管理的，也就是说该用工具的时候就用工具，而不是通过“文件重命名”、 “目录拷贝”、“收发EMail”、“重复修改”、“共享目录”等手段来做版本管理。

    下面总结了我在试用过程中的Pain Point，用过SVN或GIT的人会更有体会。

* 断网了你就死定了

打开项目要连接服务器。比如断网时修改一个文件，check out动作需要连接服务器，IDE就挂在那里，直到我受不了了把网线插回去IDE才有反应。如果一直坚持下去，据说会出现警告框，提示文件将脱离版本控制之类的，没有机会验证。

* 悲观的Conflict策略

即使修改了文件不同位置，在get latest version后也提示Conflict。

* 乐观的提交一致性保护策略

Check In时如果Local Copy不在最新版本之上不会被阻止，而是在某一个文件有Conflict时要求在本地解决，再check in。也就是说会有服务器端的冲突检测，可惜此时服务器上便产生了一个和任何本地版本都不一样的版本，天晓得这个版本会不会工作，在一致性保护上实在是够乐观的。

* 服务器端Diff

即使是查看一下本地修改也要连接到服务器才能做到。

* 本地文件控制策略不透明，不开放，而且具有侵入性

不像SVN或GIT，所有秘密全在.svn或.git隐藏文件夹内。TFS可以确定的是solution和project文件夹中各有一个版本管理元文件，所有被管理的文件会被“侵入式”地变为只读（在IDE外被更改后会欺骗版本控制，类似ClearCase中的Hijack），再就是通过Source Control Explorer管理了workplace和local path的映射......。

如果把项目文件夹挪动位置或改名，别指望会成功打开，项目会因binding information找不到和workspace mapping错误而脱离版本控制。事实上，你要先创建一个workplace和新的Local path关联，然后TFS才允许你在新的地方签出同一个项目。

本地目录的完整路径是和Server上的目录对应的，这个关系不可以改，项目保存的位置不可以随便变。你创建Branch后也不能把本地目录直接Switch到Branch上，要重新get latest version。

不透明的文件控制策略会让针对版本管理的排错变得困难很多。

* TFS采用了check in/check out/lock的同步模式

它并不跟踪真实的修改，即使check out后什么都没改，文件还是修改状态，还需要check in。

* TFS与IDE的秘密约定导致在IDE之外进行版本管理相当繁琐

比如对目录和文件做版本管理，需要通过Source Control Explore进行繁琐的操作（与SVN或GIT在资源管理器中的操作相比真是......）

* 有些操作太复杂，蹩脚

比如查看本地的所有改动，只能一个一个文件地看，通过右键菜单，每次都要到服务器端做Diff。

再比如Revert Change操作，看看MVP给的步骤吧：https://msmvps.com/blogs/vstsblog/archive/2009/01/10/how-to-revert-changes-checked-into-tfs-version-control.aspx

再比如把一个文件从solution中移出，但想保留版本控制，TFS认为你要删除该文件，为你创建了一个delete的pending change，你需要undo这个change才行，或者执行这个删除，再到Source Control Explorer中把它加回来，别扭死了。

还有到处都是对话框，即使你每次都做同样的事情，还是需要多次点击和选择。

* TFS内部集成了任务跟踪，Project Portal，Planning，Reporting等功能

这对大型团队来说确实省了不少事，但对中小团队，唉，又被绑架了。它的敏捷项目管理模板给人官僚的感觉，刚起步的敏捷团队最好是从Story Wall开始。这种集成性降低了灵活性，剥夺了选择的权利，甚至让人懒得去看看外面的世界是什么样的。

* 安装、配置、维护繁琐

你需要几个G的空间安装相应组件。

* 只支持http和https

在网络条件不佳的环境中速度会有影响

总结

TFS为了照顾VSS的客户，同时眼睛还总盯着另一个官僚版本管理工具IBM的ClearCase，最后搞的它和ClearCase一样，功能不少，很强大，就是思路偏了，适合给大领导看，不适合给团队用。

本来点5次鼠标，打开关闭1个窗口就能做的事它要点30次鼠标，确认3个对话框，打开并关闭4个窗口才能做到，同时你还要不断提醒自己到了哪一步了。它压根就不理会程序员此时到底想干什么。

收藏到：Del.icio.us

Share DOM Fixtures between JavaScript Unit Tests

Mon, 21 Dec 2009 13:41:55 +0800

For the JavaScript unit tests that operate DOM, it's quite handy if the DOM fixtures could be shared between tests. This involves how to load another HTML file from one HTML file for most of the JavaScript testing frameworks (like Screw.Unit and JSUnit), the prior file is the DOM fixture and the later file hosts the test codes.

This blog demonstrates a way to do it through jQuery synchronized Ajax call. Below is the code skeleton of a test file:

<html>
  <head>
    <script type="text/javascript" src="lib/jquery-1.3.2.js"></script>
  </head>

  <body>
    <div id="fixture">
      <script type="text/javascript">
        $.ajaxSetup({ async: false }); // Ajax will run in sync
        $("#fixture").load("fixtures/DOMFixture.html"); // replace inner html with loaded content
      </script>
    </div>

    <script type="text/javascript">
      // tests go here
    </script>
  </body>
</html>

This works for all the mainstream browsers including Firefox and IE.

Another possible approach that I haven't verified in detail is that 1) create XML document element dynamically, 2) load fixture file to the element synchronously, then 3) append the element to the place holder DIV in test file.

收藏到：Del.icio.us