Ted Naleid

I’ve just released version 0.2.1 of the build-test-data grails plugin.

The build-test-data plugin makes creating integration test data easy. It decorates your domain objects with a “build” method that will create new domain instances and will automatically populate required fields with data and save it to the database. This enables you to create more maintainable tests where the data you create is targeted specifically at the situations you’re trying to test, without having to go through all of the ceremony of creating the rest of the object graph that you don’t care about.

// creates a new Book instance with all required fields 
// (like the Author that the book belongsTo) populated
def b = Book.build()

To learn more about the basics of the build-test-data plugin, see this blog post and check out the Basic Usage and Sample Code wiki pages.
Read the rest of this article »

I’ve recently thrown together a few different command line aliases that have been very helpful in my grails development and I thought others might benefit from them.

The aliases are primarily just the first letter of the words in the command, which makes them easy to remember (and saves on typing). Some examples:

gta                   # grails test-app
gtai                  # grails test-app -integration
gtaud AuthorService   # grails-debug-suspend test-app -unit AuthorService

Read the rest of this article »

The need to add some functionality an existing method, but avoiding cutting and pasting the old implementation has come up a few times over the last week.

Sometimes, creating a subclass isn’t feasible, often because you don’t control all of the places where that class gets used. Read the rest of this article »

Creating maintainable test data is hard.

Often an entire object graph needs to be created to support the instantiation of a single domain object. This leads to either the cutting and pasting of that creation code, or relying on a canned set of objects that we’ve grown over time and maintained as the domain objects change. After a while, adding just one more Widget to that set of canned data ends up breaking tests just about every time.

There has to be a better solution, right? Read the rest of this article »

Groovy 1.6.1 was released today, and it includes a patch I submitted a few weeks ago to make working with regular expressions much more groovy. Thanks to everyone that voted for the patch in the Groovy JIRA.

The main functionality is the addition of a variety of find and findAll regular expression aware methods that have been added to string.
Read the rest of this article »

I just submitted a groovy patch that enhances the String class with a “find” method that makes working with regular expressions much easier.

One of the most common use cases is to search a string for a regular expression pattern. If a match is found, then do something with the matched value.
Read the rest of this article »

Late last night, I ran across Tropo, a new IVR platform by Voxeo that supports a large variety of modern scripting languages, including my current favorite, Groovy (it also supports JavaScript, Ruby, Python, Jython, and PHP).

They just opened their “early beta” to the public about 10 days ago and have free accounts for developers to try things out.

They also have a github repository with a bunch of sample applications, and the adapter code that they’re using to make their core functionality available to all these different languages.

It’s nice to see an IVR company support all these modern things. VoiceXML has been rotting in a dungeon for the last 5 years and making a programming language out of an XML syntax was wrongheaded to begin with. Bringing languages like Groovy to bear on IVR problems will enable much more robust applications and quickent development.

Tropo’s documentation is a good start, but there are a number of holes in it since it’s so new. Because we have access to all of the yummy Groovy metaprogramming and reflection, we can find out lots of information about the system and it’s functionality for ourselves.

Read the rest of this article »

I’ve just opened JIRA issue with a patch to enhance the groovy and grails consoles so that the default font size and the dimensions of the input and output areas can be overridden.

The initial patch I submitted used a custom GroovyConfig file, but at the suggestion of Guillame, I’ve modified the patch to use the preferences API. In my initial poke through the code, I didn’t see the preferences API being used (and couldn’t remember any settings that were saved by the console). After a closer look, it was being used in a couple of places.

The updated patch has been accepted and scheduled for inclusion in Groovy 1.6.1.

If you’re interested in making sure this change gets in, please vote for the JIRA.

I know that I open a groovy or grails console probably 10 times on an average day of programming, and the first thing that I do every time is to hit cmd-shift-L 3 times to bump the font size up to 18 points (yes, my eyes aren’t that great and I’m running my monitor at 1920×1200). The next thing that I do is drag it from the postage stamp size that it defaults to to cover at least half my screen.

This patch will probably save me more frustration than time, but I’m hoping it’ll save a lot of both for others out there.

This change won’t get in till 1.6.1, so if you want to tweak your current groovy install, it’s actually pretty easy to do.
Read the rest of this article »

The January 2009 issue of GroovyMag was released today. In it, I’ve written an article that shows how easy regular expressions are to use in groovy. It starts with some regular expression basics, shows some common idiomatic groovy usage patterns and wraps up with some of the cool new features that groovy 1.6 is adding to regexp handling.

There are over 30 code samples in then article and I wanted to make sure while writing and editing that all of the code samples ran exactly as they appeared in the article text. Also, when you download an issue of GroovyMag, you get a zip file that has a PDF and a set of code “listing” files for each article. Each listing file contains a snippet of groovy code that appeared in the issue.

I decided to write a couple of simple groovy scripts to keep things DRY, and to ensure that my edits didn’t break anything. The first script extracts code listings out of my draft article and saved them to individually numbered listing files. The second script executes each of the listing files and reported success or failure for each. Sort of a poor man’s JUnit for writing articles.

Read the rest of this article »

So groovy has this cool operator called the “spread” operator: “*.”.

Right now, it’s listed as the top hidden feature of Groovy over on StackOverflow. It works like this:

[1, 2, 3, 4]*.toString() 
// equals ["1", "2", "3", "4"]

It applies the method/property to the right of the operator to each member of the collection and returns the results as another collection. It’s syntactic sugar for doing this:

[1, 2, 3, 4].collect { item -> item.toString() }

(and that’s syntactic sugar for a whole pile of Java code :)

Did you know that for properties, you don’t actually need to use the spread operator? Neither did I till I fat-fingered a command working with a list of Grails domain objects and it still worked.
Read the rest of this article »