Posts Tagged ‘grails’

Some Great Gr8 Conference Follow-up

Thursday, May 21st, 2009

There have been some great blog posts over at groovyblogs reporting on the sessions at this week’s Gr8 Conference, the Groovy/Grails/Griffon conference held in Denmark.

Among the standouts are an excellent write-up on what’s new in Groovy 1.6 and a summary of a session titled “Groovy Usage Patterns“, both by Peter Bell (the write-ups, not the sessions).

Peter also has a summary on “What’s Changed in Grails 1.1” with a notable section on standalone GORM (something I’ve not been able to get to work yet).

Conspicuously absent though, is significant coverage devoted to Griffon, which is unfortunate since I think this Swing/Grails-like framework has all of the right ideas.

Tags: , ,
Posted in Groovy | 2 Comments »

TDD: It’s Not Just For Zealots

Monday, March 16th, 2009

TDD (Test Driven Design/Development) is the practice of writing tests before writing the thing that will be tested. I’ve been simultaneously interested and suspicious of this way of writing software, trying to decide if the assumed rise in quality of the software could outweigh the dictatorial approach to writing tests (a testocracy)?

A convenient opportunity to try out TDD presented itself recently in the form of helping out on a Grails project. TDD’s autocratic approach to testing seemed like a good fit in this situation since, while I was no stranger to Groovy, this would be my first real foray into Grails.

In an effort to get up to speed in the application, and even Grails to some extent, I ended up writing 20 or so tests in the general area that I would need to be working in just to verify my assumptions of how the application was supposed to work.

When it came time to implement the feature, in true TDD fashion, I first asked myself, “how will I test this?” — that is, I wanted an exit strategy before I even started to think about how to implement the feature. In other words, how would I know when I was done?

So I wrote several more tests, and I was immediately confronted with the overzealousness of TDD: I had failing tests that would remain angry and contemptuous toward me until I implemented the feature sufficiently enough to get them to pass. But once that last test passed, I had a surprisingly satisfying feeling as I pushed away the keyboard and said to myself, “I guess I’m done”.

I have friends who practice TDD full time on a much larger project and it really seems to work for them. While I think TDD worked well for me in the situation, I still remain skeptical of it in larger settings — or for larger amounts of time.

My primary issue with TDD stems from my inability to think about two things at once: am I writing tests, or am I writing software? If I’m constantly thinking “how would I test this?” then I’m not thinking about what I’m even supposed to be doing. Often I need to burst out and write some code, try some experiments, refactor it, experiment some more, throw it away and start again, etc.

It’s not uncommon, during this process, to realize that the tests are now wrong or otherwise obsolete, and now I have to make the internal context switch to nurse them back to health, breaking the flow of what I was otherwise doing.

It makes more sense, I think, as a general rule of development, to test after things have stabilized.

I imagine tests being all these little yipping puppies nipping at the cuff of my pants when I’m trying to walk. Sure they’re cute and all, but sometimes I just want to walk at a brisk pace and these damn puppies are getting in my way!

Tags: ,
Posted in Groovy | 2 Comments »

Why I Like Grails

Thursday, February 19th, 2009

I’ve always been a fan of glass mugs. In addition to being able to see what I’m drinking, I prefer their smooth feel to that of standard ceramic. Recently however, a friend turned me onto grails. On the surface, it would seem that grails are a throwback from an era long past, but there is something to be said about drinking from the satisfying heft of a jewel encrusted grail made of bronze that helps me get in touch with my northern Germanic roots.

I especially like drinking out of grails when working with the Groovy web framework, Grails (no relation). As a side note, here are a few reasons I like Grails (the web framework):

I get to work with Groovy all day

I had been working with Groovy for about a year before coming to Grails (that is, the web framework — I was still drinking out of glass mugs at the time) in the context of a Java desktop application. There was a lot of “split brain” development with about 30% Groovy and the rest Java. It was always a painful context switch back to Java from Groovy, consoled only by the IDE’s superior compiler support (”There, there, look on the bright side: I can look up your methods for you again. By the way, you need to catch this exception and you forgot your semis).

Grails is 100% Groovy though — config files and all. In fact, I wish they would have taken this further with the gsp syntax, but I guess you’re not really web programming unless you have those god forsaken tags somewhere in your application.

It hides scary things from me

I’ve been actively avoiding using Spring in projects due to sheer intimidation, which can be summed up in the following exchange:

Coworker: Are you using Spring on your project?
me: You mean the Dependency Injection framework? We’re just using Google Guice–
Coworker: Oh but Spring is so much more than that — it also handles security and transaction control, and aspects, and it has a small island off the coast of Haiti, and it’s currency is the Spring Buck, and on clear nights if you quiet your mind, you can hear its song…

I’m told that Grails uses Spring behind the scenes, but I don’t have to know about it, which is the way it should be.

Testing is very easy less hard

There is this tension with regard to testing out there where on the one hand there is the Public Face of Software Engineering, which includes every software book I’ve ever read or speaker I’ve ever listened to, that says that testing is very important and that you should unit test all your code.

Then on the other hand there is my primary experience of the dozen or so projects that I’ve been a part of over the last decade plus in which testing was always (at best) an afterthought, and even when we did set out with the best intentions, with our TDD hats on, a project always degenerates to the point where if we achieved 30% coverage we were feeling pretty smug about ourselves.

So the short of it is: regardless of what they tell you, testing is hard.

With Grails though, testing is…less hard. Tests are auto generated, and neatly stubbed out in their “unit” vs “integration” buckets just begging for some love. The great thing though is that, unlike my previous experience with writing tests, I don’t have to pretend that I’m not using a real database, or making a real HttpRequest. All that stuff is mocked out, which I realize you can do for any type of system, but the true gem is that I don’t have to set it up.

The testing is actually so effortless, that it actually encourages me to think about better design in that I will gladly refactor, say controller logic out into a service if it means a cleaner test.

I should also say at this point that while I’ve been drinking out of grails for a few months now, I’ve only been on a Grails project for a week, so these initial impressions may seem naive to the seasoned veteran. Nevertheless, I give grails a thumbs up — just avoid the ones lined with lead.

Tags: ,
Posted in Groovy | 1 Comment »