Refactr Intrview Series: Marc Palmer

Post by Ben Edwards

This post is the first in a series of interviews of people we find interesting that we will post here on Refactr. We asked some questions of British software consultant, Marc Palmer, regarding his experiences working for Enotions Ltd. on range of Pepsico UK owned brands using Groovy and Grails. You can read his weblog at http://www.anyware.co.uk. UPDATE: Leer esta entrevista en español

REFACTR: You left school early (at 16) to start programming, how do you think that has made you a better professional? How has it hindered you (if at all)?

MARC PALMER: I left at 16 because I was desperate to get out of school. I found it very boring and was eager to work (with computers) as I had been programming since I was 11, and I was writing 68000 assembly language ATARI ST demos and dealing with hardware interrupts etc by night while going to school and being taught BASIC.

In terms of being a better professional, I think the advantage is simply about 5 years more commercial experience than other people my age who went through further education and to university. It enabled me to become a freelance contractor in my early 20s.

It may have hindered me occasionally in that many companies use “Must have computer science degree” as a silly filter on applicants for work, but I’ve had little time without work in the last 10+ years. I have always been a self-teacher and always try to do things better. You could say I’m a bit of a perfectionist ;-)

R: How did you get involved with Grails development and why?

MP: Early in 2006 I started on some of the Pepsico UK juice brand websites, using my own Spring and Groovy framework. It was quick and clean, but once I had time later in the year to try Grails properly, I was immediately sold – especially because of GORM. However at the time it lacked some things that would make development even easier, so I decided to get involved and contribute some small things in order to increase my understanding of it so that we could deploy sites with it eventually, which happened in Jan 2007.

R: You are giving a talk titled “Grails in the Real World” at Grails eXchange 2007. Can you give us a preview of what that talk will include?

MP: It will be quite high-level, talking about some of the five high profile branded sites we’ve done with Grails this year. It will cover some Grails basics as well as some practical tips and simple design choices employed when building some of the more interesting features of the sites. It’s not going to be a “let’s code this app before your eyes” kind of talk, there will be plenty of those I’m sure! I think what people really want to hear from me at the moment relates to our experience of commercially deploying Grails applications.

R: What do all the Groovy/Grails folks on this side of the pond not know about what is going on over in the UK and other parts of Europe?

MP: Well I’m a bit of a recluse to be honest; with work, Grails dev, working on our house and garden, and being with my wife and two daughters – I don’t get much time to be part of the “scene”. It seems like Groovy is getting some good coverage in Germany, no doubt due to the great work of Dierk Koenig and Sven Haiges. Over here in the UK generally I think people are rather slow to catch on, businesses are generally very conservative. The biggest thing I think people may not realise is how much work Graeme (Rocher) puts in to Grails and Groovy dev. The guy’s a coding demon.

R: What new language features would you like to see from Groovy?

MP: At the moment, nothing special in terms of features. Truly lazy valuated GStrings would be nice for making logging more elegant (no if (log.traceEnabled) …” needed).

What I do want from Groovy is high code coverage in regression tests, and stellar documentation. Far too much Groovy detail is stuck in developers’ heads. I want a definitive language reference, not a bunch of cobbled together wiki pages! Back in the day when I was teaching myself Pascal, “Oh! Pascal” was a bit like the “Groovy In Action” for Pascal – but it was the Borland Turbo/Object Pascal manuals with their detailed grammar diagrams and truly excellent writing that had me using every feature of the language and understanding every “corner case”.

I love Groovy, but at times I feel it is a murky catacomb of “corner cases”, and sometimes the principle of least surprise is violated and a monster jumps out and makes you sh*t yourself! Things are getting better, but Groovy is under-resourced. Someone needs to invest in a salary for a single experienced author to co-ordinate and write definitive documentation for the language. Wikis are fine but they are a cop-out – it’s what you do when you can’t be bothered / don’t have time to write documentation yourself.

R: What have your experiences with large Grails projects like PepsiCo and Tropicana shown you in terms of both the difficulties and successes of using the technology on large scale projects?

MP: Difficulties… well we were bleeding edge for a while circa Grails 0.4 and there were some painful moments, which meant the primary difficulty was convincing “Mr.Boss Man” that we were doing the right thing. Performance of GSPs was a concern for a while, but then Graeme and I did some profiling and made some good in-roads there, although there is more we can do in future. Some of our form handling requiredsome Grails improvements and some crafty coding. The few multi-page forms we have were a bit painful because flows weren’t implemented when we did the work.

In success terms… well we had 2 sites launched by early Feb after starting from scratch, with just me and an HTML dev working on the code. By June we had five Grails sites deployed, all gradually upgraded from Grails 0.4 to 0.5 to 0.5.6 smoothly. We were able to add new features easily including a blog, weather feed, “no frills” CMS for specific content elements, admin reporting on data stored by the sites (criteria builder rocks!), drawing of competition winners, high score tracking, e-cards and more. We often have hard dates to work to, where a feature has to be live to tie in with promotion or a new product launch, and we didn’t miss anything.

Seb – our HTML/PHP developer – loves Grails and GSPs/layouts. We now prototype rapidly, locally and reproducibly thanks to Grails’ built in web server, we can check out the whole app from SVN onto another server for the testing/QA department and it “just works”. It’s really helped improve our working methods.

R: In the past few years, a number of Java developers have taken to Ruby on Rails. Do you think as Grails matures, more of those developers will switch to Grails? Said differently, what does Grails need to do to win those folks back?

MP: Grails momentum is building. Moving to Rails is even more of a leap of faith than moving to Grails, so I think as awareness of Grails grows it will stop any hemorrhaging of Java people to Rails. In terms of luring people back… I think they may return by themselves when they realise all their favourite APIs are instantly accessible, and that they can get the tools and scalability that they were used to with Java, but without any of the pain.

We just need to keep driving up Grails’ profile.

R: With Grails 1.0 coming out soon, there’s an expectation that Grails adoption will grow rapidly because of the perception of increased maturity of the technology. What are your thoughts? What is getting you the most excited about Grails these days?

MP: Yes, I agree 1.0 is crucial. It is mainly psychological but 0.6 sounds so… lame compared to 1.0. Its also our guarantee that we won’t break stuff any more. That’s the killer for many people – with our five sites I didn’t really relish upgrading each one through the various Grails builds, even though each one was a great improvement. It’s OK with your own toy projects but when the customer is paying for your time and you have deadlines, upgrading to a new version of your framework is unattractive at best.

The most exciting thing for me about Grails is that its all coming together now. All the main pieces I’ve wanted to see are coming in – flows, rationalized config, ORM caching and mapping control, plugins, better documentation. We’re cleaning it all up and sanding off the rough edges so that it’s not just a productivity boost, it feels coherent and designed. The difference between a white-box PC and an iMac.

Oh, and there’s the future plans we have for some great plugins and other stuff in the pipeline…

R: Jumping feet-first into helping out with the Grails project may seem daunting to some. What’s the best way for people to get involved if they want to help?

MP: Yes, I was daunted at first. The best way to get involved I think is to check out the developer docs on the website which give a bit of an overview, then pick a simple looking issue from Jira and dive in to where you think it will be in the code – and ask on the dev list for the starting point. I found it very hard at first because, while IoC is a good thing, I find it can make applications very hard to fathom because its often not clear where your entry point is, what order things occur in and so on. To be honest there’s still some bits that make me scratch my head, and I don’t have time to fully investigate them at the moment – the flow of execution during GSP compile and rendering for example.

The great thing about Grails is that most of the core functionality has very good code coverage for tests. So as long as you run all tests successfully before committing, you can feel pretty sure that you haven’t broken anything. This is unit testing at its best because you can go in and work on little bits without worrying too much about breaking other things. Nothing more embarrassing than causing the continuous integration to spew a “Build Failed” message citing your commit! I should know, I’ve done it a few times.

If all your tests passed and it still broke something, make sure you write the unit test to prove this failure locally BEFORE you fix the bug! We love unit tests. The more the better. A project of this complexity would fall apart quite quickly without them.

R: Do you have any expectations/hopes/predictions for Grails development in 2008 other than what’s specifically on the roadmap (e.g. new features, etc)?

MP: I think that 2008 will be see rapid adoption, and with that primarily bug and compatibility fixes and performance improvements to 1.0′s core, and probably one or two point releases with new features.

Alongside I’m hoping for an explosion in high-quality plug-in development. Once you can drop in a blog, forum and authorization plug-in to your application and have it just fire up and work, for many users of Grails this will be killer. It will also open it up more to the non-Enterprise crowd. I am a firm believer, as this is where I sit currently, that Grails is brilliant for building web sites, not just web apps.

About Ben Edwards

Designer of information and interactions; contributes as much with enthusiasm and drive as anything else; generalist; can migrate easily between discussions of databases, use cases, and Photoshop techniques; avid blogger (from the days when it didn't have a name); critic of bad design; organized and presented at the minnebar (un)conference in Minneapolis; married, no children, dog; loves travel. alttext.com, minnestar.org, @alttext
This entry was posted in Software Development and tagged , , , , , , . Bookmark the permalink.

Related Posts:

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>