REST, Groovy, Behavior Driven Development, and Other Things Changing How I Approach My Work

January 26, 2007

Every few years, I learn a new approach to software development or a new set of tools, that once mastered, leaves me thinking that I finally really understand how to do my job. Instead of being concerned that up to that point I hadn’t really known what I was doing, I am reassured that now, finally, I have a firm grasp of whatever it is that I think I should be doing. But, as I said, I seem to go through this every few years, and as I’ve discussed this with other software developers, it seems that I am not alone.

I have come to look forward to these periods of graduated evolution in my career, and I think that perhaps by the end of 2007, I may have completed another of these phases. So, in this post, rather than embarrass myself making belated predictions for what will be hot in 2007, and almost certainly getting it wrong, I’d like to reflect on a few things the value of which I have slowly begun to realize and which I would like to incorporate into my development practices in the near future.

REST, again

I guess I will start with REST, which has been discussed so much in the blogosphere recently that I had to take notice. As a long time Java developer, this style of application design seemed to go against some pretty fundamental, accepted practices I have learned over the years, such as action based controllers for example. It initially seemed to me that analogous to the object-relation impedance mismatch, controllers would be managing an HTTP-object impedance mismatch with the REST approach.

I am slowly warming to REST, however, at least in terms of designing Web applications. I’ve come to believe that a RESTful application can take a more logical and natural approach to the design of the controller layer in Web applications, and is in fact more true to the OO approach, than say a typical EJB based application, a technology I have always thought was tremendously wrong-headed. In fact, I have come to think of the two approaches as being the complete opposite of one another in certain fundamental aspects.

I am not convinced that a REST approach is always the better alternative to SOAP or XML/RPC based Web Services, although I am willing to be further convinced of this too. There are examples of successful Web Services, in many of these cases, to facilitate a remote call paradigm of a small set of functions on a rather large, black-box component. Also, I think there are cases in which the interaction between the client and the service may be complex enough that a SOAP based Web service may actually be the simpler, more natural implementation.

That said, I have recently entertained the idea of rewriting four SOAP based Web Services I created not long ago as a simple authenticated REST application. As with many things in Java, I relied on tool support (Apache Axis) to make short work of exposing four functions of an otherwise completely server based application as SOAP services. It just so happens that the four functions are CRUD functions. Also, in my organization, we use several development environments, and I am one of only a small handful of people who know Java. Originally, I thought the SOAP approach would allow universal access to this resource, as I think every major language has tools to create client stubs from WSDL output, but then, basic HTTP access to a simple set of Java servlets, without the SOAP layer, is easier still.

Several resources have helped me reach the “aha!” point with REST: Resource-oriented vs. Activity-Oriented Web Services is an excellent overview of REST vs. SOAP/XML-RPC, while Building Web Services the REST Way and How to create a REST protocol are both excellent resources for designing applications RESTfully. I have also signed up to read pre-print chapters of REST Web Services by Leonard Richardson and Sam Ruby, so you can probably look forward to my thoughts on this book in future posts.


On the subject of bridging the gap between Java and other languages in my organization, I have recently reacquainted myself with Groovy. I first looked at Groovy several years ago when it was first released, but I already knew Jython and was also aware of criticisms of Groovy at the time. I was quite surprised when Groovy became a Java standard some time later, and as such, version 1.0 was released just a few weeks ago. In the meantime, Jython has slowly fallen out of favor, despite its surprisingly wide adoption at one point.

Now, learning and using Groovy would be incredibly fun for me, and a refreshing change of pace from normal Java programming, but more than that, I am thinking that this would allow others in my organization, who would not otherwise use Java, to more comfortably take advantage of the IDE’s and open source libraries and applications that the Java platform provides. The truth is that Java has always valued academic correctness over developer productivity, and if I hadn’t learned Java when I did, about ten years ago, before there were so many layers of XML standards for example, I would scoff at it now. In fact, a few years ago, I seriously considered dropping Java development entirely (as much as I could) for Python–this was at a time when Java was in somewhat of a crisis anyway. But the tool support for Java and the presence of so many open source frameworks and libraries is what I believe kept Java going, and kept developers productive, and it still separates Java from every other language today. Perhaps Groovy can give us the best of both worlds. Another selling point among the other developers in my organization might be Grails, a Ruby On Rails inspired framework for Groovy. (Its also interesting to see that JRuby seems to be getting a lot of attention lately.)

Behavior Driven Development

I stumbled across the term behavior driven development (BDD) in a blog post to which I have long since lost the link, but as a practitioner of test driven development (TDD), it intrigued me. After reading the Wikipedia entry for it, however, I was left with the feeling that the difference between BDD and TDD was extremely subtle. I wasn’t getting it.

Dan North’s explanation of how BDD evolved finally gave me the “aha!” moment I needed to begin understanding BDD. I also highly recommend the wiki at

I am still unclear how this approach would fit into my current TDD worldview, but I am intrigued enough by the idea to begin exploring this approach and its implications on my next project. As I do, I will undoubtedly want to share my misinformation on this blog.

Final Thoughts

Speaking of “aha!” moments, I recently read Effective Java Exceptions by Barry Ruzek, and although Barry doesn’t come to conclusions I would describe as earth shattering–he advises among other things that exceptions should be softened and treated as aspects, although his discussion of a “fault barrier pattern” didn’t sound familiar to me–what he does is frame the discussion in the clearest way I have ever read, giving me a new appreciation for how to properly design exception handling in a Java application (with a great deal of transference to Python) and why. Its an extremely logical and even handed article, easy to read and with a lot of practical advice. In fact I think its not only easy enough for a Java newbie to grasp, but I also think that experienced Java developers, who may already feel like they have mastered the finer points of exception handling, can find significant value in this article.

Last year at this time, I was seriously looking into FIT testing, but then also started reading about Selenium. I have not been very active in Web development lately, but when I return to it shortly, I think that Selenium would be the better fit for testing Web applications through the browser and complement the unit testing I would already be doing. Interestingly, Selenium has both a Firefox plugin as well as language bindings to Python and Ruby, so it seems poised to be something that both Django and Rails folks can agree on.

Of course, I have been getting my feet wet with Django, and am looking forward to really delving into it more deeply soon. (From what I can see, Django encourages a RESTful approach to application development.) I think I will also need to start using Firebug which looks like it will make Web development much more enjoyable. And finally, I think its about time I started transitioning from CVS to Subversion, and catch up with the rest of the world.

So, what software development oriented new years resolutions have you made? What article have you read recently that changed your perspective on something? Take a moment to leave a comment and let me know about it.


No comments yet.

Sorry, the comment form is closed at this time.