The Disco Blog Welcome Guest | Login or Register

Sockin’ it to you, baby:

• StatSVN rocks- Indeed it does, baby!
• Custom MSBuild Tasks- Start coding them!
• TotT: Too Many Tests- A good problem to have, I’d say.
• Glean v1.3: Code feedback tools for Ant- John’s got a good thing with Glean!
• FEST-Assert 1.0a1 released!- Have you checked out what Alex and team are up to?
• Java Power Tools: where it’s at- I can’t wait for this book to be officially released!

The hip folks involved with easyb just released version 0.7! The latest and greatest version includes the new should wiring to all objects (i.e. value.shouldBe false) within the context of story (or behavior); moreover, easyb now offers Maven 2 support via a new plug-in.

What’s more, easyb.org has been updated to include documentation on the database plug-in, how to use the Maven 2 plug-in, and an in-depth description of the easyb should syntax. Plus, there is a new mailing list.

Copasetic tests verify every possible path through a method– sunny day and rainy scenarios; however, in the Age of Aquarius we’re lucky enough to have a test– consequently, one can scan a cornucopia of test suites to discover a false sense of security.

You: This method has 100% code coverage?

Them: Yes.

You: It’s bug free?

Them: Totally.

You: What happens if I pass in null?

Them: null would never be passed in.

Because it’s your bag (and not theirs), you write a hip test that passes in null and voila! that 100% covered method isn’t 100% reliable.

Of course, handling this condition is as old as programming itself (even older than disco!)– checking for null before doing anything. But, checking for null is a bit verbose, not to mention fairly repetitive if it’s pervasive across a series of methods. Those dancers familiar with aspect oriented programming, or AOP, will recognize this as a crosscutting concern, meaning that defensive programming techniques span horizontally across a code base.

If AOP isn’t your bag though, you can always employ Groovy’s ? construct, which still results in repetitive code, however, it’s dramatically less verbose than typical if/then/else conditionals.

For example, take this hip getter on a JavaBean-like Java class:

public String getGenre() {
 if(genre != null){
  return genre.toUpperCase();
 }else{
  return null;
 }
}

The guard conditional now effectively removes the chance of a NullpointerException should the bean be initialized without a genre property. With Groovy, however, I can replace the entire conditional with one operator, baby.

Groovy’s ? operator is an effective safety net that you can apply before calling a method on an object you suspect could be null. For example, the above code is guarding against the bogue genre variable– with Groovy then, before I attempt to invoke the toUpperCase method, I can simply place a strategic ? and thus forego any conditionals like so:

def getGenre(){
 "${genre?.toUpperCase()}"
}

In essence, the two code examples are exactly the same (save for a few minor keystroke differences)– either an all capitalized String instance is returned or null is returned. Consequently, if you find yourself writing a lot of defensive code (and your bag isn’t AOP) then consider applying Groovy’s ? operator– it’ll save you a couple lines of code and a few NullpointerException headaches, man!

And you thought I’d be late, man!

• Chewing the fat over switch statements and CCN- Andrew Binstock and Chris have a copasetic discussion going on through comments regarding CCN and switch statements. This is a great read!
• Behavior Driven Development- What is the difference between BDD and TDD?
• TDD/BDD Leading To Incomplete Unit Tests?- This is an amusing read and as one commenter summed it up “…if I had this problem, boy, would I be in a happy place.” Amen, man!
• Interview and Book Excerpt: Hani Suleiman & Cedric Beust on TestNG- These cats always have interesting things to say, baby!
• Dynamic Languages: Rationalizations and Myths- Angry Bill has a good perspective here– worth the read.
• Groovy-power automated builds with Gant- I’m a huge fan of Gant!

I had the pleasure of a buzz session with my hip friend Scott Davis recently regarding Groovy and the upcoming Groovy/Grails Experience. Scott is a entertaining guy to chat with and I had a lot of fun describing BDD with easyb and the joy of using Gant. Check out the hip podcast if you have a few spare minutes and don’t forget to show up to the conference later this month, baby!

The hip folks at Enerjy talked with a copasetic crowd recently asking their thoughts on cyclomatic complexity. It seems most (including this disco dancer) find that CCN is an excellent indicator of risk– I haven’t found a better metric yet– in fact, a recent addition to the hip metrics crowd, dubbed C.R.A.P, which was donated by the folks at Agitar, even builds upon CCN by combining code coverage. What do you think, man?

Four days off, but right on, baby:

• Unit Testing C and C++ … with Ruby and RSpec!- SWIG works, baby! Nice to see it used for something quite interesting.
• Unit-testing Spring MVC: It gets even awesomer- Mr Smart is so smart, man.
• Ruby: Did TDD make Ruby a viable option?- The lack of pirates is causing global warming.
• Gosling on Closures- Java already has them, man.
• Testing: One expectation per test- Good advice, Ruby, Java, .NET, you name it.
• The Grinder 3.0 Released- JMeter or Grinder? Which one is your bag?

I had the pleasure of being interviewed by Steven Devijver (of Grails fame) regarding easyb recently on the DZone– the title of the interview is dubbed “easyb: Introducing Conversational Unit Tests for Java.” I hadn’t thought about the term conversational when it comes to testing, but I think its right on, man! As the interview points out, with easyb, you can have conversational expectations that read quite nicely, such as

var.shouldNotBe null
and
var.length().shouldEqual 6 

If that code isn’t having a heart-to-heart with you regarding what var or its length should or should not be then I don’t know how to talk to you anymore, man.

Thanks, Steven, for the opportunity!

In writing JavaWorld’s “The future is now — Java development in 2008”, I had the pleasure of asking a copasetic group of individuals their thoughts on what the future holds for Java. It wasn’t surprising that a majority of these disco dancers mentioned the OpenJDK project as a giant step of innovation, which could usher in a new era for Java (and all things that run on the JVM itself).

One particular project, dubbed Da Vinci, seems to owe its hip inception to an October 2007 emailing where John Rose of Sun proposed a Multi-Language VM, which, by the way, should be familiar to some in the community as it is an evolutionary offshoot of the “Kitchen Sink” project. Of interest is John’s own words in which he states that this project will address

“pain points” already observed by implementors
of successful or influential languages

Back when I picked up Jython, I was amazed that someone had actually gotten Python to work with the JVM; however, thinking that someday the JVM itself could change (because of this wizardry) was unthinkable. Times are changing though, man! While Jython appears to have slithered away, JRuby, Groovy, and Scala are all the rage– and now they are, in turn, influencing Java.

Case in point– InfoWorld recently published an article entitled “Sun’s Da Vinci Machine broadens JVM coverage“, where the author states that the project

is intended to overcome obstacles like mismatches between a source language’s design patterns and JVM capabilities. Because the JVM was designed for Java and Java favors some design patterns over others, implementers can find themselves dealing with these mismatches…

The question of course is, will Sun’s Da Vinci project survive? Make no mistake– Da Vinci isn’t revolutionary– the Perl world has been working on Parrot (another multi-langauge VM) for some time (at one point I thought it was supposed to run Java?).

Indeed, because it’s Java bag, Java is rapidly transforming from a language to a platform; what’s more, alternate languages, which solve some problems much more easily than Java, are profoundly influencing not only developers’ day to day activities but the heart of Java itself.

For inspiration, all you have to do, man, is either listen to some disco music or take a look at Mr. Leonardo da Vinci– this brilliant man was a musician, a scientist, an artist, and 14 other things! So too is the Java platform– it’s Java, Ruby, Groovy, Scala, Jython, JEE, Applets, you name it. It’s all that (and 14 other things!).

One of the hippest features of dynamic languages is the ability to modify fundamental aspects of the language at runtime — for example, Ruby’s open classes facilitate the addition of new methods at runtime– so for instance, you can easily add a blank? method to the String object. In Plain Jane Java you can’t actually add methods to Java’s String as it is a final class– what’s more, you can’t easily add methods to non-final classes at runtime either. With Groovy, however, you can.

Groovy has extensive metaprogramming facilities and one such addition is the ExpandoMetaClass, which enables you to do a host of copasetic things, including adding methods to normal Java objects (like String).

For example, imagine a domain object representing a runner in a race– a race can have 1 to many runners; consequently, a simple domain object for a runner could look like:

class Runner{
  def firstName
  def lastName
  def age
  def race
}

in which an instance of a Runner is connected to an instance of a Race (let’s keep this simple, man, so don’t worry about the fact that you think you can run in multiple races). Users go online and fill out a race application and invariably fail to capitalize the first character of proper names– hence, when race information is printed, some names appear inconsistent:

• emily Smith
• Gordon herch
• bart simpson

Race organizers don’t care that people enter in names inconsistently, but they do want the official race ballets to reflect consistent-ness, man.

Ideally, the Runner domain object should have a fullName method, which returns “Emily Smith” instead of “emily Smith”– you could put some logic into the fullName method itself to manipulate the firstName and lastName properties; however, what if you need that same sort of first character capitalization technique else where?

You could look to a 3rd party library– such as Apache commons-lang, which actually does contain a capitalize method. This would certainly solve your dilemma, but you do have another option: just add a capitalize method to the String class itself, man.

To do so, you need to reference the metaClass property that all classes in Groovy expose– once you have it, you can dynamically add methods to that class itself by defining a closure. For instance, adding capitalize method is as easy as writing

String.metaClass.capitalize = {
 return delegate[0].toUpperCase() + delegate[1..<(delegate.length())]
}

As you can see, the delegate variable inside the closure is the instance of the outside object, which in my case is a String. Using some Groovy constructs, all I am doing is grabbing the first character of a String instance (via a positional construct) and calling toUpperCase to it, then I’m ensuring that the remaining characters (using an exclusive range) are returned– otherwise the capitalize method would return a single capitalized character.

I can verify things are copasetic via a handy assert:

assert "test".capitalize() == "Test"

I’m sure there are better, more efficient ways to code the capitalize method too (such as having the closure use commons-lang’s capitalize method!), suffice to say, man, this took all of 2 minutes.

Now, because it’s my bag, I can code my fullName method as follows:

def fullName(){
 return firstName.capitalize() + " " + lastName.capitalize()
}

The beauty of Groovy, of course, is that the above code is one of a few ways that method could be written– the return statement isn’t required and I could have used GStrings to convey the intent of the method in a nicer manner (i.e. "${firstName.capitalize()} ${lastName.capitalize()}").

Metaprogramming in Groovy is, as you can see, baby, hip and indubitably easy– what’s more, this capability brings unbridled power to Java applications– take a look under the covers of Grails (and Rails, for that matter, to see Ruby’s copasetic flexibility in action) and you’ll see what I mean. Dig it?