We have a lotofdata to parse through at 37signals. Our internal stats application, Dash, does the majority of heavy data lifting for us, including reports, application health, CI builds, and much more. Our Campfire bot named Tally happily pings us when a build fails, deploys are fired off, and when Nagios alerts pop up.
I had a problem though: I needed to have all of this data open constantly to absorb it. Either I had to look at the pages on Dash directly or make sure I’m in the reading through messages in the right Campfire room.
I decided it was time to fix this overload. The release of Status Board let me take a step back and understand what pieces of data really mattered to my daily work. As a programmer, I want to answer a few questions:
What’s the on-call load like? Do I need to help out?
I’m really in awe of this. There’s no “pledge $10 or more” and get a prize. There’s no stretch goals. It’s real, the entire production process is documented openly, and you can get the final product today for $20.
There’s something to be said for launching a product and making it happen yourself. Congrats on the launch, Jon. I can’t wait to play Space Dice.
Being remote means that the typical watercooler discussion of the office tends to be reduced to sharing neat links and cute dog photos in our Campfire rooms. This is another reason I enjoy our company meetups: it’s a chance to learn a little more about your coworkers. It’s much more rewarding when we share snippets of daily life, like our current workspace status.
There’re 36 signals now, spread across 6 countries. Since we’re remote, we don’t get to see each other that often. We have meetups 2-3 times a year, but I don’t view them that way: they’re reunions. Our first of 2013 was last week. When you don’t get in-person face time with your coworkers every day, seeing each other makes it special, and it’s much more fun.
Some of my favorite feedback on Basecamp for iPhone has been that the app feels wicked fast, and all native. The app actually is a mix of web and native UI, but it’s difficult to see where the line is drawn. The majority of the content shown in the app is web: From the login screen, to posting a message, and even uploading photos on a comment, that’s all done using UIWebView.
Chrome inspired us that web views could be pushed to the next level, and we wanted to make use of our existing fast, mobile HTML5 views. Going web wasn’t always solid: Some views started as web, went native, and ended up back in a web view. In the end, the app evolved into a simple web content browser with a native feel on top. It’s certainly a compromise, but we’ve been really happy with the hybrid architecture so far.
It’s been over 8 months since our workplace experiment last July, when I got an entire month to buckle down and make an iPhone app. Last Friday, Basecamp landed in the App store. It’s been a long journey of simulator runs, device testing, and app crashes, but I’m convinced that I wouldn’t have been able to ship an iPhone app at all without RubyMotion.
I’ve tried to jump into mobile development a few times over the past few years, and I got stuck every time. I made a Android app in Eclipse, wrapped my head around Lua and Corona SDK, and tried to deal with Objective-C, Xcode, and Interface Builder. Not only did I have to throw out my existing toolset and workflow to break into this world, I had to ramp up with new APIs, frameworks, and more.
RubyMotion came at the perfect time: I wanted to make mobile apps, I didn’t have to throw out my existing workflow, and I could still write Ruby! Here’s what I learned about my experience with RubyMotion from the past few months.
I was on In Beta a while ago, and we talked about the “guilt” that comes with maintaining open source projects. I feel both intensely passionate and exceptionally guilty with how I contribute to open source. I love getting patches into new projects, and the needs of existing projects are demanding.
An open source contributor doesn’t feel guilt as in a crime, but guilt as in time: What is best to spend your yours on? Steve Klabnik has a strategy for dealing with a limited amount of time:
The basic idea is this: you try to minimize the things that are bad, and maximize those that are good.
My strategy has built on Steve’s: minimize the guilt of open source, maximize the passion from open source. I’ve been thinking a lot about what creates passion, and what builds up guilt. It’s also worth considering what destroys passion, and what can tear down guilt.
When I started my on-call shifts, we had pretty little in the way of automation for day-to-day issues. Tasks like SSH’ing into our cluster, starting a Rails console, or doing a deep search through our gigantic mail directories, were either shelved away in someone’s bashrc, history log, or just ingrained into someone’s memory. This pain was also felt by a few other of my fellow programmers, and we started cobbling together a Git repo simply named “37s shell scripts”.
This repo started very innocently: a little Ruby script named console that mapped a product name (basecamp) to a server name inside of our cluster (jobs-03), SSH’d in, and then ran a production Rails console. Several more bash and Ruby scripts started to trickle in as we started to share more of our personal code that we used when on-call. Eventually Sam laid down a foundation of bash scripts and directories borrowed from rbenv, and dubbed it “37”.
I was on