The Disco Blog

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!

On Wednesday, September 10th, I will have the privilege of speaking about easyb at the Northern Virginia Java Users Group. This is my hometown JUG and it’s always a blast to converse with old friends and familiar faces. Plus, I can’t think of anything more fun (well, other than perhaps listening to disco music) than chewing the fat about easyb!

As I see it, this presentation will address the notion of executable documentation — agile developmental practices push for reducing repetitive documentation and for a rapid acceptance of change; yet, achieving these goals is by no means easy. While a process can enable increased collaboration, for instance, there are only a few tools that can effectively implement collaboration. Once such tool is easyb, which facilitates collaboration by bridging those that define requirements (i.e. customers) and those who turn requirements into code (i.e. development). With easyb, collaborative teams can develop stories in a specific format which are then implemented as verification assets through a framework which marries the underlying application. This verification suite enables change and produces accordance among teams in short order.

In this presentation, we’ll see how to embrace collaboration and change rapidly by defining hip easyb stories that exercise a Java application end to end. I’ll demonstrate how to define specific easyb structures, how to plug them into real code, and how to run them in an automated fashion. Hopefully, you’ll see first hand how non-coders can define tests easily and how the collaboration this brings yields working software faster.

I hope to see you there, man!

Back in the Age of Aquarius, hip cats could somewhat quickly knock out an account creation web page (for basically any web application) that contained a few form fields, such as account name and password to name few. Those days are gone, however, with the proliferation of various nefarious bots that annoy basically everyone except their inventors.

While automated annoying machines are not completely stoppable (much like disco music, baby!), the CAPTCHA has been helpful in at least slowing them down. As such, various CAPTCHA implementations have sprung up– JCaptcha is one such open source implementation built for Java applications; what’s more, there is a JCaptcha plug-in for Groovy’s Grails web framework.

Using the plug-in is easy too — all it takes is four hip steps.

First, you need to download and install the plug-in, which can be done by issuing the command:

%>grails install-plugin jcaptcha

After that’s complete, you’ll need to define one or more captchas in your Grails Config.groovy file– this step was a bit confusing to me at first, so let me explain. JCaptcha offers two logical types of captchas– images and sound files. Image captchas also come in different flavors. For me, I only needed one type of captcha– that being an image one, so I was able to define it like so:

jcaptchas {
 image = new GenericManageableCaptchaService(
   new GenericCaptchaEngine(
    new GimpyFactory(
     new RandomWordGenerator("abcdefghijklmnopqrstuvwxyz1234567890"),
     new ComposedWordToImage(new RandomFontGenerator(
       20, 30, [new Font("Arial", 0, 10)] as Font[]),
     new GradientBackgroundGenerator(140, 35,
       new SingleColorGenerator(Color.white),
       new SingleColorGenerator(new Color(152, 245, 255))),
     new NonLinearTextPaster(6, 6, new Color(108, 123, 139))
     )
    )
  ),
 180,
 180000)
}

There’s a lot going on there, man, but it makes sense once you figure out what’s important.

First and foremost is the RandomWordGenerator object, which essentially represents the available copasetic characters and digits captchas will contain when generated. Because it’s my bag, in mine, all letters in the alphabet are fair game; however, they are all lower case. Also too, I’ve got 10 digits represented.

The GradientBackgroundGenerator enables you to have an image with essentially two colors with a fading effect. For instance, mine fades from white to a blue-ish color (which you can see the left). The NonLinearTextPaster object allows you to declare how many characters (or digits) will appear and what color they’ll be– in my case they are gray-ish.

Note, you’ll have to import all of these trippin’ objects into your Config object; however, that’s about it– it’s boiler plate code and of course, there are other options and objects which are free to be utilized, provided you read the JCaptcha documentation. In truth, this captcha isn’t all that sophisticated and thus, advanced bots can, most likely, figure it out– in any case, you can always make these captchas more cerebral via the various objects the JCaptcha team offers.

The next step is to incorporate the captcha object into a web page. This is easily done via the jcaptcha tag, which, at its minimal usage, takes the captcha name defined in the Config object. In my case, the name is “image”.

For instance, the relevant code which shows the captcha in the image to the left is as follows:

<p><label>&nbsp;</label><jcaptcha:jpeg name="image"/></p>
<p style="padding-bottom: 0.5em;"><label>What's in the image?</label>
<input type="text" id="captcha"
       name="captcha" value=""/></p>

As you can see, there is a form input of type text, which has an id of “captcha” — this will hold the value a user presumably enters. Accordingly, the controller that the form is submitted to needs to validate the captcha. This is done by providing the JcaptchaService (which is provided via the plug-in) with the answer the user submitted, the captcha name and the session id for which the challenge was issued — i.e. the session associated with the browser when the image was viewed.

In my case, I have a closure which contains this code to verify the correct answer was issued:

if (params.captcha.equals("") ||
    !jcaptchaService.validateResponse("image", session.id, params.captcha)) {
        account.errors.reject("blank.captcha",
          "You must specify the correct characters and/or numbers in the image")
}

As you can see, the validateResponse method returns a boolean, which indicates the answer. If false is returned, then the account domain object is provided with an error, which will be displayed on the web page, allowing the person another chance to correctly get the characters and digits correct.

With the JCaptcha plug-in, implementing a virtual wall to facilitate in hampering annoying spam bots for various web forms in Grails is as easy as cake! Can you dig it?

Andy Warhol is famous for having coined the phrase

In the future everyone will be famous for 15 minutes.

In my case, I still have roughly 38 seconds left. Ok, fine, you are correct, I have yet to achieve famousness and have, still, to use my 15 minutes; nevertheless, I had the pleasure of chatting with my good friend Scott Davis about a year ago regarding all things Groovy.

This video was shot while a few of us were in lovely Florida in early December 2007. In this conversation, Scott inquires as to how I got involved with Groovy and how I (at the time) was using Groovy from day to day. A few quotes jumped out at me– one in particular is Scott’s musing that

Groovy is more of a seasoning than an entrée.

Well said friend! It dovetails nicely with something I probably said three times in our conversation:

Groovy is just another JAR file!

Interestingly, Scott asked me to comment on what I saw as an upcoming aspect of Groovy that excited me. Probably to most people’s surprise, I indicated that I was looking forward to improvements to Groovy’s console. At that time, the console was lagging in usability as compared to Ruby’s IRB or Python’s shell– I was sure that the community was as excited as I was regarding improvements to this aspect. Indeed, the Groovy console is much improved (you no longer need to issue the “go” command); however, it appears that most people overlook it– at least, I don’t think I’ve talked much about the console since that day last December.

Lastly, I’ve definitely jumped head first into Grails since this video was recorded and I’m still as excited about Grails now as I was then.

The next release of easyb will support the notion of ignoring entire stories or various scenarios within in story via the ignore keyword.

As currently coded, ignore supports two features– either ignoring the entire story all together via ignore all or you can pass in one or more scenario names which to ignore. This selective ignoring feature can take three different types of parameters– a single String (which represents the particular scenario to avoid), a series of Strings (separated by commas, which represents a series of scenarios to ignore) or a Collection of Strings (which also represents a series of scenarios not to run).

As you can see, this keyword is very much like the standard xUnit paradigm’s ignore; however, it might be a bit more flexible as you can specify just what scenarios to ignore and which to presumably run in one statement, rather than having to repeatedly issue ignore statements.

For instance, the following story, dubbed noworking.story, would be completely ignored:

ignore all

scenario "this is purposely a broken scenario", {
 given "some variable with a value", {
  val = 12
 }
 then "to force an error, one should verify it is not 12", {
  val.shouldNotEqual 12
 }
}

That is, nothing within the story would be executed; consequently, no state would be captured– nothing is pending either. As of right now, pending and ignoring stories/scenarios are completely different and also convey different meanings.

Using the same exact story, you could also specify the particular scenario to ignore by passing it its name as follows:

ignore "this is purposely a broken scenario"

scenario "this is purposely a broken scenario", {
 given "some variable with a value", {
   val = 12
 }
 then "to force an error, one should verify it is not 12", {
   val.shouldNotEqual 12
 }
}

If this same story had more than one scenario, you could then either continue passing in comma delimited scenario names or just pass in a collection like so:

ignore "this is purposely a broken scenario",
    "this is also a purposely broken scenario"
//or
ignore  ["this is purposely a broken scenario",
   "this is also a purposely broken scenario"]
//which is the same as saying
coll = ["this is purposely a broken scenario",
   "this is also a purposely broken scenario"]
ignore coll

This feature is currently considered a prototype and only lives in the tip of easyb’s SVN repository. Feel free to download the source and give it a spin for yourself (building easyb is easy, man!)!