Grails Best Practices presentation

This week I presented on Grails best practices at the Scottsdale Groovy Brigade user group. I’ve had several requests to share the slides, so I’m posting them here for easy access.

BestPracticesPresentation

For those that didn’t attend, the abstract was as follows:

Grails is an opinionated convention over configuration framework. However, there are still lots of options for how we structure our code. This presentation will be a semi-opinioniated talk about how we can leverage and make further improvements to the existing conventions in order to have better performing and more maintainable applications.

David Kuster is a senior developer and application architect with over 10 years experience. He has worked with Grails for the last 3 years, was previously a GWT bigot, and has made an effort to scale back his technology rants so they are only semi-opinionated.

For anyone coming across these slides who wasn’t at the meetup, let me reiterate a couple things. I stressed the “semi-opinionated” aspect as this is based quite a bit on my own experience as opposed to a one-size-fits-all mentality. I also didn’t have time during a one hour lunch presentation to cover everything listed here – notably plugins/plugin-oriented architectures and database performance – which could be presentations in their own right. (And the database slides don’t even mention eager vs. lazy fetching, the N+1 queries problem, collections potentially loading every instance just to add a new object at the end, etc etc etc.)

Finally, (and this is such an internet cliche, I’m sure) this whole blogging thing obviously hasn’t taken off in my mind like I thought it might. The idea now is to begin the effort again, and these slides will hopefully be a starting point for multiple future topics. One of which – and this isn’t mentioned in the slides but was during the talk – is just how many anti-patterns the default Grails scaffolding introduces to new users and how we might go about fixing that. Unless someone already has and I just don’t know about it?

Regardless, hope you enjoy.

Introducing Command Center – a Mini-IDE for command line Grails development

In my previous life as a Java developer, I was a devotee of the IDE – primarily Eclipse.  When I was introduced to Grails, I switched over to STS and things were good.  But, when I started a new job about a year ago and was given a company-mandated Windows laptop for development, Maven and STS expressed such mutual hatred that I was driven to explore text editor options.  After evaluating many options my life was changed forever upon finding Sublime Text 2.  (Seriously, as much as a text editor can change someone’s life, ST2 has done it – the 4-pane grid layout is a huge productivity win.)

However, moving to a text editor meant using the command line again.  The DOS prompt, 1980s-era, Windows command line, with all the joy it gives – block text selection (after right-clicking and selecting ‘Edit -> Mark’), an inability to clear  output while a command is still running, and a need for continual assurance, that yes, in fact, I do want to terminate that batch job.

Turning on logSql=true in Grails and attempting to debug the output of multiple requests in the Windows command line is a recipe for madness.  I found myself going back to STS (which by now I’d succeeded in getting working) just so I could clear the SQL output between requests.  Besides which, at this point I’d tired of typing “grails run-app” for what felt like the 10,000^th time.  There had to be a better way.

Hence, the kernel of an idea for an app that would wrap the command line was born.  The result is a Java Swing app (but written in Griffon for Groovy goodness) that provides a number of conveniences without the bulk of a full IDE.

Command Center (or Grails Command Center, but I don’t think I can call it gcc – that acronym is already taken – so, suggestions on names are welcome) allows often-used commands to be configured as buttons which can then be executed in a single click.  New command buttons can be created using the “*” button, and a button’s config can be edited by right-clicking on it.

For instance, I find if I’m working on a specific unit or integration test for a while, I’ll quickly set it up as a button, click it in between code tweaks, and delete it once I’m satisfied with the resulting code and tests.

Commands can be entered directly into the combo box, with the history of these manual commands remembered in the drop-down.  Compare this to searching through your command history using the up and down arrow keys – which includes all the calls to “cls” or “clear”, and on Windows all the “y” entries to yes, really, terminate that batch job.

Output can be cleared with a keystroke (Ctrl/Cmd-W), the current command can be killed with a keystroke (Ctrl/Cmd-Q), the output can be searched and all instances of the found text highlighted, with more to come.  The Help -> About menu contains a list of possible future enhancements, but one of the main ones is to use something smarter than a text area for the output to allow for additional debugging possibilities – automatic color coding of user-specified words or phrases, font styling, etc.

There are more options in the app but I’ll mention a final one here.  While the app defaults to assuming all commands begin with “grails” – hence the “grails>” prompt above – this is configurable.  For instance, on Linux I use a script I’ve named “g.sh” which automatically determines the correct version of Grails to load based on the current project’s application.properties file, so my prompt is “g.sh>”.  An alternate way to achieve the same result would be to specify the full path to the correct bin/grails script for the current project.  And note that this prefix can be removed for a higher level of flexibility, at which point the buttons would need to be updated from “run-app” to “grails run-app”, but could also be used for non-Grails commands.

Note that currently one large shortcoming of the app is the inability to respond to requests for input in the text area.  So anything that prompts for input – “do you want to upgrade this plugin?” – will still need to be run from the actual command line.

I plan to open-source this tool on Github soon – once I’ve had the chance to clean up the code a bit and become a little more familiar with Git, honestly.  🙂  And by writing this app in Griffon, the code and project structure are very similar to Grails which should allow for easy extension and modification by Grails developers.  But in the meantime, give it a try, see what you think, and let me know.  I hope it improves your productivity and makes you hate the command line at least a little less.

Download here: GrailsCommandCenter.jar
(just in case, run the app as “java -jar GrailsCommandCenter.jar”)

Enjoy!

dave