Ted Naleid

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 »

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 »

In my current project, I’ve been doing a lot of tweaking of the default grails scaffolding templates. Because of this, I need to run the new uber generate-all command quite a bit to recreate things.

The one problem with this script is that if the files already exist, a prompt will come up after ~10 seconds or so (after the grails environment bootstraps) asking you if you want to Overwrite everything:

grails generate-all "*" 
...
~10 seconds pass
...
Generating views for domain class Baz ...
File /foobar/grails-app/views/baz/list.gsp already exists. Overwrite?y,n,a

This was a bit of a pain as I’d often kick the script off, get distracted and then come back to the shell with that prompt still waiting for me to tell it what to do. I’d rather just start working with my shiny new scaffolding.

The easy solution to this is simply to pipe the answer you want into the grails command:

echo "a" | grails generate-all "*"

Doing that will pipe the “a” into the grails command so that when the prompt finally comes up, it knows that it can continue regenerating all of my scaffolding.

It seems simple enough after I figured it out, but I thought it could save some other people time when they’re hacking around with templates and know they want to regenerate all of them.
Read the rest of this article »

Out of the box, groovy gives you a number of powerful methods to iterate over lists and maps:

def fibList = [1, 1, 2, 3, 5]
 
fibList.each { println it }  // prints all of the numbers in the list
assert fibList.any { it == 3 }
assert fibList.every { it > 0 }
assert fibList.collect { it - 1 } == [0, 0, 1, 2, 4]
assert fibList.findAll { it > 1 && it < 5 } == [2, 3]
assert fibList.find { it > 1 } == 2
assert fibList.inject("fib: ") { str, val -> str < < val }.toString() == "fib: 11235"

That’s really nice if you’re working with raw lists and maps, but what if you have a class that doesn’t extend list or map? How hard is it to empower that class with the groovy iteration methods? If this were Java, you’d likely need to implement an interface with these methods (and throw a “not implemented” exception for those you didn’t feel like taking the time to implement).

Since it’s not Java, but groovy (and you’ve read the title of this blog post :), you know it’s easy!
Read the rest of this article »

I gave a presentation at work today on Distributed Version Control Systems and Mercurial. We’re currently using Subversion, and I’m nudging my co-workers into getting interested in the benefits of distributed version control over a centralized system.

The presentation starts with the pros and cons of distributed systems and gives a brief overview of the top 3 most popular DVCS systems:

• Git
• Bazaar
• Mercurial

I go into the details of why I chose to use Mercurial and describe some common usage patterns for people used to using Subversion.

I then did a live-coding session where I created a quick grails application, added it to a new repository, cloned the repository and pushed changes back and forth to show how mercurial handles merging and history.

I also suggest how developers can use mercurial as a “super client” to enable much of this power while still working on a team that uses subversion.
Read the rest of this article »

Over on the RailsEnvy blog (the guys who made the “Rails vs. X commercials” last year), there’s an article that highlights some of the nice syntactic sugar that Groovy has that’s currently not available in Ruby.

I actually came to Groovy/Grails after working with Ruby/Rails for about a year. Both languages and framworks have their strengths and it’s nice to see cross-pollination of good ideas going both ways. From the comments, it sounds like Ruby 1.9 is getting some of the features that we’ve had in Groovy for a while.
Read the rest of this article »

UPDATE: if you’re using Groovy 1.6.1 or greater (released April 2009), check out the new find and find all methods in this post.

Some people, when confronted with a problem, think “I know, I’ll use regular expressions!”
Now they have two problems. — Jaime Zawinski

There is a common and well-earned aversion in the Java world to regular expressions. Prior to Java 1.4, regular expressions weren’t even part of the core language. Post 1.4, using regular expressions is still a painful task of working with Pattern and Matcher objects. Lots of typing is involved to make anything happen. It’s difficult enough that most Java devs don’t end up using them enough to actually remember how to read a regular expression, and they need to dig up the JavaDocs (or cut and paste an old example), every time they want to use them.

This aversion has persisted into the Groovy community to a level that I haven’t seen in other dynamic scripting languages like Ruby, Python, and (obviously) Perl.

The current regexp docs that pop up when doing a google search are all outdated and don’t use any of the best techniques that are available in the groovy 1.5.X and 1.6-beta code that is now available. The recent Groovy Recipes book doesn’t have an entry for regular expressions in the index, and I was unable to find a single example of a regular expression in the entire book.

This is unfortunate because Groovy makes using regular expressions much easier than in Java. Under the covers, you’re still working with the same old Java Pattern and Matcher objects, but the Groovy syntax and additions to those classes are pleasant to work with.
Read the rest of this article »

If you’ve ever wondered what methods a groovy class has available for you to call, all you need to do is ask the metaClass:

"foo".metaClass.methods*.name

Result:

["equals", "getClass", "hashCode", "notify", "notifyAll", "toString", "wait", "wait", 
"wait", "charAt", "codePointAt", "codePointBefore", "codePointCount", "compareTo", 
"compareTo", "compareToIgnoreCase", "concat", "contains", "contentEquals", 
"contentEquals", "copyValueOf", "copyValueOf", "endsWith", "equals", 
"equalsIgnoreCase", "format", "format", "getBytes", "getBytes",
 "getBytes", "getChars", "hashCode", "indexOf", "indexOf", "indexOf", 
"indexOf", "intern", "lastIndexOf", "lastIndexOf", "lastIndexOf", "lastIndexOf", 
"length", "matches", "offsetByCodePoints", "regionMatches", "regionMatches", 
"replace", "replace", "replaceAll", "replaceFirst", "split", "split", "startsWith",
 "startsWith", "subSequence", "substring", "substring", "toCharArray", 
"toLowerCase", "toLowerCase", "toString", "toUpperCase", "toUpperCase", 
"trim", "valueOf", "valueOf", "valueOf", "valueOf", "valueOf", "valueOf", 
"valueOf", "valueOf", "valueOf"]

There’s a lot of duplication in there, and the order is random, so I’ll often fix that like this:

"foo".metaClass.methods*.name.sort().unique()

Result:

["charAt", "codePointAt", "codePointBefore", "codePointCount", "compareTo",
 "compareToIgnoreCase", "concat", "contains", "contentEquals", "copyValueOf", 
"endsWith", "equals", "equalsIgnoreCase", "format", "getBytes", "getChars",
 "getClass", "hashCode", "indexOf", "intern", "lastIndexOf", "length", "matches", 
"notify", "notifyAll", "offsetByCodePoints", "regionMatches", "replace", "replaceAll",
 "replaceFirst", "split", "startsWith", "subSequence", "substring", "toCharArray", 
"toLowerCase", "toString", "toUpperCase", "trim", "valueOf", "wait"]

Read the rest of this article »

There’s a blog post by one of the subversion developers talking about the future of subversion in a DVCS world.

I agree with parts of the post (and many of the comments) that subversion will continue to be around for a long time, but that more and more developers will start using tools like mercurial and git as a “super client” for a normal centralized version control repository.

Read the rest of this article »

I just finished the conversion over from a wordpress.com hosted blog to a wordpress blog that I’m running on a slicehost slice.

I think that it’s good to maintain your own linux server and get your hands dirty from time in Apache rewrite rules and php code.

The biggest reason for the switch is that the wordpress instance on wordpress.com completely mangles pasted grails and groovy code. It tries to make things pretty by changing a double dash to an mdash, single dashes to an ndash and double quotes to “smart” quotes (an oxymoron if there ever was one). Not to mention the manual &gt; and &lt; that you need to enter instead of > and <. These insidious changes make pasted code worthless and painful for readers to use.

After struggling with trying to get the formatting working correctly for a few weeks, I decided to host my own blog and use the great wp-syntax plugin.

I did need to do some reformatting on my old posts (as I don’t need to encode things anymore) and I believe that I have everything fixed now.  Let me know if you run across anything I’ve missed in the conversion.