敏捷的华为
June 21st, 2008
来自华为公司、负责软件质量和流程改进工作的周耀辉在第三届 敏捷中国 技术大会上介绍了 华为实践敏捷的经验
华为是偏重于流程为主的公司，多年之后市场环境不以公司为导向，在市场环境恶劣时候，华为公司发觉以流程为中心的环境很难应对这些要求，这是引入敏捷的原因。从2004年开始研究，在2007年步伐加快了，2007年下半年全面展开研究，今年年初开始全面进入试点阶段。
我曾经多次跟华为内外的朋友说到，华为的大问题有两点。第一是信息闭塞，公司内大部分员工不知道外面的世界（尤其是技术世界）在发生什么因此不知道很多已经被证明的最佳实践，公司外大部分人不知道华为里面是什么样子而导致华为被妖魔化。第二是基层员工极度缺乏决策权，大批只有执行力而没有微观决策权的员工使得持续改进难以成为整个组织的主旋律。
敏捷是改变这两个大问题的契机吗？看起来很像。一些好的现象已经开始出现。例如今天的演讲。一个华为的朋友说，在这种技术社区分享自己的经验，对于华为来说是第一次。
在保持执行力的基础上，给员工获取更多相关信息的渠道，使之具备足够的能力和空间进行微观决策，在全组织范围展开持续改进，并更加开放地与整个社区分享经验与收获。这样的一个华为，会是什么样子？
我说，它会是中国最好、最具吸引力的一家IT企业。
郭晓在CSDN视频谈精益软件开发
June 17th, 2008
郭晓拍片 也挺上镜的，虽说有些紧张。
“精益思想就好比是做一批桌子，与其上午做好所有的桌子腿，中午做好所有的桌面，晚上组装，做流水线最后组装，不如以最快的速度出一批完整的桌子交付用户先使用” ─ Thoughtworks中国区总经理郭晓谈精益敏捷开发思想论方法
为什么Ruby on Rails不一样
June 17th, 2008
一个客户正在考虑用 Ruby on Rails 做他们的项目，但是又有些顾虑。其中一个问题颇有意思。
>> 4、网上搜索到的“初期入门，Ruby更容易，但一旦达到一定复杂度，那么Ruby的难度骤然加大。Python入门不容易，复杂的时候也不会太痛苦。rails有入门简单，深入难的问题。rails生成的目录是做什么用途？o/r mapping如何实现的？如何把数据从web中传递到数据库的。这些都是Ruby程序员早晚要面对的问题。 Python则不会这样，如果搞不清楚这些，大概根本没办法开始。集成度太高的快速开发工具都有这个特点，无论是VB、Delphi，还是.net，有多少使用了半年以内的开发人员可以说清楚工程目录下面所有的文件的用途、每个文件中的语法？我相信很多很有经验的用户也未必说的清楚。”你们怎么看？
第一，每个称职的程序员都必须了解那些“窗帘背后”的东西。做不出东西，和做出东西却不知道是怎么做的，两者没有区别。从某个角度，我并不认为Rails“入门简单”，因为有很多魔法需要去了解。而且使用Rails的新手们需要更严格、更紧密的指导，他们需要和有经验的程序员结对，不然他们很容易迷失而找不到最好的（或者说，最符合惯例的）解决办法。Rails程序员的高产是以初期的严格训练换来的，经过了这样的训练之后他们对项目有清晰的了解并且对代码有审美能力，所以我看不出有什么理由会“难度骤然加大”。
第二，Rails和“VB、Delphi和.NET”的最大区别在于Rails不做代码生成。代码生成是邪恶的，如果你需要维护自动生成的代码的话。而Rails不做代码生成的一个重要原因是Ruby的表达力，它能够在运行时变那些“传统语言”用代码生成才能变的一些魔术。有多少人能弄清楚一个Rails项目里所有的犄角旮旯呢？很多人都可以。因为这里没有自动生成的难懂的代码，并且每件事情都有约定俗成的惯例。不仅是自己的项目，就算别人的项目也很容易弄懂的，大家都用同样的惯例做这些事。
另一个 有趣的blog 这样说Ruby on Rails的缺点：
1.Ruby由日本人创造的，尽管ROR是丹麦的小伙子David开发的
如果我没理解错的话，这话的意思大概就是“Ruby on Rails没有缺点”。当然我并不这么认为，不过我确实认为它是目前看来最舒服的一个工具。
两个tricks
June 16th, 2008
今天遇到两个tricky的东西，记下来。
1. 把十六进制数写到字符串里。
[0xEF, 0xBB, 0xBF].pack("C*")
（这个是 UTF8的BOM ，写在文本文件比如CSV的头上就可以让读取的软件比如Excel知道这是UTF8编码的文件。）
2. IE窗口的滚动条如果鼠标点下去也会触发 document.onclick 事件，而Firefox就不会。
（不明白为什么滚动条也可以算作document的一部分。）
基于Rails的SNS的比较
June 13th, 2008
+----------------------+-------+-------+---------+---------+-----+-------+ | Name | Lines | LOC | Classes | Methods | M/C | LOC/M | +----------------------+-------+-------+---------+---------+-----+-------+ | Controllers | 2714 | 2448 | 34 | 228 | 6 | 8 | | Helpers | 246 | 218 | 2 | 20 | 10 | 8 | | Models | 3802 | 2653 | 55 | 284 | 5 | 7 | | Libraries | 770 | 644 | 16 | 51 | 3 | 10 | | Integration tests | 467 | 377 | 11 | 38 | 3 | 7 | | Functional tests | 442 | 321 | 50 | 71 | 1 | 2 | | Unit tests | 760 | 599 | 37 | 64 | 1 | 7 | +----------------------+-------+-------+---------+---------+-----+-------+ | Total | 9201 | 7260 | 205 | 756 | 3 | 7 | +----------------------+-------+-------+---------+---------+-----+-------+ Code LOC: 5963 Test LOC: 1297 Code to Test Ratio: 1:0.2
+----------------------+-------+-------+---------+---------+-----+-------+ | Name | Lines | LOC | Classes | Methods | M/C | LOC/M | +----------------------+-------+-------+---------+---------+-----+-------+ | Controllers | 811 | 617 | 13 | 69 | 5 | 6 | | Helpers | 278 | 224 | 0 | 27 | 0 | 6 | | Models | 640 | 351 | 10 | 49 | 4 | 5 | | Libraries | 154 | 108 | 2 | 14 | 7 | 5 | | Integration tests | 50 | 36 | 1 | 3 | 3 | 10 | | Functional tests | 1162 | 948 | 11 | 27 | 2 | 33 | | Unit tests | 609 | 402 | 12 | 20 | 1 | 18 | +----------------------+-------+-------+---------+---------+-----+-------+ | Total | 3704 | 2686 | 49 | 209 | 4 | 10 | +----------------------+-------+-------+---------+---------+-----+-------+ Code LOC: 1300 Test LOC: 1386 Code to Test Ratio: 1:1.1
什么是项目经理
June 8th, 2008
InfoQ：应对敏捷项目中的干扰
讨论组的人都认为：要去除与这些主要的干扰相关的风险，应该从两方面下手：牺牲一个人，让他来处理所有的次要任务；还要注意不要让一个人同时参加多个任务。
其实嘛，这个人就是项目经理。如若不然，有BA跟客户沟通，有developer编程，有tester测试，还要项目经理来干嘛的呢？
不过说句老实话，平常见的这些个项目经理，能老老实实坐着不添乱已属不易，更遑论帮程序员过滤干扰咯。
（不由得想起4年前在杭州做项目经理，每每下午溜出去晒太阳和看书的那些日子。）
以前说过一个话：我是一个好的pair，我让黄亮发挥出最大效率，所以我对 Selenium 也是很有贡献的。为什么黄亮和我pair能发挥最大效率呢？因为我坐在一边不给他添乱。
每个人听了这个话都觉得好笑。我觉得并非很多人意识到一个道理。
不添乱就很好，如果你不知道该怎么帮忙的话。
无为而胜
June 4th, 2008
Dreamhead觉得 等待发布 是件很爽的事。当然确实是很爽的事。不过，《 最后期限 》里面贝琳达这样描述电影里的巴顿将军：
“片子开始的那一幕，巴顿‘指挥’战役的那一幕，我们那位年轻的朋友所说的那一幕：呵呵，巴顿在那一幕里根本连一条命令都没下过。他只是从望远镜里看着整个战役。德军坦克分队像他预料的那样穿过山谷，而他就看着那些坦克。在那儿，在第一辆坦克上，站着一位军官，手里拿着马鞭。巴顿盯着他，说道：‘隆美尔，我读过你的书。’他读过隆美尔的书，所以他很清楚隆美尔会怎么做。然后，战斗打响了。进攻，侧翼机动，佯装撤退，再次进攻，空中支援，后备队到达。巴顿只是看着，根本没有下达哪怕一条命令。”
如果一件事会成功，在最后一天之前它已注定会成功；如果它会失败，最后一天之前它已注定失败。所以我对这个“最后一天”没什么感觉。做一些和往常一样简单的事，让一些注定发生的事情发生而已。平常的一天而已。
重温在 贝琳达的评论 之前，一个颇有些代表性的项目经理是如何在记忆中构造巴顿将军的：
“我想，我就像巴顿。我是说，项目经理就像是巴顿。必须这样。就像在电影的第一个战争场景，直接打击隆美尔那样。他就是策划整个战役的那个人，他指挥每一次炮击。”这个年轻人站了起来，在虚拟的战场上挥舞着手臂：“空中支援！他这样说，然后空中支援就来了。收到—收到—收到！轰隆！转向侧翼！这儿！那儿！左侧编队，进攻！进攻！现在撤下来，赶紧撤下来！快！现在等着，等着，等我的命令……就是现在！进攻，进攻，把所有的炮弹都扔给他们！右翼，切断他们的后续部队！是的，就是那儿，就是那儿。现在我要更多的轰炸机，把炸弹丢在中间。好了，现在该决个胜负了，后备队，上。后备队从左侧进攻，快。是的，就是那儿，就是那儿，敌人绝对不会想到。嘣！轰隆！把他们全干掉！耶！！”
5年前也许我也这样想。人们需要像贝琳达那样把自己累垮，然后学会用简单的方式获胜。
