-
唯一值得重复的
重复是软件开发中最大的阻力，没有之一。
重复是邪恶的。我是说，邪恶的！
永远不要为同一份信息保存两份拷贝。
DRY是写出良好代码的根本原则。
（如果这个世界上有一些信息值得被重复的话，就是这些。）
-
螺狮壳里做道场
以前闲得没事的时候想过在MSN上做插件，结论是那玩意它就不是正常人能玩的。
Spark是一个开源的IM客户端，并且据说特别适合企事业单位办公用…其实就是对插件支持比较好的意思吧。插件都是用Swing来写的，API也很简单。做一个JFrame往里一扔就搞定了。
（还有Openfire也是他们家做的。配置简单使用方便，不错不错的说…）
自己跟自己聊天几分钟以后决定做一个浏览器嵌在Spark里面这样就可以一边聊天一边看网页（唔唔，很有追求）。JDIC它对MacOS X支持就有问题，搞了两小时还是不行，于是换方向。Lobo是纯Java的浏览器然则对JavaScript的支持只有这种程度的浏览器它是没办法实用的。JRex貌似从05年以后就没有更新鸟。至于Gecko Embedding…这个，未免太高科技了吧…
于是最终来到了MozSwing。稍微花了一点时间配置，它还是效果粉不错的亚～～这里有个WebStart可以试用一下，还有一篇blog介绍怎么玩，来自LimeWire的作者，显然他们也借用了一把，呵呵。
其实粉简单，总共就三句话：
MozillaPanel mozilla = new MozillaPanel();someSwingContainer.add(mozilla);mozilla.load(“http://limewire.com“);
下一个目标，把Groovy给搞进来玩玩。
-
原来，好照片都是P出来的
被某位大人点拨了一下才知道，好照片都是要后期加工的…比如这个加过工的版本它就比原始版本看着要舒服。
楼下的苗圃到秋天时很快就黄掉了…这才是所谓金秋啊…我打算给这个苗圃拍一年四季，留做纪念。
From金秋的苗圃 也可以做出萧杀之感。
From金秋的苗圃 有个人说，你正在失去那些纯真的东西。
不对。看到那些美的事物的眼睛不是虚假的。美的本性一直就在原始的照片中。它被杂质掩盖，需要雕琢与重新发现。拒绝雕琢不是保持纯真，而是暴殄天物。
每张照片最终将成为它自己。那才是它的应得之所。
-
享受代码之美
（本文系《代码之美》的推荐序）
“希望写出漂亮代码的开发者可以向艺术家们学习一些东西。画家常常放下手中的画笔，然后远离画布一段距离，围着它转一转，翘起脑袋，斜着看看，再从不同的角度看看，在不同的光线下看看。在寻求美的过程中，他们需要设计这样一些视角并使它们融为一体。如果你的画布是个集成开发环境（IDE）而你的媒介就是代码，想一想，你如何做到离开画布一段距离，用挑剔的眼光从不同的视角来审视你的作品？──这将使你成为一个更优秀的程序员，并帮你写出美丽的代码。”
写这段话的AlbertoSavoia在他的文章里真的没有讲什么令人敬畏的高技术或是大架构，他讲的是每个计算机系的大二学生都熟悉的二分查找。所以Savoia真的是在讲如何写出漂亮的代码，所以才选择了这么一个所有人都清楚得不能再清楚的例子。你会觉得这种事情都是些不谙世事的小程序员才会热衷于干的吧？可这位Savoia却是从Google离职以后开创了AgitarSoftware公司（http://www.agitar.com/）的不折不扣的创业者。有意思吗？一个胡须花白、在这个行业里厮混了数十年、拥有自己公司的老家伙，还在乐此不疲地谈论“漂亮的代码”。
这本《代码之美》就是由三十多篇像这样有意思的文章组成的。像Brian Kernighan、Tim Bray、Charles Petzold、Douglas Schmidt、YukihiroMatsumoto这样的名字，你甚至很难想象他们同时出现在同一本书上。或许也只有“漂亮的代码”这样的话题才能激起他们共同的兴趣。于是就有了这本了不起的书：从正则表达式匹配器到图像处理，从通信到基因排序，这些可能是世界上最优秀的程序员毫不吝啬地向读者展示：不论面对什么问题、使用什么语言，代码的美感都是始终存在的，而且这种美感应该是程序员毕其一生不懈追寻的。
作为《重构》的译者，不时有人会问我一些关于重构的问题，其中一个问题让我最感为难：为什么要这样做？真的，如果不是要修改代码，也不是要添加功能，为什么要把这段代码抽取出来呢？让每个方法都保持5行以内的长度到底有什么好处呢？这种时候与其说是有什么利弊权衡，毋宁说就是为了让代码“更漂亮”。当然了，在大部分时间里，软件开发是一项集合了科学、工程和服务的工作，但──至少在我们的内心深处──它多少还有那么一点艺术的成分。除了完成任务以外让自己手上的代码更具美感，也算是对自己作为程序员的梦想的小小坚持吧。
所以，既然你已经拿起了这本书，就暂时放开那些功利的目标吧──别误会，这可不是一本没用的书，通过阅读这些“高手”们的编程心得，对自己的能力提升就算不能立竿见影至少也有潜移默化之功。但那也只是装珍珠的盒子而已。在一个安静的周末，给自己泡上一杯清茶，跟着三十三位顶尖高手畅游在代码世界，在他们的指引下遍赏代码之美，这才是作为一个程序员最大的享受呢。
-
看完美的风景就好
昨天，去了盘山。丰富的色彩。
云淡天高。
又听说了一个，看起来很疑似，培训的骗局
大概程序员就是很好骗的吧。因为总是跟机器打交道，任何事情不对了第一反应就是“那一定是我的错”。
完美的眼光，还是留着看风景吧。这个世界不是本来就有那么多不完美了么？干嘛非得我来内疚？
（补充：如今去盘山可以从机场高速温榆桥上京平高速然后直奔，路好，车少，一路飙。）
-
历史，蓝天，碧水
昨天，去了鸡鸣驿。几百年的老驿站，还有大话西游里吻别的城楼。
印象深的，却是蓝蓝的天，低低的云。似乎从没在北京见过的。曾经繁华的驿站，黄沙吹过，阳光清朗亮眼。
偶遇的驴友去了别处，和他们道别后到了官厅水库。有点小越野的乡间路上开车很有感觉。
水边好风景，在一大片向日葵边发呆，连照片也不想拍了。
-
大船瓦沙
（FromTheProductive Programmer）
1625年，瑞典国王古斯塔夫二世·阿道夫打算建造有史以来最棒的战舰。他雇了最好的造船工匠，专门种植了一片最刚硬的橡树林，都为了建造大船瓦沙。国王不断提出各种要求，希望把船建得更宏伟壮丽，到处都加上华美的装饰。有那么一天，他甚至决定在船上配备两套甲板炮，这是当时世界上绝无仅有的。他的船会是海上的霸王。而且由于迫在眉睫的外交问题，他还希望大船瓦沙能尽快造好。当然了，工匠们一开始的设计只有一套甲板炮，不过既然国王提出了要求，自然就得再加一套。由于太赶时间，工匠们来不及做“摇晃测试”──让一群水手从船的一边快跑到另一边，船在这种情况下不应该摇晃得太厉害（换句话说，没有头重脚轻）。结果，它的处女航只有几个小时，然后就沉入了海底：在给它加上所有华丽“特性”的同时，国王和工匠也让这条船变得根本无法航行。大船瓦沙在北海的海底长眠了几百年，直到20世纪初才被打捞出来，陈列在博物馆里。
一个有趣的问题：到底是谁导致了瓦沙的沉没？是国王，因为他要求了太多的特性？还是工匠，因为他们只顾着满足国王的要求，没有大声说出自己的担忧？看看你正身处其中的项目吧：你是不是正在建造又一艘瓦沙？
只做当下需要的。一开始这会很难，但最终你会得到一个更好的代码库。如果不引入不必要的复杂度，在修改或是重构时就不用对抗这些复杂度。程序员应该谨记：熵会杀死软件，所以，如无必要，勿增特性。
-
Tips from an Old Test Manager
(FromTheBuildMaster)
For most of my career, I’ve been a test manager. I’ve come to realize that the job of atestmanageris 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 thequality isterrible 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 timetheyask isjust to see if what they’re asking for sounds good to them. If you do what they ask whenthey’veonly 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 baseballbat.
- 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 percentofreorgsmean 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.”Whenthe samequestion 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 areinterpreted tomean something completely different.
-
拿起这本靠谱的书，上路吧
Rails的创造者David HeinemeierHansson这样说：“我从来不会为了学一种语言而学一种语言。我学习新的编程语言一定是要用它来做点什么事。”同样的道理，很少有人只是为了学习漂亮的设计而开始接触Rails，大部分人──就像我一样──是抱着一个功利的念头开始自己的铁道之旅的。“我要做一个网站，听说有个叫Rubyon Rails的东西做网站又快又好，我得看看这是个什么玩意。”──大抵是这样的念头。
所以，Rails的学习者们真正要的不是深入理解Rails，而是又快又好地做出自己设想中的网站。
这年头的网站创业者们想要的不是“Ruby onRails做的网站”，而是一个具有各种2.0特质的、很酷的网站。“什么mashup啦、widget啦、AJAX啦、REST啦，能用的全给它用上。你要是URL里还带一问号啊，你都不好意思跟人打招呼。每个页面放一地图，甭管有事没事都往地图上标记，倍儿有面子。这网站就够牛了吧？那是基本要求，还得在多种环境部署，高性能的服务器环境一个脚本就得部署好。你想啊，那些做一个功能都只花15分钟的程序员，根本没心思用俩小时做一次部署。所以我们的要求是：不但要酷，还要敏捷。”程序员们面临的大概就是这样的挑战。
诚然，作为入门手册的《Web开发敏捷之道》（Agile Web Development withRails）在实用性方面做得已经不错了，一位初学者可以跟着那本书做出一个像模像样的玩具网站，同时对Rails的方方面面有个大致的认识。不过当他们尝试动手做自己真正想要的那个网站时，就会突然发现面前赫然立着两只拦路虎：第一，真正的网站不是玩具，有太多真实世界里的常见问题他们不知该如何解决；第二，Rails一向秉承“做一件事并且做好”的Unix设计传统，这也就意味着要做一些真实有用的功能往往需要很多Rails之外的相关知识。这可真是件令人沮丧的事情：花了好几天工夫来学习Rails，自以为已经习得一身好武艺，一出山门却发现面前摆着那么多难题不会解决，甚至想翻书都不知该从何翻起。
简而言之，他们没有套路。
这本《Web开发大全（RoR版）》就是帮这些踌躇满志的网站初哥们解决套路问题的。这几位实战经验丰富的作者各出高招，简单介绍Rails之后，立即把用户管理、内容展示、文件上传、搜索、RSS等等网站“家常菜”给抽丝剥茧地细细解说一遍，再把各种常见的mashup逐一介绍，尤其是为地图服务这个重要的2.0元素单辟章节（值得一提的是，撰写这一章的高昂乃是中科院地理所的博士，从他的专业角度来介绍互联网上的地图服务，可谓高屋建瓴鞭辟入里，不可不读）。讲完开发的内容，部署工作也没有被忽视，第十章“部署演练”介绍了各种曾经或正在或即将流行的Rails应用部署方案，特别是关于JRubyon Rails的介绍引人注目：这是将Ruby on Rails和J2EE两个世界结合起来的纽带，ThoughtWorks的第一个商业产品Mingle就采用了这种部署方式。
这是一本有套路的书。看完这书的读者应该能学到网站开发的套路。
最后我还得夸赞一下这几位作者。从中国有Ruby onRails社区开始，这几位就个顶个的是社区里的积极分子。他们为Rails在中国的发展起了重要的推动作用。有骆古道这样远赴重洋心系祖国的爱国程序员，有王大力这样组织和掺合全国各地各种技术活动的热心大叔，有董斌、苏锐这样长年在互联网一线奋战的技术中坚，有黄翀、高昂这样醉心技术深度广度俱佳的有为青年，这么一群靠谱的人和博文视点这么一家靠谱的出版商一起创作的作品，理当是一本靠谱的书。
所以，怀揣梦想的Rails爱好者们，拿起这本靠谱的书，上路吧。
-
昨天的AJAX就是今天的并发编程
（FromTheProductive Programmer）
顶多就在五年前，我们炮制的那些丑陋得简直就像把命令行窗口直接塞进浏览器的web应用还能让用户满意。可是Google那些讨厌的程序员毁了这一切：他们发布了GoogleMaps和Gmail，更要紧的是他们让用户明白web应用不一定要那么糟烂的，于是我们只好跟着开发更好的web应用。现在并发编程的情况也是一样：我们这些程序员现在还可以幸福地对严重的线程问题视而不见，但一定会有人站出来，让人们看到某种新发明的威力，然后我们又得亦步亦趋地跟上去。我们的计算机有强大的运算能力，而我们却没有能力写出那样的代码来充分利用它们，这对矛盾正在日益凸显。
