• The days are long but the decades are short. A great writeup from Sam Altman with a good smattering of advice on a whole bunch of topics.

• Ready for Rain: Why Seattleites Crave the End of Summer. I actually read this over the winter, but it’s a beautiful article that really made me miss the PNW.

• How to Downsize a Transport Network. Never in my life did I think that I’d use the phrase “gripping, exciting article about wheelbarrows”, but that’s exactly what this is.

• “Why is software so expensive?”. Something that I thought I already knew the answer to, but which I’d never thought about like this.

Discussion welcome.

Many people shudder at the privacy implications of this. Personally, I assume my cell phone providers have very similar data on hand already, if not with quite as much accuracy and precision.

I’ve now started looking through the data to see how my movements have changed over time. One really stark difference between living in Seattle and living in Stockholm is my average furthest distance — on any given day how many miles away from home do I make it?

Check it out. This a map of my movements in Seattle on Thursday, September 29, 2011:

That was a fairly normal Thursday on which I went downtown for work, went back home, and then went out for drinks on Capitol Hill. One cool thing about having this data is that it helps spark your memory — I now remember that exact evening, who I was with, and some of the conversations that we were having. Location is an excellent trigger for that sort of thing.

Anyway, you can see that the furthest I made it from home is 4.3 miles. Most of my days in Seattle seem to have a furthest distance figure of 4 to 6 miles.

Now, here’s a map of my movements in Stockholm on this Wednesday, September 26, 2012:

Again, a fairly normal Wednesday. I walked to the office, went to a show after work, and then walked home. The difference, though, is that the furthest I made it from home is only 0.997 miles.

One mile instead of five miles. That’s a pretty significant difference. What makes it especially interesting for me is that I lived pretty centrally in Seattle and had a very enviable commute (15 minutes on the bus followed by 5 minutes on a bike).

The same holds in Stockholm. I live fairly centrally and have a similarly short commute. But the difference is that in Stockholm a short commute is a 15-minute walk, rather than a 15-minute bus ride. This is the kind of thing you can enable when you build for density, and it’s the kind of thing I hope to see become more possible in Seattle as well.

Some caveats here:

1. Neither of these days were climbing days for me, so I didn’t make it to the climbing gym. If I look at climbing days, my distance from home in Seattle is about 6 miles. In Stockholm it’s either 2 or 4 miles depending on which gym. That’s definitely a less pronounced difference, but I think the theme still holds.

2. Some neighborhoods in Seattle are fairly dense. On my stereotypical lazy Sundays spent in and around Wallingford, I often didn’t make it even 2 miles from home. I could walk to restaurants, the coffee shop, the beer shop and the pub without going even half a mile. But unlike in Stockholm, that half a mile isn’t dense enough to have many offices where a software engineer might be able to find employment. Rather, I had to go downtown for work.

3. While I have a bunch of data points about myself and my movements, this whole thing is — at its heart — quite anecdotal. I’m sure there are people in Seattle who don’t usually have to go more than a mile from home. And I know there are people in Stockholm who live further out and have to commute a few miles.

Anyway, just some data that I thought was interesting.

1. Don’t block the UI thread, ever.
2. Only access and modify the UI from the UI thread itself.

The Android Dev Guide goes into some detail about this. The usual solutions in Java are to:

• Spawn a thread that does work and then invoke View.post with a Runnable that manipulates the UI.
• Implement and run an AsyncTask that does work in doInBackground, and then manipulates the UI in onPostExecute.

As you can see, both these solutions — though they are the bread and butter of Android development — are pretty verbose and unwieldy:

I prefer AsyncTask, which has better semantics, but implementing one AsyncTask after another quickly becomes tedious. Same with writing line after line of Runnable boilerplate.

Enter Scala, using either the sbt Android plugin or my Maven-based solution.

The first step is to create an implicit conversion from a function to a Runnable, which can then be passed to View.post or runOnUiThread. Once we’ve done that, it’s simple to use spawn from scala.concurrent.ops to do background work.

Here’s a fully functional example:

This is so much nicer than the Java alternative. Instead of up to ten lines of boilerplate for each background task, we end up with just the spawn and runOnUiThread.

If you’re waiting for that final push to switch over to Scala for your Android development, I highly recommend the sbt plugin for Android. Take a look at its brilliant Getting Started guide, which will have you up and running in just a few minutes.

The way this works, you can just plug your USB peripherals and your network cord into the Thunderbolt display. Then, whenever you dock your MacBook Pro, you just connect the single Thunderbolt cable and the display, USB devices, and network all work magically.

It’s much more convenient than doing the daily morning dance of plugging four or five things into your MacBook, and it’s the closest thing we have to a good MacBook Pro dock.

Well, that’s the theory anyway. In reality, while the USB works fairly decently, the ethernet connection dropped out on day one, and I haven’t been able to get it back since. Until today.

Here are the final steps that worked for me. Hopefully somebody else can save a bit of time with this:

1. With the Thunderbolt display connected, visit the Network tab in System Preferences. If you see Display Ethernet and/or Display FireWire in the list of network interfaces, select each one and use the minus (-) button at the bottom of the list to remove it.

   For me, Display FireWire was listed, but Display Ethernet was not. I’ve heard of others having strange symptoms with neither or both listed.

2. Unplug the Thunderbolt display. This will not work if you keep the display plugged in while doing the next few steps. Trust me, I tried it.

3. sudo rm /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist

4. Restart your MacBook Pro and log back in. Once you’ve logged in, connect your Thunderbolt display again.

5. Visit the Network tab in System Preferences again. If you see Display Ethernet and Display FireWire listed, you’re all good. Otherwise, click the plus (+) button at the bottom of the list of network interfaces.

   From the Interface dropdown, select the interface you have missing and click Create. If you have both interfaces missing like I did, you will have to repeat this step for the other interface.

After all that, everything seems to be working smoothly for me.

Anyway, Stockholm decided to take to the streets to protest ACTA today. Here are a few photos of the fairly well-attended event that I managed to snap on my phone:

There’s quite a few gyms in the area, and the closest ones to downtown are run by Klättercentret and Klätterverket. The Klättercentret in Solna is the place I was really looking forward to visiting. But since it’s closed for renovation until next week, I instead found myself at the Klättercentret in Telefonplan.

What I found there was a style of setting I had never seen before on such a scale — instead of being marked by tape, problems are based on holds that are of the same color and style.

Here’s a photo of the place by Helena Wahlman at the Swedish photo blog:

Look closely and you’ll see that there’s pretty much no tape on the wall. For example, neither of the holds the guy in the photo is using are marked. Instead, he knows to use them because they are yellow.

What little tape there is just marks the start and end of a problem. The color of the tape is what specifies the problem’s approximate grade:

At the moment I’m not sure if this is a regional thing or just a Klättercentret thing.

One thing I can tell you is that, at first, I was very, very confused! I’d expected a different grading system, but when I first walked up to the wall in Telefonplan, I seriously had no idea what was going on. Of course, I tried to figure out what other people were doing, but I’m not used to looking at the color of holds.

Until I realized what was up, I just figured everyone was improvising their own problems. Also, at the time I hadn’t realized that the vast majority of the bouldering area at Telefonplan was on a different floor. Those things combined to make me wonder if I was in some special kind of hell where bouldering was just a joke.

What finally made it click for me is when I found a long overhanging problem comprised entirely of bright orange holds. Once I saw that, everything clicked into place and I could suddenly see all the problems everywhere! There were quite a few excellent problems, and overall it was a great session.

Thoughts on this style of setting:

• Grading. The approximate grading is something I can appreciate. It lets you walk up to a problem and have a general idea of what it’s going to be like, but without forming preconceptions of whether or not you can handle it. Moreover, it reflects the reality of a gym problem where grading is inexact and approximate, based on the perception of a single setter.

• Visibility. Once you get used to the idea, identifying holds based on hold color isn’t that different from tape color. You do have the same problem as with tape where similar adjacent colors can be difficult to pick apart. In some cases, you have an additional problem where heavily-chalked holds become difficult to identify.

• Style. Each problem definitely takes on a certain style based on the type of hold used. I imagine this could be really handy when you want to train a specific skill. If you pick a problem that starts with a sloper, it’s going to be full of slopers that came from the same set. Same with crimps, or jugs or pockets or what-have-you. As an example, I’ve set something similar before using a single set of bright pink crimps, and it was great for training crimps.

All that said, I’m still not sure about this system. In a way, I’m sure it encourages creativity, as limits and constraints tend to do.

Yet, the fact remains — with a given set of holds, you can express more problems and permutations if you can mix holds of different colors. Then again, the point of setting is to create challenging, climbable problems, not just to mathematically optimize your theoretical problem space.

Today, prompted by a discussion on what I should name some new object, Chris asked:

Isn’t all coding about being too clever?

I think that is a conception that many laypeople and beginning programmers have — that we should try to be clever. Seasoned engineers will know that being clever can be one of the worst sins.

Here was my response, paraphrased:

The goal is to write the minimal code that (a) gets the job done, (b) doesn’t break, and (c) is understandable and maintainable by other people.

“Clever” often meets the first requirement, can sometimes meet the second, and always fails miserably at the third — which is actually the most important one. All things equal, I’d often rather have a broken system that I can understand than a rat’s nest of code that happens to work.

That said, sometimes you do come across clever code that meets all of those requirements. These are small masterpieces and works of art and should be regarded as such.

At least the latency seems pretty good?

One of my favorite parts of the article (emphasis mine):

In the database world, developers are sometimes tempted to bypass the RDBMS, for example by storing everything in one big table with two columns labelled key and value. While this entity-attribute-value model allows the developer to break out from the structure imposed by an SQL database, it loses out on all the benefits, since all of the work that could be done efficiently by the RDBMS is forced onto the application instead. Queries become much more convoluted, the indexes and query optimizer can no longer work effectively, and data validity constraints are not enforced. Such designs rarely make their way into real world production systems, however, because performance tends to be little better than abysmal, due to all the extra joins required.

Oh man, if only. I can think of at least one example of a a platform with this very problem — and with the associated horrible performance profile — that is very widely deployed and used in production environments around the world. I’m sure you can think of others.

Anyhow, say what you will about Scott Rosenberg’s book, Dreaming in Code — but the fact is, it makes Googling for experiences of actually dreaming in code fairly impossible.

Personally though, I find dreaming in code to be very real. My dreams have always quite vividly blended reality and the imaginary, often leaving me confused as to which is which, and leaving me with a somewhat tenuous connection to the former. Code dreams are no different, and I’ve found that mine fit into three major types:

1. The Text Editor. This is your fairly standard code dream. In my case, white background, plain text and some code appearing or being written. Sometimes, it might make sense and actually relate to a project I’ve been working on or code I’ve being writing, but quite often this code doesn’t make any sense whatsoever.

   Often, there is no background or text, but just the lines and constructs of code floating in a place where there is no physical reality. I wonder if mathematicians have dreams similar to these, but with mathematical constructs?

2. The Inspiration. These dreams are comparatively rare, and don’t actually seem to involve any coding whatsoever. However, they very specifically relate to something I am working on, and when I wake up I know how to structure some code that I have been struggling with.

   This seems to be a pretty straightforward case of the brain working on a waking-world concern while asleep. Too bad the hours aren’t billable.

3. Code Blends With Reality. This is the strangest type of dream and the most difficult to relate, but in many ways my favorite. In these dreams, physical reality seems to blend and mix with the reality of code. While there is a normal dream of the physical world underlying everything here, in these dreams I interact with that world with code instead of in the normal physical manner.

   For example, I might find myself writing a script to light a campfire. Or instead of traveling from place to place by walking or in a car, I might just fiddle with the parameters that define my location. People may speak in code or in concepts rather than words.

Overall, I find #3 to be the most common type of code dream I have, as well as the most interesting. It lets the world become a playground that is strangely close to the real world. It is almost as if, in these dreams, magic is real, and code is magic.

While it’s probably not the most important thing in the world, I’m really curious to hear whether lots of other people out there dream in code, and how everyone else’s code dreams differ from mine.

After all, we spend an amazing amount of time asleep throughout the course of our lives. Who knows, maybe if talk about dreaming code enough, clients will agree that those hours asleep should be billable after all, eh?

To get myself into the right mindset for my upcoming trip, tonight I am enjoying Stone’s Sublimely Self-Righteous Ale. As frequent drinkers of Stone are surely aware, that brewery is full of downright bastards.

Which is why I just had to share this brilliant excerpt from the label on the back of this dastardly, self-rightous bottle:

Yes, we damn well know our stuff here at Stone, and it would be irresponsible of us to not acknowledge how remarkable this heavenly creation of ours is. Thus the name we are compelled to give it — Stone Sublimely Self-Rightous Ale – serves as a reminder of just how good we are, in both liquid and verbal form.

And also:

When you’re good, you’re good. And when you do something great, the least you can do is acknowledge it. Others benefit from knowing.

For the record, this self-righteous ale lives up to its label and leaves a smile on your face — or, at least, on mine.

• Democracy is not a truth machine. One of the best articles I’ve read all week. In it, a bearded philosopher eloquently demonstrates why democratic processes can’t be trusted to find the truth about objective facts about reality. For example, while a democratic process can be used to decide what we should do about climate change, the underlying scientific reality is not up for debate.

• Why we invented monsters. Paul Carr start with the idea that monsters grew into the human consciousness in the image of predators, such as felines and snakes. Eventually, as protohumans transformed from a prey species into predators, our imaginations transformed as well.

• The scandal of the Alabama poor cut off from water. It really kills me that we need a foreign news source to report about the fact that America’s infrastructure is failing and the promises of citizenship aren’t panning out for some of those who have the greatest need. Reading this article, others like it, and watching the documentary Waiting for “Superman” over the weekend has left me with a lot of questions in a place where there are few good answers.

• Why America’s Death Penalty Just Got Us Sanctioned by Europe. The European Union has decided that it will have no part in the barbarism involved in the methodical killing of human beings by their peers. I completely agree with Ford Vox’s characterization of the situation:

  The death penalty is a blind spot in our democracy, our own peculiar national anosognosia. It probably will take the rest of the world shouting us down in order to recognize our impairment.

• A tale of two systems. The folks at Remapping Debate contrast a failing labor system in America with a robust, unionized system in Germany.

• Hitch. Sam Harris, eloquent as always, on Christopher Hitchens’ death:

  Needless to say, he was effortlessly lucid and witty—and taking no prisoners. There should be a name for the peculiar cocktail of emotion I then enjoyed: one part astonishment, one part relief, two parts envy; stir. It would not be the last time I drank it in his honor.

• Freakonomics: What Went Wrong?. Andrew Gelman and Kaiser Fung examine many of the conclusions in Freakonomics and Superfreakonomics which have worked themselves into the cultural consciousness and which are now taken for granted. Specifically, they show that many of these conclusions are just plain wrong.

• Our lease doesn’t allow pounding anything into the wall, so the structure had to be entirely free-standing.
• I love bouldering on overhanging walls — the steeper the better. But we wanted to be sensitive to the fact that overhangs are not everyone’s cup of tea.

The Wall

In the end, we settled on an adjustable 10’ x 10’ lean-to design.

My roommate Chris and I have both found that mentioning the dimensions of the wall is a great heuristic for identifying climbers and non-climbers. The usual response from a non-climber is along the lines of, “Really? Isn’t that too small?”

Everyone always changes their mind on that after a good workout on the wall.

Chris and a friend handled most of the construction of the structure, which took about 40 hours in total. I think the most time-consuming part of the process — aside from waiting for the deck paint to dry – was drilling each of the dozens upon dozens of holes and installing a t-nut in each.

As I mentioned earlier, the incline is adjustable. Originally we had a 15° overhang, but have since dropped the wall down a bit further to 30°. This seems to be a nice compromise given that our friends are climbers with varying amounts of experience, specialties, and skill levels.

Setting — First Try

Initially, I tried a couple of traditional setting strategies. The specifics varied, but the basic idea was to visualize the outline of a problem and then set it piece by piece. I quickly learned a couple of things:

1. This takes skill. Just because you are good at climbing a certain type of problem does not mean you will be able to set similar satisfying problems. It’s a completely different thought process and creative skillset.

2. Setting is hard work! At first I was trying out the problem as I set each piece, which was very tiring. I heard a better strategy was to set the whole problem before trying to test and tweak it. This was great advice, but climbing up and down with holds and screwing them in is still a lot of work.

I came out with a newfound respect for routesetters at the gyms I go to, and it gave me some small amount of additional insight into bouldering problems in general.

Setting — Second Try

What ultimately made me try a different strategy was thinking more deeply about how we were using the wall. Given that the friends I climb with are all at different levels, we would generally just try climbing around or playing add-on rather than climbing specific problems.

Add-on is a very simple game. In a sense, it’s the bouldering version of H.O.R.S.E. The first climber chooses a starting position and makes a single move. The next climber copies that move, and then adds on another move. This is a great game when you have climbers at different levels, since everyone can play along and take part in some friendly competition.

Given that we were using the wall this way, I started thinking more about where to place holds on an individual basis, rather than where to place problems. Instead of trying to visualize an entire problem, I now just think about where a single hold might be interesting, and what orientation might make it fun to pull on.

Since I only have to consider one hold at a time, the cognitive load required is a lot lower. This is nice, since I’m not a very good routesetter. By just throwing up each hold in an interesting position, it’s a lot easier for me to fill the whole wall.

Here’s one of my favorite holds from So Ill, brilliantly entitled The Picking:

As a field test, we played quite a few games of add-on last Saturday, and it was tons of fun!

New Holds & Resetting

I’ve subscribed to So Ill’s hold of the month club, and it gives me an excuse to reset things and try something new every month or so. These just arrived recently:

I took the opportunity to move things around a fair bit. I moved The Picking much higher up, and rotated it to a fun new orientation. I also threw on a smattering of underclings and other new stuff.

I had actually tried putting The Picking in a similar orientation originally, but found that the it would just spin when pulled sideways — no matter how tightly I tried to bolt it in. This time I wised up and put a small hold below it to give it some reinforcement.

New game of add-on tomorrow, and we’ll see how it goes!

I’m assuming you have a working Homebrew, Python, and pip. You’ll also need my Homebrew formula for Boost.

Once you’ve got that, it’s pretty straightforward:

$ brew install imagemagick --with-magick-plus-plus
$ brew install boost --with-thread-unsafe
$ pip install pgmagick

Building Boost takes a long time so don’t fret if you don’t see anything for a while. Try it out and it should work:

$ python
Python 2.7.2 (default, Oct 20 2011, 17:33:50) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pgmagick
>>> pgmagick.gminfo.library + ' ' + pgmagick.gminfo.version
'ImageMagick 6.x.x'

For extra credit, you should also be able to install the Python Imaging Library (PIL) as well:

$ pip install -f http://effbot.org/downloads Imaging==1.1.7

This all worked for me on OS X 10.7 (Lion). Your mileage may vary on other versions.

Case in point:

If you haven’t used Android, the back button is a prominent feature. Nearly every Android device has a hardware back button. The system maintains a stack of all the activities the user has navigated to, and when the user presses the back button, it takes the user to the previous activity.

This works both inside individual apps and also across process boundaries. For example, when I’m reading an email and push the back button, I end up back at my inbox. If I push the back button again, I’ll end up at whatever app I was in before I opened Gmail.

This functionality is all provided by the OS, so all you have to do to get it right is to not break anything.

Nonetheless, many developers have taken it upon themselves to intercept the back button and swallow it. Here’s what this is like when you intercept the back button on the web:

In other words, it’s completely obnoxious and unacceptable. Unfortunately, it seems that which we know to be obviously true in web development, is quickly forgotten when it comes to a mobile device.

I remember reading about a study at the Rochester Institute of Technology a few years ago, wherein researchers mounted eye-tracking devices on subjects who were washing their hands. A very simple task: washing your hands.

What the study found was a new type of eye movement, the “planful” movement. In short, before interacting with any object, we build a model of that interaction in our minds and look at the object, without being consciously aware that we are doing so. For example, your eyes and your brain are glancing at and scouting out the paper towel dispenser while you are still rinsing your hands.

The same concept that applies to navigating your bathroom sink applies to navigating a mobile operating system. Your app may only be displaying one specific activity on the screen, but you can be sure that the user has constructed a mental model of how they are going to navigate through your app, through their device, to accomplish whatever they need to accomplish today.

Most of the time, these mental models aren’t fully conscious or completely articulated. Ask someone how they would get from Angry Birds to Gmail, and you’ll hear something along the lines of, “I’ll save and back out of the game and then open up Gmail.” Their mental machinery has abstracted away the minutiae of what they would specifically push or click on.

Instead, users just rely on their intuitive experience of how to navigate a system. That intuitive experience makes certain assumptions regarding how this virtual world is structured. These assumptions are often as strong as your assumptions regarding the physical world — up is up, down is down, and if you retrace the way you came, you’ll always end up where you started.

When you break these unconscious and conscious assumptions regarding how things work, you are basically giving your users a mental segfault:

Don’t break the back button.

If you’re just looking for the quick fix, skip ahead to the bottom of this post.

To sum up the issue, our server was responding with a Content-Type header of application/xhtml+xml to both Opera and wget. In Opera, this triggers an XML parser, which would fail since our content is actually text/html.

Of course, nowhere in our code were explicitly setting the Content-Type header to anything other than text/html, so the behavior was puzzling. Additionally, the server was responding with an application/xhtml+xml type even when the Accept header from the browser specified */*. This made no sense at all, since if the browser was willing to accept anything, we should be sending the content in its default text/html.

ASP.NET Browser Detection

As it turns out, ASP.NET has a somewhat questionable feature that allows you detect browser types and capabilities, largely based on the browser’s request headers. This is mediated through a browser definition file (*.browser), which is just a bunch of XML that matches up request header patterns to browser types and know capabilities. This file lives in your ASP.NET applicaiton’s App_Browsers folder.

The known capabilities for the current user agent are all available through the HttpContext.Request.Browser object.

As I said, all very questionable. The idea of having a giant database of browsers and what they are like just rubs me wrong and strikes me as unmaintainable. In fact, we only tried out the whole browser definition file as part of a proof-of-concept for some mobile pages. The feature never quite worked correctly, so we abandoned it and thought that was the end of that.

The insidious preferredRenderingMime

Of course, that wasn’t the end of that. For each browser definition in a browser definition file, you can define a preferredRenderingMime value for a browser. For example:

<capabilities>
  <capability name="preferredRenderingMime" value="application/xhtml+xml" />
</capabilities>

Most of the larger *.browser file compilations floating around the Web have Opera set to preferring a MIME type of application/xhtml+xml. A lot of files will default to a preferred type of application/xhtml+xml for all browsers that pass an Accept: / request header.

And even though we use ASP.NET MVC and no longer are using any of the browser detection stuff at all, the System.Web.UI.Page class has this fun code that runs when the page is processed:

1
2
3
4
5
6
7
8
9

private void SetIntrinsics(HttpContext context, bool allowAsync)
{
    ...

    HttpCapabilitiesBase browser = this._request.Browser;
    this._response.ContentType = browser.PreferredRenderingMime;

    ...
}

Brilliant, right? Since Opera prefers XHTML, this code does you the favor of automatically setting your response content type to application/xhtml+xml. Of course, since your actual content is still HTML, this causes an XML parse error and all your Opera visitors are hosed.

This might make sense if you are doing the classic ASP.NET Web Forms thing with server controls that adapt their rendering based on the browser’s preferred MIME. But even if you are using ASP.NET MVC, your .aspx views are still essentially pages, and this old code will still run.

Broken wget

Unfortunately, this SetIntrinsics code has another nasty side effect. If your application has already sent out response headers or content, it will just throw an exception since Response.ContentType can’t be set after response headers have already been sent.

In the case of Starbucks.com, this meant that issue wasn’t just that Opera visitors experienced a parse error, but that an exception would be thrown for any browser for which ASP.NET tried to switch the Response.ContentType. This would result in absolutely no content being served, resulting in a blank page for Opera visitors.

Furthermore, a large percentage of crawlers and search engines use wget to grab pages. wget sends an Accept header of */*, and runs into the same no-content issue. A fine mess all around.

The fix

The simplest fix, of course, is to get rid of any *.browser files you may be using in your application. I understand redirecting to a mobile version of your site for mobile browsers or the like, but basing any major functionality on guesses about the user’s browser is a great path to future pain.

If, however, you want to keep your browser definition files around, consider removing any uses of the preferrendRenderingMime capability. Here’s a regex that should be able to find those instances for you:

^.+"preferredRenderingMime".+$

Just do a find & replace on that and you should be good to go. This is what we ended up doing for Starbucks.com and Starbucks.co.uk, which I’m happy to say now work perfectly for Opera and wget users alike!

We love our bikes not because we race them, ride trails or perform tricks with them, although sometimes we do all of that. We love our bikes mainly because they are our transportation, our freedom, our way of moving through the spaces we call our home.

• Works equally well for simple and complex data. Regular HTTP POST works great for simple data, but gets unwieldy for anything hierarchical. XML works for complex data, but is too wordy for something simple.

• Compact and human-readable. Really, this just comes with the territory when you’re using JSON for anything.

• Easy to debug using Fiddler or related tools. You just have to type in or modify a JSON string when you want to do some ad-hoc testing.

• Easy to add support for to any server. In fact, support for receiving JSON POST is built into the latest versions of CherryPy and ASP.NET MVC.

That said, JSON POST still doesn’t seem to be all that popular compared to an old-style URL-encoded HTTP POST. One explanation I’ve heard proposed for this is the lack of support in jQuery. By default, jQuery goes with the old-style POST. You know:

foo=bar&abc=xyz&x=123

Sure, you can pass in a complex type and jQuery will gladly serialize it into this format for you, but good luck trying to read that with your human eyes, or trying to piece it back together on the server in any sane way.

The really sad thing is that jQuery has a great getJSON() function that lets you receive JSON output and parses it appropriately. But there is no built-in support for posting raw JSON.

To that end, I threw together this little plugin that I use all over the place:

1
2
3
4
5
6
7
8
9
10
11
12
13

  jQuery.extend({
    postJSON: function(url, data, callback) {
      return jQuery.ajax({
        type: "POST",
        url: url,
        data: JSON.stringify(data),
        success: callback,
        dataType: "json",
        contentType: "application/json",
        processData: false
      });
    }
  });