• 2013-08-01

    Moco 0.8.1发布

    Tag:moco

    前版信息:Moco 0.8发布

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

    Moco是什么?

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

    变更

    这次是一个小的版本发布,没有特性上的任何变更。

    本次发布主要是修复了一个Proxy实现中的一个bug:如果客户端发起的请求中包含了Host这个Header,转发到某些服务器会造成这些服务器无法返回正确的结果。

    除此之外,一个重大的调整是把底层实现由Netty 3换成了Netty 4。

    Netty 3到Netty 4是一个非常大的版本升级,几乎所有API都做了调整。这样的升级带来了更流畅的API,更好的性能,更好的模块划分。

    感谢

    感谢李毅,发现并修复了Proxy实现中的bug。

  • 2013-07-30

    JavaONE上海流水账

    Tag:JavaONE

    感谢Moco,我有机会作为Duke选择奖的获奖者参与JavaONE

    JavaONE大会的主题演讲是几个人概要介绍一下Java最近的发展,很高层的那种。真正给我留下深刻印象的是Jim Weaver,一个很有趣的老头,他是JavaFX方面的专家。他演示了一个用JavaFX实现的吉它,甚至现场演奏了《栀子花开》,引爆全场。他就像一个老顽童一样,他开了一个微博,在现场招募粉丝,还能说出,“给力able”这样的单词。感谢他在众多无趣的主题演讲中带来了一丝欢乐。

    Java EE 7,是这次很重要的一个话题,因为它刚刚发布不久。不过,要知道,标准这个东西总是落后于开发现状的,只有当一个东西很火时,它才会被考虑放到标准里。所以,如果你的开发一直在使用比较流行的技术,那Java EE 7几乎没有什么太新鲜的东西。在最重要特性的排名里,只有前几项是所谓的新技术,比如Web Socket、批处理、JSON处理和并发。后面大多是已有技术的改进和增强。

    Bert Ertman做了一个有趣的分享,把Spring的程序迁移回Java EE。我在之前碰巧和他坐在一起,聊了一下他准备这个话题的原因。在他看来,自从J2EE伤了众人心之后,现在已经很多人不那么关注Java EE了,而转向Spring,可现在Java EE已经有了很多新的发展,不再是从前那个笨拙了,所以,遵循标准总是要好一些。这也是我特意跑去听他怎样讲的一个原因。确实Java EE进步了不少,但从个人开发的审美上,JavaEE总是依赖于容器这个事情还是让我觉得不爽,尤其在测试上。虽然可以用Arquillian这样的工具帮忙,我还是持保留意见。

    最出乎我意料的是一个session是一个关于Nashorn的,这是一个JavaScript引擎。我原本意味它是介绍JavaScript的,结果却是在讲InvokeDynamic这个JVM的新指令,然后,以一段简单的JavaScript为例,介绍使用InvokeDynamic怎样实现,至于Nashorn,就是一个依赖于新指令的JavaScript引擎。我一直知道InvokeDynamic,但一直没有太深入地了解它,这个session帮我理清了InvokeDynamic的基本思路。

    还一些有意思的session。10gen的人讲MongoDB Java API设计中向后兼容性的问题。从我的角度看来,很多人在设计API时,更多的是直觉映射,还没有怎样设计API才更可用。显然,新版本的MongoDB API已经改善了很多。Oracle的人讲Lambda,作为已经比较了解Java 8 Lambda的人,我看得出,讲的人还是准备了很多东西,只不过,这个人不常出来讲东西,现场表现力和讲东西的清晰程度还有待提高。不过,我还是很喜欢他讲的内容的。TypeSafe的人讲Akka。Akka基本上算是一种企业级Actor的实现,稳定性、扩展性、监控性都要好于Scala自带的Actor。

    还有几个观察,JavaFX和Raspberry Pi是Oracle很看重的两个领域。其中,JavaFX是为了改善Java在富客户端表现不力的局面,这次的JavaONE有不少JavaFX的主题,包括一些3D的支持。但至少目前为止,用Java做富客户端还不是主流,JavaFX还有很长的路要走,虽然Oracle还在大力地鼓吹。我的一个同对JavaFX很感兴趣,但他也觉得,如果让每个客户端都额外装一个Java运行时,恐怕还是很大的负担。

    Raspberry Pi是一个很有意思的事,除了人所共知的平台外,Java 8最先移植的平台就是Raspberry Pi。为什么Oracle会在这个新型硬件上投入许多,我特意就这个问题咨询了Simon Ritter,Oracle的Java技术传播者,他说,Raspberry Pi很便宜,这可以让Java技术更好地传播,另一方面,Raspberry Pi的基础架构和普通的PC很像,移植工作相对于其它平台会简单一些。我看还有一点,Raspberry Pi是ARM架构,这也会是Java未来拓展ARM平台的一步探索。

    我遇到了台湾JUG的负责人。我们在一起交流了一下两岸程序员的差异。原来在台湾,更多的受重视是做硬件的厂商,最近几年做软件得到的重视才越来越多。不过,基本上面临的问题与大陆大同小异,对于软件开发质量的不重视,造成很多误工在里面。就程序员这个职业而言,台湾与北上广就消费和收入方面,已经差不多了,原来有不少台湾厂商把工作放到大陆来做,现在基本上已经看不到,因为成本在提升。

    这次参加大会还认识了不少人,尤其是还听说大众点评网在试用Moco,着实让我高兴了一番。

  • 2013-07-21

    Moco 0.8发布

    Tag:moco

    前版信息:Moco 0.7发布

    我很高兴地宣布,Moco第二个正式版本0.8发布了。

    Moco是什么?

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

    特性变更

    本次发布有一个重大的新特性,支持工程配置文件(Global Settings)。

    我们可以通过它,将一个复杂的Moco配置文件分解成多个配置,然后,通过这个配置文件将它整合起来:

    [
       {
           "include" : "foo.json"
       },
       {
           "include" : "bar.json"
       }
    ]  
    (settings.json)

    这个配置文件还支持几个不同的选项,让我们在开发时有更灵活的变化:

    • 支持Context:我们可以把不同的服务,部署到不同的context路径下,实现由一个Moco服务器,模拟多个服务。
    • 支持File Root:我们可以配置文件根目录,这样一来,每个具体配置文件内,所有与文件相关的路径都可以写成相对路径。
    • 支持Environment:通过指定环境变量,同一套配置在不同的环境下,由不同的部分起作用,这样就可以开发代码无需任何调整,就可以得到不同的效果。

    本次还包含一些API的变化:

    • Proxy:可以将请求(包括请求的所有信息,比如内容、头灯)转发给另一个服务器,还可以通过配置failover文件,用以故障恢复,在远程服务器失败,无法返回时,从failover文件中提取请求内容进行返回。目前failover文件是JSON格式,可以手工编辑。
    • JSONPath:请求内容按照JSONPath进行匹配。
    • with:在API上增加with,用以进行Resource到ResponseHandler的适配。
    • 移除url:用Proxy代替。
    • 移除cache:用failover代替。
    • 移除content:用with代替。

    本次发布还有一个实验性的新特性:模板,用以根据请求定制应答。目前包含有

    • 请求版本:${req.version}
    • 请求方法:${req.method}
    • 查询参数:${req.queries['foo']}
    • 请求头部:${req.headers['foo']}
    • 请求内容:${req.content}

    这个特性还在进一步探索中,欢迎反馈各种问题。

    感谢

    感谢nezhazheng,为Moco贡献JSONPath实现。

  • 你应该更新的Java知识之常用程序库(一)
    你应该更新的Java知识之常用程序库(二)
    你应该更新的Java知识之构建工具
    你应该更新的Java知识之Observer
    你应该更新的Java知识之集合初始化
    你应该更新的Java知识之集合操作

    在开发中,我们经常会遇到一些需要延迟计算的情形,比如某些运算非常消耗资源,如果提前算出来却没有用到,会得不偿失。在计算机科学中,有个专门的术语形容它:惰性求值。惰性求值是一种求值策略,也就是把求值延迟到真正需要的时候。

    在Java里,我们有一个专门的设计模式几乎就是为了处理这种情形而生的:Proxy。不过,现在我们有了新的选择:Supplier。

    我们先来看看Supplier的定义:

    public interface Supplier {
     T get();
    }

    非常简单的一个定义,简而言之,得到一个对象。

    但它有什么用呢?我们可以把耗资源运算放到get方法里,在程序里,我们传递的是Supplier对象,直到调用get方法时,运算才会执行。这就是所谓的惰性求值。

    对于Java这种缺乏惰性求值的语言,惰性一般就是通过一个间接层来实现的。David Wheeler曾经说过:“计算机科学中的所有问题都可以通过引入一个间接层解决。”

    理解了基本的用法,实现一个Supplier并不困难:

    Supplier ultimateAnswerSupplier = new Supplier() {
     @Override
     public Integer get() {
       // Long time computation
       return 42;          
     }
    };

    当我们需要这个终极答案时,只要

    int ultimateAnswer = ultimateAnswerSupplier.get();

    确实很简单,但是,我知道你已经心生另一个疑问。通常实现Proxy模式,我们只会计算一次,像终极答案这样的东西,反复运算我们可承受不起,也没有必要。

    我甚至知道你已经迫不及待地打算动手实现自己的解决方案,把结果保留下来,再下次调用时,直接返回结果。但,且慢。

    不,我并不是说多线程并发让保存结果这件小事变得复杂,因为我相信你的能力。但你是否想过,如果你打算为它这么做,也就意味着,你几乎要为所有的Supplier对象这么做。反复做一件事,显然不应该是一个程序员的作为。

    幸好Guava已经给我们准备好了:

    memorizedUltimateAnswerSupplier = Suppliers.memoize(ultimateAnswerSupplier);

    memoize函数帮我打点了前面所说的那些事情:第一次get()的时候,它会调用真正Supplier,得到结果并保存下来,下次再访问就返回这个保存下来的值。

    有时候,这个值只在一段时间内是有效的,你知道我要说什么了,Guava还给我们提供了一个另一个函数,让我们可以设定过期时间:

    expirableUltimateAnswerSupplier = memoizeWithExpiration(target, 100, NANOSECONDS);

    好了,还在自己编写Proxy处理惰性求值吗?Supplier便是你需要更新的Java知识。顺便说一下,Java 8里也有Supplier哦!

  • 今年年初,我给自己定下的读书目标是30本,于今,时间过半,完成度是24本,下半年还要读完至少6本。与以往最大的不同是,今年的许多书读的是电子版。

    对电子阅读的兴趣始于一些阅读平台的兴起。而其中,购买方式的简化,让阅读更加简单。相比于最初的电子阅读器,如今这些阅读平台做得都很好,我们不再需要四处寻找图书的文件,再想办法复制到阅读器里,只要阅读平台买了书,然后,就可以同步到自己的阅读器中,即可开启自己的阅读之旅。

    现在主流的电子书阅读平台包括,多看字节社豆瓣阅读Kindle。在上半年读完的书里,刚好每个平台都有涉及,分别是:

    其中前三个,都有几个平台的客户端(包括iPhone、iPad和Android)。单纯从阅读器软件上看,多看和字节社做得都很好,豆瓣阅读则不是第一眼美女。但从结果上你看到,我目前在豆瓣阅读上读的书最多。豆瓣阅读一如豆瓣的其它产品,简单是其最大特点,相比于其它二者,它更可以让人心无旁骛地阅读。

    但从阅读的角度说,更好的选择应该是Kindle。这里说的不是Kindle软件,而是Kindle设备。无论是iPhone,还是iPad,抑或是其它Android设备,最大的问题就是能做的事太多了,容易让人分心。除此之外,相比各种pad,Kindle Paperwhite更轻薄,而相对手机,屏幕又很大,读起书来非常有感觉。加上今年Kindle的中国商店正式上市,选择一个Kindle Paperwhite专心读书是个很不错的选择。

    之所以在Kindle上半年读完的书并不多,只是因为时间尚短。个人现在的倾向是,以后在Kindle上读更多的书。

    相对而言,电子书的价格比纸书低很多,用几块钱买一本几十块的钱数还是能够承受得起的。而且,现在明显处于一个推广期,各个平台经常会有限免或特价的活动,比如,多看每天会有一本限免书,而Kindle则每天有本特价书。正是因为价格不高,我也就买了一些正版书籍,避免盗版,省去了找文件,拷文件的过程。

    目前而言,电子阅读平台上的内容还不够多,尤其是软件开发相关的图书数量有限。不过,随着电子书逐渐普及,这方面会逐渐得到改善的。

    当然,无论有怎样的平台,怎么便利的购买手段,排在第一位的考量永远应该是读书,否则,实体书那种只买不读的往日荣光又回复现于电子平台。