Higher order programming and functional abstraction in Groovy

Leave a reply

I’ve been checking out the legendary MIT Structure and Interpretation of Computer Programs course from 1986 on YouTube, and it’s fascinating for many reasons, not least the hypnotic synthesized Bach that bookends each lecture. I don’t think I will ever be able to hear Jesu, joy of man’s desiring again without seeing that purple wizard. What’s really striking to me is how quickly the course gets into territory that I (coming from a self-taught Perl/Java background) think of as pretty advanced. In the first three lectures we are introduced to:

  • Recursive subroutines
  • big-O notation
  • passing functions around as variables
  • building functions using higher-order programming

Anyway, I thought that the example used to illustrate higher-order programming was pretty cool, so I decided to see if I could implement it in Groovy. The example involves writing a function to calculate the square root of a number using the Babylonian method - start with a guess and repeatedly average the guess with the number divided by the guess, until the answer is close enough.

Here it is in Groovy:

and the output:

I’ve defined an abs() closure because the built-in .abs() method complains about different types of numbers. The sqrt2 method itself is easy to read – given a guess, calculate how far off it is by squaring it, and either return the guess (it it’s close enough) or use the averaging procedure to make a new guess and call sqrt2() again. We could make it a bit more concise by leaving off the explicit return statements – a Groovy method returns the value of the last expression that was evaluated, so we don’t really need them (this is what I’ve done with my abs() method). Note that when we call the method in the last line, we have to supply it with an initial guess.

The first step in abstraction is pretty obvious – let’s do away with the hard-coded 2 and let the method take the number for which we want to take the square root as an argument.

To make things a a little more convenient I’ve moved the iterative code to a closure called sqrt_iter; the job of sqrt now is just to supply the initial guess. Now we can ask for the square root of exotic numbers like five:

Up to this point there’s no higher-order programming going on. But now it starts to get interesting; we can extract the bits of code that are responsible for checking if the answer is good enough and for generating the next guess:

Now, what we are left with in sqrt_iter is a generic procedure for solving a problem by generating successively better guesses until we get close enough. We can make this abstraction explicit by turning our improve / good enough methods into closures and having them as arguments to the main iteration method:

I’ve changed the names of the closures to make things clearer. sqrt_improve and sqrt_goodEnough are the particular type of improve and goodEnough routines that are for solving square roots. Our iteration routine is now a generic one that take four arguments – a closure that can tell if a guess is good enough; a closure that can improve an existing guess, a number for which we’re trying to find the answer, and a guess. Note that the generic_iter method now contains absolutely no logic to do with calculating square roots – it is completely generic. We can use it to solve any problem which we can express in terms of a way of checking if a guess is good enough, and a way of improving a guess.

Here’s a completely brain-dead example; using the generic_iter method to solve the problem of finding the smallest integer that is bigger than a given number:

The improve closure just increments the guess by one; the good enough closure just checks whether the guess is bigger than the target number. The output is not particularly surprising:

One final point: because we can return closures as values from methods in Groovy, we can redefine generic_iter so that rather than executing the iteration procedure, it returns it. So we can assign the result to another variable and use it later on:

Note that here we have to define returnClosure before we assign a value to it, because we want to refer to it inside the closure body. generic_iter now takes only two arguments – the two closures that will do the work – because its job is not to actually carry out the calculation, but to build the routine that will.

Extending Java number classes with random functions in Groovy

Leave a reply

Recently I’ve been playing around quite a bit with Processing.org, and one of the things that I often want to do is add a bit of noise to variables that represent positions, sizes, colours, etc. Most of the Processing functions that actually draw something (like lines, ellipses, etc) take their arguments in the form of floats, but most floating number operations in Java/Groovy return BigDecimal data types so we have to use casts a lot. Also, there’s no concise way to get a floating random number in a certain range that can be either negative or positive, so in order to randomly nudge a number up or down we end up with something like:

which is not exactly concise. If we want to call a Processing function that takes several such variables as arguments, then it gets worse:

Thinking about a Groovy solution to the problem I remembered reading about the meta-programming features that let us dynamically add methods to core Java classes at runtime. So here’s my solution – let’s modify the Integer, Float and BigDecimal classes to include an extra method, jiggle(), that will add or subtract a bit of random variation to the number and return it as a float. Here is the magic code, that must be called at runtime (the **setup() **method of a processing applet does the job very nicely):

The jiggle() method (actually it is a closure) itself is pretty straightforward. We take random number, scale it by the method argument, invert it half the time, add it to the number, and cast the result to a Float before returning it. Two things are of interest here; firstly, we need to have a Random object called random in the scope where this code is run (we could get round this by creating a new Random object inside the closure, but I find it easier for debugging to have a single Random object for the whole sketch, making it easy to reproduce). Secondly, when we want to refer to the object to which the closure belongs (i.e. the Integer, Float or BigDecimal) we use delegate.

Having run this little snippet, our little examples become much more concise:

and since we have ensured that all our new methods return Floats, we can happily through any type of number we like into the mix and be sure that the jiggled number will come out OK. We can even make use of Groovy’s everything-is-an-object syntax to do cool stuff like:

nice!

Beware of the default acegi Grails plugin setup

1 Reply

This is firmly in the “putting it up here just in case anyone else has the same problem” category.  There is a gotcha that bites when writing a Grails application that uses the acegi security plugin along with a postgresql database as the data source.  The problem is that the acegi plugin will, by default, create a domain class with the name “User”.  When you try to run the application with a postgresql datasource, GORM will try to create a table with the name “user”, which postgresql will not like as it is a reserved word.

This is a particularly annoying bug, because “user” is not a reserved word in other RDBMs, so the error will only become apparent when you switch from your development HSQLDB to postgres, by which time you will have have references to Users scattered throughout your application.

Thankfully, the fix is not too onerous; either rename your User class to something else (and do a tentative find/replace in your code) or use a custom GORM table mapping:

A pitfall to avoid when using the Grails UIPerformance plugin

Leave a reply

A quick warning to anyone who’s using the excellent UIPerformance plugin for grails:  don’t do what I did, and set up your bundles with identical names:

Unsurprisingly, this causes the plugin to get confused; the following works much better:

Deploying a grails app on a VPS

Leave a reply

I recently set up a grails app on a Slicehost VPS. I’ve been very happy with the Slicehost setup so far; here are a few notes that might be helpful.

  • I started out on a 256MB slice, but that was too slow, so I’ve upgraded to a 512MB slice, which seems to be working out OK.  Memory usage is still higher than I’d like, but there are a few options for tweaking that I haven’t looked into yet.
  • Using the Grail UI Performance plugin has made a massive difference in the responsiveness of the app.
  • I have gone for a straightforward setup, using Tomcat to serve both dynamic and static content.  From what I have read, this will probably slow things down a bit, but has the advantage of making admin much simpler. The main hassle so far has been implementing a 301 redirect for SEO purposes, but I fixed that as per my post here.

UPDATE:  after I added meshCMS to my VPS I started running out of PermGen space on a regular basis.  A quick search turned up some articles pointing out that this is a common problem with frameworks that generate a lot of classes dynamically.  I’ve since added -XX:MaxPermSize=256m to my CATALINA_OPTS and have had no problems since.

Hibernate magic with lazy evaluation

Leave a reply

I’ve just run across this phenomenon for the first time and it turns out that hibernate can be even lazier than I thought!  To illustrate lets use this time-honoured example in Grails.  

Here are our domain objects:

and we’ll add some sample data in our bootstrap.groovy:

Now we’ll turn on SQL logging in Datasource.groovy, so we can see exactly when hibernate is issuing SQL queries:

Now let’s create a controller to hold our test code (just for convenience, this could also be done in a groovy console):

This is pretty straightforward – we’re using a dynamic finder to retrieve the Author we added in the bootstrap script, then getting the list of Books and storing them in a variable, then printing the title of each book.

Question: when do we expect to see the SQL query issued to retrieve the books? Grails uses lazy evaluation by default, so it won’t be at line 6, because we haven’t actually asked for the books field yet. I expected to see it at line 8 – here we are asking for the books field, so surely this is where hibernate will retrieve them. I was wrong – in fact the books are not retrieved until line 10, where we actually want to do something with the books. The output make this clear:

So hibernate does not actually execute the SQL query to get the books when we ask for alice.books, but it is lazy enough to wait until we actually we try to iterate over the results. The last line of the output reveals how the magic happens – the object that myBooks points to is not a straightforward List, but a PersistentSet.

This caused me a fair amount of confusion when I was trying to optimise a Grails action by minimising the number of SQL queries issued when retrieving a large number of objects from a database. Now that I know the way that it really works, I find it both cool, and a little bit scary that this is going on behind the scenes. A nice illustration of the trade-offs involved in using an ORM framework.

How to use jQuery to send JSON data to a Grails app

Leave a reply

This took me a while to figure out, so here it is for anyone else who’d like to know. Firstly, I was quite surprised to learn that jQuery doesn’t have a built in method for turning objects into JSON, so you’ll need the JSON parser/creator from json.org. Then you can write your javascript POST function using the jQuery ajax method. Here I’ve left the content type as text/plain, which is not strictly correct but works with the Groovy code.

And on the server end, here’s the code from the relevant controller.