Chad Small setup a survey to find out what people would like in a Groovy/Grails conference. If you have not taken it, go to the survey to get your voice heard. It will help us tremendously in planning.

Below are the results from just one day of having the survey available.
Summary:
• 32 responses
• Most from MN, but pretty broad response, a few international
• Time of week not obvious - Thursday - Sunday (time of week is least important)
• Minneapolis or Chicago for location - although probably just leans based on respondents location. Location not all that important.
• Speakers and content are most important to attendees, cost next.
• Dual track with and without hands-on workshops for format (although people aren't interested in paying more for the workshops)
• Comments: Open spaces, BoF, and lightning talks mentioned quite a bit.
• 63% likely to attend; 37% maybe attend

The night before I left for Copenhagen to attend the GR8 conference there (www.gr8conf.org), several members of my local GUG, Groovy Users of Minnesota (GUM), started to discuss holding a similar conference in the Midwest. All the speakers at GR8 stated to me that they'd be open to coming, depending on timing and other commitments. I also spoke with Søren Berg Glasius, the organizer of the Copenhagen conference. He suggested branding our conference with the GR8 name, something we seem to have decided to do.

The planning for this conference is in the earliest of stages. We are looking at late September or October dates. Likely it will be a two day conference, probably a Thursday and Friday event. We may add a third day if there is enough interest. I'll be reviewing a possible venue today. Next week I expect far more details and organization to occur. I'll continue to share details as they become available.

Being a fellow member of Groovy Users of Minnesota (GUM), I was keeping an eye on the publication of Grails Persistence with GORM and GSQL by Robert Fischer. Being that so much of Grails development revolves around domains, it seemed that a book on GORM would prove beneficial. This seems even more true now that GORM is a stand alone product. I highly recommend this book! When I first glanced through it, I thought I had wasted my time. After all, I had been coding in the Grails environment for several months and had dealt with many problems, most of which were due to an incomplete comprehension of GORM. I had spent a lot of time asking questions on the GUM mailing list and on Nabble. So, it seemed that I had a pretty good handle on GORM by the time it arrived. I read it anyway. Within the first thirty pages or so, I called a friend and told him he had to read it! While I knew much, there were many subtleties he explained and that was more true the further I went into the book. I am so enthused by this book that I recommended it to just about everyone I spoke with at GR8 in Copenhagen.

Okay, so no review is honest without some criticisms. I have a few, and all are minor.

My first criticism is that I felt a bit lost at times when trying to understand what was happening. I was trying to visualize the actual db tables, etc. Perhaps that was the wrong way to think about it, but I think understandable considering my datamodeling and sql background. It might've been nice to throw in a few code samples of the resulting table structures. I no longer remember where this seemed most appropriate.

A second criticism, and this probably is out of the author's control, is that there does not seem to be any accompanying source code distribution. At least I was unable to find it at the Apress site. At those points where I was a bit more confused, having the code available so I could start up my IDE and play around a bit sure would have been nice. It would save me from hours of tedious test case writing.

Anothor criticism, and this too could be out of the author's control, is that there is no index. Being that the cover states that Robert wants this book to be a go-to reference, I feel it is essential. Yes, the book is small, so relatively easy to find what you are looking for, but an index makes it even quicker (searching an electronic version would be even faster, so maybe this is my fault for purchasing the dead tree version). Your book will undoubtedly be heavily used as a reference by me regardless.

My final criticism is surely out of the author's control. I could have used the book much sooner. I've been able to purchase EAPs from Manning and get the dead-tree once published. The fee being no different than the price for the paper version only. I would've done that with this book if APress had that as an option.

Robert reply to my criticisms, sent in an email, follows.

All the criticisms are valid, and I agree with you 100%. APress has the option for an updated/expanded second edition, which I'm trying to push for and which would include an index, forum, source code distribution, and more content in general. Personally, I think I shafted the last two chapters pretty bad, plus I wanted to talk about plugins in the database arena: I was capped at 150 pages of core content, though, and I went right up to it (edits brought it down to 148).

The database tables I intentionally side-stepped for two reasons. The first is space, but the second is that different database engines produce different SQL, and so I felt like I'd have to share SQL from a variety of databases, which would add a lot of effort, a lot of length, and. If the expanded version comes out, do you think a version with only postgres SQL code would be acceptable?

When writing a tool
comments are cool
and todos are too
Aye

Today is the first day of the GR8 conference. It should prove exciting. Several top people speaking here: Graeme Rocher, Guillaume Laforge, Dierk König and Jim Shingler. I am really looking forward to the talks Designing your own Domain-Specific Languages, Grid Computing for Real-Time Computational Finance: A Case Study with Groovy and Grails and Groovy usage patterns.

More later.