The Technology Behind Tag Better

I promised you the details on how we built Tag Better, so here we go. This is what I used to build the back-end bits. You’ll have to pester Chris or Alex to get the front-end details.

h2. Sinatra

Technically, it’s a Rails Rumble. Read between the lines of the rules and you’ll see it’s really a *Rack* Rumble. And so I went with my favorite for prototyping, Sinatra.

Happily, Sinatra had my back the whole time. I never came across anything that stumped me. Further, I didn’t pay any taxes for ceremony I don’t need.

Verdict: perfect tool for the job.

h2. Passenger

I hadn’t used Passenger much before this weekend. I’m pretty happy spooling up app processes in a terminal and watching the logs scroll past. localhost:3000 is my friend.

However, I’m an outlier in this regard. My teammates aren’t as interested in lower-level bits as I am, so I figured that using Passenger is the best bet to help them get the app up and running locally.

The benefit that I didn’t realize we’d get from this is running the same stack locally as on the production server. Besides some virtual host wrangling that Passenger Pane saved me from locally, getting the app up and running was painless.

Verdict: I am quite likely to keep tolerate Apache for that Passenger goodness, especially when I am the operations guy.

h2. Sprinkle + passenger_stack

The moment that I realized we’d have to set up our own server instance was one of brief, abject terror. I knew this could easily expand to fill *a lot* more of my time than I wanted. Luckily, I was wrong.

Ben Schwartz’s passenger_stack helped me get our Linode slice up far faster than I would have been able to by hand. I cloned his repo, tweaked it to our needs (disabled MySQL, eventually added a CouchDB recipe) and ran it on our server. Several minutes later, we had a working server. Pretty awesome.

passenger_stack uses Sprinkle, which isn’t getting as much play in the server configuration space as Puppet and Chef. Sprinkle does seem really well suited to standing up apps on a few servers. We might want to step up to something heftier once we had more servers, but Sprinkle and passenger_stack are simple to understand and don’t require any supporting infrastructure to use.

Verdict: Not too primitive, not too involved; just right.

h2. CouchDB

When I’m building any app that relies on an API as its primary data source, caching API response data is forefront on my mind. Serving the data locally, rather than making a request every time, means the app feels more responsive. An added benefit is not upsetting the upstream data provider.

I’ve built apps like this that use MySQL as a cache and it just never felt right. I’ve been tinkering with CouchDB and Tokyo Cabinet/Tyrant lately. I decided to go with CouchDB for this one because of the excellent CouchDBX, which makes it easier for those who don’t even know what Erlang is to use CouchDB.

CouchDB ended up working pretty well. While we haven’t really leaned into it, it didn’t present any challenges while I was developing. Using CouchRest with Sinatra worked just fine.

Verdict: It just worked, which is exactly what I needed.

h2. Skipping traditional TDD

OK, so maybe only Jared Diamond would consider this a technology. But skipping the writing of tests to drive my design was pretty helpful. Consider Kent Beck’s flight metaphor. Doing a Rails Rumble is just like the taxi-ing phase. Or a minimum valuable product. Either way, you want to make a small investment towards validating an idea.

Notice I said _traditional_ TDD. To tell the truth, I did write a sniff test script after I had the basic app working. But it wasn’t an xUnit-style test. It’s just a shell script that bangs on the app with fixed parameters. I do have to manually inspect it to make sure nothing is blowing up. What I’m really automating here is the pain of typing out Curl commands.

Verdict: worked great for the original purposes, but I’ll probably add a proper test suite as one of the first post-contest enhancements


So that’s what I think helped make our project go off pretty well. Really, what they did was *help me get stuff done and then get out of the way*. Isn’t that the best kind of tool?

Classy Web Development with Sinatra

An admission: I didn’t really do as many *awesome* things during the Bush administration that I would have liked to. So, now that we have a new president, I’m going to start off right by showing you something awesome.

While it may seem like I’ve had my head up in the clouds of physical computing, urbanism and monads, I’ve been nose down in something else. I’m super-excited to tell you, I’ve just finished the first two episodes of “Classy Web Development with Sinatra“, a screencast for the Pragmatic Programmers.

h2. The Particulars

Sinatra is a great subject. As I point out in the first episode, I think it’s very special in how it puts the smallest possible language over HTTP. Taken with the fun of building your own framework up from scratch, Sinatra apps are a ton of fun to write. Further, Sinatra really shines when you want to write micro-apps or services. Building an API for your Rails app by standing a Sinatra app up next to it to serve the API is a great approach for many applications.

If you’ve known me for a while, you probably know I had at one point aspired to write a book for the Pragmatic bookshelf. That didn’t work out (for the better, I think), but I still wanted to produce _something_ to get the good word out there. I’ve enjoyed the screencast format from the beginning, and I enjoy teaching people interactively, so the format seemed well suited to me. Plus, I’ve always loved the sound of keys clacking in a screencast. Now you can hear *my* keys!

h2. Shout-outs

Lately, Ryan Tomayko has been absolutely kicking ass with his contributions to Sinatra and Rack. He was kind enough to review the script before we recorded and even put out a maintenance release so that we wouldn’t have to talk around a couple bugs that snuck into the latest release. The finished product is much better for his feedback and guidance.

From the beginning, Mike Clark has been a great mentor and guide through the process of producing a screencast. He helped me write to the beginner’s perspective and avoid speaking in a monotone. Throughout the process, he’s been more helpful and supportive than I could have ever imagined. Needless to say, he’s the foundation that all the goodness of the Pragmatic Screencasts series is built upon.

h2. I want to go to there

Go give the sampler a look, then buy the episodes! If you have questions, drop a message in the forum. And don’t forget to grab the example app and service off GitHub.

Birdland, Forgetting, Libertarianism, Hoboken

Hello, 2009! Let’s try a slightly different format. Starting it out with ““Birdland” by Weather Report”:http://www.youtube.com/watch?v=pqashW66D7o&feature=related can’t hurt.

Shawn Blanc says “the best todo software lets us forget”:http://shawnblanc.net/2009/thingsday/. I absolutely agree. Shawn also pointed out “Rules For My Unborn Son”:http://rulesformyunbornson.tumblr.com/, which is indeed a great set of guidelines on being a mensch. A choice “JFK quote from therein on optimism”:http://rulesformyunbornson.tumblr.com/post/61173128/the-american-by-nature-is-optimistic-he-is.

Provocateurs “Zed Shaw”:http://www.zedshaw.com/blog/2009-01-08.html and “Giles Bowkett”:http://gilesbowkett.blogspot.com/2009/01/fundamental-problem-with-libertarianism.html are in much better form when they are tilting against libertarianism. Which isn’t to say that they’re right or libertarianism is wrong. They’re just better at tilting against social abstractions.

If you’ve ever looked at writing tiny web apps or services with Sinatra, you’re probably interested in “what’s proposed on the Hoboken branch”:http://gist.github.com/38605. “Ryan Tomayko”:http://tomayko.com/ has great taste, I tell you.