The technical story of Muxtape


Muxtape is “a minimalist platform for bands to promote their music”. That minimalist approach encompasses more that just aesthetics. It also informs our technical decisions, architecture, and the tools we use. Minimalism isn’t about doing less as much as it is about doing as little as needed. The more specific your goals the easier it is to say yes and no at the right times. Our goal is to connect people with music they love in an environment that respects and encourages that connection. Ultimately, all of our technical decisions align to support that.

Originally Muxtape was written in PHP, about a year ago. PHP is a fantastic language for gradually turning static pages into functional ones in an ad hoc way. However, PHP as a language is a clusterfuck of bad design decisions because it lacks a clear vision. With the new Muxtape we have an amazingly expansive (and yet minimally focused) vision and needed a better foundation to make that happen.

I spent my first 4 years as a web developer using PHP, and it was fun at the time, but as I began to realize how severely inefficient it was I started looking elsewhere. I’d abandoned my traditional computer science background for the web and its greater design possibilities, but because of this I knew there was a better way. PHP developers shouldn’t be ridiculed as much as they often are because, frankly, it enables people without a more rigorous background to accomplish amazingly technical things. This should satisfy nerds but usually is turned into some kind of weak ‘machismo’ thing instead. Anyways, this dissatisfaction began in late 2004 and Ruby on Rails was brand-new, stable, and addressed every limitation I’d confronted with my old homegrown PHP MVC framework. I’ve exclusively done Rails work ever since.

Well, not quite. When Justin and Jakob approached me last fall about becoming part of Muxtape I knew it was what I wanted to work on, but I had some reservations about using a tool I didn’t believe in. He’d already begun in PHP and the plan was to use that. Ultimately the project, the people, and our overall goals were > the desire to use a specific language so I said yes. Also, this would be a perfect opportunity to challenge some of my now deeply-held opinions, which is always fun.

This is how it went: I was getting things done, we had a solid MVC architecture (that obviously grew to ape a lot of Ruby– and Rails-isms), and I was able to keep “reserving judgement” until about a month had passed. But I missed language features, the framework itself, and a culture of sharing well-tested plugins, and was less productive because of their absence.

Then thing that’s so wonderful about using beautiful, appropriate tools is that they become an extension of you, your body, you fingertips, and your mind. They get out of the way and let you directly interact with the problem you are solving. Everyone’s tried to remove a screw without a screwdriver; a task quickly becomes impossible that otherwise would be trivial.

So at RubyConf in Orlando I just decided to rewrite Muxtape in Rails. It took about a day. Over the next few weeks I’d drop hints about Ruby’s terseness, expressiveness, and power: “these 20 lines of PHP == this clear 1 liner in Ruby”. On the weekend I’d keep the Rails version up to date in a fraction of the time. Justin was playing around with Ruby and liking it, and at some point he was convinced. “How long do you think it would take to re-write the site in Rails?” “Umm, well..”, Cmd-T, “localhost:3000”, Enter, “It already is.” Rejoicing, and things have been even better ever since.

The main takeaway I can share from using PHP again after so much time in the Rails world is one of the fundamental principles of computer science and engineering: abstraction as a strategy for dealing with complexity. [SICP videos] All successful large systems do this well: software, societies, the human body, whatever. You need to identify the level of abstraction that is right for your project: too general and you’ll be wasting time solving already-solved problems; too specific and you’ll continuously be looking for ways to get around its limitations.

Ruby’s inheritance, metaprogramming, flexible mixins, and testing culture support a fantastically granular ecosystem of encapsulatable, interchangeable, combinable tools. And Rails has just the right set of features that are common to web applications, allowing you live in your application’s domain, rather than in code that’s been written millions of times before. This is exactly what led Rails and Merb to combine: ultimately they shared the same values and goals. And this lets us accomplish a tremendous amount with as little effort as possible. Never re-solve solved problems, there’s plenty yet-unsolved to work on instead.

In future developer-aimed posts I’ll talk more about some of the specific tools we love using (shout-outs to AWS, Thoughtbot, SoundManager2, NewRelic, AuthLogic, and especially GitHub) and our forthcoming API, which will be an equal citizen with the HTML site.