On a whim I setup a Google App Engine account and an hour later I had the hello world Groovy example up and running. They recently added a Java option to the current Python stack. I pulled a quick tutorial from Guillaume Laforge on launching a Groovy web app. A few downloads and a bit of configuration and the app was deployed. Pretty impressive, especially for a free place to do Groovy deploys. The real fun will come when you can just dump Grails apps directly up there.
Spinning up on Groovy on Grails I pulled down the new 1.1 release. Started up a quick new project in my IDE. Change out my local GRAILS_HOME environment variable and it’s off to the races. After a number of strange errors I realized the IDE wasn’t quite updated to the 1.1 changes. I knew TextMate had Grails and Groovy support. It’s my default editor for Ruby so why not Groovy. It did take a minute to realize the svn repository for TextMate bundles had moved from:
An open TextMate window, a terminal session and a pretty minimized browser and I can fit everything in a single 17″ window on my MacBook Pro. So far no issues and time spent messing with the IDE. Simplicity is inviting.
Running through a recent code review on an outsourced internal project I came across a new issue. The developers have built a few SharePoint Web Parts in using ASP.NET. I gently asked where the unit tests where since I’d dug around in source code and not seen any.
The developers looked a little surprised and sort of thought I was talking about manual unit testing, but I reiterated that I meant NUnit or MSTest unit tests. There was a short discussion. What followed was they couldn’t see how they could unit test the Page Behind code. This is an unfortunate old story.
Testing controllers in most web frameworks is painful. The classic example is Struts Action classes where you can use StrutsTestCase, but the solution isn’t elegant. JSF was an even worse experience, especially the 1.0 spec. Lately messing around with Grails has made it a bit easier, but I still find it to test the controllers through a front end functional test like Selenium. Of course in Rails it’s fairly trivial.
I’ve followed some agile bloggers in the MS world for some time and I knew this problem existed in the ASP.NET world. I knew a lot of them advocated a model-view-presenter (MVP) design to allow for easy unit testing. I assumed with Microsoft MVC out now that this problem is solved. It appears to be a much better story, but currently Microsoft MVC doesn’t integrate directly with Sharepoint.
The next step was to find a specific library. It turns out there is one much like StrutsTestCase or other libraries that make it easier to test web controllers. NUnitAsp to the rescue, coded by no less than James Shore. Then I read the note on the front page from about a year ago:
— James Shore’s note on NUnitASP Development
So much for a silver bullet. Ever the optimist I had hoped for something like this:
- Quickly find a nice explanatory tutorial and send the developers the link.
- Answer a few questions as they experimented with their first tests.
- Hook up the project to a continuous integration server and start running the tests.
- Next code review we talk about the adoption of an MVP approach.
Looks like this is going to require some more work.
As a developer you get the occasional fire drill where some application is crashing at 3 am and you walk into a mess at 7 in the morning. You had expected to spend the day adding that cool new feature, but now you’re digging through reams of log files and looking at environmental issues.
Imagine that amplified about 10 times. Managers plan for coming in doing some strategic items like outlining an Agile rollout strategy or writing justifications to upgrade development hardware. Instead you’re pulled aside by the CIO who’s asking about some serious security breach. In the midst of digging into that a PM stops by to inform you that the project just lost its tester and you need to help them scramble to cover the role. By lunch you’re hunched over your computer catching up on the 100 emails you were ignoring when you find an outside customer asking how to connect to your external API forwarded from the head of customer relations.
They can be really frustrating days and throw off your progress on the bigger goals. The key is to try to recover and come in fresh the next day. Fire drills don’t last that long generally. If it goes long we’re probably talking about a Death March project and those are something to avoid where possible.
So if your boss is running around a bit frenzied asking for quick updates, and looks like she skipped lunch they’re probably stuck focusing on tactics over strategy.
1:15 Build Broken
1:22 Build Broken
1:46 Build Fixed
9:18 Build Broken
9:26 Build Fixed
Active healthy projects have a rhythm. The scenarios look like:
- The project rarely has any active development. Broken builds are a complete surprise. If you know someone is coding on it, you need to quickly provide some feedback on regular check ins.
- Active projects with teams new to CI have a lot of broken builds which are generally quickly resolved.
- Active projects who’ve worked with CI servers for a while tend to have long periods of calm with the unusual broken build. Often the broken build is due to some minor config item sometimes with the CI server itself.
As a manager in a shop with dozens of independent projects running the CI server is your best friend. The example email pattern was from a typical scenario over the weekend. Without doing more than scanning email subjects on my phone I could tell that a contractor was working over the weekend and adjusting to having automated builds. Gives you a extra bit of confidence.