Jason Rudolph: second leg of the Grails race
Jason Rudolph: second leg of the Grails race
Join the DZone community and get the full member experience.Join For Free
Jason Rudolph has been into Grails since the early beginnings, he is the author of Getting Started with Grails, the first (free!) book on the framework. Jason also has extensive experience with Ruby and Rails, which puts him in a privileged position to explain Grails' sweet and sour spots. Enjoy!
[img_assist|nid=2173|title=|desc=|link=none|align=right|width=120|height=150]Q. Jason, you wrote "Getting started with Grails" in the early beginnings of Grails, how was it ?
A. Grails came onto the scene with a mission of simplifying Java-based web development, at a time when the rest of the Java ecosystem was busy piling on unnecessary complexity wherever possible. Here was a full-stack solution that wasn't reinventing the wheel, but was instead built on industry stalwarts like Spring and Hibernate. It took those proven components and layered a humane interface on top of them - an interface designed foremost for productivity and embracing the convention-over-configuration mantra popularized by Ruby on Rails. After having spent several years working with traditional Java-based web frameworks and bearing the pain of numerous persistence "solutions," I couldn't help but get excited about what Grails had to offer.
InfoQ approached me about writing the book right around the time Grails 0.2 was released, so I have to give kudos to them for seeing the early promise in the framework and taking a chance on the book. We knew the framework would continue to evolve fairly rapidly, but we wanted to help get the word out about Grails and give folks an easy and accessible resource for getting started with it. Writing the book was a great experience, especially since I was fortunate enough to have a fantastic team of reviewers, including Graeme Rocher (Grails Project Lead) and others, who kindly volunteered their time to the project. As enthusiastic as I was about the book, it's of course the community's opinion that ultimately determines whether the book is of any real value. And with almost 3,000 downloads in the first month and more than 10,000 downloads by autumn of last year, the response has been overwhelmingly positive.
Q. Now that Grails has reached 1.0, how do you see the framework ?
A. Grails has come a long way on its journey to 1.0, and it's exciting to look back and see how it has matured over the course of the past few years. When I look back at the first article I wrote about Grails (Hoisting Grails to Your Legacy DB), which involved assembling Hibernate XML mapping files to hook Grails up to an unconventional database schema, and I compare it to the way I'd solve that same problem today (using the pleasantly concise GORM DSL), the advances are truly remarkable. Tack on other recently-added features like content negotiation, improved REST support, and the ever-growing plugin community, and Grails is easily the most attractive choice in the land of Java web frameworks.
Q. GORM DSL ? tell us more!
Q. How did you get involved with Groovy ?
A. It was actually through Grails that I found my way to Groovy, and as Grails continues to gain ground, I suspect that many other developers will discover Groovy in a similar fashion. Of course, it's Groovy that makes much of the functionality in Grails possible. In the Ruby community, you'll often hear Stuart Halloway and Justin Gehtland remark that, "Rails is the gateway drug, Ruby is the addiction." I can't help but think that the same rule holds true for Grails and Groovy. Grails shows off so much of what is possible with Groovy, but the value of Groovy extends well beyond the web space.
In fact, as I was trying to drum up additional enthusiasm for automated testing on my last Java project, I saw Groovy as a way to show the team that testing didn't have to be painful. The core of this particular application didn't involve the web at all, but Groovy was still a great fit for testing the app. Groovy's literal syntax for common data structures makes it incredibly simple to prepare test inputs. Its literal syntax for regular expressions and its additional assertions (beyond the standard JUnit assertions) make it even easier to validate your code. And using a dynamic language in general makes for a much more pleasant testing experience, as opposed to having to jump through all the hoops that Java imposes in order to accomplish the same tasks.
Q. You also do Ruby/Rails development, how has it influenced your Groovy/Grails work ?
A. Given that we were just talking about the merits of testing with Groovy, it's funny that you should ask this question. The passion for testing in the Ruby community is downright infectious, and Rails makes Test-Driven Development (TDD) a breeze. For most tests, Rails can spin up a test instance and report the results of your test in just over a second. Couple that speed with stellar support for testing all of the core components of your app (e.g., models, controllers, etc.), and there's simply no excuse for anything less than 100% test coverage across your code base.
Having experienced the ease of testing in Rails, I naturally find myself wanting the same thing from Grails. And while Grails benefits from using Groovy for writing tests, that fact alone is not enough to put Grails testing on par with the testing support found in Rails. Unfortunately, testing in Grails remains rather burdensome at the moment, as evidenced most recently by Glen Smith's excellent public experiments dubbed "MockFor(March)." When you look at the amount of setup required to test a Grails controller, it's hard to imagine that anyone is really testing controllers at all, and the story isn't much better when it comes to testing Grails domain classes. That's a troubling thought, given that more and more Grails apps are now making their way into production.
Grails also has room to grow regarding the general speed at which it's able to run tests, though admittedly it has gotten significantly better in the past few releases. For comparison, I find that it typically takes roughly fives times as long to run a single Grails test as it takes to run the equivalent test in a Rails app. In the typical TDD pattern of running a test, tweaking your code, and running the test again, taking too long to run tests can seriously hinder your productivity.
In fairness, it's not all gloom and doom on the Grails testing front; there are a couple silver linings worth noting. First, Glen's posts are renewing the conversation about the state of testing in Grails. I see no Grails feature that deserves more attention than improving the testing infrastructure, and there is already at least one JIRA ticket that people can vote for to show their support for taking Grails testing to the next level. Second, in Grails 1.1, we should see support for "continuous testing," a feature that will hopefully mimic Ruby's popular autotest tool, which continuously watches for changes to your code and intelligently determines which tests it needs to run to verify your recent changes. Both of these improvements will go a long way toward improving the all-important aspect of testing in Grails.
So far we've been talking about Rails features that I miss in Grails, but there's at least one Rails feature that I'm actually glad hasn't yet made it's way into Grails. While some developers are hoping to see fixtures get added to Grails, much of the Rails community has already moved on, acknowledging that fixtures were a good idea in theory, but are actually full of problems in practice. Maintaining fixtures is a pain, they simply don't belong in unit tests (and many functional tests are better off without them as well), and they drastically slow down your test suite.
You asked how Ruby/Rails development has influenced my Groovy/Grails development, but it's important to note that the influence can actually flow both ways. Since Rails came along first, some folks might wrongly assume that Grails is strictly a Rails clone, but that's certainly not the case. Consider, for example, the fact that there's no equivalent to the Grails service layer in Rails. So, we (Relevance) wrote the Rails SimpleServices plugin to provide the same automatic transaction demarcation for our Rails apps and help us keep our controllers nice and lean as the application's business logic becomes more involved. SimpleServices is 100% inspired by Grails, and we've found real value in adapting that aspect of Grails to Rails.
The common theme among each of these comparisons is that these two communities have the opportunity to learn from the other. Rails and Grails obviously have much in common, and for that reason, we owe it to ourselves to observe the successes from each camp and learn from any missteps as well.
Q. So what about Groovy, is there a feature you'd like to see in the future ?
A. While there are certainly advances that I'd like to see in Groovy, most of those advances could likely come in the form of libraries (as opposed to changes to the language itself). At this point, it probably won't surprise you to learn that the two areas that I'm watching most closely in Groovy are both related to testing. I'm curious to see how various Behavior-Driven Development (BDD) solutions will evolve in the Groovy community, and Andy Glover's easyb library is certainly one to watch. Also, as more and more people start writing tests in Groovy, I suspect we'll see other options emerge in the mocking and stubbing space as well.
In many ways, Groovy 1.5 was such a landmark release that I'm still enjoying the impressive improvements that it introduced. Adding the joint Java / Groovy compiler effectively annihilated the biggest reason (and perhaps the only reason) not to use Groovy in your Java project, and even the smaller changes were welcome improvements. For example, while adding enums was one of the smaller enhancements in Groovy 1.5, it eliminated yet another reason that we occasionally had to revert to coding in Java. Now that enums (and miscellaneous other Java 5 features) have made their way into the mix, Groovy has most (if not all) of the features you'd want from Java. And of course, Groovy offers many others as well. Heck, Groovy devs certainly don't need to wait around for closures in Java 7; we're enjoying closures with well-integrated Groovy APIs today.
Jason Rudolph is a Principal at Relevance, a leading consultancy and training organization specializing in Ruby, Rails, Groovy, and Grails, and integrating them into enterprise environments. Jason has more than nine years of experience in developing software solutions for domestic and international clients of all sizes, including start-ups, Dow 30 companies, and government organizations.
Jason is the author of the highly-praised book, Getting Started with Grails, and speaks frequently at software conferences and user groups. Jason also contributes regularly to the open source community, both as an early committer to Grails, and also as a committer to the Streamlined framework and numerous other Ruby and Rails projects.
Jason holds a degree in Computer Science from the University of Virginia. He currently lives in Raleigh, NC with his wife (who can take a functional web app and make it actually look good) and his dog (who can outrun him, but is no match for squirrels).
Opinions expressed by DZone contributors are their own.