Overall, much better buzz than last year. The content of the sessions was much higher; there were fewer keynotes, which was fine. Mainly, though, there was just a better buzz.

There was a large Scottish contingent, and we’ll be giving an overview of the event at the next Scottish Ruby User Group meeting. It’s at 19:30, at The Edinburgh Training Centre, 16 St Mary’s Street, Edinburgh, EH1 1SU. In the meantime, a few random quotes (ok paraphrasings) from my notes:

Dr Nic:

Java is like Keith Richards: used to be cool, can tell you stories about itself, but not so cute anymore.

Jason Hoffman (in an aside):

The more they pay, the less they complain. If you want a difficult user base, give your stuff away for free.

Dave Thomas:

Make something beautiful. And if you do….. let me know by signing your work.

“It’s time to deprecate Java as a language.” Venkat Subramaniam during the NFJS, London panel discussion

For a Java conference, the focus of a lot of the London NFJS was beyond Java: not Java hating, but a feeling that Java has had its innings and it’s time to move on. And a lot of the moving on was to Groovy.

I hadn’t previously paid much attention to Groovy. After all, I have Ruby. Now there are many reasons to sit up and take notice:

• The Java to Groovy migration path is miniscule. Swap javac for the latest version of groovyc and you can mix in Groovy with your Java classes: groovy can call Java; java can call Groovy. It all compiles down to bytecode so the JVM doesn’t care.
• Major support for Groovy in IntelliJ 7.
• It’s got pretty much all the items on my “what I would like Java to have had” shopping list including
  
  
  
  • closures
  • dynamic arrays
  • language support for Maps (Hashes)
  • metaprogramming and open classes (recent addition)
  • operator overloading

Groovy did not hog the “moving on from Java” vibe, though. JRuby got a look-in and Neil Ford gave a keynote on “Polyglot programming”. Neil expounded on an idea that seems to be coming back into fashion: the Unix idea of using the right “sharp tool” for the job applied to programming languages.

Peter Aitken has a good account of August’s No Fluff Just Stuff event in London here. I also have more observations.

Grails

Just as I previously had not bothered to look at Groovy, I didn’t previously see the point of Grails, given Rails. Again, maybe I was wrong. Reasons for considering Grails:

• it sits easily on a JVM, if that is what you need to use. Unlike JRuby, it compiles completely down to bytecode.
• being Groovy it can integrate with Java Code with fewer seams.
• it is layered on top of Spring and Hibernate, enabling use of Hibernates mature and reputedly excellent caching mechanisms.

I should admit that I haven’t yet used Grails in anger, so I can’t really vouch for it properly.

RIFE

RIFE is yet another Java Web Framework. It distinguishes itself by not only achieving “Rails-like” constraints in Java but by actually implementing Continuations for control flow. Which all goes to show what you can achieve if you really try.

AOP

AOP is another thing that I never so enough point in to really try out, beyond a few well-defined cases such as marking transaction boundaries. Brain Sletton introduced AOP as a tool for enforcing or monitoring policies, such as class A can only be called from classes B or C. Now this seems to be a very Directing rather than Enabling tool. My impressions was strenghtened when Brian suggested that the Junior developers could be left to write the main code, while the senior developers (architects) controlled them with AOP.

To be fair, though, he did give quite a compelling example of using AOP for good, using it to detect all the places in an inherited Swing application where threading had been incorrectly used.

Full stack frameworks

Most of the web frameworks presented, Grails, Rife, JBoss Seam were full stack. I’m guessing this is a move away from the complexity, integration issues, and burden of choice of the mix and match approach that previously held sway in Java land.

Bending Java

Of the two pure Java language sessions that I attended, AOP and Rife, both involved bending Java to be other than it was designed using byte code jiggery pokery. If you need to do that kind of thing to get the language to behavae close to how you’d like, maybe you’re using the wrong language.

I’ve been reading these kinds of polemics about analysis outperforming expertise/intuition for years and they strike me as silly, like the fantasy tournaments children sometimes invent: Can a lion beat a shark? (It might depend on whether they were fighting above or below the waterline.) Who would win, a superhero with infinite strength or one with infinite cunning? (It might depend on the rules of the contest and the resources available to the contestants.)

Gary Klein guest-blogging on Cognitive Edge.

I always encourage people who enjoyed Blink to read Gary Klein’s Sources of Power and/or The Power of Intuition. Dave Snowden puts it well when he says they have the readability of Blink, but with intellectual vigor added in for good measure and without trivialisation for journalistic effect.

Anthony comments:

I worked on a project where we got a lot of value by writing the acceptance test for a story before starting to code it. The tests were described in English, and run manually by an independent testing team

Fair point. In (the fabulous) User Stories Applied, Mike Cohn suggests writing acceptance tests on the reverse of your index cards, and I can see how they would help. I’d still maintain that those tests should still be written as close to the beginning of the story as possible, the last responsible moment.

Also, unless regularly run run the likelihood that an acceptance accurately describes the system rapidly decreases once the story is done; manual tests make poor long-term documentation.