<< Previous | Home

Vancouver's 1st Groovy/Grails Meetup

If anyone in Vancouver is wondering what Groovy/Grails is about, come over to Workspace on the 26th and find out. Gerald Bauer and I (perhaps a 3rd person) will be presenting.

My presentation will be on Grails - my plan is go from a big picture to the details by deconstructing a little web app, and then reconstructing parts of it to demonstrate what it is like to create with Grails. It should be a lot of fun.

Grails - just use it already

Now and then I see worries regarding using Grails for production apps, even though there are quite a few already out there. For the last few months I have been working on another one. All I can say is, Grails is the least of your worries! In fact, it's the part that 'just works' for the most part.

I won't be able to get into details about the app. But I can say it consists of 34 domain classes, 50+ views and about 2 million records inside a PostgreSQL database. For the first part of the project, I was lucky enough to get the lions share of the Grails programming, while others worked on data and report conversion from the old Access app.

So, not a huge app, but far more than simply serving up pages, or a simple todo list.

The good stuff:

  • Lets you get things done. Interactively creating the application is a joy that cannot be described.
  • Malleable. Take data queries: we use dynamic finders, HQL, SQL - whatever works best in the current context. There are many other instances where Grails doesn't restrict what we want to do.
  • Plays nicely. In the end it's just code on a JVM. We can reuse whatever libraries we please, in our case, Jasper Reports, XStream, OpenCSV, and many others. And then package it all up in a war. And of course, run tests using familiar tools like JUnit. The list goes on.
  • You get to code in Groovy almost all of the time! This is a huge factor to me.

 The minor problems:

  • We started with and are still using Grails 0.5.6, and so there are some minor quirks to live with that have been fixed in later versions.
  • I wish I had the speed and reloading capability of 0.6+! Upgrading is a small risk, but one to take later on, we still have too many other things to finish.
I don't know if these are really problems! Just irritations.

It seems the hardest issues were with the other components: PermGen issues, strange performance problems on PostgreSQL (some of the queries are very complex), bizarre problems on different operating systems (OS X for developing locally, Windows Server of some sort for test and production), an odd problem where the redeploy script doesn't work at random times. And many other things. But few that are the fault of Grails.

So stop worrying if you should try Grails, and worry about, oh, the other 80% of things that really deserve the worry!

The Perils of Bash

I wanted to test some Grails 0.6 features, but for some reason the snapshot I downloaded was not upgrading my project properly. I made a copy of my project folder so I could revert to my original code easily. After a series of attempts to upgrade, interspaced with a few 'rm -r' and 'cp -R' commands, I accidentally selected a 'rm -r' command from the history and autocompleted my backup folder in addition to the source folder! I could feel the nerve impulse surge from my brain and down my arm, helpless to stop it reaching its destination - a finger twiched, the return key depressed, and my work evaporated.

The obvious lesson: don't goof around when tired at the end of the day without committing the work first. But now what? Happily for us programmers, we work with text. Using grep for file recovery didn't occur to me, but after a bit of Google inspiration I recovered most of my work. The command looks something like this:
sudo grep -a -B 2 -A 200 'class Lists' /dev/disk0 > classLists.txt
where B == show lines before, A == show lines after and 'class Lists' is the text to search for.

Once I had my work back, it was time to prevent this from ever happening again. A little while later I had a nice rm script on my machine that would move files to the trash. The script comes from http://www.cs.ecu.edu/~collins/rm/rm.html and some outdated instructions are at http://www.oreillynet.com/pub/h/334.

The commands I used to set things up look something like this:
cd ~
mkdir bin
cd bin
curl -o rm "http://www.cs.ecu.edu/~collins/rm.txt"
chmod 700 rm
echo 'alias rm=$HOME/bin/rm' >> ~/.bash_profile
source ~/.bash_profile
Now I am a little safer from myself. Hopefully the above instructions will be of use to others.