Archive

Author Archive

Upgrading Maven from 2.0.x to 2.1.x – profiles.xml

October 26, 2009 Josh Leave a comment

When we tried to upgrade from Maven 2.0.x to 2.1.x, our build broke, indicating we had a problem with our profiles.xml. I had a hard time finding out what’s supposed to be in the profiles.xml, since I couldn’t find a reference to the schema on the Maven website.  I finally found a profiles.xml in one of our projects at work that referenced the profiles XML schema, which can be found here:

http://maven.apache.org/xsd/profiles-1.0.0.xsd

I’m still not sure if the schema changed from 2.0.x to 2.1.x, but I know that using <profiles/> as the root element worked in 2.0.x but did not work in 2.1.x.  When you upgrade to 2.1.x, make sure the root element in your profiles.xml is <profilesXml/>. Actually, you can make the change to your profiles.xml before upgrading to Maven 2.1.x and then upgrade when you’re ready.

Categories: Maven Tags:

Mocking and stubbing in Groovy with ‘with’

October 5, 2009 Josh Leave a comment

I often use metaClass in Groovy to create mocks or stubs in my unit tests. Recently I’ve discovered that the with method makes this a bit simpler.

This:

Foo.metaClass.with {
  doSomething = {
    return true
  }
  anotherThing = {foo ->
    assertEquals 42, foo
  }
}

is slightly shorter than this:

Foo.metaClass.doSomething = {
  return true
}
Foo.metaClass.anotherThing = {foo ->
  assertEquals 42, foo
}

and less code means less bugs.

[Update: For more explanation of why the with method is so great, read this post.]
[Update: And for another way to write your mocks and stubs, see my previous post on mocking with Groovy.]

Categories: Groovy, TDD Tags: , ,

Java 6 and Maven on Mac OS X Leopard

August 12, 2009 Josh 2 comments

This morning I was having problems with Java and Maven on my Mac. I had my JAVA_HOME set to /Library/Java/Home, which was pointing to Java 6. When I ran mvn -v, Maven told me it was pointing to Java 5. I couldn’t figure out what was wrong because running java -version showed me Java 6.

The solution, which I found in this post, was to set my JAVA_HOME to the actual place where Java is installed, which is something like:

/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home

This worked for me, but YMMV.

Categories: Java, Maven Tags: , ,

Who needs a mock framework?

July 26, 2009 Josh 11 comments

In Groovy, you can create mocks & stubs using native language features, so you can forget about learning a mock framework.

class Author {
  def getName() {
    return 'Josh Brown'
  }
  def isFamous() {
    return false
  }
}

Let’s stub the isFamous method:

def author = [isFamous: {true}] as Author
assert 'Josh Brown' == author.getName()
assert author.isFamous()

(If you haven’t already, stick the above code in your groovyConsole, run it, and play around with it.)

When mocking and stubbing are so easy to do with the language itself, using a mock framework is overkill.

[Update: Bob Martin recently wrote an excellent post about Manual Mocking.]

Categories: Groovy, TDD Tags: , ,

Story time with easyb

January 27, 2009 Josh 2 comments

Everyone loves a good story.
 

Star Wars Trilogy

 

With easyb, you can write stories in your code!

scenario "the Death Star destroys Alderaan", {
    given "the Death Star", {}
    and "Alderaan", {}
    and "Alderaan is targeted by the Death Star", {}
    when "the Death Star fires", {}
    then "Alderaan is destroyed", {}
 }

You probably could’ve written that with the stakeholders yelling over shoulder. No – the Death Star should destroy Yavin IV, not Alderaan!!! If you’re writing readable code in front of them, you might be able to get them to make a decision while you’re at your keyboard.

Now you have executable documentation, and the stakeholders can leave the party. And once they’re gone, you can move on to writing some Groovy code to fill in those empty squiggly braces:

scenario "the Death Star destroys Alderaan", {
    given "the Death Star", {
        deathStar = new DeathStar()
    }
    and "Alderaan", {
        alderaan = new Planet(name:"Alderaan")
        Galaxy.planets << alderaan
    }
    and "Alderaan is targeted by the Death Star", {
        deathStar.target = alderaan
    }
    when "the Death Star fires", {
        deathStar.fire()
    }
    then "Alderaan is destroyed", {
        Galaxy.planets.shouldNotHave alderaan
    }
}

Now run it and watch it fail. Ah, the joy of xDD…

From here, you can write the DeathStar, Planet, and Galaxy classes you need to make it pass. Run it again! Refactor! Repeat!

Now you have documentation that’s readable, executable, and verifies that your code does what it’s supposed to do! Wasn’t that easy?

Categories: Groovy, TDD Tags: , , ,

Unsolicited LinkedIn Recommendations

December 11, 2008 Josh 2 comments

Inspired by Gayle’s post, I wrote an unsolicited LinkedIn recommendation a few days ago. I found one of my previous managers on LinkedIn and just decided to recommend him. He was a great manager/architect/tech lead, so he deserved it. I wasn’t looking to get anything from it – I just thought he’d appreciate it, and I was hoping to make his day (or at least his evening, or hour, or something). I’m not sure how he reacted.

A friend and I were discussing this, and he told me he wouldn’t want an unsolicited recommendation.  I never asked why – maybe he thought I would expect some sort of payback.  Hopefully he’ll speak up in the comments.  ;)

I, on the other hand, would love to get an unsolicited recommendation on LinkedIn.  I’d be really excited about it (especially since LinkedIn keeps showing me that my profile is only 80% complete).  And I think it would motivate me to pay it forward by recommending someone else.  And pretty soon, everyone would have a recommendation…

So how would you react if someone gave you an unexpected recommendation on LinkedIn? Would you be thankful, excited, appreciative? Or would you wonder why they recommended you (maybe they’re trying to get something from you…)? Would you think it was a waste that they wrote it now, when you’re not even looking for a new job? Would you wish they had waited until the right time?

Categories: Uncategorized Tags:

The Executor Framework

November 8, 2008 Josh 1 comment

It’s great. It allows you to handle concurrency in Java (or Groovy) without directly using the Thread class.

I first heard about the executor framework in Effective Java (Second Edition) (Item 68: Prefer executors and tasks to threads) and became really interested in it, decided to investigate further, and gave a presentation on it for my coworkers.

The Executors class (new in Java 5) provides a bunch of static factory methods for creating executors. With an executor, you can submit a task (Runnable or Callable) that will be performed by that executor. Here’s an example:

ExecutorService executor =
    Executors.newSingleThreadExecutor();
executor.execute(runnable);
executor.shutdown();

As you can probably guess, this will create an executor which has a single thread. That thread will take the runnable and call its run() method. If the execute method is called multiple times, each runnable that’s passed in to the method will be placed on a queue. When the executor’s thread is available, it’ll pull the first runnable off the queue and run it. When that one finishes, it’ll grab the next one, and so on.

If a single thread isn’t enough, you can do the following:

ExecutorService executor = Executors.newFixedThreadPool(5);
for (Runnable runnable : runnables) {
    executor.execute(runnable);
}
executor.shutdown();

This would create a thread pool with 5 threads that can execute the runnables. Again, the execute method places each of the runnables on a queue, and whenever one of the 5 threads is available, it pulls the runnable off the queue and runs it. That’s it! It’s so simple.

If you want to schedule your tasks to run at certain intervals, you can do this:

ScheduledExecutorService executor =
    Executors.newSingleThreadScheduledExecutor();
executor.scheduleAtFixedRate(runnable, 0, 1, TimeUnit.MINUTES);
executor.shutdown();

This will submit a task to be executed every minute. The single thread in the executor will run the task right away, and then again every minute. The ‘0′ above indicates the initialDelay – that is, the number of units to wait before the first invocation of the runnable. The ‘1′ indicates the number of units between each invocation of the runnable. And, of course, TimeUnit.MINUTES indicates that the units for the ‘0′ an ‘1′ should be minutes.

If you’re using Groovy, it’s even easier because you don’t have to implement Runnable – you can just pass a closure to the executor (since Closure implements Runnable).

There’s no longer a reason to create threads directly in Java. The language now provides an easy way for you to run tasks in separate threads without having to micromanage them.

First Impression of Google Chrome

September 2, 2008 Josh 3 comments

Google Chrome.  It’s new, it’s different, it’s fast, it’s simple, it’s clean, it’s functional.

So far, in the couple hours or so I’ve used Google’s new browser, I love it.

Here are the things I like about Chrome:

  • the find (Ctrl+F) shows how many matches it found in the page, and which one you’re on (for example, 1 of 2)
  • the New Tab page, which shows all kinds of goodies, like most visited pages, search history, recent bookmarks, and recently closed tabs
  • the JavaScript virtual machine makes JavaScript run faster
  • the “address” bar (which is so much more) that offers suggestions for searches, web history, and addresses
  • the ability to drag tabs into a new window
  • incognito mode – the name is great (the idea is cool too)
If you want to know more about it, read the features page.  Watch the videos.  Download it.  Try it out.
Categories: Uncategorized Tags: