Grails at DMC Digital


Published on

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

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

  • Grails at DMC Digital

    1. 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. 2. Who are we?
    3. 3. How do we use Groovy and Grails?
    4. 4. Infrastructure
    5. 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. 6. Operations
    7. 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
    8. 8. 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”
    9. 9. Pain? JVM warmup time to run scripts Speed differences compared to raw java or unix scripting
    10. 10. Using Grails for Web Projects
    11. 11. 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.
    12. 12. Deciding on Grails It was built on stuff I knew. Desire to take away the pain. There had to be a better way.
    13. 13. Weekend projects
    14. 14. Greenfield projects
    15. 15. Searchable plugin Started using Compass applications for Maurice took it upon himself to write the Searchable plugin - but mostly on his time.
    16. 16. 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.
    17. 17. 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
    18. 18. 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.
    19. 19. 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
    20. 20. 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.
    21. 21. 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.
    22. 22. Moving Dealchecker to Grails - developer’s perspective
    23. 23. 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
    24. 24. Architecture Normal Dealchecker Grails App grails spring
    25. 25. Plugins
    26. 26. Plugins
    27. 27. Converting a Grails project into Spring in practice
    28. 28. 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
    29. 29. 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
    30. 30. 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.
    31. 31. Building projects with Grails - the verdict
    32. 32. 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
    33. 33. 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.
    34. 34. Questions?