Cycling Season 2011 Event Recap

Last year, I wrote about the cycling season and the events a group of friends and I participated in. This year, we got together at the beginning of the year (again) and mapped out the rides we wanted to do. This time around, however, we were happy to have our wives along for the ride. Thus began yet another epic year!

(Click on the links below to see the associated Garmin data if you’re interested in that type of thing.)

  • Elephant Rock (06/05/2011): This was the first big event of the year. I said last year that I wasn’t planning on doing it two years in a row, but it’s a great training goal and a nice “big ride” experience for the girls.

    The group at Elephant Rock

    The girls rode the metric century version of the ride, and we took a nice even pace with them until the course split. After that, we raced to try and catch them at the last aid station. We didn’t quite make it there in time (they had been waiting for about an hour when we showed up), but we had a great, albeit hot, ride in to the finish together.

    Posing at E-Rock

  • Denver Century Ride (06/12/2011): This ride began at Invesco Field (now Sports Authority Stadium) right by my house in downtown Denver. We again rode a century taking it easy until the course split away from the metric option. It was a nice ride, but we had some criticisms.

    Kevin and Leslie climbing Lookout Mountain

    The route was a bit rough with traffic and the jersey and T-shirt weren’t very attractive (I joked that I was even embarrassed to wear it to bed!) However, they took our feedback seriously and showed up this year with a brand new jersey (one that looks pretty darn good) and a completely re-designed route. I’m already registered for the 2012 version and I can’t wait!
  • Mount Evans (07/10/2011): This wasn’t an organized ride, but it was likely the most difficult ride I’ve ever done. The final ride was almost 130 miles and well over 12,000ft. of elevation gain. Mt. Evans is the highest paved road in the US; so high, in fact, that my Garmin stopped being accurate up above around 12,000ft. (it shows our max elevation as around 13,000ft. when it was easily a thousand feet more).

    The climb to Mt. Evans beings

    We were hailed on and blown all over the place on the climb up, and one of the guys in our group even snapped his rear derailleur right off his bike! (Luckily, we found a car driving down from the mountain with a bike rack that was gracious enough to drive him back into Denver) When we finally finished the ride, I wasn’t sure exactly what to think or say. It was simultaneously the most physically painful and wonderful thing I’ve tried and I can’t wait to do it again!
  • Copper Triangle (08/06/2011): This was year two of the outstanding Copper Triangle Ride.

    Finishing at Copper

    This time around, both the fellas I typically ride with got to participate (last year it was just two of us) and we all had a great time! Our three families got a cabin right in the middle of the Copper Mountain Village and we all had a blast just enjoying each other’s company and relaxing before and after the ride. I don’t think we’ll do it again next year (three years in a row is pushing it just a bit), but we’ll definitely be back soon.

    The Crew

  • Dear Creek Century (08/21/2011): This event labels itself as the “hardest century ride in the US” Considering how difficult Evans was, I went into this ride thinking I’d be able to skate through it. I was very wrong. My first mistake was riding a fair amount during the week leading up to the event. I put in around 60 miles before even starting the ride. Beyond that, I didn’t hydrate properly and ate very poorly during the week. In short, I didn’t take it seriously at all and it definitely cost me. After about 50 miles, I started feeling sluggish. After the finish, I got pretty sick and got home to see I had dropped about 10 pounds of water weight during the ride. Not good.

    Feeling bad at Deer Creek finish

    I’m not sure if I’m going to do this ride again, but if I do I will definitely take it seriously.
  • Tour de Fat (09/10/2011): This year, I rode a B-Cycle while Amber pulled Ryker in the Chariot.

    Killing it at the Tour de Fat

    It was just the three of us this year, but we had a great time and enjoyed ourselves (as usual).

    Ryker and I at the Tour de Fat

    The tradition of cycling with at least 1000 other folks in a giant parade topped off with a beer or two after the ride is something I look forward to every year.

    Amber and Ryker at Tour de Fat

  • Other Rides: Alongside the rides here, the girls did the Venus de Miles ride while the boys volunteered.

    The girls at Venus de Miles

    Beyond that, there were numerous rides in Golden, Boulder (Jamestown, Sugarloaf, Flagstaff, Nederland), Colorado Springs, Castle Rock, Monument, Lyons (Oscar Blues is a fantastic destination), and the list goes on. I also had a great time riding with my beautiful wife multiple times during the year including climbing Lookout Mountain, riding to Golden and just getting coffee in the early spring. Often, riding is about enjoying the scenery and talking with interesting people and she’s definitely the most interesting person I know.

    Getting coffee on a ride

I’m not sure we can seriously top 2011 and I’m not looking to try, really. So, here’s to 2011 and having fun, doing hard stuff, drinking good beer and making worthwhile relationships even more so. 2012, you have some big shoes to fill!



Software is Harder than it Looks

Last night, I was thinking about the game Words with Friends for the iPhone. I haven’t played, but I know a lot of people who love it. It’s basically an online version of Scrabble with a twist. I think the maximum time a player can take to finish a turn is a whole week. Games take a while to finish. Most of the people I know who play are participating in a handful of games at once. The genius of this game, and what makes it perfect for mobile devices like the iPhone, is that you can play it on your own time. On the bus and have a few minutes? No problem … that’s the perfect time to play your turn.

On the surface, this game seems super simple. “It’s basically Scrabble but online.” The concept sounds so easy and obvious that the implementation is taken for granted. People don’t understand how complex it is because it just works.

I don’t have any first hand knowledge of the game, but as simple and obvious as it seems, the implementation is likely a lot more difficult than that. Aside from the actual app that you download from the App Store, there is a whole infrastructure running to make sure games and players are kept in sync. Again, I don’t know the folks who built it but I’ll bet they spent a lot of time and effort making it work as well as it does. And I’ll bet they are constantly working on it, making it better and keeping it running smoothly.

Another example is an application I did work on: The TWCableTV application for the iPad. This application also seems simple. The first version just streams live video. That’s it. Since the first release, we’ve added Remote DVR and other features, but the vast majority of the time it’s used to simply watch TV.

What might be surprising is only a small handful (3-4) of people actually worked on the app that gets installed on the iPad. At least 7-10 people worked on the services that talk directly to the iPad, a bunch more to test the app, yet another 2-3 on making sure the television streams were setup and continue to function properly, a whole host of people working in our data centers to keep the lights on, and lots and lots of previous work by other teams across the company creating ways to programmatically retrieve things like a billing data and validate usernames / passwords. Add a few lawyers in the mix to keep us from violating our contractual agreements and the number of folks who had a hand in the application, directly or indirectly, is at least 50 and likely more in the realm of a hundred.

That’s a lot of people for an application that just plays TV.

My point is that ideas for software are comparatively easy to come up with. The implementation of ideas is the hard part. We definitely weren’t the first to think “it would be cool to let people watch live TV on an iPad”. However, we were the first to implement it. And it was hard.

Software is usually like that.

Often, when a person I just met learns I worked on an iPad application, they’ll say something like “I have a great idea for an iPad application that [insert great idea here]” That’s similar to saying “I have a great idea for a skateboard that hovers or a device that converts matter to energy, transports it, and then converts it back to matter”.

The amazing thing about the titans of the computer industry is not that they had great ideas but that they actually implemented the ideas. Steve Jobs didn’t just think of the iPhone. He built it. He hired the talented team of engineers, designers, testers, and even lawyers to make it all work.

It takes work. It takes tenacity. It’s, well … just like everything else great in life I suppose.

It’s hard.

See Dart … Java?

About a month ago, Google made headlines when an email describing ambitious plans to re-create JavaScript was leaked to the web. This email created quite a stir and spawned numerous debates ranging from the hubris of Google in trying to single-handedly replace such a ubiquitous staple of the web to the possible merits of Google’s decision on a technical level and the kinds of exciting innovations that could occur.

While I personally didn’t feel great about Google’s actions, I decided to reserve my public judgement for the time when Google actually released the language. Two days ago, that finally happened. So, let’s take a look:

main() {
  print('Hello, Dart!');

Ummm … ok. This chunk of code looks similar to JavaScript, so that’s not all bad. However, I was really expecting something more groundbreaking in terms of syntax. While I don’t loath semi-colons as line endings (you have to have something, right?) the new trend these days is to exclude them. Specifically coming from a JVM perspective Scala, Groovy and Clojure, three of the most popular Java alternatives, are happily semi-colonless. Also, as Google has deep Python roots, I expected they’d create something with a more “modern” syntax. But that’s ok … I can live with semi-colons. Let’s dig a bit through the Dart sample source code (can currently be found on Dart’s Google code page).

Check out (I’ve removed the comments for brevity):

class BiIterator<E> {
  ObservableValue<int> currentIndex;

  List<E> list;

  BiIterator(this.list, [List<ChangeListener> oldListeners = null]): currentIndex = new ObservableValue<int>(0) {
    if (oldListeners != null) {
      currentIndex.listeners = oldListeners;
  E next() {
    if (currentIndex.value < list.length - 1) {
      currentIndex.value += 1;
    return list[currentIndex.value];

  E get current() {
    return list[currentIndex.value];

  E previous() {
    if (currentIndex.value > 0) {
      currentIndex.value -= 1;
    return list[currentIndex.value];

  void jumpToValue(E val) {
    for (int i = 0; i < list.length; i++) {
      if (list[i] === val) {
        currentIndex.value = i;

When I first saw this code, I instantly recognized a very similar syntax to Java 5 generics. Eerily similar, in fact. As powerful as Java generics are, not too many people like the syntax. To port what many consider to be kruft to a brand new language is an odd choice.

Another interesting thing about this code is the inclusion of strict comparison operators (i.e. ‘===’ and ‘!==’, see line 31 for an example). While the use of these operators is instantly recognizable to those of us who regularly use JavaScript, I think it a very odd decision to include these operators in a brand new language. They are, essentially, a JavaScript oddity that often confuses people when they first learn the language.

So far, things aren’t looking great for Dart.

There is hope, however: Dart has great support for concurrency. It implements a version of the Actor model (see for details) placing code into Web Workers behind the abstraction. Concurrency is rarely easy and the Actor model is a great way to abstract that kind of complexity away from the developer.

So, let’s take a look at a basic Actor (Dart’s interface is called an Isolate):

class Printer extends Isolate {
  main() {
    port.receive((message, replyTo) {
      if (message == null) port.close();
      else print(message);

main() {
  new Printer().spawn().then((port) {
    for (var message in ['Hello', 'from', 'other', 'isolate']) {

Huh. It doesn’t look terrible, but I’ve been doing a lot of Scala development recently and Scala also happens to have actors. Let’s take a quick look at how Scala might implement the above code:

import scala.actors.Actor._ 
val portActor = actor {
    while (true) {
        receive {
            case msg => println(msg)
List("Hello", "from", "other", "actor").foreach( word => portActor ! word)

Granted: these are both contrived examples. However, look at the Scala version. It’s doing some tricks like importing a static Actor but it is still, at least to my eyes, much more readable and elegant than the Dart version. While it’s nice to have an actor-based model for client development, I feel like Dart’s falls short in comparison to Scala’s state of the art implementation. Again, considering this is a brand new language, this is puzzling.

Finally, Dart itself can either be executed in a virtual machine or transpiled to JavaScript for execution in a browser. Since most browsers outside of Chrome won’t have much support for a native Dart VM in the near future, let’s take a look at Dart’s transpiling overhead. This is probably all you need: Dart’s ‘Hello World’ application transpiled to over 17,000 lines of JavaScript. Wow. To be fair, this overhead has to do with setting up Dart’s optional typing system and other niceties of the language which is more akin to including a library. As such, this isn’t an apples-to-apples comparison with JavaScript itself or something like CoffeeScript which transpiles in a more one-to-one fashion.

But still. Wow.

So, at least for now, it seems like Dart is a bit of a snooze. As much as I was disappointed in Google with not being more open about the development of Dart, I was also excited in seeing something that would simply blow away JavaScript and set the stage for something ground-breaking (maybe something like “ScalaScript”). Dart is not that. Core Java developers will likely feel right at home with Dart, but I can’t see the huge community of client-side JavaScript engineers being very excited about this.

Dart, I am disappoint.