Glen Smith and Peter Ledbrook co-wrote "Grails in Action" (reviewed on Javalobby here), recently published by Manning.
An earlier DZone interview by Andres Almiray introduces you to Glen and how he got started with Grails and Groovy. Below follows a follow-up interview with Glen, covering some of the choices made while writing the book, some interesting things you may never have known about Grails, and a few tips and tricks to consider when writing your own technical books!
The book's site, http://www.manning.com/gsmith/, has several free downloads that should give a good idea of the book's style and content:
And now, on with the interview!
Hey Glen, congrats for having been part of the writing of a great book on Grails! How did you get you started writing it?
Thanks mate! Writing a book has been on my "by 35" list, and Grails presented the perfect opportunity. When Manning came knocking to see whether I was interested, I jumped at the chance! Graeme Rocher (Grails creator) suggested that I hook up with Peter Ledbrook (one of the core committers) to add an "internals" vibe to the book. The collaboration worked perfectly - we both have a similar pragmatic bent, and we both have (I'm told), a "charmingly lame" sense of humor. Thirteen months later -- the book was a reality!
One remarkable aspect of the book is how detailed it is and how it bubbles with tips & tricks. How did you get such an intimate understanding of so many different areas of this framework?
It was always our vision to write an "in the trenches" book. That phrase was part of my initial submission to Manning, and really resonated for us as the kind of book we wanted to present. Peter has done an amazing amount of work on the Grails mailing list, so he has a really good compass for the areas that people struggle with. I've also churned out a stack of production Grails apps, so I like to think that I have some feel for "need to know" vs "nice to know". I'm really glad that people are picking up the "real worldness" of both the book and the framework - it's really validating.
Would you say that Grails is suitable for all kinds of business-oriented web applications? Or are there certain kinds that are better suited for a different framework?
I can't imagine doing any sort of web development in anything else - the productivity gains are genuinely astounding. To my mind, the only reason to not use Grails for development is if the client has an existing commitment to an alternative framework that they need to preserve for other reasons. Even under those scenarios, I've still managed to introduce Grails into their mix.
One of the amazing benefits of Grails is that you can always drop down to the metal when you need to. Need to use some nasty custom Hibernate mapping files? Then you can. Need to wire in some custom Spring beans that you have existing Java code for? Go for it. Whilst there is rarely the need for it, the provision has been made for it. I've not yet found a limitation that stops me getting the work done.
Getting up and started with a Grails application is almost trivial. But how does it do after that phase, in your experience?
I think it's actually the second phase where Grails shines even more. The convention-over-configuration philosophy makes enhancing Grails apps a dream. You know where things live, how the app will be structured, etc. I think Maven brings the same strength to the build paradigm, but that's another story.
Grails makes it so painless to add new features to your app, that it become addictive. I think one of the biggest areas we need to grow (as a community) is to get a better handle on the testing space. It's so easy to add features, that we tend to get lazy on the testing front. It's not as fun, and, after all, you can test the feature in the browser right away, right? Getting a more disciplined mindset about testing those new features has to come, and it may take us a little while to get there. I'm excited to see what's happening with innovative testing frameworks like Spock (http://code.google.com/p/spock/). I'm really looking forward to new, easier testing paradigms coming along that take full advantage of Groovy's dynamic features.
One of the very few critiques I have of the book is that it doesn't cover Wicket as an alternative view technology to GSP pages. What do you think of the Wicket critique of JSP (and by extension GSP) in that so much code is mixed up in a file intended to be handled by designers, not coders?
Now that's a great question. I've never worked interactively with a designer, so I can't comment. I've had a bunch of CSS dumped on me a few times by designers, but I've never had one in-house that I can actually iterate with. That would be be quite a game changer. I'd be interested in others' experiences here.
Certainly Grails support for Sitemesh templates has got to help this problem, but I guess there's still some "developer" constructs (taglib calls, for instance) that would be forced on the designer. Perhaps this is a great opportunity for a plugin here? Something that works off HTML "id" tags directly to invoke Sitemesh under the covers. Would be very doable.
Time and again one sees Grails' plugin ecosystem cited as its main advantage, in the long run (i.e., beyond the start up stage), over competing frameworks. What are your thoughts on this?
I actually don't think that's true. Certainly there are hundreds of plugins out there (and many of them are huge timesavers), but I think that the framework itself is the real productivity booster. When I talk to Grails devs (even those just starting out), the real amazement comes from being able to add new features to their apps so quickly. The plugin support is just the icing on the cake! When IDE support becomes more mainstream, then we'll really be in the zone.
Have you created Grails plugins yourself? Can you say something about them and how the development process went?
Yes. The only one I've publicly released is the Jabber plugin (http://www.grails.org/plugin/jabber) used in Grails in Action. I learned to write a Grails plugin for the first time by reading Peter's chapter on plugins in Grails in Action, so I guess you could say I'm reading my own dogfood!
I found the experience fantastic, but I was following along step-by-step. The only snag came at deployment time, because I was working off a git repo rather than an svn one, but even that was surmountable (blogged up the process along the way here).
During the writing of the book, you must have learned a couple of things about Grails that you didn't know before. Can you name some of these things?
Gee. There are so many. One of the most interesting parts was around advanced GORM use cases. In particular, Grails is fantastic for mapping legacy databases... but there is a lot to learn! I took the nastiest legacy db I've worked with, and used it as the example for the book. I know people will appreciate the pain!
Some of the work around Internationalization (i18n) was very new to me (and interesting to explore). Same goes for the Quartz scheduling stuff - I've always wanted to know how to programmatically control jobs and work with persistent jobs. So all that is in there. In the UI space, I've been wanting to write up a strategy for skinning and menus for a while, so that was fun to work through and document.
For the most part, we wrote chapters based on our strengths, so a lot of the work was just codifying our experiences from the real-world into text that would make sense to others. It was certainly fun building a Twitter-style app for the examples!
As I said earlier, some of the biggest learning areas for me was actually from Peter's writing! The chapter on testing Grails artifacts with the new 1.1 testing framework (chapter 7) was a real eye opener, and I reference it all the time. You can get that chapter free from the Manning site, so everyone should go and read it right now (at http://www.manning.com/gsmith/ and click the "Sample chapter 7" link).
What are a couple of tips you'd give someone starting out writing a technical software book, as you have now done?
The biggest deal for me was "pedagogy". You need to spend a lot of time thinking about the logical way to introduce and teach material. My wife (a teacher) tells me that educators call this "scaffolding", where you give people examples that are "out of reach, but not out of sight" so they can stretch their thinking to get there. This is a lot harder than it sounds. A lot of technical books read more like a manual with each chapter disconnected from the previous.
Actually, the first 1/3 of the book was re-written completely three times to try and get this right. I reckon it was worth it! New readers have commented on the flow of the book numerous times, and I'm really glad people are finding it gentle and accessible. We had an outstanding development editor (Cynthia Kane), who would give us the tough love on this sort of stuff. Having a person like that on your team is just invaluable!
Peter has also written up a bunch of advice about writing a technical book on his blog here.
What are the projects you're currently working on and what's coming up on the horizon? More books, for example?
Are you kidding! My wife would kill me! I need to take a rest from writing and get back on the tools.
Of course, I have a bunch of stuff in the wings from the Grails side, but nothing far enough along to talk about right now. Follow along on Twitter (@glen_a_smith) or my blog (http://blogs.bytecode.com.au/glen) to get the latest buzz!
Thanks for the interview Glen!