Brian Beck’s Text Adventure

The Point and Those Who Miss It

Mon, 03 Oct 2011 16:25:00 -0700

A lot has been said about Ted’s successful troll and the several responses that seem to miss the point—including mine.

To that I say: if a point is never properly made, can one truly miss it?

There are two reasons people are benchmarking Fibonacci in response to Ted’s post:

Ted himself benchmarked it and concluded it was slow. This is wrong—it’s comparatively fast. But nobody thinks this was his entire point. It wasn’t. Let’s move on.
Because it’s an order of magnitude faster, every single one of Ted’s clients in the ab benchmark would receive a response before even a single client of an equivalent Python or Ruby service, regardless of their level of concurrency. Even though each request blocked the next, it still would have far better throughput than your typical Python or Ruby deployment. (This of course depends on which language runtime the deployment uses, that’s why I’m stressing “typical.”) This has everything to do with the speed of V8, and not Node’s event-based I/O.

So even the demonstration of a blocked request pipeline was rather poor. Still want to blame anyone for missing the point?

People are excited about Node because you can handle a large number of requests before even beginning to think about parallelization. If you start with a blazing fast runtime and request handler, you can put off parallelization until it matters. And it may never matter, because most web services are I/O-bound. Node also makes asynchronous programming very approachable.

Taken out of context, Node’s claim that “nothing blocks” can indeed be confusing. And I’m not defending the claim that “less-than-expert programmers are able to develop fast systems.” But Ted deliberately took “nothing blocks” out of context. Node’s site is very clear that it’s talking about blocking I/O. For CPU-intensive tasks, the Unix way is alive and well.

Running multiple Node processes to improve concurrency is not anti-Unix. It is in fact a widely-accepted approach, albeit one users are left to discover themselves with Node. Some people dismissed projects that serve this purpose, claiming that the introduction of third-party add-ons somehow invalidates the entire approach. Maybe we should stop using mod_python and mod_wsgi then, eh?

Perhaps there are some less-than-expert programmers out there shooting themselves in the foot with Node and failing spectacularly to scale. But so far they seem to be mythical.

If you want to read an article that does make a great point about Node’s concurrency—and concurrency in general—Anthony Fejes got it right.

Node.js Cures Cancer

Sun, 02 Oct 2011 19:57:00 -0700

I apologize for the title. But it’s no less accurate than this embarassing, poorly-reasoned article by Ted Dziuba. It’s flamebait, but I couldn’t resist. Sigh…here we go.

First, Ted takes issue with this claim on Node’s homepage:

Almost no function in Node directly performs I/O, so the process never blocks. Because nothing blocks, less-than-expert programmers are able to develop fast systems.

He then gives an example of a blocking function as some kind of weird disproof.

Here’s a fun fact: every function call that does CPU work also blocks. This function, which calculates the n’th Fibonacci number, will block the current thread of execution because it’s using the CPU.
function fibonacci(n) {
  if (n < 2)
    return 1;
  else
    return fibonacci(n-2) + fibonacci(n-1);
}

I think Ted might be confused about what exactly Node is. Node is not a language or a framework. Node is a small set of JavaScript modules bundled with a JavaScript runtime. “Almost no function in Node directly performs I/O” means that most functions included in Node’s built-in modules are asynchronous—they return as soon as possible and a callback handles the result. It doesn’t mean that any JavaScript function you write won’t block. It’s still JavaScript with normal semantics.

The first thing Ted does to disprove this claim is fire up Node’s single-threaded HTTP server in a single process and calculate fibonacci(40) on every request. Here’s his conclusion when the request takes 5.6 seconds to complete:

5 second response time. Cool. So we all know JavaScript isn’t a terribly fast language, but why is this such an indictment?

I don’t know Ted, why is it? Maybe let’s try the same thing in Python and Ruby so we can see just how terribly fast other languages are by comparison. For reference, Ted’s example takes 8 seconds on my machine.

Python:

from wsgiref.util import setup_testing_defaults
from wsgiref.simple_server import make_server

def fibonacci(n):
    if n < 2:
        return 1
    else:
        return fibonacci(n-2) + fibonacci(n-1)

def fibonacci_app(environ, start_response):
    status = '200 OK'
    headers = [('Content-Type', 'text/plain')]
    start_response(status, headers)
    return [str(fibonacci(40))]

make_server('', 1337, fibonacci_app).serve_forever()

Result:

$ time curl http://localhost:1337/
165580141
real    1m48.732s
user    0m0.009s
sys     0m0.007s

1 minute 48 second response time. Cool. This is the fastest it got after multiple runs, by the way. The results are the same for any Python web server because, surprise, it’s measuring the speed of Python. Just like Ted’s example is measuring the speed of V8.

Ruby:

require 'rubygems'
require 'mongrel'

def fibonnaci(n)
    if n < 2
        1
    else
        fibonnaci(n - 2) + fibonnaci(n - 1)
    end
end

class FibonacciHandler < Mongrel::HttpHandler
   def process(request, response)
     response.start(200) do |head,out|
       head["Content-Type"] = "text/plain"
       out.write(fibonnaci(40))
     end
   end
end

h = Mongrel::HttpServer.new("127.0.0.1", "1337")
h.register("/", FibonacciHandler.new)
h.run.join

Result:

$ time curl http://localhost:1337/
165580141
real    3m18.429s
user    0m0.011s
sys     0m0.009s

3 minute 18 second response time. Cool.

What exactly did he expect to happen in this case? We wrote a function that does block, and told Node to call it on every request. How could Node’s claim that “almost no function in Node directly performs I/O, so the process never blocks” possibly have any bearing at all on this result?

Maybe the claim that “less-than-expert programmers are able to develop fast systems” is misleading, but so far it’s actually sounding almost reasonable. Getting the response time down to 5 seconds was effortless, after all…

Ted then discredits Node for disobeying “the Unix way.” This indeed sounds pretty lamentable until you realize he just means that Node doesn’t ship with a CGI module, which is true.

How odd, then, that Node’s lack of built-in CGI support hasn’t caused an exodus en masse. People still seem to be getting along just fine without it. And even if they weren’t, nothing is stopping anybody from developing a CGI module for Node. So why haven’t they?

One reason could be that Node’s built-in web server can easily outperform Apache—even in high-concurrency tests. This is apparently dismissible since it violates “the Unix way” of separation of responsibility. All the people who are getting stuff done with Node should just drop what they’re doing, because according to Ted they’re conceptually impure.

Never mind that most developers will never need the scale that loosely coupled services would provide.

Conceptually, this is how any web application architecture that’s not cancer still works today: you have a web server program that’s job is to accept incoming requests, parse them, and figure out the appropriate action to take. That can be either serving a static file, running a CGI script, proxying the connection somewhere else, whatever. The point is that the HTTP server isn’t the same entity doing the application work.

Look, I totally agree with this. From an architectural standpoint, it’s the way to go. I’m sure someday, Node will get its own equivalent of WSGI for Python and Rack for Ruby. That will be an exciting time. But nobody seems to be in a hurry to get there. [Update: Except for Connect and Strata.]

Finally, Ted concludes that Node was just doomed from the start, since it’s written in JavaScript:

if (typeof my_var !== "undefined" && my_var !== null) {
  // you idiots put Rasmus Lerdorf to shame
}

What is this I don’t even…

Never mind that this code would be even uglier in, say, Python—presumably a non-cancerous language:

try:
    my_var
except NameError:
    pass
else:
    if my_var is not None:
        # Ted needs better examples
        ...

Some people like JavaScript now, Ted. We even have options for people who don’t.

Look, I’m not that invested in Node, and I don’t have any interest in using its web server for anything. That’s just not what I use it for. But even I could spot the flaws in Ted’s childish article. Please don’t support his inflammatory trash just because you don’t like JavaScript.

For a much more reasonable take on Node and its performance claims, I recommend this post by Alex Payne of Twitter.

Discuss this post on Hacker News.

[Update: I’ve posted a brief followup.]

So, you want to use require() in the browser...

Sun, 25 Sep 2011 17:43:00 -0700

You’ve written a bunch of JavaScript or CoffeeScript running on Node, which has helped you organize your code into modules, develop a test suite in any of numerous styles, experiment in a decent REPL, and take advantage of useful libraries.

Now you want to deploy that code to the final frontier—the web browser.

You have a couple options. A couple dozen, actually. Here are just the libraries that were easy to find, in order of GitHub popularity. The bars represent their number of watchers:

As you can see, quite a few developers have approached this problem. There are several ways to interpret this:

Maybe it’s an easy problem to solve, since so many people have opted to roll their own.
Maybe it’s hard to solve, since so many people evidently decided that the others got it wrong.
Maybe each person has legitimately different requirements.
Maybe it’s just “opinionated”, like web frameworks.

Downloading code on-demand: related, but different.

Admittedly, several of these libraries are trying to solve a related, but different problem: downloading the required modules on-demand (usually asynchronously via AJAX).

While an interesting problem to tackle, I think using this scheme in production is a bit misguided. Compiling your entire application into a single JavaScript file shouldn’t be a problem for anyone. Whose minified and compressed code is bigger than the size of a few JPEGs? (Hint: not Facebook’s, Grooveshark’s, or Pandora’s.) At most you should need a tiny loader script that grabs a couple of large, self-contained blobs of code when the page loads.

Loading dozens of small modules on demand is just going to result in more HTTP requests and worse compression. The simpler alternative is to already have the modules available, and just run them and return their exports on-demand. Thus, you have one file and no asynchrony.

Deploying the same code to production that you run in development: the actual problem.

The larger and more compelling use-case that many of these libraries tackle is running the same code in the browser that you wrote for Node. The foremost obstacle here just happens to be the organization of code into CommonJS-like modules. Even if you avoid using Node’s core modules and globals like process and __filename, the use of require for your own modules still must be addressed.

That’s where these libraries come in.

I happen to have implemented yet another one of these libraries for my own purposes, so I’m familiar with the problem. In my next blog post, I’ll explain what requirements the most popular libraries satisfy, describe where they fall short, and demonstrate some improvements we could make to truly call them production-ready.

Discuss this post on Hacker News.

adminbrowse: Fancier changelist columns in Django's admin site

Thu, 02 Dec 2010 18:12:00 -0800

I just released a new reusable Django app called django-adminbrowse on GitHub. This was factored out of a Django project I’ve been working on for a while.

Ever wish it was easier to get around in the Django admin? Maybe you’ve deployed the admin site as a management tool for some less technical users? This project lets you easily spiff up changelist pages to include better text and markup. I’ve been using it in production for a while and it’s been a welcome improvement.

In the screenshot (click to zoom), you’ll notice:

URL fields become clickable links.
Foreign key fields link to the change form for the corresponding object.
Related objects get a link to their changelist page, filtered appropriately.

There are a few more features, but the most powerful is that the code is very easily extensible. If you ever wanted to include a custom markup in your changelist columns, this makes it really easy.

See the README or use Python’s help() for starters. More advanced documentation is in progress.

Enjoy!

The Numbers: Day 70

Sat, 23 Oct 2010 15:44:00 -0700

More updates are coming! Erin and I will be taking a break from our trip next week in order to celebrate our birthday—October 30 for the both of us—back in Cleveland with friends and family. We’ll be in town from Wednesday, October 27 until Tuesday, November 2, when we’ll most likely continue our journey from Eugene, Oregon.

Miles since Cleveland: ~2,000
Cycling days: 44
Leisure days: 26
Rainy days: 4
Nights camped: 11
Nights in motels: 22½
Nights couchsurfed: 36½

[We half-camped on two occasions—the night in Oberlin, which accounts for half a motel, and in someone’s yard, which I’ll call “campsurfing” and accounts for half a couchsurf.]

Days 12-14: Milwaukee

Wed, 29 Sep 2010 16:20:00 -0700

The ferry arrived in Milwaukee just as the sun was setting. As we hadn’t yet arranged for a place to spend the night, we debated skipping the city altogether and riding 20 miles south to find a camping spot. A light rain started to fall, so after sending some futile last-minute CouchSurfing requests, we booked a room at the Ramada Inn downtown.

We showered at the hotel, and, having just spent several hours on a ferry instead of on bikes, were feeling energetic and ready to experience some Milwaukee nightlife. I found a great thread on the Milwaukee sub-reddit and made a list of everything we should check out during our stay. One bar on the list, The Safe House, was just around the corner.

The Safe House is a spy-themed bar. There’s a doorman to whom you whisper the password; a bookcase then opens to grant access to the bar. If you don’t know the password, you must suffer a hazing ritual; to your further embarassment, a live video feed of the entranceway is broadcast on every TV in the bar.

Inside is essentially a playground for adults. All the drinks are spy-themed, and many come with souvenir pint glasses (Erin took home the Spy’s Demise glass). There are secret rooms, crazy mirrors, and telephone booths into which you can enter codes to play recordings. One of several bars is tended by a magician, who we watched perform card tricks, swallow a balloon, and generally entertain the audience.

Upstairs was a couple enjoying some drinks by themselves. They overheard us talking about our trip and we made introductions and small talk. They were Milwaukee natives, yet were also first-timers at The Safe House. We decided to all go out for dinner (and more drinks), having just arrived at the bar after the kitchen closed for the night. Unfortunately, we were in too much of a hurry to find the secret exit.

We walked over a small bridge to Rock Bottom Brewery with our new friends, Tony and Allyssa. The food and conversation were both great. Apparently, they didn’t get many opportunities to hang out with other couples, so they greatly enjoyed our company. We checked out a few more downtown bars until I showed my hand by ordering a gin & tonic. This usually means I’ve had enough to drink for the night, so Tony dropped us off at the hotel.

Judging by the list we made of things to do in Milwaukee, it was clear we’d be staying at least another day. So while Tony and Allyssa were at work, we checked off the items on our list.

We relaxed in the grass along the coast, near the science center and other attractions. Then we made our way south, checking out the Pabst mansion, touring the Lakefront brewery, and grabbing a bite to eat at Alterra Coffee on the way.

As the sun went down, we hopped from bar to bar on Kinnikinnic Avenue, where some of the more hip establishments are located. Eventually, Tony got home from work and invited us to stay for the night. When Allyssa joined us, we enjoyed more drinks and some dinner at Cafe Centraal, which was supposedly named the most bike-friendly restaurant/bar in Milwaukee.

To conclude the night, we drove to a more residential area where Tony remembered finding a speakeasy called At Random. We eventually arrived, and were the only patrons there to keep the older couple running the place busy. The drink list was similar to that of the Velvet Tango Room, but the atmosphere was terribly dated (and obviously, the Velvet Tango Room wouldn’t have been empty). I took it easy (due in part to the $10 cocktails) and ordered a large drink that included ice cream.

On the way out of town in the morning, we rode over to an Einstein Bros. Bagels for breakfast. Conveniently, Allyssa was working there at the time, and Tony also stopped in for a visit. We enjoyed a good breakfast, said our goodbyes, and hopped on the highway heading south…

The Numbers: Day 34

Fri, 17 Sep 2010 16:51:33 -0700

Some quick data while I work on writing the backlog of our trip…

Miles since Cleveland: ~1,000
Cycling days: 22
Leisure days: 12
Rainy days: 1
Nights camped: 6½
Nights in motels: 8½
Nights couchsurfed: 19

Days 5-12: Ann Arbor to Milwaukee

Fri, 17 Sep 2010 15:26:00 -0700

We made some changes to our route in Ann Arbor. Our plan was to pass through Kalamazoo, Michigan and Gary, Indiana on our way to Chicago. But we looked into taking a ferry across Lake Michigan when we heard that Gary might be a bit hazardous to our health and morale. So after enjoying the Lake Folk show and spending the night in Ann Arbor, we headed out for Lansing and Grand Rapids.

We set up camp in the wilderness of the Pinckney State Recreation Area. The isolated areas were all overgrown, so our only option was to clear a spot in a covered circle of trees and bushes.

We didn’t get much sleep that night. It was hot, the road was very close, and we encountered our first critter. In the middle of the night, Erin spotted the silhouette of something big passing by. It started sniffing and snorting when it detected us, but luckily didn’t feel the need to further challenge these terrified campers or browse our food selection.

The next day, we sent out some CouchSurfing requests to various folks living northwest of Lansing. We saw some nice parts of the city as we passed through, but our only stop was for some groceries at a Meijer, where we learned that our new CouchSurfing hosts were just a few miles down the road.

Trever and Natalee were excited to host us—their first CouchSurfers—at their apartment in Grand Ledge. We went out to dinner at Cancun Mexican Grill, where I ordered what turned out to be the most impressive looking Mexican dish I’ve ever seen (and very tasty, too). We talked about our new route and the ferry, and our hosts recommended we check out Grand Haven—apparently, the place where everyone in Michigan wants to be. After dinner, Trever and Natalee took us to the rock ledges that gave Grand Ledge its name. It was a long and tricky walk in the dark, so the many bike headlights we brought came in handy.

We said our goodbyes in the morning and began the 55-mile ride to Grand Rapids. Erin was experiencing pain in her Achilles tendon by lunch time, so we applied some ointment and bandages and tried to take it easy. The sun was just going down as we rolled into Grand Rapids, so we started calling motels and contacting CouchSurfers from a park downtown, with no immediate success. Across the street was a restaurant with great reviews called One Trick Pony. We decided to mull over our lodging situation over dinner.

I ordered the pecan-crusted salmon at One Trick Pony, which was the best meal I’d had on the trip so far. When it came time for dessert, the waitress gave it to us on the house, on account of the exciting adventure we were on! To make the evening even better, I got a call from a CouchSurfer less than an hour after contacting her. Ama said she’d be happy to host us at her duplex a few minutes from downtown, despite being tired and overworked during our visit.

Before leaving the restaurant, I noticed that a lot of people were checking into a place called the Lyon Street Water Slide on foursquare. This struck me as a bit strange, since it was getting pretty late. So I asked around, and learned that there was indeed a water slide set up on a nearby street. In fact, the entire downhill portion of the road was closed off just for this special two-day event, and people were waiting for up to five hours for a free ride! Interesting…

When it came time to leave in the morning, it became apparent that Erin’s tendons needed a day of rest. So, while we were visiting the water slide just to take a peek, we made the decision to take the day off and get in line!

As expected, the slide—rather, the line for it—took up most of our day. We ended up waiting about four hours for a ride, but it was worth the wait. Others seemed to agree, since it appeared that nearly everyone in Grand Rapids was there. It was a slow day followed by a relaxing evening.

In the morning we left for Grand Haven, figuring we’d kill some time before the ferry left from Muskegon. When we rolled across the bridge into town, it became apparent why Trever and Natalee had spoken highly of it. There were beautiful beaches and boardwalks, and clean, bike-friendly streets. A sign informed us that Grand Haven is known as “Coast Guard City, USA.” It felt a lot like Newport, Rhode Island, where I grew up.

Figuring it would be appropriate to order some seafood for lunch, we sat down outdoors at The Grand, a nice downtown restaurant. Our waiter, Gavin, was incredibly friendly and talkative. He was very interested in our trip and excited to tell us all about Grand Haven—he even recommended staying overnight, so we’d have time to absorb more of the city.

Still planning to catch the ferry that night, we spent the afternoon at the beach swimming and building sand castles. Lake Michigan is so big that it was nearly indistinguishable from a beach on the ocean.

While walking back to our bikes, we noticed that the beach had camping spots for tents and trailers, and it appeared to be quite a popular activity that night. For the low price of $29, we couldn’t pass it up. So we took Gavin’s advice and spent the night, setting up our tent right on the beach. We showered and then rode our bikes to the closest movie theater to catch Piranha 3D, which is just what you’d expect. The theater employees let us in for free with no reason given.

In the morning we got the best breakfast Grand Haven has to offer at the Morning Star Cafe. A quick stop at the bike shop around the corner and we were ready for our last ride in Michigan.

It didn’t take us long to reach Muskegon, but it did take a little too much effort to find the Lake Express ferry. The tickets were also far too expensive, but at this point we had no choice. As the only cyclists, we got to board first, followed by the cars. We settled in next to a power outlet so we could charge our phones, then explored the deck as the ferry left the harbor.

Upon departing the harbor at an average pace, it soon became apparent why the Lake Express is called a high-speed ferry. That thing really moves! Standing on the deck is only reasonable for a few minutes before the wind becomes so strong that it’s hard to move. We took some pictures and returned to our seats until our arrival in Milwaukee…

Days 1-4: Cleveland to Ann Arbor

Wed, 18 Aug 2010 18:24:00 -0700

Friends and family met us at Lakewood Park on Sunday to send us off—two days later than we originally planned.

We finally hit the road a little after 3pm, but stopped at Century Cycles in Rocky River for some last minute supplies.

The ride to Oberlin was slow, but we made it. It took us quite a few miles to get used to the weight of the bikes—each carrying about 50 pounds.

There weren’t many people on campus at the time, so we just picked up some Chinese food and started scouting out a good spot to set up for the night. We settled on a hidden clearing next to a chapel and unloaded our gear.

That turned out to be a terrible idea. For one thing, the bells tolled every hour—even at 2am. And the benches around the corner turned out to be a popular late-night hangout for students looking to drink on the down-low. After the second rowdy group left, I gave in and looked up the closest motel. At 3am, we quickly packed it up and rode to the motel in the dark of the night. This turned out to be my favorite few miles of riding so far. The air was cool, there was absolutely nobody on the road, and we could only see as far as the reach of our headlights.

After showers and breakfast at the motel on Monday, we left for Fremont, Ohio.

Unfortunately, we didn’t discover the North Coast Inland Trail until we arrived in Fremont, so the ride could have been faster and easier than it was. While looking for a place to camp, we found the trail and met a new friend: John, a 26-year-old mechanical engineer contracting on a project in Fremont. After sending us off with suggested camping locations, he caught up to us and offered his place for the night. We gladly accepted and ended up having a great time.

The next morning we hopped on the trail and enjoyed another day of perfect weather. We ran into Elmore Cycle & Fitness along the trail and stopped in for some tune-ups on Erin’s bike. The head mechanic, Mike, was interested in the gear we chose to pack and eagerly offered some helpful advice (such as picking up 12oz of heat antifreeze at a gas station to replace the 32oz of denatured alcohol we’re carrying for cooking). Mike posts photos of passing tourers and his ultralight setups on his Flickr stream (photos of us coming soon).

We eventually reached and promptly exited Toledo, which had terrible roads for cycling and the worst drivers. Everyone had some stupid comment for us—none of them demonstrating any knowledge of the actual rules of the road, of course. So we rode until we reached Temperance, Michigan, and found the perfect stealth camping spot behind some trees.

This morning was the earliest we’ve started yet, waking up at 7:00 to make breakfast and pack up, and hitting the road by 9:00. After 15 miles, we took a short break in Dundee, which was home to every imaginable fast-food chain on just a half-mile stretch, but also a cute and clean downtown area.

The remainder of the trip was spent riding directly north on some very sparsely populated roads, singing songs and taking pictures along the way to cure our boredom.

We rolled into Ann Arbor a little after 1pm and met up with our friends, Erin and Bryan (funny, right?) at their apartment. We’re about to leave for the bar to see their band Lake Folk perform. We’ll be taking advantage of these comfy couches tonight and leaving for Kalamazoo after lunch tomorrow!

Bike Adventure Gear, Part 1: Camping

Thu, 05 Aug 2010 23:12:00 -0700

Over the next few days, I’ll be posting all the gear Erin and I are bringing on our bike trip to Seattle. I’m a determined comparison shopper and bargain hunter, so every last item here was meticulously researched, and we got great deals on almost everything. Maybe these posts will save you some time if you’re planning a similar adventure!

Today’s post: our camping gear.

We’ll be spending our nights in The North Face’s Big Fat Frog 2-person tent:

One of the highest rated tents on REI, I bought it there during their big sale earlier this summer, and saved some money by purchasing the footprint from Rock/Creek.

Since our bodies will likely be aching after riding for hours every day, we each have our own REI Trekker 1.75 self-inflating sleeping pad. To save on weight and space, we’re only bringing one sleeping bag, replacing the other with a Cocooon ripstop silk liner. We can always share the sleeping bag if necessary, so I’m betting that this tradeoff is going to be worthwhile.

We’ll be cooking our meals on the road with the Mini Trianga 28-T backpacking stove:

This tiny stove burns denatured alcohol and comes with a pot and pan. While we’ll mostly be using this just to boil water, I’m looking forward to learning how to cook meals as quickly and efficiently as possible with this limited equipment. CampSaver.com had the best deal on this stove.

And why bring along some normal household utensils when we can use the Guyot Designs MicroBites and the Snow Peak titanium spork? If there’s an everyday item that has a fancy backpacking equivalent, I had to have it. :)

For campsite lighting we have the Black Diamond Orbit lantern and the Mammut TR1 headlamp:

Both are super bright. Unfortunately, Steve’s dog chewed up the lantern, which does in fact resemble a dog toy. It still works fine - a testament to its durability, at least. Oregon Mountain Community had the best deal on the headlamp.

Other miscellanous items…

A couple MSR PackTowl compact and lightweight towels.
A firesteel, so I can struggle to ignite things until Erin gets frustrated and uses her lighter.
This coffee pot - Erin’s vice, not mine. You’re responsible for carrying this one, Erin!
Plates, bowls, stove fuel, soap, and a clothesline.

Think I’m missing something? Help me out in the comments!

In my next post, I’ll write about the most important gear - our bikes and accessories.

The State of the Weblog

Fri, 30 Jul 2010 15:37:48 -0700

My media server is down, so some content may be missing (pictures, linked documents), and I’m using a temporary theme.

My last day of work in Cleveland is one week from today. The week after that I’ll be riding my bicycle to Seattle with my girlfriend, camping and couchsurfing on the way. It’ll take us about five weeks, and I’ll be posting frequent updates here. Hopefully our cycling adventures capture your interest as much as code and Cleveland musings.

Follow if it is adventure that you seek…

Serious Games talk at Case

Mon, 12 Apr 2010 18:49:00 -0700

I’ll be giving a talk on serious games at the next meeting of the CWRU Hacker Society on Wednesday, April 14th, 8pm in Glennan 313.

The scope will be much wider than my previous talks on Unit Testing Achievements. A rough outline:

What are serious games?
How can they be applied to software?
How do they affect behavior?
What’s out there now?
What’s left to be explored?

See you there!

Achievement Unlocked

Wed, 24 Feb 2010 09:08:00 -0800

[This post is adapted from a lightning talk I gave at the Testing in Python Birds-of-a-Feather session at PyCon 2010.]

One of those most fun advancements in video games in recent years is not about the improved graphics, or playing with hundreds of people at once. It’s that games have evolved beyond points. While a good point system may be a good indicator of a player’s abilities, it doesn’t tell the whole story. Many modern games, even if they don’t involve points, have introduced the concept of achievements. Achievements are awarded for completing game-specific challenges—essentially, they are merit badges.

Examples

From Team Fortress 2:

From The Beatles: Rock Band:

From foursquare:

These add another level of fun to the games in question. I think it’s about time we stole this idea for software testing.

Testing Achievements

To make this happen, I announced an Achievements plugin for nose, the Python test runner. Here are a few highlights:

Night Shift
Make a failing test suite pass between midnight and 5am.

Punctuality
Make a failing test suite pass at 9am.

Coffee Break
The test suite takes between 5 and 15 minutes to run.

Happy Ending
All tests in the suite fail…except the last.

My God, It’s Full of Dots
The suite has at least 2,001 passing tests.

Sausage Fingers
At least two distinct syntax errors are raised by the test suite.

Are You Mocking Me?
Import a mocking library.

100% Code Coverage, Level x
100% of at least 2^(x+7) statements are executed.

You can view the full list of achievements here. Many of these are working right now.

Next Steps

Announcing unlocked achievements on Twitter or IRC, global or project-specific leaderboards, pluggable achievement expansion packs…

Share your ideas in the comments!

Phaeton by Kevin Cornell & Randy Jones. This typeface really...

Fri, 22 Jan 2010 08:03:23 -0800

Phaeton by Kevin Cornell & Randy Jones. This typeface really stood out in ILT’s favorites of 2009. Love it!

Emergency party at my place

Tue, 10 Nov 2009 21:56:00 -0800

Dear Reader,

You knew keeping this blog in your RSS reader would pay off one day, didn’t you? You did, right?

Well now you can reap the rewards, my friend. There comes a time.

You are invited over to my house on Friday, November 13 for a party and performances by several talented musicians.

There will be a full bar. Also an actual, physical bar. Celebrated Clevelander Marta “Martender” Lapczynski will be bartending.

We’re getting started at 10 PM; music at 11. Everything is free.

Here’s your invitation with the details:

See you there, Internet lovelies!

“The Cleveland Tourism Board gave me 14 million dollars...

Fri, 17 Apr 2009 07:55:19 -0700

“The Cleveland Tourism Board gave me 14 million dollars about 8 months ago to make a promotional video to bring people to Cleveland. As usual, I waited till the last minute and I ended up having to shoot and edit it in about an hour yesterday afternoon.” — bishopvids

Cleveland Code Co-op meeting on Sunday

Thu, 19 Feb 2009 12:55:53 -0800

The fifth meeting of the Cleveland Code Co-op will commence this Sunday, February 22, from 13:00 till 19:00. We’re expecting more participants than usual, and likely projects so far include:

redit, a text editor in Ruby
80sheep, an ADC (peer-to-peer) client in Python
a Python tutorial for beginners
your wildest software fantasies

This month’s meeting will take place in the EECS student lounge at Case Western Reserve University, which is located in the Glennan Building. Directions are located on the wiki. You can also join us on IRC in #C3 on irc.freenode.net.

Food and drinks will be provided! Hope to see you there.

Python instance descriptors: when class descriptors aren't dynamic enough

Thu, 29 Jan 2009 09:41:00 -0800

Python descriptors are great for customizing access to attributes on a class or instance. They are a big win for tasks like mapping Python objects to data from non-Python sources (such as SQL), since mapped attributes will need to be encoded/decoded and connected to other attributes in some way.

Below is a very simple descriptor; as you can see, accessing it from both the class and the instance invoke the descriptor protocol:

class Test(object):
    pass

class Descriptor(object):
    def __get__(self, instance, owner):
        return "Hello, world."

>>> Test.x = Descriptor()
>>> Test.x
'Hello, world.'
>>> test = Test()
>>> test.x
'Hello, world.'

However, in order to add descriptors to an object, they must be added to the object’s class. Descriptors added to an instance do not invoke the descriptor protocol:

>>> test.y = Descriptor()
>>> test.y
<__main__.Descriptor object at 0x16fe810>

This means that creating an instance with dynamic (determined at runtime) descriptors requires either the heavy-handed approach of generating a class just for that object (since adding descriptors to its class will add them to all other instances of the class), or the ad-hoc approach of redefining getattr/setattr behavior (essentially re-implementing your own descriptor protocol).

It turns out the latter approach is not as messy as it first sounds. Below is a class that enables “instance descriptors”:

class InstanceDescriptorMixin(object):
    def __getattribute__(self, name):
        value = object.__getattribute__(self, name)
        if hasattr(value, '__get__'):
            value = value.__get__(self, self.__class__)
        return value

    def __setattr__(self, name, value):
        try:
            obj = object.__getattribute__(self, name)
        except AttributeError:
            pass
        else:
            if hasattr(obj, '__set__'):
                return obj.__set__(self, value)
        return object.__setattr__(self, name, value)

class Test(InstanceDescriptorMixin):
    pass

>>> test = Test()
>>> test.z = Descriptor()
>>> test.z
'Hello, world.'

"The purpose of syntax highlighting is to turn your code into a map, not The Jimi Hendrix Experience."

Tue, 06 Jan 2009 12:29:26 -0800

“The purpose of syntax highlighting is to turn your code into a map, not The Jimi Hendrix Experience.”

geopy sprint at December C³ meeting

Sat, 13 Dec 2008 20:51:15 -0800

Today (Sunday) the third meeting of the Cleveland Code Co-op will be held from 1pm to 7pm at Gypsy Beans & Bakery. We’ll be focusing on geopy again, continuing our sprint goals from last time. All are welcome to attend. You can join us via IRC in #c3 on irc.freenode.net.