梦想风暴

生命是最宝贵的，工作之后，我越发可以体会健康对一个人的重要性了。当一个人失去健康时，他是不幸的，但当得到了更多人的关怀，他又是幸运的，这是一种浓浓的人间真情。原本，我不愿在梦想风暴上转载其它的东西，但为了这份人间真情，我愿意破这个例。希望看到这篇blog的朋友也能够尽自己的一份力量。

真诚的祝福王俊！

援助程序员王俊行动

王俊，今年27岁，北京北方银证公司项目经理，是北京Java用户组（BJUG，http://www.bjug.org）的核心会员，曾在BJUG的讨论会中进行了JMS、Tapestry等主题演讲，他在JavaEye的ID是"后山"，是JavaEye成立之初的老注册会员和JavaEye高级会员（http://forum.javaeye.com/profile.php?mode=viewprofile&u=33）。一个年轻人，有感兴趣的工作，不错的前途，还有一群可以随时交流技术的朋友，生活看起来平淡却充实。

业余时间，王俊经常还利用blog（http://befresh.blogbus.com）写下自己生活和工作中的酸甜苦辣，此外他还有一个并不富裕但却很温馨的家。

然而从今年二月份起，王俊的blog就再也没有更新过了，他也没有在BJUG的聚会和javaeye出现了，所有人都以为他出差去了。直到前天，惊闻他要换骨髓，才知道今年年初，王俊被查出患有“骨髓增生异常综合症”。

骨髓增生异常综合征目前认为是造血干细胞增殖分化异常所致的造血功能障碍。主要表现为外周血全血细胞减少，骨髓细胞增生，成熟和幼稚细胞有形态异常即病态造血。部分患者在经历一定时期的MDS后转化成为急性白血病；部分因感染、出血或其他原因死亡，病程中始终不转化为急性白血病。

这种病目前最有效的治疗手段是换骨髓。万幸的是，王俊的妹妹和他的骨髓配型一致，免疫系统的疾病发现治疗的越早，就越可能成功，他目前的身体状况还好，只要能更换骨髓，完全可以康复！但让他们一家望而却步的是，仅手术押金就需要20万，全部疗程视治疗效果可能需要30-100万。

王俊的家在浙江杭州千岛湖，父母都是农民，已然老迈且没有固定的经济收入，姐姐在当地出嫁，收入颇低，妹妹目前在北京读成人教育并在公司打工。王俊是家庭经济主要来源，他的病不仅掐断了家里唯一的经济来源，还要花上对他们而言是天文数字的钱来治病。

"文章千古事，得失寸心知"，这是王俊blog上的座右铭。细细翻看这个典型程序员的blog，就和他的人一样朴实无华，在那里满眼看到的都是对技术的孜孜追求。谁能想到一个如此活跃的头脑现在却被病魔折磨着。

生命是美好的，这世界每天都有若干悲剧发生，这次，大家每个人出一份力，这世界就会少一个悲剧，多一份美好，多一份欢笑。也许，你只是少吃一顿大餐，少买一瓶化妆品，少看一场演唱会，少买一件名牌服装，少玩一个月的网络游戏，少上一个月的网，但是你却可以为一个家庭托起一份生的希望。

*****
联系方式
邮件 help@bjug.org
MSN icecloud@sina.com 冰云(BJUG)

联合发起：
BJUG http://www.bjug.org
CSDN http://www.csdn.net
JavaEye http://www.javaeye.com
JActionGroup http://www.jactiongroup.net/
Huihoo http://www.huihoo.org
RedSaga http://www.redsaga.com
Matrix http://www.matrix.org.cn
Blogbus http://www.blogbus.com

援助办法：
1 捐款

帐号：
工商银行
户名 王俊
帐号 0200 2008 0102 3428 807
开户行 工商银行北京市西内所

招商银行
户名 王俊
帐号 9555 5001 0200 2820
开户行 招商银行 北京分行

中国银行
户名 王俊
帐号 4021400-0188-001204-0
开户行 北京西直门支行

国外汇款方式
ADD: BANK OF CHINA BEIJING BRANCH
NO.8 YA BAO LU
BEIJING, CHINA
SWIFT-CODE: BKCHCNBJ110
A/CNo: 4021400-0188-001204-0
NAME: WANG JUN

捐款方式：
A 网上银行
工行请采用行内汇款->有收款帐号汇款
招行请采用个人银行专业版的同城转帐/异地汇款，并选中：采用系统内快速汇款

B 银行汇款
请抄录上述帐号并到银行填写汇款单

请在捐款后，发邮件至help@bjug.org，通知我们，以便统计核对捐款帐目。
(1) 姓名，
(2) id/网站,
(3) 发出银行/发出帐号，
(4) 金额，
(5) 时间

2 帮助宣传：

• 请到http://befresh.bjug.org 留下你对他的祝福
• 请在MSN上修改您的名字，我们都写上 [祝福后山]
• 请修改您MSN的头像为我们提供的图标
• 增加行动网站的地址 http://befresh.bjug.org 到MSN名字后面的个人信息
• 请看到此文的Blogger，在您的blog上link此文，并Trackback到后山的blog
• 请看到此信息的人，帮助一起宣传，我们需要您的帮助
• 在您的BLOG或网站，加上用我们提供的LOGO，并连接到网站http://befresh.bjug.org
• 泡论坛的，请修改你的论坛LOGO和签名档为提供的图标

一个程序员的离职信
How to be a Star Engineer

工作过了一段时间之后，我并不满意自己的现状，因为我不清楚这样努力下去，自己能够到达怎样的高度。《一个程序员的离职信》是一篇让我的心为之震动的文章，同样的三年程序员，同样的喜怒哀乐，我惊讶于作者道出了我的心声，也毫不留情让问题暴露在光天化日之下，无处可藏：

• 职业生涯发展碰到天花板
• 技术发展碰到天花板
• 薪资待遇碰到天花板
• 产生惰性

无欲无求或许是一种幸福，但是仍在艰难前行的我们如何能够达到这样清高的境界。与朋友们聊天时，我常说，我向往的生活就是，在不为生活而烦恼的情况下，用程序体会创造的乐趣，用文字分享快乐的感受。虽然我现在也在写程序，也在写文字，但我毕竟我的身上还有着一个沉重的生活压力，让我无法回避。

如果说《一个程序员的离职信》是发现了问题，那么《How to be a Star Engineer》也许算是一个答案吧！

• 闪亮的轨迹（Blazing trails）
• 知道该问谁（Knowing who knows）
• 主动的自我管理（Proactive self-management）
• 掌握全局（Getting the big picture）
• 正确的追随（The right kind of followership）
• 团队合作（Teamwork as joint ownership of a project）
• 小领导者的领导风格（Small-l leadership）
• 精明（Street smarts）
• 呈现（Show and tell）

这份来自贝尔实验室的研究报告告诉我们，脱颖而出需要的并不只是个人能力，更需要把能力恰如其份的发挥出来。这份报告在每一项中将一般员工与杰出员工的行为进行了对比，相信你和我一样，阅读的这份报告时，会情不自禁的将每种行为与自己的所作所为进行暗中的对比，打了多少分，只有自己知道。究竟这些做法是否真的会让人杰出，择其善者而从之吧！

无论是做程序员，抑或是其它岗位，做事的道理都是相通的，这大概也算是一种抽象吧！^_^

最初接触计算机的时候，我一直景仰那些用代码变魔术的人，他们可以做到我无法做到的事情，其根本原因还在于我自己不过硬的技术。经过几年编码的历练，应对工作已不再话下的我慢慢的也学会了用代码表达自己的思想，渐渐可以感受到代码中蕴涵的无穷魅力。虽然我的技术还没达到令自己满意的高度，但我相信，凭借自己对技术的认知，大多数技术只要认真学上一段时间，我都可以掌握。这种感受让我清楚的认识到为什么很多人都说技术不重要，因为像我这种普通智力的人经过几年积累都可以达到的水平，相信很多人也都很快可以达到。既然技术已经不是什么问题了，那当然也就不重要了。不过，也是对技术的自信使我敢于放弃原有的工作，转到了一个全新的工作岗位上。

新部门是一个偏重研究的部门，我的工作是一个识别算法，准确的说，这是一组人的工作。说起来很容易，但工作并不像我想象的那么轻松。首先面对的就是我可怜的基础，在这里，需要的知识是图像处理和模式识别，而我懂的只是Java——根本不挨边的东西。按照领导的说法，我是部门所有人中起点最低的一个，因为这里博士硕士占了很高的比例，仅有的几个本科生工作年头都比我多，而这些年里面，他们做的也都是图像处理相关的领域。对于学习新知识，我有兴趣和自信，郁闷了一段时间之后，我逐渐能够听懂别人说的话，开始提出自己的想法，慢慢的进入到新角色中。适应了新角色之后，我才发现，真正困难的并不是那些基础知识，那只不过是一张入门的通行证而已。

软件开发就是用计算机解决问题的过程，从前开发的软件虽然问题各有不同，但解决问题的模式基本上已经固定下来，甚至可以说已经非常成熟了，所以，成熟的东西掌握起来要容易许多，这也是前面我提到自己自信的原因，创造出1+1=2不容易，学会还是很容易的。真正困难的在于不成熟的东西，这就是我们现在面临的问题。

在我加入部门之前的学习阶段，同事们曾经翻阅了几百篇的论文，但却并没有得到最终解决方案，这其中有很多原因，有的是无法达到我们的要求，有的是提出做法却语焉不详，有的是专利……，最终的结果还要我们来探索，因为这个领域的技术并不像Java技术那样成熟。当然，如果有解决方案，我们这个部门存在的价值就不大了。我们在不断尝试改进着自己的识别算法，任何一点改进都会让我们欣喜不已，好久没有这么累得这么快乐了，这是一个挑战自己技术极限的过程。在这样一个技术不成熟的领域中，我们的起点是别人的肩膀，但能否最终能够到达增样的高度却是由我们的努力所决定的。

技术不重要，前提是技术已经成熟，而在一个技术不成熟的领域，技术就是拦路虎。

这个世界唯一不变的就是变化。在软件开发中，变化更是一种常态。各种各样的原则、策略大多是为了应对变化而产生，XP的口号喊得好：“拥抱变化”。一方面，变化来临时，我们应该临危不惧，积极应对，另一方面，我们应该未雨绸缪，把变化控制在一个很小的范围内。选择第三方开发包就是我们在开发层面上应对变化的一种常用的方法。

计算机的发展已经走过了最初的那个“一切轮子从头造”的年代，不使用任何第三方开发包的项目已经逐渐的成为了稀有动物，尤其是在开源运动蓬勃发展的今天。百花齐放、争奇斗艳是计算机世界一道靓丽的风景线。任何有价值的东西都会有不只一个解决方案摆在我们面前。没有选择有时是最好的选择。选择多了，却会让我们费尽思量。毕竟，这种选择意味着风险。（关于技术风险的讨论，参见《技术的风险》）

在选择第三方开发包时，我们通常会考虑如下一些因素：

• 开发包的成熟程度。要应对的变化已经很多了，我们不想给自己找新的麻烦，几天一变的API是会让人抓狂的。
• 业界的采纳程度。一个东西用的人越多，经验教训就越多，遇到问题就越容易解决。
• 免费与开源。开发包免费意味着降低成本，降低成本意味着什么，大家都很清楚。开源意味着降低解决问题的门槛。
• 持续的更新。持续的更新意味着项目的发展，流水不腐，户枢不蠹。当然，也有例外，有些项目不发展是因为开发者认为它已成熟。
• 用户的接口。想法好，不等于实现好，毕竟，东西是给人用的，而不是自娱自乐，一个易于接受的用户接口同样重要。
• 背后的力量。同样的东西，一个由Apache、Codehaus这样的开源组织开发，一个由个人开发，我们如何选择。除非这个人就是你自己，否则，大多数人会选择背靠大树好乘凉。
• 项目组成员的熟悉程度。熟练意味着生产力，毕竟老板关注的是进度，而非技术。
• 专人支持。对整个项目影响比较大的基础结构，比如Spring、Hibernate，最好在项目组内有专人负责解决遇到的问题，如果实在找不到，请求专家的帮助也是不错的，尽管很多专家不会无偿的为你工作。
• 蕴涵的思想。这是一个自私的选项，用新东西意味着学习，谁不想多学些东西提高自己。

选择第三方开发包，关键是为了提高生产力。虽然每个组件和框架都会告诉你自己有多好，回报是否能够大于服务，最终的裁决还要自己做出。

这是我的选择，你的呢？

Apache作为一个著名的开源组织，几乎涉足了Java企业级应用的方方面面，小到基本的类库，大到完整的应用。美妙的DI容器之争又怎么会少得了它呢！Hivemind便是Apache给我们的答案。

从Hivemind的架构图中，我们可以看出，Hivemind原本是用来封装各种各样的服务，以提供给应用使用。从Hivemind文档中不断出现的“service”可以很好的印证这一点。不过，设计的结果让它成了一个DI的容器，它也由此迈上了一个更高的台阶。设计的结果让它成了一个DI的容器，由此迈上了一个更高的台阶。

下面该问候Hivemind了。
public interface Action {
    void execute();
}

public class HelloAction implements Action {
    private String name;   

    public void setName(String name) {
        this.name = name;
    }

    public void execute() {
        System.out.println("Hello, " + this.name + "!");
    }
}

public class Main {
    public static void main(String[] args) { 
        ClassResolver resolver = new DefaultClassResolver();
        Resource resource =
            new ClasspathResource(resolver, "config.xml");
        RegistryBuilder builder = new RegistryBuilder();
        builder.processModules(resolver);
        builder.processModule(resolver, resource);
        Registry registry =
            builder.constructRegistry(Locale.getDefault());
       Action action =
            (Action)registry.getService("hello.action", Action.class);
        action.execute();
    }
}

这里我们使用的是Setter Injection，对于DI容器来说，同时支持Setter Injection和Constructor Injection已经成为一种常态，只不过，有些容器对于某些注入方式有特别的偏好而已，于是，选择权转到了用户的手中。

从这个例子我们不难看出，相对Spring的API而言，Hivemind的API使用起来有些复杂。下面两行代码就是一个让人困惑的地方：
    builder.processModules(resolver);
    builder.processModule(resolver, resource);
如果说第二行代码是为了加载资源，那第一行就显得有些莫名其妙了。其实，它是用来加载Hivemind自带的一些服务。它之所以让人困惑，其主要原因就在于如果不加载这些服务，应用是无法运行的。对于老手，自然无甚所谓，而对于刚刚接触Hivemind的人而言，大家兴高采烈编写Hello的时候，哪里会知道有这些规矩的存在。通常，其结果就是给初学者以无情的打击。
当然，照着Hivemind的Tutorial写代码可能不会遇到这种问题，因为它用了缺省的加载方式，这种方式需要把叫hivemodule.xml的配置文件放到META-INF目录下。而在实际的开发中，这种被限制的做法并不让人喜欢。

在配置文件中，我们发现，服务的“接口”和“实现”是分离的。Java中关于分离接口和实现的种种好处大多适合在这里使用。当然，如果我们认为自己的服务不会发生改变，把接口与定义放在一处也并无不可。
Hivemind为用户提供了一个工具，用来从配置文件中提取相关的内容生成一个便于阅读的文档，这便是Hivedoc。我们可以把它理解成JavaDoc，通过它，我们可以将文档从“源码”中分离出来。
Hivemind允许在配置文件中对配置的格式进行自定义。这样，如果某个服务得以复用，那么就可以利用这个功能简化配置文件的编写。对Spring用户来说，这可是一个充满吸引力的功能。这一功能的实现借鉴了Commons Digester的表现形式，巧妙的将规则描述同对象生成融合在一起。

与其它DI容器稍有不同的是，Hivemind在容器一级上就把AOP的概念加了进去，在配置文件中，我们可以通过配置Interceptor，拦截对某个service的调用。Hivemind可以在配置文件中很简单加入一个Aspect，而不像Spring那样，需要绕一个弯子。这种差异就像把一个功能以语言特征还是以库的形式提供一样，对比C++中同步的处理手法，想想Java中的synchronized就不难理解这一点。“语言设计就是库设计，库设计就是语言设计”，二者在开发者的层面是可以很容易相互转化。究竟如何选择，完全取决于开发者的态度。