The Disco Blog

I’m a big fan of writing as little code as possible and borrowing everything else. I’m also a big fan of Groovy. I recently had the pleasure of reading Chris Judd, Joseph Nusairat, and James Shingler’s hip “Beginning Groovy and Grails” and in short, I loved it! This book is all about borrowing a slick web framework (and a lot of plug-ins) and leveraging the power and simplicity of Groovy to build web applications quickly.

I used this book extensively to build three different Grails applications and I found that the authors essentially covered everything one would need to it successfully. The first three chapters cover the basics of Groovy nicely, then the book dives head first into Grails with 12 valuable chapters covering GORM, Services, and using various plug-ins. Plus they cover deploying Grails applications, Ajax, and even do some cool stuff with JasperReports. I really liked how they consistently built upon a sample application throughout the entire book– that made comprehending what was going on a bit easier as you, as the reader, didn’t need to re-understand the domain.

In particular, chapters 7 and 8 proved quite helpful as they cover both security and Ajax. I did find myself wishing that the Acegi section went a bit deeper — I ultimately found myself adopting a JCaptcha solution as it proved to be a lot easier; regardless, their in-depth covering of all things related to security broadened my knowledge of the options available in Grails. I ended up using some Ajax components not covered in their Ajax section; however, they do a great job of adding some slick features to an application they build from scratch throughout the book.

I was hoping the Web Services chapter would go a bit deeper as I’m hoping Grails can become a widely adopted option for building RESTful applications; nonetheless, they do a great job of adding the essential CRUD operations to their example application. Plus they tie everything together nicely in the last chapter– 13.

If you are looking to learn Grails quickly, because it’s my bag, I can’t recommend this book enough– it covers designing, building, and deploying a Grails web application and it does so by continually building upon an ongoing application. It doesn’t matter if you don’t have a command of Groovy either, as they do a great job in the beginning and throughout the book of demonstrating Groovy’s essence.

There are various statistics related to the average defect density (i.e. how many defects one can expect to find in a code base); suffice to say, the numbers point to unhip ranges like

20 to 30 bugs for every 1,000 lines of code

and even

100–250 defects per thousand lines of code

Given this amazingly horrible data, what is one to do about it? There are a few possible answers, including:

• Write a lot of tests
• Write better code
• Write less code

The first choice is rather noble; however, it turns out to be a Herculean effort (to say the least) and therefore, few teams actually do it. Writing more hip code is a great idea– there are tons of resources related to writing better code (Robert C. Martin’s “Clean Code: A Handbook of Agile Software Craftsmanship” comes to mind) and I highly recommend teams strive to embrace the craft of coding. In spite of that, I have an alternate suggestion: write fewer lines of code.

If the average application has anywhere from 2 to 25 bugs per 100 lines (oh my goodness that’s an enormous number!) doesn’t make sense to write fewer lines of code? Of course! The question then becomes, how do you write less code? As it turns out, the answer is simple: you borrow code.

Borrowing code is certainly not new, yet I’m continually astonished to find corporations maintaining their own logging frameworks, web frameworks, UI frameworks, the list goes on and on. Why would you write your own logging framework in this day and age? Why not use log4j? Why write a web framework when you can borrow any number of wildly successful ones, such as Rails?

Of course, these frameworks have code in them too– but the beauty is that you end up leveraging the The Wisdom of Crowds; that is, you end up leveraging a community of focused smart people with varying backgrounds maintaining the code and usually a wealth a users providing feedback in multiple environments and situations– making the code more stable.

Aside from borrowing open source libraries to handle commodity issues (i.e. logging, ORM, web frameworks, etc) there are other techniques too. If you write Java code day in and day out, languages like Groovy offer manifold opportunities to lessen your lines of code.

For instance, need to read the contents of a file? If you write this requirement in Java, you could write something like this:

import java.io.BufferedReader;
import java.io.File;
import java.io.FileReader;

public class ReadFile {
 public static void main(String[] args) throws Exception {
  BufferedReader reader = new BufferedReader(
     new FileReader(new File("/Users/aglover/temp/myfile.txt")));
  String output;
  while ((output = reader.readLine()) != null) {
   System.out.println(output);
  }
 }
}

Note, the above Java code isn’t perfect nor am I trying to bash Java! But, it took 12 lines of code to print the contents of a file.

In a language like Groovy, for instance, I can achieve the goal with one line of code.

println new File("/Users/aglover/temp/myfile.txt").getText()

The above code isn’t magic– in fact, it is using essentially the same code from earlier (it’s all Java!). It’s just that someone else wrote it and scores of people are using it and making sure it works day in and day out. Ergo, using 1 line of code means I have 11 fewer lines of code to maintain (smarter people than me are maintaining those other 11 lines, baby!).

If it’s your bag to write better code, man, then I suggest you try writing less of it. Instead, focus on writing the minimal amount of code that serves a business need and borrow everything else. Can you dig it, man?

The tangible disconnect between stakeholders who define requirements and developers who implement them has long plagued software development. In recent years, however, frameworks based on dynamic languages and domain-specific languages (hint– easyb!) are bridging the stakeholder-developer gap by making code read more like normal language. IBM developerWorks‘ tutorial, dubbed “Drive development with easyb” shows how easyb — which provides a more natural DSL that is closely attuned to stakeholders — helps developers and stakeholders collaborate effectively.

In this hip, tutorial, you’ll see first hand, that easyb aims to enable executable yet readable documentation and that you can verify the behavior of anything you write in Java code, in a more natural way. When you are done with the tutorial, you’ll understand the benefits of collaborative stories implemented with easyb and how this framework makes collaboration easy.

So what are you waiting for, man? Go read it!

On October 27th, I will have the pleasure of joining my hip friend Rod Coffin in Boston for an easyb half-day tutorial. In this tutorial, hosted by the Software Development Best Practices 2008 conference, we’ll be spreading the good news of collaborative story development with easyb. We’ve planned out a fun agenda that involves a lot of trippin’ hands-on action– our goals are to demonstrate:

• how simple writing stories with easyb can be
• the power and flexibility of using a domain-specific language which binds stories to Java applications
• how easyb facilitates story documentation
• and how story documentation generation can enable requirements traceability

If you’re planning on attending, bring your laptop and a willingness to meet those around you as we plan on encouraging a lot of pair-programming! See you then!

I recently had the pleasure of chatting with Guillaume Laforge (Groovy’s hip Project Manager) for JavaWorld’s Java Technology Insider regarding the imminent release of Groovy 1.6. In this podcast, Guillaume shares what’s been done to greatly improve benchmark results in Groovy 1.6; what’s more, he also shares tips for optimizing Groovy-based applications and talks about the recent burst of tools support for Groovy. He also elaborates on the current challenges for the Groovy development team, and what the community can expect from upcoming releases such as Groovy 1.7 and 2.0.

If you are interested in hearing about the improvements and efforts related to the upcoming release of Groovy 1.6, then have a listen, man!

On Wednesday, October 8th, I will have the pleasure of giving an easyb presentation to the Richmond Java Users Group. This presentation follows a similar presentation I gave to the Northern Virginia Java Users Group in early September, which turned out to be a great time, baby!

The easyb team continues to work towards a 1.0 release having added HTML reports and recently the team has begun further focusing on documentation– new official releases will include a docbook generated PDF users guide. What’s more, a few hip articles have popped up around the web lately describing easyb, including:

• JavaWorld’s “Behavior-driven development with easyb“
• InfoQ’s “Behavior-Driven Development for Everyone“
• JavaLobby’s “Is easyb Easy?“

If you are located near Richmond, please join me on Wednesday and if you haven’t checked out easyb yet, give it a try!

My friend John Ferguson Smart (of Java Power Tools fame) has recently been bringing the good news of story based verification via easyb to the copasetic cats of Australia and New Zealand. He’s put together a slick presentation that outlines the transition from TDD to BDD and, of course, introduces easyb through an example leveraging bank accounts. He does a wonderful job of showing how to take a story (written on a story card) and implement executable documentation with easyb. John also explains the shouldBe syntax as well as the ensure syntax and easyb’s support of fixtures. Lastly, he does a hip job of showing how to run easyb via various IDEs, Ant, and Maven, baby!

Check out John’s slides and don’t forget to download easyb and join the party!

Let’s face it– page pizzazz, facilitated by JavaScript magic, is all the rage these days (along with disco dancing). And for good reason! Not only do various JavaScript libraries, like Prototype, assist in building slick effects and enable asynchronous behavior, but they also begin to shift the burden of resources towards the client.

For instance, rather than building a data-full page on the server, which could take resources (like processing power, memory, time, etc), by properly leveraging Ajax techniques, some subset of the page can be built in the server side and then other portions can be updated (resulting in smaller data transmissions between the client and the server), based upon events on the client side. Don’t get me wrong, the server side is still doing a lot of work– just not all at the same time. In fact, the server will be handling more requests, but those requests will be smaller.

In this age of Aquarius, there’s no shortage of JavaScript libraries available for facilitating Ajax (among other things, man). One contender is the aforementioned Prototpye. Prototype makes asynchronous page updating a cinch– for example, imagine an on-demand search system that searches various websites for specific items. When a user goes to their specific search page, rather than loading all the results during the page load (which can take a bit) an asynchronous call is made during a specific event to load the individual items.

When a page loads an initial table-like structure describes the search item’s facets. Yet, after the entire page is loaded, the magic happens.

First, to capture the page load event, you need to leverage Prototype’s document.observe call. This takes an event type and a function to call. The function that will be called will then leverage Ajax to call a server side resource to display the items found.

Accordingly, the event code looks like this:

document.observe("dom:loaded", getSearchResults());

The function getSearchResults is fairly simple, man. It uses Prototype’s Ajax.Updater function to do essentially two things: first, it invokes a specific URL and second, it can replace the contents of a specific DOM element with what’s returned from the URL. Accordingly, you’ve got to build a specific URL– which usually involves leveraging parameters– in my case, I’ve got to supply an id and a zipcode.

function getSearchResults() {
  var baseUrl = "${createLink(controller:'search', action:'getSearchResults')}" ;
  var pars = "searchid=${search.id}&zipcode=${search.account.zipCode}";

  new Ajax.Updater("searchresults", baseUrl, {
            method: "get",
            parameters: pars
  });
}

As you can see, the variable baseUrl is built leveraging Groovy’s copasetic Grails framework– a URL is built to the ’search’ controller type and the specific action invoked is the ‘getSearchResults’ one. What’s more, specific parameters are passed in as a String type. Note, this is URL is as unRESTful as it can get!

Lastly, the Ajax.Updater function is invoked, which takes three parameters– the id of a DOM element, a URL, and a series of options (in my case, they specify the HTTP method (i.e. GET, POST) and the parameters to bind to the URL).

The first parameter is the name of the id corresponding to the DOM element which needs replacing– in my case, I have a div whose id is “searchresults” like so:

<fieldset>
 <legend>Here's what we've found</legend>
 <ul>
  <div id="searchresults">
  (fetching search results....)
  </div>
 </ul>
</fieldset>

There is some server-side logic, which only displays this bit of HTML if the search is actually found– i.e. the fieldset is wrapped by a Grails GSP tag like so:

<g:if test="${search.found == true}">
...
</g:if>

Consequently, when a page loads and if that specific search has been found, a new table-like structure is displayed.

The details of the server-side’s hip handling of the getSearchResults call is not necessarily relevant at this point, suffice to say, this resource returns formatted text– it could return JSON, XML, etc– in my case, it just returns plain old HTML; in fact, it turns an unordered list. That way, no parsing is required– keep in mind my short cut does introduce a level of fog into the idea of separation of concerns, baby.

Putting it all together the work flow functions as follows:

1. The page loads and prototype’s “dom:loaded” event fires
2. The getSearchResults function is called
3. The getSearchResults function invokes Ajax.Updater, which asynchronously invokes and HTTP GET on a local URL
4. This URL returns a snippet of HTML that is inserted into the DOM element whose id is “searchresults” without a page refresh

Prototype makes this trippin’ process quite easy– in fact, you don’t even need to use all that much of the library– in this case, two aspects were utilized– document.observe and Ajax.Updater. And the beauty, of course, of leveraging Ajax, in this case, is that the initial page load is quite fast as the amount of data is small. After the page is loaded, another call is made, which does increase the number of hits on the server, but these hits are smaller in nature, thus reducing the load. Asynchronous page updating with Prototype is a cinch, baby!

My good friend Rod Coffin, who is an easyb team member (this cat is a coding machine and is behind the IntelliJ plug-in, the Maven plug-in, and numerous core features) recently wrote an article for JavaWorld entitled “Behavior-driven development with easyb“, which obviously extolls the manifold benefits of BBD and how to fully realize increased collaboration via a natural language provided by easyb.

Rod does a hip job of describing BDD in terms of TDD and how the two are different– as he says:

BDD attempts to re-orient the focus of TDD away from the specific structure of implementation code and towards system behaviors. One advantage of this approach is that behaviors change less often than implementation details, and typically such changes are precipitated by intentional enhancements to the functionality of the system, not as a result of simple refactoring activities.

Rod goes on to demonstrate how one can use BDD (via easyb) to verify system behavior using a more natural language. As Rod articulates,

easyb specifications are relatively free of programmer-specific syntax, placing the focus instead on communicating behaviors.

Additionally, Rod mentions that

easyb aims to stay out of the way of the story-writing process so that the center of attention is on the conversation taking place, not on the tool that is being used to capture that conversation.

Rod’s article is an excellent read and definitely serves as an in-depth tutorial on leveraging BDD with easyb– give it a read, man!

I have the distinct privilege of speaking at this year’s JAOO conference in Denmark on September 29th. I’ll be spreading the good news of Gant, which is something I’ve been having fun doing over the last year or so.

Briefly, Gant is a highly versatile build framework that leverages both Groovy and Ant to let you implement programmatic logic while using all of Ant’s capabilities. In this talk, you’ll see Gant in action and see first hand how brining Ant into a fully functional language yields an expressiveness unmatched by XML. By the end, you’ll be eager to download Gant and put your Groovy skills into action for constructing a highly flexible and extensible build system that moves concepts to cash in short order. I hope to see you there in Denmark!