Kickin' down the cobblestones

Grails: A Quick-Start Guide is back

2011-12-12T08:32:00.000-08:00

No, there isn’t a second edition (yet). But some may have noticed that the ebook of Grails: A Quick-Start Guide (or GQuick) was no longer available on The Pragmatic Programmers’ site. The thought was that it was becoming obsolete. But after several requests from developers who are still getting started with the Grails 1.x framework, the publisher decided to make it available for a while longer.

Once Grails 2.0 is out and beginning to be widely adopted, GQuick will probably be retired. But for now, it remains one of the best options for developers wanting to quickly take advantage of the powerful Grails framework.

The publisher is no longer printing copies of GQuick, but if you really want a copy of the dead-tree edition, you can find one on Amazon.com. (The price seems to be climbing, though. Currently, new copies are going for $54.39, and used copies for $48.85.)

For those who have asked, I am working on a Grails 2 intro book (publisher to be determined). Stay tuned.

CocoaConf, And My Anniversary

2011-07-19T07:13:00.000-07:00

For the past few months, my sons and I have been working on a different kind of project: We are putting on a conference for developers on Apple platforms, such as iPhone, iPad, and Mac. It’s called CocoaConf.

The first CocoaConf is being held in Columbus OH, on August 12 - 13, 2011. We have an exciting line-up of speakers, including Daniel Steinberg, Bill Dudney, Chris Adamson, Christopher Judd, and Dave Koziol.

We will be having three tracks for the two days; this will include an all day hands-on iPhone workshop on the first day. It's shaping up to be a very exciting event.

The idea for this conference came when my #3 son, Solomon, began learning Mac programming using the book Beginning Mac Programming by Tim Isted. Taking inspiration from my favorite conference series of all time — No Fluff, Just Stuff — we began tossing around ideas. The NFJS events are known for a capped size so that they don't feel crowded, and for a focus on technical content, without the vendor hype and special events that other conferences tend to have. So that's what we are doing for CocoaConf.

I hadn't blogged about CocoaConf here since it has nothing to do with my usual topics, Groovy and Grails (although the CocoaConf site is being developed in Grails). But today I am going ahead with this post, so that I have a place to explain a crazy (but fun) idea.

You see, 26 years ago today, my beautiful wife, Debbie, said “I do.” And today, we are celebrating this 26th anniversary with a one-day-only CocoaConf discount of 26% off the current early-bird rate of $350. That's a $91 savings for today (July 19th) only! So: If you are interested in developing for the iPhone/iPad or Mac and can make it out to Columbus in August, you can now sign up for CocoaConf for only $259 — but only for today, July 19, 2011. Just go to http://cocoaconf.com/register and use the coupon code “ANNIVERSARY”.

I don't know if anyone will take advantage of this deal, but I thought it would be a fun way to celebrate 26 wonderful years of marriage to my amazing wife. She is the second best thing God has ever done for me!

(And finally, I'll leave you with a bit of child exploitation. Here's our #13, Joshua, telling us where he's headed in August.)

Groovy / Grails User Groups

2011-01-25T12:57:00.000-08:00

Technology user groups benefit both a technology (with the companies behind it) and its users. Java user groups around the world played a big role in the adoption and advance of the Java language and platform. Even now that Java is in its old age (or on its deathbed, depending on who you talk to), JUGs are actively promoting educational and community-building initiatives.

The Groovy community is benefiting similarly from a growing number of user groups. There are currently a few dozen groups around the world, and more are forming every day.

Now there is a website that can help you find a group in your area or help you get one started. G2Groups.net has a list of active Groovy user groups, with links to their sites. If you can't find one in your area, you can propose one. The site will post a link to your proposal on Twitter; you can retweet this to help get the word out. Then when others are interested in your idea, you'll get emailed about it, and you're off and running!

Once you get a few likeminded (and by "likeminded," I of course mean "brilliant") people together and get a group started, send me a note, and I'll invite you to the Groovy User Group Leaders list on Google Groups. This list is a great way to get support and ideas from other Groovy/Grails/Griffon/Gaelyk/Gradle/Getc. group leaders.

I've always said that the best feature of Groovy and Grails is the community. User groups are a big part of that. So if you're not already involved in a G2Group, get plugged in. You'll be glad you did.

JavaOne Has Been Replaced

2010-10-23T15:49:00.000-07:00

I just got back from SpringOne/2GX. It was an excellent experience. The enthusiasm and interest level of the attendees was great. The content, both on the Spring side and (of course) the Groovy and Grails side, was top-notch. There were nine tracks loaded with sessions that covered all kinds of topics related to software development in the Java ecosystem. There were long breaks with plenty of stimulating hallway conversations. Even the keynotes were informative. At most conferences, I skip the keynotes. I've become so used to them being just sales pitches from people who don't even use the tools they're talking about. That wasn't the case here. One of the highlights of the show was Graeme Rocher's keynote demo of the new NoSQL DB support in GORM.

As excellent as it was, I'm not saying that SpringOne/2GX has replaced JavaOne.

The week before SpringOne/2GX, I took two of my sons to the StrangeLoop conference in St. Louis. This conference covered several important areas of software development. There was good coverage of Java and alternate JVM languages and frameworks, along with a bunch of other languages and technologies. It wasn't held in a big conference center or a nice hotel, but in three different buildings, each with a unique atmosphere. This “small” midwest conference featured industry luminaries that you might have expected to see only in the Moscone Center. To see them on the stage of a St. Louis night club was something else!

Just this afternoon, after opening registration less than 4 days ago, the CodeMash conference in Sandusky, OH, sold out. This conference, like StrangeLoop, covers a broad range of technologies. Though there is a bit more .NET than I would like to see, :-) it is another excellent event, bringing speakers from across the country and attendees from across the globe.

I could go on. There is the Silicon Valley Code Camp, the Houston TechFest, and so many more. But you get the picture.

For several years now, JavaOne has been turning into more of a vehicle for pushing a certain technology (coughJavaFXcough). The attendance has been gradually dropping. As developers stopped going to JavaOne, they began to find other events to meet the need that JavaOne was not filling. Or they started their own.

The Oracle acquisition and the subsequent decision to make JavaOne an afterthought to Oracle's annual event didn't help, but JavaOne was already on its way out. It was destroyed the way so many companies are: by pushing what it wanted its customers to have rather than providing what its customers wanted.

So I can't point to a single conference that will be the new JavaOne (although Über Conf comes close). But I can look out at all the technical gatherings happening around the world—Devoxx, JAOO, the JAX events, the GR8 events, and so many more. And then I can look closer to home and see all the “small” conferences that are providing big benefits to attendees and speakers, and I can say it without a doubt. JavaOne has been replaced.

Move On In Peace

2010-10-09T10:35:00.000-07:00

As long as we measure the success of a movement by adoption numbers, any successful movement will eventually become compromised and diluted. This is a cycle that has repeated itself time and again. It happens in all areas of human interaction: politics, religion, science, entertainment, business, and technology, to name a few.

When this cycle occurs, the founders and early adopters often begin to feel bitter about where things have gone. They long for the “early days.” They begin to lash out at the masses that have morphed their creation into something less than what they had in mind. They may even make a concerted effort to reform the movement, and to bring it back to its roots. This is understandable, but it is not practical. I cannot think of a single instance where it has worked.

I've been thinking of a more sane and peaceful path: Founders and early members of a movement could, at the first sign of success, begin to plan their next move. Learn from what has been done before. Keep the essence of it, and start over. If the original idea was good, reuse and rebrand it. If those unwashed masses did bring a little value after all, borrow it and build on it. Or scrap the whole mess and reinvent the wheel. (Round does get boring after a while. :) )

Just be willing to let go of what was, and let those who have come run with it. Don't whine about it. Don't attack the newcomers. Just move on. If you miss the “good old days,” you can always start some new ones.

GroovyMag Plugin Corner: JavaScript Validation Plugin

2010-08-30T10:26:00.000-07:00

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

Grails provides powerful and easy-to-use constraint validation. With a few short lines in a simple DSL, you can ensure that required fields are filled in or that numeric field values are within a specified range. If you take advantage of Grails’ scaffolding, error reporting is also handled for you. The only catch is that it’s server-side only. If you want this type of validation without a round-trip to the server, you’re on your own — unless you use Peter Delahunty’s brand new JavaScript Validation plugin.

Peter released the Javascript Validation plugin earlier in March and then went right to work improving it. At the time of this writing it is at version 0.7 and is working quite well. Let’s see how easy it can be adding client side validation to our Grails applications. We’ll start by installing the plugin:


> grails install-plugin javascript-validation

We’ll need to make a couple changes to the views that we want validation on, but first let’s look at the domain class that we’ll be working with.



class Book {
   String title
   String author
   Integer pages
   static constraints = {
       title(blank:false)
       author(blank:false)
       pages(range:10..1000)                                                         
   }
}

This simple Book class (bet you never saw that in an article before) has three constraints. We will use the JavaScript Validation plugin to check those constraints without a trip to the server.

Open grails-app/views/book/create.gsp and take a look at the <g:form> declaration. It should look something like this:



<g:form action=”save” method=”post” >

The Validation plugin requires that our form contain a name attribute and an onSubmit attribute that calls the validateForm JavaScript function. So, let’s modify our form declaration to look more like this:



<g:form name=”bookCreate”

        onsubmit=”return validateForm(this);”

        action=”save” method=”post” >

Finally, we need to add the following line to the <head> section of our page:



<jv:generateValidation domain=”book” form=”bookCreate”/>

Here we’re just using the minimum required attributes for the <jv:generateValidation> tag. The domain attribute takes the domain class name, but with the first letter lowercase. The form attribute takes the same value that we assigned to the name attribute of our <g:form> tag. That’s all it takes to start using this plugin.

Now if we go to create a new Book and leave out the author’s name for some dumb reason, we’ll see something like the screenshot in Figure 1.

Not bad for a couple lines of code. That’s just the basics. The <jv:generateValidation> tag has ten more attributes that we can use to add more vigor and vim to our validations.

There is support for both domain classes and command objects. Errors can be displayed in a JavaScript alert (as shown in Figure 1), which is the default, or they can be shown in a list placed in a page element of our choosing, or we can even create custom error handling.

Currently only the following constraints are supported by the plugin:

blank

nullable

email

creditCard

matches

range

This list is considerably shorter than the list of constraints that Grails provides, but as we can see by the 6 updates since its creation a few weeks ago, this plugin is being actively enhanced, so I wouldn’t be surprised to see more constraints supported soon.

Oh, and lest I forget, the Javascript Validation plugin works with Grails internationalization. So with a minor tweak to our messages.properties file, we can customize our error messages as shown in Figure 2.

This plugin has great potential. It will already save significant development time in setting up client-side validation, and I’m sure it’s going to keep getting better. Stop by the Grails Plugin Portal and check it out. You can leave a comment with enhancement suggestions, or, if you’ve tried it out, let others know what you think with a rating. I’m giving it 5 stars!

Resources

Grails Plugin Portal page:
http://grails.org/plugin/javascript-validator

Peter Delahunty’s Blog:
http://blog.peterdelahunty.com

ÜberConf - Exceeding Expectations

2010-06-15T10:17:00.000-07:00

ÜberConf kicked off yesterday with the pre-conference iPhone/iPad workshop. The workshop was completely full, with just over 90 people. The view from the front of the room was pretty impressive -- all those glowing apples. ;-)

Later, the conference proper got going with a great dinner and a keynote by industry luminary Cliff Click. At the time when a normal No Fluff, Just Stuff event would wrap up for the day, there was an opening reception with more food and drinks and a roving magician. A great time was had by all.

This morning, the sessions are going in full swing. I'm actually skipping one right now to finish up my sample project for the Grails workshop tomorrow. But the rest of the week is packed with great technical sessions, and not a marketing person in sight!

I caught Keith Donald's Spring MVC session this morning and plan on making it to a session by Ted Neward this afternoon. The content choices are amazing. You've got Java Collections, Functional Java, Groovy, Grails, Wicket, Camel, Hadoop, NoSQL, Agile Architecture, JRuby, TDD, and on and on. In fact, it's hard to think of a buzz word in the Java ecosystem that isn't covered here.

And the attendees are the best part. I've met folks from all over the country and beyond. I even ran into members of CapJUG and the Gateway Groovy Users. Seeing so many old friends and meeting so many new ones is definitely the best part of a conference like this. And with the longer breaks, receptions, etc., you actually get time to visit with folks without missing the tech sessions.

With all due respect to the many great folks who make the pilgrimage to San Francisco every year, this is what JavaOne should have been.

Recording of Grails / Terracotta webinar

2010-05-12T03:34:00.000-07:00

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

2010-05-04T13:33:00.001-07:00

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

2010-04-26T17:09:00.000-07:00

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

2010-04-07T19:29:00.000-07:00

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

2010-03-27T10:33:00.000-07:00

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

2010-03-05T09:02:00.000-08:00

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

2010-02-09T07:05:00.000-08:00

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.

My Favorite Tool

2010-02-05T09:00:00.000-08:00

Years ago, I worked in construction, building houses. My favorite tool was my Estwing 28oz. waffle-headed framing hammer. I could drive a 16d nail in one hit with that hammer. (I also got carpal tunnel syndrome from using that hammer. But that's a different story.)

That hammer, because of its characteristics (its weight, its size, the pattern on its face, its textured grip, etc.), allowed me to do what I needed to do. Beyond that, it made it easier for me to do what I needed to do. No actually, that's not quite accurate.

The hammer didn't help me do what I needed to do. It helped me to do what I chose to do. In general, I chose to do what I needed to do, but the hammer played no part in that. I had a good boss on that job, and he helped me to determine what I needed to do. I also worked with some very experienced carpenters on that job, and they helped me to learn the right way to do what I needed to do. All the while, my trusty hammer was there just making things easier.

Not all of the tools I used were that way. My circular saw had a safety guard on it that made it difficult to see where I was cutting, and it got in the way when first starting a cut. It would then slide away as I went, but I would often hold it back out of the way when I was starting. The more experienced carpenters just removed their safety guards altogether. I'm sure there were accidents that the safety guards would have prevented, but I guess they were rare enough that most folks decided that the productivity gains were worth the risk. I was always amazed at how fast those guys could frame a house!

I used my saw because I needed to use it, and it was much faster than using a hand saw, but I don't look back at my saw with the same fondness as that hammer. In fact, I can't even remember what brand or model it was. There's just something about a tool that feels good to use: a tool that helps you do what you want to do, and then just stays out of your way.

Groovy and Grails in The Gateway City

2010-01-27T05:17:00.000-08:00

On January 5th, the Gateway Groovy Users had their 2010 kick-off meeting. The turn-out was amazing. When we were discussing the plans to get the group going again (after a 6 month hiatus), we thought we might be able to get our attendance numbers up to 10 or 12 (from the previous record of 7). We ended up with over 50 people! We even had such St. Louis Groovy icons as Jeff Brown and Ken Sipe.

We're hoping to keep that momentum going with our next meeting, on February 2nd. Seth Havermann will be giving a presentation on and demonstration of Groovy's SwingBuilder.

Then we'll turn it up a notch in March, with Alex Miller presenting on GPars (officially pronounced like “Jeepers”), the Groovy concurrency library. Perhaps we can get our sponsor to bring nachos.

As excited as I am about the response to the Gateway Groovy Users meetings, I am even more thrilled to see that this is not an isolated phenomenon. Groovy and Grails groups continue to pop up around the globe, and those that have been going for a while are reporting continued success.

One of the first Groovy user groups in the US, the Groovy Users of Minnesota (GUM – you gotta love that name!), provided the inspiration for the first US-based, community-driven Groovy conference: GR8 in the US, to be held April 16th, 2010 in Bloomington, Minnesota.

To find out about other Groovy, Grails, and Griffon user groups, or to help get one started, check out http://g2groups.net. The Groovy community continues to grow, to thrive, to amaze, and to inspire.

GroovyMag Plugin Corner: Feeds Plugin

2009-12-26T15:14:00.000-08:00

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.

RSS and Atom feeds are becoming more popular and consequently more important to include in our applications. The battle for mindshare among our users or potential users is constant, and having a feed available is one of our more effective weapons.

But feeds are complicated, right? There are so many different formats and versions and then there's all that XML- don't get me started on XML! Not to worry; some of the smart people at Sun came up with the ROME API that encapsulates and simplifies much of what goes into an RSS/Atom feed. So, all we have to do is learn a new Java API. NOT! This is Grails we're talking about. In steps Groovy Award winner Marc Palmer with the Feeds Plugin.

This plugin wraps the ROME API and gives us the very groovy FeedBuilder with its powerful yet simple DSL. Once installed, the Feeds Plugin gives us a new version of the familiar render() method. Now we can just “render" a feed instead of a view. Let's get started.

For our example, we are going to build a book of the month feed. We already have a Book domain class with corresponding controller and views.

First install the plugin:


grails install-plugin feeds

That was pretty painless. Now we will add a new action to our controller:


def monthly = {
 render(feedType:"atom"){
   title="Book of the Month"
   link="http://localhost:8080/bom/book/monthly/feed"
   description="A monthly book recommendation"
     def book = bookOfTheMonth() //complex algorithm here :)
     if(book){
       entry{
         title = book.title
         link="${g.createLink(action:''show'', id:book.id)}"
       }
     }
 }
}

The render() method now takes a feedType parameter. It is this parameter that tells the plugin that this is indeed a feed. If that parameter is there, we can also include a version parameter to specify the version of the feed format we are using. The defaults are 2.0 for RSS and 1.0 for Atom. Next the render() method takes a closure where we can set the various properties of our feed and entries. In our example we are setting the title, link, and description properties on our feed and then including one entry for the book of the month. Since the FeedBuilder DSL is still Groovy code, we can handle any logic that is needed. Here, for example, we are only creating an entry if our book is not null.

Next we create our entry. The entry node also takes a closure where we will set the various properties of the entry. All we are doing with our entry is giving it a title (the book's title) and a link to the show page for that book. Now if we run our application and subscribe to the feed at http://localhost:8080/bom/book/monthly we will get
something like this:

I know- kind of boring. Let's add another feed to our application that will give us a bit more to look at. Some of us are more voracious readers than others so we might want to have a list of books all at once rather than one each month. Here's a new controller action that will give us just that:


def booklist={
  render(feedType:"atom"){
    title="Groovy Books"
    link="http://localhost:8080/bom/book/booklist/feed"
    description="A listing of Groovy and Grails books"
      def books = Book.list()
      books.each{book ->
        entry(book.title){
          link="${g.createLink(action:''show'', id:book.id)}"
        }
      }
   }
}

Now if we subscribe to http://localhost:8080/bom/book/monthly we will get a bit more content from our feed:

There is a great deal more that can be done with the Feeds Plugin than what we demonstrated here, so when you're ready to dig deeper, the official documentation is at http://grails.org/plugin/feeds. You can also find lots of information on the ROME API at the java.net site: http://rome.dev.java.net. As always, another excellent source of information is the plugin source itself. The Feeds Plugin source can be found in plugins/feedsx.x/ Much of the meat of the plugin is in src/groovy/feedplugin/FeedBuilder.groovy.

Even without digging in to the docs or source, you can see how easy it is to add basic RSS/Atom feeds to your application with the Feeds plugin. Now you can set your mind to work on finding new and innovative ways to use them. Once again Grails and Grails plugins take away the drudgery and leave us with the fun!

Pomodoro Technique Illustrated - A Brief Review

2009-12-08T07:33:00.001-08:00

If you would like to be more productive and you haven't looked into the Pomodoro technique, you need to get a hold of the new Pragmatic Bookshelf book, Pomodoro Technique Illustrated, by Staffan Nöteberg.

I had heard about the Pomodoro technique, and knew it had something to do with a kitchen timer, but that was about the extent of my understanding of this powerful technique. Staffan Nöteberg not only shows us how we can become much more productive with the Pomodoro technique, but he also shows us just how much we can learn from a cucumber and an artichoke. (You'll just have to read the book to understand that one.) Staffan's writing style and illustrations make this book easy and fun to read, but it's the simplicity and the "why didn't I think of that" nature of the technique that really pulls you in.

We may have hours in a day to spend to accomplish a task, but it's nearly impossible (for some of us, entirely impossible) to spend that time focused on that task without distractions and interruptions. The Pomodoro technique takes that into account with the obvious (in hindsight) observation that though we may not be able to focus on one thing for a lengthy period, we probably can for a short one.

Using a timer to discipline ourselves to focus on one thing for a short time (typically 25 minutes, but you can start smaller) is a key component of the technique, but there's more to it than that. It is a whole system of capturing, prioritizing, tracking and accomplishing what we want to get done. All of this is done with the simplest of tools: a timer, a piece of paper, and a pencil.

It's kind of like breaking your work day into a series of 25 minute iterations, complete with a micro-retrospective after each one. Then a break - to clear your mind, check email, Twitter, Groovyblogs, etc. Then back to it again for another iteration.

Just like with a development process, you may get some benefit from using pieces of the technique, like the timer, but you'll get much more if you use the whole thing. This book is a great way to get started. Once you do, you'll want to give it some time to get into the habit. I'm still working on it myself, and I have already seen an improvement.

Pomodoro Technique Illustrated is now shipping. You can get your copy and get started at http://pragprog.com.

There goes the timer. Finished just in time!

GroovyMag Plugin Corner: Testing

2009-12-01T08:42:00.001-08:00

In the December 2008 issue of GroovyMag, I covered the Grails Testing plugin. This plugin provided the new Grails 1.1 testing features to 1.0.x applications. With that in mind, this may seem a bit out of date. But I happen to know that there are still some applications being developed in Grails 1.0.4, and the classes and methods described here, though built-into Grails 1.1 and above, are still applicable. So, just to be clear: If you are using Grails 1.1 or above, you can still use these classes / methods, but you don't have to install the plugin.

When writing unit tests, the goal is to test a single class in isolation, with any collaborating objects being replaced by mocks or stubs. This will lead to less fragile code that can work with different implementations of collaborating objects, and it will help to isolate bugs when they appear. Unit tests are also much faster to run, since they don’t require resource-intensive services and containers to be loaded. However, with all of the functionality that Grails magically adds to your domain classes, controllers, services, and taglibs, it can be quite difficult to write unit tests for these artifacts. It can be done, and I know several determined developers who have, but many others just take the easy (and slow) road and write only integration tests. Some take the dead-end road and write no tests at all. Integration tests test a class with its collaborators, which means that the Grails goodness is all there for you. These tests are important to have, but they should not take the place of unit tests. Another concern with integration tests as your only automated tests is that they take much longer to run, which means that they will likely be run less often.

Well, now there is no excuse not to write unit tests for your Grails applications. In this Plugin Corner we will see how the Testing plugin, by Peter Ledbrook, makes it plain easy to write unit tests for Grails artifacts (domain classes, controllers, services and taglibs). This plugin does for unit testing what GORM does for persistence. It provides mock implementations of almost all of the dynamic methods added to your artifacts by Grails. The plugin includes four new TestCase classes that all descend from GroovyTestCase, which itself extends from JUnit’s TestCase.

GrailsUnitTestCase introduces most of the powerful meta-programming magic in this plugin, and it will be sufficient for testing domain classes and services that use domain classes. For testing controllers and TagLibs you can probably guess which classes to use.

Let’s take a look at just how easy-to-use and powerful this plugin is. First we’ll install it:


grails install-plugin testing

Now to take advantage of the goodness this plugin gives us, we just need to have our unit tests extend one of the new TestCase classes. In the following example we’ll extend the ControllerUnitTestCase class.


class BookControllerTests extends grails.test.ControllerUnitTestCase{
  def b1, b2

  void setUp(){
    super.setUp()
    controller = new BookController()
    b1 = new Book(title:’Programming Groovy’, author:’Venkat Subramaniam’)
    b2 = new Book(title:’Grails in Action’, author:’Glen Smith’)
    mockDomain(Book, [b1, b2])
  }

ControllerUnitTestCase has a protected controller property. In our setup() method we set this property to a new instance of our BookController. Then we create a couple Book instances and call the uber cool mockDomain() method. This method takes a class (Book) and a list ([b1, b2]). Once this method has been called, we can call methods like list(), get(), save(), delete(), and even findAllByXXX(). The list becomes an in-memory database. In our example we passed two existing instances in the list. When we called mockDomain(), the object instances in the list were “saved” to the list. Alternatively, we could have passed in an empty list and added the instances by calling save(). In either case, the objects are assigned id values based on the order they are added. This is important, because most of the actions in a standard Grails controller use the id property to find objects.


  void testShow(){
    controller.params.id = 1
    def model = controller.show()
    assertEquals(b1, model.bookInstance)
  }

When we call our controller’s show action it will call Book.get(). This will be performed by the mock implementation of get() that was added to Book when we called mockDomain(), which will retrieve the instance from the list. I point this out because the Testing plugin makes working with domain classes so seamless that it sometimes feels like we’re still writing integration tests.


  void testBookNotFound(){
    controller.params.id = 3
    controller.show()
    assertEquals(“Book not found with id 3”, mockFlash.message)
  }

In our second test we set params.id to a number we know does not exist, to ensure that the proper error message is stored in the flash scope. Notice that what we check is not flash but mockFlash. mockFlash is a Map that is declared in the MVCUnitTestCase, the super class of the ControllerUnitTestCase. MVCUnitTestCase also introduces mockRequest, mockResponse, mockSession, and more.

A unit test for the scaffolded actions is of questionable value, so let’s try a unit test for a custom service. Our service method creates a batch of Publishers and Books from XML data. Here’s the test:


class BatchServiceTests extends GrailsUnitTestCase {
  def batchService
  def bookInstances = []
  def publisherInstances = []

  void setUp(){
    super.setUp()
    mockDomain(Book, bookInstances)
    mockDomain(Publisher, publisherInstances)
    batchService = new BatchService()
  }

This test class extends GrailsUnitTestCase because we need the domain class mocking, but we do not need the features introduced in MVCUnitTestCase or later. We are defining the lists that will be passed to mockDomain() ahead of time, since we are not creating any domain instances in our test. Notice also that we are mocking both the Publisher and the Book domains. This will enable us to mock the relationship logic as well. Finally we create an instance of the service that we are going to test.


  void testLoadBooks() {
    def data = “””
      <publishers>

        <publisher name=”Apress”>

          <book title=”Definitive Guide to Grails” author=”Graeme Rocher”/>

          <book title=”Beginning Groovy and Grails” author=”Christopher Judd”/>

        </publisher>

        <publisher name=”Manning”>

          <book title=”Groovy in Action” author=”Dierk Koenig”/>

        </publisher>

      </publishers>
    “””

    batchService.loadBooks(data)
    def p = Publisher.findByName(‘Apress’)
    assertEquals(2, p.books.size())
    assertEquals(“Groovy in Action”, Book.findByAuthor(“Dierk Koenig”).title)
  }

After calling our service’s loadBooks() we are able to call Publisher.findByName() to verify that the two books by Apress are there. We also verify that Dierk’s classic work is there by calling Book.findByAuthor(). These finder methods are not available in unit tests, but the Testing plugin is providing mock implementations of them using object instances held in lists.

Here’s a snippet of our BatchService.loadBooks() method:


  def loadBooks(String data) {
    def publishers = new XmlSlurper().parseText(data)
    publishers.publisher.each {pub ->
      def p = new Publisher(name:pub.@name.text())
      pub.book.each{book ->
        def b = new Book(title:book.@title.text(), author:book.@author.text())
        p.addToBooks(b)
      }
      p.save()

Notice how we are calling Publisher.addToBooks() to place the Book instances in the Publisher’s books collection and finally calling p.save(). These methods are also being mocked by the Testing plugin. Again it’s easy to forget that we’re writing unit tests and not integration tests, that is until we see how fast they run!

The documentation on the Testing plugin is pretty good, but still leaves some holes. If you want to take full advantage of the plugin I recommend reading through the source code that is included in your project once you install the plugin. It’s mostly Groovy code so, of course, it reads like a good novel. There are also some other resources on the web to help you get going.

With this plugin there is really no need to fear unit testing your Grails artifacts. So, if you’ve been writing integration tests instead of unit tests or if you are not writing any tests
at all, then run (don’t walk) to your nearest Grails project and install this plugin. You’ll be glad you did and so will your team mates, your manager, your customers, your spouse, your neighbors...

Resources
Official Plugin Documentation: http://grails.org/Testing+Plugin

Mike Hugo’s presentation to the Groovy Users of Minnesota: http://www.piragua.com/2008/11/12/testing-plugin-presentation

Robert Fletcher’s very helpful blog post:
http://stateyourbizness.blogspot.com/2008/08/unit-testing-controllers-with-testing.html

GroovyMag Plugin Corner: Searchable

2009-11-25T13:51:00.000-08:00

Over the next few months, I will be reprinting some of the Plugin Corners that I've written for GroovyMag. Hopefully this will give you a taste of what you can find in GroovyMag each month (and keep my blog from being so dead). Enjoy!

From November 2008 issue

One of the most powerful Grails plugins is also one of the easiest to use. The Searchable plugin brings the power of the Compass search engine into Grails in a very Groovy way. If you haven’t tried the Searchable plugin yet, it’s time to stop making excuses and stop wasting time building complex search forms for your projects. Let’s get started.

The first step to using any plugin is to install it. From the root of your Grails project execute the following command:


grails install-plugin searchable

Now the fun begins. To make a domain class searchable, just add the static searchable flag to the class. Here’s our Book class, for example:


class Book {
 static Searchable = true
 String title
 Integer pages
 Author author

 String toString(){title}
}

We’ve already generated the scaffolding for this class, so now let’s add a search action to our BookController like this:


def search = {
 def bookList = Book.search(params.
query).results
 render(view:’list’, model:[bookList:
bookList])
}

In order to call our new search action we will need a form, so we’ll add one to the generated list view. Put the following block of code right before the opening <table> tag in list.gsp:


<div class=”nav”>

<g:form name=”search” action=’search’>

  Search:

  <input type=”text” name=”query” value=”${query}”/>

  <input type=”submit” value=”Search”/>

</g:form>

</div>

Now if we run our application - with a little data thrown in via the bootstrap - we’ll get something like this:

We can now search for any string value across any of the properties of our Book instances from a single input field. We can search the String properties as well as the Integers. For example, if we had a book called “200 Reasons to Use Grails,” and we searched for the value 200, we would find
that book along with any books that had exactly 200 pages.

Although the default behavior is to search across all the properties, we can search a specific property by prefacing the search value with propertyName: (eg: author:Rocher).

I should point out that the code we have right now will blow up if the user doesn’t enter any search value before submitting the form. Don’t worry - this is easy to fix. The dynamic search method that is added to our Book class by the Searchable plugin returns an instance of the SearchResult class. This class contains a property called ‘results’, which is an ArrayList. This is why we can so easily return it in the model to our list view. So if there is no search value we can just call Book.list() and return that instead. Let’s modify our search action to look more like this:


def search = {
 def bookList
 if (params.query)
   bookList = Book.search(params.query).results
 else
   bookList = Book.list()
 render(view:’list’, model:[bookList:bookList])
}

We’re not using any additional parameters here, but the search() method takes all the same parameters that the list() method takes - which is important when it comes to sorting and pagination. In order to make pagination work with the Searchable plugin, we need to make a few simple changes. First we’ll need to pass a couple extra pieces of information to the view. The SearchResult returned by the search() method will be used to determine the total number of objects found, and the query parameter will be passed back to the view so that it can be reused when loading subsequent pages. So now our search action will look like this:


def search = {
 def bookList
 if (params.query){
   def searchResult = Book.search(params.query)
   bookList = searchResult.results
 }
 else
   bookList = Book.list()
 render(view:’list’, model:[bookList:bookList, searchResult:searchResult, query:params.query])
}

Now we will modify list.gsp, but since we are using the same view for both the list and search actions, we will put our changes within a g:if tag. If we are viewing search results we will modify the g:paginate tag to make use of the new values we passed in on the model. Otherwise, we will use the original g:paginate tag.


<g:if test=”${searchResult}”>

  <g:paginate total=”${searchResult.total}” params=”[query:query]” />

</g:if>

<g:else>

  <g:paginate total=”${Book.count()}”/>

</g:else>

In keeping with the Grails way, the Searchable plugin gives you sensible defaults for most settings but allows for much more customization if needed. To add this, just install the SearchableConfiguration.groovy file by executing the following command:


grails install-searchable-config

You can get more details about what you can do with this file as well as excellent documentation on the Searchable plugin page at grails.org (see references). Hopefully this tutorial will give you enough to get you going. Once you get started, more questions will undoubtedly arise, so I’ve included a list of references below.

The Searchable plugin makes including powerful full text searching so easy to do that there’s really no reason to not take advantage of it. So dig in and have fun!

References:
http://grails.org/Searchable+Plugin
http://www.grails.org/Searchable+Plugin+-+Configuration
http://www.grails.org/Searchable+Plugin+-+Searching
http://www.compass-project.org/
http://lucene.apache.org/

Slaying Hallway Zombies

2009-11-18T05:55:00.000-08:00

For the past few months, I have been working on a project for a division of Boeing. It was a bit of a culture shock, going from a small, dynamic, family feeling company like Contegix to one of the largest companies in the world. But it's a Grails project, and the prospect of helping all of those oppressed Boeing Java devs get into Grails is well worth the cross-cultural experience. :-)

So, what does that have to do with zombies? Well, when working for a huge company, one often ends up in a huge building. And in huge buildings, we often find very long hallways. The building I work in has hallways that are several hundred feet long (almost 150 meters). Something strange happens to (otherwise friendly) people when they walk down long hallways. They become hallway zombies. Hallway zombies aren't like other zombies — they aren't decaying (usually), and they don't try eat your brains. But if you’re not careful, they will rob your joy. There’s something unnatural about walking directly past another person and not even acknowledging that they exist. But if you don’t fight it, it will start to become natural to you. And then you will have become a hallway zombie yourself!

Hallway zombies can be defeated, though, and fortunately you don't even have to decapitate them. (How would that look on a reference letter?) Some hallway zombies can be defeated with a simple smile. Some may take repeated smiles. The first smiles may seem to bounce right off of them, but if you keep it up, you will start to break through. Others are tougher and may require more drastic action, such as a full round-house “Good morning!”

Those are the basic weapons for fighting hallway zombies — and fight you must, or your fate is sealed. But these weapons are much more effective with a good technique. If you spot a hallway zombie coming towards you a couple hundred feet away and you start smiling at them right away, they will be able to defend against it. It's best to catch them by surprise. Let them think you’re one of them. Look straight ahead, or down at the floor. (Don't be tempted to take furtive glances into open office doors or down a row of cubicles. That's a dead give-away.) Then, when you are within 15 to 20 feet of passing, strike quickly with your best smile and even a nod of the head. If you're pulling out the big guns, you can start a bit sooner, just in case you see an opening for a “How’s it going?” to follow up on your “Good morning!”

I’m not yet convinced that any hallway zombie is beyond reach, but there are a few here that are proving quite challenging. I’m working on some new attack strategies, just in case. On the other hand, there have been some successes that are quite encouraging. Slaying hallway zombies is hard work, but it’s very rewarding. So I keep fighting.

You may not work in this type of environment, but chances are that you will find yourself somewhere, at some point in time, where you are faced with a hallway zombie. Don’t panic. Steady your nerves, hold your ground, and… Smile!

Yet Another 2GX Wrap-up

2009-10-27T19:23:00.000-07:00

Finally after more than a year of waiting and nagging, the second 2GX conference was held in New Orleans last week. It was almost as good as the first one. Well, in some ways it was better but in other ways... well, we'll get to that in a bit. But first, I wanted to say how great it was to see so many people from the Groovy community. It is so cool to be able to put real faces to so many on-line friends. I know conference people always say that "the attendees are what really makes the conference great", but as a speaker and part-time staff member at this conference, I can say that it's really true. The questions during the sessions and the discussions between sessions and at meals were the best part of the whole thing. Even better than the Rod Johnson bobble-head dolls. :-)

Speaking of staff, I also want to tip my hat (if I had one) to the guys that pulled it all off. Jay Zimmerman did as good of a job with the 500+ person event as he does with the NoFluffJustStuff conferences and his two volunteers (and one sales guy :), and my co-workers, Erik Weibust, Todd Crone, and Paul Luttrell were tireless in their efforts to keep things running smoothly. It was great working with you guys!

One thing I want to highlight here was how excited I was to see some relative new comers speaking at 2GX. These guys aren't new to Groovy or Grails, but I think this was the first conference appearance for each of them and they were awesome! Matt Taylor, Hamlet D'arcy, Scott Vlaminck (the 'n' is silent), and Burt Beckwith (actually I'm not sure if Burt has spoken at other conferences, so forgive me if I'm wrong)

Matt spoke on Grails UI, the YUI based Grails plugin that he developed and maintains as well as his experiences using Grails "in the wild". I caught his GrailsUI talk and was very impressed, along with the rest of the room who all gave him the coveted "green cards".

I didn't catch any of Hamlet's sessions but from what I heard from other attendees and on Twitter, he was a hit! He gave four presentations altogether: OSGi and Groovy, Functional Groovy, Compiler Metaprogramming with AST transformations, and Legacy Code and Groovy. Rumor has it that he even had Venkat Subramaniam impressed.

Scott Vlaminck, from Refactr, gave talks on Metaprogramming in Groovy and Grails, and AOP in Grails. Again, I wasn't able to catch any of these talks in person, but the feedback was quite good and in fact I happened to be in the room next to one of Scott's talks and the speaker was almost drowned out by the applause!

Burt also gave four presentations. He spoke on Spring Security in Grails, GORM performance, UI performance, and Clustering Grails apps. I only caught the GORM performance talk, but it was one of my favorites. I am already putting things I learned there to use in my day job.

Of course the usual awesome Groovy/Grails/Griffon speakers were there and they were terrific as usual, but you've already heard about them and many others have or will blog about the cool Griffon sessions, or the Grails internals, or the power of Grails plugins, or the DSLs and Groovy testing magic, etc. So I wanted to take a moment to congratulate these guys on a job well done. I look forward to seeing them present at future events.

Now, as to why I don't think this 2GX was quite as good as the first one. The full name of the conference is a clue: SpringOne 2GX. SpringOne is a good conference, but 2GX is a great conference! (or a GR8 conference :) So, when combined we ended up with a more than good but not quite great conference. Spring technology is cool. Much of it (though not all) is behind some of the power of Grails. And I do very much appreciate the support that SpringSource is giving to Groovy and Grails, but I think they just gave a bit of a "corporate feel" to the conference.

I don't want to end on a downer though. There were some distinct benefits of having the two events combined. One was that SpringOne had some very good content and some exceptional speakers to add to the mix. Another is that more than a few Spring users got to glimpse the goodness of Groovy, Grails and Griffon for the first time. The oohs and ahhs were music to my ears! It serves as a reminder to just be patient and hang in there... it's only a matter of time until they'll be holding the Groovy, Grails, Griffon and Spring conference!

10 Reasons to attend SpringOne 2GX

2009-09-16T05:59:00.000-07:00

I was going to come up with one of those clever top 10 lists but when I went to the SpringOne/2GX home page, I saw 10 great reasons to attend staring me in the face.

The early bird discount ends Friday, September 18th, but even at full price this event is less expensive than JavaOne and will contain way more good technical content. Check out the rest of the speakers and the awesome session list at http://springone2gx.com

If you're interested in Groovy, Grails, Griffon, (or related technologies) or if you use Spring in any of it's myriad forms, or, for that matter, if you use Java, you won't want to miss this conference!

See you there!

New Blog for Grails: A Quick-Start Guide

2009-08-17T09:37:00.001-07:00

I'd like to announce a new blog for Grails: A Quick-Start Guide. You can find it at http://gquick.blogspot.com. In this blog, I'll continue to build on the example app in the book, and offer tips and techniques that didn't make it into the book.

The first post covers displaying an image property of a domain class in a GSP. In the GQuick example application, there is a Sponsor class that has a logo property. We never had a chance to show how to properly render that logo image to a page in the book.

If you've read the beta of GQuick and have anything else you would like to see discussed, post a comment here, on gquick.blogspot.com, or at the book forum at pragprog.com.

I'd also like to take this opportunity to thank the beta ebook readers. Your feedback has been a huge help!

Grails: The Official Web Framework for Java.next

2009-08-03T18:07:00.000-07:00

In the August issue of GroovyMag, guest plugin-corner columnist Keith Cochran covers the new Clojure plugin by Jeff Brown. This plugin allows you to include Clojure source code in src/clj and then access that code in your Grails application. More details on the Clojure plugin can be found at http://grails.org/plugin/clojure.

A while back Vaclav Pech came out with a similar Grails plugin for Scala. This one hasn't been covered in GroovyMag... yet. Anyhow, you can find out more about this plugin at http://grails.org/plugin/scala.

So now in a Grails application you can have Groovy code (all over the place), Scala code in src/scala, and Clojure code in src/clj. That's pretty impressive! As I was marveling at these recent developments, I realized that Grails now supports 3 out of the four languages covered in Stu Halloway's paradigm-shifting blog series on Java.next (Groovy, Scala and Clojure - no JRuby... yet).

So unless something else comes along that as easily supports all four, I think we can safely call Grails the "Official Web Framework for Java.next".

P.S. Lest I forget, Griffon (the official Swing MVC framework for Java.next?) has quickly followed suit on supporting these languages. See Andres Almiray's blog for juicy details.