Don’t doubt it for a second: A paradigm-shifting idea is taking shape on Johnny Anonymous’s laptop as I write these words. Johnny’s idea is a radical as it is ingenious. It will change the way you communicate, work, think… breath. It may bring you that one love you’ve been longing for all your life; bring your kids opportunities and joy beyond their wildest dreams; resolve international crises; lead to cures for cancer; cut CO2 emissions in half; make quantum mechanics comprehensible to the lay-person; cause Dan Brown to write a decent book (okay, maybe not). Hell, it may even help us to make contact with aliens – how cool is that?!

Will Johnny’s idea ever see the light of day? As long as the Internet remains a level playing field, he/it has good a chance as any. Yet if the likes of Veroogle (Goozon?) have their way, then Mr. CEO will quash Johnny’s idea quicker than you can say the words “big fat severance package”.

Should Big Corporate really be permitted to dictate the accessibility and the quality of service that Johnny’s idea receives when he attempts to reveal it to the world? Let me put it this way: Can we trust corporations to govern themselves in such a way that they never,ever take active steps to diminish the chances of a potential competitor’s idea from taking hold? Don’t worry – it was a rhetorical question.

Is the world – virtual or otherwise – really so oblivious to the messy, awesome beauty that is the Egalitarian Internet; so apathetic that it will not lift a finger to rescue one of humankind’s finest achievements? Will the masses revolt? Furthermore, who will speak for us? Where are you Tim Berners-Lee?

So until the masses mobilize – and they surely must – here’s a tiny, yet powerful step that Joe Public – read: you – can take RIGHT THIS INSTANT: Bing.

Project Lombok is a very cool little Java library that aims (and succeeds) in removing boilerplate, meaningless, and uninteresting code from your Java objects. The basic idea is to replace things like getters and setters with simple annotations, and then let the Java compiler generate the necessary bytecode in the .class file so that tools such as Eclipse and the Java compiler have no idea what anything unusual happened. Lombok hooks into the compiler to make sure this happens correctly.

First we’ll cover some Lombok basics and then show how it can be used with the Canoo RIA Suite (ULC) project and and view generators. This includes details on how to mix Lombok annotated objects with JPA annotations, which you might want to glance at before leaving!

Update: You do not need ULC to work with Lombok. The two are separate projects.

Lombok in Action
So let’s see Lombok in action. Consider this Java class that includes a Lombok annotation:

import lombok.Data;

public @Data class Contact {
    private String name;
    private String email;
    private String primaryPhone;
}

public @Data class Contact {
    private String name;
    private String email;
    private String primaryPhone;

    public String getName() {
        return name;
    }
   
    void setName(String name) {
      this.name = name;
    }
    
    public String getEmail() {
        return email;
    }
   
    void setEmail(String email) {
      this.email = email;
    }

    public String getPrimaryPhone() {
        return primaryPhone;
    }
   
    void setPrimaryPhone(String primaryPhone) {
      this.primaryPhone = primaryPhone;
    }

    @Override public String toString() {
        return "Contact(" + name + ", " 
                + email + ", " 
                + primaryPhone + ")";
    }
     
    @Override public boolean equals(Object o) {
        if (o == this) return true;
        if (o == null) return false;
        if (o.getClass() != this.getClass()) return false;
        Contact other = (Contact) o;
        if (name == null 
                ? other.name != null 
                : !name.equals(other.name)) return false;
        if (email == null 
                ? other.email != null 
                : !email.equals(other.email)) return false;
        if (primaryPhone == null 
                ? other.primaryPhone != null 
                : !primaryPhone.equals(other.primaryPhone)) return false;
        return true;
    }
     
    @Override public int hashCode() {
        final int PRIME = 31;
        int result = 1;
        result = (result*PRIME) + (name == null 
                ? 0 
                : name.hashCode());
        result = (result*PRIME) + (email == null 
                ? 0 
                : email.hashCode());
        result = (result*PRIME) + (primaryPhone == null 
                ? 0 
                : primaryPhone.hashCode());
        return result;
    }

Richard Gabriel made this observation when comparing old programs (like MacPaint) to “modern” programs writen in langauges like Java:

I’m always delighted by the light touch and stillness of early programming languages. Not much text; a lot gets done. Old programs read like quite conversations between a well-spoken research worker and a well-studied mechanical colleague, not as a debate with a compiler. Who’d have guessed sophistication brought such noise.

Now, with Lombok, sophistication is finally taking the noise away, rather than adding to it.

Just a couple important details before moving on to a Lombok example that uses Canoo’s RIA Suite…

Lombok with Canoo RIA Suite
The point of this was to make sure I could use Lombok on my next RIA Suite(aka ULC) project. It’s looks like I can, and you can too. To prove it, let’s generate a RIA Suite project, add a domain class using Lombok, generate the views, and run the application.

Prerequisites

Steps
Here are the steps we’ll perform to get this thing working:

Generate the Project
The ULC Application Development Guide contains a 10 page getting started tutorial that walks you through the process from starting at zero and going to a deployed RIA Suite application. Really, it is quite simple. You just need to add the Project Generator as an external tool in Eclipse. Although it is a bunch of screenshots, this is a common task for Eclipse users and little can go wrong.

In Eclipse, click Run -> External Tools > Open External Tools Dialog… and point a new external tool to your “/addon/generators/build-setup.xml” from the RIA Suite install. Your window should look like this:

Now you’ll have the menu entry for Run -> External Tools -> ULC Project Generator, which you should click now. You’ll be prompted for a project name and whatnot, and a sample Contacts application will look like this:

The script runs and you now have a project on disk that can be run. Just click to File -> Import to import it, navigating to where it is on disk. Your import screen should look like this:

If it all goes well your project should be open and your Project Explorer should look like this:

Add the Lombok Jar
We need to add the lombok.jar to the Contacts project, add it to the build classpath, and click Refresh to make sure Eclipse is aware that something changed.

Copy the lombok.jar to ./Contacts/lib/development directory in your project. Then edit the project properties (right click the Contacts project and select Properties), select the Java Build Path entry, and add lombok.jar as a Jar. Should look like this:

Create Domain Object
Let’s add a domain object with JPA persistence to our project. A Contacts application must show a Contact, right? This looks about right:

package org.sample.contacts.domain;

import javax.persistence.*;
import lombok.*;

@Entity
public @Data class Contact {
    
    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE)
    @Getter(AccessLevel.NONE)
    @Setter(AccessLevel.NONE)
    private Long id;
    private String name;
    private String email;
    private String primaryPhone;
}

Generate the View Layer
To generate the view layer, click Run -> External Tools -> “Contacts generate-beans-view”. This tool was installed for you by the Project Generator. Running it generates a simple Create-Read-Update-Delete (CRUD) interface with a table, buttons, and entry editor. You’ll see a couple new classes and property files in your application after you run the tool.

Run application
Last thing to do is run the app. Click Run -> Run History -> Contacts (again installed by the project generator), sit back, and behold an application.

That’s it!

Next step is to deploy to Google App Engine using that Contacts-copy-to-GoogleApp tool that the generator installed, but that is a blog post (and task) for another day.

Enjoy!

By my count, Ubuntu Kung-Fu from Pragmatic Bookshelf is the perfect summer reading book. It’s light, the content is not going to strain your mind the way some computer science tomes will; it’s easy to read, as always with Prag books the writing is conversational and the fonts large; and it’s fun, where else can you read about easter eggs like talking cows and floating desktop fish.

Admittedly, some of the 315 tips are useless. I’m not sure when I’ll ever use the “cowsay” command to invoke a talking ascii cow, but for some reason I’m glad I know about it. I predict the error output in my Bash scripts is about to get a lot more bovine. Most of the tips are good, though. Of the 315 total tips (less than a page long each), there are maybe 25 dual boot and Windows related tips and maybe 25 more system recovery and troubleshooting tips. It isn’t a comprehensive reference to administration or dual booting, but these tips are still good to keep around in case of emergencies. Someone switching from Windows and still dual booting will find this book extremely helpful. There are also quite a few Gnome desktop tips for how to tune the desktop manager; for instance, how to use drapes to change the wallpaper every morning. But the majority of the book details cool and useful programs and packages to install… stuff I didn’t realize I needed until I found out about it. Normally I prefer printed books, but the best way to read Ubuntu Kung-Fu is by viewing the PDF directly on the computer and having a command prompt open to try the tips as you go.

If your vision of a great vacation is laying down with a laptop on your belly, banging away on new bash commands and scripts, then this is the book for you.

Now here are my favorite 10 tips.

1. Command History Search with Ctrl+R – In a terminal, the up and down arrow shuffles through recent commands on almost any operating system. I had been using grep to search my history (history | grep something) until I found out about Ctrl+R. When you type Ctrl+R, the terminal goes into a matching mode where it tries to guess the entry from your history based on what you type. So type the first few letters of a recent command and the entire thing comes up. This is great, and I use it regularly to expand out “git pu” into a full “git pull origin master”. But don’t get the wrong idea! I still think git is awful.

2. Running jobs with & and nohup – I discovered & long ago. If you run a program from the command line then the terminal is frozen until the program completes. But if you append & (for instance, “gedit &”) then it launches as a job and you can use the terminal again while your program runs simultaneously. The problem is if you close the terminal then your other program closes as well. Instead use nohup (”nohup gedit”) so that your program does not hang up when the terminal closes.

3. Use Trash for Command Line File Deletes – There are a bunch of safe alternatives to deleting files using “rm -rf”, and this type lists yet another one. However, I prefer to use the “trash” package. Just run:
sudo apt-get install trash-cli

4. gconf-edit – Desktop programs usually have a preferences panel, but not all preferences or settings are available there. The “gconf-edit” program in Gnome looks a little like a Registry Editor and is where all Free Desktop programs must store their configuration settings. Even if it is not in the preferences window you can still access it through gconf-edit. Take a look at what is available for Nautilus and gedit. It should be quite easy to expand your gedit recent files list to be 10 entries long, for example.

5. Command Line Image Manipulation - There are a whole bunch of command line and batch image tricks you can perform with “imagemagick”. Shrink and enlarge in batch using “convert -resize 50% filename.bmp”, convert formats using “convert -quality 80 filename.bmp filename.jpg”, and sharpen images using “convert -sharpen 0×1 filename.bmp”. Of course, for ascii aficionados like me, there is no beating asciiview. Install these:

sudo apt-get install imagemagick
sudo apt-get install asciiview

6. Fonts Galore – I agree, Ubuntu fonts just look better, but the author is a little obsessive including 5 different font tips. You can “Make Fonts look superb” by turning on autohinting using a somewhat lengthy process. Or you can just install a whole slew of fonts such as the 465 fonts in ttf-aenigma, the Microsoft imitation fonts in ttf-liberation, or the Comic Sans style fonts in the ttf-fifthhorseman-dkg-handwriting, ttf-sjfonts, and ttf-breip packages. There’s even directions on stealing the Mac or Windows fonts by mounting the alternative OS, copying all the .ttf files locally, and then installing them into Ubuntu. This is probably the only tip that is not 100% legal. Install these:

sudo apt-get install ttf-aenigma
sudo apt-get install ttf-liberation
sudo apt-get install ttf-fifthhorseman-dkg-handwriting
sudo apt-get install ttf-sjfonts
sudo apt-get install ttf-breip

7. Command Line Web Browser – I don’t know why but I get a real kick out of the “links” command line web browser. I enjoy the absurdities in life and browsing a text online web from the console seems like one of them. Install it with:
sudo apt-get install links

8. Install all the multimedia codecs you’ll ever need – My family’s favorite baby sitter is the DVD player. When a parent needs a break, there is no joy like popping in a princess or dinosaur movie and seeing a child fall quickly into an animation induced stupor. Peace and quiet at last! Except when the DVD doesn’t play because of missing codecs. Curse you copyright laws! Best to be prepared and just install all of these through Synaptic now:
GStreamer extra plugins
GStreamer ffmpeg video plugin
Ubuntu restricted extras
GStreamer plugins for mms, wavpack, quicktime, musepack
GStreamer plugins for aac, xvid, mpeg2, faad
GStreamer fluendo MPEG2 demuxing plugi
Finally, be sure to run the DVD playback enabler script: sudo /usr/share/doc/libdvdread3/install-css.sh

9. See a Quote of the Day Whenever You Log In – I love quotes, so seeing a new one at the top of all my Terminal windows is a real bonus. Just install signify, create a ~/.signify file, and then edit your ~/.bashrc so that the last line reads “signify”. The format for the .signify file is % { quote % | quote % | quote % }. Yes, you read correctly, that is a “% |” delimited list with a “% {” start identifier and a “% }” end identifier, which makes the .signify file qualify as the most ridiculous text file data format I have ever seen. Oh well, just install:
sudo apt-get signify

10. Play Old MS-DOS Games. Hell yes, Bard’s Tale is about to be run! First install “dosbox” and create an empty directory on your disk called “dosbox_c”. Then, using the DOSBox user interface, mount your empty directory by typing “mount C dosbox_c” and then switch to it by typing “C:”. You are now at the DOS prompt. Browse on over to your favorite abandon ware site and start downloading the classics. I suggest raiding http://www.abandonia.com. Install with:
sudo apt-get install dosbox

So that is my best 10. All I have left to say is:

 ____________________________
< I want a Bash Kung-Fu book >
 ----------------------------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

Big Griffon news today.

First, the Griffon Refcard is available from DZone. This is a concise 6-page reference to getting started and working with Griffon. If the only thing you know about Griffon is that it is a Grails and Groovy based framework for building desktop applications, then this RefCard will fill you in with tons more details. And if you’re an old Griffon hack, then you’ll probably still pick up some new tips and tricks.

Plus, DZone published an interview with Canooie Andres Almiray, the Griffon project lead. You can read the interview here, or click the RefCard below to download the card.

Anyone interested in Griffon in the Swiss area should come out to Hackergarten on the 30th of July. Several experienced Griffon developers will be present including Andres. And there is free pizza!

Two weeks ago I spoke at the Chech Java User Group (CZJUG) on the topic of “Code Generation on the JVM”. Some of the technologies covered are Lombok, Groovy, GContracts, Spock, AST Transformations, Spring Roo, and other fun stuff.

The slides are available at: http://github.com/HamletDRC/presentations/blob/master/asttransformations/asttransforms_czjug.pdf

As a fun aside: my Ubuntu laptop went crazy the night before and I spent all day before the JUG reloading Linux on my vacation. In the end, I had to switch to my wife’s Mac to do the presentation and live coding. I got the Macintosh fully configured and, during the 1st presenter, realized that I had no VGA output on the Macintosh. Oh geez. The final solution was to share my desktop, have an audience member VNC to my wife’s machine, and project the desktop from the audience. It worked and I’m glad I didn’t have to give the whole talk in chalk on the blackboard (although that would have been a fun challenge).

Enjoy the video!

When Firmenlauf ‘10 was announced, Canoo decided to build a team and to participate again this year. We had great fun last time (see Firmenlauf ‘09 part I and II) and the race deadline gave us a goal for our rigorous 30° lunchtime jogging sessions. Also I personally like the team spirit generated by such events.

Left to right: Andrei, Christian, Roland, Johannes, Hamlet, Günter, Markus and Alexandra

Even though six kilometers is a relatively small distance, a certain fitness is still needed to increase the pleasure factor. Otherwise you are only suffering and this is definitely not what you want to achieve.

It was interesting to observe how the team organized itself for the training sessions. The participants regularly asked each others to go for group runs. The single shower we have here at the office rapidly became a bottleneck, adding some roughness to the whole story.

We regrettably had to experience two defects. Hamlet kindly accepted the challenge in the last minute. So at the end we were 8 at the starting line instead of 9 initially announced. At 7pm on Friday the 9th of July the starting gun fired. After a cumulated time of 2:10:34,5 the first group of Canooies composed of Alexandra, Markus, Günter and Christian crossed the line hand in hand, just after the Herzog & de Meuron architects but before another Software engineers company I am not mentioning by name… For a complete results overview, click here.

Left to right: Markus, Christian, Günther and Alexandra

The rest of the team composed of Roland, Andrei, Johannes and Hamlet successfully crossed the line as well. Everyone did an incredible job. I can tell you: this year was really hard. It was so hot and humid. A couple of people collapsed (no one from Canoo luckily) and we heard the ambulance at least once.

More photos could be found on Flickr.

This article originally appeared in the May 2010 edition of GroovyMag, the Groovy and Grails magazine. Parts 3 and 4 are currently available for download from the magazine’s site, and more will come each month. Enjoy!

The Groovy Programming Language advertises itself as an “agile and dynamic Language for the JVM”, but what does this mean exactly? This series of articles explains Lean Software Development, and shows how your choice of programming language can make your entire process remain nimble and adaptive. Each month will cover one of the seven Lean Software Development principles and explain how Groovy and the associated ecosystem help eliminate waste, defer commitment, and build quality into your product.

About this Series

Groovy is an agile programming language. In order to explain what this means, these articles are structured around the seven principles of Lean Software Development. Last month included a short introduction to Lean, and explained how an expressive language can eliminate waste in unit testing. This month we’ll see how the easyb Behavior Driven Development framework and Groovy Builders can build quality into your life-cycle. In later months we’ll explore how different testing tools like the Spock Framework help create knowledge, how a dynamic language lets you minimize coupling and defer commitment, and how metaprogamming allows you to deliver fast. In future installments you’ll see how Groovy’s Grapes module system, alongside modules like Groovy Web Services, streamline interactions between development and other groups like operations and QA… an important aspect of respecting people. Finally, we’ll look at optimizing the whole by applying Groovy to domains that cross department boundaries: how Gradle improves the build process and easyb serves as a collaboration mechanism between different organization roles. The series will end with a discussion on the best practices of mixing Java and Groovy.

Some of the code examples are basic while others are advanced. The articles explore why the features of Groovy are important rather than the mechanics of any one Groovy feature. Hopefully you’ll leave with some new ideas about how to use Groovy, how to convince your team that Groovy is worthwhile, or most importantly how to increase your productivity.

Lean Revisited

Part 1 of this series contained a more indepth explanation of Lean, and I won’t repeat it here. But as a quick refresher here are the 7 lean principles along with a summary for those principles covered previously:

1. Eliminate Waste – Reduce work in progress and half done work
2. Build Quality In
3. Create Knowledge
4. Defer commitment
5. Deliver Fast
6. Respect People
7. Optimize the Whole

Principle 2 – Build Quality In

If you want to build a high quality product, you could inspect your product after it is built to ensure that it conforms to standards. But it would be better to change how the product is made so as not to create defects in the first place. Picking the best of breed testing practices and using them before the system is completely built is of utmost importance to quality software. At one point in time JUnit and Java were the state of the art in software testing, and eventually Test Driven Development gained mind-share in the industry, pushing testing into the same phase as development. Today, some of the best tools and practices are coming from the Behavior Driven Development community. Groovy is lucky to have an excellent choice for BDD in the Jolt Award winning easyb framework.

Instead of writing tests, easyb focuses on writing “stories”. A story is a piece of functionality that is visible and meaningful to the user. The intent is different than unit testing, although it does occur frequently at the same level. Stories are expressed in a given/when/then format. For instance, the story for a web service might be: given a user web service, when a user is looked up in the web service, then the user’s record should be found. The example in Listing 1 might make this clearer.

using "xmlunit"
scenario "web service should return XML based users", {
  given "a user web service ", {
    service = new UserWebService()
  }
  when "a user is looked up in the web service", {
    webServiceResult = service.get(123456)
  }
  then "the user's record should be found ", {
    webServiceResult.shouldBeIdenticalTo """
        <user id= "123456">
        <firstname>John</firstname>
        <lastname>Doe</lastname>
        </user>"""
  }
}

To understand the low ceremony nature of easyb, understand that Listing 1 is the entire file. There is no setup, test class subclass, or magical annotation incantation required. The essentials of your test are what it is testing, not the mechanics of a test framework. Easyb works with you in achieving a test with only the essentials being communicated.

You may have also noticed a lack of variable declarations. Where are these variables declared and what are their scope? Again, declarations are rarely an essential part of a unit test, so easyb handles this for you. Variables are scoped within the scenario they are used and instantiated when referenced. Easy, and with a lot less fluff than Java. Hopefully you are wondering how all of this works (if not then skip to the next paragraph)! Remember, parenthesis are optional in Groovy method calls, and {} is used to create a closure. In this easyb story, scenario, given, when, and then are all just normal methods that take a String and a Closure as parameters. While it may look terse enough to be qualified as a domain specific language, this is for the most part just plain old Groovy. The implicit variable declarations are a little harder to explain, but suffice it to say that a little metaprogramming is happening under the covers.

At first glance, easyb might appear to be a lot different from the traditional JUnit approach. Some of it is quite different, which gives easyb its power. But for the most part, it is plain old Groovy and is a good JVM citizen. There is plenty of build system support for easyb (an Ant task and plugins to other systems), IDE support for at least IntelliJ IDEA and Eclipse, and other JVM tools like code coverage applications should still work with it. If you are serious about building quality into your product, then take a hard look at using BDD and easyb to drive down defects before they appear in the QA phase.

Behavior Driven Development

BDD bills itself as “Unit Testing Done Right “. So what was wrong with unit testing? Unit testing is a good start, but often addresses how objects behave at the microscopic level rather than focusing on what matters to stakeholders. BDD changes this by focusing testing back on the project and the value of the system. Developers are encouraged to focus on why tests should be created rather than adhering slavishly to a one test per object approach. It might sound more like functional testing than unit testing.

The way to focus tests back on business value is by developing and using a ubiquitous language. When your customer says, “The user should be able to change their password,” then that should be your test name. Calling your test fixture UserManagerTest, your test method testChangePassword, and your assertion assertEquals creates an artificial language barrier between you as a developer and the business. It is better to call the test User Features, the test method user must change password, and the assertion should be. A common and ubiquitous language breaks down barriers between you and the business and keeps you focused on why you’re writing the system in the first place.

Groovy Builders

Another Groovy language feature useful in achieving low ceremony testing is multi-line Strings. Strings may be triple quoted, like in the Listing 1, and then all special characters and whitespace may be embedded in the String without escaping or concatenation. This makes working with XML a breeze: no need to litter your test with long blocks of string concatenation, nor do you need to hide the XML snippets away in an external file where they aren’t visible when the test fails.

Building data, and lots of it, is a common occurrence in unit tests. Multi-line Strings are nice, but are definitely not the only way to build String based data. One of the most helpful classes in the Groovy library is the MarkupBuilder, as seen in Listing 2.

def writer = new StringWriter()
new groovy.xml.MarkupBuilder(writer).
   user(id: 123456) {
      firstname('John')
      lastname('Doe')
   }

<user id= "123456 ">
   <firstname>John</firstname>
   <lastname>Doe</lastname>
</user>

Listing 3: XML output from Listing 2

The MarkupBuilder is a dynamic object that treats method calls as requests to build markup (whether it be XML or HTML). Calling a method, any method, is going to create an XML Node with the tag named the same as the method. Passing a key/value pair is going to add an attribute to that node, and passing a value is going to write that value as the node value. In Listing 2, all of this is written into the StringWriter object. The real power of MarkupBuilder comes when mixing dynamic method calls with real, statically declared method calls like List.each().

In Listing 4, the users() and user() method calls are calls on the MarkupBuilder, and will have start and end tags generated correctly, while the names.each() method is an invocation on the variable called names that is in scope. Building ad-hoc test input and test control data is greatly simplified by understanding and working with builders.

def names = ['Alice', 'Bob', 'Carol', 'Ted']
def writer = new StringWriter()
new groovy.xml.MarkupBuilder(writer).
   users {
      names.each { name ->
         user(name)
      }
   }

Listing 4: Mixing MarkupBuilder and Lists

Listing 5: Output from Listing 4

Don’t just rely on this builder though. Write your own builder for working with any sort of structured data. Any tree like data structure is a good candidate, as well as APIs that require heavy usage of setParent() or setChild() method calls. All of this can be hidden behind a builder. There is even an abstract class called BuilderSupport that takes care of all the heavy lifting.

Before writing your own builder with BuilderSupport, it pays to understand how the object works to capture arbitrary dynamic method calls. Listing 6 shows all the possible ways to interact with a Groovy builder. There are four options: you may invoke dynamic method calls with no parameters, a
single value parameter, a Map parameter, or a Map and a value parameter.

new groovy.xml.MarkupBuilder().root() {
   valueNode('a value')
   attributeNode(a: '1', b: '2')
   mixedNode(a: '1', b: '2', 'a value') {
      nestedNode()
   }
}

Listing 6: Possible Uses of Markup Builder

All of these methods take an optional closure parameter that lets you nest nodes arbitrarily deep. To generalize the builder pattern, there are 4 possible ways to invoke a dynamic method. With this in mind, the abstract BuilderSupport class is a logic implementation for a base builder class. If you want to create a new builder, then you need to implement four abstract methods, one for each type of dynamic method invocation. The BuilderSupport abstract methods can be seen in Listing 7.

class BuilderSupport {
   ...
   abstract Object createNode(Object name)
   abstract Object createNode(Object name, Map attrs)
   abstract Object createNode(Object name,
   Map attrs, Object value) abstract Object createNode(Object name, Object value)
   ...
}

Listing 7: BuilderSupport Abstract Class

What BuilderSupport does for you is handle all of the dynamic dispatch and nesting with closure parameters. Writing a new builder, and enjoying the accompanying Groovy “magic” really is as easy as implementing these four methods. You’ll get the most value from a builder by taking a few minutes early in the project to write one as a wrapper around your tree-like API.

Next Steps

One particularly rigorous Lean practice is a zero tolerance or stop the line approach for defects. The idea is that no defects should exist in the system, and when a defect is present then all attention and effort must be focused on resolving the issue before normal work resumes. In the face of error conditions and ambiguities, the assembly line stops until the issue is resolved. The effect is that your daily process becomes fine tuned around producing a high quality product early in production as opposed to optimizing a defect cycle days or weeks later. Stop the defects before they happen. My team recently applied this approach for a single two-week iteration with interesting results. Based on our retrospectives, we decided to not continue with a strict enforcement of this policy, but we all agreed we learned a lot and the lessons learned were carried forward to our current process. A worthwhile experiment; I suggest you try it.

Next Month: Create Knowledge

Software Engineering is a knowledge creating process. It is important to find the correct balance between tacit, organizational knowledge and explicit, recorded knowledge. Next month’s article explores what this means, looks at ways to use Groovy to capture and codify knowledge, and discusses the differences between terse and expressive. Along the way we will see some cool new features of Groovy and the amazing Spock testing framework.

Learn More

Everyone learns differently, and for me the best way to learn about a new framework is to experiment with it. Easyb can be downloaded from http://www.easyb.org/ and BuilderSupport is a standard Groovy class. Otherwise, the web contains many tutorials on both subjects, and “Programming Groovy” by Venkat Subramaniam contains an in-depth BuilderSupport chapter. The MEAP pre-release for “Groovy in Action 2nd Edition ” does not yet (at the time of this writing) contain Builder information, but it should be coming out shortly.

For books on agility, I still contend these three cannot be beat:

• Implementing Lean Software Development – Poppendieck
• The Pragmatic Programmer – Hunt and Thomas
• Extreme Programming Explained, 2nd Edition – Beck and Anders

What Type of “Done” are You? This is certainly one of the central questions of Scrum. Does it involve testing, integration testing, user acceptance, documentation, or all of these?

It is up to you – as a company – to define what Done means.

A “done” task at the end of a sprint means it is a fully working and shippable increment of the product, and it is an increment you want to built upon in your subsequent work. The size of the task “done” does not matter much, it can be small as long as it is “done”, according to the definition. So better do it well or it will show up again later in your backlog and retrospectives …

Questions like these – all focused on the core aspects of the Scrum methodology – were discussed at the ScrumMaster certificate workshop at the Entwicklertage Karlsruhe, 21.-22.6. One of the godfathers of Scrum, Ken Schwaber, was performing this workshop with around 30 people in the Schlosshotel Karlsruhe. Canoo was contributing well, providing 10% of the participants. The workshop was a lot of fun, full of exercises, jokes, anecdotes and insights.

Scrum is an empirical process and therefore requires some experience. Reading a book about it gives you an idea, but you have to practice and live it.

What do you think, does a Scrum Master have to be at the daily scrum meeting? That was an interesting question to discuss. On one hand, the ScrumMaster is directly accountable for the Scrum process by definition. Therefore he had better attend the meeting and help remove impediments. On the other hand, the purpose of the meeting is not to report to the Scrum Master. It is for the team to get an understanding where they are and what is going well or not.

Is it correct if management attends a Spring review meeting and applauds you for your success? What should you do if the product owner reshuffles the whole product backlog against your better knowledge? Given 20 Mio. Dollars to expand your company, how would you scale your initial team of 7 to 70? How do you write an offer based on the Scrum approach to a fixed business request?

Scrum is based on transparency and commitment, it establishes local predictability in highly complex and globally uncontrollable projects. It makes risks and defects highly visible. Its time to get rid of the “feature finish metronome” in our heads.

Some of the most important aspects we learned from the training were:

• deliver a shippable increment within each sprint, otherwise you have nothing to build upon
• select no more work then you can finish properly
• work on one thing at a time
• product owner must learn to demand less. Take it as an opportunity to focus on value not quantity
• when under pressure, drop low value items not quality
• people are able to form and manage their teams on their own

At one point, Ken made an interesting historical note about the early days of Scrum: It’s not that the world was missing the truth with respect to development. But what made Scrum possible was a change in development environments towards integrateable and automatically testable systems, a feature that first arose back in the days of smalltalk projects. Lucky for us, we were born too late…

Ken Schwabers concluded with the words

I think we have one of the best profession one can imagine; do your best to transform it back into something enjoyable!

Thanks Ken

Canoo meets Ken

So you’re thinking about getting an IT certification? Congratulations, you have discovered the Pragmatic Programmer Tip #8 – “Invest Regularly in Your Knowledge Portfolio”. But before you sign up, pay your fee, and spend your time chasing a certification, consider two points from the fine print from the Pragmatic Programmer book: Manage Risk and Buy low, sell high.

I do not have a Java certification, despite it being my primary language. There is risk for me to get this certification… I might spend all my time studying and then fail the test! I don’t think “studied for the certification exam” looks as good as simply “I am certified”, but that’s what I might end up with after several weeks of work. And there is also the risk that I am buying high and selling low, instead of the other way around. The Sun estimate for getting the Developer cert is 160 hours! This is a huge investment and I am not sure I’ll recoup the cost quickly enough. Perhaps there are better alternatives? Is there something that offers just as much benefit but with less effort? Or more benefit with the same effort? If there is, then the decision on whether to get a certification or not is an easy “no”: it’s ain’t worth your time kid.

The following is a table of all the things I’ve done in the last 12 years and the amount of time it took me to accomplish them. If the numbers are accurate, then it should be fairly simple to make a cost/benefit analysis of different knowledge portfolio endeavors.

And here is my guess about the Java certifications a few of us Canooies are considering:

And the results?

Here are some equivalent scenarios on how to spend the next 80 hours of your life:

• Sun Certified Java Programmer (80 hours)

or all of these combined:

• 2 In house technology presentations (16 hours)
• 2 Open Source Contributions (16 hours)
• Scrum Master Certification (16 hours)
• 2 Book Study Groups (32)
• And you have fun doing it!

In my opinion, the latter list sounds better than the previous list. Problem is, my opinion doesn’t count for much when it comes getting in the door as a contractor or consultant. If you are looking for a new full time job, then I recommend that 2nd list and skip the Java cert. For contractors/consultants, it pains me to say it but the Java Certification still seems like a decent value for the cost.

So what is your custom plan this year? The first list or the second?

This article originally appeared in the April 2010 edition of GroovyMag, the Groovy and Grails magazine. Parts 2 and 3 are currently available for download from the magazine’s site, and more will come each month. Enjoy!

The Groovy Programming Language advertises itself as an “agile and dynamic language for the JVM”, but what does this mean exactly? This series of articles explains Lean Software Development, and shows how your choice of programming language can make your entire process remain nimble and adaptive. Each month will cover one of the seven Lean Software Development principles and explain how Groovy and the associated ecosystem help eliminate waste, defer commitment, and build quality into your product.

About This Series

Most of your agile team will spend the majority of their day working with a programming language, making it one of the most important tools to optimize in your project’s life-cycle. Yet many organizations are reluctant to experiment with newer languages and frameworks, instead preferring to apply what works in one domain to all domains. They are skeptical about the claimed productivity gains from polyglot programming, concerned about the educational investment of retraining their developers, and worried about the risk of using less proven technologies.

Some languages are truly better than others for certain types of problems. These articles exist to help you identify which domains in your project are most in need of a little Groovy magic as well as to help you sell Groovy to a skeptical or unconvinced audience. Hopefully you will see that Groovy is a great fit for your software life-cycle: its dynamic and expressive nature brings greater productivity to testing and operational support, its closeness to Java minimizes educational investment, and its tight integration with the JVM platform allows you to slowly phase in Groovy without an all-or-nothing decision, making its use a low risk decision.

Groovy is an agile programming language. In order to explain what this means, these articles are structured around the seven principles of Lean Software Development. This month includes a short introduction to Lean, and you’ll see how an expressive language can eliminate waste in unit testing. Next month you’ll see how the easyb Behavior Driven Development framework builds quality into your software development life-cycle. Later we’ll explore how different testing tools like the Spock Framework help create knowledge, how a dynamic language lets you minimize coupling and defer commitment, and how metaprogamming allows you to deliver your software fast. In future installments you’ll see how Groovy’s Grapes module system, alongside modules like Groovy Web Services, streamline interactions between your development team and other groups like Operations and QA. Finally, we’ll look at how Groovy can be applied to domains that cross departmental boundaries: how Gradle improves the build process and easyb facilitates collaboration and communication between team members and other stakeholders. The series will end with a discussion of best practices when mixing Java and Groovy

Some of the code examples are basic while others are advanced. This series explores why the features of Groovy are important rather than the mechanics of any one Groovy feature. Hopefully you’ll leave with some new ideas about how to use Groovy, how to convince your team that Groovy is worthwhile, or most importantly how to increase your productivity.

Lean Briefly Explained

Lean manufacturing grew out of the influential Toyota Production System, which was a set of both philosophies and practices designed to weed out waste, inconsistency, and overburden from a manufacturing process. While the Toyota brand recently took a beating for some public quality failures, it is hard to ignore several decades of successful engineering sensitive product development. In the late 1990’s, Mary and Tom Poppendieck took their knowledge of Lean and applied it to a software project, eventually resulting in 2003 with the publishing of the excellent book “Lean Software Development”. The Lean principles have been revised over time; for our purposes we will use the seven principles from “Implementing Lean”:

1. Eliminate Waste
2. Build Quality In
3. Create Knowledge
4. Defer Commitment
5. Deliver Fast
6. Respect People
7. Optimize the Whole

Lean has been an influential movement within the agile community, spawning a plethora of books, workshops, and articles. Besides being a meaningful set of practices in its own right, it has also directly influenced other agile family Members such as Kanban Software and Real Options. Lean is a set of principles first and a group of practices second. The principles are specific enough to align a team but broad enough to appeal across an organization. I once spent a three-hour car ride discussing eliminating waste with the senior manager and director of my development group, and then arrived at work to help an eager development team make practical changes to reach the goals we had discussed. Compare that to a methodology with principles of “Honesty” and “Communication”. I have
yet to find a use for vague principles beyond their ability to make me feel a little better about a crummy process.

Principle 1 – Eliminate Waste

Taken literally, it is easy to see how Groovy fulfills the Lean mandate to eliminate waste: list and map literals, a terse closure syntax, and even a lack of semi-colons means there is simply less keyboard typing to do for Groovy developers. But that isn’t what Lean means by eliminating waste. The real waste within the software process is in half done work. Work that has been started but not delivered eats up the time investment from developers but does not provide value to the client. Any work that has been started but not completed is a form of waste, and we must optimize our life-cycle to keep our user stories out of this state! This means moving stories to Done faster, and any good agilista will tell you Done isn’t done until the unit and acceptance tests pass. Having used Groovy as a testing language on several projects in the last few years, my team’s experience is that the same test coverage and quality can be reached with Groovy in less time than it takes using Java.

Good unit testing means testing not just the success scenarios, but also the failure scenarios and the edge cases where things just barely pass or just barely fail (bugs do tend to congregate in corners, after all). This means your unit tests have to create data, and lots of it. Much more data than your production code needs to create. And Groovy is a language better optimized to create data than Java. Consider the data driven test in Listing 1.

public void testSimpleMath() {
  [   4: { 2 + 2}, 
    6: { 2 + 2 + 2}, 
    8: { 2 + 2 + 2 + 2}, 
  ].each { expected, actual ->
    assert expected == actual()
  }
}

The example shows a few ways in which Groovy is different from Java. Should read: First, a Map is declared using the notation [key1: value1, key2: value2, ... ]. So in the above example there is a map of type Map<Integer, Closure> with three entries, which sure beats having to use new HashMap().

The values of the map are Closures, which are function objects. The closure can be executed and passed arguments just like formal methods. They can also be passed around to other methods, returned from methods, and assigned to fields. Very, very powerful. Think of them as Runnable or Callable objects without the awful syntax.

Finally, the each method is just a method on Collections and Maps that iterates over the collection, executing the attached closure once for every element. You can see how this closure runs a simple assertion, asserting that the integer key of the map equals the evaluated value of the map.

With a minimum of non-essentials, this test creates a dataset to be used as test input and then executes the test against that input; it is a data driver test, without a framework, without needing to hide any of the mechanics of the test, and without a bunch of annotations and factory methods. Data driven tests are so easy to write in Groovy that you end up using them far more often than in Java.

Listing 2 is another data driven test with a more useful assertion than simple arithmetic:

public void testUserService(userService) {
  [   user1 :  ["John", "Doe",   123456], 
    user2 :  ["Jane", "Doe",   654321], 
    user3 :  ["John", "Smith", 789987], 
  ]. each { username, userData ->
    def user = userService.get(username)
    assert user.firstName == userData[0]
    assert user.lastName == userData[1]
    assert user.id == userData[2]
  }
}

This time the data is a map of Strings to a list of values (within Maps, unquoted key value are treated as Strings, so user1 and user2 are Strings). Java purists will notice that the generics of this expression are not easily expressed in Java, while they can be ignored in a dynamic language like Groovy. In this example the assertion block is simply pulling elements out of the list using the subscript operator [0] and [1] instead of the List#get(int) syntax.

The point is that the Groovy language features (list and map literals, closures, good iteration functions) allow you to write data driven tests more quickly, which in turn means you cover more edge cases and more failure scenarios as well. The minimal syntax of Groovy allows you to get down to the essence of a unit test: clearly show the input, execute the system, and clearly assert the output. Sure, you can Extract Method in Java until you have something with minimal accidental complexity (maybe even “extracting until you drop”), but as Alan Shalloway says, “There is a big difference between eliminating waste and not creating it in the first place.” With Groovy you will write tests faster and you will have your story cards spend less time in the “in process” phase. This is good for your project and good for your customers.

* “Extract Until You Drop” is a blog post from the inimitable Uncle Bob Martin about taking Extract Method refactorings to their logical, if absurd, conclusion. The piece could just have easily been titled, “Writing Clean Code in Java is a Complete Hassle”.

What happened to assertEquals?

Sure, using Groovy’s assert makes your tests more terse, but more importantly check out the exception message on a failing assertion in Listing 3.

def one = "1"
def two = "2"
assert one + one == two

Treating addition as String concatenation is endearing when your four-year-old is learning arithmetic but is an error in most mathematical systems. Listing 3 is interesting because of the exception message: each element of the expression is clearly expressed in the monospaced message: all three variable references as well as both the operators (+ and ==). Lower ceremony, clearer tests, easier debugging.

Next Steps

One particularly useful Lean practice for eliminating waste is Value Stream Mapping. Sit down at a whiteboard with your development team and write out your software process: the steps and time it takes to move an idea from inception to customer delivery. Where are the bottlenecks? What are the delays? Why does it take so long? Visualizing and quantifying your process helps everyone clearly see problem areas. And who knows, maybe a few Groovy scripts here and there can cut days out of your cycle. Stranger things have happened.

Next Month: Build Quality In

A lean, stream-lined development cycle with minimal waste is nothing if quality suffers. Next month’s article explores how Groovy helps you build quality into your development life-cycle. Instead of inspecting your product for defects after it is built, change your process to not create the defects in the first place. Easier said then done. Luckily, Groovy programmers can use great tools and techniques like easyb, Behavior Driven Development, and builders to build quality into their products.

Learn More

The world is overflowing with books and articles about agile development. These three books are classics and deserve a permanent spot on the bookshelves of discerning programmers.

• Implementing Lean Software Development – Poppendieck
• The Pragmatic Programmer – Hunt and Thomas
• Extreme Programming Explained, 2nd Edition – Beck and Anders