梦想风暴

周末没得闲，因为参加了一次CodeJam。

CodeJam，是公司组织的一个编程活动，就是要在周末两天时间内开发出一个东西，据说此类的活动在其他的办公室举办过。这是我第一次参加类似的活动，参加这次活动的Dev都是公司内比较优秀的程序员，平时很难把这些人都放到一个团队里面，有机会和这些人在一起工作，本身就是一件令人期待的事。

这次活动的目标是为一个支援乡村教育的组织开发一个分享平台。在活动开始之前，我们对需求一无所知，所以，几乎就是看两天内能够写出多少东西。因为这个项目要开发的是一个Web应用，从生产率的角度来看，我们当仁不让的选择了Rails作为开发工具，这也是我最近在学习Rails的原因之一。

万事开头难，这次CodeJam也不例外。在一群Dev准备甩开膀子大干一场的时候，我们发现了一个问题，没有需求。需求，是冰云（BA）和QQ（QA）在之前一天和我们的客户谈好的。QQ在离开办公室之前，把从需求整理出的Story卡片锁到了自己的抽屉里，结果，第二天，她闹肚子了。好在冰云临危不惧，顶着我们的巨大压力，把部分Story重写了出来。直到QQ重新归队，打开宝箱，需求问题才得到了彻底的解决。

正式开工，场面那是相当壮观。一群ThoughtWorker，一群快手，一帮人抢着提交代码。做用户登录部分的高喊着，他们应该是第一个提交数据库表的，结果，更新代码时，已经有了数据库版本已经到了3。那是我和WPC干的，因为我们俩负责搭建开发环境，所以，先下手为强了。不过，我们高兴得有些过，用scaffold生成的代码出现了一个拼写错误。这时我们才发现，修改这些生成代码是多么痛苦的一件事。

在这里，我们用的典型的ThoughtWorks工作方式，一对Pair，拿到一张Story卡，然后，小步前进：测试、编码、重构、提交。正是因为步幅很小，所以，就出现了大家争抢着提交代码，因为稍微慢一点，就会更新下来一片代码，这种时候，便要重新运行测试。运气不好的话，破坏了别人的测试，还要帮别人修复。其实，在一个大的开发团队中，这种现象很常见，尤其是测试多到不能很快运行完，比如有集成测试的时候，常常是运行测试之后，又来了新代码。

典型的ThoughtWorks工作方式，还有另外一个含义。一群人一边写着代码，一边互相开着玩笑。在我的印象中，ThoughtWorks开发团队从来就不缺少笑声。其实，这次参加CodeJam的人，有很多我并没有直接在一起工作过，所以，这也是一个很好的了解大家的机会。比如，在我的印象中，WPC一直是闷着头写代码的家伙，和他Pair才知道，他原来也是那么有才，可以让人笑得肚子疼。至于像徐X和gigix这种平日里就给大家很多欢乐的家伙（也许也包括我自己）就更不用说了。当然，也有比较安静的，亮亮和来自加拿大的Ricky被我评为“最安静的Pair“。

两天下来，从无到有，一个具备基本功能的网站就建立了起来。showcase的时候，看着这个小网站，心里还是很有一丝满足的。对我而言，这是我第一次做Rails项目，第一次尝试用TextMate去开发。

这次CodeJam，是在公司内部进行的，希望将来有机会把这个面扩大一些，让其他公司的人来和我们一起来做，一方面我们可以从其他人身上学习到一些东西，另一方面，也让别人了解一下ThoughtWorks是如何工作的。我相信在如何进行软件开发这个问题上，ThoughtWorks做得足够好。

UPDATE
其他的ThoughtWorker也有对这次活动发表了自己的看法。
冰云：Beijing Code Jam - 2 days agile development project
Ricky：CodeJam@Thoughtworks Beijing

是的，我在学习Rails。

我所了解到的，大多数人是因为Rails而学习Ruby，像我这种了解Ruby却对Rails一窍不通似乎是异类。道理上来说，传统的途径应该是先学语言，再去了解相关的开发框架，像Rails这样喧宾夺主的情况，也算是异类了。当然，也正是因为Rails的喧宾夺主，才让人们有了更多的机会认识Ruby，了解Ruby的优雅。

趁着我还不那么了解Rails，把Rails留给我的初印象记录在这里，算是一个初学的记录。

Convention over Configuration（CoC），这是Rails广告给我留下的最深印象。这是一种改变业界对软件开发认知的思想。如同Spring让我们认识了Dependency Injection（DI），进而改变了我们的设计方法。Rails让我们认识到，原来有时候程序设计并不需要那么灵活。一片惊呼之后，效仿者蜂拥而至，人们纷纷尝试把这个想法带到自己熟悉的平台，其场面与Spring当年带来的DI容器热如出一辙。

如果Spring只有DI，它并不会带来真正的变革，同样，Rails也不是只有CoC。在我看来，CoC之外，Rails还集成了Web开发的实践。

Web开发实践有哪些？首当其冲的自然是MVC的架构，所以，在Rails中，明明白白的在目录结构上就把MVC分得清清楚楚。不过，我们还是抛开MVC这种路人皆知的答案，看一些具体的东西吧！

用Java写Web方面的应用时，我最担心的问题是如果一不小心上了某个框架的贼船，比如Servlet，结果就是为了看到自己程序能够正确运行，不得不把应用部署到服务器上。一旦出现了问题，解决问题就变成了一个非常低效的过程，因为我们不得不一次又一次的进行部署，大好的年华便随风而逝了。所以，对我而言，做Java应用的设计时，一个指导性原则就是尽量不依赖于任何框架，这样，就可以把真正的逻辑剥离出来进行测试了。初涉Rails，我也有类似的疑问。但我发现，原来Rails框架本身已经替你考虑好这个问题，它把测试的考虑也内建到框架之中，这样便可以很容易的针对每个Controller编写测试，而又不必理会部署的消耗。

Rails在测试方面有很多的考虑，它清楚的分出为Model而写单元的测试，为Controller而写的功能测试和跨越Controller的集成测试，而Fixture这个概念的存在，让我们很好解决测试数据的问题。这一切实际上都是一些优秀的软件开发实践。实际上，像这样的实践，Rails开发框架中还有很多，比如，如何处理页面布局、如何使用Ajax、如何管理数据库的迁移、如何让自己的应用Restful等等。使用Rails，不经意间，我们便可以走上一条正确的路。同许多开发实践一样，单独来看，这些做法本身并看不出多大的价值，但放到整个软件开发过程之中，便可以极大的提高开发生产率，尤其是在后期维护阶段。

不同于之前用过的一些框架，需要在实践中摸索正确的用法，Rails是第一个让我强烈的感受到开发实践内建其中的框架。只要走在Rails的道路（Rails Way）上，那么无论如何都不会偏离正确的方向太远。正确的道路何在？不得不提起《Agile Web Develpment with Rails》（中文版《Web敏捷开发之道》）。技术，常常是养在深闺无人识。其实，这个世界上一点都不缺好的想法，好的做法。我们经常会看到一些新东西让我们感慨，原来还可以这么做，但是，大多数时候，我们并不知道这些东西的存在。这本书的出现，恰到好处的向人们展示了Rails的优秀，比如前面提到的那些实践。不同于很多板着面孔教育人的计算机书，这本书轻松愉快的把一个完整的开发过程展现在人们面前。大多数人几乎是同时认识这本书和Rails框架的，所以，几乎一开始，Rails一族便走在正确的道路上。

不过，Rails还很年轻。年轻的结果就是不稳定。《Agile Web Develpment with Rails》第一版和第二版之间号称有70%的变动，而Rails 2.0又让第二版中的程序遭遇起步停车，一开始便会有差异。有些时候，这会打击初学者的积极性，也会让希望采用Rails的企业望而却步。

这便是我对Rails的初印象。

不知道算是幸运，还是不幸，我参与的多数项目，如果不是从头开始，我也是最开始加入的几个人之一，所以，我通常对项目的来龙去脉都比较清楚。这次，我有机会尝试一下在一头雾水的情况下开始一个项目。

这个项目已经进行了超过一个月，因为客户需要在赶在最近的一次发布之前，增加一些功能。老板按照目前的进度估算了一下，如果不加人，这个任务很难完成，于是客户很合作的同意增加两个人。就这样，我成了临时工。事实上，在这个阶段进入，项目早就过了最初的阶段，远远望去，没有几百也有几十的程序文件屹立在那里。虽然有最熟悉项目的人为我们介绍了项目的背景和架构，但这些宏观层面上的东西，对于编写代码这样“微观”的操作而言，几乎是没有任何直接的帮助。作为一个新人加入到项目，除了发呆，我还能做什么呢？

回想在以前公司的情形，大多数新进项目的人多半是得到一大堆文档，然后，有人语重心长的说，先把文档看了吧！且不说这些文档这种东西几乎写出来就过时，单单读完这些文档就需要花费很多时间。运气好的话，还有代码可以对应，但千万不要指望你能够一下子读懂这些代码。也许，你会想找别人来问，如果不出意外，大多数人都会不明就里的非常忙，忙到有时间上网聊天却没有时间给你讲这些东西。事实上，很多人即便自己做了很多东西，也不一定能够清晰的描述出来，所以，即便找到一个“闲”人，成功从他那弄明白这些东西的概率也很低。其结果是，我们经常会看到一些人在那对着电脑上的文档发呆。

在ThoughtWorks，我也恨不得找到一堆这样的无聊文档来打发时间，以此来享受偷懒的时光。遗憾的是，完全没有这种机会。因为那些“文档”会被视为浪费，这在以消除浪费为己任的敏捷来看，是无论如何不能接受的。于是，我在找不到任何借口的情况下，进入项目的第一天，就开始写程序了。不了解项目，怎么写程序？这是个问题。

敏捷实践中，有一个叫做Pair Programming的，从字面上来看，就是两个人一起开发。对于ThoughtWorker们来说，Pair是一种常态。所以，我在开发时也会有一个Pair，虽然我对项目一头雾水，但我的Pair已经在这个项目上工作了很长一段时间，所以，他很清楚这个项目的一切，差不多一切，因为代码是集体所有，所以，他在开发过程中会接触到各个部分。

拿到我们要做的Story，我的Pair会结合这个Story给我介绍上下文，并结合代码大致描述一下我们要做的事情。虽然在这个项目上我是新手，但我并不是对编程一无所知。有了这些基本的信息，我至少对我们要做什么，以及如何来做，在心里已经形成了一个大致的印象。刚开始时，基本上是我的Pair在主导开发，一边做一边告诉我，我们已经走到了哪里。渐渐的，我已经对我们在做的代码有了一些认识，开发也开始由一个人主导转向两个人讨论。随着开发的深入，我也发现了现有做法的一些不足，于是，我提出对代码进行重构，并给出了自己的分析和建议。我的Pair在听了之后，认为这是一个可行的建议，于是，我们毫不留情的将那段大家看着不舒服的代码改掉，这段代码从此清净了。

这就是在加入项目前几天所做的事情，虽然我目前还不能对整个项目有个很好的把握，但是，我相信，我已经开始在这个项目中起作用了。我想，Pair Programming是主要原因。正如前面所说，虽然我对项目很无知，但我的Pair很好的弥补了我的不足。正是两个人的协调工作，让我可以在对项目没有完整认识的情况下，可以很快入门，以最快的速度融入到开发之中。

曾几何时，我对Pair Programming的认识还停留在大家一起写程序和知识分享上，原来它对半路出家的人帮助也很大。虽然《人月神话》教导我们说，加人起不了很大的作用，但Pair的方式至少可以在相当大的程度上发挥新人的价值，削弱加人带来的负面影响。

使用Java实现内部领域特定语言
One Lair and Twenty Ruby DSLs
Implementing an Internal DSL

上面几个文章都是关于DSL的，不过，在这里，我并不是太关心DSL的话题，我更感兴趣的是代码的写法。按照这几篇的分类方法，直接用程序设计语言编写的DSL算是内部DSL，也就是说，所谓内部DSL，也就是一种标准的程序代码。

Kent Beck在他的《Implementation Patterns》的第三章《A Theory Of Programming》中，谈到了编程的价值观（Value）：Communication（沟通）、Simplicity（简单）和Flexibility（灵活）。如果说简单和灵活很容易理解的话，那么把沟通放在价值观中，尤其排在所有价值观的第一位，则显现出Kent Beck对于编程的深刻。在这个软件开发越来越需要协作的年代，写代码的时候，多站在让别人理解的角度考虑一下，会极大提升代码的可读性。在ThoughtWorks的招聘流程中，有一个Code Review的环节，拜这个环节所赐，我看过很多人的代码，不在少数的应聘者其代码唯一的优点就是完成了需求。以沟通为标准进行衡量，这显然是不够的。

同样，以沟通为标准，那么内部DSL显然在这方面做得更好，因为DSL本身就是为了让人更容易理解而存在的。这几篇文章中提供了很多内部DSL的手法，比如Method Chaining、Expression Builder等等。抛开DSL这样的BuzzWord，这些方法应该属于增强程序本身表达能力的方法。

JDK有一个很好的Method Chaining的例子：StringBuffer的append方法。

StringBuffer sb = new StringBuffer();
sb.append("log1").append("log2").append("log3");

这样的写法显然比下面的写法更为简洁，尤其是需要往StringBuffer中添加很多内容的时候。

StringBuffer sb = new StringBuffer();
sb.append("log1");
sb.append("log2");
sb.append("log3");

在我看来，这些内部DSL技术为我们打开了一扇窗，它让我们在编写代码，尤其作为API提供的代码时，有了一个新的思考方向。当然，并不是一味的应用这些内部DSL技术就会写出好代码，作为一个有经验的软件开发人员，我们需要一定的鉴别能力，分辨出究竟怎样做才会真正的提高代码的“沟通”能力。

之前写过两篇关于程序设计语言表达的blog（1、2），虽然这篇不像那两篇一样讨论语言的差异，但也算是在语言表达能力上的探讨吧！

Weka，是一个用Java编写的数据挖掘软件。数据挖掘，从字面上来看，它是一个从数据中找寻有用信息的过程，不过，它涉及的内容很多，所以，这里借用“分类”这一面来说事。

分类，从名称上来看，再简单不过了，给你一样东西，给它分个类。你如何知道怎么分类呢？显然，这是基于你已有的经验。对于计算机而言，这种经验从何而来呢？只有让人来告诉它，也就是说，我们要拿一批数据训练计算机，经过训练的计算机，便具备了一定的识别能力，就可以完成一些简单的分类工作。现实中，可以用到分类的机会有很多，比如我之前，曾经参与过的一个项目就是用这种方法来做车辆的识别。

下面便是一段使用Weka完成一段分类程序。

import weka.classifiers.Classifier;
import weka.classifiers.bayes.NaiveBayesMultinomial;
import weka.core.Attribute;
import weka.core.FastVector;
import weka.core.Instance;
import weka.core.Instances;
import weka.filters.Filter;
import weka.filters.unsupervised.attribute.StringToWordVector;

public class Main {
  private static final String GOOD = "G";
  private static final String BAD = "B";
    
  private static final String CATEGORY = "category";
  private static final String TEXT = "text";
    
  private static final int INIT_CAPACITY = 100;
    
  private static final String[][] TRAINING_DATA = {
    {"Good", GOOD},
    {"Wonderful", GOOD},
    {"Cool", GOOD},
    {"Bad", BAD},
    {"Disaster", BAD},
    {"Terrible", BAD}
  };
    
  private static final String TEST_DATA = "Good";
    
  private static Filter filter = new StringToWordVector();
  private static Classifier classifier = new NaiveBayesMultinomial();
    
  public static void main(String[] args) throws Exception {
    FastVector categories = new FastVector();
    categories.addElement(GOOD);
    categories.addElement(BAD);

    FastVector attributes = new FastVector();
    attributes.addElement(new Attribute(TEXT, (FastVector)null));
    attributes.addElement(new Attribute(CATEGORY, categories));

    Instances instances = new Instances("Weka", attributes, INIT_CAPACITY);
    instances.setClassIndex(instances.numAttributes() - 1);
        
    for (String[] pair : TRAINING_DATA) {
      String text = pair[0];
      String category = pair[1];

      Instance instance = createInstanceByText(instances, text);
      instance.setClassValue(category);
      instances.add(instance);
    }
        
    filter.setInputFormat(instances);
    Instances filteredInstances = Filter.useFilter(instances, filter);
    classifier.buildClassifier(filteredInstances);

    // Test
    String testText = TEST_DATA;
    Instance testInstance = createTestInstance(instances.stringFreeStructure(), testText);

    double predicted = classifier.classifyInstance(testInstance);
    String category = instances.classAttribute().value((int)predicted);
    System.out.println(category);
  }
    
  private static Instance createInstanceByText(Instances data, String text) {
    Attribute textAtt = data.attribute(TEXT);
    int index = textAtt.addStringValue(text);

    Instance instance = new Instance(2);
    instance.setValue(textAtt, index);
    instance.setDataset(data);

    return instance;
  }
    
  private static Instance createTestInstance(Instances data, String text) throws Exception {
    Instance testInstance = createInstanceByText(data, text);
    filter.input(testInstance);
    return filter.output();
  }
}

这个程序分成两个大部分，前半部分用以训练分类器，后半部分则是测试这个分类器。

训练分类器，我们要做的包括，选择分类算法和准备训练数据。在Weka中，每一种分类算法都是Classifier的一个子类，这样的话，就可以在不改变其它部分的情况下，很容易的修改分类算法。

其实，稍微了解一下这方面的知识的人，都会知道，分类算法固然重要，但真正决定一个分类器本事大小的，是用以训练的数据。想要得到一个好的分类器，少不了不断调整训练数据和不断的训练。这同人类认识问题是一样的，经得多，见得广，才有更好的分辨能力。

在Weka中，用以训练的数据就是Instances，顾名思义，这是Instance的复数，显而易见，单独的一个训练数据就是Instance，而Instances这个类的存在，可以把Instance的一些公共的属性放到一起。在这里，我们可以看到，为了用文本作为训练数据，我们会把文本转换为Instance。同样，测试分类器的时候，我们也会把文本转换为一个Instance，然后再进行分类。

除此之外，这里还有一个Filter的概念，同常见的filter概念类似，它给了我们一个进行正式处理之前，对数据进行处理的机会。在这里，主要是对Instance做一些相关的变换。

当我们得到一个分类器之后，就可以利用这个分类器进行分类了，其中，最关键的代码是
    classifier.classifyInstance(testInstance);
这段代码返回的是根据分类算法计算结果得到的一个相似度，我们可以利用这个值来估计我们测试用的数据应该属于哪个分类。

从代码上来说，这段代码本身并不复杂。正如前面所说，一个好的分类器是需要让数据帮忙的。所以，换几个测试数据，你就会发现，这段代码中实现的分类器一点都不强大。如果希望它强大起来，扩展训练数据是一个必然的结果。不过，对于这篇blog而言，这不重要，因为我们只是要和Weka问个好，进一步的工作，还需要进一步的努力。