Triple Bypass 2011

On Saturday I rode the legendary Triple Bypass. Although this is the 23rd year of the event, this was my first year to participate and I completed it in 8h 10m riding time and I actually felt pretty good afterwards.

The weather forecast called for thunderstorms throughout the day along the entire route. But I had a good run of luck and it didn't rain for nearly the entire day save for some sprinkles here and there. This was my biggest worry because once you are soaked your core gets cold, it's very difficult to warm it up again (I've experienced this before and the only thing that can warm me back up again is a big, hot cup of tea in my water bottle).

The Triple Bypass begins in Evergreen, CO (elevation: 7,220ft) and goes over three mountain passes:

1. Juniper Pass, elevation: 11,130ft
2. Loveland Pass, elevation: 11,990 ft
3. Vail Pass, elevation: 10,617 ft

These make for over 10,000 feet of elevation gain through the day. Although I had a riding jacket with me, on both Juniper and Loveland passes, I could see my breath and I was shivering, so I stayed only long enough for a bio break, bananas and water, then I took off again (except for Loveland Pass where there was no aid station). The ride ends in Avon, CO making the total mileage 120 miles (check out the route map).

By the time I made it to Copper Mountain and started the ascent up Vail Pass, I realized that my time was cutting short -- I had paid for a shuttle ride back to my car in Evergreen and it was scheduled to depart Avon at 5pm. So I didn't take it easy going up Vail Pass and I made it to the top at 3:55pm still with about 32 miles to go. After waiting in line for a bio break, and refueling as quickly as I could, I left the top of Vail Pass at 4:09pm. I pushed it all the way down the west side of Vail Pass and continued all the way through Vail, CO. I was lucky enough to hook up with another dude and we wound up taking turns drafting for one another, hammering the entire way. Just beyond Vail but before Beaver Creek, CO, my legs began to give out a bit, so I had to ease up some. At that point I tucked in with a group of four other riders and drafted again. But to keep up with them I had to muster the last ounces of power I had left in my legs to raise my cadence a bit to keep up. As we sailed through Beaver Creek, I was counting down the miles, just hoping that I was going to make it (I hadn't checked the time since I departed Vail Pass). We pounded on to Avon, around the corner to the finish and I stood up to drive it home.

I immediately saw the transportation tent and headed there. Upon checking in, to my surprise, I found that I had actually made it - the bus had not yet departed back to Evergreen! As I checked in I looked at the time and it was 5:11pm. I had covered just over 30 miles in 1 hour! Although it was mostly downhill, it was still a tremendous amount of work after a long day, but I made it! I only had time to grab my bag from the luggage truck, no time for a bio break or even to grab water or food and the bus was off, headed back to Evergreen.

As we crested Vail Pass, all of us on the bus were noting the number of riders that were still coming down the west side of Vail Pass and still climbing up the east side. Just then, the clouds suddenly opened up and it was an utter downpour. One bus companion said, 'Better them than me, dude!' My comment was, 'Oh that sucks bad, I've been there before!' because I have been caught in the same spot in another event twice during a downpour, so I know from experience that that meant downright misery.

After dozing on the bus ride back, I picked up my car, stopped to gobble down a burrito and headed home. My wife was sorry that she and my girls could not be along the route at various locations throughout the day for mental support as they usually are, but I understood and knew ahead of time that they couldn't be there. She asked me if I'd do it again and my response: 'Yes, definitely!' What a ride in the beautiful Colorado Rocky Mountains!

BTW, there were many riders I spoke to during the day who were doing the inaugural Double Triple Bypass. That is, on Saturday you ride 120miles from Evergreen to Avon and then on Sunday you turn around and go back. Maybe I will consider doing that next year, we'll see.

Commercial Vendor Spreads FUD About ActiveMQ

It has come to my attention that a particular commercial integration and messaging vendor is actively spreading FUD about ActiveMQ.

In an official letter that was sent out yesterday, this vendor called out numerous aspects of ActiveMQ, claiming that each is a problem with ActiveMQ and their product 'resolves all of these issues'. Only one of the items mentioned in the list holds any merit. So let's first take a look at the letter and then I will address each item in turn:

Here is the official letter that was sent by the company's media relations:

============================================================
<quote>
From: Fiorano Software
Date: Thu, Jul 7, 2011 at 6:22 PM
Subject: Graduating from ActiveMQ for Enterprise Class Messaging

Dear Joe ,

If you are an ActiveMQ user, you may very likely be experiencing some or all of the following issues:

1. Poor Performance or limitation on speed - particularly for persistent queues and topics.

2. Stability issues or loss of messages, specially with clustering enabled.

2. Poor Documentation - difficult to quickly find what you're looking for or even with paid support you are unable to troubleshoot the problem.

3. Poor Reliability - when a broker goes down, do clients auto-reconnect when the broker comes up again?

4. Inadequate Technical Support - No clear directions/answers from Technical Support - for instance, if you wish to perform memory tuning, do you get clear instructions promptly?

5. Inability to handle "peak loads" - when there's a peak-load condition, does the broker tend to fail?

6. Scaling only with new hardware?

FioranoMQ resolves all of the above issues. With Fiorano, you have the best performance in the industry (for both queues and topics, persistent and non-persistent), responsive and accurate technical support, proven reliability, solid documentation and enterprise-class scalability — all of which adds up to dramatically reduced development and deployment times, with a maintenance cost lower than that of ActiveMQ and other open-source offerings.

To get started, download FioranoMQ now, at http://www.fiorano.com/downloads/login.php?prod=fmq
or contact us via email or phone to get more information.

Regards,
The Fiorano Team
info@fiorano.com
+1-408-354-3210
</quote>
============================================================

Just so you are clear, I did not write this letter. It is an official message sent out by the commercial integration and messaging vendor. Not only has this vendor posted the message on their website:

http://www.fiorano.com/newsletters/ActiveMQ_Issues_July_2011.html

They even tweeted about it:

http://twitter.com/#!/FioranoGlobal/status/89193558032134144

(Yes, I know those are not live URLs. I refuse to provide a live links to be picked up by the Google spider.)

So now let's walk through each point in this message, providing some discussion as we go.

Claim #1: Poor Performance or limitation on speed - This is rather broad statement and I'm sure that's on purpose. The idea when spreading FUD is to be as broad as possible. This way your statements can act as a catch-all for any problems that a user might be experiencing and loop them in based more on emotion rather than fact.

ActiveMQ can certainly provide poor performance if it is not configured correctly. You can do the same with any software that is not configured correctly. From time to time, I have dealt with performance related issues with ActiveMQ on consulting engagements. As I comb through configurations and code to take a look at a situation, many times I find that either the broker or the client are not configured correctly or there's something about the user's code or application design that plays into this scenario. Occasionally a user has asked about providing a better configuration out of the box for ActiveMQ to address a given problem. The answer is that we already do -- ActiveMQ distributions provide a configuration out of the box that should support middle of the road use cases. Problems arise with specific use cases or in a specific environment, etc. There are far, far too many use cases to provide a single configuration that will work with anything anyone might ever dream up.

Claim #2: Stability issues or loss of messages, specially with clustering enabled. - Loss of messages? Really?! Do you think if ActiveMQ actually lost messages that it would be as popular as it is? But blaming the clustering is ingenious for one single reason -- most users don't know enough about the ActiveMQ clustering that they are apt to believe that this claim is true. The only scenario where a user might perceive that messages have gone missing is one where messages get stuck on a particular broker in the cluster. Again, configuration plays a big role in getting clustering set up correctly as does proper application design.

Claim #3: Poor Documentation - This is the only claim that holds any truth, but it's only really half true. The ActiveMQ documentation is certainly lacking. However, the ActiveMQ website does hold a wealth of information. The real problem with it is finding what you need. Although some vendors who provide support for ActiveMQ have attempted to provide improved docs (e.g., notably the documentation for the Fuse Message Broker). This is exactly why Rob, Dejan and I wrote a book about ActiveMQ titled ActiveMQ in Action. We're quite proud of the book because it does provide markedly better documentation for ActiveMQ. If you need better info on ActiveMQ, pick up a copy.

Claim #4: Poor Reliability - when a broker goes down, do clients auto-reconnect when the broker comes up again? - This particular claim makes it clear that this vendor has little to no knowledge of ActiveMQ. This is exactly why the ActiveMQ failover transport was created. In short, the failover transport provides a JMS client automatic reconnection in the event that an ActiveMQ broker goes down or just becomes unreachable. The failover transport is extremely configurable in order to deal with many different scenarios including the ability to delay the initial reconnection, to set a max number of reconnect attempts, to exponentially increase the wait period between attempts and much more. In the ActiveMQ 5.4 release, the failover transport introduced a new feature to provide automatic cluster updates and broker rebalancing to JMS clients. The failover transport is highly powerful and strongly recommended, so I'm surprised that this was overlooked.

Claim #5: Inadequate Technical Support - Based on the vendors listed on the ActiveMQ support page, there are now at least five companies providing support for ActiveMQ. And I even know of a company that provides support which is not listed there, Savoir Technologies. If you are paying for ActiveMQ support and you are not happy, I encourage you to either speak to your vendor about it or find one that works better for you.

Claim #6: Inability to handle "peak loads" - This is a claim against ActiveMQ that I have never once heard from a user. They are essentially asking you if at the time where your business experiences a spike in the amount of messages it is handling, does ActiveMQ fail on you. Yet again, if you are truly experiencing this, then you need to take a serious look at your system design. I have helped many customers successfully address issues of scale through a number of means including some intelligent sharding of JMS client connections across a cluster of ActiveMQ brokers, use of a virtual IP address and even use of a load balancer. If ActiveMQ had a habit of failing for users during peak loads, I would have heard about it at least once.

Claim #7: Scaling only with new hardware? - This claim is similar to claim number 4 and really makes it clear to me that whoever compiled this list is not familiar with ActiveMQ. Did they bother to search the ActiveMQ site? Here is just one page on the site from the FAQ titled How do I configure 10s of 1000s of Queues in a single broker ?. Furthermore, Rob, Dejan and I clearly explain how to scale ActiveMQ both vertically and horizontally in our book. Again, this really depends on the situation and the environment, there is no single silver bullet solution.

Addressing each of these claims was actually quite easy for me to do. And I hope that each of the vendors providing professional consulting services and technical support for ActiveMQ are aware of the tactics being used by this commercial integration and messaging vendor. It sounds to me like ActiveMQ has become a real threat to this vendor's business.

I will leave you with a quote:

"First they ignore you, then they ridicule you, then they fight you, and then you win."
— Mahatma Gandhi

Favorite Rides Around Boulder, Colorado

A couple of the my favorite training rides here in the Boulder valley area include the climb up Flagstaff Mountain and the climb to Ward, CO. Neither of these rides are anything that you can just walk out your front door with zero preparation and expect to enjoy. But with the proper training, I really love being out riding these routes and being outdoors. On Saturday I did Flagstaff Mountain twice and on Sunday I rode to Ward in an effort to train for more difficult upcoming rides in the Rocky Mountains.

I always start at my home in Louisville, CO, so that always adds a sort of warm up of about 10 miles to get to the base of Flagstaff Mountain, so round trip that's 20 miles. Then the climb up Flagstaff which is always great. As you can see in the linked info, there are two parts to the climb. The first half of climb goes to the amphitheater park where there is an amazing lookout over the Boulder valley and that is considered a Category 2 climb. The second half goes up to the top of the mountain and is considered a Category 1 climb. Here is some more information on the Flagstaff climb from the 303cycling.com website (run by my friend Kris Thompson). As Kris has termed it, the climb up Flagstaff is definitely a Boulder classic! I tend to climb to the amphitheater park more often than I go to the top and I always do this climb two or three times when I ride it (climb to the amphiteater, go back down, climb to the amphitheater again, etc.). The second half of the Flagstaff climb is definitely not for the faint at heart, it's a killer. Average grade is a whopping 11% -- 2142ft. of climbing in a little over 5 miles! If you need water on this climb, you need to make sure to stop at Chatauqua Park at the base either on the way up or the way down, because there's nothing up on top but homes.

On a sidenote, there is another ride I do on my mountain bike that is called Super Walker. This ride includes riding to Flagstaff, climbing all the way to the top of Flagstaff, going down the back side to the Walker Ranch trailhead and around the trail, then back up to the top of Flagstaff and all the way down to Chataqua park and back to Louisville, CO. The ride itself takes around four hours if I recall correctly. I did it three times in the Spring right after I got a new mountain bike. But then I experienced a couple of soccer injuries that set back my training and I haven't ridden it since then. I have kinda been waiting to get past the Triple Bypass ride next weekend before I do this one again. The ride to get to Walker Ranch is about 20 miles, so round trip that's 40 miles and the Walker Ranch trail itself is 7 miles. Add in the climbing and elevation gains and you've got one hell of a mountain bike ride. (A neighbor asked me last week if this climb is more difficult on a mountain bike or a road bike. Because of difference in gearing between a road bike and a mountain bike, the Super Walker ride is definitely much more difficult on a mountain bike.)

Another favorite climb is up Lefthand Canyon to Ward, CO, about 20 miles west of Boulder. Ward is a former mining settlement near the Peak-to-Peak Highway (SH 72) with a population of under 200 and a little general store where all the cyclists stop. The general store carries snacks, ice, water and has a port-o-let toilet that is paid for by donations, so drop a couple bucks in the kitty on top of the water cooler when you're there. Just to get to the start of Lefthand Canyon road is about 20 miles, so that's 40 miles round trip. Then up the canyon to Ward is about another 16 miles -- all of which is climbing and that last mile is atrocious! So the distance is not too bad and the grade of the climb is not too bad, but the climb is constant. So the mileage plus the 16 miles of climbing makes for one tough a workout!

I know that many other folks in the area do these rides as well, because I see many people when I'm out. But I tend to do them alone just because it's difficult to work out schedules with others. I like to ride in the morning before the heat kicks in because, once it does in the afternoon, my fluid and food intake really increases. I have also done other rides throughout the area, but these tend to be a couple of my favorites, mainly because they're practically in my back yard.

New Cobb Cycling Saddle

After dealing with numbness that began last season during long rides on my road bike, this week I'm in the process of testing out a new saddle.

My previous saddle (a Selle Italio San Marcos) was causing severe numbness after long rides which obviously is not good. Evidently it wore out to the point that it was a hazard, though it never did fit me that well. After looking around at online many different saddle recommendations in forums, blogs, etc., I couldn't find any consistency anywhere. I saw so many recommendations for so many saddles I didn't know where to start. So I decided to head over to Colorado Multisport to see what they might recommend. I have trusted their recommendations in the past and they have served me well.

After trying a few saddles that didn't thrill me at all, Geoff pulled out a brand that was new to me -- Cobb Cycling. I tried a few models and found that I really liked the Cobb Cycling SHC. Of course it's difficult to determine in a 10 minute period while spinning on a trainer if a saddle is right for you, so I checked out the saddle for the week and I've been riding it ever since. Let me say that after dealing with the previous ill-fitted saddle for so long, it has been a pleasure to ride this saddle.

I learned a few years ago to never, ever go out riding without at least one extra tube (if not two) and air cartridges. Presumably you may need a tube if you experience a flat (patching a road tube is near impossible because they're so thin), the second tube I refer to as a karma tube because I have given away a few to other folks who I come across who are stranded with a flat and no supplies. I prefer to carry air cartridges because they are smaller and so much more reliable than a pump. I never had a good experience with a travel pump, so I tried cartridges and never looked back. So the only question I had left about this new saddle was about a bag to carry the all important tubes and air.

CMS had no recommendations and searching online rendered no recommendations. So I decided to call Cobb Cycling to see what they might recommend, especially since the Cervelo seat post is a tear-drop shape instead of a round shape. I figured I'd speak to a sales rep or a mechanic type who might be able to offer me something. About 30 minutes after leaving a message, surprisingly, John Cobb himself called me back. Although he didn't have a solid recommendation for a specific bag, he offered me a couple tips from his experience in fitting Cobb saddles on Cervelos.

Thanks for taking the time to speak with customers, John!