Tag Archives: grails

An haptic notification device for Grails (but not only)

I am a commuter and during my commuting I often work on some Grails projects.

As Grails users knows, there are tasks that requires a rather big amount of time (re-run an app in non-interactive mode, run a test suite etc…) even on fairly recent hardware.

Instead of watching the screen during these interval of time I prefer to lay my eyes somewhere else for at least a couple of good reasons: the first one is that programmer’s eyes are always greedy for some rest, the second one is that I live (and commute through) one of the most beatiful place in the world and taking some relaxing view of the sight is amazing!

So I needed a way to know when my attention should go back to the screen  without the need to constantly check it.

The first obvious option was to produce some kind of audible notification (and such solution are already there for Grails), but this has two problems. The first one is that  volumes of music and notifications always mismatch so it happens that the notification sound is either too low or too high. The second one it that when I’m not using hearpones I don’t want to annoy other travellers with my notification sounds.

So I got the idea of buid my own “haptic notification device”.


The first attempt with such device was a cheap bluetooth bracelet that, once paired with your smartphone, was ringing on every call.

The idea was to pair it with the PC and send a “RING” command whenever I needed to notify something.

Unfortunately I never managed it to work, and that’s a pity because that hardware was really small and light.

I haven’t really surrender with it, but meanwhile I decided to build my own vibrating box.

In the beginning I thought to use an Arduino Nano with a bluetooth module, but it required batteries and the size of the project wasn’t small enough to comfortably fit into my pocket.

Then I used a spare programmable USB I/O port that was lying around in my drawers.

The device is capable of a lot of things, however I’m just using one of the digital output. Probably you can find something cheaper with less features (and if you do, please leave a comment and let me know: I’m interested in other similar devices!)

To achieve the vibration I used a 3V vibrating motor found in these small “walking” bugs that I bought for a couple of euros some  years ago.


and here’s the schematic of the hardware:



I won’t explain the logic here (that is, anyway, pretty simple), but basically what happens is that setting the output port A2 to the “high” state, turns the motor on

And here’s how I packaged everything:



Programming the USB I/O device is quite easy. I wrote a quick and dirty shell script (/usr/local/bin/hapticnotify.sh) that turns it rapidly on and off for a couple of times.


# the serial name: might be different on your system

# the number of cycles on/off

# the duration of a single vibration

# configure the serial port parameters
stty -F $PORT cs8 57600 -ignbrk -brkint -icrnl -imaxbel -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke noflsh -ixon -crtscts -hupcl

# send a reset command to the I/O device
echo "R" > $PORT

# configure every port to output mode
echo "C,0,0,0,0" > $PORT

# produce a sequence of short vibrations
for i in `seq 1 $N_CYCLES`; do

    # vibrate!
    echo "PO,A,2,1" > $PORT
    sleep $DELAY

    # mute!
    echo "PO,A,2,0" > $PORT
    sleep $DELAY

The script makes use of stty that is commonly packaged in GNU/Linux distribuition (at least, it is in Fedora 21, which I’m running)

Integration with Grails

Integrating with Grails has been straithgforward thanks to the power of the framework events management.

Events are triggered during executions of Grails target and allows you to hook custom event handlers.

Handlers can be defined inside the project or on a per-user basis.

I used the second approach so that all my project would use my haptic notification box without any modification.

The Grails events I was interested in were:

  • the project is running
  • a test suite has finished running
  • a war building is complete

so what I did was to create a file named $HOME/.grails/scripts/_Events.groovy with the following content:

String HAPTIC_SCRIPT="/usr/local/bin/hapticnotify.sh"

eventStatusFinal = { msg ->

eventTestProduceReports = { msg ->

and that’s all!

The only possibly required step is to make sure your user has the privileges to use the serial ports (in Fedora all you have to do is to add the user to the dialout group)

Grails: how to test a rolling back service’s method

A few day ago I was writing a financial service involving several related domain classes. Under some circumstances I wanted the entire transaction to rollback.

According to the documentation, a Grails transaction is rolled back whenever a RuntimeException is thrown during its execution (this is the default behaviour in Grails, but you can configure it to rollback a transaction for whatever exception you want).

When I finished I wrote some integration tests to make sure that everything worked as expected.

It didn’t.

Basically, the exceptions were thrown but the transactions were never rolled back. It tooks me a lot of hours to understand why.

Let’s show it with an example. Just say we have the ubiquitous Book and Author domain classes:

class Author {
    String name
    static hasMany = [books: Book]

class Book {
    String title
    static belongsTo = [author: Author]

and this is our example service:

class LibrarianService {
    static transactional = true
    def createBooks() {
        def authorETAH = new Author(name: 'Ernst Theodor Amadeus Hoffmann')
        def authorHPL = new Author(name: 'Howard Phillips Lovecraft')
        authorETAH.addToBooks(new Book(title: 'Gli elisir del diavolo'))
        authorETAH.addToBooks(new Book(title: 'L uomo della sabbia'))
        authorHPL.addToBooks(new Book(title: 'Il caso di Charles Dexter Ward'))
        // I've changed my mind! let's rollback everything
        throw new RuntimeException('changed my mind')

Now, you would expect the following integration test to pass:

class TransactionalTests extends GroovyTestCase {
    static transactional = true
    def librarianService
    void testRollback() {
        shouldFail(RuntimeException) {
        assertEquals 0, Book.count()
        assertEquals 0, Author.count()

on the contrary, the assertEquals statements will both fail.


As we said, every service method call is bounded in its own transaction, unless it is already inside a transaction. That is the case when the integration test class declares to be transactional with the default line:

static transactional = true

indeed, if you change it with:

static transactional = false

the test will pass.

What does this change implies for your test class? It implies that test methods are no more wrapped in transactions and automatically rolled back, so you’ll have to take care of cleaning the house after every test!