Many, many tools perform static analysis on code. There are all sorts of automated ways to look through your code and tell you if there are likely errors or not. FindBugs, PMD, and CheckStyle are some of the big names from the Java world. On the Groovy side we have two real options: IntelliJ IDEA and CodeNarc.

This post highlights my favorite static analysis rules for Groovy in IDEA that are not enabled by default. Groovy in IDEA 11 has well over 100 rules, but less than half of them are activated when you install the product. To turn these rules on you’ll need to go into Settings (Ctrl+Alt+S) and enable them under Inspections.

So here are my favorites that I think you should turn on:

Threading
Threading comes first because these inspections have saved my butt in the past. None of them are enabled by default, so do yourself a favor and enable a few. These ones are all must haves:

* Access to static field locked on instance data – Reading and writing a static field from multiple threads is not thread-safe. It needs to be done within a synchronized block. Do you know what happens when you synchronize on instance data, like this:

class MyClass {
    static resource
    final lock = new Object()

    def initialize() {
        synchronized(lock) {
            resource = new Resource()
        }
    }
}

* Synchronization on non-final field – If you are accessing a variable within a synchronized block then your synchronization token must be final. Consider this code:

class MyClass {
    def resource
    def lock = new Object()

    def initialize() {
        synchronized(lock) {
            resource = new Resource()
        }
    }
}

* Synchronization on variable initialized with literal – Do you understand the problem with synchronizing on a primitive literal? Consider this code:

class MyClass {
    def lock = 'my lock'

    def initialize() {
        synchronized(lock) {
            // do something
        }
    }
}

* Unsynchronized method overrides synchronized method – In some limited circumstances you may actually want to override a synchronized method with an unsynchronized one. But probably not. More than likely you don’t even know and you are accidentally creating a subtle bug. If the parent is synchronized then the child should be also. Or better yet, make the parent final.

Probably bugs
* Named arguments of constructor call – This inspection warns you when something like the following happens when using named arguments, which is almost certainly a bug:

class Order {
     int orderId
}

new Order(orderid: 5)

* Access to unresolved expression – There has been a lot of talk over the years about adding static compilation to Groovy. Some people want to be warned by the compiler or in the IDE if their Groovy code is referencing an object that does not exist. For example, they’d like this to produce a warning or error:

def c = { parm ->
    println it
}

Control Flow
There are many features in Groovy that simplify standard and verbose Java code. Two of these are the Elvis operator and the Null-Safe Dereference. IDEA contains inspections to help you migrate to the new way of writing code with these features.

* Conditional expression can be elvis – This inspection migrates you from code like this:

def x = value != null ? value : 2

def x = value ?: 2

* Conditional expression can be conditional call – This inspection promotes the use of the Null-Safe dereference. This following code produces a violation:

def x = value != null ? value.toString() : null

def x = value?.toString()

* If statement (or conditional) with identical branches - I periodically refactor code and accidentally leave an if or conditional statement with identical branches. These are of course redundant and can be cleaned up by removing the if expression. If you have good unit tests and use automated refactorings then this sort of things happens from time to time. The cleanup reminder is nice.

Error Handling
* Unused catch parameter - My favorite Error Handling inspection is ‘Unused catch parameter’. Consider this code:

try {
    doSomething()
} catch (e) {
    LOG.error('unexpected error occurred')
}

Validity issues
* Duplicate switch case – Groovy has Switch on Steroids, meaning you can put almost any object in the case statement, including regular expressions:

switch (input) {
    case ~/[0-9]/ : println 'numeric!'; break
    case ~/[0-9]/ : println 'a number'; break
}

Naming Conventions
Lastly, there are a whole bunch of naming convention inspections that you can activate and configure. If you’re not using CodeNarc (why not?) then you should at least activate some of these. Standards, on a whole, are good to adhere to.

IDEA Inspections of CodeNarc?
So which should you use, IDEA or CodeNarc? These two tools complement each other. There is good reason to use both CodeNarc and IDEA together. CodeNarc does have more inspections than IDEA, but the IDE integration in IDEA is better. Pressing Alt+Enter typically rewrites the offending code, and the speed of the actions are much better in IDEA. Also, the static analysis rules do not overlap between the products because the CodeNarc developers (that’s Chris Mair and myself) already use IDEA and made a conscious effort not to duplicate anything.

And if you do want to use CodeNarc and IDEA, then you might try out the CodeNarc IDEA plugin.

If you like this then you might check out some of my other IDEA related posts: The 10 Best Inspections You’re Not Using (in Java), or the IDEA archive on my blog and the Canoo blog.

And remember if you need Groovy and Grails help, then give us a call or drop me an email at hamlet.darcy@canoo.com

IntelliJ IDEA 11 was released a few weeks ago, and it contains quite a few new features for the Groovy developer. Everything listed here is in the free and open source Community Edition of IntelliJ IDEA. There are plenty of new Grails features as well, but I wanted to separate out the Ultimate Edition features into a different post. So let’s jump in.

Groovy 2.0 Support

The big promoted feature of IDEA 11 is the Groovy 2.0 support, which is itself mostly Java 7 support. In case you’re confused: Java 7 added some small language feature to Java (more here), and Groovy naturally supports the same syntax. The Project Coin Java changes are by definition small language changes, so don’t expect anything too major in terms of productivity boosts.

The first feature is underscores in numeric literals:

assert 1000000 == 1_000_000 : 'How awesome is that?'

Do you really need an explanation of this? OK, here it is then. You can put underscores into numbers and the compiler rips them out. They are just ignored. Just look at the .class file in a decompiler if you don’t believe me.

The second feature is binary literals:

assert 0b1001_1001 == 153: 'mind == blown'

This lets you specify integers using a binary format. As far as I can tell, this is mostly used if you’re constructing bit-masks to represent multiple states within one integer. You know, you could also use objects to do that and it might be clearer. But there are always times when you need this.

The third feature is multi-catch, which is the most useful feature of the three:

try {
    takeArrowToKnee()
} catch (InjuryException
     | LowHealthException
     | LowStaminaException e) {

    becomeTownGuard() // retire to a simpler life
}

This lets you catch multiple exception types in one catch block. In Java, you can Alt+Enter on an old-style catch to convert it into a multi-catch, but you can’t yet do that in Groovy. Don’t worry though, I created a ticket and it will soon be implemented…

Refactorings

For me the Groovy refactorings are one of the killer features of IDEA. There are a pair of nice upgrades in IDEA 11 in this area. The first is that Introduce Parameter works for closures now and not just methods. So if you start with something like this, where the literal 50 is hard-coded:

def adventure = {

    killMonsters() && collectLoot()
    if (health < 50) drinkPotion()
}

You can highlight the 50 and press Ctrl+Alt+P to Introduce a Parameter:

def adventure = { int minimum ->

    killMonsters() && collectLoot()
    if (health < minimum)  drinkPotion()
}

OK, so that is nice. A less well-known intention is the Unwrap Statement intention. Unwrap takes a statement that is wrapped in some sort of loop or conditional, and it removes that conditional. Witness:

Start with an If statement, choose to unwrap it, and you’re left with only the enclosed logic. Now that you know this trick, you will start to use it more often. It’s surprisingly useful.

Intentions and Inspections

There are also a couple of good, new intentions and inspections in 11. On the inspection side is the new “Incompatible In” inspection. You can use the ‘in’ keyword in, which is normally the inverse of ‘contains’. Using the in keyword to do incompatible type comparisons now triggers an IDE warning:

It’s a dynamically typed language, but as you can see the tools can easily catch your small type errors.

Also in 11 is my favorite intention, Convert JUnit Assertion to Assert. This converts your old-style JUnit assertion methods into Groovy power-asserts:

Just position the cursor at the method call and press Alt+Enter. And if you’re not sure why power asserts are an improvement then read this.

Also in IDEA 11 is ‘Split If’ and ‘Invert If’. We wrote these intentions ourselves at Hackergarten in Devoxx. Horray for open source! Split If takes a compound boolean operation like ‘if (a && b) { … }’ and converts it into ‘if (a) { if (b) { … } }. Invert If takes the boolean conditional in the If and inverts it. Both intentions are invoked with Alt+Enter and they are both described in more detail over at the JetBrains IDEA blog.

Besides that, the Import system got some new improvements as well. You can now use Alt+Enter to swap a qualified reference with an import, add a single-member static import, or add an on-demand static import. And my favorite: copy and paste within the IDE now carries the import statements with it. So if you copy a reference to the clipboard and paste it, then IDEA will ask you if you want to update the import statements. Whenever I switch back to a text editor I always miss the seamless import statement management provided by the IDE.

Groovy Isms

What else? Well, the IDE is now aware of @Category annotations and gives you correct code completion based on them. And you can finally specify a command line parameter when running a Groovy script from within IDEA. Hint: it’s the box marked ‘Script Parameters’:

Managing dependencies with Jars and Grapes got easier. If you annotate a script with @Grape when IDEA has always imported that dependency into the project for you. Well now IDEA removes obsolete @Grapes references when you no longer need them.

Lastly, there are many small UI improvements, such as overriding properties now have a gutter icon to show the relationship, multiple declarations on a single line now have better alignment, and pasting a slashy string now escapes the slashes. There are more as well, but they are even more minor.

Plus Grails Plus Java Plus…

And don’t forget, all the base improvements of IDEA, especially the speed improvements, will be felt in Groovy. The database UI has improved, the Navbar has improved, Git support has improved. It’s all there whether you’re in Java or Groovy. And like I said at the start, Grails has many improvements but they aren’t covered here… maybe in a later post after the holidays.

So long and happy holidays!

Need help with Groovy or Grails? Canoo Engineering offers training, consulting, and project delivery. Contact me directly at hamlet.darcy@canoo.com for more information.

Domain Specific Languages (DSLs) are often littered with the accidental complexity of the host language. Have you ever seen a supposedly “friendly” language expression like “ride(minutes(10)).on(bus).towards(Basel)”. The newest version of Groovy contains a language feature that aims to eliminate the noise of all those extra periods and parenthesis, so that your DSL looks more like “ride 10.minutes on bus towards Basel”. This article shows you step-by-step how to use Groovy Command Expressions and plain old metaprogramming to write just this DSL, and also offers advice on when, and when not, to use this new language feature.

The State of the Art with DSLs

Domain Specific Languages (DSLs) have been in vogue for a long time, and the topic has featured regularly at No Fluff shows for years now. The value proposition of a DSL rests in the idea that programmers and users benefit from expressing their desires in a language closer to English than to Java, using words suited to the problem domain rather than the programming language. The goal is not to create an entire new language, but to create a small language just big enough for users to capture their commands and intents in a more natural way than is typically possible in code.

Different languages support DSLs in various ways. Some languages make it easy to write nice, readable natural language-ish code and others do not. Over the next few pages we’ll explore the state of the art with Groovy DSLs, starting with looking at some unimaginative Groovy code, seeing how to convert into a better fluent interface, transforming it further using metaprogramming, and finally showing the full power of Groovy Command Expressions. As a sample problem, imagine trying to specify directions on how to get somewhere. By the end of the article you’ll understand how the Groovy code in Listing 1 works even though to looks almost like plain English sentences.

stand 7.minutes at busstop
ride 10.stops on bus towards Basel
stand 5.minutes at tramstop
ride 3.stops on tram towards Birsfelden

The Canvas

We’ll use the same running example through all of the exercises. So let’s start by painting out a few primitive ideas. Think of these basic building blocks as the undercoat to our DSL canvas. Thinking about your domain is always a good place to start if you’re considering writing a DSL. Think, analyze, and compare the domain to see how it should be naturally organized. If you read the example in Listing 1, you may notice a few similarities between the different lines of code. There are actions, such as ‘stand’ and ‘ride’. There are vehicles, such as a ‘bus’ or a ‘tram’. And there are locations, such as the ‘bus stop’, ‘Basel’, and ‘Birsfelden’. We’ll model the actions as methods later, so let’s skip those for now. Vehicles and Locations are fairly straightforward, so we’ll model those as Java enums, as shown in Listing 2. I’ve put them in a package so that I can do a static import on them later.

package nfjs

enum Location {
    busstop, Basel, tramstop, Birsfelden
}
enum Vehicle {
    bus, tram
}

There is also something else in common between all of the instructions from Listing 1. They all have a duration or distance, such as ’7 minutes’ or ’10 stops’. A duration is a little bit harder to model, but not much so. For sake of simplicity, we’ll just define a Duration class that represents either a unit of time or a unit of distance, as shown in Listing 3. I applied the TupleConstructor annotation to generate a set of constructors on the object, making it a little easier to work with.

@TupleConstructor
class Duration {
    int value
    String unit

    String toString() {
        "$value $unit"
    }
}

The last bit of undercoat to apply to our canvas is the Instruction object itself. Listing 1 creates a list of Instructions behind the scenes, so we’ll need to model those as well. Similar to Duration, it’s a simple data type with a few properties and is shown in Listing 4.

@TupleConstructor
class Instruction {
  String action
  Location location
  Duration duration
  Vehicle vehicle

  String toString() {
    if (vehicle != null) {
      "$action $duration on $vehicle towards $location"
    } else {
      "$action $duration at $location"
  }
}

An Instruction has an action (stand or ride), a location (bus stop or Basel), a duration (five minutes or three stops), and optionally a vehicle (a bus or a tram). Now that the undercoat is applied, let’s look at some different ways to construct these Instruction objects.

Cave Paintings

The most primitive way to create Instructions is to call the constructors of objects directly. This is hardly a DSL but at least it is an improvement over the Java equivalent. There’s not much here to be proud of, and list literals like [] and the leftShift operator to add list elements is only a slight improvement over the alternative. At least Listing 5 is rather short.

import static cmdexprs.Location.*
import static cmdexprs.Vehicle.*

instructions = []

instructions << new Instruction(
    'stand', busstop, new Duration(5, 'minutes') 
)
instructions << new Instruction(
    'ride', Basel, new Duration(10, 'stops'), bus
) 

The problems with this code sample is that there is a lot of accidental complexity: pieces of the underlying programming language bleed through and obscure the intent. In the first instance, only the words ‘stand bustop 5 minutes’ are essential to the problem of creating instructions. The other 59 of the 79 characters are non-essential complexity. A 25% signal to noise ratio is pretty poor. The classical solution to this problem (in a sense that it can be applied to Java code as well) is to create a fluent interface around Instruction objects so that the end user is shielded from these implementation details.

Classicism

A fluent interface is a way to chain method calls together in order to eliminate a lot of the noise associated with configuring data. Fluent interfaces can be created with statically compiled languages as well (like Java) and requires no special metaprogramming facilities in the host language. The trick is to be creative with method return types. Listing 6 shows the result of improving our signal to noise ration after refactoring to a fluent interface.

stand(minutes(5)).at(busstop)
ride(minutes(10)).on(bus).towards(Basel)

This is a big improvement and raises or signal to noise ratio from 25% all the way up to 75%. The only noise left in this example is the parenthesis party nestled between all the interesting bits. Hmmm, looks like someone invited a few periods along as well. We’ll do better in the next example, but let’s look at how to implement this fluent interface first.

As I said, the trick is to be creative with return types. For example, the code ‘minutes(5)’ actually instantiates a Duration object for us (Listing 7), which is then passed into the ‘stand’ method as an argument.

def minutes(int length) { 
    new Duration(length, 'minutes') 
} 

The trick is to make all of the method calls chain together. So the ‘stand’ method needs to return something that has an ‘at’ method on it, and that in turn needs to accept a Location parameter and create the actual Instruction. Technically speaking, stand is a higher-order function: it is a method that returns to you a method. Groovy’s dynamic typing and map-implemented interfaces make this a pretty simple task, as shown in Listing 8.

def stand(Duration duration) {     
  [at: { Location loc ->
    instructions << new Instruction('stand', loc, duration)
  }]
}

In Groovy, an object can be created as a Map literal using the [key: value] syntax. If the keys are Strings and the values or Closures, then that object can be treated as an object and have methods invoked on it, which is what Listing 8 shows.

At first, fluent interfaces often seem complex to implement. But after writing one or two you’ll often find it is really not too difficult. You have to think differently about how you craft an API, but in the end you can get a lot of usage and nice APIs using a fluent interface instead of metaprogramming. Let’s turn now towards bouncing some of those pesky parentheses out of the party using a little Groovy metaClass magic.

Impressionism

In our tour of DSL art, I’m calling the next technique impressionism. Like impressionist paintings, it does a slightly better job of capturing the intent than the previous example, but if you examine it closely it doesn’t seem to be much clearer than the alternatives. The motivating code is in Listing 9, can you spot the difference?

stand(5.minutes).at(busstop)
ride(10.stops).on(bus).towards(Basel)

There are two less parentheses, but an added period. ‘minutes(5)’ became ’5.minutes’. The signal to noise ratio improvement is marginal; the advantage here is that the code more closely resembles the away we speak. Nobody sticks their head over the cube wall at 12:05 and asks, “Do you want to go to lunch in minutes 5?” Instead, they say “5 minutes”, which is exactly what this code says. This is a small change to implement, and listing 10 shows that making the language support singular and plural words is just a few lines of code.

Integer.metaClass.getMinute  = { new Duration(delegate, 'minute') }
Integer.metaClass.getMinutes = { new Duration(delegate, 'minutes') }
Integer.metaClass.getStop    = { new Duration(delegate, 'stop') }
Integer.metaClass.getStops   = { new Duration(delegate, 'stops') }

What’s happening here is that we’re adding a method called ‘minutes’ and ‘minute’ onto the Integer class, and this method is creating the Duration object for us. Other than replacing the old ‘minutes()’ method with these four lines of code, there is no change to the previous example. The code all just stays the same.

The combination of fluent interface and metaprogramming is powerful. Sure, there are some issues with periods and parentheses, but overall it is a pretty big improvement over trying to call constructors and wire objects together in Java. Groovy 1.8 takes things a little bit further and leaves us with the best example yet.

Expressionism

The last example is the best. It contains a minimum of accidental complexity and Groovy bleed-through and looks almost like the English language equivalent. For fun, I encourage you to compare Listing 11 with the cave paintings listing in Listing 5. It’s quite a bit improved.

stand 7.minutes at busstop
ride 10.stops on bus towards Basel

I call this final version Expressionism, not because it relates very well to the 20th century art movement of the same name, but because it uses a new feature called Command Expressions and is the most expressive of all the examples.

So what are the code changes? You might notice that there are no more listings in this article. That’s right, command expressions are just the way code may be written now. Listing 11 showing the command expression usage and Listing 9 without the usage are functionally equivalent. ‘Stand’ and ‘ride’ are still method calls that return the ‘at’ and ‘on’ methods. As long as the code follows the follows the pattern ‘method parameter method parameter method parameter’ then it gets converted into ‘method(parameter).method(parameter).method(parameter)’. You can chain as many together as you like; Groovy won’t complain. The result is a nice readable chain of expressions without any additional effort. At the time being, Command Expressions are the state of the art when it comes to DSLs in Groovy.

Art Criticism

There are a couple of pitfalls to be wary of. Command expressions are shown here in the best possible light in order to display their power. In reality, they are also a little fragile. Any code not following the ‘method parameter method parameter’ rhythm doesn’t easily fit into the command expression pattern. The result is that you might have to twist your words a little to make them fit into this pattern, which moves it away from natural language and towards accidental complexity. Also, there is always the Groovy grammar and keywords to look out for. For instance ‘for’, ‘native’, and other keywords cannot appear in your DSL, a problem which other languages do have solutions for.

Also, it is probably best to avoid command expressions outside of DSLs. The code ‘list.collect{ … } each { … }’ looks like a syntax error to most Groovy programmers because there is a period missing before the each method call. However, it isn’t wrong and works just fine. Confusing, but correctly functioning. Currently, Groovy programmers are used to some parentheses and periods, and it’s confusing to leave them out unless you have good reason.

Create Your Own Art

Thus concludes the tour of the state of the art with Groovy DSLs. To start, Groovy fluent interfaces are a great way to organize an API and make it easy to use. While not a true domain specific language, in a low ceremony language like Groovy they can go a long way towards increased expressiveness and better signal to noise ration without resorting to programming trickery. For more power, start to use metaprogramming to fine tune the the exact API you need, and use Groovy Command Expressions when you need them. How go forth and make your next DSL a true work of art.

Need help with Groovy? Canoo is ready to tackle any challenge. Contact info@canoo.com to learn more about Groovy Training and Consulting.

Opinions expressed in this post are totally my own and not necessarily that of my employer.

Wednesday started with the infamous “scriptbowl”, a competition between various scripting languages. This year the contenters were JRuby, Groovy, Scala, and Clojure. I wondered whether Scala considers itself a scripting language but obviously they either do or just seek the opportunity to be on stage.

To keep a long story short: Groovy has won this event for the third time in a row! This year the race was tied with Scala. Guillaume presented Groovy in the typical Groovy-idomatic style and explained every single line of his concurrent visual analyzer for Google+ postings. Dick Wall presented only non-idomatic Scala code. I interpret this as: to make Scala appealing you have to make it look like Groovy. Furthermore, he presented Kojo, which is a great interactive learning environment written in Play/Scala. In contrast to all other presentations, this was not specifically created for the scriptbowl, nor was it written by the presenter, nor was it clear how much effort went into it, nor did the audience see a single line the implementation code. How much this skewed the comparison, I leave to everybody’s judgement. The show was good, though.

I felt a bit sorry for Clojure. It is a great language and deserves a presentation that is more visually appealing to convince the crowd.

Afterwards, I attended a hands-on lab for “rapid enterprise development with netbeans”, which was essentially creating a Swing app for database CRUD actions. If I remember correctly, I did the exact same task 1997 with JBuilder. It left me with the feeling of “Yes, it works” but it is not less complex than it was 13 years ago.

Early afternoon Gerrit Grunwald (better known as @hansolo_) presented his work on simplified custom components for Swing. Given that he speaks about an activity that is both utterly important and highly underadvertised he would really deserve speaking at the center stage.

Graeme Rocher’s great session about Grails, polyglot datastores (hibernate, jpa, redis, mongodb, …), and the cloud was overshadowed by the news that Steve Jobs has died. Accidentally, the demo application was about showing a BBC News stream, which displayed this information live on stage. Both the presenter and the audience were equally touched.

The day officially ended with a big event at treasure island. I decided to not go there, though, and meet the former Canooey Denis Antonioli in Berkely where we had a great evening.

Dierk Koenig

Finally, late in the evening I joined Dan Sline’s talk on WebServices in the Groovy space. The major take-away for me was a repercussion of the well-known advice: “keep it simple”.

Throughout the day, a lot of people approached me to tell how much they liked my talks yesterday. That was a really nice experience. Last year I had the very last talk of the conference and only this year I recognized how much of a difference the scheduling of the talks make.

Dierk Koenig

The technical keynote started with a weird JavaZone-style video featuring a Java programmer as a rapper. It was certainly intended to be funny but as far as I can tell, it didn’t catch on.

The keynote was packed but the somehow reduced ballroom layout added to this impression. Attendance was said to be twice that of last year (so probably around 10’000). Even though there are certainly more people than last year, a doubled number seems a bit exaggerated to me. Throughout the day, all talks were well attended, though, but nothing like in the days when JavaOne had 10’000 attendees in Moscone Center.

The technical content was not surprising, beside that Oracle now advertises its NoSQL solution, which is based on the former Berkeley DB. As expected JavaFX 2.0 GA has been announced along with the respective tooling and covered by 50 (!) talks on JavaFX at JavaOne. The JavaFX presentation started very conventionally but in the end showed some really cool lab projects with a dancing duke steered by gesture recognition.

The best presenter was Mark Reinhold on Java 7/8/9. Good style, nice slides, perfect pace, interesting (but not really surprising) content. New to me was project Nashorn: new JavaScript implementation for the JVM expected for Java 8. Project Lambda is planned to contain “defender methods”, default implementations for interface methods. That sounds like traits and actually I expect some issues when doing this in Java.

Overall, the keynote was missing the JavaOne “feeling” from the olden Sun times. There was no host that led through the event, welcomed the attendees, and encouraged everybody to network. No big names on stage, no overwhelming achievements. The crowd left the room unexcited.

For the rest of the day I was mainly concerned with preparing and delivering my own talks on “Extending Java’s reach with Groovy” and “Pro Groovy”. They were well attended and received.

Andres delivered his Griffon talk in parallel.

Afterwards, I was a tired but still listened to Charles Nutter on JVM bytecode, Dan Sline on Griffon, and Jim Discroll on Groovy DSLs. Quote to take away: “Oracle ADFm makes heavy use of Groovy!”

That’s it for today.

This is gonna be a short series about my impressions of JavaOne 2011.

As always, it is nice to see the town decorated for the event, even though Oracle World gets certainly much higher attention. So the immigration officer as well as the nice guy sitting next to me on a bench at Union Square ask “ah – you are a programmer? Are you here for Oracle World?” “Hmpf…”

Should you ask yourself “what’s in for me”? Here is a first answer: the conference material

The bag is not very practical for a software developer. I guess the selection has been taken by an Oracle employee who assumes that their conference attendees never carry any material themselves in the first place (which may be true for OracleWorld). The jacket is very nice, though.

And, yes, you can rate conference organizers by the badges they produce. Hey, that should not be too difficult, right? Here is what you still can make wrong:

• Printing the delegate’s name so small that it is hardly readable from more than 20 cm away. Now since the badge usually hangs at belly height (if not lower) this can be a bit embarrassing for both involved parties.
• Second, the name belongs on both sides of the badge! Really! How often did you try to read the name only finding that the badge hangs the wrong way around?

Otherwise, the waiting time was not too long. The speakers registration was actually empty when I arrived. The attendees registration was pretty well filled, though. But then everybody has to go to the material pickup which was for me in Moscone West 3rd floor where I waited in line for about 20 minutes and I was very early and the queue grew much longer afterwards.

This made me think about my latest work on highly concurrent producer-consumer scenarios (http://people.canoo.com/mittie/kanbanflow.html) and what it would need to improve the situation.

Otherwise, from studying the program schedule, I found that Oracle has wisely chosen to pretty much always put two Groovy-related talks in parallel as if to make sure that nobody can escape the Groovy (\G) in these time-slots.

I’m eager to see what the week will bring.

Dierk Koenig, @mittie

This screencast demonstrates how to use Spock testing specifications and Groovy for mocking and stubbing behavior in unit tests. It covers creating the mock object syntax, setting expectations, verifying and spying on results, and argument matchers.

If you have any issues with video playback, then trying viewing it from the JBrains.tv website

Here are some useful links to read for this webcast:

• Spock Framework – http://code.google.com/p/spock/
• Spock Basics Screencast: http://tv.jetbrains.net/videocontent/ffff
• Mocks and Stubs aren’t Spies: http://hamletdarcy.blogspot.com/2007/10/mocks-and-stubs-arent-spies.html
• Mocking with Spocks: http://www.canoo.com/blog/2010/04/20/spock-and-test-spies-a-logical-choice/

I’ve made a lot of screencasts and blog posts over the years. If you like this, then there are many ways to see the other stuff I’ve done:

• My main blog: http://hamletdarcy.blogspot.com
• My other JetBrains.tv posts: http://tv.jetbrains.net/tags/hamlet
• IDEA related posts on my blog: http://hamletdarcy.blogspot.com/search/label/IDEA
• My screencasts on YouTube: http://www.youtube.com/user/HamletDRC
• IDEA related Posts on my work blog: http://www.canoo.com/blog/tag/idea/
• Or follow me on Twitter: @HamletDRC

Phew, that’s a lot of self-promotion

The screencast was created with Ubuntu 10.04, PiTiVi, Audicity, gtk-RecordMyDesktop, IntelliJ IDEA, and LibreOffice. OS from top to bottom.

Thanks for watching, and leave a comment!

Last week I sat down with the gang at the Grails Podcast and talked shop for about 45 minutes. We talked about a lot of different topics such as Groovy, Lean software, Spock, Groovy in Action, and of course Hackergarten. Check out the full audio and shownotes over at Grails Podcast Episode 125.