历史，蓝天，碧水
August 24th, 2008
大船瓦沙
August 14th, 2008
（From The Productive Programmer ）
1625年，瑞典国王古斯塔夫二世·阿道夫打算建造有史以来最棒的战舰。他雇了最好的造船工匠，专门种植了一片最刚硬的橡树林，都为了建造大船瓦沙。国王不断提出各种要求，希望把船建得更宏伟壮丽，到处都加上华美的装饰。有那么一天，他甚至决定在船上配备两套甲板炮，这是当时世界上绝无仅有的。他的船会是海上的霸王。而且由于迫在眉睫的外交问题，他还希望大船瓦沙能尽快造好。当然了，工匠们一开始的设计只有一套甲板炮，不过既然国王提出了要求，自然就得再加一套。由于太赶时间，工匠们来不及做“摇晃测试”──让一群水手从船的一边快跑到另一边，船在这种情况下不应该摇晃得太厉害（换句话说，没有头重脚轻）。结果，它的处女航只有几个小时，然后就沉入了海底：在给它加上所有华丽“特性”的同时，国王和工匠也让这条船变得根本无法航行。大船瓦沙在北海的海底长眠了几百年，直到20世纪初才被打捞出来，陈列在博物馆里。
一个有趣的问题：到底是谁导致了瓦沙的沉没？是国王，因为他要求了太多的特性？还是工匠，因为他们只顾着满足国王的要求，没有大声说出自己的担忧？看看你正身处其中的项目吧：你是不是正在建造又一艘瓦沙？
只做当下需要的。一开始这会很难，但最终你会得到一个更好的代码库。如果不引入不必要的复杂度，在修改或是重构时就不用对抗这些复杂度。程序员应该谨记：熵会杀死软件，所以，如无必要，勿增特性。
Tips from an Old Test Manager
August 7th, 2008
(From The Build Master )
For most of my career, I’ve been a test manager. I’ve come to realize that the job of a test manager is really quite simple and consists of three activities:
- Say “no” to development at least once a day.
- On a regular basis, complain that the project is off track, the schedule is ludicrous, and the quality is terrible only to be told to “lighten up” by the program manager.
- Find the killer metric to measure the product.
What I’ve learned that I’d like to pass along (the condensed version):
- If [people] really want you to do something, they’ll ask at least twice. The first time they ask is just to see if what they’re asking for sounds good to them. If you do what they ask when they’ve only asked once, you’re not playing the game right.
- The bug resolution fixed is more a wish than a statement of fact.
- You can still be friends with your developer even after threatening him/ her with a baseball bat.
- A schedule is not a sausage casing designed to be stuffed to the breaking point.
- 95 percent of reorgs have no impact on the people actually doing the work. The other 5 percent of reorgs mean you’ll be looking for a new job. The trick is to know which one is about to happen.
- It’s fun to have one’s mistakes made into a Dilbert cartoon.
- If no one else knows how to do what you do, leaving your group is going to be tough.
- A spec is like a fairy tale. Only the naïve and childlike believe it.
- The first time a question is asked, it’s fine to say, “I don’t know.” When the same question is asked again a week later, you’d better have an answer.
- Metrics are dangerous. No matter how carefully you caveat them in the original mail, they are interpreted to mean something completely different.
拿起这本靠谱的书，上路吧
August 7th, 2008
Rails的创造者David Heinemeier Hansson这样说：“我从来不会为了学一种语言而学一种语言。我学习新的编程语言一定是要用它来做点什么事。”同样的道理，很少有人只是为了学习漂亮的设计而开始接触Rails，大部分人──就像我一样──是抱着一个功利的念头开始自己的铁道之旅的。“我要做一个网站，听说有个叫Ruby on Rails的东西做网站又快又好，我得看看这是个什么玩意。”──大抵是这样的念头。
所以，Rails的学习者们真正要的不是深入理解Rails，而是又快又好地做出自己设想中的网站。
这年头的网站创业者们想要的不是“Ruby on Rails做的网站”，而是一个具有各种2.0特质的、很酷的网站。“什么mashup啦、widget啦、AJAX啦、REST啦，能用的全给它用上。你要是URL里还带一问号啊，你都不好意思跟人打招呼。每个页面放一地图，甭管有事没事都往地图上标记，倍儿有面子。这网站就够牛了吧？那是基本要求，还得在多种环境部署，高性能的服务器环境一个脚本就得部署好。你想啊，那些做一个功能都只花15分钟的程序员，根本没心思用俩小时做一次部署。所以我们的要求是：不但要酷，还要敏捷。”程序员们面临的大概就是这样的挑战。
诚然，作为入门手册的《Web开发敏捷之道》（Agile Web Development with Rails）在实用性方面做得已经不错了，一位初学者可以跟着那本书做出一个像模像样的玩具网站，同时对Rails的方方面面有个大致的认识。不过当他们尝试动手做自己真正想要的那个网站时，就会突然发现面前赫然立着两只拦路虎：第一，真正的网站不是玩具，有太多真实世界里的常见问题他们不知该如何解决；第二，Rails一向秉承“做一件事并且做好”的Unix设计传统，这也就意味着要做一些真实有用的功能往往需要很多Rails之外的相关知识。这可真是件令人沮丧的事情：花了好几天工夫来学习Rails，自以为已经习得一身好武艺，一出山门却发现面前摆着那么多难题不会解决，甚至想翻书都不知该从何翻起。
简而言之，他们没有套路。
这本《Web开发大全（RoR版）》就是帮这些踌躇满志的网站初哥们解决套路问题的。这几位实战经验丰富的作者各出高招，简单介绍Rails之后，立即把用户管理、内容展示、文件上传、搜索、RSS等等网站“家常菜”给抽丝剥茧地细细解说一遍，再把各种常见的mashup逐一介绍，尤其是为地图服务这个重要的2.0元素单辟章节（值得一提的是，撰写这一章的高昂乃是中科院地理所的博士，从他的专业角度来介绍互联网上的地图服务，可谓高屋建瓴鞭辟入里，不可不读）。讲完开发的内容，部署工作也没有被忽视，第十章“部署演练”介绍了各种曾经或正在或即将流行的Rails应用部署方案，特别是关于JRuby on Rails的介绍引人注目：这是将Ruby on Rails和J2EE两个世界结合起来的纽带，ThoughtWorks的第一个商业产品Mingle就采用了这种部署方式。
这是一本有套路的书。看完这书的读者应该能学到网站开发的套路。
最后我还得夸赞一下这几位作者。从中国有Ruby on Rails社区开始，这几位就个顶个的是社区里的积极分子。他们为Rails在中国的发展起了重要的推动作用。有骆古道这样远赴重洋心系祖国的爱国程序员，有王大力这样组织和掺合全国各地各种技术活动的热心大叔，有董斌、苏锐这样长年在互联网一线奋战的技术中坚，有黄翀、高昂这样醉心技术深度广度俱佳的有为青年，这么一群靠谱的人和博文视点这么一家靠谱的出版商一起创作的作品，理当是一本靠谱的书。
所以，怀揣梦想的Rails爱好者们，拿起这本靠谱的书，上路吧。
昨天的AJAX就是今天的并发编程
August 5th, 2008
（From The Productive Programmer ）
顶多就在五年前，我们炮制的那些丑陋得简直就像把命令行窗口直接塞进浏览器的web应用还能让用户满意。可是Google那些讨厌的程序员毁了这一切：他们发布了Google Maps和Gmail，更要紧的是他们让用户明白web应用不一定要那么糟烂的，于是我们只好跟着开发更好的web应用。现在并发编程的情况也是一样：我们这些程序员现在还可以幸福地对严重的线程问题视而不见，但一定会有人站出来，让人们看到某种新发明的威力，然后我们又得亦步亦趋地跟上去。我们的计算机有强大的运算能力，而我们却没有能力写出那样的代码来充分利用它们，这对矛盾正在日益凸显。
做简单重复的事是在浪费注意力
August 3rd, 2008
（From The Productive Programmer ）
计算机之所以存在就是为了执行简单重复的任务的，你应该让它们去工作！找出那些每天、每周都在做的重复工作，问问你自己：我能把这件事自动化吗？把重复的工作自动化，就能给你更多的时间来做有用的事，而不是一遍又一遍地解决没有营养的问题。亲手做那些简单重复的事会浪费你的注意力，将这些烦人的杂事自动化，你就可以把宝贵的精力用来做其他更有价值的事。
You Break It, You Fix It
August 2nd, 2008
(From The Build Master )
This leads to one of the most important rules in the build lab: The build team never fixes build breaks, regardless of how trivial the break is. That’s the developer’s responsibility. We took this a step further: The developer who breaks the build has to go to his development machine, check out the file, fix it, and then go through all the check-in process steps again.
Build Breaks Always Have the Highest Priority for Everyone
This rule means that if you are a developer and you can fix the build break, and the developer who broke the build cannot be found, you should fix it immediately. Afterward, send an e-mail to the developer and the build team explaining what you did to fix the build, and remind your co-worker that he owes you a favor.
装象你好歹也插根葱
August 2nd, 2008
这个数学公式所表达的意思就是Google的总价值等于它抓取的网页蕴含的总价值减去它的运营成本，VG可以看作Google占有的互联网信息剩余价值。
张五常看见这玩意能被气死。佛里曼半辈子讲交易成本，这帮伪经济学家们还是无视之。价值是会因为交易成本而消散的呀，同志。
葱都懒得插一根，翘着个猪拱嘴就愣充象，这玩意他不光是能力问题，他还是个态度问题。
