Interview with Stephen Caudill – FatJam

Stephen Caudill of FatJam

With more and more web applications being built by Mac-addicted developers, I thought I’d have a chat with Stephen Caudill over at FatJam. Stephen not only codes his creations on Apple hardware but also relies on it to serve up the applications to the public.

Travis Vocino for The Apple Blog: Hey there Stephen! To me, it feels like the Mac, and specifically the MacBook Pro, is the web developer’s absolute choice when it comes to deploying an environment suited to the work. It definitely hasn’t always been that way though, as you know. What about you? What’s your history with developing for the web on Apple hardware?

Stephen Caudill for FatJam: In August of 2004, I started looking at the programming language Ruby, in response to the philosophy of “developer joy” that Ruby on Rails’ creator, David Heinemeier Hansson was extolling. At the time I was working in Big Java and really just hated it… the job, the tools, the verbosity of the language were all a millstone around my neck and I wanted this golden path that David was describing.

In and amongst the various doctrines of Ruby on Rails was this devout love of the Mac computer that I kept being inundated with. Around the same time Paul Graham penned an essay in which he observed that all the smart hackers he knew were migrating to OSX… That was apparently all the coercion I needed, as I soon found myself exploring a first gen Mac Mini. In retrospect, I guess I was drinking the Koolaid, but it was good Koolaid after the sour taste Windows left in my mouth.

TV: Absolutely. In fact, these days sometimes it’s hard to find a Windows laptop at a developer’s conference — especially the more current spaces like Ruby. So, you’re really hot for Ruby these days?

SC: Definitely. It’s been revolutionary to my entire thought process, let alone my habits as a programmer. A forthcoming project I’m working on, FatJam, is a significantly large Ruby on Rails application.

TV: Can you tell me a little about FatJam?


SC: FatJam is a service that helps musicians meet and collaborate over the internet. We’ve been explained as “ for musicians” and that’s pretty accurate, but only one facet of the application. To elaborate on that bit though; we use data that the user supplies about themselves, objective analysis of their usage habits on the site and automated analysis of finished music they upload to suggest other artists in the community that they’re likely to be compatible with. From there we make it very easy to form bands (the conceptual hub of our interpersonal collaboration), collaborate over distance and promote and distribute your music. We’ve just entered our limited public beta and are due to launch the full service in September.

TV: Another key point I think web developers love about Mac is the shared love for open-source software. How has using OSS technology like the Ruby on Rails framework helped you and your team build a large-scale project like FatJam?

SC: We’ve gotten a lot of benefit from Open Source technologies like Ruby, Ruby on Rails and a plethora of client libraries. Honestly, it would have taken us much longer to develop FatJam if we weren’t standing on the shoulders of these Open Source communities. As a company, we are firm believers in Open Source and we’re making a concerted effort to give something back. We’re starting out by releasing an internal library we use for versioning database records: Acts As Revisable. We’re going to continue to release other extractions from our endeavors as OSS software on github, so keep your eyes on our account.

TV: OK, let’s talk Apple nerdery. What’s your (and perhaps your developers’) setups like as far as software and hardware? How do you utilize them in your day-to-day workflow?

SC: We’re all running MacBook Pro’s as our development machines. Rich Cavanaugh (our senior architect) and I both use TextMate and for our primary development. Our other developer, Rogelio Samour is a recent Mac convert though and a big linux guy, so his primary development is done in Vim and iTerm.

On my rig, apps that run all day every day for me are: Textmate, Terminal, Things (LOVE this app), several instances (for CampFire, GitHub and LightHouse) and Twitteriffic, in addition to the usual suspects… iTunes, iChat, Mail (with all its warts) and Safari. Notable occasional use apps are, Pixelmator (screw you Adobe), NetNewsWire, Skitch, Interarchy and of course FireFox (still the best game in town for debugging JavaScript).

As far as workflow goes, we work in a distributed fashion (I’m in North Florida, Rich is in South Florida and Rogelio is in Northwest Arkansas), so Leopard’s screen sharing capabilities have become vital for us. Using Screen Sharing, we can do pair programming and collaborative debug sessions. It’s almost as good as being in the same room. I also coordinate on a daily basis with my partners in Miami and Greece and consultants in California and less frequently with our board members, most of whom are in New York and London… keeping up with these guys makes my iPhone pretty crucial. Now, admittedly, I could be doing the same stuff on a CrackBerry, but I’d be doing it in much less style and without the super-convenient integration features that the iPhone has with my Mac life.

Apple Xserve

TV: You definitely deliver on Apple nerdery. I love getting to know how people work, what they’re using and how they use it. It speaks a lot to the real-world usefulness of an application when you can experience what someone has built using it. What about the other side — the infrastructure that actually runs and serves up FatJam?

SC: We’re running brand new 8 core Leopard servers with 16GB of RAM apiece. Our staging environment is on a single PPC Xserve running Leopard.

TV: How does using Apple hardware for server infrastructure compare to what most people are used to — generally greybox servers or Dell PowerEdge type stuff? Is the workflow different? Is the deployment easier, more difficult?

SC: Coming from a Java/Sun server background, it honestly feels pretty familiar, albeit minus some warts (and some configurability). I would guess that people who are used to running virtualized Dell PowerEdge’s would have a bit of an adjustment to make. Speaking of which, that’s one thing Apple’s server platform is screaming for: virtualization. It’ll be interesting to see how Parallels Server performs when they’re out of beta… we’ll certainly be looking closely at it.

Deploying to Apple hardware has some specific challenges, but I don’t think they’re any more difficult to deal with than a large scale deployment on any other platform. One thing I’ll give some kudos to the Leopard Server devs for is the great support that Rails enjoys in it’s server environment… mongrel_rails_persist is a super simple utility with a familiar (to a Rails dev) interface that gracefully hooks into and leverages two of my favorite Apple technologies: Launchd and Bonjour. Starting up a Rails app via mongrel_rails_persist automatically creates a launchctl instance for the app and advertises it’s presence over Bonjour, which is in turn integrated into the Apache Web Server interface in Server Admin. It’s all very slick. Beyond the simple elegance of tools like mongrel_rails_persist, it’s just a sound and performant all-around platform for running Ruby based applications from.

Workflow is really why we’re on Mac on the server though, the rest of it is icing. Specifically, we have the ability to access Apple-specific technologies for server side processes. I’m sure you can imagine the benefits that we reap from having a platform exposes sophisticated audio processing systems like QTKit and CoreAudioKit to our server side application.

TV: Plus, just looking at a rack of Xserves should make anyone giddy. In addition to server technology, I dig checking out these fabulous audio production setups that incorporate both Xserves and usually Mac Pros. Being involved with that space, do you think Macs lead the market in audio production? What tools do you or FatJam users utilize on the product end before the work gets to the site?

SC: My personal experience has been that Macs have dominated professional audio production for some time now. More generally though, it seems that many savvy users these days are gravitating toward macs because of their current level of sophistication, and this is true of much of the new breed of digital musicians I know as well. Don’t get me wrong though, I still know a ton of really talented musicians that happen to use Windows.

Apple Pro Audio

The jury is still out as to what tools are going to be prevalent amongst our users. We encourage people to use what they know and we’ll be actively looking at what they do use, so expect more concrete observations on that later. My gut feeling is that we’re going to attract an audience that’s disproportionately Mac-based — say 35% of our overall user base. Platform will affect tool choice to some extent, but I think we’ll see representations of all the usual suspects: Pro Tools, Logic, Acid, Fruity Loops, Reason, Digital Performer, Ableton Live, etc, etc.

My setup is currently oriented around using Reason for beat production and Pro Tools for recording analog sources (though I’m actively trying to move away from Pro Tools). I’ve been starting to tinker with Ableton Live and I love it so far… it’s a really fun, creativity-oriented interface for doing the discovery phase of production in. I’m also looking forward to devoting some time to learning Max/MSP post-beta, which is in a personal sweet spot for me at the intersection of programming and music.

TV: You mentioned that you expect Windows users, of course, but do you consider Apple-specific user apps (like iPhone apps, Dashboard widgets, straight for the desktop) to be crucial to the success of emerging sites like FatJam. I happen to think they’re quickly becoming an integral part. I actually attribute a lot of the success of Twitter to be tied to the early availability of Twitterific. What do you have currently in the works, already deployed or on the to-do list?

SC: With so much of what we consider important available over ever-present networks, it’s silly not to expose that data for consumption, in my opinion. Ubiquity of data is a goal all developers should be working toward these days, or else they’re going to miss the boat. Keeping that in mind, Apple provides some really sweet, fun-to-build-for platforms for getting at and exposing data to users, so it’s a no-brainer for us to get on board with it.

We’re currently putting the finishing touches on native Mac and Windows client apps that pair with the web service suite. We’ve got a couple of widgets in the works for Dashboard as well as Vista and Google Gadgets. As an iPhone user, I tend to think that any application that doesn’t have an iPhone interface is incomplete… so that’s definitely in the works too.

TV: Excellent stuff, Stephen. Endless thanks for sharing your Mac-addiction with me and our readers. We’ll be on the lookout for much more Apple-enabled goodness to come from you in the near future, including the launch of FatJam and your open-source contributions. Good luck!


Comments have been disabled for this post