What’s your overall strategy for transitioning from Think Vitamin Membership to Treehouse?
Writing Treehouse has been a bit trickier than a typical rebranding would be, just because so much of the underlying logic behind how the site works is changing as well. It’s a lot like writing a completely new app, but I’ve also got a ton of user data and other data, like video information, that has to transition with the app. Because of that, we decided against completely rewriting the app, but instead decided to rewrite chunks of it at a time and throw the old code away as we go. There are actually several things that are already rewritten and already in use, like video delivery.
Every app brings new challenges. What makes this app unique from others you’ve worked on in the past?
Probably the biggest unique factor is that we’ve got a lot of plans for the app that we’d love to be somewhat prepared for, so our strategy behind the app isn’t just focused on today, but it’s focused on how we plan to grow Treehouse. I’m usually against thinking too far ahead, but we saw with Think Vitamin Membership that getting too locked into strict rules about how our library is structured can be really limiting, so we’re changing that to build something that should be able to grow with us a bit more easily.
What’s the workflow like between you and Mike Kus?
I don’t know if there’s much of a set workflow between us. Mike and I work pretty well together, I would say, but the time zone difference makes it difficult for us to talk much. For the most part he’s been putting together HTML prototypes of the pages that we’re working on and then as I write the backed code for those pages I put the markup in place. As we get close to launch, though, I have a feeling we’ll have to deal with the time zone differences so that we can work more closely on cleanup and getting details perfect for launch.
Treehouse is being written using Ruby on Rails. What’s the reasoning behind this technology decision?
There wasn’t too much thinking behind it. Rails is just what we do when it comes to writing web apps. I’ve been a Rails developer for 5 years now (I did Java, .NET, and PHP development before that), and I can’t say that anything comes close to Ruby and Rails for me personally in terms of productivity and expressiveness.
That said, we’ve got some upcoming features that will benefit from the evented-ness of Node.js so we’ll be using it in the near future as well. We’re definitely not against using technologies other than Rails, but it has served our purposes really well thus far.
What other notable pieces of software are being used on the front-end and back-end, and why?
It’s mostly the normal stuff. On the front-end, Mike’s been creating his stylesheets with SASS. I’m using CoffeeScript for our front-end scripting and the wonderful MediaElement.js for our video playback. We’re using Modernizr. On the back-end there’s nothing too special going on. One of my major goals on almost any app that I work on is that the back-end is about as boring and reliable as it can possibly be. It’s hard to focus on overall experience if anything on the back-end is breaking, so I’m actually trying to strip away complexity and extra technologies on that side so that we can focus on having a nice, simple core to the app that will take us a long way into the future.