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.
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
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.txtwhere 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 ~Now I am a little safer from myself. Hopefully the above instructions will be of use to others.
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