Effective Groovy with CodeNarc 0.12

The new release of everyone’s favorite static anaylsis engine for Groovy is here. Time to download CodeNarc 0.12 while it’s hot. And in case this is your first time, CodeNarc analyzes your Groovy code and looks for potential problems and errors, creating a nice report or flagging the problem in your IDE. It’s like FindBugs, Lint, or PMD, but for Groovy.

So what’s new in 0.12? Performance improvements, 35 new analysis rules, and a new logo. It’s supposed to be an armadillo, but no one can tell. We’re calling it the CodeNarc Grue, as in “You are in a maze of twisty little groovy scripts, all alike.” Anyway, you can read the full rundown over on the Canoo blog. My blog post describes the rules and reasons why you might want to use them.

Read the Canoo Blog Post here.

And as usual, vote at DZone or Retweet to spread the word.

IDEA X for the Grails Developer

The new version of IntelliJ IDEA was released last week. I already blogged what IDEA X means for Groovy developers, and all of those features are obviously available to any Community Edition user (that’s the free one). This post looks at all the new Grails features available in the Ultimate Edition (the one you pay for). These features are a little harder for me to try out personally as my current project is EJB3 and not Grails (someone save me please!). I’ve tried quite a few of them personally, but feedback is always welcome in case I miss or exaggerate something.

As usual, you can read the full article over on the Canoo blog. Feeling magnanimous? Upvote at DZone.

Happy holidays everyone. Six years ago this week I decided to take a few vacation days at my in-law's house and finally get serious about learning Java. I wrote a little Swing app called "TimeTool" whose source code I would be thoroughly embarrassed by today. What a long, strange trip it's been.

Beginner Bash: Must-Know Bash Commands

I switched full time to Ubuntu Linux last year and haven’t looked back. In this year I’ve learned to love the Bash shell (which includes the Terminal in Mac and Cygwin on Windows). At this point, I can finally say I’m faster in Bash then I was in Windows Explorer, Commander, Nautilus, or the Windows command prompt; and I prided myself on being a guy with a lot of .bat files. My goal now is to write some tips I learned in the last year. Before explaining the more advanced stuff I want to introduce some of the most basic basics.

So here it is: "Stuff I wish someone had explained clearly to me a year ago". Almost all these apply to Cygwin in Windows as well as Mac/Ubuntu Terminal.

As is usual these days, the full article is available on the Canoo blog. And if you want to upvote then head on over to DZone or clicky clicky on up arrow at the bottom of the post.

Gradle Plugin Conventions: Groovy Magic Explained

Hackergarten last Friday was a big success. About 10 of us (not all Canooies!) stayed up late and created an Announce plugin for Gradle. In the 0.9 release you will be able to announce build events to Twitter, Snarl, and the Ubuntu notification service (sorry, no Growl yet, it is coming). It was fun, educational, and energizing, and you should sign up for the Google Group and come to the next event.

While writing the plugin, we were briefly delayed by a technical detail. The user guide explains how to pass simple parameters to a plugin, but does not explain how to nest parameters within a closure. For instance, in the announce plugin you specify the Twitter username and password within an announce block:

announce {
  username 'your-username'
  password 'your-password'
}

It turns out to be easy (just not documented, but we will fix that soon). Here is the full gradle build that shows you how to do it, with a detailed explanation of how it works below. As an example, we'll extend the Gradle documentation greeter custom plugin. This whole thing is runnable from the command line with "gradle hello":

apply plugin: GreetingPlugin

greet {
  message = 'Hi from Gradle'
}

class GreetingPlugin implements Plugin<Project> {
  def void apply(Project project) {

      project.convention.plugins.greeting = new GreetingPluginConvention()
      project.task('hello') << {
          println project.convention.plugins.greeting.message
      }
  }
}

class GreetingPluginConvention {
  String message

  def greet(Closure closure) {
      closure.delegate = this
      closure()
  }
}

Starting at the top... there is a property declaration called "message" within a "greet" block. This is a much nicer configuration option than just using build-global variables, and your plugin should do something like this. It is important to understand what this block actually is and how it works. In Groovy, parentheses on method calls are optional and curly braces declare a closure. So this greet block is really an invocation of a method with type "Object greet(Closure)". To read and capture this message variable, you must somewhere declare and wire in this "Object greet(Closure)" method within your plugin.

Moving on to the Plugin declaration. Plugin configuration is captured in something Gradle calls a "Convention" object. It is just a plain old Groovy object, and there is no Gradle magic... all the magic happending is standard Groovy. Let's examine the apply() method closely:

def void apply(Project project) {

  project.convention.plugins.greeting = new GreetingPluginConvention()
  project.task('hello') << {
      println project.convention.plugins.greeting.message
  }
}

During the configuration phase (before any targets are run) you will be given a Project object, and that Project object has a Convention object that holds onto a Map of all the project conventions. Three pieces of Groovy magic: Getters can be accessed with property notation, Map entries can be accessed with dot notation, and Map.put can be called with the = sign. So this line:

project.convention.plugins.greeting = new GreetingPluginConvention()

Is the same as the Java equivalent:

project.getConvention().getPlugins().put("greeting", new GreetingPluginConvention());

During the build, Gradle is going to execute the build script. Any time an unknown property is assigned or an undeclared method is invoked, Gradle will look at this plugins Map and use the respondTo method to check if any of the Plugin conventions accepts that variable. If it does, then your convention object gets invoked and that variable is set. Gradle takes care of translating an unknown method call of "Object greet(Closure)" into a call to your convention object. All that you need to do is make sure the greet(Closure) method is defined properly:

class GreetingPluginConvention {
  String message

  def greet(Closure closure) {
      closure.delegate = this
      closure()
  }
}

Now it is up to you to dispatch the parameters declared within the closure into fields on your convention object. If you just try to execute the closure then you will receive a nice PropertyMissingException because the "message" field is not declared anywhere. You get around this by defining a "message" field on your object and then setting "this" to the closure's delegate. Groovy method dispatch is flexible (complex?). Closures have a delegate object that will act as a sort of "this" reference when the closure executes. So the message field was out of scope when the closure was created, but adding a delegate makes the message field from the convention object in scope. When the closure assigns message a value, it will be the message on your Convention object. Check out my old blog post Fun with Closures for a more in depth explanation.

Now your convention object has the message String, hooray! You can do something interesting with it, like printing it out to the console:

println project.convention.plugins.greeting.message

Or maybe you had something more interesting in mind for your cool plugin. Let us hope.

By the way, you can just as easily declare a settings variable. This is an equivilent implementation of apply:

def settings = new GreetingPluginConvention()
project.convention.plugins.greeting = settings
project.task('hello') << {
  println settings.message
}

And now there is just one last piece of Groovy magic left unexplained:

apply plugin: GreetingPlugin

This too is plain old Groovy. Method parenthesis are optional. Method parameters can be passed in as name value pairs. And Class literals can be referenced without the .class extension. The apply plugin statement is really just a plain old method call in disguise, and it is an invocation of apply(Map). The apply statement can be written in Java as:

Map map = new HashMap();
map.put("plugin", GreetingPlugin.class);
apply(map);

Groovy magic is good. Thanks for taking some time to understand it. Hopefully this example makes it to the Gradle user guide in the next few days.

10 Lessons Learned from Usability Testing

This morning I published an article on my lessons learned from 7 years of experimenting with usability testing. It is called "10 Lessons Learned from Usability Testing". Creative, huh? The post is on the Canoo blog instead of here... most modern web browsers will show you the article if you click the link above. I say most because I can't trust IE 6 to do anything right.

If you like it then please do the up-vote thing at DZone.

Happy Friday everyone.

Groovy 2009 Year in Review and 2010 Predictions

Groovy in 2009

Groovy 1.6 Released
Groovy 1.6 was released at the beginning of the year, and the most exciting new features have turned out to be Grape and AST Transformations.

Grape allows a developer to declare dependencies within their Groovy source code and then, at runtime, Groovy will download and install the dependencies using Ivy repositories. Want to ship scripts to your operations team? You no longer need to email or build JARs! It's no Jigsaw, but maybe that's a good thing.

AST Transformations allow developers to hook into the Groovy compiler and alter the way the code is compiled. This has enabled great work like the @Bindable and @Delegate annotations, as well as many forward thinking (read: visionary) libraries like the Spock testing framework and the CodeNarc static code analysis tools. Watch for more cool libraries and frameworks to use these features in 2010.

Griffon Released
While Flex and JavaFX duked it out for developer mindshare in the coveted (and hyped) RIA space, a groovier team quietly forked the Grails codebase and adapted it for Swing desktop applications. Griffon is way more than a dynamically typed builder pattern on top of Swing components. Griffon gives you property binding to widgets (you're not the only one Flex), a standard and simple MVC architecture without a spaghetti monster diagram (that's you PureMVC), more components than just a TextBox (the complete JavaFX widget set last Winter), a plugin system that allows you to decompose problems into reusable addons, and an easy way to deploy your app via webstart. If the Griffon team can keep the energy they had in 2009 then 2010 should be the year of the lion. Or eagle... or dog. What the hell is a griffon anyway?

Groovy Tooling Explosion
Looks like IntelliJ IDEA has some competition for best Groovy IDE. The Groovy Eclipse plugin got new life as Andrew Eisenberg revived the project, and SpringSource released better Grails support in SpringSource Tool Suite. Was the open sourcing of IDEA a response to the new competition? Who cares, it's free now! While IDEA is still the best IDE for Groovy, Groovy users will surely benefit from each IDE maker trying to outdo the other.

VMWare Buys SpringSource
Seriously, who saw this coming? This week at Groovy/Grails Exchange, Graeme Rocher demoed deploying to the cloud from his IDE (according to Twitter). Easy cloud deployment is good news... it will end the monthly "who do you use for Java hosting?" questions on user groups. Now if only the price would come down.

GR8 Conference
A Groovy conference created by the community, for the community, and priced for the community. It's great to see not for profit additions to the Groovy conference scene, and next year sees two GR8 events: one in Europe and one in North America (Minneapolis!). In other community news, Chicago Groovy Users Group started posting video sessions to blip.tv. Can we get some other GUGs to do the same?

A Groovy 2010

Don't think of these as predictions... think of them more as premature facts.

Gradle
To be clear: Gradle is not a Groovy technology. It is an enterprise build system written in Java with Groovy used as a build script. Anyway, the 0.9 release will include "Smart Execution/Incremental Compile" and 1.0 will support multi-threaded builds. These are enterprise level features that would be totally unique to Gradle... and they're sure to intice a lot of unhappy Maven developers. If the Gradle team can hit 1.0 and publish a book(!), then a lot of people will migrate.

GPars
I can't find anyone with anything bad to say about either the Fork/Join Framework or BMW Motorcycles... and I just sold my bike to spend more time coding. GParallelizer hasn't been widely adopted to date, in my opinion because it chased the Actor-Model hype a little too strongly. But now it's been rebranded GPars and an all-star team has been assembled to work on it. This isn't a good project to just follow, it's a good project to download and play with. Get the bits and join the mailing list. Your opinion counts! It's too bad that they hate cool the logo I made for them.

Griffon
The decision by the Grails team to make almost everything a plugin was genius. It provides a standard mechanism for everyone to modularize their own applications, and provides an easy path for users to push their non-business-critical plugins back into the community. If Griffon users embrace the plugin system, and then push their plugins back to the community, then Griffon could be a real alternative to JavaFX/Flex by the end of the year.

Java Closures
I wish the JDK team the best of luck meeting their September 2010 release deadline. While I have doubts that JDK 7 will ship in 2010, I do believe the closure syntax will be decided upon. And Groovy will be the first Java language to support that syntax. Whether a version of Groovy containing Java closures actually ships before JDK 7 is probably dependent on how the Groovy team wants to address the modularization issues of Jigsaw, which sounds like a much harder problem to solve.

Groovy IDE Support Improves... a little
IntelliJ IDEA still leads in features by a wide margin, but Eclipse and STS aren't stealing IDEA users, they're stealing TextMate users. People just want to debug without parsing all the files in the world. IDEA will remain the sole provider of Groovy refactorings, intentions, and auto-completions. But Eclipse will finally become a better alternative than a text editor. However, the open sourceing of IDEA should make it easier (and faster) to get IDEA support for newer frameworks, which is a good thing.

Groovy-User Mailing List Shuts Down
For the entire month of June, all posts to groovy-user will be answered with the same response: "This is covered in Groovy in Action 2nd Edition". By the end of the month admins will simply replace the mailing list home page with an advertisement for the book.

What Won't Happen

InvokeDynamic
InvokeDynamic is set to greatly improve implementing and running dynamic languages on the JVM. Only it won't be released until September 2010 at the earliest. Sure you can get the OpenJDK now, but most users won't do that. I predict InvokeDynamic being the story of 2011, not 2010... and even then I bet the JRuby guys beat us to it.

The Java Store
Let me get this straight... you want me to pay US$50 yearly so that I can give my Griffon app away free on the Java Store? You gotta be kidding. Griffon + the Java Store could be a match made in heaven: Griffon makes JNLP Webstart simple to configure and the Java Store handles hosting the files. But Sun/Oracle is turning too many hobbiest and small time developers away with their entrance fee. Are you listening Mr Ellison? I said I want... oh wait, you're not listening. How hard would it be to make the Groovy Store?

This was fun. What are your Groovy 2009 highlights and 2010 predictions?