import grails.converters.JSON
class JSONUtils {
	protected static buildJSON(objectsToBuild, properties) {
		objectsToBuild.inject([], {
			objects, object -> objects << (properties.inject([:], {
				objectMap, property -> objectMap << [(property): object[property]]
			}))
		}) as JSON
	}
}

You could use it in a controller as following:

import static JSONUtils.buildJSON
class PersonController {
	def personService	
	static personJSONProperties = [ 'name', 'gender', 'age']

	def peopleByAge(Integer age) {
		buildJSON(personService.findByAge(age), personJSONProperties)
	}
}

I'm thinking that this could be a small but usefull AST transformation...

find . -type f -size +100M

But that won’t work with directories. After all, I guess they don’t take much spaces themselves – the files contained by them are the ones that does . So what I usually end up doing is finding directories with a certain depth, and then calculate their sizes and filter with grep. This would be an example:

find $HOME -type d -mindepth 1 -maxdepth 3 -exec du -hs {} \; | grep -E "[0-9]{1}(\.[0-9]{1,2})?G" | sort -n

This would list the directories contained in the user’s home, recursing til a max depth of 3 levels, and them calculate all their sizes. After that, it would filter by the sizes whose size is 1 gigabyte or more. Last, the sizes are sorted with a numeric criteria. You can change the last letter to filter by megabytes (M), and the count of the first regular expression so it takes only numbers of a given lenght. For example, to get sizes in the range [100M-1G), you would use the following regular expression: "[0-9]{3}(\.[0-9]{1,2})?M”. And to find directories with a size of at least 10 gigabytes, you would use: “[0-9]{2}(\.[0-9]{1,2})?G”. You can also change the mindepth and maxdepth params in order to filter how deep you want the recursion. And if you don’t provide a maxdepth param and set the base directory as /, the whole filesystem will be analized :).

I’ve seen tons of duplicated code (Tolkien fans would refer to it as “The Programmers Bane”) in the projects I’ve worked for hashCode and equals methods, even in the ones that use the Apache Commons helpers (EqualsBuilder and HashCodeBuilder), so I decided to post a pair of methods that I usually use to work out this problem:

import org.apache.commons.lang.builder.EqualsBuilder
import org.apache.commons.lang.builder.HashCodeBuilder
class DomainClassUtils {
	...
	static boolean equals(Object one, Object another) {
		one != null && another != null && 
		((obj.respondsTo('instanceOf') && obj.instanceOf(this.getClass())) || 
		 this.getClass().isInstance(obj)) && 
		(one.is(another) || 
		 one.getClass().equalsProperties.inject(new EqualsBuilder()) {
			builder, property ->
			builder.append(one[property], another[property])
		}.isEquals())
	}
	
	static int hashCode(Object one) {
		one.getClass().equalsProperties.inject(new HashCodeBuilder()) {
			builder, property ->
			builder.append(this[property])
		}.toHashCode()
	}
}

This methods will calculate equals and hashcode for domain class objects (note the use of the instanceOf method if available) that declares a static property named equalsProperties. For example:

import DomainClassUtils

class SomeDomainClass {
	Integer someProperty
	String anotherProperty
	AnotherDomainClass andAnotherProperty

	static equalsProperties = ['someProperty', 'andAnotherProperty']

	boolean equals(Object obj) {
		DomainClassUtils.equals(this, obj)
	}

	int hashCode() {
		DomainClassUtils.hashCode(this)
	}
}

This still involves duplicating the DomainClassUtils method invokations code, but this can be easily avoided injecting the methods using your prefered mechanism (in increasing order of preference, I could list the following ones: inheritance, composition, metaprogramming, category/mixin transformation, your custom AST transformation).

Assigning a variable value

I usually have in my functions.sh file something like the following:

[22:57] $ cat functions.sh 
function execute_and_log {
	echo "Executing '$1' ..."
	export ${2}="$(eval $1)"
}
[22:57] ~ $ source functions.sh 
[22:57] ~ $ execute_and_log "ls /usr" LS_RESULT 
[22:57] ~ $ echo $LS_RESULT
Executing 'ls /usr' ...
X11/ X11R6@ bin/ include/ lib/ libexec/ llvm-gcc-4.2/ local/ sbin/ share/ standalone/ texbin@

As you can see, I pass the variable name where I want to store my result as a parameter to the function. The trick is to wrap the variable that contains the variable name with braces. Note that if you don’t use export (that in most cases is not needed), it won’t work, I’m not sure why. Another possibility is to use the allmighty eval, which gives you an unglier sintax, but allows you to avoid the export:

[22:59] $ cat functions.sh 
function execute_and_log {
	echo "Executing '$1' ..."
	eval "$2=\"$(eval $1)\""
}
[22:59] ~ $ source functions.sh 
[22:59] ~ $ execute_and_log "ls /usr" LS_RESULT 
[22:57] ~ $ echo $LS_RESULT
Executing 'ls /usr' ...
X11/ X11R6@ bin/ include/ lib/ libexec/ llvm-gcc-4.2/ local/ sbin/ share/ standalone/ texbin@

Evaluating a variable value

Imagine that in the previous example you don’t want to log only the command to execute, but also the result. You then need to evaluate the value of a variable whose name is contained in another variable (the function second param in this case). In this case, I only know how to do it using eval, which would give you the following:

[11:11] ~ $ cat functions.sh 
function execute_and_log {
	echo "Executing '$1' ..."
	eval "$2=\"$(eval $1)\""
	eval echo "Result is \$$2"
}
[11:11] ~ $ source functions.sh ; execute_and_log "ls /usr" LS_RESULT 
Executing 'ls /usr' ...
Result is X11/ X11R6@ bin/ include/ lib/ libexec/ llvm-gcc-4.2/ local/ sbin/ share/ standalone/ texbin@

As you can see, we can use eval both to assign and evaluate, in this second case just by escaping the dollar sign. Really powerful .

Todo el album me parece buenísimo, pero la canción que consiguió que me enganchase a él de primeras fue Gone, un pedazo de tema que me tuvo obsesionado unos días, como siempre me pasa, y cuya letra me parece espectacular. Aquí os dejo la versión de estudio del mismo, aunque una vez que la tengáis escuchada, merece la pena darle una orejada a la fantástica versión que hicieron para AOL con Eddie Vedder a guitarra y voz.

A continuación la letra original y mi traducción, que como siempre tendrá errores varios cuyas correcciones serán más que bienvenidas :

Me quedo con los últimos versos. Si nada lo es todo, siempre se puede volver a empezar .

def updateContractAddress(contract, newAddress) 
{
   // Method configuration
   def client = contract.client
   def country =  CountryService.findByPostalCode(newAddress.postalCode)
   def currentAddress = client.address

   // Method body
   client.previousAddresses << currentAddress
   client.address = new Address
   client.save()
}

As you can see, the method has two different parts:

• In the first one, we just configure some variables that we will use in order to clean up our code, or may to not calling the same method twice (as would happen, for example, with the implicit method Contract.getClient(), that would be called three times in the variable client was inlined).
• In the second one, the actual method business logic is performed.

This is actually the method implementation, the previous stuff is just boiler plate code. In fact, in Java I have seen a lot the pattern of separating the previous code in multiple methods, in order to separate this two parts:

def updateContractAddress(contract, newAddress) 
{
   def client = contract.client
   def country =  CountryService.findByPostalCode(newAddress.postalCode)
   def currentAddress = client.address
   updateContractAddress(contract, newAddress, client, country, currentAddress)
}

private updateContractAddress(contract, newAddress, client, country, currentAddress) 
{
   client.previousAddresses << currentAddress
   client.address = new Address
   client.save()
}

Not bad. As I always say when joking, almost every life problem can be solved by applying an extract to method refactoring (yes, I am a funny guy ). But in Groovy we have another alternative that I find to be more elegant and easy to read.

As you know (and if don't, you should read this ), Groovy supports default values for a method arguments. So, you can do the following:

def method(a, b = 3, c = []) { ... } 

That is the same as doing:

def method(a) { method(a, 3, [] }
def method(a,b) { method(a, b, [] }
def method(a,b,c) { ... }

In fact, I think this is what the compiler actually do, making the feature a simple code generator that takes place in preprocessing time (but that is just me guessing ). Anyway, what you may not know is that the optional parameters can be assigned with method calls, and that this method calls can use the rest of the parameteres. So, the original code can be as following:

def updateContractAddress(contract, newAddress, client = contract.client, 
      currentAddress = client.address, country =  CountryService.findByPostalCode(newAddress.postalCode))
{
   client.previousAddresses << currentAddress
   client.address = new Address
   client.save()
}

Now we can focus on the method body without being distracted by all this boilerplate code, but if we want to take a look at it, is just a few lines above, and we don't need to navigate the class as the previous solution. And for free, we obtain a parametrized method: in we need to pass the client as a parameter in the future, we can do it without modifying a single line .

What I love about this trick is that it can aslo be used with Closures, so you can do stuff like the following:

[ name: 'diego', lastName: 'toharia', country: 'spain' ].each { 
   factName, factValue, capitalizedFactValue = factValue.capitalize() ->
   person[factName] = capitalizedFactValue
}

Ha . Love it.

Bonus track

When using this last trick, be careful: if the method that receives your closure checks the number of arguments it receives in order to invoke it with the proper number of arguments, you can see how your method initialization is replaced by an unexpected value! An example of this would be the closure passed to a Grails validator:

class SomeDomainClass {
   String prop
   static constraints = {
      prop(nullable: true, validator: { prop, domainClass, propIsEmpty = prop.trim() != "" -> 
         propIsEmpty || validateProp(prop)
      }
   }
}

In this example, the custom validator for the property prop init the propIsEmpty parameter in the closure signature, but Grails is smarter: if you pass a closure with one argument, it invokes it with the property. If it can receives two arguments, it passes the property and the object. But if the closure declare three arguments, it passes the current validation errors as well, so you will find that propIsEmpty won't have what you expected . So use it carefully .

• Me obsesione con esa canción, escuchándola muchas veces, berreándola en el coche, intentando tocarla con la acústica, y a veces, Dios no lo quiera, grabándola con el Garage Band a ver qué suena.
• Me dedique a ponérsela a mis allegados, o a compartirla compulsivamente en las distintas redes sociales de las que hago uso.

Normalmente, el segundo fenómeno implica enviarle una traducción de la letra a mi mujer, de esa manera sé que las posibilidades de que ella también se enganche crecen exponencialmente . Así que a partir de ahora, cuando eso ocurra, intentaré aprovechar para compartir el tema y la traducción con España y el mundo (apagar modo reality :lol ).

La canción que hoy traigo es de un grupo llamado Middle Brother (Hermano del medio, vaya, como yo ), una banda de folk rock estadounidense que representa la palabra americanada, pero en el buen sentido . El tema en cuestión es el que cierra su único álbum a día de hoy, de mismo nombre, y se llama Million Dollar Bill. La escuché gracias a mi dealer musical habitual, mi hermano (bajista de los archifantásticos Les Vivo), y me tiene absolutamente enganchado. Aquí os dejo una versión hecha en la calle tras conducir por la noche después de un concierto (o eso dicen, por sus pintas me lo creo):

Aunque también podéis escuchar la preciosa versión de estudio, que aunque suena mucho mejor, es menos divertida de ver . Y a continuación, mi traducción, que seguramente tenga fallos (y por supuesto, agradeceré correcciones ).

About the module

The next Puppet module I wanted to talk about is the Grails puppet module. Same as the other modules for Puppet, is published on OSOCO’s Github account, and is one of the most simple, but one of the most used in our infrastructures, for obvious reasons .

This module allows you to install multiple versions of Grails in a puppet node. The usage couldn’t be simpler, as you can see in the following code:

class jenkins {
    ...
    grails { "grails-1.3.5":
        version => '1.3.5',
        destination => '/opt'
    }

    grails { "grails-1.3.9":
        version => '1.3.9',
        destination => '/opt'
    }

    grails { "grails-2.0.0":
        version => '2.0.0',
        destination => '/opt'
    }

    grails { "grails-2.0.1":
        version => '2.0.1',
        destination => '/opt'
    }
    ...
}

In this example, a class jenkins declare multiple Grails installations (in order to launch the tests battery for each project with the proper Grails version) by adding various grails resources that is parametriced by the Grails version and the destination directory. The Grails module will resolve the download URL (that since 1.3.6 version must point to Amazon S3 instead of being self-hosted as in previous versions), and retrieve and unpack the ZIP only if necessary (i.e if the given Grails version is not already installed in the specified destination directory).

Dependencies

The module depends on OSOCO’s Puppet Wget module, so you should checkout both modules into your modules directory. Or, if you are using puppet-librarian, you can add the following to your Puppetfile file:

mod "wget",
   :git => "git://github.com/osoco/puppet-wget.git"
mod "grails",
   :git => "git://github.com/osoco/puppet-grails.git"

Motivation

Imagine you are developing an Android app that need to receive push notifications. The application in charge of sending them to GCM is being developed by another team, and not only is not finished yet, but also that team may be in another department, or even in another company. You want to make sure your Android app fullfill the specifications (i.e it reacts in a way when receives a certain push notification), but you don’t want to depend on that other team (and neither want to develope a sender app yourself ).

Solution

Well, that need of a configurable GCM sender app is the second artifact Adrian Santalla and I developed in our two first OSOCO’s hacker fridays, (being the first the Grails Android GCM plugin), the Android GCM Sender.

Subscribe your device tokens by using the supplied URL, and introduce your project ID

Started as a test app for the plugin, we felt it would be easy to evolve it until the point of being useful to anybody: we just needed to parametrice the project ID (that you will get by creating a Google API project and create an action that let Android devices subscribe. You can visit the Android GCM sender in the following URL: http://grails-android-gcm-sender.herokuapp.com/.

Usage

The first step would be to subscribe your Android device ID using the URL http://grails-android-gcm-sender.herokuapp.com/device/subscribe?deviceToken=yourDeviceToken&projectId=yourProjectId. Don’t forget to substitute yourDeviceToken and yourProjectId with your project ID and Android device token, and remember that this URL is designed to be invoked through some kind of HTTPBuilder inside the Android app – that’s why it doesn’t any output :-). But if you want to use it directly in your browser you can do that as well .

Compose your message, send it to the selected devices and see the message result

After that, write your project ID in the Android GCM Sender homepage form and press the refresh button. You will be presented a form that allows you to send a message (simple or composed) to one or many Android devices. Please note that two fake devices will be always available in case you want to do some tests with them. After filling the form, you can press the Send button, and the message result will be shown to you. And if your device ID and project ID are valid ones, you should receive a push notification with the message you composed in the previous view :-D.

Please bear in mind that, in order to keep our data small, your device and project ID are only kept for 24 hours – think of it as a feature since you don’t have to worry about unsubscribing and stuff like that. In fact, since the database is in memory, we don’t have access to it.

Source code

The Android GCM sender is up and running in Heroku, but you can see the source code in OSOCO’s Github account, and even host it yourself if you want. The app is developed using Grails, and the UI is spiced up with Ajaxify.

The idea is pretty simple: when you have different peaces of code that are enclosed by the same “header” and “footer” code, you should extract this header and footer to a new method that receives the changing code as a parameter. Simple but powerful. The typical example is the usage of a resource that must be opened before using it and closed after:

def someWritingMethod(filePath, stuffToWrite) {
   file.open(filePath)
   file.write(stuffToWrite)
   file.close()
}

def someReadingMethod(filePath, charsToRead) {
   file.open(filePath)
   def readStuff = file.read(charsToRead)
   file.close()
   readStuff
}

With execute around, this could be changed to the following:

def someWritingMethod(filePath, stuffToWrite) {
   withFile(filePath) { file ->
      file.write(stuffToWrite)
   }
}

def someReadingMethod(filePath, charsToRead) {
   withFile(filePath) { file ->
      file.read(charsToRead)
   }
}

private withFile(filePath, Closure fileUser) {
   def file = file.open(filePath)
   def result = fileUser(file)
   file.close()
   result
}

As you can see, the second code have multiple benefits: first and most important, we avoid duplicated code, the worse thing that a programmer could do. Secondly, we simplify our business logic methods by not defining variables that will be used later (for example, in someReadingMethod, we define readStuff for later returning this, forcing the person that is mantaining our code to read more of it just to be sure that the readStuff variable is not modified later).

This is the most simple case, but there are tons of usages that you wouldn’t probably think of. Here is a Grails inspired example that deals with one of our most beloved friends from the Java world, the try-catch:

class UserController {
     
    def userService

    def updateUser(userId) {
        treatExpectedExceptions('index', userId) {
            userService.updateUser(userId, params)
        }
    }

    def updateUserGroup(userId, groupId) {
        treatExpectedExceptions('showGroup', userId) {
            userService.changeUserGroup(userId, groupId)
        }
    }

    private treatExpectedExceptions(actionToRedirect, userId, Closure exceptionThrower) {
         try {
            exceptionThrower()
            flash.message = "action.$actionToRedirect.success"
            redirect action: action, id: userId
         } 
         catch (MultipleValidationException validationException) {
            flash.error = "action.$actionToRedirect.validation.failure"
            redirect action: action, id: userId, params: [ invalidFields : formatInvalidFields(validationException) ]
         }
         catch (UserNotFoundException userNotFoundException) {
            response.sendError HttpServletResponse.SC_NOT_FOUND
         }
    }
}

As you can see, the user controller always follows the same structure: it tries to perform some business logic with a supplied user id. When the logic fails because of the user id not corresponding to an existing user, a 404 response is sent. If the logic fails because the changes made to the user are not valid, a error message is set and the invalid fields are included in the redirect parameters in order to be formatted in the view. And if the logic doesn’t fail, a success message is set and a plain redirect is done.

Here you can sense another benefit of using the pattern: when another programmer have to add a new method to the controller, he will see the existing code and probably will try to adapt the new method to use the treatExpectedExceptions, leading the UserController to be a uniform and easy to understand class. And by not having to rewrite all the exceptions logic, the UserController has became an easy to extend class too .

And this is just an example that I made up while writting the post, but probably could be used in multiple controllers in the projects I’m currently working . So, as you can see, is a really simple idea that can be really powerful.