Abstract: Even after a bad experience with client-side MVC, I’m excited to try React (it’s totally different). The Flux pattern detangles client-side spaghetti and makes code which is more reusable and more easily reasoned about.

It was quite a few years ago now that I was tasked to look at the current landscape of JavaScript frameworks and advise as to which one would be useful for an ambitious project. I spent time looking at Backbone, Ember, Angular, and Batman as I have recorded in previous blog posts.

We picked Batman. Sadly, it didn’t work out.

While there was much to commend it, it is no longer used by it’s creators and we’ve moved away from it as well.

Which left me with the question: is client-side MVC a good thing for the kinds of apps I build?


For quite a while I’ve had this on my to-do list:

  • Migrate from Octopress to a pure Jekyll blog

Well, I decided to finally tackle it and it was only a little bit tedious.


Four months ago, I started work on a new product. My coworker and I were talking about strategies we wanted to take on this green field project, and we came across a thought-provoking gist by DHH. I’m not fully aware of the whole origin story of it, but his Tweet indicates it’s a pattern they use in Basecamp to avoid bloating a controller. Instead, they divide actions by domain and have related controllers, ‘co-controllers’, tackle stuff for their respective domain. Makes sense.

So we decided to give it a shot through the whole course of the project to date and I have to say it’s been quite useful. I feel really confident that this project is going to be able to grow more gracefully than previous large scale projects I’ve written. Why? I think there are a few things that contribute to it’s helpfulness, but let’s start with a reminder on some of the pain points large projects have.


Motivation is a big part of programming for me. Why I do what I do…why write programs when there are many other options for what to do with the hours in which I work? And closely related, why write this kind of program vs another kind of program?

The answer for me is easy, but you won’t believe me. It’s trite…it’s expected…and heck, even an HBO Series is making fun of this part of Silicon Valley, but oh well…here goes:

I program computers to make the world a better place.

I’m a devout optimist and in a past life, figuratively speaking, I’ve gone on record at conferences in front of 2000+ people to the same effect. I was being genuine, that’s really who I am. The trick though, is it’s not for any reason you could probably think of…


This last week I was sitting with friends around a campfire and told the following true story. They found it rather interesting, so I figured it was worth retelling. The truth is, my career has been a really weird one…there’s nothing linear about any of the progression through work that I’ve chosen. It has been a truly wild ride, but I’m getting ahead of myself.

Amazon. 1999. It was a totally different company than it is now, though in many ways it’s probably still Day 1. Back then, no one believed in Amazon but us…the insiders, those that had drunk the kool-aid of the best business model for commerce (e-commerce…what a funny name now). There were so many people on “the street” that liked to write these scathing “Amazon will explode in a fiery ball of bankruptcy” stories that even the stalwart had their confidence shaken from time to time. I mean, how many times did I have to explain that I worked for a company that made no profit…sigh. Anyway, from the vantage point of 2014, it’s really easy to think it was a foregone conclusion, but for those of us in the “earlyish” times, it was an exhilirating wild west adventure.