Saturday, October 23, 2010

JavaOne Has Been Replaced

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.

Saturday, October 9, 2010

Move On In Peace

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.

Monday, August 30, 2010

GroovyMag Plugin Corner: JavaScript Validation Plugin

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

Tuesday, June 15, 2010

ÜberConf - Exceeding Expectations

Ü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.

Wednesday, May 12, 2010

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.

Tuesday, May 4, 2010

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.

Monday, April 26, 2010

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

Wednesday, April 7, 2010

Ü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!

Saturday, March 27, 2010

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/

Friday, March 5, 2010

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/

Tuesday, February 9, 2010

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.

Friday, February 5, 2010

My Favorite Tool

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.

Wednesday, January 27, 2010

Groovy and Grails in The Gateway City

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.