The Disco Blog

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!

A few months ago, I had the pleasure of chewing the fat with my good friend Scott Davis about all things GIS (that is, Geographic Information Systems, baby). Scott, as well as being a Groovyphile, is affectionalty known as the “Map Guy” amoung educated circles having authored “GIS for Web Developers” and has long touted the benefits of taking geography mainstream, baby.

In this Java Technology Insider Podcast, Scott talks about what Google Maps has done to make GIS more accessible to web developers across the globe (no pun intended, baby). He also discusses in-depth the options available for Java developers who require a more sophisticated, less closed-stack GIS solution than Google Maps provides– like GeoNames.org (which I’ve used on more than one occasion based upon Scott’s sage advice, man).

This podcast is definitely an informal primer from a leading authority on using geospatial data, Web services, and open source APIs in Java Web development. So what are you waiting for? Have a listen now!

The easyb team recently shared what’s coming down the pipe in the imminent 1.0 release as well as where the project may be headed with the hip cats at InfoQ.com. Ken Brooks, a long time team member, was the point man for the interview and he does a great job of outlining the high level game plan going forward as well as providing a sneak peek at some related projects.

Check out InfoQ’s coverage of easyb and don’t forget to download easyb for yourself!

JavaLobby recently published about easyb entitled “Is easyb Easy?” authored by my friend, Meera Subbarao. Meera does a great job of providing a sample application, which leverages Spring 2.5 and EJB 3.0 that she ultimately verifies with easyb. In the article she shows how to run easyb via Ant and she even provides a nice image depicting the should and ensure syntax for validating expectations.

Her opinion of easyb? I think she says it quite nicely:

And now finally, the verdict. Is easyb Easy? In my opinion, it was very.

Go ahead and give Meera’s article a read!

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!

Earlier this year, I had the pleasure of chatting with Ted Goddard, who is an ICEfaces Senior Architect, for JavaWorld’s Java Technology Insider. In this podocast, Ted explains the inner workings of ICEfaces, including the framework’s hip JSF component library, its Ajax Push technology, how the framework handles application security, and how it compares to Google Web Toolkit for component-based Ajax development.

The ICEfaces project has some pretty slick components that definitely raise the bar with respect to web development; consequently, this conversation with Ted is quite enlightening and I definitely learned a thing or two!

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!

James Thurber once voiced that:

It is better to know some of the questions than all of the answers.

Indeed, as anyone who has ever pondered REST and the hip implications of implementing RESTful applications knows, the question that often pops up is:

Is this URI RESTful?

Of course, since REST is neither a standard nor some product you can buy, but simply a style of designing applications the question has many answers, depending on who decides to answer it.

In the course of trying to answer this same question for various people, someone pointed me to an interesting resource dubbed “Common REST Mistakes“, authored by Paul Prescod (who co-authored the XML Handbook). Paul’s mistakes page is an easy read and quite helpful, especially if you are asking yourself whether or not something is truly RESTful. In essence, this page attempts to answer the RESTful or not question by stating what’s not RESTful.

Keep in mind, REST is a style and thus there are strict implementations and loose implementations, man.

Earlier this summer, I had the pleasure of picking Brian Sletten’s brain regarding all things REST for JavaWorld’s Java Technology Insider. Brian does an excellent job of demystifying REST– as such he explains that REST is an application protocol, not a transport protocol; further, he describes the series of interactions that define REST. As he explains, REST is best used for managing information and information spaces without revealing back-end implementation. What REST is not about, he says, is hijacking the GET verb and abusing it badly.

Have a listen to my good friend’s RESTful discourse and while you are at it, check out IBM developerWorks‘ tutorial dubbed “Build a RESTful Web service” — in it, you’ll get to further know what REST is and how to build RESTful applications with Restlets, plus, you’ll see how to deploy and test them.

The SOA space has been interesting to watch over the past few years; indeed, things recently become quite intriguing with the recent release of MuleSource’s Mule Galaxy, which is an open source SOA governance platform with an integrated registry and repository. If the description of Galaxy seems like a mouthful, then you’ll definitely want to listen to a conversation I recently had the honor of having with Dan Diephouse for JavaWorld’s Java Technology Insider.

Dan is the chief architect of Mule Galaxy and in this conversation, he explains what an SOA registry and repository is and how all of this is related to governance. Dan’s also a big fan of REST and does an excellent job of explaining why. If you’re curious about SOA governance or REST in general, then have a listen, man!