Where Groovy & Grails Breaks Down

First off, I do love Groovy & Grails. We’ve built a product with it: http://bounceoff.com. And I advise any dev shop that is Java focused to stop all development and switch immediately to G&G.

However, there are dirty little things that always ruin an otherwise perfect experience. This could be a very long post, detailing all of the tiny nits I have with Groovy & Grails. It wouldn’t be fun to write and it wouldn’t be fun to read.

Instead, I can encapsulate everything that is wrong with Groovy & Grails in one quick example. <Read on…>

N.A.D.D. Neutralizer

After starting up another Grails project and completely missing my text-to-speech solution for long build times, I decided to do something a little more re-usable.

I just released a Grails plugin that provides this functionality. It’s as simple as: 

grails install-plugin nadd-neutralizer

Right now, only Mac OS X is supported. Patches are welcome for other operating systems. Source code is here: http://github.com/digerata/grails-nadd-neutralizer

How to Externalize Your Grails Configuration Like a Professional

Grails docs go a long way towards being the only materials you need to learn how to use Grails. Unfortunately, it can miss a few things that are common use cases.

In any real world production app, you don’t manage your configuration from within your WAR file. How do you have a configuration file deployed out to your production server beside your WAR file?

Most of the posts out there about external configuration all talk about hard coding external config locations into a variable like so:

grails.config.locations = [ "file:${userHome}/${appName}-conf.properties"]

Well, that sucks. That is assuming, again, more about production then you really can afford. The configuration of the production system, isn’t up to the developer. It’s up to the Release Manager or System Admin or a whole team of people besides you. Rather than force them into accommodating you, the programmer, you need to make it easy for them to specify WHATEVER THE FUCK THEY WANT.
<Read on…>

Decrease “Latency” on Grails Builds

This is a tip for those of you dealing with long build times, which for me, is anything greater than about 4 seconds

The problem that those of us with NADD face is the second we are waiting for something to finish, we [alt|cmd]+Tab to a browser and start reading slashdot, rotten tomatoes, daringfireball, or any of a million other sites. Likely, you classify this “quick field trip” as multitasking and because you are so very good at multitasking (despite what all the experts say), you disregard the fact that your build was probably finished 10 minutes ago.
<Read on…>

Grails Newbie Mistakes & Gotchas

Whew, Grails has some gotchas. It is so great for so many reasons. But WOW! There are some time sinks tucked away for you to discover. In the hope of helping others, here is a list of the ones that hit me.
<Read on…>

How to Use Test Files in Grails

I’m embarking, balls-out, on a new project using Grails. I’ll be leveraging a significant portion of our Java codebase and the fact that I can do that,is just plain stellar.

It quickly came time to test out some of the integration. The very first question was how to load resources for testing. E.g., I have a service that handles file uploads. How do I pass it a test file?

The documentation isn’t straightforward on this. In fact, I found the solution attached to a bug report for grails 1.1. It’s pretty simple, once you pull in the spring packages:

import org.springframework.core.io.ClassPathResource
import org.springframework.core.io.Resource

And then in your testXXX() function:

Resource resource = new ClassPathResource("resources/crying-baby.jpg")
def file = resource.getFile()
assert file.exists()

And you are good to go. Note the assert at the end to verify things are working.