Maven: when it works, it really works. When it doesnt, it really sucks.

October 10, 2007

About a week ago, we decided to fix our build. Because of architectural and implementation changes, the build, which was fairly monolithic, was no longer capable of deploying our components, which (a) had interdependencies, (b) depended on a lot of 3rd party jars, and (c) were, as the term implies, modular and not monolithic.

One of the senior devs on the team suggested that we switch from Ant to Maven2. As the original writer of the Ant script that was used to build the first paltry web server that launched the demo that got the project rolling, I wasn’t an Ant expert, and basically punted dependencies, relying on build order and installing all jars to the same dist directory that was on the classpath. When better Ant wranglers came along, they parameterized everything and made it work good enough, which was actually good enough until last week.

Still, I’m wary of overengineering (because I’m so damn good at it :), and maven2 seemed like a case study in complexity. The learning curve was steep — especially in the middle of an integration, when I’d rather be coding than reading about POMs. And, unlike my mac, you can’t just pick up Maven and run with it. You need to understand about repositories, both for resolving dependencies and uploading compiled components.

I almost cracked, when, in the middle of a yak shaving exercise involving a bash script and a recalcitrant database, something went sideways with a POM file and I had to start all over. But then I remembered that Gil, the guy who wanted to use Maven, was lazy — lazy in a good way. He would never sign up to work any harder than he absolutely had to, because he wanted to have time to learn more cool things. There had to be something to this maven crap, other than the clever and witty blog posts.

My turning point came today. I created a new project, I needed to whip up a servlet, so I created a webapp from a maven archetype and ripped off some old servlet code from somewhere, and jammed it in to the right place according to the maven directory layout. Then I added some lines to download the Jetty plugin, did some reading, and figured out that I could run jetty as a maven task in a way that detected changes in my class files and automatically re-deployed my app. Then I looked up a way to debug from eclipse, which almost made me not miss Ruby as much, because my code-debug cycle was pretty much automated. No more code-deploy-debug-redeploy, it was just code-debug-code-debug, (and by code, you TDD nazis, I mean write tests first and make them pass, of course!!

In the end, I have mixed feelings about Maven. When you get over the learning hump — and I do remember having similar learning humps with ant and make — it takes a lot of the cruft of build management out. When something goes wrong, it can be really hard to figure out how to resolve the issue — for instance when a necessary plugin isn’t specified in the almighty POM, you only get a message saying that the plugin isn’t there, not one to check your POM. And some of the documentation does leave something to be desired. Still, now that I’m seeing the light at the end of the tunnel — and I had Gil to set up repositories and lend a helping hand — I do feel like in the end it’s a net win when your project changes from ‘toy’ mode to ‘production’ mode.

Advertisements

searching for the perfect bike setup

October 3, 2007

Last year I decided to start road riding seriously again. I dropped a chunk of change on a nice titanium frame roadbike, and rode the RAMROD with a good friend, actually, by the end it was more like 20 good friends in an extremely fast paceline who didn’t mind that I couldn’t pull through until mile 120 when I underwent some kind of reincarnation.

This year, with work picking up, I felt significantly less motivated to log 70 miles in the AM before work, and the hours working restricted me to 2 fast laps around Mercer Island in the morning, for a whopping 32 mile ride, 28 if you don’t count the 5 mile limp to work. Mercer Island is still a great course to ride, there are 2 stop signs in 10 miles, and it’s up and down, twisty and turny. And at 5:30 in the morning, the only traffic you see are people walking their dogs and other cyclists.

Still, I was getting kind of burned by the repetitive route (and had no time to go longer / different), and halfway through the summer I decided to get some tri extensions.

Wow, what a difference. All of a sudden I was stretched out low and fast and moving much faster than I did when I was riding the hoods. I loved being in that super stretched out position.

Being a geek, and especially an equipment geek, I started drooling at all of the fast tri bikes I saw, and wondered about how I could convert my current rig to reflect my current riding style — after all, I was never in the drops anymore, and to be honest, drop bars with tri extensions seem too cluttered to me.

I was all about to spring for a standard base bar, new brakes, new shifters on the end of the tri extensions, and all that jazz, when I read this article, which really nailed both my riding style and a much simpler solution that would let me keep my STI shifters and be able to shift while climbing, which is about the only time I shift a lot. It’s not going to kill me, especially since I’m very non competitive, to reach over to an STI lever and shift while in the extensions. And those Deda base cow horn bars are a measly $59 dollars. Which is only about 20 Lattes (converting to Latte$ is a great way to justify anything).