• 刚刚结束了一个项目,个人觉得颇有意思的一个项目,记录一些发生过的事情,算作备忘。

    这是一个互联网金融的项目,P2P借贷相关,也许有人知道,就是搭建一个借贷平台,个人对个人借款。这个项目大幅度刷新了我对投资理财的一些观念,让我个人受益匪浅。但是,投资这种事,肯定是有风险的,自己想好,所以,我不会特别鼓励别人投资,只会和一些周边的人私下交流。只有几点特别提示,做这种P2P投资,要看背后的平台,发展历史,利率越高,风险越大。

    说一些与做软件相关的吧。

    这是一个金融项目,金融项目时间相关性非常强,这个特性刚好与做敏捷不谋而合。举个例子,我们这个项目第一阶段,做了借款相关的业务流程,而还款部分,我们一开始只处理了提前全额还款这一种情况。为什么?因为这个系统上线后,最早的正常还款、逾期还款等情况,最早要在一个月以后出现,只有提前全额还款可能在第一个月内发生,所以,在第一期上线之后,我们还有一个月时间去处理正常还款等情况。

    只做当前优先级最高的,这就是敏捷软件开发的思路。我们还开发了一个理财计划的方案,采用了同样的思路,上线之初,我们只做用户购买理财计划,至于到期赎回,一开始根本没有做,因为根据产品的特点,最早的赎回会发生在6个月后,只要能在6个月内把赎回开发出来就够了。

    根据客户的反馈,这次合作开发给他们留下印象最深的并不是代码或是技术能力,而是我们帮他们打造出了一个有特点的团队。合作之初,客户的开发团队还没有组建起来,只有一两个人,在双方合作的过程中,他们的新团队成员才逐渐加入进来。我们的合作模式也在这个过程中不断调整,第一期,我们的开发团队负责了所有的开发,第二期,客户的团队开始介入开发,负责一些边缘业务的开发,我们依然是开发主体,第三期,双方当做一个团队,平分主要业务的开发,第四期,他们成了主力,我们则只负责一些边缘业务的开发,至此,客户完全把项目接了过去。

    相比于单纯的业务开发,客户开发团队的开发方式完全遵从了我们的方式。通过每天的代码评审,我们共同分享着对整洁的理解。因为工作时间比大多数人长,我一直在这个过程中扮演着恶人,很多人辛辛苦苦写了一天的代码,到最后都批得一无是处,不得不拿回去重写。犹记得当时,许多人都很不理解我为什么要求这么严格,但几个月下来,大家都认同了好代码,最初的不理解只是因为从来没有人这么要求过。在合作过程中,他们见识了怎么去做自动化,怎么用git管理源码和发布,认识到了测试的重要性。有了这些基础,发布不再是战战兢兢如履薄冰。

    这些习惯闷着头干活的人,经过几个月的合作,已经变得开朗了许多,彼此肆无忌惮地开着玩笑,欢声笑语多了起来。每天下午4点,准时有人号召大家做平板支撑,最厉害的家伙甚至可以一次性撑个五六分钟。桌子上的技术书多了起来,这是他们的技术经理给大家买的。有不少人购买了Kindle,把它用在了上下班的路上。我们还给他们定期做了一些分享,各个方面,从前端到后端,从安全到构建。

    相比于从前几个月的出差,这次的时间过得飞快,我打心眼里喜欢这个项目,它让我有所学,更重要的是,有一群有趣的人,这样的合作是值得记录的。

  • 有一种说法,人对时间的感觉取决于时间相对于整个生命的比例,所以,小时候,我们会觉得一天很长,而年纪越大,觉得时间越快。生命长了,比例降低了。超过30岁以后,一年的光阴也开始转瞬即逝了。

    2014年已经到了最后一天,于我而言,这是相对平淡,却也奔波的一年。

    很多事情都是之前的继续,比如Moco,我还在继续写,为一个开源项目坚持超过两年,我越发佩服自己的耐性了。只不过,发布周期由原来的三个月变成了五个月。每天在github上提交至少一次代码已经成了我日常生活的一部分。看着越来越多的项目因为我的这份坚持而受益,心里还是很高兴的。

    在外演讲也是去年的继续,4月份北京的QCon是2013年就答应了的,7月份WOT是Moco给我的机会。倒是10月份上海的QCon,专题出品人对我而言,是一个新鲜的角色,这个角色算不上很成功,因为我的坚持,在这个主题里引入了很多全新的内容,对听众的吸引力要差一些,但我依然坚信,应该让更多的人了解这些“新”东西,让开发世界进化得再快一点。

    2013年,我制定了读30本书的计划,结果读了52本书。2014年,我的目标是52本,也就是一个星期一本,结果读到82本,这完全出乎了我的意料。一些朋友问我,读这么多书,能记住吗?实际上,我压根也没打算记住所有的内容。读书的目的是为了思考,在阅读的过程中,让文字和自己的思维碰撞。最终留下的才是收获。尝试过每年读几十本书,我才知道,其实,我也不是每天抱着书本不放,如果每天早晚各坚持读半个小时书,一年下来就可以读很多书,大多数抱怨没时间读书的人,真的是没花时间读书。

    2014年读书多,另外一个很重要的原因是拜奔波所赐。这一年,我坐飞机超过30次,每个月都会出现在机场里,路上的时间很大一部分都献给书了。作为一个ThoughtWorker,这几乎就是正常工作的一部分,我的同事里有很多人比我坐飞机的次数还多,我是按月计算,有的人是按周计算。当然,常在岸边走的结果就是,2014年,我住了两回机场提供的宾馆,这也是之前没有经历过的。

    如果说2014年做了一件之前没做过的事情,应该算是组织了ThoughtWorks中国区内部的技术大会。准确地说,这也是2013年想法的一个延续。2013年,我就和现在ThoughtWorks的CEO郭晓谈到过这个想法,直到2014年,各方面因素都成熟了,才把这个活动做了起来。第一次是7月份在西安,第二次是11月份在成都。我个人是亲手策划组织了第一次的技术大会。整体来说,得到的评价还不错,大家也都希望这样的活动继续做下去。2015年已经为此申请了专门的预算,这也是我在ThoughtWorks内部第一次组织有预算的活动。

    2014年,在我的强烈要求下,我一直工作在国内项目,因为我实在想做一些自己能用得上的东西了,而海外交付的东西离我们的生活太远了,当然,这也在客观上决定了我的奔波。年初为一个大的快递公司做了一次网站改版,时至今日,每每我去查快递的时候,心里还有一种极大的成就感。下半年,我又参与到一个P2P网站的建设中,就是现在比较火爆的互联网金融项目。这个项目让我有机会深入理解了一下这个领域。当然,为了实践,我在其它几个网站上做了一些投资的。随着这个网站更加完善,我预期,我还是会多多尝试自己的项目。

    读书与行路,与更多的人交流,我的视野也在不断开阔,我已经开始尝试思考自己的未来几年,2015年,我希望有一些大的变化,让自己的人生有一些全新的体验。

  • 2014-12-03

    Moco 0.10.0发布

    Tag:moco

    前版信息:Moco 0.9.2发布

    我很高兴地宣布,Moco 0.10.0发布了。

    Moco是什么?

    Moco是一个可以轻松搭建测试服务器的框架/工具/程序库。

    变更

    本次发布最大的变更是加入了Socket的支持。

    除了HTTP,Socket是另一种常见的集成方式,对Socket的支持让Moco能够更为全面地对集成进行支持。创建一个Socket的服务器,可以采用socketServer:

      final SocketServer server = socketServer(12306);

    与HTTP支持类似,Socket服务器也是需要设定请求以及对应的应答:

      server.request(by("foo")).response("bar");

    与HTTP本身支持很多参数不同,Socket只支持与内容相关的部分,比如,text、file、xml、json、match、exist、latency、template等等。更多细节,请参见Socket API的文档

    因为增加了不同的服务器类型,Moco独立服务器的启动参数也有所调整,原来的一个start已经不足以满足需要了。在最新的版本中,你可以根据服务类型记性启动,比如,启动一个Socket服务器的方式如下:

      java -jar moco-runner--standalone.jar socket -p 12306 -c foo.json 

    HTTP和HTTPS服务器的启动参数分别对应着http和https,为了兼容原有版本,start依然得到保留,但不确定未来是否会长期存在下去。

    这个版本增加了一个许多人要求的新特性,在Java代码中可以使用JSON配置文件。这种用法与Moco设计JSON API的初衷有很大差别,但在实际的使用中,确实有很多人这么用,所以,在这个版本里提供了一个更简洁的API,不过,这个API存在于Moco Runner包中:

      jsonHttpServer(12306, file("foo.json"));

    在API方面,

    • 增加attachment API,直接对下载附件提供支持。
    • 增加了template提取器的支持,比如,如下代码就会从请求中提取内容作为应答返回值。
        server.response(template("${foo}", "foo", jsonPath("$.book.price")));

    在Moco独立服务器和shell版本,增加了版本查询功能,以便对一些外部工具进行支持。

    另外,由于JSON Path底层实现的升级,可能会引入一些破坏性的变化,如果你用到JSON Path API,请注意。

    更多发布相关信息,请参考Release Notes

    感谢

    感谢Alex Soto,提供Moco服务关闭的解决方案,增强了Moco服务器的稳定性。
    感谢方志刚,提供Moco的Shell版本在Cygwin下运行的支持。

  • 2014-11-30

    读《不敢止步》

    Tag:书评

    十几年前,我刚开始工作那会儿,我如饥似渴地找各种的与软件开发相关的材料来读,包括《程序员》杂志。于是,我注意了一个叫“透明”的家伙,写东西文笔很好。后来,因为讨论一些技术问题,我们俩就联系上了,然后,就把“熊节”,“透明”,“gigix”划上了等号。再后来,我加入了ThoughtWorks,第一次见到了活的熊节。

    我依然记得那天,我在新笔记本上装了Ubuntu,我问他怎么联网,他说,你上网,我传个驱动给你。汗……

    从那天开始,我们俩已经同事了七年半的时间,在很多项目上合作过,以ThoughtWorks如今的标准看,我们俩的合作次数和时间也算是很多了。我早就知道他在写一本书,关于他自己这十几年的故事,作为一个和他认识了十几年,共事了七年半的人,我也很好奇他会怎么写我。如今书出版了,我当然会读一下。

    于我而言,这是一本岁月随想,把我带回了那些过去的日子。我很自然地将书分成了两个部分,以他加入ThoughtWorks为界。

    即便是今天,我偶尔也会调侃熊节是搞媒体的。他做媒体人那段日子,恰逢软件开发世界风云突变,有很多大家不断争论的东西。是.NET还是Java,是EJB还是Without EJB,是瀑布还是敏捷。那些年,各路大神你来我往,各种观点风起云涌,争论很大,每个人都有自己的思考,不断地拓展着理解,即便是作为看客,也很过瘾。时至今日,虽然新技术依然层出不穷,但大方向已定,那种思维之争已一去不复返了。抑或是今天的人都忙着各自创新去了,没有闲做思维之辩了。对于错过那段历史的年轻程序员,这本书可以带着回到那个唇枪舌剑的年代。

    他加入ThoughtWorks之后的事情,我都知道。即便是在我加入之前的故事,这么多年吃饭聊天下来,也都听了几遍了。但是,跟着他一起回顾ThoughtWorks这么多年走下来的历程,也颇为感慨。其实,许多人不知道,ThoughtWorks中国区在最初的几年里,有几次已经危在旦夕了。直白地说,不赚钱。在那些不怎么赚钱的日子里,其实作为基层员工,大家活得还是很开心的,拼了命地研究各种各样的技术,经常会有神秘兮兮地跑过来,展示他刚刚做好的东西,那时候,招聘的标准也很高,几乎个个身怀绝技。后来,这些家伙几乎个顶个是现在公司的顶梁柱。

    为了生存,公司调整了方向,随之而来的就是规模的扩张,这也不断地挑战着这些“老员工”的思考方式。从只写代码到带人,甚至做管理,ThoughtWorks中国区的思路不断地调整着,这些老家伙们也不断改变着自己的角色。如今,最初的程序员,留在公司的,似乎只有我还在一线每天写代码了。其他更多人已经各方面的管理者了。即便是我,也干了很多跟程序不搭边的事,比如,郑大晔校。

    熊节在2012年去了成都,开辟新办公室。作为老战友,我也在下半年跑到成都支持他,一干就是一年半。以战绩论,成都的结果真是惊人,第一年就超过了西安办公室两年的发展速度,而且这样的高速一点都没有停下来的迹象。由程序员转成管理者,熊节做得还真不赖。这些年是ThoughtWorks不断发展变化的一段时间,所以,我们这些土鳖程序员为了支撑公司发展,不断地拓展着自己的视野和思路。随着一个公司长大,这样的机会不常有,现在更多的人加入多半是在享受发展的结果。当然,机会永远是有的,只要有心。

    我还是很贪心的,2013年并没有出现在这本书里,否则,我的Moco一定会位列其中,因为2013年,我们玩出了创新的新花样。后来,熊节去了非洲,支援其他办公室建设去了。

    抛开我和熊节熟人的关系不论,我个人还是很喜欢看这种个人发展的真实故事。尤其是像熊节这样的文笔写出来,一定是比较好看的。多谢熊节用这本书带我回忆那过去的事情。勘个误吧,至少关于我,也算是补充一下那段历史:

    • 2007年,敏捷中国大会,原本是我和Ola Bini一起讲东西,结果,他没来,我只好一个人上了。
    • 2008年,Starwood项目,关于IE上出Bug的故事,其实我用的是Dell笔记本,但是,装的是Ubuntu,所以,没发现IE的问题。
    • 2011年,熊节说他叫我去西安,可是,我2010年就已经转到了西安。
    • 2011年,索勤的故事,当时,我其实在墨尔本,那个时候的熊节不太相信人是可以培养的,而我则刚好相反。现在索勤已经是公司里面独挡一面的高手了。

    这其实算不上一篇书评,只是借着这本书,回想一下过去的日子罢了。我个人还有个期待,再过十年或是十二年,我希望看到这个故事的新篇章。

  • “default method”是Java 8引入的一个特性,其初衷是为了解决既有程序库扩展的问题。在之前的Java版本中,如果要给一个已有接口添加新方法,这会带来一些问题,因为新方法没有对应的实现,所以,实现这个接口的类就会编译不通过。而“default method”的引入给了方法一个实现,编译就可以通过了,从而我们可以在不改变已有代码的前提下,为程序库增加新的方法。

    但是,既然接口方法可以有实现,那它也给了我们另一种思路。

    在Java开发中,我们可能会经常面临一种情况。以Web开发为例,假设我们有一个领域对象Foo。

    class Foo {
      ...
    }

    我们有个需求,根据其某些属性决定是否在页面上隐藏它。你当然用一个类实现它,但在页面上是否隐藏它,显然不应该属于领域对象的一部分。所以,我们通常会用另外一个类封装它,比如HiddenableFoo。

    class HiddenableFoo extends Foo {
      boolean isHidden() {
        ...
      }
    }

    好,新需求来了,我们要在页面上决定是否要给它的名字加粗,于是,这个类就成了HiddenableBoldableFoo。

    class HiddenableBoldableFoo extends HiddenableFoo {
      boolean isBold() {
        ...
      }
    }

    这里其实有个问题,为什么不是先由BoldableFoo,然后,从它继承呢?我们暂且不关心这个细节。

    又有一个需求来了,在另一个页面,我们需要确定这个对象是否需要隐藏以及是否需要斜体:

    class HiddenableItalicableFoo extends HiddenableFoo {
      boolean isItablic() {
        ...
      }
    }

    又有一个页面,需要的判断一下某些地方是否要加粗,某些地方判断要斜体,那这个类要怎么做呢?

    class BoldableItalicableFoo {
      boolean isBold() {
        ...
      }

      boolean isItablic() {
        ...
      }
    }

    如果这里的isBold和isItablic与前面的实现是一样的,是不是重复代码就此出现了呢?这就是在Java 8之前,我们面对的问题,我们可以继承接口,但实现不成。

    Java 8来了,“default method”就给了我们一个机会,让我们可以继承实现。下面是一种实现:

    interface Fooable {
      ...
    }

    class Foo implments Fooable {
      ...
    }

    interface Hiddenable extends Fooable {
      default boolean isHidden() {
        ...
      }
    }

    interface Boldable extends Fooable {
      default boolean isBold() {
        ...
      }
    }

    interface Italicable extends Fooable {
      default boolean isItablic() {
        ...
      }
    }

    这里之所以引入一个Fooable接口,因为接口只能继承接口。有了这样的基础,我们就可以自由组合了,比如:

    class HiddenableBoldableItalicableFoo extends Foo implements Hiddenable, Boldable, Italicable {
    }

    如果你熟悉Ruby,这俨然就是Mixin,对于Scala粉丝来说,Trait已然呼之欲出,C++人则会看到多重继承的影子。是的,所有这些语言特性背后都有一个共同的理念:面向组合的编程。

    Trygve Reenskaug和James Coplien在2009年提出的DCI架构,它是一种很好的面向对象编程的视角,其基础就是这种面向组合编程的理念。DCI架构在Java社区里面一直没有很好的讨论,也是因为Java语言没有给力的支持。

    诚如前面所说,Java语言之前是不支持面向组合编程的,但是,在Java社区里,有人不断地做着这方面的探索,Rickard Oberg,这个前JBoss架构师,实现了一个Qi4J的框架。不过,现在Java语言本身也可以这么做了。

    当然,相比于其它的语言,Java在这方面的表现力是有限的,因为它的基础是接口,所以:

    • 它不能有字段
    • 所有方法只能是public的

    另外,组合只能是基于类来做,就像HiddenableBoldableItalicableFoo,虽然这个类除了声明什么都没有。相比于Ruby的Mixin这种可以在运行时扩展的特性,更是表现力要弱了许多。

    但与之前的版本相比,Java算是在这个方面迈了一步,至少我们可以不用再为同一份代码多处出现而纠结了。