One immediate difference between the Ride the Rockies and what I did last year was the route. Last year, I rode a loop, which made the logistics of travel a little bit easier. This year, it was a point-to-point ride from Grand Junction to Salida. Neither town is easy to get to, and while I had originally planned on driving, the logistics of getting both my bike and myself back to where my car would be parked would be annoying.

The ride organizers contracted a bus service that could be purchased from the various towns, but since for your bike to be transported you would have to disassemble and box it anyway, I decided to just save the time and effort and fly myself and ship my bike. I like driving, but the thought of driving through west Texas again just to get to Colorado is never fun.

This was the first time I had ever disassembled a bike and had it shipped. I first purchased one of the more popular hard-case luggage boxes for the bike but it didn’t fit my frame. I decided in the end to just use the cardboard box method and it worked out fine, although there’s a little bit of wear and tear on the bike from the experience.

Training

Unlike 2009, I knew coming into 2010 that I was going to ride either Ride the Rockies or the Bicycle Tour of Colorado again. I put in significantly more time and effort into training prior to this year’s event compared to last year. Instead of just under 1,000 miles of cycling from January through June in 2009, I managed to put in 2,500. Instead of just riding with no real plan in mind, I used a professional coach this year to correctly manage my workout, recovery and nutrition efforts before the ride. And last, but not least, I purchased a new bike with better gearing and a lighter frame to improve climbing potential.

My coach also talked me into buying a power meter for the bike early on in the training season. I had read about the benefits of training with a power meter for years, but the high price, and the knowledge that I only race occasionally, had kept me from buying one. In the end I gave in, and it really did help make my training time more efficient and beneficial.

One of the biggest changes with my training plan, versus the previous years when I had no real plan, was both the frequency of training rides and the intervals within them. In most years, I would only ride on the weekend and maybe one ride in the middle of a week. This season, it was pretty consistently 5 times a week.

Interval training is how you improve your performance, strength and speed in any endurance sport, and cycling is no different. With the power meter, my coach was able to tell where my weaknesses were and tailor my training program based upon that data and the goal of my season (the tour!).

For me, that meant a lot of tempo intervals – slower cadence rides at moderate power levels that help build slow-twitch muscle strength. Since I tended to ride at high cadences, I found myself relatively weak at these lower cadences for any long duration rides. The tempo intervals paid off big-time here.

The other big focus was on climbing repeat intervals where I would ride just under my lactate threshold at a moderate cadence to simulate a long, steady hill climb. These proved pretty difficult for me. When I would ride in Austin, TX, the hills were both too short and too steep for me to stay in the proper power range. In the Houston area, well, there are no hills, so your best approach is to just use a very large gear and ride into the wind to sort-of simulate the effort it would take to do a long climb. Frankly, it’s not anywhere close to what a real climb is like. Regardless, these climbs did do a lot to improve sustained strength on the longer climbs I had coming up.

The Ride

Day 1 – Colorado National Monument

Our first day was a short ride through the Colorado National Monument just outside Grand Junction. The monument is an amazing place to take in the canyons of the great southwest. I had never been to the monument before, so being able to see it for the first time on a bicycle was quite a joy.

We entered the monument from its south entrance and then stayed on Rim Rock Drive until leaving on the north side of the monument and returning to Mesa State College.

The steepness of the climb surprised me, since the elevation profile didn’t look bad at all from the ride book. Over 44 miles we climbed (and then descended) 4,200 ft. It took me just under 3.5 hours, including breaks and sight-seeing. Energy was 1,688 kJ & TSS was 184.

I left about an hour before most of the attendees did for this ride and it turned out to be a very good idea. When I got back to town there was a light rain storm, but up at the monument it was a heavy hail and lightning storm. There were lots of very wet and cold riders when the main group began to return to town.

I talked with some Grand Junction locals during the afternoon who said the monument was a weekly ride ritual for them. That would not get old.

Day 2 – Grand Junction to Delta via Grand Mesa

Day 2 was the hardest day of the tour on paper, and proved to be on the road, too. Oddly enough, during last year’s Bicycle Tour of Colorado, we also rode up Grand Mesa but that year we started from the south side of the mountain, whereas this year we started on the north side. I’ve heard locals say that riding from the south side is more difficult.

Now, ultimately, this is just one tough mountain to climb. From either side you’re looking at 6,000 ft of climbing over 20 solid miles. If you’re a flat-lander like me, you have the additional disadvantage of not yet having any acclimation to altitude to contend with.

Unlike my 2009 climb up Grand Mesa, 2010 was quite a bit easier. The training and gearing paid off, and we had cooler, cloudier weather to contend with. That weather actually turned out to be a disadvantage on the descent, where a rainstorm kicked up and I rode over 10 miles at high speed with heavy rain and sleet – ouch!

At the summit of the climb, the logistical skills of the Ride the Rockies crew really shined. There were plenty of supplies and food vendors ready for us, and no shortage of food and drinks. They even had a motor coach idling a the top with its heaters on, so riders could go inside and warm up nicely – it was about 38 degrees F at the top when I arrived.

Overall the ride took me a whopping 8 hours and 20 minutes, with just under 7 hours of actual riding time to cover 94 miles. I did 3,578 kJ and my TSS was 350.9 with right at 8,000 ft of total climbing. That’s a big ride!

Day 3 – Delta to Ouray

Day 3 was assumed to be a nice easy day for us to recover. At only 67 miles and with a nice gentle slope up to the town of Ouray, it didn’t look like a rough ride. We were in for a surprise, though, as the route we took from Delta to bypass the main highway to Montrose was some of the roughest roads I’ve ever ridden on. It was incredibly jarring and annoying, especially after being rather worn-out from day 2.

Luckily, the scenery made up for the road quality. While not very dramatic, the farms and ranches along the route were gorgeous and as we got closer to Ouray, we began to see the San Juan Mountains in the distance – our destination for day 4.

Day’s 3 ride took 6 hours 34 minutes, with just under 5 hours of actual riding time to cover 67 miles. I did 2,375 kJ of work and my TSS was 208 with just 4,000 ft of total climbing.

Arriving into Ouray was a real treat in itself. I had never been to this tiny mountain town, and it was amazing how gorgeous it really was. The local businesses did a bang up job hosting and it was a great place to have lots of beer and food.

Day 4 – Ouray to Durango via Red Mountain Pass, Molas Pass and Coal Bank Pass

I expected day 4 to be everyone’s favorite of the entire tour, and I was not disappointed. The day began with a climb up to Red Mountain Pass immediately upon leaving the town of Ouray – no warm-up here! Literally before we made it six blocks and to the end of town we were climbing on a steep grade.

The ride up Red Mountain Pass was, simply put, stunning. The road is narrow, winding, and steep. Halfway up the climb to Red Mountain Pass was the first aid station of the day. So far in the tour I hadn’t been stopping this early, but today I was tired enough after the initial climb to take an early break and have a big breakfast.

The break was worth it, as the rest of the climb to the summit of Red Mountain Pass was a tough, but incredibly gorgeous, climb. After the summit was a fast, winding descent into the town of Silverton.

After Silverton, the second big climb of the day started immediately – the climb up to Molas Pass. This was my favorite climb of the entire tour as the scenery of this part of the San Juan Mountains is hard to beat.

Molas Pass was a good spot for a rest, with a short climb to Coal Bank Pass to follow. The climb up Coal Bank pass continued to be incredibly scenic and afterwards everyone knew the climbs were done for the day and all we had was a 35 mile descent into Durango.

As soon as I started the descent off Coal Bank Pass I had my first safety incident of the tour. At about 40 mph a female elk darted out in front of me from the side of the road. I braked hard – too hard and the rear wheel locked up and started to skid. Luckily I let go of the brake immediately and my bike corrected. Even though I was only yards away from hitting the elk, she moved across fast enough that I could have avoided her even if I hadn’t braked. That said, the adrenaline rush from that little experience stuck with me for a while and I took the rest of the descent into the Purgatory area a little bit easier than I would have otherwise.

It turns out the descent into Durango wasn’t as easy as we had been expecting. We had a strong headwind to contend with and the increased heat of the afternoon as we exited the high mountains. I screwed up and wore a long sleeved jersey on the day, which was great until the last 20 miles. At that point, not only could I not remove my sleeves to keep cool, I also found my sunscreen had given up and I lost my spare tube somewhere during my descent. Luckily one of the riding medics loaned me some of her sunscreen so I covered up a bit, but regardless I was still rather toasty.

The last few miles in Durango proper were a bit of a surprise, at least if you haven’t ridden in the area before. Rather than being straight down into town, there was a very steep short climb to go up from the valley where Durango proper is to reach the top of the mesa were Fort Lewis College is. As minor as that climb was, by that time of day I was spent and was just looking forward to getting off the bike, finding some food and taking a cold shower.

The best part of being in Durango was that I knew some of the good restaurants in town and found one of my favorite sushi restaurants. What a treat after a long, hot day in the beautiful San Juans.

Day 4′s ride took me just under 9 hours elapsed time with 7 hours on the bike itself to cover just 75 miles. I did 3,068 kJ of work and had a TSS of 294 with 7,818 ft of elevation gain.

Day 5 – Durango to Pagosa Springs

But not for me! I decided to take a tactical rest day on day 5, despite the promise of an easy day. The route was a long 87 miles, but with only 2 short climbs. In retrospect I probably would have been fine to ride it, but I wanted to be fully rested for day 6.

I took one of the motor coaches to the next town and had the entire day for R&R in Pagosa Springs. The hot springs there were a great treat and the warm waters made my muscles feel better, even though it probably was not the best thing for recovery. Nor was all the beer probably the best idea either, but it hit the spot regardless.

Disaster almost struck today as my helmet was not attached to my bike when I went to go check on my bike before getting ready for bed. I foolishly had my helmet attached to the bike when I handed it off to the luggage truck folks before boarding the motor coach for my ride into town. And since I checked too late in the day, all of the local vendors that might have sold helmets were closed already, as was the information tent with the lost & found.

The next morning I was assuming I would likely have to take the bus again since I didn’t have a helmet, but one of the folks working the luggage trucks in the morning was kind enough to loan me his helmet for the day. Random kindness from strangers saved my bacon!

Day 6 – Pagosa Springs to Alamosa via Wolf Creek Pass

Day 6 started with a climb up Wolf Creek Pass on US160 – one of my favorite passes to drive over in a car, especially if you take the side road off the pass onto the mountain top once you reach the summit of the pass. The true climb was only 8 miles total, but we had a 16 mile warm-up climb that slowly took us up the 700 ft or so before the true climb begin. Since aid station 1 was right at the base of the climb, it was a perfect spot to take a rest and grab a nice breakfast.

Wolf Creek pass is a gorgeous climb and a moderately difficult 6.5% grade the whole way up. Halfway up there was a bit of a distraction as a tractor-trailer had rolled itself in a tight corner and almost plowed off the side of the pass. That slowed us down a bit as the road went down to one-lane and we had to intermix with road traffic a bit more than we otherwise would be.

The summit of Wolf Creek Pass is a bit anti-climatic as its rather flat and wide with no dramatic views. The side-road going up to the top of the mountain is gravel, so a no-go on a road bike. So, after a quick resupply, it was time for the very long descent off the pass and into Alamosa.

The descent off Wolf Creek Pass proved to be one of the more dangerous ones of the whole tour as there were several crashes reported later on in the press. I almost did myself in by swatting at a bee that landed on my knee rather than keeping both hands on my handlebars – moving your arms quickly at 45 mph is not the best way to keep your bike stable. Luckily I corrected myself just in time before entering one of the larger tunnels that you go through on the descent.

US160 turns from a northeasterly direction to a southeasterly direction between the towns of South Fork and Del Norte. For us, that meant exposing ourselves to a pretty rough crosswind about the same time the valley opened up for the trip into Alamosa. The ride from Del Norte into Alamosa was the toughest, or at least most uncomfortable, part of my entire tour as my body could just not get comfortable on the bike and my riding form wasn’t good as a result. Crosswinds take even more out of you than headwinds as they can be rather dangerous when gusty and make it harder to hold a steady tempo pace.

Day 6 took me a total of 7 hours 17 minutes with 6 hours 18 minutes on the bike to cover 92 miles. I did 2,909 kJ of work and my TSS was 270 with 5,000 ft of total elevation gain.

Day 7 – Alamosa to Pagosa Springs

The final day of the tour turned out to be one of the most fun, thanks largely to Mother Nature cooperating with favorable wind conditions. We road north from Alamosa up to the San Luis Valley to Pocha Pass before descending into Salida.

What is amazing about this route is just how incredibly flat the road is. For the first 40 miles we gained 30 ft – yes, 30. With a tailwind, this meant nice, fast speeds of over 20 mph even while soft pedaling, and over 25 mph with a little bit of effort.

Once the valley began to narrow and we began to ascend towards Pocha Pass, we added only 1,600 ft of elevation gain over the next 20 miles. The climb up Poncha Pass from the south is amazing in that you don’t really feel like you are going up a mountain pass at all. Once you begin your descent, however, it is a totally different story.

The descent off Poncha Pass into Salida was a nice, steep grade to keep the speeds up. I hit my top speed of any of the descents during the tour right at 50 mph, or 80 kph.

Day 7 took me 5 hours 27 minutes total time, with 4 hours 22 minutes on the bike. I did 2,171 kJ of work with a TSS of 178 and 1,753 ft of total elevation gain over 85 miles.

Once in Salida, it was time to disassemble and box up my bike, find a cold shower and hot food, and then wait for the bus that returned me to Denver for my plane ride home the next morning.

Reflections

On the tour: The Ride the Rockies organizers are very professional and the overall smoothness of the tour reflects it. Everything wasn’t perfect, but it was very well done. My only real complaint would be the over-reliance on third-party vendors at aid stations. That meant no key supplies like sunscreen, etc. at most of the aid stations. For the most part, this is a non-issue, until you’re That Guy that forgot to bring some that day and forgot to make a quick stop at a connivence store along the route to get one. Don’t be That Guy!

I do also wish the ride had organized ways to drop off some of your extra clothing at aid stations and have it returned to you at the next nightly camp. The Bicycle Tour of Colorado folks did this in 2009 and for some of the big mountain pass days it made perfect sense – you would need a lot of warm clothing for the first half of the day, but the second half you were hot and needed to get rid of some of that bulk.

On the route: It was awesome. They certainly made it difficult, and I thought they should have thrown in a rest day in the middle. But in hindsight, it was so easy to take your own rest day, and the majority of people did ride all 7 days, so clearly while the route was hard, it was not too hard. From having done two tours in Colorado now, somewhere between 450 and 550 miles does seem like the right amount for a week-long tour.

On the equipment: My new bike was awesome. The frame was lighter and more comfortable than my previous bike, and the compact gearing with the 11-28 cassette made climbing the big, steep hills a lot easier for a flatlander like me. I could have done the ride with standard gearing and an 11-25 cassette, but my knees would not be thanking me now.

And the power meter? For something that you totally don’t need, it’s totally worth having. But then I’m a data junkie so my perspective might be a bit skewed.

I also avoided carrying extra equipment with me this year – no camelback backpack for holding extra clothes, etc. – everything went into my jersey pockets. I just made sure I bought jerseys with big enough pockets and it worked out just fine. I even managed to carry my rain gear almost the entire tour except on days with no chance of rain.

On coaching: Totally worth the price. Yes, you can self-coach, and yes, once you know what coaching is all about,  it’s more likely that you could self-coach and be effective. But the information and insight I gained, along with the planning of my training season to match my priorities, was easily worth the price. If I had tried to do this myself again, I would have not ridden as much total volume, nor would I have utilized the build-up and recovery cycles effectively and would have not been in peak condition for the tour.

Ride Your Bike

If you haven’t done a long bike tour yet, especially somewhere in the mountains, put it on your list. If you like to ride, there is something really special about being out on the bike for a solid week of riding. The event itself will be amazing, and if you properly train for it that effort will be life-changing all on its own.

All of the pictures I took on the ride are on my flickr page here: http://www.flickr.com/photos/26521676@N00/sets/72157624320722734/show/

Many times, however, Flash isn’t an appropriate technology to use. If you’re an open-source product like Zenoss, Flash presents a licensing issue. If you’re targeting mobile platforms like the iPhone, Flash isn’t available. And, sometimes, you may just not like Flash; it does have it’s own security problems and overhead, for example. What’s a web developer to do? Enter HTML5 to the rescue…

HTML5 is not yet an approved standard, but it’s well on its way and surprisingly well-supported by the browser community already. One of the nice new features provided in HTML5 is the canvas element which allows for two-dimensional drawing functionality. Between this new feature and JavaScript, we should be able to create a rich graph display.

To get started, we’ll first need to create an HTML document that has the structure we’re after and a place for our drawing canvas to reside.

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Rich Graph Example using HTML5's Canvas Element</title>
  </head>
  <body>
    <h1>Rich Graph Example using HTML5's Canvas Element</h1>
    <canvas id="graph1" width="500" height="200">
      This text is displayed if your browser sucks.
    </canvas>
  </body>
</html>

Next, we’ll need some JavaScript to do the work of creating the actual graph display. First, we’ll need to get a reference to the canvas DOM element and then ask it for it’s 2D drawing context:

    var graph1 = document.getElementById('graph1');
    var context = graph1.getContext('2d');

Next, we’ll need to define the raw data used to display the graph. We’re going to assume a set of CPU processor time measurements with 5-minute measurement intervals, much like you would see in Zenoss or other systems management application.

    // Raw data, such as what might come back from a server query.
    data = [
      { value: 9.9430, time: new Date(2010, 4, 9, 7, 50, 0, 0) },
      { value: 0.0000, time: new Date(2010, 4, 9, 7, 55, 0, 0) },
      { value: 0.0000, time: new Date(2010, 4, 9, 8, 00, 0, 0) },
      { value: 0.0000, time: new Date(2010, 4, 9, 8, 05, 0, 0) },
      { value: 5.5828, time: new Date(2010, 4, 9, 8, 10, 0, 0) },
      { value: 1.0000, time: new Date(2010, 4, 9, 8, 15, 0, 0) },
      { value: 25.3120, time: new Date(2010, 4, 9, 8, 20, 0, 0) },
      { value: 45.8210, time: new Date(2010, 4, 9, 8, 25, 0, 0) },
      { value: 98.3211, time: new Date(2010, 4, 9, 8, 30, 0, 0) },
      { value: 96.1290, time: new Date(2010, 4, 9, 8, 35, 0, 0) },
      { value: 94.9128, time: new Date(2010, 4, 9, 8, 40, 0, 0) },
      { value: 98.3219, time: new Date(2010, 4, 9, 8, 45, 0, 0) },
      { value: 32.4912, time: new Date(2010, 4, 9, 8, 50, 0, 0) },
    ];
 
    // Calculate the maximums in the provided data.
    var maxY = 0.0;
    for (var i = 0; i < data.length; i++) {
      maxY = Math.max(data[i].value, maxY);
    }
    var dataMaxY = Math.ceil(maxY);
    var dataMaxX = data.length;

Now, we have to calculate where we can start drawing on the canvas and how many pixels equal one coordinate in our user space data. The more elaborate legends we’ll want to use on the graph, the more these calculations will matter as we leave space for drawing text around the actual graph.

    // define a font to use for legends
    var fontHeight = 20;
    var font = "12px/20px arial, sans-serif";
 
    var xStart = 0;
    var yStart = fontHeight * 2; // leave room for 2 lines of text at the bottom
    var xEnd = graph1.width;
    var yEnd = graph1.height;
 
    // Determine how many pixel units equal one user space coordinate.
    var xStep = dataMaxX / (xEnd - xStart);
    var yStep = dataMaxY / (yEnd - yStart);
 
    // Create an array of 2D points to represent the user space
    // coordinates of each data item.
    points = new Array(data.length);
    for (var i = 0; i < data.length; i++) {
      var x = i / xStep + xStart;
      var y = data[i].value / yStep + yStart;
      points[i] = { x: x, y: y };
    }

Now we get to the actual drawing of the graph. This is straight-forward 2D drawing that should be familiar to anyone who has done it with other technology.

    // Save the graphics context before we begin mucking with it.
    context.save();
 
    // Create a transform so that the graph portion of the chart can be
    // drawn using a bottom-left origin instead of the default upper-left.
    context.translate(0, yEnd);
    context.scale(1.0, -1.0);
 
    // Draw our path using the appropriate color.
    context.beginPath();
    context.strokeStyle = 'black';
    context.lineWidth = 5;
    context.moveTo(points[0].x, points[0].y);
    for (var i = 1; i < points.length; i++) {
      context.lineTo(points[i].x, points[i].y);
    }
    context.stroke();
    context.restore();

At this stage, we can render a simple line-graph using JavaScript and an HTML5 canvas element. Now about making it rich and interactive? We’ll need to add some mouse event handling. We’ll do something simple here: as the mouse moves along the x-axis of the graph we’ll find the current data point based solely on its x-position. This technique is more useful to an end-user and saves the calculation of finding how close a point is to a line segment.

Mouse events are still rather browser specific, so the calculations presented here to determine the offset of the mouse inside of the canvas are simplified and will not work in all scenarios.

    graph1.addEventListener('mousemove', mouseWatcher, false);
 
    function mouseWatcher(evt) {
      // Get the mouse position relative to the canvas element. This stuff
      // is still gnarly across browsers. Here we're assuming we need to
      // figure out the offset the canvas has in the client area, so our
      // mouse position is really relative to the canvas, not the client area.
      var x = graph1.offsetLeft + evt.clientX;
      var y = graph1.height + graph1.offsetTop - evt.clientY;
 
      // Get the data point at this X position
      var foundPoint = -1;
      var x1 = points[0].x;
      for (var i = 1; i < points.length; i++) {
        var x2 = points[i].x;
        if (x >= x1 && x <= x2) {
          foundPoint = i-1;
          break;
        }
      }
 
      if (foundPoint >= 0) {
        txt = "" + data[foundPoint].value.toFixed(2) + " @ " + data[foundPoint].time.toDateString();
 
        // draw a new information line in the legend
        context.save();
        context.font = font;
        context.clearRect(0, yEnd - fontHeight, xEnd, fontHeight);
        context.fillText(txt, 0, yEnd, xEnd);
        context.restore();
      }
    }

And that’s it. Over your Sunday morning coffee you can write a simple, yet effective, interactive graph display using HTML and JavaScript alone. Clearly, a tremendous amount of work remains to make the graphs beautiful and robust, but luckily a large number of people are already working on libraries to do this work for us.

Internet Explorer will not yet display canvas elements natively, but luckily this problem is being solved for us.

There are other problems, too. Today, for example, the font measurement abilities in the HTML5 specification are lacking.

If you want to see the example in action click here. View the source in your browser to see the final source code to the example. A screenshot of the example is below.

If you are already an iPhone user, the iPad will simultaneously feel familiar but also so incredibly rich and powerful compared to it’s little brother. The extra screen real estate is in itself nice, but more importantly is how the iPhone OS’s approach to user interaction makes use of this extra room.

For example, the Mail app shows each message in full screen glory, but with a fast overlay window to show message and folder navigation. The usability effect is wonderful. Using Safari is now like browsing on a regular computer, except with a multi-touch interface.

I don’t play very many games on the iPhone or iPad, but the Words With Friends game (think Scrabble) is almost worth getting an iPad for just to play it. I suspect the casual gaming crowd I’ll a have a lot to look forward to with their new toy.

Battery life on the iPad has been better than I expected. A little over 48 hour into ownership and I’m down to 10% battery life. I’ve used it a lot, including a lot of reading, so it seems to hold up well there. While it does not compare to the extra long battery life of a Kindle, the device does so much more it seems like a good trade-off.

As far as being an e-reader, I like the iPad better than the Kindle DX (that I normally read from), but not as much as the regular Kindle 2. That device is sized so well, and the battery life is so good, it’s easy to see it remaining the king of its segment for a while. That said, I am a guy, so i like big screens, and here the iPad wins over the DX. The iPad is a touch heavier, but it still feels natural to hold. A minor, but very nice feature in the iPad is the physical orientation lock button, something which the DX has as a software feature that is hard to use.

I plan on using my iPad as a replacement for my laptop for casual computing. It seems like it is going to do that job well. They keyboard is easy enough to use even for this blog entry, and the heavy writers out there may find the keyboard dock option even better than lugging around a laptop.

BMW 7-series = nicer than the previous generation, also quite surprised to see roof-rack slots in for this model.

All Audis = beautiful design on the exterior, meh on the inside. You can do better, Audi… make me feel like I’m giving up something if I go buy a BMW.

Cadillac CTS, CTS-V and CTS SportWagon = much nicer than I expected. Exterior is sharp, interior is nicely done and about on par with the BMW 3-series as it should be. CTS-V is slightly nicer on the inside.

New Camaro = too bad they kept the name, because eventually this car will be in every trailer park making the new ones look horrible. Extremely well done car, inside & out. Back-seat only for midgets and a large trunk with one of the smallest hatches I’ve ever seen on a car. Totally not practical, but totally awesome. Even the V6 version looks good.

New Grand Sport version of the Corvette = much, much sharper looking in person than I expected. Tempting, tempting…

New Mercedes-Benz E-Class sedan & coupe = absolutely gorgeous on the outside and a total letdown on the inside. Not even as nice as a BMW 3-series, let alone a 5-series. These were the E-350 versions, so hopefully the V8 and AMG versions will remedy some of that. Having a total display floor size of an average size guest bedroom doesn’t help showing off the cars.

All Acuras = couldn’t be more boring if they tried. Interiors remind me of cheap GM cars from the early 90s. Exteriors only a boy racer wanna-be could love. The new ZDX was interesting but had rear-doors that would make you yearn for the spaciousness of a Camaro.

2009 was a record year for riding in a cars at just over 21,000 miles, just over my previous record driving year of 2008 which was around 19,000 miles.

On the bicycles, I only managed 2,000 miles, significantly less than my 2008 peak of 2,700 miles.

Branch-Based Development

At Zenoss we do all development, including bug fixes and small maintenance tasks, in a private development branch within the subversion repository. This allows us to independently work-on changes, check-them into the repository for safe-keeping, and then perform code reviews with team members without having to share files or using pastebin style tools (even though we do both at times).

1. Create a branch within your user’s sandbox. In this example, I’ve decided to name the sandbox new-widget to identify what I’m working on. If I were fixing a defect, I’d use the defect number from the defect tracking system. Create the branch by copying the trunk folder to the sandbox branch. In Subversion this is a low-overhead operation and doesn’t actually copy files.
svn copy http://dev.zenoss.org/svn/trunk http://dev.zenoss.org/svn/sandboxen/cgibbons/new-widget -m " * Copying trunk to sandbox branch."

2. Switch your working directory to use the new sandbox branch. You can do this either from the command-line or using Eclipse. From the command line, you’d do the following:
cd $HOME/zenoss/core
svn switch http://dev.zenoss.org/svn/sandboxen/cgibbons/new-widget
From within Eclipse, secondary-click on the core project and choose Switch to Another Branch/Tag/Revision… option from the Team menu. On the dialog that appears, enter in the sandbox URL. After switching, your Eclipse will show the new location next to the core project item.
   

Once your development environment has been switched, you can make changes and commit to the Subversion repository as desired. If you’re unsure if you are in the right branch, you can always use the svn info command to see which directory is being used.

Merging Branches

Once you have completed changes in a branch and have had them reviewed by a peer, it is time to merge them into trunk (or another branch, if using a maintenance release). Merging can be tricky, but a consistent process can make it much easier to handle.

1. Change your working directory to a checked-out and clean version of the branch you want to merge into. For example, I keep a $HOME/zenoss/clean-trunk directory that I never make changes to, except for merging.
2. Determine the base working revision of your working branch. There are a variety of ways to do this, but one of the best is to view the revision log graph within the Trac system directly. For example, for the branch discussed above we can browse to http://dev.zenoss.org/trac/log/sandboxen/cgibbons/new-widget/ and see that revision 15513 is the base.
3. Perform a dry-run on the merge to get a general idea of what the changes into the branch will be. You should see your expected changes, plus any conflicts from changes to the other branch while you have been working in the sandbox branch.
svn merge --dry-run --revision 15513:HEAD http://dev.zenoss.org/svn/sandboxen/cgibbons/new-widget .

4. If the merge results look satisfactory, rerun the command without the dry-run argument.
5. Look at the final merge results using svn status and svn diff, and once you’re ready, issue an svn commit.

Multiple Branches and Zenoss Configuration

As you switch between branches you will often render your Zenoss configuration useless.  Resetting your database after each branch switch is usually a good practice, and being able to quickly recreate any test data you may need makes this process less painful.

After switching a branch, my process is usually the following:

1. Shutdown zenoss and restart only zeo.
zenoss stop
zeoctl start
2. Run the zenwipe script from the inst source directory.
$HOME/zenoss/inst/zenwipe.sh --no-prompt
3. Run zenmigrate to install any database changes available within the current branch.

Depending upon the task at hand, I may install additional ZenPacks and add new devices through the command-line if those are needed. Helper scripts, such as install-windows.sh to install of the Windows ZenPacks and create several local test devices in the instance, are useful tools to have for your typical configurations.

Mac OS X Prerequisites

1. Install Eclipse Classic 3.5.x Mac Cocoa 32-bit.

Ubuntu Prerequisites

1. Install the Sun Java JDK. Why? Eclipse is a Java application and requires a full-fledged Java environment to run properly.
sudo apt-get -y install sun-java6-jdk

2. Install Eclipse Classic 3.5.x Linux 32-bit.

Eclipse Configuration

1. In part one, we created a Zenoss root project directory of $HOME/zenoss – use that directory, or the one you created, for the rest of these steps.
2. Launch Eclipse and configure it to use the Zenoss root project directory. Why? Eclipse needs a workspace directory to keep track of configuration settings for a group of related projects. By placing the workspace directory inside of the Zenoss root workspace, we can separate the requirements for a Zenoss workspace from other projects you may be using.
3. Install the PyDev plug-in for Eclipse. Why? PyDev provides Python language support to Eclipse.
   1. Go to the Help Menu and choose Install New Software.
   2. In the Available Software dialog, choose Add and enter in http://pydev.org/updates/ as the Location and close the dialog. Eclipse will return to the Available Software dialog.
   3. Software matching PyDev will appear in the dialog; pick the PyDev option but do not pick PyDev Mylyn Integration. Click Next and install the plug-in.

   

4. Install the Subclipse plug-in. Why? Subclipse allows you to work with the Subversion version control system directly from within Eclipse.
   1. In the Available Software dialog add the Subclipse plug-in update site:

      http://subclipse.tigris.org/update_1.6.x

   2. In the Available Software dialog, choose the Subclipse, Subversion Client Adapter, Subversion JavaHL Native Library Adapter and the Subversion Revision Graph items.
5. Go to the Window menu, choose Open Perspective and then SVN Repository Exploring (you may have to choose Other… to see this option).
6. Choose the New Repository Location button in the SVN Repositories panel. Add the Zenoss SVN site at http://dev.zenoss.org/svn
7. Open the SVN repository and select the trunk folder. Secondary-click the folder and choose the Checkout… option. Be sure to change the Depth option to be Only this item so that we don’t check out any of the sub-folders of trunk just yet (many of the folders within trunk are not needed for development, but we want to keep the directory structure). In the next dialog you will be asked to choose a Project Wizard. Open the Pydev tree item and select the Pydev Project option.
8. Create the project in the Pydev Project dialog:
   1. Use core as the project name and use the default location. This should create a core project at $HOME/zenoss/core.
   2. Make sure the Python project type is selected.
   3. Select 2.4 as the Python Grammar version.
   4. Uncheck the Create default ‘src’ folder... option.
   5. Click the Click here to configure an interpreter not listed… option in order to add the python interpreter built by the Zenoss installation scripts.
      1. In the Preferences Dialog, choose the Interpreter – Python item underneath Pydev and select the New… button to add a new Python interpreter.
      2. Browse to the $ZENHOME/bin directory and choose the python2.4 executable from that directory.
      3. Name the interpreter python-2.4, zenoss-python or some other variant.

      After the new Python interpreter has been added, return to the Pydev Project dialog and choose that interpreter from the list and then click Finish to create the project.

   6. Update the core folder from the command-line SVN client so you can selectively pull the sub-folders of the core project and not all of them:
cd $HOME/zenoss/core
svn update Products

   7. Move the Products directory the installation checked out and create a symbolic link to the one updated above. Why? This allows the Products source tree to be worked on from Eclipse and then also used by the Zenoss run-time.
cd $ZENHOME
mv Products Products.old
ln -s $HOME/zenoss/core/Products Products
   8. Return to Eclipse and choose the Refresh option from the File menu so that Eclipse notices the updated directory and builds necessary dependencies.
   9. Secondary-click on the core project folder in Eclipse and choose Properties. Choose the PyDev – PYTHONPATH item and add source folders so PyDev can reference the project from within itself.
      1. In the Source Folders tab choose the Add source folder button and pick the root core folder from the provided list.
      2. In the External Libraries tab choose the Add source folder button and choose the $ZENHOME/lib/python directory.

   At this point, your Eclipse project should allow you to navigate between dependencies within the Zenoss project. You can also simultaneously switch between using the Team feature within Eclipse to update and manage Subversion or do so using the command-line svn client.

   Next…

   In Part 3 of this series, we’ll discuss how to manage day-to-day activities such as creating sandbox branches for changes and dealing with multiple versions are done from within the same environment.

I develop Zenoss primarily on Mac OS X, with some work done on Ubuntu when necessary. I normally use Eclipse as my development editor, although I’ll often just use vim when doing quick changes or bug fixes. In either case, careful setup of the Zenoss environment is key to being able to productively work with both the new development version and with the shipping versions that require maintenance.

The environment you get by default when you check out the source version of Zenoss from the source repository, or from a source tarball, is not necessarily setup in the best way to develop productively using tools like Eclipse.

The rest of this post will document how both my Mac OS X and Ubuntu environments are initially configured so that a working source Zenoss installation is realized.

Mac OS X Prerequisites

These prerequisite instructions assume Mac OS X 10.5 Leopard; 10.6 Snow Leopard will not be able to compile Zenoss’s third-party dependencies, so an additional work-around is required for that platform until Zenoss moves to Python 2.6.

1. Install Xcode. Why? Installs the GNU C/C++ compiler and other command-line development tools needed to build dependencies used by Zenoss.
2. Install Universal Subversion 1.6.x from CollabNet Community.Why? Leopard only comes with Subversion 1.4.x. This version is not compatible with the Subclipse plug-in for Eclipse that will be used later. In order to be able to use both the command-line and Eclipse Subversion versions simultaneously on the same checked our source, the release of subversion should match. This installation will place the Subversion binaries in /opt/subversion and should automatically add it to your PATH.
3. Install MySQL Community Edition 5.1 32-bit. Why? Zenoss needs MySQL for storage of event data.

Ubuntu Prerequisites

These prerequisite instructions assume Ubuntu 9.04 32-bit Desktop Edition. Installing the server edition or one with different options may require additional prerequisites to be installed.

1. Install Subversion. Why? Working with the Zenoss product in source form requires Subversion to access the source repositories (it is also possible to build directly from a source tarball, but this is not discussed here).
   sudo apt-get -y install subversion

2. Install MySQL. Why? Zenoss needs MySQL for storage of event data.
   sudo apt-get -y install mysql-client mysql-server libmysqlclient15-dev

3. Install additional development environment tools. Why? Zenoss third-party dependencies require several binaries to be built from source.
   sudo apt-get -y install patch make vim gcc g++ autoconf
4. Install SNMP support. Why? Zenoss requires SNMP libraries for monitoring, and having a local SNMP agent is useful for testing.
sudo apt-get -y install libsnmp-base snmp snmpd
5. Install Liberation TrueType fonts. Why? Graphs generated by RRDtool will not contain the correct glyphs without this font package.
sudo apt-get -y install ttf-liberation

Environment Configuration

Configuring Eclipse will require determining where you want to work with your Zenoss installation, and installing Eclipse plug-ins to provide the features required for Python and Subversion support.

1. Create your Zenoss root directory:
mkdir $HOME/zenoss

2. Create and run a setup.sh script that will configure needed environment variables for zenoss. This script can be started from your log in profile if desired.
cd $HOME/zenoss
cat > zenoss-config.sh <<EOF
ZENHOME=$HOME/zenoss/zenhome
PYTHONPATH=$ZENHOME/lib/python
PATH=\$ZENHOME/bin:\$PATH
export ZENHOME PYTHONPATH PATH
EOF
chmod +x zenoss-config.sh
. zenoss-config.sh
mkdir $ZENHOME

3. Checkout the Zenoss source installation tree. Why? This tree is used to bootstrap the installation from the source repository and create a running Zenoss installation. We’ll need this before we modify it to fit the needs of our development environment.
svn co http://dev.zenoss.org/svn/trunk/inst inst

4. Run the installation script to checkout, compile, and configure a zenoss environment. If you need to customize your MySQL configuration at all do not use the --no-prompt argument.
cd inst
./install.sh --no-prompt

5. Modify the zensocket file to be setuid root. Why? Some of the Zenoss daemons use a privileged port and making the file owned by root and accessible by the Zenoss user allows the daemons to be run as a non-priviledged user but still use the privileged port.
sudo chown root:`id -g` $ZENHOME/bin/zensocket
sudo chmod 04750 $ZENHOME/bin/zensocket


At this point, you should have running zeo and zope processes and be able to log on to the local Zenoss instance. Your Zenoss root directory should look similar to the following:

Next…

In Part 2 of this series, we’ll download and configure the Eclipse IDE.

I travel quite a bit between Houston and Austin and there are really only three reasonable ways to go: US-290; I-10 & TX-71; or I-10 & TX-183. Over the years my preference has moved from US-290 to I-10 & TX-71 as traffic along US-290 has increased on the eastern fridges of the Austin area, but the distance and time between the two is very similar and really it depends upon where in Austin you might be headed.

The GPS systems in my cars have three route options when you pick a destination: fastest, shortest and other. In both cars, the route displayed is none of the above three, but instead a long, out-of-the-way route of I-10 to Seguin before heading north on TX-123 to San Marcos, and then heading into Austin on I-35. This option is a whopping 222 miles with an estimated travel time of 3 hours and 39 minutes.

Now, the fastest route is usually not the shortest. Route calculations are supposed to take into account the actual speeds of the road segments involved, and since interstate highways are almost always faster than anything else, there is a natural preference to these roads. In this case, however, the calculation is way off. Taking I-10 to US-71 (via US-59 & TX-8 inside of Houston for those familiar with the area) is only 166 miles and estimated to take 3 hours 29 minutes according to Google. Likewise, taking US-290 is only 168 miles and estimated to take 3 hours 22 minutes.

Of course these time estimates are usually worst case scenario. Driving a few miles per hour over the speed limit I often make my trip in 2 hours and 30 minutes; worst case has been 3 hours and 10 minutes when driving 55 as an experiment (a painful one at that).

What about the shortest route option in the GPS system? That does actually route you onto I-10 & US-71 in this example, but the shortest route calculations are always incredibly stupid, too. They will often take you onto side streets for half a mile or less just to maintain the shortest possible distance. Once, when driving through Memphis, TN, the GM GPS took us on and off the interstate highway three times when driving through town, often for just a couple of blocks, just to maintain the shortest distance. Granted this is a clear example of a GPS system not being there to replace your own intelligence, but if you don’t know the town…

In the early days of consumer-level GPS systems, one of the common problems was having accurate speed data for different road segments. In western states especially, secondary highways often have the same speed limits as interstate highways. In Texas, the past 20 years has seen many of these highways improved so they route around the smaller towns, rather than going through them and stopping at every light. Consequently it is often better to take these roads than the interstates whenever possible. If the GM GPS systems do not have accurate speed data then it can account for some of this behavior, but not all.

On my normal route, once you finally hit TX-71 and the GPS decides you mean it, suddenly the estimated arrival time drops dramatically along with the distance. Is it computing this arrival time based upon your actual speed so far, or based upon the speed data of the road?

Over the years I’ve gone from absolutely wanting a satnav system in the car to wishing mine didn’t. I get much better results using a smart phone with Google Maps to get a general idea of the route to take and then consulting with it now and then if things get tricky. But for the most part, they seem poorly done enough that they just get in the way rather than help. Will the newer generations out now that provide real-time traffic data and have hard-disk based data improve their logic and performance enough that these problems are solved?

One final note for embedded systems developers: you don’t get to break the interactive response time rule of 250ms just because you are writing code for an embedded system.

I’m looking for a maintainer that will take the reins of the project from me and give the project some much needed love as time and platforms march on. If interested, drop a comment on this post and we can discuss the possibility.