Technologies we are using

My current project has given my team a great opportunity to use some newer web technologies. Prior to starting this project there were several things I had been looking at for a while and was interested in using. So, I’m going to list all the technologies we are using in this post and say a little about them. Then I’ll follow that up with a post about each one, and some details on what we are doing with them and things I’ve learned. These are in the order that we decided on using them.

Mercurial

In previous jobs I’ve use PVCS, ClearCase, CVS, and Subversion. I don’t really have anything to say about PVCS, except that I was glad when we quit using it. ClearCase was too heavy handed, and a pain to deal with. CVS works well, but has some major performance issues and is missing a lot of nice features of more modern VCS systems. Subversion does fix some of the issues with CVS, but every project I’ve worked on with Subversion, everyone ran into major issues when trying to merge code. Add to that some other oddities we ran into with Subversion, and I wasn’t very happy with it either.

I’d read a decent amount about the new distributed version control systems like Git and Mercurial. Although I never really understood why people liked them so much. I didn’t really get it until I read the first chapter of the Mercurial guide about distributed version control. I ended up deciding to go with Mercurial. The main reason I went with it over Git was the Eclipse plugin for Mercurial seemed a lot better. Git seems to be too tied to the command line. Not that I hate the command line, some times I use it with Mercurial, but I like good IDE integration with a VCS.

Gradle

I used Maven 2 back when it hadn’t been out very long. It was really cool how quickly you could get a build up and running with it. However, my team at the time had a bad experience with it. It cost me a few days of work a couple times, fixing weird build errors caused by plugins that got automatically updated. All those things that Maven just does for you can be a real headache when they aren’t working right. In the end, the issues we kept having with Maven lead us to switch to Ant and Ivy.

So, for the last four years or so I’ve been using Ant for builds and Ivy for dependency management. Ant is great because you can literally do anything with it, and I really like the way Ivy does dependency management. But it can take a lot of work just to get a build working. And all the XML can be a pain. GANT is a nice solution to the XML, but it still takes a lot of effort to get the build running.

A while ago I came across a new build tool called Gradle. It uses Groovy for writing the build instead of XML, so adding a bit of logic to your build is simple and straightforward. It also uses some of the build by convention concepts that Maven has, so getting a simple build running is a snap. It also has tight integration with Ant, so calling ant tasks is simple. It uses Ivy under the covers for dependency management, too. All in all, it looked like a nice option, so we decided to try it out.

GWT

I’ve kept track of GWT since it first came out. I’ve played around with it a few times, but never really got a chance to build anything with it. I really like the idea behind GWT. It’s not that I dislike JavaScript, I like it just fine, and jQuery is fun to work with. But I can’t really imagine building the entire front end of a rich internet application using JavaScript. It’s just too hard to test and debug, in my opinion. And I don’t really want to develop for Flash or Silverlight. So that leaves GWT. Which, to me is a great option.

Grails

I’ve done a couple small projects with Grails, and been pretty impressed. You can really get things done quickly with it. It takes some getting used to, and doing TDD feels different than Java. But once you get the hang of it, it’s a nice environment to develop in. We looked at a couple different options for the backend of our system, but decided Grails would be the best choice.

SOFEA

With the back end and front end in place, there was still a decision to make about how they would communicate with each other. A friend of mine told me I should read about SOFEA. It stands for Service-Oriented Front-End Architecture. The concept is that the front end is completely client side and controls the flow of the application. The back end is simply a bunch of stateless services that the front end calls.

Matt Raible is really big on this right now. He’s been using this architecture with GWT as the front end and Grails as the back end. We liked the idea of a clean separation between the front and back end that SOFEA presented, and had already decided to go with GWT and Grails. So it seemed natural to go with SOFEA also.

Easyb

The last thing we decided to use was Easyb. We were definitely going to be doing TDD, but we liked the concepts that the BDD style had. Although you can do BDD in jUnit, it doesn’t really feel all that natural of a thing to do, and it’s really easy to fall back into some bad testing habits. I was hoping there was a better solution out there.

I looked at JDave, but felt like it looked too verbose. I had heard of Easyb before, but never really looked at it. Once I checked it out I found that I really liked it. It uses Groovy instead of Java. Which adds some flexibility, and since we are using Groovy with Grails, it wasn’t another language to learn.

I found writing Easyb specifications is pretty similar to how I was doing TDD in jUnit, just nicer. I still use Mockito for mocking, and my tests are structured very similar to how they were before. They are just easier to read, and you aren’t tempted to fall back into the non BDD tests like you can be with jUnit. Also, Easyb has a nice HTML report that it outputs as part of our build. It’s a great tool! Well worth a look, if you haven’t seen it before.

Well, that’s it. That’s a lot of new stuff, but I think it’s already coming together pretty nicely. As I said at the beginning, I will be blogging about each of these technologies in the coming weeks. Until next time…