Ted Naleid

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 work on a couple of different grails projects that use a variety of versions of groovy and grails. I’ve thrown together a quick shell script that makes it easy to create a new alias to switch between different versions depending on what project you’re working with.

function switchGrails() {
    echo "Switching to groovy version: $1"
    echo "Switching to grails version: $2"
    sudo rm /usr/local/{groovy,grails}
 
    sudo ln -s /usr/local/$1 /usr/local/groovy
    sudo ln -s /usr/local/$2 /usr/local/grails
    echo "Done!"
    ls -latr /usr/local/{groovy,grails}
}
 
alias g104='switchGrails "groovy-1.5.7" "grails-1.0.4"'
alias g11rc2='switchGrails "groovy-1.6.0" "grails-1.1-RC2"'

You can create your own aliases like the ones above to switch to the groovy/grails combinations that you happen to be working with.

Just stick the code above in your .profile/.bashrc/.zshrc file and restart your shell to make the aliases available.

This function assumes that you’ve got you’ve got groovy and grails installed in your /usr/local directory and that you use a symlink at /usr/local/groovy that $GROOVY_HOME is pointed to and /usr/local/grails that $GRAILS_HOME is pointed to. If those assumptions aren’t correct for you, you’ll have to tweak the script.

It also uses “sudo” as it assumes that /usr/local is owned by root and not by your logged in user. If you’ve chowned the directory to yourself, you can remove the sudo (and the need to enter your password).

Now it’s easy for me to switch between different projects by just typing the appropriate alias:

pollux% g104
Switching to groovy version: groovy-1.5.7
Switching to grails version: grails-1.0.4
Done!
lrwxr-xr-x  1 root  wheel  23 Mar  8 19:55 /usr/local/groovy -> /usr/local/groovy-1.5.7
lrwxr-xr-x  1 root  wheel  23 Mar  8 19:55 /usr/local/grails -> /usr/local/grails-1.0.4
 
 
pollux% g11rc2 
Switching to groovy version: groovy-1.6.0
Switching to grails version: grails-1.1-RC2
Done!
lrwxr-xr-x  1 root  wheel  23 Mar  8 19:56 /usr/local/groovy -> /usr/local/groovy-1.6.0
lrwxr-xr-x  1 root  wheel  25 Mar  8 19:56 /usr/local/grails -> /usr/local/grails-1.1-RC2

Today I’ve run across a few mentions of SelectorGadget. First when John Resig tweeted about it and now it’s at the top of Hacker News.

It’s worth all the attention it’s getting. It makes working with CSS selectors, and especially scraping websites, dead simple. This is the gateway into

The kind of information that it gives you can be fed into jQuery (or other CSS selector aware API’s like nokogiri or hpricot for Ruby or beautiful soup for Python) to easily get the right syntax for querying the DOM.

Check out the author’s screencast on the front page. He very quickly demonstrates how easy it is to use SelectorGadget to modify the scope of the intended selector.

P.S. if anyone is aware of any Groovy/Java parsers that can take CSS 3 selectors, I’d love to hear about them. Some quick googling isn’t showing anything.

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 »

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 »

In his book, The Productive Programmer, Neal Ford talks about using shims or jigs to help productivity. Jigs and shims are quickly created little snippets of code that automate repetitive tasks or make them easy enough that they’re worth doing. They’re little tools that help make your job easier and let you avoid using brute force to solve all of your problems.

My home directory has a bin folder in it that’s continually getting new jigs added to it, and my zshrc file is an ever-expanding list of quick shell functions.

Recently, I’ve been doing a lot more work with Mercurial as the team that I’m on switched from Subversion a couple of months ago on our Grails project. The initial transition was a little difficult for some people, but I think just about everyone is pretty happy with the transition now that we’ve made it.

Something that has helped everyone get comfortable with more complex Distributed Version Control System like Mercurial has been the distribution of shims and jigs amongst the team. I thought these tips might be useful to others as well.
Read the rest of this article »

Have you ever needed to test your website as if you were a dialup user? According to a Pew research study earlier this year 55% of Americans have broadband at home, and 10% still have dialup (with the remainder having no connectivity at home). This means that almost 20% of home browsers are on dialup. If you want to make sure that you’re app isn’t completely unusable for this population it could be useful to know how to slow your fat pipe down to dialup speeds.

Under the covers, Mac OSX uses a tool called “ipfw” (IP firewall) that allows for all kinds of fancy traffic shaping and piping. It’s a very unix tool though and it’s not the easiest thing to use if you’re not familiar with parsing through man pages.

There is a GUI called WaterRoof (http://www.hanynet.com/waterroof/) that makes things a little better, though it still isn’t the most intuitive thing.

Here are the steps to slow your connection down using WaterRoof.
Read the rest of this article »