Recording of Grails / Terracotta webinar

In case you missed it and in case you're interested, Terracotta has posted a recording of the webinar that Mike Allen and I held a couple weeks ago. You can catch it in all of its glory (or lack thereof :) at http://bit.ly/scaling_grails.

During the demo I mentioned a blog post coming to the GQuick blog where we would add Quartz scheduling to TekDays (the sample app from GQuick), well that post ended up here instead.

Once again I'd like to thank the folks at Terracotta for their cool technology and for their support of the Grails community.

Quartz and Grails: A Quick-Start Guide

Terracotta's Quartz scheduler has always played a key role in Grails development. Originally it was built into the framework; now it is a core plugin. Quartz allows us to have code executed at regular intervals. This a great way to have batch processes or system checks performed at off hours.

The Quartz plugin provides three different mechanisms (triggers) to determine the timing of job execution: Simple, Cron, and Custom. With a simple trigger, we can set the amount of time to wait before initial job execution, an interval to wait between repeated executions, and the number of times the job should be executed. The cron trigger also allows us to set a start delay. Then it takes a cron expression, which we can use to set a wide range of schedules. With a custom trigger – well, you can use your imagination.

In our TekDays application, we have lists of tasks that need to be done to organize a technical event. These tasks have due dates, but we currently have no way of reminding event organizers and volunteers when they have tasks that are overdue. That's where Quartz comes in. In this post, we'll create a Quartz job to check for overdue tasks and send a reminder email to the person assigned to that task.

First, we'll install the Quartz plugin:

> grails install-plugin quartz

The plugin provides us with a new Grails script, create-job. We'll use this script to create our TaskReminderJob.

> grails create-job TaskReminder

The create-job script will create a stubbed out TaskReminderJob.groovy that looks like this:

class TaskReminderJob {
   def timeout = 5000l // execute job once in 5 seconds

   def execute() {
       // execute task
   }
}

We'll replace the timeout property with a triggers closure in a moment, but first let's look at the execute method. This method will be called at the intervals that we determine with the triggers. We can put any code we want in this method, but the most common practice, and the one we'll follow, is to call a method of a service class.

For triggering the call to our service method we'll use the cron expression: "0 0 2 ? * MON-FRI", which will execute every weekday at 2:00AM. This is how our new TaskReminderJob looks:

class TaskReminderJob {
   def taskService
   static triggers = {
       cron name: 'cronTrigger', cronExpression: "0 0 2 ? * MON-FRI"
   }

   def execute() {
       taskService.sendTaskReminders()
       log.info("Task reminders sent on ${new Date()}")
   }
}

Now we need to add the sendTaskReminders() method to our TaskService. This method will use the Mail plugin (which you can find more about at http://grails.org/plugin/mail), so we'll add that to TaskService too. Something like this:

class TaskService {
   def mailService

   //...

   def sendTaskReminders(){
       def tasks = Task.findAllByDueDateLessThan(new Date())
       tasks.each{task ->
           def recipient
           if (task.assignedTo)
               recipient task.assignedTo.email
           else
               task.event.organizer.email
   
           mailService.sendMail {
       to recipient
       from "admin@tekdays.com"
       subject "Task Reminder"
       body """The following task is overdue:
      ${task.title}"""
           }    
       }
   }
}

That's all there is to it. We now have the confidence of knowing that event organizers and volunteers will be kept informed of the tasks they need to do. And based on the experience of some people I know who recently put on a tech conference, this is important.

Now, something that in days past might have required us developers to climb tall mountains to make supplication to sysadmins wearing robes and conical hats has been made almost trivial by Quartz and the Quartz plugin. I, for one, am impressed and grateful. (I'm getting way too old for mountain climbing.)

But wait (as they say) – there's more. As TekDays gets more and more traffic (which we know will happen with all the new and exciting technologies coming out these days), we will want to take advantage of the power of Terracotta and cluster our Quartz jobs. To do this, we just need to create the property file: grails-app/conf/quartz.properties. Then enter the following values in this file:

org.quartz.jobStore.class = org.terracotta.quartz.TerracottaJobStore
org.quartz.jobStore.tcConfigUrl = localhost:9510
org.quartz.scheduler.instanceName = TekDaysScheduler
org.quartz.scheduler.instanceId = AUTO
org.quartz.scheduler.jmx.export = true

Finally, we'll copy quartz-terracotta-1.1.0.jar in our lib folder. The quartz-terracotta jar comes in the Terracotta download, which can be found at http://www.terracotta.org/dl/oss-download-catalog.

Now, if we've clustered our TekDays application as described in an earlier post, our scheduled jobs will be spread out across all the nodes. Not too shabby.

There is still some room for improvement in the Grails / Terracotta integration story, but I continue to be amazed at just how low the barrier of entry is to these powerful products.

Like speaking at a conference in my bath robe

On April 27th at 11:00am Pacific time, Mike Allen and I will be holding a free webinar on clustering and scaling grails applications the easy way. A webinar is a cool thing. It's like a tech conference session where you can't see anybody. So, while you're sitting at your desk at work or at home or in a coffee shop, Mike will be in California somewhere and I'll be sitting in my basement office in St. Louis, quite possibly still in my pajamas.

But that's not the important part. The important part is that we'll be talking about how easy it is to make a Grails application scalable. To demonstrate that we'll be using one of my favorite sample apps, TekDays from Grails: A Quick-Start Guide.

If you haven't already, go ahead and sign up at http://bit.ly/aeDQ3I. The whole thing will be recorded and posted later. So, if you can't make it on the 27th or if 11am Pacific is the middle of the night for you, register anyway so you can be notified when the recording is available.

If you can make it though, it would be great to have you.

See you there (in a figurative sense),
Dave

ÜberConf

I am very excited about the upcoming ÜberConf - June 14 - 17, Denver, CO. Even before I found out that I'd be speaking at it, I was planning to attend. I've been to a lot of conferences, and I think this is going to be the best one ever!

I've been attending technical conferences for over 15 years. I've been to big ones and small ones, free ones and expensive ones. Just doing a quick count in my head, I think I've been to around 35 tech events. Most of these have been as an attendee and on my own dime, because I am convinced of their usefulness and value. More recently I've been speaking at some conferences. Over the years I've become somewhat of a tech conference connoisseur.

Of all these events, the best have been the ones put on by Jay Zimmerman of No Fluff, Just Stuff fame. The NFJS events and others, such as the Groovy/Grails Experience, the Agile IT Experience and SpringOne/2GX, have some elements that other conference organizers just can't seem to duplicate. CodeMash comes close, and the old Borland Developer Conferences were also pretty good, but neither of these are quite up to the level of an NFJS event.

JavaOne used to score real high on the technical content before it became JavaFX One, but the conference organization and overall experience was always lacking. The SD conferences usually had some big names that were worth the price of admission, but the rest of the sessions were hit and miss, and the mobs that were there just for the free expo floor made it so difficult to get to sessions that it often wasn't worth it.

The NFJS events have speakers who are well known, though maybe not as famous as some of the SD headliners. More importantly, they know their stuff, and they have tons of experience in presenting it to others. And since the event size is purposely kept small, it's easy to get to the sessions of interest and easy to get time to talk with the speakers. The schedule is always arranged with plenty of break time for the hallway discussions and questions after the sessions. And all of the little details that we don't really notice but that provide for a much better learning experience are taken care of.

But back to ÜberConf. This event will, I'm sure, have the quality experience and flawless execution common to all NFJS events, but with an expanded focus, expanded schedule and an amazing line-up of speakers (and me too :).

ÜberConf's technical content will be what JavaOne should have been over the last couple years. It will fully embrace Java the platform, with sessions on Java, Groovy, JRuby, Clojure and Scala. ÜberConf goes beyond just the languages and draws from the rich diversity of open source communities that have found a home on the JVM, with Grails, Wicket, Gradle, Maven, Gaelyk, Camel, and more. And since what we're developing with is only part of the story, ÜberConf goes on to bring together some of most important ideas in agile processes from speakers such as Esther Derby, Johanna Rothman, David Hussman, Michael Nygard, and others.

With a mix of 90 minute sessions and 3 hour workshops, and eight concurrent tracks to choose from, ÜberConf will be packed with great content. With attendance capped at 500, it will be easy to get time to talk with speakers and other attendees - and getting to and from the sessions will be easy.

I speak from experience when I say that you will leave this conference full of new ideas and inspiration. Check out the schedule. You'll find plenty of sessions that apply to your current work, but don't stop there. To get the most out of an event like this, you need to go to sessions about topics you know nothing about. You will be amazed at how much you can learn about what you are currently doing by learning about new tools and technologies.

Check out the site for details. There's much more than I've discussed here, including sessions on iPhone, iPad and Android development. For what's included, the full registration price is a steal, but if you register by Monday, April 12th, there's a big discount. So register now, or register later, but do register and attend this awesome conference.

See you there!

Hats Off to Terracotta

One of the advantages of Grails is the way that it gives us access to the wealth of proven frameworks in the Java ecosystem. There are Java frameworks and libraries to help with every aspect of application development you could imagine. For many applications, a major requirement that the Java world has worked out quite well is scalability. And when we think of Java and scalability we naturally think of Terracotta.

Of all the open source libraries and frameworks available in the Java ecosystem, Terracotta is one of the most Grails-friendly. In fact, one of Terracotta's projects is built right into Grails (EhCache). Another is one of the most popular Grails plugins (Quartz). What's really cool is that as an organization, Terracotta sees the important role that Grails is playing the Java development space, and is actively working to make their products integrate better with Grails.

Recently, I undertook the task of trying this integration out with the sample app from my book, Grails: A Quick-Start Guide. Other than Quartz, I hadn't used any of their products before, so I was a bit intimidated, but I was pleasantly surprised with how easy it is. As with any tool, you can get into more advanced usages that may take more configuration and more work. But the basic integration was a snap!

I've put up the first of a series of blog posts on the GQuick blog, detailing the steps needed to integrate Terracotta's Web Sessions Express clustering tool with the TekDays application from the book. Future posts will cover some of the other products in the Terracotta family.

If you're a Grails developer and haven't taken a look at Terracotta, check 'em out at http://terracotta.org.

Also check out these resources by others in the Grails community who have discovered the synergy of Terracotta and Grails:

http://adhockery.blogspot.com/2010/02/full-page-caching-in-grails-with.html

http://burtbeckwith.com/blog/?p=244

http://ehcache.org/documentation/grails.html

http://alterlabs.com/technologies/java/terracotta-plugin-for-grails/

GroovyMag Plugin Corner: Grails Help-Balloon Plugin

The following post is a reprint of the Plugin Corner article for the January 2009 issue of GroovyMag. You can find this and other past issues at http://groovymag.com.

Sometimes our web applications get a little more complex and not entirely intuitive. When this happens, it is important to find ways to provide the cues and clues that our users need to find their way around and to accomplish the task at hand. The Help-Balloon plugin can help with that.

The Help-Balloon plugin provides a pair of tags which will render an icon in your view. This icon is a link which brings up a balloon shaped, non-modal dialog with the text that you give it. It’s simple, but very handy. Let’s see how we can add this helpful gadget to our toolbox.

First things first. Make sure that you are in your project’s root directory, and then run the following command:

grails install-plugin Help-Balloon

The next step is to add the <g:helpBalloon> tag to the head of our .gsp page. For our example we will start with our List view. Here’s the head section of our list.gsp:

<head>

<meta http-equiv="Content-Type"

content="text/html; charset=UTF-8"/>

<meta name="layout" content="main" />

<g:helpBalloons />

<title>Book List</title>

</head>

The <g:helpBalloon> tag will load the Prototype Javascript library (if it isn’t already loaded). By default it will find this library in your Grails installation. If you have a different location for Prototype, you can declare that with the base attribute. We’ll take a look at some other customizations that are possible with this tag shortly. For now, let’s add a help balloon to our list view.

In our list.gsp we will add another <td> to our table. If all goes well, this will give us an icon at the end of each row in our list table.

<td>

<g:helpBalloon title="Book Info"

content="${bookInstance.moreInfo()}"/>

</td>

</tr>

As you can see, the <g:helpBalloon> tag has title and content attributes. The title will show up as a heading in the balloon and you can probably guess what the content ends up as. For static
text from a message bundle, you can also use the code attribute. In our example the balloon content will be the same as the fields in the table but in a paragraph format. The content can be HTML so <br /> tags are an easy way to structure the text for our balloon, but if we put them in the tag it doesn’t work. For example:

<g:helpBallon title="Foo" content="line1<br/

>line2<br/>line3" />

will leave the content of the balloon empty. (At least that’s what happened to me.) However those same break tags passed in as the result of a method work fine. So, we added a moreInfo() method to our Book class to give us the text we want. This has a nice side-effect of keeping our page cleaner.

For the curious here’s the code for the moreInfo() method:

String moreInfo(){
  """$title <br/>
  by $author<br/>
  published in $published<br/>
  pg: $pages / ISBN: $isbn """
}

When we run our application we get something like this:



And when we click on one of those icons, the balloon will show
up:



That’s about all there is to using the Help-Balloon plugin - except that I promised to show how we can customize a couple more things with the <g:helpBalloon> tag that goes in the <head> of our page. This tag can has optional button and icon attributes (it can has cheezburgr, too). [After seeing this typo, I couldn't resist. -- Ed.] Both of these take a path to an image. If you specify an icon it will replace the "letter i" icon that is used for the link. The button attribute is used to replace the "x" in the upper right corner of the balloon.

The Help-Balloon plugin is based on the HelpBalloon system written by Beau Scott. You can find more detailed documentation and keep up with the latest updates of the Javascript code on his
site (see references).

There you have it: a Grails-easy way to add help balloons to your applications. I bet you can think of dozens of ways to use help balloons. Well, at least two or three. In any case, your toolbox just got a little more powerful.

Resources
Help-Balloon Plugin page:

http://grails.org/plugin/help-balloons

Beau Scott’s web site:

http://www.beauscott.com/

Grails: It Just Makes Sense

Grails. It just makes sense.

After a recent Gateway Groovy Users meeting, some of us were talking about the adoption of Grails, which is still on the rise. The signs are everywhere: the increasing number and turnout of Groovy user groups, the number of openings on various job sites, the increasing number of Java frameworks that are including Groovy support.

This led to another question. Why do individuals and companies still say things like “We can't use Grails because we are a Java shop”? Do “Java shops” use Spring? Spring beans can be written in Groovy. Do “Java shops” use JSF? JSF backing beans can be written in Groovy. Contrariwise, most Grails artifacts can be written in Java. Grails is a Java framework, just like Spring, JSF, etc. It just happens to be the first one out with Groovy support – and the best Groovy support, at that.

Consider that Grails uses Groovy for some things for which other Java frameworks use another non-Java language – one that is much further from Java in syntax and usage than Groovy. XML is not Java. XML does not compile to Java byte-code. Grails allows you to use Groovy for many of the things for which other frameworks require (or used to require) you to use XML. Now some other Java frameworks are providing support for Groovy in configuration files, instead of XML. So the differences continue to blur.

More and more developers are seeing the value of Groovy, and consequently tools like Grails and Griffon. You can see this in various polls around the internet, some of which we've discussed in a previous blog post. Now there is hope that more decision makers will get a clue. In a recent article on Forbes.com, Dan Woods makes the case for Groovy in companies that already use Java. The whole article is good, but this line pretty much sums it up: “For a company with a heavy investment in Java, Groovy should be a no-brainer.”

I'm not saying that every Java developer should start using Grails, though that might not be a bad idea. :-) There are some that prefer a component-based framework such as JSF or Wicket to a page based framework like Grails. That's fine: with JSF 2.0 and its Groovy support, JSF is showing some promise.

The bottom line is to use the framework that will help your team be the most productive and do the best job. But we need to get beyond the “we can't use Grails because we are a Java shop” stuff. It just doesn't make sense.