FiveRuns Blog

Welcome to this week’s Rails TakeFive interview, our weekly discussion about Ruby on Rails with noted developers from throughout our community. This week, Mike Subelsky, co-founder of OtherInbox, hacker, Ruby on Rails developer, SproutCore neophyte, and improv theater director based in Baltimore, Maryland joins us to share his thoughts on Ruby + Rails.

FiveRuns: Welcome, Mike! And thanks for taking the time! Let’s start by talking about GitHub. Now that the Rails repository has been moved over, can you talk a little bit about the benefits of Github and how SCM and agile development go hand-in-hand?

Mike Subelsky: Agile development is greatly enhanced by elegant tools that enhance collaboration and reduce mental friction, and that’s how we view SCM. Knowing you have every past revision of your code available, and being able to create experimental branches means it’s very easy to try new techniques and throw away what doesn’t work. We keep our code trunk pristine, with all tests always passing, and we deploy that code daily to an alpha server meant to host the bleeding edge version of our app. Our users can even login to that server if they want to try out the latest code. We also always have a tagged branch of our code representing the stable release currently in production. If we need to make a bug fix in between releases, we always have that tagged branch ready for commits, while the rest of the team can continue contributing to trunk. If a major piece of work is in progress, it goes into its own separate branch until its ready to be merged into the trunk.

We use Subversion and Git simultaneously, so we’re in a good position to compare the two approaches. We started OtherInbox before GitHub came to the fore, and are still using Subversion for our server code. We decided to experiment with Git and GitHub while rewriting the browser client as a SproutCore application. The learning curve has been a bit steeper than expected, but I am definitely a Git believer. We have people working on this in three different time zones, all able to share code branches and patches very easily, pushing and pulling code all along.

FiveRuns: Bruce likes to talk about “backpacking” through other languages. What others have you dabbled in and/or are you learning right now? How have these travels impacted your work in Ruby? Your overall approach?

Mike Subelsky: Most web development requires you to dabble in Javascript, but this summer marked my conversion from Javascript dilettante to Javascript veteran. It turns out there is a beautiful, functional, prototypal language wrapped inside Javascript. I discovered this for myself while building a full-blown desktop app for OtherInbox that runs inside the browser. In order to make it perform quickly and reliably, I had to learn to think in Javascript, using functional programming techniques, and not think like a Ruby guy writing Javascript.

This has impacted my Ruby work by teaching me how to better use closures and functional programming techniques to full advantage. As one example, in several places in our app, we pass around Javascript functions intended for lazy execution, whenever an AJAX call succeeds. That’s a pretty common technique these days, but in order to take full advantage of it, I had to make subtle but powerful change in my thinking that will reverberate across all the languages I use.

FiveRuns: Let’s switch gears a little and talk about Merb – they are all about being agnostic—ORM-agnostic, JavaScript library agnostic, and template language agnostic – what does this mean? And what does it mean to be “thread-safe”? Is there promise in implementing Merb alongside of Rails, say, for processing?

Mike Subelsky: I love Merb and think there are many applications where people are using Rails but should be using Merb, because they don’t need the entire Rails stack, or because they are doing something too custom and unconventional and end up having to fight with Rails. The agnosticism simply means that Merb leaves more decisions up to you, though there are still plenty of conventions available if you want them in Merb—more and other gems.

Thread-safety means one process can perform multiple tasks concurrently, via threads, without one thread disrupting another. This can yield much more efficiency in many applications. We are considering rewriting a key part of our application as a separate Merb app to run alongside the main Rails app. Right now, we have a lightweight read-only API that the SproutCore client uses to get updates from the server. The code for this uses almost no Rails conventions (we make raw SQL calls and marshal the results into JSON ourselves) so there’s no reason we have to use Rails. If we serve it up via Merb, we’ll get a performance boost and more efficient use of memory, at the cost of extra complexity.

FiveRuns: Switching to the deployment side of things, Amazon + Rails seems to be a prevalent choice right now for developers looking to quickly deploy their apps in the cloud. Can you talk a little bit about the benefits and challenges here?

Mike Subelsky: We are 100% hosted on Amazon Web Services (AWS), except for our outbound SMTP service, and we’ll probably move that onto AWS soon. There’s an immediate business benefit from the greatly reduced costs compared to conventional providers, and how easy it is to launch new instances when scaling horizontally, but to me the biggest benefits accrue to our productivity and imagination. We can fire up servers for experimental reasons, setup copies of our production environment to try out new features, and so on, which make our development processes extremely agile, because servers are a commodity for us, not some precious, limiting resource.

It can be difficult to manage a cloud of servers, though. If you are planning on launching an app of any moderate scale you will end up having to write a lot of tools to launch and provision servers, monitor their health, and consolidate their logs. As our development team grows, we’re outgrowing the home-brew approach I outlined at the Lone Star Ruby Conference. We’re switching our server management over to RightScale, though there are many other services I would recommend. I think they have the best Ruby gem out there for talking to SQS, S3, and EC2, called Right-AWS.

We use S3 for message storage and it has been very reliable.

FiveRuns: Obie Fernandez’s startup Hashrocket, which has been blogged about extensively, is all about being ultra-productive in 3 days. What are your own tips around, to paraphrase Obie and 37Signals, getting real—on steroids?

Mike Subelsky: This may be very trendy to say, but as a developer, I’ve really learned to appreciate the value of having great test coverage. Our app has a lot of moving parts and a very high availability and integrity requirement. We simply cannot and will not ever lose anyone’s email, and we know our customers won’t tolerate even a moment of time without being able to access their email, so the tests help prevent us from ever putting unreliable code into production. It takes extra time to write them, but having a well-tested app means we spend an order of magnitude less time on debugging and troubleshooting, and more time building new features. It also helps us sleep better at night. This summer I made some major schema changes to our app, and I was able to implement them with a minimum of pain because the tests were there to back me up.

As a manager, I always try to keep in mind that our people and what they know are the real platform for our company, not Ruby, Rails, SproutCore, AWS, or any other particular technology choice you could name. I try hard not to dictate the answers to things, or mandate the use of any tool or practice, because often what the team comes up with organically is much better than what I would think of. Except the testing thing, that’s an organizational standard we have that I’m a pretty strong proponent of.

I don’t hear enough about code review. I’d like to figure out a way to inject more code review into our processes in a way that would be agile and not onerous. I think a lot of common bugs could be killed by requiring multiple programmer eyes on production code, and I think it would help developers on a complex project get familiar with more of the codebase.

Mike Subelsky built a variety of Ruby-on-Rails applications as a freelance developer for two years before co-founding OtherInbox with Austin entrepreneur Josh Baer. He is the author of random-data, an open-source Ruby gem used for prototyping new Ruby applications, and wrote two recipes in the recently-released book Advanced Rails Recipes. Prior to becoming a full-time Rails hacker, he served as a U.S. Navy information warfare officer with overseas assignments around the world, including counterterrorism operations during Operation ENDURING FREEDOM. He has also worked as a civilian cybersecurity analyst for the Department of Defense and private industry. He holds Bachelor and Master of Information Systems Management degrees from Carnegie Mellon University, and is a Certified Information Systems Security Professional. He blogs about open-source technologies such as Ruby on Rails and SproutCore at subelsky.com.