DZone interviews: Marc Palmer on Grails
Long time Grails developers are well aware of who Marc Palmer is. Those that are new to the platform may have seen his name pop in constantly in the mailing lists, and with good reason: he has written more plugins than anyone else so far. Marc will tell us how he got started with Grails and more. Enjoy!
Andres Almiray: Could you please introduce yourself.
Marc Palmer: Hi, I’m a long-time Grails developer with a long background in Java development across web, desktop and mobile, and before that all those horrible things we try to forget; Delphi, C++, Pascal, C, 68000 assembly. I’ve been a freelancer since 1997 and love it.
I consult for various clients (yes I’ve got capacity currently - drop me a line!) and am currently paid to work part-time on Weceem CMS. I’m also founder of NoticeLocal.com, a pure Grails app startup.
I’m also the primary author of a bunch of plugins including the new grails-resources framework, cache-headers, email-confirmation, invitation-only, authentication, feeds, taxonomy, one-time-data... and more.
Andres: How did you get into Grails?
Marc: Back in 2005 I started developing the websites for a few PepsiCo UK juice brands, using my own “craptastic” framework gluing together Spring DI/MVC, WebMacro and Groovy. Groovy was such a breath of fresh air.
Graeme Rocher kept telling me to take a look at Grails when it was around version 0.3 and while initially confusing for me, I liked the ideas. I couldn’t use it for the PepsiCo sites at that time because our first roll-outs were well advanced, and there was a bunch of fundamental stuff that was still missing until about Grails 0.4/0.5.
I started some contributions to feature proposals on some of the boilerplate stuff - codecs, mail plugin, plugin framework and contribs to core like the Artefact API - yes that spelling is my Brit’s revenge for decades of having to type “color” - custom validators and stacktrace sanitizing.
The next year we moved all the sites and future ones to Grails and I have never looked back.
Any Java dev who does not completely fall in love with Groovy must be paid by the character rather than their skills. I get really excited by stuff that improves the user experience for developers - we’ve all suffered for too long!
Andres: You're quite the prolific plugin author. How do you keep up with all the updates and changes coming from new Grails releases?
Marc: I’ll be honest, I do struggle. It’s hard to keep up with the backlog on my existing plugins, let alone new stuff coming along and my new projects. My main sources of info are the grails mailing list, twitter, and chatting to other grails developers.
Luckily most of my plugins are relatively simple and not significantly affected by changes to Grails. This is really testament to the stability of the framework. Back when I wrote shareware components for Delphi/C++ Builder this became a real problem over time where you had to do so much work on new releases specifically for new framework/IDE versions - I got sick of it and gave up.
One notable exception is Functional-Test plugin which desperately needs some love since some tricky XML API dependency problems crept in with newer Grails builds. I just haven’t had the time/need to fix it yet.
Ultimately the best way to keep your code up to date is to respond to your users’ needs.
Andres: If I recall correctly the resources plugin will be merged eventually into Grails core. What’s the secret sauce that powers this plugin?
Marc: Well the ideas behind this plugin were formed a few years ago. I wasn’t happy with the web performance tools available because they seemed to be missing something and tied me into a given plugin’s implementation. I eventually worked out that this missing something was dependency information and extensibility of processing resources for minify/zip etc.
Part of the secret sauce is that we have a DSL to describe the resources you need, in modules. Modules can depend on other resource modules - including those provided by other Grails plugins. This means that coupled with Grails plugin transitive dependency resolution, you get some really smart stuff. Instead of including specific resources in your GSP pages or layouts, you now just say what modules you need using a tag. It works out the rest including the correct load order of the resources, and which resources should go in <head> and which should defer to the end of <body> etc.
Another part is that we process the resources at runtime instead of build time. This may sound a little counter-intuitive, but we only do this once at startup (except for when the resource is not declared explicitly). It adds a small bit of bloat to the WAR but the benefits are that your WAR still looks like your source tree did, and at runtime we can do all the smart processing stuff using the information from the DSLs - because we know at runtime how the link for a given resource has changed and to what. Oh, and we can also process undeclared resources - even resources not present at build time for apps that require it (think CMS... although Weceem does not yet work with this) within certain limits.
Its very exciting for me as the power is immense - it’s a really different take on including resources in HTML content. The plan is for this to be in Grails core in 1.4, but it remains to be seen if I can fit that in with my workload (sponsorship is welcome!). There are still a couple of tricky bugs to track down and some integration work to be done. I want to release a solid 1.0 of the framework for pre-Grails 1.4 apps to use, before it goes into 1.4 as a core plugin.
Andres: Please tell us more about Weceem. What motivated you to build it in the first place? What can we expect of it in the future?
Marc: Well Weceem is actually an application that originated at jCatalog AG, one of my clients. They had a rough prototype 0.1 release, and seeing the potential of Grails they wanted to take this further and open source it to give something back to the community - so they asked me to help out initially as consultant but then I became the sole developer which has been great fun
A core driver is that, in our view at least, most Java-based CMS were really too heavyweight and complicated to deploy and use - having a pure Grails solution simply rocks. Taking it step by step towards 1.0 has been a long process, but we’ve been focusing on the core feature set and 100% embeddability inside other Grails apps as a plugin.
You might not have thought it but this turns out to be a very popular use-case - you can build your own CMS or just CMS-enabled Grails app using Weceem in minutes. Release 1.0 is in RC stage now.
In the future, post-1.0, I’m really desperate to overhaul the admin UI completely - if you follow my tweets you know how much I hate bad UIs. Part of this will be updating all the example content to be nice and polished. I also have some plans for reusable fragments of the content graph, for some great new features.
It may seem odd to have yet another Java-based CMS, but what other CMS can you embed in your own Grails app and customize to your heart’s content? For simple apps you don’t even need your own Grails code, you can set up actions that run Groovy code right in the CMS.
Andres: What's your favorite Grails plugin?
Marc: That’s a tricky one. I have to say at the moment that it is the mongodb plugin. It is almost magical in the same way that Grails was when I first started. I have never wanted to waste much of my life learning the intricate details of any ORM - Grails was initially so attractive because it hid most of the Hibernate stuff that made me want to grab that rusty saw and start on my own leg rather than code J2EE the conventional (or hibernate) way.
Mongodb plugin does the same for mongo, and the amazing abstraction of GORM in the recent Grails releases makes this possible. With zero knowledge of Mongo DB I had a test app up and running in no time at all. Oh, and I can mix and match mongo and hibernate in the same app. Incredible.
Andres: What can you recommend to a developer that’s just about to start building his first plugin?
Marc: I would say take a good look at the best plugins out there to see how they work - and more importantly try to understand the Grails-y "attitude" behind it (see for example Taggable, Resources, Searchable or Cache-Headers). Plugins that just wrap something thinly are boring - a slight step sideways and coming at it from a convention and/or DSL based mindset will help you create something much more compelling. Don't think like you are in Java-land, think like you are in the new exciting Groovy-land. Push yourself to create something really new.
Andres: If you could go back in time and change a key decision in Grails' design, what would it be?
Marc: Well I would really have no right to do such a thing... but it always bugged me that the original hibernate-only GORM was so leaky an abstraction. It seemed so simple at first but then you find you are constantly referring back to Hibernate documentation to get non-trivial things done and discovering gotchas. I wish Grails had “owned” its ORM completely from the start - “ownership” of key technologies is so important. This is less of an issue now the GORM APIs have been abstracted but I’d still like to see a Groovy-targetted top-notch SQL ORM for Grails, but nobody has the appetite to write this, it would be very hard work.
I would also have liked to see a bit more abstraction away from Spring DI/MVC and Binding. Spring DI/MVC is great, but for many Grails apps it is overkill. Spring Binding just does not seem to work well for us in Grails - complex custom binding is really painful.
Andres: What’s the feature on the current Grails 1.4/2.0 roadmap that excites you the most?
Marc: This sounds dull but actually its the plugin usage tracking feature, something most people will not even see. I believe this is so critical to the health of the ecosystem. A lot of people disagree with me, but the mist obscuring any info about usage and quality of the plugin ecosystem has to be lifted. From usage information springs useful statistics that can begin to be used to provide information to developers about what is or isn’t a “good” or at least “well used” plugin.
Plugin authors are effectively marketing a product at no cost. This means you have to be able to connect with your users, and at the very least know how many there are to know if it is worthwhile doing it any more.
Furthermore, its impossible to build a commercial model around plugins when you have no information about the size of the market, and though many devs don’t like this thought... commercial options are necessary to maintain high quality product and customer service. An adaptation of an anti-Linux dig that a friend told me applies: “Open source is free if your time is worth nothing.“ As a lone developer you might be able to make one really high quality plugin in your spare time and maintain and support it for the next 5-10 years. If you want to do more than that outside of work-time, you will either die young, or die alone!
Understand that plugin usage tracking is not going to force people to pay for plugins or anything like that - but its a step towards providing the fundamental juice of economics: information.
Imagine if the Grails plugin ecosystem was full of great high quality plugins that add killer functionality to your apps, with polished and highly usable admin UIs, aggressively developed and maintained, and documented exquisitely with PDF and epub docs and screencasts.
Quality like this would grow the Grails community further, and the effect snowballs. You attract more developers because there is a viable model and growing community etc.
This level of quality is never going to happen unless we (the community) can create a commercial market of some kind. I’ve been doing shareware/open source for too long to ignore this - the truth is right there in front of me in my own neglected projects.
Oops I went a bit off-topic :)
Andres: Do you make use of other Groovy tools like Spock, Gradle or CodeNarc?
Marc: Sadly not yet - I just haven’t had enough time, though I surely will soon. All three of those are on my to-do list.
Andres: What would you like to see in a future release of the Groovy language?
Marc: I have to say there’s not much I wish for in Groovy, it is just fantastic - Guillaume, Jochen and the guys do a great job. Obviously everyone is keen to see more and more performance out of it, but one of the little things I would like is improvements to the Groovy JDK docs to make them integrate with regular Java JDK docs. Having to consult two different sets of docs for a given JDK class is a pain.
Actually while you’re asking, I think a complete revamp of the Groovy website and a dedicated domain would do wonders for the language. An online complete language-reference and MOP guide would really help people. I used to love those Borland language references with full detailed explanation of every language feature.
Andres: How do you keep in touch with Groovy news and community?
Marc: Again, the typical answer of groovy mailing list and Twitter. I also subscribe to GroovyMag and read it on the iPad (where else!). I do view Groovy through the lens of Grails however, like many people. This is perhaps a little unfair to the Groovy community, but ultimately its the frameworks that sell a “new” language. i.e. Most people learn a language because they’re going on holiday somewhere nice and it works better for everyone if you can communicate well.
Andres: What's on your reading table right now?
Marc: Oh... I’m not much of a reader because I spend all my time coding, being with my family, working in the garden or practicing drums! However on my iPad I am currently dipping in and out of “Geology - The Key Ideas” (working out why there are fossils up the hill from us, and why our garden is full of clay), “iPad Programming”, Apple’s “Objective-C Programming Language”.
Along with watching the WWDC videos showing a bunch of the key iOS technologies...
Andres: Any parting thoughts you may want to share?
Marc: Yes actually... the Grails community really needs people with great graphic design skills! I think all the “funky” people disappeared to Rails-land, and we’re left with a bunch of really smart Java developers who really suck at UI :) [<<<Note the smiley] ….OK, if I’m wrong community, please prove it to me! Grails and its plugins NEED YOU!
Thanks for listening.
Thank you Marc!