A presentation for the London Groovy and Grails User Group about how Grails is being used at DMC digital. - the presentation will be available shortly at
A presentation for the London Groovy and Grails User Group about how Grails is being used at DMC digital. - the presentation will be available shortly at http://skillsmatter.com/podcast/java-jee/grails-at-dmc-digital-1351
Company wide, Groovy is our default
Quick debug views into Java with
Scripts for updating system
information, deploying static content
into Content Delivery Networks
Looking into JMX / other tasks
automation / integration
Groovy console to explore / debug new
Java or Web-based APIs for
Scripts to help manage multiple
databases - e.g. supplier wizard
Scripts to automate manual, tedious
tasks - e.g. SQL generation from
Internal Grails applications for
reporting and update routing data
One less language to remember
Lower automation barrier
Grape / @Grab makes scripts light and
Ship scripts to any system
“It’s like Java with a whole bunch of
good stuff added to it”
JVM warmup time to run scripts
Speed differences compared to raw
java or unix scripting
Betting on Grails
Been using it since Grails 0.3
Questions of Longevity?
Rails - can barely speak English,
don’t want to learn another language.
At that point, we had half a million
lines of code in Java. Too much of a
risk if I couldn’t understand it.
Only on greenfield projects.
Deciding on Grails
It was built on stuff I knew.
Desire to take away the pain.
There had to be a better way.
Started using Compass applications
Maurice took it upon himself to write
the Searchable plugin - but mostly on
Write once, use across multiple
Standing on the shoulder of giants.
Time to market is drastically
Allows us to compete with much larger
companies because we are more
Less formal & verbosity. Lightweight.
One person can have view of whole project.
Dealchecker ( Spring )
68,700 lines of XML config
550,000 lines of code
Cruiseline Fans ( Grails )
2,650 lines of XML config
22,600 lines of code
Working with Grails is enjoyable.
The platform is nimble and takes away
a lot of the pain in development.
Developers are happy. Staff
retention. Encourages professional
and personal development.
Set of conventions / structure.
Guides you through the process.
Dealchecker stood up in 5 years
because of Spring - it’s been good
because people always know whereto
Grails is the next step in that
The Grails Community
Plenty of good solutions.
You feel that people working on
Grails have been through the same
pain so many times. It feels that
they are a group of people getting
together to build a better platform.
Classic Grails philosophy - I want to
take the pain away.
In-place, internal plugins.
Can allows us to build functionality
specific to us, but then re-use it
across all our applications.
Relief of building non generic
internal plugins. Fills me with joy.
to Grails -
Converting 5 year’s worth of
development into the Grails stack
Spring Application with Sitemesh,
Hibernate, JSecurity, etc.
120 domain classes, 620 beans.
550,000 lines of code
Converting a Grails
project into Spring
Upgrade Spring application to latest
Resolve library dependencies.
Convert Jar files to plugins
Build top level web apps.
Make web layer customizations
Take a jar file used by the Spring project.
Generate a plugin ( grails create-plugin )
Set dependencies in BuildConfig
Copy mapping files into conf/hibernate
Copy bean definitions into conf/resource
Add bean mappings to applicationContext.xml
What could possibly
Moving from Spring 2.x to 3.0 is not
trivial. Some Grails bugs. Some Spring
bugs. They add up.
Things must be done the Grails way - e.g.
sitemesh integration, JSecurity.
Grails is much more strict in separating
Dependency Management Hell.
Things we hate
Upgrade cycles from hell
Grails Logging is a big wtf
IDE support needs to be better
Testing takes forever
Can make bad code worst
Feels like nobody can help you
Memory hungry beast
Stack traces are a million lines long
Things we love
“Grails makes you realize how
cumbersome and brittle it is to work
Testing / Code coverage -> so easy to
set up that you actually use it.
Rapid prototyping - I can build it!
Conventions. Forces you to use MVC.
One language you’re familiar with.