Windows 环境下用 Eclipse IDE，编辑器的默认字体是等宽的 Courier New。 在 Windows XP 和 Vista 下面，这个字体并不好看，可能是不支持 Clear Type 的缘故。 所以通常我会把默认字体换成 Monaco。 Monaco 是 Mac OS X 环境的字体，被转换成 ttf 以后可以在 Windows 下面用。 但是效果还是不如 Mac OS X 里面。

Mac OS X 下面，Monaco 的效果：

Windows 下，使用 Monaco 的 Eclipse IDE（10号字体，点击看大图）:

最近，发现了 Windows 下的另一字体，Consolas，这可能是安装了 Office 2007 以后带来的新字体（Update：Vista 自带了 Consolas）。 使用了 Consolas 的 Eclipse IDE （11号字体）:

Consolas 字体在 Windows 环境下处理 anti-alias 更好一下，而且在斜体和括号的处理上，看上去比 Monaco 要清晰。 作为编程使用的字体，等宽的 Consolas 至少比 Courier New 要好太多了。

如果没有安装 Office 2007 而得不到 Consolas 字体的话，可以看看这个字体: Inconsolas。

Popularity: 26% [?]

1. 【摘自《译言》】
2. 1. 任何一个程序一旦发布就意味着它已经过时了。 【所以永远需要升级版本】
3. 2. 让需求根据程序调整往往要比让程序根据需求调整来得容易。
4. 3. 如果一个程序是有用的，那它必将被改变。
5. 4. 如果一个程序是无用的，那它必须被注释。
6. 5. 在任何一个程序里只有10%的代码会被执行。 【那为什么还有其他90%代码？ 因为这90%是为这10%服务的】
7. 6. 软件会无限扩张以占用所有的系统资源。 【看看Windows就知道了】
8. 7. 任何有价值的程序都会包含至少一个错误。 【存在bug-free的程序吗？不存在】
9. 8. 一个演示版的程序完美无瑕的几率和关注它的人数成反比，最终要花费的金钱的数量是原数量的平方。 【不做不错，越做越错，承接第7条】
10. 9. 一个程序的致命错误要到其发布至少半年后才会被发现。 【千年虫问题跨越了千年】
11. 10. 不可检测的错误是无穷无尽的，并以各种形式存在；相反，可检测的错误从理论上讲是有限的。 【因为看不到，所以不知道有多少。但是，不要让我太轻易就找到bug。】
12. 11. 随着时间的推移，修正某个错误所需花费的精力会成指数级增加。 【所以不如重写】
13. 12. 程序的复杂度会一直增长，直到超出维护它的程序员的能力为止。
14. 13. 一段你自己写的代码如果几个月不曾看过，重读的时候还不如当作是别人写的代码去理解。
15. 14. 在每个小程序里都会有一大段代码想要破壳而出。
16. 15. 你越快开始编写代码，就会需要越长的时间。 【所以要TDD，但是TDD写的太快，TDD自己也会出错】
17. 16. 一个项目如果没有精心策划，那将需要比预期多出两倍的时间来完成它；相反的，如果项目是精心策划过的，就只需要多出一倍的时间。 【如果想按时完成，只有一个办法，把项目停掉】
18. 17. 向一个落后于进度的项目添加程序员只会让项目更加落后于进度。 【man/month早过时了】
19. 18. 一个程序的完成程度总在90%到95%之间。 【因为第7条】
20. 19. 如果你让一团糟糕的代码自动化，那你就会得到一团自动化的糟糕的代码。
21. 20. 建立一个连傻瓜都会使用的程序，而只有一个傻瓜才想要去使用它。
22. 21. 用户直到他们使用了一个程序之后才知道他们究竟想要的是什么。 【太正确了，所以需求调研等同于鸡同鸭讲】

Popularity: 16% [?]

1. 架构师对于PowerPoint的熟练程度要远远胜过流行的Java IDE。
2. 光是部署基本环境（比如应用程序服务器和数据库）就需要若干张ＤＶＤ和几个小时。
3. 一些流行的服务器需要几分钟去启动和部署，而你每天要重复这一过程若干次。
4. 为应用服务器的bug立案（并且重现问题的所在）往往比你自己修复它需要的时间更长（当然，如果你有源代码的话） 。
5. 很难为开发者们找到一个可以高效运行那些“企业级”开发工具的硬件，而且因为这些开发工具十分昂贵，想要弃他们不用也很困难。
6. 架构师热爱分层，光是从持久层传递一个持久实体到表现层，就需要若干次mapping。
7. 一切都是可配置、可替换、可建模的。ＸＭＬ的负担十分巨大。问题是：上一次你真正的需要在工程中替换某些东西是什么时候？
8. 无论是瀑布式还是敏捷式都充满各种专业术语和奇怪的规范。两者都可以非常的低效。看上去只做最基本的有时真的很难。
9. 开发者有的时候非常极端：不是用成千上万的模式和最佳实践把所有东西都过度设计，就是直接了当的使用“意大利面条”式的开发风格。
10. “快感已经不再”很多开发者、构架师和经理们已经失去了他们的狂热和激情。这也是为什么许多工程如此低效的原因之一。
11. 即使像留言板这样的程序，也要考虑高可用性，不掉线、集群。复杂性统治一切。
12. 奇怪的质量保证规则（比如文档化很明显的getters／setters方法）加大开发和维护成本。
13. 构架师和开发者热爱框架。即使对于最简单的增删查改类的程序，也要用到internet://**/*.jar，而不是Java SE或者应用程序服务器提供的API。

【英文原文】

如果真的出现这种情况，那就太可怕了：

一定要找那最流行的框架，
用功能最强大编辑器，
做就要做最复杂的系统，
轻量级的绝对不行，
框架最简单也得是ＳＰＲＩＮＧ，
什么ＥＪＢ啊，ＨＩＢＥＲＮＡＴＥ啊，ＳＥＡＭ啊，能用的全都得用上，
表现层要可配置、持久层要可替换，
程序最好能用一万年，
客户一见面，甭管有事没事，
都得问人家：您准备换框架不？
系统还得能够集群
访问量再小也得同时开１０几台服务器
一天２４小时在线
火星撞地球了都能提供服务
服务器上跑得都是weblogic、websphere
你要用一jboss，都不好意思跟人家打招呼
你说这系统，得做多长时间？
（怎么地也得５年吧？）
５年？那是一期工程，
１０年起，
你得揣摩老板的心理，
愿意花５年开发一套系统的老板，
根本就不在乎再多等５年，
什么是软件工程你知道么？
软件工程就是，搞什么都不用最好的，用最复杂的
所以我们口号就是：
不求最好，但求最复杂。

Popularity: 22% [?]

受 Eclipse Search 的启发，利用 Google Coop 做了一个 Groovy/Grails 的自定义搜索，除了搜索整个 web 以外，还着重于一些介绍 Groovy/Grails 的 blogs，当然，groovy.codehaus.org 和 grails.codehaus.org 是一定不会缺的。 同时，利用 Google Coop 的调优功能，设置了 blogs 和 documents 这两个 label，对添加的站点做了一定的分类，这样除了普通的查询，也可以缩小查询范围，只搜索 blogs 或者 documents。

有了这个自定义的 Groovy/Grails 搜索，参考 OpenSearch，我也定义了一个 opensearch.xml，所以如果你访问这个搜索网页，就可以把它添加到 Firefox 3 的搜索工具条中（也支持 Internet Explorer 7）。

对于整个页面的设计，还会继续调整和美化；而对于所搜索的站点，现在还不是很多，一个原因是现在专注于 Groovy/Grails 的比较少，也可能是我所知道的比较少。 我会逐渐的添加更多关注 Groovy/Grails 的站点，也许会把 Google Coop 中的这个自定搜索设置为公开，或者邀请感兴趣的热心人一起来维护。

Popularity: 25% [?]

早几天曾经介绍过在Firefox 3的查询工具条中利用OpenSearch技术添加自定义的搜索引擎，比如把我的kukoo’s blog的内建查询添加到查询工具条中。

Eclipse 社区的 Cypal Solutions 首先利用 Google 的自定义搜索技术制作了一个 Eclipse Search，然后通过同样的 OpenSearch 技术，可以把这个 Eclipse Search 添加到Firefox 3 的搜索工具条中。 这个自定义的 Eclipse Search 通过 Google 可以搜索超过250个和 Eclipse 有关的站点，包括blogs，docs，source code等。

（图片来源：cypal-solution.com）

使用 OpenSearch 技术，首先要定义一个搜索引擎，我的kukoo’s blog搜索之所以能被加入到 Firefox 3 的搜索工具条，也是因为有 WordPress 提供的搜索引擎。 通过 Cypal Solution 的做法，可以通过 Google 自定义搜索的方式来首先定义一个搜索引擎，然后通过 OpenSearch 让其可以支持 Firefox 3（也能支持IE 7）。 也许，用同样的方法来做一个 Groovy/Grails 的搜索，有利于目前正在进行的学习之旅。

Popularity: 31% [?]