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

1. Groovy and Grails
at DMC Digital
Real world applications from a business
and development perspective
Andrew Bredon ( @bredo )
Tomas Lin ( @tomaslin )
London GGUG, April 2010

2. Who are we?

3. How do we use Groovy
and Grails?

4. Infrastructure

5. Portable scripting
Company wide, Groovy is our default
scripting language.
Quick debug views into Java with
Groovy.
Scripts for updating system
information, deploying static content
into Content Delivery Networks
Looking into JMX / other tasks

6. Operations

7. automation / integration
Groovy console to explore / debug new
Java or Web-based APIs for
integration.
Scripts to help manage multiple
databases - e.g. supplier wizard
Scripts to automate manual, tedious
tasks - e.g. SQL generation from
Excel files
Internal Grails applications for
reporting and update routing data

9. Benefits
One less language to remember
Lower automation barrier
Grape / @Grab makes scripts light and
portable
Ship scripts to any system
“It’s like Java with a whole bunch of
good stuff added to it”

10. Pain?
JVM warmup time to run scripts
Speed differences compared to raw
java or unix scripting

11. Using Grails for
Web Projects

12. 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.

13. Deciding on Grails
It was built on stuff I knew.
Desire to take away the pain.
There had to be a better way.

14. Weekend projects

15. Greenfield projects

19. Searchable plugin
Started using Compass applications
for Zipatrip.com.
Maurice took it upon himself to write
the Searchable plugin - but mostly on
his time.

20. Grails Projects
Write once, use across multiple
products
Standing on the shoulder of giants.
Time to market is drastically
reduced.
Allows us to compete with much larger
companies because we are more
efficient.

21. Grails Projects
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

22. Enjoying Development
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.

23. Working with
Conventions
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
find code.
Grails is the next step in that
structured evolution

24. 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.

25. Working with
outsourcers
We sat on Skype as if we’re working
on the same office.
Grails allows you to very quickly see
if they are on the right track.
Gives us more confidence working with
an outsource team.

26. Moving Dealchecker
to Grails
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.
Hiring Tomas.

28. Moving Dealchecker
to Grails -
developer’s
perspective

29. Moving Dealchecker
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

30. Architecture
Normal Dealchecker
Grails
App
grails spring

31. Plugins

32. Plugins

34. Converting a Grails
project into Spring
in practice

35. Steps
Upgrade Spring application to latest
Spring version.
Resolve library dependencies.
Convert Jar files to plugins
Build top level web apps.
Make web layer customizations

36. In practice
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
or resources.xml

37. What could possibly
go wrong?
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
project boundaries.
Dependency Management Hell.

38. Building projects
with Grails -
the verdict

39. 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

40. Things we love
“Grails makes you realize how
cumbersome and brittle it is to work
with Spring”
Testing / Code coverage -> so easy to
set up that you actually use it.
Reuse code.
Rapid prototyping - I can build it!
Conventions. Forces you to use MVC.
One language you’re familiar with.

41. Questions?